LVDS/DSI and EDID

Technical Support
, ,
1

The Toradex documentation makes reference to the fact that LVDS and DSI support EDID/DDC for display resolutions, but comment that the typical use case is to hard code this information in the device tree.

Can you recommend any resources/information on how one might actually support EDID “in hardware” for these interfaces? I know for HDMI there is an embedded I2C channel used to read the data from an EEPROM - how is this set up/designated for say, an LVDS or DSI display, assuming that is even possible?

Or, is this just referring to that it’s possible to “inject” an EDID blob via the kernel command line, and there is no capability to have (say) a display adapter board with an EEPROM that can be read automatically and allow for auto-setting of resolution?

Thanks!

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

Hardware EDID Support for LVDS and DSI Displays

Based on the Toradex documentation, EDID support varies significantly between different display interfaces and modules.

HDMI EDID Support

For HDMI interfaces, EDID is fully supported in hardware(1). The documentation states that “a connected monitor provides the modes it is capable of displaying and its preferred mode through DDC/EDID”(1). No configuration is needed as “the kernel then decides on the mode depending on the capabilities of the monitor and the SoM”(1).

LVDS EDID Implementation

For LVDS displays, the documentation indicates that EDID support exists but is typically not used in practice(1). The documentation notes that LVDS “Supports EDID (Software)” but clarifies that “the common use case is to hard-code the mode information in the device-tree/panel-driver or the overlay”(1).

However, there is evidence that hardware EDID can be implemented for LVDS. The SMARC module design guide provides detailed information about implementing EDID EEPROM for LVDS displays. It explains that EDID data can be stored in an EEPROM accessed via I2C, and this EEPROM may reside either on the display assembly or elsewhere in the path between the SoC and display.

The implementation requires:

  • An I2C interface (I2C_LCD) between the module and display
  • Level translation (typically 3.3V levels for the display)
  • An EDID EEPROM at I2C address 0x50

DSI EDID Support

For DSI displays on modules like Verdin iMX8M Plus, the documentation shows that DSI-to-HDMI adapters support EDID(1), but direct DSI panel connections typically require hardcoded timing information in device tree overlays(1).

Practical Implementation

The documentation suggests that while hardware EDID is theoretically possible for LVDS and some DSI configurations, the standard practice is device tree configuration because:

  1. Complexity: Hardware EDID requires additional I2C infrastructure and level translation
  2. Reliability: Hardcoded timings in device trees are more predictable
  3. Cost: Adding EDID EEPROM increases BOM cost

For LVDS specifically, if you want to implement hardware EDID, you would need to:

  • Include the I2C_LCD interface in your carrier board design
  • Add level translation circuitry (back-to-back FETs or dedicated buffer like FXMA2102)
  • Include an EDID EEPROM (such as AT24HC02) at I2C address 0x50
  • Ensure your display timing software can read and interpret the EDID data

Recommendation

For most applications, Toradex recommends using device tree overlays to specify display timings rather than implementing hardware EDID for LVDS and DSI interfaces(1). This approach is more reliable, cost-effective, and easier to debug than hardware EDID implementations.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.