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

Albert ARIBAUD
2011-09-06T06:19:26Z

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.

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.