From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: Arnaud Mouiche <arnaud.mouiche@gmail.com>
Cc: Peter Pan <peterpansjtu@gmail.com>,
Peter Pan <peterpandong@micron.com>,
Richard Weinberger <richard@nod.at>,
Brian Norris <computersforpeace@gmail.com>,
linux-mtd@lists.infradead.org,
"linshunquan (A)" <linshunquan1@hisilicon.com>
Subject: Re: [PATCH v2 1/6] nand: spi: Add init/release function
Date: Fri, 3 Mar 2017 11:00:03 +0100 [thread overview]
Message-ID: <20170303110003.5d734f1e@bbrezillon> (raw)
In-Reply-To: <eeae52f3-e446-4865-d0c6-2c97b5d9842e@gmail.com>
On Fri, 3 Mar 2017 10:37:04 +0100
Arnaud Mouiche <arnaud.mouiche@gmail.com> wrote:
> On 03/03/2017 10:28, Boris Brezillon wrote:
> > On Fri, 3 Mar 2017 16:37:55 +0800
> > Peter Pan <peterpansjtu@gmail.com> wrote:
> >
> > [..]
> >> BTW, there is another question. read id method is not unique. Micron spi nand
> >> need a dummy byte before reading ID while some vendors don't. Now I define
> >> vendor alias in DTS and use this info to choose right manufacture ops. Do you
> >> have a better idea?
> > Ouch. That's bad news. How about letting the manufacturer code read the
> > ID and detect the NAND?
> >
> > That means you'll iterate over all manufacturer entries in the
> > manufacturer table and call ->detect(). The ->detect() hook will be
> > responsible for reading the ID (with the proper read-id sequence) and
> > initialize the NAND parameters.
> >
> > If we find a common pattern between different vendors, we can then
> > provide default helpers for the read-id and/or detect implementation.
> A effective way will be to read the up to 4 bytes of ID response, and
> ask every manufacturer to provide an ID and mask to compare with.
> Here is the list of ID/MASK I have compiled.
>
> "MT29F1G01AAADD",
> .id = 0x002C1200, .id_mask = 0x00FFFF00,
>
> "MT29F2G01AAAED",
>
> "MT29F4G01AAADD",
> .id = 0x002C3200, .id_mask = 0x00FFFF00,
>
> "GD5F1GQ4xC", /* version U (3.3V) or R (1.8) */
> .id = 0xC8A14800, .id_mask = 0xffefff00, /* 0xC8A148 or
> 0xC8B148 */
>
> "GD5F2GQ4xC", /* version U (3.3V) or R (1.8) */
> .id = 0xC8A24800, .id_mask = 0xffefff00, /* 0xC8A248 or
> 0xC8B248 */
>
> "GD5F1GQ4xBYIG", /* version U (3.3V) or R (1.8) */
> .id = 0x00C8D100, .id_mask = 0x00ffef00, /* C8D1 or C8C1 */
>
> "GD5F2GQ4xBYIG", /* version U (3.3V) or R (1.8) */
> .id = 0x00C8D200, .id_mask = 0x00ffef00, /* C8D2 or C8C2 */
>
> "F50L1G41A", /* ESMT */
> .id = 0x00C8217F, .id_mask = 0x00ffffff,
>
> "W25N01GVZEIG", /* Winbond */
> .id = 0x00EFAA21, .id_mask = 0x00ffffff,
>
> "MX35LF1GE4AB", /* Micronix */
> .id = 0x00C21200, .id_mask = 0x00ffff00,
I'm not a big fan of this approach. See how each vendor seems to have
its own scheme, and we're not even sure they will use the same for
their next chips. That's what happened with raw NANDs, and the NAND ID
parsing just became a huge pile of hacks like that:
if(vendorX and revisionY) then id-should-decoded-like-that;
By letting the detection process to manufacturer code, we just get rid
of this complexity in the core, which is a good thing IMO.
next prev parent reply other threads:[~2017-03-03 10:00 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-01 8:52 [PATCH v2 0/6] Introduction to SPI NAND framework Peter Pan
2017-03-01 8:52 ` [PATCH v2 1/6] nand: spi: Add init/release function Peter Pan
2017-03-01 9:58 ` Boris Brezillon
2017-03-03 8:37 ` Peter Pan
2017-03-03 9:28 ` Boris Brezillon
2017-03-03 9:37 ` Arnaud Mouiche
2017-03-03 10:00 ` Boris Brezillon [this message]
2017-03-03 10:12 ` Arnaud Mouiche
2017-03-03 10:17 ` Boris Brezillon
2017-03-10 7:50 ` Peter Pan
2017-03-10 9:13 ` Arnaud Mouiche
2017-03-01 13:21 ` Thomas Petazzoni
2017-03-03 8:40 ` Peter Pan
2017-03-01 8:52 ` [PATCH v2 2/6] nand: spi: add basic operations support Peter Pan
2017-03-07 17:57 ` Boris Brezillon
2017-03-09 1:43 ` Peter Pan
2017-03-09 6:02 ` Boris Brezillon
2017-03-09 17:09 ` Arnaud Mouiche
2017-03-10 1:58 ` Peter Pan
2017-03-10 7:50 ` Arnaud Mouiche
2017-03-01 8:52 ` [PATCH v2 3/6] nand: spi: Add bad block support Peter Pan
2017-03-08 7:23 ` Boris Brezillon
2017-03-08 7:59 ` Peter Pan
2017-03-01 8:52 ` [PATCH v2 4/6] nand: spi: Add BBT support Peter Pan
2017-03-08 8:31 ` Boris Brezillon
2017-03-09 1:58 ` Peter Pan
2017-03-09 6:12 ` Boris Brezillon
2017-03-01 8:52 ` [PATCH v2 5/6] nand: spi: add Micron spi nand support Peter Pan
2017-03-08 8:32 ` Boris Brezillon
2017-03-09 1:59 ` Peter Pan
2017-03-01 8:52 ` [PATCH v2 6/6] nand: spi: Add generic SPI controller support Peter Pan
2017-03-08 8:44 ` Boris Brezillon
2017-03-09 2:02 ` Peter Pan
2017-03-09 6:06 ` Boris Brezillon
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=20170303110003.5d734f1e@bbrezillon \
--to=boris.brezillon@free-electrons.com \
--cc=arnaud.mouiche@gmail.com \
--cc=computersforpeace@gmail.com \
--cc=linshunquan1@hisilicon.com \
--cc=linux-mtd@lists.infradead.org \
--cc=peterpandong@micron.com \
--cc=peterpansjtu@gmail.com \
--cc=richard@nod.at \
/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