[PATCHv9 0/8] ARM: OMAP4: core retention support

[PATCHv9 0/8] ARM: OMAP4: core retention support

[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)

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

[PATCHv9 0/8] ARM: OMAP4: core retention support

[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)

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

[PATCHv9 1/8] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count

[Tero Kristo]

From: Rajendra Nayak <rnayak@ti.com>

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.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@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@ti.com: added support for arch specific hwmod ops, and changed
 the no context offset indicator to USHRT_MAX]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[paul@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]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
 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(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index b969ab1..d810f85 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -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");
 	}
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index b3349f7..8590f62 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -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;
 };
 
 
-- 
1.7.4.1

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

[PATCHv9 1/8] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count

[Tero Kristo]

From: Rajendra Nayak <rnayak@ti.com>

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.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[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]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[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]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
 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(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index b969ab1..d810f85 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -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");
 	}
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index b3349f7..8590f62 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -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;
 };
 
 
-- 
1.7.4.1

[PATCHv9 2/8] ARM: OMAP4: PM: add errata support

[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 <t-kristo@ti.com>
---
 arch/arm/mach-omap2/pm.h     |    7 +++++++
 arch/arm/mach-omap2/pm44xx.c |    1 +
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 707e9cb..f26f2d7 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -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);
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index ba06300..07e7ef2 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -33,6 +33,7 @@ struct power_state {
 };
 
 static LIST_HEAD(pwrst_list);
+u16 pm44xx_errata;
 
 #ifdef CONFIG_SUSPEND
 static int omap4_pm_suspend(void)
-- 
1.7.4.1

[PATCHv9 2/8] ARM: OMAP4: PM: add errata support

[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 <t-kristo@ti.com>
---
 arch/arm/mach-omap2/pm.h     |    7 +++++++
 arch/arm/mach-omap2/pm44xx.c |    1 +
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 707e9cb..f26f2d7 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -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);
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index ba06300..07e7ef2 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -33,6 +33,7 @@ struct power_state {
 };
 
 static LIST_HEAD(pwrst_list);
+u16 pm44xx_errata;
 
 #ifdef CONFIG_SUSPEND
 static int omap4_pm_suspend(void)
-- 
1.7.4.1

[PATCHv9 3/8] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC control register change.

[Tero Kristo]

From: Santosh Shilimkar <santosh.shilimkar@ti.com>

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 secure

But 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-secure

Hence 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.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 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(-)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 7045e4d..70993a9 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -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);
diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S
index 502e313..0ea09fa 100644
--- a/arch/arm/mach-omap2/omap-headsmp.S
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -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)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 13c1249..562fd38 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -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");
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 4d05fa8..7d9c0e3 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -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);
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index e1f2897..72cf396 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -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)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index f26f2d7..bee3911 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -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))
-- 
1.7.4.1

[PATCHv9 3/8] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX GIC control register change.

[Tero Kristo]

From: Santosh Shilimkar <santosh.shilimkar@ti.com>

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 secure

But 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-secure

Hence 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.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 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(-)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 7045e4d..70993a9 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -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);
diff --git a/arch/arm/mach-omap2/omap-headsmp.S b/arch/arm/mach-omap2/omap-headsmp.S
index 502e313..0ea09fa 100644
--- a/arch/arm/mach-omap2/omap-headsmp.S
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -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)
diff --git a/arch/arm/mach-omap2/omap-mpuss-lowpower.c b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
index 13c1249..562fd38 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -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");
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 4d05fa8..7d9c0e3 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -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);
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index e1f2897..72cf396 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -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)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index f26f2d7..bee3911 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -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))
-- 
1.7.4.1

[PATCHv9 4/8] ARM: OMAP4: suspend: Program all domains to retention

[Tero Kristo]

From: Rajendra Nayak <rnayak@ti.com>

Remove the FIXME's in the suspend sequence since
we now intend to support system level RET support.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/mach-omap2/pm44xx.c |    7 -------
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 07e7ef2..a313165 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -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;
-- 
1.7.4.1

[PATCHv9 4/8] ARM: OMAP4: suspend: Program all domains to retention

[Tero Kristo]

From: Rajendra Nayak <rnayak@ti.com>

Remove the FIXME's in the suspend sequence since
we now intend to support system level RET support.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/mach-omap2/pm44xx.c |    7 -------
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 07e7ef2..a313165 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -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;
-- 
1.7.4.1

[PATCHv9 5/8] ARM: OMAP4: PM: put all domains to OSWR during suspend

