[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