we are currently having an issue where our 1280x800 hdmi screen is not displaying anything via hdmi. This only happens occasionally probably ~20% of the time. The board detects that a display is present however has an edid error then display at the output of “dmesg | grep drm” We had previously posted about this before here: HDMI failing to recognize screen on Apalis-IMX8 - #4 by jeremias.tx
We had thought that updating to torizoncore 6 had fixed it but it is now starting to occur again. We are currently using Torizoncore 6.4+build.5 with the imx8qm-apalis-v1.1-ixora-v1.2 device tree overlay and adding the apalis-imx8_hdmi_overlay device tree.
This only happens occasionally probably ~20% of the time.
Just to clarify are you saying that out of all your displays 20% are affected? Or are you saying that a single specific display will fail 20% of the time? Basically, if a specific display exhibits this issue will it always exhibit this issue going forward?
Also have you seen this issue with other HDMI displays? Or is it just this specific model?
The fact this only happens sometimes is strange. I mean all we have to go off of is the error messages. If we assume these are true then that would mean your displays have a bad EDID sometimes.
This has happened across multiple displays but it is the same brand. It happens ~20% of the time when we start our systems. Leading to us needing to restart the system multiple times until everything is successful.
Is there other information/logs that would be helpful for you?
This has happened across multiple displays but it is the same brand. It happens ~20% of the time when we start our systems. Leading to us needing to restart the system multiple times until everything is successful.
Hmm okay so the EDID isn’t actually bad then since restarting can fix the issue. I recall in your previous thread you mentioned:
We are currently running the screen and compute module off of a single power supply
I understand this to mean that both module and display get powered on at the same time by the same power supply, yes?
Maybe, and I’m just theorizing now, there’s a race condition here. Perhaps the module probes the display for EDID information, but in some cases the display is still in state of starting up and then for some reason it provides garbage EDID information to the module.
This might explain why you only see this issue a fraction of the time and why restarting the system can “fix” the issue.
Can you try putting the display and module on separate power supplies. Power the display on first and make sure it’s fully-powered on, then power on the module. Can you see if this setup has any effect at all on the issue?
We also believe that this is creating a race condition after looking at it a bit more. We tried powering the screen on first and then the compute module and everything seems to work in that scenario.
Is there a way that we could delay the module from probing the display?
I have tried to change the status of the hdmi connection when the unit is on to try and restart the hdmi connection with no success by running:
echo off > /sys/class/drm/card0-HDMI-A-1/status
echo on > /sys/class/drm/card0-HDMI-A-1/status
We also have attempted to restart the system via reboot in the command line to no success there either.
I tried feeding detect to status and it did not update. The status is still stuck at unknown. I tried to do on and on-digital which updates the status to connected but doesn’t have any impact. Oddly enough feeding detect into status occasionally crashed the system and the screen then booted up as expected.
This is the output of dmesg | grep drm after feeding detect into the hdmi status which still shows the edid error but added other error messages such as “PMA ouput macro power up failed” and the registers failing to read the registers:
Hmm seems like that’s not enough or maybe the entire graphics stack needs to be restarted for anything to change here. Though I’m not sure how to do that without restarting the entire system. Could you try if the following has any affect:
To close this out, it was a bad edid issue as well as weston not using the proper resolution. Used the kernel command line and proper edid blob to set that and created our own weston.ini file specifying resolution and everything works like a charm!
they had good edids. The problem was initiated because the power of the board and the screens were coming from the same supply. This seemed to cause a race condition where the edid blob was getting lost due to bring-up time of one of the components. I was able to pull the edid during one of the occasions the screen worked and then just inject that into the drm to use instead of reading the edid from the screen itself.
Interesting, I guess my race condition theory from earlier was on the right track. Well it’s good to know this can happen for future reference, appreciate your analysis here.
