The eCos, QNX, ChorusOs irq handling API
strauman at SLAC.Stanford.EDU
Thu Feb 20 20:33:07 UTC 2003
Valette Eric wrote:
> till wrote:
-- snip --
>> Sure, but if you have to manipulate the masks you have to assert
>> mutual exclusion
>> which means that you cannot handle interrupts (that critical section
>> better be short).
> But the section is usually
0) Mask this vector's bit
> 1) Mask other lower priority interrupts by mapipulating PIC masks
> 2) execute the handler,
> 3) Restore original pic masks
> This cannot be guaranteed to be *ALWAYS* short...
No, but you'd only mutex steps 1 and 3 individually (I've added
the LOCK/UNLOCKs above). If the only
permitted action for the handler is re-enabling its own vector,
or the priorities below itself (the only thing that probably makes
sense) everything is fine (otherwise, the PIC driver has to manage
a stack of masks tracking the ISR nesting level).
Of course, the handler has to use an API
call to do that it's not manipulating the PIC directly.
-- snip --
>> Of course, bitmask manipulation (i.e. 'disable(vector)' /
>> 'enable(vector)') has to be SMP safe.
>> BTW: one example of a driver who needs to do that is the tundra
>> universe PCI-VME bridge.
>> It encorporates a "PIC" itself and hence wants to re-enable it's PCI
>> IRQ at the OpenPIC ASAP
>> (to support VME interrupt priorities in software)
> Yes same for ISA inetrrupt. Browsing the code to answer greg question I
> was wondering why you did not acknloledge the VME request immediately as
> I have done on ISA :-)
It _is_ done immediately: by the Universe hardware - beyond software
More information about the users