public inbox for linux-sh@vger.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: linux-sh@vger.kernel.org
Subject: Re: [linux-pm] [PATCH 00/04][RFC] PM: Runtime platform device PM
Date: Sat, 18 Jul 2009 11:49:48 +0000	[thread overview]
Message-ID: <20090718114947.GG1433@ucw.cz> (raw)
In-Reply-To: <20090527100625.29671.43166.sendpatchset@rx1.opensource.se>

Hi!

> > Sure, conditions may have changed while the system was asleep.  They might
> > also change while the system is awake.  In general, whether or not the system
> > was asleep shouldn't make any difference -- to as great an extent as possible
> > we should strive to pretend that the entire sleep took no time at all (or
> > simply didn't happen).
> > 
> > So: Suppose the system had been awake when the access point
> > disappeared.  What would the wireless adapter driver do then?  It
> > should try to do exactly the same thing if the access point disappears
> > while the system is asleep.
> 
> Not really.  Namely, when the access point _vanishes_ at run time, this is an
> error condition from which we have to recover, while if it's _not_ _present_
> after a resume, it's a normal situation and we shouldn't be recovering from
> that (the user might have changed the physical location while
> suspended).

I disagree here. User can just walk away with powered notebook.


> > You see?  The sleep should be transparent.
> 
> In some cases it won't be, because the hardware state changes while sleeping.
> For example, a laptop battery may be depleted while suspended, so that after
> resume it's in the 'low' condition, while it was in the 'good' condition before
> the preceding suspend.  Arguably, you can't drain a battery from 90% to 10%,
> for example, momentarily.  Also, a CPU fan might be 100% on before
> suspend,

Actually... going 90%->10% immediately is common behaviour of old
li-ion batteries.

> because the CPU was hot at that time, but that doesn't mean the fan should be
> 100% on after the subsequent resume, because it's likely that the CPU will be
> cold (on some systems trying to make the fan spin too fast may lead to
> general problems with thermal management afterwards).

100% is indeed sane default for fan. Yes you should slow the fan down
when you read the real temperature. And yes some systems play it safe
and do 100% fan during boot.

(Otherwise you may have heat problems if you suspend and immediately
resume).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

      parent reply	other threads:[~2009-07-18 11:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-27 10:06 [PATCH 00/04][RFC] PM: Runtime platform device PM Magnus Damm
2009-05-27 12:10 ` [linux-pm] " Mark Brown
2009-05-27 14:30 ` Alan Stern
2009-05-28  0:32 ` Kevin Hilman
2009-05-28  6:02 ` [linux-pm] " Magnus Damm
2009-05-28  6:14 ` Magnus Damm
2009-05-28  7:12 ` Rafael J. Wysocki
2009-05-28 15:28 ` Alan Stern
2009-05-28 15:33 ` Alan Stern
2009-05-28 17:14 ` Kevin Hilman
2009-05-29  7:41 ` Magnus Damm
2009-05-29 13:45   ` Alan Stern
2009-05-29  9:17 ` Magnus Damm
2009-05-29 18:18 ` Rafael J. Wysocki
2009-06-01 19:04 ` Rafael J. Wysocki
2009-06-01 19:31 ` Alan Stern
2009-06-01 19:58 ` Rafael J. Wysocki
2009-06-01 22:16 ` Alan Stern
2009-06-01 23:21 ` Rafael J. Wysocki
2009-06-02 13:44 ` Magnus Damm
2009-06-02 14:51 ` Alan Stern
2009-06-02 21:37 ` [linux-pm] " Pavel Machek
2009-06-04 10:03 ` Magnus Damm
2009-06-04 16:30 ` Rafael J. Wysocki
2009-07-18 11:49 ` Pavel Machek [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090718114947.GG1433@ucw.cz \
    --to=pavel@ucw.cz \
    --cc=linux-sh@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox