Re: [PATCH] drm/i915/dp: On DPCD init/caps wake the DPRx

["Murthy, Arun R" <arun.r.murthy@intel.com>]

On 20-02-2026 08:41, Ville Syrjälä wrote:
> On Thu, Feb 19, 2026 at 08:42:49PM +0530, Murthy, Arun R wrote:
>> On 19-02-2026 20:23, Ville Syrjälä wrote:
>>> On Thu, Feb 19, 2026 at 03:13:26PM +0530, Arun R Murthy wrote:
>>>> Before reading the DPCD caps for eDP wake the sink device and for DP
>>>> after reading the lttpr caps and before reading the dpcd caps wake up
>>>> the sink device.
>>> Why?
>> Just to ensure that sink is awake.
>> On eDP init, as part of reading the DPCD caps during the AUX transaction
>> its sometimes observed that the AUX tx fails with timeout. In those
>> scenarios even if the retry is increased to 1000 AUX tx will not
>> succeed. May be that sink is in sleep or unknown state.
>> Spec DP2.1 sec 2.11.7.1.5.8 says if there is a NO REPLY for AUX tx this
>> can be due to illegal cmd or sink in low power state.
> That section is specifically about i2c-over-aux.
>
> Generally we have retries and appropriate timeouts to deal with AUX
> having to wake up from low power state.
We have tried this for 1000 times and didnt work.
This leaves a question as to why not replying even after 1000 trials. 
Answer might be the command/request is wrong for which sink is not able 
to understand. But its not the case.
So the other thinking is "is the sink in low power mode" ?
In link training sections of the spec it says before starting link 
training ensure that sink is up and provides steps to wake the sink device.
Example: Section 3.5.2.16

> Although, I suppose we might consider switching to D0 for eg. duration
> of the detection to make sure none of the AUX transactions there take
> too long. That *might* make things a bit faster (but we'd need actual
> numbers to show that). And once we're done we should switch back to D3
> to save power.
I am doing that in the patch. I switch to D0 and then immediately switch 
to D3_AUX_ON state.
The reason for reading DP_SET_POWER in a loop is the spec says that DPTX 
should try for atleast 3 times as DPRX is waking from power saving state 
which takes 1ms.
Section 2.3.5 explains the DPRX AUX_CH state and says that DPRX shall 
avoid not issuing a reply when waking from a power saving state.
This section also explains the DPRX AUX_CH state on RESET. Usually this 
is the state on power on, and in the issue that we are referring to can 
also be co-related to this state as its during the kernel boot/driver 
probe.
>   Perhaps we could then also use a larger timeout just for
> the DP_SET_POWER AUX accesses,
spec mention on this time as 1ms, to allow sink to exit low power mode 
or AUX_CH Receiver is monitoring differential signals (sec 2.3.1.2)
> and all other AUX accesses could assume
> that the thing is awake and use a smaller timeout. Although the LTTPR
> mess probably means we can't actually reduce the timeouts :/
>
> Another slight snag in the current way of doing things is that IIRC
> we never put a device into D3 after the initial detection, unless we
> actually turned the main link on and off again. That's also something
> that could get fixed by always putting the device into D3 after
> detection. But to do that stuff safely we'd need some way to make sure
> nothing else (eg. the main link) requires the D0 at that time. So some
> kind of D0 vs. D3 reference counting scheme might be needed.
>
> I did consider implementing something like that years ago, but dealing
> with the reference counting seemed too messy at the time. And since I
> never implemented it I never measured it either. Perhaps things are a
> bit cleaner these days to make that easier. Dunno.
>
>> So in this patch we are trying to wake the sink device.
> Still the same question remains: Why? What *exactly* is the problem
> you're trying to solve here?
The problem we are trying to solve is that the AUX_CH Requested is not 
succeeding even after sending multiple AUX requests and fails to get a 
response from the AUX_CH Replier.
Increasing the retry count to a large value (1000) is also not helping.

In order to solve this went through the spec in detail, able to get some 
information scattered over multiple sections leaving us to a thinking 
that may be AUX_CH Replier in low power state. Also in link training 
section(3.5.2.16) it says source should wake the sink before starting 
link training.

Thanks and Regards,
Arun R Murthy
-------------------

