On Mon, 15 Apr 2019, Doug Anderson wrote: > 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. I can confirm that the upstream dwc2 driver has fixed some bugs that are (or were at the time) present in dwc_otg. It was years ago and I don't remember the details, but one of the problems involved communication with a full-speed device. Possibly isochronous transfers; I'm not sure. The transfers were failing, and a USB bus analyzer showed that the reason was an invalid byte sequence sent by the Raspberry Pi while using dwc_otg. dwc2 sent the correct sequence. I don't know how much development work is currently going into dwc_otg, but I suspect it's a lot less than the amount of work being put into dwc2. Alan Stern
