Re: [PATCH v4 00/13] ARM: dts: imx6ul: Add Variscite VAR-SOM-6UL and DART-6UL

[Stefano Radaelli <stefano.radaelli21@gmail.com>]

On Tue, Sep 29, 2026 at 12:14:55PM -0400, Hugo Villeneuve wrote:
> Hi Stefano,
> 
> Your title seems to imply that VAR-SOM-6UL support did not
> exist before your patch, but it did. Please rephrase that, and
> your description accordingly.
> 

Hi Hugo,
You’re right that VAR-SOM-6UL already has mainline support.
I’ll reword the title and description to distinguish the existing
support from the new variants and DART-6UL boards.

> 
> On Tue, 29 Sep 2026 17:17:27 +0200
> Stefano Radaelli <stefano.radaelli21@gmail.com> wrote:
> 
> > Add device trees for Variscite VAR-SOM-6UL and DART-6UL modules based on
> > i.MX6UL, i.MX6ULL and i.MX6ULZ. VAR-SOM-6UL is supported on the
> > Concerto-Board and Symphony-Board carriers, and DART-6UL on the
> > VAR-6ULCustomBoard. The 90 new DTBs cover the supported combinations of
> > storage, wireless and audio options.
> 
> Do they? You would need far more than 90 DTBs to support all options...
> 
> When I submitted the latest changes for the VAR-SOM-6UL, I did not
> create DTBs for every available options knowing that it would lead to
> an insane number of files. So I simply created a full DTB that
> incorporated most of the DTSI options. And my custom boards simply
> include only the required DTSI for their specific options.
> 
> Looking simply at the ENET phy level, you seem to have now removed
> the two individual DTSI to selectively add support for ENET1 and ENET2,
> but not all board use these, so that is why they
> were created as individual DTSI files in the first place to make it
> easier to create a DTB with only the required options. As an example,
> one of my custom boards do not have ethernet at all, so i don't want
> that support enabled by default.
> 
> Please keep the existing DTSI as distinct and individual files.
> 
> Maybe using DT overlays would be better suited if you really want to
> support every available combinations?
> 

Just to be clear about the 90 DTBs: They are the minimum set of prebuilt
DTBs for the Variscite-supported configurations that select between
mutually exclusive hardware alternatives. Selecting an alternative changes
the hardware described on a SoM interface and therefore requires changes
to Device Tree nodes, pin configuration or controller properties.
For example, the SD interface may connect to an SD card or an SDIO wireless
module; storage, wireless-module and codec choices similarly require
different descriptions.

These are not every possible combination of fitted and unfitted components.
We do not add another DTB merely because an optional peripheral is not
populated.
This follows the existing VAR-SOM-MX7 mainline approach: it provides
separate DTBs for hardware choices such as eMMC versus NAND and codec
variants, without enumerating every optional component’s presence or
absence.

> 
> > The descriptions use shared module, option and carrier DTSI files with
> > SoC-specific wrappers. In particular, the WM8904 and WM8731 codecs are
> > selected explicitly instead of keeping a codec in the module base.
> > The four existing Concerto DTBs are converted to this layout without
> > changing their DTB names or compatible strings. This also replaces the
> > non-working legacy LVDS panel description with the LCDIF configuration
> 
> Can you describe what exactly is not working? When I submitted these
> LVDS changes I tested the LVDS panel with the Variscite concerto EVK
> (VAR-SOM-6UL LD option) and it was working ok (also tested with two
> custom boards).
> 
> If a fix is needed for this bug, this should go in a separate patch.
> 

In an initial hardware test, the display timing behavior did not appear
to match what we observe with Variscite’s downstream configuration.
I will repeat the test and measure the output before proposing any display
change. If a fix is needed, I will send it as a separate patch.

> 
> > for the Variscite display. Wi-Fi and Bluetooth enable/reset sequencing
> > on these modules is handled by userspace, so the legacy kernel-managed
> > power-sequence and Bluetooth nodes are not carried forward.
> 
> That is not ok. I specifically implemented enable/reset sequencing in
> the kernel to finally get rid of the need for external
> proprietary userspace scripts, and it was tested ok. If somethings needs
> to be fixed or improved in this sequencing, fine if you submit a patch
> to do it, but certainly do not get rid of it.
> 

Calling these “external proprietary userspace scripts” misses their purpose.
First because they are not proprietary :D. Second, because they implement
the initialization procedure Variscite validates for the Broadcom
modules we ship (talking about the brcm, the existing one in your DTSs)
folowing the datasheet instructions.

This is not equivalent to the sequence in the existing Concerto DT.
For the LWB5 option, the procedure enables WIFI_PWR, waits 10 ms,
enables WLAN_EN and BT_EN, waits 200 ms, then lowers BT_EN before
re-enumerating the SDIO device.
The other Broadcom option does not use the separate WIFI_PWR step.
The existing regulator and MMC power-sequence nodes do not express that
complete, module-dependent procedure, particularly the BT_EN step during
Wi-Fi initialization.
The scripts also select the Bluetooth firmware according to the detected
SDIO device.

We use that procedure to avoid sequencing-related failures for our
customers.
This approach is not new to Variscite’s mainline DTS files.

Thank you for your time,
Best Regards,
Stefano