Re: [RFC] usb: dwc2: hcd: fix split schedule issue

From: John Youn <John.Youn@synopsys.com>
To: Doug Anderson <dianders@chromium.org>,
	John Youn <John.Youn@synopsys.com>
Cc: Yunzhi Li <lyz@rock-chips.com>,
	Julius Werner <jwerner@google.com>,
	"Dinh Nguyen" <dinguyen@opensource.altera.com>,
	"Kaukab, Yousaf" <yousaf.kaukab@intel.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	wulf <wulf@rock-chips.com>,
	Kever Yang <kever.yang@rock-chips.com>,
	caesar <caesar.wang@rock-chips.com>,
	Tao Huang <huangtao@rock-chips.com>,
	rockchip-discuss <rockchip-discuss@chromium.org>
Subject: Re: [RFC] usb: dwc2: hcd: fix split schedule issue
Date: Fri, 13 Nov 2015 05:05:12 +0000	[thread overview]
Message-ID: <2B3535C5ECE8B5419E3ECBE30077290901DC3CBCA4@US01WEMBX2.internal.synopsys.com> (raw)
In-Reply-To: CAD=FV=W_SEGMMY-+gezfnAsujO34YxQg0MsYKvVkEAFKNFB+rA@mail.gmail.com

On 11/11/2015 8:46 PM, Doug Anderson wrote:
> John,
> 
> On Wed, Nov 11, 2015 at 8:29 PM, John Youn <John.Youn@synopsys.com> wrote:
>> I also feel it is not quite right as the SSPLIT should be able to
>> happen during the SSPLIT of another device. I tried to reproduce
>> and see the same scheduling but don't see any hang due to it.
>>
>> Yunzhi, any details on what kind of hub and keyboard you are
>> using? I have the same Jabra 410 speaker.
> 
> I saw it with a standard Logitech mouse.  It wasn't a hang, but the
> mouse effectively became non-functional (behaved like it hung) when
> you started playing audio.  Once the audio stream stopped, the mouse
> would work again.  I was using the same Jabra 410 as well.
> 
> /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M
>     |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
>         |__ Port 2: Dev 6, If 0, Class=Human Interface Device,
> Driver=usbhid, 1.5M
>         |__ Port 3: Dev 5, If 0, Class=Audio, Driver=snd-usb-audio, 12M
>         |__ Port 3: Dev 5, If 1, Class=Audio, Driver=snd-usb-audio, 12M
>         |__ Port 3: Dev 5, If 2, Class=Audio, Driver=snd-usb-audio, 12M
>         |__ Port 3: Dev 5, If 3, Class=Human Interface Device, Driver=, 12M
> 
> Bus 002 Device 005: ID 0b0e:0412 GN Netcom
> Bus 002 Device 006: ID 046d:c05a Logitech, Inc. M90/M100 Optical Mouse
> Bus 002 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> 
> We've also had some discussion of this patch in our bug tracker at
> <https://chromium-review.googlesource.com/#/c/312160/>.
> 
> I'll keep digging tomorrow, too.
> 
> -Doug
> 

It seems to be an issue with single TT hubs. I've tried several
multi-TT hubs with no issues.

With a single TT hub I do see a problem though not the exact one
described. I see corrupted and dropped packets on the FS side of
the hub. In a microframe with SSPLIT.begin, taking up the max
bandwidth for the microframe, when another SSPLIT for a different
device is issued, the data gets corrupted on the other side of
the TT. Probably due to exceeding the bandwidth in the microframe
since a single TT hub's ports all share the bandwidth.

With this fix, the next SSPLIT goes out in the same microframe as
the SSPLIT.end and the data goes through fine.

However I don't think this will work as a general fix. Since it
is just skipping things without rescheduling. For example SSPLIT
now happens a microframe later but the CSPLIT is not adjusted so
it comes a microframe too early.

I think the correct fix is to create a proper schedule based on
all the active endpoints to make sure we don't go over the
bandwidth for a single TT hub. Or to make the adjustments earlier
like in dwc2_sched_periodic_split().

Regards,
John