[PATCH 0/6] ARM: OMAP4: core retention support

[PATCH 0/6] ARM: OMAP4: core retention support

[Tero Kristo]

Hi,

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.

-Tero

[PATCH 0/6] ARM: OMAP4: core retention support

[Tero Kristo]

Hi,

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.

-Tero

[PATCH 1/6] arm: omap4: suspend: Program all domains to RET

[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>
---
 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 c264ef7..1ab30a3 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -151,12 +151,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

[PATCH 1/6] arm: omap4: suspend: Program all domains to RET

[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>
---
 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 c264ef7..1ab30a3 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -151,12 +151,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

Re: [PATCH 1/6] arm: omap4: suspend: Program all domains to RET

[Shilimkar, Santosh]

On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristo <t-kristo@ti.com> wrote:
> 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>
> ---

$subject
arm: omap4: suspend: Program all domains to RET
s/arm/ARM
s/omap4/OMAP4
s/RET/retention

o.w looks good.
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

[PATCH 1/6] arm: omap4: suspend: Program all domains to RET

[Shilimkar, Santosh]

On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristo <t-kristo@ti.com> wrote:
> 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>
> ---

$subject
arm: omap4: suspend: Program all domains to RET
s/arm/ARM
s/omap4/OMAP4
s/RET/retention

o.w looks good.
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>

[PATCH 2/6] ARM: OMAP4 PM: Add IO Daisychain support

[Tero Kristo]

From: Rajendra Nayak <rnayak@ti.com>

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

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/mach-omap2/prm44xx.c |   32 ++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/prm44xx.h |    1 +
 2 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 33dd655..1557647 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -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())
diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h
index 7978092..a840f0f 100644
--- a/arch/arm/mach-omap2/prm44xx.h
+++ b/arch/arm/mach-omap2/prm44xx.h
@@ -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);
-- 
1.7.4.1

[PATCH 2/6] ARM: OMAP4 PM: Add IO Daisychain support

[Tero Kristo]

From: Rajendra Nayak <rnayak@ti.com>

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

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/mach-omap2/prm44xx.c |   32 ++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/prm44xx.h |    1 +
 2 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 33dd655..1557647 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -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())
diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h
index 7978092..a840f0f 100644
--- a/arch/arm/mach-omap2/prm44xx.h
+++ b/arch/arm/mach-omap2/prm44xx.h
@@ -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);
-- 
1.7.4.1

Re: [PATCH 2/6] ARM: OMAP4 PM: Add IO Daisychain support

[Shilimkar, Santosh]

On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristo <t-kristo@ti.com> wrote:
> From: Rajendra Nayak <rnayak@ti.com>
>
> patch adds IO Daisychain support for OMAP4 as per section 3.9.4 in OMAP4430
> Public TRM.
>
A brief about IO daisy in changelog would be good apart from TRM reference.

> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
>  arch/arm/mach-omap2/prm44xx.c |   32 ++++++++++++++++++++++++++++++++
>  arch/arm/mach-omap2/prm44xx.h |    1 +
>  2 files changed, 33 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
> index 33dd655..1557647 100644
> --- a/arch/arm/mach-omap2/prm44xx.c
> +++ b/arch/arm/mach-omap2/prm44xx.c
> @@ -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
> +
Is the 1000 us/ms ?
Is that documented or arbitrary chosen ?

Rest of the change looks good to me.

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

[PATCH 2/6] ARM: OMAP4 PM: Add IO Daisychain support

[Shilimkar, Santosh]

On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristo <t-kristo@ti.com> wrote:
> From: Rajendra Nayak <rnayak@ti.com>
>
> patch adds IO Daisychain support for OMAP4 as per section 3.9.4 in OMAP4430
> Public TRM.
>
A brief about IO daisy in changelog would be good apart from TRM reference.

> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> ?arch/arm/mach-omap2/prm44xx.c | ? 32 ++++++++++++++++++++++++++++++++
> ?arch/arm/mach-omap2/prm44xx.h | ? ?1 +
> ?2 files changed, 33 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
> index 33dd655..1557647 100644
> --- a/arch/arm/mach-omap2/prm44xx.c
> +++ b/arch/arm/mach-omap2/prm44xx.c
> @@ -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
> +
Is the 1000 us/ms ?
Is that documented or arbitrary chosen ?

Rest of the change looks good to me.

regards
santosh

Re: [PATCH 2/6] ARM: OMAP4 PM: Add IO Daisychain support

[Rajendra Nayak]

