[PATCH v2, 1/1] mtd: devices: m25p80: Add PM suspend resume support

[Michal Suchanek]

Hello,

On 20 January 2017 at 19:50, Kamal Dasu <kdasu.kdev at gmail.com> wrote:
> On Fri, Jan 20, 2017 at 12:22 PM, Marek Vasut <marex at denx.de> wrote:
>> On 01/20/2017 05:33 PM, Kamal Dasu wrote:
>>> Marek,
>>>
>>>>>
>>>>> OK, so I'm fine with leaving the patch as is for now but I would like Marek
>>>>> review just to be sure we didn't miss something: Marek, any comments?
>>>>>
>>>>> I just have one more comment below but it's only a detail.
>>>>
>>>> What would happen if you have a FS attached on this SPI NOR (like UBIFS)
>>>> and you suspend with this patch ? Will it survive ?
>>>>
>>>>
>>>
>>> I have tried with both jffs2 rw and ubifs rw rootfs on spi-nor
>>> booting from spi-nor partitions while  active filesystem operations
>>> were going on over suspend/resume cycles. And it survives.
>>
>> Can you elaborate on your test a bit ?
>>
>
> The power management test  puts  board in standby mode,  during
> standby the DRAM is in refresh and power to the spi-nor is removed.
> After a set timeout the board wakes up again and resumes from where it
> left off. This pm test is run while a cp command is invoked where a
> file is transferred to the rw rootfs. The test loops through said
> number of iterations of suspend and resumes cycles. The copy
> operations is eventually done over a few cycles. Once the test is
> completed  filesystem should have no corruptions, the copied files
> should compare and rootfs should be intact.  This test was repeated
> with jffs2 as well as ubifs rootfs flashed on spi-nor device.

Can some problem arise from not cutting the power in some situation?

Presumably with this patch the system tries to re-initialize the SPI NOR
after resume from suspend.

Can some SPI NOR memories be programmed into state in which they
would not respond to the commands used for identify?

Perhaps flash memories in dual/quad mode should be switched to plain
mode first?

Thanks

Michal