| Message ID | 1389960820-18696-2-git-send-email-ezequiel.garcia@free-electrons.com |
|---|---|
| State | Accepted, archived |
| Headers | show |
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@free-electrons.com> > --- > 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
Hi Gupta, On 11/02/2014 16:49, Gupta, Pekon wrote: > 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 ? 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@gmail.com>' > "[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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Feb 11, 2014 at 03:49:24PM +0000, Gupta, Pekon wrote: > 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 ? 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 :-)
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@free-electrons.com> > --- > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@free-electrons.com> > > --- > > 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!
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
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@free-electrons.com> --- Documentation/devicetree/bindings/mtd/nand.txt | 4 ++++ 1 file changed, 4 insertions(+)