Patchwork [05/11] ARM: OMAP2+: hwmod code/data: fix 32K sync timer

login
register
mail settings
Submitter Paul Walmsley
Date June 7, 2012, 6:13 a.m.
Message ID <20120607061309.25532.13430.stgit@dusk>
Download mbox | patch
Permalink /patch/163486/
State New
Headers show

Comments

Paul Walmsley - June 7, 2012, 6:13 a.m.
Kevin discovered that commit c8d82ff68fb6873691536cf33021977efbf5593c
("ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod
database") broke CORE idle on OMAP3.  This prevents device low power
states.

The root cause is that the 32K sync timer IP block does not support
smart-idle mode[1], and so the hwmod code keeps the IP block in
no-idle mode while it is active.  This in turn prevents the WKUP
clockdomain from transitioning to idle.  There is a hardcoded sleep
dependency that prevents the CORE_L3 and CORE_CM clockdomains from
transitioning to idle when the WKUP clockdomain is active[2], so the
chip cannot enter any device low power states.

It turns out that there is no need to take the 32k sync timer out of
idle.  The IP block itself probably does not have any native idle
handling at all, due to its simplicity.  Furthermore, the PRCM will
never request target idle for this IP block while the kernel is
running, due to the sleep dependency that prevents the WKUP
clockdomain from idling while the CORE_L3 clockdomain is active.  So
we can safely leave the 32k sync timer in target-no-idle mode, even
while we continue to access it.

This workaround is implemented by programming the force-idle mode for
any IP block that only supports the force-idle and no-idle modes.  If
an IP block is ever released that doesn't support smart-idle and
requires no-idle mode to be programmed while it's in use, we'll have
to change this behavior.

Another theoretically clean fix for this problem would be to implement
PM runtime-based control for 32k sync timer accesses.  These PM
runtime calls would need to located in a custom clocksource, since the
32k sync timer is currently used as an MMIO clocksource.  But in
practice, there would be little benefit to doing so; and there would
be some cost, due to the addition of unnecessary lines of code and the
additional CPU overhead of the PM runtime and hwmod code - unnecessary
in this case.

Another possible fix would have been to modify the pm34xx.c code to
force the IP block idle before entering WFI.  But this would not have
been an acceptable approach: we are trying to remove this type of
centralized IP block idle control from the PM code.

This patch is effectively a workaround for a hardware problem.  A
better hardware approach would have been to implement a smart-idle
target idle mode for this IP block.  The smart-idle mode in this case
would behave identically to the force-idle mode.  We consider the
force-idle and no-idle target idle mode settings to be intended for
debugging and automatic idle management bug workarounds only[4].

This patch is a collaboration between Kevin Hilman <khilman@ti.com>
and Paul Walmsley <paul@pwsan.com>.

References:

1. Table 16-96 "REG_32KSYNCNT_SYSCONFIG" of the OMAP34xx TRM Rev. ZU
   (SWPU223U), available from:
   http://www.ti.com/pdfs/wtbu/OMAP34x_ES3.1.x_PUBLIC_TRM_vzU.zip

2. Table 4-72 "Sleep Dependencies" of the OMAP34xx TRM Rev. ZU
   (SWPU223U)

3. ibid.

4. Section 3.1.1.1.2 "Module-Level Clock Management" of The
   OMAP4430 TRM Rev. vAA (SWPU231AA).

Cc: Tony Lindgren <tony@atomide.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: BenoƮt Cousson <b-cousson@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/omap_hwmod.c |   32 ++++++++++++++++++++++++++------
 1 file changed, 26 insertions(+), 6 deletions(-)
hvaibhav@ti.com - June 7, 2012, 6:59 a.m.
On Thu, Jun 07, 2012 at 11:43:10, Paul Walmsley wrote:
> Kevin discovered that commit c8d82ff68fb6873691536cf33021977efbf5593c
> ("ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod
> database") broke CORE idle on OMAP3.  This prevents device low power
> states.
> 
> The root cause is that the 32K sync timer IP block does not support
> smart-idle mode[1], and so the hwmod code keeps the IP block in
> no-idle mode while it is active.  This in turn prevents the WKUP
> clockdomain from transitioning to idle.  There is a hardcoded sleep
> dependency that prevents the CORE_L3 and CORE_CM clockdomains from
> transitioning to idle when the WKUP clockdomain is active[2], so the
> chip cannot enter any device low power states.
> 
> It turns out that there is no need to take the 32k sync timer out of
> idle.  The IP block itself probably does not have any native idle
> handling at all, due to its simplicity.  Furthermore, the PRCM will
> never request target idle for this IP block while the kernel is
> running, due to the sleep dependency that prevents the WKUP
> clockdomain from idling while the CORE_L3 clockdomain is active.  So
> we can safely leave the 32k sync timer in target-no-idle mode, even
> while we continue to access it.
> 
> This workaround is implemented by programming the force-idle mode for
> any IP block that only supports the force-idle and no-idle modes.  If
> an IP block is ever released that doesn't support smart-idle and
> requires no-idle mode to be programmed while it's in use, we'll have
> to change this behavior.
> 

Isn't this impact AM33xx devices, where we do not support smart idle mode???
Anyway, I will also test it on both OMAP3EVM and AM33xx platform now...

Thanks,
Vaibhav
Paul Walmsley - June 7, 2012, 7:08 a.m.
Hi

On Thu, 7 Jun 2012, Hiremath, Vaibhav wrote:

> Isn't this impact AM33xx devices, where we do not support smart idle mode???
> Anyway, I will also test it on both OMAP3EVM and AM33xx platform now...

Thanks, please let me know how your tests go.  If it doesn't work, we'll 
go back to the flag-based approach in the patch I posted already.  


- Paul
hvaibhav@ti.com - June 7, 2012, 6:09 p.m.
On Thu, Jun 07, 2012 at 12:38:50, Paul Walmsley wrote:
> Hi
> 
> On Thu, 7 Jun 2012, Hiremath, Vaibhav wrote:
> 
> > Isn't this impact AM33xx devices, where we do not support smart idle mode???
> > Anyway, I will also test it on both OMAP3EVM and AM33xx platform now...
> 
> Thanks, please let me know how your tests go.  If it doesn't work, we'll 
> go back to the flag-based approach in the patch I posted already.  
> 

Paul,

I couldn't finish my testing today, got into continuous meetings.
Tomorrow, I will test it and update you on this.

Thanks,
Vaibhav
Paul Walmsley - June 7, 2012, 8:03 p.m.
Hi

On Thu, 7 Jun 2012, Hiremath, Vaibhav wrote:

> I couldn't finish my testing today, got into continuous meetings.

No worries, I understand.

> Tomorrow, I will test it and update you on this.

That would be great.

I took a look at SPRUH73F and sure enough, at least one module (CONTROL) 
doesn't support smart-idle -- per Table 14-217 "CONTROL Register Field 
Descriptions".  I'd guess that the PRCM won't idle-req this IP block until 
the kernel is not running, so we might be able to get away with the 
existing approach; but the TRM also says:

"By definition, initiator may generate read/write transaction as long as
it is out of IDLE state."

Which pretty much matches my understanding too of the implicit interface 
contract here.

So I think we'd better go back to the flag approach as implemented in this 
patch:

http://www.spinics.net/lists/arm-kernel/msg176836.html

The WBU 32k sync timer's behavior is what relies on quirks of the 
integration that are hard to identify via other means, so it seems to be 
safest to tag it explicitly.


- Paul
Tero Kristo - June 8, 2012, 1:22 p.m.
Hi Paul,

There's a bug in this patch, see below.

<clip>

>  {
> @@ -1141,8 +1143,26 @@ static void _enable_sysc(struct omap_hwmod *oh)
>  	sf = oh->class->sysc->sysc_flags;
>  
>  	if (sf & SYSC_HAS_SIDLEMODE) {
> -		idlemode = (oh->flags & HWMOD_SWSUP_SIDLE) ?
> -			HWMOD_IDLEMODE_NO : HWMOD_IDLEMODE_SMART;
> +		if (oh->flags & HWMOD_SWSUP_SIDLE) {
> +			/*
> +			 * IP blocks without smart idle should be left
> +			 * in force-idle.  Currently this only applies
> +			 * to 32k sync "timer" which is guaranteed to
> +			 * be accessible when the kernel is running.
> +			 * HWMOD_SWSUP_IDLE must also be set on these
> +			 * IP blocks to indicate a hardware problem.
> +			 * XXX Not an ideal workaround.
> +			 */
> +			if (oh->class->sysc->idlemodes &
> +			    (SIDLE_NO | SIDLE_FORCE) &&
> +			    !(oh->class->sysc->idlemodes &
> +			      (SIDLE_SMART || SIDLE_SMART_WKUP)))

There should by binary or, not logical here.

-Tero
hvaibhav@ti.com - June 8, 2012, 7:10 p.m.
On Fri, Jun 08, 2012 at 01:33:46, Paul Walmsley wrote:
> Hi
> 
> On Thu, 7 Jun 2012, Hiremath, Vaibhav wrote:
> 
> > I couldn't finish my testing today, got into continuous meetings.
> 
> No worries, I understand.
> 
> > Tomorrow, I will test it and update you on this.
> 
> That would be great.
> 
> I took a look at SPRUH73F and sure enough, at least one module (CONTROL) 
> doesn't support smart-idle -- per Table 14-217 "CONTROL Register Field 
> Descriptions".  I'd guess that the PRCM won't idle-req this IP block until 
> the kernel is not running, so we might be able to get away with the 
> existing approach; but the TRM also says:
> 
> "By definition, initiator may generate read/write transaction as long as
> it is out of IDLE state."
> 
> Which pretty much matches my understanding too of the implicit interface 
> contract here.
> 
> So I think we'd better go back to the flag approach as implemented in this 
> patch:
> 
> http://www.spinics.net/lists/arm-kernel/msg176836.html
> 
> The WBU 32k sync timer's behavior is what relies on quirks of the 
> integration that are hard to identify via other means, so it seems to be 
> safest to tag it explicitly.
> 

Paul,

I tested it on AM335x platform just now, it booted up to the Linux prompt, 
but I am sure it is going to impact low power state usecases on AM33xx.

So, I also feel that, flag based approach should be used here. 

Thanks,
Vaibhav
Paul Walmsley - June 8, 2012, 11:18 p.m.
On Fri, 8 Jun 2012, Tero Kristo wrote:

> There's a bug in this patch, see below.

...

> There should by binary or, not logical here.

Thanks for reporting this, I've added some credit in the patch 
description.  This has been fixed by switching back to using a flag-based 
approach based on some comments from Vaibhav Hiremath.


- Paul
Cousson, Benoit - June 11, 2012, 9:12 a.m.
On 6/8/2012 9:10 PM, Hiremath, Vaibhav wrote:
> On Fri, Jun 08, 2012 at 01:33:46, Paul Walmsley wrote:
>> Hi
>>
>> On Thu, 7 Jun 2012, Hiremath, Vaibhav wrote:
>>
>>> I couldn't finish my testing today, got into continuous meetings.
>>
>> No worries, I understand.
>>
>>> Tomorrow, I will test it and update you on this.
>>
>> That would be great.
>>
>> I took a look at SPRUH73F and sure enough, at least one module (CONTROL)
>> doesn't support smart-idle -- per Table 14-217 "CONTROL Register Field
>> Descriptions".  I'd guess that the PRCM won't idle-req this IP block until
>> the kernel is not running, so we might be able to get away with the
>> existing approach; but the TRM also says:
>>
>> "By definition, initiator may generate read/write transaction as long as
>> it is out of IDLE state."
>>
>> Which pretty much matches my understanding too of the implicit interface
>> contract here.
>>
>> So I think we'd better go back to the flag approach as implemented in this
>> patch:
>>
>> http://www.spinics.net/lists/arm-kernel/msg176836.html
>>
>> The WBU 32k sync timer's behavior is what relies on quirks of the
>> integration that are hard to identify via other means, so it seems to be
>> safest to tag it explicitly.
>>
>
> Paul,
>
> I tested it on AM335x platform just now, it booted up to the Linux prompt,
> but I am sure it is going to impact low power state usecases on AM33xx.

Why are you sure about that? As explained to Paul, using the force-idle 
will do the same as smart-idle most of the time.

So what power impact are you expecting?

> So, I also feel that, flag based approach should be used here.

Why? Why adding a new flag to detect a condition that is already 
captured somewhere else?

Regards,
Benoit

Patch

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index b0d3064..6b4ae31 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1124,10 +1124,12 @@  static struct omap_hwmod_addr_space * __init _find_mpu_rt_addr_space(struct omap
  * _enable_sysc - try to bring a module out of idle via OCP_SYSCONFIG
  * @oh: struct omap_hwmod *
  *
- * If module is marked as SWSUP_SIDLE, force the module out of slave
- * idle; otherwise, configure it for smart-idle.  If module is marked
- * as SWSUP_MSUSPEND, force the module out of master standby;
- * otherwise, configure it for smart-standby.  No return value.
+ * Ensure that the OCP_SYSCONFIG register for the IP block represented
+ * by @oh is set to indicate to the PRCM that the IP block is active.
+ * Usually this means placing the module into smart-idle mode and
+ * smart-standby, but if there is a bug in the automatic idle handling
+ * for the IP block, it may need to be placed into the force-idle or
+ * no-idle variants of these modes.  No return value.
  */
 static void _enable_sysc(struct omap_hwmod *oh)
 {
@@ -1141,8 +1143,26 @@  static void _enable_sysc(struct omap_hwmod *oh)
 	sf = oh->class->sysc->sysc_flags;
 
 	if (sf & SYSC_HAS_SIDLEMODE) {
-		idlemode = (oh->flags & HWMOD_SWSUP_SIDLE) ?
-			HWMOD_IDLEMODE_NO : HWMOD_IDLEMODE_SMART;
+		if (oh->flags & HWMOD_SWSUP_SIDLE) {
+			/*
+			 * IP blocks without smart idle should be left
+			 * in force-idle.  Currently this only applies
+			 * to 32k sync "timer" which is guaranteed to
+			 * be accessible when the kernel is running.
+			 * HWMOD_SWSUP_IDLE must also be set on these
+			 * IP blocks to indicate a hardware problem.
+			 * XXX Not an ideal workaround.
+			 */
+			if (oh->class->sysc->idlemodes &
+			    (SIDLE_NO | SIDLE_FORCE) &&
+			    !(oh->class->sysc->idlemodes &
+			      (SIDLE_SMART || SIDLE_SMART_WKUP)))
+				idlemode = HWMOD_IDLEMODE_FORCE;
+			else
+				idlemode = HWMOD_IDLEMODE_NO;
+		} else {
+			idlemode = HWMOD_IDLEMODE_SMART;
+		}
 		_set_slave_idlemode(oh, idlemode, &v);
 	}