On Thursday 23 February 2012 07:18 PM, Shilimkar, Santosh wrote:
> On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristo<t-kristo@ti.com>  wrote:
[..]
>>
>> +/**
>> + * 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 ?

1000 us.

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

>
> Rest of the change looks good to me.
>
> regards
> santosh

[PATCH 2/6] ARM: OMAP4 PM: Add IO Daisychain support

[Rajendra Nayak]

On Thursday 23 February 2012 07:18 PM, Shilimkar, Santosh wrote:
> On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristo<t-kristo@ti.com>  wrote:
[..]
>>
>> +/**
>> + * 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 ?

1000 us.

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

>
> Rest of the change looks good to me.
>
> regards
> santosh

Re: [PATCH 2/6] ARM: OMAP4 PM: Add IO Daisychain support

[Shilimkar, Santosh]

On Fri, Feb 24, 2012 at 12:29 PM, Rajendra Nayak <rnayak@ti.com> wrote:
> On Thursday 23 February 2012 07:18 PM, Shilimkar, Santosh wrote:
>>
>> On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristo<t-kristo@ti.com>  wrote:
>
> [..]
>
>>>
>>> +/**
>>> + * 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 ?
>
>
> 1000 us.
>
>
>> 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.
>
Thanks for clarification Rajendra.

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

[PATCH 2/6] ARM: OMAP4 PM: Add IO Daisychain support

[Shilimkar, Santosh]

On Fri, Feb 24, 2012 at 12:29 PM, Rajendra Nayak <rnayak@ti.com> wrote:
> On Thursday 23 February 2012 07:18 PM, Shilimkar, Santosh wrote:
>>
>> On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristo<t-kristo@ti.com> ?wrote:
>
> [..]
>
>>>
>>> +/**
>>> + * 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 ?
>
>
> 1000 us.
>
>
>> 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.
>
Thanks for clarification Rajendra.

Regards
Santosh

RE: [PATCH 2/6] ARM: OMAP4 PM: Add IO Daisychain support

[Elaidi, Djamil]

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.

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


Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

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

From: Rajendra Nayak <rnayak@ti.com>

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

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/mach-omap2/prm44xx.c |   32 ++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/prm44xx.h |    1 +
 2 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 33dd655..1557647 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -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())
diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h
index 7978092..a840f0f 100644
--- a/arch/arm/mach-omap2/prm44xx.h
+++ b/arch/arm/mach-omap2/prm44xx.h
@@ -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);
--
1.7.4.1

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

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

[PATCH 2/6] ARM: OMAP4 PM: Add IO Daisychain support

[Elaidi, Djamil]

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.

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


Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920

-----Original Message-----
From: linux-omap-owner@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 <rnayak@ti.com>

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

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 arch/arm/mach-omap2/prm44xx.c |   32 ++++++++++++++++++++++++++++++++
 arch/arm/mach-omap2/prm44xx.h |    1 +
 2 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 33dd655..1557647 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -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())
diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h
index 7978092..a840f0f 100644
--- a/arch/arm/mach-omap2/prm44xx.h
+++ b/arch/arm/mach-omap2/prm44xx.h
@@ -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);
--
1.7.4.1

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

Re: [PATCH 2/6] ARM: OMAP4 PM: Add IO Daisychain support

[Rajendra Nayak]

Djamil,

On Thursday 23 February 2012 09:28 PM, Elaidi, Djamil wrote:
> 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.

You are right, this was missed and needs to be added.
Thanks for the review.

regards,
Rajendra

>
> +	/* 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@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Kristo, Tero
> Sent: jeudi 23 février 2012 14:22
> To: linux-omap@vger.kernel.org; Hilman, Kevin
> Cc: linux-arm-kernel@lists.infradead.org; Nayak, Rajendra; Sripathy, Vishwanath
> Subject: [PATCH 2/6] ARM: OMAP4 PM: Add IO Daisychain support
>
> From: Rajendra Nayak<rnayak@ti.com>
>
> patch adds IO Daisychain support for OMAP4 as per section 3.9.4 in OMAP4430
> Public TRM.
>
> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
> Signed-off-by: Vishwanath BS<vishwanath.bs@ti.com>
> Signed-off-by: Tero Kristo<t-kristo@ti.com>
> ---
>   arch/arm/mach-omap2/prm44xx.c |   32 ++++++++++++++++++++++++++++++++
>   arch/arm/mach-omap2/prm44xx.h |    1 +
>   2 files changed, 33 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
> index 33dd655..1557647 100644
> --- a/arch/arm/mach-omap2/prm44xx.c
> +++ b/arch/arm/mach-omap2/prm44xx.c
> @@ -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())
> diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h
> index 7978092..a840f0f 100644
> --- a/arch/arm/mach-omap2/prm44xx.h
> +++ b/arch/arm/mach-omap2/prm44xx.h
> @@ -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);

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

[PATCH 2/6] ARM: OMAP4 PM: Add IO Daisychain support

[Rajendra Nayak]

Djamil,

On Thursday 23 February 2012 09:28 PM, Elaidi, Djamil wrote:
> 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.

You are right, this was missed and needs to be added.
Thanks for the review.

regards,
Rajendra

>
> +	/* 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<rnayak@ti.com>
>
> patch adds IO Daisychain support for OMAP4 as per section 3.9.4 in OMAP4430
> Public TRM.
>
> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
> Signed-off-by: Vishwanath BS<vishwanath.bs@ti.com>
> Signed-off-by: Tero Kristo<t-kristo@ti.com>
> ---
>   arch/arm/mach-omap2/prm44xx.c |   32 ++++++++++++++++++++++++++++++++
>   arch/arm/mach-omap2/prm44xx.h |    1 +
>   2 files changed, 33 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
> index 33dd655..1557647 100644
> --- a/arch/arm/mach-omap2/prm44xx.c
> +++ b/arch/arm/mach-omap2/prm44xx.c
> @@ -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())
> diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h
> index 7978092..a840f0f 100644
> --- a/arch/arm/mach-omap2/prm44xx.h
> +++ b/arch/arm/mach-omap2/prm44xx.h
> @@ -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);

[PATCH 3/6] ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux

[Tero Kristo]

From: Vishwanath BS <vishwanath.bs@ti.com>

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 <vishwanath.bs@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 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(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5192cab..b052f11 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -152,6 +152,7 @@
 #include "prm44xx.h"
 #include "prminst44xx.h"
 #include "mux.h"
+#include "pm.h"
 
 /* Maximum microseconds to wait for OMAP module to softreset */
 #define MAX_MODULE_SOFTRESET_WAIT	10000
@@ -1535,8 +1536,10 @@ static int _enable(struct omap_hwmod *oh)
 	/* Mux pins for device runtime if populated */
 	if (oh->mux && (!oh->mux->enabled ||
 			((oh->_state == _HWMOD_STATE_IDLE) &&
-			 oh->mux->pads_dynamic)))
+			 oh->mux->pads_dynamic))) {
 		omap_hwmod_mux(oh->mux, _HWMOD_STATE_ENABLED);
+		omap_trigger_wuclk_ctrl();
+	}
 
 	_add_initiator_dep(oh, mpu_oh);
 
@@ -1622,8 +1625,10 @@ static int _idle(struct omap_hwmod *oh)
 		clkdm_hwmod_disable(oh->clkdm, oh);
 
 	/* Mux pins for device idle if populated */
-	if (oh->mux && oh->mux->pads_dynamic)
+	if (oh->mux && oh->mux->pads_dynamic) {
 		omap_hwmod_mux(oh->mux, _HWMOD_STATE_IDLE);
+		omap_trigger_wuclk_ctrl();
+	}
 
 	oh->_state = _HWMOD_STATE_IDLE;
 
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 1881fe9..e8b54eb 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -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)
 	}
 }
 
+void omap_trigger_wuclk_ctrl(void)
+{
+	if (cpu_is_omap44xx())
+		omap4_trigger_wuclk_ctrl();
+}
+
 /* Types of sleep_switch used in omap_set_pwrdm_state */
 #define FORCEWAKEUP_SWITCH	0
 #define LOWPOWERSTATE_SWITCH	1
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index b737b11..de0a453 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -22,6 +22,7 @@ extern int omap3_can_sleep(void);
 extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
 extern int omap3_idle_init(void);
 extern int omap4_idle_init(void);
+extern void omap_trigger_wuclk_ctrl(void);
 
 #if defined(CONFIG_PM_OPP)
 extern int omap3_opp_init(void);
-- 
1.7.4.1

[PATCH 3/6] ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux

[Tero Kristo]

From: Vishwanath BS <vishwanath.bs@ti.com>

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 <vishwanath.bs@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
 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(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 5192cab..b052f11 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -152,6 +152,7 @@
 #include "prm44xx.h"
 #include "prminst44xx.h"
 #include "mux.h"
+#include "pm.h"
 
 /* Maximum microseconds to wait for OMAP module to softreset */
 #define MAX_MODULE_SOFTRESET_WAIT	10000
@@ -1535,8 +1536,10 @@ static int _enable(struct omap_hwmod *oh)
 	/* Mux pins for device runtime if populated */
 	if (oh->mux && (!oh->mux->enabled ||
 			((oh->_state == _HWMOD_STATE_IDLE) &&
-			 oh->mux->pads_dynamic)))
+			 oh->mux->pads_dynamic))) {
 		omap_hwmod_mux(oh->mux, _HWMOD_STATE_ENABLED);
+		omap_trigger_wuclk_ctrl();
+	}
 
 	_add_initiator_dep(oh, mpu_oh);
 
@@ -1622,8 +1625,10 @@ static int _idle(struct omap_hwmod *oh)
 		clkdm_hwmod_disable(oh->clkdm, oh);
 
 	/* Mux pins for device idle if populated */
-	if (oh->mux && oh->mux->pads_dynamic)
+	if (oh->mux && oh->mux->pads_dynamic) {
 		omap_hwmod_mux(oh->mux, _HWMOD_STATE_IDLE);
+		omap_trigger_wuclk_ctrl();
+	}
 
 	oh->_state = _HWMOD_STATE_IDLE;
 
diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
index 1881fe9..e8b54eb 100644
--- a/arch/arm/mach-omap2/pm.c
+++ b/arch/arm/mach-omap2/pm.c
@@ -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)
 	}
 }
 
+void omap_trigger_wuclk_ctrl(void)
+{
+	if (cpu_is_omap44xx())
+		omap4_trigger_wuclk_ctrl();
+}
+
 /* Types of sleep_switch used in omap_set_pwrdm_state */
 #define FORCEWAKEUP_SWITCH	0
 #define LOWPOWERSTATE_SWITCH	1
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index b737b11..de0a453 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -22,6 +22,7 @@ extern int omap3_can_sleep(void);
 extern int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32 state);
 extern int omap3_idle_init(void);
 extern int omap4_idle_init(void);
+extern void omap_trigger_wuclk_ctrl(void);
 
 #if defined(CONFIG_PM_OPP)
 extern int omap3_opp_init(void);
-- 
1.7.4.1

Re: [PATCH 3/6] ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux

[Shilimkar, Santosh]

On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristo <t-kristo@ti.com> wrote:
> From: Vishwanath BS <vishwanath.bs@ti.com>
>
> 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 <vishwanath.bs@ti.com>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
>  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(-)
>

[...]

