All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Hilman <khilman@ti.com>
To: Jean Pihet <jean.pihet@newoldbits.com>
Cc: Sakari Ailus <sakari.ailus@iki.fi>,
	Paul Walmsley <paul@pwsan.com>,
	linux-omap@vger.kernel.org, laurent.pinchart@ideasonboard.com
Subject: Re: [RFC 1/1] omap3: PM: MPU and CORE should stay awake if there is CAM domain ACTIVE
Date: Tue, 31 Jan 2012 09:23:36 -0800	[thread overview]
Message-ID: <87r4yfokfb.fsf@ti.com> (raw)
In-Reply-To: <CAORVsuU+Gw5kAh13pgsxCH1B=q5Vs1QBwAfJ520p9AzkTyRjig@mail.gmail.com> (Jean Pihet's message of "Tue, 31 Jan 2012 10:34:09 +0100")

Jean Pihet <jean.pihet@newoldbits.com> writes:

> Hi Kevin, Paul,
>
> On Fri, Jan 27, 2012 at 3:03 PM, Sakari Ailus <sakari.ailus@iki.fi> wrote:
>> Hi Jean,
>>
>> Thanks for you quick reply.
>>
>> On Fri, Jan 27, 2012 at 12:06:37PM +0100, Jean Pihet wrote:
>>> Hi,
>>>
>>> On Fri, Jan 27, 2012 at 11:00 AM, Sakari Ailus <sakari.ailus@iki.fi> wrote:
>>> > MPU and CORE should stay awake if there is CAM domain ACTIVE. This is
>>> > because that module doesn't have wake-up capability.
>>> >
>>> > The original patch was written by Jouni Högander in 2008 and this is the
>>> > last part left of it which is not in upstream yet.
>>> >
>>> > I wonder if the approach taken in the patch is valid these days;
>>> > nevertheless it seems to do the job...
>>> The code in the function omap3_enter_idle_bm from
>>> arch/arm/mach-omap2/cpuidle34xx.c is doing exactly the same thing: it
>>> is choosing the cpuidle safe_state if the CAM power domain is active.
>>>
>>> Please note that this only works if CPU_IDLE is selected, which is
>>> needed to reach any decent low power mode.
>>
>> I didn't have CONFIG_CPU_IDLE selected --- it works if I enable it. But
>> still it should work even if it's disabled I guess.
> What is your call on this?

We made a concious decision a while back to move any idle decision
making out of pm34xx.c and into the CPUidle driver.

Longer term, the goal is that CPUidle should not be handling this
either.  CPUidle is for the CPU, not for the rest of the devices.
Device constrataints should be handled by the device code itself.

Kevin


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2012-01-31 17:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-27 10:00 [RFC 1/1] omap3: PM: MPU and CORE should stay awake if there is CAM domain ACTIVE Sakari Ailus
2012-01-27 11:06 ` Jean Pihet
2012-01-27 14:03   ` Sakari Ailus
2012-01-31  9:34     ` Jean Pihet
2012-01-31 17:23       ` Kevin Hilman [this message]
2012-02-01 22:19 ` Paul Walmsley
2012-02-04 12:11   ` Sakari Ailus

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=87r4yfokfb.fsf@ti.com \
    --to=khilman@ti.com \
    --cc=jean.pihet@newoldbits.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-omap@vger.kernel.org \
    --cc=paul@pwsan.com \
    --cc=sakari.ailus@iki.fi \
    /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.