From: boris.brezillon@free-electrons.com (Boris Brezillon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] mtd: nand: automate NAND timings selection
Date: Tue, 6 Sep 2016 10:41:30 +0200 [thread overview]
Message-ID: <20160906104130.61605fa4@bbrezillon> (raw)
In-Reply-To: <20160906082302.4itzqv4ldd3foazu@pengutronix.de>
On Tue, 6 Sep 2016 10:23:02 +0200
Sascha Hauer <s.hauer@pengutronix.de> wrote:
> Hi Boris,
>
> On Fri, Sep 02, 2016 at 02:42:28PM +0200, Sascha Hauer wrote:
> > +static int nand_configure_data_interface(struct mtd_info *mtd)
> > +{
> > + struct nand_chip *chip = mtd_to_nand(mtd);
> > + struct nand_data_interface *conf;
> > + int modes, mode, ret = -EINVAL;
> > + uint8_t tmode_param[ONFI_SUBFEATURE_PARAM_LEN] = { };
> > + int i;
> > +
> > + conf = kzalloc(sizeof(*conf), GFP_KERNEL);
> > + if (!conf)
> > + return -ENOMEM;
> > +
> > + /* TODO: support DDR interfaces */
> > + conf->type = NAND_SDR_IFACE;
> > +
> > + /*
> > + * First try to identify the best timings from ONFI parameters and
> > + * if the NAND does not support ONFI, fallback to the default ONFI
> > + * timing mode.
> > + */
> > + modes = onfi_get_async_timing_mode(chip);
> > + if (modes == ONFI_TIMING_MODE_UNKNOWN) {
> > + mode = chip->onfi_timing_mode_default;
> > + conf->timings.sdr =
> > + *onfi_async_timing_mode_to_sdr_timings(mode);
> > +
> > + ret = nand_check_data_interface(mtd, conf);
> > + } else {
> > + for (mode = fls(modes) - 1; mode >= 0; mode--) {
> > + conf->timings.sdr =
> > + *onfi_async_timing_mode_to_sdr_timings(mode);
> > +
> > + ret = nand_check_data_interface(mtd, conf);
> > + if (!ret)
> > + break;
> > + }
> > + }
>
> I wonder if this works good for non ONFI NANDs. In the ONFI case we
> iterate over all modes supported by the NAND until we find one that also
> suits the driver. By doing so we inherently assume that not all drivers
> support all modes. In the non ONFI case instead we hardcode a single
> timing into the nand_id table, what if the driver does not support this
> timing? It will fail in this case without ever trying slower timings.
> Shouldn't we encode the mode bitmask into the nand_id table rather than
> a single timing?
IIRC, this is what I proposed in my first patch (having a bitmask
encoding supported modes), but Brian suggested to directly put the
highest supported mode.
Anyway, I don't think a NAND can support higher modes without
supporting lower ones, so extracting the supported modes info from the
default_onfi_timing_mode should be pretty easy:
supported_modes = GENMASK(default_onfi_timing_mode, 0);
> I cannot find a chip in the nand_id table which actually sets
> onfi_timing_mode_default, but since you introduced the field in the
> nand_id table with commit 57a94e24bc92 you can probably tell me more.
Hm, this one [1] is defining timing mode 4.
[1]http://lxr.free-electrons.com/source/drivers/mtd/nand/nand_ids.c#L51
next prev parent reply other threads:[~2016-09-06 8:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-02 12:42 mtd: nand: automate NAND timings selection Sascha Hauer
2016-09-02 12:42 ` [PATCH 1/2] " Sascha Hauer
2016-09-05 6:51 ` Boris Brezillon
2016-09-05 11:09 ` Sascha Hauer
2016-09-05 13:26 ` Boris Brezillon
2016-09-06 8:23 ` Sascha Hauer
2016-09-06 8:41 ` Boris Brezillon [this message]
2016-09-06 9:30 ` Sascha Hauer
2016-09-02 12:42 ` [PATCH 2/2] mtd: mxc_nand: Set timing for v2 controllers Sascha Hauer
2016-09-02 14:17 ` Lothar Waßmann
2016-09-05 7:05 ` 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=20160906104130.61605fa4@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).