>
> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> index 1881fe9..e8b54eb 100644
> --- a/arch/arm/mach-omap2/pm.c
> +++ b/arch/arm/mach-omap2/pm.c
> @@ -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)
>        }
>  }
>
> +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
--
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

[PATCH 3/6] ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux

[Shilimkar, Santosh]

On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristo <t-kristo@ti.com> wrote:
> From: Vishwanath BS <vishwanath.bs@ti.com>
>
> 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 <vishwanath.bs@ti.com>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> ?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(-)
>

[...]

>
> diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> index 1881fe9..e8b54eb 100644
> --- a/arch/arm/mach-omap2/pm.c
> +++ b/arch/arm/mach-omap2/pm.c
> @@ -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)
> ? ? ? ?}
> ?}
>
> +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

Re: [PATCH 3/6] ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux

[Tero Kristo]

On Thu, 2012-02-23 at 19:23 +0530, Shilimkar, Santosh wrote:
> On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristo <t-kristo@ti.com> wrote:
> > From: Vishwanath BS <vishwanath.bs@ti.com>
> >
> > 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 <vishwanath.bs@ti.com>
> > Signed-off-by: Tero Kristo <t-kristo@ti.com>
> > ---
> >  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(-)
> >
> 
> [...]
> 
> >
> > diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> > index 1881fe9..e8b54eb 100644
> > --- a/arch/arm/mach-omap2/pm.c
> > +++ b/arch/arm/mach-omap2/pm.c
> > @@ -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)
> >        }
> >  }
> >
> > +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.

Can't remove this check, as we don't want to execute this code for
omap2 / omap3, it would just crash.

-Tero

> 
> Rest of the patch looks fine to me.
> 
> Regards
> Santosh

[PATCH 3/6] ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux

[Tero Kristo]

On Thu, 2012-02-23 at 19:23 +0530, Shilimkar, Santosh wrote:
> On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristo <t-kristo@ti.com> wrote:
> > From: Vishwanath BS <vishwanath.bs@ti.com>
> >
> > 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 <vishwanath.bs@ti.com>
> > Signed-off-by: Tero Kristo <t-kristo@ti.com>
> > ---
> >  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(-)
> >
> 
> [...]
> 
> >
> > diff --git a/arch/arm/mach-omap2/pm.c b/arch/arm/mach-omap2/pm.c
> > index 1881fe9..e8b54eb 100644
> > --- a/arch/arm/mach-omap2/pm.c
> > +++ b/arch/arm/mach-omap2/pm.c
> > @@ -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)
> >        }
> >  }
> >
> > +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.

Can't remove this check, as we don't want to execute this code for
omap2 / omap3, it would just crash.

-Tero

> 
> Rest of the patch looks fine to me.
> 
> Regards
> Santosh

Re: [PATCH 3/6] ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux

[Kevin Hilman]

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

> From: Vishwanath BS <vishwanath.bs@ti.com>
>
> 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 <vishwanath.bs@ti.com>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>

My review comments from the last version of this patch were not
answered/addressed:

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

[...]

> @@ -64,6 +65,12 @@ static void omap2_init_processor_devices(void)
>  	}
>  }
>  
> +void omap_trigger_wuclk_ctrl(void)
> +{
> +	if (cpu_is_omap44xx())
> +		omap4_trigger_wuclk_ctrl();
> +}

Subject says OMAP3+, but clearly this only works on OMAP4.

Also, no cpu_is* checks at runtime please.  Instead, at init time, use
cpu_is_* to initialize a function pointer.

Kevin

[PATCH 3/6] ARM: OMAP3PLUS PM: Add IO Daisychain support via hwmod mux

[Kevin Hilman]

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

> From: Vishwanath BS <vishwanath.bs@ti.com>
>
> 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 <vishwanath.bs@ti.com>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>

My review comments from the last version of this patch were not
answered/addressed:

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

[...]

> @@ -64,6 +65,12 @@ static void omap2_init_processor_devices(void)
>  	}
>  }
>  
> +void omap_trigger_wuclk_ctrl(void)
> +{
> +	if (cpu_is_omap44xx())
> +		omap4_trigger_wuclk_ctrl();
> +}

Subject says OMAP3+, but clearly this only works on OMAP4.

Also, no cpu_is* checks at runtime please.  Instead, at init time, use
cpu_is_* to initialize a function pointer.

Kevin

[PATCH 4/6] arm: omap4: prm: fix interrupt register offsets

[Tero Kristo]

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

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/prm44xx.c |   21 +++++++++++----------
 1 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 1557647..a6efbdf 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -145,8 +145,9 @@ static inline u32 _read_pending_irq_reg(u16 irqen_offs, u16 irqst_offs)
 	u32 mask, st;
 
 	/* XXX read mask from RAM? */
-	mask = omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST, irqen_offs);
-	st = omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST, irqst_offs);
+	mask = omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
+		irqen_offs);
+	st = omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST, irqst_offs);
 
 	return mask & st;
 }
@@ -178,7 +179,7 @@ void omap44xx_prm_read_pending_irqs(unsigned long *events)
  */
 void omap44xx_prm_ocp_barrier(void)
 {
-	omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
 				OMAP4_REVISION_PRM_OFFSET);
 }
 
@@ -196,19 +197,19 @@ void omap44xx_prm_ocp_barrier(void)
 void omap44xx_prm_save_and_clear_irqen(u32 *saved_mask)
 {
 	saved_mask[0] =
-		omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+		omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
 					OMAP4_PRM_IRQSTATUS_MPU_OFFSET);
 	saved_mask[1] =
-		omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+		omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
 					OMAP4_PRM_IRQSTATUS_MPU_2_OFFSET);
 
-	omap4_prm_write_inst_reg(0, OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_write_inst_reg(0, OMAP4430_PRM_OCP_SOCKET_INST,
 				 OMAP4_PRM_IRQENABLE_MPU_OFFSET);
-	omap4_prm_write_inst_reg(0, OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_write_inst_reg(0, OMAP4430_PRM_OCP_SOCKET_INST,
 				 OMAP4_PRM_IRQENABLE_MPU_2_OFFSET);
 
 	/* OCP barrier */
-	omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
 				OMAP4_REVISION_PRM_OFFSET);
 }
 
@@ -224,9 +225,9 @@ void omap44xx_prm_save_and_clear_irqen(u32 *saved_mask)
  */
 void omap44xx_prm_restore_irqen(u32 *saved_mask)
 {
-	omap4_prm_write_inst_reg(saved_mask[0], OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_write_inst_reg(saved_mask[0], OMAP4430_PRM_OCP_SOCKET_INST,
 				 OMAP4_PRM_IRQENABLE_MPU_OFFSET);
-	omap4_prm_write_inst_reg(saved_mask[1], OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_write_inst_reg(saved_mask[1], OMAP4430_PRM_OCP_SOCKET_INST,
 				 OMAP4_PRM_IRQENABLE_MPU_2_OFFSET);
 }
 
-- 
1.7.4.1

[PATCH 4/6] arm: omap4: prm: fix interrupt register offsets

[Tero Kristo]

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

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/prm44xx.c |   21 +++++++++++----------
 1 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 1557647..a6efbdf 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -145,8 +145,9 @@ static inline u32 _read_pending_irq_reg(u16 irqen_offs, u16 irqst_offs)
 	u32 mask, st;
 
 	/* XXX read mask from RAM? */
-	mask = omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST, irqen_offs);
-	st = omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST, irqst_offs);
+	mask = omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
+		irqen_offs);
+	st = omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST, irqst_offs);
 
 	return mask & st;
 }
@@ -178,7 +179,7 @@ void omap44xx_prm_read_pending_irqs(unsigned long *events)
  */
 void omap44xx_prm_ocp_barrier(void)
 {
-	omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
 				OMAP4_REVISION_PRM_OFFSET);
 }
 
@@ -196,19 +197,19 @@ void omap44xx_prm_ocp_barrier(void)
 void omap44xx_prm_save_and_clear_irqen(u32 *saved_mask)
 {
 	saved_mask[0] =
-		omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+		omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
 					OMAP4_PRM_IRQSTATUS_MPU_OFFSET);
 	saved_mask[1] =
-		omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+		omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
 					OMAP4_PRM_IRQSTATUS_MPU_2_OFFSET);
 
-	omap4_prm_write_inst_reg(0, OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_write_inst_reg(0, OMAP4430_PRM_OCP_SOCKET_INST,
 				 OMAP4_PRM_IRQENABLE_MPU_OFFSET);
-	omap4_prm_write_inst_reg(0, OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_write_inst_reg(0, OMAP4430_PRM_OCP_SOCKET_INST,
 				 OMAP4_PRM_IRQENABLE_MPU_2_OFFSET);
 
 	/* OCP barrier */
-	omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
 				OMAP4_REVISION_PRM_OFFSET);
 }
 
@@ -224,9 +225,9 @@ void omap44xx_prm_save_and_clear_irqen(u32 *saved_mask)
  */
 void omap44xx_prm_restore_irqen(u32 *saved_mask)
 {
-	omap4_prm_write_inst_reg(saved_mask[0], OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_write_inst_reg(saved_mask[0], OMAP4430_PRM_OCP_SOCKET_INST,
 				 OMAP4_PRM_IRQENABLE_MPU_OFFSET);
-	omap4_prm_write_inst_reg(saved_mask[1], OMAP4430_PRM_DEVICE_INST,
+	omap4_prm_write_inst_reg(saved_mask[1], OMAP4430_PRM_OCP_SOCKET_INST,
 				 OMAP4_PRM_IRQENABLE_MPU_2_OFFSET);
 }
 
-- 
1.7.4.1

Re: [PATCH 4/6] arm: omap4: prm: fix interrupt register offsets

[Kevin Hilman]

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

> Previous code used wrong instance for the interrupt register access.
> Use the right one which is OCP_SOCKET.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> ---
>  arch/arm/mach-omap2/prm44xx.c |   21 +++++++++++----------
>  1 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
> index 1557647..a6efbdf 100644
> --- a/arch/arm/mach-omap2/prm44xx.c
> +++ b/arch/arm/mach-omap2/prm44xx.c
> @@ -145,8 +145,9 @@ static inline u32 _read_pending_irq_reg(u16 irqen_offs, u16 irqst_offs)
>  	u32 mask, st;
>  
>  	/* XXX read mask from RAM? */
> -	mask = omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST, irqen_offs);
> -	st = omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST, irqst_offs);
> +	mask = omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
> +		irqen_offs);

nit: indentaion.  this line should be indented and star at the same
place as OMAP4430_PRM_OCP....


Kevin

[PATCH 4/6] arm: omap4: prm: fix interrupt register offsets

[Kevin Hilman]

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

> Previous code used wrong instance for the interrupt register access.
> Use the right one which is OCP_SOCKET.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> ---
>  arch/arm/mach-omap2/prm44xx.c |   21 +++++++++++----------
>  1 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
> index 1557647..a6efbdf 100644
> --- a/arch/arm/mach-omap2/prm44xx.c
> +++ b/arch/arm/mach-omap2/prm44xx.c
> @@ -145,8 +145,9 @@ static inline u32 _read_pending_irq_reg(u16 irqen_offs, u16 irqst_offs)
>  	u32 mask, st;
>  
>  	/* XXX read mask from RAM? */
> -	mask = omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST, irqen_offs);
> -	st = omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST, irqst_offs);
> +	mask = omap4_prm_read_inst_reg(OMAP4430_PRM_OCP_SOCKET_INST,
> +		irqen_offs);

nit: indentaion.  this line should be indented and star at the same
place as OMAP4430_PRM_OCP....


Kevin

[PATCH 5/6] ARM: OMAP4: suspend: Do not get dsp/tesla out of reset

[Tero Kristo]

From: Rajendra Nayak <rnayak@ti.com>

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

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 ef0524c..81d90da 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

[PATCH 5/6] ARM: OMAP4: suspend: Do not get dsp/tesla out of reset

[Tero Kristo]

From: Rajendra Nayak <rnayak@ti.com>

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

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 ef0524c..81d90da 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

Re: [PATCH 5/6] ARM: OMAP4: suspend: Do not get dsp/tesla out of reset

[Shilimkar, Santosh]

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

On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristo <t-kristo@ti.com> wrote:
> From: Rajendra Nayak <rnayak@ti.com>
>
> 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.

> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---

Patch is fine though script needs to be updated I guess

Regards
Santosh

[PATCH 5/6] ARM: OMAP4: suspend: Do not get dsp/tesla out of reset

[Shilimkar, Santosh]

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

On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristo <t-kristo@ti.com> wrote:
> From: Rajendra Nayak <rnayak@ti.com>
>
> 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.

> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---

Patch is fine though script needs to be updated I guess

Regards
Santosh

Re: [PATCH 5/6] ARM: OMAP4: suspend: Do not get dsp/tesla out of reset

[Cousson, Benoit]

On 2/23/2012 2:56 PM, Shilimkar, Santosh wrote:
> $Subject
> s/dsp/DSP
> s/tesla/TESLA

Even better... remove tesla :-)

This is an internal codename that at some point should be removed from 
the clkdm name. I just did not have the time to do that for OMAP4, but 
it will not exist anymore on OMAP5.

Nit: The subject should be:
"ARM: OMAP4: hwmod data: Do not get DSP out of reset at boot time"

Regards,
Benoit

>
> On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristo<t-kristo@ti.com>  wrote:
>> From: Rajendra Nayak<rnayak@ti.com>
>>
>> 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.
>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>> Signed-off-by: Tero Kristo<t-kristo@ti.com>
>> ---
>
> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/6] ARM: OMAP4: suspend: Do not get dsp/tesla out of reset

[Cousson, Benoit]

On 2/23/2012 2:56 PM, Shilimkar, Santosh wrote:
> $Subject
> s/dsp/DSP
> s/tesla/TESLA

Even better... remove tesla :-)

This is an internal codename that at some point should be removed from 
the clkdm name. I just did not have the time to do that for OMAP4, but 
it will not exist anymore on OMAP5.

Nit: The subject should be:
"ARM: OMAP4: hwmod data: Do not get DSP out of reset at boot time"

Regards,
Benoit

>
> On Thu, Feb 23, 2012 at 6:51 PM, Tero Kristo<t-kristo@ti.com>  wrote:
>> From: Rajendra Nayak<rnayak@ti.com>
>>
>> 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.
>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>> Signed-off-by: Tero Kristo<t-kristo@ti.com>
>> ---
>
> 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

Re: [PATCH 5/6] ARM: OMAP4: suspend: Do not get dsp/tesla out of reset

[Kevin Hilman]

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

> From: Rajendra Nayak <rnayak@ti.com>
>
> With no driver handling DSP/TESLA, if brought out of reset, it stays
> active and does not assert standby.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>

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

Kevin

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

[PATCH 5/6] ARM: OMAP4: suspend: Do not get dsp/tesla out of reset

[Kevin Hilman]

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

> From: Rajendra Nayak <rnayak@ti.com>
>
> With no driver handling DSP/TESLA, if brought out of reset, it stays
> active and does not assert standby.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>

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

Kevin

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

Re: [PATCH 5/6] ARM: OMAP4: suspend: Do not get dsp/tesla out of reset

[Rajendra Nayak]

Hi Kevin,

On Tuesday 28 February 2012 05:58 AM, Kevin Hilman wrote:
> Tero Kristo<t-kristo@ti.com>  writes:
>
>> From: Rajendra Nayak<rnayak@ti.com>
>>
>> With no driver handling DSP/TESLA, if brought out of reset, it stays
>> active and does not assert standby.
>>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>> Signed-off-by: Tero Kristo<t-kristo@ti.com>
>
> Subject says 'OMAP4: suspend'.  How does HWMOD_INIT_NO_RESET affect
> suspend?

