On Mon, 19 Nov 2012, Sarah Sharp wrote: > On Mon, Nov 19, 2012 at 10:50:32AM -0500, Alan Stern wrote: > > Sarah: > > > > Improving the bandwidth management in ehci-hcd will require a lot of > > changes, and some difficult issues have come up. Maybe you can suggest > > a good way to approach them. > > > > The first problem is that when a Set-Interface request fails, the HCD > > needs to revert to the previous schedule settings. Now even though the > > badnwidth mutex gets held throughout the entire procedure, there's no > > guarantee that the old settings can be restored unless they are saved > > somewhere for reuse. > > > > This suggests that bandwidth allocation changes should be carried in > > multiple steps. Initially usbcore tells the HCD which endpoints are to > > be disabled and enabled, and then later usbcore tells the HCD either > > to accept the changes or to revert them. > > Sure. xHCI has to do this too, and currently doesn't handle it well, as > you've seen with the configuration failure bug fix. > > Where would you store the old and new bandwidth changes? Perhaps > somewhere in usb_device? Or if you don't want to add that to every USB > device, you probably could store that in the usb_hcd structure, since > bandwidth changes are protected by the bandwidth_mutex. It would have to be stored somewhere in the driver's private data structures. It couldn't go in the usb_hcd structure, because different HCDs would need to save different data. And besides, it would vary with the number and type of endpoints involved. > > The second problem is that periodic schedule changes can be rather > > invasive, causing service intervals to be missed for endpoints on > > devices other than the one being changed if rebalancing is needed. For > > this reason I would like to avoid rebalancing whenever possible. One > > example is when reverting an altsetting change, the other is when a > > Set-Config request fails. In that case we disable all the device's > > endpoints (other than ep0), which means there's no need to rebalance > > the schedule for all the other devices. > > > > Again, to recognize when this situation occurs, the HCD has to be told > > not to accept the previous changes (installing the new config) but to > > carry out different changes instead (disabling the entire device). > > So are you changing EHCI to be more like xHCI, in that bandwidth is > claimed before a configuration or alt setting is installed? I thought > currently the EHCI driver only added in URBs into the schedule a > just-in-time manner. That's right, and yes, I am thinking of changing ehci-hcd as you say. The USB spec actually states somewhere that this is how bandwidth is supposed to be reserved -- not that this really matters. > Perhaps we should only update the schedule after the configuration or > alt setting is installed? We could force a driver to claim an endpoint > before submitting any URBs to it, and release an endpoint when it was > done. I don't want to change the drivers. The time when the schedule actually gets updated would indeed be after the config or altsetting is installed. But most of the computations have to be done beforehand, to know whether there is sufficient bandwidth for the update to succeed. > That way if a driver doesn't use a particular endpoint, it doesn't take > up useless space in the schedule. This helps for webcams or serial > devices that don't need the endpoints until their open FOP is called, > and can release the endpoints when their close FOP is called. "FOP"? 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. > 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. 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. > > What do you think? Does this seem feasible? > > Your original idea of storing the state and reverting it does seem > feasible. However, I like the idea of doing one big fix to solve > several different bandwidth issues. What do you think of having drivers > claim endpoints? I really don't want to update the drivers. :-) Besides, installing an altsetting could be viewed as the moral equivalent of claiming all the endpoints it contains. 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
