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

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hi Aneesh,

On 05/08/2011 12:47, Aneesh V wrote:
> Hi Eric,
>
> On Friday 05 August 2011 04:03 PM, Hong Xu wrote:
>> Hi Aneesh,
> [snip ..]
>>>
>>> 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. :)
>
> We have a fundamental problem when it comes to invalidating an
> un-aligned buffer. Either you flush the boundary lines and corrupt your
> buffer at boundaries OR you invalidate without flushing and corrupt
> memory around your buffer. Both are not good! The only real solution is
> to have aligned buffers, if you want to have D-cache enabled and do DMA
> at the same time.

Plus, there should not be *heavy* modifications; DMA engines tend to use 
essentially two types of memory-resident objects: data buffers and 
buffer descriptors. There's only a small handful of places in the driver 
code to look at to find where these objects are allocated and how.

So I stand by my opinion: since the cache invalidation routine should 
only be called with cache-aligned objects, there is no requirement to 
flush the first (resp. last) cache line in case of unaligned start 
(resp.stop), and I don't want cache operations performed when they are 
not required.

> br,
> Aneesh

Amicalement,
-- 
Albert.