From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D1A96C433FE for ; Tue, 26 Apr 2022 12:54:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235085AbiDZM5P (ORCPT ); Tue, 26 Apr 2022 08:57:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59270 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350041AbiDZM5M (ORCPT ); Tue, 26 Apr 2022 08:57:12 -0400 Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6CDDA17DA13 for ; Tue, 26 Apr 2022 05:54:04 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C9C7C5C01AB; Tue, 26 Apr 2022 08:54:03 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 26 Apr 2022 08:54:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1650977643; x=1651064043; bh=KqyOC63okT CBiZ8lJYPrKN9nzXKeDkTwLdtSOukq/2E=; b=cj3X/K838OBL/WFeHgbEJXzedj 13tSVv8zQe0VlGl9J60aelN/dBdUNf3rokUv6/sX5NxTEwQ+8J/ElQqTrqxTSzq1 6dVl/PBu6W+iKvdGpcuYBb8duWaaxgRdDtUwRtx+5ueeahia53pk0Ry2KLWfPyy9 lU5JlrhrXqIIXhJxDZXterHrQzmhi5B97K0cF1LiJtigdlCtIeslvojtp3ufMsRy 28ZCn5uXH6HtmOxxYv59AaxDo9uaP7kRXax2c5mcG6jPm2PHbWMrxYA/D+NoPQT7 Va/iuEgBRYDQemTz9iSZq/EBIWCCTZh7aIOT6RytwTCmLuEdYZjFxsx6zhmg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1650977643; x= 1651064043; bh=KqyOC63okTCBiZ8lJYPrKN9nzXKeDkTwLdtSOukq/2E=; b=V HP4ImsGg2NK1FxzrLMDBrSdd/YbtNX7CciCgJr0nkR6ynG4YEa0siMwH7TSjLc7V tnT6t4UUOn2xHQ1B3H515clGBR/iL6WUpBrB1NMZXlBmCkUTT0PR0TLdbhPzbuFE xo+3NV9vQc+p0gM/e0K9zat8/5kB3lFmiFhjxX/U2oGz1f/gvCPmt5uRoZygI4mK YZwG57aNlhLDB1anaCNx82mXkDaNNW3mfXyOZxUrmC9CkGpEY2gN7cHzOHjq1+2t hwS159Jw7/AIJIBDhmuwworreEMvx/bMxQh4/LqCJM415m242Ak45Joe7Jvd4+Lg RhLMLGG7rlwIS/QPeL4Xg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudefgdehgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpeforgigihhm vgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrth htvghrnhepteefffefgfektdefgfeludfgtdejfeejvddttdekteeiffejvdfgheehfffh vedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmh grgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 26 Apr 2022 08:54:03 -0400 (EDT) Date: Tue, 26 Apr 2022 14:54:01 +0200 From: Maxime Ripard To: Paul Kocialkowski Cc: Laurent Pinchart , Jagan Teki , Bjorn Andersson , Maarten Lankhorst , Thomas Zimmermann , David Airlie , Daniel Vetter , Thierry Reding , Rob Clark , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Linus Walleij , Marek Szyprowski , Robert Foss Subject: Re: [PATCH 2/2] Revert "drm: of: Lookup if child node has panel or bridge" Message-ID: <20220426125401.yyrhg6aeafdjw4ad@houat> References: <20220420231230.58499-1-bjorn.andersson@linaro.org> <20220420231230.58499-2-bjorn.andersson@linaro.org> <20220421082358.ivpmtak3ednvddrc@houat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="y6e5ldbnofa2rtha" Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --y6e5ldbnofa2rtha Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 26, 2022 at 02:41:44PM +0200, Paul Kocialkowski wrote: > On Tue 26 Apr 22, 14:33, Laurent Pinchart wrote: > > On Tue, Apr 26, 2022 at 09:54:36AM +0200, Paul Kocialkowski wrote: > > > On Thu 21 Apr 22, 10:59, Paul Kocialkowski wrote: > > > > On Thu 21 Apr 22, 10:23, Maxime Ripard wrote: > > > > > On Thu, Apr 21, 2022 at 01:15:54PM +0530, Jagan Teki wrote: > > > > > > + Linus > > > > > > + Marek > > > > > > + Laurent > > > > > > + Robert > > > > > >=20 > > > > > > On Thu, Apr 21, 2022 at 4:40 AM Bjorn Andersson wrote: > > > > > > > > > > > > > > Commit '80253168dbfd ("drm: of: Lookup if child node has pane= l or > > > > > > > bridge")' attempted to simplify the case of expressing a simp= le panel > > > > > > > under a DSI controller, by assuming that the first non-graph = child node > > > > > > > was a panel or bridge. > > > > > > > > > > > > > > Unfortunately for non-trivial cases the first child node migh= t not be a > > > > > > > panel or bridge. Examples of this can be a aux-bus in the ca= se of > > > > > > > DisplayPort, or an opp-table represented before the panel nod= e. > > > > > > > > > > > > > > In these cases the reverted commit prevents the caller from e= ver finding > > > > > > > a reference to the panel. > > > > > > > > > > > > > > This reverts commit '80253168dbfd ("drm: of: Lookup if child = node has > > > > > > > panel or bridge")', in favor of using an explicit graph refer= ence to the > > > > > > > panel in the trivial case as well. > > > > > >=20 > > > > > > This eventually breaks many child-based devm_drm_of_get_bridge > > > > > > switched drivers. Do you have any suggestions on how to procee= d to > > > > > > succeed in those use cases as well? > > > > >=20 > > > > > I guess we could create a new helper for those, like > > > > > devm_drm_of_get_bridge_with_panel, or something. > > > >=20 > > > > Oh wow I feel stupid for not thinking about that. > > > >=20 > > > > Yeah I agree that it seems like the best option. > > >=20 > > > Should I prepare a patch with such a new helper? > > >=20 > > > The idea would be to keep drm_of_find_panel_or_bridge only for the of= graph > > > case and add one for the child node case, maybe: > > > drm_of_find_child_panel_or_bridge. > > >=20 > > > I really don't have a clear idea of which driver would need to be swi= tched > > > over though. Could someone (Jagan?) let me know where it would be nee= ded? > > >=20 > > > Are there cases where we could both expect of graph and child node? > > > (i.e. does the new helper also need to try via of graph?) > >=20 > > I still think we should use OF graph uncondtionally, even in the DSI > > case. We need to ensure backward-compatibility, but I'd like new > > bindings (and thus new drivers) to always use OF graph. >=20 > I just went over the thread on "drm: of: Improve error handling in bridge= /panel > detection" again and I'm no longer sure there's actually still an issue t= hat > stands, with the fix that allows returning -ENODEV when possible. >=20 > The remaining issue that was brought up was with a connector node, but it= should > be up to the driver to detect that and avoid calling drm_of_find_panel_or= _bridge > in such situations. >=20 > So with that in mind it feels like the child node approach can be viable > (and integrated in the same helper). >=20 > We might still want to favor an explicit OF graph approach, but note that > dsi-controller.yaml also specifies extra properties that are specific to > MIPI DSI and I'm not sure there are equivalent definitions for the OF gra= ph > approach. >=20 > What do you think? I don't think Laurent's point was to move the child node away from its DSI controller, that part doesn't make much sense. The panel or bridge is still accessed through the DSI bus, so it very much belongs there. What he meant I think was that we mandate the OF graph for all panels, so for panels/bridges controlled through DCS, you would still list the output through the graph. Maxime --y6e5ldbnofa2rtha Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYmfraQAKCRDj7w1vZxhR xTLvAPwNTRGGtvE//BlyATQ4o/WTVAfO/eP5PRbMPa1jRUc95AD/a/wgPoeGE+ap VSrVt3Fc47ZURZmI1uOBRoIGcl1Kfgc= =4Mvq -----END PGP SIGNATURE----- --y6e5ldbnofa2rtha-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 88F09C433F5 for ; Tue, 26 Apr 2022 12:54:06 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9EC2910E067; Tue, 26 Apr 2022 12:54:05 +0000 (UTC) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by gabe.freedesktop.org (Postfix) with ESMTPS id 79FA610E067 for ; Tue, 26 Apr 2022 12:54:04 +0000 (UTC) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C9C7C5C01AB; Tue, 26 Apr 2022 08:54:03 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 26 Apr 2022 08:54:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h=cc :cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; t=1650977643; x=1651064043; bh=KqyOC63okT CBiZ8lJYPrKN9nzXKeDkTwLdtSOukq/2E=; b=cj3X/K838OBL/WFeHgbEJXzedj 13tSVv8zQe0VlGl9J60aelN/dBdUNf3rokUv6/sX5NxTEwQ+8J/ElQqTrqxTSzq1 6dVl/PBu6W+iKvdGpcuYBb8duWaaxgRdDtUwRtx+5ueeahia53pk0Ry2KLWfPyy9 lU5JlrhrXqIIXhJxDZXterHrQzmhi5B97K0cF1LiJtigdlCtIeslvojtp3ufMsRy 28ZCn5uXH6HtmOxxYv59AaxDo9uaP7kRXax2c5mcG6jPm2PHbWMrxYA/D+NoPQT7 Va/iuEgBRYDQemTz9iSZq/EBIWCCTZh7aIOT6RytwTCmLuEdYZjFxsx6zhmg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1650977643; x= 1651064043; bh=KqyOC63okTCBiZ8lJYPrKN9nzXKeDkTwLdtSOukq/2E=; b=V HP4ImsGg2NK1FxzrLMDBrSdd/YbtNX7CciCgJr0nkR6ynG4YEa0siMwH7TSjLc7V tnT6t4UUOn2xHQ1B3H515clGBR/iL6WUpBrB1NMZXlBmCkUTT0PR0TLdbhPzbuFE xo+3NV9vQc+p0gM/e0K9zat8/5kB3lFmiFhjxX/U2oGz1f/gvCPmt5uRoZygI4mK YZwG57aNlhLDB1anaCNx82mXkDaNNW3mfXyOZxUrmC9CkGpEY2gN7cHzOHjq1+2t hwS159Jw7/AIJIBDhmuwworreEMvx/bMxQh4/LqCJM415m242Ak45Joe7Jvd4+Lg RhLMLGG7rlwIS/QPeL4Xg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudefgdehgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfhfgggtuggjsehgtderredttddvnecuhfhrohhmpeforgigihhm vgcutfhiphgrrhguuceomhgrgihimhgvsegtvghrnhhordhtvggthheqnecuggftrfgrth htvghrnhepteefffefgfektdefgfeludfgtdejfeejvddttdekteeiffejvdfgheehfffh vedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmh grgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 26 Apr 2022 08:54:03 -0400 (EDT) Date: Tue, 26 Apr 2022 14:54:01 +0200 From: Maxime Ripard To: Paul Kocialkowski Subject: Re: [PATCH 2/2] Revert "drm: of: Lookup if child node has panel or bridge" Message-ID: <20220426125401.yyrhg6aeafdjw4ad@houat> References: <20220420231230.58499-1-bjorn.andersson@linaro.org> <20220420231230.58499-2-bjorn.andersson@linaro.org> <20220421082358.ivpmtak3ednvddrc@houat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="y6e5ldbnofa2rtha" Content-Disposition: inline In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: David Airlie , Robert Foss , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Bjorn Andersson , Thierry Reding , Laurent Pinchart , Thomas Zimmermann , Marek Szyprowski , Jagan Teki Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --y6e5ldbnofa2rtha Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 26, 2022 at 02:41:44PM +0200, Paul Kocialkowski wrote: > On Tue 26 Apr 22, 14:33, Laurent Pinchart wrote: > > On Tue, Apr 26, 2022 at 09:54:36AM +0200, Paul Kocialkowski wrote: > > > On Thu 21 Apr 22, 10:59, Paul Kocialkowski wrote: > > > > On Thu 21 Apr 22, 10:23, Maxime Ripard wrote: > > > > > On Thu, Apr 21, 2022 at 01:15:54PM +0530, Jagan Teki wrote: > > > > > > + Linus > > > > > > + Marek > > > > > > + Laurent > > > > > > + Robert > > > > > >=20 > > > > > > On Thu, Apr 21, 2022 at 4:40 AM Bjorn Andersson wrote: > > > > > > > > > > > > > > Commit '80253168dbfd ("drm: of: Lookup if child node has pane= l or > > > > > > > bridge")' attempted to simplify the case of expressing a simp= le panel > > > > > > > under a DSI controller, by assuming that the first non-graph = child node > > > > > > > was a panel or bridge. > > > > > > > > > > > > > > Unfortunately for non-trivial cases the first child node migh= t not be a > > > > > > > panel or bridge. Examples of this can be a aux-bus in the ca= se of > > > > > > > DisplayPort, or an opp-table represented before the panel nod= e. > > > > > > > > > > > > > > In these cases the reverted commit prevents the caller from e= ver finding > > > > > > > a reference to the panel. > > > > > > > > > > > > > > This reverts commit '80253168dbfd ("drm: of: Lookup if child = node has > > > > > > > panel or bridge")', in favor of using an explicit graph refer= ence to the > > > > > > > panel in the trivial case as well. > > > > > >=20 > > > > > > This eventually breaks many child-based devm_drm_of_get_bridge > > > > > > switched drivers. Do you have any suggestions on how to procee= d to > > > > > > succeed in those use cases as well? > > > > >=20 > > > > > I guess we could create a new helper for those, like > > > > > devm_drm_of_get_bridge_with_panel, or something. > > > >=20 > > > > Oh wow I feel stupid for not thinking about that. > > > >=20 > > > > Yeah I agree that it seems like the best option. > > >=20 > > > Should I prepare a patch with such a new helper? > > >=20 > > > The idea would be to keep drm_of_find_panel_or_bridge only for the of= graph > > > case and add one for the child node case, maybe: > > > drm_of_find_child_panel_or_bridge. > > >=20 > > > I really don't have a clear idea of which driver would need to be swi= tched > > > over though. Could someone (Jagan?) let me know where it would be nee= ded? > > >=20 > > > Are there cases where we could both expect of graph and child node? > > > (i.e. does the new helper also need to try via of graph?) > >=20 > > I still think we should use OF graph uncondtionally, even in the DSI > > case. We need to ensure backward-compatibility, but I'd like new > > bindings (and thus new drivers) to always use OF graph. >=20 > I just went over the thread on "drm: of: Improve error handling in bridge= /panel > detection" again and I'm no longer sure there's actually still an issue t= hat > stands, with the fix that allows returning -ENODEV when possible. >=20 > The remaining issue that was brought up was with a connector node, but it= should > be up to the driver to detect that and avoid calling drm_of_find_panel_or= _bridge > in such situations. >=20 > So with that in mind it feels like the child node approach can be viable > (and integrated in the same helper). >=20 > We might still want to favor an explicit OF graph approach, but note that > dsi-controller.yaml also specifies extra properties that are specific to > MIPI DSI and I'm not sure there are equivalent definitions for the OF gra= ph > approach. >=20 > What do you think? I don't think Laurent's point was to move the child node away from its DSI controller, that part doesn't make much sense. The panel or bridge is still accessed through the DSI bus, so it very much belongs there. What he meant I think was that we mandate the OF graph for all panels, so for panels/bridges controlled through DCS, you would still list the output through the graph. Maxime --y6e5ldbnofa2rtha Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYmfraQAKCRDj7w1vZxhR xTLvAPwNTRGGtvE//BlyATQ4o/WTVAfO/eP5PRbMPa1jRUc95AD/a/wgPoeGE+ap VSrVt3Fc47ZURZmI1uOBRoIGcl1Kfgc= =4Mvq -----END PGP SIGNATURE----- --y6e5ldbnofa2rtha--