linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Roger Quadros <rogerq@kernel.org>
Cc: tony@atomide.com, grygorii.strashko@ti.com, nm@ti.com,
	lokeshvutla@ti.com, nsekhar@ti.com,
	krzysztof.kozlowski@canonical.com, miquel.raynal@bootlin.com,
	devicetree@vger.kernel.org, linux-mtd@lists.infradead.org,
	linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 5/8] dt-bindings: mtd: ti,gpmc-nand: Convert to yaml
Date: Wed, 8 Sep 2021 07:46:47 -0500	[thread overview]
Message-ID: <CAL_Jsq+Nz3V4yri8QqaGoNOjL6dObPPV4dM1B2uzDMp6Fvw=SA@mail.gmail.com> (raw)
In-Reply-To: <5b7787ce-d51f-e79c-fa7a-0113acda5648@kernel.org>

On Wed, Sep 8, 2021 at 6:14 AM Roger Quadros <rogerq@kernel.org> wrote:
>
>
>
> On 07/09/2021 20:01, Rob Herring wrote:
> > On Tue, Sep 07, 2021 at 02:32:23PM +0300, Roger Quadros wrote:
> >> Convert gpmc-nand.txt to ti,gpmc-nand.yaml.
> >>
> >> Signed-off-by: Roger Quadros <rogerq@kernel.org>
> >> ---
> >>  .../devicetree/bindings/mtd/gpmc-nand.txt     | 147 ------------------
> >>  .../devicetree/bindings/mtd/ti,gpmc-nand.yaml | 110 +++++++++++++
> >>  2 files changed, 110 insertions(+), 147 deletions(-)
> >>  delete mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> >>  create mode 100644 Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml
> >>
> >> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> >> deleted file mode 100644
> >> index 44919d48d241..000000000000
> >> --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> >> +++ /dev/null
> >> @@ -1,147 +0,0 @@
> >> -Device tree bindings for GPMC connected NANDs
> >> -
> >> -GPMC connected NAND (found on OMAP boards) are represented as child nodes of
> >> -the GPMC controller with a name of "nand".
> >> -
> >> -All timing relevant properties as well as generic gpmc child properties are
> >> -explained in a separate documents - please refer to
> >> -Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
> >> -
> >> -For NAND specific properties such as ECC modes or bus width, please refer to
> >> -Documentation/devicetree/bindings/mtd/nand-controller.yaml
> >> -
> >> -
> >> -Required properties:
> >> -
> >> - - compatible:      "ti,omap2-nand"
> >> - - reg:             range id (CS number), base offset and length of the
> >> -            NAND I/O space
> >> - - interrupts:      Two interrupt specifiers, one for fifoevent, one for termcount.
> >> -
> >> -Optional properties:
> >> -
> >> - - nand-bus-width:          Set this numeric value to 16 if the hardware
> >> -                            is wired that way. If not specified, a bus
> >> -                            width of 8 is assumed.
> >> -
> >> - - ti,nand-ecc-opt:         A string setting the ECC layout to use. One of:
> >> -            "sw"            1-bit Hamming ecc code via software
> >> -            "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
> >> -            "bch16"         16-bit BCH ECC code
> >> -            Refer below "How to select correct ECC scheme for your device ?"
> >> -
> >> - - ti,nand-xfer-type:               A string setting the data transfer type. One of:
> >> -
> >> -            "prefetch-polled"       Prefetch polled mode (default)
> >> -            "polled"                Polled mode, without prefetch
> >> -            "prefetch-dma"          Prefetch enabled DMA mode
> >> -            "prefetch-irq"          Prefetch enabled irq mode
> >> -
> >> - - elm_id:  <deprecated> use "ti,elm-id" instead
> >> - - ti,elm-id:       Specifies phandle of the ELM devicetree node.
> >> -            ELM is an on-chip hardware engine on TI SoC which is used for
> >> -            locating ECC errors for BCHx algorithms. SoC devices which have
> >> -            ELM hardware engines should specify this device node in .dtsi
> >> -            Using ELM for ECC error correction frees some CPU cycles.
> >> - - rb-gpios:        GPIO specifier for the ready/busy# pin.
> >> -
> >> -For inline partition table parsing (optional):
> >> -
> >> - - #address-cells: should be set to 1
> >> - - #size-cells: should be set to 1
> >> -
> >> -Example for an AM33xx board:
> >> -
> >> -    gpmc: gpmc@50000000 {
> >> -            compatible = "ti,am3352-gpmc";
> >> -            ti,hwmods = "gpmc";
> >> -            reg = <0x50000000 0x36c>;
> >> -            interrupts = <100>;
> >> -            gpmc,num-cs = <8>;
> >> -            gpmc,num-waitpins = <2>;
> >> -            #address-cells = <2>;
> >> -            #size-cells = <1>;
> >> -            ranges = <0 0 0x08000000 0x1000000>;    /* CS0 space, 16MB */
> >> -            elm_id = <&elm>;
> >> -            interrupt-controller;
> >> -            #interrupt-cells = <2>;
> >> -
> >> -            nand@0,0 {
> >> -                    compatible = "ti,omap2-nand";
> >> -                    reg = <0 0 4>;          /* CS0, offset 0, NAND I/O window 4 */
> >> -                    interrupt-parent = <&gpmc>;
> >> -                    interrupts = <0 IRQ_TYPE_NONE>, <1 IRQ_TYPE NONE>;
> >> -                    nand-bus-width = <16>;
> >> -                    ti,nand-ecc-opt = "bch8";
> >> -                    ti,nand-xfer-type = "polled";
> >> -                    rb-gpios = <&gpmc 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
> >> -
> >> -                    gpmc,sync-clk-ps = <0>;
> >> -                    gpmc,cs-on-ns = <0>;
> >> -                    gpmc,cs-rd-off-ns = <44>;
> >> -                    gpmc,cs-wr-off-ns = <44>;
> >> -                    gpmc,adv-on-ns = <6>;
> >> -                    gpmc,adv-rd-off-ns = <34>;
> >> -                    gpmc,adv-wr-off-ns = <44>;
> >> -                    gpmc,we-off-ns = <40>;
> >> -                    gpmc,oe-off-ns = <54>;
> >> -                    gpmc,access-ns = <64>;
> >> -                    gpmc,rd-cycle-ns = <82>;
> >> -                    gpmc,wr-cycle-ns = <82>;
> >> -                    gpmc,wr-access-ns = <40>;
> >> -                    gpmc,wr-data-mux-bus-ns = <0>;
> >> -
> >> -                    #address-cells = <1>;
> >> -                    #size-cells = <1>;
> >> -
> >> -                    /* partitions go here */
> >> -            };
> >> -    };
> >> -
> >> -How to select correct ECC scheme for your device ?
> >> ---------------------------------------------------
> >> -Higher ECC scheme usually means better protection against bit-flips and
> >> -increased system lifetime. However, selection of ECC scheme is dependent
> >> -on various other factors also like;
> >> -
> >> -(1) support of built in hardware engines.
> >> -    Some legacy OMAP SoC do not have ELM harware engine, so those SoC cannot
> >> -    support ecc-schemes with hardware error-correction (BCHx_HW). However
> >> -    such SoC can use ecc-schemes with software library for error-correction
> >> -    (BCHx_HW_DETECTION_SW). The error correction capability with software
> >> -    library remains equivalent to their hardware counter-part, but there is
> >> -    slight CPU penalty when too many bit-flips are detected during reads.
> >> -
> >> -(2) Device parameters like OOBSIZE.
> >> -    Other factor which governs the selection of ecc-scheme is oob-size.
> >> -    Higher ECC schemes require more OOB/Spare area to store ECC syndrome,
> >> -    so the device should have enough free bytes available its OOB/Spare
> >> -    area to accommodate ECC for entire page. In general following expression
> >> -    helps in determining if given device can accommodate ECC syndrome:
> >> -    "2 + (PAGESIZE / 512) * ECC_BYTES" >= OOBSIZE"
> >> -    where
> >> -            OOBSIZE         number of bytes in OOB/spare area
> >> -            PAGESIZE        number of bytes in main-area of device page
> >> -            ECC_BYTES       number of ECC bytes generated to protect
> >> -                            512 bytes of data, which is:
> >> -                            '3' for HAM1_xx ecc schemes
> >> -                            '7' for BCH4_xx ecc schemes
> >> -                            '14' for BCH8_xx ecc schemes
> >> -                            '26' for BCH16_xx ecc schemes
> >> -
> >> -    Example(a): For a device with PAGESIZE = 2048 and OOBSIZE = 64 and
> >> -            trying to use BCH16 (ECC_BYTES=26) ecc-scheme.
> >> -            Number of ECC bytes per page = (2 + (2048 / 512) * 26) = 106 B
> >> -            which is greater than capacity of NAND device (OOBSIZE=64)
> >> -            Hence, BCH16 cannot be supported on given device. But it can
> >> -            probably use lower ecc-schemes like BCH8.
> >> -
> >> -    Example(b): For a device with PAGESIZE = 2048 and OOBSIZE = 128 and
> >> -            trying to use BCH16 (ECC_BYTES=26) ecc-scheme.
> >> -            Number of ECC bytes per page = (2 + (2048 / 512) * 26) = 106 B
> >> -            which can be accommodated in the OOB/Spare area of this device
> >> -            (OOBSIZE=128). So this device can use BCH16 ecc-scheme.
> >> diff --git a/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml b/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml
> >> new file mode 100644
> >> index 000000000000..db36f2e944ef
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mtd/ti,gpmc-nand.yaml
> >> @@ -0,0 +1,110 @@
> >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> +%YAML 1.2
> >> +---
> >> +$id: http://devicetree.org/schemas/mtd/ti,gpmc-nand.yaml#
> >> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> +
> >> +title: Texas Instruments GPMC NAND Flash controller.
> >> +
> >> +maintainers:
> >> +  - Tony Lindgren <tony@atomide.com>
> >> +  - Roger Quadros <rogerq@kernel.org>
> >> +
> >> +description:
> >> +  GPMC NAND controller/Flash is represented as a child of the
> >> +  GPMC controller node.
> >> +
> >> +properties:
> >> +  compatible:
> >> +    const: ti,omap2-nand
> >> +
> >> +  reg:
> >> +    maxItems: 1
> >> +
> >> +  interrupts:
> >> +    items:
> >> +      - description: Interrupt for fifoevent
> >> +      - description: Interrupt for termcount
> >> +
> >> +  "#address-cells":
> >> +    const: 1
> >> +
> >> +  "#size-cells":
> >> +    const: 1
> >> +
> >> +  ti,nand-ecc-opt:
> >> +    description: Desired ECC algorithm
> >> +    $ref: /schemas/types.yaml#/definitions/string
> >> +    enum: [sw, ham1, bch4, bch8, bch16]
> >> +
> >> +  ti,nand-xfer-type:
> >> +    description: Data transfer method between controller and chip.
> >> +    $ref: /schemas/types.yaml#/definitions/string
> >> +    enum: [prefetch-polled, polled, prefetch-dma, prefetch-irq]
> >> +    default: prefetch-polled
> >> +
> >> +  ti,elm-id:
> >> +    description:
> >> +      phandle to the ELM (Error Location Module).
> >> +    $ref: /schemas/types.yaml#/definitions/phandle
> >> +
> >> +  nand-bus-width:
> >> +    description:
> >> +      Bus width to the NAND chip
> >> +    $ref: /schemas/types.yaml#/definitions/uint32
> >> +    enum: [8, 16]
> >> +    default: 8
> >> +
> >> +allOf:
> >> +  - $ref: "../memory-controllers/ti,gpmc-child.yaml"
> >
> > Use /schemas/... rather than '..'
>
> ok.
>
> >
> >> +
> >> +required:
> >> +  - compatible
> >> +  - reg
> >> +  - ti,nand-ecc-opt
> >> +
> >> +unevaluatedProperties: false
> >
> > This will throw errors if you have partition nodes. You need to
> > reference the partitions schema.
>
> I didn't get any errors with dtbs_check so far. But I will
> try referencing the partition schema here.

Not yet because 'unevaluatedProperties' isn't actually supported in
the jsonschema package yet. It will be in the next release which I
expect soonish.

Rob

  reply	other threads:[~2021-09-08 12:47 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-07 11:32 [PATCH v3 0/8] dt-bindings: memory-controllers: ti,gpmc: Convert to yaml Roger Quadros
2021-09-07 11:32 ` [PATCH v3 1/8] ARM: dts: omap: Fixup GPMC child nodes Roger Quadros
2021-09-07 12:44   ` Krzysztof Kozlowski
2021-09-15  8:53     ` Roger Quadros
2021-09-07 11:32 ` [PATCH v3 2/8] dt-bindings: mtd: Remove gpmc-nor.txt Roger Quadros
2021-09-07 11:32 ` [PATCH v3 3/8] dt-bindings: net: Remove gpmc-eth.txt Roger Quadros
2021-09-07 11:32 ` [PATCH v3 4/8] dt-bindings: memory-controllers: Introduce ti,gpmc-child Roger Quadros
2021-09-07 11:32 ` [PATCH v3 5/8] dt-bindings: mtd: ti,gpmc-nand: Convert to yaml Roger Quadros
2021-09-07 14:03   ` Miquel Raynal
2021-09-07 15:27     ` Grygorii Strashko
2021-09-07 16:35       ` Miquel Raynal
2021-09-07 16:57         ` Roger Quadros
2021-09-07 22:24           ` Rob Herring
2021-09-08  6:55             ` Roger Quadros
2021-09-07 17:01   ` Rob Herring
2021-09-08 11:14     ` Roger Quadros
2021-09-08 12:46       ` Rob Herring [this message]
2021-09-07 11:32 ` [PATCH v3 6/8] dt-bindings: mtd: ti,gpmc-onenand: " Roger Quadros
2021-09-07 11:32 ` [PATCH v3 7/8] dt-bindings: memory-controllers: ti,gpmc: " Roger Quadros
2021-09-07 11:32 ` [PATCH v3 8/8] memory: gpmc-omap: "gpmc,device-width" DT property is optional Roger Quadros
2021-09-07 12:36   ` Krzysztof Kozlowski
2021-09-15  9:11     ` Roger Quadros
2021-09-16 10:48       ` Krzysztof Kozlowski
2021-09-17  7:17         ` Roger Quadros

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='CAL_Jsq+Nz3V4yri8QqaGoNOjL6dObPPV4dM1B2uzDMp6Fvw=SA@mail.gmail.com' \
    --to=robh@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=grygorii.strashko@ti.com \
    --cc=krzysztof.kozlowski@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=lokeshvutla@ti.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=nm@ti.com \
    --cc=nsekhar@ti.com \
    --cc=rogerq@kernel.org \
    --cc=tony@atomide.com \
    /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 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).