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,