ARM: OMAP4: core retention support

From: Rajendra Nayak <[email protected]>

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

Signed-off-by Rajendra Nayak <[email protected]>

Signed-off-by Tero Kristo <[email protected]>

---

From: Rajendra Nayak <[email protected]>

patch adds IO Daisychain support for OMAP4 as per section 3.9.4 in OMAP4430 Public TRM.

Signed-off-by Rajendra Nayak <[email protected]>

Signed-off-by Vishwanath BS <[email protected]>

Signed-off-by Tero Kristo <[email protected]>

---
?arch/arm/mach-omap2/prm44xx.c | ? 32 ++++++++++++++++++++++++++++++++ ?arch/arm/mach-omap2/prm44xx.h | ? ?1 +
?2 files changed, 33 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/prm44xx.c +0 -0

index 33dd655..1557647 100644

On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristo<[email protected]> wrote:

arch/arm/mach-omap2/prm44xx.c void omap44xx_prm_restore_irqen(u32 *saved_mask) · line 238

Quoted 7 lines

arch/arm/mach-omap2/prm44xx.c +6 -0

+/**
+ * Maximum time(us) it takes to output the signal WUCLKOUT of the last pad of
+ * the I/O ring after asserting WUCLKIN high
+ */
+#define MAX_IOPAD_LATCH_TIME 1000
+

Is the 1000 us/ms ?

Is that documented or arbitrary chosen ?

Rest of the change looks good to me.

regards
santosh

Quoted 2 lines · Santosh

On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristo<[email protected]> ?wrote:

[..]

Quoted 10 lines

Review

Quoted 8 lines

+/**
+ * Maximum time(us) it takes to output the signal WUCLKOUT of the last pad of
+ * the I/O ring after asserting WUCLKIN high
+ */

(quoted diff) +2 -0

+#define MAX_IOPAD_LATCH_TIME 1000
+

Is the 1000 us/ms ?

1000 us.

Quoted 1 line

Is that documented or arbitrary chosen ?

looks like it was arbitrarily chosen as there's no documentation on the worst case delay. I spoke to Nilesh (copied) and he suggested using a value close to 100us instead which should be quite safe. 1000us according to him is really very high.
however there does not seem to be any documented value available for this in any of the specs.

Hi Kristo,

I think you must also add a omap_test_timeout() check after the Trigger WUCLKIN disable, to verify WUCLK_STATUS has come back to 0. This is needed because the IO daisy chain will not be ready until the WUCLKIN falling edge has propagated.

(quoted diff) +10 -0

+	/* Trigger WUCLKIN disable */
+	omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, 0x0,
+			OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET);
+	return;
+	omap_test_timeout(
+		(((omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+			OMAP4_PRM_IO_PMCTRL_OFFSET)&
+			OMAP4430_WUCLK_STATUS_MASK)>>
+			OMAP4430_WUCLK_STATUS_SHIFT) == 0),
+		MAX_IOPAD_LATCH_TIME, i);

Best regards
Djamil ELA?DI
+33 4 97 27 50 97
Software Systems Engineer
OMAP Platform Business Unit - PSI Modem Integration Texas Instruments

-----Original Message-----
From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-owner at vger.kernel.org] On Behalf Of Kristo, Tero
Sent: jeudi 23 f?vrier 2012 14:22
To: linux-omap at vger.kernel.org; Hilman, Kevin
Cc: linux-arm-kernel at lists.infradead.org; Nayak, Rajendra; Sripathy, Vishwanath
Subject: [PATCH 2/6] ARM: OMAP4 PM: Add IO Daisychain support

From: Rajendra Nayak<[email protected]>

patch adds IO Daisychain support for OMAP4 as per section 3.9.4 in OMAP4430 Public TRM.

Signed-off-by Rajendra Nayak<[email protected]>

Signed-off-by Vishwanath BS<[email protected]>

Signed-off-by Tero Kristo<[email protected]>

---
  arch/arm/mach-omap2/prm44xx.c |   32 ++++++++++++++++++++++++++++++++
  arch/arm/mach-omap2/prm44xx.h |    1 +
  2 files changed, 33 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/prm44xx.c +35 -0

index 33dd655..1557647 100644
@@ -230,6 +230,41 @@ void omap44xx_prm_restore_irqen(u32 *saved_mask)
  				 OMAP4_PRM_IRQENABLE_MPU_2_OFFSET);
  }
 
+/**
+ * Maximum time(us) it takes to output the signal WUCLKOUT of the last pad of
+ * the I/O ring after asserting WUCLKIN high
+ */
+#define MAX_IOPAD_LATCH_TIME 1000
+
+/* OMAP4 IO Daisychain trigger sequence */
+void omap4_trigger_wuclk_ctrl(void)
+{
+	int i = 0;
+
+	/* Enable GLOBAL_WUEN */
+	if (!(omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+		OMAP4_PRM_IO_PMCTRL_OFFSET)&  OMAP4430_GLOBAL_WUEN_MASK))
+		omap4_prm_rmw_inst_reg_bits(OMAP4430_GLOBAL_WUEN_MASK,
+			OMAP4430_GLOBAL_WUEN_MASK, OMAP4430_PRM_DEVICE_INST,
+			OMAP4_PRM_IO_PMCTRL_OFFSET);
+
+	/* Trigger WUCLKIN enable */
+	omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK,
+			OMAP4430_WUCLK_CTRL_MASK, OMAP4430_PRM_DEVICE_INST,
+			OMAP4_PRM_IO_PMCTRL_OFFSET);
+	omap_test_timeout(
+		(((omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+			OMAP4_PRM_IO_PMCTRL_OFFSET)&
+			OMAP4430_WUCLK_STATUS_MASK)>>
+			OMAP4430_WUCLK_STATUS_SHIFT) == 1),
+		MAX_IOPAD_LATCH_TIME, i);
+
+	/* Trigger WUCLKIN disable */
+	omap4_prm_rmw_inst_reg_bits(OMAP4430_WUCLK_CTRL_MASK, 0x0,
+			OMAP4430_PRM_DEVICE_INST, OMAP4_PRM_IO_PMCTRL_OFFSET);
+	return;
+}
+
  static int __init omap4xxx_prcm_init(void)
  {
  	if (cpu_is_omap44xx())

arch/arm/mach-omap2/prm44xx.h +1 -0

index 7978092..a840f0f 100644
@@ -762,6 +762,7 @@ void omap4_prm_vp_clear_txdone(u8 vp_id);
  extern u32 omap4_prm_vcvp_read(u8 offset);
  extern void omap4_prm_vcvp_write(u32 val, u8 offset);
  extern u32 omap4_prm_vcvp_rmw(u32 mask, u32 bits, u8 offset);
+extern void omap4_trigger_wuclk_ctrl(void);
 
  /* PRM interrupt-related functions */
  extern void omap44xx_prm_read_pending_irqs(unsigned long *events);

From: Vishwanath BS <[email protected]>

IO Daisychain feature has to be triggered whenever there is a change in device's mux configuration (See section 3.9.4 in OMAP4 Public TRM vP).

Now devices can idle independent of the powerdomain, there can be a window where device is idled and corresponding powerdomain can be ON/INACTIVE state. In such situations, since both module wake up is enabled at padlevel as well as io daisychain sequence is triggered, there will be 2 PRCM interrupts (Module async wake up via swakeup and IO Pad interrupt). But as PRCM Interrupt handler clears the Module Padlevel WKST bit in the first interrupt, module specific interrupt handler will not triggered for the second time

Also look at detailed explanation given by Rajendra at
http://www.spinics.net/lists/linux-serial/msg04480.html

Signed-off-by Vishwanath BS <[email protected]>

Signed-off-by Tero Kristo <[email protected]>

---

?arch/arm/mach-omap2/omap_hwmod.c | ? ?9 +++++++--
?arch/arm/mach-omap2/pm.c ? ? ? ? | ? ?7 +++++++
?arch/arm/mach-omap2/pm.h ? ? ? ? | ? ?1 +

?3 files changed, 15 insertions(+), 2 deletions(-)

arch/arm/mach-omap2/pm.c +0 -0

index 1881fe9..e8b54eb 100644
@@ -25,6 +25,7 @@

?#include "clockdomain.h"
?#include "pm.h"
?#include "twl-common.h"
+#include "prm44xx.h"

?static struct omap_device_pm_latency *pm_lats;

Quoted 25 lines · Tero Kristo

From: Vishwanath BS <[email protected]>

IO Daisychain feature has to be triggered whenever there is a change in device's mux configuration (See section 3.9.4 in OMAP4 Public TRM vP).

Now devices can idle independent of the powerdomain, there can be a window where device is idled and corresponding powerdomain can be ON/INACTIVE state. In such situations, since both module wake up is enabled at padlevel as well as io daisychain sequence is triggered, there will be 2 PRCM interrupts (Module async wake up via swakeup and IO Pad interrupt). But as PRCM Interrupt handler clears the Module Padlevel WKST bit in the first interrupt, module specific interrupt handler will not triggered for the second time

Also look at detailed explanation given by Rajendra at
http://www.spinics.net/lists/linux-serial/msg04480.html

Signed-off-by Vishwanath BS <[email protected]>

Signed-off-by Tero Kristo <[email protected]>

---
 arch/arm/mach-omap2/omap_hwmod.c |    9 +++++++--
 arch/arm/mach-omap2/pm.c         |    7 +++++++
 arch/arm/mach-omap2/pm.h         |    1 +
 3 files changed, 15 insertions(+), 2 deletions(-)

[...]

Quoted 17 lines

arch/arm/mach-omap2/pm.c +1 -0

index 1881fe9..e8b54eb 100644
@@ -25,6 +25,7 @@
 #include "clockdomain.h"
 #include "pm.h"
 #include "twl-common.h"
+#include "prm44xx.h"
 
 static struct omap_device_pm_latency *pm_lats;
 

@@ -64,6 +65,12 @@ static void omap2_init_processor_devices(void)
       }
 }
 

