Linux-mtd Archive on lore.kernel.org
 help / color / Atom feed
* i.MX28 nand driver broken in Linux 4.18
@ 2019-02-08  9:27 Wolfgang Grandegger
  2019-03-04 11:54 ` Miquel Raynal
  0 siblings, 1 reply; 9+ messages in thread
From: Wolfgang Grandegger @ 2019-02-08  9:27 UTC (permalink / raw)
  To: linux-mtd

Hello,

I'm upgrading the BSP of my i.MX28 board to Linux 4.18. Unfortunately,
the NAND driver does not working any longer. Here is the output of
"nandtest" including the kernel messages:

  root@m28evk:~# nandtest -k /dev/mtd3 
  ECC corrections: 0
  ECC failures   : 0
  Bad blocks     : 0
  BBT blocks     : 0
  00000000: reading (2 of 4)...gpmi-nand 8000c000.gpmi-nand: DMA timeout, last DMA
  gpmi-nand 8000c000.gpmi-nand: Show GPMI registers :
  gpmi-nand 8000c000.gpmi-nand: offset 0x000 : 0x2180083e
  gpmi-nand 8000c000.gpmi-nand: offset 0x010 : 0x00000000
  gpmi-nand 8000c000.gpmi-nand: offset 0x020 : 0x000011ff
  gpmi-nand 8000c000.gpmi-nand: offset 0x030 : 0x0000083e
  gpmi-nand 8000c000.gpmi-nand: offset 0x040 : 0x44dc0800
  gpmi-nand 8000c000.gpmi-nand: offset 0x050 : 0x46800800
  gpmi-nand 8000c000.gpmi-nand: offset 0x060 : 0x0104000c
  gpmi-nand 8000c000.gpmi-nand: offset 0x070 : 0x00010101
  gpmi-nand 8000c000.gpmi-nand: offset 0x080 : 0x90000000
  gpmi-nand 8000c000.gpmi-nand: offset 0x090 : 0x09020101
  gpmi-nand 8000c000.gpmi-nand: offset 0x0a0 : 0x01000030
  gpmi-nand 8000c000.gpmi-nand: offset 0x0b0 : 0x0f000003
  gpmi-nand 8000c000.gpmi-nand: offset 0x0c0 : 0x00000000
  gpmi-nand 8000c000.gpmi-nand: offset 0x0d0 : 0x03010000
  gpmi-nand 8000c000.gpmi-nand: Show BCH registers :
  gpmi-nand 8000c000.gpmi-nand: offset 0x000 : 0x00000100
  gpmi-nand 8000c000.gpmi-nand: offset 0x010 : 0x0000fe04
  gpmi-nand 8000c000.gpmi-nand: offset 0x020 : 0x00000000
  gpmi-nand 8000c000.gpmi-nand: offset 0x030 : 0x00000000
  gpmi-nand 8000c000.gpmi-nand: offset 0x040 : 0x00000000
  gpmi-nand 8000c000.gpmi-nand: offset 0x050 : 0x00000000
  gpmi-nand 8000c000.gpmi-nand: offset 0x060 : 0x00000000
  gpmi-nand 8000c000.gpmi-nand: offset 0x070 : 0x00000000
  gpmi-nand 8000c000.gpmi-nand: offset 0x080 : 0x030a4200
  gpmi-nand 8000c000.gpmi-nand: offset 0x090 : 0x083e4200
  gpmi-nand 8000c000.gpmi-nand: offset 0x0a0 : 0x070a8200
  gpmi-nand 8000c000.gpmi-nand: offset 0x0b0 : 0x10da8200
  gpmi-nand 8000c000.gpmi-nand: offset 0x0c0 : 0x070a8200
  gpmi-nand 8000c000.gpmi-nand: offset 0x0d0 : 0x10da8200
  gpmi-nand 8000c000.gpmi-nand: offset 0x0e0 : 0x070a8200
  gpmi-nand 8000c000.gpmi-nand: offset 0x0f0 : 0x10da8200
  gpmi-nand 8000c000.gpmi-nand: offset 0x100 : 0x00000000
  gpmi-nand 8000c000.gpmi-nand: offset 0x110 : 0x00000000
  gpmi-nand 8000c000.gpmi-nand: offset 0x120 : 0x00000000
  gpmi-nand 8000c000.gpmi-nand: offset 0x130 : 0x00000000
  gpmi-nand 8000c000.gpmi-nand: offset 0x140 : 0x00000000
  gpmi-nand 8000c000.gpmi-nand: offset 0x150 : 0x20484342
  gpmi-nand 8000c000.gpmi-nand: offset 0x160 : 0x01000000
  gpmi-nand 8000c000.gpmi-nand: offset 0x170 : 0x00000000
  gpmi-nand 8000c000.gpmi-nand: BCH Geometry :
  GF length              : 13
  ECC Strength           : 8
  Page Size in Bytes     : 2110
  Metadata Size in Bytes : 10
  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
  gpmi-nand 8000c000.gpmi-nand: Chip: 0, Error -22
  gpmi-nand 8000c000.gpmi-nand: Chip: 0, Error -22
  gpmi-nand 8000c000.gpmi-nand: Chip: 0, Error -22
  gpmi-nand 8000c000.gpmi-nand: Chip: 0, Error -22
  gpmi-nand 8000c000.gpmi-nand: Chip: 0, Error -22
  gpmi-nand 8000c000.gpmi-nand: Chip: 0, Error -22
  gpmi-nand 8000c000.gpmi-nand: Chip: 0, Error -22
  gpmi-nand 8000c000.gpmi-nand: Chip: 0, Error -22
  gpmi-nand 8000c000.gpmi-nand: Chip: 0, Error -22
  gpmi-nand 8000c000.gpmi-nand: Chip: 0, Error -22
  gpmi-nand 8000c000.gpmi-nand: Error in ECC-based read: -22
  00000000: reading (3 of 4)...gpmi-nand 8000c000.gpmi-nand: Chip: 0, Error -22
  gpmi-nand 8000c000.gpmi-nand: Chip: 0, Error -22
  gpmi-nand 8000c000.gpmi-nand: Error in ECC-based read: -22
  00000000: reading (4 of 4)...gpmi-nand 8000c000.gpmi-nand: Chip: 0, Error -22
  gpmi-nand 8000c000.gpmi-nand: Chip: 0, Error -22
  gpmi-nand 8000c000.gpmi-nand: Error in ECC-based read: -22
  00000000: erasing... gpmi-nand 8000c000.gpmi-nand: Chip: 0, Error -22
  gpmi-nand 8000c000.gpmi-nand: Chip: 0, Error -22
  gpmi-nand 8000c000.gpmi-nand: Chip: 0, Error -22
  gpmi-nand 8000c000.gpmi-nand: Chip: 0, Error -22
  00000000: writing...gpmi-nand 8000c000.gpmi-nand: Chip: 0, Error -22
  gpmi-nand 8000c000.gpmi-nand: Chip: 0, Error -22
  gpmi-nand 8000c000.gpmi-nand: Error in ECC-based write: -22

  write: Invalid argument
  ...

I have already applied the patch: 

  [PATCH] mtd: rawnand: gpmi: fix MX28 bus master lockup problem

but it didn't help. It works fine with Linux 4.14. Are there any known
issues with 4.18?

Thanks,

Wolfgang.

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

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

* Re: i.MX28 nand driver broken in Linux 4.18
  2019-02-08  9:27 i.MX28 nand driver broken in Linux 4.18 Wolfgang Grandegger
@ 2019-03-04 11:54 ` Miquel Raynal
  2019-03-04 20:46   ` Wolfgang Grandegger
  0 siblings, 1 reply; 9+ messages in thread
From: Miquel Raynal @ 2019-03-04 11:54 UTC (permalink / raw)
  To: Wolfgang Grandegger; +Cc: linux-mtd

Hi Wolfgang,

Wolfgang Grandegger <wg@grandegger.com> wrote on Fri, 8 Feb 2019
10:27:19 +0100:

> Hello,
> 
> I'm upgrading the BSP of my i.MX28 board to Linux 4.18. Unfortunately,
> the NAND driver does not working any longer. Here is the output of
> "nandtest" including the kernel messages:
> 

Could you find a solution or at least bisected and found the culprit?

Thanks,
Miquèl

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

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

* Re: i.MX28 nand driver broken in Linux 4.18
  2019-03-04 11:54 ` Miquel Raynal
