Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp7222290rwr; Tue, 25 Apr 2023 09:42:27 -0700 (PDT) X-Google-Smtp-Source: AKy350YtHtcZ7/puKIBqWPoIR2dOOQOPAJezfrYHJk6mG/AFprCu2S1auQqCbDaik2Qt/8XujkRi X-Received: by 2002:a05:6a00:1248:b0:63b:5174:4784 with SMTP id u8-20020a056a00124800b0063b51744784mr22972162pfi.30.1682440947327; Tue, 25 Apr 2023 09:42:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682440947; cv=none; d=google.com; s=arc-20160816; b=aCUjfLxVx6wZyJJFX5+8piWK4WmOVUdlC2omeWjukkt7lm8AmHErD07vnYbkeCESfz BDF+RHPlvLcW7CN2VlcX+reem4kmgY3k/8lrscCUSyZEBihbL9ZSEpe1H+OW+Ghl1FCQ gXk4QnSPXTXnJLD0TAoe2WlmMJOg7marRcRL/aCcZz2yk2/scwZECRoeQrFgrxLb1d7W AAJX2egYSTtZVpJmiHW9QMp4VDkPT3tmxXMvOoJO3LVTfFl5IN4abI5MjJwI9MOPVuVm qtYULpc81oQ2/YpVhO0qzXW+vCd56hASZJAh5zBjgJ+IQHTUVz1wy+6R7zejYAmD+oh7 aKng== 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=pyQ9aw1iDtuqrwB8RzLXGb4IGVhijYrwwWhBYgij5+o=; b=kWAIZQgmOTTkKjkwseMd5n4/cgzdXvEFcD+XQGGPkv/EkmK8cvtSBJu/L0GeeTdyU/ U/1riw4EhGnNL8vfbUEEpFCK4ozzC1Q17B8hquGJhtcMjyCcaAIy4l3kyI1GGjNBcp7M lCRAZT/1YwESRzTrevZmDK9zgnriW1Kn0SMY26ZLIb35MoIXwad4ZPH7TP8GCGVXQzDj BCfHo+Pp4CAU0VvOxkcM89IXYlB0OLrUkSuci+dos4citW5Qm5boUrqADYtA6rAssvMW yKOvNx8MJ7lVansiMR2oovvPyXaBLWaS/hcO3NOlJWqkZqXnKQOkvzn7Un/KKBdB0R6R fUeQ== 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 t26-20020a63445a000000b0051b9ce24708si13249088pgk.103.2023.04.25.09.42.15; Tue, 25 Apr 2023 09:42:27 -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 S234377AbjDYQeQ (ORCPT + 99 others); Tue, 25 Apr 2023 12:34:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35090 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234629AbjDYQeN (ORCPT ); Tue, 25 Apr 2023 12:34:13 -0400 Received: from relay04.th.seeweb.it (relay04.th.seeweb.it [IPv6:2001:4b7a:2000:18::165]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 00105CC08 for ; Tue, 25 Apr 2023 09:34:06 -0700 (PDT) Received: from SoMainline.org (unknown [89.205.225.67]) (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 019541F963; Tue, 25 Apr 2023 18:33:59 +0200 (CEST) Date: Tue, 25 Apr 2023 18:33:51 +0200 From: Marijn Suijten To: Abhinav Kumar Cc: dri-devel@lists.freedesktop.org, Jordan Crouse , AngeloGioacchino Del Regno , David Airlie , Chandan Uddaraju , Archit Taneja , Robert Foss , Rob Clark , Kuogee Hsieh , Rajesh Yadav , linux-arm-msm@vger.kernel.org, Adam Skladowski , Martin Botka , ~postmarketos/upstreaming@lists.sr.ht, Jeykumar Sankaran , Sean Paul , Neil Armstrong , Loic Poulain , Jami Kettunen , Bjorn Andersson , linux-kernel@vger.kernel.org, Konrad Dybcio , Vinod Koul , Daniel Vetter , Dmitry Baryshkov , freedreno@lists.freedesktop.org, Sravanthi Kollukuduru Subject: Re: [Freedreno] [PATCH v2 04/17] drm/msm/dpu: Fix PP_BLK_DIPHER -> DITHER typo Message-ID: References: <20230411-dpu-intf-te-v2-0-ef76c877eb97@somainline.org> <20230411-dpu-intf-te-v2-4-ef76c877eb97@somainline.org> <65bb4d8a-c607-4152-0ae3-bf3134955925@quicinc.com> <5td7ikd76obc5bn5sndnt7fbzjuwmyxtu35ma3lykzmmbyfffk@b24jh6imaocy> <7541b780-482e-ea92-f788-18c8fbf45d77@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7541b780-482e-ea92-f788-18c8fbf45d77@quicinc.com> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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 2023-04-25 09:18:58, Abhinav Kumar wrote: > > > On 4/24/2023 11:54 PM, Marijn Suijten wrote: > > On 2023-04-24 16:09:45, Abhinav Kumar wrote: > > > >>>> dither block should be present on many other chipsets too but looks like > >>>> on sm8550 was enabling it. Not sure how it was validated there. But we > >>>> are enabling dither, even other chipsets have this block. > >>> > >>> Correct, they all seem to have it starting at sdm845. My patch message > >>> seems to lack the word "exclusively" as the PP on sm8550 appears to > >>> exclusively contain a DITHER subblock (unless other blocks are available > >>> that simply aren't supported within this driver yet) and no other > >>> registers. Hence this aptly named macro exist to emit just the feature > >>> bitflag for that and a .len of zero. > >>> > >> > >> I think after the TE blocks were moved to INTF, dither is the only > >> sub-block for all Ping-Pongs not just in sm8550. > > > > So you are asking / leaving context to make all >= 5.0.0 pingpong blocks > > use this macro with only a single DITHER sblk in PP? > > > > As far as I recall SM8550 is the first SoC to use zero registers in PP, > > which is specifically what this macro takes care of too. Then, there > > are only a few SoCs downstream still (erroneously?) referencing TE2 as > > the only other sub-blk, those SoCs still use sdm845_pp_sblk_te. > > > > So, what I didnt follow is why should sm8450 use PP_BLK_TE Vs sm8550 > should use PP_BLK_DIPHER? > > Atleast for those two, both should be using PP_BLK_DIPHER. > > Thats what I was trying to note here. > > This isnt even right as there is no PP_BLK_TE in sm8450. SM8450 doesn't use PP_BLK_TE (TE2) anymore since the second patch in this series. If you think it should use the DITHER (not DIPHER!) macro instead of the regular PP_BLK with a size of 0xd4, we can do that in another patch as that's not strictly related to this series. Note that that's the only difference between these macros. The size becomes 0 but the .features mask is the same (SM8450 uses PINGPONG_SM8150_MASK). These patches are anyway already distracting from my series, but were easier to do in one go as I was touching the PP and INTF catalog blocks regardless. While at it, perhaps we should check if the version and offset for the DITHER block are correct? SM8450 uses SDM845 sblk definitions. - Marijn > >>> Now, whether we should have the features contain subblock flags rather > >>> than just scanning for their id's or presence in the subblocks is a > >>> different discussion / cleanup we should have. > >>> > >> > >> Yes, separate patch and hence I gave R-b on this one. But had to leave > >> this comment to not lose context. > > > > Fwiw this is a different suggestion: we already have these flags in the > > sub-block `.id` field so there seems to be no reason to duplicate info > > in the top-level `.features` field, deduplicating some info and > > simplifying some defines. > > > > - Marijn > > > >>> - Marijn > >>> > >>>>> - PP_BLK_DIPHER("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0, sc7280_pp_sblk, > >>>>> + PP_BLK_DITHER("pingpong_0", PINGPONG_0, 0x69000, MERGE_3D_0, sc7280_pp_sblk, > >>>>> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 8), > >>>>> -1), > >>>>> - PP_BLK_DIPHER("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0, sc7280_pp_sblk, > >>>>> + PP_BLK_DITHER("pingpong_1", PINGPONG_1, 0x6a000, MERGE_3D_0, sc7280_pp_sblk, > >>>>> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 9), > >>>>> -1), > >>>>> - PP_BLK_DIPHER("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1, sc7280_pp_sblk, > >>>>> + PP_BLK_DITHER("pingpong_2", PINGPONG_2, 0x6b000, MERGE_3D_1, sc7280_pp_sblk, > >>>>> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 10), > >>>>> -1), > >>>>> - PP_BLK_DIPHER("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1, sc7280_pp_sblk, > >>>>> + PP_BLK_DITHER("pingpong_3", PINGPONG_3, 0x6c000, MERGE_3D_1, sc7280_pp_sblk, > >>>>> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR, 11), > >>>>> -1), > >>>>> - PP_BLK_DIPHER("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2, sc7280_pp_sblk, > >>>>> + PP_BLK_DITHER("pingpong_4", PINGPONG_4, 0x6d000, MERGE_3D_2, sc7280_pp_sblk, > >>>>> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 30), > >>>>> -1), > >>>>> - PP_BLK_DIPHER("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2, sc7280_pp_sblk, > >>>>> + PP_BLK_DITHER("pingpong_5", PINGPONG_5, 0x6e000, MERGE_3D_2, sc7280_pp_sblk, > >>>>> DPU_IRQ_IDX(MDP_SSPP_TOP0_INTR2, 31), > >>>>> -1), > >>>>> - PP_BLK_DIPHER("pingpong_6", PINGPONG_6, 0x66000, MERGE_3D_3, sc7280_pp_sblk, > >>>>> + PP_BLK_DITHER("pingpong_6", PINGPONG_6, 0x66000, MERGE_3D_3, sc7280_pp_sblk, > >>>>> -1, > >>>>> -1), > >>>>> - PP_BLK_DIPHER("pingpong_7", PINGPONG_7, 0x66400, MERGE_3D_3, sc7280_pp_sblk, > >>>>> + PP_BLK_DITHER("pingpong_7", PINGPONG_7, 0x66400, MERGE_3D_3, sc7280_pp_sblk, > >>>>> -1, > >>>>> -1), > >>>>> }; > >>>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c > >>>>> index 03f162af1a50..ca8a02debda9 100644 > >>>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c > >>>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c > >>>>> @@ -491,7 +491,7 @@ static const struct dpu_pingpong_sub_blks sc7280_pp_sblk = { > >>>>> .len = 0x20, .version = 0x20000}, > >>>>> }; > >>>>> > >>>>> -#define PP_BLK_DIPHER(_name, _id, _base, _merge_3d, _sblk, _done, _rdptr) \ > >>>>> +#define PP_BLK_DITHER(_name, _id, _base, _merge_3d, _sblk, _done, _rdptr) \ > >>>>> {\ > >>>>> .name = _name, .id = _id, \ > >>>>> .base = _base, .len = 0, \ > >>>>>