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