LVDS pixel clock not respected (Torizon 7.3, Verdin imx8mp)

Hi all,

We’re trying to get an LVDS display working on our Verdin IMX8MP. The current issue I am running into is that we need a pixel clock of 25 MHz, but regardless of the DTS configuration, it remains fixed at ~74 MHz - which is rejected by the panel.

I did find this thread which discusses needing to make patches to the kernel, but it is both several years old, and inspecting the drivers for the 6.6 kernel reveals that the restraint that is causing us problems was first removed, then re-added.

Can you confirm that there’s currently no way to support our display without patching the kernel and doing a complete custom OS build?

For reference, the following items were added to our custom DTS:

	panel_lvds {
		compatible = "panel-lvds";
		#address-cells = <1>;
		#size-cells = <0>;
		backlight = <&gpio_bl>;
		data-mapping = "vesa-24";
		width-mm = <108>;
		height-mm = <64>;
		panel-timing {
			clock-frequency = <25000000>;
			hactive = <800>;
			vactive = <480>;
			hback-porch = <4 8 48>;
			hfront-porch = <4 8 48>;
			vback-porch = <4 8 12>;
			vfront-porch = <4 8 12>;
			hsync-len = <2 4 8>;
			vsync-len = <2 4 8>;
			hsync-active = <0>;
			vsync-active = <0>; 
			pixelclk-active = <1>;
			// de-active = <1>;
		};
		port {
			panel_lvds_in: endpoint {
				remote-endpoint = <&lvds_out>;
			};
		};
	};
// // Enable items from the stock SoC config for graphics:
&gpu_2d {
	status = "okay";
};

&gpu_3d {
	status = "okay";
};

&lcdif2 {
	status = "okay";
};

&ldb {
	status = "okay";
	lvds-channel@0 {
		fsl,data-mapping = "spwg";
		fsl,data-width = <24>;
		status = "okay";

		port@1 {
			reg = <1>;

			lvds_out: endpoint {
				remote-endpoint = <&panel_lvds_in>;
			};
		};
	};
};

&ldb_phy {
	status = "okay";
};

&mix_gpu_ml {
	status = "okay";
};

&ml_vipsi {
	status = "okay";
};

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.


LVDS Pixel Clock Configuration on Verdin iMX8M Plus

Current LVDS Driver Limitations

Yes, you are correct about the current limitations. The Verdin iMX8M Plus LVDS implementation has known restrictions regarding pixel clock frequencies(1). The current LVDS driver implementation from the NXP kernel only supports 74.25 MHz single channel and 148.5 MHz dual channel LVDS(1). If a different frequency is set, the value will default to one of these predetermined frequencies(1).

Required Kernel Modifications

To work around this limitation and support your 25 MHz pixel clock requirement, kernel modifications are indeed necessary(1). The documentation provides specific steps:

1. Remove Clock Restrictions

First, you need to remove the following code inside drivers/gpu/drm/imx/imx8mp-ldb.c(1):

diff --git a/drivers/gpu/drm/imx/imx8mp-ldb.c b/drivers/gpu/drm/imx/imx8mp-ldb.c  
index 195146f82839..27720e47427e 100644  
--- a/drivers/gpu/drm/imx/imx8mp-ldb.c  
+++ b/drivers/gpu/drm/imx/imx8mp-ldb.c  
@@ -195,15 +195,6 @@ imx8mp_ldb_encoder_atomic_check(struct drm_encoder *encoder,  
 		return -EINVAL;  
 	}  
   
-	/*  
-	 * Due to limited video PLL frequency points on i.MX8mp,  
-	 * we do mode fixup here in case any mode is unsupported.  
-	 */  
-	if (ldb->dual)  
-		mode->clock = mode->clock > 100000 ? 148500 : 74250;  
-	else  
-		mode->clock = 74250;  
-  
 	return 0;  
 }  
   
@@ -221,16 +212,6 @@ imx8mp_ldb_encoder_mode_valid(struct drm_encoder *encoder,  
 	if (ldb_ch->panel)  
 		return MODE_OK;  
   
-	/*  
-	 * Due to limited video PLL frequency points on i.MX8mp,  
-	 * we do mode valid check here.  
-	 */  
-	if (ldb->dual && mode->clock != 74250 && mode->clock != 148500)  
-		return MODE_NOCLOCK;  
-  
-	if (!ldb->dual && mode->clock != 74250)  
-		return MODE_NOCLOCK;  
-  
 	return MODE_OK;  
 }  

(1)

2. Configure Device Tree Clock Settings

Next, update your device tree to specify the desired clock value times 7, since the internal divider will always divide the output LVDS clock by 7(1). For your 25 MHz requirement, you would need to calculate the appropriate value.

diff --git a/overlays/verdin-imx8mp_panel-cap-touch-10inch-lvds_overlay.dts b/overlays/verdin-imx8mp_panel-cap-touch-10inch-lvds_overlay.dts  
index c697398..812f346 100644  
--- a/overlays/verdin-imx8mp_panel-cap-touch-10inch-lvds_overlay.dts  
+++ b/overlays/verdin-imx8mp_panel-cap-touch-10inch-lvds_overlay.dts  
@@ -61,6 +61,13 @@  
 	};  
 };  
   
+&media_blk_ctrl {  
+       assigned-clock-rates = <500000000>, <200000000>,  
+                              <0>, <0>, <497700000>; // 71.1MHz  
+                               //<0>, <0>, <358400000>; // 51.2MHz  
+                              //<0>, <0>, <454970880>; // 64.9Mhz  
+};  
+  
 &gpu_2d {  
 	status = "okay";  
 };  

(1)

3. Build and Deploy

Finally, compile the new kernel, device tree and update your image(1). You can verify the clock frequency using:

# cat /sys/kernel/debug/clk/clk_summary | grep -C 5 video  

(1)

Hardware Considerations

According to the latest datasheet, the i.MX 8M Plus SoC features one LVDS interface that can be configured for single or dual-channel with 18 and 24-bit support(2). The LVDS signals are on module-specific pins and are not guaranteed to be compatible with other Verdin modules(2).

Conclusion

Unfortunately, there is currently no way to support your 25 MHz pixel clock requirement without patching the kernel and doing a complete custom OS build. The kernel modifications are necessary to remove the hardcoded frequency restrictions in the LVDS driver implementation.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

I guess the AI answer confirms what I suspected.

I’ll just note that reviewing the comments on the commit reversion, the decision seems a bit silly - it was reverted because it “breaks the 10” panel" - but wouldn’t that have been better addressed by patching the DTS overlay for said Toradex panel while leaving the driver configuration to be more flexible?

Hello @bw908 ,

Patching the kernel is the only way to work around this issue at the moment.

wouldn’t that have been better addressed by patching the DTS overlay for said Toradex panel while leaving the driver configuration to be more flexible?

That was discussed when the decision was made. The problem is there are some clock changes that need to be done, and we couldn’t do that without creating a requirement that all overlays are changed. We can fix our overlays, but for customers with products already in the field, this would create a breaking change, requiring them to change their overlays as well.

We refrain from this kind of change within a stable version cycle.

Best regards,

Rafael

1 Like

Fair enough, thanks for the insight into the decision(s).