linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Andrew Morton <akpm@osdl.org>
Cc: linuxppc-dev@ozlabs.org,
	Johannes Berg <johannes@sipsolutions.net>,
	Alan Stern <stern@rowland.harvard.edu>,
	cpufreq@lists.linux.org.uk
Subject: Re: [Fwd: Re: via-pmu runs device_power_down in atomic context]
Date: Thu, 25 May 2006 15:44:49 +1000	[thread overview]
Message-ID: <1148535890.13249.250.camel@localhost.localdomain> (raw)
In-Reply-To: <1148534398.13249.246.camel@localhost.localdomain>


> No. If we call device_power_down with interrupts enabled, very bad
> things will happen. This powermac code is very carefully crafted to do
> things in a strict order and it's along those lines that the callbacks
> in the device model were initially defined. Now, people who don't
> understand shit about how to make power management reliable may have
> broken things around, but the powermac implementation is right there.

To be more precise, sysdev suspend is supposed to happen with irq offs
(it's specifically designed to handle legacy things, interrupt
controllers, ec...). Thus cpufreq suspend/resume need to assume that
it's being called in that context or be made something else than a
sysdev...

Regarding the possible down() if we walk through the irq_off device
list, well, that's indeed annoying, we probably need to pass a "no_lock"
argument. Never hit that one since as I told you, there are really few
if not no drivers using this facility of deferring suspend to after
interrupts are disabled. Also, the down there is harmless as in no
normal circumstances should it ever turn into a schedule() (there should
be no contention possible that late in the suspend process).

Ben.

  parent reply	other threads:[~2006-05-25  5:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1148531830.13249.237.camel@localhost.localdomain>
2006-05-25  4:59 ` [Fwd: Re: via-pmu runs device_power_down in atomic context] Andrew Morton
2006-05-25  5:19   ` Benjamin Herrenschmidt
2006-05-25  5:36     ` Andrew Morton
2006-05-25  5:46       ` Benjamin Herrenschmidt
2006-05-25  5:53         ` Benjamin Herrenschmidt
2006-05-25  5:44     ` Benjamin Herrenschmidt [this message]
2006-05-25 14:12   ` Alan Stern
2006-05-25 14:44     ` Andrew Morton
2006-05-25 16:44       ` Jon Loeliger
2006-05-25 17:53         ` [PATCH] Make cpufreq_transition_notifier a raw notifier Alan Stern
2006-05-25 18:41           ` Johannes Berg
2006-05-25 19:14             ` Alan Stern
2006-05-25 23:18           ` Benjamin Herrenschmidt

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=1148535890.13249.250.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=akpm@osdl.org \
    --cc=cpufreq@lists.linux.org.uk \
    --cc=johannes@sipsolutions.net \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=stern@rowland.harvard.edu \
    /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;
as well as URLs for NNTP newsgroup(s).