Re: [PATCH 12/13] mtd: spinand: Perform Power-on-Reset when runtime_pm suspend is issued

From: Apurva Nandan <a-nandan@ti.com>
To: Miquel Raynal <miquel.raynal@bootlin.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 12/13] mtd: spinand: Perform Power-on-Reset when runtime_pm suspend is issued
Date: Fri, 20 Aug 2021 17:15:38 +0530	[thread overview]
Message-ID: <2437d7b9-2a01-28c7-9a81-f38c35f37964@ti.com> (raw)
In-Reply-To: <20210806211231.5c569939@xps13>

On 07/08/21 12:42 am, Miquel Raynal wrote:
> Hi Apurva,
> 
> Apurva Nandan <a-nandan@ti.com> wrote on Tue, 13 Jul 2021 13:05:37
> +0000:
> 
>> A soft reset using FFh command doesn't erase the flash's configuration
>> and doesn't reset the SPI IO mode also. This can result in the flash
>> being in a different SPI IO mode, e.g. Octal DTR, when resuming from
>> sleep. This would render the flash in an unusable state.
> 
>                could put the falsh in?
> 

Okay, will make it clearer.
Basically, we don't want the flash to be in an ambiguous state. It might 
or might not have undergone a power off during the suspend state. So, 
the spinand core wouldn't know if the flash is still in Octal DTR mode 
or not. If it is still in Octal DTR mode, then none of the SPI 
instruction during mtd_resume() would work. So this is an ambiguous 
situation for driver. To avoid this, perform a PoR reset before suspending.

>> Perform a Power-on-Reset (PoR), if available in the flash, when
>> suspending the device by runtime_pm. This would set the flash to clean
> 
> I think runtime_pm is something else.
> 

Yeah, will make it clearer.

>> state for reinitialization during resume and would also ensure that it
>> is in standard SPI IO mode (1S-1S-1S) before the resume begins.
> 
> Please add a comment about this to explain why we don't do this reset
> at resume time.
> 

Yes sure!

>>
>> Signed-off-by: Apurva Nandan <a-nandan@ti.com>
>> ---
>>   drivers/mtd/nand/spi/core.c | 16 ++++++++++++++++
>>   1 file changed, 16 insertions(+)
>>
>> diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
>> index 608f4eb85b0a..6fb3aa6af540 100644
>> --- a/drivers/mtd/nand/spi/core.c
>> +++ b/drivers/mtd/nand/spi/core.c
>> @@ -1329,6 +1329,21 @@ static void spinand_mtd_resume(struct mtd_info *mtd)
>>   	spinand_ecc_enable(spinand, false);
>>   }
>>   
>> +static int spinand_mtd_suspend(struct mtd_info *mtd)
>> +{
>> +	struct spinand_device *spinand = mtd_to_spinand(mtd);
>> +	int ret;
>> +
>> +	if (!(spinand->flags & SPINAND_HAS_POR_CMD_BIT))
>> +		return 0;
>> +
>> +	ret = spinand_power_on_rst_op(spinand);
>> +	if (ret)
>> +		dev_err(&spinand->spimem->spi->dev, "suspend() failed\n");
>> +
>> +	return ret;
>> +}
>> +
>>   static int spinand_init(struct spinand_device *spinand)
>>   {
>>   	struct device *dev = &spinand->spimem->spi->dev;
>> @@ -1401,6 +1416,7 @@ static int spinand_init(struct spinand_device *spinand)
>>   	mtd->_erase = spinand_mtd_erase;
>>   	mtd->_max_bad_blocks = nanddev_mtd_max_bad_blocks;
>>   	mtd->_resume = spinand_mtd_resume;
>> +	mtd->_suspend = spinand_mtd_suspend;
>>   
>>   	if (nand->ecc.engine) {
>>   		ret = mtd_ooblayout_count_freebytes(mtd);
> 
> 
> Thanks,
> Miquèl
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

Thanks,
Apurva Nandan