AnsweredAssumed Answered

Bugs fixed in Linux imx6 HDMI driver

Question asked by JONATHAN OLSON on Nov 6, 2015
Latest reply on Aug 29, 2018 by Tanner Black

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

Outcomes