Re: [PATCH] Add support for flag status register on Micron chips
On Wednesday, April 09, 2014 at 08:14:49 PM, Graham Moore wrote: > On Wed, Apr 9, 2014 at 6:09 AM, Gerhard Sittig wrote: > > On Wed, 2014-04-09 at 12:03 +0200, Marek Vasut wrote: > >> On Tuesday, April 08, 2014 at 06:12:49 PM, grmo...@altera.com wrote: > >> > From: Graham Moore > >> > > >> > This is a slightly different version of the patch that Insop Song > >> > submitted > >> > (http://marc.info/?i=201403012022.10111.marex%20()%20denx%20!%20de). > >> > > >> > I talked to Insop, and he agreed I should submit this patch as a > >> > follow-on to his. > >> > > >> > This patch uses a flag in the m25p_ids[] array to determine which > >> > chips need to use the FSR (Flag Status Register). > >> > > >> > Rationale for using the FSR: > >> > > >> > The Micron data sheets say we have to do this, at least for the > >> > multi-die 512M and 1G parts (n25q512 and n25q00). In practice, if we > >> > don't check the FSR for program/erase status, and we rely solely on > >> > the status register (SR), then we get corrupted data in the flash. > > [...] > > >> > Micron told us (Altera) that for multi-die chips based on the 65nm > >> > 256MB die, we need to check the SR first, then check the FSR, which > >> > is why the wait_for_fsr_ready function does that. Future chips based > >> > on 45 nm 512MB die will use the FSR only. > > > > This sounds to me similar to polling the NAND's R/B pin until the > > operation has completed, to then fetch the STATUS byte to > > determine the execution's result. Does this sound plausible? > > For NOR, do you poll for the "busy" condition to deassert, and > > check for success then? > > Sounds plausible to me. We poll the SR until not busy, then poll the > FSR until it's not busy. Success is when FSR busy is deasserted > within the timeout. > > Micron said we have to read the FSR "at least once", so we don't > read it once for every die or anything like that. I ran a quick > test, and for both the 2-die and 4-die parts, the FSR shows not busy > on the first read after SR not busy. I'd love to know how this FSR-not-busy is exactly related to SR-not-busy, but I guess only Micron can tell :-/ Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add support for flag status register on Micron chips
On Wed, Apr 9, 2014 at 6:09 AM, Gerhard Sittig wrote: > On Wed, 2014-04-09 at 12:03 +0200, Marek Vasut wrote: >> >> On Tuesday, April 08, 2014 at 06:12:49 PM, grmo...@altera.com wrote: >> > From: Graham Moore >> > >> > This is a slightly different version of the patch that Insop Song >> > submitted >> > (http://marc.info/?i=201403012022.10111.marex%20()%20denx%20!%20de). >> > >> > I talked to Insop, and he agreed I should submit this patch as a follow-on >> > to his. >> > >> > This patch uses a flag in the m25p_ids[] array to determine which chips >> > need to use the FSR (Flag Status Register). >> > >> > Rationale for using the FSR: >> > >> > The Micron data sheets say we have to do this, at least for the multi-die >> > 512M and 1G parts (n25q512 and n25q00). In practice, if we don't check >> > the FSR for program/erase status, and we rely solely on the status >> > register (SR), then we get corrupted data in the flash. [...] >> > Micron told us (Altera) that for multi-die chips based on the 65nm 256MB >> > die, we need to check the SR first, then check the FSR, which is why the >> > wait_for_fsr_ready function does that. Future chips based on 45 nm 512MB >> > die will use the FSR only. > > This sounds to me similar to polling the NAND's R/B pin until the > operation has completed, to then fetch the STATUS byte to > determine the execution's result. Does this sound plausible? > For NOR, do you poll for the "busy" condition to deassert, and > check for success then? Sounds plausible to me. We poll the SR until not busy, then poll the FSR until it's not busy. Success is when FSR busy is deasserted within the timeout. Micron said we have to read the FSR "at least once", so we don't read it once for every die or anything like that. I ran a quick test, and for both the 2-die and 4-die parts, the FSR shows not busy on the first read after SR not busy. -Graham -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add support for flag status register on Micron chips
On Wed, 2014-04-09 at 12:03 +0200, Marek Vasut wrote: > > On Tuesday, April 08, 2014 at 06:12:49 PM, grmo...@altera.com wrote: > > From: Graham Moore > > > > This is a slightly different version of the patch that Insop Song > > submitted > > (http://marc.info/?i=201403012022.10111.marex%20()%20denx%20!%20de). > > > > I talked to Insop, and he agreed I should submit this patch as a follow-on > > to his. > > > > This patch uses a flag in the m25p_ids[] array to determine which chips > > need to use the FSR (Flag Status Register). > > > > Rationale for using the FSR: > > > > The Micron data sheets say we have to do this, at least for the multi-die > > 512M and 1G parts (n25q512 and n25q00). In practice, if we don't check > > the FSR for program/erase status, and we rely solely on the status > > register (SR), then we get corrupted data in the flash. > > I talked to Gerhard yesterday and he told me there is something like that on > ONFI NAND. I think I now understand why that new register is in-place. > Apparently, in the ONFI NAND case, there is a READY and TRUE-READY signal and > one of those reflects that _all_ the dies have finished their operation. This > is > in my opinion seriously misdesigned as it breaks any kind of backward > compatibility. There's a little more to it, I think. The "ready" and "true ready" are terms from Linux header files. In Micron datasheets, both of the bits 5 and 6 in the READ_STATUS response are referred to as "ready/busy", with a few footnotes to them depending on the mode of operation or the command that is being executed. The other thing is that there is the READ_STATUS command, which _might_ yield responses from different dies upon subsequent repeated reads. So you may have to determine how many dies are in the package, to repeat the STATUS query as many times, and logically combine these results in the chip's overall status. Or use the extended status query where you can address an individual die, but which is not supported by every chip. Pick your poison. The hardware R/B pins are wired-OR, such that any busy die will pull the summary pin level low. But this only tells you whether the operation is still pending, after it's complete you have to get the status and will face the situation described above. Can't tell how this NAND approach maps to the NOR subject described here. They might have a similar motivation, yet implement different approaches to the issue. > > Micron told us (Altera) that for multi-die chips based on the 65nm 256MB > > die, we need to check the SR first, then check the FSR, which is why the > > wait_for_fsr_ready function does that. Future chips based on 45 nm 512MB > > die will use the FSR only. This sounds to me similar to polling the NAND's R/B pin until the operation has completed, to then fetch the STATUS byte to determine the execution's result. Does this sound plausible? For NOR, do you poll for the "busy" condition to deassert, and check for success then? virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add support for flag status register on Micron chips.
On Wednesday, April 09, 2014 7:16 PM, Jingoo Han wrote:
> On Wednesday, April 09, 2014 7:07 PM, Marek Vasut wrote:
> > On Tuesday, April 08, 2014 at 06:12:50 PM, grmo...@altera.com wrote:
> > > From: Graham Moore
> > >
> > > Some new Micron flash chips require reading the flag
> > > status register to determine when operations have completed.
> > >
> > > Furthermore, chips with multi-die stacks of the 65nm 256Mb QSPI also
> > > require reading the status register before reading the flag status
> > > register.
> > >
> > > This patch adds support for the flag status register in the n25q512a1 and
> > > n25q00 Micron QSPI flash chips.
> >
> > [...]
> >
> > > +static int read_fsr(struct m25p *flash)
> > > +{
> > > + ssize_t retval;
> > > + u8 code = OPCODE_RDFSR;
> > > + u8 val;
> > > +
> > > + retval = spi_write_then_read(flash->spi, , 1, , 1);
> > > +
> > > + if (retval < 0) {
> > > + dev_err(>spi->dev, "error %d reading FSR\n",
> > > + (int) retval);
> >
> > Is the type-cast really needed here? Why ?
>
> The type-cast looks clumsy.
> The type of 'retval' is retval; thus, '%zd' can be used,
Sorry, there is a typo!
s/retval/ssize_t
The type of 'retval' is "ssize_t"; thus, '%zd' can be used,
instead of '%d', as below.
+ dev_err(>spi->dev, "error %zd reading FSR\n",
+ retval);
Best regards,
Jingoo Han
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add support for flag status register on Micron chips.
On Wednesday, April 09, 2014 7:07 PM, Marek Vasut wrote:
> On Tuesday, April 08, 2014 at 06:12:50 PM, grmo...@altera.com wrote:
> > From: Graham Moore
> >
> > Some new Micron flash chips require reading the flag
> > status register to determine when operations have completed.
> >
> > Furthermore, chips with multi-die stacks of the 65nm 256Mb QSPI also
> > require reading the status register before reading the flag status
> > register.
> >
> > This patch adds support for the flag status register in the n25q512a1 and
> > n25q00 Micron QSPI flash chips.
>
> [...]
>
> > +static int read_fsr(struct m25p *flash)
> > +{
> > + ssize_t retval;
> > + u8 code = OPCODE_RDFSR;
> > + u8 val;
> > +
> > + retval = spi_write_then_read(flash->spi, , 1, , 1);
> > +
> > + if (retval < 0) {
> > + dev_err(>spi->dev, "error %d reading FSR\n",
> > + (int) retval);
>
> Is the type-cast really needed here? Why ?
The type-cast looks clumsy.
The type of 'retval' is retval; thus, '%zd' can be used,
instead of '%d', as below.
+ dev_err(>spi->dev, "error %zd reading FSR\n",
+ retval);
>
> > + return retval;
> > + }
> > +
> > + return val;
> > +}
> > +/*
> > * Read configuration register, returning its value in the
> > * location. Return the configuration register value.
> > * Returns negative if error occured.
> > @@ -233,7 +259,7 @@ static inline int set_4byte(struct m25p *flash, u32
> > jedec_id, int enable) * Service routine to read status register until
> > ready, or timeout occurs. * Returns non-zero if error.
> > */
> > -static int wait_till_ready(struct m25p *flash)
> > +static int _wait_till_ready(struct m25p *flash)
>
> Please avoid using function names that start with underscore .
+1
I agree with Marek Vasut's opinion.
If there is no reason, please don't use it.
Best regards,
Jingoo Han
> [...]
>
> Thanks!
>
> Best regards,
> Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add support for flag status register on Micron chips
On Tuesday, April 08, 2014 at 06:12:49 PM, grmo...@altera.com wrote: > From: Graham Moore > > This is a slightly different version of the patch that Insop Song > submitted > (http://marc.info/?i=201403012022.10111.marex%20()%20denx%20!%20de). > > I talked to Insop, and he agreed I should submit this patch as a follow-on > to his. > > This patch uses a flag in the m25p_ids[] array to determine which chips > need to use the FSR (Flag Status Register). > > Rationale for using the FSR: > > The Micron data sheets say we have to do this, at least for the multi-die > 512M and 1G parts (n25q512 and n25q00). In practice, if we don't check > the FSR for program/erase status, and we rely solely on the status > register (SR), then we get corrupted data in the flash. I talked to Gerhard yesterday and he told me there is something like that on ONFI NAND. I think I now understand why that new register is in-place. Apparently, in the ONFI NAND case, there is a READY and TRUE-READY signal and one of those reflects that _all_ the dies have finished their operation. This is in my opinion seriously misdesigned as it breaks any kind of backward compatibility. > Micron told us (Altera) that for multi-die chips based on the 65nm 256MB > die, we need to check the SR first, then check the FSR, which is why the > wait_for_fsr_ready function does that. Future chips based on 45 nm 512MB > die will use the FSR only. Can these SPI flash makers screw the design even more? OT: Why don't we have a single standard for all the SF chips which won't need all these crappy quirks :-( Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add support for flag status register on Micron chips.
On Tuesday, April 08, 2014 at 06:12:50 PM, grmo...@altera.com wrote:
> From: Graham Moore
>
> Some new Micron flash chips require reading the flag
> status register to determine when operations have completed.
>
> Furthermore, chips with multi-die stacks of the 65nm 256Mb QSPI also
> require reading the status register before reading the flag status
> register.
>
> This patch adds support for the flag status register in the n25q512a1 and
> n25q00 Micron QSPI flash chips.
[...]
> +static int read_fsr(struct m25p *flash)
> +{
> + ssize_t retval;
> + u8 code = OPCODE_RDFSR;
> + u8 val;
> +
> + retval = spi_write_then_read(flash->spi, , 1, , 1);
> +
> + if (retval < 0) {
> + dev_err(>spi->dev, "error %d reading FSR\n",
> + (int) retval);
Is the type-cast really needed here? Why ?
> + return retval;
> + }
> +
> + return val;
> +}
> +/*
> * Read configuration register, returning its value in the
> * location. Return the configuration register value.
> * Returns negative if error occured.
> @@ -233,7 +259,7 @@ static inline int set_4byte(struct m25p *flash, u32
> jedec_id, int enable) * Service routine to read status register until
> ready, or timeout occurs. * Returns non-zero if error.
> */
> -static int wait_till_ready(struct m25p *flash)
> +static int _wait_till_ready(struct m25p *flash)
Please avoid using function names that start with underscore .
[...]
Thanks!
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add support for flag status register on Micron chips.
On Tuesday, April 08, 2014 at 06:12:50 PM, grmo...@altera.com wrote:
From: Graham Moore grmo...@altera.com
Some new Micron flash chips require reading the flag
status register to determine when operations have completed.
Furthermore, chips with multi-die stacks of the 65nm 256Mb QSPI also
require reading the status register before reading the flag status
register.
This patch adds support for the flag status register in the n25q512a1 and
n25q00 Micron QSPI flash chips.
[...]
+static int read_fsr(struct m25p *flash)
+{
+ ssize_t retval;
+ u8 code = OPCODE_RDFSR;
+ u8 val;
+
+ retval = spi_write_then_read(flash-spi, code, 1, val, 1);
+
+ if (retval 0) {
+ dev_err(flash-spi-dev, error %d reading FSR\n,
+ (int) retval);
Is the type-cast really needed here? Why ?
+ return retval;
+ }
+
+ return val;
+}
+/*
* Read configuration register, returning its value in the
* location. Return the configuration register value.
* Returns negative if error occured.
@@ -233,7 +259,7 @@ static inline int set_4byte(struct m25p *flash, u32
jedec_id, int enable) * Service routine to read status register until
ready, or timeout occurs. * Returns non-zero if error.
*/
-static int wait_till_ready(struct m25p *flash)
+static int _wait_till_ready(struct m25p *flash)
Please avoid using function names that start with underscore .
[...]
Thanks!
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add support for flag status register on Micron chips
On Tuesday, April 08, 2014 at 06:12:49 PM, grmo...@altera.com wrote: From: Graham Moore grmo...@altera.com This is a slightly different version of the patch that Insop Song submitted (http://marc.info/?i=201403012022.10111.marex%20()%20denx%20!%20de). I talked to Insop, and he agreed I should submit this patch as a follow-on to his. This patch uses a flag in the m25p_ids[] array to determine which chips need to use the FSR (Flag Status Register). Rationale for using the FSR: The Micron data sheets say we have to do this, at least for the multi-die 512M and 1G parts (n25q512 and n25q00). In practice, if we don't check the FSR for program/erase status, and we rely solely on the status register (SR), then we get corrupted data in the flash. I talked to Gerhard yesterday and he told me there is something like that on ONFI NAND. I think I now understand why that new register is in-place. Apparently, in the ONFI NAND case, there is a READY and TRUE-READY signal and one of those reflects that _all_ the dies have finished their operation. This is in my opinion seriously misdesigned as it breaks any kind of backward compatibility. Micron told us (Altera) that for multi-die chips based on the 65nm 256MB die, we need to check the SR first, then check the FSR, which is why the wait_for_fsr_ready function does that. Future chips based on 45 nm 512MB die will use the FSR only. Can these SPI flash makers screw the design even more? OT: Why don't we have a single standard for all the SF chips which won't need all these crappy quirks :-( Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add support for flag status register on Micron chips.
On Wednesday, April 09, 2014 7:07 PM, Marek Vasut wrote:
On Tuesday, April 08, 2014 at 06:12:50 PM, grmo...@altera.com wrote:
From: Graham Moore grmo...@altera.com
Some new Micron flash chips require reading the flag
status register to determine when operations have completed.
Furthermore, chips with multi-die stacks of the 65nm 256Mb QSPI also
require reading the status register before reading the flag status
register.
This patch adds support for the flag status register in the n25q512a1 and
n25q00 Micron QSPI flash chips.
[...]
+static int read_fsr(struct m25p *flash)
+{
+ ssize_t retval;
+ u8 code = OPCODE_RDFSR;
+ u8 val;
+
+ retval = spi_write_then_read(flash-spi, code, 1, val, 1);
+
+ if (retval 0) {
+ dev_err(flash-spi-dev, error %d reading FSR\n,
+ (int) retval);
Is the type-cast really needed here? Why ?
The type-cast looks clumsy.
The type of 'retval' is retval; thus, '%zd' can be used,
instead of '%d', as below.
+ dev_err(flash-spi-dev, error %zd reading FSR\n,
+ retval);
+ return retval;
+ }
+
+ return val;
+}
+/*
* Read configuration register, returning its value in the
* location. Return the configuration register value.
* Returns negative if error occured.
@@ -233,7 +259,7 @@ static inline int set_4byte(struct m25p *flash, u32
jedec_id, int enable) * Service routine to read status register until
ready, or timeout occurs. * Returns non-zero if error.
*/
-static int wait_till_ready(struct m25p *flash)
+static int _wait_till_ready(struct m25p *flash)
Please avoid using function names that start with underscore .
+1
I agree with Marek Vasut's opinion.
If there is no reason, please don't use it.
Best regards,
Jingoo Han
[...]
Thanks!
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add support for flag status register on Micron chips.
On Wednesday, April 09, 2014 7:16 PM, Jingoo Han wrote:
On Wednesday, April 09, 2014 7:07 PM, Marek Vasut wrote:
On Tuesday, April 08, 2014 at 06:12:50 PM, grmo...@altera.com wrote:
From: Graham Moore grmo...@altera.com
Some new Micron flash chips require reading the flag
status register to determine when operations have completed.
Furthermore, chips with multi-die stacks of the 65nm 256Mb QSPI also
require reading the status register before reading the flag status
register.
This patch adds support for the flag status register in the n25q512a1 and
n25q00 Micron QSPI flash chips.
[...]
+static int read_fsr(struct m25p *flash)
+{
+ ssize_t retval;
+ u8 code = OPCODE_RDFSR;
+ u8 val;
+
+ retval = spi_write_then_read(flash-spi, code, 1, val, 1);
+
+ if (retval 0) {
+ dev_err(flash-spi-dev, error %d reading FSR\n,
+ (int) retval);
Is the type-cast really needed here? Why ?
The type-cast looks clumsy.
The type of 'retval' is retval; thus, '%zd' can be used,
Sorry, there is a typo!
s/retval/ssize_t
The type of 'retval' is ssize_t; thus, '%zd' can be used,
instead of '%d', as below.
+ dev_err(flash-spi-dev, error %zd reading FSR\n,
+ retval);
Best regards,
Jingoo Han
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add support for flag status register on Micron chips
On Wed, 2014-04-09 at 12:03 +0200, Marek Vasut wrote: On Tuesday, April 08, 2014 at 06:12:49 PM, grmo...@altera.com wrote: From: Graham Moore grmo...@altera.com This is a slightly different version of the patch that Insop Song submitted (http://marc.info/?i=201403012022.10111.marex%20()%20denx%20!%20de). I talked to Insop, and he agreed I should submit this patch as a follow-on to his. This patch uses a flag in the m25p_ids[] array to determine which chips need to use the FSR (Flag Status Register). Rationale for using the FSR: The Micron data sheets say we have to do this, at least for the multi-die 512M and 1G parts (n25q512 and n25q00). In practice, if we don't check the FSR for program/erase status, and we rely solely on the status register (SR), then we get corrupted data in the flash. I talked to Gerhard yesterday and he told me there is something like that on ONFI NAND. I think I now understand why that new register is in-place. Apparently, in the ONFI NAND case, there is a READY and TRUE-READY signal and one of those reflects that _all_ the dies have finished their operation. This is in my opinion seriously misdesigned as it breaks any kind of backward compatibility. There's a little more to it, I think. The ready and true ready are terms from Linux header files. In Micron datasheets, both of the bits 5 and 6 in the READ_STATUS response are referred to as ready/busy, with a few footnotes to them depending on the mode of operation or the command that is being executed. The other thing is that there is the READ_STATUS command, which _might_ yield responses from different dies upon subsequent repeated reads. So you may have to determine how many dies are in the package, to repeat the STATUS query as many times, and logically combine these results in the chip's overall status. Or use the extended status query where you can address an individual die, but which is not supported by every chip. Pick your poison. The hardware R/B pins are wired-OR, such that any busy die will pull the summary pin level low. But this only tells you whether the operation is still pending, after it's complete you have to get the status and will face the situation described above. Can't tell how this NAND approach maps to the NOR subject described here. They might have a similar motivation, yet implement different approaches to the issue. Micron told us (Altera) that for multi-die chips based on the 65nm 256MB die, we need to check the SR first, then check the FSR, which is why the wait_for_fsr_ready function does that. Future chips based on 45 nm 512MB die will use the FSR only. This sounds to me similar to polling the NAND's R/B pin until the operation has completed, to then fetch the STATUS byte to determine the execution's result. Does this sound plausible? For NOR, do you poll for the busy condition to deassert, and check for success then? virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add support for flag status register on Micron chips
On Wed, Apr 9, 2014 at 6:09 AM, Gerhard Sittig g...@denx.de wrote: On Wed, 2014-04-09 at 12:03 +0200, Marek Vasut wrote: On Tuesday, April 08, 2014 at 06:12:49 PM, grmo...@altera.com wrote: From: Graham Moore grmo...@altera.com This is a slightly different version of the patch that Insop Song submitted (http://marc.info/?i=201403012022.10111.marex%20()%20denx%20!%20de). I talked to Insop, and he agreed I should submit this patch as a follow-on to his. This patch uses a flag in the m25p_ids[] array to determine which chips need to use the FSR (Flag Status Register). Rationale for using the FSR: The Micron data sheets say we have to do this, at least for the multi-die 512M and 1G parts (n25q512 and n25q00). In practice, if we don't check the FSR for program/erase status, and we rely solely on the status register (SR), then we get corrupted data in the flash. [...] Micron told us (Altera) that for multi-die chips based on the 65nm 256MB die, we need to check the SR first, then check the FSR, which is why the wait_for_fsr_ready function does that. Future chips based on 45 nm 512MB die will use the FSR only. This sounds to me similar to polling the NAND's R/B pin until the operation has completed, to then fetch the STATUS byte to determine the execution's result. Does this sound plausible? For NOR, do you poll for the busy condition to deassert, and check for success then? Sounds plausible to me. We poll the SR until not busy, then poll the FSR until it's not busy. Success is when FSR busy is deasserted within the timeout. Micron said we have to read the FSR at least once, so we don't read it once for every die or anything like that. I ran a quick test, and for both the 2-die and 4-die parts, the FSR shows not busy on the first read after SR not busy. -Graham -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add support for flag status register on Micron chips
On Wednesday, April 09, 2014 at 08:14:49 PM, Graham Moore wrote: On Wed, Apr 9, 2014 at 6:09 AM, Gerhard Sittig g...@denx.de wrote: On Wed, 2014-04-09 at 12:03 +0200, Marek Vasut wrote: On Tuesday, April 08, 2014 at 06:12:49 PM, grmo...@altera.com wrote: From: Graham Moore grmo...@altera.com This is a slightly different version of the patch that Insop Song submitted (http://marc.info/?i=201403012022.10111.marex%20()%20denx%20!%20de). I talked to Insop, and he agreed I should submit this patch as a follow-on to his. This patch uses a flag in the m25p_ids[] array to determine which chips need to use the FSR (Flag Status Register). Rationale for using the FSR: The Micron data sheets say we have to do this, at least for the multi-die 512M and 1G parts (n25q512 and n25q00). In practice, if we don't check the FSR for program/erase status, and we rely solely on the status register (SR), then we get corrupted data in the flash. [...] Micron told us (Altera) that for multi-die chips based on the 65nm 256MB die, we need to check the SR first, then check the FSR, which is why the wait_for_fsr_ready function does that. Future chips based on 45 nm 512MB die will use the FSR only. This sounds to me similar to polling the NAND's R/B pin until the operation has completed, to then fetch the STATUS byte to determine the execution's result. Does this sound plausible? For NOR, do you poll for the busy condition to deassert, and check for success then? Sounds plausible to me. We poll the SR until not busy, then poll the FSR until it's not busy. Success is when FSR busy is deasserted within the timeout. Micron said we have to read the FSR at least once, so we don't read it once for every die or anything like that. I ran a quick test, and for both the 2-die and 4-die parts, the FSR shows not busy on the first read after SR not busy. I'd love to know how this FSR-not-busy is exactly related to SR-not-busy, but I guess only Micron can tell :-/ Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] Add support for flag status register on Micron chips.
On Tuesday, April 08, 2014 9:13 AM, Graham Moore
>
> From: Graham Moore
>
> Some new Micron flash chips require reading the flag status register to
> determine when operations have completed.
>
> Furthermore, chips with multi-die stacks of the 65nm 256Mb QSPI also
> require reading the status register before reading the flag status register.
>
> This patch adds support for the flag status register in the n25q512a1 and
> n25q00 Micron QSPI flash chips.
>
Reviewed his change, and it is more generic then my previous patch.
Reviewed-by: Insop Song
> Signed-off-by: Graham Moore
> ---
> drivers/mtd/devices/m25p80.c | 94
> +++---
> 1 file changed, 80 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index ad19139..38306aa 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -39,6 +39,7 @@
> #define OPCODE_WREN 0x06/* Write enable */
> #define OPCODE_RDSR 0x05/* Read status register */
> #define OPCODE_WRSR 0x01/* Write status
> register 1 byte */
> +#define OPCODE_RDFSR0x70 /* read flag status
> register */
> #define OPCODE_NORM_READ0x03/* Read data bytes (low
> frequency) */
> #define OPCODE_FAST_READ0x0b/* Read data bytes (high
> frequency) */
> #define OPCODE_QUAD_READ0x6b/* Read data bytes */
> @@ -81,6 +82,9 @@
>
> #define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */
>
> +/* Flag Status Register bits */
> +#define FSR_READY 0x80/* FSR ready */
> +
> /* Configuration Register bits. */
> #define CR_QUAD_EN_SPAN 0x2 /* Spansion Quad I/O */
>
> @@ -108,6 +112,7 @@ struct m25p {
> u8 read_opcode;
> u8 program_opcode;
> u8 *command;
> + int (*wait_till_ready)(struct m25p *flash);
> enum read_type flash_read;
> };
>
> @@ -145,6 +150,27 @@ static int read_sr(struct m25p *flash) }
>
> /*
> + * Read the flag status register, returning its value in the location
> + * Return the status register value.
> + * Returns negative if error occurred.
> + */
> +static int read_fsr(struct m25p *flash) {
> + ssize_t retval;
> + u8 code = OPCODE_RDFSR;
> + u8 val;
> +
> + retval = spi_write_then_read(flash->spi, , 1, , 1);
> +
> + if (retval < 0) {
> + dev_err(>spi->dev, "error %d reading FSR\n",
> + (int) retval);
> + return retval;
> + }
> +
> + return val;
> +}
> +/*
> * Read configuration register, returning its value in the
> * location. Return the configuration register value.
> * Returns negative if error occured.
> @@ -233,7 +259,7 @@ static inline int set_4byte(struct m25p *flash, u32
> jedec_id, int enable)
> * Service routine to read status register until ready, or timeout occurs.
> * Returns non-zero if error.
> */
> -static int wait_till_ready(struct m25p *flash)
> +static int _wait_till_ready(struct m25p *flash)
> {
> unsigned long deadline;
> int sr;
> @@ -254,6 +280,37 @@ static int wait_till_ready(struct m25p *flash) }
>
> /*
> + * Service routine to read flag status register until ready, or timeout
> occurs.
> + * Returns non-zero if error.
> + */
> +static int _wait_till_fsr_ready(struct m25p *flash) {
> + unsigned long deadline;
> + int fsr;
> + int sr;
> +
> + deadline = jiffies + MAX_READY_WAIT_JIFFIES;
> +
> + do {
> + sr = read_sr(flash);
> + if (sr < 0)
> + break;
> + /* only check fsr if sr not busy */
> + if (!(sr & SR_WIP)) {
> + fsr = read_fsr(flash);
> + if (fsr < 0)
> + break;
> + if (fsr & FSR_READY)
> + return 0;
> + }
> +
> + cond_resched();
> +
> + } while (!time_after_eq(jiffies, deadline));
> +
> + return 1;
> +}
> +/*
> * Write status Register and configuration register with 2 bytes
> * The first byte will be written to the status register, while the
> * second byte will be written to the configuration register.
> @@ -280,7 +337,7 @@ static int macronix_quad_enable(struct m25p *flash)
>
> spi_write(flash->spi, , 2);
>
> - if (wait_till_ready(flash))
> + if (flash->wait_till_ready(flash))
> return 1;
>
> ret = read_sr(flash);
> @@ -351,7 +408,7 @@ static int erase_chip(struct m25p *flash)
> (long long)(flash->mtd.size >> 10));
>
> /* Wait until finished previous write command. */
> - if (wait_till_ready(flash))
> + if (flash->wait_till_ready(flash))
> return 1;
>
> /* Send write enable, then erase commands. */ @@ -391,7
RE: [PATCH] Add support for flag status register on Micron chips.
On Tuesday, April 08, 2014 9:13 AM, Graham Moore grmo...@altera.com
From: Graham Moore grmo...@altera.com
Some new Micron flash chips require reading the flag status register to
determine when operations have completed.
Furthermore, chips with multi-die stacks of the 65nm 256Mb QSPI also
require reading the status register before reading the flag status register.
This patch adds support for the flag status register in the n25q512a1 and
n25q00 Micron QSPI flash chips.
Reviewed his change, and it is more generic then my previous patch.
Reviewed-by: Insop Song insop.s...@gainspeed.com
Signed-off-by: Graham Moore grmo...@altera.com
---
drivers/mtd/devices/m25p80.c | 94
+++---
1 file changed, 80 insertions(+), 14 deletions(-)
diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
index ad19139..38306aa 100644
--- a/drivers/mtd/devices/m25p80.c
+++ b/drivers/mtd/devices/m25p80.c
@@ -39,6 +39,7 @@
#define OPCODE_WREN 0x06/* Write enable */
#define OPCODE_RDSR 0x05/* Read status register */
#define OPCODE_WRSR 0x01/* Write status
register 1 byte */
+#define OPCODE_RDFSR0x70 /* read flag status
register */
#define OPCODE_NORM_READ0x03/* Read data bytes (low
frequency) */
#define OPCODE_FAST_READ0x0b/* Read data bytes (high
frequency) */
#define OPCODE_QUAD_READ0x6b/* Read data bytes */
@@ -81,6 +82,9 @@
#define SR_QUAD_EN_MX 0x40/* Macronix Quad I/O */
+/* Flag Status Register bits */
+#define FSR_READY 0x80/* FSR ready */
+
/* Configuration Register bits. */
#define CR_QUAD_EN_SPAN 0x2 /* Spansion Quad I/O */
@@ -108,6 +112,7 @@ struct m25p {
u8 read_opcode;
u8 program_opcode;
u8 *command;
+ int (*wait_till_ready)(struct m25p *flash);
enum read_type flash_read;
};
@@ -145,6 +150,27 @@ static int read_sr(struct m25p *flash) }
/*
+ * Read the flag status register, returning its value in the location
+ * Return the status register value.
+ * Returns negative if error occurred.
+ */
+static int read_fsr(struct m25p *flash) {
+ ssize_t retval;
+ u8 code = OPCODE_RDFSR;
+ u8 val;
+
+ retval = spi_write_then_read(flash-spi, code, 1, val, 1);
+
+ if (retval 0) {
+ dev_err(flash-spi-dev, error %d reading FSR\n,
+ (int) retval);
+ return retval;
+ }
+
+ return val;
+}
+/*
* Read configuration register, returning its value in the
* location. Return the configuration register value.
* Returns negative if error occured.
@@ -233,7 +259,7 @@ static inline int set_4byte(struct m25p *flash, u32
jedec_id, int enable)
* Service routine to read status register until ready, or timeout occurs.
* Returns non-zero if error.
*/
-static int wait_till_ready(struct m25p *flash)
+static int _wait_till_ready(struct m25p *flash)
{
unsigned long deadline;
int sr;
@@ -254,6 +280,37 @@ static int wait_till_ready(struct m25p *flash) }
/*
+ * Service routine to read flag status register until ready, or timeout
occurs.
+ * Returns non-zero if error.
+ */
+static int _wait_till_fsr_ready(struct m25p *flash) {
+ unsigned long deadline;
+ int fsr;
+ int sr;
+
+ deadline = jiffies + MAX_READY_WAIT_JIFFIES;
+
+ do {
+ sr = read_sr(flash);
+ if (sr 0)
+ break;
+ /* only check fsr if sr not busy */
+ if (!(sr SR_WIP)) {
+ fsr = read_fsr(flash);
+ if (fsr 0)
+ break;
+ if (fsr FSR_READY)
+ return 0;
+ }
+
+ cond_resched();
+
+ } while (!time_after_eq(jiffies, deadline));
+
+ return 1;
+}
+/*
* Write status Register and configuration register with 2 bytes
* The first byte will be written to the status register, while the
* second byte will be written to the configuration register.
@@ -280,7 +337,7 @@ static int macronix_quad_enable(struct m25p *flash)
spi_write(flash-spi, cmd, 2);
- if (wait_till_ready(flash))
+ if (flash-wait_till_ready(flash))
return 1;
ret = read_sr(flash);
@@ -351,7 +408,7 @@ static int erase_chip(struct m25p *flash)
(long long)(flash-mtd.size 10));
/* Wait until finished previous write command. */
- if (wait_till_ready(flash))
+ if (flash-wait_till_ready(flash))
return 1;
/* Send write enable, then erase commands. */ @@ -391,7 +448,7
@@ static int erase_sector(struct m25p *flash, u32 offset)
