Re: [PATCH 11/13] mtd: spinand: Add support for Power-on-Reset (PoR) instruction

From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Apurva Nandan <a-nandan@ti.com>
Cc: Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Mark Brown <broonie@kernel.org>,
	Patrice Chotard <patrice.chotard@foss.st.com>,
	Boris Brezillon <boris.brezillon@collabora.com>,
	<linux-mtd@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
	<linux-spi@vger.kernel.org>, Pratyush Yadav <p.yadav@ti.com>
Subject: Re: [PATCH 11/13] mtd: spinand: Add support for Power-on-Reset (PoR) instruction
Date: Fri, 20 Aug 2021 14:18:22 +0200	[thread overview]
Message-ID: <20210820141822.03d658b8@xps13> (raw)
In-Reply-To: <403a2b26-fd95-31ab-8992-a6e6862249e6@ti.com>

Hi Apurva,

Apurva Nandan <a-nandan@ti.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@ti.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@ti.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.

Otherwise the best is to have some kind of signaling but I'm not sure
you'll have one for the reset op...

> 
> >>    */
> >>   #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