[Linux-stm32] [PATCH 07/22] ARM: dts: stm32: Add alternate pinmux for SDMMC2 pins 4-7
Marek Vasut
marex at denx.de
Mon Mar 30 11:45:30 UTC 2020
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.
--
Best regards,
Marek Vasut
More information about the Linux-stm32
mailing list