[RFC 1/1] omap3: PM: MPU and CORE should stay awake if there is CAM domain ACTIVE

[RFC 1/1] omap3: PM: MPU and CORE should stay awake if there is CAM domain ACTIVE

[Sakari Ailus]

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...

Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
---
 arch/arm/mach-omap2/pm34xx.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index fc69875..4ef682d 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -295,6 +295,9 @@ void omap_sram_idle(void)
 	pwrdm_clear_all_prev_pwrst(core_pwrdm);
 	pwrdm_clear_all_prev_pwrst(per_pwrdm);
 
+	if (pwrdm_read_pwrst(cam_pwrdm) == PWRDM_POWER_ON)
+		clkdm_deny_idle(mpu_pwrdm->pwrdm_clkdms[0]);
+
 	mpu_next_state = pwrdm_read_next_pwrst(mpu_pwrdm);
 	switch (mpu_next_state) {
 	case PWRDM_POWER_ON:
-- 
1.7.2.5

--
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

Re: [RFC 1/1] omap3: PM: MPU and CORE should stay awake if there is CAM domain ACTIVE

[Jean Pihet]

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.

Regards,
Jean

>
> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
> ---
>  arch/arm/mach-omap2/pm34xx.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index fc69875..4ef682d 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -295,6 +295,9 @@ void omap_sram_idle(void)
>        pwrdm_clear_all_prev_pwrst(core_pwrdm);
>        pwrdm_clear_all_prev_pwrst(per_pwrdm);
>
> +       if (pwrdm_read_pwrst(cam_pwrdm) == PWRDM_POWER_ON)
> +               clkdm_deny_idle(mpu_pwrdm->pwrdm_clkdms[0]);
> +
>        mpu_next_state = pwrdm_read_next_pwrst(mpu_pwrdm);
>        switch (mpu_next_state) {
>        case PWRDM_POWER_ON:
> --
> 1.7.2.5
>
> --
> 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
--
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

Re: [RFC 1/1] omap3: PM: MPU and CORE should stay awake if there is CAM domain ACTIVE

[Sakari Ailus]

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.

Kind regards,

-- 
Sakari Ailus
e-mail: sakari.ailus@iki.fi	jabber/XMPP/Gmail: sailus@retiisi.org.uk
--
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

Re: [RFC 1/1] omap3: PM: MPU and CORE should stay awake if there is CAM domain ACTIVE

[Jean Pihet]

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?

Regards,
Jean

>
> Kind regards,
>
> --
> Sakari Ailus
> e-mail: sakari.ailus@iki.fi     jabber/XMPP/Gmail: sailus@retiisi.org.uk
--
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

Re: [RFC 1/1] omap3: PM: MPU and CORE should stay awake if there is CAM domain ACTIVE

[Kevin Hilman]

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

Re: [RFC 1/1] omap3: PM: MPU and CORE should stay awake if there is CAM domain ACTIVE

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1333 bytes --]

On Fri, 27 Jan 2012, Sakari Ailus wrote:

> MPU and CORE should stay awake if there is CAM domain ACTIVE.

I guess this should read that MPU and CORE should stay awake if the ISP IP 
block is 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...

Unfortunately we do not yet have a Linux generic framework for this sort 
of thing yet, and Tony doesn't want to add more platform_data function 
pointers.  So in the interim, would suggest following an 
approach similar to the patch at the bottom of this message:

http://www.spinics.net/lists/linux-omap/msg63495.html

using PM QoS constraints to get what you want.  Make sure you keep the big 
nasty comment in there.  That way, when someone manages to get some 
generic support in for it, we can convert it over easily.

We should probably be marking all of these IP blocks with broken wakeup 
with a hwmod flag also, for warning purposes if nothing else.  "Warning, 
missing IP block wakeup line; energy consumption will be higher than 
necessary; please annoy your silicon vendor"


- Paul

Re: [RFC 1/1] omap3: PM: MPU and CORE should stay awake if there is CAM domain ACTIVE

[Sakari Ailus]

Paul Walmsley wrote:
> On Fri, 27 Jan 2012, Sakari Ailus wrote:
> 
>> MPU and CORE should stay awake if there is CAM domain ACTIVE.
> 
> I guess this should read that MPU and CORE should stay awake if the ISP IP 
> block is 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...
> 
> Unfortunately we do not yet have a Linux generic framework for this sort 
> of thing yet, and Tony doesn't want to add more platform_data function 
> pointers.  So in the interim, would suggest following an 
> approach similar to the patch at the bottom of this message:
> 
> http://www.spinics.net/lists/linux-omap/msg63495.html
> 
> using PM QoS constraints to get what you want.  Make sure you keep the big 
> nasty comment in there.  That way, when someone manages to get some 
> generic support in for it, we can convert it over easily.
> 
> We should probably be marking all of these IP blocks with broken wakeup 
> with a hwmod flag also, for warning purposes if nothing else.  "Warning, 
> missing IP block wakeup line; energy consumption will be higher than 
> necessary; please annoy your silicon vendor"

Thanks Kevin, Paul and Jean!

I think we'll then make a similar change to the ISP driver until the
matter is resolved in a generic way.

Regards,

-- 
Sakari Ailus
sakari.ailus@iki.fi
--
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