[PATCH v3 3/3] mtd: nand: raw: atmel: Fix pulse read timing for certain NAND flashes

[Alexander Dahl]

Hello,

Am Tue, May 28, 2024 at 12:32:44PM +0200 schrieb Alexander Dahl:
> Hei hei,
> 
> Am Mon, Apr 15, 2024 at 09:57:55AM +0200 schrieb Alexander Dahl:
> > From reading the S34ML02G1 and the SAM9X60 datasheets again, it seems
> > like we have to wait tREA after rising RE# before sampling the data.
> > Thus pulse time must be at least tREA.
> > 
> > Without this fix we got PMECC errors when reading, after switching to
> > ONFI timing mode 3 on SAM9X60 SoC with S34ML02G1 raw NAND flash chip.
> > 
> > The approach to set timings used before worked on sam9g20 and sama5d2
> > with the same flash (S34ML02G1), probably because those have a slower
> > mck clock rate and thus the resolution of the timings setup is not as
> > tight as with sam9x60.
> > 
> > The approach to fix the issue was carried over from at91bootstrap, and
> > has been successfully tested in at91bootstrap, U-Boot and Linux.
> > 
> > Link: https://github.com/linux4sam/at91bootstrap/issues/174
> > Cc: Li Bin <bin.li at microchip.com>
> > Signed-off-by: Alexander Dahl <ada at thorsis.com>
> > ---
> > 
> > Notes:
> >     v3:
> >     - initial patch version (not present in v1 and v2)
> 
> This patch was send as part of a series, which you wanted to have some
> more time to test.  Besides that, has anyone looked into this
> particular fix?  Maybe it can be applied separately?

I'd kindly ask what the status of this patch series is from U-Boot
NAND subsystem maintainers POV?  Could you test it?  Should I rebase
and resend?

Two of these three patches are specific to at91 family, what's the
opinion of at91 maintainers on this?

Link to the series discussion for reference:

https://lore.kernel.org/u-boot/20240415074547.779264-1-ada@thorsis.com/T/#u

Greets
Alex

> 
> Greets
> Alex
> 
> > 
> >  drivers/mtd/nand/raw/atmel/nand-controller.c | 13 +++++++++----
> >  1 file changed, 9 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/mtd/nand/raw/atmel/nand-controller.c b/drivers/mtd/nand/raw/atmel/nand-controller.c
> > index bbafc88e44c..00ffeadd113 100644
> > --- a/drivers/mtd/nand/raw/atmel/nand-controller.c
> > +++ b/drivers/mtd/nand/raw/atmel/nand-controller.c
> > @@ -1133,7 +1133,7 @@ static int atmel_smc_nand_prepare_smcconf(struct atmel_nand *nand,
> >  					  const struct nand_data_interface *conf,
> >  					  struct atmel_smc_cs_conf *smcconf)
> >  {
> > -	u32 ncycles, totalcycles, timeps, mckperiodps;
> > +	u32 ncycles, totalcycles, timeps, mckperiodps, pulse;
> >  	struct atmel_nand_controller *nc;
> >  	int ret;
> >  
> > @@ -1259,11 +1259,16 @@ static int atmel_smc_nand_prepare_smcconf(struct atmel_nand *nand,
> >  			 ATMEL_SMC_MODE_TDFMODE_OPTIMIZED;
> >  
> >  	/*
> > -	 * Read pulse timing directly matches tRP:
> > +	 * Read pulse timing would directly match tRP,
> > +	 * but some NAND flash chips (S34ML01G2 and W29N02KVxxAF)
> > +	 * do not work properly in timing mode 3.
> > +	 * The workaround is to extend the SMC NRD pulse to meet tREA
> > +	 * timing.
> >  	 *
> > -	 * NRD_PULSE = tRP
> > +	 * NRD_PULSE = max(tRP, tREA)
> >  	 */
> > -	ncycles = DIV_ROUND_UP(conf->timings.sdr.tRP_min, mckperiodps);
> > +	pulse = max(conf->timings.sdr.tRP_min, conf->timings.sdr.tREA_max);
> > +	ncycles = DIV_ROUND_UP(pulse, mckperiodps);
> >  	totalcycles += ncycles;
> >  	ret = atmel_smc_cs_conf_set_pulse(smcconf, ATMEL_SMC_NRD_SHIFT,
> >  					  ncycles);
> > -- 
> > 2.39.2
> > 
>