On 9/30/24 11:07, Alexander Dahl wrote: > 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...@microchip.com> >>> Signed-off-by: Alexander Dahl <a...@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?
Hello Alexander, >From at91 perspective I have no objections. As these are very NAND specific, I defer the patches to the NAND maintainers. Eugen > > Link to the series discussion for reference: > > https://lore.kernel.org/u-boot/20240415074547.779264-1-...@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 >>> >>
