Artyom Tarasenko wrote: > 2009/11/15 Blue Swirl <blauwir...@gmail.com>: > > On Sun, Nov 15, 2009 at 1:15 AM, Artyom Tarasenko > > <atar4q...@googlemail.com> wrote: > >> 2009/11/14 Blue Swirl <blauwir...@gmail.com>: > >>> On Sat, Nov 14, 2009 at 3:03 AM, Artyom Tarasenko > >>> <atar4q...@googlemail.com> wrote: > >>>> According to NCR89C105 documentation > >>>> http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/NCR89C105.txt > >>>> > >>>> Interrupts are cleared by disabling and then re-enabling them. > >>>> This patch implements the specified behaviour. The most visible effects: > >>> > >>> I think the current version also implements this behaviour. The > >>> difference is that now we clear on disable, with your version, the > >>> interrupts are cleared when re-enabling them. > >> > >> Doesn't this imply that the current version does not implement this > >> ("Interrupts are cleared by disabling and then re-enabling them") > >> behavior? ;-) > > > > The specification only says that the sequence disable-enable clears > > interrupts, but not which of these is true: > > - clearing happens in the moment of disabling (and interrupts after > > that are not cleared, current version) > > - clearing happens in the moment of re-enabling (your version, sort of) > > - clearing happens in both cases (lose interrupts) > > English is not my native language, but fwiw I think "and then > re-enabling" can only be the second variant. Without "then" it could > be either one or three. And if the first variant is what they really > meant, the part with "and then" is totally redundant and misleading.
It could also be a fourth: - Clearing happens continuously _during_ the time the interrupt is disabled. Note that neither this, nor the third possibility, have to cause lost interrupts - that depends on whether the code which enables interrupts checks for them being pending after enabling them, or checks the devices generating them. > > It's also interesting to think what happens between the interrupt > > controller and the devices. Clearing an interrupt at controller level > > does not clear the interrupt condition at the device. Aren't the > > interrupts level triggered on Sparc, so the interrupt is still posted? > > Is the interrupt actually masked by clearing until the level is > > deactivated? > > Looks unlikely to me. In the book "Panic! Unix system crash dump > analysis" the authors write that the first thing interrupt handler has > to do is disable the interrupt, and yes wrting "unix" they mean > "SunOS/Solaris". > > That's also what I observe debugging the Solaris kernel code > (Solaris kernel debugger is a really powerful tool). > Looks like interrupts can be shared between devices, so the general > handler disables the interrupt and then calls multiple device-specific > handlers sequentially and checks if any of then claims the interrupt. > If no one does it writes the message "Spurious interrupt %d\n". That's consistent with level triggered interrupts, and may require the interrupt to be cleared at the device before it is re-enabled at the interrupt controller. > > Or maybe the controller latches the interrupt so that even after the > > device releases the interrupt line, interrupt is still active towards > > the CPU. Then the clearing would make sense. > > Looks very realistic to me. >From what you said above about Solaris, I don't think you can distinguish between interrupts being asserted only while a device continues to assert it, and interrupts remaining asserted after the device stops. -- Jamie
