Hi,
I'm working with the Variscite SOM VAR-SOM-MX8M-PLUS (you can find their website when googling this SOM model) that is using LVDS for a 640x480 60Hz LCD. I'm unable to get a stable image for the LCD when using the display timing parameters from the spec sheet.
My device tree changes:
#include "imx8mp-var-som-symphony.dts" / { panel { compatible = "panel-lvds"; backlight = <&backlight>; width-mm = <211>; height-mm = <158>; label = "640x480"; data-mapping = "jeida-24"; status = "okay"; panel-timing { clock-frequency = <25175000>; hactive = <640>; vactive = <480>; hback-porch = <40>; hfront-porch = <8>; vback-porch = <25>; vfront-porch = <2>; hsync-len = <96>; vsync-len = <2>; hsync-active = <0>; vsync-active = <0>; de-active = <1>; }; port { panel_in: endpoint { remote-endpoint = <&lvds_out>; }; }; }; }; &clk { assigned-clock-rates = <0>, <0>, <1000000000>, <800000000>, <500000000>, <400000000>, <800000000>, <393216000>, <361267200>, <352450000>; }; &media_blk_ctrl { assigned-clock-rates = <500000000>, <200000000>, <0>, <0>, <352450000>; }; &ldb { status = "okay"; lvds-channel@0 { fsl,data-mapping = "jeida"; fsl,data-width = <24>; status = "okay"; port@1 { reg = <1>; lvds_out: endpoint { remote-endpoint = <&panel_in>; }; }; }; };
I've updated the PLL clocks to reflect the 25.175 MHz pixel clock (25.175 * 14 = 352.450MHz) I've also added other clocks incase there was different multiplier (not just 14).
static const struct imx_pll14xx_rate_table imx_pll1443x_tbl[] = { PLL_1443X_RATE(1039500000U, 173, 2, 1, 16384), /* 74.25 MHz */ PLL_1443X_RATE(910000000U, 455, 3, 2, 0), /* 65 MHz */ PLL_1443X_RATE(1040000000U, 208, 3, 1, 0), /* 65 MHz */ PLL_1443X_RATE(455000000U, 379, 5, 2, 10923), /* 65 MHz */ PLL_1443X_RATE(650000000U, 325, 3, 2, 0), PLL_1443X_RATE(594000000U, 198, 2, 2, 0), PLL_1443X_RATE(519750000U, 173, 2, 2, 16384), /* 37.125 MHz */ /*PLL_1443X_RATE(420000000U, 175, 5, 1, 0),*/ /* 30 MHz */ PLL_1443X_RATE(393216000U, 262, 2, 3, 9437), /*PLL_1443X_RATE(378000000U, 126, 4, 1, 0),*/ /* 27 MHz */ PLL_1443X_RATE(361267200U, 361, 3, 3, 17511), PLL_1443X_RATE(352450000U, 220, 15, 0, 18432), /* 25.175 MHz */ PLL_1443X_RATE(400000000U, 200, 3, 2, 0), /* 25 MHz */ PLL_1443X_RATE(700000000U, 175, 3, 1, 0), /* 25 MHz */ PLL_1443X_RATE(350000000U, 175, 6, 1, 0), /* 25 MHz */ PLL_1443X_RATE(245760000U, 328, 4, 3, 0xae15), PLL_1443X_RATE(225792000U, 226, 3, 3, 0xcac1), PLL_1443X_RATE(122880000U, 328, 4, 4, 0xae15), PLL_1443X_RATE(112896000U, 226, 3, 4, 0xcac1), PLL_1443X_RATE(61440000U, 328, 4, 5, 0xae15), PLL_1443X_RATE(56448000U, 226, 3, 5, 0xcac1), PLL_1443X_RATE(49152000U, 393, 3, 6, 0x374c), PLL_1443X_RATE(45158400U, 241, 2, 6, 0xd845), PLL_1443X_RATE(40960000U, 109, 1, 6, 0x3a07), };
I've commented out the hardcoded clocks inside imx8mp-ldb.c
/* * 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;
Verified PLL clock on board:
root@imx8mp-var-dart:~# cat /sys/kernel/debug/clk/video_pll1/clk_rate
352450000
The picture looks like this
Please advise on what to try next.
Thanks,
Jon
refer to your panel spec, it seems you don't set correct timings, the h_total is 800 and v_total is 525, pls double check it
Bumping to be seen by support @joanxie
I updated the timings to equal 800 htotal and 525 vtotal. Picture comes out the same.
I measured the clocks on the scope, 25MHz comes out fine for pixel clock but the vertical and horizontal sync are unstable.
Can IMX8MP support 640x480? Why wouldn't the h/v sync timings be unstable?
We have this same LCD for imx6solox and there wasn't any problems (kernel 4.9), simple-panel setup in the device tree, it was straight forward and worked right away.
Hi @synthesys
Can you share your current timing setting?
Best Regards,
Zhiming
Hi, here are the current timings.
panel {
compatible = "panel-lvds";
backlight = <&backlight>;
width-mm = <211>;
height-mm = <158>;
label = "640x480";
data-mapping = "jeida-24";
status = "okay";
panel-timing {
clock-frequency = <25175000>;
hactive = <640>;
vactive = <480>;
hback-porch = <46>;
hfront-porch = <8>;
vback-porch = <38>;
vfront-porch = <4>;
hsync-len = <106>;
vsync-len = <3>;
hsync-active = <0>;
vsync-active = <0>;
de-active = <1>;
};
port {
panel_in: endpoint {
remote-endpoint = <&lvds_out>;
};
};
};I attached the LCD data sheet and the specific page with timings. We have an LCD board that converts LVDS to Parallel RGB. Like I mentioned previously, this same LCD works with IMX6SoloX just fine.
For some reason, 12.5MHz, the image looks great but its only at 30Hz refresh rate. I want to use the spec which is 25MHz @ 60 Hz refresh rate.
Zhiming,
I've tried the new timings and the image is still bad, similar to the picture I posted in the original post. I'm thinking the solution might not be changing these panel timings.
Is there something else in the device tree or maybe kernel that is required to enable this?
I've tried changing the PLL (pixel clock x 7 or pixel clock x 14) and still same issue.
Any other suggestions?
Thank you for your continued support on this problem.
Jon
Hi @synthesys
I checked the timing parameters in the datasheet and your dts.
datasheet:
In Linux, htotal = hactive + hfront_porch + hsync_len + hback_porch
You are using hsync-active=0, which means hsync_len + hback_porch = THS = 144, hsync_len = TWH = 30 from datasheet, so
hback_porch = 144 - 30 = 114
The vertical direction is similar, so I suggest you try the following parameters.
panel-timing {
clock-frequency = <25175000>;
hactive = <640>;
vactive = <480>;
hfront-porch = <16>;
hsync-len = <30>;
hback-porch = <114>;
vfront-porch = <10>;
vsync-len = <3>;
vback-porch = <32>;
hsync-active = <0>;
vsync-active = <0>;
de-active = <1>;
};
Best Regards,
Zhiming
Hi @synthesys
You can try modifying the following section in imx8mp-ldb.c to your desired `mclock` value instead of using the annotation.
And this modification to `mclock` actually worked for me.
Hi @Zhiming_Liu any other suggestions? Changing PLL or driver code?
@Zhiming_Liu @JESON @joanxie
Hi All, it seems like the issue is in hardware. We needed to add a resister to several LVDS lines. We can close this ticket. Thank you all for your input.