[PATCH 0/3] ARM: OMAP2+: PM/hwmod: clean up some WFI-related code

[PATCH 0/3] ARM: OMAP2+: PM/hwmod: clean up some WFI-related code

[Paul Walmsley]

This series implements a hwmod flag that can be set on OMAP IP blocks
to indicate that the MPU should not be allowed to enter WFI when the
IP blocks are active.  It also drops what appears to be unnecessary
SRAM code used by the OMAP2xxx PM code, using an inline WFI instead.

- Paul

---

Paul Walmsley (3):
      ARM: OMAP2xxx: PM: enter WFI via inline asm if CORE stays active
      ARM: OMAP2+: hwmod: add support for blocking WFI when a device is active
      ARM: OMAP2420: hwmod data/PM: use hwmod to block WFI when I2C active


 arch/arm/mach-omap2/omap_hwmod.c           |    8 ++++++++
 arch/arm/mach-omap2/omap_hwmod.h           |    9 +++++++++
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |    7 ++++++-
 arch/arm/mach-omap2/pm24xx.c               |   22 +++-------------------
 arch/arm/mach-omap2/sleep24xx.S            |   19 -------------------
 5 files changed, 26 insertions(+), 39 deletions(-)

[PATCH 1/3] ARM: OMAP2xxx: PM: enter WFI via inline asm if CORE stays active

[Paul Walmsley]

There shouldn't be any need to jump to SRAM code if the OMAP CORE
clockdomain (and consequently the SDRAM controller and CORE PLL) stays
active during MPU WFI.  The SRAM code should only be needed when the RAM
enters self-refresh.  So in the case where CORE stays active, just call
WFI directly from the mach-omap2/pm24xx.c code.  This removes some
unnecessary SRAM code.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
---
 arch/arm/mach-omap2/pm24xx.c    |    9 +++------
 arch/arm/mach-omap2/sleep24xx.S |   19 -------------------
 2 files changed, 3 insertions(+), 25 deletions(-)

diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index c333fa6..659a2f5 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -54,7 +54,6 @@
 #include "powerdomain.h"
 #include "clockdomain.h"
 
-static void (*omap2_sram_idle)(void);
 static void (*omap2_sram_suspend)(u32 dllctrl, void __iomem *sdrc_dlla_ctrl,
 				  void __iomem *sdrc_power);
 
@@ -196,7 +195,7 @@ static void omap2_enter_mpu_retention(void)
 						 OMAP2_PM_PWSTCTRL);
 	}
 
-	omap2_sram_idle();
+	asm("wfi" : : : "memory", "cc");
 }
 
 static int omap2_can_sleep(void)
@@ -356,11 +355,9 @@ int __init omap2_pm_init(void)
 	/*
 	 * We copy the assembler sleep/wakeup routines to SRAM.
 	 * These routines need to be in SRAM as that's the only
-	 * memory the MPU can see when it wakes up.
+	 * memory the MPU can see when it wakes up after the entire
+	 * chip enters idle.
 	 */
-	omap2_sram_idle = omap_sram_push(omap24xx_idle_loop_suspend,
-					 omap24xx_idle_loop_suspend_sz);
-
 	omap2_sram_suspend = omap_sram_push(omap24xx_cpu_suspend,
 					    omap24xx_cpu_suspend_sz);
 
