From: Tero Kristo <t-kristo@ti.com>
To: Tony Lindgren <tony@atomide.com>
Cc: linux-omap@vger.kernel.org, paul@pwsan.com, khilman@linaro.org,
linux-arm-kernel@lists.infradead.org, Nishanth Menon <nm@ti.com>
Subject: Re: [PATCH 12/18] ARM: OMAP3: PM: remove access to PRM_VOLTCTRL register
Date: Wed, 26 Mar 2014 10:00:31 +0200 [thread overview]
Message-ID: <5332891F.9070002@ti.com> (raw)
In-Reply-To: <20140325223612.GA26395@atomide.com>
On 03/26/2014 12:36 AM, Tony Lindgren wrote:
> * Tero Kristo <t-kristo@ti.com> [140304 08:23]:
>> There is a solitary write to this register every wakeup from off-mode,
>> which isn't doing anything, so remove it.
>
> Argh, this chunk of code is for sure the the thing that's blocking all
> the voltage scaling for idle modes that twl4030 is supposed to do!
>
> AFAIK we must have AUTO_SLEEP, AUTO_RET and AUTO_OFF bits set in
> PRM_VOLTCTRL for twl4030 to scale anything. They must be set if we're
> scaling over I2C4 or using the pins as triggers. Unless these bits
> are set, VC won't send any SLEEP, RET or OFF commands.
>
> Looks like we're not even set these bits anywhere like we should?
>
> I think we should enabled these bits in vc.c init, and never clear?
The bits should be set according to the target sleep mode I believe,
e.g. for retention we should set only AUTO_RET, and for off-mode
AUTO_OFF. You can't have AUTO_OFF enabled if you are going to retention
only as far as I recall, this potentially caused some problems.
-Tero
>
> Nishant and Kevin, any comments?
>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>> arch/arm/mach-omap2/pm34xx.c | 4 ----
>> 1 file changed, 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
>> index 0eecf6f..2fa9478 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -282,10 +282,6 @@ void omap_sram_idle(void)
>> omap3_sram_restore_context();
>> omap2_sms_restore_context();
>> }
>> - if (core_next_state == PWRDM_POWER_OFF)
>> - omap2_prm_clear_mod_reg_bits(OMAP3430_AUTO_OFF_MASK,
>> - OMAP3430_GR_MOD,
>> - OMAP3_PRM_VOLTCTRL_OFFSET);
>> }
>> omap3_intc_resume_idle();
>>
>> --
>> 1.7.9.5
>>
WARNING: multiple messages have this Message-ID (diff)
From: t-kristo@ti.com (Tero Kristo)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 12/18] ARM: OMAP3: PM: remove access to PRM_VOLTCTRL register
Date: Wed, 26 Mar 2014 10:00:31 +0200 [thread overview]
Message-ID: <5332891F.9070002@ti.com> (raw)
In-Reply-To: <20140325223612.GA26395@atomide.com>
On 03/26/2014 12:36 AM, Tony Lindgren wrote:
> * Tero Kristo <t-kristo@ti.com> [140304 08:23]:
>> There is a solitary write to this register every wakeup from off-mode,
>> which isn't doing anything, so remove it.
>
> Argh, this chunk of code is for sure the the thing that's blocking all
> the voltage scaling for idle modes that twl4030 is supposed to do!
>
> AFAIK we must have AUTO_SLEEP, AUTO_RET and AUTO_OFF bits set in
> PRM_VOLTCTRL for twl4030 to scale anything. They must be set if we're
> scaling over I2C4 or using the pins as triggers. Unless these bits
> are set, VC won't send any SLEEP, RET or OFF commands.
>
> Looks like we're not even set these bits anywhere like we should?
>
> I think we should enabled these bits in vc.c init, and never clear?
The bits should be set according to the target sleep mode I believe,
e.g. for retention we should set only AUTO_RET, and for off-mode
AUTO_OFF. You can't have AUTO_OFF enabled if you are going to retention
only as far as I recall, this potentially caused some problems.
-Tero
>
> Nishant and Kevin, any comments?
>
>> Signed-off-by: Tero Kristo <t-kristo@ti.com>
>> ---
>> arch/arm/mach-omap2/pm34xx.c | 4 ----
>> 1 file changed, 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
>> index 0eecf6f..2fa9478 100644
>> --- a/arch/arm/mach-omap2/pm34xx.c
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -282,10 +282,6 @@ void omap_sram_idle(void)
>> omap3_sram_restore_context();
>> omap2_sms_restore_context();
>> }
>> - if (core_next_state == PWRDM_POWER_OFF)
>> - omap2_prm_clear_mod_reg_bits(OMAP3430_AUTO_OFF_MASK,
>> - OMAP3430_GR_MOD,
>> - OMAP3_PRM_VOLTCTRL_OFFSET);
>> }
>> omap3_intc_resume_idle();
>>
>> --
>> 1.7.9.5
>>
next prev parent reply other threads:[~2014-03-26 8:00 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-04 16:19 [PATCH 00/18] ARM: OMAP2+: CM/PRM cleanup set Tero Kristo
2014-03-04 16:19 ` Tero Kristo
2014-03-04 16:19 ` [PATCH 01/18] ARM: OMAP3: CM: remove a few OMAP34XX_CM_REGADDR defines Tero Kristo
2014-03-04 16:19 ` Tero Kristo
2014-03-04 16:19 ` [PATCH 02/18] ARM: OMAP2+: prcm: add omap_test_timeout to prcm-common.h Tero Kristo
2014-03-04 16:19 ` Tero Kristo
2014-03-04 16:19 ` [PATCH 03/18] ARM: OMAP2/3: CM: remove some external dependencies Tero Kristo
2014-03-04 16:19 ` Tero Kristo
2014-03-04 16:19 ` [PATCH 04/18] ARM: OMAP3: PRM: move prcm wakeup helper to prm driver Tero Kristo
2014-03-04 16:19 ` Tero Kristo
2014-03-04 16:19 ` [PATCH 05/18] ARM: OMAP3: PRM: move iva reset to PRM driver Tero Kristo
2014-03-04 16:19 ` Tero Kristo
2014-03-04 16:19 ` [PATCH 06/18] ARM: OMAP3: PRM: move modem " Tero Kristo
2014-03-04 16:19 ` Tero Kristo
2014-03-04 16:19 ` [PATCH 07/18] ARM: OMAP2/3: CM: remove direct register access macros from common header Tero Kristo
2014-03-04 16:19 ` Tero Kristo
2014-03-04 16:19 ` [PATCH 08/18] ARM: OMAP3: PRM: add API for checking and clearing cold reset status Tero Kristo
2014-03-04 16:19 ` Tero Kristo
2014-03-04 16:19 ` [PATCH 09/18] ARM: OMAP3: PRM: add API for saving PRM scratchpad contents Tero Kristo
2014-03-04 16:19 ` Tero Kristo
2014-03-04 16:19 ` [PATCH 10/18] ARM: OMAP24xx: PRM: add API for clearing wakeup status bits Tero Kristo
2014-03-04 16:19 ` Tero Kristo
2014-03-04 16:19 ` [PATCH 11/18] ARM: OMAP24xx: PRM: move PRM init code within PRM driver from PM core Tero Kristo
2014-03-04 16:19 ` Tero Kristo
2014-03-04 16:19 ` [PATCH 12/18] ARM: OMAP3: PM: remove access to PRM_VOLTCTRL register Tero Kristo
2014-03-04 16:19 ` Tero Kristo
2014-03-25 22:36 ` Tony Lindgren
2014-03-25 22:36 ` Tony Lindgren
2014-03-26 8:00 ` Tero Kristo [this message]
2014-03-26 8:00 ` Tero Kristo
2014-03-26 18:40 ` Tony Lindgren
2014-03-26 18:40 ` Tony Lindgren
2014-03-04 16:19 ` [PATCH 13/18] ARM: OMAP3: PRM: move PRM init code from PM core to the driver Tero Kristo
2014-03-04 16:19 ` Tero Kristo
2014-03-04 16:19 ` [PATCH 14/18] ARM: OMAP2/3: PRM: split PRM header file to common and internal versions Tero Kristo
2014-03-04 16:19 ` Tero Kristo
2014-03-04 16:19 ` [PATCH 15/18] ARM: OMAP4+: PRM: make prm register access internal to PRM driver only Tero Kristo
2014-03-04 16:19 ` Tero Kristo
2014-03-04 16:19 ` [PATCH 16/18] ARM: OMAP3: control: add API for setting up the modem pads Tero Kristo
2014-03-04 16:19 ` Tero Kristo
2014-03-04 16:19 ` [PATCH 17/18] ARM: OMAP3: PRM: move modem reset and iva2 idle to PRM driver Tero Kristo
2014-03-04 16:19 ` Tero Kristo
2014-03-04 16:19 ` [PATCH 18/18] ARM: OMAP3: control: isolate control module init to its own function Tero Kristo
2014-03-04 16:19 ` Tero Kristo
2014-03-05 17:36 ` [PATCH 00/18] ARM: OMAP2+: CM/PRM cleanup set Tony Lindgren
2014-03-05 17:36 ` Tony Lindgren
2014-04-12 10:22 ` Tero Kristo
2014-04-12 10:22 ` Tero Kristo
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=5332891F.9070002@ti.com \
--to=t-kristo@ti.com \
--cc=khilman@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=nm@ti.com \
--cc=paul@pwsan.com \
--cc=tony@atomide.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.