From mboxrd@z Thu Jan 1 00:00:00 1970 From: Valentin R Sitsikov Date: Mon, 31 Aug 2009 07:56:10 +0000 Subject: Re: sh7785 cache question Message-Id: <4A9B821A.4000602@siemens.com> List-Id: References: <4A7A9C73.1070000@siemens.com> In-Reply-To: <4A7A9C73.1070000@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-sh@vger.kernel.org Hello Paul! Thanks a lot for your answer. I still can`t understand the situation with ocbi, ocbp, ocbwb on sh4-a. It is written what they should be used only with address starting from 0xf4000000 (Rn[31:24] = 0xF4 - memory mapped OC address area) . But there are some functions in the kerenl which use virtual address of zero page to manipulate with cache. I made some experiments and has a feeling what cache still can be controlled by ocbi... by using not only 0xf4000000 but any virtual address (which is not permitted by spec). So i am in doubts . May be You have some ideas if sh7785 could still use ocbi with virtual addresses? Best regards, Valentin. Paul Mundt wrote: > On Thu, Aug 06, 2009 at 01:03:47PM +0400, Valentin R Sitsikov wrote: > >> So my question is why still all cache related code for the sh-7785 in >> these instructions have effective address as operand instead of >> 0xF4XXXXXX ? >> >> > [snip] > > >> Also It is interesting if there any plans for remove associative write >> operation to memory mapped OC address array? >> >> > This has mostly been a compatibility thing, as these new methods do not > work on older parts while at the same time the associated write still > works with current parts, even though it's less than optimal and will > likely go away in the future. > > Currently there are a few cases that need to be handled: > > - icbi based I-cache flushing, especially for SMP parts where > broadcast invalidation is not handled by hardware. > > - decoupled I-cache and D-cache flushing, mostly for parts with > D-cache coherency that still need to maintain the I-cache bits. > > - D-cache flushing overloads for platforms that prefer using more > optimized routines. > > These are things that I am presently working on in the sh/cachetlb topic > branch getting things tidied up for highmem and variable SH-X3 cache > configurations, which in turn will also benefit SH-X2 cores when > everything is done. It's a bit slow going due to the amount of heavy > testing and benchmarking that needs to be done every step of the way, but > it's slowly getting there. > > Feel free to poke around at the topic branch if this is an area you are > interested in playing with, otherwise it should see a 2.6.32 merge. >