[lkml]   [2006]   [Nov]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] 2.6.18-rt7: PowerPC: fix breakage in threaded fasteoi type IRQ handlers
On Mon, 2006-11-20 at 11:01 +0100, Ingo Molnar wrote:

> so the question is not 'is there an ACK' (all non-MSI-type-of IRQ
> delivery mechanisms have some sort of ACK mechanism), but what is the
> precise structure of ACK-ing an IRQ that the host recieves.
> on PPC64, 'get the vector' initiates an ACK as well - is that done
> before handle_irq() is done?


> > So by doing a mask followed by an eoi, you essentially mask the
> > interrupt preventing further delivery of that interrupt and lower the
> > CPU priority in the PIC thus allowing processing of further
> > interrupts.
> correct, that's what should happen.
> > Are there other fasteoi controllers than the ones I have on powerpc
> > anyway ?
> well, if you mean the x86 APICs, there you get the vector 'for free' as
> part of the IRQ entry call sequence, and there's an EOI register in the
> local APIC that notifies the IRQ hardware, lowers the CPU priority, etc.
> We have that as an ->eoi handler right now.

Ok, so that's like me. Which means that what you need is a specific thre
aded_fasteoi flow handler that does mask & eoi, not ack.

Note that I still think it would work in the absence of mask too if the
controller only does edge interrupts, as it is the case for the cell.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-11-20 21:09    [W:0.099 / U:41.636 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site