All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@free-electrons.com>
To: "Bean Huo (beanhuo)" <beanhuo@micron.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"pawel.moll@arm.com" <pawel.moll@arm.com>,
	Campbell <ijc+devicetree@hellion.org.uk>,
	"richard@nod.at" <richard@nod.at>,
	Mark Rutland <mark.rutland@arm.com>,
	"marek.vasut@gmail.com" <marek.vasut@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"galak@codeaurora.org" <galak@codeaurora.org>,
	Cyrille Pitchen <cyrille.pitchen@atmel.com>,
	"computersforpeace@gmail.com" <computersforpeace@gmail.com>
Subject: Re: [PATCH 4/5] mtd: nand: add support for Micron on-die ECC
Date: Tue, 11 Apr 2017 14:51:02 +0200	[thread overview]
Message-ID: <20170411145102.563fa388@bbrezillon> (raw)
In-Reply-To: <414dd35931814ce38381a251917ad79f@SIWEX5A.sing.micron.com>

Hi Bean,

On Mon, 3 Apr 2017 11:31:05 +0000
"Bean Huo (beanhuo)" <beanhuo@micron.com> wrote:

> Hi, Boris and Thomas
> 
> >>
> >> Ok, but I recommend that 70s should be the first choice on this single
> >> solution, it doesn't need to read twice to detect its bitflips count.  
> >
> >That's exactly why we need to differentiate the 2 chips.  
> 
> Sorry for later this response. 
> Below is the pseudo codes about how to differentiate these 2 series parallel
> NAND with on-die ECC:
> 
> if (NAND == SLC ) { // on-die ECC only exists in SLC
> //check device ID byte 4
>      if ((ID.byte4 & 0x02) == 0x02) {// internal ECC level ==10b

So here the MT29F1G08ABADAWP datasheet says 0x2 <=> 4bit/512bytes ECC.

> 	if (ID.byte4 & 0x80) {//on-Die ECC enabled

Did you read my last reply?
Thomas discovered that ID[4].bit7 is actually reflecting the ECC engine
state (1 if the engine is enabled, 0 if it's disabled), not whether the
NAND supports on-die ECC or not, so no this test is not reliable.

>                     if (ONFI.byte112 == 4)
> 		 60s SLC NAND with on-die ECC
> 	    else if (ONFI.byte112 == 8)
>      	              70s SLC NAND with on-die ECC

This is completely fucked up! Now the ONFI param page says the NAND
requires 8bits/512bytes, while the ID bytes advertised an on-die ECC
providing 4bits/512bytes correctability.
So either your algorithm is wrong, or the ID and ONFI param page are
contracting (not sure what solution I'd prefer...).

> 	    else
>                           Doesn't support on-die ECC

Sorry to say that, but I find it worrisome that even someone from Micron
is not able to get it right.

I think we'll stick to the model name to detect whether on-die ECC is
supported.

Regards,

Boris

WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
To: "Bean Huo (beanhuo)" <beanhuo-AL4WhLSQfzjQT0dZR+AlfA@public.gmane.org>
Cc: Thomas Petazzoni
	<thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
	"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"pawel.moll-5wv7dgnIgG8@public.gmane.org"
	<pawel.moll-5wv7dgnIgG8@public.gmane.org>,
	Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
	"richard-/L3Ra7n9ekc@public.gmane.org"
	<richard-/L3Ra7n9ekc@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	"marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
	<marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	"linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org"
	<galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	Cyrille Pitchen
	<cyrille.pitchen-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>,
	"computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org"
	<computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH 4/5] mtd: nand: add support for Micron on-die ECC
Date: Tue, 11 Apr 2017 14:51:02 +0200	[thread overview]
Message-ID: <20170411145102.563fa388@bbrezillon> (raw)
In-Reply-To: <414dd35931814ce38381a251917ad79f-aBoyCxvc2dBaXkNJqdKpEhSpLNRU/VIH@public.gmane.org>

Hi Bean,

On Mon, 3 Apr 2017 11:31:05 +0000
"Bean Huo (beanhuo)" <beanhuo-AL4WhLSQfzjQT0dZR+AlfA@public.gmane.org> wrote:

> Hi, Boris and Thomas
> 
> >>
> >> Ok, but I recommend that 70s should be the first choice on this single
> >> solution, it doesn't need to read twice to detect its bitflips count.  
> >
> >That's exactly why we need to differentiate the 2 chips.  
> 
> Sorry for later this response. 
> Below is the pseudo codes about how to differentiate these 2 series parallel
> NAND with on-die ECC:
> 
> if (NAND == SLC ) { // on-die ECC only exists in SLC
> //check device ID byte 4
>      if ((ID.byte4 & 0x02) == 0x02) {// internal ECC level ==10b

So here the MT29F1G08ABADAWP datasheet says 0x2 <=> 4bit/512bytes ECC.

> 	if (ID.byte4 & 0x80) {//on-Die ECC enabled

Did you read my last reply?
Thomas discovered that ID[4].bit7 is actually reflecting the ECC engine
state (1 if the engine is enabled, 0 if it's disabled), not whether the
NAND supports on-die ECC or not, so no this test is not reliable.

>                     if (ONFI.byte112 == 4)
> 		 60s SLC NAND with on-die ECC
> 	    else if (ONFI.byte112 == 8)
>      	              70s SLC NAND with on-die ECC

This is completely fucked up! Now the ONFI param page says the NAND
requires 8bits/512bytes, while the ID bytes advertised an on-die ECC
providing 4bits/512bytes correctability.
So either your algorithm is wrong, or the ID and ONFI param page are
contracting (not sure what solution I'd prefer...).

> 	    else
>                           Doesn't support on-die ECC

Sorry to say that, but I find it worrisome that even someone from Micron
is not able to get it right.

I think we'll stick to the model name to detect whether on-die ECC is
supported.

Regards,

Boris
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2017-04-11 12:51 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <538805ebf8e64015a8b833de755652b3@SIWEX5A.sing.micron.com>
2017-03-22 13:20 ` [PATCH 4/5] mtd: nand: add support for Micron on-die ECC Bean Huo (beanhuo)
2017-03-22 13:20   ` Bean Huo (beanhuo)
2017-03-22 13:45   ` Boris Brezillon
2017-03-22 13:45     ` Boris Brezillon
2017-03-22 14:01     ` Arnaud Mouiche
2017-03-22 14:39     ` Bean Huo (beanhuo)
2017-03-22 14:39       ` Bean Huo (beanhuo)
2017-03-22 14:52       ` Boris Brezillon
2017-03-22 14:52         ` Boris Brezillon
2017-03-22 17:11         ` Bean Huo (beanhuo)
2017-03-22 17:11           ` Bean Huo (beanhuo)
2017-04-03 11:31         ` Bean Huo (beanhuo)
2017-04-03 11:31           ` Bean Huo (beanhuo)
2017-04-11 12:51           ` Boris Brezillon [this message]
2017-04-11 12:51             ` Boris Brezillon
2017-04-11 14:26             ` Bean Huo (beanhuo)
2017-04-11 14:26               ` Bean Huo (beanhuo)
2017-04-11 14:49               ` Boris Brezillon
2017-04-11 14:49                 ` Boris Brezillon
2017-04-11 15:10                 ` Boris Brezillon
2017-04-11 15:10                   ` Boris Brezillon
2017-04-11 15:28                   ` Bean Huo (beanhuo)
2017-04-11 15:28                     ` Bean Huo (beanhuo)
2017-04-11 15:02             ` Bean Huo (beanhuo)
2017-04-11 15:02               ` Bean Huo (beanhuo)
2017-04-11 15:30               ` Boris Brezillon
2017-04-11 15:30                 ` Boris Brezillon
2017-04-11 17:01                 ` Bean Huo (beanhuo)
2017-04-11 17:01                   ` Bean Huo (beanhuo)
2017-04-12  7:03                   ` Boris Brezillon
2017-04-12  7:03                     ` Boris Brezillon
2017-04-13 14:08                     ` Bean Huo (beanhuo)
2017-04-13 14:08                       ` Bean Huo (beanhuo)
2017-03-21 10:38 [PATCH 0/5] mtd: nand: add support for " Thomas Petazzoni
2017-03-21 10:38 ` [PATCH 4/5] mtd: nand: add support for Micron " Thomas Petazzoni
2017-03-21 10:38   ` Thomas Petazzoni

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=20170411145102.563fa388@bbrezillon \
    --to=boris.brezillon@free-electrons.com \
    --cc=beanhuo@micron.com \
    --cc=computersforpeace@gmail.com \
    --cc=cyrille.pitchen@atmel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marek.vasut@gmail.com \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=richard@nod.at \
    --cc=robh+dt@kernel.org \
    --cc=thomas.petazzoni@free-electrons.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 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.