Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp6597976rwr; Tue, 25 Apr 2023 00:27:23 -0700 (PDT) X-Google-Smtp-Source: AKy350bOxiEIythvPVj1OmgJXiykx6M0g2sYoeSRS5vhEmBHCh8k+7isrJKuWVgpWnmFw+VB3v2L X-Received: by 2002:a05:6a00:c83:b0:63f:120a:1dc3 with SMTP id a3-20020a056a000c8300b0063f120a1dc3mr23747624pfv.0.1682407643370; Tue, 25 Apr 2023 00:27:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682407643; cv=none; d=google.com; s=arc-20160816; b=Vc+rhYWYuIWe5WV4hXQlXIcEjeJ2LCC42JtlpmclmS8aqBaaBMBKTLjfmzo+QyJ8Ff c59lT4sbw6ldvy5JhHLohR/XCMu/oq4ZOAMciJr0P63xAfi5NLv1rYbNl/2lMrNd16Zp bdt2OJ083l9jEVF0NH3Dq/El0UDwZTR57RI/mZ+FpRNYwsE5w5FhHwJCDhb6R+fRC5AE TahUR/scjwSSNyqSzJXJy1kifuqs458ktZVs6bsjsfIIAvTQ+sMxt905n+A36iXApvZz 4QQYkpFtnb8T5VM7iXsbXRRfX4sK6OkoI6gIyfh0bzXpcrRWAYUEmAoY+d4VTPeF3/vx FQkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=XghhDVwnV5SlJfbfmTw2a/3TTv2RnIHLAMxHh0Sg0ak=; b=LoYgP3umaz+qM4a9SDMv3YUcPFstPvxJP9nEsY2iZ+wUQ4MQLQnjBXw3ZL1KTqvC8P fPeJm5I+uo4fd/H9kr7LcKBpppL7v5Ekld9eBaXWf4dIxhHfHmDcFwfqi64UK25PKSd7 ub73M0Q6ZjnTKyEyPvVF5q+7p7ZqlCokp4Q/SQQvOBhoNW0/ihrPfwIDDftTfy+Vc1O1 QVryAPMP3IB/yt11mhCGX/FFvQj83ccQ64KvkdmH4IdH+E7DNQ5XeT8/4YKWl+1SMBw9 OfCjeqfasjrbbQMvQ2vLZgKmYtV6YRuqZIrHOFit6mys9L8XPn2CEpQ+kzPsPUyskA+I f2oA== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a15-20020a65640f000000b0051397a23a0bsi12703298pgv.482.2023.04.25.00.27.06; Tue, 25 Apr 2023 00:27:23 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233311AbjDYHQ3 (ORCPT + 99 others); Tue, 25 Apr 2023 03:16:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36696 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230314AbjDYHQ0 (ORCPT ); Tue, 25 Apr 2023 03:16:26 -0400 Received: from relay01.th.seeweb.it (relay01.th.seeweb.it [5.144.164.162]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CFC749EDE for ; Tue, 25 Apr 2023 00:16:24 -0700 (PDT) Received: from SoMainline.org (unknown [89.205.225.90]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by m-r1.th.seeweb.it (Postfix) with ESMTPSA id 297F31F6C4; Tue, 25 Apr 2023 09:16:21 +0200 (CEST) Date: Tue, 25 Apr 2023 09:16:19 +0200 From: Marijn Suijten To: Abhinav Kumar Cc: Dmitry Baryshkov , Rob Clark , Sean Paul , David Airlie , Daniel Vetter , ~postmarketos/upstreaming@lists.sr.ht, AngeloGioacchino Del Regno , Konrad Dybcio , Martin Botka , Jami Kettunen , Jordan Crouse , linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 3/3] drm/msm/dpu: Pass catalog pointers directly from RM instead of IDs Message-ID: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 2023-04-24 16:23:17, Abhinav Kumar wrote: > > > 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. To both: keep in mind that the range-checks we want to remove from dpu_rm_init validate the ID (index?) of a block. This check is for the *TYPE* of an INTF block, to skip it gracefully if no hardware is mapped there. As per the first patch of this series SM6115/QCM2290 only have a DSI interface which always sits at ID 1, and ID 0 has its TYPE set to INTF_NONE and is skipped. Hence we _should_ keep the graceful TYPE check in dpu_rm_init() to skip calling this function _and assigning it to the rm->hw_intf array_. But I can remove the second TYPE check here in dpu_hw_intf_init() if you prefer. - Marijn