On Sat, Aug 31, 2024 at 09:06:39PM GMT, Stephen Boyd wrote: > Add support to the DRM atomic logic to support lane remapping between > bridges, encoders and connectors. Typically lane mapping is handled > statically in firmware, e.g. on DT we use the data-lanes property to > assign lanes when connecting display bridges. Lane assignment is dynamic > with USB-C DisplayPort altmodes, e.g. pin conf D assigns 2 lanes of DP > to pins on the USB-C connector while pin conf C assigns 4 lanes of DP to > pins on the USB-C connector. The lane assignment can't be set statically > because the DP altmode repurposes USB-C pins for the DP lanes while also > limiting the number of DP lanes or their pin assignment at runtime. > > Bridge drivers should point their 'struct drm_bus_cfg::lanes' pointer to > an allocated array of 'struct drm_lane_cfg' structures and indicate the > size of this allocated array with 'struct drm_bus_cfg::num_lanes' in > their atomic_check() callback. The previous bridge in the bridge chain > can look at this information by calling > drm_bridge_next_bridge_lane_cfg() in their atomic_check() callback to > figure out what lanes need to be logically assigned to the physical > output lanes to satisfy the next bridge's lane assignment. > > Cc: Andrzej Hajda <andrzej.hajda@xxxxxxxxx> > Cc: Neil Armstrong <neil.armstrong@xxxxxxxxxx> > Cc: Robert Foss <rfoss@xxxxxxxxxx> > Cc: Laurent Pinchart <Laurent.pinchart@xxxxxxxxxxxxxxxx> > Cc: Jonas Karlman <jonas@xxxxxxxxx> > Cc: Jernej Skrabec <jernej.skrabec@xxxxxxxxx> > Cc: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx> > Cc: Maxime Ripard <mripard@xxxxxxxxxx> > Cc: Thomas Zimmermann <tzimmermann@xxxxxxx> > Cc: David Airlie <airlied@xxxxxxxxx> > Cc: Daniel Vetter <daniel@xxxxxxxx> > Cc: <dri-devel@xxxxxxxxxxxxxxxxxxxxx> > Cc: Pin-yen Lin <treapking@xxxxxxxxxxxx> > Cc: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxx> > Signed-off-by: Stephen Boyd <swboyd@xxxxxxxxxxxx> > --- > drivers/gpu/drm/drm_atomic_state_helper.c | 2 ++ > drivers/gpu/drm/drm_bridge.c | 34 +++++++++++++++++++++++ > include/drm/drm_atomic.h | 31 +++++++++++++++++++++ > include/drm/drm_bridge.h | 4 +++ > 4 files changed, 71 insertions(+) I have given this a lot of thought in the last several days, thanks for the interesting problem. Basically, as I said during LPC, I feel that this is an overkill to be handled in the drm_bridge layer. In most other usecases the lane configuration is static and doesn't change. MIPI DSI standard, for example, explicitly disallows that: "The number of Lanes used shall be a static parameter. It shall be fixed at the time of system design or initial configuration and may not change dynamically." (MIPI DSI 1.3, section 6.1). Following the struct drm_connector_hdmi introduction I think we are getting closer and closer to the struct drm_connector_dp, which should record all DP-related data to be used by DisplayPort connectors. An example of a field in this struct-to-be might be `u8 num_lanes`. In the normal DP / uDP cases it will be static, in case of USB-C AltMode it will be dynamic and change depending on pinconf being configured. -- With best wishes Dmitry
