Message-ID: <CAMxfBF5YQCE9i-Xot209S+vWtaH6NFUrcViFcsEG6GKyeQ5j3A@mail.gmail.com>
Date:   Wed, 19 Aug 2020 00:07:05 +0200
From:   Grzegorz Jaszczyk <grzegorz.jaszczyk@...aro.org>
To:     Rob Herring <robh@...nel.org>
Cc:     ssantosh@...nel.org, "Anna, Suman" <s-anna@...com>,
        santosh.shilimkar@...cle.com, Lee Jones <lee.jones@...aro.org>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        "Bajjuri, Praneeth" <praneeth@...com>,
        Roger Quadros <rogerq@...com>
Subject: Re: [PATCH 1/6] dt-bindings: soc: ti: Add TI PRUSS bindings

Hi Rob,

On Mon, 17 Aug 2020 at 23:14, Rob Herring <robh@...nel.org> wrote:
>
> On Wed, Jul 29, 2020 at 01:02:03PM +0200, Grzegorz Jaszczyk wrote:
> > This patch adds the bindings for the Programmable Real-Time Unit
> > and Industrial Communication Subsystem (PRU-ICSS) present on various
> > TI SoCs. The IP is present on multiple TI SoC architecture families
> > including the OMAP architecture SoCs such as AM33xx, AM437x and
> > AM57xx; and on a Keystone 2 architecture based 66AK2G SoC. It is
> > also present on the Davinci based OMAPL138 SoCs and K3 architecture
> > based AM65x and J721E SoCs as well.
> >
> > The IP has a number of sub-modules some of which are represented as
> > their own devices. This binding covers only the top-level sub-system
> > devices, and some sub-modules like MDIO, MII_RT (Ethernet MII_RT module
> > with MII ports) and IEP (Industrial Ethernet Peripheral). The remaining
> > sub-modules bindings shall be defined in the respective driver
> > subsystem bindings folders. Couple of full examples have also been
> > added demonstrating the devices on AM335x and AM437x SoCs.
> >
> > Signed-off-by: Suman Anna <s-anna@...com>
> > Signed-off-by: Roger Quadros <rogerq@...com>
> > Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@...aro.org>
> > Reviewed-by: Lee Jones <lee.jones@...aro.org>
> > ---
> >  .../devicetree/bindings/soc/ti/ti,pruss.yaml       | 383 +++++++++++++++++++++
> >  1 file changed, 383 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
> > new file mode 100644
> > index 0000000..4b7a098
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml
> > @@ -0,0 +1,383 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/soc/ti/ti,pruss.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: |+
> > +  TI Programmable Real-Time Unit and Industrial Communication Subsystem
> > +
> > +maintainers:
> > +  - Suman Anna <s-anna@...com>
> > +
> > +description: |+
> > +
> > +  The Programmable Real-Time Unit and Industrial Communication Subsystem
> > +  (PRU-ICSS a.k.a. PRUSS) is present on various TI SoCs such as AM335x, AM437x,
> > +  Keystone 66AK2G, OMAP-L138/DA850 etc. A PRUSS consists of dual 32-bit RISC
> > +  cores (Programmable Real-Time Units, or PRUs), shared RAM, data and
> > +  instruction RAMs, some internal peripheral modules to facilitate industrial
> > +  communication, and an interrupt controller.
> > +
> > +  The programmable nature of the PRUs provide flexibility to implement custom
> > +  peripheral interfaces, fast real-time responses, or specialized data handling.
> > +  The common peripheral modules include the following,
> > +    - an Ethernet MII_RT module with two MII ports
> > +    - an MDIO port to control external Ethernet PHYs
> > +    - an Industrial Ethernet Peripheral (IEP) to manage/generate Industrial
> > +      Ethernet functions
> > +    - an Enhanced Capture Module (eCAP)
> > +    - an Industrial Ethernet Timer with 7/9 capture and 16 compare events
> > +    - a 16550-compatible UART to support PROFIBUS
> > +    - Enhanced GPIO with async capture and serial support
> > +
> > +  A PRU-ICSS subsystem can have up to three shared data memories. A PRU core
> > +  acts on a primary Data RAM (there are usually 2 Data RAMs) at its address
> > +  0x0, but also has access to a secondary Data RAM (primary to the other PRU
> > +  core) at its address 0x2000. A shared Data RAM, if present, can be accessed
> > +  by both the PRU cores. The Interrupt Controller (INTC) and a CFG module are
> > +  common to both the PRU cores. Each PRU core also has a private instruction
> > +  RAM, and specific register spaces for Control and Debug functionalities.
> > +
> > +  Various sub-modules within a PRU-ICSS subsystem are represented as individual
> > +  nodes and are defined using a parent-child hierarchy depending on their
> > +  integration within the IP and the SoC. These nodes are described in the
> > +  following sections.
> > +
> > +
> > +  PRU-ICSS Node
> > +  ==============
> > +  Each PRU-ICSS instance is represented as its own node with the individual PRU
> > +  processor cores, the memories node, an INTC node and an MDIO node represented
> > +  as child nodes within this PRUSS node. This node shall be a child of the
> > +  corresponding interconnect bus nodes or target-module nodes.
> > +
> > +  See ../../mfd/syscon.yaml for generic SysCon binding details.
> > +
> > +
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - ti,am3356-pruss  # for AM335x SoC family
> > +      - ti,am4376-pruss0 # for AM437x SoC family and PRUSS unit 0
> > +      - ti,am4376-pruss1 # for AM437x SoC family and PRUSS unit 1
> > +      - ti,am5728-pruss  # for AM57xx SoC family
> > +      - ti,k2g-pruss     # for 66AK2G SoC family
> > +      - ti,am654-icssg   # for K3 AM65x SoC family
> > +      - ti,j721e-icssg   # for K3 J721E SoC family
> > +
> > +  reg:
> > +    maxItems: 1
> > +
> > +  ranges:
> > +    maxItems: 1
> > +    description: |
> > +      Standard ranges definition using addresses from 0 for child nodes.
>
> Don't need a description on standard properties.

