From: Boris Brezillon <boris.brezillon@bootlin.com>
To: "Bean Huo (beanhuo)" <beanhuo@micron.com>
Cc: Richard Weinberger <richard@nod.at>,
Miquel Raynal <miquel.raynal@bootlin.com>,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Chris Packham <chris.packham@alliedtelesis.co.nz>,
David Woodhouse <dwmw2@infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
Marek Vasut <marek.vasut@gmail.com>
Subject: Re: [EXT] Re: [PATCH 2/2] mtd: rawnand: micron: Fix on-die ECC detection logic
Date: Thu, 12 Jul 2018 10:57:15 +0200 [thread overview]
Message-ID: <20180712105715.3574016d@bbrezillon> (raw)
In-Reply-To: <81218b8d34df4881af81bb36fa55bf44@SIWEX5A.sing.micron.com>
On Thu, 12 Jul 2018 08:40:33 +0000
"Bean Huo (beanhuo)" <beanhuo@micron.com> wrote:
> Hi, Boris
> It is true. Bit7 of byte4 in READID changes after enable/disable internal ECC in case of its default value is 0.
> Also this bit value is volatile. After power cyling, it resets to default value.
That's actually a good thing that ECC status get resets on PoR. I'd
wish that would be the case when issuing a SW reset (RESET command),
but unfortunately it's not.
> I don't know if
> this condition will be changed or kept since maybe it was a specific design request from customers.
> But GET Feature is still the preferred way to determine the state of ECC, we recommend using this way.
> If internal ECC is default on, we don't do anything, and if default is off, then SET feature and GET feature.
> This always makes sense.
No, it doesn't work. When Linux acquires control on the NAND, we don't
know what was done before (maybe u-boot enabled ECC and didn't disable
it), so checking READID[4].bit7 only does not work. We need to first
disable the ECC through the SET_FEATURES(DIS_ECC) and then check the
READID bytes.
Also, using GET_FEATURES() does not work either, because Micron NANDs
with "forced on-die ECC" do not expose the ECC status in the 0x90
(Array Operation Mode) feature reg. So if we do that we report ECC as
always disabled which means "not supported"
>
> I am still digging into why this doesn't depict in datasheet and whether this will be kept in coming design.
> As long I have new update, I will back to you.
Arrrggg! Please don't change that in future designs. We seem to have
something that works to detect whether on-die ECC is supported and if
it can be disabled.
prev parent reply other threads:[~2018-07-12 8:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1be1ede4dcf14f24b68b8497b167c1b3@SIWEX5A.sing.micron.com>
2018-07-11 10:32 ` [PATCH 2/2] mtd: rawnand: micron: Fix on-die ECC detection logic Boris Brezillon
2018-07-11 11:41 ` [EXT] " Bean Huo (beanhuo)
2018-07-12 8:40 ` Bean Huo (beanhuo)
2018-07-12 8:57 ` Boris Brezillon [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=20180712105715.3574016d@bbrezillon \
--to=boris.brezillon@bootlin.com \
--cc=beanhuo@micron.com \
--cc=chris.packham@alliedtelesis.co.nz \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marek.vasut@gmail.com \
--cc=miquel.raynal@bootlin.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 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.