DisplayPort link training negotiates the physical-layer parameters needed
for a reliable connection: lane count, link rate, voltage swing,
pre-emphasis, and optionally Display Stream Compression (DSC). Currently,
each driver exposes this state in its own way, often through
driver-specific debugfs entries, with no standard interface for userspace
diagnostic and monitoring tools.

This series introduces a generic, DRM-managed framework for exposing DP
link training state as standard connector properties, modeled after the
existing HDMI helper drmm_connector_hdmi_init().

The new drmm_connector_dp_init() helper initializes a DP connector and
registers the following connector properties to expose the negotiated link
state to userspace:

- num_lanes:      negotiated lane count (1, 2 or 4)
- link_rate:      negotiated link rate
- dsc_en:         whether Display Stream Compression is active
- voltage_swingN: per-lane voltage swing level (lanes 0-3)
- pre_emphasisN:  per-lane pre-emphasis level (lanes 0-3)

Two runtime helpers update and clear these properties when link training
completes or the link goes down:
- drm_connector_dp_set_link_train_properties()
- drm_connector_dp_reset_link_train_properties()

Two drivers are updated as reference implementations: i915 (direct
connector path) and MediaTek (via the bridge connector framework using a
new DRM_BRIDGE_OP_DP flag). The i915 patches are preceded by a series of
conversions to DRM managed resources, which are required before adopting
drmm_connector_dp_init().

The MST case in i915 driver is not supported yet.

Patches 1-3:  Fix two error-path cleanup bugs in i915 sdvo and lvds
[Will probably be sent standalone]
Patches 4-8: Convert i915 display resources to DRM managed lifetime
Patch 9: Introduce the core drmm_connector_dp_init() framework
Patch 10: Wire the i915 DP connector to use the new helpers
Patch 11: Introduce DRM_BRIDGE_OP_DP and wire bridge connectors
Patch 12: Wire the MediaTek DP bridge to the new helpers [untested]

Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
---
Kory Maincent (12):
      drm/i915/display/intel_sdvo: Fix double connector destroy in error paths
      drm/i915/display/intel_lvds: Drop redundant manual cleanup on init failure
      drm/i915/display/intel_dp: Drop redundant intel_dp_aux_fini() on init failure
      drm/i915/display: Switch to drmm_mode_config_init() and drop manual cleanup
      drm/i915/display: Switch to managed for crtc
      drm/i915/display: Switch to managed for plane
      drm/i915/display: Switch to managed for encoder
      drm/i915/display: Switch to managed for connector
      drm: Introduce drmm_connector_dp_init() with link training state properties
      drm/i915/display/dp: Adopt dp_connector helpers to expose link training state
      drm/bridge: Wire drmm_connector_dp_init() via new DRM_BRIDGE_OP_DP flag
      drm/mediatek: Use dp_connector helpers to report link training state

 drivers/gpu/drm/Makefile                           |   1 +
 drivers/gpu/drm/display/drm_bridge_connector.c     |  26 +-
 drivers/gpu/drm/drm_dp_connector.c                 | 344 +++++++++++++++++++++
 drivers/gpu/drm/i915/display/g4x_dp.c              |  39 +--
 drivers/gpu/drm/i915/display/g4x_hdmi.c            |  27 +-
 drivers/gpu/drm/i915/display/i9xx_plane.c          |  97 +++---
 drivers/gpu/drm/i915/display/icl_dsi.c             |  50 ++-
 drivers/gpu/drm/i915/display/intel_connector.c     |  26 +-
 drivers/gpu/drm/i915/display/intel_connector.h     |   5 +-
 drivers/gpu/drm/i915/display/intel_crt.c           |  28 +-
 drivers/gpu/drm/i915/display/intel_crtc.c          | 102 +++---
 drivers/gpu/drm/i915/display/intel_cursor.c        |  41 ++-
 drivers/gpu/drm/i915/display/intel_ddi.c           |  64 ++--
 drivers/gpu/drm/i915/display/intel_display.c       |   8 -
 drivers/gpu/drm/i915/display/intel_display.h       |   1 -
 .../gpu/drm/i915/display/intel_display_driver.c    |  37 ++-
 drivers/gpu/drm/i915/display/intel_dp.c            |  43 ++-
 .../gpu/drm/i915/display/intel_dp_link_training.c  |  25 ++
 drivers/gpu/drm/i915/display/intel_dp_mst.c        |  33 +-
 drivers/gpu/drm/i915/display/intel_dvo.c           |  43 +--
 drivers/gpu/drm/i915/display/intel_encoder.c       |   6 +-
 drivers/gpu/drm/i915/display/intel_encoder.h       |   3 +-
 drivers/gpu/drm/i915/display/intel_hdmi.c          |  15 +-
 drivers/gpu/drm/i915/display/intel_lvds.c          |  45 ++-
 drivers/gpu/drm/i915/display/intel_plane.c         |  45 +--
 drivers/gpu/drm/i915/display/intel_plane.h         |   5 +-
 drivers/gpu/drm/i915/display/intel_sdvo.c          | 134 +++-----
 drivers/gpu/drm/i915/display/intel_sprite.c        | 119 ++++---
 drivers/gpu/drm/i915/display/intel_tv.c            |  26 +-
 drivers/gpu/drm/i915/display/skl_universal_plane.c | 102 +++---
 drivers/gpu/drm/i915/display/vlv_dsi.c             |  42 +--
 drivers/gpu/drm/mediatek/mtk_dp.c                  |  34 +-
 include/drm/drm_bridge.h                           |  13 +
 include/drm/drm_connector.h                        |  38 +++
 include/drm/drm_dp_connector.h                     | 109 +++++++
 35 files changed, 1125 insertions(+), 651 deletions(-)
