Re: Need Help Enabling HDMI on Debix Model A

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Thu, Apr 10, 2025 at 11:33:08AM +0000, Tarang Raval wrote:
> > On Thu, Apr 10, 2025 at 08:13:17AM +0000, Tarang Raval wrote:
> > > > On Mon, Apr 07, 2025 at 02:06:35PM +0000, Tarang Raval wrote:
> > > > > > On Mon, Apr 07, 2025 at 11:10:23AM +0000, Tarang Raval wrote:
> > > > > > > Hi Laurent,
> > > > > > >
> > > > > > > I’m trying to bring up HDMI on the Debix Model A board using the
> > > > > > > mainline kernel, but I’m currently facing issues.
> > > > > > >
> > > > > > > I saw that you tested the patch for HDMI support on this board in
> > > > > > > mainline, so I am hoping you could help me figure out what might be
> > > > > > > missing.
> > > > > > >
> > > > > > > To clarify — I'm using the prebuilt image provided by Debix, but I replaced
> > > > > > > the kernel image and the device tree (DTS) file in the /boot directory with
> > > > > > > ones built from the mainline kernel.
> > > > > > >
> > > > > > > I’ve enabled the following configurations in the kernel:
> > > > > > > CONFIG_DRM_DISPLAY_CONNECTOR=y
> > > > > > > CONFIG_DRM_IMX8MP_DW_HDMI_BRIDGE=y
> > > > > > > CONFIG_DRM_IMX8MP_HDMI_PVI=y
> > > > > > > CONFIG_DRM_IMX_LCDIF=y
> > > > > > > CONFIG_PHY_FSL_SAMSUNG_HDMI_PHY=y
> > > > > > >
> > > > > > > When I boot the board, I see the following HDMI/DRM related logs:
> > > > > > > debix@imx8mp-debix:~$ dmesg | grep -iE "drm|hdmi"
> > > > > > > [    0.121979] /soc@0/bus@32c00000/display-bridge@32fc4000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/hdmi@32fd8000
> > > > > > > [    0.122164] /soc@0/bus@32c00000/hdmi@32fd8000: Fixed dependency cycle(s) with /soc@0/bus@32c00000/display-bridge@32fc4000
> > > > > > > [    0.127417] /soc@0/bus@32c00000/hdmi@32fd8000: Fixed dependency cycle(s) with /hdmi-connector
> > > > > > > [    0.127608] /hdmi-connector: Fixed dependency cycle(s) with /soc@0/bus@32c00000/hdmi@32fd8000
> > > > > > > [    1.947962] imx8mp-dw-hdmi-tx 32fd8000.hdmi: Detected HDMI TX controller v2.13a with HDCP (SAMSUNG HDMI TX PHY)
> > > > > > > [    1.949220] imx8mp-dw-hdmi-tx 32fd8000.hdmi: registered DesignWare HDMI I2C bus driver
> > > > > > > [    1.956365] [drm] Initialized imx-lcdif 1.0.0 for 32fc6000.display-controller on minor 0
> > > > > > > [    2.016601] imx-lcdif 32fc6000.display-controller: [drm] fb0: imx-lcdifdrmfb frame buffer device
> > > > > > > [    8.380915] systemd[1]: Starting Load Kernel Module drm...
> > > > > > >
> > > > > > >
> > > > > > > I also checked that the display's modeline is recognized under sysfs :
> > > > > > >
> > > > > > > root@imx8mp-debix:~# ls /sys/class/drm/card0-HDMI-A-1/
> > > > > > > connector_id  dpms          modes         subsystem/
> > > > > > > ddc/          edid          power/        uevent
> > > > > > > device/       enabled       status
> > > > > > >
> > > > > > > However, there is still no HDMI output on the display. Instead,
> > > > > > > I only see a white blinking cursor on the screen.. I'm not sure
> > > > > > > what I'm missing.
> > > > > > 
> > > > > > The white blinking cursor means the display is working from the kernel
> > > > > > point of view. What are you expecting, are you running an X server or
> > > > > > Wayland compositor ?
> > > > >
> > > > > I'm expecting to see the Ubuntu desktop environment on the HDMI
> > > > > display — just like how it appears with the original prebuilt image provided
> > > > > by Debix. I'm running the default Ubuntu 22.04 LTS prebuilt image, and I only
> > > > > replaced the Image and .dtb file
> > > > >
> > > > > I'm not explicitly launching an X server or Wayland compositor myself
> > > > >
> > > > > However, based on your response, I now realize that I may also need to
> > > > > enable GPU support in the mainline device tree. Specifically, I believe I
> > > > > need to enable the gpu2D and gpu3D nodes to allow the graphical
> > > > > environment to start properly and render the desktop over HDMI.
> > > > >
> > > > > Does that sound correct, or is there anything else I should check or
> > > > > enable?
> > > > 
> > > > That's a plausible explanation. The 2D GPU is probably not used by the
> > > > compositor, but a 3D GPU could be required. I'd recommend checking the
> > > > system logs to see why the compositor (or session manager) failed to
> > > > start.
> > >
> > > I reviewed the system logs for more context regarding the failure of the
> > > compositor (or session manager) to start.
> > >
> > > Here are some relevant log entries from journalctl -b -p err:
> > >
> > > debix@imx8mp-debix:~$ journalctl -b -p err
> > > Hint: You are currently not seeing messages from other users and the system.
> > >       Users in groups 'adm', 'systemd-journal' can see all messages.
> > >       Pass -q to turn off this notice.
> > > Apr 10 06:37:29 imx8mp-debix pulseaudio[766]: GetManagedObjects() failed: org.freedesktop.systemd1.NoSuchUnit: Unit dbus-org.bluez.serv>
> > > Apr 10 06:37:29 imx8mp-debix systemd[757]: Failed to start Application launched by gnome-session-binary.
> > > Apr 10 06:37:29 imx8mp-debix systemd[757]: Failed to start Application launched by gnome-session-binary.
> > > Apr 10 06:37:30 imx8mp-debix systemd[757]: Failed to start GNOME Shell on Wayland.
> > >
> > > Additionally, from journalctl -b | grep -i gnome, the following lines appear to be significant:
> > >
> > > Apr 10 06:37:29 imx8mp-debix systemd[757]: org.gnome.Shell@x11.service: Skipped due to 'exec-condition'.
> > > Apr 10 06:37:29 imx8mp-debix systemd[757]: Started GNOME Shell on X11.
> > > Apr 10 06:37:30 imx8mp-debix gnome-shell[873]: Running GNOME Shell (using mutter 42.9) as a Wayland display server
> > > Apr 10 06:37:30 imx8mp-debix gnome-shell[873]: g_hash_table_destroy: assertion 'hash_table != NULL' failed
> > > Apr 10 06:37:30 imx8mp-debix gnome-shell[873]: Failed to open gpu '/dev/dri/card0': No suitable mode setting backend found
> > 
> > I don't know how gnome-shell finds the GPU, if Ubuntu ships a modified
> > version, or possibly configuration files specific to the closed-source
> > GPU stack shipped with the BSP kernel. It could also be that the mesa
> > version they ship does not support the upstream kernel driver. You will
> > have to investigate all this.
> 
> I need to verify the compatibility between the kernel GPU driver (etnaviv), 
> the Mesa library version, and GNOME Shell on my Ubuntu image, is that correct?
> 
> you're suggesting that the prebuilt Ubuntu image might be expecting a 
> proprietary GPU driver provided by the BSP kernel is that what you meant?

