[Top] [All Lists]

Re: [PATCH RESEND 1/6] MIPS: sync after cacheflush

To: Kevin Cernekee <>
Subject: Re: [PATCH RESEND 1/6] MIPS: sync after cacheflush
From: Shinya Kuribayashi <>
Date: Fri, 07 Jan 2011 01:17:52 +0900
Cc: Ralf Baechle <>,,,,,
Dkim-signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=XdjpO4FWLZQ/ 2pXR64yaFxnUxeY=; b=NJF5yWdqevE/wXfVCvL/U8zbaUiuOxuz+U3ghaobEsx6 j6AeWzQ/vBhRo64/NwLzrDegE2cTt0kFu7bZwCZ7r6VZBDHU+aRmABIy99YZe4f9 ozxkEDieO80tRzU+Ixgs9g/uD0J80QtS87YonWTF7s69cibPGDtNzSKTMIJcZ50=
Domainkey-signature: a=rsa-sha1; c=nofws;; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=amUoe6 ONVDaIDesiCRjA6vyg5TCGX/tF9hg62+1c0PmVEaHurXXTdGyGFoSS7WhfJMIdN3 tOUJizFpOy9ixFQAepMseer/79dW3k2omorarq0KiGjFg9u810wusefOdOkacfwB esKWWGXVZW+czZ7dcX+fY0uiHX5wP58ENwomM=
In-reply-to: <8eec0c63f92528c501c0e6a0c8396359@localhost>
Original-recipient: rfc822;
References: <8eec0c63f92528c501c0e6a0c8396359@localhost>
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101208 Thunderbird/3.1.7

sorry for my silence for several resending posts.  I talked with Ralf
on this briefly, when the patch was posted for the first time last
year.  He seems busy these days, so I'm trying to move things forward.

On 01/06/2011 04:31 PM, Kevin Cernekee wrote:
> On processors with deep write buffers, it is likely that many cycles
> will pass between a CACHE instruction and the time the data actually
> gets written out to DRAM.  Add a SYNC instruction to ensure that the
> buffers get emptied before the flush functions return.

Having a talk with appropriate people (probably including MIPS guys),
such CACHE behavior would be eventually considered to be _legitimate_,
Ralf said.  Thus we agree with this change required not only for BMIPS
cores, but also for the rest of processors, as one of cache features.

The problem is how to implement it.

Most of SYNC-equipped processors work fine without this treatment,
so unless it's required, we don't want to have __sync() after every
cacheflush operations.  Having SYNC there is somewhat waste of time.

> diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
> index b4923a7..dc5d9c4 100644
> --- a/arch/mips/mm/c-r4k.c
> +++ b/arch/mips/mm/c-r4k.c
> @@ -604,6 +604,7 @@ static void r4k_dma_cache_wback_inv(unsigned long addr, 
> unsigned long size)
>                       r4k_blast_scache();
>               else
>                       blast_scache_range(addr, addr + size);
> +             __sync();
>               return;
>       }

Just random thought, how it's going to be when implementing this as,
- sort of barrier
- sort of hazard
- one of cache features (e.g., cpu_has_xxx or similar way)
- and so on...

Another concern is that, except for four __sync() insertions, are we
missing other places?

Ralf also thinks that run-time probe & detection would be better than
build-time configuration.  Optimization is easy and won't be problem
here, so we'd like to keep things synthesized as much as possible.

I couldn't imagine the final shape how this patch should be as of now,


<Prev in Thread] Current Thread [Next in Thread>