---
base-commit: db5a75cfd29766536be62aece9f19c6e7a858fa6
change-id: 20260226-feat_link_cap-20cbb6f31d40

Best regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

On Thu, Apr 09, 2026 at 07:08:16PM +0200, Kory Maincent wrote:
> DisplayPort link training negotiates the physical-layer parameters needed
> for a reliable connection: lane count, link rate, voltage swing,
> pre-emphasis, and optionally Display Stream Compression (DSC). Currently,
> each driver exposes this state in its own way, often through
> driver-specific debugfs entries, with no standard interface for userspace
> diagnostic and monitoring tools.
> 
> This series introduces a generic, DRM-managed framework for exposing DP
> link training state as standard connector properties, modeled after the
> existing HDMI helper drmm_connector_hdmi_init().
> 
> The new drmm_connector_dp_init() helper initializes a DP connector and
> registers the following connector properties to expose the negotiated link
> state to userspace:
> 
> - num_lanes:      negotiated lane count (1, 2 or 4)
> - link_rate:      negotiated link rate
> - dsc_en:         whether Display Stream Compression is active
> - voltage_swingN: per-lane voltage swing level (lanes 0-3)
> - pre_emphasisN:  per-lane pre-emphasis level (lanes 0-3)

I don't see why any real userspace would be interested in those (apart
from maybe DSC). If this is just for diagnostics and whatnot then I
think sysfs/debugfs could be a better fit.

