[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c4a1eae9-7c0b-62c8-f10a-000e65c94f1b@ti.com>
Date: Fri, 20 Aug 2021 19:11:58 +0530
From: Apurva Nandan <a-nandan@...com>
To: Miquel Raynal <miquel.raynal@...tlin.com>
CC: Richard Weinberger <richard@....at>,
Vignesh Raghavendra <vigneshr@...com>,
Mark Brown <broonie@...nel.org>,
Patrice Chotard <patrice.chotard@...s.st.com>,
Boris Brezillon <boris.brezillon@...labora.com>,
<linux-mtd@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
<linux-spi@...r.kernel.org>, Pratyush Yadav <p.yadav@...com>
Subject: Re: [PATCH 11/13] mtd: spinand: Add support for Power-on-Reset (PoR)
instruction
Hi Miquèl,
On 20/08/21 5:48 pm, Miquel Raynal wrote:
> Hi Apurva,
>
> Apurva Nandan <a-nandan@...com> wrote on Fri, 20 Aug 2021 17:09:07
> +0530:
>
>> Hi Miquèl,
>>
>> On 07/08/21 12:38 am, Miquel Raynal wrote:
>>> Hi Apurva,
>>>
>>> Apurva Nandan <a-nandan@...com> wrote on Tue, 13 Jul 2021 13:05:36
>>> +0000:
>>>
>>>> Manufacturers like Gigadevice and Winbond are adding Power-on-Reset
>>>> functionality in their SPI NAND flash chips. PoR instruction consists
>>>> of a 66h command followed by 99h command, and is different from the FFh
>>>> reset. The reset command FFh just clears the status only registers,
>>>> while the PoR command erases all the configurations written to the
>>>> flash and is equivalent to a power-down -> power-up cycle.
>>>>
>>>> Add support for the Power-on-Reset command for any flash that provides
>>>> this feature.
>>>>
>>>> Datasheet: https://www.winbond.com/export/sites/winbond/datasheet/W35N01JW_Datasheet_Brief.pdf
>>>>
>>>> Signed-off-by: Apurva Nandan <a-nandan@...com>
>>>> ---
>>>
>>> [...]
>>> \
>>>> @@ -218,6 +230,8 @@ struct spinand_device;
>>>> * reading/programming/erasing when the RESET occurs. Since we always
>>>> * issue a RESET when the device is IDLE, 5us is selected for both initial
>>>> * and poll delay.
>>>> + * Power on Reset can take max upto 500 us to complete, so sleep for 1000 us
>>>
>>> s/max upto/up to/
>>>
>>
>> Okay!
>>
>>>> + * to 1200 us safely.
>>>
>>> I don't really get why, if the maximum is 500, then let's wait for
>>> 500us.
>>>
>>
>> Generally we keep some margin from the maximum time, no?
>
> Well, yes and no.
>
> If you know that an operation will last Xms and have nothing else to
> do, then you can take some margin if you are in a probe (called once)
> but definitely not if you are in a fast path.
>
I think as PoR reset would be called at every mtd_suspend() call, so we
can reduce the delay. And we would be expecting some time gap before the
next mtd_resume() call.
> Otherwise the best is to have some kind of signaling but I'm not sure
> you'll have one for the reset op...
>
According to public datasheet, it doesn't set the busy bit during reset.
So do you suggest in the favor of removing the delay margin?
>>
>>>> */
>>>> #define SPINAND_READ_INITIAL_DELAY_US 6
>>>> #define SPINAND_READ_POLL_DELAY_US 5
>>>> @@ -227,6 +241,8 @@ struct spinand_device;
>>>> #define SPINAND_WRITE_POLL_DELAY_US 15
>>>> #define SPINAND_ERASE_INITIAL_DELAY_US 250
>>>> #define SPINAND_ERASE_POLL_DELAY_US 50
>>>> +#define SPINAND_POR_MIN_DELAY_US 1000
>>>> +#define SPINAND_POR_MAX_DELAY_US 1200
>>>> >> #define SPINAND_WAITRDY_TIMEOUT_MS 400
>>>> >> @@ -351,6 +367,7 @@ struct spinand_ecc_info {
>>>> #define SPINAND_HAS_QE_BIT BIT(0)
>>>> #define SPINAND_HAS_CR_FEAT_BIT BIT(1)
>>>> #define SPINAND_HAS_OCTAL_DTR_BIT BIT(2)
>>>> +#define SPINAND_HAS_POR_CMD_BIT BIT(3)
>>>> >> /**
>>>> * struct spinand_ondie_ecc_conf - private SPI-NAND on-die ECC engine structure
>>>
>>>
>>>
>>>
>>> Thanks,
>>> Miquèl
>>>
>>> ______________________________________________________
>>> Linux MTD discussion mailing list
>>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>>>
>>
>> Thanks,
>> Apurva Nandan
>
> Thanks,
> Miquèl
>
Thanks,
Apurva Nandan
Powered by blists - more mailing lists