Linux GPIO subsystem development
 help / color / mirror / Atom feed
From: Clement LE GOFFIC <clement.legoffic@foss.st.com>
To: Krzysztof Kozlowski <krzk@kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Bartosz Golaszewski <brgl@bgdev.pl>
Cc: <linux-kernel@vger.kernel.org>, <linux-gpio@vger.kernel.org>,
	<devicetree@vger.kernel.org>,
	<linux-stm32@st-md-mailman.stormreply.com>,
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/9] dt-bindings: pinctrl: stm32: Introduce HDP
Date: Thu, 27 Feb 2025 12:05:24 +0100	[thread overview]
Message-ID: <cf86046b-00e2-41cc-b93c-7ad6cb4d062e@foss.st.com> (raw)
In-Reply-To: <46fbdccb-610a-4b73-8697-d7bcf4942a41@kernel.org>

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


  reply	other threads:[~2025-02-27 11:07 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-25  8:47 [PATCH 0/9] Introduce HDP support for STM32MP platforms Clément Le Goffic
2025-02-25  8:48 ` [PATCH 1/9] dt-bindings: pinctrl: stm32: Add HDP includes for stm32mp platforms Clément Le Goffic
2025-02-25 13:01   ` Krzysztof Kozlowski
2025-02-25 15:46     ` Clement LE GOFFIC
2025-02-26  7:19       ` Krzysztof Kozlowski
2025-02-25  8:48 ` [PATCH 2/9] dt-bindings: pinctrl: stm32: Introduce HDP Clément Le Goffic
2025-02-25 13:04   ` Krzysztof Kozlowski
2025-02-25 15:51     ` Clement LE GOFFIC
2025-02-26  7:21       ` Krzysztof Kozlowski
2025-02-26 10:52         ` Clement LE GOFFIC
2025-02-26 15:05           ` Krzysztof Kozlowski
2025-02-27 11:05             ` Clement LE GOFFIC [this message]
2025-02-25  8:48 ` [PATCH 3/9] pinctrl: stm32: Introduce HDP driver Clément Le Goffic
2025-02-25 12:59   ` Krzysztof Kozlowski
2025-02-25 16:05     ` Clement LE GOFFIC
2025-02-25  8:48 ` [PATCH 4/9] MAINTAINERS: Add Clément Le Goffic as STM32 HDP maintainer Clément Le Goffic
2025-02-25  8:48 ` [PATCH 5/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp13 Clément Le Goffic
2025-02-25  8:48 ` [PATCH 6/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp15 Clément Le Goffic
2025-02-25  8:48 ` [PATCH 7/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp25 Clément Le Goffic
2025-02-25 13:05   ` Krzysztof Kozlowski
2025-02-25 16:09     ` Clement LE GOFFIC
2025-02-26  7:23       ` Krzysztof Kozlowski
2025-02-26  9:33         ` Alexandre TORGUE
2025-02-26 15:08           ` Krzysztof Kozlowski
2025-02-26 15:30             ` Alexandre TORGUE
2025-02-26 16:54               ` Alexandre TORGUE
2025-02-26 21:27                 ` Krzysztof Kozlowski
2025-02-26 21:26               ` Krzysztof Kozlowski
2025-02-26 21:31                 ` Krzysztof Kozlowski
2025-02-27 12:16                   ` Alexandre TORGUE
2025-02-25  8:48 ` [PATCH 8/9] ARM: dts: stm32: add alternate pinmux for HDP pin and add HDP pinctrl node Clément Le Goffic
2025-02-25  8:48 ` [PATCH 9/9] ARM: dts: stm32: add Hardware debug port (HDP) on stm32mp157c-dk2 board Clément Le Goffic

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=cf86046b-00e2-41cc-b93c-7ad6cb4d062e@foss.st.com \
    --to=clement.legoffic@foss.st.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=brgl@bgdev.pl \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=robh@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox