From: Harvey Hunt <harvey.hunt@imgtec.com>
To: Boris Brezillon <boris.brezillon@free-electrons.com>,
David Woodhouse <dwmw2@infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
<linux-mtd@lists.infradead.org>,
Richard Weinberger <richard@nod.at>
Cc: Mark Rutland <mark.rutland@arm.com>, <devicetree@vger.kernel.org>,
Pawel Moll <pawel.moll@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
<linux-kernel@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>,
Kumar Gala <galak@codeaurora.org>,
Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
Subject: Re: [PATCH] mtd: nand: document the NAND controller/NAND chip DT representation
Date: Thu, 31 Mar 2016 16:15:26 +0100 [thread overview]
Message-ID: <56FD3F0E.9080306@imgtec.com> (raw)
In-Reply-To: <1459432633-23162-1-git-send-email-boris.brezillon@free-electrons.com>
Hi Boris,
On 31/03/16 14:57, Boris Brezillon wrote:
> Standardize the NAND controller/NAND chip DT representation. Now, all new
> NAND controller drivers should comply with this representation, even if
> they are only supporting a single NAND chip.
>
> Existing drivers can keep support for the old representation (where only
> the NAND chip was described), but are encouraged to also support the new
> one.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> Documentation/devicetree/bindings/mtd/nand.txt | 37 +++++++++++++++++++++++++-
> 1 file changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt
> index b53f92e..fbf5677 100644
> --- a/Documentation/devicetree/bindings/mtd/nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/nand.txt
> @@ -1,4 +1,23 @@
> -* MTD generic binding
> +* NAND chip and NAND controller generic binding
> +
> +NAND controller/NAND chip representation:
> +
> +The NAND controller should be represented with it's own DT node, and all
s/it's/its/
> +NAND chips attached to this controller should be defined as children nodes
> +of the NAND controller. This representation should be enforced even for
> +simple controllers supporting only one chip.
> +
> +Mandatory NAND controller properties:
> +- #address-cells: depends on your controller. Should at least be 1 to
> + encode the CS line id.
> +- #size-cells: depends on your controller. Put zero unless you need a
> + mapping between CS lines and dedicated memory regions
> +
> +Optional NAND controller properties
> +- ranges: only needed if you need to define a mapping between CS lines and
> + memory regions
> +
> +Optional NAND chip properties:
>
> - nand-ecc-mode : String, operation mode of the NAND ecc mode.
> Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first",
> @@ -19,3 +38,19 @@ errors per {size} bytes".
> The interpretation of these parameters is implementation-defined, so not all
> implementations must support all possible combinations. However, implementations
> are encouraged to further specify the value(s) they support.
> +
> +Example:
> +
> + nand-controller {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* controller specific properties */
> +
> + nand@0 {
> + reg = <0>;
> + nand-ecc-mode = "soft_bch";
> +
> + /* controller specific properties */
Did you mean "chip specific properties"?
> + };
> + };
>
Thanks,
Harvey
WARNING: multiple messages have this Message-ID (diff)
From: Harvey Hunt <harvey.hunt@imgtec.com>
To: Boris Brezillon <boris.brezillon@free-electrons.com>,
David Woodhouse <dwmw2@infradead.org>,
Brian Norris <computersforpeace@gmail.com>,
linux-mtd@lists.infradead.org,
Richard Weinberger <richard@nod.at>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org, Pawel Moll <pawel.moll@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
linux-kernel@vger.kernel.org, Rob Herring <robh+dt@kernel.org>,
Kumar Gala <galak@codeaurora.org>,
Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
Subject: Re: [PATCH] mtd: nand: document the NAND controller/NAND chip DT representation
Date: Thu, 31 Mar 2016 16:15:26 +0100 [thread overview]
Message-ID: <56FD3F0E.9080306@imgtec.com> (raw)
In-Reply-To: <1459432633-23162-1-git-send-email-boris.brezillon@free-electrons.com>
Hi Boris,
On 31/03/16 14:57, Boris Brezillon wrote:
> Standardize the NAND controller/NAND chip DT representation. Now, all new
> NAND controller drivers should comply with this representation, even if
> they are only supporting a single NAND chip.
>
> Existing drivers can keep support for the old representation (where only
> the NAND chip was described), but are encouraged to also support the new
> one.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> Documentation/devicetree/bindings/mtd/nand.txt | 37 +++++++++++++++++++++++++-
> 1 file changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt
> index b53f92e..fbf5677 100644
> --- a/Documentation/devicetree/bindings/mtd/nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/nand.txt
> @@ -1,4 +1,23 @@
> -* MTD generic binding
> +* NAND chip and NAND controller generic binding
> +
> +NAND controller/NAND chip representation:
> +
> +The NAND controller should be represented with it's own DT node, and all
s/it's/its/
> +NAND chips attached to this controller should be defined as children nodes
> +of the NAND controller. This representation should be enforced even for
> +simple controllers supporting only one chip.
> +
> +Mandatory NAND controller properties:
> +- #address-cells: depends on your controller. Should at least be 1 to
> + encode the CS line id.
> +- #size-cells: depends on your controller. Put zero unless you need a
> + mapping between CS lines and dedicated memory regions
> +
> +Optional NAND controller properties
> +- ranges: only needed if you need to define a mapping between CS lines and
> + memory regions
> +
> +Optional NAND chip properties:
>
> - nand-ecc-mode : String, operation mode of the NAND ecc mode.
> Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first",
> @@ -19,3 +38,19 @@ errors per {size} bytes".
> The interpretation of these parameters is implementation-defined, so not all
> implementations must support all possible combinations. However, implementations
> are encouraged to further specify the value(s) they support.
> +
> +Example:
> +
> + nand-controller {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* controller specific properties */
> +
> + nand@0 {
> + reg = <0>;
> + nand-ecc-mode = "soft_bch";
> +
> + /* controller specific properties */
Did you mean "chip specific properties"?
> + };
> + };
>
Thanks,
Harvey
next prev parent reply other threads:[~2016-03-31 15:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-31 13:57 [PATCH] mtd: nand: document the NAND controller/NAND chip DT representation Boris Brezillon
2016-03-31 13:57 ` Boris Brezillon
2016-03-31 15:15 ` Harvey Hunt [this message]
2016-03-31 15:15 ` Harvey Hunt
2016-03-31 15:19 ` Boris Brezillon
2016-03-31 15:19 ` Boris Brezillon
2016-03-31 15:22 ` Harvey Hunt
2016-03-31 15:22 ` Harvey Hunt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56FD3F0E.9080306@imgtec.com \
--to=harvey.hunt@imgtec.com \
--cc=boris.brezillon@free-electrons.com \
--cc=computersforpeace@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dwmw2@infradead.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=jorge.ramirez-ortiz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=richard@nod.at \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.