Lately, I've been fixing some serious issues with the imx6 HDMI driver. These issues have appeared in several previous discussions, however I've not yet seen any official resolution to this issue. Attaching a DVI or VGA monitor which does not support standard HDMI resolutions like 720p or 1080p caused the kernel to hang or crash. Attaching a DVI monitor through a HDMI-to-DVI adapter often caused the imx6 driver to detect bogus plugin events causing repeated flashing of the display.
Here are the issues I've tracked down in the past couple of days and patches which address these issues.
I'm attaching my patches to mxc_hdmi.c and mxc_edid.c which allows me to work with monitors that only support 800x600 and 1024x768. However, I still have an issue with a 1024x768 resolution on one of my monitors. This monitor displays the initial 1024x768@60 resolution generated by u-boot, but after linux boots, the same 1024x768@60 resolution fails. Fortunately, the monitor works with a 1024x768@70 resolution which is provided by the EDID.
Original Attachment has been moved to: mxc_hdmi.patch.zip
I am using Boundary Devices Nitrogen 6 Max board and i am facing the same issue as to how to add the custom HDMI display timing in the Linux kernel. Can anybody here share how to do this custom setting?
I have successfully tested your patches, and I will share this input to the developers team in order to be evaluated and possibly to be added to next bsp release. Thanks for your inputs.
Hi Johnatan and all,
many thanks, really,
I applied your patch where possible, on kernel 3.14.28, that seems to be slightly different.
Seems it is producing some good results, but still studying it.
I have some questions:
for what kernel branch/version is the related patch ?
- if ((H_SIZE / 16) == (V_SIZE / 9))
+ if (H_SIZE * 9 / 16 == V_SIZE)
mode->vmode |= FB_VMODE_ASPECT_16_9;
Are these lines producing the same results btw ?
1) These patches are against branch 3.14-1.0.x-mx6-sr of the repository at https://github.com/SolidRun/linux-fslc.git.
2) Either aspect ratio form would work for standard 16:9 or 4:3 resolutions. I rewrote this expression when tracking down the errors in matching logic for the FB_VMODE_ASPECT_16_9 FB_VMODE_ASPECT_4_3 bits. Turns out the problem was that it was not setting these bits for the resolutions added from the EDID.
One issue I'm not certain about is the significance of the HDMI_PHY_RX_SENSEx and HDMI_PHY_HPD bits since I don't have any hardware documentation on these signals. The previous logic did not work with a DVI monitor connected to the HDMI interface, since it was checking a bit in the EDID to determine if it was connected via HDMI or DVI. Obviously, whether the monitor is DVI or HDMI doesn't indicate how it's connected to the iMX6 processor. My updated logic which only checks HDMI_PHY_RX_SENSEx bits works for my use case where either an HDMI or DVI monitor is connected to an HDMI port on the processor. However, I don't have a board with an actual DVI port (does anybody still use DVI?).
i applied part of your patch ojn 3.14.28., really many thanks.
I have mainly some buffer underrun or overrun on HDMI audio.
Since i also hear audio faster and slower, I suspect this is due to bad resolution sync.
Maybe you know,
- Is audio working only for certain CEA modes (extension block) ?
- so, if the above assumtion is correct, i should keep CEA enabled always for audio, correct ?