[Tero Kristo]

Currently 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.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/mach-omap2/pm44xx.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index a313165..d36e4e5 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -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);
-- 
1.7.4.1

[PATCHv9 5/8] ARM: OMAP4: PM: put all domains to OSWR during suspend

[Tero Kristo]

Currently 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.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/mach-omap2/pm44xx.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index a313165..d36e4e5 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -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);
-- 
1.7.4.1

[PATCHv9 6/8] ARM: OMAP4: retrigger localtimers after re-enabling gic

[Tero Kristo]

From: Colin Cross <ccross@android.com>

'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.

Signed-off-by: Colin Cross <ccross@android.com>
[s-jan@ti.com: adapted to k3.4 + validated functionality]
Signed-off-by: Sebastien Jan <s-jan@ti.com>
[t-kristo@ti.com: dropped generic ARM kernel exports from the code, rebased
 to mainline]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 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(-)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 70993a9..d29dbaa 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -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);
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 7d9c0e3..49a08df 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -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;
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index 72cf396..6f94b4e 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -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)
-- 
1.7.4.1

[PATCHv9 6/8] ARM: OMAP4: retrigger localtimers after re-enabling gic

[Tero Kristo]

From: Colin Cross <ccross@android.com>

'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.

Signed-off-by: Colin Cross <ccross@android.com>
[s-jan at ti.com: adapted to k3.4 + validated functionality]
Signed-off-by: Sebastien Jan <s-jan@ti.com>
[t-kristo at ti.com: dropped generic ARM kernel exports from the code, rebased
 to mainline]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 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(-)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 70993a9..d29dbaa 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -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);
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 7d9c0e3..49a08df 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -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;
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index 72cf396..6f94b4e 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -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)
-- 
1.7.4.1

[PATCHv9 7/8] ARM: OMAP: PM: update target fpwrst to what pwrdm can reach

[Tero Kristo]

As 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.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/mach-omap2/powerdomain.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c
index f5786b4..f92a867 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -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);
 
-- 
1.7.4.1

[PATCHv9 7/8] ARM: OMAP: PM: update target fpwrst to what pwrdm can reach

[Tero Kristo]

As 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.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/mach-omap2/powerdomain.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c
index f5786b4..f92a867 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -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);
 
-- 
1.7.4.1

[PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used

[Tero Kristo]

Commit 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.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/omap_phy_internal.c |   27 +++++++++++++++++++++++++++
 1 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_phy_internal.c b/arch/arm/mach-omap2/omap_phy_internal.c
index d992db8..6a4b9cf 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -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;
-- 
1.7.4.1

[PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used

[Tero Kristo]

Commit 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.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
---
 arch/arm/mach-omap2/omap_phy_internal.c |   27 +++++++++++++++++++++++++++
 1 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_phy_internal.c b/arch/arm/mach-omap2/omap_phy_internal.c
index d992db8..6a4b9cf 100644
--- a/arch/arm/mach-omap2/omap_phy_internal.c
+++ b/arch/arm/mach-omap2/omap_phy_internal.c
@@ -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;
-- 
1.7.4.1

Re: [PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1943 bytes --]

Hi,

On Thu, Oct 18, 2012 at 12:20:10PM +0300, Tero Kristo wrote:
> Commit 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.
> 
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> ---
>  arch/arm/mach-omap2/omap_phy_internal.c |   27 +++++++++++++++++++++++++++
>  1 files changed, 27 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_phy_internal.c b/arch/arm/mach-omap2/omap_phy_internal.c
> index d992db8..6a4b9cf 100644
> --- a/arch/arm/mach-omap2/omap_phy_internal.c
> +++ b/arch/arm/mach-omap2/omap_phy_internal.c
> @@ -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.

> +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

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 ?

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used

[Felipe Balbi]

Hi,

On Thu, Oct 18, 2012 at 12:20:10PM +0300, Tero Kristo wrote:
> Commit 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.
> 
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>
> ---
>  arch/arm/mach-omap2/omap_phy_internal.c |   27 +++++++++++++++++++++++++++
>  1 files changed, 27 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_phy_internal.c b/arch/arm/mach-omap2/omap_phy_internal.c
> index d992db8..6a4b9cf 100644
> --- a/arch/arm/mach-omap2/omap_phy_internal.c
> +++ b/arch/arm/mach-omap2/omap_phy_internal.c
> @@ -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.

> +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

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 ?

-- 
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>

Re: [PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used

[Tero Kristo]

On Thu, 2012-10-18 at 13:33 +0300, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Oct 18, 2012 at 12:20:10PM +0300, Tero Kristo wrote:
> > Commit 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.
> > 
> > Signed-off-by: Tero Kristo <t-kristo@ti.com>
> > Cc: Kishon Vijay Abraham I <kishon@ti.com>
> > Cc: Felipe Balbi <balbi@ti.com>
> > Cc: Tony Lindgren <tony@atomide.com>
> > ---
> >  arch/arm/mach-omap2/omap_phy_internal.c |   27 +++++++++++++++++++++++++++
> >  1 files changed, 27 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/mach-omap2/omap_phy_internal.c b/arch/arm/mach-omap2/omap_phy_internal.c
> > index d992db8..6a4b9cf 100644
> > --- a/arch/arm/mach-omap2/omap_phy_internal.c
> > +++ b/arch/arm/mach-omap2/omap_phy_internal.c
> > @@ -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.

Ok, so extra check for that needed.

> 
> > +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
> 
> 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.

> 
> 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

[PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used

[Tero Kristo]

On Thu, 2012-10-18 at 13:33 +0300, Felipe Balbi wrote:
> Hi,
> 
> On Thu, Oct 18, 2012 at 12:20:10PM +0300, Tero Kristo wrote:
> > Commit 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.
> > 
> > Signed-off-by: Tero Kristo <t-kristo@ti.com>
> > Cc: Kishon Vijay Abraham I <kishon@ti.com>
> > Cc: Felipe Balbi <balbi@ti.com>
> > Cc: Tony Lindgren <tony@atomide.com>
> > ---
> >  arch/arm/mach-omap2/omap_phy_internal.c |   27 +++++++++++++++++++++++++++
> >  1 files changed, 27 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/mach-omap2/omap_phy_internal.c b/arch/arm/mach-omap2/omap_phy_internal.c
> > index d992db8..6a4b9cf 100644
> > --- a/arch/arm/mach-omap2/omap_phy_internal.c
> > +++ b/arch/arm/mach-omap2/omap_phy_internal.c
> > @@ -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.

Ok, so extra check for that needed.

> 
> > +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
> 
> 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.

> 
> 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

Re: [PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]

hi,

On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
> > > +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
> > 
> > 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.

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 ??

> > 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 ;-)

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used

[Felipe Balbi]

hi,

On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
> > > +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
> > 
> > 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.

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 ??

> > 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 ;-)

-- 
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>

Re: [PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used

[Tero Kristo]

On Thu, 2012-10-18 at 16:53 +0300, Felipe Balbi wrote:
> hi,
> 
> On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
> > > > +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
> > > 
> > > 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.
> 
> 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

> > > 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 ;-)
> 

[PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used

[Tero Kristo]

On Thu, 2012-10-18 at 16:53 +0300, Felipe Balbi wrote:
> hi,
> 
> On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
> > > > +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
> > > 
> > > 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.
> 
> 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

> > > 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 ;-)
> 

Re: [PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1702 bytes --]

On Thu, Oct 18, 2012 at 05:39:59PM +0300, Tero Kristo wrote:
> On Thu, 2012-10-18 at 16:53 +0300, Felipe Balbi wrote:
> > hi,
> > 
> > On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
> > > > > +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
> > > > 
> > > > 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.
> > 
> > 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 ;-)

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used

[Felipe Balbi]

On Thu, Oct 18, 2012 at 05:39:59PM +0300, Tero Kristo wrote:
> On Thu, 2012-10-18 at 16:53 +0300, Felipe Balbi wrote:
> > hi,
> > 
> > On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
> > > > > +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
> > > > 
> > > > 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.
> > 
> > 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 ;-)

-- 
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>

Re: [PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used

[kishon]

Hi,

On Thursday 18 October 2012 08:09 PM, Tero Kristo wrote:
> On Thu, 2012-10-18 at 16:53 +0300, Felipe Balbi wrote:
>> hi,
>>
>> On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
>>>>> +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
>>>>
>>>> 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.
>>
>> 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
> mechanism for the case where we don't have the driver also (which is the
> default config for omap.)

Agree.

Thanks
Kishon

[PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used

[kishon]

Hi,

On Thursday 18 October 2012 08:09 PM, Tero Kristo wrote:
> On Thu, 2012-10-18 at 16:53 +0300, Felipe Balbi wrote:
>> hi,
>>
>> On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
>>>>> +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
>>>>
>>>> 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.
>>
>> 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
> mechanism for the case where we don't have the driver also (which is the
> default config for omap.)

