On Fri, 1 Jul 2011, Sarah Sharp wrote: > On Fri, Jul 01, 2011 at 09:46:51PM -0400, Alan Stern wrote: > > On Fri, 1 Jul 2011, Sarah Sharp wrote: > > > > > > 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. > > > > Maybe it won't be the same. But if it isn't, I don't see how your way > > will work. > > I just meant that there are some simplifications and hardware specific > quirks that I don't know if you'll want for the EHCI implementation. Yeah, who knows? The EHCI hardware itself has some restrictions that go beyond what the USB-2 spec says. For example, during any microframe the controller will issue all the isochronous transactions before any of the interrupt transactions, and it will issue longer-period interrupt transactions before shorter-period transactions. That affects the scheduling; it means you can't do things like schedule an interrupt transaction to start in uframe 1 and an isochronous transaction (to the same TT) to start in uframe 3. > > For example, if you let the hardware do the dynamic scheduling, doesn't > > that mean it picks which frames to use for isochronous transfers with > > period > 1 frame? > > Yes, it does. There's this bit of text in the xHCI spec: > > "The xHC is free to schedule a isoch transfer at any time within an ESIT > as long as the complete TD shall have an opportunity to complete within > the ESIT." > > ESIT means basically the endpoint's interval in microframes. > > > Does it pass that information back to xhci-hcd? > > The starting frame number is supposed to be filled in whenever an URB > > is submitted. > > Yeah, I don't think we can get that information. We can pretend it was > the current frame when the interrupt happened, but with the BEI flag, > we'll only get an interrupt when all the frames in an URB complete. Do > drivers use that information? I think most of them set the ASAP flag. I don't know if any of them use it or not. But ASAP is not appropriate if a driver wants the transfers to occur at a fixed, known rate -- it can lead to delays in the sequence. > Right, I forgot the EHCI driver doesn't reject configuration or set > alternate setting requests. I was confused by your statement about > wanting to make sure URBs took up bandwidth even when they weren't > active. So you basically want to use the new bandwidth checking code to > make sure the bandwidth estimate is correct when an URB is submitted? Yes. Ultimately I'd like to make EHCI work more like xHCI -- bandwidth should be reserved and hardware resources allocated when an altsetting is installed, instead of waiting until the endpoint is used for the first time. Alan Stern -- 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
