lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f2brfgvsnwqu5rudr32fkjx6qiuut2im546mjqrk2ouego4npx@g6avls6o7kws>
Date: Thu, 15 May 2025 03:28:05 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Jessica Zhang <jessica.zhang@....qualcomm.com>
Cc: Rob Clark <robdclark@...il.com>, Sean Paul <sean@...rly.run>,
        Marijn Suijten <marijn.suijten@...ainline.org>,
        David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
        Abhinav Kumar <quic_abhinavk@...cinc.com>,
        Abhinav Kumar <abhinav.kumar@....qualcomm.com>,
        linux-arm-msm@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        freedreno@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/5] drm/msm/dpu: Check mode against PINGPONG or DSC max
 width

On Wed, May 14, 2025 at 04:52:31PM -0700, Jessica Zhang wrote:
> Validate requested mode and topology based on the PINGPONG or DSC encoder
> max width. In addition, drop MAX_HDISPLAY_SPLIT and base LM reservation
> off of PINGPONG or DSC encoder max width

Separate commit for num_lm, please.

> 
> As noted in the patch, while DPU 8.x+ supports a max linewidth of 8960
> for PINGPONG_0, there is some additional logic that needs to be added to
> the resource manager to specifically try and reserve PINGPONG_0 for
> modes that are greater than 5k.
> 
> Since this is out of the scope of this series, add a helper that will
> get the overall minimum PINGPONG max linewidth for a given chipset.
> 
> Signed-off-by: Jessica Zhang <jessica.zhang@....qualcomm.com>
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 46 +++++++++++++++++++++++++++-----
>  1 file changed, 39 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 0714936d8835..6131d071b051 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -723,6 +723,31 @@ void dpu_crtc_complete_commit(struct drm_crtc *crtc)
>  	_dpu_crtc_complete_flip(crtc);
>  }
>  
> +static int msm_display_get_max_pingpong_width(struct dpu_kms *dpu_kms)
> +{
> +	const struct dpu_pingpong_cfg *pingpong;
> +	u32 max_pingpong_width = dpu_kms->catalog->pingpong[0].max_linewidth;
> +
> +	/*
> +	 * Find the smallest overall PINGPONG max_linewidth in the catalog since
> +	 * max_linewidth can differ between PINGPONGs even within the same
> +	 * chipset.
> +	 *
> +	 * Note: While, for DPU 8.x+, PINGPONG_0 can technically support up to
> +	 * 8k resolutions, this requires reworking the RM to try to reserve
> +	 * PINGPONG_0 for modes greater than 5k.
> +	 *
> +	 * Once this additional logic is implemented, we can drop this helper
> +	 * and use the reserved PINGPONG's max_linewidth
> +	 */
> +	for (int i = 1; i < dpu_kms->catalog->pingpong_count; i++) {
> +		pingpong = &dpu_kms->catalog->pingpong[i];
> +		max_pingpong_width = min(max_pingpong_width, pingpong->max_linewidth);
> +	}

Since we are skipping PINGPONG_0, wouldn't it be enough to return
max_linewidth of PP_1 ?

I think, it would be easier to follow .max_dsc_encoder_width and store
.max_pingpong_linewidth in dpu_caps (and later add special
.max_pp0_linewidth).

> +
> +	return max_pingpong_width;
> +}
> +
>  static int _dpu_crtc_check_and_setup_lm_bounds(struct drm_crtc *crtc,
>  		struct drm_crtc_state *state)
>  {

-- 
With best wishes
Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