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

[Alexandre Torgue]

On 5/6/20 4:39 PM, Marek Vasut wrote:
> On 5/6/20 4:26 PM, Alexandre Torgue wrote:
>>
>>
>>
>>> 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 ?
>>
>> Yes I have the same point in mind. How to maintain all boards ? Should
>> we refuse some boards and only keep one as example ?
> 
> But which ones do you want to drop? The pdk2 is a devkit , so you can
> put in any SoM option, that's the problem.

Ok but we could choice to build only one (or few) possibilities. I mean 
maybe only mp157 ?


>>> 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.
>>>
>>
>> It is something I discussed with Kevin Hilman at ELCE and sometime with
>> Rob on IIRc. We could use u-boot to handle differences between SoC, and
>> boards. Technically it's possible but the main issue doing that is,  you
>> will hide some updates in your bootloader and then your dtb used by
>> kernel will not reflect your dts file. It could be confused for
>> customers and users.
> 
> Yes.
> 
>>> Any other ideas ?
>>
>> What is for you the main issue ? the number of files to add or how to
>> maintain all those files ?
> 
> The number. Maintaining them is not that much of a problem.

I agree

> 
>> If it is the number of files to add, we can think about several ways:
>>
>> 1-As mentioned above, to only keep kind of reference platforms
>>
>> 2-Have vendor directories in arch/arm/boot/dts (but it's another story
>> to make it accepted)
> 
> Maybe that's something we should consider for arm32, but that's a
> different discussion altogether.

I gonna see how to start discussion on that (maybe thanks to Linaro and 
device tree evolution)


>> 3-Or maybe use DTBO to overwrite some configuration.
>>
>> If the concern is about how to maintain, maybe I'm wrong but I think
>> that with a good split and factorization we could minimize support.
>>
>> Currently I only those things in mind but nothing really mature.
> 
> I hope this patchset does the split right, it's the number.
>