public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
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



  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