Agree.

Thanks
Kishon

Re: [PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1657 bytes --]

On Mon, Oct 22, 2012 at 02:24:30PM +0530, kishon wrote:
> Hi,
> 
> On Thursday 18 October 2012 08:09 PM, Tero Kristo wrote:
> >On Thu, 2012-10-18 at 16:53 +0300, Felipe Balbi wrote:
> >>hi,
> >>
> >>On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
> >>>>>+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
> >>>>
> >>>>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.
> >>
> >>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.

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.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used

[Felipe Balbi]

On Mon, Oct 22, 2012 at 02:24:30PM +0530, kishon wrote:
> Hi,
> 
> On Thursday 18 October 2012 08:09 PM, Tero Kristo wrote:
> >On Thu, 2012-10-18 at 16:53 +0300, Felipe Balbi wrote:
> >>hi,
> >>
> >>On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
> >>>>>+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
> >>>>
> >>>>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.
> >>
> >>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.

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.

-- 
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>

Re: [PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used

[kishon]

Hi,

On Monday 22 October 2012 02:37 PM, Felipe Balbi wrote:
> On Mon, Oct 22, 2012 at 02:24:30PM +0530, kishon wrote:
>> Hi,
>>
>> On Thursday 18 October 2012 08:09 PM, Tero Kristo wrote:
>>> On Thu, 2012-10-18 at 16:53 +0300, Felipe Balbi wrote:
>>>> hi,
>>>>
>>>> On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
>>>>>>> +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
>>>>>>
>>>>>> 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.
>>>>
>>>> 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.
>
> 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

[PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used

[kishon]

Hi,

On Monday 22 October 2012 02:37 PM, Felipe Balbi wrote:
> On Mon, Oct 22, 2012 at 02:24:30PM +0530, kishon wrote:
>> Hi,
>>
>> On Thursday 18 October 2012 08:09 PM, Tero Kristo wrote:
>>> On Thu, 2012-10-18 at 16:53 +0300, Felipe Balbi wrote:
>>>> hi,
>>>>
>>>> On Thu, Oct 18, 2012 at 03:18:04PM +0300, Tero Kristo wrote:
>>>>>>> +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
>>>>>>
>>>>>> 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.
>>>>
>>>> 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.
>
> 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

Re: [PATCHv9 6/8] ARM: OMAP4: retrigger localtimers after re-enabling gic

[Paul Walmsley]

Hi

On Thu, 18 Oct 2012, Tero Kristo wrote:

> From: Colin Cross <ccross@android.com>
> 
> '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

[PATCHv9 6/8] ARM: OMAP4: retrigger localtimers after re-enabling gic

[Paul Walmsley]

Hi

On Thu, 18 Oct 2012, Tero Kristo wrote:

> From: Colin Cross <ccross@android.com>
> 
> '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

Re: [PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used

[Paul Walmsley]

Hi

On Thu, 18 Oct 2012, Tero Kristo wrote:

> Commit 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.
> 
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>

Looks like another one for Tony...

- Paul

[PATCHv9 8/8] ARM: OMAP4: USB: power down MUSB PHY if not used

[Paul Walmsley]

Hi

On Thu, 18 Oct 2012, Tero Kristo wrote:

> Commit 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.
> 
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> Cc: Felipe Balbi <balbi@ti.com>
> Cc: Tony Lindgren <tony@atomide.com>

Looks like another one for Tony...

- Paul

Re: [PATCHv9 1/8] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count

[Paul Walmsley]

Hi,

On Thu, 18 Oct 2012, Tero Kristo wrote:

> From: Rajendra Nayak <rnayak@ti.com>
> 
> 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.
> 
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> [paul@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@ti.com: added support for arch specific hwmod ops, and changed
>  the no context offset indicator to USHRT_MAX]
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> [paul@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]
> Signed-off-by: Paul Walmsley <paul@pwsan.com>

Thanks, re-queued for 3.8.

- Paul

[PATCHv9 1/8] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count

[Paul Walmsley]

Hi,

On Thu, 18 Oct 2012, Tero Kristo wrote:

> From: Rajendra Nayak <rnayak@ti.com>
> 
> 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.
> 
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> [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]
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> [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]
> Signed-off-by: Paul Walmsley <paul@pwsan.com>

Thanks, re-queued for 3.8.

- Paul

Re: [PATCHv9 0/8] ARM: OMAP4: core retention support

[Paul Walmsley]

Hi Tero, Kevin,

On Thu, 18 Oct 2012, Tero Kristo wrote:

> 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...

> - 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

[PATCHv9 0/8] ARM: OMAP4: core retention support

[Paul Walmsley]

Hi Tero, Kevin,

On Thu, 18 Oct 2012, Tero Kristo wrote:

> 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...

> - 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

Re: [PATCHv9 0/8] ARM: OMAP4: core retention support

[Kevin Hilman]

Hi Tero,

Tero Kristo <t-kristo@ti.com> writes:

> 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

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv9 0/8] ARM: OMAP4: core retention support

[Kevin Hilman]

Hi Tero,

Tero Kristo <t-kristo@ti.com> writes:

> 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

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.

Re: [PATCHv9 6/8] ARM: OMAP4: retrigger localtimers after re-enabling gic

[Kevin Hilman]

Tero Kristo <t-kristo@ti.com> writes:

> From: Colin Cross <ccross@android.com>
>
> '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

[PATCHv9 6/8] ARM: OMAP4: retrigger localtimers after re-enabling gic

[Kevin Hilman]

Tero Kristo <t-kristo@ti.com> writes:

> From: Colin Cross <ccross@android.com>
>
> '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

Re: [PATCHv9 2/8] ARM: OMAP4: PM: add errata support

[Kevin Hilman]

Tero Kristo <t-kristo@ti.com> writes:

> 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 <t-kristo@ti.com>

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


> ---
>  arch/arm/mach-omap2/pm.h     |    7 +++++++
>  arch/arm/mach-omap2/pm44xx.c |    1 +
>  2 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> index 707e9cb..f26f2d7 100644
> --- a/arch/arm/mach-omap2/pm.h
> +++ b/arch/arm/mach-omap2/pm.h
> @@ -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);
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> index ba06300..07e7ef2 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm44xx.c
> @@ -33,6 +33,7 @@ struct power_state {
>  };
>  
>  static LIST_HEAD(pwrst_list);
> +u16 pm44xx_errata;
>  
>  #ifdef CONFIG_SUSPEND
>  static int omap4_pm_suspend(void)

[PATCHv9 2/8] ARM: OMAP4: PM: add errata support

[Kevin Hilman]

Tero Kristo <t-kristo@ti.com> writes:

> 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 <t-kristo@ti.com>

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


> ---
>  arch/arm/mach-omap2/pm.h     |    7 +++++++
>  arch/arm/mach-omap2/pm44xx.c |    1 +
>  2 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
> index 707e9cb..f26f2d7 100644
> --- a/arch/arm/mach-omap2/pm.h
> +++ b/arch/arm/mach-omap2/pm.h
> @@ -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);
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> index ba06300..07e7ef2 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm44xx.c
> @@ -33,6 +33,7 @@ struct power_state {
>  };
>  
>  static LIST_HEAD(pwrst_list);
> +u16 pm44xx_errata;
>  
>  #ifdef CONFIG_SUSPEND
>  static int omap4_pm_suspend(void)

