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
next prev 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).