Hi, On Sun, Apr 14, 2019 at 12:46 PM Lukas Wunner <lukas@xxxxxxxxx> wrote: > > On Tue, Apr 09, 2019 at 09:28:16AM +0000, Minas Harutyunyan wrote: > > Am 09.04.19 um 08:54 schrieb Jisheng Zhang: > > > The second one: 8000 usb interrupts per second when idle. > > > This is abnormal. any idea? Is it due to the lan78xx? > > > > dwc2 in host mode enable SOF interrupts if any periodic EP are in use. > > So, 8000 interrupts per second is expectant behavior. > > The dwc_otg driver patched into the Raspberry Pi Foundation's > kernel seems to make do with much fewer interrupts and much > lower CPU load. How does it do that and how could dwc2 be > made to do the same? Would it be possible for you to provide > me with documentation on the chip? The Synopsis website > requires registration for downloads and registration requires > a Synopsis customer ID. > > It seems the Foundation's dwc_otg driver was forked from code > that later begat dwc2. Your information might be misleading. The downstream dwc2 driver for Raspberry PI handles the SoF interrupts at FIQ (fast interrupt) time. The idea here is that this is to prioritize it above all other things in the system since FIQ can fire even if we're currently in another interrupt handler. IIRC: * FIQs don't get counted in /proc/interrupts. So probably you really are getting 8000 FIQs per second still, you just don't know it. * FIQs don't count towards CPU load calculations, so it looks like the CPU is less loaded by this than it really is. I have no evidence here, but I seem to remember someone telling me this, so if you believe this is wrong then ignore it. That all being said, though the purpose of using the FIQ is to improve the latency of handling SoF interrupts, it is also plausible that when it was written it also had the side effect of making the code more efficient. I mean, there's theoretically maybe some built-in efficiency by skipping all the Linux interrupt infrastructure, but I'd bet that's not a huge deal and a bigger deal is how inefficient the mainline dwc2 driver is at handling interrupts. I doubt you'd manage to get FIQ support for something like this on mainline, but you could possible spend more time improving the efficiency of the interrupt handler. I spent some time on this a while ago but it was just small things--I didn't gut it and re-think how to make it faster. Note also that I spent a bit of time a few years ago making the upstream dwc2 driver more robust despite some of its inefficiencies. In the end it was fairly robust, though if you wanted to do something like audio or USB webcams with it you'd still struggle without higher CPU speeds or patches like <https://crbug.com/820961>. I'm still of the belief that, unless the downstream driver has ported over the uFrame work I did, that the upstream dwc2 driver will be compatible with more more combinations of devices/hubs than the downstream one. -Doug
