From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hong Xu Date: Fri, 05 Aug 2011 18:33:57 +0800 Subject: [U-Boot] [PATCH v2] ARM926ejs: Add routines to invalidate D-Cache In-Reply-To: <4E3B9753.3020002@ti.com> References: <1312519452-22926-1-git-send-email-hong.xu@atmel.com> <4E3B8A16.50604@aribaud.net> <4E3B8FF3.2070400@atmel.com> <4E3B91C1.2040307@aribaud.net> <4E3B9753.3020002@ti.com> Message-ID: <4E3BC715.9070706@atmel.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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