linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Angus CLARK <angus.clark@st.com>
To: linux-mtd@lists.infradead.org
Cc: Huang Shijie <b32955@freescale.com>,
	Brian Norris <computersforpeace@gmail.com>,
	Huang Shijie <shijie8@gmail.com>
Subject: Re: [PATCH V3 3/6] MTD : add the database for the NANDs
Date: Fri, 16 Sep 2011 09:11:00 +0100	[thread overview]
Message-ID: <4E730494.7030509@st.com> (raw)
In-Reply-To: <CAN8TOE9-iEPyWXLsxddeofazgrCWDWKgrx6eBkr7vdKErfgeCA@mail.gmail.com>

Hi Brian, Huang,

Sorry for the long email, but this topic also interests me.

On 09/14/2011 04:44 PM, Brian Norris wrote:
> I see nothing has happened with this thread recently. It doesn't
> deserve to die though.

Having played around with the nand_ids.c and nand_get_flash_type(), I
also think the approach is in need of a bit of an overhaul.  The code is
getting increasingly difficult to follow, given the growing number of
non-standard decoding exceptions.

My first attempt was rather similar to Huang's -- using a static table
of READIDs and extended device properties.  However, this also gets
rather complicated, and again needs to handle special cases.  For
example, early revisions of a NAND device often include 'don't care'
bytes in the READID, or even just shorter READIDs.  We could add a
"matching-mask" to the table, and enforce some ordering to the binding
process (e.g. bind against the first match in the table, or perhaps the
most-specific match in the table?), but the semantics of the
table-ordering is difficult to enforce, especially when new devices are
added later.  Using a static table also has other disadvantages, such as
size and the need to continually update as new devices emerge (my list
is now over 300 devices!).

I ended up refactoring the nand_get_flash_type() code, according to 3
basic schemes:

	'ID 2' : extract properties from nand_flash_ids[].  For 2-byte IDs, or
where device ID gives a non-zero page-size (particularly SP devices).

	'Extended ID': decode properties from ID string where possible, falling
back to nand_flash_ids[].  For 3/4/5-byte IDs.

 	'ID 6'       : decode properties from ID string where possible,
falling back to nand_flash_ids[].  For 6-byte IDs.

The refactoring was primarily aimed at simplifying the way in which
decoding exceptions could be accommodated.

I have tested the code on the all the devices found in Brian's most
excellent table:
> http://linux-mtd.infradead.org/nand-data/nanddata.html

with the following exceptions:
	- ONFI-only devices: decode not possible using READID
	- Multi-CS devices: probe must be repeated on each CS
	- Toshiba devices: difficultly in acquiring the datasheets and the full
READID.

I have also added a few more devices and columns to the table (#CS,
#LUNs, #RBn) which I hope to submit shortly.

I was working on a non-standard NAND driver at the time, which made
little use of nand_base.c, and on an older 2.6.32 tree.  However, if
there is sufficient interest, I am happy at having a go at updating
nand_get_flash_type() on mtd-2.6.

Let me know if you think this might be useful.  Perhaps posting the
standalone test code I used on nanddata.html (actually a csv version of
the table!) would be a good start?

Cheers,

Angus

  parent reply	other threads:[~2011-09-16  8:11 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-30  8:40 [PATCH V3 0/6] add the GPMI controller driver for IMX23/IMX28 Huang Shijie
2011-03-30  8:40 ` [PATCH V3 1/6] ARM: add GPMI support for imx23/imx28 Huang Shijie
2011-03-30  8:40 ` [PATCH V3 2/6] dmaengine: change the flags of request_irq() Huang Shijie
2011-03-30  9:03   ` Lothar Waßmann
2011-03-30  9:13     ` Shawn Guo
2011-03-30  9:15       ` Lothar Waßmann
2011-03-30  9:44         ` Huang Shijie
2011-03-31  7:02         ` [PATCH V3 2/6] dmaengine: add interrupt check for GPMI controller Huang Shijie
2011-03-31  8:02           ` Lothar Waßmann
2011-03-31  8:50             ` Huang Shijie
2011-03-31  8:50               ` Lothar Waßmann
2011-03-31  9:08                 ` Huang Shijie
2011-03-31  9:34                   ` Lothar Waßmann
2011-04-01  3:47                   ` Shawn Guo
2011-04-01  4:36                     ` Huang Shijie
2011-03-30  8:40 ` [PATCH V3 3/6] MTD : add the database for the NANDs Huang Shijie
2011-03-30  8:46   ` Florian Fainelli
2011-03-30  9:05     ` Huang Shijie
2011-03-30  9:23       ` Florian Fainelli
2011-03-30  9:54         ` Huang Shijie
2011-03-31 10:10       ` Artem Bityutskiy
2011-03-31 14:17         ` Huang Shijie
2011-09-14 15:44           ` Brian Norris
2011-09-15  2:21             ` Huang Shijie
2011-09-16  8:11             ` Angus CLARK [this message]
2011-11-21 22:18               ` Brian Norris
2011-12-06 12:06                 ` Angus CLARK
2011-11-24  3:11             ` Huang Shijie
2011-03-30  8:40 ` [PATCH V3 4/6] MTD : add the common code for GPMI controller driver Huang Shijie
2011-03-30  8:40 ` [PATCH V3 5/6] MTD: add support for imx23 and imx28 Huang Shijie
2011-03-30  8:40 ` [PATCH V3 6/6] MTD : add GPMI driver in the config and Makefile 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=4E730494.7030509@st.com \
    --to=angus.clark@st.com \
    --cc=b32955@freescale.com \
    --cc=computersforpeace@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=shijie8@gmail.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;
as well as URLs for NNTP newsgroup(s).