Bugs fixed in Linux imx6 HDMI driver

[jonathanolson]

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.

1. The mxc_find_nearest_mode() is written to recursively call itself when a requested video mode did not match one of the standard video modes in its table.  The logic could easily get in an infinite recursion loop which caused a kernel hang followed by a crash when the stack was overrun.
2. The logic in mxc_hdmi.c was designed to effectively ignore the video mode timings returned by EDID parsing and instead just return the closest mode with a similar size and aspect ratio in the standard timings.  This often resulted in bogus resolutions like 720x576 when the requested resolution was 1024x768.  IMHO, the driver should always use the EDID timings if available.
3. The extended block parsing in mxc_edid_read() results in many bogus resolutions with the Asus and Dell monitors I tested.  For now, I just #ifdef'd the extended EDID parsing and only use the standard resolutions returned in the EDID.
4. The mxc_find_nearest_mode() function requires the custom VMODE bits FB_VMODE_ASPECT_4_3 and FB_VMODE_ASPECT_9_16 to be set in the fb_videomode table for matching an appropriate mode.  Unfortunately, it wasn't setting these bits when adding video modes from the EDID which prevented matching any of the EDID video timings.
5. The logic in mxc_hdmi.c required a monitor which supported the resolution provided in the mode_str of the dts file.  Since most of the dts files contained 1920x1080p resolution, the driver was pretty much DOA unless you gave it an explicit resolution on the linux command line.
6. The plugin logic didn't work when attaching a DVI monitor with a HDMI->DVI adapter.  The mxc_hdmi.c driver was erroneously using a bit in the EDID to choose betwen using the HDMI_PHY_RX_SENSEx bits and the HDMI_PHY_HPD bits.  With an HDMI->DVI adapter, this resulted in repeated plugin events every second and video resets.  I found that only checking the HDMI_PHY_RX_SENSEx bits and ignoring the HDMI_PHY_HPD bit worked for both HDMI and HDMI->DVI connections.  Hoeever, I'd appreciate if someone with more knowledge of this hardware interface reviews this.

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.

Regards,

Jonathan Olson

Original Attachment has been moved to: mxc_hdmi.patch.zip

[jgoncalves1]

Is this patch still available? I would like to try and see if it helps with an issue I am having, non-cea 1024x768

[kokshyangchin]

Hi All,

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?

[tannerb]

I am having a similar issue with a 1024x600 HDMI display. I have been looking on where to add the timings with no luck, is there a way to add these to the kernel?

[himanshugusain]

Hi Jonathon 

Does this patch configures the HDMI resolution based on EDID information 

or we still need to hard code mode_str in device tree file

Regards

Himanshu

[Bio_TICFSL]

Hi Jonathan,

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.

Regards

[angelo_d]

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:

1)

for what kernel branch/version is the related patch ?

2)

-    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 ?

Thanks

Regards,

angelo

[jonathanolson]

Hi Angelo,

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?).

Regards,

Jonathan Olson

[angelo_d]

Hi Johnatan,

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 ?

Thanks

angelo