From: boris.brezillon@free-electrons.com (Boris Brezillon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 6/7] mtd: nand: mxc: implement onfi get/set features
Date: Tue, 6 Sep 2016 14:52:37 +0200 [thread overview]
Message-ID: <20160906145237.0d2c936b@bbrezillon> (raw)
In-Reply-To: <20160906124714.5bidphcpp2oa5yxn@pengutronix.de>
On Tue, 6 Sep 2016 14:47:14 +0200
Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Tue, Sep 06, 2016 at 02:05:21PM +0200, Boris Brezillon wrote:
> > On Tue, 6 Sep 2016 12:39:14 +0200
> > Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >
> > > To be able to support different ONFI timing modes we have to implement
> > > the onfi_set_features and onfi_get_features. Tested on an i.MX25 SoC.
> > >
> > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > ---
> > > drivers/mtd/nand/mxc_nand.c | 53 +++++++++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 53 insertions(+)
> > >
> > > diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
> > > index 5173fad..1db8299 100644
> > > --- a/drivers/mtd/nand/mxc_nand.c
> > > +++ b/drivers/mtd/nand/mxc_nand.c
> > > @@ -1239,6 +1239,57 @@ static void mxc_nand_command(struct mtd_info *mtd, unsigned command,
> > > }
> > > }
> > >
> > > +static int mxc_nand_onfi_set_features(struct mtd_info *mtd, struct nand_chip *chip,
> > > + int addr, uint8_t *subfeature_param)
> > > +{
> > > + struct nand_chip *nand_chip = mtd_to_nand(mtd);
> > > + struct mxc_nand_host *host = nand_get_controller_data(nand_chip);
> > > + int i;
> > > +
> > > + if (!chip->onfi_version ||
> > > + !(le16_to_cpu(chip->onfi_params.opt_cmd)
> > > + & ONFI_OPT_CMD_SET_GET_FEATURES))
> > > + return -EINVAL;
> > > +
> > > + host->buf_start = 0;
> > > +
> > > + for (i = 0; i < ONFI_SUBFEATURE_PARAM_LEN; ++i)
> > > + chip->write_byte(mtd, subfeature_param[i]);
> > > +
> > > + memcpy32_toio(host->main_area0, host->data_buf, mtd->writesize);
> > > + host->devtype_data->send_cmd(host, NAND_CMD_SET_FEATURES, false);
> > > + mxc_do_addr_cycle(mtd, addr, -1);
> > > + host->devtype_data->send_page(mtd, NFC_INPUT);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int mxc_nand_onfi_get_features(struct mtd_info *mtd, struct nand_chip *chip,
> > > + int addr, uint8_t *subfeature_param)
> > > +{
> > > + struct nand_chip *nand_chip = mtd_to_nand(mtd);
> > > + struct mxc_nand_host *host = nand_get_controller_data(nand_chip);
> > > + int i;
> > > +
> > > + if (!chip->onfi_version ||
> > > + !(le16_to_cpu(chip->onfi_params.opt_cmd)
> > > + & ONFI_OPT_CMD_SET_GET_FEATURES))
> > > + return -EINVAL;
> > > +
> > > + *(uint32_t *)host->main_area0 = 0xdeadbeef;
>
> This line should be removed by the way.
>
> > > +
> > > + host->devtype_data->send_cmd(host, NAND_CMD_GET_FEATURES, false);
> > > + mxc_do_addr_cycle(mtd, addr, -1);
> > > + host->devtype_data->send_page(mtd, NFC_OUTPUT);
> > > + memcpy32_fromio(host->data_buf, host->main_area0, 512);
> > > + host->buf_start = 0;
> > > +
> > > + for (i = 0; i < ONFI_SUBFEATURE_PARAM_LEN; ++i)
> > > + *subfeature_param++ = chip->read_byte(mtd);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > /*
> > > * The generic flash bbt decriptors overlap with our ecc
> > > * hardware, so define some i.MX specific ones.
> > > @@ -1513,6 +1564,8 @@ static int mxcnd_probe(struct platform_device *pdev)
> > > this->read_word = mxc_nand_read_word;
> > > this->write_buf = mxc_nand_write_buf;
> > > this->read_buf = mxc_nand_read_buf;
> > > + this->onfi_set_features = mxc_nand_onfi_set_features;
> > > + this->onfi_get_features = mxc_nand_onfi_get_features;
> >
> > Do you really have to re-implement ->onfi_{set,get}_features()?
> > How about adding support for this command in your ->cmdfunc()
> > implementation and relying on the default ->onfi_{set,get}_features()
> > provided by the core?
>
> I probably could. The problem is that the generic
> nand_onfi_set_features() first sends the command then afterwards uses
> chip->write_byte to actually send the data. This is not how the mxc_nand
> controller works. On mxc_nand I first need the data before I can issue
> the command.
> I could implement it in the ->cmdfunc() like: When NAND_CMD_SET_FEATURES
> is issued, track that information. Then I have to count how many times
> ->write_byte() has been called and when I reach
> ONFI_SUBFEATURE_PARAM_LEN I have to send the command. While that would
> probably work I was glad that I could avoid that. It's one of the
> places where one realizes that the nand core layer is built around the
> nand controllers of the late nineties.
Okay. Actually I have some plans for these problems, but let's stick to
mxc_nand_onfi_{set,get}_features() for now.
next prev parent reply other threads:[~2016-09-06 12:52 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-06 10:39 [PATCH v2] mtd: nand: automate NAND timings selection Sascha Hauer
2016-09-06 10:39 ` [PATCH 1/7] mtd: nand: Create a NAND reset function Sascha Hauer
2016-09-06 11:18 ` Boris Brezillon
2016-09-06 13:02 ` Sascha Hauer
2016-09-06 13:06 ` Boris Brezillon
2016-09-06 10:39 ` [PATCH 2/7] mtd: nand: Introduce nand_data_interface Sascha Hauer
2016-09-06 11:21 ` Boris Brezillon
2016-09-06 13:34 ` Sascha Hauer
2016-09-06 13:46 ` Boris Brezillon
2016-09-06 14:09 ` Sascha Hauer
2016-09-06 10:39 ` [PATCH 3/7] mtd: nand: convert ONFI mode into data interface Sascha Hauer
2016-09-06 11:27 ` Boris Brezillon
2016-09-06 12:15 ` Boris Brezillon
2016-09-06 10:39 ` [PATCH 4/7] mtd: nand: automate NAND timings selection Sascha Hauer
2016-09-06 11:58 ` Boris Brezillon
2016-09-06 14:08 ` Sascha Hauer
2016-09-06 14:50 ` Boris Brezillon
2016-09-06 15:04 ` Sascha Hauer
2016-09-06 15:15 ` Boris Brezillon
2016-09-06 10:39 ` [PATCH 5/7] mtd: nand: sunxi: switch from manual to automated timing config Sascha Hauer
2016-09-06 12:01 ` Boris Brezillon
2016-09-06 10:39 ` [PATCH 6/7] mtd: nand: mxc: implement onfi get/set features Sascha Hauer
2016-09-06 12:05 ` Boris Brezillon
2016-09-06 12:47 ` Sascha Hauer
2016-09-06 12:52 ` Boris Brezillon [this message]
2016-09-06 10:39 ` [PATCH 7/7] mtd: nand: mxc: Add timing setup for v2 controllers Sascha Hauer
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=20160906145237.0d2c936b@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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;
as well as URLs for NNTP newsgroup(s).