linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Josh Boyer <jwboyer@linux.vnet.ibm.com>
To: Trent Piepho <tpiepho@freescale.com>
Cc: linuxppc-dev@ozlabs.org, linux-mtd@lists.infradead.org,
	Trent Piepho <xyzzy@speakeasy.org>,
	Trent Piepho <tpiepho@freescale.com>
Subject: Re: [PATCH] POWERPC: MTD: Add cached map support to physmap_of MTD driver
Date: Mon, 15 Dec 2008 13:30:26 -0500	[thread overview]
Message-ID: <20081215133026.4a86e7f7@zod.rchland.ibm.com> (raw)
In-Reply-To: <1229365518-20538-1-git-send-email-tpiepho@freescale.com>

On Mon, 15 Dec 2008 10:25:18 -0800
Trent Piepho <tpiepho@freescale.com> wrote:

> The MTD system supports operation where a direct mapped flash chip is
> mapped twice.  The normal mapping is a standard ioremap(), which is
> non-cached and guarded on powerpc.  The second mapping is used only for
> reads and can be cached and non-guarded.  Currently, only the pxa2xx
> mapping driver makes use of this feature.  This patch adds support to the
> physmap_of driver on PPC32 platforms for this cached mapping mode.
> 
> Because the flash chip doesn't participate in the cache coherency protocol,
> it's necessary to invalidate the cache for parts of flash that are modified
> with a program or erase operation.  This is platform specific, for instance
> the pxa2xx driver uses an ARM specific function.  This patch adds
> invalidate_dcache_icache_range() for PPC32 and uses it.  Because of XIP,
> it's entirely possible that the flash might be in the icache(*), so the
> existing invalidate_dcache_range() function isn't enough.
> 
> Of course, a cached mapping can increase performance if the data is read
> from cache instead of flash.  But less obvious is that it can provide a
> significant performance increase for cold-cache reads that still come from
> flash.  It allows efficient back-to-back reads and if the flash chip &
> controller support page burst mode, it allows that to be used as well.
> 
> The figures are for *cold-cache* read performance, measured on a Freescale
> MPC8572 controlling a Spansion S29GL064N NOR flash chip.  With and without
> the flash being mapped cached and with and without the localbus controller
> being programmed to use page burst mode:
> 
> Non-cached, w/o bursts: 13.61 MB/s
> Non-cached, w/ bursts:  13.61 MB/s
> Cached, w/o bursts:     16.75 MB/s 23% increase
> Cached, w/ bursts:      44.79 MB/s 229% increase!
> 
> Even without any cache hits, the cached mapping provides a significant
> increase in performance via improved bus utilization.  Enabling burst
> transfers is even more significant.
> 
> (*) The MTD device's ->point() method, which is the mechanism for
> supporting mmap and XIP, only allows for mmapping the uncached region.  So
> you can't actually XIP anything in the cache.  But this could be fixed.
> 
> Signed-off-by: Trent Piepho <tpiepho@freescale.com>

Did you actually change anything in this version when compared to the
version you sent out last week?  If not, is there a reason you sent it
again without flagging it as a resend?

(Hint, the MTD community reviews patches slowly.  No comments for a
week is normal.)

josh

  reply	other threads:[~2008-12-15 18:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-15 18:25 [PATCH] POWERPC: MTD: Add cached map support to physmap_of MTD driver Trent Piepho
2008-12-15 18:30 ` Josh Boyer [this message]
2008-12-15 22:56   ` Trent Piepho
2008-12-16  0:21 ` Paul Mackerras
2008-12-16  1:11   ` Trent Piepho
2008-12-16  8:56     ` Benjamin Herrenschmidt
2008-12-17 21:01       ` Trent Piepho
2008-12-16  8:55 ` Benjamin Herrenschmidt

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=20081215133026.4a86e7f7@zod.rchland.ibm.com \
    --to=jwboyer@linux.vnet.ibm.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=tpiepho@freescale.com \
    --cc=xyzzy@speakeasy.org \
    /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).