All of lore.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: 89+ 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 10:06 ` [PATCH 01/04] Driver Core: Add platform device arch data Magnus Damm
2009-05-27 10:06 ` Magnus Damm
2009-05-28 21:26   ` Rafael J. Wysocki
2009-05-28 21:26   ` Rafael J. Wysocki
2009-05-29  5:07     ` Magnus Damm
2009-05-29  5:07   ` Magnus Damm
2009-05-29  5:51     ` Paul Mundt
2009-05-29  5:51   ` Paul Mundt
2009-05-27 10:06 ` [PATCH 02/04] Driver Core: Add idle and wakeup functions Magnus Damm
2009-05-28 21:29   ` Rafael J. Wysocki
2009-05-29  5:10     ` Magnus Damm
2009-05-28 21:29   ` Rafael J. Wysocki
2009-05-29  5:10   ` Magnus Damm
2009-06-03  9:05     ` Rafael J. Wysocki
2009-06-03  9:05   ` Rafael J. Wysocki
2009-06-05  3:26     ` Magnus Damm
2009-06-05  3:26   ` Magnus Damm
2009-06-05 20:42     ` Rafael J. Wysocki
2009-06-05 20:42   ` Rafael J. Wysocki
2009-06-09  4:22     ` Magnus Damm
2009-06-09  4:22   ` Magnus Damm
2009-06-09 23:41     ` Rafael J. Wysocki
2009-06-09 23:41   ` Rafael J. Wysocki
2009-06-10  6:03     ` Magnus Damm
2009-06-10  6:03   ` Magnus Damm
2009-06-10  8:19     ` Rafael J. Wysocki
2009-06-10  8:19   ` Rafael J. Wysocki
2009-05-27 10:06 ` Magnus Damm
2009-05-27 10:06 ` [PATCH 03/04] PM: Add platform bus runtime dev_pm_ops Magnus Damm
2009-05-29 23:23   ` Rafael J. Wysocki
2009-06-02 13:37     ` Magnus Damm
2009-05-29 23:23   ` Rafael J. Wysocki
2009-06-02 13:37   ` Magnus Damm
2009-06-03  9:47     ` Rafael J. Wysocki
2009-06-05 10:40       ` Magnus Damm
2009-06-05 10:40   ` Magnus Damm
2009-06-05 21:24     ` Rafael J. Wysocki
2009-06-05 21:24   ` Rafael J. Wysocki
2009-05-27 10:06 ` Magnus Damm
2009-05-27 10:06 ` [PATCH 04/04] sh: Runtime platform device PM mockup Magnus Damm
2009-05-27 12:10 ` [linux-pm] [PATCH 00/04][RFC] PM: Runtime platform device PM Mark Brown
2009-05-28  6:02   ` Magnus Damm
2009-05-27 12:10 ` Mark Brown
2009-05-27 14:30 ` Alan Stern
2009-05-27 14:30 ` Alan Stern
2009-05-28  6:14   ` Magnus Damm
2009-05-28  0:32 ` Kevin Hilman
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:33   ` Alan Stern
2009-05-28  7:12 ` Rafael J. Wysocki
2009-05-28 15:28   ` Alan Stern
2009-05-28 15:28 ` Alan Stern
2009-06-01 19:04   ` Rafael J. Wysocki
2009-05-28 15:33 ` Alan Stern
2009-05-29  7:41   ` Magnus Damm
2009-05-28 17:14 ` Kevin Hilman
2009-05-29  9:17   ` Magnus Damm
2009-05-28 17:14 ` Kevin Hilman
2009-05-29  7:41 ` Magnus Damm
2009-05-29 13:45   ` Alan Stern
2009-05-29 13:45     ` Alan Stern
2009-05-29 18:18     ` Rafael J. Wysocki
2009-05-29  9:17 ` Magnus Damm
2009-06-02 21:37   ` Pavel Machek
2009-05-29 18:18 ` Rafael J. Wysocki
2009-06-02 13:44   ` Magnus Damm
2009-06-01 19:04 ` Rafael J. Wysocki
2009-06-01 19:31   ` Alan Stern
2009-06-01 19:31 ` Alan Stern
2009-06-01 19:58   ` Rafael J. Wysocki
2009-06-01 19:58 ` Rafael J. Wysocki
2009-06-01 22:16   ` Alan Stern
2009-06-01 22:16 ` Alan Stern
2009-06-01 23:21   ` Rafael J. Wysocki
2009-06-01 23:21 ` Rafael J. Wysocki
2009-06-02 14:51   ` Alan Stern
2009-06-02 13:44 ` Magnus Damm
2009-06-02 14:51 ` Alan Stern
2009-06-04 16:30   ` Rafael J. Wysocki
2009-06-02 21:37 ` [linux-pm] " Pavel Machek
2009-06-04 10:03   ` Magnus Damm
2009-06-04 10:03 ` [linux-pm] " Magnus Damm
2009-06-04 16:30 ` Rafael J. Wysocki
2009-07-18 11:49   ` Pavel Machek
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.