* [PATCH v2] mtd: rawnand: denali: add more delays before latching incoming data
@ 2020-03-17 7:18 ` Masahiro Yamada
0 siblings, 0 replies; 16+ messages in thread
From: Masahiro Yamada @ 2020-03-17 7:18 UTC (permalink / raw)
To: linux-mtd
Cc: Marek Vasut, Miquel Raynal, Masahiro Yamada, Richard Weinberger,
Vignesh Raghavendra, linux-kernel
The Denali IP have several registers to specify how many clock cycles
should be waited between falling/rising signals. You can improve the
NAND access performance by programming these registers with optimized
values.
Because struct nand_sdr_timings represents the device requirement
in pico seconds, denali_setup_data_interface() computes the register
values by dividing the device timings with the clock period.
Marek Vasut reported this driver in the latest kernel does not work
on his SOCFPGA board. (The on-board NAND chip is mode 5)
The suspicious parameter is acc_clks, so this commit relaxes it.
The Denali NAND Flash Memory Controller User's Guide describes this
register as follows:
acc_clks
signifies the number of bus interface clk_x clock cycles,
controller should wait from read enable going low to sending
out a strobe of clk_x for capturing of incoming data.
Currently, acc_clks is calculated only based on tREA, the delay on the
chip side. This does not include additional delays that come from the
data path on the PCB and in the SoC, load capacity of the pins, etc.
This relatively becomes a big factor on faster timing modes like mode 5.
Before supporting the ->setup_data_interface() hook (e.g. Linux 4.12),
the Denali driver hacks acc_clks in a couple of ways [1] [2] to support
the timing mode 5.
We would not go back to the hard-coded acc_clks, but we need to include
this factor into the delay somehow. Let's say the amount of the additional
delay is 10000 pico sec.
In the new calculation, acc_clks is determined by timings->tREA_max +
data_setup_on_host.
Also, prolong the RE# low period to make sure the data hold is met.
Finally, re-center the data latch timing for extra safety.
[1] https://github.com/torvalds/linux/blob/v4.12/drivers/mtd/nand/denali.c#L276
[2] https://github.com/torvalds/linux/blob/v4.12/drivers/mtd/nand/denali.c#L282
Reported-by: Marek Vasut <marex@denx.de>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Changes in v2:
- Use 'unsigned int' instead of 'u32' for data_setup_on_host
- Fix 'line over 80 characters' warning from checkpatch.pl
drivers/mtd/nand/raw/denali.c | 45 ++++++++++++++++++++++++++---------
1 file changed, 34 insertions(+), 11 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 6a6c919b2569..2fcd2baf6e35 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -764,6 +764,7 @@ static int denali_write_page(struct nand_chip *chip, const u8 *buf,
static int denali_setup_data_interface(struct nand_chip *chip, int chipnr,
const struct nand_data_interface *conf)
{
+ static const unsigned int data_setup_on_host = 10000;
struct denali_controller *denali = to_denali_controller(chip);
struct denali_chip_sel *sel;
const struct nand_sdr_timings *timings;
@@ -796,15 +797,6 @@ static int denali_setup_data_interface(struct nand_chip *chip, int chipnr,
sel = &to_denali_chip(chip)->sels[chipnr];
- /* tREA -> ACC_CLKS */
- acc_clks = DIV_ROUND_UP(timings->tREA_max, t_x);
- acc_clks = min_t(int, acc_clks, ACC_CLKS__VALUE);
-
- tmp = ioread32(denali->reg + ACC_CLKS);
- tmp &= ~ACC_CLKS__VALUE;
- tmp |= FIELD_PREP(ACC_CLKS__VALUE, acc_clks);
- sel->acc_clks = tmp;
-
/* tRWH -> RE_2_WE */
re_2_we = DIV_ROUND_UP(timings->tRHW_min, t_x);
re_2_we = min_t(int, re_2_we, RE_2_WE__VALUE);
@@ -862,14 +854,45 @@ static int denali_setup_data_interface(struct nand_chip *chip, int chipnr,
tmp |= FIELD_PREP(RDWR_EN_HI_CNT__VALUE, rdwr_en_hi);
sel->rdwr_en_hi_cnt = tmp;
- /* tRP, tWP -> RDWR_EN_LO_CNT */
+ /*
+ * tREA -> ACC_CLKS
+ * tRP, tWP, tRHOH, tRC, tWC -> RDWR_EN_LO_CNT
+ */
+
+ /*
+ * Determine the minimum of acc_clks to meet the setup timing when
+ * capturing the incoming data.
+ *
+ * The delay on the chip side is well-defined as tREA, but we need to
+ * take additional delay into account. This includes a certain degree
+ * of unknowledge, such as signal propagation delays on the PCB and
+ * in the SoC, load capacity of the I/O pins, etc.
+ */
+ acc_clks = DIV_ROUND_UP(timings->tREA_max + data_setup_on_host, t_x);
+
+ /* Determine the minimum of rdwr_en_lo_cnt from RE#/WE# pulse width */
rdwr_en_lo = DIV_ROUND_UP(max(timings->tRP_min, timings->tWP_min), t_x);
+
+ /* Extend rdwr_en_lo to meet the data hold timing */
+ rdwr_en_lo = max_t(int, rdwr_en_lo,
+ acc_clks - timings->tRHOH_min / t_x);
+
+ /* Extend rdwr_en_lo to meet the requirement for RE#/WE# cycle time */
rdwr_en_lo_hi = DIV_ROUND_UP(max(timings->tRC_min, timings->tWC_min),
t_x);
- rdwr_en_lo_hi = max_t(int, rdwr_en_lo_hi, mult_x);
rdwr_en_lo = max(rdwr_en_lo, rdwr_en_lo_hi - rdwr_en_hi);
rdwr_en_lo = min_t(int, rdwr_en_lo, RDWR_EN_LO_CNT__VALUE);
+ /* Center the data latch timing for extra safety */
+ acc_clks = (acc_clks + rdwr_en_lo +
+ DIV_ROUND_UP(timings->tRHOH_min, t_x)) / 2;
+ acc_clks = min_t(int, acc_clks, ACC_CLKS__VALUE);
+
+ tmp = ioread32(denali->reg + ACC_CLKS);
+ tmp &= ~ACC_CLKS__VALUE;
+ tmp |= FIELD_PREP(ACC_CLKS__VALUE, acc_clks);
+ sel->acc_clks = tmp;
+
tmp = ioread32(denali->reg + RDWR_EN_LO_CNT);
tmp &= ~RDWR_EN_LO_CNT__VALUE;
tmp |= FIELD_PREP(RDWR_EN_LO_CNT__VALUE, rdwr_en_lo);
--
2.17.1
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH v2] mtd: rawnand: denali: add more delays before latching incoming data
@ 2020-03-17 7:18 ` Masahiro Yamada
0 siblings, 0 replies; 16+ messages in thread
From: Masahiro Yamada @ 2020-03-17 7:18 UTC (permalink / raw)
To: linux-mtd
Cc: Marek Vasut, Vignesh Raghavendra, Richard Weinberger,
linux-kernel, Masahiro Yamada, Miquel Raynal
The Denali IP have several registers to specify how many clock cycles
should be waited between falling/rising signals. You can improve the
NAND access performance by programming these registers with optimized
values.
Because struct nand_sdr_timings represents the device requirement
in pico seconds, denali_setup_data_interface() computes the register
values by dividing the device timings with the clock period.
Marek Vasut reported this driver in the latest kernel does not work
on his SOCFPGA board. (The on-board NAND chip is mode 5)
The suspicious parameter is acc_clks, so this commit relaxes it.
The Denali NAND Flash Memory Controller User's Guide describes this
register as follows:
acc_clks
signifies the number of bus interface clk_x clock cycles,
controller should wait from read enable going low to sending
out a strobe of clk_x for capturing of incoming data.
Currently, acc_clks is calculated only based on tREA, the delay on the
chip side. This does not include additional delays that come from the
data path on the PCB and in the SoC, load capacity of the pins, etc.
This relatively becomes a big factor on faster timing modes like mode 5.
Before supporting the ->setup_data_interface() hook (e.g. Linux 4.12),
the Denali driver hacks acc_clks in a couple of ways [1] [2] to support
the timing mode 5.
We would not go back to the hard-coded acc_clks, but we need to include
this factor into the delay somehow. Let's say the amount of the additional
delay is 10000 pico sec.
In the new calculation, acc_clks is determined by timings->tREA_max +
data_setup_on_host.
Also, prolong the RE# low period to make sure the data hold is met.
Finally, re-center the data latch timing for extra safety.
[1] https://github.com/torvalds/linux/blob/v4.12/drivers/mtd/nand/denali.c#L276
[2] https://github.com/torvalds/linux/blob/v4.12/drivers/mtd/nand/denali.c#L282
Reported-by: Marek Vasut <marex@denx.de>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Changes in v2:
- Use 'unsigned int' instead of 'u32' for data_setup_on_host
- Fix 'line over 80 characters' warning from checkpatch.pl
drivers/mtd/nand/raw/denali.c | 45 ++++++++++++++++++++++++++---------
1 file changed, 34 insertions(+), 11 deletions(-)
diff --git a/drivers/mtd/nand/raw/denali.c b/drivers/mtd/nand/raw/denali.c
index 6a6c919b2569..2fcd2baf6e35 100644
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -764,6 +764,7 @@ static int denali_write_page(struct nand_chip *chip, const u8 *buf,
static int denali_setup_data_interface(struct nand_chip *chip, int chipnr,
const struct nand_data_interface *conf)
{
+ static const unsigned int data_setup_on_host = 10000;
struct denali_controller *denali = to_denali_controller(chip);
struct denali_chip_sel *sel;
const struct nand_sdr_timings *timings;
@@ -796,15 +797,6 @@ static int denali_setup_data_interface(struct nand_chip *chip, int chipnr,
sel = &to_denali_chip(chip)->sels[chipnr];
- /* tREA -> ACC_CLKS */
- acc_clks = DIV_ROUND_UP(timings->tREA_max, t_x);
- acc_clks = min_t(int, acc_clks, ACC_CLKS__VALUE);
-
- tmp = ioread32(denali->reg + ACC_CLKS);
- tmp &= ~ACC_CLKS__VALUE;
- tmp |= FIELD_PREP(ACC_CLKS__VALUE, acc_clks);
- sel->acc_clks = tmp;
-
/* tRWH -> RE_2_WE */
re_2_we = DIV_ROUND_UP(timings->tRHW_min, t_x);
re_2_we = min_t(int, re_2_we, RE_2_WE__VALUE);
@@ -862,14 +854,45 @@ static int denali_setup_data_interface(struct nand_chip *chip, int chipnr,
tmp |= FIELD_PREP(RDWR_EN_HI_CNT__VALUE, rdwr_en_hi);
sel->rdwr_en_hi_cnt = tmp;
- /* tRP, tWP -> RDWR_EN_LO_CNT */
+ /*
+ * tREA -> ACC_CLKS
+ * tRP, tWP, tRHOH, tRC, tWC -> RDWR_EN_LO_CNT
+ */
+
+ /*
+ * Determine the minimum of acc_clks to meet the setup timing when
+ * capturing the incoming data.
+ *
+ * The delay on the chip side is well-defined as tREA, but we need to
+ * take additional delay into account. This includes a certain degree
+ * of unknowledge, such as signal propagation delays on the PCB and
+ * in the SoC, load capacity of the I/O pins, etc.
+ */
+ acc_clks = DIV_ROUND_UP(timings->tREA_max + data_setup_on_host, t_x);
+
+ /* Determine the minimum of rdwr_en_lo_cnt from RE#/WE# pulse width */
rdwr_en_lo = DIV_ROUND_UP(max(timings->tRP_min, timings->tWP_min), t_x);
+
+ /* Extend rdwr_en_lo to meet the data hold timing */
+ rdwr_en_lo = max_t(int, rdwr_en_lo,
+ acc_clks - timings->tRHOH_min / t_x);
+
+ /* Extend rdwr_en_lo to meet the requirement for RE#/WE# cycle time */
rdwr_en_lo_hi = DIV_ROUND_UP(max(timings->tRC_min, timings->tWC_min),
t_x);
- rdwr_en_lo_hi = max_t(int, rdwr_en_lo_hi, mult_x);
rdwr_en_lo = max(rdwr_en_lo, rdwr_en_lo_hi - rdwr_en_hi);
rdwr_en_lo = min_t(int, rdwr_en_lo, RDWR_EN_LO_CNT__VALUE);
+ /* Center the data latch timing for extra safety */
+ acc_clks = (acc_clks + rdwr_en_lo +
+ DIV_ROUND_UP(timings->tRHOH_min, t_x)) / 2;
+ acc_clks = min_t(int, acc_clks, ACC_CLKS__VALUE);
+
+ tmp = ioread32(denali->reg + ACC_CLKS);
+ tmp &= ~ACC_CLKS__VALUE;
+ tmp |= FIELD_PREP(ACC_CLKS__VALUE, acc_clks);
+ sel->acc_clks = tmp;
+
tmp = ioread32(denali->reg + RDWR_EN_LO_CNT);
tmp &= ~RDWR_EN_LO_CNT__VALUE;
tmp |= FIELD_PREP(RDWR_EN_LO_CNT__VALUE, rdwr_en_lo);
--
2.17.1
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH v2] mtd: rawnand: denali: add more delays before latching incoming data
2020-03-17 7:18 ` Masahiro Yamada
@ 2020-04-22 15:29 ` Marek Vasut
-1 siblings, 0 replies; 16+ messages in thread
From: Marek Vasut @ 2020-04-22 15:29 UTC (permalink / raw)
To: Masahiro Yamada, linux-mtd
Cc: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra, linux-kernel
On 3/17/20 8:18 AM, Masahiro Yamada wrote:
> The Denali IP have several registers to specify how many clock cycles
> should be waited between falling/rising signals. You can improve the
> NAND access performance by programming these registers with optimized
> values.
>
> Because struct nand_sdr_timings represents the device requirement
> in pico seconds, denali_setup_data_interface() computes the register
> values by dividing the device timings with the clock period.
>
> Marek Vasut reported this driver in the latest kernel does not work
> on his SOCFPGA board. (The on-board NAND chip is mode 5)
>
> The suspicious parameter is acc_clks, so this commit relaxes it.
>
> The Denali NAND Flash Memory Controller User's Guide describes this
> register as follows:
>
> acc_clks
> signifies the number of bus interface clk_x clock cycles,
> controller should wait from read enable going low to sending
> out a strobe of clk_x for capturing of incoming data.
>
> Currently, acc_clks is calculated only based on tREA, the delay on the
> chip side. This does not include additional delays that come from the
> data path on the PCB and in the SoC, load capacity of the pins, etc.
>
> This relatively becomes a big factor on faster timing modes like mode 5.
>
> Before supporting the ->setup_data_interface() hook (e.g. Linux 4.12),
> the Denali driver hacks acc_clks in a couple of ways [1] [2] to support
> the timing mode 5.
>
> We would not go back to the hard-coded acc_clks, but we need to include
> this factor into the delay somehow. Let's say the amount of the additional
> delay is 10000 pico sec.
>
> In the new calculation, acc_clks is determined by timings->tREA_max +
> data_setup_on_host.
>
> Also, prolong the RE# low period to make sure the data hold is met.
>
> Finally, re-center the data latch timing for extra safety.
>
> [1] https://github.com/torvalds/linux/blob/v4.12/drivers/mtd/nand/denali.c#L276
> [2] https://github.com/torvalds/linux/blob/v4.12/drivers/mtd/nand/denali.c#L282
>
> Reported-by: Marek Vasut <marex@denx.de>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
I tested it on the AV SoCFPGA, this seems to work, so feel free to apply.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] mtd: rawnand: denali: add more delays before latching incoming data
@ 2020-04-22 15:29 ` Marek Vasut
0 siblings, 0 replies; 16+ messages in thread
From: Marek Vasut @ 2020-04-22 15:29 UTC (permalink / raw)
To: Masahiro Yamada, linux-mtd
Cc: Richard Weinberger, Vignesh Raghavendra, linux-kernel, Miquel Raynal
On 3/17/20 8:18 AM, Masahiro Yamada wrote:
> The Denali IP have several registers to specify how many clock cycles
> should be waited between falling/rising signals. You can improve the
> NAND access performance by programming these registers with optimized
> values.
>
> Because struct nand_sdr_timings represents the device requirement
> in pico seconds, denali_setup_data_interface() computes the register
> values by dividing the device timings with the clock period.
>
> Marek Vasut reported this driver in the latest kernel does not work
> on his SOCFPGA board. (The on-board NAND chip is mode 5)
>
> The suspicious parameter is acc_clks, so this commit relaxes it.
>
> The Denali NAND Flash Memory Controller User's Guide describes this
> register as follows:
>
> acc_clks
> signifies the number of bus interface clk_x clock cycles,
> controller should wait from read enable going low to sending
> out a strobe of clk_x for capturing of incoming data.
>
> Currently, acc_clks is calculated only based on tREA, the delay on the
> chip side. This does not include additional delays that come from the
> data path on the PCB and in the SoC, load capacity of the pins, etc.
>
> This relatively becomes a big factor on faster timing modes like mode 5.
>
> Before supporting the ->setup_data_interface() hook (e.g. Linux 4.12),
> the Denali driver hacks acc_clks in a couple of ways [1] [2] to support
> the timing mode 5.
>
> We would not go back to the hard-coded acc_clks, but we need to include
> this factor into the delay somehow. Let's say the amount of the additional
> delay is 10000 pico sec.
>
> In the new calculation, acc_clks is determined by timings->tREA_max +
> data_setup_on_host.
>
> Also, prolong the RE# low period to make sure the data hold is met.
>
> Finally, re-center the data latch timing for extra safety.
>
> [1] https://github.com/torvalds/linux/blob/v4.12/drivers/mtd/nand/denali.c#L276
> [2] https://github.com/torvalds/linux/blob/v4.12/drivers/mtd/nand/denali.c#L282
>
> Reported-by: Marek Vasut <marex@denx.de>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
I tested it on the AV SoCFPGA, this seems to work, so feel free to apply.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] mtd: rawnand: denali: add more delays before latching incoming data
2020-04-22 15:29 ` Marek Vasut
@ 2020-04-22 15:36 ` Miquel Raynal
-1 siblings, 0 replies; 16+ messages in thread
From: Miquel Raynal @ 2020-04-22 15:36 UTC (permalink / raw)
To: Marek Vasut
Cc: Masahiro Yamada, linux-mtd, Richard Weinberger,
Vignesh Raghavendra, linux-kernel
Hi Marek,
Marek Vasut <marex@denx.de> wrote on Wed, 22 Apr 2020 17:29:53 +0200:
> On 3/17/20 8:18 AM, Masahiro Yamada wrote:
> > The Denali IP have several registers to specify how many clock cycles
> > should be waited between falling/rising signals. You can improve the
> > NAND access performance by programming these registers with optimized
> > values.
> >
> > Because struct nand_sdr_timings represents the device requirement
> > in pico seconds, denali_setup_data_interface() computes the register
> > values by dividing the device timings with the clock period.
> >
> > Marek Vasut reported this driver in the latest kernel does not work
> > on his SOCFPGA board. (The on-board NAND chip is mode 5)
> >
> > The suspicious parameter is acc_clks, so this commit relaxes it.
> >
> > The Denali NAND Flash Memory Controller User's Guide describes this
> > register as follows:
> >
> > acc_clks
> > signifies the number of bus interface clk_x clock cycles,
> > controller should wait from read enable going low to sending
> > out a strobe of clk_x for capturing of incoming data.
> >
> > Currently, acc_clks is calculated only based on tREA, the delay on the
> > chip side. This does not include additional delays that come from the
> > data path on the PCB and in the SoC, load capacity of the pins, etc.
> >
> > This relatively becomes a big factor on faster timing modes like mode 5.
> >
> > Before supporting the ->setup_data_interface() hook (e.g. Linux 4.12),
> > the Denali driver hacks acc_clks in a couple of ways [1] [2] to support
> > the timing mode 5.
> >
> > We would not go back to the hard-coded acc_clks, but we need to include
> > this factor into the delay somehow. Let's say the amount of the additional
> > delay is 10000 pico sec.
> >
> > In the new calculation, acc_clks is determined by timings->tREA_max +
> > data_setup_on_host.
> >
> > Also, prolong the RE# low period to make sure the data hold is met.
> >
> > Finally, re-center the data latch timing for extra safety.
> >
> > [1] https://github.com/torvalds/linux/blob/v4.12/drivers/mtd/nand/denali.c#L276
> > [2] https://github.com/torvalds/linux/blob/v4.12/drivers/mtd/nand/denali.c#L282
> >
> > Reported-by: Marek Vasut <marex@denx.de>
> > Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>
> I tested it on the AV SoCFPGA, this seems to work, so feel free to apply.
Great! Thanks a lot for testing, would you mind sending your Tested-by?
Thanks,
Miquèl
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] mtd: rawnand: denali: add more delays before latching incoming data
@ 2020-04-22 15:36 ` Miquel Raynal
0 siblings, 0 replies; 16+ messages in thread
From: Miquel Raynal @ 2020-04-22 15:36 UTC (permalink / raw)
To: Marek Vasut
Cc: Masahiro Yamada, linux-mtd, Vignesh Raghavendra, linux-kernel,
Richard Weinberger
Hi Marek,
Marek Vasut <marex@denx.de> wrote on Wed, 22 Apr 2020 17:29:53 +0200:
> On 3/17/20 8:18 AM, Masahiro Yamada wrote:
> > The Denali IP have several registers to specify how many clock cycles
> > should be waited between falling/rising signals. You can improve the
> > NAND access performance by programming these registers with optimized
> > values.
> >
> > Because struct nand_sdr_timings represents the device requirement
> > in pico seconds, denali_setup_data_interface() computes the register
> > values by dividing the device timings with the clock period.
> >
> > Marek Vasut reported this driver in the latest kernel does not work
> > on his SOCFPGA board. (The on-board NAND chip is mode 5)
> >
> > The suspicious parameter is acc_clks, so this commit relaxes it.
> >
> > The Denali NAND Flash Memory Controller User's Guide describes this
> > register as follows:
> >
> > acc_clks
> > signifies the number of bus interface clk_x clock cycles,
> > controller should wait from read enable going low to sending
> > out a strobe of clk_x for capturing of incoming data.
> >
> > Currently, acc_clks is calculated only based on tREA, the delay on the
> > chip side. This does not include additional delays that come from the
> > data path on the PCB and in the SoC, load capacity of the pins, etc.
> >
> > This relatively becomes a big factor on faster timing modes like mode 5.
> >
> > Before supporting the ->setup_data_interface() hook (e.g. Linux 4.12),
> > the Denali driver hacks acc_clks in a couple of ways [1] [2] to support
> > the timing mode 5.
> >
> > We would not go back to the hard-coded acc_clks, but we need to include
> > this factor into the delay somehow. Let's say the amount of the additional
> > delay is 10000 pico sec.
> >
> > In the new calculation, acc_clks is determined by timings->tREA_max +
> > data_setup_on_host.
> >
> > Also, prolong the RE# low period to make sure the data hold is met.
> >
> > Finally, re-center the data latch timing for extra safety.
> >
> > [1] https://github.com/torvalds/linux/blob/v4.12/drivers/mtd/nand/denali.c#L276
> > [2] https://github.com/torvalds/linux/blob/v4.12/drivers/mtd/nand/denali.c#L282
> >
> > Reported-by: Marek Vasut <marex@denx.de>
> > Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>
> I tested it on the AV SoCFPGA, this seems to work, so feel free to apply.
Great! Thanks a lot for testing, would you mind sending your Tested-by?
Thanks,
Miquèl
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] mtd: rawnand: denali: add more delays before latching incoming data
2020-04-22 15:36 ` Miquel Raynal
@ 2020-04-22 15:37 ` Marek Vasut
-1 siblings, 0 replies; 16+ messages in thread
From: Marek Vasut @ 2020-04-22 15:37 UTC (permalink / raw)
To: Miquel Raynal
Cc: Masahiro Yamada, linux-mtd, Richard Weinberger,
Vignesh Raghavendra, linux-kernel
On 4/22/20 5:36 PM, Miquel Raynal wrote:
> Hi Marek,
>
> Marek Vasut <marex@denx.de> wrote on Wed, 22 Apr 2020 17:29:53 +0200:
>
>> On 3/17/20 8:18 AM, Masahiro Yamada wrote:
>>> The Denali IP have several registers to specify how many clock cycles
>>> should be waited between falling/rising signals. You can improve the
>>> NAND access performance by programming these registers with optimized
>>> values.
>>>
>>> Because struct nand_sdr_timings represents the device requirement
>>> in pico seconds, denali_setup_data_interface() computes the register
>>> values by dividing the device timings with the clock period.
>>>
>>> Marek Vasut reported this driver in the latest kernel does not work
>>> on his SOCFPGA board. (The on-board NAND chip is mode 5)
>>>
>>> The suspicious parameter is acc_clks, so this commit relaxes it.
>>>
>>> The Denali NAND Flash Memory Controller User's Guide describes this
>>> register as follows:
>>>
>>> acc_clks
>>> signifies the number of bus interface clk_x clock cycles,
>>> controller should wait from read enable going low to sending
>>> out a strobe of clk_x for capturing of incoming data.
>>>
>>> Currently, acc_clks is calculated only based on tREA, the delay on the
>>> chip side. This does not include additional delays that come from the
>>> data path on the PCB and in the SoC, load capacity of the pins, etc.
>>>
>>> This relatively becomes a big factor on faster timing modes like mode 5.
>>>
>>> Before supporting the ->setup_data_interface() hook (e.g. Linux 4.12),
>>> the Denali driver hacks acc_clks in a couple of ways [1] [2] to support
>>> the timing mode 5.
>>>
>>> We would not go back to the hard-coded acc_clks, but we need to include
>>> this factor into the delay somehow. Let's say the amount of the additional
>>> delay is 10000 pico sec.
>>>
>>> In the new calculation, acc_clks is determined by timings->tREA_max +
>>> data_setup_on_host.
>>>
>>> Also, prolong the RE# low period to make sure the data hold is met.
>>>
>>> Finally, re-center the data latch timing for extra safety.
>>>
>>> [1] https://github.com/torvalds/linux/blob/v4.12/drivers/mtd/nand/denali.c#L276
>>> [2] https://github.com/torvalds/linux/blob/v4.12/drivers/mtd/nand/denali.c#L282
>>>
>>> Reported-by: Marek Vasut <marex@denx.de>
>>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>>
>> I tested it on the AV SoCFPGA, this seems to work, so feel free to apply.
>
>
> Great! Thanks a lot for testing, would you mind sending your Tested-by?
Lightly
Tested-by: Marek Vasut <marex@denx.de>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] mtd: rawnand: denali: add more delays before latching incoming data
@ 2020-04-22 15:37 ` Marek Vasut
0 siblings, 0 replies; 16+ messages in thread
From: Marek Vasut @ 2020-04-22 15:37 UTC (permalink / raw)
To: Miquel Raynal
Cc: Masahiro Yamada, linux-mtd, Vignesh Raghavendra, linux-kernel,
Richard Weinberger
On 4/22/20 5:36 PM, Miquel Raynal wrote:
> Hi Marek,
>
> Marek Vasut <marex@denx.de> wrote on Wed, 22 Apr 2020 17:29:53 +0200:
>
>> On 3/17/20 8:18 AM, Masahiro Yamada wrote:
>>> The Denali IP have several registers to specify how many clock cycles
>>> should be waited between falling/rising signals. You can improve the
>>> NAND access performance by programming these registers with optimized
>>> values.
>>>
>>> Because struct nand_sdr_timings represents the device requirement
>>> in pico seconds, denali_setup_data_interface() computes the register
>>> values by dividing the device timings with the clock period.
>>>
>>> Marek Vasut reported this driver in the latest kernel does not work
>>> on his SOCFPGA board. (The on-board NAND chip is mode 5)
>>>
>>> The suspicious parameter is acc_clks, so this commit relaxes it.
>>>
>>> The Denali NAND Flash Memory Controller User's Guide describes this
>>> register as follows:
>>>
>>> acc_clks
>>> signifies the number of bus interface clk_x clock cycles,
>>> controller should wait from read enable going low to sending
>>> out a strobe of clk_x for capturing of incoming data.
>>>
>>> Currently, acc_clks is calculated only based on tREA, the delay on the
>>> chip side. This does not include additional delays that come from the
>>> data path on the PCB and in the SoC, load capacity of the pins, etc.
>>>
>>> This relatively becomes a big factor on faster timing modes like mode 5.
>>>
>>> Before supporting the ->setup_data_interface() hook (e.g. Linux 4.12),
>>> the Denali driver hacks acc_clks in a couple of ways [1] [2] to support
>>> the timing mode 5.
>>>
>>> We would not go back to the hard-coded acc_clks, but we need to include
>>> this factor into the delay somehow. Let's say the amount of the additional
>>> delay is 10000 pico sec.
>>>
>>> In the new calculation, acc_clks is determined by timings->tREA_max +
>>> data_setup_on_host.
>>>
>>> Also, prolong the RE# low period to make sure the data hold is met.
>>>
>>> Finally, re-center the data latch timing for extra safety.
>>>
>>> [1] https://github.com/torvalds/linux/blob/v4.12/drivers/mtd/nand/denali.c#L276
>>> [2] https://github.com/torvalds/linux/blob/v4.12/drivers/mtd/nand/denali.c#L282
>>>
>>> Reported-by: Marek Vasut <marex@denx.de>
>>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>>
>> I tested it on the AV SoCFPGA, this seems to work, so feel free to apply.
>
>
> Great! Thanks a lot for testing, would you mind sending your Tested-by?
Lightly
Tested-by: Marek Vasut <marex@denx.de>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] mtd: rawnand: denali: add more delays before latching incoming data
2020-03-17 7:18 ` Masahiro Yamada
@ 2020-05-10 20:06 ` Miquel Raynal
-1 siblings, 0 replies; 16+ messages in thread
From: Miquel Raynal @ 2020-05-10 20:06 UTC (permalink / raw)
To: Masahiro Yamada, linux-mtd
Cc: Miquel Raynal, Marek Vasut, Vignesh Raghavendra,
Richard Weinberger, linux-kernel
On Tue, 2020-03-17 at 07:18:21 UTC, Masahiro Yamada wrote:
> The Denali IP have several registers to specify how many clock cycles
> should be waited between falling/rising signals. You can improve the
> NAND access performance by programming these registers with optimized
> values.
>
> Because struct nand_sdr_timings represents the device requirement
> in pico seconds, denali_setup_data_interface() computes the register
> values by dividing the device timings with the clock period.
>
> Marek Vasut reported this driver in the latest kernel does not work
> on his SOCFPGA board. (The on-board NAND chip is mode 5)
>
> The suspicious parameter is acc_clks, so this commit relaxes it.
>
> The Denali NAND Flash Memory Controller User's Guide describes this
> register as follows:
>
> acc_clks
> signifies the number of bus interface clk_x clock cycles,
> controller should wait from read enable going low to sending
> out a strobe of clk_x for capturing of incoming data.
>
> Currently, acc_clks is calculated only based on tREA, the delay on the
> chip side. This does not include additional delays that come from the
> data path on the PCB and in the SoC, load capacity of the pins, etc.
>
> This relatively becomes a big factor on faster timing modes like mode 5.
>
> Before supporting the ->setup_data_interface() hook (e.g. Linux 4.12),
> the Denali driver hacks acc_clks in a couple of ways [1] [2] to support
> the timing mode 5.
>
> We would not go back to the hard-coded acc_clks, but we need to include
> this factor into the delay somehow. Let's say the amount of the additional
> delay is 10000 pico sec.
>
> In the new calculation, acc_clks is determined by timings->tREA_max +
> data_setup_on_host.
>
> Also, prolong the RE# low period to make sure the data hold is met.
>
> Finally, re-center the data latch timing for extra safety.
>
> [1] https://github.com/torvalds/linux/blob/v4.12/drivers/mtd/nand/denali.c#L276
> [2] https://github.com/torvalds/linux/blob/v4.12/drivers/mtd/nand/denali.c#L282
>
> Reported-by: Marek Vasut <marex@denx.de>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Tested-by: Marek Vasut <marex@denx.de>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next, thanks.
Miquel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] mtd: rawnand: denali: add more delays before latching incoming data
@ 2020-05-10 20:06 ` Miquel Raynal
0 siblings, 0 replies; 16+ messages in thread
From: Miquel Raynal @ 2020-05-10 20:06 UTC (permalink / raw)
To: Masahiro Yamada, linux-mtd
Cc: Marek Vasut, Richard Weinberger, Vignesh Raghavendra,
linux-kernel, Miquel Raynal
On Tue, 2020-03-17 at 07:18:21 UTC, Masahiro Yamada wrote:
> The Denali IP have several registers to specify how many clock cycles
> should be waited between falling/rising signals. You can improve the
> NAND access performance by programming these registers with optimized
> values.
>
> Because struct nand_sdr_timings represents the device requirement
> in pico seconds, denali_setup_data_interface() computes the register
> values by dividing the device timings with the clock period.
>
> Marek Vasut reported this driver in the latest kernel does not work
> on his SOCFPGA board. (The on-board NAND chip is mode 5)
>
> The suspicious parameter is acc_clks, so this commit relaxes it.
>
> The Denali NAND Flash Memory Controller User's Guide describes this
> register as follows:
>
> acc_clks
> signifies the number of bus interface clk_x clock cycles,
> controller should wait from read enable going low to sending
> out a strobe of clk_x for capturing of incoming data.
>
> Currently, acc_clks is calculated only based on tREA, the delay on the
> chip side. This does not include additional delays that come from the
> data path on the PCB and in the SoC, load capacity of the pins, etc.
>
> This relatively becomes a big factor on faster timing modes like mode 5.
>
> Before supporting the ->setup_data_interface() hook (e.g. Linux 4.12),
> the Denali driver hacks acc_clks in a couple of ways [1] [2] to support
> the timing mode 5.
>
> We would not go back to the hard-coded acc_clks, but we need to include
> this factor into the delay somehow. Let's say the amount of the additional
> delay is 10000 pico sec.
>
> In the new calculation, acc_clks is determined by timings->tREA_max +
> data_setup_on_host.
>
> Also, prolong the RE# low period to make sure the data hold is met.
>
> Finally, re-center the data latch timing for extra safety.
>
> [1] https://github.com/torvalds/linux/blob/v4.12/drivers/mtd/nand/denali.c#L276
> [2] https://github.com/torvalds/linux/blob/v4.12/drivers/mtd/nand/denali.c#L282
>
> Reported-by: Marek Vasut <marex@denx.de>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Tested-by: Marek Vasut <marex@denx.de>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git nand/next, thanks.
Miquel
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] mtd: rawnand: denali: add more delays before latching incoming data
2020-03-17 7:18 ` Masahiro Yamada
@ 2021-06-30 18:47 ` Ralph Siemsen
-1 siblings, 0 replies; 16+ messages in thread
From: Ralph Siemsen @ 2021-06-30 18:47 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mtd, Marek Vasut, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, linux-kernel
On Tue, Mar 17, 2020 at 04:18:21PM +0900, Masahiro Yamada wrote:
>
>Marek Vasut reported this driver in the latest kernel does not work
>on his SOCFPGA board. (The on-board NAND chip is mode 5)
In a bit of an ironic twist, this change seems to cause a regression for
me. I'm also using a Cyclone V SoC system, similar but not the same as
the SOCFPGA eval board. The NAND device in my case is S34ML04G2.
It worked fine in 4.9, 4.19 and 5.4 kernels. However after upgrading to
5.10 the NAND driver fails with "timeout while waiting for irq 0x4",
just as was reported back in 2018:
https://lore.kernel.org/linux-mtd/737ejrj81y.fsf@pengutronix.de/
Reverting commit 5756f2e8dad46eba6e2d3e530243b8eff4dd5a42 restores the
behaviour in my case, but that would presumably break the SOCFPGA board.
Any thoughts on how we could make it work for everybody?
Ralph
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] mtd: rawnand: denali: add more delays before latching incoming data
@ 2021-06-30 18:47 ` Ralph Siemsen
0 siblings, 0 replies; 16+ messages in thread
From: Ralph Siemsen @ 2021-06-30 18:47 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mtd, Marek Vasut, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, linux-kernel
On Tue, Mar 17, 2020 at 04:18:21PM +0900, Masahiro Yamada wrote:
>
>Marek Vasut reported this driver in the latest kernel does not work
>on his SOCFPGA board. (The on-board NAND chip is mode 5)
In a bit of an ironic twist, this change seems to cause a regression for
me. I'm also using a Cyclone V SoC system, similar but not the same as
the SOCFPGA eval board. The NAND device in my case is S34ML04G2.
It worked fine in 4.9, 4.19 and 5.4 kernels. However after upgrading to
5.10 the NAND driver fails with "timeout while waiting for irq 0x4",
just as was reported back in 2018:
https://lore.kernel.org/linux-mtd/737ejrj81y.fsf@pengutronix.de/
Reverting commit 5756f2e8dad46eba6e2d3e530243b8eff4dd5a42 restores the
behaviour in my case, but that would presumably break the SOCFPGA board.
Any thoughts on how we could make it work for everybody?
Ralph
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] mtd: rawnand: denali: add more delays before latching incoming data
2021-06-30 18:47 ` Ralph Siemsen
@ 2021-07-04 16:00 ` Masahiro Yamada
-1 siblings, 0 replies; 16+ messages in thread
From: Masahiro Yamada @ 2021-07-04 16:00 UTC (permalink / raw)
To: Ralph Siemsen
Cc: linux-mtd, Marek Vasut, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Linux Kernel Mailing List
On Thu, Jul 1, 2021 at 3:47 AM Ralph Siemsen <ralph.siemsen@linaro.org> wrote:
>
> On Tue, Mar 17, 2020 at 04:18:21PM +0900, Masahiro Yamada wrote:
> >
> >Marek Vasut reported this driver in the latest kernel does not work
> >on his SOCFPGA board. (The on-board NAND chip is mode 5)
>
> In a bit of an ironic twist, this change seems to cause a regression for
> me. I'm also using a Cyclone V SoC system, similar but not the same as
> the SOCFPGA eval board. The NAND device in my case is S34ML04G2.
>
> It worked fine in 4.9, 4.19 and 5.4 kernels. However after upgrading to
> 5.10 the NAND driver fails with "timeout while waiting for irq 0x4",
> just as was reported back in 2018:
> https://lore.kernel.org/linux-mtd/737ejrj81y.fsf@pengutronix.de/
>
> Reverting commit 5756f2e8dad46eba6e2d3e530243b8eff4dd5a42 restores the
> behaviour in my case, but that would presumably break the SOCFPGA board.
>
> Any thoughts on how we could make it work for everybody?
>
> Ralph
I no longer have any hardware to test this driver.
If you increase data_setup_on_host (the current value is 10000),
will it solve your issue?
--
Best Regards
Masahiro Yamada
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] mtd: rawnand: denali: add more delays before latching incoming data
@ 2021-07-04 16:00 ` Masahiro Yamada
0 siblings, 0 replies; 16+ messages in thread
From: Masahiro Yamada @ 2021-07-04 16:00 UTC (permalink / raw)
To: Ralph Siemsen
Cc: linux-mtd, Marek Vasut, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Linux Kernel Mailing List
On Thu, Jul 1, 2021 at 3:47 AM Ralph Siemsen <ralph.siemsen@linaro.org> wrote:
>
> On Tue, Mar 17, 2020 at 04:18:21PM +0900, Masahiro Yamada wrote:
> >
> >Marek Vasut reported this driver in the latest kernel does not work
> >on his SOCFPGA board. (The on-board NAND chip is mode 5)
>
> In a bit of an ironic twist, this change seems to cause a regression for
> me. I'm also using a Cyclone V SoC system, similar but not the same as
> the SOCFPGA eval board. The NAND device in my case is S34ML04G2.
>
> It worked fine in 4.9, 4.19 and 5.4 kernels. However after upgrading to
> 5.10 the NAND driver fails with "timeout while waiting for irq 0x4",
> just as was reported back in 2018:
> https://lore.kernel.org/linux-mtd/737ejrj81y.fsf@pengutronix.de/
>
> Reverting commit 5756f2e8dad46eba6e2d3e530243b8eff4dd5a42 restores the
> behaviour in my case, but that would presumably break the SOCFPGA board.
>
> Any thoughts on how we could make it work for everybody?
>
> Ralph
I no longer have any hardware to test this driver.
If you increase data_setup_on_host (the current value is 10000),
will it solve your issue?
--
Best Regards
Masahiro Yamada
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] mtd: rawnand: denali: add more delays before latching incoming data
2021-07-04 16:00 ` Masahiro Yamada
@ 2021-07-05 14:48 ` Ralph Siemsen
-1 siblings, 0 replies; 16+ messages in thread
From: Ralph Siemsen @ 2021-07-05 14:48 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mtd, Marek Vasut, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Linux Kernel Mailing List
On Mon, Jul 05, 2021 at 01:00:43AM +0900, Masahiro Yamada wrote:
>
>I no longer have any hardware to test this driver.
>
>If you increase data_setup_on_host (the current value is 10000),
>will it solve your issue?
Yes, it does seem to work with this value increased to 10001.
Looking more closely, I compared timing parameters in struct
denali_chip_sel, for the kernel 5.4 (which works), for 5.10 (which
fails), and also for 5.10 with data_setup_host=10001 (which works).
5.4 5.10 5.10+10001
acc_clks 2 3 4
rdwr_en_lo_cnt 3 2 3
cs_setup_cnt 1 0 0
So it seems that on my hardware, rdwr_en_lo_cnt must be >= 3.
Regards,
Ralph
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] mtd: rawnand: denali: add more delays before latching incoming data
@ 2021-07-05 14:48 ` Ralph Siemsen
0 siblings, 0 replies; 16+ messages in thread
From: Ralph Siemsen @ 2021-07-05 14:48 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-mtd, Marek Vasut, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Linux Kernel Mailing List
On Mon, Jul 05, 2021 at 01:00:43AM +0900, Masahiro Yamada wrote:
>
>I no longer have any hardware to test this driver.
>
>If you increase data_setup_on_host (the current value is 10000),
>will it solve your issue?
Yes, it does seem to work with this value increased to 10001.
Looking more closely, I compared timing parameters in struct
denali_chip_sel, for the kernel 5.4 (which works), for 5.10 (which
fails), and also for 5.10 with data_setup_host=10001 (which works).
5.4 5.10 5.10+10001
acc_clks 2 3 4
rdwr_en_lo_cnt 3 2 3
cs_setup_cnt 1 0 0
So it seems that on my hardware, rdwr_en_lo_cnt must be >= 3.
Regards,
Ralph
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2021-07-05 14:49 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-17 7:18 [PATCH v2] mtd: rawnand: denali: add more delays before latching incoming data Masahiro Yamada
2020-03-17 7:18 ` Masahiro Yamada
2020-04-22 15:29 ` Marek Vasut
2020-04-22 15:29 ` Marek Vasut
2020-04-22 15:36 ` Miquel Raynal
2020-04-22 15:36 ` Miquel Raynal
2020-04-22 15:37 ` Marek Vasut
2020-04-22 15:37 ` Marek Vasut
2020-05-10 20:06 ` Miquel Raynal
2020-05-10 20:06 ` Miquel Raynal
2021-06-30 18:47 ` Ralph Siemsen
2021-06-30 18:47 ` Ralph Siemsen
2021-07-04 16:00 ` Masahiro Yamada
2021-07-04 16:00 ` Masahiro Yamada
2021-07-05 14:48 ` Ralph Siemsen
2021-07-05 14:48 ` Ralph Siemsen
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.