HDMI failing to recognize screen on Apalis-IMX8

Hello,

I am working with the apalis imx8 and ixora carrier board interfacing with a 1280x800 screen communicating via HDMI and usb for touch. I am running an custom image with the base 5.7 lts release of torizoncore.

We are currently running the screen and compute module off of a single power supply(I have confirmed there is enough power available for both) and upon startup where the screen and board are powered on the hdmi communication seems to fail. However, when I unplug the board and let the screen boot on and then plug the board back in the communication works.

It seems that getting the EDID block fails in the first case but not the second. I am unsure how to fix this so that we can reliably use the screen.

When the board and screen are powered on together at the same time:
The output of cat /sys/class/drm/card1-HDMI-A-1/status is: unknown
The output of dmesg | grep drm is:
[ 1.544237] imx-drm display-subsystem: parent device of /bus@57240000/ldb@572410e0/lvds-channel@0 is not available
[ 4.774299] [drm] Initialized vivante 1.0.0 20170808 for 80000000.imx8_gpu1_ss on minor 0
[ 5.852063] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 5.852068] [drm] No driver support for vblank timestamp query.
[ 5.852154] imx-drm display-subsystem: bound imx-drm-dpu-bliteng.2 (ops dpu_bliteng_ops)
[ 5.852207] imx-drm display-subsystem: bound imx-drm-dpu-bliteng.5 (ops dpu_bliteng_ops)
[ 5.859004] imx-drm display-subsystem: bound imx-dpu-crtc.0 (ops dpu_crtc_ops)
[ 5.869446] imx-drm display-subsystem: bound imx-dpu-crtc.1 (ops dpu_crtc_ops)
[ 5.871883] imx-drm display-subsystem: bound imx-dpu-crtc.3 (ops dpu_crtc_ops)
[ 5.875216] imx-drm display-subsystem: bound imx-dpu-crtc.4 (ops dpu_crtc_ops)
[ 5.916420] [drm] Started firmware!
[ 5.917550] [drm] HDP FW Version - ver 34219 verlib 20560
[ 5.920373] imx-drm display-subsystem: bound 56268000.hdmi (ops cdns_mhdp_imx_ops [cdns_mhdp_imx])
[ 5.922085] [drm] Initialized imx-drm 1.0.0 20120507 for display-subsystem on minor 1
[ 23.261912] [drm:cdns_hdmi_get_edid_block] ERROR get block[0] edid failed: -110
[ 23.269468] [drm:cdns_hdmi_connector_get_modes] ERROR Invalid edid
[ 23.281094] imx-drm display-subsystem: fb0: imx-drmdrmfb frame buffer device
[ 45.316041] [drm:cdns_mhdp_read_hpd] ERROR read hpd failed: -110
[ 45.322411] [drm] Unknow cable status, hpd=146

When the board is powered on after the screen:
The output of cat /sys/class/drm/card1-HDMI-A-1/status is: connected
The output of dmesg | grep drm is:
[ 1.546657] imx-drm display-subsystem: parent device of /bus@57240000/ldb@572410e0/lvds-channel@0 is not available
[ 4.604533] [drm] Initialized vivante 1.0.0 20170808 for 80000000.imx8_gpu1_ss on minor 0
[ 5.649827] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 5.649832] [drm] No driver support for vblank timestamp query.
[ 5.649920] imx-drm display-subsystem: bound imx-drm-dpu-bliteng.2 (ops dpu_bliteng_ops)
[ 5.649978] imx-drm display-subsystem: bound imx-drm-dpu-bliteng.5 (ops dpu_bliteng_ops)
[ 5.653893] imx-drm display-subsystem: bound imx-dpu-crtc.0 (ops dpu_crtc_ops)
[ 5.657477] imx-drm display-subsystem: bound imx-dpu-crtc.1 (ops dpu_crtc_ops)
[ 5.662631] imx-drm display-subsystem: bound imx-dpu-crtc.3 (ops dpu_crtc_ops)
[ 5.665825] imx-drm display-subsystem: bound imx-dpu-crtc.4 (ops dpu_crtc_ops)
[ 5.701825] [drm] Started firmware!
[ 5.704577] [drm] HDP FW Version - ver 34219 verlib 20560
[ 5.715950] imx-drm display-subsystem: bound 56268000.hdmi (ops cdns_mhdp_imx_ops [cdns_mhdp_imx])
[ 5.716654] [drm] Initialized imx-drm 1.0.0 20120507 for display-subsystem on minor 1
[ 5.749840] imx-drm display-subsystem: fb0: imx-drmdrmfb frame buffer device
[ 23.677129] [drm] Mode: 1280x800p71000
[ 23.709611] [drm] Pixel clock: 71000 KHz, character clock: 71000, bpc is 8-bit.
[ 23.709620] [drm] VCO frequency is 2840000 KHz
[ 23.810826] [drm] Sink Not Support SCDC
[ 23.812471] [drm] No vendor infoframe

Thanks, Mike

Greetings @MikeHA,

This is a very strange sounding issue. I’ve also never heard of such behavior like this before. Just given the information here it’s hard to say whether the issue lies on the module side, or the display side, or really what the issue even is.

As a sanity test have you tried your display here on TorizonCore 6.X? Perhaps the more recent software behaves better.

Also, is this behavior only with this specific display? Or do you see it happen with other HDMI displays?

Best Regards,
Jeremias

It seems whatever the issue is might have been fixed in TorizonCore 6+ as I have not been able to recreate the issue as of yet with the upgraded version of Torizoncore.

Thanks, Mike

Interesting perhaps it was some issue on the kernel side that got fixed in newer Linux versions. Though it would be hard to say what specific change fixes this with such a big difference in Linux kernel version.

That said, is moving to TorizonCore 6 a suitable solution for you? Or must you stay on TorizonCore 5 for some reason?

Best Regards,
Jeremias

TC6 is a suitable solution as we already planned to update anyways. Thanks!

Best, Mike

Alright glad to hear then. Glad I was able to help!