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

[Ilya Yanok <yanok@emcraft.com>]

Dear Wolfgang,

On 27.11.2011 22:09, Wolfgang Denk wrote:
>> To be clear, the problem is that today the driver is broken (not cache
>> safe) and this series of patches fixes that problem.  In doing so we
>> expose that arm926ejs doesn't have complete cache support today.
> 
> 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).

> For example, booting from NAND is probably MUCH faster with caches on.
> Why should we make this slower than necessary?
> 
>> 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...

>>> It should be sufficient to switch the cache off ("dc off") before
>>> runnign any network related commands (and you want to make sure to
>>> switch it on again afterwards).
>>
>> We can't because we can't compile the driver, once we make it cache
>> safe.  It's not today and at least anecdotally the driver doesn't work
>> today on these platforms unless you turn off dcache.
> 
> We cannot _compile_ the driver?  That's even worse and needs to be
> fixed.

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?

Regards, Ilya.