[PATCH v3 0/2] pwm: Add support for pwm nexus node

[PATCH v3 0/2] pwm: Add support for pwm nexus node

[Herve Codina]

Platforms can have a standardized connector/expansion slot that exposes
PWMs signals to expansion boards.

A nexus node [1] allows to remap a phandle list in a consumer node
through a connector node in a generic way. With this remapping, the
consumer node needs to know only about the nexus node. Resources behind
the nexus node are decoupled by the nexus node itself.

This is particularly useful when this consumer is described in a
device-tree overlay. Indeed, to have the exact same overlay reused with
several base systems the overlay needs to known only about the connector
is going to be applied to without any knowledge of the SoC (or the
component providing the resource) available in the system.

As an example, suppose 3 PWMs connected to a connector. The connector
PWM 0 and 2 comes from the PWM 1 and 3 of the pwm-controller1. The
connector PWM 1 comes from the PWM 4 of the pwm-controller2. An
expansion device is connected to the connector and uses the connector
PMW 1.

Nexus node support in PWM allows the following description:
        soc {
                soc_pwm1: pwm-controller1 {
                        #pwm-cells = <3>;
                };

                soc_pwm2: pwm-controller2 {
                        #pwm-cells = <3>;
                };
        };

        connector: connector {
                #pwm-cells = <3>;
                pwm-map = <0 0 0 &soc_pwm1 1 0 0>,
                          <1 0 0 &soc_pwm2 4 0 0>,
                          <2 0 0 &soc_pwm1 3 0 0>;
                pwm-map-mask = <0xffffffff 0x0 0x0>;
                pwm-map-pass-thru = <0x0 0xffffffff 0xffffffff>;
        };

        expansion_device {
                pwms = <&connector 1 57000 0>;
        };

From the expansion device point of view, the PWM requested is the PWM 1
available at the connector regardless of the exact PWM wired to this
connector PWM 1. Thanks to nexus node remapping described at connector
node, this PWM is the PWM 4 of the pwm-controller2.

[1] https://github.com/devicetree-org/devicetree-specification/blob/v0.4/source/chapter2-devicetree-basics.rst#nexus-nodes-and-specifier-mapping

Compared to previous iteration, this v3 series mainly adds the PWM nexus node
devicetree binding.

Best regards,
Hervé Codina

Changes v2 -> v3
  - Patch 1 (new patch)
    devicetree binding

  - Patch 2 (single patch in v2)
    Fix typos in commit log DT example.
    Avoid wildcard for PWM nexus node properties in the commit log.

Changes v1 -> v2
  v1: https://lore.kernel.org/all/20241202164459.157672-1-herve.codina@bootlin.com/

  - Rework commit log

Herve Codina (2):
  dt-bindings: pwm: Add support for PWM nexus node
  pwm: Add support for pwm nexus dt bindings

 .../bindings/pwm/pwm-nexus-node.yaml          | 65 +++++++++++++++++++
 drivers/pwm/core.c                            |  3 +-
 2 files changed, 66 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml

-- 
2.47.1

[PATCH v3 1/2] dt-bindings: pwm: Add support for PWM nexus node

[Herve Codina]

Platforms can have a standardized connector/expansion slot that exposes
PWMs signals to expansion boards.

A nexus node [1] allows to remap a phandle list in a consumer node
through a connector node in a generic way. With this remapping, the
consumer node needs to know only about the nexus node. Resources behind
the nexus node are decoupled by the nexus node itself.

This is particularly useful when this consumer is described in a
device-tree overlay. Indeed, to have the exact same overlay reused with
several base systems the overlay needs to known only about the connector
is going to be applied to without any knowledge of the SoC (or the
component providing the resource) available in the system.

As an example, suppose 3 PWMs connected to a connector. The connector
PWM 0 and 2 comes from the PWM 1 and 3 of the pwm-controller1. The
connector PWM 1 comes from the PWM 4 of the pwm-controller2. An
expansion device is connected to the connector and uses the connector
PMW 1.

