On Thu, 12 Nov 2009, Sarah Sharp wrote: > > 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. Changing the exported value should be good enough, as long as the value never decreases. > 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. There will be a certain amount of difficulty in allowing drivers to poll at a different rate. This is because we are going to reserve bandwidth for the endpoint at the time the altsetting is installed. In order to reserve the bandwidth we have to fix the polling rate and phase. Since these decisions have to be made before the driver can submit any URBs to the endpoint, it will be impossible for the driver to change the polling rate unless we specifically add an API for it. Such an API would probably have to work by modifying the interval value stored in the usb_host_endpoint's embedded descriptor and then reinstalling the altsetting. > 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. Currently we flush endpoints, but this is done after the device is suspended, not before. And we don't disable endpoints, which is what you're talking about. In addition, they would have to get re-enabled when the device is resumed. > 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. It depends on how long the wait will be. We don't disable endpoints until all their URBs have completed, so the endpoint won't be busy when you want to stop it. > I'm not sure exactly how the system suspend/hibernate process works, so > please correct me if I have the details wrong. Eventually the device-suspend parts may be done asynchronously in parallel, which will help. In any case, a short delay won't hurt. 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
