Add the hdp devicetree node for stm32mp13 SoC family

Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
---
 arch/arm/boot/dts/st/stm32mp131.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/st/stm32mp131.dtsi b/arch/arm/boot/dts/st/stm32mp131.dtsi
index 8512a6e46b33..b0537bcdb9d5 100644
--- a/arch/arm/boot/dts/st/stm32mp131.dtsi
+++ b/arch/arm/boot/dts/st/stm32mp131.dtsi
@@ -951,6 +951,12 @@ dts: thermal@50028000 {
 			clocks = <&rcc DTS>;
 			clock-names = "pclk";
 			#thermal-sensor-cells = <0>;
+		};
+
+		hdp: pinctrl@5002a000 {
+			compatible = "st,stm32mp131-hdp";
+			reg = <0x5002a000 0x400>;
+			clocks = <&rcc HDP>;
 			status = "disabled";
 		};
 

-- 
2.43.0

On 23/05/2025 14:38, Clément Le Goffic wrote:
> Add the hdp devicetree node for stm32mp13 SoC family
> 
> Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
> ---
>  arch/arm/boot/dts/st/stm32mp131.dtsi | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/st/stm32mp131.dtsi b/arch/arm/boot/dts/st/stm32mp131.dtsi
> index 8512a6e46b33..b0537bcdb9d5 100644
> --- a/arch/arm/boot/dts/st/stm32mp131.dtsi
> +++ b/arch/arm/boot/dts/st/stm32mp131.dtsi
> @@ -951,6 +951,12 @@ dts: thermal@50028000 {
>  			clocks = <&rcc DTS>;
>  			clock-names = "pclk";
>  			#thermal-sensor-cells = <0>;

Why are you enabling it? Commit msg should explain this and this should
be sparate patch.

> +		};
> +
> +		hdp: pinctrl@5002a000 {
> +			compatible = "st,stm32mp131-hdp";
> +			reg = <0x5002a000 0x400>;
> +			clocks = <&rcc HDP>;
>  			status = "disabled";

Why are you disabling it? What is missing?

>  		};
>  
> 


Best regards,
Krzysztof

On 5/28/25 10:55, Krzysztof Kozlowski wrote:
> On 23/05/2025 14:38, Clément Le Goffic wrote:
>> Add the hdp devicetree node for stm32mp13 SoC family
>>
>> Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
>> ---
>>   arch/arm/boot/dts/st/stm32mp131.dtsi | 6 ++++++
>>   1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/st/stm32mp131.dtsi b/arch/arm/boot/dts/st/stm32mp131.dtsi
>> index 8512a6e46b33..b0537bcdb9d5 100644
>> --- a/arch/arm/boot/dts/st/stm32mp131.dtsi
>> +++ b/arch/arm/boot/dts/st/stm32mp131.dtsi
>> @@ -951,6 +951,12 @@ dts: thermal@50028000 {
>>   			clocks = <&rcc DTS>;
>>   			clock-names = "pclk";
>>   			#thermal-sensor-cells = <0>;
> 
> Why are you enabling it? Commit msg should explain this and this should
> be sparate patch.

Oops good catch I'll fix this.

> 
>> +		};
>> +
>> +		hdp: pinctrl@5002a000 {
>> +			compatible = "st,stm32mp131-hdp";
>> +			reg = <0x5002a000 0x400>;
>> +			clocks = <&rcc HDP>;
>>   			status = "disabled";
> 
> Why are you disabling it? What is missing?

Nothing is missing just disabled by default.
The node is then enabled when needed in board's dts file.

> 
>>   		};
>>   
>>
> 
> 
> Best regards,
> Krzysztof

Clément

