Hello.
Benjamin Herrenschmidt wrote:
The fasteoi flow seem to only had been used for x86 IOAPIC in the RT patch
only *before* PPC took to using them in the mainline...
I don't think so, I asked for the fasteoi to be created while porting
ppc to genirq :-)
Oh, I was unaware of such details. :-)
threaded handlers need a mask() + an ack(), because that's the correct
Not all of them. This could be customized on type-by-type basis. I.e. we
could call eoi() instead of ack() for fasteoi chips without having to resort
to the duplicated ack/eoi handlers.
I still don't see how ack() makes sense in the context of a fasteoi...
It doesn't make sense even in the context of 8259 with its level/edge
flows. That's what I'm talking about...
You can either just not EOI until it's handled, but you'll indeed
introduce delays for other interrupts of the same priority or lower, or
you can mask() and then eoi(), which is, I think, what Apple does, to
deliver the interrupt to a thread (and later unmask).
In any case, I don't see the need for a separate ack().
Yeah, that's what the threaded versions of flow handlers are doing. Except
they're calling ack() to actually EOI an IRQ.
Ben.
WBR, Sergei
-
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]
