Am Dienstag, 29. Dezember 2009 04:03:39 schrieb Alan Stern: > On Mon, 28 Dec 2009, Oliver Neukum wrote: > > 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. Yes, but I don't think we need to depend on that. I believe we can do away with hub_activate() if we do global suspend. And this is not just the cost of resubmitting the URBs but requesting the port status and waiting for it, because we walk the tree top down. We can simply globally resume, do the delay and assume all hubs are still present. If not, khubd will eventually deal with it. > > 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 Yes, but why do we care? There may be reasons we need to wake devices that were asleep when the system suspended, but does this need to be anything but a normal autoresume, which can happen fully asynchronous? > 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. I am tempted to treat USB 3.0 as a different system in terms of power management. It is just too different with functions as opposed to devices sleeping. 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
