public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Tim Harvey <tharvey@gateworks.com>
Cc: "Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Sascha Hauer" <s.hauer@pengutronix.de>,
	"Tomasz Moń" <tomasz.mon@camlingroup.com>,
	"Richard Weinberger" <richard@nod.at>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	"Sasha Levin" <sashal@kernel.org>, "Han Xu" <han.xu@nxp.com>,
	kernel <kernel@pengutronix.de>, stable <stable@vger.kernel.org>
Subject: Re: [PATCH v2 stable 5.10] mtd: rawnand: gpmi: Set WAIT_FOR_READY timeout based on program/erase times
Date: Mon, 7 Nov 2022 10:12:31 +0100	[thread overview]
Message-ID: <Y2jL/8zu90UizMGF@kroah.com> (raw)
In-Reply-To: <20221103153341.2600899-1-tharvey@gateworks.com>

On Thu, Nov 03, 2022 at 08:33:41AM -0700, Tim Harvey wrote:
> From: Sascha Hauer <s.hauer@pengutronix.de>
> 
> commit 0fddf9ad06fd9f439f137139861556671673e31c upstream.
> 
> 06781a5026350 Fixes the calculation of the DEVICE_BUSY_TIMEOUT register
> value from busy_timeout_cycles. busy_timeout_cycles is calculated wrong
> though: It is calculated based on the maximum page read time, but the
> timeout is also used for page write and block erase operations which
> require orders of magnitude bigger timeouts.
> 
> Fix this by calculating busy_timeout_cycles from the maximum of
> tBERS_max and tPROG_max.
> 
> This is for now the easiest and most obvious way to fix the driver.
> There's room for improvements though: The NAND_OP_WAITRDY_INSTR tells us
> the desired timeout for the current operation, so we could program the
> timeout dynamically for each operation instead of setting a fixed
> timeout. Also we could wire up the interrupt handler to actually detect
> and forward timeouts occurred when waiting for the chip being ready.
> 
> As a sidenote I verified that the change in 06781a5026350 is really
> correct. I wired up the interrupt handler in my tree and measured the
> time between starting the operation and the timeout interrupt handler
> coming in. The time increases 41us with each step in the timeout
> register which corresponds to 4096 clock cycles with the 99MHz clock
> that I have.
> 
> Fixes: 06781a5026350 ("mtd: rawnand: gpmi: Fix setting busy timeout setting")
> Fixes: b1206122069aa ("mtd: rawniand: gpmi: use core timings instead of an empirical derivation")
> Cc: stable@vger.kernel.org
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> Acked-by: Han Xu <han.xu@nxp.com>
> Tested-by: Tomasz Moń <tomasz.mon@camlingroup.com>
> Signed-off-by: Richard Weinberger <richard@nod.at>
> Signed-off-by: Tim Harvey <tharvey@gateworks.com>
> ---
> v2: add sb tag and add upstream commit id

Now queued up, thanks.

greg k-h

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

      reply	other threads:[~2022-11-07  9:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-03 15:33 [PATCH v2 stable 5.10] mtd: rawnand: gpmi: Set WAIT_FOR_READY timeout based on program/erase times Tim Harvey
2022-11-07  9:12 ` Greg KH [this message]

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=Y2jL/8zu90UizMGF@kroah.com \
    --to=greg@kroah.com \
    --cc=han.xu@nxp.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=richard@nod.at \
    --cc=s.hauer@pengutronix.de \
    --cc=sashal@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tharvey@gateworks.com \
    --cc=tomasz.mon@camlingroup.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