* [PATCH 1/9] ARM: OMAP4+: Use common scratchpad SAR RAM offsets for all architectures
2013-02-20 15:18 [PATCH 0/9] ARM: OMAP: Static deps, fiq, omap-smp cleanup Santosh Shilimkar
@ 2013-02-20 15:18 ` Santosh Shilimkar
2013-03-27 18:41 ` Kevin Hilman
2013-02-20 15:18 ` [PATCH 2/9] ARM: OMAP1: PM: Remove bogus fiq_[enable/disable] tuple Santosh Shilimkar
` (7 subsequent siblings)
8 siblings, 1 reply; 37+ messages in thread
From: Santosh Shilimkar @ 2013-02-20 15:18 UTC (permalink / raw)
To: linux-arm-kernel
From: Tero Kristo <t-kristo@ti.com>
Simplifies code and also allows the re-use as is on OMAP5 devices.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap4-sar-layout.h | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/omap4-sar-layout.h b/arch/arm/mach-omap2/omap4-sar-layout.h
index e170fe8..6822d0a 100644
--- a/arch/arm/mach-omap2/omap4-sar-layout.h
+++ b/arch/arm/mach-omap2/omap4-sar-layout.h
@@ -20,13 +20,13 @@
#define SAR_BANK4_OFFSET 0x3000
/* Scratch pad memory offsets from SAR_BANK1 */
-#define SCU_OFFSET0 0xd00
-#define SCU_OFFSET1 0xd04
-#define OMAP_TYPE_OFFSET 0xd10
-#define L2X0_SAVE_OFFSET0 0xd14
-#define L2X0_SAVE_OFFSET1 0xd18
-#define L2X0_AUXCTRL_OFFSET 0xd1c
-#define L2X0_PREFETCH_CTRL_OFFSET 0xd20
+#define SCU_OFFSET0 0xfe4
+#define SCU_OFFSET1 0xfe8
+#define OMAP_TYPE_OFFSET 0xfec
+#define L2X0_SAVE_OFFSET0 0xff0
+#define L2X0_SAVE_OFFSET1 0xff4
+#define L2X0_AUXCTRL_OFFSET 0xff8
+#define L2X0_PREFETCH_CTRL_OFFSET 0xffc
/* CPUx Wakeup Non-Secure Physical Address offsets in SAR_BANK3 */
#define CPU0_WAKEUP_NS_PA_ADDR_OFFSET 0xa04
--
1.7.9.5
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 1/9] ARM: OMAP4+: Use common scratchpad SAR RAM offsets for all architectures
2013-02-20 15:18 ` [PATCH 1/9] ARM: OMAP4+: Use common scratchpad SAR RAM offsets for all architectures Santosh Shilimkar
@ 2013-03-27 18:41 ` Kevin Hilman
2013-03-27 20:49 ` Santosh Shilimkar
0 siblings, 1 reply; 37+ messages in thread
From: Kevin Hilman @ 2013-03-27 18:41 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> From: Tero Kristo <t-kristo@ti.com>
>
> Simplifies code and also allows the re-use as is on OMAP5 devices.
nit: changelog here is rather weak. It claims "simplifies code" but
it's not obvious from the patch how changing a few #defines does that.
Kevin
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/omap4-sar-layout.h | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap4-sar-layout.h b/arch/arm/mach-omap2/omap4-sar-layout.h
> index e170fe8..6822d0a 100644
> --- a/arch/arm/mach-omap2/omap4-sar-layout.h
> +++ b/arch/arm/mach-omap2/omap4-sar-layout.h
> @@ -20,13 +20,13 @@
> #define SAR_BANK4_OFFSET 0x3000
>
> /* Scratch pad memory offsets from SAR_BANK1 */
> -#define SCU_OFFSET0 0xd00
> -#define SCU_OFFSET1 0xd04
> -#define OMAP_TYPE_OFFSET 0xd10
> -#define L2X0_SAVE_OFFSET0 0xd14
> -#define L2X0_SAVE_OFFSET1 0xd18
> -#define L2X0_AUXCTRL_OFFSET 0xd1c
> -#define L2X0_PREFETCH_CTRL_OFFSET 0xd20
> +#define SCU_OFFSET0 0xfe4
> +#define SCU_OFFSET1 0xfe8
> +#define OMAP_TYPE_OFFSET 0xfec
> +#define L2X0_SAVE_OFFSET0 0xff0
> +#define L2X0_SAVE_OFFSET1 0xff4
> +#define L2X0_AUXCTRL_OFFSET 0xff8
> +#define L2X0_PREFETCH_CTRL_OFFSET 0xffc
>
> /* CPUx Wakeup Non-Secure Physical Address offsets in SAR_BANK3 */
> #define CPU0_WAKEUP_NS_PA_ADDR_OFFSET 0xa04
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/9] ARM: OMAP4+: Use common scratchpad SAR RAM offsets for all architectures
2013-03-27 18:41 ` Kevin Hilman
@ 2013-03-27 20:49 ` Santosh Shilimkar
2013-03-27 20:49 ` Tony Lindgren
0 siblings, 1 reply; 37+ messages in thread
From: Santosh Shilimkar @ 2013-03-27 20:49 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 28 March 2013 12:11 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> From: Tero Kristo <t-kristo@ti.com>
>>
>> Simplifies code and also allows the re-use as is on OMAP5 devices.
>
> nit: changelog here is rather weak. It claims "simplifies code" but
> it's not obvious from the patch how changing a few #defines does that.
>
I agree. Basically the offset are chosen such a way that they can
work on OMAP4 and OMAP5 instead of having two separate sets.
Will expand the changelog to make it clear.
Regards,
Santosh
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/9] ARM: OMAP4+: Use common scratchpad SAR RAM offsets for all architectures
2013-03-27 20:49 ` Santosh Shilimkar
@ 2013-03-27 20:49 ` Tony Lindgren
2013-03-27 20:52 ` Santosh Shilimkar
0 siblings, 1 reply; 37+ messages in thread
From: Tony Lindgren @ 2013-03-27 20:49 UTC (permalink / raw)
To: linux-arm-kernel
* Santosh Shilimkar <santosh.shilimkar@ti.com> [130327 13:52]:
> On Thursday 28 March 2013 12:11 AM, Kevin Hilman wrote:
> > Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> >
> >> From: Tero Kristo <t-kristo@ti.com>
> >>
> >> Simplifies code and also allows the re-use as is on OMAP5 devices.
> >
> > nit: changelog here is rather weak. It claims "simplifies code" but
> > it's not obvious from the patch how changing a few #defines does that.
> >
> I agree. Basically the offset are chosen such a way that they can
> work on OMAP4 and OMAP5 instead of having two separate sets.
> Will expand the changelog to make it clear.
You might want to mention also that the offsets are only used by
the kernel to save and restore registers from so people don't
think those are hardare registers and that the patch might break
some things.
Regards,
Tony
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/9] ARM: OMAP4+: Use common scratchpad SAR RAM offsets for all architectures
2013-03-27 20:49 ` Tony Lindgren
@ 2013-03-27 20:52 ` Santosh Shilimkar
2013-03-28 7:32 ` Santosh Shilimkar
0 siblings, 1 reply; 37+ messages in thread
From: Santosh Shilimkar @ 2013-03-27 20:52 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 28 March 2013 02:19 AM, Tony Lindgren wrote:
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [130327 13:52]:
>> On Thursday 28 March 2013 12:11 AM, Kevin Hilman wrote:
>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>
>>>> From: Tero Kristo <t-kristo@ti.com>
>>>>
>>>> Simplifies code and also allows the re-use as is on OMAP5 devices.
>>>
>>> nit: changelog here is rather weak. It claims "simplifies code" but
>>> it's not obvious from the patch how changing a few #defines does that.
>>>
>> I agree. Basically the offset are chosen such a way that they can
>> work on OMAP4 and OMAP5 instead of having two separate sets.
>> Will expand the changelog to make it clear.
>
> You might want to mention also that the offsets are only used by
> the kernel to save and restore registers from so people don't
> think those are hardare registers and that the patch might break
> some things.
>
Yeah. Will mention that.
Regards,
Santosh
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/9] ARM: OMAP4+: Use common scratchpad SAR RAM offsets for all architectures
2013-03-27 20:52 ` Santosh Shilimkar
@ 2013-03-28 7:32 ` Santosh Shilimkar
0 siblings, 0 replies; 37+ messages in thread
From: Santosh Shilimkar @ 2013-03-28 7:32 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 28 March 2013 02:22 AM, Santosh Shilimkar wrote:
> On Thursday 28 March 2013 02:19 AM, Tony Lindgren wrote:
>> * Santosh Shilimkar <santosh.shilimkar@ti.com> [130327 13:52]:
>>> On Thursday 28 March 2013 12:11 AM, Kevin Hilman wrote:
>>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>>
>>>>> From: Tero Kristo <t-kristo@ti.com>
>>>>>
>>>>> Simplifies code and also allows the re-use as is on OMAP5 devices.
>>>>
>>>> nit: changelog here is rather weak. It claims "simplifies code" but
>>>> it's not obvious from the patch how changing a few #defines does that.
>>>>
>>> I agree. Basically the offset are chosen such a way that they can
>>> work on OMAP4 and OMAP5 instead of having two separate sets.
>>> Will expand the changelog to make it clear.
>>
>> You might want to mention also that the offsets are only used by
>> the kernel to save and restore registers from so people don't
>> think those are hardare registers and that the patch might break
>> some things.
>>
> Yeah. Will mention that.
>
For record, patch with updated changelog end of email.
Regards,
Santosh
>From f98d5fe8079cc4830e4ce22585055822119da5c8 Mon Sep 17 00:00:00 2001
From: Tero Kristo <t-kristo@ti.com>
Date: Wed, 6 Feb 2013 18:39:20 +0530
Subject: [PATCH v2 1/9] ARM: OMAP4+: Use common scratchpad SAR RAM offsets
for all architectures
Choose the common scratch pad offsets, so that same offsets can work for
OMAP4 and OMAP5 devices. It simplifies code and also allows the re-use as
is on OMAP5 devices. Note that these offsets are used by low power
code for various power state management. They are not hardware register
offsets.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap4-sar-layout.h | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/omap4-sar-layout.h b/arch/arm/mach-omap2/omap4-sar-layout.h
index e170fe8..6822d0a 100644
--- a/arch/arm/mach-omap2/omap4-sar-layout.h
+++ b/arch/arm/mach-omap2/omap4-sar-layout.h
@@ -20,13 +20,13 @@
#define SAR_BANK4_OFFSET 0x3000
/* Scratch pad memory offsets from SAR_BANK1 */
-#define SCU_OFFSET0 0xd00
-#define SCU_OFFSET1 0xd04
-#define OMAP_TYPE_OFFSET 0xd10
-#define L2X0_SAVE_OFFSET0 0xd14
-#define L2X0_SAVE_OFFSET1 0xd18
-#define L2X0_AUXCTRL_OFFSET 0xd1c
-#define L2X0_PREFETCH_CTRL_OFFSET 0xd20
+#define SCU_OFFSET0 0xfe4
+#define SCU_OFFSET1 0xfe8
+#define OMAP_TYPE_OFFSET 0xfec
+#define L2X0_SAVE_OFFSET0 0xff0
+#define L2X0_SAVE_OFFSET1 0xff4
+#define L2X0_AUXCTRL_OFFSET 0xff8
+#define L2X0_PREFETCH_CTRL_OFFSET 0xffc
/* CPUx Wakeup Non-Secure Physical Address offsets in SAR_BANK3 */
#define CPU0_WAKEUP_NS_PA_ADDR_OFFSET 0xa04
--
1.7.9.5
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH 2/9] ARM: OMAP1: PM: Remove bogus fiq_[enable/disable] tuple
2013-02-20 15:18 [PATCH 0/9] ARM: OMAP: Static deps, fiq, omap-smp cleanup Santosh Shilimkar
2013-02-20 15:18 ` [PATCH 1/9] ARM: OMAP4+: Use common scratchpad SAR RAM offsets for all architectures Santosh Shilimkar
@ 2013-02-20 15:18 ` Santosh Shilimkar
2013-02-20 16:09 ` Tony Lindgren
2013-02-20 15:18 ` [PATCH 3/9] ARM: OMAP2+: " Santosh Shilimkar
` (6 subsequent siblings)
8 siblings, 1 reply; 37+ messages in thread
From: Santosh Shilimkar @ 2013-02-20 15:18 UTC (permalink / raw)
To: linux-arm-kernel
On OMAP platform, FIQ is reserved for secure environment only. If at all
the FIQ needs to be disabled, it involves going through security
API call. Hence the local_fiq_[enable/disable]() in the OMAP code is bogus.
So just get rid of it.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap1/pm.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c
index 7a7690a..25aa9c4 100644
--- a/arch/arm/mach-omap1/pm.c
+++ b/arch/arm/mach-omap1/pm.c
@@ -111,8 +111,6 @@ void omap1_pm_idle(void)
__u32 use_idlect1 = arm_idlect1_mask;
int do_sleep = 0;
- local_fiq_disable();
-
#if defined(CONFIG_OMAP_MPU_TIMER) && !defined(CONFIG_OMAP_DM_TIMER)
#warning Enable 32kHz OS timer in order to allow sleep states in idle
use_idlect1 = use_idlect1 & ~(1 << 9);
@@ -158,8 +156,6 @@ void omap1_pm_idle(void)
}
omap_sram_suspend(omap_readl(ARM_IDLECT1),
omap_readl(ARM_IDLECT2));
-
- local_fiq_enable();
}
/*
@@ -235,7 +231,6 @@ void omap1_pm_suspend(void)
*/
local_irq_disable();
- local_fiq_disable();
/*
* Step 2: save registers
@@ -414,7 +409,6 @@ void omap1_pm_suspend(void)
*/
local_irq_enable();
- local_fiq_enable();
omap_serial_wake_trigger(0);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 2/9] ARM: OMAP1: PM: Remove bogus fiq_[enable/disable] tuple
2013-02-20 15:18 ` [PATCH 2/9] ARM: OMAP1: PM: Remove bogus fiq_[enable/disable] tuple Santosh Shilimkar
@ 2013-02-20 16:09 ` Tony Lindgren
2013-02-20 16:14 ` Santosh Shilimkar
0 siblings, 1 reply; 37+ messages in thread
From: Tony Lindgren @ 2013-02-20 16:09 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
* Santosh Shilimkar <santosh.shilimkar@ti.com> [130220 07:21]:
> On OMAP platform, FIQ is reserved for secure environment only. If at all
> the FIQ needs to be disabled, it involves going through security
> API call. Hence the local_fiq_[enable/disable]() in the OMAP code is bogus.
>
> So just get rid of it.
This is not true for all omaps, needs to be checked carefully
at what point it was made HS omap only. We have at least
mach-omap1//ams-delta-fiq.c that's being used.
Regards,
Tony
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 2/9] ARM: OMAP1: PM: Remove bogus fiq_[enable/disable] tuple
2013-02-20 16:09 ` Tony Lindgren
@ 2013-02-20 16:14 ` Santosh Shilimkar
0 siblings, 0 replies; 37+ messages in thread
From: Santosh Shilimkar @ 2013-02-20 16:14 UTC (permalink / raw)
To: linux-arm-kernel
On Wednesday 20 February 2013 09:39 PM, Tony Lindgren wrote:
> Hi,
>
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [130220 07:21]:
>> On OMAP platform, FIQ is reserved for secure environment only. If at all
>> the FIQ needs to be disabled, it involves going through security
>> API call. Hence the local_fiq_[enable/disable]() in the OMAP code is bogus.
>>
>> So just get rid of it.
>
> This is not true for all omaps, needs to be checked carefully
> at what point it was made HS omap only. We have at least
> mach-omap1//ams-delta-fiq.c that's being used.
>
This is true for all OMAP2 and onward devices. I assumed it was
the case for OMAP1 as well but that doesn't seems to be the
case. Sorry I didn't look at OMAP1 code carefully.
So this patch can be dropped then.
Regards
Santosh
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 3/9] ARM: OMAP2+: PM: Remove bogus fiq_[enable/disable] tuple
2013-02-20 15:18 [PATCH 0/9] ARM: OMAP: Static deps, fiq, omap-smp cleanup Santosh Shilimkar
2013-02-20 15:18 ` [PATCH 1/9] ARM: OMAP4+: Use common scratchpad SAR RAM offsets for all architectures Santosh Shilimkar
2013-02-20 15:18 ` [PATCH 2/9] ARM: OMAP1: PM: Remove bogus fiq_[enable/disable] tuple Santosh Shilimkar
@ 2013-02-20 15:18 ` Santosh Shilimkar
2013-03-27 18:36 ` Kevin Hilman
2013-02-20 15:18 ` [PATCH 4/9] ARM: OMAP4+: Remove the un-necessary cache flush from hotplug code Santosh Shilimkar
` (5 subsequent siblings)
8 siblings, 1 reply; 37+ messages in thread
From: Santosh Shilimkar @ 2013-02-20 15:18 UTC (permalink / raw)
To: linux-arm-kernel
On OMAP platform, FIQ is reserved for secure environment only. If at all
the FIQ needs to be disabled, it involves going through security
API call. Hence the local_fiq_[enable/disable]() in the OMAP code is bogus.
So just get rid of it.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/cpuidle34xx.c | 4 ----
arch/arm/mach-omap2/cpuidle44xx.c | 7 -------
arch/arm/mach-omap2/pm24xx.c | 11 +++--------
arch/arm/mach-omap2/pm34xx.c | 9 +--------
arch/arm/mach-omap2/pm44xx.c | 4 ----
5 files changed, 4 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index 22590db..f61b28c 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -82,8 +82,6 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
struct omap3_idle_statedata *cx = &omap3_idle_data[index];
u32 mpu_state = cx->mpu_state, core_state = cx->core_state;
- local_fiq_disable();
-
pwrdm_set_next_pwrst(mpu_pd, mpu_state);
pwrdm_set_next_pwrst(core_pd, core_state);
@@ -121,8 +119,6 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
return_sleep_time:
- local_fiq_enable();
-
return index;
}
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index d639aef..944e64a 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -70,10 +70,7 @@ static int omap4_enter_idle_simple(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- local_fiq_disable();
omap_do_wfi();
- local_fiq_enable();
-
return index;
}
@@ -84,8 +81,6 @@ static int omap4_enter_idle_coupled(struct cpuidle_device *dev,
struct omap4_idle_statedata *cx = &omap4_idle_data[index];
int cpu_id = smp_processor_id();
- local_fiq_disable();
-
/*
* CPU0 has to wait and stay ON until CPU1 is OFF state.
* This is necessary to honour hardware recommondation
@@ -158,8 +153,6 @@ fail:
cpuidle_coupled_parallel_barrier(dev, &abort_barrier);
cpu_done[dev->cpu] = false;
- local_fiq_enable();
-
return index;
}
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index c333fa6..af29c31 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -213,22 +213,17 @@ static int omap2_can_sleep(void)
static void omap2_pm_idle(void)
{
- local_fiq_disable();
-
if (!omap2_can_sleep()) {
if (omap_irq_pending())
- goto out;
+ return;
omap2_enter_mpu_retention();
- goto out;
+ return;
}
if (omap_irq_pending())
- goto out;
+ return;
omap2_enter_full_retention();
-
-out:
- local_fiq_enable();
}
static void __init prcm_setup_regs(void)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 7be3622..2f7e58e 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -346,10 +346,8 @@ void omap_sram_idle(void)
static void omap3_pm_idle(void)
{
- local_fiq_disable();
-
if (omap_irq_pending())
- goto out;
+ return;
trace_power_start(POWER_CSTATE, 1, smp_processor_id());
trace_cpu_idle(1, smp_processor_id());
@@ -358,9 +356,6 @@ static void omap3_pm_idle(void)
trace_power_end(smp_processor_id());
trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
-
-out:
- local_fiq_enable();
}
#ifdef CONFIG_SUSPEND
@@ -759,14 +754,12 @@ int __init omap3_pm_init(void)
pr_err("Memory allocation failed when allocating for secure sram context\n");
local_irq_disable();
- local_fiq_disable();
omap_dma_global_context_save();
omap3_save_secure_ram_context();
omap_dma_global_context_restore();
local_irq_enable();
- local_fiq_enable();
}
omap3_save_scratchpad_contents();
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index aa6fd98..a96ae57 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -121,11 +121,7 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
*/
static void omap_default_idle(void)
{
- local_fiq_disable();
-
omap_do_wfi();
-
- local_fiq_enable();
}
/**
--
1.7.9.5
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 3/9] ARM: OMAP2+: PM: Remove bogus fiq_[enable/disable] tuple
2013-02-20 15:18 ` [PATCH 3/9] ARM: OMAP2+: " Santosh Shilimkar
@ 2013-03-27 18:36 ` Kevin Hilman
2013-03-27 19:02 ` Santosh Shilimkar
0 siblings, 1 reply; 37+ messages in thread
From: Kevin Hilman @ 2013-03-27 18:36 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> On OMAP platform, FIQ is reserved for secure environment only. If at all
> the FIQ needs to be disabled, it involves going through security
> API call. Hence the local_fiq_[enable/disable]() in the OMAP code is bogus.
>
> So just get rid of it.
What about GP devices?
Kevin
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/cpuidle34xx.c | 4 ----
> arch/arm/mach-omap2/cpuidle44xx.c | 7 -------
> arch/arm/mach-omap2/pm24xx.c | 11 +++--------
> arch/arm/mach-omap2/pm34xx.c | 9 +--------
> arch/arm/mach-omap2/pm44xx.c | 4 ----
> 5 files changed, 4 insertions(+), 31 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
> index 22590db..f61b28c 100644
> --- a/arch/arm/mach-omap2/cpuidle34xx.c
> +++ b/arch/arm/mach-omap2/cpuidle34xx.c
> @@ -82,8 +82,6 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
> struct omap3_idle_statedata *cx = &omap3_idle_data[index];
> u32 mpu_state = cx->mpu_state, core_state = cx->core_state;
>
> - local_fiq_disable();
> -
> pwrdm_set_next_pwrst(mpu_pd, mpu_state);
> pwrdm_set_next_pwrst(core_pd, core_state);
>
> @@ -121,8 +119,6 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
>
> return_sleep_time:
>
> - local_fiq_enable();
> -
> return index;
> }
>
> diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
> index d639aef..944e64a 100644
> --- a/arch/arm/mach-omap2/cpuidle44xx.c
> +++ b/arch/arm/mach-omap2/cpuidle44xx.c
> @@ -70,10 +70,7 @@ static int omap4_enter_idle_simple(struct cpuidle_device *dev,
> struct cpuidle_driver *drv,
> int index)
> {
> - local_fiq_disable();
> omap_do_wfi();
> - local_fiq_enable();
> -
> return index;
> }
>
> @@ -84,8 +81,6 @@ static int omap4_enter_idle_coupled(struct cpuidle_device *dev,
> struct omap4_idle_statedata *cx = &omap4_idle_data[index];
> int cpu_id = smp_processor_id();
>
> - local_fiq_disable();
> -
> /*
> * CPU0 has to wait and stay ON until CPU1 is OFF state.
> * This is necessary to honour hardware recommondation
> @@ -158,8 +153,6 @@ fail:
> cpuidle_coupled_parallel_barrier(dev, &abort_barrier);
> cpu_done[dev->cpu] = false;
>
> - local_fiq_enable();
> -
> return index;
> }
>
> diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
> index c333fa6..af29c31 100644
> --- a/arch/arm/mach-omap2/pm24xx.c
> +++ b/arch/arm/mach-omap2/pm24xx.c
> @@ -213,22 +213,17 @@ static int omap2_can_sleep(void)
>
> static void omap2_pm_idle(void)
> {
> - local_fiq_disable();
> -
> if (!omap2_can_sleep()) {
> if (omap_irq_pending())
> - goto out;
> + return;
> omap2_enter_mpu_retention();
> - goto out;
> + return;
> }
>
> if (omap_irq_pending())
> - goto out;
> + return;
>
> omap2_enter_full_retention();
> -
> -out:
> - local_fiq_enable();
> }
>
> static void __init prcm_setup_regs(void)
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> index 7be3622..2f7e58e 100644
> --- a/arch/arm/mach-omap2/pm34xx.c
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -346,10 +346,8 @@ void omap_sram_idle(void)
>
> static void omap3_pm_idle(void)
> {
> - local_fiq_disable();
> -
> if (omap_irq_pending())
> - goto out;
> + return;
>
> trace_power_start(POWER_CSTATE, 1, smp_processor_id());
> trace_cpu_idle(1, smp_processor_id());
> @@ -358,9 +356,6 @@ static void omap3_pm_idle(void)
>
> trace_power_end(smp_processor_id());
> trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
> -
> -out:
> - local_fiq_enable();
> }
>
> #ifdef CONFIG_SUSPEND
> @@ -759,14 +754,12 @@ int __init omap3_pm_init(void)
> pr_err("Memory allocation failed when allocating for secure sram context\n");
>
> local_irq_disable();
> - local_fiq_disable();
>
> omap_dma_global_context_save();
> omap3_save_secure_ram_context();
> omap_dma_global_context_restore();
>
> local_irq_enable();
> - local_fiq_enable();
> }
>
> omap3_save_scratchpad_contents();
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> index aa6fd98..a96ae57 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm44xx.c
> @@ -121,11 +121,7 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
> */
> static void omap_default_idle(void)
> {
> - local_fiq_disable();
> -
> omap_do_wfi();
> -
> - local_fiq_enable();
> }
>
> /**
^ permalink raw reply [flat|nested] 37+ messages in thread* [PATCH 3/9] ARM: OMAP2+: PM: Remove bogus fiq_[enable/disable] tuple
2013-03-27 18:36 ` Kevin Hilman
@ 2013-03-27 19:02 ` Santosh Shilimkar
2013-03-28 7:37 ` Santosh Shilimkar
0 siblings, 1 reply; 37+ messages in thread
From: Santosh Shilimkar @ 2013-03-27 19:02 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 28 March 2013 12:06 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> On OMAP platform, FIQ is reserved for secure environment only. If at all
>> the FIQ needs to be disabled, it involves going through security
>> API call. Hence the local_fiq_[enable/disable]() in the OMAP code is bogus.
>>
>> So just get rid of it.
>
> What about GP devices?
>
On GP devices as well FIQ isn't available for non-secure software since
its marked secure only in ROM initialization. There has been heavy
debate on this since some customers wanted to have it available
for debug purpose but some other work-around was done rather
than opening it for public.
Regards,
Santosh
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 3/9] ARM: OMAP2+: PM: Remove bogus fiq_[enable/disable] tuple
2013-03-27 19:02 ` Santosh Shilimkar
@ 2013-03-28 7:37 ` Santosh Shilimkar
0 siblings, 0 replies; 37+ messages in thread
From: Santosh Shilimkar @ 2013-03-28 7:37 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 28 March 2013 12:32 AM, Santosh Shilimkar wrote:
> On Thursday 28 March 2013 12:06 AM, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> On OMAP platform, FIQ is reserved for secure environment only. If at all
>>> the FIQ needs to be disabled, it involves going through security
>>> API call. Hence the local_fiq_[enable/disable]() in the OMAP code is bogus.
>>>
>>> So just get rid of it.
>>
>> What about GP devices?
>>
> On GP devices as well FIQ isn't available for non-secure software since
> its marked secure only in ROM initialization. There has been heavy
> debate on this since some customers wanted to have it available
> for debug purpose but some other work-around was done rather
> than opening it for public.
>
For record, patch with updated changelog for GP device is end of
the email.
Regards,
Santosh
>From 6b85638b83caac7bae9ffa202391882a9ad4388f Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Mon, 11 Feb 2013 19:29:45 +0530
Subject: [PATCH v2 3/9] ARM: OMAP2+: PM: Remove bogus fiq_[enable/disable]
tuple
On OMAP platform, FIQ is reserved for secure environment only. If at all
the FIQ needs to be disabled, it involves going through security
API call. Hence the local_fiq_[enable/disable]() in the OMAP code is bogus.
On GP devices too, the fiq is disabled for non-secure software.
So just get rid of it.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/cpuidle34xx.c | 3 ---
arch/arm/mach-omap2/cpuidle44xx.c | 7 -------
arch/arm/mach-omap2/pm24xx.c | 11 +++--------
arch/arm/mach-omap2/pm34xx.c | 9 +--------
arch/arm/mach-omap2/pm44xx.c | 4 ----
5 files changed, 4 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c b/arch/arm/mach-omap2/cpuidle34xx.c
index 80392fc..06f567f 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -107,8 +107,6 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
{
struct omap3_idle_statedata *cx = &omap3_idle_data[index];
- local_fiq_disable();
-
if (omap_irq_pending() || need_resched())
goto return_sleep_time;
@@ -143,7 +141,6 @@ static int __omap3_enter_idle(struct cpuidle_device *dev,
clkdm_allow_idle(mpu_pd->pwrdm_clkdms[0]);
return_sleep_time:
- local_fiq_enable();
return index;
}
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c b/arch/arm/mach-omap2/cpuidle44xx.c
index d639aef..944e64a 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -70,10 +70,7 @@ static int omap4_enter_idle_simple(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index)
{
- local_fiq_disable();
omap_do_wfi();
- local_fiq_enable();
-
return index;
}
@@ -84,8 +81,6 @@ static int omap4_enter_idle_coupled(struct cpuidle_device *dev,
struct omap4_idle_statedata *cx = &omap4_idle_data[index];
int cpu_id = smp_processor_id();
- local_fiq_disable();
-
/*
* CPU0 has to wait and stay ON until CPU1 is OFF state.
* This is necessary to honour hardware recommondation
@@ -158,8 +153,6 @@ fail:
cpuidle_coupled_parallel_barrier(dev, &abort_barrier);
cpu_done[dev->cpu] = false;
- local_fiq_enable();
-
return index;
}
diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
index b59d939..ce956b0 100644
--- a/arch/arm/mach-omap2/pm24xx.c
+++ b/arch/arm/mach-omap2/pm24xx.c
@@ -200,22 +200,17 @@ static int omap2_can_sleep(void)
static void omap2_pm_idle(void)
{
- local_fiq_disable();
-
if (!omap2_can_sleep()) {
if (omap_irq_pending())
- goto out;
+ return;
omap2_enter_mpu_retention();
- goto out;
+ return;
}
if (omap_irq_pending())
- goto out;
+ return;
omap2_enter_full_retention();
-
-out:
- local_fiq_enable();
}
static void __init prcm_setup_regs(void)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 2d93d8b..c018593 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -346,19 +346,14 @@ void omap_sram_idle(void)
static void omap3_pm_idle(void)
{
- local_fiq_disable();
-
if (omap_irq_pending())
- goto out;
+ return;
trace_cpu_idle(1, smp_processor_id());
omap_sram_idle();
trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id());
-
-out:
- local_fiq_enable();
}
#ifdef CONFIG_SUSPEND
@@ -757,14 +752,12 @@ int __init omap3_pm_init(void)
pr_err("Memory allocation failed when allocating for secure sram context\n");
local_irq_disable();
- local_fiq_disable();
omap_dma_global_context_save();
omap3_save_secure_ram_context();
omap_dma_global_context_restore();
local_irq_enable();
- local_fiq_enable();
}
omap3_save_scratchpad_contents();
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index ea62e75..9e9095c 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -131,11 +131,7 @@ static int __init pwrdms_setup(struct powerdomain *pwrdm, void *unused)
*/
static void omap_default_idle(void)
{
- local_fiq_disable();
-
omap_do_wfi();
-
- local_fiq_enable();
}
/**
--
1.7.9.5
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH 4/9] ARM: OMAP4+: Remove the un-necessary cache flush from hotplug code
2013-02-20 15:18 [PATCH 0/9] ARM: OMAP: Static deps, fiq, omap-smp cleanup Santosh Shilimkar
` (2 preceding siblings ...)
2013-02-20 15:18 ` [PATCH 3/9] ARM: OMAP2+: " Santosh Shilimkar
@ 2013-02-20 15:18 ` Santosh Shilimkar
2013-03-27 18:43 ` Kevin Hilman
2013-02-20 15:18 ` [PATCH 5/9] ARM: OMAP4+: Remove un-necessary cacheflush in secondary CPU boot path Santosh Shilimkar
` (4 subsequent siblings)
8 siblings, 1 reply; 37+ messages in thread
From: Santosh Shilimkar @ 2013-02-20 15:18 UTC (permalink / raw)
To: linux-arm-kernel
This was added with intial port where OMAP PM support wasn't existing
and only simple WFI based hooks were used.
This should have been cleaned up while adding the PM support but some
how fall through cracks.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap-hotplug.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-hotplug.c b/arch/arm/mach-omap2/omap-hotplug.c
index e712d17..458f72f 100644
--- a/arch/arm/mach-omap2/omap-hotplug.c
+++ b/arch/arm/mach-omap2/omap-hotplug.c
@@ -19,11 +19,8 @@
#include <linux/smp.h>
#include <linux/io.h>
-#include <asm/cacheflush.h>
#include "omap-wakeupgen.h"
-
#include "common.h"
-
#include "powerdomain.h"
/*
@@ -35,9 +32,6 @@ void __ref omap4_cpu_die(unsigned int cpu)
unsigned int boot_cpu = 0;
void __iomem *base = omap_get_wakeupgen_base();
- flush_cache_all();
- dsb();
-
/*
* we're ready for shutdown now, so do it
*/
--
1.7.9.5
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 4/9] ARM: OMAP4+: Remove the un-necessary cache flush from hotplug code
2013-02-20 15:18 ` [PATCH 4/9] ARM: OMAP4+: Remove the un-necessary cache flush from hotplug code Santosh Shilimkar
@ 2013-03-27 18:43 ` Kevin Hilman
2013-03-27 20:47 ` Santosh Shilimkar
0 siblings, 1 reply; 37+ messages in thread
From: Kevin Hilman @ 2013-03-27 18:43 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> This was added with intial port where OMAP PM support wasn't existing
> and only simple WFI based hooks were used.
>
> This should have been cleaned up while adding the PM support but some
> how fall through cracks.
Changelog describes a bit of history, but does not it's no longer
needed.
Kevin
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/omap-hotplug.c | 6 ------
> 1 file changed, 6 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap-hotplug.c b/arch/arm/mach-omap2/omap-hotplug.c
> index e712d17..458f72f 100644
> --- a/arch/arm/mach-omap2/omap-hotplug.c
> +++ b/arch/arm/mach-omap2/omap-hotplug.c
> @@ -19,11 +19,8 @@
> #include <linux/smp.h>
> #include <linux/io.h>
>
> -#include <asm/cacheflush.h>
> #include "omap-wakeupgen.h"
> -
> #include "common.h"
> -
> #include "powerdomain.h"
>
> /*
> @@ -35,9 +32,6 @@ void __ref omap4_cpu_die(unsigned int cpu)
> unsigned int boot_cpu = 0;
> void __iomem *base = omap_get_wakeupgen_base();
>
> - flush_cache_all();
> - dsb();
> -
> /*
> * we're ready for shutdown now, so do it
> */
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 4/9] ARM: OMAP4+: Remove the un-necessary cache flush from hotplug code
2013-03-27 18:43 ` Kevin Hilman
@ 2013-03-27 20:47 ` Santosh Shilimkar
2013-03-28 7:29 ` Santosh Shilimkar
0 siblings, 1 reply; 37+ messages in thread
From: Santosh Shilimkar @ 2013-03-27 20:47 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 28 March 2013 12:13 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> This was added with intial port where OMAP PM support wasn't existing
>> and only simple WFI based hooks were used.
>>
>> This should have been cleaned up while adding the PM support but some
>> how fall through cracks.
>
> Changelog describes a bit of history, but does not it's no longer
> needed.
>
I thought "This should have been cleaned up while adding PM support"
means its no longer needed. At least I meant that way.
Anyway I will just make it explicit.
Regards,
Santosh
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 4/9] ARM: OMAP4+: Remove the un-necessary cache flush from hotplug code
2013-03-27 20:47 ` Santosh Shilimkar
@ 2013-03-28 7:29 ` Santosh Shilimkar
0 siblings, 0 replies; 37+ messages in thread
From: Santosh Shilimkar @ 2013-03-28 7:29 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 28 March 2013 02:17 AM, Santosh Shilimkar wrote:
> On Thursday 28 March 2013 12:13 AM, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> This was added with intial port where OMAP PM support wasn't existing
>>> and only simple WFI based hooks were used.
>>>
>>> This should have been cleaned up while adding the PM support but some
>>> how fall through cracks.
>>
>> Changelog describes a bit of history, but does not it's no longer
>> needed.
>>
> I thought "This should have been cleaned up while adding PM support"
> means its no longer needed. At least I meant that way.
>
> Anyway I will just make it explicit.
>
For record, patch with updated changelog end of email.
Regards,
Santosh
>From 4df9c29bf6eec23e99e83c9e1531603af69b4b42 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Sun, 10 Feb 2013 13:14:17 +0530
Subject: [PATCH v2 4/9] ARM: OMAP4+: Remove the un-necessary cache flush from
hotplug code
This was added with intial port where OMAP PM support wasn't existing
and only simple WFI based hooks were used.
This should have been cleaned up while adding the PM support but some
how fall through cracks.
So remove the cache flush code which is no longer needed now.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap-hotplug.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-hotplug.c b/arch/arm/mach-omap2/omap-hotplug.c
index e712d17..458f72f 100644
--- a/arch/arm/mach-omap2/omap-hotplug.c
+++ b/arch/arm/mach-omap2/omap-hotplug.c
@@ -19,11 +19,8 @@
#include <linux/smp.h>
#include <linux/io.h>
-#include <asm/cacheflush.h>
#include "omap-wakeupgen.h"
-
#include "common.h"
-
#include "powerdomain.h"
/*
@@ -35,9 +32,6 @@ void __ref omap4_cpu_die(unsigned int cpu)
unsigned int boot_cpu = 0;
void __iomem *base = omap_get_wakeupgen_base();
- flush_cache_all();
- dsb();
-
/*
* we're ready for shutdown now, so do it
*/
--
1.7.9.5
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH 5/9] ARM: OMAP4+: Remove un-necessary cacheflush in secondary CPU boot path
2013-02-20 15:18 [PATCH 0/9] ARM: OMAP: Static deps, fiq, omap-smp cleanup Santosh Shilimkar
` (3 preceding siblings ...)
2013-02-20 15:18 ` [PATCH 4/9] ARM: OMAP4+: Remove the un-necessary cache flush from hotplug code Santosh Shilimkar
@ 2013-02-20 15:18 ` Santosh Shilimkar
2013-02-20 15:18 ` [PATCH 6/9] ARM: OMAP4+: Remove out of placed smp_wmb() in secondary wakeup code Santosh Shilimkar
` (3 subsequent siblings)
8 siblings, 0 replies; 37+ messages in thread
From: Santosh Shilimkar @ 2013-02-20 15:18 UTC (permalink / raw)
To: linux-arm-kernel
This was borrowed from ARM versatile code with pen_release mechanism but since
OMAP uses hardware register based synchronisation, pen_release stuff was
dropped. Unfortunately the cacheflush wasn't dropped along with it.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap-smp.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index cd42d92..81fd489 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -20,7 +20,6 @@
#include <linux/smp.h>
#include <linux/io.h>
-#include <asm/cacheflush.h>
#include <asm/hardware/gic.h>
#include <asm/smp_scu.h>
@@ -103,9 +102,6 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
else
__raw_writel(0x20, base + OMAP_AUX_CORE_BOOT_0);
- flush_cache_all();
- smp_wmb();
-
if (!cpu1_clkdm)
cpu1_clkdm = clkdm_lookup("mpu1_clkdm");
--
1.7.9.5
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 6/9] ARM: OMAP4+: Remove out of placed smp_wmb() in secondary wakeup code
2013-02-20 15:18 [PATCH 0/9] ARM: OMAP: Static deps, fiq, omap-smp cleanup Santosh Shilimkar
` (4 preceding siblings ...)
2013-02-20 15:18 ` [PATCH 5/9] ARM: OMAP4+: Remove un-necessary cacheflush in secondary CPU boot path Santosh Shilimkar
@ 2013-02-20 15:18 ` Santosh Shilimkar
2013-02-21 12:55 ` Sergei Shtylyov
2013-02-20 15:18 ` [PATCH 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus() Santosh Shilimkar
` (2 subsequent siblings)
8 siblings, 1 reply; 37+ messages in thread
From: Santosh Shilimkar @ 2013-02-20 15:18 UTC (permalink / raw)
To: linux-arm-kernel
The smp_wmb() here is out of placed and redundant. So remove it. It is
a left over of the pain_release cleanup mostly.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap-smp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 81fd489..7d29a74 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -186,8 +186,6 @@ static void __init wakeup_secondary(void)
__raw_writel(virt_to_phys(omap5_secondary_startup),
base + OMAP_AUX_CORE_BOOT_1);
- smp_wmb();
-
/*
* Send a 'sev' to wake the secondary core from WFE.
* Drain the outstanding writes to memory
--
1.7.9.5
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus()
2013-02-20 15:18 [PATCH 0/9] ARM: OMAP: Static deps, fiq, omap-smp cleanup Santosh Shilimkar
` (5 preceding siblings ...)
2013-02-20 15:18 ` [PATCH 6/9] ARM: OMAP4+: Remove out of placed smp_wmb() in secondary wakeup code Santosh Shilimkar
@ 2013-02-20 15:18 ` Santosh Shilimkar
2013-03-27 18:45 ` Kevin Hilman
2013-02-20 15:18 ` [PATCH 8/9] ARM: OMAP4: PM: Remove L4 wakeup depedency with MPU since errata fix exist now Santosh Shilimkar
2013-02-20 15:18 ` [PATCH 9/9] ARM: OMAP4: PM: Now remove L4 per clockdomain static depedency with MPU Santosh Shilimkar
8 siblings, 1 reply; 37+ messages in thread
From: Santosh Shilimkar @ 2013-02-20 15:18 UTC (permalink / raw)
To: linux-arm-kernel
Move the secondary CPU wakeup prepare code under smp_prepare_cpus(). While at
it drop the un-necessary sev() and barrier which was under prepare code.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap-smp.c | 51 ++++++++++++++++------------------------
1 file changed, 20 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 7d29a74..9711ecd 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -164,36 +164,6 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
return 0;
}
-static void __init wakeup_secondary(void)
-{
- void *startup_addr = omap_secondary_startup;
- void __iomem *base = omap_get_wakeupgen_base();
-
- if (cpu_is_omap446x()) {
- startup_addr = omap_secondary_startup_4460;
- pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
- }
-
- /*
- * Write the address of secondary startup routine into the
- * AuxCoreBoot1 where ROM code will jump and start executing
- * on secondary core once out of WFE
- * A barrier is added to ensure that write buffer is drained
- */
- if (omap_secure_apis_support())
- omap_auxcoreboot_addr(virt_to_phys(startup_addr));
- else
- __raw_writel(virt_to_phys(omap5_secondary_startup),
- base + OMAP_AUX_CORE_BOOT_1);
-
- /*
- * Send a 'sev' to wake the secondary core from WFE.
- * Drain the outstanding writes to memory
- */
- dsb_sev();
- mb();
-}
-
/*
* Initialise the CPU possible map early - this describes the CPUs
* which may be present or become present in the system.
@@ -231,6 +201,8 @@ static void __init omap4_smp_init_cpus(void)
static void __init omap4_smp_prepare_cpus(unsigned int max_cpus)
{
+ void *startup_addr = omap_secondary_startup;
+ void __iomem *base = omap_get_wakeupgen_base();
/*
* Initialise the SCU and wake up the secondary core using
@@ -238,7 +210,24 @@ static void __init omap4_smp_prepare_cpus(unsigned int max_cpus)
*/
if (scu_base)
scu_enable(scu_base);
- wakeup_secondary();
+
+ if (cpu_is_omap446x()) {
+ startup_addr = omap_secondary_startup_4460;
+ pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
+ }
+
+ /*
+ * Write the address of secondary startup routine into the
+ * AuxCoreBoot1 where ROM code will jump and start executing
+ * on secondary core once out of WFE
+ * A barrier is added to ensure that write buffer is drained
+ */
+ if (omap_secure_apis_support())
+ omap_auxcoreboot_addr(virt_to_phys(startup_addr));
+ else
+ __raw_writel(virt_to_phys(omap5_secondary_startup),
+ base + OMAP_AUX_CORE_BOOT_1);
+
}
struct smp_operations omap4_smp_ops __initdata = {
--
1.7.9.5
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus()
2013-02-20 15:18 ` [PATCH 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus() Santosh Shilimkar
@ 2013-03-27 18:45 ` Kevin Hilman
2013-03-27 19:04 ` Santosh Shilimkar
0 siblings, 1 reply; 37+ messages in thread
From: Kevin Hilman @ 2013-03-27 18:45 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> Move the secondary CPU wakeup prepare code under smp_prepare_cpus().
Why?
> While at
> it drop the un-necessary sev() and barrier which was under prepare code.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> ---
> arch/arm/mach-omap2/omap-smp.c | 51 ++++++++++++++++------------------------
> 1 file changed, 20 insertions(+), 31 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
> index 7d29a74..9711ecd 100644
> --- a/arch/arm/mach-omap2/omap-smp.c
> +++ b/arch/arm/mach-omap2/omap-smp.c
> @@ -164,36 +164,6 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
> return 0;
> }
>
> -static void __init wakeup_secondary(void)
> -{
> - void *startup_addr = omap_secondary_startup;
> - void __iomem *base = omap_get_wakeupgen_base();
> -
> - if (cpu_is_omap446x()) {
> - startup_addr = omap_secondary_startup_4460;
> - pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
> - }
> -
> - /*
> - * Write the address of secondary startup routine into the
> - * AuxCoreBoot1 where ROM code will jump and start executing
> - * on secondary core once out of WFE
> - * A barrier is added to ensure that write buffer is drained
> - */
> - if (omap_secure_apis_support())
> - omap_auxcoreboot_addr(virt_to_phys(startup_addr));
> - else
> - __raw_writel(virt_to_phys(omap5_secondary_startup),
> - base + OMAP_AUX_CORE_BOOT_1);
> -
> - /*
> - * Send a 'sev' to wake the secondary core from WFE.
> - * Drain the outstanding writes to memory
> - */
> - dsb_sev();
> - mb();
> -}
> -
> /*
> * Initialise the CPU possible map early - this describes the CPUs
> * which may be present or become present in the system.
> @@ -231,6 +201,8 @@ static void __init omap4_smp_init_cpus(void)
>
> static void __init omap4_smp_prepare_cpus(unsigned int max_cpus)
> {
> + void *startup_addr = omap_secondary_startup;
> + void __iomem *base = omap_get_wakeupgen_base();
>
> /*
> * Initialise the SCU and wake up the secondary core using
> @@ -238,7 +210,24 @@ static void __init omap4_smp_prepare_cpus(unsigned int max_cpus)
> */
> if (scu_base)
> scu_enable(scu_base);
> - wakeup_secondary();
> +
> + if (cpu_is_omap446x()) {
> + startup_addr = omap_secondary_startup_4460;
> + pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
> + }
> +
> + /*
> + * Write the address of secondary startup routine into the
> + * AuxCoreBoot1 where ROM code will jump and start executing
> + * on secondary core once out of WFE
> + * A barrier is added to ensure that write buffer is drained
> + */
> + if (omap_secure_apis_support())
> + omap_auxcoreboot_addr(virt_to_phys(startup_addr));
> + else
> + __raw_writel(virt_to_phys(omap5_secondary_startup),
> + base + OMAP_AUX_CORE_BOOT_1);
> +
> }
>
> struct smp_operations omap4_smp_ops __initdata = {
^ permalink raw reply [flat|nested] 37+ messages in thread* [PATCH 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus()
2013-03-27 18:45 ` Kevin Hilman
@ 2013-03-27 19:04 ` Santosh Shilimkar
2013-03-27 19:54 ` Kevin Hilman
2013-03-28 9:46 ` Russell King - ARM Linux
0 siblings, 2 replies; 37+ messages in thread
From: Santosh Shilimkar @ 2013-03-27 19:04 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> Move the secondary CPU wakeup prepare code under smp_prepare_cpus().
>
> Why?
>
Because that code belongs to smp_prepare_cpus(). As I said
in earlier patches, it was remainder of the pen release code
which was borrowed from ARM code initially.
Regards,
Santosh
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus()
2013-03-27 19:04 ` Santosh Shilimkar
@ 2013-03-27 19:54 ` Kevin Hilman
2013-03-27 20:50 ` Santosh Shilimkar
2013-03-28 9:46 ` Russell King - ARM Linux
1 sibling, 1 reply; 37+ messages in thread
From: Kevin Hilman @ 2013-03-27 19:54 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> Move the secondary CPU wakeup prepare code under smp_prepare_cpus().
>>
>> Why?
>>
> Because that code belongs to smp_prepare_cpus(). As I said
> in earlier patches, it was remainder of the pen release code
> which was borrowed from ARM code initially.
Sure, but that should be in the changelog.
Kevin
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus()
2013-03-27 19:54 ` Kevin Hilman
@ 2013-03-27 20:50 ` Santosh Shilimkar
2013-03-28 7:35 ` Santosh Shilimkar
0 siblings, 1 reply; 37+ messages in thread
From: Santosh Shilimkar @ 2013-03-27 20:50 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 28 March 2013 01:24 AM, Kevin Hilman wrote:
> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>
>> On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>
>>>> Move the secondary CPU wakeup prepare code under smp_prepare_cpus().
>>>
>>> Why?
>>>
>> Because that code belongs to smp_prepare_cpus(). As I said
>> in earlier patches, it was remainder of the pen release code
>> which was borrowed from ARM code initially.
>
> Sure, but that should be in the changelog.
>
Yep. Will add above info in changelog.
Regards,
Santosh
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus()
2013-03-27 20:50 ` Santosh Shilimkar
@ 2013-03-28 7:35 ` Santosh Shilimkar
0 siblings, 0 replies; 37+ messages in thread
From: Santosh Shilimkar @ 2013-03-28 7:35 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 28 March 2013 02:20 AM, Santosh Shilimkar wrote:
> On Thursday 28 March 2013 01:24 AM, Kevin Hilman wrote:
>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>
>>> On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
>>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>>
>>>>> Move the secondary CPU wakeup prepare code under smp_prepare_cpus().
>>>>
>>>> Why?
>>>>
>>> Because that code belongs to smp_prepare_cpus(). As I said
>>> in earlier patches, it was remainder of the pen release code
>>> which was borrowed from ARM code initially.
>>
>> Sure, but that should be in the changelog.
>>
> Yep. Will add above info in changelog.
>
For record, patch with updated changelog end of email.
Regards,
Santosh
>From b699ddd19bf3542d43ffe293c6148161e160b1bc Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Sun, 10 Feb 2013 13:54:00 +0530
Subject: [PATCH v2 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under
smp_prepare_cpus()
Move the secondary CPU wakeup prepare code under smp_prepare_cpus() where it
belongs. It was remainder of the pen release code which was borrowed from
ARM code initially.
While at it drop the un-necessary sev() and barrier which was under
prepare code.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/omap-smp.c | 51 ++++++++++++++++------------------------
1 file changed, 20 insertions(+), 31 deletions(-)
diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c
index 1e14899..0cbb677 100644
--- a/arch/arm/mach-omap2/omap-smp.c
+++ b/arch/arm/mach-omap2/omap-smp.c
@@ -164,36 +164,6 @@ static int __cpuinit omap4_boot_secondary(unsigned int cpu, struct task_struct *
return 0;
}
-static void __init wakeup_secondary(void)
-{
- void *startup_addr = omap_secondary_startup;
- void __iomem *base = omap_get_wakeupgen_base();
-
- if (cpu_is_omap446x()) {
- startup_addr = omap_secondary_startup_4460;
- pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
- }
-
- /*
- * Write the address of secondary startup routine into the
- * AuxCoreBoot1 where ROM code will jump and start executing
- * on secondary core once out of WFE
- * A barrier is added to ensure that write buffer is drained
- */
- if (omap_secure_apis_support())
- omap_auxcoreboot_addr(virt_to_phys(startup_addr));
- else
- __raw_writel(virt_to_phys(omap5_secondary_startup),
- base + OMAP_AUX_CORE_BOOT_1);
-
- /*
- * Send a 'sev' to wake the secondary core from WFE.
- * Drain the outstanding writes to memory
- */
- dsb_sev();
- mb();
-}
-
/*
* Initialise the CPU possible map early - this describes the CPUs
* which may be present or become present in the system.
@@ -229,6 +199,8 @@ static void __init omap4_smp_init_cpus(void)
static void __init omap4_smp_prepare_cpus(unsigned int max_cpus)
{
+ void *startup_addr = omap_secondary_startup;
+ void __iomem *base = omap_get_wakeupgen_base();
/*
* Initialise the SCU and wake up the secondary core using
@@ -236,7 +208,24 @@ static void __init omap4_smp_prepare_cpus(unsigned int max_cpus)
*/
if (scu_base)
scu_enable(scu_base);
- wakeup_secondary();
+
+ if (cpu_is_omap446x()) {
+ startup_addr = omap_secondary_startup_4460;
+ pm44xx_errata |= PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD;
+ }
+
+ /*
+ * Write the address of secondary startup routine into the
+ * AuxCoreBoot1 where ROM code will jump and start executing
+ * on secondary core once out of WFE
+ * A barrier is added to ensure that write buffer is drained
+ */
+ if (omap_secure_apis_support())
+ omap_auxcoreboot_addr(virt_to_phys(startup_addr));
+ else
+ __raw_writel(virt_to_phys(omap5_secondary_startup),
+ base + OMAP_AUX_CORE_BOOT_1);
+
}
struct smp_operations omap4_smp_ops __initdata = {
--
1.7.9.5
^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus()
2013-03-27 19:04 ` Santosh Shilimkar
2013-03-27 19:54 ` Kevin Hilman
@ 2013-03-28 9:46 ` Russell King - ARM Linux
2013-03-28 9:58 ` Santosh Shilimkar
1 sibling, 1 reply; 37+ messages in thread
From: Russell King - ARM Linux @ 2013-03-28 9:46 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Mar 28, 2013 at 12:34:50AM +0530, Santosh Shilimkar wrote:
> On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
> > Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> >
> >> Move the secondary CPU wakeup prepare code under smp_prepare_cpus().
> >
> > Why?
> >
> Because that code belongs to smp_prepare_cpus(). As I said
> in earlier patches, it was remainder of the pen release code
> which was borrowed from ARM code initially.
What about hotplug after the system is suspended? Is this setup
preserved by the secure ROM?
If not, it really needs to be part of the CPU bringup, not the
boot-time-only preparation code.
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus()
2013-03-28 9:46 ` Russell King - ARM Linux
@ 2013-03-28 9:58 ` Santosh Shilimkar
2013-03-28 12:04 ` Russell King - ARM Linux
0 siblings, 1 reply; 37+ messages in thread
From: Santosh Shilimkar @ 2013-03-28 9:58 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 28 March 2013 03:16 PM, Russell King - ARM Linux wrote:
> On Thu, Mar 28, 2013 at 12:34:50AM +0530, Santosh Shilimkar wrote:
>> On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>
>>>> Move the secondary CPU wakeup prepare code under smp_prepare_cpus().
>>>
>>> Why?
>>>
>> Because that code belongs to smp_prepare_cpus(). As I said
>> in earlier patches, it was remainder of the pen release code
>> which was borrowed from ARM code initially.
>
> What about hotplug after the system is suspended? Is this setup
> preserved by the secure ROM?
>
> If not, it really needs to be part of the CPU bringup, not the
> boot-time-only preparation code.
>
Its already the case. Hotplug CPU restarts just like CPU bring-up.
Initial code, hotplug cpu and last cpu(suspend) were taking identical
path for the suspend wakeup. Later you suggested after the discussion
that hotplug CPU state need not be saved and can be restarted just like
the CPU bring-up path.
So the current code follows above.
Regards,
Santosh
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus()
2013-03-28 9:58 ` Santosh Shilimkar
@ 2013-03-28 12:04 ` Russell King - ARM Linux
2013-03-28 12:09 ` Santosh Shilimkar
0 siblings, 1 reply; 37+ messages in thread
From: Russell King - ARM Linux @ 2013-03-28 12:04 UTC (permalink / raw)
To: linux-arm-kernel
On Thu, Mar 28, 2013 at 03:28:12PM +0530, Santosh Shilimkar wrote:
> On Thursday 28 March 2013 03:16 PM, Russell King - ARM Linux wrote:
> > On Thu, Mar 28, 2013 at 12:34:50AM +0530, Santosh Shilimkar wrote:
> >> On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
> >>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> >>>
> >>>> Move the secondary CPU wakeup prepare code under smp_prepare_cpus().
> >>>
> >>> Why?
> >>>
> >> Because that code belongs to smp_prepare_cpus(). As I said
> >> in earlier patches, it was remainder of the pen release code
> >> which was borrowed from ARM code initially.
> >
> > What about hotplug after the system is suspended? Is this setup
> > preserved by the secure ROM?
> >
> > If not, it really needs to be part of the CPU bringup, not the
> > boot-time-only preparation code.
> >
> Its already the case. Hotplug CPU restarts just like CPU bring-up.
> Initial code, hotplug cpu and last cpu(suspend) were taking identical
> path for the suspend wakeup. Later you suggested after the discussion
> that hotplug CPU state need not be saved and can be restarted just like
> the CPU bring-up path.
>
> So the current code follows above.
smp_prepare_cpus() doesn't get run apart from at initial boot.
So, I repeat my question: what restores OMAP_AUX_CORE_BOOT_1 after
context loss?
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus()
2013-03-28 12:04 ` Russell King - ARM Linux
@ 2013-03-28 12:09 ` Santosh Shilimkar
0 siblings, 0 replies; 37+ messages in thread
From: Santosh Shilimkar @ 2013-03-28 12:09 UTC (permalink / raw)
To: linux-arm-kernel
On Thursday 28 March 2013 05:34 PM, Russell King - ARM Linux wrote:
> On Thu, Mar 28, 2013 at 03:28:12PM +0530, Santosh Shilimkar wrote:
>> On Thursday 28 March 2013 03:16 PM, Russell King - ARM Linux wrote:
>>> On Thu, Mar 28, 2013 at 12:34:50AM +0530, Santosh Shilimkar wrote:
>>>> On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
>>>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>>>
>>>>>> Move the secondary CPU wakeup prepare code under smp_prepare_cpus().
>>>>>
>>>>> Why?
>>>>>
>>>> Because that code belongs to smp_prepare_cpus(). As I said
>>>> in earlier patches, it was remainder of the pen release code
>>>> which was borrowed from ARM code initially.
>>>
>>> What about hotplug after the system is suspended? Is this setup
>>> preserved by the secure ROM?
>>>
>>> If not, it really needs to be part of the CPU bringup, not the
>>> boot-time-only preparation code.
>>>
>> Its already the case. Hotplug CPU restarts just like CPU bring-up.
>> Initial code, hotplug cpu and last cpu(suspend) were taking identical
>> path for the suspend wakeup. Later you suggested after the discussion
>> that hotplug CPU state need not be saved and can be restarted just like
>> the CPU bring-up path.
>>
>> So the current code follows above.
>
> smp_prepare_cpus() doesn't get run apart from at initial boot.
>
> So, I repeat my question: what restores OMAP_AUX_CORE_BOOT_1 after
> context loss?
>
Sorry I missed your point. OMAP_AUX_CORE_BOOT_* registers
are maintained across power transitions.
Regards,
Santosh
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 8/9] ARM: OMAP4: PM: Remove L4 wakeup depedency with MPU since errata fix exist now
2013-02-20 15:18 [PATCH 0/9] ARM: OMAP: Static deps, fiq, omap-smp cleanup Santosh Shilimkar
` (6 preceding siblings ...)
2013-02-20 15:18 ` [PATCH 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus() Santosh Shilimkar
@ 2013-02-20 15:18 ` Santosh Shilimkar
2013-03-27 18:46 ` Kevin Hilman
2013-02-20 15:18 ` [PATCH 9/9] ARM: OMAP4: PM: Now remove L4 per clockdomain static depedency with MPU Santosh Shilimkar
8 siblings, 1 reply; 37+ messages in thread
From: Santosh Shilimkar @ 2013-02-20 15:18 UTC (permalink / raw)
To: linux-arm-kernel
With commit bfd6d021 {ARM: OMAP3+: Implement timer workaround for errata
i103 and i767}, the sync and gptimer synchronization errata got fixed.
Hence the l4_wakeup static dependency with MPU can can be removed
now. Static dependency was one of the proposed workaround but from
power savings perspective, it isn't an ideal workaround.
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/pm44xx.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index a96ae57..1fd9662 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -133,7 +133,7 @@ static void omap_default_idle(void)
int __init omap4_pm_init(void)
{
int ret;
- struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm, *l4wkup;
+ struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm;
struct clockdomain *ducati_clkdm, *l3_2_clkdm, *l4_per_clkdm;
if (omap_rev() == OMAP4430_REV_ES1_0) {
@@ -154,19 +154,14 @@ int __init omap4_pm_init(void)
* MPUSS -> L4_PER/L3_* and DUCATI -> L3_* doesn't work as
* expected. The hardware recommendation is to enable static
* dependencies for these to avoid system lock ups or random crashes.
- * The L4 wakeup depedency is added to workaround the OCP sync hardware
- * BUG with 32K synctimer which lead to incorrect timer value read
- * from the 32K counter. The BUG applies for GPTIMER1 and WDT2 which
- * are part of L4 wakeup clockdomain.
*/
mpuss_clkdm = clkdm_lookup("mpuss_clkdm");
emif_clkdm = clkdm_lookup("l3_emif_clkdm");
l3_1_clkdm = clkdm_lookup("l3_1_clkdm");
l3_2_clkdm = clkdm_lookup("l3_2_clkdm");
l4_per_clkdm = clkdm_lookup("l4_per_clkdm");
- l4wkup = clkdm_lookup("l4_wkup_clkdm");
ducati_clkdm = clkdm_lookup("ducati_clkdm");
- if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) || (!l4wkup) ||
+ if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) ||
(!l3_2_clkdm) || (!ducati_clkdm) || (!l4_per_clkdm))
goto err2;
@@ -174,7 +169,6 @@ int __init omap4_pm_init(void)
ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm);
ret |= clkdm_add_wkdep(mpuss_clkdm, l3_2_clkdm);
ret |= clkdm_add_wkdep(mpuss_clkdm, l4_per_clkdm);
- ret |= clkdm_add_wkdep(mpuss_clkdm, l4wkup);
ret |= clkdm_add_wkdep(ducati_clkdm, l3_1_clkdm);
ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm);
if (ret) {
--
1.7.9.5
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 9/9] ARM: OMAP4: PM: Now remove L4 per clockdomain static depedency with MPU
2013-02-20 15:18 [PATCH 0/9] ARM: OMAP: Static deps, fiq, omap-smp cleanup Santosh Shilimkar
` (7 preceding siblings ...)
2013-02-20 15:18 ` [PATCH 8/9] ARM: OMAP4: PM: Remove L4 wakeup depedency with MPU since errata fix exist now Santosh Shilimkar
@ 2013-02-20 15:18 ` Santosh Shilimkar
2013-03-27 18:46 ` Kevin Hilman
8 siblings, 1 reply; 37+ messages in thread
From: Santosh Shilimkar @ 2013-02-20 15:18 UTC (permalink / raw)
To: linux-arm-kernel
UART driver slave idle issue has been taken care by driver using hwmod
framework.
So we can now ger rid off the L4 per clockdomain static dependency with
MPU which was used to wrok around UART wakeup and console sluggishnesh issue
on OMAP4 SOCs.
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/pm44xx.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
index 1fd9662..1d03110 100644
--- a/arch/arm/mach-omap2/pm44xx.c
+++ b/arch/arm/mach-omap2/pm44xx.c
@@ -134,7 +134,7 @@ int __init omap4_pm_init(void)
{
int ret;
struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm;
- struct clockdomain *ducati_clkdm, *l3_2_clkdm, *l4_per_clkdm;
+ struct clockdomain *ducati_clkdm, *l3_2_clkdm;
if (omap_rev() == OMAP4430_REV_ES1_0) {
WARN(1, "Power Management not supported on OMAP4430 ES1.0\n");
@@ -159,16 +159,14 @@ int __init omap4_pm_init(void)
emif_clkdm = clkdm_lookup("l3_emif_clkdm");
l3_1_clkdm = clkdm_lookup("l3_1_clkdm");
l3_2_clkdm = clkdm_lookup("l3_2_clkdm");
- l4_per_clkdm = clkdm_lookup("l4_per_clkdm");
ducati_clkdm = clkdm_lookup("ducati_clkdm");
if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) ||
- (!l3_2_clkdm) || (!ducati_clkdm) || (!l4_per_clkdm))
+ (!l3_2_clkdm) || (!ducati_clkdm))
goto err2;
ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm);
ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm);
ret |= clkdm_add_wkdep(mpuss_clkdm, l3_2_clkdm);
- ret |= clkdm_add_wkdep(mpuss_clkdm, l4_per_clkdm);
ret |= clkdm_add_wkdep(ducati_clkdm, l3_1_clkdm);
ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm);
if (ret) {
--
1.7.9.5
^ permalink raw reply related [flat|nested] 37+ messages in thread* [PATCH 9/9] ARM: OMAP4: PM: Now remove L4 per clockdomain static depedency with MPU
2013-02-20 15:18 ` [PATCH 9/9] ARM: OMAP4: PM: Now remove L4 per clockdomain static depedency with MPU Santosh Shilimkar
@ 2013-03-27 18:46 ` Kevin Hilman
0 siblings, 0 replies; 37+ messages in thread
From: Kevin Hilman @ 2013-03-27 18:46 UTC (permalink / raw)
To: linux-arm-kernel
Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> UART driver slave idle issue has been taken care by driver using hwmod
> framework.
>
> So we can now ger rid off the L4 per clockdomain static dependency with
> MPU which was used to wrok around UART wakeup and console sluggishnesh issue
> on OMAP4 SOCs.
>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Nice.
Acked-by: Kevin Hilman <khilman@linaro.org>
> ---
> arch/arm/mach-omap2/pm44xx.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c
> index 1fd9662..1d03110 100644
> --- a/arch/arm/mach-omap2/pm44xx.c
> +++ b/arch/arm/mach-omap2/pm44xx.c
> @@ -134,7 +134,7 @@ int __init omap4_pm_init(void)
> {
> int ret;
> struct clockdomain *emif_clkdm, *mpuss_clkdm, *l3_1_clkdm;
> - struct clockdomain *ducati_clkdm, *l3_2_clkdm, *l4_per_clkdm;
> + struct clockdomain *ducati_clkdm, *l3_2_clkdm;
>
> if (omap_rev() == OMAP4430_REV_ES1_0) {
> WARN(1, "Power Management not supported on OMAP4430 ES1.0\n");
> @@ -159,16 +159,14 @@ int __init omap4_pm_init(void)
> emif_clkdm = clkdm_lookup("l3_emif_clkdm");
> l3_1_clkdm = clkdm_lookup("l3_1_clkdm");
> l3_2_clkdm = clkdm_lookup("l3_2_clkdm");
> - l4_per_clkdm = clkdm_lookup("l4_per_clkdm");
> ducati_clkdm = clkdm_lookup("ducati_clkdm");
> if ((!mpuss_clkdm) || (!emif_clkdm) || (!l3_1_clkdm) ||
> - (!l3_2_clkdm) || (!ducati_clkdm) || (!l4_per_clkdm))
> + (!l3_2_clkdm) || (!ducati_clkdm))
> goto err2;
>
> ret = clkdm_add_wkdep(mpuss_clkdm, emif_clkdm);
> ret |= clkdm_add_wkdep(mpuss_clkdm, l3_1_clkdm);
> ret |= clkdm_add_wkdep(mpuss_clkdm, l3_2_clkdm);
> - ret |= clkdm_add_wkdep(mpuss_clkdm, l4_per_clkdm);
> ret |= clkdm_add_wkdep(ducati_clkdm, l3_1_clkdm);
> ret |= clkdm_add_wkdep(ducati_clkdm, l3_2_clkdm);
> if (ret) {
^ permalink raw reply [flat|nested] 37+ messages in thread