Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp5150664rwr; Mon, 8 May 2023 19:23:47 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4/8U5ErJPOH/9mpSoKM7Q54ncrnR61SzkuYZVPb1cnCp2rQ/JoROW77SsfOG4/ZU0qJZay X-Received: by 2002:a17:902:e805:b0:1ac:820e:c34a with SMTP id u5-20020a170902e80500b001ac820ec34amr4893676plg.0.1683599026619; Mon, 08 May 2023 19:23:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683599026; cv=none; d=google.com; s=arc-20160816; b=Q5YN/XvNFtyrh3dYyhKzdssVugu8cW7K3LzHr+t3grVoJ5Cr/AITUgFC9lVbpJr8t5 vACXrV9VDPY96SuUhMEbIu1jo1hZJ9m0fgo882LjGp4SPtCHzpFLBx9Su9o3tOufx1rN Akyvsb57wJOuYkpJRM8561CUDAnYWDXUOudIx+eOMl04nKi8EFZ7mGtceVadKRu2TDIA ayFOMKltWu6jgYvsv91AwW7amyAuOAOMjbHB7tBt/O9ZxhhBejs9zELGJKlB+LTQKatL jk+3ZJ+E1kkOWf2ClIXpFgw/uq9ikcLoDduMwAahMJiqkdnu9dFlvIhmqFMRlo6ar3r/ X9gA== 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=xEoYb2xvPRwLyc46wdI5EgNKAR1nZoXMta3OPGG44ew=; b=TN5b/FWQo+/jSHH1IUtaSa+5e1XLdsoG14VyUbGEo52jJMJ0v2ERWK4Q5rgwKqInIZ zwvLBQXe4rDHCccyhu+SGdMJ+Oheaj4bDYFoTOCE9rvxBjsOKblXomG8X1sA4zaQ0pzz WfhSP/Z26BwsgWi0PkFBnXBfjbCioZqmBpNPunFZMo8j2+8yKiK5GXhcNL1GHu6u1BZ4 vW571IioWffHwe9vvyBeYhi3mlavCC9l/ALdlObnveqlFLOdx/+/7z3HV6Jff3NH4pYC Z7tgvJWpAeIF4c2mE5usnx053FTkDC/ELXwgLV5YIa/9WPagyJp8ZtFsAZ91XemcTu79 0UpA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@denx.de header.s=phobos-20191101 header.b=iWod83Xh; 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=denx.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x3-20020a170902ec8300b001ab19e023a1si399982plg.375.2023.05.08.19.23.30; Mon, 08 May 2023 19:23:46 -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=@denx.de header.s=phobos-20191101 header.b=iWod83Xh; 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=denx.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232223AbjEICOi (ORCPT + 99 others); Mon, 8 May 2023 22:14:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57412 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234220AbjEICOg (ORCPT ); Mon, 8 May 2023 22:14:36 -0400 Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A32A99EE2; Mon, 8 May 2023 19:14:13 -0700 (PDT) Received: from [127.0.0.1] (p578adb1c.dip0.t-ipconnect.de [87.138.219.28]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: marex@denx.de) by phobos.denx.de (Postfix) with ESMTPSA id 5008C85FE2; Tue, 9 May 2023 04:14:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1683598452; bh=xEoYb2xvPRwLyc46wdI5EgNKAR1nZoXMta3OPGG44ew=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=iWod83Xhh6gAViiy3/MfBkHDYkQuG/qh40xtEs0jtBlKRA/OdT3BfO3FXR9adLr4G 2/Xb1PU+NaVDclwGDHsq1746zUPFevni+6Tr5I8zbmWp0bC5T0gs0Fm8ZDltUgIE7S c2XA4bOOl2Ybk9HXuML0oPjxs9d6DrJKss9Z9wf/qOfRp2vDv6ChSlrwSrpZaDpmoh 4+OokQhVBPbGturixBLeKY5iKH5gqD5KOBPXsbdrjjIuhQvQ4uFKcuklmYJRYAbkcz wCo5j1m02g+YpmO1y2EOuda0kN6Z7i+jpIXR9u2wkuJ2OyJCr6PNekNte19gMti8Lt i+t6nPP0de12g== Message-ID: <2ef8da6c-a16b-4396-1456-9a4d75ca5200@denx.de> Date: Tue, 9 May 2023 02:23:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH v5 5/6] drm: lcdif: Add multiple encoders and first bridges support Content-Language: en-US To: Liu Ying , dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Cc: stefan@agner.ch, airlied@gmail.com, daniel@ffwll.ch, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, shawnguo@kernel.org, s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com, linux-imx@nxp.com, krzysztof.kozlowski@linaro.org, LW@karo-electronics.de, alexander.stein@ew.tq-group.com References: <20230508055740.635256-1-victor.liu@nxp.com> <20230508055740.635256-6-victor.liu@nxp.com> From: Marek Vasut In-Reply-To: <20230508055740.635256-6-victor.liu@nxp.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.103.8 at phobos.denx.de X-Virus-Status: Clean X-Spam-Status: No, score=-6.2 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,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/23 07:57, Liu Ying wrote: > The single LCDIF embedded in i.MX93 SoC may drive multiple displays > simultaneously. Look at LCDIF output port's remote port parents to > find all enabled first bridges. Add an encoder for each found bridge > and attach the bridge to the encoder. This is a preparation for > adding i.MX93 LCDIF support. > > Tested-by: Alexander Stein > Acked-by: Alexander Stein > Signed-off-by: Liu Ying > --- > v4->v5: > * Rebase upon v6.4-rc1 and resolve a trivial conflict. > * Add Alexander's A-b and T-b tags. > > v3->v4: > * Improve warning message when ignoring invalid LCDIF OF endpoint ids. > (Alexander) > > v2->v3: > * No change. > > v1->v2: > * Split from patch 2/2 in v1. (Marek, Alexander) > * Drop '!remote ||' from lcdif_attach_bridge(). (Lothar) > * Drop unneeded 'bridges' member from lcdif_drm_private structure. > > drivers/gpu/drm/mxsfb/lcdif_drv.c | 68 +++++++++++++++++++++++++++---- > drivers/gpu/drm/mxsfb/lcdif_drv.h | 4 +- > drivers/gpu/drm/mxsfb/lcdif_kms.c | 21 ++-------- > 3 files changed, 66 insertions(+), 27 deletions(-) > > diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c b/drivers/gpu/drm/mxsfb/lcdif_drv.c > index e816f87828fb..cf27b63b1899 100644 > --- a/drivers/gpu/drm/mxsfb/lcdif_drv.c > +++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c > @@ -9,13 +9,16 @@ > #include > #include > #include > +#include > #include > +#include > #include > #include > > #include > #include > #include > +#include > #include > #include > #include > @@ -38,19 +41,68 @@ static const struct drm_mode_config_helper_funcs lcdif_mode_config_helpers = { > .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm, > }; > > +static const struct drm_encoder_funcs lcdif_encoder_funcs = { > + .destroy = drm_encoder_cleanup, > +}; > + > static int lcdif_attach_bridge(struct lcdif_drm_private *lcdif) > { > - struct drm_device *drm = lcdif->drm; > + struct device *dev = lcdif->drm->dev; > + struct device_node *ep; > struct drm_bridge *bridge; > int ret; > > - bridge = devm_drm_of_get_bridge(drm->dev, drm->dev->of_node, 0, 0); > - if (IS_ERR(bridge)) > - return PTR_ERR(bridge); > - > - ret = drm_bridge_attach(&lcdif->encoder, bridge, NULL, 0); > - if (ret) > - return dev_err_probe(drm->dev, ret, "Failed to attach bridge\n"); > + for_each_endpoint_of_node(dev->of_node, ep) { > + struct device_node *remote; > + struct of_endpoint of_ep; > + struct drm_encoder *encoder; > + > + remote = of_graph_get_remote_port_parent(ep); > + if (!of_device_is_available(remote)) { > + of_node_put(remote); > + continue; > + } > + of_node_put(remote); > + > + ret = of_graph_parse_endpoint(ep, &of_ep); > + if (ret < 0) { > + dev_err(dev, "Failed to parse endpoint %pOF\n", ep); > + of_node_put(ep); > + return ret; > + } > + > + if (of_ep.id >= MAX_DISPLAYS) { Can we make the maximum number of displays, or really bridge, specific to IP instance instead (1 for mx8mp, 3 for mx93) ? If so, then I think we need to track a list of bridges in some linked list or some such dynamic structure, which would allow us to get rid of MAX_DISPLAYS macro. > + dev_warn(dev, "ingoring invalid endpoint id %u\n", of_ep.id); s@ingoring@ignoring@ [...]