> 
> Two runtime helpers update and clear these properties when link training
> completes or the link goes down:
> - drm_connector_dp_set_link_train_properties()
> - drm_connector_dp_reset_link_train_properties()
> 
> Two drivers are updated as reference implementations: i915 (direct
> connector path) and MediaTek (via the bridge connector framework using a
> new DRM_BRIDGE_OP_DP flag). The i915 patches are preceded by a series of
> conversions to DRM managed resources, which are required before adopting
> drmm_connector_dp_init().
> 
> The MST case in i915 driver is not supported yet.
> 
> Patches 1-3:  Fix two error-path cleanup bugs in i915 sdvo and lvds
> [Will probably be sent standalone]
> Patches 4-8: Convert i915 display resources to DRM managed lifetime
> Patch 9: Introduce the core drmm_connector_dp_init() framework
> Patch 10: Wire the i915 DP connector to use the new helpers
> Patch 11: Introduce DRM_BRIDGE_OP_DP and wire bridge connectors
> Patch 12: Wire the MediaTek DP bridge to the new helpers [untested]
> 
> Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
> ---
> Kory Maincent (12):
>       drm/i915/display/intel_sdvo: Fix double connector destroy in error paths
>       drm/i915/display/intel_lvds: Drop redundant manual cleanup on init failure
>       drm/i915/display/intel_dp: Drop redundant intel_dp_aux_fini() on init failure
>       drm/i915/display: Switch to drmm_mode_config_init() and drop manual cleanup
>       drm/i915/display: Switch to managed for crtc
>       drm/i915/display: Switch to managed for plane
>       drm/i915/display: Switch to managed for encoder
>       drm/i915/display: Switch to managed for connector
>       drm: Introduce drmm_connector_dp_init() with link training state properties
>       drm/i915/display/dp: Adopt dp_connector helpers to expose link training state
>       drm/bridge: Wire drmm_connector_dp_init() via new DRM_BRIDGE_OP_DP flag
>       drm/mediatek: Use dp_connector helpers to report link training state
> 
>  drivers/gpu/drm/Makefile                           |   1 +
>  drivers/gpu/drm/display/drm_bridge_connector.c     |  26 +-
>  drivers/gpu/drm/drm_dp_connector.c                 | 344 +++++++++++++++++++++
>  drivers/gpu/drm/i915/display/g4x_dp.c              |  39 +--
>  drivers/gpu/drm/i915/display/g4x_hdmi.c            |  27 +-
>  drivers/gpu/drm/i915/display/i9xx_plane.c          |  97 +++---
>  drivers/gpu/drm/i915/display/icl_dsi.c             |  50 ++-
>  drivers/gpu/drm/i915/display/intel_connector.c     |  26 +-
>  drivers/gpu/drm/i915/display/intel_connector.h     |   5 +-
>  drivers/gpu/drm/i915/display/intel_crt.c           |  28 +-
>  drivers/gpu/drm/i915/display/intel_crtc.c          | 102 +++---
>  drivers/gpu/drm/i915/display/intel_cursor.c        |  41 ++-
>  drivers/gpu/drm/i915/display/intel_ddi.c           |  64 ++--
>  drivers/gpu/drm/i915/display/intel_display.c       |   8 -
>  drivers/gpu/drm/i915/display/intel_display.h       |   1 -
>  .../gpu/drm/i915/display/intel_display_driver.c    |  37 ++-
>  drivers/gpu/drm/i915/display/intel_dp.c            |  43 ++-
>  .../gpu/drm/i915/display/intel_dp_link_training.c  |  25 ++
>  drivers/gpu/drm/i915/display/intel_dp_mst.c        |  33 +-
>  drivers/gpu/drm/i915/display/intel_dvo.c           |  43 +--
>  drivers/gpu/drm/i915/display/intel_encoder.c       |   6 +-
>  drivers/gpu/drm/i915/display/intel_encoder.h       |   3 +-
>  drivers/gpu/drm/i915/display/intel_hdmi.c          |  15 +-
>  drivers/gpu/drm/i915/display/intel_lvds.c          |  45 ++-
>  drivers/gpu/drm/i915/display/intel_plane.c         |  45 +--
>  drivers/gpu/drm/i915/display/intel_plane.h         |   5 +-
>  drivers/gpu/drm/i915/display/intel_sdvo.c          | 134 +++-----
>  drivers/gpu/drm/i915/display/intel_sprite.c        | 119 ++++---
>  drivers/gpu/drm/i915/display/intel_tv.c            |  26 +-
>  drivers/gpu/drm/i915/display/skl_universal_plane.c | 102 +++---
>  drivers/gpu/drm/i915/display/vlv_dsi.c             |  42 +--
>  drivers/gpu/drm/mediatek/mtk_dp.c                  |  34 +-
>  include/drm/drm_bridge.h                           |  13 +
>  include/drm/drm_connector.h                        |  38 +++
>  include/drm/drm_dp_connector.h                     | 109 +++++++
>  35 files changed, 1125 insertions(+), 651 deletions(-)
> ---
> base-commit: db5a75cfd29766536be62aece9f19c6e7a858fa6
> change-id: 20260226-feat_link_cap-20cbb6f31d40
> 
> Best regards,
> -- 
> Köry Maincent, Bootlin
> Embedded Linux and kernel engineering
> https://bootlin.com

