ARM: Few patches for PM enablement.

Few architectures combine the GIC with an external interrupt controller. On such systems it may be necessary to update both the GIC registers and the external controller's registers to control IRQ behavior.

This can be addressed in couple of possible methods.
?1. ? ? Export common GIC routines along with 'struct irq_chip gic_chip' ? ? ? ?and allow architectures to have custom function by override.

?2. ? ? Provide architecture specific function pointer hooks ? ? ? ?within GIC library and leave platforms to add the necessary ? ? ? ?code as part of these hooks.

First one might be non-intrusive but have few shortcomings like arch needs to have there own custom gic library. Locks used should be common since it caters to same IRQs etc. Maintenance point of view also it leads to multiple file fixes.

The second probably is cleaner and portable. It ensures that all the common GIC infrastructure is not touched and also provides archs to address their specific issue.

Quoted 17 lines · Santosh Shilimkar

Few architectures combine the GIC with an external interrupt controller. On such systems it may be necessary to update both the GIC registers and the external controller's registers to control IRQ behavior.

This can be addressed in couple of possible methods.
?1. ? ? Export common GIC routines along with 'struct irq_chip gic_chip' ? ? ? ?and allow architectures to have custom function by override.

?2. ? ? Provide architecture specific function pointer hooks ? ? ? ?within GIC library and leave platforms to add the necessary ? ? ? ?code as part of these hooks.

First one might be non-intrusive but have few shortcomings like arch needs to have there own custom gic library. Locks used should be common since it caters to same IRQs etc. Maintenance point of view also it leads to multiple file fixes.

Quoted 3 lines

The second probably is cleaner and portable. It ensures that all the common GIC infrastructure is not touched and also provides archs to address their specific issue.

This method would work for most of Tegra's needs, although we would need gic_set_type and gic_ack_irq to have arch extensions as well. However, it does not allow for irq_retrigger, which can be implemented on Tegra.

-----Original Message-----
From: ccross at google.com [mailto:ccross at google.com] On Behalf Of Colin Cross
Sent: Wednesday, January 26, 2011 2:25 AM
To: Santosh Shilimkar
Cc: linux-arm-kernel at lists.infradead.org; linux-
omap at vger.kernel.org; catalin.marinas at arm.com;
linux at arm.linux.org.uk; linus.ml.walleij at gmail.com; Russell King
Subject: Re: [PATCH 1/5] ARM: gic: Add hooks for architecture specific extensions

Quoted 3 lines · Colin Cross

Quoted 1 line · Santosh Shilimkar

Few architectures combine the GIC with an external interrupt

controller.

Quoted 1 line

Quoted 1 line

On such systems it may be necessary to update both the GIC

registers

Quoted 4 lines

Quoted 4 lines

and the external controller's registers to control IRQ behavior.

This can be addressed in couple of possible methods. ?1. ? ? Export common GIC routines along with 'struct irq_chip

gic_chip'

Quoted 1 line

Quoted 1 line

? ? ? ?and allow architectures to have custom function by

override.

Quoted 3 lines

Quoted 3 lines

?2. ? ? Provide architecture specific function pointer hooks ? ? ? ?within GIC library and leave platforms to add the

necessary

Quoted 3 lines

Quoted 3 lines

? ? ? ?code as part of these hooks.

First one might be non-intrusive but have few shortcomings like

arch needs

Quoted 1 line

Quoted 1 line

to have there own custom gic library. Locks used should be common

since it

Quoted 1 line

Quoted 1 line

caters to same IRQs etc. Maintenance point of view also it leads

to

Quoted 3 lines

Quoted 3 lines

multiple file fixes.

The second probably is cleaner and portable. It ensures that all

the

Quoted 1 line

Quoted 1 line

common GIC infrastructure is not touched and also provides archs

to

Quoted 3 lines

Quoted 1 line

address their specific issue.

This method would work for most of Tegra's needs, although we

would

Quoted 2 lines

need gic_set_type and gic_ack_irq to have arch extensions as well. However, it does not allow for irq_retrigger, which can be

implemented

Quoted 1 line

on Tegra.

irq_retrigger does work with this method, the core IRQ code checks for
a return value if the retrigger was successful. Tegra works with your
patch along with these changes:

arch/arm/common/gic.c +2 -0

index 0b6c043..7993f07 100644
@@ -90,6 +90,8 @@ static inline unsigned int gic_irq(struct irq_data
 *d)
 static void gic_ack_irq(struct irq_data *d)
 {
 	spin_lock(&irq_controller_lock);
+	if (gic_arch_extn.irq_ack)
+		gic_arch_extn.irq_ack(d);
 	writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
 	spin_unlock(&irq_controller_lock);

}

arch/arm/common/gic.c +8 -0

@@ -161,6 +163,14 @@ static int gic_set_type(struct irq_data *d,
 unsigned int type)
 	return 0;
 }
 
+static int gic_retrigger(struct irq_data *d)
+{
+	if (gic_arch_extn.irq_retrigger)
+		return gic_arch_extn.irq_retrigger(d);
+
+	return 0;
+}
+
 #ifdef CONFIG_SMP
 static int

gic_set_cpu(struct irq_data *d, const struct cpumask *mask_val,
bool force)

arch/arm/common/gic.c +1 -0

@@ -234,6 +244,7 @@ static struct irq_chip gic_chip = {
 	.irq_mask		= gic_mask_irq,
 	.irq_unmask		= gic_unmask_irq,
 	.irq_set_type		= gic_set_type,
+	.irq_retrigger		= gic_retrigger,
 #ifdef CONFIG_SMP
 	.irq_set_affinity	= gic_set_cpu,
 #endif

Quoted 53 lines

-----Original Message-----
From: ccross at google.com [mailto:ccross at google.com] On Behalf Of Colin Cross
Sent: Wednesday, January 26, 2011 2:25 AM
To: Santosh Shilimkar
Cc: linux-arm-kernel at lists.infradead.org; linux-
omap at vger.kernel.org; catalin.marinas at arm.com;
linux at arm.linux.org.uk; linus.ml.walleij at gmail.com; Russell King
Subject: Re: [PATCH 1/5] ARM: gic: Add hooks for architecture specific extensions

Quoted 3 lines · Colin Cross

Quoted 1 line · Santosh Shilimkar

Few architectures combine the GIC with an external interrupt

controller.

Quoted 1 line

Quoted 1 line

On such systems it may be necessary to update both the GIC

registers

Quoted 4 lines

Quoted 4 lines

and the external controller's registers to control IRQ behavior.

This can be addressed in couple of possible methods. ?1. ? ? Export common GIC routines along with 'struct irq_chip

gic_chip'

Quoted 1 line

Quoted 1 line

? ? ? ?and allow architectures to have custom function by

override.

Quoted 3 lines

Quoted 3 lines

?2. ? ? Provide architecture specific function pointer hooks ? ? ? ?within GIC library and leave platforms to add the

necessary

Quoted 3 lines

Quoted 3 lines

? ? ? ?code as part of these hooks.

First one might be non-intrusive but have few shortcomings like

arch needs

Quoted 1 line

Quoted 1 line

to have there own custom gic library. Locks used should be common

since it

Quoted 1 line

Quoted 1 line

caters to same IRQs etc. Maintenance point of view also it leads

to

Quoted 3 lines

Quoted 3 lines

multiple file fixes.

The second probably is cleaner and portable. It ensures that all

the

Quoted 1 line

Quoted 1 line

common GIC infrastructure is not touched and also provides archs

to

Quoted 3 lines

Quoted 1 line

address their specific issue.

This method would work for most of Tegra's needs, although we

would

Quoted 2 lines

need gic_set_type and gic_ack_irq to have arch extensions as well. However, it does not allow for irq_retrigger, which can be

implemented

Quoted 1 line

on Tegra.

Quoted 6 lines

irq_retrigger does work with this method, the core IRQ code checks for
a return value if the retrigger was successful. ?Tegra works with your
patch along with these changes:

Great.
Can I fold below changes in my patch and add you ack and tested-by?

Quoted 39 lines

arch/arm/common/gic.c +2 -0

index 0b6c043..7993f07 100644
@@ -90,6 +90,8 @@ static inline unsigned int gic_irq(struct irq_data
 *d)
 ?static void gic_ack_irq(struct irq_data *d)
 ?{
 ? ? ? spin_lock(&irq_controller_lock);
+ ? ? if (gic_arch_extn.irq_ack)
+ ? ? ? ? ? ? gic_arch_extn.irq_ack(d);
 ? ? ? writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
 ? ? ? spin_unlock(&irq_controller_lock);

?}

arch/arm/common/gic.c +8 -0

@@ -161,6 +163,14 @@ static int gic_set_type(struct irq_data *d,
 unsigned int type)
 ? ? ? return 0;
 ?}
 
+static int gic_retrigger(struct irq_data *d)
+{
+ ? ? if (gic_arch_extn.irq_retrigger)
+ ? ? ? ? ? ? return gic_arch_extn.irq_retrigger(d);
+
+ ? ? return 0;
+}
+

?#ifdef CONFIG_SMP
?static int
?gic_set_cpu(struct irq_data *d, const struct cpumask *mask_val, bool force)

arch/arm/common/gic.c +1 -0

@@ -234,6 +244,7 @@ static struct irq_chip gic_chip = {
 ? ? ? .irq_mask ? ? ? ? ? ? ? = gic_mask_irq,
 ? ? ? .irq_unmask ? ? ? ? ? ? = gic_unmask_irq,
 ? ? ? .irq_set_type ? ? ? ? ? = gic_set_type,
+ ? ? .irq_retrigger ? ? ? ? ?= gic_retrigger,

?#ifdef CONFIG_SMP
? ? ? .irq_set_affinity ? ? ? = gic_set_cpu,
?#endif

-----Original Message-----
From: ccross at google.com [mailto:ccross at google.com] On Behalf Of Colin Cross
Sent: Wednesday, January 26, 2011 12:54 PM
To: Santosh Shilimkar
Cc: linux-arm-kernel at lists.infradead.org; linux-
omap at vger.kernel.org; catalin.marinas at arm.com;
linux at arm.linux.org.uk; linus.ml.walleij at gmail.com; Russell King
Subject: Re: [PATCH 1/5] ARM: gic: Add hooks for architecture specific extensions

Quoted 3 lines

Quoted 1 line

Great.
Can I fold below changes in my patch and add you ack and tested-

by?

Sure

Quoted 6 lines

arch/arm/common/gic.c static inline unsigned int gic_irq(struct

Quoted 6 lines

arch/arm/common/gic.c +0 -0

index 0b6c043..7993f07 100644
@@ -90,6 +90,8 @@ static inline unsigned int gic_irq(struct

irq_data

Quoted 35 lines

Quoted 34 lines

arch/arm/common/gic.c +2 -0

 *d)
 ?static void gic_ack_irq(struct irq_data *d)
 ?{
 ? ? ? spin_lock(&irq_controller_lock);
+ ? ? if (gic_arch_extn.irq_ack)
+ ? ? ? ? ? ? gic_arch_extn.irq_ack(d);
 ? ? ? writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
 ? ? ? spin_unlock(&irq_controller_lock);

?}

arch/arm/common/gic.c +8 -0

@@ -161,6 +163,14 @@ static int gic_set_type(struct irq_data *d,
 unsigned int type)
 ? ? ? return 0;
 ?}
 
+static int gic_retrigger(struct irq_data *d)
+{
+ ? ? if (gic_arch_extn.irq_retrigger)
+ ? ? ? ? ? ? return gic_arch_extn.irq_retrigger(d);
+
+ ? ? return 0;
+}
+

?#ifdef CONFIG_SMP
?static int
?gic_set_cpu(struct irq_data *d, const struct cpumask *mask_val, bool force)

arch/arm/common/gic.c +1 -0

@@ -234,6 +244,7 @@ static struct irq_chip gic_chip = {
 ? ? ? .irq_mask ? ? ? ? ? ? ? = gic_mask_irq,
 ? ? ? .irq_unmask ? ? ? ? ? ? = gic_unmask_irq,
 ? ? ? .irq_set_type ? ? ? ? ? = gic_set_type,
+ ? ? .irq_retrigger ? ? ? ? ?= gic_retrigger,

?#ifdef CONFIG_SMP
? ? ? .irq_set_affinity ? ? ? = gic_set_cpu,
?#endif

Quoted 11 lines

-----Original Message-----
From: ccross at google.com [mailto:ccross at google.com] On Behalf Of Colin Cross
Sent: Wednesday, January 26, 2011 12:54 PM
To: Santosh Shilimkar
Cc: linux-arm-kernel at lists.infradead.org; linux-
omap at vger.kernel.org; catalin.marinas at arm.com;
linux at arm.linux.org.uk; linus.ml.walleij at gmail.com; Russell King
Subject: Re: [PATCH 1/5] ARM: gic: Add hooks for architecture specific extensions

[....]

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

Great.
Can I fold below changes in my patch and add you ack and tested-

Quoted 3 lines

by?

Sure

After reading your initial comment, you mentioned you need to have 'gic_set_type' as well. Is this still true. If yes then we need to have arch_extn call for that as well.

Quoted 41 lines

Quoted 5 lines

arch/arm/common/gic.c static inline unsigned int gic_irq(struct

Quoted 5 lines

arch/arm/common/gic.c +0 -0

index 0b6c043..7993f07 100644
@@ -90,6 +90,8 @@ static inline unsigned int gic_irq(struct

irq_data

Quoted 35 lines

Quoted 34 lines

arch/arm/common/gic.c +2 -0

 *d)
 ?static void gic_ack_irq(struct irq_data *d)
 ?{
 ? ? ? spin_lock(&irq_controller_lock);
+ ? ? if (gic_arch_extn.irq_ack)
+ ? ? ? ? ? ? gic_arch_extn.irq_ack(d);
 ? ? ? writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
 ? ? ? spin_unlock(&irq_controller_lock);

?}

arch/arm/common/gic.c +8 -0

@@ -161,6 +163,14 @@ static int gic_set_type(struct irq_data *d,
 unsigned int type)
 ? ? ? return 0;
 ?}
 
+static int gic_retrigger(struct irq_data *d)
+{
+ ? ? if (gic_arch_extn.irq_retrigger)
+ ? ? ? ? ? ? return gic_arch_extn.irq_retrigger(d);
+
+ ? ? return 0;
+}
+

?#ifdef CONFIG_SMP
?static int
?gic_set_cpu(struct irq_data *d, const struct cpumask *mask_val, bool force)

arch/arm/common/gic.c +1 -0

@@ -234,6 +244,7 @@ static struct irq_chip gic_chip = {
 ? ? ? .irq_mask ? ? ? ? ? ? ? = gic_mask_irq,
 ? ? ? .irq_unmask ? ? ? ? ? ? = gic_unmask_irq,
 ? ? ? .irq_set_type ? ? ? ? ? = gic_set_type,
+ ? ? .irq_retrigger ? ? ? ? ?= gic_retrigger,

?#ifdef CONFIG_SMP
? ? ? .irq_set_affinity ? ? ? = gic_set_cpu,
?#endif

-----Original Message-----
From: ccross at google.com [mailto:ccross at google.com] On Behalf Of Colin Cross
Sent: Wednesday, January 26, 2011 1:23 PM
To: Santosh Shilimkar
Cc: linux-arm-kernel at lists.infradead.org; linux-
omap at vger.kernel.org; catalin.marinas at arm.com;
linux at arm.linux.org.uk; linus.ml.walleij at gmail.com; Russell King
Subject: Re: [PATCH 1/5] ARM: gic: Add hooks for architecture specific extensions

Quoted 11 lines · Santosh Shilimkar

Quoted 11 lines

-----Original Message-----
From: ccross at google.com [mailto:ccross at google.com] On Behalf Of Colin Cross
Sent: Wednesday, January 26, 2011 12:54 PM
To: Santosh Shilimkar
Cc: linux-arm-kernel at lists.infradead.org; linux-
omap at vger.kernel.org; catalin.marinas at arm.com;
linux at arm.linux.org.uk; linus.ml.walleij at gmail.com; Russell King
Subject: Re: [PATCH 1/5] ARM: gic: Add hooks for architecture specific extensions

Quoted 5 lines

[....]

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

Great.
Can I fold below changes in my patch and add you ack and

tested-

Quoted 7 lines

Quoted 3 lines

by?

Sure

After reading your initial comment, you mentioned you need to have 'gic_set_type' as well. Is this still true. If yes then we need to have arch_extn call for that as well.

You are right, I missed adding the extension for gic_set_type. My testing doesn't cover that case right now, because I don't have any drivers updated to linux-next that use a wake source that is compatible with Tegra's lowest power suspend mode, and that is the only time the extension to gic_set_type is necessary.

-----Original Message-----
From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
Sent: Monday, January 24, 2011 2:21 PM
To: linux-arm-kernel at lists.infradead.org
Cc: linux-omap at vger.kernel.org; ccross at android.com; catalin.marinas at arm.com; linux at arm.linux.org.uk; linus.ml.walleij at gmail.com; Santosh Shilimkar; Russell King
Subject: [PATCH 2/5] ARM: gic: Add distributor and interface enable/disable accessory api

The power management code needs to have access to enable/disable the gic cpu interface and distributor based on targetted low power states.

This patch adds and exports one API each for distributor and cpu interface enable/disable.

Signed-off-by Santosh Shilimkar <[email protected]>

Cc Russell King <[email protected]>

---

In CPU low power state, local timer looses its register context. This patch adds context save restore hooks which can be used by platforms appropriately.

Quoted 3 lines · Santosh Shilimkar

In CPU low power state, local timer looses its register context. This patch adds context save restore hooks which can be used by platforms appropriately.

I thought the whole point of CLOCK_EVT_FEAT_C3STOP was that the generic timer stuff wouldn't rely on it being kept alive?

Hmm, it looks like we bypass the clockevents code by only setting the TWD load value at initialization time, not when we switch to periodic mode. We really ought to rewrite it whenever we switch back to periodic mode.

I suspect fixing that means you won't need this save/restore support.

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Monday, January 24, 2011 4:41 PM
To: Santosh Shilimkar
Cc: linux-arm-kernel at lists.infradead.org; catalin.marinas at arm.com; ccross at android.com; linus.ml.walleij at gmail.com; linux- omap at vger.kernel.org
Subject: Re: [PATCH 3/5] ARM: twd: Add context save restore support

Quoted 2 lines · Russell King - ARM Linux

Quoted 1 line · Santosh Shilimkar

In CPU low power state, local timer looses its register context.

This

Quoted 1 line

Quoted 1 line

patch adds context save restore hooks which can be used by

platforms

Quoted 3 lines

Quoted 1 line

appropriately.

I thought the whole point of CLOCK_EVT_FEAT_C3STOP was that the

generic

Quoted 3 lines

timer stuff wouldn't rely on it being kept alive?

Hmm, it looks like we bypass the clockevents code by only setting

the

Quoted 1 line

TWD load value at initialization time, not when we switch to

periodic

Quoted 1 line

mode. We really ought to rewrite it whenever we switch back to

periodic

Quoted 3 lines

mode.

I suspect fixing that means you won't need this save/restore

support.

Untested, but should do what's required.

arch/arm/kernel/smp_twd.c +0 -0

index fd91566..60636f4 100644
@@ -36,6 +36,7 @@ static void twd_set_mode(enum clock_event_mode
 mode,
 		/* timer load already set up */
 		ctrl = TWD_TIMER_CONTROL_ENABLE |

TWD_TIMER_CONTROL_IT_ENABLE

arch/arm/kernel/smp_twd.c +1 -0

 			| TWD_TIMER_CONTROL_PERIODIC;
+		__raw_writel(twd_timer_rate / HZ, twd_base +

TWD_TIMER_LOAD);

arch/arm/kernel/smp_twd.c +1 -5

 		break;
 	case CLOCK_EVT_MODE_ONESHOT:
 		/* period set, and timer enabled in 'next_event' hook */

@@ -81,7 +82,7 @@ int twd_timer_ack(void)
 
 static void __cpuinit twd_calibrate_rate(void)
 {
-	unsigned long load, count;
+	unsigned long count;
 	u64 waitjiffies;
 
 	/*

@@ -116,10 +117,6 @@ static void __cpuinit twd_calibrate_rate(void)
 		printk("%lu.%02luMHz.\n", twd_timer_rate / 1000000,
 			(twd_timer_rate / 1000000) % 100);
 	}
-
-	load = twd_timer_rate / HZ;
-
-	__raw_writel(load, twd_base + TWD_TIMER_LOAD);
 }
 
 /*

Quoted 8 lines · Russell King - ARM Linux

Quoted 3 lines · Santosh Shilimkar

In CPU low power state, local timer looses its register context. This patch adds context save restore hooks which can be used by platforms appropriately.

I thought the whole point of CLOCK_EVT_FEAT_C3STOP was that the generic timer stuff wouldn't rely on it being kept alive?

Quoted 6 lines

Hmm, it looks like we bypass the clockevents code by only setting the TWD load value at initialization time, not when we switch to periodic mode. ?We really ought to rewrite it whenever we switch back to periodic mode.

I suspect fixing that means you won't need this save/restore support.

Untested, but should do what's required.

arch/arm/kernel/smp_twd.c +0 -0

index fd91566..60636f4 100644
@@ -36,6 +36,7 @@ static void twd_set_mode(enum clock_event_mode mode,

? ? ? ? ? ? ? ?/* timer load already set up */
? ? ? ? ? ? ? ?ctrl = TWD_TIMER_CONTROL_ENABLE | TWD_TIMER_CONTROL_IT_ENABLE ? ? ? ? ? ? ? ? ? ? ? ?| TWD_TIMER_CONTROL_PERIODIC;
+ ? ? ? ? ? ? ? __raw_writel(twd_timer_rate / HZ, twd_base + TWD_TIMER_LOAD); ? ? ? ? ? ? ? ?break;
? ? ? ?case CLOCK_EVT_MODE_ONESHOT:
? ? ? ? ? ? ? ?/* period set, and timer enabled in 'next_event' hook */

arch/arm/kernel/smp_twd.c +1 -1

@@ -81,7 +82,7 @@ int twd_timer_ack(void)
 
 ?static void __cpuinit twd_calibrate_rate(void)
 ?{
- ? ? ? unsigned long load, count;
+ ? ? ? unsigned long count;
 ? ? ? ?u64 waitjiffies;
 

? ? ? ?/*

arch/arm/kernel/smp_twd.c +0 -4

@@ -116,10 +117,6 @@ static void __cpuinit twd_calibrate_rate(void)
 ? ? ? ? ? ? ? ?printk("%lu.%02luMHz.\n", twd_timer_rate / 1000000,
 ? ? ? ? ? ? ? ? ? ? ? ?(twd_timer_rate / 1000000) % 100);
 ? ? ? ?}
-
- ? ? ? load = twd_timer_rate / HZ;
-
- ? ? ? __raw_writel(load, twd_base + TWD_TIMER_LOAD);
 ?}
 

?/*

Quoted 49 lines · Russell King - ARM Linux

Quoted 8 lines · Russell King - ARM Linux

Quoted 3 lines · Santosh Shilimkar

In CPU low power state, local timer looses its register context. This patch adds context save restore hooks which can be used by platforms appropriately.

I thought the whole point of CLOCK_EVT_FEAT_C3STOP was that the generic timer stuff wouldn't rely on it being kept alive?

Quoted 6 lines

Hmm, it looks like we bypass the clockevents code by only setting the TWD load value at initialization time, not when we switch to periodic mode. ?We really ought to rewrite it whenever we switch back to periodic mode.

I suspect fixing that means you won't need this save/restore support.

Untested, but should do what's required.

arch/arm/kernel/smp_twd.c +0 -0

index fd91566..60636f4 100644
@@ -36,6 +36,7 @@ static void twd_set_mode(enum clock_event_mode mode,

? ? ? ? ? ? ? ?/* timer load already set up */
? ? ? ? ? ? ? ?ctrl = TWD_TIMER_CONTROL_ENABLE | TWD_TIMER_CONTROL_IT_ENABLE ? ? ? ? ? ? ? ? ? ? ? ?| TWD_TIMER_CONTROL_PERIODIC;
+ ? ? ? ? ? ? ? __raw_writel(twd_timer_rate / HZ, twd_base + TWD_TIMER_LOAD); ? ? ? ? ? ? ? ?break;
? ? ? ?case CLOCK_EVT_MODE_ONESHOT:
? ? ? ? ? ? ? ?/* period set, and timer enabled in 'next_event' hook */

arch/arm/kernel/smp_twd.c +1 -1

@@ -81,7 +82,7 @@ int twd_timer_ack(void)
 
 ?static void __cpuinit twd_calibrate_rate(void)
 ?{
- ? ? ? unsigned long load, count;
+ ? ? ? unsigned long count;
 ? ? ? ?u64 waitjiffies;
 

? ? ? ?/*

arch/arm/kernel/smp_twd.c +0 -4

@@ -116,10 +117,6 @@ static void __cpuinit twd_calibrate_rate(void)
 ? ? ? ? ? ? ? ?printk("%lu.%02luMHz.\n", twd_timer_rate / 1000000,
 ? ? ? ? ? ? ? ? ? ? ? ?(twd_timer_rate / 1000000) % 100);
 ? ? ? ?}
-
- ? ? ? load = twd_timer_rate / HZ;
-
- ? ? ? __raw_writel(load, twd_base + TWD_TIMER_LOAD);
 ?}
 

Quoted 1 line

?/*

This doesn't work for oneshot timers if the TWD_TIMER_CONTROL register gets reset by cpu idle between twd_set_mode and twd_set_next_event. Shadowing ctrl in a percpu variable and rewriting it during every call to twd_set_next_event does work, but that's not much different, and a little less efficient, than just saving and restoring the control and load registers in idle. It does have the advantage that platforms don't need any extra calls.

Quoted 51 lines · Colin Cross

Quoted 49 lines · Russell King - ARM Linux

Quoted 8 lines · Russell King - ARM Linux

Quoted 3 lines · Santosh Shilimkar

In CPU low power state, local timer looses its register context. This patch adds context save restore hooks which can be used by platforms appropriately.

I thought the whole point of CLOCK_EVT_FEAT_C3STOP was that the generic timer stuff wouldn't rely on it being kept alive?

Quoted 6 lines

Hmm, it looks like we bypass the clockevents code by only setting the TWD load value at initialization time, not when we switch to periodic mode. ?We really ought to rewrite it whenever we switch back to periodic mode.

I suspect fixing that means you won't need this save/restore support.

Untested, but should do what's required.

arch/arm/kernel/smp_twd.c +0 -0

index fd91566..60636f4 100644
@@ -36,6 +36,7 @@ static void twd_set_mode(enum clock_event_mode mode,

? ? ? ? ? ? ? ?/* timer load already set up */
? ? ? ? ? ? ? ?ctrl = TWD_TIMER_CONTROL_ENABLE | TWD_TIMER_CONTROL_IT_ENABLE ? ? ? ? ? ? ? ? ? ? ? ?| TWD_TIMER_CONTROL_PERIODIC;
+ ? ? ? ? ? ? ? __raw_writel(twd_timer_rate / HZ, twd_base + TWD_TIMER_LOAD); ? ? ? ? ? ? ? ?break;
? ? ? ?case CLOCK_EVT_MODE_ONESHOT:
? ? ? ? ? ? ? ?/* period set, and timer enabled in 'next_event' hook */

arch/arm/kernel/smp_twd.c +1 -1

@@ -81,7 +82,7 @@ int twd_timer_ack(void)
 
 ?static void __cpuinit twd_calibrate_rate(void)
 ?{
- ? ? ? unsigned long load, count;
+ ? ? ? unsigned long count;
 ? ? ? ?u64 waitjiffies;
 

? ? ? ?/*

arch/arm/kernel/smp_twd.c +0 -4

@@ -116,10 +117,6 @@ static void __cpuinit twd_calibrate_rate(void)
 ? ? ? ? ? ? ? ?printk("%lu.%02luMHz.\n", twd_timer_rate / 1000000,
 ? ? ? ? ? ? ? ? ? ? ? ?(twd_timer_rate / 1000000) % 100);
 ? ? ? ?}
-
- ? ? ? load = twd_timer_rate / HZ;
-
- ? ? ? __raw_writel(load, twd_base + TWD_TIMER_LOAD);
 ?}
 

Quoted 9 lines

Quoted 1 line

?/*

This doesn't work for oneshot timers if the TWD_TIMER_CONTROL register gets reset by cpu idle between twd_set_mode and twd_set_next_event. Shadowing ctrl in a percpu variable and rewriting it during every call to twd_set_next_event does work, but that's not much different, and a little less efficient, than just saving and restoring the control and load registers in idle. It does have the advantage that platforms don't need any extra calls.

The next question is can we teach the generic time infrastructure about this so we don't have to modify every clock event driver for it? We really need to get away from having this kind of knowledge buried down in the lowest levels of every driver.

Quoted 62 lines · Russell King - ARM Linux

Quoted 60 lines · Colin Cross

Quoted 49 lines · Russell King - ARM Linux

Quoted 8 lines · Russell King - ARM Linux

Quoted 3 lines · Santosh Shilimkar

In CPU low power state, local timer looses its register context. This patch adds context save restore hooks which can be used by platforms appropriately.

I thought the whole point of CLOCK_EVT_FEAT_C3STOP was that the generic timer stuff wouldn't rely on it being kept alive?

Quoted 6 lines

Hmm, it looks like we bypass the clockevents code by only setting the TWD load value at initialization time, not when we switch to periodic mode. ?We really ought to rewrite it whenever we switch back to periodic mode.

I suspect fixing that means you won't need this save/restore support.

Untested, but should do what's required.

arch/arm/kernel/smp_twd.c +0 -0

index fd91566..60636f4 100644
@@ -36,6 +36,7 @@ static void twd_set_mode(enum clock_event_mode mode,

? ? ? ? ? ? ? ?/* timer load already set up */
? ? ? ? ? ? ? ?ctrl = TWD_TIMER_CONTROL_ENABLE | TWD_TIMER_CONTROL_IT_ENABLE ? ? ? ? ? ? ? ? ? ? ? ?| TWD_TIMER_CONTROL_PERIODIC;
+ ? ? ? ? ? ? ? __raw_writel(twd_timer_rate / HZ, twd_base + TWD_TIMER_LOAD); ? ? ? ? ? ? ? ?break;
? ? ? ?case CLOCK_EVT_MODE_ONESHOT:
? ? ? ? ? ? ? ?/* period set, and timer enabled in 'next_event' hook */

arch/arm/kernel/smp_twd.c +1 -1

@@ -81,7 +82,7 @@ int twd_timer_ack(void)
 
 ?static void __cpuinit twd_calibrate_rate(void)
 ?{
- ? ? ? unsigned long load, count;
+ ? ? ? unsigned long count;
 ? ? ? ?u64 waitjiffies;
 

? ? ? ?/*

arch/arm/kernel/smp_twd.c +0 -4

@@ -116,10 +117,6 @@ static void __cpuinit twd_calibrate_rate(void)
 ? ? ? ? ? ? ? ?printk("%lu.%02luMHz.\n", twd_timer_rate / 1000000,
 ? ? ? ? ? ? ? ? ? ? ? ?(twd_timer_rate / 1000000) % 100);
 ? ? ? ?}
-
- ? ? ? load = twd_timer_rate / HZ;
-
- ? ? ? __raw_writel(load, twd_base + TWD_TIMER_LOAD);
 ?}
 

Quoted 1 line

?/*

This doesn't work for oneshot timers if the TWD_TIMER_CONTROL register gets reset by cpu idle between twd_set_mode and twd_set_next_event. Shadowing ctrl in a percpu variable and rewriting it during every call to twd_set_next_event does work, but that's not much different, and a little less efficient, than just saving and restoring the control and load registers in idle. It does have the advantage that platforms don't need any extra calls.

Quoted 4 lines

The next question is can we teach the generic time infrastructure about this so we don't have to modify every clock event driver for it? We really need to get away from having this kind of knowledge buried down in the lowest levels of every driver.

In which way? I mean the generic code issues a call to the set_mode function when we leave the broadcast mode. So what should the generic code do more ?

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Tuesday, January 25, 2011 7:08 PM
To: Thomas Gleixner
Cc: Colin Cross; Santosh Shilimkar; catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux-omap at vger.kernel.org; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH 3/5] ARM: twd: Add context save restore support

Quoted 1 line · Thomas Gleixner

On Tue, 25 Jan 2011, Russell King - ARM Linux wrote:

Quoted 1 line

Quoted 1 line

The next question is can we teach the generic time

infrastructure about

Quoted 1 line

Quoted 1 line

this so we don't have to modify every clock event driver for it?

We

Quoted 1 line

Quoted 1 line

really need to get away from having this kind of knowledge

buried down

Quoted 3 lines

Quoted 1 line

in the lowest levels of every driver.

In which way? I mean the generic code issues a call to the

set_mode

Quoted 1 line

function when we leave the broadcast mode. So what should the

generic

Quoted 1 line

code do more ?

I can't say because these patches only add the hooks, there's no implementation yet which uses the hooks.

Given the description about _why_ those hooks are necessary, it seems
that something is required. Either we start adding custom hacks to each clockevent driver as is done with this patch, or we get some generic help in place.

I'm not thrilled by the custom hack approach - and I thought the clockevent stuff was created to stop this kind of thing happening.

I suggest we defer this until there's a visible use case available.

Quoted 3 lines · Thomas Gleixner

In which way? I mean the generic code issues a call to the set_mode function when we leave the broadcast mode. So what should the generic code do more ?

I can't say because these patches only add the hooks, there's no implementation yet which uses the hooks.

Given the description about _why_ those hooks are necessary, it seems that something is required. Either we start adding custom hacks to each clockevent driver as is done with this patch, or we get some generic help in place.

I'm not thrilled by the custom hack approach - and I thought the clockevent stuff was created to stop this kind of thing happening.

Quoted 8 lines · Russell King - ARM Linux

Quoted 3 lines · Thomas Gleixner

In which way? I mean the generic code issues a call to the set_mode function when we leave the broadcast mode. So what should the generic code do more ?

I can't say because these patches only add the hooks, there's no implementation yet which uses the hooks.

Quoted 7 lines

Given the description about _why_ those hooks are necessary, it seems that something is required. Either we start adding custom hacks to each clockevent driver as is done with this patch, or we get some generic help in place.

I'm not thrilled by the custom hack approach - and I thought the clockevent stuff was created to stop this kind of thing happening.

Yes, and it does the right thing:

     idle enter (where the cpu local tick device stops)

     	  tick_broadcast_oneshot_control(CLOCK_EVT_NOTIFY_BROADCAST_ENTER)

		clockevents_set_mode(dev, CLOCK_EVT_MODE_SHUTDOWN)
		tick_broadcast_set_event(dev->next_event, 1)

    idle exit

     	  tick_broadcast_oneshot_control(CLOCK_EVT_NOTIFY_BROADCAST_EXIT)

		clockevents_set_mode(dev, CLOCK_EVT_MODE_ONESHOT)
		tick_program_event(dev->next_event, 1)

So the generic code has all the calls in place. If a clock chip implementation misses to set control registers in the CLOCK_EVT_MODE_ONESHOT case, then it's not a short coming of the generic code which needs magic hooks in the arch code.

The same applies for the periodic mode switch, which is handled via tick_broadcast_on_off().

Am I missing something ?

Quoted 41 lines · Thomas Gleixner

Quoted 8 lines · Russell King - ARM Linux

Quoted 3 lines · Thomas Gleixner

In which way? I mean the generic code issues a call to the set_mode function when we leave the broadcast mode. So what should the generic code do more ?

I can't say because these patches only add the hooks, there's no implementation yet which uses the hooks.

Quoted 7 lines

Given the description about _why_ those hooks are necessary, it seems that something is required. Either we start adding custom hacks to each clockevent driver as is done with this patch, or we get some generic help in place.

I'm not thrilled by the custom hack approach - and I thought the clockevent stuff was created to stop this kind of thing happening.

Yes, and it does the right thing:

     idle enter (where the cpu local tick device stops)

     	  tick_broadcast_oneshot_control(CLOCK_EVT_NOTIFY_BROADCAST_ENTER)

		clockevents_set_mode(dev, CLOCK_EVT_MODE_SHUTDOWN)
		tick_broadcast_set_event(dev->next_event, 1)

    idle exit

     	  tick_broadcast_oneshot_control(CLOCK_EVT_NOTIFY_BROADCAST_EXIT)

		clockevents_set_mode(dev, CLOCK_EVT_MODE_ONESHOT)
		tick_program_event(dev->next_event, 1)

So the generic code has all the calls in place. If a clock chip implementation misses to set control registers in the CLOCK_EVT_MODE_ONESHOT case, then it's not a short coming of the generic code which needs magic hooks in the arch code.

The same applies for the periodic mode switch, which is handled via tick_broadcast_on_off().

Quoted 1 line

Am I missing something ?

I quote Colin:

| This doesn't work for oneshot timers if the TWD_TIMER_CONTROL register | gets reset by cpu idle between twd_set_mode and twd_set_next_event.

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Tuesday, January 25, 2011 7:08 PM
To: Thomas Gleixner
Cc: Colin Cross; Santosh Shilimkar; catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux-omap at vger.kernel.org; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH 3/5] ARM: twd: Add context save restore support

I can't say because these patches only add the hooks, there's no implementation yet which uses the hooks.

Given the description about _why_ those hooks are necessary, it seems
that something is required. Either we start adding custom hacks to each clockevent driver as is done with this patch, or we get some generic help in place.

I'm not thrilled by the custom hack approach - and I thought the clockevent stuff was created to stop this kind of thing happening.

I suggest we defer this until there's a visible use case available.

Russell, Thomas

Quoted 9 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Tuesday, January 25, 2011 7:08 PM
To: Thomas Gleixner
Cc: Colin Cross; Santosh Shilimkar; catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux-omap at vger.kernel.org; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH 3/5] ARM: twd: Add context save restore support

[...]

Quoted 10 lines

I can't say because these patches only add the hooks, there's no implementation yet which uses the hooks.

Given the description about _why_ those hooks are necessary, it seems
that something is required. Either we start adding custom hacks to each clockevent driver as is done with this patch, or we get some generic help in place.

Quoted 4 lines

I'm not thrilled by the custom hack approach - and I thought the clockevent stuff was created to stop this kind of thing happening.

I suggest we defer this until there's a visible use case available.

Got some time to debug this issue. OMAP idle code already has the broad-cast notifiers working for sometime. So I removed the existing save restore twd code and just used the below patch which Russell posted on this thread.
And things just work and I guess we are done with this issue !! Timer framework is doing all right things with notifiers.

Am going to use this patch for my further work and drop the save/restore patch. Will update you if there is any other issue on this. I should have validated this patch on my own earlier :(

Thanks for the discussion.

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Tuesday, January 25, 2011 9:43 PM
To: Santosh Shilimkar
Cc: Thomas Gleixner; Colin Cross; catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux-omap at vger.kernel.org; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH 3/5] ARM: twd: Add context save restore support

Quoted 7 lines · Santosh Shilimkar

Russell, Thomas

Quoted 6 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Tuesday, January 25, 2011 7:08 PM
To: Thomas Gleixner
Cc: Colin Cross; Santosh Shilimkar; catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux-omap at vger.kernel.org; linux-

arm-

Quoted 2 lines

Quoted 2 lines

kernel at lists.infradead.org
Subject: Re: [PATCH 3/5] ARM: twd: Add context save restore

support

Quoted 9 lines

Quoted 1 line

[...]

Quoted 7 lines

I can't say because these patches only add the hooks, there's no implementation yet which uses the hooks.

Given the description about _why_ those hooks are necessary, it seems
that something is required. Either we start adding custom hacks

to

Quoted 1 line

Quoted 1 line

each clockevent driver as is done with this patch, or we get

some

Quoted 4 lines

Quoted 4 lines

generic help in place.

I'm not thrilled by the custom hack approach - and I thought the clockevent stuff was created to stop this kind of thing

happening.

Quoted 2 lines

Quoted 2 lines

I suggest we defer this until there's a visible use case

available.

Quoted 2 lines

Got some time to debug this issue. OMAP idle code already has the broad-cast notifiers working for sometime. So I removed the

existing

Quoted 5 lines

save restore twd code and just used the below patch which Russell posted on this thread.
And things just work and I guess we are done with this issue !! Timer framework is doing all right things with notifiers.

Quoted 6 lines

Am going to use this patch for my further work and drop the save/restore patch. Will update you if there is any other issue on this. I should have validated this patch on my own earlier :(

Thanks for the discussion.

Thanks - I guess that's a tested-by then?

This doesn't work for oneshot timers if the TWD_TIMER_CONTROL register gets reset by cpu idle between twd_set_mode and twd_set_next_event. Shadowing ctrl in a percpu variable and rewriting it during every call to twd_set_next_event does work, but that's not much different, and a little less efficient, than just saving and restoring the control and load registers in idle. It does have the advantage that platforms don't need any extra calls.

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Tuesday, January 25, 2011 5:00 PM
To: Colin Cross
Cc: Santosh Shilimkar; catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux-omap at vger.kernel.org; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH 3/5] ARM: twd: Add context save restore support

Quoted 1 line · Colin Cross

This doesn't work for oneshot timers if the TWD_TIMER_CONTROL

register

Quoted 1 line

gets reset by cpu idle between twd_set_mode and

twd_set_next_event.

Quoted 1 line

Shadowing ctrl in a percpu variable and rewriting it during every

call

Quoted 1 line

to twd_set_next_event does work, but that's not much different,

and a

Quoted 1 line

little less efficient, than just saving and restoring the control

and

Quoted 2 lines

load registers in idle. It does have the advantage that platforms don't need any extra calls.

BTW, do you think the patch is, nevertheless, an improvement and something
we should do? If so, please can I have your ack for it?

As I was suspecting the one shot mode wouldn't work it. Collin just confirmed it.
To make it fully work it needs control register save restore. And that can be managed within TWD library so that every platform doesn't have to bother of calling it from their idle code.

Do you prefer that as a separate patch or I can post a new version in which can add your fix + per cpu control register shadowing ?

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Tuesday, January 25, 2011 5:19 PM
To: Santosh Shilimkar
Cc: Colin Cross; catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux-omap at vger.kernel.org; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH 3/5] ARM: twd: Add context save restore support

Quoted 8 lines · Santosh Shilimkar

As I was suspecting the one shot mode wouldn't work it. Collin just confirmed it.
To make it fully work it needs control register save restore. And that can be managed within TWD library so that every platform doesn't have to bother of calling it from their idle code.

Do you prefer that as a separate patch or I can post a new version in which can add your fix + per cpu control register shadowing ?

I said earlier:
| The next question is can we teach the generic time infrastructure about
| this so we don't have to modify every clock event driver for it? We
| really need to get away from having this kind of knowledge buried down
| in the lowest levels of every driver.

IOW, if we go into a PM idle mode, when we come back out we need to call clockevent set_mode to ensure that the control register is properly
reset. I don't think its right to have this kind of knowledge buried
in each and every clockevent driver.

Looping Thomas G

Quoted 28 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Tuesday, January 25, 2011 5:19 PM
To: Santosh Shilimkar
Cc: Colin Cross; catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux-omap at vger.kernel.org; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH 3/5] ARM: twd: Add context save restore support

Quoted 8 lines · Santosh Shilimkar

As I was suspecting the one shot mode wouldn't work it. Collin just confirmed it.
To make it fully work it needs control register save restore. And that can be managed within TWD library so that every platform doesn't have to bother of calling it from their idle code.

Do you prefer that as a separate patch or I can post a new version in which can add your fix + per cpu control register shadowing ?

I said earlier:
| The next question is can we teach the generic time infrastructure about
| this so we don't have to modify every clock event driver for it? We
| really need to get away from having this kind of knowledge buried down
| in the lowest levels of every driver.

Quoted 6 lines

IOW, if we go into a PM idle mode, when we come back out we need to call clockevent set_mode to ensure that the control register is properly
reset. I don't think its right to have this kind of knowledge buried
in each and every clockevent driver.

May be Thomas can comment on this.

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Tuesday, January 25, 2011 5:48 PM
To: Santosh Shilimkar
Cc: Thomas Gleixner; Colin Cross; catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux-omap at vger.kernel.org; linux-arm- kernel at lists.infradead.org
Subject: Re: [PATCH 3/5] ARM: twd: Add context save restore support

Quoted 5 lines

Quoted 5 lines

call clockevent set_mode to ensure that the control register is properly
reset. I don't think its right to have this kind of knowledge buried
in each and every clockevent driver.

Quoted 1 line

May be Thomas can comment on this.

He was already added on my previous email... we're going round in circles.

Quoted 7 lines · Colin Cross

This doesn't work for oneshot timers if the TWD_TIMER_CONTROL register gets reset by cpu idle between twd_set_mode and twd_set_next_event. Shadowing ctrl in a percpu variable and rewriting it during every call to twd_set_next_event does work, but that's not much different, and a little less efficient, than just saving and restoring the control and load registers in idle. ?It does have the advantage that platforms don't need any extra calls.

BTW, do you think the patch is, nevertheless, an improvement and something we should do? ?If so, please can I have your ack for it?

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Monday, January 24, 2011 4:36 PM
To: Santosh Shilimkar
Cc: linux-arm-kernel at lists.infradead.org; catalin.marinas at arm.com; ccross at android.com; linus.ml.walleij at gmail.com; linux- omap at vger.kernel.org
Subject: Re: [PATCH 3/5] ARM: twd: Add context save restore support

Quoted 1 line · Santosh Shilimkar

In CPU low power state, local timer looses its register context.

This

Quoted 1 line

patch adds context save restore hooks which can be used by

platforms

Quoted 1 line

appropriately.

I thought the whole point of CLOCK_EVT_FEAT_C3STOP was that the generic
timer stuff wouldn't rely on it being kept alive?

Hmm, it looks like we bypass the clockevents code by only setting the
TWD load value at initialization time, not when we switch to periodic
mode. We really ought to rewrite it whenever we switch back to periodic
mode.

I suspect fixing that means you won't need this save/restore support.

This patch moves SCU register defines from smp_scu.c to smp_scu.h so that its available for platforms to use

The SCU CPU power status registers is used for power management on OMAP4.

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Tuesday, January 25, 2011 5:17 PM
To: Santosh Shilimkar
Cc: linux-arm-kernel at lists.infradead.org; catalin.marinas at arm.com; ccross at android.com; linus.ml.walleij at gmail.com; linux- omap at vger.kernel.org
Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header file

Quoted 3 lines · Santosh Shilimkar

This patch moves SCU register defines from smp_scu.c to smp_scu.h so that its available for platforms to use

Quoted 2 lines

The SCU CPU power status registers is used for power management on OMAP4.

Could we instead have an API inside smp_scu.c rather than having each
SoC implement its own SCU PM stuff?

Maybe this. Note that scu_power_mode() needs to be called from a non-
preemptible context, which is sane as we don't want to be rescheduled
onto a different CPU between scu_power_mode() and the wfi/wfe required
to enter the selected mode.

I have similar patch implemented but what it does is just prepares the value to be programmed and stores it to a scratchpad. I see your point but below patch may now work well. The reason is the SCU register needs to accessed at the lowest level. May be even when stack is not available. Also this register needs to be cleared in cases where the attempted power state is failed for some reason.

Quoted 8 lines · Santosh Shilimkar

I have similar patch implemented but what it does is just prepares the value to be programmed and stores it to a scratchpad. I see your point but below patch may now work well. The reason is the SCU register needs to accessed at the lowest level. May be even when stack is not available. Also this register needs to be cleared in cases where the attempted power state is failed for some reason.

From the documentation I have, the power control register has no effect

until the CPU enters WFI mode - which means that provided we can guarantee no one issues a WFI instruction between setting the power mode, and executing that instruction, being woken up (or failing) and resetting the power mode back... that shouldn't require the power mode to be programmed from assembly code.

In any case, we actually need the help of spinlocks to deal with concurrent access to the SCU power control register - something you can't do in assembly code.

On the way down to a WFI low power mode, we can call scu_power_mode(), do the rest of the cleanup (which must not schedule) and issue WFI. On the way back up, do whatever needs to be done and call scu_power_mode() to reset back to 'normal' mode.

Quoted 3 lines

Also note that this register can be blocked using trust-zone which again makes it platform dependent because direct write won't be allowed in that case.

Yes, I did notice. What's the OMAP SMC interface for that?

Quoted 6 lines

I would prefer the header export if there is no major objection since there is already a possibility of custom implementation with trust zone.

On OMAP4, on ES1.0 we need to use a secure API to achieve this where as on ES2.0, it can be directly accessed.

As I say, I'd rather not have each SoC implementing access to this as someone's bound to forget the spinlock if they're dealing with more than one CPU, which'll make stuff unreliable (just like I did on my initial version.)

We could have a callback to SoC code which does the appropriate SMC call, but first I'll need to know what's required for the SMC call.

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Tuesday, January 25, 2011 5:59 PM
To: Santosh Shilimkar
Cc: catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux- omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; ccross at android.com
Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header file

I did mean to include the updated patch:

 arch/arm/include/asm/smp_scu.h |    5 +++++
 arch/arm/kernel/smp_scu.c      |   23 +++++++++++++++++++++++
 2 files changed, 28 insertions(+), 0 deletions(-)

If we need a SMC call, that should happen within the spinlock'd region via
a function pointer which the platform can set. I can't code that into this
patch until I know what the SMC call requires as arguments (cpu number,
power state, or new register value, or mask and bits to set?)

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Tuesday, January 25, 2011 5:47 PM
To: Santosh Shilimkar
Cc: linux-arm-kernel at lists.infradead.org; catalin.marinas at arm.com; ccross at android.com; linus.ml.walleij at gmail.com; linux- omap at vger.kernel.org
Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header file

Quoted 3 lines · Santosh Shilimkar

I have similar patch implemented but what it does is just prepares the value to be programmed and stores it to a scratchpad. I see your point but below patch may now work well. The reason is

the SCU

Quoted 2 lines

register needs to accessed at the lowest level. May be even when stack is not available. Also this register needs to be cleared in

cases

Quoted 1 line

where the attempted power state is failed for some reason.

From the documentation I have, the power control register has no effect
until the CPU enters WFI mode - which means that provided we can guarantee no one issues a WFI instruction between setting the power mode,
and executing that instruction, being woken up (or failing) and resetting
the power mode back... that shouldn't require the power mode to be programmed from assembly code.

In any case, we actually need the help of spinlocks to deal with concurrent access to the SCU power control register - something you can't do in assembly code.

On the way down to a WFI low power mode, we can call scu_power_mode(),
do the rest of the cleanup (which must not schedule) and issue WFI. On
the way back up, do whatever needs to be done and call scu_power_mode()
to reset back to 'normal' mode.

Quoted 4 lines

Also note that this register can be blocked using trust-zone which again makes it platform dependent because direct write won't be allowed in that case.

Yes, I did notice. What's the OMAP SMC interface for that?

Quoted 6 lines

I would prefer the header export if there is no major objection since there is already a possibility of custom implementation with trust zone.

On OMAP4, on ES1.0 we need to use a secure API to achieve this where as on ES2.0, it can be directly accessed.

As I say, I'd rather not have each SoC implementing access to this as
someone's bound to forget the spinlock if they're dealing with more than
one CPU, which'll make stuff unreliable (just like I did on my initial
version.)
We could have a callback to SoC code which does the appropriate SMC call,
but first I'll need to know what's required for the SMC call.

Ok. I missed some information my last email.
The SCU power status programming is used to take CPU in/out of coherency as an alternative to SMP bit. We don't have an access to SMP bit on OMAP4. ARM has already confirmed SCU programming is same as SMP bit enable/disable.

I don't know how safe is to use spin lock when one CPU is goes out of coherency after programming the power state. The spin lock release may not even be visible to other CPU.

Quoted 9 lines · Santosh Shilimkar

Ok. I missed some information my last email.
The SCU power status programming is used to take CPU in/out of coherency as an alternative to SMP bit. We don't have an access to SMP bit on OMAP4. ARM has already confirmed SCU programming is same as SMP bit enable/disable.

I don't know how safe is to use spin lock when one CPU is goes out of coherency after programming the power state. The spin lock release may not even be visible to other CPU.

Erm, I do hope that's not the case, as that means it is unsafe for CPUs in a SMP system to write to this register without them potentially trampling over each other.

If it is the case, then the solutions are either:
1. Fix the hardware so that coherency requests only yet turned off when entering the WFI state.
2. Fix the hardware such that each CPU has a separate register.

Actually, we can do this safely - byte stores are permitted to SCU registers probably for this very reason.

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Tuesday, January 25, 2011 6:36 PM
To: Santosh Shilimkar
Cc: catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux- omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; ccross at android.com
Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header file

Quoted 2 lines · Russell King - ARM Linux

Actually, we can do this safely - byte stores are permitted to SCU registers probably for this very reason.

3rd revision of the patch:

After fixing the 3rd version for base address break, I was able to use this patch and test it. Seems to work. SMC related stuff can be ignored because OMAP4 ES1.0 doesn't have functional PM hardware support.

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Friday, February 04, 2011 4:11 PM
To: Santosh Shilimkar
Cc: catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux- omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; ccross at android.com
Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header file

On Tue, Jan 25, 2011 at 11:53:35PM +0530, Santosh Shilimkar wrote:

Quoted 4 lines

After fixing the 3rd version for base address break, I was able to use this patch and test it. Seems to work. SMC related stuff can be ignored because OMAP4 ES1.0 doesn't have functional PM hardware support.

I think I'd prefer to do as the other functions do, and pass in the scu base address from the platform code. It's potentially more efficient for platforms which have a fixed SCU base address.

Quoted 16 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Friday, February 04, 2011 4:11 PM
To: Santosh Shilimkar
Cc: catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux- omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; ccross at android.com
Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header file

Quoted 4 lines · Santosh Shilimkar

After fixing the 3rd version for base address break, I was able to use this patch and test it. Seems to work. SMC related stuff can be ignored because OMAP4 ES1.0 doesn't have functional PM hardware support.

Quoted 3 lines

I think I'd prefer to do as the other functions do, and pass in the scu base address from the platform code. It's potentially more efficient for platforms which have a fixed SCU base address.

Ok. I can fix that

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Friday, February 04, 2011 5:01 PM
To: Santosh Shilimkar
Cc: catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux- omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; ccross at android.com
Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header file

Quoted 8 lines · Santosh Shilimkar

Quoted 8 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Friday, February 04, 2011 4:11 PM
To: Santosh Shilimkar
Cc: catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux- omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; ccross at android.com
Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to

header

Quoted 3 lines

Quoted 3 lines

file

On Tue, Jan 25, 2011 at 11:53:35PM +0530, Santosh Shilimkar

Quoted 1 line · wrote:

Quoted 1 line

Quoted 1 line

After fixing the 3rd version for base address break, I was

able to

Quoted 1 line

Quoted 1 line

Quoted 1 line

use this patch and test it. Seems to work. SMC related stuff

can

Quoted 1 line

Quoted 1 line

Quoted 1 line

be ignored because OMAP4 ES1.0 doesn't have functional PM

hardware

Quoted 3 lines

Quoted 3 lines

Quoted 1 line

support.

I think I'd prefer to do as the other functions do, and pass in

the

Quoted 3 lines

Quoted 2 lines

scu base address from the platform code. It's potentially more efficient for platforms which have a fixed SCU base address.

Ok. I can fix that

8<------
Subject: [PATCH] ARM: smp: add function to set WFI low-power mode for SMP CPUs

Add a function to set the SCU low-power mode for SMP CPUs. This centralizes this functionality rather than having to expose the SCU register definitions to each platform.

Signed-off-by Russell King <[email protected]>

---
 arch/arm/include/asm/smp_scu.h |    5 +++++
 arch/arm/kernel/smp_scu.c      |   24 ++++++++++++++++++++++++
 2 files changed, 29 insertions(+), 0 deletions(-)

arch/arm/include/asm/smp_scu.h +5 -0

index 2376835..800860d 100644
@@ -1,7 +1,12 @@
 #ifndef __ASMARM_ARCH_SCU_H
 #define __ASMARM_ARCH_SCU_H
 
+#define SCU_PM_NORMAL	0
+#define SCU_PM_DORMANT	2
+#define SCU_PM_POWEROFF	3
+
 unsigned int scu_get_core_count(void __iomem *);
 void scu_enable(void __iomem *);
+int scu_power_mode(void __iomem *, unsigned int);
 
 #endif

arch/arm/kernel/smp_scu.c +7 -0

index 9ab4149..0ba329a 100644
@@ -50,3 +50,27 @@ void __init scu_enable(void __iomem *scu_base)
 	 */
 	flush_cache_all();
 }
+
+/*
+ * Set the executing CPUs power mode as defined.  This will be in
+ * preparation for it executing a WFI instruction.
+ *
+ * This function must be called with preemption disabled, and as it
+ * has the side effect of disabling coherency, caches must have

been
+ * flushed. Interrupts must also have been disabled.
+ */

arch/arm/kernel/smp_scu.c +15 -1

+int scu_power_mode(void __iomem *scu_base, unsigned int mode)
+{
+	unsigned int val;
+	int cpu = smp_processor_id();
+	int shift;
+
+	if (mode > 3 || mode == 1 || cpu > 3)
+		return -EINVAL;
+
+	val = __raw_readb(scu_base + SCU_CPU_STATUS + cpu) & ~0x03;
+	val |= mode;
+	__raw_writeb(val, scu_base + SCU_CPU_STATUS + cpu);
+
+	return 0;
+}
--

1.6.2.5

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Friday, February 04, 2011 5:01 PM
To: Santosh Shilimkar
Cc: catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux- omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; ccross at android.com
Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header file

8<------
Subject: [PATCH] ARM: smp: add function to set WFI low-power mode for SMP CPUs

Add a function to set the SCU low-power mode for SMP CPUs. This centralizes this functionality rather than having to expose the SCU register definitions to each platform.

Signed-off-by Russell King <[email protected]>

---
 arch/arm/include/asm/smp_scu.h |    5 +++++
 arch/arm/kernel/smp_scu.c      |   24 ++++++++++++++++++++++++
 2 files changed, 29 insertions(+), 0 deletions(-)

arch/arm/kernel/smp_scu.c +7 -0

index 9ab4149..0ba329a 100644
@@ -50,3 +50,27 @@ void __init scu_enable(void __iomem *scu_base)
 	 */
 	flush_cache_all();
 }
+
+/*
+ * Set the executing CPUs power mode as defined.  This will be in
+ * preparation for it executing a WFI instruction.
+ *
+ * This function must be called with preemption disabled, and as it
+ * has the side effect of disabling coherency, caches must have

been
+ * flushed. Interrupts must also have been disabled.
+ */

arch/arm/kernel/smp_scu.c +10 -1

+
+	if (mode > 3 || mode == 1 || cpu > 3)
+		return -EINVAL;
+
+	val = __raw_readb(scu_base + SCU_CPU_STATUS + cpu) & ~0x03;
+	val |= mode;
+	__raw_writeb(val, scu_base + SCU_CPU_STATUS + cpu);
+
+	return 0;
+}
--

1.6.2.5

Quoted 10 lines

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Friday, February 04, 2011 5:01 PM
To: Santosh Shilimkar
Cc: catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux- omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; ccross at android.com
Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header file

[.....]

Quoted 14 lines

8<------
Subject: [PATCH] ARM: smp: add function to set WFI low-power mode for SMP CPUs

Add a function to set the SCU low-power mode for SMP CPUs. This centralizes this functionality rather than having to expose the SCU register definitions to each platform.

Signed-off-by Russell King <[email protected]>

---
 arch/arm/include/asm/smp_scu.h |    5 +++++
 arch/arm/kernel/smp_scu.c      |   24 ++++++++++++++++++++++++
 2 files changed, 29 insertions(+), 0 deletions(-)

[....]

Quoted 16 lines

arch/arm/kernel/smp_scu.c +7 -0

index 9ab4149..0ba329a 100644
@@ -50,3 +50,27 @@ void __init scu_enable(void __iomem *scu_base)
 	 */
 	flush_cache_all();
 }
+
+/*
+ * Set the executing CPUs power mode as defined.  This will be in
+ * preparation for it executing a WFI instruction.
+ *
+ * This function must be called with preemption disabled, and as it
+ * has the side effect of disabling coherency, caches must have

been

arch/arm/kernel/smp_scu.c void __init scu_enable(void __iomem *scu_base) · line 66

Quoted 7 lines

+ * flushed. Interrupts must also have been disabled.
+ */

arch/arm/kernel/smp_scu.c +5 -0

+int scu_power_mode(void __iomem *scu_base, unsigned int mode)
+{
+	unsigned int val;
+	int cpu = smp_processor_id();
+	int shift;

shift is unused with this version now so I am removing it.

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Monday, February 07, 2011 3:48 PM
To: Santosh Shilimkar
Cc: catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux- omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; ccross at android.com
Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header file

Quoted 6 lines

arch/arm/kernel/smp_scu.c void __init scu_enable(void __iomem *scu_base) · line 66

Quoted 5 lines

arch/arm/kernel/smp_scu.c +5 -0

+int scu_power_mode(void __iomem *scu_base, unsigned int mode)
+{
+	unsigned int val;
+	int cpu = smp_processor_id();
+	int shift;

shift is unused with this version now so I am removing it.

Yes, I noticed that - it's gone in the version I merged into my tree.

Quoted 9 lines

Quoted 6 lines

arch/arm/kernel/smp_scu.c void __init scu_enable(void __iomem *scu_base) · line 66

Quoted 5 lines

arch/arm/kernel/smp_scu.c +5 -0

+int scu_power_mode(void __iomem *scu_base, unsigned int mode)
+{
+	unsigned int val;
+	int cpu = smp_processor_id();
+	int shift;

shift is unused with this version now so I am removing it.

Yes, I noticed that - it's gone in the version I merged into my tree.

Ok.
Did you also merged twd patch of yours ?

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Monday, February 07, 2011 3:54 PM
To: Santosh Shilimkar
Cc: catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux- omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; ccross at android.com
Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header file

Quoted 1 line · Santosh Shilimkar

Quoted 1 line

Quoted 1 line

Quoted 1 line

+int scu_power_mode(void __iomem *scu_base, unsigned int

mode)

Quoted 10 lines

Quoted 8 lines

Quoted 5 lines

arch/arm/kernel/smp_scu.c void __init scu_enable(void __iomem *scu_base) · line 66

Quoted 4 lines

arch/arm/kernel/smp_scu.c +4 -0

+{
+	unsigned int val;
+	int cpu = smp_processor_id();
+	int shift;

shift is unused with this version now so I am removing it.

Yes, I noticed that - it's gone in the version I merged into my tree.

Ok.
Did you also merged twd patch of yours ?

Both:

ARM: twd: ensure timer reload is reprogrammed on entry to
periodic mode
ARM: twd: fix display of twd frequency

are in mainline. They both qualify as bug fixes, so go in during - rc periods.

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Monday, February 07, 2011 3:48 PM
To: Santosh Shilimkar
Cc: catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux- omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; ccross at android.com
Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header file

Quoted 2 lines

Quoted 2 lines

8<------
Subject: [PATCH] ARM: smp: add function to set WFI low-power

mode

Quoted 12 lines

Quoted 12 lines

for SMP CPUs

Add a function to set the SCU low-power mode for SMP CPUs. This centralizes this functionality rather than having to expose the SCU register definitions to each platform.

Signed-off-by Russell King <[email protected]>

---
 arch/arm/include/asm/smp_scu.h |    5 +++++
 arch/arm/kernel/smp_scu.c      |   24 ++++++++++++++++++++++++
 2 files changed, 29 insertions(+), 0 deletions(-)

Quoted 6 lines

Review

Quoted 5 lines

(quoted diff) +5 -0

+int scu_power_mode(void __iomem *scu_base, unsigned int mode)
+{
+	unsigned int val;
+	int cpu = smp_processor_id();
+	int shift;

shift is unused with this version now so I am removing it.

Yes, I noticed that - it's gone in the version I merged into my tree.

This patch will need below update so that the smp_scu.h header can be included from assembly files. Will you fold this into your patch or you want me to send below as separate patch ?

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Thursday, February 10, 2011 9:44 PM
To: Santosh Shilimkar
Cc: catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux- omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; ccross at android.com
Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header file

Quoted 4 lines · Santosh Shilimkar

This patch will need below update so that the smp_scu.h header can be included from assembly files. Will you fold this into your patch or you want me to send below as separate patch ?

Folded.

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Tuesday, January 25, 2011 6:27 PM
To: Santosh Shilimkar
Cc: linux-arm-kernel at lists.infradead.org; catalin.marinas at arm.com; ccross at android.com; linus.ml.walleij at gmail.com; linux- omap at vger.kernel.org
Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header file

Quoted 9 lines · Santosh Shilimkar

Ok. I missed some information my last email.
The SCU power status programming is used to take CPU in/out of coherency as an alternative to SMP bit. We don't have an access to SMP bit on OMAP4. ARM has already confirmed SCU programming is same as SMP bit enable/disable.

I don't know how safe is to use spin lock when one CPU is goes out of coherency after programming the power state. The spin lock release may not even be visible to other CPU.

Erm, I do hope that's not the case, as that means it is unsafe for CPUs in
a SMP system to write to this register without them potentially trampling
over each other.

If it is the case, then the solutions are either:
1. Fix the hardware so that coherency requests only yet turned off when entering the WFI state.
2. Fix the hardware such that each CPU has a separate register.

I can't see a software solution to this as we can't use ldrex/strex anything
but memory regions, and memory regions without coherency won't work. Maybe ARM Support can help by suggesting how a 4-CPU system is supposed
to safely read/modify/write the SCU power control register...

Ok. I missed some information my last email.
The SCU power status programming is used to take CPU in/out of coherency as an alternative to SMP bit. We don't have an access to SMP bit on OMAP4. ARM has already confirmed SCU programming is same as SMP bit enable/disable.

I don't know how safe is to use spin lock when one CPU is goes out of coherency after programming the power state. The spin lock release may not even be visible to other CPU. The programming happens from IDLE or suspend where the

-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Tuesday, January 25, 2011 7:11 PM
To: Santosh Shilimkar
Cc: linux-arm-kernel at lists.infradead.org; catalin.marinas at arm.com; ccross at android.com; linus.ml.walleij at gmail.com; linux- omap at vger.kernel.org
Subject: Re: [PATCH 4/5] ARM: scu: Move register defines to header file

Quoted 6 lines · Santosh Shilimkar

Ok. I missed some information my last email.
The SCU power status programming is used to take CPU in/out of coherency as an alternative to SMP bit. We don't have an access to SMP bit on OMAP4. ARM has already confirmed SCU programming is same as SMP bit enable/disable.

Quoted 4 lines

I don't know how safe is to use spin lock when one CPU is goes out of coherency after programming the power state. The spin lock release may not even be visible to other CPU. The programming happens from IDLE or suspend where the

BTW, presumably we should be flushing the caches/tlbs before setting the CPU power register to a non-normal setting?

I'll wait until there's more information available (such as an example
implementation.)

On some architectures, secondary cores shares clock with primiary core and hence scale together. Hence secondary core lpj calibration is not necessary and can be skipped to save considerable time.

This can speed up the secondary cpu boot and hotplug cpu online paths.

-----Original Message-----
From: linux-omap-owner at vger.kernel.org [mailto:linux-omap- owner at vger.kernel.org] On Behalf Of Santosh Shilimkar
Sent: Monday, January 24, 2011 2:21 PM
To: linux-arm-kernel at lists.infradead.org
Cc: linux-omap at vger.kernel.org; ccross at android.com; catalin.marinas at arm.com; linux at arm.linux.org.uk; linus.ml.walleij at gmail.com
Subject: [PATCH 5/5] ARM: smp: Skip secondary cpu calibration to speed-up boot

(quoted diff) +1 -1

 	if (!skip_secondary_calibrate) {
 		for_each_online_cpu(cpu)
-			bogosum += per_cpu(cpu_data, cpu).loops_per_jiffy;
+			bogosums += per_cpu(cpu_data,

cpu).loops_per_jiffy;

(quoted diff) +0 -1

-		snprintf(bogosum, sizeof(bogosum), " (%lu.%02lu

BogoMIPS).\n",

(quoted diff) +0 -1

-			bogosum / (500000/HZ), (bogosum / (5000/HZ)) %

100);

(quoted diff) +1 -0

+		snprintf(bogosum, sizeof(bogosums), " (%lu.%02lu

BogoMIPS).\n",

(quoted diff) +1 -0

+			bogosums / (500000/HZ), (bogosums / (5000/HZ)) %

100);

-----Original Message-----
From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
Sent: Monday, January 24, 2011 2:21 PM
To: linux-arm-kernel at lists.infradead.org
Cc: linux-omap at vger.kernel.org; ccross at android.com; catalin.marinas at arm.com; linux at arm.linux.org.uk; linus.ml.walleij at gmail.com; Santosh Shilimkar
Subject: [PATCH 0/5] ARM: Few patches for PM enablement.

The series consist of few patches to address some common PM issues on Cortex-A9 based ARM SoCs. The skip calibration on secondary cores is still under discussion.
On OMAP, the GIC save restore is done differently and hence that part isn't included. Collin already have a patch for the same which should address other SOCs.

The following changes since commit
1bae4ce27c9c90344f23c65ea6966c50ffeae2f5:
Linus Torvalds (1):

        Linux 2.6.38-rc2

ARM: gic: Add hooks for architecture specific extensions

ARM: gic: Add distributor and interface enable/disable
accessory api

ARM: twd: Add context save restore support

ARM: scu: Move register defines to header file

ARM: smp: Skip secondary cpu calibration to speed-up boot

-----Original Message-----
From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
Sent: Friday, February 04, 2011 3:49 PM
To: Russell King - ARM Linux
Cc: linux-omap at vger.kernel.org; ccross at android.com; catalin.marinas at arm.com; linus.ml.walleij at gmail.com; linux-arm- kernel at lists.infradead.org
Subject: RE: [PATCH 0/5] ARM: Few patches for PM enablement.

ARM: gic: Add hooks for architecture specific extensions
ARM: gic: Add distributor and interface enable/disable accessory api

ARM: twd: Add context save restore support
ARM: scu: Move register defines to header file

ARM: smp: Skip secondary cpu calibration to speed-up boot