Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp1427305ybk; Thu, 14 May 2020 08:44:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxNIHnHwhmw3JiI7gNiSarTzJymsB9QWiibF7WMZBQvbj/RrTGOzp6VzDJRcOWrHpXfRuq3 X-Received: by 2002:aa7:dac4:: with SMTP id x4mr4374745eds.127.1589471051715; Thu, 14 May 2020 08:44:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589471051; cv=none; d=google.com; s=arc-20160816; b=JqZd/ahjzoJhYyf33uqkUfXSG4azpeVLOmDZnui/kL4tjoU9fGi1jenfWWbGRc8zFO gWenIjNgUebtbs1zvGRVxdxZjaz0KK0MB/v0YORgBwkw4v31Nd9Vu28M981XQoO0Hu4D m3MyzeXC/K1NeAlzc77cDhSCWJLoFwBDwdDWuEKbxknX6FlhIMpLZTptz8gW6nR/1mpv X+FZWovirB/ExDxN5HILNkAgUfOYxFEz0GugtHsC7diP+v6jlWyVYhUk2Dm9zYD8HT2c UHPCPrZfdOF0xm1RN8xt2ZOyNl4T/3L+f0lD+4osX9Ds54NklH1i4k/Tgw5mwW3mZ5XX p7jA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=hHBdT4v2pqY0CLzpcipnAJnzySi8oO3QrBqDJM6g04A=; b=MobM002n00T6xWuZXfjBtPqgkWvwmTitxUTEeGni7x+dcYcwGDYoXNghaGlfz1dSjm 659mCEOwoJ/Vyx/+vvFB1DJ1Fzwm1IK1UYrSkqk4C7n/nf+umPSGMcCBVCHS4v2s1ltf nxQ4sQBAyeOEd1YSfOJDOT/eVPXKgE4nNtCkIBuYyD8uxIXP0KICiD/44rwBVd/0ah58 UpNDzHj8nOwDKSJq+g4Q32aO9wKkEInihMKZ/7FrfKMu5zFdV6l1wvsF1pwI2Bu/47fT WGnNQGpKa2BBjL5ciB92oLse/eeXmabf9y0EcjNLfQy6UpOYomUL5b+AQiwOJb8wb9bK BMXA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w13si2173013edf.228.2020.05.14.08.43.47; Thu, 14 May 2020 08:44:11 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727827AbgENPmV (ORCPT + 99 others); Thu, 14 May 2020 11:42:21 -0400 Received: from bhuna.collabora.co.uk ([46.235.227.227]:33254 "EHLO bhuna.collabora.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726056AbgENPmV (ORCPT ); Thu, 14 May 2020 11:42:21 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: eballetbo) with ESMTPSA id E7DE12A2F7B Subject: Re: [PATCH v4 7/7] drm/mediatek: mtk_dsi: Create connector for bridges To: Chun-Kuang Hu , Enric Balletbo Serra Cc: 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 , Sam Ravnborg , Linux ARM References: <20200501152335.1805790-1-enric.balletbo@collabora.com> <20200501152335.1805790-8-enric.balletbo@collabora.com> From: Enric Balletbo i Serra Message-ID: <53683f2d-23c7-57ab-2056-520c50795ffe@collabora.com> Date: Thu, 14 May 2020 17:42:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Chun-Kuang, On 14/5/20 16:28, Chun-Kuang Hu wrote: > Hi, Enric: > > Enric Balletbo Serra 於 2020年5月14日 週四 上午12:41寫道: >> >> Hi Chun-Kuang, >> >> Missatge de Enric Balletbo i Serra del >> dia dv., 1 de maig 2020 a les 17:25: >>> >>> Use the drm_bridge_connector helper to create a connector for pipelines >>> that use drm_bridge. This allows splitting connector operations across >>> multiple bridges when necessary, instead of having the last bridge in >>> the chain creating the connector and handling all connector operations >>> internally. >>> >>> Signed-off-by: Enric Balletbo i Serra >>> Acked-by: Sam Ravnborg >> >> A gentle ping on this, I think that this one is the only one that >> still needs a review in the series. > > This is what I reply in patch v3: > Sorry for missing this. > I think the panel is wrapped into next_bridge here, > Yes, you can have for example: 1. drm_bridge (mtk_dsi) -> drm_bridge (ps8640 - dsi-to-edp) -> drm_panel_bridge (edp panel) or a 2. drm_bridge (mtk_dsi)-> drm_panel_bridge (dsi panel) The _first_ one is my use case > if (panel) { This handles the second case, where you attach a dsi panel. > dsi->next_bridge = devm_drm_panel_bridge_add(dev, panel); > > so the next_bridge is a panel_bridge, in its attach function > panel_bridge_attach(), > according to the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR, if not exist, > it would create connector and attach connector to panel. > > I'm not sure this flag would exist or not, but for both case, it's strange. > If exist, you create connector in this patch but no where to attach > connector to panel. Yes, in fact, this is transitional patch needed, as once I converted mtk_dpi, mtk_dsi and mtk_hdmi to the new drm_bridge API the drm_bridge_connector_init() will be done in mtk_drm_drv. We will need to call drm_bridge_connector_init for dpi and dsi pipes and remove that call from mtk_dsi and mtk_dpi drivers. The graphic controller driver should create connectors and CRTCs, as example you can take a look at drivers/gpu/drm/omapdrm/omap_drv.c > If not exist, the next_brige would create one connector and this brige > would create another connector. > > I think in your case, mtk_dsi does not directly connect to a panel, so Exactly > I need a exact explain. Or someone could test this on a > directly-connect-panel platform. I don't think I am breaking this use case but AFAICS there is no users in mainline that directly connect a panel using the mediatek driver. As I said my use case is the other so I can't really test. Do you know anyone that can test this? Thanks, Enric > > Regards, > Chun-Kuang. > >> >> Thanks, >> Enric >> >>> --- >>> >>> Changes in v4: None >>> Changes in v3: >>> - Move the bridge.type line to the patch that adds drm_bridge support. (Laurent Pinchart) >>> >>> Changes in v2: None >>> >>> drivers/gpu/drm/mediatek/mtk_dsi.c | 13 ++++++++++++- >>> 1 file changed, 12 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c >>> index 4f3bd095c1ee..471fcafdf348 100644 >>> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c >>> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c >>> @@ -17,6 +17,7 @@ >>> >>> #include >>> #include >>> +#include >>> #include >>> #include >>> #include >>> @@ -183,6 +184,7 @@ struct mtk_dsi { >>> struct drm_encoder encoder; >>> struct drm_bridge bridge; >>> struct drm_bridge *next_bridge; >>> + struct drm_connector *connector; >>> struct phy *phy; >>> >>> void __iomem *regs; >>> @@ -977,10 +979,19 @@ static int mtk_dsi_encoder_init(struct drm_device *drm, struct mtk_dsi *dsi) >>> */ >>> dsi->encoder.possible_crtcs = 1; >>> >>> - ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL, 0); >>> + ret = drm_bridge_attach(&dsi->encoder, &dsi->bridge, NULL, >>> + DRM_BRIDGE_ATTACH_NO_CONNECTOR); >>> if (ret) >>> goto err_cleanup_encoder; >>> >>> + dsi->connector = drm_bridge_connector_init(drm, &dsi->encoder); >>> + if (IS_ERR(dsi->connector)) { >>> + DRM_ERROR("Unable to create bridge connector\n"); >>> + ret = PTR_ERR(dsi->connector); >>> + goto err_cleanup_encoder; >>> + } >>> + drm_connector_attach_encoder(dsi->connector, &dsi->encoder); >>> + >>> return 0; >>> >>> err_cleanup_encoder: >>> -- >>> 2.26.2 >>> >>> >>> _______________________________________________ >>> Linux-mediatek mailing list >>> Linux-mediatek@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-mediatek