[PATCH] ARM: dts: stm32: Fill GPIO line names on AV96

[PATCH] ARM: dts: stm32: Fill GPIO line names on AV96

[Marek Vasut]

Fill in the custom GPIO line names used by DH.

Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: linux-stm32@st-md-mailman.stormreply.com
To: linux-arm-kernel@lists.infradead.org
---
 .../boot/dts/stm32mp15xx-dhcor-avenger96.dtsi | 35 +++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
index 930202742a3f..e7643fbed69e 100644
--- a/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
+++ b/arch/arm/boot/dts/stm32mp15xx-dhcor-avenger96.dtsi
@@ -162,6 +162,41 @@ phy0: ethernet-phy@7 {
 	};
 };
 
+&gpioa {
+	gpio-line-names = "", "", "", "",
+			  "", "", "", "",
+			  "", "", "", "DH-GPIO-K",
+			  "DH-GPIO-I", "", "DH-GPIO-A", "";
+};
+
+&gpiob {
+	gpio-line-names = "", "", "", "",
+			  "", "DH-GPIO-J", "", "",
+			  "", "", "", "DH-GPIO-B",
+			  "", "DH-GPIO-L", "", "";
+};
+
+&gpioc {
+	gpio-line-names = "", "", "", "DH-GPIO-C",
+			  "", "", "", "",
+			  "", "", "", "",
+			  "", "", "", "";
+};
+
+&gpiod {
+	gpio-line-names = "", "", "", "",
+			  "", "", "", "",
+			  "DH-GPIO-D", "", "", "",
+			  "", "", "DH-GPIO-E", "DH-GPIO-F";
+};
+
+&gpiof {
+	gpio-line-names = "", "", "", "",
+			  "", "", "", "",
+			  "", "", "", "",
+			  "DH-GPIO-G", "DH-GPIO-H", "", "";
+};
+
 &i2c1 {	/* X6 I2C1 */
 	pinctrl-names = "default";
 	pinctrl-0 = <&i2c1_pins_b>;
-- 
2.27.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH] ARM: dts: stm32: Fill GPIO line names on AV96

[Christoph Niedermaier]

From: Marek Vasut <marex@denx.de>
Sent: Friday, July 24, 2020 12:16 PM
> 
> Fill in the custom GPIO line names used by DH.
>
[...]
> +&gpioa {
> +       gpio-line-names = "", "", "", "",
> +                         "", "", "", "",
> +                         "", "", "", "DH-GPIO-K",
> +                         "DH-GPIO-I", "", "DH-GPIO-A", "";
> +};
> +
[...]

Hello Marek,

We have been using the GPIO names at DH electronics for some time and also
on other SOMs, but have not yet streamed them. We started with the naming
only with a capital letter "A-W" since then without problems. To avoid a
hard cut or patching for us and our customers it would be good if we could
use the same naming in the mainline kernel as well. Marek, we would be
happy if you would adopt our valued GPIO naming in your patch.

Regards,
Christoph

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] ARM: dts: stm32: Fill GPIO line names on AV96

[Marek Vasut]

On 8/6/20 9:09 AM, Christoph Niedermaier wrote:
> From: Marek Vasut <marex@denx.de>
> Sent: Friday, July 24, 2020 12:16 PM
>>
>> Fill in the custom GPIO line names used by DH.
>>
> [...]
>> +&gpioa {
>> +       gpio-line-names = "", "", "", "",
>> +                         "", "", "", "",
>> +                         "", "", "", "DH-GPIO-K",
>> +                         "DH-GPIO-I", "", "DH-GPIO-A", "";
>> +};
>> +
> [...]
> 
> Hello Marek,

Hello Christoph,

> We have been using the GPIO names at DH electronics for some time and also
> on other SOMs, but have not yet streamed them. We started with the naming
> only with a capital letter "A-W" since then without problems. To avoid a
> hard cut or patching for us and our customers it would be good if we could
> use the same naming in the mainline kernel as well. Marek, we would be
> happy if you would adopt our valued GPIO naming in your patch.

My counter-argument to this is that the naming should be unique and
provide a hint where those GPIO lines come from, so maybe even DH-GPIO-n
should rather be DHCOM-n . I can't say I'm particularly fond of the
plain 'n' naming of GPIO lines, because then the GPIO label (and e.g.
listing in libgpiod tools) does not give any hint what the GPIO is or
where it comes from. Also, I worry a plain 'n' naming might clash with
other GPIO IPs easily, while a more unique name can not.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] ARM: dts: stm32: Fill GPIO line names on AV96

[Christoph Niedermaier]

From: Marek Vasut [mailto:marex@denx.de]
Sent: Thursday, August 6, 2020 9:30 AM

