linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: "Miquel Raynal" <miquel.raynal@bootlin.com>,
	"Richard Weinberger" <richard@nod.at>,
	"Vignesh Raghavendra" <vigneshr@ti.com>,
	"Brian Norris" <computersforpeace@gmail.com>,
	"Kamal Dasu" <kdasu.kdev@gmail.com>,
	linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
	bcm-kernel-feedback-list@broadcom.com,
	"Rafał Miłecki" <rafal@milecki.pl>
Subject: Re: [PATCH V2] dt-bindings: mtd: brcm,brcmnand: convert to the json-schema
Date: Tue, 20 Apr 2021 13:50:43 -0500	[thread overview]
Message-ID: <20210420185043.GA3597594@robh.at.kernel.org> (raw)
In-Reply-To: <20210416195432.24595-1-zajec5@gmail.com>

On Fri, Apr 16, 2021 at 09:54:32PM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
> 
> This helps validating DTS files.
> 
> Changes that require mentioning:
> 1. Property "clock" was renamed to "clocks"
> 2. Duplicated properties (defined in nand-controller.yaml) were dropped
> 3. Compatible "brcm,nand-bcm63168" was added
> 
> Examples changes:
> 1. Nodes "nand" were renamed to "nand-controller"
> 2. Nodes "nandcs" were renamed to "nand"
> 3. Dropped partitions as they were using old syntax and are well
>    documented elsewhere anyway
> 
> This rewritten binding validates cleanly using the "dt_binding_check".
> Some Linux stored DTS files will require updating to make "dtbs_check"
> happy.
> 
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> V2: Drop example partitions that were using deprecated syntax-thanks Rob
> ---
>  .../devicetree/bindings/mtd/brcm,brcmnand.txt | 186 ------------
>  .../bindings/mtd/brcm,brcmnand.yaml           | 265 ++++++++++++++++++
>  2 files changed, 265 insertions(+), 186 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
>  create mode 100644 Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml


> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml
> new file mode 100644
> index 000000000000..c0f1e7747e23
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml
> @@ -0,0 +1,265 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mtd/brcm,brcmnand.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Broadcom STB NAND Controller
> +
> +maintainers:
> +  - Brian Norris <computersforpeace@gmail.com>
> +  - Kamal Dasu <kdasu.kdev@gmail.com>
> +
> +description: |
> +  The Broadcom Set-Top Box NAND controller supports low-level access to raw NAND
> +  flash chips. It has a memory-mapped register interface for both control
> +  registers and for its data input/output buffer. On some SoCs, this controller
> +  is paired with a custom DMA engine (inventively named "Flash DMA") which
> +  supports basic PROGRAM and READ functions, among other features.
> +
> +  This controller was originally designed for STB SoCs (BCM7xxx) but is now
> +  available on a variety of Broadcom SoCs, including some BCM3xxx, BCM63xx, and
> +  iProc/Cygnus. Its history includes several similar (but not fully register
> +  compatible) versions.
> +
> +  -- Additional SoC-specific NAND controller properties --
> +
> +  The NAND controller is integrated differently on the variety of SoCs on which
> +  it is found. Part of this integration involves providing status and enable
> +  bits with which to control the 8 exposed NAND interrupts, as well as hardware
> +  for configuring the endianness of the data bus. On some SoCs, these features
> +  are handled via standard, modular components (e.g., their interrupts look like
> +  a normal IRQ chip), but on others, they are controlled in unique and
> +  interesting ways, sometimes with registers that lump multiple NAND-related
> +  functions together. The former case can be described simply by the standard
> +  interrupts properties in the main controller node. But for the latter
> +  exceptional cases, we define additional 'compatible' properties and associated
> +  register resources within the NAND controller node above.
> +
> +properties:
> +  compatible:
> +    oneOf:
> +      - items:
> +          - enum:
> +              - brcm,brcmnand-v2.1
> +              - brcm,brcmnand-v2.2
> +              - brcm,brcmnand-v4.0
> +              - brcm,brcmnand-v5.0
> +              - brcm,brcmnand-v6.0
> +              - brcm,brcmnand-v6.1
> +              - brcm,brcmnand-v6.2
> +              - brcm,brcmnand-v7.0
> +              - brcm,brcmnand-v7.1
> +              - brcm,brcmnand-v7.2
> +              - brcm,brcmnand-v7.3
> +          - const: brcm,brcmnand
> +      - description: SoC-specific NAND controller
> +        items:
> +          - enum:
> +              - brcm,nand-bcm63138
> +              - brcm,nand-iproc
> +          - enum:
> +              - brcm,brcmnand-v2.1
> +              - brcm,brcmnand-v2.2
> +              - brcm,brcmnand-v4.0
> +              - brcm,brcmnand-v5.0
> +              - brcm,brcmnand-v6.0
> +              - brcm,brcmnand-v6.1
> +              - brcm,brcmnand-v6.2
> +              - brcm,brcmnand-v7.0
> +              - brcm,brcmnand-v7.1
> +              - brcm,brcmnand-v7.2
> +              - brcm,brcmnand-v7.3

