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

[Alexandre Torgue]

On 3/31/20 3:38 PM, Marek Vasut wrote:
> 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 ?
> 

Sorry but what would the advantage to do so ?