[Top] [All Lists]

Re: [patch] R4k cache code synchronization

To: Ralf Baechle <>
Subject: Re: [patch] R4k cache code synchronization
From: "Maciej W. Rozycki" <>
Date: Fri, 10 Jan 2003 14:30:12 +0100 (MET)
In-reply-to: <>
Organization: Technical University of Gdansk
Original-recipient: rfc822;
On Fri, 10 Jan 2003, Ralf Baechle wrote:

> The reason for the existance of flush_cache_l1 and flush_cache_l2 is the
> Origin.  An empty flush_cache_all() is sufficient on the Origin because
> it's R10000 processor doesn't suffer from cache aliases.  During bootup
> we have to flush all caches or the cache coherence logic will send crazy
> exceptions at us.  For all other occasions just a flush of the primary
> caches is sufficient which is why there is flush_cache_l1.

 So flush_cache_l1() as currently defined is sufficient for DMA coherency
on the R10000, isn't it?

> So I think we want to wrap things a bit nicer but basically we have to
> keep those cacheops for the sake of the Origin.

 The naming is grossly incorrect.  If the R10000 has such a cache
semantics, then it should use flush_cache_all() (targetting L1) for
coherency and __flush_cache_all() (targetting L2; I assume L2 operations
imply L1 ones, otherwise the function should explicitly operate on L1,
too) for a maintenance flush.  Just like it's done for the 32-bit port. 

 There was a patch attached -- what about it? 


+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail:, PGP key available        +

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