How can a specific SoC have all these different versions?

> +          - const: brcm,brcmnand
> +      - description: BCM6368 SoC-specific NAND controller
> +        items:
> +          - enum:
> +              - brcm,nand-bcm63168
> +          - const: brcm,nand-bcm6368
> +          - enum:
> +              - brcm,brcmnand-v2.1
> +              - brcm,brcmnand-v2.2
> +              - brcm,brcmnand-v4.0
> +              - brcm,brcmnand-v5.0
> +              - brcm,brcmnand-v6.0
> +              - brcm,brcmnand-v6.1
> +              - brcm,brcmnand-v6.2
> +              - brcm,brcmnand-v7.0
> +              - brcm,brcmnand-v7.1
> +              - brcm,brcmnand-v7.2
> +              - brcm,brcmnand-v7.3
> +          - const: brcm,brcmnand
> +
> +  reg:
> +    minItems: 1
> +    maxItems: 6
> +
> +  reg-names:
> +    minItems: 1
> +    maxItems: 6
> +    items:
> +      - const: nand
> +      - enum: [ flash-dma, flash-edu, nand-cache, nand-int-base, iproc-idm, iproc-ext ]
> +      - enum: [ flash-dma, flash-edu, nand-cache, nand-int-base, iproc-idm, iproc-ext ]
> +      - enum: [ flash-dma, flash-edu, nand-cache, nand-int-base, iproc-idm, iproc-ext ]
> +      - enum: [ flash-dma, flash-edu, nand-cache, nand-int-base, iproc-idm, iproc-ext ]
> +      - enum: [ flash-dma, flash-edu, nand-cache, nand-int-base, iproc-idm, iproc-ext ]

How many actual combinations do you need to support? A reasonable number 
can be listed out under a 'oneOf'. 

Given you're already explicit for 3 cases below, I think I'd just do:

items:
  enum: [ nand, flash-dma, flash-edu, nand-cache, nand-int-base, iproc-idm, iproc-ext ]

(Without the '-', 'items' is a schema rather than list and is applied to 
all entries.)

