| Message ID | 20180524195845.20458-1-marex@denx.de |
|---|---|
| State | Accepted |
| Commit | 069b746ad9e66ab75973020f992e059c06cf3a7c |
| Delegated to: | Jagannadha Sutradharudu Teki |
| Headers | show |
| Series | [U-Boot] sf: Enable FSR polling on N25Q256(A) | expand |
+ 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 Jagan.
Hi, > -----Original Message----- > From: Jagan Teki [mailto:jagannadh.teki@gmail.com] > Sent: Tuesday, May 29, 2018 10:22 AM > To: Marek Vasut <marex@denx.de>; Siva Durga Prasad Paladugu > <sivadur@xilinx.com> > Cc: U-Boot Mailing List <u-boot@lists.denx.de>; Tom Rini > <trini@konsulko.com> > Subject: Re: [U-Boot] [PATCH] sf: Enable FSR polling on N25Q256(A) > > + 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 PEC bit in Flag status register on N25Q256A will apply only for PROGRAM/ERASE commands but not to WRITE command cycles where as WIP bit in Status register will be applicable to all(PROGRAM/ERASE and WRITE). Here is the snippet from N25Q256A datasheet about PEC bit in FSR. "These program/erase controller settings apply only to PROGRAM or ERASE command cycles in progress; they do not apply to a WRITE command cycle in progress." Regarding PEC bit in FSR of N25Q512(where it has two 256MB dies) here, it is mostly used to find out whether WRITE command(Write Status and Write Non volatile config Register) completed successfully for both dies. This is ensured by reading FSR twice with S# toggled in between and checking the PEC bit to be 1 in both the cases. Thanks, Siva > > > Jagan. > > -- > Jagan Teki > Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream > Maintainer Hyderabad, India.
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.
On 05/24/2018 09:58 PM, Marek Vasut 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) }, > {"n25q512", INFO(0x20ba20, 0x0, 64 * 1024, 1024, RD_FULL | WR_QPP | E_FSR | SECT_4K) }, > {"n25q512a", INFO(0x20bb20, 0x0, 64 * 1024, 1024, RD_FULL | WR_QPP | E_FSR | SECT_4K) }, > {"n25q1024", INFO(0x20ba21, 0x0, 64 * 1024, 2048, RD_FULL | WR_QPP | E_FSR | SECT_4K) }, > So, where is this stuff, I don't see it in u-boot/master ?
On Thu, Jun 7, 2018 at 12:15 AM, Marek Vasut <marex@denx.de> wrote: > On 05/24/2018 09:58 PM, Marek Vasut 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) }, >> {"n25q512", INFO(0x20ba20, 0x0, 64 * 1024, 1024, RD_FULL | WR_QPP | E_FSR | SECT_4K) }, >> {"n25q512a", INFO(0x20bb20, 0x0, 64 * 1024, 1024, RD_FULL | WR_QPP | E_FSR | SECT_4K) }, >> {"n25q1024", INFO(0x20ba21, 0x0, 64 * 1024, 2048, RD_FULL | WR_QPP | E_FSR | SECT_4K) }, >> > > So, where is this stuff, I don't see it in u-boot/master ? Why it should be in u-boot/master? it's neither in u-boot-spi/master nor with PR. still under discussion.
On 06/06/2018 09:04 PM, Jagan Teki wrote: > On Thu, Jun 7, 2018 at 12:15 AM, Marek Vasut <marex@denx.de> wrote: >> On 05/24/2018 09:58 PM, Marek Vasut 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) }, >>> {"n25q512", INFO(0x20ba20, 0x0, 64 * 1024, 1024, RD_FULL | WR_QPP | E_FSR | SECT_4K) }, >>> {"n25q512a", INFO(0x20bb20, 0x0, 64 * 1024, 1024, RD_FULL | WR_QPP | E_FSR | SECT_4K) }, >>> {"n25q1024", INFO(0x20ba21, 0x0, 64 * 1024, 2048, RD_FULL | WR_QPP | E_FSR | SECT_4K) }, >>> >> >> So, where is this stuff, I don't see it in u-boot/master ? > > Why it should be in u-boot/master? it's neither in u-boot-spi/master > nor with PR. still under discussion. So what is the problem with this patch exactly ?
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. Does this the same case with Linux? I never see n25q256a to use FSR. did you find any issue/correction with current master? Jagan.
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
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.
On Fri, Jun 29, 2018 at 2:02 PM, Marek Vasut <marex@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@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 ? 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.
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) }, {"n25q512", INFO(0x20ba20, 0x0, 64 * 1024, 1024, RD_FULL | WR_QPP | E_FSR | SECT_4K) }, {"n25q512a", INFO(0x20bb20, 0x0, 64 * 1024, 1024, RD_FULL | WR_QPP | E_FSR | SECT_4K) }, {"n25q1024", INFO(0x20ba21, 0x0, 64 * 1024, 2048, RD_FULL | WR_QPP | E_FSR | SECT_4K) },
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(-)