| Message ID | 20240901040658.157425-2-swboyd@chromium.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | platform/chrome: Add DT USB/DP muxing/topology support | expand |
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@intel.com> > Cc: Neil Armstrong <neil.armstrong@linaro.org> > Cc: Robert Foss <rfoss@kernel.org> > Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> > Cc: Jonas Karlman <jonas@kwiboo.se> > Cc: Jernej Skrabec <jernej.skrabec@gmail.com> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> > Cc: Maxime Ripard <mripard@kernel.org> > Cc: Thomas Zimmermann <tzimmermann@suse.de> > Cc: David Airlie <airlied@gmail.com> > Cc: Daniel Vetter <daniel@ffwll.ch> > Cc: <dri-devel@lists.freedesktop.org> > Cc: Pin-yen Lin <treapking@chromium.org> > Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > Signed-off-by: Stephen Boyd <swboyd@chromium.org> > --- > 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.
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c index 519228eb1095..12d574458e7b 100644 --- a/drivers/gpu/drm/drm_atomic_state_helper.c +++ b/drivers/gpu/drm/drm_atomic_state_helper.c @@ -779,6 +779,8 @@ EXPORT_SYMBOL(drm_atomic_helper_bridge_duplicate_state); void drm_atomic_helper_bridge_destroy_state(struct drm_bridge *bridge, struct drm_bridge_state *state) { + kfree(state->input_bus_cfg.lanes); + kfree(state->output_bus_cfg.lanes); kfree(state); } EXPORT_SYMBOL(drm_atomic_helper_bridge_destroy_state); diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c index d44f055dbe3e..bd18c1e91dee 100644 --- a/drivers/gpu/drm/drm_bridge.c +++ b/drivers/gpu/drm/drm_bridge.c @@ -822,6 +822,40 @@ void drm_atomic_bridge_chain_enable(struct drm_bridge *bridge, } EXPORT_SYMBOL(drm_atomic_bridge_chain_enable); +/** + * drm_bridge_next_bridge_lane_cfg - get the lane configuration of the next bridge + * @bridge: bridge control structure + * @state: new atomic state + * @num_lanes: will contain the size of the returned array + * + * This function is typically called from &drm_bridge_funcs.atomic_check(). + * The @bridge driver calls this function to determine what the next bridge in + * the bridge chain requires for the physical to logical lane assignments. + * + * Return: Lane configuration array of size @num_lanes for the next bridge + * after @bridge in the bridge chain, or NULL if the lane configuration is + * unchanged from the default. + */ +const struct drm_lane_cfg * +drm_bridge_next_bridge_lane_cfg(struct drm_bridge *bridge, + struct drm_atomic_state *state, + u8 *num_lanes) +{ + const struct drm_bridge_state *next_bridge_state; + struct drm_bridge *next_bridge = drm_bridge_get_next_bridge(bridge); + + next_bridge_state = drm_atomic_get_new_bridge_state(state, next_bridge); + if (!next_bridge_state) { + *num_lanes = 0; + return NULL; + } + + *num_lanes = next_bridge_state->input_bus_cfg.num_lanes; + + return next_bridge_state->input_bus_cfg.lanes; +} +EXPORT_SYMBOL(drm_bridge_next_bridge_lane_cfg); + static int drm_atomic_bridge_check(struct drm_bridge *bridge, struct drm_crtc_state *crtc_state, struct drm_connector_state *conn_state) diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h index 4d7f4c5f2001..e1a38d0742f1 100644 --- a/include/drm/drm_atomic.h +++ b/include/drm/drm_atomic.h @@ -1122,6 +1122,27 @@ drm_atomic_crtc_effectively_active(const struct drm_crtc_state *state) return state->active || state->self_refresh_active; } +/** + * struct drm_lane_cfg - lane configuration + * + * This structure stores the lane configuration of a physical bus between + * two components in an output pipeline, usually between two bridges, an + * encoder and a bridge, or a bridge and a connector. + * + * The lane configuration is stored in &drm_bus_cfg. + */ +struct drm_lane_cfg { + /** + * @logical: Logical lane number + */ + u8 logical; + + /** + * @inverted: True if lane polarity is inverted, false otherwise + */ + bool inverted; +}; + /** * struct drm_bus_cfg - bus configuration * @@ -1152,6 +1173,16 @@ struct drm_bus_cfg { * @flags: DRM_BUS_* flags used on this bus */ u32 flags; + + /** + * @lanes: Lane mapping for this bus + */ + struct drm_lane_cfg *lanes; + + /** + * @num_lanes: Number of lanes in @lanes + */ + u8 num_lanes; }; /** diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h index 75019d16be64..064d3c8600a9 100644 --- a/include/drm/drm_bridge.h +++ b/include/drm/drm_bridge.h @@ -963,6 +963,10 @@ drm_atomic_helper_bridge_propagate_bus_fmt(struct drm_bridge *bridge, struct drm_connector_state *conn_state, u32 output_fmt, unsigned int *num_input_fmts); +const struct drm_lane_cfg * +drm_bridge_next_bridge_lane_cfg(struct drm_bridge *bridge, + struct drm_atomic_state *state, + u8 *num_lanes); enum drm_connector_status drm_bridge_detect(struct drm_bridge *bridge); int drm_bridge_get_modes(struct drm_bridge *bridge,
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@intel.com> Cc: Neil Armstrong <neil.armstrong@linaro.org> Cc: Robert Foss <rfoss@kernel.org> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: <dri-devel@lists.freedesktop.org> Cc: Pin-yen Lin <treapking@chromium.org> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> --- 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(+)