From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Fri, 05 Aug 2011 11:20:08 +0200 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: <4E3BB5C8.1030902@aribaud.net> 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 05/08/2011 09:10, 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. AIUI, you describe what I requested, so I agree with it. :) And if there is an alignment requirement, then there is no need any more to flush lines when unaligned start/stop is passed, because it would only have a use for call cases that do not conform to the requirement. > best regards, > Aneesh Amicalement, -- Albert.