Torizon long delay display initialization

Hi,

I was recently configuring a custom splash screen and I realized that I never actually got to see the it during boot (custom or default splash-screen), eventhough it showed perfectly during shutdown.

After some investigation I realized it was because the display subsystem is taking ~7 seconds to bind properly. At which point I am guessing everything else is initialized and the splash-screen shows for a split second or not at all …

We are using a custom carrier board with a WF50DTYA3MNG10 display.
WF50DTYA3MNG10.pdf (1.9 MB)

Dmesg shows that there are several attempts at binding but keep failing until they succeed at ~7.4 seconds.

verdin-imx8mm-06944605:~$ dmesg | grep -E "dsim|mipi|dsi|display"
[    1.208046] imx-drm soc@0:bus@32c00000:display-subsystem: bound imx-lcdif-crtc.0 (ops lcdif_crtc_ops)
[    1.208098] imx_sec_dsim_drv 32e10000.mipi_dsi: failed to get blk_ctl
[    1.208241] imx_sec_dsim_drv 32e10000.mipi_dsi: version number is 0x1060200
[    1.208476] imx_sec_dsim_drv 32e10000.mipi_dsi: Failed to attach bridge: 32e10000.mipi_dsi
[    1.216835] imx_sec_dsim_drv 32e10000.mipi_dsi: failed to bind sec dsim bridge: -517
[    1.648969] imx-drm soc@0:bus@32c00000:display-subsystem: bound imx-lcdif-crtc.0 (ops lcdif_crtc_ops)
[    1.649029] imx_sec_dsim_drv 32e10000.mipi_dsi: failed to get blk_ctl
[    1.649141] imx_sec_dsim_drv 32e10000.mipi_dsi: version number is 0x1060200
[    1.649279] imx_sec_dsim_drv 32e10000.mipi_dsi: Failed to attach bridge: 32e10000.mipi_dsi
[    1.657674] imx_sec_dsim_drv 32e10000.mipi_dsi: failed to bind sec dsim bridge: -517
[    1.753973] imx-drm soc@0:bus@32c00000:display-subsystem: bound imx-lcdif-crtc.0 (ops lcdif_crtc_ops)
[    1.754034] imx_sec_dsim_drv 32e10000.mipi_dsi: failed to get blk_ctl
[    1.754137] imx_sec_dsim_drv 32e10000.mipi_dsi: version number is 0x1060200
[    1.754285] imx_sec_dsim_drv 32e10000.mipi_dsi: Failed to attach bridge: 32e10000.mipi_dsi
[    1.762631] imx_sec_dsim_drv 32e10000.mipi_dsi: failed to bind sec dsim bridge: -517
[    1.773640] imx-drm soc@0:bus@32c00000:display-subsystem: bound imx-lcdif-crtc.0 (ops lcdif_crtc_ops)
[    1.773695] imx_sec_dsim_drv 32e10000.mipi_dsi: failed to get blk_ctl
[    1.773785] imx_sec_dsim_drv 32e10000.mipi_dsi: version number is 0x1060200
[    1.773938] imx_sec_dsim_drv 32e10000.mipi_dsi: Failed to attach bridge: 32e10000.mipi_dsi
[    1.782279] imx_sec_dsim_drv 32e10000.mipi_dsi: failed to bind sec dsim bridge: -517
[    1.795628] imx-drm soc@0:bus@32c00000:display-subsystem: bound imx-lcdif-crtc.0 (ops lcdif_crtc_ops)
[    1.795688] imx_sec_dsim_drv 32e10000.mipi_dsi: failed to get blk_ctl
[    1.795831] imx_sec_dsim_drv 32e10000.mipi_dsi: version number is 0x1060200
[    1.795963] imx_sec_dsim_drv 32e10000.mipi_dsi: Failed to attach bridge: 32e10000.mipi_dsi
[    1.804405] imx_sec_dsim_drv 32e10000.mipi_dsi: failed to bind sec dsim bridge: -517
[    3.989186] imx-drm soc@0:bus@32c00000:display-subsystem: bound imx-lcdif-crtc.0 (ops lcdif_crtc_ops)
[    3.989240] imx_sec_dsim_drv 32e10000.mipi_dsi: failed to get blk_ctl
[    3.989340] imx_sec_dsim_drv 32e10000.mipi_dsi: version number is 0x1060200
[    3.989480] imx_sec_dsim_drv 32e10000.mipi_dsi: Failed to attach bridge: 32e10000.mipi_dsi
[    3.999848] imx_sec_dsim_drv 32e10000.mipi_dsi: failed to bind sec dsim bridge: -517
[    7.436271] imx-drm soc@0:bus@32c00000:display-subsystem: bound imx-lcdif-crtc.0 (ops lcdif_crtc_ops)
[    7.436329] imx_sec_dsim_drv 32e10000.mipi_dsi: failed to get blk_ctl
[    7.436428] imx_sec_dsim_drv 32e10000.mipi_dsi: version number is 0x1060200
[    7.436821] imx-drm soc@0:bus@32c00000:display-subsystem: bound 32e10000.mipi_dsi (ops imx_sec_dsim_ops)
[    7.437182] [drm] Initialized imx-drm 1.0.0 20120507 for soc@0:bus@32c00000:display-subsystem on minor 1
[    7.439715] imx-drm soc@0:bus@32c00000:display-subsystem: fb0: imx-drmdrmfb frame buffer device
[   26.582974] ili9881c-dsi 32e10000.mipi_dsi.0: ili9881c_enable: Set 4-lane mode ; Color 7

