All of lore.kernel.org
 help / color / mirror / Atom feed
From: pekon <pekon@pek-sem.com>
To: Roger Quadros <rogerq@ti.com>, Tony Lindgren <tony@atomide.com>,
	"Rini, Tom" <trini@ti.com>
Cc: computersforpeace@gmail.com, dwmw2@infradead.org,
	ezequiel@vanguardiasur.com.ar, linux-mtd@lists.infradead.org,
	linux-omap@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH] mtd: nand: omap: Fix NAND enumeration on 3430 LDP
Date: Sat, 15 Nov 2014 16:42:17 +0530	[thread overview]
Message-ID: <54673511.80205@pek-sem.com> (raw)
In-Reply-To: <54649612.8090402@ti.com>

Hi,

On Thursday 13 November 2014 04:59 PM, Roger Quadros wrote:
[...]
>
> What about performance impact? OMAP3 doesn't have ELM module. So error location
> for BCH8 has to be done in software.
>

Performance impact happens only when there are bit-flips in an page.
- For BCH8_HW ECC schemes
ELM comes in the picture only when during reads there is an ECC 
mis-match, if there is no ECC mis-match GPMC engine alone handles all 
the decoding part.

- For BCH8_SW ECC schemes
Same-way, lib/bch.8: decode_bch() path is taken only when ECC mismatch 
is detected on the read path, for normal read/write GPMC engine handles 
everything.

Yes, you may argue that with aging of the NAND the occurrence of 
bit-flips is common. That's true, but for new devices especially for SLC 
NAND the occurrence is usually rare on fresh parts. Also considering 
that most SLC are now manufactured in matured technologies.

Also, if you are using UBIFS on top of NAND, then it will scrub the data 
on first detection of bit-flips, thereby reducing the accumulation of 
bit-flips and thereby conserving read performance.


>>
>>
[...]
>> Right no objections to using BCH8 for rootfs, except it stopped working
>> over past year or so.
>
> This would be BCH8-sw on OMAP3 right? AM3xx uses BCH8-hw and that seems to work fine.
> So it seems nobody has used/tested BCH8-sw.
>
I have tested BCH8_SW on both AM335x and later SoC, and checked its 
compatibility with various combinations of u-boot. [1] should give you 
some indications of various combinations users can try ..


with regards, pekon

[1]
http://processors.wiki.ti.com/index.php/Linux_Core_NAND_User%27s_Guide#ECC_schemes_support


------------------------
Powered by BigRock.com

WARNING: multiple messages have this Message-ID (diff)
From: pekon <pekon@pek-sem.com>
To: Roger Quadros <rogerq@ti.com>, Tony Lindgren <tony@atomide.com>,
	"Rini, Tom" <trini@ti.com>
Cc: computersforpeace@gmail.com, stable@vger.kernel.org,
	linux-mtd@lists.infradead.org, ezequiel@vanguardiasur.com.ar,
	linux-omap@vger.kernel.org, dwmw2@infradead.org
Subject: Re: [PATCH] mtd: nand: omap: Fix NAND enumeration on 3430 LDP
Date: Sat, 15 Nov 2014 16:42:17 +0530	[thread overview]
Message-ID: <54673511.80205@pek-sem.com> (raw)
In-Reply-To: <54649612.8090402@ti.com>

Hi,

On Thursday 13 November 2014 04:59 PM, Roger Quadros wrote:
[...]
>
> What about performance impact? OMAP3 doesn't have ELM module. So error location
> for BCH8 has to be done in software.
>

Performance impact happens only when there are bit-flips in an page.
- For BCH8_HW ECC schemes
ELM comes in the picture only when during reads there is an ECC 
mis-match, if there is no ECC mis-match GPMC engine alone handles all 
the decoding part.

- For BCH8_SW ECC schemes
Same-way, lib/bch.8: decode_bch() path is taken only when ECC mismatch 
is detected on the read path, for normal read/write GPMC engine handles 
everything.

Yes, you may argue that with aging of the NAND the occurrence of 
bit-flips is common. That's true, but for new devices especially for SLC 
NAND the occurrence is usually rare on fresh parts. Also considering 
that most SLC are now manufactured in matured technologies.

Also, if you are using UBIFS on top of NAND, then it will scrub the data 
on first detection of bit-flips, thereby reducing the accumulation of 
bit-flips and thereby conserving read performance.


>>
>>
[...]
>> Right no objections to using BCH8 for rootfs, except it stopped working
>> over past year or so.
>
> This would be BCH8-sw on OMAP3 right? AM3xx uses BCH8-hw and that seems to work fine.
> So it seems nobody has used/tested BCH8-sw.
>
I have tested BCH8_SW on both AM335x and later SoC, and checked its 
compatibility with various combinations of u-boot. [1] should give you 
some indications of various combinations users can try ..


with regards, pekon

[1]
http://processors.wiki.ti.com/index.php/Linux_Core_NAND_User%27s_Guide#ECC_schemes_support


------------------------
Powered by BigRock.com

  parent reply	other threads:[~2014-11-15 11:12 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-05 11:00 [PATCH] mtd: nand: omap: Fix NAND enumeration on 3430 LDP Roger Quadros
2014-11-05 11:00 ` Roger Quadros
2014-11-06 18:03 ` Tony Lindgren
2014-11-06 18:03   ` Tony Lindgren
2014-11-07  9:35   ` Roger Quadros
2014-11-07  9:35     ` Roger Quadros
2014-11-07  9:58     ` Roger Quadros
2014-11-07  9:58       ` Roger Quadros
2014-11-07 22:48       ` Tony Lindgren
2014-11-07 22:48         ` Tony Lindgren
2014-11-09 19:29         ` pekon
2014-11-09 19:29           ` pekon
2014-11-12 18:02           ` Tony Lindgren
2014-11-12 18:02             ` Tony Lindgren
2014-11-13 11:29             ` Roger Quadros
2014-11-13 11:29               ` Roger Quadros
2014-11-13 16:00               ` Tom Rini
2014-11-13 16:00                 ` Tom Rini
2014-11-13 17:54                 ` Tony Lindgren
2014-11-13 17:54                   ` Tony Lindgren
2014-11-15 11:12               ` pekon [this message]
2014-11-15 11:12                 ` pekon
2014-11-13 12:00           ` Roger Quadros
2014-11-13 12:00             ` Roger Quadros
2014-11-19 12:22 ` [PATCH v2] " Roger Quadros
2014-11-19 12:22   ` Roger Quadros
2014-11-26  6:47   ` Brian Norris
2014-11-26  6:47     ` Brian Norris

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=54673511.80205@pek-sem.com \
    --to=pekon@pek-sem.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=ezequiel@vanguardiasur.com.ar \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=rogerq@ti.com \
    --cc=stable@vger.kernel.org \
    --cc=tony@atomide.com \
    --cc=trini@ti.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.