On Fri, Jun 29, 2018 at 2:02 PM, Marek Vasut <ma...@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.t...@gmail.com> wrote: >>> On Tue, May 29, 2018 at 2:30 PM, Marek Vasut <ma...@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 <ma...@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 <ma...@denx.de> >>>>>> Cc: Jagan Teki <ja...@openedev.com> >>>>>> Cc: Tom Rini <tr...@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot