How DisplayPort Converts AUX to I2C Commands

This article explains how a DisplayPort (DP) source encapsulates and converts bidirectional Auxiliary (AUX) channel transactions into standard I2C commands. It covers the protocol-level mapping known as I2C-over-AUX, detailing how the source frames I2C START and STOP conditions, transfers data payloads, and handles peripheral responses such as ACKs, NACKs, and bus stretching via DP sink hardware.

The Purpose of I2C-over-AUX

DisplayPort does not include dedicated physical I2C lines (SCL and SDA) for display configuration channels like DDC/CI or EDID reading. Instead, DisplayPort features an AC-coupled, differential Auxiliary (AUX) Channel that operates at 1 Mbps using Manchester II encoding. To maintain backward compatibility with legacy display peripherals that rely on standard I2C protocols, the DisplayPort standard defines a method called "I2C-over-AUX." This protocol allows a DP source to tunnel native I2C transactions across the high-speed differential AUX pair.

Packet Encapsulation and Command Encoding

When an application or graphics driver requests an I2C operation (such as reading an EDID at address 0x50), the DisplayPort source controller translates the operation into an AUX Request packet. Each AUX packet contains:

  1. A 4-bit Command Code: The DP standard designates specific command codes for I2C access, distinguishing between I2C-over-AUX Write (0000_b), I2C-over-AUX Read (0001_b), and I2C-over-AUX Write Status (0010_b).
  2. A 20-bit Address Field: The source places the 7-bit target I2C slave address into the least significant bits of this field, leaving the higher bits cleared to zero.
  3. A Length Field: Indicates the number of bytes to transfer (from 1 up to 16 bytes per AUX packet).
  4. Data Payload: The raw data bytes being written to or read from the peripheral.

Managing Bus States: The MOT (Middle-of-Transaction) Bit

Standard I2C communications rely on physical bus states—specifically START, Repeated START, and STOP conditions. Because the AUX channel is packetized and does not feature persistent line levels, the DisplayPort source simulates these states using the MOT (Middle-of-Transaction) bit embedded within the AUX command header:

  • I2C START Condition: When the source begins an I2C sequence, it issues an I2C-over-AUX command with the MOT bit set to 1.
  • Middle Transactions: Subsequent read or write packets maintain the MOT bit as 1, signaling to the sink device that the logical I2C bus should remain owned and not release a STOP condition.
  • I2C STOP Condition: When the final byte is transferred, the source sends the concluding AUX request packet with the MOT bit cleared to 0. This informs the receiving device that it must release the bus and generate an I2C STOP condition.

Hardware Decoding at the Sink Device

The physical translation to real I2C signals occurs inside the DisplayPort sink device (the display controller, scalar chip, or an active DP-to-HDMI/VGA converter):

  1. AUX Transceiver to I2C Master: The sink controller features an integrated I2C master core alongside its DP AUX receiver.
  2. Signal Generation: Upon receiving an I2C-over-AUX command, the sink's internal logic drives physical SCL (clock) and SDA (data) pins. It outputs the START condition, clocks out the 7-bit slave address plus the R/W bit, and clocks the payload data to or from the physical bus.
  3. Response Forwarding: The sink monitors the SDA line for the slave device's physical ACK or NACK bit and maps it into an AUX Reply packet sent back to the source.

Handling Timing and Bus Latency

Standard I2C runs at 100 kHz or 400 kHz, which is significantly slower than the 1 Mbps AUX channel. Additionally, I2C slaves may perform clock stretching to delay transmission while processing data. The DP protocol manages this speed disparity using specialized AUX replies:

  • AUX ACK: Returned to the source when the I2C slave acknowledges the byte.
  • AUX NACK: Returned when the I2C slave fails to acknowledge its address or data, allowing the source to abort or retry.
  • AUX DEFER: If the physical I2C transaction is still in progress because of clock stretching or slow bus speeds, the sink cannot immediately return the requested data within the DP AUX timeout window (typically 300 to 400 microseconds). In this case, the sink responds with AUX DEFER. The DP source detects this deferral, pauses briefly, and automatically retries the request until the sink completes the physical I2C read or write and can return an AUX ACK with the payload.