@ 2019-03-04 20:46   ` Wolfgang Grandegger
  2019-03-05 14:52     ` Wolfgang Grandegger
  0 siblings, 1 reply; 9+ messages in thread
From: Wolfgang Grandegger @ 2019-03-04 20:46 UTC (permalink / raw)
  To: linux-mtd

Hello Miquel,

I didn't have time to investigate but I switched back to 4.14.

Wolfgang

Am 04.03.19 um 12:54 schrieb Miquel Raynal:
> Hi Wolfgang,
> 
> Wolfgang Grandegger <wg@grandegger.com> wrote on Fri, 8 Feb 2019
> 10:27:19 +0100:
> 
>> Hello,
>>
>> I'm upgrading the BSP of my i.MX28 board to Linux 4.18. Unfortunately,
>> the NAND driver does not working any longer. Here is the output of
>> "nandtest" including the kernel messages:
>>
> 
> Could you find a solution or at least bisected and found the culprit?
> 
> Thanks,
> Miquèl
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

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

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

* Re: i.MX28 nand driver broken in Linux 4.18
  2019-03-04 20:46   ` Wolfgang Grandegger
@ 2019-03-05 14:52     ` Wolfgang Grandegger
  2019-03-06 13:59       ` Miquel Raynal
  0 siblings, 1 reply; 9+ messages in thread
From: Wolfgang Grandegger @ 2019-03-05 14:52 UTC (permalink / raw)
  To: linux-mtd

Hello,

I will bisect the problem next week when I have access to the
hardware... more soon...

Wolfgang.

Am 04.03.19 um 21:46 schrieb Wolfgang Grandegger:
> Hello Miquel,
> 
> I didn't have time to investigate but I switched back to 4.14.
> 
> Wolfgang
> 
> Am 04.03.19 um 12:54 schrieb Miquel Raynal:
>> Hi Wolfgang,
>>
>> Wolfgang Grandegger <wg@grandegger.com> wrote on Fri, 8 Feb 2019
>> 10:27:19 +0100:
>>
>>> Hello,
>>>
>>> I'm upgrading the BSP of my i.MX28 board to Linux 4.18. Unfortunately,
>>> the NAND driver does not working any longer. Here is the output of
>>> "nandtest" including the kernel messages:
>>>
>>
>> Could you find a solution or at least bisected and found the culprit?
>>
>> Thanks,
>> Miquèl
>>
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

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

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

* Re: i.MX28 nand driver broken in Linux 4.18
  2019-03-05 14:52     ` Wolfgang Grandegger
