[lkml]   [2007]   [Dec]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] sleepy linux
On Wed 2007-12-26 21:23:37, Oliver Neukum wrote:
> Am Mittwoch, 26. Dezember 2007 21:17:22 schrieb Pavel Machek:
> > On Wed 2007-12-26 18:28:04, Oliver Neukum wrote:
> > > Am Mittwoch, 26. Dezember 2007 00:07:31 schrieb Pavel Machek:
> > > > Heute 00:07:31
> > > >  
> > > > This is RFC. It does not even work for me... it sleeps but it will not
> > > > wake up, because SATA wakeup code is missing. Code attached for illustration.
> > > >
> > > > I wonder if this is the right approach? What is right interface to the
> > > > drivers?
> > >
> > > IMHO you are making to many special cases. The system can be "sleepy"
> > > if all devices can be runtime suspended and all CPUs are idle.
> >
> > Is there an easy way to tell if all the devices are runtime suspended?
> Do you really want to know whether they are suspended or whether they
> could be suspended?

If they are suspended.

My plan is: let the drivers autosuspend on their own. If I see all of
them are autosuspended, then it looks like great time to put whole
system into s2ram...

> > I guess I need to know from atomic context :-(.
> Urgh. suspend() must be able to sleep and can fail.

That's ok.

... I also don't need to call any suspend() routines, because all the
drivers are already suspended, right?

And yes, I want device activity to prevent s2ram. If user is burning
CD, machine should not sleep. If user is actively typing, machine
should not sleep. My vision is: screen saver tells kernel keyboard
need not be very responsive, at that point keyboard driver can
autosuspend the keyboard, and if that was the last device, whole
system sleeps.
(cesky, pictures)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-12-26 21:37    [W:0.081 / U:3.424 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site