All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Dave Jones <davej@redhat.com>
Cc: Marcin Slusarz <marcin.slusarz@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux PM List <linux-pm@lists.linux-foundation.org>,
	cpufreq@vger.kernel.org
Subject: Re: 2.6.31-rc2+: Interrupts enabled after cpufreq_suspend
Date: Sat, 11 Jul 2009 08:23:37 +1000	[thread overview]
Message-ID: <1247264617.21776.6.camel@pasglop> (raw)
In-Reply-To: <20090710192511.GB6240@redhat.com>

On Fri, 2009-07-10 at 15:25 -0400, Dave Jones wrote:

> The answer seems to be in 42d4dc3f4e1ec1396371aac89d0dccfdd977191b
> which introduced all this code to work around some failure that only happens
> on PPC...
> 
>     [PATCH] Add suspend method to cpufreq core
>     
>     In order to properly fix some issues with cpufreq vs. sleep on
>     PowerBooks, I had to add a suspend callback to the pmac_cpufreq driver.
>     I must force a switch to full speed before sleep and I switch back to
>     previous speed on resume.
> 
> 
> Ben, is there something better we can do here ?
> 
> I really don't want to add an #ifdef __powerpc__ to core code if we can help it.
> I'd rather we didn't call into driver guts at all from the suspend path.

Wait a minute ... having a suspend/resume method in cpufreq is one
thing, having it muck around with SMP is another :-) The ppc code
doesn't do that.

There's nothing fundamentally "fail" in requiring a switch to a given
frequency before suspend. I don't know what kind of major FAIL the K8
code is doing here though :-)

I'm happy instead of #ifdef's however to push the logic into the ppc
driver, or use a flag that the ppc driver sets to enable that logic.

Cheers,
Ben.



  parent reply	other threads:[~2009-07-10 22:24 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-09 15:44 2.6.31-rc2+: Interrupts enabled after cpufreq_suspend Marcin Slusarz
2009-07-10 19:25 ` Dave Jones
2009-07-10 20:13   ` Dave Jones
2009-07-10 20:13   ` Dave Jones
2009-07-11 14:33     ` Marcin Slusarz
2009-07-11 14:33     ` Marcin Slusarz
2009-07-10 22:23   ` Benjamin Herrenschmidt [this message]
2009-07-10 23:46     ` Dave Jones
2009-07-16  3:10       ` Benjamin Herrenschmidt
2009-07-16  3:10       ` Benjamin Herrenschmidt
2009-07-10 23:46     ` Dave Jones
2009-07-10 22:23   ` Benjamin Herrenschmidt
2009-07-10 19:25 ` Dave Jones
  -- strict thread matches above, loose matches on Subject: below --
2009-07-09 15:44 Marcin Slusarz

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=1247264617.21776.6.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=cpufreq@vger.kernel.org \
    --cc=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=marcin.slusarz@gmail.com \
    /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.