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

[Tom Rini]

On 06/18/2012 07:13 AM, R, Sricharan wrote:
> Hi Tom,
> 
> On Fri, Jun 15, 2012 at 8:50 PM, Tom Rini <trini at ti.com> wrote:
>> On 06/15/2012 08:18 AM, R, Sricharan wrote:
>>> Hi,
>>> [snip..]
>>>>>>>    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.
>>>>
>>>     Ok, but who is calling cache maintenance in your case after
>>>    turning off caches ?
>>
>> The USB stack currently.
> 
>  Ok, in that case if
>  1) Alignment issue has to be fixed USB stack,  (or)

This is the correct, long term solution.

> 2) Better to turn off caches when say USB-EHCI is enabled ?

Doing that is what showed the issue to start with.  Running 'dcache off'
doesn't turn off attempted cache flushing.

>    (or)
> 
> 3) Turn of caches until cache library is fixed so that
>       we will not require any maintenance after turning it off.
>      ( I will work on this some time, this week)

This is also a good thing.  It just needs to make sure attempted flushes
don't spam the console, when cache is off :)

>  I am not sure which one to do, but definitely we should not
>  prevent it from executing as in the above patch. This may
>  lead to other issues.

OK.  I'll see how badly boot time goes up when dcache is off to start
with on a few boards.

-- 
Tom