ARM: omap4 related fixes for 2.6.39
Subsystems (8)
cover ARM: omap4 related fixes for 2.6.39
The series mainly does below
- Makes ARM local timers selection runtime instead of compile time.
- Enables the LOCAL_TIMER support for OMAP4430
- Add and enable PL310 Errata for flush by Way
- Fixes the NR_CPU value in omap2plus config
- Removes the un-necessary omap44xx_sram_init FIXME
Boot tested on OMAP4430 ES1.0 and ES2.X silicons.
The following changes since commit 100b33c8bd8a3235fd0b7948338d6cbb3db3c63d:
Linus Torvalds (1):
Linux 2.6.38-rc4
are available in the git repository at:
git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git omap4-misc_for.39
Santosh Shilimkar (5):
ARM: smp: Select local timers vs dummy timer support runtime
omap4: Enable ARM local timers with OMAP4430 es1.0 exception
ARM: l2x0: Errata fix for flush by Way operation can cause data
corruption
omap2plus: omap4: Set NR_CPU to 2 instead of default 4
omap4: Remove 'FIXME: omap44xx_sram_init not implemented'
arch/arm/Kconfig | 11 +++++++++++ arch/arm/configs/omap2plus_defconfig | 1 + arch/arm/include/asm/localtimer.h | 8 +++++++- arch/arm/kernel/smp.c | 7 +++---- arch/arm/mach-msm/timer.c | 3 ++- arch/arm/mach-omap2/Kconfig | 2 ++ arch/arm/mach-omap2/timer-mpu.c | 7 ++++++- arch/arm/mach-realview/localtimer.c | 3 ++- arch/arm/mach-s5pv310/localtimer.c | 3 ++- arch/arm/mach-shmobile/localtimer.c | 3 ++- arch/arm/mach-tegra/localtimer.c | 3 ++- arch/arm/mach-ux500/localtimer.c | 3 ++- arch/arm/mach-vexpress/localtimer.c | 3 ++- arch/arm/mm/cache-l2x0.c | 16 ++++++++++------ arch/arm/plat-omap/sram.c | 16 ---------------- 15 files changed, 54 insertions(+), 35 deletions(-)
PATCH 1/5 ARM: smp: Select local timers vs dummy timer support runtime
The current code support of dummy timers in absence of local timer is compile time. This is an attempt to convert it to runtime so that on few SOC version if the local timers aren't supported kernel can switch to dummy timers. OMAP4430 ES1.0 does suffer from this limitation.
This patch should not have any functional impact on affected files.
--- arch/arm/include/asm/localtimer.h | 8 +++++++- arch/arm/kernel/smp.c | 7 +++---- arch/arm/mach-msm/timer.c | 3 ++- arch/arm/mach-omap2/timer-mpu.c | 3 ++- arch/arm/mach-realview/localtimer.c | 3 ++- arch/arm/mach-s5pv310/localtimer.c | 3 ++- arch/arm/mach-shmobile/localtimer.c | 3 ++- arch/arm/mach-tegra/localtimer.c | 3 ++- arch/arm/mach-ux500/localtimer.c | 3 ++- arch/arm/mach-vexpress/localtimer.c | 3 ++- 10 files changed, 26 insertions(+), 13 deletions(-)
arch/arm/include/asm/localtimer.h +7 -1
@@ -44,8 +44,14 @@ int local_timer_ack(void);/* * Setup a local timer interrupt for a CPU. */ -void local_timer_setup (struct clock_event_device *); +int local_timer_setup (struct clock_event_device *); +#else + +static inline int local_timer_setup (struct clock_event_device *evt) +{ +return -ENXIO ; +}#endif #endif
arch/arm/kernel/smp.c +3 -4
@@ -474,13 +474,12 @@ static void smp_timer_broadcast(const struct cpumask *mask)#define smp_timer_broadcast NULL#endif -#ifndef CONFIG_LOCAL_TIMERS static void broadcast_timer_set_mode (enum clock_event_mode mode,struct clock_event_device *evt) { } -static void local_timer_setup (struct clock_event_device *evt) +static void dummy_timer_setup (struct clock_event_device *evt) { evt->name ="dummy_timer" ; evt->features = CLOCK_EVT_FEAT_ONESHOT |
@@ -492,7 +491,6 @@ static void local_timer_setup(struct clock_event_device *evt)clockevents_register_device (evt); } -#endif void __cpuinit percpu_timer_setup (void ) {
@@ -502,7 +500,8 @@ void __cpuinit percpu_timer_setup(void) evt->cpumask =cpumask_of (cpu); evt->broadcast = smp_timer_broadcast; -local_timer_setup (evt); +if (local_timer_setup (evt)) +dummy_timer_setup (evt); }#ifdef CONFIG_HOTPLUG_CPU
arch/arm/mach-msm/timer.c +2 -1
@@ -255,7 +255,7 @@ static void __init msm_timer_init(void) }#ifdef CONFIG_SMP -void __cpuinit local_timer_setup (struct clock_event_device *evt) +int __cpuinit local_timer_setup (struct clock_event_device *evt) {struct msm_clock *clock = &msm_clocks[MSM_GLOBAL_TIMER ];
@@ -287,6 +287,7 @@ void __cpuinit local_timer_setup(struct clock_event_device *evt)gic_enable_ppi (clock->irq.irq);clockevents_register_device (evt); +return 0 ; }inline int local_timer_ack (void )
arch/arm/mach-omap2/timer-mpu.c +2 -1
@@ -26,9 +26,10 @@/* * Setup the local clock events for a CPU. */ -void __cpuinit local_timer_setup (struct clock_event_device *evt) +int __cpuinit local_timer_setup (struct clock_event_device *evt) { evt->irq =OMAP44XX_IRQ_LOCALTIMER ;twd_timer_setup (evt); +return 0 ; }
arch/arm/mach-realview/localtimer.c +2 -1
@@ -19,8 +19,9 @@/* * Setup the local clock events for a CPU. */ -void __cpuinit local_timer_setup (struct clock_event_device *evt) +int __cpuinit local_timer_setup (struct clock_event_device *evt) { evt->irq =IRQ_LOCALTIMER ;twd_timer_setup (evt); +return 0 ; }
arch/arm/mach-s5pv310/localtimer.c +2 -1
@@ -18,8 +18,9 @@/* * Setup the local clock events for a CPU. */ -void __cpuinit local_timer_setup (struct clock_event_device *evt) +int __cpuinit local_timer_setup (struct clock_event_device *evt) { evt->irq =IRQ_LOCALTIMER ;twd_timer_setup (evt); +return 0 ; }
arch/arm/mach-shmobile/localtimer.c +2 -1
@@ -18,8 +18,9 @@/* * Setup the local clock events for a CPU. */ -void __cpuinit local_timer_setup (struct clock_event_device *evt) +int __cpuinit local_timer_setup (struct clock_event_device *evt) { evt->irq =29 ;twd_timer_setup (evt); +return 0 ; }
arch/arm/mach-tegra/localtimer.c +2 -1
@@ -18,8 +18,9 @@/* * Setup the local clock events for a CPU. */ -void __cpuinit local_timer_setup (struct clock_event_device *evt) +int __cpuinit local_timer_setup (struct clock_event_device *evt) { evt->irq =IRQ_LOCALTIMER ;twd_timer_setup (evt); +return 0 ; }
arch/arm/mach-ux500/localtimer.c +2 -1
@@ -21,8 +21,9 @@/* * Setup the local clock events for a CPU. */ -void __cpuinit local_timer_setup (struct clock_event_device *evt) +int __cpuinit local_timer_setup (struct clock_event_device *evt) { evt->irq =IRQ_LOCALTIMER ;twd_timer_setup (evt); +return 0 ; }
arch/arm/mach-vexpress/localtimer.c +2 -1
@@ -19,8 +19,9 @@/* * Setup the local clock events for a CPU. */ -void __cpuinit local_timer_setup (struct clock_event_device *evt) +int __cpuinit local_timer_setup (struct clock_event_device *evt) { evt->irq =IRQ_LOCALTIMER ;twd_timer_setup (evt); +return 0 ; }
Signature · 1 line
1.6.0.4
PATCH 1/5 ARM: smp: Select local timers vs dummy timer support runtime
Quoted 6 lines · Santosh Shilimkar
The current code support of dummy timers in absence of local timer is compile time. This is an attempt to convert it to runtime so that on few SOC version if the local timers aren't supported kernel can switch to dummy timers. OMAP4430 ES1.0 does suffer from this limitation.
Quoted 6 lines
This patch should not have any functional impact on affected files.
Signed-off-by Santosh Shilimkar <[email protected]>--- arch/arm/mach-msm/timer.c | 3 ++-
Signature · 2 lines
Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
PATCH 1/5 ARM: smp: Select local timers vs dummy timer support runtime
In reply to Santosh ShilimkarLet's try this again from the correct email address...
Quoted 10 lines · Santosh Shilimkar
The current code support of dummy timers in absence of local timer is compile time. This is an attempt to convert it to runtime so that on few SOC version if the local timers aren't supported kernel can switch to dummy timers. OMAP4430 ES1.0 does suffer from this limitation.
This patch should not have any functional impact on affected files.
arch/arm/mach-msm/timer.c | 3 ++-
Signature · 2 lines
Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
PATCH 1/5 ARM: smp: Select local timers vs dummy timer support runtime
In reply to Santosh ShilimkarRussell,
Quoted 33 lines
-----Original Message-----
From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
Sent: Saturday, February 12, 2011 5:00 PM
To: linux-omap at vger.kernel.org
Cc: khilman at ti.com; linux-arm-kernel at lists.infradead.org; tony at atomide.com; Santosh Shilimkar; Russell King; David Brown; Daniel Walker; Bryan Huntsman; Kukjin Kim; Paul Mundt; Magnus Damm; Colin Cross; Erik Gilling; Srinidhi Kasagar; Linus Walleij
Subject: [PATCH 1/5] ARM: smp: Select local timers vs dummy timer support runtimeThe current code support of dummy timers in absence of local timer is compile time. This is an attempt to convert it to runtime so that on few SOC version if the local timers aren't supported kernel can switch to dummy timers. OMAP4430 ES1.0 does suffer from this limitation.
This patch should not have any functional impact on affected files.
Signed-off-by Santosh Shilimkar <[email protected]>Cc Russell King <[email protected]>Cc David Brown <[email protected]>Cc Daniel Walker <[email protected]>Cc Bryan Huntsman <[email protected]>Cc Tony Lindgren <[email protected]>Cc Kukjin Kim <[email protected]>Cc Paul Mundt <[email protected]>Cc Magnus Damm <[email protected]>Cc Colin Cross <[email protected]>Cc Erik Gilling <[email protected]>Cc Srinidhi Kasagar <[email protected]>Cc Linus Walleij <[email protected]>
Quoted 1 line
---
Any comments on this one?
So far David has acked this for mach-msm.
Quoted 209 lines
arch/arm/include/asm/localtimer.h | 8 +++++++- arch/arm/kernel/smp.c | 7 +++---- arch/arm/mach-msm/timer.c | 3 ++- arch/arm/mach-omap2/timer-mpu.c | 3 ++- arch/arm/mach-realview/localtimer.c | 3 ++- arch/arm/mach-s5pv310/localtimer.c | 3 ++- arch/arm/mach-shmobile/localtimer.c | 3 ++- arch/arm/mach-tegra/localtimer.c | 3 ++- arch/arm/mach-ux500/localtimer.c | 3 ++- arch/arm/mach-vexpress/localtimer.c | 3 ++- 10 files changed, 26 insertions(+), 13 deletions(-)arch/arm/include/asm/localtimer.h +7
-1@@ -44,8 +44,14 @@ int local_timer_ack(void);/* * Setup a local timer interrupt for a CPU. */ -void local_timer_setup (struct clock_event_device *); +int local_timer_setup (struct clock_event_device *); +#else + +static inline int local_timer_setup (struct clock_event_device *evt) +{ +return -ENXIO ; +}#endif #endif arch/arm/kernel/smp.c +1
-2@@ -474,13 +474,12 @@ static void smp_timer_broadcast(const struct cpumask *mask)#define smp_timer_broadcast NULL#endif -#ifndef CONFIG_LOCAL_TIMERS static void broadcast_timer_set_mode (enum clock_event_mode mode,struct clock_event_device *evt) { } -static void local_timer_setup (struct clock_event_device *evt) +static void dummy_timer_setup (struct clock_event_device *evt) { evt->name ="dummy_timer" ;arch/arm/kernel/smp.c +0
-1evt->features = CLOCK_EVT_FEAT_ONESHOT |@@ -492,7 +491,6 @@ static void local_timer_setup(struct clock_event_device *evt)clockevents_register_device (evt ); } -#endif void __cpuinit percpu_timer_setup (void ){
arch/arm/kernel/smp.c +2
-1@@ -502,7 +500,8 @@ void __cpuinit percpu_timer_setup(void) evt->cpumask =cpumask_of (cpu); evt->broadcast = smp_timer_broadcast; -local_timer_setup (evt); +if (local_timer_setup (evt)) +dummy_timer_setup (evt); }#ifdef CONFIG_HOTPLUG_CPU arch/arm/mach-msm/timer.c +2
-1@@ -255,7 +255,7 @@ static void __init msm_timer_init(void) }#ifdef CONFIG_SMP -void __cpuinit local_timer_setup (struct clock_event_device *evt) +int __cpuinit local_timer_setup (struct clock_event_device *evt) {struct msm_clock *clock = &msm_clocks[MSM_GLOBAL_TIMER ];@@ -287,6 +287,7 @@ void __cpuinit local_timer_setup(struct clock_event_device *evt) gic_enable_ppi(clock->irq.irq);clockevents_register_device (evt); +return 0 ; }inline int
local_timer_ack(void)arch/arm/mach- renamed from arch/arm/mach-omap2/timer-mpu.c +0
-0
omap2/timer-mpu.c
index 954682e..09c73dc 100644arch/arm/mach-omap2/timer-mpu.c +2
-1@@ -26,9 +26,10 @@/* * Setup the local clock events for a CPU. */ -void __cpuinit local_timer_setup (struct clock_event_device *evt) +int __cpuinit local_timer_setup (struct clock_event_device *evt) { evt->irq =OMAP44XX_IRQ_LOCALTIMER ;twd_timer_setup (evt); +return 0 ; }arch/arm/mach- renamed from arch/arm/mach-realview/localtimer.c +0
-0
realview/localtimer.c
index 60b4e11..aca29ce 100644arch/arm/mach-realview/localtimer.c +2
-1@@ -19,8 +19,9 @@/* * Setup the local clock events for a CPU. */ -void __cpuinit local_timer_setup (struct clock_event_device *evt) +int __cpuinit local_timer_setup (struct clock_event_device *evt) { evt->irq =IRQ_LOCALTIMER ;twd_timer_setup (evt); +return 0 ; }arch/arm/mach- renamed from arch/arm/mach-s5pv310/localtimer.c +0
-0
s5pv310/localtimer.c
index 2784036..8239c6a 100644arch/arm/mach-s5pv310/localtimer.c +2
-1@@ -18,8 +18,9 @@/* * Setup the local clock events for a CPU. */ -void __cpuinit local_timer_setup (struct clock_event_device *evt) +int __cpuinit local_timer_setup (struct clock_event_device *evt) { evt->irq =IRQ_LOCALTIMER ;twd_timer_setup (evt); +return 0 ; }arch/arm/mach- renamed from arch/arm/mach-shmobile/localtimer.c +0
-0
shmobile/localtimer.c
index 2111c28..ad9ccc9 100644arch/arm/mach-shmobile/localtimer.c +2
-1@@ -18,8 +18,9 @@/* * Setup the local clock events for a CPU. */ -void __cpuinit local_timer_setup (struct clock_event_device *evt) +int __cpuinit local_timer_setup (struct clock_event_device *evt) { evt->irq =29 ;twd_timer_setup (evt); +return 0 ; }arch/arm/mach- renamed from arch/arm/mach-tegra/localtimer.c +0
-0
tegra/localtimer.c
index f81ca7c..e91d681 100644arch/arm/mach-tegra/localtimer.c +2
-1@@ -18,8 +18,9 @@/* * Setup the local clock events for a CPU. */ -void __cpuinit local_timer_setup (struct clock_event_device *evt) +int __cpuinit local_timer_setup (struct clock_event_device *evt) { evt->irq =IRQ_LOCALTIMER ;twd_timer_setup (evt); +return 0 ; }arch/arm/mach- renamed from arch/arm/mach-ux500/localtimer.c +0
-0
ux500/localtimer.c
index 2288f6a..5ba1133 100644arch/arm/mach-ux500/localtimer.c +2
-1@@ -21,8 +21,9 @@/* * Setup the local clock events for a CPU. */ -void __cpuinit local_timer_setup (struct clock_event_device *evt) +int __cpuinit local_timer_setup (struct clock_event_device *evt) { evt->irq =IRQ_LOCALTIMER ;twd_timer_setup (evt); +return 0 ; }arch/arm/mach- renamed from arch/arm/mach-vexpress/localtimer.c +0
-0
vexpress/localtimer.c
index c0e3a59..e5adbfa 100644arch/arm/mach-vexpress/localtimer.c +2
-2@@ -19,8 +19,9 @@/* * Setup the local clock events for a CPU. */ -void __cpuinit local_timer_setup (struct clock_event_device *evt) +int __cpuinit local_timer_setup (struct clock_event_device *evt) { evt->irq =IRQ_LOCALTIMER ;twd_timer_setup (evt); +return 0 ; } --1.6.0.4
PATCH 1/5 ARM: smp: Select local timers vs dummy timer support runtime
In reply to Santosh Shilimkararch/arm/kernel/smp.c static void smp_timer_broadcast(const struct cpumask *mask) · line 482
Quoted 8 lines · Santosh Shilimkar
arch/arm/kernel/smp.c +1
-2-#ifndef CONFIG_LOCAL_TIMERS static void broadcast_timer_set_mode (enum clock_event_mode mode,struct clock_event_device *evt) { } -static void local_timer_setup (struct clock_event_device *evt) +static void dummy_timer_setup (struct clock_event_device *evt)
Please call this broadcast_timer_setup().
PATCH 1/5 ARM: smp: Select local timers vs dummy timersupport runtime
Quoted 18 lines
-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Sunday, February 20, 2011 4:34 PM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; khilman at ti.com; linux-arm- kernel at lists.infradead.org; tony at atomide.com; David Brown; Daniel Walker; Bryan Huntsman; Kukjin Kim; Paul Mundt; Magnus Damm; Colin Cross; Erik Gilling; Srinidhi Kasagar; Linus Walleij
Subject: Re: [PATCH 1/5] ARM: smp: Select local timers vs dummy timersupport runtimeQuoted 6 lines · Santosh Shilimkar
arch/arm/kernel/smp.c +0
-1-#ifndef CONFIG_LOCAL_TIMERS static void broadcast_timer_set_mode (enum clock_event_mode mode,struct clock_event_device *evt) { }
Quoted 4 lines
arch/arm/kernel/smp.c static void smp_timer_broadcast(const struct cpumask *mask) · line 482
Quoted 2 lines
arch/arm/kernel/smp.c +1
-1-static void local_timer_setup (struct clock_event_device *evt) +static void dummy_timer_setup (struct clock_event_device *evt)Please call this
broadcast_timer_setup().
Right. Will fix this.
Regards
Santosh
PATCH 1/5 ARM: smp: Select local timers vs dummy timersupport runtime
Quoted 18 lines · Santosh Shilimkar
Quoted 18 lines
-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Sunday, February 20, 2011 4:34 PM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; khilman at ti.com; linux-arm- kernel at lists.infradead.org; tony at atomide.com; David Brown; Daniel Walker; Bryan Huntsman; Kukjin Kim; Paul Mundt; Magnus Damm; Colin Cross; Erik Gilling; Srinidhi Kasagar; Linus Walleij
Subject: Re: [PATCH 1/5] ARM: smp: Select local timers vs dummy timersupport runtimeQuoted 6 lines · Santosh Shilimkar
arch/arm/kernel/smp.c +0
-1-#ifndef CONFIG_LOCAL_TIMERS static void broadcast_timer_set_mode (enum clock_event_mode mode,struct clock_event_device *evt) { }
Quoted 6 lines
Quoted 4 lines
arch/arm/kernel/smp.c static void smp_timer_broadcast(const struct cpumask *mask) · line 482
Quoted 2 lines
arch/arm/kernel/smp.c +1
-1-static void local_timer_setup (struct clock_event_device *evt) +static void dummy_timer_setup (struct clock_event_device *evt)Please call this
broadcast_timer_setup().Right. Will fix this.
Grr. This conflicts horribly with the Versatile stuff. Can you recreate against what currently appears in devel rather than mainline please?
PATCH 1/5 ARM: smp: Select local timers vs dummytimersupport runtime
Quoted 39 lines
-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Wednesday, February 23, 2011 10:07 PM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; Kevin Hilman; linux-arm- kernel at lists.infradead.org; tony at atomide.com; David Brown; Daniel Walker; Bryan Huntsman; Kukjin Kim; Paul Mundt; Magnus Damm; Colin Cross; Erik Gilling; Srinidhi Kasagar; Linus Walleij
Subject: Re: [PATCH 1/5] ARM: smp: Select local timers vs dummytimersupport runtimeQuoted 6 lines · Santosh Shilimkar
Quoted 6 lines
-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Sunday, February 20, 2011 4:34 PM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; khilman at ti.com; linux-arm- kernel at lists.infradead.org; tony at atomide.com; David Brown;Daniel
Quoted 1 line
Quoted 1 line
Walker; Bryan Huntsman; Kukjin Kim; Paul Mundt; Magnus Damm;
Colin
Quoted 5 lines
Quoted 5 lines
Cross; Erik Gilling; Srinidhi Kasagar; Linus Walleij
Subject: Re: [PATCH 1/5] ARM: smp: Select local timers vs dummy timersupport runtimeOn Sat, Feb 12, 2011 at 04:59:43PM +0530, Santosh Shilimkar
Quoted 2 lines · wrote:
Quoted 2 lines
Quoted 2 lines
-#ifndef
CONFIG_LOCAL_TIMERS
static void broadcast_timer_set_mode(enumclock_event_modemode,
Quoted 9 lines
Quoted 8 lines
arch/arm/kernel/smp.c static void smp_timer_broadcast(const struct cpumask *mask) · line 482
Quoted 6 lines
arch/arm/kernel/smp.c +1
-1struct clock_event_device *evt) { } -static void local_timer_setup (struct clock_event_device *evt) +static void dummy_timer_setup (struct clock_event_device *evt)Please call this
broadcast_timer_setup().
Quoted 5 lines
Quoted 1 line
Right. Will fix this.
Grr. This conflicts horribly with the Versatile stuff. Can you recreate
against what currently appears in devel rather than mainline please?
Ok. I will pull your devel branch and rebase it
PATCH 1/5 ARM: smp: Select local timers vs dummytimersupport runtime
Quoted 10 lines
-----Original Message-----
From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
Sent: Wednesday, February 23, 2011 10:09 PM
To: Russell King - ARM Linux
Cc: linux-omap at vger.kernel.org; Kevin Hilman; linux-arm- kernel at lists.infradead.org; tony at atomide.com; David Brown; Daniel Walker; Bryan Huntsman; Kukjin Kim; Paul Mundt; Magnus Damm; Colin Cross; Erik Gilling; Srinidhi Kasagar; Linus Walleij
Subject: RE: [PATCH 1/5] ARM: smp: Select local timers vs dummytimersupport runtime
[....]
Quoted 6 lines
Quoted 4 lines
Grr. This conflicts horribly with the Versatile stuff. Can you recreate
against what currently appears in devel rather than mainlineplease?
Ok. I will pull your devel branch and rebase it
Done.
Patch 6759/1 and patch 6760/1 in patch system
Regards,
Santosh
PATCH 1/5 ARM: smp: Select local timers vs dummytimersupport runtime
Quoted 1 line · Santosh Shilimkar
Patch 6759/1 and patch 6760/1 in patch system
Was there any difference between 6760 and 6753 ?
PATCH 1/5 ARM: smp: Select local timers vs dummytimersupportruntime
Quoted 11 lines
-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Thursday, February 24, 2011 12:33 AM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; Kevin Hilman; linux-arm- kernel at lists.infradead.org; tony at atomide.com; David Brown; Daniel Walker; Bryan Huntsman; Kukjin Kim; Paul Mundt; Magnus Damm; Colin Cross; Erik Gilling; Srinidhi Kasagar; Linus Walleij
Subject: Re: [PATCH 1/5] ARM: smp: Select local timers vs dummytimersupportruntime
Quoted 4 lines
Quoted 1 line · Santosh Shilimkar
Patch 6759/1 and patch 6760/1 in patch system
Was there any difference between 6760 and 6753 ?
Nope.
I just rebased them together and pushed
PATCH 1/5 ARM: smp: Select local timers vs dummytimersupportruntime
Quoted 11 lines · Santosh Shilimkar
Quoted 11 lines
-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Thursday, February 24, 2011 12:33 AM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; Kevin Hilman; linux-arm- kernel at lists.infradead.org; tony at atomide.com; David Brown; Daniel Walker; Bryan Huntsman; Kukjin Kim; Paul Mundt; Magnus Damm; Colin Cross; Erik Gilling; Srinidhi Kasagar; Linus Walleij
Subject: Re: [PATCH 1/5] ARM: smp: Select local timers vs dummytimersupportruntime
Quoted 6 lines
Quoted 4 lines · Santosh Shilimkar
Quoted 1 line
Patch 6759/1 and patch 6760/1 in patch system
Was there any difference between 6760 and 6753 ?
Nope.
I just rebased them together and pushed
Well, both patches are identical, so I'll stick with 6753/1 which I've already merged.
Thanks
PATCH 1/5 ARM: smp: Select local timers vsdummytimersupportruntime
Quoted 27 lines
-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Thursday, February 24, 2011 1:26 AM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; Kevin Hilman; linux-arm- kernel at lists.infradead.org; tony at atomide.com; David Brown; Daniel Walker; Bryan Huntsman; Kukjin Kim; Paul Mundt; Magnus Damm; Colin Cross; Erik Gilling; Srinidhi Kasagar; Linus Walleij
Subject: Re: [PATCH 1/5] ARM: smp: Select local timers vsdummytimersupportruntimeQuoted 6 lines · Santosh Shilimkar
Quoted 6 lines
-----Original Message-----
From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
Sent: Thursday, February 24, 2011 12:33 AM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; Kevin Hilman; linux-arm- kernel at lists.infradead.org; tony at atomide.com; David Brown;Daniel
Quoted 1 line
Quoted 1 line
Walker; Bryan Huntsman; Kukjin Kim; Paul Mundt; Magnus Damm;
Colin
Quoted 5 lines
Quoted 5 lines
Cross; Erik Gilling; Srinidhi Kasagar; Linus Walleij
Subject: Re: [PATCH 1/5] ARM: smp: Select local timers vs dummytimersupportruntimeOn Wed, Feb 23, 2011 at 11:28:11PM +0530, Santosh Shilimkar
wrote:
Quoted 9 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Patch 6759/1 and patch 6760/1 in patch system
Was there any difference between 6760 and 6753 ?
Nope.
I just rebased them together and pushedWell, both patches are identical, so I'll stick with 6753/1 which I've already merged.
Thanks.
I got discarded messege for 6753, so I submitted it. As you noticed, they are same.
PATCH 2/5 omap4: Enable ARM local timers with OMAP4430 es1.0 exception
In reply to Santosh ShilimkarOn OMAP4430 ES1.0 the local timers are gated by security. Enable the CONFIG_LOCAL_TIMERS for omap2plus build and handle the OMAP4430 es1.0 exception case.
This patch has dependency on the first patch in this series.
ARM: smp: Select local timers vs dummy timer support runtime
--- arch/arm/mach-omap2/Kconfig | 1 + arch/arm/mach-omap2/timer-mpu.c | 4 ++++ 2 files changed, 5 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/Kconfig +1 -0
@@ -44,6 +44,7 @@ config ARCH_OMAP4 depends on ARCH_OMAP2PLUS select CPU_V7 select ARM_GIC + select LOCAL_TIMERS select PL310_ERRATA_588369 select ARM_ERRATA_720789 select ARCH_HAS_OPP
arch/arm/mach-omap2/timer-mpu.c +4 -0
@@ -28,6 +28,10 @@*/ int __cpuinit local_timer_setup (struct clock_event_device *evt) { +/* Local timers are not supprted on OMAP4430 ES1.0 */ +if (omap_rev () ==OMAP4430_REV_ES1_0 ) +return -ENXIO ; + evt->irq =OMAP44XX_IRQ_LOCALTIMER ;twd_timer_setup (evt);return 0 ;
Signature · 1 line
1.6.0.4
Tony Lindgren
maintainerPATCH 2/5 omap4: Enable ARM local timers with OMAP4430 es1.0 exception
Quoted 8 lines · Santosh Shilimkar
On OMAP4430 ES1.0 the local timers are gated by security. Enable the
CONFIG_LOCAL_TIMERSfor omap2plus build and handle the OMAP4430 es1.0 exception case.This patch has dependency on the first patch in this series.
ARM: smp: Select local timers vs dummy timer support runtimeSigned-off-by Santosh Shilimkar <[email protected]>
Quoted 35 lines
--- arch/arm/mach-omap2/Kconfig | 1 + arch/arm/mach-omap2/timer-mpu.c | 4 ++++ 2 files changed, 5 insertions(+), 0 deletions(-)arch/arm/mach-omap2/Kconfig +1
-0@@ -44,6 +44,7 @@ config ARCH_OMAP4 depends on ARCH_OMAP2PLUS select CPU_V7 select ARM_GIC + select LOCAL_TIMERS select PL310_ERRATA_588369 select ARM_ERRATA_720789 select ARCH_HAS_OPParch/arm/mach-omap2/timer-mpu.c +4
-0@@ -28,6 +28,10 @@*/ int __cpuinit local_timer_setup (struct clock_event_device *evt) { +/* Local timers are not supprted on OMAP4430 ES1.0 */ +if (omap_rev () ==OMAP4430_REV_ES1_0 ) +return -ENXIO ; + evt->irq =OMAP44XX_IRQ_LOCALTIMER ;twd_timer_setup (evt);return 0 ;Signature · 1 line
1.6.0.4
PATCH 2/5 omap4: Enable ARM local timers with OMAP4430 es1.0 exception
In reply to Santosh ShilimkarQuoted 9 lines
-----Original Message-----
From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
Sent: Saturday, February 12, 2011 5:00 PM
To: linux-omap at vger.kernel.org
Cc: khilman at ti.com; linux-arm-kernel at lists.infradead.org; tony at atomide.com; Santosh Shilimkar
Subject: [PATCH 2/5] omap4: Enable ARM local timers with OMAP4430 es1.0 exception
[....]
arch/arm/mach-omap2/Kconfig config ARCH_OMAP4 · line 47
Quoted 10 lines
arch/arm/mach- renamed from arch/arm/mach-omap2/Kconfig +0
-0omap2/Kconfig
index 1a2cf62..f285dd7 100644arch/arm/mach-omap2/Kconfig +1
-0@@ -44,6 +44,7 @@ config ARCH_OMAP4 depends on ARCH_OMAP2PLUS select CPU_V7 select ARM_GIC + select LOCAL_TIMERS
This change should be 'select LOCAL_TIMERS if SMP'
Otherwise, with !SMP, the build will break. Here is the updated version with Tony's ack added.
--------
PATCH 3/5 ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
In reply to Santosh ShilimkarPL310 implements the Clean & Invalidate by Way L2 cache maintenance operation (offset 0x7FC). This operation runs in background so that PL310 can handle normal accesses while it is in progress. Under very rare circumstances, due to this erratum, write data can be lost when PL310 treats a cacheable write transaction during a Clean & Invalidate by Way operation.
Workaround:
Disable Write-Back and Cache Linefill (Debug Control Register) Clean & Invalidate by Way (0x7FC)
Re-enable Write-Back and Cache Linefill (Debug Control Register)
--- arch/arm/Kconfig | 11 +++++++++++ arch/arm/mach-omap2/Kconfig | 1 + arch/arm/mm/cache-l2x0.c | 16 ++++++++++------ 3 files changed, 22 insertions(+), 6 deletions(-)
arch/arm/Kconfig +11 -0
@@ -1177,6 +1177,17 @@ config ARM_ERRATA_743622 visible impact on the overall performance or power consumption of the processor. +config PL310_ERRATA_727915 + bool "Background Clean & Invalidate by Way operation can cause data corruption" + depends on CACHE_L2X0 && ARCH_OMAP4 + help + PL310 implements the Clean & Invalidate by Way L2 cache maintenance + operation (offset 0x7FC). This operation runs in background so that + PL310 can handle normal accesses while it is in progress. Under very + rare circumstances, due to this erratum, write data can be lost when + PL310 treats a cacheable write transaction during a Clean & + Invalidate by Way operation Note that this errata uses Texas + Instrument's secure monitor api to implement the work around. endmenu source "arch/arm/common/Kconfig"
arch/arm/mach-omap2/Kconfig +1 -0
@@ -46,6 +46,7 @@ config ARCH_OMAP4 select ARM_GIC select LOCAL_TIMERS select PL310_ERRATA_588369 + select PL310_ERRATA_727915 select ARM_ERRATA_720789 select ARCH_HAS_OPP select PM_OPP if PM
arch/arm/mm/cache-l2x0.c +10 -6
@@ -67,7 +67,7 @@ static inline void l2x0_inv_line(unsigned long addr)writel_relaxed (addr, base +L2X0_INV_LINE_PA ); } -#ifdef CONFIG_PL310_ERRATA_588369 +#if defined(CONFIG_PL310_ERRATA_588369 ) || defined(CONFIG_PL310_ERRATA_727915 )static void debug_writel (unsigned long val) {extern void omap_smc1 (u32 fn,u32 arg);
@@ -78,7 +78,14 @@ static void debug_writel(unsigned long val)*/ omap_smc1 (0x100 , val); } +#else +/* Optimised out for non-errata case */ +static inline void debug_writel (unsigned long val) +{ +} +#endif +#ifdef CONFIG_PL310_ERRATA_588369 static inline void l2x0_flush_line (unsigned long addr) {void __iomem *base = l2x0_base;
@@ -91,11 +98,6 @@ static inline void l2x0_flush_line(unsigned long addr) }#else -/* Optimised out for non-errata case */ -static inline void debug_writel (unsigned long val) -{ -} -static inline void l2x0_flush_line (unsigned long addr) {void __iomem *base = l2x0_base;
@@ -119,9 +121,11 @@ static void l2x0_flush_all(void)/* clean all ways */ spin_lock_irqsave (&l2x0_lock, flags); +debug_writel (0x03 );writel_relaxed (l2x0_way_mask, l2x0_base +L2X0_CLEAN_INV_WAY );cache_wait_way (l2x0_base +L2X0_CLEAN_INV_WAY , l2x0_way_mask);cache_sync (); +debug_writel (0x00 );spin_unlock_irqrestore (&l2x0_lock, flags); }
Signature · 1 line
1.6.0.4
PATCH 3/5 ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
Quoted 106 lines · Santosh Shilimkar
PL310 implements the Clean & Invalidate by Way L2 cache maintenance operation (offset
0x7FC). This operation runs in background so that PL310 can handle normal accesses while it is in progress. Under very rare circumstances, due to this erratum, write data can be lost when PL310 treats a cacheable write transaction during a Clean & Invalidate by Way operation.Workaround:
Disable Write-Back and Cache Linefill (Debug Control Register) Clean & Invalidate by Way (0x7FC)
Re-enable Write-Back and Cache Linefill (Debug Control Register)Signed-off-by Santosh Shilimkar <[email protected]>Cc Catalin Marinas <[email protected]>---
?arch/arm/Kconfig ? ? ? ? ? ?| ? 11 +++++++++++ ?arch/arm/mach-omap2/Kconfig | ? ?1 + ?arch/arm/mm/cache-l2x0.c ? ?| ? 16 ++++++++++------?3 files changed, 22 insertions(+), 6 deletions(-)
arch/arm/Kconfig +0
-0@@ -1177,6 +1177,17 @@ config ARM_ERRATA_743622? ? ? ? ?visible impact on the overall performance or power consumption of the ? ? ? ? ?processor.
+config
PL310_ERRATA_727915
+ ? ? ? bool "Background Clean & Invalidate by Way operation can cause data corruption"
+ ? ? ? depends onCACHE_L2X0&&ARCH_OMAP4
+ ? ? ? help
+ ? ? ? ? PL310 implements the Clean & Invalidate by Way L2 cache maintenance
+ ? ? ? ? operation (offset0x7FC). This operation runs in background so that
+ ? ? ? ? PL310 can handle normal accesses while it is in progress. Under very
+ ? ? ? ? rare circumstances, due to this erratum, write data can be lost when
+ ? ? ? ? PL310 treats a cacheable write transaction during a Clean &
+ ? ? ? ? Invalidate by Way operation Note that this errata uses Texas
+ ? ? ? ? Instrument's secure monitor api to implement the work around. ?endmenu?source "
arch/arm/common/Kconfig"arch/arm/mach-omap2/Kconfig +0
-0@@ -46,6 +46,7 @@ config ARCH_OMAP4? ? ? ?select
ARM_GIC
? ? ? ?selectLOCAL_TIMERS
? ? ? ?selectPL310_ERRATA_588369
+ ? ? ? selectPL310_ERRATA_727915
? ? ? ?selectARM_ERRATA_720789
? ? ? ?selectARCH_HAS_OPP
? ? ? ?selectPM_OPPif PMarch/arm/mm/cache-l2x0.c +1
-1@@ -67,7 +67,7 @@ static inline void l2x0_inv_line(unsigned long addr) ? ? ? ?writel_relaxed(addr, base + L2X0_INV_LINE_PA); ?} -#ifdef CONFIG_PL310_ERRATA_588369 +#if defined(CONFIG_PL310_ERRATA_588369 ) || defined(CONFIG_PL310_ERRATA_727915 ) ?static void debug_writel(unsigned long val) ?{ ? ? ? ?extern void omap_smc1(u32 fn, u32 arg);@@ -78,7 +78,14 @@ static void debug_writel(unsigned long val)? ? ? ? */
? ? ? ?omap_smc1(0x100, val);
?}arch/arm/mm/cache-l2x0.c +7
-0+#else +/* Optimised out for non-errata case */ +static inline void debug_writel (unsigned long val) +{ +} +#endif +#ifdef CONFIG_PL310_ERRATA_588369 ?static inline void
l2x0_flush_line(unsigned long addr)?{
? ? ? ?void__iomem*base =l2x0_base;arch/arm/mm/cache-l2x0.c +0
-0@@ -91,11 +98,6 @@ static inline void l2x0_flush_line(unsigned long addr) ?}?#else
arch/arm/mm/cache-l2x0.c +0
-5-/* Optimised out for non-errata case */ -static inline void debug_writel (unsigned long val) -{ -} -?static inline void
l2x0_flush_line(unsigned long addr)?{
? ? ? ?void__iomem*base =l2x0_base;arch/arm/mm/cache-l2x0.c +0
-0@@ -119,9 +121,11 @@ static void l2x0_flush_all(void)? ? ? ?/* clean all ways */
? ? ? ?spin_lock_irqsave(&l2x0_lock, flags);
+ ? ? ?debug_writel(0x03);
? ? ? ?writel_relaxed(l2x0_way_mask,l2x0_base+L2X0_CLEAN_INV_WAY); ? ? ? ?cache_wait_way(l2x0_base +L2X0_CLEAN_INV_WAY,l2x0_way_mask); ? ? ? ?cache_sync();
+ ? ? ?debug_writel(0x00);
? ? ? ?spin_unlock_irqrestore(&l2x0_lock, flags);
?}
Quoted 9 lines
--
1.6.0.4_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Can these PL310 errata fixes be made more generic? PL310 is present in non-OMAP platforms too, which lack the TI hypervisor. And these platforms might have the same PL310 rev, and suffer the same glitches. While ideally there is some kind of hypervisor_ops to modify the protected register, at the very least there should be the generic debug_write handling the "I can write all PL310 regs" case. If you're interested I have a patch someplace that tried to do this, hopefully I can still find it.
PATCH 3/5 ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
Quoted 9 lines
-----Original Message-----
From: Andrei Warkentin [mailto:andreiw at motorola.com]
Sent: Saturday, February 12, 2011 11:20 PM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; khilman at ti.com; tony at atomide.com; linux-arm-kernel at lists.infradead.org; Catalin Marinas
Subject: Re: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
[....]
Quoted 11 lines
Can these PL310 errata fixes be made more generic? PL310 is present in
non-OMAP platforms too, which lack the TI hypervisor. And these platforms might have the same PL310 rev, and suffer the same glitches.
While ideally there is some kind ofhypervisor_opsto modify the protected register, at the very least there should be the genericdebug_writehandling the "I can write all PL310 regs" case. If you're interested I have a patch someplace that tried to do this, hopefully I can still find it.
They are kind of generic. If you look at it, the only change Which is arch specific is the implementation of "debug_writel" function. Today this code is not in generic PL310 code, but
OMAP specific.
May be we can make this as exported function pointer, which arch's can populate.
Will that work for you ?
Regards,
Santosh
PATCH 3/5 ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
Quoted 28 lines · Santosh Shilimkar
Quoted 9 lines
-----Original Message-----
From: Andrei Warkentin [mailto:andreiw at motorola.com]
Sent: Saturday, February 12, 2011 11:20 PM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; khilman at ti.com; tony at atomide.com; linux-arm-kernel at lists.infradead.org; Catalin Marinas
Subject: Re: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruption[....]
Quoted 11 lines
Can these PL310 errata fixes be made more generic? PL310 is present in
non-OMAP platforms too, which lack the TI hypervisor. And these platforms might have the same PL310 rev, and suffer the same glitches.
While ideally there is some kind ofhypervisor_opsto modify the protected register, at the very least there should be the genericdebug_writehandling the ?"I ?can write all PL310 regs" case. If you're interested I have a patch someplace that tried to do this, hopefully I can still find it.They are kind of generic. If you look at it, the only change Which is arch specific is the implementation of "
debug_writel" function. Today this code is not in generic PL310 code, but
OMAP specific.
Quoted 8 lines
May be we can make this as exported function pointer, which arch's can populate.
Will that work for you ?
Regards,
Santosh
Ie something like the following.... what do you think???
#define L2X0_DCR (0xF40)
static void debug_writel(unsigned long val)
{
#ifdef CONFIG_ARCH_OMAP4
omap_smc1(0x100, val);
#else
writel_relaxed(val, l2x0_base + L2X0_DCR);#endif
}
...
...
/* clean all ways */
spin_lock_irqsave(&l2x0_lock, flags);
#ifdef CONFIG_PL310_ERRATA_727915
debug_writel(DCR_DWB | DCR_DCL); <---- not 0x3, but self-documenting
#endif
writel_relaxed(l2x0_way_mask, l2x0_base + L2X0_CLEAN_INV_WAY);
cache_wait_way(l2x0_base + L2X0_CLEAN_INV_WAY, l2x0_way_mask);
cache_sync();
#ifdef CONFIG_PL310_ERRATA_727915
debug_writel(0x00);
#endif
spin_unlock_irqrestore(&l2x0_lock, flags);PATCH 3/5 ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
Quoted 56 lines
-----Original Message-----
From: Andrei Warkentin [mailto:andreiw at motorola.com]
Sent: Sunday, February 13, 2011 4:48 AM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; Kevin Hilman; tony at atomide.com; linux-arm-kernel at lists.infradead.org; Catalin Marinas
Subject: Re: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruptionQuoted 9 lines · Santosh Shilimkar
Quoted 9 lines
-----Original Message-----
From: Andrei Warkentin [mailto:andreiw at motorola.com]
Sent: Saturday, February 12, 2011 11:20 PM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; khilman at ti.com; tony at atomide.com; linux-arm-kernel at lists.infradead.org; Catalin Marinas
Subject: Re: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruptionQuoted 4 lines
[....]
Quoted 2 lines
Can these PL310 errata fixes be made more generic? PL310 is
present
Quoted 10 lines
Quoted 9 lines
in
non-OMAP platforms too, which lack the TI hypervisor. And these platforms might have the same PL310 rev, and suffer the same glitches.
While ideally there is some kind ofhypervisor_opsto modify the protected register, at the very least there should be the genericdebug_writehandling the ?"I ?can write all PL310 regs" case. If you're interested I have a patch someplace that tried to do this, hopefully I can still find it.Quoted 2 lines
They are kind of generic. If you look at it, the only change Which is arch specific is the implementation of "
debug_writel"function.
Quoted 11 lines
Today this code is not in generic PL310 code, but
OMAP specific.May be we can make this as exported function pointer, which arch's can populate.
Will that work for you ?
Regards,
SantoshIe something like the following.... what do you think???
#define
L2X0_DCR(0xF40)static void
debug_writel(unsigned long val)
{
Quoted 7 lines
#ifdef CONFIG_ARCH_OMAP4 omap_smc1(0x100, val); #else writel_relaxed(val, l2x0_base + L2X0_DCR);#endif
}
...
I understood that from first comment. But I am not in favor of polluting common ARM files with SOC specific #ifdeffery. We have gone over this when first errata support was added for PL310
I have a better way to handle this scenario.
Expect an updated patch for this.
Regards,
Santosh
PATCH 3/5 ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
Quoted 68 lines · Santosh Shilimkar
Quoted 54 lines
-----Original Message-----
From: Andrei Warkentin [mailto:andreiw at motorola.com]
Sent: Sunday, February 13, 2011 4:48 AM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; Kevin Hilman; tony at atomide.com; linux-arm-kernel at lists.infradead.org; Catalin Marinas
Subject: Re: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruptionQuoted 9 lines · Santosh Shilimkar
Quoted 9 lines
-----Original Message-----
From: Andrei Warkentin [mailto:andreiw at motorola.com]
Sent: Saturday, February 12, 2011 11:20 PM
To: Santosh Shilimkar
Cc: linux-omap at vger.kernel.org; khilman at ti.com; tony at atomide.com; linux-arm-kernel at lists.infradead.org; Catalin Marinas
Subject: Re: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruptionQuoted 4 lines
[....]
Quoted 2 lines
Can these PL310 errata fixes be made more generic? PL310 is
present
Quoted 10 lines
Quoted 9 lines
in
non-OMAP platforms too, which lack the TI hypervisor. And these platforms might have the same PL310 rev, and suffer the same glitches.
While ideally there is some kind ofhypervisor_opsto modify the protected register, at the very least there should be the genericdebug_writehandling the ?"I ?can write all PL310 regs" case. If you're interested I have a patch someplace that tried to do this, hopefully I can still find it.Quoted 2 lines
They are kind of generic. If you look at it, the only change Which is arch specific is the implementation of "
debug_writel"function.
Quoted 11 lines
Today this code is not in generic PL310 code, but
OMAP specific.May be we can make this as exported function pointer, which arch's can populate.
Will that work for you ?
Regards,
SantoshIe something like the following.... what do you think???
#define
L2X0_DCR(0xF40)Quoted 9 lines
static void
debug_writel(unsigned long val)
{
#ifdefCONFIG_ARCH_OMAP4
? ? ? ?omap_smc1(0x100, val);
#else
? ? ? ?writel_relaxed(val,l2x0_base+L2X0_DCR);
#endif
}
...I understood that from first comment. But I am not in favor of polluting common ARM files with SOC specific #ifdeffery. We have gone over this when first errata support was added for PL310
Quoted 6 lines
I have a better way to handle this scenario.
Expect an updated patch for this.Regards,
Santosh
Fair enough, but you're doing it right now :-). I believe the smarter approach would be to start abstracting all accesses to secure-only resources (like the DCR reg). This would be your "hypervisor" interface. Then provide an implementation for your TI secure monitor. Obviously over time :).
PATCH 3/5 ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
Quoted 7 lines · Andrei Warkentin
Fair enough, but you're doing it right now :-). I believe the smarter approach would be to start abstracting all accesses to secure-only resources (like the DCR reg). This would be your "hypervisor" interface. Then provide an implementation for your TI secure monitor. Obviously over time :).
Santosh,
Maybe this can influence you in some ways. I have this old patch sitting around, although it does #ifdef around the TI stuff, simply because I wasn't really interested in moving it out.
I group the errata by revs so it's simpler to see what you need and what you don't. Obviously there aren't that many, but it does provide a pattern to follow...
Thanks,
A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ARM-PL310-Cleanup-errata-handling-for-cache-controll.patch
Type: text/x-diff
Size: 9798 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110214/842681d4/attachment-0001.bin>
PATCH 3/5 ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
In reply to Santosh ShilimkarQuoted 9 lines
-----Original Message-----
From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
Sent: Monday, February 14, 2011 10:39 AM
To: Andrei Warkentin
Cc: linux-omap at vger.kernel.org; Kevin Hilman; tony at atomide.com; linux-arm-kernel at lists.infradead.org; Catalin Marinas
Subject: RE: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
[....]
Quoted 9 lines
Quoted 1 line
...
I understood that from first comment. But I am not in favor of polluting common ARM files with SOC specific #ifdeffery. We have gone over this when first errata support was added for PL310
I have a better way to handle this scenario.
Expect an updated patch for this.
Below is the updated version which should remove any OMAP dependency on these errata's. Attached same.
----
From: Santosh Shilimkar <[email protected]>
Date: Fri, 14 Jan 2011 14:16:04 +0530
Subject: [v2 PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
PL310 implements the Clean & Invalidate by Way L2 cache maintenance operation (offset 0x7FC). This operation runs in background so that PL310 can handle normal accesses while it is in progress. Under very rare circumstances, due to this erratum, write data can be lost when PL310 treats a cacheable write transaction during a Clean & Invalidate by Way operation.
Workaround:
Disable Write-Back and Cache Linefill (Debug Control Register) Clean & Invalidate by Way (0x7FC)
Re-enable Write-Back and Cache Linefill (Debug Control Register)
--- arch/arm/Kconfig | 13 ++++++++++++- arch/arm/include/asm/outercache.h | 1 + arch/arm/mach-omap2/Kconfig | 3 +++ arch/arm/mach-omap2/omap4-common.c | 7 +++++++ arch/arm/mm/cache-l2x0.c | 28 +++++++++++++++------------- 5 files changed, 38 insertions(+), 14 deletions(-)
arch/arm/Kconfig +0 -0
@@ -1140,7 +1140,7 @@ config ARM_ERRATA_742231 config PL310_ERRATA_588369 bool "Clean & Invalidate maintenance operations do not invalidate
clean lines"
- depends on CACHE_L2X0 && ARCH_OMAP4
+ depends on CACHE_L2X0 && CACHE_PL310
help
The PL310 L2 cache controller implements three types of Clean & Invalidate maintenance operations: by Physical Address
@@ -1177,6 +1177,17 @@ config ARM_ERRATA_743622
visible impact on the overall performance or power consumption
of the
processor.
+config PL310_ERRATA_727915
+ bool "Background Clean & Invalidate by Way operation can cause
data corruption"
+ depends on CACHE_L2X0 && CACHE_PL310
+ help
+ PL310 implements the Clean & Invalidate by Way L2 cache
maintenance
+ operation (offset 0x7FC). This operation runs in background so
that
+ PL310 can handle normal accesses while it is in progress. Under
very
+ rare circumstances, due to this erratum, write data can be lost
when
+ PL310 treats a cacheable write transaction during a Clean & + Invalidate by Way operation Note that this errata uses Texas + Instrument's secure monitor api to implement the work around.
endmenu
source "arch/arm/common/Kconfig"
(quoted diff) +0 -0
b/arch/arm/include/asm/outercache.h
index fc19009..348d513 100644
arch/arm/include/asm/outercache.h +1 -0
@@ -31,6 +31,7 @@ struct outer_cache_fns {#ifdef CONFIG_OUTER_CACHE_SYNC void (*sync)(void );#endif +void (*set_debug)(unsigned long ); };#ifdef CONFIG_OUTER_CACHE
arch/arm/mach-omap2/Kconfig +3 -0
@@ -45,7 +45,10 @@ config ARCH_OMAP4 select CPU_V7 select ARM_GIC select LOCAL_TIMERS + select CACHE_L2X0 + select CACHE_PL310 select PL310_ERRATA_588369 + select PL310_ERRATA_727915 select ARM_ERRATA_720789 select ARCH_HAS_OPP select PM_OPP if PM
(quoted diff) +0 -0
b/arch/arm/mach-omap2/omap4-common.c
index 1926864..9ef8c29 100644
arch/arm/mach-omap2/omap4-common.c +7 -0
@@ -52,6 +52,12 @@ static void omap4_l2x0_disable(void)omap_smc1 (0x102 ,0x0 ); } +static void omap4_l2x0_set_debug (unsigned long val) +{ +/* Program PL310 L2 Cache controller debug register */ +omap_smc1 (0x100 , val); +} +static int __init omap_l2_cache_init (void ) {u32 aux_ctrl =0 ;
@@ -99,6 +105,7 @@ static int __init omap_l2_cache_init(void)* specific one */ outer_cache.disable = omap4_l2x0_disable; + outer_cache.set_debug = omap4_l2x0_set_debug;return 0 ; }
arch/arm/mm/cache-l2x0.c +1 -1
@@ -67,18 +67,22 @@ static inline void l2x0_inv_line(unsigned long addr)writel_relaxed (addr, base +L2X0_INV_LINE_PA ); } -#ifdef CONFIG_PL310_ERRATA_588369 +#if defined(CONFIG_PL310_ERRATA_588369) ||
defined(CONFIG_PL310_ERRATA_727915)
static void debug_writel(unsigned long val) {
- extern void omap_smc1(u32 fn, u32 arg);
-
- /*
- * Texas Instrument secure monitor api to modify the
- * PL310 Debug Control Register.
- */
- omap_smc1(0x100, val);
+ if (outer_cache.set_debug)
+ outer_cache.set_debug(val);
+ else
+ writel(val, l2x0_base + L2X0_DEBUG_CTRL);
+}
+#else
+/* Optimised out for non-errata case */ +static inline void debug_writel(unsigned long val) +{
}
+#endif
+#ifdef CONFIG_PL310_ERRATA_588369
static inline void l2x0_flush_line(unsigned long addr)
{
void __iomem *base = l2x0_base;
@@ -91,11 +95,6 @@ static inline void l2x0_flush_line(unsigned long addr)
}
#else
-/* Optimised out for non-errata case */ -static inline void debug_writel(unsigned long val) -{
-}
-
static inline void l2x0_flush_line(unsigned long addr) {
void __iomem *base = l2x0_base;
@@ -119,9 +118,11 @@ static void l2x0_flush_all(void)
/* clean all ways */
spin_lock_irqsave(&l2x0_lock, flags);
+ debug_writel(0x03);
writel_relaxed(l2x0_way_mask, l2x0_base + L2X0_CLEAN_INV_WAY); cache_wait_way(l2x0_base + L2X0_CLEAN_INV_WAY, l2x0_way_mask); cache_sync();
+ debug_writel(0x00);
spin_unlock_irqrestore(&l2x0_lock, flags);
}
@@ -329,6 +330,7 @@ void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
outer_cache.flush_all = l2x0_flush_all; outer_cache.inv_all = l2x0_inv_all; outer_cache.disable = l2x0_disable;
+ outer_cache.set_debug = NULL;
printk(KERN_INFO "%s cache controller enabled\n", type); printk(KERN_INFO "l2x0: %d ways, CACHE_ID 0x%08x, AUX_CTRL 0x%08x,
Cache size: %d B\n",
Signature · 8 lines
1.6.0.4 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-ARM-l2x0-Errata-fix-for-flush-by-Way-operation-can.patch Type: application/octet-stream Size: 6061 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110215/2e6980b7/attachment-0001.obj>
PATCH 3/5 ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
Quoted 213 lines · Santosh Shilimkar
Quoted 9 lines
-----Original Message-----
From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
Sent: Monday, February 14, 2011 10:39 AM
To: Andrei Warkentin
Cc: linux-omap at vger.kernel.org; Kevin Hilman; tony at atomide.com; linux-arm-kernel at lists.infradead.org; Catalin Marinas
Subject: RE: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruption[....]
Quoted 9 lines
Quoted 1 line
...
I understood that from first comment. But I am not in favor of polluting common ARM files with SOC specific #ifdeffery. We have gone over this when first errata support was added for PL310
I have a better way to handle this scenario.
Expect an updated patch for this.Below is the updated version which should remove any OMAP dependency on these errata's. Attached same.
----
From: Santosh Shilimkar <[email protected]>
Date: Fri, 14 Jan 2011 14:16:04 +0530
Subject: [v2 PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruptionPL310 implements the Clean & Invalidate by Way L2 cache maintenance operation (offset
0x7FC). This operation runs in background so that PL310 can handle normal accesses while it is in progress. Under very rare circumstances, due to this erratum, write data can be lost when PL310 treats a cacheable write transaction during a Clean & Invalidate by Way operation.Workaround:
Disable Write-Back and Cache Linefill (Debug Control Register) Clean & Invalidate by Way (0x7FC)
Re-enable Write-Back and Cache Linefill (Debug Control Register)Signed-off-by Santosh Shilimkar <[email protected]>Cc Catalin Marinas <[email protected]>---
?arch/arm/Kconfig ? ? ? ? ? ? ? ? ? | ? 13 ++++++++++++- ?arch/arm/include/asm/outercache.h ?| ? ?1 + ?arch/arm/mach-omap2/Kconfig ? ? ? ?| ? ?3 +++ ?arch/arm/mach-omap2/omap4-common.c | ? ?7 +++++++ ?arch/arm/mm/cache-l2x0.c ? ? ? ? ? | ? 28 +++++++++++++++-------------?5 files changed, 38 insertions(+), 14 deletions(-)
arch/arm/Kconfig +0
-0@@ -1140,7 +1140,7 @@ config ARM_ERRATA_742231?config
PL310_ERRATA_588369
? ? ? ?bool "Clean & Invalidate maintenance operations do not invalidate clean lines"
- ? ? ? depends onCACHE_L2X0&&ARCH_OMAP4
+ ? ? ? depends onCACHE_L2X0&&CACHE_PL310
? ? ? ?help
? ? ? ? ? The PL310 L2 cache controller implements three types of Clean & ? ? ? ? ? Invalidate maintenance operations: by Physical Addressarch/arm/Kconfig +0
-0@@ -1177,6 +1177,17 @@ config ARM_ERRATA_743622? ? ? ? ?visible impact on the overall performance or power consumption of the
? ? ? ? ?processor.+config
PL310_ERRATA_727915
+ ? ? ? bool "Background Clean & Invalidate by Way operation can cause data corruption"
+ ? ? ? depends onCACHE_L2X0&&CACHE_PL310
+ ? ? ? help
+ ? ? ? ? PL310 implements the Clean & Invalidate by Way L2 cache maintenance
+ ? ? ? ? operation (offset0x7FC). This operation runs in background so that
+ ? ? ? ? PL310 can handle normal accesses while it is in progress. Under very
+ ? ? ? ? rare circumstances, due to this erratum, write data can be lost when
+ ? ? ? ? PL310 treats a cacheable write transaction during a Clean &
+ ? ? ? ? Invalidate by Way operation Note that this errata uses Texas
+ ? ? ? ? Instrument's secure monitor api to implement the work around. ?endmenu?source "
arch/arm/common/Kconfig"arch/arm/include/asm/outercache.h +0
-0@@ -31,6 +31,7 @@ struct outer_cache_fns {?#ifdef
CONFIG_OUTER_CACHE_SYNC
? ? ? ?void (*sync)(void);
?#endif
+ ? ? ? void (*set_debug)(unsigned long);
?};?#ifdef
CONFIG_OUTER_CACHEarch/arm/mach-omap2/Kconfig +0
-0@@ -45,7 +45,10 @@ config ARCH_OMAP4? ? ? ?select
CPU_V7
? ? ? ?selectARM_GIC
? ? ? ?selectLOCAL_TIMERS
+ ? ? ? selectCACHE_L2X0
+ ? ? ? selectCACHE_PL310
? ? ? ?selectPL310_ERRATA_588369
+ ? ? ? selectPL310_ERRATA_727915
? ? ? ?selectARM_ERRATA_720789
? ? ? ?selectARCH_HAS_OPP
? ? ? ?selectPM_OPPif PMarch/arm/mach-omap2/omap4-common.c +6
-0@@ -52,6 +52,12 @@ static void omap4_l2x0_disable(void) ? ? ? ?omap_smc1(0x102, 0x0); ?} +static void omap4_l2x0_set_debug (unsigned long val) +{ + ? ? ? /* Program PL310 L2 Cache controller debug register */ + ? ? ? omap_smc1(0x100, val); +} + ?static int __init omap_l2_cache_init(void) ?{ ? ? ? ?u32 aux_ctrl = 0;@@ -99,6 +105,7 @@ static int __init omap_l2_cache_init(void)? ? ? ? * specific one
? ? ? ?*/
? ? ? ?outer_cache.disable =omap4_l2x0_disable;
+ ? ? ? outer_cache.set_debug =omap4_l2x0_set_debug;? ? ? ?return 0;
?}arch/arm/mm/cache-l2x0.c +12
-8@@ -67,18 +67,22 @@ static inline void l2x0_inv_line(unsigned long addr) ? ? ? ?writel_relaxed(addr, base + L2X0_INV_LINE_PA); ?} -#ifdef CONFIG_PL310_ERRATA_588369 +#if defined(CONFIG_PL310_ERRATA_588369 ) || defined(CONFIG_PL310_ERRATA_727915 ) ?static void debug_writel(unsigned long val) ?{ - ? ? ? extern void omap_smc1(u32 fn, u32 arg); - - ? ? ? /* - ? ? ? ?* Texas Instrument secure monitor api to modify the - ? ? ? ?* PL310 Debug Control Register. - ? ? ? ?*/ - ? ? ? omap_smc1(0x100, val); + ? ? ? if (outer_cache.set_debug) + ? ? ? ? ? ? ? outer_cache.set_debug(val); + ? ? ? else + ? ? ? ? ? ? ? writel(val, l2x0_base + L2X0_DEBUG_CTRL); +} +#else +/* Optimised out for non-errata case */ +static inline void debug_writel (unsigned long val) +{ ?} +#endif +#ifdef CONFIG_PL310_ERRATA_588369 ?static inline void l2x0_flush_line(unsigned long addr) ?{? ? ? ?void
__iomem*base =l2x0_base;arch/arm/mm/cache-l2x0.c +0
-0@@ -91,11 +95,6 @@ static inline void l2x0_flush_line(unsigned long addr) ?}?#else
arch/arm/mm/cache-l2x0.c +0
-5-/* Optimised out for non-errata case */ -static inline void debug_writel (unsigned long val) -{ -} -?static inline void
l2x0_flush_line(unsigned long addr)?{
? ? ? ?void__iomem*base =l2x0_base;arch/arm/mm/cache-l2x0.c +0
-0@@ -119,9 +118,11 @@ static void l2x0_flush_all(void)? ? ? ?/* clean all ways */
? ? ? ?spin_lock_irqsave(&l2x0_lock, flags);
+ ? ? ?debug_writel(0x03);
? ? ? ?writel_relaxed(l2x0_way_mask,l2x0_base+L2X0_CLEAN_INV_WAY); ? ? ? ?cache_wait_way(l2x0_base +L2X0_CLEAN_INV_WAY,l2x0_way_mask); ? ? ? ?cache_sync();
+ ? ? ?debug_writel(0x00);
? ? ? ?spin_unlock_irqrestore(&l2x0_lock, flags);
?}arch/arm/mm/cache-l2x0.c +1
-0@@ -329,6 +330,7 @@ void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask) ? ? ? ?outer_cache.flush_all = l2x0_flush_all; ? ? ? ?outer_cache.inv_all = l2x0_inv_all; ? ? ? ?outer_cache.disable = l2x0_disable; + ? ? ? outer_cache.set_debug = NULL; ? ? ? ?printk(KERN_INFO "%s cache controller enabled\n", type);
Quoted 5 lines
? ? ? ?printk(KERN_INFO "l2x0: %d ways,
CACHE_ID0x%08x,AUX_CTRL0x%08x, Cache size: %d B\n",
--
1.6.0.4
Why set by default to NULL, why not have a normal l2x0_set_debug which just does a write to L2X0_DEBUG_CTRL, and then just invoke the function pointer when you wish to manipulate the DCR? That way you don't need the runtime check, and it's just clearer, I think.
Also, why not do something like -
....do_stuff();
#ifdef CONFIG_NEED_ERRATA_1234do_errata_stuff();
#endifdo_more_stuff();
...
instead of -
...
#ifdef CONFIG_NEED_ERRATA_1234do_some_stuf() {bar();
}
#else
{do_some_stuff() {
}
// nothing
}
do_stuff();do_some_stuff();do_more_stuff();
It's not exactly clear otherwise what's happening and why there are these extra calls that sometimes are compiled in, and sometimes aren't. The way I am suggesting, you would just look at a function block and you can easily tell what is different in the errata case, and you don't need to jump back and forth to figure that out. I think it makes for cleaner code.
And it would be nice if the errata had some revision data attached to them, as in my suggestion patch I sent earlier. It's a nuisance to look at Kconfig wondering which errata you might be interested in, especially if your platform spans several generations and revs of different parts. Then you need to dig up an errata sheet and scan it yourself. The alternative is to be able to select a known rev for PL310, for example, which would just pick the errata that apply to that rev, or at least mention the affected revs in the documentation for the option.
PATCH 3/5 ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
Quoted 22 lines
-----Original Message-----
From: Andrei Warkentin [mailto:andreiw at motorola.com]
Sent: Tuesday, February 15, 2011 2:40 PM
To: Santosh Shilimkar
Cc: linux-arm-kernel at lists.infradead.org; linux-
omap at vger.kernel.org; Kevin Hilman; tony at atomide.com; Catalin Marinas
Subject: Re: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruptionQuoted 10 lines · Santosh Shilimkar
Quoted 9 lines
-----Original Message-----
From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
Sent: Monday, February 14, 2011 10:39 AM
To: Andrei Warkentin
Cc: linux-omap at vger.kernel.org; Kevin Hilman; tony at atomide.com; linux-arm-kernel at lists.infradead.org; Catalin Marinas
Subject: RE: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
[....]
Quoted 8 lines
Quoted 1 line
Why set by default to NULL, why not have a normal
l2x0_set_debugwhich
just does a write toL2X0_DEBUG_CTRL, and then just invoke the function pointer when you wish to manipulate the DCR? That way you don't need the runtime check, and it's just clearer, I think.
I though about it. There more changes in the file and hence I avoided it. This can be done though.
Quoted 9 lines
Also, why not do something like -
....do_stuff();
#ifdefCONFIG_NEED_ERRATA_1234do_errata_stuff();
#endifdo_more_stuff();
...
Which makes code completely ugly.
Quoted 14 lines
instead of -
...
#ifdefCONFIG_NEED_ERRATA_1234do_some_stuf(){bar();
}
#else
{do_some_stuff(){
}
// nothing
}
We have already discussed this. The code becomes ugly. If you are interested in the reasoning, please check archives.
Russell and Catalin has suggested above.
If you understand the errata in first place, you could understand the comment.
I let Catalin, Russell comment on it more, but unnecessary CONFIG options and polluting every function with #If, else checks don't make sense. Rest of your comments are related to this.
Regards,
Santosh
PATCH 3/5 ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
In reply to Santosh ShilimkarCatalin,
Quoted 49 lines
-----Original Message-----
From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
Sent: Tuesday, February 15, 2011 12:44 PM
To: linux-arm-kernel at lists.infradead.org; Andrei Warkentin
Cc: linux-omap at vger.kernel.org; Kevin Hilman; tony at atomide.com; Catalin Marinas
Subject: RE: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruptionQuoted 9 lines
-----Original Message-----
From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
Sent: Monday, February 14, 2011 10:39 AM
To: Andrei Warkentin
Cc: linux-omap at vger.kernel.org; Kevin Hilman; tony at atomide.com; linux-arm-kernel at lists.infradead.org; Catalin Marinas
Subject: RE: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruption[....]
Quoted 9 lines
Quoted 1 line
...
I understood that from first comment. But I am not in favor of polluting common ARM files with SOC specific #ifdeffery. We have gone over this when first errata support was added for PL310
I have a better way to handle this scenario.
Expect an updated patch for this.Below is the updated version which should remove any OMAP dependency on these errata's. Attached same.
----
From: Santosh Shilimkar <[email protected]>
Date: Fri, 14 Jan 2011 14:16:04 +0530
Subject: [v2 PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation
can cause data corruptionPL310 implements the Clean & Invalidate by Way L2 cache maintenance operation (offset
0x7FC). This operation runs in background so that PL310 can handle normal accesses while it is in progress. Under very rare circumstances, due to this erratum, write data can be lost when PL310 treats a cacheable write transaction during a Clean & Invalidate
by Way operation.
Quoted 8 lines
Workaround:
Disable Write-Back and Cache Linefill (Debug Control Register) Clean & Invalidate by Way (0x7FC)
Re-enable Write-Back and Cache Linefill (Debug Control Register)Signed-off-by Santosh Shilimkar <[email protected]>Cc Catalin Marinas <[email protected]>---
Ack , Nak ?
Quoted 183 lines
arch/arm/Kconfig | 13 ++++++++++++- arch/arm/include/asm/outercache.h | 1 + arch/arm/mach-omap2/Kconfig | 3 +++ arch/arm/mach-omap2/omap4-common.c | 7 +++++++ arch/arm/mm/cache-l2x0.c | 28 +++++++++++++++---------- --- 5 files changed, 38 insertions(+), 14 deletions(-)arch/arm/Kconfig +0
-0@@ -1140,7 +1140,7 @@ config ARM_ERRATA_742231 config PL310_ERRATA_588369 bool "Clean & Invalidate maintenance operations do notinvalidate
clean lines"arch/arm/Kconfig +1
-1- depends on CACHE_L2X0 && ARCH_OMAP4 + depends on CACHE_L2X0 && CACHE_PL310 help The PL310 L2 cache controller implements three types ofClean &
arch/arm/Kconfig +0
-0Invalidate maintenance operations: by Physical Address@@ -1177,6 +1177,17 @@ config ARM_ERRATA_743622 visible impact on the overall performance or powerconsumption
of thearch/arm/Kconfig +2
-0processor. +config PL310_ERRATA_727915 + bool "Background Clean & Invalidate by Way operation can causedata corruption"
arch/arm/Kconfig +3
-0+ depends on CACHE_L2X0 && CACHE_PL310 + help + PL310 implements the Clean & Invalidate by Way L2 cachemaintenance
arch/arm/Kconfig +1
-0+ operation (offset 0x7FC). This operation runs in backgroundso
thatarch/arm/Kconfig +1
-0+ PL310 can handle normal accesses while it is in progress.Under
veryarch/arm/Kconfig +1
-0+ rare circumstances, due to this erratum, write data can belost
whenarch/arm/Kconfig +3
-0+ PL310 treats a cacheable write transaction during a Clean & + Invalidate by Way operation Note that this errata uses Texas + Instrument's secure monitor api to implement the workaround.
endmenusource "
arch/arm/common/Kconfig"arch/arm/include/asm/outercache.h +1
-0@@ -31,6 +31,7 @@ struct outer_cache_fns {#ifdef CONFIG_OUTER_CACHE_SYNC void (*sync)(void );#endif +void (*set_debug)(unsigned long ); };#ifdef CONFIG_OUTER_CACHE arch/arm/mach- renamed from arch/arm/mach-omap2/Kconfig +0
-0omap2/Kconfig
index f285dd7..fd11ab4 100644arch/arm/mach-omap2/Kconfig +3
-0@@ -45,7 +45,10 @@ config ARCH_OMAP4 select CPU_V7 select ARM_GIC select LOCAL_TIMERS + select CACHE_L2X0 + select CACHE_PL310 select PL310_ERRATA_588369 + select PL310_ERRATA_727915 select ARM_ERRATA_720789 select ARCH_HAS_OPP select PM_OPP if PMarch/arm/mach-omap2/omap4-common.c +7
-0@@ -52,6 +52,12 @@ static void omap4_l2x0_disable(void)omap_smc1 (0x102 ,0x0 ); } +static void omap4_l2x0_set_debug (unsigned long val) +{ +/* Program PL310 L2 Cache controller debug register */ +omap_smc1 (0x100 , val); +} +static int __init omap_l2_cache_init (void ) {u32 aux_ctrl =0 ;@@ -99,6 +105,7 @@ static int __init omap_l2_cache_init(void)* specific one */ outer_cache.disable = omap4_l2x0_disable; + outer_cache.set_debug = omap4_l2x0_set_debug;return 0 ; }arch/arm/mm/cache-l2x0.c +12
-8@@ -67,18 +67,22 @@ static inline void l2x0_inv_line(unsigned long addr) writel_relaxed(addr, base + L2X0_INV_LINE_PA); } -#ifdef CONFIG_PL310_ERRATA_588369 +#if defined(CONFIG_PL310_ERRATA_588369 ) || defined(CONFIG_PL310_ERRATA_727915 )static void debug_writel (unsigned long val) { -extern void omap_smc1 (u32 fn,u32 arg); - -/* -* Texas Instrument secure monitor api to modify the -* PL310 Debug Control Register. -*/ -omap_smc1 (0x100 , val); +if (outer_cache.set_debug) + outer_cache.set_debug (val); +else +writel (val, l2x0_base +L2X0_DEBUG_CTRL ); +} +#else +/* Optimised out for non-errata case */ +static inline void debug_writel (unsigned long val) +{ } +#endif +#ifdef CONFIG_PL310_ERRATA_588369 static inline void l2x0_flush_line (unsigned long addr){
arch/arm/mm/cache-l2x0.c +0
-5void __iomem *base = l2x0_base;@@ -91,11 +95,6 @@ static inline void l2x0_flush_line(unsigned long addr) }#else -/* Optimised out for non-errata case */ -static inline void debug_writel (unsigned long val) -{ -} -static inline void l2x0_flush_line (unsigned long addr) {arch/arm/mm/cache-l2x0.c +3
-0void __iomem *base = l2x0_base;@@ -119,9 +118,11 @@ static void l2x0_flush_all(void)/* clean all ways */ spin_lock_irqsave (&l2x0_lock, flags); +debug_writel (0x03 );writel_relaxed (l2x0_way_mask, l2x0_base +L2X0_CLEAN_INV_WAY );cache_wait_way (l2x0_base +L2X0_CLEAN_INV_WAY , l2x0_way_mask);cache_sync (); +debug_writel (0x00 );spin_unlock_irqrestore (&l2x0_lock, flags); }@@ -329,6 +330,7 @@ void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask) outer_cache.flush_all = l2x0_flush_all; outer_cache.inv_all = l2x0_inv_all; outer_cache.disable = l2x0_disable; + outer_cache.set_debug =NULL ;printk (KERN_INFO "%s cache controller enabled\n" , type);printk(KERN_INFO "l2x0: %d ways,
CACHE_ID0x%08x,AUX_CTRL
0x%08x,
Cache size: %d B\n",
--
1.6.0.4
PATCH 3/5 ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
In reply to Santosh ShilimkarQuoted 9 lines · Santosh Shilimkar
arch/arm/Kconfig +0
-0@@ -1140,7 +1140,7 @@ config ARM_ERRATA_742231?config
PL310_ERRATA_588369
? ? ? ?bool "Clean & Invalidate maintenance operations do not invalidate clean lines"
- ? ? ? depends onCACHE_L2X0&&ARCH_OMAP4
+ ? ? ? depends onCACHE_L2X0&&CACHE_PL310
It can just depend on CACHE_PL310 as this depends on CACHE_L2X0.
Quoted 4 lines
+config
PL310_ERRATA_727915
+ ? ? ? bool "Background Clean & Invalidate by Way operation can cause data corruption"
+ ? ? ? depends onCACHE_L2X0&&CACHE_PL310
Same here.
Quoted 7 lines
arch/arm/mach-omap2/Kconfig +0
-0@@ -45,7 +45,10 @@ config ARCH_OMAP4? ? ? ?select
CPU_V7
? ? ? ?selectARM_GIC
? ? ? ?selectLOCAL_TIMERS
+ ? ? ? selectCACHE_L2X0
CACHE_L2X0 has a long dependency list. You could add ARCH_OMAP4 in there or just change the other platforms to select a HAVE_CACHE_L2X0. Ideally we would like this option to be selectable in config just in case you want to debug some issues.
arch/arm/mach-omap2/omap4-common.c static void omap4_l2x0_disable(void) · line 59
Quoted 11 lines
arch/arm/mach-omap2/omap4-common.c +5
-0@@ -52,6 +52,12 @@ static void omap4_l2x0_disable(void) ? ? ? ?omap_smc1(0x102, 0x0); ?} +static void omap4_l2x0_set_debug (unsigned long val) +{ + ? ? ? /* Program PL310 L2 Cache controller debug register */ + ? ? ? omap_smc1(0x100, val); +}
This part together with the Kconfig changes for OMAP4 could be a separate patch, OMAP-specific.
The rest seems fine.
Signature · 1 line
Catalin
PATCH 3/5 ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
Quoted 16 lines
-----Original Message-----
From: catalin.marinas at gmail.com [mailto:catalin.marinas at gmail.com] On Behalf Of Catalin Marinas
Sent: Wednesday, February 16, 2011 9:24 PM
To: Santosh Shilimkar
Cc: linux-arm-kernel at lists.infradead.org; Andrei Warkentin; Kevin Hilman; tony at atomide.com; linux-omap at vger.kernel.org
Subject: Re: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruptionQuoted 4 lines · Santosh Shilimkar
arch/arm/Kconfig +0
-0@@ -1140,7 +1140,7 @@ config ARM_ERRATA_742231
Quoted 9 lines
Quoted 2 lines
?config
PL310_ERRATA_588369
? ? ? ?bool "Clean & Invalidate maintenance operations do notinvalidate
Quoted 3 lines
clean lines"
- ? ? ? depends onCACHE_L2X0&&ARCH_OMAP4
+ ? ? ? depends onCACHE_L2X0&&CACHE_PL310It can just depend on
CACHE_PL310as this depends onCACHE_L2X0.
Ok.
Quoted 8 lines
Quoted 2 lines
+config
PL310_ERRATA_727915
+ ? ? ? bool "Background Clean & Invalidate by Way operation cancause
Quoted 2 lines
data corruption"
+ ? ? ? depends onCACHE_L2X0&&CACHE_PL310Same here.
Quoted 14 lines
Quoted 7 lines
arch/arm/mach-omap2/Kconfig +0
-0@@ -45,7 +45,10 @@ config ARCH_OMAP4? ? ? ?select
CPU_V7
? ? ? ?selectARM_GIC
? ? ? ?selectLOCAL_TIMERS
+ ? ? ? selectCACHE_L2X0
CACHE_L2X0has a long dependency list. You could addARCH_OMAP4in there or just change the other platforms to select aHAVE_CACHE_L2X0.
Ideally we would like this option to be selectable in config just in case you want to debug some issues.
I will add ARCH_OMAP4 under CACHE_L2X0.
Quoted 6 lines
Quoted 6 lines
arch/arm/mach-omap2/omap4-common.c +0
-0@@ -52,6 +52,12 @@ static void omap4_l2x0_disable(void) ? ? ? ?omap_smc1(0x102, 0x0); ?}
Quoted 9 lines
arch/arm/mach-omap2/omap4-common.c static void omap4_l2x0_disable(void) · line 59
Quoted 5 lines
arch/arm/mach-omap2/omap4-common.c +5
-0+static void omap4_l2x0_set_debug (unsigned long val) +{ + ? ? ? /* Program PL310 L2 Cache controller debug register */ + ? ? ? omap_smc1(0x100, val); +}This part together with the
Kconfigchanges for OMAP4 could be a separate patch, OMAP-specific.
Agree. I will split this patch and repost.
Quoted 1 line
The rest seems fine.
Thanks for the feedback.
Regards,
Santosh
PATCH 3/5 ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
In reply to Catalin MarinasQuoted 16 lines
-----Original Message-----
From: catalin.marinas at gmail.com [mailto:catalin.marinas at gmail.com] On Behalf Of Catalin Marinas
Sent: Wednesday, February 16, 2011 9:24 PM
To: Santosh Shilimkar
Cc: linux-arm-kernel at lists.infradead.org; Andrei Warkentin; Kevin Hilman; tony at atomide.com; linux-omap at vger.kernel.org
Subject: Re: [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruptionQuoted 4 lines · Santosh Shilimkar
arch/arm/Kconfig +0
-0@@ -1140,7 +1140,7 @@ config ARM_ERRATA_742231
Quoted 9 lines
Quoted 2 lines
?config
PL310_ERRATA_588369
? ? ? ?bool "Clean & Invalidate maintenance operations do notinvalidate
Quoted 3 lines
clean lines"
- ? ? ? depends onCACHE_L2X0&&ARCH_OMAP4
+ ? ? ? depends onCACHE_L2X0&&CACHE_PL310It can just depend on
CACHE_PL310as this depends onCACHE_L2X0.
With CACHE_PL310 alone, I get below warning.
warning: (ARCH_OMAP4) selects PL310_ERRATA_588369 which has unmet direct dependencies (CACHE_PL310)
This is coming because Pl310 can't be selected on V6 and OMAP common build has V6 and V7 both enabled.
So to avoid the warning and also able to select the errata in OMAP build, I am making the errata's depends on CACHE_L2X0 with comment.
Regards,
Santosh
PATCH 4/5 omap2plus: omap4: Set NR_CPU to 2 instead of default 4
In reply to Santosh ShilimkarThe omap2plus_defconfig picks default NR_CPU value as 4 which isn't correct for OMAP4430. Available CPUs are ony 2, so fix the same.
--- arch/arm/configs/omap2plus_defconfig | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
arch/arm/configs/omap2plus_defconfig +1 -0
@@ -58,6 +58,7 @@ CONFIG_ARM_ERRATA_411920=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_SMP=y +CONFIG_NR_CPUS=2 # CONFIG_LOCAL_TIMERS is not set CONFIG_AEABI=y CONFIG_LEDS=y
Signature · 1 line
1.6.0.4
Tony Lindgren
maintainerPATCH 4/5 omap2plus: omap4: Set NR_CPU to 2 instead of default 4
Quoted 2 lines · Santosh Shilimkar
The
omap2plus_defconfigpicks defaultNR_CPUvalue as 4 which isn't correct for OMAP4430. Available CPUs are ony 2, so fix the same.
I'll queue this for the upcoming merge window.
Tony
PATCH 5/5 omap4: Remove 'FIXME: omap44xx_sram_init not implemented'
In reply to Santosh ShilimkarThe omap44xx_sram_init() implements functionality to push some code on SRAM whenever the code can't be executed from external memory. The low power and DVFS code can be executed from external DDR itself thanks to OMAP4 memory controller hardware support. So on OMAP4, sram_push kind of functionality isn't needed.
Hence remove the FIXME warning added for implementing sram push feature on OMAP4.
--- arch/arm/plat-omap/sram.c | 16 ---------------- 1 files changed, 0 insertions(+), 16 deletions(-)
arch/arm/plat-omap/sram.c +0 -16
@@ -405,20 +405,6 @@ static inline int omap34xx_sram_init(void) }#endif -#ifdef CONFIG_ARCH_OMAP4 -static int __init omap44xx_sram_init (void ) -{ -printk (KERN_ERR "FIXME: %s not implemented\n" , __func__); - -return -ENODEV ; -} -#else -static inline int omap44xx_sram_init (void ) -{ -return 0 ; -} -#endif -int __init omap_sram_init (void ) {omap_detect_sram ();
@@ -432,8 +418,6 @@ int __init omap_sram_init(void)omap243x_sram_init (); else if (cpu_is_omap34xx()) omap34xx_sram_init(); - else if (cpu_is_omap44xx()) - omap44xx_sram_init();return 0 ; }
Signature · 1 line
1.6.0.4
Tony Lindgren
maintainerPATCH 5/5 omap4: Remove 'FIXME: omap44xx_sram_init not implemented'
Quoted 8 lines · Santosh Shilimkar
The
omap44xx_sram_init()implements functionality to push some code on SRAM whenever the code can't be executed from external memory. The low power and DVFS code can be executed from external DDR itself thanks to OMAP4 memory controller hardware support. So on OMAP4,sram_pushkind of functionality isn't needed.Hence remove the FIXME warning added for implementing sram push feature on OMAP4.
Will take this one too.
Tony