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

[Marek Vasut <marex@denx.de>]

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