Nexus node support in PWM allows the following description:
        soc {
                soc_pwm1: pwm-controller1 {
                        #pwm-cells = <3>;
                };

                soc_pwm2: pwm-controller2 {
                        #pwm-cells = <3>;
                };
        };

        connector: connector {
                #pwm-cells = <3>;
                pwm-map = <0 0 0 &soc_pwm1 1 0 0>,
                          <1 0 0 &soc_pwm2 4 0 0>,
                          <2 0 0 &soc_pwm1 3 0 0>;
                pwm-map-mask = <0xffffffff 0x0 0x0>;
                pwm-map-pass-thru = <0x0 0xffffffff 0xffffffff>;
        };

        expansion_device {
                pwms = <&connector 1 57000 0>;
        };

From the expansion device point of view, the PWM requested is the PWM 1
available at the connector regardless of the exact PWM wired to this
connector PWM 1. Thanks to nexus node remapping described at connector
node, this PWM is the PWM 4 of the pwm-controller2.

[1] https://github.com/devicetree-org/devicetree-specification/blob/v0.4/source/chapter2-devicetree-basics.rst#nexus-nodes-and-specifier-mapping

Signed-off-by: Herve Codina <herve.codina@bootlin.com>
---
 .../bindings/pwm/pwm-nexus-node.yaml          | 65 +++++++++++++++++++
 1 file changed, 65 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml

diff --git a/Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml b/Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml
new file mode 100644
index 000000000000..55412fe50d01
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml
@@ -0,0 +1,65 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pwm/pwm-nexus-node.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PWM Nexus node properties
+
+description:
+  Platforms can have a standardized connector/expansion slot that exposes PWMs
+  signals to expansion boards.
+
+  A nexus node allows to remap a phandle list in a consumer node through a
+  connector node in a generic way. With this remapping, the consumer node needs
+  to know only about the nexus node. Resources behind the nexus node are
+  decoupled by the nexus node itself.
+
+maintainers:
+  - Herve Codina <herve.codina@bootlin.com>
+
+select: true
+
+properties:
+  '#pwm-cells': true
+
+  pwm-map:
+    $ref: /schemas/types.yaml#/definitions/uint32-matrix
+
+  pwm-map-mask:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+
+  pwm-map-pass-thru:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+
+dependentRequired:
+  pwm-map: ['#pwm-cells']
+  pwm-map-mask: [ pwm-map ]
+  pwm-map-pass-thru: [ pwm-map ]
+
+additionalProperties: true
+
+examples:
+  - |
+        pwm1: pwm@100 {
+            reg = <0x100 0x10>;
+            #pwm-cells = <3>;
+        };
+
+        pwm2: pwm@200 {
+            reg = <0x200 0x10>;
+            #pwm-cells = <3>;
+        };
+
+        connector: connector {
+            #pwm-cells = <3>;
+            pwm-map = <0 0 0 &pwm1 1 0 0>,
+                      <1 0 0 &pwm2 4 0 0>,
+                      <2 0 0 &pwm1 3 0 0>;
+            pwm-map-mask = <0xffffffff 0x0 0x0>;
+            pwm-map-pass-thru = <0x0 0xffffffff 0xffffffff>;
+        };
+
+        device {
+            pwms = <&connector 1 57000 0>;
+        };
-- 
2.47.1

Re: [PATCH v3 1/2] dt-bindings: pwm: Add support for PWM nexus node

[Rob Herring]

