From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Brian Norris <computersforpeace@gmail.com>,
Ralf Baechle <ralf@linux-mips.org>
Cc: "Rafał Miłecki" <zajec5@gmail.com>,
"Javier Martinez Canillas" <javier@osg.samsung.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Fengguang Wu" <fengguang.wu@intel.com>,
"Michael Ellerman" <mpe@ellerman.id.au>,
"Luis de Bethencourt" <luisbg@osg.samsung.com>,
"Jeremy Kerr" <jk@ozlabs.org>,
"Neelesh Gupta" <neelegup@linux.vnet.ibm.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
"David Woodhouse" <dwmw2@infradead.org>,
"Cyril Bur" <cyrilbur@gmail.com>
Subject: Re: [PATCH] mtd: bcm47xxsflash: use devm_ioremap_nocache() instead of KSEG0ADDR()
Date: Sat, 9 Jan 2016 02:10:44 +0000 (GMT) [thread overview]
Message-ID: <alpine.LFD.2.20.1601090058430.29879@eddie.linux-mips.org> (raw)
In-Reply-To: <20160108185120.GQ109450@google.com>
On Fri, 8 Jan 2016, Brian Norris wrote:
> > > > This removes some (implicit) MIPS dependencies and makes the code more
> > > > portable, whether we need it or not :)
> > >
> > > So now we have following forwardtrace:
> > > devm_ioremap_nocache
> > > ioremap_nocache
> > > __ioremap_mode
> > > __ioremap
> > > CKSEG1ADDR
>
> I just noticed that ioremap() and ioremap_nocache() are the same on
> MIPS. So I could just do devm_ioremap_resource() and save myself a few
> lines...
My bad, I wrote from memory and didn't double check what the caching mode
for plain `ioremap' is. You need to use `ioremap_cache' for a cached
mapping. Unfortunately the MIPS port is missing this generic interface
and defines `ioremap_cachable' instead. I've just posted an obvious fix
for this problem.
Ralf, can you pick this fix for 4.5? It qualifies as obvious I believe,
similar to a recent `ioremap_uc' addition.
> > > It results in different address than KSEG0ADDR:
> > > [ 1.339752] [bcm47xxsflash_bcma_probe] KSEG0ADDR(BCMA_SOC_FLASH2):9c000000
> > > [ 1.346848] [bcm47xxsflash_bcma_probe] devm_ioremap_nocache:bc000000
> > >
> > > But it still works as expected! :)
> > > [ 1.609426] 6 bcm47xxpart partitions found on MTD device bcm47xxsflash
> > > [ 1.616169] Creating 6 MTD partitions on "bcm47xxsflash":
> >
> > It is a functional change though and I think the change from a cached to
> > uncached mapping (i.e. from `ioremap' to `ioremap_nocache') has to be a
> > separate patch, so that both changes can be reviewed independently.
>
> As I noted before sending my patch, I don't think this driver should
> have been using KSEG0 anyway; it should have been KSEG1, right? I can
> note that in the patch description, but I don't really see why it needs
> to be a separate patch.
You did mention that, but didn't actually justify why an uncached mapping
is required here.
This code is in a function called `bcm47xxsflash_read' and reads from an
MMIO region, presumably flash memory which behaves like ordinary memory on
reads (i.e. no side effects). Therefore using a cached mapping will in
most cases result in much better performance as the CPU will load
(prefetch) data in cacheline-sized quantities rather than hitting the
external bus every time with a word-sized quantity transferred only.
Switching to an uncached mapping would invalidate this optimisation and
is independent from a build error fix. Therefore it requires a separate
patch and review. Perhaps `memremap' should be used instead (possibly
with the MEMREMAP_WT policy), but this is exactly why a separate review is
required for that part.
Maciej
next prev parent reply other threads:[~2016-01-09 2:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-14 9:04 [PATCH] mtd: Make MTD_BCM47XXSFLASH to depend on MIPS Javier Martinez Canillas
2015-10-14 16:25 ` Brian Norris
2015-11-04 9:04 ` Rafał Miłecki
2015-11-04 18:53 ` Brian Norris
2016-01-07 21:06 ` Maciej W. Rozycki
2016-01-07 23:05 ` [PATCH] mtd: bcm47xxsflash: use devm_ioremap_nocache() instead of KSEG0ADDR() Brian Norris
2016-01-08 7:53 ` Rafał Miłecki
2016-01-08 14:01 ` Maciej W. Rozycki
2016-01-08 15:26 ` Rafał Miłecki
2016-01-09 2:12 ` Maciej W. Rozycki
2016-01-08 18:51 ` Brian Norris
2016-01-09 2:10 ` Maciej W. Rozycki [this message]
2016-01-16 0:38 ` Rafał Miłecki
2016-01-16 19:36 ` Maciej W. Rozycki
2016-01-23 21:49 ` Brian Norris
2016-01-24 9:44 ` Rafał Miłecki
2016-01-24 20:26 ` Maciej W. Rozycki
2016-01-24 21:31 ` Rafał Miłecki
2016-01-24 23:07 ` Maciej W. Rozycki
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=alpine.LFD.2.20.1601090058430.29879@eddie.linux-mips.org \
--to=macro@linux-mips.org \
--cc=computersforpeace@gmail.com \
--cc=cyrilbur@gmail.com \
--cc=dwmw2@infradead.org \
--cc=fengguang.wu@intel.com \
--cc=javier@osg.samsung.com \
--cc=jk@ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=luisbg@osg.samsung.com \
--cc=mpe@ellerman.id.au \
--cc=neelegup@linux.vnet.ibm.com \
--cc=ralf@linux-mips.org \
--cc=zajec5@gmail.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
all inboxes | Powered by JetHome®