[U-Boot] [PATCH 3/3 v3] ARM: ARM926EJS - Add cache operations
Add a new file arch/arm/cpu/arm926ejs/cache.c and put cache operations into this file.
Signed-off-by: Hong Xu hong.xu@atmel.com --- V2: Fixed a typo when CONFIG_SYS_DCACHE_OFF is defined V3: Undo changes in include/configs/at91sam9260ek.h It's for testing purpose
arch/arm/cpu/arm926ejs/Makefile | 2 +- arch/arm/cpu/arm926ejs/cache.c | 142 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 143 insertions(+), 1 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/cache.c
diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..5b5f330 100644 --- a/arch/arm/cpu/arm926ejs/Makefile +++ b/arch/arm/cpu/arm926ejs/Makefile @@ -26,7 +26,7 @@ include $(TOPDIR)/config.mk LIB = $(obj)lib$(CPU).o
START = start.o -COBJS = cpu.o +COBJS = cpu.o cache.o
SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) diff --git a/arch/arm/cpu/arm926ejs/cache.c b/arch/arm/cpu/arm926ejs/cache.c new file mode 100644 index 0000000..fc321f6 --- /dev/null +++ b/arch/arm/cpu/arm926ejs/cache.c @@ -0,0 +1,142 @@ +/* + * (C) Copyright 2002 + * Wolfgang Denk, DENX Software Engineering, wd@denx.de. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include <common.h> + +#define FLUSH_CACHE_OP 0 +#define INVALIDATE_CACHE_OP 1 + +#ifndef CONFIG_SYS_DCACHE_OFF +/* + * Flush or Invalidate DCache respectively + */ +static void cache_range_op(unsigned long start, unsigned long stop, int op) +{ + int cache_line_len; + unsigned long mva; + char *func_name; + + if (op == FLUSH_CACHE_OP) + func_name = "flush_dcache_range"; + else if (op == INVALIDATE_CACHE_OP) + func_name = "invalidate_dcache_range"; + else { + printf("WARNING: %s - Invalid cache operation!\n", __func__); + return; + } + +#ifdef CONFIG_SYS_CACHELINE_SIZE + cache_line_len = CONFIG_SYS_CACHELINE_SIZE; +#else + /* + * ARM926EJ-S Technical Reference Manual, Chap 2.3.1 Table 2-9 + * only b'10, aka. 32 bytes cache line len is valid + */ + cache_line_len = 32; +#endif + mva = start; + if ((mva & (cache_line_len - 1)) != 0) { + printf("WARNING: %s - start address 0x%08x not aligned to" + "cache line size(%d bytes)\n", func_name, start, + cache_line_len); + /* Round up starting address */ + mva = (mva | (cache_line_len - 1)) + 1; + } + if ((stop & (cache_line_len - 1)) != 0) { + printf("WARNING: %s - stop address 0x%08x not aligned to" + "cache line size(%d bytes)\n", func_name, stop, + cache_line_len); + /* Round down ending address */ + stop &= ~(cache_line_len - 1); + } + + while (mva < stop) { + if (op == FLUSH_CACHE_OP) + asm("mcr p15, 0, %0, c7, c14, 1\n" : : "r"(mva)); + else + asm("mcr p15, 0, %0, c7, c6, 1\n" : : "r"(mva)); + + mva += cache_line_len; + } + + /* Drain WB if necessary */ + if (op == FLUSH_CACHE_OP) + asm("mcr p15, 0, %0, c7, c10, 4\n" : : "r" (0)); +} + +/* + * The buffer range to be flushed is [start, stop) + */ +void flush_dcache_range(unsigned long start, unsigned long stop) +{ + cache_range_op(start, stop, FLUSH_CACHE_OP); +} + +void flush_dcache_all(void) +{ + /* + * ARM926EJ-S Technical Reference Manual, Chap 2.3.8 + * Clean & Invalidate the entire DCache + */ + asm("0: mrc p15, 0, r15, c7, c14, 3\n\t" "bne 0b\n" : : : "memory"); + /* Drain WB */ + asm("mcr p15, 0, %0, c7, c10, 4\n" : : "r" (0)); +} + +void flush_cache(unsigned long start, unsigned long size) +{ + flush_dcache_range(start, start + size); +} + +/* + * The buffer range to be invalidated is [start, stop) + */ +void invalidate_dcache_range(unsigned long start, unsigned long stop) +{ + cache_range_op(start, stop, INVALIDATE_CACHE_OP); +} + +void invalidate_dcache_all(void) +{ + asm("mcr p15, 0, %0, c7, c6, 0\n" : : "r" (0)); +} + +#else /* #ifndef CONFIG_SYS_DCACHE_OFF */ + +void flush_cache(unsigned long start, unsigned long size) {} +void flush_dcache_all(void) {} +void flush_dcache_range(unsigned long start, unsigned long stop) {} +void invalidate_dcache_range(unsigned long start, unsigned long stop) {} +void invalidate_dcache_all(void) {} +#endif + +#ifndef CONFIG_SYS_ICACHE_OFF +void invalidate_icache_all(void) +{ + asm("mcr p15, 0, %0, c7, c5, 0\n" : : "r" (0)); +} + +#else /* #ifndef CONFIG_SYS_ICACHE_OFF */ + +void invalidate_icache_all(void) {} +#endif
On Thursday, August 11, 2011 05:27:37 AM Hong Xu wrote:
Add a new file arch/arm/cpu/arm926ejs/cache.c and put cache operations into this file.
Signed-off-by: Hong Xu hong.xu@atmel.com
V2: Fixed a typo when CONFIG_SYS_DCACHE_OFF is defined V3: Undo changes in include/configs/at91sam9260ek.h It's for testing purpose
arch/arm/cpu/arm926ejs/Makefile | 2 +- arch/arm/cpu/arm926ejs/cache.c | 142 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 143 insertions(+), 1 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/cache.c
diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..5b5f330 100644 --- a/arch/arm/cpu/arm926ejs/Makefile +++ b/arch/arm/cpu/arm926ejs/Makefile @@ -26,7 +26,7 @@ include $(TOPDIR)/config.mk LIB = $(obj)lib$(CPU).o
START = start.o -COBJS = cpu.o +COBJS = cpu.o cache.o
SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) diff --git a/arch/arm/cpu/arm926ejs/cache.c b/arch/arm/cpu/arm926ejs/cache.c new file mode 100644 index 0000000..fc321f6 --- /dev/null +++ b/arch/arm/cpu/arm926ejs/cache.c @@ -0,0 +1,142 @@ +/*
- (C) Copyright 2002
- Wolfgang Denk, DENX Software Engineering, wd@denx.de.
Again ... really ?
- See file CREDITS for list of people who contributed to this
- project.
- This program is free software; you can redistribute it and/or
- modify it under the terms of the GNU General Public License as
- published by the Free Software Foundation; either version 2 of
- the License, or (at your option) any later version.
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- MA 02111-1307 USA
- */
+#include <common.h>
+#define FLUSH_CACHE_OP 0 +#define INVALIDATE_CACHE_OP 1
+#ifndef CONFIG_SYS_DCACHE_OFF +/*
- Flush or Invalidate DCache respectively
- */
+static void cache_range_op(unsigned long start, unsigned long stop, int op) +{
- int cache_line_len;
- unsigned long mva;
- char *func_name;
- if (op == FLUSH_CACHE_OP)
func_name = "flush_dcache_range";- else if (op == INVALIDATE_CACHE_OP)
func_name = "invalidate_dcache_range";- else {
printf("WARNING: %s - Invalid cache operation!\n", __func__);return;- }
hm... if (op > 2) printf(warning);
otherwise, just declare an array of strings ... char *name[] = { "flush", "invalidate" };
and access it where needed ... printf("%s", name[OP]); ... maybe ?
+#ifdef CONFIG_SYS_CACHELINE_SIZE
- cache_line_len = CONFIG_SYS_CACHELINE_SIZE;
+#else
- /*
* ARM926EJ-S Technical Reference Manual, Chap 2.3.1 Table 2-9* only b'10, aka. 32 bytes cache line len is valid*/- cache_line_len = 32;
+#endif
Move this at the begining of the file
#ifndef CONFIG_SYS... #define #endif
include the comment, just modify it a bit accordingly, explaining what it does here. Then use CONFIG_SYS... as it'll always be defined.
Otherwise looks good.
I need sleep badly :-) Good night !
- mva = start;
- if ((mva & (cache_line_len - 1)) != 0) {
printf("WARNING: %s - start address 0x%08x not aligned to""cache line size(%d bytes)\n", func_name, start,cache_line_len);/* Round up starting address */mva = (mva | (cache_line_len - 1)) + 1;- }
- if ((stop & (cache_line_len - 1)) != 0) {
printf("WARNING: %s - stop address 0x%08x not aligned to""cache line size(%d bytes)\n", func_name, stop,cache_line_len);/* Round down ending address */stop &= ~(cache_line_len - 1);- }
- while (mva < stop) {
if (op == FLUSH_CACHE_OP)asm("mcr p15, 0, %0, c7, c14, 1\n" : : "r"(mva));elseasm("mcr p15, 0, %0, c7, c6, 1\n" : : "r"(mva));mva += cache_line_len;- }
- /* Drain WB if necessary */
- if (op == FLUSH_CACHE_OP)
asm("mcr p15, 0, %0, c7, c10, 4\n" : : "r" (0));+}
+/*
- The buffer range to be flushed is [start, stop)
- */
+void flush_dcache_range(unsigned long start, unsigned long stop) +{
- cache_range_op(start, stop, FLUSH_CACHE_OP);
+}
+void flush_dcache_all(void) +{
- /*
* ARM926EJ-S Technical Reference Manual, Chap 2.3.8* Clean & Invalidate the entire DCache*/- asm("0: mrc p15, 0, r15, c7, c14, 3\n\t" "bne 0b\n" : : : "memory");
- /* Drain WB */
- asm("mcr p15, 0, %0, c7, c10, 4\n" : : "r" (0));
+}
+void flush_cache(unsigned long start, unsigned long size) +{
- flush_dcache_range(start, start + size);
+}
+/*
- The buffer range to be invalidated is [start, stop)
- */
+void invalidate_dcache_range(unsigned long start, unsigned long stop) +{
- cache_range_op(start, stop, INVALIDATE_CACHE_OP);
+}
+void invalidate_dcache_all(void) +{
- asm("mcr p15, 0, %0, c7, c6, 0\n" : : "r" (0));
+}
+#else /* #ifndef CONFIG_SYS_DCACHE_OFF */
+void flush_cache(unsigned long start, unsigned long size) {} +void flush_dcache_all(void) {} +void flush_dcache_range(unsigned long start, unsigned long stop) {} +void invalidate_dcache_range(unsigned long start, unsigned long stop) {} +void invalidate_dcache_all(void) {} +#endif
+#ifndef CONFIG_SYS_ICACHE_OFF +void invalidate_icache_all(void) +{
- asm("mcr p15, 0, %0, c7, c5, 0\n" : : "r" (0));
+}
+#else /* #ifndef CONFIG_SYS_ICACHE_OFF */
+void invalidate_icache_all(void) {} +#endif
Hi Marek,
On 08/11/2011 12:47 PM, Marek Vasut wrote:
On Thursday, August 11, 2011 05:27:37 AM Hong Xu wrote:
Add a new file arch/arm/cpu/arm926ejs/cache.c and put cache operations into this file.
Signed-off-by: Hong Xuhong.xu@atmel.com
V2: Fixed a typo when CONFIG_SYS_DCACHE_OFF is defined V3: Undo changes in include/configs/at91sam9260ek.h It's for testing purpose
arch/arm/cpu/arm926ejs/Makefile | 2 +- arch/arm/cpu/arm926ejs/cache.c | 142 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 143 insertions(+), 1 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/cache.c
diff --git a/arch/arm/cpu/arm926ejs/Makefile b/arch/arm/cpu/arm926ejs/Makefile index 930e0d1..5b5f330 100644 --- a/arch/arm/cpu/arm926ejs/Makefile +++ b/arch/arm/cpu/arm926ejs/Makefile @@ -26,7 +26,7 @@ include $(TOPDIR)/config.mk LIB = $(obj)lib$(CPU).o
START = start.o -COBJS = cpu.o +COBJS = cpu.o cache.o
SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS)) diff --git a/arch/arm/cpu/arm926ejs/cache.c b/arch/arm/cpu/arm926ejs/cache.c new file mode 100644 index 0000000..fc321f6 --- /dev/null +++ b/arch/arm/cpu/arm926ejs/cache.c @@ -0,0 +1,142 @@ +/*
- (C) Copyright 2002
- Wolfgang Denk, DENX Software Engineering, wd@denx.de.
Again ... really ?
not sure... add a new copyright line on top of it?
- See file CREDITS for list of people who contributed to this
- project.
- This program is free software; you can redistribute it and/or
- modify it under the terms of the GNU General Public License as
- published by the Free Software Foundation; either version 2 of
- the License, or (at your option) any later version.
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- MA 02111-1307 USA
- */
+#include<common.h>
+#define FLUSH_CACHE_OP 0 +#define INVALIDATE_CACHE_OP 1
+#ifndef CONFIG_SYS_DCACHE_OFF +/*
- Flush or Invalidate DCache respectively
- */
+static void cache_range_op(unsigned long start, unsigned long stop, int op) +{
- int cache_line_len;
- unsigned long mva;
- char *func_name;
- if (op == FLUSH_CACHE_OP)
func_name = "flush_dcache_range";- else if (op == INVALIDATE_CACHE_OP)
func_name = "invalidate_dcache_range";- else {
printf("WARNING: %s - Invalid cache operation!\n", __func__);return;- }
well, looks removing it and printing the `op' code is enough.
hm... if (op> 2) printf(warning);
otherwise, just declare an array of strings ... char *name[] = { "flush", "invalidate" };
and access it where needed ... printf("%s", name[OP]); ... maybe ?
+#ifdef CONFIG_SYS_CACHELINE_SIZE
- cache_line_len = CONFIG_SYS_CACHELINE_SIZE;
+#else
- /*
* ARM926EJ-S Technical Reference Manual, Chap 2.3.1 Table 2-9* only b'10, aka. 32 bytes cache line len is valid*/- cache_line_len = 32;
+#endif
Move this at the begining of the file
#ifndef CONFIG_SYS... #define #endif
include the comment, just modify it a bit accordingly, explaining what it does here. Then use CONFIG_SYS... as it'll always be defined.
OK, looks better.
BR, Eric
Otherwise looks good.
I need sleep badly :-) Good night !
- mva = start;
- if ((mva& (cache_line_len - 1)) != 0) {
printf("WARNING: %s - start address 0x%08x not aligned to""cache line size(%d bytes)\n", func_name, start,
[...]
Hi Hong,
On Mon, Aug 15, 2011 at 03:08:51PM +0800, Hong Xu wrote:
Hi Marek,
On 08/11/2011 12:47 PM, Marek Vasut wrote:
On Thursday, August 11, 2011 05:27:37 AM Hong Xu wrote:
Add a new file arch/arm/cpu/arm926ejs/cache.c and put cache operations into this file.
Signed-off-by: Hong Xuhong.xu@atmel.com
V2: Fixed a typo when CONFIG_SYS_DCACHE_OFF is defined V3: Undo changes in include/configs/at91sam9260ek.h It's for testing purpose
arch/arm/cpu/arm926ejs/Makefile | 2 +- arch/arm/cpu/arm926ejs/cache.c | 142 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 143 insertions(+), 1 deletions(-) create mode 100644 arch/arm/cpu/arm926ejs/cache.c
What is the status for this patch ?
I have failed to find any trace for this patch in patchwork or in the arm git repository...
Regards,
Simon
On Friday, September 02, 2011 12:22:05 PM Simon Guinot wrote:
Hi Hong,
On Mon, Aug 15, 2011 at 03:08:51PM +0800, Hong Xu wrote:
Hi Marek,
On 08/11/2011 12:47 PM, Marek Vasut wrote:
On Thursday, August 11, 2011 05:27:37 AM Hong Xu wrote:
Add a new file arch/arm/cpu/arm926ejs/cache.c and put cache operations into this file.
Signed-off-by: Hong Xuhong.xu@atmel.com
V2: Fixed a typo when CONFIG_SYS_DCACHE_OFF is defined
V3: Undo changes in include/configs/at91sam9260ek.h It's for testing purpose
arch/arm/cpu/arm926ejs/Makefile | 2 +- arch/arm/cpu/arm926ejs/cache.c | 142
+++++++++++++++++++++++++++++++++++++++ 2 files changed, 143 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/cpu/arm926ejs/cache.c
What is the status for this patch ?
I have failed to find any trace for this patch in patchwork or in the arm git repository...
We discussed this should be moved to arch/arm/cpu/armv5 (Aneesh V's idea ... I dunno what's this guys' full name ;-D). I tested this patch on certain type of CPU and it works really good. I'd be really glad if we got this mainline!
Cheers
Regards,
Simon
On Fri, Sep 02, 2011 at 12:23:54PM +0200, Marek Vasut wrote:
On Friday, September 02, 2011 12:22:05 PM Simon Guinot wrote:
Hi Hong,
On Mon, Aug 15, 2011 at 03:08:51PM +0800, Hong Xu wrote:
Hi Marek,
On 08/11/2011 12:47 PM, Marek Vasut wrote:
On Thursday, August 11, 2011 05:27:37 AM Hong Xu wrote:
Add a new file arch/arm/cpu/arm926ejs/cache.c and put cache operations into this file.
Signed-off-by: Hong Xuhong.xu@atmel.com
V2: Fixed a typo when CONFIG_SYS_DCACHE_OFF is defined
V3: Undo changes in include/configs/at91sam9260ek.h It's for testing purpose
arch/arm/cpu/arm926ejs/Makefile | 2 +- arch/arm/cpu/arm926ejs/cache.c | 142
+++++++++++++++++++++++++++++++++++++++ 2 files changed, 143 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/cpu/arm926ejs/cache.c
What is the status for this patch ?
I have failed to find any trace for this patch in patchwork or in the arm git repository...
We discussed this should be moved to arch/arm/cpu/armv5 (Aneesh V's idea ... I dunno what's this guys' full name ;-D). I tested this patch on certain type of CPU and it works really good. I'd be really glad if we got this mainline!
Yes. Moreover some drivers (as mvgbe) really needs such functions to fix the DMA operations when D-cache is enabled.
Simon
On Friday, September 02, 2011 01:43:39 PM Simon Guinot wrote:
On Fri, Sep 02, 2011 at 12:23:54PM +0200, Marek Vasut wrote:
On Friday, September 02, 2011 12:22:05 PM Simon Guinot wrote:
Hi Hong,
On Mon, Aug 15, 2011 at 03:08:51PM +0800, Hong Xu wrote:
Hi Marek,
On 08/11/2011 12:47 PM, Marek Vasut wrote:
On Thursday, August 11, 2011 05:27:37 AM Hong Xu wrote:
Add a new file arch/arm/cpu/arm926ejs/cache.c and put cache operations into this file.
Signed-off-by: Hong Xuhong.xu@atmel.com
V2: Fixed a typo when CONFIG_SYS_DCACHE_OFF is defined
V3: Undo changes in include/configs/at91sam9260ek.h It's for testing purpose
arch/arm/cpu/arm926ejs/Makefile | 2 +- arch/arm/cpu/arm926ejs/cache.c | 142
+++++++++++++++++++++++++++++++++++++++ 2 files changed, 143 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/cpu/arm926ejs/cache.c
What is the status for this patch ?
I have failed to find any trace for this patch in patchwork or in the arm git repository...
We discussed this should be moved to arch/arm/cpu/armv5 (Aneesh V's idea ... I dunno what's this guys' full name ;-D). I tested this patch on certain type of CPU and it works really good. I'd be really glad if we got this mainline!
Yes. Moreover some drivers (as mvgbe) really needs such functions to fix the DMA operations when D-cache is enabled.
I have some fixes already queued, yes.
Simon
Le 02/09/2011 13:57, Marek Vasut a écrit :
On Friday, September 02, 2011 01:43:39 PM Simon Guinot wrote:
On Fri, Sep 02, 2011 at 12:23:54PM +0200, Marek Vasut wrote:
On Friday, September 02, 2011 12:22:05 PM Simon Guinot wrote:
Hi Hong,
On Mon, Aug 15, 2011 at 03:08:51PM +0800, Hong Xu wrote:
Hi Marek,
On 08/11/2011 12:47 PM, Marek Vasut wrote:
On Thursday, August 11, 2011 05:27:37 AM Hong Xu wrote: > Add a new file arch/arm/cpu/arm926ejs/cache.c and put cache > operations into this file. > > Signed-off-by: Hong Xuhong.xu@atmel.com > --- > > V2: > Fixed a typo when CONFIG_SYS_DCACHE_OFF is defined > > V3: > Undo changes in include/configs/at91sam9260ek.h > It's for testing purpose > > arch/arm/cpu/arm926ejs/Makefile | 2 +- > arch/arm/cpu/arm926ejs/cache.c | 142 > > +++++++++++++++++++++++++++++++++++++++ 2 files changed, 143 > insertions(+), 1 deletions(-) > > create mode 100644 arch/arm/cpu/arm926ejs/cache.c
What is the status for this patch ?
I have failed to find any trace for this patch in patchwork or in the arm git repository...
We discussed this should be moved to arch/arm/cpu/armv5 (Aneesh V's idea ... I dunno what's this guys' full name ;-D). I tested this patch on certain type of CPU and it works really good. I'd be really glad if we got this mainline!
Yes. Moreover some drivers (as mvgbe) really needs such functions to fix the DMA operations when D-cache is enabled.
I have some fixes already queued, yes.
Simon
Hi folks,
I'm trying to locate the latest version of this set's patches in patchwork and I can't find them at all in any state. What am I missing?
Amicalement,
Le 02/09/2011 13:57, Marek Vasut a écrit :
On Friday, September 02, 2011 01:43:39 PM Simon Guinot wrote:
On Fri, Sep 02, 2011 at 12:23:54PM +0200, Marek Vasut wrote:
On Friday, September 02, 2011 12:22:05 PM Simon Guinot wrote:
Hi Hong,
On Mon, Aug 15, 2011 at 03:08:51PM +0800, Hong Xu wrote:
Hi Marek,
On 08/11/2011 12:47 PM, Marek Vasut wrote: > On Thursday, August 11, 2011 05:27:37 AM Hong Xu wrote: > > Add a new file arch/arm/cpu/arm926ejs/cache.c and put cache > > operations into this file. > > > > Signed-off-by: Hong Xuhong.xu@atmel.com > > --- > > > > V2: > > Fixed a typo when CONFIG_SYS_DCACHE_OFF is defined > > > > V3: > > Undo changes in include/configs/at91sam9260ek.h > > It's for testing purpose > > > > arch/arm/cpu/arm926ejs/Makefile | 2 +- > > arch/arm/cpu/arm926ejs/cache.c | 142 > > > > +++++++++++++++++++++++++++++++++++++++ 2 files changed, > > 143 insertions(+), 1 deletions(-) > > > > create mode 100644 arch/arm/cpu/arm926ejs/cache.c
What is the status for this patch ?
I have failed to find any trace for this patch in patchwork or in the arm git repository...
We discussed this should be moved to arch/arm/cpu/armv5 (Aneesh V's idea ... I dunno what's this guys' full name ;-D). I tested this patch on certain type of CPU and it works really good. I'd be really glad if we got this mainline!
Yes. Moreover some drivers (as mvgbe) really needs such functions to fix the DMA operations when D-cache is enabled.
I have some fixes already queued, yes.
Simon
Hi folks,
I'm trying to locate the latest version of this set's patches in patchwork and I can't find them at all in any state. What am I missing?
Hi Albert,
you're missing the move from cpu/arm926ejs to cpu/armv5/ . Though I'd prefer to have it in arm926 for now as we still didn't verify the other cores are ok with it (I changed my opinion just recently). For example, xscale isn't. So maybe we can pick the patches as they are.
Cheers!
Amicalement,
Albert.
Le 05/09/2011 21:50, Marek Vasut a écrit :
Le 02/09/2011 13:57, Marek Vasut a écrit :
On Friday, September 02, 2011 01:43:39 PM Simon Guinot wrote:
On Fri, Sep 02, 2011 at 12:23:54PM +0200, Marek Vasut wrote:
On Friday, September 02, 2011 12:22:05 PM Simon Guinot wrote:
Hi Hong,
On Mon, Aug 15, 2011 at 03:08:51PM +0800, Hong Xu wrote: > Hi Marek, > > On 08/11/2011 12:47 PM, Marek Vasut wrote: >> On Thursday, August 11, 2011 05:27:37 AM Hong Xu wrote: >>> Add a new file arch/arm/cpu/arm926ejs/cache.c and put cache >>> operations into this file. >>> >>> Signed-off-by: Hong Xuhong.xu@atmel.com >>> --- >>> >>> V2: >>> Fixed a typo when CONFIG_SYS_DCACHE_OFF is defined >>> >>> V3: >>> Undo changes in include/configs/at91sam9260ek.h >>> It's for testing purpose >>> >>> arch/arm/cpu/arm926ejs/Makefile | 2 +- >>> arch/arm/cpu/arm926ejs/cache.c | 142 >>> >>> +++++++++++++++++++++++++++++++++++++++ 2 files changed, >>> 143 insertions(+), 1 deletions(-) >>> >>> create mode 100644 arch/arm/cpu/arm926ejs/cache.c
What is the status for this patch ?
I have failed to find any trace for this patch in patchwork or in the arm git repository...
We discussed this should be moved to arch/arm/cpu/armv5 (Aneesh V's idea ... I dunno what's this guys' full name ;-D). I tested this patch on certain type of CPU and it works really good. I'd be really glad if we got this mainline!
Yes. Moreover some drivers (as mvgbe) really needs such functions to fix the DMA operations when D-cache is enabled.
I have some fixes already queued, yes.
Simon
Hi folks,
I'm trying to locate the latest version of this set's patches in patchwork and I can't find them at all in any state. What am I missing?
Hi Albert,
you're missing the move from cpu/arm926ejs to cpu/armv5/ . Though I'd prefer to have it in arm926 for now as we still didn't verify the other cores are ok with it (I changed my opinion just recently). For example, xscale isn't. So maybe we can pick the patches as they are.
Seems like we're having two problems there:
1) at least some cpus or cores (xscale) do not implement all of what was thought to be armv5 cache operations, which suggests we should indeed keep this patch in arm926ejs;
2) that many cpus and cores implement a good subset of armv5 cache operations, which warrants having an armv5 directory where we would define them once only for all to use.
I think the Right Way is to create an armv5 subtree with armv5-common operations, but with the capability of overruling these with cpu-level variants, themselves being possibly overridden by core-level variants.
Now as to where to put this:
As ARMv5 is an ISA, not a cpu or core, I'm uncomfortable with creating arch/arm/cpu/armv5 anyway. I'd prefer an ISA subtree, either in parallel with the cpu subtree: arch/arm/isa [/armv5], or, and I would slightly prefer that even though some paths would become rather long, a hierarchy withe cpus stand below their isa: arch/arm/isa [/armv5/cpu/arm926ejs]. To reduce path length, we could remove the 'cpu' part and consider that anything below the 'isa' is a cpu, just like currently anything below the cpu is a core.
To sum it up, we would have
arch/arm/isa/armv5 (where ARMv5t ISA common code would reside, including cache ops)
arch/arm/isa/armv5/arm926ejs (where ARM926EJ-S cpu common code would reside, including cache ops)
arch/arm/isa/armv5/arm926ejs/orion5x (a personal favorite :) where Orion5x core code would reside, including cache ops)
Maybe we could even make do without the .../isa/... level and put ISAs directly under ARM -- I don't think any ARM ISA will ever be named 'include' or 'lib' or 'Makefile'. :)
Comments?
Cheers!
Amicalement,
On Tuesday, September 06, 2011 08:19:26 AM Albert ARIBAUD wrote:
Le 05/09/2011 21:50, Marek Vasut a écrit :
Le 02/09/2011 13:57, Marek Vasut a écrit :
On Friday, September 02, 2011 01:43:39 PM Simon Guinot wrote:
On Fri, Sep 02, 2011 at 12:23:54PM +0200, Marek Vasut wrote:
On Friday, September 02, 2011 12:22:05 PM Simon Guinot wrote: > Hi Hong, > > On Mon, Aug 15, 2011 at 03:08:51PM +0800, Hong Xu wrote: >> Hi Marek, >> >> On 08/11/2011 12:47 PM, Marek Vasut wrote: >>> On Thursday, August 11, 2011 05:27:37 AM Hong Xu wrote: >>>> Add a new file arch/arm/cpu/arm926ejs/cache.c and put cache >>>> operations into this file. >>>> >>>> Signed-off-by: Hong Xuhong.xu@atmel.com >>>> --- >>>> >>>> V2: >>>> Fixed a typo when CONFIG_SYS_DCACHE_OFF is defined >>>> >>>> V3: >>>> Undo changes in include/configs/at91sam9260ek.h >>>> It's for testing purpose >>>> >>>> arch/arm/cpu/arm926ejs/Makefile | 2 +- >>>> arch/arm/cpu/arm926ejs/cache.c | 142 >>>> >>>> +++++++++++++++++++++++++++++++++++++++ 2 files changed, >>>> 143 insertions(+), 1 deletions(-) >>>> >>>> create mode 100644 arch/arm/cpu/arm926ejs/cache.c > > What is the status for this patch ? > > I have failed to find any trace for this patch in patchwork or > in the arm git repository...
We discussed this should be moved to arch/arm/cpu/armv5 (Aneesh V's idea ... I dunno what's this guys' full name ;-D). I tested this patch on certain type of CPU and it works really good. I'd be really glad if we got this mainline!
Yes. Moreover some drivers (as mvgbe) really needs such functions to fix the DMA operations when D-cache is enabled.
I have some fixes already queued, yes.
Simon
Hi folks,
I'm trying to locate the latest version of this set's patches in patchwork and I can't find them at all in any state. What am I missing?
Hi Albert,
you're missing the move from cpu/arm926ejs to cpu/armv5/ . Though I'd prefer to have it in arm926 for now as we still didn't verify the other cores are ok with it (I changed my opinion just recently). For example, xscale isn't. So maybe we can pick the patches as they are.
Seems like we're having two problems there:
- at least some cpus or cores (xscale) do not implement all of what was
thought to be armv5 cache operations, which suggests we should indeed keep this patch in arm926ejs;
- that many cpus and cores implement a good subset of armv5 cache
operations, which warrants having an armv5 directory where we would define them once only for all to use.
I think the Right Way is to create an armv5 subtree with armv5-common operations, but with the capability of overruling these with cpu-level variants, themselves being possibly overridden by core-level variants.
All right, but what about the CPUs that don't adapt so fast? There will be CPUs with broken cache-ops. How do you intend to solve that ?
Now as to where to put this:
As ARMv5 is an ISA, not a cpu or core, I'm uncomfortable with creating arch/arm/cpu/armv5 anyway. I'd prefer an ISA subtree, either in parallel with the cpu subtree: arch/arm/isa [/armv5], or, and I would slightly prefer that even though some paths would become rather long, a hierarchy withe cpus stand below their isa: arch/arm/isa [/armv5/cpu/arm926ejs]. To reduce path length, we could remove the 'cpu' part and consider that anything below the 'isa' is a cpu, just like currently anything below the cpu is a core.
This is completely out of scope for this patch. My proposal would be to merge this, then start mucking with this moving files around.
To sum it up, we would have
arch/arm/isa/armv5 (where ARMv5t ISA common code would reside, including cache ops)
arch/arm/isa/armv5/arm926ejs (where ARM926EJ-S cpu common code would reside, including cache ops)
arch/arm/isa/armv5/arm926ejs/orion5x (a personal favorite :) where Orion5x core code would reside, including cache ops)
Maybe we could even make do without the .../isa/... level and put ISAs directly under ARM -- I don't think any ARM ISA will ever be named 'include' or 'lib' or 'Makefile'. :)
Comments?
I'll have to think about it, but there is my proposal above. Please consider it, it'll help while dodging the trouble for a while until this is settled.
Cheers!
Amicalement,
Cheers
(splitting this discussion between the patch and my longer term RFC, here I follow the patch, keeping the subject line unchanged)
Le 06/09/2011 08:40, Marek Vasut a écrit :
This is completely out of scope for this patch. My proposal would be to merge this, then start mucking with this moving files around.
Agreed. My proposal was more of a longer term RFC)
I'll have to think about it, but there is my proposal above. Please consider it, it'll help while dodging the trouble for a while until this is settled.
If you mean 'have arm-generic weak defaults in arch/arm and arm926ejs implementation in arch/arm/cpu/arm926ejs', I'm ok with that.
Amicalement,
On Tuesday, September 06, 2011 01:38:46 PM Albert ARIBAUD wrote:
(splitting this discussion between the patch and my longer term RFC, here I follow the patch, keeping the subject line unchanged)
Le 06/09/2011 08:40, Marek Vasut a écrit :
This is completely out of scope for this patch. My proposal would be to merge this, then start mucking with this moving files around.
Agreed. My proposal was more of a longer term RFC)
I'll have to think about it, but there is my proposal above. Please consider it, it'll help while dodging the trouble for a while until this is settled.
If you mean 'have arm-generic weak defaults in arch/arm and arm926ejs implementation in arch/arm/cpu/arm926ejs', I'm ok with that.
Yes please.
Amicalement,
Cheers
(splitting this discussion between the patch question and longer term RFC, here I follow the RFC and update the subject line accordingly)
Seems like we're having two problems there:
- at least some cpus or cores (xscale) do not implement all of what was
thought to be armv5 cache operations, which suggests we should indeed keep this patch in arm926ejs;
- that many cpus and cores implement a good subset of armv5 cache
operations, which warrants having an armv5 directory where we would define them once only for all to use.
I think the Right Way is to create an armv5 subtree with armv5-common operations, but with the capability of overruling these with cpu-level variants, themselves being possibly overridden by core-level variants.
All right, but what about the CPUs that don't adapt so fast?
Adapt to what?
There will be CPUs with broken cache-ops. How do you intend to solve that ?
If a cpu has partly broken cache ops, but its cache is still useable by not using the armv5-stock cache ops implementation, then the cpu should override the broken armv5 ops with its own version.
For instance, say some armv5 based cpu badly implements full flush but correctly implements cache line flush. The cpu code should then provide its own version of the full cache flush op, based on looping through the cache lines instead of the armv5 single coprocessor instruction.
If, OTOH, a cpu has broken cache ops, to the point that cache is unuseable, then it should have its cache disabled, which can be done through configuration options or by providing cpu-specific cache ops implementations that will emit appropriate messages.
Now as to where to put this:
As ARMv5 is an ISA, not a cpu or core, I'm uncomfortable with creating arch/arm/cpu/armv5 anyway. I'd prefer an ISA subtree, either in parallel with the cpu subtree: arch/arm/isa [/armv5], or, and I would slightly prefer that even though some paths would become rather long, a hierarchy withe cpus stand below their isa: arch/arm/isa [/armv5/cpu/arm926ejs]. To reduce path length, we could remove the 'cpu' part and consider that anything below the 'isa' is a cpu, just like currently anything below the cpu is a core.
This is completely out of scope for this patch. My proposal would be to merge this, then start mucking with this moving files around.
Indeed -- I was not suggestion a rework of the patch, only sending out an RFC of sorts.
To sum it up, we would have
arch/arm/isa/armv5 (where ARMv5t ISA common code would reside, including cache ops)
arch/arm/isa/armv5/arm926ejs (where ARM926EJ-S cpu common code would reside, including cache ops)
arch/arm/isa/armv5/arm926ejs/orion5x (a personal favorite :) where Orion5x core code would reside, including cache ops)
Maybe we could even make do without the .../isa/... level and put ISAs directly under ARM -- I don't think any ARM ISA will ever be named 'include' or 'lib' or 'Makefile'. :)
Comments?
I'll have to think about it,
By all means do. :)
Amicalement,
On Tuesday, September 06, 2011 01:43:33 PM Albert ARIBAUD wrote:
(splitting this discussion between the patch question and longer term RFC, here I follow the RFC and update the subject line accordingly)
Seems like we're having two problems there:
- at least some cpus or cores (xscale) do not implement all of what was
thought to be armv5 cache operations, which suggests we should indeed keep this patch in arm926ejs;
- that many cpus and cores implement a good subset of armv5 cache
operations, which warrants having an armv5 directory where we would define them once only for all to use.
I think the Right Way is to create an armv5 subtree with armv5-common operations, but with the capability of overruling these with cpu-level variants, themselves being possibly overridden by core-level variants.
All right, but what about the CPUs that don't adapt so fast?
Adapt to what?
Adapt to this new cache stuff. Some CPUs have no cache functions implemented at all and therefore with the new stuff, they will use the generic ones -- which might be not good.
There will be CPUs with broken cache-ops. How do you intend to solve that ?
If a cpu has partly broken cache ops, but its cache is still useable by not using the armv5-stock cache ops implementation, then the cpu should override the broken armv5 ops with its own version.
For instance, say some armv5 based cpu badly implements full flush but correctly implements cache line flush. The cpu code should then provide its own version of the full cache flush op, based on looping through the cache lines instead of the armv5 single coprocessor instruction.
If, OTOH, a cpu has broken cache ops, to the point that cache is unuseable, then it should have its cache disabled, which can be done through configuration options or by providing cpu-specific cache ops implementations that will emit appropriate messages.
Ack, agree.
Now as to where to put this:
As ARMv5 is an ISA, not a cpu or core, I'm uncomfortable with creating arch/arm/cpu/armv5 anyway. I'd prefer an ISA subtree, either in parallel with the cpu subtree: arch/arm/isa [/armv5], or, and I would slightly prefer that even though some paths would become rather long, a hierarchy withe cpus stand below their isa: arch/arm/isa [/armv5/cpu/arm926ejs]. To reduce path length, we could remove the 'cpu' part and consider that anything below the 'isa' is a cpu, just like currently anything below the cpu is a core.
This is completely out of scope for this patch. My proposal would be to merge this, then start mucking with this moving files around.
Indeed -- I was not suggestion a rework of the patch, only sending out an RFC of sorts.
To sum it up, we would have
arch/arm/isa/armv5 (where ARMv5t ISA common code would reside, including cache ops)
arch/arm/isa/armv5/arm926ejs (where ARM926EJ-S cpu common code would reside, including cache ops)
arch/arm/isa/armv5/arm926ejs/orion5x (a personal favorite :) where Orion5x core code would reside, including cache ops)
Maybe we could even make do without the .../isa/... level and put ISAs directly under ARM -- I don't think any ARM ISA will ever be named 'include' or 'lib' or 'Makefile'. :)
Comments?
I'll have to think about it,
By all means do. :)
Amicalement,
Cheers
Hi Albert,
On Tuesday 06 September 2011 05:13 PM, Albert ARIBAUD wrote:
(splitting this discussion between the patch question and longer term
[snip ...]
To sum it up, we would have
arch/arm/isa/armv5 (where ARMv5t ISA common code would reside, including cache ops)
arch/arm/isa/armv5/arm926ejs (where ARM926EJ-S cpu common code would reside, including cache ops)
arch/arm/isa/armv5/arm926ejs/orion5x (a personal favorite :) where Orion5x core code would reside, including cache ops)
Maybe we could even make do without the .../isa/... level and put ISAs directly under ARM -- I don't think any ARM ISA will ever be named 'include' or 'lib' or 'Makefile'. :)
Comments?
Here is a rather wild thought. I am not sure whether we can do such a thing for ARM alone. Just ideating:-)
arch/arm/cpu/<isa>/<cpu> arch/arm/soc/<soc-family>/<soc>
Reasoning: 1. SoCs in same SoC family typically share/can-share a lot of code. 2. SoCs in same SoC family need not necessarily have the same cpu. Usually a new SoC brings in a new CPU while maintaining a lot of peripheral IPs from the previous generation.
best regards, Aneesh
participants (6)
-
Albert ARIBAUD -
Aneesh V -
Hong Xu -
Marek Vasut -
Marek Vasut -
Simon Guinot