> On 8/6/20 9:09 AM, Christoph Niedermaier wrote:
>> From: Marek Vasut <marex@denx.de>
>> Sent: Friday, July 24, 2020 12:16 PM
>>>
>>> Fill in the custom GPIO line names used by DH.
>>>
>> [...]
>>> +&gpioa {
>>> +       gpio-line-names = "", "", "", "",
>>> +                         "", "", "", "",
>>> +                         "", "", "", "DH-GPIO-K",
>>> +                         "DH-GPIO-I", "", "DH-GPIO-A", "";
>>> +};
>>> +
>> [...]
>>
>> We have been using the GPIO names at DH electronics for some time and also
>> on other SOMs, but have not yet streamed them. We started with the naming
>> only with a capital letter "A-W" since then without problems. To avoid a
>> hard cut or patching for us and our customers it would be good if we could
>> use the same naming in the mainline kernel as well. Marek, we would be
>> happy if you would adopt our valued GPIO naming in your patch.
> 
> My counter-argument to this is that the naming should be unique and
> provide a hint where those GPIO lines come from, so maybe even DH-GPIO-n
> should rather be DHCOM-n . I can't say I'm particularly fond of the
> plain 'n' naming of GPIO lines, because then the GPIO label (and e.g.
> listing in libgpiod tools) does not give any hint what the GPIO is or
> where it comes from. Also, I worry a plain 'n' naming might clash with
> other GPIO IPs easily, while a more unique name can not.

Hello Marek,

after an internal discussion, we decided the following:

Could you update the patch for the Avenger96 to the GPIO naming "AV96-n".

Moreover for the SOM layer (stm32mp15xx-dhcom-som.dtsi) we would prefer
"DHCOM-n". It would be nice if you could create a patch for it.


Regards,
Christoph
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] ARM: dts: stm32: Fill GPIO line names on AV96

[Marek Vasut]

On 3/12/21 4:17 PM, Christoph Niedermaier wrote:
> From: Marek Vasut [mailto:marex@denx.de]
> Sent: Thursday, August 6, 2020 9:30 AM
> 
>> On 8/6/20 9:09 AM, Christoph Niedermaier wrote:
>>> From: Marek Vasut <marex@denx.de>
>>> Sent: Friday, July 24, 2020 12:16 PM
>>>>
>>>> Fill in the custom GPIO line names used by DH.
>>>>
>>> [...]
>>>> +&gpioa {
>>>> +       gpio-line-names = "", "", "", "",
>>>> +                         "", "", "", "",
>>>> +                         "", "", "", "DH-GPIO-K",
>>>> +                         "DH-GPIO-I", "", "DH-GPIO-A", "";
>>>> +};
>>>> +
>>> [...]
>>>
>>> We have been using the GPIO names at DH electronics for some time and also
>>> on other SOMs, but have not yet streamed them. We started with the naming
>>> only with a capital letter "A-W" since then without problems. To avoid a
>>> hard cut or patching for us and our customers it would be good if we could
>>> use the same naming in the mainline kernel as well. Marek, we would be
>>> happy if you would adopt our valued GPIO naming in your patch.
>>
>> My counter-argument to this is that the naming should be unique and
>> provide a hint where those GPIO lines come from, so maybe even DH-GPIO-n
>> should rather be DHCOM-n . I can't say I'm particularly fond of the
>> plain 'n' naming of GPIO lines, because then the GPIO label (and e.g.
>> listing in libgpiod tools) does not give any hint what the GPIO is or
>> where it comes from. Also, I worry a plain 'n' naming might clash with
>> other GPIO IPs easily, while a more unique name can not.
> 
> Hello Marek,
> 
> after an internal discussion, we decided the following:
> 
> Could you update the patch for the Avenger96 to the GPIO naming "AV96-n".
> 
> Moreover for the SOM layer (stm32mp15xx-dhcom-som.dtsi) we would prefer
> "DHCOM-n". It would be nice if you could create a patch for it.

I don't think we should have any SoM-side gpio-line-names, because once 
you plug the SoM into new carrier board, the gpio-lane-names will no 
longer make sense. So, I think all the gpio-line-names should be 
implemented in the carrier board DTS.

As for the naming scheme, I was also hoping Linus might jump in and 
provide some suggestion on best practice here.

I think naming carrier board GPIOs "A", "B", "C",... is too opaque and 
can easily collide e.g. with GPIO expanders which might be on I2C or so.

A naming scheme which encodes the carrier board name is clearer and less 
likely to cause collision, so "AV96-A", "AV96-B", etc. looks good to me. 
It is obvious where the GPIO is located and unlikely to collide with any 
other GPIO name.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH] ARM: dts: stm32: Fill GPIO line names on AV96

[Christoph Niedermaier]

From: Marek Vasut [mailto:marex@denx.de]
Sent: Friday, March 12, 2021 5:17 PM
> To: Christoph Niedermaier <cniedermaier@dh-electronics.com>; linux-arm-
> kernel@lists.infradead.org; linus.walleij@linaro.org
> Cc: Alexandre Torgue <alexandre.torgue@st.com>; Patrice Chotard
> <patrice.chotard@st.com>; Patrick Delaunay <patrick.delaunay@st.com>;
> Maxime Coquelin <mcoquelin.stm32@gmail.com>; linux-stm32@st-md-
> mailman.stormreply.com
> Subject: Re: [PATCH] ARM: dts: stm32: Fill GPIO line names on AV96
> 
> ACHTUNG: Diese E-Mail kommt aus dem Internet und nicht aus unserem
> Firmennetzwerk!
> 
> 
> 
> On 3/12/21 4:17 PM, Christoph Niedermaier wrote:
>> From: Marek Vasut [mailto:marex@denx.de]
>> Sent: Thursday, August 6, 2020 9:30 AM
>>
>>> On 8/6/20 9:09 AM, Christoph Niedermaier wrote:
>>>> From: Marek Vasut <marex@denx.de>
>>>> Sent: Friday, July 24, 2020 12:16 PM
>>>>>
>>>>> Fill in the custom GPIO line names used by DH.
>>>>>
>>>> [...]
>>>>> +&gpioa {
>>>>> +       gpio-line-names = "", "", "", "",
>>>>> +                         "", "", "", "",
>>>>> +                         "", "", "", "DH-GPIO-K",
>>>>> +                         "DH-GPIO-I", "", "DH-GPIO-A", "";
>>>>> +};
>>>>> +
>>>> [...]
>>>>
>>>> We have been using the GPIO names at DH electronics for some time and also
>>>> on other SOMs, but have not yet streamed them. We started with the naming
>>>> only with a capital letter "A-W" since then without problems. To avoid a
>>>> hard cut or patching for us and our customers it would be good if we could
>>>> use the same naming in the mainline kernel as well. Marek, we would be
>>>> happy if you would adopt our valued GPIO naming in your patch.
>>>
>>> My counter-argument to this is that the naming should be unique and
>>> provide a hint where those GPIO lines come from, so maybe even DH-GPIO-n
>>> should rather be DHCOM-n . I can't say I'm particularly fond of the
>>> plain 'n' naming of GPIO lines, because then the GPIO label (and e.g.
>>> listing in libgpiod tools) does not give any hint what the GPIO is or
>>> where it comes from. Also, I worry a plain 'n' naming might clash with
>>> other GPIO IPs easily, while a more unique name can not.
>>
>> Hello Marek,
>>
>> after an internal discussion, we decided the following:
>>
>> Could you update the patch for the Avenger96 to the GPIO naming "AV96-n".
>>
>> Moreover for the SOM layer (stm32mp15xx-dhcom-som.dtsi) we would prefer
>> "DHCOM-n". It would be nice if you could create a patch for it.
> 
> I don't think we should have any SoM-side gpio-line-names, because once
> you plug the SoM into new carrier board, the gpio-lane-names will no
> longer make sense. So, I think all the gpio-line-names should be
> implemented in the carrier board DTS.

The idea is to define the GPIO names on the SOM layer and then
overwrite them on the carrier board DTS if needed. If there is no
naming on the carrier board, at least you have access via the DHCOM
GPIO names. The DHCOM GPIO names are standardized, so that you can
be sure that the assignment to a pin always fits.

> 
> As for the naming scheme, I was also hoping Linus might jump in and
> provide some suggestion on best practice here.
> 
> I think naming carrier board GPIOs "A", "B", "C",... is too opaque and
> can easily collide e.g. with GPIO expanders which might be on I2C or so.
> 
> A naming scheme which encodes the carrier board name is clearer and less
> likely to cause collision, so "AV96-A", "AV96-B", etc. looks good to me.
> It is obvious where the GPIO is located and unlikely to collide with any
> other GPIO name.

Regards,
Christoph

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] ARM: dts: stm32: Fill GPIO line names on AV96

[Marek Vasut]