@ 2019-03-06 13:59       ` Miquel Raynal
  2019-03-23 19:55         ` Wolfgang Grandegger
  0 siblings, 1 reply; 9+ messages in thread
From: Miquel Raynal @ 2019-03-06 13:59 UTC (permalink / raw)
  To: Wolfgang Grandegger; +Cc: Richard Weinberger, linux-mtd, Boris Brezillon

Hi Wolfgang,

Wolfgang Grandegger <wg@grandegger.com> wrote on Tue, 5 Mar 2019
15:52:52 +0100:

> Hello,
> 
> I will bisect the problem next week when I have access to the
> hardware... more soon...
> 

Great, thanks.

Please don't forget to keep MTD maintainers in Cc: to speed up the
discussion.

Thanks,
Miquèl

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

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

* Re: i.MX28 nand driver broken in Linux 4.18
  2019-03-06 13:59       ` Miquel Raynal
@ 2019-03-23 19:55         ` Wolfgang Grandegger
  2019-04-01  9:23           ` Miquel Raynal
  0 siblings, 1 reply; 9+ messages in thread
From: Wolfgang Grandegger @ 2019-03-23 19:55 UTC (permalink / raw)
  To: Miquel Raynal; +Cc: Richard Weinberger, linux-mtd, Boris Brezillon

Hello Miquel,

Am 06.03.19 um 14:59 schrieb Miquel Raynal:
> Hi Wolfgang,
> 
> Wolfgang Grandegger <wg@grandegger.com> wrote on Tue, 5 Mar 2019
> 15:52:52 +0100:
> 
>> Hello,
>>
>> I will bisect the problem next week when I have access to the
>> hardware... more soon...
>>
> 
> Great, thanks.

Here is the result of git bisection:

wolf@bernex:~/git/linux$ git bisect good
76e1a0086a0c3276b384f77905345e0fcc886fdd is the first bad commit
commit 76e1a0086a0c3276b384f77905345e0fcc886fdd
Author: Miquel Raynal <miquel.raynal@bootlin.com>
Date:   Fri Mar 2 15:38:39 2018 +0100

    mtd: rawnand: gpmi: support ->setup_data_interface()
    
    Until now the GPMI driver had its own timings logic while the core
    already handles that and request the NAND controller drivers to support
    the ->setup_data_interface() hook. Implement that hook by reusing the
    already existing function. No real glue is necessary between core timing
    delays and GPMI registers because the driver already translates the
    ONFI timing modes into register values.
    
    Make use of the core's tREA, tRLOH and tRHOH values that allow computing
    more precise timings for mode [0-3] and get significantly better values
    (+20% with an i.MX6 Sabre Auto board). Otherwise use the existing logic.
    
    Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
    Tested-by: Han Xu <han.xu@nxp.com>
    Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>

:040000 040000 938baf080db67ef7af38509421e11704da11baca 7f792706ecdd81977373dc8f44cccf28280f12ba M	drivers

At the end, I have added the full "git biscect log".

> 
> Please don't forget to keep MTD maintainers in Cc: to speed up the
> discussion.

OK.

wolf@bernex:~/git/linux$ git bisect log
# bad: [94710cac0ef4ee177a63b5227664b38c95bbf703] Linux 4.18
# good: [bebc6082da0a9f5d47a1ea2edc099bf671058bd4] Linux 4.14
git bisect start '94710cac0ef4ee177a63b5227664b38c95bbf703' 'bebc6082da0a9f5d47a1ea2edc099bf671058bd4'
# good: [053533fc7577ddbe14b2a7c4a8fc70ce3fbb3547] selftests: rtnetlink: remove testns on test fail
git bisect good 053533fc7577ddbe14b2a7c4a8fc70ce3fbb3547
# bad: [a1a3a0624e6cd0e2c46a7400800a5e687521a504] perf kcore_copy: Copy x86 PTI entry trampoline sections
git bisect bad a1a3a0624e6cd0e2c46a7400800a5e687521a504
# good: [9abf8acea297b4c65f5fa3206e2b8e468e730e84] Merge tag 'tty-4.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
git bisect good 9abf8acea297b4c65f5fa3206e2b8e468e730e84
# bad: [299f89d53e61c0b17479cc7d6f3b5382d5e83f28] Merge tag 'leaks-4.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tobin/leaks
git bisect bad 299f89d53e61c0b17479cc7d6f3b5382d5e83f28
# good: [274c0e74e508c939a4ae5ef3890fddb4af537b76] Merge tag 'f2fs-for-4.17' of git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs
git bisect good 274c0e74e508c939a4ae5ef3890fddb4af537b76
# good: [b240b419db5d624ce7a5a397d6f62a1a686009ec] Merge tag 'armsoc-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect good b240b419db5d624ce7a5a397d6f62a1a686009ec
# bad: [3b54765cca23152ec0cc254b75c877c10f6e2870] Merge branch 'akpm' (patches from Andrew)
git bisect bad 3b54765cca23152ec0cc254b75c877c10f6e2870
# good: [38c23685b273cfb4ccf31a199feccce3bdcb5d83] Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
git bisect good 38c23685b273cfb4ccf31a199feccce3bdcb5d83
# bad: [3fd14cdcc05a682b03743683ce3a726898b20555] Merge tag 'mtd/for-4.17' of git://git.infradead.org/linux-mtd
git bisect bad 3fd14cdcc05a682b03743683ce3a726898b20555
# bad: [097ccca726ffedb277c104aba45c59d075969e51] mtd: nand: Fix some function description mismatches in core.c
git bisect bad 097ccca726ffedb277c104aba45c59d075969e51
# good: [ecc40b8df59a13dc1c1abd8abe4361e4160d29ea] mtd: rawnand: vf610_nfc: remove old hooks
git bisect good ecc40b8df59a13dc1c1abd8abe4361e4160d29ea
# good: [480139d9229e3be0530bc548da208b5f49b1ab90] mtd: rawnand: get rid of the JEDEC parameter page in nand_chip
git bisect good 480139d9229e3be0530bc548da208b5f49b1ab90
# bad: [4acc3046ed5c1641874b89fe66ef8707d81ff80e] mtd: rawnand: davinci: fix probe function error path
git bisect bad 4acc3046ed5c1641874b89fe66ef8707d81ff80e
# bad: [961ba15c48dd465fdbef1b9379bd8031c374d62e] mtd: rawnand: marvell: Fix clock resource by adding a register clock
git bisect bad 961ba15c48dd465fdbef1b9379bd8031c374d62e
# bad: [76e1a0086a0c3276b384f77905345e0fcc886fdd] mtd: rawnand: gpmi: support ->setup_data_interface()
git bisect bad 76e1a0086a0c3276b384f77905345e0fcc886fdd
# good: [bd0b64340c2d66c0fe1aa99b0b23159d7e0c21f2] mtd: rawnand: get rid of the ONFI parameter page in nand_chip
git bisect good bd0b64340c2d66c0fe1aa99b0b23159d7e0c21f2
# first bad commit: [76e1a0086a0c3276b384f77905345e0fcc886fdd] mtd: rawnand: gpmi: support ->setup_data_interface()

Hope it helps to locate the problem.

Wolfgang

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

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

* Re: i.MX28 nand driver broken in Linux 4.18
  2019-03-23 19:55         ` Wolfgang Grandegger
@ 2019-04-01  9:23           ` Miquel Raynal
  2019-04-01 20:08             ` Wolfgang Grandegger
  0 siblings, 1 reply; 9+ messages in thread
From: Miquel Raynal @ 2019-04-01  9:23 UTC (permalink / raw)
  To: Wolfgang Grandegger; +Cc: Richard Weinberger, linux-mtd, Boris Brezillon

Hi Wolfgang,

Wolfgang Grandegger <wg@grandegger.com> wrote on Sat, 23 Mar 2019
20:55:19 +0100:

> Hello Miquel,
> 
> Am 06.03.19 um 14:59 schrieb Miquel Raynal:
> > Hi Wolfgang,
> > 
> > Wolfgang Grandegger <wg@grandegger.com> wrote on Tue, 5 Mar 2019
> > 15:52:52 +0100:
> >   
> >> Hello,
> >>
> >> I will bisect the problem next week when I have access to the
> >> hardware... more soon...
> >>  
> > 
> > Great, thanks.  
> 
> Here is the result of git bisection:
> 
> wolf@bernex:~/git/linux$ git bisect good
> 76e1a0086a0c3276b384f77905345e0fcc886fdd is the first bad commit
> commit 76e1a0086a0c3276b384f77905345e0fcc886fdd
> Author: Miquel Raynal <miquel.raynal@bootlin.com>
> Date:   Fri Mar 2 15:38:39 2018 +0100
> 
>     mtd: rawnand: gpmi: support ->setup_data_interface()
>     
>     Until now the GPMI driver had its own timings logic while the core
>     already handles that and request the NAND controller drivers to support
>     the ->setup_data_interface() hook. Implement that hook by reusing the
>     already existing function. No real glue is necessary between core timing
>     delays and GPMI registers because the driver already translates the
>     ONFI timing modes into register values.
>     
>     Make use of the core's tREA, tRLOH and tRHOH values that allow computing
>     more precise timings for mode [0-3] and get significantly better values
>     (+20% with an i.MX6 Sabre Auto board). Otherwise use the existing logic.
>     
>     Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
>     Tested-by: Han Xu <han.xu@nxp.com>
>     Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>

