[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