I’m running into a bit of a head-scratcher here and I’m hoping to get some external input as to what might be going wrong.
Preamble:
I’d previously posted here (LVDS pixel clock not respected (Torizon 7.3, Verdin imx8mp)) and have since made the requisite kernel and DTS patches as outlined in the help article.
The issue:
After the patch, the display works as expected on a Torizon 6.8.x-based build of the OS. However, I am unable to get the display working properly on Torizon 7.1.0 with the same set of changes.
Details/observations:
- I’ve confirmed the patch is applied correctly. I’ve scoped the LVDS_CLK lines and can see that it is indeed operating at 25MHz in both cases.
- Torizon 7.x has some notable changes to the DeviceTree handling, so while I could not use the exact same entries as on 6.x, the display timing values were copy-pasted verbatim.
- The display “attempts” to come up and seems functional as far as the system is concerned (e.g. running an application with EGLFS works and the garbled pattern on the display changes a bit as the application draws different screens).
- However, as noted, the display is completely garbled and non-functional. The current finding is that it appears only two of the four LVDS data lanes are transmitting any data; the other two are idle. (specifically, LVDS_D0 and LVDS_D3 show no activity - the clock, D1, and D2 have signals).
It’s not clear to me what would cause this since as far as I can tell this is not any sort of configurable mode. - I do sporadically see
ldb-display-controller: Failed to create device link (0x180) with 32e90000.lcd-controllerin the kernel dmesg. Trying to find information on this has been somewhat fruitless and as far as I can tell, using e.g. devmem2 to inspect the LCDIF2 peripheral it seems to be configured correctly as far as video timings and display size.
Do you have any ideas why the system might be in this weird state or where I should start digging next? I’ve already tried playing with the timing values within the allowed ranges in the datasheet (ST7262 controller), but the underlying issue seems to be the missing channels.
These are the DTS changes I added for Torizon 7.x, based off the example 10" LVDS mezzanine overlay:
- Under the
/root node:
panel_lvds {
compatible = "panel-lvds";
#address-cells = <1>;
#size-cells = <0>;
backlight = <&backlight>;
data-mapping = "vesa-24";
width-mm = <108>;
height-mm = <64>;
panel-timing {
clock-frequency = <24000000>;
hactive = <800>;
vactive = <480>;
hback-porch = <40>;
hfront-porch = <40>;
vback-porch = <8>;
vfront-porch = <8>;
hsync-len = <7>;
vsync-len = <7> ;
hsync-active = <0>;
vsync-active = <0>;
pixelclk-active = <1>;
de-active = <1>;
};
port {
panel_lvds_in: endpoint {
remote-endpoint = <&lvds_out>;
};
};
};
- elsewhere, changes to existing nodes:
&backlight {
status = "okay";
default-brightness-level = <0>;
pwms = <&pwm3 0 6666667 0>;
};
&media_blk_ctrl {
assigned-clock-rates = <500000000>, <200000000>,
<0>, <0>, <168000000>; // 24MHz
};
// // 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";
};