On 3/12/21 6:38 PM, Christoph Niedermaier wrote:
> From: Marek Vasut [mailto:marex@denx.de]
> Sent: Friday, March 12, 2021 5:17 PM
>> To: Christoph Niedermaier <cniedermaier@dh-electronics.com>; linux-arm-
>> kernel@lists.infradead.org; linus.walleij@linaro.org
>> Cc: Alexandre Torgue <alexandre.torgue@st.com>; Patrice Chotard
>> <patrice.chotard@st.com>; Patrick Delaunay <patrick.delaunay@st.com>;
>> Maxime Coquelin <mcoquelin.stm32@gmail.com>; linux-stm32@st-md-
>> mailman.stormreply.com
>> Subject: Re: [PATCH] ARM: dts: stm32: Fill GPIO line names on AV96
>>
>> ACHTUNG: Diese E-Mail kommt aus dem Internet und nicht aus unserem
>> Firmennetzwerk!
>>
>>
>>
>> On 3/12/21 4:17 PM, Christoph Niedermaier wrote:
>>> From: Marek Vasut [mailto:marex@denx.de]
>>> Sent: Thursday, August 6, 2020 9:30 AM
>>>
>>>> On 8/6/20 9:09 AM, Christoph Niedermaier wrote:
>>>>> From: Marek Vasut <marex@denx.de>
>>>>> Sent: Friday, July 24, 2020 12:16 PM
>>>>>>
>>>>>> Fill in the custom GPIO line names used by DH.
>>>>>>
>>>>> [...]
>>>>>> +&gpioa {
>>>>>> +       gpio-line-names = "", "", "", "",
>>>>>> +                         "", "", "", "",
>>>>>> +                         "", "", "", "DH-GPIO-K",
>>>>>> +                         "DH-GPIO-I", "", "DH-GPIO-A", "";
>>>>>> +};
>>>>>> +
>>>>> [...]
>>>>>
>>>>> We have been using the GPIO names at DH electronics for some time and also
>>>>> on other SOMs, but have not yet streamed them. We started with the naming
>>>>> only with a capital letter "A-W" since then without problems. To avoid a
>>>>> hard cut or patching for us and our customers it would be good if we could
>>>>> use the same naming in the mainline kernel as well. Marek, we would be
>>>>> happy if you would adopt our valued GPIO naming in your patch.
>>>>
>>>> My counter-argument to this is that the naming should be unique and
>>>> provide a hint where those GPIO lines come from, so maybe even DH-GPIO-n
>>>> should rather be DHCOM-n . I can't say I'm particularly fond of the
>>>> plain 'n' naming of GPIO lines, because then the GPIO label (and e.g.
>>>> listing in libgpiod tools) does not give any hint what the GPIO is or
>>>> where it comes from. Also, I worry a plain 'n' naming might clash with
>>>> other GPIO IPs easily, while a more unique name can not.
>>>
>>> Hello Marek,
>>>
>>> after an internal discussion, we decided the following:
>>>
>>> Could you update the patch for the Avenger96 to the GPIO naming "AV96-n".
>>>
>>> Moreover for the SOM layer (stm32mp15xx-dhcom-som.dtsi) we would prefer
>>> "DHCOM-n". It would be nice if you could create a patch for it.
>>
>> I don't think we should have any SoM-side gpio-line-names, because once
>> you plug the SoM into new carrier board, the gpio-lane-names will no
>> longer make sense. So, I think all the gpio-line-names should be
>> implemented in the carrier board DTS.
> 
> The idea is to define the GPIO names on the SOM layer and then
> overwrite them on the carrier board DTS if needed. If there is no
> naming on the carrier board, at least you have access via the DHCOM
> GPIO names. The DHCOM GPIO names are standardized, so that you can
> be sure that the assignment to a pin always fits.

So I'll pose another question here to the GPIO maintainers.

Is it OK to define gpio-line-names in SoM DTSI even for pins which will 
not be used as GPIOs e.g. because they are muxed differently in the 
carrier board DTS ?

If that is OK, then the above approach is then also OK.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH] ARM: dts: stm32: Fill GPIO line names on AV96

[Christoph Niedermaier]

From: Marek Vasut <marex@denx.de>
Sent: Friday, March 12, 2021 10:01 PM
> On 3/12/21 6:38 PM, Christoph Niedermaier wrote:
>> From: Marek Vasut [mailto:marex@denx.de]
>> Sent: Friday, March 12, 2021 5:17 PM
>>> On 3/12/21 4:17 PM, Christoph Niedermaier wrote:
>>>> From: Marek Vasut [mailto:marex@denx.de]
>>>> Sent: Thursday, August 6, 2020 9:30 AM
>>>>
>>>>> On 8/6/20 9:09 AM, Christoph Niedermaier wrote:
>>>>>> From: Marek Vasut <marex@denx.de>
>>>>>> Sent: Friday, July 24, 2020 12:16 PM
>>>>>>>
>>>>>>> Fill in the custom GPIO line names used by DH.
>>>>>>>
>>>>>> [...]
>>>>>>> +&gpioa {
>>>>>>> +       gpio-line-names = "", "", "", "",
>>>>>>> +                         "", "", "", "",
>>>>>>> +                         "", "", "", "DH-GPIO-K",
>>>>>>> +                         "DH-GPIO-I", "", "DH-GPIO-A", "";
>>>>>>> +};
>>>>>>> +
>>>>>> [...]
>>>>>>
>>>>>> We have been using the GPIO names at DH electronics for some time and also
>>>>>> on other SOMs, but have not yet streamed them. We started with the naming
>>>>>> only with a capital letter "A-W" since then without problems. To avoid a
>>>>>> hard cut or patching for us and our customers it would be good if we could
>>>>>> use the same naming in the mainline kernel as well. Marek, we would be
>>>>>> happy if you would adopt our valued GPIO naming in your patch.
>>>>>
>>>>> My counter-argument to this is that the naming should be unique and
>>>>> provide a hint where those GPIO lines come from, so maybe even DH-GPIO-n
>>>>> should rather be DHCOM-n . I can't say I'm particularly fond of the
>>>>> plain 'n' naming of GPIO lines, because then the GPIO label (and e.g.
>>>>> listing in libgpiod tools) does not give any hint what the GPIO is or
>>>>> where it comes from. Also, I worry a plain 'n' naming might clash with
>>>>> other GPIO IPs easily, while a more unique name can not.
>>>>
>>>> Hello Marek,
>>>>
>>>> after an internal discussion, we decided the following:
>>>>
>>>> Could you update the patch for the Avenger96 to the GPIO naming "AV96-n".
>>>>
>>>> Moreover for the SOM layer (stm32mp15xx-dhcom-som.dtsi) we would prefer
>>>> "DHCOM-n". It would be nice if you could create a patch for it.
>>>
>>> I don't think we should have any SoM-side gpio-line-names, because once
>>> you plug the SoM into new carrier board, the gpio-lane-names will no
>>> longer make sense. So, I think all the gpio-line-names should be
>>> implemented in the carrier board DTS.
>>
>> The idea is to define the GPIO names on the SOM layer and then
>> overwrite them on the carrier board DTS if needed. If there is no
>> naming on the carrier board, at least you have access via the DHCOM
>> GPIO names. The DHCOM GPIO names are standardized, so that you can
>> be sure that the assignment to a pin always fits.
> 
> So I'll pose another question here to the GPIO maintainers.
> 
> Is it OK to define gpio-line-names in SoM DTSI even for pins which will
> not be used as GPIOs e.g. because they are muxed differently in the
> carrier board DTS ?
> 
> If that is OK, then the above approach is then also OK.

