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