[U-Boot] [PATCH 2/4] cache_v7: Check for dcache enablement in dcache flush functions

[Tom Rini <trini@ti.com>]

On 06/15/2012 07:48 AM, R, Sricharan wrote:
> Hi,
> 
>>> On Fri, Jun 15, 2012 at 12:31 AM, Tom Rini <trini@ti.com> wrote:
>>>> If we are built with D-CACHE enabled but have run 'dcache off' and then
>>>> attempt to flush unaligned regions we spam the console with problems
>>>> that aren't true (as the cache was off).
>>>>
>>>   Today we do cache maintenance operations after the dcache is turned off.
>>>   One example is before jumping to kernel, we try to invalidate the caches,
>>>   in cache turned off state. So with this patch those maintenance calls will
>>>   do nothing, which is not correct.
>>
>> Ah yes,  But, shouldn't we be doing these same operations as part of
>> turning the cache off?
>>
>   The problem is that while turning of dcaches, we flush it, and turn
>  cache and MMU off.  But these operations are not happening
>  automatically in a single call. So there is a chance of  valid
>  entries present in cache even after it is OFF.
> 
>  So we invalidate it before jumping to kernel.
> 
> In fact our procedure of turning off the caches and MMU should
> have a relook, to really ensure things are safe. I will check on
> this more.

OK, thanks.

>>>    If it is a problem with unaligned regions, then that is the only
>>> thing to be fixed
>>>   right ?. Just trying to understand why this change is required ?
>>
>> The problem is that within the USB/network/filesystem stacks we have a
>> lot of not cache safe alignments apparently.  Without this every '#' of
>> a tftp gives a screen full of error printfs.  So tftp'ing a kernel takes
>> minutes, not seconds, to complete.
>>
>  Ok,but when buffers are not aligned
>    isn't that you are going to have coherency problems ?

Exactly.  USB requires dcache to be turned off today.  With it turned
off it spams these messages making tftp to an aligned address take
minutes because the console is busy printing all of these messages about
flushes it didn't need to do.  The alternative is to build
omap4/omap5/etc with dcache disabled or USB disabled.

I think the answer here is we need to make sure that when we switch the
cache off (dcache_off()) we're always doing the kind of flushing that we
had been doing for the kernel.

-- 
Tom