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. 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. 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. 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. 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? 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
