STRUCT DRM_DP_AUX(9)

🦋 NAME 🦋

struct drm_dp_aux — the DisplayPort AUX channel, bestie 💅

okay so real talk, this is the manual page for struct drm_dp_aux from the Kernel API Manual. she's the whole AUX-channel situation and she has a lot of fields, so grab a snack 🍓

---

✨ SYNOPSIS ✨

struct drm_dp_aux {
    const char *name;
    struct i2c_adapter ddc;
    struct device *dev;
    struct drm_device *drm_dev;
    struct drm_crtc *crtc;
    struct mutex hw_mutex;
    struct work_struct crc_work;
    u8 crc_count;
    ssize_t (*transfer)(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg);
    int (*wait_hpd_asserted)(struct drm_dp_aux *aux, unsigned long wait_us);
    unsigned i2c_nack_count;
    unsigned i2c_defer_count;
    struct drm_dp_aux_cec cec;
    bool is_remote;
    bool powered_down;
    bool no_zero_sized;
    bool dpcd_probe_disabled;
};

like, look at her. so many little fields. iconic 👑

---

🌸 MEMBERS 🌸

okay going through them one by one, no skipping, periodt:

• name — the user-visible name of this AUX channel and the I2C-over-AUX adapter.

it's also the thing that names the I2C adapter, iykyk. if you set it to NULL, then dev_name of dev gets used instead. slay.

• ddc — the I2C adapter you can use for I2C-over-AUX communication 🫶
• dev — pointer to the struct device that's the parent for this AUX channel.
• drm_dev — pointer to the drm_device that owns this AUX channel. beware, this may be NULL before drm_dp_aux_register has been called 😭

so like, set it to the drm_device that'll be using this AUX channel as early as possible. for many graphics drivers that should happen before drm_dp_aux_init, but ngl it's perfectly fine to set this field later — as long as it's assigned before calling drm_dp_aux_register. just don't forget, bestie 💀

• crtc — backpointer to the crtc that's currently using this AUX channel.
• hw_mutex — internal mutex used for locking transfers.

heads up: if the underlying hardware is shared among multiple channels, the driver needs to do additional locking to prevent concurrent access. the mutex alone is not gonna save you 🙈

• crc_work — worker that captures CRCs for each frame.
• crc_count — counter of captured frame CRCs.
• transfer — transfers a message representing a single AUX transaction.

this is the hardware-specific implementation of how transactions get executed, and the drivers must provide it. no cap.

a pointer to a drm_dp_aux_msg structure describing the transaction gets passed into this function. upon success, your implementation should return the number of payload bytes that were transferred, or a negative error-code on failure.

helpers will propagate these errors, except the -EBUSY error, which causes a transaction to be retried. on a short, helpers will return -EPROTO to make it simpler to check for failure.

the transfer function must only modify the reply field of the drm_dp_aux_msg structure. the retry logic and i2c helpers assume this is the case. fr fr, don't touch anything else 🚫

also note that this callback can be called no matter the state dev is in, and also no matter what state the panel is in. it's expected that:

• if the dev providing the AUX bus is currently unpowered, then it will power itself up for the transfer.
• if we're on eDP (using a drm_panel) and the panel is not in a state where it can respond (it's not powered or it's in a low power state), then this function may return an error, but not crash. it's up to the caller of this code to make sure that the panel is powered on if getting an error back is not OK. if a drm_panel driver is initiating a DP AUX transfer it may power itself up however it wants. all other code should ensure that the pre_enable bridge chain (which eventually calls the drm_panel prepare function) has powered the panel.

• wait_hpd_asserted — wait for HPD to be asserted.

this is mainly useful for eDP panels drivers to wait for an eDP panel to finish powering on. it's optional for DP AUX controllers to implement this function. it is required for DP AUX endpoints (panel drivers) to call this function after powering up but before doing AUX transfers — unless the DP AUX endpoint driver knows that we're not using the AUX controller's HPD. one example of the panel driver not needing to call this: if HPD is hooked up to a GPIO that the panel driver can read directly ✨

if a DP AUX controller does not implement this function, then it may still support eDP panels that use the AUX controller's built-in HPD signal by implementing a long wait for HPD in the transfer callback — though this is deprecated 💀

this function will efficiently wait for the HPD signal to be asserted. the wait_us parameter that's passed in says that we know the HPD signal is expected to be asserted within wait_us microseconds. this function could wait for longer than wait_us if the logic in the DP controller has a long debouncing time. the important thing is that if this function returns success, the DP controller is ready to send AUX transactions 👑

this function returns 0 if HPD was asserted, or -ETIMEDOUT if time expired and HPD wasn't asserted. this function should not print timeout errors to the log.

the semantics of this function are designed to match the readx_poll_timeout function. that means a wait_us of 0 means to wait forever. like readx_poll_timeout, this function may sleep 😴

NOTE: this function specifically reports the state of the HPD pin that's associated with the DP AUX channel. this is different from the HPD concept in much of the rest of DRM, which is more about physical presence of a display. for eDP, for instance, a display is assumed always present even if the HPD pin is deasserted. two different HPDs, don't mix them up bestie 🫶

• i2c_nack_count — counts I2C NACKs, used for DP validation.
• i2c_defer_count — counts I2C DEFERs, used for DP validation.
• cec — struct containing fields used for CEC-Tunneling-over-AUX.
• is_remote — is this AUX CH actually using sideband messaging.
• powered_down — if true, then the remote endpoint is powered down.
• no_zero_sized — if the hw can't use zero sized transfers (NVIDIA) 🎀
• dpcd_probe_disabled — if probing before a DPCD access is disabled.

---

💖 DESCRIPTION 💖

an AUX channel can also be used to transport I2C messages to a sink, and a typical application of that is to access an EDID that's present in the sink device. the transfer function can also be used to execute such transactions 🌈

the drm_dp_aux_register function registers an I2C adapter that can be passed to drm_probe_ddc. upon removal, drivers should call drm_dp_aux_unregister to remove the I2C adapter. the I2C adapter uses long transfers by default; if a partial response is received, the adapter will drop down to the size given by the partial response — but for this transaction only. just this one. no carryover 💅

---

👀 SEE ALSO 👀

kernel file ./include/drm/display/drm_dp_helper.h, plus all these cuties:

struct drm_dp_vsc_sdp(9), struct drm_dp_as_sdp(9), drm_dp_dsc_sink_supports_format(9), drm_edp_backlight_supported(9), drm_dp_is_uhbr_rate(9), struct drm_dp_aux_msg(9), struct drm_dp_aux_cec(9), drm_dp_dpcd_readb(9), drm_dp_dpcd_read_data(9), drm_dp_dpcd_write_data(9), drm_dp_dpcd_writeb(9), drm_dp_dpcd_read_byte(9), drm_dp_dpcd_write_byte(9), struct drm_dp_desc(9), enum drm_dp_quirk(9), drm_dp_has_quirk(9), struct drm_edp_backlight_info(9), struct drm_dp_phy_test_params(9)

---

and that's the whole page, bestie 🧚💜

this lil gem lives in the source tree at ./include/drm/display, dated October 2026 — and yes, the header up top said struct drm_dp_aux(9) the whole time, she's just like that 💅✨ mwah, go forth and AUX 🦋