From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: imre.deak@intel.com, Jouni Hogander <jouni.hogander@intel.com>,
intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH 1/5] drm/i915/dp: Add helpers to reset link params
Date: Fri, 22 May 2026 15:39:07 +0300 [thread overview]
Message-ID: <ahBOa-Pepaw8iTsW@intel.com> (raw)
In-Reply-To: <6b7498358483981472e9a9c6b0c76739de0b028a@intel.com>
On Fri, May 22, 2026 at 01:29:39PM +0300, Jani Nikula wrote:
> On Fri, 22 May 2026, Imre Deak <imre.deak@intel.com> wrote:
> > On Fri, May 22, 2026 at 12:36:27AM +0300, Ville Syrjälä wrote:
> >> On Mon, May 18, 2026 at 02:24:22PM +0300, Imre Deak wrote:
> >> > Add helpers to defer and handle link params resets instead of
> >> > open-coding the same. Rename intel_dp_reset_link_params() to
> >> > intel_dp_reset_link_params_force() to align its name with the new
> >> > deferred reset helpers.
> >> >
> >> > When deferring a reset, return whether a new reset was queued, used by a
> >> > follow-up change.
> >> >
> >> > Signed-off-by: Imre Deak <imre.deak@intel.com>
> >> > ---
> >> > drivers/gpu/drm/i915/display/g4x_dp.c | 2 +-
> >> > drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
> >> > drivers/gpu/drm/i915/display/intel_dp.c | 41 +++++++++++++++----
> >> > drivers/gpu/drm/i915/display/intel_dp.h | 3 +-
> >> > .../drm/i915/display/intel_dp_link_training.c | 4 +-
> >> > 5 files changed, 38 insertions(+), 14 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c b/drivers/gpu/drm/i915/display/g4x_dp.c
> >> > index 5ff1cdf4581a5..c20a97e21419b 100644
> >> > --- a/drivers/gpu/drm/i915/display/g4x_dp.c
> >> > +++ b/drivers/gpu/drm/i915/display/g4x_dp.c
> >> > @@ -1265,7 +1265,7 @@ static void intel_dp_encoder_reset(struct drm_encoder *encoder)
> >> >
> >> > intel_dp->DP = intel_de_read(display, intel_dp->output_reg);
> >> >
> >> > - intel_dp->reset_link_params = true;
> >> > + intel_dp_reset_link_params_defer(intel_dp);
> >> > intel_dp_invalidate_source_oui(intel_dp);
> >> >
> >> > if (display->platform.valleyview || display->platform.cherryview)
> >> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c
> >> > index 86520848892e0..77819aaeccb76 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> >> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> >> > @@ -4664,7 +4664,7 @@ static void intel_ddi_encoder_reset(struct drm_encoder *encoder)
> >> > struct intel_dp *intel_dp = enc_to_intel_dp(to_intel_encoder(encoder));
> >> > struct intel_digital_port *dig_port = enc_to_dig_port(to_intel_encoder(encoder));
> >> >
> >> > - intel_dp->reset_link_params = true;
> >> > + intel_dp_reset_link_params_defer(intel_dp);
> >> > intel_dp_invalidate_source_oui(intel_dp);
> >> >
> >> > intel_pps_encoder_reset(intel_dp);
> >> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> >> > index 1920d2f026665..13163dd085e91 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> > @@ -3710,7 +3710,11 @@ void intel_dp_set_link_params(struct intel_dp *intel_dp,
> >> > intel_dp->lane_count = lane_count;
> >> > }
> >> >
> >> > -void intel_dp_reset_link_params(struct intel_dp *intel_dp)
> >> > +/*
> >> > + * Reset link params now, preserving any deferred connector
> >> > + * detect-time reset request.
> >> > + */
> >> > +void intel_dp_reset_link_params_force(struct intel_dp *intel_dp)
> >> > {
> >> > intel_dp->link.max_lane_count = intel_dp_max_common_lane_count(intel_dp);
> >> > intel_dp->link.max_rate = intel_dp_max_common_rate(intel_dp);
> >> > @@ -3720,6 +3724,28 @@ void intel_dp_reset_link_params(struct intel_dp *intel_dp)
> >> > intel_dp->link.seq_train_failures = 0;
> >> > }
> >> >
> >> > +/*
> >> > + * Reset link params during the next connector detect.
> >> > + * Return %true if a new reset was queued.
> >> > + */
> >> > +bool intel_dp_reset_link_params_defer(struct intel_dp *intel_dp)
> >>
> >> I find the intel_dp_reset_link_params_defer() vs.
> >> intel_dp_reset_link_params_force() naming rather confusing.
> >>
> >> Can't immediately think of a really good name for
> >> intel_dp_reset_link_params_defer() so maybe it's better to not
> >> have a function for it at all (ie. just drop this patch)?
> >
> > The idea was to have an interface to reset the link params directly or
> > in a deferred way, instead of a direct access of the flag.
> >
> > The names are not great yes. I could use what Jouni suggested instead,
> > or if the above argument is not good enough I can also drop this patch.
>
> I suggest intel_dp_reset_link_params() keeps its name, or gets renamed
> to intel_dp_link_params_reset(). It just does the thing, no "force".
>
> Then the other two use something like:
>
> - submit/process
> - queue/process
> - stage/handle
>
> or some combination i.e. something like:
>
> intel_dp_link_params_reset()
> intel_dp_link_params_reset_submit()
> intel_dp_link_params_reset_process()
All of it kinda leaves it a bit unclear how these things
are related, and then one probably has to read through
them to figure out what they're actually doing.
Hence why I think just setting/checking the flag on the
spot might be the clearest approach. You can immediately
find where it's set vs. checked.
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2026-05-22 12:39 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-18 11:24 [PATCH 0/5] drm/i915/dp: Sanitize link capability change handling Imre Deak
2026-05-18 11:24 ` [PATCH 1/5] drm/i915/dp: Add helpers to reset link params Imre Deak
2026-05-21 21:36 ` Ville Syrjälä
2026-05-22 7:36 ` Hogander, Jouni
2026-05-22 7:47 ` Imre Deak
2026-05-22 10:29 ` Jani Nikula
2026-05-22 12:39 ` Ville Syrjälä [this message]
2026-05-22 12:46 ` Jani Nikula
2026-05-22 12:50 ` Ville Syrjälä
2026-05-22 15:32 ` Imre Deak
2026-05-18 11:24 ` [PATCH 2/5] drm/i915/dp: Reset link params after a DPRX capability change Imre Deak
2026-05-18 11:24 ` [PATCH 3/5] drm/i915/dp: Add helper to set common link params Imre Deak
2026-05-22 7:20 ` Hogander, Jouni
2026-05-18 11:24 ` [PATCH 4/5] drm/i915/dp: Cache max common lane count Imre Deak
2026-05-22 7:21 ` Hogander, Jouni
2026-05-18 11:24 ` [PATCH 5/5] drm/i915/dp: Detect changes in common link parameters Imre Deak
2026-05-21 21:43 ` Ville Syrjälä
2026-05-22 7:54 ` Imre Deak
2026-05-18 12:01 ` ✓ CI.KUnit: success for drm/i915/dp: Sanitize link capability change handling Patchwork
2026-05-18 12:41 ` ✓ Xe.CI.BAT: " Patchwork
2026-05-18 16:04 ` ✗ 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=ahBOa-Pepaw8iTsW@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=jouni.hogander@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