diff mbox

[V3] Add support for flag status register on Micron chips.

Message ID 1398175396-7560-2-git-send-email-grmoore@altera.com
State Not Applicable
Headers show

Commit Message

grmoore@altera.com April 22, 2014, 2:03 p.m. UTC
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 n25q512ax3 and n25q00
Micron QSPI flash chips.

Signed-off-by: Graham Moore <grmoore@altera.com>
---
V3:
Rebase to l2-mtd spinor branch.
V2:
Remove leading underscore in function names.
Remove type cast in dev_err call and use the proper format
specifier instead.
---
 drivers/mtd/spi-nor/spi-nor.c |   51 +++++++++++++++++++++++++++++++++++++++++
 include/linux/mtd/spi-nor.h   |    4 ++++
 2 files changed, 55 insertions(+)

Comments

Marek Vasut April 22, 2014, 4:55 p.m. UTC | #1
On Tuesday, April 22, 2014 at 04:03:16 PM, Graham Moore wrote:
[...]

>  #define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags)	\
> @@ -488,6 +534,8 @@ const struct spi_device_id spi_nor_ids[] = {
>  	{ "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256, 0) },
>  	{ "n25q256a",    INFO(0x20ba19, 0, 64 * 1024,  512, SECT_4K) },
>  	{ "n25q512a",    INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K) },
> +	{ "n25q512ax3",  INFO(0x20ba20, 0, 64 * 1024, 1024, USE_FSR) },
> +	{ "n25q00",      INFO(0x20ba21, 0, 64 * 1024, 2048, USE_FSR) },

Are you sure the n25q512a doesn't use FSR ? Do n25q512a{1,8}3 share the same 
IDs?

[...]
Best regards,
Marek Vasut
Gerhard Sittig April 22, 2014, 6:45 p.m. UTC | #2
On Tue, 2014-04-22 at 09:03 -0500, Graham Moore wrote:
> 
> ---
> V3:
> Rebase to l2-mtd spinor branch.
> V2:
> Remove leading underscore in function names.
> Remove type cast in dev_err call and use the proper format
> specifier instead.

the patch appears to not have dev_err() references, were they
removed? see below

> [ ... ]
> + * 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 spi_nor *nor)
> +{
> +	int ret;
> +	u8 val;
> +
> +	ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val, 1);
> +	if (ret < 0) {
> +		pr_err("error %d reading FSR\n", ret);
> +		return ret;
> +	}
> [ ... ]

this emits a message that an error has occured, but doesn't tell
where it occured -- can you dev_err() here to make the message
even more helpful?

> @@ -165,6 +184,32 @@ static int spi_nor_wait_till_ready(struct spi_nor *nor)
>  	return -ETIMEDOUT;
>  }
>  
> +static int spi_nor_wait_till_fsr_ready(struct spi_nor *nor)
> +{
> +	unsigned long deadline;
> +	int sr;
> +	int fsr;
> +
> +	deadline = jiffies + MAX_READY_WAIT_JIFFIES;
> +
> +	do {
> +		cond_resched();
> +
> +		sr = read_sr(nor);
> +		if (sr < 0)
> +			break;
> +		else if (!(sr & SR_WIP)) {
> +			fsr = read_fsr(nor);
> +			if (fsr < 0)
> +				break;
> +			if (fsr & FSR_READY)
> +				return 0;			
> +		}
> +	} while (!time_after_eq(jiffies, deadline));
> +
> +	return -ETIMEDOUT;
> +}

this logic always returns "timed out" when the ready flag is not
seen, even in the case of read errors -- can you "preset" the
error code with "timed out", and update it with something more
appropriate before returning when other errors are seen?

though this is an internal helper, and callers may not tell the
situations apart in the first place, so this might be a minor nit


virtually yours
Gerhard Sittig
Graham Moore April 22, 2014, 6:48 p.m. UTC | #3
On Tue, Apr 22, 2014 at 11:55 AM, Marek Vasut <marex@denx.de> wrote:
> Are you sure the n25q512a doesn't use FSR ? Do n25q512a{1,8}3 share the same
> IDs?

I looked at the datasheet and the n25q512a *does* have the same FSR
usage note, so I suppose I should add USE_FSR to it as well.  But how
is it working now?  Maybe nobody is actually using that chip.
Yes, n25q512a{1,8}3 share the same id, 0x20ba20.
Marek Vasut April 22, 2014, 6:58 p.m. UTC | #4
On Tuesday, April 22, 2014 at 08:48:21 PM, Graham Moore wrote:
> On Tue, Apr 22, 2014 at 11:55 AM, Marek Vasut <marex@denx.de> wrote:
> > Are you sure the n25q512a doesn't use FSR ? Do n25q512a{1,8}3 share the
> > same IDs?
> 
> I looked at the datasheet and the n25q512a *does* have the same FSR
> usage note, so I suppose I should add USE_FSR to it as well.  But how
> is it working now?

Is it at all ?

> Maybe nobody is actually using that chip.
> Yes, n25q512a{1,8}3 share the same id, 0x20ba20.

Sigh, oh Micron ...

Best regards,
Marek Vasut
Graham Moore April 22, 2014, 7:17 p.m. UTC | #5
On Tue, Apr 22, 2014 at 1:45 PM, Gerhard Sittig <gsi@denx.de> wrote:
> the patch appears to not have dev_err() references, were they
> removed? see below
[...]
> this emits a message that an error has occured, but doesn't tell
> where it occured -- can you dev_err() here to make the message
> even more helpful?

Yeah, the previous dev_err was actually copy-pasted from a similar
function that already existed.  When I rebased to l2-mtd/spinor, I did
the same copy-paste but that branch has pr_err instead of dev_err.
I'm a noob, so I didn't want to change things without a good
explanation :)  On the other hand, I'm in favor of using dev_err
instead.

[...]
> this logic always returns "timed out" when the ready flag is not
> seen, even in the case of read errors -- can you "preset" the
> error code with "timed out", and update it with something more
> appropriate before returning when other errors are seen?
>
> though this is an internal helper, and callers may not tell the
> situations apart in the first place, so this might be a minor nit

Same here as above, copy-pasted, and so the logic is what already
existed.  I double-checked the calling code, and like you say, the
callers do not tell the situations apart.  About half the calls assume
any error is timeout.  The others either pass return value or some
other error up, or they ignore it.

