On Friday 02 March 2012 02:49 PM, Tero Kristo wrote:
On Thu, 2012-03-01 at 14:37 -0800, Kevin Hilman wrote:
Rajendra Nayak<rnayak@xxxxxx> writes:
On Wednesday 29 February 2012 07:56 PM, Tero Kristo wrote:
From: Vishwanath BS<vishwanath.bs@xxxxxx>
Enable IO Wake up for OMAP3 as part of PM Init. Currently this has been
managed in cpuidle path which is not the right place. Subsequent patch
will remove IO Daisy chain handling in cpuidle path once daisy chain is
handled as part of hwmod mux.
Signed-off-by: Vishwanath BS<vishwanath.bs@xxxxxx>
Tested-by: Govindraj.R<govindraj.raja@xxxxxx>
Signed-off-by: Tero Kristo<t-kristo@xxxxxx>
---
arch/arm/mach-omap2/pm34xx.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index e97ec3f..e6c2d39 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -793,6 +793,10 @@ static int __init omap3_pm_init(void)
goto err1;
}
+ if (omap3_has_io_wakeup())
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
+ PM_WKEN);
On OMAP4 this GLOBAL IO chain enable happens as part of the trigger
function itself, it might make sense to do that for OMAP3 too to avoid
similar issues as seen on OMAP4 when the GLOBAL switch is enabled too
late in boot. The best however would be to get rid of it in the trigger
function and enable this early during PM init, but I am not sure whats
a good place to do this 'early' enough.
What about the subsys_initcall() that's already in the prm*.c files?
IMO, the global one-time init doesn't belong in the trigger function
because there's no need to do the extra PRM read/write when it should be
a one-shot init.
This sounds good to me at least, I can change the patches to work like
this, Rajendra?
Yup, sounds good to me too. The extra PRM read/write is really an
overhead when done for every trigger. Thanks Kevin.
-Tero
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