> +
> +  interrupts:
> +    minItems: 1
> +    maxItems: 3
> +    items:
> +      - description: NAND CTLRDY interrupt
> +      - description: FLASH_DMA_DONE if flash DMA is available
> +      - description: FLASH_EDU_DONE if EDU is available
> +
> +  interrupt-names:
> +    minItems: 1
> +    maxItems: 3
> +    items:
> +      - const: nand_ctlrdy
> +      - const: flash_dma_done
> +      - const: flash_edu_done
> +
> +  clocks:
> +    maxItems: 1
> +    description: reference to the clock for the NAND controller
> +
> +  clock-names:
> +    const: nand
> +
> +  brcm,nand-has-wp:
> +    description: >
> +      Some versions of this IP include a write-protect
> +      (WP) control bit. It is always available on >=
> +      v7.0. Use this property to describe the rare
> +      earlier versions of this core that include WP
> +    type: boolean
> +
> +patternProperties:
> +  "^nand@[a-f0-9]$":
> +    type: object
> +    properties:
> +      compatible:
> +        const: brcm,nandcs
> +
> +      nand-ecc-step-size:
> +        enum: [ 512, 1024 ]
> +
> +      brcm,nand-oob-sector-size:
> +        description: |
> +          integer, to denote the spare area sector size
> +          expected for the ECC layout in use. This size, in
> +          addition to the strength and step-size,
> +          determines how the hardware BCH engine will lay
> +          out the parity bytes it stores on the flash.
> +          This property can be automatically determined by
> +          the flash geometry (particularly the NAND page
> +          and OOB size) in many cases, but when booting
> +          from NAND, the boot controller has only a limited
> +          number of available options for its default ECC
> +          layout.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +
> +allOf:
> +  - $ref: nand-controller.yaml#
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: brcm,nand-bcm63138
> +    then:
> +      properties:
> +        reg-names:
> +          minItems: 2
> +          maxItems: 2
> +          items:
> +            - const: nand
> +            - const: nand-int-base
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: brcm,nand-bcm6368
> +    then:
> +      properties:
> +        reg-names:
> +          minItems: 2
> +          maxItems: 3
> +          items:
> +            - const: nand
> +            - const: nand-int-base
> +            - const: nand-cache
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            const: brcm,nand-iproc
> +    then:
> +      properties:
> +        reg-names:
> +          minItems: 2
> +          maxItems: 3
> +          items:
> +            - const: nand
> +            - const: iproc-idm
> +            - const: iproc-ext
> +
> +unevaluatedProperties: false
> +
> +required:
> +  - reg
> +  - reg-names
> +  - interrupts
> +
> +examples:
> +  - |
> +    nand-controller@f0442800 {
> +            compatible = "brcm,brcmnand-v7.0", "brcm,brcmnand";
> +            reg = <0xf0442800 0x600>,
> +                  <0xf0443000 0x100>;
> +            reg-names = "nand", "flash-dma";
> +            interrupt-parent = <&hif_intr2_intc>;
> +            interrupts = <24>, <4>;
> +
> +            #address-cells = <1>;
> +            #size-cells = <0>;
> +
> +            nand@1 {
> +                    compatible = "brcm,nandcs";
> +                    reg = <1>; // Chip select 1
> +                    nand-on-flash-bbt;
> +                    nand-ecc-strength = <12>;
> +                    nand-ecc-step-size = <512>;
> +
> +                    #address-cells = <1>;
> +                    #size-cells = <1>;
> +            };
> +    };
> +  - |
> +    nand-controller@10000200 {
> +            compatible = "brcm,nand-bcm63168", "brcm,nand-bcm6368",
> +                         "brcm,brcmnand-v4.0", "brcm,brcmnand";
> +            reg = <0x10000200 0x180>,
> +                  <0x100000b0 0x10>,
> +                  <0x10000600 0x200>;
> +            reg-names = "nand", "nand-int-base", "nand-cache";
> +            interrupt-parent = <&periph_intc>;
> +            interrupts = <50>;
> +            clocks = <&periph_clk 20>;
> +            clock-names = "nand";
> +
> +            #address-cells = <1>;
> +            #size-cells = <0>;
> +
> +            nand@0 {
> +                    compatible = "brcm,nandcs";
> +                    reg = <0>;
> +                    nand-on-flash-bbt;
> +                    nand-ecc-strength = <1>;
> +                    nand-ecc-step-size = <512>;
> +
> +                    #address-cells = <1>;
> +                    #size-cells = <1>;
> +            };
> +    };
> -- 
> 2.26.2
> 

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2021-04-20 18:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-16 12:33 [PATCH] dt-bindings: mtd: brcm,brcmnand: convert to the json-schema Rafał Miłecki
2021-04-16 19:54 ` [PATCH V2] dt-bindings: mtd: brcm, brcmnand: " Rafał Miłecki
2021-04-20 18:50   ` Rob Herring [this message]
2021-04-20 21:20   ` [PATCH V3] " Rafał Miłecki
2021-04-21 17:05     ` [PATCH V3] dt-bindings: mtd: brcm,brcmnand: " Rob Herring
2021-04-23  2:34     ` [PATCH V3] dt-bindings: mtd: brcm, brcmnand: " Brian Norris
2021-04-23  5:05     ` [PATCH V4] " Rafał Miłecki
2021-05-10 10:02       ` Miquel Raynal

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=20210420185043.GA3597594@robh.at.kernel.org \
    --to=robh@kernel.org \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=computersforpeace@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=kdasu.kdev@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=rafal@milecki.pl \
    --cc=richard@nod.at \
    --cc=vigneshr@ti.com \
    --cc=zajec5@gmail.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).