[PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[Santosh Shilimkar]

This series is just repost adding Catalin's ack to the patches and
combining Thomas's two rebased kexec patches.
It's generated against the mainline 2.6.36-rc3 + Catalin's
"[PATCH 0/9] Various patches for 2.6.37-rc1" series.

Santosh Shilimkar (4):
  omap4: l2x0: Override the default l2x0_disable
  ARM: l2x0: Fix coding-style in the cache-l2x0.h
  ARM: l2x0: Determine the cache size
  ARM: l2x0: Optimise the range based operations

Thomas Gleixner (2):
  arm: Disable outer (L2) cache in kexec
  arm: Implement l2x0 cache disable functions

 arch/arm/include/asm/hardware/cache-l2x0.h |    9 +++-
 arch/arm/include/asm/outercache.h          |   24 +++++++++++
 arch/arm/kernel/machine_kexec.c            |    3 +
 arch/arm/mach-omap2/omap4-common.c         |   13 ++++++
 arch/arm/mm/cache-l2x0.c                   |   63 ++++++++++++++++++++++++++-
 5 files changed, 106 insertions(+), 6 deletions(-)

[PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[Santosh Shilimkar]

This series is just repost adding Catalin's ack to the patches and
combining Thomas's two rebased kexec patches.
It's generated against the mainline 2.6.36-rc3 + Catalin's
"[PATCH 0/9] Various patches for 2.6.37-rc1" series.

Santosh Shilimkar (4):
  omap4: l2x0: Override the default l2x0_disable
  ARM: l2x0: Fix coding-style in the cache-l2x0.h
  ARM: l2x0: Determine the cache size
  ARM: l2x0: Optimise the range based operations

Thomas Gleixner (2):
  arm: Disable outer (L2) cache in kexec
  arm: Implement l2x0 cache disable functions

 arch/arm/include/asm/hardware/cache-l2x0.h |    9 +++-
 arch/arm/include/asm/outercache.h          |   24 +++++++++++
 arch/arm/kernel/machine_kexec.c            |    3 +
 arch/arm/mach-omap2/omap4-common.c         |   13 ++++++
 arch/arm/mm/cache-l2x0.c                   |   63 ++++++++++++++++++++++++++-
 5 files changed, 106 insertions(+), 6 deletions(-)

[PATCH 1/6] arm: Disable outer (L2) cache in kexec

[Santosh Shilimkar]

From: Thomas Gleixner <[tglx@linutronix.de]>

kexec does not disable the outer cache before disabling the inner
caches in cpu_proc_fin(). So L2 is enabled across the kexec jump. When
the new kernel enables chaches again, it randomly crashes.

Disabling L2 before calling cpu_proc_fin() cures the problem.

Disabling L2 requires the following new functions: flush_all(),
inv_all() and disable(). Add them to outer_cache_fns and call them
from the kexec code.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm/include/asm/outercache.h |   24 ++++++++++++++++++++++++
 arch/arm/kernel/machine_kexec.c   |    3 +++
 2 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/outercache.h b/arch/arm/include/asm/outercache.h
index 25f76ba..fc19009 100644
--- a/arch/arm/include/asm/outercache.h
+++ b/arch/arm/include/asm/outercache.h
@@ -25,6 +25,9 @@ struct outer_cache_fns {
 	void (*inv_range)(unsigned long, unsigned long);
 	void (*clean_range)(unsigned long, unsigned long);
 	void (*flush_range)(unsigned long, unsigned long);
+	void (*flush_all)(void);
+	void (*inv_all)(void);
+	void (*disable)(void);
 #ifdef CONFIG_OUTER_CACHE_SYNC
 	void (*sync)(void);
 #endif
@@ -50,6 +53,24 @@ static inline void outer_flush_range(unsigned long start, unsigned long end)
 		outer_cache.flush_range(start, end);
 }
 
+static inline void outer_flush_all(void)
+{
+	if (outer_cache.flush_all)
+		outer_cache.flush_all();
+}
+
+static inline void outer_inv_all(void)
+{
+	if (outer_cache.inv_all)
+		outer_cache.inv_all();
+}
+
+static inline void outer_disable(void)
+{
+	if (outer_cache.disable)
+		outer_cache.disable();
+}
+
 #else
 
 static inline void outer_inv_range(unsigned long start, unsigned long end)
@@ -58,6 +79,9 @@ static inline void outer_clean_range(unsigned long start, unsigned long end)
 { }
 static inline void outer_flush_range(unsigned long start, unsigned long end)
 { }
+static inline void outer_flush_all(void) { }
+static inline void outer_inv_all(void) { }
+static inline void outer_disable(void) { }
 
 #endif
 
diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index 1fc74cb..3a8fd51 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -78,7 +78,10 @@ void machine_kexec(struct kimage *image)
 	local_fiq_disable();
 	setup_mm_for_reboot(0); /* mode is not used, so just pass 0*/
 	flush_cache_all();
+	outer_flush_all();
+	outer_disable();
 	cpu_proc_fin();
+	outer_inv_all();
 	flush_cache_all();
 	cpu_reset(reboot_code_buffer_phys);
 }
-- 
1.6.0.4

[PATCH 2/6] arm: Implement l2x0 cache disable functions

[Santosh Shilimkar]

From: Thomas Gleixner <[tglx@linutronix.de]>

Add flush_all, inv_all and disable functions to the l2x0 code. These
functions are called from kexec code to prevent random crashes in the
new kernel.

Platforms like OMAP which control L2 enable/disable via SMI mode can
override the outer_cache.disable() function to implement their own.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm/mm/cache-l2x0.c |   28 +++++++++++++++++++++++++++-
 1 files changed, 27 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index edb43ff..9310d61 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -112,12 +112,26 @@ static void l2x0_cache_sync(void)
 	spin_unlock_irqrestore(&l2x0_lock, flags);
 }
 
-static inline void l2x0_inv_all(void)
+static void l2x0_flush_all(void)
+{
+	unsigned long flags;
+
+	/* clean all ways */
+	spin_lock_irqsave(&l2x0_lock, flags);
+	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();
+	spin_unlock_irqrestore(&l2x0_lock, flags);
+}
+
+static void l2x0_inv_all(void)
 {
 	unsigned long flags;
 
 	/* invalidate all ways */
 	spin_lock_irqsave(&l2x0_lock, flags);
+	/* Invalidating when L2 is enabled is a nono */
+	BUG_ON(readl(l2x0_base + L2X0_CTRL) & 1);
 	writel_relaxed(l2x0_way_mask, l2x0_base + L2X0_INV_WAY);
 	cache_wait_way(l2x0_base + L2X0_INV_WAY, l2x0_way_mask);
 	cache_sync();
@@ -215,6 +229,15 @@ static void l2x0_flush_range(unsigned long start, unsigned long end)
 	spin_unlock_irqrestore(&l2x0_lock, flags);
 }
 
+static void l2x0_disable(void)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&l2x0_lock, flags);
+	writel(0, l2x0_base + L2X0_CTRL);
+	spin_unlock_irqrestore(&l2x0_lock, flags);
+}
+
 void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
 {
 	__u32 aux;
@@ -272,6 +295,9 @@ void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
 	outer_cache.clean_range = l2x0_clean_range;
 	outer_cache.flush_range = l2x0_flush_range;
 	outer_cache.sync = l2x0_cache_sync;
+	outer_cache.flush_all = l2x0_flush_all;
+	outer_cache.inv_all = l2x0_inv_all;
+	outer_cache.disable = l2x0_disable;
 
 	printk(KERN_INFO "%s cache controller enabled\n", type);
 	printk(KERN_INFO "l2x0: %d ways, CACHE_ID 0x%08x, AUX_CTRL 0x%08x\n",
-- 
1.6.0.4

[PATCH 3/6] omap4: l2x0: Override the default l2x0_disable

[Santosh Shilimkar]

The machine_kexec() calls outer_disable which can crash on OMAP4
becasue of trustzone restrictions.

This patch overrides the default l2x0_disable with a OMAP4
specific implementation taking care of trustzone

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/mach-omap2/omap4-common.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index 13dc979..b557cc2 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -44,6 +44,13 @@ void __init gic_init_irq(void)
 }
 
 #ifdef CONFIG_CACHE_L2X0
+
+static void omap4_l2x0_disable(void)
+{
+	/* Disable PL310 L2 Cache controller */
+	omap_smc1(0x102, 0x0);
+}
+
 static int __init omap_l2_cache_init(void)
 {
 	/*
@@ -66,6 +73,12 @@ static int __init omap_l2_cache_init(void)
 	 */
 	l2x0_init(l2cache_base, 0x0e050000, 0xc0000fff);
 
+	/*
+	 * Override default outer_cache.disable with a OMAP4
+	 * specific one
+	*/
+	outer_cache.disable = omap4_l2x0_disable;
+
 	return 0;
 }
 early_initcall(omap_l2_cache_init);
-- 
1.6.0.4

[PATCH 3/6] omap4: l2x0: Override the default l2x0_disable

[Santosh Shilimkar]

The machine_kexec() calls outer_disable which can crash on OMAP4
becasue of trustzone restrictions.

This patch overrides the default l2x0_disable with a OMAP4
specific implementation taking care of trustzone

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
 arch/arm/mach-omap2/omap4-common.c |   13 +++++++++++++
 1 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/omap4-common.c b/arch/arm/mach-omap2/omap4-common.c
index 13dc979..b557cc2 100644
--- a/arch/arm/mach-omap2/omap4-common.c
+++ b/arch/arm/mach-omap2/omap4-common.c
@@ -44,6 +44,13 @@ void __init gic_init_irq(void)
 }
 
 #ifdef CONFIG_CACHE_L2X0
