Hi Antonin, On Wed, 04 Mar 2026 09:01:20 +0100 "Antonin Godard" <[email protected]> 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 <[email protected]> wrote: > > > >> On Mon, Mar 02, 2026 at 02:03:44PM -0500, Hugo Villeneuve wrote: > >> > From: Hugo Villeneuve <[email protected]> > >> > > >> > 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
