* Benjamin Herrenschmidt <[email protected]> wrote:
> If my understanding of "threaded handlers" is correct, that is
> delaying the delivery of the interrupt to a thread while restoring the
> ability to process further interrupts of the same or lower priority
> immediately.
correct. It's basically a different type of 'flow' of handling an
interrupt. It's a host-side genirq-level detail that should have no
irqchip level impact at all.
The only detail is that sometimes a threaded flow /cannot/ be
implemented if the irqchip lacks certain methods. (such as a
mask/unmask)
i.e. Sergei's patch tweaking the irqchip data structures is wrong - the
correct approach is what i do for i386/x86_64: install a different
"threaded" flow handler. I prefer this to tweaking the existing
'fasteoi' handler, to make the act of supporting a threaded flow design
explicit. (and to allow a mixed threaded/non-threaded flow setup) I
didnt take Daniel's prior patch for that reason: he tried to tweak the
fasteoi flow handler - which is an almost good approach but not good
enough :-)
> There is no such thing as an explicit "ack" on fasteoi controllers.
> The ack is implicit with the reading of the vector (either via a
> special cycle on the bus or via reading the intack register for
> example on mpic).
well, even if it's coupled to the reading of the vector, there is an ack
initiated by the host. This is not really a fundamental thing, it's API
semantics of the hardware interface.
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.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
