[U-Boot] [RFC/PATCH] davinci: disable dcache on boards with EMAC

[Albert ARIBAUD]

Hi all,

Le 27/11/2011 20:36, Wolfgang Denk a écrit :

>> Don't you think that adding stub implementation for cache functions on
>> arm926ejs and fixing the driver is better?
>
> Yes, that would be the 4th approach, listed as "much better" :-)

Better yet, have an ARM-wide, not only ARM926EJ-S, cache framework with 
a hierarchy of cache function implementations, from ARM architectures to 
Cores / SoCs or even boards.

My general idea is that:

- each ISA (ARMv4/5/4/7/etc) should provide generic implementations for 
cache handling functions to all cores, SoCs, boards that use this ISA, 
and that implementation should be used by default;

- each core / SoC should be able to easily provide specific cache 
function variants to all boards based on it, on a function granularity 
(i.e. reuse as much of the ISA cache handling code as possible);

- maybe a board should be able to easily provide specific cache 
functions as well;

- the cache API should hide L1 / L2 intricacies at the client level, 
i.e. a driver that wants to flush to memory should just call 
'cache_flush_range(address, size)' without wondering which caches the 
board provides;

- global cache enable/disable/flush (as opposed to cache range) should 
be used only in very few cases (init and exit, meaning U-Boot startup 
and jum-to-OS cases).

The system of 'overloading' between lib, ISA and SoC / Core could be 
achieved through weak symbols maybe, or a set of CONFIG variables, e.g. 
CONFIG_ARM_CACHE_FLUSH would be set to the name of the function to use 
for cache flushing, etc.

However, I have very little time ATM even to try and keep up with 
patches and pull reqs, so I simply cannot submit any code for ARM cache 
handling. Thus anyone wishing to submit code along the lines above, or 
provide an RFC if they feel there is a better approach, is more than 
welcome, and I *promise* I'll give such submissions first priority -- at 
which point I suggest making sure I am in the "To:" list of the patch 
submission mails.

> Best regards,
>
> Wolfgang Denk

Amicalement,
-- 
Albert.