LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>,
Gregory Clement <gregory.clement@free-electrons.com>,
Jason Cooper <jason@lakedaemon.net>, Andrew Lunn <andrew@lunn.ch>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
linux-mtd@lists.infradead.org,
Boris Brezillon <boris@free-electrons.com>,
Thomas Petazzoni <thomas@free-electrons.com>,
linux-arm-kernel@lists.infradead.org,
Tawfik Bayouk <tawfik@marvell.com>,
Nadav Haklai <nadavh@marvell.com>,
Lior Amsalem <alior@marvell.com>,
linux-kernel@vger.kernel.org,
Sudhakar Gundubogula <sudhakar@marvell.com>,
Seif Mazareeb <seif@marvell.com>,
stable@vger.kernel.org, Rob Herring <robh@kernel.org>
Subject: Re: [PATCH v2 1/2] mtd: nand: pxa3xx: Fix PIO FIFO draining
Date: Fri, 6 Feb 2015 09:13:07 +0100 [thread overview]
Message-ID: <20150206091307.1162b123@bbrezillon> (raw)
In-Reply-To: <20150206010835.GB30781@ld-irv-0074>
Hi Brian,
On Thu, 5 Feb 2015 17:08:35 -0800
Brian Norris <computersforpeace@gmail.com> wrote:
> + Rob
>
> This patch has conflicts with an ARM64-preparation from Rob. I'd like to
> get this patch in first, as it's a bugfix. But I'd like to settle
> Boris's comments first.
>
> (Regarding the request to get this into 3.19: not likely. Judging by the
> age of the "bug", it's not massively critical, and we have no time. It
> can get out through -stable once it's gotten proper review and testing.)
>
> On Wed, Feb 04, 2015 at 11:10:28AM +0100, Boris Brezillon wrote:
> > On Mon, 26 Jan 2015 15:56:03 +0100
> > Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> >
> > > The NDDB register holds the data that are needed by the read and write
> > > commands.
> > >
> > > However, during a read PIO access, the datasheet specifies that after each 32
> > > bits read in that register, when BCH is enabled, we have to make sure that the
> > > RDDREQ bit is set in the NDSR register.
> > >
> > > This fixes an issue that was seen on the Armada 385, and presumably other mvebu
> > > SoCs, when a read on a newly erased page would end up in the driver reporting a
> > > timeout from the NAND.
> > >
> > > Cc: <stable@vger.kernel.org> # v3.14
> > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > > ---
> > > drivers/mtd/nand/pxa3xx_nand.c | 45 ++++++++++++++++++++++++++++++++++++------
> > > 1 file changed, 39 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
> > > index 96b0b1d27df1..e6918befb951 100644
> > > --- a/drivers/mtd/nand/pxa3xx_nand.c
> > > +++ b/drivers/mtd/nand/pxa3xx_nand.c
> > > @@ -23,6 +23,7 @@
> > > #include <linux/mtd/partitions.h>
> > > #include <linux/io.h>
> > > #include <linux/irq.h>
> > > +#include <linux/jiffies.h>
> > > #include <linux/slab.h>
> > > #include <linux/of.h>
> > > #include <linux/of_device.h>
> > > @@ -480,6 +481,38 @@ static void disable_int(struct pxa3xx_nand_info *info, uint32_t int_mask)
> > > nand_writel(info, NDCR, ndcr | int_mask);
> > > }
> > >
> > > +static void drain_fifo(struct pxa3xx_nand_info *info, void *data, int len)
> > > +{
> > > + u32 *dst = (u32 *)data;
> > > +
> > > + if (info->ecc_bch) {
> > > + while (len--) {
> > > + u32 timeout;
> > > +
> > > + *dst++ = nand_readl(info, NDDB);
> > > +
> > > + /*
> > > + * According to the datasheet, when reading
> > > + * from NDDB with BCH enabled, after each 32
> > > + * bits reads, we have to make sure that the
> > > + * NDSR.RDDREQ bit is set
> > > + */
> >
> > I know the datasheet says this bit should be checked after each
> > transfer, but I wonder if we shouldn't check it before reading the data.
> > What happens if you drain all the data available in the FIFO ? Is the
> > controller still setting the RDDREQ bit ?
> >
> > Moreover, the datasheet says this RDDREQ bit should be checked after
> > each 32 bytes (not 32 bits) transfer.
> > Testing it after each readl call shouldn't hurt though.
>
> Seems like that could quite possibly kill performance unnecessarily,
> couldn't it? But then, PIO is probably not that fast in the first
> place...
Absolutety, my point was, it shouldn't hurt from a functional POV, but
yes it will definitely impact performances.
But that's not the first thing I would rework of if you're concerned
about performances: when doing PIO read/write, the page read/write
operations (I mean the part reading the internal fifo) are all done in
interrupt context (called from pxa3xx_nand_irq), and doing this will
prevent any other interrupt from taking place while you are
draining/filling the FIFO :-(.
An alternative would be to move this part into the read/write_buf
functions, but that's a lot of work...
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2015-02-06 8:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-26 14:56 [PATCH v2 0/2] ARM: mvebu: a385-db-ap: Enable the NAND controller Maxime Ripard
2015-01-26 14:56 ` [PATCH v2 1/2] mtd: nand: pxa3xx: Fix PIO FIFO draining Maxime Ripard
2015-02-04 9:13 ` Maxime Ripard
2015-02-04 10:10 ` Boris Brezillon
2015-02-06 1:08 ` Brian Norris
2015-02-06 8:13 ` Boris Brezillon [this message]
2015-02-06 8:33 ` Brian Norris
2015-02-06 14:17 ` Ezequiel Garcia
2015-02-06 19:38 ` Brian Norris
2015-02-06 20:33 ` Maxime Ripard
2015-01-26 14:56 ` [PATCH v2 2/2] ARM: mvebu: a385-db-ap: Enable the NAND Maxime Ripard
2015-01-28 2:06 ` Ezequiel Garcia
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=20150206091307.1162b123@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=alior@marvell.com \
--cc=andrew@lunn.ch \
--cc=boris@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=ezequiel.garcia@free-electrons.com \
--cc=gregory.clement@free-electrons.com \
--cc=jason@lakedaemon.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=maxime.ripard@free-electrons.com \
--cc=nadavh@marvell.com \
--cc=robh@kernel.org \
--cc=sebastian.hesselbarth@gmail.com \
--cc=seif@marvell.com \
--cc=stable@vger.kernel.org \
--cc=sudhakar@marvell.com \
--cc=tawfik@marvell.com \
--cc=thomas@free-electrons.com \
--subject='Re: [PATCH v2 1/2] mtd: nand: pxa3xx: Fix PIO FIFO draining' \
/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
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).