diff --git a/arch/arm/mach-omap2/sleep24xx.S b/arch/arm/mach-omap2/sleep24xx.S
index ce0ccd2..1d3cb25 100644
--- a/arch/arm/mach-omap2/sleep24xx.S
+++ b/arch/arm/mach-omap2/sleep24xx.S
@@ -37,25 +37,6 @@
 	.text
 
 /*
- * Forces OMAP into idle state
- *
- * omap24xx_idle_loop_suspend() - This bit of code just executes the WFI
- * for normal idles.
- *
- * Note: This code get's copied to internal SRAM at boot. When the OMAP
- *	 wakes up it continues execution at the point it went to sleep.
- */
-	.align	3
-ENTRY(omap24xx_idle_loop_suspend)
-	stmfd	sp!, {r0, lr}		@ save registers on stack
-	mov	r0, #0			@ clear for mcr setup
-	mcr	p15, 0, r0, c7, c0, 4	@ wait for interrupt
-	ldmfd	sp!, {r0, pc}		@ restore regs and return
-
-ENTRY(omap24xx_idle_loop_suspend_sz)
-	.word	. - omap24xx_idle_loop_suspend
-
-/*
  * omap24xx_cpu_suspend() - Forces OMAP into deep sleep state by completing
  * SDRC shutdown then ARM shutdown.  Upon wake MPU is back on so just restore
  * SDRC.

[PATCH 1/3] ARM: OMAP2xxx: PM: enter WFI via inline asm if CORE stays active

[Santosh Shilimkar]

On Sunday 30 December 2012 11:58 PM, Paul Walmsley wrote:
> There shouldn't be any need to jump to SRAM code if the OMAP CORE
> clockdomain (and consequently the SDRAM controller and CORE PLL) stays
> active during MPU WFI.  The SRAM code should only be needed when the RAM
> enters self-refresh.  So in the case where CORE stays active, just call
> WFI directly from the mach-omap2/pm24xx.c code.  This removes some
> unnecessary SRAM code.
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Richard Woodruff <r-woodruff2@ti.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> ---
This sounds correct to me.
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

[PATCH 1/3] ARM: OMAP2xxx: PM: enter WFI via inline asm if CORE stays active

[Paul Walmsley]

On Sun, 30 Dec 2012, Paul Walmsley wrote:

> There shouldn't be any need to jump to SRAM code if the OMAP CORE
> clockdomain (and consequently the SDRAM controller and CORE PLL) stays
> active during MPU WFI.  The SRAM code should only be needed when the RAM
> enters self-refresh.  So in the case where CORE stays active, just call
> WFI directly from the mach-omap2/pm24xx.c code.  This removes some
> unnecessary SRAM code.
> 
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Richard Woodruff <r-woodruff2@ti.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>

Here's an updated version of this one.


- Paul

From: Paul Walmsley <paul@pwsan.com>
Date: Sun, 30 Dec 2012 10:15:48 -0700
Subject: [PATCH] ARM: OMAP2xxx: PM: enter WFI via inline asm if CORE stays
 active

There shouldn't be any need to jump to SRAM code if the OMAP CORE
clockdomain (and consequently the SDRAM controller and CORE PLL) stays
active during MPU WFI.  The SRAM code should only be needed when the RAM
enters self-refresh.  So in the case where CORE stays active, just call
WFI directly from the mach-omap2/pm24xx.c code.  This removes some
unnecessary SRAM code.

This second version replaces the inline WFI with the corresponding
coprocessor register call, using tlbflush.h as an example.  This is
because the assembler doesn't recognize WFI as a valid ARMv6
instruction.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Richard Woodruff <r-woodruff2@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
---
 arch/arm/mach-omap2/pm24xx.c    |   12 ++++++------
 arch/arm/mach-omap2/sleep24xx.S |   19 -------------------
 2 files changed, 6 insertions(+), 25 deletions(-)

diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index c333fa6..8914b9e 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -54,7 +54,6 @@
 #include "powerdomain.h"
 #include "clockdomain.h"
 
-static void (*omap2_sram_idle)(void);
 static void (*omap2_sram_suspend)(u32 dllctrl, void __iomem *sdrc_dlla_ctrl,
 				  void __iomem *sdrc_power);
 
@@ -172,6 +171,8 @@ static int omap2_allow_mpu_retention(void)
 
 static void omap2_enter_mpu_retention(void)
 {
+	const int zero = 0;
+
 	/* Putting MPU into the WFI state while a transfer is active
 	 * seems to cause the I2C block to timeout. Why? Good question. */
 	if (omap2_i2c_active())
@@ -196,7 +197,8 @@ static void omap2_enter_mpu_retention(void)
 						 OMAP2_PM_PWSTCTRL);
 	}
 
-	omap2_sram_idle();
+	/* WFI */
+	asm("mcr p15, 0, %0, c7, c0, 4" : : "r" (zero) : "memory", "cc");
 }
 
 static int omap2_can_sleep(void)
@@ -356,11 +358,9 @@ int __init omap2_pm_init(void)
 	/*
 	 * We copy the assembler sleep/wakeup routines to SRAM.
 	 * These routines need to be in SRAM as that's the only
-	 * memory the MPU can see when it wakes up.
+	 * memory the MPU can see when it wakes up after the entire
+	 * chip enters idle.
 	 */
-	omap2_sram_idle = omap_sram_push(omap24xx_idle_loop_suspend,
-					 omap24xx_idle_loop_suspend_sz);
-
 	omap2_sram_suspend = omap_sram_push(omap24xx_cpu_suspend,
 					    omap24xx_cpu_suspend_sz);
 
diff --git a/arch/arm/mach-omap2/sleep24xx.S b/arch/arm/mach-omap2/sleep24xx.S
index ce0ccd2..1d3cb25 100644
--- a/arch/arm/mach-omap2/sleep24xx.S
+++ b/arch/arm/mach-omap2/sleep24xx.S
@@ -37,25 +37,6 @@
 	.text
 
 /*
- * Forces OMAP into idle state
- *
- * omap24xx_idle_loop_suspend() - This bit of code just executes the WFI
- * for normal idles.
- *
- * Note: This code get's copied to internal SRAM at boot. When the OMAP
- *	 wakes up it continues execution at the point it went to sleep.
- */
-	.align	3
-ENTRY(omap24xx_idle_loop_suspend)
-	stmfd	sp!, {r0, lr}		@ save registers on stack
-	mov	r0, #0			@ clear for mcr setup
-	mcr	p15, 0, r0, c7, c0, 4	@ wait for interrupt
-	ldmfd	sp!, {r0, pc}		@ restore regs and return
-
-ENTRY(omap24xx_idle_loop_suspend_sz)
-	.word	. - omap24xx_idle_loop_suspend
-
-/*
  * omap24xx_cpu_suspend() - Forces OMAP into deep sleep state by completing
  * SDRC shutdown then ARM shutdown.  Upon wake MPU is back on so just restore
  * SDRC.
-- 
1.7.10.4

[PATCH 1/3] ARM: OMAP2xxx: PM: enter WFI via inline asm if CORE stays active

[Kevin Hilman]

Paul Walmsley <paul@pwsan.com> writes:

> On Sun, 30 Dec 2012, Paul Walmsley wrote:
>
>> There shouldn't be any need to jump to SRAM code if the OMAP CORE
>> clockdomain (and consequently the SDRAM controller and CORE PLL) stays
>> active during MPU WFI.  The SRAM code should only be needed when the RAM
>> enters self-refresh.  So in the case where CORE stays active, just call
>> WFI directly from the mach-omap2/pm24xx.c code.  This removes some
>> unnecessary SRAM code.
>> 
>> Signed-off-by: Paul Walmsley <paul@pwsan.com>
>> Cc: Richard Woodruff <r-woodruff2@ti.com>
>> Cc: Kevin Hilman <khilman@deeprootsystems.com>
>
> Here's an updated version of this one.
>
>
> - Paul
>
> From: Paul Walmsley <paul@pwsan.com>
> Date: Sun, 30 Dec 2012 10:15:48 -0700
> Subject: [PATCH] ARM: OMAP2xxx: PM: enter WFI via inline asm if CORE stays
>  active
>
> There shouldn't be any need to jump to SRAM code if the OMAP CORE
> clockdomain (and consequently the SDRAM controller and CORE PLL) stays
> active during MPU WFI.  The SRAM code should only be needed when the RAM
> enters self-refresh.  So in the case where CORE stays active, just call
> WFI directly from the mach-omap2/pm24xx.c code.  This removes some
> unnecessary SRAM code.
>
> This second version replaces the inline WFI with the corresponding
> coprocessor register call, using tlbflush.h as an example.  This is
> because the assembler doesn't recognize WFI as a valid ARMv6
> instruction.
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> Cc: Richard Woodruff <r-woodruff2@ti.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>

Acked-by: Kevin Hilman <khilman@linaro.org>

> ---
>  arch/arm/mach-omap2/pm24xx.c    |   12 ++++++------
>  arch/arm/mach-omap2/sleep24xx.S |   19 -------------------
>  2 files changed, 6 insertions(+), 25 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
> index c333fa6..8914b9e 100644
> --- a/arch/arm/mach-omap2/pm24xx.c
> +++ b/arch/arm/mach-omap2/pm24xx.c
> @@ -54,7 +54,6 @@
>  #include "powerdomain.h"
>  #include "clockdomain.h"
>  
> -static void (*omap2_sram_idle)(void);
>  static void (*omap2_sram_suspend)(u32 dllctrl, void __iomem *sdrc_dlla_ctrl,
>  				  void __iomem *sdrc_power);
>  
> @@ -172,6 +171,8 @@ static int omap2_allow_mpu_retention(void)
>  
>  static void omap2_enter_mpu_retention(void)
>  {
> +	const int zero = 0;
> +
>  	/* Putting MPU into the WFI state while a transfer is active
>  	 * seems to cause the I2C block to timeout. Why? Good question. */
>  	if (omap2_i2c_active())
> @@ -196,7 +197,8 @@ static void omap2_enter_mpu_retention(void)
>  						 OMAP2_PM_PWSTCTRL);
>  	}
>  
> -	omap2_sram_idle();
> +	/* WFI */
> +	asm("mcr p15, 0, %0, c7, c0, 4" : : "r" (zero) : "memory", "cc");
>  }
>  
>  static int omap2_can_sleep(void)
> @@ -356,11 +358,9 @@ int __init omap2_pm_init(void)
>  	/*
>  	 * We copy the assembler sleep/wakeup routines to SRAM.
>  	 * These routines need to be in SRAM as that's the only
> -	 * memory the MPU can see when it wakes up.
> +	 * memory the MPU can see when it wakes up after the entire
> +	 * chip enters idle.
>  	 */
> -	omap2_sram_idle = omap_sram_push(omap24xx_idle_loop_suspend,
> -					 omap24xx_idle_loop_suspend_sz);
> -
>  	omap2_sram_suspend = omap_sram_push(omap24xx_cpu_suspend,
>  					    omap24xx_cpu_suspend_sz);
>  
> diff --git a/arch/arm/mach-omap2/sleep24xx.S b/arch/arm/mach-omap2/sleep24xx.S
> index ce0ccd2..1d3cb25 100644
> --- a/arch/arm/mach-omap2/sleep24xx.S
> +++ b/arch/arm/mach-omap2/sleep24xx.S
> @@ -37,25 +37,6 @@
>  	.text
>  
>  /*
> - * Forces OMAP into idle state
> - *
> - * omap24xx_idle_loop_suspend() - This bit of code just executes the WFI
> - * for normal idles.
> - *
> - * Note: This code get's copied to internal SRAM at boot. When the OMAP
> - *	 wakes up it continues execution at the point it went to sleep.
> - */
> -	.align	3
> -ENTRY(omap24xx_idle_loop_suspend)
> -	stmfd	sp!, {r0, lr}		@ save registers on stack
> -	mov	r0, #0			@ clear for mcr setup
> -	mcr	p15, 0, r0, c7, c0, 4	@ wait for interrupt
> -	ldmfd	sp!, {r0, pc}		@ restore regs and return
> -
> -ENTRY(omap24xx_idle_loop_suspend_sz)
> -	.word	. - omap24xx_idle_loop_suspend
> -
> -/*
>   * omap24xx_cpu_suspend() - Forces OMAP into deep sleep state by completing
>   * SDRC shutdown then ARM shutdown.  Upon wake MPU is back on so just restore
>   * SDRC.

[PATCH 2/3] ARM: OMAP2+: hwmod: add support for blocking WFI when a device is active

[Paul Walmsley]

Apparently, on some OMAPs, the MPU can't be allowed to enter WFI while
certain peripherals are active.  It's not clear why, and it's likely
that there is simply some other bug in the driver or integration code.
But since the likelihood that anyone will have the time to track these
problems down in the future seems quite small, we'll provide a
flag, HWMOD_BLOCK_WFI, to mark these issues in the hwmod data.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/omap_hwmod.c |    8 ++++++++
 arch/arm/mach-omap2/omap_hwmod.h |    9 +++++++++
 2 files changed, 17 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 4653efb..6804d47 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -139,6 +139,8 @@
 #include <linux/slab.h>
 #include <linux/bootmem.h>
 
+#include <asm/system_misc.h>
+
 #include "clock.h"
 #include "omap_hwmod.h"
 
@@ -2134,6 +2136,8 @@ static int _enable(struct omap_hwmod *oh)
 	_enable_clocks(oh);
 	if (soc_ops.enable_module)
 		soc_ops.enable_module(oh);
+	if (oh->flags & HWMOD_BLOCK_WFI)
+		disable_hlt();
 
 	if (soc_ops.update_context_lost)
 		soc_ops.update_context_lost(oh);
@@ -2195,6 +2199,8 @@ static int _idle(struct omap_hwmod *oh)
 		_idle_sysc(oh);
 	_del_initiator_dep(oh, mpu_oh);
 
+	if (oh->flags & HWMOD_BLOCK_WFI)
+		enable_hlt();
 	if (soc_ops.disable_module)
 		soc_ops.disable_module(oh);
 
@@ -2303,6 +2309,8 @@ static int _shutdown(struct omap_hwmod *oh)
 	if (oh->_state == _HWMOD_STATE_ENABLED) {
 		_del_initiator_dep(oh, mpu_oh);
 		/* XXX what about the other system initiators here? dma, dsp */
