From: Artem Bityutskiy <dedekind1@gmail.com>
To: Brian Norris <norris@broadcom.com>
Cc: David Woodhouse <dwmw2@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Maxim Levitsky <maximlevitsky@gmail.com>
Subject: Re: [PATCH] mtd/nand: Support Micron chips, 4KB page
Date: Thu, 05 Aug 2010 07:31:04 +0300 [thread overview]
Message-ID: <1280982664.4363.17.camel@localhost.localdomain> (raw)
In-Reply-To: <4C4DEA3D.5070208@broadcom.com>
On Mon, 2010-07-26 at 13:04 -0700, Brian Norris wrote:
> The following parts exhibit some interesting patterns in their ID strings.
> Their ID strings are not fully compatible with the current nand_base.c
> detection algorithm. In order to detect them properly, I have taken the
> liberty to develop a heuristic algorithm. None of these chips have a *good*
> detection pattern listed in their datasheets, although MT29F16G08MAA has a
> table on p.24 of its data sheet (not included here).
>
> Part ID String Block Page OOB
> MT29F16G08ABABA 2C 48 00 26 89 00 00 512K 4K 224
> MT29F16G08CBABA 2C 48 04 46 85 00 00 1024K 4K 224
> MT29F16G08MAA 2C D5 94 3E 74 00 00 512K 4K 218
>
> I have attached a table logging most of the relevant data for the many chips
> I have researched. The three chips are highlighted red, although there are
> variants of the chips listed as well. I believe this patch should correctly
> identify all the 5-byte ID Micron chips.
>
> And before the question is asked: I realize that these chips support ONFI,
> so that should be the primary means by which to identify them, but I would
> still like to be able to detect these properly without ONFI if necessary,
> especially considering some of the older NAND controllers we still use do not
> support reading ONFI data.
>
> Feedback on my logic is appreciated.
>
> Signed-off-by: Brian Norris <norris@broadcom.com>
Really not sure about this patch. Sounds like ONFI should be used,
except for those few chips which do not support reading ONFI data. The
heuristics you add smell fishy...
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
prev parent reply other threads:[~2010-08-05 4:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-26 20:04 [PATCH] mtd/nand: Support Micron chips, 4KB page Brian Norris
2010-07-27 19:42 ` [PATCH v2] mtd/nand: Support Micron chips, pagesize >= 4KB Brian Norris
2010-07-28 8:36 ` Matthieu CASTET
2010-07-29 23:28 ` Brian Norris
2010-08-22 8:14 ` Artem Bityutskiy
2010-08-22 8:20 ` Artem Bityutskiy
2010-08-22 22:20 ` Kevin Cernekee
2010-08-23 8:22 ` Matthieu CASTET
2010-08-23 21:48 ` Kevin Cernekee
2010-08-24 6:10 ` Artem Bityutskiy
2010-08-26 0:43 ` Kevin Cernekee
2010-08-30 12:32 ` Artem Bityutskiy
2010-08-05 4:31 ` Artem Bityutskiy [this message]
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=1280982664.4363.17.camel@localhost.localdomain \
--to=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=maximlevitsky@gmail.com \
--cc=norris@broadcom.com \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.