Thanks,
Graham
Huang Shijie April 25, 2014, 1:34 a.m. UTC | #6
On Tue, Apr 22, 2014 at 09:03:16AM -0500, Graham Moore wrote:
> 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 n25q512ax3 and n25q00
> Micron QSPI flash chips.
> 
> Signed-off-by: Graham Moore <grmoore@altera.com>
> ---
> V3:
> Rebase to l2-mtd spinor branch.
> V2:
> Remove leading underscore in function names.
> Remove type cast in dev_err call and use the proper format
> specifier instead.
> ---
>  drivers/mtd/spi-nor/spi-nor.c |   51 +++++++++++++++++++++++++++++++++++++++++
>  include/linux/mtd/spi-nor.h   |    4 ++++
>  2 files changed, 55 insertions(+)
> 
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index d6f44d5..24b84d8 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -48,6 +48,25 @@ static int read_sr(struct spi_nor *nor)
>  }
>  
>  /*
> + * 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 spi_nor *nor)
> +{
> +	int ret;
> +	u8 val;
> +
> +	ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val, 1);
> +	if (ret < 0) {
> +		pr_err("error %d reading FSR\n", ret);
> +		return ret;
> +	}
> +
> +	return val;
> +}
> +
> +/*
>   * Read configuration register, returning its value in the
>   * location. Return the configuration register value.
>   * Returns negative if error occured.
> @@ -165,6 +184,32 @@ static int spi_nor_wait_till_ready(struct spi_nor *nor)
>  	return -ETIMEDOUT;
>  }
>  
> +static int spi_nor_wait_till_fsr_ready(struct spi_nor *nor)
> +{
> +	unsigned long deadline;
> +	int sr;
> +	int fsr;
> +
> +	deadline = jiffies + MAX_READY_WAIT_JIFFIES;
> +
> +	do {
> +		cond_resched();
> +
> +		sr = read_sr(nor);
> +		if (sr < 0)
> +			break;
> +		else if (!(sr & SR_WIP)) {
> +			fsr = read_fsr(nor);
> +			if (fsr < 0)
> +				break;
> +			if (fsr & FSR_READY)
> +				return 0;			
> +		}
> +	} while (!time_after_eq(jiffies, deadline));
> +
> +	return -ETIMEDOUT;
> +}
> +
>  /*
>   * Service routine to read status register until ready, or timeout occurs.
>   * Returns non-zero if error.
> @@ -402,6 +447,7 @@ struct flash_info {
>  #define	SECT_4K_PMC		0x10	/* SPINOR_OP_BE_4K_PMC works uniformly */
>  #define	SPI_NOR_DUAL_READ	0x20    /* Flash supports Dual Read */
>  #define	SPI_NOR_QUAD_READ	0x40    /* Flash supports Quad Read */
> +#define	USE_FSR			0x80	/* use flag status register */
>  };
>  
>  #define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags)	\
> @@ -488,6 +534,8 @@ const struct spi_device_id spi_nor_ids[] = {
>  	{ "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256, 0) },
>  	{ "n25q256a",    INFO(0x20ba19, 0, 64 * 1024,  512, SECT_4K) },
>  	{ "n25q512a",    INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K) },
> +	{ "n25q512ax3",  INFO(0x20ba20, 0, 64 * 1024, 1024, USE_FSR) },
> +	{ "n25q00",      INFO(0x20ba21, 0, 64 * 1024, 2048, USE_FSR) },
>  
>  	/* PMC */
>  	{ "pm25lv512",   INFO(0,        0, 32 * 1024,    2, SECT_4K_PMC) },
> @@ -965,6 +1013,9 @@ int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
>  	else
>  		mtd->_write = spi_nor_write;
>  
> +	if (info->flags & USE_FSR)
> +		nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
> +
the drivers may fills this hook itself, so the code should like this:
   --------------------------------------------------
	if ((info->flags & USE_FSR) &&
	       	nor->wait_till_ready == spi_nor_wait_till_fsr_ready)
		nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
   --------------------------------------------------


thanks
Huang Shijie
Huang Shijie April 25, 2014, 1:52 a.m. UTC | #7
On Fri, Apr 25, 2014 at 04:42:33AM +0200, Marek Vasut wrote:
> On Friday, April 25, 2014 at 03:34:36 AM, Huang Shijie wrote:
> > On Tue, Apr 22, 2014 at 09:03:16AM -0500, Graham Moore wrote:
> > > 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 n25q512ax3
> > > and n25q00 Micron QSPI flash chips.
> > > 
> > > Signed-off-by: Graham Moore <grmoore@altera.com>
> > > ---
> > > V3:
> > > Rebase to l2-mtd spinor branch.
> > > V2:
> > > Remove leading underscore in function names.
> > > Remove type cast in dev_err call and use the proper format
> > > specifier instead.
> > > ---
> > > 
> > >  drivers/mtd/spi-nor/spi-nor.c |   51
> > >  +++++++++++++++++++++++++++++++++++++++++ include/linux/mtd/spi-nor.h  
> > >  |    4 ++++
> > >  2 files changed, 55 insertions(+)
> > > 
> > > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > > b/drivers/mtd/spi-nor/spi-nor.c index d6f44d5..24b84d8 100644
> > > --- a/drivers/mtd/spi-nor/spi-nor.c
> > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > > @@ -48,6 +48,25 @@ static int read_sr(struct spi_nor *nor)
> > > 
> > >  }
> > >  
> > >  /*
> > > 
> > > + * 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 spi_nor *nor)
> > > +{
> > > +	int ret;
> > > +	u8 val;
> > > +
> > > +	ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val, 1);
> > > +	if (ret < 0) {
> > > +		pr_err("error %d reading FSR\n", ret);
> > > +		return ret;
> > > +	}
> > > +
> > > +	return val;
> > > +}
> > > +
> > > +/*
> > > 
> > >   * Read configuration register, returning its value in the
> > >   * location. Return the configuration register value.
> > >   * Returns negative if error occured.
> > > 
> > > @@ -165,6 +184,32 @@ static int spi_nor_wait_till_ready(struct spi_nor
> > > *nor)
> > > 
> > >  	return -ETIMEDOUT;
> > >  
> > >  }
> > > 
> > > +static int spi_nor_wait_till_fsr_ready(struct spi_nor *nor)
> > > +{
> > > +	unsigned long deadline;
> > > +	int sr;
> > > +	int fsr;
> > > +
> > > +	deadline = jiffies + MAX_READY_WAIT_JIFFIES;
> > > +
> > > +	do {
> > > +		cond_resched();
> > > +
> > > +		sr = read_sr(nor);
> > > +		if (sr < 0)
> > > +			break;
> > > +		else if (!(sr & SR_WIP)) {
> > > +			fsr = read_fsr(nor);
> > > +			if (fsr < 0)
> > > +				break;
> > > +			if (fsr & FSR_READY)
> > > +				return 0;
> > > +		}
> > > +	} while (!time_after_eq(jiffies, deadline));
> > > +
> > > +	return -ETIMEDOUT;
> > > +}
> > > +
> > > 
> > >  /*
> > >  
> > >   * Service routine to read status register until ready, or timeout
> > >   occurs. * Returns non-zero if error.
> > > 
> > > @@ -402,6 +447,7 @@ struct flash_info {
> > > 
> > >  #define	SECT_4K_PMC		0x10	/* SPINOR_OP_BE_4K_PMC works 
> uniformly */
> > >  #define	SPI_NOR_DUAL_READ	0x20    /* Flash supports Dual Read */
> > >  #define	SPI_NOR_QUAD_READ	0x40    /* Flash supports Quad Read */
> > > 
> > > +#define	USE_FSR			0x80	/* use flag status register */
> > > 
> > >  };
> > >  
> > >  #define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags)	\
> > > 
> > > @@ -488,6 +534,8 @@ const struct spi_device_id spi_nor_ids[] = {
> > > 
> > >  	{ "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256, 0) },
> > >  	{ "n25q256a",    INFO(0x20ba19, 0, 64 * 1024,  512, SECT_4K) },
> > >  	{ "n25q512a",    INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K) },
> > > 
> > > +	{ "n25q512ax3",  INFO(0x20ba20, 0, 64 * 1024, 1024, USE_FSR) },
> > > +	{ "n25q00",      INFO(0x20ba21, 0, 64 * 1024, 2048, USE_FSR) },
> > > 
> > >  	/* PMC */
> > >  	{ "pm25lv512",   INFO(0,        0, 32 * 1024,    2, SECT_4K_PMC) },
> > > 
> > > @@ -965,6 +1013,9 @@ int spi_nor_scan(struct spi_nor *nor, const struct
> > > spi_device_id *id,
> > > 
> > >  	else
> > >  	
> > >  		mtd->_write = spi_nor_write;
> > > 
> > > +	if (info->flags & USE_FSR)
> > > +		nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
> > > +
> > 
> > the drivers may fills this hook itself, so the code should like this:
> >    --------------------------------------------------
> > 	if ((info->flags & USE_FSR) &&
> > 	       	nor->wait_till_ready == spi_nor_wait_till_fsr_ready)
> > 		nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
> >    --------------------------------------------------
> 
> I sense a misdesign of the SPI NOR subsystem here. The subsystem and the driver 
> compete for a function pointer here ? I guess one should have precedence in some 
> way then ... and also, they should be two different pointers, where the 
> subsystem decides which to use.
the subsystem do not decides which one to use, the driver decides which one to use.

If driver has its own @wait_till_ready , it means the driver knows the feature,
and has implemented it in its own @wait_till_ready.

If the driver does not fill any wait_till_ready, it means the driver will use the
default @wait_till_ready. We can treat the spi_nor_wait_till_fsr_ready as a default hook 
too.

thanks
Huang Shijie
Huang Shijie April 25, 2014, 1:54 a.m. UTC | #8
On Fri, Apr 25, 2014 at 04:42:33AM +0200, Marek Vasut wrote:
> On Friday, April 25, 2014 at 03:34:36 AM, Huang Shijie wrote:
> > On Tue, Apr 22, 2014 at 09:03:16AM -0500, Graham Moore wrote:
> > > 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 n25q512ax3
> > > and n25q00 Micron QSPI flash chips.
> > > 
> > > Signed-off-by: Graham Moore <grmoore@altera.com>
> > > ---
> > > V3:
> > > Rebase to l2-mtd spinor branch.
> > > V2:
> > > Remove leading underscore in function names.
> > > Remove type cast in dev_err call and use the proper format
> > > specifier instead.
> > > ---
> > > 
> > >  drivers/mtd/spi-nor/spi-nor.c |   51
> > >  +++++++++++++++++++++++++++++++++++++++++ include/linux/mtd/spi-nor.h  
> > >  |    4 ++++
> > >  2 files changed, 55 insertions(+)
> > > 
> > > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > > b/drivers/mtd/spi-nor/spi-nor.c index d6f44d5..24b84d8 100644
> > > --- a/drivers/mtd/spi-nor/spi-nor.c
> > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > > @@ -48,6 +48,25 @@ static int read_sr(struct spi_nor *nor)
> > > 
> > >  }
> > >  
> > >  /*
> > > 
> > > + * 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 spi_nor *nor)
> > > +{
> > > +	int ret;
> > > +	u8 val;
> > > +
> > > +	ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val, 1);
> > > +	if (ret < 0) {
> > > +		pr_err("error %d reading FSR\n", ret);
> > > +		return ret;
> > > +	}
> > > +
> > > +	return val;
> > > +}
> > > +
> > > +/*
> > > 
> > >   * Read configuration register, returning its value in the
> > >   * location. Return the configuration register value.
> > >   * Returns negative if error occured.
> > > 
> > > @@ -165,6 +184,32 @@ static int spi_nor_wait_till_ready(struct spi_nor
> > > *nor)
> > > 
> > >  	return -ETIMEDOUT;
> > >  
> > >  }
> > > 
> > > +static int spi_nor_wait_till_fsr_ready(struct spi_nor *nor)
> > > +{
> > > +	unsigned long deadline;
> > > +	int sr;
> > > +	int fsr;
> > > +
> > > +	deadline = jiffies + MAX_READY_WAIT_JIFFIES;
> > > +
> > > +	do {
> > > +		cond_resched();
> > > +
> > > +		sr = read_sr(nor);
> > > +		if (sr < 0)
> > > +			break;
> > > +		else if (!(sr & SR_WIP)) {
> > > +			fsr = read_fsr(nor);
> > > +			if (fsr < 0)
> > > +				break;
> > > +			if (fsr & FSR_READY)
> > > +				return 0;
> > > +		}
> > > +	} while (!time_after_eq(jiffies, deadline));
> > > +
> > > +	return -ETIMEDOUT;
> > > +}
> > > +
> > > 
> > >  /*
> > >  
> > >   * Service routine to read status register until ready, or timeout
> > >   occurs. * Returns non-zero if error.
> > > 
> > > @@ -402,6 +447,7 @@ struct flash_info {
> > > 
> > >  #define	SECT_4K_PMC		0x10	/* SPINOR_OP_BE_4K_PMC works 
> uniformly */
> > >  #define	SPI_NOR_DUAL_READ	0x20    /* Flash supports Dual Read */
> > >  #define	SPI_NOR_QUAD_READ	0x40    /* Flash supports Quad Read */
> > > 
> > > +#define	USE_FSR			0x80	/* use flag status register */
> > > 
> > >  };
> > >  
> > >  #define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags)	\
> > > 
> > > @@ -488,6 +534,8 @@ const struct spi_device_id spi_nor_ids[] = {
> > > 
> > >  	{ "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256, 0) },
> > >  	{ "n25q256a",    INFO(0x20ba19, 0, 64 * 1024,  512, SECT_4K) },
> > >  	{ "n25q512a",    INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K) },
> > > 
> > > +	{ "n25q512ax3",  INFO(0x20ba20, 0, 64 * 1024, 1024, USE_FSR) },
> > > +	{ "n25q00",      INFO(0x20ba21, 0, 64 * 1024, 2048, USE_FSR) },
> > > 
> > >  	/* PMC */
> > >  	{ "pm25lv512",   INFO(0,        0, 32 * 1024,    2, SECT_4K_PMC) },
> > > 
> > > @@ -965,6 +1013,9 @@ int spi_nor_scan(struct spi_nor *nor, const struct
> > > spi_device_id *id,
> > > 
> > >  	else
> > >  	
> > >  		mtd->_write = spi_nor_write;
> > > 
> > > +	if (info->flags & USE_FSR)
> > > +		nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
> > > +
> > 
> > the drivers may fills this hook itself, so the code should like this:
> >    --------------------------------------------------
> > 	if ((info->flags & USE_FSR) &&
> > 	       	nor->wait_till_ready == spi_nor_wait_till_fsr_ready)
> > 		nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
> >    --------------------------------------------------
sorry, the code should like this:
   --------------------------------------------------
   if ((info->flags & USE_FSR) &&
          	nor->wait_till_ready == spi_nor_wait_till_ready)
   	nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
  --------------------------------------------------
	  

thanks
Huang Shijie
Marek Vasut April 25, 2014, 2:42 a.m. UTC | #9
On Friday, April 25, 2014 at 03:34:36 AM, Huang Shijie wrote:
> On Tue, Apr 22, 2014 at 09:03:16AM -0500, Graham Moore wrote:
> > 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 n25q512ax3
> > and n25q00 Micron QSPI flash chips.
> > 
> > Signed-off-by: Graham Moore <grmoore@altera.com>
> > ---
> > V3:
> > Rebase to l2-mtd spinor branch.
> > V2:
> > Remove leading underscore in function names.
> > Remove type cast in dev_err call and use the proper format
> > specifier instead.
> > ---
> > 
> >  drivers/mtd/spi-nor/spi-nor.c |   51
> >  +++++++++++++++++++++++++++++++++++++++++ include/linux/mtd/spi-nor.h  
> >  |    4 ++++
> >  2 files changed, 55 insertions(+)
> > 
> > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > b/drivers/mtd/spi-nor/spi-nor.c index d6f44d5..24b84d8 100644
> > --- a/drivers/mtd/spi-nor/spi-nor.c
> > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > @@ -48,6 +48,25 @@ static int read_sr(struct spi_nor *nor)
> > 
> >  }
> >  
> >  /*
> > 
> > + * 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 spi_nor *nor)
> > +{
> > +	int ret;
> > +	u8 val;
> > +
> > +	ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val, 1);
> > +	if (ret < 0) {
> > +		pr_err("error %d reading FSR\n", ret);
> > +		return ret;
> > +	}
> > +
> > +	return val;
> > +}
> > +
> > +/*
> > 
> >   * Read configuration register, returning its value in the
> >   * location. Return the configuration register value.
> >   * Returns negative if error occured.
> > 
> > @@ -165,6 +184,32 @@ static int spi_nor_wait_till_ready(struct spi_nor
> > *nor)
> > 
> >  	return -ETIMEDOUT;
> >  
> >  }
> > 
> > +static int spi_nor_wait_till_fsr_ready(struct spi_nor *nor)
> > +{
> > +	unsigned long deadline;
> > +	int sr;
> > +	int fsr;
> > +
> > +	deadline = jiffies + MAX_READY_WAIT_JIFFIES;
> > +
> > +	do {
> > +		cond_resched();
> > +
> > +		sr = read_sr(nor);
> > +		if (sr < 0)
> > +			break;
> > +		else if (!(sr & SR_WIP)) {
> > +			fsr = read_fsr(nor);
> > +			if (fsr < 0)
> > +				break;
> > +			if (fsr & FSR_READY)
> > +				return 0;
> > +		}
> > +	} while (!time_after_eq(jiffies, deadline));
> > +
> > +	return -ETIMEDOUT;
> > +}
> > +
> > 
> >  /*
> >  
> >   * Service routine to read status register until ready, or timeout
> >   occurs. * Returns non-zero if error.
> > 
> > @@ -402,6 +447,7 @@ struct flash_info {
> > 
> >  #define	SECT_4K_PMC		0x10	/* SPINOR_OP_BE_4K_PMC works 
uniformly */
> >  #define	SPI_NOR_DUAL_READ	0x20    /* Flash supports Dual Read */
> >  #define	SPI_NOR_QUAD_READ	0x40    /* Flash supports Quad Read */
> > 
> > +#define	USE_FSR			0x80	/* use flag status register */
> > 
> >  };
> >  
> >  #define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags)	\
> > 
> > @@ -488,6 +534,8 @@ const struct spi_device_id spi_nor_ids[] = {
> > 
> >  	{ "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256, 0) },
> >  	{ "n25q256a",    INFO(0x20ba19, 0, 64 * 1024,  512, SECT_4K) },
> >  	{ "n25q512a",    INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K) },
> > 
> > +	{ "n25q512ax3",  INFO(0x20ba20, 0, 64 * 1024, 1024, USE_FSR) },
> > +	{ "n25q00",      INFO(0x20ba21, 0, 64 * 1024, 2048, USE_FSR) },
> > 
> >  	/* PMC */
> >  	{ "pm25lv512",   INFO(0,        0, 32 * 1024,    2, SECT_4K_PMC) },
> > 
> > @@ -965,6 +1013,9 @@ int spi_nor_scan(struct spi_nor *nor, const struct
> > spi_device_id *id,
> > 
> >  	else
> >  	
> >  		mtd->_write = spi_nor_write;
> > 
> > +	if (info->flags & USE_FSR)
> > +		nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
> > +
> 
> the drivers may fills this hook itself, so the code should like this:
>    --------------------------------------------------
> 	if ((info->flags & USE_FSR) &&
> 	       	nor->wait_till_ready == spi_nor_wait_till_fsr_ready)
> 		nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
>    --------------------------------------------------

I sense a misdesign of the SPI NOR subsystem here. The subsystem and the driver 
compete for a function pointer here ? I guess one should have precedence in some 
way then ... and also, they should be two different pointers, where the 
subsystem decides which to use.
Huang Shijie April 25, 2014, 4:47 a.m. UTC | #10
On Tue, Apr 22, 2014 at 01:48:21PM -0500, Graham Moore wrote:
> On Tue, Apr 22, 2014 at 11:55 AM, Marek Vasut <marex@denx.de> wrote:
> > Are you sure the n25q512a doesn't use FSR ? Do n25q512a{1,8}3 share the same
> > IDs?
> 
> I looked at the datasheet and the n25q512a *does* have the same FSR
> usage note, so I suppose I should add USE_FSR to it as well.  But how
> is it working now?  Maybe nobody is actually using that chip.
> Yes, n25q512a{1,8}3 share the same id, 0x20ba20.
> 
could use the ext_id to distinguish them ? just as we did for Spansion NOR.

i dumped out 5 bytes of my n25q256a: 0x20, 0xba, 0x19, 0x10, 0x00.

thanks
Huang Shijie
Marek Vasut April 25, 2014, 3:50 p.m. UTC | #11
On Friday, April 25, 2014 at 06:47:04 AM, Huang Shijie wrote:
> On Tue, Apr 22, 2014 at 01:48:21PM -0500, Graham Moore wrote:
> > On Tue, Apr 22, 2014 at 11:55 AM, Marek Vasut <marex@denx.de> wrote:
> > > Are you sure the n25q512a doesn't use FSR ? Do n25q512a{1,8}3 share the
> > > same IDs?
> > 
> > I looked at the datasheet and the n25q512a *does* have the same FSR
> > usage note, so I suppose I should add USE_FSR to it as well.  But how
> > is it working now?  Maybe nobody is actually using that chip.
> > Yes, n25q512a{1,8}3 share the same id, 0x20ba20.
> 
> could use the ext_id to distinguish them ? just as we did for Spansion NOR.
> 
> i dumped out 5 bytes of my n25q256a: 0x20, 0xba, 0x19, 0x10, 0x00.

The q256 and q512 are rather different chips it seems to me ...

Best regards,
Marek Vasut
Marek Vasut April 25, 2014, 10:12 p.m. UTC | #12
On Friday, April 25, 2014 at 03:52:46 AM, Huang Shijie wrote:
> On Fri, Apr 25, 2014 at 04:42:33AM +0200, Marek Vasut wrote:
> > On Friday, April 25, 2014 at 03:34:36 AM, Huang Shijie wrote:
> > > On Tue, Apr 22, 2014 at 09:03:16AM -0500, Graham Moore wrote:
> > > > 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
> > > > n25q512ax3 and n25q00 Micron QSPI flash chips.
> > > > 
> > > > Signed-off-by: Graham Moore <grmoore@altera.com>
> > > > ---
> > > > V3:
> > > > Rebase to l2-mtd spinor branch.
> > > > V2:
> > > > Remove leading underscore in function names.
> > > > Remove type cast in dev_err call and use the proper format
> > > > specifier instead.
> > > > ---
> > > > 
> > > >  drivers/mtd/spi-nor/spi-nor.c |   51
> > > >  +++++++++++++++++++++++++++++++++++++++++
> > > >  include/linux/mtd/spi-nor.h
> > > >  
> > > >  |    4 ++++
> > > >  
> > > >  2 files changed, 55 insertions(+)
> > > > 
> > > > diff --git a/drivers/mtd/spi-nor/spi-nor.c
> > > > b/drivers/mtd/spi-nor/spi-nor.c index d6f44d5..24b84d8 100644
> > > > --- a/drivers/mtd/spi-nor/spi-nor.c
> > > > +++ b/drivers/mtd/spi-nor/spi-nor.c
> > > > @@ -48,6 +48,25 @@ static int read_sr(struct spi_nor *nor)
> > > > 
> > > >  }
> > > >  
> > > >  /*
> > > > 
> > > > + * 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 spi_nor *nor)
> > > > +{
> > > > +	int ret;
> > > > +	u8 val;
> > > > +
> > > > +	ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val, 1);
> > > > +	if (ret < 0) {
> > > > +		pr_err("error %d reading FSR\n", ret);
> > > > +		return ret;
> > > > +	}
> > > > +
> > > > +	return val;
> > > > +}
> > > > +
> > > > +/*
> > > > 
> > > >   * Read configuration register, returning its value in the
> > > >   * location. Return the configuration register value.
> > > >   * Returns negative if error occured.
> > > > 
> > > > @@ -165,6 +184,32 @@ static int spi_nor_wait_till_ready(struct
> > > > spi_nor *nor)
> > > > 
> > > >  	return -ETIMEDOUT;
> > > >  
> > > >  }
> > > > 
> > > > +static int spi_nor_wait_till_fsr_ready(struct spi_nor *nor)
> > > > +{
> > > > +	unsigned long deadline;
> > > > +	int sr;
> > > > +	int fsr;
> > > > +
> > > > +	deadline = jiffies + MAX_READY_WAIT_JIFFIES;
> > > > +
> > > > +	do {
> > > > +		cond_resched();
> > > > +
> > > > +		sr = read_sr(nor);
> > > > +		if (sr < 0)
> > > > +			break;
> > > > +		else if (!(sr & SR_WIP)) {
> > > > +			fsr = read_fsr(nor);
> > > > +			if (fsr < 0)
> > > > +				break;
> > > > +			if (fsr & FSR_READY)
> > > > +				return 0;
> > > > +		}
> > > > +	} while (!time_after_eq(jiffies, deadline));
> > > > +
> > > > +	return -ETIMEDOUT;
> > > > +}
> > > > +
> > > > 
> > > >  /*
> > > >  
> > > >   * Service routine to read status register until ready, or timeout
> > > >   occurs. * Returns non-zero if error.
> > > > 
> > > > @@ -402,6 +447,7 @@ struct flash_info {
> > > > 
> > > >  #define	SECT_4K_PMC		0x10	/* SPINOR_OP_BE_4K_PMC 
works
> > 
> > uniformly */
> > 
> > > >  #define	SPI_NOR_DUAL_READ	0x20    /* Flash supports Dual 
Read */
> > > >  #define	SPI_NOR_QUAD_READ	0x40    /* Flash supports Quad 
Read */
> > > > 
> > > > +#define	USE_FSR			0x80	/* use flag status 
register */
> > > > 
> > > >  };
> > > >  
> > > >  #define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags)	\
> > > > 
> > > > @@ -488,6 +534,8 @@ const struct spi_device_id spi_nor_ids[] = {
> > > > 
> > > >  	{ "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256, 0) },
> > > >  	{ "n25q256a",    INFO(0x20ba19, 0, 64 * 1024,  512, SECT_4K) },
> > > >  	{ "n25q512a",    INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K) },
> > > > 
> > > > +	{ "n25q512ax3",  INFO(0x20ba20, 0, 64 * 1024, 1024, USE_FSR) },
> > > > +	{ "n25q00",      INFO(0x20ba21, 0, 64 * 1024, 2048, USE_FSR) },
> > > > 
> > > >  	/* PMC */
> > > >  	{ "pm25lv512",   INFO(0,        0, 32 * 1024,    2, SECT_4K_PMC) 
},
> > > > 
> > > > @@ -965,6 +1013,9 @@ int spi_nor_scan(struct spi_nor *nor, const
> > > > struct spi_device_id *id,
> > > > 
> > > >  	else
> > > >  	
> > > >  		mtd->_write = spi_nor_write;
> > > > 
> > > > +	if (info->flags & USE_FSR)
> > > > +		nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
> > > > +
> > > 
> > > the drivers may fills this hook itself, so the code should like this:
> > >    --------------------------------------------------
> > > 	
> > > 	if ((info->flags & USE_FSR) &&
> > > 	
> > > 	       	nor->wait_till_ready == spi_nor_wait_till_fsr_ready)
> > > 		
> > > 		nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
> > > 		
> > >    --------------------------------------------------
> > 
> > I sense a misdesign of the SPI NOR subsystem here. The subsystem and the
> > driver compete for a function pointer here ? I guess one should have
> > precedence in some way then ... and also, they should be two different
> > pointers, where the subsystem decides which to use.
> 
> the subsystem do not decides which one to use, the driver decides which one
> to use.
> 
> If driver has its own @wait_till_ready , it means the driver knows the
> feature, and has implemented it in its own @wait_till_ready.
> 
> If the driver does not fill any wait_till_ready, it means the driver will
> use the default @wait_till_ready. We can treat the
> spi_nor_wait_till_fsr_ready as a default hook too.

I see the driver overwriting a hook previously set by the subsystem. This 
doesn't seem right to me, but please correct me if I'm wrong ...
Huang Shijie April 26, 2014, 3:10 a.m. UTC | #13
On Sat, Apr 26, 2014 at 12:12:24AM +0200, Marek Vasut wrote:
> > > > the drivers may fills this hook itself, so the code should like this:
> > > >    --------------------------------------------------
> > > > 	
> > > > 	if ((info->flags & USE_FSR) &&
> > > > 	
> > > > 	       	nor->wait_till_ready == spi_nor_wait_till_fsr_ready)
> > > > 		
> > > > 		nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
> > > > 		
> > > >    --------------------------------------------------
> > > 
> > > I sense a misdesign of the SPI NOR subsystem here. The subsystem and the
> > > driver compete for a function pointer here ? I guess one should have
> > > precedence in some way then ... and also, they should be two different
> > > pointers, where the subsystem decides which to use.
> > 
> > the subsystem do not decides which one to use, the driver decides which one
> > to use.
> > 
> > If driver has its own @wait_till_ready , it means the driver knows the
> > feature, and has implemented it in its own @wait_till_ready.
> > 
> > If the driver does not fill any wait_till_ready, it means the driver will
> > use the default @wait_till_ready. We can treat the
> > spi_nor_wait_till_fsr_ready as a default hook too.
> 
> I see the driver overwriting a hook previously set by the subsystem. This 
not sure ;)

The driver set the hooks before the subsystem set these hooks.

If the driver has already set the @wait_till_ready hook before it calls
the spi_nor_scan, the subsystem will not set the hook anymore.

Please see the spi_nor_check().

thanks
Huang Shijie
Marek Vasut April 28, 2014, 5:06 a.m. UTC | #14
On Saturday, April 26, 2014 at 05:10:13 AM, Huang Shijie wrote:
> On Sat, Apr 26, 2014 at 12:12:24AM +0200, Marek Vasut wrote:
> > > > > the drivers may fills this hook itself, so the code should like this:
> > > > >    --------------------------------------------------
> > > > > 	
> > > > > 	if ((info->flags & USE_FSR) &&
> > > > > 	
> > > > > 	       	nor->wait_till_ready == spi_nor_wait_till_fsr_ready)
> > > > > 		
> > > > > 		nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
> > > > > 		
> > > > >    --------------------------------------------------
> > > > 
> > > > I sense a misdesign of the SPI NOR subsystem here. The subsystem and
> > > > the driver compete for a function pointer here ? I guess one should
> > > > have precedence in some way then ... and also, they should be two
> > > > different pointers, where the subsystem decides which to use.
> > > 
> > > the subsystem do not decides which one to use, the driver decides which
> > > one to use.
> > > 
> > > If driver has its own @wait_till_ready , it means the driver knows the
> > > feature, and has implemented it in its own @wait_till_ready.
> > > 
> > > If the driver does not fill any wait_till_ready, it means the driver
> > > will use the default @wait_till_ready. We can treat the
> > > spi_nor_wait_till_fsr_ready as a default hook too.
> > 
> > I see the driver overwriting a hook previously set by the subsystem. This
> 
> not sure ;)
> 
> The driver set the hooks before the subsystem set these hooks.
> 
> If the driver has already set the @wait_till_ready hook before it calls
> the spi_nor_scan, the subsystem will not set the hook anymore.
> 
> Please see the spi_nor_check().

