[U-Boot] [PATCH] sf: Enable FSR polling on N25Q256(A)

[Jagan Teki]

On Fri, Jun 29, 2018 at 2:02 PM, Marek Vasut <marex at denx.de> wrote:
> On 06/28/2018 04:29 PM, Jagan Teki wrote:
>> On Mon, Jun 18, 2018 at 1:18 PM, Jagan Teki <jagannadh.teki at gmail.com> wrote:
>>> On Tue, May 29, 2018 at 2:30 PM, Marek Vasut <marex at denx.de> wrote:
>>>> On 05/29/2018 06:52 AM, Jagan Teki wrote:
>>>>> + Siva
>>>>>
>>>>> On Fri, May 25, 2018 at 1:28 AM, Marek Vasut <marex at denx.de> wrote:
>>>>>> The N25Q256(A) datasheet clearly states that this device does have
>>>>>> a Flag Status Register and does update FSR PEC bit 7 during Program
>>>>>> and Erase cycles to indicate the cycle is in progress. Enable the
>>>>>> FSR PEC bit polling on this device to prevent data corruption.
>>>>>>
>>>>>> Signed-off-by: Marek Vasut <marex at denx.de>
>>>>>> Cc: Jagan Teki <jagan at openedev.com>
>>>>>> Cc: Tom Rini <trini at konsulko.com>
>>>>>> ---
>>>>>>  drivers/mtd/spi/spi_flash_ids.c | 4 ++--
>>>>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/mtd/spi/spi_flash_ids.c b/drivers/mtd/spi/spi_flash_ids.c
>>>>>> index 3b8f254ca2..fbc1bb6a5e 100644
>>>>>> --- a/drivers/mtd/spi/spi_flash_ids.c
>>>>>> +++ b/drivers/mtd/spi/spi_flash_ids.c
>>>>>> @@ -130,8 +130,8 @@ const struct spi_flash_info spi_flash_ids[] = {
>>>>>>         {"n25q64a",        INFO(0x20bb17, 0x0,  64 * 1024,   128, RD_FULL | WR_QPP | SECT_4K) },
>>>>>>         {"n25q128",        INFO(0x20ba18, 0x0,  64 * 1024,   256, RD_FULL | WR_QPP) },
>>>>>>         {"n25q128a",       INFO(0x20bb18, 0x0,  64 * 1024,   256, RD_FULL | WR_QPP) },
>>>>>> -       {"n25q256",        INFO(0x20ba19, 0x0,  64 * 1024,   512, RD_FULL | WR_QPP | SECT_4K) },
>>>>>> -       {"n25q256a",       INFO(0x20bb19, 0x0,  64 * 1024,   512, RD_FULL | WR_QPP | SECT_4K) },
>>>>>> +       {"n25q256",        INFO(0x20ba19, 0x0,  64 * 1024,   512, RD_FULL | WR_QPP | E_FSR | SECT_4K) },
>>>>>> +       {"n25q256a",       INFO(0x20bb19, 0x0,  64 * 1024,   512, RD_FULL | WR_QPP | E_FSR | SECT_4K) },
>>>>>
>>>>> FSR is required to poll flag status instead of read status only from
>>>>> Micron n25q512 because 512 is divided into two 256 dies so FSR is used
>>>>> for polling each die. In case of n25q256 the flash is single entity
>>>>> (doesn't have die concept) so there is no need to poll FSR.
>>>>>
>>>>> This is what I understood when I add initial FSR support
>>>>> 0f6232801cee4f45dbdb0cec45f71172c9b617ca
>>>>
>>>> The datasheet for N25Q256A (which is probably a better reference than a
>>>> commit in the U-Boot tree) claims the FSR is an indication of
>>>> PROGRAM/ERASE completion. We use SR and FSR (if it is avaiable) to check
>>>> whether all of the SNOR operations finished, so if FSR is available, we
>>>> should use it. Plus, I have an impression that the SR polling is not
>>>> reliable on the N25Q256A.
>>
>> Applied to u-boot-spi/master
>
> So why did you apply this patch only now, now that it missed all RCs ?

It's because of taking time for me to verify on hardware. ie reason I
asked you about how Linux deal this.

> Since you seem to be quite keen on lecturing other maintainers how they
> should do their job, I'm really curious.

As per as I know I commented to know why the patche apply such fast,
Sorry If I made any wrong words on this.