From: Marek Vasut <marex@denx.de>
To: Huang Shijie <b32955@freescale.com>
Cc: Graham Moore <grmoore@altera.com>,
ggrahammoore@gmail.com,
Geert Uytterhoeven <geert+renesas@linux-m68k.org>,
Artem Bityutskiy <artem.bityutskiy@linux.intel.com>,
Sascha Hauer <s.hauer@pengutronix.de>,
Jingoo Han <jg1.han@samsung.com>,
linux-kernel@vger.kernel.org,
Yves Vandervennet <rocket.yvanderv@gmail.com>,
linux-mtd@lists.infradead.org,
Insop Song <insop.song@gainspeed.com>,
Alan Tull <atull@altera.com>,
Sourav Poddar <sourav.poddar@ti.com>,
Brian Norris <computersforpeace@gmail.com>,
David Woodhouse <dwmw2@infradead.org>,
Dinh Nguyen <dinguyen@altera.com>
Subject: Re: [PATCH V3] Add support for flag status register on Micron chips.
Date: Sat, 26 Apr 2014 00:12:24 +0200 [thread overview]
Message-ID: <201404260012.24311.marex@denx.de> (raw)
In-Reply-To: <20140425015245.GB24530@localhost>
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 ...
next prev parent reply other threads:[~2014-04-25 22:12 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-22 14:03 [PATCH V3] Add support for flag status register on Micron chips Graham Moore
2014-04-22 14:03 ` Graham Moore
2014-04-22 16:55 ` Marek Vasut
2014-04-22 18:48 ` Graham Moore
2014-04-22 18:58 ` Marek Vasut
2014-04-25 4:47 ` Huang Shijie
2014-04-25 15:50 ` Marek Vasut
2014-04-22 18:45 ` Gerhard Sittig
2014-04-22 19:17 ` Graham Moore
2014-04-25 1:34 ` Huang Shijie
2014-04-25 2:42 ` Marek Vasut
2014-04-25 1:52 ` Huang Shijie
2014-04-25 22:12 ` Marek Vasut [this message]
2014-04-26 3:10 ` Huang Shijie
2014-04-28 5:06 ` Marek Vasut
2014-04-28 7:06 ` Huang Shijie
2014-04-28 14:22 ` Graham Moore
2014-04-28 15:37 ` Huang Shijie
2014-07-12 2:07 ` Brian Norris
2014-04-25 1:54 ` Huang Shijie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201404260012.24311.marex@denx.de \
--to=marex@denx.de \
--cc=artem.bityutskiy@linux.intel.com \
--cc=atull@altera.com \
--cc=b32955@freescale.com \
--cc=computersforpeace@gmail.com \
--cc=dinguyen@altera.com \
--cc=dwmw2@infradead.org \
--cc=geert+renesas@linux-m68k.org \
--cc=ggrahammoore@gmail.com \
--cc=grmoore@altera.com \
--cc=insop.song@gainspeed.com \
--cc=jg1.han@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=rocket.yvanderv@gmail.com \
--cc=s.hauer@pengutronix.de \
--cc=sourav.poddar@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox