ARM: OMAP4: core retention support
Subsystems (6)
v9 cover ARM: OMAP4: core retention support
Hi,
Changes compared to previous version:
- rebased on top of 3.7-rc1
- applies on top of latest func pwrst code (v6)
- added back patch #1 to this set (it wasn't queued yet after all)
- added patch #7 for fixing a bug in the functional pwrst code
- added patch #8 for fixing a regression with MUSB PHY power handling (not quite sure if this is the correct way to fix this or not)
Tested with omap4460 gp panda + omap4430 emu blaze boards, with cpuidle + suspend.
Branch also available here:git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
branch: mainline-3.7-rc1-omap4-ret-v9
Branch contains also the local timer fix patch from Tony, otherwise cpuidle does not work properly.
-Tero
PATCH v9 1/8 ARM: OMAP: hwmod: Add support for per hwmod/module context lost count
From: Rajendra Nayak <[email protected]>
OMAP4 has module specific context lost registers which makes it now possible to have module level context loss count, instead of relying on the powerdomain level context count.
Add 2 private hwmod api's to update/clear the hwmod/module specific context lost counters/register.
Update the module specific context_lost_counter and clear the hardware bits just after enabling the module.
omap_hwmod_get_context_loss_count() now returns the hwmod context loss count them on platforms where they exist (OMAP4), else fall back on the pwrdm level counters for older platforms.
[paul at pwsan.com: added function kerneldoc, fixed structure kerneldoc,
rearranged structure to avoid memory waste, marked fns as OMAP4-specific, prevent fn entry on non-OMAP4 chips, reduced indentation, merged update and clear, merged patches]
[t-kristo at ti.com: added support for arch specific hwmod ops, and changed
the no context offset indicator to USHRT_MAX]
[paul at pwsan.com: use NO_CONTEXT_LOSS_BIT flag rather than USHRT_MAX;
convert unsigned context lost counter to int to match the return type; get rid of hwmod_ops in favor of the existing soc_ops mechanism]
--- arch/arm/mach-omap2/omap_hwmod.c | 60 ++++++++++++++++++++++++-- arch/arm/plat-omap/include/plat/omap_hwmod.h | 10 +++- 2 files changed, 63 insertions(+), 7 deletions(-)
arch/arm/mach-omap2/omap_hwmod.c +56 -4
@@ -189,6 +189,8 @@ struct omap_hwmod_soc_ops {int (*is_hardreset_asserted)(struct omap_hwmod *oh,struct omap_hwmod_rst_info *ohri);int (*init_clkdm)(struct omap_hwmod *oh); +void (*update_context_lost)(struct omap_hwmod *oh); +int (*get_context_lost)(struct omap_hwmod *oh); };/* soc_ops: adapts the omap_hwmod code to the currently-booted SoC */
@@ -1962,6 +1964,47 @@ static void _reconfigure_io_chain(void) }/** +* _omap4_update_context_lost - increment hwmod context loss counter if +* hwmod context was lost, and clear hardware context loss reg +* @oh: hwmod to check for context loss +* +* If the PRCM indicates that the hwmod @oh lost context, increment +* our in-memory context loss counter, and clear the RM_*_CONTEXT +* bits. No return value. +*/ +static void _omap4_update_context_lost (struct omap_hwmod *oh) +{ +u32 r; + +if (oh->prcm.omap4.flags &HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT ) +return ; + + r =omap4_prminst_read_inst_reg (oh->clkdm->pwrdm.ptr->prcm_partition, + oh->clkdm->pwrdm.ptr->prcm_offs, + oh->prcm.omap4.context_offs); + +if (!r) +return ; + + oh->prcm.omap4.context_lost_counter++; + +omap4_prminst_write_inst_reg (r, oh->clkdm->pwrdm.ptr->prcm_partition, + oh->clkdm->pwrdm.ptr->prcm_offs, + oh->prcm.omap4.context_offs); +} + +/** +* _omap4_get_context_lost - get context loss counter for a hwmod +* @oh: hwmod to get context loss counter for +* +* Returns the in-memory context loss counter for a hwmod. +*/ +static int _omap4_get_context_lost (struct omap_hwmod *oh) +{ +return oh->prcm.omap4.context_lost_counter; +} + +/** * _enable - enable an omap_hwmod * @oh: struct omap_hwmod * *
@@ -2044,6 +2087,9 @@ static int _enable(struct omap_hwmod *oh)if (soc_ops.enable_module) soc_ops.enable_module (oh); +if (soc_ops.update_context_lost) + soc_ops.update_context_lost (oh); + r = (soc_ops.wait_target_ready) ? soc_ops.wait_target_ready (oh) : -EINVAL ;if (!r) {
@@ -3852,17 +3898,21 @@ ohsps_unlock:* omap_hwmod_get_context_loss_count - get lost context count * @oh: struct omap_hwmod * * -* Query the powerdomain of of @oh to get the context loss -* count for this device. +* Returns the context loss count of associated @oh +* upon success, or zero if no context loss data is available. * -* Returns the context loss count of the powerdomain assocated with @oh -* upon success, or zero if no powerdomain exists for @oh. +* On OMAP4, this queries the per-hwmod context loss register, +* assuming one exists. If not, or on OMAP2/3, this queries the +* enclosing powerdomain context loss count. */ int omap_hwmod_get_context_loss_count (struct omap_hwmod *oh) {struct powerdomain *pwrdm;int ret =0 ; +if (soc_ops.get_context_lost) +return soc_ops.get_context_lost (oh); + pwrdm =omap_hwmod_get_pwrdm (oh);if (pwrdm) ret =pwrdm_get_context_loss_count (pwrdm);
@@ -3980,6 +4030,8 @@ void __init omap_hwmod_init(void) soc_ops.deassert_hardreset = _am33xx_deassert_hardreset; soc_ops.is_hardreset_asserted = _am33xx_is_hardreset_asserted; soc_ops.init_clkdm = _init_clkdm; + soc_ops.update_context_lost = _omap4_update_context_lost; + soc_ops.get_context_lost = _omap4_get_context_lost; }else {WARN (1 ,"omap_hwmod: unknown SoC type\n" ); }
arch/arm/plat-omap/include/plat/omap_hwmod.h +7 -3
@@ -2,7 +2,7 @@* omap_hwmod macros, structures * * Copyright (C) 2009-2011 Nokia Corporation -* Copyright (C) 2012 Texas Instruments, Inc. +* Copyright (C) 2011-2012 Texas Instruments, Inc. * Paul Walmsley * * Created in collaboration with (alphabetical order): Beno?t Cousson,
@@ -395,12 +395,15 @@ struct omap_hwmod_omap2_prcm {/** * struct omap_hwmod_omap4_prcm - OMAP4-specific PRCM data -* @clkctrl_reg: PRCM address of the clock control register -* @rstctrl_reg: address of the XXX_RSTCTRL register located in the PRM +* @clkctrl_offs: offset of the PRCM clock control register +* @rstctrl_offs: offset of the XXX_RSTCTRL register located in the PRM +* @context_offs: offset of the RM_*_CONTEXT register * @lostcontext_mask: bitmask for selecting bits from RM_*_CONTEXT register * @rstst_reg: (AM33XX only) address of the XXX_RSTST register in the PRM * @submodule_wkdep_bit: bit shift of the WKDEP range * @flags: PRCM register capabilities for this IP block +* @modulemode: allowable modulemodes +* @context_lost_counter: Count of module level context lost * * If @lostcontext_mask is not defined, context loss check code uses * whole register without masking. @lostcontext_mask should only be
@@ -416,6 +419,7 @@ struct omap_hwmod_omap4_prcm {u8 submodule_wkdep_bit;u8 modulemode;u8 flags; +int context_lost_counter; };
Signature · 1 line
1.7.4.1
Paul Walmsley
maintainerPATCH v9 1/8 ARM: OMAP: hwmod: Add support for per hwmod/module context lost count
Hi,
Quoted 23 lines · Tero Kristo
From: Rajendra Nayak <[email protected]>
OMAP4 has module specific context lost registers which makes it now possible to have module level context loss count, instead of relying on the powerdomain level context count.
Add 2 private hwmod api's to update/clear the hwmod/module specific context lost counters/register.
Update the module specific
context_lost_counterand clear the hardware bits just after enabling the module.
omap_hwmod_get_context_loss_count()now returns the hwmod context loss count them on platforms where they exist (OMAP4), else fall back on the pwrdm level counters for older platforms.Signed-off-by Rajendra Nayak <[email protected]>[paul at pwsan.com: added function kerneldoc, fixed structure kerneldoc,
rearranged structure to avoid memory waste, marked fns as OMAP4-specific, prevent fn entry on non-OMAP4 chips, reduced indentation, merged update and clear, merged patches]
[t-kristo at ti.com: added support for arch specific hwmod ops, and changed
the no context offset indicator toUSHRT_MAX]
Quoted 5 lines
Signed-off-by Tero Kristo <[email protected]>[paul at pwsan.com: use
NO_CONTEXT_LOSS_BITflag rather thanUSHRT_MAX;
convert unsigned context lost counter to int to match the return type; get rid ofhwmod_opsin favor of the existingsoc_opsmechanism]Signed-off-by Paul Walmsley <[email protected]>
Thanks, re-queued for 3.8.
- Paul
Paul Walmsley
maintainerPATCH v9 1/8 ARM: OMAP: hwmod: Add support for per hwmod/module context lost count
In reply to Tero KristoQuoted 23 lines · Tero Kristo
From: Rajendra Nayak <[email protected]>
OMAP4 has module specific context lost registers which makes it now possible to have module level context loss count, instead of relying on the powerdomain level context count.
Add 2 private hwmod api's to update/clear the hwmod/module specific context lost counters/register.
Update the module specific
context_lost_counterand clear the hardware bits just after enabling the module.
omap_hwmod_get_context_loss_count()now returns the hwmod context loss count them on platforms where they exist (OMAP4), else fall back on the pwrdm level counters for older platforms.Signed-off-by Rajendra Nayak <[email protected]>[paul at pwsan.com: added function kerneldoc, fixed structure kerneldoc,
rearranged structure to avoid memory waste, marked fns as OMAP4-specific, prevent fn entry on non-OMAP4 chips, reduced indentation, merged update and clear, merged patches]
[t-kristo at ti.com: added support for arch specific hwmod ops, and changed
the no context offset indicator toUSHRT_MAX]
Quoted 5 lines
Signed-off-by Tero Kristo <[email protected]>[paul at pwsan.com: use
NO_CONTEXT_LOSS_BITflag rather thanUSHRT_MAX;
convert unsigned context lost counter to int to match the return type; get rid ofhwmod_opsin favor of the existingsoc_opsmechanism]Signed-off-by Paul Walmsley <[email protected]>
Here's an updated version of this one with the low-level PRM accesses moved out to the PRM code.
- Paul
From: Rajendra Nayak <[email protected]>
Date: Wed, 21 Nov 2012 11:48:46 -0700
Subject: [PATCH] ARM: OMAP2+: hwmod: Add support for per hwmod/module context
lost count
OMAP4 has module specific context lost registers which makes it now possible to have module level context loss count, instead of relying on the powerdomain level context count.
Add 2 private hwmod api's to update/clear the hwmod/module specific context lost counters/register.
Update the module specific context_lost_counter and clear the hardware bits just after enabling the module.
omap_hwmod_get_context_loss_count() now returns the hwmod context loss count them on platforms where they exist (OMAP4), else fall back on the pwrdm level counters for older platforms.
[paul at pwsan.com: added function kerneldoc, fixed structure kerneldoc,
rearranged structure to avoid memory waste, marked fns as OMAP4-specific, prevent fn entry on non-OMAP4 chips, reduced indentation, merged update and clear, merged patches]
[t-kristo at ti.com: added support for arch specific hwmod ops, and changed
the no context offset indicator to USHRT_MAX]
[paul at pwsan.com: use NO_CONTEXT_LOSS_BIT flag rather than USHRT_MAX;
convert unsigned context lost counter to int to match the return type; get rid of hwmod_ops in favor of the existing soc_ops mechanism; move context loss low-level accesses to the PRM code]
--- arch/arm/mach-omap2/omap_hwmod.c | 55 +++++++++++++++++++++++++++++++++++--- arch/arm/mach-omap2/omap_hwmod.h | 10 ++++--- arch/arm/mach-omap2/prm.h | 11 +++++++- arch/arm/mach-omap2/prm44xx.c | 33 +++++++++++++++++++++++ arch/arm/mach-omap2/prm_common.c | 45 +++++++++++++++++++++++++++++++ 5 files changed, 146 insertions(+), 8 deletions(-)
arch/arm/mach-omap2/omap_hwmod.c +51 -4
@@ -187,6 +187,8 @@ struct omap_hwmod_soc_ops {int (*is_hardreset_asserted)(struct omap_hwmod *oh,struct omap_hwmod_rst_info *ohri);int (*init_clkdm)(struct omap_hwmod *oh); +void (*update_context_lost)(struct omap_hwmod *oh); +int (*get_context_lost)(struct omap_hwmod *oh); };/* soc_ops: adapts the omap_hwmod code to the currently-booted SoC */
@@ -1983,6 +1985,42 @@ static void _reconfigure_io_chain(void) }/** +* _omap4_update_context_lost - increment hwmod context loss counter if +* hwmod context was lost, and clear hardware context loss reg +* @oh: hwmod to check for context loss +* +* If the PRCM indicates that the hwmod @oh lost context, increment +* our in-memory context loss counter, and clear the RM_*_CONTEXT +* bits. No return value. +*/ +static void _omap4_update_context_lost (struct omap_hwmod *oh) +{ +if (oh->prcm.omap4.flags &HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT ) +return ; + +if (!prm_was_any_context_lost_old (oh->clkdm->pwrdm.ptr->prcm_partition, + oh->clkdm->pwrdm.ptr->prcm_offs, + oh->prcm.omap4.context_offs)) +return ; + + oh->prcm.omap4.context_lost_counter++; +prm_clear_context_loss_flags_old (oh->clkdm->pwrdm.ptr->prcm_partition, + oh->clkdm->pwrdm.ptr->prcm_offs, + oh->prcm.omap4.context_offs); +} + +/** +* _omap4_get_context_lost - get context loss counter for a hwmod +* @oh: hwmod to get context loss counter for +* +* Returns the in-memory context loss counter for a hwmod. +*/ +static int _omap4_get_context_lost (struct omap_hwmod *oh) +{ +return oh->prcm.omap4.context_lost_counter; +} + +/** * _enable - enable an omap_hwmod * @oh: struct omap_hwmod * *
@@ -2065,6 +2103,9 @@ static int _enable(struct omap_hwmod *oh)if (soc_ops.enable_module) soc_ops.enable_module (oh); +if (soc_ops.update_context_lost) + soc_ops.update_context_lost (oh); + r = (soc_ops.wait_target_ready) ? soc_ops.wait_target_ready (oh) : -EINVAL ;if (!r) {
@@ -3907,17 +3948,21 @@ ohsps_unlock:* omap_hwmod_get_context_loss_count - get lost context count * @oh: struct omap_hwmod * * -* Query the powerdomain of of @oh to get the context loss -* count for this device. +* Returns the context loss count of associated @oh +* upon success, or zero if no context loss data is available. * -* Returns the context loss count of the powerdomain assocated with @oh -* upon success, or zero if no powerdomain exists for @oh. +* On OMAP4, this queries the per-hwmod context loss register, +* assuming one exists. If not, or on OMAP2/3, this queries the +* enclosing powerdomain context loss count. */ int omap_hwmod_get_context_loss_count (struct omap_hwmod *oh) {struct powerdomain *pwrdm;int ret =0 ; +if (soc_ops.get_context_lost) +return soc_ops.get_context_lost (oh); + pwrdm =omap_hwmod_get_pwrdm (oh);if (pwrdm) ret =pwrdm_get_context_loss_count (pwrdm);
@@ -4032,6 +4077,8 @@ void __init omap_hwmod_init(void) soc_ops.deassert_hardreset = _omap4_deassert_hardreset; soc_ops.is_hardreset_asserted = _omap4_is_hardreset_asserted; soc_ops.init_clkdm = _init_clkdm; + soc_ops.update_context_lost = _omap4_update_context_lost; + soc_ops.get_context_lost = _omap4_get_context_lost; }else if (soc_is_am33xx ()) { soc_ops.enable_module = _am33xx_enable_module; soc_ops.disable_module = _am33xx_disable_module;
arch/arm/mach-omap2/omap_hwmod.h +7 -3
@@ -2,7 +2,7 @@* omap_hwmod macros, structures * * Copyright (C) 2009-2011 Nokia Corporation -* Copyright (C) 2012 Texas Instruments, Inc. +* Copyright (C) 2011-2012 Texas Instruments, Inc. * Paul Walmsley * * Created in collaboration with (alphabetical order): Beno?t Cousson,
@@ -394,12 +394,15 @@ struct omap_hwmod_omap2_prcm {/** * struct omap_hwmod_omap4_prcm - OMAP4-specific PRCM data -* @clkctrl_reg: PRCM address of the clock control register -* @rstctrl_reg: address of the XXX_RSTCTRL register located in the PRM +* @clkctrl_offs: offset of the PRCM clock control register +* @rstctrl_offs: offset of the XXX_RSTCTRL register located in the PRM +* @context_offs: offset of the RM_*_CONTEXT register * @lostcontext_mask: bitmask for selecting bits from RM_*_CONTEXT register * @rstst_reg: (AM33XX only) address of the XXX_RSTST register in the PRM * @submodule_wkdep_bit: bit shift of the WKDEP range * @flags: PRCM register capabilities for this IP block +* @modulemode: allowable modulemodes +* @context_lost_counter: Count of module level context lost * * If @lostcontext_mask is not defined, context loss check code uses * whole register without masking. @lostcontext_mask should only be
@@ -415,6 +418,7 @@ struct omap_hwmod_omap4_prcm {u8 submodule_wkdep_bit;u8 modulemode;u8 flags; +int context_lost_counter; };
arch/arm/mach-omap2/prm.h +10 -1
@@ -114,16 +114,25 @@ struct prm_reset_src_map {/** * struct prm_ll_data - fn ptrs to per-SoC PRM function implementations -* @read_reset_sources: ptr to the Soc PRM-specific get_reset_source impl +* @read_reset_sources: ptr to the SoC PRM-specific get_reset_source impl +* @was_any_context_lost_old: ptr to the SoC PRM context loss test fn +* @clear_context_loss_flags_old: ptr to the SoC PRM context loss flag clear fn +* +* XXX @was_any_context_lost_old and @clear_context_loss_flags_old are +* deprecated. */ struct prm_ll_data {u32 (*read_reset_sources)(void ); +bool (*was_any_context_lost_old)(u8 part,s16 inst,u16 idx); +void (*clear_context_loss_flags_old)(u8 part,s16 inst,u16 idx); };extern int prm_register (struct prm_ll_data *pld);extern int prm_unregister (struct prm_ll_data *pld);extern u32 prm_read_reset_sources (void ); +extern bool prm_was_any_context_lost_old (u8 part,s16 inst,u16 idx); +extern void prm_clear_context_loss_flags_old (u8 part,s16 inst,u16 idx);#endif
arch/arm/mach-omap2/prm44xx.c +33 -0
@@ -346,6 +346,37 @@ static u32 omap44xx_prm_read_reset_sources(void)return r; } +/** +* omap44xx_prm_was_any_context_lost_old - was module hardware context lost? +* @part: PRM partition ID (e.g., OMAP4430_PRM_PARTITION) +* @inst: PRM instance offset (e.g., OMAP4430_PRM_MPU_INST) +* @idx: CONTEXT register offset +* +* Return 1 if any bits were set in the *_CONTEXT_* register +* identified by (@part, @inst, @idx), which means that some context +* was lost for that module; otherwise, return 0. +*/ +static bool omap44xx_prm_was_any_context_lost_old (u8 part,s16 inst,u16 idx) +{ +return (omap4_prminst_read_inst_reg (part, inst, idx)) ?1 :0 ; +} + +/** +* omap44xx_prm_clear_context_lost_flags_old - clear context loss flags +* @part: PRM partition ID (e.g., OMAP4430_PRM_PARTITION) +* @inst: PRM instance offset (e.g., OMAP4430_PRM_MPU_INST) +* @idx: CONTEXT register offset +* +* Clear hardware context loss bits for the module identified by +* (@part, @inst, @idx). No return value. XXX Writes to reserved bits; +* is there a way to avoid this? +*/ +static void omap44xx_prm_clear_context_loss_flags_old (u8 part,s16 inst, +u16 idx) +{ +omap4_prminst_write_inst_reg (0xffffffff , part, inst, idx); +} +/* Powerdomain low-level functions */ static int omap4_pwrdm_set_next_pwrst (struct powerdomain *pwrdm,u8 pwrst)
@@ -613,6 +644,8 @@ struct pwrdm_ops omap4_pwrdm_operations = {*/ static struct prm_ll_data omap44xx_prm_ll_data = { .read_reset_sources = &omap44xx_prm_read_reset_sources, + .was_any_context_lost_old = &omap44xx_prm_was_any_context_lost_old, + .clear_context_loss_flags_old = &omap44xx_prm_clear_context_loss_flags_old, };int __init omap44xx_prm_init (void )
arch/arm/mach-omap2/prm_common.c +45 -0
51 lines not on this page · raw message
Signature · 1 line
1.7.10.4
PATCH v9 2/8 ARM: OMAP4: PM: add errata support
In reply to Tero KristoAdded similar PM errata flag support as omap3 has. This should be used in similar manner, set the flags during init time, and check the flag values during runtime.
--- arch/arm/mach-omap2/pm.h | 7 +++++++ arch/arm/mach-omap2/pm44xx.c | 1 + 2 files changed, 8 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/pm.h +7 -0
@@ -100,6 +100,13 @@ extern void enable_omap3630_toggle_l2_on_restore(void);static inline void enable_omap3630_toggle_l2_on_restore (void ) { }#endif /* defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP3) */ +#if defined(CONFIG_ARCH_OMAP4 ) +extern u16 pm44xx_errata; +#define IS_PM44XX_ERRATUM (id) (pm44xx_errata & (id)) +#else +#define IS_PM44XX_ERRATUM (id) 0 +#endif +#ifdef CONFIG_POWER_AVS_OMAP extern int omap_devinit_smartreflex (void );extern void omap_enable_smartreflex_on_init (void );
arch/arm/mach-omap2/pm44xx.c +1 -0
@@ -33,6 +33,7 @@ struct power_state { };static LIST_HEAD (pwrst_list); +u16 pm44xx_errata;#ifdef CONFIG_SUSPEND static int omap4_pm_suspend (void )
Signature · 1 line
1.7.4.1
PATCH v9 2/8 ARM: OMAP4: PM: add errata support
Quoted 5 lines · Tero Kristo
Added similar PM errata flag support as omap3 has. This should be used in similar manner, set the flags during init time, and check the flag values during runtime.
Signed-off-by Tero Kristo <[email protected]>
These allow basic suspend/resume to work on 4460/Panda-ES, so I'm going to queue these up as fixes.
However, since they're not technically regressions, it may be too late to get them in for v3.7, but they'll be in for v3.8 for sure.
Kevin
Quoted 35 lines
--- arch/arm/mach-omap2/pm.h | 7 +++++++ arch/arm/mach-omap2/pm44xx.c | 1 + 2 files changed, 8 insertions(+), 0 deletions(-)arch/arm/mach-omap2/pm.h +7
-0@@ -100,6 +100,13 @@ extern void enable_omap3630_toggle_l2_on_restore(void);static inline void enable_omap3630_toggle_l2_on_restore (void ) { }#endif /* defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP3) */ +#if defined(CONFIG_ARCH_OMAP4 ) +extern u16 pm44xx_errata; +#define IS_PM44XX_ERRATUM (id) (pm44xx_errata & (id)) +#else +#define IS_PM44XX_ERRATUM (id) 0 +#endif +#ifdef CONFIG_POWER_AVS_OMAP extern int omap_devinit_smartreflex (void );extern void omap_enable_smartreflex_on_init (void );arch/arm/mach-omap2/pm44xx.c +1
-0@@ -33,6 +33,7 @@ struct power_state { };static LIST_HEAD (pwrst_list); +u16 pm44xx_errata;#ifdef CONFIG_SUSPEND static int omap4_pm_suspend (void )
PATCH v9 2/8 ARM: OMAP4: PM: add errata support
Quoted 6 lines · Kevin Hilman
Quoted 4 lines · Tero Kristo
Added similar PM errata flag support as omap3 has. This should be used in similar manner, set the flags during init time, and check the flag values during runtime.
Quoted 7 lines
Quoted 1 line
Signed-off-by Tero Kristo <[email protected]>These allow basic suspend/resume to work on 4460/Panda-ES, so I'm going to queue these up as fixes.
However, since they're not technically regressions, it may be too late to get them in for v3.7, but they'll be in for v3.8 for sure.
To be more specific, I'm planning on queuing patches 2, 3 and 6 as fixes for v3.8 (branch: for_3.8/fixes/pm).
Paul has already queued patch 1, so that leaves patches 4, 5, 7 & 8.
I think we can get this series in for v3.8 if we drop the functional pwrst dependency. To test, I dropped patches 5 & 7, and tested on 4430/Panda and 4460/Panda-ES (with latest mainline u-boot) and CORE is hitting retention just fine in suspend.
If you can respin patch 8 based on the feedback from Felipe, I'll queue up patches 4 & 8 for v3.8 as well, then we'll at least have CORE retention in suspend in mainline. Then, the rest can be done when functional pwrsts are ready.
Kevin
P.S. do you have any patches to add any OMAP4 CPUidle support for CORE
retention?
Paul has already queued patch 1, and that leaves the
PATCH v9 2/8 ARM: OMAP4: PM: add errata support
Quoted 26 lines · Kevin Hilman
Quoted 6 lines · Kevin Hilman
Quoted 4 lines · Tero Kristo
Added similar PM errata flag support as omap3 has. This should be used in similar manner, set the flags during init time, and check the flag values during runtime.
Quoted 7 lines
Quoted 1 line
Signed-off-by Tero Kristo <[email protected]>These allow basic suspend/resume to work on 4460/Panda-ES, so I'm going to queue these up as fixes.
However, since they're not technically regressions, it may be too late to get them in for v3.7, but they'll be in for v3.8 for sure.
To be more specific, I'm planning on queuing patches 2, 3 and 6 as fixes for v3.8 (branch: for_3.8/fixes/pm).
Paul has already queued patch 1, so that leaves patches 4, 5, 7 & 8.
I think we can get this series in for v3.8 if we drop the functional pwrst dependency. To test, I dropped patches 5 & 7, and tested on 4430/Panda and 4460/Panda-ES (with latest mainline u-boot) and CORE is hitting retention just fine in suspend.
Quoted 4 lines
If you can respin patch 8 based on the feedback from Felipe, I'll queue up patches 4 & 8 for v3.8 as well, then we'll at least have CORE retention in suspend in mainline. Then, the rest can be done when functional pwrsts are ready.
Yea, I can do that on Friday once I get back home, I am travelling currently.
Quoted 5 lines
Kevin
P.S. do you have any patches to add any OMAP4 CPUidle support for CORE
retention?
No, cpuidle core ret should work with this set already. Not sure what happens without the func pwrst patches, I have not tested with that setup lately. I can try this out on Friday as well.
-Tero
PATCH v9 3/8 ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC control register change.
In reply to Tero KristoFrom: Santosh Shilimkar <[email protected]>
On OMAP4+ devices, GIC register context is lost when MPUSS hits the OSWR(Open Switch Retention). On the CPU wakeup path, ROM code gets executed and one of the steps in it is to restore the saved context of the GIC. The ROM Code GIC distributor restoration is split in two parts: CPU specific register done by each CPU and common register done by only one CPU.
Below is the abstract flow.
...............................................................
- MPUSS in OSWR state.
- CPU0 wakes up on the event(interrupt) and start executing ROM code.
[..]
- CPU0 executes "GIC Restoration:"
[...]
- CPU0 swicthes to non-secure mode and jumps to OS resume code.
[...]
- CPU0 is online in OS
- CPU0 enables the GIC distributor. GICD.Enable Non-secure = 1
- CPU0 wakes up CPU1 with clock-domain force wakeup method.
- CPU0 continues it's execution.
[..]
- CPU1 wakes up and start executing ROM code.
[..]
- CPU1 executes "GIC Restoration:"
[..]
- CPU1 swicthes to non-secure mode and jumps to OS resume code.
[...]
- CPU1 is online in OS and start executing.
[...] -
GIC Restoration: /* Common routine for HS and GP devices */ {
if (GICD != 1) { /* This will be true in OSWR state */
if (GIC_SAR_BACKUP_STATE == SAVED)
- CPU restores GIC distributor
else
- reconfigure GIC distributor to boot values.
GICD.Enable secure = 1
}
if (GIC_SAR_BACKUP_STATE == SAVED)
- CPU restore its GIC CPU interface registers if saved.
else
- reconfigure its GIC CPU interface registers to boot values.
}
...............................................................
So as mentioned in the flow, GICD != 1 condition decides how the GIC registers are handled in ROM code wakeup path from OSWR. As evident from the flow, ROM code relies on the entire GICD register value and not specific register bits.
The assumption was valid till CortexA9 r1pX version since there was only one banked bit to control secure and non-secure GICD. Secure view which ROM code sees:
bit 0 == Enable Non-secure
Non-secure view which HLOS sees:
bit 0 == Enable secureBut GICD register has changed between CortexA9 r1pX and r2pX. On r2pX GICD register is composed of 2 bits.
Secure view which ROM code sees:
bit 1 == Enable Non-secure
bit 0 == Enable secure
Non-secure view which HLOS sees:
bit 0 == Enable Non-secureHence on OMAP4460(r2pX) devices, if you go through the above flow again during CPU1 wakeup, GICD == 3 and hence ROM code fails to understand the real wakeup power state and reconfigures GIC distributor to boot values. This is nasty since you loose the entire interrupt controller context in a live system.
The ROM code fix done on next OMAP4 device (OMAP4470 - r2px) is to check "GICD.Enable secure != 1" for GIC restoration in OSWR wakeup path.
Since ROM code can't be fixed on OMAP4460 devices, a work around needs to be implemented. As evident from the flow, as long as CPU1 sees GICD == 1 in it's wakeup path from OSWR, the issue won't happen. Below is the flow with the work-around.
...............................................................
- MPUSS in OSWR state.
- CPU0 wakes up on the event(interrupt) and start executing ROM code.
[..]
- CPU0 executes "GIC Restoration:"
[..]
- CPU0 swicthes to non-secure mode and jumps to OS resume code.
[..]
- CPU0 is online in OS.
- CPU0 does GICD.Enable Non-secure = 0
- CPU0 wakes up CPU1 with clock domain force wakeup method.
- CPU0 waits for GICD.Enable Non-secure = 1
- CPU0 coninues it's execution.
[..]
- CPU1 wakes up and start executing ROM code.
[..]
- CPU1 executes "GIC Restoration:"
[..]
- CPU1 swicthes to non-secure mode and jumps to OS resume code.
[..]
- CPU1 is online in OS
- CPU1 does GICD.Enable Non-secure = 1
- CPU1 start executing
[...]
...............................................................
With this procedure, the GIC configuration done between the CPU0 wakeup and CPU1 wakeup will not be lost but during this short windows, the CPU0 will not receive interrupts.
The BUG is applicable to only OMAP4460(r2pX) devices. OMAP4470 (also r2pX) is not affected by this bug because ROM code has been fixed.
--- arch/arm/mach-omap2/common.h | 2 + arch/arm/mach-omap2/omap-headsmp.S | 38 +++++++++++++++++++++++++++++ arch/arm/mach-omap2/omap-mpuss-lowpower.c | 9 ++++++- arch/arm/mach-omap2/omap-smp.c | 28 ++++++++++++++++++++- arch/arm/mach-omap2/omap4-common.c | 8 +++++- arch/arm/mach-omap2/pm.h | 2 + 6 files changed, 84 insertions(+), 3 deletions(-)
arch/arm/mach-omap2/common.h +2 -0
@@ -275,6 +275,7 @@ static inline void __iomem *omap4_get_scu_base(void)#endif extern void __init gic_init_irq (void ); +extern void gic_dist_disable (void );extern void omap_smc1 (u32 fn,u32 arg);extern void __iomem *omap4_get_sar_ram_base (void );extern void omap_do_wfi (void );
@@ -282,6 +283,7 @@ extern void omap_do_wfi(void);#ifdef CONFIG_SMP /* Needed for secondary core boot */ extern void omap_secondary_startup (void ); +extern void omap_secondary_startup_4460 (void );extern u32 omap_modify_auxcoreboot0 (u32 set_mask,u32 clear_mask);extern void omap_auxcoreboot_addr (u32 cpu_addr);extern u32 omap_read_auxcoreboot0 (void );
arch/arm/mach-omap2/omap-headsmp.S +38 -0
@@ -18,6 +18,8 @@ #include <linux/linkage.h> #include <linux/init.h> +#include "omap44xx.h" + __CPUINIT /* Physical address needed since MMU not enabled yet on secondary core */
@@ -64,3 +66,39 @@ hold: ldr r12,=0x103 b secondary_startup ENDPROC(omap_secondary_startup) +ENTRY(omap_secondary_startup_4460) +hold_2: ldr r12,=0x103 + dsb + smc #0 @ read from AuxCoreBoot0 + mov r0, r0, lsr #9 + mrc p15, 0, r4, c0, c0, 5 + and r4, r4, #0x0f + cmp r0, r4 + bne hold_2 + + /* + * GIC distributor control register has changed between + * CortexA9 r1pX and r2pX. The Control Register secure + * banked version is now composed of 2 bits: + * bit 0 == Secure Enable + * bit 1 == Non-Secure Enable + * The Non-Secure banked register has not changed + * Because the ROM Code is based on the r1pX GIC, the CPU1 + * GIC restoration will cause a problem to CPU0 Non-Secure SW. + * The workaround must be: + * 1) Before doing the CPU1 wakeup, CPU0 must disable + * the GIC distributor + * 2) CPU1 must re-enable the GIC distributor on + * it's wakeup path. + */ + ldr r1, =OMAP44XX_GIC_DIST_BASE + ldr r0, [r1] + orr r0, #1 + str r0, [r1] + + /* + * we've been released from the wait loop,secondary_stack + * should now contain the SVC stack for this core + */ + b secondary_startup +ENDPROC(omap_secondary_startup_4460)
arch/arm/mach-omap2/omap-mpuss-lowpower.c +8 -1
@@ -67,6 +67,7 @@ struct omap4_cpu_pm_info {void __iomem *scu_sar_addr;void __iomem *wkup_sar_addr;void __iomem *l2x0_sar_addr; +void (*secondary_startup)(void ); }; static DEFINE_PER_CPU(struct omap4_cpu_pm_info, omap4_pm_info);
@@ -300,6 +301,7 @@ int omap4_enter_lowpower(unsigned int cpu, unsigned int power_state)int __cpuinit omap4_hotplug_cpu (unsigned int cpu,unsigned int power_state) {unsigned int cpu_state =0 ; +struct omap4_cpu_pm_info *pm_info = &per_cpu (omap4_pm_info, cpu);if (omap_rev () ==OMAP4430_REV_ES1_0 )return -ENXIO ;
@@ -309,7 +311,7 @@ int __cpuinit omap4_hotplug_cpu(unsigned int cpu, unsigned int power_state)clear_cpu_prev_pwrst (cpu);set_cpu_next_pwrst (cpu, power_state); -set_cpu_wakeup_addr (cpu,virt_to_phys (omap_secondary_startup)); +set_cpu_wakeup_addr (cpu,virt_to_phys (pm_info->secondary_startup));scu_pwrst_prepare (cpu, power_state);/*
@@ -360,6 +362,11 @@ int __init omap4_mpuss_init(void) pm_info->scu_sar_addr = sar_base +SCU_OFFSET1 ; pm_info->wkup_sar_addr = sar_base +CPU1_WAKEUP_NS_PA_ADDR_OFFSET ; pm_info->l2x0_sar_addr = sar_base +L2X0_SAVE_OFFSET1 ; +if (cpu_is_omap446x ()) + pm_info->secondary_startup = omap_secondary_startup_4460; +else + pm_info->secondary_startup = omap_secondary_startup; + pm_info->pwrdm =pwrdm_lookup ("cpu1_pwrdm" );if (!pm_info->pwrdm) {pr_err ("Lookup failed for CPU1 pwrdm\n" );
arch/arm/mach-omap2/omap-smp.c +27 -1
@@ -32,6 +32,7 @@#include "iomap.h" #include "common.h" #include "clockdomain.h" +#include "pm.h" #define CPU_MASK 0xff0ffff0#define CPU_CORTEX_A9 0x410FC090
@@ -118,6 +119,24 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct ** 4.3.4.2 Power States of CPU0 and CPU1 */ if (booted) { +/* +* GIC distributor control register has changed between +* CortexA9 r1pX and r2pX. The Control Register secure +* banked version is now composed of 2 bits: +* bit 0 == Secure Enable +* bit 1 == Non-Secure Enable +* The Non-Secure banked register has not changed +* Because the ROM Code is based on the r1pX GIC, the CPU1 +* GIC restoration will cause a problem to CPU0 Non-Secure SW. +* The workaround must be: +* 1) Before doing the CPU1 wakeup, CPU0 must disable +* the GIC distributor +* 2) CPU1 must re-enable the GIC distributor on +* it's wakeup path. +*/ +if (IS_PM44XX_ERRATUM (PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD )) +gic_dist_disable (); +clkdm_wakeup (cpu1_clkdm);clkdm_allow_idle (cpu1_clkdm); }else {
@@ -138,7 +157,14 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *static void __init wakeup_secondary (void ) { +void *startup_addr = omap_secondary_startup;void __iomem *base =omap_get_wakeupgen_base (); + +if (cpu_is_omap446x ()) { + startup_addr = omap_secondary_startup_4460; + pm44xx_errata |=PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD ; + } +/* * Write the address of secondary startup routine into the * AuxCoreBoot1 where ROM code will jump and start executing
@@ -146,7 +172,7 @@ static void __init wakeup_secondary(void)* A barrier is added to ensure that write buffer is drained */ if (omap_secure_apis_support ()) -omap_auxcoreboot_addr (virt_to_phys (omap_secondary_startup)); +omap_auxcoreboot_addr (virt_to_phys (startup_addr));else __raw_writel (virt_to_phys (omap5_secondary_startup), base +OMAP_AUX_CORE_BOOT_1 );
arch/arm/mach-omap2/omap4-common.c +7 -1
@@ -41,6 +41,7 @@ static void __iomem *l2cache_base;#endif static void __iomem *sar_ram_base; +static void __iomem *gic_dist_base_addr;#ifdef CONFIG_OMAP4_ERRATA_I688 /* Used to implement memory barrier on DRAM path */
@@ -95,7 +96,6 @@ void __init omap_barriers_init(void)void __init gic_init_irq (void ) {void __iomem *omap_irq_base; -void __iomem *gic_dist_base_addr;/* Static mapping, never released */ gic_dist_base_addr =ioremap (OMAP44XX_GIC_DIST_BASE ,SZ_4K );
@@ -110,6 +110,12 @@ void __init gic_init_irq(void)gic_init (0 ,29 , gic_dist_base_addr, omap_irq_base); } +void gic_dist_disable (void ) +{ +if (gic_dist_base_addr) +__raw_writel (0x0 , gic_dist_base_addr +GIC_DIST_CTRL ); +} +#ifdef CONFIG_CACHE_L2X0 void __iomem *omap4_get_l2cache_base (void )
arch/arm/mach-omap2/pm.h +2 -0
@@ -100,6 +100,8 @@ extern void enable_omap3630_toggle_l2_on_restore(void);static inline void enable_omap3630_toggle_l2_on_restore (void ) { }#endif /* defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP3) */ +#define PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD (1 << 0) +#if defined(CONFIG_ARCH_OMAP4 )extern u16 pm44xx_errata;#define IS_PM44XX_ERRATUM (id) (pm44xx_errata & (id))
Signature · 1 line
1.7.4.1
PATCH v9 4/8 ARM: OMAP4: suspend: Program all domains to retention
In reply to Tero KristoFrom: Rajendra Nayak <[email protected]>
Remove the FIXME's in the suspend sequence since we now intend to support system level RET support.
--- arch/arm/mach-omap2/pm44xx.c | 7 ------- 1 files changed, 0 insertions(+), 7 deletions(-)
arch/arm/mach-omap2/pm44xx.c +0 -7
@@ -95,13 +95,6 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)if (!strncmp (pwrdm->name,"cpu" ,3 ))return 0 ; -/* -* FIXME: Remove this check when core retention is supported -* Only MPUSS power domain is added in the list. -*/ -if (strcmp (pwrdm->name,"mpu_pwrdm" )) -return 0 ; - pwrst =kmalloc (sizeof (struct power_state ),GFP_ATOMIC );if (!pwrst)return -ENOMEM ;
Signature · 1 line
1.7.4.1
PATCH v9 5/8 ARM: OMAP4: PM: put all domains to OSWR during suspend
In reply to Tero KristoCurrently OMAP4 suspend puts all power domains to CSWR. OSWR is a deeper state that saves more power, but has higher latencies also. As suspend is considered a high-latency operation, OSWR is appropriate here.
--- arch/arm/mach-omap2/pm44xx.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
arch/arm/mach-omap2/pm44xx.c +1 -1
@@ -100,7 +100,7 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)return -ENOMEM ; pwrst->pwrdm = pwrdm; - pwrst->next_state =PWRDM_FUNC_PWRST_CSWR ; + pwrst->next_state =PWRDM_FUNC_PWRST_OSWR ;list_add (&pwrst->node, &pwrst_list);return pwrdm_set_fpwrst (pwrst->pwrdm, pwrst->next_state);
Signature · 1 line
1.7.4.1
PATCH v9 6/8 ARM: OMAP4: retrigger localtimers after re-enabling gic
In reply to Tero KristoFrom: Colin Cross <[email protected]>
'Workaround for ROM bug because of CA9 r2pX gic control' register change disables the gic distributor while the secondary cpu is being booted. If a localtimer interrupt on the primary cpu occurs when the distributor is turned off, the interrupt is lost, and the localtimer never fires again.
Make the primary cpu wait for the secondary cpu to reenable the gic distributor (with interrupts off for safety), and then check if the pending bit is set in the localtimer but not the gic. If so, ack it in the localtimer, and reset the timer with the minimum timeout to trigger a new timer interrupt.
[t-kristo at ti.com: dropped generic ARM kernel exports from the code, rebased
to mainline]
--- arch/arm/mach-omap2/common.h | 2 ++ arch/arm/mach-omap2/omap-smp.c | 13 ++++++++++++- arch/arm/mach-omap2/omap4-common.c | 34 ++++++++++++++++++++++++++++++++++ 3 files changed, 48 insertions(+), 1 deletions(-)
arch/arm/mach-omap2/common.h +2 -0
@@ -276,6 +276,8 @@ static inline void __iomem *omap4_get_scu_base(void)extern void __init gic_init_irq (void );extern void gic_dist_disable (void ); +extern bool gic_dist_disabled (void ); +extern void gic_timer_retrigger (void );extern void omap_smc1 (u32 fn,u32 arg);extern void __iomem *omap4_get_sar_ram_base (void );extern void omap_do_wfi (void );
arch/arm/mach-omap2/omap-smp.c +12 -1
@@ -134,11 +134,22 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct ** 2) CPU1 must re-enable the GIC distributor on * it's wakeup path. */ -if (IS_PM44XX_ERRATUM (PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD )) +if (IS_PM44XX_ERRATUM (PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD )) { +local_irq_disable ();gic_dist_disable (); + }clkdm_wakeup (cpu1_clkdm);clkdm_allow_idle (cpu1_clkdm); + +if (IS_PM44XX_ERRATUM (PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD )) { +while (gic_dist_disabled ()) { +udelay (1 ); +cpu_relax (); + } +gic_timer_retrigger (); +local_irq_enable (); + } }else {dsb_sev (); booted = true;
arch/arm/mach-omap2/omap4-common.c +34 -0
@@ -14,6 +14,7 @@#include <linux/kernel.h> #include <linux/init.h> #include <linux/io.h> +#include <linux/irq.h> #include <linux/platform_device.h> #include <linux/memblock.h> #include <linux/of_irq.h>
@@ -24,6 +25,7 @@#include <asm/hardware/cache-l2x0.h> #include <asm/mach/map.h> #include <asm/memblock.h> +#include <asm/smp_twd.h> #include <plat/sram.h> #include <plat/omap-secure.h>
@@ -42,6 +44,9 @@ static void __iomem *l2cache_base;static void __iomem *sar_ram_base;static void __iomem *gic_dist_base_addr; +static void __iomem *twd_base; + +#define IRQ_LOCALTIMER 29#ifdef CONFIG_OMAP4_ERRATA_I688 /* Used to implement memory barrier on DRAM path */
@@ -101,6 +106,9 @@ void __init gic_init_irq(void) gic_dist_base_addr =ioremap (OMAP44XX_GIC_DIST_BASE ,SZ_4K );BUG_ON (!gic_dist_base_addr); + twd_base =ioremap (OMAP44XX_LOCAL_TWD_BASE ,SZ_4K ); +BUG_ON (!twd_base); +/* Static mapping, never released */ omap_irq_base =ioremap (OMAP44XX_GIC_CPU_BASE ,SZ_512 );BUG_ON (!omap_irq_base);
@@ -116,6 +124,32 @@ void gic_dist_disable(void)__raw_writel (0x0 , gic_dist_base_addr +GIC_DIST_CTRL ); } +bool gic_dist_disabled (void ) +{ +return !(__raw_readl (gic_dist_base_addr +GIC_DIST_CTRL ) &0x1 ); +} + +void gic_timer_retrigger (void ) +{ +u32 twd_int =__raw_readl (twd_base +TWD_TIMER_INTSTAT ); +u32 gic_int =__raw_readl (gic_dist_base_addr +GIC_DIST_PENDING_SET ); +u32 twd_ctrl =__raw_readl (twd_base +TWD_TIMER_CONTROL ); + +if (twd_int && !(gic_int &BIT (IRQ_LOCALTIMER ))) { +/* +* The local timer interrupt got lost while the distributor was +* disabled. Ack the pending interrupt, and retrigger it. +*/ +pr_warn ("%s: lost localtimer interrupt\n" , __func__); +__raw_writel (1 , twd_base +TWD_TIMER_INTSTAT ); +if (!(twd_ctrl &TWD_TIMER_CONTROL_PERIODIC )) { +__raw_writel (1 , twd_base +TWD_TIMER_COUNTER ); + twd_ctrl |=TWD_TIMER_CONTROL_ENABLE ; +__raw_writel (twd_ctrl, twd_base +TWD_TIMER_CONTROL ); + } + } +} +#ifdef CONFIG_CACHE_L2X0 void __iomem *omap4_get_l2cache_base (void )
Signature · 1 line
1.7.4.1
Paul Walmsley
maintainerPATCH v9 6/8 ARM: OMAP4: retrigger localtimers after re-enabling gic
Hi
Quoted 7 lines · Tero Kristo
From: Colin Cross <[email protected]>
'Workaround for ROM bug because of CA9 r2pX gic control' register change disables the gic distributor while the secondary cpu is being booted. If a localtimer interrupt on the primary cpu occurs when the distributor is turned off, the interrupt is lost, and the localtimer never fires again.
Looks like this one should go in separately via Tony.
- Paul
PATCH v9 6/8 ARM: OMAP4: retrigger localtimers after re-enabling gic
In reply to Tero KristoQuoted 4 lines · Tero Kristo
From: Colin Cross <[email protected]>
'Workaround for ROM bug because of CA9 r2pX gic control' register change disables the gic distributor while the secondary
Just to clarify: this is referring to PATCH 3/8 of this series, correct?
Kevin
PATCH v9 6/8 ARM: OMAP4: retrigger localtimers after re-enabling gic
Quoted 9 lines · Kevin Hilman
Quoted 4 lines · Tero Kristo
From: Colin Cross <[email protected]>
'Workaround for ROM bug because of CA9 r2pX gic control' register change disables the gic distributor while the secondary
Just to clarify: this is referring to PATCH 3/8 of this series, correct?
Yes.
-Tero
PATCH v9 7/8 ARM: OMAP: PM: update target fpwrst to what pwrdm can reach
In reply to Tero KristoAs the code within pwrdm_set_fpwrst is updating powerstate and logic states according to powerdomain capabilities, it may alter the target fpwrst also. Update the target fpwrst status according to these checks, otherwise rest of the code in this function will malfunction.
--- arch/arm/mach-omap2/powerdomain.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/powerdomain.c +3 -0
@@ -711,6 +711,9 @@ int pwrdm_set_fpwrst(struct powerdomain *pwrdm, enum pwrdm_func_state fpwrst)return -EINVAL ; } +/* Refresh target fprwst according to what we can reach */ + fpwrst =_pwrdm_pwrst_to_fpwrst (pwrdm, pwrst, logic); +pr_debug ("%s: set fpwrst %0x to pwrdm %s\n" , __func__, fpwrst, pwrdm->name);
Signature · 1 line
1.7.4.1
PATCH v9 8/8 ARM: OMAP4: USB: power down MUSB PHY if not used
In reply to Tero KristoCommit c9e4412ab8eb8ef82d645d8749c4ce96ad490007 removed all of the USB PHY functions for OMAP4, but this causes a problem with core retention as the MUSB module remains enabled if omap-usb2 phy driver is not used. This keeps the USB DPLL enabled and prevents l3_init pwrdm from idling.
Fixed by adding a minimal function back that disables the USB PHY in case omap-usb2 driver is not used.
--- arch/arm/mach-omap2/omap_phy_internal.c | 27 +++++++++++++++++++++++++++ 1 files changed, 27 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/omap_phy_internal.c +27 -0
@@ -33,6 +33,33 @@#include "soc.h" #include "control.h" +#define CONTROL_DEV_CONF 0x300 +#define PHY_PD 0x1 + +#ifndef CONFIG_OMAP_USB2 +static int __init omap4430_phy_power_down (void ) +{ +void __iomem *ctrl_base; + +if (!cpu_is_omap44xx ()) +return 0 ; + + ctrl_base =ioremap (OMAP443X_SCM_BASE ,SZ_1K ); +if (!ctrl_base) { +pr_err ("control module ioremap failed\n" ); +return -ENOMEM ; + } + +/* Power down the phy */ +__raw_writel (PHY_PD , ctrl_base +CONTROL_DEV_CONF ); + +iounmap (ctrl_base); + +return 0 ; +} +early_initcall (omap4430_phy_power_down); +#endif +void am35x_musb_reset (void ) {u32 regval;
Signature · 1 line
1.7.4.1
PATCH v9 8/8 ARM: OMAP4: USB: power down MUSB PHY if not used
Hi,
Quoted 21 lines · Tero Kristo
Commit
c9e4412ab8eb8ef82d645d8749c4ce96ad490007removed all of the USB PHY functions for OMAP4, but this causes a problem with core retention as the MUSB module remains enabled if omap-usb2 phy driver is not used. This keeps the USB DPLL enabled and preventsl3_initpwrdm from idling.Fixed by adding a minimal function back that disables the USB PHY in case omap-usb2 driver is not used.
Signed-off-by Tero Kristo <[email protected]>Cc Kishon Vijay Abraham I <[email protected]>Cc Felipe Balbi <[email protected]>Cc Tony Lindgren <[email protected]>--- arch/arm/mach-omap2/omap_phy_internal.c | 27 +++++++++++++++++++++++++++ 1 files changed, 27 insertions(+), 0 deletions(-)arch/arm/mach-omap2/omap_phy_internal.c +0
-0
arch/arm/mach-omap2/omap_phy_internal.c line 39
Quoted 7 lines
arch/arm/mach-omap2/omap_phy_internal.c +4
-0@@ -33,6 +33,33 @@#include "soc.h" #include "control.h" +#define CONTROL_DEV_CONF 0x300 +#define PHY_PD 0x1 + +#ifndef CONFIG_OMAP_USB2
this is a tristate, meaning that can be a module.
Quoted 12 lines
arch/arm/mach-omap2/omap_phy_internal.c +12
-0+static int __init omap4430_phy_power_down (void ) +{ +void __iomem *ctrl_base; + +if (!cpu_is_omap44xx ()) +return 0 ; + + ctrl_base =ioremap (OMAP443X_SCM_BASE ,SZ_1K ); +if (!ctrl_base) { +pr_err ("control module ioremap failed\n" ); +return -ENOMEM ; + }
arch/arm/mach-omap2/omap_phy_internal.c line 61
Quoted 10 lines
arch/arm/mach-omap2/omap_phy_internal.c +10
-0+ +/* Power down the phy */ +__raw_writel (PHY_PD , ctrl_base +CONTROL_DEV_CONF ); + +iounmap (ctrl_base); + + return 0; +} +early_initcall (omap4430_phy_power_down); +#endif
I think you could do it even if the driver is enabled.
Just to make sure I understand the issue right: is the PHY enabled by default or did bootloader left this enabled ?
Signature · 8 lines
balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121018/7b28c5a5/attachment.sig>
PATCH v9 8/8 ARM: OMAP4: USB: power down MUSB PHY if not used
Quoted 27 lines · Felipe Balbi
Hi,
Quoted 24 lines · Tero Kristo
Commit
c9e4412ab8eb8ef82d645d8749c4ce96ad490007removed all of the USB PHY functions for OMAP4, but this causes a problem with core retention as the MUSB module remains enabled if omap-usb2 phy driver is not used. This keeps the USB DPLL enabled and preventsl3_initpwrdm from idling.Fixed by adding a minimal function back that disables the USB PHY in case omap-usb2 driver is not used.
Signed-off-by Tero Kristo <[email protected]>Cc Kishon Vijay Abraham I <[email protected]>Cc Felipe Balbi <[email protected]>Cc Tony Lindgren <[email protected]>--- arch/arm/mach-omap2/omap_phy_internal.c | 27 +++++++++++++++++++++++++++ 1 files changed, 27 insertions(+), 0 deletions(-)arch/arm/mach-omap2/omap_phy_internal.c +0
-0@@ -33,6 +33,33 @@#include "soc.h" #include "control.h"
Quoted 6 lines
arch/arm/mach-omap2/omap_phy_internal.c line 39
Quoted 4 lines
arch/arm/mach-omap2/omap_phy_internal.c +4
-0+#define CONTROL_DEV_CONF 0x300 +#define PHY_PD 0x1 + +#ifndef CONFIG_OMAP_USB2 this is a tristate, meaning that can be a module.
Ok, so extra check for that needed.
Quoted 17 lines
Quoted 17 lines
arch/arm/mach-omap2/omap_phy_internal.c +16
-0+static int __init omap4430_phy_power_down (void ) +{ +void __iomem *ctrl_base; + +if (!cpu_is_omap44xx ()) +return 0 ; + + ctrl_base =ioremap (OMAP443X_SCM_BASE ,SZ_1K ); +if (!ctrl_base) { +pr_err ("control module ioremap failed\n" ); +return -ENOMEM ; + } + +/* Power down the phy */ +__raw_writel (PHY_PD , ctrl_base +CONTROL_DEV_CONF ); +
Quoted 8 lines
arch/arm/mach-omap2/omap_phy_internal.c line 61
Quoted 6 lines
arch/arm/mach-omap2/omap_phy_internal.c +6
-0+iounmap (ctrl_base); + + return 0; +} +early_initcall (omap4430_phy_power_down); +#endif I think you could do it even if the driver is enabled.
Actually not at least now, it looks like the driver is not controlling this bit at all, so the driver would fail if we do this.
Quoted 3 lines
Just to make sure I understand the issue right: is the PHY enabled by default or did bootloader left this enabled ?
The reset value for the register is zero (at least according to TRM), so it is enabled from boot. Also, I couldn't find any code from the u-boot that would touch this bit with a quick look.
-Tero
PATCH v9 8/8 ARM: OMAP4: USB: power down MUSB PHY if not used
hi,
Quoted 25 lines · Tero Kristo
Quoted 16 lines
Quoted 16 lines
arch/arm/mach-omap2/omap_phy_internal.c +16
-0+static int __init omap4430_phy_power_down (void ) +{ +void __iomem *ctrl_base; + +if (!cpu_is_omap44xx ()) +return 0 ; + + ctrl_base =ioremap (OMAP443X_SCM_BASE ,SZ_1K ); +if (!ctrl_base) { +pr_err ("control module ioremap failed\n" ); +return -ENOMEM ; + } + +/* Power down the phy */ +__raw_writel (PHY_PD , ctrl_base +CONTROL_DEV_CONF ); +Quoted 8 lines
arch/arm/mach-omap2/omap_phy_internal.c line 61
Quoted 6 lines
arch/arm/mach-omap2/omap_phy_internal.c +6
-0+iounmap (ctrl_base); + + return 0; +} +early_initcall (omap4430_phy_power_down); +#endif I think you could do it even if the driver is enabled.
Quoted 2 lines
Actually not at least now, it looks like the driver is not controlling this bit at all, so the driver would fail if we do this.
then we can consider that a bug in the driver. Kishon, I thought you had added SCM address space to PHY driver for this particular reason until we get SCM driver, wasn't it ??
Quoted 6 lines
Quoted 2 lines
Just to make sure I understand the issue right: is the PHY enabled by default or did bootloader left this enabled ?
The reset value for the register is zero (at least according to TRM), so it is enabled from boot. Also, I couldn't find any code from the u-boot that would touch this bit with a quick look.
ok, so it looks like we must do this anyway, thanks ;-)
Signature · 8 lines
balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121018/51556c03/attachment.sig>
PATCH v9 8/8 ARM: OMAP4: USB: power down MUSB PHY if not used
Quoted 28 lines · Felipe Balbi
hi,
Quoted 25 lines · Tero Kristo
Quoted 24 lines
Quoted 12 lines
arch/arm/mach-omap2/omap_phy_internal.c +12
-0+static int __init omap4430_phy_power_down (void ) +{ +void __iomem *ctrl_base; + +if (!cpu_is_omap44xx ()) +return 0 ; + + ctrl_base =ioremap (OMAP443X_SCM_BASE ,SZ_1K ); +if (!ctrl_base) { +pr_err ("control module ioremap failed\n" ); +return -ENOMEM ; + }arch/arm/mach-omap2/omap_phy_internal.c line 61
Quoted 10 lines
arch/arm/mach-omap2/omap_phy_internal.c +10
-0+ +/* Power down the phy */ +__raw_writel (PHY_PD , ctrl_base +CONTROL_DEV_CONF ); + +iounmap (ctrl_base); + + return 0; +} +early_initcall (omap4430_phy_power_down); +#endif I think you could do it even if the driver is enabled.
Quoted 6 lines
Quoted 2 lines
Actually not at least now, it looks like the driver is not controlling this bit at all, so the driver would fail if we do this.
then we can consider that a bug in the driver. Kishon, I thought you had added SCM address space to PHY driver for this particular reason until we get SCM driver, wasn't it ??
Yes, I would say its a bug in the driver. However we need this disable mechanism for the case where we don't have the driver also (which is the default config for omap.)
-Tero
Quoted 9 lines
Quoted 6 lines
Quoted 2 lines
Just to make sure I understand the issue right: is the PHY enabled by default or did bootloader left this enabled ?
The reset value for the register is zero (at least according to TRM), so it is enabled from boot. Also, I couldn't find any code from the u-boot that would touch this bit with a quick look.
ok, so it looks like we must do this anyway, thanks ;-)
PATCH v9 8/8 ARM: OMAP4: USB: power down MUSB PHY if not used
Quoted 32 lines · Tero Kristo
Quoted 31 lines · Felipe Balbi
hi,
Quoted 27 lines · Tero Kristo
Quoted 16 lines
Quoted 16 lines
arch/arm/mach-omap2/omap_phy_internal.c +16
-0+static int __init omap4430_phy_power_down (void ) +{ +void __iomem *ctrl_base; + +if (!cpu_is_omap44xx ()) +return 0 ; + + ctrl_base =ioremap (OMAP443X_SCM_BASE ,SZ_1K ); +if (!ctrl_base) { +pr_err ("control module ioremap failed\n" ); +return -ENOMEM ; + } + +/* Power down the phy */ +__raw_writel (PHY_PD , ctrl_base +CONTROL_DEV_CONF ); +Quoted 8 lines
arch/arm/mach-omap2/omap_phy_internal.c line 61
Quoted 6 lines
arch/arm/mach-omap2/omap_phy_internal.c +6
-0+iounmap (ctrl_base); + + return 0; +} +early_initcall (omap4430_phy_power_down); +#endif I think you could do it even if the driver is enabled.
Actually not at least now, it looks like the driver is not controlling this bit at all, so the driver would fail if we do this.
Quoted 7 lines
Quoted 3 lines
then we can consider that a bug in the driver. Kishon, I thought you had added SCM address space to PHY driver for this particular reason until we get SCM driver, wasn't it ??
Yes, I would say its a bug in the driver. However we need this disable mechanism for the case where we don't have the driver also (which is the default config for omap.)
sure, of course. But I'd like to see it unconditionally done, meaning that there needs to be a counterpart in the driver to make sure you can run this unconditionally during early phases of boot up ;-)
Signature · 8 lines
balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121018/e5a68533/attachment.sig>
PATCH v9 8/8 ARM: OMAP4: USB: power down MUSB PHY if not used
In reply to Tero KristoHi,
Quoted 29 lines · Tero Kristo
Quoted 28 lines · Felipe Balbi
hi,
Quoted 25 lines · Tero Kristo
Quoted 24 lines
Quoted 12 lines
arch/arm/mach-omap2/omap_phy_internal.c +12
-0+static int __init omap4430_phy_power_down (void ) +{ +void __iomem *ctrl_base; + +if (!cpu_is_omap44xx ()) +return 0 ; + + ctrl_base =ioremap (OMAP443X_SCM_BASE ,SZ_1K ); +if (!ctrl_base) { +pr_err ("control module ioremap failed\n" ); +return -ENOMEM ; + }arch/arm/mach-omap2/omap_phy_internal.c line 61
Quoted 10 lines
arch/arm/mach-omap2/omap_phy_internal.c +10
-0+ +/* Power down the phy */ +__raw_writel (PHY_PD , ctrl_base +CONTROL_DEV_CONF ); + +iounmap (ctrl_base); + + return 0; +} +early_initcall (omap4430_phy_power_down); +#endif I think you could do it even if the driver is enabled.
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
Actually not at least now, it looks like the driver is not controlling this bit at all, so the driver would fail if we do this.
then we can consider that a bug in the driver. Kishon, I thought you had added SCM address space to PHY driver for this particular reason until we get SCM driver, wasn't it ??
Yes, I would say its a bug in the driver.
No. It's done in the driver (omap_usb_phy_power() in drivers/usb/phy/omap-usb2.c). We explicitly power off the phy during probe in the driver.
However we need this disable
Quoted 2 lines
mechanism for the case where we don't have the driver also (which is the default config for omap.)
Agree.
Thanks
Kishon
PATCH v9 8/8 ARM: OMAP4: USB: power down MUSB PHY if not used
Quoted 39 lines · kishon
Hi,
Quoted 36 lines · Tero Kristo
Quoted 34 lines · Felipe Balbi
hi,
Quoted 25 lines · Tero Kristo
Quoted 16 lines
Quoted 16 lines
arch/arm/mach-omap2/omap_phy_internal.c +16
-0+static int __init omap4430_phy_power_down (void ) +{ +void __iomem *ctrl_base; + +if (!cpu_is_omap44xx ()) +return 0 ; + + ctrl_base =ioremap (OMAP443X_SCM_BASE ,SZ_1K ); +if (!ctrl_base) { +pr_err ("control module ioremap failed\n" ); +return -ENOMEM ; + } + +/* Power down the phy */ +__raw_writel (PHY_PD , ctrl_base +CONTROL_DEV_CONF ); +Quoted 8 lines
arch/arm/mach-omap2/omap_phy_internal.c line 61
Quoted 6 lines
arch/arm/mach-omap2/omap_phy_internal.c +6
-0+iounmap (ctrl_base); + + return 0; +} +early_initcall (omap4430_phy_power_down); +#endif I think you could do it even if the driver is enabled.
Quoted 2 lines
Actually not at least now, it looks like the driver is not controlling this bit at all, so the driver would fail if we do this.
then we can consider that a bug in the driver. Kishon, I thought you had added SCM address space to PHY driver for this particular reason until we get SCM driver, wasn't it ??
Quoted 5 lines
Quoted 1 line
Yes, I would say its a bug in the driver.
No. It's done in the driver (
omap_usb_phy_power()indrivers/usb/phy/omap-usb2.c). We explicitly power off the phy during probe in the driver.
so you also handle enabling the IP later when you need ? That's great, it means we can do the above unconditionally, driver enabled or not.
Signature · 8 lines
balbi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121022/927ddcc6/attachment-0001.sig>
PATCH v9 8/8 ARM: OMAP4: USB: power down MUSB PHY if not used
Hi,
Quoted 40 lines · Felipe Balbi
Quoted 39 lines · kishon
Hi,
Quoted 36 lines · Tero Kristo
Quoted 34 lines · Felipe Balbi
hi,
Quoted 25 lines · Tero Kristo
Quoted 16 lines
Quoted 16 lines
(quoted diff) +16
-0+static int __init omap4430_phy_power_down(void) +{ + void __iomem *ctrl_base; + + if (!cpu_is_omap44xx()) + return 0; + + ctrl_base = ioremap(OMAP443X_SCM_BASE, SZ_1K); + if (!ctrl_base) { + pr_err("control module ioremap failed\n"); + return -ENOMEM; + } + + /* Power down the phy */ + __raw_writel(PHY_PD, ctrl_base + CONTROL_DEV_CONF); +Quoted 8 lines
Review
Quoted 6 lines
(quoted diff) +6
-0+ iounmap(ctrl_base); + + return 0; +} +early_initcall(omap4430_phy_power_down); +#endifI think you could do it even if the driver is enabled.
Quoted 2 lines
Actually not at least now, it looks like the driver is not controlling this bit at all, so the driver would fail if we do this.
then we can consider that a bug in the driver. Kishon, I thought you had added SCM address space to PHY driver for this particular reason until we get SCM driver, wasn't it ??
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
Yes, I would say its a bug in the driver.
No. It's done in the driver (
omap_usb_phy_power()indrivers/usb/phy/omap-usb2.c). We explicitly power off the phy during probe in the driver.so you also handle enabling the IP later when you need ? That's great, it means we can do the above unconditionally, driver enabled or not.
yes.
Thanks
Kishon
Paul Walmsley
maintainerPATCH v9 8/8 ARM: OMAP4: USB: power down MUSB PHY if not used
In reply to Tero KristoHi
Quoted 5 lines · Tero Kristo
Commit
c9e4412ab8eb8ef82d645d8749c4ce96ad490007removed all of the USB PHY functions for OMAP4, but this causes a problem with core retention as the MUSB module remains enabled if omap-usb2 phy driver is not used. This keeps the USB DPLL enabled and preventsl3_initpwrdm from idling.
Quoted 7 lines
Fixed by adding a minimal function back that disables the USB PHY in case omap-usb2 driver is not used.
Signed-off-by Tero Kristo <[email protected]>Cc Kishon Vijay Abraham I <[email protected]>Cc Felipe Balbi <[email protected]>Cc Tony Lindgren <[email protected]>
Looks like another one for Tony...
- Paul
Paul Walmsley
maintainerv9 cover ARM: OMAP4: core retention support
In reply to Tero KristoHi Tero, Kevin,
Quoted 4 lines · Tero Kristo
Changes compared to previous version:
- rebased on top of 3.7-rc1
- applies on top of latest func pwrst code (v6)
- added back patch #1 to this set (it wasn't queued yet after all)
That's because there was an interaction between it and the omap-serial changes in the last merge window that caused several failures :-( Hopefully it's good to go now...
Quoted 10 lines
- added patch #7 for fixing a bug in the functional pwrst code
- added patch #8 for fixing a regression with MUSB PHY power handling (not quite sure if this is the correct way to fix this or not)Tested with omap4460 gp panda + omap4430 emu blaze boards, with cpuidle + suspend.
Branch also available here:
git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
branch: mainline-3.7-rc1-omap4-ret-v9
Looks like only patches #5 and #7 have dependencies on Jean's functional powerstate series, so those should be postponed until that rework is complete. Looks like #6 and #8 should go in via Tony, assuming there are no dependencies on the rest of the patches. Have just queued #1 for 3.8 and kicked off a test to ensure that everything is working.
As far as the rest go, Kevin, do you want to take them?
- Paul
v9 cover ARM: OMAP4: core retention support
In reply to Tero KristoHi Tero,
Quoted 10 lines · Tero Kristo
Hi,
Changes compared to previous version:
- rebased on top of 3.7-rc1
- applies on top of latest func pwrst code (v6)
- added back patch #1 to this set (it wasn't queued yet after all)
- added patch #7 for fixing a bug in the functional pwrst code
- added patch #8 for fixing a regression with MUSB PHY power handling (not quite sure if this is the correct way to fix this or not)
Quoted 6 lines
Tested with omap4460 gp panda + omap4430 emu blaze boards, with cpuidle + suspend.
Branch also available here:
git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
branch: mainline-3.7-rc1-omap4-ret-v9
I tested this branch on 4430/Panda and 4460/Panda-ES and I'm seeing several domains not hitting target power state in suspend[1].
Am I missing some other fixes? Using omap2plus_defconfig, I tried your branch alone, and merged with v3.7-rc4, and I get the same errors.
Kevin
[1]
# echo enabled > /sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup # echo mem > /sys/power/state [ 102.271087] PM: Syncing filesystems ... done. [ 102.282196] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 102.312133] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 102.343353] Suspending console(s) (use no_console_suspend to debug) ?[ 102.363433] PM: suspend of devices complete after 10.650 msecs [ 102.365631] PM: late suspend of devices complete after 2.166 msecs [ 102.369201] PM: noirq suspend of devices complete after 3.509 msecs [ 102.369232] Disabling non-boot CPUs ... [ 102.373016] CPU1: shutdown [ 104.357421] Powerdomain (core_pwrdm) didn't enter target state 1 [ 104.357452] Powerdomain (tesla_pwrdm) didn't enter target state 1 [ 104.357452] Powerdomain (ivahd_pwrdm) didn't enter target state 1 [ 104.357482] Powerdomain (l3init_pwrdm) didn't enter target state 1 [ 104.357482] Could not enter target state in pm_suspend [ 104.357666] Enabling non-boot CPUs ... [ 104.359863] CPU1: Booted secondary processor [ 104.360626] cpu cpu0: opp_init_cpufreq_table: Device OPP not found (-19) [ 104.360656] cpu cpu0: omap_cpu_init: cpu1: failed creating freq table[-19] [ 104.360656] CPU1 is up [ 104.362579] PM: noirq resume of devices complete after 1.892 msecs [ 104.364807] PM: early resume of devices complete after 1.373 msecs [ 104.710937] PM: resume of devices complete after 346.099 msecs [ 104.817901] Restarting tasks ... done.
v9 cover ARM: OMAP4: core retention support
Hi Kevin,
Quoted 47 lines · Kevin Hilman
Hi Tero,
Quoted 10 lines · Tero Kristo
Hi,
Changes compared to previous version:
- rebased on top of 3.7-rc1
- applies on top of latest func pwrst code (v6)
- added back patch #1 to this set (it wasn't queued yet after all)
- added patch #7 for fixing a bug in the functional pwrst code
- added patch #8 for fixing a regression with MUSB PHY power handling (not quite sure if this is the correct way to fix this or not)Quoted 6 lines
Tested with omap4460 gp panda + omap4430 emu blaze boards, with cpuidle + suspend.
Branch also available here:
git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
branch: mainline-3.7-rc1-omap4-ret-v9I tested this branch on 4430/Panda and 4460/Panda-ES and I'm seeing several domains not hitting target power state in suspend[1].
Am I missing some other fixes? Using
omap2plus_defconfig, I tried your branch alone, and merged with v3.7-rc4, and I get the same errors.Kevin
[1]
# echo enabled > /sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup # echo mem > /sys/power/state [ 102.271087] PM: Syncing filesystems ... done. [ 102.282196] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 102.312133] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 102.343353] Suspending console(s) (use no_console_suspend to debug) ?[ 102.363433] PM: suspend of devices complete after 10.650 msecs [ 102.365631] PM: late suspend of devices complete after 2.166 msecs [ 102.369201] PM: noirq suspend of devices complete after 3.509 msecs [ 102.369232] Disabling non-boot CPUs ... [ 102.373016] CPU1: shutdown [ 104.357421] Powerdomain (core_pwrdm) didn't enter target state 1 [ 104.357452] Powerdomain (tesla_pwrdm) didn't enter target state 1 [ 104.357452] Powerdomain (ivahd_pwrdm) didn't enter target state 1 [ 104.357482] Powerdomain (l3init_pwrdm) didn't enter target state 1 [ 104.357482] Could not enter target state in pm_suspend [ 104.357666] Enabling non-boot CPUs ...
Quoted 8 lines
[ 104.359863] CPU1: Booted secondary processor [ 104.360626] cpu cpu0: opp_init_cpufreq_table: Device OPP not found (-19) [ 104.360656] cpu cpu0: omap_cpu_init: cpu1: failed creating freq table[-19] [ 104.360656] CPU1 is up [ 104.362579] PM: noirq resume of devices complete after 1.892 msecs [ 104.364807] PM: early resume of devices complete after 1.373 msecs [ 104.710937] PM: resume of devices complete after 346.099 msecs [ 104.817901] Restarting tasks ... done.
This looks like a combination of boot loader/kernel problems. My guess is that l3init is probably held on by the USB, and both ivahd / tesla are held on by some DSP/IVA modules which are not idling properly.
The last patch in this set should fix the USB problems at least partially, but also the USB DPLL itself might be in wrong state, attached patch might help for that one and get l3init to idle.
For DSP I don't have a patch right now, what is the boot loader you are using? (Can you provide git / commit / config info?)
-Tero
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-ARM-OMAP4-clock-setup-USB-DPLL-during-init.patch
Type: text/x-patch
Size: 1199 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121106/aa09bad8/attachment.bin>
v9 cover ARM: OMAP4: core retention support
Quoted 29 lines · Tero Kristo
Hi Kevin,
Quoted 26 lines · Kevin Hilman
Hi Tero,
Quoted 10 lines · Tero Kristo
Hi,
Changes compared to previous version:
- rebased on top of 3.7-rc1
- applies on top of latest func pwrst code (v6)
- added back patch #1 to this set (it wasn't queued yet after all)
- added patch #7 for fixing a bug in the functional pwrst code
- added patch #8 for fixing a regression with MUSB PHY power handling (not quite sure if this is the correct way to fix this or not)Quoted 6 lines
Tested with omap4460 gp panda + omap4430 emu blaze boards, with cpuidle + suspend.
Branch also available here:
git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
branch: mainline-3.7-rc1-omap4-ret-v9I tested this branch on 4430/Panda and 4460/Panda-ES and I'm seeing several domains not hitting target power state in suspend[1].
Am I missing some other fixes? Using
omap2plus_defconfig, I tried your branch alone, and merged with v3.7-rc4, and I get the same errors.
[...]
Quoted 10 lines
This looks like a combination of boot loader/kernel problems. My guess is that l3init is probably held on by the USB, and both ivahd / tesla are held on by some DSP/IVA modules which are not idling properly.
The last patch in this set should fix the USB problems at least partially, but also the USB DPLL itself might be in wrong state, attached patch might help for that one and get l3init to idle.
For DSP I don't have a patch right now, what is the boot loader you are using? (Can you provide git / commit / config info?)
I was using mainline u-boot at tag v2012.04.01 when I saw the errors.
To check the bootloader, I upgraded to the latest mainline tag (v2012.10) and the problems are gone on both 4430/Panda and
4460/Panda-ES... Interesting.
That suggests that there's still some kernel assumptions/dependencies on the bootloader that need to be addressed.
Kevin
v9 cover ARM: OMAP4: core retention support
Quoted 45 lines · Kevin Hilman
Quoted 29 lines · Tero Kristo
Hi Kevin,
Quoted 26 lines · Kevin Hilman
Hi Tero,
Quoted 10 lines · Tero Kristo
Hi,
Changes compared to previous version:
- rebased on top of 3.7-rc1
- applies on top of latest func pwrst code (v6)
- added back patch #1 to this set (it wasn't queued yet after all)
- added patch #7 for fixing a bug in the functional pwrst code
- added patch #8 for fixing a regression with MUSB PHY power handling (not quite sure if this is the correct way to fix this or not)Quoted 6 lines
Tested with omap4460 gp panda + omap4430 emu blaze boards, with cpuidle + suspend.
Branch also available here:
git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
branch: mainline-3.7-rc1-omap4-ret-v9I tested this branch on 4430/Panda and 4460/Panda-ES and I'm seeing several domains not hitting target power state in suspend[1].
Am I missing some other fixes? Using
omap2plus_defconfig, I tried your branch alone, and merged with v3.7-rc4, and I get the same errors.[...]
Quoted 10 lines
This looks like a combination of boot loader/kernel problems. My guess is that l3init is probably held on by the USB, and both ivahd / tesla are held on by some DSP/IVA modules which are not idling properly.
The last patch in this set should fix the USB problems at least partially, but also the USB DPLL itself might be in wrong state, attached patch might help for that one and get l3init to idle.
For DSP I don't have a patch right now, what is the boot loader you are using? (Can you provide git / commit / config info?)
Quoted 8 lines
I was using mainline u-boot at tag v2012.04.01 when I saw the errors.
To check the bootloader, I upgraded to the latest mainline tag (v2012.10) and the problems are gone on both 4430/Panda and
4460/Panda-ES... Interesting.That suggests that there's still some kernel assumptions/dependencies on the bootloader that need to be addressed.
I am not surprised of that, the all so common bootloader madness hits again. Anyway, I can try with the bootloader tag you used hopefully next week and see if I can figure out something. The l3init problem can probably be fixed rather easily if it is because of the USB, but the tesla / ivahd might be more problematic... last time I saw that problem I wasn't able to recover from the situation without power on reset... bootloader took the tesla out of reset and it seemed impossible to put it back to idle after that. I tried resetting the DSP but it didn't help. Also, I didn't find a bootmode register similar to what omap3 has.
-Tero
v9 cover ARM: OMAP4: core retention support
In reply to Kevin HilmanQuoted 45 lines · Kevin Hilman
Quoted 29 lines · Tero Kristo
Hi Kevin,
Quoted 26 lines · Kevin Hilman
Hi Tero,
Quoted 10 lines · Tero Kristo
Hi,
Changes compared to previous version:
- rebased on top of 3.7-rc1
- applies on top of latest func pwrst code (v6)
- added back patch #1 to this set (it wasn't queued yet after all)
- added patch #7 for fixing a bug in the functional pwrst code
- added patch #8 for fixing a regression with MUSB PHY power handling (not quite sure if this is the correct way to fix this or not)Quoted 6 lines
Tested with omap4460 gp panda + omap4430 emu blaze boards, with cpuidle + suspend.
Branch also available here:
git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
branch: mainline-3.7-rc1-omap4-ret-v9I tested this branch on 4430/Panda and 4460/Panda-ES and I'm seeing several domains not hitting target power state in suspend[1].
Am I missing some other fixes? Using
omap2plus_defconfig, I tried your branch alone, and merged with v3.7-rc4, and I get the same errors.[...]
Quoted 10 lines
This looks like a combination of boot loader/kernel problems. My guess is that l3init is probably held on by the USB, and both ivahd / tesla are held on by some DSP/IVA modules which are not idling properly.
The last patch in this set should fix the USB problems at least partially, but also the USB DPLL itself might be in wrong state, attached patch might help for that one and get l3init to idle.
For DSP I don't have a patch right now, what is the boot loader you are using? (Can you provide git / commit / config info?)
Quoted 8 lines
I was using mainline u-boot at tag v2012.04.01 when I saw the errors.
To check the bootloader, I upgraded to the latest mainline tag (v2012.10) and the problems are gone on both 4430/Panda and
4460/Panda-ES... Interesting.That suggests that there's still some kernel assumptions/dependencies on the bootloader that need to be addressed.
After a little bit of looking into this, this is pretty similar to what I was working on quite a while back once I tried to get the core ret work with mainline kernel. I ended up sending patches against the boot-loader as there wasn't a readily visible solution to some of the issues on kernel side => so now if you update the u-boot, it gets fixed.
I am seeing (at least) following subsystems being non-idle with the old bootloader:
- M3 cortex (stuck in transition)
- DSP (stuck in transition)
- SL2IF (stuck in transition)
- FSUSB (stuck in transition)
...but I am not aware of any way to get these to working properly from this state without POR. Some of them probably require firmware to be loaded and letting them out of reset also (M3 / DSP.) Benoit, do you have any clues?
-Tero
v9 cover ARM: OMAP4: core retention support
Quoted 52 lines · Tero Kristo
Quoted 51 lines · Kevin Hilman
Quoted 29 lines · Tero Kristo
Hi Kevin,
Quoted 26 lines · Kevin Hilman
Hi Tero,
Quoted 10 lines · Tero Kristo
Hi,
Changes compared to previous version:
- rebased on top of 3.7-rc1
- applies on top of latest func pwrst code (v6)
- added back patch #1 to this set (it wasn't queued yet after all)
- added patch #7 for fixing a bug in the functional pwrst code
- added patch #8 for fixing a regression with MUSB PHY power handling (not quite sure if this is the correct way to fix this or not)Quoted 6 lines
Tested with omap4460 gp panda + omap4430 emu blaze boards, with cpuidle + suspend.
Branch also available here:
git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
branch: mainline-3.7-rc1-omap4-ret-v9I tested this branch on 4430/Panda and 4460/Panda-ES and I'm seeing several domains not hitting target power state in suspend[1].
Am I missing some other fixes? Using
omap2plus_defconfig, I tried your branch alone, and merged with v3.7-rc4, and I get the same errors.[...]
Quoted 10 lines
This looks like a combination of boot loader/kernel problems. My guess is that l3init is probably held on by the USB, and both ivahd / tesla are held on by some DSP/IVA modules which are not idling properly.
The last patch in this set should fix the USB problems at least partially, but also the USB DPLL itself might be in wrong state, attached patch might help for that one and get l3init to idle.
For DSP I don't have a patch right now, what is the boot loader you are using? (Can you provide git / commit / config info?)
I was using mainline u-boot at tag v2012.04.01 when I saw the errors.
To check the bootloader, I upgraded to the latest mainline tag (v2012.10) and the problems are gone on both 4430/Panda and
4460/Panda-ES... Interesting.
Quoted 8 lines
Quoted 2 lines
That suggests that there's still some kernel assumptions/dependencies on the bootloader that need to be addressed.
After a little bit of looking into this, this is pretty similar to what I was working on quite a while back once I tried to get the core ret work with mainline kernel. I ended up sending patches against the boot-loader as there wasn't a readily visible solution to some of the issues on kernel side => so now if you update the u-boot, it gets fixed.
Yes, recent u-boots have become much more sane in what they initialze. Now, there is a bare set of "essential" clocks/pads that are configured, so that probably explains why things work better with a sane bootloader.
Kevin
Quoted 13 lines
I am seeing (at least) following subsystems being non-idle with the old bootloader:
- M3 cortex (stuck in transition)
- DSP (stuck in transition)
- SL2IF (stuck in transition)
- FSUSB (stuck in transition)...but I am not aware of any way to get these to working properly from this state without POR. Some of them probably require firmware to be loaded and letting them out of reset also (M3 / DSP.) Benoit, do you have any clues?
-Tero
Paul Walmsley
maintainerv9 cover ARM: OMAP4: core retention support
In reply to Kevin HilmanHi,
Quoted 10 lines · Kevin Hilman
# echo mem > /sys/power/state [ 102.271087] PM: Syncing filesystems ... done. [ 102.282196] Freezing user space processes ... (elapsed 0.02 seconds) done. [ 102.312133] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done. [ 102.343353] Suspending console(s) (use no_console_suspend to debug) ???[ 102.363433] PM: suspend of devices complete after 10.650 msecs [ 102.365631] PM: late suspend of devices complete after 2.166 msecs [ 102.369201] PM: noirq suspend of devices complete after 3.509 msecs [ 102.369232] Disabling non-boot CPUs ... [ 102.373016] CPU1: shutdown
[...]
By the way, looks like you're seeing the same garbage character generated as I was on v3.6 with these patches. It's the first character of the line that's dated "102.363433". At 230kbps, it comes across as a "5" that the OMAP thinks originates from the host computer, sent to the Panda.
Would be useful if someone could identify what's causing this. None of the OMAP3 boards currently exhibit this behavior. Would na?vely assume that the OMAP4 is waking up fast enough to capture some of the bits of the serial wakeup character, but have not confirmed this.
- Paul