On Wed, 11 Nov 2009, Sarah Sharp wrote: > On Wed, Nov 11, 2009 at 04:22:42PM -0500, Alan Stern wrote: > > On Wed, 11 Nov 2009, Sarah Sharp wrote: > > > > > Make the USB core check the bandwidth when switching from one > > > interface alternate setting to another. Also check the bandwidth > > > when resetting a configuration (so that alt setting 0 is used). If > > > this check fails, the device's state is unchanged. If the device > > > refuses the new alt setting, re-instate the old alt setting in the > > > host controller hardware. > > > > That's right. Our stack should have been designed this way from the > > beginning, with periodic bandwidth being checked and allocated as soon > > as an altsetting is installed. Unfortunately, going back and changing > > all the HCDs now would be a huge job. > > You could have a generic USB core function that does the checking for > OHCI, UHCI, and EHCI. The bandwidth requirements are in the bus > specification, and there shouldn't be any host controller specific > limitations, correct? There are, because different controllers have different scheduling horizons (i.e., different hardware schedule lengths). Luckily, that can be parametrized. In fact it should be -- to inform drivers of the isochronous scheduling constraints we need to export the minimum and maximum scheduling delays, and the maximum is closely related to the length of the hardware schedule. Regardless, moving everything into the core won't be all that easy, especially for ehci-hcd. The drivers would all need to be changed to use a single common data structure to represent their allocations. For high-speed, there would have to be a new data structure to represent the schedule info for each TT (this has to be added anyway). Maybe we should get started on doing it, even though it will be hard... > > > */ > > > int usb_hcd_check_bandwidth(struct usb_device *udev, > > > > Since this does more than just check, it should have a different name. > > usb_hcd_allocate_bandwidth()? Okay. > I don't disagree with you. Here's the bigger problem I'm trying to > solve. The xHCI specification says you have to issue a reset endpoint > command after a successful device reset. That command will remove all > endpoints except the control endpoint 0 from the internal structures and > schedule. The xHCI hardware also keeps track of the device state, so > the xHCI internal state for that device is reset to default. xHCI seems to complicate everything by taking on more and more of the functions that up 'til now have belonged in usbcore. It would be nice if we could arrange things so that the core code doesn't end up containing a spaghetti maze of special cases for USB 3.0. > Since the reset endpoint command caused all the other endpoints to go > away in the internal xHCI structures, I need to reinstate the old > configuration and alternate interface settings. Reinstating the > configuration with alt setting 0 is this added code. The previous > alternate interface settings are re-instated with the call to > usb_set_interface() later on in usb_reset_and_verify_device(). Okay, I accept your point. 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
