Am Montag, 28. Dezember 2009 15:37:45 schrieb Alan Stern: > On Mon, 28 Dec 2009, Oliver Neukum wrote: > > > > I don't see any benefit to your patch. Instead of having a > > > "supports_transparent_suspend" flag, why not just have suspend and > > > resume routines that do nothing? > > > > True, the flag is stupid. Still some support from the core is needed as > > drivers cannot know whether they can safely let IO run. How about this? > > I'm not at all sure this is worth doing. It simplifies things to > assume that there are no outstanding URBs when a device is suspended. > See also the calls to usb_hcd_flush_endpoint() in usb_suspend_both(). That is true. > 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. If we keep URBs scheduled we can guarantee at most three steps in the resumption of a bus. Regards Oliver -- 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
