From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.bootlin.com ([62.4.15.54]) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1fEXKG-0007Wf-Tg for linux-mtd@lists.infradead.org; Fri, 04 May 2018 09:48:30 +0000 Date: Fri, 4 May 2018 11:48:06 +0200 From: Boris Brezillon To: Miquel Raynal Cc: Richard Weinberger , linux-mtd@lists.infradead.org, David Woodhouse , Brian Norris , Marek Vasut , Cyrille Pitchen Subject: Re: [PATCH] mtd: rawnand: fsmc: Make sure we wait tWB before polling the STATUS reg Message-ID: <20180504114806.06695c12@bbrezillon> In-Reply-To: <20180504114510.4ea1e2f2@xps13> References: <20180503074544.19938-1-boris.brezillon@bootlin.com> <20180504114510.4ea1e2f2@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, 4 May 2018 11:45:10 +0200 Miquel Raynal wrote: > Hi Boris, > > On Thu, 3 May 2018 09:45:44 +0200, Boris Brezillon > wrote: > > > NAND chips require a bit of time to take the NAND operation into account > > and set the BUSY bit in the STATUS reg. Make sure we don't poll the > > STATUS reg too early. > > > > Fixes: 4da712e70294 ("mtd: nand: fsmc: use ->exec_op()") > > Signed-off-by: Boris Brezillon > > --- > > drivers/mtd/nand/raw/fsmc_nand.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/drivers/mtd/nand/raw/fsmc_nand.c b/drivers/mtd/nand/raw/fsmc_nand.c > > index 28c48dcc514e..0960665858b7 100644 > > --- a/drivers/mtd/nand/raw/fsmc_nand.c > > +++ b/drivers/mtd/nand/raw/fsmc_nand.c > > @@ -18,6 +18,7 @@ > > > > #include > > #include > > +#include > > #include > > #include > > #include > > @@ -695,6 +696,13 @@ static int fsmc_exec_op(struct nand_chip *chip, const struct nand_operation *op, > > pr_debug(" ->WAITRDY [max %d ms]\n", > > instr->ctx.waitrdy.timeout_ms); > > > > + /* > > + * Make sure we wait tWB before polling the STATUS > > + * register. > > + */ > > + if (op_id && op->instrs[op_id - 1].delay_ns) > > + ndelay(op->instrs[op_id - 1].delay_ns); > > + > > ret = nand_soft_waitrdy(chip, > > instr->ctx.waitrdy.timeout_ms); > > break; > > I'm afraid that we encounter this exact same issue with all the drivers > using nand_soft_waitrdy() whenever the controller does not already > wait for tWB. Could we force a tWB_max delay directly inside > nand_soft_waitrdy()? Yep, I agree. I'll send a new version doing that. Thanks, Boris