linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* GPMI iMX6ull timeout on DMA
@ 2019-07-29  6:41 Greg Ungerer
  2019-07-29  8:36 ` Miquel Raynal
  2021-10-04  5:54 ` Christian Eggers
  0 siblings, 2 replies; 85+ messages in thread
From: Greg Ungerer @ 2019-07-29  6:41 UTC (permalink / raw)
  To: Miquel Raynal; +Cc: linux-mtd

Hi Miquel,

I am experiencing a problem with NAND flash DMA timeouts on
iMX6ull based boards. The problem is very similar to that
described in:

   https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma

That didn't come to any specific resolution that I could see
in that thread.

The boot trace on the console for me looks like this:

nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
gpmi-nand 1806000.gpmi-nand: Show BCH registers :
gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
gpmi-nand 1806000.gpmi-nand: BCH Geometry :
GF length              : 13
ECC Strength           : 8
Page Size in Bytes     : 2110
Metadata Size in Bytes : 10
ECC Chunk0 Size in Bytes: 512
ECC Chunkn Size in Bytes: 512
ECC Chunk Count        : 4
Payload Size in Bytes  : 2048
Auxiliary Size in Bytes: 16
Auxiliary Status Offset: 12
Block Mark Byte Offset : 1999
Block Mark Bit Offset  : 0
gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
nand: timing mode 5 not acknowledged by the NAND chip
gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
Scanning device for bad blocks
gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
....
gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
5 fixed-partitions partitions found on MTD device gpmi-nand
Creating 5 MTD partitions on "gpmi-nand":
0x000000000000-0x000000500000 : "u-boot"
0x000000500000-0x000000600000 : "u-boot-env"
0x000000600000-0x000000800000 : "log"
0x000000800000-0x000010000000 : "flash"
0x000000000000-0x000010000000 : "all"
gpmi-nand 1806000.gpmi-nand: driver registered.


This is using a linux kernel v5.1.14. I have seen this happen on
a number of boards I have here - but it is only occasional. It
only happens once in a while on boot, maybe 1 in 40 or more times.
So it can take quite a while to reproduce (using a boot loop setup).

As per the email thread I pointed to above I looked at reverting
those patches, but that was not at all easy given how much the gpmi
driver code had moved. So instead I modified the code with this:

--- a/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
+++ b/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
@@ -481,6 +481,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
  
  void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
  {
+#if 0
         struct gpmi_nfc_hardware_timing *hw = &this->hw;
         struct resources *r = &this->resources;
         void __iomem *gpmi_regs = r->gpmi_regs;
@@ -505,6 +512,7 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
  
         /* Wait for the DLL to settle. */
         udelay(dll_wait_time_us);
+#endif
  }
  
  int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,

So far after a couple of days of testing with this I no longer
see the DMA timeout.

Any thoughts?

Regards
Greg


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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-07-29  6:41 GPMI iMX6ull timeout on DMA Greg Ungerer
@ 2019-07-29  8:36 ` Miquel Raynal
  2019-07-29  8:42   ` Michael Nazzareno Trimarchi
  2019-07-29 12:33   ` Greg Ungerer
  2021-10-04  5:54 ` Christian Eggers
  1 sibling, 2 replies; 85+ messages in thread
From: Miquel Raynal @ 2019-07-29  8:36 UTC (permalink / raw)
  To: Greg Ungerer; +Cc: s.hauer, Michael Nazzareno Trimarchi, linux-mtd

Hi Greg,

One question below.

+Michael
+Sascha

Hello Michael, here is a similar issue to yours, I know you did not
have enough time to share your solution but here we have someone else
reproducing the issue, would you mind sharing a branch or a patch, even
a WIP one, just to help debugging?

Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:

> Hi Miquel,
> 
> I am experiencing a problem with NAND flash DMA timeouts on
> iMX6ull based boards. The problem is very similar to that
> described in:
> 
>    https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
> 
> That didn't come to any specific resolution that I could see
> in that thread.
> 
> The boot trace on the console for me looks like this:
> 
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron MT29F2G08ABAEAWP
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> GF length              : 13
> ECC Strength           : 8
> Page Size in Bytes     : 2110
> Metadata Size in Bytes : 10
> ECC Chunk0 Size in Bytes: 512
> ECC Chunkn Size in Bytes: 512
> ECC Chunk Count        : 4
> Payload Size in Bytes  : 2048
> Auxiliary Size in Bytes: 16
> Auxiliary Status Offset: 12
> Block Mark Byte Offset : 1999
> Block Mark Bit Offset  : 0
> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> nand: timing mode 5 not acknowledged by the NAND chip

What is the final timing mode used? Most of us tested in mode 5 I
guess, maybe mode 4 is broken (don't know if this is the one used here,
neither why mode 5 is refused). Can you please try by limiting the mode
to 0, 1, 2... until, hopefully, we narrow down to the failing mode.

> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> Scanning device for bad blocks
> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> ....
> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> 5 fixed-partitions partitions found on MTD device gpmi-nand
> Creating 5 MTD partitions on "gpmi-nand":
> 0x000000000000-0x000000500000 : "u-boot"
> 0x000000500000-0x000000600000 : "u-boot-env"
> 0x000000600000-0x000000800000 : "log"
> 0x000000800000-0x000010000000 : "flash"
> 0x000000000000-0x000010000000 : "all"
> gpmi-nand 1806000.gpmi-nand: driver registered.
> 
> 
> This is using a linux kernel v5.1.14. I have seen this happen on
> a number of boards I have here - but it is only occasional. It
> only happens once in a while on boot, maybe 1 in 40 or more times.
> So it can take quite a while to reproduce (using a boot loop setup).

That's strange... I don't get what would produce such unstable issue.

> 
> As per the email thread I pointed to above I looked at reverting
> those patches, but that was not at all easy given how much the gpmi
> driver code had moved. So instead I modified the code with this:
> 
> --- a/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> +++ b/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> @@ -481,6 +481,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
>     void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>   {
> +#if 0
>          struct gpmi_nfc_hardware_timing *hw = &this->hw;
>          struct resources *r = &this->resources;
>          void __iomem *gpmi_regs = r->gpmi_regs;
> @@ -505,6 +512,7 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>            /* Wait for the DLL to settle. */
>          udelay(dll_wait_time_us);
> +#endif
>   }
>     int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
> 
> So far after a couple of days of testing with this I no longer
> see the DMA timeout.
> 
> Any thoughts?
> 
> Regards
> Greg
> 

Thanks,
Miquèl

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-07-29  8:36 ` Miquel Raynal
@ 2019-07-29  8:42   ` Michael Nazzareno Trimarchi
  2019-07-29 12:18     ` Greg Ungerer
  2019-07-29 12:33   ` Greg Ungerer
  1 sibling, 1 reply; 85+ messages in thread
From: Michael Nazzareno Trimarchi @ 2019-07-29  8:42 UTC (permalink / raw)
  To: Miquel Raynal; +Cc: s.hauer, Greg Ungerer, linux-mtd

Hi all

On Mon, Jul 29, 2019 at 10:36 AM Miquel Raynal
<miquel.raynal@bootlin.com> wrote:
>
> Hi Greg,
>
> One question below.
>
> +Michael
> +Sascha
>
> Hello Michael, here is a similar issue to yours, I know you did not
> have enough time to share your solution but here we have someone else
> reproducing the issue, would you mind sharing a branch or a patch, even
> a WIP one, just to help debugging?
>

I have patches reverted as I mention in the email. The step to
reproduce is simple.

Just reboot every successful boot.

Michael

> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>
> > Hi Miquel,
> >
> > I am experiencing a problem with NAND flash DMA timeouts on
> > iMX6ull based boards. The problem is very similar to that
> > described in:
> >
> >    https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
> >
> > That didn't come to any specific resolution that I could see
> > in that thread.
> >
> > The boot trace on the console for me looks like this:
> >
> > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> > nand: Micron MT29F2G08ABAEAWP
> > nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> > gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> > gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> > gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> > gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> > gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> > gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> > gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> > gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
> > gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> > gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> > gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> > gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> > gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> > gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> > gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> > GF length              : 13
> > ECC Strength           : 8
> > Page Size in Bytes     : 2110
> > Metadata Size in Bytes : 10
> > ECC Chunk0 Size in Bytes: 512
> > ECC Chunkn Size in Bytes: 512
> > ECC Chunk Count        : 4
> > Payload Size in Bytes  : 2048
> > Auxiliary Size in Bytes: 16
> > Auxiliary Status Offset: 12
> > Block Mark Byte Offset : 1999
> > Block Mark Bit Offset  : 0
> > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> > nand: timing mode 5 not acknowledged by the NAND chip
>
> What is the final timing mode used? Most of us tested in mode 5 I
> guess, maybe mode 4 is broken (don't know if this is the one used here,
> neither why mode 5 is refused). Can you please try by limiting the mode
> to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
>
> > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > Scanning device for bad blocks
> > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > ....
> > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > 5 fixed-partitions partitions found on MTD device gpmi-nand
> > Creating 5 MTD partitions on "gpmi-nand":
> > 0x000000000000-0x000000500000 : "u-boot"
> > 0x000000500000-0x000000600000 : "u-boot-env"
> > 0x000000600000-0x000000800000 : "log"
> > 0x000000800000-0x000010000000 : "flash"
> > 0x000000000000-0x000010000000 : "all"
> > gpmi-nand 1806000.gpmi-nand: driver registered.
> >
> >
> > This is using a linux kernel v5.1.14. I have seen this happen on
> > a number of boards I have here - but it is only occasional. It
> > only happens once in a while on boot, maybe 1 in 40 or more times.
> > So it can take quite a while to reproduce (using a boot loop setup).
>
> That's strange... I don't get what would produce such unstable issue.
>
> >
> > As per the email thread I pointed to above I looked at reverting
> > those patches, but that was not at all easy given how much the gpmi
> > driver code had moved. So instead I modified the code with this:
> >
> > --- a/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > +++ b/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > @@ -481,6 +481,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
> >     void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >   {
> > +#if 0
> >          struct gpmi_nfc_hardware_timing *hw = &this->hw;
> >          struct resources *r = &this->resources;
> >          void __iomem *gpmi_regs = r->gpmi_regs;
> > @@ -505,6 +512,7 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >            /* Wait for the DLL to settle. */
> >          udelay(dll_wait_time_us);
> > +#endif
> >   }
> >     int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
> >
> > So far after a couple of days of testing with this I no longer
> > see the DMA timeout.
> >
> > Any thoughts?
> >
> > Regards
> > Greg
> >
>
> Thanks,
> Miquèl



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-07-29  8:42   ` Michael Nazzareno Trimarchi
@ 2019-07-29 12:18     ` Greg Ungerer
  2019-07-29 12:20       ` Michael Nazzareno Trimarchi
  0 siblings, 1 reply; 85+ messages in thread
From: Greg Ungerer @ 2019-07-29 12:18 UTC (permalink / raw)
  To: Michael Nazzareno Trimarchi, Miquel Raynal; +Cc: s.hauer, linux-mtd

Hi Michael,

On 29/7/19 6:42 pm, Michael Nazzareno Trimarchi wrote:
> Hi all
> 
> On Mon, Jul 29, 2019 at 10:36 AM Miquel Raynal
> <miquel.raynal@bootlin.com> wrote:
>>
>> Hi Greg,
>>
>> One question below.
>>
>> +Michael
>> +Sascha
>>
>> Hello Michael, here is a similar issue to yours, I know you did not
>> have enough time to share your solution but here we have someone else
>> reproducing the issue, would you mind sharing a branch or a patch, even
>> a WIP one, just to help debugging?
>>
> 
> I have patches reverted as I mention in the email. The step to
> reproduce is simple.
> 
> Just reboot every successful boot.

Testing like this how often does it occur?

Regards
Greg


> Michael
> 
>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>
>>> Hi Miquel,
>>>
>>> I am experiencing a problem with NAND flash DMA timeouts on
>>> iMX6ull based boards. The problem is very similar to that
>>> described in:
>>>
>>>     https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
>>>
>>> That didn't come to any specific resolution that I could see
>>> in that thread.
>>>
>>> The boot trace on the console for me looks like this:
>>>
>>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>>> nand: Micron MT29F2G08ABAEAWP
>>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>>> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
>>> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
>>> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
>>> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
>>> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
>>> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
>>> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
>>> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
>>> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
>>> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
>>> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
>>> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
>>> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
>>> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
>>> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
>>> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
>>> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
>>> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
>>> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
>>> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
>>> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
>>> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
>>> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
>>> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
>>> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
>>> GF length              : 13
>>> ECC Strength           : 8
>>> Page Size in Bytes     : 2110
>>> Metadata Size in Bytes : 10
>>> ECC Chunk0 Size in Bytes: 512
>>> ECC Chunkn Size in Bytes: 512
>>> ECC Chunk Count        : 4
>>> Payload Size in Bytes  : 2048
>>> Auxiliary Size in Bytes: 16
>>> Auxiliary Status Offset: 12
>>> Block Mark Byte Offset : 1999
>>> Block Mark Bit Offset  : 0
>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
>>> nand: timing mode 5 not acknowledged by the NAND chip
>>
>> What is the final timing mode used? Most of us tested in mode 5 I
>> guess, maybe mode 4 is broken (don't know if this is the one used here,
>> neither why mode 5 is refused). Can you please try by limiting the mode
>> to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
>>
>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>> Scanning device for bad blocks
>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>> ....
>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>> 5 fixed-partitions partitions found on MTD device gpmi-nand
>>> Creating 5 MTD partitions on "gpmi-nand":
>>> 0x000000000000-0x000000500000 : "u-boot"
>>> 0x000000500000-0x000000600000 : "u-boot-env"
>>> 0x000000600000-0x000000800000 : "log"
>>> 0x000000800000-0x000010000000 : "flash"
>>> 0x000000000000-0x000010000000 : "all"
>>> gpmi-nand 1806000.gpmi-nand: driver registered.
>>>
>>>
>>> This is using a linux kernel v5.1.14. I have seen this happen on
>>> a number of boards I have here - but it is only occasional. It
>>> only happens once in a while on boot, maybe 1 in 40 or more times.
>>> So it can take quite a while to reproduce (using a boot loop setup).
>>
>> That's strange... I don't get what would produce such unstable issue.
>>
>>>
>>> As per the email thread I pointed to above I looked at reverting
>>> those patches, but that was not at all easy given how much the gpmi
>>> driver code had moved. So instead I modified the code with this:
>>>
>>> --- a/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
>>> +++ b/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
>>> @@ -481,6 +481,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
>>>      void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>>    {
>>> +#if 0
>>>           struct gpmi_nfc_hardware_timing *hw = &this->hw;
>>>           struct resources *r = &this->resources;
>>>           void __iomem *gpmi_regs = r->gpmi_regs;
>>> @@ -505,6 +512,7 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>>             /* Wait for the DLL to settle. */
>>>           udelay(dll_wait_time_us);
>>> +#endif
>>>    }
>>>      int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
>>>
>>> So far after a couple of days of testing with this I no longer
>>> see the DMA timeout.
>>>
>>> Any thoughts?
>>>
>>> Regards
>>> Greg
>>>
>>
>> Thanks,
>> Miquèl
> 
> 
> 

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-07-29 12:18     ` Greg Ungerer
@ 2019-07-29 12:20       ` Michael Nazzareno Trimarchi
  0 siblings, 0 replies; 85+ messages in thread
From: Michael Nazzareno Trimarchi @ 2019-07-29 12:20 UTC (permalink / raw)
  To: Greg Ungerer; +Cc: s.hauer, linux-mtd, Miquel Raynal

Hi

On Mon, Jul 29, 2019 at 2:19 PM Greg Ungerer <gerg@kernel.org> wrote:
>
> Hi Michael,
>
> On 29/7/19 6:42 pm, Michael Nazzareno Trimarchi wrote:
> > Hi all
> >
> > On Mon, Jul 29, 2019 at 10:36 AM Miquel Raynal
> > <miquel.raynal@bootlin.com> wrote:
> >>
> >> Hi Greg,
> >>
> >> One question below.
> >>
> >> +Michael
> >> +Sascha
> >>
> >> Hello Michael, here is a similar issue to yours, I know you did not
> >> have enough time to share your solution but here we have someone else
> >> reproducing the issue, would you mind sharing a branch or a patch, even
> >> a WIP one, just to help debugging?
> >>
> >
> > I have patches reverted as I mention in the email. The step to
> > reproduce is simple.
> >
> > Just reboot every successful boot.
>
> Testing like this how often does it occur?
>

Not more then 60 reboot ;). The problem is how is done the code the
system can not rebooting without an hardware watchdog

MIchael

> Regards
> Greg
>
>
> > Michael
> >
> >> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> >>
> >>> Hi Miquel,
> >>>
> >>> I am experiencing a problem with NAND flash DMA timeouts on
> >>> iMX6ull based boards. The problem is very similar to that
> >>> described in:
> >>>
> >>>     https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
> >>>
> >>> That didn't come to any specific resolution that I could see
> >>> in that thread.
> >>>
> >>> The boot trace on the console for me looks like this:
> >>>
> >>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> >>> nand: Micron MT29F2G08ABAEAWP
> >>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> >>> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> >>> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> >>> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> >>> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> >>> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> >>> GF length              : 13
> >>> ECC Strength           : 8
> >>> Page Size in Bytes     : 2110
> >>> Metadata Size in Bytes : 10
> >>> ECC Chunk0 Size in Bytes: 512
> >>> ECC Chunkn Size in Bytes: 512
> >>> ECC Chunk Count        : 4
> >>> Payload Size in Bytes  : 2048
> >>> Auxiliary Size in Bytes: 16
> >>> Auxiliary Status Offset: 12
> >>> Block Mark Byte Offset : 1999
> >>> Block Mark Bit Offset  : 0
> >>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> >>> nand: timing mode 5 not acknowledged by the NAND chip
> >>
> >> What is the final timing mode used? Most of us tested in mode 5 I
> >> guess, maybe mode 4 is broken (don't know if this is the one used here,
> >> neither why mode 5 is refused). Can you please try by limiting the mode
> >> to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
> >>
> >>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >>> Scanning device for bad blocks
> >>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >>> ....
> >>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >>> 5 fixed-partitions partitions found on MTD device gpmi-nand
> >>> Creating 5 MTD partitions on "gpmi-nand":
> >>> 0x000000000000-0x000000500000 : "u-boot"
> >>> 0x000000500000-0x000000600000 : "u-boot-env"
> >>> 0x000000600000-0x000000800000 : "log"
> >>> 0x000000800000-0x000010000000 : "flash"
> >>> 0x000000000000-0x000010000000 : "all"
> >>> gpmi-nand 1806000.gpmi-nand: driver registered.
> >>>
> >>>
> >>> This is using a linux kernel v5.1.14. I have seen this happen on
> >>> a number of boards I have here - but it is only occasional. It
> >>> only happens once in a while on boot, maybe 1 in 40 or more times.
> >>> So it can take quite a while to reproduce (using a boot loop setup).
> >>
> >> That's strange... I don't get what would produce such unstable issue.
> >>
> >>>
> >>> As per the email thread I pointed to above I looked at reverting
> >>> those patches, but that was not at all easy given how much the gpmi
> >>> driver code had moved. So instead I modified the code with this:
> >>>
> >>> --- a/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> >>> +++ b/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> >>> @@ -481,6 +481,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
> >>>      void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >>>    {
> >>> +#if 0
> >>>           struct gpmi_nfc_hardware_timing *hw = &this->hw;
> >>>           struct resources *r = &this->resources;
> >>>           void __iomem *gpmi_regs = r->gpmi_regs;
> >>> @@ -505,6 +512,7 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >>>             /* Wait for the DLL to settle. */
> >>>           udelay(dll_wait_time_us);
> >>> +#endif
> >>>    }
> >>>      int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
> >>>
> >>> So far after a couple of days of testing with this I no longer
> >>> see the DMA timeout.
> >>>
> >>> Any thoughts?
> >>>
> >>> Regards
> >>> Greg
> >>>
> >>
> >> Thanks,
> >> Miquèl
> >
> >
> >



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-07-29  8:36 ` Miquel Raynal
  2019-07-29  8:42   ` Michael Nazzareno Trimarchi
@ 2019-07-29 12:33   ` Greg Ungerer
  2019-07-29 12:47     ` Miquel Raynal
  1 sibling, 1 reply; 85+ messages in thread
From: Greg Ungerer @ 2019-07-29 12:33 UTC (permalink / raw)
  To: Miquel Raynal; +Cc: s.hauer, Michael Nazzareno Trimarchi, linux-mtd

Hi Miquel,

On 29/7/19 6:36 pm, Miquel Raynal wrote:
> Hi Greg,
> 
> One question below.
> 
> +Michael
> +Sascha
> 
> Hello Michael, here is a similar issue to yours, I know you did not
> have enough time to share your solution but here we have someone else
> reproducing the issue, would you mind sharing a branch or a patch, even
> a WIP one, just to help debugging?
> 
> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> 
>> Hi Miquel,
>>
>> I am experiencing a problem with NAND flash DMA timeouts on
>> iMX6ull based boards. The problem is very similar to that
>> described in:
>>
>>     https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
>>
>> That didn't come to any specific resolution that I could see
>> in that thread.
>>
>> The boot trace on the console for me looks like this:
>>
>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>> nand: Micron MT29F2G08ABAEAWP
>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
>> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
>> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
>> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
>> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
>> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
>> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
>> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
>> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
>> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
>> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
>> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
>> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
>> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
>> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
>> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
>> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
>> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
>> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
>> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
>> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
>> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
>> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
>> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
>> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
>> GF length              : 13
>> ECC Strength           : 8
>> Page Size in Bytes     : 2110
>> Metadata Size in Bytes : 10
>> ECC Chunk0 Size in Bytes: 512
>> ECC Chunkn Size in Bytes: 512
>> ECC Chunk Count        : 4
>> Payload Size in Bytes  : 2048
>> Auxiliary Size in Bytes: 16
>> Auxiliary Status Offset: 12
>> Block Mark Byte Offset : 1999
>> Block Mark Bit Offset  : 0
>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
>> nand: timing mode 5 not acknowledged by the NAND chip
> 
> What is the final timing mode used? Most of us tested in mode 5 I
> guess, maybe mode 4 is broken (don't know if this is the one used here,
> neither why mode 5 is refused). Can you please try by limiting the mode
> to 0, 1, 2... until, hopefully, we narrow down to the failing mode.

Sure, how to do that?


>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>> Scanning device for bad blocks
>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>> ....
>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>> 5 fixed-partitions partitions found on MTD device gpmi-nand
>> Creating 5 MTD partitions on "gpmi-nand":
>> 0x000000000000-0x000000500000 : "u-boot"
>> 0x000000500000-0x000000600000 : "u-boot-env"
>> 0x000000600000-0x000000800000 : "log"
>> 0x000000800000-0x000010000000 : "flash"
>> 0x000000000000-0x000010000000 : "all"
>> gpmi-nand 1806000.gpmi-nand: driver registered.
>>
>>
>> This is using a linux kernel v5.1.14. I have seen this happen on
>> a number of boards I have here - but it is only occasional. It
>> only happens once in a while on boot, maybe 1 in 40 or more times.
>> So it can take quite a while to reproduce (using a boot loop setup).
> 
> That's strange... I don't get what would produce such unstable issue.

My initial guess is that the calculated timing is very marginal.
The problem seems more likely to happen if flash write activity
had been occurring just before a soft reboot. Its not a guarantee,
just more likely.

Interesting observation is that Michael was using Micron flash,
and boards that I have with the problem also have Micron flash.
Both a form of Micron MT29F2G08.

I have similar boards, iMX6ull based, with different brands of
NAND flash and I have not seen any problem on them.

Regards
Greg



>> As per the email thread I pointed to above I looked at reverting
>> those patches, but that was not at all easy given how much the gpmi
>> driver code had moved. So instead I modified the code with this:
>>
>> --- a/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
>> +++ b/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
>> @@ -481,6 +481,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
>>      void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>    {
>> +#if 0
>>           struct gpmi_nfc_hardware_timing *hw = &this->hw;
>>           struct resources *r = &this->resources;
>>           void __iomem *gpmi_regs = r->gpmi_regs;
>> @@ -505,6 +512,7 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>             /* Wait for the DLL to settle. */
>>           udelay(dll_wait_time_us);
>> +#endif
>>    }
>>      int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
>>
>> So far after a couple of days of testing with this I no longer
>> see the DMA timeout.
>>
>> Any thoughts?
>>
>> Regards
>> Greg
>>
> 
> Thanks,
> Miquèl
> 

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-07-29 12:33   ` Greg Ungerer
@ 2019-07-29 12:47     ` Miquel Raynal
  2019-07-29 12:49       ` Michael Nazzareno Trimarchi
  2019-07-30  0:28       ` Greg Ungerer
  0 siblings, 2 replies; 85+ messages in thread
From: Miquel Raynal @ 2019-07-29 12:47 UTC (permalink / raw)
  To: Greg Ungerer
  Cc: s.hauer, Michael Nazzareno Trimarchi, linux-mtd, Boris Brezillon

Hi Greg,

+ Boris

Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:

> Hi Miquel,
> 
> On 29/7/19 6:36 pm, Miquel Raynal wrote:
> > Hi Greg,
> > 
> > One question below.
> > 
> > +Michael
> > +Sascha
> > 
> > Hello Michael, here is a similar issue to yours, I know you did not
> > have enough time to share your solution but here we have someone else
> > reproducing the issue, would you mind sharing a branch or a patch, even
> > a WIP one, just to help debugging?
> > 
> > Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> >   
> >> Hi Miquel,
> >>
> >> I am experiencing a problem with NAND flash DMA timeouts on
> >> iMX6ull based boards. The problem is very similar to that
> >> described in:
> >>
> >>     https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
> >>
> >> That didn't come to any specific resolution that I could see
> >> in that thread.
> >>
> >> The boot trace on the console for me looks like this:
> >>
> >> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> >> nand: Micron MT29F2G08ABAEAWP
> >> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> >> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> >> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
> >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> >> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> >> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> >> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> >> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> >> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> >> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> >> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> >> GF length              : 13
> >> ECC Strength           : 8
> >> Page Size in Bytes     : 2110
> >> Metadata Size in Bytes : 10
> >> ECC Chunk0 Size in Bytes: 512
> >> ECC Chunkn Size in Bytes: 512
> >> ECC Chunk Count        : 4
> >> Payload Size in Bytes  : 2048
> >> Auxiliary Size in Bytes: 16
> >> Auxiliary Status Offset: 12
> >> Block Mark Byte Offset : 1999
> >> Block Mark Bit Offset  : 0
> >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> >> nand: timing mode 5 not acknowledged by the NAND chip  
> > 
> > What is the final timing mode used? Most of us tested in mode 5 I
> > guess, maybe mode 4 is broken (don't know if this is the one used here,
> > neither why mode 5 is refused). Can you please try by limiting the mode
> > to 0, 1, 2... until, hopefully, we narrow down to the failing mode.  
> 
> Sure, how to do that?

This loop [1] tries to configure each mode (5, 4, ...) until one
succeeds (default is 0: must always work). Please try to limit mode to
0, 1, etc.

Mode 0 should work.

[1] https://elixir.bootlin.com/linux/v5.3-rc1/source/drivers/mtd/nand/raw/nand_base.c#L933

> 
> 
> >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >> Scanning device for bad blocks
> >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >> ....
> >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> >> 5 fixed-partitions partitions found on MTD device gpmi-nand
> >> Creating 5 MTD partitions on "gpmi-nand":
> >> 0x000000000000-0x000000500000 : "u-boot"
> >> 0x000000500000-0x000000600000 : "u-boot-env"
> >> 0x000000600000-0x000000800000 : "log"
> >> 0x000000800000-0x000010000000 : "flash"
> >> 0x000000000000-0x000010000000 : "all"
> >> gpmi-nand 1806000.gpmi-nand: driver registered.
> >>
> >>
> >> This is using a linux kernel v5.1.14. I have seen this happen on
> >> a number of boards I have here - but it is only occasional. It
> >> only happens once in a while on boot, maybe 1 in 40 or more times.
> >> So it can take quite a while to reproduce (using a boot loop setup).  
> > 
> > That's strange... I don't get what would produce such unstable issue.  
> 
> My initial guess is that the calculated timing is very marginal.

What do you mean by "marginal"?

> The problem seems more likely to happen if flash write activity
> had been occurring just before a soft reboot. Its not a guarantee,
> just more likely.

That's really disturbing. I doubt this is the real cause though.

> 
> Interesting observation is that Michael was using Micron flash,
> and boards that I have with the problem also have Micron flash.
> Both a form of Micron MT29F2G08.
> 
> I have similar boards, iMX6ull based, with different brands of
> NAND flash and I have not seen any problem on them.

That's great to narrow down the root cause. Maybe these chips have
tighter timing constraints.

> 
> Regards
> Greg
> 
> 
> 
> >> As per the email thread I pointed to above I looked at reverting
> >> those patches, but that was not at all easy given how much the gpmi
> >> driver code had moved. So instead I modified the code with this:
> >>
> >> --- a/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> >> +++ b/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> >> @@ -481,6 +481,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
> >>      void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >>    {
> >> +#if 0
> >>           struct gpmi_nfc_hardware_timing *hw = &this->hw;
> >>           struct resources *r = &this->resources;
> >>           void __iomem *gpmi_regs = r->gpmi_regs;
> >> @@ -505,6 +512,7 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >>             /* Wait for the DLL to settle. */
> >>           udelay(dll_wait_time_us);
> >> +#endif
> >>    }
> >>      int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
> >>
> >> So far after a couple of days of testing with this I no longer
> >> see the DMA timeout.
> >>
> >> Any thoughts?
> >>
> >> Regards
> >> Greg
> >>  
> > 
> > Thanks,
> > Miquèl
> >   

Thanks,
Miquèl

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-07-29 12:47     ` Miquel Raynal
@ 2019-07-29 12:49       ` Michael Nazzareno Trimarchi
  2019-07-29 12:55         ` Miquel Raynal
  2019-07-30  0:28       ` Greg Ungerer
  1 sibling, 1 reply; 85+ messages in thread
From: Michael Nazzareno Trimarchi @ 2019-07-29 12:49 UTC (permalink / raw)
  To: Miquel Raynal; +Cc: s.hauer, Greg Ungerer, linux-mtd, Boris Brezillon

Hi Miguel

On Mon, Jul 29, 2019 at 2:47 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Greg,
>
> + Boris
>
> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>
> > Hi Miquel,
> >
> > On 29/7/19 6:36 pm, Miquel Raynal wrote:
> > > Hi Greg,
> > >
> > > One question below.
> > >
> > > +Michael
> > > +Sascha
> > >
> > > Hello Michael, here is a similar issue to yours, I know you did not
> > > have enough time to share your solution but here we have someone else
> > > reproducing the issue, would you mind sharing a branch or a patch, even
> > > a WIP one, just to help debugging?
> > >
> > > Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> > >
> > >> Hi Miquel,
> > >>
> > >> I am experiencing a problem with NAND flash DMA timeouts on
> > >> iMX6ull based boards. The problem is very similar to that
> > >> described in:
> > >>
> > >>     https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
> > >>
> > >> That didn't come to any specific resolution that I could see
> > >> in that thread.
> > >>
> > >> The boot trace on the console for me looks like this:
> > >>
> > >> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> > >> nand: Micron MT29F2G08ABAEAWP
> > >> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > >> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> > >> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> > >> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> > >> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> > >> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> > >> GF length              : 13
> > >> ECC Strength           : 8
> > >> Page Size in Bytes     : 2110
> > >> Metadata Size in Bytes : 10
> > >> ECC Chunk0 Size in Bytes: 512
> > >> ECC Chunkn Size in Bytes: 512
> > >> ECC Chunk Count        : 4
> > >> Payload Size in Bytes  : 2048
> > >> Auxiliary Size in Bytes: 16
> > >> Auxiliary Status Offset: 12
> > >> Block Mark Byte Offset : 1999
> > >> Block Mark Bit Offset  : 0
> > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> > >> nand: timing mode 5 not acknowledged by the NAND chip
> > >
> > > What is the final timing mode used? Most of us tested in mode 5 I
> > > guess, maybe mode 4 is broken (don't know if this is the one used here,
> > > neither why mode 5 is refused). Can you please try by limiting the mode
> > > to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
> >
> > Sure, how to do that?
>
> This loop [1] tries to configure each mode (5, 4, ...) until one
> succeeds (default is 0: must always work). Please try to limit mode to
> 0, 1, etc.
>
> Mode 0 should work.
>

This is not correct. When all the mode fail it fallback to 0 that does
not work. Already check
So the fallback is created for this situation

> [1] https://elixir.bootlin.com/linux/v5.3-rc1/source/drivers/mtd/nand/raw/nand_base.c#L933
>
> >
> >
> > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > >> Scanning device for bad blocks
> > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > >> ....
> > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > >> 5 fixed-partitions partitions found on MTD device gpmi-nand
> > >> Creating 5 MTD partitions on "gpmi-nand":
> > >> 0x000000000000-0x000000500000 : "u-boot"
> > >> 0x000000500000-0x000000600000 : "u-boot-env"
> > >> 0x000000600000-0x000000800000 : "log"
> > >> 0x000000800000-0x000010000000 : "flash"
> > >> 0x000000000000-0x000010000000 : "all"
> > >> gpmi-nand 1806000.gpmi-nand: driver registered.
> > >>
> > >>
> > >> This is using a linux kernel v5.1.14. I have seen this happen on
> > >> a number of boards I have here - but it is only occasional. It
> > >> only happens once in a while on boot, maybe 1 in 40 or more times.
> > >> So it can take quite a while to reproduce (using a boot loop setup).
> > >
> > > That's strange... I don't get what would produce such unstable issue.
> >
> > My initial guess is that the calculated timing is very marginal.
>
> What do you mean by "marginal"?
>

I don't think that is timing calculation. I have tried to use the same timing
as before but when those are applide. Is it possible?

Michael

> > The problem seems more likely to happen if flash write activity
> > had been occurring just before a soft reboot. Its not a guarantee,
> > just more likely.
>
> That's really disturbing. I doubt this is the real cause though.
>
> >
> > Interesting observation is that Michael was using Micron flash,
> > and boards that I have with the problem also have Micron flash.
> > Both a form of Micron MT29F2G08.
> >
> > I have similar boards, iMX6ull based, with different brands of
> > NAND flash and I have not seen any problem on them.
>
> That's great to narrow down the root cause. Maybe these chips have
> tighter timing constraints.
>
> >
> > Regards
> > Greg
> >
> >
> >
> > >> As per the email thread I pointed to above I looked at reverting
> > >> those patches, but that was not at all easy given how much the gpmi
> > >> driver code had moved. So instead I modified the code with this:
> > >>
> > >> --- a/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > >> +++ b/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > >> @@ -481,6 +481,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
> > >>      void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > >>    {
> > >> +#if 0
> > >>           struct gpmi_nfc_hardware_timing *hw = &this->hw;
> > >>           struct resources *r = &this->resources;
> > >>           void __iomem *gpmi_regs = r->gpmi_regs;
> > >> @@ -505,6 +512,7 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > >>             /* Wait for the DLL to settle. */
> > >>           udelay(dll_wait_time_us);
> > >> +#endif
> > >>    }
> > >>      int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
> > >>
> > >> So far after a couple of days of testing with this I no longer
> > >> see the DMA timeout.
> > >>
> > >> Any thoughts?
> > >>
> > >> Regards
> > >> Greg
> > >>
> > >
> > > Thanks,
> > > Miquèl
> > >
>
> Thanks,
> Miquèl



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-07-29 12:49       ` Michael Nazzareno Trimarchi
@ 2019-07-29 12:55         ` Miquel Raynal
  2019-07-29 13:00           ` Michael Nazzareno Trimarchi
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel Raynal @ 2019-07-29 12:55 UTC (permalink / raw)
  To: Michael Nazzareno Trimarchi
  Cc: s.hauer, Greg Ungerer, linux-mtd, Boris Brezillon

Hi Michael,

Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
Mon, 29 Jul 2019 14:49:19 +0200:

> Hi Miguel
> 
> On Mon, Jul 29, 2019 at 2:47 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Greg,
> >
> > + Boris
> >
> > Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
> >  
> > > Hi Miquel,
> > >
> > > On 29/7/19 6:36 pm, Miquel Raynal wrote:  
> > > > Hi Greg,
> > > >
> > > > One question below.
> > > >
> > > > +Michael
> > > > +Sascha
> > > >
> > > > Hello Michael, here is a similar issue to yours, I know you did not
> > > > have enough time to share your solution but here we have someone else
> > > > reproducing the issue, would you mind sharing a branch or a patch, even
> > > > a WIP one, just to help debugging?
> > > >
> > > > Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> > > >  
> > > >> Hi Miquel,
> > > >>
> > > >> I am experiencing a problem with NAND flash DMA timeouts on
> > > >> iMX6ull based boards. The problem is very similar to that
> > > >> described in:
> > > >>
> > > >>     https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
> > > >>
> > > >> That didn't come to any specific resolution that I could see
> > > >> in that thread.
> > > >>
> > > >> The boot trace on the console for me looks like this:
> > > >>
> > > >> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> > > >> nand: Micron MT29F2G08ABAEAWP
> > > >> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > >> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> > > >> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> > > >> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> > > >> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> > > >> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> > > >> GF length              : 13
> > > >> ECC Strength           : 8
> > > >> Page Size in Bytes     : 2110
> > > >> Metadata Size in Bytes : 10
> > > >> ECC Chunk0 Size in Bytes: 512
> > > >> ECC Chunkn Size in Bytes: 512
> > > >> ECC Chunk Count        : 4
> > > >> Payload Size in Bytes  : 2048
> > > >> Auxiliary Size in Bytes: 16
> > > >> Auxiliary Status Offset: 12
> > > >> Block Mark Byte Offset : 1999
> > > >> Block Mark Bit Offset  : 0
> > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> > > >> nand: timing mode 5 not acknowledged by the NAND chip  
> > > >
> > > > What is the final timing mode used? Most of us tested in mode 5 I
> > > > guess, maybe mode 4 is broken (don't know if this is the one used here,
> > > > neither why mode 5 is refused). Can you please try by limiting the mode
> > > > to 0, 1, 2... until, hopefully, we narrow down to the failing mode.  
> > >
> > > Sure, how to do that?  
> >
> > This loop [1] tries to configure each mode (5, 4, ...) until one
> > succeeds (default is 0: must always work). Please try to limit mode to
> > 0, 1, etc.
> >
> > Mode 0 should work.
> >  
> 
> This is not correct. When all the mode fail it fallback to 0 that does
> not work. Already check
> So the fallback is created for this situation

Sorry but I don't understand what you are saying.

Are you telling me that you already tried mode 0 and that it did not
work better than other timings?

> 
> > [1] https://elixir.bootlin.com/linux/v5.3-rc1/source/drivers/mtd/nand/raw/nand_base.c#L933
> >  
> > >
> > >  
> > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > >> Scanning device for bad blocks
> > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > >> ....
> > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > >> 5 fixed-partitions partitions found on MTD device gpmi-nand
> > > >> Creating 5 MTD partitions on "gpmi-nand":
> > > >> 0x000000000000-0x000000500000 : "u-boot"
> > > >> 0x000000500000-0x000000600000 : "u-boot-env"
> > > >> 0x000000600000-0x000000800000 : "log"
> > > >> 0x000000800000-0x000010000000 : "flash"
> > > >> 0x000000000000-0x000010000000 : "all"
> > > >> gpmi-nand 1806000.gpmi-nand: driver registered.
> > > >>
> > > >>
> > > >> This is using a linux kernel v5.1.14. I have seen this happen on
> > > >> a number of boards I have here - but it is only occasional. It
> > > >> only happens once in a while on boot, maybe 1 in 40 or more times.
> > > >> So it can take quite a while to reproduce (using a boot loop setup).  
> > > >
> > > > That's strange... I don't get what would produce such unstable issue.  
> > >
> > > My initial guess is that the calculated timing is very marginal.  
> >
> > What do you mean by "marginal"?
> >  
> 
> I don't think that is timing calculation. I have tried to use the same timing
> as before but when those are applide. Is it possible?

                                      ^
I suppose the end of the sentence is missing?


Thanks,
Miquèl

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-07-29 12:55         ` Miquel Raynal
@ 2019-07-29 13:00           ` Michael Nazzareno Trimarchi
  2019-07-29 13:22             ` Miquel Raynal
  0 siblings, 1 reply; 85+ messages in thread
From: Michael Nazzareno Trimarchi @ 2019-07-29 13:00 UTC (permalink / raw)
  To: Miquel Raynal; +Cc: s.hauer, Greg Ungerer, linux-mtd, Boris Brezillon

Hi Miquel

On Mon, Jul 29, 2019 at 2:55 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Michael,
>
> Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> Mon, 29 Jul 2019 14:49:19 +0200:
>
> > Hi Miguel
> >
> > On Mon, Jul 29, 2019 at 2:47 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > Hi Greg,
> > >
> > > + Boris
> > >
> > > Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
> > >
> > > > Hi Miquel,
> > > >
> > > > On 29/7/19 6:36 pm, Miquel Raynal wrote:
> > > > > Hi Greg,
> > > > >
> > > > > One question below.
> > > > >
> > > > > +Michael
> > > > > +Sascha
> > > > >
> > > > > Hello Michael, here is a similar issue to yours, I know you did not
> > > > > have enough time to share your solution but here we have someone else
> > > > > reproducing the issue, would you mind sharing a branch or a patch, even
> > > > > a WIP one, just to help debugging?
> > > > >
> > > > > Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> > > > >
> > > > >> Hi Miquel,
> > > > >>
> > > > >> I am experiencing a problem with NAND flash DMA timeouts on
> > > > >> iMX6ull based boards. The problem is very similar to that
> > > > >> described in:
> > > > >>
> > > > >>     https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
> > > > >>
> > > > >> That didn't come to any specific resolution that I could see
> > > > >> in that thread.
> > > > >>
> > > > >> The boot trace on the console for me looks like this:
> > > > >>
> > > > >> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> > > > >> nand: Micron MT29F2G08ABAEAWP
> > > > >> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > > >> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> > > > >> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> > > > >> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> > > > >> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> > > > >> GF length              : 13
> > > > >> ECC Strength           : 8
> > > > >> Page Size in Bytes     : 2110
> > > > >> Metadata Size in Bytes : 10
> > > > >> ECC Chunk0 Size in Bytes: 512
> > > > >> ECC Chunkn Size in Bytes: 512
> > > > >> ECC Chunk Count        : 4
> > > > >> Payload Size in Bytes  : 2048
> > > > >> Auxiliary Size in Bytes: 16
> > > > >> Auxiliary Status Offset: 12
> > > > >> Block Mark Byte Offset : 1999
> > > > >> Block Mark Bit Offset  : 0
> > > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> > > > >> nand: timing mode 5 not acknowledged by the NAND chip
> > > > >
> > > > > What is the final timing mode used? Most of us tested in mode 5 I
> > > > > guess, maybe mode 4 is broken (don't know if this is the one used here,
> > > > > neither why mode 5 is refused). Can you please try by limiting the mode
> > > > > to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
> > > >
> > > > Sure, how to do that?
> > >
> > > This loop [1] tries to configure each mode (5, 4, ...) until one
> > > succeeds (default is 0: must always work). Please try to limit mode to
> > > 0, 1, etc.
> > >
> > > Mode 0 should work.
> > >
> >
> > This is not correct. When all the mode fail it fallback to 0 that does
> > not work. Already check
> > So the fallback is created for this situation
>
> Sorry but I don't understand what you are saying.
>

I said that where a timing mode is not ackolege then the mtd stack should
send a reset command and fallback to timeing mode 0. The nand does not
respond anymore.

> Are you telling me that you already tried mode 0 and that it did not
> work better than other timings?
>

I force only to use different mode but never try mode 0 ;) just
because should be
the normal fallback

Michael

> >
> > > [1] https://elixir.bootlin.com/linux/v5.3-rc1/source/drivers/mtd/nand/raw/nand_base.c#L933
> > >
> > > >
> > > >
> > > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > > >> Scanning device for bad blocks
> > > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > > >> ....
> > > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
> > > > >> 5 fixed-partitions partitions found on MTD device gpmi-nand
> > > > >> Creating 5 MTD partitions on "gpmi-nand":
> > > > >> 0x000000000000-0x000000500000 : "u-boot"
> > > > >> 0x000000500000-0x000000600000 : "u-boot-env"
> > > > >> 0x000000600000-0x000000800000 : "log"
> > > > >> 0x000000800000-0x000010000000 : "flash"
> > > > >> 0x000000000000-0x000010000000 : "all"
> > > > >> gpmi-nand 1806000.gpmi-nand: driver registered.
> > > > >>
> > > > >>
> > > > >> This is using a linux kernel v5.1.14. I have seen this happen on
> > > > >> a number of boards I have here - but it is only occasional. It
> > > > >> only happens once in a while on boot, maybe 1 in 40 or more times.
> > > > >> So it can take quite a while to reproduce (using a boot loop setup).
> > > > >
> > > > > That's strange... I don't get what would produce such unstable issue.
> > > >
> > > > My initial guess is that the calculated timing is very marginal.
> > >
> > > What do you mean by "marginal"?
> > >
> >
> > I don't think that is timing calculation. I have tried to use the same timing
> > as before but when those are applide. Is it possible?
>
>                                       ^
> I suppose the end of the sentence is missing?
>
>
> Thanks,
> Miquèl



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-07-29 13:00           ` Michael Nazzareno Trimarchi
@ 2019-07-29 13:22             ` Miquel Raynal
  2019-07-29 20:00               ` Michael Nazzareno Trimarchi
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel Raynal @ 2019-07-29 13:22 UTC (permalink / raw)
  To: Michael Nazzareno Trimarchi
  Cc: s.hauer, Greg Ungerer, linux-mtd, Boris Brezillon

Hi Michael,

Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
Mon, 29 Jul 2019 15:00:04 +0200:

> Hi Miquel
> 
> On Mon, Jul 29, 2019 at 2:55 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Michael,
> >
> > Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> > Mon, 29 Jul 2019 14:49:19 +0200:
> >  
> > > Hi Miguel
> > >
> > > On Mon, Jul 29, 2019 at 2:47 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > >
> > > > Hi Greg,
> > > >
> > > > + Boris
> > > >
> > > > Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
> > > >  
> > > > > Hi Miquel,
> > > > >
> > > > > On 29/7/19 6:36 pm, Miquel Raynal wrote:  
> > > > > > Hi Greg,
> > > > > >
> > > > > > One question below.
> > > > > >
> > > > > > +Michael
> > > > > > +Sascha
> > > > > >
> > > > > > Hello Michael, here is a similar issue to yours, I know you did not
> > > > > > have enough time to share your solution but here we have someone else
> > > > > > reproducing the issue, would you mind sharing a branch or a patch, even
> > > > > > a WIP one, just to help debugging?
> > > > > >
> > > > > > Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> > > > > >  
> > > > > >> Hi Miquel,
> > > > > >>
> > > > > >> I am experiencing a problem with NAND flash DMA timeouts on
> > > > > >> iMX6ull based boards. The problem is very similar to that
> > > > > >> described in:
> > > > > >>
> > > > > >>     https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
> > > > > >>
> > > > > >> That didn't come to any specific resolution that I could see
> > > > > >> in that thread.
> > > > > >>
> > > > > >> The boot trace on the console for me looks like this:
> > > > > >>
> > > > > >> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> > > > > >> nand: Micron MT29F2G08ABAEAWP
> > > > > >> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > > > >> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> > > > > >> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> > > > > >> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> > > > > >> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> > > > > >> GF length              : 13
> > > > > >> ECC Strength           : 8
> > > > > >> Page Size in Bytes     : 2110
> > > > > >> Metadata Size in Bytes : 10
> > > > > >> ECC Chunk0 Size in Bytes: 512
> > > > > >> ECC Chunkn Size in Bytes: 512
> > > > > >> ECC Chunk Count        : 4
> > > > > >> Payload Size in Bytes  : 2048
> > > > > >> Auxiliary Size in Bytes: 16
> > > > > >> Auxiliary Status Offset: 12
> > > > > >> Block Mark Byte Offset : 1999
> > > > > >> Block Mark Bit Offset  : 0
> > > > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> > > > > >> nand: timing mode 5 not acknowledged by the NAND chip  
> > > > > >
> > > > > > What is the final timing mode used? Most of us tested in mode 5 I
> > > > > > guess, maybe mode 4 is broken (don't know if this is the one used here,
> > > > > > neither why mode 5 is refused). Can you please try by limiting the mode
> > > > > > to 0, 1, 2... until, hopefully, we narrow down to the failing mode.  
> > > > >
> > > > > Sure, how to do that?  
> > > >
> > > > This loop [1] tries to configure each mode (5, 4, ...) until one
> > > > succeeds (default is 0: must always work). Please try to limit mode to
> > > > 0, 1, etc.
> > > >
> > > > Mode 0 should work.
> > > >  
> > >
> > > This is not correct. When all the mode fail it fallback to 0 that does
> > > not work. Already check
> > > So the fallback is created for this situation  
> >
> > Sorry but I don't understand what you are saying.
> >  
> 
> I said that where a timing mode is not ackolege then the mtd stack should
> send a reset command and fallback to timeing mode 0. The nand does not
> respond anymore.

It depends on what you define by "not acknowledged". What you describe
is the current situation: if either the NAND controller or the NAND
chip do not support the mode requested by the core, the core will try
another (slower) mode until either we found one or we are at timing
mode 0.

Unfortunately, we cannot check that "all operation with these timings
will work" at boot time, it would be very time consuming; especially
for something that is very likely to be a controller driver issue, and
that is what happens here: both the controller and the chip acknowledge
the new timings.

> 
> > Are you telling me that you already tried mode 0 and that it did not
> > work better than other timings?
> >  
> 
> I force only to use different mode but never try mode 0 ;) just
> because should be
> the normal fallback

Unless there is a timing calculation issue in the controller driver.
Greg, can you please find the quickest working mode (starting from 0,
of course, to ensure mode 0 is stable).

[...]

> > > > > >
> > > > > > That's strange... I don't get what would produce such unstable issue.  
> > > > >
> > > > > My initial guess is that the calculated timing is very marginal.  
> > > >
> > > > What do you mean by "marginal"?
> > > >  
> > >
> > > I don't think that is timing calculation. I have tried to use the same timing
> > > as before but when those are applide. Is it possible?  
> >
> >                                       ^
> > I suppose the end of the sentence is missing?

Michael, what did you mean here?


Thanks,
Miquèl

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-07-29 13:22             ` Miquel Raynal
@ 2019-07-29 20:00               ` Michael Nazzareno Trimarchi
  2019-07-29 21:02                 ` Miquel Raynal
  0 siblings, 1 reply; 85+ messages in thread
From: Michael Nazzareno Trimarchi @ 2019-07-29 20:00 UTC (permalink / raw)
  To: Miquel Raynal; +Cc: s.hauer, Greg Ungerer, linux-mtd, Boris Brezillon

Hi Miquel

sorry was difficult day ;). My answer below

On Mon, Jul 29, 2019 at 3:22 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Michael,
>
> Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> Mon, 29 Jul 2019 15:00:04 +0200:
>
> > Hi Miquel
> >
> > On Mon, Jul 29, 2019 at 2:55 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > >
> > > Hi Michael,
> > >
> > > Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> > > Mon, 29 Jul 2019 14:49:19 +0200:
> > >
> > > > Hi Miguel
> > > >
> > > > On Mon, Jul 29, 2019 at 2:47 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > >
> > > > > Hi Greg,
> > > > >
> > > > > + Boris
> > > > >
> > > > > Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
> > > > >
> > > > > > Hi Miquel,
> > > > > >
> > > > > > On 29/7/19 6:36 pm, Miquel Raynal wrote:
> > > > > > > Hi Greg,
> > > > > > >
> > > > > > > One question below.
> > > > > > >
> > > > > > > +Michael
> > > > > > > +Sascha
> > > > > > >
> > > > > > > Hello Michael, here is a similar issue to yours, I know you did not
> > > > > > > have enough time to share your solution but here we have someone else
> > > > > > > reproducing the issue, would you mind sharing a branch or a patch, even
> > > > > > > a WIP one, just to help debugging?
> > > > > > >
> > > > > > > Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> > > > > > >
> > > > > > >> Hi Miquel,
> > > > > > >>
> > > > > > >> I am experiencing a problem with NAND flash DMA timeouts on
> > > > > > >> iMX6ull based boards. The problem is very similar to that
> > > > > > >> described in:
> > > > > > >>
> > > > > > >>     https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
> > > > > > >>
> > > > > > >> That didn't come to any specific resolution that I could see
> > > > > > >> in that thread.
> > > > > > >>
> > > > > > >> The boot trace on the console for me looks like this:
> > > > > > >>
> > > > > > >> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> > > > > > >> nand: Micron MT29F2G08ABAEAWP
> > > > > > >> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > > > > >> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> > > > > > >> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> > > > > > >> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> > > > > > >> GF length              : 13
> > > > > > >> ECC Strength           : 8
> > > > > > >> Page Size in Bytes     : 2110
> > > > > > >> Metadata Size in Bytes : 10
> > > > > > >> ECC Chunk0 Size in Bytes: 512
> > > > > > >> ECC Chunkn Size in Bytes: 512
> > > > > > >> ECC Chunk Count        : 4
> > > > > > >> Payload Size in Bytes  : 2048
> > > > > > >> Auxiliary Size in Bytes: 16
> > > > > > >> Auxiliary Status Offset: 12
> > > > > > >> Block Mark Byte Offset : 1999
> > > > > > >> Block Mark Bit Offset  : 0
> > > > > > >> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> > > > > > >> nand: timing mode 5 not acknowledged by the NAND chip
> > > > > > >
> > > > > > > What is the final timing mode used? Most of us tested in mode 5 I
> > > > > > > guess, maybe mode 4 is broken (don't know if this is the one used here,
> > > > > > > neither why mode 5 is refused). Can you please try by limiting the mode
> > > > > > > to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
> > > > > >
> > > > > > Sure, how to do that?
> > > > >
> > > > > This loop [1] tries to configure each mode (5, 4, ...) until one
> > > > > succeeds (default is 0: must always work). Please try to limit mode to
> > > > > 0, 1, etc.
> > > > >
> > > > > Mode 0 should work.
> > > > >
> > > >
> > > > This is not correct. When all the mode fail it fallback to 0 that does
> > > > not work. Already check
> > > > So the fallback is created for this situation
> > >
> > > Sorry but I don't understand what you are saying.
> > >
> >
> > I said that where a timing mode is not ackolege then the mtd stack should
> > send a reset command and fallback to timeing mode 0. The nand does not
> > respond anymore.
>
> It depends on what you define by "not acknowledged". What you describe
> is the current situation: if either the NAND controller or the NAND
> chip do not support the mode requested by the core, the core will try
> another (slower) mode until either we found one or we are at timing
> mode 0.
>
> Unfortunately, we cannot check that "all operation with these timings
> will work" at boot time, it would be very time consuming; especially
> for something that is very likely to be a controller driver issue, and
> that is what happens here: both the controller and the chip acknowledge
> the new timings.
>
> >
> > > Are you telling me that you already tried mode 0 and that it did not
> > > work better than other timings?
> > >
> >
> > I force only to use different mode but never try mode 0 ;) just
> > because should be
> > the normal fallback
>
> Unless there is a timing calculation issue in the controller driver.
> Greg, can you please find the quickest working mode (starting from 0,
> of course, to ensure mode 0 is stable).
>
> [...]
>
> > > > > > >
> > > > > > > That's strange... I don't get what would produce such unstable issue.
> > > > > >
> > > > > > My initial guess is that the calculated timing is very marginal.
> > > > >
> > > > > What do you mean by "marginal"?
> > > > >
> > > >
> > > > I don't think that is timing calculation. I have tried to use the same timing
> > > > as before but when those are applide. Is it possible?
> > >
> > >                                       ^
> > > I suppose the end of the sentence is missing?
>
> Michael, what did you mean here?
>
commit 02c786627b93b3c3286570f793294816286ff397
Author: Michael Trimarchi <michael@amarulasolutions.com>
Date:   Fri Oct 5 09:46:29 2018 +0200

    Revert "mtd: rawnand: gpmi: use core timings instead of an
empirical derivation"

    This reverts commit b1206122069aadabe1a8c50789277a978aaa4df7.

    Change-Id: Icd0ddcd5e3ac7d82932bbf412299cca424cbc571
    Jira-Id: WAN-50
    Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>

Revert this one does not fix the problem. Right now I have two revert
this one and

commit 6ab543c1924f77957004994bd6806a9daa45f903 (tag: MMI_004_011_R02)
Author: Michael Trimarchi <michael@amarulasolutions.com>
Date:   Fri Oct 5 09:46:44 2018 +0200

    Revert "mtd: rawnand: gpmi: support ->setup_data_interface()"

    This reverts commit 76e1a0086a0c3276b384f77905345e0fcc886fdd.

    Change-Id: I60fb6f874364d1deeda3424d4508553a38ac9b1a
    Jira-Id: WAN-50
    Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>

I did not have time to finish to undestand why this was fixing my problem
Michael


>
> Thanks,
> Miquèl



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-07-29 20:00               ` Michael Nazzareno Trimarchi
@ 2019-07-29 21:02                 ` Miquel Raynal
  0 siblings, 0 replies; 85+ messages in thread
From: Miquel Raynal @ 2019-07-29 21:02 UTC (permalink / raw)
  To: Michael Nazzareno Trimarchi
  Cc: s.hauer, Greg Ungerer, linux-mtd, Boris Brezillon

Hi Michael,

Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
Mon, 29 Jul 2019 22:00:25 +0200:

> Hi Miquel
> 
> sorry was difficult day ;). My answer below
> 

No pb ;)

[...]

> > > > > > > > That's strange... I don't get what would produce
such unstable issue.  
> > > > > > >
> > > > > > > My initial guess is that the calculated timing is very marginal.  
> > > > > >
> > > > > > What do you mean by "marginal"?
> > > > > >  
> > > > >
> > > > > I don't think that is timing calculation. I have tried to use the same timing
> > > > > as before but when those are applide. Is it possible?  
> > > >
> > > >                                       ^
> > > > I suppose the end of the sentence is missing?  
> >
> > Michael, what did you mean here?
> >  
> commit 02c786627b93b3c3286570f793294816286ff397
> Author: Michael Trimarchi <michael@amarulasolutions.com>
> Date:   Fri Oct 5 09:46:29 2018 +0200
> 
>     Revert "mtd: rawnand: gpmi: use core timings instead of an
> empirical derivation"
> 
>     This reverts commit b1206122069aadabe1a8c50789277a978aaa4df7.
> 
>     Change-Id: Icd0ddcd5e3ac7d82932bbf412299cca424cbc571
>     Jira-Id: WAN-50
>     Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> 
> Revert this one does not fix the problem. Right now I have two revert
> this one and
> 
> commit 6ab543c1924f77957004994bd6806a9daa45f903 (tag: MMI_004_011_R02)
> Author: Michael Trimarchi <michael@amarulasolutions.com>
> Date:   Fri Oct 5 09:46:44 2018 +0200
> 
>     Revert "mtd: rawnand: gpmi: support ->setup_data_interface()"
> 
>     This reverts commit 76e1a0086a0c3276b384f77905345e0fcc886fdd.
> 
>     Change-Id: I60fb6f874364d1deeda3424d4508553a38ac9b1a
>     Jira-Id: WAN-50
>     Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> 
> I did not have time to finish to undestand why this was fixing my problem

Ok so I am pretty convinced that this is still a timings issue then;
but not entirely due to the different timings calculation. Interesting.
I'm waiting for Greg's results now.


Thanks,
Miquèl

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-07-29 12:47     ` Miquel Raynal
  2019-07-29 12:49       ` Michael Nazzareno Trimarchi
@ 2019-07-30  0:28       ` Greg Ungerer
  2019-07-30  0:41         ` Greg Ungerer
  1 sibling, 1 reply; 85+ messages in thread
From: Greg Ungerer @ 2019-07-30  0:28 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: s.hauer, Michael Nazzareno Trimarchi, linux-mtd, Boris Brezillon

Hi Miquel,

On 29/7/19 10:47 pm, Miquel Raynal wrote:
> Hi Greg,
> 
> + Boris
> 
> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
> 
>> Hi Miquel,
>>
>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>> Hi Greg,
>>>
>>> One question below.
>>>
>>> +Michael
>>> +Sascha
>>>
>>> Hello Michael, here is a similar issue to yours, I know you did not
>>> have enough time to share your solution but here we have someone else
>>> reproducing the issue, would you mind sharing a branch or a patch, even
>>> a WIP one, just to help debugging?
>>>
>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>>    
>>>> Hi Miquel,
>>>>
>>>> I am experiencing a problem with NAND flash DMA timeouts on
>>>> iMX6ull based boards. The problem is very similar to that
>>>> described in:
>>>>
>>>>      https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
>>>>
>>>> That didn't come to any specific resolution that I could see
>>>> in that thread.
>>>>
>>>> The boot trace on the console for me looks like this:
>>>>
>>>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>>>> nand: Micron MT29F2G08ABAEAWP
>>>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>>>> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
>>>> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
>>>> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
>>>> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
>>>> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
>>>> GF length              : 13
>>>> ECC Strength           : 8
>>>> Page Size in Bytes     : 2110
>>>> Metadata Size in Bytes : 10
>>>> ECC Chunk0 Size in Bytes: 512
>>>> ECC Chunkn Size in Bytes: 512
>>>> ECC Chunk Count        : 4
>>>> Payload Size in Bytes  : 2048
>>>> Auxiliary Size in Bytes: 16
>>>> Auxiliary Status Offset: 12
>>>> Block Mark Byte Offset : 1999
>>>> Block Mark Bit Offset  : 0
>>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
>>>> nand: timing mode 5 not acknowledged by the NAND chip
>>>
>>> What is the final timing mode used? Most of us tested in mode 5 I
>>> guess, maybe mode 4 is broken (don't know if this is the one used here,
>>> neither why mode 5 is refused). Can you please try by limiting the mode
>>> to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
>>
>> Sure, how to do that?
> 
> This loop [1] tries to configure each mode (5, 4, ...) until one
> succeeds (default is 0: must always work). Please try to limit mode to
> 0, 1, etc.
> 
> Mode 0 should work.
> 
> [1] https://elixir.bootlin.com/linux/v5.3-rc1/source/drivers/mtd/nand/raw/nand_base.c#L933

The normal behavior - which usually works - has
chip->onfi_timing_mode_default=5 here. So in other words on the first pass
through this loop it is checking mode 5, and setting it as the default.

I am running a test/reboot loop now waiting for failure to see
if it is still using mode 5 in that case.

Regards
Greg



>>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>>> Scanning device for bad blocks
>>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>>> ....
>>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>>> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22
>>>> 5 fixed-partitions partitions found on MTD device gpmi-nand
>>>> Creating 5 MTD partitions on "gpmi-nand":
>>>> 0x000000000000-0x000000500000 : "u-boot"
>>>> 0x000000500000-0x000000600000 : "u-boot-env"
>>>> 0x000000600000-0x000000800000 : "log"
>>>> 0x000000800000-0x000010000000 : "flash"
>>>> 0x000000000000-0x000010000000 : "all"
>>>> gpmi-nand 1806000.gpmi-nand: driver registered.
>>>>
>>>>
>>>> This is using a linux kernel v5.1.14. I have seen this happen on
>>>> a number of boards I have here - but it is only occasional. It
>>>> only happens once in a while on boot, maybe 1 in 40 or more times.
>>>> So it can take quite a while to reproduce (using a boot loop setup).
>>>
>>> That's strange... I don't get what would produce such unstable issue.
>>
>> My initial guess is that the calculated timing is very marginal.
> 
> What do you mean by "marginal"?
> 
>> The problem seems more likely to happen if flash write activity
>> had been occurring just before a soft reboot. Its not a guarantee,
>> just more likely.
> 
> That's really disturbing. I doubt this is the real cause though.
> 
>>
>> Interesting observation is that Michael was using Micron flash,
>> and boards that I have with the problem also have Micron flash.
>> Both a form of Micron MT29F2G08.
>>
>> I have similar boards, iMX6ull based, with different brands of
>> NAND flash and I have not seen any problem on them.
> 
> That's great to narrow down the root cause. Maybe these chips have
> tighter timing constraints.
> 
>>
>> Regards
>> Greg
>>
>>
>>
>>>> As per the email thread I pointed to above I looked at reverting
>>>> those patches, but that was not at all easy given how much the gpmi
>>>> driver code had moved. So instead I modified the code with this:
>>>>
>>>> --- a/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
>>>> +++ b/linux/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
>>>> @@ -481,6 +481,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
>>>>       void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>>>     {
>>>> +#if 0
>>>>            struct gpmi_nfc_hardware_timing *hw = &this->hw;
>>>>            struct resources *r = &this->resources;
>>>>            void __iomem *gpmi_regs = r->gpmi_regs;
>>>> @@ -505,6 +512,7 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>>>              /* Wait for the DLL to settle. */
>>>>            udelay(dll_wait_time_us);
>>>> +#endif
>>>>     }
>>>>       int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
>>>>
>>>> So far after a couple of days of testing with this I no longer
>>>> see the DMA timeout.
>>>>
>>>> Any thoughts?
>>>>
>>>> Regards
>>>> Greg
>>>>   
>>>
>>> Thanks,
>>> Miquèl
>>>    
> 
> Thanks,
> Miquèl
> 

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-07-30  0:28       ` Greg Ungerer
@ 2019-07-30  0:41         ` Greg Ungerer
  2019-07-30  6:06           ` Greg Ungerer
  0 siblings, 1 reply; 85+ messages in thread
From: Greg Ungerer @ 2019-07-30  0:41 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: s.hauer, Michael Nazzareno Trimarchi, linux-mtd, Boris Brezillon

Hi Miquel,

On 30/7/19 10:28 am, Greg Ungerer wrote:
> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
[snip]
>>>>> nand: timing mode 5 not acknowledged by the NAND chip
>>>>
>>>> What is the final timing mode used? Most of us tested in mode 5 I
>>>> guess, maybe mode 4 is broken (don't know if this is the one used here,
>>>> neither why mode 5 is refused). Can you please try by limiting the mode
>>>> to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
>>>
>>> Sure, how to do that?
>>
>> This loop [1] tries to configure each mode (5, 4, ...) until one
>> succeeds (default is 0: must always work). Please try to limit mode to
>> 0, 1, etc.
>>
>> Mode 0 should work.
>>
>> [1] https://elixir.bootlin.com/linux/v5.3-rc1/source/drivers/mtd/nand/raw/nand_base.c#L933
> 
> The normal behavior - which usually works - has
> chip->onfi_timing_mode_default=5 here. So in other words on the first pass
> through this loop it is checking mode 5, and setting it as the default.
> 
> I am running a test/reboot loop now waiting for failure to see
> if it is still using mode 5 in that case.

With this trace in place:

--- a/linux/drivers/mtd/nand/raw/nand_base.c
+++ b/linux/drivers/mtd/nand/raw/nand_base.c
@@ -910,6 +910,7 @@ static int nand_init_data_interface(struct nand_chip *chip)
         }
  
         for (mode = fls(modes) - 1; mode >= 0; mode--) {
+               printk("%s(%d): checking mode=%d\n", __FILE__, __LINE__, mode);
                 ret = onfi_fill_data_interface(chip, NAND_SDR_IFACE, mode);
                 if (ret)
                         continue;
@@ -923,10 +924,12 @@ static int nand_init_data_interface(struct nand_chip *chip)
                                                  &chip->data_interface);
                 if (!ret) {
                         chip->onfi_timing_mode_default = mode;
+                       printk("%s(%d): BREAKING AT mode=%d\n", __FILE__, __LINE__, mode);
                         break;
                 }
         }
  
+       printk("%s(%d): chip->onfi_timing_mode_default=%d\n", __FILE__, __LINE__, chip->onfi_timing_mode_default);
         return 0;
  }
  

First NAND failure gives this:

nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
drivers/mtd/nand/raw/nand_base.c(913): checking mode=5
drivers/mtd/nand/raw/nand_base.c(927): BREAKING AT mode=5
drivers/mtd/nand/raw/nand_base.c(932): chip->onfi_timing_mode_default=5
gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000100
gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
gpmi-nand 1806000.gpmi-nand: Show BCH registers :
gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
gpmi-nand 1806000.gpmi-nand: BCH Geometry :
GF length              : 13
ECC Strength           : 8
Page Size in Bytes     : 2110
Metadata Size in Bytes : 10
ECC Chunk0 Size in Bytes: 512
ECC Chunkn Size in Bytes: 512
ECC Chunk Count        : 4
Payload Size in Bytes  : 2048
Auxiliary Size in Bytes: 16
Auxiliary Status Offset: 12
Block Mark Byte Offset : 1999
Block Mark Bit Offset  : 0
gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
nand: timing mode 5 not acknowledged by the NAND chip
gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22

Regards
Greg



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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-07-30  0:41         ` Greg Ungerer
@ 2019-07-30  6:06           ` Greg Ungerer
  2019-07-30  8:38             ` Miquel Raynal
  0 siblings, 1 reply; 85+ messages in thread
From: Greg Ungerer @ 2019-07-30  6:06 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: s.hauer, Michael Nazzareno Trimarchi, linux-mtd, Boris Brezillon

Hi Miquel,

On 30/7/19 10:41 am, Greg Ungerer wrote:
> On 30/7/19 10:28 am, Greg Ungerer wrote:
>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> [snip]
>>>>>> nand: timing mode 5 not acknowledged by the NAND chip
>>>>>
>>>>> What is the final timing mode used? Most of us tested in mode 5 I
>>>>> guess, maybe mode 4 is broken (don't know if this is the one used here,
>>>>> neither why mode 5 is refused). Can you please try by limiting the mode
>>>>> to 0, 1, 2... until, hopefully, we narrow down to the failing mode.
>>>>
>>>> Sure, how to do that?
>>>
>>> This loop [1] tries to configure each mode (5, 4, ...) until one
>>> succeeds (default is 0: must always work). Please try to limit mode to
>>> 0, 1, etc.
>>>
>>> Mode 0 should work.
>>>
>>> [1] https://elixir.bootlin.com/linux/v5.3-rc1/source/drivers/mtd/nand/raw/nand_base.c#L933
>>
>> The normal behavior - which usually works - has
>> chip->onfi_timing_mode_default=5 here. So in other words on the first pass
>> through this loop it is checking mode 5, and setting it as the default.
>>
>> I am running a test/reboot loop now waiting for failure to see
>> if it is still using mode 5 in that case.
> 
> With this trace in place:
> 
> --- a/linux/drivers/mtd/nand/raw/nand_base.c
> +++ b/linux/drivers/mtd/nand/raw/nand_base.c
> @@ -910,6 +910,7 @@ static int nand_init_data_interface(struct nand_chip *chip)
>          }
> 
>          for (mode = fls(modes) - 1; mode >= 0; mode--) {
> +               printk("%s(%d): checking mode=%d\n", __FILE__, __LINE__, mode);
>                  ret = onfi_fill_data_interface(chip, NAND_SDR_IFACE, mode);
>                  if (ret)
>                          continue;
> @@ -923,10 +924,12 @@ static int nand_init_data_interface(struct nand_chip *chip)
>                                                   &chip->data_interface);
>                  if (!ret) {
>                          chip->onfi_timing_mode_default = mode;
> +                       printk("%s(%d): BREAKING AT mode=%d\n", __FILE__, __LINE__, mode);
>                          break;
>                  }
>          }
> 
> +       printk("%s(%d): chip->onfi_timing_mode_default=%d\n", __FILE__, __LINE__, chip->onfi_timing_mode_default);
>          return 0;
>   }
> 
> 
> First NAND failure gives this:
> 
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron MT29F2G08ABAEAWP
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
> drivers/mtd/nand/raw/nand_base.c(913): checking mode=5
> drivers/mtd/nand/raw/nand_base.c(927): BREAKING AT mode=5
> drivers/mtd/nand/raw/nand_base.c(932): chip->onfi_timing_mode_default=5
> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000100
> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> GF length              : 13
> ECC Strength           : 8
> Page Size in Bytes     : 2110
> Metadata Size in Bytes : 10
> ECC Chunk0 Size in Bytes: 512
> ECC Chunkn Size in Bytes: 512
> ECC Chunk Count        : 4
> Payload Size in Bytes  : 2048
> Auxiliary Size in Bytes: 16
> Auxiliary Status Offset: 12
> Block Mark Byte Offset : 1999
> Block Mark Bit Offset  : 0
> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> nand: timing mode 5 not acknowledged by the NAND chip
> gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22

Not sure if this is a useful data point... But I modified that
nand_init_data_interface() loop to start checking from data mode 4.
So now on every boot it defaults to mode 4. That has been running
most of the day, up to 900 boot cycles now, no failures.

Regards
Greg


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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-07-30  6:06           ` Greg Ungerer
@ 2019-07-30  8:38             ` Miquel Raynal
  2019-07-30  8:58               ` Boris Brezillon
  2019-07-31  2:05               ` Greg Ungerer
  0 siblings, 2 replies; 85+ messages in thread
From: Miquel Raynal @ 2019-07-30  8:38 UTC (permalink / raw)
  To: Greg Ungerer
  Cc: s.hauer, Michael Nazzareno Trimarchi, linux-mtd, Boris Brezillon

Hi Greg,

Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:

> Hi Miquel,
> 
> On 30/7/19 10:41 am, Greg Ungerer wrote:
> > On 30/7/19 10:28 am, Greg Ungerer wrote:  
> >> On 29/7/19 10:47 pm, Miquel Raynal wrote:  
> >>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:  
> >>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:  
> >>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:  
> > [snip]  
> >>>>>> nand: timing mode 5 not acknowledged by the NAND chip  
> >>>>>
> >>>>> What is the final timing mode used? Most of us tested in mode 5 I
> >>>>> guess, maybe mode 4 is broken (don't know if this is the one used here,
> >>>>> neither why mode 5 is refused). Can you please try by limiting the mode
> >>>>> to 0, 1, 2... until, hopefully, we narrow down to the failing mode.  
> >>>>
> >>>> Sure, how to do that?  
> >>>
> >>> This loop [1] tries to configure each mode (5, 4, ...) until one
> >>> succeeds (default is 0: must always work). Please try to limit mode to
> >>> 0, 1, etc.
> >>>
> >>> Mode 0 should work.
> >>>
> >>> [1] https://elixir.bootlin.com/linux/v5.3-rc1/source/drivers/mtd/nand/raw/nand_base.c#L933  
> >>
> >> The normal behavior - which usually works - has
> >> chip->onfi_timing_mode_default=5 here. So in other words on the first pass
> >> through this loop it is checking mode 5, and setting it as the default.
> >>
> >> I am running a test/reboot loop now waiting for failure to see
> >> if it is still using mode 5 in that case.  
> > 
> > With this trace in place:
> > 
> > --- a/linux/drivers/mtd/nand/raw/nand_base.c
> > +++ b/linux/drivers/mtd/nand/raw/nand_base.c
> > @@ -910,6 +910,7 @@ static int nand_init_data_interface(struct nand_chip *chip)
> >          }
> > 
> >          for (mode = fls(modes) - 1; mode >= 0; mode--) {
> > +               printk("%s(%d): checking mode=%d\n", __FILE__, __LINE__, mode);
> >                  ret = onfi_fill_data_interface(chip, NAND_SDR_IFACE, mode);
> >                  if (ret)
> >                          continue;
> > @@ -923,10 +924,12 @@ static int nand_init_data_interface(struct nand_chip *chip)
> >                                                   &chip->data_interface);
> >                  if (!ret) {
> >                          chip->onfi_timing_mode_default = mode;
> > +                       printk("%s(%d): BREAKING AT mode=%d\n", __FILE__, __LINE__, mode);
> >                          break;
> >                  }
> >          }
> > 
> > +       printk("%s(%d): chip->onfi_timing_mode_default=%d\n", __FILE__, __LINE__, chip->onfi_timing_mode_default);
> >          return 0;
> >   }
> > 
> > 
> > First NAND failure gives this:
> > 
> > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> > nand: Micron MT29F2G08ABAEAWP
> > nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
> > drivers/mtd/nand/raw/nand_base.c(913): checking mode=5
> > drivers/mtd/nand/raw/nand_base.c(927): BREAKING AT mode=5
> > drivers/mtd/nand/raw/nand_base.c(932): chip->onfi_timing_mode_default=5
> > gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> > gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> > gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> > gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> > gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> > gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> > gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> > gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> > gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000100
> > gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> > gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> > gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> > gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> > gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> > gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> > gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> > GF length              : 13
> > ECC Strength           : 8
> > Page Size in Bytes     : 2110
> > Metadata Size in Bytes : 10
> > ECC Chunk0 Size in Bytes: 512
> > ECC Chunkn Size in Bytes: 512
> > ECC Chunk Count        : 4
> > Payload Size in Bytes  : 2048
> > Auxiliary Size in Bytes: 16
> > Auxiliary Status Offset: 12
> > Block Mark Byte Offset : 1999
> > Block Mark Bit Offset  : 0
> > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> > nand: timing mode 5 not acknowledged by the NAND chip
> > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22  
> 
> Not sure if this is a useful data point... But I modified that
> nand_init_data_interface() loop to start checking from data mode 4.
> So now on every boot it defaults to mode 4. That has been running
> most of the day, up to 900 boot cycles now, no failures.

Ok so after having chatted quite a bit with Boris, it is very likely
that, for these chips, the timings in mode 5 are too tight. It could
fail the GET_FEATURES once in mode 5. Can you please dump every single
intermediate value in gpmi_nfc_compute_timings() (period, *_cycles,
use of half pêriods, tRP, sample delay, etc) as well as the content
of /sys/kernel/debug/clk/clk_summary (you'll need debugfs support
enabled and mounted).

Also, can you be sure that the NAND chip is powered with 3.3V?

Thanks,
Miquèl

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-07-30  8:38             ` Miquel Raynal
@ 2019-07-30  8:58               ` Boris Brezillon
  2019-07-31  2:05               ` Greg Ungerer
  1 sibling, 0 replies; 85+ messages in thread
From: Boris Brezillon @ 2019-07-30  8:58 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: s.hauer, Greg Ungerer, linux-mtd, Michael Nazzareno Trimarchi,
	Boris Brezillon

On Tue, 30 Jul 2019 10:38:22 +0200
Miquel Raynal <miquel.raynal@bootlin.com> wrote:

> Hi Greg,
> 
> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
> 
> > Hi Miquel,
> > 
> > On 30/7/19 10:41 am, Greg Ungerer wrote:  
> > > On 30/7/19 10:28 am, Greg Ungerer wrote:    
> > >> On 29/7/19 10:47 pm, Miquel Raynal wrote:    
> > >>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:    
> > >>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:    
> > >>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:    
> > > [snip]    
> > >>>>>> nand: timing mode 5 not acknowledged by the NAND chip    
> > >>>>>
> > >>>>> What is the final timing mode used? Most of us tested in mode 5 I
> > >>>>> guess, maybe mode 4 is broken (don't know if this is the one used here,
> > >>>>> neither why mode 5 is refused). Can you please try by limiting the mode
> > >>>>> to 0, 1, 2... until, hopefully, we narrow down to the failing mode.    
> > >>>>
> > >>>> Sure, how to do that?    
> > >>>
> > >>> This loop [1] tries to configure each mode (5, 4, ...) until one
> > >>> succeeds (default is 0: must always work). Please try to limit mode to
> > >>> 0, 1, etc.
> > >>>
> > >>> Mode 0 should work.
> > >>>
> > >>> [1] https://elixir.bootlin.com/linux/v5.3-rc1/source/drivers/mtd/nand/raw/nand_base.c#L933    
> > >>
> > >> The normal behavior - which usually works - has
> > >> chip->onfi_timing_mode_default=5 here. So in other words on the first pass
> > >> through this loop it is checking mode 5, and setting it as the default.
> > >>
> > >> I am running a test/reboot loop now waiting for failure to see
> > >> if it is still using mode 5 in that case.    
> > > 
> > > With this trace in place:
> > > 
> > > --- a/linux/drivers/mtd/nand/raw/nand_base.c
> > > +++ b/linux/drivers/mtd/nand/raw/nand_base.c
> > > @@ -910,6 +910,7 @@ static int nand_init_data_interface(struct nand_chip *chip)
> > >          }
> > > 
> > >          for (mode = fls(modes) - 1; mode >= 0; mode--) {
> > > +               printk("%s(%d): checking mode=%d\n", __FILE__, __LINE__, mode);
> > >                  ret = onfi_fill_data_interface(chip, NAND_SDR_IFACE, mode);
> > >                  if (ret)
> > >                          continue;
> > > @@ -923,10 +924,12 @@ static int nand_init_data_interface(struct nand_chip *chip)
> > >                                                   &chip->data_interface);
> > >                  if (!ret) {
> > >                          chip->onfi_timing_mode_default = mode;
> > > +                       printk("%s(%d): BREAKING AT mode=%d\n", __FILE__, __LINE__, mode);
> > >                          break;
> > >                  }
> > >          }
> > > 
> > > +       printk("%s(%d): chip->onfi_timing_mode_default=%d\n", __FILE__, __LINE__, chip->onfi_timing_mode_default);
> > >          return 0;
> > >   }
> > > 
> > > 
> > > First NAND failure gives this:
> > > 
> > > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> > > nand: Micron MT29F2G08ABAEAWP
> > > nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
> > > drivers/mtd/nand/raw/nand_base.c(913): checking mode=5
> > > drivers/mtd/nand/raw/nand_base.c(927): BREAKING AT mode=5
> > > drivers/mtd/nand/raw/nand_base.c(932): chip->onfi_timing_mode_default=5
> > > gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> > > gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> > > gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> > > gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> > > gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> > > gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000100
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> > > gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> > > gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> > > gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> > > gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> > > gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> > > gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> > > gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> > > GF length              : 13
> > > ECC Strength           : 8
> > > Page Size in Bytes     : 2110
> > > Metadata Size in Bytes : 10
> > > ECC Chunk0 Size in Bytes: 512
> > > ECC Chunkn Size in Bytes: 512
> > > ECC Chunk Count        : 4
> > > Payload Size in Bytes  : 2048
> > > Auxiliary Size in Bytes: 16
> > > Auxiliary Status Offset: 12
> > > Block Mark Byte Offset : 1999
> > > Block Mark Bit Offset  : 0
> > > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
> > > nand: timing mode 5 not acknowledged by the NAND chip
> > > gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -22    
> > 
> > Not sure if this is a useful data point... But I modified that
> > nand_init_data_interface() loop to start checking from data mode 4.
> > So now on every boot it defaults to mode 4. That has been running
> > most of the day, up to 900 boot cycles now, no failures.  
> 
> Ok so after having chatted quite a bit with Boris, it is very likely
> that, for these chips, the timings in mode 5 are too tight. It could
> fail the GET_FEATURES once in mode 5. Can you please dump every single
> intermediate value in gpmi_nfc_compute_timings() (period, *_cycles,
> use of half pêriods, tRP, sample delay, etc) as well as the content
> of /sys/kernel/debug/clk/clk_summary (you'll need debugfs support
> enabled and mounted).

Not sure the clk will stay at the rate it was set during the timing
selection. Can you also add a trace printing the result of
clk_get_rate(r->clock[0], hw->clk_rate) here [1]?

[1]https://elixir.bootlin.com/linux/v5.3-rc1/source/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c#L711

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-07-30  8:38             ` Miquel Raynal
  2019-07-30  8:58               ` Boris Brezillon
@ 2019-07-31  2:05               ` Greg Ungerer
  2019-07-31  6:28                 ` Boris Brezillon
  1 sibling, 1 reply; 85+ messages in thread
From: Greg Ungerer @ 2019-07-31  2:05 UTC (permalink / raw)
  To: Miquel Raynal, Boris Brezillon
  Cc: s.hauer, Michael Nazzareno Trimarchi, linux-mtd

[-- Attachment #1: Type: text/plain, Size: 29834 bytes --]

Hi Miquel, Boris,

On 30/7/19 6:38 pm, Miquel Raynal wrote:
> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
>> On 30/7/19 10:41 am, Greg Ungerer wrote:
>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>> [snip]
>> Not sure if this is a useful data point... But I modified that
>> nand_init_data_interface() loop to start checking from data mode 4.
>> So now on every boot it defaults to mode 4. That has been running
>> most of the day, up to 900 boot cycles now, no failures.
> 
> Ok so after having chatted quite a bit with Boris, it is very likely
> that, for these chips, the timings in mode 5 are too tight. It could
> fail the GET_FEATURES once in mode 5. Can you please dump every single
> intermediate value in gpmi_nfc_compute_timings() (period, *_cycles,
> use of half pêriods, tRP, sample delay, etc) as well as the content
> of /sys/kernel/debug/clk/clk_summary (you'll need debugfs support
> enabled and mounted).
> 
> Also, can you be sure that the NAND chip is powered with 3.3V?

Yes, 3.3V NAND chip.

Using the attached patch I get the following trace:

...
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
   sdr->tBERS_max=65535000000
   sdr->tCCS_min=500000000
   sdr->tPROG_max=65535000000
   sdr->tR_max=200000000000000
   sdr->tALH_min=20000
   sdr->tADL_min=400000
   sdr->tALS_min=50000
   sdr->tAR_min=25000
   sdr->tCEA_max=100000
   sdr->tCEH_min=20000
   sdr->tCH_min=20000
   sdr->tCHZ_max=100000
   sdr->tCLH_min=20000
   sdr->tCLR_min=20000
   sdr->tCLS_min=50000
   sdr->tCOH_min=0
   sdr->tCS_min=70000
   sdr->tDH_min=20000
   sdr->tDS_min=40000
   sdr->tFEAT_max=1000000
   sdr->tIR_min=10000
   sdr->tITC_max=1000000
   sdr->tRC_min=100000
   sdr->tREA_max=40000
   sdr->tREH_min=30000
   sdr->tRHOH_min=0
   sdr->tRHW_min=200000
   sdr->tRHZ_max=200000
   sdr->tRLOH_min=0
   sdr->tRP_min=50000
   sdr->tRR_min=40000
   sdr->tRST_max=250000000000
   sdr->tWB_max=200000
   sdr->tWC_min=100000
   sdr->tWH_min=30000
   sdr->tWHR_min=120000
   sdr->tWP_min=50000
   sdr->tWW_min=100000
     hw->clk_rate=22000000
     wrn_dly_sel=0
     period_ps=45454
     addr_setup_cycles=2
     data_setup_cycles=1
     data_hold_cycles=1
     busy_timeout_cycles=31302
     hw->timing0=0x00020101
     hw->timing1=0x60000000
     dll_threshold_ps=12000
     use_half_period=1
     reference_period_ps=22727
     tRP_ps=45454
     sample_delay_ps=4294955664
     sample_delay_factor=0
     hw->ctrl1n=0x00000000
     hw->ctrl1n=0x00000000
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
   hw>clk_rate=22000000
   clk_set_rate(r->clock[0], hw->clk_rate)=0
   clk_get_rate(r->clock[0])=22000000
random: fast init done
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
   sdr->tBERS_max=3000000000
   sdr->tCCS_min=100000
   sdr->tPROG_max=600000000
   sdr->tR_max=25000000
   sdr->tALH_min=20000
   sdr->tADL_min=400000
   sdr->tALS_min=50000
   sdr->tAR_min=25000
   sdr->tCEA_max=100000
   sdr->tCEH_min=20000
   sdr->tCH_min=20000
   sdr->tCHZ_max=100000
   sdr->tCLH_min=20000
   sdr->tCLR_min=20000
   sdr->tCLS_min=50000
   sdr->tCOH_min=0
   sdr->tCS_min=70000
   sdr->tDH_min=20000
   sdr->tDS_min=40000
   sdr->tFEAT_max=1000000
   sdr->tIR_min=10000
   sdr->tITC_max=1000000
   sdr->tRC_min=100000
   sdr->tREA_max=40000
   sdr->tREH_min=30000
   sdr->tRHOH_min=0
   sdr->tRHW_min=200000
   sdr->tRHZ_max=200000
   sdr->tRLOH_min=0
   sdr->tRP_min=50000
   sdr->tRR_min=40000
   sdr->tRST_max=250000000000
   sdr->tWB_max=200000
   sdr->tWC_min=100000
   sdr->tWH_min=30000
   sdr->tWHR_min=120000
   sdr->tWP_min=50000
   sdr->tWW_min=100000
     hw->clk_rate=22000000
     wrn_dly_sel=0
     period_ps=45454
     addr_setup_cycles=2
     data_setup_cycles=1
     data_hold_cycles=1
     busy_timeout_cycles=555
     hw->timing0=0x00020101
     hw->timing1=0xb0000000
     dll_threshold_ps=12000
     use_half_period=1
     reference_period_ps=22727
     tRP_ps=45454
     sample_delay_ps=4294955664
     sample_delay_factor=0
     hw->ctrl1n=0x00000000
     hw->ctrl1n=0x00000000
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
   hw>clk_rate=22000000
   clk_set_rate(r->clock[0], hw->clk_rate)=0
   clk_get_rate(r->clock[0])=22000000
gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
drivers/mtd/nand/raw/nand_base.c(913): checking mode=5
drivers/mtd/nand/raw/nand_base.c(927): BREAKING AT  mode=5
drivers/mtd/nand/raw/nand_base.c(932): chip->onfi_timing_mode_default=5
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
   sdr->tBERS_max=3000000000
   sdr->tCCS_min=100000
   sdr->tPROG_max=600000000
   sdr->tR_max=25000000
   sdr->tALH_min=5000
   sdr->tADL_min=400000
   sdr->tALS_min=10000
   sdr->tAR_min=10000
   sdr->tCEA_max=25000
   sdr->tCEH_min=20000
   sdr->tCH_min=5000
   sdr->tCHZ_max=30000
   sdr->tCLH_min=5000
   sdr->tCLR_min=10000
   sdr->tCLS_min=10000
   sdr->tCOH_min=15000
   sdr->tCS_min=15000
   sdr->tDH_min=5000
   sdr->tDS_min=7000
   sdr->tFEAT_max=1000000
   sdr->tIR_min=0
   sdr->tITC_max=1000000
   sdr->tRC_min=20000
   sdr->tREA_max=16000
   sdr->tREH_min=7000
   sdr->tRHOH_min=15000
   sdr->tRHW_min=100000
   sdr->tRHZ_max=100000
   sdr->tRLOH_min=5000
   sdr->tRP_min=10000
   sdr->tRR_min=20000
   sdr->tRST_max=500000000
   sdr->tWB_max=100000
   sdr->tWC_min=20000
   sdr->tWH_min=7000
   sdr->tWHR_min=80000
   sdr->tWP_min=10000
   sdr->tWW_min=100000
     hw->clk_rate=100000000
     wrn_dly_sel=3
     period_ps=10000
     addr_setup_cycles=1
     data_setup_cycles=1
     data_hold_cycles=1
     busy_timeout_cycles=2510
     hw->timing0=0x00010101
     hw->timing1=0xe0000000
     dll_threshold_ps=12000
     use_half_period=0
     reference_period_ps=10000
     tRP_ps=10000
     sample_delay_ps=80000
     sample_delay_factor=8
     hw->ctrl1n=0x00c00000
     hw->ctrl1n=0x00c28000
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
   hw>clk_rate=100000000
   clk_set_rate(r->clock[0], hw->clk_rate)=0
   clk_get_rate(r->clock[0])=99000000
Scanning device for bad blocks
5 fixed-partitions partitions found on MTD device gpmi-nand
Creating 5 MTD partitions on "gpmi-nand":
0x000000000000-0x000000500000 : "u-boot"
0x000000500000-0x000000600000 : "u-boot-env"
0x000000600000-0x000000800000 : "log"
0x000000800000-0x000010000000 : "flash"
0x000000000000-0x000010000000 : "all"
gpmi-nand 1806000.gpmi-nand: driver registered.
...


And "cat /sys/kernel/debug/clk/clk_summary" gives:

                                  enable  prepare  protect                                duty
    clock                          count    count    count        rate   accuracy phase  cycle
---------------------------------------------------------------------------------------------
  dummy                                2        2        0           0          0     0  50000
     cko2_sel                          0        0        0           0          0     0  50000
        cko2_podf                      0        0        0           0          0     0  50000
           cko2                        0        0        0           0          0     0  50000
     cko1_sel                          0        0        0           0          0     0  50000
        cko1_podf                      0        0        0           0          0     0  50000
           cko1                        0        0        0           0          0     0  50000
              cko                      0        0        0           0          0     0  50000
     usbphy2_gate                      1        1        0           0          0     0  50000
     usbphy1_gate                      1        1        0           0          0     0  50000
  ipp_di1                              0        0        0           0          0     0  50000
  ipp_di0                              0        0        0           0          0     0  50000
  osc                                  6        6        0    24000000          0     0  50000
     perclk_sel                        1        1        0    24000000          0     0  50000
        perclk                         3        3        0    24000000          0     0  50000
           pwm7                        0        0        0    24000000          0     0  50000
           pwm6                        0        0        0    24000000          0     0  50000
           pwm5                        0        0        0    24000000          0     0  50000
           i2c4                        0        0        0    24000000          0     0  50000
           pwm8                        0        0        0    24000000          0     0  50000
           pwm4                        0        0        0    24000000          0     0  50000
           pwm3                        0        0        0    24000000          0     0  50000
           pwm2                        0        0        0    24000000          0     0  50000
           pwm1                        0        0        0    24000000          0     0  50000
           i2c3                        0        0        0    24000000          0     0  50000
           i2c2                        1        1        0    24000000          0     0  50000
           i2c1                        0        0        0    24000000          0     0  50000
           gpt1_serial                 1        1        0    24000000          0     0  50000
           gpt1_bus                    1        1        0    24000000          0     0  50000
           epit2                       0        0        0    24000000          0     0  50000
           epit1                       0        0        0    24000000          0     0  50000
           gpt2_serial                 0        0        0    24000000          0     0  50000
           gpt2_bus                    0        0        0    24000000          0     0  50000
     periph_clk2_sel                   0        0        0    24000000          0     0  50000
        periph_clk2                    0        0        0    24000000          0     0  50000
     gpt_3m                            0        0        0     3000000          0     0  50000
     csi_sel                           0        0        0    24000000          0     0  50000
        csi_podf                       0        0        0    24000000          0     0  50000
           csi                         0        0        0    24000000          0     0  50000
     pll7                              1        1        0   480000000          0     0  50000
        pll7_bypass                    1        1        0   480000000          0     0  50000
           pll7_usb_host               1        1        0   480000000          0     0  50000
              usbphy2                  1        1        0   480000000          0     0  50000
     pll6                              1        1        0   500000000          0     0  50000
        pll6_bypass                    1        1        0   500000000          0     0  50000
           pll6_enet                   2        2        0   500000000          0     0  50000
              enet_ptp_ref             1        1        0    25000000          0     0  50000
                 enet_ptp              1        1        0    25000000          0     0  50000
              enet2_ref                0        0        0    50000000          0     0  50000
                 enet_ref_125m         0        0        0    50000000          0     0  50000
              enet_ref                 2        2        0    50000000          0     0  50000
     pll5                              0        0        0   296600000          0     0  50000
        pll5_bypass                    0        0        0   296600000          0     0  50000
           pll5_video                  0        0        0   296600000          0     0  50000
              pll5_post_div            0        0        0    74150000          0     0  50000
                 pll5_video_div        0        0        0    74150000          0     0  50000
     pll4                              0        0        0   147456000          0     0  50000
        pll4_bypass                    0        0        0   147456000          0     0  50000
           pll4_audio                  0        0        0   147456000          0     0  50000
              pll4_post_div            0        0        0    36864000          0     0  50000
                 pll4_audio_div        0        0        0    36864000          0     0  50000
     pll3                              1        1        0   480000000          0     0  50000
        pll3_bypass                    1        1        0   480000000          0     0  50000
           pll3_usb_otg                2        2        0   480000000          0     0  50000
              spdif_sel                0        0        0   480000000          0     0  50000
                 spdif_pred            0        0        0   240000000          0     0  50000
                    spdif_podf         0        0        0    30000000          0     0  50000
                       spdif           0        0        0    30000000          0     0  50000
              esai_sel                 0        0        0   480000000          0     0  50000
                 esai_pred             0        0        0   240000000          0     0  50000
                    esai_podf          0        0        0    30000000          0     0  50000
                       esai_extal       0        0        0    30000000          0     0  50000
              qspi1_sel                0        0        0   480000000          0     0  50000
                 qspi1_podf            0        0        0   240000000          0     0  50000
                    qspi1              0        0        0   240000000          0     0  50000
                 ldb_di1_div_7         0        0        0    68571428          0     0  50000
                    ldb_di1            0        0        0    68571428          0     0  50000
                 ldb_di1_div_3_5       0        0        0   137142857          0     0  50000
              periph2_clk2_sel         0        0        0   480000000          0     0  50000
                 periph2_clk2          0        0        0   480000000          0     0  50000
              pll3_60m                 0        0        0    60000000          0     0  50000
                 can_sel               0        0        0    60000000          0     0  50000
                    can_podf           0        0        0    30000000          0     0  50000
                       can2_serial       0        0        0    30000000          0     0  50000
                       can1_serial       0        0        0    30000000          0     0  50000
                 ecspi_sel             0        0        0    60000000          0     0  50000
                    ecspi_podf         0        0        0    60000000          0     0  50000
                       ecspi4          0        0        0    60000000          0     0  50000
                       ecspi3          0        0        0    60000000          0     0  50000
                       ecspi2          0        0        0    60000000          0     0  50000
                       ecspi1          0        0        0    60000000          0     0  50000
              pll3_80m                 1        1        0    80000000          0     0  50000
                 uart_sel              1        1        0    80000000          0     0  50000
                    uart_podf          1        1        0    80000000          0     0  50000
                       uart8_serial       0        0        0    80000000          0     0  50000
                       uart7_serial       0        0        0    80000000          0     0  50000
                       uart1_serial       1        2        0    80000000          0     0  50000
                       uart6_serial       0        0        0    80000000          0     0  50000
                       uart5_serial       0        0        0    80000000          0     0  50000
                       uart4_serial       0        0        0    80000000          0     0  50000
                       uart3_serial       0        0        0    80000000          0     0  50000
                       uart2_serial       0        0        0    80000000          0     0  50000
              pll3_pfd3_454m           0        0        0   454736842          0     0  50000
              pll3_pfd2_508m           0        0        0   508235294          0     0  50000
                 epdc_pre_sel          0        0        0   508235294          0     0  50000
                    epdc_podf          0        0        0   254117647          0     0  50000
                       epdc_pix        0        0        0   254117647          0     0  50000
                       epdc_sel        0        0        0   254117647          0     0  50000
                 sai1_sel              0        0        0   508235294          0     0  50000
                    sai1_pred          0        0        0   127058824          0     0  50000
                       sai1_podf       0        0        0    63529412          0     0  50000
                          sai1         0        0        0    63529412          0     0  50000
                 sai2_sel              0        0        0   508235294          0     0  50000
                    sai2_pred          0        0        0   127058824          0     0  50000
                       sai2_podf       0        0        0    63529412          0     0  50000
                          sai2         0        0        0    63529412          0     0  50000
                 sai3_sel              0        0        0   508235294          0     0  50000
                    sai3_pred          0        0        0   127058824          0     0  50000
                       sai3_podf       0        0        0    63529412          0     0  50000
                          sai3         0        0        0    63529412          0     0  50000
              pll3_pfd1_540m           0        0        0   540000000          0     0  50000
                 lcdif_pre_sel         0        0        0   540000000          0     0  50000
                    lcdif_pred         0        0        0   270000000          0     0  50000
                       lcdif_podf       0        0        0   135000000          0     0  50000
                          lcdif_pix       0        0        0   135000000          0     0  50000
                          iomuxc       0        0        0   135000000          0     0  50000
                          lcdif_sel       0        0        0   135000000          0     0  50000
              pll3_pfd0_720m           0        0        0   720000000          0     0  50000
              usbphy1                  1        1        0   480000000          0     0  50000
     pll2                              1        1        0   528000000          0     0  50000
        pll2_bypass                    1        1        0   528000000          0     0  50000
           pll2_bus                    2        2        0   528000000          0     0  50000
              ca7_secondary_sel        0        0        0   528000000          0     0  50000
                 step                  0        0        0   528000000          0     0  50000
              periph_pre               1        1        0   528000000          0     0  50000
                 periph                3        3        0   528000000          0     0  50000
                    ahb                7        7        0   132000000          0     0  50000
                       sdma            0        0        0   132000000          0     0  50000
                       rom             1        1        0   132000000          0     0  50000
                       esai_mem        0        0        0   132000000          0     0  50000
                       esai_ipg        0        0        0   132000000          0     0  50000
                       aips_tz3        1        1        0   132000000          0     0  50000
                       enet_ahb        2        2        0   132000000          0     0  50000
                       dcp             0        0        0   132000000          0     0  50000
                       asrc_mem        0        0        0   132000000          0     0  50000
                       asrc_ipg        0        0        0   132000000          0     0  50000
                       aips_tz2        1        1        0   132000000          0     0  50000
                       aips_tz1        1        1        0   132000000          0     0  50000
                       ipg            10       10        0    66000000          0     0  50000
                          wdog3        0        0        0    66000000          0     0  50000
                          uart8_ipg       0        0        0    66000000          0     0  50000
                          usboh3       2        2        0    66000000          0     0  50000
                          sai2_ipg       0        0        0    66000000          0     0  50000
                          sai1_ipg       0        0        0    66000000          0     0  50000
                          uart7_ipg       0        0        0    66000000          0     0  50000
                          uart1_ipg       1        2        0    66000000          0     0  50000
                          sai3_ipg       0        0        0    66000000          0     0  50000
                          spdif_gclk       0        0        0    66000000          0     0  50000
                          spba         0        0        0    66000000          0     0  50000
                          wdog2        0        0        0    66000000          0     0  50000
                          kpp          0        0        0    66000000          0     0  50000
                          mmdc_p1_ipg       0        0        0    66000000          0     0  50000
                          mmdc_p0_ipg       2        2        0    66000000          0     0  50000
                          wdog1        1        1        0    66000000          0     0  50000
                          gpio4        1        1        0    66000000          0     0  50000
                          uart6_ipg       0        0        0    66000000          0     0  50000
                          uart5_ipg       0        0        0    66000000          0     0  50000
                          gpio3        1        1        0    66000000          0     0  50000
                          ocotp        0        0        0    66000000          0     0  50000
                          gpio5        1        1        0    66000000          0     0  50000
                          gpio1        1        1        0    66000000          0     0  50000
                          uart4_ipg       0        0        0    66000000          0     0  50000
                          adc1         0        0        0    66000000          0     0  50000
                          uart3_ipg       0        0        0    66000000          0     0  50000
                          adc2         0        0        0    66000000          0     0  50000
                          gpio2        1        1        0    66000000          0     0  50000
                          uart2_ipg       0        0        0    66000000          0     0  50000
                          can2_ipg       0        0        0    66000000          0     0  50000
                          can1_ipg       0        0        0    66000000          0     0  50000
                          enet         2        2        0    66000000          0     0  50000
                    axi_sel            1        1        0   528000000          0     0  50000
                       axi_podf        2        2        0   264000000          0     0  50000
                          axi          1        1        0   264000000          0     0  50000
                             eim_slow_sel       0        0        0   264000000          0     0  50000
                                eim_slow_podf       0        0        0   132000000          0     0  50000
                                   eim       0        0        0   132000000          0     0  50000
                             lcdif_apb       0        0        0   264000000          0     0  50000
                             pxp       0        0        0   264000000          0     0  50000
                             epdc_aclk       0        0        0   264000000          0     0  50000
              pll2_pfd3_594m           0        0        0   594000000          0     0  50000
                 ldb_di0_sel           0        0        0   594000000          0     0  50000
                    ldb_di0_div_7       0        0        0    84857142          0     0  50000
                       ldb_di0         0        0        0    84857142          0     0  50000
                    ldb_di0_div_3_5       0        0        0   169714285          0     0  50000
              pll2_pfd2_396m           2        2        0   396000000          0     0  50000
                 enfc_sel              0        0        0   396000000          0     0  50000
                    enfc_pred          0        0        0    99000000          0     0  50000
                       enfc_podf       0        0        0    99000000          0     0  50000
                          gpmi_io       0        0        0    99000000          0     0  50000
                 usdhc1_sel            0        0        0   396000000          0     0  50000
                    usdhc1_podf        0        0        0   198000000          0     0  50000
                       usdhc1          0        0        0   198000000          0     0  50000
                 usdhc2_sel            0        0        0   396000000          0     0  50000
                    usdhc2_podf        0        0        0   198000000          0     0  50000
                       usdhc2          0        0        0   198000000          0     0  50000
                 bch_sel               1        1        0   396000000          0     0  50000
                    bch_podf           1        1        0    99000000          0     0  50000
                       gpmi_apb        0        0        0    99000000          0     0  50000
                       gpmi_bch_apb       0        0        0    99000000          0     0  50000
                       per_bch         0        0        0    99000000          0     0  50000
                       apbh_dma        1        1        0    99000000          0     0  50000
                 gpmi_sel              0        0        0   396000000          0     0  50000
                    gpmi_podf          0        0        0    99000000          0     0  50000
                       gpmi_bch        0        0        0    99000000          0     0  50000
                 periph2_pre           1        1        0   396000000          0     0  50000
                    periph2            2        2        0   396000000          0     0  50000
                       mmdc_podf       2        2        0   396000000          0     0  50000
                          mmdc_p0_fast       1        1        0   396000000          0     0  50000
                 axi_alt_sel           0        0        0   396000000          0     0  50000
                 pll2_198m             0        0        0   198000000          0     0  50000
              pll2_pfd1_594m           0        0        0   594000000          0     0  50000
              pll2_pfd0_352m           0        0        0   352000000          0     0  50000
     pll1                              1        1        0   900000000          0     0  50000
        pll1_bypass                    1        1        0   900000000          0     0  50000
           pll1_sys                    1        1        0   900000000          0     0  50000
              pll1_sw                  1        1        0   900000000          0     0  50000
                 arm                   1        1        0   900000000          0     0  50000
     pll7_bypass_src                   0        0        0    24000000          0     0  50000
     pll6_bypass_src                   0        0        0    24000000          0     0  50000
     pll5_bypass_src                   0        0        0    24000000          0     0  50000
     pll4_bypass_src                   0        0        0    24000000          0     0  50000
     pll3_bypass_src                   0        0        0    24000000          0     0  50000
     pll2_bypass_src                   0        0        0    24000000          0     0  50000
     pll1_bypass_src                   0        0        0    24000000          0     0  50000
  ckil                                 0        0        0       32768          0     0  50000


Note that this was generated on a normal boot up (not failure).

Running boot testing now waiting for a failure.

Regards
Greg

[-- Attachment #2: imx6-nand-trace.patch --]
[-- Type: text/x-patch, Size: 6320 bytes --]

diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
index 95ab933a10..7d6492452b 100644
--- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
+++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
@@ -423,6 +423,46 @@
 	u16 busy_timeout_cycles;
 	u8 wrn_dly_sel;
 
+	printk("%s(%d): gpmi_nfc_compute_timings()\n", __FILE__, __LINE__);
+	printk("  sdr->tBERS_max=%llu\n", sdr->tBERS_max);
+	printk("  sdr->tCCS_min=%u\n", sdr->tCCS_min);
+	printk("  sdr->tPROG_max=%llu\n", sdr->tPROG_max);
+	printk("  sdr->tR_max=%llu\n", sdr->tR_max);
+	printk("  sdr->tALH_min=%u\n", sdr->tALH_min);
+	printk("  sdr->tADL_min=%u\n", sdr->tADL_min);
+	printk("  sdr->tALS_min=%u\n", sdr->tALS_min);
+	printk("  sdr->tAR_min=%u\n", sdr->tAR_min);
+	printk("  sdr->tCEA_max=%u\n", sdr->tCEA_max);
+	printk("  sdr->tCEH_min=%u\n", sdr->tCEH_min);
+	printk("  sdr->tCH_min=%u\n", sdr->tCH_min);
+	printk("  sdr->tCHZ_max=%u\n", sdr->tCHZ_max);
+	printk("  sdr->tCLH_min=%u\n", sdr->tCLH_min);
+	printk("  sdr->tCLR_min=%u\n", sdr->tCLR_min);
+	printk("  sdr->tCLS_min=%u\n", sdr->tCLS_min);
+	printk("  sdr->tCOH_min=%u\n", sdr->tCOH_min);
+	printk("  sdr->tCS_min=%u\n", sdr->tCS_min);
+	printk("  sdr->tDH_min=%u\n", sdr->tDH_min);
+	printk("  sdr->tDS_min=%u\n", sdr->tDS_min);
+	printk("  sdr->tFEAT_max=%u\n", sdr->tFEAT_max);
+	printk("  sdr->tIR_min=%u\n", sdr->tIR_min);
+	printk("  sdr->tITC_max=%u\n", sdr->tITC_max);
+	printk("  sdr->tRC_min=%u\n", sdr->tRC_min);
+	printk("  sdr->tREA_max=%u\n", sdr->tREA_max);
+	printk("  sdr->tREH_min=%u\n", sdr->tREH_min);
+	printk("  sdr->tRHOH_min=%u\n", sdr->tRHOH_min);
+	printk("  sdr->tRHW_min=%u\n", sdr->tRHW_min);
+	printk("  sdr->tRHZ_max=%u\n", sdr->tRHZ_max);
+	printk("  sdr->tRLOH_min=%u\n", sdr->tRLOH_min);
+	printk("  sdr->tRP_min=%u\n", sdr->tRP_min);
+	printk("  sdr->tRR_min=%u\n", sdr->tRR_min);
+	printk("  sdr->tRST_max=%llu\n", sdr->tRST_max);
+	printk("  sdr->tWB_max=%u\n", sdr->tWB_max);
+	printk("  sdr->tWC_min=%u\n", sdr->tWC_min);
+	printk("  sdr->tWH_min=%u\n", sdr->tWH_min);
+	printk("  sdr->tWHR_min=%u\n", sdr->tWHR_min);
+	printk("  sdr->tWP_min=%u\n", sdr->tWP_min);
+	printk("  sdr->tWW_min=%u\n", sdr->tWW_min);
+
 	if (sdr->tRC_min >= 30000) {
 		/* ONFI non-EDO modes [0-3] */
 		hw->clk_rate = 22000000;
@@ -436,19 +476,28 @@
 		hw->clk_rate = 100000000;
 		wrn_dly_sel = BV_GPMI_CTRL1_WRN_DLY_SEL_NO_DELAY;
 	}
+	printk("    hw->clk_rate=%lu\n", hw->clk_rate);
+	printk("    wrn_dly_sel=%u\n", wrn_dly_sel);
 
 	/* SDR core timings are given in picoseconds */
 	period_ps = div_u64((u64)NSEC_PER_SEC * 1000, hw->clk_rate);
+	printk("    period_ps=%u\n", period_ps);
 
 	addr_setup_cycles = TO_CYCLES(sdr->tALS_min, period_ps);
+	printk("    addr_setup_cycles=%u\n", addr_setup_cycles);
 	data_setup_cycles = TO_CYCLES(sdr->tDS_min, period_ps);
+	printk("    data_setup_cycles=%u\n", data_setup_cycles);
 	data_hold_cycles = TO_CYCLES(sdr->tDH_min, period_ps);
+	printk("    data_hold_cycles=%u\n", data_hold_cycles);
 	busy_timeout_cycles = TO_CYCLES(sdr->tWB_max + sdr->tR_max, period_ps);
+	printk("    busy_timeout_cycles=%u\n", busy_timeout_cycles);
 
 	hw->timing0 = BF_GPMI_TIMING0_ADDRESS_SETUP(addr_setup_cycles) |
 		      BF_GPMI_TIMING0_DATA_HOLD(data_hold_cycles) |
 		      BF_GPMI_TIMING0_DATA_SETUP(data_setup_cycles);
+	printk("    hw->timing0=0x%08x\n", hw->timing0);
 	hw->timing1 = BF_GPMI_TIMING1_BUSY_TIMEOUT(busy_timeout_cycles * 4096);
+	printk("    hw->timing1=0x%08x\n", hw->timing1);
 
 	/*
 	 * Derive NFC ideal delay from {3}:
@@ -457,6 +506,7 @@
 	 *         RDN_DELAY = -----------------------
 	 *                                RP
 	 */
+	printk("    dll_threshold_ps=%u\n", dll_threshold_ps);
 	if (period_ps > dll_threshold_ps) {
 		use_half_period = true;
 		reference_period_ps = period_ps / 2;
@@ -464,19 +514,26 @@
 		use_half_period = false;
 		reference_period_ps = period_ps;
 	}
+	printk("    use_half_period=%u\n", use_half_period);
+	printk("    reference_period_ps=%u\n", reference_period_ps);
 
 	tRP_ps = data_setup_cycles * period_ps;
+	printk("    tRP_ps=%u\n", tRP_ps);
 	sample_delay_ps = (sdr->tREA_max + 4000 - tRP_ps) * 8;
+	printk("    sample_delay_ps=%u\n", sample_delay_ps);
 	if (sample_delay_ps > 0)
 		sample_delay_factor = sample_delay_ps / reference_period_ps;
 	else
 		sample_delay_factor = 0;
+	printk("    sample_delay_factor=%u\n", sample_delay_factor);
 
 	hw->ctrl1n = BF_GPMI_CTRL1_WRN_DLY_SEL(wrn_dly_sel);
+	printk("    hw->ctrl1n=0x%08x\n", hw->ctrl1n);
 	if (sample_delay_factor)
 		hw->ctrl1n |= BF_GPMI_CTRL1_RDN_DELAY(sample_delay_factor) |
 			      BM_GPMI_CTRL1_DLL_ENABLE |
 			      (use_half_period ? BM_GPMI_CTRL1_HALF_PERIOD : 0);
+	printk("    hw->ctrl1n=0x%08x\n", hw->ctrl1n);
 }
 
 void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
@@ -485,8 +542,13 @@
 	struct resources *r = &this->resources;
 	void __iomem *gpmi_regs = r->gpmi_regs;
 	unsigned int dll_wait_time_us;
+	int ret;
 
-	clk_set_rate(r->clock[0], hw->clk_rate);
+	printk("%s(%d): gpmi_nfc_apply_timings()\n", __FILE__, __LINE__);
+	printk("  hw>clk_rate=%lu\n", hw->clk_rate);
+	ret = clk_set_rate(r->clock[0], hw->clk_rate);
+	printk("  clk_set_rate(r->clock[0], hw->clk_rate)=%d\n", ret);
+	printk("  clk_get_rate(r->clock[0])=%lu\n", clk_get_rate(r->clock[0]));
 
 	writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
 	writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index ddd396e93e..73f94842e8 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -910,6 +910,7 @@ static int nand_init_data_interface(struct nand_chip *chip)
 	}
 
 	for (mode = fls(modes) - 1; mode >= 0; mode--) {
+		printk("%s(%d): checking mode=%d\n", __FILE__, __LINE__, mode);
 		ret = onfi_fill_data_interface(chip, NAND_SDR_IFACE, mode);
 		if (ret)
 			continue;
@@ -923,10 +924,12 @@ static int nand_init_data_interface(struct nand_chip *chip)
 						 &chip->data_interface);
 		if (!ret) {
 			chip->onfi_timing_mode_default = mode;
+			printk("%s(%d): BREAKING AT  mode=%d\n", __FILE__, __LINE__, mode);
 			break;
 		}
 	}
 
+	printk("%s(%d): chip->onfi_timing_mode_default=%d\n", __FILE__, __LINE__, chip->onfi_timing_mode_default);
 	return 0;
 }
 

[-- Attachment #3: Type: text/plain, Size: 144 bytes --]

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

^ permalink raw reply related	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-07-31  2:05               ` Greg Ungerer
@ 2019-07-31  6:28                 ` Boris Brezillon
  2019-08-02  7:19                   ` Greg Ungerer
  2019-08-02 12:34                   ` Greg Ungerer
  0 siblings, 2 replies; 85+ messages in thread
From: Boris Brezillon @ 2019-07-31  6:28 UTC (permalink / raw)
  To: Greg Ungerer
  Cc: s.hauer, Boris Brezillon, linux-mtd, Michael Nazzareno Trimarchi,
	Miquel Raynal

On Wed, 31 Jul 2019 12:05:44 +1000
Greg Ungerer <gerg@kernel.org> wrote:

> Hi Miquel, Boris,
> 
> On 30/7/19 6:38 pm, Miquel Raynal wrote:
> > Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:  
> >> On 30/7/19 10:41 am, Greg Ungerer wrote:  
> >>> On 30/7/19 10:28 am, Greg Ungerer wrote:  
> >>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:  
> >>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:  
> >>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:  
> >>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:  
> >>> [snip]  
> >> Not sure if this is a useful data point... But I modified that
> >> nand_init_data_interface() loop to start checking from data mode 4.
> >> So now on every boot it defaults to mode 4. That has been running
> >> most of the day, up to 900 boot cycles now, no failures.  
> > 
> > Ok so after having chatted quite a bit with Boris, it is very likely
> > that, for these chips, the timings in mode 5 are too tight. It could
> > fail the GET_FEATURES once in mode 5. Can you please dump every single
> > intermediate value in gpmi_nfc_compute_timings() (period, *_cycles,
> > use of half pêriods, tRP, sample delay, etc) as well as the content
> > of /sys/kernel/debug/clk/clk_summary (you'll need debugfs support
> > enabled and mounted).
> > 
> > Also, can you be sure that the NAND chip is powered with 3.3V?  
> 
> Yes, 3.3V NAND chip.
> 
> Using the attached patch I get the following trace:
> 
> ...
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
>    sdr->tBERS_max=65535000000
>    sdr->tCCS_min=500000000
>    sdr->tPROG_max=65535000000
>    sdr->tR_max=200000000000000
>    sdr->tALH_min=20000
>    sdr->tADL_min=400000
>    sdr->tALS_min=50000
>    sdr->tAR_min=25000
>    sdr->tCEA_max=100000
>    sdr->tCEH_min=20000
>    sdr->tCH_min=20000
>    sdr->tCHZ_max=100000
>    sdr->tCLH_min=20000
>    sdr->tCLR_min=20000
>    sdr->tCLS_min=50000
>    sdr->tCOH_min=0
>    sdr->tCS_min=70000
>    sdr->tDH_min=20000
>    sdr->tDS_min=40000
>    sdr->tFEAT_max=1000000
>    sdr->tIR_min=10000
>    sdr->tITC_max=1000000
>    sdr->tRC_min=100000
>    sdr->tREA_max=40000
>    sdr->tREH_min=30000
>    sdr->tRHOH_min=0
>    sdr->tRHW_min=200000
>    sdr->tRHZ_max=200000
>    sdr->tRLOH_min=0
>    sdr->tRP_min=50000
>    sdr->tRR_min=40000
>    sdr->tRST_max=250000000000
>    sdr->tWB_max=200000
>    sdr->tWC_min=100000
>    sdr->tWH_min=30000
>    sdr->tWHR_min=120000
>    sdr->tWP_min=50000
>    sdr->tWW_min=100000
>      hw->clk_rate=22000000
>      wrn_dly_sel=0
>      period_ps=45454
>      addr_setup_cycles=2
>      data_setup_cycles=1
>      data_hold_cycles=1
>      busy_timeout_cycles=31302
>      hw->timing0=0x00020101
>      hw->timing1=0x60000000
>      dll_threshold_ps=12000
>      use_half_period=1
>      reference_period_ps=22727
>      tRP_ps=45454
>      sample_delay_ps=4294955664
>      sample_delay_factor=0
>      hw->ctrl1n=0x00000000
>      hw->ctrl1n=0x00000000
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
>    hw>clk_rate=22000000  
>    clk_set_rate(r->clock[0], hw->clk_rate)=0
>    clk_get_rate(r->clock[0])=22000000
> random: fast init done
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron MT29F2G08ABAEAWP
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
>    sdr->tBERS_max=3000000000
>    sdr->tCCS_min=100000
>    sdr->tPROG_max=600000000
>    sdr->tR_max=25000000
>    sdr->tALH_min=20000
>    sdr->tADL_min=400000
>    sdr->tALS_min=50000
>    sdr->tAR_min=25000
>    sdr->tCEA_max=100000
>    sdr->tCEH_min=20000
>    sdr->tCH_min=20000
>    sdr->tCHZ_max=100000
>    sdr->tCLH_min=20000
>    sdr->tCLR_min=20000
>    sdr->tCLS_min=50000
>    sdr->tCOH_min=0
>    sdr->tCS_min=70000
>    sdr->tDH_min=20000
>    sdr->tDS_min=40000
>    sdr->tFEAT_max=1000000
>    sdr->tIR_min=10000
>    sdr->tITC_max=1000000
>    sdr->tRC_min=100000
>    sdr->tREA_max=40000
>    sdr->tREH_min=30000
>    sdr->tRHOH_min=0
>    sdr->tRHW_min=200000
>    sdr->tRHZ_max=200000
>    sdr->tRLOH_min=0
>    sdr->tRP_min=50000
>    sdr->tRR_min=40000
>    sdr->tRST_max=250000000000
>    sdr->tWB_max=200000
>    sdr->tWC_min=100000
>    sdr->tWH_min=30000
>    sdr->tWHR_min=120000
>    sdr->tWP_min=50000
>    sdr->tWW_min=100000
>      hw->clk_rate=22000000
>      wrn_dly_sel=0
>      period_ps=45454
>      addr_setup_cycles=2
>      data_setup_cycles=1
>      data_hold_cycles=1
>      busy_timeout_cycles=555
>      hw->timing0=0x00020101
>      hw->timing1=0xb0000000
>      dll_threshold_ps=12000
>      use_half_period=1
>      reference_period_ps=22727
>      tRP_ps=45454
>      sample_delay_ps=4294955664
>      sample_delay_factor=0
>      hw->ctrl1n=0x00000000
>      hw->ctrl1n=0x00000000
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
>    hw>clk_rate=22000000  
>    clk_set_rate(r->clock[0], hw->clk_rate)=0
>    clk_get_rate(r->clock[0])=22000000
> gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
> drivers/mtd/nand/raw/nand_base.c(913): checking mode=5
> drivers/mtd/nand/raw/nand_base.c(927): BREAKING AT  mode=5
> drivers/mtd/nand/raw/nand_base.c(932): chip->onfi_timing_mode_default=5
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
>    sdr->tBERS_max=3000000000
>    sdr->tCCS_min=100000
>    sdr->tPROG_max=600000000
>    sdr->tR_max=25000000
>    sdr->tALH_min=5000
>    sdr->tADL_min=400000
>    sdr->tALS_min=10000
>    sdr->tAR_min=10000
>    sdr->tCEA_max=25000
>    sdr->tCEH_min=20000
>    sdr->tCH_min=5000
>    sdr->tCHZ_max=30000
>    sdr->tCLH_min=5000
>    sdr->tCLR_min=10000
>    sdr->tCLS_min=10000
>    sdr->tCOH_min=15000
>    sdr->tCS_min=15000
>    sdr->tDH_min=5000
>    sdr->tDS_min=7000
>    sdr->tFEAT_max=1000000
>    sdr->tIR_min=0
>    sdr->tITC_max=1000000
>    sdr->tRC_min=20000
>    sdr->tREA_max=16000
>    sdr->tREH_min=7000
>    sdr->tRHOH_min=15000
>    sdr->tRHW_min=100000
>    sdr->tRHZ_max=100000
>    sdr->tRLOH_min=5000
>    sdr->tRP_min=10000
>    sdr->tRR_min=20000
>    sdr->tRST_max=500000000
>    sdr->tWB_max=100000
>    sdr->tWC_min=20000
>    sdr->tWH_min=7000
>    sdr->tWHR_min=80000
>    sdr->tWP_min=10000
>    sdr->tWW_min=100000
>      hw->clk_rate=100000000
>      wrn_dly_sel=3
>      period_ps=10000
>      addr_setup_cycles=1
>      data_setup_cycles=1
>      data_hold_cycles=1
>      busy_timeout_cycles=2510
>      hw->timing0=0x00010101
>      hw->timing1=0xe0000000
>      dll_threshold_ps=12000
>      use_half_period=0
>      reference_period_ps=10000
>      tRP_ps=10000
>      sample_delay_ps=80000
>      sample_delay_factor=8
>      hw->ctrl1n=0x00c00000
>      hw->ctrl1n=0x00c28000
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
>    hw>clk_rate=100000000  
>    clk_set_rate(r->clock[0], hw->clk_rate)=0
>    clk_get_rate(r->clock[0])=99000000
> Scanning device for bad blocks
> 5 fixed-partitions partitions found on MTD device gpmi-nand
> Creating 5 MTD partitions on "gpmi-nand":
> 0x000000000000-0x000000500000 : "u-boot"
> 0x000000500000-0x000000600000 : "u-boot-env"
> 0x000000600000-0x000000800000 : "log"
> 0x000000800000-0x000010000000 : "flash"
> 0x000000000000-0x000010000000 : "all"
> gpmi-nand 1806000.gpmi-nand: driver registered.
> ...
> 
> 
> And "cat /sys/kernel/debug/clk/clk_summary" gives:
> 
>                                   enable  prepare  protect                                duty
>     clock                          count    count    count        rate   accuracy phase  cycle
> ---------------------------------------------------------------------------------------------
>   dummy                                2        2        0           0          0     0  50000
>      cko2_sel                          0        0        0           0          0     0  50000
>         cko2_podf                      0        0        0           0          0     0  50000
>            cko2                        0        0        0           0          0     0  50000
>      cko1_sel                          0        0        0           0          0     0  50000
>         cko1_podf                      0        0        0           0          0     0  50000
>            cko1                        0        0        0           0          0     0  50000
>               cko                      0        0        0           0          0     0  50000
>      usbphy2_gate                      1        1        0           0          0     0  50000
>      usbphy1_gate                      1        1        0           0          0     0  50000
>   ipp_di1                              0        0        0           0          0     0  50000
>   ipp_di0                              0        0        0           0          0     0  50000
>   osc                                  6        6        0    24000000          0     0  50000
>      perclk_sel                        1        1        0    24000000          0     0  50000
>         perclk                         3        3        0    24000000          0     0  50000
>            pwm7                        0        0        0    24000000          0     0  50000
>            pwm6                        0        0        0    24000000          0     0  50000
>            pwm5                        0        0        0    24000000          0     0  50000
>            i2c4                        0        0        0    24000000          0     0  50000
>            pwm8                        0        0        0    24000000          0     0  50000
>            pwm4                        0        0        0    24000000          0     0  50000
>            pwm3                        0        0        0    24000000          0     0  50000
>            pwm2                        0        0        0    24000000          0     0  50000
>            pwm1                        0        0        0    24000000          0     0  50000
>            i2c3                        0        0        0    24000000          0     0  50000
>            i2c2                        1        1        0    24000000          0     0  50000
>            i2c1                        0        0        0    24000000          0     0  50000
>            gpt1_serial                 1        1        0    24000000          0     0  50000
>            gpt1_bus                    1        1        0    24000000          0     0  50000
>            epit2                       0        0        0    24000000          0     0  50000
>            epit1                       0        0        0    24000000          0     0  50000
>            gpt2_serial                 0        0        0    24000000          0     0  50000
>            gpt2_bus                    0        0        0    24000000          0     0  50000
>      periph_clk2_sel                   0        0        0    24000000          0     0  50000
>         periph_clk2                    0        0        0    24000000          0     0  50000
>      gpt_3m                            0        0        0     3000000          0     0  50000
>      csi_sel                           0        0        0    24000000          0     0  50000
>         csi_podf                       0        0        0    24000000          0     0  50000
>            csi                         0        0        0    24000000          0     0  50000
>      pll7                              1        1        0   480000000          0     0  50000
>         pll7_bypass                    1        1        0   480000000          0     0  50000
>            pll7_usb_host               1        1        0   480000000          0     0  50000
>               usbphy2                  1        1        0   480000000          0     0  50000
>      pll6                              1        1        0   500000000          0     0  50000
>         pll6_bypass                    1        1        0   500000000          0     0  50000
>            pll6_enet                   2        2        0   500000000          0     0  50000
>               enet_ptp_ref             1        1        0    25000000          0     0  50000
>                  enet_ptp              1        1        0    25000000          0     0  50000
>               enet2_ref                0        0        0    50000000          0     0  50000
>                  enet_ref_125m         0        0        0    50000000          0     0  50000
>               enet_ref                 2        2        0    50000000          0     0  50000
>      pll5                              0        0        0   296600000          0     0  50000
>         pll5_bypass                    0        0        0   296600000          0     0  50000
>            pll5_video                  0        0        0   296600000          0     0  50000
>               pll5_post_div            0        0        0    74150000          0     0  50000
>                  pll5_video_div        0        0        0    74150000          0     0  50000
>      pll4                              0        0        0   147456000          0     0  50000
>         pll4_bypass                    0        0        0   147456000          0     0  50000
>            pll4_audio                  0        0        0   147456000          0     0  50000
>               pll4_post_div            0        0        0    36864000          0     0  50000
>                  pll4_audio_div        0        0        0    36864000          0     0  50000
>      pll3                              1        1        0   480000000          0     0  50000
>         pll3_bypass                    1        1        0   480000000          0     0  50000
>            pll3_usb_otg                2        2        0   480000000          0     0  50000
>               spdif_sel                0        0        0   480000000          0     0  50000
>                  spdif_pred            0        0        0   240000000          0     0  50000
>                     spdif_podf         0        0        0    30000000          0     0  50000
>                        spdif           0        0        0    30000000          0     0  50000
>               esai_sel                 0        0        0   480000000          0     0  50000
>                  esai_pred             0        0        0   240000000          0     0  50000
>                     esai_podf          0        0        0    30000000          0     0  50000
>                        esai_extal       0        0        0    30000000          0     0  50000
>               qspi1_sel                0        0        0   480000000          0     0  50000
>                  qspi1_podf            0        0        0   240000000          0     0  50000
>                     qspi1              0        0        0   240000000          0     0  50000
>                  ldb_di1_div_7         0        0        0    68571428          0     0  50000
>                     ldb_di1            0        0        0    68571428          0     0  50000
>                  ldb_di1_div_3_5       0        0        0   137142857          0     0  50000
>               periph2_clk2_sel         0        0        0   480000000          0     0  50000
>                  periph2_clk2          0        0        0   480000000          0     0  50000
>               pll3_60m                 0        0        0    60000000          0     0  50000
>                  can_sel               0        0        0    60000000          0     0  50000
>                     can_podf           0        0        0    30000000          0     0  50000
>                        can2_serial       0        0        0    30000000          0     0  50000
>                        can1_serial       0        0        0    30000000          0     0  50000
>                  ecspi_sel             0        0        0    60000000          0     0  50000
>                     ecspi_podf         0        0        0    60000000          0     0  50000
>                        ecspi4          0        0        0    60000000          0     0  50000
>                        ecspi3          0        0        0    60000000          0     0  50000
>                        ecspi2          0        0        0    60000000          0     0  50000
>                        ecspi1          0        0        0    60000000          0     0  50000
>               pll3_80m                 1        1        0    80000000          0     0  50000
>                  uart_sel              1        1        0    80000000          0     0  50000
>                     uart_podf          1        1        0    80000000          0     0  50000
>                        uart8_serial       0        0        0    80000000          0     0  50000
>                        uart7_serial       0        0        0    80000000          0     0  50000
>                        uart1_serial       1        2        0    80000000          0     0  50000
>                        uart6_serial       0        0        0    80000000          0     0  50000
>                        uart5_serial       0        0        0    80000000          0     0  50000
>                        uart4_serial       0        0        0    80000000          0     0  50000
>                        uart3_serial       0        0        0    80000000          0     0  50000
>                        uart2_serial       0        0        0    80000000          0     0  50000
>               pll3_pfd3_454m           0        0        0   454736842          0     0  50000
>               pll3_pfd2_508m           0        0        0   508235294          0     0  50000
>                  epdc_pre_sel          0        0        0   508235294          0     0  50000
>                     epdc_podf          0        0        0   254117647          0     0  50000
>                        epdc_pix        0        0        0   254117647          0     0  50000
>                        epdc_sel        0        0        0   254117647          0     0  50000
>                  sai1_sel              0        0        0   508235294          0     0  50000
>                     sai1_pred          0        0        0   127058824          0     0  50000
>                        sai1_podf       0        0        0    63529412          0     0  50000
>                           sai1         0        0        0    63529412          0     0  50000
>                  sai2_sel              0        0        0   508235294          0     0  50000
>                     sai2_pred          0        0        0   127058824          0     0  50000
>                        sai2_podf       0        0        0    63529412          0     0  50000
>                           sai2         0        0        0    63529412          0     0  50000
>                  sai3_sel              0        0        0   508235294          0     0  50000
>                     sai3_pred          0        0        0   127058824          0     0  50000
>                        sai3_podf       0        0        0    63529412          0     0  50000
>                           sai3         0        0        0    63529412          0     0  50000
>               pll3_pfd1_540m           0        0        0   540000000          0     0  50000
>                  lcdif_pre_sel         0        0        0   540000000          0     0  50000
>                     lcdif_pred         0        0        0   270000000          0     0  50000
>                        lcdif_podf       0        0        0   135000000          0     0  50000
>                           lcdif_pix       0        0        0   135000000          0     0  50000
>                           iomuxc       0        0        0   135000000          0     0  50000
>                           lcdif_sel       0        0        0   135000000          0     0  50000
>               pll3_pfd0_720m           0        0        0   720000000          0     0  50000
>               usbphy1                  1        1        0   480000000          0     0  50000
>      pll2                              1        1        0   528000000          0     0  50000
>         pll2_bypass                    1        1        0   528000000          0     0  50000
>            pll2_bus                    2        2        0   528000000          0     0  50000
>               ca7_secondary_sel        0        0        0   528000000          0     0  50000
>                  step                  0        0        0   528000000          0     0  50000
>               periph_pre               1        1        0   528000000          0     0  50000
>                  periph                3        3        0   528000000          0     0  50000
>                     ahb                7        7        0   132000000          0     0  50000
>                        sdma            0        0        0   132000000          0     0  50000
>                        rom             1        1        0   132000000          0     0  50000
>                        esai_mem        0        0        0   132000000          0     0  50000
>                        esai_ipg        0        0        0   132000000          0     0  50000
>                        aips_tz3        1        1        0   132000000          0     0  50000
>                        enet_ahb        2        2        0   132000000          0     0  50000
>                        dcp             0        0        0   132000000          0     0  50000
>                        asrc_mem        0        0        0   132000000          0     0  50000
>                        asrc_ipg        0        0        0   132000000          0     0  50000
>                        aips_tz2        1        1        0   132000000          0     0  50000
>                        aips_tz1        1        1        0   132000000          0     0  50000
>                        ipg            10       10        0    66000000          0     0  50000
>                           wdog3        0        0        0    66000000          0     0  50000
>                           uart8_ipg       0        0        0    66000000          0     0  50000
>                           usboh3       2        2        0    66000000          0     0  50000
>                           sai2_ipg       0        0        0    66000000          0     0  50000
>                           sai1_ipg       0        0        0    66000000          0     0  50000
>                           uart7_ipg       0        0        0    66000000          0     0  50000
>                           uart1_ipg       1        2        0    66000000          0     0  50000
>                           sai3_ipg       0        0        0    66000000          0     0  50000
>                           spdif_gclk       0        0        0    66000000          0     0  50000
>                           spba         0        0        0    66000000          0     0  50000
>                           wdog2        0        0        0    66000000          0     0  50000
>                           kpp          0        0        0    66000000          0     0  50000
>                           mmdc_p1_ipg       0        0        0    66000000          0     0  50000
>                           mmdc_p0_ipg       2        2        0    66000000          0     0  50000
>                           wdog1        1        1        0    66000000          0     0  50000
>                           gpio4        1        1        0    66000000          0     0  50000
>                           uart6_ipg       0        0        0    66000000          0     0  50000
>                           uart5_ipg       0        0        0    66000000          0     0  50000
>                           gpio3        1        1        0    66000000          0     0  50000
>                           ocotp        0        0        0    66000000          0     0  50000
>                           gpio5        1        1        0    66000000          0     0  50000
>                           gpio1        1        1        0    66000000          0     0  50000
>                           uart4_ipg       0        0        0    66000000          0     0  50000
>                           adc1         0        0        0    66000000          0     0  50000
>                           uart3_ipg       0        0        0    66000000          0     0  50000
>                           adc2         0        0        0    66000000          0     0  50000
>                           gpio2        1        1        0    66000000          0     0  50000
>                           uart2_ipg       0        0        0    66000000          0     0  50000
>                           can2_ipg       0        0        0    66000000          0     0  50000
>                           can1_ipg       0        0        0    66000000          0     0  50000
>                           enet         2        2        0    66000000          0     0  50000
>                     axi_sel            1        1        0   528000000          0     0  50000
>                        axi_podf        2        2        0   264000000          0     0  50000
>                           axi          1        1        0   264000000          0     0  50000
>                              eim_slow_sel       0        0        0   264000000          0     0  50000
>                                 eim_slow_podf       0        0        0   132000000          0     0  50000
>                                    eim       0        0        0   132000000          0     0  50000
>                              lcdif_apb       0        0        0   264000000          0     0  50000
>                              pxp       0        0        0   264000000          0     0  50000
>                              epdc_aclk       0        0        0   264000000          0     0  50000
>               pll2_pfd3_594m           0        0        0   594000000          0     0  50000
>                  ldb_di0_sel           0        0        0   594000000          0     0  50000
>                     ldb_di0_div_7       0        0        0    84857142          0     0  50000
>                        ldb_di0         0        0        0    84857142          0     0  50000
>                     ldb_di0_div_3_5       0        0        0   169714285          0     0  50000
>               pll2_pfd2_396m           2        2        0   396000000          0     0  50000
>                  enfc_sel              0        0        0   396000000          0     0  50000
>                     enfc_pred          0        0        0    99000000          0     0  50000
>                        enfc_podf       0        0        0    99000000          0     0  50000
>                           gpmi_io       0        0        0    99000000          0     0  50000
>                  usdhc1_sel            0        0        0   396000000          0     0  50000
>                     usdhc1_podf        0        0        0   198000000          0     0  50000
>                        usdhc1          0        0        0   198000000          0     0  50000
>                  usdhc2_sel            0        0        0   396000000          0     0  50000
>                     usdhc2_podf        0        0        0   198000000          0     0  50000
>                        usdhc2          0        0        0   198000000          0     0  50000
>                  bch_sel               1        1        0   396000000          0     0  50000
>                     bch_podf           1        1        0    99000000          0     0  50000
>                        gpmi_apb        0        0        0    99000000          0     0  50000
>                        gpmi_bch_apb       0        0        0    99000000          0     0  50000
>                        per_bch         0        0        0    99000000          0     0  50000
>                        apbh_dma        1        1        0    99000000          0     0  50000
>                  gpmi_sel              0        0        0   396000000          0     0  50000
>                     gpmi_podf          0        0        0    99000000          0     0  50000
>                        gpmi_bch        0        0        0    99000000          0     0  50000
>                  periph2_pre           1        1        0   396000000          0     0  50000
>                     periph2            2        2        0   396000000          0     0  50000
>                        mmdc_podf       2        2        0   396000000          0     0  50000
>                           mmdc_p0_fast       1        1        0   396000000          0     0  50000
>                  axi_alt_sel           0        0        0   396000000          0     0  50000
>                  pll2_198m             0        0        0   198000000          0     0  50000
>               pll2_pfd1_594m           0        0        0   594000000          0     0  50000
>               pll2_pfd0_352m           0        0        0   352000000          0     0  50000
>      pll1                              1        1        0   900000000          0     0  50000
>         pll1_bypass                    1        1        0   900000000          0     0  50000
>            pll1_sys                    1        1        0   900000000          0     0  50000
>               pll1_sw                  1        1        0   900000000          0     0  50000
>                  arm                   1        1        0   900000000          0     0  50000
>      pll7_bypass_src                   0        0        0    24000000          0     0  50000
>      pll6_bypass_src                   0        0        0    24000000          0     0  50000
>      pll5_bypass_src                   0        0        0    24000000          0     0  50000
>      pll4_bypass_src                   0        0        0    24000000          0     0  50000
>      pll3_bypass_src                   0        0        0    24000000          0     0  50000
>      pll2_bypass_src                   0        0        0    24000000          0     0  50000
>      pll1_bypass_src                   0        0        0    24000000          0     0  50000
>   ckil                                 0        0        0       32768          0     0  50000
> 
> 
> Note that this was generated on a normal boot up (not failure).

The values looks good. Can you try with the below diff applied?
--->8---
diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
index 334fe3130285..9771f6a82abe 100644
--- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
@@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
        writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
 
        /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
-       dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
-       if (!dll_wait_time_us)
-               dll_wait_time_us = 1;
+       dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
 
        /* Wait for the DLL to settle. */
-       udelay(dll_wait_time_us);
+       usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
 }
 
 static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,

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

^ permalink raw reply related	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-07-31  6:28                 ` Boris Brezillon
@ 2019-08-02  7:19                   ` Greg Ungerer
  2019-08-02 12:34                   ` Greg Ungerer
  1 sibling, 0 replies; 85+ messages in thread
From: Greg Ungerer @ 2019-08-02  7:19 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: s.hauer, Boris Brezillon, linux-mtd, Michael Nazzareno Trimarchi,
	Miquel Raynal

Hi Boris,

On 31/7/19 4:28 pm, Boris Brezillon wrote:
> On Wed, 31 Jul 2019 12:05:44 +1000
> Greg Ungerer <gerg@kernel.org> wrote:
> 
>> Hi Miquel, Boris,
>>
>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>>>> [snip]
>>>> Not sure if this is a useful data point... But I modified that
>>>> nand_init_data_interface() loop to start checking from data mode 4.
>>>> So now on every boot it defaults to mode 4. That has been running
>>>> most of the day, up to 900 boot cycles now, no failures.
>>>
>>> Ok so after having chatted quite a bit with Boris, it is very likely
>>> that, for these chips, the timings in mode 5 are too tight. It could
>>> fail the GET_FEATURES once in mode 5. Can you please dump every single
>>> intermediate value in gpmi_nfc_compute_timings() (period, *_cycles,
>>> use of half pêriods, tRP, sample delay, etc) as well as the content
>>> of /sys/kernel/debug/clk/clk_summary (you'll need debugfs support
>>> enabled and mounted).
>>>
>>> Also, can you be sure that the NAND chip is powered with 3.3V?
>>
>> Yes, 3.3V NAND chip.
>>
>> Using the attached patch I get the following trace:
>>
>> ...
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
>>     sdr->tBERS_max=65535000000
>>     sdr->tCCS_min=500000000
>>     sdr->tPROG_max=65535000000
>>     sdr->tR_max=200000000000000
>>     sdr->tALH_min=20000
>>     sdr->tADL_min=400000
>>     sdr->tALS_min=50000
>>     sdr->tAR_min=25000
>>     sdr->tCEA_max=100000
>>     sdr->tCEH_min=20000
>>     sdr->tCH_min=20000
>>     sdr->tCHZ_max=100000
>>     sdr->tCLH_min=20000
>>     sdr->tCLR_min=20000
>>     sdr->tCLS_min=50000
>>     sdr->tCOH_min=0
>>     sdr->tCS_min=70000
>>     sdr->tDH_min=20000
>>     sdr->tDS_min=40000
>>     sdr->tFEAT_max=1000000
>>     sdr->tIR_min=10000
>>     sdr->tITC_max=1000000
>>     sdr->tRC_min=100000
>>     sdr->tREA_max=40000
>>     sdr->tREH_min=30000
>>     sdr->tRHOH_min=0
>>     sdr->tRHW_min=200000
>>     sdr->tRHZ_max=200000
>>     sdr->tRLOH_min=0
>>     sdr->tRP_min=50000
>>     sdr->tRR_min=40000
>>     sdr->tRST_max=250000000000
>>     sdr->tWB_max=200000
>>     sdr->tWC_min=100000
>>     sdr->tWH_min=30000
>>     sdr->tWHR_min=120000
>>     sdr->tWP_min=50000
>>     sdr->tWW_min=100000
>>       hw->clk_rate=22000000
>>       wrn_dly_sel=0
>>       period_ps=45454
>>       addr_setup_cycles=2
>>       data_setup_cycles=1
>>       data_hold_cycles=1
>>       busy_timeout_cycles=31302
>>       hw->timing0=0x00020101
>>       hw->timing1=0x60000000
>>       dll_threshold_ps=12000
>>       use_half_period=1
>>       reference_period_ps=22727
>>       tRP_ps=45454
>>       sample_delay_ps=4294955664
>>       sample_delay_factor=0
>>       hw->ctrl1n=0x00000000
>>       hw->ctrl1n=0x00000000
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
>>     hw>clk_rate=22000000
>>     clk_set_rate(r->clock[0], hw->clk_rate)=0
>>     clk_get_rate(r->clock[0])=22000000
>> random: fast init done
>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>> nand: Micron MT29F2G08ABAEAWP
>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
>>     sdr->tBERS_max=3000000000
>>     sdr->tCCS_min=100000
>>     sdr->tPROG_max=600000000
>>     sdr->tR_max=25000000
>>     sdr->tALH_min=20000
>>     sdr->tADL_min=400000
>>     sdr->tALS_min=50000
>>     sdr->tAR_min=25000
>>     sdr->tCEA_max=100000
>>     sdr->tCEH_min=20000
>>     sdr->tCH_min=20000
>>     sdr->tCHZ_max=100000
>>     sdr->tCLH_min=20000
>>     sdr->tCLR_min=20000
>>     sdr->tCLS_min=50000
>>     sdr->tCOH_min=0
>>     sdr->tCS_min=70000
>>     sdr->tDH_min=20000
>>     sdr->tDS_min=40000
>>     sdr->tFEAT_max=1000000
>>     sdr->tIR_min=10000
>>     sdr->tITC_max=1000000
>>     sdr->tRC_min=100000
>>     sdr->tREA_max=40000
>>     sdr->tREH_min=30000
>>     sdr->tRHOH_min=0
>>     sdr->tRHW_min=200000
>>     sdr->tRHZ_max=200000
>>     sdr->tRLOH_min=0
>>     sdr->tRP_min=50000
>>     sdr->tRR_min=40000
>>     sdr->tRST_max=250000000000
>>     sdr->tWB_max=200000
>>     sdr->tWC_min=100000
>>     sdr->tWH_min=30000
>>     sdr->tWHR_min=120000
>>     sdr->tWP_min=50000
>>     sdr->tWW_min=100000
>>       hw->clk_rate=22000000
>>       wrn_dly_sel=0
>>       period_ps=45454
>>       addr_setup_cycles=2
>>       data_setup_cycles=1
>>       data_hold_cycles=1
>>       busy_timeout_cycles=555
>>       hw->timing0=0x00020101
>>       hw->timing1=0xb0000000
>>       dll_threshold_ps=12000
>>       use_half_period=1
>>       reference_period_ps=22727
>>       tRP_ps=45454
>>       sample_delay_ps=4294955664
>>       sample_delay_factor=0
>>       hw->ctrl1n=0x00000000
>>       hw->ctrl1n=0x00000000
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
>>     hw>clk_rate=22000000
>>     clk_set_rate(r->clock[0], hw->clk_rate)=0
>>     clk_get_rate(r->clock[0])=22000000
>> gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
>> drivers/mtd/nand/raw/nand_base.c(913): checking mode=5
>> drivers/mtd/nand/raw/nand_base.c(927): BREAKING AT  mode=5
>> drivers/mtd/nand/raw/nand_base.c(932): chip->onfi_timing_mode_default=5
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
>>     sdr->tBERS_max=3000000000
>>     sdr->tCCS_min=100000
>>     sdr->tPROG_max=600000000
>>     sdr->tR_max=25000000
>>     sdr->tALH_min=5000
>>     sdr->tADL_min=400000
>>     sdr->tALS_min=10000
>>     sdr->tAR_min=10000
>>     sdr->tCEA_max=25000
>>     sdr->tCEH_min=20000
>>     sdr->tCH_min=5000
>>     sdr->tCHZ_max=30000
>>     sdr->tCLH_min=5000
>>     sdr->tCLR_min=10000
>>     sdr->tCLS_min=10000
>>     sdr->tCOH_min=15000
>>     sdr->tCS_min=15000
>>     sdr->tDH_min=5000
>>     sdr->tDS_min=7000
>>     sdr->tFEAT_max=1000000
>>     sdr->tIR_min=0
>>     sdr->tITC_max=1000000
>>     sdr->tRC_min=20000
>>     sdr->tREA_max=16000
>>     sdr->tREH_min=7000
>>     sdr->tRHOH_min=15000
>>     sdr->tRHW_min=100000
>>     sdr->tRHZ_max=100000
>>     sdr->tRLOH_min=5000
>>     sdr->tRP_min=10000
>>     sdr->tRR_min=20000
>>     sdr->tRST_max=500000000
>>     sdr->tWB_max=100000
>>     sdr->tWC_min=20000
>>     sdr->tWH_min=7000
>>     sdr->tWHR_min=80000
>>     sdr->tWP_min=10000
>>     sdr->tWW_min=100000
>>       hw->clk_rate=100000000
>>       wrn_dly_sel=3
>>       period_ps=10000
>>       addr_setup_cycles=1
>>       data_setup_cycles=1
>>       data_hold_cycles=1
>>       busy_timeout_cycles=2510
>>       hw->timing0=0x00010101
>>       hw->timing1=0xe0000000
>>       dll_threshold_ps=12000
>>       use_half_period=0
>>       reference_period_ps=10000
>>       tRP_ps=10000
>>       sample_delay_ps=80000
>>       sample_delay_factor=8
>>       hw->ctrl1n=0x00c00000
>>       hw->ctrl1n=0x00c28000
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
>>     hw>clk_rate=100000000
>>     clk_set_rate(r->clock[0], hw->clk_rate)=0
>>     clk_get_rate(r->clock[0])=99000000
>> Scanning device for bad blocks
>> 5 fixed-partitions partitions found on MTD device gpmi-nand
>> Creating 5 MTD partitions on "gpmi-nand":
>> 0x000000000000-0x000000500000 : "u-boot"
>> 0x000000500000-0x000000600000 : "u-boot-env"
>> 0x000000600000-0x000000800000 : "log"
>> 0x000000800000-0x000010000000 : "flash"
>> 0x000000000000-0x000010000000 : "all"
>> gpmi-nand 1806000.gpmi-nand: driver registered.
>> ...
>>
>>
>> And "cat /sys/kernel/debug/clk/clk_summary" gives:
>>
>>                                    enable  prepare  protect                                duty
>>      clock                          count    count    count        rate   accuracy phase  cycle
>> ---------------------------------------------------------------------------------------------
>>    dummy                                2        2        0           0          0     0  50000
>>       cko2_sel                          0        0        0           0          0     0  50000
>>          cko2_podf                      0        0        0           0          0     0  50000
>>             cko2                        0        0        0           0          0     0  50000
>>       cko1_sel                          0        0        0           0          0     0  50000
>>          cko1_podf                      0        0        0           0          0     0  50000
>>             cko1                        0        0        0           0          0     0  50000
>>                cko                      0        0        0           0          0     0  50000
>>       usbphy2_gate                      1        1        0           0          0     0  50000
>>       usbphy1_gate                      1        1        0           0          0     0  50000
>>    ipp_di1                              0        0        0           0          0     0  50000
>>    ipp_di0                              0        0        0           0          0     0  50000
>>    osc                                  6        6        0    24000000          0     0  50000
>>       perclk_sel                        1        1        0    24000000          0     0  50000
>>          perclk                         3        3        0    24000000          0     0  50000
>>             pwm7                        0        0        0    24000000          0     0  50000
>>             pwm6                        0        0        0    24000000          0     0  50000
>>             pwm5                        0        0        0    24000000          0     0  50000
>>             i2c4                        0        0        0    24000000          0     0  50000
>>             pwm8                        0        0        0    24000000          0     0  50000
>>             pwm4                        0        0        0    24000000          0     0  50000
>>             pwm3                        0        0        0    24000000          0     0  50000
>>             pwm2                        0        0        0    24000000          0     0  50000
>>             pwm1                        0        0        0    24000000          0     0  50000
>>             i2c3                        0        0        0    24000000          0     0  50000
>>             i2c2                        1        1        0    24000000          0     0  50000
>>             i2c1                        0        0        0    24000000          0     0  50000
>>             gpt1_serial                 1        1        0    24000000          0     0  50000
>>             gpt1_bus                    1        1        0    24000000          0     0  50000
>>             epit2                       0        0        0    24000000          0     0  50000
>>             epit1                       0        0        0    24000000          0     0  50000
>>             gpt2_serial                 0        0        0    24000000          0     0  50000
>>             gpt2_bus                    0        0        0    24000000          0     0  50000
>>       periph_clk2_sel                   0        0        0    24000000          0     0  50000
>>          periph_clk2                    0        0        0    24000000          0     0  50000
>>       gpt_3m                            0        0        0     3000000          0     0  50000
>>       csi_sel                           0        0        0    24000000          0     0  50000
>>          csi_podf                       0        0        0    24000000          0     0  50000
>>             csi                         0        0        0    24000000          0     0  50000
>>       pll7                              1        1        0   480000000          0     0  50000
>>          pll7_bypass                    1        1        0   480000000          0     0  50000
>>             pll7_usb_host               1        1        0   480000000          0     0  50000
>>                usbphy2                  1        1        0   480000000          0     0  50000
>>       pll6                              1        1        0   500000000          0     0  50000
>>          pll6_bypass                    1        1        0   500000000          0     0  50000
>>             pll6_enet                   2        2        0   500000000          0     0  50000
>>                enet_ptp_ref             1        1        0    25000000          0     0  50000
>>                   enet_ptp              1        1        0    25000000          0     0  50000
>>                enet2_ref                0        0        0    50000000          0     0  50000
>>                   enet_ref_125m         0        0        0    50000000          0     0  50000
>>                enet_ref                 2        2        0    50000000          0     0  50000
>>       pll5                              0        0        0   296600000          0     0  50000
>>          pll5_bypass                    0        0        0   296600000          0     0  50000
>>             pll5_video                  0        0        0   296600000          0     0  50000
>>                pll5_post_div            0        0        0    74150000          0     0  50000
>>                   pll5_video_div        0        0        0    74150000          0     0  50000
>>       pll4                              0        0        0   147456000          0     0  50000
>>          pll4_bypass                    0        0        0   147456000          0     0  50000
>>             pll4_audio                  0        0        0   147456000          0     0  50000
>>                pll4_post_div            0        0        0    36864000          0     0  50000
>>                   pll4_audio_div        0        0        0    36864000          0     0  50000
>>       pll3                              1        1        0   480000000          0     0  50000
>>          pll3_bypass                    1        1        0   480000000          0     0  50000
>>             pll3_usb_otg                2        2        0   480000000          0     0  50000
>>                spdif_sel                0        0        0   480000000          0     0  50000
>>                   spdif_pred            0        0        0   240000000          0     0  50000
>>                      spdif_podf         0        0        0    30000000          0     0  50000
>>                         spdif           0        0        0    30000000          0     0  50000
>>                esai_sel                 0        0        0   480000000          0     0  50000
>>                   esai_pred             0        0        0   240000000          0     0  50000
>>                      esai_podf          0        0        0    30000000          0     0  50000
>>                         esai_extal       0        0        0    30000000          0     0  50000
>>                qspi1_sel                0        0        0   480000000          0     0  50000
>>                   qspi1_podf            0        0        0   240000000          0     0  50000
>>                      qspi1              0        0        0   240000000          0     0  50000
>>                   ldb_di1_div_7         0        0        0    68571428          0     0  50000
>>                      ldb_di1            0        0        0    68571428          0     0  50000
>>                   ldb_di1_div_3_5       0        0        0   137142857          0     0  50000
>>                periph2_clk2_sel         0        0        0   480000000          0     0  50000
>>                   periph2_clk2          0        0        0   480000000          0     0  50000
>>                pll3_60m                 0        0        0    60000000          0     0  50000
>>                   can_sel               0        0        0    60000000          0     0  50000
>>                      can_podf           0        0        0    30000000          0     0  50000
>>                         can2_serial       0        0        0    30000000          0     0  50000
>>                         can1_serial       0        0        0    30000000          0     0  50000
>>                   ecspi_sel             0        0        0    60000000          0     0  50000
>>                      ecspi_podf         0        0        0    60000000          0     0  50000
>>                         ecspi4          0        0        0    60000000          0     0  50000
>>                         ecspi3          0        0        0    60000000          0     0  50000
>>                         ecspi2          0        0        0    60000000          0     0  50000
>>                         ecspi1          0        0        0    60000000          0     0  50000
>>                pll3_80m                 1        1        0    80000000          0     0  50000
>>                   uart_sel              1        1        0    80000000          0     0  50000
>>                      uart_podf          1        1        0    80000000          0     0  50000
>>                         uart8_serial       0        0        0    80000000          0     0  50000
>>                         uart7_serial       0        0        0    80000000          0     0  50000
>>                         uart1_serial       1        2        0    80000000          0     0  50000
>>                         uart6_serial       0        0        0    80000000          0     0  50000
>>                         uart5_serial       0        0        0    80000000          0     0  50000
>>                         uart4_serial       0        0        0    80000000          0     0  50000
>>                         uart3_serial       0        0        0    80000000          0     0  50000
>>                         uart2_serial       0        0        0    80000000          0     0  50000
>>                pll3_pfd3_454m           0        0        0   454736842          0     0  50000
>>                pll3_pfd2_508m           0        0        0   508235294          0     0  50000
>>                   epdc_pre_sel          0        0        0   508235294          0     0  50000
>>                      epdc_podf          0        0        0   254117647          0     0  50000
>>                         epdc_pix        0        0        0   254117647          0     0  50000
>>                         epdc_sel        0        0        0   254117647          0     0  50000
>>                   sai1_sel              0        0        0   508235294          0     0  50000
>>                      sai1_pred          0        0        0   127058824          0     0  50000
>>                         sai1_podf       0        0        0    63529412          0     0  50000
>>                            sai1         0        0        0    63529412          0     0  50000
>>                   sai2_sel              0        0        0   508235294          0     0  50000
>>                      sai2_pred          0        0        0   127058824          0     0  50000
>>                         sai2_podf       0        0        0    63529412          0     0  50000
>>                            sai2         0        0        0    63529412          0     0  50000
>>                   sai3_sel              0        0        0   508235294          0     0  50000
>>                      sai3_pred          0        0        0   127058824          0     0  50000
>>                         sai3_podf       0        0        0    63529412          0     0  50000
>>                            sai3         0        0        0    63529412          0     0  50000
>>                pll3_pfd1_540m           0        0        0   540000000          0     0  50000
>>                   lcdif_pre_sel         0        0        0   540000000          0     0  50000
>>                      lcdif_pred         0        0        0   270000000          0     0  50000
>>                         lcdif_podf       0        0        0   135000000          0     0  50000
>>                            lcdif_pix       0        0        0   135000000          0     0  50000
>>                            iomuxc       0        0        0   135000000          0     0  50000
>>                            lcdif_sel       0        0        0   135000000          0     0  50000
>>                pll3_pfd0_720m           0        0        0   720000000          0     0  50000
>>                usbphy1                  1        1        0   480000000          0     0  50000
>>       pll2                              1        1        0   528000000          0     0  50000
>>          pll2_bypass                    1        1        0   528000000          0     0  50000
>>             pll2_bus                    2        2        0   528000000          0     0  50000
>>                ca7_secondary_sel        0        0        0   528000000          0     0  50000
>>                   step                  0        0        0   528000000          0     0  50000
>>                periph_pre               1        1        0   528000000          0     0  50000
>>                   periph                3        3        0   528000000          0     0  50000
>>                      ahb                7        7        0   132000000          0     0  50000
>>                         sdma            0        0        0   132000000          0     0  50000
>>                         rom             1        1        0   132000000          0     0  50000
>>                         esai_mem        0        0        0   132000000          0     0  50000
>>                         esai_ipg        0        0        0   132000000          0     0  50000
>>                         aips_tz3        1        1        0   132000000          0     0  50000
>>                         enet_ahb        2        2        0   132000000          0     0  50000
>>                         dcp             0        0        0   132000000          0     0  50000
>>                         asrc_mem        0        0        0   132000000          0     0  50000
>>                         asrc_ipg        0        0        0   132000000          0     0  50000
>>                         aips_tz2        1        1        0   132000000          0     0  50000
>>                         aips_tz1        1        1        0   132000000          0     0  50000
>>                         ipg            10       10        0    66000000          0     0  50000
>>                            wdog3        0        0        0    66000000          0     0  50000
>>                            uart8_ipg       0        0        0    66000000          0     0  50000
>>                            usboh3       2        2        0    66000000          0     0  50000
>>                            sai2_ipg       0        0        0    66000000          0     0  50000
>>                            sai1_ipg       0        0        0    66000000          0     0  50000
>>                            uart7_ipg       0        0        0    66000000          0     0  50000
>>                            uart1_ipg       1        2        0    66000000          0     0  50000
>>                            sai3_ipg       0        0        0    66000000          0     0  50000
>>                            spdif_gclk       0        0        0    66000000          0     0  50000
>>                            spba         0        0        0    66000000          0     0  50000
>>                            wdog2        0        0        0    66000000          0     0  50000
>>                            kpp          0        0        0    66000000          0     0  50000
>>                            mmdc_p1_ipg       0        0        0    66000000          0     0  50000
>>                            mmdc_p0_ipg       2        2        0    66000000          0     0  50000
>>                            wdog1        1        1        0    66000000          0     0  50000
>>                            gpio4        1        1        0    66000000          0     0  50000
>>                            uart6_ipg       0        0        0    66000000          0     0  50000
>>                            uart5_ipg       0        0        0    66000000          0     0  50000
>>                            gpio3        1        1        0    66000000          0     0  50000
>>                            ocotp        0        0        0    66000000          0     0  50000
>>                            gpio5        1        1        0    66000000          0     0  50000
>>                            gpio1        1        1        0    66000000          0     0  50000
>>                            uart4_ipg       0        0        0    66000000          0     0  50000
>>                            adc1         0        0        0    66000000          0     0  50000
>>                            uart3_ipg       0        0        0    66000000          0     0  50000
>>                            adc2         0        0        0    66000000          0     0  50000
>>                            gpio2        1        1        0    66000000          0     0  50000
>>                            uart2_ipg       0        0        0    66000000          0     0  50000
>>                            can2_ipg       0        0        0    66000000          0     0  50000
>>                            can1_ipg       0        0        0    66000000          0     0  50000
>>                            enet         2        2        0    66000000          0     0  50000
>>                      axi_sel            1        1        0   528000000          0     0  50000
>>                         axi_podf        2        2        0   264000000          0     0  50000
>>                            axi          1        1        0   264000000          0     0  50000
>>                               eim_slow_sel       0        0        0   264000000          0     0  50000
>>                                  eim_slow_podf       0        0        0   132000000          0     0  50000
>>                                     eim       0        0        0   132000000          0     0  50000
>>                               lcdif_apb       0        0        0   264000000          0     0  50000
>>                               pxp       0        0        0   264000000          0     0  50000
>>                               epdc_aclk       0        0        0   264000000          0     0  50000
>>                pll2_pfd3_594m           0        0        0   594000000          0     0  50000
>>                   ldb_di0_sel           0        0        0   594000000          0     0  50000
>>                      ldb_di0_div_7       0        0        0    84857142          0     0  50000
>>                         ldb_di0         0        0        0    84857142          0     0  50000
>>                      ldb_di0_div_3_5       0        0        0   169714285          0     0  50000
>>                pll2_pfd2_396m           2        2        0   396000000          0     0  50000
>>                   enfc_sel              0        0        0   396000000          0     0  50000
>>                      enfc_pred          0        0        0    99000000          0     0  50000
>>                         enfc_podf       0        0        0    99000000          0     0  50000
>>                            gpmi_io       0        0        0    99000000          0     0  50000
>>                   usdhc1_sel            0        0        0   396000000          0     0  50000
>>                      usdhc1_podf        0        0        0   198000000          0     0  50000
>>                         usdhc1          0        0        0   198000000          0     0  50000
>>                   usdhc2_sel            0        0        0   396000000          0     0  50000
>>                      usdhc2_podf        0        0        0   198000000          0     0  50000
>>                         usdhc2          0        0        0   198000000          0     0  50000
>>                   bch_sel               1        1        0   396000000          0     0  50000
>>                      bch_podf           1        1        0    99000000          0     0  50000
>>                         gpmi_apb        0        0        0    99000000          0     0  50000
>>                         gpmi_bch_apb       0        0        0    99000000          0     0  50000
>>                         per_bch         0        0        0    99000000          0     0  50000
>>                         apbh_dma        1        1        0    99000000          0     0  50000
>>                   gpmi_sel              0        0        0   396000000          0     0  50000
>>                      gpmi_podf          0        0        0    99000000          0     0  50000
>>                         gpmi_bch        0        0        0    99000000          0     0  50000
>>                   periph2_pre           1        1        0   396000000          0     0  50000
>>                      periph2            2        2        0   396000000          0     0  50000
>>                         mmdc_podf       2        2        0   396000000          0     0  50000
>>                            mmdc_p0_fast       1        1        0   396000000          0     0  50000
>>                   axi_alt_sel           0        0        0   396000000          0     0  50000
>>                   pll2_198m             0        0        0   198000000          0     0  50000
>>                pll2_pfd1_594m           0        0        0   594000000          0     0  50000
>>                pll2_pfd0_352m           0        0        0   352000000          0     0  50000
>>       pll1                              1        1        0   900000000          0     0  50000
>>          pll1_bypass                    1        1        0   900000000          0     0  50000
>>             pll1_sys                    1        1        0   900000000          0     0  50000
>>                pll1_sw                  1        1        0   900000000          0     0  50000
>>                   arm                   1        1        0   900000000          0     0  50000
>>       pll7_bypass_src                   0        0        0    24000000          0     0  50000
>>       pll6_bypass_src                   0        0        0    24000000          0     0  50000
>>       pll5_bypass_src                   0        0        0    24000000          0     0  50000
>>       pll4_bypass_src                   0        0        0    24000000          0     0  50000
>>       pll3_bypass_src                   0        0        0    24000000          0     0  50000
>>       pll2_bypass_src                   0        0        0    24000000          0     0  50000
>>       pll1_bypass_src                   0        0        0    24000000          0     0  50000
>>    ckil                                 0        0        0       32768          0     0  50000
>>
>>
>> Note that this was generated on a normal boot up (not failure).
> 
> The values looks good. Can you try with the below diff applied?
> --->8---
> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> index 334fe3130285..9771f6a82abe 100644
> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>          writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
>   
>          /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
> -       dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
> -       if (!dll_wait_time_us)
> -               dll_wait_time_us = 1;
> +       dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
>   
>          /* Wait for the DLL to settle. */
> -       udelay(dll_wait_time_us);
> +       usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
>   }
>   
>   static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,

Running a boot test with this now. Has run for a couple of hours, but I
want to give it a really good run over the weekend. Will report results
on Monday.

Thanks
Greg



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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-07-31  6:28                 ` Boris Brezillon
  2019-08-02  7:19                   ` Greg Ungerer
@ 2019-08-02 12:34                   ` Greg Ungerer
  2019-08-02 12:51                     ` Boris Brezillon
  1 sibling, 1 reply; 85+ messages in thread
From: Greg Ungerer @ 2019-08-02 12:34 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: s.hauer, Boris Brezillon, linux-mtd, Michael Nazzareno Trimarchi,
	Miquel Raynal

Hi Boris,

On 31/7/19 4:28 pm, Boris Brezillon wrote:
> On Wed, 31 Jul 2019 12:05:44 +1000
> Greg Ungerer <gerg@kernel.org> wrote:
> 
>> Hi Miquel, Boris,
>>
>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>>>> [snip]
>>>> Not sure if this is a useful data point... But I modified that
>>>> nand_init_data_interface() loop to start checking from data mode 4.
>>>> So now on every boot it defaults to mode 4. That has been running
>>>> most of the day, up to 900 boot cycles now, no failures.
>>>
>>> Ok so after having chatted quite a bit with Boris, it is very likely
>>> that, for these chips, the timings in mode 5 are too tight. It could
>>> fail the GET_FEATURES once in mode 5. Can you please dump every single
>>> intermediate value in gpmi_nfc_compute_timings() (period, *_cycles,
>>> use of half pêriods, tRP, sample delay, etc) as well as the content
>>> of /sys/kernel/debug/clk/clk_summary (you'll need debugfs support
>>> enabled and mounted).
>>>
>>> Also, can you be sure that the NAND chip is powered with 3.3V?
>>
>> Yes, 3.3V NAND chip.
>>
>> Using the attached patch I get the following trace:
>>
>> ...
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
>>     sdr->tBERS_max=65535000000
>>     sdr->tCCS_min=500000000
>>     sdr->tPROG_max=65535000000
>>     sdr->tR_max=200000000000000
>>     sdr->tALH_min=20000
>>     sdr->tADL_min=400000
>>     sdr->tALS_min=50000
>>     sdr->tAR_min=25000
>>     sdr->tCEA_max=100000
>>     sdr->tCEH_min=20000
>>     sdr->tCH_min=20000
>>     sdr->tCHZ_max=100000
>>     sdr->tCLH_min=20000
>>     sdr->tCLR_min=20000
>>     sdr->tCLS_min=50000
>>     sdr->tCOH_min=0
>>     sdr->tCS_min=70000
>>     sdr->tDH_min=20000
>>     sdr->tDS_min=40000
>>     sdr->tFEAT_max=1000000
>>     sdr->tIR_min=10000
>>     sdr->tITC_max=1000000
>>     sdr->tRC_min=100000
>>     sdr->tREA_max=40000
>>     sdr->tREH_min=30000
>>     sdr->tRHOH_min=0
>>     sdr->tRHW_min=200000
>>     sdr->tRHZ_max=200000
>>     sdr->tRLOH_min=0
>>     sdr->tRP_min=50000
>>     sdr->tRR_min=40000
>>     sdr->tRST_max=250000000000
>>     sdr->tWB_max=200000
>>     sdr->tWC_min=100000
>>     sdr->tWH_min=30000
>>     sdr->tWHR_min=120000
>>     sdr->tWP_min=50000
>>     sdr->tWW_min=100000
>>       hw->clk_rate=22000000
>>       wrn_dly_sel=0
>>       period_ps=45454
>>       addr_setup_cycles=2
>>       data_setup_cycles=1
>>       data_hold_cycles=1
>>       busy_timeout_cycles=31302
>>       hw->timing0=0x00020101
>>       hw->timing1=0x60000000
>>       dll_threshold_ps=12000
>>       use_half_period=1
>>       reference_period_ps=22727
>>       tRP_ps=45454
>>       sample_delay_ps=4294955664
>>       sample_delay_factor=0
>>       hw->ctrl1n=0x00000000
>>       hw->ctrl1n=0x00000000
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
>>     hw>clk_rate=22000000
>>     clk_set_rate(r->clock[0], hw->clk_rate)=0
>>     clk_get_rate(r->clock[0])=22000000
>> random: fast init done
>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>> nand: Micron MT29F2G08ABAEAWP
>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
>>     sdr->tBERS_max=3000000000
>>     sdr->tCCS_min=100000
>>     sdr->tPROG_max=600000000
>>     sdr->tR_max=25000000
>>     sdr->tALH_min=20000
>>     sdr->tADL_min=400000
>>     sdr->tALS_min=50000
>>     sdr->tAR_min=25000
>>     sdr->tCEA_max=100000
>>     sdr->tCEH_min=20000
>>     sdr->tCH_min=20000
>>     sdr->tCHZ_max=100000
>>     sdr->tCLH_min=20000
>>     sdr->tCLR_min=20000
>>     sdr->tCLS_min=50000
>>     sdr->tCOH_min=0
>>     sdr->tCS_min=70000
>>     sdr->tDH_min=20000
>>     sdr->tDS_min=40000
>>     sdr->tFEAT_max=1000000
>>     sdr->tIR_min=10000
>>     sdr->tITC_max=1000000
>>     sdr->tRC_min=100000
>>     sdr->tREA_max=40000
>>     sdr->tREH_min=30000
>>     sdr->tRHOH_min=0
>>     sdr->tRHW_min=200000
>>     sdr->tRHZ_max=200000
>>     sdr->tRLOH_min=0
>>     sdr->tRP_min=50000
>>     sdr->tRR_min=40000
>>     sdr->tRST_max=250000000000
>>     sdr->tWB_max=200000
>>     sdr->tWC_min=100000
>>     sdr->tWH_min=30000
>>     sdr->tWHR_min=120000
>>     sdr->tWP_min=50000
>>     sdr->tWW_min=100000
>>       hw->clk_rate=22000000
>>       wrn_dly_sel=0
>>       period_ps=45454
>>       addr_setup_cycles=2
>>       data_setup_cycles=1
>>       data_hold_cycles=1
>>       busy_timeout_cycles=555
>>       hw->timing0=0x00020101
>>       hw->timing1=0xb0000000
>>       dll_threshold_ps=12000
>>       use_half_period=1
>>       reference_period_ps=22727
>>       tRP_ps=45454
>>       sample_delay_ps=4294955664
>>       sample_delay_factor=0
>>       hw->ctrl1n=0x00000000
>>       hw->ctrl1n=0x00000000
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
>>     hw>clk_rate=22000000
>>     clk_set_rate(r->clock[0], hw->clk_rate)=0
>>     clk_get_rate(r->clock[0])=22000000
>> gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
>> drivers/mtd/nand/raw/nand_base.c(913): checking mode=5
>> drivers/mtd/nand/raw/nand_base.c(927): BREAKING AT  mode=5
>> drivers/mtd/nand/raw/nand_base.c(932): chip->onfi_timing_mode_default=5
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
>>     sdr->tBERS_max=3000000000
>>     sdr->tCCS_min=100000
>>     sdr->tPROG_max=600000000
>>     sdr->tR_max=25000000
>>     sdr->tALH_min=5000
>>     sdr->tADL_min=400000
>>     sdr->tALS_min=10000
>>     sdr->tAR_min=10000
>>     sdr->tCEA_max=25000
>>     sdr->tCEH_min=20000
>>     sdr->tCH_min=5000
>>     sdr->tCHZ_max=30000
>>     sdr->tCLH_min=5000
>>     sdr->tCLR_min=10000
>>     sdr->tCLS_min=10000
>>     sdr->tCOH_min=15000
>>     sdr->tCS_min=15000
>>     sdr->tDH_min=5000
>>     sdr->tDS_min=7000
>>     sdr->tFEAT_max=1000000
>>     sdr->tIR_min=0
>>     sdr->tITC_max=1000000
>>     sdr->tRC_min=20000
>>     sdr->tREA_max=16000
>>     sdr->tREH_min=7000
>>     sdr->tRHOH_min=15000
>>     sdr->tRHW_min=100000
>>     sdr->tRHZ_max=100000
>>     sdr->tRLOH_min=5000
>>     sdr->tRP_min=10000
>>     sdr->tRR_min=20000
>>     sdr->tRST_max=500000000
>>     sdr->tWB_max=100000
>>     sdr->tWC_min=20000
>>     sdr->tWH_min=7000
>>     sdr->tWHR_min=80000
>>     sdr->tWP_min=10000
>>     sdr->tWW_min=100000
>>       hw->clk_rate=100000000
>>       wrn_dly_sel=3
>>       period_ps=10000
>>       addr_setup_cycles=1
>>       data_setup_cycles=1
>>       data_hold_cycles=1
>>       busy_timeout_cycles=2510
>>       hw->timing0=0x00010101
>>       hw->timing1=0xe0000000
>>       dll_threshold_ps=12000
>>       use_half_period=0
>>       reference_period_ps=10000
>>       tRP_ps=10000
>>       sample_delay_ps=80000
>>       sample_delay_factor=8
>>       hw->ctrl1n=0x00c00000
>>       hw->ctrl1n=0x00c28000
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()
>>     hw>clk_rate=100000000
>>     clk_set_rate(r->clock[0], hw->clk_rate)=0
>>     clk_get_rate(r->clock[0])=99000000
>> Scanning device for bad blocks
>> 5 fixed-partitions partitions found on MTD device gpmi-nand
>> Creating 5 MTD partitions on "gpmi-nand":
>> 0x000000000000-0x000000500000 : "u-boot"
>> 0x000000500000-0x000000600000 : "u-boot-env"
>> 0x000000600000-0x000000800000 : "log"
>> 0x000000800000-0x000010000000 : "flash"
>> 0x000000000000-0x000010000000 : "all"
>> gpmi-nand 1806000.gpmi-nand: driver registered.
>> ...
>>
>>
>> And "cat /sys/kernel/debug/clk/clk_summary" gives:
>>
>>                                    enable  prepare  protect                                duty
>>      clock                          count    count    count        rate   accuracy phase  cycle
>> ---------------------------------------------------------------------------------------------
>>    dummy                                2        2        0           0          0     0  50000
>>       cko2_sel                          0        0        0           0          0     0  50000
>>          cko2_podf                      0        0        0           0          0     0  50000
>>             cko2                        0        0        0           0          0     0  50000
>>       cko1_sel                          0        0        0           0          0     0  50000
>>          cko1_podf                      0        0        0           0          0     0  50000
>>             cko1                        0        0        0           0          0     0  50000
>>                cko                      0        0        0           0          0     0  50000
>>       usbphy2_gate                      1        1        0           0          0     0  50000
>>       usbphy1_gate                      1        1        0           0          0     0  50000
>>    ipp_di1                              0        0        0           0          0     0  50000
>>    ipp_di0                              0        0        0           0          0     0  50000
>>    osc                                  6        6        0    24000000          0     0  50000
>>       perclk_sel                        1        1        0    24000000          0     0  50000
>>          perclk                         3        3        0    24000000          0     0  50000
>>             pwm7                        0        0        0    24000000          0     0  50000
>>             pwm6                        0        0        0    24000000          0     0  50000
>>             pwm5                        0        0        0    24000000          0     0  50000
>>             i2c4                        0        0        0    24000000          0     0  50000
>>             pwm8                        0        0        0    24000000          0     0  50000
>>             pwm4                        0        0        0    24000000          0     0  50000
>>             pwm3                        0        0        0    24000000          0     0  50000
>>             pwm2                        0        0        0    24000000          0     0  50000
>>             pwm1                        0        0        0    24000000          0     0  50000
>>             i2c3                        0        0        0    24000000          0     0  50000
>>             i2c2                        1        1        0    24000000          0     0  50000
>>             i2c1                        0        0        0    24000000          0     0  50000
>>             gpt1_serial                 1        1        0    24000000          0     0  50000
>>             gpt1_bus                    1        1        0    24000000          0     0  50000
>>             epit2                       0        0        0    24000000          0     0  50000
>>             epit1                       0        0        0    24000000          0     0  50000
>>             gpt2_serial                 0        0        0    24000000          0     0  50000
>>             gpt2_bus                    0        0        0    24000000          0     0  50000
>>       periph_clk2_sel                   0        0        0    24000000          0     0  50000
>>          periph_clk2                    0        0        0    24000000          0     0  50000
>>       gpt_3m                            0        0        0     3000000          0     0  50000
>>       csi_sel                           0        0        0    24000000          0     0  50000
>>          csi_podf                       0        0        0    24000000          0     0  50000
>>             csi                         0        0        0    24000000          0     0  50000
>>       pll7                              1        1        0   480000000          0     0  50000
>>          pll7_bypass                    1        1        0   480000000          0     0  50000
>>             pll7_usb_host               1        1        0   480000000          0     0  50000
>>                usbphy2                  1        1        0   480000000          0     0  50000
>>       pll6                              1        1        0   500000000          0     0  50000
>>          pll6_bypass                    1        1        0   500000000          0     0  50000
>>             pll6_enet                   2        2        0   500000000          0     0  50000
>>                enet_ptp_ref             1        1        0    25000000          0     0  50000
>>                   enet_ptp              1        1        0    25000000          0     0  50000
>>                enet2_ref                0        0        0    50000000          0     0  50000
>>                   enet_ref_125m         0        0        0    50000000          0     0  50000
>>                enet_ref                 2        2        0    50000000          0     0  50000
>>       pll5                              0        0        0   296600000          0     0  50000
>>          pll5_bypass                    0        0        0   296600000          0     0  50000
>>             pll5_video                  0        0        0   296600000          0     0  50000
>>                pll5_post_div            0        0        0    74150000          0     0  50000
>>                   pll5_video_div        0        0        0    74150000          0     0  50000
>>       pll4                              0        0        0   147456000          0     0  50000
>>          pll4_bypass                    0        0        0   147456000          0     0  50000
>>             pll4_audio                  0        0        0   147456000          0     0  50000
>>                pll4_post_div            0        0        0    36864000          0     0  50000
>>                   pll4_audio_div        0        0        0    36864000          0     0  50000
>>       pll3                              1        1        0   480000000          0     0  50000
>>          pll3_bypass                    1        1        0   480000000          0     0  50000
>>             pll3_usb_otg                2        2        0   480000000          0     0  50000
>>                spdif_sel                0        0        0   480000000          0     0  50000
>>                   spdif_pred            0        0        0   240000000          0     0  50000
>>                      spdif_podf         0        0        0    30000000          0     0  50000
>>                         spdif           0        0        0    30000000          0     0  50000
>>                esai_sel                 0        0        0   480000000          0     0  50000
>>                   esai_pred             0        0        0   240000000          0     0  50000
>>                      esai_podf          0        0        0    30000000          0     0  50000
>>                         esai_extal       0        0        0    30000000          0     0  50000
>>                qspi1_sel                0        0        0   480000000          0     0  50000
>>                   qspi1_podf            0        0        0   240000000          0     0  50000
>>                      qspi1              0        0        0   240000000          0     0  50000
>>                   ldb_di1_div_7         0        0        0    68571428          0     0  50000
>>                      ldb_di1            0        0        0    68571428          0     0  50000
>>                   ldb_di1_div_3_5       0        0        0   137142857          0     0  50000
>>                periph2_clk2_sel         0        0        0   480000000          0     0  50000
>>                   periph2_clk2          0        0        0   480000000          0     0  50000
>>                pll3_60m                 0        0        0    60000000          0     0  50000
>>                   can_sel               0        0        0    60000000          0     0  50000
>>                      can_podf           0        0        0    30000000          0     0  50000
>>                         can2_serial       0        0        0    30000000          0     0  50000
>>                         can1_serial       0        0        0    30000000          0     0  50000
>>                   ecspi_sel             0        0        0    60000000          0     0  50000
>>                      ecspi_podf         0        0        0    60000000          0     0  50000
>>                         ecspi4          0        0        0    60000000          0     0  50000
>>                         ecspi3          0        0        0    60000000          0     0  50000
>>                         ecspi2          0        0        0    60000000          0     0  50000
>>                         ecspi1          0        0        0    60000000          0     0  50000
>>                pll3_80m                 1        1        0    80000000          0     0  50000
>>                   uart_sel              1        1        0    80000000          0     0  50000
>>                      uart_podf          1        1        0    80000000          0     0  50000
>>                         uart8_serial       0        0        0    80000000          0     0  50000
>>                         uart7_serial       0        0        0    80000000          0     0  50000
>>                         uart1_serial       1        2        0    80000000          0     0  50000
>>                         uart6_serial       0        0        0    80000000          0     0  50000
>>                         uart5_serial       0        0        0    80000000          0     0  50000
>>                         uart4_serial       0        0        0    80000000          0     0  50000
>>                         uart3_serial       0        0        0    80000000          0     0  50000
>>                         uart2_serial       0        0        0    80000000          0     0  50000
>>                pll3_pfd3_454m           0        0        0   454736842          0     0  50000
>>                pll3_pfd2_508m           0        0        0   508235294          0     0  50000
>>                   epdc_pre_sel          0        0        0   508235294          0     0  50000
>>                      epdc_podf          0        0        0   254117647          0     0  50000
>>                         epdc_pix        0        0        0   254117647          0     0  50000
>>                         epdc_sel        0        0        0   254117647          0     0  50000
>>                   sai1_sel              0        0        0   508235294          0     0  50000
>>                      sai1_pred          0        0        0   127058824          0     0  50000
>>                         sai1_podf       0        0        0    63529412          0     0  50000
>>                            sai1         0        0        0    63529412          0     0  50000
>>                   sai2_sel              0        0        0   508235294          0     0  50000
>>                      sai2_pred          0        0        0   127058824          0     0  50000
>>                         sai2_podf       0        0        0    63529412          0     0  50000
>>                            sai2         0        0        0    63529412          0     0  50000
>>                   sai3_sel              0        0        0   508235294          0     0  50000
>>                      sai3_pred          0        0        0   127058824          0     0  50000
>>                         sai3_podf       0        0        0    63529412          0     0  50000
>>                            sai3         0        0        0    63529412          0     0  50000
>>                pll3_pfd1_540m           0        0        0   540000000          0     0  50000
>>                   lcdif_pre_sel         0        0        0   540000000          0     0  50000
>>                      lcdif_pred         0        0        0   270000000          0     0  50000
>>                         lcdif_podf       0        0        0   135000000          0     0  50000
>>                            lcdif_pix       0        0        0   135000000          0     0  50000
>>                            iomuxc       0        0        0   135000000          0     0  50000
>>                            lcdif_sel       0        0        0   135000000          0     0  50000
>>                pll3_pfd0_720m           0        0        0   720000000          0     0  50000
>>                usbphy1                  1        1        0   480000000          0     0  50000
>>       pll2                              1        1        0   528000000          0     0  50000
>>          pll2_bypass                    1        1        0   528000000          0     0  50000
>>             pll2_bus                    2        2        0   528000000          0     0  50000
>>                ca7_secondary_sel        0        0        0   528000000          0     0  50000
>>                   step                  0        0        0   528000000          0     0  50000
>>                periph_pre               1        1        0   528000000          0     0  50000
>>                   periph                3        3        0   528000000          0     0  50000
>>                      ahb                7        7        0   132000000          0     0  50000
>>                         sdma            0        0        0   132000000          0     0  50000
>>                         rom             1        1        0   132000000          0     0  50000
>>                         esai_mem        0        0        0   132000000          0     0  50000
>>                         esai_ipg        0        0        0   132000000          0     0  50000
>>                         aips_tz3        1        1        0   132000000          0     0  50000
>>                         enet_ahb        2        2        0   132000000          0     0  50000
>>                         dcp             0        0        0   132000000          0     0  50000
>>                         asrc_mem        0        0        0   132000000          0     0  50000
>>                         asrc_ipg        0        0        0   132000000          0     0  50000
>>                         aips_tz2        1        1        0   132000000          0     0  50000
>>                         aips_tz1        1        1        0   132000000          0     0  50000
>>                         ipg            10       10        0    66000000          0     0  50000
>>                            wdog3        0        0        0    66000000          0     0  50000
>>                            uart8_ipg       0        0        0    66000000          0     0  50000
>>                            usboh3       2        2        0    66000000          0     0  50000
>>                            sai2_ipg       0        0        0    66000000          0     0  50000
>>                            sai1_ipg       0        0        0    66000000          0     0  50000
>>                            uart7_ipg       0        0        0    66000000          0     0  50000
>>                            uart1_ipg       1        2        0    66000000          0     0  50000
>>                            sai3_ipg       0        0        0    66000000          0     0  50000
>>                            spdif_gclk       0        0        0    66000000          0     0  50000
>>                            spba         0        0        0    66000000          0     0  50000
>>                            wdog2        0        0        0    66000000          0     0  50000
>>                            kpp          0        0        0    66000000          0     0  50000
>>                            mmdc_p1_ipg       0        0        0    66000000          0     0  50000
>>                            mmdc_p0_ipg       2        2        0    66000000          0     0  50000
>>                            wdog1        1        1        0    66000000          0     0  50000
>>                            gpio4        1        1        0    66000000          0     0  50000
>>                            uart6_ipg       0        0        0    66000000          0     0  50000
>>                            uart5_ipg       0        0        0    66000000          0     0  50000
>>                            gpio3        1        1        0    66000000          0     0  50000
>>                            ocotp        0        0        0    66000000          0     0  50000
>>                            gpio5        1        1        0    66000000          0     0  50000
>>                            gpio1        1        1        0    66000000          0     0  50000
>>                            uart4_ipg       0        0        0    66000000          0     0  50000
>>                            adc1         0        0        0    66000000          0     0  50000
>>                            uart3_ipg       0        0        0    66000000          0     0  50000
>>                            adc2         0        0        0    66000000          0     0  50000
>>                            gpio2        1        1        0    66000000          0     0  50000
>>                            uart2_ipg       0        0        0    66000000          0     0  50000
>>                            can2_ipg       0        0        0    66000000          0     0  50000
>>                            can1_ipg       0        0        0    66000000          0     0  50000
>>                            enet         2        2        0    66000000          0     0  50000
>>                      axi_sel            1        1        0   528000000          0     0  50000
>>                         axi_podf        2        2        0   264000000          0     0  50000
>>                            axi          1        1        0   264000000          0     0  50000
>>                               eim_slow_sel       0        0        0   264000000          0     0  50000
>>                                  eim_slow_podf       0        0        0   132000000          0     0  50000
>>                                     eim       0        0        0   132000000          0     0  50000
>>                               lcdif_apb       0        0        0   264000000          0     0  50000
>>                               pxp       0        0        0   264000000          0     0  50000
>>                               epdc_aclk       0        0        0   264000000          0     0  50000
>>                pll2_pfd3_594m           0        0        0   594000000          0     0  50000
>>                   ldb_di0_sel           0        0        0   594000000          0     0  50000
>>                      ldb_di0_div_7       0        0        0    84857142          0     0  50000
>>                         ldb_di0         0        0        0    84857142          0     0  50000
>>                      ldb_di0_div_3_5       0        0        0   169714285          0     0  50000
>>                pll2_pfd2_396m           2        2        0   396000000          0     0  50000
>>                   enfc_sel              0        0        0   396000000          0     0  50000
>>                      enfc_pred          0        0        0    99000000          0     0  50000
>>                         enfc_podf       0        0        0    99000000          0     0  50000
>>                            gpmi_io       0        0        0    99000000          0     0  50000
>>                   usdhc1_sel            0        0        0   396000000          0     0  50000
>>                      usdhc1_podf        0        0        0   198000000          0     0  50000
>>                         usdhc1          0        0        0   198000000          0     0  50000
>>                   usdhc2_sel            0        0        0   396000000          0     0  50000
>>                      usdhc2_podf        0        0        0   198000000          0     0  50000
>>                         usdhc2          0        0        0   198000000          0     0  50000
>>                   bch_sel               1        1        0   396000000          0     0  50000
>>                      bch_podf           1        1        0    99000000          0     0  50000
>>                         gpmi_apb        0        0        0    99000000          0     0  50000
>>                         gpmi_bch_apb       0        0        0    99000000          0     0  50000
>>                         per_bch         0        0        0    99000000          0     0  50000
>>                         apbh_dma        1        1        0    99000000          0     0  50000
>>                   gpmi_sel              0        0        0   396000000          0     0  50000
>>                      gpmi_podf          0        0        0    99000000          0     0  50000
>>                         gpmi_bch        0        0        0    99000000          0     0  50000
>>                   periph2_pre           1        1        0   396000000          0     0  50000
>>                      periph2            2        2        0   396000000          0     0  50000
>>                         mmdc_podf       2        2        0   396000000          0     0  50000
>>                            mmdc_p0_fast       1        1        0   396000000          0     0  50000
>>                   axi_alt_sel           0        0        0   396000000          0     0  50000
>>                   pll2_198m             0        0        0   198000000          0     0  50000
>>                pll2_pfd1_594m           0        0        0   594000000          0     0  50000
>>                pll2_pfd0_352m           0        0        0   352000000          0     0  50000
>>       pll1                              1        1        0   900000000          0     0  50000
>>          pll1_bypass                    1        1        0   900000000          0     0  50000
>>             pll1_sys                    1        1        0   900000000          0     0  50000
>>                pll1_sw                  1        1        0   900000000          0     0  50000
>>                   arm                   1        1        0   900000000          0     0  50000
>>       pll7_bypass_src                   0        0        0    24000000          0     0  50000
>>       pll6_bypass_src                   0        0        0    24000000          0     0  50000
>>       pll5_bypass_src                   0        0        0    24000000          0     0  50000
>>       pll4_bypass_src                   0        0        0    24000000          0     0  50000
>>       pll3_bypass_src                   0        0        0    24000000          0     0  50000
>>       pll2_bypass_src                   0        0        0    24000000          0     0  50000
>>       pll1_bypass_src                   0        0        0    24000000          0     0  50000
>>    ckil                                 0        0        0       32768          0     0  50000
>>
>>
>> Note that this was generated on a normal boot up (not failure).
> 
> The values looks good. Can you try with the below diff applied?
> --->8---
> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> index 334fe3130285..9771f6a82abe 100644
> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>          writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
>   
>          /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
> -       dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
> -       if (!dll_wait_time_us)
> -               dll_wait_time_us = 1;
> +       dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
>   
>          /* Wait for the DLL to settle. */
> -       udelay(dll_wait_time_us);
> +       usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
>   }
>   
>   static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,

Eventually it failed, in the same way with with same errors.
Took quite a while, over 600 boot cycles.

Note also that I had to hand merge the changes, since in 5.1.14 that
gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.

Regards
Greg




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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-08-02 12:34                   ` Greg Ungerer
@ 2019-08-02 12:51                     ` Boris Brezillon
  2019-08-05  5:51                       ` Greg Ungerer
  0 siblings, 1 reply; 85+ messages in thread
From: Boris Brezillon @ 2019-08-02 12:51 UTC (permalink / raw)
  To: Greg Ungerer
  Cc: s.hauer, Boris Brezillon, linux-mtd, Michael Nazzareno Trimarchi,
	Miquel Raynal

On Fri, 2 Aug 2019 22:34:57 +1000
Greg Ungerer <gerg@kernel.org> wrote:

> Hi Boris,
> 
> On 31/7/19 4:28 pm, Boris Brezillon wrote:
> > On Wed, 31 Jul 2019 12:05:44 +1000
> > Greg Ungerer <gerg@kernel.org> wrote:
> >   
> >> Hi Miquel, Boris,
> >>
> >> On 30/7/19 6:38 pm, Miquel Raynal wrote:  
> >>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:  
> >>>> On 30/7/19 10:41 am, Greg Ungerer wrote:  
> >>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:  
> >>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:  
> >>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:  
> >>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:  
> >>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:  
> >>>>> [snip]  
> >>>> Not sure if this is a useful data point... But I modified that
> >>>> nand_init_data_interface() loop to start checking from data mode 4.
> >>>> So now on every boot it defaults to mode 4. That has been running
> >>>> most of the day, up to 900 boot cycles now, no failures.  
> >>>
> >>> Ok so after having chatted quite a bit with Boris, it is very likely
> >>> that, for these chips, the timings in mode 5 are too tight. It could
> >>> fail the GET_FEATURES once in mode 5. Can you please dump every single
> >>> intermediate value in gpmi_nfc_compute_timings() (period, *_cycles,
> >>> use of half pêriods, tRP, sample delay, etc) as well as the content
> >>> of /sys/kernel/debug/clk/clk_summary (you'll need debugfs support
> >>> enabled and mounted).
> >>>
> >>> Also, can you be sure that the NAND chip is powered with 3.3V?  
> >>
> >> Yes, 3.3V NAND chip.
> >>
> >> Using the attached patch I get the following trace:
> >>
> >> ...
> >> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
> >>     sdr->tBERS_max=65535000000
> >>     sdr->tCCS_min=500000000
> >>     sdr->tPROG_max=65535000000
> >>     sdr->tR_max=200000000000000
> >>     sdr->tALH_min=20000
> >>     sdr->tADL_min=400000
> >>     sdr->tALS_min=50000
> >>     sdr->tAR_min=25000
> >>     sdr->tCEA_max=100000
> >>     sdr->tCEH_min=20000
> >>     sdr->tCH_min=20000
> >>     sdr->tCHZ_max=100000
> >>     sdr->tCLH_min=20000
> >>     sdr->tCLR_min=20000
> >>     sdr->tCLS_min=50000
> >>     sdr->tCOH_min=0
> >>     sdr->tCS_min=70000
> >>     sdr->tDH_min=20000
> >>     sdr->tDS_min=40000
> >>     sdr->tFEAT_max=1000000
> >>     sdr->tIR_min=10000
> >>     sdr->tITC_max=1000000
> >>     sdr->tRC_min=100000
> >>     sdr->tREA_max=40000
> >>     sdr->tREH_min=30000
> >>     sdr->tRHOH_min=0
> >>     sdr->tRHW_min=200000
> >>     sdr->tRHZ_max=200000
> >>     sdr->tRLOH_min=0
> >>     sdr->tRP_min=50000
> >>     sdr->tRR_min=40000
> >>     sdr->tRST_max=250000000000
> >>     sdr->tWB_max=200000
> >>     sdr->tWC_min=100000
> >>     sdr->tWH_min=30000
> >>     sdr->tWHR_min=120000
> >>     sdr->tWP_min=50000
> >>     sdr->tWW_min=100000
> >>       hw->clk_rate=22000000
> >>       wrn_dly_sel=0
> >>       period_ps=45454
> >>       addr_setup_cycles=2
> >>       data_setup_cycles=1
> >>       data_hold_cycles=1
> >>       busy_timeout_cycles=31302
> >>       hw->timing0=0x00020101
> >>       hw->timing1=0x60000000
> >>       dll_threshold_ps=12000
> >>       use_half_period=1
> >>       reference_period_ps=22727
> >>       tRP_ps=45454
> >>       sample_delay_ps=4294955664
> >>       sample_delay_factor=0
> >>       hw->ctrl1n=0x00000000
> >>       hw->ctrl1n=0x00000000
> >> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()  
> >>     hw>clk_rate=22000000  
> >>     clk_set_rate(r->clock[0], hw->clk_rate)=0
> >>     clk_get_rate(r->clock[0])=22000000
> >> random: fast init done
> >> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> >> nand: Micron MT29F2G08ABAEAWP
> >> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> >> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
> >>     sdr->tBERS_max=3000000000
> >>     sdr->tCCS_min=100000
> >>     sdr->tPROG_max=600000000
> >>     sdr->tR_max=25000000
> >>     sdr->tALH_min=20000
> >>     sdr->tADL_min=400000
> >>     sdr->tALS_min=50000
> >>     sdr->tAR_min=25000
> >>     sdr->tCEA_max=100000
> >>     sdr->tCEH_min=20000
> >>     sdr->tCH_min=20000
> >>     sdr->tCHZ_max=100000
> >>     sdr->tCLH_min=20000
> >>     sdr->tCLR_min=20000
> >>     sdr->tCLS_min=50000
> >>     sdr->tCOH_min=0
> >>     sdr->tCS_min=70000
> >>     sdr->tDH_min=20000
> >>     sdr->tDS_min=40000
> >>     sdr->tFEAT_max=1000000
> >>     sdr->tIR_min=10000
> >>     sdr->tITC_max=1000000
> >>     sdr->tRC_min=100000
> >>     sdr->tREA_max=40000
> >>     sdr->tREH_min=30000
> >>     sdr->tRHOH_min=0
> >>     sdr->tRHW_min=200000
> >>     sdr->tRHZ_max=200000
> >>     sdr->tRLOH_min=0
> >>     sdr->tRP_min=50000
> >>     sdr->tRR_min=40000
> >>     sdr->tRST_max=250000000000
> >>     sdr->tWB_max=200000
> >>     sdr->tWC_min=100000
> >>     sdr->tWH_min=30000
> >>     sdr->tWHR_min=120000
> >>     sdr->tWP_min=50000
> >>     sdr->tWW_min=100000
> >>       hw->clk_rate=22000000
> >>       wrn_dly_sel=0
> >>       period_ps=45454
> >>       addr_setup_cycles=2
> >>       data_setup_cycles=1
> >>       data_hold_cycles=1
> >>       busy_timeout_cycles=555
> >>       hw->timing0=0x00020101
> >>       hw->timing1=0xb0000000
> >>       dll_threshold_ps=12000
> >>       use_half_period=1
> >>       reference_period_ps=22727
> >>       tRP_ps=45454
> >>       sample_delay_ps=4294955664
> >>       sample_delay_factor=0
> >>       hw->ctrl1n=0x00000000
> >>       hw->ctrl1n=0x00000000
> >> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()  
> >>     hw>clk_rate=22000000  
> >>     clk_set_rate(r->clock[0], hw->clk_rate)=0
> >>     clk_get_rate(r->clock[0])=22000000
> >> gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
> >> drivers/mtd/nand/raw/nand_base.c(913): checking mode=5
> >> drivers/mtd/nand/raw/nand_base.c(927): BREAKING AT  mode=5
> >> drivers/mtd/nand/raw/nand_base.c(932): chip->onfi_timing_mode_default=5
> >> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(426): gpmi_nfc_compute_timings()
> >>     sdr->tBERS_max=3000000000
> >>     sdr->tCCS_min=100000
> >>     sdr->tPROG_max=600000000
> >>     sdr->tR_max=25000000
> >>     sdr->tALH_min=5000
> >>     sdr->tADL_min=400000
> >>     sdr->tALS_min=10000
> >>     sdr->tAR_min=10000
> >>     sdr->tCEA_max=25000
> >>     sdr->tCEH_min=20000
> >>     sdr->tCH_min=5000
> >>     sdr->tCHZ_max=30000
> >>     sdr->tCLH_min=5000
> >>     sdr->tCLR_min=10000
> >>     sdr->tCLS_min=10000
> >>     sdr->tCOH_min=15000
> >>     sdr->tCS_min=15000
> >>     sdr->tDH_min=5000
> >>     sdr->tDS_min=7000
> >>     sdr->tFEAT_max=1000000
> >>     sdr->tIR_min=0
> >>     sdr->tITC_max=1000000
> >>     sdr->tRC_min=20000
> >>     sdr->tREA_max=16000
> >>     sdr->tREH_min=7000
> >>     sdr->tRHOH_min=15000
> >>     sdr->tRHW_min=100000
> >>     sdr->tRHZ_max=100000
> >>     sdr->tRLOH_min=5000
> >>     sdr->tRP_min=10000
> >>     sdr->tRR_min=20000
> >>     sdr->tRST_max=500000000
> >>     sdr->tWB_max=100000
> >>     sdr->tWC_min=20000
> >>     sdr->tWH_min=7000
> >>     sdr->tWHR_min=80000
> >>     sdr->tWP_min=10000
> >>     sdr->tWW_min=100000
> >>       hw->clk_rate=100000000
> >>       wrn_dly_sel=3
> >>       period_ps=10000
> >>       addr_setup_cycles=1
> >>       data_setup_cycles=1
> >>       data_hold_cycles=1
> >>       busy_timeout_cycles=2510
> >>       hw->timing0=0x00010101
> >>       hw->timing1=0xe0000000
> >>       dll_threshold_ps=12000
> >>       use_half_period=0
> >>       reference_period_ps=10000
> >>       tRP_ps=10000
> >>       sample_delay_ps=80000
> >>       sample_delay_factor=8
> >>       hw->ctrl1n=0x00c00000
> >>       hw->ctrl1n=0x00c28000
> >> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(547): gpmi_nfc_apply_timings()  
> >>     hw>clk_rate=100000000  
> >>     clk_set_rate(r->clock[0], hw->clk_rate)=0
> >>     clk_get_rate(r->clock[0])=99000000
> >> Scanning device for bad blocks
> >> 5 fixed-partitions partitions found on MTD device gpmi-nand
> >> Creating 5 MTD partitions on "gpmi-nand":
> >> 0x000000000000-0x000000500000 : "u-boot"
> >> 0x000000500000-0x000000600000 : "u-boot-env"
> >> 0x000000600000-0x000000800000 : "log"
> >> 0x000000800000-0x000010000000 : "flash"
> >> 0x000000000000-0x000010000000 : "all"
> >> gpmi-nand 1806000.gpmi-nand: driver registered.
> >> ...
> >>
> >>
> >> And "cat /sys/kernel/debug/clk/clk_summary" gives:
> >>
> >>                                    enable  prepare  protect                                duty
> >>      clock                          count    count    count        rate   accuracy phase  cycle
> >> ---------------------------------------------------------------------------------------------
> >>    dummy                                2        2        0           0          0     0  50000
> >>       cko2_sel                          0        0        0           0          0     0  50000
> >>          cko2_podf                      0        0        0           0          0     0  50000
> >>             cko2                        0        0        0           0          0     0  50000
> >>       cko1_sel                          0        0        0           0          0     0  50000
> >>          cko1_podf                      0        0        0           0          0     0  50000
> >>             cko1                        0        0        0           0          0     0  50000
> >>                cko                      0        0        0           0          0     0  50000
> >>       usbphy2_gate                      1        1        0           0          0     0  50000
> >>       usbphy1_gate                      1        1        0           0          0     0  50000
> >>    ipp_di1                              0        0        0           0          0     0  50000
> >>    ipp_di0                              0        0        0           0          0     0  50000
> >>    osc                                  6        6        0    24000000          0     0  50000
> >>       perclk_sel                        1        1        0    24000000          0     0  50000
> >>          perclk                         3        3        0    24000000          0     0  50000
> >>             pwm7                        0        0        0    24000000          0     0  50000
> >>             pwm6                        0        0        0    24000000          0     0  50000
> >>             pwm5                        0        0        0    24000000          0     0  50000
> >>             i2c4                        0        0        0    24000000          0     0  50000
> >>             pwm8                        0        0        0    24000000          0     0  50000
> >>             pwm4                        0        0        0    24000000          0     0  50000
> >>             pwm3                        0        0        0    24000000          0     0  50000
> >>             pwm2                        0        0        0    24000000          0     0  50000
> >>             pwm1                        0        0        0    24000000          0     0  50000
> >>             i2c3                        0        0        0    24000000          0     0  50000
> >>             i2c2                        1        1        0    24000000          0     0  50000
> >>             i2c1                        0        0        0    24000000          0     0  50000
> >>             gpt1_serial                 1        1        0    24000000          0     0  50000
> >>             gpt1_bus                    1        1        0    24000000          0     0  50000
> >>             epit2                       0        0        0    24000000          0     0  50000
> >>             epit1                       0        0        0    24000000          0     0  50000
> >>             gpt2_serial                 0        0        0    24000000          0     0  50000
> >>             gpt2_bus                    0        0        0    24000000          0     0  50000
> >>       periph_clk2_sel                   0        0        0    24000000          0     0  50000
> >>          periph_clk2                    0        0        0    24000000          0     0  50000
> >>       gpt_3m                            0        0        0     3000000          0     0  50000
> >>       csi_sel                           0        0        0    24000000          0     0  50000
> >>          csi_podf                       0        0        0    24000000          0     0  50000
> >>             csi                         0        0        0    24000000          0     0  50000
> >>       pll7                              1        1        0   480000000          0     0  50000
> >>          pll7_bypass                    1        1        0   480000000          0     0  50000
> >>             pll7_usb_host               1        1        0   480000000          0     0  50000
> >>                usbphy2                  1        1        0   480000000          0     0  50000
> >>       pll6                              1        1        0   500000000          0     0  50000
> >>          pll6_bypass                    1        1        0   500000000          0     0  50000
> >>             pll6_enet                   2        2        0   500000000          0     0  50000
> >>                enet_ptp_ref             1        1        0    25000000          0     0  50000
> >>                   enet_ptp              1        1        0    25000000          0     0  50000
> >>                enet2_ref                0        0        0    50000000          0     0  50000
> >>                   enet_ref_125m         0        0        0    50000000          0     0  50000
> >>                enet_ref                 2        2        0    50000000          0     0  50000
> >>       pll5                              0        0        0   296600000          0     0  50000
> >>          pll5_bypass                    0        0        0   296600000          0     0  50000
> >>             pll5_video                  0        0        0   296600000          0     0  50000
> >>                pll5_post_div            0        0        0    74150000          0     0  50000
> >>                   pll5_video_div        0        0        0    74150000          0     0  50000
> >>       pll4                              0        0        0   147456000          0     0  50000
> >>          pll4_bypass                    0        0        0   147456000          0     0  50000
> >>             pll4_audio                  0        0        0   147456000          0     0  50000
> >>                pll4_post_div            0        0        0    36864000          0     0  50000
> >>                   pll4_audio_div        0        0        0    36864000          0     0  50000
> >>       pll3                              1        1        0   480000000          0     0  50000
> >>          pll3_bypass                    1        1        0   480000000          0     0  50000
> >>             pll3_usb_otg                2        2        0   480000000          0     0  50000
> >>                spdif_sel                0        0        0   480000000          0     0  50000
> >>                   spdif_pred            0        0        0   240000000          0     0  50000
> >>                      spdif_podf         0        0        0    30000000          0     0  50000
> >>                         spdif           0        0        0    30000000          0     0  50000
> >>                esai_sel                 0        0        0   480000000          0     0  50000
> >>                   esai_pred             0        0        0   240000000          0     0  50000
> >>                      esai_podf          0        0        0    30000000          0     0  50000
> >>                         esai_extal       0        0        0    30000000          0     0  50000
> >>                qspi1_sel                0        0        0   480000000          0     0  50000
> >>                   qspi1_podf            0        0        0   240000000          0     0  50000
> >>                      qspi1              0        0        0   240000000          0     0  50000
> >>                   ldb_di1_div_7         0        0        0    68571428          0     0  50000
> >>                      ldb_di1            0        0        0    68571428          0     0  50000
> >>                   ldb_di1_div_3_5       0        0        0   137142857          0     0  50000
> >>                periph2_clk2_sel         0        0        0   480000000          0     0  50000
> >>                   periph2_clk2          0        0        0   480000000          0     0  50000
> >>                pll3_60m                 0        0        0    60000000          0     0  50000
> >>                   can_sel               0        0        0    60000000          0     0  50000
> >>                      can_podf           0        0        0    30000000          0     0  50000
> >>                         can2_serial       0        0        0    30000000          0     0  50000
> >>                         can1_serial       0        0        0    30000000          0     0  50000
> >>                   ecspi_sel             0        0        0    60000000          0     0  50000
> >>                      ecspi_podf         0        0        0    60000000          0     0  50000
> >>                         ecspi4          0        0        0    60000000          0     0  50000
> >>                         ecspi3          0        0        0    60000000          0     0  50000
> >>                         ecspi2          0        0        0    60000000          0     0  50000
> >>                         ecspi1          0        0        0    60000000          0     0  50000
> >>                pll3_80m                 1        1        0    80000000          0     0  50000
> >>                   uart_sel              1        1        0    80000000          0     0  50000
> >>                      uart_podf          1        1        0    80000000          0     0  50000
> >>                         uart8_serial       0        0        0    80000000          0     0  50000
> >>                         uart7_serial       0        0        0    80000000          0     0  50000
> >>                         uart1_serial       1        2        0    80000000          0     0  50000
> >>                         uart6_serial       0        0        0    80000000          0     0  50000
> >>                         uart5_serial       0        0        0    80000000          0     0  50000
> >>                         uart4_serial       0        0        0    80000000          0     0  50000
> >>                         uart3_serial       0        0        0    80000000          0     0  50000
> >>                         uart2_serial       0        0        0    80000000          0     0  50000
> >>                pll3_pfd3_454m           0        0        0   454736842          0     0  50000
> >>                pll3_pfd2_508m           0        0        0   508235294          0     0  50000
> >>                   epdc_pre_sel          0        0        0   508235294          0     0  50000
> >>                      epdc_podf          0        0        0   254117647          0     0  50000
> >>                         epdc_pix        0        0        0   254117647          0     0  50000
> >>                         epdc_sel        0        0        0   254117647          0     0  50000
> >>                   sai1_sel              0        0        0   508235294          0     0  50000
> >>                      sai1_pred          0        0        0   127058824          0     0  50000
> >>                         sai1_podf       0        0        0    63529412          0     0  50000
> >>                            sai1         0        0        0    63529412          0     0  50000
> >>                   sai2_sel              0        0        0   508235294          0     0  50000
> >>                      sai2_pred          0        0        0   127058824          0     0  50000
> >>                         sai2_podf       0        0        0    63529412          0     0  50000
> >>                            sai2         0        0        0    63529412          0     0  50000
> >>                   sai3_sel              0        0        0   508235294          0     0  50000
> >>                      sai3_pred          0        0        0   127058824          0     0  50000
> >>                         sai3_podf       0        0        0    63529412          0     0  50000
> >>                            sai3         0        0        0    63529412          0     0  50000
> >>                pll3_pfd1_540m           0        0        0   540000000          0     0  50000
> >>                   lcdif_pre_sel         0        0        0   540000000          0     0  50000
> >>                      lcdif_pred         0        0        0   270000000          0     0  50000
> >>                         lcdif_podf       0        0        0   135000000          0     0  50000
> >>                            lcdif_pix       0        0        0   135000000          0     0  50000
> >>                            iomuxc       0        0        0   135000000          0     0  50000
> >>                            lcdif_sel       0        0        0   135000000          0     0  50000
> >>                pll3_pfd0_720m           0        0        0   720000000          0     0  50000
> >>                usbphy1                  1        1        0   480000000          0     0  50000
> >>       pll2                              1        1        0   528000000          0     0  50000
> >>          pll2_bypass                    1        1        0   528000000          0     0  50000
> >>             pll2_bus                    2        2        0   528000000          0     0  50000
> >>                ca7_secondary_sel        0        0        0   528000000          0     0  50000
> >>                   step                  0        0        0   528000000          0     0  50000
> >>                periph_pre               1        1        0   528000000          0     0  50000
> >>                   periph                3        3        0   528000000          0     0  50000
> >>                      ahb                7        7        0   132000000          0     0  50000
> >>                         sdma            0        0        0   132000000          0     0  50000
> >>                         rom             1        1        0   132000000          0     0  50000
> >>                         esai_mem        0        0        0   132000000          0     0  50000
> >>                         esai_ipg        0        0        0   132000000          0     0  50000
> >>                         aips_tz3        1        1        0   132000000          0     0  50000
> >>                         enet_ahb        2        2        0   132000000          0     0  50000
> >>                         dcp             0        0        0   132000000          0     0  50000
> >>                         asrc_mem        0        0        0   132000000          0     0  50000
> >>                         asrc_ipg        0        0        0   132000000          0     0  50000
> >>                         aips_tz2        1        1        0   132000000          0     0  50000
> >>                         aips_tz1        1        1        0   132000000          0     0  50000
> >>                         ipg            10       10        0    66000000          0     0  50000
> >>                            wdog3        0        0        0    66000000          0     0  50000
> >>                            uart8_ipg       0        0        0    66000000          0     0  50000
> >>                            usboh3       2        2        0    66000000          0     0  50000
> >>                            sai2_ipg       0        0        0    66000000          0     0  50000
> >>                            sai1_ipg       0        0        0    66000000          0     0  50000
> >>                            uart7_ipg       0        0        0    66000000          0     0  50000
> >>                            uart1_ipg       1        2        0    66000000          0     0  50000
> >>                            sai3_ipg       0        0        0    66000000          0     0  50000
> >>                            spdif_gclk       0        0        0    66000000          0     0  50000
> >>                            spba         0        0        0    66000000          0     0  50000
> >>                            wdog2        0        0        0    66000000          0     0  50000
> >>                            kpp          0        0        0    66000000          0     0  50000
> >>                            mmdc_p1_ipg       0        0        0    66000000          0     0  50000
> >>                            mmdc_p0_ipg       2        2        0    66000000          0     0  50000
> >>                            wdog1        1        1        0    66000000          0     0  50000
> >>                            gpio4        1        1        0    66000000          0     0  50000
> >>                            uart6_ipg       0        0        0    66000000          0     0  50000
> >>                            uart5_ipg       0        0        0    66000000          0     0  50000
> >>                            gpio3        1        1        0    66000000          0     0  50000
> >>                            ocotp        0        0        0    66000000          0     0  50000
> >>                            gpio5        1        1        0    66000000          0     0  50000
> >>                            gpio1        1        1        0    66000000          0     0  50000
> >>                            uart4_ipg       0        0        0    66000000          0     0  50000
> >>                            adc1         0        0        0    66000000          0     0  50000
> >>                            uart3_ipg       0        0        0    66000000          0     0  50000
> >>                            adc2         0        0        0    66000000          0     0  50000
> >>                            gpio2        1        1        0    66000000          0     0  50000
> >>                            uart2_ipg       0        0        0    66000000          0     0  50000
> >>                            can2_ipg       0        0        0    66000000          0     0  50000
> >>                            can1_ipg       0        0        0    66000000          0     0  50000
> >>                            enet         2        2        0    66000000          0     0  50000
> >>                      axi_sel            1        1        0   528000000          0     0  50000
> >>                         axi_podf        2        2        0   264000000          0     0  50000
> >>                            axi          1        1        0   264000000          0     0  50000
> >>                               eim_slow_sel       0        0        0   264000000          0     0  50000
> >>                                  eim_slow_podf       0        0        0   132000000          0     0  50000
> >>                                     eim       0        0        0   132000000          0     0  50000
> >>                               lcdif_apb       0        0        0   264000000          0     0  50000
> >>                               pxp       0        0        0   264000000          0     0  50000
> >>                               epdc_aclk       0        0        0   264000000          0     0  50000
> >>                pll2_pfd3_594m           0        0        0   594000000          0     0  50000
> >>                   ldb_di0_sel           0        0        0   594000000          0     0  50000
> >>                      ldb_di0_div_7       0        0        0    84857142          0     0  50000
> >>                         ldb_di0         0        0        0    84857142          0     0  50000
> >>                      ldb_di0_div_3_5       0        0        0   169714285          0     0  50000
> >>                pll2_pfd2_396m           2        2        0   396000000          0     0  50000
> >>                   enfc_sel              0        0        0   396000000          0     0  50000
> >>                      enfc_pred          0        0        0    99000000          0     0  50000
> >>                         enfc_podf       0        0        0    99000000          0     0  50000
> >>                            gpmi_io       0        0        0    99000000          0     0  50000
> >>                   usdhc1_sel            0        0        0   396000000          0     0  50000
> >>                      usdhc1_podf        0        0        0   198000000          0     0  50000
> >>                         usdhc1          0        0        0   198000000          0     0  50000
> >>                   usdhc2_sel            0        0        0   396000000          0     0  50000
> >>                      usdhc2_podf        0        0        0   198000000          0     0  50000
> >>                         usdhc2          0        0        0   198000000          0     0  50000
> >>                   bch_sel               1        1        0   396000000          0     0  50000
> >>                      bch_podf           1        1        0    99000000          0     0  50000
> >>                         gpmi_apb        0        0        0    99000000          0     0  50000
> >>                         gpmi_bch_apb       0        0        0    99000000          0     0  50000
> >>                         per_bch         0        0        0    99000000          0     0  50000
> >>                         apbh_dma        1        1        0    99000000          0     0  50000
> >>                   gpmi_sel              0        0        0   396000000          0     0  50000
> >>                      gpmi_podf          0        0        0    99000000          0     0  50000
> >>                         gpmi_bch        0        0        0    99000000          0     0  50000
> >>                   periph2_pre           1        1        0   396000000          0     0  50000
> >>                      periph2            2        2        0   396000000          0     0  50000
> >>                         mmdc_podf       2        2        0   396000000          0     0  50000
> >>                            mmdc_p0_fast       1        1        0   396000000          0     0  50000
> >>                   axi_alt_sel           0        0        0   396000000          0     0  50000
> >>                   pll2_198m             0        0        0   198000000          0     0  50000
> >>                pll2_pfd1_594m           0        0        0   594000000          0     0  50000
> >>                pll2_pfd0_352m           0        0        0   352000000          0     0  50000
> >>       pll1                              1        1        0   900000000          0     0  50000
> >>          pll1_bypass                    1        1        0   900000000          0     0  50000
> >>             pll1_sys                    1        1        0   900000000          0     0  50000
> >>                pll1_sw                  1        1        0   900000000          0     0  50000
> >>                   arm                   1        1        0   900000000          0     0  50000
> >>       pll7_bypass_src                   0        0        0    24000000          0     0  50000
> >>       pll6_bypass_src                   0        0        0    24000000          0     0  50000
> >>       pll5_bypass_src                   0        0        0    24000000          0     0  50000
> >>       pll4_bypass_src                   0        0        0    24000000          0     0  50000
> >>       pll3_bypass_src                   0        0        0    24000000          0     0  50000
> >>       pll2_bypass_src                   0        0        0    24000000          0     0  50000
> >>       pll1_bypass_src                   0        0        0    24000000          0     0  50000
> >>    ckil                                 0        0        0       32768          0     0  50000
> >>
> >>
> >> Note that this was generated on a normal boot up (not failure).  
> > 
> > The values looks good. Can you try with the below diff applied?  
> > --->8---  
> > diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > index 334fe3130285..9771f6a82abe 100644
> > --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >          writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
> >   
> >          /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
> > -       dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
> > -       if (!dll_wait_time_us)
> > -               dll_wait_time_us = 1;
> > +       dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
> >   
> >          /* Wait for the DLL to settle. */
> > -       udelay(dll_wait_time_us);
> > +       usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
> >   }
> >   
> >   static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,  
> 
> Eventually it failed, in the same way with with same errors.
> Took quite a while, over 600 boot cycles.
> 
> Note also that I had to hand merge the changes, since in 5.1.14 that
> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.

Oh well. I guess the next thing to do would be to dump the timing regs
and clk rate that are set by the bootloader (before the driver override
them) or those applied by an older kernel (one that didn't have that
issue).

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-08-02 12:51                     ` Boris Brezillon
@ 2019-08-05  5:51                       ` Greg Ungerer
  2019-08-07 16:05                         ` Miquel Raynal
  2019-08-08 16:36                         ` Boris Brezillon
  0 siblings, 2 replies; 85+ messages in thread
From: Greg Ungerer @ 2019-08-05  5:51 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: s.hauer, Boris Brezillon, linux-mtd, Michael Nazzareno Trimarchi,
	Miquel Raynal

[-- Attachment #1: Type: text/plain, Size: 3937 bytes --]

Hi Boris,

On 2/8/19 10:51 pm, Boris Brezillon wrote:
> On Fri, 2 Aug 2019 22:34:57 +1000
> Greg Ungerer <gerg@kernel.org> wrote:
>> On 31/7/19 4:28 pm, Boris Brezillon wrote:
>>> On Wed, 31 Jul 2019 12:05:44 +1000
>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
>>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
>>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
>>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
>>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>>>>>> [snip]
>>>> Note that this was generated on a normal boot up (not failure).
>>>
>>> The values looks good. Can you try with the below diff applied?
>>> --->8---
>>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>> index 334fe3130285..9771f6a82abe 100644
>>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>>           writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
>>>    
>>>           /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
>>> -       dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
>>> -       if (!dll_wait_time_us)
>>> -               dll_wait_time_us = 1;
>>> +       dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
>>>    
>>>           /* Wait for the DLL to settle. */
>>> -       udelay(dll_wait_time_us);
>>> +       usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
>>>    }
>>>    
>>>    static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
>>
>> Eventually it failed, in the same way with with same errors.
>> Took quite a while, over 600 boot cycles.
>>
>> Note also that I had to hand merge the changes, since in 5.1.14 that
>> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
> 
> Oh well. I guess the next thing to do would be to dump the timing regs
> and clk rate that are set by the bootloader (before the driver override
> them) or those applied by an older kernel (one that didn't have that
> issue).

Is this useful?

With attached patch, I get the following dump of the timing
settings in use:

...
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
   HW_GPMI_TIMING0=0x00010203  (calculated=0x00020101)
   HW_GPMI_TIMING1=0x00000000  (calculated=0x60000000)
   HW_GPMI_CTRL1_SET=0x01c4000c  (calculated=0x00000000)
   r->clock[0]=22000000  (calculated=22000000)
random: fast init done
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
   HW_GPMI_TIMING0=0x00010203  (calculated=0x00020101)
   HW_GPMI_TIMING1=0x00000000  (calculated=0xb0000000)
   HW_GPMI_CTRL1_SET=0x01c4000c  (calculated=0x00000000)
   r->clock[0]=22000000  (calculated=22000000)
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
   HW_GPMI_TIMING0=0x00010203  (calculated=0x00010101)
   HW_GPMI_TIMING1=0x00000000  (calculated=0xe0000000)
   HW_GPMI_CTRL1_SET=0x01c4000c  (calculated=0x00c28000)
   r->clock[0]=22000000  (calculated=100000000)
Scanning device for bad blocks
5 fixed-partitions partitions found on MTD device gpmi-nand
Creating 5 MTD partitions on "gpmi-nand":
0x000000000000-0x000000500000 : "u-boot"
0x000000500000-0x000000600000 : "u-boot-env"
0x000000600000-0x000000800000 : "log"
0x000000800000-0x000010000000 : "flash"
0x000000000000-0x000010000000 : "all"
gpmi-nand 1806000.gpmi-nand: driver registered.
...

Regards
Greg



[-- Attachment #2: gpmi-nand-default-timing.patch --]
[-- Type: text/x-patch, Size: 1042 bytes --]

--- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c	2019-03-06 15:47:24.310993476 +1000
+++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c	2019-08-05 15:04:49.241345883 +1000
@@ -486,6 +486,14 @@
 	void __iomem *gpmi_regs = r->gpmi_regs;
 	unsigned int dll_wait_time_us;
 
+#if 1
+	printk("%s(%d): gpmi_nfc_apply_timings()\n", __FILE__, __LINE__);
+	printk("  HW_GPMI_TIMING0=0x%08x  (calculated=0x%08x)\n", readl(gpmi_regs + HW_GPMI_TIMING0), hw->timing0);
+	printk("  HW_GPMI_TIMING1=0x%08x  (calculated=0x%08x)\n", readl(gpmi_regs + HW_GPMI_TIMING1), hw->timing1);
+	printk("  HW_GPMI_CTRL1_SET=0x%08x  (calculated=0x%08x)\n", readl(gpmi_regs + HW_GPMI_CTRL1_SET), hw->ctrl1n);
+	printk("  r->clock[0]=%d  (calculated=%d)\n", clk_get_rate(r->clock[0]), hw->clk_rate);
+#endif
+#if 0
 	clk_set_rate(r->clock[0], hw->clk_rate);
 
 	writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
@@ -505,6 +513,7 @@
 
 	/* Wait for the DLL to settle. */
 	udelay(dll_wait_time_us);
+#endif
 }
 
 int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,

[-- Attachment #3: Type: text/plain, Size: 144 bytes --]

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-08-05  5:51                       ` Greg Ungerer
@ 2019-08-07 16:05                         ` Miquel Raynal
  2019-08-08  0:43                           ` Greg Ungerer
  2019-08-08 16:36                         ` Boris Brezillon
  1 sibling, 1 reply; 85+ messages in thread
From: Miquel Raynal @ 2019-08-07 16:05 UTC (permalink / raw)
  To: Greg Ungerer
  Cc: s.hauer, Boris Brezillon, linux-mtd, Michael Nazzareno Trimarchi,
	Boris Brezillon

Hi Greg,

Greg Ungerer <gerg@kernel.org> wrote on Mon, 5 Aug 2019 15:51:05 +1000:

> Hi Boris,
> 
> On 2/8/19 10:51 pm, Boris Brezillon wrote:
> > On Fri, 2 Aug 2019 22:34:57 +1000
> > Greg Ungerer <gerg@kernel.org> wrote:  
> >> On 31/7/19 4:28 pm, Boris Brezillon wrote:  
> >>> On Wed, 31 Jul 2019 12:05:44 +1000
> >>> Greg Ungerer <gerg@kernel.org> wrote:  
> >>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:  
> >>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:  
> >>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:  
> >>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:  
> >>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:  
> >>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:  
> >>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:  
> >>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:  
> >>>>>>> [snip]  
> >>>> Note that this was generated on a normal boot up (not failure).  
> >>>
> >>> The values looks good. Can you try with the below diff applied?  
> >>> --->8---  
> >>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>> index 334fe3130285..9771f6a82abe 100644
> >>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >>>           writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);  
> >>>    >>>           /* Wait 64 clock cycles before using the GPMI after enabling the DLL */  
> >>> -       dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
> >>> -       if (!dll_wait_time_us)
> >>> -               dll_wait_time_us = 1;
> >>> +       dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);  
> >>>    >>>           /* Wait for the DLL to settle. */  
> >>> -       udelay(dll_wait_time_us);
> >>> +       usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
> >>>    }  
> >>>    >>>    static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,  
> >>
> >> Eventually it failed, in the same way with with same errors.
> >> Took quite a while, over 600 boot cycles.
> >>
> >> Note also that I had to hand merge the changes, since in 5.1.14 that
> >> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.  
> > 
> > Oh well. I guess the next thing to do would be to dump the timing regs
> > and clk rate that are set by the bootloader (before the driver override
> > them) or those applied by an older kernel (one that didn't have that
> > issue).  
> 
> Is this useful?
> 
> With attached patch, I get the following dump of the timing
> settings in use:
> 
> ...
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
>    HW_GPMI_TIMING0=0x00010203  (calculated=0x00020101)
>    HW_GPMI_TIMING1=0x00000000  (calculated=0x60000000)
>    HW_GPMI_CTRL1_SET=0x01c4000c  (calculated=0x00000000)
>    r->clock[0]=22000000  (calculated=22000000)
> random: fast init done
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron MT29F2G08ABAEAWP
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
>    HW_GPMI_TIMING0=0x00010203  (calculated=0x00020101)
>    HW_GPMI_TIMING1=0x00000000  (calculated=0xb0000000)
>    HW_GPMI_CTRL1_SET=0x01c4000c  (calculated=0x00000000)
>    r->clock[0]=22000000  (calculated=22000000)
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
>    HW_GPMI_TIMING0=0x00010203  (calculated=0x00010101)
>    HW_GPMI_TIMING1=0x00000000  (calculated=0xe0000000)
>    HW_GPMI_CTRL1_SET=0x01c4000c  (calculated=0x00c28000)
>    r->clock[0]=22000000  (calculated=100000000)

Why are the registers not updated? Is it the same situation when we
get all the failures?

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-08-07 16:05                         ` Miquel Raynal
@ 2019-08-08  0:43                           ` Greg Ungerer
  0 siblings, 0 replies; 85+ messages in thread
From: Greg Ungerer @ 2019-08-08  0:43 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: s.hauer, Boris Brezillon, linux-mtd, Michael Nazzareno Trimarchi,
	Boris Brezillon

Hi Miquel,

On 8/8/19 2:05 am, Miquel Raynal wrote:
> Greg Ungerer <gerg@kernel.org> wrote on Mon, 5 Aug 2019 15:51:05 +1000:
>> On 2/8/19 10:51 pm, Boris Brezillon wrote:
>>> On Fri, 2 Aug 2019 22:34:57 +1000
>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>> On 31/7/19 4:28 pm, Boris Brezillon wrote:
>>>>> On Wed, 31 Jul 2019 12:05:44 +1000
>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
>>>>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
>>>>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
>>>>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>>>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>>>>>>>> [snip]
>>>>>> Note that this was generated on a normal boot up (not failure).
>>>>>
>>>>> The values looks good. Can you try with the below diff applied?
>>>>> --->8---
>>>>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>> index 334fe3130285..9771f6a82abe 100644
>>>>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>>>>            writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
>>>>>     >>>           /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
>>>>> -       dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
>>>>> -       if (!dll_wait_time_us)
>>>>> -               dll_wait_time_us = 1;
>>>>> +       dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
>>>>>     >>>           /* Wait for the DLL to settle. */
>>>>> -       udelay(dll_wait_time_us);
>>>>> +       usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
>>>>>     }
>>>>>     >>>    static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
>>>>
>>>> Eventually it failed, in the same way with with same errors.
>>>> Took quite a while, over 600 boot cycles.
>>>>
>>>> Note also that I had to hand merge the changes, since in 5.1.14 that
>>>> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
>>>
>>> Oh well. I guess the next thing to do would be to dump the timing regs
>>> and clk rate that are set by the bootloader (before the driver override
>>> them) or those applied by an older kernel (one that didn't have that
>>> issue).
>>
>> Is this useful?
>>
>> With attached patch, I get the following dump of the timing
>> settings in use:
>>
>> ...
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
>>     HW_GPMI_TIMING0=0x00010203  (calculated=0x00020101)
>>     HW_GPMI_TIMING1=0x00000000  (calculated=0x60000000)
>>     HW_GPMI_CTRL1_SET=0x01c4000c  (calculated=0x00000000)
>>     r->clock[0]=22000000  (calculated=22000000)
>> random: fast init done
>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>> nand: Micron MT29F2G08ABAEAWP
>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
>>     HW_GPMI_TIMING0=0x00010203  (calculated=0x00020101)
>>     HW_GPMI_TIMING1=0x00000000  (calculated=0xb0000000)
>>     HW_GPMI_CTRL1_SET=0x01c4000c  (calculated=0x00000000)
>>     r->clock[0]=22000000  (calculated=22000000)
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
>>     HW_GPMI_TIMING0=0x00010203  (calculated=0x00010101)
>>     HW_GPMI_TIMING1=0x00000000  (calculated=0xe0000000)
>>     HW_GPMI_CTRL1_SET=0x01c4000c  (calculated=0x00c28000)
>>     r->clock[0]=22000000  (calculated=100000000)
> 
> Why are the registers not updated? Is it the same situation when we
> get all the failures?

As per the patch that was attached to that email. The setting of the
registers and clock was "#if 0" out so you could see what the
power-up/boot-loader settings are. Those settings work reliably
with no nand failures. In between running various tests I have
left my hardware boot cycle testing with those settings. I don't
have an exact number but it has probably run at least 100 hours
and tens of thousands of boots with no problem using those.

Or am I misunderstanding your question?

Regards
Greg


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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-08-05  5:51                       ` Greg Ungerer
  2019-08-07 16:05                         ` Miquel Raynal
@ 2019-08-08 16:36                         ` Boris Brezillon
  2019-08-09  5:20                           ` Greg Ungerer
  1 sibling, 1 reply; 85+ messages in thread
From: Boris Brezillon @ 2019-08-08 16:36 UTC (permalink / raw)
  To: Greg Ungerer
  Cc: Miquel Raynal, s.hauer, Michael Nazzareno Trimarchi, linux-mtd,
	Boris Brezillon

On Mon, 5 Aug 2019 15:51:05 +1000
Greg Ungerer <gerg@kernel.org> wrote:

> Hi Boris,
> 
> On 2/8/19 10:51 pm, Boris Brezillon wrote:
> > On Fri, 2 Aug 2019 22:34:57 +1000
> > Greg Ungerer <gerg@kernel.org> wrote:  
> >> On 31/7/19 4:28 pm, Boris Brezillon wrote:  
> >>> On Wed, 31 Jul 2019 12:05:44 +1000
> >>> Greg Ungerer <gerg@kernel.org> wrote:  
> >>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:  
> >>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:  
> >>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:  
> >>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:  
> >>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:  
> >>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:  
> >>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:  
> >>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:  
> >>>>>>> [snip]  
> >>>> Note that this was generated on a normal boot up (not failure).  
> >>>
> >>> The values looks good. Can you try with the below diff applied?  
> >>> --->8---  
> >>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>> index 334fe3130285..9771f6a82abe 100644
> >>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >>>           writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
> >>>    
> >>>           /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
> >>> -       dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
> >>> -       if (!dll_wait_time_us)
> >>> -               dll_wait_time_us = 1;
> >>> +       dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
> >>>    
> >>>           /* Wait for the DLL to settle. */
> >>> -       udelay(dll_wait_time_us);
> >>> +       usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
> >>>    }
> >>>    
> >>>    static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,  
> >>
> >> Eventually it failed, in the same way with with same errors.
> >> Took quite a while, over 600 boot cycles.
> >>
> >> Note also that I had to hand merge the changes, since in 5.1.14 that
> >> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.  
> > 
> > Oh well. I guess the next thing to do would be to dump the timing regs
> > and clk rate that are set by the bootloader (before the driver override
> > them) or those applied by an older kernel (one that didn't have that
> > issue).  
> 
> Is this useful?

Hm, looks like it's configured in mode 0, so no, it's not super useful.
Can you try booting an older kernel (one that didn't have the
->setup_data_interface() hook implemented).

> 
> With attached patch, I get the following dump of the timing
> settings in use:
> 
> ...
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
>    HW_GPMI_TIMING0=0x00010203  (calculated=0x00020101)
>    HW_GPMI_TIMING1=0x00000000  (calculated=0x60000000)
>    HW_GPMI_CTRL1_SET=0x01c4000c  (calculated=0x00000000)
>    r->clock[0]=22000000  (calculated=22000000)
> random: fast init done
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron MT29F2G08ABAEAWP
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
>    HW_GPMI_TIMING0=0x00010203  (calculated=0x00020101)
>    HW_GPMI_TIMING1=0x00000000  (calculated=0xb0000000)
>    HW_GPMI_CTRL1_SET=0x01c4000c  (calculated=0x00000000)
>    r->clock[0]=22000000  (calculated=22000000)
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
>    HW_GPMI_TIMING0=0x00010203  (calculated=0x00010101)
>    HW_GPMI_TIMING1=0x00000000  (calculated=0xe0000000)
>    HW_GPMI_CTRL1_SET=0x01c4000c  (calculated=0x00c28000)
>    r->clock[0]=22000000  (calculated=100000000)
> Scanning device for bad blocks
> 5 fixed-partitions partitions found on MTD device gpmi-nand
> Creating 5 MTD partitions on "gpmi-nand":
> 0x000000000000-0x000000500000 : "u-boot"
> 0x000000500000-0x000000600000 : "u-boot-env"
> 0x000000600000-0x000000800000 : "log"
> 0x000000800000-0x000010000000 : "flash"
> 0x000000000000-0x000010000000 : "all"
> gpmi-nand 1806000.gpmi-nand: driver registered.
> ...
> 
> Regards
> Greg
> 
> 


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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-08-08 16:36                         ` Boris Brezillon
@ 2019-08-09  5:20                           ` Greg Ungerer
  2019-08-09  6:23                             ` Boris Brezillon
  0 siblings, 1 reply; 85+ messages in thread
From: Greg Ungerer @ 2019-08-09  5:20 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Miquel Raynal, s.hauer, Michael Nazzareno Trimarchi, linux-mtd,
	Boris Brezillon

Hi Boris,

On 9/8/19 2:36 am, Boris Brezillon wrote:
> On Mon, 5 Aug 2019 15:51:05 +1000
> Greg Ungerer <gerg@kernel.org> wrote:
>> On 2/8/19 10:51 pm, Boris Brezillon wrote:
>>> On Fri, 2 Aug 2019 22:34:57 +1000
>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>> On 31/7/19 4:28 pm, Boris Brezillon wrote:
>>>>> On Wed, 31 Jul 2019 12:05:44 +1000
>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
>>>>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
>>>>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
>>>>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>>>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>>>>>>>> [snip]
>>>>>> Note that this was generated on a normal boot up (not failure).
>>>>>
>>>>> The values looks good. Can you try with the below diff applied?
>>>>> --->8---
>>>>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>> index 334fe3130285..9771f6a82abe 100644
>>>>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>>>>            writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
>>>>>     
>>>>>            /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
>>>>> -       dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
>>>>> -       if (!dll_wait_time_us)
>>>>> -               dll_wait_time_us = 1;
>>>>> +       dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
>>>>>     
>>>>>            /* Wait for the DLL to settle. */
>>>>> -       udelay(dll_wait_time_us);
>>>>> +       usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
>>>>>     }
>>>>>     
>>>>>     static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
>>>>
>>>> Eventually it failed, in the same way with with same errors.
>>>> Took quite a while, over 600 boot cycles.
>>>>
>>>> Note also that I had to hand merge the changes, since in 5.1.14 that
>>>> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
>>>
>>> Oh well. I guess the next thing to do would be to dump the timing regs
>>> and clk rate that are set by the bootloader (before the driver override
>>> them) or those applied by an older kernel (one that didn't have that
>>> issue).
>>
>> Is this useful?
> 
> Hm, looks like it's configured in mode 0, so no, it's not super useful.
> Can you try booting an older kernel (one that didn't have the
> ->setup_data_interface() hook implemented).

Ok. I went back from 5.1 and the first kernel I could find that
returned no grep hits for "setup_data_interface" was 4.16.

So I built for my target with that and added similar trace to dump
the hardware register settings for that. Debug output looks like
this now for it:

...
drivers/mtd/nand/gpmi-nand/gpmi-nand.c(807): gpmi_get_clks()
   clk_get_rate(r->clock[0])=22000000
drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
   HW_GPMI_TIMING0=0x00010203
   HW_GPMI_TIMING1=0x05000000
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
drivers/mtd/nand/gpmi-nand/gpmi-lib.c(966): enable_edo_mode()
   clk_get_rate(r->clock[0])=99000000
gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
   HW_GPMI_TIMING0=0x00010101
   HW_GPMI_TIMING1=0x90000000
Scanning device for bad blocks
5 ofpart partitions found on MTD device gpmi-nand
Creating 5 MTD partitions on "gpmi-nand":
0x000000000000-0x000000500000 : "u-boot"
0x000000500000-0x000000600000 : "u-boot-env"
0x000000600000-0x000000800000 : "log"
0x000000800000-0x000010000000 : "flash"
0x000000000000-0x000010000000 : "all"
gpmi-nand 1806000.gpmi-nand: driver registered.
...


I am running boot tests now on this to confirm it actually runs
reliably.

Regards
Greg



>> With attached patch, I get the following dump of the timing
>> settings in use:
>>
>> ...
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
>>     HW_GPMI_TIMING0=0x00010203  (calculated=0x00020101)
>>     HW_GPMI_TIMING1=0x00000000  (calculated=0x60000000)
>>     HW_GPMI_CTRL1_SET=0x01c4000c  (calculated=0x00000000)
>>     r->clock[0]=22000000  (calculated=22000000)
>> random: fast init done
>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>> nand: Micron MT29F2G08ABAEAWP
>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
>>     HW_GPMI_TIMING0=0x00010203  (calculated=0x00020101)
>>     HW_GPMI_TIMING1=0x00000000  (calculated=0xb0000000)
>>     HW_GPMI_CTRL1_SET=0x01c4000c  (calculated=0x00000000)
>>     r->clock[0]=22000000  (calculated=22000000)
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(490): gpmi_nfc_apply_timings()
>>     HW_GPMI_TIMING0=0x00010203  (calculated=0x00010101)
>>     HW_GPMI_TIMING1=0x00000000  (calculated=0xe0000000)
>>     HW_GPMI_CTRL1_SET=0x01c4000c  (calculated=0x00c28000)
>>     r->clock[0]=22000000  (calculated=100000000)
>> Scanning device for bad blocks
>> 5 fixed-partitions partitions found on MTD device gpmi-nand
>> Creating 5 MTD partitions on "gpmi-nand":
>> 0x000000000000-0x000000500000 : "u-boot"
>> 0x000000500000-0x000000600000 : "u-boot-env"
>> 0x000000600000-0x000000800000 : "log"
>> 0x000000800000-0x000010000000 : "flash"
>> 0x000000000000-0x000010000000 : "all"
>> gpmi-nand 1806000.gpmi-nand: driver registered.
>> ...
>>
>> Regards
>> Greg
>>
>>
> 
> 

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-08-09  5:20                           ` Greg Ungerer
@ 2019-08-09  6:23                             ` Boris Brezillon
  2019-08-09  6:55                               ` Greg Ungerer
  0 siblings, 1 reply; 85+ messages in thread
From: Boris Brezillon @ 2019-08-09  6:23 UTC (permalink / raw)
  To: Greg Ungerer
  Cc: Miquel Raynal, s.hauer, Michael Nazzareno Trimarchi, linux-mtd,
	Boris Brezillon

On Fri, 9 Aug 2019 15:20:52 +1000
Greg Ungerer <gerg@kernel.org> wrote:

> Hi Boris,
> 
> On 9/8/19 2:36 am, Boris Brezillon wrote:
> > On Mon, 5 Aug 2019 15:51:05 +1000
> > Greg Ungerer <gerg@kernel.org> wrote:  
> >> On 2/8/19 10:51 pm, Boris Brezillon wrote:  
> >>> On Fri, 2 Aug 2019 22:34:57 +1000
> >>> Greg Ungerer <gerg@kernel.org> wrote:  
> >>>> On 31/7/19 4:28 pm, Boris Brezillon wrote:  
> >>>>> On Wed, 31 Jul 2019 12:05:44 +1000
> >>>>> Greg Ungerer <gerg@kernel.org> wrote:  
> >>>>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:  
> >>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:  
> >>>>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:  
> >>>>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:  
> >>>>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:  
> >>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:  
> >>>>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:  
> >>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:  
> >>>>>>>>> [snip]  
> >>>>>> Note that this was generated on a normal boot up (not failure).  
> >>>>>
> >>>>> The values looks good. Can you try with the below diff applied?  
> >>>>> --->8---  
> >>>>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>> index 334fe3130285..9771f6a82abe 100644
> >>>>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >>>>>            writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
> >>>>>     
> >>>>>            /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
> >>>>> -       dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
> >>>>> -       if (!dll_wait_time_us)
> >>>>> -               dll_wait_time_us = 1;
> >>>>> +       dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
> >>>>>     
> >>>>>            /* Wait for the DLL to settle. */
> >>>>> -       udelay(dll_wait_time_us);
> >>>>> +       usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
> >>>>>     }
> >>>>>     
> >>>>>     static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,  
> >>>>
> >>>> Eventually it failed, in the same way with with same errors.
> >>>> Took quite a while, over 600 boot cycles.
> >>>>
> >>>> Note also that I had to hand merge the changes, since in 5.1.14 that
> >>>> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.  
> >>>
> >>> Oh well. I guess the next thing to do would be to dump the timing regs
> >>> and clk rate that are set by the bootloader (before the driver override
> >>> them) or those applied by an older kernel (one that didn't have that
> >>> issue).  
> >>
> >> Is this useful?  
> > 
> > Hm, looks like it's configured in mode 0, so no, it's not super useful.
> > Can you try booting an older kernel (one that didn't have the  
> > ->setup_data_interface() hook implemented).  
> 
> Ok. I went back from 5.1 and the first kernel I could find that
> returned no grep hits for "setup_data_interface" was 4.16.
> 
> So I built for my target with that and added similar trace to dump
> the hardware register settings for that. Debug output looks like
> this now for it:
> 
> ...
> drivers/mtd/nand/gpmi-nand/gpmi-nand.c(807): gpmi_get_clks()
>    clk_get_rate(r->clock[0])=22000000
> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>    HW_GPMI_TIMING0=0x00010203
>    HW_GPMI_TIMING1=0x05000000
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron MT29F2G08ABAEAWP
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(966): enable_edo_mode()
>    clk_get_rate(r->clock[0])=99000000
> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>    HW_GPMI_TIMING0=0x00010101

TIMING0 match the one you have with 5.1 kernels.

>    HW_GPMI_TIMING1=0x90000000

And we even have a bigger timeout value in 5.1 (0xe0000000), so we
should be all safe WRT to timings in TIMING{0,1}.

Can you dump CTRL1?

> Scanning device for bad blocks
> 5 ofpart partitions found on MTD device gpmi-nand
> Creating 5 MTD partitions on "gpmi-nand":
> 0x000000000000-0x000000500000 : "u-boot"
> 0x000000500000-0x000000600000 : "u-boot-env"
> 0x000000600000-0x000000800000 : "log"
> 0x000000800000-0x000010000000 : "flash"
> 0x000000000000-0x000010000000 : "all"
> gpmi-nand 1806000.gpmi-nand: driver registered.
> ...
> 


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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-08-09  6:23                             ` Boris Brezillon
@ 2019-08-09  6:55                               ` Greg Ungerer
  2019-08-09  7:32                                 ` Boris Brezillon
  0 siblings, 1 reply; 85+ messages in thread
From: Greg Ungerer @ 2019-08-09  6:55 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Miquel Raynal, s.hauer, Michael Nazzareno Trimarchi, linux-mtd,
	Boris Brezillon


On 9/8/19 4:23 pm, Boris Brezillon wrote:
> On Fri, 9 Aug 2019 15:20:52 +1000
> Greg Ungerer <gerg@kernel.org> wrote:
>> On 9/8/19 2:36 am, Boris Brezillon wrote:
>>> On Mon, 5 Aug 2019 15:51:05 +1000
>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>> On 2/8/19 10:51 pm, Boris Brezillon wrote:
>>>>> On Fri, 2 Aug 2019 22:34:57 +1000
>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>> On 31/7/19 4:28 pm, Boris Brezillon wrote:
>>>>>>> On Wed, 31 Jul 2019 12:05:44 +1000
>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
>>>>>>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
>>>>>>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
>>>>>>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>>>>>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>>>>>>>>>> [snip]
>>>>>>>> Note that this was generated on a normal boot up (not failure).
>>>>>>>
>>>>>>> The values looks good. Can you try with the below diff applied?
>>>>>>> --->8---
>>>>>>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>> index 334fe3130285..9771f6a82abe 100644
>>>>>>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>>>>>>             writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
>>>>>>>      
>>>>>>>             /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
>>>>>>> -       dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
>>>>>>> -       if (!dll_wait_time_us)
>>>>>>> -               dll_wait_time_us = 1;
>>>>>>> +       dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
>>>>>>>      
>>>>>>>             /* Wait for the DLL to settle. */
>>>>>>> -       udelay(dll_wait_time_us);
>>>>>>> +       usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
>>>>>>>      }
>>>>>>>      
>>>>>>>      static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
>>>>>>
>>>>>> Eventually it failed, in the same way with with same errors.
>>>>>> Took quite a while, over 600 boot cycles.
>>>>>>
>>>>>> Note also that I had to hand merge the changes, since in 5.1.14 that
>>>>>> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
>>>>>
>>>>> Oh well. I guess the next thing to do would be to dump the timing regs
>>>>> and clk rate that are set by the bootloader (before the driver override
>>>>> them) or those applied by an older kernel (one that didn't have that
>>>>> issue).
>>>>
>>>> Is this useful?
>>>
>>> Hm, looks like it's configured in mode 0, so no, it's not super useful.
>>> Can you try booting an older kernel (one that didn't have the
>>> ->setup_data_interface() hook implemented).
>>
>> Ok. I went back from 5.1 and the first kernel I could find that
>> returned no grep hits for "setup_data_interface" was 4.16.
>>
>> So I built for my target with that and added similar trace to dump
>> the hardware register settings for that. Debug output looks like
>> this now for it:
>>
>> ...
>> drivers/mtd/nand/gpmi-nand/gpmi-nand.c(807): gpmi_get_clks()
>>     clk_get_rate(r->clock[0])=22000000
>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>>     HW_GPMI_TIMING0=0x00010203
>>     HW_GPMI_TIMING1=0x05000000
>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>> nand: Micron MT29F2G08ABAEAWP
>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(966): enable_edo_mode()
>>     clk_get_rate(r->clock[0])=99000000
>> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>>     HW_GPMI_TIMING0=0x00010101
> 
> TIMING0 match the one you have with 5.1 kernels.
> 
>>     HW_GPMI_TIMING1=0x90000000
> 
> And we even have a bigger timeout value in 5.1 (0xe0000000), so we
> should be all safe WRT to timings in TIMING{0,1}.
> 
> Can you dump CTRL1?

drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
   HW_GPMI_TIMING0=0x00010101
   HW_GPMI_TIMING1=0x90000000
   HW_GPMI_CTRL1_SET=0x01c4800c
Scanning device for bad blocks
5 ofpart partitions found on MTD device gpmi-nand
Creating 5 MTD partitions on "gpmi-nand":
0x000000000000-0x000000500000 : "u-boot"
0x000000500000-0x000000600000 : "u-boot-env"
0x000000600000-0x000000800000 : "log"
0x000000800000-0x000010000000 : "flash"
0x000000000000-0x000010000000 : "all"
gpmi-nand 1806000.gpmi-nand: driver registered.

Regards
Greg


>> Scanning device for bad blocks
>> 5 ofpart partitions found on MTD device gpmi-nand
>> Creating 5 MTD partitions on "gpmi-nand":
>> 0x000000000000-0x000000500000 : "u-boot"
>> 0x000000500000-0x000000600000 : "u-boot-env"
>> 0x000000600000-0x000000800000 : "log"
>> 0x000000800000-0x000010000000 : "flash"
>> 0x000000000000-0x000010000000 : "all"
>> gpmi-nand 1806000.gpmi-nand: driver registered.
>> ...
>>
> 
> 

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-08-09  6:55                               ` Greg Ungerer
@ 2019-08-09  7:32                                 ` Boris Brezillon
  2019-08-09 13:57                                   ` Greg Ungerer
  0 siblings, 1 reply; 85+ messages in thread
From: Boris Brezillon @ 2019-08-09  7:32 UTC (permalink / raw)
  To: Greg Ungerer
  Cc: Miquel Raynal, s.hauer, Michael Nazzareno Trimarchi, linux-mtd,
	Boris Brezillon

On Fri, 9 Aug 2019 16:55:22 +1000
Greg Ungerer <gerg@kernel.org> wrote:

> On 9/8/19 4:23 pm, Boris Brezillon wrote:
> > On Fri, 9 Aug 2019 15:20:52 +1000
> > Greg Ungerer <gerg@kernel.org> wrote:  
> >> On 9/8/19 2:36 am, Boris Brezillon wrote:  
> >>> On Mon, 5 Aug 2019 15:51:05 +1000
> >>> Greg Ungerer <gerg@kernel.org> wrote:  
> >>>> On 2/8/19 10:51 pm, Boris Brezillon wrote:  
> >>>>> On Fri, 2 Aug 2019 22:34:57 +1000
> >>>>> Greg Ungerer <gerg@kernel.org> wrote:  
> >>>>>> On 31/7/19 4:28 pm, Boris Brezillon wrote:  
> >>>>>>> On Wed, 31 Jul 2019 12:05:44 +1000
> >>>>>>> Greg Ungerer <gerg@kernel.org> wrote:  
> >>>>>>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:  
> >>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:  
> >>>>>>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:  
> >>>>>>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:  
> >>>>>>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:  
> >>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:  
> >>>>>>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:  
> >>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:  
> >>>>>>>>>>> [snip]  
> >>>>>>>> Note that this was generated on a normal boot up (not failure).  
> >>>>>>>
> >>>>>>> The values looks good. Can you try with the below diff applied?  
> >>>>>>> --->8---  
> >>>>>>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>>>> index 334fe3130285..9771f6a82abe 100644
> >>>>>>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>>>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>>>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >>>>>>>             writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
> >>>>>>>      
> >>>>>>>             /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
> >>>>>>> -       dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
> >>>>>>> -       if (!dll_wait_time_us)
> >>>>>>> -               dll_wait_time_us = 1;
> >>>>>>> +       dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
> >>>>>>>      
> >>>>>>>             /* Wait for the DLL to settle. */
> >>>>>>> -       udelay(dll_wait_time_us);
> >>>>>>> +       usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
> >>>>>>>      }
> >>>>>>>      
> >>>>>>>      static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,  
> >>>>>>
> >>>>>> Eventually it failed, in the same way with with same errors.
> >>>>>> Took quite a while, over 600 boot cycles.
> >>>>>>
> >>>>>> Note also that I had to hand merge the changes, since in 5.1.14 that
> >>>>>> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.  
> >>>>>
> >>>>> Oh well. I guess the next thing to do would be to dump the timing regs
> >>>>> and clk rate that are set by the bootloader (before the driver override
> >>>>> them) or those applied by an older kernel (one that didn't have that
> >>>>> issue).  
> >>>>
> >>>> Is this useful?  
> >>>
> >>> Hm, looks like it's configured in mode 0, so no, it's not super useful.
> >>> Can you try booting an older kernel (one that didn't have the  
> >>> ->setup_data_interface() hook implemented).  
> >>
> >> Ok. I went back from 5.1 and the first kernel I could find that
> >> returned no grep hits for "setup_data_interface" was 4.16.
> >>
> >> So I built for my target with that and added similar trace to dump
> >> the hardware register settings for that. Debug output looks like
> >> this now for it:
> >>
> >> ...
> >> drivers/mtd/nand/gpmi-nand/gpmi-nand.c(807): gpmi_get_clks()
> >>     clk_get_rate(r->clock[0])=22000000
> >> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
> >>     HW_GPMI_TIMING0=0x00010203
> >>     HW_GPMI_TIMING1=0x05000000
> >> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> >> nand: Micron MT29F2G08ABAEAWP
> >> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> >> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(966): enable_edo_mode()
> >>     clk_get_rate(r->clock[0])=99000000
> >> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
> >> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
> >>     HW_GPMI_TIMING0=0x00010101  
> > 
> > TIMING0 match the one you have with 5.1 kernels.
> >   
> >>     HW_GPMI_TIMING1=0x90000000  
> > 
> > And we even have a bigger timeout value in 5.1 (0xe0000000), so we
> > should be all safe WRT to timings in TIMING{0,1}.
> > 
> > Can you dump CTRL1?  
> 
> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>    HW_GPMI_TIMING0=0x00010101
>    HW_GPMI_TIMING1=0x90000000
>    HW_GPMI_CTRL1_SET=0x01c4800c

The read/write delay fields seem to match, but there are a few more
fields set in this version:
- DECOUPLE_CS
- BCH_MODE
- DEV_RESET
- CTRL1_ATA_IRQRDY_POLARITY__ACTIVEHIGH

Looks like those fields are not explicitly set in the gpmi_begin()
patch, but maybe you dumped CTRL1. Would you mind sharing your patch?
If I'm right and you indeed dumped CTRL1, it might be worth doing the
same in your 5.1 kernel so we can more easily compare those dumps.
While at it, can you dump CTRL1 before and after applying the changes?

> Scanning device for bad blocks
> 5 ofpart partitions found on MTD device gpmi-nand
> Creating 5 MTD partitions on "gpmi-nand":
> 0x000000000000-0x000000500000 : "u-boot"
> 0x000000500000-0x000000600000 : "u-boot-env"
> 0x000000600000-0x000000800000 : "log"
> 0x000000800000-0x000010000000 : "flash"
> 0x000000000000-0x000010000000 : "all"
> gpmi-nand 1806000.gpmi-nand: driver registered.
> 
> Regards
> Greg
> 
> 
> >> Scanning device for bad blocks
> >> 5 ofpart partitions found on MTD device gpmi-nand
> >> Creating 5 MTD partitions on "gpmi-nand":
> >> 0x000000000000-0x000000500000 : "u-boot"
> >> 0x000000500000-0x000000600000 : "u-boot-env"
> >> 0x000000600000-0x000000800000 : "log"
> >> 0x000000800000-0x000010000000 : "flash"
> >> 0x000000000000-0x000010000000 : "all"
> >> gpmi-nand 1806000.gpmi-nand: driver registered.
> >> ...
> >>  
> > 
> >   


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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-08-09  7:32                                 ` Boris Brezillon
@ 2019-08-09 13:57                                   ` Greg Ungerer
  2019-08-09 13:59                                     ` Boris Brezillon
  0 siblings, 1 reply; 85+ messages in thread
From: Greg Ungerer @ 2019-08-09 13:57 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Miquel Raynal, s.hauer, Michael Nazzareno Trimarchi, linux-mtd,
	Boris Brezillon

[-- Attachment #1: Type: text/plain, Size: 5440 bytes --]

Hi Boris,

On 9/8/19 5:32 pm, Boris Brezillon wrote:
> On Fri, 9 Aug 2019 16:55:22 +1000
> Greg Ungerer <gerg@kernel.org> wrote:
>> On 9/8/19 4:23 pm, Boris Brezillon wrote:
>>> On Fri, 9 Aug 2019 15:20:52 +1000
>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>> On 9/8/19 2:36 am, Boris Brezillon wrote:
>>>>> On Mon, 5 Aug 2019 15:51:05 +1000
>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>> On 2/8/19 10:51 pm, Boris Brezillon wrote:
>>>>>>> On Fri, 2 Aug 2019 22:34:57 +1000
>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>>>> On 31/7/19 4:28 pm, Boris Brezillon wrote:
>>>>>>>>> On Wed, 31 Jul 2019 12:05:44 +1000
>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>>>>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
>>>>>>>>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
>>>>>>>>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
>>>>>>>>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>>>>>>>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>>>>>>>>>>>> [snip]
>>>>>>>>>> Note that this was generated on a normal boot up (not failure).
>>>>>>>>>
>>>>>>>>> The values looks good. Can you try with the below diff applied?
>>>>>>>>> --->8---
>>>>>>>>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>>>> index 334fe3130285..9771f6a82abe 100644
>>>>>>>>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>>>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>>>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>>>>>>>>              writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
>>>>>>>>>       
>>>>>>>>>              /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
>>>>>>>>> -       dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
>>>>>>>>> -       if (!dll_wait_time_us)
>>>>>>>>> -               dll_wait_time_us = 1;
>>>>>>>>> +       dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
>>>>>>>>>       
>>>>>>>>>              /* Wait for the DLL to settle. */
>>>>>>>>> -       udelay(dll_wait_time_us);
>>>>>>>>> +       usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
>>>>>>>>>       }
>>>>>>>>>       
>>>>>>>>>       static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
>>>>>>>>
>>>>>>>> Eventually it failed, in the same way with with same errors.
>>>>>>>> Took quite a while, over 600 boot cycles.
>>>>>>>>
>>>>>>>> Note also that I had to hand merge the changes, since in 5.1.14 that
>>>>>>>> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
>>>>>>>
>>>>>>> Oh well. I guess the next thing to do would be to dump the timing regs
>>>>>>> and clk rate that are set by the bootloader (before the driver override
>>>>>>> them) or those applied by an older kernel (one that didn't have that
>>>>>>> issue).
>>>>>>
>>>>>> Is this useful?
>>>>>
>>>>> Hm, looks like it's configured in mode 0, so no, it's not super useful.
>>>>> Can you try booting an older kernel (one that didn't have the
>>>>> ->setup_data_interface() hook implemented).
>>>>
>>>> Ok. I went back from 5.1 and the first kernel I could find that
>>>> returned no grep hits for "setup_data_interface" was 4.16.
>>>>
>>>> So I built for my target with that and added similar trace to dump
>>>> the hardware register settings for that. Debug output looks like
>>>> this now for it:
>>>>
>>>> ...
>>>> drivers/mtd/nand/gpmi-nand/gpmi-nand.c(807): gpmi_get_clks()
>>>>      clk_get_rate(r->clock[0])=22000000
>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>>>>      HW_GPMI_TIMING0=0x00010203
>>>>      HW_GPMI_TIMING1=0x05000000
>>>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>>>> nand: Micron MT29F2G08ABAEAWP
>>>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(966): enable_edo_mode()
>>>>      clk_get_rate(r->clock[0])=99000000
>>>> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>>>>      HW_GPMI_TIMING0=0x00010101
>>>
>>> TIMING0 match the one you have with 5.1 kernels.
>>>    
>>>>      HW_GPMI_TIMING1=0x90000000
>>>
>>> And we even have a bigger timeout value in 5.1 (0xe0000000), so we
>>> should be all safe WRT to timings in TIMING{0,1}.
>>>
>>> Can you dump CTRL1?
>>
>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>>     HW_GPMI_TIMING0=0x00010101
>>     HW_GPMI_TIMING1=0x90000000
>>     HW_GPMI_CTRL1_SET=0x01c4800c
> 
> The read/write delay fields seem to match, but there are a few more
> fields set in this version:
> - DECOUPLE_CS
> - BCH_MODE
> - DEV_RESET
> - CTRL1_ATA_IRQRDY_POLARITY__ACTIVEHIGH
> 
> Looks like those fields are not explicitly set in the gpmi_begin()
> patch, but maybe you dumped CTRL1. Would you mind sharing your patch?

Attached.


> If I'm right and you indeed dumped CTRL1, it might be worth doing the
> same in your 5.1 kernel so we can more easily compare those dumps.
> While at it, can you dump CTRL1 before and after applying the changes?

Will do. I am out of my lab for the weekend, but I'll get
those numbers first thing Monday morning.

Regards
Greg


[-- Attachment #2: gpmi-416.patch --]
[-- Type: text/x-patch, Size: 2481 bytes --]

--- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c
@@ -963,6 +963,7 @@ static int enable_edo_mode(struct gpmi_n
 	unsigned long rate;
 	int ret;
 
+printk("%s(%d): enable_edo_mode()\n", __FILE__, __LINE__);
 	feature = kzalloc(ONFI_SUBFEATURE_PARAM_LEN, GFP_KERNEL);
 	if (!feature)
 		return -ENOMEM;
@@ -988,6 +989,7 @@ static int enable_edo_mode(struct gpmi_n
 	/* [3] set the main IO clock, 100MHz for mode 5, 80MHz for mode 4. */
 	rate = (mode == 5) ? 100000000 : 80000000;
 	clk_set_rate(r->clock[0], rate);
+printk("  clk_get_rate(r->clock[0])=%ld\n", clk_get_rate(r->clock[0]));
 
 	/* Let the gpmi_begin() re-compute the timing again. */
 	this->flags &= ~GPMI_TIMING_INIT_OK;
@@ -1049,6 +1051,7 @@ void gpmi_begin(struct gpmi_nand_data *t
 		return;
 	this->flags |= GPMI_TIMING_INIT_OK;
 
+printk("%s(%d): gpmi_begin()\n", __FILE__, __LINE__);
 	if (this->flags & GPMI_ASYNC_EDO_ENABLED)
 		gpmi_compute_edo_timing(this, &hw);
 	else
@@ -1060,10 +1063,12 @@ void gpmi_begin(struct gpmi_nand_data *t
 		BF_GPMI_TIMING0_DATA_SETUP(hw.data_setup_in_cycles);
 
 	writel(reg, gpmi_regs + HW_GPMI_TIMING0);
+printk("  HW_GPMI_TIMING0=0x%08x\n", readl(gpmi_regs + HW_GPMI_TIMING0));
 
 	/* [2] Set HW_GPMI_TIMING1 */
 	writel(BF_GPMI_TIMING1_BUSY_TIMEOUT(hw.device_busy_timeout),
 		gpmi_regs + HW_GPMI_TIMING1);
+printk("  HW_GPMI_TIMING1=0x%08x\n", readl(gpmi_regs + HW_GPMI_TIMING1));
 
 	/* [3] The following code is to set the HW_GPMI_CTRL1. */
 
@@ -1088,6 +1093,7 @@ void gpmi_begin(struct gpmi_nand_data *t
 		| BF_GPMI_CTRL1_RDN_DELAY(hw.sample_delay_factor);
 
 	writel(reg, gpmi_regs + HW_GPMI_CTRL1_SET);
+printk("  HW_GPMI_CTRL1_SET=0x%08x\n", readl(gpmi_regs + HW_GPMI_CTRL1_SET));
 
 	/* At last, we enable the DLL. */
 	writel(BM_GPMI_CTRL1_DLL_ENABLE, gpmi_regs + HW_GPMI_CTRL1_SET);
--- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c
@@ -804,6 +804,7 @@ static int gpmi_get_clks(struct gpmi_nan
 	struct clk *clk;
 	int err, i;
 
+printk("%s(%d): gpmi_get_clks()\n", __FILE__, __LINE__);
 	for (i = 0; i < this->devdata->clks_count; i++) {
 		clk = devm_clk_get(this->dev, this->devdata->clks[i]);
 		if (IS_ERR(clk)) {
@@ -822,6 +823,7 @@ static int gpmi_get_clks(struct gpmi_nan
 		 * Synchronous Mode, you should change the clock as you need.
 		 */
 		clk_set_rate(r->clock[0], 22000000);
+printk("  clk_get_rate(r->clock[0])=%ld\n", clk_get_rate(r->clock[0]));
 
 	return 0;
 

[-- Attachment #3: Type: text/plain, Size: 144 bytes --]

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-08-09 13:57                                   ` Greg Ungerer
@ 2019-08-09 13:59                                     ` Boris Brezillon
  2019-08-12  2:50                                       ` Greg Ungerer
  0 siblings, 1 reply; 85+ messages in thread
From: Boris Brezillon @ 2019-08-09 13:59 UTC (permalink / raw)
  To: Greg Ungerer
  Cc: Miquel Raynal, s.hauer, Michael Nazzareno Trimarchi, linux-mtd,
	Boris Brezillon

On Fri, 9 Aug 2019 23:57:08 +1000
Greg Ungerer <gerg@kernel.org> wrote:

> Hi Boris,
> 
> On 9/8/19 5:32 pm, Boris Brezillon wrote:
> > On Fri, 9 Aug 2019 16:55:22 +1000
> > Greg Ungerer <gerg@kernel.org> wrote:
> >> On 9/8/19 4:23 pm, Boris Brezillon wrote:
> >>> On Fri, 9 Aug 2019 15:20:52 +1000
> >>> Greg Ungerer <gerg@kernel.org> wrote:
> >>>> On 9/8/19 2:36 am, Boris Brezillon wrote:
> >>>>> On Mon, 5 Aug 2019 15:51:05 +1000
> >>>>> Greg Ungerer <gerg@kernel.org> wrote:
> >>>>>> On 2/8/19 10:51 pm, Boris Brezillon wrote:
> >>>>>>> On Fri, 2 Aug 2019 22:34:57 +1000
> >>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
> >>>>>>>> On 31/7/19 4:28 pm, Boris Brezillon wrote:
> >>>>>>>>> On Wed, 31 Jul 2019 12:05:44 +1000
> >>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
> >>>>>>>>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
> >>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
> >>>>>>>>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
> >>>>>>>>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
> >>>>>>>>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
> >>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
> >>>>>>>>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
> >>>>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
> >>>>>>>>>>>>> [snip]
> >>>>>>>>>> Note that this was generated on a normal boot up (not failure).
> >>>>>>>>>
> >>>>>>>>> The values looks good. Can you try with the below diff applied?
> >>>>>>>>> --->8---
> >>>>>>>>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>>>>>> index 334fe3130285..9771f6a82abe 100644
> >>>>>>>>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>>>>>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>>>>>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >>>>>>>>>              writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
> >>>>>>>>>       
> >>>>>>>>>              /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
> >>>>>>>>> -       dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
> >>>>>>>>> -       if (!dll_wait_time_us)
> >>>>>>>>> -               dll_wait_time_us = 1;
> >>>>>>>>> +       dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
> >>>>>>>>>       
> >>>>>>>>>              /* Wait for the DLL to settle. */
> >>>>>>>>> -       udelay(dll_wait_time_us);
> >>>>>>>>> +       usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
> >>>>>>>>>       }
> >>>>>>>>>       
> >>>>>>>>>       static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
> >>>>>>>>
> >>>>>>>> Eventually it failed, in the same way with with same errors.
> >>>>>>>> Took quite a while, over 600 boot cycles.
> >>>>>>>>
> >>>>>>>> Note also that I had to hand merge the changes, since in 5.1.14 that
> >>>>>>>> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
> >>>>>>>
> >>>>>>> Oh well. I guess the next thing to do would be to dump the timing regs
> >>>>>>> and clk rate that are set by the bootloader (before the driver override
> >>>>>>> them) or those applied by an older kernel (one that didn't have that
> >>>>>>> issue).
> >>>>>>
> >>>>>> Is this useful?
> >>>>>
> >>>>> Hm, looks like it's configured in mode 0, so no, it's not super useful.
> >>>>> Can you try booting an older kernel (one that didn't have the
> >>>>> ->setup_data_interface() hook implemented).
> >>>>
> >>>> Ok. I went back from 5.1 and the first kernel I could find that
> >>>> returned no grep hits for "setup_data_interface" was 4.16.
> >>>>
> >>>> So I built for my target with that and added similar trace to dump
> >>>> the hardware register settings for that. Debug output looks like
> >>>> this now for it:
> >>>>
> >>>> ...
> >>>> drivers/mtd/nand/gpmi-nand/gpmi-nand.c(807): gpmi_get_clks()
> >>>>      clk_get_rate(r->clock[0])=22000000
> >>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
> >>>>      HW_GPMI_TIMING0=0x00010203
> >>>>      HW_GPMI_TIMING1=0x05000000
> >>>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> >>>> nand: Micron MT29F2G08ABAEAWP
> >>>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> >>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(966): enable_edo_mode()
> >>>>      clk_get_rate(r->clock[0])=99000000
> >>>> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
> >>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
> >>>>      HW_GPMI_TIMING0=0x00010101
> >>>
> >>> TIMING0 match the one you have with 5.1 kernels.
> >>>    
> >>>>      HW_GPMI_TIMING1=0x90000000
> >>>
> >>> And we even have a bigger timeout value in 5.1 (0xe0000000), so we
> >>> should be all safe WRT to timings in TIMING{0,1}.
> >>>
> >>> Can you dump CTRL1?
> >>
> >> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
> >>     HW_GPMI_TIMING0=0x00010101
> >>     HW_GPMI_TIMING1=0x90000000
> >>     HW_GPMI_CTRL1_SET=0x01c4800c
> > 
> > The read/write delay fields seem to match, but there are a few more
> > fields set in this version:
> > - DECOUPLE_CS
> > - BCH_MODE
> > - DEV_RESET
> > - CTRL1_ATA_IRQRDY_POLARITY__ACTIVEHIGH
> > 
> > Looks like those fields are not explicitly set in the gpmi_begin()
> > patch, but maybe you dumped CTRL1. Would you mind sharing your patch?
> 
> Attached.

Hm, you should read CTRL1 instead of CTRL1_SET which I guess is WO.

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-08-09 13:59                                     ` Boris Brezillon
@ 2019-08-12  2:50                                       ` Greg Ungerer
  2019-08-12  4:04                                         ` Greg Ungerer
  2019-08-12  7:31                                         ` Boris Brezillon
  0 siblings, 2 replies; 85+ messages in thread
From: Greg Ungerer @ 2019-08-12  2:50 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Miquel Raynal, s.hauer, Michael Nazzareno Trimarchi, linux-mtd,
	Boris Brezillon

Hi Boris,

On 9/8/19 11:59 pm, Boris Brezillon wrote:
> On Fri, 9 Aug 2019 23:57:08 +1000
> Greg Ungerer <gerg@kernel.org> wrote:
>> On 9/8/19 5:32 pm, Boris Brezillon wrote:
>>> On Fri, 9 Aug 2019 16:55:22 +1000
>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>> On 9/8/19 4:23 pm, Boris Brezillon wrote:
>>>>> On Fri, 9 Aug 2019 15:20:52 +1000
>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>> On 9/8/19 2:36 am, Boris Brezillon wrote:
>>>>>>> On Mon, 5 Aug 2019 15:51:05 +1000
>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>>>> On 2/8/19 10:51 pm, Boris Brezillon wrote:
>>>>>>>>> On Fri, 2 Aug 2019 22:34:57 +1000
>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>>>>>> On 31/7/19 4:28 pm, Boris Brezillon wrote:
>>>>>>>>>>> On Wed, 31 Jul 2019 12:05:44 +1000
>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>>>>>>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
>>>>>>>>>>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
>>>>>>>>>>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
>>>>>>>>>>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>>>>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>>>>>>>>>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>>>>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>>>>>>>>>>>>>> [snip]
>>>>>>>>>>>> Note that this was generated on a normal boot up (not failure).
>>>>>>>>>>>
>>>>>>>>>>> The values looks good. Can you try with the below diff applied?
>>>>>>>>>>> --->8---
>>>>>>>>>>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>>>>>> index 334fe3130285..9771f6a82abe 100644
>>>>>>>>>>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>>>>>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>>>>>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>>>>>>>>>>               writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
>>>>>>>>>>>        
>>>>>>>>>>>               /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
>>>>>>>>>>> -       dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
>>>>>>>>>>> -       if (!dll_wait_time_us)
>>>>>>>>>>> -               dll_wait_time_us = 1;
>>>>>>>>>>> +       dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
>>>>>>>>>>>        
>>>>>>>>>>>               /* Wait for the DLL to settle. */
>>>>>>>>>>> -       udelay(dll_wait_time_us);
>>>>>>>>>>> +       usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
>>>>>>>>>>>        }
>>>>>>>>>>>        
>>>>>>>>>>>        static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
>>>>>>>>>>
>>>>>>>>>> Eventually it failed, in the same way with with same errors.
>>>>>>>>>> Took quite a while, over 600 boot cycles.
>>>>>>>>>>
>>>>>>>>>> Note also that I had to hand merge the changes, since in 5.1.14 that
>>>>>>>>>> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
>>>>>>>>>
>>>>>>>>> Oh well. I guess the next thing to do would be to dump the timing regs
>>>>>>>>> and clk rate that are set by the bootloader (before the driver override
>>>>>>>>> them) or those applied by an older kernel (one that didn't have that
>>>>>>>>> issue).
>>>>>>>>
>>>>>>>> Is this useful?
>>>>>>>
>>>>>>> Hm, looks like it's configured in mode 0, so no, it's not super useful.
>>>>>>> Can you try booting an older kernel (one that didn't have the
>>>>>>> ->setup_data_interface() hook implemented).
>>>>>>
>>>>>> Ok. I went back from 5.1 and the first kernel I could find that
>>>>>> returned no grep hits for "setup_data_interface" was 4.16.
>>>>>>
>>>>>> So I built for my target with that and added similar trace to dump
>>>>>> the hardware register settings for that. Debug output looks like
>>>>>> this now for it:
>>>>>>
>>>>>> ...
>>>>>> drivers/mtd/nand/gpmi-nand/gpmi-nand.c(807): gpmi_get_clks()
>>>>>>       clk_get_rate(r->clock[0])=22000000
>>>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>>>>>>       HW_GPMI_TIMING0=0x00010203
>>>>>>       HW_GPMI_TIMING1=0x05000000
>>>>>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>>>>>> nand: Micron MT29F2G08ABAEAWP
>>>>>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>>>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(966): enable_edo_mode()
>>>>>>       clk_get_rate(r->clock[0])=99000000
>>>>>> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
>>>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>>>>>>       HW_GPMI_TIMING0=0x00010101
>>>>>
>>>>> TIMING0 match the one you have with 5.1 kernels.
>>>>>     
>>>>>>       HW_GPMI_TIMING1=0x90000000
>>>>>
>>>>> And we even have a bigger timeout value in 5.1 (0xe0000000), so we
>>>>> should be all safe WRT to timings in TIMING{0,1}.
>>>>>
>>>>> Can you dump CTRL1?
>>>>
>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>>>>      HW_GPMI_TIMING0=0x00010101
>>>>      HW_GPMI_TIMING1=0x90000000
>>>>      HW_GPMI_CTRL1_SET=0x01c4800c
>>>
>>> The read/write delay fields seem to match, but there are a few more
>>> fields set in this version:
>>> - DECOUPLE_CS
>>> - BCH_MODE
>>> - DEV_RESET
>>> - CTRL1_ATA_IRQRDY_POLARITY__ACTIVEHIGH
>>>
>>> Looks like those fields are not explicitly set in the gpmi_begin()
>>> patch, but maybe you dumped CTRL1. Would you mind sharing your patch?
>>
>> Attached.
> 
> Hm, you should read CTRL1 instead of CTRL1_SET which I guess is WO.


Here is 2 sets of trace dumping the same set of registers.
This first is on the linux-4.16 kernel:

Linux version 4.16.0 (gerg@goober) (gcc version 4.8.3 (GCC)) #9 Mon Aug 12 10:46:25 AEST 2019
...
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1110): gpmi_begin()
   HW_GPMI_TIMING0=0x00010101
   HW_GPMI_TIMING1=0x90000000
   HW_GPMI_CTRL1=0x01c6800c
   r->clock[0]=99000000
Scanning device for bad blocks
5 ofpart partitions found on MTD device gpmi-nand
Creating 5 MTD partitions on "gpmi-nand":
0x000000000000-0x000000500000 : "u-boot"
0x000000500000-0x000000600000 : "u-boot-env"
0x000000600000-0x000000800000 : "log"
0x000000800000-0x000010000000 : "flash"
0x000000000000-0x000010000000 : "all"
gpmi-nand 1806000.gpmi-nand: driver registered.
...


And then this is from the 5.1.14 kernel:

Linux version 5.1.14 (gerg@goober) (gcc version 4.8.3 (GCC)) #25 Mon Aug 12 10:49:21 AEST 2019
...
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(510): gpmi_nfc_apply_timings()
   HW_GPMI_TIMING0=0x00020101
   HW_GPMI_TIMING1=0xb0000000
   HW_GPMI_CTRL1=0x0104000c
   r->clock[0]=22000000
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(510): gpmi_nfc_apply_timings()
   HW_GPMI_TIMING0=0x00010101
   HW_GPMI_TIMING1=0xe0000000
   HW_GPMI_CTRL1=0x01c6800c
   r->clock[0]=99000000
Scanning device for bad blocks
5 fixed-partitions partitions found on MTD device gpmi-nand
Creating 5 MTD partitions on "gpmi-nand":
0x000000000000-0x000000500000 : "u-boot"
0x000000500000-0x000000600000 : "u-boot-env"
0x000000600000-0x000000800000 : "log"
0x000000800000-0x000010000000 : "flash"
0x000000000000-0x000010000000 : "all"
gpmi-nand 1806000.gpmi-nand: driver registered.


Register settings read back from the registers themselves at the end
of the respective setting routines (so gpmi_begin() for 4.16 and
gpmi_nfc_apply_timings() for 5.1.14)

So something I notice here is that gpmi_nfc_apply_timings() is
being run multiple times. When I look back to the original
failure dumps the first error ("DMA timeout, last DMA") occurred
after the device type messages ("nand: 256 MiB, SLC,..."). Is it
happening with that higher clock rate still set?

Regards
Greg






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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-08-12  2:50                                       ` Greg Ungerer
@ 2019-08-12  4:04                                         ` Greg Ungerer
  2019-08-12  7:31                                         ` Boris Brezillon
  1 sibling, 0 replies; 85+ messages in thread
From: Greg Ungerer @ 2019-08-12  4:04 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Miquel Raynal, s.hauer, Michael Nazzareno Trimarchi, linux-mtd,
	Boris Brezillon


On 12/8/19 12:50 pm, Greg Ungerer wrote:
> On 9/8/19 11:59 pm, Boris Brezillon wrote:
>> On Fri, 9 Aug 2019 23:57:08 +1000
>> Greg Ungerer <gerg@kernel.org> wrote:
>>> On 9/8/19 5:32 pm, Boris Brezillon wrote:
>>>> On Fri, 9 Aug 2019 16:55:22 +1000
>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>> On 9/8/19 4:23 pm, Boris Brezillon wrote:
>>>>>> On Fri, 9 Aug 2019 15:20:52 +1000
>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>>> On 9/8/19 2:36 am, Boris Brezillon wrote:
>>>>>>>> On Mon, 5 Aug 2019 15:51:05 +1000
>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>>>>> On 2/8/19 10:51 pm, Boris Brezillon wrote:
>>>>>>>>>> On Fri, 2 Aug 2019 22:34:57 +1000
>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>>>>>>> On 31/7/19 4:28 pm, Boris Brezillon wrote:
>>>>>>>>>>>> On Wed, 31 Jul 2019 12:05:44 +1000
>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:
>>>>>>>>>>>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:
>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:
>>>>>>>>>>>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:
>>>>>>>>>>>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:
>>>>>>>>>>>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:
>>>>>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:
>>>>>>>>>>>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:
>>>>>>>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:
>>>>>>>>>>>>>>>> [snip]
>>>>>>>>>>>>> Note that this was generated on a normal boot up (not failure).
>>>>>>>>>>>>
>>>>>>>>>>>> The values looks good. Can you try with the below diff applied?
>>>>>>>>>>>> --->8---
>>>>>>>>>>>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>>>>>>> index 334fe3130285..9771f6a82abe 100644
>>>>>>>>>>>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>>>>>>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
>>>>>>>>>>>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>>>>>>>>>>>>               writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
>>>>>>>>>>>>               /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
>>>>>>>>>>>> -       dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
>>>>>>>>>>>> -       if (!dll_wait_time_us)
>>>>>>>>>>>> -               dll_wait_time_us = 1;
>>>>>>>>>>>> +       dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
>>>>>>>>>>>>               /* Wait for the DLL to settle. */
>>>>>>>>>>>> -       udelay(dll_wait_time_us);
>>>>>>>>>>>> +       usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
>>>>>>>>>>>>        }
>>>>>>>>>>>>        static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,
>>>>>>>>>>>
>>>>>>>>>>> Eventually it failed, in the same way with with same errors.
>>>>>>>>>>> Took quite a while, over 600 boot cycles.
>>>>>>>>>>>
>>>>>>>>>>> Note also that I had to hand merge the changes, since in 5.1.14 that
>>>>>>>>>>> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.
>>>>>>>>>>
>>>>>>>>>> Oh well. I guess the next thing to do would be to dump the timing regs
>>>>>>>>>> and clk rate that are set by the bootloader (before the driver override
>>>>>>>>>> them) or those applied by an older kernel (one that didn't have that
>>>>>>>>>> issue).
>>>>>>>>>
>>>>>>>>> Is this useful?
>>>>>>>>
>>>>>>>> Hm, looks like it's configured in mode 0, so no, it's not super useful.
>>>>>>>> Can you try booting an older kernel (one that didn't have the
>>>>>>>> ->setup_data_interface() hook implemented).
>>>>>>>
>>>>>>> Ok. I went back from 5.1 and the first kernel I could find that
>>>>>>> returned no grep hits for "setup_data_interface" was 4.16.
>>>>>>>
>>>>>>> So I built for my target with that and added similar trace to dump
>>>>>>> the hardware register settings for that. Debug output looks like
>>>>>>> this now for it:
>>>>>>>
>>>>>>> ...
>>>>>>> drivers/mtd/nand/gpmi-nand/gpmi-nand.c(807): gpmi_get_clks()
>>>>>>>       clk_get_rate(r->clock[0])=22000000
>>>>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>>>>>>>       HW_GPMI_TIMING0=0x00010203
>>>>>>>       HW_GPMI_TIMING1=0x05000000
>>>>>>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>>>>>>> nand: Micron MT29F2G08ABAEAWP
>>>>>>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>>>>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(966): enable_edo_mode()
>>>>>>>       clk_get_rate(r->clock[0])=99000000
>>>>>>> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
>>>>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>>>>>>>       HW_GPMI_TIMING0=0x00010101
>>>>>>
>>>>>> TIMING0 match the one you have with 5.1 kernels.
>>>>>>>       HW_GPMI_TIMING1=0x90000000
>>>>>>
>>>>>> And we even have a bigger timeout value in 5.1 (0xe0000000), so we
>>>>>> should be all safe WRT to timings in TIMING{0,1}.
>>>>>>
>>>>>> Can you dump CTRL1?
>>>>>
>>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
>>>>>      HW_GPMI_TIMING0=0x00010101
>>>>>      HW_GPMI_TIMING1=0x90000000
>>>>>      HW_GPMI_CTRL1_SET=0x01c4800c
>>>>
>>>> The read/write delay fields seem to match, but there are a few more
>>>> fields set in this version:
>>>> - DECOUPLE_CS
>>>> - BCH_MODE
>>>> - DEV_RESET
>>>> - CTRL1_ATA_IRQRDY_POLARITY__ACTIVEHIGH
>>>>
>>>> Looks like those fields are not explicitly set in the gpmi_begin()
>>>> patch, but maybe you dumped CTRL1. Would you mind sharing your patch?
>>>
>>> Attached.
>>
>> Hm, you should read CTRL1 instead of CTRL1_SET which I guess is WO.
> 
> 
> Here is 2 sets of trace dumping the same set of registers.
> This first is on the linux-4.16 kernel:
> 
> Linux version 4.16.0 (gerg@goober) (gcc version 4.8.3 (GCC)) #9 Mon Aug 12 10:46:25 AEST 2019
> ...
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron MT29F2G08ABAEAWP
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1110): gpmi_begin()
>    HW_GPMI_TIMING0=0x00010101
>    HW_GPMI_TIMING1=0x90000000
>    HW_GPMI_CTRL1=0x01c6800c
>    r->clock[0]=99000000
> Scanning device for bad blocks
> 5 ofpart partitions found on MTD device gpmi-nand
> Creating 5 MTD partitions on "gpmi-nand":
> 0x000000000000-0x000000500000 : "u-boot"
> 0x000000500000-0x000000600000 : "u-boot-env"
> 0x000000600000-0x000000800000 : "log"
> 0x000000800000-0x000010000000 : "flash"
> 0x000000000000-0x000010000000 : "all"
> gpmi-nand 1806000.gpmi-nand: driver registered.
> ...
> 
> 
> And then this is from the 5.1.14 kernel:
> 
> Linux version 5.1.14 (gerg@goober) (gcc version 4.8.3 (GCC)) #25 Mon Aug 12 10:49:21 AEST 2019
> ...
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron MT29F2G08ABAEAWP
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(510): gpmi_nfc_apply_timings()
>    HW_GPMI_TIMING0=0x00020101
>    HW_GPMI_TIMING1=0xb0000000
>    HW_GPMI_CTRL1=0x0104000c
>    r->clock[0]=22000000
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(510): gpmi_nfc_apply_timings()
>    HW_GPMI_TIMING0=0x00010101
>    HW_GPMI_TIMING1=0xe0000000
>    HW_GPMI_CTRL1=0x01c6800c
>    r->clock[0]=99000000
> Scanning device for bad blocks
> 5 fixed-partitions partitions found on MTD device gpmi-nand
> Creating 5 MTD partitions on "gpmi-nand":
> 0x000000000000-0x000000500000 : "u-boot"
> 0x000000500000-0x000000600000 : "u-boot-env"
> 0x000000600000-0x000000800000 : "log"
> 0x000000800000-0x000010000000 : "flash"
> 0x000000000000-0x000010000000 : "all"
> gpmi-nand 1806000.gpmi-nand: driver registered.
> 
> 
> Register settings read back from the registers themselves at the end
> of the respective setting routines (so gpmi_begin() for 4.16 and
> gpmi_nfc_apply_timings() for 5.1.14)
> 
> So something I notice here is that gpmi_nfc_apply_timings() is
> being run multiple times. When I look back to the original
> failure dumps the first error ("DMA timeout, last DMA") occurred
> after the device type messages ("nand: 256 MiB, SLC,..."). Is it
> happening with that higher clock rate still set?

Looks like that is not the case...

...
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(510): gpmi_nfc_apply_timings()
   HW_GPMI_TIMING0=0x00020101
   HW_GPMI_TIMING1=0xb0000000
   HW_GPMI_CTRL1=0x0104000c
   r->clock[0]=22000000
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(510): gpmi_nfc_apply_timings()
   HW_GPMI_TIMING0=0x00010101
   HW_GPMI_TIMING1=0xe0000000
   HW_GPMI_CTRL1=0x01c6800c
   r->clock[0]=99000000
gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000100
gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
gpmi-nand 1806000.gpmi-nand: Show BCH registers :
gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000

Regards
Greg



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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-08-12  2:50                                       ` Greg Ungerer
  2019-08-12  4:04                                         ` Greg Ungerer
@ 2019-08-12  7:31                                         ` Boris Brezillon
  2019-08-13  0:50                                           ` Greg Ungerer
  1 sibling, 1 reply; 85+ messages in thread
From: Boris Brezillon @ 2019-08-12  7:31 UTC (permalink / raw)
  To: Greg Ungerer
  Cc: Miquel Raynal, s.hauer, Michael Nazzareno Trimarchi, linux-mtd,
	Boris Brezillon

On Mon, 12 Aug 2019 12:50:36 +1000
Greg Ungerer <gerg@kernel.org> wrote:

> Hi Boris,
> 
> On 9/8/19 11:59 pm, Boris Brezillon wrote:
> > On Fri, 9 Aug 2019 23:57:08 +1000
> > Greg Ungerer <gerg@kernel.org> wrote:  
> >> On 9/8/19 5:32 pm, Boris Brezillon wrote:  
> >>> On Fri, 9 Aug 2019 16:55:22 +1000
> >>> Greg Ungerer <gerg@kernel.org> wrote:  
> >>>> On 9/8/19 4:23 pm, Boris Brezillon wrote:  
> >>>>> On Fri, 9 Aug 2019 15:20:52 +1000
> >>>>> Greg Ungerer <gerg@kernel.org> wrote:  
> >>>>>> On 9/8/19 2:36 am, Boris Brezillon wrote:  
> >>>>>>> On Mon, 5 Aug 2019 15:51:05 +1000
> >>>>>>> Greg Ungerer <gerg@kernel.org> wrote:  
> >>>>>>>> On 2/8/19 10:51 pm, Boris Brezillon wrote:  
> >>>>>>>>> On Fri, 2 Aug 2019 22:34:57 +1000
> >>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:  
> >>>>>>>>>> On 31/7/19 4:28 pm, Boris Brezillon wrote:  
> >>>>>>>>>>> On Wed, 31 Jul 2019 12:05:44 +1000
> >>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote:  
> >>>>>>>>>>>> On 30/7/19 6:38 pm, Miquel Raynal wrote:  
> >>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Tue, 30 Jul 2019 16:06:55 +1000:  
> >>>>>>>>>>>>>> On 30/7/19 10:41 am, Greg Ungerer wrote:  
> >>>>>>>>>>>>>>> On 30/7/19 10:28 am, Greg Ungerer wrote:  
> >>>>>>>>>>>>>>>> On 29/7/19 10:47 pm, Miquel Raynal wrote:  
> >>>>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 22:33:56 +1000:  
> >>>>>>>>>>>>>>>>>> On 29/7/19 6:36 pm, Miquel Raynal wrote:  
> >>>>>>>>>>>>>>>>>>> Greg Ungerer <gerg@kernel.org> wrote on Mon, 29 Jul 2019 16:41:51 +1000:  
> >>>>>>>>>>>>>>> [snip]  
> >>>>>>>>>>>> Note that this was generated on a normal boot up (not failure).  
> >>>>>>>>>>>
> >>>>>>>>>>> The values looks good. Can you try with the below diff applied?  
> >>>>>>>>>>> --->8---  
> >>>>>>>>>>> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>>>>>>>> index 334fe3130285..9771f6a82abe 100644
> >>>>>>>>>>> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>>>>>>>> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> >>>>>>>>>>> @@ -721,12 +721,10 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >>>>>>>>>>>               writel(hw->ctrl1n, gpmi_regs + HW_GPMI_CTRL1_SET);
> >>>>>>>>>>>        
> >>>>>>>>>>>               /* Wait 64 clock cycles before using the GPMI after enabling the DLL */
> >>>>>>>>>>> -       dll_wait_time_us = USEC_PER_SEC / hw->clk_rate * 64;
> >>>>>>>>>>> -       if (!dll_wait_time_us)
> >>>>>>>>>>> -               dll_wait_time_us = 1;
> >>>>>>>>>>> +       dll_wait_time_us = DIV_ROUND_UP(USEC_PER_SEC * 64, hw->clk_rate);
> >>>>>>>>>>>        
> >>>>>>>>>>>               /* Wait for the DLL to settle. */
> >>>>>>>>>>> -       udelay(dll_wait_time_us);
> >>>>>>>>>>> +       usleep_range(dll_wait_time_us, dll_wait_time_us * 10);
> >>>>>>>>>>>        }
> >>>>>>>>>>>        
> >>>>>>>>>>>        static int gpmi_setup_data_interface(struct nand_chip *chip, int chipnr,  
> >>>>>>>>>>
> >>>>>>>>>> Eventually it failed, in the same way with with same errors.
> >>>>>>>>>> Took quite a while, over 600 boot cycles.
> >>>>>>>>>>
> >>>>>>>>>> Note also that I had to hand merge the changes, since in 5.1.14 that
> >>>>>>>>>> gpmi_nfc_apply_timings() is in gpmi-lib.c. But it was trivial to do.  
> >>>>>>>>>
> >>>>>>>>> Oh well. I guess the next thing to do would be to dump the timing regs
> >>>>>>>>> and clk rate that are set by the bootloader (before the driver override
> >>>>>>>>> them) or those applied by an older kernel (one that didn't have that
> >>>>>>>>> issue).  
> >>>>>>>>
> >>>>>>>> Is this useful?  
> >>>>>>>
> >>>>>>> Hm, looks like it's configured in mode 0, so no, it's not super useful.
> >>>>>>> Can you try booting an older kernel (one that didn't have the  
> >>>>>>> ->setup_data_interface() hook implemented).  
> >>>>>>
> >>>>>> Ok. I went back from 5.1 and the first kernel I could find that
> >>>>>> returned no grep hits for "setup_data_interface" was 4.16.
> >>>>>>
> >>>>>> So I built for my target with that and added similar trace to dump
> >>>>>> the hardware register settings for that. Debug output looks like
> >>>>>> this now for it:
> >>>>>>
> >>>>>> ...
> >>>>>> drivers/mtd/nand/gpmi-nand/gpmi-nand.c(807): gpmi_get_clks()
> >>>>>>       clk_get_rate(r->clock[0])=22000000
> >>>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
> >>>>>>       HW_GPMI_TIMING0=0x00010203
> >>>>>>       HW_GPMI_TIMING1=0x05000000
> >>>>>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> >>>>>> nand: Micron MT29F2G08ABAEAWP
> >>>>>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> >>>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(966): enable_edo_mode()
> >>>>>>       clk_get_rate(r->clock[0])=99000000
> >>>>>> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
> >>>>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
> >>>>>>       HW_GPMI_TIMING0=0x00010101  
> >>>>>
> >>>>> TIMING0 match the one you have with 5.1 kernels.
> >>>>>       
> >>>>>>       HW_GPMI_TIMING1=0x90000000  
> >>>>>
> >>>>> And we even have a bigger timeout value in 5.1 (0xe0000000), so we
> >>>>> should be all safe WRT to timings in TIMING{0,1}.
> >>>>>
> >>>>> Can you dump CTRL1?  
> >>>>
> >>>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1054): gpmi_begin()
> >>>>      HW_GPMI_TIMING0=0x00010101
> >>>>      HW_GPMI_TIMING1=0x90000000
> >>>>      HW_GPMI_CTRL1_SET=0x01c4800c  
> >>>
> >>> The read/write delay fields seem to match, but there are a few more
> >>> fields set in this version:
> >>> - DECOUPLE_CS
> >>> - BCH_MODE
> >>> - DEV_RESET
> >>> - CTRL1_ATA_IRQRDY_POLARITY__ACTIVEHIGH
> >>>
> >>> Looks like those fields are not explicitly set in the gpmi_begin()
> >>> patch, but maybe you dumped CTRL1. Would you mind sharing your patch?  
> >>
> >> Attached.  
> > 
> > Hm, you should read CTRL1 instead of CTRL1_SET which I guess is WO.  
> 
> 
> Here is 2 sets of trace dumping the same set of registers.
> This first is on the linux-4.16 kernel:
> 
> Linux version 4.16.0 (gerg@goober) (gcc version 4.8.3 (GCC)) #9 Mon Aug 12 10:46:25 AEST 2019
> ...
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron MT29F2G08ABAEAWP
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> gpmi-nand 1806000.gpmi-nand: use legacy bch geometry
> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1110): gpmi_begin()
>    HW_GPMI_TIMING0=0x00010101
>    HW_GPMI_TIMING1=0x90000000
>    HW_GPMI_CTRL1=0x01c6800c
>    r->clock[0]=99000000
> Scanning device for bad blocks
> 5 ofpart partitions found on MTD device gpmi-nand
> Creating 5 MTD partitions on "gpmi-nand":
> 0x000000000000-0x000000500000 : "u-boot"
> 0x000000500000-0x000000600000 : "u-boot-env"
> 0x000000600000-0x000000800000 : "log"
> 0x000000800000-0x000010000000 : "flash"
> 0x000000000000-0x000010000000 : "all"
> gpmi-nand 1806000.gpmi-nand: driver registered.
> ...
> 
> 
> And then this is from the 5.1.14 kernel:
> 
> Linux version 5.1.14 (gerg@goober) (gcc version 4.8.3 (GCC)) #25 Mon Aug 12 10:49:21 AEST 2019
> ...
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron MT29F2G08ABAEAWP
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(510): gpmi_nfc_apply_timings()
>    HW_GPMI_TIMING0=0x00020101
>    HW_GPMI_TIMING1=0xb0000000
>    HW_GPMI_CTRL1=0x0104000c
>    r->clock[0]=22000000
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(510): gpmi_nfc_apply_timings()
>    HW_GPMI_TIMING0=0x00010101
>    HW_GPMI_TIMING1=0xe0000000
>    HW_GPMI_CTRL1=0x01c6800c
>    r->clock[0]=99000000
> Scanning device for bad blocks
> 5 fixed-partitions partitions found on MTD device gpmi-nand
> Creating 5 MTD partitions on "gpmi-nand":
> 0x000000000000-0x000000500000 : "u-boot"
> 0x000000500000-0x000000600000 : "u-boot-env"
> 0x000000600000-0x000000800000 : "log"
> 0x000000800000-0x000010000000 : "flash"
> 0x000000000000-0x000010000000 : "all"
> gpmi-nand 1806000.gpmi-nand: driver registered.
> 
> 
> Register settings read back from the registers themselves at the end
> of the respective setting routines (so gpmi_begin() for 4.16 and
> gpmi_nfc_apply_timings() for 5.1.14)

Hm, CTRL1 is identical. Can you dump all regs at the beginning and at
the end of those funcs?

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-08-12  7:31                                         ` Boris Brezillon
@ 2019-08-13  0:50                                           ` Greg Ungerer
  2021-01-28  9:45                                             ` Michael Nazzareno Trimarchi
  0 siblings, 1 reply; 85+ messages in thread
From: Greg Ungerer @ 2019-08-13  0:50 UTC (permalink / raw)
  To: Boris Brezillon
  Cc: Miquel Raynal, s.hauer, Michael Nazzareno Trimarchi, linux-mtd,
	Boris Brezillon

Hi Boris,

On 12/8/19 5:31 pm, Boris Brezillon wrote:
> On Mon, 12 Aug 2019 12:50:36 +1000
[snip]
> Hm, CTRL1 is identical. Can you dump all regs at the beginning and at
> the end of those funcs?

Here is a more complete dump of registers. Trace points are at
entry and exit of the respective functions in the different
kernel versions. Register dumping code is identical for both.


Linux version 4.16.0 (gerg@goober) (gcc version 4.8.3 (GCC)) #10 Tue Aug 13 10:24:28 AEST 2019
...
drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1073): gpmi_begin(): ENTRY
   HW_GPMI_CTRL0=0x00000000
   HW_GPMI_CTRL1=0x01c4000c
   HW_GPMI_COMPARE=0x00000000
   HW_GPMI_ECCCTRL=0x00000400
   HW_GPMI_ECCCOUNT=0x00000000
   HW_GPMI_PAYLOAD=0x00000000
   HW_GPMI_AUXILIARY=0x00000000
   HW_GPMI_TIMING0=0x00010203
   HW_GPMI_TIMING1=0x00000000
   HW_GPMI_TIMING2=0x23023336
   HW_GPMI_DATA=0x00000000
   HW_GPMI_STAT=0xff000005
   HW_GPMI_DEBUG=0x00000000
   r->clock[0]=22000000
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1073): gpmi_begin(): ENTRY
   HW_GPMI_CTRL0=0x01800001
   HW_GPMI_CTRL1=0x0104000c
   HW_GPMI_COMPARE=0x00000000
   HW_GPMI_ECCCTRL=0x00000000
   HW_GPMI_ECCCOUNT=0x00000000
   HW_GPMI_PAYLOAD=0x00000000
   HW_GPMI_AUXILIARY=0x00000000
   HW_GPMI_TIMING0=0x00010203
   HW_GPMI_TIMING1=0x05000000
   HW_GPMI_TIMING2=0x23023336
   HW_GPMI_DATA=0x00000000
   HW_GPMI_STAT=0xff000005
   HW_GPMI_DEBUG=0x00000101
   r->clock[0]=99000000
drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1136): gpmi_begin(): EXIT
   HW_GPMI_CTRL0=0x01800001
   HW_GPMI_CTRL1=0x01c6800c
   HW_GPMI_COMPARE=0x00000000
   HW_GPMI_ECCCTRL=0x00000000
   HW_GPMI_ECCCOUNT=0x00000000
   HW_GPMI_PAYLOAD=0x00000000
   HW_GPMI_AUXILIARY=0x00000000
   HW_GPMI_TIMING0=0x00010101
   HW_GPMI_TIMING1=0x90000000
   HW_GPMI_TIMING2=0x23023336
   HW_GPMI_DATA=0x00000000
   HW_GPMI_STAT=0xff000005
   HW_GPMI_DEBUG=0x00000101
   r->clock[0]=99000000
Scanning device for bad blocks
5 ofpart partitions found on MTD device gpmi-nand
Creating 5 MTD partitions on "gpmi-nand":
0x000000000000-0x000000500000 : "u-boot"
0x000000500000-0x000000600000 : "u-boot-env"
0x000000600000-0x000000800000 : "log"
0x000000800000-0x000010000000 : "flash"
0x000000000000-0x000010000000 : "all"
gpmi-nand 1806000.gpmi-nand: driver registered.
...

Note that the first ENTRY dump has no matching EXIT dump. From the
code I assume it is returning from gpmi_begin() at the
"if (!hw.sample_delay_factor)" check.


And for the 5.1.14 kernel:

Linux version 5.1.14 (gerg@goober) (gcc version 4.8.3 (GCC)) #27 Tue Aug 13 10:20:32 AEST 2019
...
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(512): gpmi_nfc_apply_timings(): ENTRY
   HW_GPMI_CTRL0=0x00000000
   HW_GPMI_CTRL1=0x01c4000c
   HW_GPMI_COMPARE=0x00000000
   HW_GPMI_ECCCTRL=0x00000400
   HW_GPMI_ECCCOUNT=0x00000000
   HW_GPMI_PAYLOAD=0x00000000
   HW_GPMI_AUXILIARY=0x00000000
   HW_GPMI_TIMING0=0x00010203
   HW_GPMI_TIMING1=0x00000000
   HW_GPMI_TIMING2=0x23023336
   HW_GPMI_DATA=0x00000000
   HW_GPMI_STAT=0xff000005
   HW_GPMI_DEBUG=0x00000000
   r->clock[0]=22000000
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(536): gpmi_nfc_apply_timings(): EXIT
   HW_GPMI_CTRL0=0x00000000
   HW_GPMI_CTRL1=0x0104000c
   HW_GPMI_COMPARE=0x00000000
   HW_GPMI_ECCCTRL=0x00000400
   HW_GPMI_ECCCOUNT=0x00000000
   HW_GPMI_PAYLOAD=0x00000000
   HW_GPMI_AUXILIARY=0x00000000
   HW_GPMI_TIMING0=0x00020101
   HW_GPMI_TIMING1=0x60000000
   HW_GPMI_TIMING2=0x23023336
   HW_GPMI_DATA=0x00000000
   HW_GPMI_STAT=0xff000005
   HW_GPMI_DEBUG=0x00000000
   r->clock[0]=22000000
random: fast init done
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
nand: Micron MT29F2G08ABAEAWP
nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(512): gpmi_nfc_apply_timings(): ENTRY
   HW_GPMI_CTRL0=0x01800001
   HW_GPMI_CTRL1=0x0104000c
   HW_GPMI_COMPARE=0x00000000
   HW_GPMI_ECCCTRL=0x00000000
   HW_GPMI_ECCCOUNT=0x00000000
   HW_GPMI_PAYLOAD=0x00000000
   HW_GPMI_AUXILIARY=0x00000000
   HW_GPMI_TIMING0=0x00020101
   HW_GPMI_TIMING1=0x60000000
   HW_GPMI_TIMING2=0x23023336
   HW_GPMI_DATA=0x0000003f
   HW_GPMI_STAT=0xff000005
   HW_GPMI_DEBUG=0x00000101
   r->clock[0]=22000000
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(536): gpmi_nfc_apply_timings(): EXIT
   HW_GPMI_CTRL0=0x01800001
   HW_GPMI_CTRL1=0x0104000c
   HW_GPMI_COMPARE=0x00000000
   HW_GPMI_ECCCTRL=0x00000000
   HW_GPMI_ECCCOUNT=0x00000000
   HW_GPMI_PAYLOAD=0x00000000
   HW_GPMI_AUXILIARY=0x00000000
   HW_GPMI_TIMING0=0x00020101
   HW_GPMI_TIMING1=0xb0000000
   HW_GPMI_TIMING2=0x23023336
   HW_GPMI_DATA=0x0000003f
   HW_GPMI_STAT=0xff000005
   HW_GPMI_DEBUG=0x00000101
   r->clock[0]=22000000
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(512): gpmi_nfc_apply_timings(): ENTRY
   HW_GPMI_CTRL0=0x01800001
   HW_GPMI_CTRL1=0x0104000c
   HW_GPMI_COMPARE=0x00000000
   HW_GPMI_ECCCTRL=0x00000000
   HW_GPMI_ECCCOUNT=0x00000000
   HW_GPMI_PAYLOAD=0x00000000
   HW_GPMI_AUXILIARY=0x00000000
   HW_GPMI_TIMING0=0x00020101
   HW_GPMI_TIMING1=0xb0000000
   HW_GPMI_TIMING2=0x23023336
   HW_GPMI_DATA=0x000000e0
   HW_GPMI_STAT=0xff000005
   HW_GPMI_DEBUG=0x00000000
   r->clock[0]=22000000
drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(536): gpmi_nfc_apply_timings(): EXIT
   HW_GPMI_CTRL0=0x01800001
   HW_GPMI_CTRL1=0x01c6800c
   HW_GPMI_COMPARE=0x00000000
   HW_GPMI_ECCCTRL=0x00000000
   HW_GPMI_ECCCOUNT=0x00000000
   HW_GPMI_PAYLOAD=0x00000000
   HW_GPMI_AUXILIARY=0x00000000
   HW_GPMI_TIMING0=0x00010101
   HW_GPMI_TIMING1=0xe0000000
   HW_GPMI_TIMING2=0x23023336
   HW_GPMI_DATA=0x000000e0
   HW_GPMI_STAT=0xff000005
   HW_GPMI_DEBUG=0x00000000
   r->clock[0]=99000000
Scanning device for bad blocks
5 fixed-partitions partitions found on MTD device gpmi-nand
Creating 5 MTD partitions on "gpmi-nand":
0x000000000000-0x000000500000 : "u-boot"
0x000000500000-0x000000600000 : "u-boot-env"
0x000000600000-0x000000800000 : "log"
0x000000800000-0x000010000000 : "flash"
0x000000000000-0x000010000000 : "all"
gpmi-nand 1806000.gpmi-nand: driver registered.
...


Regards
Greg



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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-08-13  0:50                                           ` Greg Ungerer
@ 2021-01-28  9:45                                             ` Michael Nazzareno Trimarchi
  2021-01-28 10:26                                               ` Miquel Raynal
  2021-01-29 12:43                                               ` Greg Ungerer
  0 siblings, 2 replies; 85+ messages in thread
From: Michael Nazzareno Trimarchi @ 2021-01-28  9:45 UTC (permalink / raw)
  To: Greg Ungerer
  Cc: Miquel Raynal, Sascha Hauer, Boris Brezillon, linux-mtd, Boris Brezillon

Hi Greg

On Tue, Aug 13, 2019 at 2:50 AM Greg Ungerer <gerg@kernel.org> wrote:
>
> Hi Boris,
>
> On 12/8/19 5:31 pm, Boris Brezillon wrote:
> > On Mon, 12 Aug 2019 12:50:36 +1000
> [snip]
> > Hm, CTRL1 is identical. Can you dump all regs at the beginning and at
> > the end of those funcs?
>
> Here is a more complete dump of registers. Trace points are at
> entry and exit of the respective functions in the different
> kernel versions. Register dumping code is identical for both.
>
>
> Linux version 4.16.0 (gerg@goober) (gcc version 4.8.3 (GCC)) #10 Tue Aug 13 10:24:28 AEST 2019
> ...

I ran an overnight reboot process on linux-4.19.y tag: v4.19.169 and
I'm not able to reproduce up to now.

Do you have an update from your side?

Michael

> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1073): gpmi_begin(): ENTRY
>    HW_GPMI_CTRL0=0x00000000
>    HW_GPMI_CTRL1=0x01c4000c
>    HW_GPMI_COMPARE=0x00000000
>    HW_GPMI_ECCCTRL=0x00000400
>    HW_GPMI_ECCCOUNT=0x00000000
>    HW_GPMI_PAYLOAD=0x00000000
>    HW_GPMI_AUXILIARY=0x00000000
>    HW_GPMI_TIMING0=0x00010203
>    HW_GPMI_TIMING1=0x00000000
>    HW_GPMI_TIMING2=0x23023336
>    HW_GPMI_DATA=0x00000000
>    HW_GPMI_STAT=0xff000005
>    HW_GPMI_DEBUG=0x00000000
>    r->clock[0]=22000000
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron MT29F2G08ABAEAWP
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1073): gpmi_begin(): ENTRY
>    HW_GPMI_CTRL0=0x01800001
>    HW_GPMI_CTRL1=0x0104000c
>    HW_GPMI_COMPARE=0x00000000
>    HW_GPMI_ECCCTRL=0x00000000
>    HW_GPMI_ECCCOUNT=0x00000000
>    HW_GPMI_PAYLOAD=0x00000000
>    HW_GPMI_AUXILIARY=0x00000000
>    HW_GPMI_TIMING0=0x00010203
>    HW_GPMI_TIMING1=0x05000000
>    HW_GPMI_TIMING2=0x23023336
>    HW_GPMI_DATA=0x00000000
>    HW_GPMI_STAT=0xff000005
>    HW_GPMI_DEBUG=0x00000101
>    r->clock[0]=99000000
> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1136): gpmi_begin(): EXIT
>    HW_GPMI_CTRL0=0x01800001
>    HW_GPMI_CTRL1=0x01c6800c
>    HW_GPMI_COMPARE=0x00000000
>    HW_GPMI_ECCCTRL=0x00000000
>    HW_GPMI_ECCCOUNT=0x00000000
>    HW_GPMI_PAYLOAD=0x00000000
>    HW_GPMI_AUXILIARY=0x00000000
>    HW_GPMI_TIMING0=0x00010101
>    HW_GPMI_TIMING1=0x90000000
>    HW_GPMI_TIMING2=0x23023336
>    HW_GPMI_DATA=0x00000000
>    HW_GPMI_STAT=0xff000005
>    HW_GPMI_DEBUG=0x00000101
>    r->clock[0]=99000000
> Scanning device for bad blocks
> 5 ofpart partitions found on MTD device gpmi-nand
> Creating 5 MTD partitions on "gpmi-nand":
> 0x000000000000-0x000000500000 : "u-boot"
> 0x000000500000-0x000000600000 : "u-boot-env"
> 0x000000600000-0x000000800000 : "log"
> 0x000000800000-0x000010000000 : "flash"
> 0x000000000000-0x000010000000 : "all"
> gpmi-nand 1806000.gpmi-nand: driver registered.
> ...
>
> Note that the first ENTRY dump has no matching EXIT dump. From the
> code I assume it is returning from gpmi_begin() at the
> "if (!hw.sample_delay_factor)" check.
>
>
> And for the 5.1.14 kernel:
>
> Linux version 5.1.14 (gerg@goober) (gcc version 4.8.3 (GCC)) #27 Tue Aug 13 10:20:32 AEST 2019
> ...
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(512): gpmi_nfc_apply_timings(): ENTRY
>    HW_GPMI_CTRL0=0x00000000
>    HW_GPMI_CTRL1=0x01c4000c
>    HW_GPMI_COMPARE=0x00000000
>    HW_GPMI_ECCCTRL=0x00000400
>    HW_GPMI_ECCCOUNT=0x00000000
>    HW_GPMI_PAYLOAD=0x00000000
>    HW_GPMI_AUXILIARY=0x00000000
>    HW_GPMI_TIMING0=0x00010203
>    HW_GPMI_TIMING1=0x00000000
>    HW_GPMI_TIMING2=0x23023336
>    HW_GPMI_DATA=0x00000000
>    HW_GPMI_STAT=0xff000005
>    HW_GPMI_DEBUG=0x00000000
>    r->clock[0]=22000000
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(536): gpmi_nfc_apply_timings(): EXIT
>    HW_GPMI_CTRL0=0x00000000
>    HW_GPMI_CTRL1=0x0104000c
>    HW_GPMI_COMPARE=0x00000000
>    HW_GPMI_ECCCTRL=0x00000400
>    HW_GPMI_ECCCOUNT=0x00000000
>    HW_GPMI_PAYLOAD=0x00000000
>    HW_GPMI_AUXILIARY=0x00000000
>    HW_GPMI_TIMING0=0x00020101
>    HW_GPMI_TIMING1=0x60000000
>    HW_GPMI_TIMING2=0x23023336
>    HW_GPMI_DATA=0x00000000
>    HW_GPMI_STAT=0xff000005
>    HW_GPMI_DEBUG=0x00000000
>    r->clock[0]=22000000
> random: fast init done
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> nand: Micron MT29F2G08ABAEAWP
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(512): gpmi_nfc_apply_timings(): ENTRY
>    HW_GPMI_CTRL0=0x01800001
>    HW_GPMI_CTRL1=0x0104000c
>    HW_GPMI_COMPARE=0x00000000
>    HW_GPMI_ECCCTRL=0x00000000
>    HW_GPMI_ECCCOUNT=0x00000000
>    HW_GPMI_PAYLOAD=0x00000000
>    HW_GPMI_AUXILIARY=0x00000000
>    HW_GPMI_TIMING0=0x00020101
>    HW_GPMI_TIMING1=0x60000000
>    HW_GPMI_TIMING2=0x23023336
>    HW_GPMI_DATA=0x0000003f
>    HW_GPMI_STAT=0xff000005
>    HW_GPMI_DEBUG=0x00000101
>    r->clock[0]=22000000
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(536): gpmi_nfc_apply_timings(): EXIT
>    HW_GPMI_CTRL0=0x01800001
>    HW_GPMI_CTRL1=0x0104000c
>    HW_GPMI_COMPARE=0x00000000
>    HW_GPMI_ECCCTRL=0x00000000
>    HW_GPMI_ECCCOUNT=0x00000000
>    HW_GPMI_PAYLOAD=0x00000000
>    HW_GPMI_AUXILIARY=0x00000000
>    HW_GPMI_TIMING0=0x00020101
>    HW_GPMI_TIMING1=0xb0000000
>    HW_GPMI_TIMING2=0x23023336
>    HW_GPMI_DATA=0x0000003f
>    HW_GPMI_STAT=0xff000005
>    HW_GPMI_DEBUG=0x00000101
>    r->clock[0]=22000000
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(512): gpmi_nfc_apply_timings(): ENTRY
>    HW_GPMI_CTRL0=0x01800001
>    HW_GPMI_CTRL1=0x0104000c
>    HW_GPMI_COMPARE=0x00000000
>    HW_GPMI_ECCCTRL=0x00000000
>    HW_GPMI_ECCCOUNT=0x00000000
>    HW_GPMI_PAYLOAD=0x00000000
>    HW_GPMI_AUXILIARY=0x00000000
>    HW_GPMI_TIMING0=0x00020101
>    HW_GPMI_TIMING1=0xb0000000
>    HW_GPMI_TIMING2=0x23023336
>    HW_GPMI_DATA=0x000000e0
>    HW_GPMI_STAT=0xff000005
>    HW_GPMI_DEBUG=0x00000000
>    r->clock[0]=22000000
> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(536): gpmi_nfc_apply_timings(): EXIT
>    HW_GPMI_CTRL0=0x01800001
>    HW_GPMI_CTRL1=0x01c6800c
>    HW_GPMI_COMPARE=0x00000000
>    HW_GPMI_ECCCTRL=0x00000000
>    HW_GPMI_ECCCOUNT=0x00000000
>    HW_GPMI_PAYLOAD=0x00000000
>    HW_GPMI_AUXILIARY=0x00000000
>    HW_GPMI_TIMING0=0x00010101
>    HW_GPMI_TIMING1=0xe0000000
>    HW_GPMI_TIMING2=0x23023336
>    HW_GPMI_DATA=0x000000e0
>    HW_GPMI_STAT=0xff000005
>    HW_GPMI_DEBUG=0x00000000
>    r->clock[0]=99000000
> Scanning device for bad blocks
> 5 fixed-partitions partitions found on MTD device gpmi-nand
> Creating 5 MTD partitions on "gpmi-nand":
> 0x000000000000-0x000000500000 : "u-boot"
> 0x000000500000-0x000000600000 : "u-boot-env"
> 0x000000600000-0x000000800000 : "log"
> 0x000000800000-0x000010000000 : "flash"
> 0x000000000000-0x000010000000 : "all"
> gpmi-nand 1806000.gpmi-nand: driver registered.
> ...
>
>
> Regards
> Greg
>
>


-- 
Michael Nazzareno Trimarchi
Amarula Solutions BV
COO Co-Founder
Cruquiuskade 47 Amsterdam 1018 AM NL
T. +31(0)851119172
M. +39(0)3479132170
[`as] https://www.amarulasolutions.com

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-01-28  9:45                                             ` Michael Nazzareno Trimarchi
@ 2021-01-28 10:26                                               ` Miquel Raynal
  2021-01-28 10:35                                                 ` Michael Nazzareno Trimarchi
  2021-01-29 12:43                                               ` Greg Ungerer
  1 sibling, 1 reply; 85+ messages in thread
From: Miquel Raynal @ 2021-01-28 10:26 UTC (permalink / raw)
  To: Michael Nazzareno Trimarchi
  Cc: linux-mtd, Sascha Hauer, Greg Ungerer, Boris Brezillon, Boris Brezillon

Hi Michael,

Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
Thu, 28 Jan 2021 10:45:29 +0100:

> Hi Greg
> 
> On Tue, Aug 13, 2019 at 2:50 AM Greg Ungerer <gerg@kernel.org> wrote:
> >
> > Hi Boris,
> >
> > On 12/8/19 5:31 pm, Boris Brezillon wrote:  
> > > On Mon, 12 Aug 2019 12:50:36 +1000  
> > [snip]  
> > > Hm, CTRL1 is identical. Can you dump all regs at the beginning and at
> > > the end of those funcs?  
> >
> > Here is a more complete dump of registers. Trace points are at
> > entry and exit of the respective functions in the different
> > kernel versions. Register dumping code is identical for both.
> >
> >
> > Linux version 4.16.0 (gerg@goober) (gcc version 4.8.3 (GCC)) #10 Tue Aug 13 10:24:28 AEST 2019
> > ...  
> 
> I ran an overnight reboot process on linux-4.19.y tag: v4.19.169 and
> I'm not able to reproduce up to now.
> 
> Do you have an update from your side?

Perhaps this patch [1] was backported to v4.19.169 (I didn't check) but
it might have fixed the DMA issue you were seeing, at least in the
recent kernel versions.

[1] mtd: rawnand: gpmi: Fix the random DMA timeout issue

Thanks,
Miquèl

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-01-28 10:26                                               ` Miquel Raynal
@ 2021-01-28 10:35                                                 ` Michael Nazzareno Trimarchi
  2021-01-28 11:55                                                   ` Michael Nazzareno Trimarchi
  0 siblings, 1 reply; 85+ messages in thread
From: Michael Nazzareno Trimarchi @ 2021-01-28 10:35 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: linux-mtd, Sascha Hauer, Greg Ungerer, Boris Brezillon, Boris Brezillon

Hi

On Thu, Jan 28, 2021 at 11:26 AM Miquel Raynal
<miquel.raynal@bootlin.com> wrote:
>
> Hi Michael,
>
> Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> Thu, 28 Jan 2021 10:45:29 +0100:
>
> > Hi Greg
> >
> > On Tue, Aug 13, 2019 at 2:50 AM Greg Ungerer <gerg@kernel.org> wrote:
> > >
> > > Hi Boris,
> > >
> > > On 12/8/19 5:31 pm, Boris Brezillon wrote:
> > > > On Mon, 12 Aug 2019 12:50:36 +1000
> > > [snip]
> > > > Hm, CTRL1 is identical. Can you dump all regs at the beginning and at
> > > > the end of those funcs?
> > >
> > > Here is a more complete dump of registers. Trace points are at
> > > entry and exit of the respective functions in the different
> > > kernel versions. Register dumping code is identical for both.
> > >
> > >
> > > Linux version 4.16.0 (gerg@goober) (gcc version 4.8.3 (GCC)) #10 Tue Aug 13 10:24:28 AEST 2019
> > > ...
> >
> > I ran an overnight reboot process on linux-4.19.y tag: v4.19.169 and
> > I'm not able to reproduce up to now.
> >
> > Do you have an update from your side?
>
> Perhaps this patch [1] was backported to v4.19.169 (I didn't check) but
> it might have fixed the DMA issue you were seeing, at least in the
> recent kernel versions.

It's not there and should not go because this patch fixes another
regression.  Apply
it means apply anyway both.
I will decode the registers on those thread and check the difference

Michael

>
> [1] mtd: rawnand: gpmi: Fix the random DMA timeout issue
>
> Thanks,
> Miquèl



-- 
Michael Nazzareno Trimarchi
Amarula Solutions BV
COO Co-Founder
Cruquiuskade 47 Amsterdam 1018 AM NL
T. +31(0)851119172
M. +39(0)3479132170
[`as] https://www.amarulasolutions.com

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-01-28 10:35                                                 ` Michael Nazzareno Trimarchi
@ 2021-01-28 11:55                                                   ` Michael Nazzareno Trimarchi
  0 siblings, 0 replies; 85+ messages in thread
From: Michael Nazzareno Trimarchi @ 2021-01-28 11:55 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: linux-mtd, Sascha Hauer, Greg Ungerer, Boris Brezillon, Boris Brezillon

Hi

I have a couple of questions

On Thu, Jan 28, 2021 at 11:35 AM Michael Nazzareno Trimarchi
<michael@amarulasolutions.com> wrote:
>
> Hi
>
> On Thu, Jan 28, 2021 at 11:26 AM Miquel Raynal
> <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Michael,
> >
> > Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> > Thu, 28 Jan 2021 10:45:29 +0100:
> >
> > > Hi Greg
> > >
> > > On Tue, Aug 13, 2019 at 2:50 AM Greg Ungerer <gerg@kernel.org> wrote:
> > > >
> > > > Hi Boris,
> > > >
> > > > On 12/8/19 5:31 pm, Boris Brezillon wrote:
> > > > > On Mon, 12 Aug 2019 12:50:36 +1000
> > > > [snip]
> > > > > Hm, CTRL1 is identical. Can you dump all regs at the beginning and at
> > > > > the end of those funcs?
> > > >
> > > > Here is a more complete dump of registers. Trace points are at
> > > > entry and exit of the respective functions in the different
> > > > kernel versions. Register dumping code is identical for both.
> > > >
> > > >
> > > > Linux version 4.16.0 (gerg@goober) (gcc version 4.8.3 (GCC)) #10 Tue Aug 13 10:24:28 AEST 2019
> > > > ...
> > >
> > > I ran an overnight reboot process on linux-4.19.y tag: v4.19.169 and
> > > I'm not able to reproduce up to now.
> > >
> > > Do you have an update from your side?
> >
> > Perhaps this patch [1] was backported to v4.19.169 (I didn't check) but
> > it might have fixed the DMA issue you were seeing, at least in the
> > recent kernel versions.
>
> It's not there and should not go because this patch fixes another
> regression.  Apply
> it means apply anyway both.
> I will decode the registers on those thread and check the difference
>

maxchips is 2 for IMX6 and I think that is connected to NAND_CE0_B and
NAND_CE1_B, When
we probe I think both are probed. Is that right?

Michael


> Michae
>
> >
> > [1] mtd: rawnand: gpmi: Fix the random DMA timeout issue
> >
> > Thanks,
> > Miquèl
>
>
>
> --
> Michael Nazzareno Trimarchi
> Amarula Solutions BV
> COO Co-Founder
> Cruquiuskade 47 Amsterdam 1018 AM NL
> T. +31(0)851119172
> M. +39(0)3479132170
> [`as] https://www.amarulasolutions.com



-- 
Michael Nazzareno Trimarchi
Amarula Solutions BV
COO Co-Founder
Cruquiuskade 47 Amsterdam 1018 AM NL
T. +31(0)851119172
M. +39(0)3479132170
[`as] https://www.amarulasolutions.com

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-01-28  9:45                                             ` Michael Nazzareno Trimarchi
  2021-01-28 10:26                                               ` Miquel Raynal
@ 2021-01-29 12:43                                               ` Greg Ungerer
  2021-01-30  9:41                                                 ` Michael Nazzareno Trimarchi
  1 sibling, 1 reply; 85+ messages in thread
From: Greg Ungerer @ 2021-01-29 12:43 UTC (permalink / raw)
  To: Michael Nazzareno Trimarchi
  Cc: Miquel Raynal, Sascha Hauer, Boris Brezillon, linux-mtd, Boris Brezillon

Hi Michael,

On 28/1/21 7:45 pm, Michael Nazzareno Trimarchi wrote:
> Hi Greg
> 
> On Tue, Aug 13, 2019 at 2:50 AM Greg Ungerer <gerg@kernel.org> wrote:
>>
>> Hi Boris,
>>
>> On 12/8/19 5:31 pm, Boris Brezillon wrote:
>>> On Mon, 12 Aug 2019 12:50:36 +1000
>> [snip]
>>> Hm, CTRL1 is identical. Can you dump all regs at the beginning and at
>>> the end of those funcs?
>>
>> Here is a more complete dump of registers. Trace points are at
>> entry and exit of the respective functions in the different
>> kernel versions. Register dumping code is identical for both.
>>
>>
>> Linux version 4.16.0 (gerg@goober) (gcc version 4.8.3 (GCC)) #10 Tue Aug 13 10:24:28 AEST 2019
>> ...
> 
> I ran an overnight reboot process on linux-4.19.y tag: v4.19.169 and
> I'm not able to reproduce up to now.
> 
> Do you have an update from your side?

I haven't seen the problem for a while now.
I pretty much only run modern kernels, I am currently using 5.10.
So I am guessing it was resolved somewhere at some point, but I
don't know exactly what change resolved it.

Regards
Greg



>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1073): gpmi_begin(): ENTRY
>>     HW_GPMI_CTRL0=0x00000000
>>     HW_GPMI_CTRL1=0x01c4000c
>>     HW_GPMI_COMPARE=0x00000000
>>     HW_GPMI_ECCCTRL=0x00000400
>>     HW_GPMI_ECCCOUNT=0x00000000
>>     HW_GPMI_PAYLOAD=0x00000000
>>     HW_GPMI_AUXILIARY=0x00000000
>>     HW_GPMI_TIMING0=0x00010203
>>     HW_GPMI_TIMING1=0x00000000
>>     HW_GPMI_TIMING2=0x23023336
>>     HW_GPMI_DATA=0x00000000
>>     HW_GPMI_STAT=0xff000005
>>     HW_GPMI_DEBUG=0x00000000
>>     r->clock[0]=22000000
>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>> nand: Micron MT29F2G08ABAEAWP
>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1073): gpmi_begin(): ENTRY
>>     HW_GPMI_CTRL0=0x01800001
>>     HW_GPMI_CTRL1=0x0104000c
>>     HW_GPMI_COMPARE=0x00000000
>>     HW_GPMI_ECCCTRL=0x00000000
>>     HW_GPMI_ECCCOUNT=0x00000000
>>     HW_GPMI_PAYLOAD=0x00000000
>>     HW_GPMI_AUXILIARY=0x00000000
>>     HW_GPMI_TIMING0=0x00010203
>>     HW_GPMI_TIMING1=0x05000000
>>     HW_GPMI_TIMING2=0x23023336
>>     HW_GPMI_DATA=0x00000000
>>     HW_GPMI_STAT=0xff000005
>>     HW_GPMI_DEBUG=0x00000101
>>     r->clock[0]=99000000
>> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1136): gpmi_begin(): EXIT
>>     HW_GPMI_CTRL0=0x01800001
>>     HW_GPMI_CTRL1=0x01c6800c
>>     HW_GPMI_COMPARE=0x00000000
>>     HW_GPMI_ECCCTRL=0x00000000
>>     HW_GPMI_ECCCOUNT=0x00000000
>>     HW_GPMI_PAYLOAD=0x00000000
>>     HW_GPMI_AUXILIARY=0x00000000
>>     HW_GPMI_TIMING0=0x00010101
>>     HW_GPMI_TIMING1=0x90000000
>>     HW_GPMI_TIMING2=0x23023336
>>     HW_GPMI_DATA=0x00000000
>>     HW_GPMI_STAT=0xff000005
>>     HW_GPMI_DEBUG=0x00000101
>>     r->clock[0]=99000000
>> Scanning device for bad blocks
>> 5 ofpart partitions found on MTD device gpmi-nand
>> Creating 5 MTD partitions on "gpmi-nand":
>> 0x000000000000-0x000000500000 : "u-boot"
>> 0x000000500000-0x000000600000 : "u-boot-env"
>> 0x000000600000-0x000000800000 : "log"
>> 0x000000800000-0x000010000000 : "flash"
>> 0x000000000000-0x000010000000 : "all"
>> gpmi-nand 1806000.gpmi-nand: driver registered.
>> ...
>>
>> Note that the first ENTRY dump has no matching EXIT dump. From the
>> code I assume it is returning from gpmi_begin() at the
>> "if (!hw.sample_delay_factor)" check.
>>
>>
>> And for the 5.1.14 kernel:
>>
>> Linux version 5.1.14 (gerg@goober) (gcc version 4.8.3 (GCC)) #27 Tue Aug 13 10:20:32 AEST 2019
>> ...
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(512): gpmi_nfc_apply_timings(): ENTRY
>>     HW_GPMI_CTRL0=0x00000000
>>     HW_GPMI_CTRL1=0x01c4000c
>>     HW_GPMI_COMPARE=0x00000000
>>     HW_GPMI_ECCCTRL=0x00000400
>>     HW_GPMI_ECCCOUNT=0x00000000
>>     HW_GPMI_PAYLOAD=0x00000000
>>     HW_GPMI_AUXILIARY=0x00000000
>>     HW_GPMI_TIMING0=0x00010203
>>     HW_GPMI_TIMING1=0x00000000
>>     HW_GPMI_TIMING2=0x23023336
>>     HW_GPMI_DATA=0x00000000
>>     HW_GPMI_STAT=0xff000005
>>     HW_GPMI_DEBUG=0x00000000
>>     r->clock[0]=22000000
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(536): gpmi_nfc_apply_timings(): EXIT
>>     HW_GPMI_CTRL0=0x00000000
>>     HW_GPMI_CTRL1=0x0104000c
>>     HW_GPMI_COMPARE=0x00000000
>>     HW_GPMI_ECCCTRL=0x00000400
>>     HW_GPMI_ECCCOUNT=0x00000000
>>     HW_GPMI_PAYLOAD=0x00000000
>>     HW_GPMI_AUXILIARY=0x00000000
>>     HW_GPMI_TIMING0=0x00020101
>>     HW_GPMI_TIMING1=0x60000000
>>     HW_GPMI_TIMING2=0x23023336
>>     HW_GPMI_DATA=0x00000000
>>     HW_GPMI_STAT=0xff000005
>>     HW_GPMI_DEBUG=0x00000000
>>     r->clock[0]=22000000
>> random: fast init done
>> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>> nand: Micron MT29F2G08ABAEAWP
>> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(512): gpmi_nfc_apply_timings(): ENTRY
>>     HW_GPMI_CTRL0=0x01800001
>>     HW_GPMI_CTRL1=0x0104000c
>>     HW_GPMI_COMPARE=0x00000000
>>     HW_GPMI_ECCCTRL=0x00000000
>>     HW_GPMI_ECCCOUNT=0x00000000
>>     HW_GPMI_PAYLOAD=0x00000000
>>     HW_GPMI_AUXILIARY=0x00000000
>>     HW_GPMI_TIMING0=0x00020101
>>     HW_GPMI_TIMING1=0x60000000
>>     HW_GPMI_TIMING2=0x23023336
>>     HW_GPMI_DATA=0x0000003f
>>     HW_GPMI_STAT=0xff000005
>>     HW_GPMI_DEBUG=0x00000101
>>     r->clock[0]=22000000
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(536): gpmi_nfc_apply_timings(): EXIT
>>     HW_GPMI_CTRL0=0x01800001
>>     HW_GPMI_CTRL1=0x0104000c
>>     HW_GPMI_COMPARE=0x00000000
>>     HW_GPMI_ECCCTRL=0x00000000
>>     HW_GPMI_ECCCOUNT=0x00000000
>>     HW_GPMI_PAYLOAD=0x00000000
>>     HW_GPMI_AUXILIARY=0x00000000
>>     HW_GPMI_TIMING0=0x00020101
>>     HW_GPMI_TIMING1=0xb0000000
>>     HW_GPMI_TIMING2=0x23023336
>>     HW_GPMI_DATA=0x0000003f
>>     HW_GPMI_STAT=0xff000005
>>     HW_GPMI_DEBUG=0x00000101
>>     r->clock[0]=22000000
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(512): gpmi_nfc_apply_timings(): ENTRY
>>     HW_GPMI_CTRL0=0x01800001
>>     HW_GPMI_CTRL1=0x0104000c
>>     HW_GPMI_COMPARE=0x00000000
>>     HW_GPMI_ECCCTRL=0x00000000
>>     HW_GPMI_ECCCOUNT=0x00000000
>>     HW_GPMI_PAYLOAD=0x00000000
>>     HW_GPMI_AUXILIARY=0x00000000
>>     HW_GPMI_TIMING0=0x00020101
>>     HW_GPMI_TIMING1=0xb0000000
>>     HW_GPMI_TIMING2=0x23023336
>>     HW_GPMI_DATA=0x000000e0
>>     HW_GPMI_STAT=0xff000005
>>     HW_GPMI_DEBUG=0x00000000
>>     r->clock[0]=22000000
>> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(536): gpmi_nfc_apply_timings(): EXIT
>>     HW_GPMI_CTRL0=0x01800001
>>     HW_GPMI_CTRL1=0x01c6800c
>>     HW_GPMI_COMPARE=0x00000000
>>     HW_GPMI_ECCCTRL=0x00000000
>>     HW_GPMI_ECCCOUNT=0x00000000
>>     HW_GPMI_PAYLOAD=0x00000000
>>     HW_GPMI_AUXILIARY=0x00000000
>>     HW_GPMI_TIMING0=0x00010101
>>     HW_GPMI_TIMING1=0xe0000000
>>     HW_GPMI_TIMING2=0x23023336
>>     HW_GPMI_DATA=0x000000e0
>>     HW_GPMI_STAT=0xff000005
>>     HW_GPMI_DEBUG=0x00000000
>>     r->clock[0]=99000000
>> Scanning device for bad blocks
>> 5 fixed-partitions partitions found on MTD device gpmi-nand
>> Creating 5 MTD partitions on "gpmi-nand":
>> 0x000000000000-0x000000500000 : "u-boot"
>> 0x000000500000-0x000000600000 : "u-boot-env"
>> 0x000000600000-0x000000800000 : "log"
>> 0x000000800000-0x000010000000 : "flash"
>> 0x000000000000-0x000010000000 : "all"
>> gpmi-nand 1806000.gpmi-nand: driver registered.
>> ...
>>
>>
>> Regards
>> Greg
>>
>>
> 
> 

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-01-29 12:43                                               ` Greg Ungerer
@ 2021-01-30  9:41                                                 ` Michael Nazzareno Trimarchi
  2021-02-01 14:13                                                   ` Miquel Raynal
  0 siblings, 1 reply; 85+ messages in thread
From: Michael Nazzareno Trimarchi @ 2021-01-30  9:41 UTC (permalink / raw)
  To: Greg Ungerer
  Cc: Miquel Raynal, Sascha Hauer, Boris Brezillon, linux-mtd, Boris Brezillon

Hi Miquel

commit f8e6ad14388067f91b26d044185d95623fbc9535
Author: Michael Trimarchi <michael@amarulasolutions.com>
Date:   Fri Jan 29 08:46:53 2021 +0100

    mtd: nand: Calculate the clock before enable it

    Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
    Change-Id: I79b0da39de0a9b32ea0b002fa200d7f44d4f8ce7

diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
index 322a008290e5..0bca52b3bc8f 100644
--- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
+++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
@@ -377,6 +377,7 @@ static void gpmi_nfc_compute_timings(struct
gpmi_nand_data *this,
                                     const struct nand_sdr_timings *sdr)
 {
        struct gpmi_nfc_hardware_timing *hw = &this->hw;
+       struct resources *r = &this->resources;
        unsigned int dll_threshold_ps = this->devdata->max_chain_delay;
        unsigned int period_ps, reference_period_ps;
        unsigned int data_setup_cycles, data_hold_cycles, addr_setup_cycles;
@@ -440,6 +441,8 @@ static void gpmi_nfc_compute_timings(struct
gpmi_nand_data *this,
                hw->ctrl1n |= BF_GPMI_CTRL1_RDN_DELAY(sample_delay_factor) |
                              BM_GPMI_CTRL1_DLL_ENABLE |
                              (use_half_period ? BM_GPMI_CTRL1_HALF_PERIOD : 0);
+
+       clk_set_rate(r->clock[0], hw->clk_rate);
 }

 void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
@@ -449,8 +452,6 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
        void __iomem *gpmi_regs = r->gpmi_regs;
        unsigned int dll_wait_time_us;

-       clk_set_rate(r->clock[0], hw->clk_rate);
-
        writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
        writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);

Right now I have this change applied and seems fine. That is the only
difference I get. Clock is apply a bit earlier that when is enabled
it.

Michael

On Fri, Jan 29, 2021 at 1:43 PM Greg Ungerer <gerg@kernel.org> wrote:
>
> Hi Michael,
>
> On 28/1/21 7:45 pm, Michael Nazzareno Trimarchi wrote:
> > Hi Greg
> >
> > On Tue, Aug 13, 2019 at 2:50 AM Greg Ungerer <gerg@kernel.org> wrote:
> >>
> >> Hi Boris,
> >>
> >> On 12/8/19 5:31 pm, Boris Brezillon wrote:
> >>> On Mon, 12 Aug 2019 12:50:36 +1000
> >> [snip]
> >>> Hm, CTRL1 is identical. Can you dump all regs at the beginning and at
> >>> the end of those funcs?
> >>
> >> Here is a more complete dump of registers. Trace points are at
> >> entry and exit of the respective functions in the different
> >> kernel versions. Register dumping code is identical for both.
> >>
> >>
> >> Linux version 4.16.0 (gerg@goober) (gcc version 4.8.3 (GCC)) #10 Tue Aug 13 10:24:28 AEST 2019
> >> ...
> >
> > I ran an overnight reboot process on linux-4.19.y tag: v4.19.169 and
> > I'm not able to reproduce up to now.
> >
> > Do you have an update from your side?
>
> I haven't seen the problem for a while now.
> I pretty much only run modern kernels, I am currently using 5.10.
> So I am guessing it was resolved somewhere at some point, but I
> don't know exactly what change resolved it.
>
> Regards
> Greg
>
>
>
> >> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1073): gpmi_begin(): ENTRY
> >>     HW_GPMI_CTRL0=0x00000000
> >>     HW_GPMI_CTRL1=0x01c4000c
> >>     HW_GPMI_COMPARE=0x00000000
> >>     HW_GPMI_ECCCTRL=0x00000400
> >>     HW_GPMI_ECCCOUNT=0x00000000
> >>     HW_GPMI_PAYLOAD=0x00000000
> >>     HW_GPMI_AUXILIARY=0x00000000
> >>     HW_GPMI_TIMING0=0x00010203
> >>     HW_GPMI_TIMING1=0x00000000
> >>     HW_GPMI_TIMING2=0x23023336
> >>     HW_GPMI_DATA=0x00000000
> >>     HW_GPMI_STAT=0xff000005
> >>     HW_GPMI_DEBUG=0x00000000
> >>     r->clock[0]=22000000
> >> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> >> nand: Micron MT29F2G08ABAEAWP
> >> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> >> gpmi-nand 1806000.gpmi-nand: enable the asynchronous EDO mode 5
> >> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1073): gpmi_begin(): ENTRY
> >>     HW_GPMI_CTRL0=0x01800001
> >>     HW_GPMI_CTRL1=0x0104000c
> >>     HW_GPMI_COMPARE=0x00000000
> >>     HW_GPMI_ECCCTRL=0x00000000
> >>     HW_GPMI_ECCCOUNT=0x00000000
> >>     HW_GPMI_PAYLOAD=0x00000000
> >>     HW_GPMI_AUXILIARY=0x00000000
> >>     HW_GPMI_TIMING0=0x00010203
> >>     HW_GPMI_TIMING1=0x05000000
> >>     HW_GPMI_TIMING2=0x23023336
> >>     HW_GPMI_DATA=0x00000000
> >>     HW_GPMI_STAT=0xff000005
> >>     HW_GPMI_DEBUG=0x00000101
> >>     r->clock[0]=99000000
> >> drivers/mtd/nand/gpmi-nand/gpmi-lib.c(1136): gpmi_begin(): EXIT
> >>     HW_GPMI_CTRL0=0x01800001
> >>     HW_GPMI_CTRL1=0x01c6800c
> >>     HW_GPMI_COMPARE=0x00000000
> >>     HW_GPMI_ECCCTRL=0x00000000
> >>     HW_GPMI_ECCCOUNT=0x00000000
> >>     HW_GPMI_PAYLOAD=0x00000000
> >>     HW_GPMI_AUXILIARY=0x00000000
> >>     HW_GPMI_TIMING0=0x00010101
> >>     HW_GPMI_TIMING1=0x90000000
> >>     HW_GPMI_TIMING2=0x23023336
> >>     HW_GPMI_DATA=0x00000000
> >>     HW_GPMI_STAT=0xff000005
> >>     HW_GPMI_DEBUG=0x00000101
> >>     r->clock[0]=99000000
> >> Scanning device for bad blocks
> >> 5 ofpart partitions found on MTD device gpmi-nand
> >> Creating 5 MTD partitions on "gpmi-nand":
> >> 0x000000000000-0x000000500000 : "u-boot"
> >> 0x000000500000-0x000000600000 : "u-boot-env"
> >> 0x000000600000-0x000000800000 : "log"
> >> 0x000000800000-0x000010000000 : "flash"
> >> 0x000000000000-0x000010000000 : "all"
> >> gpmi-nand 1806000.gpmi-nand: driver registered.
> >> ...
> >>
> >> Note that the first ENTRY dump has no matching EXIT dump. From the
> >> code I assume it is returning from gpmi_begin() at the
> >> "if (!hw.sample_delay_factor)" check.
> >>
> >>
> >> And for the 5.1.14 kernel:
> >>
> >> Linux version 5.1.14 (gerg@goober) (gcc version 4.8.3 (GCC)) #27 Tue Aug 13 10:20:32 AEST 2019
> >> ...
> >> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(512): gpmi_nfc_apply_timings(): ENTRY
> >>     HW_GPMI_CTRL0=0x00000000
> >>     HW_GPMI_CTRL1=0x01c4000c
> >>     HW_GPMI_COMPARE=0x00000000
> >>     HW_GPMI_ECCCTRL=0x00000400
> >>     HW_GPMI_ECCCOUNT=0x00000000
> >>     HW_GPMI_PAYLOAD=0x00000000
> >>     HW_GPMI_AUXILIARY=0x00000000
> >>     HW_GPMI_TIMING0=0x00010203
> >>     HW_GPMI_TIMING1=0x00000000
> >>     HW_GPMI_TIMING2=0x23023336
> >>     HW_GPMI_DATA=0x00000000
> >>     HW_GPMI_STAT=0xff000005
> >>     HW_GPMI_DEBUG=0x00000000
> >>     r->clock[0]=22000000
> >> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(536): gpmi_nfc_apply_timings(): EXIT
> >>     HW_GPMI_CTRL0=0x00000000
> >>     HW_GPMI_CTRL1=0x0104000c
> >>     HW_GPMI_COMPARE=0x00000000
> >>     HW_GPMI_ECCCTRL=0x00000400
> >>     HW_GPMI_ECCCOUNT=0x00000000
> >>     HW_GPMI_PAYLOAD=0x00000000
> >>     HW_GPMI_AUXILIARY=0x00000000
> >>     HW_GPMI_TIMING0=0x00020101
> >>     HW_GPMI_TIMING1=0x60000000
> >>     HW_GPMI_TIMING2=0x23023336
> >>     HW_GPMI_DATA=0x00000000
> >>     HW_GPMI_STAT=0xff000005
> >>     HW_GPMI_DEBUG=0x00000000
> >>     r->clock[0]=22000000
> >> random: fast init done
> >> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> >> nand: Micron MT29F2G08ABAEAWP
> >> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> >> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(512): gpmi_nfc_apply_timings(): ENTRY
> >>     HW_GPMI_CTRL0=0x01800001
> >>     HW_GPMI_CTRL1=0x0104000c
> >>     HW_GPMI_COMPARE=0x00000000
> >>     HW_GPMI_ECCCTRL=0x00000000
> >>     HW_GPMI_ECCCOUNT=0x00000000
> >>     HW_GPMI_PAYLOAD=0x00000000
> >>     HW_GPMI_AUXILIARY=0x00000000
> >>     HW_GPMI_TIMING0=0x00020101
> >>     HW_GPMI_TIMING1=0x60000000
> >>     HW_GPMI_TIMING2=0x23023336
> >>     HW_GPMI_DATA=0x0000003f
> >>     HW_GPMI_STAT=0xff000005
> >>     HW_GPMI_DEBUG=0x00000101
> >>     r->clock[0]=22000000
> >> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(536): gpmi_nfc_apply_timings(): EXIT
> >>     HW_GPMI_CTRL0=0x01800001
> >>     HW_GPMI_CTRL1=0x0104000c
> >>     HW_GPMI_COMPARE=0x00000000
> >>     HW_GPMI_ECCCTRL=0x00000000
> >>     HW_GPMI_ECCCOUNT=0x00000000
> >>     HW_GPMI_PAYLOAD=0x00000000
> >>     HW_GPMI_AUXILIARY=0x00000000
> >>     HW_GPMI_TIMING0=0x00020101
> >>     HW_GPMI_TIMING1=0xb0000000
> >>     HW_GPMI_TIMING2=0x23023336
> >>     HW_GPMI_DATA=0x0000003f
> >>     HW_GPMI_STAT=0xff000005
> >>     HW_GPMI_DEBUG=0x00000101
> >>     r->clock[0]=22000000
> >> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(512): gpmi_nfc_apply_timings(): ENTRY
> >>     HW_GPMI_CTRL0=0x01800001
> >>     HW_GPMI_CTRL1=0x0104000c
> >>     HW_GPMI_COMPARE=0x00000000
> >>     HW_GPMI_ECCCTRL=0x00000000
> >>     HW_GPMI_ECCCOUNT=0x00000000
> >>     HW_GPMI_PAYLOAD=0x00000000
> >>     HW_GPMI_AUXILIARY=0x00000000
> >>     HW_GPMI_TIMING0=0x00020101
> >>     HW_GPMI_TIMING1=0xb0000000
> >>     HW_GPMI_TIMING2=0x23023336
> >>     HW_GPMI_DATA=0x000000e0
> >>     HW_GPMI_STAT=0xff000005
> >>     HW_GPMI_DEBUG=0x00000000
> >>     r->clock[0]=22000000
> >> drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c(536): gpmi_nfc_apply_timings(): EXIT
> >>     HW_GPMI_CTRL0=0x01800001
> >>     HW_GPMI_CTRL1=0x01c6800c
> >>     HW_GPMI_COMPARE=0x00000000
> >>     HW_GPMI_ECCCTRL=0x00000000
> >>     HW_GPMI_ECCCOUNT=0x00000000
> >>     HW_GPMI_PAYLOAD=0x00000000
> >>     HW_GPMI_AUXILIARY=0x00000000
> >>     HW_GPMI_TIMING0=0x00010101
> >>     HW_GPMI_TIMING1=0xe0000000
> >>     HW_GPMI_TIMING2=0x23023336
> >>     HW_GPMI_DATA=0x000000e0
> >>     HW_GPMI_STAT=0xff000005
> >>     HW_GPMI_DEBUG=0x00000000
> >>     r->clock[0]=99000000
> >> Scanning device for bad blocks
> >> 5 fixed-partitions partitions found on MTD device gpmi-nand
> >> Creating 5 MTD partitions on "gpmi-nand":
> >> 0x000000000000-0x000000500000 : "u-boot"
> >> 0x000000500000-0x000000600000 : "u-boot-env"
> >> 0x000000600000-0x000000800000 : "log"
> >> 0x000000800000-0x000010000000 : "flash"
> >> 0x000000000000-0x000010000000 : "all"
> >> gpmi-nand 1806000.gpmi-nand: driver registered.
> >> ...
> >>
> >>
> >> Regards
> >> Greg
> >>
> >>
> >
> >



-- 
Michael Nazzareno Trimarchi
Amarula Solutions BV
COO Co-Founder
Cruquiuskade 47 Amsterdam 1018 AM NL
T. +31(0)851119172
M. +39(0)3479132170
[`as] https://www.amarulasolutions.com

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

^ permalink raw reply related	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-01-30  9:41                                                 ` Michael Nazzareno Trimarchi
@ 2021-02-01 14:13                                                   ` Miquel Raynal
  2021-02-01 14:32                                                     ` Michael Nazzareno Trimarchi
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel Raynal @ 2021-02-01 14:13 UTC (permalink / raw)
  To: Michael Nazzareno Trimarchi
  Cc: linux-mtd, Sascha Hauer, Greg Ungerer, Boris Brezillon, Boris Brezillon

Hi Michael,

Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
Sat, 30 Jan 2021 10:41:29 +0100:

> Hi Miquel
> 
> commit f8e6ad14388067f91b26d044185d95623fbc9535
> Author: Michael Trimarchi <michael@amarulasolutions.com>
> Date:   Fri Jan 29 08:46:53 2021 +0100
> 
>     mtd: nand: Calculate the clock before enable it
> 
>     Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
>     Change-Id: I79b0da39de0a9b32ea0b002fa200d7f44d4f8ce7
> 
> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> index 322a008290e5..0bca52b3bc8f 100644
> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> @@ -377,6 +377,7 @@ static void gpmi_nfc_compute_timings(struct
> gpmi_nand_data *this,
>                                      const struct nand_sdr_timings *sdr)
>  {
>         struct gpmi_nfc_hardware_timing *hw = &this->hw;
> +       struct resources *r = &this->resources;
>         unsigned int dll_threshold_ps = this->devdata->max_chain_delay;
>         unsigned int period_ps, reference_period_ps;
>         unsigned int data_setup_cycles, data_hold_cycles, addr_setup_cycles;
> @@ -440,6 +441,8 @@ static void gpmi_nfc_compute_timings(struct
> gpmi_nand_data *this,
>                 hw->ctrl1n |= BF_GPMI_CTRL1_RDN_DELAY(sample_delay_factor) |
>                               BM_GPMI_CTRL1_DLL_ENABLE |
>                               (use_half_period ? BM_GPMI_CTRL1_HALF_PERIOD : 0);
> +
> +       clk_set_rate(r->clock[0], hw->clk_rate);
>  }
> 
>  void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> @@ -449,8 +452,6 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>         void __iomem *gpmi_regs = r->gpmi_regs;
>         unsigned int dll_wait_time_us;
> 
> -       clk_set_rate(r->clock[0], hw->clk_rate);
> -
>         writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
>         writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);
> 
> Right now I have this change applied and seems fine. That is the only
> difference I get. Clock is apply a bit earlier that when is enabled
> it.

This is very interesting. So this would mean the issue you are
experiencing comes from the clock driver which kind of returns too
early from clk_set_rate()? Could you report this to the clk ML/NXP clk
maintainers and keep us in copy? If it is as global as it sounds, we
might not be the only ones affected.

Thanks,
Miquèl

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-02-01 14:13                                                   ` Miquel Raynal
@ 2021-02-01 14:32                                                     ` Michael Nazzareno Trimarchi
  2021-02-01 15:08                                                       ` Michael Nazzareno Trimarchi
  0 siblings, 1 reply; 85+ messages in thread
From: Michael Nazzareno Trimarchi @ 2021-02-01 14:32 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: linux-mtd, Sascha Hauer, Greg Ungerer, Boris Brezillon, Boris Brezillon

Hi

On Mon, Feb 1, 2021 at 3:13 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Michael,
>
> Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> Sat, 30 Jan 2021 10:41:29 +0100:
>
> > Hi Miquel
> >
> > commit f8e6ad14388067f91b26d044185d95623fbc9535
> > Author: Michael Trimarchi <michael@amarulasolutions.com>
> > Date:   Fri Jan 29 08:46:53 2021 +0100
> >
> >     mtd: nand: Calculate the clock before enable it
> >
> >     Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> >     Change-Id: I79b0da39de0a9b32ea0b002fa200d7f44d4f8ce7
> >
> > diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > index 322a008290e5..0bca52b3bc8f 100644
> > --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > @@ -377,6 +377,7 @@ static void gpmi_nfc_compute_timings(struct
> > gpmi_nand_data *this,
> >                                      const struct nand_sdr_timings *sdr)
> >  {
> >         struct gpmi_nfc_hardware_timing *hw = &this->hw;
> > +       struct resources *r = &this->resources;
> >         unsigned int dll_threshold_ps = this->devdata->max_chain_delay;
> >         unsigned int period_ps, reference_period_ps;
> >         unsigned int data_setup_cycles, data_hold_cycles, addr_setup_cycles;
> > @@ -440,6 +441,8 @@ static void gpmi_nfc_compute_timings(struct
> > gpmi_nand_data *this,
> >                 hw->ctrl1n |= BF_GPMI_CTRL1_RDN_DELAY(sample_delay_factor) |
> >                               BM_GPMI_CTRL1_DLL_ENABLE |
> >                               (use_half_period ? BM_GPMI_CTRL1_HALF_PERIOD : 0);
> > +
> > +       clk_set_rate(r->clock[0], hw->clk_rate);
> >  }
> >
> >  void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > @@ -449,8 +452,6 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >         void __iomem *gpmi_regs = r->gpmi_regs;
> >         unsigned int dll_wait_time_us;
> >
> > -       clk_set_rate(r->clock[0], hw->clk_rate);
> > -
> >         writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
> >         writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);
> >
> > Right now I have this change applied and seems fine. That is the only
> > difference I get. Clock is apply a bit earlier that when is enabled
> > it.
>
> This is very interesting. So this would mean the issue you are
> experiencing comes from the clock driver which kind of returns too
> early from clk_set_rate()? Could you report this to the clk ML/NXP clk
> maintainers and keep us in copy? If it is as global as it sounds, we
> might not be the only ones affected.
>

The imx28 is broken too, so it's a general problem. I need to trace it down
I have a reverting for lts but it\s not the way to go

Michael

> Thanks,
> Miquèl



-- 
Michael Nazzareno Trimarchi
Amarula Solutions BV
COO Co-Founder
Cruquiuskade 47 Amsterdam 1018 AM NL
T. +31(0)851119172
M. +39(0)3479132170
[`as] https://www.amarulasolutions.com

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-02-01 14:32                                                     ` Michael Nazzareno Trimarchi
@ 2021-02-01 15:08                                                       ` Michael Nazzareno Trimarchi
  2021-02-01 15:14                                                         ` Miquel Raynal
  0 siblings, 1 reply; 85+ messages in thread
From: Michael Nazzareno Trimarchi @ 2021-02-01 15:08 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: linux-mtd, Sascha Hauer, Greg Ungerer, Boris Brezillon, Boris Brezillon

Hi

On Mon, Feb 1, 2021 at 3:32 PM Michael Nazzareno Trimarchi
<michael@amarulasolutions.com> wrote:
>
> Hi
>
> On Mon, Feb 1, 2021 at 3:13 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Michael,
> >
> > Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> > Sat, 30 Jan 2021 10:41:29 +0100:
> >
> > > Hi Miquel
> > >
> > > commit f8e6ad14388067f91b26d044185d95623fbc9535
> > > Author: Michael Trimarchi <michael@amarulasolutions.com>
> > > Date:   Fri Jan 29 08:46:53 2021 +0100
> > >
> > >     mtd: nand: Calculate the clock before enable it
> > >
> > >     Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> > >     Change-Id: I79b0da39de0a9b32ea0b002fa200d7f44d4f8ce7
> > >
> > > diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > index 322a008290e5..0bca52b3bc8f 100644
> > > --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > @@ -377,6 +377,7 @@ static void gpmi_nfc_compute_timings(struct
> > > gpmi_nand_data *this,
> > >                                      const struct nand_sdr_timings *sdr)
> > >  {
> > >         struct gpmi_nfc_hardware_timing *hw = &this->hw;
> > > +       struct resources *r = &this->resources;
> > >         unsigned int dll_threshold_ps = this->devdata->max_chain_delay;
> > >         unsigned int period_ps, reference_period_ps;
> > >         unsigned int data_setup_cycles, data_hold_cycles, addr_setup_cycles;
> > > @@ -440,6 +441,8 @@ static void gpmi_nfc_compute_timings(struct
> > > gpmi_nand_data *this,
> > >                 hw->ctrl1n |= BF_GPMI_CTRL1_RDN_DELAY(sample_delay_factor) |
> > >                               BM_GPMI_CTRL1_DLL_ENABLE |
> > >                               (use_half_period ? BM_GPMI_CTRL1_HALF_PERIOD : 0);
> > > +
> > > +       clk_set_rate(r->clock[0], hw->clk_rate);
> > >  }
> > >
> > >  void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > @@ -449,8 +452,6 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > >         void __iomem *gpmi_regs = r->gpmi_regs;
> > >         unsigned int dll_wait_time_us;
> > >
> > > -       clk_set_rate(r->clock[0], hw->clk_rate);
> > > -
> > >         writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
> > >         writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);
> > >
> > > Right now I have this change applied and seems fine. That is the only
> > > difference I get. Clock is apply a bit earlier that when is enabled
> > > it.
> >
> > This is very interesting. So this would mean the issue you are
> > experiencing comes from the clock driver which kind of returns too
> > early from clk_set_rate()? Could you report this to the clk ML/NXP clk
> > maintainers and keep us in copy? If it is as global as it sounds, we
> > might not be the only ones affected.
> >
>
> The imx28 is broken too, so it's a general problem. I need to trace it down
> I have a reverting for lts but it\s not the way to go
>

For imx28 you ask to set the rate to 22Mhz but you don't care about the clock
that you get back. You get back 12Mhz because the base clock is 24 Mhz and seems
that it can not get the point. You need to check if the clock
requested is in range or ask
for set_rate_clk_min to avoid to have somenthing lower. Then for
imx6ull because is sporadic
I think that is more connected to the clk_set_rate and when you change
the register. Can not be a
setting time?

Michael

> Michael
>
> > Thanks,
> > Miquèl
>
>
>
> --
> Michael Nazzareno Trimarchi
> Amarula Solutions BV
> COO Co-Founder
> Cruquiuskade 47 Amsterdam 1018 AM NL
> T. +31(0)851119172
> M. +39(0)3479132170
> [`as] https://www.amarulasolutions.com



-- 
Michael Nazzareno Trimarchi
Amarula Solutions BV
COO Co-Founder
Cruquiuskade 47 Amsterdam 1018 AM NL
T. +31(0)851119172
M. +39(0)3479132170
[`as] https://www.amarulasolutions.com

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-02-01 15:08                                                       ` Michael Nazzareno Trimarchi
@ 2021-02-01 15:14                                                         ` Miquel Raynal
  2021-02-01 15:17                                                           ` Michael Nazzareno Trimarchi
  2021-10-15 20:05                                                           ` Michael Trimarchi
  0 siblings, 2 replies; 85+ messages in thread
From: Miquel Raynal @ 2021-02-01 15:14 UTC (permalink / raw)
  To: Michael Nazzareno Trimarchi
  Cc: linux-mtd, Sascha Hauer, Greg Ungerer, Boris Brezillon, Boris Brezillon

Hi Michael,

Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
Mon, 1 Feb 2021 16:08:23 +0100:

> Hi
> 
> On Mon, Feb 1, 2021 at 3:32 PM Michael Nazzareno Trimarchi
> <michael@amarulasolutions.com> wrote:
> >
> > Hi
> >
> > On Mon, Feb 1, 2021 at 3:13 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > >
> > > Hi Michael,
> > >
> > > Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> > > Sat, 30 Jan 2021 10:41:29 +0100:
> > >  
> > > > Hi Miquel
> > > >
> > > > commit f8e6ad14388067f91b26d044185d95623fbc9535
> > > > Author: Michael Trimarchi <michael@amarulasolutions.com>
> > > > Date:   Fri Jan 29 08:46:53 2021 +0100
> > > >
> > > >     mtd: nand: Calculate the clock before enable it
> > > >
> > > >     Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> > > >     Change-Id: I79b0da39de0a9b32ea0b002fa200d7f44d4f8ce7
> > > >
> > > > diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > index 322a008290e5..0bca52b3bc8f 100644
> > > > --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > @@ -377,6 +377,7 @@ static void gpmi_nfc_compute_timings(struct
> > > > gpmi_nand_data *this,
> > > >                                      const struct nand_sdr_timings *sdr)
> > > >  {
> > > >         struct gpmi_nfc_hardware_timing *hw = &this->hw;
> > > > +       struct resources *r = &this->resources;
> > > >         unsigned int dll_threshold_ps = this->devdata->max_chain_delay;
> > > >         unsigned int period_ps, reference_period_ps;
> > > >         unsigned int data_setup_cycles, data_hold_cycles, addr_setup_cycles;
> > > > @@ -440,6 +441,8 @@ static void gpmi_nfc_compute_timings(struct
> > > > gpmi_nand_data *this,
> > > >                 hw->ctrl1n |= BF_GPMI_CTRL1_RDN_DELAY(sample_delay_factor) |
> > > >                               BM_GPMI_CTRL1_DLL_ENABLE |
> > > >                               (use_half_period ? BM_GPMI_CTRL1_HALF_PERIOD : 0);
> > > > +
> > > > +       clk_set_rate(r->clock[0], hw->clk_rate);
> > > >  }
> > > >
> > > >  void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > > @@ -449,8 +452,6 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > >         void __iomem *gpmi_regs = r->gpmi_regs;
> > > >         unsigned int dll_wait_time_us;
> > > >
> > > > -       clk_set_rate(r->clock[0], hw->clk_rate);
> > > > -
> > > >         writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
> > > >         writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);
> > > >
> > > > Right now I have this change applied and seems fine. That is the only
> > > > difference I get. Clock is apply a bit earlier that when is enabled
> > > > it.  
> > >
> > > This is very interesting. So this would mean the issue you are
> > > experiencing comes from the clock driver which kind of returns too
> > > early from clk_set_rate()? Could you report this to the clk ML/NXP clk
> > > maintainers and keep us in copy? If it is as global as it sounds, we
> > > might not be the only ones affected.
> > >  
> >
> > The imx28 is broken too, so it's a general problem. I need to trace it down
> > I have a reverting for lts but it\s not the way to go
> >  
> 
> For imx28 you ask to set the rate to 22Mhz but you don't care about the clock
> that you get back. You get back 12Mhz because the base clock is 24 Mhz and seems
> that it can not get the point. You need to check if the clock
> requested is in range or ask
> for set_rate_clk_min to avoid to have somenthing lower. Then for
> imx6ull because is sporadic
> I think that is more connected to the clk_set_rate and when you change
> the register. Can not be a
> setting time?

So, if I understand correctly, we face two different problems:
- imx6*: seems like a clock issue regarding the clock settlement
- imx28: actual NAND driver issue (does not check the validity of the
  new frequency). This should be handled properly in
  ->setup_interface().

Thanks,
Miquèl

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-02-01 15:14                                                         ` Miquel Raynal
@ 2021-02-01 15:17                                                           ` Michael Nazzareno Trimarchi
  2021-10-15 20:05                                                           ` Michael Trimarchi
  1 sibling, 0 replies; 85+ messages in thread
From: Michael Nazzareno Trimarchi @ 2021-02-01 15:17 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: linux-mtd, Sascha Hauer, Greg Ungerer, Boris Brezillon, Boris Brezillon

Hi

On Mon, Feb 1, 2021 at 4:14 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Michael,
>
> Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> Mon, 1 Feb 2021 16:08:23 +0100:
>
> > Hi
> >
> > On Mon, Feb 1, 2021 at 3:32 PM Michael Nazzareno Trimarchi
> > <michael@amarulasolutions.com> wrote:
> > >
> > > Hi
> > >
> > > On Mon, Feb 1, 2021 at 3:13 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > >
> > > > Hi Michael,
> > > >
> > > > Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> > > > Sat, 30 Jan 2021 10:41:29 +0100:
> > > >
> > > > > Hi Miquel
> > > > >
> > > > > commit f8e6ad14388067f91b26d044185d95623fbc9535
> > > > > Author: Michael Trimarchi <michael@amarulasolutions.com>
> > > > > Date:   Fri Jan 29 08:46:53 2021 +0100
> > > > >
> > > > >     mtd: nand: Calculate the clock before enable it
> > > > >
> > > > >     Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> > > > >     Change-Id: I79b0da39de0a9b32ea0b002fa200d7f44d4f8ce7
> > > > >
> > > > > diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > index 322a008290e5..0bca52b3bc8f 100644
> > > > > --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > @@ -377,6 +377,7 @@ static void gpmi_nfc_compute_timings(struct
> > > > > gpmi_nand_data *this,
> > > > >                                      const struct nand_sdr_timings *sdr)
> > > > >  {
> > > > >         struct gpmi_nfc_hardware_timing *hw = &this->hw;
> > > > > +       struct resources *r = &this->resources;
> > > > >         unsigned int dll_threshold_ps = this->devdata->max_chain_delay;
> > > > >         unsigned int period_ps, reference_period_ps;
> > > > >         unsigned int data_setup_cycles, data_hold_cycles, addr_setup_cycles;
> > > > > @@ -440,6 +441,8 @@ static void gpmi_nfc_compute_timings(struct
> > > > > gpmi_nand_data *this,
> > > > >                 hw->ctrl1n |= BF_GPMI_CTRL1_RDN_DELAY(sample_delay_factor) |
> > > > >                               BM_GPMI_CTRL1_DLL_ENABLE |
> > > > >                               (use_half_period ? BM_GPMI_CTRL1_HALF_PERIOD : 0);
> > > > > +
> > > > > +       clk_set_rate(r->clock[0], hw->clk_rate);
> > > > >  }
> > > > >
> > > > >  void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > > > @@ -449,8 +452,6 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > > >         void __iomem *gpmi_regs = r->gpmi_regs;
> > > > >         unsigned int dll_wait_time_us;
> > > > >
> > > > > -       clk_set_rate(r->clock[0], hw->clk_rate);
> > > > > -
> > > > >         writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
> > > > >         writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);
> > > > >
> > > > > Right now I have this change applied and seems fine. That is the only
> > > > > difference I get. Clock is apply a bit earlier that when is enabled
> > > > > it.
> > > >
> > > > This is very interesting. So this would mean the issue you are
> > > > experiencing comes from the clock driver which kind of returns too
> > > > early from clk_set_rate()? Could you report this to the clk ML/NXP clk
> > > > maintainers and keep us in copy? If it is as global as it sounds, we
> > > > might not be the only ones affected.
> > > >
> > >
> > > The imx28 is broken too, so it's a general problem. I need to trace it down
> > > I have a reverting for lts but it\s not the way to go
> > >
> >
> > For imx28 you ask to set the rate to 22Mhz but you don't care about the clock
> > that you get back. You get back 12Mhz because the base clock is 24 Mhz and seems
> > that it can not get the point. You need to check if the clock
> > requested is in range or ask
> > for set_rate_clk_min to avoid to have somenthing lower. Then for
> > imx6ull because is sporadic
> > I think that is more connected to the clk_set_rate and when you change
> > the register. Can not be a
> > setting time?
>
> So, if I understand correctly, we face two different problems:
> - imx6*: seems like a clock issue regarding the clock settlement
> - imx28: actual NAND driver issue (does not check the validity of the
>   new frequency). This should be handled properly in
>   ->setup_interface().

I'm planning to work on it, I need to deliver on the field updates on
the new LTS release.
Everything is correct what you said. I will check and try to fix the
issues properly after this

Michael

>
> Thanks,
> Miquèl



-- 
Michael Nazzareno Trimarchi
Amarula Solutions BV
COO Co-Founder
Cruquiuskade 47 Amsterdam 1018 AM NL
T. +31(0)851119172
M. +39(0)3479132170
[`as] https://www.amarulasolutions.com

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2019-07-29  6:41 GPMI iMX6ull timeout on DMA Greg Ungerer
  2019-07-29  8:36 ` Miquel Raynal
@ 2021-10-04  5:54 ` Christian Eggers
  2021-10-04  6:27   ` Michael Nazzareno Trimarchi
  1 sibling, 1 reply; 85+ messages in thread
From: Christian Eggers @ 2021-10-04  5:54 UTC (permalink / raw)
  To: linux-mtd
  Cc: Miquel Raynal, Greg Ungerer, Michael Nazzareno Trimarchi, Han Xu,
	Sascha Hauer

On Monday, 29 July 2019, 08:41:51 CEST, Greg Ungerer wrote:
> Hi Miquel,
> 
> I am experiencing a problem with NAND flash DMA timeouts on
> iMX6ull based boards. The problem is very similar to that
> described in:
> 
>    https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
> 
> That didn't come to any specific resolution that I could see
> in that thread.

Hi all,

I am joining this thread because I am also affected by this problem. I use
kernel 5.10.65-rt53 but I have seen this issue on many previous versions. In the
past I only recognized this on my development setup but now this has been found
by our testing team.

In our test setup we simply perform a reboot every 30s. After 5 to 200 cycles
the test stops due to this error.

The kernel version I use already includes:

> Han Xu <han.xu@nxp.com>
> mtd: rawnand: gpmi: Fix the random DMA timeout issue

Additionally I tried ...

> Michael Trimarchi <michael@amarulasolutions.com>
> mtd: nand: Calculate the clock before enable it

... but the problem still persists.

In my case, some registers show different values (annotated below):

> 
> The boot trace on the console for me looks like this:
> 
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
  nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc
> nand: Micron MT29F2G08ABAEAWP
  nand: Micron MT29F4G08ABADAH4
> nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
  gpmi-nand 1806000.nand-controller: offset 0x0c0 : 0x00000202
> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
  gpmi-nand 1806000.nand-controller: offset 0x000 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
  gpmi-nand 1806000.nand-controller: offset 0x080 : 0x070a4080
> gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
  gpmi-nand 1806000.nand-controller: offset 0x090 : 0x10da4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> GF length              : 13
> ECC Strength           : 8
> Page Size in Bytes     : 2110
> Metadata Size in Bytes : 10
> ECC Chunk0 Size in Bytes: 512
> ECC Chunkn Size in Bytes: 512
  ECC Chunk Size in Bytes: 512
> ECC Chunk Count        : 4
> Payload Size in Bytes  : 2048
> Auxiliary Size in Bytes: 16
> Auxiliary Status Offset: 12
> Block Mark Byte Offset : 1999
> Block Mark Bit Offset  : 0

Please let me know if further information is required.

regards
Christian





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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-04  5:54 ` Christian Eggers
@ 2021-10-04  6:27   ` Michael Nazzareno Trimarchi
  2021-10-04 15:33     ` Miquel Raynal
  0 siblings, 1 reply; 85+ messages in thread
From: Michael Nazzareno Trimarchi @ 2021-10-04  6:27 UTC (permalink / raw)
  To: Christian Eggers
  Cc: linux-mtd, Miquel Raynal, Greg Ungerer, Han Xu, Sascha Hauer

Hi Christian

On Mon, Oct 4, 2021 at 7:54 AM Christian Eggers <ceggers@arri.de> wrote:
>
> On Monday, 29 July 2019, 08:41:51 CEST, Greg Ungerer wrote:
> > Hi Miquel,
> >
> > I am experiencing a problem with NAND flash DMA timeouts on
> > iMX6ull based boards. The problem is very similar to that
> > described in:
> >
> >    https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
> >
> > That didn't come to any specific resolution that I could see
> > in that thread.
>
> Hi all,
>
> I am joining this thread because I am also affected by this problem. I use
> kernel 5.10.65-rt53 but I have seen this issue on many previous versions. In the
> past I only recognized this on my development setup but now this has been found
> by our testing team.
>
> In our test setup we simply perform a reboot every 30s. After 5 to 200 cycles
> the test stops due to this error.
>
> The kernel version I use already includes:
>
> > Han Xu <han.xu@nxp.com>
> > mtd: rawnand: gpmi: Fix the random DMA timeout issue
>
> Additionally I tried ...
>
> > Michael Trimarchi <michael@amarulasolutions.com>
> > mtd: nand: Calculate the clock before enable it
>
> ... but the problem still persists.
>
> In my case, some registers show different values (annotated below):
>
> >
> > The boot trace on the console for me looks like this:
> >
> > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
>   nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc
> > nand: Micron MT29F2G08ABAEAWP
>   nand: Micron MT29F4G08ABADAH4
> > nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> > gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> > gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> > gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> > gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> > gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> > gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> > gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> > gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001
>   gpmi-nand 1806000.nand-controller: offset 0x0c0 : 0x00000202
> > gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> > gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> > gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
>   gpmi-nand 1806000.nand-controller: offset 0x000 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> > gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
>   gpmi-nand 1806000.nand-controller: offset 0x080 : 0x070a4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
>   gpmi-nand 1806000.nand-controller: offset 0x090 : 0x10da4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> > gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> > gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> > gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> > gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> > GF length              : 13
> > ECC Strength           : 8
> > Page Size in Bytes     : 2110
> > Metadata Size in Bytes : 10
> > ECC Chunk0 Size in Bytes: 512
> > ECC Chunkn Size in Bytes: 512
>   ECC Chunk Size in Bytes: 512
> > ECC Chunk Count        : 4
> > Payload Size in Bytes  : 2048
> > Auxiliary Size in Bytes: 16
> > Auxiliary Status Offset: 12
> > Block Mark Byte Offset : 1999
> > Block Mark Bit Offset  : 0
>
> Please let me know if further information is required.

I need to continue on it, during the following days. I have stopped
moving to LTS 4.19.y and with my partial revert.
The problem as usual was to go to production on some devices. Anyway I
have the device that has this problem. I can
restart next weekend. One of the thing I notice that make not work on imx28 is:

       if (sdr->tRC_min >= 30000) {
               /* ONFI non-EDO modes [0-3] */
               hw->clk_rate = 22000000;
               wrn_dly_sel = BV_GPMI_CTRL1_WRN_DLY_SEL_4_TO_8NS;
       } else if (sdr->tRC_min >= 25000) {
               /* ONFI EDO mode 4 */
               hw->clk_rate = 80000000;
               wrn_dly_sel = BV_GPMI_CTRL1_WRN_DLY_SEL_NO_DELAY;
       } else {
               /* ONFI EDO mode 5 */
               hw->clk_rate = 100000000;
               wrn_dly_sel = BV_GPMI_CTRL1_WRN_DLY_SEL_NO_DELAY;
       }

Here there is an assumption that your clk_rate can be set to that rate
but on imx28, the parent clock of the NAND one can not
let it go to those speed. Changing it let it really set to the wrong
value, so imx28 was totally broken. The other computation was based
not on fixed clock rate but I think even on clk_get_rate

Michael

>
> regards
> Christian
>
>
>
>


-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael@amarulasolutions.com
__________________________________

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info@amarulasolutions.com
www.amarulasolutions.com

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-04  6:27   ` Michael Nazzareno Trimarchi
@ 2021-10-04 15:33     ` Miquel Raynal
  2021-10-04 16:06       ` Han Xu
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel Raynal @ 2021-10-04 15:33 UTC (permalink / raw)
  To: Michael Nazzareno Trimarchi
  Cc: Christian Eggers, linux-mtd, Greg Ungerer, Han Xu, Sascha Hauer

Hi Michael, Christian,

michael@amarulasolutions.com wrote on Mon, 4 Oct 2021 08:27:54 +0200:

> Hi Christian
> 
> On Mon, Oct 4, 2021 at 7:54 AM Christian Eggers <ceggers@arri.de> wrote:
> >
> > On Monday, 29 July 2019, 08:41:51 CEST, Greg Ungerer wrote:  
> > > Hi Miquel,
> > >
> > > I am experiencing a problem with NAND flash DMA timeouts on
> > > iMX6ull based boards. The problem is very similar to that
> > > described in:
> > >
> > >    https://linux-mtd.infradead.narkive.com/JIUulfFB/gpmi-imx6ull-timeout-on-dma
> > >
> > > That didn't come to any specific resolution that I could see
> > > in that thread.  
> >
> > Hi all,
> >
> > I am joining this thread because I am also affected by this problem. I use
> > kernel 5.10.65-rt53 but I have seen this issue on many previous versions. In the
> > past I only recognized this on my development setup but now this has been found
> > by our testing team.
> >
> > In our test setup we simply perform a reboot every 30s. After 5 to 200 cycles
> > the test stops due to this error.
> >
> > The kernel version I use already includes:
> >  
> > > Han Xu <han.xu@nxp.com>
> > > mtd: rawnand: gpmi: Fix the random DMA timeout issue  
> >
> > Additionally I tried ...
> >  
> > > Michael Trimarchi <michael@amarulasolutions.com>
> > > mtd: nand: Calculate the clock before enable it  
> >
> > ... but the problem still persists.
> >
> > In my case, some registers show different values (annotated below):
> >  
> > >
> > > The boot trace on the console for me looks like this:
> > >
> > > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda  
> >   nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc  
> > > nand: Micron MT29F2G08ABAEAWP  
> >   nand: Micron MT29F4G08ABADAH4  
> > > nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> > > gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> > > gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> > > gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> > > gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> > > gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001  
> >   gpmi-nand 1806000.nand-controller: offset 0x0c0 : 0x00000202  
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> > > gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> > > gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100  
> >   gpmi-nand 1806000.nand-controller: offset 0x000 : 0x00000000  
> > > gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> > > gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080  
> >   gpmi-nand 1806000.nand-controller: offset 0x080 : 0x070a4080  
> > > gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080  
> >   gpmi-nand 1806000.nand-controller: offset 0x090 : 0x10da4080  
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> > > gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> > > gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> > > gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> > > gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> > > gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> > > GF length              : 13
> > > ECC Strength           : 8
> > > Page Size in Bytes     : 2110
> > > Metadata Size in Bytes : 10
> > > ECC Chunk0 Size in Bytes: 512
> > > ECC Chunkn Size in Bytes: 512  
> >   ECC Chunk Size in Bytes: 512  
> > > ECC Chunk Count        : 4
> > > Payload Size in Bytes  : 2048
> > > Auxiliary Size in Bytes: 16
> > > Auxiliary Status Offset: 12
> > > Block Mark Byte Offset : 1999
> > > Block Mark Bit Offset  : 0  
> >
> > Please let me know if further information is required.  
> 
> I need to continue on it, during the following days. I have stopped
> moving to LTS 4.19.y and with my partial revert.
> The problem as usual was to go to production on some devices. Anyway I
> have the device that has this problem. I can
> restart next weekend. One of the thing I notice that make not work on imx28 is:
> 
>        if (sdr->tRC_min >= 30000) {
>                /* ONFI non-EDO modes [0-3] */
>                hw->clk_rate = 22000000;
>                wrn_dly_sel = BV_GPMI_CTRL1_WRN_DLY_SEL_4_TO_8NS;
>        } else if (sdr->tRC_min >= 25000) {
>                /* ONFI EDO mode 4 */
>                hw->clk_rate = 80000000;
>                wrn_dly_sel = BV_GPMI_CTRL1_WRN_DLY_SEL_NO_DELAY;
>        } else {
>                /* ONFI EDO mode 5 */
>                hw->clk_rate = 100000000;
>                wrn_dly_sel = BV_GPMI_CTRL1_WRN_DLY_SEL_NO_DELAY;
>        }
> 
> Here there is an assumption that your clk_rate can be set to that rate
> but on imx28, the parent clock of the NAND one can not
> let it go to those speed. Changing it let it really set to the wrong
> value, so imx28 was totally broken. The other computation was based
> not on fixed clock rate but I think even on clk_get_rate

Interesting finding. I guess we should try to apply the desired block
rate and if the final clock rate is too far from what is achievable and
works we should refuse the requested configuration. The core will
automatically try the slowest -but perhaps working- modes.

Thanks,
Miquèl

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-04 15:33     ` Miquel Raynal
@ 2021-10-04 16:06       ` Han Xu
  2021-10-05  6:02         ` Christian Eggers
  2021-10-08  9:55         ` Christian Eggers
  0 siblings, 2 replies; 85+ messages in thread
From: Han Xu @ 2021-10-04 16:06 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: Michael Nazzareno Trimarchi, Christian Eggers, linux-mtd,
	Greg Ungerer, Sascha Hauer

On 21/10/04 05:33PM, Miquel Raynal wrote:
> Hi Michael, Christian,
> 
> michael@amarulasolutions.com wrote on Mon, 4 Oct 2021 08:27:54 +0200:
> 
> > Hi Christian
> > 
> > On Mon, Oct 4, 2021 at 7:54 AM Christian Eggers <ceggers@arri.de> wrote:
> > >
> > > On Monday, 29 July 2019, 08:41:51 CEST, Greg Ungerer wrote:  
> > > > Hi Miquel,
> > > >
> > > > I am experiencing a problem with NAND flash DMA timeouts on
> > > > iMX6ull based boards. The problem is very similar to that
> > > > described in:
> > > >
> > > >    https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flinux-mtd.infradead.narkive.com%2FJIUulfFB%2Fgpmi-imx6ull-timeout-on-dma&amp;data=04%7C01%7Chan.xu%40nxp.com%7C278d7b93edbb4b72923408d9874c5ffe%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637689584362563293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=uSkVTsEF9yhHt5ZstJMbPIjUQbHzjhiHMjO9eDgFSg0%3D&amp;reserved=0
> > > >
> > > > That didn't come to any specific resolution that I could see
> > > > in that thread.  
> > >
> > > Hi all,
> > >
> > > I am joining this thread because I am also affected by this problem. I use
> > > kernel 5.10.65-rt53 but I have seen this issue on many previous versions. In the
> > > past I only recognized this on my development setup but now this has been found
> > > by our testing team.
> > >
> > > In our test setup we simply perform a reboot every 30s. After 5 to 200 cycles
> > > the test stops due to this error.
> > >
> > > The kernel version I use already includes:
> > >  
> > > > Han Xu <han.xu@nxp.com>
> > > > mtd: rawnand: gpmi: Fix the random DMA timeout issue  
> > >
> > > Additionally I tried ...
> > >  
> > > > Michael Trimarchi <michael@amarulasolutions.com>
> > > > mtd: nand: Calculate the clock before enable it  
> > >
> > > ... but the problem still persists.
> > >
> > > In my case, some registers show different values (annotated below):
> > >  
> > > >
> > > > The boot trace on the console for me looks like this:
> > > >
> > > > nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda  
> > >   nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc  
> > > > nand: Micron MT29F2G08ABAEAWP  
> > >   nand: Micron MT29F4G08ABADAH4  
> > > > nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> > > > gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA
> > > > gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000001  
> > >   gpmi-nand 1806000.nand-controller: offset 0x0c0 : 0x00000202  
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> > > > gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100  
> > >   gpmi-nand 1806000.nand-controller: offset 0x000 : 0x00000000  
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080  
> > >   gpmi-nand 1806000.nand-controller: offset 0x080 : 0x070a4080  
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080  
> > >   gpmi-nand 1806000.nand-controller: offset 0x090 : 0x10da4080  
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> > > > gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> > > > gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> > > > GF length              : 13
> > > > ECC Strength           : 8
> > > > Page Size in Bytes     : 2110
> > > > Metadata Size in Bytes : 10
> > > > ECC Chunk0 Size in Bytes: 512
> > > > ECC Chunkn Size in Bytes: 512  
> > >   ECC Chunk Size in Bytes: 512  
> > > > ECC Chunk Count        : 4
> > > > Payload Size in Bytes  : 2048
> > > > Auxiliary Size in Bytes: 16
> > > > Auxiliary Status Offset: 12
> > > > Block Mark Byte Offset : 1999
> > > > Block Mark Bit Offset  : 0  
> > >
> > > Please let me know if further information is required.  

Could you please try to add clock dis/enable when setting clock rate, in case
clock glitches.

clk_disable_unprepare(r->clock[0]);
clk_set_rate(r->clock[0], hw->clk_rate);
clk_prepare_enable(r->clock[0]);

> > 
> > I need to continue on it, during the following days. I have stopped
> > moving to LTS 4.19.y and with my partial revert.
> > The problem as usual was to go to production on some devices. Anyway I
> > have the device that has this problem. I can
> > restart next weekend. One of the thing I notice that make not work on imx28 is:
> > 
> >        if (sdr->tRC_min >= 30000) {
> >                /* ONFI non-EDO modes [0-3] */
> >                hw->clk_rate = 22000000;
> >                wrn_dly_sel = BV_GPMI_CTRL1_WRN_DLY_SEL_4_TO_8NS;
> >        } else if (sdr->tRC_min >= 25000) {
> >                /* ONFI EDO mode 4 */
> >                hw->clk_rate = 80000000;
> >                wrn_dly_sel = BV_GPMI_CTRL1_WRN_DLY_SEL_NO_DELAY;
> >        } else {
> >                /* ONFI EDO mode 5 */
> >                hw->clk_rate = 100000000;
> >                wrn_dly_sel = BV_GPMI_CTRL1_WRN_DLY_SEL_NO_DELAY;
> >        }
> > 
> > Here there is an assumption that your clk_rate can be set to that rate
> > but on imx28, the parent clock of the NAND one can not
> > let it go to those speed. Changing it let it really set to the wrong
> > value, so imx28 was totally broken. The other computation was based
> > not on fixed clock rate but I think even on clk_get_rate
> 
> Interesting finding. I guess we should try to apply the desired block
> rate and if the final clock rate is too far from what is achievable and
> works we should refuse the requested configuration. The core will
> automatically try the slowest -but perhaps working- modes.
> 
> Thanks,
> Miquèl

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-04 16:06       ` Han Xu
@ 2021-10-05  6:02         ` Christian Eggers
  2021-10-08  9:55         ` Christian Eggers
  1 sibling, 0 replies; 85+ messages in thread
From: Christian Eggers @ 2021-10-05  6:02 UTC (permalink / raw)
  To: Miquel Raynal, Han Xu
  Cc: Michael Nazzareno Trimarchi, linux-mtd, Greg Ungerer, Sascha Hauer

On Monday, 4 October 2021, 18:06:20 CEST, Han Xu wrote:
> 
> Could you please try to add clock dis/enable when setting clock rate, in case
> clock glitches.
> 
> clk_disable_unprepare(r->clock[0]);
> clk_set_rate(r->clock[0], hw->clk_rate);
> clk_prepare_enable(r->clock[0]);
> 
This looks promising! Last night I had a successful test run with more than 
600 reboots! The test only stopped because my network was disturbed by the
daily backup run...

I'll do further tests within the next 24 hours.

regards
Christian




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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-04 16:06       ` Han Xu
  2021-10-05  6:02         ` Christian Eggers
@ 2021-10-08  9:55         ` Christian Eggers
  2021-10-08 12:08           ` Stefan Riedmüller
  1 sibling, 1 reply; 85+ messages in thread
From: Christian Eggers @ 2021-10-08  9:55 UTC (permalink / raw)
  To: Miquel Raynal, Han Xu
  Cc: Michael Nazzareno Trimarchi, linux-mtd, Greg Ungerer,
	Sascha Hauer, Stefan Riedmueller, Christian Hemp

+ set PHYTEC developers on (B)CC

On Monday, 4 October 2021, 18:06:20 CEST, Han Xu wrote:
> 
> Could you please try to add clock dis/enable when setting clock rate, in case
> clock glitches.
> 
> clk_disable_unprepare(r->clock[0]);
> clk_set_rate(r->clock[0], hw->clk_rate);
> clk_prepare_enable(r->clock[0]);
> 

With this change, we made over 2000 successful reboots without any GPMI DMA
timeout problems!

From PHYTEC (our BSP supplier), I got some possible background for this
problem. For older revisions of IMX6DQ there was an errata (ERR007117, [1])
in the ROM bootloader which triggers a similar / the same behavior:

> For raw NAND boot, ROM switches the source of enfc_clk_root from PLL2_PFD2
> to PLL3. The root clock is required to be gated before switching the source
> clock. If the root clock is not gated, clock glitches might be passed to
> the divider that follows the clock mux, and the divider might behave
> unpredictably.
> ...
> This problem can also occur elsewhere in application code if the root clock
> is not properly gated when the clock configuration is changed.

In my case (Linux boot on i.MX6ULL), I recognized that on the 3rd call of
gpmi_nfc_apply_timings(), the rate of r->clock[0] is changed 

- from: 22 MHz (CS2CDR::ENFC_CLK_PRED=6 and CS2CDR::ENFC_CLK_PODF=3)
- to:  100 MHz (CS2CDR::ENFC_CLK_PRED=4 and CS2CDR::ENFC_CLK_PODF=1)

The proposal from from Han Xu
> clk_disable_unprepare(r->clock[0]);
> clk_set_rate(r->clock[0], hw->clk_rate);
> clk_prepare_enable(r->clock[0]);
disables only CCGR4::CG14 [RAWNAND_U_GPMI_BCH_INPUT_GPMI_IO_CLK_ENABLE] during
the rate change. While this works very fine on my system, this probably doesn't
fulfill the requirements in the errata description:

> For other occurrences in application code, the following procedure should be
> followed to change the clock configuration for the enfc_clk_root:
> 1) Gate (disable) the GPMI/BCH clocks in register CCM_CCGR4.
> 2) Gate (disable) the enfc_clk_root before changing the enfc_clk_root source
>    or dividers by clearing CCM_CCGR2[CG7] to 2’b00. This disables the
>    iomux_ipt_clk_io_clk.
> 3) Configure CCM_CS2CDR for the new clock source configuration.
> 4) Enable enfc_clk_root by setting CCM_CCGR2[CG7] to 2’b11. This enables the
>    iomux_ipt_clk_io_clk.
> 5) Enable the GPMI/BCH clocks in register CCM_CCGR4

I got another solution from PHYTEC ([2], not lengthy tested yet), which
disables all GPMI/BCH clocks on CCGR4 (verified with a JTAG debugger):
- CCGR4::CG15  [RAWNAND_U_GPMI_INPUT_APB_CLK_ENABLE]
- CCGR4::CG14  [RAWNAND_U_GPMI_BCH_INPUT_GPMI_IO_CLK_ENABLE]
- CCGR4::CG13  [RAWNAND_U_GPMI_BCH_INPUT_BCH_CLK_ENABLE]
- CCGR4::CG12  [RAWNAND_U_BCH_INPUT_APB_CLK_ENABLE]
- CCGR4::CG6   [PL301_MX6QPER1_BCHCLK_ENABLE]

CCM_CCGR2[CG7] is used for IOMUX_IPT_CLK_IO_ENABLE on i.MX6ULL, so step 2.
seems not to apply here. Actually I don't know how to gate ENFC_CLK_ROOT.

I will cyclic test the solution from PHYTEC over the weekend.

@Han Xu: Should I prefer the solution from PHYTEC?
@Stefan Riedmueller: Are you willing to commit this upstream?

regards
Christian


[1] https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf
[2] https://git.phytec.de/linux-mainline/commit/?h=v5.10.48-phy&id=866939ea8110764d9c12af960d746e2f7f5debe3




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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-08  9:55         ` Christian Eggers
@ 2021-10-08 12:08           ` Stefan Riedmüller
  2021-10-08 12:27             ` Miquel Raynal
  2021-10-09  6:33             ` Christian Eggers
  0 siblings, 2 replies; 85+ messages in thread
From: Stefan Riedmüller @ 2021-10-08 12:08 UTC (permalink / raw)
  To: ceggers
  Cc: s.hauer, han.xu, michael, Christian Hemp, gerg, miquel.raynal, linux-mtd

Hi Christian,

On Fri, 2021-10-08 at 11:55 +0200, Christian Eggers wrote:
> + set PHYTEC developers on (B)CC
> 
> On Monday, 4 October 2021, 18:06:20 CEST, Han Xu wrote:
> > Could you please try to add clock dis/enable when setting clock rate, in
> > case
> > clock glitches.
> > 
> > clk_disable_unprepare(r->clock[0]);
> > clk_set_rate(r->clock[0], hw->clk_rate);
> > clk_prepare_enable(r->clock[0]);
> > 
> 
> With this change, we made over 2000 successful reboots without any GPMI DMA
> timeout problems!
> 
> From PHYTEC (our BSP supplier), I got some possible background for this
> problem. For older revisions of IMX6DQ there was an errata (ERR007117, [1])
> in the ROM bootloader which triggers a similar / the same behavior:
> 
> > For raw NAND boot, ROM switches the source of enfc_clk_root from PLL2_PFD2
> > to PLL3. The root clock is required to be gated before switching the
> > source
> > clock. If the root clock is not gated, clock glitches might be passed to
> > the divider that follows the clock mux, and the divider might behave
> > unpredictably.
> > ...
> > This problem can also occur elsewhere in application code if the root
> > clock
> > is not properly gated when the clock configuration is changed.
> 
> In my case (Linux boot on i.MX6ULL), I recognized that on the 3rd call of
> gpmi_nfc_apply_timings(), the rate of r->clock[0] is changed 
> 
> - from: 22 MHz (CS2CDR::ENFC_CLK_PRED=6 and CS2CDR::ENFC_CLK_PODF=3)
> - to:  100 MHz (CS2CDR::ENFC_CLK_PRED=4 and CS2CDR::ENFC_CLK_PODF=1)
> 
> The proposal from from Han Xu
> > clk_disable_unprepare(r->clock[0]);
> > clk_set_rate(r->clock[0], hw->clk_rate);
> > clk_prepare_enable(r->clock[0]);
> disables only CCGR4::CG14 [RAWNAND_U_GPMI_BCH_INPUT_GPMI_IO_CLK_ENABLE]
> during
> the rate change. While this works very fine on my system, this probably
> doesn't
> fulfill the requirements in the errata description:
> 
> > For other occurrences in application code, the following procedure should
> > be
> > followed to change the clock configuration for the enfc_clk_root:
> > 1) Gate (disable) the GPMI/BCH clocks in register CCM_CCGR4.
> > 2) Gate (disable) the enfc_clk_root before changing the enfc_clk_root
> > source
> >    or dividers by clearing CCM_CCGR2[CG7] to 2’b00. This disables the
> >    iomux_ipt_clk_io_clk.
> > 3) Configure CCM_CS2CDR for the new clock source configuration.
> > 4) Enable enfc_clk_root by setting CCM_CCGR2[CG7] to 2’b11. This enables
> > the
> >    iomux_ipt_clk_io_clk.
> > 5) Enable the GPMI/BCH clocks in register CCM_CCGR4
> 
> I got another solution from PHYTEC ([2], not lengthy tested yet), which
> disables all GPMI/BCH clocks on CCGR4 (verified with a JTAG debugger):
> - CCGR4::CG15  [RAWNAND_U_GPMI_INPUT_APB_CLK_ENABLE]
> - CCGR4::CG14  [RAWNAND_U_GPMI_BCH_INPUT_GPMI_IO_CLK_ENABLE]
> - CCGR4::CG13  [RAWNAND_U_GPMI_BCH_INPUT_BCH_CLK_ENABLE]
> - CCGR4::CG12  [RAWNAND_U_BCH_INPUT_APB_CLK_ENABLE]
> - CCGR4::CG6   [PL301_MX6QPER1_BCHCLK_ENABLE]
> 
> CCM_CCGR2[CG7] is used for IOMUX_IPT_CLK_IO_ENABLE on i.MX6ULL, so step 2.
> seems not to apply here. Actually I don't know how to gate ENFC_CLK_ROOT.
> 
> I will cyclic test the solution from PHYTEC over the weekend.
> 
> @Han Xu: Should I prefer the solution from PHYTEC?
> @Stefan Riedmueller: Are you willing to commit this upstream?

Yes sure, I can prepare a patch beginning of next week.
BTW, we have seen these DMA timeout issues on the i.MX6 SOCs as well. So this
fix is not only for the i.MX 6ULL.

Regards,
Stefan

> 
> regards
> Christian
> 
> 
> [1] https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf
> [2] 
> https://git.phytec.de/linux-mainline/commit/?h=v5.10.48-phy&id=866939ea8110764d9c12af960d746e2f7f5debe3
> 
> 
> 
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-08 12:08           ` Stefan Riedmüller
@ 2021-10-08 12:27             ` Miquel Raynal
  2021-10-08 13:11               ` Christian Eggers
  2021-10-08 13:13               ` Christian Eggers
  2021-10-09  6:33             ` Christian Eggers
  1 sibling, 2 replies; 85+ messages in thread
From: Miquel Raynal @ 2021-10-08 12:27 UTC (permalink / raw)
  To: Stefan Riedmüller
  Cc: ceggers, s.hauer, han.xu, michael, Christian Hemp, gerg, linux-mtd

Hello,

S.Riedmueller@phytec.de wrote on Fri, 8 Oct 2021 12:08:01 +0000:

> Hi Christian,
> 
> On Fri, 2021-10-08 at 11:55 +0200, Christian Eggers wrote:
> > + set PHYTEC developers on (B)CC
> > 
> > On Monday, 4 October 2021, 18:06:20 CEST, Han Xu wrote:  
> > > Could you please try to add clock dis/enable when setting clock rate, in
> > > case
> > > clock glitches.
> > > 
> > > clk_disable_unprepare(r->clock[0]);
> > > clk_set_rate(r->clock[0], hw->clk_rate);
> > > clk_prepare_enable(r->clock[0]);
> > >   
> > 
> > With this change, we made over 2000 successful reboots without any GPMI DMA
> > timeout problems!
> > 
> > From PHYTEC (our BSP supplier), I got some possible background for this
> > problem. For older revisions of IMX6DQ there was an errata (ERR007117, [1])
> > in the ROM bootloader which triggers a similar / the same behavior:
> >   
> > > For raw NAND boot, ROM switches the source of enfc_clk_root from PLL2_PFD2
> > > to PLL3. The root clock is required to be gated before switching the
> > > source
> > > clock. If the root clock is not gated, clock glitches might be passed to
> > > the divider that follows the clock mux, and the divider might behave
> > > unpredictably.
> > > ...
> > > This problem can also occur elsewhere in application code if the root
> > > clock
> > > is not properly gated when the clock configuration is changed.  
> > 
> > In my case (Linux boot on i.MX6ULL), I recognized that on the 3rd call of
> > gpmi_nfc_apply_timings(), the rate of r->clock[0] is changed 
> > 
> > - from: 22 MHz (CS2CDR::ENFC_CLK_PRED=6 and CS2CDR::ENFC_CLK_PODF=3)
> > - to:  100 MHz (CS2CDR::ENFC_CLK_PRED=4 and CS2CDR::ENFC_CLK_PODF=1)
> > 
> > The proposal from from Han Xu  
> > > clk_disable_unprepare(r->clock[0]);
> > > clk_set_rate(r->clock[0], hw->clk_rate);
> > > clk_prepare_enable(r->clock[0]);  
> > disables only CCGR4::CG14 [RAWNAND_U_GPMI_BCH_INPUT_GPMI_IO_CLK_ENABLE]
> > during
> > the rate change. While this works very fine on my system, this probably
> > doesn't
> > fulfill the requirements in the errata description:
> >   
> > > For other occurrences in application code, the following procedure should
> > > be
> > > followed to change the clock configuration for the enfc_clk_root:
> > > 1) Gate (disable) the GPMI/BCH clocks in register CCM_CCGR4.
> > > 2) Gate (disable) the enfc_clk_root before changing the enfc_clk_root
> > > source
> > >    or dividers by clearing CCM_CCGR2[CG7] to 2’b00. This disables the
> > >    iomux_ipt_clk_io_clk.
> > > 3) Configure CCM_CS2CDR for the new clock source configuration.
> > > 4) Enable enfc_clk_root by setting CCM_CCGR2[CG7] to 2’b11. This enables
> > > the
> > >    iomux_ipt_clk_io_clk.
> > > 5) Enable the GPMI/BCH clocks in register CCM_CCGR4  
> > 
> > I got another solution from PHYTEC ([2], not lengthy tested yet), which
> > disables all GPMI/BCH clocks on CCGR4 (verified with a JTAG debugger):
> > - CCGR4::CG15  [RAWNAND_U_GPMI_INPUT_APB_CLK_ENABLE]
> > - CCGR4::CG14  [RAWNAND_U_GPMI_BCH_INPUT_GPMI_IO_CLK_ENABLE]
> > - CCGR4::CG13  [RAWNAND_U_GPMI_BCH_INPUT_BCH_CLK_ENABLE]
> > - CCGR4::CG12  [RAWNAND_U_BCH_INPUT_APB_CLK_ENABLE]
> > - CCGR4::CG6   [PL301_MX6QPER1_BCHCLK_ENABLE]
> > 
> > CCM_CCGR2[CG7] is used for IOMUX_IPT_CLK_IO_ENABLE on i.MX6ULL, so step 2.
> > seems not to apply here. Actually I don't know how to gate ENFC_CLK_ROOT.
> > 
> > I will cyclic test the solution from PHYTEC over the weekend.
> > 
> > @Han Xu: Should I prefer the solution from PHYTEC?
> > @Stefan Riedmueller: Are you willing to commit this upstream?  
> 
> Yes sure, I can prepare a patch beginning of next week.
> BTW, we have seen these DMA timeout issues on the i.MX6 SOCs as well. So this
> fix is not only for the i.MX 6ULL.

Could it be possible to quantify the extra time spent in
disabling/re-enabling clocks just for the record? So far this driver
only supports a single chip and thus frequency changes do not happen
frequently (a couple times at boot) but if someday we introduce support
for several chips it might become very impacting. 

Thanks,
Miquèl

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-08 12:27             ` Miquel Raynal
@ 2021-10-08 13:11               ` Christian Eggers
  2021-10-08 13:29                 ` Miquel Raynal
  2021-10-08 13:13               ` Christian Eggers
  1 sibling, 1 reply; 85+ messages in thread
From: Christian Eggers @ 2021-10-08 13:11 UTC (permalink / raw)
  To: Stefan Riedmüller, Miquel Raynal
  Cc: s.hauer, han.xu, michael, Christian Hemp, gerg, linux-mtd

On Friday, 8 October 2021, 11:55:56 CEST, Christian Eggers wrote:

> I got another solution from PHYTEC ([2], not lengthy tested yet), which
> disables all GPMI/BCH clocks on CCGR4

> -static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> +static int gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> 
>  {
>  
>  	struct gpmi_nfc_hardware_timing *hw = &this->hw;
>  	struct resources *r = &this->resources;
>  	void __iomem *gpmi_regs = r->gpmi_regs;
>  	unsigned int dll_wait_time_us;
> 
> +	int ret;
> 
> +	ret = __gpmi_enable_clk(this, false);
> +	if (ret)
> +		return ret;
> 
>  	clk_set_rate(r->clock[0], hw->clk_rate);
> 
> +	ret = __gpmi_enable_clk(this, true);
> +	if (ret)
> +		return ret;
> 
>  	writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
>  	writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);


I think that this is also required for the first call to clk_set_rate() in
gpmi_get_clks(). From the kernel's point of view, the clocks are not enabled
yet, so no "guard" is required. Putting the same guard here will actually give
a warning at runtime that I am trying to disable a clock which is not enabled.
But on my system, all clock gates are enabled by the bootloader (barebox)
and therefore the glitch could also happen here.

If setting the clock to a "default" rate is really required (on my system, the
clock is switched from 99 MHz to 22 MHz, and back to 99 MHz on a later call...),
I suggest moving this call to gpmi_nand_probe() (below __gpmi_enable_clock())
and guard it. The result would look like:

...
	ret = acquire_resources(this);
	if (ret)
		goto exit_acquire_resources;

	ret = __gpmi_enable_clk(this, true);
	if (ret)
		goto exit_acquire_resources;

	if (GPMI_IS_MX6(this)) {
		/*
		 * Set the default value for the gpmi clock.
		 *
		 * If you want to use the ONFI nand which is in the
		 * Synchronous Mode, you should change the clock as you need.
		 */
		__gpmi_enable_clk(this, false);
		clk_set_rate(this->resources.clock[0], 22000000);
		__gpmi_enable_clk(this, true);
	}

	pm_runtime_set_autosuspend_delay(&pdev->dev, 500);
...

It looks a little bit useless to enable the clocks and immediately disable
them. But probably this is the only way to make sure that clocks enabled by
the bootloader are certainly off.

regards
Christian




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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-08 12:27             ` Miquel Raynal
  2021-10-08 13:11               ` Christian Eggers
@ 2021-10-08 13:13               ` Christian Eggers
  2021-10-08 13:30                 ` Miquel Raynal
  1 sibling, 1 reply; 85+ messages in thread
From: Christian Eggers @ 2021-10-08 13:13 UTC (permalink / raw)
  To: Stefan Riedmüller, Miquel Raynal
  Cc: s.hauer, han.xu, michael, Christian Hemp, gerg, linux-mtd

On Friday, 8 October 2021, 14:27:24 CEST, Miquel Raynal wrote:
> Hello,
> 
> Could it be possible to quantify the extra time spent in
> disabling/re-enabling clocks just for the record? So far this driver
> only supports a single chip and thus frequency changes do not happen
> frequently (a couple times at boot) but if someday we introduce support
> for several chips it might become very impacting. 
> 
> Thanks,
> Miquèl
> 


ktime_t start = ktime_get(), duration;
__gpmi_enable_clk(this, false);
clk_set_rate(r->clock[0], hw->clk_rate);
__gpmi_enable_clk(this, true);
duration = ktime_get() - start;
printk(KERN_ERR "%s() duration = %lld ns\n", __func__, ktime_to_ns(duration));

--> 

gpmi_nfc_apply_timings() duration = 39250 ns
...
nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc
nand: Micron MT29F4G08ABADAH4
nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
gpmi_nfc_apply_timings() duration = 36750 ns
gpmi_nfc_apply_timings() duration = 170750 ns

On i.MX6ULL @ 792MHz this takes less than 250 us.

regards
Christian




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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-08 13:11               ` Christian Eggers
@ 2021-10-08 13:29                 ` Miquel Raynal
  2021-10-08 13:36                   ` Miquel Raynal
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel Raynal @ 2021-10-08 13:29 UTC (permalink / raw)
  To: Christian Eggers
  Cc: Stefan Riedmüller, s.hauer, han.xu, michael, Christian Hemp,
	gerg, linux-mtd

Hi Christian,

ceggers@arri.de wrote on Fri, 8 Oct 2021 15:11:59 +0200:

> On Friday, 8 October 2021, 11:55:56 CEST, Christian Eggers wrote:
> 
> > I got another solution from PHYTEC ([2], not lengthy tested yet), which
> > disables all GPMI/BCH clocks on CCGR4  
> 
> > -static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > +static int gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > 
> >  {
> >  
> >  	struct gpmi_nfc_hardware_timing *hw = &this->hw;
> >  	struct resources *r = &this->resources;
> >  	void __iomem *gpmi_regs = r->gpmi_regs;
> >  	unsigned int dll_wait_time_us;
> > 
> > +	int ret;
> > 
> > +	ret = __gpmi_enable_clk(this, false);
> > +	if (ret)
> > +		return ret;
> > 
> >  	clk_set_rate(r->clock[0], hw->clk_rate);
> > 
> > +	ret = __gpmi_enable_clk(this, true);
> > +	if (ret)
> > +		return ret;
> > 
> >  	writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
> >  	writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);  
> 
> 
> I think that this is also required for the first call to clk_set_rate() in
> gpmi_get_clks(). From the kernel's point of view, the clocks are not enabled
> yet, so no "guard" is required. Putting the same guard here will actually give
> a warning at runtime that I am trying to disable a clock which is not enabled.
> But on my system, all clock gates are enabled by the bootloader (barebox)
> and therefore the glitch could also happen here.
> 
> If setting the clock to a "default" rate is really required (on my system, the
> clock is switched from 99 MHz to 22 MHz, and back to 99 MHz on a later call...),
> I suggest moving this call to gpmi_nand_probe() (below __gpmi_enable_clock())
> and guard it. The result would look like:
> 
> ...
> 	ret = acquire_resources(this);
> 	if (ret)
> 		goto exit_acquire_resources;
> 
> 	ret = __gpmi_enable_clk(this, true);
> 	if (ret)
> 		goto exit_acquire_resources;
> 
> 	if (GPMI_IS_MX6(this)) {
> 		/*
> 		 * Set the default value for the gpmi clock.
> 		 *
> 		 * If you want to use the ONFI nand which is in the
> 		 * Synchronous Mode, you should change the clock as you need.
> 		 */
> 		__gpmi_enable_clk(this, false);
> 		clk_set_rate(this->resources.clock[0], 22000000);
> 		__gpmi_enable_clk(this, true);
> 	}
> 
> 	pm_runtime_set_autosuspend_delay(&pdev->dev, 500);

If this clock (as I understand) does not prevent us to access the
registers but only feeds the external NAND bus part, then there is no
need to enable it in the probe, just acquiring it will be enough.

Then, the first call for an IO operation with ->must_apply_timings
should:

	if (imx6)
		disable_clk();

	clk_set_rate();

	if (imx6)
		enable_clk();

I believe this should cover it all.

> ...
> 
> It looks a little bit useless to enable the clocks and immediately disable
> them. But probably this is the only way to make sure that clocks enabled by
> the bootloader are certainly off.
> 
> regards
> Christian
> 
> 
> 


Thanks,
Miquèl

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-08 13:13               ` Christian Eggers
@ 2021-10-08 13:30                 ` Miquel Raynal
  0 siblings, 0 replies; 85+ messages in thread
From: Miquel Raynal @ 2021-10-08 13:30 UTC (permalink / raw)
  To: Christian Eggers
  Cc: Stefan Riedmüller, s.hauer, han.xu, michael, Christian Hemp,
	gerg, linux-mtd

Hi Christian,

ceggers@arri.de wrote on Fri, 8 Oct 2021 15:13:17 +0200:

> On Friday, 8 October 2021, 14:27:24 CEST, Miquel Raynal wrote:
> > Hello,
> > 
> > Could it be possible to quantify the extra time spent in
> > disabling/re-enabling clocks just for the record? So far this driver
> > only supports a single chip and thus frequency changes do not happen
> > frequently (a couple times at boot) but if someday we introduce support
> > for several chips it might become very impacting. 
> > 
> > Thanks,
> > Miquèl
> >   
> 
> 
> ktime_t start = ktime_get(), duration;
> __gpmi_enable_clk(this, false);
> clk_set_rate(r->clock[0], hw->clk_rate);
> __gpmi_enable_clk(this, true);
> duration = ktime_get() - start;
> printk(KERN_ERR "%s() duration = %lld ns\n", __func__, ktime_to_ns(duration));
> 
> -->   
> 
> gpmi_nfc_apply_timings() duration = 39250 ns
> ...
> nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xdc
> nand: Micron MT29F4G08ABADAH4
> nand: 512 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
> gpmi_nfc_apply_timings() duration = 36750 ns
> gpmi_nfc_apply_timings() duration = 170750 ns
> 
> On i.MX6ULL @ 792MHz this takes less than 250 us.

Ok thanks for the feedback. This is not negligible if we start
switching between chips with different frequencies quite regularly.

Thanks,
Miquèl

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-08 13:29                 ` Miquel Raynal
@ 2021-10-08 13:36                   ` Miquel Raynal
  2021-10-08 13:49                     ` Christian Eggers
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel Raynal @ 2021-10-08 13:36 UTC (permalink / raw)
  To: Christian Eggers
  Cc: Stefan Riedmüller, s.hauer, han.xu, michael, Christian Hemp,
	gerg, linux-mtd


miquel.raynal@bootlin.com wrote on Fri, 8 Oct 2021 15:29:05 +0200:

> Hi Christian,
> 
> ceggers@arri.de wrote on Fri, 8 Oct 2021 15:11:59 +0200:
> 
> > On Friday, 8 October 2021, 11:55:56 CEST, Christian Eggers wrote:
> >   
> > > I got another solution from PHYTEC ([2], not lengthy tested yet), which
> > > disables all GPMI/BCH clocks on CCGR4    
> >   
> > > -static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > +static int gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > 
> > >  {
> > >  
> > >  	struct gpmi_nfc_hardware_timing *hw = &this->hw;
> > >  	struct resources *r = &this->resources;
> > >  	void __iomem *gpmi_regs = r->gpmi_regs;
> > >  	unsigned int dll_wait_time_us;
> > > 
> > > +	int ret;
> > > 
> > > +	ret = __gpmi_enable_clk(this, false);
> > > +	if (ret)
> > > +		return ret;
> > > 
> > >  	clk_set_rate(r->clock[0], hw->clk_rate);
> > > 
> > > +	ret = __gpmi_enable_clk(this, true);
> > > +	if (ret)
> > > +		return ret;
> > > 
> > >  	writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
> > >  	writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);    
> > 
> > 
> > I think that this is also required for the first call to clk_set_rate() in
> > gpmi_get_clks(). From the kernel's point of view, the clocks are not enabled
> > yet, so no "guard" is required. Putting the same guard here will actually give
> > a warning at runtime that I am trying to disable a clock which is not enabled.
> > But on my system, all clock gates are enabled by the bootloader (barebox)
> > and therefore the glitch could also happen here.
> > 
> > If setting the clock to a "default" rate is really required (on my system, the
> > clock is switched from 99 MHz to 22 MHz, and back to 99 MHz on a later call...),
> > I suggest moving this call to gpmi_nand_probe() (below __gpmi_enable_clock())
> > and guard it. The result would look like:
> > 
> > ...
> > 	ret = acquire_resources(this);
> > 	if (ret)
> > 		goto exit_acquire_resources;
> > 
> > 	ret = __gpmi_enable_clk(this, true);
> > 	if (ret)
> > 		goto exit_acquire_resources;
> > 
> > 	if (GPMI_IS_MX6(this)) {
> > 		/*
> > 		 * Set the default value for the gpmi clock.
> > 		 *
> > 		 * If you want to use the ONFI nand which is in the
> > 		 * Synchronous Mode, you should change the clock as you need.
> > 		 */
> > 		__gpmi_enable_clk(this, false);
> > 		clk_set_rate(this->resources.clock[0], 22000000);
> > 		__gpmi_enable_clk(this, true);
> > 	}
> > 
> > 	pm_runtime_set_autosuspend_delay(&pdev->dev, 500);  
> 
> If this clock (as I understand) does not prevent us to access the
> registers but only feeds the external NAND bus part, then there is no
> need to enable it in the probe, just acquiring it will be enough.
> Then, the first call for an IO operation with ->must_apply_timings
> should:
> 
> 	if (imx6)
> 		disable_clk();
> 
> 	clk_set_rate();
> 
> 	if (imx6)
> 		enable_clk();

Actually we should ensure clks are enabled in the !imx6 case anyway,
but this is needed only once so either we keep enabling the clock in
the probe or we check here if the clk has already been enabled or not.

Cheers,
Miquèl

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-08 13:36                   ` Miquel Raynal
@ 2021-10-08 13:49                     ` Christian Eggers
  2021-10-08 16:07                       ` Miquel Raynal
  0 siblings, 1 reply; 85+ messages in thread
From: Christian Eggers @ 2021-10-08 13:49 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: Stefan Riedmüller, s.hauer, han.xu, michael, Christian Hemp,
	gerg, linux-mtd

On Friday, 8 October 2021, 15:36:31 CEST, Miquel Raynal wrote:
> 
> miquel.raynal@bootlin.com wrote on Fri, 8 Oct 2021 15:29:05 +0200:
> 
> > 
> > If this clock (as I understand) does not prevent us to access the
> > registers but only feeds the external NAND bus part, then there is no
> > need to enable it in the probe, just acquiring it will be enough.

clocks[0] is "gpmi_io" which sounds more like i/o than registers. So lets
try to remove the initial call to clk_set_rate().

> > Then, the first call for an IO operation with ->must_apply_timings
> > should:
> > 
> > 	if (imx6)
> > 		disable_clk();
> > 
> > 	clk_set_rate();
> > 
> > 	if (imx6)
> > 		enable_clk();

Do you think that the need for avoiding clock glitches is i.MX6 specific?
The errata I mentioned is specific for the bootloader software, but (I think)
the requirement for switching off the clocks gates prior changing the dividers
may apply also for other series.

> Actually we should ensure clks are enabled in the !imx6 case anyway,
> but this is needed only once so either we keep enabling the clock in
> the probe or we check here if the clk has already been enabled or not.
The clocks are already enabled (and kept on) in probe. The initial call to
clk_set_rate() is just above this (but the clocks are not disabled at this
stage as all gates have been enabled by the boot loader).

regards
Christian




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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-08 13:49                     ` Christian Eggers
@ 2021-10-08 16:07                       ` Miquel Raynal
  2021-10-09  5:53                         ` Michael Nazzareno Trimarchi
  2021-10-09  6:26                         ` GPMI iMX6ull timeout on DMA Christian Eggers
  0 siblings, 2 replies; 85+ messages in thread
From: Miquel Raynal @ 2021-10-08 16:07 UTC (permalink / raw)
  To: Christian Eggers
  Cc: Stefan Riedmüller, s.hauer, han.xu, michael, Christian Hemp,
	gerg, linux-mtd

Hi Christian,

ceggers@arri.de wrote on Fri, 8 Oct 2021 15:49:21 +0200:

> On Friday, 8 October 2021, 15:36:31 CEST, Miquel Raynal wrote:
> > 
> > miquel.raynal@bootlin.com wrote on Fri, 8 Oct 2021 15:29:05 +0200:
> >   
> > > 
> > > If this clock (as I understand) does not prevent us to access the
> > > registers but only feeds the external NAND bus part, then there is no
> > > need to enable it in the probe, just acquiring it will be enough.  
> 
> clocks[0] is "gpmi_io" which sounds more like i/o than registers. So lets
> try to remove the initial call to clk_set_rate().
> 
> > > Then, the first call for an IO operation with ->must_apply_timings
> > > should:
> > > 
> > > 	if (imx6)
> > > 		disable_clk();
> > > 
> > > 	clk_set_rate();
> > > 
> > > 	if (imx6)
> > > 		enable_clk();  
> 
> Do you think that the need for avoiding clock glitches is i.MX6 specific?
> The errata I mentioned is specific for the bootloader software, but (I think)
> the requirement for switching off the clocks gates prior changing the dividers
> may apply also for other series.

I honestly don't know, perhaps Han have more details about it. If you
think it's a wider issue, then we can just do the disable/enable step
without any further checks.

> > Actually we should ensure clks are enabled in the !imx6 case anyway,
> > but this is needed only once so either we keep enabling the clock in
> > the probe or we check here if the clk has already been enabled or not.  
> The clocks are already enabled (and kept on) in probe. The initial call to
> clk_set_rate() is just above this (but the clocks are not disabled at this
> stage as all gates have been enabled by the boot loader).

The IO clock should be enabled and set to a particular rate the first
time the die is selected to perform a NAND operation, or when we switch
from one device to the other (this does not apply to the GPMI driver
for now). So we can drop the enable/set_rate call in the probe if the
assumption that this clock only feeds the external bus is right.

Thanks,
Miquèl

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-08 16:07                       ` Miquel Raynal
@ 2021-10-09  5:53                         ` Michael Nazzareno Trimarchi
  2021-10-11  6:46                           ` Miquel Raynal
  2021-10-09  6:26                         ` GPMI iMX6ull timeout on DMA Christian Eggers
  1 sibling, 1 reply; 85+ messages in thread
From: Michael Nazzareno Trimarchi @ 2021-10-09  5:53 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: Christian Eggers, Stefan Riedmüller, s.hauer, han.xu,
	Christian Hemp, gerg, linux-mtd

Hi

On Fri, Oct 8, 2021 at 6:07 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Christian,
>
> ceggers@arri.de wrote on Fri, 8 Oct 2021 15:49:21 +0200:
>
> > On Friday, 8 October 2021, 15:36:31 CEST, Miquel Raynal wrote:
> > >
> > > miquel.raynal@bootlin.com wrote on Fri, 8 Oct 2021 15:29:05 +0200:
> > >
> > > >
> > > > If this clock (as I understand) does not prevent us to access the
> > > > registers but only feeds the external NAND bus part, then there is no
> > > > need to enable it in the probe, just acquiring it will be enough.
> >
> > clocks[0] is "gpmi_io" which sounds more like i/o than registers. So lets
> > try to remove the initial call to clk_set_rate().
> >
> > > > Then, the first call for an IO operation with ->must_apply_timings
> > > > should:
> > > >
> > > >   if (imx6)
> > > >           disable_clk();
> > > >
> > > >   clk_set_rate();
> > > >
> > > >   if (imx6)
> > > >           enable_clk();
> >
> > Do you think that the need for avoiding clock glitches is i.MX6 specific?
> > The errata I mentioned is specific for the bootloader software, but (I think)
> > the requirement for switching off the clocks gates prior changing the dividers
> > may apply also for other series.
>
> I honestly don't know, perhaps Han have more details about it. If you
> think it's a wider issue, then we can just do the disable/enable step
> without any further checks.
>

Still don't explain why it was working on the old driver. The glitch
was already there,
so just a delay can do the trick. For imx28 we need to reparent to a
different clock the
nand driver in order to get the frequency we want in EDO mode. I'm
still thinking that
set the frequency without without get back and understand if in that
edo mode is valid
is still a bug.

Michael

> > > Actually we should ensure clks are enabled in the !imx6 case anyway,
> > > but this is needed only once so either we keep enabling the clock in
> > > the probe or we check here if the clk has already been enabled or not.
> > The clocks are already enabled (and kept on) in probe. The initial call to
> > clk_set_rate() is just above this (but the clocks are not disabled at this
> > stage as all gates have been enabled by the boot loader).
>
> The IO clock should be enabled and set to a particular rate the first
> time the die is selected to perform a NAND operation, or when we switch
> from one device to the other (this does not apply to the GPMI driver
> for now). So we can drop the enable/set_rate call in the probe if the
> assumption that this clock only feeds the external bus is right.
>
> Thanks,
> Miquèl



-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael@amarulasolutions.com
__________________________________

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info@amarulasolutions.com
www.amarulasolutions.com

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-08 16:07                       ` Miquel Raynal
  2021-10-09  5:53                         ` Michael Nazzareno Trimarchi
@ 2021-10-09  6:26                         ` Christian Eggers
  2021-10-13  6:15                           ` Christian Eggers
  1 sibling, 1 reply; 85+ messages in thread
From: Christian Eggers @ 2021-10-09  6:26 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: Stefan Riedmüller, s.hauer, han.xu, michael, Christian Hemp,
	gerg, linux-mtd

On Friday, 8 October 2021, 18:07:52 CEST, Miquel Raynal wrote:
> Hi Christian,
> 
> ceggers@arri.de wrote on Fri, 8 Oct 2021 15:49:21 +0200:
> 
> > On Friday, 8 October 2021, 15:36:31 CEST, Miquel Raynal wrote:
> > > 
> > > miquel.raynal@bootlin.com wrote on Fri, 8 Oct 2021 15:29:05 +0200:
> > >   
> > > > 
> > > > If this clock (as I understand) does not prevent us to access the
> > > > registers but only feeds the external NAND bus part, then there is no
> > > > need to enable it in the probe, just acquiring it will be enough.  
> > 
> > clocks[0] is "gpmi_io" which sounds more like i/o than registers. So lets
> > try to remove the initial call to clk_set_rate().

From the GPMI description (i.MX6 ULL):
> [GPMI] Registers are clocked on the HCLK domain. The I/O and pin timing are 
> clocked on a dedicated GPMICLK domain. GPMICLK can be set to maximize I/O
> performance.

Additionally, figure 17-1 in IMX6ULLRM.pdf shows that both (BCH and GPMI)
registers are connected to APBH.

I checked this with the debugger: For accessing the BCH and GPMI
registers, only CCGR0::CG2 [APBHDMA_HCLK_ENABLE] is required. This bit is
enabled in mxs_dma_alloc_chan_resources():

-000|mxs_dma_alloc_chan_resources(chan = 0xC2090154)
-001|__refcount_inc_not_zero(inline)
-001|refcount_inc_not_zero(inline)
-001|kref_get_unless_zero(inline)
-001|dma_chan_get(:chan = 0xC2090154)
-002|find_candidate(device = 0xC2090050, :mask = 0xC209BD38, :fn = 0xC0254679, :fn_param = 0xC209BD3C)
-003|__dma_request_channel(:mask = 0xC209BD38, :fn = 0xC0254679, :fn_param = 0xC209BD3C, np = 0xC7EEB0B0)
-004|mxs_dma_xlate(:dma_spec = 0xC209BD60, :ofdma = 0xC2264840)
-005|of_dma_request_slave_channel(np = 0xC7EEB2B4, name = 0xC04F923A -> "rx-tx")
-006|dma_request_chan(dev = 0xC2182410, :name = 0xC04F923A -> "rx-tx")
-007|acquire_dma_channels(inline)
-007|acquire_resources(:this = 0xC200F840)
-008|gpmi_nand_probe(:pdev = 0xC2182400)

The root clock is BCH_CLK_ROOT. It doesn't depend on ENFC_PRED or ENFC_PODF
(the dividers which are actually set in clk_set_rate(r->clock[0], 22000000)).

--> clk_set_rate(r->clock[0], 22000000) is not required for accessing the
registers. I removed the call entirely and everything works fine.

> > 
> > > > Then, the first call for an IO operation with ->must_apply_timings
> > > > should:
> > > > 
> > > > 	if (imx6)
> > > > 		disable_clk();
> > > > 
> > > > 	clk_set_rate();
> > > > 
> > > > 	if (imx6)
> > > > 		enable_clk();  
> > 
> > Do you think that the need for avoiding clock glitches is i.MX6 specific?
> > The errata I mentioned is specific for the bootloader software, but (I think)
> > the requirement for switching off the clocks gates prior changing the dividers
> > may apply also for other series.
> 
> I honestly don't know, perhaps Han have more details about it. If you
> think it's a wider issue, then we can just do the disable/enable step
> without any further checks.
I also don't know. I can not find the required sequence in the reference manual
(only in the errata sheet), so I cannot compare with other series. For best
performance we can start with checking for GPMI_IS_MX6Q(x) and extend it later
if this issue comes up on other devices.

I sent a question for this on NXP community:
https://community.nxp.com/t5/i-MX-Processors/ERR007117-Which-i-MX-devices-require-gating-the-clocks-when/m-p/1353018

> > > Actually we should ensure clks are enabled in the !imx6 case anyway,
> > > but this is needed only once so either we keep enabling the clock in
> > > the probe or we check here if the clk has already been enabled or not.  
> > The clocks are already enabled (and kept on) in probe. The initial call to
> > clk_set_rate() is just above this (but the clocks are not disabled at this
> > stage as all gates have been enabled by the boot loader).
> 
> The IO clock should be enabled and set to a particular rate the first
> time the die is selected to perform a NAND operation, or when we switch
> from one device to the other (this does not apply to the GPMI driver
> for now). So we can drop the enable/set_rate call in the probe if the
> assumption that this clock only feeds the external bus is right.

I think that this assumption is right.

regards
Christian




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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-08 12:08           ` Stefan Riedmüller
  2021-10-08 12:27             ` Miquel Raynal
@ 2021-10-09  6:33             ` Christian Eggers
  1 sibling, 0 replies; 85+ messages in thread
From: Christian Eggers @ 2021-10-09  6:33 UTC (permalink / raw)
  To: Stefan Riedmüller
  Cc: s.hauer, han.xu, michael, Christian Hemp, gerg, miquel.raynal, linux-mtd

On Friday, 8 October 2021, 14:08:01 CEST, Stefan Riedmüller wrote:
> On Fri, 2021-10-08 at 11:55 +0200, Christian Eggers wrote:
> > @Stefan Riedmueller: Are you willing to commit this upstream?
> 
> Yes sure, I can prepare a patch beginning of next week.
> BTW, we have seen these DMA timeout issues on the i.MX6 SOCs as well. So this
> fix is not only for the i.MX 6ULL.

Current status:

- If have entirely removed the following part:
	if (GPMI_IS_MX6(this))
		/*
		 * Set the default value for the gpmi clock.
		 *
		 * If you want to use the ONFI nand which is in the
		 * Synchronous Mode, you should change the clock as you need.
		 */
		clk_set_rate(r->clock[0], 22000000);

- I applied your patch:
https://git.phytec.de/linux-mainline/commit/?h=v5.10.48-phy&id=866939ea8110764d9c12af960d746e2f7f5debe3


Last night I made a cycle test with a phyCORE i.MX6ULL. Over 1700 cycles were successful!

regards
Christian




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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-09  5:53                         ` Michael Nazzareno Trimarchi
@ 2021-10-11  6:46                           ` Miquel Raynal
  2021-10-12  9:02                             ` [RFC PATCH 1/2] mtd: rawnand: gpmi: Remove explicit default gpmi clock setting for i.MX6 Stefan Riedmueller
  0 siblings, 1 reply; 85+ messages in thread
From: Miquel Raynal @ 2021-10-11  6:46 UTC (permalink / raw)
  To: Michael Nazzareno Trimarchi
  Cc: Christian Eggers, Stefan Riedmüller, s.hauer, han.xu,
	Christian Hemp, gerg, linux-mtd

Hi Michael,

michael@amarulasolutions.com wrote on Sat, 9 Oct 2021 07:53:26 +0200:

> Hi
> 
> On Fri, Oct 8, 2021 at 6:07 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Christian,
> >
> > ceggers@arri.de wrote on Fri, 8 Oct 2021 15:49:21 +0200:
> >  
> > > On Friday, 8 October 2021, 15:36:31 CEST, Miquel Raynal wrote:  
> > > >
> > > > miquel.raynal@bootlin.com wrote on Fri, 8 Oct 2021 15:29:05 +0200:
> > > >  
> > > > >
> > > > > If this clock (as I understand) does not prevent us to access the
> > > > > registers but only feeds the external NAND bus part, then there is no
> > > > > need to enable it in the probe, just acquiring it will be enough.  
> > >
> > > clocks[0] is "gpmi_io" which sounds more like i/o than registers. So lets
> > > try to remove the initial call to clk_set_rate().
> > >  
> > > > > Then, the first call for an IO operation with ->must_apply_timings
> > > > > should:
> > > > >
> > > > >   if (imx6)
> > > > >           disable_clk();
> > > > >
> > > > >   clk_set_rate();
> > > > >
> > > > >   if (imx6)
> > > > >           enable_clk();  
> > >
> > > Do you think that the need for avoiding clock glitches is i.MX6 specific?
> > > The errata I mentioned is specific for the bootloader software, but (I think)
> > > the requirement for switching off the clocks gates prior changing the dividers
> > > may apply also for other series.  
> >
> > I honestly don't know, perhaps Han have more details about it. If you
> > think it's a wider issue, then we can just do the disable/enable step
> > without any further checks.
> >  
> 
> Still don't explain why it was working on the old driver. The glitch
> was already there,
> so just a delay can do the trick. For imx28 we need to reparent to a
> different clock the
> nand driver in order to get the frequency we want in EDO mode. I'm
> still thinking that
> set the frequency without without get back and understand if in that
> edo mode is valid
> is still a bug.

There are possibly two bugs here, I am also in favor of checking
that the received frequencies match what we expect, so please provide a
patch to also cover that situation.

Thanks,
Miquèl

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* [RFC PATCH 1/2] mtd: rawnand: gpmi: Remove explicit default gpmi clock setting for i.MX6
  2021-10-11  6:46                           ` Miquel Raynal
@ 2021-10-12  9:02                             ` Stefan Riedmueller
  2021-10-12  9:02                               ` [RFC PATCH 2/2] gpmi-nand: Add ERR007117 protection for nfc_apply_timings Stefan Riedmueller
  2021-10-13  6:00                               ` [RFC PATCH 1/2] mtd: rawnand: gpmi: Remove explicit default gpmi clock setting for i.MX6 Christian Eggers
  0 siblings, 2 replies; 85+ messages in thread
From: Stefan Riedmueller @ 2021-10-12  9:02 UTC (permalink / raw)
  To: Miquel Raynal, Christian Eggers, Michael Nazzareno Trimarchi,
	Greg Ungerer
  Cc: Stefan Riedmueller, Sascha Hauer, Han Xu, Christian Hemp,
	Boris Brezillon, linux-mtd

There is no need to explicitly set the default gpmi clock rate during
boot for the i.MX 6 since this is done during nand_detect anyway.

Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
---
 drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
index 4d08e4ab5c1b..a1f7000f033e 100644
--- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
@@ -1034,15 +1034,6 @@ static int gpmi_get_clks(struct gpmi_nand_data *this)
 		r->clock[i] = clk;
 	}
 
-	if (GPMI_IS_MX6(this))
-		/*
-		 * Set the default value for the gpmi clock.
-		 *
-		 * If you want to use the ONFI nand which is in the
-		 * Synchronous Mode, you should change the clock as you need.
-		 */
-		clk_set_rate(r->clock[0], 22000000);
-
 	return 0;
 
 err_clock:
-- 
2.25.1


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

^ permalink raw reply related	[flat|nested] 85+ messages in thread

* [RFC PATCH 2/2] gpmi-nand: Add ERR007117 protection for nfc_apply_timings
  2021-10-12  9:02                             ` [RFC PATCH 1/2] mtd: rawnand: gpmi: Remove explicit default gpmi clock setting for i.MX6 Stefan Riedmueller
@ 2021-10-12  9:02                               ` Stefan Riedmueller
  2021-10-13  5:01                                 ` Han Xu
  2021-10-13  6:10                                 ` Christian Eggers
  2021-10-13  6:00                               ` [RFC PATCH 1/2] mtd: rawnand: gpmi: Remove explicit default gpmi clock setting for i.MX6 Christian Eggers
  1 sibling, 2 replies; 85+ messages in thread
From: Stefan Riedmueller @ 2021-10-12  9:02 UTC (permalink / raw)
  To: Miquel Raynal, Christian Eggers, Michael Nazzareno Trimarchi,
	Greg Ungerer
  Cc: Stefan Riedmueller, Sascha Hauer, Han Xu, Christian Hemp,
	Boris Brezillon, linux-mtd

According to i.MX 6 erratum ERR007117 gpmi clocks need to be gated off
when doing a gpmi_io clk rate change. So gate the clocks off before
the rate change in nfc_apply_timings and ungate them again after the
change.

Otherwise this rate change can lead to an unresponsive GPMI core which
results in DMA timeouts and failed driver probe:

[    4.072318] gpmi-nand 112000.gpmi-nand: DMA timeout, last DMA
...
[    4.370355] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -110
...
[    4.375988] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
[    4.381524] gpmi-nand 112000.gpmi-nand: Error in ECC-based read: -22
[    4.387988] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
[    4.393535] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
...

Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
---
Hi,

I'm not sure about the error handling here, if it is actually neccessary.
So some feedback would be nice here.

Thanks,
Stefan
---
 drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
index a1f7000f033e..326c8a895f1f 100644
--- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
@@ -713,15 +713,28 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
 			      (use_half_period ? BM_GPMI_CTRL1_HALF_PERIOD : 0);
 }
 
-static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
+static int gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
 {
 	struct gpmi_nfc_hardware_timing *hw = &this->hw;
 	struct resources *r = &this->resources;
 	void __iomem *gpmi_regs = r->gpmi_regs;
 	unsigned int dll_wait_time_us;
+	int ret;
+
+	if (GPMI_IS_MX6Q(this)) {
+		ret = __gpmi_enable_clk(this, false);
+		if (ret)
+			return ret;
+	}
 
 	clk_set_rate(r->clock[0], hw->clk_rate);
 
+	if (GPMI_IS_MX6Q(this)) {
+		ret = __gpmi_enable_clk(this, true);
+		if (ret)
+			return ret;
+	}
+
 	writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
 	writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);
 
@@ -739,6 +752,8 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
 
 	/* Wait for the DLL to settle. */
 	udelay(dll_wait_time_us);
+
+	return 0;
 }
 
 static int gpmi_setup_interface(struct nand_chip *chip, int chipnr,
@@ -2271,7 +2286,9 @@ static int gpmi_nfc_exec_op(struct nand_chip *chip,
 	 */
 	if (this->hw.must_apply_timings) {
 		this->hw.must_apply_timings = false;
-		gpmi_nfc_apply_timings(this);
+		ret = gpmi_nfc_apply_timings(this);
+		if (ret)
+			return ret;
 	}
 
 	dev_dbg(this->dev, "%s: %d instructions\n", __func__, op->ninstrs);
-- 
2.25.1


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

^ permalink raw reply related	[flat|nested] 85+ messages in thread

* Re: [RFC PATCH 2/2] gpmi-nand: Add ERR007117 protection for nfc_apply_timings
  2021-10-12  9:02                               ` [RFC PATCH 2/2] gpmi-nand: Add ERR007117 protection for nfc_apply_timings Stefan Riedmueller
@ 2021-10-13  5:01                                 ` Han Xu
  2021-10-22  8:45                                   ` Stefan Riedmüller
  2021-10-13  6:10                                 ` Christian Eggers
  1 sibling, 1 reply; 85+ messages in thread
From: Han Xu @ 2021-10-13  5:01 UTC (permalink / raw)
  To: Stefan Riedmueller
  Cc: Miquel Raynal, Christian Eggers, Michael Nazzareno Trimarchi,
	Greg Ungerer, Sascha Hauer, Christian Hemp, Boris Brezillon,
	linux-mtd

On 21/10/12 11:02AM, Stefan Riedmueller wrote:
> According to i.MX 6 erratum ERR007117 gpmi clocks need to be gated off
> when doing a gpmi_io clk rate change. So gate the clocks off before
> the rate change in nfc_apply_timings and ungate them again after the
> change.
> 
> Otherwise this rate change can lead to an unresponsive GPMI core which
> results in DMA timeouts and failed driver probe:
> 
> [    4.072318] gpmi-nand 112000.gpmi-nand: DMA timeout, last DMA
> ...
> [    4.370355] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -110
> ...
> [    4.375988] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
> [    4.381524] gpmi-nand 112000.gpmi-nand: Error in ECC-based read: -22
> [    4.387988] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
> [    4.393535] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
> ...
> 
> Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
> ---
> Hi,
> 
> I'm not sure about the error handling here, if it is actually neccessary.
> So some feedback would be nice here.
> 
> Thanks,
> Stefan
> ---
>  drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 21 +++++++++++++++++++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> index a1f7000f033e..326c8a895f1f 100644
> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> @@ -713,15 +713,28 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
>  			      (use_half_period ? BM_GPMI_CTRL1_HALF_PERIOD : 0);
>  }
>  
> -static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> +static int gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>  {
>  	struct gpmi_nfc_hardware_timing *hw = &this->hw;
>  	struct resources *r = &this->resources;
>  	void __iomem *gpmi_regs = r->gpmi_regs;
>  	unsigned int dll_wait_time_us;
> +	int ret;
> +
> +	if (GPMI_IS_MX6Q(this)) {

Not only for 6Q but for GPMI_IS_MX6

> +		ret = __gpmi_enable_clk(this, false);
> +		if (ret)
> +			return ret;
> +	}
>  
>  	clk_set_rate(r->clock[0], hw->clk_rate);
>  
> +	if (GPMI_IS_MX6Q(this)) {
> +		ret = __gpmi_enable_clk(this, true);
> +		if (ret)
> +			return ret;
> +	}
> +
>  	writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
>  	writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);
>  
> @@ -739,6 +752,8 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>  
>  	/* Wait for the DLL to settle. */
>  	udelay(dll_wait_time_us);
> +
> +	return 0;
>  }
>  
>  static int gpmi_setup_interface(struct nand_chip *chip, int chipnr,
> @@ -2271,7 +2286,9 @@ static int gpmi_nfc_exec_op(struct nand_chip *chip,
>  	 */
>  	if (this->hw.must_apply_timings) {
>  		this->hw.must_apply_timings = false;
> -		gpmi_nfc_apply_timings(this);
> +		ret = gpmi_nfc_apply_timings(this);
> +		if (ret)
> +			return ret;
>  	}
>  
>  	dev_dbg(this->dev, "%s: %d instructions\n", __func__, op->ninstrs);
> -- 
> 2.25.1
> 

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [RFC PATCH 1/2] mtd: rawnand: gpmi: Remove explicit default gpmi clock setting for i.MX6
  2021-10-12  9:02                             ` [RFC PATCH 1/2] mtd: rawnand: gpmi: Remove explicit default gpmi clock setting for i.MX6 Stefan Riedmueller
  2021-10-12  9:02                               ` [RFC PATCH 2/2] gpmi-nand: Add ERR007117 protection for nfc_apply_timings Stefan Riedmueller
@ 2021-10-13  6:00                               ` Christian Eggers
  1 sibling, 0 replies; 85+ messages in thread
From: Christian Eggers @ 2021-10-13  6:00 UTC (permalink / raw)
  To: Miquel Raynal, Michael Nazzareno Trimarchi, Greg Ungerer,
	Stefan Riedmueller
  Cc: Stefan Riedmueller, Sascha Hauer, Han Xu, Christian Hemp,
	Boris Brezillon, linux-mtd

On Tuesday, 12 October 2021, 11:02:23 CEST, Stefan Riedmueller wrote:
> There is no need to explicitly set the default gpmi clock rate during
> boot for the i.MX 6 since this is done during nand_detect anyway.
> 
> Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
> ---
>  drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 9 ---------
>  1 file changed, 9 deletions(-)
> 
> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> index 4d08e4ab5c1b..a1f7000f033e 100644
> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> @@ -1034,15 +1034,6 @@ static int gpmi_get_clks(struct gpmi_nand_data *this)
>  		r->clock[i] = clk;
>  	}
>  
> -	if (GPMI_IS_MX6(this))
> -		/*
> -		 * Set the default value for the gpmi clock.
> -		 *
> -		 * If you want to use the ONFI nand which is in the
> -		 * Synchronous Mode, you should change the clock as you need.
> -		 */
> -		clk_set_rate(r->clock[0], 22000000);
> -
>  	return 0;
>  
>  err_clock:
> 

Tested-by: Christian Eggers <ceggers@arri.de>  # on i.MX6ULL with MT29F4G08ABADAH4
Cc: stable@vger.kernel.org




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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [RFC PATCH 2/2] gpmi-nand: Add ERR007117 protection for nfc_apply_timings
  2021-10-12  9:02                               ` [RFC PATCH 2/2] gpmi-nand: Add ERR007117 protection for nfc_apply_timings Stefan Riedmueller
  2021-10-13  5:01                                 ` Han Xu
@ 2021-10-13  6:10                                 ` Christian Eggers
  1 sibling, 0 replies; 85+ messages in thread
From: Christian Eggers @ 2021-10-13  6:10 UTC (permalink / raw)
  To: Miquel Raynal, Michael Nazzareno Trimarchi, Greg Ungerer,
	Stefan Riedmueller
  Cc: Stefan Riedmueller, Sascha Hauer, Han Xu, Christian Hemp,
	Boris Brezillon, linux-mtd

On Tuesday, 12 October 2021, 11:02:24 CEST, Stefan Riedmueller wrote:
> According to i.MX 6 erratum ERR007117 gpmi clocks need to be gated off
> when doing a gpmi_io clk rate change. So gate the clocks off before
> the rate change in nfc_apply_timings and ungate them again after the
> change.
> 
> Otherwise this rate change can lead to an unresponsive GPMI core which
> results in DMA timeouts and failed driver probe:
> 
> [    4.072318] gpmi-nand 112000.gpmi-nand: DMA timeout, last DMA
> ...
> [    4.370355] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -110
> ...
> [    4.375988] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
> [    4.381524] gpmi-nand 112000.gpmi-nand: Error in ECC-based read: -22
> [    4.387988] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
> [    4.393535] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
> ...
> 
> Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
> ---
> Hi,
Hi Stefan,

thanks for providing the patches! I am suffering from this problem for some
time now and I am happy to get this fixed!

> 
> I'm not sure about the error handling here, if it is actually neccessary.
> So some feedback would be nice here.

IMHO errors should always be handled.

> 
> Thanks,
> Stefan
> ---
>  drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 21 +++++++++++++++++++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> index a1f7000f033e..326c8a895f1f 100644
> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> @@ -713,15 +713,28 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
>  			      (use_half_period ? BM_GPMI_CTRL1_HALF_PERIOD : 0);
>  }
>  
> -static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> +static int gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>  {
>  	struct gpmi_nfc_hardware_timing *hw = &this->hw;
>  	struct resources *r = &this->resources;
>  	void __iomem *gpmi_regs = r->gpmi_regs;
>  	unsigned int dll_wait_time_us;
> +	int ret;
> +
> +	if (GPMI_IS_MX6Q(this)) {
I would like to explicitly see i.MX6UL(L) here (in order to make clear that
not only Solo/Dual/Quad are affected):
#define GPMI_IS_MX6UL(x)		((x)->devdata->type == IS_MX6Q)
...
if (GPMI_IS_MX6Q(this) || GPMI_IS_MX6UL(this)) {

But if Han Xu is sure that also SoloX and i.MX7 are affected, GPMI_IS_MX6(x)
is fine for me. In this case I would like to explicitly mention this in the 
commit message, so that nobody will change this later because ERR007117
exists only for Solo/Dual/Quad.

> +		ret = __gpmi_enable_clk(this, false);
> +		if (ret)
> +			return ret;
> +	}
>  
>  	clk_set_rate(r->clock[0], hw->clk_rate);
>  
> +	if (GPMI_IS_MX6Q(this)) {
> +		ret = __gpmi_enable_clk(this, true);
> +		if (ret)
> +			return ret;
> +	}
> +
>  	writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
>  	writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);
>  
> @@ -739,6 +752,8 @@ static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
>  
>  	/* Wait for the DLL to settle. */
>  	udelay(dll_wait_time_us);
> +
> +	return 0;
>  }
>  
>  static int gpmi_setup_interface(struct nand_chip *chip, int chipnr,
> @@ -2271,7 +2286,9 @@ static int gpmi_nfc_exec_op(struct nand_chip *chip,
>  	 */
>  	if (this->hw.must_apply_timings) {
>  		this->hw.must_apply_timings = false;
> -		gpmi_nfc_apply_timings(this);
> +		ret = gpmi_nfc_apply_timings(this);
> +		if (ret)
> +			return ret;
>  	}
>  
>  	dev_dbg(this->dev, "%s: %d instructions\n", __func__, op->ninstrs);
> 

Tested-by: Christian Eggers <ceggers@arri.de>  # on i.MX6ULL with MT29F4G08ABADAH4
Cc: stable@vger.kernel.org




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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-09  6:26                         ` GPMI iMX6ull timeout on DMA Christian Eggers
@ 2021-10-13  6:15                           ` Christian Eggers
  0 siblings, 0 replies; 85+ messages in thread
From: Christian Eggers @ 2021-10-13  6:15 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: Stefan Riedmüller, s.hauer, han.xu, michael, Christian Hemp,
	gerg, linux-mtd

On Saturday, 9 October 2021, 08:26:36 CEST, Christian Eggers wrote:
> > > Do you think that the need for avoiding clock glitches is i.MX6 specific?
> > > The errata I mentioned is specific for the bootloader software, but (I think)
> > > the requirement for switching off the clocks gates prior changing the dividers
> > > may apply also for other series.
> > 
> > I honestly don't know, perhaps Han have more details about it. If you
> > think it's a wider issue, then we can just do the disable/enable step
> > without any further checks.
> I also don't know. I can not find the required sequence in the reference manual
> (only in the errata sheet), so I cannot compare with other series. For best
> performance we can start with checking for GPMI_IS_MX6Q(x) and extend it later
> if this issue comes up on other devices.
> 
> I sent a question for this on NXP community:
> https://community.nxp.com/t5/i-MX-Processors/ERR007117-Which-i-MX-devices-require-gating-the-clocks-when/m-p/1353018
> 
> 1. Which i.MX models / series require this sequence?
> 2. Where can I find this sequence in the reference manuals (e.g. for i.MX6 ULL)?
> 3. How is CCM_CCGR2[CG7] (iomux_ipt_clk_io_clk) related to "gating enfc_clk_root"?

@Han Xu: Can you provide further information about this? Do you have contact to
the hardware developers?

regards
Christian




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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-02-01 15:14                                                         ` Miquel Raynal
  2021-02-01 15:17                                                           ` Michael Nazzareno Trimarchi
@ 2021-10-15 20:05                                                           ` Michael Trimarchi
  2021-10-15 20:12                                                             ` Michael Nazzareno Trimarchi
  2021-10-18  7:19                                                             ` Miquel Raynal
  1 sibling, 2 replies; 85+ messages in thread
From: Michael Trimarchi @ 2021-10-15 20:05 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: Greg Ungerer, Boris Brezillon, Sascha Hauer, Boris Brezillon, linux-mtd

Hi

On Mon, Feb 01, 2021 at 04:14:33PM +0100, Miquel Raynal wrote:
> Hi Michael,
> 
> Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> Mon, 1 Feb 2021 16:08:23 +0100:
> 
> > Hi
> > 
> > On Mon, Feb 1, 2021 at 3:32 PM Michael Nazzareno Trimarchi
> > <michael@amarulasolutions.com> wrote:
> > >
> > > Hi
> > >
> > > On Mon, Feb 1, 2021 at 3:13 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > >
> > > > Hi Michael,
> > > >
> > > > Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> > > > Sat, 30 Jan 2021 10:41:29 +0100:
> > > >  
> > > > > Hi Miquel
> > > > >
> > > > > commit f8e6ad14388067f91b26d044185d95623fbc9535
> > > > > Author: Michael Trimarchi <michael@amarulasolutions.com>
> > > > > Date:   Fri Jan 29 08:46:53 2021 +0100
> > > > >
> > > > >     mtd: nand: Calculate the clock before enable it
> > > > >
> > > > >     Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> > > > >     Change-Id: I79b0da39de0a9b32ea0b002fa200d7f44d4f8ce7
> > > > >
> > > > > diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > index 322a008290e5..0bca52b3bc8f 100644
> > > > > --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > @@ -377,6 +377,7 @@ static void gpmi_nfc_compute_timings(struct
> > > > > gpmi_nand_data *this,
> > > > >                                      const struct nand_sdr_timings *sdr)
> > > > >  {
> > > > >         struct gpmi_nfc_hardware_timing *hw = &this->hw;
> > > > > +       struct resources *r = &this->resources;
> > > > >         unsigned int dll_threshold_ps = this->devdata->max_chain_delay;
> > > > >         unsigned int period_ps, reference_period_ps;
> > > > >         unsigned int data_setup_cycles, data_hold_cycles, addr_setup_cycles;
> > > > > @@ -440,6 +441,8 @@ static void gpmi_nfc_compute_timings(struct
> > > > > gpmi_nand_data *this,
> > > > >                 hw->ctrl1n |= BF_GPMI_CTRL1_RDN_DELAY(sample_delay_factor) |
> > > > >                               BM_GPMI_CTRL1_DLL_ENABLE |
> > > > >                               (use_half_period ? BM_GPMI_CTRL1_HALF_PERIOD : 0);
> > > > > +
> > > > > +       clk_set_rate(r->clock[0], hw->clk_rate);
> > > > >  }
> > > > >
> > > > >  void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > > > @@ -449,8 +452,6 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > > >         void __iomem *gpmi_regs = r->gpmi_regs;
> > > > >         unsigned int dll_wait_time_us;
> > > > >
> > > > > -       clk_set_rate(r->clock[0], hw->clk_rate);
> > > > > -
> > > > >         writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
> > > > >         writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);
> > > > >
> > > > > Right now I have this change applied and seems fine. That is the only
> > > > > difference I get. Clock is apply a bit earlier that when is enabled
> > > > > it.  
> > > >
> > > > This is very interesting. So this would mean the issue you are
> > > > experiencing comes from the clock driver which kind of returns too
> > > > early from clk_set_rate()? Could you report this to the clk ML/NXP clk
> > > > maintainers and keep us in copy? If it is as global as it sounds, we
> > > > might not be the only ones affected.
> > > >  
> > >
> > > The imx28 is broken too, so it's a general problem. I need to trace it down
> > > I have a reverting for lts but it\s not the way to go
> > >  
> > 
> > For imx28 you ask to set the rate to 22Mhz but you don't care about the clock
> > that you get back. You get back 12Mhz because the base clock is 24 Mhz and seems
> > that it can not get the point. You need to check if the clock
> > requested is in range or ask
> > for set_rate_clk_min to avoid to have somenthing lower. Then for
> > imx6ull because is sporadic
> > I think that is more connected to the clk_set_rate and when you change
> > the register. Can not be a
> > setting time?
> 
> So, if I understand correctly, we face two different problems:
> - imx6*: seems like a clock issue regarding the clock settlement
> - imx28: actual NAND driver issue (does not check the validity of the
>   new frequency). This should be handled properly in
>   ->setup_interface().
>

Somenthing like this? Not compile/tested

diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
index 4d08e4ab5c1b..cc8146ab1b78 100644
--- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
@@ -644,7 +644,7 @@ static int bch_set_geometry(struct gpmi_nand_data *this)
  *         RDN_DELAY = -----------------------     {3}
  *                           RP
  */
-static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
+static int gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
 				     const struct nand_sdr_timings *sdr)
 {
 	struct gpmi_nfc_hardware_timing *hw = &this->hw;
@@ -656,6 +656,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
 	int sample_delay_ps, sample_delay_factor;
 	u16 busy_timeout_cycles;
 	u8 wrn_dly_sel;
+	long clk_rate;
 
 	if (sdr->tRC_min >= 30000) {
 		/* ONFI non-EDO modes [0-3] */
@@ -671,6 +672,10 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
 		wrn_dly_sel = BV_GPMI_CTRL1_WRN_DLY_SEL_NO_DELAY;
 	}
 
+	clk_rate = clk_round_rate(r->clock[0], hw->clk_rate);
+	if (clk_rate < hw->clk_rate || clk_rate <= 0)
+		return -ENOTSUPP;
+
 	/* SDR core timings are given in picoseconds */
 	period_ps = div_u64((u64)NSEC_PER_SEC * 1000, hw->clk_rate);
 
@@ -746,6 +751,7 @@ static int gpmi_setup_interface(struct nand_chip *chip, int chipnr,
 {
 	struct gpmi_nand_data *this = nand_get_controller_data(chip);
 	const struct nand_sdr_timings *sdr;
+	int ret = 0;
 
 	/* Retrieve required NAND timings */
 	sdr = nand_get_sdr_timings(conf);
@@ -761,11 +767,11 @@ static int gpmi_setup_interface(struct nand_chip *chip, int chipnr,
 		return 0;
 
 	/* Do the actual derivation of the controller timings */
-	gpmi_nfc_compute_timings(this, sdr);
-
-	this->hw.must_apply_timings = true;
+	ret = gpmi_nfc_compute_timings(this, sdr);
+	if (!ret)
+		this->hw.must_apply_timings = true;
 
-	return 0;
+	return ret;
 }
 
 /* Clears a BCH interrupt. */
> Thanks,
> Miquèl

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

^ permalink raw reply related	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-15 20:05                                                           ` Michael Trimarchi
@ 2021-10-15 20:12                                                             ` Michael Nazzareno Trimarchi
  2021-10-18  7:19                                                             ` Miquel Raynal
  1 sibling, 0 replies; 85+ messages in thread
From: Michael Nazzareno Trimarchi @ 2021-10-15 20:12 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: Greg Ungerer, Boris Brezillon, Sascha Hauer, Boris Brezillon, linux-mtd

Hi

On Fri, Oct 15, 2021 at 10:05 PM Michael Trimarchi
<michael@amarulasolutions.com> wrote:
>
> Hi
>
> On Mon, Feb 01, 2021 at 04:14:33PM +0100, Miquel Raynal wrote:
> > Hi Michael,
> >
> > Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> > Mon, 1 Feb 2021 16:08:23 +0100:
> >
> > > Hi
> > >
> > > On Mon, Feb 1, 2021 at 3:32 PM Michael Nazzareno Trimarchi
> > > <michael@amarulasolutions.com> wrote:
> > > >
> > > > Hi
> > > >
> > > > On Mon, Feb 1, 2021 at 3:13 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > >
> > > > > Hi Michael,
> > > > >
> > > > > Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> > > > > Sat, 30 Jan 2021 10:41:29 +0100:
> > > > >
> > > > > > Hi Miquel
> > > > > >
> > > > > > commit f8e6ad14388067f91b26d044185d95623fbc9535
> > > > > > Author: Michael Trimarchi <michael@amarulasolutions.com>
> > > > > > Date:   Fri Jan 29 08:46:53 2021 +0100
> > > > > >
> > > > > >     mtd: nand: Calculate the clock before enable it
> > > > > >
> > > > > >     Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> > > > > >     Change-Id: I79b0da39de0a9b32ea0b002fa200d7f44d4f8ce7
> > > > > >
> > > > > > diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > > b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > > index 322a008290e5..0bca52b3bc8f 100644
> > > > > > --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > > +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > > @@ -377,6 +377,7 @@ static void gpmi_nfc_compute_timings(struct
> > > > > > gpmi_nand_data *this,
> > > > > >                                      const struct nand_sdr_timings *sdr)
> > > > > >  {
> > > > > >         struct gpmi_nfc_hardware_timing *hw = &this->hw;
> > > > > > +       struct resources *r = &this->resources;
> > > > > >         unsigned int dll_threshold_ps = this->devdata->max_chain_delay;
> > > > > >         unsigned int period_ps, reference_period_ps;
> > > > > >         unsigned int data_setup_cycles, data_hold_cycles, addr_setup_cycles;
> > > > > > @@ -440,6 +441,8 @@ static void gpmi_nfc_compute_timings(struct
> > > > > > gpmi_nand_data *this,
> > > > > >                 hw->ctrl1n |= BF_GPMI_CTRL1_RDN_DELAY(sample_delay_factor) |
> > > > > >                               BM_GPMI_CTRL1_DLL_ENABLE |
> > > > > >                               (use_half_period ? BM_GPMI_CTRL1_HALF_PERIOD : 0);
> > > > > > +
> > > > > > +       clk_set_rate(r->clock[0], hw->clk_rate);
> > > > > >  }
> > > > > >
> > > > > >  void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > > > > @@ -449,8 +452,6 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > > > >         void __iomem *gpmi_regs = r->gpmi_regs;
> > > > > >         unsigned int dll_wait_time_us;
> > > > > >
> > > > > > -       clk_set_rate(r->clock[0], hw->clk_rate);
> > > > > > -
> > > > > >         writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
> > > > > >         writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);
> > > > > >
> > > > > > Right now I have this change applied and seems fine. That is the only
> > > > > > difference I get. Clock is apply a bit earlier that when is enabled
> > > > > > it.
> > > > >
> > > > > This is very interesting. So this would mean the issue you are
> > > > > experiencing comes from the clock driver which kind of returns too
> > > > > early from clk_set_rate()? Could you report this to the clk ML/NXP clk
> > > > > maintainers and keep us in copy? If it is as global as it sounds, we
> > > > > might not be the only ones affected.
> > > > >
> > > >
> > > > The imx28 is broken too, so it's a general problem. I need to trace it down
> > > > I have a reverting for lts but it\s not the way to go
> > > >
> > >
> > > For imx28 you ask to set the rate to 22Mhz but you don't care about the clock
> > > that you get back. You get back 12Mhz because the base clock is 24 Mhz and seems
> > > that it can not get the point. You need to check if the clock
> > > requested is in range or ask
> > > for set_rate_clk_min to avoid to have somenthing lower. Then for
> > > imx6ull because is sporadic
> > > I think that is more connected to the clk_set_rate and when you change
> > > the register. Can not be a
> > > setting time?
> >
> > So, if I understand correctly, we face two different problems:
> > - imx6*: seems like a clock issue regarding the clock settlement
> > - imx28: actual NAND driver issue (does not check the validity of the
> >   new frequency). This should be handled properly in
> >   ->setup_interface().
> >
>
> Somenthing like this? Not compile/tested
>
> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> index 4d08e4ab5c1b..cc8146ab1b78 100644
> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> @@ -644,7 +644,7 @@ static int bch_set_geometry(struct gpmi_nand_data *this)
>   *         RDN_DELAY = -----------------------     {3}
>   *                           RP
>   */
> -static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
> +static int gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
>                                      const struct nand_sdr_timings *sdr)
>  {
>         struct gpmi_nfc_hardware_timing *hw = &this->hw;
> @@ -656,6 +656,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
>         int sample_delay_ps, sample_delay_factor;
>         u16 busy_timeout_cycles;
>         u8 wrn_dly_sel;
> +       long clk_rate;
>
>         if (sdr->tRC_min >= 30000) {
>                 /* ONFI non-EDO modes [0-3] */
> @@ -671,6 +672,10 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
>                 wrn_dly_sel = BV_GPMI_CTRL1_WRN_DLY_SEL_NO_DELAY;
>         }
>
> +       clk_rate = clk_round_rate(r->clock[0], hw->clk_rate);
> +       if (clk_rate < hw->clk_rate || clk_rate <= 0)
> +               return -ENOTSUPP;
> +
>         /* SDR core timings are given in picoseconds */
>         period_ps = div_u64((u64)NSEC_PER_SEC * 1000, hw->clk_rate);

Not sure here or:

period_ps = div_u64((u64)NSEC_PER_SEC * 1000, clk_rate);

Michael

>
> @@ -746,6 +751,7 @@ static int gpmi_setup_interface(struct nand_chip *chip, int chipnr,
>  {
>         struct gpmi_nand_data *this = nand_get_controller_data(chip);
>         const struct nand_sdr_timings *sdr;
> +       int ret = 0;
>
>         /* Retrieve required NAND timings */
>         sdr = nand_get_sdr_timings(conf);
> @@ -761,11 +767,11 @@ static int gpmi_setup_interface(struct nand_chip *chip, int chipnr,
>                 return 0;
>
>         /* Do the actual derivation of the controller timings */
> -       gpmi_nfc_compute_timings(this, sdr);
> -
> -       this->hw.must_apply_timings = true;
> +       ret = gpmi_nfc_compute_timings(this, sdr);
> +       if (!ret)
> +               this->hw.must_apply_timings = true;
>
> -       return 0;
> +       return ret;
>  }
>
>  /* Clears a BCH interrupt. */
> > Thanks,
> > Miquèl

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-15 20:05                                                           ` Michael Trimarchi
  2021-10-15 20:12                                                             ` Michael Nazzareno Trimarchi
@ 2021-10-18  7:19                                                             ` Miquel Raynal
  2021-10-18  7:33                                                               ` Michael Nazzareno Trimarchi
  1 sibling, 1 reply; 85+ messages in thread
From: Miquel Raynal @ 2021-10-18  7:19 UTC (permalink / raw)
  To: Michael Trimarchi
  Cc: Greg Ungerer, Boris Brezillon, Sascha Hauer, Boris Brezillon, linux-mtd

Hi Michael,

michael@amarulasolutions.com wrote on Fri, 15 Oct 2021 22:05:41 +0200:

> Hi
> 
> On Mon, Feb 01, 2021 at 04:14:33PM +0100, Miquel Raynal wrote:
> > Hi Michael,
> > 
> > Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> > Mon, 1 Feb 2021 16:08:23 +0100:
> >   
> > > Hi
> > > 
> > > On Mon, Feb 1, 2021 at 3:32 PM Michael Nazzareno Trimarchi
> > > <michael@amarulasolutions.com> wrote:  
> > > >
> > > > Hi
> > > >
> > > > On Mon, Feb 1, 2021 at 3:13 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:    
> > > > >
> > > > > Hi Michael,
> > > > >
> > > > > Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> > > > > Sat, 30 Jan 2021 10:41:29 +0100:
> > > > >    
> > > > > > Hi Miquel
> > > > > >
> > > > > > commit f8e6ad14388067f91b26d044185d95623fbc9535
> > > > > > Author: Michael Trimarchi <michael@amarulasolutions.com>
> > > > > > Date:   Fri Jan 29 08:46:53 2021 +0100
> > > > > >
> > > > > >     mtd: nand: Calculate the clock before enable it
> > > > > >
> > > > > >     Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> > > > > >     Change-Id: I79b0da39de0a9b32ea0b002fa200d7f44d4f8ce7
> > > > > >
> > > > > > diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > > b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > > index 322a008290e5..0bca52b3bc8f 100644
> > > > > > --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > > +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > > @@ -377,6 +377,7 @@ static void gpmi_nfc_compute_timings(struct
> > > > > > gpmi_nand_data *this,
> > > > > >                                      const struct nand_sdr_timings *sdr)
> > > > > >  {
> > > > > >         struct gpmi_nfc_hardware_timing *hw = &this->hw;
> > > > > > +       struct resources *r = &this->resources;
> > > > > >         unsigned int dll_threshold_ps = this->devdata->max_chain_delay;
> > > > > >         unsigned int period_ps, reference_period_ps;
> > > > > >         unsigned int data_setup_cycles, data_hold_cycles, addr_setup_cycles;
> > > > > > @@ -440,6 +441,8 @@ static void gpmi_nfc_compute_timings(struct
> > > > > > gpmi_nand_data *this,
> > > > > >                 hw->ctrl1n |= BF_GPMI_CTRL1_RDN_DELAY(sample_delay_factor) |
> > > > > >                               BM_GPMI_CTRL1_DLL_ENABLE |
> > > > > >                               (use_half_period ? BM_GPMI_CTRL1_HALF_PERIOD : 0);
> > > > > > +
> > > > > > +       clk_set_rate(r->clock[0], hw->clk_rate);
> > > > > >  }
> > > > > >
> > > > > >  void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > > > > @@ -449,8 +452,6 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > > > >         void __iomem *gpmi_regs = r->gpmi_regs;
> > > > > >         unsigned int dll_wait_time_us;
> > > > > >
> > > > > > -       clk_set_rate(r->clock[0], hw->clk_rate);
> > > > > > -
> > > > > >         writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
> > > > > >         writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);
> > > > > >
> > > > > > Right now I have this change applied and seems fine. That is the only
> > > > > > difference I get. Clock is apply a bit earlier that when is enabled
> > > > > > it.    
> > > > >
> > > > > This is very interesting. So this would mean the issue you are
> > > > > experiencing comes from the clock driver which kind of returns too
> > > > > early from clk_set_rate()? Could you report this to the clk ML/NXP clk
> > > > > maintainers and keep us in copy? If it is as global as it sounds, we
> > > > > might not be the only ones affected.
> > > > >    
> > > >
> > > > The imx28 is broken too, so it's a general problem. I need to trace it down
> > > > I have a reverting for lts but it\s not the way to go
> > > >    
> > > 
> > > For imx28 you ask to set the rate to 22Mhz but you don't care about the clock
> > > that you get back. You get back 12Mhz because the base clock is 24 Mhz and seems
> > > that it can not get the point. You need to check if the clock
> > > requested is in range or ask
> > > for set_rate_clk_min to avoid to have somenthing lower. Then for
> > > imx6ull because is sporadic
> > > I think that is more connected to the clk_set_rate and when you change
> > > the register. Can not be a
> > > setting time?  
> > 
> > So, if I understand correctly, we face two different problems:
> > - imx6*: seems like a clock issue regarding the clock settlement
> > - imx28: actual NAND driver issue (does not check the validity of the
> >   new frequency). This should be handled properly in  
> >   ->setup_interface().  
> >  
> 
> Somenthing like this? Not compile/tested
> 
> diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> index 4d08e4ab5c1b..cc8146ab1b78 100644
> --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> @@ -644,7 +644,7 @@ static int bch_set_geometry(struct gpmi_nand_data *this)
>   *         RDN_DELAY = -----------------------     {3}
>   *                           RP
>   */
> -static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
> +static int gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
>  				     const struct nand_sdr_timings *sdr)
>  {
>  	struct gpmi_nfc_hardware_timing *hw = &this->hw;
> @@ -656,6 +656,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
>  	int sample_delay_ps, sample_delay_factor;
>  	u16 busy_timeout_cycles;
>  	u8 wrn_dly_sel;
> +	long clk_rate;
>  
>  	if (sdr->tRC_min >= 30000) {
>  		/* ONFI non-EDO modes [0-3] */
> @@ -671,6 +672,10 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
>  		wrn_dly_sel = BV_GPMI_CTRL1_WRN_DLY_SEL_NO_DELAY;
>  	}
>  
> +	clk_rate = clk_round_rate(r->clock[0], hw->clk_rate);
> +	if (clk_rate < hw->clk_rate || clk_rate <= 0)
> +		return -ENOTSUPP;

I believe clk_rate < hw->clk_rate will always match cases where
clk_rate <= 0 ?

The check looks very strict though. Will it even pass on i.MX6? Perhaps
we could verify something like a 10% error which might grab all the
erroneous situations?

	if (abs(clk_rate - hw->clk_rate) > (hw->clk_rate / 10))
		return -ENOTSUPP;

> +
>  	/* SDR core timings are given in picoseconds */
>  	period_ps = div_u64((u64)NSEC_PER_SEC * 1000, hw->clk_rate);
>  
> @@ -746,6 +751,7 @@ static int gpmi_setup_interface(struct nand_chip *chip, int chipnr,
>  {
>  	struct gpmi_nand_data *this = nand_get_controller_data(chip);
>  	const struct nand_sdr_timings *sdr;
> +	int ret = 0;
>  
>  	/* Retrieve required NAND timings */
>  	sdr = nand_get_sdr_timings(conf);
> @@ -761,11 +767,11 @@ static int gpmi_setup_interface(struct nand_chip *chip, int chipnr,
>  		return 0;
>  
>  	/* Do the actual derivation of the controller timings */
> -	gpmi_nfc_compute_timings(this, sdr);
> -
> -	this->hw.must_apply_timings = true;
> +	ret = gpmi_nfc_compute_timings(this, sdr);
> +	if (!ret)
> +		this->hw.must_apply_timings = true;
>  
> -	return 0;
> +	return ret;
>  }
>  
>  /* Clears a BCH interrupt. */
> > Thanks,
> > Miquèl  

Otherwise looks good, thanks!

Miquèl

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-18  7:19                                                             ` Miquel Raynal
@ 2021-10-18  7:33                                                               ` Michael Nazzareno Trimarchi
  2021-10-18  7:43                                                                 ` Miquel Raynal
  0 siblings, 1 reply; 85+ messages in thread
From: Michael Nazzareno Trimarchi @ 2021-10-18  7:33 UTC (permalink / raw)
  To: Miquel Raynal
  Cc: Greg Ungerer, Boris Brezillon, Sascha Hauer, Boris Brezillon, linux-mtd

Hi


On Mon, Oct 18, 2021 at 9:19 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
>
> Hi Michael,
>
> michael@amarulasolutions.com wrote on Fri, 15 Oct 2021 22:05:41 +0200:
>
> > Hi
> >
> > On Mon, Feb 01, 2021 at 04:14:33PM +0100, Miquel Raynal wrote:
> > > Hi Michael,
> > >
> > > Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> > > Mon, 1 Feb 2021 16:08:23 +0100:
> > >
> > > > Hi
> > > >
> > > > On Mon, Feb 1, 2021 at 3:32 PM Michael Nazzareno Trimarchi
> > > > <michael@amarulasolutions.com> wrote:
> > > > >
> > > > > Hi
> > > > >
> > > > > On Mon, Feb 1, 2021 at 3:13 PM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> > > > > >
> > > > > > Hi Michael,
> > > > > >
> > > > > > Michael Nazzareno Trimarchi <michael@amarulasolutions.com> wrote on
> > > > > > Sat, 30 Jan 2021 10:41:29 +0100:
> > > > > >
> > > > > > > Hi Miquel
> > > > > > >
> > > > > > > commit f8e6ad14388067f91b26d044185d95623fbc9535
> > > > > > > Author: Michael Trimarchi <michael@amarulasolutions.com>
> > > > > > > Date:   Fri Jan 29 08:46:53 2021 +0100
> > > > > > >
> > > > > > >     mtd: nand: Calculate the clock before enable it
> > > > > > >
> > > > > > >     Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> > > > > > >     Change-Id: I79b0da39de0a9b32ea0b002fa200d7f44d4f8ce7
> > > > > > >
> > > > > > > diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > > > b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > > > index 322a008290e5..0bca52b3bc8f 100644
> > > > > > > --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > > > +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > > > @@ -377,6 +377,7 @@ static void gpmi_nfc_compute_timings(struct
> > > > > > > gpmi_nand_data *this,
> > > > > > >                                      const struct nand_sdr_timings *sdr)
> > > > > > >  {
> > > > > > >         struct gpmi_nfc_hardware_timing *hw = &this->hw;
> > > > > > > +       struct resources *r = &this->resources;
> > > > > > >         unsigned int dll_threshold_ps = this->devdata->max_chain_delay;
> > > > > > >         unsigned int period_ps, reference_period_ps;
> > > > > > >         unsigned int data_setup_cycles, data_hold_cycles, addr_setup_cycles;
> > > > > > > @@ -440,6 +441,8 @@ static void gpmi_nfc_compute_timings(struct
> > > > > > > gpmi_nand_data *this,
> > > > > > >                 hw->ctrl1n |= BF_GPMI_CTRL1_RDN_DELAY(sample_delay_factor) |
> > > > > > >                               BM_GPMI_CTRL1_DLL_ENABLE |
> > > > > > >                               (use_half_period ? BM_GPMI_CTRL1_HALF_PERIOD : 0);
> > > > > > > +
> > > > > > > +       clk_set_rate(r->clock[0], hw->clk_rate);
> > > > > > >  }
> > > > > > >
> > > > > > >  void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > > > > > @@ -449,8 +452,6 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > > > > >         void __iomem *gpmi_regs = r->gpmi_regs;
> > > > > > >         unsigned int dll_wait_time_us;
> > > > > > >
> > > > > > > -       clk_set_rate(r->clock[0], hw->clk_rate);
> > > > > > > -
> > > > > > >         writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
> > > > > > >         writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);
> > > > > > >
> > > > > > > Right now I have this change applied and seems fine. That is the only
> > > > > > > difference I get. Clock is apply a bit earlier that when is enabled
> > > > > > > it.
> > > > > >
> > > > > > This is very interesting. So this would mean the issue you are
> > > > > > experiencing comes from the clock driver which kind of returns too
> > > > > > early from clk_set_rate()? Could you report this to the clk ML/NXP clk
> > > > > > maintainers and keep us in copy? If it is as global as it sounds, we
> > > > > > might not be the only ones affected.
> > > > > >
> > > > >
> > > > > The imx28 is broken too, so it's a general problem. I need to trace it down
> > > > > I have a reverting for lts but it\s not the way to go
> > > > >
> > > >
> > > > For imx28 you ask to set the rate to 22Mhz but you don't care about the clock
> > > > that you get back. You get back 12Mhz because the base clock is 24 Mhz and seems
> > > > that it can not get the point. You need to check if the clock
> > > > requested is in range or ask
> > > > for set_rate_clk_min to avoid to have somenthing lower. Then for
> > > > imx6ull because is sporadic
> > > > I think that is more connected to the clk_set_rate and when you change
> > > > the register. Can not be a
> > > > setting time?
> > >
> > > So, if I understand correctly, we face two different problems:
> > > - imx6*: seems like a clock issue regarding the clock settlement
> > > - imx28: actual NAND driver issue (does not check the validity of the
> > >   new frequency). This should be handled properly in
> > >   ->setup_interface().
> > >
> >
> > Somenthing like this? Not compile/tested
> >
> > diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > index 4d08e4ab5c1b..cc8146ab1b78 100644
> > --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > @@ -644,7 +644,7 @@ static int bch_set_geometry(struct gpmi_nand_data *this)
> >   *         RDN_DELAY = -----------------------     {3}
> >   *                           RP
> >   */
> > -static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
> > +static int gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
> >                                    const struct nand_sdr_timings *sdr)
> >  {
> >       struct gpmi_nfc_hardware_timing *hw = &this->hw;
> > @@ -656,6 +656,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
> >       int sample_delay_ps, sample_delay_factor;
> >       u16 busy_timeout_cycles;
> >       u8 wrn_dly_sel;
> > +     long clk_rate;
> >
> >       if (sdr->tRC_min >= 30000) {
> >               /* ONFI non-EDO modes [0-3] */
> > @@ -671,6 +672,10 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
> >               wrn_dly_sel = BV_GPMI_CTRL1_WRN_DLY_SEL_NO_DELAY;
> >       }
> >
> > +     clk_rate = clk_round_rate(r->clock[0], hw->clk_rate);
> > +     if (clk_rate < hw->clk_rate || clk_rate <= 0)
> > +             return -ENOTSUPP;
>
> I believe clk_rate < hw->clk_rate will always match cases where
> clk_rate <= 0 ?
>
> The check looks very strict though. Will it even pass on i.MX6? Perhaps
> we could verify something like a 10% error which might grab all the
> erroneous situations?

According to what I read the clk is the min that we can accept. So any clock
from EDO4 to EDO5 should be ok. My concern is that calculation. I need to read
it properly. I don't think that put 10% or any will help us, until we
now that is possible or not.

I will even anyway put a warning

Michael

>
>         if (abs(clk_rate - hw->clk_rate) > (hw->clk_rate / 10))
>                 return -ENOTSUPP;
>
> > +
> >       /* SDR core timings are given in picoseconds */
> >       period_ps = div_u64((u64)NSEC_PER_SEC * 1000, hw->clk_rate);
> >
> > @@ -746,6 +751,7 @@ static int gpmi_setup_interface(struct nand_chip *chip, int chipnr,
> >  {
> >       struct gpmi_nand_data *this = nand_get_controller_data(chip);
> >       const struct nand_sdr_timings *sdr;
> > +     int ret = 0;
> >
> >       /* Retrieve required NAND timings */
> >       sdr = nand_get_sdr_timings(conf);
> > @@ -761,11 +767,11 @@ static int gpmi_setup_interface(struct nand_chip *chip, int chipnr,
> >               return 0;
> >
> >       /* Do the actual derivation of the controller timings */
> > -     gpmi_nfc_compute_timings(this, sdr);
> > -
> > -     this->hw.must_apply_timings = true;
> > +     ret = gpmi_nfc_compute_timings(this, sdr);
> > +     if (!ret)
> > +             this->hw.must_apply_timings = true;
> >
> > -     return 0;
> > +     return ret;
> >  }
> >
> >  /* Clears a BCH interrupt. */
> > > Thanks,
> > > Miquèl
>
> Otherwise looks good, thanks!
>
> Miquèl



--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael@amarulasolutions.com
__________________________________

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info@amarulasolutions.com
www.amarulasolutions.com

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI iMX6ull timeout on DMA
  2021-10-18  7:33                                                               ` Michael Nazzareno Trimarchi
@ 2021-10-18  7:43                                                                 ` Miquel Raynal
  0 siblings, 0 replies; 85+ messages in thread
From: Miquel Raynal @ 2021-10-18  7:43 UTC (permalink / raw)
  To: Michael Nazzareno Trimarchi
  Cc: Greg Ungerer, Boris Brezillon, Sascha Hauer, Boris Brezillon, linux-mtd

Hi Michael,

> > > > > > > > commit f8e6ad14388067f91b26d044185d95623fbc9535
> > > > > > > > Author: Michael Trimarchi <michael@amarulasolutions.com>
> > > > > > > > Date:   Fri Jan 29 08:46:53 2021 +0100
> > > > > > > >
> > > > > > > >     mtd: nand: Calculate the clock before enable it
> > > > > > > >
> > > > > > > >     Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
> > > > > > > >     Change-Id: I79b0da39de0a9b32ea0b002fa200d7f44d4f8ce7
> > > > > > > >
> > > > > > > > diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > > > > b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > > > > index 322a008290e5..0bca52b3bc8f 100644
> > > > > > > > --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > > > > +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-lib.c
> > > > > > > > @@ -377,6 +377,7 @@ static void gpmi_nfc_compute_timings(struct
> > > > > > > > gpmi_nand_data *this,
> > > > > > > >                                      const struct nand_sdr_timings *sdr)
> > > > > > > >  {
> > > > > > > >         struct gpmi_nfc_hardware_timing *hw = &this->hw;
> > > > > > > > +       struct resources *r = &this->resources;
> > > > > > > >         unsigned int dll_threshold_ps = this->devdata->max_chain_delay;
> > > > > > > >         unsigned int period_ps, reference_period_ps;
> > > > > > > >         unsigned int data_setup_cycles, data_hold_cycles, addr_setup_cycles;
> > > > > > > > @@ -440,6 +441,8 @@ static void gpmi_nfc_compute_timings(struct
> > > > > > > > gpmi_nand_data *this,
> > > > > > > >                 hw->ctrl1n |= BF_GPMI_CTRL1_RDN_DELAY(sample_delay_factor) |
> > > > > > > >                               BM_GPMI_CTRL1_DLL_ENABLE |
> > > > > > > >                               (use_half_period ? BM_GPMI_CTRL1_HALF_PERIOD : 0);
> > > > > > > > +
> > > > > > > > +       clk_set_rate(r->clock[0], hw->clk_rate);
> > > > > > > >  }
> > > > > > > >
> > > > > > > >  void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > > > > > > @@ -449,8 +452,6 @@ void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > > > > > >         void __iomem *gpmi_regs = r->gpmi_regs;
> > > > > > > >         unsigned int dll_wait_time_us;
> > > > > > > >
> > > > > > > > -       clk_set_rate(r->clock[0], hw->clk_rate);
> > > > > > > > -
> > > > > > > >         writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
> > > > > > > >         writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);
> > > > > > > >
> > > > > > > > Right now I have this change applied and seems fine. That is the only
> > > > > > > > difference I get. Clock is apply a bit earlier that when is enabled
> > > > > > > > it.  
> > > > > > >
> > > > > > > This is very interesting. So this would mean the issue you are
> > > > > > > experiencing comes from the clock driver which kind of returns too
> > > > > > > early from clk_set_rate()? Could you report this to the clk ML/NXP clk
> > > > > > > maintainers and keep us in copy? If it is as global as it sounds, we
> > > > > > > might not be the only ones affected.
> > > > > > >  
> > > > > >
> > > > > > The imx28 is broken too, so it's a general problem. I need to trace it down
> > > > > > I have a reverting for lts but it\s not the way to go
> > > > > >  
> > > > >
> > > > > For imx28 you ask to set the rate to 22Mhz but you don't care about the clock
> > > > > that you get back. You get back 12Mhz because the base clock is 24 Mhz and seems
> > > > > that it can not get the point. You need to check if the clock
> > > > > requested is in range or ask
> > > > > for set_rate_clk_min to avoid to have somenthing lower. Then for
> > > > > imx6ull because is sporadic
> > > > > I think that is more connected to the clk_set_rate and when you change
> > > > > the register. Can not be a
> > > > > setting time?  
> > > >
> > > > So, if I understand correctly, we face two different problems:
> > > > - imx6*: seems like a clock issue regarding the clock settlement
> > > > - imx28: actual NAND driver issue (does not check the validity of the
> > > >   new frequency). This should be handled properly in  
> > > >   ->setup_interface().  
> > > >  
> > >
> > > Somenthing like this? Not compile/tested
> > >
> > > diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > > index 4d08e4ab5c1b..cc8146ab1b78 100644
> > > --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > > +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > > @@ -644,7 +644,7 @@ static int bch_set_geometry(struct gpmi_nand_data *this)
> > >   *         RDN_DELAY = -----------------------     {3}
> > >   *                           RP
> > >   */
> > > -static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
> > > +static int gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
> > >                                    const struct nand_sdr_timings *sdr)
> > >  {
> > >       struct gpmi_nfc_hardware_timing *hw = &this->hw;
> > > @@ -656,6 +656,7 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
> > >       int sample_delay_ps, sample_delay_factor;
> > >       u16 busy_timeout_cycles;
> > >       u8 wrn_dly_sel;
> > > +     long clk_rate;
> > >
> > >       if (sdr->tRC_min >= 30000) {
> > >               /* ONFI non-EDO modes [0-3] */
> > > @@ -671,6 +672,10 @@ static void gpmi_nfc_compute_timings(struct gpmi_nand_data *this,
> > >               wrn_dly_sel = BV_GPMI_CTRL1_WRN_DLY_SEL_NO_DELAY;
> > >       }
> > >
> > > +     clk_rate = clk_round_rate(r->clock[0], hw->clk_rate);
> > > +     if (clk_rate < hw->clk_rate || clk_rate <= 0)
> > > +             return -ENOTSUPP;  
> >
> > I believe clk_rate < hw->clk_rate will always match cases where
> > clk_rate <= 0 ?
> >
> > The check looks very strict though. Will it even pass on i.MX6? Perhaps
> > we could verify something like a 10% error which might grab all the
> > erroneous situations?  
> 
> According to what I read the clk is the min that we can accept. So any clock
> from EDO4 to EDO5 should be ok. My concern is that calculation. I need to read
> it properly. I don't think that put 10% or any will help us, until we
> now that is possible or not.

10% was for the example, what I mean is that it is very common to
request a clock to run at 100MHz and to read it at eg. 93MHz. Your
check won't pass in this case and we cannot get the necessary test
coverage in order to ensure that we won't break working boards.

The thing is, if the calculation are made using hw->clk_rate we will
always get the register values wrong anyway and in this case it's true
that only experience will tell us if such a clock works or not.
However, if the calculations are made with clk_rate instead, it is
likely that we will get more accurate timings which very likely will
work. So perhaps the right solution would be to use the real clock rate
instead than refusing clock rates which do not match our strict
expectations?


> >
> >         if (abs(clk_rate - hw->clk_rate) > (hw->clk_rate / 10))
> >                 return -ENOTSUPP;
> >  
> > > +
> > >       /* SDR core timings are given in picoseconds */
> > >       period_ps = div_u64((u64)NSEC_PER_SEC * 1000, hw->clk_rate);
> > >
> > > @@ -746,6 +751,7 @@ static int gpmi_setup_interface(struct nand_chip *chip, int chipnr,
> > >  {
> > >       struct gpmi_nand_data *this = nand_get_controller_data(chip);
> > >       const struct nand_sdr_timings *sdr;
> > > +     int ret = 0;
> > >
> > >       /* Retrieve required NAND timings */
> > >       sdr = nand_get_sdr_timings(conf);
> > > @@ -761,11 +767,11 @@ static int gpmi_setup_interface(struct nand_chip *chip, int chipnr,
> > >               return 0;
> > >
> > >       /* Do the actual derivation of the controller timings */
> > > -     gpmi_nfc_compute_timings(this, sdr);
> > > -
> > > -     this->hw.must_apply_timings = true;
> > > +     ret = gpmi_nfc_compute_timings(this, sdr);
> > > +     if (!ret)
> > > +             this->hw.must_apply_timings = true;
> > >
> > > -     return 0;
> > > +     return ret;
> > >  }
> > >
> > >  /* Clears a BCH interrupt. */  
> > > > Thanks,
> > > > Miquèl  
> >
> > Otherwise looks good, thanks!
> >
> > Miquèl  
> 

Thanks,
Miquèl

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [RFC PATCH 2/2] gpmi-nand: Add ERR007117 protection for nfc_apply_timings
  2021-10-13  5:01                                 ` Han Xu
@ 2021-10-22  8:45                                   ` Stefan Riedmüller
  2021-10-22 14:35                                     ` han.xu
  0 siblings, 1 reply; 85+ messages in thread
From: Stefan Riedmüller @ 2021-10-22  8:45 UTC (permalink / raw)
  To: han.xu
  Cc: miquel.raynal, s.hauer, michael, ceggers, bbrezillon, linux-mtd,
	gerg, Christian Hemp

Hi Han,

sorry it took me some time to get back to you.

On Wed, 2021-10-13 at 00:01 -0500, Han Xu wrote:
> On 21/10/12 11:02AM, Stefan Riedmueller wrote:
> > According to i.MX 6 erratum ERR007117 gpmi clocks need to be gated off
> > when doing a gpmi_io clk rate change. So gate the clocks off before
> > the rate change in nfc_apply_timings and ungate them again after the
> > change.
> > 
> > Otherwise this rate change can lead to an unresponsive GPMI core which
> > results in DMA timeouts and failed driver probe:
> > 
> > [    4.072318] gpmi-nand 112000.gpmi-nand: DMA timeout, last DMA
> > ...
> > [    4.370355] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -110
> > ...
> > [    4.375988] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
> > [    4.381524] gpmi-nand 112000.gpmi-nand: Error in ECC-based read: -22
> > [    4.387988] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
> > [    4.393535] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
> > ...
> > 
> > Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
> > ---
> > Hi,
> > 
> > I'm not sure about the error handling here, if it is actually neccessary.
> > So some feedback would be nice here.
> > 
> > Thanks,
> > Stefan
> > ---
> >  drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 21 +++++++++++++++++++--
> >  1 file changed, 19 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > index a1f7000f033e..326c8a895f1f 100644
> > --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > @@ -713,15 +713,28 @@ static void gpmi_nfc_compute_timings(struct
> > gpmi_nand_data *this,
> >  			      (use_half_period ? BM_GPMI_CTRL1_HALF_PERIOD :
> > 0);
> >  }
> >  
> > -static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > +static int gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> >  {
> >  	struct gpmi_nfc_hardware_timing *hw = &this->hw;
> >  	struct resources *r = &this->resources;
> >  	void __iomem *gpmi_regs = r->gpmi_regs;
> >  	unsigned int dll_wait_time_us;
> > +	int ret;
> > +
> > +	if (GPMI_IS_MX6Q(this)) {
> 
> Not only for 6Q but for GPMI_IS_MX6

Can you confirm that i.MX 6SX and i.MX 7 are affected by the ERR007117 erratum
as well? Because the i.MX 6UL/ULL are included by the GPMI_IS_MX6Q already.

Or do we need another macro for i.MX 6UL/ULL as Christian has suggested
earlier?

Thanks,
Stefan

> 
> > +		ret = __gpmi_enable_clk(this, false);
> > +		if (ret)
> > +			return ret;
> > +	}
> >  
> >  	clk_set_rate(r->clock[0], hw->clk_rate);
> >  
> > +	if (GPMI_IS_MX6Q(this)) {
> > +		ret = __gpmi_enable_clk(this, true);
> > +		if (ret)
> > +			return ret;
> > +	}
> > +
> >  	writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
> >  	writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);
> >  
> > @@ -739,6 +752,8 @@ static void gpmi_nfc_apply_timings(struct
> > gpmi_nand_data *this)
> >  
> >  	/* Wait for the DLL to settle. */
> >  	udelay(dll_wait_time_us);
> > +
> > +	return 0;
> >  }
> >  
> >  static int gpmi_setup_interface(struct nand_chip *chip, int chipnr,
> > @@ -2271,7 +2286,9 @@ static int gpmi_nfc_exec_op(struct nand_chip *chip,
> >  	 */
> >  	if (this->hw.must_apply_timings) {
> >  		this->hw.must_apply_timings = false;
> > -		gpmi_nfc_apply_timings(this);
> > +		ret = gpmi_nfc_apply_timings(this);
> > +		if (ret)
> > +			return ret;
> >  	}
> >  
> >  	dev_dbg(this->dev, "%s: %d instructions\n", __func__, op->ninstrs);
> > -- 
> > 2.25.1
> > 
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [RFC PATCH 2/2] gpmi-nand: Add ERR007117 protection for nfc_apply_timings
  2021-10-22  8:45                                   ` Stefan Riedmüller
@ 2021-10-22 14:35                                     ` han.xu
  2021-10-25  9:39                                       ` Stefan Riedmüller
  2021-10-28  9:28                                       ` Stefan Riedmüller
  0 siblings, 2 replies; 85+ messages in thread
From: han.xu @ 2021-10-22 14:35 UTC (permalink / raw)
  To: Stefan Riedmüller
  Cc: miquel.raynal, s.hauer, michael, ceggers, bbrezillon, linux-mtd,
	gerg, Christian Hemp

On 21/10/22 08:45AM, Stefan Riedmüller wrote:
> Hi Han,
> 
> sorry it took me some time to get back to you.
> 
> On Wed, 2021-10-13 at 00:01 -0500, Han Xu wrote:
> > On 21/10/12 11:02AM, Stefan Riedmueller wrote:
> > > According to i.MX 6 erratum ERR007117 gpmi clocks need to be gated off
> > > when doing a gpmi_io clk rate change. So gate the clocks off before
> > > the rate change in nfc_apply_timings and ungate them again after the
> > > change.
> > > 
> > > Otherwise this rate change can lead to an unresponsive GPMI core which
> > > results in DMA timeouts and failed driver probe:
> > > 
> > > [    4.072318] gpmi-nand 112000.gpmi-nand: DMA timeout, last DMA
> > > ...
> > > [    4.370355] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -110
> > > ...
> > > [    4.375988] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
> > > [    4.381524] gpmi-nand 112000.gpmi-nand: Error in ECC-based read: -22
> > > [    4.387988] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
> > > [    4.393535] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
> > > ...
> > > 
> > > Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
> > > ---
> > > Hi,
> > > 
> > > I'm not sure about the error handling here, if it is actually neccessary.
> > > So some feedback would be nice here.
> > > 
> > > Thanks,
> > > Stefan
> > > ---
> > >  drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 21 +++++++++++++++++++--
> > >  1 file changed, 19 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > > b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > > index a1f7000f033e..326c8a895f1f 100644
> > > --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > > +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > > @@ -713,15 +713,28 @@ static void gpmi_nfc_compute_timings(struct
> > > gpmi_nand_data *this,
> > >  			      (use_half_period ? BM_GPMI_CTRL1_HALF_PERIOD :
> > > 0);
> > >  }
> > >  
> > > -static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > +static int gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > >  {
> > >  	struct gpmi_nfc_hardware_timing *hw = &this->hw;
> > >  	struct resources *r = &this->resources;
> > >  	void __iomem *gpmi_regs = r->gpmi_regs;
> > >  	unsigned int dll_wait_time_us;
> > > +	int ret;
> > > +
> > > +	if (GPMI_IS_MX6Q(this)) {
> > 
> > Not only for 6Q but for GPMI_IS_MX6
> 
> Can you confirm that i.MX 6SX and i.MX 7 are affected by the ERR007117 erratum
> as well? Because the i.MX 6UL/ULL are included by the GPMI_IS_MX6Q already.

i.MX6SX has the glitch issue for sure, but I can double check if it's due to the
same errata. I will also go check if the errata will affect i.MX7

> 
> Or do we need another macro for i.MX 6UL/ULL as Christian has suggested
> earlier?
> 
> Thanks,
> Stefan
> 
> > 
> > > +		ret = __gpmi_enable_clk(this, false);
> > > +		if (ret)
> > > +			return ret;
> > > +	}
> > >  
> > >  	clk_set_rate(r->clock[0], hw->clk_rate);
> > >  
> > > +	if (GPMI_IS_MX6Q(this)) {
> > > +		ret = __gpmi_enable_clk(this, true);
> > > +		if (ret)
> > > +			return ret;
> > > +	}
> > > +
> > >  	writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
> > >  	writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);
> > >  
> > > @@ -739,6 +752,8 @@ static void gpmi_nfc_apply_timings(struct
> > > gpmi_nand_data *this)
> > >  
> > >  	/* Wait for the DLL to settle. */
> > >  	udelay(dll_wait_time_us);
> > > +
> > > +	return 0;
> > >  }
> > >  
> > >  static int gpmi_setup_interface(struct nand_chip *chip, int chipnr,
> > > @@ -2271,7 +2286,9 @@ static int gpmi_nfc_exec_op(struct nand_chip *chip,
> > >  	 */
> > >  	if (this->hw.must_apply_timings) {
> > >  		this->hw.must_apply_timings = false;
> > > -		gpmi_nfc_apply_timings(this);
> > > +		ret = gpmi_nfc_apply_timings(this);
> > > +		if (ret)
> > > +			return ret;
> > >  	}
> > >  
> > >  	dev_dbg(this->dev, "%s: %d instructions\n", __func__, op->ninstrs);
> > > -- 
> > > 2.25.1
> > > 

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [RFC PATCH 2/2] gpmi-nand: Add ERR007117 protection for nfc_apply_timings
  2021-10-22 14:35                                     ` han.xu
@ 2021-10-25  9:39                                       ` Stefan Riedmüller
  2021-10-28  9:28                                       ` Stefan Riedmüller
  1 sibling, 0 replies; 85+ messages in thread
From: Stefan Riedmüller @ 2021-10-25  9:39 UTC (permalink / raw)
  To: han.xu
  Cc: miquel.raynal, s.hauer, michael, ceggers, bbrezillon,
	Christian Hemp, gerg, linux-mtd

Hi Han,

On Fri, 2021-10-22 at 09:35 -0500, han.xu@nxp.com wrote:
> On 21/10/22 08:45AM, Stefan Riedmüller wrote:
> > Hi Han,
> > 
> > sorry it took me some time to get back to you.
> > 
> > On Wed, 2021-10-13 at 00:01 -0500, Han Xu wrote:
> > > On 21/10/12 11:02AM, Stefan Riedmueller wrote:
> > > > According to i.MX 6 erratum ERR007117 gpmi clocks need to be gated off
> > > > when doing a gpmi_io clk rate change. So gate the clocks off before
> > > > the rate change in nfc_apply_timings and ungate them again after the
> > > > change.
> > > > 
> > > > Otherwise this rate change can lead to an unresponsive GPMI core which
> > > > results in DMA timeouts and failed driver probe:
> > > > 
> > > > [    4.072318] gpmi-nand 112000.gpmi-nand: DMA timeout, last DMA
> > > > ...
> > > > [    4.370355] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -110
> > > > ...
> > > > [    4.375988] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
> > > > [    4.381524] gpmi-nand 112000.gpmi-nand: Error in ECC-based read:
> > > > -22
> > > > [    4.387988] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
> > > > [    4.393535] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
> > > > ...
> > > > 
> > > > Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
> > > > ---
> > > > Hi,
> > > > 
> > > > I'm not sure about the error handling here, if it is actually
> > > > neccessary.
> > > > So some feedback would be nice here.
> > > > 
> > > > Thanks,
> > > > Stefan
> > > > ---
> > > >  drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 21 +++++++++++++++++++--
> > > >  1 file changed, 19 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > > > b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > > > index a1f7000f033e..326c8a895f1f 100644
> > > > --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > > > +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > > > @@ -713,15 +713,28 @@ static void gpmi_nfc_compute_timings(struct
> > > > gpmi_nand_data *this,
> > > >  			      (use_half_period ?
> > > > BM_GPMI_CTRL1_HALF_PERIOD :
> > > > 0);
> > > >  }
> > > >  
> > > > -static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > > +static int gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > >  {
> > > >  	struct gpmi_nfc_hardware_timing *hw = &this->hw;
> > > >  	struct resources *r = &this->resources;
> > > >  	void __iomem *gpmi_regs = r->gpmi_regs;
> > > >  	unsigned int dll_wait_time_us;
> > > > +	int ret;
> > > > +
> > > > +	if (GPMI_IS_MX6Q(this)) {
> > > 
> > > Not only for 6Q but for GPMI_IS_MX6
> > 
> > Can you confirm that i.MX 6SX and i.MX 7 are affected by the ERR007117
> > erratum
> > as well? Because the i.MX 6UL/ULL are included by the GPMI_IS_MX6Q
> > already.
> 
> i.MX6SX has the glitch issue for sure, but I can double check if it's due to
> the
> same errata. I will also go check if the errata will affect i.MX7

Thanks, that'll be great!

I'll wait for your response.

Thanks,
Stefan

> 
> > Or do we need another macro for i.MX 6UL/ULL as Christian has suggested
> > earlier?
> > 
> > Thanks,
> > Stefan
> > 
> > > > +		ret = __gpmi_enable_clk(this, false);
> > > > +		if (ret)
> > > > +			return ret;
> > > > +	}
> > > >  
> > > >  	clk_set_rate(r->clock[0], hw->clk_rate);
> > > >  
> > > > +	if (GPMI_IS_MX6Q(this)) {
> > > > +		ret = __gpmi_enable_clk(this, true);
> > > > +		if (ret)
> > > > +			return ret;
> > > > +	}
> > > > +
> > > >  	writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
> > > >  	writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);
> > > >  
> > > > @@ -739,6 +752,8 @@ static void gpmi_nfc_apply_timings(struct
> > > > gpmi_nand_data *this)
> > > >  
> > > >  	/* Wait for the DLL to settle. */
> > > >  	udelay(dll_wait_time_us);
> > > > +
> > > > +	return 0;
> > > >  }
> > > >  
> > > >  static int gpmi_setup_interface(struct nand_chip *chip, int chipnr,
> > > > @@ -2271,7 +2286,9 @@ static int gpmi_nfc_exec_op(struct nand_chip
> > > > *chip,
> > > >  	 */
> > > >  	if (this->hw.must_apply_timings) {
> > > >  		this->hw.must_apply_timings = false;
> > > > -		gpmi_nfc_apply_timings(this);
> > > > +		ret = gpmi_nfc_apply_timings(this);
> > > > +		if (ret)
> > > > +			return ret;
> > > >  	}
> > > >  
> > > >  	dev_dbg(this->dev, "%s: %d instructions\n", __func__, op-
> > > > >ninstrs);
> > > > -- 
> > > > 2.25.1
> > > > 
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [RFC PATCH 2/2] gpmi-nand: Add ERR007117 protection for nfc_apply_timings
  2021-10-22 14:35                                     ` han.xu
  2021-10-25  9:39                                       ` Stefan Riedmüller
@ 2021-10-28  9:28                                       ` Stefan Riedmüller
  2021-11-01  4:01                                         ` han.xu
  1 sibling, 1 reply; 85+ messages in thread
From: Stefan Riedmüller @ 2021-10-28  9:28 UTC (permalink / raw)
  To: han.xu
  Cc: miquel.raynal, s.hauer, michael, ceggers, bbrezillon,
	Christian Hemp, gerg, linux-mtd

Hi Han,

On Fri, 2021-10-22 at 09:35 -0500, han.xu@nxp.com wrote:
> On 21/10/22 08:45AM, Stefan Riedmüller wrote:
> > Hi Han,
> > 
> > sorry it took me some time to get back to you.
> > 
> > On Wed, 2021-10-13 at 00:01 -0500, Han Xu wrote:
> > > On 21/10/12 11:02AM, Stefan Riedmueller wrote:
> > > > According to i.MX 6 erratum ERR007117 gpmi clocks need to be gated off
> > > > when doing a gpmi_io clk rate change. So gate the clocks off before
> > > > the rate change in nfc_apply_timings and ungate them again after the
> > > > change.
> > > > 
> > > > Otherwise this rate change can lead to an unresponsive GPMI core which
> > > > results in DMA timeouts and failed driver probe:
> > > > 
> > > > [    4.072318] gpmi-nand 112000.gpmi-nand: DMA timeout, last DMA
> > > > ...
> > > > [    4.370355] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -110
> > > > ...
> > > > [    4.375988] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
> > > > [    4.381524] gpmi-nand 112000.gpmi-nand: Error in ECC-based read:
> > > > -22
> > > > [    4.387988] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
> > > > [    4.393535] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
> > > > ...
> > > > 
> > > > Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
> > > > ---
> > > > Hi,
> > > > 
> > > > I'm not sure about the error handling here, if it is actually
> > > > neccessary.
> > > > So some feedback would be nice here.
> > > > 
> > > > Thanks,
> > > > Stefan
> > > > ---
> > > >  drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 21 +++++++++++++++++++--
> > > >  1 file changed, 19 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > > > b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > > > index a1f7000f033e..326c8a895f1f 100644
> > > > --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > > > +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > > > @@ -713,15 +713,28 @@ static void gpmi_nfc_compute_timings(struct
> > > > gpmi_nand_data *this,
> > > >  			      (use_half_period ?
> > > > BM_GPMI_CTRL1_HALF_PERIOD :
> > > > 0);
> > > >  }
> > > >  
> > > > -static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > > +static int gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > >  {
> > > >  	struct gpmi_nfc_hardware_timing *hw = &this->hw;
> > > >  	struct resources *r = &this->resources;
> > > >  	void __iomem *gpmi_regs = r->gpmi_regs;
> > > >  	unsigned int dll_wait_time_us;
> > > > +	int ret;
> > > > +
> > > > +	if (GPMI_IS_MX6Q(this)) {
> > > 
> > > Not only for 6Q but for GPMI_IS_MX6
> > 
> > Can you confirm that i.MX 6SX and i.MX 7 are affected by the ERR007117
> > erratum
> > as well? Because the i.MX 6UL/ULL are included by the GPMI_IS_MX6Q
> > already.
> 
> i.MX6SX has the glitch issue for sure, but I can double check if it's due to
> the
> same errata. I will also go check if the errata will affect i.MX7

Any updates yet?

Thanks,
Stefan

> 
> > Or do we need another macro for i.MX 6UL/ULL as Christian has suggested
> > earlier?
> > 
> > Thanks,
> > Stefan
> > 
> > > > +		ret = __gpmi_enable_clk(this, false);
> > > > +		if (ret)
> > > > +			return ret;
> > > > +	}
> > > >  
> > > >  	clk_set_rate(r->clock[0], hw->clk_rate);
> > > >  
> > > > +	if (GPMI_IS_MX6Q(this)) {
> > > > +		ret = __gpmi_enable_clk(this, true);
> > > > +		if (ret)
> > > > +			return ret;
> > > > +	}
> > > > +
> > > >  	writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
> > > >  	writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);
> > > >  
> > > > @@ -739,6 +752,8 @@ static void gpmi_nfc_apply_timings(struct
> > > > gpmi_nand_data *this)
> > > >  
> > > >  	/* Wait for the DLL to settle. */
> > > >  	udelay(dll_wait_time_us);
> > > > +
> > > > +	return 0;
> > > >  }
> > > >  
> > > >  static int gpmi_setup_interface(struct nand_chip *chip, int chipnr,
> > > > @@ -2271,7 +2286,9 @@ static int gpmi_nfc_exec_op(struct nand_chip
> > > > *chip,
> > > >  	 */
> > > >  	if (this->hw.must_apply_timings) {
> > > >  		this->hw.must_apply_timings = false;
> > > > -		gpmi_nfc_apply_timings(this);
> > > > +		ret = gpmi_nfc_apply_timings(this);
> > > > +		if (ret)
> > > > +			return ret;
> > > >  	}
> > > >  
> > > >  	dev_dbg(this->dev, "%s: %d instructions\n", __func__, op-
> > > > >ninstrs);
> > > > -- 
> > > > 2.25.1
> > > > 
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: [RFC PATCH 2/2] gpmi-nand: Add ERR007117 protection for nfc_apply_timings
  2021-10-28  9:28                                       ` Stefan Riedmüller
@ 2021-11-01  4:01                                         ` han.xu
  0 siblings, 0 replies; 85+ messages in thread
From: han.xu @ 2021-11-01  4:01 UTC (permalink / raw)
  To: Stefan Riedmüller
  Cc: miquel.raynal, s.hauer, michael, ceggers, bbrezillon,
	Christian Hemp, gerg, linux-mtd

On 21/10/28 09:28AM, Stefan Riedmüller wrote:
> Hi Han,
> 
> On Fri, 2021-10-22 at 09:35 -0500, han.xu@nxp.com wrote:
> > On 21/10/22 08:45AM, Stefan Riedmüller wrote:
> > > Hi Han,
> > > 
> > > sorry it took me some time to get back to you.
> > > 
> > > On Wed, 2021-10-13 at 00:01 -0500, Han Xu wrote:
> > > > On 21/10/12 11:02AM, Stefan Riedmueller wrote:
> > > > > According to i.MX 6 erratum ERR007117 gpmi clocks need to be gated off
> > > > > when doing a gpmi_io clk rate change. So gate the clocks off before
> > > > > the rate change in nfc_apply_timings and ungate them again after the
> > > > > change.
> > > > > 
> > > > > Otherwise this rate change can lead to an unresponsive GPMI core which
> > > > > results in DMA timeouts and failed driver probe:
> > > > > 
> > > > > [    4.072318] gpmi-nand 112000.gpmi-nand: DMA timeout, last DMA
> > > > > ...
> > > > > [    4.370355] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -110
> > > > > ...
> > > > > [    4.375988] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
> > > > > [    4.381524] gpmi-nand 112000.gpmi-nand: Error in ECC-based read:
> > > > > -22
> > > > > [    4.387988] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
> > > > > [    4.393535] gpmi-nand 112000.gpmi-nand: Chip: 0, Error -22
> > > > > ...
> > > > > 
> > > > > Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de>
> > > > > ---
> > > > > Hi,
> > > > > 
> > > > > I'm not sure about the error handling here, if it is actually
> > > > > neccessary.
> > > > > So some feedback would be nice here.
> > > > > 
> > > > > Thanks,
> > > > > Stefan
> > > > > ---
> > > > >  drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 21 +++++++++++++++++++--
> > > > >  1 file changed, 19 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > > > > b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > > > > index a1f7000f033e..326c8a895f1f 100644
> > > > > --- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > > > > +++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
> > > > > @@ -713,15 +713,28 @@ static void gpmi_nfc_compute_timings(struct
> > > > > gpmi_nand_data *this,
> > > > >  			      (use_half_period ?
> > > > > BM_GPMI_CTRL1_HALF_PERIOD :
> > > > > 0);
> > > > >  }
> > > > >  
> > > > > -static void gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > > > +static int gpmi_nfc_apply_timings(struct gpmi_nand_data *this)
> > > > >  {
> > > > >  	struct gpmi_nfc_hardware_timing *hw = &this->hw;
> > > > >  	struct resources *r = &this->resources;
> > > > >  	void __iomem *gpmi_regs = r->gpmi_regs;
> > > > >  	unsigned int dll_wait_time_us;
> > > > > +	int ret;
> > > > > +
> > > > > +	if (GPMI_IS_MX6Q(this)) {
> > > > 
> > > > Not only for 6Q but for GPMI_IS_MX6
> > > 
> > > Can you confirm that i.MX 6SX and i.MX 7 are affected by the ERR007117
> > > erratum
> > > as well? Because the i.MX 6UL/ULL are included by the GPMI_IS_MX6Q
> > > already.
> > 
> > i.MX6SX has the glitch issue for sure, but I can double check if it's due to
> > the
> > same errata. I will also go check if the errata will affect i.MX7
> 
> Any updates yet?
> 
> Thanks,
> Stefan

Sorry Stefan, I didn't get useful info so I involved more people for this
question. Hopefully can get an answer soon.

Or you can just add 6Q and 6UL/ULL first.

> 
> > 
> > > Or do we need another macro for i.MX 6UL/ULL as Christian has suggested
> > > earlier?
> > > 
> > > Thanks,
> > > Stefan
> > > 
> > > > > +		ret = __gpmi_enable_clk(this, false);
> > > > > +		if (ret)
> > > > > +			return ret;
> > > > > +	}
> > > > >  
> > > > >  	clk_set_rate(r->clock[0], hw->clk_rate);
> > > > >  
> > > > > +	if (GPMI_IS_MX6Q(this)) {
> > > > > +		ret = __gpmi_enable_clk(this, true);
> > > > > +		if (ret)
> > > > > +			return ret;
> > > > > +	}
> > > > > +
> > > > >  	writel(hw->timing0, gpmi_regs + HW_GPMI_TIMING0);
> > > > >  	writel(hw->timing1, gpmi_regs + HW_GPMI_TIMING1);
> > > > >  
> > > > > @@ -739,6 +752,8 @@ static void gpmi_nfc_apply_timings(struct
> > > > > gpmi_nand_data *this)
> > > > >  
> > > > >  	/* Wait for the DLL to settle. */
> > > > >  	udelay(dll_wait_time_us);
> > > > > +
> > > > > +	return 0;
> > > > >  }
> > > > >  
> > > > >  static int gpmi_setup_interface(struct nand_chip *chip, int chipnr,
> > > > > @@ -2271,7 +2286,9 @@ static int gpmi_nfc_exec_op(struct nand_chip
> > > > > *chip,
> > > > >  	 */
> > > > >  	if (this->hw.must_apply_timings) {
> > > > >  		this->hw.must_apply_timings = false;
> > > > > -		gpmi_nfc_apply_timings(this);
> > > > > +		ret = gpmi_nfc_apply_timings(this);
> > > > > +		if (ret)
> > > > > +			return ret;
> > > > >  	}
> > > > >  
> > > > >  	dev_dbg(this->dev, "%s: %d instructions\n", __func__, op-
> > > > > >ninstrs);
> > > > > -- 
> > > > > 2.25.1
> > > > > 

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

^ permalink raw reply	[flat|nested] 85+ messages in thread

* Re: GPMI IMX6ull timeout on dma
  2018-10-02 13:22 GPMI IMX6ull timeout on dma Michael Nazzareno Trimarchi
@ 2018-10-04 14:36 ` Michael Nazzareno Trimarchi
  0 siblings, 0 replies; 85+ messages in thread
From: Michael Nazzareno Trimarchi @ 2018-10-04 14:36 UTC (permalink / raw)
  To: Han Xu, Boris Brezillon; +Cc: linux-mtd

Hi

I add now this code but nand seems incosistent
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
---
 drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
index c2597c8107a0..b1598dc5013f 100644
--- a/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
+++ b/drivers/mtd/nand/raw/gpmi-nand/gpmi-nand.c
@@ -466,11 +466,9 @@ void prepare_data_dma(struct gpmi_nand_data
*this, enum dma_data_direction dr)
        this->direct_dma_map_ok = false;
 }

-/* This will be called after the DMA operation is finished. */
-static void dma_irq_callback(void *param)
+static void dma_unmap_request(void *param)
 {
        struct gpmi_nand_data *this = param;
-       struct completion *dma_c = &this->dma_done;

        switch (this->dma_type) {
        case DMA_FOR_COMMAND:
@@ -492,11 +490,18 @@ static void dma_irq_callback(void *param)
        case DMA_FOR_WRITE_ECC_PAGE:
                /* We have to wait the BCH interrupt to finish. */
                break;
-
        default:
                dev_err(this->dev, "in wrong DMA operation.\n");
        }
+}
+
+/* This will be called after the DMA operation is finished. */
+static void dma_irq_callback(void *param)
+{
+       struct gpmi_nand_data *this = param;
+       struct completion *dma_c = &this->dma_done;

+       dma_unmap_request(param);
        complete(dma_c);
 }

Michael
On Tue, Oct 2, 2018 at 3:22 PM Michael Nazzareno Trimarchi
<michael@amarulasolutions.com> wrote:
>
> Hi all
>
> I have a strange problem on booting an imx6ull system. The problem is
> not systematic and seems that it depends on how bootloader is using
> the nand on first stage boot. BTW kernel can not always pass to go to
> edo time 5 (even 4). If I power off and power on the unit the nand
> work properly.
>
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 4.17.0-rc1 (michael@panicking) (gcc
> version 6.4.0 (Buildroot 2018.02-rc2-00006-g39101b7)) #2 SMP Tue Oct 2
> 08:24:58 CEST 2018
>
> [    1.612357] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
> [    1.618905] nand: Micron MT29F2G08ABAEAH4
> [    1.623126] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
> 2048, OOB size: 64
> [    2.651940] gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA :2
> [    2.658146] gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
> [    2.664203] gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
> [    2.670474] gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
> [    2.676849] gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> [    2.683217] gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> [    2.689482] gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> [    2.695840] gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> [    2.702202] gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
> [    2.708470] gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
> [    2.714826] gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
> [    2.721093] gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
> [    2.727450] gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
> [    2.733812] gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
> [    2.740078] gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000000
> [    2.746437] gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
> [    2.752794] gpmi-nand 1806000.gpmi-nand: Show BCH registers :
> [    2.758626] gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
> [    2.764982] gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
> [    2.771247] gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
> [    2.777604] gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
> [    2.783961] gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
> [    2.790226] gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
> [    2.796582] gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
> [    2.802942] gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
> [    2.809208] gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
> [    2.815564] gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
> [    2.821924] gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
> [    2.828191] gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
> [    2.834546] gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
> [    2.840813] gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
> [    2.847170] gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
> [    2.853527] gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
> [    2.859794] gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
> [    2.866153] gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
> [    2.872513] gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
> [    2.878779] gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
> [    2.885135] gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
> [    2.891401] gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
> [    2.897759] gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
> [    2.904117] gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
> [    2.910400] gpmi-nand 1806000.gpmi-nand: BCH Geometry :
> [    2.910400] GF length              : 13
> [    2.910400] ECC Strength           : 8
> [    2.910400] Page Size in Bytes     : 2110
> [    2.910400] Metadata Size in Bytes : 10
> [    2.910400] ECC Chunk Size in Bytes: 512
> [    2.910400] ECC Chunk Count        : 4
> [    2.910400] Payload Size in Bytes  : 2048
> [    2.910400] Auxiliary Size in Bytes: 16
> [    2.910400] Auxiliary Status Offset: 12
> [    2.910400] Block Mark Byte Offset : 1999
> [    2.910400] Block Mark Bit Offset  : 0
> [    2.958231] gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110
>
> What bootloader do is just attach the ubi and then boot the image
>
> ubi0: attaching mtd1
> ubi0: scanning is finished
> ubi0: attached mtd1 (name "mtd=5", size 231 MiB)
> ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
> ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
> ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
> ubi0: good PEBs: 1844, bad PEBs: 4, corrupted PEBs: 0
> ubi0: user volume: 4, internal volumes: 1, max. volumes count: 128
> ubi0: max/mean erase counter: 4/2, WL threshold: 4096, image sequence number: 0
> ubi0: available PEBs: 2, total reserved PEBs: 1842, PEBs reserved for
> bad PEB handling: 36
> Read 0 bytes from volume kernel to 82800000
> No size specified -> Using max size (16887808)
> ## Loading kernel from FIT Image at 82800000 ...
>    Using 'conf@2' configuration
>    Verifying Hash Integrity ... OK
>    Trying 'kernel@1' kernel subimage
>      Description:  kernel
>      Type:         Kernel Image
>      Compression:  uncompressed
>      Data Start:   0x828000ac
>      Data Size:    6685920 Bytes = 6.4 MiB
>      Architecture: ARM
>      OS:           Linux
>      Load Address: 0x80008000
>      Entry Point:  0x80008000
>      Hash algo:    sha1
>      Hash value:   4646b0eea535d8ea9e2f7167bdeedc7668b2a948
>    Verifying Hash Integrity ... sha1+ OK
> ## Loading fdt from FIT Image at 82800000 ...
>    Using 'conf@2' configuration
>    Trying 'fdt@2' fdt subimage
>      Description:  imx6ull-bammi.dtb
>      Type:         Flat Device Tree
>      Compression:  uncompressed
>      Data Start:   0x82e67730
>      Data Size:    28667 Bytes = 28 KiB
>      Architecture: ARM
>      Hash algo:    sha1
>      Hash value:   1cf147576a30eb901a6306172f9385d6a6b65753
>    Verifying Hash Integrity ... sha1+ OK
>    Booting using the fdt blob at 0x82e67730
>    Loading Kernel Image ... OK
>    Using Device Tree in place at 82e67730, end 82e7172a
>    Using Device Tree in place at 82e67730, end 82e7472a
>
> Any idea?
>
> Michael



-- 
| Michael Nazzareno Trimarchi                     Amarula Solutions BV |
| COO  -  Founder                                      Cruquiuskade 47 |
| +31(0)851119172                                 Amsterdam 1018 AM NL |
|                  [`as] http://www.amarulasolutions.com               |

^ permalink raw reply related	[flat|nested] 85+ messages in thread

* GPMI IMX6ull timeout on dma
@ 2018-10-02 13:22 Michael Nazzareno Trimarchi
  2018-10-04 14:36 ` Michael Nazzareno Trimarchi
  0 siblings, 1 reply; 85+ messages in thread
From: Michael Nazzareno Trimarchi @ 2018-10-02 13:22 UTC (permalink / raw)
  To: Han Xu, Boris Brezillon; +Cc: linux-mtd

Hi all

I have a strange problem on booting an imx6ull system. The problem is
not systematic and seems that it depends on how bootloader is using
the nand on first stage boot. BTW kernel can not always pass to go to
edo time 5 (even 4). If I power off and power on the unit the nand
work properly.

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.17.0-rc1 (michael@panicking) (gcc
version 6.4.0 (Buildroot 2018.02-rc2-00006-g39101b7)) #2 SMP Tue Oct 2
08:24:58 CEST 2018

[    1.612357] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda
[    1.618905] nand: Micron MT29F2G08ABAEAH4
[    1.623126] nand: 256 MiB, SLC, erase size: 128 KiB, page size:
2048, OOB size: 64
[    2.651940] gpmi-nand 1806000.gpmi-nand: DMA timeout, last DMA :2
[    2.658146] gpmi-nand 1806000.gpmi-nand: Show GPMI registers :
[    2.664203] gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x20830002
[    2.670474] gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000000
[    2.676849] gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
[    2.683217] gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
[    2.689482] gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
[    2.695840] gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
[    2.702202] gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x01c6800c
[    2.708470] gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00010101
[    2.714826] gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0xe0000000
[    2.721093] gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x23023336
[    2.727450] gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x000001ee
[    2.733812] gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0xff000001
[    2.740078] gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x00000000
[    2.746437] gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x05020000
[    2.752794] gpmi-nand 1806000.gpmi-nand: Show BCH registers :
[    2.758626] gpmi-nand 1806000.gpmi-nand: offset 0x000 : 0x00000100
[    2.764982] gpmi-nand 1806000.gpmi-nand: offset 0x010 : 0x00000010
[    2.771247] gpmi-nand 1806000.gpmi-nand: offset 0x020 : 0x00000000
[    2.777604] gpmi-nand 1806000.gpmi-nand: offset 0x030 : 0x00000000
[    2.783961] gpmi-nand 1806000.gpmi-nand: offset 0x040 : 0x00000000
[    2.790226] gpmi-nand 1806000.gpmi-nand: offset 0x050 : 0x00000000
[    2.796582] gpmi-nand 1806000.gpmi-nand: offset 0x060 : 0x00000000
[    2.802942] gpmi-nand 1806000.gpmi-nand: offset 0x070 : 0x00000000
[    2.809208] gpmi-nand 1806000.gpmi-nand: offset 0x080 : 0x030a2080
[    2.815564] gpmi-nand 1806000.gpmi-nand: offset 0x090 : 0x083e2080
[    2.821924] gpmi-nand 1806000.gpmi-nand: offset 0x0a0 : 0x070a4080
[    2.828191] gpmi-nand 1806000.gpmi-nand: offset 0x0b0 : 0x10da4080
[    2.834546] gpmi-nand 1806000.gpmi-nand: offset 0x0c0 : 0x070a4080
[    2.840813] gpmi-nand 1806000.gpmi-nand: offset 0x0d0 : 0x10da4080
[    2.847170] gpmi-nand 1806000.gpmi-nand: offset 0x0e0 : 0x070a4080
[    2.853527] gpmi-nand 1806000.gpmi-nand: offset 0x0f0 : 0x10da4080
[    2.859794] gpmi-nand 1806000.gpmi-nand: offset 0x100 : 0x00000000
[    2.866153] gpmi-nand 1806000.gpmi-nand: offset 0x110 : 0x00000000
[    2.872513] gpmi-nand 1806000.gpmi-nand: offset 0x120 : 0x00000000
[    2.878779] gpmi-nand 1806000.gpmi-nand: offset 0x130 : 0x00000000
[    2.885135] gpmi-nand 1806000.gpmi-nand: offset 0x140 : 0x00000000
[    2.891401] gpmi-nand 1806000.gpmi-nand: offset 0x150 : 0x20484342
[    2.897759] gpmi-nand 1806000.gpmi-nand: offset 0x160 : 0x01000000
[    2.904117] gpmi-nand 1806000.gpmi-nand: offset 0x170 : 0x00000000
[    2.910400] gpmi-nand 1806000.gpmi-nand: BCH Geometry :
[    2.910400] GF length              : 13
[    2.910400] ECC Strength           : 8
[    2.910400] Page Size in Bytes     : 2110
[    2.910400] Metadata Size in Bytes : 10
[    2.910400] ECC Chunk Size in Bytes: 512
[    2.910400] ECC Chunk Count        : 4
[    2.910400] Payload Size in Bytes  : 2048
[    2.910400] Auxiliary Size in Bytes: 16
[    2.910400] Auxiliary Status Offset: 12
[    2.910400] Block Mark Byte Offset : 1999
[    2.910400] Block Mark Bit Offset  : 0
[    2.958231] gpmi-nand 1806000.gpmi-nand: Chip: 0, Error -110

What bootloader do is just attach the ubi and then boot the image

ubi0: attaching mtd1
ubi0: scanning is finished
ubi0: attached mtd1 (name "mtd=5", size 231 MiB)
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 bytes
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
ubi0: VID header offset: 2048 (aligned 2048), data offset: 4096
ubi0: good PEBs: 1844, bad PEBs: 4, corrupted PEBs: 0
ubi0: user volume: 4, internal volumes: 1, max. volumes count: 128
ubi0: max/mean erase counter: 4/2, WL threshold: 4096, image sequence number: 0
ubi0: available PEBs: 2, total reserved PEBs: 1842, PEBs reserved for
bad PEB handling: 36
Read 0 bytes from volume kernel to 82800000
No size specified -> Using max size (16887808)
## Loading kernel from FIT Image at 82800000 ...
   Using 'conf@2' configuration
   Verifying Hash Integrity ... OK
   Trying 'kernel@1' kernel subimage
     Description:  kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x828000ac
     Data Size:    6685920 Bytes = 6.4 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x80008000
     Entry Point:  0x80008000
     Hash algo:    sha1
     Hash value:   4646b0eea535d8ea9e2f7167bdeedc7668b2a948
   Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 82800000 ...
   Using 'conf@2' configuration
   Trying 'fdt@2' fdt subimage
     Description:  imx6ull-bammi.dtb
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x82e67730
     Data Size:    28667 Bytes = 28 KiB
     Architecture: ARM
     Hash algo:    sha1
     Hash value:   1cf147576a30eb901a6306172f9385d6a6b65753
   Verifying Hash Integrity ... sha1+ OK
   Booting using the fdt blob at 0x82e67730
   Loading Kernel Image ... OK
   Using Device Tree in place at 82e67730, end 82e7172a
   Using Device Tree in place at 82e67730, end 82e7472a

Any idea?

Michael

^ permalink raw reply	[flat|nested] 85+ messages in thread

end of thread, other threads:[~2021-11-01  4:02 UTC | newest]

Thread overview: 85+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-29  6:41 GPMI iMX6ull timeout on DMA Greg Ungerer
2019-07-29  8:36 ` Miquel Raynal
2019-07-29  8:42   ` Michael Nazzareno Trimarchi
2019-07-29 12:18     ` Greg Ungerer
2019-07-29 12:20       ` Michael Nazzareno Trimarchi
2019-07-29 12:33   ` Greg Ungerer
2019-07-29 12:47     ` Miquel Raynal
2019-07-29 12:49       ` Michael Nazzareno Trimarchi
2019-07-29 12:55         ` Miquel Raynal
2019-07-29 13:00           ` Michael Nazzareno Trimarchi
2019-07-29 13:22             ` Miquel Raynal
2019-07-29 20:00               ` Michael Nazzareno Trimarchi
2019-07-29 21:02                 ` Miquel Raynal
2019-07-30  0:28       ` Greg Ungerer
2019-07-30  0:41         ` Greg Ungerer
2019-07-30  6:06           ` Greg Ungerer
2019-07-30  8:38             ` Miquel Raynal
2019-07-30  8:58               ` Boris Brezillon
2019-07-31  2:05               ` Greg Ungerer
2019-07-31  6:28                 ` Boris Brezillon
2019-08-02  7:19                   ` Greg Ungerer
2019-08-02 12:34                   ` Greg Ungerer
2019-08-02 12:51                     ` Boris Brezillon
2019-08-05  5:51                       ` Greg Ungerer
2019-08-07 16:05                         ` Miquel Raynal
2019-08-08  0:43                           ` Greg Ungerer
2019-08-08 16:36                         ` Boris Brezillon
2019-08-09  5:20                           ` Greg Ungerer
2019-08-09  6:23                             ` Boris Brezillon
2019-08-09  6:55                               ` Greg Ungerer
2019-08-09  7:32                                 ` Boris Brezillon
2019-08-09 13:57                                   ` Greg Ungerer
2019-08-09 13:59                                     ` Boris Brezillon
2019-08-12  2:50                                       ` Greg Ungerer
2019-08-12  4:04                                         ` Greg Ungerer
2019-08-12  7:31                                         ` Boris Brezillon
2019-08-13  0:50                                           ` Greg Ungerer
2021-01-28  9:45                                             ` Michael Nazzareno Trimarchi
2021-01-28 10:26                                               ` Miquel Raynal
2021-01-28 10:35                                                 ` Michael Nazzareno Trimarchi
2021-01-28 11:55                                                   ` Michael Nazzareno Trimarchi
2021-01-29 12:43                                               ` Greg Ungerer
2021-01-30  9:41                                                 ` Michael Nazzareno Trimarchi
2021-02-01 14:13                                                   ` Miquel Raynal
2021-02-01 14:32                                                     ` Michael Nazzareno Trimarchi
2021-02-01 15:08                                                       ` Michael Nazzareno Trimarchi
2021-02-01 15:14                                                         ` Miquel Raynal
2021-02-01 15:17                                                           ` Michael Nazzareno Trimarchi
2021-10-15 20:05                                                           ` Michael Trimarchi
2021-10-15 20:12                                                             ` Michael Nazzareno Trimarchi
2021-10-18  7:19                                                             ` Miquel Raynal
2021-10-18  7:33                                                               ` Michael Nazzareno Trimarchi
2021-10-18  7:43                                                                 ` Miquel Raynal
2021-10-04  5:54 ` Christian Eggers
2021-10-04  6:27   ` Michael Nazzareno Trimarchi
2021-10-04 15:33     ` Miquel Raynal
2021-10-04 16:06       ` Han Xu
2021-10-05  6:02         ` Christian Eggers
2021-10-08  9:55         ` Christian Eggers
2021-10-08 12:08           ` Stefan Riedmüller
2021-10-08 12:27             ` Miquel Raynal
2021-10-08 13:11               ` Christian Eggers
2021-10-08 13:29                 ` Miquel Raynal
2021-10-08 13:36                   ` Miquel Raynal
2021-10-08 13:49                     ` Christian Eggers
2021-10-08 16:07                       ` Miquel Raynal
2021-10-09  5:53                         ` Michael Nazzareno Trimarchi
2021-10-11  6:46                           ` Miquel Raynal
2021-10-12  9:02                             ` [RFC PATCH 1/2] mtd: rawnand: gpmi: Remove explicit default gpmi clock setting for i.MX6 Stefan Riedmueller
2021-10-12  9:02                               ` [RFC PATCH 2/2] gpmi-nand: Add ERR007117 protection for nfc_apply_timings Stefan Riedmueller
2021-10-13  5:01                                 ` Han Xu
2021-10-22  8:45                                   ` Stefan Riedmüller
2021-10-22 14:35                                     ` han.xu
2021-10-25  9:39                                       ` Stefan Riedmüller
2021-10-28  9:28                                       ` Stefan Riedmüller
2021-11-01  4:01                                         ` han.xu
2021-10-13  6:10                                 ` Christian Eggers
2021-10-13  6:00                               ` [RFC PATCH 1/2] mtd: rawnand: gpmi: Remove explicit default gpmi clock setting for i.MX6 Christian Eggers
2021-10-09  6:26                         ` GPMI iMX6ull timeout on DMA Christian Eggers
2021-10-13  6:15                           ` Christian Eggers
2021-10-08 13:13               ` Christian Eggers
2021-10-08 13:30                 ` Miquel Raynal
2021-10-09  6:33             ` Christian Eggers
  -- strict thread matches above, loose matches on Subject: below --
2018-10-02 13:22 GPMI IMX6ull timeout on dma Michael Nazzareno Trimarchi
2018-10-04 14:36 ` Michael Nazzareno Trimarchi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).