
On 06/28/2018 04:29 PM, Jagan Teki wrote:
On Mon, Jun 18, 2018 at 1:18 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On Tue, May 29, 2018 at 2:30 PM, Marek Vasut marex@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@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@denx.de Cc: Jagan Teki jagan@openedev.com Cc: Tom Rini trini@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 ? Since you seem to be quite keen on lecturing other maintainers how they should do their job, I'm really curious.