Thank you for the bisection, there is definitely something wrong with
this commit but it worked for me and for Han so it's quite difficult to
find out what is failing if I cannot reproduce. Could you please dump
the timing registers in both cases (working/not working) and observer if
there are odd values ? (0, too short or too big values, etc).


Thanks,
Miquèl

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

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

* Re: i.MX28 nand driver broken in Linux 4.18
  2019-04-01  9:23           ` Miquel Raynal
@ 2019-04-01 20:08             ` Wolfgang Grandegger
  2019-04-02  9:16               ` Miquel Raynal
  0 siblings, 1 reply; 9+ messages in thread
From: Wolfgang Grandegger @ 2019-04-01 20:08 UTC (permalink / raw)
  To: Miquel Raynal; +Cc: Richard Weinberger, linux-mtd, Boris Brezillon

Hello Miquel;

Am 01.04.19 um 11:23 schrieb Miquel Raynal:
> Hi Wolfgang,
> 
> Wolfgang Grandegger <wg@grandegger.com> wrote on Sat, 23 Mar 2019
> 20:55:19 +0100:
> 
>> Hello Miquel,
>>
>> Am 06.03.19 um 14:59 schrieb Miquel Raynal:
>>> Hi Wolfgang,
>>>
>>> Wolfgang Grandegger <wg@grandegger.com> wrote on Tue, 5 Mar 2019
>>> 15:52:52 +0100:
>>>   
>>>> Hello,
>>>>
>>>> I will bisect the problem next week when I have access to the
>>>> hardware... more soon...
>>>>  
>>>
>>> Great, thanks.  
>>
>> Here is the result of git bisection:
>>
>> wolf@bernex:~/git/linux$ git bisect good
>> 76e1a0086a0c3276b384f77905345e0fcc886fdd is the first bad commit
>> commit 76e1a0086a0c3276b384f77905345e0fcc886fdd
>> Author: Miquel Raynal <miquel.raynal@bootlin.com>
>> Date:   Fri Mar 2 15:38:39 2018 +0100
>>
>>     mtd: rawnand: gpmi: support ->setup_data_interface()
>>     
>>     Until now the GPMI driver had its own timings logic while the core
>>     already handles that and request the NAND controller drivers to support
>>     the ->setup_data_interface() hook. Implement that hook by reusing the
>>     already existing function. No real glue is necessary between core timing
>>     delays and GPMI registers because the driver already translates the
>>     ONFI timing modes into register values.
>>     
>>     Make use of the core's tREA, tRLOH and tRHOH values that allow computing
>>     more precise timings for mode [0-3] and get significantly better values
>>     (+20% with an i.MX6 Sabre Auto board). Otherwise use the existing logic.
>>     
>>     Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
>>     Tested-by: Han Xu <han.xu@nxp.com>
>>     Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
> 
> Thank you for the bisection, there is definitely something wrong with
> this commit but it worked for me and for Han so it's quite difficult to
> find out what is failing if I cannot reproduce. Could you please dump
> the timing registers in both cases (working/not working) and observer if
> there are odd values ? (0, too short or too big values, etc).

here are some first figures:

76e1a0086a0c3276b384f77905345e0fcc886fdd^:
[    1.911760] clock_period_in_ns : 41
[    1.922818] address_setup_in_cycles : 1
[    1.915343] data_setup_in_cycles : 3
[    1.919254] data_hold_in_cycles : 2
[    1.926709] HW_GPMI_TIMING0 : 0x10203
[    1.930641] HW_GPMI_TIMING1 : 0x5000000

v4.18:
[    2.090621] period_ps : 45454
[    2.076601] addr_setup_cycles : 1
[    2.080002] data_setup_cycles : 1
[    2.083598] data_hold_cycles : 1
[    2.093849] HW_GPMI_TIMING0 : 0x10101
[    2.096890] HW_GPMI_TIMING1 : 0x90000000

Hope that's what you are looking for. Unfortunately, the code of both
versions is very different (complete rewrite). I will have a closer look
tomorrow.

Wolfgang.

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

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

* Re: i.MX28 nand driver broken in Linux 4.18
  2019-04-01 20:08             ` Wolfgang Grandegger
