Re: [PATCH RFC 09/12] drm: Introduce drmm_connector_dp_init() with link training state properties

Kory Maincent
2026-04-14T12:10:15Z

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

> On Thu, Apr 09, 2026 at 07:08:25PM +0200, Kory Maincent wrote:
> > Add a managed DisplayPort connector initialization helper,
> > drmm_connector_dp_init(), modeled after the existing HDMI counterpart
> > drmm_connector_hdmi_init(). Cleanup is handled automatically via a
> > DRM-managed action.
> >
> > The helper creates the following immutable connector properties to expose
> > DP link training capabilities and state to userspace:
> >
> > - num_lanes: bitmask of supported lane counts (1, 2, 4)
> > - link_rate: Array of supported link rates.
> > - dsc_en: Display Stream Compression supported
> > - voltage_swingN: per-lane voltage swing level bitmask
> > - pre-emphasisN: per-lane pre-emphasis level bitmask
> >
> > Link rates are passed by the driver in deca-kbps, following the DRM
> > convention, but exposed to userspace in kbps for clarity.
> >
> > Two additional helpers are provided to update and reset those properties
> > at runtime:
> > - drm_connector_dp_set_link_train_properties()
> > - drm_connector_dp_reset_link_train_properties()
> >

...

> > +/**
> > + * struct drm_connector_dp_link_train - DRM DisplayPort link training
> > + * information report
> > + */
> > +struct drm_connector_dp_link_train {
>
> THese define the current DP state. As such, they definitely make sense
> to be a part of the drm_connector.
> > + /**
> > + * @nlanes: The number of lanes used
> > + */
> > + u8 nlanes;
> > +
> > + /**
> > + * @rates: Link rate value selected in deca-kbps
> > + */
> > + u32 rate;
> > +
> > + /**
> > + * @dsc: Display Stream Compression enabled
> > + */
> > + bool dsc_en;
> > +
> > + /**
> > + * @v_swings: Array listing the bitmask voltage swing level per
> > lanes
> > + */
> > + u8 v_swing[4];
> > +
> > + /**
> > + * @pre_emph: Array listing the bitmask pre-emphasis level per
> > lanes
> > + */
> > + u8 pre_emph[4];
>
> Please consider following struct phy_configure_opts_dp (or using it as
> is). Overall, please refer the talk and (more important) the lightning
> resumee at this XDC. I have some bits and pieces ready in spite of that
> proposal, but I didn't have time to finish it.

I didn't know this phy_configure_opts_dp struct. This indeed could make sense
to reuse and modify that structure for our needs.

About your XDC talk. What were the developments you were talking about? Could I
have a look at them?

Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering