[RFC/PATCH 0/1] mtd: Add NAND ECC devicetree binding
Ezequiel Garcia
ezequiel.garcia at free-electrons.com
Fri Jan 17 15:33:48 EST 2014
On Fri, Jan 17, 2014 at 05:58:13PM +0000, Gupta, Pekon wrote:
> Hi Ezequiel,
>
> >From: Ezequiel Garcia [mailto:ezequiel.garcia at free-electrons.com]
> >
> >This patch is our first proposal to address the need for a suitable ECC
> >devicetree binding.
> >
> >NAND controllers have special ECC modes, raising per-driver ECC mode devicetree
> >binding. See for instance the binding for OMAP:
> >
> > - ti,nand-ecc-opt: A string setting the ECC layout to use. One of:
> > "sw" <deprecated> use "ham1" instead
> > "hw" <deprecated> use "ham1" instead
> > "hw-romcode" <deprecated> use "ham1" instead
> > "ham1" 1-bit Hamming ecc code
> > "bch4" 4-bit BCH ecc code
> > "bch8" 8-bit BCH ecc code
> >
> >Other drivers (such as pxa3xx-nand) have similar requirements, with special
> >(controller-specific) ECC modes. Instead of adding a possibly different binding
> >per compatible-string, let's add generic ECC strength and ECC step size.
> >
> >This properties should describe completely the ECC mode and let drivers choose
> >the appropriate ECC mode.
> >
> Yes, this is good approach.
> It was found earlier that generic NAND DT bindings are not much use to other
> controllers as well, as different h/w engines have different interpretations.
> Brian Norris had similar comments giving example of his hardware.
> (hope following reference helps).
>
> [1] http://lists.infradead.org/pipermail/linux-mtd/2013-September/048869.html
>
Yes, Brian suggested this ecc-strength/ecc-size approach on IRC.
Pekon, do you think this binding proposal is good enough to describe OMAP NAND
ECC mode?
I'm not implying we should deprecate the recently added "ti-nand-ecc-opt",
but just want to know it's eventually possible.
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
More information about the linux-mtd
mailing list