This is the part of the dt overlay concerning the configuration of this display:

&mipi_dsi {
	status = "okay";
    #address-cells = <1>;
    #size-cells = <0>;
    
	panel@0 {
        reg = <0>;
		compatible = "startek,kd050hdfia020", "ilitek,ili9881c";

        power-supply = <&reg_3p3v>;
		pinctrl-0 = <&pinctrl_panelreset>;
		reset-gpio = <&gpio5 9 GPIO_ACTIVE_LOW>;

		dsi-lanes = <4>;
		video-mode = <2>;
		timing-mode = <0>;

		panel-width-mm = <62>;
		panel-height-mm = <110>;
		status = "okay";
		backlight = <&backlight>;
	};
};
verdin-imx8mm-06944605:~$ uname -r
5.4.129-5.4.0+git.cb88cc157bfb

Honestly, I am quite lost when it comes to the inner workings of the display subsytem.
I have tried to find some answers online but couldn’t find anything tangible.

Is there anything I can do to accelerate the time it takes to bind properly ?

Otherwise, I am essentially left with a black “splash screen” that transitions directly into a weston UI.

Thanks,
Jaume

Greetings @jcabecerans,

I’ve worked with another customer on the Verdin i.MX8M Plus where they had a MIPI-DSI display as well. But in that case I never saw the display sub-system fail to bind so many times. I mean it’s not the exact same case as yours but the 8M Mini and 8M Plus are fairly similar in this regard.

Based off your dmesg logs it almost looks like the display subsystem is attempting to bind before the MIPI-DSI display is “ready”. I’m a little surprised it even tries so many times despite the failures.

When your system starts up is your MIPI-DSI display black, like the display is completely off black? Or black like not displaying anything but it is on/powered black?

Also do you notice the display sub-system taking this long to initialize with other display interfaces? Like HDMI for example? Assuming you can test other display interfaces with your setup.

Finally just for reference was that snippet the only device tree related changes you made regarding the display subsystem?

Best Regards,
Jeremias

Hi @jeremias.tx

When your system starts up is your MIPI-DSI display black, like the display is completely off black? Or black like not displaying anything but it is on/powered black?

I’ve been reseting the device and staring at the screen for a while …
This is the sequence of events I can observe externally:

  1. Tun on board (t=0s)
  2. Display Completely black / off (t=0s)
  3. Backlight on ? Still black but there is brightness (t= ~7s)
  4. Display working, weston-dev gray background (t=~24s)
  5. Display working, chromium kiosk on screen (t=~34s)

Also do you notice the display sub-system taking this long to initialize with other display interfaces? Like HDMI for example? Assuming you can test other display interfaces with your setup.

Unfortunally on our custom board we only have this display interface available. Of course in the verdin development board it initializes way faster.

I attach the whole overlay in case I am missing out on something:

#include "dt-bindings/gpio/gpio.h"
#include "dt-bindings/pwm/pwm.h"
#include "dt-bindings/input/input.h"
#include "dt-bindings/interrupt-controller/irq.h"
#include <imx8mm-pinfunc.h>

/dts-v1/;
/plugin/;

/ {
	compatible = "toradex,verdin-imx8mm";
};

&usdhc2 {
	status = "disabled";
};

