Re: [RFC] usb: dwc2: hcd: fix split schedule issue
From: John Youn
Date: Fri Nov 13 2015 - 00:05:23 EST
On 11/11/2015 8:46 PM, Doug Anderson wrote:
> On Wed, Nov 11, 2015 at 8:29 PM, John Youn <John.Youn@xxxxxxxxxxxx> 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
> I'll keep digging tomorrow, too.
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().
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/