In our case, we cannot mux the GPIO pins in the carrier board DTS
to another functions, because then we break our SOM standard (DHCOM).
So in the case we relabel a GPIO in the carrier board e.g. "DHCOM-I"
becomes "LED1" the mux function have to be GPIO.

Regards,
Christoph
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Linux-stm32] [PATCH] ARM: dts: stm32: Fill GPIO line names on AV96

[Ahmad Fatoum]

On 15.03.21 12:41, Christoph Niedermaier wrote:
>> So I'll pose another question here to the GPIO maintainers.
>>
>> Is it OK to define gpio-line-names in SoM DTSI even for pins which will
>> not be used as GPIOs e.g. because they are muxed differently in the
>> carrier board DTS ?
>>
>> If that is OK, then the above approach is then also OK.
> 
> In our case, we cannot mux the GPIO pins in the carrier board DTS
> to another functions, because then we break our SOM standard (DHCOM).
> So in the case we relabel a GPIO in the carrier board e.g. "DHCOM-I"
> becomes "LED1" the mux function have to be GPIO.

For standards like SMARC, where the interface is predefined, I think it makes
much sense to have the SoM dtsi contain not only the line-names, but also
ready-to-use, pinmuxing settings.

Base boards can then either enable peripherals with just a status = "okay"
if they follow the standard or just override it if they choose to do
stuff differently.

Cheers,
Ahmad

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

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Linux-stm32] [PATCH] ARM: dts: stm32: Fill GPIO line names on AV96

[Marek Vasut]

On 3/15/21 1:05 PM, Ahmad Fatoum wrote:
> On 15.03.21 12:41, Christoph Niedermaier wrote:
>>> So I'll pose another question here to the GPIO maintainers.
>>>
>>> Is it OK to define gpio-line-names in SoM DTSI even for pins which will
>>> not be used as GPIOs e.g. because they are muxed differently in the
>>> carrier board DTS ?
>>>
>>> If that is OK, then the above approach is then also OK.
>>
>> In our case, we cannot mux the GPIO pins in the carrier board DTS
>> to another functions, because then we break our SOM standard (DHCOM).
>> So in the case we relabel a GPIO in the carrier board e.g. "DHCOM-I"
>> becomes "LED1" the mux function have to be GPIO.
> 
> For standards like SMARC, where the interface is predefined, I think it makes
> much sense to have the SoM dtsi contain not only the line-names, but also
> ready-to-use, pinmuxing settings.
> 
> Base boards can then either enable peripherals with just a status = "okay"
> if they follow the standard or just override it if they choose to do
> stuff differently.

Sadly, I think I have to remind you of the discussion around pinctrl 
groups we have in stm32mp15-pinctrl.dtsi and how that does not scale. 
This is a very similar situation here, since the SoM is rather universal.

And the other thing I would like to point out here are the discussions 
around DT connector. What you described above is exactly that, except 
the implementation is still not finished. Let's CC Frank.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Linux-stm32] [PATCH] ARM: dts: stm32: Fill GPIO line names on AV96

[Ahmad Fatoum]

Hello,

On 15.03.21 15:29, Marek Vasut wrote:
> On 3/15/21 1:05 PM, Ahmad Fatoum wrote:
>> On 15.03.21 12:41, Christoph Niedermaier wrote:
>>>> So I'll pose another question here to the GPIO maintainers.
>>>>
>>>> Is it OK to define gpio-line-names in SoM DTSI even for pins which will
>>>> not be used as GPIOs e.g. because they are muxed differently in the
>>>> carrier board DTS ?
>>>>
>>>> If that is OK, then the above approach is then also OK.
>>>
>>> In our case, we cannot mux the GPIO pins in the carrier board DTS
>>> to another functions, because then we break our SOM standard (DHCOM).
>>> So in the case we relabel a GPIO in the carrier board e.g. "DHCOM-I"
>>> becomes "LED1" the mux function have to be GPIO.
>>
>> For standards like SMARC, where the interface is predefined, I think it makes
>> much sense to have the SoM dtsi contain not only the line-names, but also
>> ready-to-use, pinmuxing settings.
>>
>> Base boards can then either enable peripherals with just a status = "okay"
>> if they follow the standard or just override it if they choose to do
>> stuff differently.
> 
> Sadly, I think I have to remind you of the discussion around pinctrl groups we have in stm32mp15-pinctrl.dtsi and how that does not scale. This is a very similar situation here, since the SoM is rather universal.

