[Linux-stm32] [PATCH 07/22] ARM: dts: stm32: Add alternate pinmux for SDMMC2 pins 4-7

[Marek Vasut]

On 3/31/20 10:58 AM, Alexandre Torgue wrote:
> 
> 
> On 3/30/20 1:45 PM, Marek Vasut wrote:
>> On 3/30/20 1:37 PM, Ahmad Fatoum wrote:
>>> Hi Marek,
>>
>> Hi,
>>
>>> On 3/30/20 1:22 PM, Marek Vasut wrote:
>>>> On 3/30/20 1:17 PM, Ahmad Fatoum wrote:
>>>>> Hello Patrice,
>>>>
>>>> Hi,
>>>>
>>>>> On 3/30/20 1:11 PM, Patrice CHOTARD wrote:
>>>>>> For your information, another submitted patch uses the same
>>>>>> pinctrl sdmmc2_d47_pins_b node with different muxing (SDMMC2_D5)
>>>>>>
>>>>>> see https://lore.kernel.org/patchwork/patch/1216452/
>>>>>>
>>>>>> I haven't checked other muxing if there are other conflict.
>>>>>
>>>>> (author of linked patch here)
>>>>>
>>>>> I don't like the central stm32mp15-pinctrl.dtsi. I'd have preferred
>>>>> if each
>>>>> file defined the pinctrl groups it is using.
>>>>
>>>> I'm not a big fan of that either, because this is gonna be a
>>>> combinatorial explosion of various pinmux options. But if you have each
>>>> board define it's pinmux, it's also gonna become a massive amount of
>>>> duplication (like iMX). So I cannot tell which one is better ...
>>>
>>> Mhm. A middle ground could be keeping stm32mp15-pinctrl, but only for
>>> the
>>> official ST eval kits as HW designers are expected to copy off those
>>> and have
>>> board specifics in the board/SoM device tree?
>>
>> Then you should call it stm32mp1-something-st-eval-pinmux.dtsi ,
>> otherwise it's gonna be confusing.
>>
>>> If it has to be either one or the other, I prefer duplication in the
>>> device
>>> tree. When the HW misses pull ups or needs to adjust slew rates, you
>>> probably
>>> don't want a new, slightly different, pinctrl group in the
>>> stm32mp15-pinctrl.dtsi
>>> for each variant.
>>
>> That's a valid point, but then you can override those in the boards'
>> pinmux node for a specific pinmux entry too.
>>
>>> So you are left with doctoring around with overrides and
>>> /delete-property/,
>>> while just duplicating the node with the correct properties would've
>>> been
>>> better for readability IMO.
>>
>> That is true, but how many of such cases do we have so far ? Maybe it's
>> better to cross that bridge when (if) we come to it.
>>
> 
> I agree, and I prefer to keep pins groups definition in
> stm32mp15-pinctrl.dtsi file. IMO, it is easier for users to find them in
> only one file. Actually, I already had this discussions with some guys
> "where pins groups have to be defined ?". For me (and maybe only for
> me), muxing is SOC dependent, I mean SoC provides a bunch a possible
> pinmux for each IPs. If we got enough memory spaces (and time to waste
> also) we could define all possible pinmux (AFx....) for each devices and
> let board users chose the good one (using stm32mp15-pictrl.dtsi as a
> database). In board file, you select one possible pin configuration
> (provided by the SoC) for your device according to your schematic.
> However you could append pin groups in board file to update bias,
> slewrate ...
> If your concern it to embed a bunch of not used pin configuration for a
> board, we could use /omit-if-no-ref/ tag on pin groups.

Can we instead define pinmux the way e.g. iMX6 does , as separate pins ,
instead of pinmux groups ?