&iomuxc {
	pinctrl-0 = <&pinctrl_gpio1>, <&pinctrl_gpio2>,
		<&pinctrl_gpio3>, <&pinctrl_gpio4>,
		<&pinctrl_gpio7>, <&pinctrl_gpio8>,
		<&pinctrl_gpio_hog1>, <&pinctrl_gpio_hog2>, <&pinctrl_gpio_hog3>,
		<&pinctrl_pmic_tpm_ena>,
		<&pinctrl_misc_pins_gpio2>;

	pinctrl_misc_pins_gpio2: pinctrl_misc_pins_gpio2grp {
		fsl,pins = <
			MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12		0x40		// LBO CAP			SODIMM_84
			MX8MM_IOMUXC_SD2_CLK_GPIO2_IO13			0x1C0		// ADC DRDY			SODIMM_78
			MX8MM_IOMUXC_SD2_CMD_GPIO2_IO14			0x40		// ADC Start		SODIMM_74
			MX8MM_IOMUXC_SD2_DATA0_GPIO2_IO15		0x1C0		// DIG In 0			SODIMM_80
			MX8MM_IOMUXC_SD2_DATA1_GPIO2_IO16		0x1C0		// DIG In 1			SODIMM_82
			MX8MM_IOMUXC_SD2_DATA2_GPIO2_IO17		0x40		// ADC Reset		SODIMM_70
			MX8MM_IOMUXC_SD2_DATA3_GPIO2_IO18		0x40 		// Level enable		SODIMM_72
		>;
	};

	// Display Reset GPIO
	pinctrl_panelreset: panelresetgrp {
		fsl,pins = <
			MX8MM_IOMUXC_ECSPI1_SS0_GPIO5_IO9		0x184
		>;
	};
	// Cap touch
	pinctrl_captouch: captouchgrp {
		fsl,pins = <
			MX8MM_IOMUXC_ECSPI1_MISO_GPIO5_IO8		0x141  /* TOUCH RST */
			MX8MM_IOMUXC_NAND_RE_B_GPIO3_IO15		0x16  /* TOUCH INT */
		>;
	};

};

/* Verdin SPI_1 */
&ecspi2 {
	status = "okay";
	// Pass a dummy unused GPIO to we can free the real CS GPIO (<&gpio5 13 GPIO_ACTIVE_LOW>)
	// This is because we want to controll the CS from the ADS1148 driver directly and the spi_imx driver
	// doesn't free it to be used as GPIO
	cs-gpios = <&gpio5 7 GPIO_ACTIVE_LOW>;
	spidev20: spidev@0 {
		compatible = "toradex,evalspi";
		reg = <0>;
		spi-max-frequency = <10000000>;
		status = "okay";
	};
};

// Limit LDO5 to 1.8V (before it was 1.8V to 3.3V)
// This makes the power rail in the SD2 interface 1.8V which is what we need
&ldo5_reg {
	regulator-always-on;
	regulator-min-microvolt = <1800000>;
	regulator-max-microvolt = <1800000>;
};

&backlight {
	compatible = "pwm-backlight";
	brightness-levels = <0 4 8 16 32 64 128 255>;
	default-brightness-level = <6>;
	/* Verdin DSI_1_BKL_EN (SODIMM 21) */
	enable-gpios = <&gpio3 3 GPIO_ACTIVE_HIGH>;
	
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_gpio_10_dsi>;
	
	power-supply = <&reg_3p3v>;
	/* Verdin PWM_3_DSI (SODIMM 19) */
	pwms = <&pwm1 0 50000 0>;
	status = "okay";
};

&lcdif {
	status = "okay";
};

&mipi_dsi {
	status = "okay";
    #address-cells = <1>;
    #size-cells = <0>;
    
	panel@0 {
        reg = <0>;
		compatible = "startek,kd050hdfia020", "ilitek,ili9881c";

        power-supply = <&reg_3p3v>;
		pinctrl-0 = <&pinctrl_panelreset>;
		reset-gpio = <&gpio5 9 GPIO_ACTIVE_LOW>;

		dsi-lanes = <4>;
		video-mode = <2>;
		timing-mode = <0>;

		panel-width-mm = <62>;
		panel-height-mm = <110>;
		status = "okay";
		backlight = <&backlight>;
	};
};


&gpu {
	status = "okay";
};


