Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp6238509rwr; Mon, 24 Apr 2023 16:30:55 -0700 (PDT) X-Google-Smtp-Source: AKy350YMqXflEN1sfn9U6zHrFIV4+aZEE/VtE7yl5waHsS0kj1WHRrT5Pp8ksxRmegfjkcIX5NX1 X-Received: by 2002:a17:903:30c3:b0:1a6:f1f3:e475 with SMTP id s3-20020a17090330c300b001a6f1f3e475mr12679428plc.55.1682379054861; Mon, 24 Apr 2023 16:30:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682379054; cv=none; d=google.com; s=arc-20160816; b=kPta9p3AmqIrfwDTF+vSiMWsCv04xcFNZ0SW5stI+M4jBQAoxPlmL9i4e6SE438VMt Xd0rYYtAoTNMm6fjapRwoK8ljQnlvZjHTEwihV1tVT2JfV9AYyviRZI0MvWdxS1b2ow2 YAwnzd21NcFgVTGeA6aJBvYXFEr97JTRpwj/v78S3kltoZ92VYM5CgGOaf0kvjDcHEik +E6+EvvAlbdrOZfoBibzNgC8CEA7qtFJVbOciweV2KWrmldSObHINxO8uleN9/726/WI pHBd7B9liNsLaVmFG1Ow6tDbRi4TcV8riPVeuaZ+S8YypZ5s8UGjUUi6DSJ0zyIu+q+E mabA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=yNFsgYKLYRBOMGHyMr5serQwECNokrkVZzHPo5ntJqo=; b=g6poH6GPAoC8FdvHJOmEF4eHRGlZwxEahzaOPFxpqe2HMLebdJKc2zKGJmYuisbWfa VinL8jRy54aG/7N1yUYYMRnw5BOYHxorUxr2mlpOc+fpV4onc9ZU8VtIupg1u7v7K2y9 7kd6T72m0zMABEBcIMGzdLwR6NWgF/5iKQSVwm1pVTGMtJ1i0XjbGLwF3CyOgX+dpeIG 3cV8AfOux+bayNdphysN1JqIfj+MmD8UWdB2XYSRZwCc8T7OLmuQw6nhHSOVkQhqGBur hnYYlLZCUVkmIp+8IAZOt1wkI9aYXzoB5BQyXUP0+rImP622xRth4kNqIa1XjjYKZMLz 9R9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=AnoHrOhS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p8-20020a170902e74800b001a51bb4ad7dsi10447927plf.45.2023.04.24.16.30.42; Mon, 24 Apr 2023 16:30:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=AnoHrOhS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231646AbjDXXZS (ORCPT + 99 others); Mon, 24 Apr 2023 19:25:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46112 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230340AbjDXXZQ (ORCPT ); Mon, 24 Apr 2023 19:25:16 -0400 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B02829767; Mon, 24 Apr 2023 16:24:43 -0700 (PDT) Received: from pps.filterd (m0279866.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 33ON3ZDs003078; Mon, 24 Apr 2023 23:23:20 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=qcppdkim1; bh=yNFsgYKLYRBOMGHyMr5serQwECNokrkVZzHPo5ntJqo=; b=AnoHrOhSSX07Is8Byg9YoOBlCn+RYqxR/oxFEG048NLf3LNvVuOUf8/PPCegdgZD0BDI X9uS3dRoDuSuxRCooql1/o6BxKB1J8ZDIWS7KrMd73gURm/wynYM/0tzU2Jrz4JpV7Gr ZcbGY9kBEdU12oDhZU8/ZGPMXxfc1BbUbn8Gk/yzyCGEthfG97mtqrSZF+Tjd2ipiYbv 4ZpZr5FUJ+Xho7QYGjnIWXdQbFkJvQSJJYs/fuffrby0hm1bFAhETKpgR3a8+FrzJPdF o9dLiPSojQHEvnQQF4M8lo0UUdBA5JJtUZWNqmqzNsh3wjQqNs0FoBt8vZJVrIORjSsj zw== Received: from nalasppmta04.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3q628x83p4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Apr 2023 23:23:20 +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 33ONNJIN006896 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Apr 2023 23:23:19 GMT Received: from [10.110.104.134] (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.986.42; Mon, 24 Apr 2023 16:23:18 -0700 Message-ID: Date: Mon, 24 Apr 2023 16:23:17 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Subject: Re: [PATCH v2 3/3] drm/msm/dpu: Pass catalog pointers directly from RM instead of IDs Content-Language: en-US To: Dmitry Baryshkov , Marijn Suijten CC: Rob Clark , Sean Paul , David Airlie , Daniel Vetter , <~postmarketos/upstreaming@lists.sr.ht>, AngeloGioacchino Del Regno , Konrad Dybcio , Martin Botka , Jami Kettunen , Jordan Crouse , , , , References: <20230418-dpu-drop-useless-for-lookup-v2-0-acb08e82ef19@somainline.org> <20230418-dpu-drop-useless-for-lookup-v2-3-acb08e82ef19@somainline.org> <50d22e0c-84b3-0678-eb06-30fb66fd24cf@quicinc.com> From: Abhinav Kumar In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit 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: UTmkUOBSnlKKu5wp8LXKqlSIZkRKIoRB X-Proofpoint-ORIG-GUID: UTmkUOBSnlKKu5wp8LXKqlSIZkRKIoRB X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-04-24_11,2023-04-21_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=894 spamscore=0 clxscore=1015 mlxscore=0 bulkscore=0 malwarescore=0 impostorscore=0 adultscore=0 phishscore=0 lowpriorityscore=0 priorityscore=1501 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2304240212 X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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: X-Mailing-List: linux-kernel@vger.kernel.org On 4/24/2023 3:54 PM, Dmitry Baryshkov wrote: > On Tue, 25 Apr 2023 at 01:03, Marijn Suijten > wrote: >> >> On 2023-04-21 16:25:15, Abhinav Kumar wrote: >>> >>> >>> On 4/21/2023 1:53 PM, Marijn Suijten wrote: >>>> The Resource Manager already iterates over all available blocks from the >>>> catalog, only to pass their ID to a dpu_hw_xxx_init() function which >>>> uses an _xxx_offset() helper to search for and find the exact same >>>> catalog pointer again to initialize the block with, fallible error >>>> handling and all. >>>> >>>> Instead, pass const pointers to the catalog entries directly to these >>>> _init functions and drop the for loops entirely, saving on both >>>> readability complexity and unnecessary cycles at boot. >>>> >>>> Signed-off-by: Marijn Suijten >>>> Reviewed-by: Dmitry Baryshkov >>> >>> Overall, a nice cleanup! >>> >>> One comment below. >>> >>>> --- >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 37 +++++---------------- >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 14 ++++---- >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.c | 32 +++--------------- >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dsc.h | 11 +++---- >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 38 ++++----------------- >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.h | 12 +++---- >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 2 +- >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 40 ++++++----------------- >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 12 +++---- >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 38 ++++----------------- >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.h | 10 +++--- >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c | 33 +++---------------- >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.h | 14 ++++---- >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 33 +++---------------- >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 14 ++++---- >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 39 ++++------------------ >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 12 +++---- >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c | 33 +++---------------- >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.h | 11 +++---- >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 33 ++++--------------- >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h | 11 +++---- >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 17 +++++----- >>>> drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 18 +++++----- >>>> 23 files changed, 139 insertions(+), 375 deletions(-) >>>> >>> >>> >>> >>>> -struct dpu_hw_intf *dpu_hw_intf_init(enum dpu_intf idx, >>>> - void __iomem *addr, >>>> - const struct dpu_mdss_cfg *m) >>>> +struct dpu_hw_intf *dpu_hw_intf_init(const struct dpu_intf_cfg *cfg, >>>> + void __iomem *addr) >>>> { >>>> struct dpu_hw_intf *c; >>>> - const struct dpu_intf_cfg *cfg; >>>> + >>>> + if (cfg->type == INTF_NONE) { >>>> + pr_err("Cannot create interface hw object for INTF_NONE type\n"); >>>> + return ERR_PTR(-EINVAL); >>>> + } >>> >>> The caller of dpu_hw_intf_init which is the RM already has protection >>> for INTF_NONE, see below >>> >>> for (i = 0; i < cat->intf_count; i++) { >>> struct dpu_hw_intf *hw; >>> const struct dpu_intf_cfg *intf = &cat->intf[i]; >>> >>> if (intf->type == INTF_NONE) { >>> DPU_DEBUG("skip intf %d with type none\n", i); >>> continue; >>> } >>> if (intf->id < INTF_0 || intf->id >= INTF_MAX) { >>> DPU_ERROR("skip intf %d with invalid id\n", >>> intf->id); >>> continue; >>> } >>> hw = dpu_hw_intf_init(intf->id, mmio, cat); >>> >>> So this part can be dropped. >> >> I mainly intended to keep original validation where _intf_offset would >> skip INTF_NONE, and error out. RM init is hence expected to filter out >> INTF_NONE instead of running into that `-EINVAL`, which I maintained >> here. >> >> If you think there won't be another caller of dpu_hw_intf_init, and that >> such validation is hence excessive, I can remove it in a followup v3. > > I'd prefer to see the checks at dpu_rm to be dropped. > dpu_hw_intf_init() (and other dpu_hw_foo_init() functions) should be > self-contained. If they can not init HW block (e.g. because the index > is out of the boundaries), they should return an error. > They already do that today because even without this it will call into _intf_offset() and that will bail out for INTF_NONE. I feel this is a duplicated check because the caller with the loop needs to validate the index before passing it to dpu_hw_intf_init() otherwise the loop will get broken at the first return of the error and rest of the blocks will also not be initialized. >> >> - Marijn >> >>>> c = kzalloc(sizeof(*c), GFP_KERNEL); >>>> if (!c) >>>> return ERR_PTR(-ENOMEM); >>>> >>>> - cfg = _intf_offset(idx, m, addr, &c->hw); >>>> - if (IS_ERR_OR_NULL(cfg)) { >>>> - kfree(c); >>>> - pr_err("failed to create dpu_hw_intf %d\n", idx); >>>> - return ERR_PTR(-EINVAL); >>>> - } >>>> + c->hw.blk_addr = addr + cfg->base; >>>> + c->hw.log_mask = DPU_DBG_MASK_INTF; >>>> >>> >>> > > >