Two things competing over the same pointer looks misdesigned to me. I will need 
to dig into this one more time ...

Best regards,
Marek Vasut
Huang Shijie April 28, 2014, 7:06 a.m. UTC | #15
On Mon, Apr 28, 2014 at 07:06:17AM +0200, Marek Vasut wrote:
> On Saturday, April 26, 2014 at 05:10:13 AM, Huang Shijie wrote:
> > On Sat, Apr 26, 2014 at 12:12:24AM +0200, Marek Vasut wrote:
> > > > > > the drivers may fills this hook itself, so the code should like this:
> > > > > >    --------------------------------------------------
> > > > > > 	
> > > > > > 	if ((info->flags & USE_FSR) &&
> > > > > > 	
> > > > > > 	       	nor->wait_till_ready == spi_nor_wait_till_fsr_ready)
> > > > > > 		
> > > > > > 		nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
> > > > > > 		
> > > > > >    --------------------------------------------------
> > > > > 
> > > > > I sense a misdesign of the SPI NOR subsystem here. The subsystem and
> > > > > the driver compete for a function pointer here ? I guess one should
> > > > > have precedence in some way then ... and also, they should be two
> > > > > different pointers, where the subsystem decides which to use.
> > > > 
> > > > the subsystem do not decides which one to use, the driver decides which
> > > > one to use.
> > > > 
> > > > If driver has its own @wait_till_ready , it means the driver knows the
> > > > feature, and has implemented it in its own @wait_till_ready.
> > > > 
> > > > If the driver does not fill any wait_till_ready, it means the driver
> > > > will use the default @wait_till_ready. We can treat the
> > > > spi_nor_wait_till_fsr_ready as a default hook too.
> > > 
> > > I see the driver overwriting a hook previously set by the subsystem. This
> > 
> > not sure ;)
> > 
> > The driver set the hooks before the subsystem set these hooks.
> > 
> > If the driver has already set the @wait_till_ready hook before it calls
> > the spi_nor_scan, the subsystem will not set the hook anymore.
> > 
> > Please see the spi_nor_check().
> 
> Two things competing over the same pointer looks misdesigned to me. I will need 
> to dig into this one more time ...
Please refer to the code for NAND chip, the nand_get_flash_type() :

