[PATCH 1/6] dt-bindings: soc: ti: Add TI PRUSS bindings
Grzegorz Jaszczyk
grzegorz.jaszczyk at linaro.org
Tue Aug 18 18:07:05 EDT 2020
Hi Rob,
On Mon, 17 Aug 2020 at 23:14, Rob Herring <robh at kernel.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 at ti.com>
> > Signed-off-by: Roger Quadros <rogerq at ti.com>
> > Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk at linaro.org>
> > Reviewed-by: Lee Jones <lee.jones at linaro.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 at ti.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 at 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
More information about the linux-arm-kernel
mailing list