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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