On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>
>>> +		};
>>> +
>>> +		hdp: pinctrl@5002a000 {
>>> +			compatible = "st,stm32mp131-hdp";
>>> +			reg = <0x5002a000 0x400>;
>>> +			clocks = <&rcc HDP>;
>>>   			status = "disabled";
>>
>> Why are you disabling it? What is missing?
> 
> Nothing is missing just disabled by default.
> The node is then enabled when needed in board's dts file.
> 
How much time did you give me to respond to this feedback? 1 hour 15
minutes. That's too short. We have also other work except constantly
checking inbox.

Best regards,
Krzysztof

On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>
>>> +		};
>>> +
>>> +		hdp: pinctrl@5002a000 {
>>> +			compatible = "st,stm32mp131-hdp";
>>> +			reg = <0x5002a000 0x400>;
>>> +			clocks = <&rcc HDP>;
>>>   			status = "disabled";
>>
>> Why are you disabling it? What is missing?
> 
> Nothing is missing just disabled by default.
> The node is then enabled when needed in board's dts file.
Nodes should not be disabled by default if they are complete. That's why
I asked what is missing. Drop.

Best regards,
Krzysztof

On 5/29/25 11:01, Krzysztof Kozlowski wrote:
> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>
>>>> +		};
>>>> +
>>>> +		hdp: pinctrl@5002a000 {
>>>> +			compatible = "st,stm32mp131-hdp";
>>>> +			reg = <0x5002a000 0x400>;
>>>> +			clocks = <&rcc HDP>;
>>>>    			status = "disabled";
>>>
>>> Why are you disabling it? What is missing?
>>
>> Nothing is missing just disabled by default.
>> The node is then enabled when needed in board's dts file.
> Nodes should not be disabled by default if they are complete. That's why
> I asked what is missing. Drop.

Hi Krzysztof, OK I better understand now.
So yes the 'pinctrl-*' properties which are board dependent are lacking.

In the last patch of my serie I add them (only for stm32mp157f-dk2) but 
keep it disabled because the pin is on an external connector (the 
Arduino connector of the board).
This prevent any issue with a possible connected module.

> Best regards,
> Krzysztof

On 10/06/2025 14:02, Clement LE GOFFIC wrote:
> On 5/29/25 11:01, Krzysztof Kozlowski wrote:
>> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>>
>>>>> +		};
>>>>> +
>>>>> +		hdp: pinctrl@5002a000 {
>>>>> +			compatible = "st,stm32mp131-hdp";
>>>>> +			reg = <0x5002a000 0x400>;
>>>>> +			clocks = <&rcc HDP>;
>>>>>    			status = "disabled";
>>>>
>>>> Why are you disabling it? What is missing?
>>>
>>> Nothing is missing just disabled by default.
>>> The node is then enabled when needed in board's dts file.
>> Nodes should not be disabled by default if they are complete. That's why
>> I asked what is missing. Drop.
> 
> Hi Krzysztof, OK I better understand now.
> So yes the 'pinctrl-*' properties which are board dependent are lacking.

These are not properties of this node.

> 
> In the last patch of my serie I add them (only for stm32mp157f-dk2) but 
> keep it disabled because the pin is on an external connector (the 
> Arduino connector of the board).
> This prevent any issue with a possible connected module.

Not relevant. Pin control for connector are board specific, but pinctrl
SoC part is SoC.

Best regards,
Krzysztof

On 6/10/25 14:38, Krzysztof Kozlowski wrote:
> On 10/06/2025 14:02, Clement LE GOFFIC wrote:
>> On 5/29/25 11:01, Krzysztof Kozlowski wrote:
>>> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>>>
>>>>>> +		};
>>>>>> +
>>>>>> +		hdp: pinctrl@5002a000 {
>>>>>> +			compatible = "st,stm32mp131-hdp";
>>>>>> +			reg = <0x5002a000 0x400>;
>>>>>> +			clocks = <&rcc HDP>;
>>>>>>     			status = "disabled";
>>>>>
>>>>> Why are you disabling it? What is missing?
>>>>
>>>> Nothing is missing just disabled by default.
>>>> The node is then enabled when needed in board's dts file.
>>> Nodes should not be disabled by default if they are complete. That's why
>>> I asked what is missing. Drop.
>>
>> Hi Krzysztof, OK I better understand now.
>> So yes the 'pinctrl-*' properties which are board dependent are lacking.
> 
> These are not properties of this node.

Does this mean I should add 'pinctrl-*' properties in bindings yaml file ?
I don't get it..

>>
>> In the last patch of my serie I add them (only for stm32mp157f-dk2) but
>> keep it disabled because the pin is on an external connector (the
>> Arduino connector of the board).
>> This prevent any issue with a possible connected module.
> 
> Not relevant. Pin control for connector are board specific, but pinctrl
> SoC part is SoC.

I think we don't understand each other here too. I don't understand the 
end of your sentence "pinctrl SoC part is SoC".

Maybe some informations that could help:
The 'pinctrl-*' properties are used in the HDP case to select the 
internal signal to output AND the alternate function on the pin to 
output the HDP function.

> Best regards,
> Krzysztof

On 10/06/2025 15:33, Clement LE GOFFIC wrote:
> On 6/10/25 14:38, Krzysztof Kozlowski wrote:
>> On 10/06/2025 14:02, Clement LE GOFFIC wrote:
>>> On 5/29/25 11:01, Krzysztof Kozlowski wrote:
>>>> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>>>>
>>>>>>> +		};
>>>>>>> +
>>>>>>> +		hdp: pinctrl@5002a000 {
>>>>>>> +			compatible = "st,stm32mp131-hdp";
>>>>>>> +			reg = <0x5002a000 0x400>;
>>>>>>> +			clocks = <&rcc HDP>;
>>>>>>>     			status = "disabled";
>>>>>>
>>>>>> Why are you disabling it? What is missing?
>>>>>
>>>>> Nothing is missing just disabled by default.
>>>>> The node is then enabled when needed in board's dts file.
>>>> Nodes should not be disabled by default if they are complete. That's why
>>>> I asked what is missing. Drop.
>>>
>>> Hi Krzysztof, OK I better understand now.
>>> So yes the 'pinctrl-*' properties which are board dependent are lacking.
>>
>> These are not properties of this node.
> 
> Does this mean I should add 'pinctrl-*' properties in bindings yaml file ?
> I don't get it..

These properties have no meaning here, so the hardware description is
complete. You claim that you miss them thus device is incomplete is just
not correct: these properties do not belong here! They belong to the
board but even there they are totally optional. Why would they be a
required resource?

To remind: we talk here ONLY about required resources.

> 
>>>
>>> In the last patch of my serie I add them (only for stm32mp157f-dk2) but
>>> keep it disabled because the pin is on an external connector (the
>>> Arduino connector of the board).
>>> This prevent any issue with a possible connected module.
>>
>> Not relevant. Pin control for connector are board specific, but pinctrl
>> SoC part is SoC.
> 
> I think we don't understand each other here too. I don't understand the 
> end of your sentence "pinctrl SoC part is SoC".

Please read first how DTS is organized.

The pin controller device is part of SoC not part of a board.

Pins configuration for devices on the board are not part of the SoC.
What is not clear here? We talk here in terms how DTS is supposed to be
organized.

> 
> Maybe some informations that could help:
> The 'pinctrl-*' properties are used in the HDP case to select the 
> internal signal to output AND the alternate function on the pin to 
> output the HDP function.

We all know this.

> 
>> Best regards,
>> Krzysztof
> 


Best regards,
Krzysztof

On 6/11/25 08:35, Krzysztof Kozlowski wrote:
> On 10/06/2025 15:33, Clement LE GOFFIC wrote:
>> On 6/10/25 14:38, Krzysztof Kozlowski wrote:
>>> On 10/06/2025 14:02, Clement LE GOFFIC wrote:
>>>> On 5/29/25 11:01, Krzysztof Kozlowski wrote:
>>>>> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>>>>>
>>>>>>>> +		};
>>>>>>>> +
>>>>>>>> +		hdp: pinctrl@5002a000 {
>>>>>>>> +			compatible = "st,stm32mp131-hdp";
>>>>>>>> +			reg = <0x5002a000 0x400>;
>>>>>>>> +			clocks = <&rcc HDP>;
>>>>>>>>      			status = "disabled";
>>>>>>>
>>>>>>> Why are you disabling it? What is missing?
>>>>>>
>>>>>> Nothing is missing just disabled by default.
>>>>>> The node is then enabled when needed in board's dts file.
>>>>> Nodes should not be disabled by default if they are complete. That's why
>>>>> I asked what is missing. Drop.
>>>>
>>>> Hi Krzysztof, OK I better understand now.
>>>> So yes the 'pinctrl-*' properties which are board dependent are lacking.
>>>
>>> These are not properties of this node.
>>
>> Does this mean I should add 'pinctrl-*' properties in bindings yaml file ?
>> I don't get it..
> 
> These properties have no meaning here, so the hardware description is
> complete. You claim that you miss them thus device is incomplete is just
> not correct: these properties do not belong here! They belong to the
> board but even there they are totally optional. Why would they be a
> required resource?
> 
> To remind: we talk here ONLY about required resources.

Yes, 'pinctrl-*' properties belongs to the board and are not required.
So nothing is missing.

This hdp node in the SoC dtsi file can be enabled by default.
But the hdp driver will probe and do nothing because without the 
'pinctrl-*' properties from the board files it would not be able to 
access to any pin.
I consider enabling this driver by default in SoC dtsi file as just 
increasing the boot time on "every" board.
It's the board dts that requires the hdp and provides the 'pinctrl-*' 
properties to connect the hdp to some SoC pin and then to some signal on 
the board. For me it's natural to have the status okay only in the board 
dts file.

>>
>>>>
>>>> In the last patch of my serie I add them (only for stm32mp157f-dk2) but
>>>> keep it disabled because the pin is on an external connector (the
>>>> Arduino connector of the board).
>>>> This prevent any issue with a possible connected module.
>>>
>>> Not relevant. Pin control for connector are board specific, but pinctrl
>>> SoC part is SoC.
>>
>> I think we don't understand each other here too. I don't understand the
>> end of your sentence "pinctrl SoC part is SoC".
> 
> Please read first how DTS is organized.
> 
> The pin controller device is part of SoC not part of a board.
> 
> Pins configuration for devices on the board are not part of the SoC.
> What is not clear here? We talk here in terms how DTS is supposed to be
> organized.

Now everything is clear, you want me to just set status enable in soc 
dtsi file but I disagree, keep discussing.

> 
>>
>> Maybe some informations that could help:
>> The 'pinctrl-*' properties are used in the HDP case to select the
>> internal signal to output AND the alternate function on the pin to
>> output the HDP function.
> 
> We all know this.

Ok fine

Best regards,

Clément

> 
>>
>>> Best regards,
>>> Krzysztof
>>
> 
> 
> Best regards,
> Krzysztof

On 11/06/2025 16:08, Clement LE GOFFIC wrote:
> On 6/11/25 08:35, Krzysztof Kozlowski wrote:
>> On 10/06/2025 15:33, Clement LE GOFFIC wrote:
>>> On 6/10/25 14:38, Krzysztof Kozlowski wrote:
>>>> On 10/06/2025 14:02, Clement LE GOFFIC wrote:
>>>>> On 5/29/25 11:01, Krzysztof Kozlowski wrote:
>>>>>> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>>>>>>
>>>>>>>>> +		};
>>>>>>>>> +
>>>>>>>>> +		hdp: pinctrl@5002a000 {
>>>>>>>>> +			compatible = "st,stm32mp131-hdp";
>>>>>>>>> +			reg = <0x5002a000 0x400>;
>>>>>>>>> +			clocks = <&rcc HDP>;
>>>>>>>>>      			status = "disabled";
>>>>>>>>
>>>>>>>> Why are you disabling it? What is missing?
>>>>>>>
>>>>>>> Nothing is missing just disabled by default.
>>>>>>> The node is then enabled when needed in board's dts file.
>>>>>> Nodes should not be disabled by default if they are complete. That's why
>>>>>> I asked what is missing. Drop.
>>>>>
>>>>> Hi Krzysztof, OK I better understand now.
>>>>> So yes the 'pinctrl-*' properties which are board dependent are lacking.
>>>>
>>>> These are not properties of this node.
>>>
>>> Does this mean I should add 'pinctrl-*' properties in bindings yaml file ?
>>> I don't get it..
>>
>> These properties have no meaning here, so the hardware description is
>> complete. You claim that you miss them thus device is incomplete is just
>> not correct: these properties do not belong here! They belong to the
>> board but even there they are totally optional. Why would they be a
>> required resource?
>>
>> To remind: we talk here ONLY about required resources.
> 
> Yes, 'pinctrl-*' properties belongs to the board and are not required.
> So nothing is missing.
> 
> This hdp node in the SoC dtsi file can be enabled by default.
> But the hdp driver will probe and do nothing because without the 
> 'pinctrl-*' properties from the board files it would not be able to 
> access to any pin.


Pinctrl has other features in general, including interfaces to userspace
(as pretty often combined with gpio, although not sure if relevant here).

> I consider enabling this driver by default in SoC dtsi file as just 
> increasing the boot time on "every" board.
> It's the board dts that requires the hdp and provides the 'pinctrl-*' 
> properties to connect the hdp to some SoC pin and then to some signal on 
> the board. For me it's natural to have the status okay only in the board 
> dts file.

The DTS is not the way to optimize boot processes. It is OS-independent
hardware description. My BSD system for example uses smart driver which
avoids probing, but also my user-space needs this device to talk over
exposed interface, so why choice of Linux probing should affect others?

Best regards,
Krzysztof

On 6/11/25 17:48, Krzysztof Kozlowski wrote:
> On 11/06/2025 16:08, Clement LE GOFFIC wrote:
>> On 6/11/25 08:35, Krzysztof Kozlowski wrote:
>>> On 10/06/2025 15:33, Clement LE GOFFIC wrote:
>>>> On 6/10/25 14:38, Krzysztof Kozlowski wrote:
>>>>> On 10/06/2025 14:02, Clement LE GOFFIC wrote:
>>>>>> On 5/29/25 11:01, Krzysztof Kozlowski wrote:
>>>>>>> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>>>>>>>
>>>>>>>>>> +		};
>>>>>>>>>> +
>>>>>>>>>> +		hdp: pinctrl@5002a000 {
>>>>>>>>>> +			compatible = "st,stm32mp131-hdp";
>>>>>>>>>> +			reg = <0x5002a000 0x400>;
>>>>>>>>>> +			clocks = <&rcc HDP>;
>>>>>>>>>>       			status = "disabled";
>>>>>>>>>
>>>>>>>>> Why are you disabling it? What is missing?
>>>>>>>>
>>>>>>>> Nothing is missing just disabled by default.
>>>>>>>> The node is then enabled when needed in board's dts file.
>>>>>>> Nodes should not be disabled by default if they are complete. That's why
>>>>>>> I asked what is missing. Drop.
>>>>>>
>>>>>> Hi Krzysztof, OK I better understand now.
>>>>>> So yes the 'pinctrl-*' properties which are board dependent are lacking.
>>>>>
>>>>> These are not properties of this node.
>>>>
>>>> Does this mean I should add 'pinctrl-*' properties in bindings yaml file ?
>>>> I don't get it..
>>>
>>> These properties have no meaning here, so the hardware description is
>>> complete. You claim that you miss them thus device is incomplete is just
>>> not correct: these properties do not belong here! They belong to the
>>> board but even there they are totally optional. Why would they be a
>>> required resource?
>>>
>>> To remind: we talk here ONLY about required resources.
>>
>> Yes, 'pinctrl-*' properties belongs to the board and are not required.
>> So nothing is missing.
>>
>> This hdp node in the SoC dtsi file can be enabled by default.
>> But the hdp driver will probe and do nothing because without the
>> 'pinctrl-*' properties from the board files it would not be able to
>> access to any pin.
> 
> 
> Pinctrl has other features in general, including interfaces to userspace
> (as pretty often combined with gpio, although not sure if relevant here).

You're right. Also HDP pinctrl has a GPO feature accessible from userspace.
But by default the HDP is not connected to any pad; it needs the board 
'pinctrl-*' properties to configure the SoC pinctrl and expose HDP on 
the SoC pads.

That's why for me the enabling of the driver should be in the board file 
together with the SoC pinctrl configuration.

The userland cannot change the pinctrl alternate function mux, this is 
statically defined by the devicetree.

> 
>> I consider enabling this driver by default in SoC dtsi file as just
>> increasing the boot time on "every" board.
>> It's the board dts that requires the hdp and provides the 'pinctrl-*'
>> properties to connect the hdp to some SoC pin and then to some signal on
>> the board. For me it's natural to have the status okay only in the board
>> dts file.
> 
> The DTS is not the way to optimize boot processes. It is OS-independent
> hardware description. My BSD system for example uses smart driver which
> avoids probing, but also my user-space needs this device to talk over
> exposed interface, so why choice of Linux probing should affect others?

As I wrote above the HDP will not offer any functionality without the 
'pinctrl-*' properties in the board file.
If you insist, I can enable it in the SoC file but I really don't see 
any reason for that.

Best regards, Clément

> 
> Best regards,
> Krzysztof

On 12/06/2025 11:31, Clement LE GOFFIC wrote:
> On 6/11/25 17:48, Krzysztof Kozlowski wrote:
>> On 11/06/2025 16:08, Clement LE GOFFIC wrote:
>>> On 6/11/25 08:35, Krzysztof Kozlowski wrote:
>>>> On 10/06/2025 15:33, Clement LE GOFFIC wrote:
>>>>> On 6/10/25 14:38, Krzysztof Kozlowski wrote:
>>>>>> On 10/06/2025 14:02, Clement LE GOFFIC wrote:
>>>>>>> On 5/29/25 11:01, Krzysztof Kozlowski wrote:
>>>>>>>> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>>>>>>>>
>>>>>>>>>>> +		};
>>>>>>>>>>> +
>>>>>>>>>>> +		hdp: pinctrl@5002a000 {
>>>>>>>>>>> +			compatible = "st,stm32mp131-hdp";
>>>>>>>>>>> +			reg = <0x5002a000 0x400>;
>>>>>>>>>>> +			clocks = <&rcc HDP>;
>>>>>>>>>>>       			status = "disabled";
>>>>>>>>>>
>>>>>>>>>> Why are you disabling it? What is missing?
>>>>>>>>>
>>>>>>>>> Nothing is missing just disabled by default.
>>>>>>>>> The node is then enabled when needed in board's dts file.
>>>>>>>> Nodes should not be disabled by default if they are complete. That's why
>>>>>>>> I asked what is missing. Drop.
>>>>>>>
>>>>>>> Hi Krzysztof, OK I better understand now.
>>>>>>> So yes the 'pinctrl-*' properties which are board dependent are lacking.
>>>>>>
>>>>>> These are not properties of this node.
>>>>>
>>>>> Does this mean I should add 'pinctrl-*' properties in bindings yaml file ?
>>>>> I don't get it..
>>>>
>>>> These properties have no meaning here, so the hardware description is
>>>> complete. You claim that you miss them thus device is incomplete is just
>>>> not correct: these properties do not belong here! They belong to the
>>>> board but even there they are totally optional. Why would they be a
>>>> required resource?
>>>>
>>>> To remind: we talk here ONLY about required resources.
>>>
>>> Yes, 'pinctrl-*' properties belongs to the board and are not required.
>>> So nothing is missing.
>>>
>>> This hdp node in the SoC dtsi file can be enabled by default.
>>> But the hdp driver will probe and do nothing because without the
>>> 'pinctrl-*' properties from the board files it would not be able to
>>> access to any pin.
>>
>>
>> Pinctrl has other features in general, including interfaces to userspace
>> (as pretty often combined with gpio, although not sure if relevant here).
> 
> You're right. Also HDP pinctrl has a GPO feature accessible from userspace.
> But by default the HDP is not connected to any pad; it needs the board 

OK, then that was the answer to my first question - what is missing.
However aren't these pads connected internally also to other parts of
the SoC (like in most other vendors)?

> 'pinctrl-*' properties to configure the SoC pinctrl and expose HDP on 
> the SoC pads.
> 
> That's why for me the enabling of the driver should be in the board file 
> together with the SoC pinctrl configuration.

And what are the default pad settings configured by HPD driver in
bootloader (and by bootloader I mean one of few bootloaders this is
going to be used on like U-Boot)

> 
> The userland cannot change the pinctrl alternate function mux, this is 
> statically defined by the devicetree.

If you expose GPIO then userland needs this regardless of alternate mux.
IOW, board level could not configure mux because it should be always
configured to safe GPIO input.

Best regards,
Krzysztof

On 6/12/25 13:05, Krzysztof Kozlowski wrote:
> On 12/06/2025 11:31, Clement LE GOFFIC wrote:
>> On 6/11/25 17:48, Krzysztof Kozlowski wrote:
>>> On 11/06/2025 16:08, Clement LE GOFFIC wrote:
>>>> On 6/11/25 08:35, Krzysztof Kozlowski wrote:
>>>>> On 10/06/2025 15:33, Clement LE GOFFIC wrote:
>>>>>> On 6/10/25 14:38, Krzysztof Kozlowski wrote:
>>>>>>> On 10/06/2025 14:02, Clement LE GOFFIC wrote:
>>>>>>>> On 5/29/25 11:01, Krzysztof Kozlowski wrote:
>>>>>>>>> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>>>>>>>>>
>>>>>>>>>>>> +		};
>>>>>>>>>>>> +
>>>>>>>>>>>> +		hdp: pinctrl@5002a000 {
>>>>>>>>>>>> +			compatible = "st,stm32mp131-hdp";
>>>>>>>>>>>> +			reg = <0x5002a000 0x400>;
>>>>>>>>>>>> +			clocks = <&rcc HDP>;
>>>>>>>>>>>>        			status = "disabled";
>>>>>>>>>>>
>>>>>>>>>>> Why are you disabling it? What is missing?
>>>>>>>>>>
>>>>>>>>>> Nothing is missing just disabled by default.
>>>>>>>>>> The node is then enabled when needed in board's dts file.
>>>>>>>>> Nodes should not be disabled by default if they are complete. That's why
>>>>>>>>> I asked what is missing. Drop.
>>>>>>>>
>>>>>>>> Hi Krzysztof, OK I better understand now.
>>>>>>>> So yes the 'pinctrl-*' properties which are board dependent are lacking.
>>>>>>>
>>>>>>> These are not properties of this node.
>>>>>>
>>>>>> Does this mean I should add 'pinctrl-*' properties in bindings yaml file ?
>>>>>> I don't get it..
>>>>>
>>>>> These properties have no meaning here, so the hardware description is
>>>>> complete. You claim that you miss them thus device is incomplete is just
>>>>> not correct: these properties do not belong here! They belong to the
>>>>> board but even there they are totally optional. Why would they be a
>>>>> required resource?
>>>>>
>>>>> To remind: we talk here ONLY about required resources.
>>>>
>>>> Yes, 'pinctrl-*' properties belongs to the board and are not required.
>>>> So nothing is missing.
>>>>
>>>> This hdp node in the SoC dtsi file can be enabled by default.
>>>> But the hdp driver will probe and do nothing because without the
>>>> 'pinctrl-*' properties from the board files it would not be able to
>>>> access to any pin.
>>>
>>>
>>> Pinctrl has other features in general, including interfaces to userspace
>>> (as pretty often combined with gpio, although not sure if relevant here).
>>
>> You're right. Also HDP pinctrl has a GPO feature accessible from userspace.
>> But by default the HDP is not connected to any pad; it needs the board
> 
> OK, then that was the answer to my first question - what is missing.
> However aren't these pads connected internally also to other parts of
> the SoC (like in most other vendors)?

No, HDP "output pads" are only connected to SoC pinctrl to route outside 
the internal SoC signals for debug purpose.

>> 'pinctrl-*' properties to configure the SoC pinctrl and expose HDP on
>> the SoC pads.
>>
>> That's why for me the enabling of the driver should be in the board file
>> together with the SoC pinctrl configuration.
> 
> And what are the default pad settings configured by HPD driver in
> bootloader (and by bootloader I mean one of few bootloaders this is
> going to be used on like U-Boot)

The default is to use the GPIO of the SoC pinctrl. The HDP is not routed 
outside.
  >>
>> The userland cannot change the pinctrl alternate function mux, this is
>> statically defined by the devicetree.
> 
> If you expose GPIO then userland needs this regardless of alternate mux.
> IOW, board level could not configure mux because it should be always
> configured to safe GPIO input.

For userland sight view, SoC GPIO are preferred instead of HDP.
HDP is only GPO not GPIO. 'pinctrl-*' properties configure at the same 
time the SoC pinctrl mux to HDP and the HDP pinctrl mux to one of the 
HDP functions (e.g. GPO).

Best regards,
Clément

On 12/06/2025 15:02, Clement LE GOFFIC wrote:
> On 6/12/25 13:05, Krzysztof Kozlowski wrote:
>> On 12/06/2025 11:31, Clement LE GOFFIC wrote:
>>> On 6/11/25 17:48, Krzysztof Kozlowski wrote:
>>>> On 11/06/2025 16:08, Clement LE GOFFIC wrote:
>>>>> On 6/11/25 08:35, Krzysztof Kozlowski wrote:
>>>>>> On 10/06/2025 15:33, Clement LE GOFFIC wrote:
>>>>>>> On 6/10/25 14:38, Krzysztof Kozlowski wrote:
>>>>>>>> On 10/06/2025 14:02, Clement LE GOFFIC wrote:
>>>>>>>>> On 5/29/25 11:01, Krzysztof Kozlowski wrote:
>>>>>>>>>> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> +		};
>>>>>>>>>>>>> +
>>>>>>>>>>>>> +		hdp: pinctrl@5002a000 {
>>>>>>>>>>>>> +			compatible = "st,stm32mp131-hdp";
>>>>>>>>>>>>> +			reg = <0x5002a000 0x400>;
>>>>>>>>>>>>> +			clocks = <&rcc HDP>;
>>>>>>>>>>>>>        			status = "disabled";
>>>>>>>>>>>>
>>>>>>>>>>>> Why are you disabling it? What is missing?
>>>>>>>>>>>
>>>>>>>>>>> Nothing is missing just disabled by default.
>>>>>>>>>>> The node is then enabled when needed in board's dts file.
>>>>>>>>>> Nodes should not be disabled by default if they are complete. That's why
>>>>>>>>>> I asked what is missing. Drop.
>>>>>>>>>
>>>>>>>>> Hi Krzysztof, OK I better understand now.
>>>>>>>>> So yes the 'pinctrl-*' properties which are board dependent are lacking.
>>>>>>>>
>>>>>>>> These are not properties of this node.
>>>>>>>
>>>>>>> Does this mean I should add 'pinctrl-*' properties in bindings yaml file ?
>>>>>>> I don't get it..
>>>>>>
>>>>>> These properties have no meaning here, so the hardware description is
>>>>>> complete. You claim that you miss them thus device is incomplete is just
>>>>>> not correct: these properties do not belong here! They belong to the
>>>>>> board but even there they are totally optional. Why would they be a
>>>>>> required resource?
>>>>>>
>>>>>> To remind: we talk here ONLY about required resources.
>>>>>
>>>>> Yes, 'pinctrl-*' properties belongs to the board and are not required.
>>>>> So nothing is missing.
>>>>>
>>>>> This hdp node in the SoC dtsi file can be enabled by default.
>>>>> But the hdp driver will probe and do nothing because without the
>>>>> 'pinctrl-*' properties from the board files it would not be able to
>>>>> access to any pin.
>>>>
>>>>
>>>> Pinctrl has other features in general, including interfaces to userspace
>>>> (as pretty often combined with gpio, although not sure if relevant here).
>>>
>>> You're right. Also HDP pinctrl has a GPO feature accessible from userspace.
>>> But by default the HDP is not connected to any pad; it needs the board
>>
>> OK, then that was the answer to my first question - what is missing.
>> However aren't these pads connected internally also to other parts of
>> the SoC (like in most other vendors)?
> 
> No, HDP "output pads" are only connected to SoC pinctrl to route outside 
> the internal SoC signals for debug purpose.
> 
>>> 'pinctrl-*' properties to configure the SoC pinctrl and expose HDP on
>>> the SoC pads.
>>>
>>> That's why for me the enabling of the driver should be in the board file
>>> together with the SoC pinctrl configuration.
>>
>> And what are the default pad settings configured by HPD driver in
>> bootloader (and by bootloader I mean one of few bootloaders this is
>> going to be used on like U-Boot)
> 
> The default is to use the GPIO of the SoC pinctrl. The HDP is not routed 
> outside.
>   >>
>>> The userland cannot change the pinctrl alternate function mux, this is
>>> statically defined by the devicetree.
>>
>> If you expose GPIO then userland needs this regardless of alternate mux.
>> IOW, board level could not configure mux because it should be always
>> configured to safe GPIO input.
> 
> For userland sight view, SoC GPIO are preferred instead of HDP.
> HDP is only GPO not GPIO. 'pinctrl-*' properties configure at the same 
> time the SoC pinctrl mux to HDP and the HDP pinctrl mux to one of the 
> HDP functions (e.g. GPO).
Thanks, that's explains, fine to keep it disabled. Unless it is obvious
for everyone, it would be nice to put it in commit msg.

Best regards,
Krzysztof

On 6/12/25 15:09, Krzysztof Kozlowski wrote:
> On 12/06/2025 15:02, Clement LE GOFFIC wrote:
>> On 6/12/25 13:05, Krzysztof Kozlowski wrote:
>>> On 12/06/2025 11:31, Clement LE GOFFIC wrote:
>>>> On 6/11/25 17:48, Krzysztof Kozlowski wrote:
>>>>> On 11/06/2025 16:08, Clement LE GOFFIC wrote:
>>>>>> On 6/11/25 08:35, Krzysztof Kozlowski wrote:
>>>>>>> On 10/06/2025 15:33, Clement LE GOFFIC wrote:
>>>>>>>> On 6/10/25 14:38, Krzysztof Kozlowski wrote:
>>>>>>>>> On 10/06/2025 14:02, Clement LE GOFFIC wrote:
>>>>>>>>>> On 5/29/25 11:01, Krzysztof Kozlowski wrote:
>>>>>>>>>>> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> +		};
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> +		hdp: pinctrl@5002a000 {
>>>>>>>>>>>>>> +			compatible = "st,stm32mp131-hdp";
>>>>>>>>>>>>>> +			reg = <0x5002a000 0x400>;
>>>>>>>>>>>>>> +			clocks = <&rcc HDP>;
>>>>>>>>>>>>>>         			status = "disabled";
>>>>>>>>>>>>>
>>>>>>>>>>>>> Why are you disabling it? What is missing?
>>>>>>>>>>>>
>>>>>>>>>>>> Nothing is missing just disabled by default.
>>>>>>>>>>>> The node is then enabled when needed in board's dts file.
>>>>>>>>>>> Nodes should not be disabled by default if they are complete. That's why
>>>>>>>>>>> I asked what is missing. Drop.
>>>>>>>>>>
>>>>>>>>>> Hi Krzysztof, OK I better understand now.
>>>>>>>>>> So yes the 'pinctrl-*' properties which are board dependent are lacking.
>>>>>>>>>
>>>>>>>>> These are not properties of this node.
>>>>>>>>
>>>>>>>> Does this mean I should add 'pinctrl-*' properties in bindings yaml file ?
>>>>>>>> I don't get it..
>>>>>>>
>>>>>>> These properties have no meaning here, so the hardware description is
>>>>>>> complete. You claim that you miss them thus device is incomplete is just
>>>>>>> not correct: these properties do not belong here! They belong to the
>>>>>>> board but even there they are totally optional. Why would they be a
>>>>>>> required resource?
>>>>>>>
>>>>>>> To remind: we talk here ONLY about required resources.
>>>>>>
>>>>>> Yes, 'pinctrl-*' properties belongs to the board and are not required.
>>>>>> So nothing is missing.
>>>>>>
>>>>>> This hdp node in the SoC dtsi file can be enabled by default.
>>>>>> But the hdp driver will probe and do nothing because without the
>>>>>> 'pinctrl-*' properties from the board files it would not be able to
>>>>>> access to any pin.
>>>>>
>>>>>
>>>>> Pinctrl has other features in general, including interfaces to userspace
>>>>> (as pretty often combined with gpio, although not sure if relevant here).
>>>>
>>>> You're right. Also HDP pinctrl has a GPO feature accessible from userspace.
>>>> But by default the HDP is not connected to any pad; it needs the board
>>>
>>> OK, then that was the answer to my first question - what is missing.
>>> However aren't these pads connected internally also to other parts of
>>> the SoC (like in most other vendors)?
>>
>> No, HDP "output pads" are only connected to SoC pinctrl to route outside
>> the internal SoC signals for debug purpose.
>>
>>>> 'pinctrl-*' properties to configure the SoC pinctrl and expose HDP on
>>>> the SoC pads.
>>>>
>>>> That's why for me the enabling of the driver should be in the board file
>>>> together with the SoC pinctrl configuration.
>>>
>>> And what are the default pad settings configured by HPD driver in
>>> bootloader (and by bootloader I mean one of few bootloaders this is
>>> going to be used on like U-Boot)
>>
>> The default is to use the GPIO of the SoC pinctrl. The HDP is not routed
>> outside.
>>    >>
>>>> The userland cannot change the pinctrl alternate function mux, this is
>>>> statically defined by the devicetree.
>>>
>>> If you expose GPIO then userland needs this regardless of alternate mux.
>>> IOW, board level could not configure mux because it should be always
>>> configured to safe GPIO input.
>>
>> For userland sight view, SoC GPIO are preferred instead of HDP.
>> HDP is only GPO not GPIO. 'pinctrl-*' properties configure at the same
>> time the SoC pinctrl mux to HDP and the HDP pinctrl mux to one of the
>> HDP functions (e.g. GPO).
> Thanks, that's explains, fine to keep it disabled. Unless it is obvious
> for everyone, it would be nice to put it in commit msg.

You're welcome, so I'll provide the V6 with more information in the 
commit message of patch [5-7] among other needed fixes.

> 
> Best regards,
> Krzysztof

On 6/12/25 15:21, Clement LE GOFFIC wrote:
> On 6/12/25 15:09, Krzysztof Kozlowski wrote:
>> On 12/06/2025 15:02, Clement LE GOFFIC wrote:
>>> On 6/12/25 13:05, Krzysztof Kozlowski wrote:
>>>> On 12/06/2025 11:31, Clement LE GOFFIC wrote:
>>>>> On 6/11/25 17:48, Krzysztof Kozlowski wrote:
>>>>>> On 11/06/2025 16:08, Clement LE GOFFIC wrote:
>>>>>>> On 6/11/25 08:35, Krzysztof Kozlowski wrote:
>>>>>>>> On 10/06/2025 15:33, Clement LE GOFFIC wrote:
>>>>>>>>> On 6/10/25 14:38, Krzysztof Kozlowski wrote:
>>>>>>>>>> On 10/06/2025 14:02, Clement LE GOFFIC wrote:
>>>>>>>>>>> On 5/29/25 11:01, Krzysztof Kozlowski wrote:
>>>>>>>>>>>> On 28/05/2025 14:14, Clement LE GOFFIC wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> +        };
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +        hdp: pinctrl@5002a000 {
>>>>>>>>>>>>>>> +            compatible = "st,stm32mp131-hdp";
>>>>>>>>>>>>>>> +            reg = <0x5002a000 0x400>;
>>>>>>>>>>>>>>> +            clocks = <&rcc HDP>;
>>>>>>>>>>>>>>>                     status = "disabled";
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Why are you disabling it? What is missing?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nothing is missing just disabled by default.
>>>>>>>>>>>>> The node is then enabled when needed in board's dts file.
>>>>>>>>>>>> Nodes should not be disabled by default if they are 
>>>>>>>>>>>> complete. That's why
>>>>>>>>>>>> I asked what is missing. Drop.
>>>>>>>>>>>
>>>>>>>>>>> Hi Krzysztof, OK I better understand now.
>>>>>>>>>>> So yes the 'pinctrl-*' properties which are board dependent 
>>>>>>>>>>> are lacking.
>>>>>>>>>>
>>>>>>>>>> These are not properties of this node.
>>>>>>>>>
>>>>>>>>> Does this mean I should add 'pinctrl-*' properties in bindings 
>>>>>>>>> yaml file ?
>>>>>>>>> I don't get it..
>>>>>>>>
>>>>>>>> These properties have no meaning here, so the hardware 
>>>>>>>> description is
>>>>>>>> complete. You claim that you miss them thus device is incomplete 
>>>>>>>> is just
>>>>>>>> not correct: these properties do not belong here! They belong to 
>>>>>>>> the
>>>>>>>> board but even there they are totally optional. Why would they be a
>>>>>>>> required resource?
>>>>>>>>
>>>>>>>> To remind: we talk here ONLY about required resources.
>>>>>>>
>>>>>>> Yes, 'pinctrl-*' properties belongs to the board and are not 
>>>>>>> required.
>>>>>>> So nothing is missing.
>>>>>>>
>>>>>>> This hdp node in the SoC dtsi file can be enabled by default.
>>>>>>> But the hdp driver will probe and do nothing because without the
>>>>>>> 'pinctrl-*' properties from the board files it would not be able to
>>>>>>> access to any pin.
>>>>>>
>>>>>>
>>>>>> Pinctrl has other features in general, including interfaces to 
>>>>>> userspace
>>>>>> (as pretty often combined with gpio, although not sure if relevant 
>>>>>> here).
>>>>>
>>>>> You're right. Also HDP pinctrl has a GPO feature accessible from 
>>>>> userspace.
>>>>> But by default the HDP is not connected to any pad; it needs the board
>>>>
>>>> OK, then that was the answer to my first question - what is missing.
>>>> However aren't these pads connected internally also to other parts of
>>>> the SoC (like in most other vendors)?
>>>
>>> No, HDP "output pads" are only connected to SoC pinctrl to route outside
>>> the internal SoC signals for debug purpose.
>>>
>>>>> 'pinctrl-*' properties to configure the SoC pinctrl and expose HDP on
>>>>> the SoC pads.
>>>>>
>>>>> That's why for me the enabling of the driver should be in the board 
>>>>> file
>>>>> together with the SoC pinctrl configuration.
>>>>
>>>> And what are the default pad settings configured by HPD driver in
>>>> bootloader (and by bootloader I mean one of few bootloaders this is
>>>> going to be used on like U-Boot)
>>>
>>> The default is to use the GPIO of the SoC pinctrl. The HDP is not routed
>>> outside.
>>>    >>
>>>>> The userland cannot change the pinctrl alternate function mux, this is
>>>>> statically defined by the devicetree.
>>>>
>>>> If you expose GPIO then userland needs this regardless of alternate 
>>>> mux.
>>>> IOW, board level could not configure mux because it should be always
>>>> configured to safe GPIO input.
>>>
>>> For userland sight view, SoC GPIO are preferred instead of HDP.
>>> HDP is only GPO not GPIO. 'pinctrl-*' properties configure at the same
>>> time the SoC pinctrl mux to HDP and the HDP pinctrl mux to one of the
>>> HDP functions (e.g. GPO).
>> Thanks, that's explains, fine to keep it disabled. Unless it is obvious
>> for everyone, it would be nice to put it in commit msg.
> 
> You're welcome, so I'll provide the V6 with more information in the
> commit message of patch [5-7] among other needed fixes.

V5*

>>
>> Best regards,
>> Krzysztof
> 
> _______________________________________________
> Linux-stm32 mailing list
> Linux-stm32@st-md-mailman.stormreply.com
> https://st-md-mailman.stormreply.com/mailman/listinfo/linux-stm32