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@sipsolutions.net,
	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:53:56 +1000	[thread overview]
Message-ID: <1148536437.13249.262.camel@localhost.localdomain> (raw)
In-Reply-To: <1148535984.13249.253.camel@localhost.localdomain>

On Thu, 2006-05-25 at 15:46 +1000, Benjamin Herrenschmidt wrote:
> > This requirement to keep interrupts off in there breaks things again and
> > again and again and again.  And this time: again.
> 
> Where else ?
> 
> If you look at this function it's _designed_ for interrupts off ! the
> driver suspend have the option of deferring their suspend() callback
> until after irqs have been turned off (needed for legacy stuff afaik but
> rarely used) and the sysdev's are very low level things whose suspend
> and resume callbacks should be called after that point as well. 

BTW. The root of the problem with cpufreq is it's upside down design :)
Well, not all of it, but the fact that it registers a sysdev. It's not
the "midlayer" (ugh) business to register devices and hook things like
PM events to pass them down to actual drivers. It should be the cpufreq
drivers themselves that attach to the device model in a way or another
and "instanciate" the ability to control the cpu frequency, passing
along their struct device.

The driver itself should pick the right type of "device" to attach to
(sysdev's are just weird beast and were a bad idea in the first place
since they aren't even struct device).

But then, iirc, that's because we also did the cpu stuff in sysfs upside
down too ... :)

Now, wether the cpufreq notifier might end up calling things that will
sleep or not ... hrm... that's an interesting issue. Part of the problem
is that because cpufreq is a sysdev, it will be called so late in the
suspend process, pretty much everything else is asleep. So I'm quite
confident that things attaching to the cpufreq notifiers other than bits
of cpufreq itself are likely to break anyway. Is it documented anywhere
that registering a cpufreq notifier might cause it to be called in
atomic context or very later in the suspend process (possibly after the
interrupt controller hs been put down) ?

Yes it's messy, no I don't have a miracle solution, but I think here the
proper way to fix it in the long run is for cpufreq not to be a sysdev
or anything like that and to stop trying to do the suspend/resume thing
for the drivers. Drivers are in charge, they get to create the device of
whatever type it is and get the suspend/resume events whenever they are
sent. cpufreq can then provide maybe "helpers" to help work out what to
do at suspend and/or resume time but with the knowledge that for some
drivers maybe, this will happen in atomic context.

Ben.

  reply	other threads:[~2006-05-25  5:54 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 [this message]
2006-05-25  5:44     ` Benjamin Herrenschmidt
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=1148536437.13249.262.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).