[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <24e419da-71f8-4b0d-9416-0fe4c63eed0f@oss.qualcomm.com>
Date: Thu, 15 May 2025 17:39:06 -0700
From: Jessica Zhang <jessica.zhang@....qualcomm.com>
To: Dmitry Baryshkov <dmitry.baryshkov@....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 5/14/2025 5:28 PM, Dmitry Baryshkov wrote:
> 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.
Hi Dmitry,
Ack.
>
>>
>> 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 don't think we're skipping PINGPONG_0 here since `u32
max_pingpong_width = dpu_kms->catalog->pingpong[0].max_linewidth;` at
the top of the function.
>
> 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).
Ack. I think my only concern for this is that max_pp0_linewidth won't be
set for all chipsets. But if you're fine with that I'll go ahead and
make this change.
Thanks,
Jessica Zhang
>
>> +
>> + return max_pingpong_width;
>> +}
>> +
>> static int _dpu_crtc_check_and_setup_lm_bounds(struct drm_crtc *crtc,
>> struct drm_crtc_state *state)
>> {
>
Powered by blists - more mailing lists