[Linux-stm32] [PATCH 01/12] ARM: dts: stm32: Add alternate pinmux for I2C2 pins

Marek Vasut marex at denx.de
Wed May 6 13:37:31 UTC 2020


On 5/6/20 9:46 AM, Alexandre Torgue wrote:
> Hi Marek

Hi,

> On 4/29/20 6:37 PM, Marek Vasut wrote:
>> Add another mux option for I2C2 pins, this is used on AV96 board.
>>
>> Signed-off-by: Marek Vasut <marex at denx.de>
>> Cc: Alexandre Torgue <alexandre.torgue at st.com>
>> Cc: Manivannan Sadhasivam <manivannan.sadhasivam at linaro.org>
>> Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>
>> Cc: Patrice Chotard <patrice.chotard at st.com>
>> Cc: Patrick Delaunay <patrick.delaunay at st.com>
>> Cc: linux-stm32 at st-md-mailman.stormreply.com
>> To: linux-arm-kernel at lists.infradead.org
>> ---
>>   arch/arm/boot/dts/stm32mp15-pinctrl.dtsi | 17 +++++++++++++++++
>>   1 file changed, 17 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
>> b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
>> index aeddcaadb829..ca4edcf369d0 100644
>> --- a/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
>> +++ b/arch/arm/boot/dts/stm32mp15-pinctrl.dtsi
>> @@ -408,6 +408,23 @@ pins {
>>           };
>>       };
>>   +    i2c2_pins_c: i2c2-4 {
>> +        pins {
>> +            pinmux = <STM32_PINMUX('F', 1, AF4)>, /* I2C2_SCL */
>> +                 <STM32_PINMUX('H', 5, AF4)>; /* I2C2_SDA */
>> +            bias-disable;
>> +            drive-open-drain;
>> +            slew-rate = <0>;
>> +        };
>> +    };
>> +
>> +    i2c2_pins_sleep_c: i2c2-5 {
> 
> should be i2c2-sleep-4. I'll fix it directly when I'll merge.

All right, thanks.

btw I had this internal discussion now about handling the combinatorial
explosion of board DTs here. If we support them all, by the end of the
lifespan of these devices, we end up with:

STM32MP15{1,3,7}{a,c,d,f} SoM rev. {0..7}00 on baseboard rev. {0..7}00.

There won't be every SoM and baseboard revision combination all right.
But even the amount of SoM options gives me 12 DTs. That is not a low
number. Does ST have some plan to handle such situation ?

I can imagine that U-Boot can patch the DT and enable/disable
functionality , which could handle the {a,c,d,f} options and reduce the
amount of DTs. It could possibly also handle the {1,3,7} options.

Any other ideas ?



More information about the Linux-stm32 mailing list