Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp5067229rwr; Mon, 8 May 2023 17:47:10 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7MmQD40lIMthHKYWzFknrLX004rl76Zc7JO++socaWXVpb4HrvUZYdrarls8FB0AKPVkrW X-Received: by 2002:a05:6a21:3286:b0:f1:fa94:ee65 with SMTP id yt6-20020a056a21328600b000f1fa94ee65mr15853844pzb.4.1683593230373; Mon, 08 May 2023 17:47:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683593230; cv=none; d=google.com; s=arc-20160816; b=IyBlLBOHPuGir0ObvfMGMM6pzMq/a9YIN7ZvVfENDsR4gDoAaEXpxp5UEqjJjq+c3I km2E2wMGmhkfBTY4URN2x4S/sBw98Gjh9xrQ+8wdZEzB66to6iyHpdFkzTrQZoHr1TZH f1590GqXsQpdMCRCZX2NEHqM+04WdntF02uxa0SPSY3n4ajE+HIvhhC1TpkWtnkAzf+s hUQnc5O2HdR4ri7cNpki7CEG0DoCMuMMpcaEeQ4llGneaGW4HYAVQu7fJaxtoqK9bcns YHO08q6sDDOGXu860rUgKixOdZ2SNFTcJSAwxB9fDvZ7NTgOjpdo/OyDtgM+jxvSH18i FS1Q== 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=haDEAzScw5Q4ifeArnQZ0cit0TqKFjC9SaEKAqwZB8I=; b=Qh1BUJlAuolfm4muSULX5p790k9PdzFFgVCVc7reBAW2VYz128N9CY3wuPP/iTQ6P/ kOCaZFT5x4ce4prHkj0J2ri+x17KThECq81QN0YCgT4uGciWMF2T1uTbGhxxMc+wXUFx CFlH9iK3DFqu7eco138aCc+67HwpXc85y80MY5LUWo1fJY3p9LPq8DVNMMJnOfiVzwkX JlqM9XuPXaZ+w90YdPXC5nOYV52rvU4yGljkkbGcSifrirjBZ9+A2/tY+0vSGQsbEjxm c9WoE/2jFVJ9o1JCyqNpBUs/DqGeRTS/cHPr77lRbfAgCW78ukBbzcCzgBu9c03cJwS/ pPDA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=aV67UFld; 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 d2-20020a633602000000b0050bfa82c23bsi236217pga.230.2023.05.08.17.46.57; Mon, 08 May 2023 17:47:10 -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=aV67UFld; 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 S231459AbjEIA2x (ORCPT + 99 others); Mon, 8 May 2023 20:28:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40990 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229479AbjEIA2v (ORCPT ); Mon, 8 May 2023 20:28:51 -0400 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9C2AD4EEE; Mon, 8 May 2023 17:28:49 -0700 (PDT) Received: from pps.filterd (m0279873.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 348NswtK023495; Tue, 9 May 2023 00:28:42 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=haDEAzScw5Q4ifeArnQZ0cit0TqKFjC9SaEKAqwZB8I=; b=aV67UFldXXJJicIj6NILY0Zz44URayedZO6XsfBtLtbnRnpKFjsVd67o37hHT75PgbSS bnhTRP7qvUOcMWhp3y9cuOQCdgNPvuOxYvlWjmCI3+doKPF0UVNqw3r/fCHYHs35VDjl mzk1qH43YQqsRWcYtGIZO7xSHjr6ttpR/j7XR6L+BBoOcaixMYT/YA83Efh/7zAezYSh aa2zbjQ9p3HhGxcDYtpIMwY6CntmghuDorLovBZOkGBnhk8vRKJmb5Ji/N0USL9N6+uS hPfFAW4z6lomW0s8jxp1DpV1XvcUYUuw7g4SHL2KvxEJs9Z3smAyZAxfZADnCOkimB6F 3Q== Received: from nalasppmta01.qualcomm.com (Global_NAT1.qualcomm.com [129.46.96.20]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3qf781gds0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 09 May 2023 00:28:42 +0000 Received: from nalasex01a.na.qualcomm.com (nalasex01a.na.qualcomm.com [10.47.209.196]) by NALASPPMTA01.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 3490SfCL011433 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 9 May 2023 00:28:41 GMT Received: from [10.134.70.142] (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, 8 May 2023 17:28:40 -0700 Message-ID: <9aad0f0a-f168-5162-68a0-9e9cde21c1f6@quicinc.com> Date: Mon, 8 May 2023 17:28:30 -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/4] drm/msm/dpu: Add DPU_INTF_DATA_COMPRESS feature flag Content-Language: en-US To: Dmitry Baryshkov , Jessica Zhang , Marijn Suijten CC: Rob Clark , Sean Paul , David Airlie , Daniel Vetter , Konrad Dybcio , , , , References: <20230405-add-dsc-support-v2-0-1072c70e9786@quicinc.com> <20230405-add-dsc-support-v2-3-1072c70e9786@quicinc.com> <1d7ccb5f-55c2-3b3a-df97-2c17beffabfc@quicinc.com> <0aa4130d-bb37-4743-10e5-fd518276f4a2@linaro.org> From: Abhinav Kumar In-Reply-To: <0aa4130d-bb37-4743-10e5-fd518276f4a2@linaro.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01a.na.qualcomm.com (10.52.223.231) 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: IY3IKbLjwgT9ZKefPMrIKlptq8-QtoDd X-Proofpoint-ORIG-GUID: IY3IKbLjwgT9ZKefPMrIKlptq8-QtoDd 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-05-08_17,2023-05-05_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 bulkscore=0 suspectscore=0 clxscore=1015 mlxlogscore=999 malwarescore=0 mlxscore=0 impostorscore=0 adultscore=0 phishscore=0 lowpriorityscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2304280000 definitions=main-2305090002 X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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 5/8/2023 4:08 PM, Dmitry Baryshkov wrote: > On 09/05/2023 00:46, Jessica Zhang wrote: >> >> >> On 5/7/2023 9:00 AM, Marijn Suijten wrote: >>> On 2023-05-05 14:23:50, Jessica Zhang wrote: >>>> Add DATA_COMPRESS feature flag to DPU INTF block. >>>> >>>> In DPU 7.x and later, DSC/DCE enablement registers have been moved from >>>> PINGPONG to INTF. >>>> >>>> As core_rev (and related macros) was removed from the dpu_kms >>>> struct, the >>>> most straightforward way to indicate the presence of this register >>>> would be >>>> to have a feature flag. >>> >>> Irrelevant.  Even though core_rev was still in mainline until recently, >>> we always hardcoded the features in the catalog and only used core_rev >>> to select a dpu_mdss_cfg catalog entry.  There is no "if version >= X >>> then enable feature Y" logic, this manually-enabled feature flag is the >>> only, correct way to do it. >> >> Hi Marijn, >> >> Understood. FWIW, if we do find more register bit-level differences >> between HW versions in the future, it might make more sense to keep >> the HW catalog small and bring core_rev back, rather than keep adding >> these kinds of small differences to caps. > > Let's see how it goes. Abhinav suggested that there might be feature > differences inside the DPU generations (and even inside the single DPU > major/minor combo). So I'm not sure what core_rev will bring us. > It allows us to have if MDSS_REV() checks which are convenient for some calculations / bit programming which we dont want to expose in the catalog as they cannot be classified as a hw cap as such or atleast we dont want them to be classified as such. > Let's land the platforms which are ready (or if there is anything close > to be submitted). I'll post the next proposal for the catalog cleanups > close to -rc4, when the dust settles then we can have one or two weaks > for the discussion and polishing. > > I'd like to consider: > - inlining foo_BLK macros, if that makes adding new features easier > - reformat of clk_ctrls > - maybe reintroduction of per-generation feature masks instead of > keeping them named after the random SoC > - maybe a rework of mdss_irqs / INTFn_INTR. We already have this info in > hw catalog. > > Comments are appreciated. > I would say, lets wait for DSC to settle. Atleast the parts already on the list. Continuous rebase of features already on the list is becoming time consuming because of overlapping catalog reworks. > >> >> Thanks, >> >> Jessica Zhang >> >>> >>>> Changes in v2: >>>> - Changed has_data_compress dpu_cap to a DATA_COMPRESS INTF feature >>>> flag >>>> >>>> Signed-off-by: Jessica Zhang >>> >>> Reviewed-by: Marijn Suijten >>> >>>> --- >>>>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +- >>>>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 ++ >>>>   2 files changed, 3 insertions(+), 1 deletion(-) >>>> >>>> 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 7944481d0a33..c74051906d05 100644 >>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c >>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c >>>> @@ -104,7 +104,7 @@ >>>>   #define INTF_SC7180_MASK \ >>>>       (BIT(DPU_INTF_INPUT_CTRL) | BIT(DPU_INTF_TE) | >>>> BIT(DPU_INTF_STATUS_SUPPORTED)) >>>> -#define INTF_SC7280_MASK INTF_SC7180_MASK | BIT(DPU_DATA_HCTL_EN) >>>> +#define INTF_SC7280_MASK INTF_SC7180_MASK | BIT(DPU_DATA_HCTL_EN) | >>>> BIT(DPU_INTF_DATA_COMPRESS) >>> >>> Konrad: Your SM6350/SM6375 series v3 [1] switched from INTF_SC7180_MASK >>> to INTF_SC7280_MASK to enable HCTL on SM6375, but that will now >>> erroneously also receive this feature flag and write the new >>> DATA_COMPESS mask even if it's DPU 6.9 (< 7.x where it got added). >>> >>> [1]: >>> https://lore.kernel.org/linux-arm-msm/80b46fcb-d6d0-1998-c273-5401fa924c7d@linaro.org/T/#u >>> >>> >>> Depending on who lands first, this flag should be split. >>> >>> I still see value in inlining and removing these defines, though that >>> brings a host of other complexity. >>> >>> - Marijn >>> >>>>   #define WB_SM8250_MASK (BIT(DPU_WB_LINE_MODE) | \ >>>>                BIT(DPU_WB_UBWC) | \ >>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h >>>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h >>>> index 4eda2cc847ef..01c65f940f2a 100644 >>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h >>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h >>>> @@ -185,6 +185,7 @@ enum { >>>>    * @DPU_DATA_HCTL_EN                Allows data to be transferred >>>> at different rate >>>>    *                                  than video timing >>>>    * @DPU_INTF_STATUS_SUPPORTED       INTF block has INTF_STATUS >>>> register >>>> + * @DPU_INTF_DATA_COMPRESS          INTF block has DATA_COMPRESS >>>> register >>>>    * @DPU_INTF_MAX >>>>    */ >>>>   enum { >>>> @@ -192,6 +193,7 @@ enum { >>>>       DPU_INTF_TE, >>>>       DPU_DATA_HCTL_EN, >>>>       DPU_INTF_STATUS_SUPPORTED, >>>> +    DPU_INTF_DATA_COMPRESS, >>>>       DPU_INTF_MAX >>>>   }; >>>> >>>> -- >>>> 2.40.1 >>>> >