Ok.

>
>
> > +
> > +  power-domains:
> > +    description: |
> > +      This property is as per sci-pm-domain.txt.
> > +
> > +  memories:
>
> Missing unit-address pattern.

Ok, I will also update other subnodes regarding the unit-address pattern.

>
>
> > +    description: |
> > +      The various Data RAMs within a single PRU-ICSS unit are represented as a
> > +      single node with the name 'memories'.
> > +
> > +    type: object
> > +
> > +    properties:
> > +      reg:
> > +        minItems: 2 # On AM437x one of two PRUSS units don't contain Shared RAM.
> > +        maxItems: 3
> > +        items:
> > +          - description: Address and size of the Data RAM0.
> > +          - description: Address and size of the Data RAM1.
> > +          - description: |
> > +              Address and size of the Shared Data RAM. Note that on AM437x one
> > +              of two PRUSS units don't contain Shared RAM, while the second one
> > +              has it.
> > +
> > +      reg-names:
> > +        minItems: 2
> > +        maxItems: 3
> > +        items:
> > +          - const: dram0
> > +          - const: dram1
> > +          - const: shrdram2
> > +
> > +    required:
> > +      - reg
> > +      - reg-names
>
>        additionalProperties: false
>

Ok.

>
>
> (And throughout for other child nodes).

Ok.

