Message ID | 20230911221627.9569-1-quic_abhinavk@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9ecd:0:b0:3f2:4152:657d with SMTP id t13csp561297vqx; Tue, 12 Sep 2023 10:20:08 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFuvLMrPIfyrqqEmafqh9mvAf/3T+3fq+cYkuPpaPlEnLUMrTaef0FHkZmZyLF0vkgcCUjh X-Received: by 2002:a05:6a00:22d4:b0:68f:eb8f:785c with SMTP id f20-20020a056a0022d400b0068feb8f785cmr442337pfj.10.1694539208298; Tue, 12 Sep 2023 10:20:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694539208; cv=none; d=google.com; s=arc-20160816; b=VJT9JBWgk04QgJufR3a0aF7lkWDOyoo4hbosR/PuPfgkL8q2VWI483XPyTUp2Z5RZu ZWz1L4FU7i6oM1avwKW3wZiVEDyMRXqta2mAyOS+JqLBhaEFr10nNYNORn3VS0tDXwrc ri8/Gz4WRWfnOvhhSmdDuCSIgwNWB6fEr1QbVS4ykKKPHkvfMUni+FBXxlrtEqUnTX4e gjqULBzhdTdBt5xRVEF8Oo96tHsdYFaCBJS6wqtMtPt+KO7Coe6cgbMBbVQ2D3EVBooZ am6Eyp0v6om607t9FaEOXXlhFX7mhgitOW/lzPOgkwKmiZDdTvH65YtZLSmwVfa/eQ+I ovmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=iTbSB/pI39QxEotFpFEZLZAK7TLYbBFkO7NqA2AIVj0=; fh=o2+LIM4JVVg2bJSFRYw64qKYCs24sf+jiNqVdUrKzIo=; b=XOE2KjI6yLHvQKTxc0wulVdcjAiKkvNdrL8NGrBsOhsK1ZcL4PsYMstfmf1UhF016W z3D2gLrgHnXP9lQiQz0je4OHZxCTkZrvZsoX5yRFEDDMh87M43PO8cxxq6VNVb8KRmBI ZPWIok6xpHOkRWbA0w22oeBhOsOP3GX/dB7ffhohUPI6LehFxrKCEL1CidT6bCWUkhhs nuIDxqzr230ruwQ6TcsWP6wY9EHPAEEusBzOowpjEMThG8OTExSwKYUL1OrLoZaFuquC RU/FXWMRNeRulJB/IJPGIDIJw6gv3lDqHfb8GX9J1AuGYr4pv0+cHkWDagheMzIG7+0S Cbaw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=mDPqGyUE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from snail.vger.email (snail.vger.email. [23.128.96.37]) by mx.google.com with ESMTPS id f9-20020a056a0022c900b0068ff9edf98asi380155pfj.322.2023.09.12.10.20.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Sep 2023 10:20:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=mDPqGyUE; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 7BA0581D8083; Mon, 11 Sep 2023 21:35:32 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.8 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240852AbjILCyA (ORCPT <rfc822;ruipengqi7@gmail.com> + 40 others); Mon, 11 Sep 2023 22:54:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45930 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240644AbjILCxv (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 11 Sep 2023 22:53:51 -0400 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F1E20104418; Mon, 11 Sep 2023 16:26:07 -0700 (PDT) Received: from pps.filterd (m0279867.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 38BLA1gE019094; Mon, 11 Sep 2023 22:16:47 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=from : to : cc : subject : date : message-id : mime-version : content-transfer-encoding : content-type; s=qcppdkim1; bh=iTbSB/pI39QxEotFpFEZLZAK7TLYbBFkO7NqA2AIVj0=; b=mDPqGyUEDdbM9wGIOZTp9k8aCkyR0/pUFGqvnlRcsrJu5VHae8G9Ddd4CJ+kqZwCGMmx BDTNwd8/nsVaLfhfgzO8zG4SRqIUtqJo1fzUXxdloeP+0xizhWV9D8Y0CmcnPl/b3/Ha tkIvp7ttbQdUhrXIF3XUVztS0G7c6bj2eUanZOYK6d247EsYIHJDXAAwbzU4KxR+4geD AP6x6H5g/h96Wls9PFGot+oeFEwNAz74MKi9Zccwtzv3271MBHGbPcaBItP6whnwC5QT PT2Tf7RpPCT3y+rm4cp1SwjLayH1NeFyd4Km3cpm84cTbk+hPAvAlFgEFNOLsqt8Ndf5 VA== Received: from nalasppmta04.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3t24ra94a2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Sep 2023 22:16:47 +0000 Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA04.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 38BMGkLn004032 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Sep 2023 22:16:46 GMT Received: from abhinavk-linux.qualcomm.com (10.80.80.8) by nalasex01a.na.qualcomm.com (10.47.209.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.36; Mon, 11 Sep 2023 15:16:45 -0700 From: Abhinav Kumar <quic_abhinavk@quicinc.com> To: <freedreno@lists.freedesktop.org>, Rob Clark <robdclark@gmail.com>, Abhinav Kumar <quic_abhinavk@quicinc.com>, Dmitry Baryshkov <dmitry.baryshkov@linaro.org>, Sean Paul <sean@poorly.run>, Marijn Suijten <marijn.suijten@somainline.org>, David Airlie <airlied@gmail.com>, "Daniel Vetter" <daniel@ffwll.ch>, Archit Taneja <architt@codeaurora.org>, "Chandan Uddaraju" <chandanu@codeaurora.org>, Jeykumar Sankaran <jsanka@codeaurora.org>, Rajesh Yadav <ryadav@codeaurora.org> CC: <dri-devel@lists.freedesktop.org>, <quic_jesszhan@quicinc.com>, <quic_parellan@quicinc.com>, <nespera@igalia.com>, <linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org> Subject: [PATCH v2 1/2] drm/msm/dpu: fail dpu_plane_atomic_check() based on mdp clk limits Date: Mon, 11 Sep 2023 15:16:26 -0700 Message-ID: <20230911221627.9569-1-quic_abhinavk@quicinc.com> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nalasex01a.na.qualcomm.com (10.47.209.196) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-GUID: OGcO9xz4tUb7yoZ7qgK3ZimWH2WS4569 X-Proofpoint-ORIG-GUID: OGcO9xz4tUb7yoZ7qgK3ZimWH2WS4569 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.957,Hydra:6.0.601,FMLib:17.11.176.26 definitions=2023-09-11_18,2023-09-05_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 spamscore=0 clxscore=1015 mlxscore=0 bulkscore=0 suspectscore=0 phishscore=0 impostorscore=0 mlxlogscore=811 priorityscore=1501 adultscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2308100000 definitions=main-2309110205 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Mon, 11 Sep 2023 21:35:32 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1776853144893326146 X-GMAIL-MSGID: 1776853144893326146 |
Series |
[v2,1/2] drm/msm/dpu: fail dpu_plane_atomic_check() based on mdp clk limits
|
|
Commit Message
Abhinav Kumar
Sept. 11, 2023, 10:16 p.m. UTC
Currently, dpu_plane_atomic_check() does not check whether the
plane can process the image without exceeding the per chipset
limits for MDP clock. This leads to underflow issues because the
SSPP is not able to complete the processing for the data rate of
the display.
Fail the dpu_plane_atomic_check() if the SSPP cannot process the
image without exceeding the MDP clock limits.
changes in v2:
- use crtc_state's adjusted_mode instead of mode
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
---
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
Comments
On Tue, 12 Sept 2023 at 01:16, Abhinav Kumar <quic_abhinavk@quicinc.com> wrote: > > It's certainly possible that for large resolutions a single DPU SSPP > cannot process the image without exceeding the MDP clock limits but > it can still process it in multirect mode because the source rectangles > will get divided and can fall within the MDP clock limits. > > If the SSPP cannot process the image even in multirect mode, then it > will be rejected in dpu_plane_atomic_check_pipe(). > > Hence try using multirect for resolutions which cannot be processed > by a single SSPP without exceeding the MDP clock limits. > > changes in v2: > - use crtc_state's adjusted_mode instead of mode > - fix the UBWC condition to check maxlinewidth > > Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
On Tue, 12 Sept 2023 at 01:18, Abhinav Kumar <quic_abhinavk@quicinc.com> wrote: > > Currently, dpu_plane_atomic_check() does not check whether the > plane can process the image without exceeding the per chipset > limits for MDP clock. This leads to underflow issues because the > SSPP is not able to complete the processing for the data rate of > the display. > > Fail the dpu_plane_atomic_check() if the SSPP cannot process the > image without exceeding the MDP clock limits. > > changes in v2: > - use crtc_state's adjusted_mode instead of mode > > Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") > Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 15 ++++++++++++--- > 1 file changed, 12 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c > index 98c1b22e9bca..0be195f9149c 100644 > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c > @@ -733,9 +733,11 @@ static int dpu_plane_check_inline_rotation(struct dpu_plane *pdpu, > static int dpu_plane_atomic_check_pipe(struct dpu_plane *pdpu, > struct dpu_sw_pipe *pipe, > struct dpu_sw_pipe_cfg *pipe_cfg, > - const struct dpu_format *fmt) > + const struct dpu_format *fmt, > + const struct drm_display_mode *mode) > { > uint32_t min_src_size; > + struct dpu_kms *kms = _dpu_plane_get_kms(&pdpu->base); > > min_src_size = DPU_FORMAT_IS_YUV(fmt) ? 2 : 1; > > @@ -774,6 +776,12 @@ static int dpu_plane_atomic_check_pipe(struct dpu_plane *pdpu, > return -EINVAL; > } > > + /* max clk check */ > + if (_dpu_plane_calc_clk(mode, pipe_cfg) > kms->perf.max_core_clk_rate) { > + DPU_DEBUG_PLANE(pdpu, "plane exceeds max mdp core clk limits\n"); > + return -E2BIG; > + } > + > return 0; > } > > @@ -899,12 +907,13 @@ static int dpu_plane_atomic_check(struct drm_plane *plane, > r_pipe_cfg->dst_rect.x1 = pipe_cfg->dst_rect.x2; > } > > - ret = dpu_plane_atomic_check_pipe(pdpu, pipe, pipe_cfg, fmt); > + ret = dpu_plane_atomic_check_pipe(pdpu, pipe, pipe_cfg, fmt, &crtc_state->adjusted_mode); > if (ret) > return ret; > > if (r_pipe->sspp) { > - ret = dpu_plane_atomic_check_pipe(pdpu, r_pipe, r_pipe_cfg, fmt); > + ret = dpu_plane_atomic_check_pipe(pdpu, r_pipe, r_pipe_cfg, fmt, > + &crtc_state->adjusted_mode); > if (ret) > return ret; > } > -- > 2.40.1 >
On Mon, 11 Sep 2023 15:16:26 -0700, Abhinav Kumar wrote: > Currently, dpu_plane_atomic_check() does not check whether the > plane can process the image without exceeding the per chipset > limits for MDP clock. This leads to underflow issues because the > SSPP is not able to complete the processing for the data rate of > the display. > > Fail the dpu_plane_atomic_check() if the SSPP cannot process the > image without exceeding the MDP clock limits. > > [...] Applied, thanks! [2/2] drm/msm/dpu: try multirect based on mdp clock limits https://gitlab.freedesktop.org/lumag/msm/-/commit/e6c0de5f4450 Best regards,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c index 98c1b22e9bca..0be195f9149c 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c @@ -733,9 +733,11 @@ static int dpu_plane_check_inline_rotation(struct dpu_plane *pdpu, static int dpu_plane_atomic_check_pipe(struct dpu_plane *pdpu, struct dpu_sw_pipe *pipe, struct dpu_sw_pipe_cfg *pipe_cfg, - const struct dpu_format *fmt) + const struct dpu_format *fmt, + const struct drm_display_mode *mode) { uint32_t min_src_size; + struct dpu_kms *kms = _dpu_plane_get_kms(&pdpu->base); min_src_size = DPU_FORMAT_IS_YUV(fmt) ? 2 : 1; @@ -774,6 +776,12 @@ static int dpu_plane_atomic_check_pipe(struct dpu_plane *pdpu, return -EINVAL; } + /* max clk check */ + if (_dpu_plane_calc_clk(mode, pipe_cfg) > kms->perf.max_core_clk_rate) { + DPU_DEBUG_PLANE(pdpu, "plane exceeds max mdp core clk limits\n"); + return -E2BIG; + } + return 0; } @@ -899,12 +907,13 @@ static int dpu_plane_atomic_check(struct drm_plane *plane, r_pipe_cfg->dst_rect.x1 = pipe_cfg->dst_rect.x2; } - ret = dpu_plane_atomic_check_pipe(pdpu, pipe, pipe_cfg, fmt); + ret = dpu_plane_atomic_check_pipe(pdpu, pipe, pipe_cfg, fmt, &crtc_state->adjusted_mode); if (ret) return ret; if (r_pipe->sspp) { - ret = dpu_plane_atomic_check_pipe(pdpu, r_pipe, r_pipe_cfg, fmt); + ret = dpu_plane_atomic_check_pipe(pdpu, r_pipe, r_pipe_cfg, fmt, + &crtc_state->adjusted_mode); if (ret) return ret; }