On Mon, 28 Dec 2009, Oliver Neukum wrote: > > Besides, the amount of time spent killing and resubmitting URBs is > > relatively small. What ends up eating all the time is resetting > > controllers and re-enumerating devices, plus the normal suspend/resume > > delays defined by the USB spec. > > > > We can't avoid the need for resets or re-enumeration when the > > controller loses power, but the other delays can be minimized by > > suspending the entire bus as a single operation instead of suspending > > each device individually. Then there's only one set of delays instead > > of a set for each device. > > Going to one delay is very likely to be the largest speedup we can do. > However, if we stop the URBs for the hubs, we'll have to wait for each > layer of depth in the device tree to restart IO before we go farther down. Sorry, I don't follow. Remember that regardless of when the hub interrupt URBs get restarted, they don't get _acted_ on until khubd is unfrozen. > If we keep URBs scheduled we can guarantee at most three steps > in the resumption of a bus. Keeping URBs alive while suspending devices is a tricky game. It doesn't work if a device is selectively suspended, i.e., the way we do things now and which Sarah says is required for SuperSpeed buses. An active URB for a suspended device will generally terminate with an error, caused by lack of response. 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
