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

[Albert ARIBAUD]

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 at 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,
-- 
Albert.