From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Bastien Curutchet <bastien.curutchet@bootlin.com>
Cc: Santosh Shilimkar <ssantosh@kernel.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Herve Codina <herve.codina@bootlin.com>,
Christopher Cordahi <christophercordahi@nanometrics.ca>
Subject: Re: [PATCH v2 6/6] mtd: rawnand: davinci: Implement setup_interface() operation
Date: Mon, 11 Nov 2024 20:32:09 +0100 [thread overview]
Message-ID: <87frnxr2h2.fsf@bootlin.com> (raw)
In-Reply-To: <20241106085507.76425-7-bastien.curutchet@bootlin.com> (Bastien Curutchet's message of "Wed, 6 Nov 2024 09:55:07 +0100")
Hi Bastien,
On 06/11/2024 at 09:55:07 +01, Bastien Curutchet <bastien.curutchet@bootlin.com> wrote:
> The setup_interface() operation isn't implemented. It forces the driver
> to use the ONFI mode 0, though it could use more optimal modes.
>
> Implement the setup_interface() operation. It uses the
> aemif_set_cs_timings() function from the AEMIF driver to update the
> chip select timings. The calculation of the register's contents is
> directly extracted from §20.3.2.3 of the DaVinci TRM [1]
>
> These timings are previously set by the AEMIF driver itself from
> device-tree properties. Therefore, IMHO, failing to update them in the
> setup_interface() isn't critical, which is why 0 is returned even when
> timings aren't updated.
Did you experience failures? Because I'd be more conservative and error
out loudly when something is wrong. In general it is a safest approach
on the long term. Here maybe you have good reasons to do differently, in
this case I am all ears.
> MAX_TH_PS and MAX_TSU_PS are the worst case timings based on the
> Keystone2 and DaVinci datasheets.
>
> [1] : https://www.ti.com/lit/ug/spruh77c/spruh77c.pdf
>
> Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
> ---
> drivers/mtd/nand/raw/davinci_nand.c | 78 +++++++++++++++++++++++++++++
> 1 file changed, 78 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/davinci_nand.c b/drivers/mtd/nand/raw/davinci_nand.c
> index 563045c7ce08..2d0c564c8d17 100644
> --- a/drivers/mtd/nand/raw/davinci_nand.c
> +++ b/drivers/mtd/nand/raw/davinci_nand.c
> @@ -14,6 +14,7 @@
> #include <linux/err.h>
> #include <linux/iopoll.h>
> #include <linux/kernel.h>
> +#include <linux/memory/ti-aemif.h>
> #include <linux/module.h>
> #include <linux/mtd/rawnand.h>
> #include <linux/mtd/partitions.h>
> @@ -44,6 +45,9 @@
> #define MASK_ALE 0x08
> #define MASK_CLE 0x10
>
> +#define MAX_TSU_PS 3000 /* Input setup time in ps */
> +#define MAX_TH_PS 1600 /* Input hold time in ps */
> +
> struct davinci_nand_pdata {
> uint32_t mask_ale;
> uint32_t mask_cle;
> @@ -120,6 +124,7 @@ struct davinci_nand_info {
> uint32_t core_chipsel;
>
> struct clk *clk;
> + struct aemif_device *aemif;
> };
>
> static DEFINE_SPINLOCK(davinci_nand_lock);
> @@ -767,9 +772,81 @@ static int davinci_nand_exec_op(struct nand_chip *chip,
> return 0;
> }
>
> +#define TO_CYCLES(ps, period_ns) (DIV_ROUND_UP((ps) / 1000, (period_ns)))
> +
> +static int davinci_nand_setup_interface(struct nand_chip *chip, int chipnr,
> + const struct nand_interface_config *conf)
> +{
> + struct davinci_nand_info *info = to_davinci_nand(nand_to_mtd(chip));
> + const struct nand_sdr_timings *sdr;
> + struct aemif_cs_timings timings;
> + s32 cfg, min, cyc_ns;
> +
> + cyc_ns = 1000000000 / clk_get_rate(info->clk);
> +
> + sdr = nand_get_sdr_timings(conf);
> + if (IS_ERR(sdr))
> + return PTR_ERR(sdr);
> +
> + cfg = TO_CYCLES(sdr->tCLR_min, cyc_ns) - 1;
> + timings.rsetup = cfg > 0 ? cfg : 0;
> +
> + cfg = max_t(s32, TO_CYCLES(sdr->tREA_max + MAX_TSU_PS, cyc_ns),
> + TO_CYCLES(sdr->tRP_min, cyc_ns)) - 1;
> + timings.rstrobe = cfg > 0 ? cfg : 0;
> +
> + min = TO_CYCLES(sdr->tCEA_max + MAX_TSU_PS, cyc_ns) - 2;
> + while ((s32)(timings.rsetup + timings.rstrobe) < min)
> + timings.rstrobe++;
I see a lot of while loops which just stop if you reach a min/max, I
believe a slightly more robust approach should be attempted, and
returning errors when these limits are crossed would be probably
beneficial on the long term?
> +
> + cfg = TO_CYCLES((s32)(MAX_TH_PS - sdr->tCHZ_max), cyc_ns) - 1;
> + timings.rhold = cfg > 0 ? cfg : 0;
> +
> + min = TO_CYCLES(sdr->tRC_min, cyc_ns) - 3;
> + while ((s32)(timings.rsetup + timings.rstrobe + timings.rhold) < min)
> + timings.rhold++;
> +
> + cfg = TO_CYCLES((s32)(sdr->tRHZ_max - (timings.rhold + 1) * cyc_ns * 1000), cyc_ns);
> + cfg = max_t(s32, cfg, TO_CYCLES(sdr->tCHZ_max, cyc_ns)) - 1;
> + timings.ta = cfg > 0 ? cfg : 0;
> +
> + cfg = TO_CYCLES(sdr->tWP_min, cyc_ns) - 1;
> + timings.wstrobe = cfg > 0 ? cfg : 0;
> +
> + cfg = max_t(s32, TO_CYCLES(sdr->tCLS_min, cyc_ns), TO_CYCLES(sdr->tALS_min, cyc_ns));
> + cfg = max_t(s32, cfg, TO_CYCLES(sdr->tCS_min, cyc_ns)) - 1;
> + timings.wsetup = cfg > 0 ? cfg : 0;
> +
> + min = TO_CYCLES(sdr->tDS_min, cyc_ns) - 2;
> + while ((s32)(timings.wsetup + timings.wstrobe) < min)
> + timings.wstrobe++;
> +
> + cfg = max_t(s32, TO_CYCLES(sdr->tCLH_min, cyc_ns), TO_CYCLES(sdr->tALH_min, cyc_ns));
> + cfg = max_t(s32, cfg, TO_CYCLES(sdr->tCH_min, cyc_ns));
> + cfg = max_t(s32, cfg, TO_CYCLES(sdr->tDH_min, cyc_ns)) - 1;
> + timings.whold = cfg > 0 ? cfg : 0;
> +
> + min = TO_CYCLES(sdr->tWC_min, cyc_ns) - 2;
> + while ((s32)(timings.wsetup + timings.wstrobe + timings.whold) < min)
> + timings.whold++;
> +
> + dev_dbg(&info->pdev->dev, "RSETUP %x RSTROBE %x RHOLD %x\n",
> + timings.rsetup, timings.rstrobe, timings.rhold);
> + dev_dbg(&info->pdev->dev, "TA %x\n", timings.ta);
> + dev_dbg(&info->pdev->dev, "WSETUP %x WSTROBE %x WHOLD %x\n",
> + timings.wsetup, timings.wstrobe, timings.whold);
> +
Here you probably want to exit in the NAND_DATA_IFACE_CHECK_ONLY case.
> + if (aemif_set_cs_timings(info->aemif, info->core_chipsel, &timings) < 0)
> + dev_info(&info->pdev->dev,
> + "Failed to dynamically update the CS timings, keep them unchanged");
> +
> + return 0;
> +}
> +
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Bastien Curutchet <bastien.curutchet@bootlin.com>
Cc: Santosh Shilimkar <ssantosh@kernel.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Herve Codina <herve.codina@bootlin.com>,
Christopher Cordahi <christophercordahi@nanometrics.ca>
Subject: Re: [PATCH v2 6/6] mtd: rawnand: davinci: Implement setup_interface() operation
Date: Mon, 11 Nov 2024 20:32:09 +0100 [thread overview]
Message-ID: <87frnxr2h2.fsf@bootlin.com> (raw)
In-Reply-To: <20241106085507.76425-7-bastien.curutchet@bootlin.com> (Bastien Curutchet's message of "Wed, 6 Nov 2024 09:55:07 +0100")
Hi Bastien,
On 06/11/2024 at 09:55:07 +01, Bastien Curutchet <bastien.curutchet@bootlin.com> wrote:
> The setup_interface() operation isn't implemented. It forces the driver
> to use the ONFI mode 0, though it could use more optimal modes.
>
> Implement the setup_interface() operation. It uses the
> aemif_set_cs_timings() function from the AEMIF driver to update the
> chip select timings. The calculation of the register's contents is
> directly extracted from §20.3.2.3 of the DaVinci TRM [1]
>
> These timings are previously set by the AEMIF driver itself from
> device-tree properties. Therefore, IMHO, failing to update them in the
> setup_interface() isn't critical, which is why 0 is returned even when
> timings aren't updated.
Did you experience failures? Because I'd be more conservative and error
out loudly when something is wrong. In general it is a safest approach
on the long term. Here maybe you have good reasons to do differently, in
this case I am all ears.
> MAX_TH_PS and MAX_TSU_PS are the worst case timings based on the
> Keystone2 and DaVinci datasheets.
>
> [1] : https://www.ti.com/lit/ug/spruh77c/spruh77c.pdf
>
> Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
> ---
> drivers/mtd/nand/raw/davinci_nand.c | 78 +++++++++++++++++++++++++++++
> 1 file changed, 78 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/davinci_nand.c b/drivers/mtd/nand/raw/davinci_nand.c
> index 563045c7ce08..2d0c564c8d17 100644
> --- a/drivers/mtd/nand/raw/davinci_nand.c
> +++ b/drivers/mtd/nand/raw/davinci_nand.c
> @@ -14,6 +14,7 @@
> #include <linux/err.h>
> #include <linux/iopoll.h>
> #include <linux/kernel.h>
> +#include <linux/memory/ti-aemif.h>
> #include <linux/module.h>
> #include <linux/mtd/rawnand.h>
> #include <linux/mtd/partitions.h>
> @@ -44,6 +45,9 @@
> #define MASK_ALE 0x08
> #define MASK_CLE 0x10
>
> +#define MAX_TSU_PS 3000 /* Input setup time in ps */
> +#define MAX_TH_PS 1600 /* Input hold time in ps */
> +
> struct davinci_nand_pdata {
> uint32_t mask_ale;
> uint32_t mask_cle;
> @@ -120,6 +124,7 @@ struct davinci_nand_info {
> uint32_t core_chipsel;
>
> struct clk *clk;
> + struct aemif_device *aemif;
> };
>
> static DEFINE_SPINLOCK(davinci_nand_lock);
> @@ -767,9 +772,81 @@ static int davinci_nand_exec_op(struct nand_chip *chip,
> return 0;
> }
>
> +#define TO_CYCLES(ps, period_ns) (DIV_ROUND_UP((ps) / 1000, (period_ns)))
> +
> +static int davinci_nand_setup_interface(struct nand_chip *chip, int chipnr,
> + const struct nand_interface_config *conf)
> +{
> + struct davinci_nand_info *info = to_davinci_nand(nand_to_mtd(chip));
> + const struct nand_sdr_timings *sdr;
> + struct aemif_cs_timings timings;
> + s32 cfg, min, cyc_ns;
> +
> + cyc_ns = 1000000000 / clk_get_rate(info->clk);
> +
> + sdr = nand_get_sdr_timings(conf);
> + if (IS_ERR(sdr))
> + return PTR_ERR(sdr);
> +
> + cfg = TO_CYCLES(sdr->tCLR_min, cyc_ns) - 1;
> + timings.rsetup = cfg > 0 ? cfg : 0;
> +
> + cfg = max_t(s32, TO_CYCLES(sdr->tREA_max + MAX_TSU_PS, cyc_ns),
> + TO_CYCLES(sdr->tRP_min, cyc_ns)) - 1;
> + timings.rstrobe = cfg > 0 ? cfg : 0;
> +
> + min = TO_CYCLES(sdr->tCEA_max + MAX_TSU_PS, cyc_ns) - 2;
> + while ((s32)(timings.rsetup + timings.rstrobe) < min)
> + timings.rstrobe++;
I see a lot of while loops which just stop if you reach a min/max, I
believe a slightly more robust approach should be attempted, and
returning errors when these limits are crossed would be probably
beneficial on the long term?
> +
> + cfg = TO_CYCLES((s32)(MAX_TH_PS - sdr->tCHZ_max), cyc_ns) - 1;
> + timings.rhold = cfg > 0 ? cfg : 0;
> +
> + min = TO_CYCLES(sdr->tRC_min, cyc_ns) - 3;
> + while ((s32)(timings.rsetup + timings.rstrobe + timings.rhold) < min)
> + timings.rhold++;
> +
> + cfg = TO_CYCLES((s32)(sdr->tRHZ_max - (timings.rhold + 1) * cyc_ns * 1000), cyc_ns);
> + cfg = max_t(s32, cfg, TO_CYCLES(sdr->tCHZ_max, cyc_ns)) - 1;
> + timings.ta = cfg > 0 ? cfg : 0;
> +
> + cfg = TO_CYCLES(sdr->tWP_min, cyc_ns) - 1;
> + timings.wstrobe = cfg > 0 ? cfg : 0;
> +
> + cfg = max_t(s32, TO_CYCLES(sdr->tCLS_min, cyc_ns), TO_CYCLES(sdr->tALS_min, cyc_ns));
> + cfg = max_t(s32, cfg, TO_CYCLES(sdr->tCS_min, cyc_ns)) - 1;
> + timings.wsetup = cfg > 0 ? cfg : 0;
> +
> + min = TO_CYCLES(sdr->tDS_min, cyc_ns) - 2;
> + while ((s32)(timings.wsetup + timings.wstrobe) < min)
> + timings.wstrobe++;
> +
> + cfg = max_t(s32, TO_CYCLES(sdr->tCLH_min, cyc_ns), TO_CYCLES(sdr->tALH_min, cyc_ns));
> + cfg = max_t(s32, cfg, TO_CYCLES(sdr->tCH_min, cyc_ns));
> + cfg = max_t(s32, cfg, TO_CYCLES(sdr->tDH_min, cyc_ns)) - 1;
> + timings.whold = cfg > 0 ? cfg : 0;
> +
> + min = TO_CYCLES(sdr->tWC_min, cyc_ns) - 2;
> + while ((s32)(timings.wsetup + timings.wstrobe + timings.whold) < min)
> + timings.whold++;
> +
> + dev_dbg(&info->pdev->dev, "RSETUP %x RSTROBE %x RHOLD %x\n",
> + timings.rsetup, timings.rstrobe, timings.rhold);
> + dev_dbg(&info->pdev->dev, "TA %x\n", timings.ta);
> + dev_dbg(&info->pdev->dev, "WSETUP %x WSTROBE %x WHOLD %x\n",
> + timings.wsetup, timings.wstrobe, timings.whold);
> +
Here you probably want to exit in the NAND_DATA_IFACE_CHECK_ONLY case.
> + if (aemif_set_cs_timings(info->aemif, info->core_chipsel, &timings) < 0)
> + dev_info(&info->pdev->dev,
> + "Failed to dynamically update the CS timings, keep them unchanged");
> +
> + return 0;
> +}
> +
Thanks,
Miquèl
next prev parent reply other threads:[~2024-11-11 19:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-06 8:55 [PATCH v2 0/6] Implement setup_interface() in the DaVinci NAND controller Bastien Curutchet
2024-11-06 8:55 ` Bastien Curutchet
2024-11-06 8:55 ` [PATCH v2 1/6] memory: ti-aemif: Create aemif_set_cs_timings() Bastien Curutchet
2024-11-06 8:55 ` Bastien Curutchet
2024-11-11 19:16 ` Miquel Raynal
2024-11-11 19:16 ` Miquel Raynal
2024-11-06 8:55 ` [PATCH v2 2/6] memory: ti-aemif: Export aemif_set_cs_timings() Bastien Curutchet
2024-11-06 8:55 ` Bastien Curutchet
2024-11-11 19:21 ` Miquel Raynal
2024-11-11 19:21 ` Miquel Raynal
2024-11-12 9:13 ` Bastien Curutchet
2024-11-12 9:13 ` Bastien Curutchet
2024-11-12 11:17 ` Miquel Raynal
2024-11-12 11:17 ` Miquel Raynal
2024-11-06 8:55 ` [PATCH v2 3/6] mtd: rawnand: davinci: Always depends on TI_AEMIF Bastien Curutchet
2024-11-06 8:55 ` Bastien Curutchet
2024-11-06 8:55 ` [PATCH v2 4/6] mtd: rawnand: davinci: Order headers alphabetically Bastien Curutchet
2024-11-06 8:55 ` Bastien Curutchet
2024-11-06 8:55 ` [PATCH v2 5/6] mtd: rawnand: davinci: Add clock resource Bastien Curutchet
2024-11-06 8:55 ` Bastien Curutchet
2024-11-06 8:55 ` [PATCH v2 6/6] mtd: rawnand: davinci: Implement setup_interface() operation Bastien Curutchet
2024-11-06 8:55 ` Bastien Curutchet
2024-11-11 19:32 ` Miquel Raynal [this message]
2024-11-11 19:32 ` Miquel Raynal
2024-11-12 12:53 ` Bastien Curutchet
2024-11-12 12:53 ` Bastien Curutchet
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=87frnxr2h2.fsf@bootlin.com \
--to=miquel.raynal@bootlin.com \
--cc=bastien.curutchet@bootlin.com \
--cc=christophercordahi@nanometrics.ca \
--cc=herve.codina@bootlin.com \
--cc=krzk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=ssantosh@kernel.org \
--cc=thomas.petazzoni@bootlin.com \
--cc=vigneshr@ti.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.