arch/arm/mach-omap2/pm.c static void omap2_init_processor_devices(void) · line 70

Quoted 3 lines

arch/arm/mach-omap2/pm.c +3 -0

+void omap_trigger_wuclk_ctrl(void)
+{
+       if (cpu_is_omap44xx())

can we avoid above check to make it generic so that even OMAP5 can use this code without any change. Some flag might do the trick.

Rest of the patch looks fine to me.

Regards
Santosh

From: Vishwanath BS <[email protected]>

IO Daisychain feature has to be triggered whenever there is a change in device's mux configuration (See section 3.9.4 in OMAP4 Public TRM vP).

Now devices can idle independent of the powerdomain, there can be a window where device is idled and corresponding powerdomain can be ON/INACTIVE state. In such situations, since both module wake up is enabled at padlevel as well as io daisychain sequence is triggered, there will be 2 PRCM interrupts (Module async wake up via swakeup and IO Pad interrupt). But as PRCM Interrupt handler clears the Module Padlevel WKST bit in the first interrupt, module specific interrupt handler will not triggered for the second time

Also look at detailed explanation given by Rajendra at
http://www.spinics.net/lists/linux-serial/msg04480.html

Signed-off-by Vishwanath BS <[email protected]>

Signed-off-by Tero Kristo <[email protected]>

Previous code used wrong instance for the interrupt register access. Use the right one which is OCP_SOCKET.

Signed-off-by Tero Kristo <[email protected]>

Cc Paul Walmsley <[email protected]>

---
 arch/arm/mach-omap2/prm44xx.c |   21 +++++++++++----------
 1 files changed, 11 insertions(+), 10 deletions(-)

arch/arm/mach-omap2/prm44xx.c +0 -0

index 1557647..a6efbdf 100644

From: Rajendra Nayak <[email protected]>

With no driver handling DSP/TESLA, if brought out of reset, it stays active and does not assert standby.

Signed-off-by Rajendra Nayak <[email protected]>

Signed-off-by Tero Kristo <[email protected]>

---

$Subject
s/dsp/DSP
s/tesla/TESLA

Quoted 5 lines

From: Rajendra Nayak<[email protected]>

With no driver handling DSP/TESLA, if brought out of reset, it stays active and does not assert standby.

Which lead to IVHA PD not transitiong and hence gating CHIP retention. You may want to add these bits as well.

Quoted 3 lines

Signed-off-by Rajendra Nayak<[email protected]>

Signed-off-by Tero Kristo<[email protected]>

---

Patch is fine though script needs to be updated I guess

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

From: Rajendra Nayak <[email protected]>

With no driver handling DSP/TESLA, if brought out of reset, it stays active and does not assert standby.

Signed-off-by Rajendra Nayak <[email protected]>

Signed-off-by Tero Kristo <[email protected]>

---
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/omap_hwmod_44xx_data.c +1 -0

index ef0524c..81d90da 100644
@@ -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),

