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

[Mihai.Sain at microchip.com]

Hi Alex,

Please find bellow my answer:

------------------------------

Added Mihai who tested this a lot at some point in time

Eugen

On 8/8/23 16:02, Alexander Dahl wrote:
> 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?

// I'm sorry for quoting (email is sent from Outlook)
# Please add in your board dts: atmel,rb = <0>
# nand at 3 {
#			reg = <0x3 0x0 0x800000>;
#			atmel,rb = <0>;
#			cs-gpios = <&pioD 4 GPIO_ACTIVE_HIGH>;
#			rb-gpios = <&pioD 5 GPIO_ACTIVE_HIGH>;
#			nand-bus-width = <8>;
#			nand-ecc-mode = "hw";
#			nand-ecc-strength = <8>;
#			nand-ecc-step-size = <512>;
#			nand-on-flash-bbt;>

> 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