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

[Kory Maincent]

On Mon, 13 Apr 2026 16:59:43 +0300
Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxxxxxxxx> wrote:

> On Mon, Apr 13, 2026 at 02:59:30PM +0200, Kory Maincent wrote:
> > On Fri, 10 Apr 2026 00:53:08 +0300
> > Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxxxxxxxx> 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.  
> 
> Why would you want to modify it? It is an interface for the PHY drivers.
> Is there anything that you miss there?

I was thinking of the DSC, but after a quick look it is not done at the PHY
level therefore it won't land here.
 
> > About your XDC talk. What were the developments you were talking about?
> > Could I have a look at them?  
> 
> I've posted an RFC just before the XDC. Currently I'm looking at the
> link training generification. Overall, you don't have to wait for that
> job to be completed, just take some of the notes in account (like reuse
> of the PHY config structures).

Ok, have you a link? I can't find the related series.

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