Re: [PATCHv9 6/8] ARM: OMAP4: retrigger localtimers after re-enabling gic

[Tero Kristo]

On Mon, 2012-11-05 at 14:25 -0800, Kevin Hilman wrote:
> Tero Kristo <t-kristo@ti.com> writes:
> 
> > From: Colin Cross <ccross@android.com>
> >
> > '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

[PATCHv9 6/8] ARM: OMAP4: retrigger localtimers after re-enabling gic

[Tero Kristo]

On Mon, 2012-11-05 at 14:25 -0800, Kevin Hilman wrote:
> Tero Kristo <t-kristo@ti.com> writes:
> 
> > From: Colin Cross <ccross@android.com>
> >
> > '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

Re: [PATCHv9 0/8] ARM: OMAP4: core retention support

[Tero Kristo]

[-- Attachment #1: Type: text/plain, Size: 3182 bytes --]

Hi Kevin,

On Mon, 2012-11-05 at 14:23 -0800, Kevin Hilman wrote:
> Hi Tero,
> 
> Tero Kristo <t-kristo@ti.com> writes:
> 
> > 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
> 
> 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.

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


[-- Attachment #2: 0003-ARM-OMAP4-clock-setup-USB-DPLL-during-init.patch --]
[-- Type: text/x-patch, Size: 1199 bytes --]

>From 2bde02977db605822ee83042ebc0077ba133277e Mon Sep 17 00:00:00 2001
From: Tero Kristo <t-kristo@ti.com>
Date: Thu, 21 Jun 2012 14:56:40 +0300
Subject: [PATCH 3/7] ARM: OMAP4: clock: setup USB DPLL during init

The reset setup for USB DPLL does not allow idle, thus the kernel must
program it during init. This puts the USB DPLL in locked mode, autoidle
for it is enabled automatically later during the boot sequence.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/mach-omap2/clock44xx_data.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/clock44xx_data.c b/arch/arm/mach-omap2/clock44xx_data.c
index e2b701e..e28950a 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3413,6 +3413,7 @@ int __init omap4xxx_clk_init(void)
 {
 	struct omap_clk *c;
 	u32 cpu_clkflg;
+	struct clk *dpll_usb;
 
 	if (cpu_is_omap443x()) {
 		cpu_mask = RATE_IN_4430;
@@ -3456,5 +3457,12 @@ int __init omap4xxx_clk_init(void)
 	 */
 	clk_enable_init_clocks();
 
+	/*
+	 * Setup USB DPLL
+	 */
+	dpll_usb = clk_get(NULL, "dpll_usb_ck");
+
+	clk_set_rate(dpll_usb, 960000000);
+
 	return 0;
 }
-- 
1.7.4.1

[PATCHv9 0/8] ARM: OMAP4: core retention support

[Tero Kristo]

Hi Kevin,

On Mon, 2012-11-05 at 14:23 -0800, Kevin Hilman wrote:
> Hi Tero,
> 
> Tero Kristo <t-kristo@ti.com> writes:
> 
> > 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
> 
> 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.

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>

Re: [PATCHv9 0/8] ARM: OMAP4: core retention support

[Kevin Hilman]

Tero Kristo <t-kristo@ti.com> writes:

> Hi Kevin,
>
> On Mon, 2012-11-05 at 14:23 -0800, Kevin Hilman wrote:
>> Hi Tero,
>> 
>> Tero Kristo <t-kristo@ti.com> writes:
>> 
>> > 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
>> 
>> 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.

[...]

> 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

[PATCHv9 0/8] ARM: OMAP4: core retention support

[Kevin Hilman]

Tero Kristo <t-kristo@ti.com> writes:

> Hi Kevin,
>
> On Mon, 2012-11-05 at 14:23 -0800, Kevin Hilman wrote:
>> Hi Tero,
>> 
>> Tero Kristo <t-kristo@ti.com> writes:
>> 
>> > 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
>> 
>> 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.

[...]

> 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

Re: [PATCHv9 2/8] ARM: OMAP4: PM: add errata support

[Kevin Hilman]

Kevin Hilman <khilman@deeprootsystems.com> writes:

> Tero Kristo <t-kristo@ti.com> writes:
>
>> 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 <t-kristo@ti.com>
>
> 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 

[PATCHv9 2/8] ARM: OMAP4: PM: add errata support

[Kevin Hilman]

Kevin Hilman <khilman@deeprootsystems.com> writes:

> Tero Kristo <t-kristo@ti.com> writes:
>
>> 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 <t-kristo@ti.com>
>
> 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 

Re: [PATCHv9 2/8] ARM: OMAP4: PM: add errata support

[Tero Kristo]

On Tue, 2012-11-06 at 13:52 -0800, Kevin Hilman wrote:
> Kevin Hilman <khilman@deeprootsystems.com> writes:
> 
> > Tero Kristo <t-kristo@ti.com> writes:
> >
> >> 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 <t-kristo@ti.com>
> >
> > 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.

Yea, I can do that on Friday once I get back home, I am travelling
currently.

> 
> 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

[PATCHv9 2/8] ARM: OMAP4: PM: add errata support

[Tero Kristo]

On Tue, 2012-11-06 at 13:52 -0800, Kevin Hilman wrote:
> Kevin Hilman <khilman@deeprootsystems.com> writes:
> 
> > Tero Kristo <t-kristo@ti.com> writes:
> >
> >> 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 <t-kristo@ti.com>
> >
> > 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.

Yea, I can do that on Friday once I get back home, I am travelling
currently.

> 
> 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

Re: [PATCHv9 0/8] ARM: OMAP4: core retention support

[Tero Kristo]

On Tue, 2012-11-06 at 13:19 -0800, Kevin Hilman wrote:
> Tero Kristo <t-kristo@ti.com> writes:
> 
> > Hi Kevin,
> >
> > On Mon, 2012-11-05 at 14:23 -0800, Kevin Hilman wrote:
> >> Hi Tero,
> >> 
> >> Tero Kristo <t-kristo@ti.com> writes:
> >> 
> >> > 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
> >> 
> >> 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.
> 
> [...]
> 
> > 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.

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

[PATCHv9 0/8] ARM: OMAP4: core retention support

[Tero Kristo]

On Tue, 2012-11-06 at 13:19 -0800, Kevin Hilman wrote:
> Tero Kristo <t-kristo@ti.com> writes:
> 
> > Hi Kevin,
> >
> > On Mon, 2012-11-05 at 14:23 -0800, Kevin Hilman wrote:
> >> Hi Tero,
> >> 
> >> Tero Kristo <t-kristo@ti.com> writes:
> >> 
> >> > 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
> >> 
> >> 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.
> 
> [...]
> 
> > 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.

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

Re: [PATCHv9 0/8] ARM: OMAP4: core retention support

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1275 bytes --]

Hi,

On Mon, 5 Nov 2012, Kevin Hilman wrote:

> # 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

[PATCHv9 0/8] ARM: OMAP4: core retention support

[Paul Walmsley]

Hi,

On Mon, 5 Nov 2012, Kevin Hilman wrote:

> # 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

Re: [PATCHv9 0/8] ARM: OMAP4: core retention support

[Tero Kristo]

On Tue, 2012-11-06 at 13:19 -0800, Kevin Hilman wrote:
> Tero Kristo <t-kristo@ti.com> writes:
> 
> > Hi Kevin,
> >
> > On Mon, 2012-11-05 at 14:23 -0800, Kevin Hilman wrote:
> >> Hi Tero,
> >> 
> >> Tero Kristo <t-kristo@ti.com> writes:
> >> 
> >> > 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
> >> 
> >> 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.
> 
> [...]
> 
> > 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.

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

[PATCHv9 0/8] ARM: OMAP4: core retention support

[Tero Kristo]

On Tue, 2012-11-06 at 13:19 -0800, Kevin Hilman wrote:
> Tero Kristo <t-kristo@ti.com> writes:
> 
> > Hi Kevin,
> >
> > On Mon, 2012-11-05 at 14:23 -0800, Kevin Hilman wrote:
> >> Hi Tero,
> >> 
> >> Tero Kristo <t-kristo@ti.com> writes:
> >> 
> >> > 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
> >> 
> >> 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.
> 
> [...]
> 
> > 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.

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

Re: [PATCHv9 0/8] ARM: OMAP4: core retention support

[Kevin Hilman]

Tero Kristo <t-kristo@ti.com> writes:

> On Tue, 2012-11-06 at 13:19 -0800, Kevin Hilman wrote:
>> Tero Kristo <t-kristo@ti.com> writes:
>> 
>> > Hi Kevin,
>> >
>> > On Mon, 2012-11-05 at 14:23 -0800, Kevin Hilman wrote:
>> >> Hi Tero,
>> >> 
>> >> Tero Kristo <t-kristo@ti.com> writes:
>> >> 
>> >> > 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
>> >> 
>> >> 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.
>> 
>> [...]
>> 
>> > 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.
>
> 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

> 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

[PATCHv9 0/8] ARM: OMAP4: core retention support

[Kevin Hilman]

Tero Kristo <t-kristo@ti.com> writes:

> On Tue, 2012-11-06 at 13:19 -0800, Kevin Hilman wrote:
>> Tero Kristo <t-kristo@ti.com> writes:
>> 
>> > Hi Kevin,
>> >
>> > On Mon, 2012-11-05 at 14:23 -0800, Kevin Hilman wrote:
>> >> Hi Tero,
>> >> 
>> >> Tero Kristo <t-kristo@ti.com> writes:
>> >> 
>> >> > 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
>> >> 
>> >> 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.
>> 
>> [...]
>> 
>> > 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.
>
> 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

> 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

Re: [PATCHv9 1/8] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count

[Paul Walmsley]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 13952 bytes --]

On Thu, 18 Oct 2012, Tero Kristo wrote:

> From: Rajendra Nayak <rnayak@ti.com>
> 
> 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.
> 
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> [paul@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@ti.com: added support for arch specific hwmod ops, and changed
>  the no context offset indicator to USHRT_MAX]
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> [paul@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]
> Signed-off-by: Paul Walmsley <paul@pwsan.com>

Here's an updated version of this one with the low-level PRM accesses 
moved out to the PRM code.


- Paul

From: Rajendra Nayak <rnayak@ti.com>
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.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[paul@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@ti.com: added support for arch specific hwmod ops, and changed
 the no context offset indicator to USHRT_MAX]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[paul@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]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
 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(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 68616b2..083adbe 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -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;
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 87b59b4..421ff65 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -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;
 };
 
 
diff --git a/arch/arm/mach-omap2/prm.h b/arch/arm/mach-omap2/prm.h
index a1a266c..ac25ae6 100644
--- a/arch/arm/mach-omap2/prm.h
+++ b/arch/arm/mach-omap2/prm.h
@@ -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
 
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 9db1bd2..7498bc7 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -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)
diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index d2e0798..c6ae53c 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -367,6 +367,51 @@ u32 prm_read_reset_sources(void)
 }
 
 /**
+ * prm_was_any_context_lost_old - was device context lost? (old API)
+ * @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.  XXX Deprecated;
+ * callers need to use a less-SoC-dependent way to identify hardware
+ * IP blocks.
+ */
+bool prm_was_any_context_lost_old(u8 part, s16 inst, u16 idx)
+{
+	bool ret = true;
+
+	if (prm_ll_data->was_any_context_lost_old)
+		ret = prm_ll_data->was_any_context_lost_old(part, inst, idx);
+	else
+		WARN_ONCE(1, "prm: %s: no mapping function defined\n",
+			  __func__);
+
+	return ret;
+}
+
+/**
+ * prm_clear_context_lost_flags_old - clear context loss flags (old API)
+ * @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 Deprecated; callers
+ * need to use a less-SoC-dependent way to identify hardware IP
+ * blocks.
+ */
+void prm_clear_context_loss_flags_old(u8 part, s16 inst, u16 idx)
+{
+	if (prm_ll_data->clear_context_loss_flags_old)
+		prm_ll_data->clear_context_loss_flags_old(part, inst, idx);
+	else
+		WARN_ONCE(1, "prm: %s: no mapping function defined\n",
+			  __func__);
+}
+
+/**
  * prm_register - register per-SoC low-level data with the PRM
  * @pld: low-level per-SoC OMAP PRM data & function pointers to register
  *
-- 
1.7.10.4

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCHv9 1/8] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count

[Paul Walmsley]

On Thu, 18 Oct 2012, Tero Kristo wrote:

> From: Rajendra Nayak <rnayak@ti.com>
> 
> 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.
> 
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> [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]
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> [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]
> Signed-off-by: Paul Walmsley <paul@pwsan.com>

Here's an updated version of this one with the low-level PRM accesses 
moved out to the PRM code.


- Paul

From: Rajendra Nayak <rnayak@ti.com>
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.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[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]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[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]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
 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(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 68616b2..083adbe 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -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;
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index 87b59b4..421ff65 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -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;
 };
 
 
diff --git a/arch/arm/mach-omap2/prm.h b/arch/arm/mach-omap2/prm.h
index a1a266c..ac25ae6 100644
--- a/arch/arm/mach-omap2/prm.h
+++ b/arch/arm/mach-omap2/prm.h
@@ -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
 
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 9db1bd2..7498bc7 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -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)
diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index d2e0798..c6ae53c 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -367,6 +367,51 @@ u32 prm_read_reset_sources(void)
 }
 
 /**
+ * prm_was_any_context_lost_old - was device context lost? (old API)
+ * @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.  XXX Deprecated;
+ * callers need to use a less-SoC-dependent way to identify hardware
+ * IP blocks.
+ */
+bool prm_was_any_context_lost_old(u8 part, s16 inst, u16 idx)
+{
+	bool ret = true;
+
+	if (prm_ll_data->was_any_context_lost_old)
+		ret = prm_ll_data->was_any_context_lost_old(part, inst, idx);
+	else
+		WARN_ONCE(1, "prm: %s: no mapping function defined\n",
+			  __func__);
+
+	return ret;
+}
+
+/**
+ * prm_clear_context_lost_flags_old - clear context loss flags (old API)
+ * @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 Deprecated; callers
+ * need to use a less-SoC-dependent way to identify hardware IP
+ * blocks.
+ */
+void prm_clear_context_loss_flags_old(u8 part, s16 inst, u16 idx)
+{
+	if (prm_ll_data->clear_context_loss_flags_old)
+		prm_ll_data->clear_context_loss_flags_old(part, inst, idx);
+	else
+		WARN_ONCE(1, "prm: %s: no mapping function defined\n",
+			  __func__);
+}
+
+/**
  * prm_register - register per-SoC low-level data with the PRM
  * @pld: low-level per-SoC OMAP PRM data & function pointers to register
  *
-- 
1.7.10.4