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

From: Doug Anderson
Date: Fri Nov 13 2015 - 19:34:05 EST


On Thu, Nov 12, 2015 at 9:05 PM, John Youn <John.Youn@xxxxxxxxxxxx> wrote:
> 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.

Seems like different single TT hubs react differently. I got one
where the mouse kept working but the audio was just static...

> 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().

I've started working on this and just before I needed to leave my desk
I got something that seemed to work. I'll keep at it on Monday.

At the moment I'm making the assumption that we never got a multi_tt
hub attached to us. My code will always just schedule one split per
microframe. Would that be OK for now until we make the scheduler

To handle things smarter, I think I need to research how to deal with
hubs attached to hubs attached to hubs. For instance:

-> multi_tt hub
-> single_tt hub
-> device 1
-> device 2
-> single_tt hub
-> device 3
-> device 4

-> single_tt hub
-> multi_tt hub
-> device 1
-> device 2
-> multi_tt hub
-> device 3
-> device 4

In the first case I presume I could schedule device 1 and device 3 at
the same time, but not device 2 and device 4. In the 2nd case I
presume I could schedule all 4 devices independently. ...but I
haven't dug through the spec to confirm that, yet.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at