+
+static void omap4_l2x0_disable(void)
+{
+	/* Disable PL310 L2 Cache controller */
+	omap_smc1(0x102, 0x0);
+}
+
 static int __init omap_l2_cache_init(void)
 {
 	/*
@@ -66,6 +73,12 @@ static int __init omap_l2_cache_init(void)
 	 */
 	l2x0_init(l2cache_base, 0x0e050000, 0xc0000fff);
 
+	/*
+	 * Override default outer_cache.disable with a OMAP4
+	 * specific one
+	*/
+	outer_cache.disable = omap4_l2x0_disable;
+
 	return 0;
 }
 early_initcall(omap_l2_cache_init);
-- 
1.6.0.4

[PATCH 4/6] ARM: l2x0: Fix coding-style in the cache-l2x0.h

[Santosh Shilimkar]

Replace tab with space after #define to be consisten with other
define in the file. Also move the bit mask below the register offsets.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm/include/asm/hardware/cache-l2x0.h |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h
index 6bcba48..d833355 100644
--- a/arch/arm/include/asm/hardware/cache-l2x0.h
+++ b/arch/arm/include/asm/hardware/cache-l2x0.h
@@ -21,9 +21,6 @@
 #define __ASM_ARM_HARDWARE_L2X0_H
 
 #define L2X0_CACHE_ID			0x000
-#define   L2X0_CACHE_ID_PART_MASK	(0xf << 6)
-#define   L2X0_CACHE_ID_PART_L210	(1 << 6)
-#define   L2X0_CACHE_ID_PART_L310	(3 << 6)
 #define L2X0_CACHE_TYPE			0x004
 #define L2X0_CTRL			0x100
 #define L2X0_AUX_CTRL			0x104
@@ -54,6 +51,11 @@
 #define L2X0_LINE_TAG			0xF30
 #define L2X0_DEBUG_CTRL			0xF40
 
+/* Registers shifts and masks */
+#define L2X0_CACHE_ID_PART_MASK		(0xf << 6)
+#define L2X0_CACHE_ID_PART_L210		(1 << 6)
+#define L2X0_CACHE_ID_PART_L310		(3 << 6)
+
 #ifndef __ASSEMBLY__
 extern void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask);
 #endif
-- 
1.6.0.4

[PATCH 4/6] ARM: l2x0: Fix coding-style in the cache-l2x0.h

[Santosh Shilimkar]

Replace tab with space after #define to be consisten with other
define in the file. Also move the bit mask below the register offsets.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm/include/asm/hardware/cache-l2x0.h |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h
index 6bcba48..d833355 100644
--- a/arch/arm/include/asm/hardware/cache-l2x0.h
+++ b/arch/arm/include/asm/hardware/cache-l2x0.h
@@ -21,9 +21,6 @@
 #define __ASM_ARM_HARDWARE_L2X0_H
 
 #define L2X0_CACHE_ID			0x000
-#define   L2X0_CACHE_ID_PART_MASK	(0xf << 6)
-#define   L2X0_CACHE_ID_PART_L210	(1 << 6)
-#define   L2X0_CACHE_ID_PART_L310	(3 << 6)
 #define L2X0_CACHE_TYPE			0x004
 #define L2X0_CTRL			0x100
 #define L2X0_AUX_CTRL			0x104
@@ -54,6 +51,11 @@
 #define L2X0_LINE_TAG			0xF30
 #define L2X0_DEBUG_CTRL			0xF40
 
+/* Registers shifts and masks */
+#define L2X0_CACHE_ID_PART_MASK		(0xf << 6)
+#define L2X0_CACHE_ID_PART_L210		(1 << 6)
+#define L2X0_CACHE_ID_PART_L310		(3 << 6)
+
 #ifndef __ASSEMBLY__
 extern void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask);
 #endif
-- 
1.6.0.4

[PATCH 5/6] ARM: l2x0: Determine the cache size

[Santosh Shilimkar]

The cache size is needed for to optimise range based
maintainance operations

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm/include/asm/hardware/cache-l2x0.h |    1 +
 arch/arm/mm/cache-l2x0.c                   |   13 +++++++++++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h
index d833355..4633d2a 100644
--- a/arch/arm/include/asm/hardware/cache-l2x0.h
+++ b/arch/arm/include/asm/hardware/cache-l2x0.h
@@ -55,6 +55,7 @@
 #define L2X0_CACHE_ID_PART_MASK		(0xf << 6)
 #define L2X0_CACHE_ID_PART_L210		(1 << 6)
 #define L2X0_CACHE_ID_PART_L310		(3 << 6)
+#define L2X0_AUX_CTRL_WAY_SIZE_MASK	(0x3 << 17)
 
 #ifndef __ASSEMBLY__
 extern void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask);
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 9310d61..87b487e 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -28,6 +28,7 @@
 static void __iomem *l2x0_base;
 static DEFINE_SPINLOCK(l2x0_lock);
 static uint32_t l2x0_way_mask;	/* Bitmask of active ways */
+static uint32_t l2x0_size;
 
 static inline void cache_wait_way(void __iomem *reg, unsigned long mask)
 {
@@ -242,6 +243,7 @@ void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
 {
 	__u32 aux;
 	__u32 cache_id;
+	__u32 way_size = 0;
 	int ways;
 	const char *type;
 
@@ -276,6 +278,13 @@ void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
 	l2x0_way_mask = (1 << ways) - 1;
 
 	/*
+	 * L2 cache Size =  Way size * Number of ways
+	 */
+	way_size = (aux & L2X0_AUX_CTRL_WAY_SIZE_MASK) >> 17;
+	way_size = 1 << (way_size + 3);
+	l2x0_size = ways * way_size;
+
+	/*
 	 * Check if l2x0 controller is already enabled.
 	 * If you are booting from non-secure mode
 	 * accessing the below registers will fault.
@@ -300,6 +309,6 @@ void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
 	outer_cache.disable = l2x0_disable;
 
 	printk(KERN_INFO "%s cache controller enabled\n", type);
-	printk(KERN_INFO "l2x0: %d ways, CACHE_ID 0x%08x, AUX_CTRL 0x%08x\n",
-			 ways, cache_id, aux);
+	printk(KERN_INFO "l2x0: %d ways, CACHE_ID 0x%08x, AUX_CTRL 0x%08x, Cache size: %d KB\n",
+			ways, cache_id, aux, l2x0_size);
 }
-- 
1.6.0.4

[PATCH 5/6] ARM: l2x0: Determine the cache size

[Santosh Shilimkar]

The cache size is needed for to optimise range based
maintainance operations

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm/include/asm/hardware/cache-l2x0.h |    1 +
 arch/arm/mm/cache-l2x0.c                   |   13 +++++++++++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h
index d833355..4633d2a 100644
--- a/arch/arm/include/asm/hardware/cache-l2x0.h
+++ b/arch/arm/include/asm/hardware/cache-l2x0.h
@@ -55,6 +55,7 @@
 #define L2X0_CACHE_ID_PART_MASK		(0xf << 6)
 #define L2X0_CACHE_ID_PART_L210		(1 << 6)
 #define L2X0_CACHE_ID_PART_L310		(3 << 6)
+#define L2X0_AUX_CTRL_WAY_SIZE_MASK	(0x3 << 17)
 
 #ifndef __ASSEMBLY__
 extern void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask);
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 9310d61..87b487e 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -28,6 +28,7 @@
 static void __iomem *l2x0_base;
 static DEFINE_SPINLOCK(l2x0_lock);
 static uint32_t l2x0_way_mask;	/* Bitmask of active ways */
+static uint32_t l2x0_size;
 
 static inline void cache_wait_way(void __iomem *reg, unsigned long mask)
 {
@@ -242,6 +243,7 @@ void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
 {
 	__u32 aux;
 	__u32 cache_id;
+	__u32 way_size = 0;
 	int ways;
 	const char *type;
 
@@ -276,6 +278,13 @@ void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
 	l2x0_way_mask = (1 << ways) - 1;
 
 	/*
+	 * L2 cache Size =  Way size * Number of ways
+	 */
+	way_size = (aux & L2X0_AUX_CTRL_WAY_SIZE_MASK) >> 17;
+	way_size = 1 << (way_size + 3);
+	l2x0_size = ways * way_size;
+
+	/*
 	 * Check if l2x0 controller is already enabled.
 	 * If you are booting from non-secure mode
 	 * accessing the below registers will fault.
@@ -300,6 +309,6 @@ void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
 	outer_cache.disable = l2x0_disable;
 
 	printk(KERN_INFO "%s cache controller enabled\n", type);
-	printk(KERN_INFO "l2x0: %d ways, CACHE_ID 0x%08x, AUX_CTRL 0x%08x\n",
-			 ways, cache_id, aux);
+	printk(KERN_INFO "l2x0: %d ways, CACHE_ID 0x%08x, AUX_CTRL 0x%08x, Cache size: %d KB\n",
+			ways, cache_id, aux, l2x0_size);
 }
-- 
1.6.0.4

[PATCH 6/6] ARM: l2x0: Optimise the range based operations

[Santosh Shilimkar]

For the big buffers which are in excess of cache size, the maintaince
operations by PA are very slow. For such buffers the maintainace
operations can be speeded up by using the WAY based method.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm/mm/cache-l2x0.c |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 87b487e..143a39f 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -125,6 +125,18 @@ static void l2x0_flush_all(void)
 	spin_unlock_irqrestore(&l2x0_lock, flags);
 }
 
+static void l2x0_clean_all(void)
+{
+	unsigned long flags;
+
+	/* clean all ways */
+	spin_lock_irqsave(&l2x0_lock, flags);
+	writel_relaxed(l2x0_way_mask, l2x0_base + L2X0_CLEAN_WAY);
+	cache_wait_way(l2x0_base + L2X0_CLEAN_WAY, l2x0_way_mask);
+	cache_sync();
+	spin_unlock_irqrestore(&l2x0_lock, flags);
+}
+
 static void l2x0_inv_all(void)
 {
 	unsigned long flags;
@@ -183,6 +195,11 @@ static void l2x0_clean_range(unsigned long start, unsigned long end)
 	void __iomem *base = l2x0_base;
 	unsigned long flags;
 
+	if ((end - start) >= l2x0_size) {
+		l2x0_clean_all();
+		return;
+	}
+
 	spin_lock_irqsave(&l2x0_lock, flags);
 	start &= ~(CACHE_LINE_SIZE - 1);
 	while (start < end) {
@@ -208,6 +225,11 @@ static void l2x0_flush_range(unsigned long start, unsigned long end)
 	void __iomem *base = l2x0_base;
 	unsigned long flags;
 
+	if ((end - start) >= l2x0_size) {
+		l2x0_flush_all();
+		return;
+	}
+
 	spin_lock_irqsave(&l2x0_lock, flags);
 	start &= ~(CACHE_LINE_SIZE - 1);
 	while (start < end) {
-- 
1.6.0.4

[PATCH 6/6] ARM: l2x0: Optimise the range based operations

[Santosh Shilimkar]

For the big buffers which are in excess of cache size, the maintaince
operations by PA are very slow. For such buffers the maintainace
operations can be speeded up by using the WAY based method.

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm/mm/cache-l2x0.c |   22 ++++++++++++++++++++++
 1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 87b487e..143a39f 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -125,6 +125,18 @@ static void l2x0_flush_all(void)
 	spin_unlock_irqrestore(&l2x0_lock, flags);
 }
 
+static void l2x0_clean_all(void)
+{
+	unsigned long flags;
+
+	/* clean all ways */
+	spin_lock_irqsave(&l2x0_lock, flags);
+	writel_relaxed(l2x0_way_mask, l2x0_base + L2X0_CLEAN_WAY);
+	cache_wait_way(l2x0_base + L2X0_CLEAN_WAY, l2x0_way_mask);
+	cache_sync();
+	spin_unlock_irqrestore(&l2x0_lock, flags);
+}
+
 static void l2x0_inv_all(void)
 {
 	unsigned long flags;
@@ -183,6 +195,11 @@ static void l2x0_clean_range(unsigned long start, unsigned long end)
 	void __iomem *base = l2x0_base;
 	unsigned long flags;
 
+	if ((end - start) >= l2x0_size) {
+		l2x0_clean_all();
+		return;
+	}
+
 	spin_lock_irqsave(&l2x0_lock, flags);
 	start &= ~(CACHE_LINE_SIZE - 1);
 	while (start < end) {
@@ -208,6 +225,11 @@ static void l2x0_flush_range(unsigned long start, unsigned long end)
 	void __iomem *base = l2x0_base;
 	unsigned long flags;
 
+	if ((end - start) >= l2x0_size) {
+		l2x0_flush_all();
+		return;
+	}
+
 	spin_lock_irqsave(&l2x0_lock, flags);
 	start &= ~(CACHE_LINE_SIZE - 1);
 	while (start < end) {
-- 
1.6.0.4

Re: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[Linus Walleij]

2010/9/7 Santosh Shilimkar <santosh.shilimkar@ti.com>:

> This series is just repost adding Catalin's ack to the patches and
> combining Thomas's two rebased kexec patches.
> It's generated against the mainline 2.6.36-rc3 + Catalin's
> "[PATCH 0/9] Various patches for 2.6.37-rc1" series.
>
> Santosh Shilimkar (4):
>  omap4: l2x0: Override the default l2x0_disable
>  ARM: l2x0: Fix coding-style in the cache-l2x0.h
>  ARM: l2x0: Determine the cache size
>  ARM: l2x0: Optimise the range based operations
>
> Thomas Gleixner (2):
>  arm: Disable outer (L2) cache in kexec
>  arm: Implement l2x0 cache disable functions

FWIW:
Acked-by: Linus Walleij <linus.walleij@stericsson.com>

Can you also include the patch by Per Fransson I sent off to
Thomas and the list just a few days ago with the subject
"[PATCH] ARM: ux500 specific L2 cache code"
in this patch series?

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

[PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[Linus Walleij]

2010/9/7 Santosh Shilimkar <santosh.shilimkar@ti.com>:

> This series is just repost adding Catalin's ack to the patches and
> combining Thomas's two rebased kexec patches.
> It's generated against the mainline 2.6.36-rc3 + Catalin's
> "[PATCH 0/9] Various patches for 2.6.37-rc1" series.
>
> Santosh Shilimkar (4):
> ?omap4: l2x0: Override the default l2x0_disable
> ?ARM: l2x0: Fix coding-style in the cache-l2x0.h
> ?ARM: l2x0: Determine the cache size
> ?ARM: l2x0: Optimise the range based operations
>
> Thomas Gleixner (2):
> ?arm: Disable outer (L2) cache in kexec
> ?arm: Implement l2x0 cache disable functions

FWIW:
Acked-by: Linus Walleij <linus.walleij@stericsson.com>

Can you also include the patch by Per Fransson I sent off to
Thomas and the list just a few days ago with the subject
"[PATCH] ARM: ux500 specific L2 cache code"
in this patch series?

Yours,
Linus Walleij

RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[Shilimkar, Santosh]

> -----Original Message-----
> From: Linus Walleij [mailto:linus.ml.walleij@gmail.com]
> Sent: Tuesday, September 07, 2010 11:49 PM
> To: Shilimkar, Santosh
> Cc: linux-arm-kernel@lists.infradead.org; catalin.marinas@arm.com;
> tglx@linutronix.de; linux-omap@vger.kernel.org;
> per.xx.fransson@stericsson.com
> Subject: Re: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation
> 
> 2010/9/7 Santosh Shilimkar <santosh.shilimkar@ti.com>:
> 
> > This series is just repost adding Catalin's ack to the patches and
> > combining Thomas's two rebased kexec patches.
> > It's generated against the mainline 2.6.36-rc3 + Catalin's
> > "[PATCH 0/9] Various patches for 2.6.37-rc1" series.
> >
> > Santosh Shilimkar (4):
> >  omap4: l2x0: Override the default l2x0_disable
> >  ARM: l2x0: Fix coding-style in the cache-l2x0.h
> >  ARM: l2x0: Determine the cache size
> >  ARM: l2x0: Optimise the range based operations
> >
> > Thomas Gleixner (2):
> >  arm: Disable outer (L2) cache in kexec
> >  arm: Implement l2x0 cache disable functions
> 
> FWIW:
> Acked-by: Linus Walleij <linus.walleij@stericsson.com>
> 
Thanks !!
> Can you also include the patch by Per Fransson I sent off to
> Thomas and the list just a few days ago with the subject
> "[PATCH] ARM: ux500 specific L2 cache code"
> in this patch series?
> 
Basically I plan to push all these patches to 
RMK's patch system after getting his OK. I can push 
your patch along with that.

Is that ok with you ?

Regards,
Santosh

[PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[Shilimkar, Santosh]

> -----Original Message-----
> From: Linus Walleij [mailto:linus.ml.walleij at gmail.com]
> Sent: Tuesday, September 07, 2010 11:49 PM
> To: Shilimkar, Santosh
> Cc: linux-arm-kernel at lists.infradead.org; catalin.marinas at arm.com;
> tglx at linutronix.de; linux-omap at vger.kernel.org;
> per.xx.fransson at stericsson.com
> Subject: Re: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation
> 
> 2010/9/7 Santosh Shilimkar <santosh.shilimkar@ti.com>:
> 
> > This series is just repost adding Catalin's ack to the patches and
> > combining Thomas's two rebased kexec patches.
> > It's generated against the mainline 2.6.36-rc3 + Catalin's
> > "[PATCH 0/9] Various patches for 2.6.37-rc1" series.
> >
> > Santosh Shilimkar (4):
> > ?omap4: l2x0: Override the default l2x0_disable
> > ?ARM: l2x0: Fix coding-style in the cache-l2x0.h
> > ?ARM: l2x0: Determine the cache size
> > ?ARM: l2x0: Optimise the range based operations
> >
> > Thomas Gleixner (2):
> > ?arm: Disable outer (L2) cache in kexec
> > ?arm: Implement l2x0 cache disable functions
> 
> FWIW:
> Acked-by: Linus Walleij <linus.walleij@stericsson.com>
> 
Thanks !!
> Can you also include the patch by Per Fransson I sent off to
> Thomas and the list just a few days ago with the subject
> "[PATCH] ARM: ux500 specific L2 cache code"
> in this patch series?
> 
Basically I plan to push all these patches to 
RMK's patch system after getting his OK. I can push 
your patch along with that.

Is that ok with you ?

Regards,
Santosh

Re: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[Linus Walleij]

2010/9/8 Shilimkar, Santosh <santosh.shilimkar@ti.com>:

> Basically I plan to push all these patches to
> RMK's patch system after getting his OK. I can push
> your patch along with that.
>
> Is that ok with you ?

Yep seems like a plan, thanks!

Yours,
Linus Walleij

[PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[Linus Walleij]

2010/9/8 Shilimkar, Santosh <santosh.shilimkar@ti.com>:

> Basically I plan to push all these patches to
> RMK's patch system after getting his OK. I can push
> your patch along with that.
>
> Is that ok with you ?

Yep seems like a plan, thanks!

Yours,
Linus Walleij

RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[Catalin Marinas]

On Wed, 2010-09-08 at 08:34 +0100, Shilimkar, Santosh wrote:
> > Can you also include the patch by Per Fransson I sent off to
> > Thomas and the list just a few days ago with the subject
> > "[PATCH] ARM: ux500 specific L2 cache code"
> > in this patch series?
> 
> Basically I plan to push all these patches to
> RMK's patch system after getting his OK. I can push
> your patch along with that.
> 
> Is that ok with you ?

Or rather a pull request. AFAIK (unless this was fixed recently) the
patch system doesn't handle the "From: " line to set the correct patch
author.

-- 
Catalin

[PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[Catalin Marinas]

On Wed, 2010-09-08 at 08:34 +0100, Shilimkar, Santosh wrote:
> > Can you also include the patch by Per Fransson I sent off to
> > Thomas and the list just a few days ago with the subject
> > "[PATCH] ARM: ux500 specific L2 cache code"
> > in this patch series?
> 
> Basically I plan to push all these patches to
> RMK's patch system after getting his OK. I can push
> your patch along with that.
> 
> Is that ok with you ?

Or rather a pull request. AFAIK (unless this was fixed recently) the
patch system doesn't handle the "From: " line to set the correct patch
author.

-- 
Catalin

RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[Shilimkar, Santosh]

> -----Original Message-----
> From: Catalin Marinas [mailto:catalin.marinas@arm.com]
> Sent: Wednesday, September 08, 2010 8:31 PM
> To: Shilimkar, Santosh
> Cc: Linus Walleij; linux-arm-kernel@lists.infradead.org;
> tglx@linutronix.de; linux-omap@vger.kernel.org;
> per.xx.fransson@stericsson.com
> Subject: RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation
> 
> On Wed, 2010-09-08 at 08:34 +0100, Shilimkar, Santosh wrote:
> > > Can you also include the patch by Per Fransson I sent off to
> > > Thomas and the list just a few days ago with the subject
> > > "[PATCH] ARM: ux500 specific L2 cache code"
> > > in this patch series?
> >
> > Basically I plan to push all these patches to
> > RMK's patch system after getting his OK. I can push
> > your patch along with that.
> >
> > Is that ok with you ?
> 
> Or rather a pull request. AFAIK (unless this was fixed recently) the
> patch system doesn't handle the "From: " line to set the correct patch
> author.
> 
Oh Yes... pull request-is also doable... I have all these patches pilled up
here already ...
http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/l2x0-for-rmk

Regards,
Santosh

[PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[Shilimkar, Santosh]

> -----Original Message-----
> From: Catalin Marinas [mailto:catalin.marinas at arm.com]
> Sent: Wednesday, September 08, 2010 8:31 PM
> To: Shilimkar, Santosh
> Cc: Linus Walleij; linux-arm-kernel at lists.infradead.org;
> tglx at linutronix.de; linux-omap at vger.kernel.org;
> per.xx.fransson at stericsson.com
> Subject: RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation
> 
> On Wed, 2010-09-08 at 08:34 +0100, Shilimkar, Santosh wrote:
> > > Can you also include the patch by Per Fransson I sent off to
> > > Thomas and the list just a few days ago with the subject
> > > "[PATCH] ARM: ux500 specific L2 cache code"
> > > in this patch series?
> >
> > Basically I plan to push all these patches to
> > RMK's patch system after getting his OK. I can push
> > your patch along with that.
> >
> > Is that ok with you ?
> 
> Or rather a pull request. AFAIK (unless this was fixed recently) the
> patch system doesn't handle the "From: " line to set the correct patch
> author.
> 
Oh Yes... pull request-is also doable... I have all these patches pilled up
here already ...
http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/l2x0-for-rmk

Regards,
Santosh

RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[Catalin Marinas]

On Wed, 2010-09-08 at 16:09 +0100, Shilimkar, Santosh wrote:
> > On Wed, 2010-09-08 at 08:34 +0100, Shilimkar, Santosh wrote:
> > > > Can you also include the patch by Per Fransson I sent off to
> > > > Thomas and the list just a few days ago with the subject
> > > > "[PATCH] ARM: ux500 specific L2 cache code"
> > > > in this patch series?
> > >
> > > Basically I plan to push all these patches to
> > > RMK's patch system after getting his OK. I can push
> > > your patch along with that.
> > >
> > > Is that ok with you ?
> >
> > Or rather a pull request. AFAIK (unless this was fixed recently) the
> > patch system doesn't handle the "From: " line to set the correct patch
> > author.
> >
> Oh Yes... pull request-is also doable... I have all these patches pilled up
> here already ...
> http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/l2x0-for-rmk

Well, regarding my patches, I'm only OK for you to submit the
cache-l2x0.c one named:

"ARM: Improve the L2 cache performance when PL310 is used"

The other patches I'll push separately.

Thanks.

-- 
Catalin

[PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[Catalin Marinas]

On Wed, 2010-09-08 at 16:09 +0100, Shilimkar, Santosh wrote:
> > On Wed, 2010-09-08 at 08:34 +0100, Shilimkar, Santosh wrote:
> > > > Can you also include the patch by Per Fransson I sent off to
> > > > Thomas and the list just a few days ago with the subject
> > > > "[PATCH] ARM: ux500 specific L2 cache code"
> > > > in this patch series?
> > >
> > > Basically I plan to push all these patches to
> > > RMK's patch system after getting his OK. I can push
> > > your patch along with that.
> > >
> > > Is that ok with you ?
> >
> > Or rather a pull request. AFAIK (unless this was fixed recently) the
> > patch system doesn't handle the "From: " line to set the correct patch
> > author.
> >
> Oh Yes... pull request-is also doable... I have all these patches pilled up
> here already ...
> http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/l2x0-for-rmk

Well, regarding my patches, I'm only OK for you to submit the
cache-l2x0.c one named:

"ARM: Improve the L2 cache performance when PL310 is used"

The other patches I'll push separately.

Thanks.

-- 
Catalin

RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[Shilimkar, Santosh]

> -----Original Message-----
> From: Catalin Marinas [mailto:catalin.marinas@arm.com]
> Sent: Wednesday, September 08, 2010 8:56 PM
> To: Shilimkar, Santosh
> Cc: Linus Walleij; linux-arm-kernel@lists.infradead.org;
> tglx@linutronix.de; linux-omap@vger.kernel.org;
> per.xx.fransson@stericsson.com
> Subject: RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation
> 
> On Wed, 2010-09-08 at 16:09 +0100, Shilimkar, Santosh wrote:
> > > On Wed, 2010-09-08 at 08:34 +0100, Shilimkar, Santosh wrote:
> > > > > Can you also include the patch by Per Fransson I sent off to
> > > > > Thomas and the list just a few days ago with the subject
> > > > > "[PATCH] ARM: ux500 specific L2 cache code"
> > > > > in this patch series?
> > > >
> > > > Basically I plan to push all these patches to
> > > > RMK's patch system after getting his OK. I can push
> > > > your patch along with that.
> > > >
> > > > Is that ok with you ?
> > >
> > > Or rather a pull request. AFAIK (unless this was fixed recently) the
> > > patch system doesn't handle the "From: " line to set the correct patch
> > > author.
> > >
> > Oh Yes... pull request-is also doable... I have all these patches pilled
> up
> > here already ...
> > http://dev.omapzoom.org/?p=santosh/kernel-omap4-
> base.git;a=shortlog;h=refs/heads/l2x0-for-rmk
> 
> Well, regarding my patches, I'm only OK for you to submit the
> cache-l2x0.c one named:
> 
> "ARM: Improve the L2 cache performance when PL310 is used"
> 
> The other patches I'll push separately.
> 
Sure. 

[PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[Shilimkar, Santosh]

> -----Original Message-----
> From: Catalin Marinas [mailto:catalin.marinas at arm.com]
> Sent: Wednesday, September 08, 2010 8:56 PM
> To: Shilimkar, Santosh
> Cc: Linus Walleij; linux-arm-kernel at lists.infradead.org;
> tglx at linutronix.de; linux-omap at vger.kernel.org;
> per.xx.fransson at stericsson.com
> Subject: RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation
> 
> On Wed, 2010-09-08 at 16:09 +0100, Shilimkar, Santosh wrote:
> > > On Wed, 2010-09-08 at 08:34 +0100, Shilimkar, Santosh wrote:
> > > > > Can you also include the patch by Per Fransson I sent off to
> > > > > Thomas and the list just a few days ago with the subject
> > > > > "[PATCH] ARM: ux500 specific L2 cache code"
> > > > > in this patch series?
> > > >
> > > > Basically I plan to push all these patches to
> > > > RMK's patch system after getting his OK. I can push
> > > > your patch along with that.
> > > >
> > > > Is that ok with you ?
> > >
> > > Or rather a pull request. AFAIK (unless this was fixed recently) the
> > > patch system doesn't handle the "From: " line to set the correct patch
> > > author.
> > >
> > Oh Yes... pull request-is also doable... I have all these patches pilled
> up
> > here already ...
> > http://dev.omapzoom.org/?p=santosh/kernel-omap4-
> base.git;a=shortlog;h=refs/heads/l2x0-for-rmk
> 
> Well, regarding my patches, I'm only OK for you to submit the
> cache-l2x0.c one named:
> 
> "ARM: Improve the L2 cache performance when PL310 is used"
> 
> The other patches I'll push separately.
> 
Sure. 

RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[Shilimkar, Santosh]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Shilimkar, Santosh
> Sent: Wednesday, September 08, 2010 8:59 PM
> To: Catalin Marinas
> Cc: Linus Walleij; linux-arm-kernel@lists.infradead.org;
> tglx@linutronix.de; linux-omap@vger.kernel.org;
> per.xx.fransson@stericsson.com
> Subject: RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation
> 
> > -----Original Message-----
> > From: Catalin Marinas [mailto:catalin.marinas@arm.com]
> > Sent: Wednesday, September 08, 2010 8:56 PM
> > To: Shilimkar, Santosh
> > Cc: Linus Walleij; linux-arm-kernel@lists.infradead.org;
> > tglx@linutronix.de; linux-omap@vger.kernel.org;
> > per.xx.fransson@stericsson.com
> > Subject: RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation
> >
> > On Wed, 2010-09-08 at 16:09 +0100, Shilimkar, Santosh wrote:
> > > > On Wed, 2010-09-08 at 08:34 +0100, Shilimkar, Santosh wrote:
> > > > > > Can you also include the patch by Per Fransson I sent off to
> > > > > > Thomas and the list just a few days ago with the subject
> > > > > > "[PATCH] ARM: ux500 specific L2 cache code"
> > > > > > in this patch series?
> > > > >
> > > > > Basically I plan to push all these patches to
> > > > > RMK's patch system after getting his OK. I can push
> > > > > your patch along with that.
> > > > >
> > > > > Is that ok with you ?
> > > >
> > > > Or rather a pull request. AFAIK (unless this was fixed recently) the
> > > > patch system doesn't handle the "From: " line to set the correct
> patch
> > > > author.
> > > >
> > > Oh Yes... pull request-is also doable... I have all these patches
> pilled
> > up
> > > here already ...
> > > http://dev.omapzoom.org/?p=santosh/kernel-omap4-
> > base.git;a=shortlog;h=refs/heads/l2x0-for-rmk
> >
> > Well, regarding my patches, I'm only OK for you to submit the
> > cache-l2x0.c one named:
> >
> > "ARM: Improve the L2 cache performance when PL310 is used"
> >
> > The other patches I'll push separately.
> >
> Sure.
> 
Here is the updated branch including "Per Fransson" patch.
http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/l2x0-pull-rmk

Regards,
Santosh

[PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[Shilimkar, Santosh]

> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Shilimkar, Santosh
> Sent: Wednesday, September 08, 2010 8:59 PM
> To: Catalin Marinas
> Cc: Linus Walleij; linux-arm-kernel at lists.infradead.org;
> tglx at linutronix.de; linux-omap at vger.kernel.org;
> per.xx.fransson at stericsson.com
> Subject: RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation
> 
> > -----Original Message-----
> > From: Catalin Marinas [mailto:catalin.marinas at arm.com]
> > Sent: Wednesday, September 08, 2010 8:56 PM
> > To: Shilimkar, Santosh
> > Cc: Linus Walleij; linux-arm-kernel at lists.infradead.org;
> > tglx at linutronix.de; linux-omap at vger.kernel.org;
> > per.xx.fransson at stericsson.com
> > Subject: RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation
> >
> > On Wed, 2010-09-08 at 16:09 +0100, Shilimkar, Santosh wrote:
> > > > On Wed, 2010-09-08 at 08:34 +0100, Shilimkar, Santosh wrote:
> > > > > > Can you also include the patch by Per Fransson I sent off to
> > > > > > Thomas and the list just a few days ago with the subject
> > > > > > "[PATCH] ARM: ux500 specific L2 cache code"
> > > > > > in this patch series?
> > > > >
> > > > > Basically I plan to push all these patches to
> > > > > RMK's patch system after getting his OK. I can push
> > > > > your patch along with that.
> > > > >
> > > > > Is that ok with you ?
> > > >
> > > > Or rather a pull request. AFAIK (unless this was fixed recently) the
> > > > patch system doesn't handle the "From: " line to set the correct
> patch
> > > > author.
> > > >
> > > Oh Yes... pull request-is also doable... I have all these patches
> pilled
> > up
> > > here already ...
> > > http://dev.omapzoom.org/?p=santosh/kernel-omap4-
> > base.git;a=shortlog;h=refs/heads/l2x0-for-rmk
> >
> > Well, regarding my patches, I'm only OK for you to submit the
> > cache-l2x0.c one named:
> >
> > "ARM: Improve the L2 cache performance when PL310 is used"
> >
> > The other patches I'll push separately.
> >
> Sure.
> 
Here is the updated branch including "Per Fransson" patch.
http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/l2x0-pull-rmk

Regards,
Santosh

RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[Catalin Marinas]

On Wed, 2010-09-08 at 16:46 +0100, Shilimkar, Santosh wrote:
> Here is the updated branch including "Per Fransson" patch.
> http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/l2x0-pull-rmk

It looks fine to me.

-- 
Catalin

[PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[Catalin Marinas]

On Wed, 2010-09-08 at 16:46 +0100, Shilimkar, Santosh wrote:
> Here is the updated branch including "Per Fransson" patch.
> http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=shortlog;h=refs/heads/l2x0-pull-rmk

It looks fine to me.

-- 
Catalin

RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[Shilimkar, Santosh]

Tony,
> -----Original Message-----
> From: Catalin Marinas [mailto:catalin.marinas@arm.com]
> Sent: Wednesday, September 08, 2010 9:20 PM
> To: Shilimkar, Santosh
> Cc: Linus Walleij; Russell King - ARM Linux; linux-arm-
> kernel@lists.infradead.org; tglx@linutronix.de; linux-
> omap@vger.kernel.org; per.xx.fransson@stericsson.com
> Subject: RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation
> 
> On Wed, 2010-09-08 at 16:46 +0100, Shilimkar, Santosh wrote:
> > Here is the updated branch including "Per Fransson" patch.
> > http://dev.omapzoom.org/?p=santosh/kernel-omap4-
> base.git;a=shortlog;h=refs/heads/l2x0-pull-rmk
> 
> It looks fine to me.
> 

Are you ok if " [PATCH 3/6] omap4: l2x0: Override the default l2x0_disable"
patch gets merged via Russell's tree?

http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=blobdiff;f=arch/arm/mach-omap2/omap4-common.c;h=b557cc2c4b10e2ba4b6c4d6e3397611fb2de5952;hp=13dc9794dcc2ea68fe9115cff7be9cd8c074a484;hb=e1612fb084e78d5cba127f360803863e87a1e0cd;hpb=32ff2ccc0ca4d22c211fc5f5cc71b3d9a950c8c3

Regards,
Santosh

[PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation

[Shilimkar, Santosh]

Tony,
> -----Original Message-----
> From: Catalin Marinas [mailto:catalin.marinas at arm.com]
> Sent: Wednesday, September 08, 2010 9:20 PM
> To: Shilimkar, Santosh
> Cc: Linus Walleij; Russell King - ARM Linux; linux-arm-
> kernel at lists.infradead.org; tglx at linutronix.de; linux-
> omap at vger.kernel.org; per.xx.fransson at stericsson.com
> Subject: RE: [PATCH 0/6] ARM: l2x0: kexex, cleanup and optimisation
> 
> On Wed, 2010-09-08 at 16:46 +0100, Shilimkar, Santosh wrote:
> > Here is the updated branch including "Per Fransson" patch.
> > http://dev.omapzoom.org/?p=santosh/kernel-omap4-
> base.git;a=shortlog;h=refs/heads/l2x0-pull-rmk
> 
> It looks fine to me.
> 

Are you ok if " [PATCH 3/6] omap4: l2x0: Override the default l2x0_disable"
patch gets merged via Russell's tree?

http://dev.omapzoom.org/?p=santosh/kernel-omap4-base.git;a=blobdiff;f=arch/arm/mach-omap2/omap4-common.c;h=b557cc2c4b10e2ba4b6c4d6e3397611fb2de5952;hp=13dc9794dcc2ea68fe9115cff7be9cd8c074a484;hb=e1612fb084e78d5cba127f360803863e87a1e0cd;hpb=32ff2ccc0ca4d22c211fc5f5cc71b3d9a950c8c3

Regards,
Santosh

Re: [PATCH 3/6] omap4: l2x0: Override the default l2x0_disable

[Tony Lindgren]

* Santosh Shilimkar <santosh.shilimkar@ti.com> [100907 00:50]:
> The machine_kexec() calls outer_disable which can crash on OMAP4
> becasue of trustzone restrictions.
> 
> This patch overrides the default l2x0_disable with a OMAP4
> specific implementation taking care of trustzone

<snip>

> @@ -66,6 +73,12 @@ static int __init omap_l2_cache_init(void)
>
>  	 */
>  	l2x0_init(l2cache_base, 0x0e050000, 0xc0000fff);
>
> +	/*
> +	 * Override default outer_cache.disable with a OMAP4
> +	 * specific one
> +	*/
> +	outer_cache.disable = omap4_l2x0_disable;
> +
>  	return 0;
>  }
>  early_initcall(omap_l2_cache_init);

Just to be sure.. No outer_cache functions get set unless
l2x0_init gets called, right? So omap2 and omap3 functions
always stay NULL with omap3_defconfig?

Tony

[PATCH 3/6] omap4: l2x0: Override the default l2x0_disable

[Tony Lindgren]

* Santosh Shilimkar <santosh.shilimkar@ti.com> [100907 00:50]:
> The machine_kexec() calls outer_disable which can crash on OMAP4
> becasue of trustzone restrictions.
> 
> This patch overrides the default l2x0_disable with a OMAP4
> specific implementation taking care of trustzone

<snip>

> @@ -66,6 +73,12 @@ static int __init omap_l2_cache_init(void)
>
>  	 */
>  	l2x0_init(l2cache_base, 0x0e050000, 0xc0000fff);
>
> +	/*
> +	 * Override default outer_cache.disable with a OMAP4
> +	 * specific one
> +	*/
> +	outer_cache.disable = omap4_l2x0_disable;
> +
>  	return 0;
>  }
>  early_initcall(omap_l2_cache_init);

Just to be sure.. No outer_cache functions get set unless
l2x0_init gets called, right? So omap2 and omap3 functions
always stay NULL with omap3_defconfig?

Tony

RE: [PATCH 3/6] omap4: l2x0: Override the default l2x0_disable

[Shilimkar, Santosh]

> -----Original Message-----
> From: Tony Lindgren [mailto:tony@atomide.com]
> Sent: Thursday, September 16, 2010 5:52 AM
> To: Shilimkar, Santosh
> Cc: linux-arm-kernel@lists.infradead.org; tglx@linutronix.de;
> catalin.marinas@arm.com; linux-omap@vger.kernel.org
> Subject: Re: [PATCH 3/6] omap4: l2x0: Override the default l2x0_disable
> 
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [100907 00:50]:
> > The machine_kexec() calls outer_disable which can crash on OMAP4
> > becasue of trustzone restrictions.
> >
> > This patch overrides the default l2x0_disable with a OMAP4
> > specific implementation taking care of trustzone
> 
> <snip>
> 
> > @@ -66,6 +73,12 @@ static int __init omap_l2_cache_init(void)
> >
> >  	 */
> >  	l2x0_init(l2cache_base, 0x0e050000, 0xc0000fff);
> >
> > +	/*
> > +	 * Override default outer_cache.disable with a OMAP4
> > +	 * specific one
> > +	*/
> > +	outer_cache.disable = omap4_l2x0_disable;
> > +
> >  	return 0;
> >  }
> >  early_initcall(omap_l2_cache_init);
> 
> Just to be sure.. No outer_cache functions get set unless
> l2x0_init gets called, right? So omap2 and omap3 functions
> always stay NULL with omap3_defconfig?
> 
Yes.

[PATCH 3/6] omap4: l2x0: Override the default l2x0_disable

[Shilimkar, Santosh]

> -----Original Message-----
> From: Tony Lindgren [mailto:tony at atomide.com]
> Sent: Thursday, September 16, 2010 5:52 AM
> To: Shilimkar, Santosh
> Cc: linux-arm-kernel at lists.infradead.org; tglx at linutronix.de;
> catalin.marinas at arm.com; linux-omap at vger.kernel.org
> Subject: Re: [PATCH 3/6] omap4: l2x0: Override the default l2x0_disable
> 
> * Santosh Shilimkar <santosh.shilimkar@ti.com> [100907 00:50]:
> > The machine_kexec() calls outer_disable which can crash on OMAP4
> > becasue of trustzone restrictions.
> >
> > This patch overrides the default l2x0_disable with a OMAP4
> > specific implementation taking care of trustzone
> 
> <snip>
> 
> > @@ -66,6 +73,12 @@ static int __init omap_l2_cache_init(void)
> >
> >  	 */
> >  	l2x0_init(l2cache_base, 0x0e050000, 0xc0000fff);
> >
> > +	/*
> > +	 * Override default outer_cache.disable with a OMAP4
> > +	 * specific one
> > +	*/
> > +	outer_cache.disable = omap4_l2x0_disable;
> > +
> >  	return 0;
> >  }
> >  early_initcall(omap_l2_cache_init);
> 
> Just to be sure.. No outer_cache functions get set unless
> l2x0_init gets called, right? So omap2 and omap3 functions
> always stay NULL with omap3_defconfig?
> 
Yes.

Re: [PATCH 6/6] ARM: l2x0: Optimise the range based operations

[Russell King - ARM Linux]

On Tue, Sep 07, 2010 at 01:27:23PM +0530, Santosh Shilimkar wrote:
> For the big buffers which are in excess of cache size, the maintaince
> operations by PA are very slow. For such buffers the maintainace
> operations can be speeded up by using the WAY based method.

This causes my Versatile Express to corrupt MMC transfers.  Reverting
both this and the 'Determine cache size' patches makes it work again.

(Note that just reverting this one doesn't result in a working situation.)

Good boot:

L310 cache controller enabled                                                   
l2x0: 8 ways, CACHE_ID 0x410000c3, AUX_CTRL 0x02460000                          
...
mmci-pl18x mb:mmci: mmc0: MMCI rev 0 cfg 00 at 0x0000000010005000 irq 41,42     
aaci-pl041 mb:aaci: ARM AC'97 Interface at 0x0000000010004000, irq 43, fifo 512 
ALSA device list:                                                               
  #0: ARM AC'97 Interface at 0x0000000010004000, irq 43                         
TCP cubic registered                                                            
mmc0: host does not support reading read-only switch. assuming write-enable.    
mmc0: new SD card at address e624                                               
mmcblk0: mmc0:e624 SD02G 1.89 GiB                                               
NET: Registered protocol family 17                                              
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 0         
 mmcblk0: p1                                                                    
Initalizing network drop monitor service                                        
Waiting 5sec before mounting root device...                                     
port 1 high speed                                                               

Bad boot (with just 'Determine cache size' patch applied):

L310 cache controller enabled                                                   
l2x0: 8 ways, CACHE_ID 0x410000c3, AUX_CTRL 0x02460000, Cache size: 512 KB      
...
mmci-pl18x mb:mmci: mmc0: MMCI rev 0 cfg 00 at 0x0000000010005000 irq 41,42     
aaci-pl041 mb:aaci: ARM AC'97 Interface at 0x0000000010004000, irq 43, fifo 512 
ALSA device list:                                                               
  #0: ARM AC'97 Interface at 0x0000000010004000, irq 43                         
mmc0: host does not support reading read-only switch. assuming write-enable.    
mmc0: new SD card at address e624                                               
mmcblk0: mmc0:e624 SD02G 1.89 GiB                                               
TCP cubic registered                                                            
NET: Registered protocol family 17                                              
mmcblk0: retrying using single block read                                       
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 0         
mmcblk0: error -5 transferring data, sector 0, nr 8, card status 0x900          
Initalizing network drop monitor service                                        
<random garbage>
mmcblk0: error -5 transferring data, sector 1, nr 7, card status 0x900
end_request: I/O error, dev mmcblk0, sector 1                                   
Buffer I/O error on device mmcblk0, logical block 0                             
port 1 high speed                                                               

-5 is -EIO, which is a FIFO overrun error, so somehow these changes are
causing the CPU or bus accesses to be slower.

[PATCH 6/6] ARM: l2x0: Optimise the range based operations

[Russell King - ARM Linux]

On Tue, Sep 07, 2010 at 01:27:23PM +0530, Santosh Shilimkar wrote:
> For the big buffers which are in excess of cache size, the maintaince
> operations by PA are very slow. For such buffers the maintainace
> operations can be speeded up by using the WAY based method.

This causes my Versatile Express to corrupt MMC transfers.  Reverting
both this and the 'Determine cache size' patches makes it work again.

(Note that just reverting this one doesn't result in a working situation.)

Good boot:

L310 cache controller enabled                                                   
l2x0: 8 ways, CACHE_ID 0x410000c3, AUX_CTRL 0x02460000                          
...
mmci-pl18x mb:mmci: mmc0: MMCI rev 0 cfg 00 at 0x0000000010005000 irq 41,42     
aaci-pl041 mb:aaci: ARM AC'97 Interface at 0x0000000010004000, irq 43, fifo 512 
ALSA device list:                                                               
  #0: ARM AC'97 Interface at 0x0000000010004000, irq 43                         
TCP cubic registered                                                            
mmc0: host does not support reading read-only switch. assuming write-enable.    
mmc0: new SD card at address e624                                               
mmcblk0: mmc0:e624 SD02G 1.89 GiB                                               
NET: Registered protocol family 17                                              
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 0         
 mmcblk0: p1                                                                    
Initalizing network drop monitor service                                        
Waiting 5sec before mounting root device...                                     
port 1 high speed                                                               

Bad boot (with just 'Determine cache size' patch applied):

L310 cache controller enabled                                                   
l2x0: 8 ways, CACHE_ID 0x410000c3, AUX_CTRL 0x02460000, Cache size: 512 KB      
...
mmci-pl18x mb:mmci: mmc0: MMCI rev 0 cfg 00 at 0x0000000010005000 irq 41,42     
aaci-pl041 mb:aaci: ARM AC'97 Interface at 0x0000000010004000, irq 43, fifo 512 
ALSA device list:                                                               
  #0: ARM AC'97 Interface at 0x0000000010004000, irq 43                         
mmc0: host does not support reading read-only switch. assuming write-enable.    
mmc0: new SD card at address e624                                               
mmcblk0: mmc0:e624 SD02G 1.89 GiB                                               
TCP cubic registered                                                            
NET: Registered protocol family 17                                              
mmcblk0: retrying using single block read                                       
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 0         
mmcblk0: error -5 transferring data, sector 0, nr 8, card status 0x900          
Initalizing network drop monitor service                                        
<random garbage>
mmcblk0: error -5 transferring data, sector 1, nr 7, card status 0x900
end_request: I/O error, dev mmcblk0, sector 1                                   
Buffer I/O error on device mmcblk0, logical block 0                             
port 1 high speed                                                               

-5 is -EIO, which is a FIFO overrun error, so somehow these changes are
causing the CPU or bus accesses to be slower.

RE: [PATCH 6/6] ARM: l2x0: Optimise the range based operations

[Shilimkar, Santosh]

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> Sent: Tuesday, October 05, 2010 2:53 AM
> To: Shilimkar, Santosh
> Cc: linux-arm-kernel@lists.infradead.org; catalin.marinas@arm.com;
> tglx@linutronix.de; linux-omap@vger.kernel.org
> Subject: Re: [PATCH 6/6] ARM: l2x0: Optimise the range based operations
> 
> On Tue, Sep 07, 2010 at 01:27:23PM +0530, Santosh Shilimkar wrote:
> > For the big buffers which are in excess of cache size, the maintaince
> > operations by PA are very slow. For such buffers the maintainace
> > operations can be speeded up by using the WAY based method.
> 
> This causes my Versatile Express to corrupt MMC transfers.  Reverting
> both this and the 'Determine cache size' patches makes it work again.
>
> (Note that just reverting this one doesn't result in a working situation.)
> 
Mostly MMC buffers are smaller than 512KB so the optimization won't
even be invoked.

> Good boot:
> 
> L310 cache controller enabled
> l2x0: 8 ways, CACHE_ID 0x410000c3, AUX_CTRL 0x02460000
> ...
> mmci-pl18x mb:mmci: mmc0: MMCI rev 0 cfg 00 at 0x0000000010005000 irq
> 41,42
> aaci-pl041 mb:aaci: ARM AC'97 Interface at 0x0000000010004000, irq 43,
> fifo 512
> ALSA device list:
>   #0: ARM AC'97 Interface at 0x0000000010004000, irq 43
> TCP cubic registered
> mmc0: host does not support reading read-only switch. assuming write-
> enable.
> mmc0: new SD card at address e624
> mmcblk0: mmc0:e624 SD02G 1.89 GiB
> NET: Registered protocol family 17
> VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 0
>  mmcblk0: p1
> Initalizing network drop monitor service
> Waiting 5sec before mounting root device...
> port 1 high speed
> 
> Bad boot (with just 'Determine cache size' patch applied):
> 
> L310 cache controller enabled
> l2x0: 8 ways, CACHE_ID 0x410000c3, AUX_CTRL 0x02460000, Cache size: 512 KB
> ...
> mmci-pl18x mb:mmci: mmc0: MMCI rev 0 cfg 00 at 0x0000000010005000 irq
> 41,42
> aaci-pl041 mb:aaci: ARM AC'97 Interface at 0x0000000010004000, irq 43,
> fifo 512
> ALSA device list:
>   #0: ARM AC'97 Interface at 0x0000000010004000, irq 43
> mmc0: host does not support reading read-only switch. assuming write-
> enable.
> mmc0: new SD card at address e624
> mmcblk0: mmc0:e624 SD02G 1.89 GiB
> TCP cubic registered
> NET: Registered protocol family 17
> mmcblk0: retrying using single block read
> VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 0
> mmcblk0: error -5 transferring data, sector 0, nr 8, card status 0x900
> Initalizing network drop monitor service
> <random garbage>
> mmcblk0: error -5 transferring data, sector 1, nr 7, card status 0x900
> end_request: I/O error, dev mmcblk0, sector 1
> Buffer I/O error on device mmcblk0, logical block 0
> port 1 high speed
> 
> -5 is -EIO, which is a FIFO overrun error, so somehow these changes are
> causing the CPU or bus accesses to be slower.
I don't see the problem on OMAP MMC.
May be some how additional check is making these operations 
touch slower which lead to the under run.

Will have a look at it again. May for this merge window you can
drop 'Optimise the range based operations' and ''Determine cache size'
patches.

Regards,
Santosh

[PATCH 6/6] ARM: l2x0: Optimise the range based operations

[Shilimkar, Santosh]

> -----Original Message-----
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Tuesday, October 05, 2010 2:53 AM
> To: Shilimkar, Santosh
> Cc: linux-arm-kernel at lists.infradead.org; catalin.marinas at arm.com;
> tglx at linutronix.de; linux-omap at vger.kernel.org
> Subject: Re: [PATCH 6/6] ARM: l2x0: Optimise the range based operations
> 
> On Tue, Sep 07, 2010 at 01:27:23PM +0530, Santosh Shilimkar wrote:
> > For the big buffers which are in excess of cache size, the maintaince
> > operations by PA are very slow. For such buffers the maintainace
> > operations can be speeded up by using the WAY based method.
> 
> This causes my Versatile Express to corrupt MMC transfers.  Reverting
> both this and the 'Determine cache size' patches makes it work again.
>
> (Note that just reverting this one doesn't result in a working situation.)
> 
Mostly MMC buffers are smaller than 512KB so the optimization won't
even be invoked.

> Good boot:
> 
> L310 cache controller enabled
> l2x0: 8 ways, CACHE_ID 0x410000c3, AUX_CTRL 0x02460000
> ...
> mmci-pl18x mb:mmci: mmc0: MMCI rev 0 cfg 00 at 0x0000000010005000 irq
> 41,42
> aaci-pl041 mb:aaci: ARM AC'97 Interface at 0x0000000010004000, irq 43,
> fifo 512
> ALSA device list:
>   #0: ARM AC'97 Interface at 0x0000000010004000, irq 43
> TCP cubic registered
> mmc0: host does not support reading read-only switch. assuming write-
> enable.
> mmc0: new SD card at address e624
> mmcblk0: mmc0:e624 SD02G 1.89 GiB
> NET: Registered protocol family 17
> VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 0
>  mmcblk0: p1
> Initalizing network drop monitor service
> Waiting 5sec before mounting root device...
> port 1 high speed
> 
> Bad boot (with just 'Determine cache size' patch applied):
> 
> L310 cache controller enabled
> l2x0: 8 ways, CACHE_ID 0x410000c3, AUX_CTRL 0x02460000, Cache size: 512 KB
> ...
> mmci-pl18x mb:mmci: mmc0: MMCI rev 0 cfg 00 at 0x0000000010005000 irq
> 41,42
> aaci-pl041 mb:aaci: ARM AC'97 Interface at 0x0000000010004000, irq 43,
> fifo 512
> ALSA device list:
>   #0: ARM AC'97 Interface at 0x0000000010004000, irq 43
> mmc0: host does not support reading read-only switch. assuming write-
> enable.
> mmc0: new SD card at address e624
> mmcblk0: mmc0:e624 SD02G 1.89 GiB
> TCP cubic registered
> NET: Registered protocol family 17
> mmcblk0: retrying using single block read
> VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 0
> mmcblk0: error -5 transferring data, sector 0, nr 8, card status 0x900
> Initalizing network drop monitor service
> <random garbage>
> mmcblk0: error -5 transferring data, sector 1, nr 7, card status 0x900
> end_request: I/O error, dev mmcblk0, sector 1
> Buffer I/O error on device mmcblk0, logical block 0
> port 1 high speed
> 
> -5 is -EIO, which is a FIFO overrun error, so somehow these changes are
> causing the CPU or bus accesses to be slower.
I don't see the problem on OMAP MMC.
May be some how additional check is making these operations 
touch slower which lead to the under run.

Will have a look at it again. May for this merge window you can
drop 'Optimise the range based operations' and ''Determine cache size'
patches.

Regards,
Santosh

RE: [PATCH 6/6] ARM: l2x0: Optimise the range based operations

[Shilimkar, Santosh]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Shilimkar, Santosh
> Sent: Tuesday, October 05, 2010 10:25 AM
> To: Russell King - ARM Linux
> Cc: linux-arm-kernel@lists.infradead.org; catalin.marinas@arm.com;
> tglx@linutronix.de; linux-omap@vger.kernel.org
> Subject: RE: [PATCH 6/6] ARM: l2x0: Optimise the range based operations
> 
[....]

> > mmcblk0: error -5 transferring data, sector 1, nr 7, card status 0x900
> > end_request: I/O error, dev mmcblk0, sector 1
> > Buffer I/O error on device mmcblk0, logical block 0
> > port 1 high speed
> >
> > -5 is -EIO, which is a FIFO overrun error, so somehow these changes are
> > causing the CPU or bus accesses to be slower.
> I don't see the problem on OMAP MMC.
> May be some how additional check is making these operations
> touch slower which lead to the under run.
> 
> Will have a look at it again. May for this merge window you can
> drop 'Optimise the range based operations' and 'Determine cache size'
> patches.
> 
The Pl310 cache way size given in KB and 'Determine cache size' missed
to include that. Have updated the git tree with refreshed patch. Here is
the updated patch.. 

----------------------
>From 8b351fbc4da738a0727854cb88933c4051657384 Mon Sep 17 00:00:00 2001
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
Date: Sun, 11 Jul 2010 14:35:37 +0530
Subject: [PATCH 6/8 v2] ARM: l2x0: Determine the cache size

The cache size is needed for to optimise range based
maintainance operations

Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Linus Walleij <linus.walleij@stericsson.com>
---
 arch/arm/include/asm/hardware/cache-l2x0.h |    1 +
 arch/arm/mm/cache-l2x0.c                   |   13 +++++++++++--
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/hardware/cache-l2x0.h b/arch/arm/include/asm/hardware/cache-l2x0.h
index d833355..4633d2a 100644
--- a/arch/arm/include/asm/hardware/cache-l2x0.h
+++ b/arch/arm/include/asm/hardware/cache-l2x0.h
@@ -55,6 +55,7 @@
 #define L2X0_CACHE_ID_PART_MASK		(0xf << 6)
 #define L2X0_CACHE_ID_PART_L210		(1 << 6)
 #define L2X0_CACHE_ID_PART_L310		(3 << 6)
+#define L2X0_AUX_CTRL_WAY_SIZE_MASK	(0x3 << 17)
 
 #ifndef __ASSEMBLY__
 extern void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask);
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 9310d61..262c752 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -28,6 +28,7 @@
 static void __iomem *l2x0_base;
 static DEFINE_SPINLOCK(l2x0_lock);
 static uint32_t l2x0_way_mask;	/* Bitmask of active ways */
+static uint32_t l2x0_size;
 
 static inline void cache_wait_way(void __iomem *reg, unsigned long mask)
 {
@@ -242,6 +243,7 @@ void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
 {
 	__u32 aux;
 	__u32 cache_id;
+	__u32 way_size = 0;
 	int ways;
 	const char *type;
 
@@ -276,6 +278,13 @@ void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
 	l2x0_way_mask = (1 << ways) - 1;
 
 	/*
+	 * L2 cache Size =  Way size * Number of ways
+	 */
+	way_size = (aux & L2X0_AUX_CTRL_WAY_SIZE_MASK) >> 17;
+	way_size = 1 << (way_size + 3);
+	l2x0_size = ways * way_size * SZ_1K;
+
+	/*
 	 * Check if l2x0 controller is already enabled.
 	 * If you are booting from non-secure mode
 	 * accessing the below registers will fault.
@@ -300,6 +309,6 @@ void __init l2x0_init(void __iomem *base, __u32 aux_val, __u32 aux_mask)
 	outer_cache.disable = l2x0_disable;
 
 	printk(KERN_INFO "%s cache controller enabled\n", type);
-	printk(KERN_INFO "l2x0: %d ways, CACHE_ID 0x%08x, AUX_CTRL 0x%08x\n",
-			 ways, cache_id, aux);
+	printk(KERN_INFO "l2x0: %d ways, CACHE_ID 0x%08x, AUX_CTRL 0x%08x, Cache size: %d B\n",
+			ways, cache_id, aux, l2x0_size);
 }
-- 
1.6.0.4

[PATCH 6/6] ARM: l2x0: Optimise the range based operations

[Shilimkar, Santosh]

> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Shilimkar, Santosh
> Sent: Tuesday, October 05, 2010 10:25 AM
> To: Russell King - ARM Linux
> Cc: linux-arm-kernel at lists.infradead.org; catalin.marinas at arm.com;
> tglx at linutronix.de; linux-omap at vger.kernel.org
> Subject: RE: [PATCH 6/6] ARM: l2x0: Optimise the range based operations
> 
[....]

> > mmcblk0: error -5 transferring data, sector 1, nr 7, card status 0x900
> > end_request: I/O error, dev mmcblk0, sector 1
> > Buffer I/O error on device mmcblk0, logical block 0
> > port 1 high speed
> >
> > -5 is -EIO, which is a FIFO overrun error, so somehow these changes are
> > causing the CPU or bus accesses to be slower.
> I don't see the problem on OMAP MMC.
> May be some how additional check is making these operations
> touch slower which lead to the under run.
> 
> Will have a look at it again. May for this merge window you can
> drop 'Optimise the range based operations' and 'Determine cache size'
> patches.
> 
The Pl310 cache way size given in KB and 'Determine cache size' missed
to include that. Have updated the git tree with refreshed patch. Here is
the updated patch.. 

----------------------

[PATCH 6/6] ARM: l2x0: Optimise the range based operations

[Antti P Miettinen]

Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
> For the big buffers which are in excess of cache size, the maintaince
> operations by PA are very slow. For such buffers the maintainace
> operations can be speeded up by using the WAY based method.
>
> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
>  arch/arm/mm/cache-l2x0.c |   22 ++++++++++++++++++++++
>  1 files changed, 22 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
[..]
> @@ -208,6 +225,11 @@ static void l2x0_flush_range(unsigned long start, unsigned long end)
>  	void __iomem *base = l2x0_base;
>  	unsigned long flags;
>  
> +	if ((end - start) >= l2x0_size) {
> +		l2x0_flush_all();
> +		return;
> +	}
> +
>  	spin_lock_irqsave(&l2x0_lock, flags);
>  	start &= ~(CACHE_LINE_SIZE - 1);
>  	while (start < end) {

I wonder if this is safe. Are the L2 controller clean&invalidate
operations atomic in relation to CPU stores? The PL310 TRM says that
clean and invalidate by way is a background operation. About background
operations the TRM says that the targeted ways are locked for
allocations but read or write hits are permitted to access the way. So
is the following sequence possible?

1. L2 controller cleans a way
2. A CPU writes to the same way
3. L2 controller invalidates the way

This would result in loss of data. This would mean that the optimization
is not safe if several cores are active.

--
Antti P Miettinen
http://www.iki.fi/~ananaza/