-----------------------------------------------------------
	/* Do not replace user supplied command function! */
	if (mtd->writesize > 512 && chip->cmdfunc == nand_command)
		chip->cmdfunc = nand_command_lp;
-----------------------------------------------------------

It uses the same logic: 
	" Do not replace user supplied command function!"

thanks
Huang Shijie
Graham Moore April 28, 2014, 2:22 p.m. UTC | #16
On Mon, Apr 28, 2014 at 2:06 AM, Huang Shijie <b32955@freescale.com> wrote:
> On Mon, Apr 28, 2014 at 07:06:17AM +0200, Marek Vasut wrote:
>>
>> Two things competing over the same pointer looks misdesigned to me. I will need
>> to dig into this one more time ...
> Please refer to the code for NAND chip, the nand_get_flash_type() :
>
> -----------------------------------------------------------
>         /* Do not replace user supplied command function! */
>         if (mtd->writesize > 512 && chip->cmdfunc == nand_command)
>                 chip->cmdfunc = nand_command_lp;
> -----------------------------------------------------------
>
> It uses the same logic:
>         " Do not replace user supplied command function!"
>
> thanks
> Huang Shijie

I would like to set the @wait_till_ready in m25p80.c, because the
USE_FSR flag is only for Micron chips.  But the m25p80 driver doesn't
have access to the flags, they are contained in spi-nor.c.  It seems
to me that the driver_data should be accessible by the driver.  So
maybe there is room for improvement there.

