From: Jani Nikula <jani.nikula@linux.intel.com>
To: Kory Maincent <kory.maincent@bootlin.com>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>,
David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Tvrtko Ursulin <tursulin@ursulin.net>,
Andrzej Hajda <andrzej.hajda@intel.com>,
Neil Armstrong <neil.armstrong@linaro.org>,
Robert Foss <rfoss@kernel.org>,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
Jonas Karlman <jonas@kwiboo.se>,
Jernej Skrabec <jernej.skrabec@gmail.com>,
Luca Ceresoli <luca.ceresoli@bootlin.com>,
Chun-Kuang Hu <chunkuang.hu@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
Dmitry Baryshkov <lumag@kernel.org>,
Daniel Stone <daniels@collabora.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
Mark Yacoub <markyacoub@google.com>,
Sean Paul <seanpaul@google.com>,
Manasi Navare <navaremanasi@google.com>,
Drew Davenport <ddavenport@google.com>,
Louis Chauvet <louis.chauvet@bootlin.com>,
Luca Ceresoli <luca.ceresoli@bootlin.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
Kory Maincent <kory.maincent@bootlin.com>
Subject: Re: [PATCH RFC v2 2/4] drm/i915/display/dp: Adopt dp_connector helpers to expose link training state
Date: Mon, 22 Jun 2026 10:28:19 +0300 [thread overview]
Message-ID: <97cb159654547b937a882c67bc9986dfd77eb620@intel.com> (raw)
In-Reply-To: <20260619-feat_link_cap-v2-2-a3dec4c02ad9@bootlin.com>
On Fri, 19 Jun 2026, Kory Maincent <kory.maincent@bootlin.com> wrote:
> Switch the i915 DP connector initialization from
> drm_connector_init_with_ddc() to drm_connector_dp_init_with_ddc(),
> providing the source link capabilities (supported lane counts, link rates
> and DSC support).
>
> Add intel_dp_report_link_train() to collect the negotiated link
> parameters (rate, lane count and DSC enable) and report them via
> drm_dp_set_max_link_params() and drm_dp_set_cur_link_params() once
> link training completes successfully.
>
> Reset the link properties via drm_dp_reset_link_params()
> when the connector is reported as disconnected or when the display device
> is disabled, so the exposed state always reflects the current link status.
>
> Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
> ---
>
> Changes in v2:
> - Remove voltage swing and pre emphasis properties.
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 26 ++++++++++++++++++----
> .../gpu/drm/i915/display/intel_dp_link_training.c | 17 ++++++++++++++
> 2 files changed, 39 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
> index f01a6eed38395..46c06c76952e0 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -6414,8 +6414,10 @@ intel_dp_detect(struct drm_connector *_connector,
> drm_WARN_ON(display->drm,
> !drm_modeset_is_locked(&display->drm->mode_config.connection_mutex));
>
> - if (!intel_display_device_enabled(display))
> + if (!intel_display_device_enabled(display)) {
> + drm_dp_sink_reset_link_caps(_connector);
Gut feeling is that the sprinkling of these around is error prone.
> return connector_status_disconnected;
> + }
>
> if (!intel_display_driver_check_access(display))
> return connector->base.status;
> @@ -6465,6 +6467,8 @@ intel_dp_detect(struct drm_connector *_connector,
>
> intel_dp_tunnel_disconnect(intel_dp);
>
> + drm_dp_sink_reset_link_caps(_connector);
> +
> goto out_unset_edid;
> }
>
> @@ -7240,10 +7244,12 @@ intel_dp_init_connector(struct intel_digital_port *dig_port,
> struct intel_connector *connector)
> {
> struct intel_display *display = to_intel_display(dig_port);
> + struct drm_connector_dp_link_caps link_caps;
> struct intel_dp *intel_dp = &dig_port->dp;
> struct intel_encoder *encoder = &dig_port->base;
> struct drm_device *dev = encoder->base.dev;
> enum port port = encoder->port;
> + u32 *rates;
> int type;
>
> if (drm_WARN(dev, dig_port->max_lanes < 1,
> @@ -7291,8 +7297,21 @@ intel_dp_init_connector(struct intel_digital_port *dig_port,
> type == DRM_MODE_CONNECTOR_eDP ? "eDP" : "DP",
> encoder->base.base.id, encoder->base.name);
>
> - drm_connector_init_with_ddc(dev, &connector->base, &intel_dp_connector_funcs,
> - type, &intel_dp->aux.ddc);
> + intel_dp_set_source_rates(intel_dp);
> + link_caps.nlanes = 4;
> + link_caps.nlink_rates = intel_dp->num_source_rates;
> + rates = kmemdup_array(intel_dp->source_rates, intel_dp->num_source_rates,
> + sizeof(*rates), GFP_KERNEL);
> + if (!rates)
> + goto fail;
> +
> + link_caps.link_rates = rates;
> + link_caps.dsc = HAS_DSC(display);
> +
> + drm_connector_dp_init_with_ddc(dev, &connector->base, &intel_dp_connector_funcs,
> + &link_caps, type, &intel_dp->aux.ddc);
> + kfree(rates);
> +
All of the above feels a bit clumsy in the middle of an already too long
function.
> drm_connector_helper_add(&connector->base, &intel_dp_connector_helper_funcs);
>
> if (!HAS_GMCH(display) && DISPLAY_VER(display) < 12)
> @@ -7315,7 +7334,6 @@ intel_dp_init_connector(struct intel_digital_port *dig_port,
> goto fail;
> }
>
> - intel_dp_set_source_rates(intel_dp);
> intel_dp_set_common_rates(intel_dp);
> intel_dp_reset_link_params(intel_dp);
>
> 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 a26094223f780..25e0e957fe36d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
> @@ -1231,6 +1231,18 @@ intel_dp_128b132b_intra_hop(struct intel_dp *intel_dp,
> return sink_status & DP_INTRA_HOP_AUX_REPLY_INDICATION ? 1 : 0;
> }
>
> +static void intel_dp_report_link_train(struct intel_dp *intel_dp)
> +{
> + struct intel_connector *connector = intel_dp->attached_connector;
> +
> + drm_dp_set_max_link_params(&connector->base, intel_dp->link_rate,
> + intel_dp->lane_count);
> +
> + drm_dp_set_cur_link_params(&connector->base, intel_dp->link_rate,
> + intel_dp->lane_count,
> + connector->dp.dsc_decompression_enabled);
> +}
> +
> /**
> * intel_dp_stop_link_train - stop link training
> * @intel_dp: DP struct
> @@ -1259,6 +1271,9 @@ void intel_dp_stop_link_train(struct intel_dp *intel_dp,
> intel_dp_program_link_training_pattern(intel_dp, crtc_state, DP_PHY_DPRX,
> DP_TRAINING_PATTERN_DISABLE);
>
> + if (!intel_dp->is_mst)
> + intel_dp_report_link_train(intel_dp);
> +
> if (intel_dp_is_uhbr(crtc_state)) {
> ret = poll_timeout_us(ret = intel_dp_128b132b_intra_hop(intel_dp, crtc_state),
> ret == 0,
> @@ -1772,6 +1787,8 @@ void intel_dp_start_link_train(struct intel_atomic_state *state,
> */
> int lttpr_count;
>
> + drm_dp_sink_set_link_caps(&intel_dp->attached_connector->base, &intel_dp->aux);
This is not okay.
We've already figured out all the information needed, and this call goes
ahead and reads the same information out again.
Moreover, some sinks are fragile when it comes to reading the info and
starting link training. The CTS might complain about redundant reads as
well.
drm_dp_sink_set_link_caps() as a name implies something about link,
i.e. the thing between the source and the sink. But this only sets sink
capabilities. Which also means it should not happen at link training
time at all. We figure the information out at detect, which means it's
available *before* modeset.
The more I think about the function, the more I question it. Like, if
the source doesn't support UHBR at all, or not on this connector, what's
the point of reading the sink UHBR rates?
> +
> intel_hpd_block(encoder);
>
> lttpr_count = intel_dp_init_lttpr_and_dprx_caps(intel_dp);
--
Jani Nikula, Intel
next prev parent reply other threads:[~2026-06-22 7:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-19 14:08 [PATCH RFC v2 0/4] Add support for DisplayPort link training information report Kory Maincent
2026-06-19 14:08 ` [PATCH RFC v2 1/4] drm: Introduce DisplayPort connector helpers with link training state Kory Maincent
2026-06-22 7:05 ` Jani Nikula
2026-06-19 14:08 ` [PATCH RFC v2 2/4] drm/i915/display/dp: Adopt dp_connector helpers to expose " Kory Maincent
2026-06-22 7:28 ` Jani Nikula [this message]
2026-06-19 14:08 ` [PATCH RFC v2 3/4] drm/bridge: Wire drmm_connector_dp_init() via new DRM_BRIDGE_OP_DP flag Kory Maincent
2026-06-19 14:08 ` [PATCH RFC v2 4/4] drm/mediatek: Use dp_connector helpers to report link training state Kory Maincent
2026-06-19 14:18 ` ✗ Fi.CI.BUILD: failure for Add support for DisplayPort link training information report (rev2) Patchwork
2026-06-19 17:49 ` [PATCH RFC v2 0/4] Add support for DisplayPort link training information report Kory Maincent
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=97cb159654547b937a882c67bc9986dfd77eb620@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=airlied@gmail.com \
--cc=andrzej.hajda@intel.com \
--cc=angelogioacchino.delregno@collabora.com \
--cc=chunkuang.hu@kernel.org \
--cc=daniels@collabora.com \
--cc=ddavenport@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jernej.skrabec@gmail.com \
--cc=jonas@kwiboo.se \
--cc=joonas.lahtinen@linux.intel.com \
--cc=kory.maincent@bootlin.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=louis.chauvet@bootlin.com \
--cc=luca.ceresoli@bootlin.com \
--cc=lumag@kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=markyacoub@google.com \
--cc=matthias.bgg@gmail.com \
--cc=mripard@kernel.org \
--cc=navaremanasi@google.com \
--cc=neil.armstrong@linaro.org \
--cc=p.zabel@pengutronix.de \
--cc=rfoss@kernel.org \
--cc=rodrigo.vivi@intel.com \
--cc=seanpaul@google.com \
--cc=simona@ffwll.ch \
--cc=thomas.petazzoni@bootlin.com \
--cc=tursulin@ursulin.net \
--cc=tzimmermann@suse.de \
/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