I don't think this is directly comparable. A SoC has _lots_ of possible way to mux and
conf pads. A SMARC, AFAIU, has exactly one official pinout. That one you can add into
the dtsi and the bast board either extends that or overrides it if it diverges.

> And the other thing I would like to point out here are the discussions around DT connector. What you described above is exactly that, except the implementation is still not finished. Let's CC Frank.
Thanks for the pointer. I'll check it out.

Cheers,
Ahmad

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Linux-stm32] [PATCH] ARM: dts: stm32: Fill GPIO line names on AV96

[Marek Vasut]

On 3/15/21 4:05 PM, Ahmad Fatoum wrote:
> Hello,
> 
> On 15.03.21 15:29, Marek Vasut wrote:
>> On 3/15/21 1:05 PM, Ahmad Fatoum wrote:
>>> On 15.03.21 12:41, Christoph Niedermaier wrote:
>>>>> So I'll pose another question here to the GPIO maintainers.
>>>>>
>>>>> Is it OK to define gpio-line-names in SoM DTSI even for pins which will
>>>>> not be used as GPIOs e.g. because they are muxed differently in the
>>>>> carrier board DTS ?
>>>>>
>>>>> If that is OK, then the above approach is then also OK.
>>>>
>>>> In our case, we cannot mux the GPIO pins in the carrier board DTS
>>>> to another functions, because then we break our SOM standard (DHCOM).
>>>> So in the case we relabel a GPIO in the carrier board e.g. "DHCOM-I"
>>>> becomes "LED1" the mux function have to be GPIO.
>>>
>>> For standards like SMARC, where the interface is predefined, I think it makes
>>> much sense to have the SoM dtsi contain not only the line-names, but also
>>> ready-to-use, pinmuxing settings.
>>>
>>> Base boards can then either enable peripherals with just a status = "okay"
>>> if they follow the standard or just override it if they choose to do
>>> stuff differently.
>>
>> Sadly, I think I have to remind you of the discussion around pinctrl groups we have in stm32mp15-pinctrl.dtsi and how that does not scale. This is a very similar situation here, since the SoM is rather universal.
> 
> I don't think this is directly comparable. A SoC has _lots_ of possible way to mux and
> conf pads. A SMARC, AFAIU, has exactly one official pinout. That one you can add into
> the dtsi and the bast board either extends that or overrides it if it diverges.

That's not the case here.

>> And the other thing I would like to point out here are the discussions around DT connector. What you described above is exactly that, except the implementation is still not finished. Let's CC Frank.
> Thanks for the pointer. I'll check it out.

Sure

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] ARM: dts: stm32: Fill GPIO line names on AV96

[Marek Vasut]

On 3/15/21 12:41 PM, Christoph Niedermaier wrote:

[...]

>>>>>>>> Fill in the custom GPIO line names used by DH.
>>>>>>>>
>>>>>>> [...]
>>>>>>>> +&gpioa {
>>>>>>>> +       gpio-line-names = "", "", "", "",
>>>>>>>> +                         "", "", "", "",
>>>>>>>> +                         "", "", "", "DH-GPIO-K",
>>>>>>>> +                         "DH-GPIO-I", "", "DH-GPIO-A", "";
>>>>>>>> +};
>>>>>>>> +
>>>>>>> [...]
>>>>>>>
>>>>>>> We have been using the GPIO names at DH electronics for some time and also
>>>>>>> on other SOMs, but have not yet streamed them. We started with the naming
>>>>>>> only with a capital letter "A-W" since then without problems. To avoid a
>>>>>>> hard cut or patching for us and our customers it would be good if we could
>>>>>>> use the same naming in the mainline kernel as well. Marek, we would be
>>>>>>> happy if you would adopt our valued GPIO naming in your patch.
>>>>>>
>>>>>> My counter-argument to this is that the naming should be unique and
>>>>>> provide a hint where those GPIO lines come from, so maybe even DH-GPIO-n
>>>>>> should rather be DHCOM-n . I can't say I'm particularly fond of the
>>>>>> plain 'n' naming of GPIO lines, because then the GPIO label (and e.g.
>>>>>> listing in libgpiod tools) does not give any hint what the GPIO is or
>>>>>> where it comes from. Also, I worry a plain 'n' naming might clash with
>>>>>> other GPIO IPs easily, while a more unique name can not.
>>>>>
>>>>> Hello Marek,
>>>>>
>>>>> after an internal discussion, we decided the following:
>>>>>
>>>>> Could you update the patch for the Avenger96 to the GPIO naming "AV96-n".
>>>>>
>>>>> Moreover for the SOM layer (stm32mp15xx-dhcom-som.dtsi) we would prefer
>>>>> "DHCOM-n". It would be nice if you could create a patch for it.
>>>>
>>>> I don't think we should have any SoM-side gpio-line-names, because once
>>>> you plug the SoM into new carrier board, the gpio-lane-names will no
>>>> longer make sense. So, I think all the gpio-line-names should be
>>>> implemented in the carrier board DTS.
>>>
>>> The idea is to define the GPIO names on the SOM layer and then
>>> overwrite them on the carrier board DTS if needed. If there is no
>>> naming on the carrier board, at least you have access via the DHCOM
>>> GPIO names. The DHCOM GPIO names are standardized, so that you can
>>> be sure that the assignment to a pin always fits.
>>
>> So I'll pose another question here to the GPIO maintainers.
>>
>> Is it OK to define gpio-line-names in SoM DTSI even for pins which will
>> not be used as GPIOs e.g. because they are muxed differently in the
>> carrier board DTS ?
>>
>> If that is OK, then the above approach is then also OK.
> 
> In our case, we cannot mux the GPIO pins in the carrier board DTS
> to another functions, because then we break our SOM standard (DHCOM).

