Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

2012-10-08 Thread Jon Hunter 
Hi Paul,

On 08/01/2012 10:36 AM, Paul Walmsley wrote:
 Hi Jon et al,
 
 Here's what I'm planning to queue here.  The only changes from what Jon
 posted are the patch changelog and some checkpatch fixes.  If anyone
 has any final comments, please let me know.
 
 
 - Paul
 
 From: Paul Walmsley p...@pwsan.com
 Date: Wed, 1 Aug 2012 09:11:20 -0600
 Subject: [PATCH] ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU
  clockdomain idle problems

[snip]

 diff --git a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c 
 b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 index f99e65c..3f4b04b 100644
 --- a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 +++ b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 @@ -248,6 +248,17 @@ static int omap3xxx_clkdm_clk_enable(struct clockdomain 
 *clkdm)
   if (!clkdm-clktrctrl_mask)
   return 0;
  
 + /*
 +  * The CLKDM_MISSING_IDLE_REPORTING flag documentation has
 +  * more details on the unpleasant problem this is working
 +  * around
 +  */
 + if ((clkdm-flags  CLKDM_MISSING_IDLE_REPORTING) 
 + (clkdm-flags  CLKDM_CAN_FORCE_WAKEUP)) {
 + omap3_clkdm_wakeup(clkdm);
 + return 0;
 + }
 +
   hwsup = omap2_cm_is_clkdm_in_hwsup(clkdm-pwrdm.ptr-prcm_offs,
   clkdm-clktrctrl_mask);
  
 @@ -271,6 +282,17 @@ static int omap3xxx_clkdm_clk_disable(struct clockdomain 
 *clkdm)
   if (!clkdm-clktrctrl_mask)
   return 0;
  
 + /*
 +  * The CLKDM_MISSING_IDLE_REPORTING flag documentation has
 +  * more details on the unpleasant problem this is working
 +  * around
 +  */
 + if (clkdm-flags  CLKDM_MISSING_IDLE_REPORTING 
 + !(clkdm-flags  CLKDM_CAN_FORCE_SLEEP)) {
 + _enable_hwsup(clkdm);
 + return 0;
 + }
 +
   hwsup = omap2_cm_is_clkdm_in_hwsup(clkdm-pwrdm.ptr-prcm_offs,
   clkdm-clktrctrl_mask);

I was looking at what got merged and it appears that the above code was
added to the omap2 clkdm enable/disable functions and not omap3. I believe
that is a mistake? If so the below fixes this.

Cheers
Jon

From 16db11f3373bc6e03254c4d1d92ee762f69cbacc Mon Sep 17 00:00:00 2001
From: Jon Hunter jon-hun...@ti.com
Date: Wed, 1 Aug 2012 09:36:13 -0600
Subject: [PATCH] ARM: OMAP3: fix workaround for EMU clockdomain

Commit b71c721 (ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU
clockdomain idle problems) added a workaround for the EMU clock domain on
OMAP3/4 devices to prevent the clock domain for transitioning while it is
in use.

In the proposed patch [1] code was added to the omap3xxx_clkdm_clk_enable()
and omap3xxx_clkdm_clk_disable() functions to check for the flag
CLKDM_MISSING_IDLE_REPORTING and perform the appropriate action. However, in the
merged patch it appears that this code was added to the omap2_clkdm_clk_enable()
and omap2_clkdm_clk_disable() functions by mistake.

[1] http://marc.info/?l=linux-arm-kernelm=134383567112518w=2

Signed-off-by: Jon Hunter jon-hun...@ti.com
---
 arch/arm/mach-omap2/clockdomain2xxx_3xxx.c |   44 ++--
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c 
b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
index 9a7792a..70294f5 100644
--- a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
@@ -183,17 +183,6 @@ static int omap2_clkdm_clk_enable(struct clockdomain 
*clkdm)
if (!clkdm-clktrctrl_mask)
return 0;
 
-   /*
-* The CLKDM_MISSING_IDLE_REPORTING flag documentation has
-* more details on the unpleasant problem this is working
-* around
-*/
-   if (clkdm-flags  CLKDM_MISSING_IDLE_REPORTING 
-   !(clkdm-flags  CLKDM_CAN_FORCE_SLEEP)) {
-   _enable_hwsup(clkdm);
-   return 0;
-   }
-
hwsup = omap2_cm_is_clkdm_in_hwsup(clkdm-pwrdm.ptr-prcm_offs,
clkdm-clktrctrl_mask);
 
@@ -217,17 +206,6 @@ static int omap2_clkdm_clk_disable(struct clockdomain 
*clkdm)
if (!clkdm-clktrctrl_mask)
return 0;
 
-   /*
-* The CLKDM_MISSING_IDLE_REPORTING flag documentation has
-* more details on the unpleasant problem this is working
-* around
-*/
-   if ((clkdm-flags  CLKDM_MISSING_IDLE_REPORTING) 
-   (clkdm-flags  CLKDM_CAN_FORCE_WAKEUP)) {
-   omap3_clkdm_wakeup(clkdm);
-   return 0;
-   }
-
hwsup = omap2_cm_is_clkdm_in_hwsup(clkdm-pwrdm.ptr-prcm_offs,
clkdm-clktrctrl_mask);
 
@@ -269,6 +247,17 @@ static int omap3xxx_clkdm_clk_enable(struct clockdomain 
*clkdm)
if (!clkdm-clktrctrl_mask)
return 0;
 
