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

[Aneesh V <aneesh@ti.com>]

Hi Albert,

On Monday 08 August 2011 03:09 PM, Albert ARIBAUD wrote:
> Le 08/08/2011 10:24, Aneesh V a ?crit :
>> Hi Albert,
>>
>> On Sunday 07 August 2011 12:25 PM, Albert ARIBAUD wrote:
>>> Hi Aneesh,
>>>
>>> (cutting quotation for readability)
>>>
>>> Le 05/08/2011 16:59, Aneesh V a ?crit :
>>>> Hi Albert,
>>>
>>>> I don't dispute that having buffers aligned is the ideal scenario. The
>>>> question is about error-handling the situation when this requirement is
>>>> not met.
>>>
>>> I understand what you're trying to achieve in this respect, that is,
>>> make the code as correct as it can be under unspecified conditions. I
>>> believe we are differing in how we construe 'as correct as it can be':
>>> you want to make the implementation of the called function as correct as
>>> it can be' at the expense of introducing a non-intuitive behavior (flush
>>> while invalidating), while I prefer the overall system to be as correct
>>> as it can be by 'doing exactly what it says on the tin', i.e.
>>> invalidating only.
>>
>> I understand your point of view now. I shall update my cache fix series
>> to invalidate only the aligned part of the buffer and to print a big
>> warning when the buffer is not aligned.
>
> Thanks Aneesh.
>
> Another point I raised with Hong Xu's patch: for range-limited
> operations, in case of a misalignment, why not try to *reduce* to
> aligned addresses rather than *expand* it? Moving start up to the next
> cache line boundary, and moving stop down, would still cause an
> imperfect situation (can't help it anyway) but it would not affect third
> party data any more, only the data which the cache range operation was
> supposed to affect.
>
> What do you (and others) think?

I agree. Indeed this is what I meant when I wrote this above:
"invalidate *only the aligned part* of the buffer"

best regards,
Aneesh