@ 2019-04-02  9:16               ` Miquel Raynal
  0 siblings, 0 replies; 9+ messages in thread
From: Miquel Raynal @ 2019-04-02  9:16 UTC (permalink / raw)
  To: Wolfgang Grandegger; +Cc: Richard Weinberger, linux-mtd, Boris Brezillon

Hi Wolfgang,

Wolfgang Grandegger <wg@grandegger.com> wrote on Mon, 1 Apr 2019
22:08:45 +0200:

> Hello Miquel;
> 
> Am 01.04.19 um 11:23 schrieb Miquel Raynal:
> > Hi Wolfgang,
> > 
> > Wolfgang Grandegger <wg@grandegger.com> wrote on Sat, 23 Mar 2019
> > 20:55:19 +0100:
> >   
> >> Hello Miquel,
> >>
> >> Am 06.03.19 um 14:59 schrieb Miquel Raynal:  
> >>> Hi Wolfgang,
> >>>
> >>> Wolfgang Grandegger <wg@grandegger.com> wrote on Tue, 5 Mar 2019
> >>> 15:52:52 +0100:
> >>>     
> >>>> Hello,
> >>>>
> >>>> I will bisect the problem next week when I have access to the
> >>>> hardware... more soon...
> >>>>    
> >>>
> >>> Great, thanks.    
> >>
> >> Here is the result of git bisection:
> >>
> >> wolf@bernex:~/git/linux$ git bisect good
> >> 76e1a0086a0c3276b384f77905345e0fcc886fdd is the first bad commit
> >> commit 76e1a0086a0c3276b384f77905345e0fcc886fdd
> >> Author: Miquel Raynal <miquel.raynal@bootlin.com>
> >> Date:   Fri Mar 2 15:38:39 2018 +0100
> >>
> >>     mtd: rawnand: gpmi: support ->setup_data_interface()
> >>     
> >>     Until now the GPMI driver had its own timings logic while the core
> >>     already handles that and request the NAND controller drivers to support
> >>     the ->setup_data_interface() hook. Implement that hook by reusing the
> >>     already existing function. No real glue is necessary between core timing
> >>     delays and GPMI registers because the driver already translates the
> >>     ONFI timing modes into register values.
> >>     
> >>     Make use of the core's tREA, tRLOH and tRHOH values that allow computing
> >>     more precise timings for mode [0-3] and get significantly better values
> >>     (+20% with an i.MX6 Sabre Auto board). Otherwise use the existing logic.
> >>     
> >>     Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> >>     Tested-by: Han Xu <han.xu@nxp.com>
> >>     Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>  
> > 
> > Thank you for the bisection, there is definitely something wrong with
> > this commit but it worked for me and for Han so it's quite difficult to
> > find out what is failing if I cannot reproduce. Could you please dump
> > the timing registers in both cases (working/not working) and observer if
> > there are odd values ? (0, too short or too big values, etc).  
> 
> here are some first figures:
> 
> 76e1a0086a0c3276b384f77905345e0fcc886fdd^:
> [    1.911760] clock_period_in_ns : 41
> [    1.922818] address_setup_in_cycles : 1
> [    1.915343] data_setup_in_cycles : 3
> [    1.919254] data_hold_in_cycles : 2
> [    1.926709] HW_GPMI_TIMING0 : 0x10203
> [    1.930641] HW_GPMI_TIMING1 : 0x5000000
> 
> v4.18:
> [    2.090621] period_ps : 45454
> [    2.076601] addr_setup_cycles : 1
> [    2.080002] data_setup_cycles : 1
> [    2.083598] data_hold_cycles : 1
> [    2.093849] HW_GPMI_TIMING0 : 0x10101
> [    2.096890] HW_GPMI_TIMING1 : 0x90000000
> 
> Hope that's what you are looking for. Unfortunately, the code of both
> versions is very different (complete rewrite). I will have a closer look
> tomorrow.

Just looking at these values it does not look like there is a big
difference...

Can you please force the timing registers to working values (taken from
v4.18) to be sure the problem comes from the derivations made in
->setup_data_interface() and not something else?

Also, in setup_data_interface(), you may refuse to support the highest
modes (4 and 5) and observe if it solves something? I would test:
forcing to maximum mode 4, 3 and 0. Please continue to dump the above
values/registers to compare.

Thanks for your time,
Miquèl

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

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

end of thread, back to index

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-08  9:27 i.MX28 nand driver broken in Linux 4.18 Wolfgang Grandegger
2019-03-04 11:54 ` Miquel Raynal
2019-03-04 20:46   ` Wolfgang Grandegger
2019-03-05 14:52     ` Wolfgang Grandegger
2019-03-06 13:59       ` Miquel Raynal
2019-03-23 19:55         ` Wolfgang Grandegger
2019-04-01  9:23           ` Miquel Raynal
2019-04-01 20:08             ` Wolfgang Grandegger
2019-04-02  9:16               ` Miquel Raynal

Linux-mtd Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-mtd/0 linux-mtd/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-mtd linux-mtd/ https://lore.kernel.org/linux-mtd \
		linux-mtd@lists.infradead.org linux-mtd@archiver.kernel.org
	public-inbox-index linux-mtd


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-mtd


AGPL code for this site: git clone https://public-inbox.org/ public-inbox