From: Brian Norris <computersforpeace@gmail.com>
To: Vladimir Zapolskiy <vz@mleia.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
linux-mtd@lists.infradead.org, Roland Stigge <stigge@antcom.de>
Subject: Re: [PATCH 1/5] mtd: nand: lpc32xx_slc: fix calculation of timing arcs from given values
Date: Wed, 30 Sep 2015 14:12:53 -0700 [thread overview]
Message-ID: <20150930211253.GK143959@google.com> (raw)
In-Reply-To: <1443458338-23552-1-git-send-email-vz@mleia.com>
+ Roland, who authored the driver
On Mon, Sep 28, 2015 at 07:38:58PM +0300, Vladimir Zapolskiy wrote:
> According to LPC32xx User's Manual all values measured in clock cycles
> are programmable from 1 to 16 clocks (4 bits) starting from 0 in
> bitfield. Correctness of 0 bitfield value (i.e. programmed 1 clock
> timing) is proven with actual NAND chip devices.
>
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
> ---
> drivers/mtd/nand/lpc32xx_slc.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mtd/nand/lpc32xx_slc.c b/drivers/mtd/nand/lpc32xx_slc.c
> index abfec13..5a3c6e0 100644
> --- a/drivers/mtd/nand/lpc32xx_slc.c
> +++ b/drivers/mtd/nand/lpc32xx_slc.c
> @@ -240,13 +240,13 @@ static void lpc32xx_nand_setup(struct lpc32xx_nand_host *host)
>
> /* Compute clock setup values */
> tmp = SLCTAC_WDR(host->ncfg->wdr_clks) |
> - SLCTAC_WWIDTH(1 + (clkrate / host->ncfg->wwidth)) |
> - SLCTAC_WHOLD(1 + (clkrate / host->ncfg->whold)) |
> - SLCTAC_WSETUP(1 + (clkrate / host->ncfg->wsetup)) |
> + SLCTAC_WWIDTH(clkrate / host->ncfg->wwidth) |
> + SLCTAC_WHOLD(clkrate / host->ncfg->whold) |
> + SLCTAC_WSETUP(clkrate / host->ncfg->wsetup) |
> SLCTAC_RDR(host->ncfg->rdr_clks) |
> - SLCTAC_RWIDTH(1 + (clkrate / host->ncfg->rwidth)) |
> - SLCTAC_RHOLD(1 + (clkrate / host->ncfg->rhold)) |
> - SLCTAC_RSETUP(1 + (clkrate / host->ncfg->rsetup));
> + SLCTAC_RWIDTH(clkrate / host->ncfg->rwidth) |
> + SLCTAC_RHOLD(clkrate / host->ncfg->rhold) |
> + SLCTAC_RSETUP(clkrate / host->ncfg->rsetup);
> writel(tmp, SLC_TAC(host->io_base));
> }
>
Hmm, I'm guessing this was done to ensure we didn't round down too much.
Perhaps this should be using DIV_ROUND_UP() instead, so we can get an
exact match where possible, but not set too low of a clock rate by
rounding down?
Brian
next prev parent reply other threads:[~2015-09-30 21:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-28 16:38 [PATCH 1/5] mtd: nand: lpc32xx_slc: fix calculation of timing arcs from given values Vladimir Zapolskiy
2015-09-30 21:12 ` Brian Norris [this message]
2015-09-30 21:13 ` Brian Norris
2015-09-30 21:41 ` Vladimir Zapolskiy
2015-09-30 21:48 ` Brian Norris
2015-09-30 21:17 ` Vladimir Zapolskiy
2015-09-30 21:46 ` Brian Norris
2015-09-30 22:09 ` Vladimir Zapolskiy
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=20150930211253.GK143959@google.com \
--to=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=stigge@antcom.de \
--cc=vz@mleia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.