My goal is to get a Display working with my TorizonOS based i.MX8MP, but due to my limited Device Tree Experience, I’m a bit stuck. Our setup is as follows:
i.MX8MP with TorizonOS 7.1.0. and a working Slint application (Tested with HDMI using the preinstalled HDMI overlay), which should output via MIPI to a connected FPD Serializer (https://www.ti.com/product/DS90UB941AS-Q1), then Deserializer (https://www.ti.com/product/DS90UB926Q-Q1) and in the end RGB display:
What I did until now was I enabled the verdin-imx8mp_dsi-to-lvds_panel-cap-touch-10inch-lvds_overlay.dtbo, and then I was able to see the MIPI data lines active, but the MIPI clock line shows nothing at all.
Following up on that, I now want to use a custom overlay, but as mentioned have not really much experience with it and do not know what is even needed. Does the Linux need to know that there is a serializer/deserializer in between? Do I really need to specify the display in the end of the chain, or does MIPI just fire-and-forget?
My guess is that I need to specify something instead of the lvds_ti_sn65dsi84 bridge, and then the correct panel (I guess I should already see the pixel clock without this?)
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?
Hello Tim,
Thank you for reaching out with your question about configuring a display on the Verdin i.MX8MP with TorizonOS. Let’s go through the steps to help you set up your display using Device Tree Overlays.
Device Tree Overlays: These are used to modify the device tree without recompiling the entire kernel, which is ideal for customizing hardware configurations like display interfaces.
Serializer/Deserializer Configuration: Generally, the Linux kernel does not need to be explicitly aware of the serializer/deserializer (DS90UB941AS-Q1 and DS90UB926Q-Q1) unless they require specific configuration or initialization. These components typically act as transparent data conduits. However, ensure any necessary configurations, such as I2C settings, are handled either in the device tree or through user-space utilities.
Custom Overlay Creation: Since you have a custom display setup, creating a custom device tree overlay is necessary. This involves:
Defining the MIPI DSI interface in the device tree.
Specifying the data lanes and any necessary bridge components.
Configuring the final display panel with the correct timings and resolutions.
Display Panel Configuration: Ensure the display panel’s timing parameters (e.g., hsync, vsync, pixel clock) are correctly specified in the device tree. These should match the specifications provided in the display’s datasheet.
Testing the Configuration: After deploying your custom overlay, reboot the system and verify the display output. You can use tools like modetest from the libdrm-tests package to check the display configuration and ensure that the system recognizes the display.
By following these steps, you should be able to configure your display setup on the Verdin i.MX8MP. If you encounter issues, double-check the connections and ensure that all components are correctly configured in the device tree.
I hope this helps you get your display up and running smoothly!
Best regards,
Toradex AI Assistant
Please, also check if these links can help you solve your problem:
I’m fairly certain that I only need to specify the MIPI/DSI output and the panel, but I am running into the following error during boot: imx_sec_dsim_drv: probe of 32e60000.mipi_dsi failed with error -2
so there seems to be some issue still with DRM not recognizing the panel i defined (panel-simple).
When running a weston container for example, the logs mention that no drm device found → but in /dev/dri/ at least I see the cardo (which is from imx-drm)
I have some experience in this area, not with ds90ub941 but with sn65dsi86 ( mipi to eDP) interface to a different processor , but similar principles would apply.
Youll need a driver for the FPDLink serialiser IC , check the latest kernel source from kernel.org or ask TI.
In the device tree there needs to be a kind of chain, LCDIF->BRIDGE->FPD link, no LCD panel definition was required just a generic panel
I found the device trees included in the kernel source helped a bit to understand how it works in principle but a fair amount of try and debug was needed.
What I’m wondering now is if I do not need to interact with the bridge via I2C (in the case I can just use it’s defaults), is it enough to specify a generic panel for MIPI? I guess that with the panel-simple driver, this should work? (see the last device tree i posted)
Or where exactly should the generic panel then be defined?
If you search the TI support forums for DS90UB941 you’ll see many posts
For the DSI86 there was no need to define the panel at all , the endpoint was a Displayport connector as shown below.
But Displayport has an I2C channel which is used to communicate the EDID paramter set of the display and then the DRM layer has an function that decides what display resolutions are possible based on the MIPI DSI clock system available frequencies and error margin.
The FPD-Link III interface supports full duplex control, including I2C and SPI communication, over the same differential link, so there should be a way to communicate panel parameters over the FPD Link. TI has a newer device DS90UH981-Q1 which has more features for this.
For DS90UB941 since theres no driver you may need to create a panel driver much like a standard MIP-DSI LCD panel driver , there are many examples online.
And then manually configure the DS90UB941 using the I2C port as the TI forum posts describe
I don’t have any further comments since I’ve never used this IC myself, so my knowledge about it is probably the same as yours. For in-depth questions on this IC you may need to reach out to TI about the specifics of getting it setup.
For our DSI to LVDS overlay you can see everything has driver support in the Linux kernel by default. This makes it relatively simple to define them in the device tree and create the link from mipi dsi → sn65dsi84 bridge → generic LVDS panel.
If I pretend to not have any ser/deser (I do not need to make any configurations there…) in between and I want to add a “dummy” panel to my MIPI output, how would that work?
Similar to how I now have my DT set up?
So the equivalent to the &panel_lvds from the DSI to LVDS overlay, but without the bridge in between.
As far as I understand, that is why this panel-simple exists in the first place, but it is not working for me…
If I pretend to not have any ser/deser (I do not need to make any configurations there…) in between and I want to add a “dummy” panel to my MIPI output, how would that work?
Similar to how I now have my DT set up?
Without having ever worked on it, I’m not really sure how that would work. From an abstraction point of view with a bridge it’s clear how that makes sense. The mipi dsi node outputs dsi signals which the sn65dsi84 bridge accepts and outputs an LVDS signal to the lvds panel driver. In this chain everything gets the expected input it wants.
In your theoretical abstraction we would just have the mipi dsi outputting dsi signal straight to the rgb panel driver, which I imagine the driver would be confused about. Of course on the hardware level you do have the ser/deser in-between. But the software level the system would not know anything about that, since there’s nothing explicit in the device tree to tell it so.
I would need to see if I can find anything on this topic as my knowledge on this is limited.
If I was tackling this , I would first get the RGB panel connected via a MIPI-DSI to RGB converter to the iMX8 mipi port and get it going, then attempt to add the FPDLink.
You can also decompile the Device tree Binary using the device tree compiler to check if it has all the elements needed. I found dtc can exclude elements from overlays without warning if your syntax isn’t 100% compliant, maybe theres a way to make it generate warnings.
we were able to get a MIPI DSI output, so Linux recognized it as a DSI panel. The relevant settings are in a panel_desc_dsi struct in panel-simple.c. However, there are only certain panels defined and we obv. can’t overwrite the parameters there with overlays, I guess the only way is to then make a patch and a custom yocto build, which we would like to avoid… (we use torizoncore builder).
Or do you see any other way to add our settings into the driver?
Basically any of these (also from panel-simple.c):
Or do you see any other way to add our settings into the driver?
Well the DSI panel abstraction doesn’t have a generic compatible since DSI displays aren’t really generic in their design and usually require their own specific logic/driver to operate. As opposed to lvds and rgb panels which have the panel-lvds and panel-dpi compatibles respectively that allow you to provide generic display timing values.
Then connect this node directly to the mipi_dsi node via the port endpoint properties. That said we’re not entirely sure if any panel type node can be connected directly to the mipi_dsi node even if the panel does not describe a dsi panel. This is all assuming of course the hardware side of things is properly configured and setup.
One other note, you mentioned you do at least get DSI output on the hardware side. In Linux with any of your device tree configurations are there any logs coming from the DSI/display subsystems in dmesg? Maybe there’s a hint there.
In most cases I have seen the best way is to create your own panel driver in /drivers/gpu/drm/panel and add it to the makefile and Kconfig so that you can select it when doing a kernel configuration using menuconfig.
You would then add it to the device tree using for example compatible = “leadtek,ltk050h3123w-qc03”;
The who dsi definition would look something like this - maybe slightly different for IMX8:
I have the following output (with the panel described as my comment above):
torizon@verdin-imx8mp-15337625:~$ dmesg | grep -E 'drm|dsi|mipi|panel'
[ 0.059473] platform 32e60000.mipi_dsi: Fixed dependency cycle(s) with /soc@0/bus@32c00000/lcd-controller@32e80000
[ 0.059723] platform 32e60000.mipi_dsi: Fixed dependency cycle(s) with /soc@0/bus@32c00000/lcd-controller@32e80000
[ 0.059820] platform 32e80000.lcd-controller: Fixed dependency cycle(s) with /soc@0/bus@32c00000/mipi_dsi@32e60000
[ 4.221642] Kernel module loaded from ramdisk: sec_dsim - result: 0
[ 4.246999] imx-drm display-subsystem: bound imx-lcdifv3-crtc.0 (ops lcdifv3_crtc_ops)
[ 4.255064] imx_sec_dsim_drv 32e60000.mipi_dsi: version number is 0x1060200
[ 4.262664] imx-drm display-subsystem: bound 32e60000.mipi_dsi (ops imx_sec_dsim_ops [sec_mipi_dsim_imx])
[ 4.272885] [drm] Initialized imx-drm 1.0.0 20120507 for display-subsystem on minor 0
[ 4.283162] imx-drm display-subsystem: [drm] fb0: imx-drmdrmfb frame buffer device
[ 4.360998] Kernel module loaded from ramdisk: sec_mipi_dsim_imx - result: 0
[ 4.372724] Kernel module loaded from ramdisk: ti_sn65dsi83 - result: 0
[ 7.537621] systemd[1]: Starting Load Kernel Module drm...
[ 7.798847] [drm] Initialized vivante 1.0.0 20170808 for 40000000.mix_gpu_ml on minor 1
and on the hardware end, we can see the clock and data. But of course now the settings are the ones from "lg,lh500wx1-sd03" (in panel-simple.c)
I think the dmesg output looks quite ok, but as mentioned, without having to touch the kernel driver itself (and therefore ditching TorizonCore builder etc.), we can’t set our own panel settings.
and on the hardware end, we can see the clock and data. But of course now the settings are the ones from "lg,lh500wx1-sd03" (in panel-simple.c)
My question here, and I’m not entirely sure myself. In the device tree if you specify timings for a DSI panel. When the signal goes through the serializer/deserializer hardware, would the timing signals be correct for your RGB display at the end?
This is assuming you have the settings/timings for your display.
I think the dmesg output looks quite ok, but as mentioned, without having to touch the kernel driver itself (and therefore ditching TorizonCore builder etc.), we can’t set our own panel settings.
Well in theory, you could create a separate new out-of-tree driver for your display settings and that would work with TorizonCore Builder. Though creating such a standalone driver is arguably more complex than just modifying the already existing driver code. Again though this is usually the case when defining new DSI panel timings in Linux.
I’m still curious if it’s possible to connect a RGB/LVDS panel in the device tree to the mipi_dsi node and have that work. Since RGB/LVDS panels allow one to specify custom display timings unlike the DSI panel abstraction.
