* [RFC/PATCH 0/1] mtd: Add NAND ECC devicetree binding
@ 2014-01-17 12:13 Ezequiel Garcia
[not found] ` <1389960820-18696-1-git-send-email-ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2014-01-17 17:58 ` [RFC/PATCH 0/1] mtd: Add NAND ECC devicetree binding Gupta, Pekon
0 siblings, 2 replies; 14+ messages in thread
From: Ezequiel Garcia @ 2014-01-17 12:13 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Brian Norris, David Woodhouse, Pekon Gupta, Thomas Petazzoni,
Gregory Clement, Seif Mazareeb, Lior Amsalem, Ezequiel Garcia
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.
Ezequiel Garcia (1):
mtd: nand: Add a devicetree binding for ECC strength and ECC step size
Documentation/devicetree/bindings/mtd/nand.txt | 4 ++++
1 file changed, 4 insertions(+)
--
1.8.1.5
--
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
^ permalink raw reply [flat|nested] 14+ messages in thread[parent not found: <1389960820-18696-1-git-send-email-ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>]
* [RFC/PATCH 1/1] mtd: nand: Add a devicetree binding for ECC strength and ECC step size [not found] ` <1389960820-18696-1-git-send-email-ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> @ 2014-01-17 12:13 ` Ezequiel Garcia [not found] ` <1389960820-18696-2-git-send-email-ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> 0 siblings, 1 reply; 14+ messages in thread From: Ezequiel Garcia @ 2014-01-17 12:13 UTC (permalink / raw) To: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Cc: Brian Norris, David Woodhouse, Pekon Gupta, Thomas Petazzoni, Gregory Clement, Seif Mazareeb, Lior Amsalem, Ezequiel Garcia Some flashes can only be properly accessed when the ECC mode is specified, and a way to describe such mode is required. Such ECC mode is completely driver-specific so instead of having one binding per compatible-string, let's add generic ECC strength and ECC step size. Driver's can choose the appropriate ECC mode, based on this specification. Signed-off-by: Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> --- Documentation/devicetree/bindings/mtd/nand.txt | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt index 03855c8..683a310 100644 --- a/Documentation/devicetree/bindings/mtd/nand.txt +++ b/Documentation/devicetree/bindings/mtd/nand.txt @@ -3,5 +3,9 @@ - nand-ecc-mode : String, operation mode of the NAND ecc mode. Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first", "soft_bch". +- nand-ecc-strength : integer ECC required strength. +- nand-ecc-size : integer step size associated to the ECC strength. + The exact meaning of the ECC strength and ECC size parameters is completely + driver-specific. - nand-bus-width : 8 or 16 bus width if not present 8 - nand-on-flash-bbt: boolean to enable on flash bbt option if not present false -- 1.8.1.5 -- 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 ^ permalink raw reply related [flat|nested] 14+ messages in thread
[parent not found: <1389960820-18696-2-git-send-email-ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>]
* Re: [RFC/PATCH 1/1] mtd: nand: Add a devicetree binding for ECC strength and ECC step size [not found] ` <1389960820-18696-2-git-send-email-ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> @ 2014-02-11 14:19 ` Ezequiel Garcia 2014-02-11 15:49 ` Gupta, Pekon 2014-02-12 8:00 ` Brian Norris 1 sibling, 1 reply; 14+ messages in thread From: Ezequiel Garcia @ 2014-02-11 14:19 UTC (permalink / raw) To: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Brian Norris Cc: David Woodhouse, Pekon Gupta, Thomas Petazzoni, Gregory Clement, Seif Mazareeb, Lior Amsalem, b.brezillon.dev-Re5JQEeQqe8AvxtiuMwx3w, Grant Likely On Fri, Jan 17, 2014 at 09:13:40AM -0300, Ezequiel Garcia wrote: > Some flashes can only be properly accessed when the ECC mode is > specified, and a way to describe such mode is required. > > Such ECC mode is completely driver-specific so instead of having one binding > per compatible-string, let's add generic ECC strength and ECC step size. > Driver's can choose the appropriate ECC mode, based on this specification. > > Signed-off-by: Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> > --- > Documentation/devicetree/bindings/mtd/nand.txt | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt > index 03855c8..683a310 100644 > --- a/Documentation/devicetree/bindings/mtd/nand.txt > +++ b/Documentation/devicetree/bindings/mtd/nand.txt > @@ -3,5 +3,9 @@ > - nand-ecc-mode : String, operation mode of the NAND ecc mode. > Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first", > "soft_bch". > +- nand-ecc-strength : integer ECC required strength. > +- nand-ecc-size : integer step size associated to the ECC strength. > + The exact meaning of the ECC strength and ECC size parameters is completely > + driver-specific. > - nand-bus-width : 8 or 16 bus width if not present 8 > - nand-on-flash-bbt: boolean to enable on flash bbt option if not present false > -- > 1.8.1.5 > Brian, do you agree (as MTD maintainer) with this new binding? Can we get any Acks from a devicetree binding maintainer? Grant has already given his (informal) approval [1], but I'd rather have a formal ack from binding maintainer. Once this binding gets accepted, I'll submit an of_helper patch, and a patch for pxa3xx-nand to use it. [1] http://www.spinics.net/lists/devicetree/msg20534.html -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [RFC/PATCH 1/1] mtd: nand: Add a devicetree binding for ECC strength and ECC step size 2014-02-11 14:19 ` Ezequiel Garcia @ 2014-02-11 15:49 ` Gupta, Pekon [not found] ` <20980858CB6D3A4BAE95CA194937D5E73EA6F815-yXqyApvAXouIQmiDNMet8wC/G2K4zDHf@public.gmane.org> 0 siblings, 1 reply; 14+ messages in thread From: Gupta, Pekon @ 2014-02-11 15:49 UTC (permalink / raw) To: Ezequiel Garcia, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Brian Norris Cc: David Woodhouse, Thomas Petazzoni, Gregory Clement, Seif Mazareeb, Lior Amsalem, b.brezillon.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Grant Likely [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1208 bytes --] Hi Ezequiel, >From: Ezequiel Garcia [mailto:ezequiel.garcia@free-electrons.com] >> diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt >> index 03855c8..683a310 100644 >> --- a/Documentation/devicetree/bindings/mtd/nand.txt >> +++ b/Documentation/devicetree/bindings/mtd/nand.txt >> @@ -3,5 +3,9 @@ >> - nand-ecc-mode : String, operation mode of the NAND ecc mode. >> Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first", >> "soft_bch". >> Should nand-ecc-mode also be marked as <deprecated>, and but we continue supporting it in kernel code ? If yes, then what is the life-time of these <deprecated> bindings. I mean exactly how many kernel versions should continue support deprecated bindings ? >> +- nand-ecc-strength : integer ECC required strength. With recent patches from 'Boris BREZILLON <b.brezillon.dev@gmail.com>' "[RFC PATCH] mtd: add per NAND partition ECC config" Would you like 'nand-ecc-strength' to be per partition based ? with regards, pekon N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·zøœzÚÞz)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j.ïÛ°\½½MŽúgjÌæa×\x02››–' ™©Þ¢¸\f¢·¦j:+v‰¨ŠwèjØm¶Ÿÿ¾\a«‘êçzZ+ƒùšŽŠÝ¢j"ú!¶i ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <20980858CB6D3A4BAE95CA194937D5E73EA6F815-yXqyApvAXouIQmiDNMet8wC/G2K4zDHf@public.gmane.org>]
* Re: [RFC/PATCH 1/1] mtd: nand: Add a devicetree binding for ECC strength and ECC step size [not found] ` <20980858CB6D3A4BAE95CA194937D5E73EA6F815-yXqyApvAXouIQmiDNMet8wC/G2K4zDHf@public.gmane.org> @ 2014-02-11 15:56 ` Boris BREZILLON 2014-02-11 16:08 ` Ezequiel Garcia 1 sibling, 0 replies; 14+ messages in thread From: Boris BREZILLON @ 2014-02-11 15:56 UTC (permalink / raw) To: Gupta, Pekon, Ezequiel Garcia, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Brian Norris Cc: David Woodhouse, Thomas Petazzoni, Gregory Clement, Seif Mazareeb, Lior Amsalem, Grant Likely Hi Gupta, On 11/02/2014 16:49, Gupta, Pekon wrote: > Hi Ezequiel, > >> From: Ezequiel Garcia [mailto:ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org] >>> diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt >>> index 03855c8..683a310 100644 >>> --- a/Documentation/devicetree/bindings/mtd/nand.txt >>> +++ b/Documentation/devicetree/bindings/mtd/nand.txt >>> @@ -3,5 +3,9 @@ >>> - nand-ecc-mode : String, operation mode of the NAND ecc mode. >>> Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first", >>> "soft_bch". >>> > Should nand-ecc-mode also be marked as <deprecated>, and but we continue > supporting it in kernel code ? If yes, then what is the life-time of these > <deprecated> bindings. I mean exactly how many kernel versions should > continue support deprecated bindings ? What do you mean by deprecated ? How would a NAND flash controller driver choose amongs its supported NAND ecc modes if we remove this property ? Is there another patch series removing this property in the wild ? > >>> +- nand-ecc-strength : integer ECC required strength. > With recent patches from 'Boris BREZILLON <b.brezillon.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>' > "[RFC PATCH] mtd: add per NAND partition ECC config" > Would you like 'nand-ecc-strength' to be per partition based ? I don't think we should rely on this for the moment: I'm still working on it but it's far from stable. Moreover, we can keep a default ecc mode for the NAND chip and partitions will inherit this ECC mode when they do not specify any specific ECC config. Best Regards, Boris > > with regards, pekon -- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC/PATCH 1/1] mtd: nand: Add a devicetree binding for ECC strength and ECC step size [not found] ` <20980858CB6D3A4BAE95CA194937D5E73EA6F815-yXqyApvAXouIQmiDNMet8wC/G2K4zDHf@public.gmane.org> 2014-02-11 15:56 ` Boris BREZILLON @ 2014-02-11 16:08 ` Ezequiel Garcia 1 sibling, 0 replies; 14+ messages in thread From: Ezequiel Garcia @ 2014-02-11 16:08 UTC (permalink / raw) To: Gupta, Pekon Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Brian Norris, David Woodhouse, Thomas Petazzoni, Gregory Clement, Seif Mazareeb, Lior Amsalem, b.brezillon.dev-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, Grant Likely On Tue, Feb 11, 2014 at 03:49:24PM +0000, Gupta, Pekon wrote: > Hi Ezequiel, > > >From: Ezequiel Garcia [mailto:ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org] > >> diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt > >> index 03855c8..683a310 100644 > >> --- a/Documentation/devicetree/bindings/mtd/nand.txt > >> +++ b/Documentation/devicetree/bindings/mtd/nand.txt > >> @@ -3,5 +3,9 @@ > >> - nand-ecc-mode : String, operation mode of the NAND ecc mode. > >> Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first", > >> "soft_bch". > >> > Should nand-ecc-mode also be marked as <deprecated>, and but we continue > supporting it in kernel code ? No, I wouldn't deprecate them, as they're in use by the atmel-nand and mxc-nand drivers. > If yes, then what is the life-time of these <deprecated> bindings. > I mean exactly how many kernel versions should > continue support deprecated bindings ? > Well, if we ever decide to deprecate a DT binding, I'd say we must keep backwards compatible forever. Yes, forever. Or at least, until the last user dies or we can steal his board :-) -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC/PATCH 1/1] mtd: nand: Add a devicetree binding for ECC strength and ECC step size [not found] ` <1389960820-18696-2-git-send-email-ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> 2014-02-11 14:19 ` Ezequiel Garcia @ 2014-02-12 8:00 ` Brian Norris 2014-02-12 17:32 ` [RFC/PATCH 1/1] mtd: nand: Add a devicetree binding for ECC strength and ECC step sizeç Ezequiel Garcia 1 sibling, 1 reply; 14+ messages in thread From: Brian Norris @ 2014-02-12 8:00 UTC (permalink / raw) To: Ezequiel Garcia Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse, Pekon Gupta, Thomas Petazzoni, Gregory Clement, Seif Mazareeb, Lior Amsalem Hi Ezequiel, On Fri, Jan 17, 2014 at 09:13:40AM -0300, Ezequiel Garcia wrote: > Some flashes can only be properly accessed when the ECC mode is > specified, and a way to describe such mode is required. > > Such ECC mode is completely driver-specific so instead of having one binding > per compatible-string, let's add generic ECC strength and ECC step size. > Driver's can choose the appropriate ECC mode, based on this specification. > > Signed-off-by: Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> > --- > Documentation/devicetree/bindings/mtd/nand.txt | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt > index 03855c8..683a310 100644 > --- a/Documentation/devicetree/bindings/mtd/nand.txt > +++ b/Documentation/devicetree/bindings/mtd/nand.txt > @@ -3,5 +3,9 @@ > - nand-ecc-mode : String, operation mode of the NAND ecc mode. > Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first", > "soft_bch". > +- nand-ecc-strength : integer ECC required strength. > +- nand-ecc-size : integer step size associated to the ECC strength. Probably should be nand-ecc-step-size, to be clearer. > + The exact meaning of the ECC strength and ECC size parameters is completely > + driver-specific. I think we can be much more specific than this. We need to at least describe how the strength and size are related, and we need to mention how this represents the ECC scheme to use, rather than the minimum requirement of the flash. I'd say something like this. Feel free to improve it, but it covers the gist of what I think we can say in a generic document: - nand-ecc-strength: integer representing the number of bits to correct per ECC step - nand-ecc-step-size: integer representing the number of data bytes that are covered by a single ECC step Together, the ECC strength and step size define the correction capability, so that we say we will correct "X bit errors per Y bytes". The interpretation of these parameters is implementation-defined, but they often have ramifications on the formation, interpretation, and placement of correction metadata on the flash. Not all implementations must support all possible combinations. Implementations are encouraged to further define the value(s) they support. > - nand-bus-width : 8 or 16 bus width if not present 8 > - nand-on-flash-bbt: boolean to enable on flash bbt option if not present false 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC/PATCH 1/1] mtd: nand: Add a devicetree binding for ECC strength and ECC step sizeç 2014-02-12 8:00 ` Brian Norris @ 2014-02-12 17:32 ` Ezequiel Garcia 0 siblings, 0 replies; 14+ messages in thread From: Ezequiel Garcia @ 2014-02-12 17:32 UTC (permalink / raw) To: Brian Norris Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, David Woodhouse, Pekon Gupta, Thomas Petazzoni, Gregory Clement, Seif Mazareeb, Lior Amsalem On Wed, Feb 12, 2014 at 12:00:14AM -0800, Brian Norris wrote: > Hi Ezequiel, > > On Fri, Jan 17, 2014 at 09:13:40AM -0300, Ezequiel Garcia wrote: > > Some flashes can only be properly accessed when the ECC mode is > > specified, and a way to describe such mode is required. > > > > Such ECC mode is completely driver-specific so instead of having one binding > > per compatible-string, let's add generic ECC strength and ECC step size. > > Driver's can choose the appropriate ECC mode, based on this specification. > > > > Signed-off-by: Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> > > --- > > Documentation/devicetree/bindings/mtd/nand.txt | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt > > index 03855c8..683a310 100644 > > --- a/Documentation/devicetree/bindings/mtd/nand.txt > > +++ b/Documentation/devicetree/bindings/mtd/nand.txt > > @@ -3,5 +3,9 @@ > > - nand-ecc-mode : String, operation mode of the NAND ecc mode. > > Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first", > > "soft_bch". > > +- nand-ecc-strength : integer ECC required strength. > > +- nand-ecc-size : integer step size associated to the ECC strength. > > Probably should be nand-ecc-step-size, to be clearer. > No problem. > > + The exact meaning of the ECC strength and ECC size parameters is completely > > + driver-specific. > > I think we can be much more specific than this. We need to at least > describe how the strength and size are related, and we need to mention > how this represents the ECC scheme to use, rather than the minimum > requirement of the flash. > > I'd say something like this. Feel free to improve it, but it covers the > gist of what I think we can say in a generic document: > > - nand-ecc-strength: integer representing the number of bits to correct > per ECC step > - nand-ecc-step-size: integer representing the number of data bytes > that are covered by a single ECC step > > Together, the ECC strength and step size define the correction > capability, so that we say we will correct "X bit errors per Y > bytes". The interpretation of these parameters is > implementation-defined, but they often have ramifications on the > formation, interpretation, and placement of correction metadata on > the flash. Not all implementations must support all possible > combinations. Implementations are encouraged to further define the > value(s) they support. > Much better, thanks! -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [RFC/PATCH 0/1] mtd: Add NAND ECC devicetree binding 2014-01-17 12:13 [RFC/PATCH 0/1] mtd: Add NAND ECC devicetree binding Ezequiel Garcia [not found] ` <1389960820-18696-1-git-send-email-ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> @ 2014-01-17 17:58 ` Gupta, Pekon [not found] ` <20980858CB6D3A4BAE95CA194937D5E73EA66555-yXqyApvAXouIQmiDNMet8wC/G2K4zDHf@public.gmane.org> 1 sibling, 1 reply; 14+ messages in thread From: Gupta, Pekon @ 2014-01-17 17:58 UTC (permalink / raw) To: Ezequiel Garcia, Brian Norris Cc: Thomas Petazzoni, Lior Amsalem, devicetree@vger.kernel.org, Seif Mazareeb, linux-mtd@lists.infradead.org, Gregory Clement, David Woodhouse Hi Ezequiel, >From: Ezequiel Garcia [mailto:ezequiel.garcia@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 with regards, pekon ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <20980858CB6D3A4BAE95CA194937D5E73EA66555-yXqyApvAXouIQmiDNMet8wC/G2K4zDHf@public.gmane.org>]
* Re: [RFC/PATCH 0/1] mtd: Add NAND ECC devicetree binding [not found] ` <20980858CB6D3A4BAE95CA194937D5E73EA66555-yXqyApvAXouIQmiDNMet8wC/G2K4zDHf@public.gmane.org> @ 2014-01-17 20:33 ` Ezequiel Garcia 2014-01-20 6:21 ` Gupta, Pekon 2014-01-20 19:48 ` Brian Norris 0 siblings, 2 replies; 14+ messages in thread From: Ezequiel Garcia @ 2014-01-17 20:33 UTC (permalink / raw) To: Gupta, Pekon Cc: Brian Norris, Thomas Petazzoni, Lior Amsalem, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Seif Mazareeb, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Gregory Clement, David Woodhouse On Fri, Jan 17, 2014 at 05:58:13PM +0000, Gupta, Pekon wrote: > Hi Ezequiel, > > >From: Ezequiel Garcia [mailto:ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org] > > > >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 -- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [RFC/PATCH 0/1] mtd: Add NAND ECC devicetree binding 2014-01-17 20:33 ` Ezequiel Garcia @ 2014-01-20 6:21 ` Gupta, Pekon [not found] ` <20980858CB6D3A4BAE95CA194937D5E73EA67E79-yXqyApvAXouIQmiDNMet8wC/G2K4zDHf@public.gmane.org> 2014-01-20 19:48 ` Brian Norris 1 sibling, 1 reply; 14+ messages in thread From: Gupta, Pekon @ 2014-01-20 6:21 UTC (permalink / raw) To: Ezequiel Garcia, David Woodhouse Cc: Brian Norris, Thomas Petazzoni, Lior Amsalem, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Seif Mazareeb, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Gregory Clement Hi Ezequiel, >From: Ezequiel Garcia >>On Fri, Jan 17, 2014 at 05:58:13PM +0000, Gupta, Pekon wrote: [...] >> 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. > Yes, this is good approach for long-term, and it can replace "ti-nand-ecc-opt" "ti-nand-ecc-opt" is not new DT binding, it just got some new values added However, you have to convince DT Maintainers to get this in, and then deprecate other vendor specific bindings. It would be difficult to maintain backward compatibility to these bindings, if we move to 'nand-ecc-strength'. At some-point we need to get some concrete guidelines from DT Maintainers on how long we should support deprecated bindings in our code, And what is the age of DT binding. I think David Woodhouse should throw more light, as he had some discussions & ideas on about DT binding life, during a linux conference. with regards, pekon ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <20980858CB6D3A4BAE95CA194937D5E73EA67E79-yXqyApvAXouIQmiDNMet8wC/G2K4zDHf@public.gmane.org>]
* Re: [RFC/PATCH 0/1] mtd: Add NAND ECC devicetree binding [not found] ` <20980858CB6D3A4BAE95CA194937D5E73EA67E79-yXqyApvAXouIQmiDNMet8wC/G2K4zDHf@public.gmane.org> @ 2014-01-20 17:03 ` Ezequiel Garcia 2014-02-12 7:44 ` Brian Norris 1 sibling, 0 replies; 14+ messages in thread From: Ezequiel Garcia @ 2014-01-20 17:03 UTC (permalink / raw) To: Gupta, Pekon, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala Cc: David Woodhouse, Brian Norris, Thomas Petazzoni, Lior Amsalem, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Seif Mazareeb, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Gregory Clement On Mon, Jan 20, 2014 at 06:21:35AM +0000, Gupta, Pekon wrote: [..] > > > >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. > > > Yes, this is good approach for long-term, and it can replace "ti-nand-ecc-opt" > "ti-nand-ecc-opt" is not new DT binding, it just got some new values added > However, you have to convince DT Maintainers to get this in, and then deprecate > other vendor specific bindings. It would be difficult to maintain backward > compatibility to these bindings, if we move to 'nand-ecc-strength'. > Putting the DT maintainers on the To: field to get some feedback. > At some-point we need to get some concrete guidelines from DT Maintainers on > how long we should support deprecated bindings in our code, And what is the > age of DT binding. I think David Woodhouse should throw more light, as he had > some discussions & ideas on about DT binding life, during a linux conference. > That's a good question :-) -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC/PATCH 0/1] mtd: Add NAND ECC devicetree binding [not found] ` <20980858CB6D3A4BAE95CA194937D5E73EA67E79-yXqyApvAXouIQmiDNMet8wC/G2K4zDHf@public.gmane.org> 2014-01-20 17:03 ` Ezequiel Garcia @ 2014-02-12 7:44 ` Brian Norris 1 sibling, 0 replies; 14+ messages in thread From: Brian Norris @ 2014-02-12 7:44 UTC (permalink / raw) To: Gupta, Pekon Cc: Ezequiel Garcia, David Woodhouse, Thomas Petazzoni, Lior Amsalem, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Seif Mazareeb, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Gregory Clement On Mon, Jan 20, 2014 at 06:21:35AM +0000, Pekon Gupta wrote: > >From: Ezequiel Garcia > >I'm not implying we should deprecate the recently added "ti-nand-ecc-opt", > >but just want to know it's eventually possible. > > > Yes, this is good approach for long-term, and it can replace "ti-nand-ecc-opt" > "ti-nand-ecc-opt" is not new DT binding, it just got some new values added > However, you have to convince DT Maintainers to get this in, and then deprecate > other vendor specific bindings. It would be difficult to maintain backward > compatibility to these bindings, if we move to 'nand-ecc-strength'. I don't see why it would be difficult to support both the more generic nand-ecc-strength and the OMAP-specific ti-nand-ecc-opt in the same driver. OMAP NAND would just have to define a helper that translates properties like "bch8" into a strength and sector size (8 and 512, respectively). From then on, you can treat them identically. > At some-point we need to get some concrete guidelines from DT Maintainers on > how long we should support deprecated bindings in our code, And what is the > age of DT binding. I think David Woodhouse should throw more light, as he had > some discussions & ideas on about DT binding life, during a linux conference. Barring some new direction from the DT folks, I believe DT is an eternal ABI. We can and should maintain compatibility forever. And in this case, I don't think it's that hard. 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [RFC/PATCH 0/1] mtd: Add NAND ECC devicetree binding 2014-01-17 20:33 ` Ezequiel Garcia 2014-01-20 6:21 ` Gupta, Pekon @ 2014-01-20 19:48 ` Brian Norris 1 sibling, 0 replies; 14+ messages in thread From: Brian Norris @ 2014-01-20 19:48 UTC (permalink / raw) To: Ezequiel Garcia Cc: Gupta, Pekon, Thomas Petazzoni, Lior Amsalem, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Seif Mazareeb, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Gregory Clement, David Woodhouse On Fri, Jan 17, 2014 at 05:33:48PM -0300, Ezequiel Garcia wrote: > On Fri, Jan 17, 2014 at 05:58:13PM +0000, Gupta, Pekon wrote: > > Hi Ezequiel, > > > > >From: Ezequiel Garcia [mailto:ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org] > > > > > >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. And for the record, I also alluded to it in the last paragraph of the email Pekon linked to: So I'm not convinced that extending this nand-ecc-mode property is correct at all. But if we do want to, perhaps we'd need to introduce additional orthogonal properties to specify strength and step size, rather than listing all combinations as separate values for nand-ecc-mode. [IOW, nand-ecc-strength and nand-ecc-step-size] 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2014-02-12 17:32 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-17 12:13 [RFC/PATCH 0/1] mtd: Add NAND ECC devicetree binding Ezequiel Garcia
[not found] ` <1389960820-18696-1-git-send-email-ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2014-01-17 12:13 ` [RFC/PATCH 1/1] mtd: nand: Add a devicetree binding for ECC strength and ECC step size Ezequiel Garcia
[not found] ` <1389960820-18696-2-git-send-email-ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2014-02-11 14:19 ` Ezequiel Garcia
2014-02-11 15:49 ` Gupta, Pekon
[not found] ` <20980858CB6D3A4BAE95CA194937D5E73EA6F815-yXqyApvAXouIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2014-02-11 15:56 ` Boris BREZILLON
2014-02-11 16:08 ` Ezequiel Garcia
2014-02-12 8:00 ` Brian Norris
2014-02-12 17:32 ` [RFC/PATCH 1/1] mtd: nand: Add a devicetree binding for ECC strength and ECC step sizeç Ezequiel Garcia
2014-01-17 17:58 ` [RFC/PATCH 0/1] mtd: Add NAND ECC devicetree binding Gupta, Pekon
[not found] ` <20980858CB6D3A4BAE95CA194937D5E73EA66555-yXqyApvAXouIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2014-01-17 20:33 ` Ezequiel Garcia
2014-01-20 6:21 ` Gupta, Pekon
[not found] ` <20980858CB6D3A4BAE95CA194937D5E73EA67E79-yXqyApvAXouIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2014-01-20 17:03 ` Ezequiel Garcia
2014-02-12 7:44 ` Brian Norris
2014-01-20 19:48 ` Brian Norris
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).