On Wed, Feb 05, 2025 at 10:55:42AM +0100, Herve Codina wrote:
> Platforms can have a standardized connector/expansion slot that exposes
> PWMs signals to expansion boards.
> 
> A nexus node [1] allows to remap a phandle list in a consumer node
> through a connector node in a generic way. With this remapping, the
> consumer node needs to know only about the nexus node. Resources behind
> the nexus node are decoupled by the nexus node itself.
> 
> This is particularly useful when this consumer is described in a
> device-tree overlay. Indeed, to have the exact same overlay reused with
> several base systems the overlay needs to known only about the connector
> is going to be applied to without any knowledge of the SoC (or the
> component providing the resource) available in the system.
> 
> As an example, suppose 3 PWMs connected to a connector. The connector
> PWM 0 and 2 comes from the PWM 1 and 3 of the pwm-controller1. The
> connector PWM 1 comes from the PWM 4 of the pwm-controller2. An
> expansion device is connected to the connector and uses the connector
> PMW 1.
> 
> Nexus node support in PWM allows the following description:
>         soc {
>                 soc_pwm1: pwm-controller1 {
>                         #pwm-cells = <3>;
>                 };
> 
>                 soc_pwm2: pwm-controller2 {
>                         #pwm-cells = <3>;
>                 };
>         };
> 
>         connector: connector {
>                 #pwm-cells = <3>;
>                 pwm-map = <0 0 0 &soc_pwm1 1 0 0>,
>                           <1 0 0 &soc_pwm2 4 0 0>,
>                           <2 0 0 &soc_pwm1 3 0 0>;
>                 pwm-map-mask = <0xffffffff 0x0 0x0>;
>                 pwm-map-pass-thru = <0x0 0xffffffff 0xffffffff>;
>         };
> 
>         expansion_device {
>                 pwms = <&connector 1 57000 0>;
>         };
> 
> >From the expansion device point of view, the PWM requested is the PWM 1
> available at the connector regardless of the exact PWM wired to this
> connector PWM 1. Thanks to nexus node remapping described at connector
> node, this PWM is the PWM 4 of the pwm-controller2.
> 
> [1] https://github.com/devicetree-org/devicetree-specification/blob/v0.4/source/chapter2-devicetree-basics.rst#nexus-nodes-and-specifier-mapping
> 
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> ---
>  .../bindings/pwm/pwm-nexus-node.yaml          | 65 +++++++++++++++++++
>  1 file changed, 65 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml
> 
> diff --git a/Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml b/Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml
> new file mode 100644
> index 000000000000..55412fe50d01
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pwm/pwm-nexus-node.yaml
> @@ -0,0 +1,65 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pwm/pwm-nexus-node.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: PWM Nexus node properties
> +
> +description:

You need '>' on the end to preserve paragraphs. With that,

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

[PATCH v3 2/2] pwm: Add support for pwm nexus dt bindings

[Herve Codina]

Platforms can have a standardized connector/expansion slot that exposes
signals like PWMs to expansion boards in an SoC agnostic way.

