lkml.org 
[lkml]   [2015]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [RFC] usb: dwc2: hcd: fix split schedule issue
From
> To handle things smarter, I think I need to research how to deal with
> hubs attached to hubs attached to hubs. For instance:
>
> dwc2
> -> multi_tt hub
> -> single_tt hub
> -> device 1
> -> device 2

Keep in mind that there's always at most one (active) TT between host
and device. The TT is the point where high-speed traffic is translated
to low-/full-speed traffic, so after that you cannot translate again.
With multiple hubs you either have

-> high-speed 2.0 hub (TT inactive / irrelevant for this path)
-> multi or single TT 2.0 hub
-> device

or

-> multi or single TT 2.0 hub
-> full-speed 1.1 hub
-> device

All the information you need should already be in struct usb_device.
If udev->tt->multi == 0, then it must be scheduled in the same group
as all other devices it shares udev->tt (the same pointer address)
with. If udev->tt->multi == 1, then it belongs in the same group as
all that have the same udev->tt and the same udev->ttport. There's
even a udev->tt->hcpriv where you could link a data structure (array)
in to keep track of these matching devices.

I agree that this is a nice-to-have optimization, though... it's more
important to get the thing stable, and I think it's fine to assume
that all low-/full-speed transfers go on the same bus for the first
iteration.


\
 
 \ /
  Last update: 2015-11-16 22:01    [W:1.882 / U:1.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site