[U-Boot] [PATCH v2] ARM926ejs: Add routines to invalidate D-Cache

[Hong Xu]

Hi Aneesh,

On 08/05/2011 03:10 PM, Aneesh V wrote:
> Hi Hong, Albert,
>
> On Friday 05 August 2011 12:16 PM, Albert ARIBAUD wrote:
>> Le 05/08/2011 08:38, Hong Xu a écrit :
>>> Hi Albert,
>>>
>>> I've tried to deal with the case that the (start, stop) is not aligned.
>>> If mis-align happens, the adjacent lines will be cleaned before
>>> invalidating. And from my view it's impossible for a driver to always
>>> pass aligned address to invalidate_dcache_range.
>>
>> Why would it be impossible? If it is statically allocated it can use
>> __attribute__(aligned)) and if it is dynamically aligned, it can be
>> over-allocated to make sure it starts and ends at cache boundaries.
>>
>>> To answer your question in another email
>>>
>>> > How do you know the dirty data should be flushed rather than
>>> invalidated?
>>>
>>> "Dirty" means this cache is changed by CPU but not has not been written
>>> into memory or WB. If we invalidate it, data will lost. In most cases, I
>>> do not see a situation why the dirty data shall not be written into
>>> memory.
>>
>> The problem is the cases that fall outside of 'most'. This kind of issue
>> tends to have effects that, when unwanted, are extremely difficult to
>> link to their cause and makes for long and painful debugging.
>>
>
> IMHO, Hong's approach is correct. If the buffer that is invalidated is
> not aligned to cache-line, one cache-line at the respective boundary
> may have to be flushed to make sure the invalidation doesn't affect
> somebody else's memory.
>
> The solution is for drivers to ensure that any buffer that needs to be
> invalidated is aligned to cache-line boundary at both ends. The above
> approach puts this onus on the driver. I have documented the alignment
> requirement in my recent patch series for fixing arm cache problems.

I have not noticed the patch series. ;-)
If we put the alignment burden to the driver, I'm afraid many drivers 
which make use of something like a DMA controller have to modify the 
code heavily. This sounds not good. :)

BR,
Eric

> best regards,
> Aneesh