Received: by 2002:a05:6a10:7420:0:0:0:0 with SMTP id hk32csp1701677pxb; Fri, 18 Feb 2022 13:32:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJz4un213NOWwrtdU8qvXSE4rI7KE43n2aUqF4PX8AnDlXfdgpLatU+/UyPjZX42QQtLw/LK X-Received: by 2002:a65:4101:0:b0:372:1875:c19c with SMTP id w1-20020a654101000000b003721875c19cmr7683805pgp.435.1645219931359; Fri, 18 Feb 2022 13:32:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645219931; cv=none; d=google.com; s=arc-20160816; b=sKi7riBIbC3jW3gvtnaBCo3ELR+VsfM5wOMIyjq8GdxgN6Xj/M02qdB92bqLPQADbV VNWKqTa1MBEz5i9bqhNL7w8I1nDb81bSJzbNjSvjm2T7CtUNTbu7vPcRdgo8nfIB2F6M Gci1B5qV121NHjZCd3EDoWG9jvMYBUriEnibjq2Zn6WtYHOpl4L1Nv9fJr0+6t5WpPoU qwVA/Chw/hucO/nlly/+cd8ELdjtr0gNUe+1kPhYnLEy4jxOuqJFbamUvh1dbZvoJhSb onImwyVnSe/jaVP+s5ksRgsZ1hP91NlYrKRE2kLUOekm/xU6lG345uYB1T4pRyaFZ42v QMfQ== 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=XugFhl1wiMuFiF3bnszfWL3zaFWaY1W+76hbSOxZQ2I=; b=0sv77JzO8BiLVME7sJWV/tuKs3fr22PeFTer6PdnIE+Rghnr3pw3ub/eUCG5CYjm+g JyiQlFiC04/8OixxEXGYUUk0sLcJm86tZ9ZcETXFDOFUsJpKNc/mWYTR99qbrsKHsUtp A28Ns/KwoJHYXPiWMS2b2OruinOB86OQdy3AjjGPJvy8TjZkUlgv8MxZVP+TD5gbrXGu WX8m05ideh1bS4yK/WJcDuHs2jg/POM8KNn7N/puMXCJuv1KPd+AkP49c6v5QgAwpU/r HSbYco7ug176E+r4s7zcYxqT9pDK8j32zlR9Un8B9ZQQGyvOEOdoE96onrAKoGoRgPpq H6Vg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcdkim header.b=b5nJJ6A5; 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 e17si17786585plh.542.2022.02.18.13.31.54; Fri, 18 Feb 2022 13:32:11 -0800 (PST) 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=qcdkim header.b=b5nJJ6A5; 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 S239525AbiBRUqf (ORCPT + 99 others); Fri, 18 Feb 2022 15:46:35 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:59400 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233019AbiBRUqd (ORCPT ); Fri, 18 Feb 2022 15:46:33 -0500 Received: from alexa-out-sd-02.qualcomm.com (alexa-out-sd-02.qualcomm.com [199.106.114.39]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 50DC9483B4; Fri, 18 Feb 2022 12:46:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; i=@quicinc.com; q=dns/txt; s=qcdkim; t=1645217176; x=1676753176; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=XugFhl1wiMuFiF3bnszfWL3zaFWaY1W+76hbSOxZQ2I=; b=b5nJJ6A5OA/ANFkFvk0YSnoIGQRDSrTRmwynJaHKagooByr7sIkvNaJF Fm1v0VaQ8MI3Uni+Nv3pfrH/xDE+k5h3R9pX3/dA1S5S/5meS+UZm9y3z ccIhPc3JXJ0vbUnHH6kAFqtNAzufpR7TrxQt7i9CcTHeTnh4LTHaz4Rv/ I=; Received: from unknown (HELO ironmsg01-sd.qualcomm.com) ([10.53.140.141]) by alexa-out-sd-02.qualcomm.com with ESMTP; 18 Feb 2022 12:46:15 -0800 X-QCInternal: smtphost Received: from nasanex01c.na.qualcomm.com ([10.47.97.222]) by ironmsg01-sd.qualcomm.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Feb 2022 12:46:14 -0800 Received: from nalasex01a.na.qualcomm.com (10.47.209.196) by nasanex01c.na.qualcomm.com (10.47.97.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.15; Fri, 18 Feb 2022 12:46:14 -0800 Received: from [10.111.174.92] (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.15; Fri, 18 Feb 2022 12:46:08 -0800 Message-ID: Date: Fri, 18 Feb 2022 12:46:06 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [REPOST PATCH v4 08/13] drm/msm/disp/dpu1: Don't use DSC with mode_3d Content-Language: en-US To: Dmitry Baryshkov , Vinod Koul CC: Rob Clark , , "Bjorn Andersson" , David Airlie , Daniel Vetter , Jonathan Marek , "Abhinav Kumar" , , , References: <20220210103423.271016-1-vkoul@kernel.org> <20220210103423.271016-9-vkoul@kernel.org> <67006cc4-3385-fe03-bb4d-58623729a8a8@quicinc.com> <4b89f5fe-0752-3c6a-3fb0-192f1f2e7b9e@quicinc.com> From: Abhinav Kumar In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit 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-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_MED, 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 2/16/2022 11:12 PM, Dmitry Baryshkov wrote: > On 17/02/2022 09:33, Abhinav Kumar wrote: >> >> >> On 2/16/2022 10:10 PM, Vinod Koul wrote: >>> On 16-02-22, 19:11, Abhinav Kumar wrote: >>>> >>>> >>>> On 2/10/2022 2:34 AM, Vinod Koul wrote: >>>>> We cannot enable mode_3d when we are using the DSC. So pass >>>>> configuration to detect DSC is enabled and not enable mode_3d >>>>> when we are using DSC >>>>> >>>>> We add a helper dpu_encoder_helper_get_dsc() to detect dsc >>>>> enabled and pass this to .setup_intf_cfg() >>>>> >>>>> Signed-off-by: Vinod Koul >>>> >>>> We should not use 3D mux only when we use DSC merge topology. >>>> I agree that today we use only 2-2-1 topology for DSC which means >>>> its using >>>> DSC merge. >>>> >>>> But generalizing that 3D mux should not be used for DSC is not right. >>>> >>>> You can detect DSC merge by checking if there are two encoders and one >>>> interface in the topology and if so, you can disable 3D mux. >>> >>> Right now with DSC we disable that as suggested by Dmitry last time. >>> Whenever we introduce merge we should revisit this, for now this should >>> suffice >>> >> >> Sorry I didnt follow. >> >> The topology which you are supporting today IS DSC merge 2-2-1. I >> didnt get what you mean by "whenever we introduce". >> >> I didnt follow Dmitry's comment either. >> >> "anybody adding support for SDE_RM_TOPOLOGY_DUALPIPE_3DMERGE_DSC >> handle this." >> >> 3D mux shouldnt be used when DSC merge is used. >> >> The topology Dmitry is referring to will not use DSC merge but you are >> using it here and thats why you had to make this patch in the first >> place. So I am not sure why would someone who uses 3D merge topology >> worry about DSC merge. Your patch is the one which deals with the >> topology in question. >> >> What I am suggesting is a small but necessary improvement to this patch. > > It seems that we can replace this patch by changing > dpu_encoder_helper_get_3d_blend_mode() to contain the following > condition (instead of the one present there). Does the following seem > correct to you: > > static inline enum dpu_3d_blend_mode dpu_encoder_helper_get_3d_blend_mode( >                 struct dpu_encoder_phys *phys_enc) > { >         struct dpu_crtc_state *dpu_cstate; > >         if (!phys_enc || phys_enc->enable_state == DPU_ENC_DISABLING) >                 return BLEND_3D_NONE; > >         dpu_cstate = to_dpu_crtc_state(phys_enc->parent->crtc->state); > > +    /* Use merge_3d unless DSCMERGE topology is used */ >         if (phys_enc->split_role == ENC_ROLE_SOLO && > +           hweight(dpu_encoder_helper_get_dsc(phys_enc)) != 1 && >             dpu_cstate->num_mixers == CRTC_DUAL_MIXERS) >                 return BLEND_3D_H_ROW_INT; > >         return BLEND_3D_NONE; > } This will not be enough. To detect whether DSC merge is enabled you need to query the topology. The above condition only checks if DSC is enabled not DSC merge. So the above function can be modified to use a helper like below instead of the hweight. bool dpu_encoder_get_dsc_merge_info(struct dpu_encoder_virt *dpu_enc) { struct msm_display_topology topology = {0}; topology = dpu_encoder_get_topology(...); if (topology.num_dsc > topology.num_intf) return true; else return false; } if (!dpu_encoder_get_dsc_merge_info() && other conditions listed above) return BLEND_3D_H_ROW_INT; else BLEND_3D_NONE; > > >> >> All that you have to do is in query whether DSC merge is used from the >> topology. You can do it in multiple ways: >> >> 1) Either query this from the encoder >> 2) Store a bool "dsc_merge" in the intf_cfg >> > >