The v2 of this patch posted by Tero has a better $subject as suggested
by Benoit which says 'ARM: OMAP4: hwmod_data: Do not get DSP out of
reset at boot time'

The intention of this patch is to *not* get DSP out of reset at boot,
because once out of reset DSP needs some code that executes a 'wfi'
equivalent for it to assert a standby and allow suspend to sleep.

regards,
Rajendra

>
> Kevin
>
>> ---
>>   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 ef0524c..81d90da 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),

[PATCH 5/6] ARM: OMAP4: suspend: Do not get dsp/tesla out of reset

[Rajendra Nayak]

Hi Kevin,

On Tuesday 28 February 2012 05:58 AM, Kevin Hilman wrote:
> Tero Kristo<t-kristo@ti.com>  writes:
>
>> From: Rajendra Nayak<rnayak@ti.com>
>>
>> With no driver handling DSP/TESLA, if brought out of reset, it stays
>> active and does not assert standby.
>>
>> Signed-off-by: Rajendra Nayak<rnayak@ti.com>
>> Signed-off-by: Tero Kristo<t-kristo@ti.com>
>
> Subject says 'OMAP4: suspend'.  How does HWMOD_INIT_NO_RESET affect
> suspend?

The v2 of this patch posted by Tero has a better $subject as suggested
by Benoit which says 'ARM: OMAP4: hwmod_data: Do not get DSP out of
reset at boot time'

The intention of this patch is to *not* get DSP out of reset at boot,
because once out of reset DSP needs some code that executes a 'wfi'
equivalent for it to assert a standby and allow suspend to sleep.

regards,
Rajendra

>
> Kevin
>
>> ---
>>   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 ef0524c..81d90da 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),

[PATCH 6/6] arm: omap3+: add prcm chain interrupts to the interrupt list

[Tero Kristo]

Currently PRCM chain handler for OMAP4 requires SPARSE_IRQ to be enabled
from kernel config, however enabling this option breaks the OMAP kernel
completely and it can't be used. Thus, OMAP_PRCM_IRQ_BASE was added
to the end of the irq list, and the prm_common code was changed to use
this instead of irq_desc allocation scheme.

Once SPARSE_IRQ is enabled for OMAP kernel, this patch can be reverted.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/prm_common.c       |   14 +-------------
 arch/arm/plat-omap/include/plat/irqs.h |    6 +++++-
 2 files changed, 6 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index 860118a..9ca829f 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -196,11 +196,6 @@ void omap_prcm_irq_cleanup(void)
 	prcm_irq_setup->priority_mask = NULL;
 
 	irq_set_chained_handler(prcm_irq_setup->irq, NULL);
-
-	if (prcm_irq_setup->base_irq > 0)
-		irq_free_descs(prcm_irq_setup->base_irq,
-			prcm_irq_setup->nr_regs * 32);
-	prcm_irq_setup->base_irq = 0;
 }
 
 void omap_prcm_irq_prepare(void)
@@ -282,14 +277,7 @@ int omap_prcm_register_chain_handler(struct omap_prcm_irq_setup *irq_setup)
 
 	irq_set_chained_handler(irq_setup->irq, omap_prcm_irq_handler);
 
