[PATCH 0/2] mtd: nand: raw: atmel: R/B gpio on sam9x60

[Alexander Dahl]

Hello everyone,

this is a patch series wtih some real fixes _and_ a question or some
kind of support request in the cover letter.  I would be happy if anyone
could read the cover letter carefully and answer to that one what might
be the problem I see. O:-)

I'm currently working on the sam9x60-curiosity board and especially
trying to get it booting from onboard raw NAND flash.  As reported in my
last series I got the flash recognized already.  However interacting
with it was terribly slow, because nand_wait_ready() calling
atmel_nand_dev_ready() ran into a 400ms timeout in several occasions,
especially when reading from the device.  Reading a single block
triggered that timeout two times per page, which summed up to over 50
seconds for 64 × 4096 = 256k Bytes!

(You can have U-Boot print that warning from nand_wait_ready() by
increasing the console log level to at least "warn".)

Note: the dts from atmel/next seems correct to me, I double checked that
again.  My own debug log messages showed the GPIO is accessed, and if
you add enough debug messages sometimes the timeout is not reached, so
I'm sure the NAND chip eventually switches that R/B line and the code
correctly sees that, that line level change however takes ages,
something between 400ms and 500ms most of the times.

I vaguely remembered on SAMA5D2 the old atmel raw nand driver is used
which does not support reading the R/B signal, but nevertheless works.
I'm not familiar in detail with those raw NAND flash chips, but as far
as I can understand, there are other ways to determine if the chip is
ready or busy.  So after I removed that rb-gpio parameter from
'at91-sam9x60_curiosity.dts' I ran into the bug fixed by patch 2.

With that patch applied _and_ rb-gpio still removed from dts, raw NAND
access is reasonably fast on sam9x60-curiosity board.  (You might want
to rebase to atmel/next for testing this.)  Not sure if I should send a
patch for that dts change, because I suppose it's a workaround only and
not addressing the actual cause?

I think the fix is correct in itself, I tested different combinations
and compared with the driver in Linux, however …

Can anyone explain to me, why flash access is sooo slow if the R/B gpio
is used?  Especially in comparision to Linux, where I don't need to
remove that thing from dts and it works reasonably fast?

The actual flash chip is a Macronix MX30LF4G28AD, 512 MiB, SLC, erase
size: 256 KiB, page size: 4096, OOB size: 256.

Greets
Alex

P.S.: although not returned by get_maintainer.pl I added Eugen to Cc
because he is maintainer of the at91 and might have some insight if it
is a general problem of the nand controller in at91 socs?

Alexander Dahl (2):
  mtd: nand: raw: atmel: Remove duplicate line
  mtd: nand: raw: atmel: Add error handling when rb-gpios missing

 drivers/mtd/nand/raw/atmel/nand-controller.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)


base-commit: a169438411f9277cc689c14078151aa1d1caae3c
-- 
2.30.2