On Wed, 21 Nov 2012, Sarah Sharp wrote: > > The USB spec already provides for this, to some extent. Altsetting 0 > > is not supposed to contain any isochronous endpoints and should have > > minimal bandwidth requirements. Drivers ought to switch back to > > altsetting 0 when they are not using the device. > > Yep. I have seen broken webcams with isoc endpoints on alt setting 0, > though. A lot of devices make this mistake, unfortunately. > > > It also means you don't have to go through a revert if the Set > > > Configuration or Set Interface control transfers fail. It has the > > > further advantage that drivers could specify the interval they're using > > > for periodic endpoints, and we could finally address the issue of xHCI > > > only being able to use the interval from the endpoint descriptors. > > > > Maximum transfer size too, not just interval. > > You mean that some devices have bogus bMaxPacketSize fields? I'm > confused by what you mean by maximum transfer size. Not bMaxPacketSize. I don't think altering that value would work unless the value in the descriptor was actually wrong, which is unlikely to happen. No, I meant that the driver may realize, for example, that it's never going to send a packet larger than 150 bytes even though bMaxPacketSize is 192. This may be more common than drivers wanting to change the interval. In fact, I'm considering changing ehci-hcd so that it will no longer support bandwidth allocations for any interval larger than 8 frames. Transfers might get scheduled with a larger interval, but they would be charged for bandwidth as though the interval was 8 frames. For isochronous endpoints this probably doesn't matter much. In fact, I'm not aware of any devices that have isochronous intervals larger than 1. Are you? > > This could be done as part of an extended set-interface API. Along > > with specifying the altsetting to install, a driver could pass a list > > of the transfer sizes and intervals it wants for all the periodic > > endpoints in the altsetting. > > Sure. Then we would only need to chase down the drivers that don't use > bInterval from the endpoint descriptors. Do you know of any drivers that really care about using a different interval? > > I really don't want to update the drivers. :-) > > Ok, I was just throwing it out there, since you were asking for ideas. :) > > I guess you're stuck with rebalancing after a Set Interface fails. > I don't think that will be too common though. Actually that's not the problem. When Set-Interface fails, things simply continue the way they were; no rebalancing is needed. The difficulty arises when Set-Interface succeeds but the updated endpoints can't be squeezed into the existing schedule. I'm not sure about what API we should use for this stuff. Maybe an extended version of usb_set_interface could take a pointer to a list of structures, each of which contains a pointer to a usb_host_endpoint and values for the desired max transfer size and interval. Something like that. For saving the existing settings during an update, I'd like to add an hcpriv_backup field to the usb_host_endpoint structure. Or perhaps it would be better to have hcpriv_new for storing the updated settings, which would then either be thrown away or copied into hcpriv. Finally, when usbcore wants to tell an HCD about endpoint changes, the method should accept two arrays: one for the endpoints that need to be dropped and one for the endpoints that need to be added. If we allow modifications to the max transfer size and the interval, those values would have to be included in the second array. There should be two methods. The first is for proposing a set of endpoint changes, and the second either accepts or drops the changes. (Hmmm, maybe that means we need three methods.) The same arrays would have to be passed to all the methods. 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
