On Mon, Apr 18, 2022 at 04:11:14PM +0530, Puranjay Mohan wrote: > From: Suman Anna <s-anna@xxxxxx> > > Add a YAML binding document for PRU consumers. The binding includes > all the common properties that can be used by different PRU consumer > or application nodes and supported by the PRU remoteproc driver. > These are used to configure the PRU hardware for specific user > applications. > > The application nodes themselves should define their own bindings. > > Co-developed-by: Tero Kristo <t-kristo@xxxxxx> > Signed-off-by: Tero Kristo <t-kristo@xxxxxx> > Signed-off-by: Suman Anna <s-anna@xxxxxx> > Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@xxxxxxxxxx> > Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@xxxxxxxxxx> > Signed-off-by: Puranjay Mohan <p-mohan@xxxxxx> > --- > .../bindings/remoteproc/ti,pru-consumer.yaml | 70 +++++++++++++++++++ > 1 file changed, 70 insertions(+) > create mode 100644 Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml > > diff --git a/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml > new file mode 100644 > index 000000000000..5b1f1cb2f098 > --- /dev/null > +++ b/Documentation/devicetree/bindings/remoteproc/ti,pru-consumer.yaml > @@ -0,0 +1,70 @@ > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/remoteproc/ti,pru-consumer.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Common TI PRU Consumer Binding > + > +maintainers: > + - Suman Anna <s-anna@xxxxxx> > + > +description: | > + A PRU application/consumer/user node typically uses one or more PRU device > + nodes to implement a PRU application/functionality. Each application/client > + node would need a reference to at least a PRU node, and optionally define > + some properties needed for hardware/firmware configuration. The below > + properties are a list of common properties supported by the PRU remoteproc > + infrastructure. > + > + The application nodes shall define their own bindings like regular platform > + devices, so below are in addition to each node's bindings. > + > +properties: > + ti,prus: > + $ref: /schemas/types.yaml#/definitions/phandle-array > + description: phandles to the PRU, RTU or Tx_PRU nodes used > + minItems: 1 > + maxItems: 6 > + items: > + maxItems: 1 > + > + firmware-name: > + $ref: /schemas/types.yaml#/definitions/string-array > + description: | > + firmwares for the PRU cores, the default firmware for the core from > + the PRU node will be used if not provided. The firmware names should > + correspond to the PRU cores listed in the 'ti,prus' property So should be the name number of entries?: minItems: 1 maxItems: 6 > + > + ti,pruss-gp-mux-sel: > + $ref: /schemas/types.yaml#/definitions/uint32-array minItems: 1 > + maxItems: 6 > + items: > + enum: [0, 1, 2, 3, 4] > + description: | > + array of values for the GP_MUX_SEL under PRUSS_GPCFG register for a PRU. > + This selects the internal muxing scheme for the PRU instance. Values > + should correspond to the PRU cores listed in the 'ti,prus' property. The > + GP_MUX_SEL setting is a per-slice setting (one setting for PRU0, RTU0, > + and Tx_PRU0 on K3 SoCs). Use the same value for all cores within the > + same slice in the associative array. If the array size is smaller than > + the size of 'ti,prus' property, the default out-of-reset value (0) for the > + PRU core is used. > + > +required: > + - ti,prus > + > +dependencies: > + firmware-name: [ 'ti,prus' ] > + ti,pruss-gp-mux-sel: [ 'ti,prus' ] This doesn't make sense because 'ti,prus' is already required. Should all 3 properties always be required? > + > +additionalProperties: true > + > +examples: > + - | > + /* PRU application node example */ > + pru-app { > + ti,prus = <&pru0>, <&pru1>; > + firmware-name = "pruss-app-fw0", "pruss-app-fw1"; > + ti,pruss-gp-mux-sel = <2>, <1>; This example never validates, but okay I guess. > + }; > -- > 2.17.1 > >
