This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SN65DSI83-Q1: Screen is abnormal

Part Number: SN65DSI83-Q1
Other Parts Discussed in Thread: SN65DSI83

Hi,
We are currently working on integrating our system with a TI SN65DSI83 LVDS chip, connected to an IMX8MM chip, and an Orient Display LVDS screen. We are reaching out because we are facing a lot of instability issues resulting in graphical glitches on the screen.

The graphical chain of my system can be summarized as follows:

IMX8MM (mipi-dsi) <--> (mipi-dsi) TI-SN65DSI83 (LVDS) <--> (LVDS) Orient Display AFY1280800A1

On the software side, we are using a custom Yocto distribution, utilizing a Linux kernel version 5.10.35, and the mainline SN65DSI83 Linux driver, which we backported from the 5.15 kernel on the first initial commit release. We are also using panel timings provided by Orient Display:



The main problem is that when we are testing the system using typical panel timing values, the screen is abnormal and gives a lot of glitches. The glitches appear in the images generated by Linux and randomly on the LVDS test pattern:


Currently, we have a workaround by using custom panel timing values (a mix of typical and max values) that give a stable screen with no glitches at all. This values are :

clock frequency = 78MHz
hsync pulse = 40
hback-porch = 48
hfront-porch = 102
vsync-len = 20
vback-porch = 3
vfront-porch = 10

However, as mentioned, it is a workaround, and we want to use the typical panel timing values from Orient Display.

Here's all the investigation we have done so far:

On IMX8MM:

    Checked MIPI-DSI signals
    --> Signals are OK; the frequency is normal and corresponds to what is configured in SN65DSI83 registers.

On Linux:

    Checked DTS
    --> Decompiled DTB shows that we are using the panel timing values we set in DTSI, which are the correct ones.
    --> No errors reported by the driver, but the following warning is printed:
    "Unsupported LVDS bus format 0x100a, please check the output bridge driver. Falling back to SPWG24."

This warning is always printed, whether we are in a working state or an unstable state.

    Bumped driver revision
    --> Tested on the latest revision with no effect on stability with typical values

On Orient Display screen:

    Tested panel timings on other hardware
    --> Panel timings have been retested by Orient Display on their test bench and show no issues.

On SN65DSI83:

    Checked initialization sequence
    --> With an oscilloscope, we have checked that the SN65DSI83 driver respects the initialization sequence described in the datasheet.

    Checked IRQ registers
    --> No error reported in error registers (0xE5)

    Compared I2C registers configuration with one generated with DSI-tools software
    --> I2C registers are configured as expected.

Finally, LVDS panel and SN65DSI83 are defined as below in our dts:

	panel{
		status = "okay";
		compatible = "panel-lvds";
		width-mm = <217>;
		height-mm = <136>;
		data-mapping = "vesa-24";

		panel-timing {
			clock-frequency = <72400000>;
			hactive = <1280>;
			vactive = <800>;
			hsync-len = <40>;
			hback-porch = <48>;
			hfront-porch = <72>;
			vsync-len = <20>;
			vback-porch = <3>;
			vfront-porch = <15>;
		};
		port {
			panel_in: endpoint {
				remote-endpoint = <&sn65dsi83_out>;
			};
		};
	};
	
pinctrl_lvds: lvdsgrp {
	fsl,pins = <
		MX8MM_IOMUXC_SAI2_MCLK_GPIO4_IO26  0x15
	>;
};

&i2c3 {
	status = "okay";
	mipi_bridge: bridge@2c {
		compatible = "ti,sn65dsi83";
		reg = <0x2c>;
		status = "okay";
		enable-gpios = <&gpio4 26 GPIO_ACTIVE_HIGH>;
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_lvds>;
		ti,dsi-lanes = <4>;
		ti,lvds-format = <2>;
		ti,lvds-bpp = <24>;
		ti,width-mm = <217>;
		ti,height-mm = <136>;
		ports {
			port@0 {
				reg = <0>;

				sn65dsi83_in: endpoint {
					remote-endpoint = <&mipi_dsi_out>;
					data-lanes = <1 2 3 4>;
				};
			};

			port@2 {
				reg = <2>;

				sn65dsi83_out: endpoint {
					remote-endpoint = <&panel_in>;
				};
			};
		};
	};
};

We are open to any suggestions to resolve our problem. Our goal is to use the typical panel timing values without instability.

Thanks in advance for all your answers,
Kindly,
Paul Le Guen de Kerneizon