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

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

[Tero Kristo]

Changes compared to previous version:

- rebased on top of 3.4
- added back TEMP patch for preventing DSP wakeup as Paul's powerdomain
  fixes are not yet in (patch #2)
- added open switch retention support (OSWR), can be enabled by
  echo 1 > /debug/pm_debug/enable_oswr_mode
- fixed support for 4460 (added patch #3)

Applies on top of mainline 3.4 + iochain set. May kind of work without
the iochain set but waking up from retention might be impossible.

Tested both CSWR + OSWR modes on omap4430 EMU blaze + omap4460 GP panda.

Working branch available here:
tree: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git
branch: mainline-3.4-omap4-ret

-Tero

[PATCHv4 1/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 |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 8856253..31990d5 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -101,12 +101,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)
-- 
1.7.4.1

[PATCHv4 2/8] TEMP: ARM: OMAP4: hwmod_data: Do not get DSP out of reset at boot time

[Tero Kristo]

From: Rajendra Nayak <rnayak@ti.com>

With no driver handling DSP, if brought out of reset, it stays
active and does not assert standby. This leads to IVAHD powerdomain not
transitioning and hence preventing chip retention.

This patch is no longer needed once Paul's powerdomain fixes are merged:
   http://marc.info/?l=linux-omap&m=133040749621183&w=2

Just provided for testing purposes.

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

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index cc9bd10..86e1b96 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -1160,6 +1160,7 @@ static struct omap_hwmod omap44xx_dsp_hwmod = {
 	.name		= "dsp",
 	.class		= &omap44xx_dsp_hwmod_class,
 	.clkdm_name	= "tesla_clkdm",
+	.flags		= HWMOD_INIT_NO_RESET,
 	.mpu_irqs	= omap44xx_dsp_irqs,
 	.rst_lines	= omap44xx_dsp_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap44xx_dsp_resets),
-- 
1.7.4.1

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

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

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

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        |   36 +++++++++++++++++++++++++++++
 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 +++++-
 5 files changed, 80 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 57da7f4..48d1ebe 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -199,6 +199,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);
@@ -206,6 +207,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 503ac77..d602555 100644
--- a/arch/arm/mach-omap2/omap-headsmp.S
+++ b/arch/arm/mach-omap2/omap-headsmp.S
@@ -43,3 +43,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, =0x48241000
+	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 13670aa..e02c082 100644
--- a/arch/arm/mach-omap2/omap-mpuss-lowpower.c
+++ b/arch/arm/mach-omap2/omap-mpuss-lowpower.c
@@ -68,6 +68,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 deffbf1..c3eb9e8 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -33,6 +33,7 @@
 
 /* SCU base address */
 static void __iomem *scu_base;
+bool omap4_smp_romcode_errata;
 
 static DEFINE_SPINLOCK(boot_lock);
 
@@ -104,6 +105,24 @@ int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)
 	 *	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 (omap4_smp_romcode_errata)
+			gic_dist_disable();
+
 		clkdm_wakeup(cpu1_clkdm);
 		clkdm_allow_idle(cpu1_clkdm);
 	} else {
@@ -124,13 +143,20 @@ int __cpuinit boot_secondary(unsigned int cpu, struct task_struct *idle)
 
 static void __init wakeup_secondary(void)
 {
+	void *startup_addr = omap_secondary_startup;
+
 	/*
 	 * Write the address of secondary startup routine into the
 	 * AuxCoreBoot1 where ROM code will jump and start executing
 	 * on secondary core once out of WFE
 	 * A barrier is added to ensure that write buffer is drained
 	 */
-	omap_auxcoreboot_addr(virt_to_phys(omap_secondary_startup));
+	if (cpu_is_omap446x()) {
+		startup_addr = omap_secondary_startup_4460;
+		omap4_smp_romcode_errata = true;
+	}
+
+	omap_auxcoreboot_addr(virt_to_phys(startup_addr));
 	smp_wmb();
 
 	/*
diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index 70de277..cc6a915 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -38,6 +38,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 */
@@ -92,7 +93,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);
@@ -107,6 +107,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)
-- 
1.7.4.1

[PATCHv4 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status

[Tero Kristo]

From: Rajendra Nayak <rnayak@ti.com>

On OMAP4 most modules/hwmods support module level context status. On
OMAP3 and earlier, we relyed on the power domain level context status.
Identify all such modules using a 'HWMOD_CONTEXT_REG' flag, all such
hwmods already have a valid 'context_offs' populated in .prcm structure.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c   |  104 ++++++++++++++++++++++----
 arch/arm/plat-omap/include/plat/omap_hwmod.h |    2 +
 2 files changed, 91 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 86e1b96..6c36e63 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -128,6 +128,7 @@ static struct omap_hwmod omap44xx_dmm_hwmod = {
 	.name		= "dmm",
 	.class		= &omap44xx_dmm_hwmod_class,
 	.clkdm_name	= "l3_emif_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_MEMIF_DMM_CLKCTRL_OFFSET,
@@ -184,6 +185,7 @@ static struct omap_hwmod omap44xx_emif_fw_hwmod = {
 	.name		= "emif_fw",
 	.class		= &omap44xx_emif_fw_hwmod_class,
 	.clkdm_name	= "l3_emif_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_MEMIF_EMIF_FW_CLKCTRL_OFFSET,
@@ -229,6 +231,7 @@ static struct omap_hwmod omap44xx_l3_instr_hwmod = {
 	.name		= "l3_instr",
 	.class		= &omap44xx_l3_hwmod_class,
 	.clkdm_name	= "l3_instr_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L3INSTR_L3_INSTR_CLKCTRL_OFFSET,
@@ -328,6 +331,7 @@ static struct omap_hwmod omap44xx_l3_main_1_hwmod = {
 	.name		= "l3_main_1",
 	.class		= &omap44xx_l3_hwmod_class,
 	.clkdm_name	= "l3_1_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_l3_main_1_irqs,
 	.prcm = {
 		.omap4 = {
@@ -430,6 +434,7 @@ static struct omap_hwmod omap44xx_l3_main_2_hwmod = {
 	.name		= "l3_main_2",
 	.class		= &omap44xx_l3_hwmod_class,
 	.clkdm_name	= "l3_2_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L3_2_L3_2_CLKCTRL_OFFSET,
@@ -486,6 +491,7 @@ static struct omap_hwmod omap44xx_l3_main_3_hwmod = {
 	.name		= "l3_main_3",
 	.class		= &omap44xx_l3_hwmod_class,
 	.clkdm_name	= "l3_instr_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L3INSTR_L3_3_CLKCTRL_OFFSET,
@@ -577,6 +583,7 @@ static struct omap_hwmod omap44xx_l4_cfg_hwmod = {
 	.name		= "l4_cfg",
 	.class		= &omap44xx_l4_hwmod_class,
 	.clkdm_name	= "l4_cfg_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4CFG_L4_CFG_CLKCTRL_OFFSET,
@@ -605,6 +612,7 @@ static struct omap_hwmod omap44xx_l4_per_hwmod = {
 	.name		= "l4_per",
 	.class		= &omap44xx_l4_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4PER_L4PER_CLKCTRL_OFFSET,
@@ -633,6 +641,7 @@ static struct omap_hwmod omap44xx_l4_wkup_hwmod = {
 	.name		= "l4_wkup",
 	.class		= &omap44xx_l4_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_WKUP_L4WKUP_CLKCTRL_OFFSET,
@@ -807,6 +816,7 @@ static struct omap_hwmod omap44xx_aess_hwmod = {
 	.name		= "aess",
 	.class		= &omap44xx_aess_hwmod_class,
 	.clkdm_name	= "abe_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_aess_irqs,
 	.sdma_reqs	= omap44xx_aess_sdma_reqs,
 	.main_clk	= "aess_fck",
@@ -898,7 +908,7 @@ static struct omap_hwmod omap44xx_counter_32k_hwmod = {
 	.name		= "counter_32k",
 	.class		= &omap44xx_counter_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
-	.flags		= HWMOD_SWSUP_SIDLE,
+	.flags		= HWMOD_CONTEXT_REG | HWMOD_SWSUP_SIDLE,
 	.main_clk	= "sys_32k_ck",
 	.prcm = {
 		.omap4 = {
@@ -982,6 +992,7 @@ static struct omap_hwmod omap44xx_dma_system_hwmod = {
 	.name		= "dma_system",
 	.class		= &omap44xx_dma_hwmod_class,
 	.clkdm_name	= "l3_dma_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_dma_system_irqs,
 	.main_clk	= "l3_div_ck",
 	.prcm = {
@@ -1077,6 +1088,7 @@ static struct omap_hwmod omap44xx_dmic_hwmod = {
 	.name		= "dmic",
 	.class		= &omap44xx_dmic_hwmod_class,
 	.clkdm_name	= "abe_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_dmic_irqs,
 	.sdma_reqs	= omap44xx_dmic_sdma_reqs,
 	.main_clk	= "dmic_fck",
@@ -1160,7 +1172,7 @@ static struct omap_hwmod omap44xx_dsp_hwmod = {
 	.name		= "dsp",
 	.class		= &omap44xx_dsp_hwmod_class,
 	.clkdm_name	= "tesla_clkdm",
-	.flags		= HWMOD_INIT_NO_RESET,
+	.flags		= HWMOD_INIT_NO_RESET | HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_dsp_irqs,
 	.rst_lines	= omap44xx_dsp_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap44xx_dsp_resets),
@@ -1252,7 +1264,8 @@ static struct omap_hwmod_opt_clk dss_opt_clks[] = {
 
 static struct omap_hwmod omap44xx_dss_hwmod = {
 	.name		= "dss_core",
-	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+	.flags		= HWMOD_CONTEXT_REG |
+			  HWMOD_CONTROL_OPT_CLKS_IN_RESET,
 	.class		= &omap44xx_dss_hwmod_class,
 	.clkdm_name	= "l3_dss_clkdm",
 	.main_clk	= "dss_dss_clk",
@@ -1356,6 +1369,7 @@ static struct omap_hwmod omap44xx_dss_dispc_hwmod = {
 	.name		= "dss_dispc",
 	.class		= &omap44xx_dispc_hwmod_class,
 	.clkdm_name	= "l3_dss_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_dss_dispc_irqs,
 	.sdma_reqs	= omap44xx_dss_dispc_sdma_reqs,
 	.main_clk	= "dss_dss_clk",
@@ -1453,6 +1467,7 @@ static struct omap_hwmod omap44xx_dss_dsi1_hwmod = {
 	.name		= "dss_dsi1",
 	.class		= &omap44xx_dsi_hwmod_class,
 	.clkdm_name	= "l3_dss_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_dss_dsi1_irqs,
 	.sdma_reqs	= omap44xx_dss_dsi1_sdma_reqs,
 	.main_clk	= "dss_dss_clk",
@@ -1530,6 +1545,7 @@ static struct omap_hwmod omap44xx_dss_dsi2_hwmod = {
 	.name		= "dss_dsi2",
 	.class		= &omap44xx_dsi_hwmod_class,
 	.clkdm_name	= "l3_dss_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_dss_dsi2_irqs,
 	.sdma_reqs	= omap44xx_dss_dsi2_sdma_reqs,
 	.main_clk	= "dss_dss_clk",
@@ -1627,6 +1643,7 @@ static struct omap_hwmod omap44xx_dss_hdmi_hwmod = {
 	.name		= "dss_hdmi",
 	.class		= &omap44xx_hdmi_hwmod_class,
 	.clkdm_name	= "l3_dss_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_dss_hdmi_irqs,
 	.sdma_reqs	= omap44xx_dss_hdmi_sdma_reqs,
 	.main_clk	= "dss_48mhz_clk",
@@ -1719,6 +1736,7 @@ static struct omap_hwmod omap44xx_dss_rfbi_hwmod = {
 	.name		= "dss_rfbi",
 	.class		= &omap44xx_rfbi_hwmod_class,
 	.clkdm_name	= "l3_dss_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.sdma_reqs	= omap44xx_dss_rfbi_sdma_reqs,
 	.main_clk	= "dss_dss_clk",
 	.prcm = {
@@ -1790,6 +1808,7 @@ static struct omap_hwmod omap44xx_dss_venc_hwmod = {
 	.name		= "dss_venc",
 	.class		= &omap44xx_venc_hwmod_class,
 	.clkdm_name	= "l3_dss_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.main_clk	= "dss_tv_clk",
 	.prcm = {
 		.omap4 = {
@@ -1868,6 +1887,7 @@ static struct omap_hwmod omap44xx_gpio1_hwmod = {
 	.name		= "gpio1",
 	.class		= &omap44xx_gpio_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_gpio1_irqs,
 	.main_clk	= "gpio1_ick",
 	.prcm = {
@@ -1922,7 +1942,8 @@ static struct omap_hwmod omap44xx_gpio2_hwmod = {
 	.name		= "gpio2",
 	.class		= &omap44xx_gpio_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
-	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+	.flags		= HWMOD_CONTEXT_REG |
+			  HWMOD_CONTROL_OPT_CLKS_IN_RESET,
 	.mpu_irqs	= omap44xx_gpio2_irqs,
 	.main_clk	= "gpio2_ick",
 	.prcm = {
@@ -1977,7 +1998,8 @@ static struct omap_hwmod omap44xx_gpio3_hwmod = {
 	.name		= "gpio3",
 	.class		= &omap44xx_gpio_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
-	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+	.flags		= HWMOD_CONTEXT_REG |
+			  HWMOD_CONTROL_OPT_CLKS_IN_RESET,
 	.mpu_irqs	= omap44xx_gpio3_irqs,
 	.main_clk	= "gpio3_ick",
 	.prcm = {
@@ -2032,7 +2054,8 @@ static struct omap_hwmod omap44xx_gpio4_hwmod = {
 	.name		= "gpio4",
 	.class		= &omap44xx_gpio_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
-	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+	.flags		= HWMOD_CONTEXT_REG |
+			  HWMOD_CONTROL_OPT_CLKS_IN_RESET,
 	.mpu_irqs	= omap44xx_gpio4_irqs,
 	.main_clk	= "gpio4_ick",
 	.prcm = {
@@ -2087,7 +2110,8 @@ static struct omap_hwmod omap44xx_gpio5_hwmod = {
 	.name		= "gpio5",
 	.class		= &omap44xx_gpio_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
-	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+	.flags		= HWMOD_CONTEXT_REG |
+			  HWMOD_CONTROL_OPT_CLKS_IN_RESET,
 	.mpu_irqs	= omap44xx_gpio5_irqs,
 	.main_clk	= "gpio5_ick",
 	.prcm = {
@@ -2142,7 +2166,8 @@ static struct omap_hwmod omap44xx_gpio6_hwmod = {
 	.name		= "gpio6",
 	.class		= &omap44xx_gpio_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
-	.flags		= HWMOD_CONTROL_OPT_CLKS_IN_RESET,
+	.flags		= HWMOD_CONTEXT_REG |
+			  HWMOD_CONTROL_OPT_CLKS_IN_RESET,
 	.mpu_irqs	= omap44xx_gpio6_irqs,
 	.main_clk	= "gpio6_ick",
 	.prcm = {
@@ -2223,6 +2248,7 @@ static struct omap_hwmod omap44xx_hsi_hwmod = {
 	.name		= "hsi",
 	.class		= &omap44xx_hsi_hwmod_class,
 	.clkdm_name	= "l3_init_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_hsi_irqs,
 	.main_clk	= "hsi_fck",
 	.prcm = {
@@ -2306,7 +2332,8 @@ static struct omap_hwmod omap44xx_i2c1_hwmod = {
 	.name		= "i2c1",
 	.class		= &omap44xx_i2c_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
-	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
+	.flags		= HWMOD_CONTEXT_REG | HWMOD_16BIT_REG |
+			  HWMOD_SET_DEFAULT_CLOCKACT,
 	.mpu_irqs	= omap44xx_i2c1_irqs,
 	.sdma_reqs	= omap44xx_i2c1_sdma_reqs,
 	.main_clk	= "i2c1_fck",
@@ -2362,7 +2389,8 @@ static struct omap_hwmod omap44xx_i2c2_hwmod = {
 	.name		= "i2c2",
 	.class		= &omap44xx_i2c_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
-	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
+	.flags		= HWMOD_CONTEXT_REG | HWMOD_16BIT_REG |
+			  HWMOD_SET_DEFAULT_CLOCKACT,
 	.mpu_irqs	= omap44xx_i2c2_irqs,
 	.sdma_reqs	= omap44xx_i2c2_sdma_reqs,
 	.main_clk	= "i2c2_fck",
@@ -2418,7 +2446,8 @@ static struct omap_hwmod omap44xx_i2c3_hwmod = {
 	.name		= "i2c3",
 	.class		= &omap44xx_i2c_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
-	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
+	.flags		= HWMOD_CONTEXT_REG | HWMOD_16BIT_REG |
+			  HWMOD_SET_DEFAULT_CLOCKACT,
 	.mpu_irqs	= omap44xx_i2c3_irqs,
 	.sdma_reqs	= omap44xx_i2c3_sdma_reqs,
 	.main_clk	= "i2c3_fck",
@@ -2474,7 +2503,8 @@ static struct omap_hwmod omap44xx_i2c4_hwmod = {
 	.name		= "i2c4",
 	.class		= &omap44xx_i2c_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
-	.flags		= HWMOD_16BIT_REG | HWMOD_SET_DEFAULT_CLOCKACT,
+	.flags		= HWMOD_CONTEXT_REG | HWMOD_16BIT_REG |
+			  HWMOD_SET_DEFAULT_CLOCKACT,
 	.mpu_irqs	= omap44xx_i2c4_irqs,
 	.sdma_reqs	= omap44xx_i2c4_sdma_reqs,
 	.main_clk	= "i2c4_fck",
@@ -2569,6 +2599,7 @@ static struct omap_hwmod omap44xx_ipu_hwmod = {
 	.name		= "ipu",
 	.class		= &omap44xx_ipu_hwmod_class,
 	.clkdm_name	= "ducati_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_ipu_irqs,
 	.rst_lines	= omap44xx_ipu_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap44xx_ipu_resets),
@@ -2658,6 +2689,7 @@ static struct omap_hwmod omap44xx_iss_hwmod = {
 	.name		= "iss",
 	.class		= &omap44xx_iss_hwmod_class,
 	.clkdm_name	= "iss_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_iss_irqs,
 	.sdma_reqs	= omap44xx_iss_sdma_reqs,
 	.main_clk	= "iss_fck",
@@ -2769,6 +2801,7 @@ static struct omap_hwmod omap44xx_iva_hwmod = {
 	.name		= "iva",
 	.class		= &omap44xx_iva_hwmod_class,
 	.clkdm_name	= "ivahd_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_iva_irqs,
 	.rst_lines	= omap44xx_iva_resets,
 	.rst_lines_cnt	= ARRAY_SIZE(omap44xx_iva_resets),
@@ -2843,6 +2876,7 @@ static struct omap_hwmod omap44xx_kbd_hwmod = {
 	.name		= "kbd",
 	.class		= &omap44xx_kbd_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_kbd_irqs,
 	.main_clk	= "kbd_fck",
 	.prcm = {
@@ -2910,6 +2944,7 @@ static struct omap_hwmod omap44xx_mailbox_hwmod = {
 	.name		= "mailbox",
 	.class		= &omap44xx_mailbox_hwmod_class,
 	.clkdm_name	= "l4_cfg_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_mailbox_irqs,
 	.prcm = {
 		.omap4 = {
@@ -3006,6 +3041,7 @@ static struct omap_hwmod omap44xx_mcbsp1_hwmod = {
 	.name		= "mcbsp1",
 	.class		= &omap44xx_mcbsp_hwmod_class,
 	.clkdm_name	= "abe_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_mcbsp1_irqs,
 	.sdma_reqs	= omap44xx_mcbsp1_sdma_reqs,
 	.main_clk	= "mcbsp1_fck",
@@ -3088,6 +3124,7 @@ static struct omap_hwmod omap44xx_mcbsp2_hwmod = {
 	.name		= "mcbsp2",
 	.class		= &omap44xx_mcbsp_hwmod_class,
 	.clkdm_name	= "abe_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_mcbsp2_irqs,
 	.sdma_reqs	= omap44xx_mcbsp2_sdma_reqs,
 	.main_clk	= "mcbsp2_fck",
@@ -3170,6 +3207,7 @@ static struct omap_hwmod omap44xx_mcbsp3_hwmod = {
 	.name		= "mcbsp3",
 	.class		= &omap44xx_mcbsp_hwmod_class,
 	.clkdm_name	= "abe_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_mcbsp3_irqs,
 	.sdma_reqs	= omap44xx_mcbsp3_sdma_reqs,
 	.main_clk	= "mcbsp3_fck",
@@ -3231,6 +3269,7 @@ static struct omap_hwmod omap44xx_mcbsp4_hwmod = {
 	.name		= "mcbsp4",
 	.class		= &omap44xx_mcbsp_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_mcbsp4_irqs,
 	.sdma_reqs	= omap44xx_mcbsp4_sdma_reqs,
 	.main_clk	= "mcbsp4_fck",
@@ -3327,6 +3366,7 @@ static struct omap_hwmod omap44xx_mcpdm_hwmod = {
 	.name		= "mcpdm",
 	.class		= &omap44xx_mcpdm_hwmod_class,
 	.clkdm_name	= "abe_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_mcpdm_irqs,
 	.sdma_reqs	= omap44xx_mcpdm_sdma_reqs,
 	.main_clk	= "mcpdm_fck",
@@ -3414,6 +3454,7 @@ static struct omap_hwmod omap44xx_mcspi1_hwmod = {
 	.name		= "mcspi1",
 	.class		= &omap44xx_mcspi_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_mcspi1_irqs,
 	.sdma_reqs	= omap44xx_mcspi1_sdma_reqs,
 	.main_clk	= "mcspi1_fck",
@@ -3476,6 +3517,7 @@ static struct omap_hwmod omap44xx_mcspi2_hwmod = {
 	.name		= "mcspi2",
 	.class		= &omap44xx_mcspi_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_mcspi2_irqs,
 	.sdma_reqs	= omap44xx_mcspi2_sdma_reqs,
 	.main_clk	= "mcspi2_fck",
@@ -3538,6 +3580,7 @@ static struct omap_hwmod omap44xx_mcspi3_hwmod = {
 	.name		= "mcspi3",
 	.class		= &omap44xx_mcspi_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_mcspi3_irqs,
 	.sdma_reqs	= omap44xx_mcspi3_sdma_reqs,
 	.main_clk	= "mcspi3_fck",
@@ -3598,6 +3641,7 @@ static struct omap_hwmod omap44xx_mcspi4_hwmod = {
 	.name		= "mcspi4",
 	.class		= &omap44xx_mcspi_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_mcspi4_irqs,
 	.sdma_reqs	= omap44xx_mcspi4_sdma_reqs,
 	.main_clk	= "mcspi4_fck",
@@ -3684,6 +3728,7 @@ static struct omap_hwmod omap44xx_mmc1_hwmod = {
 	.name		= "mmc1",
 	.class		= &omap44xx_mmc_hwmod_class,
 	.clkdm_name	= "l3_init_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_mmc1_irqs,
 	.sdma_reqs	= omap44xx_mmc1_sdma_reqs,
 	.main_clk	= "mmc1_fck",
@@ -3745,6 +3790,7 @@ static struct omap_hwmod omap44xx_mmc2_hwmod = {
 	.name		= "mmc2",
 	.class		= &omap44xx_mmc_hwmod_class,
 	.clkdm_name	= "l3_init_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_mmc2_irqs,
 	.sdma_reqs	= omap44xx_mmc2_sdma_reqs,
 	.main_clk	= "mmc2_fck",
@@ -3801,6 +3847,7 @@ static struct omap_hwmod omap44xx_mmc3_hwmod = {
 	.name		= "mmc3",
 	.class		= &omap44xx_mmc_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_mmc3_irqs,
 	.sdma_reqs	= omap44xx_mmc3_sdma_reqs,
 	.main_clk	= "mmc3_fck",
@@ -3855,6 +3902,7 @@ static struct omap_hwmod omap44xx_mmc4_hwmod = {
 	.name		= "mmc4",
 	.class		= &omap44xx_mmc_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_mmc4_irqs,
 
 	.sdma_reqs	= omap44xx_mmc4_sdma_reqs,
@@ -3910,6 +3958,7 @@ static struct omap_hwmod omap44xx_mmc5_hwmod = {
 	.name		= "mmc5",
 	.class		= &omap44xx_mmc_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_mmc5_irqs,
 	.sdma_reqs	= omap44xx_mmc5_sdma_reqs,
 	.main_clk	= "mmc5_fck",
@@ -3952,7 +4001,8 @@ static struct omap_hwmod omap44xx_mpu_hwmod = {
 	.name		= "mpu",
 	.class		= &omap44xx_mpu_hwmod_class,
 	.clkdm_name	= "mpuss_clkdm",
-	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+	.flags		= HWMOD_CONTEXT_REG | HWMOD_INIT_NO_IDLE |
+			  HWMOD_INIT_NO_RESET,
 	.mpu_irqs	= omap44xx_mpu_irqs,
 	.main_clk	= "dpll_mpu_m2_ck",
 	.prcm = {
@@ -4029,6 +4079,7 @@ static struct omap_hwmod omap44xx_smartreflex_core_hwmod = {
 	.name		= "smartreflex_core",
 	.class		= &omap44xx_smartreflex_hwmod_class,
 	.clkdm_name	= "l4_ao_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_smartreflex_core_irqs,
 
 	.main_clk	= "smartreflex_core_fck",
@@ -4082,6 +4133,7 @@ static struct omap_hwmod omap44xx_smartreflex_iva_hwmod = {
 	.name		= "smartreflex_iva",
 	.class		= &omap44xx_smartreflex_hwmod_class,
 	.clkdm_name	= "l4_ao_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_smartreflex_iva_irqs,
 	.main_clk	= "smartreflex_iva_fck",
 	.prcm = {
@@ -4134,6 +4186,7 @@ static struct omap_hwmod omap44xx_smartreflex_mpu_hwmod = {
 	.name		= "smartreflex_mpu",
 	.class		= &omap44xx_smartreflex_hwmod_class,
 	.clkdm_name	= "l4_ao_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_smartreflex_mpu_irqs,
 	.main_clk	= "smartreflex_mpu_fck",
 	.prcm = {
@@ -4200,6 +4253,7 @@ static struct omap_hwmod omap44xx_spinlock_hwmod = {
 	.name		= "spinlock",
 	.class		= &omap44xx_spinlock_hwmod_class,
 	.clkdm_name	= "l4_cfg_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.prcm = {
 		.omap4 = {
 			.clkctrl_offs = OMAP4_CM_L4CFG_HW_SEM_CLKCTRL_OFFSET,
@@ -4292,6 +4346,7 @@ static struct omap_hwmod omap44xx_timer1_hwmod = {
 	.name		= "timer1",
 	.class		= &omap44xx_timer_1ms_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_timer1_irqs,
 	.main_clk	= "timer1_fck",
 	.prcm = {
@@ -4340,6 +4395,7 @@ static struct omap_hwmod omap44xx_timer2_hwmod = {
 	.name		= "timer2",
 	.class		= &omap44xx_timer_1ms_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_timer2_irqs,
 	.main_clk	= "timer2_fck",
 	.prcm = {
@@ -4388,6 +4444,7 @@ static struct omap_hwmod omap44xx_timer3_hwmod = {
 	.name		= "timer3",
 	.class		= &omap44xx_timer_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_timer3_irqs,
 	.main_clk	= "timer3_fck",
 	.prcm = {
@@ -4436,6 +4493,7 @@ static struct omap_hwmod omap44xx_timer4_hwmod = {
 	.name		= "timer4",
 	.class		= &omap44xx_timer_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_timer4_irqs,
 	.main_clk	= "timer4_fck",
 	.prcm = {
@@ -4503,6 +4561,7 @@ static struct omap_hwmod omap44xx_timer5_hwmod = {
 	.name		= "timer5",
 	.class		= &omap44xx_timer_hwmod_class,
 	.clkdm_name	= "abe_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_timer5_irqs,
 	.main_clk	= "timer5_fck",
 	.prcm = {
@@ -4570,6 +4629,7 @@ static struct omap_hwmod omap44xx_timer6_hwmod = {
 	.name		= "timer6",
 	.class		= &omap44xx_timer_hwmod_class,
 	.clkdm_name	= "abe_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_timer6_irqs,
 
 	.main_clk	= "timer6_fck",
@@ -4638,6 +4698,7 @@ static struct omap_hwmod omap44xx_timer7_hwmod = {
 	.name		= "timer7",
 	.class		= &omap44xx_timer_hwmod_class,
 	.clkdm_name	= "abe_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_timer7_irqs,
 	.main_clk	= "timer7_fck",
 	.prcm = {
@@ -4705,6 +4766,7 @@ static struct omap_hwmod omap44xx_timer8_hwmod = {
 	.name		= "timer8",
 	.class		= &omap44xx_timer_hwmod_class,
 	.clkdm_name	= "abe_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_timer8_irqs,
 	.main_clk	= "timer8_fck",
 	.prcm = {
@@ -4753,6 +4815,7 @@ static struct omap_hwmod omap44xx_timer9_hwmod = {
 	.name		= "timer9",
 	.class		= &omap44xx_timer_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_timer9_irqs,
 	.main_clk	= "timer9_fck",
 	.prcm = {
@@ -4801,6 +4864,7 @@ static struct omap_hwmod omap44xx_timer10_hwmod = {
 	.name		= "timer10",
 	.class		= &omap44xx_timer_1ms_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_timer10_irqs,
 	.main_clk	= "timer10_fck",
 	.prcm = {
@@ -4849,6 +4913,7 @@ static struct omap_hwmod omap44xx_timer11_hwmod = {
 	.name		= "timer11",
 	.class		= &omap44xx_timer_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_timer11_irqs,
 	.main_clk	= "timer11_fck",
 	.prcm = {
@@ -4925,6 +4990,7 @@ static struct omap_hwmod omap44xx_uart1_hwmod = {
 	.name		= "uart1",
 	.class		= &omap44xx_uart_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_uart1_irqs,
 	.sdma_reqs	= omap44xx_uart1_sdma_reqs,
 	.main_clk	= "uart1_fck",
@@ -4979,6 +5045,7 @@ static struct omap_hwmod omap44xx_uart2_hwmod = {
 	.name		= "uart2",
 	.class		= &omap44xx_uart_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_uart2_irqs,
 	.sdma_reqs	= omap44xx_uart2_sdma_reqs,
 	.main_clk	= "uart2_fck",
@@ -5033,7 +5100,8 @@ static struct omap_hwmod omap44xx_uart3_hwmod = {
 	.name		= "uart3",
 	.class		= &omap44xx_uart_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
-	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+	.flags		= HWMOD_CONTEXT_REG | HWMOD_INIT_NO_IDLE |
+			  HWMOD_INIT_NO_RESET,
 	.mpu_irqs	= omap44xx_uart3_irqs,
 	.sdma_reqs	= omap44xx_uart3_sdma_reqs,
 	.main_clk	= "uart3_fck",
@@ -5088,6 +5156,7 @@ static struct omap_hwmod omap44xx_uart4_hwmod = {
 	.name		= "uart4",
 	.class		= &omap44xx_uart_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_uart4_irqs,
 	.sdma_reqs	= omap44xx_uart4_sdma_reqs,
 	.main_clk	= "uart4_fck",
@@ -5168,7 +5237,8 @@ static struct omap_hwmod omap44xx_usb_otg_hs_hwmod = {
 	.name		= "usb_otg_hs",
 	.class		= &omap44xx_usb_otg_hs_hwmod_class,
 	.clkdm_name	= "l3_init_clkdm",
-	.flags		= HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+	.flags		= HWMOD_CONTEXT_REG | HWMOD_SWSUP_SIDLE |
+			  HWMOD_SWSUP_MSTANDBY,
 	.mpu_irqs	= omap44xx_usb_otg_hs_irqs,
 	.main_clk	= "usb_otg_hs_ick",
 	.prcm = {
@@ -5243,6 +5313,7 @@ static struct omap_hwmod omap44xx_wd_timer2_hwmod = {
 	.name		= "wd_timer2",
 	.class		= &omap44xx_wd_timer_hwmod_class,
 	.clkdm_name	= "l4_wkup_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_wd_timer2_irqs,
 	.main_clk	= "wd_timer2_fck",
 	.prcm = {
@@ -5309,6 +5380,7 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
 	.name		= "wd_timer3",
 	.class		= &omap44xx_wd_timer_hwmod_class,
 	.clkdm_name	= "abe_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.mpu_irqs	= omap44xx_wd_timer3_irqs,
 	.main_clk	= "wd_timer3_fck",
 	.prcm = {
@@ -5396,6 +5468,7 @@ static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
 	.name		= "usb_host_hs",
 	.class		= &omap44xx_usb_host_hs_hwmod_class,
 	.clkdm_name	= "l3_init_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.main_clk	= "usb_host_hs_fck",
 	.prcm = {
 		.omap4 = {
@@ -5510,6 +5583,7 @@ static struct omap_hwmod omap44xx_usb_tll_hs_hwmod = {
 	.name		= "usb_tll_hs",
 	.class		= &omap44xx_usb_tll_hs_hwmod_class,
 	.clkdm_name	= "l3_init_clkdm",
+	.flags		= HWMOD_CONTEXT_REG,
 	.main_clk	= "usb_tll_hs_ick",
 	.prcm = {
 		.omap4 = {
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 8070145..4e5513b 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -399,6 +399,7 @@ struct omap_hwmod_omap4_prcm {
  *     in order to complete the reset. Optional clocks will be disabled
  *     again after the reset.
  * HWMOD_16BIT_REG: Module has 16bit registers
+ * HWMOD_CONTEXT_REG: Module has a valid context register
  */
 #define HWMOD_SWSUP_SIDLE			(1 << 0)
 #define HWMOD_SWSUP_MSTANDBY			(1 << 1)
@@ -409,6 +410,7 @@ struct omap_hwmod_omap4_prcm {
 #define HWMOD_NO_IDLEST				(1 << 6)
 #define HWMOD_CONTROL_OPT_CLKS_IN_RESET		(1 << 7)
 #define HWMOD_16BIT_REG				(1 << 8)
+#define HWMOD_CONTEXT_REG			(1 << 9)
 
 /*
  * omap_hwmod._int_flags definitions
-- 
1.7.4.1

Re: [PATCHv4 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status

[Jon Hunter]

Hi Tero,

On 04/20/2012 04:19 AM, Tero Kristo wrote:
> From: Rajendra Nayak <rnayak@ti.com>
> 
> On OMAP4 most modules/hwmods support module level context status. On
> OMAP3 and earlier, we relyed on the power domain level context status.
> Identify all such modules using a 'HWMOD_CONTEXT_REG' flag, all such
> hwmods already have a valid 'context_offs' populated in .prcm structure.

Is it necessary to add another flag? Can't we just check if context_offs
is non-zero? Would save adding a lot more lines to an already large file
:-)

Cheers
Jon

Re: [PATCHv4 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status

[Tero Kristo]

On Mon, 2012-04-23 at 10:52 -0500, Jon Hunter wrote:
> Hi Tero,
> 
> On 04/20/2012 04:19 AM, Tero Kristo wrote:
> > From: Rajendra Nayak <rnayak@ti.com>
> > 
> > On OMAP4 most modules/hwmods support module level context status. On
> > OMAP3 and earlier, we relyed on the power domain level context status.
> > Identify all such modules using a 'HWMOD_CONTEXT_REG' flag, all such
> > hwmods already have a valid 'context_offs' populated in .prcm structure.
> 
> Is it necessary to add another flag? Can't we just check if context_offs
> is non-zero? Would save adding a lot more lines to an already large file
> :-)

Actually one of the older versions of this patch was just checking
against a non-zero value, but it was decided to be changed as
potentially the context_offs can be zero even if it is a valid offset.

-Tero

Re: [PATCHv4 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status

[Cousson, Benoit]

On 4/24/2012 4:46 PM, Tero Kristo wrote:
> On Mon, 2012-04-23 at 10:52 -0500, Jon Hunter wrote:
>> Hi Tero,
>>
>> On 04/20/2012 04:19 AM, Tero Kristo wrote:
>>> From: Rajendra Nayak<rnayak@ti.com>
>>>
>>> On OMAP4 most modules/hwmods support module level context status. On
>>> OMAP3 and earlier, we relyed on the power domain level context status.
>>> Identify all such modules using a 'HWMOD_CONTEXT_REG' flag, all such
>>> hwmods already have a valid 'context_offs' populated in .prcm structure.
>>
>> Is it necessary to add another flag? Can't we just check if context_offs
>> is non-zero? Would save adding a lot more lines to an already large file
>> :-)
>
> Actually one of the older versions of this patch was just checking
> against a non-zero value, but it was decided to be changed as
> potentially the context_offs can be zero even if it is a valid offset.

Yeah, but still, every OMAP4 IPs are supporting that except two of them 
I guess, so it is a pity to add that to every IPs.

We'd better add a HWMOD_NO_CONTEXT_REG to the few IPs that are not 
supporting that. Since OMAP 2 & 3 does not have this feature at all, we 
can check on the cpu revision.

I think the issue raised by Rajendra was about AM35xx that looks like an 
OMAP3 variant but does have these registers like an OMAP4 variant:-(

Regards,
Benoit

Re: [PATCHv4 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status

[Kevin Hilman]

"Cousson, Benoit" <b-cousson@ti.com> writes:

> On 4/24/2012 4:46 PM, Tero Kristo wrote:
>> On Mon, 2012-04-23 at 10:52 -0500, Jon Hunter wrote:
>>> Hi Tero,
>>>
>>> On 04/20/2012 04:19 AM, Tero Kristo wrote:
>>>> From: Rajendra Nayak<rnayak@ti.com>
>>>>
>>>> On OMAP4 most modules/hwmods support module level context status. On
>>>> OMAP3 and earlier, we relyed on the power domain level context status.
>>>> Identify all such modules using a 'HWMOD_CONTEXT_REG' flag, all such
>>>> hwmods already have a valid 'context_offs' populated in .prcm structure.
>>>
>>> Is it necessary to add another flag? Can't we just check if context_offs
>>> is non-zero? Would save adding a lot more lines to an already large file
>>> :-)
>>
>> Actually one of the older versions of this patch was just checking
>> against a non-zero value, but it was decided to be changed as
>> potentially the context_offs can be zero even if it is a valid offset.

Potentially?  Is that the case on OMAP4/5 today?  I don't see any for
OMAP4 in mainline.

If zero really is a valid offset somewhere (where?), then we could use
-1 (or USHRT_MAX in this case.)

> Yeah, but still, every OMAP4 IPs are supporting that except two of
> them I guess, so it is a pity to add that to every IPs.
>
> We'd better add a HWMOD_NO_CONTEXT_REG to the few IPs that are not
> supporting that. Since OMAP 2 & 3 does not have this feature at all,
> we can check on the cpu revision.
>
> I think the issue raised by Rajendra was about AM35xx that looks like
> an OMAP3 variant but does have these registers like an OMAP4
> variant:-(

If AM335x is missing it for *all* IPs, that's easy enough to solve
without bloating the data file: just set .context_offs field (or flag)
to the magic value for all IPs during hwmod registration.

Paul/Benoit should make the call whether to use a special value in the
.context_offs field (0 or -1) or add a new flag.  If a flag is chosen, I
agree with Benoit that it should indicate the *lack* of the feature,
since having the feature is the norm.

Kevin

Re: [PATCHv4 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status

[Rajendra Nayak]

On Wednesday 16 May 2012 03:52 AM, Kevin Hilman wrote:
> "Cousson, Benoit"<b-cousson@ti.com>  writes:
>
>> On 4/24/2012 4:46 PM, Tero Kristo wrote:
>>> On Mon, 2012-04-23 at 10:52 -0500, Jon Hunter wrote:
>>>> Hi Tero,
>>>>
>>>> On 04/20/2012 04:19 AM, Tero Kristo wrote:
>>>>> From: Rajendra Nayak<rnayak@ti.com>
>>>>>
>>>>> On OMAP4 most modules/hwmods support module level context status. On
>>>>> OMAP3 and earlier, we relyed on the power domain level context status.
>>>>> Identify all such modules using a 'HWMOD_CONTEXT_REG' flag, all such
>>>>> hwmods already have a valid 'context_offs' populated in .prcm structure.
>>>>
>>>> Is it necessary to add another flag? Can't we just check if context_offs
>>>> is non-zero? Would save adding a lot more lines to an already large file
>>>> :-)
>>>
>>> Actually one of the older versions of this patch was just checking
>>> against a non-zero value, but it was decided to be changed as
>>> potentially the context_offs can be zero even if it is a valid offset.
>
> Potentially?  Is that the case on OMAP4/5 today?  I don't see any for
> OMAP4 in mainline.

No, we don;t have any such cases today in either OMAP4 or OMAP5.

>
> If zero really is a valid offset somewhere (where?), then we could use
> -1 (or USHRT_MAX in this case.)

This makes sense for OMAP4 and beyond (and same with having a flag
to indicate the *lack* of having the feature) as it will mean just
adding a few entries in hwmod data files to indicate IP blocks (very
few) which do not support this feature.

However since none of OMAP2/3 varients (except I guess the AMxxxx
family) support this, it would also mean we mark
*most* blocks in OMAP2/3 to indicate they *lack* this feature, which
would mean bloating the OMAP2/3 data files, but your
comment below about doing it for all IPs during hwmod registration
makes sense at least for OMAP2 since *all* blocks can be marked at
registration. OMAP3 would probably need more data files to be updated
to indicate which ones support and which ones don't.

Having said that I also see 'context_reg' being defined inside
omap_hwmod_omap4_prcm would need to be fixed if we have to
support this for SoCs which fall as OMAP3 varients.

>
>> Yeah, but still, every OMAP4 IPs are supporting that except two of
>> them I guess, so it is a pity to add that to every IPs.
>>
>> We'd better add a HWMOD_NO_CONTEXT_REG to the few IPs that are not
>> supporting that. Since OMAP 2&  3 does not have this feature at all,
>> we can check on the cpu revision.
>>
>> I think the issue raised by Rajendra was about AM35xx that looks like
>> an OMAP3 variant but does have these registers like an OMAP4
>> variant:-(
>
> If AM335x is missing it for *all* IPs, that's easy enough to solve
> without bloating the data file: just set .context_offs field (or flag)
> to the magic value for all IPs during hwmod registration.
>
> Paul/Benoit should make the call whether to use a special value in the
> .context_offs field (0 or -1) or add a new flag.  If a flag is chosen, I
> agree with Benoit that it should indicate the *lack* of the feature,
> since having the feature is the norm.
>
> Kevin
>

Re: [PATCHv4 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status

[Rajendra Nayak]

On Wednesday 16 May 2012 10:54 AM, Rajendra Nayak wrote:
> On Wednesday 16 May 2012 03:52 AM, Kevin Hilman wrote:
>> "Cousson, Benoit"<b-cousson@ti.com> writes:
>>
>>> On 4/24/2012 4:46 PM, Tero Kristo wrote:
>>>> On Mon, 2012-04-23 at 10:52 -0500, Jon Hunter wrote:
>>>>> Hi Tero,
>>>>>
>>>>> On 04/20/2012 04:19 AM, Tero Kristo wrote:
>>>>>> From: Rajendra Nayak<rnayak@ti.com>
>>>>>>
>>>>>> On OMAP4 most modules/hwmods support module level context status. On
>>>>>> OMAP3 and earlier, we relyed on the power domain level context
>>>>>> status.
>>>>>> Identify all such modules using a 'HWMOD_CONTEXT_REG' flag, all such
>>>>>> hwmods already have a valid 'context_offs' populated in .prcm
>>>>>> structure.
>>>>>
>>>>> Is it necessary to add another flag? Can't we just check if
>>>>> context_offs
>>>>> is non-zero? Would save adding a lot more lines to an already large
>>>>> file
>>>>> :-)
>>>>
>>>> Actually one of the older versions of this patch was just checking
>>>> against a non-zero value, but it was decided to be changed as
>>>> potentially the context_offs can be zero even if it is a valid offset.
>>
>> Potentially? Is that the case on OMAP4/5 today? I don't see any for
>> OMAP4 in mainline.
>
> No, we don;t have any such cases today in either OMAP4 or OMAP5.
>
>>
>> If zero really is a valid offset somewhere (where?), then we could use
>> -1 (or USHRT_MAX in this case.)
>
> This makes sense for OMAP4 and beyond (and same with having a flag
> to indicate the *lack* of having the feature) as it will mean just
> adding a few entries in hwmod data files to indicate IP blocks (very
> few) which do not support this feature.
>
> However since none of OMAP2/3 varients (except I guess the AMxxxx
> family) support this, it would also mean we mark
> *most* blocks in OMAP2/3 to indicate they *lack* this feature, which
> would mean bloating the OMAP2/3 data files, but your
> comment below about doing it for all IPs during hwmod registration
> makes sense at least for OMAP2 since *all* blocks can be marked at
> registration. OMAP3 would probably need more data files to be updated
> to indicate which ones support and which ones don't.
>
> Having said that I also see 'context_reg' being defined inside
> omap_hwmod_omap4_prcm would need to be fixed if we have to
> support this for SoCs which fall as OMAP3 varients.

I just went back and looked at Vaibhavs patch which adds am33xx
hwmod data and I think none of what I said above is a problem.
I think we can safely mark the few blocks on OMAP4 which do
not have a valid context_reg with -1 or USHRT_MAX as you suggested
and mark all OMAP2/3 blocks with this at registration.

Benoit/Paul, does that sound good?

>
>>
>>> Yeah, but still, every OMAP4 IPs are supporting that except two of
>>> them I guess, so it is a pity to add that to every IPs.
>>>
>>> We'd better add a HWMOD_NO_CONTEXT_REG to the few IPs that are not
>>> supporting that. Since OMAP 2& 3 does not have this feature at all,
>>> we can check on the cpu revision.
>>>
>>> I think the issue raised by Rajendra was about AM35xx that looks like
>>> an OMAP3 variant but does have these registers like an OMAP4
>>> variant:-(
>>
>> If AM335x is missing it for *all* IPs, that's easy enough to solve
>> without bloating the data file: just set .context_offs field (or flag)
>> to the magic value for all IPs during hwmod registration.
>>
>> Paul/Benoit should make the call whether to use a special value in the
>> .context_offs field (0 or -1) or add a new flag. If a flag is chosen, I
>> agree with Benoit that it should indicate the *lack* of the feature,
>> since having the feature is the norm.
>>
>> Kevin
>>
>

Re: [PATCHv4 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status

[Tero Kristo]

On Wed, 2012-05-16 at 11:15 +0530, Rajendra Nayak wrote:
> On Wednesday 16 May 2012 10:54 AM, Rajendra Nayak wrote:
> > On Wednesday 16 May 2012 03:52 AM, Kevin Hilman wrote:
> >> "Cousson, Benoit"<b-cousson@ti.com> writes:
> >>
> >>> On 4/24/2012 4:46 PM, Tero Kristo wrote:
> >>>> On Mon, 2012-04-23 at 10:52 -0500, Jon Hunter wrote:
> >>>>> Hi Tero,
> >>>>>
> >>>>> On 04/20/2012 04:19 AM, Tero Kristo wrote:
> >>>>>> From: Rajendra Nayak<rnayak@ti.com>
> >>>>>>
> >>>>>> On OMAP4 most modules/hwmods support module level context status. On
> >>>>>> OMAP3 and earlier, we relyed on the power domain level context
> >>>>>> status.
> >>>>>> Identify all such modules using a 'HWMOD_CONTEXT_REG' flag, all such
> >>>>>> hwmods already have a valid 'context_offs' populated in .prcm
> >>>>>> structure.
> >>>>>
> >>>>> Is it necessary to add another flag? Can't we just check if
> >>>>> context_offs
> >>>>> is non-zero? Would save adding a lot more lines to an already large
> >>>>> file
> >>>>> :-)
> >>>>
> >>>> Actually one of the older versions of this patch was just checking
> >>>> against a non-zero value, but it was decided to be changed as
> >>>> potentially the context_offs can be zero even if it is a valid offset.
> >>
> >> Potentially? Is that the case on OMAP4/5 today? I don't see any for
> >> OMAP4 in mainline.
> >
> > No, we don;t have any such cases today in either OMAP4 or OMAP5.
> >
> >>
> >> If zero really is a valid offset somewhere (where?), then we could use
> >> -1 (or USHRT_MAX in this case.)
> >
> > This makes sense for OMAP4 and beyond (and same with having a flag
> > to indicate the *lack* of having the feature) as it will mean just
> > adding a few entries in hwmod data files to indicate IP blocks (very
> > few) which do not support this feature.
> >
> > However since none of OMAP2/3 varients (except I guess the AMxxxx
> > family) support this, it would also mean we mark
> > *most* blocks in OMAP2/3 to indicate they *lack* this feature, which
> > would mean bloating the OMAP2/3 data files, but your
> > comment below about doing it for all IPs during hwmod registration
> > makes sense at least for OMAP2 since *all* blocks can be marked at
> > registration. OMAP3 would probably need more data files to be updated
> > to indicate which ones support and which ones don't.
> >
> > Having said that I also see 'context_reg' being defined inside
> > omap_hwmod_omap4_prcm would need to be fixed if we have to
> > support this for SoCs which fall as OMAP3 varients.
> 
> I just went back and looked at Vaibhavs patch which adds am33xx
> hwmod data and I think none of what I said above is a problem.
> I think we can safely mark the few blocks on OMAP4 which do
> not have a valid context_reg with -1 or USHRT_MAX as you suggested
> and mark all OMAP2/3 blocks with this at registration.
> 
> Benoit/Paul, does that sound good?

Any comments to this? This is blocking v6 for this set. Also, who is
going to generate the hwmod data?

-Tero

> 
> >
> >>
> >>> Yeah, but still, every OMAP4 IPs are supporting that except two of
> >>> them I guess, so it is a pity to add that to every IPs.
> >>>
> >>> We'd better add a HWMOD_NO_CONTEXT_REG to the few IPs that are not
> >>> supporting that. Since OMAP 2& 3 does not have this feature at all,
> >>> we can check on the cpu revision.
> >>>
> >>> I think the issue raised by Rajendra was about AM35xx that looks like
> >>> an OMAP3 variant but does have these registers like an OMAP4
> >>> variant:-(
> >>
> >> If AM335x is missing it for *all* IPs, that's easy enough to solve
> >> without bloating the data file: just set .context_offs field (or flag)
> >> to the magic value for all IPs during hwmod registration.
> >>
> >> Paul/Benoit should make the call whether to use a special value in the
> >> .context_offs field (0 or -1) or add a new flag. If a flag is chosen, I
> >> agree with Benoit that it should indicate the *lack* of the feature,
> >> since having the feature is the norm.
> >>
> >> Kevin
> >>
> >
> 

Re: [PATCHv4 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status

[Cousson, Benoit]

On 5/22/2012 4:20 PM, Tero Kristo wrote:
> On Wed, 2012-05-16 at 11:15 +0530, Rajendra Nayak wrote:
>> On Wednesday 16 May 2012 10:54 AM, Rajendra Nayak wrote:
>>> On Wednesday 16 May 2012 03:52 AM, Kevin Hilman wrote:
>>>> "Cousson, Benoit"<b-cousson@ti.com>  writes:
>>>>
>>>>> On 4/24/2012 4:46 PM, Tero Kristo wrote:
>>>>>> On Mon, 2012-04-23 at 10:52 -0500, Jon Hunter wrote:
>>>>>>> Hi Tero,
>>>>>>>
>>>>>>> On 04/20/2012 04:19 AM, Tero Kristo wrote:
>>>>>>>> From: Rajendra Nayak<rnayak@ti.com>
>>>>>>>>
>>>>>>>> On OMAP4 most modules/hwmods support module level context status. On
>>>>>>>> OMAP3 and earlier, we relyed on the power domain level context
>>>>>>>> status.
>>>>>>>> Identify all such modules using a 'HWMOD_CONTEXT_REG' flag, all such
>>>>>>>> hwmods already have a valid 'context_offs' populated in .prcm
>>>>>>>> structure.
>>>>>>>
>>>>>>> Is it necessary to add another flag? Can't we just check if
>>>>>>> context_offs
>>>>>>> is non-zero? Would save adding a lot more lines to an already large
>>>>>>> file
>>>>>>> :-)
>>>>>>
>>>>>> Actually one of the older versions of this patch was just checking
>>>>>> against a non-zero value, but it was decided to be changed as
>>>>>> potentially the context_offs can be zero even if it is a valid offset.
>>>>
>>>> Potentially? Is that the case on OMAP4/5 today? I don't see any for
>>>> OMAP4 in mainline.
>>>
>>> No, we don;t have any such cases today in either OMAP4 or OMAP5.
>>>
>>>>
>>>> If zero really is a valid offset somewhere (where?), then we could use
>>>> -1 (or USHRT_MAX in this case.)
>>>
>>> This makes sense for OMAP4 and beyond (and same with having a flag
>>> to indicate the *lack* of having the feature) as it will mean just
>>> adding a few entries in hwmod data files to indicate IP blocks (very
>>> few) which do not support this feature.
>>>
>>> However since none of OMAP2/3 varients (except I guess the AMxxxx
>>> family) support this, it would also mean we mark
>>> *most* blocks in OMAP2/3 to indicate they *lack* this feature, which
>>> would mean bloating the OMAP2/3 data files, but your
>>> comment below about doing it for all IPs during hwmod registration
>>> makes sense at least for OMAP2 since *all* blocks can be marked at
>>> registration. OMAP3 would probably need more data files to be updated
>>> to indicate which ones support and which ones don't.
>>>
>>> Having said that I also see 'context_reg' being defined inside
>>> omap_hwmod_omap4_prcm would need to be fixed if we have to
>>> support this for SoCs which fall as OMAP3 varients.
>>
>> I just went back and looked at Vaibhavs patch which adds am33xx
>> hwmod data and I think none of what I said above is a problem.
>> I think we can safely mark the few blocks on OMAP4 which do
>> not have a valid context_reg with -1 or USHRT_MAX as you suggested
>> and mark all OMAP2/3 blocks with this at registration.
>>
>> Benoit/Paul, does that sound good?
>
> Any comments to this? This is blocking v6 for this set.

That's OK for me.

> Also, who is going to generate the hwmod data?

Well, in that case, only two entries have to be changed I guess, but 
I'll update anyway the scripts to populate the missing one with the 
macros you will create.

Benoit

[PATCHv4 5/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]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.c             |   44 +++++++++++++++++++++++--
 arch/arm/plat-omap/include/plat/omap_hwmod.h |    8 +++-
 2 files changed, 46 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 00e8cbf..fb2f4a3 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1489,6 +1489,36 @@ static int _reset(struct omap_hwmod *oh)
 }
 
 /**
+ * _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->flags & HWMOD_CONTEXT_REG))
+		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);
+}
+
+/**
  * _enable - enable an omap_hwmod
  * @oh: struct omap_hwmod *
  *
@@ -1568,6 +1598,8 @@ static int _enable(struct omap_hwmod *oh)
 	_enable_clocks(oh);
 	_enable_module(oh);
 
+	_omap4_update_context_lost(oh);
+
 	r = _wait_target_ready(oh);
 	if (!r) {
 		/*
@@ -2683,17 +2715,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 (oh->flags & HWMOD_CONTEXT_REG)
+		return oh->prcm.omap4.context_lost_counter;
+
 	pwrdm = omap_hwmod_get_pwrdm(oh);
 	if (pwrdm)
 		ret = pwrdm_get_context_loss_count(pwrdm);
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 4e5513b..7a00215 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -362,9 +362,12 @@ 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
  * @submodule_wkdep_bit: bit shift of the WKDEP range
+ * @modulemode: allowable modulemodes
+ * @context_lost_counter: Count of module level context lost
  */
 struct omap_hwmod_omap4_prcm {
 	u16		clkctrl_offs;
@@ -372,6 +375,7 @@ struct omap_hwmod_omap4_prcm {
 	u16		context_offs;
 	u8		submodule_wkdep_bit;
 	u8		modulemode;
+	unsigned	context_lost_counter;
 };
 
 
-- 
1.7.4.1

[PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters

[Tero Kristo]

From: Axel Haslam <axelhaslam@gmail.com>

On OMAP4, there is no support to read previous logic state
or previous memory state achieved when a power domain transitions
to RET. Instead there are module level context registers.

In order to support the powerdomain level logic/mem_off_counters
on OMAP4, instead use the previous power state achieved (RET) and
the *programmed* logic/mem RET state to derive if a powerdomain lost
logic or did not.

If the powerdomain is programmed to enter RET state and lose logic
in RET state, knowing that the powerdomain entered RET is good enough
to derive that the logic was lost as well, in such cases.

Signed-off-by: Axel Haslam <axelhaslam@gmail.com>
[rnayak@ti.com: Updated changelog, updated patch to support mem counters]
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/mach-omap2/powerdomain.c |   16 ++++++++++------
 1 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c
index 96ad3dbe..068f06b 100644
--- a/arch/arm/mach-omap2/powerdomain.c
+++ b/arch/arm/mach-omap2/powerdomain.c
@@ -124,18 +124,22 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
 static void _update_logic_membank_counters(struct powerdomain *pwrdm)
 {
 	int i;
-	u8 prev_logic_pwrst, prev_mem_pwrst;
+	int logic_pwrst, mem_pwrst;
+
+	logic_pwrst = pwrdm_read_prev_logic_pwrst(pwrdm);
+	if (logic_pwrst == -EINVAL)
+		logic_pwrst = pwrdm_read_logic_retst(pwrdm);
 
-	prev_logic_pwrst = pwrdm_read_prev_logic_pwrst(pwrdm);
 	if ((pwrdm->pwrsts_logic_ret == PWRSTS_OFF_RET) &&
-	    (prev_logic_pwrst == PWRDM_POWER_OFF))
+	    (logic_pwrst == PWRDM_POWER_OFF))
 		pwrdm->ret_logic_off_counter++;
 
 	for (i = 0; i < pwrdm->banks; i++) {
-		prev_mem_pwrst = pwrdm_read_prev_mem_pwrst(pwrdm, i);
-
+		mem_pwrst = pwrdm_read_prev_mem_pwrst(pwrdm, i);
+		if (mem_pwrst == -EINVAL)
+			mem_pwrst = pwrdm_read_mem_retst(pwrdm, i);
 		if ((pwrdm->pwrsts_mem_ret[i] == PWRSTS_OFF_RET) &&
-		    (prev_mem_pwrst == PWRDM_POWER_OFF))
+		    (mem_pwrst == PWRDM_POWER_OFF))
 			pwrdm->ret_mem_off_counter[i]++;
 	}
 }
-- 
1.7.4.1

RE: [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters

[Bedia, Vaibhav]

Hi Tero,

On Fri, Apr 20, 2012 at 14:49:49, Kristo, Tero wrote:
> From: Axel Haslam <axelhaslam@gmail.com>
> 
> On OMAP4, there is no support to read previous logic state
> or previous memory state achieved when a power domain transitions
> to RET. Instead there are module level context registers.
> 
> In order to support the powerdomain level logic/mem_off_counters
> on OMAP4, instead use the previous power state achieved (RET) and
> the *programmed* logic/mem RET state to derive if a powerdomain lost
> logic or did not.
> 
> If the powerdomain is programmed to enter RET state and lose logic
> in RET state, knowing that the powerdomain entered RET is good enough
> to derive that the logic was lost as well, in such cases.
> 

Unfortunately this won't scale for AM33xx devices :(
It neither has module level context registers nor previous logic/memory state
registers in PRCM. 

At a top level, there's a Cortex-M3 (CM3) to assist the low power state transitions
and the indication of successful transition to a low power states is handled as part
of the IPC mechanism between the MPU (A8) and CM3 which is s/w defined.

Since the various APIs like omap_hwmod_get_context_loss_context() and friends are
necessary to have correct context saves and restores in drivers we'll need
to add another API for AM33xx which basically builds on the IPC mechanism
and updates the counters.

So, instead of the fallback mechanism that is currently in place, can the
implementation for updating the logic/mem counters be converted to make use of
function pointers. When AM33xx PM support comes in, we can just define
a custom function and not pollute the code with cpu_is_* checks.

Regards,
Vaibhav

RE: [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters

[Tero Kristo]

On Wed, 2012-05-02 at 10:45 +0200, Bedia, Vaibhav wrote:
> Hi Tero,
> 
> On Fri, Apr 20, 2012 at 14:49:49, Kristo, Tero wrote:
> > From: Axel Haslam <axelhaslam@gmail.com>
> > 
> > On OMAP4, there is no support to read previous logic state
> > or previous memory state achieved when a power domain transitions
> > to RET. Instead there are module level context registers.
> > 
> > In order to support the powerdomain level logic/mem_off_counters
> > on OMAP4, instead use the previous power state achieved (RET) and
> > the *programmed* logic/mem RET state to derive if a powerdomain lost
> > logic or did not.
> > 
> > If the powerdomain is programmed to enter RET state and lose logic
> > in RET state, knowing that the powerdomain entered RET is good enough
> > to derive that the logic was lost as well, in such cases.
> > 
> 
> Unfortunately this won't scale for AM33xx devices :(
> It neither has module level context registers nor previous logic/memory state
> registers in PRCM. 
> 
> At a top level, there's a Cortex-M3 (CM3) to assist the low power state transitions
> and the indication of successful transition to a low power states is handled as part
> of the IPC mechanism between the MPU (A8) and CM3 which is s/w defined.
> 
> Since the various APIs like omap_hwmod_get_context_loss_context() and friends are
> necessary to have correct context saves and restores in drivers we'll need
> to add another API for AM33xx which basically builds on the IPC mechanism
> and updates the counters.
> 
> So, instead of the fallback mechanism that is currently in place, can the
> implementation for updating the logic/mem counters be converted to make use of
> function pointers. When AM33xx PM support comes in, we can just define
> a custom function and not pollute the code with cpu_is_* checks.

I think that should be fine. We can add arch_hwmod struct or such
(similar to arch_clkdm / arch_pwrdm) if need be. However, I think we
should just expand the support towards that way once we can implement
the am33xx support properly with a separate patch. I guess this doesn't
break anything on am33xx currently, right?

-Tero

RE: [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters

[Bedia, Vaibhav]

On Wed, May 02, 2012 at 14:50:21, Kristo, Tero wrote:
> On Wed, 2012-05-02 at 10:45 +0200, Bedia, Vaibhav wrote:
> > Hi Tero,
> > 
> > On Fri, Apr 20, 2012 at 14:49:49, Kristo, Tero wrote:
> > > From: Axel Haslam <axelhaslam@gmail.com>
> > > 
> > > On OMAP4, there is no support to read previous logic state
> > > or previous memory state achieved when a power domain transitions
> > > to RET. Instead there are module level context registers.
> > > 
> > > In order to support the powerdomain level logic/mem_off_counters
> > > on OMAP4, instead use the previous power state achieved (RET) and
> > > the *programmed* logic/mem RET state to derive if a powerdomain lost
> > > logic or did not.
> > > 
> > > If the powerdomain is programmed to enter RET state and lose logic
> > > in RET state, knowing that the powerdomain entered RET is good enough
> > > to derive that the logic was lost as well, in such cases.
> > > 
> > 
> > Unfortunately this won't scale for AM33xx devices :(
> > It neither has module level context registers nor previous logic/memory state
> > registers in PRCM. 
> > 
> > At a top level, there's a Cortex-M3 (CM3) to assist the low power state transitions
> > and the indication of successful transition to a low power states is handled as part
> > of the IPC mechanism between the MPU (A8) and CM3 which is s/w defined.
> > 
> > Since the various APIs like omap_hwmod_get_context_loss_context() and friends are
> > necessary to have correct context saves and restores in drivers we'll need
> > to add another API for AM33xx which basically builds on the IPC mechanism
> > and updates the counters.
> > 
> > So, instead of the fallback mechanism that is currently in place, can the
> > implementation for updating the logic/mem counters be converted to make use of
> > function pointers. When AM33xx PM support comes in, we can just define
> > a custom function and not pollute the code with cpu_is_* checks.
> 
> I think that should be fine. We can add arch_hwmod struct or such
> (similar to arch_clkdm / arch_pwrdm) if need be. However, I think we
> should just expand the support towards that way once we can implement
> the am33xx support properly with a separate patch. I guess this doesn't
> break anything on am33xx currently, right?
> 

It doesn't break anything right now but since we know this doesn't scale
that would be save some additional round of validation on OMAP3/4
later on.

-Vaibhav

Re: [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters

[Kevin Hilman]

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

> From: Axel Haslam <axelhaslam@gmail.com>
>
> On OMAP4, there is no support to read previous logic state
> or previous memory state achieved when a power domain transitions
> to RET. Instead there are module level context registers.
>
> In order to support the powerdomain level logic/mem_off_counters
> on OMAP4, instead use the previous power state achieved (RET) and
> the *programmed* logic/mem RET state to derive if a powerdomain lost
> logic or did not.

OK, but this also changes the behavior for OMAP3 as well, right?  I
don't see in the changelog how this affects OMAP3 and whether it is
still expected to work on OMAP3.  When changing common code like this,
the changelog should describe the impacts on to all affected SoCs.

As suggested by Vaibhav Bedia, now might be the right time to add this
function to the SoC specific function pointers (struct pwrdm_ops.)

Doing that, the existing function could be used for OMAP3 (and OMAP4 if
the changelog describes that it can/should be used for both.)

Then, when AM33xx support is added, it will be obvious where they will
need to plugin support for that SoC.

Kevin

> If the powerdomain is programmed to enter RET state and lose logic
> in RET state, knowing that the powerdomain entered RET is good enough
> to derive that the logic was lost as well, in such cases.
>
> Signed-off-by: Axel Haslam <axelhaslam@gmail.com>
> [rnayak@ti.com: Updated changelog, updated patch to support mem counters]
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
>  arch/arm/mach-omap2/powerdomain.c |   16 ++++++++++------
>  1 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c
> index 96ad3dbe..068f06b 100644
> --- a/arch/arm/mach-omap2/powerdomain.c
> +++ b/arch/arm/mach-omap2/powerdomain.c
> @@ -124,18 +124,22 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
>  static void _update_logic_membank_counters(struct powerdomain *pwrdm)
>  {
>  	int i;
> -	u8 prev_logic_pwrst, prev_mem_pwrst;
> +	int logic_pwrst, mem_pwrst;
> +
> +	logic_pwrst = pwrdm_read_prev_logic_pwrst(pwrdm);
> +	if (logic_pwrst == -EINVAL)
> +		logic_pwrst = pwrdm_read_logic_retst(pwrdm);
>  
> -	prev_logic_pwrst = pwrdm_read_prev_logic_pwrst(pwrdm);
>  	if ((pwrdm->pwrsts_logic_ret == PWRSTS_OFF_RET) &&
> -	    (prev_logic_pwrst == PWRDM_POWER_OFF))
> +	    (logic_pwrst == PWRDM_POWER_OFF))
>  		pwrdm->ret_logic_off_counter++;
>  
>  	for (i = 0; i < pwrdm->banks; i++) {
> -		prev_mem_pwrst = pwrdm_read_prev_mem_pwrst(pwrdm, i);
> -
> +		mem_pwrst = pwrdm_read_prev_mem_pwrst(pwrdm, i);
> +		if (mem_pwrst == -EINVAL)
> +			mem_pwrst = pwrdm_read_mem_retst(pwrdm, i);
>  		if ((pwrdm->pwrsts_mem_ret[i] == PWRSTS_OFF_RET) &&
> -		    (prev_mem_pwrst == PWRDM_POWER_OFF))
> +		    (mem_pwrst == PWRDM_POWER_OFF))
>  			pwrdm->ret_mem_off_counter[i]++;
>  	}
>  }

Re: [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters

[Tero Kristo]

On Mon, 2012-05-07 at 17:19 -0700, Kevin Hilman wrote:
> Tero Kristo <t-kristo@ti.com> writes:
> 
> > From: Axel Haslam <axelhaslam@gmail.com>
> >
> > On OMAP4, there is no support to read previous logic state
> > or previous memory state achieved when a power domain transitions
> > to RET. Instead there are module level context registers.
> >
> > In order to support the powerdomain level logic/mem_off_counters
> > on OMAP4, instead use the previous power state achieved (RET) and
> > the *programmed* logic/mem RET state to derive if a powerdomain lost
> > logic or did not.
> 
> OK, but this also changes the behavior for OMAP3 as well, right?  I
> don't see in the changelog how this affects OMAP3 and whether it is
> still expected to work on OMAP3.  When changing common code like this,
> the changelog should describe the impacts on to all affected SoCs.

Actually this doesn't change the behavior for OMAP3, as OMAP3 has
defined the ops for read_prev_logic_pwrst + read_prev_mem_pwrst. Looking
at the code more closely it might actually make more sense to implement
these for omap4 as well, instead of hacking this function. I'll check
this out and see if this can be done.

-Tero

> As suggested by Vaibhav Bedia, now might be the right time to add this
> function to the SoC specific function pointers (struct pwrdm_ops.)
> 
> Doing that, the existing function could be used for OMAP3 (and OMAP4 if
> the changelog describes that it can/should be used for both.)
> 
> Then, when AM33xx support is added, it will be obvious where they will
> need to plugin support for that SoC.
> 
> Kevin
> 
> > If the powerdomain is programmed to enter RET state and lose logic
> > in RET state, knowing that the powerdomain entered RET is good enough
> > to derive that the logic was lost as well, in such cases.
> >
> > Signed-off-by: Axel Haslam <axelhaslam@gmail.com>
> > [rnayak@ti.com: Updated changelog, updated patch to support mem counters]
> > Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> > Signed-off-by: Tero Kristo <t-kristo@ti.com>
> > ---
> >  arch/arm/mach-omap2/powerdomain.c |   16 ++++++++++------
> >  1 files changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/arm/mach-omap2/powerdomain.c b/arch/arm/mach-omap2/powerdomain.c
> > index 96ad3dbe..068f06b 100644
> > --- a/arch/arm/mach-omap2/powerdomain.c
> > +++ b/arch/arm/mach-omap2/powerdomain.c
> > @@ -124,18 +124,22 @@ static int _pwrdm_register(struct powerdomain *pwrdm)
> >  static void _update_logic_membank_counters(struct powerdomain *pwrdm)
> >  {
> >  	int i;
> > -	u8 prev_logic_pwrst, prev_mem_pwrst;
> > +	int logic_pwrst, mem_pwrst;
> > +
> > +	logic_pwrst = pwrdm_read_prev_logic_pwrst(pwrdm);
> > +	if (logic_pwrst == -EINVAL)
> > +		logic_pwrst = pwrdm_read_logic_retst(pwrdm);
> >  
> > -	prev_logic_pwrst = pwrdm_read_prev_logic_pwrst(pwrdm);
> >  	if ((pwrdm->pwrsts_logic_ret == PWRSTS_OFF_RET) &&
> > -	    (prev_logic_pwrst == PWRDM_POWER_OFF))
> > +	    (logic_pwrst == PWRDM_POWER_OFF))
> >  		pwrdm->ret_logic_off_counter++;
> >  
> >  	for (i = 0; i < pwrdm->banks; i++) {
> > -		prev_mem_pwrst = pwrdm_read_prev_mem_pwrst(pwrdm, i);
> > -
> > +		mem_pwrst = pwrdm_read_prev_mem_pwrst(pwrdm, i);
> > +		if (mem_pwrst == -EINVAL)
> > +			mem_pwrst = pwrdm_read_mem_retst(pwrdm, i);
> >  		if ((pwrdm->pwrsts_mem_ret[i] == PWRSTS_OFF_RET) &&
> > -		    (prev_mem_pwrst == PWRDM_POWER_OFF))
> > +		    (mem_pwrst == PWRDM_POWER_OFF))
> >  			pwrdm->ret_mem_off_counter[i]++;
> >  	}
> >  }

Re: [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters

[Tero Kristo]

On Mon, 2012-05-07 at 17:19 -0700, Kevin Hilman wrote:
> Tero Kristo <t-kristo@ti.com> writes:
> 
> > From: Axel Haslam <axelhaslam@gmail.com>
> >
> > On OMAP4, there is no support to read previous logic state
> > or previous memory state achieved when a power domain transitions
> > to RET. Instead there are module level context registers.
> >
> > In order to support the powerdomain level logic/mem_off_counters
> > on OMAP4, instead use the previous power state achieved (RET) and
> > the *programmed* logic/mem RET state to derive if a powerdomain lost
> > logic or did not.
> 
> OK, but this also changes the behavior for OMAP3 as well, right?  I
> don't see in the changelog how this affects OMAP3 and whether it is
> still expected to work on OMAP3.  When changing common code like this,
> the changelog should describe the impacts on to all affected SoCs.
> 
> As suggested by Vaibhav Bedia, now might be the right time to add this
> function to the SoC specific function pointers (struct pwrdm_ops.)
> 
> Doing that, the existing function could be used for OMAP3 (and OMAP4 if
> the changelog describes that it can/should be used for both.)
> 
> Then, when AM33xx support is added, it will be obvious where they will
> need to plugin support for that SoC.

How about the following patch? It will add a couple of redundant
read_prev_pwrst calls, but works in the same way as the original patch,
without touching the generic code. Also, as there have been talks about
adding caching for some of the pwrdm registers (especially the
prev_pwrst), this might not be that big of an issue.

If this looks good to you, I'll re-post the set with this patch.

-Tero


diff --git a/arch/arm/mach-omap2/powerdomain44xx.c
b/arch/arm/mach-omap2/powerdomain44xx.c
index 9bfb8a0..3d5e8d4 100644
--- a/arch/arm/mach-omap2/powerdomain44xx.c
+++ b/arch/arm/mach-omap2/powerdomain44xx.c
@@ -155,6 +155,14 @@ static int omap4_pwrdm_read_logic_retst(struct
powerdomain *pwrdm)
 	return v;
 }
 
+static int omap4_pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm)
+{
+	if (omap4_pwrdm_read_prev_pwrst(pwrdm) != PWRDM_POWER_RET)
+		return PWRDM_POWER_ON;
+
+	return omap4_pwrdm_read_logic_retst(pwrdm);
+}
+
 static int omap4_pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8
bank)
 {
 	u32 m, v;
@@ -183,6 +191,14 @@ static int omap4_pwrdm_read_mem_retst(struct
powerdomain *pwrdm, u8 bank)
 	return v;
 }
 
+static int omap4_pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm,
u8 bank)
+{
+	if (omap4_pwrdm_read_prev_pwrst(pwrdm) != PWRDM_POWER_RET)
+		return PWRDM_POWER_ON;
+
+	return omap4_pwrdm_read_mem_retst(pwrdm, bank);
+}
+
 static int omap4_pwrdm_wait_transition(struct powerdomain *pwrdm)
 {
 	u32 c = 0;
@@ -256,9 +272,11 @@ struct pwrdm_ops omap4_pwrdm_operations = {
 	.pwrdm_clear_all_prev_pwrst	= omap4_pwrdm_clear_all_prev_pwrst,
 	.pwrdm_set_logic_retst	= omap4_pwrdm_set_logic_retst,
 	.pwrdm_read_logic_pwrst	= omap4_pwrdm_read_logic_pwrst,
+	.pwrdm_read_prev_logic_pwrst	= omap4_pwrdm_read_prev_logic_pwrst,
 	.pwrdm_read_logic_retst	= omap4_pwrdm_read_logic_retst,
 	.pwrdm_read_mem_pwrst	= omap4_pwrdm_read_mem_pwrst,
 	.pwrdm_read_mem_retst	= omap4_pwrdm_read_mem_retst,
+	.pwrdm_read_prev_mem_pwrst	= omap4_pwrdm_read_prev_mem_pwrst,
 	.pwrdm_set_mem_onst	= omap4_pwrdm_set_mem_onst,
 	.pwrdm_set_mem_retst	= omap4_pwrdm_set_mem_retst,
 	.pwrdm_wait_transition	= omap4_pwrdm_wait_transition,

Re: [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters

[Rajendra Nayak]

On Tuesday 08 May 2012 02:06 PM, Tero Kristo wrote:
> On Mon, 2012-05-07 at 17:19 -0700, Kevin Hilman wrote:
>> Tero Kristo<t-kristo@ti.com>  writes:
>>
>>> From: Axel Haslam<axelhaslam@gmail.com>
>>>
>>> On OMAP4, there is no support to read previous logic state
>>> or previous memory state achieved when a power domain transitions
>>> to RET. Instead there are module level context registers.
>>>
>>> In order to support the powerdomain level logic/mem_off_counters
>>> on OMAP4, instead use the previous power state achieved (RET) and
>>> the *programmed* logic/mem RET state to derive if a powerdomain lost
>>> logic or did not.
>>
>> OK, but this also changes the behavior for OMAP3 as well, right?  I
>> don't see in the changelog how this affects OMAP3 and whether it is
>> still expected to work on OMAP3.  When changing common code like this,
>> the changelog should describe the impacts on to all affected SoCs.
>>
>> As suggested by Vaibhav Bedia, now might be the right time to add this
>> function to the SoC specific function pointers (struct pwrdm_ops.)
>>
>> Doing that, the existing function could be used for OMAP3 (and OMAP4 if
>> the changelog describes that it can/should be used for both.)
>>
>> Then, when AM33xx support is added, it will be obvious where they will
>> need to plugin support for that SoC.
>
> How about the following patch? It will add a couple of redundant
> read_prev_pwrst calls, but works in the same way as the original patch,
> without touching the generic code. Also, as there have been talks about
> adding caching for some of the pwrdm registers (especially the
> prev_pwrst), this might not be that big of an issue.
>
> If this looks good to you, I'll re-post the set with this patch.
>
> -Tero
>
>
> diff --git a/arch/arm/mach-omap2/powerdomain44xx.c
> b/arch/arm/mach-omap2/powerdomain44xx.c
> index 9bfb8a0..3d5e8d4 100644
> --- a/arch/arm/mach-omap2/powerdomain44xx.c
> +++ b/arch/arm/mach-omap2/powerdomain44xx.c
> @@ -155,6 +155,14 @@ static int omap4_pwrdm_read_logic_retst(struct
> powerdomain *pwrdm)
>   	return v;
>   }
>
> +static int omap4_pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm)
> +{
> +	if (omap4_pwrdm_read_prev_pwrst(pwrdm) != PWRDM_POWER_RET)
> +		return PWRDM_POWER_ON;
> +
> +	return omap4_pwrdm_read_logic_retst(pwrdm);

Looks good to me. Do these ever get called with target state programmed
to OFF?

regards,
Rajendra

> +}
> +
>   static int omap4_pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8
> bank)
>   {
>   	u32 m, v;
> @@ -183,6 +191,14 @@ static int omap4_pwrdm_read_mem_retst(struct
> powerdomain *pwrdm, u8 bank)
>   	return v;
>   }
>
> +static int omap4_pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm,
> u8 bank)
> +{
> +	if (omap4_pwrdm_read_prev_pwrst(pwrdm) != PWRDM_POWER_RET)
> +		return PWRDM_POWER_ON;
> +
> +	return omap4_pwrdm_read_mem_retst(pwrdm, bank);
> +}
> +
>   static int omap4_pwrdm_wait_transition(struct powerdomain *pwrdm)
>   {
>   	u32 c = 0;
> @@ -256,9 +272,11 @@ struct pwrdm_ops omap4_pwrdm_operations = {
>   	.pwrdm_clear_all_prev_pwrst	= omap4_pwrdm_clear_all_prev_pwrst,
>   	.pwrdm_set_logic_retst	= omap4_pwrdm_set_logic_retst,
>   	.pwrdm_read_logic_pwrst	= omap4_pwrdm_read_logic_pwrst,
> +	.pwrdm_read_prev_logic_pwrst	= omap4_pwrdm_read_prev_logic_pwrst,
>   	.pwrdm_read_logic_retst	= omap4_pwrdm_read_logic_retst,
>   	.pwrdm_read_mem_pwrst	= omap4_pwrdm_read_mem_pwrst,
>   	.pwrdm_read_mem_retst	= omap4_pwrdm_read_mem_retst,
> +	.pwrdm_read_prev_mem_pwrst	= omap4_pwrdm_read_prev_mem_pwrst,
>   	.pwrdm_set_mem_onst	= omap4_pwrdm_set_mem_onst,
>   	.pwrdm_set_mem_retst	= omap4_pwrdm_set_mem_retst,
>   	.pwrdm_wait_transition	= omap4_pwrdm_wait_transition,
>
>

Re: [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters

[Tero Kristo]

On Tue, 2012-05-08 at 14:27 +0530, Rajendra Nayak wrote:
> On Tuesday 08 May 2012 02:06 PM, Tero Kristo wrote:
> > On Mon, 2012-05-07 at 17:19 -0700, Kevin Hilman wrote:
> >> Tero Kristo<t-kristo@ti.com>  writes:
> >>
> >>> From: Axel Haslam<axelhaslam@gmail.com>
> >>>
> >>> On OMAP4, there is no support to read previous logic state
> >>> or previous memory state achieved when a power domain transitions
> >>> to RET. Instead there are module level context registers.
> >>>
> >>> In order to support the powerdomain level logic/mem_off_counters
> >>> on OMAP4, instead use the previous power state achieved (RET) and
> >>> the *programmed* logic/mem RET state to derive if a powerdomain lost
> >>> logic or did not.
> >>
> >> OK, but this also changes the behavior for OMAP3 as well, right?  I
> >> don't see in the changelog how this affects OMAP3 and whether it is
> >> still expected to work on OMAP3.  When changing common code like this,
> >> the changelog should describe the impacts on to all affected SoCs.
> >>
> >> As suggested by Vaibhav Bedia, now might be the right time to add this
> >> function to the SoC specific function pointers (struct pwrdm_ops.)
> >>
> >> Doing that, the existing function could be used for OMAP3 (and OMAP4 if
> >> the changelog describes that it can/should be used for both.)
> >>
> >> Then, when AM33xx support is added, it will be obvious where they will
> >> need to plugin support for that SoC.
> >
> > How about the following patch? It will add a couple of redundant
> > read_prev_pwrst calls, but works in the same way as the original patch,
> > without touching the generic code. Also, as there have been talks about
> > adding caching for some of the pwrdm registers (especially the
> > prev_pwrst), this might not be that big of an issue.
> >
> > If this looks good to you, I'll re-post the set with this patch.
> >
> > -Tero
> >
> >
> > diff --git a/arch/arm/mach-omap2/powerdomain44xx.c
> > b/arch/arm/mach-omap2/powerdomain44xx.c
> > index 9bfb8a0..3d5e8d4 100644
> > --- a/arch/arm/mach-omap2/powerdomain44xx.c
> > +++ b/arch/arm/mach-omap2/powerdomain44xx.c
> > @@ -155,6 +155,14 @@ static int omap4_pwrdm_read_logic_retst(struct
> > powerdomain *pwrdm)
> >   	return v;
> >   }
> >
> > +static int omap4_pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm)
> > +{
> > +	if (omap4_pwrdm_read_prev_pwrst(pwrdm) != PWRDM_POWER_RET)
> > +		return PWRDM_POWER_ON;
> > +
> > +	return omap4_pwrdm_read_logic_retst(pwrdm);
> 
> Looks good to me. Do these ever get called with target state programmed
> to OFF?

At least with current kernel code, no. But you are right, it might be
better to change these to check against > PWRDM_POWER_RET.

-Tero

> 
> regards,
> Rajendra
> 
> > +}
> > +
> >   static int omap4_pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8
> > bank)
> >   {
> >   	u32 m, v;
> > @@ -183,6 +191,14 @@ static int omap4_pwrdm_read_mem_retst(struct
> > powerdomain *pwrdm, u8 bank)
> >   	return v;
> >   }
> >
> > +static int omap4_pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm,
> > u8 bank)
> > +{
> > +	if (omap4_pwrdm_read_prev_pwrst(pwrdm) != PWRDM_POWER_RET)
> > +		return PWRDM_POWER_ON;
> > +
> > +	return omap4_pwrdm_read_mem_retst(pwrdm, bank);
> > +}
> > +
> >   static int omap4_pwrdm_wait_transition(struct powerdomain *pwrdm)
> >   {
> >   	u32 c = 0;
> > @@ -256,9 +272,11 @@ struct pwrdm_ops omap4_pwrdm_operations = {
> >   	.pwrdm_clear_all_prev_pwrst	= omap4_pwrdm_clear_all_prev_pwrst,
> >   	.pwrdm_set_logic_retst	= omap4_pwrdm_set_logic_retst,
> >   	.pwrdm_read_logic_pwrst	= omap4_pwrdm_read_logic_pwrst,
> > +	.pwrdm_read_prev_logic_pwrst	= omap4_pwrdm_read_prev_logic_pwrst,
> >   	.pwrdm_read_logic_retst	= omap4_pwrdm_read_logic_retst,
> >   	.pwrdm_read_mem_pwrst	= omap4_pwrdm_read_mem_pwrst,
> >   	.pwrdm_read_mem_retst	= omap4_pwrdm_read_mem_retst,
> > +	.pwrdm_read_prev_mem_pwrst	= omap4_pwrdm_read_prev_mem_pwrst,
> >   	.pwrdm_set_mem_onst	= omap4_pwrdm_set_mem_onst,
> >   	.pwrdm_set_mem_retst	= omap4_pwrdm_set_mem_retst,
> >   	.pwrdm_wait_transition	= omap4_pwrdm_wait_transition,
> >
> >
> 

Re: [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters

[Rajendra Nayak]

On Tuesday 08 May 2012 02:39 PM, Tero Kristo wrote:
> On Tue, 2012-05-08 at 14:27 +0530, Rajendra Nayak wrote:
>> On Tuesday 08 May 2012 02:06 PM, Tero Kristo wrote:
>>> On Mon, 2012-05-07 at 17:19 -0700, Kevin Hilman wrote:
>>>> Tero Kristo<t-kristo@ti.com>   writes:
>>>>
>>>>> From: Axel Haslam<axelhaslam@gmail.com>
>>>>>
>>>>> On OMAP4, there is no support to read previous logic state
>>>>> or previous memory state achieved when a power domain transitions
>>>>> to RET. Instead there are module level context registers.
>>>>>
>>>>> In order to support the powerdomain level logic/mem_off_counters
>>>>> on OMAP4, instead use the previous power state achieved (RET) and
>>>>> the *programmed* logic/mem RET state to derive if a powerdomain lost
>>>>> logic or did not.
>>>>
>>>> OK, but this also changes the behavior for OMAP3 as well, right?  I
>>>> don't see in the changelog how this affects OMAP3 and whether it is
>>>> still expected to work on OMAP3.  When changing common code like this,
>>>> the changelog should describe the impacts on to all affected SoCs.
>>>>
>>>> As suggested by Vaibhav Bedia, now might be the right time to add this
>>>> function to the SoC specific function pointers (struct pwrdm_ops.)
>>>>
>>>> Doing that, the existing function could be used for OMAP3 (and OMAP4 if
>>>> the changelog describes that it can/should be used for both.)
>>>>
>>>> Then, when AM33xx support is added, it will be obvious where they will
>>>> need to plugin support for that SoC.
>>>
>>> How about the following patch? It will add a couple of redundant
>>> read_prev_pwrst calls, but works in the same way as the original patch,
>>> without touching the generic code. Also, as there have been talks about
>>> adding caching for some of the pwrdm registers (especially the
>>> prev_pwrst), this might not be that big of an issue.
>>>
>>> If this looks good to you, I'll re-post the set with this patch.
>>>
>>> -Tero
>>>
>>>
>>> diff --git a/arch/arm/mach-omap2/powerdomain44xx.c
>>> b/arch/arm/mach-omap2/powerdomain44xx.c
>>> index 9bfb8a0..3d5e8d4 100644
>>> --- a/arch/arm/mach-omap2/powerdomain44xx.c
>>> +++ b/arch/arm/mach-omap2/powerdomain44xx.c
>>> @@ -155,6 +155,14 @@ static int omap4_pwrdm_read_logic_retst(struct
>>> powerdomain *pwrdm)
>>>    	return v;
>>>    }
>>>
>>> +static int omap4_pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm)
>>> +{
>>> +	if (omap4_pwrdm_read_prev_pwrst(pwrdm) != PWRDM_POWER_RET)
>>> +		return PWRDM_POWER_ON;
>>> +
>>> +	return omap4_pwrdm_read_logic_retst(pwrdm);
>>
>> Looks good to me. Do these ever get called with target state programmed
>> to OFF?
>
> At least with current kernel code, no. But you are right, it might be
> better to change these to check against>  PWRDM_POWER_RET.

But in case of target power state being programmed to OFF, the logic
retst might not be programmed at all, so in case of target state being
OFF, returning the logic retst programmed might as well return
PWRDM_POWER_ON itself, right?

>
> -Tero
>
>>
>> regards,
>> Rajendra
>>
>>> +}
>>> +
>>>    static int omap4_pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8
>>> bank)
>>>    {
>>>    	u32 m, v;
>>> @@ -183,6 +191,14 @@ static int omap4_pwrdm_read_mem_retst(struct
>>> powerdomain *pwrdm, u8 bank)
>>>    	return v;
>>>    }
>>>
>>> +static int omap4_pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm,
>>> u8 bank)
>>> +{
>>> +	if (omap4_pwrdm_read_prev_pwrst(pwrdm) != PWRDM_POWER_RET)
>>> +		return PWRDM_POWER_ON;
>>> +
>>> +	return omap4_pwrdm_read_mem_retst(pwrdm, bank);
>>> +}
>>> +
>>>    static int omap4_pwrdm_wait_transition(struct powerdomain *pwrdm)
>>>    {
>>>    	u32 c = 0;
>>> @@ -256,9 +272,11 @@ struct pwrdm_ops omap4_pwrdm_operations = {
>>>    	.pwrdm_clear_all_prev_pwrst	= omap4_pwrdm_clear_all_prev_pwrst,
>>>    	.pwrdm_set_logic_retst	= omap4_pwrdm_set_logic_retst,
>>>    	.pwrdm_read_logic_pwrst	= omap4_pwrdm_read_logic_pwrst,
>>> +	.pwrdm_read_prev_logic_pwrst	= omap4_pwrdm_read_prev_logic_pwrst,
>>>    	.pwrdm_read_logic_retst	= omap4_pwrdm_read_logic_retst,
>>>    	.pwrdm_read_mem_pwrst	= omap4_pwrdm_read_mem_pwrst,
>>>    	.pwrdm_read_mem_retst	= omap4_pwrdm_read_mem_retst,
>>> +	.pwrdm_read_prev_mem_pwrst	= omap4_pwrdm_read_prev_mem_pwrst,
>>>    	.pwrdm_set_mem_onst	= omap4_pwrdm_set_mem_onst,
>>>    	.pwrdm_set_mem_retst	= omap4_pwrdm_set_mem_retst,
>>>    	.pwrdm_wait_transition	= omap4_pwrdm_wait_transition,
>>>
>>>
>>
>
>

Re: [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters

[Tero Kristo]

On Tue, 2012-05-08 at 14:45 +0530, Rajendra Nayak wrote:
> On Tuesday 08 May 2012 02:39 PM, Tero Kristo wrote:
> > On Tue, 2012-05-08 at 14:27 +0530, Rajendra Nayak wrote:
> >> On Tuesday 08 May 2012 02:06 PM, Tero Kristo wrote:
> >>> On Mon, 2012-05-07 at 17:19 -0700, Kevin Hilman wrote:
> >>>> Tero Kristo<t-kristo@ti.com>   writes:
> >>>>
> >>>>> From: Axel Haslam<axelhaslam@gmail.com>
> >>>>>
> >>>>> On OMAP4, there is no support to read previous logic state
> >>>>> or previous memory state achieved when a power domain transitions
> >>>>> to RET. Instead there are module level context registers.
> >>>>>
> >>>>> In order to support the powerdomain level logic/mem_off_counters
> >>>>> on OMAP4, instead use the previous power state achieved (RET) and
> >>>>> the *programmed* logic/mem RET state to derive if a powerdomain lost
> >>>>> logic or did not.
> >>>>
> >>>> OK, but this also changes the behavior for OMAP3 as well, right?  I
> >>>> don't see in the changelog how this affects OMAP3 and whether it is
> >>>> still expected to work on OMAP3.  When changing common code like this,
> >>>> the changelog should describe the impacts on to all affected SoCs.
> >>>>
> >>>> As suggested by Vaibhav Bedia, now might be the right time to add this
> >>>> function to the SoC specific function pointers (struct pwrdm_ops.)
> >>>>
> >>>> Doing that, the existing function could be used for OMAP3 (and OMAP4 if
> >>>> the changelog describes that it can/should be used for both.)
> >>>>
> >>>> Then, when AM33xx support is added, it will be obvious where they will
> >>>> need to plugin support for that SoC.
> >>>
> >>> How about the following patch? It will add a couple of redundant
> >>> read_prev_pwrst calls, but works in the same way as the original patch,
> >>> without touching the generic code. Also, as there have been talks about
> >>> adding caching for some of the pwrdm registers (especially the
> >>> prev_pwrst), this might not be that big of an issue.
> >>>
> >>> If this looks good to you, I'll re-post the set with this patch.
> >>>
> >>> -Tero
> >>>
> >>>
> >>> diff --git a/arch/arm/mach-omap2/powerdomain44xx.c
> >>> b/arch/arm/mach-omap2/powerdomain44xx.c
> >>> index 9bfb8a0..3d5e8d4 100644
> >>> --- a/arch/arm/mach-omap2/powerdomain44xx.c
> >>> +++ b/arch/arm/mach-omap2/powerdomain44xx.c
> >>> @@ -155,6 +155,14 @@ static int omap4_pwrdm_read_logic_retst(struct
> >>> powerdomain *pwrdm)
> >>>    	return v;
> >>>    }
> >>>
> >>> +static int omap4_pwrdm_read_prev_logic_pwrst(struct powerdomain *pwrdm)
> >>> +{
> >>> +	if (omap4_pwrdm_read_prev_pwrst(pwrdm) != PWRDM_POWER_RET)
> >>> +		return PWRDM_POWER_ON;
> >>> +
> >>> +	return omap4_pwrdm_read_logic_retst(pwrdm);
> >>
> >> Looks good to me. Do these ever get called with target state programmed
> >> to OFF?
> >
> > At least with current kernel code, no. But you are right, it might be
> > better to change these to check against>  PWRDM_POWER_RET.
> 
> But in case of target power state being programmed to OFF, the logic
> retst might not be programmed at all, so in case of target state being
> OFF, returning the logic retst programmed might as well return
> PWRDM_POWER_ON itself, right?

You are right, so better to check against OFF and return prev logic +
membank states as OFF also if that is the case, and with RET, return the
programmed state.

-Tero

> 
> >
> > -Tero
> >
> >>
> >> regards,
> >> Rajendra
> >>
> >>> +}
> >>> +
> >>>    static int omap4_pwrdm_read_mem_pwrst(struct powerdomain *pwrdm, u8
> >>> bank)
> >>>    {
> >>>    	u32 m, v;
> >>> @@ -183,6 +191,14 @@ static int omap4_pwrdm_read_mem_retst(struct
> >>> powerdomain *pwrdm, u8 bank)
> >>>    	return v;
> >>>    }
> >>>
> >>> +static int omap4_pwrdm_read_prev_mem_pwrst(struct powerdomain *pwrdm,
> >>> u8 bank)
> >>> +{
> >>> +	if (omap4_pwrdm_read_prev_pwrst(pwrdm) != PWRDM_POWER_RET)
> >>> +		return PWRDM_POWER_ON;
> >>> +
> >>> +	return omap4_pwrdm_read_mem_retst(pwrdm, bank);
> >>> +}
> >>> +
> >>>    static int omap4_pwrdm_wait_transition(struct powerdomain *pwrdm)
> >>>    {
> >>>    	u32 c = 0;
> >>> @@ -256,9 +272,11 @@ struct pwrdm_ops omap4_pwrdm_operations = {
> >>>    	.pwrdm_clear_all_prev_pwrst	= omap4_pwrdm_clear_all_prev_pwrst,
> >>>    	.pwrdm_set_logic_retst	= omap4_pwrdm_set_logic_retst,
> >>>    	.pwrdm_read_logic_pwrst	= omap4_pwrdm_read_logic_pwrst,
> >>> +	.pwrdm_read_prev_logic_pwrst	= omap4_pwrdm_read_prev_logic_pwrst,
> >>>    	.pwrdm_read_logic_retst	= omap4_pwrdm_read_logic_retst,
> >>>    	.pwrdm_read_mem_pwrst	= omap4_pwrdm_read_mem_pwrst,
> >>>    	.pwrdm_read_mem_retst	= omap4_pwrdm_read_mem_retst,
> >>> +	.pwrdm_read_prev_mem_pwrst	= omap4_pwrdm_read_prev_mem_pwrst,
> >>>    	.pwrdm_set_mem_onst	= omap4_pwrdm_set_mem_onst,
> >>>    	.pwrdm_set_mem_retst	= omap4_pwrdm_set_mem_retst,
> >>>    	.pwrdm_wait_transition	= omap4_pwrdm_wait_transition,
> >>>
> >>>
> >>
> >
> >
> 

[PATCHv4 7/8] ARM: OMAP4: PM: Add next_logic_state param to power_state

[Tero Kristo]

This will make it easier to handle next logic states for power domains
during suspend. With this patch, the parameter is also programmed to
retention for every powerdomain, thus all powerdomains enter CSWR
state after this patch.

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

diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 31990d5..cc85576 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -26,6 +26,7 @@
 struct power_state {
 	struct powerdomain *pwrdm;
 	u32 next_state;
+	u32 next_logic_state;
 #ifdef CONFIG_SUSPEND
 	u32 saved_state;
 	u32 saved_logic_state;
@@ -51,7 +52,7 @@ static int omap4_pm_suspend(void)
 	/* Set targeted power domain states by suspend */
 	list_for_each_entry(pwrst, &pwrst_list, node) {
 		omap_set_pwrdm_state(pwrst->pwrdm, pwrst->next_state);
-		pwrdm_set_logic_retst(pwrst->pwrdm, PWRDM_POWER_OFF);
+		pwrdm_set_logic_retst(pwrst->pwrdm, pwrst->next_logic_state);
 	}
 
 	/*
@@ -108,6 +109,7 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
 
 	pwrst->pwrdm = pwrdm;
 	pwrst->next_state = PWRDM_POWER_RET;
+	pwrst->next_logic_state = PWRDM_POWER_RET;
 	list_add(&pwrst->node, &pwrst_list);
 
 	return omap_set_pwrdm_state(pwrst->pwrdm, pwrst->next_state);
-- 
1.7.4.1

[PATCHv4 8/8] ARM: OMAP4: PM: Added option for enabling OSWR

[Tero Kristo]

PM debug now contains a file that can be used to control OSWR support
enable / disable on OMAP4. Also removed the off_mode_enable file for
the same platform as it is unsupported.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/mach-omap2/pm-debug.c |   20 ++++++++++++++++----
 arch/arm/mach-omap2/pm.h       |    1 +
 arch/arm/mach-omap2/pm44xx.c   |   16 ++++++++++++++++
 3 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
index 814bcd9..d9a8e42 100644
--- a/arch/arm/mach-omap2/pm-debug.c
+++ b/arch/arm/mach-omap2/pm-debug.c
@@ -39,6 +39,7 @@
 #include "pm.h"
 
 u32 enable_off_mode;
+static u32 enable_oswr_mode;
 
 #ifdef CONFIG_DEBUG_FS
 #include <linux/debugfs.h>
@@ -247,10 +248,13 @@ static int option_set(void *data, u64 val)
 			omap_pm_enable_off_mode();
 		else
 			omap_pm_disable_off_mode();
-		if (cpu_is_omap34xx())
-			omap3_pm_off_mode_enable(val);
+
+		omap3_pm_off_mode_enable(val);
 	}
 
+	if (option == &enable_oswr_mode)
+		omap4_pm_oswr_mode_enable(val);
+
 	return 0;
 }
 
@@ -274,8 +278,16 @@ static int __init pm_dbg_init(void)
 
 	pwrdm_for_each(pwrdms_setup, (void *)d);
 
-	(void) debugfs_create_file("enable_off_mode", S_IRUGO | S_IWUSR, d,
-				   &enable_off_mode, &pm_dbg_option_fops);
+	if (cpu_is_omap34xx())
+		(void) debugfs_create_file("enable_off_mode",
+			S_IRUGO | S_IWUSR, d, &enable_off_mode,
+			&pm_dbg_option_fops);
+
+	if (cpu_is_omap44xx())
+		(void) debugfs_create_file("enable_oswr_mode",
+			S_IRUGO | S_IWUSR, d, &enable_oswr_mode,
+			&pm_dbg_option_fops);
+
 	pm_dbg_init_done = 1;
 
 	return 0;
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index 256e63c..07ad800 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -17,6 +17,7 @@
 
 extern void *omap3_secure_ram_storage;
 extern void omap3_pm_off_mode_enable(int);
+extern void omap4_pm_oswr_mode_enable(int);
 extern void omap_sram_idle(void);
 extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
 extern int omap3_idle_init(void);
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index cc85576..07ac0d3 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -115,6 +115,22 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
 	return omap_set_pwrdm_state(pwrst->pwrdm, pwrst->next_state);
 }
 
+void omap4_pm_oswr_mode_enable(int enable)
+{
+	u32 next_logic_state;
+	struct power_state *pwrst;
+
+	if (enable)
+		next_logic_state = PWRDM_POWER_OFF;
+	else
+		next_logic_state = PWRDM_POWER_RET;
+
+	list_for_each_entry(pwrst, &pwrst_list, node) {
+		pwrst->next_logic_state = next_logic_state;
+		pwrdm_set_logic_retst(pwrst->pwrdm, pwrst->next_logic_state);
+	}
+}
+
 /**
  * omap_default_idle - OMAP4 default ilde routine.'
  *
-- 
1.7.4.1

Re: [PATCHv4 8/8] ARM: OMAP4: PM: Added option for enabling OSWR

[Jean Pihet]

Hi Tero,

On Fri, Apr 20, 2012 at 11:19 AM, Tero Kristo <t-kristo@ti.com> wrote:
> PM debug now contains a file that can be used to control OSWR support
> enable / disable on OMAP4. Also removed the off_mode_enable file for
> the same platform as it is unsupported.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
>  arch/arm/mach-omap2/pm-debug.c |   20 ++++++++++++++++----
>  arch/arm/mach-omap2/pm.h       |    1 +
>  arch/arm/mach-omap2/pm44xx.c   |   16 ++++++++++++++++
>  3 files changed, 33 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm-debug.c b/arch/arm/mach-omap2/pm-debug.c
> index 814bcd9..d9a8e42 100644
> --- a/arch/arm/mach-omap2/pm-debug.c
> +++ b/arch/arm/mach-omap2/pm-debug.c
> @@ -39,6 +39,7 @@
>  #include "pm.h"
>
>  u32 enable_off_mode;
> +static u32 enable_oswr_mode;
>
>  #ifdef CONFIG_DEBUG_FS
>  #include <linux/debugfs.h>
> @@ -247,10 +248,13 @@ static int option_set(void *data, u64 val)
>                        omap_pm_enable_off_mode();
>                else
>                        omap_pm_disable_off_mode();
> -               if (cpu_is_omap34xx())
> -                       omap3_pm_off_mode_enable(val);
> +
> +               omap3_pm_off_mode_enable(val);
Great since this change removes a non-init cpu_is_xxx check.

>        }
>
> +       if (option == &enable_oswr_mode)
> +               omap4_pm_oswr_mode_enable(val);
> +
>        return 0;
>  }
>
> @@ -274,8 +278,16 @@ static int __init pm_dbg_init(void)
>
>        pwrdm_for_each(pwrdms_setup, (void *)d);
>
> -       (void) debugfs_create_file("enable_off_mode", S_IRUGO | S_IWUSR, d,
> -                                  &enable_off_mode, &pm_dbg_option_fops);
> +       if (cpu_is_omap34xx())
> +               (void) debugfs_create_file("enable_off_mode",
> +                       S_IRUGO | S_IWUSR, d, &enable_off_mode,
> +                       &pm_dbg_option_fops);
Is the enable_off_mode entry needed on other OMAP platorms (OMAP<3)?

> +
> +       if (cpu_is_omap44xx())
> +               (void) debugfs_create_file("enable_oswr_mode",
> +                       S_IRUGO | S_IWUSR, d, &enable_oswr_mode,
> +                       &pm_dbg_option_fops);
> +
>        pm_dbg_init_done = 1;

Regards,
Jean
--
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

Re: [PATCHv4 8/8] ARM: OMAP4: PM: Added option for enabling OSWR

[Tero Kristo]

<clip>

> > @@ -274,8 +278,16 @@ static int __init pm_dbg_init(void)
> >
> >        pwrdm_for_each(pwrdms_setup, (void *)d);
> >
> > -       (void) debugfs_create_file("enable_off_mode", S_IRUGO | S_IWUSR, d,
> > -                                  &enable_off_mode, &pm_dbg_option_fops);
> > +       if (cpu_is_omap34xx())
> > +               (void) debugfs_create_file("enable_off_mode",
> > +                       S_IRUGO | S_IWUSR, d, &enable_off_mode,
> > +                       &pm_dbg_option_fops);
> Is the enable_off_mode entry needed on other OMAP platorms (OMAP<3)?

Actually I am not sure, I've never used OMAP2. It looks like at least
the kernel does not support off-mode for OMAP2, but according to TRM it
might be possible to support it on HW.

-Tero