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

[Alexandre Torgue]

On 5/6/20 4:58 PM, Marek Vasut wrote:
> 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?

No but we could let user of 153 do his own dts by hand. With a good 
split is not difficult to do.

For e.g I don't plan to upstream stm32mp153c-dk2 (I don't know if it 
really exist), but user could easily create his own stm32mp153c-dk2.dts 
by assembling well dtsi files and taking stm32mp157c-dk2 (or dk1) as 
example.

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