[U-Boot] [PATCH 3/3 v3] ARM: ARM926EJS - Add cache operations

[Marek Vasut <marek.vasut@gmail.com>]

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 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
> >>>>>> 
> >>>>>> 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.

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