Hi David,
To be honest, it is always quite a challenge to troubleshoot the display issues just from email or message, especially when they are custom-made ones, as there is virtually no way to replicatre the issue, but i will try my best.
A couple of things to reset first, because the AI assistant sent you down some wrong paths:
There is no lcdif1 on iMX95, so you were correct to question it, iMX95 uses:
DPU (display-controller@4b400000) → pixel-interleaver (bridge@4b0d0000) → display-pixel-link → DSI host (dsi@4acf0000) → panel. Stop looking for LCDIF and stop adding clocks under dpu - clocking on iMX95 is handled by SCMI/DPU firmware, not by anything you set in the overlay.
What “CLK” dropping down could actually mean: the DSI D-PHY only drives the clock lane once the DSI host is actively streaming video from the DPU pipeline. That brief 200mV→1.2V→0V blip is the lane initializing and then going idle because the host never started HS clocking.
Your panel powering up and passing BIST unfortunately tells us nothing here - BIST is generated internally by the panel and doesn’t require any DSI input. So the clock lane being dark is a sign of the pipeline upstream of the DSI host not being fully assembled, not a missing clock config.
The real issue is your OF graph. Your prepare runs but the pipeline never reaches a streaming enable.
Two things in your overlay are suspect:
-
From what i see, you only wired the DSI output (port@1 → panel). You never confirmed the DSI imput (port@0) is still connected to the pixel-link upstream. On iMX95 the DSI host needs a valid input endpoint or it will bail out - the NXP failure mode for exactly this is imx95-mipi-dsi 4acf0000.dsi: No valid input endpoint found ... probe failed with error -22.
-
The Failed to create device link (0x180) line and the Fixed dependency cycle(s) messages are on BSP 7.6.x which is most likely noise, not your root cause. We have another iMX95 case on this same BSP where that exact devlink warning appears even on a confirmed-working reference display setup, proven by bypassing the whole pipeline with the DSI host’s internal pattern generator. So don’t chase the devlink warning; chase the endpoint graph.
On the panel driver: since you forked rm67191 (a 4-lane video-mode DSI panel), double-check inside your driver that you’re actually setting, for the YTC700:
dsi->lanes = 4;dsi->format (rm67191 uses MIPI_DSI_FMT_RGB888)dsi->mode_flags - rm67191 sets MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_HSE. If your panel needs a burst/non-burst or sync-pulse mode different from rm67191’s, a mismatch here can prevent the host from starting HS clocking even with a valid pipeline.- The DSI HS bit clock is derived from your panel’s pixel clock × bpp / lanes. Confirm your mode’s
clock (pixel clock in kHz) in get_modes is a sane value for 1024×600 - a bogus pixel clock can leave the PHY unable to lock and the clock lane dark.
Concrete next step: please post the output of:
for p in /proc/device-tree/soc/dsi@4acf0000/ports/port@*/endpoint/remote-endpoint; do echo "$p:"; xxd "$p"; donecat /sys/class/drm/card0*/status 2>/dev/nullls /sys/class/drm/card0/crtc* 2>/dev/nulldmesg | grep -iE 'dsi|crtc|bridge|no valid|endpoint'
If you see No valid input endpoint or an empty crtc list, that confirms the graph break and we fix the overlay’s ports wiring. If the graph is intact, we move to the panel driver’s lane/format/mode_flags.
Also always please rely heavily on the existing device tree overlays that we have, those should be the primary reference point.
Question: I might wanna know if you used any driver for the display? Have you received a bunch of those, or just a handful number for prototyping?
Sorry for a delayed response, i had to take my time to make sure i understand the issue,
Once again thanks for you patience, and feel free to text me back.
Sincerely,
Ruslan Nurimbetov
Ruslan Nurimbetov
Toradex
Hi David,
To be honest, it is always quite a challenge to troubleshoot the display issues just from email or message, especially when they are custom-made ones, as there is virtually no way to replicatre the issue, but i will try my best.
A couple of things to reset first, because the AI assistant sent you down some wrong paths:
There is no lcdif1 on iMX95, so you were correct to question it, iMX95 uses:
DPU (display-controller@4b400000) → pixel-interleaver (bridge@4b0d0000) → display-pixel-link → DSI host (dsi@4acf0000) → panel. Stop looking for LCDIF and stop adding clocks under dpu - clocking on iMX95 is handled by SCMI/DPU firmware, not by anything you set in the overlay.
What “CLK” dropping down could actually mean: the DSI D-PHY only drives the clock lane once the DSI host is actively streaming video from the DPU pipeline. That brief 200mV→1.2V→0V blip is the lane initializing and then going idle because the host never started HS clocking.
Your panel powering up and passing BIST unfortunately tells us nothing here - BIST is generated internally by the panel and doesn’t require any DSI input. So the clock lane being dark is a sign of the pipeline upstream of the DSI host not being fully assembled, not a missing clock config.
The real issue is your OF graph. Your prepare runs but the pipeline never reaches a streaming enable.
Two things in your overlay are suspect:
-
From what i see, you only wired the DSI output (port@1 → panel). You never confirmed the DSI imput (port@0) is still connected to the pixel-link upstream. On iMX95 the DSI host needs a valid input endpoint or it will bail out - the NXP failure mode for exactly this is imx95-mipi-dsi 4acf0000.dsi: No valid input endpoint found ... probe failed with error -22.
-
The Failed to create device link (0x180) line and the Fixed dependency cycle(s) messages are on BSP 7.6.x which is most likely noise, not your root cause. We have another iMX95 case on this same BSP where that exact devlink warning appears even on a confirmed-working reference display setup, proven by bypassing the whole pipeline with the DSI host’s internal pattern generator. So don’t chase the devlink warning; chase the endpoint graph.
On the panel driver: since you forked rm67191 (a 4-lane video-mode DSI panel), double-check inside your driver that you’re actually setting, for the YTC700:
dsi->lanes = 4;
dsi->format (rm67191 uses MIPI_DSI_FMT_RGB888)
dsi->mode_flags - rm67191 sets MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_HSE. If your panel needs a burst/non-burst or sync-pulse mode different from rm67191’s, a mismatch here can prevent the host from starting HS clocking even with a valid pipeline.
The DSI HS bit clock is derived from your panel’s pixel clock × bpp / lanes. Confirm your mode’s clock (pixel clock in kHz) in get_modes is a sane value for 1024×600 - a bogus pixel clock can leave the PHY unable to lock and the clock lane dark.
Concrete next step: please post the output of:
for p in /proc/device-tree/soc/dsi@4acf0000/ports/port@*/endpoint/remote-endpoint; do echo "$p:"; xxd "$p"; donecat /sys/class/drm/card0*/status 2>/dev/nullls /sys/class/drm/card0/crtc* 2>/dev/nulldmesg | grep -iE 'dsi|crtc|bridge|no valid|endpoint'
If you see No valid input endpoint or an empty crtc list, that confirms the graph break and we fix the overlay’s ports wiring. If the graph is intact, we move to the panel driver’s lane/format/mode_flags.
Also always please rely heavily on the existing device tree overlays that we have, those should be the primary reference point.
Question: I might wanna know if you used any driver for the display? Have you received a bunch of those, or just a handful number for prototyping?
Sorry for a delayed response, i had to take my time to make sure i understand the issue,
Once again thanks for you patience, and feel free to text me back.
Sincerely,
Ruslan Nurimbetov
Ruslan Nurimbetov
Toradex
