From: Bjorn Helgaas
> Sent: 12 April 2017 16:05
...
> >> So we mask the interrupt in the TH and a short time later, the
> >> interrupt de-assertion packet is sent on PCIe bus and if that's not
> >> seen right away we may already have another call to TH before the BH
> >> gets scheduled.
> >
> > not sure this can happen. If that's the case, every PCI driver would
> > have all sorts of tricks to cope with this, not only dwc3 :-)
Most don't care about extra interrupts.
But even going back as far as sun4 it was possible to get a 'spurious
interrupt' reported because the cpu exited the ISR before the write
to the device to drop the IRQ actually caused the interrupt to drop.
> > Bjorn, is this something that can happen on PCIe?
>
> I'm pretty sure that the device will send Deassert_INTx *after* the
> driver tells the device to stop interrupting. That should eventually
> result in deassertion of the level-triggered interrupt.
I believe that level sensitive (legacy) interrupts are emulated on
PCIe by sending packets to the host on both edges of the interrupt.
Any write to the device to disable interrupts could cross the above
message exchange.
Writing to a device to request an interrupt be de-asserted or disabled
has been asynchronous since cpu writes started being 'posted'.
(It was potentially async earlier.)
A read-back of the register is typically enough to ensure that the
IRQ line drops before interrupts are enabled.
MSI-X is potentially worse.
If you disable an MSI-X interrupt by writing a 0x1 to the enable word
you could do so after the interrupt generation logic has tested the
value of it, but before it has actually generated the PCIe write
to raise the interrupt.
Logic delays could easily mean a read-back would also complete.
In this case the interrupt won't be re-raised when later enabled.
So the kernel would need to remember the 'unexpected' interrupt and
itself call the ISR when the interrupt is enabled.
The MSI-X docs (I've read) do not indicate how much guard time you
need when updating the address and data values associated with the
interrupt. Writing all 16 bytes with a single TLP might not be
enough to guarantee that an interrupt won't be raised with 'mixed'
old and new data.
> I can't speak to the mechanics of interrupt masking and the IRQ
> subsystem. I do think all IRQ handlers should be prepared to handle
> spurious interrupts gracefully.
Agreed.
David
��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