-	irq_setup->base_irq = irq_alloc_descs(-1, 0, irq_setup->nr_regs * 32,
-		0);
-
-	if (irq_setup->base_irq < 0) {
-		pr_err("PRCM: failed to allocate irq descs: %d\n",
-			irq_setup->base_irq);
-		goto err;
-	}
+	irq_setup->base_irq = OMAP_PRCM_IRQ_BASE;
 
 	for (i = 0; i <= irq_setup->nr_regs; i++) {
 		gc = irq_alloc_generic_chip("PRCM", 1,
diff --git a/arch/arm/plat-omap/include/plat/irqs.h b/arch/arm/plat-omap/include/plat/irqs.h
index 2efd645..fe1be1d 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -428,8 +428,12 @@
 #define OMAP_GPMC_NR_IRQS	8
 #define OMAP_GPMC_IRQ_END	(OMAP_GPMC_IRQ_BASE + OMAP_GPMC_NR_IRQS)
 
+/* PRCM chain handler */
+#define OMAP_PRCM_IRQ_BASE	(OMAP_GPMC_IRQ_END)
+#define OMAP_PRCM_NR_IRQS	64
+#define OMAP_PRCM_IRQ_END	(OMAP_PRCM_IRQ_BASE + OMAP_PRCM_NR_IRQS)
 
-#define NR_IRQS			OMAP_GPMC_IRQ_END
+#define NR_IRQS			OMAP_PRCM_IRQ_END
 
 #define OMAP_IRQ_BIT(irq)	(1 << ((irq) % 32))
 
-- 
1.7.4.1

[PATCH 6/6] arm: omap3+: add prcm chain interrupts to the interrupt list

[Tero Kristo]

Currently PRCM chain handler for OMAP4 requires SPARSE_IRQ to be enabled
from kernel config, however enabling this option breaks the OMAP kernel
completely and it can't be used. Thus, OMAP_PRCM_IRQ_BASE was added
to the end of the irq list, and the prm_common code was changed to use
this instead of irq_desc allocation scheme.

Once SPARSE_IRQ is enabled for OMAP kernel, this patch can be reverted.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---
 arch/arm/mach-omap2/prm_common.c       |   14 +-------------
 arch/arm/plat-omap/include/plat/irqs.h |    6 +++++-
 2 files changed, 6 insertions(+), 14 deletions(-)

diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index 860118a..9ca829f 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -196,11 +196,6 @@ void omap_prcm_irq_cleanup(void)
 	prcm_irq_setup->priority_mask = NULL;
 
 	irq_set_chained_handler(prcm_irq_setup->irq, NULL);
-
-	if (prcm_irq_setup->base_irq > 0)
-		irq_free_descs(prcm_irq_setup->base_irq,
-			prcm_irq_setup->nr_regs * 32);
-	prcm_irq_setup->base_irq = 0;
 }
 
 void omap_prcm_irq_prepare(void)
@@ -282,14 +277,7 @@ int omap_prcm_register_chain_handler(struct omap_prcm_irq_setup *irq_setup)
 
 	irq_set_chained_handler(irq_setup->irq, omap_prcm_irq_handler);
 
-	irq_setup->base_irq = irq_alloc_descs(-1, 0, irq_setup->nr_regs * 32,
-		0);
-
-	if (irq_setup->base_irq < 0) {
-		pr_err("PRCM: failed to allocate irq descs: %d\n",
-			irq_setup->base_irq);
-		goto err;
-	}
+	irq_setup->base_irq = OMAP_PRCM_IRQ_BASE;
 
 	for (i = 0; i <= irq_setup->nr_regs; i++) {
 		gc = irq_alloc_generic_chip("PRCM", 1,
diff --git a/arch/arm/plat-omap/include/plat/irqs.h b/arch/arm/plat-omap/include/plat/irqs.h
index 2efd645..fe1be1d 100644
--- a/arch/arm/plat-omap/include/plat/irqs.h
+++ b/arch/arm/plat-omap/include/plat/irqs.h
@@ -428,8 +428,12 @@
 #define OMAP_GPMC_NR_IRQS	8
 #define OMAP_GPMC_IRQ_END	(OMAP_GPMC_IRQ_BASE + OMAP_GPMC_NR_IRQS)
 
+/* PRCM chain handler */
+#define OMAP_PRCM_IRQ_BASE	(OMAP_GPMC_IRQ_END)
+#define OMAP_PRCM_NR_IRQS	64
+#define OMAP_PRCM_IRQ_END	(OMAP_PRCM_IRQ_BASE + OMAP_PRCM_NR_IRQS)
 
-#define NR_IRQS			OMAP_GPMC_IRQ_END
+#define NR_IRQS			OMAP_PRCM_IRQ_END
 
 #define OMAP_IRQ_BIT(irq)	(1 << ((irq) % 32))
 
-- 
1.7.4.1

Re: [PATCH 0/6] ARM: OMAP4: core retention support

[Kevin Hilman]

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

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

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.

Kevin

[PATCH 0/6] ARM: OMAP4: core retention support

[Kevin Hilman]

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

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

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.

Kevin

Re: [PATCH 0/6] ARM: OMAP4: core retention support

[Tero Kristo]

On Mon, 2012-02-27 at 17:25 -0800, Kevin Hilman wrote:
> Tero Kristo <t-kristo@ti.com> writes:
> 
> > 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.
> 
> Please separate out the IO daisy chain stuff as a separate series.

Okay, will do that. Based on your next comment it makes sense. I'll
double check from Vishwa how we handle the IO chain set.

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

Oh okay, sorry about that. I just checked your comments and most of them
appear valid. One of the major complaints you had was for the IO chain
to be enabled all the time now, this appears to be based on design. IO
chain can now generate wake-ups for idle modules even if the CPU is not
idle. It means that the IO chain must be re-armed every time the IO
config (mux / wakeup setup) changes. The wakeup triggering logic should
be moved to the mux code probably.

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

I dropped part of the patches (mainly the ones that touch OMAP3), as I
wasn't quite certain whether they are needed or not, and/or whether they
work on omap3 properly (mainly the above io chain arming logic.) I
wanted to keep this separate from the CSWR set itself as it should be
touching only omap4.

-Tero

[PATCH 0/6] ARM: OMAP4: core retention support

[Tero Kristo]

On Mon, 2012-02-27 at 17:25 -0800, Kevin Hilman wrote:
> Tero Kristo <t-kristo@ti.com> writes:
> 
> > 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.
> 
> Please separate out the IO daisy chain stuff as a separate series.

Okay, will do that. Based on your next comment it makes sense. I'll
double check from Vishwa how we handle the IO chain set.

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

Oh okay, sorry about that. I just checked your comments and most of them
appear valid. One of the major complaints you had was for the IO chain
to be enabled all the time now, this appears to be based on design. IO
chain can now generate wake-ups for idle modules even if the CPU is not
idle. It means that the IO chain must be re-armed every time the IO
config (mux / wakeup setup) changes. The wakeup triggering logic should
be moved to the mux code probably.

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

I dropped part of the patches (mainly the ones that touch OMAP3), as I
wasn't quite certain whether they are needed or not, and/or whether they
work on omap3 properly (mainly the above io chain arming logic.) I
wanted to keep this separate from the CSWR set itself as it should be
touching only omap4.

-Tero