-- 
Ville Syrjälä
Intel

On Thu, Apr 09, 2026 at 11:36:21PM +0300, Ville Syrjälä wrote:
> On Thu, Apr 09, 2026 at 07:08:16PM +0200, Kory Maincent wrote:
> > DisplayPort link training negotiates the physical-layer parameters needed
> > for a reliable connection: lane count, link rate, voltage swing,
> > pre-emphasis, and optionally Display Stream Compression (DSC). Currently,
> > each driver exposes this state in its own way, often through
> > driver-specific debugfs entries, with no standard interface for userspace
> > diagnostic and monitoring tools.
> > 
> > This series introduces a generic, DRM-managed framework for exposing DP
> > link training state as standard connector properties, modeled after the
> > existing HDMI helper drmm_connector_hdmi_init().
> > 
> > The new drmm_connector_dp_init() helper initializes a DP connector and
> > registers the following connector properties to expose the negotiated link
> > state to userspace:
> > 
> > - num_lanes:      negotiated lane count (1, 2 or 4)
> > - link_rate:      negotiated link rate
> > - dsc_en:         whether Display Stream Compression is active
> > - voltage_swingN: per-lane voltage swing level (lanes 0-3)
> > - pre_emphasisN:  per-lane pre-emphasis level (lanes 0-3)
> 
> I don't see why any real userspace would be interested in those (apart
> from maybe DSC). If this is just for diagnostics and whatnot then I
> think sysfs/debugfs could be a better fit.

I'd agree here. Please consider implementing it as a debugfs interface,
possibly reusing the Intel's format.

-- 
With best wishes
Dmitry

On Fri, 10 Apr 2026 00:36:09 +0300
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:

> On Thu, Apr 09, 2026 at 11:36:21PM +0300, Ville Syrjälä wrote:
> > On Thu, Apr 09, 2026 at 07:08:16PM +0200, Kory Maincent wrote:  
> > > DisplayPort link training negotiates the physical-layer parameters needed
> > > for a reliable connection: lane count, link rate, voltage swing,
> > > pre-emphasis, and optionally Display Stream Compression (DSC). Currently,
> > > each driver exposes this state in its own way, often through
> > > driver-specific debugfs entries, with no standard interface for userspace
> > > diagnostic and monitoring tools.
> > > 
> > > This series introduces a generic, DRM-managed framework for exposing DP
> > > link training state as standard connector properties, modeled after the
> > > existing HDMI helper drmm_connector_hdmi_init().
> > > 
> > > The new drmm_connector_dp_init() helper initializes a DP connector and
> > > registers the following connector properties to expose the negotiated link
> > > state to userspace:
> > > 
> > > - num_lanes:      negotiated lane count (1, 2 or 4)
> > > - link_rate:      negotiated link rate
> > > - dsc_en:         whether Display Stream Compression is active
> > > - voltage_swingN: per-lane voltage swing level (lanes 0-3)
> > > - pre_emphasisN:  per-lane pre-emphasis level (lanes 0-3)  
> > 
> > I don't see why any real userspace would be interested in those (apart
> > from maybe DSC). If this is just for diagnostics and whatnot then I
> > think sysfs/debugfs could be a better fit.  
> 
> I'd agree here. Please consider implementing it as a debugfs interface,
> possibly reusing the Intel's format.

Sorry, I completely forgot to include a paragraph explaining the rationale
behind using DRM properties.

This DisplayPort link information report was requested by OSes to allow them to
assess the capabilities of each DisplayPort connector on the system, and to
guide users from the most to least capable ones. It will also enable the OS to
warn the user when a cable is too long or experiencing noise (indicated by high
voltage swing and pre-emphasis levels).

Since this is information that OSes will consume on a regular basis, exposing
it directly as DRM properties seems the most appropriate approach. 

Regards,
-- 
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

