public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: <Balamanikandan.Gunasundar@microchip.com>
To: <dario.binacchi@amarulasolutions.com>,
	<michael@amarulasolutions.com>, <eugen.hristev@collabora.com>,
	<Mihai.Sain@microchip.com>, <Bin.Li@microchip.com>,
	<u-boot@lists.denx.de>, <Nicolas.Ferre@microchip.com>
Subject: Re: [PATCH v3 3/3] mtd: nand: raw: atmel: Fix pulse read timing for certain NAND flashes
Date: Wed, 9 Oct 2024 04:45:02 +0000	[thread overview]
Message-ID: <3a3cc57c-e696-408f-a050-39502081b6f3@microchip.com> (raw)
In-Reply-To: <20240930-pamperer-prance-8b4566ba43a6@thorsis.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@microchip.com>
>>> Signed-off-by: Alexander Dahl <ada@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.

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
>>>
>>


  parent reply	other threads:[~2024-10-09  4:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-15  7:45 [PATCH v3 0/3] mtd: nand: raw: Collected improvements Alexander Dahl
2024-04-15  7:45 ` [PATCH v3 1/3] mtd: nand: raw: atmel: Introduce optional debug commands Alexander Dahl
2024-04-15  7:45 ` [PATCH v3 2/3] cmd: nand: Add new optional sub-command 'onfi' Alexander Dahl
2024-04-15  7:57 ` [PATCH v3 3/3] mtd: nand: raw: atmel: Fix pulse read timing for certain NAND flashes Alexander Dahl
2024-05-28 10:32   ` Alexander Dahl
2024-09-30  8:07     ` Alexander Dahl
2024-10-08 11:41       ` Eugen Hristev
2024-10-08 12:12         ` Michael Nazzareno Trimarchi
2024-12-19  7:19           ` Alexander Dahl
2024-10-09  4:45       ` Balamanikandan.Gunasundar [this message]
2024-12-19  7:17         ` Alexander Dahl
2025-02-12  7:09         ` Alexander Dahl
2025-02-12  8:44           ` Eugen Hristev
2025-02-12  8:45             ` Michael Nazzareno Trimarchi
2025-02-12 16:12               ` Eugen Hristev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3a3cc57c-e696-408f-a050-39502081b6f3@microchip.com \
    --to=balamanikandan.gunasundar@microchip.com \
    --cc=Bin.Li@microchip.com \
    --cc=Mihai.Sain@microchip.com \
    --cc=Nicolas.Ferre@microchip.com \
    --cc=dario.binacchi@amarulasolutions.com \
    --cc=eugen.hristev@collabora.com \
    --cc=michael@amarulasolutions.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox