From: Rob Herring <robh@kernel.org>
To: Herve Codina <herve.codina@bootlin.com>
Cc: "Uwe Kleine-König" <ukleinek@kernel.org>,
"Saravana Kannan" <saravanak@google.com>,
linux-pwm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
"Luca Ceresoli" <luca.ceresoli@bootlin.com>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>
Subject: Re: [PATCH v2 1/1] pwm: Add support for pwm nexus dt bindings
Date: Fri, 17 Jan 2025 07:38:54 -0600 [thread overview]
Message-ID: <20250117133854.GA500748-robh@kernel.org> (raw)
In-Reply-To: <20250108161853.431915-1-herve.codina@bootlin.com>
On Wed, Jan 08, 2025 at 05:18:53PM +0100, Herve Codina wrote:
> 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 #*-cells, *-map,
> *-map-mask and *-map-pass-thru properties. This is already supported
> by of_parse_phandle_with_args_map().
You need a schema for all these properties (pwm-map, etc.). A wildcard
doesn't work because '-map$' is not unique:
$ dt-extract-props Documentation/devicetree/bindings/ | grep '\-map'
'adi,pdm-clk-map': ['uint32-array'],
'arm,v2m-memory-map': ['string'],
'brcm,ccode-map': ['string-array'],
'brcm,ccode-map-trivial': ['flag'],
'brcm,int-map-mask': ['uint32-array'],
'charge-current-limit-mapping': ['uint32-matrix'],
'dai-tdm-slot-width-map': ['uint32-matrix'],
'data-mapping': ['string-array'],
'fsl,asrc-clk-map': ['uint32'],
'gpio-fan,speed-map': ['uint32-matrix'],
'gpio-map': ['uint32-matrix'],
'gpio-map-mask': ['uint32-array'],
'gpio-map-pass-thru': ['uint32-array'],
'intel,vm-map': ['uint8-array'],
'interrupt-map': ['uint32-matrix'],
'interrupt-map-mask': ['uint32-array'],
'iommu-map': ['uint32-matrix'],
'iommu-map-mask': ['uint32'],
'linux,rc-map-name': ['string'],
'msi-map': ['uint32-matrix'],
'msi-map-mask': ['uint32'],
'mstar,irqs-map-range': ['uint32-matrix'],
'no-map': ['flag'],
'port-mapping-mode': ['flag'],
'qcom,mpm-pin-map': ['uint32-matrix'],
'qcom,port-mapping': ['uint32-array'],
'qcom,rx-port-mapping': ['uint32-array'],
'qcom,tx-port-mapping': ['uint32-array'],
'rockchip,path-map': ['uint32-array'],
'ti,linear-mapping-mode': ['flag'],
Rob
prev parent reply other threads:[~2025-01-17 13:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-08 16:18 [PATCH v2 1/1] pwm: Add support for pwm nexus dt bindings Herve Codina
2025-01-17 8:27 ` Herve Codina
2025-01-17 9:13 ` Uwe Kleine-König
2025-01-17 13:38 ` Rob Herring [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250117133854.GA500748-robh@kernel.org \
--to=robh@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=herve.codina@bootlin.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=luca.ceresoli@bootlin.com \
--cc=saravanak@google.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=ukleinek@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.