linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Markus Pargmann <mpa@pengutronix.de>
To: Boris Brezillon <boris.brezillon@free-electrons.com>
Cc: Han Xu <han.xu@nxp.com>, David Woodhouse <dwmw2@infradead.org>,
	Fabio Estevam <fabio.estevam@freescale.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"kernel@pengutronix.de" <kernel@pengutronix.de>,
	Huang Shijie <shijie.huang@intel.com>,
	Brian Norris <computersforpeace@gmail.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Stefan Christ <s.christ@phytec.de>,
	Elie De Brauwer <eliedebrauwer@gmail.com>
Subject: Re: [PATCH RESEND] gpmi-nand: Handle ECC Errors in erased pages
Date: Fri, 15 Apr 2016 09:55:45 +0200	[thread overview]
Message-ID: <7168760.YSQBa3GsdA@adelgunde> (raw)
In-Reply-To: <20160413005155.03cb7bc6@bbrezillon>

[-- Attachment #1: Type: text/plain, Size: 2418 bytes --]

On Wednesday 13 April 2016 00:51:55 Boris Brezillon wrote:
> On Tue, 12 Apr 2016 22:39:08 +0000
> Han Xu <han.xu@nxp.com> wrote:
> 
> > > Thanks for the feedback. Talking with a coworker about this we may have found a
> > > better approach to this that is less complicated to implement. The hardware
> > > unit allows us to set a bitflip threshold for erased pages. The ECC unit
> > > creates an ECC error only if the number of bitflips exceeds this threshold, but
> > > it does not correct these. So the idea is to change the patch so that we set
> > > pages, that are signaled by the ECC as erased, to 0xff completely without
> > > checking. So the ECC will do all the work and we completely trust in its
> > > abilities to do it correctly.
> > 
> > Sounds good.
> > 
> > some new platforms with new gpmi controller could check the count of 0 bits in page,
> > refer to my patch https://patchwork.ozlabs.org/patch/587124/
> > 
> > But for all legacy platforms, IMO, considering bitflip is rare case, set threshold to 0 and
> > only check the uncorrectable branch and then correct data sounds better. Setting threshold
> > and correcting all erased page may highly impact the performance.
> 
> Indeed, bitflips in erased pages is not so common, and penalizing the
> likely case (erased pages without any bitflips) doesn't look like a good
> idea in the end.

Are erased pages really read that often? I am not sure how UBI handles
this, does it read every page before writing?

> 
> You can still implement this check in software. You can have a look at
> nand_check_erased_ecc_chunk() [1] if you need an example, but you'll
> have to adapt it because your controller does not guarantees that ECC
> bits for a given chunk are byte aligned :-/

Yes I used this function in the patch. The issue is that I am not quite
sure yet where to find the raw ECC data (without rereading the page).
The reference manual is not extremely clear about that, ecc data may be
in the 'auxilliary data' but I am not sure that it really is available
somewhere.

Best Regards,

Markus

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2016-04-15  7:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-21 12:52 [PATCH RESEND] gpmi-nand: Handle ECC Errors in erased pages Markus Pargmann
2016-02-24 13:57 ` Boris Brezillon
2016-04-11  6:34   ` Markus Pargmann
2016-04-11  7:29     ` Boris Brezillon
2016-04-12 22:39       ` Han Xu
2016-04-12 22:51         ` Boris Brezillon
2016-04-15  7:55           ` Markus Pargmann [this message]
2016-04-15  8:35             ` Boris Brezillon
2016-04-15  9:35               ` Markus Pargmann
2016-04-15  9:39                 ` Boris Brezillon
2016-04-15 12:03                   ` Markus Pargmann
2016-04-15 15:33                     ` Han Xu
2016-04-15 15:40                       ` Boris Brezillon
2016-04-18 10:07                         ` Markus Pargmann
2016-04-18 14:47                   ` Stefan Christ
2016-04-18 15:10                     ` Boris Brezillon

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=7168760.YSQBa3GsdA@adelgunde \
    --to=mpa@pengutronix.de \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=eliedebrauwer@gmail.com \
    --cc=fabio.estevam@freescale.com \
    --cc=han.xu@nxp.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=s.christ@phytec.de \
    --cc=shijie.huang@intel.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).