Re: lan78xx: About 8000 usb interrupts per second when idle

From: Doug Anderson <dianders@chromium.org>
To: Lukas Wunner <lukas@wunner.de>
Cc: Minas Harutyunyan <minas.harutyunyan@synopsys.com>,
	Stefan Wahren <stefan.wahren@i2se.com>,
	Jisheng Zhang <Jisheng.Zhang@synaptics.com>,
	Woojung Huh <woojung.huh@microchip.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-rpi-kernel@lists.infradead.org" 
	<linux-rpi-kernel@lists.infradead.org>,
	Alexandru M Stan <amstan@chromium.org>
Subject: Re: lan78xx: About 8000 usb interrupts per second when idle
Date: Mon, 15 Apr 2019 10:35:31 -0700	[thread overview]
Message-ID: <CAD=FV=Wbt-g0QtWQ2KzmWsXRygCk6=mJ6xYrnbL6E_NAUY6QkA@mail.gmail.com> (raw)
In-Reply-To: <20190414194623.afp3fanjuq72ctln@wunner.de>

Hi,

On Sun, Apr 14, 2019 at 12:46 PM Lukas Wunner <lukas@wunner.de> 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