On Fri, Jul 08, 2011 at 03:17:56PM -0400, Alan Stern wrote: > On Thu, 7 Jul 2011, Sarah Sharp wrote: > > > Hi Alan, > > > > These compile, but haven't been tested yet. The last patch should give > > you an idea of what sort of algorithm the hardware folks came up with > > for LS/FS/HS bandwidth tracking. The SuperSpeed bandwidth tracking > > isn't done yet, but I don't expect many people to plug in large amounts > > of SuperSpeed periodic devices at this time. :) > > > > I would suggest starting with the last patch takes a table with a "row" > > per periodic interval and computes the bandwidth consumed, using the > > algorithm. All the rest of the code is just used to create that table, > > and revert it back if there isn't enough bandwidth for the changes. > > > > I'll test these further tonight/tomorrow and fix the inevitable silly > > mistakes I've made. > > Okay. I'm not going to have time to look at this closely for a while. No worries, it took me a month to wrap my brain around the algorithm. I don't think this is going to be ready for 3.1 in time anyway. > By the way, you went to some effort earlier to make sure that the same > bandwidth mutex would be used for both buses on an xHCI controller. Is > that still necessary? Since the buses are physically separate (they > use different wires in the USB cable), I would expect that the > scheduling and bandwidth calculations could be independent as well. Yes, it's still necessary, because there are global resources shared between both buses. In the case of the Intel xHCI host, it has a global limit on the number of endpoints, so we have to only allow one bandwidth change at a time. Adding or changing endpoints in either bus can also impact the direct memory interface bandwidth to the host (although I haven't gotten around to adding in bandwidth checking for that yet). I would suspect that other host controllers have other global resources that require the bandwidth mutex to be shared between both xHCI roothubs. So we can't allow bandwidth changes on both buses at the same time. > It's not too early to start thinking about how we can allow drivers to > request smaller-than-the-max bandwidth usage. It seems to me that in > the usb_host_endpoint structure, we should add a max_bytes_per_period > field. Normally this would be the same as the maxpacket value > (adjusted for multiplicity and bursting), but drivers could ask to make > it smaller. Hmm, yes, that could work. But I really need to know the max packet size and the burst/mult separately for the bandwidth algorithm. Maybe we also need a field for polling interval, since some devices advertise the wrong value, and some drivers actually do want to poll more often? > Actually, we'd need two copies of this field: One for the current value > and one for the new value requested by the driver. The current value > would be set equal to the new value at the next usb_set_interface call. > There wouldn't be any way to adjust the new value prior to a > usb_set_configuration call, but since drivers can't make those calls > directly, this shouldn't matter too much. Is there any reason a driver would submit an URB and then request a new alt setting? If not, why not just have the USB core write over the endpoint descriptors when the driver asks for the new value? If we do decide to allow drivers to modify a new field in the usb_host_endpoint structure, does it matter that there's a disconnect between what we're actually using and what a userspace program like lsusb sees? > This mechanism can be added later, but I think it would be a good idea > to add a field like this now so that we can use it in the upcoming > bandwidth allocation and scheduling changes. What do you think? I think this could be done in the call to the xHCI driver to add the endpoint. It would be as simple as setting the max packet size in the input context from the usb_host_endpoint instead of using the endpoint descriptors. But let's get the basic bandwidth support in the xHCI driver before we go optimize it for these special cases. 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
