On Thu, Nov 12, 2009 at 10:50:36AM -0500, Alan Stern wrote: > 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. Sure. With xHCI, the hardware schedule can be expanded. Right now there's only one segment per endpoint ring, but I had plans to allow the rings to be expanded with more segments on the fly. I'm not quite sure how I would advertise the schedule length to the driver in that case. > 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... Maybe. For xHCI, I also need to know the interval at which the driver wants to poll, if it's different from the interval in the endpoint descriptor. That's going to require yet another hook for the xHCI driver, and it would be nice if the interval data could be combined into a more useful structure. I've had a couple non-Linux people suggest that it's very strange to poll at a different rate than the endpoint advertises; they seemed to view the advertised rate as a contract between hardware and software, rather than a suggestion. > > 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. When hardware starts to act like a scheduler, the functions it performs starts to mirror some of the functions that the USB core does. Then you throw in the fact that the hardware is supposed to support virtualization, and it gets even more complicated. The xHCI spec was written by a software engineer, so it's way more detailed and complex than EHCI. One might even say it's rather bloated. ;) > 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. Yes, I would like that too. Unfortunately, there are still four problems that I see where the xHCI driver will need new hooks: - non-standard polling rates (which I've mentioned above) - USB device suspend - resetting a configured device - bulk streams support USB device suspend is going to be, well, messy, because the hardware wants to know when a device is suspended so it can save power and memory by removing the endpoints from the schedule and stopping internal clocks if all the devices on a port are suspended. The xHCI spec says that software "shall" issue a command to stop the endpoint (with a "suspending device" bit set), wait until it finishes, and then issue a port suspend to the hub. I don't think the xHCI driver can wait on that command, since the USB devices might be being suspended prior to a system suspend or hibernate, where we want to do things fast. I'm not sure exactly how the system suspend/hibernate process works, so please correct me if I have the details wrong. Sarah -- 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