>> Thanks and Regards,
>> Arun R Murthy
>> -------------------
>>
>>>> Closes: https://issues.redhat.com/browse/RHEL-120913
>>>> Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
>>>> ---
>>>>    drivers/gpu/drm/i915/display/intel_dp.c       | 41 +++++++++++++++++++
>>>>    drivers/gpu/drm/i915/display/intel_dp.h       |  1 +
>>>>    .../drm/i915/display/intel_dp_link_training.c |  3 ++
>>>>    3 files changed, 45 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
>>>> index 454e6144ee4e..2fbb947e6cc8 100644
>>>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>>>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>>>> @@ -4705,6 +4705,45 @@ intel_edp_set_sink_rates(struct intel_dp *intel_dp)
>>>>    	intel_edp_set_data_override_rates(intel_dp);
>>>>    }
>>>>    
>>>> +void intel_dp_wake_sink(struct intel_dp *intel_dp)
>>>> +{
>>>> +	u8 value = 0;
>>>> +	int ret = 0, try = 0;
>>>> +
>>>> +	intel_dp_dpcd_set_probe(intel_dp, false);
>>>> +
>>>> +	/*
>>>> +	 * 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
>>>> +	 */
>>>> +	while (try < 10 && ret < 0) {
>>>> +		ret = drm_dp_dpcd_readb(&intel_dp->aux, DP_SET_POWER, &value);
>>>> +		/*
>>>> +		 * If sink is in D3 then it may not respond to the AUX tx so
>>>> +		 * wake it up to D3_AUX_ON state
>>>> +		 */
>>>> +		if (value == DP_SET_POWER_D3) {
>>>> +			/* After setting to D0 need a min of 1ms to wake(Spec DP2.1 sec 2.3.1.2) */
>>>> +			drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER,
>>>> +					   DP_SET_POWER_D0);
>>>> +			fsleep(1000);
>>>> +			drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER,
>>>> +					   DP_SET_POWER_D3_AUX_ON);
>>>> +			break;
>>>> +		} else if ((value == DP_SET_POWER_D0) ||
>>>> +			   (value == DP_SET_POWER_D3_AUX_ON)) {
>>>> +			/* if in D0 or D3_AUX_ON exit */
>>>> +			break;
>>>> +		}
>>>> +		/* Sink in D0 or even if read fails a minimum of 1ms is required to wake and respond */
>>>> +		fsleep(1000);
>>>> +		try++;
>>>> +	}
>>>> +
>>>> +	intel_dp_dpcd_set_probe(intel_dp, true);
>>>> +}
>>>> +
>>>>    static bool
>>>>    intel_edp_init_dpcd(struct intel_dp *intel_dp, struct intel_connector *connector)
>>>>    {
>>>> @@ -4713,6 +4752,8 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp, struct intel_connector *connector
>>>>    	/* this function is meant to be called only once */
>>>>    	drm_WARN_ON(display->drm, intel_dp->dpcd[DP_DPCD_REV] != 0);
>>>>    
>>>> +	intel_dp_wake_sink(intel_dp);
>>>> +
>>>>    	if (drm_dp_read_dpcd_caps(&intel_dp->aux, intel_dp->dpcd) != 0)
>>>>    		return false;
>>>>    
>>>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h b/drivers/gpu/drm/i915/display/intel_dp.h
>>>> index b0bbd5981f57..3f16077c0cc7 100644
>>>> --- a/drivers/gpu/drm/i915/display/intel_dp.h
>>>> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
>>>> @@ -232,6 +232,7 @@ bool intel_dp_dotclk_valid(struct intel_display *display,
>>>>    bool intel_dp_joiner_candidate_valid(struct intel_connector *connector,
>>>>    				     int hdisplay,
>>>>    				     int num_joined_pipes);
>>>> +void intel_dp_wake_sink(struct intel_dp *intel_dp);
>>>>    
>>>>    #define for_each_joiner_candidate(__connector, __mode, __num_joined_pipes) \
>>>>    	for ((__num_joined_pipes) = 1; (__num_joined_pipes) <= (I915_MAX_PIPES); (__num_joined_pipes)++) \
>>>> diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>>>> index 54c585c59b90..cbb712ea9f60 100644
>>>> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>>>> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
>>>> @@ -270,6 +270,9 @@ int intel_dp_init_lttpr_and_dprx_caps(struct intel_dp *intel_dp)
>>>>    		lttpr_count = intel_dp_init_lttpr(intel_dp, dpcd);
>>>>    	}
>>>>    
>>>> +	/* After reading LTTPR wake up the sink before reading DPRX caps */
>>>> +	intel_dp_wake_sink(intel_dp);
>>>> +
>>>>    	/*
>>>>    	 * The DPTX shall read the DPRX caps after LTTPR detection, so re-read
>>>>    	 * it here.
>>>> -- 
>>>> 2.25.1