On Mon, 13 Apr 2026, Kory Maincent <kory.maincent@bootlin.com> wrote:
> On Fri, 10 Apr 2026 00:36:09 +0300
> Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
>
>> On Thu, Apr 09, 2026 at 11:36:21PM +0300, Ville Syrjälä wrote:
>> > On Thu, Apr 09, 2026 at 07:08:16PM +0200, Kory Maincent wrote:  
>> > > DisplayPort link training negotiates the physical-layer parameters needed
>> > > for a reliable connection: lane count, link rate, voltage swing,
>> > > pre-emphasis, and optionally Display Stream Compression (DSC). Currently,
>> > > each driver exposes this state in its own way, often through
>> > > driver-specific debugfs entries, with no standard interface for userspace
>> > > diagnostic and monitoring tools.
>> > > 
>> > > This series introduces a generic, DRM-managed framework for exposing DP
>> > > link training state as standard connector properties, modeled after the
>> > > existing HDMI helper drmm_connector_hdmi_init().
>> > > 
>> > > The new drmm_connector_dp_init() helper initializes a DP connector and
>> > > registers the following connector properties to expose the negotiated link
>> > > state to userspace:
>> > > 
>> > > - num_lanes:      negotiated lane count (1, 2 or 4)
>> > > - link_rate:      negotiated link rate
>> > > - dsc_en:         whether Display Stream Compression is active
>> > > - voltage_swingN: per-lane voltage swing level (lanes 0-3)
>> > > - pre_emphasisN:  per-lane pre-emphasis level (lanes 0-3)  
>> > 
>> > I don't see why any real userspace would be interested in those (apart
>> > from maybe DSC). If this is just for diagnostics and whatnot then I
>> > think sysfs/debugfs could be a better fit.  
>> 
>> I'd agree here. Please consider implementing it as a debugfs interface,
>> possibly reusing the Intel's format.
>
> Sorry, I completely forgot to include a paragraph explaining the rationale
> behind using DRM properties.
>
> This DisplayPort link information report was requested by OSes to allow them to
> assess the capabilities of each DisplayPort connector on the system, and to
> guide users from the most to least capable ones. It will also enable the OS to
> warn the user when a cable is too long or experiencing noise (indicated by high
> voltage swing and pre-emphasis levels).

The selection of the number of lanes or link rate are at the discretion
of the driver, or link policy manager in DP spec terms. It does not
really convey the capabilities of the *connectors* but rather the
current *link*. Ditto for enabling DSC.

I don't think the voltage swing and pre-emphasis are really diagnostic
measures either, but a response to measuring and adapting to the
link. And if the link training failed, the driver may have already
reduced the number of lanes and link rate to compensate. So you could
appear to have the perfect link only because it was so bad at high link
rate that it was reduced already.

The policies may also vary from driver to driver, and possibly depending
on what makes sense for the hardware (e.g. power consumption with or
without DSC).

I think "link information report ... requested by OSs" is vague, and I
don't think the concept has been completely thought through. I can't see
how you could present reliable and actionable information to the user
with what the patch at hand provides. Or how it could work in a generic
manner across drivers.

Overall sounds like an XY problem [1]. We should focus on what you're
trying to achieve first, in userspace, and only then think about what
the appropriate kernel mechanism should be.

I don't think this is it.


BR,
Jani.


[1] https://en.wikipedia.org/wiki/XY_problem


>
> Since this is information that OSes will consume on a regular basis, exposing
> it directly as DRM properties seems the most appropriate approach.





-- 
Jani Nikula, Intel

Thank you Jani and Ville and others for your feedback on this approach.
I think adding the current negotiated link rate , lane count and DSC
status as part of a connector property is a great
way to standardize this instead of every driver adding a debugfs for
this same information.

Please find my comments for why OS would use this information as below:


