GPMI-NAND ECC DT binding (was: Re: [PATCH v3 22/28] mtd: nand: pxa3xx: Introduce multiple page I/O support)

GPMI-NAND ECC DT binding (was: Re: [PATCH v3 22/28] mtd: nand: pxa3xx: Introduce multiple page I/O support)

[Brian Norris]

(Trim the CC list)

Hi Huang,

On Wed, Dec 04, 2013 at 01:41:25PM -0800, Brian Norris wrote:
> I'd like to follow up on this question, since you didn't answer it, and
> it's still relevant, since we haven't yet merged your GPMI DT binding
> (it's queued for the next merge window):
> 
> On Mon, Nov 18, 2013 at 10:50:59AM -0800, Brian Norris wrote:
> > Do you have a good reason why you needed GPMI NAND to choose the ECC
> > configuration (a la "miminum ECC") instead of fully specifying your ECC
> > selection in device tree? I recall most of your arguments were about
> > using an ECC strength that leaves room for user data in OOB (e.g., with
> > JFFS2). But you could have done the same thing by creating a proper DT
> > property to describe the desidered ECC strength, with no real
> > disadvantage, right?
> 
> I'll rephrase it: why can't/don't you define a GPMI binding for the
> actual ECC level, like:
> 
>   fsl,nand-ecc-strength and fsl,nand-ecc-sector
> 
> ?
> 
> Then, you could still default to the old geometry if these properties
> aren't present, and you don't have to rely on Linux auto-detecting ECC
> properties for non-ONFI chips.

Ping? Do you have any comment here? It seems like a more precise DT
binding could still be useful for GPMI NAND.

Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: GPMI-NAND ECC DT binding (was: Re: [PATCH v3 22/28] mtd: nand: pxa3xx: Introduce multiple page I/O support)

[Huang Shijie]

On Wed, Dec 18, 2013 at 11:31:38PM -0800, Brian Norris wrote:
> (Trim the CC list)
> 
> Hi Huang,
> 
> On Wed, Dec 04, 2013 at 01:41:25PM -0800, Brian Norris wrote:
> > I'd like to follow up on this question, since you didn't answer it, and
> > it's still relevant, since we haven't yet merged your GPMI DT binding
> > (it's queued for the next merge window):
> > 
> > On Mon, Nov 18, 2013 at 10:50:59AM -0800, Brian Norris wrote:
> > > Do you have a good reason why you needed GPMI NAND to choose the ECC
> > > configuration (a la "miminum ECC") instead of fully specifying your ECC
> > > selection in device tree? I recall most of your arguments were about
> > > using an ECC strength that leaves room for user data in OOB (e.g., with
> > > JFFS2). But you could have done the same thing by creating a proper DT
> > > property to describe the desidered ECC strength, with no real
> > > disadvantage, right?
> > 
> > I'll rephrase it: why can't/don't you define a GPMI binding for the
> > actual ECC level, like:
> > 
> >   fsl,nand-ecc-strength and fsl,nand-ecc-sector
> > 
> > ?
> > 
> > Then, you could still default to the old geometry if these properties
> > aren't present, and you don't have to rely on Linux auto-detecting ECC
> > properties for non-ONFI chips.
> 
> Ping? Do you have any comment here? It seems like a more precise DT
sorry, i did not see this email.

> binding could still be useful for GPMI NAND.
agree.

but i suggest add a more common DT for it. I think other drivers may also
use it.
We have "nand-ecc-mode" now, why not add a more generic dt such as:
    "nand-ecc-strength" 



thanks
Huang Shijie

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html