Thanks,
Graham Moore
Huang Shijie April 28, 2014, 3:37 p.m. UTC | #17
On Mon, Apr 28, 2014 at 09:22:58AM -0500, Graham Moore wrote:
> On Mon, Apr 28, 2014 at 2:06 AM, Huang Shijie <b32955@freescale.com> wrote:
> > On Mon, Apr 28, 2014 at 07:06:17AM +0200, Marek Vasut wrote:
> >>
> >> Two things competing over the same pointer looks misdesigned to me. I will need
> >> to dig into this one more time ...
> > Please refer to the code for NAND chip, the nand_get_flash_type() :
> >
> > -----------------------------------------------------------
> >         /* Do not replace user supplied command function! */
> >         if (mtd->writesize > 512 && chip->cmdfunc == nand_command)
> >                 chip->cmdfunc = nand_command_lp;
> > -----------------------------------------------------------
> >
> > It uses the same logic:
> >         " Do not replace user supplied command function!"
> >
> > thanks
> > Huang Shijie
> 
> I would like to set the @wait_till_ready in m25p80.c, because the
> USE_FSR flag is only for Micron chips.  But the m25p80 driver doesn't
m25p80.c is not the right place. 

we should put these code in the spi-nor.c

thanks
Huang Shijie
Brian Norris July 12, 2014, 2:07 a.m. UTC | #18
Hi guys,