Quoted 2 lines · Tero Kristo

From: Rajendra Nayak<[email protected]>

Quoted 5 lines

With no driver handling DSP/TESLA, if brought out of reset, it stays active and does not assert standby.

Signed-off-by Rajendra Nayak<[email protected]>

Signed-off-by Tero Kristo<[email protected]>

Subject says 'OMAP4: suspend'. How does HWMOD_INIT_NO_RESET affect suspend?

Kevin

Quoted 16 lines

---
  arch/arm/mach-omap2/omap_hwmod_44xx_data.c |    1 +
  1 files changed, 1 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/omap_hwmod_44xx_data.c +1 -0

index ef0524c..81d90da 100644
@@ -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),

This set adds core retention support on top of mainline. The set also adds IO CHAIN wakeup capability for OMAP4, which is a nice feature to have while trying suspend / resume with CSWR as it is quite difficult to wake up the device without this.

Patch 6 might cause some stir, but this is needed as omap4 PRCM chain handler currently does not work without SPARSE_IRQ. Enabling the SPARSE_IRQ causes a WARN from gic during boot for omap4, and attempting to fix this creates some spam from interrupt handling code which seems to originate from GPMC/GPIO. Also, omap3 boot breaks completely, thus it is impossible to enable this option as of now.

Tested on OMAP4 blaze board, with OMAP4430 EMU chip. Suspend / resume works nicely, and wakeup with UART3 works. The powerdomain state info under pm-debug appears to be somewhat bogus right after boot, but fixes itself during suspend. This should be addressed separately. Also verified that suspend / resume with OMAP3 beagle is okay.

Quoted 12 lines · Tero Kristo

This set adds core retention support on top of mainline. The set also adds IO CHAIN wakeup capability for OMAP4, which is a nice feature to have while trying suspend / resume with CSWR as it is quite difficult to wake up the device without this.

Patch 6 might cause some stir, but this is needed as omap4 PRCM chain handler currently does not work without SPARSE_IRQ. Enabling the SPARSE_IRQ causes a WARN from gic during boot for omap4, and attempting to fix this creates some spam from interrupt handling code which seems to originate from GPMC/GPIO. Also, omap3 boot breaks completely, thus it is impossible to enable this option as of now.

Quoted 5 lines

Tested on OMAP4 blaze board, with OMAP4430 EMU chip. Suspend / resume works nicely, and wakeup with UART3 works. The powerdomain state info under pm-debug appears to be somewhat bogus right after boot, but fixes itself during suspend. This should be addressed separately. Also verified that suspend / resume with OMAP3 beagle is okay.

Please separate out the IO daisy chain stuff as a separate series.

Vishwa had a multiple patch series that cleaned some of this up and also made it common for OMAP3 and 4.

   http://marc.info/?l=linux-omap&m=132387916807059&w=2

I had several review comments on that series that were never responded to,

   http://marc.info/?l=linux-omap&w=2&r=1&s=DaisyChain&q=b

so I'd first like to understand why that series was dropped and only selected parts were taken for $SUBJECT series, and what is the plan for the IO daisy chain series.