slow performance for marvell+micron nand after upgrade to v4.19

[Zak Hays <zak.hays@xxxxxxxxxxx>]

Hello all,

After upgrading from v4.17 to v4.19, I see nearly 3x slower performance reading
from a 256M Micron part with the marvell-nand driver.

If I run a simple dd command while running 4.17 I get the following:

root@granite2:~# uname -r
4.17.19-yocto-standard-e84b95ca38008a00318ce62ef88c5220
root@granite2:~# time dd if=/dev/mtd0 of=/dev/null 
524288+0 records in
524288+0 records out

real    1m18.399s
user    0m0.179s
sys     1m17.904s

This timing is pretty consistent across multiple tests.

It should be noted that this is with nand-ecc-mode set to "hw".

When I upgraded to v4.19, I had to switch nand-ecc-mode over to "on-die" as trying to use "hw"
now throws an error after this series of commits:

    243f37cb1f63  Chris Packham  mtd: rawnand: micron: add fixup for ONFI revision
    872b71ff084a  Chris Packham  mtd: rawnand: add defines for ONFI version bits
    00ce4e039ad5  Chris Packham  mtd: rawnand: add manufacturer fixup for ONFI parameter page
    ed6d0285f81c  Chris Packham  mtd: rawnand: marvell: Handle on-die ECC

Running that same test as above, I see the following:

root@granite2:~# uname -r
4.19.82-yocto-standard-b66d2fc889af853949e4ada9b12c55b7
root@granite2:~# time dd if=/dev/mtd0 of=/dev/null 
524288+0 records in
524288+0 records out

real    3m34.116s
user    0m0.562s
sys     1m12.934s

This timing is again consistent across multiple tests and is roughly 3x the timing of v4.17.

A few questions I have:
- Is anybody else seeing this same issue? I'm curious if this is the case for all instances that use
the marvell nand driver or it is purely my combination of hardware.

- Is there a reason why ecc "hw" mode is not allowed if "on-die" is supported? I assume that both are
valid methods for error correction. Hardware ECC also seems like it would be preferable in some
situations where multiple nand parts may need to be supported and some of those may not necessarily
provide on-die support.

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