On 04/11/2017 09:31 AM, John Youn wrote: > On 04/11/2017 12:45 AM, Felipe Balbi wrote: >> >> Hi, >> >> John Youn <john.y...@synopsys.com> writes: >>>> Thinh Nguyen <thinh.ngu...@synopsys.com> 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.
Also, another thing is that the device uses legacy, level-triggered, PCIe interrupts, so for as long as the interrupt is asserted, the TH is called repeatedly. 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. Unfortunately the device controller does not support MSI interrupts, where it would be edge triggered and you would only see an assertion packet (no de-assertion). With that you would probably not see this behavior. Regards, John -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
