Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp7053713rwr; Tue, 25 Apr 2023 07:31:27 -0700 (PDT) X-Google-Smtp-Source: AKy350byNF6a0GMRbcOhOZDdr1wVtA5IQynp8+shTX8e1fkOcWFBtRxbHiMv7IeOZYIkjTBUJN2+ X-Received: by 2002:a17:903:1212:b0:1a1:c3eb:afd with SMTP id l18-20020a170903121200b001a1c3eb0afdmr20871362plh.65.1682433086752; Tue, 25 Apr 2023 07:31:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682433086; cv=none; d=google.com; s=arc-20160816; b=LVqhKvh4l6vAPPFw/D+rw5uyR2pzwJs46xce1AaQpPgfZk6VqXPe3d2fhZCadZiwCI zKFv7k5fcpLw2eG0JiIhxJOioyL6+epiTPVApWQoIKnIThqgo8cnN5Z6XoJRZC2UEjAB 4Lq2WyoEpDrAR8bwwLgb8Jld3f2SEVb4fX00TI5EwGJeITXjtTOAV+maWXZCVHskLlg1 ZiUxDvVUfGoFNqk6uQs8cwOIVIKy2FHz5HnJLBGHSKeyT0ZUuy8rxh1PMbxWRsoG3ZeY iIInfbwboGiTC6hJxUtqiYbOF1HstYeq6wC7Wx2QMHEv/x7rdIXgbqHJE22vCaViXxDv cUPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=kbD1oCQK52/WTKujUBAVRhz/h35B5FS7o9GLDaVgvUg=; b=w/QCgBTGOePcQWSMcWSBeZqIrch1rypX7v/3pdkk20WeCDwPKYEe+iTXS2EfuflIna afyx0yOzbNtjVXwsLQiJiRi6e9JcFgaRytZ7z3GI//JdjV4F2bMSToYH8nFcWoLNMnVH 1aHkgXS6YAMOgWES/brWqOt+j1sPi7op4gSENzV5Lp9VD0+9YYoBl7Glg5e21Z5kqFZm m/faSOT3Emlus/FRaB1Xmb2cLzkEh4ijiUFPjEtJqQqnVmYv9vDuMk9QHqG/f1pZ+jFm Ei6X8BkoGSEzb7aDjz1ASXoaSDibYiYqwxhpSXShkRlNaFRUllv1RzDsIxg6TwwrbCsC Ez8A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=LGMfNC+n; 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=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bj8-20020a17090b088800b00246fd478a3bsi13586820pjb.164.2023.04.25.07.31.11; Tue, 25 Apr 2023 07:31:26 -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=@linaro.org header.s=google header.b=LGMfNC+n; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229915AbjDYO1F (ORCPT + 99 others); Tue, 25 Apr 2023 10:27:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41248 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233896AbjDYO1D (ORCPT ); Tue, 25 Apr 2023 10:27:03 -0400 Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8526D13FBB for ; Tue, 25 Apr 2023 07:26:57 -0700 (PDT) Received: by mail-yb1-xb2d.google.com with SMTP id 3f1490d57ef6-b8f549d36e8so10352192276.3 for ; Tue, 25 Apr 2023 07:26:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1682432816; x=1685024816; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=kbD1oCQK52/WTKujUBAVRhz/h35B5FS7o9GLDaVgvUg=; b=LGMfNC+nTBPrgf5Af4/ohQbKn6AHdljSnvffiECsphEFyX2qT8Hs2n0Gx7F3gWZykf qoFYEV1yL3d6olaNXixbV0ToXH+YiGnkItVrvaUAgVuVEOMMA3b59FZ31O/b1spF5HEr kDnVT6TuLrCVaHerZkdIlH2BxP8CF+RxHQIk1zHiKAbASGrAmQg3aFaObODMbiSf+D3p txoJTRej2XbvfmsWEYM9WCjZx/W05d3b/tdEKIiUMYuMLymdXjKs5mfEQupYxeNm+E9u v22VYQphIBWtpGwWL9GmzD17igHcxbfeKxYaPp57XcSozb8Tiy5dWmHA9WCZLnSt64eK qHlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682432816; x=1685024816; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=kbD1oCQK52/WTKujUBAVRhz/h35B5FS7o9GLDaVgvUg=; b=lBaqlZicLbOuGalXEty7c8TVGWy59H61V3eZPoOhmdgVqeUpf21mTrV/ybIFKCtFny OaRiOLpgPFeOc3WEktF1TjWM6y+/DExpWMtdT1X8tDYx6E9cxZZqf3UE3CM+qDvUTt7O j2QXIHos6l6I8BW2/zDXeWrFt3xFgLsaIJzUdZL/C2Q9F/NaQcem/AOp4CBQGM9Kn9E+ 6AF7HQsVzvHbaCqwmeFWmNadSJ8Kj/V6jyWLeKtgmsU+ltXxKVsw9cqG3EXUSu77xpWQ 7Mk1b9cHn2PsaYqhC5zfQFHAeOxuqBsu1ZKm+p3jQgb3yDBcJjN7uRdv0nkF9X53NIU/ Lavg== X-Gm-Message-State: AAQBX9dP8ttMl1Q05ddqNJbG9MrnSOfBWPTfSStXLsD0NXT8OKF/h6UK 0O+Pf6PW9EUzXTSGuKcO01lEsVKyYyzgQ5iz2TytJQ== X-Received: by 2002:a25:aab2:0:b0:b92:32aa:be5c with SMTP id t47-20020a25aab2000000b00b9232aabe5cmr12680159ybi.49.1682432816630; Tue, 25 Apr 2023 07:26:56 -0700 (PDT) MIME-Version: 1.0 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> <31f116f6-a6b7-1241-83bc-96c31e718f3f@linaro.org> In-Reply-To: From: Dmitry Baryshkov Date: Tue, 25 Apr 2023 17:26:45 +0300 Message-ID: Subject: Re: [PATCH v2 3/3] drm/msm/dpu: Pass catalog pointers directly from RM instead of IDs To: Marijn Suijten Cc: Abhinav Kumar , 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 Content-Type: text/plain; charset="UTF-8" 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_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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 Tue, 25 Apr 2023 at 11:55, Marijn Suijten wrote: > > On 2023-04-25 10:54:47, Dmitry Baryshkov wrote: > > On 25/04/2023 10:16, Marijn Suijten wrote: > > > 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. > > > > We can return NULL from dpu_hw_foo_init(), which would mean that the > > block was skipped or is not present. > > An then replace the `if INTF_NONE continue` logic in dpu_rm_init with a > check for NULL that skips, and a check for IS_ERR` that goes to `fail`? You can just drop the INTF_NONE in dpu_rm. If dpu_hw_intf_init() returns NULL, the rest of the code in dpu_rm will work correctly. > > Should I do that in a new or the same patch for v3? > > Note that there's a similar check for the `pingpong` "id" member of > every Layer Mixer. > > - Marijn -- With best wishes Dmitry