Here is my input to the ongoing discussions of how to structure the upcoming pinctrl API and devicetree nodes in Zephyr. These ideas build upon the many proposals and ideas by other members of the community. The following PRs have been used as inspiration:
The discussions have focused on two different areas of implementation; the pinctrl C/C++ API for configuring pin function and pin properties at runtime, and the devicetree representation of pre-defined pin functions and pin properties.
Multiple ideas for devicetree representation has surfaced during the ongoing API discussions. From what I have seen, the discussions have been centred around the following concepts:
Given the differences between the pin controllers/pin multiplexers present in the various SoCs, I do not see any way (or even value) of a truly common API. One option that comes close is an API that allows passing in a SoC pinctrl/pinmux specific data structure (or array of said data structure along with a length) representing the specific information needed for that given SoC pinctrl/pinmux as a void pointer.
The data structures representing the
Should a user application have a need for
For more advanced use-cases (e.g those outlined for CircuitPython in #11918), the above can also support run-time configuration of pinctrl/pinmux without any compile-time devicetree representation of the desired
This is basically what we have for the clock control API. I could see some value in this, since it would allow hardware-specific overlays to configure a subsystem or application for e.g. "on" / "powersave" without cluttering the source code with board ifdefs.
For DTS, we have something like this today for NXP:
In SOC-pinctrl.dtsi (this data is generated from vendor XML files):
From #35039 for STM32:
From SoC dtsi we have:
I have been giving this some more thought. The pinctrl DTS grouping makes sense if the pinctrl API takes an index for which group to configure. If the API does not take an index (but instead takes a pointer to a semi-opaque structure as discussed above) I do not see any gain from adding the group indirection in DTS. I therefore think DTS representation option 3. (see above) makes most sense.