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

Wed Feb 12 09:45:27 CET 2025

Hi Eugen

Please apply

Michael

On Wed, Feb 12, 2025 at 9:44 AM Eugen Hristev <eugen.hristev at linaro.org> wrote:
>
>
>
> On 2/12/25 09:09, Alexander Dahl wrote:
> > Hello,
> >
> > Am Wed, Oct 09, 2024 at 04:45:02AM +0000 schrieb Balamanikandan.Gunasundar at microchip.com:
> >> On 30/09/24 1:37 pm, Alexander Dahl wrote:
> >>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >>>
> >>> 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
> >>>
> >>
> >> Hi Alex,
> >>
> >> Apologies for the delay in response. I also faced the same kind of
> >> problem while testing our new sam7d65 board with MX30LF4G28AD nand
> >> flash. I just had a workaround to increase the pulse time by 5 nsecs
> >> just for testing. The issue has been reported to the validation team and
> >> an investigation is under progress.
> >>
> >> I would request a few more days for this patch alone.
> >
> > Why did the _same_ change I posted here last year in April appeared
> > in linux4sam now with different credits? o.O
> >
> > https://github.com/linux4sam/u-boot-at91/commit/4175c4c8535ea886e2c0fd99e94ead6bc7a4df5f
> >
> > For reference: the issue was discussed in length here before I made
> > the patch for U-Boot last year:
> >
> > https://github.com/linux4sam/at91bootstrap/issues/174
> >
> > Besides: this patch series was still not reviewed and not merged.
> > Dear U-Boot NAND subsystem maintainer, what's the status?
> >
> > Greets
> > Alex
>
> Hello Alex,
>
> As this change appeared downstream, apparently it's validated.
>
> I can apply this as a fix through at91 tree.
>
> Dario do you mind if I do that ? Apparently the patch is now on your list.
>
> Eugen
> >
> >>
> >> Thanks,
> >> Bala.
> >>
> >>>>
> >>>> 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
> >>>>>
> >>>>
> >>
>


-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
michael at amarulasolutions.com
__________________________________

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
info at amarulasolutions.com
www.amarulasolutions.com