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. > 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. > Suppose you have an endpoint using 75% of the available bandwidth/frame > but with a period of 8 frames. Now you want to end another endpoint > also using 75% of the bandwidth and also with a period of 8. With > worst-case scheduling, you have to assume the hardware will try to > squeeze both endpoints into the same frame and therefore you have to > reject the new endpoint -- which would be a pretty dumb thing to do > under the circumstances. Ok, let me just post some code before we get into the details. :) I'd really like to clean it up a bit, so it might not be until next week. > > Have you gotten reports about problems with the EHCI TT bandwidth > > scheduler, or do you just know it's not working properly? > > Both. It sort of works okay, provided you don't put it under any > stress. But it definitely has lots of bugs. I see. I had assumed it just worked, which was why it was a bit distressing to discover our xHCI hardware didn't do bandwidth checking. > > 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? > > No -- I want to do the calculation _correctly_ so that the URB won't > be rejected if there really is space available in the schedule. (And > conversely, the URB will be rejected if there isn't space available -- > I haven't heard of this happening but I'm not convinced it can't.) 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? 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
