Hello On Fri, 19 Jun 2026 16:08:42 +0200 Kory Maincent <[email protected]> wrote:
> DisplayPort link training negotiates the physical-layer parameters needed > for a reliable connection: lane count, link rate, 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 generic, managed and unmanaged DisplayPort > connector initialization helpers, for exposing DP link capabilities and > state as standard sysfs entries, modeled after the existing HDMI helper > drmm_connector_hdmi_init(). > > The aim of such development is to guide users to select the most suitable > DisplayPort connector for their needs. For example, if you have a USB-C > hub with lesser capabilities than your computer’s native DisplayPort > connector (such as HBR2 versus HBR3 support), the system could recommend > connecting high-resolution displays directly to the computer’s port > instead of through the hub to ensure optimal performance. > > These new drmm_connector_dp_init() and drm_connector_dp_init_with_ddc() > helpers initialize a DP connector and expose link training capabilities > and state to userspace via sysfs attributes under dp_link. > > Additional helpers are provided to manage link capabilities and parameters > at runtime. > > 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 changes updating the i915 driver to use DRM managed resources have been > removed due to cleanup path issues. The core problem is that some functions > do not consistently propagate errors through their call paths (whether this > is intentional or not) making it difficult to properly handle cleanup of > DRM objects (planes, encoders, connectors). A potential solution would be > to implement something similar to devres_group for each DRM object type, > but this represents a substantial undertaking that falls outside the scope > of this patch series. > > The MST case in i915 driver is not supported yet. I have seen and fixed the reviews from Sashiko. I prefer to wait for human reviews about the core design before sending a v3, so don't hesitate to look at the series. Mainly the first patch which tackle core DRM changes. Regards, -- Köry Maincent, Bootlin Embedded Linux and kernel engineering https://bootlin.com
