[U-Boot] [PATCH] arm: socfpga: Fix cache configuration

[Stefan Roese <sr@denx.de>]

On 18.09.2015 08:34, Pavel Machek wrote:
> Hi!
>
>>>> With this patch:
>>>> => tftp 100000 big-40mb
>>>> Speed: 1000, full duplex
>>>> Using dwmac.ff702000 device
>>>> TFTP from server 192.168.1.54; our IP address is 192.168.1.252
>>>> Filename 'big-40mb'.
>>>> Load address: 0x100000
>>>> Loading: #################################################################
>>>>           #################################################################
>>>>           #################################################################
>>>>           #################################################################
>>>>           ##########################
>>>>           7.6 MiB/s
>>>>
>>>> A performance improvement of factor ~3.
>>>
>>> Ok, so you turn on write-back cache and it is faster.
>>
>> Its not only faster. My tests have shown, that the current implementation
>> (WRITEALLOC) does not enable the dcache at all. No performance difference
>> with dcache enable or disabled. I also tested this by removing the dcache
>> flush and invalidate calls from the ethernet driver. And tftp still worked
>> without any problems (same slow speed of course) with dcache enabled. On
>> platforms with a really enabled dcache, such a change leads to a non-working
>> network interface.
>
> Yes, so we were running with dcache disabled, which can mask _many_
> programming errors.

Of course.

>>> Now... do you have an explanation why this is safe to do? Are there
>>> cache flushes that need to be added to the code now that we turned on
>>> write-back?
>>
>> I have not found any issues yet with this patch added. The cache handling
>> calls (flush, invalidate) are already included in the code using it (e.g.
>> USB, ethernet, MMC).
>
> For generic code, you are right.
>
> What about socfpga-specific code? Will this still do the right thing
> with cache enabled? Do we have hardware registers mapped uncacheable?

Yes. Thats how it should be done for all platforms. Only for SDRAM 
dcache should be enabled. Otherwise we would run in many problems.

> Ok, I guess we should enable the cache and fix any bugs currently
> hidden.

This is also my feeling. Such problems should show pretty quickly.

Thanks,
Stefan