Yes, possibly. I don't know what is shipped in that image, but I know
it's common for board vendors to ship images with customized components.

> > > Apr 10 06:37:30 imx8mp-debix gnome-shell[873]: Added device '/dev/dri/card1' (imx-lcdif) using atomic mode setting.
> > > Apr 10 06:37:30 imx8mp-debix gnome-shell[873]: Failed to setup: No GPUs with outputs found
> > >
> > > the GNOME Shell logs indicate that no GPUs with outputs were found but the dmesg
> > > output suggests that the GPU is successfully probed and initialized:
> > >
> > > debix@imx8mp-debix:~$ dmesg | grep -i -e drm -e gpu -e galcore -e etnaviv
> > > [    2.156784] etnaviv etnaviv: bound 38000000.gpu (ops gpu_ops)
> > > [    2.157294] etnaviv etnaviv: bound 38008000.gpu (ops gpu_ops)
> > > [    2.157753] etnaviv etnaviv: bound 38500000.npu (ops gpu_ops)
> > > [    2.157852] etnaviv-gpu 38000000.gpu: model: GC7000, revision: 6204
> > > [    2.157986] etnaviv-gpu 38008000.gpu: model: GC520, revision: 5341
> > > [    2.158111] etnaviv-gpu 38500000.npu: model: GC8000, revision: 8002
> > > [    2.158118] etnaviv-gpu 38500000.npu: etnaviv has been instantiated on a NPU, for which the UAPI is still experimental
> > > [    2.158905] [drm] Initialized etnaviv 1.4.0 for etnaviv on minor 0
> > > [    2.161597] [drm] Initialized imx-lcdif 1.0.0 for 32fc6000.display-controller on minor 1
> > > [    2.161637] imx-lcdif 32fc6000.display-controller: [drm] Cannot find any crtc or sizes
> > 
> > This doesn't seem right. Here's the corresponding part of my boot log:
> > 
> > [    3.347606] imx8mp-dw-hdmi-tx 32fd8000.hdmi: Detected HDMI TX controller v2.13a with HDCP (SAMSUNG HDMI TX PHY)
> > [    3.352436] imx8mp-dw-hdmi-tx 32fd8000.hdmi: registered DesignWare HDMI I2C bus driver
> > [    3.378609] etnaviv etnaviv: bound 38000000.gpu (ops gpu_ops)
> > [    3.379829] etnaviv etnaviv: bound 38008000.gpu (ops gpu_ops)
> > [    3.381695] etnaviv etnaviv: bound 38500000.npu (ops gpu_ops)
> > [    3.382290] etnaviv-gpu 38000000.gpu: model: GC7000, revision: 6204
> > [    3.383178] etnaviv-gpu 38008000.gpu: model: GC520, revision: 5341
> > [    3.383735] etnaviv-gpu 38500000.npu: model: GC8000, revision: 8002
> > [    3.383753] etnaviv-gpu 38500000.npu: etnaviv has been instantiated on a NPU, for which the UAPI is still experimental
> > [    3.386818] [drm] Initialized etnaviv 1.4.0 for etnaviv on minor 0
> > [    3.390018] stackdepot: allocating hash table of 131072 entries via kvcalloc
> > [    3.399113] [drm] Initialized imx-lcdif 1.0.0 for 32fc6000.display-controller on minor 1
> > [    3.523021] Console: switching to colour frame buffer device 180x56
> > [    3.539272] imx-lcdif 32fc6000.display-controller: [drm] fb0: imx-lcdifdrmfb frame buffer device
> 
> Thank you for sharing this.
> 
> One last question: Is this log from the mainline kernel?
> If so, did you apply any external patches to the GPU driver to make it work?

Yes, that was from a v6.14-rc1 kernel. I'm compiling v6.15-rc1 now. I
haven't applied any patch to the GPU driver.

> > > [   10.201152] systemd[1]: Starting Load Kernel Module drm...
> > >
> > > I have not yet identified a conclusive reason for GNOME Shell's failure to start.
> > >
> > > However, since my primary objective was to preview the camera output
> > > on the display, I initially suspected the issue might be related to the HDMI
> > > display, as I encountered errors while using autovideosink. After your
> > > confirmation that the display was functioning correctly, I explored alternative
> > > video sinks and was able to successfully achieve a working preview using
> > > fbdevsink.
> > >
> > > I may revisit the GNOME Shell issue when time permits. If you have any
> > > suggestions or insights regarding the compositor or GPU setup failure, I’d be
> > > happy to take them into consideration.
> > >
> > > > > > > Could you please help me out or point me in the right direction?
> > > > > > >
> > > > > > > Thank you for your time.

-- 
Regards,

Laurent Pinchart