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

[Tom Rini]

On Sun, Nov 27, 2011 at 11:09 AM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Tom Rini,
>
> In message <CA+M6bXkFRqkzRtiPuLYN9Zi8ZtXCYQS+LAT4pbKD0nmb3NONdQ at mail.gmail.com> you wrote:
>>
>> > Why do we have to permanently disable the data cache just because the
>> > network driver is broken?  USB is also broken, and probably other
>> > drivers as well.
>>
>> 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?
>
> For example, booting from NAND is probably MUCH faster with caches on.
> Why should we make this slower than necessary?

To encourage someone with the domain knowledge to finish cache support
for the processor?

>> But cache support is incomplete is the problem.  None of the flushing
>> operations exist.
>
> Then fix _THAT_.

OK.

>> > 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.

That's what this patch was doing, by disabling the cache so it would
build.  To be clear, today it builds but doesn't work with cache on.

>> As a tangent, is pushing new network drivers that aren't cache safe OK
>> if we just say that you need to turn off the dcache before using?
>
> No.  We should not accept any such drivers any more.

Noted and as I suspected, thanks.

-- 
Tom