+		if (oh->flags & HWMOD_BLOCK_WFI)
+			enable_hlt();
 		if (soc_ops.disable_module)
 			soc_ops.disable_module(oh);
 		_disable_clocks(oh);
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 3ae852a..80c00e7 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -451,6 +451,14 @@ struct omap_hwmod_omap4_prcm {
  *     enabled.  This prevents the hwmod code from being able to
  *     enable and reset the IP block early.  XXX Eventually it should
  *     be possible to query the clock framework for this information.
+ * HWMOD_BLOCK_WFI: Some OMAP peripherals apparently don't work
+ *     correctly if the MPU is allowed to go idle while the
+ *     peripherals are active.  This is apparently true for the I2C on
+ *     OMAP2420, and also the EMAC on AM3517/3505.  It's unlikely that
+ *     this is really true -- we're probably not configuring something
+ *     correctly, or this is being abused to deal with some PM latency
+ *     issues -- but we're currently suffering from a shortage of
+ *     folks who are able to track these issues down properly.
  */
 #define HWMOD_SWSUP_SIDLE			(1 << 0)
 #define HWMOD_SWSUP_MSTANDBY			(1 << 1)
@@ -462,6 +470,7 @@ struct omap_hwmod_omap4_prcm {
 #define HWMOD_CONTROL_OPT_CLKS_IN_RESET		(1 << 7)
 #define HWMOD_16BIT_REG				(1 << 8)
 #define HWMOD_EXT_OPT_MAIN_CLK			(1 << 9)
+#define HWMOD_BLOCK_WFI				(1 << 10)
 
 /*
  * omap_hwmod._int_flags definitions

[PATCH 2/3] ARM: OMAP2+: hwmod: add support for blocking WFI when a device is active

[Santosh Shilimkar]

Paul,

On Sunday 30 December 2012 11:58 PM, Paul Walmsley wrote:
> Apparently, on some OMAPs, the MPU can't be allowed to enter WFI while
> certain peripherals are active.  It's not clear why, and it's likely
> that there is simply some other bug in the driver or integration code.
> But since the likelihood that anyone will have the time to track these
> problems down in the future seems quite small, we'll provide a
> flag, HWMOD_BLOCK_WFI, to mark these issues in the hwmod data.
>
> Signed-off-by: Paul Walmsley <paul@pwsan.com>
> ---
This is more of question. If the limitation is w.r.t MPU power
state then shouldn't we just prevent the MPU power state rather
than blocking the WFI completely.

Can you please clarify if retaining MPU power state in ON can achieve
the same results ?

Regards
Santosh

[PATCH 2/3] ARM: OMAP2+: hwmod: add support for blocking WFI when a device is active

[Paul Walmsley]

Hi

On Mon, 31 Dec 2012, Santosh Shilimkar wrote:

> This is more of question. If the limitation is w.r.t MPU power
> state then shouldn't we just prevent the MPU power state rather
> than blocking the WFI completely.
> 
> Can you please clarify if retaining MPU power state in ON can achieve
> the same results ?

In these cases, it's blocking WFI that is apparently needed.  I know it 
doesn't make much sense.


- Paul

[PATCH 2/3] ARM: OMAP2+: hwmod: add support for blocking WFI when a device is active

[Santosh Shilimkar]

On Monday 31 December 2012 06:26 PM, Paul Walmsley wrote:
> Hi
>
> On Mon, 31 Dec 2012, Santosh Shilimkar wrote:
>
>> This is more of question. If the limitation is w.r.t MPU power
>> state then shouldn't we just prevent the MPU power state rather
>> than blocking the WFI completely.
>>
>> Can you please clarify if retaining MPU power state in ON can achieve
>> the same results ?
>
> In these cases, it's blocking WFI that is apparently needed.  I know it
> doesn't make much sense.
>
Ya. It doesn't make sense but if that is the case then the patch make
sense :-)

Thanks for clarification !!

Regards
Santosh

[PATCH 3/3] ARM: OMAP2420: hwmod data/PM: use hwmod to block WFI when I2C active

[Paul Walmsley]

Use the HWMOD_BLOCK_WFI flag in the hwmod data to prevent the MPU from
entering WFI when the I2C devices are active.  No idea why this is needed;
this could certainly bear further investigation if anyone is interested.
The objective here is to remove some custom code from the OMAP24xx PM
code.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
---
 arch/arm/mach-omap2/omap_hwmod_2420_data.c |    7 ++++++-
 arch/arm/mach-omap2/pm24xx.c               |   13 -------------
 2 files changed, 6 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index b5efe58..6a764af 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -121,7 +121,12 @@ static struct omap_hwmod omap2420_i2c1_hwmod = {
 	},
 	.class		= &i2c_class,
 	.dev_attr	= &i2c_dev_attr,
-	.flags		= HWMOD_16BIT_REG,
+	/*
+	 * From mach-omap2/pm24xx.c: "Putting MPU into the WFI state
+	 * while a transfer is active seems to cause the I2C block to
+	 * timeout. Why? Good question."
+	 */
+	.flags		= (HWMOD_16BIT_REG | HWMOD_BLOCK_WFI),
 };
 
 /* I2C2 */
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index 659a2f5..f69c701 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -139,14 +139,6 @@ no_sleep:
 	return 0;
 }
 
-static int omap2_i2c_active(void)
-{
-	u32 l;
-
-	l = omap2_cm_read_mod_reg(CORE_MOD, CM_FCLKEN1);
-	return l & (OMAP2420_EN_I2C2_MASK | OMAP2420_EN_I2C1_MASK);
-}
-
 static int sti_console_enabled;
 
 static int omap2_allow_mpu_retention(void)
@@ -171,11 +163,6 @@ static int omap2_allow_mpu_retention(void)
 
 static void omap2_enter_mpu_retention(void)
 {
-	/* Putting MPU into the WFI state while a transfer is active
-	 * seems to cause the I2C block to timeout. Why? Good question. */
-	if (omap2_i2c_active())
-		return;
-
 	/* The peripherals seem not to be able to wake up the MPU when
 	 * it is in retention mode. */
 	if (omap2_allow_mpu_retention()) {