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

[Marek Vasut]

On 5/6/20 4:55 PM, Alexandre Torgue wrote:
> 
> 
> 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 ?

But that one isn't gonna work for e.g. 153 then, would it?

>>>> 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)

All right.