Speed up USB resume.

[cjb]

The largest obstacle to resuming aggressively is the ~800ms that USB resume takes. This bug tracks investigation on how that could be sped up; a first area to look at is Arjan van der Ven's recent patchset to parallelize the (currently serial) 100ms delays for USB ports to come up, so that every port is brought up at the same time.

[mikus]

While I have no objection to this ticket, I believe that a more agressive resume will not be enough to dispel an impression of "slow responsiveness" that a XO user might assert. When my (non-suspended) XO has not had any keyboard input for a while (and particularly if a task happens to be running and using 100% of the CPU), I can press a key - then have to wait much more than 800 msec to see that character appear on the screen.

FWIW, at home I usually run with five or more devices plugged into the USB. Although I normally haven't used suspend (NM 0.6 doesn't resume my ethernet connection), when I have tested it I have *not* felt unduly "held back" by the time the XO takes to re-activate my USB devices. [Rightly or wrongly, my impression is that what takes time after resume is for the software to dialogue with the device, not the delay for the port to come up.]

I'm glad that under 0.83 the software does not appear to be scanning the content of my "permanent" SD card -- that could take minutes all told. [If done after a 'resume', such a scan would cause the XO to feel "unresponsive" for a long long time.]

[cjb]

Mikus, your experiences with wired ethernet and no suspend aren't very relevant to these power management tickets.

[mikus]

Replying to cjb:

Mikus, your experiences with wired ethernet and no suspend aren't very relevant to these power management tickets.

The first sentence of the description of this ticket emphasizes "resuming aggressively". I think it relevant to think about results.

I wanted to go on record as believing that, if the intent of this 'power management' ticket was to improve the user's impression of the XO, then "resuming aggressively" (specifically, "speeding up USB resume") would likely improve just a small part of that user's impression.

[dsaxena]

I have merged the following patch from 2.6.28 into our master tree. This is the patch that Arjan reffered to @ LPC and it only speeds up boot up intialization, not resume re-init. Marcelo posted a generic device resume parallelization patch but as pointed out in the short thread, there are a whole slew of issues in doing parallel resume in a generic way. Next step for me is to look at the USB resume path in detail and see where we can parallelize.

commit 672cde9409f412e11076e0bac053f1e992748bc4
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Mon Sep 22 14:44:26 2008 -0400

    USB: change hub initialization sleeps to delayed_work

    This patch (as1137) changes the hub_activate() routine, replacing the
    power-power-up and debounce delays with delayed_work calls.  The idea
    is that on systems where the USB stack is compiled into the kernel
    rather than built as modules, these delays will no longer block the
    boot thread.  At least 100 ms is saved for each root hub, which can
    add up to a significant savings in total boot time.

    Arjan van de Ven was very pleased to see that this shaved 700 ms off
    his computer's boot time.  Since his total boot time is on the order
    of two seconds, the improvement is considerable.

    Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
    Tested-by: Arjan van de Ven <arjan@infradead.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>