linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Kenneth Johansson <kenneth@southpole.se>
To: Scott Wood <scottwood@freescale.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: 5121 cache handling.
Date: Mon, 10 Aug 2009 22:16:24 +0200	[thread overview]
Message-ID: <1249935384.7077.35.camel@localhost> (raw)
In-Reply-To: <20090807195600.GB11681@b07421-ec1.am.freescale.net>

On Fri, 2009-08-07 at 14:56 -0500, Scott Wood wrote:
> On Fri, Aug 07, 2009 at 02:53:52PM +0200, Kenneth Johansson wrote:
> > on 5121 there is a e300 core that unfortunately is connected to the rest
> > of the SOC with a bus that do not support coherency.
> > 
> > solution for many driver has been to use uncached memory. But for the
> > framebuffer that is not going to work as the performance impact of doing
> > graphics operations on uncached memory is to large.
> > 
> > currently the "solution" is to flush the cache in the interrupt
> > handler. 
> > 
> > #if defined(CONFIG_NOT_COHERENT_CACHE)
> >                         int i;
> >                         unsigned int *ptr;
> >                         ptr  = coherence_data;
> >                         for (i = 0; i < 1024*8; i++)
> >                                 *ptr++ = 0;
> > #endif
> > 
> > Now this apparently is not enough on a e300 core that has a PLRU cache
> > replacement algorithm. but what is the optimal solution? 
> 
> Which driver (in which kernel) are you looking at?

The one included in ltib 2009-06-02 for ads5121. Thought that was
including the latest drivers.

> drivers/video/fsl-diu-fb.c in current mainline has properly sized
> coherence data.  It also does a dcbz (on unused data) instead of loads,
> as it's apparently faster (though I'd think you'd get more traffic
> flushing those zeroes out later on, compared to a clean line that can
> just be discarded).

It's hard to know exactly how things behave when cache is involved.

But the code allocate the 52KB buffer with vmalloc that cant be right as
cache is stored with physical address the 52KB data need to be 52KB
continuous in physical address and vmalloc do not guarantee that.

> > should not the framebuffer be marked as cache write through. that is the
> > W bit should be set in the tlb mapping. Why is this not done ? is that
> > feature also not working on 5121 ??
> 
> It probably would have been too slow.

how much slower would write through be ? I thought it was not that big
of a difference from copy back.

  reply	other threads:[~2009-08-10 20:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-07 12:53 5121 cache handling Kenneth Johansson
2009-08-07 19:56 ` Scott Wood
2009-08-10 20:16   ` Kenneth Johansson [this message]
2009-08-10 20:26     ` Scott Wood
2009-08-10 20:45       ` Kenneth Johansson
2009-08-10 20:49         ` Scott Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1249935384.7077.35.camel@localhost \
    --to=kenneth@southpole.se \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=scottwood@freescale.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).