You can, assume you take two of the SoM GPIO-X and GPIO-Y signals which 
are present e.g. on the PDK2 jumper header and connect I2C EEPROM to 
those two pins. Then you mux those two pins as I2C bus. And that happens 
on the carrier board level (or a DTO, but that's out of scope here).

> So in the case we relabel a GPIO in the carrier board e.g. "DHCOM-I"
> becomes "LED1" the mux function have to be GPIO.

In the above example, the mux function becomes i2c in the carrier board 
DT and the gpio-line-names remains the same since its included from the 
SoM DTSI. I would like to know whether this is OK or whether we need to 
patch the gpio-line-names in the carrier board DT and remove the GPIO-X 
and GPIO-Y from the gpio-line-names there.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH] ARM: dts: stm32: Fill GPIO line names on AV96

[Christoph Niedermaier]

From: Marek Vasut <marex@denx.de>
Sent: Monday, March 15, 2021 3:26 PM
> To: Christoph Niedermaier <cniedermaier@dh-electronics.com>; linux-arm-
> kernel@lists.infradead.org; linus.walleij@linaro.org
> Cc: Alexandre Torgue <alexandre.torgue@st.com>; Patrice Chotard
> <patrice.chotard@st.com>; Patrick Delaunay <patrick.delaunay@st.com>;
> Maxime Coquelin <mcoquelin.stm32@gmail.com>; linux-stm32@st-md-
> mailman.stormreply.com
> Subject: Re: [PATCH] ARM: dts: stm32: Fill GPIO line names on AV96
> 
> ACHTUNG: Diese E-Mail kommt aus dem Internet und nicht aus unserem
> Firmennetzwerk!
> 
> 
> 
> On 3/15/21 12:41 PM, Christoph Niedermaier wrote:
> 
> [...]
> 
>>>>>>>>> Fill in the custom GPIO line names used by DH.
>>>>>>>>>
>>>>>>>> [...]
>>>>>>>>> +&gpioa {
>>>>>>>>> +       gpio-line-names = "", "", "", "",
>>>>>>>>> +                         "", "", "", "",
>>>>>>>>> +                         "", "", "", "DH-GPIO-K",
>>>>>>>>> +                         "DH-GPIO-I", "", "DH-GPIO-A", "";
>>>>>>>>> +};
>>>>>>>>> +
>>>>>>>> [...]
>>>>>>>>
>>>>>>>> We have been using the GPIO names at DH electronics for some time and also
>>>>>>>> on other SOMs, but have not yet streamed them. We started with the naming
>>>>>>>> only with a capital letter "A-W" since then without problems. To avoid a
>>>>>>>> hard cut or patching for us and our customers it would be good if we could
>>>>>>>> use the same naming in the mainline kernel as well. Marek, we would be
>>>>>>>> happy if you would adopt our valued GPIO naming in your patch.
>>>>>>>
>>>>>>> My counter-argument to this is that the naming should be unique and
>>>>>>> provide a hint where those GPIO lines come from, so maybe even DH-GPIO-n
>>>>>>> should rather be DHCOM-n . I can't say I'm particularly fond of the
>>>>>>> plain 'n' naming of GPIO lines, because then the GPIO label (and e.g.
>>>>>>> listing in libgpiod tools) does not give any hint what the GPIO is or
>>>>>>> where it comes from. Also, I worry a plain 'n' naming might clash with
>>>>>>> other GPIO IPs easily, while a more unique name can not.
>>>>>>
>>>>>> Hello Marek,
>>>>>>
>>>>>> after an internal discussion, we decided the following:
>>>>>>
>>>>>> Could you update the patch for the Avenger96 to the GPIO naming "AV96-n".
>>>>>>
>>>>>> Moreover for the SOM layer (stm32mp15xx-dhcom-som.dtsi) we would prefer
>>>>>> "DHCOM-n". It would be nice if you could create a patch for it.
>>>>>
>>>>> I don't think we should have any SoM-side gpio-line-names, because once
>>>>> you plug the SoM into new carrier board, the gpio-lane-names will no
>>>>> longer make sense. So, I think all the gpio-line-names should be
>>>>> implemented in the carrier board DTS.
>>>>
>>>> The idea is to define the GPIO names on the SOM layer and then
>>>> overwrite them on the carrier board DTS if needed. If there is no
>>>> naming on the carrier board, at least you have access via the DHCOM
>>>> GPIO names. The DHCOM GPIO names are standardized, so that you can
>>>> be sure that the assignment to a pin always fits.
>>>
>>> So I'll pose another question here to the GPIO maintainers.
>>>
>>> Is it OK to define gpio-line-names in SoM DTSI even for pins which will
>>> not be used as GPIOs e.g. because they are muxed differently in the
>>> carrier board DTS ?
>>>
>>> If that is OK, then the above approach is then also OK.
>>
>> In our case, we cannot mux the GPIO pins in the carrier board DTS
>> to another functions, because then we break our SOM standard (DHCOM).
> 
> You can, assume you take two of the SoM GPIO-X and GPIO-Y signals which
> are present e.g. on the PDK2 jumper header and connect I2C EEPROM to
> those two pins. Then you mux those two pins as I2C bus. And that happens
> on the carrier board level (or a DTO, but that's out of scope here).

This is a very absurd example, because we have I2C on the PDK2 board
and if you want to use I2C use our given I2C buses. We don't want that
a costumer uses a GPIO pin as I2C, because it breaks our SOM standard
(DHCOM) and we cannot exchange the SOM module without breaking the
function. A GPIO is intended to be a GPIO and we don't want to have a
carrier board upstream, that breaks your standard. So if we label the
GPIOs on the SOM layer, it will never be wrong.
 
>> So in the case we relabel a GPIO in the carrier board e.g. "DHCOM-I"
>> becomes "LED1" the mux function have to be GPIO.
> 
> In the above example, the mux function becomes i2c in the carrier board
> DT and the gpio-line-names remains the same since its included from the
> SoM DTSI. I would like to know whether this is OK or whether we need to
> patch the gpio-line-names in the carrier board DT and remove the GPIO-X
> and GPIO-Y from the gpio-line-names there.

In the carrier board the GPIO becomes an input, output, led, button, etc.,
but the function is still GPIO. So the labeling on the SOM layer is never
been wrong. A relabeling on the carrier board then improves it to the real
usage, but it is not mandatory.


Regards
Christoph
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] ARM: dts: stm32: Fill GPIO line names on AV96

[Marek Vasut]

On 3/15/21 7:58 PM, Christoph Niedermaier wrote:
[...]
>>>>>> I don't think we should have any SoM-side gpio-line-names, because once
>>>>>> you plug the SoM into new carrier board, the gpio-lane-names will no
>>>>>> longer make sense. So, I think all the gpio-line-names should be
>>>>>> implemented in the carrier board DTS.
>>>>>
>>>>> The idea is to define the GPIO names on the SOM layer and then
>>>>> overwrite them on the carrier board DTS if needed. If there is no
>>>>> naming on the carrier board, at least you have access via the DHCOM
>>>>> GPIO names. The DHCOM GPIO names are standardized, so that you can
>>>>> be sure that the assignment to a pin always fits.
>>>>
>>>> So I'll pose another question here to the GPIO maintainers.
>>>>
>>>> Is it OK to define gpio-line-names in SoM DTSI even for pins which will
>>>> not be used as GPIOs e.g. because they are muxed differently in the
>>>> carrier board DTS ?
>>>>
>>>> If that is OK, then the above approach is then also OK.
>>>
>>> In our case, we cannot mux the GPIO pins in the carrier board DTS
>>> to another functions, because then we break our SOM standard (DHCOM).
>>
>> You can, assume you take two of the SoM GPIO-X and GPIO-Y signals which
>> are present e.g. on the PDK2 jumper header and connect I2C EEPROM to
>> those two pins. Then you mux those two pins as I2C bus. And that happens
>> on the carrier board level (or a DTO, but that's out of scope here).
> 
> This is a very absurd example, because we have I2C on the PDK2 board
> and if you want to use I2C use our given I2C buses. We don't want that
> a costumer uses a GPIO pin as I2C, because it breaks our SOM standard
> (DHCOM) and we cannot exchange the SOM module without breaking the
> function. A GPIO is intended to be a GPIO and we don't want to have a
> carrier board upstream, that breaks your standard. So if we label the
> GPIOs on the SOM layer, it will never be wrong.

I can see how this could work on SoM level if the muxing requirement is 
constrained like this.

>>> So in the case we relabel a GPIO in the carrier board e.g. "DHCOM-I"
>>> becomes "LED1" the mux function have to be GPIO.
>>
>> In the above example, the mux function becomes i2c in the carrier board
>> DT and the gpio-line-names remains the same since its included from the
>> SoM DTSI. I would like to know whether this is OK or whether we need to
>> patch the gpio-line-names in the carrier board DT and remove the GPIO-X
>> and GPIO-Y from the gpio-line-names there.
> 
> In the carrier board the GPIO becomes an input, output, led, button, etc.,
> but the function is still GPIO. So the labeling on the SOM layer is never
> been wrong. A relabeling on the carrier board then improves it to the real
> usage, but it is not mandatory.

Right, see above.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel