From: Charles Manning <manningc2@actrix.gen.nz>
To: "Ghorai, Sukumar" <s-ghorai@ti.com>
Cc: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
Grazvydas Ignotas <notasas@gmail.com>
Subject: Re: No more software ECC in omap2.c NAND driver. Why?
Date: Mon, 22 Nov 2010 10:01:22 +1300 [thread overview]
Message-ID: <201011221001.22909.manningc2@actrix.gen.nz> (raw)
In-Reply-To: <2A3DCF3DA181AD40BDE86A3150B27B6B036977BBA2@dbde02.ent.ti.com>
On Friday 19 November 2010 03:33:24 Ghorai, Sukumar wrote:
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > owner@vger.kernel.org] On Behalf Of Charles Manning
> > Sent: Thursday, November 18, 2010 6:36 AM
> > To: linux-omap@vger.kernel.org
> > Subject: No more software ECC in omap2.c NAND driver. Why?
> >
> > Between 2.6.35 and 2.6.36 there have need quite a few changes in the NAND
> > driver, including a change from software to hardware ECC.
> >
> > The new code has hardware ECC forced on by:
> >
> > #define CONFIG_MTD_NAND_OMAP_HWECC
> >
> > I am surprised that this was done. Surely this should have been a Kconfig
> > option to select either sw ECC or hw ECC?
> >
> > Does moving to hardware ECC to the exclusion of software ECC reduce
> > functionality?
>
> [Ghorai] This is wrongly added by me, during last few patches. So I have
> send the fix as you mentioned too as.
> [PATCH] omap: nand: remove hardware ECC as default
>
> And please let me know still if it has any issue.
Just recompiling with the CONFIG_MTD_NAND_OMAP_HWECC define commented out did
not result in a working system. I suspect there is more tto the problem than
this.
>
> And I am re-working on the patches for the different ecc schema including
> s/w, h/w or different, to pass it form board file.
>
> > Does the new hwecc scheme still support sub-page writes or does it only
> > provide full page writes? If sub-page writes are lost then this has a
> > ripple
> > effect in breaking the way some UBI stuff works.
>
> [Ghorai]
> 1. do you think this sub-page read/write support was there before, say in
> 2.6.35? And breaks in 2.6.36?
2.6.35 works with subpages of 512 bytes. Tested with UBIFS.
>
> 2. In that case would you please let know what are the size(s) used for
> sub-page/read write?
AFAIK, 512 is all that is needed. There is no need for any smaller or larger.
sub-page reads are not available on all flash types and sub-page writing
causes extra write disturb. However, 512-byte sub-page writing is valuable.
This of course needs the ECC to be partitioned and performed in chunks of 256
or 512 so that the subpages can be written individually.
-- CHarles
next prev parent reply other threads:[~2010-11-21 21:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-18 1:06 No more software ECC in omap2.c NAND driver. Why? Charles Manning
2010-11-18 14:33 ` Ghorai, Sukumar
2010-11-19 10:35 ` Grazvydas Ignotas
2010-11-19 20:45 ` Ghorai, Sukumar
2010-11-21 21:01 ` Charles Manning [this message]
2010-11-22 6:08 ` Grant Erickson
2010-11-22 6:27 ` Ghorai, Sukumar
2010-11-22 6:39 ` Grant Erickson
2010-11-22 7:29 ` Ghorai, Sukumar
2010-11-22 19:03 ` Grant Erickson
2010-11-24 14:08 ` Ghorai, Sukumar
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=201011221001.22909.manningc2@actrix.gen.nz \
--to=manningc2@actrix.gen.nz \
--cc=linux-omap@vger.kernel.org \
--cc=notasas@gmail.com \
--cc=s-ghorai@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox