MIPI-DSI display on imx8qxp

Hello,

we have Colibri iMX8QXP on a custom carrier board. Mipi display is connected using X2 FFC. To start with, I am using the Toradex reference linux image (5.0.0) with multimedia capabilities.

I am getting only backlight on the display. Nothing is listed under /sys/class/drm except card0, renderD128, version so I feel it is not detected by Linux at all. What steps do I have to follow to get it working? Device tree modifications, custom driver?

Display in question:
https://www.data-modul.com/sites/default/files/products/COM%2043H4N10ULC_specification_12015179.pdf

Thanks in advance!

More info:

It uses HX8363-A driver chip, so that lead me to the mxcfb_hx8363_wvga.c driver. How can I use that with imx8 (DRM)? Any tips getting us forward appreciated!

Hi @stuo,

The reason why this display is not working is because it’s not enabled or configured in the device-tree for a proper operation. Normally a display will require specific setup of timings for its proper operation.

Here is a list of known Toradex Supported Displays for your knowledge.
You’ll find an example on how to setup a MIPI display on the node “panel_dpi” at imx8qxp-colibri-eval-v3.dtsi file at our BSP/Linux Kernel sources.

Here is a detailed information about the mipi-dsi device-tree bindings on Linux Kernel.

And here in the NXP Forum I managed to find a post in which another developer managed to make the display COM43H4N10ULC working for the iMX6.
You may have to follow a similar path in order to make it work for the Colibri iMX8X, so, configuring the Device Tree for that display. This information may be useful for you.

I found here also a discussion of the dt-binding of “Xingbangda XBD599 panel” being also similar as “himax,hx8363”.

I hope it helps.

Best regards, André Curvello

Hi, thanks for answer!

is panel_dpi the right place to look in the device tree? DPI sounds like it refers to something else than mipi DSI?

In that NXP forum post, they are using the mxcfb_hx8363_wvga.c driver. It is a fbdev driver that iMX8 doesn’t support, or does it work with DRM’s fbdev emulation automatically?

What could be the reason that I get backlight with toradex_5.4-2.1.x-imx kernel line, but not with toradex_4.14-2.3.x-imx? Has there been some changes in device tree?

Hi @stuo,

is panel_dpi the right place to look in the device tree? DPI sounds like it refers to something else than mipi DSI?

See the “Device Tree Node” reference for display usage on Colibri IMX8X here - Display Output, Resolution and Timings (Linux).

In that NXP forum post, they are using the mxcfb_hx8363_wvga.c driver. It is a fbdev driver that iMX8 doesn’t support, or does it work with DRM’s fbdev emulation automatically?

What can you say about this @marcel.tx?

What could be the reason that I get backlight with toradex_5.4-2.1.x-imx kernel line, but not with toradex_4.14-2.3.x-imx? Has there been some changes in device tree?

About the backlight in your case, hard to tell. Any inputs in this situation, @stefan.tx / @jeremias.tx ?

Best regards,
André Curvello

I checked the Display Output, Resolution and Timings (Linux) wiki page, but the table has only parallel RGB, DSI-to-HDMI adapter, and LVDS information. I want to use MIPI-DSI, so I don’t think any of those are applicable, or are they?

@stuo, sorry if the information seemed confuse.

I checked internally and we are working in the list/table of MIPI-DSI for Colibri iMX8X, but it shall support it.

I don’t know if you are already aware of it, but we are adopting the approach of “Device Tree Overlays”, which are portions of Device Tree that activates custom features. This has been our approach for activating displays for both TorizonCore 5 and Embedded Linux (BSP).

As you already know the driver for the display you want to use (mxcfb_hx8363_wvga.c), you can base in a similar display for your case, creating a Device-Tree Overlay for it.

Take for example this overlay for the raydium,rm67191: imx8dx-mek-dsi-rm67191.dts « freescale « dts « boot « arm64 « arch - linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules

In this section of the Device Tree Overlay, it’s configuring the raydium,rm67191 as a panel:

&mipi0_dsi_host {
	status = "okay";
	fsl,clock-drop-level = <2>;

	panel@0 {
		#address-cells = <1>;
		#size-cells = <0>;

		compatible = "raydium,rm67191";
		reg = <0>;
		reset-gpios = <&pca9557_a 6 GPIO_ACTIVE_LOW>;
		dsi-lanes = <4>;
		video-mode = <2>;
		width-mm = <68>;
		height-mm = <121>;

		port@0 {
			reg = <0>;
			panel0_in: endpoint {
				remote-endpoint = <&mipi0_panel_out>;
			};
		};
	};

	ports {
		/delete-node/ port@1;

		port@1 {
			reg = <1>;
			mipi0_panel_out: endpoint {
				remote-endpoint = <&panel0_in>;
			};
		};
	};
};

The driver for this display is available here in the Linux Kernel Sources: drivers/gpu/drm/panel/panel-raydium-rm67191.c

I’d like to suggest you to read our guides about Device Tree Overlay.

Best regards,
André Curvello

Hi, thanks for answer! This helped me to get a little forward. I wrote a driver based on panel-raydium-rm67191.c. Now I’m struggling with the device tree.

The example you posted seems to be made for some imx8dx-mek board, am I right? I found &mipi0_dsi_host node also in imx8qxp-colibri.dtsi file, so I thought I paste the node there. I changed the compatible string based on my own driver. How do I find what is the reset-gpio for this board? I only know it is SODIMM 87 (I guess?). Do I need to change something in the port@0 or ports sections?

Thanks!

Hi @stuo,

Yes, the imx8dx-mek is another board, just taken as reference as it’s resources are in the Linux Kernel mainline.

For Toradex X2 FCC, please have a look at the pinout mentioned here:
Colibri iMX8X Datasheet - Page 19, Section “3.3 MIPI/DSI and LVDS FFC Pin Assignment

For the reset-pin, that will depend on your driver, and probably that will be set with a dedicated GPIO, apart from the MIPI/FFC connector.

See here an example of using a MIPI DSI-HDMI adapter with our Colibri iMX8X at our git repository. It uses the “lontium,lt8912” module, which is controlled by I2C and used as an endpoint for MIPI.
In this example, there is no reset pin :slight_smile:

Best regards,
André Curvello

The driver gets the reset pin from the device tree. Our carrier board has the colibri imx8qxp SODIMM 87 (nRESET out) connected to the reset of the panel. The colibri device trees do not have this pin anywhere. In fact, it is completely skipped. I can find pins 86 and 88 and many others. Is there some reason for this? Is nRESET out wrong choice? This pin is also skipped in the datasheet function list (4.4.1), does it mean it cannot be used in device tree?

Hi @stuo,

Well, the reason why this signal is not on the Device Tree is that it’s transparent for the driver/system.

See the file attached as shown in the Colibri iMX8X datasheet, page 29.
The nRESET_Out at SODIMM_87 is a buffered output from the possible sources of “Reset input”:

  1. (nRESET_EXT) at SODIMM_26
  2. Button Circuit
  3. RSETBMCU from PF8100.

In other words, the nRESET_Out is directly connected to the system’s reset.

As there is no GPIO related, I’d suggest you do adapt your driver to not count on the reset pin from Device Tree.

Best regards,
André Curvello

alt text

Hi, thanks. I will look into it.

I noticed a device tree file imx8qxp.dtsi includes imx8qxp-ss-lvds.dtsi that has disabled many mipi-related nodes. I changed their status to ‘okay’ and finally my driver was loaded, but I get errors. Now I don’t know are the errors related to my driver or the device tree, I get DSI transfer timeouts.

What specifically I need to enable from imx8qxp-ss-lvds.dtsi, or from any other device tree file, to get working mipi-dsi? I enabled mipi0_dphy, mipi0_dsi_host, mipi1_dphy, mipi1_dsi_host. Are the addresses etc. correct in that file?

Thanks!

Hi @stuo

You would have to enable mipi0_dsi_host and mipi0_dphy and disable everything related to ldb/lvds. What else did you enable? Can you maybe share your devicetree files? What error do you get when booting your system?

Regards,
Stefan

Hi @stefan_e.tx,

I enabled mipi0_dsi_host and mipi0_dphy and same for mipi1. I’m using basically colibri eval v3 device tree for now for our custom board as a starting point. I used the imx8qxp-colibri-lvds-dual-eval-v3.dts because it had some backlight pins enabled and I figured it could affect my use case too. I disabled ethernet because our board doesn’t have one and would not boot with this setting. Otherwise everything is default from toradex_5.4-2.1.x-imx.

My driver gets loaded with these changes to device tree but I get [drm:nwl_dsi_host_transfer] *ERROR* [11] DSI transfer timed out when driver wants to write 0x11 to mipi (first command). So this is possibly communication problem, either hardware or device tree, and I try to rule device tree out now.

I could not attach device trees here (the system claims that I miswrote the very clear verification code…) but if links are allowed, here is pastebin for the combined device tree https://pastebin.com/i5Vviev9

EDIT: One more question. The MIPI-DSI panel datasheet states in the beginning of the power-on sequence that “keep CLKN, CLKP, D0N, D0P, D1N, D1P in STOP state (LP-11)”. Is this something the DSI host controller on the Colibri SoM takes care of automatically, or can I change the behavior somewhere? In device tree?

Thanks!

Hi @stuo

Hmm for me the device tree looks fine. Can you maybe measure the Clock and Data signals to see if there is something coming out of the SoC?

The states should be kept okay by the DSI PHY. I don’t think you can influence it in the device tree.

Regards,
Stefan

Hi again,

I’m continuing working on this issue.

I noticed dmesg message about regulators not found and that it is using dummy regulator. I think I need to tell the driver the 3v3 and 1v8 regulator names? What are the correct regulator names (from device tree) used for MIPI DSI?

Thanks!

EDIT: scratch that. The display is now working. The driver didn’t need regulator info. But the default device tree for pwm-backlight is missing some mandatory properties, pwms and power-supply. I added them and now backlight works and is controllable.

Perfect, thanks for the feedback