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

[John Youn]

On 11/11/2015 8:46 PM, Doug Anderson wrote:
> John,
> 
> 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
> <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






--
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/