This issue is the same described in HDMI HPD disconnect does not disable HDMI Data and Clock - Technical Support - Toradex Community, but it affects BSP 7 (We tried both 7.2.0 and 7.1.0 releases). BSP 6 (6.8.2) still works correctly, however we would like to switch to BSP 7 because some applications – chromium in particular – using the previous BSP, have screen flickering issues which are gone with the new BSP.
We have already verified that the code changes suggested in the linked solution, are still in place in the linux-toradex 6.6 kernel, but they don’t seem to have any effect on the HDMI output.
The HDMI output behavior, for BSP 7, went back to the same as described in the linked question (Data and Clock stays active after the HPD level is low (disconnect).
We are still using the same hardware setup as described in the previous question.
Thank you in advance for your help.
Best regards,
Dario
Hi, I’m the Toradex AI Assistant.
I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.
Did you like my answer? 
Hello Dario,
Thank you for your detailed description and for referencing your previous investigation.
Your findings are consistent with known HDMI hotplug detect (HPD) handling regressions in BSP 7 for the i.MX 8M Plus platform. As you observed, the HPD disconnect does not properly disable HDMI Data and Clock when using BSP 7.x, even though it works as expected with BSP 6.8.2. This issue has also been documented in other community posts, such as “Weston and Chromium crashes on iMX8MP after HDMI connector little movements/vibrations on touch”.
Important context:
- The i.MX 8 series modules use the Linux kernel’s DRM/KMS subsystem to manage HDMI output in both BSP 6 and BSP 7. Updates or regressions in this stack with BSP 7 may impact the actual hardware response to HPD events (reference).
- Some issues could arise from changes or updates to the Weston compositor, the DRM subsystem, or related kernel drivers between BSP 6 and BSP 7.
Suggestions for further debugging:
- Collect boot and runtime kernel logs (dmesg) for both BSP 6.8.2 and BSP 7.x while performing the HDMI disconnect/reconnect event. This may reveal differences in how HPD events are handled.
- Compare the relevant kernel DRM/HDMI log outputs for handling HPD interrupts.
- Examine user-space components, such as Weston or the compositor in use, as sometimes higher-level display managers might handle the hotplug differently.
- If you have a custom device tree or overlays, verify that there are no differences regarding HDMI settings between BSP 6 and BSP 7.
Unfortunately, if the code changes referenced in the earlier solution are still present in the 6.6 kernel for BSP 7 and do not resolve the issue, this points to a potential regression or behavioral change in the HDMI kernel stack or associated user-space components.
For your reference, these resources summarize the handling and changes around HDMI and display outputs on the i.MX 8 series:
If capturing and comparing logs highlights driver differences, you may want to investigate BSP 7-specific overlays, kernel patches, or configuration changes related to DRM, HDMI, or display hotplug support.
Please let me know if you need additional information about HDMI or display handling for your specific module. I’ll be happy to assist further!
Best regards,
Toradex AI Assistant.
Collin Bos, 18 Jun 2025, 09:50
Dear Mr. Gallucci,
Apologies for the delay in replying. I am in conversation with our domain expert regarding the HDMI HPD issue on BSP7. On our side the solution is still in an early stage and we need to check, whether this is working on the upstream kernel. I will get back to you with further information as soon as they are provided.
Best regards,
Collin Bos
Toradex
Dear Mr Bos
What is the state of the case?
Best regards,
Christian Mueller
Collin Bos, 27 Jun 2025, 08:08
Dear Mr Müller,
I wanted to provide a quick update regarding the issue we’re currently investigating.
We are actively looking into it, and at this point, it appears to resemble a problem we encountered previously. At that time, the root cause was traced back to the NXP codebase, and our resolution involved a workaround rather than a definitive fix. Given that we are now working with a different kernel version, it’s possible that the underlying constraints have changed, rendering our previous workaround ineffective.
If this is the case, we may once again be facing the consequences of limitations or flaws in the original NXP implementation.
We’ll continue our analysis and will keep you updated as soon as we have more concrete findings or a proposed solution.
Best regards,
Collin Bos
Toradex
Dear Mr. Müller,
We believe we are close to finding the solution to this issue. We are currently working on this with high priority.
Best regards,
Collin