&i2c2 {
	status = "okay";
	clock-frequency = <400000>;
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_i2c2>;

	touchscreen@5d {
		compatible = "goodix,gt928";
		reg = <0x5d>;
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_captouch>;
		interrupt-parent = <&gpio3>;
		interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
		reset-gpios = <&gpio5 8 GPIO_ACTIVE_HIGH>;
		irq-gpios = <&gpio3 15 GPIO_ACTIVE_HIGH>;
		touchscreen-size-x = <1000>;
		touchscreen-size-y = <1760>;
	};
};

// Disabled other unused Other stuff

/* Audio Codec */
&wm8904_1a {
	status = "disabled";
};

/* We don't use PCIE */
&pcie0 {
	status = "disabled";
};

// Used by dispay and cap
&uart3 {
	status = "disabled";
};

&gpio_expander_21 {
	status = "disabled";
};

&sound_card {
	status = "disabled";
};

&nau8822_1a {
	status = "disabled";
};

Thanks for the awesome support !
Jaume

Backlight on ? Still black but there is brightness (t= ~7s)

This ~7s timeline seems to fit with your dmesg logs you provided. In those logs the subsystem finally binds around the 7s time as well. This seems to support my theory that the system is trying to bind the display subsystem before the display is “ready”.

Of course in the verdin development board it initializes way faster.

Just to clarify this statement are you saying that on the Verdin Development Board this specific display initializes differently and quicker? Cause if so then that would be an interesting detail to follow.

As for your overlay I don’t notice anything immediately amiss, at least related to the issue you’re seeing here.

Best Regards,
Jeremias

Hi @jeremias.tx ,

Just to clarify this statement are you saying that on the Verdin Development Board this specific display initializes differently and quicker? Cause if so then that would be an interesting detail to follow.

No, sorry, I mean with HDMI. It would be a nice test but after a quick glance I can’t find any MIPI DSI ports on the Verdin Developement Board.

I didn’t pay special attention to the timings before, but now that I have them measured …
27 seconds before the UI starts is quite a long wait, especially if there is no splash-screen to notifiy the user that something is going on. I’m affraid the end user will keep turning it on/off because they don’t realize it is booting.

IMHO, the big problem here is the ~20s from the successful bind untill the display driver is initialized.

I added some print statements to the driver to better understand what is happening:

The first thing I noticed is that now it binds in 3.7 seconds instead of 7.4. I am really puzzled since literally, the only thing I changed are the print statements in the driver.

I also noticed that the function ili9881c_get_modes gets called at 3.7s and runs sucessfully (if there was an error it would also print an error message).
This same function gets called again ~18s later, an then finally prepare and enable get called.

verdin-imx8mm-06944605:~$ dmesg | grep -E "bound 32e10000.mipi_dsi|ili"
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 258048
[    3.253408] systemd[1]: Listening on initctl Compatibility Named Pipe.
[    3.748795] ili9881c-dsi 32e10000.mipi_dsi.0: ili9881c_dsi_probe: Start
[    3.748878] ili9881c-dsi 32e10000.mipi_dsi.0: ili9881c_dsi_probe: End
[    3.748940] imx-drm soc@0:bus@32c00000:display-subsystem: bound 32e10000.mipi_dsi (ops imx_sec_dsim_ops)
[    3.749279] ili9881c-dsi 32e10000.mipi_dsi.0: ili9881c_get_modes: Start
[    3.749285] ili9881c-dsi 32e10000.mipi_dsi.0: calling bus format set function ili9881c
[    3.749288] ili9881c-dsi 32e10000.mipi_dsi.0: ili9881c_get_modes: End
[   22.354505] ili9881c-dsi 32e10000.mipi_dsi.0: ili9881c_get_modes: Start
[   22.354523] ili9881c-dsi 32e10000.mipi_dsi.0: calling bus format set function ili9881c
[   22.354531] ili9881c-dsi 32e10000.mipi_dsi.0: ili9881c_get_modes: End
[   22.572001] ili9881c-dsi 32e10000.mipi_dsi.0: ili9881c_prepare: Start
[   22.843939] ili9881c-dsi 32e10000.mipi_dsi.0: ili9881c_prepare: End
[   22.843949] ili9881c-dsi 32e10000.mipi_dsi.0: ili9881c_enable: Start
[   23.023040] ili9881c-dsi 32e10000.mipi_dsi.0: ili9881c_enable: Set 4-lane mode ; Color 7
[   23.023048] ili9881c-dsi 32e10000.mipi_dsi.0: ili9881c_enable: End

ili9881c_get_modes code:

static int ili9881c_get_modes(struct drm_panel *panel)
{
    struct drm_connector *connector = panel->connector;
    struct ili9881c *ctx = panel_to_ili9881c(panel);
    struct drm_display_mode *mode;
    int ret;

    dev_notice(&ctx->dsi->dev,"%s: Start\n",__func__);

    mode = drm_mode_duplicate(panel->drm, &bananapi_default_mode);
    if (!mode) {
        dev_err(&ctx->dsi->dev, "failed to add mode %ux%ux@%u\n",
            bananapi_default_mode.hdisplay,
            bananapi_default_mode.vdisplay,
            bananapi_default_mode.vrefresh);
        return -ENOMEM;
    }

    drm_mode_set_name(mode);

    panel->connector->display_info.width_mm = 62;
    panel->connector->display_info.height_mm = 110;

    dev_notice(&ctx->dsi->dev, "calling bus format set function ili9881c\n");
    connector->display_info.bus_flags = DRM_BUS_FLAG_DE_LOW | DRM_BUS_FLAG_PIXDATA_NEGEDGE;
    ret = drm_display_info_set_bus_formats(&panel->connector->display_info,
                    ili_bus_formats, ARRAY_SIZE(ili_bus_formats));
    if (ret) {
        dev_err(&ctx->dsi->dev,"%s: drm_display_info_set_bus_formats failed\n",__func__);
        return -EINVAL;
    }

    mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
    drm_mode_probed_add(connector, mode);

    dev_notice(&ctx->dsi->dev,"%s: End\n",__func__);
    return 1;
}

Can you make something out this new information ?

Thanks,
Jaume

The timings you provided seem interesting actually.

So again I’m comparing using a prototype board a customer sent me for the Verdin i.MX8M Plus that uses a MIPI DSI display. This is as close a comparison I can get since Toradex doesn’t have a “standard” MIPI DSI display, and also our carrier boards don’t have MIPI DSI ports by default. But this is the closest comparison I can get.

On this prototype board the MIPI DSI display starts displaying under 10secs and the application UI shows up under ~15secs. Furthermore as you said an HDMI display initializes a lot faster as well.

While not conclusive this leads me to think this is a display specific issue possibly. If the display subsystem can initialize this alternative MIPI DSI and an HDMI quicker, then that means the display subsystem is capable and is not the root issue here. Perhaps the issue is the driver for this display you’re using? This would be the main difference between your display and the one I have. Though It’s hard to say without other MIPI DSI displays as a comparison.

By the way how long does it take to boot into the kernel? I.e. if you’re connected to serial debug how long does it take for the login prompt to be available?

I’m curious because you’re saying it takes 20-30secs for the display to bind and the UI to start up. But is the system taking that long to boot as well or just the display?

I know on our latest 5.4.0 release of TorizonCore that the system should boot faster than 20-30secs.

Best Regards,
Jeremias

Hi @jeremias.tx,

Good evening :slight_smile:

By the way how long does it take to boot into the kernel? I.e. if you’re connected to serial debug how long does it take for the login prompt to be available?

I will check the exact time tomorrow when I am back in the office, but I would say its arround 15s.

While not conclusive this leads me to think this is a display specific issue possibly. If the display subsystem can initialize this alternative MIPI DSI and an HDMI quicker, then that means the display subsystem is capable and is not the root issue here. Perhaps the issue is the driver for this display you’re using? This would be the main difference between your display and the one I have. Though It’s hard to say without other MIPI DSI displays as a comparison

To be honest, I don’t know much how the internals of the display subsystem work, but analyzing the function calls to the driver I am not so quick to conclude it’s the display’s fault.

How come if ili9881c_get_modes (called at t= 3.7s) runs wihtout error, the initialization process is halted for ~18s ?
Why is ili9881c_get_modes called again if it was sucessfull the previous time ?
This are the points which are not clear to me :confused:

Thanks,
Jaume

Unfortunately it’s difficult for me to say infer/say much more on this. There would need to be a more in-depth debugging/analysis on what the driver for this display acts the way it does.

Also even then I don’t have this specific hardware/display. So anything I could say would be assumptions/inferences at best. Again I think testing alternative displays might provide some more data-points to narrow down the issue. Otherwise the entire display stack is suspect. Though I don’t think it’s the entire stack since other displays can initialize relatively quickly.

Best Regards,
Jeremias

Hi @jeremias.tx,

Alright, thanks :slight_smile:
I will discuss it internally with the team and se what we can do about it.

Best Regards,
Jaume

Please let us know if you receive any additional information about this issue.

Best Regards,
Jeremias