linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: linuxppc-dev@ozlabs.org, Shaohua Li <shaohua.li@intel.com>,
	linux-pm@vger.kernel.org,
	Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Subject: Re: [PATCH] cpuidle: Default y for pseries
Date: Wed, 11 Jan 2012 18:05:35 +1100	[thread overview]
Message-ID: <1326265535.23910.111.camel@pasglop> (raw)
In-Reply-To: <CA+55aFycfYKFagVgckrEm3dAFHNZEvm0Hkw0UbH+XfKQu8Cvzg@mail.gmail.com>

On Tue, 2012-01-10 at 22:08 -0800, Linus Torvalds wrote:
> On Tue, Jan 10, 2012 at 5:05 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> >
> > Linus, do you want to just pick that up or should I put it into powerpc.git
> > and ask you to pull ? I will have 2 or 3 other fixes there later today,
> > but I wanted to make sure you were ok with the approach with this
> > specific one.
> 
> It doesn't seem to be all that different from the "default y if ACPI"
> case, so I guess it works ok.

It works for my case, that's tested, but ...

> That said, I wonder if the right approach wouldn't be
> 
>    default y if SUPPORT_CPU_IDLE
> 
> or something along those lines. And then both ACPI and PPC_PSERIES
> could just select that instead. Because I do hate having random
> board-level knowledge in something like this. I dunno.

I tend to agree, I wasn't too keen on touching ACPI related stuff I
suppose it shouldn't be hard :-) Btw, what about the change:

-	default ACPI
+	default y if ACPI

(To be honest I'm not sure what the first form does in details).

Oh, also, I just see that in drivers/acpi/Kconfig:

config ACPI_PROCESSOR
	tristate "Processor"
	select THERMAL
	select CPU_IDLE
	default y

Hrm... maybe I should just do the same in pseries and remove both the
"default" statements above, what do you think ?

On pSeries I'm keen to build that in rather than make it a module too
because you get no idle handling until it loads which can be
problematic. Built-in, it seems to be quite early in the link order (if
we can still trust that nowadays ...).

Cheers,
Ben.

  reply	other threads:[~2012-01-11  7:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-11  1:05 [PATCH] cpuidle: Default y for pseries Benjamin Herrenschmidt
2012-01-11  6:08 ` Linus Torvalds
2012-01-11  7:05   ` Benjamin Herrenschmidt [this message]
2012-01-11 22:37 ` Thadeu Lima de Souza Cascardo
2012-01-11 23:06   ` Benjamin Herrenschmidt
2012-01-12 13:05     ` Deepthi Dharwar

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=1326265535.23910.111.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=shaohua.li@intel.com \
    --cc=torvalds@linux-foundation.org \
    --cc=venkatesh.pallipadi@intel.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 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).