On Fri, Jul 01, 2011 at 04:36:51PM -0400, Alan Stern wrote: > On Fri, 1 Jul 2011, Sarah Sharp wrote: > > The full bandwidth of the full speed bus (12Mbps) is reserved on the HS > > bus. Then we calculate, for each TT, what the worst case frame would be > > for it. So when a LS or FS device is plugged in, we have to recalculate > > the bandwidth that's free for both the HS bus (which is only effected if > > this is the first periodic endpoint added to this TT), and then the bus > > bandwidth for that TT. The newly added device would be taken care of by > > the TT bandwidth calculation in your example. > > That's what I'm talking about. Instead of recalculating the free > bandwidth for the LS/FS part of the bus, we should store it along with > the TT. For xhci-hcd this would be a time-space tradeoff. > > However for ehci-hcd this is really necessary. The existing > implementation doesn't keep track of how much bandwidth has actually > been allocated; instead it relies on looking at how much is currently > in use. This is wrong, because the bandwidth can remain allocated for > some period of time even while it isn't being used. Hmm, ok. I'm still not sure you're going to want to calculate the EHCI TT bandwidth in the same way the xHCI driver will. We'll have to see once I get the algorithm coded up. Have you gotten reports about problems with the EHCI TT bandwidth scheduler, or do you just know it's not working properly? The EHCI driver will at least reject the URB if it can't find space in the schedule, correct? It seems like you just want to capture that issue earlier? Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
