Hi, John Youn <John.Youn@xxxxxxxxxxxx> writes: >> John Youn <John.Youn@xxxxxxxxxxxx> writes: >>>> Thinh Nguyen <Thinh.Nguyen@xxxxxxxxxxxx> writes: >>>>> The dwc3 driver can overwite its previous events if its top half IRQ >>>>> handler gets invoked again before processing the events in the cache. We >>>> >>>> interrupts are masked, why would top half get invoked again? Is this, >>>> perhaps, related to DWC3 3.00a which has the "Interrupt line doesn't >>>> lower when masked" problem? We've added a lot of code to workaround that >>>> problem and, apparently, it wasn't enough. >>> >>> No, it is not related to that. We verified with PCIe traces. The >>> interrupt line gets deasserted after we mask it. And we put the >>> masking as close to the beginning of the top-half as possible. >>> >>>> >>>> In any case, there's no way top half would be invoked again in a >>>> properly working DWC3. >>> >>> Yet we still see it sometimes. Usually it doesn't create a problem, >> >> that's fair, but it's not for the reason you're describing :-) There >> might be another problem going on, because since we masked the interrupt >> and cleared all events, IRQ shouldn't be raised at all; unless, as I >> mentioned on the other subthread, the IRQ line is shared. >> >>> but if there happens to be a new event there, we get the failure. >>> >>> We didn't trace into that part of the kernel so we can't explain why. >>> But if there is any chance the interrupt line deassertion wasn't >>> detected in time, whatever part of the kernel that thinks it is still >>> asserted might just call our top-half again. This could be a totally >>> wrong assumption, but it doesn't seem too far-fetched. >> >> The kernel doesn't detect IRQ line assertion/deassertion. CPU gets an >> exception when that happens and calls Kernel IRQ handler vector. That >> will, in turn, figure out which line triggered, call the handler and so >> on. > > We're talking about PCIe though, where interrupt assertion and > deassertion are packets. So I would imagine the kernel has to do > something and there could be some latency associated with that. right, dwc3.ko isn't using MSI/MSI-X though. Unless PCI bus is handling that for us, I suppose we would be relying on the legacy physical interrupt line, no? -- balbi
Attachment:
signature.asc
Description: PGP signature