Sorry to revisit this way late, and sorry for not paying as much
attention initially. I'm prepped to merge v4, but some of the
conversation matches what I was just thinking.

On Mon, Apr 28, 2014 at 07:06:17AM +0200, Marek Vasut wrote:
> On Saturday, April 26, 2014 at 05:10:13 AM, Huang Shijie wrote:
> > On Sat, Apr 26, 2014 at 12:12:24AM +0200, Marek Vasut wrote:
> > > > > > the drivers may fills this hook itself, so the code should like this:
> > > > > >    --------------------------------------------------
> > > > > > 	
> > > > > > 	if ((info->flags & USE_FSR) &&
> > > > > > 	
> > > > > > 	       	nor->wait_till_ready == spi_nor_wait_till_fsr_ready)
> > > > > > 		
> > > > > > 		nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
> > > > > > 		
> > > > > >    --------------------------------------------------
> > > > > 
> > > > > I sense a misdesign of the SPI NOR subsystem here. The subsystem and
> > > > > the driver compete for a function pointer here ? I guess one should
> > > > > have precedence in some way then ... and also, they should be two
> > > > > different pointers, where the subsystem decides which to use.
> > > > 
> > > > the subsystem do not decides which one to use, the driver decides which
> > > > one to use.
> > > > 
> > > > If driver has its own @wait_till_ready , it means the driver knows the
> > > > feature, and has implemented it in its own @wait_till_ready.
> > > > 
> > > > If the driver does not fill any wait_till_ready, it means the driver
> > > > will use the default @wait_till_ready. We can treat the
> > > > spi_nor_wait_till_fsr_ready as a default hook too.
> > > 
> > > I see the driver overwriting a hook previously set by the subsystem. This
> > 
> > not sure ;)
> > 
> > The driver set the hooks before the subsystem set these hooks.
> > 
> > If the driver has already set the @wait_till_ready hook before it calls
> > the spi_nor_scan, the subsystem will not set the hook anymore.
> > 
> > Please see the spi_nor_check().
> 
> Two things competing over the same pointer looks misdesigned to me. I will need 
> to dig into this one more time ...

