[Linux-stm32] [PATCH] [RFC] ARM: dts: stm32: Add DTs for STM32MP15x variants of the DH SOM and PDK2

[Marek Vasut]

On 3/24/20 4:17 PM, Alexandre Torgue wrote:
> 
> 
> On 3/24/20 3:58 PM, Marek Vasut wrote:
>> On 3/24/20 3:39 PM, Alexandre TORGUE wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Marek Vasut <marex at denx.de>
>>>> Sent: mardi 24 mars 2020 15:31
>>>> To: Alexandre TORGUE <alexandre.torgue at st.com>; linux-arm-
>>>> kernel at lists.infradead.org
>>>> Cc: Maxime Coquelin <mcoquelin.stm32 at gmail.com>; Patrice CHOTARD
>>>> <patrice.chotard at st.com>; Patrick DELAUNAY
>>>> <patrick.delaunay at st.com>; linux-
>>>> stm32 at st-md-mailman.stormreply.com
>>>> Subject: Re: [PATCH] [RFC] ARM: dts: stm32: Add DTs for STM32MP15x
>>>> variants
>>>> of the DH SOM and PDK2
>>>>
>>>> On 3/24/20 3:28 PM, Alexandre Torgue wrote:
>>>>>
>>>>>
>>>>> On 3/24/20 3:15 PM, Marek Vasut wrote:
>>>>>> On 3/24/20 3:07 PM, Alexandre Torgue wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 3/24/20 2:22 PM, Marek Vasut wrote:
>>>>>>>> On 3/24/20 2:04 PM, Alexandre Torgue wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 3/23/20 3:31 AM, Marek Vasut wrote:
>>>>>>>>>> The DH PDK2 can be populated with SoM with any STM32MP15x
>>>>>>>>>> variant.
>>>>>>>>>> Add the DTs describing the remaining combinations.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Marek Vasut <marex at denx.de>
>>>>>>>>>> Cc: Alexandre Torgue <alexandre.torgue at st.com>
>>>>>>>>>> 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
>>>>>>>>>> ---
>>>>>>>>>> NOTE: Is there a better way to do this than to have this kind of
>>>>>>>>>> a
>>>>>>>>>>        combinatorial explosion of DTs ?
>>>>>>>>>
>>>>>>>>> I have no better idea. Question was the same for stm32 boards, and
>>>>>>>>> I chose to take this option.
>>>>>>>>
>>>>>>>> One option would be to just have DT for the most feature-complete
>>>>>>>> option
>>>>>>>> (157) and then have U-Boot remove the nodes for HW which is not
>>>>>>>> present on the particular SoC option if it's one of the more
>>>>>>>> limited ones (153, 151).
>>>>>>>>
>>>>>>>
>>>>>>> Yes it was a possibility that I discussed with kevin H. at the
>>>>>>> latest ELCE but at the end the best way to follow was to enhance
>>>>>>> number of dts files. The best would be to have dedicated folders but
>>>>>>> it is another story.
>>>>>>
>>>>>> Or use DT overlays somehow ? U-Boot can apply DTOs onto DT before
>>>>>> booting Linux.
>>>>>>
>>>>>> Having tons of DTs on a system is a lot of duplication, I don't
>>>>>> really like that.
>>>>>
>>>>> I agree that to maintain it's a nightmare, but it's a way to help
>>>>> DT users.
>>>>>
>>>>>>
>>>>>> But for starters, feel free to review this patch.
>>>>>>
>>>>>
>>>>> Your patch sounds good.
>>>>
>>>> Then feel free to apply it, thanks.
>>>>
>>>> btw don't you have a "next" tree somewhere with all the patches
>>>> queued up for
>>>> next release ? If I rebase on linux next, I still have quite a few
>>>> stm32mp1 DT
>>>> patches in my tree which are presumably applied, but I don't see
>>>> them in linux next.
>>>
>>>
>>> Yes but it is not merged into Linux-next. See:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git
>>>
>>> Branch stm32-next
>>
>> Thanks. Wouldn't it be more convenient and receive more testing if it
>> were to be merged into next, just like the other trees are ?
>>
> I completely agree with you! Other arm trees are merged ?

Seems like iMX stuff keeps landing in next, which is nice.