Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp2933079ybk; Mon, 18 May 2020 11:26:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxA6kLUhARs3ZaW1VFZCz7vfEYzWnCCvumcs02TR9V6df7ddQKTvK0jDBfibEp6TFL2P9a9 X-Received: by 2002:aa7:d718:: with SMTP id t24mr15031150edq.29.1589826389129; Mon, 18 May 2020 11:26:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589826389; cv=none; d=google.com; s=arc-20160816; b=bNB5Pvdw31IsLjftLo+FNBN7qtP4GGbzeCzA+xBYcswPsVO1iJhpiQX2cABlPsCnLE I4vvLfq2ecq7G/Y175lX+KUUP1sqFMV4sz0VtyHEqXLKIafzp8LARxwwKhzHNeM/y0aL 1qbhXGJA905YXXyrZ/hwlihuWf4ZMFbICVRlffbyPA0JOsVcFbI7yrao3ZB6jPonfONr MeyUtIMN3hCK7D8vdziOrlNB7tVkglnRlPfTDRumgpn0FIhPllP6fjtGYuOjCiqYdJvo DfEzsCTlscra/Gsp5lnkBav95KOGiURx07fVWswxHffDRwAnQbTog/rV2Jxz2O7phWev lflA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=R5S7yMnY0AxXYilxigjacEzs6rYDyGOqvhQBCOmMXzs=; b=o3fbqsCicL2gq06PARiA7IRHjK8R2FeqpApcJR4/QrxNC7mfzzyRsV6WFq5Wdp7ns9 AawICEYip0nFxNQWATgvILeyTQcPn159Tf8wwU6mTE5go30yrfvqhF+uJ3X9a4r7AgrU SvA5fUjask3KzHlmv950xPDnMt/189H93IjHGiyneBgjGXYPk3q2orMLzMCq2XNs/OM5 33mGTa88tqmMvUuiDNStA+YWjBZQzT+8TJnH0jElmFvjEndrZjBLl+iPuCbmv1w7gijh 44UkQL7vGrIW59GrFl6djegBbBc3FgnylfEzHW0O28MNLpDmnn2dV6ZZQT21ay9Z2dzU leSw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a20si6347910edr.516.2020.05.18.11.26.05; Mon, 18 May 2020 11:26:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729994AbgERRtB (ORCPT + 99 others); Mon, 18 May 2020 13:49:01 -0400 Received: from asavdk4.altibox.net ([109.247.116.15]:40232 "EHLO asavdk4.altibox.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729906AbgERRs5 (ORCPT ); Mon, 18 May 2020 13:48:57 -0400 Received: from ravnborg.org (unknown [158.248.194.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by asavdk4.altibox.net (Postfix) with ESMTPS id 4F54380512; Mon, 18 May 2020 19:48:49 +0200 (CEST) Date: Mon, 18 May 2020 19:48:47 +0200 From: Sam Ravnborg To: Enric Balletbo Serra Cc: Chun-Kuang Hu , Enric Balletbo i Serra , linux-kernel , Collabora Kernel ML , Nicolas Boichat , Philipp Zabel , David Airlie , dri-devel , "moderated list:ARM/Mediatek SoC support" , Laurent Pinchart , Daniel Vetter , Hsin-Yi Wang , Matthias Brugger , Linux ARM Subject: Re: [PATCH v4 7/7] drm/mediatek: mtk_dsi: Create connector for bridges Message-ID: <20200518174847.GA770263@ravnborg.org> References: <20200501152335.1805790-1-enric.balletbo@collabora.com> <20200501152335.1805790-8-enric.balletbo@collabora.com> <53683f2d-23c7-57ab-2056-520c50795ffe@collabora.com> <37191700-5832-2931-5764-7f7fddd023b9@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-CMAE-Score: 0 X-CMAE-Analysis: v=2.3 cv=MOBOZvRl c=1 sm=1 tr=0 a=UWs3HLbX/2nnQ3s7vZ42gw==:117 a=UWs3HLbX/2nnQ3s7vZ42gw==:17 a=kj9zAlcOel0A:10 a=33rsfa9LKxz_d3rkTGwA:9 a=mxk1C73UtW0IAQGh:21 a=CjuIK1q_8ugA:10 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Enric/Chun-Kuang. > > > > My point is: when do you attach panel to a connector? > > In this patch, > > > > ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL, > > DRM_BRIDGE_ATTACH_NO_CONNECTOR); > > > > it would call into mtk_dsi_bridge_attach() with > > DRM_BRIDGE_ATTACH_NO_CONNECTOR, and call into panel_bridge_attach() > > with DRM_BRIDGE_ATTACH_NO_CONNECTOR. > > My understanding is that the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is to > ease transition between the old and the new model. The drivers that > support the new model shall set that flag. Yes, right now we have fous on migrating all bridge drivers to the new model and next step is to make the transition for the display drivers one by one. Display drivers that uses the old model rely on the bridge driver to create the connector, whereas display drivers using the new model will create the connector themself. Display drivers following the new model will pass DRM_BRIDGE_ATTACH_NO_CONNECTOR to tell the bridge drive that no connector shall be created by the bridge driver. For this driver where only the new model is needed there is no reason to try to support both models. So the display driver shall always create the connector, and never ask the bridge driver to do it (always pass DRM_BRIDGE_ATTACH_NO_CONNECTOR). I hope this confirm and clarifies it. Sam