Yes, that is misdesigned. And looking at nand_base for examples is not
foolproof; it has quite a bit of legacy and workarounds. It'd be best to
get the design right for spi-nor.

The subsystem code should not require a function pointer for FSR vs.
non-FSR -- all devices should be able to use the same function. We just
need to stash some flash-ID-related data (i.e., a flags field) in the
spi_nor struct. On the plus side, we can avoid the code duplication
between spi_nor_wait_till_fsr_ready() and spi_nor_wait_till_ready().

I think the wait_till_ready pointer should be reserved for the driver,
as a hardware-specific "wait" function.

This still leaves the question of whether the SPI NOR core should assume
that any driver's 'wait_till_ready' function (if present) actually
implements all necessary waits (FSR vs. non-FSR, for instance). I'd
argue that's a maintenance burden, and that the subsystem should still
do a sanity check that the status register is correct. After all, that's
what the ->{read,write}_reg() functions are useful for. But perhaps
there is some performance argument for avoiding the (potentially
redundant) register checks?

Anyway, I've tested v4, and I plan to merge it soon. Patches can be sent
on top. (I may even cook up my own.)

Regards,
Brian
diff mbox

Patch

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index d6f44d5..24b84d8 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -48,6 +48,25 @@  static int read_sr(struct spi_nor *nor)
 }
 
 /*
+ * 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 spi_nor *nor)
+{
+	int ret;
+	u8 val;
+
+	ret = nor->read_reg(nor, SPINOR_OP_RDFSR, &val, 1);
+	if (ret < 0) {
+		pr_err("error %d reading FSR\n", ret);
+		return ret;
+	}
+
+	return val;
+}
+
+/*
  * Read configuration register, returning its value in the
  * location. Return the configuration register value.
  * Returns negative if error occured.
@@ -165,6 +184,32 @@  static int spi_nor_wait_till_ready(struct spi_nor *nor)
 	return -ETIMEDOUT;
 }
 
+static int spi_nor_wait_till_fsr_ready(struct spi_nor *nor)
+{
+	unsigned long deadline;
+	int sr;
+	int fsr;
+
+	deadline = jiffies + MAX_READY_WAIT_JIFFIES;
+
+	do {
+		cond_resched();
+
+		sr = read_sr(nor);
+		if (sr < 0)
+			break;
+		else if (!(sr & SR_WIP)) {
+			fsr = read_fsr(nor);
+			if (fsr < 0)
+				break;
+			if (fsr & FSR_READY)
+				return 0;			
+		}
+	} while (!time_after_eq(jiffies, deadline));
+
+	return -ETIMEDOUT;
+}
+
 /*
  * Service routine to read status register until ready, or timeout occurs.
  * Returns non-zero if error.
@@ -402,6 +447,7 @@  struct flash_info {
 #define	SECT_4K_PMC		0x10	/* SPINOR_OP_BE_4K_PMC works uniformly */
 #define	SPI_NOR_DUAL_READ	0x20    /* Flash supports Dual Read */
 #define	SPI_NOR_QUAD_READ	0x40    /* Flash supports Quad Read */
