From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Murthy, Arun R" <arun.r.murthy@intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
imre.deak@intel.com, suraj.kandpal@intel.com
Subject: Re: [PATCH] drm/i915/dp: On DPCD init/caps wake the DPRx
Date: Fri, 20 Feb 2026 05:11:10 +0200 [thread overview]
Message-ID: <aZfQzqdS0koZQVwg@intel.com> (raw)
In-Reply-To: <2f2a155d-3b2c-4cf9-b8cd-8116fe84f85a@intel.com>
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.
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. Perhaps we could then also use a larger timeout just for
the DP_SET_POWER AUX accesses, 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?
>
> 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
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2026-02-20 3:11 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-19 9:43 [PATCH] drm/i915/dp: On DPCD init/caps wake the DPRx Arun R Murthy
2026-02-19 10:45 ` ✗ CI.checkpatch: warning for " Patchwork
2026-02-19 10:46 ` ✓ CI.KUnit: success " Patchwork
2026-02-19 11:22 ` ✓ Xe.CI.BAT: " Patchwork
2026-02-19 14:20 ` ✗ Xe.CI.FULL: failure " Patchwork
2026-02-19 14:53 ` [PATCH] " Ville Syrjälä
2026-02-19 15:12 ` Murthy, Arun R
2026-02-20 3:11 ` Ville Syrjälä [this message]
2026-02-20 5:01 ` Murthy, Arun R
2026-02-24 8:24 ` Ville Syrjälä
2026-02-24 8:48 ` Murthy, Arun R
2026-02-24 7:48 ` [PATCHv2] " Arun R Murthy
2026-02-24 14:50 ` Imre Deak
2026-02-25 3:33 ` Murthy, Arun R
2026-02-25 5:58 ` Murthy, Arun R
2026-03-02 7:57 ` Imre Deak
2026-03-02 9:04 ` Murthy, Arun R
2026-03-02 9:20 ` Imre Deak
2026-03-10 8:52 ` Murthy, Arun R
2026-02-24 7:56 ` ✓ CI.KUnit: success for drm/i915/dp: On DPCD init/caps wake the DPRx (rev2) Patchwork
2026-02-25 6:11 ` [PATCHv3] drm/i915/dp: On DPCD init wake the DPRx for eDP Arun R Murthy
2026-02-25 6:19 ` ✓ CI.KUnit: success for drm/i915/dp: On DPCD init/caps wake the DPRx (rev3) Patchwork
2026-02-25 6:56 ` ✓ Xe.CI.BAT: " Patchwork
2026-02-25 11:20 ` ✗ Xe.CI.FULL: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aZfQzqdS0koZQVwg@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=arun.r.murthy@intel.com \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=suraj.kandpal@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox