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.1Hello,
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
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é
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
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é
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
© 2016 - 2025 Red Hat, Inc.