Re: [PATCH RFC 00/12] Add support for DisplayPort link training information report

[Kory Maincent <kory.maincent@bootlin.com>]

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