lkml.org 
[lkml]   [2009]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] PM updates for 2.6.33
On Sun, 6 Dec 2009, Arjan van de Ven wrote:

> > Arjan, can you try testing the USB timings again with the patch below
> > (for vanilla 2.6.32)?
> >
> > Fair warning: I just composed this and haven't tried it out myself.
>
> unfortunately it does not make a difference that I can notice in the
> graphs.
>
> http://www.fenrus.org/graphs/resume2.svg

Disappointing...

> the resume problem seems to be that we resume all the hubs sequentially,
> much like we used to discover them sequentially during boot....

But the patch should have reduced the time required to resume each
non-root hub. So the fact that they go sequentially shouldn't matter
as much.

For root hubs the patch won't help. Their delays can't be reduced.

> I do not know how much I'm asking for, but would it be sensible to do a
> similar thing for hub resume as we did for boot? eg start resuming them
> all at the same time, so that the mandatory delays of these hubs will
> overlap ?

For one thing, there shouldn't be any mandatory delays for non-root
hubs during resume-from-RAM (although this depends to some extent on
your system firmware -- and it probably helps to have USB-2.0 hubs
rather than USB-1.1).

More importantly, what you're asking is impossible given the way the PM
core is structured. The hub-resume routine can't return early because
then it wouldn't be possible to resume devices plugged into that hub.

(Ironically, your request is essentially what Rafael was trying to
accomplish in the patches that provoked this email conversation.)

Guess I'll just have to try out your timing log addition for myself and
see what's going on...

Alan Stern



\
 
 \ /
  Last update: 2009-12-06 22:49    [W:0.214 / U:0.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site