Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp2246241rwd; Mon, 15 May 2023 09:04:21 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5P4O5uO+tcLp1U7hnHykYfKrEaNkbZFc7uBxDh8+cWrGBjEnTnZ4EJVifqKzOP7WgQh7e4 X-Received: by 2002:a05:6a20:728d:b0:100:47a5:d754 with SMTP id o13-20020a056a20728d00b0010047a5d754mr37381226pzk.23.1684166661082; Mon, 15 May 2023 09:04:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684166661; cv=none; d=google.com; s=arc-20160816; b=wZwNnd1ujklhFbew4UYU7AC5QwwfxjI3laBHO/Aix0EL2bLmFpScqaGaqfyJmdAXsI Sly+SM/zEDaAqk7FvqOAUNuBBfIpOvuJ1JNBjGz2MjPxAR1vm2fN8UNEaDMWphb5ufIM wC8/yUphm/Ol4pMxGdbzAT0L+lyPBqxXKLXSkxGYTidPa8trCKhqhPR642V3vfEofPle jGxfv3AuRZYwIS1NulAoNQWUuZ1tcU5F7vyWgFEOakIHBIyZ7apgMs4GuBhCOfBKqDaA isa8CKdf3l0prNSrUUAEKQr7HHRo4jx7g2vfME7830ElJWpUQMlr5GsEUA9kytHolZSS iH6w== 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 :content-language:references:cc:to:subject:from:user-agent :mime-version:date:message-id:dkim-signature; bh=qjABwUr1hXvkw414y+Eg3oGhQFuBwCDysLn+iQJNQ5s=; b=NoxOddR0uP3+FzzkSy6ZH648Zk5FeNaUON3W06QP17HQzi/VlDmyGsNiL1L3GGeUfv Z/IZpes4x0OHXDq/PucMk2pKo1ZEnkl13OCM8O+lc7rigJknm4aafqBMtGvD2oTB2cIe nB81VIgz5+4r1s0GxVvpX1ry0iI3kIZWEBb0B8nM3YNiltk2y/EKPNGFlQo15qDSlN25 GYvfnf/yEFCrB7s+sOmByzAVF+mYkFFfQfqhyvzBFTC2grO7Wyk6QjEMEBMbI6DvhvMs oVHs1I8WXT/JRS0p2KH+uLDcYO1kE7ELPndLn0d9wZuggvk4jkkccYYtMSBJ9H5e3bLi FTUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=o65VZDhA; 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=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bv185-20020a632ec2000000b0051970ed57e0si15912829pgb.9.2023.05.15.09.03.55; Mon, 15 May 2023 09:04:21 -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=@ti.com header.s=ti-com-17Q1 header.b=o65VZDhA; 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=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234849AbjEOQAD (ORCPT + 99 others); Mon, 15 May 2023 12:00:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60188 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241161AbjEOP76 (ORCPT ); Mon, 15 May 2023 11:59:58 -0400 Received: from lelv0143.ext.ti.com (lelv0143.ext.ti.com [198.47.23.248]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E310DE5D for ; Mon, 15 May 2023 08:59:53 -0700 (PDT) Received: from fllv0034.itg.ti.com ([10.64.40.246]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id 34FFxS6d003709; Mon, 15 May 2023 10:59:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1684166368; bh=qjABwUr1hXvkw414y+Eg3oGhQFuBwCDysLn+iQJNQ5s=; h=Date:From:Subject:To:CC:References:In-Reply-To; b=o65VZDhA6IbyPjFVJi8Xai37r2Vo709zJ9oODwsbk4REhO4K1/0t6EyiytEDepidH TM5n0XV4LEscwdWoRiRLtysGnKHwxBK8QayiX45qVf5WVpm2NbUtt+2hTDN9W0fp2I BcLLRzCXCpz3agYsrt27WrE9RBsbvp/JJXj9qqMo= Received: from DLEE101.ent.ti.com (dlee101.ent.ti.com [157.170.170.31]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 34FFxSWv030704 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 15 May 2023 10:59:28 -0500 Received: from DLEE105.ent.ti.com (157.170.170.35) by DLEE101.ent.ti.com (157.170.170.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Mon, 15 May 2023 10:59:27 -0500 Received: from fllv0039.itg.ti.com (10.64.41.19) by DLEE105.ent.ti.com (157.170.170.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Mon, 15 May 2023 10:59:27 -0500 Received: from [10.249.133.231] (ileaxei01-snat2.itg.ti.com [10.180.69.6]) by fllv0039.itg.ti.com (8.15.2/8.15.2) with ESMTP id 34FFxLdo091684; Mon, 15 May 2023 10:59:22 -0500 Message-ID: Date: Mon, 15 May 2023 21:29:20 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 From: Aradhya Bhatia Subject: Re: [PATCH v6 3/8] drm/bridge: mhdp8546: Add minimal format negotiation To: Tomi Valkeinen , Jyri Sarha , David Airlie , Daniel Vetter , Laurent Pinchart , Andrzej Hajda , Neil Armstrong , Robert Foss , Jonas Karlman , Jernej Skrabec , Rahul T R , Swapnil Jakhade , Boris Brezillon , Francesco Dolcini CC: DRI Development List , Linux Kernel List , Nishanth Menon , Vignesh Raghavendra , Devarsh Thakkar , Jayesh Choudhary References: <20230509093036.3303-1-a-bhatia1@ti.com> <20230509093036.3303-4-a-bhatia1@ti.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-Spam-Status: No, score=-8.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,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 Hi Tomi, On 12-May-23 14:45, Tomi Valkeinen wrote: > On 09/05/2023 12:30, Aradhya Bhatia wrote: >> From: Nikhil Devshatwar >> >> With new connector model, mhdp bridge will not create the connector and >> SoC driver will rely on format negotiation to setup the encoder format. >> >> Support minimal format negotiations hooks in the drm_bridge_funcs. >> Complete format negotiation can be added based on EDID data. >> This patch adds the minimal required support to avoid failure >> after moving to new connector model. >> >> Signed-off-by: Nikhil Devshatwar >> Reviewed-by: Tomi Valkeinen > > You need to add your SoB to this and the other patches. Okay! > >> --- >> >> Notes: >> >>      changes from v1: >>      * cosmetic fixes, commit message update. >> >>      changes from v5: >>      * dropped the default_bus_format variable and directly assigned >>        MEDIA_BUS_FMT_RGB121212_1X36 to input_fmts. >> >>   .../drm/bridge/cadence/cdns-mhdp8546-core.c   | 25 +++++++++++++++++++ >>   1 file changed, 25 insertions(+) >> >> diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c >> b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c >> index f6822dfa3805..623e4235c94f 100644 >> --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c >> +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c >> @@ -2146,6 +2146,30 @@ cdns_mhdp_bridge_atomic_reset(struct drm_bridge >> *bridge) >>       return &cdns_mhdp_state->base; >>   } >>   +static u32 *cdns_mhdp_get_input_bus_fmts(struct drm_bridge *bridge, >> +                     struct drm_bridge_state *bridge_state, >> +                     struct drm_crtc_state *crtc_state, >> +                     struct drm_connector_state *conn_state, >> +                     u32 output_fmt, >> +                     unsigned int *num_input_fmts) >> +{ >> +    u32 *input_fmts; >> + >> +    *num_input_fmts = 0; >> + >> +    if (output_fmt != MEDIA_BUS_FMT_FIXED) >> +        return NULL; > > The tfp410 and sii902x drivers don't have the above check. Why does mhdp > need it? Or the other way, why don't tfp410 and sii902x need it? I had removed this condition in order to follow status quo, from the ITE-66121 HDMI bridge driver. The idea would have been to drop this for MHDP as well, but I guess I overlooked this one. However... > I guess at the moment we always do get MEDIA_BUS_FMT_FIXED as the out > fmt (in all three bridge drivers), don't we? ... I tested again to ensure that the above is indeed the case. And ended up catching some odd behavior. It turns out that for all the HDMI bridges (TFP410, SII902X, ITE-66121), the format negotiation doesn't stop at output_fmt = MEDIA_BUS_FMT_FIXED. The {bridge}_get_input_format API gets called again with the output_fmt = MEDIA_BUS_FMT_RGB24_1X24. This doesn't happen with the MHDP driver. Format negotiation with MHDP bridge stops after one round, at output_fmt = MEDIA_BUS_FMT_FIXED. Regards Aradhya