+#define	USE_FSR			0x80	/* use flag status register */
 };
 
 #define INFO(_jedec_id, _ext_id, _sector_size, _n_sectors, _flags)	\
@@ -488,6 +534,8 @@  const struct spi_device_id spi_nor_ids[] = {
 	{ "n25q128a13",  INFO(0x20ba18, 0, 64 * 1024,  256, 0) },
 	{ "n25q256a",    INFO(0x20ba19, 0, 64 * 1024,  512, SECT_4K) },
 	{ "n25q512a",    INFO(0x20bb20, 0, 64 * 1024, 1024, SECT_4K) },
+	{ "n25q512ax3",  INFO(0x20ba20, 0, 64 * 1024, 1024, USE_FSR) },
+	{ "n25q00",      INFO(0x20ba21, 0, 64 * 1024, 2048, USE_FSR) },
 
 	/* PMC */
 	{ "pm25lv512",   INFO(0,        0, 32 * 1024,    2, SECT_4K_PMC) },
@@ -965,6 +1013,9 @@  int spi_nor_scan(struct spi_nor *nor, const struct spi_device_id *id,
 	else
 		mtd->_write = spi_nor_write;
 
+	if (info->flags & USE_FSR)
+		nor->wait_till_ready = spi_nor_wait_till_fsr_ready;
+
 	/* prefer "small sector" erase if possible */
 	if (info->flags & SECT_4K) {
 		nor->erase_opcode = SPINOR_OP_BE_4K;
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 5324184..9e6294f 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -34,6 +34,7 @@ 
 #define SPINOR_OP_SE		0xd8	/* Sector erase (usually 64KiB) */
 #define SPINOR_OP_RDID		0x9f	/* Read JEDEC ID */
 #define SPINOR_OP_RDCR		0x35	/* Read configuration register */
+#define SPINOR_OP_RDFSR		0x70	/* Read flag status register */
 
 /* 4-byte address opcodes - used on Spansion and some Macronix flashes. */
 #define SPINOR_OP_READ4		0x13	/* Read data bytes (low frequency) */
@@ -66,6 +67,9 @@ 
 
 #define SR_QUAD_EN_MX		0x40	/* Macronix Quad I/O */
 
+/* Flag Status Register bits */
+#define FSR_READY		0x80
+
 /* Configuration Register bits. */
 #define CR_QUAD_EN_SPAN		0x2	/* Spansion Quad I/O */