Received: by 2002:a05:6a10:2726:0:0:0:0 with SMTP id ib38csp3486558pxb; Mon, 4 Apr 2022 18:31:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx5RzlCQzjwzl1hI/buu77O9HNmeYKHi07akLYF92AU5NqogKXpI/r0n+tuaqMWqYWHAhgw X-Received: by 2002:a17:902:8a81:b0:155:f91b:9ac with SMTP id p1-20020a1709028a8100b00155f91b09acmr1036188plo.37.1649122319559; Mon, 04 Apr 2022 18:31:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649122319; cv=none; d=google.com; s=arc-20160816; b=0CrYsm7la6bmBmx0fnQyZJkrGo+8Oi45Jy6x4Nt81yioqhIlFhhN4gMec70UhZttjH 8MEn1JUZPooeWIcXE6Jy5mscLe36WVNBUhF4UOJJqVnhtxFyN/L0V8GIcUIyuyz+VFoL PVmuJaDbwMigWau9BUB4RmeTsteGh84ZJYIMfUIcPxSmIySz5b68v5snvjnRK/H21ff2 H8PF+YtWww3+kdcmMEhIqGagK0YZmxrcVdGtOFoR6R0px4H/AquznBCNr5XHVkl38oWN rFJFprnT1N1t09qUwfb82JqLvyA5lkB1abYIw6oYTGMgeKd8ustUpSOFIswz8xLYg3iP +CEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=P2d3No4EDXkEh3l7L1vhz/J82XaNZW1KUTwfTQprtMI=; b=r6pwFjEq70O9LFOJxHUnEsyV2kdwPAODCYDAKMJ7TPm90Pth8C+5gCn1WZLyrZxSLl P0fPaiUYjd++RZk0n2bOJTzLRbLfijRH1jIlMY2IPmZTU+iRJes/cmfqRIAIdI+AF8Dh CmU2N1ZfzK6+jGt52kmIPy5hqTjLN0Ro3xYHDDlKdMwJR/d4C6QeQrqVdtehIGDUFqAg //dbGc5mEyfhb8MqjDWlDid/heJnoMnIeUJw2HpeXPwzE0IfQi0v6KeHLmZGcQ8t+gTD nnl/R3SMmmHFY4268QdSeB4RSo3TMJMFbvKfC1+oU8lhfC1juSNZFK+MfuwGt0zrs1qD roVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=ixhmXyxr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id bt24-20020a17090af01800b001c651f909easi527108pjb.137.2022.04.04.18.31.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Apr 2022 18:31:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=ixhmXyxr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 3FC0D1D41BD; Mon, 4 Apr 2022 17:22:01 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343919AbiDAHql (ORCPT + 99 others); Fri, 1 Apr 2022 03:46:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43318 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236779AbiDAHqk (ORCPT ); Fri, 1 Apr 2022 03:46:40 -0400 Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E6F11697A8 for ; Fri, 1 Apr 2022 00:44:50 -0700 (PDT) Received: (Authenticated sender: paul.kocialkowski@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id 34E7D1BF206; Fri, 1 Apr 2022 07:44:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1648799089; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=P2d3No4EDXkEh3l7L1vhz/J82XaNZW1KUTwfTQprtMI=; b=ixhmXyxrKfJTOBUFTFjmcF1pqZICgVBc7T7yeYk0J3ogOABA+iOg5R9Jv5kc1CuUJ6JiPE b9RhyzNa81/eHrJFxaUlsc0+xh/NwDYvAT80C2P3vAf9yK9C0zf9w5bfJPVMNwKmHtIXRS O53OcFtIr8A5HMH+XR8F78LIJXZvgHeHBtq8pYR8zfWI/GsfNxykxZ/BkhwJU+15tqvPKD PIXZGUFV+/bTurtZpxs/G/bHoutebuGKyqOvy9e8S5Qbu8XfW6vGmBQ5KsoD03G1L7qRc9 MwCHcYwCGXqpQwUMms27g1bXV+p+KJn6SS6Hko315OpYMr8A3/uQXe2yPh6Wuw== Date: Fri, 1 Apr 2022 09:44:46 +0200 From: Paul Kocialkowski To: Bjorn Andersson Cc: Kuogee Hsieh , Dmitry Baryshkov , dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Linus Walleij , Jagan Teki , Thomas Petazzoni Subject: Re: [PATCH v3] drm: of: Properly try all possible cases for bridge/panel detection Message-ID: References: <20220329132732.628474-1-paul.kocialkowski@bootlin.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RmzJoGyI2gCKxmMX" Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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 --RmzJoGyI2gCKxmMX Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Bjorn, On Thu 31 Mar 22, 20:16, Bjorn Andersson wrote: > On Tue 29 Mar 06:27 PDT 2022, Paul Kocialkowski wrote: >=20 > > While bridge/panel detection was initially relying on the usual > > port/ports-based of graph detection, it was recently changed to > > perform the lookup on any child node that is not port/ports > > instead when such a node is available, with no fallback on the > > usual way. > >=20 > > This results in breaking detection when a child node is present > > but does not contain any panel or bridge node, even when the > > usual port/ports-based of graph is there. > >=20 > > In order to support both situations properly, this commit reworks > > the logic to try both options and not just one of the two: it will > > only return -EPROBE_DEFER when both have failed. > >=20 >=20 > Thanks for your patch Paul, it fixed a regression on a device where I > have a eDP bridge with an of_graph and a aux-bus defined. >=20 > But unfortunately it does not resolve the regression I have for the > USB based DisplayPort setup described below. >=20 >=20 > In the Qualcomm DisplayPort driver We're calling: >=20 > devm_drm_of_get_bridge(dev, dev->of_node, 1, 0); >=20 > and with the following DT snippet the behavior changed: >=20 > displayport-controller@ae90000 { > compatible =3D "qcom,sc8180x-dp"; > ... >=20 > operating-points-v2 =3D <&dp0_opp_table>; >=20 > ports { > #address-cells =3D <1>; > #size-cells =3D <0>; >=20 > port@0 { > reg =3D <0>; > dp0_in: endpoint { > remote-endpoint =3D <&display_driver>; > }; > }; > }; >=20 > dp0_opp_table: opp-table { > ...; > }; > }; >=20 > Prior to the introduction of 80253168dbfd ("drm: of: Lookup if child > node has panel or bridge") this would return -ENODEV, so we could > differentiate the case when we have a statically defined eDP panel from > that of a dynamically attached (over USB) DP panel. >=20 > Prior to your change, above case without the opp-table node would have > still returned -ENODEV. >=20 > But now this will just return -EPROBE_DEFER in both cases. Oh that's right, the -ENODEV case was just completely removed by my change. Initially this would happen if !of_graph_is_present or if the remote node doesn't exist. Now that we are also checking for child nodes, we can't just return -ENODEV when the graph or remote node is missing: we must also check that there is = no child node that is a panel/bridge. For the graph remote case, we can reliabily return -EPROBE_DEFER when of_graph_is_present and the remote exists and of_device_is_available. Otherwise we can go for -ENODEV. I think getting -EPROBE_DEFER at this point should stop the drm_of_find_panel_or_bridge process. On the other hand for the child panel/bridge node case, I don't see how we can reliably distinguish between -EPROBE_DEFER and -ENODEV, because of_drm_find_panel and of_drm_find_bridge will behave the same if the child node is a not-yet-probed panel/bridge or a totally unrelated node. So I think we should always return -EPROBE_DEFER in that case. As a result you can't get -ENODEV if using the of graph while having any (unrelated) child node there, so your issue remains. Do you see any way we could make this work? > I thought the appropriate method of referencing the dsi panel was to > actually reference that using the of_graph, even though it's a child of > the dsi controller - that's at least how we've done it in e.g. [1]. > I find this to be much nicer than to just blindly define that all > children of any sort of display controller must be a bridge or a panel. Yes I totally agree. Given that using the child node directly apparently can't allow us to distinguish between -EPROBE_DEFER/-ENODEV I would be in favor of dropping this mechanism and going with explicit of graph in any ca= se (even if it's a child node). I don't see any downside to this approach. What do yout think? Paul > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tr= ee/arch/arm64/boot/dts/qcom/sdm845-mtp.dts#n436 >=20 > Regards, > Bjorn >=20 > > Signed-off-by: Paul Kocialkowski > > Fixes: 80253168dbfd ("drm: of: Lookup if child node has panel or bridge= ") > > --- > >=20 > > Changes since v2: > > - Removed unnecessary else statement and added a comment about > > clearing the panel pointer on error. > >=20 > > Changes since v1: > > - Renamed remote to node; > > - Renamed helper to find_panel_or_bridge; > > - Cleared bridge pointer early; > > - Returned early to make the code more concise; > >=20 > > --- > > drivers/gpu/drm/drm_of.c | 99 ++++++++++++++++++++-------------------- > > 1 file changed, 50 insertions(+), 49 deletions(-) > >=20 > > diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c > > index 9d90cd75c457..8716da6369a6 100644 > > --- a/drivers/gpu/drm/drm_of.c > > +++ b/drivers/gpu/drm/drm_of.c > > @@ -219,6 +219,29 @@ int drm_of_encoder_active_endpoint(struct device_n= ode *node, > > } > > EXPORT_SYMBOL_GPL(drm_of_encoder_active_endpoint); > > =20 > > +static int find_panel_or_bridge(struct device_node *node, > > + struct drm_panel **panel, > > + struct drm_bridge **bridge) > > +{ > > + if (panel) { > > + *panel =3D of_drm_find_panel(node); > > + if (!IS_ERR(*panel)) > > + return 0; > > + > > + /* Clear the panel pointer in case of error. */ > > + *panel =3D NULL; > > + } > > + > > + /* No panel found yet, check for a bridge next. */ > > + if (bridge) { > > + *bridge =3D of_drm_find_bridge(node); > > + if (*bridge) > > + return 0; > > + } > > + > > + return -EPROBE_DEFER; > > +} > > + > > /** > > * drm_of_find_panel_or_bridge - return connected panel or bridge devi= ce > > * @np: device tree node containing encoder output ports > > @@ -241,66 +264,44 @@ int drm_of_find_panel_or_bridge(const struct devi= ce_node *np, > > struct drm_panel **panel, > > struct drm_bridge **bridge) > > { > > - int ret =3D -EPROBE_DEFER; > > - struct device_node *remote; > > + struct device_node *node; > > + int ret; > > =20 > > if (!panel && !bridge) > > return -EINVAL; > > + > > if (panel) > > *panel =3D NULL; > > - > > - /** > > - * Devices can also be child nodes when we also control that device > > - * through the upstream device (ie, MIPI-DCS for a MIPI-DSI device). > > - * > > - * Lookup for a child node of the given parent that isn't either port > > - * or ports. > > - */ > > - for_each_available_child_of_node(np, remote) { > > - if (of_node_name_eq(remote, "port") || > > - of_node_name_eq(remote, "ports")) > > - continue; > > - > > - goto of_find_panel_or_bridge; > > + if (bridge) > > + *bridge =3D NULL; > > + > > + /* Check for a graph on the device node first. */ > > + if (of_graph_is_present(np)) { > > + node =3D of_graph_get_remote_node(np, port, endpoint); > > + if (node) { > > + ret =3D find_panel_or_bridge(node, panel, bridge); > > + of_node_put(node); > > + > > + if (!ret) > > + return 0; > > + } > > } > > =20 > > - /* > > - * of_graph_get_remote_node() produces a noisy error message if port > > - * node isn't found and the absence of the port is a legit case here, > > - * so at first we silently check whether graph presents in the > > - * device-tree node. > > - */ > > - if (!of_graph_is_present(np)) > > - return -ENODEV; > > - > > - remote =3D of_graph_get_remote_node(np, port, endpoint); > > - > > -of_find_panel_or_bridge: > > - if (!remote) > > - return -ENODEV; > > + /* Otherwise check for any child node other than port/ports. */ > > + for_each_available_child_of_node(np, node) { > > + if (of_node_name_eq(node, "port") || > > + of_node_name_eq(node, "ports")) > > + continue; > > =20 > > - if (panel) { > > - *panel =3D of_drm_find_panel(remote); > > - if (!IS_ERR(*panel)) > > - ret =3D 0; > > - else > > - *panel =3D NULL; > > - } > > - > > - /* No panel found yet, check for a bridge next. */ > > - if (bridge) { > > - if (ret) { > > - *bridge =3D of_drm_find_bridge(remote); > > - if (*bridge) > > - ret =3D 0; > > - } else { > > - *bridge =3D NULL; > > - } > > + ret =3D find_panel_or_bridge(node, panel, bridge); > > + of_node_put(node); > > =20 > > + /* Stop at the first found occurrence. */ > > + if (!ret) > > + return 0; > > } > > =20 > > - of_node_put(remote); > > - return ret; > > + return -EPROBE_DEFER; > > } > > EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge); > > =20 > > --=20 > > 2.35.1 > >=20 --=20 Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com --RmzJoGyI2gCKxmMX Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEJZpWjZeIetVBefti3cLmz3+fv9EFAmJGrW4ACgkQ3cLmz3+f v9E0GAf/TTQSoT8Uptk97ABofCuAwM4f1FkNEk95OXicipadFTC7w9N1dfqBni6f pOaAg2X6rotvMUKzFbgLAP6zyyEaGkqhlq0J/K3Wa56Zygi4zlv3DmGhjOuEHliH FHbEdOJFEn5DzlGLy3IUjGCO+lsURqB4RE5AOZSYqR2fhIrHzNdbB9yQ7FPydLbJ nmH9o0qkrX37bXLgTz4YYT0fuZ8rEHJYZsqfAFw6wakP54IqLx4DEe+IHjqzUo5t 4zSX/n45GZsJ5BLoelmFeVhewG2/MfRWHQ9PmYo+vYgZ2sG+gTo9wuR1WMstdwba utI3/aj0CuyAPUsOOCrBQeRgsYdzpw== =Dhbj -----END PGP SIGNATURE----- --RmzJoGyI2gCKxmMX--