| Message ID | 20250225-hdp-upstream-v1-2-9d049c65330a@foss.st.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Introduce HDP support for STM32MP platforms | expand |
On 25/02/2025 09:48, Clément Le Goffic wrote: > + > +maintainers: > + - Clément LE GOFFIC <clement.legoffic@foss.st.com> > + > +description: | Do not need '|' unless you need to preserve formatting. > + STMicroelectronics's STM32 MPUs integrate a Hardware Debug Port (HDP). > + It allows to output internal signals on SoC's GPIO. > + > +properties: > + compatible: > + const: st,stm32mp-hdp There is a mess in STM SoCs. Sometimes you call SoC stm32, sometimes stm32mp and sometimes stm32mpXX. Define for all your STM contributions what is the actual SoC. This feedback was already given to ST. > + > + reg: > + maxItems: 1 > + > + clocks: > + maxItems: 1 > + > +patternProperties: > + '-pins$': > + type: object > + $ref: pinmux-node.yaml# > + > + properties: > + function: > + enum: [ "0", "1", "2", "3", "4", "5", "6", "7", > + "8", "9", "10", "11", "12", "13", "14", > + "15" ] Function which has a number is not really useful. What does it even express? > + > + pins: > + enum: [ hdp0, hdp1, hdp2, hdp3, hdp4, hdp5, hdp6, hdp7 ] > + > + required: > + - function > + - pins > + > + additionalProperties: false > + > +allOf: > + - $ref: pinctrl.yaml# > + > +required: > + - compatible > + - reg > + - clocks > + > +additionalProperties: false > + > +examples: > + - | > + #include <dt-bindings/clock/stm32mp1-clks.h> > + #include <dt-bindings/pinctrl/stm32mp15-hdp.h> > + //Example 1 Drop Best regards, Krzysztof
On 2/25/25 14:04, Krzysztof Kozlowski wrote: > On 25/02/2025 09:48, Clément Le Goffic wrote: >> + >> +maintainers: >> + - Clément LE GOFFIC <clement.legoffic@foss.st.com> >> + >> +description: | > > > Do not need '|' unless you need to preserve formatting. Ok >> + STMicroelectronics's STM32 MPUs integrate a Hardware Debug Port (HDP). >> + It allows to output internal signals on SoC's GPIO. >> + >> +properties: >> + compatible: >> + const: st,stm32mp-hdp > > There is a mess in STM SoCs. Sometimes you call SoC stm32, sometimes > stm32mp and sometimes stm32mpXX. > > Define for all your STM contributions what is the actual SoC. This > feedback was already given to ST. > >> + >> + reg: >> + maxItems: 1 >> + >> + clocks: >> + maxItems: 1 >> + >> +patternProperties: >> + '-pins$': >> + type: object >> + $ref: pinmux-node.yaml# >> + >> + properties: >> + function: >> + enum: [ "0", "1", "2", "3", "4", "5", "6", "7", >> + "8", "9", "10", "11", "12", "13", "14", >> + "15" ] > > Function which has a number is not really useful. What does it even express? As said in my previous answer, function names are very different from one platform to another. Numbers were used as string to be generic. I'll consider it in a V2. > >> + >> + pins: >> + enum: [ hdp0, hdp1, hdp2, hdp3, hdp4, hdp5, hdp6, hdp7 ] >> + >> + required: >> + - function >> + - pins >> + >> + additionalProperties: false >> + >> +allOf: >> + - $ref: pinctrl.yaml# >> + >> +required: >> + - compatible >> + - reg >> + - clocks >> + >> +additionalProperties: false >> + >> +examples: >> + - | >> + #include <dt-bindings/clock/stm32mp1-clks.h> >> + #include <dt-bindings/pinctrl/stm32mp15-hdp.h> >> + //Example 1 > > Drop Ok > > Best regards, > Krzysztof
On 25/02/2025 16:51, Clement LE GOFFIC wrote: > On 2/25/25 14:04, Krzysztof Kozlowski wrote: >> On 25/02/2025 09:48, Clément Le Goffic wrote: >>> + >>> +maintainers: >>> + - Clément LE GOFFIC <clement.legoffic@foss.st.com> >>> + >>> +description: | >> >> >> Do not need '|' unless you need to preserve formatting. > > Ok > >>> + STMicroelectronics's STM32 MPUs integrate a Hardware Debug Port (HDP). >>> + It allows to output internal signals on SoC's GPIO. >>> + >>> +properties: >>> + compatible: >>> + const: st,stm32mp-hdp >> >> There is a mess in STM SoCs. Sometimes you call SoC stm32, sometimes >> stm32mp and sometimes stm32mpXX. >> >> Define for all your STM contributions what is the actual SoC. This >> feedback was already given to ST. >> >>> + >>> + reg: >>> + maxItems: 1 >>> + >>> + clocks: >>> + maxItems: 1 >>> + >>> +patternProperties: >>> + '-pins$': >>> + type: object >>> + $ref: pinmux-node.yaml# >>> + >>> + properties: >>> + function: >>> + enum: [ "0", "1", "2", "3", "4", "5", "6", "7", >>> + "8", "9", "10", "11", "12", "13", "14", >>> + "15" ] >> >> Function which has a number is not really useful. What does it even express? > > As said in my previous answer, function names are very different from > one platform to another. Numbers were used as string to be generic. > I'll consider it in a V2. What does it mean "one platform to another"? This is one platform! Is this some sort of continuation of SoC compatible mess? What are the exact functions written in datasheet? Best regards, Krzysztof
On 2/26/25 08:21, Krzysztof Kozlowski wrote: > On 25/02/2025 16:51, Clement LE GOFFIC wrote: >> On 2/25/25 14:04, Krzysztof Kozlowski wrote: >>> On 25/02/2025 09:48, Clément Le Goffic wrote: >>>> + >>>> +maintainers: >>>> + - Clément LE GOFFIC <clement.legoffic@foss.st.com> >>>> + >>>> +description: | >>> >>> >>> Do not need '|' unless you need to preserve formatting. >> >> Ok >> >>>> + STMicroelectronics's STM32 MPUs integrate a Hardware Debug Port (HDP). >>>> + It allows to output internal signals on SoC's GPIO. >>>> + >>>> +properties: >>>> + compatible: >>>> + const: st,stm32mp-hdp >>> >>> There is a mess in STM SoCs. Sometimes you call SoC stm32, sometimes >>> stm32mp and sometimes stm32mpXX. >>> >>> Define for all your STM contributions what is the actual SoC. This >>> feedback was already given to ST. >>> >>>> + >>>> + reg: >>>> + maxItems: 1 >>>> + >>>> + clocks: >>>> + maxItems: 1 >>>> + >>>> +patternProperties: >>>> + '-pins$': >>>> + type: object >>>> + $ref: pinmux-node.yaml# >>>> + >>>> + properties: >>>> + function: >>>> + enum: [ "0", "1", "2", "3", "4", "5", "6", "7", >>>> + "8", "9", "10", "11", "12", "13", "14", >>>> + "15" ] >>> >>> Function which has a number is not really useful. What does it even express? >> >> As said in my previous answer, function names are very different from >> one platform to another. Numbers were used as string to be generic. >> I'll consider it in a V2. > > What does it mean "one platform to another"? This is one platform! Is > this some sort of continuation of SoC compatible mess? I may used incorrectly the word platform. This driver is the same for the three SoC families STM32MP13, STM32MP15 and STM32MP25 because the hardware is mostly the same. Why mostly ? The peripheral is behaving as a mux, there are 8 HDP ports, for each port there is up to 16 possible hardware signals. Numbered from 0 to 15. Each of this number represent a signal on the port. But the hardware signal behind the number is not the same from one SoC family to another. As example, in STM32MP15 family the HDP is able to output GPU hardware signals because the family has a GPU but in the STM32MP13 family this signal is not present. The purpose of my helpers was to give a readable name to facilitate the configuration in boards devicetree's. If needed I can get rid of that and use only the number as string. > What are the exact functions written in datasheet? The exact functions name written in the datasheet are the ones of my helper file without the HDP prefix. > Best regards, > Krzysztof
On 26/02/2025 11:52, Clement LE GOFFIC wrote: > On 2/26/25 08:21, Krzysztof Kozlowski wrote: >> On 25/02/2025 16:51, Clement LE GOFFIC wrote: >>> On 2/25/25 14:04, Krzysztof Kozlowski wrote: >>>> On 25/02/2025 09:48, Clément Le Goffic wrote: >>>>> + >>>>> +maintainers: >>>>> + - Clément LE GOFFIC <clement.legoffic@foss.st.com> >>>>> + >>>>> +description: | >>>> >>>> >>>> Do not need '|' unless you need to preserve formatting. >>> >>> Ok >>> >>>>> + STMicroelectronics's STM32 MPUs integrate a Hardware Debug Port (HDP). >>>>> + It allows to output internal signals on SoC's GPIO. >>>>> + >>>>> +properties: >>>>> + compatible: >>>>> + const: st,stm32mp-hdp >>>> >>>> There is a mess in STM SoCs. Sometimes you call SoC stm32, sometimes >>>> stm32mp and sometimes stm32mpXX. >>>> >>>> Define for all your STM contributions what is the actual SoC. This >>>> feedback was already given to ST. >>>> >>>>> + >>>>> + reg: >>>>> + maxItems: 1 >>>>> + >>>>> + clocks: >>>>> + maxItems: 1 >>>>> + >>>>> +patternProperties: >>>>> + '-pins$': >>>>> + type: object >>>>> + $ref: pinmux-node.yaml# >>>>> + >>>>> + properties: >>>>> + function: >>>>> + enum: [ "0", "1", "2", "3", "4", "5", "6", "7", >>>>> + "8", "9", "10", "11", "12", "13", "14", >>>>> + "15" ] >>>> >>>> Function which has a number is not really useful. What does it even express? >>> >>> As said in my previous answer, function names are very different from >>> one platform to another. Numbers were used as string to be generic. >>> I'll consider it in a V2. >> >> What does it mean "one platform to another"? This is one platform! Is >> this some sort of continuation of SoC compatible mess? > > I may used incorrectly the word platform. > This driver is the same for the three SoC families STM32MP13, STM32MP15 That's driver and it is fine, but we talk about hardware here. The binding is for given specific hardware. > and STM32MP25 because the hardware is mostly the same. > > Why mostly ? > > The peripheral is behaving as a mux, there are 8 HDP ports, for each > port there is up to 16 possible hardware signals. Numbered from 0 to 15. > Each of this number represent a signal on the port. > > But the hardware signal behind the number is not the same from one SoC > family to another. > As example, in STM32MP15 family the HDP is able to output GPU hardware > signals because the family has a GPU but in the STM32MP13 family this > signal is not present. It looks like you have clear mapping between function and port number (your header also suggests that), so the function property should follow that user-visible function. Just like we do for many other architectures - it is not that very, very different, I think. all of platform hardwares do not operate on strings but some bits in registers (so numbers) but all (ideally) bindings operate on strings. You created here exception on basis this is somehow special, but the point is: it is not special. > > The purpose of my helpers was to give a readable name to facilitate the > configuration in boards devicetree's. If needed I can get rid of that > and use only the number as string. If you use "names" you do not need even that helper header. > >> What are the exact functions written in datasheet? > > The exact functions name written in the datasheet are the ones of my > helper file without the HDP prefix. so full strings "pwr_pwrwake_sys" and these should be used. Best regards, Krzysztof
On 2/26/25 16:05, Krzysztof Kozlowski wrote: > On 26/02/2025 11:52, Clement LE GOFFIC wrote: >> On 2/26/25 08:21, Krzysztof Kozlowski wrote: >>> On 25/02/2025 16:51, Clement LE GOFFIC wrote: >>>> On 2/25/25 14:04, Krzysztof Kozlowski wrote: >>>>> On 25/02/2025 09:48, Clément Le Goffic wrote: >>>>>> + >>>>>> +maintainers: >>>>>> + - Clément LE GOFFIC <clement.legoffic@foss.st.com> >>>>>> + >>>>>> +description: | >>>>> >>>>> >>>>> Do not need '|' unless you need to preserve formatting. >>>> >>>> Ok >>>> >>>>>> + STMicroelectronics's STM32 MPUs integrate a Hardware Debug Port (HDP). >>>>>> + It allows to output internal signals on SoC's GPIO. >>>>>> + >>>>>> +properties: >>>>>> + compatible: >>>>>> + const: st,stm32mp-hdp >>>>> >>>>> There is a mess in STM SoCs. Sometimes you call SoC stm32, sometimes >>>>> stm32mp and sometimes stm32mpXX. >>>>> >>>>> Define for all your STM contributions what is the actual SoC. This >>>>> feedback was already given to ST. >>>>> >>>>>> + >>>>>> + reg: >>>>>> + maxItems: 1 >>>>>> + >>>>>> + clocks: >>>>>> + maxItems: 1 >>>>>> + >>>>>> +patternProperties: >>>>>> + '-pins$': >>>>>> + type: object >>>>>> + $ref: pinmux-node.yaml# >>>>>> + >>>>>> + properties: >>>>>> + function: >>>>>> + enum: [ "0", "1", "2", "3", "4", "5", "6", "7", >>>>>> + "8", "9", "10", "11", "12", "13", "14", >>>>>> + "15" ] >>>>> >>>>> Function which has a number is not really useful. What does it even express? >>>> >>>> As said in my previous answer, function names are very different from >>>> one platform to another. Numbers were used as string to be generic. >>>> I'll consider it in a V2. >>> >>> What does it mean "one platform to another"? This is one platform! Is >>> this some sort of continuation of SoC compatible mess? >> >> I may used incorrectly the word platform. >> This driver is the same for the three SoC families STM32MP13, STM32MP15 > > That's driver and it is fine, but we talk about hardware here. The > binding is for given specific hardware. > >> and STM32MP25 because the hardware is mostly the same. >> >> Why mostly ? >> >> The peripheral is behaving as a mux, there are 8 HDP ports, for each >> port there is up to 16 possible hardware signals. Numbered from 0 to 15. >> Each of this number represent a signal on the port. >> >> But the hardware signal behind the number is not the same from one SoC >> family to another. >> As example, in STM32MP15 family the HDP is able to output GPU hardware >> signals because the family has a GPU but in the STM32MP13 family this >> signal is not present. > > It looks like you have clear mapping between function and port number > (your header also suggests that), so the function property should follow > that user-visible function. > > Just like we do for many other architectures - it is not that very, very > different, I think. all of platform hardwares do not operate on strings > but some bits in registers (so numbers) but all (ideally) bindings > operate on strings. You created here exception on basis this is somehow > special, but the point is: it is not special. > >> >> The purpose of my helpers was to give a readable name to facilitate the >> configuration in boards devicetree's. If needed I can get rid of that >> and use only the number as string. > > If you use "names" you do not need even that helper header. > >> >>> What are the exact functions written in datasheet? >> >> The exact functions name written in the datasheet are the ones of my >> helper file without the HDP prefix. > > so full strings "pwr_pwrwake_sys" and these should be used. Ok so in the V2, I'll keep the 'function' property of the pinmux and use signal names such as 'pwr_pwrwake_sys' to select signals in the DT. The signal names are different from one SoC to another (stm32mp131, stm32mp151 and stm32mp251) so I'll need compatible data and the compatibles will be: MP15: compatible = "st,stm32mp151-hdp"; MP13: compatible = "st,stm32mp131-hdp"; MP25: compatible = "st,stm32mp251-hdp"; > Best regards, > Krzysztof
diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl-hdp.yaml b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl-hdp.yaml new file mode 100644 index 000000000000..b6787162faaa --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl-hdp.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) STMicroelectronics 2025. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/st,stm32-pinctrl-hdp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STM32 Hardware Debug Port Mux/Config + +maintainers: + - Clément LE GOFFIC <clement.legoffic@foss.st.com> + +description: | + STMicroelectronics's STM32 MPUs integrate a Hardware Debug Port (HDP). + It allows to output internal signals on SoC's GPIO. + +properties: + compatible: + const: st,stm32mp-hdp + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + +patternProperties: + '-pins$': + type: object + $ref: pinmux-node.yaml# + + properties: + function: + enum: [ "0", "1", "2", "3", "4", "5", "6", "7", + "8", "9", "10", "11", "12", "13", "14", + "15" ] + + pins: + enum: [ hdp0, hdp1, hdp2, hdp3, hdp4, hdp5, hdp6, hdp7 ] + + required: + - function + - pins + + additionalProperties: false + +allOf: + - $ref: pinctrl.yaml# + +required: + - compatible + - reg + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/stm32mp1-clks.h> + #include <dt-bindings/pinctrl/stm32mp15-hdp.h> + //Example 1 + pinctrl@54090000 { + compatible = "st,stm32mp-hdp"; + reg = <0x54090000 0x400>; + clocks = <&rcc HDP>; + pinctrl-names = "default"; + pinctrl-0 = <&hdp2>; + hdp2-pins { + function = HDP2_GPOVAL_2; + pins = "hdp2"; + }; + };
Introduce dt-bindings for HDP driver. 'HDP' stands for Hardware Debug Port, it is an hardware block in STMicrolectronics' MPUs that let the user decide which internal SoC's signal to observe. It provides 8 ports and for each port there is up to 16 different signals that can be output. Signals are different for each MPU. Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com> --- .../bindings/pinctrl/st,stm32-pinctrl-hdp.yaml | 72 ++++++++++++++++++++++ 1 file changed, 72 insertions(+)