+   /*
+* The CLKDM_MISSING_IDLE_REPORTING flag documentation has
+* more details on the unpleasant problem this is working
+*

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

2012-10-08 Thread Paul Walmsley 
Hi Jon,

On Mon, 8 Oct 2012, Jon Hunter wrote:

 I was looking at what got merged and it appears that the above code was
 added to the omap2 clkdm enable/disable functions and not omap3. I believe
 that is a mistake? If so the below fixes this.

Yep looks like either a mismerge or a victim of a rebase -- queued for 
late 3.7 fixes -- thanks,

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

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

2012-08-02 Thread Shilimkar, Santosh 
On Wed, Aug 1, 2012 at 9:06 PM, Paul Walmsley p...@pwsan.com wrote:

 Hi Jon et al,

 Here's what I'm planning to queue here.  The only changes from what Jon
 posted are the patch changelog and some checkpatch fixes.  If anyone
 has any final comments, please let me know.


 - Paul

 From: Paul Walmsley p...@pwsan.com
 Date: Wed, 1 Aug 2012 09:11:20 -0600
 Subject: [PATCH] ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU
  clockdomain idle problems

 The idle status of the IP blocks and clocks inside the EMU clockdomain
 isn't taken into account by the PRCM hardware when deciding whether
 the clockdomain is idle.  Add a workaround flag in the clockdomain
 code, CLKDM_MISSING_IDLE_REPORTING, to deal with this problem, and add
 the code necessary to support it.

 If CLKDM_MISSING_IDLE_REPORTING is set on a clockdomain, the
 clockdomain will be forced active whenever an IP block inside that
 clockdomain is in use, even if the clockdomain supports
 hardware-supervised idle.  When the kernel indicates that the last
 active IP block inside the clockdomain is no longer used, the
 clockdomain will be forced idle, or, if that mode is not supported in
 the hardware, it will be placed into hardware-supervised idle.

 This patch is an equal collaboration with Jon Hunter
 jon-hun...@ti.com.  Ming Lei ming@canonical.com, Will Deacon
 will.dea...@arm.com, Madhav Vij m...@ti.com, Kevin Hilman
 khil...@ti.com, Benoît Cousson b-cous...@ti.com, and Santosh
 Shilimkar santosh.shilim...@ti.com all made essential contributions
 to the understanding of EMU clockdomain power management on OMAP.

 Signed-off-by: Paul Walmsley p...@pwsan.com
 Cc: Jon Hunter jon-hun...@ti.com
 Cc: Ming Lei ming@canonical.com
 Cc: Will Deacon will.dea...@arm.com
 Cc: Madhav Vij m...@ti.com
 Cc: Kevin Hilman khil...@ti.com
 Cc: Benoît Cousson b-cous...@ti.com
 Cc: Santosh Shilimkar santosh.shilim...@ti.com
 ---
Acked-by: Santosh Shilimkar santosh.shilim...@ti.com
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

2012-08-01 Thread Paul Walmsley 
Hi Jon,

On Tue, 31 Jul 2012, Jon Hunter wrote:

 Sorry for all the emails. However, I wanted to get this out to you as
 I am due to be out for a couple weeks. 
 
 So I have updated your patch [1] with the following changes ...
 
 1. Re-based on top of your omap3 clock domain fix [2]
 2. Modified the above change I mentioned to check for
CLKDM_MISSING_IDLE_REPORTING in omap_pm_clkdms_setup() instead of
the omap2_clkdm_clk_enable(). This is to prevent the clock domain
being placed in HW_AUTO on boot if enabled early.
 3. Made the other change I mentioned earlier [3].
 
 This is now working well for me on OMAP3/4.

Your changes look good to me.  Do you have a strong preference as to 
whether that patch should go in as part of 3.6-rc or 3.7?  I'd be inclined 
to queue it for 3.7 based on the size of the patch.


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

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

2012-08-01 Thread Paul Walmsley 
Hi Jon et al,

Here's what I'm planning to queue here.  The only changes from what Jon
posted are the patch changelog and some checkpatch fixes.  If anyone
has any final comments, please let me know.


- Paul

From: Paul Walmsley p...@pwsan.com
Date: Wed, 1 Aug 2012 09:11:20 -0600
Subject: [PATCH] ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU
 clockdomain idle problems

The idle status of the IP blocks and clocks inside the EMU clockdomain
isn't taken into account by the PRCM hardware when deciding whether
the clockdomain is idle.  Add a workaround flag in the clockdomain
code, CLKDM_MISSING_IDLE_REPORTING, to deal with this problem, and add
the code necessary to support it.

If CLKDM_MISSING_IDLE_REPORTING is set on a clockdomain, the
clockdomain will be forced active whenever an IP block inside that
clockdomain is in use, even if the clockdomain supports
hardware-supervised idle.  When the kernel indicates that the last
active IP block inside the clockdomain is no longer used, the
clockdomain will be forced idle, or, if that mode is not supported in
the hardware, it will be placed into hardware-supervised idle.

This patch is an equal collaboration with Jon Hunter
jon-hun...@ti.com.  Ming Lei ming@canonical.com, Will Deacon
will.dea...@arm.com, Madhav Vij m...@ti.com, Kevin Hilman
khil...@ti.com, Benoît Cousson b-cous...@ti.com, and Santosh
Shilimkar santosh.shilim...@ti.com all made essential contributions
to the understanding of EMU clockdomain power management on OMAP.

Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Jon Hunter jon-hun...@ti.com
Cc: Ming Lei ming@canonical.com
Cc: Will Deacon will.dea...@arm.com
Cc: Madhav Vij m...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
 arch/arm/mach-omap2/clockdomain.c   |   17 +
 arch/arm/mach-omap2/clockdomain.h   |   20 +---
 arch/arm/mach-omap2/clockdomain2xxx_3xxx.c  |   22 ++
 arch/arm/mach-omap2/clockdomain44xx.c   |   11 +++
 arch/arm/mach-omap2/clockdomains3xxx_data.c |7 ++-
 arch/arm/mach-omap2/clockdomains44xx_data.c |3 ++-
 arch/arm/mach-omap2/omap_hwmod.c|3 ++-
 arch/arm/mach-omap2/pm.c|3 ++-
 8 files changed, 75 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomain.c 
b/arch/arm/mach-omap2/clockdomain.c
index b851ba4..17b1d32 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -914,6 +914,23 @@ bool clkdm_in_hwsup(struct clockdomain *clkdm)
return ret;
 }
 
+/**
+ * clkdm_missing_idle_reporting - can @clkdm enter autoidle even if in use?
+ * @clkdm: struct clockdomain *
+ *
+ * Returns true if clockdomain @clkdm has the
+ * CLKDM_MISSING_IDLE_REPORTING flag set, or false if not or @clkdm is
+ * null.  More information is available in the documentation for the
+ * CLKDM_MISSING_IDLE_REPORTING macro.
+ */
+bool clkdm_missing_idle_reporting(struct clockdomain *clkdm)
+{
+   if (!clkdm)
+   return false;
+
+   return (clkdm-flags  CLKDM_MISSING_IDLE_REPORTING) ? true : false;
+}
+
 /* Clockdomain-to-clock/hwmod framework interface code */
 
 static int _clkdm_clk_hwmod_enable(struct clockdomain *clkdm)
diff --git a/arch/arm/mach-omap2/clockdomain.h 
b/arch/arm/mach-omap2/clockdomain.h
index 7b3c1d2..fb5d37f 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -1,9 +1,7 @@
 /*
- * arch/arm/plat-omap/include/mach/clockdomain.h
- *
  * OMAP2/3 clockdomain framework functions
  *
- * Copyright (C) 2008 Texas Instruments, Inc.
+ * Copyright (C) 2008, 2012 Texas Instruments, Inc.
  * Copyright (C) 2008-2011 Nokia Corporation
  *
  * Paul Walmsley
@@ -34,6 +32,20 @@
  * CLKDM_ACTIVE_WITH_MPU: The PRCM guarantees that this clockdomain is
  * active whenever the MPU is active.  True for interconnects and
  * the WKUP clockdomains.
+ * CLKDM_MISSING_IDLE_REPORTING: The idle status of the IP blocks and
+ * clocks inside this clockdomain are not taken into account by
+ * the PRCM when determining whether the clockdomain is idle.
+ * Without this flag, if the clockdomain is set to
+ * hardware-supervised idle mode, the PRCM may transition the
+ * enclosing powerdomain to a low power state, even when devices
+ * inside the clockdomain and powerdomain are in use.  (An example
+ * of such a clockdomain is the EMU clockdomain on OMAP3/4.)  If
+ * this flag is set, and the clockdomain does not support the
+ * force-sleep mode, then the HW_AUTO mode will be used to put the
+ * clockdomain to sleep.  Similarly, if the clockdomain supports
+ * the force-wakeup mode, then it will be used whenever a clock or
+ * IP block inside the clockdomain is active, rather than the
+ * HW_AUTO mode.
  */
 #define CLKDM_CAN_FORCE_SLEEP  (1  0)
 #define

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

2012-08-01 Thread Jon Hunter 
Hi Paul,

On 08/01/2012 10:08 AM, Paul Walmsley wrote:
 Hi Jon,
 
 On Tue, 31 Jul 2012, Jon Hunter wrote:
 
 Sorry for all the emails. However, I wanted to get this out to you as
 I am due to be out for a couple weeks. 

 So I have updated your patch [1] with the following changes ...

 1. Re-based on top of your omap3 clock domain fix [2]
 2. Modified the above change I mentioned to check for
CLKDM_MISSING_IDLE_REPORTING in omap_pm_clkdms_setup() instead of
the omap2_clkdm_clk_enable(). This is to prevent the clock domain
being placed in HW_AUTO on boot if enabled early.
 3. Made the other change I mentioned earlier [3].

 This is now working well for me on OMAP3/4.
 
 Your changes look good to me.  Do you have a strong preference as to 
 whether that patch should go in as part of 3.6-rc or 3.7?  I'd be inclined 
 to queue it for 3.7 based on the size of the patch.

Thanks for the feedback. 3.7 is fine with me, I don't expect the PMU
changes I have will be in before that.

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

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

2012-08-01 Thread Jon Hunter 
Hi Paul,

On 08/01/2012 10:36 AM, Paul Walmsley wrote:
 Hi Jon et al,
 
 Here's what I'm planning to queue here.  The only changes from what Jon
 posted are the patch changelog and some checkpatch fixes.  If anyone
 has any final comments, please let me know.
 
 
 - Paul
 
 From: Paul Walmsley p...@pwsan.com
 Date: Wed, 1 Aug 2012 09:11:20 -0600
 Subject: [PATCH] ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU
  clockdomain idle problems
 
 The idle status of the IP blocks and clocks inside the EMU clockdomain
 isn't taken into account by the PRCM hardware when deciding whether
 the clockdomain is idle.  Add a workaround flag in the clockdomain
 code, CLKDM_MISSING_IDLE_REPORTING, to deal with this problem, and add
 the code necessary to support it.
 
 If CLKDM_MISSING_IDLE_REPORTING is set on a clockdomain, the
 clockdomain will be forced active whenever an IP block inside that
 clockdomain is in use, even if the clockdomain supports
 hardware-supervised idle.  When the kernel indicates that the last
 active IP block inside the clockdomain is no longer used, the
 clockdomain will be forced idle, or, if that mode is not supported in
 the hardware, it will be placed into hardware-supervised idle.
 
 This patch is an equal collaboration with Jon Hunter
 jon-hun...@ti.com.  Ming Lei ming@canonical.com, Will Deacon
 will.dea...@arm.com, Madhav Vij m...@ti.com, Kevin Hilman
 khil...@ti.com, Benoît Cousson b-cous...@ti.com, and Santosh
 Shilimkar santosh.shilim...@ti.com all made essential contributions
 to the understanding of EMU clockdomain power management on OMAP.
 
 Signed-off-by: Paul Walmsley p...@pwsan.com

Thanks for sending out. You can add my ...

Tested-by: Jon Hunter jon-hun...@ti.com

I have tested this on omap3430 (beagle), omap4430 (blaze) and omap4460
(panda) with perf and my PMU series [1]. I have verified that the EMU
power domain is transitioning correctly on these platforms. For OMAP3430
I checked that CORE retention is still being achieved with this change.

Cheers
Jon

[1] g...@gitorious.org:linux-omap-dev/linux-omap-dev.git -b dev-pmu
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

2012-07-31 Thread Jon Hunter 
Hi Paul,

On 07/30/2012 11:36 PM, Jon Hunter wrote:
 Hi Paul,
 
 On 07/30/2012 06:26 PM, Jon Hunter wrote:
 
 [...]
 
 1. When HWMOD attempts to disable the clock domain for OMAP2/3 devices 
we simply return without doing anything. Not sure if it is safe to 
remove this but I can do some more testing on OMAP2/3. 

 commit a0307bd539ecef976793679a1c4ff0d47b22c4bd
 Author: Jon Hunter jon-hun...@ti.com
 Date:   Mon Jul 30 18:04:06 2012 -0500

 ARM: OMAP2/3: Allow HWMOD to disable clock domains
 
 Currently when HWMOD attempts to disable a clock domain on OMAP2/3 
 devices we
 will return from the function clkdm_hwmod_disable() without actually 
 disabling
 the clock domain. Per the comment this is deliberate because initially 
 HWMOD
 OMAP2/3 devices did not support clock domains. However, clock domains 
 are now
 supported by HWMOD for these devices and so allow HWMOD to disable the 
 clock
 domains.
 
 XXX - Tested on OMAP3430 beagle board, but needs more testing on OMAP2/3

 diff --git a/arch/arm/mach-omap2/clockdomain.c 
 b/arch/arm/mach-omap2/clockdomain.c
 index 011186f..8f7a941 100644
 --- a/arch/arm/mach-omap2/clockdomain.c
 +++ b/arch/arm/mach-omap2/clockdomain.c
 @@ -1075,10 +1075,6 @@ int clkdm_hwmod_enable(struct clockdomain *clkdm, 
 struct omap_hwmod *oh)
   */
  int clkdm_hwmod_disable(struct clockdomain *clkdm, struct omap_hwmod *oh)
  {
 -   /* The clkdm attribute does not exist yet prior OMAP4 */
 -   if (cpu_is_omap24xx() || cpu_is_omap34xx())
 -   return 0;
 -
 /*
  * XXX Rewrite this code to maintain a list of enabled
  * downstream hwmods for debugging purposes?


 2. I need to make the following changes to your patch. The change to
omap2_clkdm_clk_disable() was needed to get the EMU to turn off.
At the same time I thought we should make the same change to
omap2_clkdm_clk_enable().

 diff --git a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c 
 b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 index 09385a9..c94b2fb 100644
 --- a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 +++ b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 @@ -223,7 +223,8 @@ static int omap2_clkdm_clk_enable(struct clockdomain 
 *clkdm)
 _enable_hwsup(clkdm);
 } else {
 if (clkdm-flags  CLKDM_CAN_FORCE_WAKEUP)
 -   omap2_clkdm_wakeup(clkdm);
 +   (cpu_is_omap24xx()) ? omap2_clkdm_wakeup(clkdm) :
 +   omap3_clkdm_wakeup(clkdm);
 }
  
 return 0;
 @@ -257,7 +258,8 @@ static int omap2_clkdm_clk_disable(struct clockdomain 
 *clkdm)
 _enable_hwsup(clkdm);
 } else {
 if (clkdm-flags  CLKDM_CAN_FORCE_SLEEP)
 -   omap2_clkdm_sleep(clkdm);
 +   (cpu_is_omap24xx()) ? omap2_clkdm_sleep(clkdm) :
 +   omap3_clkdm_sleep(clkdm);
 }
 
 I just remembered you sending out a patch [1] to address #2 above. Let
 me know your thoughts about change #1.

So scratch item #1 above. As Rajendra pointed out in another thread this
is not right. The only other comment I have with your patch is maybe we
need to add the following to prevent the EMU PD being idled during
boot-up if enabled early in the boot process. 

diff --git a/arch/arm/mach-omap2/clockdomain.c 
b/arch/arm/mach-omap2/clockdomain.c
index 011186f..84d3fbc 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -825,7 +825,8 @@ void clkdm_allow_idle(struct clockdomain *clkdm)
if (!clkdm)
return;
 
-   if (!(clkdm-flags  CLKDM_CAN_ENABLE_AUTO)) {
+   if (!(clkdm-flags  CLKDM_CAN_ENABLE_AUTO) ||
+   (clkdm-flags  CLKDM_MISSING_IDLE_REPORTING)) {
pr_debug(clock: automatic idle transitions cannot be enabled 
 on clockdomain %s\n, clkdm-name);
return;

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

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

2012-07-31 Thread Jon Hunter 
Hi Paul,

On 07/12/2012 04:17 PM, Paul Walmsley wrote:

[snip]

 @@ -170,6 +201,18 @@ static int omap2_clkdm_clk_enable(struct clockdomain 
 *clkdm)
   if (!clkdm-clktrctrl_mask)
   return 0;
  
 + /*
 +  * The CLKDM_MISSING_IDLE_REPORTING flag documentation has
 +  * more details on the unpleasant problem this is working
 +  * around
 +  */
 + if (clkdm-flags  (CLKDM_MISSING_IDLE_REPORTING |
 + CLKDM_CAN_FORCE_WAKEUP)) {
 + (cpu_is_omap24xx()) ? omap2_clkdm_wakeup(clkdm) :
 + omap3_clkdm_wakeup(clkdm);
 + return 0;
 + }
 +
   hwsup = omap2_cm_is_clkdm_in_hwsup(clkdm-pwrdm.ptr-prcm_offs,
   clkdm-clktrctrl_mask);

I think that the above needs to be ...

diff --git a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c 
b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
index e5bb219..d2b081d 100644
--- a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
@@ -253,8 +253,8 @@ static int omap3xxx_clkdm_clk_enable(struct clockdomain 
*clkdm)
 * more details on the unpleasant problem this is working
 * around
 */
-   if (clkdm-flags  (CLKDM_MISSING_IDLE_REPORTING |
-   CLKDM_CAN_FORCE_WAKEUP)) {
+   if ((clkdm-flags  CLKDM_MISSING_IDLE_REPORTING) 
+   (clkdm-flags  CLKDM_CAN_FORCE_WAKEUP)) {
omap3_clkdm_wakeup(clkdm);
return 0;

... otherwise I see other clkdm such as MPU being put in force-wakeup state 
although they don't have CLKDM_MISSING_IDLE_REPORTING set.

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

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

2012-07-31 Thread Jon Hunter 
Hi Paul,

On 07/31/2012 01:16 PM, Jon Hunter wrote:

[snip]

 So scratch item #1 above. As Rajendra pointed out in another thread this
 is not right. The only other comment I have with your patch is maybe we
 need to add the following to prevent the EMU PD being idled during
 boot-up if enabled early in the boot process. 
 
 diff --git a/arch/arm/mach-omap2/clockdomain.c 
 b/arch/arm/mach-omap2/clockdomain.c
 index 011186f..84d3fbc 100644
 --- a/arch/arm/mach-omap2/clockdomain.c
 +++ b/arch/arm/mach-omap2/clockdomain.c
 @@ -825,7 +825,8 @@ void clkdm_allow_idle(struct clockdomain *clkdm)
 if (!clkdm)
 return;
  
 -   if (!(clkdm-flags  CLKDM_CAN_ENABLE_AUTO)) {
 +   if (!(clkdm-flags  CLKDM_CAN_ENABLE_AUTO) ||
 +   (clkdm-flags  CLKDM_MISSING_IDLE_REPORTING)) {
 pr_debug(clock: automatic idle transitions cannot be enabled 
 
  on clockdomain %s\n, clkdm-name);
 return;

Sorry for all the emails. However, I wanted to get this out to you as
I am due to be out for a couple weeks. 

So I have updated your patch [1] with the following changes ...

1. Re-based on top of your omap3 clock domain fix [2]
2. Modified the above change I mentioned to check for
   CLKDM_MISSING_IDLE_REPORTING in omap_pm_clkdms_setup() instead of
   the omap2_clkdm_clk_enable(). This is to prevent the clock domain
   being placed in HW_AUTO on boot if enabled early.
3. Made the other change I mentioned earlier [3].

This is now working well for me on OMAP3/4.

Let me know your thoughts.

Cheers
Jon

[1] http://marc.info/?l=linux-omapm=134212809112530w=2
[2] http://marc.info/?l=linux-omapm=134333691309305w=2
[3] http://marc.info/?l=linux-arm-kernelm=134376848803220w=2

From c0b0077192239f7c03e39e8292bd74575d74f7d8 Mon Sep 17 00:00:00 2001
From: Paul Walmsley p...@pwsan.com
Date: Thu, 12 Jul 2012 14:58:43 -0600
Subject: [PATCH] ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU
 clockdomain idle problems

The idle status of the IP blocks and clocks inside the EMU clockdomain
isn't taken into account by the PRCM hardware when deciding whether
the clockdomain is idle.  Add a workaround flag, CLKDM_MISSING_IDLE_REPORTING,
to deal with this problem, and add the code necessary to support it.

XXX Add more description of what this flag actually does

XXX Jon, Ming, Will
---
 arch/arm/mach-omap2/clockdomain.c   |   17 +
 arch/arm/mach-omap2/clockdomain.h   |   20 +---
 arch/arm/mach-omap2/clockdomain2xxx_3xxx.c  |   22 ++
 arch/arm/mach-omap2/clockdomain44xx.c   |   11 +++
 arch/arm/mach-omap2/clockdomains3xxx_data.c |7 ++-
 arch/arm/mach-omap2/clockdomains44xx_data.c |3 ++-
 arch/arm/mach-omap2/omap_hwmod.c|3 ++-
 arch/arm/mach-omap2/pm.c|3 ++-
 8 files changed, 75 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomain.c 
b/arch/arm/mach-omap2/clockdomain.c
index 8664f5a..011186f 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -905,6 +905,23 @@ bool clkdm_in_hwsup(struct clockdomain *clkdm)
return ret;
 }
 
+/**
+ * clkdm_missing_idle_reporting - can @clkdm enter autoidle even if in use?
+ * @clkdm: struct clockdomain *
+ *
+ * Returns true if clockdomain @clkdm has the
+ * CLKDM_MISSING_IDLE_REPORTING flag set, or false if not or @clkdm is
+ * null.  More information is available in the documentation for the
+ * CLKDM_MISSING_IDLE_REPORTING macro.
+ */
+bool clkdm_missing_idle_reporting(struct clockdomain *clkdm)
+{
+   if (!clkdm)
+   return false;
+
+   return (clkdm-flags  CLKDM_MISSING_IDLE_REPORTING) ? true : false;
+}
+
 /* Clockdomain-to-clock/hwmod framework interface code */
 
 static int _clkdm_clk_hwmod_enable(struct clockdomain *clkdm)
diff --git a/arch/arm/mach-omap2/clockdomain.h 
b/arch/arm/mach-omap2/clockdomain.h
index 5601dc1..629576b 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -1,9 +1,7 @@
 /*
- * arch/arm/plat-omap/include/mach/clockdomain.h
- *
  * OMAP2/3 clockdomain framework functions
  *
- * Copyright (C) 2008 Texas Instruments, Inc.
+ * Copyright (C) 2008, 2012 Texas Instruments, Inc.
  * Copyright (C) 2008-2011 Nokia Corporation
  *
  * Paul Walmsley
@@ -34,6 +32,20 @@
  * CLKDM_ACTIVE_WITH_MPU: The PRCM guarantees that this clockdomain is
  * active whenever the MPU is active.  True for interconnects and
  * the WKUP clockdomains.
+ * CLKDM_MISSING_IDLE_REPORTING: The idle status of the IP blocks and
+ * clocks inside this clockdomain are not taken into account by
+ * the PRCM when determining whether the clockdomain is idle.
+ * Without this flag, if the clockdomain is set to
+ * hardware-supervised idle mode, the PRCM may transition the
+ * enclosing powerdomain to a low power state, even when devices
+ *

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

2012-07-30 Thread Jon Hunter 
Hi Paul,

On 07/16/2012 01:38 PM, Paul Walmsley wrote:
 Hi Jon,
 
 On Mon, 16 Jul 2012, Jon Hunter wrote:
 
 Yes I see that makes sense. However, patch #7 has already changed the
 mapping of the flags. I had intended that patch #7 and #8 would be
 applied together. However, I could see that patch #7 can be taken just
 to eliminate using the SW_SLEEP state. So basically, what I am saying is
 does patch #7 have any value without #8?
 
 Certainly not as much value as it had before.  But my understanding, which 
 is possibly incorrect, matches what you wrote in patch #7's description:
 
 For OMAP4 devices, SW_SLEEP is equivalent to HW_AUTO and NO_SLEEP is 
 equivalent to SW_WKUP. The only difference between HW_AUTO and SW_SLEEP 
 for OMAP4 devices is that the PRM_IRQSTATUS_MPU.TRANSITION_ST interrupt 
 status is set in case of SW_SLEEP transition, and not set in case of 
 HW_AUTO transition.
 
 We don't use that PRM_IRQSTATUS_MPU.TRANSITION_ST interrupt bit.  So if 
 SW_SLEEP and HW_AUTO really have identical meanings otherwise, then I 
 suppose we might as well use the one that does what we need with no 
 extraneous side-effects?  My recollection from a conversation with Benoît 
 a few months ago was that this was his view as well.
 
 That's fine with me. We can always workaround such issues by adding flags.

 I can give this a try this week and let you know how it goes.
 
 Okay, great.  No rush on my account.

I have been testing your patch [1] on OMAP3 and found that the EMU
clock domain was not being disabled for two reasons. 

1. When HWMOD attempts to disable the clock domain for OMAP2/3 devices 
   we simply return without doing anything. Not sure if it is safe to 
   remove this but I can do some more testing on OMAP2/3. 

commit a0307bd539ecef976793679a1c4ff0d47b22c4bd
Author: Jon Hunter jon-hun...@ti.com
Date:   Mon Jul 30 18:04:06 2012 -0500

ARM: OMAP2/3: Allow HWMOD to disable clock domains

Currently when HWMOD attempts to disable a clock domain on OMAP2/3 devices 
we
will return from the function clkdm_hwmod_disable() without actually 
disabling
the clock domain. Per the comment this is deliberate because initially HWMOD
OMAP2/3 devices did not support clock domains. However, clock domains are 
now
supported by HWMOD for these devices and so allow HWMOD to disable the clock
domains.

XXX - Tested on OMAP3430 beagle board, but needs more testing on OMAP2/3

diff --git a/arch/arm/mach-omap2/clockdomain.c 
b/arch/arm/mach-omap2/clockdomain.c
index 011186f..8f7a941 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -1075,10 +1075,6 @@ int clkdm_hwmod_enable(struct clockdomain *clkdm, struct 
omap_hwmod *oh)
  */
 int clkdm_hwmod_disable(struct clockdomain *clkdm, struct omap_hwmod *oh)
 {
-   /* The clkdm attribute does not exist yet prior OMAP4 */
-   if (cpu_is_omap24xx() || cpu_is_omap34xx())
-   return 0;
-
/*
 * XXX Rewrite this code to maintain a list of enabled
 * downstream hwmods for debugging purposes?


2. I need to make the following changes to your patch. The change to
   omap2_clkdm_clk_disable() was needed to get the EMU to turn off.
   At the same time I thought we should make the same change to
   omap2_clkdm_clk_enable().

diff --git a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c 
b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
index 09385a9..c94b2fb 100644
--- a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
@@ -223,7 +223,8 @@ static int omap2_clkdm_clk_enable(struct clockdomain *clkdm)
_enable_hwsup(clkdm);
} else {
if (clkdm-flags  CLKDM_CAN_FORCE_WAKEUP)
-   omap2_clkdm_wakeup(clkdm);
+   (cpu_is_omap24xx()) ? omap2_clkdm_wakeup(clkdm) :
+   omap3_clkdm_wakeup(clkdm);
}
 
return 0;
@@ -257,7 +258,8 @@ static int omap2_clkdm_clk_disable(struct clockdomain 
*clkdm)
_enable_hwsup(clkdm);
} else {
if (clkdm-flags  CLKDM_CAN_FORCE_SLEEP)
-   omap2_clkdm_sleep(clkdm);
+   (cpu_is_omap24xx()) ? omap2_clkdm_sleep(clkdm) :
+   omap3_clkdm_sleep(clkdm);
}


I need to do more testing but wanted to give you this feedback and
get your comments.

Cheers
Jon

[1] http://marc.info/?l=linux-arm-kernelm=134212814812557w=2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

2012-07-30 Thread Jon Hunter 
Hi Paul,

On 07/30/2012 06:26 PM, Jon Hunter wrote:

[...]

 1. When HWMOD attempts to disable the clock domain for OMAP2/3 devices 
we simply return without doing anything. Not sure if it is safe to 
remove this but I can do some more testing on OMAP2/3. 
 
 commit a0307bd539ecef976793679a1c4ff0d47b22c4bd
 Author: Jon Hunter jon-hun...@ti.com
 Date:   Mon Jul 30 18:04:06 2012 -0500
 
 ARM: OMAP2/3: Allow HWMOD to disable clock domains
 
 Currently when HWMOD attempts to disable a clock domain on OMAP2/3 
 devices we
 will return from the function clkdm_hwmod_disable() without actually 
 disabling
 the clock domain. Per the comment this is deliberate because initially 
 HWMOD
 OMAP2/3 devices did not support clock domains. However, clock domains are 
 now
 supported by HWMOD for these devices and so allow HWMOD to disable the 
 clock
 domains.
 
 XXX - Tested on OMAP3430 beagle board, but needs more testing on OMAP2/3
 
 diff --git a/arch/arm/mach-omap2/clockdomain.c 
 b/arch/arm/mach-omap2/clockdomain.c
 index 011186f..8f7a941 100644
 --- a/arch/arm/mach-omap2/clockdomain.c
 +++ b/arch/arm/mach-omap2/clockdomain.c
 @@ -1075,10 +1075,6 @@ int clkdm_hwmod_enable(struct clockdomain *clkdm, 
 struct omap_hwmod *oh)
   */
  int clkdm_hwmod_disable(struct clockdomain *clkdm, struct omap_hwmod *oh)
  {
 -   /* The clkdm attribute does not exist yet prior OMAP4 */
 -   if (cpu_is_omap24xx() || cpu_is_omap34xx())
 -   return 0;
 -
 /*
  * XXX Rewrite this code to maintain a list of enabled
  * downstream hwmods for debugging purposes?
 
 
 2. I need to make the following changes to your patch. The change to
omap2_clkdm_clk_disable() was needed to get the EMU to turn off.
At the same time I thought we should make the same change to
omap2_clkdm_clk_enable().
 
 diff --git a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c 
 b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 index 09385a9..c94b2fb 100644
 --- a/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 +++ b/arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
 @@ -223,7 +223,8 @@ static int omap2_clkdm_clk_enable(struct clockdomain 
 *clkdm)
 _enable_hwsup(clkdm);
 } else {
 if (clkdm-flags  CLKDM_CAN_FORCE_WAKEUP)
 -   omap2_clkdm_wakeup(clkdm);
 +   (cpu_is_omap24xx()) ? omap2_clkdm_wakeup(clkdm) :
 +   omap3_clkdm_wakeup(clkdm);
 }
  
 return 0;
 @@ -257,7 +258,8 @@ static int omap2_clkdm_clk_disable(struct clockdomain 
 *clkdm)
 _enable_hwsup(clkdm);
 } else {
 if (clkdm-flags  CLKDM_CAN_FORCE_SLEEP)
 -   omap2_clkdm_sleep(clkdm);
 +   (cpu_is_omap24xx()) ? omap2_clkdm_sleep(clkdm) :
 +   omap3_clkdm_sleep(clkdm);
 }

I just remembered you sending out a patch [1] to address #2 above. Let
me know your thoughts about change #1.

Cheers
Jon

[1] http://marc.info/?l=linux-omapm=134333691309305w=2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

2012-07-20 Thread Jon Hunter 
Hi Paul,

On 07/16/2012 01:38 PM, Paul Walmsley wrote:
 Hi Jon,
 
 On Mon, 16 Jul 2012, Jon Hunter wrote:
 
 Yes I see that makes sense. However, patch #7 has already changed the
 mapping of the flags. I had intended that patch #7 and #8 would be
 applied together. However, I could see that patch #7 can be taken just
 to eliminate using the SW_SLEEP state. So basically, what I am saying is
 does patch #7 have any value without #8?
 
 Certainly not as much value as it had before.  But my understanding, which 
 is possibly incorrect, matches what you wrote in patch #7's description:
 
 For OMAP4 devices, SW_SLEEP is equivalent to HW_AUTO and NO_SLEEP is 
 equivalent to SW_WKUP. The only difference between HW_AUTO and SW_SLEEP 
 for OMAP4 devices is that the PRM_IRQSTATUS_MPU.TRANSITION_ST interrupt 
 status is set in case of SW_SLEEP transition, and not set in case of 
 HW_AUTO transition.
 
 We don't use that PRM_IRQSTATUS_MPU.TRANSITION_ST interrupt bit.  So if 
 SW_SLEEP and HW_AUTO really have identical meanings otherwise, then I 
 suppose we might as well use the one that does what we need with no 
 extraneous side-effects?  My recollection from a conversation with Benoît 
 a few months ago was that this was his view as well.
 
 That's fine with me. We can always workaround such issues by adding flags.

 I can give this a try this week and let you know how it goes.
 
 Okay, great.  No rush on my account.

I have been testing this today and is working well for OMAP4. However, I
noticed that this is not working for OMAP3. The problem for OMAP3 is
that we don't have hwmod support for the debugss in OMAP3 and so the
flag CLKDM_CAN_ENABLE_AUTO is shutting down the EMU PD on boot. To be
honest it is clear to me now that PMU support on OMAP3 needs some work
as it is dependent on the ETM driver as highlighted by Will.

So I think that this patch will work but I need to create a hwmod for
OMAP3's debugss. Are you able to generate this or just Benoit? I could
probably create something by hand but did not know if we could
auto-generate.

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

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

2012-07-20 Thread Jon Hunter 
Hi Will,

On 07/13/2012 09:00 AM, Will Deacon wrote:
 Jon,
 
 [cutting out realms of context!]
 
 On Fri, Jul 13, 2012 at 02:54:59PM +0100, Jon Hunter wrote:
 Another proposal I also thought of is re-working the flags to describe
 the HW mode to be used when turning on the CLKDM, when the CLKDM is
 active and when the CLKDM is shut down. So instead of saying what modes
 the CLKDM supports, specify what modes should be used for pre-ON (i.e.
 turn ON), ON and OFF. Right now software is trying to decide for us by
 what is available (which is ideal) but makes working around such nuances
 a little more painful.

 By the way, I did do some testing on OMAP3, but I don't recall now
 whether I was having such problems with OMAP3. I need to go back and
 test perf again on OMAP3 to see if such a flag is needed.
 
 If you do test on OMAP3, please kill the OMAP3_EMU option as I think this
 has the effect of keeping the EMU power domain up via the etm code (look at
 etb_probe).

You are right. Removing that options breaks PMU on OMAP3. I need to add
hwmod support for the debugss on OMAP3.

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

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

2012-07-16 Thread Jon Hunter 
Hi Paul,

On 07/13/2012 04:00 PM, Paul Walmsley wrote:

[...]

 Unfortunately, although this works it does make the flags a bit less 
 clearer. The upside is the solution is simpler.
 
 Yeah, the problem is the clockdomain CLKDM_CAN_* flags are just intended 
 to represent the available bits from the register bitfield, rather than a 
 higher-level concept.  Among other things, it allows the maintainers and 
 users of this code to verify it by comparing it to the TRM.  Changing the 
 CLKDM_CAN_* flags in the kernel is not actually that simple since it 
 involves overriding the hardware data for the EMU clockdomain for every 
 applicable chip.  In other words, it just moves the complexity 
 elsewhere.

Yes I see that makes sense. However, patch #7 has already changed the
mapping of the flags. I had intended that patch #7 and #8 would be
applied together. However, I could see that patch #7 can be taken just
to eliminate using the SW_SLEEP state. So basically, what I am saying is
does patch #7 have any value without #8?

 I am not sure if it is really a matter of the clock domain missing the
 idle reporting, but more of a problem that the EMU power domain power
 state is programmed in HW to OFF and cannot be changed by software. (see
 POWER_STATE field of PM_EMU_PWRSTCTRL register description in the TRM).

 This means that when the EMU clock domain does idle, the EMU power
 domain can transition to OFF and hence we loss the EMU logic context. So
 we need to keep the EMU CLKDM on to keep the EMU PWRDM on, but it is
 really the lack of control we have over the PWRDM that is the problem. I
 would not say this is a HW bug but more of a design choice probably to
 keep the design simpler at the expense of power.
 
 I really wonder how much more difficult it would have been to add the 
 ON state to the EMU powerdomain next-power-state control bitfields...

True, probably a good area for us to provide some feedback to the
designers.

 I believe that this problem would happen to all power domains if they
 were programmed for the OFF power state when the clock domain idled. For
 other power domains we avoid this by programming them to the ON state
 when we are using them.
 
 Hmm.  In the case of most other clockdomains, we have some way to indicate 
 to the PRCM whether the IP block/clock is in use or not: functional clock 
 control bits or modulemode control bits or CLKACTIVITY bits or (in the 
 worst case) SIDLEMODE bits.  We don't really have any of these control 
 mechanisms for most of the EMU clockdomain IP blocks/clocks.
 
 From a theoretical perspective, assigning the problem solely to the 
 powerdomain next-power-state bits might also ignore the impact on 
 clockdomain dependencies.  These take effect based on the clockdomain 
 activity state, rather than powerdomain next-power-states.  Although, for 
 the specific case of the EMU clockdomains on OMAP3/4, it looks like this 
 is not a practical problem according to the TRM.

Ok, yes I understand your point of view.

 Thanks for the detailed suggestion! Adding a flag to prevent programming
 the HW_AUTO while the CLKDM is active could definitely work (although I
 may change the name/description of the flag a little).
 
 Sure, let me know what you think of the above reasoning.

I would say it is fair (with limited knowledge of the h/w design
decisions made here).

 Another proposal I also thought of is re-working the flags to describe
 the HW mode to be used when turning on the CLKDM, when the CLKDM is
 active and when the CLKDM is shut down. So instead of saying what modes
 the CLKDM supports, specify what modes should be used for pre-ON (i.e.
 turn ON), ON and OFF. Right now software is trying to decide for us by
 what is available (which is ideal) but makes working around such nuances
 a little more painful.
 
 With the hardware data, it would be good to keep it something that can be 
 generated with as little human intervention as possible, except in the 
 case of bug workarounds or departures from standard practice.  The idea is 
 to reduce the amount of human interaction needed to generate data to 
 support new chips, when everything works as it should.  It also allows us 
 software forks to explicitly mark unusual quirks or bugs that we'd like 
 the hardware people to change for future revisions :-)

That's fine with me. We can always workaround such issues by adding flags.

I can give this a try this week and let you know how it goes.

I think that Benoit is out until the end of the month. I am not sure if
he will have any inputs.

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

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

2012-07-16 Thread Paul Walmsley 
Hi Jon,

On Mon, 16 Jul 2012, Jon Hunter wrote:

 Yes I see that makes sense. However, patch #7 has already changed the
 mapping of the flags. I had intended that patch #7 and #8 would be
 applied together. However, I could see that patch #7 can be taken just
 to eliminate using the SW_SLEEP state. So basically, what I am saying is
 does patch #7 have any value without #8?

Certainly not as much value as it had before.  But my understanding, which 
is possibly incorrect, matches what you wrote in patch #7's description:

For OMAP4 devices, SW_SLEEP is equivalent to HW_AUTO and NO_SLEEP is 
equivalent to SW_WKUP. The only difference between HW_AUTO and SW_SLEEP 
for OMAP4 devices is that the PRM_IRQSTATUS_MPU.TRANSITION_ST interrupt 
status is set in case of SW_SLEEP transition, and not set in case of 
HW_AUTO transition.

We don't use that PRM_IRQSTATUS_MPU.TRANSITION_ST interrupt bit.  So if 
SW_SLEEP and HW_AUTO really have identical meanings otherwise, then I 
suppose we might as well use the one that does what we need with no 
extraneous side-effects?  My recollection from a conversation with Benoît 
a few months ago was that this was his view as well.

 That's fine with me. We can always workaround such issues by adding flags.
 
 I can give this a try this week and let you know how it goes.

Okay, great.  No rush on my account.


- Paul

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

2012-07-16 Thread Jon Hunter 
Hi Paul,

On 07/16/2012 01:38 PM, Paul Walmsley wrote:
 Hi Jon,
 
 On Mon, 16 Jul 2012, Jon Hunter wrote:
 
 Yes I see that makes sense. However, patch #7 has already changed the
 mapping of the flags. I had intended that patch #7 and #8 would be
 applied together. However, I could see that patch #7 can be taken just
 to eliminate using the SW_SLEEP state. So basically, what I am saying is
 does patch #7 have any value without #8?
 
 Certainly not as much value as it had before.  But my understanding, which 
 is possibly incorrect, matches what you wrote in patch #7's description:
 
 For OMAP4 devices, SW_SLEEP is equivalent to HW_AUTO and NO_SLEEP is 
 equivalent to SW_WKUP. The only difference between HW_AUTO and SW_SLEEP 
 for OMAP4 devices is that the PRM_IRQSTATUS_MPU.TRANSITION_ST interrupt 
 status is set in case of SW_SLEEP transition, and not set in case of 
 HW_AUTO transition.
 
 We don't use that PRM_IRQSTATUS_MPU.TRANSITION_ST interrupt bit.  So if 
 SW_SLEEP and HW_AUTO really have identical meanings otherwise, then I 
 suppose we might as well use the one that does what we need with no 
 extraneous side-effects?  My recollection from a conversation with Benoît 
 a few months ago was that this was his view as well.

Yes that is my understanding too. So from that standpoint it is fine to
keep. However, I just wanted to make sure I understood your thinking here.

 That's fine with me. We can always workaround such issues by adding flags.

 I can give this a try this week and let you know how it goes.
 
 Okay, great.  No rush on my account.

Ok. I have a few items on my plate that keep preventing me from getting
back to this, but what to get this done.

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

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

2012-07-13 Thread Jon Hunter 
Hi Paul,

On 07/12/2012 04:17 PM, Paul Walmsley wrote:
 Hello Jon
 
 On Thu, 7 Jun 2012, Jon Hunter wrote:
 
 By removing the CLKDM_CAN_ENABLE_AUTO flag, the EMU clock domain will always
 remain on and hence, this will break low-power modes. The EMU clock domain 
 only
 support the SW_WKUP and HW_AUTO transition modes (for more details refer to 
 the
 OMAP4430 TRM) and power down the EMU power domain we need to place the EMU
 clock domain back into the HW_AUTO mode. This can be accomplished by setting
 the CLKDM_CAN_FORCE_SLEEP flag, which for an OMAP4 device will enable the
 HW_AUTO mode.
 
 Hmm, it would be nice if we could keep the CLKDM_CAN_* flags matching the 
 hardware capabilities.  Looking at the 4430 TRM Rev X Table 3-744 
 CM_EMU_CLKSTCTRL, the CLKTRCTRL field isn't documented as supporting the 
 SW_SLEEP mode (which CLKDM_CAN_FORCE_SLEEP will set).

Right, however, this was part of the recommendation from Benoit. In
patch #7 of this series we actually made the following modification ...

By eliminating the SW_SLEEP mode the the mapping of the flags for OMAP4
devices can becomes ...

CLKDM_CAN_DISABLE_AUTO  -- NO_SLEEP
CLKDM_CAN_ENABLE_AUTO   -- HW_AUTO
CLKDM_CAN_FORCE_SLEEP   -- HW_AUTO
CLKDM_CAN_FORCE_WAKEUP  -- SW_WKUP

So now, by setting CLKDM_CAN_FORCE_SLEEP we are actually enabling
HW_AUTO and not SW_SLEEP (for OMAP4). This was the purpose of patch #7
was to remove the SW_SLEEP for OMAP4 as it is equivalent to HW_AUTO when
using it to disable the module. Unfortunately, although this works it
does make the flags a bit less clearer. The upside is the solution is
simpler.

 Maybe the CLKDM_CAN_* flags should be moved to a separate u8...
 
 Anyway, what do you think about the following approach?  It uses a 
 special flag to indicate that the EMU clockdomain is behaving in an 
 unexpected way.  If you think it's reasonable, perhaps you could try your 
 PMU tests with it?  It applies on top of linux-omap master 
 (cb07e3394573a419147a1783f3bd7ef13045353c) plus the clockdomain patch 
 posted earlier at:
 
 http://marc.info/?l=linux-omapm=134209072829531w=2
 
 But these patches may need to be applied on Kevin's 'pm' branch for 
 meaningful PM testing:
 
 http://marc.info/?l=linux-omapm=134196493819792w=2
 
 
 
 - Paul
 
 From: Paul Walmsley p...@pwsan.com
 Date: Thu, 12 Jul 2012 14:58:43 -0600
 Subject: [PATCH] ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU
  clockdomain idle problems
 
 The idle status of the IP blocks and clocks inside the EMU clockdomain
 isn't taken into account by the PRCM hardware when deciding whether
 the clockdomain is idle.  Add a workaround flag, CLKDM_MISSING_IDLE_REPORTING,
 to deal with this problem, and add the code necessary to support it.
 
 XXX Add more description of what this flag actually does
 
 XXX Jon, Ming, Will
 ---
  arch/arm/mach-omap2/clockdomain.c   |   17 ++
  arch/arm/mach-omap2/clockdomain.h   |   20 ++-
  arch/arm/mach-omap2/clockdomain2xxx_3xxx.c  |   86 
 +--
  arch/arm/mach-omap2/clockdomain44xx.c   |   11 
  arch/arm/mach-omap2/clockdomains3xxx_data.c |7 +--
  arch/arm/mach-omap2/clockdomains44xx_data.c |3 +-
  arch/arm/mach-omap2/omap_hwmod.c|3 +-
  7 files changed, 105 insertions(+), 42 deletions(-)
 
 diff --git a/arch/arm/mach-omap2/clockdomain.c 
 b/arch/arm/mach-omap2/clockdomain.c
 index b851ba4..17b1d32 100644
 --- a/arch/arm/mach-omap2/clockdomain.c
 +++ b/arch/arm/mach-omap2/clockdomain.c
 @@ -914,6 +914,23 @@ bool clkdm_in_hwsup(struct clockdomain *clkdm)
   return ret;
  }
  
 +/**
 + * clkdm_missing_idle_reporting - can @clkdm enter autoidle even if in use?
 + * @clkdm: struct clockdomain *
 + *
 + * Returns true if clockdomain @clkdm has the
 + * CLKDM_MISSING_IDLE_REPORTING flag set, or false if not or @clkdm is
 + * null.  More information is available in the documentation for the
 + * CLKDM_MISSING_IDLE_REPORTING macro.
 + */
 +bool clkdm_missing_idle_reporting(struct clockdomain *clkdm)
 +{
 + if (!clkdm)
 + return false;
 +
 + return (clkdm-flags  CLKDM_MISSING_IDLE_REPORTING) ? true : false;
 +}
 +
  /* Clockdomain-to-clock/hwmod framework interface code */
  
  static int _clkdm_clk_hwmod_enable(struct clockdomain *clkdm)
 diff --git a/arch/arm/mach-omap2/clockdomain.h 
 b/arch/arm/mach-omap2/clockdomain.h
 index 7b3c1d2..fb5d37f 100644
 --- a/arch/arm/mach-omap2/clockdomain.h
 +++ b/arch/arm/mach-omap2/clockdomain.h
 @@ -1,9 +1,7 @@
  /*
 - * arch/arm/plat-omap/include/mach/clockdomain.h
 - *
   * OMAP2/3 clockdomain framework functions
   *
 - * Copyright (C) 2008 Texas Instruments, Inc.
 + * Copyright (C) 2008, 2012 Texas Instruments, Inc.
   * Copyright (C) 2008-2011 Nokia Corporation
   *
   * Paul Walmsley
 @@ -34,6 +32,20 @@
   * CLKDM_ACTIVE_WITH_MPU: The PRCM guarantees that this clockdomain is
   * active whenever the MPU is active.  True for interconnects and
   * the WKUP clockdomains.
 + *

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

2012-07-13 Thread Will Deacon 
Jon,

[cutting out realms of context!]

On Fri, Jul 13, 2012 at 02:54:59PM +0100, Jon Hunter wrote:
 Another proposal I also thought of is re-working the flags to describe
 the HW mode to be used when turning on the CLKDM, when the CLKDM is
 active and when the CLKDM is shut down. So instead of saying what modes
 the CLKDM supports, specify what modes should be used for pre-ON (i.e.
 turn ON), ON and OFF. Right now software is trying to decide for us by
 what is available (which is ideal) but makes working around such nuances
 a little more painful.
 
 By the way, I did do some testing on OMAP3, but I don't recall now
 whether I was having such problems with OMAP3. I need to go back and
 test perf again on OMAP3 to see if such a flag is needed.

If you do test on OMAP3, please kill the OMAP3_EMU option as I think this
has the effect of keeping the EMU power domain up via the etm code (look at
etb_probe).

Will

---8---

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a91009c..d02054c 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1139,8 +1139,7 @@ config XSCALE_PMU
default y
 
 config CPU_HAS_PMU
-   depends on (CPU_V6 || CPU_V6K || CPU_V7 || XSCALE_PMU)  \
-  (!ARCH_OMAP3 || OMAP3_EMU)
+   depends on (CPU_V6 || CPU_V6K || CPU_V7 || XSCALE_PMU)
default y
bool
 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

2012-07-13 Thread Jon Hunter 
Hi Will,

On 07/13/2012 09:00 AM, Will Deacon wrote:
 Jon,
 
 [cutting out realms of context!]

Thanks! My inbox thanks you too ;-)

 On Fri, Jul 13, 2012 at 02:54:59PM +0100, Jon Hunter wrote:
 Another proposal I also thought of is re-working the flags to describe
 the HW mode to be used when turning on the CLKDM, when the CLKDM is
 active and when the CLKDM is shut down. So instead of saying what modes
 the CLKDM supports, specify what modes should be used for pre-ON (i.e.
 turn ON), ON and OFF. Right now software is trying to decide for us by
 what is available (which is ideal) but makes working around such nuances
 a little more painful.

 By the way, I did do some testing on OMAP3, but I don't recall now
 whether I was having such problems with OMAP3. I need to go back and
 test perf again on OMAP3 to see if such a flag is needed.
 
 If you do test on OMAP3, please kill the OMAP3_EMU option as I think this
 has the effect of keeping the EMU power domain up via the etm code (look at
 etb_probe).
 
 Will
 
 ---8---
 
 diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
 index a91009c..d02054c 100644
 --- a/arch/arm/Kconfig
 +++ b/arch/arm/Kconfig
 @@ -1139,8 +1139,7 @@ config XSCALE_PMU
 default y
  
  config CPU_HAS_PMU
 -   depends on (CPU_V6 || CPU_V6K || CPU_V7 || XSCALE_PMU)  \
 -  (!ARCH_OMAP3 || OMAP3_EMU)
 +   depends on (CPU_V6 || CPU_V6K || CPU_V7 || XSCALE_PMU)
 default y
 bool

Ah-ha! May be this is why is worked without issue. I will look at that
and check the power states. I must admit that my testing was quick to
ensure no breakages but no thorough to check what was going on with power.

Cheers
Jon



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

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

2012-07-13 Thread Paul Walmsley 
Hi Jon

On Fri, 13 Jul 2012, Jon Hunter wrote:

 On 07/12/2012 04:17 PM, Paul Walmsley wrote:
  On Thu, 7 Jun 2012, Jon Hunter wrote:
  
  Hmm, it would be nice if we could keep the CLKDM_CAN_* flags matching the 
  hardware capabilities.  Looking at the 4430 TRM Rev X Table 3-744 
  CM_EMU_CLKSTCTRL, the CLKTRCTRL field isn't documented as supporting the 
  SW_SLEEP mode (which CLKDM_CAN_FORCE_SLEEP will set).
 
 Right, however, this was part of the recommendation from Benoit. In
 patch #7 of this series we actually made the following modification ...

[ ... ]

 So now, by setting CLKDM_CAN_FORCE_SLEEP we are actually enabling
 HW_AUTO and not SW_SLEEP (for OMAP4). This was the purpose of patch #7
 was to remove the SW_SLEEP for OMAP4 as it is equivalent to HW_AUTO when
 using it to disable the module. 

OK, that's right.

 Unfortunately, although this works it does make the flags a bit less 
 clearer. The upside is the solution is simpler.

Yeah, the problem is the clockdomain CLKDM_CAN_* flags are just intended 
to represent the available bits from the register bitfield, rather than a 
higher-level concept.  Among other things, it allows the maintainers and 
users of this code to verify it by comparing it to the TRM.  Changing the 
CLKDM_CAN_* flags in the kernel is not actually that simple since it 
involves overriding the hardware data for the EMU clockdomain for every 
applicable chip.  In other words, it just moves the complexity 
elsewhere.

 I am not sure if it is really a matter of the clock domain missing the
 idle reporting, but more of a problem that the EMU power domain power
 state is programmed in HW to OFF and cannot be changed by software. (see
 POWER_STATE field of PM_EMU_PWRSTCTRL register description in the TRM).
 
 This means that when the EMU clock domain does idle, the EMU power
 domain can transition to OFF and hence we loss the EMU logic context. So
 we need to keep the EMU CLKDM on to keep the EMU PWRDM on, but it is
 really the lack of control we have over the PWRDM that is the problem. I
 would not say this is a HW bug but more of a design choice probably to
 keep the design simpler at the expense of power.

I really wonder how much more difficult it would have been to add the 
ON state to the EMU powerdomain next-power-state control bitfields...

 I believe that this problem would happen to all power domains if they
 were programmed for the OFF power state when the clock domain idled. For
 other power domains we avoid this by programming them to the ON state
 when we are using them.

Hmm.  In the case of most other clockdomains, we have some way to indicate 
to the PRCM whether the IP block/clock is in use or not: functional clock 
control bits or modulemode control bits or CLKACTIVITY bits or (in the 
worst case) SIDLEMODE bits.  We don't really have any of these control 
mechanisms for most of the EMU clockdomain IP blocks/clocks.

From a theoretical perspective, assigning the problem solely to the 
powerdomain next-power-state bits might also ignore the impact on 
clockdomain dependencies.  These take effect based on the clockdomain 
activity state, rather than powerdomain next-power-states.  Although, for 
the specific case of the EMU clockdomains on OMAP3/4, it looks like this 
is not a practical problem according to the TRM.

 Thanks for the detailed suggestion! Adding a flag to prevent programming
 the HW_AUTO while the CLKDM is active could definitely work (although I
 may change the name/description of the flag a little).

Sure, let me know what you think of the above reasoning.

 Another proposal I also thought of is re-working the flags to describe
 the HW mode to be used when turning on the CLKDM, when the CLKDM is
 active and when the CLKDM is shut down. So instead of saying what modes
 the CLKDM supports, specify what modes should be used for pre-ON (i.e.
 turn ON), ON and OFF. Right now software is trying to decide for us by
 what is available (which is ideal) but makes working around such nuances
 a little more painful.

With the hardware data, it would be good to keep it something that can be 
generated with as little human intervention as possible, except in the 
case of bug workarounds or departures from standard practice.  The idea is 
to reduce the amount of human interaction needed to generate data to 
support new chips, when everything works as it should.  It also allows us 
software forks to explicitly mark unusual quirks or bugs that we'd like 
the hardware people to change for future revisions :-)


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

Re: [PATCH V2 08/10] ARM: OMAP4: Prevent EMU power domain transitioning to OFF when in-use

2012-07-12 Thread Paul Walmsley 
Hello Jon

On Thu, 7 Jun 2012, Jon Hunter wrote:

 By removing the CLKDM_CAN_ENABLE_AUTO flag, the EMU clock domain will always
 remain on and hence, this will break low-power modes. The EMU clock domain 
 only
 support the SW_WKUP and HW_AUTO transition modes (for more details refer to 
 the
 OMAP4430 TRM) and power down the EMU power domain we need to place the EMU
 clock domain back into the HW_AUTO mode. This can be accomplished by setting
 the CLKDM_CAN_FORCE_SLEEP flag, which for an OMAP4 device will enable the
 HW_AUTO mode.

Hmm, it would be nice if we could keep the CLKDM_CAN_* flags matching the 
hardware capabilities.  Looking at the 4430 TRM Rev X Table 3-744 
CM_EMU_CLKSTCTRL, the CLKTRCTRL field isn't documented as supporting the 
SW_SLEEP mode (which CLKDM_CAN_FORCE_SLEEP will set).

Maybe the CLKDM_CAN_* flags should be moved to a separate u8...

Anyway, what do you think about the following approach?  It uses a 
special flag to indicate that the EMU clockdomain is behaving in an 
unexpected way.  If you think it's reasonable, perhaps you could try your 
PMU tests with it?  It applies on top of linux-omap master 
(cb07e3394573a419147a1783f3bd7ef13045353c) plus the clockdomain patch 
posted earlier at:

http://marc.info/?l=linux-omapm=134209072829531w=2

But these patches may need to be applied on Kevin's 'pm' branch for 
meaningful PM testing:

http://marc.info/?l=linux-omapm=134196493819792w=2



- Paul

From: Paul Walmsley p...@pwsan.com
Date: Thu, 12 Jul 2012 14:58:43 -0600
Subject: [PATCH] ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU
 clockdomain idle problems

The idle status of the IP blocks and clocks inside the EMU clockdomain
isn't taken into account by the PRCM hardware when deciding whether
the clockdomain is idle.  Add a workaround flag, CLKDM_MISSING_IDLE_REPORTING,
to deal with this problem, and add the code necessary to support it.

XXX Add more description of what this flag actually does

XXX Jon, Ming, Will
---
 arch/arm/mach-omap2/clockdomain.c   |   17 ++
 arch/arm/mach-omap2/clockdomain.h   |   20 ++-
 arch/arm/mach-omap2/clockdomain2xxx_3xxx.c  |   86 +--
 arch/arm/mach-omap2/clockdomain44xx.c   |   11 
 arch/arm/mach-omap2/clockdomains3xxx_data.c |7 +--
 arch/arm/mach-omap2/clockdomains44xx_data.c |3 +-
 arch/arm/mach-omap2/omap_hwmod.c|3 +-
 7 files changed, 105 insertions(+), 42 deletions(-)

diff --git a/arch/arm/mach-omap2/clockdomain.c 
b/arch/arm/mach-omap2/clockdomain.c
index b851ba4..17b1d32 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -914,6 +914,23 @@ bool clkdm_in_hwsup(struct clockdomain *clkdm)
return ret;
 }
 
+/**
+ * clkdm_missing_idle_reporting - can @clkdm enter autoidle even if in use?
+ * @clkdm: struct clockdomain *
+ *
+ * Returns true if clockdomain @clkdm has the
+ * CLKDM_MISSING_IDLE_REPORTING flag set, or false if not or @clkdm is
+ * null.  More information is available in the documentation for the
+ * CLKDM_MISSING_IDLE_REPORTING macro.
+ */
+bool clkdm_missing_idle_reporting(struct clockdomain *clkdm)
+{
+   if (!clkdm)
+   return false;
+
+   return (clkdm-flags  CLKDM_MISSING_IDLE_REPORTING) ? true : false;
+}
+
 /* Clockdomain-to-clock/hwmod framework interface code */
 
 static int _clkdm_clk_hwmod_enable(struct clockdomain *clkdm)
diff --git a/arch/arm/mach-omap2/clockdomain.h 
b/arch/arm/mach-omap2/clockdomain.h
index 7b3c1d2..fb5d37f 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -1,9 +1,7 @@
 /*
- * arch/arm/plat-omap/include/mach/clockdomain.h
- *
  * OMAP2/3 clockdomain framework functions
  *
- * Copyright (C) 2008 Texas Instruments, Inc.
+ * Copyright (C) 2008, 2012 Texas Instruments, Inc.
  * Copyright (C) 2008-2011 Nokia Corporation
  *
  * Paul Walmsley
@@ -34,6 +32,20 @@
  * CLKDM_ACTIVE_WITH_MPU: The PRCM guarantees that this clockdomain is
  * active whenever the MPU is active.  True for interconnects and
  * the WKUP clockdomains.
+ * CLKDM_MISSING_IDLE_REPORTING: The idle status of the IP blocks and
+ * clocks inside this clockdomain are not taken into account by
+ * the PRCM when determining whether the clockdomain is idle.
+ * Without this flag, if the clockdomain is set to
+ * hardware-supervised idle mode, the PRCM may transition the
+ * enclosing powerdomain to a low power state, even when devices
+ * inside the clockdomain and powerdomain are in use.  (An example
+ * of such a clockdomain is the EMU clockdomain on OMAP3/4.)  If
+ * this flag is set, and the clockdomain does not support the
+ * force-sleep mode, then the HW_AUTO mode will be used to put the
+ * clockdomain to sleep.  Similarly, if the clockdomain supports
+ * the force-wakeup mode, then it will be used whenever a clock or
+ * IP block inside the clockdomain is active, rather than the
+ *