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

[Alexandre Torgue]

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.

regards
alex