On Sep 24, 2008, at 4:16 PM, Benjamin Herrenschmidt wrote:
On Wed, 2008-09-24 at 11:42 -0500, Milton Miller wrote:
I was trying to understand why the mask and early eoi, but I guess its
to handle other more limited interrupt controllers where the
interrupts
stack in hardware instead of software.
No Milton, we must do it that way, because the EOI must be done on the
right CPU even on XICS, or we won't get the CPU priority back properly.
Ben and I had a online chat, and he pointed out I needed to be more
specific in saying what I was thinking.
I think the flows we want on xics are:
(non-threaded)
getirq (implicit source specific mask until eoi)
handle interrupt
eoi (implicit cpu priority restore)
(threaded)
getirq (implicit source specific mask until eoi)
explicit cpu priority restore
handle interrupt
eoi (implicit cpu priority restore to same as explicit level)
cpu takes interrupt, checks soft disabled
if so,
set hard disabled
else
call get_irq
if threaded
write cppr to restore this cpu irq dispatch state to
non-interrupt
mark irq thread as irq pending
else
handle interrupt
eoi (cppr = base)
irq thread will
handle interrupt
eoi
wait for marked pending again
The part Ben did not follow was that the cppr write to base priority is
done by the interrupted cpu (like the mask and eoi in the current flow)
and only the final eoi (where the mask is in the existing flow) is done
on which ever cpu happens to run the irq thread.
(optional) As I was discussing with Paul, when taking an irq when
soft-disabled but still hard enabled, it is possible to write the cppr
such that it would reject the pending irq and have it be considered for
dispatch to another cpu. But it would increase pathlength on both the
go-to-hard-disabled and return-from-hard-disabled and the hardware will
have some latency as it will likely send it back to the io source until
it retrys, so we would only want to do this if the hard-disable period
is sufficiently long.
milton
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
