Re: [PATCH 09/13] drm/msm/dp: Track output bit depth in bridge atomic state

[Dmitry Baryshkov]

On Wed, Sep 30, 2026 at 08:41:53PM +0800, Xilin Wu wrote:
> Expose max bpc on DP and eDP and select a supported component depth from
> the new connector state. Keep the result in a private bridge state so
> TEST_ONLY atomic commits do not modify the running stream. Force a modeset
> when max bpc changes to apply the new depth to the stream.
> 
> Read cached capabilities under the plugged lock and defer the bandwidth
> check if they are not yet valid. Recheck the selected depth against the
> trained link before enabling video, including the reduced pixel rate of
> YUV420. Retain support for 6 bpc SDR panels.
> 
> Retain the generic bridge helper's missing-state guard in the custom
> duplicate callback. Initial state allocation can fail at bridge attach;
> return NULL in that case so atomic state acquisition reports -ENOMEM
> instead of copying from a NULL pointer.
> 
> Assisted-by: LLM
> Signed-off-by: Xilin Wu <sophon@xxxxxxxxx>
> ---
>  drivers/gpu/drm/msm/dp/dp_ctrl.c    | 15 +++++++
>  drivers/gpu/drm/msm/dp/dp_display.c | 39 ++++++++++++++++--
>  drivers/gpu/drm/msm/dp/dp_display.h |  6 +++
>  drivers/gpu/drm/msm/dp/dp_drm.c     | 81 +++++++++++++++++++++++++++++++++----
>  drivers/gpu/drm/msm/dp/dp_drm.h     |  7 ++++
>  drivers/gpu/drm/msm/dp/dp_panel.c   |  5 ---
>  drivers/gpu/drm/msm/dp/dp_utils.c   | 20 +++++++++
>  drivers/gpu/drm/msm/dp/dp_utils.h   |  4 ++
>  8 files changed, 162 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/dp/dp_ctrl.c b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> index 16c9165b5f31..f41924e75854 100644
> --- a/drivers/gpu/drm/msm/dp/dp_ctrl.c
> +++ b/drivers/gpu/drm/msm/dp/dp_ctrl.c
> @@ -23,6 +23,7 @@
>  
>  #include "dp_reg.h"
>  #include "dp_ctrl.h"
> +#include "dp_utils.h"
>  #include "dp_link.h"
>  
>  #define POLLING_SLEEP_US			1000
> @@ -2620,6 +2621,20 @@ int msm_dp_ctrl_on_stream(struct msm_dp_ctrl *msm_dp_ctrl, struct msm_dp_panel *
>  
>  	ctrl = container_of(msm_dp_ctrl, struct msm_dp_ctrl_private, msm_dp_ctrl);
>  
> +	/* Link training may have reduced the available bandwidth. */
> +	if (!panel->video_test) {
> +		u32 clock = panel->msm_dp_mode.drm_mode.clock;
> +
> +		if (panel->msm_dp_mode.out_fmt_is_yuv_420)
> +			clock /= 2;
> +		ret = msm_dp_utils_select_bpp(panel->msm_dp_mode.bpp / 3, 10,
> +					      clock, ctrl->link->link_params.rate,
> +					      ctrl->link->link_params.num_lanes);

This doesn't feel correct. Yes, we can lower num_lanes (or rate), but
then it would mean that the caps that we checked in atomic_check() might
no longer match the actual hardware. How do other DP drivers handle the
case? We have a "golden standard" of i915, amdgpu and nouveau, which we
probably should refer to and follow.

> +		if (ret < 0)
> +			return ret;
> +		panel->msm_dp_mode.bpp = ret;
> +	}
> +
>  	pixel_rate_orig = panel->msm_dp_mode.drm_mode.clock;
>  	pixel_rate = pixel_rate_orig;
>  

-- 
With best wishes
Dmitry