No output on X2 of imx8qxp colibri for LVDS

I received some help from the Toradex team and was able to get a device tree that is supposed to work for the imx8qxp using the X2 connector to output LVDS signals.

I am using a custom adapter board to connect to the display.

I am using the Torizon Core builder to create the image that I am using with the device tree enabled. My file looks like this:

input:
  easy-installer:
    remote: "https://artifacts.toradex.com:443/artifactory/torizoncore-oe-prod-frankfurt/dunfell-5.x.y/release/7/colibri-imx8x/torizon/torizon-core-docker-evaluation/oedeploy/torizon-core-docker-evaluation-colibri-imx8x-Tezi_5.3.0%2Bbuild.7.container.tar"

customization:
  device-tree:
    include-dirs:
      - device-trees/include/
    overlays:
      add:
        - device-trees/dts-arm64/imx8qxp-colibri-lvds-single-channel.dts

output:
  easy-installer:
    local: torizon-core-colibri-imx8-custom-dt

Checking the overlays.txt file i can see that the changes are setup.

Probing the lines with an oscilloscope shows no output on any of the channel’s though. I would expect that I would see something if it was working on the Clock at least.

Is there something wrong with my image build?

The device tree i received has the following:

// SPDX-License-Identifier: GPL-2.0+ OR X11
/*
 * Copyright 2018-2020 Toradex
 */

/dts-v1/;

#include "imx8qxp-colibri.dtsi"

/ {
	model = "Toradex Colibri iMX8QXP/DX on LVDS Embedded World Demo";
	compatible = "toradex,colibri-imx8x-lvds-demo",
		     "toradex,colibri-imx8x",
		     "fsl,imx8qxp";

	panel_lvds: panel-lvds {
		compatible = "panel-lvds";
		backlight = <&backlight>;
		data-mapping = "vesa-24";
		width-mm = <217>;
		height-mm = <136>;

		status = "okay";

		panel-timing {
			clock-frequency = <68930000>;
			hactive = <1280>;
			vactive = <800>;
			hback-porch = <64>;
			hfront-porch = <64>;
			vback-porch = <5>;
			vfront-porch = <5>;
			hsync-len = <40>;
			vsync-len = <6>;
			hsync-active = <0>;
			vsync-active = <0>;
			pixelclk-active = <0>;
		};

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

&adma_pwm {
	status = "okay";
};

&adma_pwm_lpcg {
	status = "okay";
};

&backlight {
	pinctrl-0 = <&pinctrl_gpio_hpd>;
	enable-gpios = <&lsio_gpio1 31 GPIO_ACTIVE_HIGH>; /* Colibri BL_ON */
	status = "okay";
};

/* Colibri FastEthernet */
&fec1 {
	status = "okay";
};

&ldb1 {
	status = "okay";

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

		 port@1 {
			  reg = <1>;

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

&ldb1_phy {
	status = "okay";
};

&ldb2 {
	status = "disabled";
};

/* Colibri UART_A */
&lpuart3 {
	status= "okay";
};

&mipi0_dphy {
	status = "okay";
};

I don’t see any DRM Connector Name when i look through the drm class directory. I do see card0 and card1.

I’ve tried with the 5.4 nightly release as well to no avail.

Thanks for any additional help.

Greetings @egbio,

I saw from your other post that you got this from my fellow FAE Alex. Let me check in with him and see what he has to comment regarding this.

However just as an initial comment, this looks to be a full device tree file but going off of your yaml build file you’re treating it like an overlay. You want to take this and apply it as the system’s device tree instead of an overlay. As an example look at the usage of the custom: field here: TorizonCore Builder Tool “build” command

Best Regards,
Jeremias

Ok i will try setting it to the custom field (i believe i already tried this). I was under the impression that this was considered an overlay since it contains the panel information, and is “overlayed” over the main device tree. Thanks for the info.

The tree that i received was supposed to be run with Kernel Version 5.3 or later of Torizon. Looking through the device tree I saw only these nodes:

&adma_pwm
&adma_pwm_lpcg
&backlight
&fec1
&ldb1 lvds-channel@0 port@1
&ldb1_phy
&ldb2
&mipi0_dphy

digging into the imx8qxp-ss-lvds file I can see all the node’s referenced there in the device tree for 5.3.x. this file is then included into the device tree imx8qxp.dtsi. Am i reading this wrong, based on your comment that these node’s don’t exist in the Kernel Version 5.

Am i reading this wrong, based on your comment that these node’s don’t exist in the Kernel Version 5.

You’re replying to a deleted comment of mine. I made that comment before I read your other reply where you stated that you got the device tree from my colleague. I was out of the loop on how got the device tree and details surrounding. Please ignore that deleted comment.

I was under the impression that this was considered an overlay

I’m fairly sure this is a full device tree file and not an overlay. Overlays have the header: /plugin/; as seen here: apalis-imx6_atmel-mxt_overlay.dts « overlays - device-tree-overlays.git - Sources for Device Tree Overlays

Best Regards,
Jeremias

Ok thanks for the clarification. I wasn’t sure if i was misinterpreting the way the tree worked.

Overlays have the header: /plugin/;

I didn’t pick up on this detail thanks for pointing this out.

I was out of the loop on how got the device tree and details surrounding

Do you believe that device tree should be working? I’m not sure what the issue would be after reading through ldb.txt « imx « display « bindings « devicetree « Documentation - linux-toradex.git - Linux kernel for Apalis and Colibri modules it seems as though it is fully defined.

Sorry for the confusion.

Do you believe that device tree should be working?

Unfortunately I can’t make any further comments right now regarding this specific device tree. I’m completely out of the loop regarding it’s details/creation. I’ll need to sync up with my colleague who gave you this device tree and see if perhaps they can take a look here.

Apologies again about my initial confusion here.

Best Regards,
Jeremias

1 Like

Using the custom field work’s for getting the display. I am working on integrating it with the following display now: RVT70HSLNWC00-B - Riverdi

Using the custom field work’s for getting the display.

Perfect, so I assume the display is at least working on a basic level then? Sounds like you just need to now tweak the values in panel-timing to match your display’s specific timing parameters.

Are you experiencing any other issues related to this that I could assist with?

Best Regards,
Jeremias

Please check SSP-6