Re: [PATCH 08/14] ARM: dts: imx6ul-var-som: factor out SD card support

[Hugo Villeneuve <hugo@hugovil.com>]

Hi Antonin,

On Wed, 04 Mar 2026 09:01:20 +0100
"Antonin Godard" <antonin.godard@bootlin.com> wrote:

> Hi,
> 
> On Mon Mar 2, 2026 at 10:15 PM CET, Hugo Villeneuve wrote:
> > Hi Frank,
> >
> > On Mon, 2 Mar 2026 15:54:43 -0500
> > Frank Li <Frank.li@nxp.com> wrote:
> >
> >> On Mon, Mar 02, 2026 at 02:03:44PM -0500, Hugo Villeneuve wrote:
> >> > From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> >> >
> >> > Move SD support to a separate include, since it cannot be used at the
> >> 
> >> s/include/dtsi/
> >
> > Ok. I will also change it in all the other commit messages.
> >
> >  
> >> > same time as the Wifi/BT module.
> >> 
> >> what's relation ship between wifi/bt? you just move sd related part to a
> >> dtsi file.
> >
> > As stated in commit message, the SD card interface cannot be used if
> > the Wifi/BT module is in use.
> >
> > Sd card is not mandatory, for example on our board we do not have it,
> > so we need to have it disabled.
> 
> My two cents: if SDCard and WiFi/Bt support are the only mutually exclusive
> features for this SoM, then how about the following organization:

They maybe are not. There are other peculiarities, for example using the
touch panel configuration has some impacts on an oscillator used by the
Wifi/Bt module. The Varisctite documentation is not entirely clear or
evident about all these details.


> Three SoM dtsi files:

This is already the case (apart from the -bt suffix)?

> 
> imx6ul-var-som-common.dtsi
> 
>   imx6ul-var-som-wifi-bt.dtsi:
>     #include "imx6ul-var-som-common.dtsi"

No need to include it, as it is already included by
imx6ul-var-som-concerto.dts

> 
>   imx6ul-var-som-sd.dtsi:
>     #include "imx6ul-var-som-common.dtsi"

Same...

> 
> A common concerto dtsi file:
> 
>   imx6ul-var-som-concerto-common.dtsi
> 
> Separate concerto dts files:
> 
>   imx6ul-var-som-concerto-wifi-bt.dts:
>     #include "imx6ul-var-som-wifi-bt.dtsi"
>     #include "imx6ul-var-som-concerto-common.dtsi"
> 
>   imx6ul-var-som-concerto-sd.dts
>     #include "imx6ul-var-som-sd.dtsi"
>     #include "imx6ul-var-som-concerto-common.dtsi"
> 
> And possibly the following one to avoid breaking compatibility:
> 
>   imx6ul-var-som-concerto.dts
>     #include "imx6ul-var-som-sd.dtsi"
>     #include "imx6ul-var-som-concerto-common.dtsi"
> 
> In any case, the imx6ul-var-som-concerto-common.dtsi should be full-featured
> (and thus avoid the imx6ull-var-som-concerto-full.dts file from patch 09/14), if
> that's possible?

I am not convinced that it needs to be full-featured. For our custom
boards, we want to include only the relevant dtsis, because for example
we do not use sd, or enet1 or enet2, or audio. Having these options in
separate dtsi allows our custom boards to include/enable only the
required features.

The full dts is only there as a reference, and to make sure all dtsi
are included and therefore compiled-checked. In it I have enabled
enet1 and enet2, but some boards may use enet1, and not enet2, or
vice-versa, or some boards (like our custom boards) we are not using
either one.

> But I don't know if this follows common practices, and if this is possible, but
> I think it's clearer as a user to know if the DTS I will use will support
> WiFi/BT _or_ support SDCard by looking at its name.
> 
> Of course this is based on the assumption that those two features are the only
> mutually exclusive ones.
> 
> What do you think?

Yes, but there is an exponential number of different
combinations, and thus would require a lot of different DTS...

If you look at the Variscite git repos, you will see a lot of different
DTS to support only a subset of the possible combinations, and it
already looks like a mess to me :) I would like to keep things simple if
possible.

-- 
Hugo Villeneuve