Re: [PATCHv4] drm/i915/dp: On DPCD init wake the DPRx for eDP

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [High] The wake function is called after reading DPCD caps, entirely defeating the patch's purpose.
- [High] Ineffective polling loop in `poll_timeout_us` due to internal `drm_dp_dpcd_read_byte` timeouts exceeding the requested polling timeout.
- [Medium] Missing DPCD revision check before accessing the DP_SET_POWER register.
- [Medium] Unconditional write of DP_SET_POWER_D3_AUX_ON (0x5) is unsafe for eDP 1.1 panels.
- [Medium] The `poll_timeout_us` macro expands such that `ret` is modified inside the expression and overwritten by the return value, obfuscating errors.
- [Medium] The use of `true` for `sleep_before_op` unconditionally forces a 1ms delay on every eDP initialization.
--

commit fdfc8b88675078b318b600613848f0873f293de0
Author: Arun R Murthy <arun.r.murthy@intel.com>
drm/i915/dp: On DPCD init wake the DPRx for eDP

This commit attempts to fix AUX channel failures by waking up the sink
device for eDP connections. It introduces a wake sequence that is
called right before reading the DPCD capabilities.

Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/4391
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/16654

> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index 0cd5e6b5034cf..d4cc5f7e82a49 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4779,6 +4779,38 @@ intel_edp_set_sink_rates(struct intel_dp *intel_dp)
>  	intel_edp_set_data_override_rates(intel_dp);
>  }
>  
> +/* Spec says to try for 3 times, its doubled to add the software overhead */
> +#define AUX_CH_WAKE_RETRY	6
> +
> +static void intel_edp_wake_sink(struct intel_dp *intel_dp)
> +{
> +	u8 value = 0;
> +	int ret = 0;
> +
> +	/*
> +	 * Wake the sink device
> +	 * Spec DP2.1 section 2.3.1.2 if AUX CH is powered down by writing 0x02
> +	 * to DP_SET_POWER dpcd reg, 1ms time would be required to wake it up
> +	 */
> +	ret = poll_timeout_us(ret = drm_dp_dpcd_read_byte(&intel_dp->aux,
> +							  DP_SET_POWER, &value),
> +			      ret == 0, 1000, AUX_CH_WAKE_RETRY * 1000, true);

[Severity: High]
Will this polling loop actually run more than once?

The poll_timeout_us() macro is given a 6ms timeout. However,
drm_dp_dpcd_read_byte() internally retries for 16ms.

Doesn't this mean the macro's timeout will expire during the very first
read attempt, unconditionally terminating the loop prematurely?

[Severity: Medium]
Does the ret = poll_timeout_us(ret = ...) assignment clobber the actual
error codes?

Since the macro expands and evaluates the inner expression, it looks
like it overwrites the internal hardware error (like -EIO) with
-ETIMEDOUT, which could hide the true failure reason.

[Severity: Medium]
Does passing true for sleep_before_op force an unconditional 1ms delay
on every eDP initialization?

It seems this sleep happens on the hot path before any wake command has
actually been issued to the hardware.

[Severity: Medium]
Is it safe to unconditionally read the DP_SET_POWER register here
without verifying panel capabilities first?

For DPCD 1.0 panels, polling an unsupported register might trigger
guaranteed NAKs and timeout delays.

> +
> +	/*
> +	 * If sink is in D3 then it may not respond to the AUX tx so
> +	 * wake it up to D3_AUX_ON state
> +	 * If the above poll_timeout_us fails, try waking the sink.
> +	 */
> +	if (value == DP_SET_POWER_D3 || ret < 0) {
> +		/* After setting to D0 need a min of 1ms to wake (Spec DP2.1 sec 2.3.1.2) */
> +		drm_dp_dpcd_write_byte(&intel_dp->aux, DP_SET_POWER,
> +				       DP_SET_POWER_D0);
> +		fsleep(1000);
> +		drm_dp_dpcd_write_byte(&intel_dp->aux, DP_SET_POWER,
> +				       DP_SET_POWER_D3_AUX_ON);

[Severity: Medium]
Is it safe to write DP_SET_POWER_D3_AUX_ON (0x5) unconditionally to
older hardware?

For eDP 1.1 panels where 0x5 is a reserved value, could this force a
compliance violation and cause a potential link drop?

> +	}
> +}
> +
>  static bool
>  intel_edp_init_dpcd(struct intel_dp *intel_dp, struct intel_connector *connector)
>  {
> @@ -4792,6 +4824,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp, struct intel_connector *connector
>  	if (drm_dp_read_dpcd_caps(&intel_dp->aux, intel_dp->dpcd) != 0)
>  		return false;
>  
> +	intel_edp_wake_sink(intel_dp);

[Severity: High]
Is intel_edp_wake_sink() unreachable if the sink is actually asleep?

If the sink is asleep, it seems like drm_dp_read_dpcd_caps() would
fail and immediately return false, completely bypassing the new wake
function.

Could this abort initialization and leave the display broken, defeating
the purpose of the patch?

> +
>  	drm_dp_read_desc(&intel_dp->aux, &intel_dp->desc,
>  			 drm_dp_is_branch(intel_dp->dpcd));
>  	intel_init_dpcd_quirks(intel_dp, &intel_dp->desc.ident);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260907092707.1823088-1-arun.r.murthy@intel.com?part=1