The support for nexus node [1] has been added to handle those cases in
commit bd6f2fd5a1d5 ("of: Support parsing phandle argument lists through
a nexus node"). This commit introduced of_parse_phandle_with_args_map()
to handle nexus nodes in a generic way and the gpio subsystem adopted
the support in commit c11e6f0f04db ("gpio: Support gpio nexus dt
bindings").

A nexus node allows to remap a phandle list in a consumer node through a
connector node in a generic way. With this remapping supported, the
consumer node needs to knwow only about the nexus node. Resources behind
the nexus node are decoupled by the nexus node itself.

This is particularly useful when this consumer is described in a
device-tree overlay. Indeed, to have the exact same overlay reused with
several base systems the overlay needs to known only about the connector
is going to be applied to without any knowledge of the SoC (or the
component providing the resource) available in the system.

As an example, suppose 3 PWMs connected to a connector. The connector
PWM 0 and 2 comes from the PWM 1 and 3 of the pwm-controller1. The
connector PWM 1 comes from the PWM 4 of the pwm-controller2. An
expansion device is connected to the connector and uses the connector
PMW 1.

Nexus node support in PWM allows the following description:
	soc {
		soc_pwm1: pwm-controller1 {
			#pwm-cells = <3>;
		};

		soc_pwm2: pwm-controller2 {
			#pwm-cells = <3>;
		};
	};

	connector: connector {
		#pwm-cells = <3>;
		pwm-map = <0 0 0 &soc_pwm1 1 0 0>,
			  <1 0 0 &soc_pwm2 4 0 0>,
			  <2 0 0 &soc_pwm1 3 0 0>;
		pwm-map-mask = <0xffffffff 0x0 0x0>;
		pwm-map-pass-thru = <0x0 0xffffffff 0xffffffff>;
	};

	expansion_device {
		pwms = <&connector 1 57000 0>;
	};

From the expansion device point of view, the PWM requested is the PWM 1
available at the connector regardless of the exact PWM wired to this
connector PWM 1. Thanks to nexus node remapping described at connector
node, this PWM is the PWM 4 of the pwm-controller2.

The nexus node remapping handling consists in handling #pwm-cells,
pwm-map, pwm-map-mask and pwm-map-pass-thru properties. This is already
supported by of_parse_phandle_with_args_map() thanks to its stem_name
parameter.

Add support for nexus node device-tree binding and the related remapping
in the PWM subsystem by simply using of_parse_phandle_with_args_map()
instead of of_parse_phandle_with_args().

[1] https://github.com/devicetree-org/devicetree-specification/blob/v0.4/source/chapter2-devicetree-basics.rst#nexus-nodes-and-specifier-mapping

Signed-off-by: Herve Codina <herve.codina@bootlin.com>
---
 drivers/pwm/core.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index ccd54c089bab..a4eedf09922d 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -1716,8 +1716,7 @@ static struct pwm_device *of_pwm_get(struct device *dev, struct device_node *np,
 			return ERR_PTR(index);
 	}
 
-	err = of_parse_phandle_with_args(np, "pwms", "#pwm-cells", index,
-					 &args);
+	err = of_parse_phandle_with_args_map(np, "pwms", "pwm", index, &args);
 	if (err) {
 		pr_err("%s(): can't parse \"pwms\" property\n", __func__);
 		return ERR_PTR(err);
-- 
2.47.1

Re: [PATCH v3 2/2] pwm: Add support for pwm nexus dt bindings

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 1351 bytes --]

Hello,

I really like this mechanism. Assuming the dt guys are happy yet, I
intend to merge it. Just some detail question below.

On Wed, Feb 05, 2025 at 10:55:43AM +0100, Herve Codina wrote:
> Nexus node support in PWM allows the following description:
> 	soc {
> 		soc_pwm1: pwm-controller1 {
> 			#pwm-cells = <3>;
> 		};
> 
> 		soc_pwm2: pwm-controller2 {
> 			#pwm-cells = <3>;
> 		};
> 	};
> 
> 	connector: connector {
> 		#pwm-cells = <3>;
> 		pwm-map = <0 0 0 &soc_pwm1 1 0 0>,
> 			  <1 0 0 &soc_pwm2 4 0 0>,
> 			  <2 0 0 &soc_pwm1 3 0 0>;
> 		pwm-map-mask = <0xffffffff 0x0 0x0>;
> 		pwm-map-pass-thru = <0x0 0xffffffff 0xffffffff>;
> 	};
> 
> 	expansion_device {
> 		pwms = <&connector 1 57000 0>;
> 	};

Does this also work if &soc_pwm2 has #pwm-cells = <2>? Would I need just

	pwm-map = <0 0 0 &soc_pwm1 1 0 0>,
		  <1 0 0 &soc_pwm2 4 0>,
		  <2 0 0 &soc_pwm1 3 0 0>;

then and

	pwms = <&connector 1 57000 0>;

would then have the same effect as

	pwms = <&soc_pwm2 4 57000>

and the 0 is dropped then? Could I adapt the mapping that the effect is

	pwms = <&soc_pwm2 57000 0>

instead?

This smells a bit ugly and I wonder if this gives a motivation to extend
the binding for PWMs that use #pwm-cells = <2> (or less) to also accept
the default 3-cell binding.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 2/2] pwm: Add support for pwm nexus dt bindings

[Herve Codina]

Hi Uwe,

On Wed, 5 Feb 2025 12:38:32 +0100
Uwe Kleine-König <ukleinek@kernel.org> wrote:

> Hello,
> 
> I really like this mechanism. Assuming the dt guys are happy yet, I
> intend to merge it. Just some detail question below.
> 
> On Wed, Feb 05, 2025 at 10:55:43AM +0100, Herve Codina wrote:
> > Nexus node support in PWM allows the following description:
> > 	soc {
> > 		soc_pwm1: pwm-controller1 {
> > 			#pwm-cells = <3>;
> > 		};
> > 
> > 		soc_pwm2: pwm-controller2 {
> > 			#pwm-cells = <3>;
> > 		};
> > 	};
> > 
> > 	connector: connector {
> > 		#pwm-cells = <3>;
> > 		pwm-map = <0 0 0 &soc_pwm1 1 0 0>,
> > 			  <1 0 0 &soc_pwm2 4 0 0>,
> > 			  <2 0 0 &soc_pwm1 3 0 0>;
> > 		pwm-map-mask = <0xffffffff 0x0 0x0>;
> > 		pwm-map-pass-thru = <0x0 0xffffffff 0xffffffff>;
> > 	};
> > 
> > 	expansion_device {
> > 		pwms = <&connector 1 57000 0>;
> > 	};  
> 
> Does this also work if &soc_pwm2 has #pwm-cells = <2>? Would I need just
> 
> 	pwm-map = <0 0 0 &soc_pwm1 1 0 0>,
> 		  <1 0 0 &soc_pwm2 4 0>,
> 		  <2 0 0 &soc_pwm1 3 0 0>;

Yes, exactly.

> 
> then and
> 
> 	pwms = <&connector 1 57000 0>;
> 
> would then have the same effect as
> 
> 	pwms = <&soc_pwm2 4 57000>

Yes, the last 0 (or any other values) in pwms = <&connector 1 57000 0> is
simply dropped in the translation (#pwm-cells = 3 in connector nexus to
#pwm-cells = 2 in soc_pwm1 node).

In more generic terms, it works in translation from #pwm-cells = N to
#pwm-cells = M by simply dropping the last N-M values.

Also note that even if values are dropped, you need to have them set when
you point the nexus node because #pwm-cells = 3 is set in the connector
node and need to be fixed and usable for all the entries in the
pwm-map table.

> 
> and the 0 is dropped then? Could I adapt the mapping that the effect is
> 
> 	pwms = <&soc_pwm2 57000 0>

In this one, I think you miss the PWM number
If I read correctly this line you ask for the PWM 57000 from the soc_pwm2
controller. This doesn't make sense :)

If I didn't answer already, can you clarify your point here ?
> 
> instead?


> 
> This smells a bit ugly and I wonder if this gives a motivation to extend
> the binding for PWMs that use #pwm-cells = <2> (or less) to also accept
> the default 3-cell binding.

With my understanding in the translation performed, this is not needed.

Also the following translation works:

	soc {
 		soc_pwm1: pwm-controller1 {
 			#pwm-cells = <2>;
		};

		soc_pwm2: pwm-controller2 {
			#pwm-cells = <3>;
		};
 	};

	connector: connector {
		#pwm-cells = <2>;   <--------- Note the 2 here
 		pwm-map = <0 0 &soc_pwm1 1 0>,
 			  <1 0 &soc_pwm2 4 0 123>,
 		pwm-map-mask = <0xffffffff 0x0>;   <---- #pwm-cells = <2> 
 		pwm-map-pass-thru = <0x0 0xffffffff>; <---- #pwm-cells = <2>
 	};

pwms = <&connector 1 57000> translates to pwms = <&soc_pwm2 1 57000 123>

The last value in the translation (i.e 123) was added during the translation
(#pwm-cells = <2> to #pwm-cells = <3>) from the value set in the pwm-map
table.

Hope I answered your questions.

Best regards,
Hervé

Re: [PATCH v3 2/2] pwm: Add support for pwm nexus dt bindings

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 2036 bytes --]

Hello Hervé,

On Wed, Feb 05, 2025 at 02:37:37PM +0100, Herve Codina wrote:
> On Wed, 5 Feb 2025 12:38:32 +0100
> Uwe Kleine-König <ukleinek@kernel.org> wrote:
> > Does this also work if &soc_pwm2 has #pwm-cells = <2>? Would I need just
> > 
> > 	pwm-map = <0 0 0 &soc_pwm1 1 0 0>,
> > 		  <1 0 0 &soc_pwm2 4 0>,
> > 		  <2 0 0 &soc_pwm1 3 0 0>;
> 
> Yes, exactly.
> 
> > 
> > then and
> > 
> > 	pwms = <&connector 1 57000 0>;
> > 
> > would then have the same effect as
> > 
> > 	pwms = <&soc_pwm2 4 57000>
> 
> Yes, the last 0 (or any other values) in pwms = <&connector 1 57000 0> is
> simply dropped in the translation (#pwm-cells = 3 in connector nexus to
> #pwm-cells = 2 in soc_pwm1 node).
> 
> In more generic terms, it works in translation from #pwm-cells = N to
> #pwm-cells = M by simply dropping the last N-M values.
> 
> Also note that even if values are dropped, you need to have them set when
> you point the nexus node because #pwm-cells = 3 is set in the connector
> node and need to be fixed and usable for all the entries in the
> pwm-map table.

Makes sense.

> > and the 0 is dropped then? Could I adapt the mapping that the effect is
> > 
> > 	pwms = <&soc_pwm2 57000 0>
> 
> In this one, I think you miss the PWM number
> 
> If I read correctly this line you ask for the PWM 57000 from the soc_pwm2
> controller. This doesn't make sense :)

Some pwm chip devices with only a single output line use this. The first
paramter is the default period (which is passed in the 2nd parameter
normally) and the 2nd paramter are flags (normally the 3rd parameter).
Back then the rationale was that for such hardware, the line index is
zero always anyhow, and so could better be skipped.

Compare of_pwm_xlate_with_flags() to of_pwm_single_xlate(). pwm-pxa is
the single offender using the latter. Thinking about that, it's easy
enough to fix without breaking compatibility. I'll tackle that.

So for a PWM on pxa `<&soc_pwm2 57000 0>` works fine.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 2/2] pwm: Add support for pwm nexus dt bindings

[Herve Codina]

Hi Uwe,

On Wed, 5 Feb 2025 17:29:30 +0100
Uwe Kleine-König <ukleinek@kernel.org> wrote:

> Hello Hervé,
> 
> On Wed, Feb 05, 2025 at 02:37:37PM +0100, Herve Codina wrote:
> > On Wed, 5 Feb 2025 12:38:32 +0100
> > Uwe Kleine-König <ukleinek@kernel.org> wrote:  
> > > Does this also work if &soc_pwm2 has #pwm-cells = <2>? Would I need just
> > > 
> > > 	pwm-map = <0 0 0 &soc_pwm1 1 0 0>,
> > > 		  <1 0 0 &soc_pwm2 4 0>,
> > > 		  <2 0 0 &soc_pwm1 3 0 0>;  
> > 
> > Yes, exactly.
> >   
> > > 
> > > then and
> > > 
> > > 	pwms = <&connector 1 57000 0>;
> > > 
> > > would then have the same effect as
> > > 
> > > 	pwms = <&soc_pwm2 4 57000>  
> > 
> > Yes, the last 0 (or any other values) in pwms = <&connector 1 57000 0> is
> > simply dropped in the translation (#pwm-cells = 3 in connector nexus to
> > #pwm-cells = 2 in soc_pwm1 node).
> > 
> > In more generic terms, it works in translation from #pwm-cells = N to
> > #pwm-cells = M by simply dropping the last N-M values.
> > 
> > Also note that even if values are dropped, you need to have them set when
> > you point the nexus node because #pwm-cells = 3 is set in the connector
> > node and need to be fixed and usable for all the entries in the
> > pwm-map table.  
> 
> Makes sense.
> 
> > > and the 0 is dropped then? Could I adapt the mapping that the effect is
> > > 
> > > 	pwms = <&soc_pwm2 57000 0>  
> > 
> > In this one, I think you miss the PWM number
> > 
> > If I read correctly this line you ask for the PWM 57000 from the soc_pwm2
> > controller. This doesn't make sense :)  
> 
> Some pwm chip devices with only a single output line use this. The first
> paramter is the default period (which is passed in the 2nd parameter
> normally) and the 2nd paramter are flags (normally the 3rd parameter).
> Back then the rationale was that for such hardware, the line index is
> zero always anyhow, and so could better be skipped.
> 
> Compare of_pwm_xlate_with_flags() to of_pwm_single_xlate(). pwm-pxa is
> the single offender using the latter. Thinking about that, it's easy
> enough to fix without breaking compatibility. I'll tackle that.
> 
> So for a PWM on pxa `<&soc_pwm2 57000 0>` works fine.

I see. In this case, a parameter shift during translation would be needed to
skip the PWM line index in the translated arguments. This is not currently
neither described in device-tree specicication [0] nor handled in the common
code of_parse_phandle_with_args_map() in the kernel.

This use case can appear for resources other than PWMs and IMHO it should be
nice to have it supported.

I think this support should proposed out of this series adding support for
PWM nexus nodes.

Is it blocking for this current series ?

[0] https://github.com/devicetree-org/devicetree-specification/releases/download/v0.4/devicetree-specification-v0.4.pdf

Best regards,
Hervé

Re: [PATCH v3 2/2] pwm: Add support for pwm nexus dt bindings

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 1964 bytes --]

Hello Hervé,

On Wed, Feb 05, 2025 at 06:19:30PM +0100, Herve Codina wrote:
> On Wed, 5 Feb 2025 17:29:30 +0100
> Uwe Kleine-König <ukleinek@kernel.org> wrote:
> 
> > On Wed, Feb 05, 2025 at 02:37:37PM +0100, Herve Codina wrote:
> > > On Wed, 5 Feb 2025 12:38:32 +0100
> > > Uwe Kleine-König <ukleinek@kernel.org> wrote:  
> > > > Could I adapt the mapping that the effect is
> > > > 
> > > > 	pwms = <&soc_pwm2 57000 0>  
> > > 
> > > In this one, I think you miss the PWM number
> > > 
> > > If I read correctly this line you ask for the PWM 57000 from the soc_pwm2
> > > controller. This doesn't make sense :)  
> > 
> > Some pwm chip devices with only a single output line use this. The first
> > paramter is the default period (which is passed in the 2nd parameter
> > normally) and the 2nd paramter are flags (normally the 3rd parameter).
> > Back then the rationale was that for such hardware, the line index is
> > zero always anyhow, and so could better be skipped.
> > 
> > Compare of_pwm_xlate_with_flags() to of_pwm_single_xlate(). pwm-pxa is
> > the single offender using the latter. Thinking about that, it's easy
> > enough to fix without breaking compatibility. I'll tackle that.
> > 
> > So for a PWM on pxa `<&soc_pwm2 57000 0>` works fine.
> 
> I see. In this case, a parameter shift during translation would be needed to
> skip the PWM line index in the translated arguments. This is not currently
> neither described in device-tree specicication [0] nor handled in the common
> code of_parse_phandle_with_args_map() in the kernel.

OK, that's what I expected.

> This use case can appear for resources other than PWMs and IMHO it should be
> nice to have it supported.
> 
> I think this support should proposed out of this series adding support for
> PWM nexus nodes.
> 
> Is it blocking for this current series ?

Not from my side. If I get an Ack from the dt guys, I'll merge it.

Thanks
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v3 0/2] pwm: Add support for pwm nexus node

[Uwe Kleine-König]

[-- Attachment #1: Type: text/plain, Size: 195 bytes --]

Hello,

applied both patches to

	https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git pwm/for-next

with the fixup that Rob requested in the first patch. Thanks!

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]