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

  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).