On Mon, Apr 13, 2026 at 6:30 AM Jani Nikula <jani.nikula@linux.intel.com> wrote:
>
> On Mon, 13 Apr 2026, Kory Maincent <kory.maincent@bootlin.com> wrote:
> > On Fri, 10 Apr 2026 00:36:09 +0300
> > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
> >
> >> On Thu, Apr 09, 2026 at 11:36:21PM +0300, Ville Syrjälä wrote:
> >> > On Thu, Apr 09, 2026 at 07:08:16PM +0200, Kory Maincent wrote:
> >> > > DisplayPort link training negotiates the physical-layer parameters needed
> >> > > for a reliable connection: lane count, link rate, voltage swing,
> >> > > pre-emphasis, and optionally Display Stream Compression (DSC). Currently,
> >> > > each driver exposes this state in its own way, often through
> >> > > driver-specific debugfs entries, with no standard interface for userspace
> >> > > diagnostic and monitoring tools.
> >> > >
> >> > > This series introduces a generic, DRM-managed framework for exposing DP
> >> > > link training state as standard connector properties, modeled after the
> >> > > existing HDMI helper drmm_connector_hdmi_init().
> >> > >
> >> > > The new drmm_connector_dp_init() helper initializes a DP connector and
> >> > > registers the following connector properties to expose the negotiated link
> >> > > state to userspace:
> >> > >
> >> > > - num_lanes:      negotiated lane count (1, 2 or 4)
> >> > > - link_rate:      negotiated link rate
> >> > > - dsc_en:         whether Display Stream Compression is active
> >> > > - voltage_swingN: per-lane voltage swing level (lanes 0-3)
> >> > > - pre_emphasisN:  per-lane pre-emphasis level (lanes 0-3)
> >> >
> >> > I don't see why any real userspace would be interested in those (apart
> >> > from maybe DSC). If this is just for diagnostics and whatnot then I
> >> > think sysfs/debugfs could be a better fit.
> >>
> >> I'd agree here. Please consider implementing it as a debugfs interface,
> >> possibly reusing the Intel's format.
> >
> > Sorry, I completely forgot to include a paragraph explaining the rationale
> > behind using DRM properties.
> >
> > This DisplayPort link information report was requested by OSes to allow them to
> > assess the capabilities of each DisplayPort connector on the system, and to
> > guide users from the most to least capable ones. It will also enable the OS to
> > warn the user when a cable is too long or experiencing noise (indicated by high
> > voltage swing and pre-emphasis levels).
>
> The selection of the number of lanes or link rate are at the discretion
> of the driver, or link policy manager in DP spec terms. It does not
> really convey the capabilities of the *connectors* but rather the
> current *link*. Ditto for enabling DSC.

I agree that it would be up to each driver to have a policy
on choosing link rate/lane count and when to enable DSC and then if it fails
fallback to lower link rate/lane count as per the VESA spec.

Currently this information is only available through a debugfs and not standard
across the drivers. However adding it as part of the connector property would
be useful for the userspace, such as DRM HWC to use this information along
with the link status property to understand the reason for reduced
resolutions/modes
exposed to userspace.  This can be used to provide better diagnostics and useful
information up to the end user.
DSC being enabled or not or what was the final negotiated link rate
and lane count
could be used to take smarter mode configuration handling choices in
the usersapce
For example for MST, if usersapce can know the negotiated link parameters
usersapce can be smarter in choosing resolutions on each of the downstream sinks
based on the total link bandwidth between source and the hub.

At the end it just helps the OSs to provide better control to the user
in certain scenarios.
I agree that Voltage swing and pre emphasis values can be removed and we
can focus on adding property for link rate, lane count and dsc info
like enabled/disabled, compressed bpp etc.

Regards
Manasi



>
> I don't think the voltage swing and pre-emphasis are really diagnostic
> measures either, but a response to measuring and adapting to the
> link. And if the link training failed, the driver may have already
> reduced the number of lanes and link rate to compensate. So you could
> appear to have the perfect link only because it was so bad at high link
> rate that it was reduced already.
>
> The policies may also vary from driver to driver, and possibly depending
> on what makes sense for the hardware (e.g. power consumption with or
> without DSC).
>
> I think "link information report ... requested by OSs" is vague, and I
> don't think the concept has been completely thought through. I can't see
> how you could present reliable and actionable information to the user
> with what the patch at hand provides. Or how it could work in a generic
> manner across drivers.
>
> Overall sounds like an XY problem [1]. We should focus on what you're
> trying to achieve first, in userspace, and only then think about what
> the appropriate kernel mechanism should be.
>
> I don't think this is it.
>
>
> BR,
> Jani.
>
>
> [1] https://en.wikipedia.org/wiki/XY_problem
>
>
> >
> > Since this is information that OSes will consume on a regular basis, exposing
> > it directly as DRM properties seems the most appropriate approach.
>
>
>
>
>
> --
> Jani Nikula, Intel