>
>
> > +
> > +  cfg:
> > +    description: |
> > +      PRU-ICSS configuration space. CFG sub-module represented as a SysCon.
> > +
> > +    type: object
> > +
> > +    properties:
> > +      compatible:
> > +        items:
> > +          - const: ti,pruss-cfg
> > +          - const: syscon
> > +
> > +      reg:
> > +        maxItems: 1
> > +
> > +  iep:
> > +    description: |
> > +      Industrial Ethernet Peripheral to manage/generate Industrial Ethernet
> > +      functions such as time stamping. Each PRUSS has either 1 IEP (on AM335x,
> > +      AM437x, AM57xx & 66AK2G SoCs) or 2 IEPs (on K3 AM65x & J721E SoCs ). IEP
> > +      is used for creating PTP clocks and generating PPS signals. The bindings
> > +      for this shall be defined in ../../net/ti,icss-iep.yaml.
> > +
> > +    type: object
> > +
> > +  mii-rt:
> > +    description: |
> > +      Real-Time Ethernet to support multiple industrial communication protocols.
> > +      MII-RT sub-module represented as a SysCon.
> > +
> > +    type: object
> > +
> > +    properties:
> > +      compatible:
> > +        items:
> > +          - const: ti,pruss-mii
> > +          - const: syscon
> > +
> > +      reg:
> > +        maxItems: 1
> > +
> > +  mii-g-rt:
> > +    description: |
> > +      The Real-time Media Independent Interface to support multiple industrial
> > +      communication protocols (G stands for Gigabit). MII-G-RT sub-module
> > +      represented as a SysCon.
> > +
> > +    type: object
> > +
> > +    properties:
> > +      compatible:
> > +        items:
> > +          - const: ti,pruss-mii-g
> > +          - const: syscon
> > +
> > +      reg:
> > +        maxItems: 1
> > +
> > +  interrupt-controller:
> > +    description: |
> > +      PRUSS INTC Node. Each PRUSS has a single interrupt controller instance
> > +      that is common to all the PRU cores. This should be represented as an
> > +      interrupt-controller node. The bindings for this shall be defined in
> > +      ../../interrupt-controller/ti,pruss-intc.yaml.
>
> Use $ref to reference the schema.

The problem is that the mentioned binding is not merged yet. Is it ok
for you to leave it as is and update once
../../interrupt-controller/ti,pruss-intc.yam get merged?

>
>
> > +
> > +    type: object
> > +
> > +  mdio:
> > +    description: |
> > +      MDIO Node. Each PRUSS has an MDIO module that can be used to control
> > +      external PHYs. The MDIO module used within the PRU-ICSS is an instance of
> > +      the MDIO Controller used in TI Davinci SoCs.
> > +
> > +    allOf:
> > +      - $ref: /schemas/net/ti,davinci-mdio.yaml#
> > +
> > +    type: object
> > +
> > +patternProperties:
> > +  "^(pru|rtu|txpru)@[0-9a-f]+$":
> > +    description: |
> > +      PRU Node. Each PRUSS has dual PRU cores, each represented as a RemoteProc
> > +      device through a PRU child node each. Each node can optionally be rendered
> > +      inactive by using the standard DT string property, "status". The ICSSG IP
> > +      present on K3 SoCs have additional auxiliary PRU cores with slightly
> > +      different IP integration. The bindings for this shall be defined in
> > +      ../../remoteproc/ti,pru-rproc.yaml
> > +
> > +    type: object
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - ranges
> > +
> > +# Due to inability of correctly verifying sub-nodes with an @address through
> > +# the "required" list, the required sub-nodes below are commented out for now.
> > +
> > +#required:
> > +# - memories
> > +# - interrupt-controller
> > +# - pru
>
> Add:
>
> additionalProperties: false

Ok.

>
>
> > +
> > +if:
> > +  properties:
> > +    compatible:
> > +      contains:
> > +        enum:
> > +          - ti,k2g-pruss
> > +          - ti,am654-icssg
> > +          - ti,j721e-icssg
> > +then:
> > +  required:
> > +    - power-domains
> > +
> > +examples:
> > +  - |
> > +
> > +    /* Example 1 AM33xx PRU-ICSS */
> > +    pruss: pruss@0 {
> > +        compatible = "ti,am3356-pruss";
> > +        reg = <0x0 0x80000>;
> > +        #address-cells = <1>;
> > +        #size-cells = <1>;
> > +        ranges;
>
> I would have expected a warning on this since you defined it to have 1
> entry.

I've double checked with dt_binding_check - there is no warning. For
ranges maxItems: 1 is defined.

Thank you for your review,
Grzegorz

Powered by blists - more mailing lists