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

[Ilya Yanok <yanok@emcraft.com>]

Dear Wolfgang,

On 27.11.2011 22:49, Wolfgang Denk wrote:
>>> But the cahce support works fine for a lot of things - basicly
>>> everything except for the broken drivers.  Why do you want to make ALL
>>> user suffer from this, even if they don't intend to use the broken
>>> driver(s) at all?
>>
>> Please note that I've already fixed the driver itself but the patch is
>> still not accepted (because of this problem).
> 
> Because of which problem?

DaVinci building problem. After fixing the driver many DaVinci boards
failed to build because of missing cache functions.

>>>> But cache support is incomplete is the problem.  None of the flushing
>>>> operations exist.
>>>
>>> Then fix _THAT_.
>>
>> Hm. So I've fixed the broken driver but you aren't going to accept the
>> patch and say "Please go ahead and fix arm926ejs cache support also".
>> But it's not even the SoC type I'm working with...
> 
> I am aware of this. I don't think I rejected your driver patch.

Well, that wasn't you. But the series were rejected because of DaVinci
build failure. Now, with this patch rejected, the complete series is
going to be rejected again...

> I also did not say _you_ are supposed to add the necessary level of
> cache support for all SoCs that need it.

But to push my changes I have to add it, right?

Thinking once more about this... Can't we add stub implementation of
cache functions for arm926ejs? Something like this:

void flush_dcache_range(...)
{
	printf("Cache operations are not implemented, consider using 'dc off'
command or (better) implement cache support\n");
}

This will preserve status quo: we can leave D-Cache enabled on DaVinci
but user will have to disable it by hand before using network. On AM35x
network will work with caches enabled.

>> Alternatively we can just drop the driver cache-related fix, leave the
>> driver broken and work with the network with "dc off" trick on AM35x also.
>>
>> Do you think this will be better?
> 
> I think we have a number of different proposals here.  My assessment
> is:
> 
> Worst:  permanently disable data chache on all boards
> 
> slightly better:  leave the driver broken and use "dc off" before
>         running any network related commands
> 

Don't you think that adding stub implementation for cache functions on
arm926ejs and fixing the driver is better?

> best:  fix the driver and cache support and permanently enable it.

Regards, Ilya.