RE: MPC8260 cache patch

["Patrick Doyle" <wpd at delcomsys dot com>]

OK, now I am confused.

I just looked at changing the 'DCACHE_SYNC()' macro in the five variants
currently in the powerpc source tree (mpc5xx, mpc8260, mpc8xx, ppc40x,
ppc60x).  I was planning on defining it in
"powerpc/arch/current/include/hal_cache.h" (with the usual trick of allowing
the variants to redefine it) because of my bias against cutting and pasting
code from one variant to another.  I figured that, at least the mpc8260 and
the ppc60x would benefit from this.  (Please chime in here if you have any
objections to this strategy, but it's not really what I wanted to get to
here).  What I learned was that the mpc5xx variant has no cache and I have
no idea what the SPR's that are manipulated in the mpc8xx variant do (so I
would leave those to override the arch definition in "hal_cache.h").  But,
what really caught my eye was the ppc40x variant, which uses the "dcbf"
instruction to flush (and invalidate) the cache line corresponding to the
given address.

So, here is my question:

Why don't we always use the "dcbf" instruction (in "hal_cache.h" -- and let
the mpc5xx variant override it for efficiency and, perhaps, let the mpc8xx
variant override because of whatever it needs to do with the SPRs, or
perhaps not -- but somebody else would have to test it for me)?  The "dcbf"
instruction is defined by the powerpc architecture, and, as I understand it,
will always do the "right thing" regardless of how a particular variant
implements its cache (i.e. split data & instruction, number of ways, etc...)
Is the "dcbf" instruction not used because it invalidates the cache as well
as flushing it?  Was it an oversight?  Would you like me to update the
architecture and the three (or even four) variant HALs as I have described
here instead of just doubling the number of lines in the 8260 and 60x
variants?

I'll be back in OMAP (i.e. innovator) land on Monday, so I won't be able to
play with this until Tuesday at the earliest, but please let me know what
you think.


On a related but different topic, I'm still not to sure about the disable
vs. disable and invalidate point.  It still sounds familiar to me, but I
don't see anything like that in the OMAP documenation (Jonathan's point
about it being one of Jesper's ports has me really worried here).  Perhaps
it was back when I was reading the MIPS book...

--wpd


> -----Original Message-----
> From: Gary Thomas [mailto:gary at mlbassoc dot com]
> Sent: Friday, March 28, 2003 11:34 AM
> To: Patrick Doyle
> Cc: Jonathan Larmour; eCos patches
> Subject: RE: MPC8260 cache patch
>
>
> On Fri, 2003-03-28 at 09:29, Patrick Doyle wrote:
> > Yes, I also think that it's safe in this case.
> > >
> > > I vaguely recall something about some architecture or variant (not
> > > powerpc) which had caches where, if you "just" disabled them, it would
> > > still use the cache lines that were still valid. So the invalidate was
> > > needed too. Perhaps Nick might remember the specifics? Although I also
> > > vaguely recall it was one of Jesper's ports.
> > Here's where you are making me wonder if it might be the OMAP
> port.  Gee,
> > you would think I could remember that sort of stuff from one day to the
> > next.  Sigh... I'll double check that, especially since, now that you
> > mention it, it sounds vaguely familiar to me as well.
> >
>
> I doubt that it would be any ARM or PowerPC port.  It might have been
> SH though.
>
> > I guess I've got some cache problems of my own. :-)  Gary, we
> once discussed
> > ugrading to the new 2.0 brains, have you heard anything about
> them lately?
> > I've got two newer model Patricks in development right now, but they are
> > only 2.5 years and 5 months old, so I think it will be while
> before I can
> > depend on them for support.
> >
>
> Even then, don't count on it!  My replacements are now 21,17 and 14 and
> I doubt if I'll ever be able to count on them to help my ailing gray
> cells!
>
> --
> ------------------------------------------------------------
> Gary Thomas                 |
> MLB Associates              |  Consulting for the
> +1 (970) 229-1963           |    Embedded world
> http://www.mlbassoc.com/    |
> email: <gary at mlbassoc dot com>  |
> gpg: http://www.chez-thomas.org/gary/gpg_key.asc
> ------------------------------------------------------------
>