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

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

[-- Attachment #1: Type: text/plain, Size: 9878 bytes --]


On 24-02-2026 13:54, Ville Syrjälä wrote:
> On Fri, Feb 20, 2026 at 10:31:10AM +0530, Murthy, Arun R wrote:
>> 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.
> Tried it where/when/what? I still have no idea what you're trying to
> solve here.
The issue is https://issues.redhat.com/browse/RHEL-120913 In aux_xfer 
function intel_dp_aux_wait_done times out and fails. The retry count is 
5. eDP is plugged in and powered-up, so should respond.

We tried to increase the retry count to 1000, even that didnt help, 
issue is still reproduced. The solution to this issue is what we are 
trying to fix in this issue, explained below.

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

>> 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
> We already do that (intel_dp_set_power()). Though even then we seem
> to doing the OUI DPCD stuff before the D3->D0 transition. So that still
> assumes that any random DPCD accesses work while in D3. Why we do it in
> that order I have no idea.
>
>>> 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.
> D3_AUX_ON isn't even a thing in the older DP versions.
>
>> 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

[-- Attachment #2: Type: text/html, Size: 12095 bytes --]