Am Donnerstag, 23. Februar 2012, 21:41:25 schrieb Sarah Sharp: > 3. When a new configuration is selected, save the old U1 and U2 > timeouts, and then disable the timeouts and device-initiated U1/U2 (if > the device is configured). When the USB core calls into the xHCI driver > to add a new periodic endpoint for a bandwidth change, add the service > interval and endpoint type to a small linked list of endpoints, sorted > by configuration and interface numbers. If the USB core removes an > endpoint, delete it from the list. We might even be able to reuse some > of those awful bandwidth tables I had to create for the Panther Point > xHCI host controller. > > 4. Once the bandwidth change has successfully (but before the interfaces > are bound), call into the xHCI driver twice to calculate the new U1 and > U2 timeouts. It will attempt to submit an Evaluate Context command to > change the max exit latency for the device. If the xHC host agrees to > that latency, the xHCI driver returns a timeout. Otherwise the call > returns an error. (We have to increase the max exit latency stored by > the xHC before we change any timeouts in parent hubs, so that the xHC > will have added extra latency in its schedule before we enable U1/U2.) Why do you want to take driver binding into account? It seems to me that that is too early. Periodic transfers matter only when the driver decides to actually use them. I don't think you can calculate U1/2 latencies merely from descriptors without taking into account whether endpoints are used. Regards Oliver -- 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
