| Message ID | 20220202160414.16493-1-jagan@amarulasolutions.com |
|---|---|
| State | New |
| Headers |
Return-Path: <linux-amarula+bncBD7MFH7A7EEBBCWX5KHQMGQE6JAHQJQ@amarulasolutions.com> X-Original-To: linux-amarula@patchwork.amarulasolutions.com Delivered-To: linux-amarula@patchwork.amarulasolutions.com Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) by ganimede.amarulasolutions.com (Postfix) with ESMTPS id 1FE913F03E for <linux-amarula@patchwork.amarulasolutions.com>; Wed, 2 Feb 2022 17:04:28 +0100 (CET) Received: by mail-pj1-f71.google.com with SMTP id s9-20020a17090aad8900b001b82d1e4dc8sf1398229pjq.6 for <linux-amarula@patchwork.amarulasolutions.com>; Wed, 02 Feb 2022 08:04:28 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1643817866; cv=pass; d=google.com; s=arc-20160816; b=OlWBQK3NZuvMGpO50b2qP18o21q8DV8tr62WjdTq/30WP7y7Vsa7nkloK/Mf6tePHW fimoOZlocSBGjeOC9zlcOhRJ68AZM78IaZHbdNLbRx0OP2ajNyMmpatXzdro4re2JPWa +zJ+jH35RS+VBk7RwLbmiWhfDV3auQxtMaSOiYbDMmpYMy84dn3Y9dofkxOWar0U8DXL 1PfqMJp2YuIawSkrPmBRGuHoinkNWcDYD/xco1h63h6iVckeYFTfN1QT8IPMEaN1kuHp zub8JEFeAnQQzRBskkaJ4vkbKL2aqpyk4xwJH+jGqOjrfCLA9L9st2IIuMmXi42f6gic 7xig== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-archive:list-help:list-post:list-id :mailing-list:precedence:mime-version:message-id:date:subject:cc:to :from:dkim-signature; bh=2vtqzNoPT2ZJjlaO+rj+8P4WNBN/Eb7rSySqQLHZpRM=; b=Uvl/VVPdzK/4v0d6FE8eSRp6SuKjHDDGCOcqp3ID0il0YaD4kVZc+RkPkqjIAAznvO wQAzSbfIvr07uCHYrUoytmkJCj3X+3ibLxtBcsmcZCh7cUQ2i+4aoJp/3KAEgfCSuM0d Y/Vj7WRmn8VwI6XdUxMnlSbqsR2EV5gHv5zCyhiv6uYsni+LhHv/XQue9bKepCdjfCDI EPce+OXkVyX5Sb1w/XYIARjKwgoUT0OjczzdRd+ImerIYmJFUP5vFRyZMqtr9AQ7CgpN kBB4eBYsdv0Her4XH7hMbtUVPrAxAmuIqMp+Nt+hcmCJ8gRmAaMVNSzENbmmnT5RaapG pC5Q== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=T6w0s4UD; spf=pass (google.com: domain of jagan@amarulasolutions.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jagan@amarulasolutions.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=from:to:cc:subject:date:message-id:mime-version:x-original-sender :x-original-authentication-results:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-unsubscribe; bh=2vtqzNoPT2ZJjlaO+rj+8P4WNBN/Eb7rSySqQLHZpRM=; b=rGV6mTV7wUeoPVthTpSCU5H8OKVMKS4D8eC6wyx544u2TwdowSySU+X2lB3FohNyCl p3Ikf/8l8TWTKAiHbaY5st1UsWj3Z5H/DFYKOvvTbydbufhF1NdaWoTTSEgF+1T22CHt NY7c99k6peZ2L8u2kKr7GkP1Ue52WGpDyaPjk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :x-original-sender:x-original-authentication-results:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-unsubscribe; bh=2vtqzNoPT2ZJjlaO+rj+8P4WNBN/Eb7rSySqQLHZpRM=; b=D6XB1NpUx82nk8Ei3ViZ5BcKlSy1iPbZtYQTetkSQNSkdr/tXqqh+RPq8x07Rvt0lW 2G0U1kBzXbnoPx2D+D0hbk/uXoHqjdQJ7NkH0lkgfVrDuewi+2tgsFanbPbV7/EhVeGa 9vtvg4JMIJNgAKXuShZVvxcATyftpTRWKgt9UPqyFCfoaVZO/t7jAhBDF4OElfrAQInq 18iPsf1PVWfjTmDbkRvFqiKGuHt9E43/E1ftK+wDIsANlUe4FtR2gQyvegkGKWOfY2Ff 3Ku2v91knFz1UzGFauiEkg6ij2qf4fPQoA/kBQAz8QtRtr0gX7CsPmfeJWNHlaiVJ/Og hjRA== X-Gm-Message-State: AOAM531lRTBJZrOI10gcjd+Jc3vQhRXTyFQfWCo0OQBvak0IixuI0q+k bLHrRW1VMvoQqE5+rAdaykH8392z X-Google-Smtp-Source: ABdhPJxw0Z++0ln96hlmgMvty9KwJtqgFWCMhwWvkbYeq2Qzd09351txygc3jQ5O53NixpQMrGm07Q== X-Received: by 2002:a63:214f:: with SMTP id s15mr2029102pgm.442.1643817866751; Wed, 02 Feb 2022 08:04:26 -0800 (PST) X-BeenThere: linux-amarula@amarulasolutions.com Received: by 2002:a17:90b:38cc:: with SMTP id nn12ls3755463pjb.1.canary-gmail; Wed, 02 Feb 2022 08:04:26 -0800 (PST) X-Received: by 2002:a17:902:780d:: with SMTP id p13mr5545815pll.32.1643817865937; Wed, 02 Feb 2022 08:04:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643817865; cv=none; d=google.com; s=arc-20160816; b=HFzgChs7EnQqNtpprvk4znTeJRjS+QNaQmMCs5sNQcPu8oRs4PD/qqH8QZx7fHnVTs 2CgzeJpfWDe6z8n+U0SQi2FgzkBgZ7fCgm00+0mXro5BzbaoDXLmULgC2TXS7DWTs+9P iAie3msvghFXx3EDriaLpEH8LUQNj3WZUzMCMkA4+vYKbtLzK7n9gPTO7b+wP9v4xe1u s3os7b8eQbpp4W5xvU5zsY58BSIqzaZ+P0ZSamnZ470RXDFLyt1+7QAg93iQF5V6avQ9 gdPYwD/wuuVDTKheWnp5W3zFmUCh8KfRHJglaWtuYj+2BQ1hN7B6zTq7FSRC5d4KrAtl XOdg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:dkim-signature; bh=Vdt15RbKeINjdAxS0uwzQxpkDqN0hKXbL17QnOjs/Kk=; b=r1YQ7tFU4LaD0xKJIewoZJrFjdSI7yphHKhCd15pODDfm0agksM/qaq7AV6CxpxHmR dVWKZIA17wR4mhY4AAuNs2+pvfqlf2nfBA2q3fLD4uBiK6X0DrqLX+Zh4JkNAwN/Awxu zphjuIfbLbD82oa98yHz0xdyYY3ErxRBYAnV1ukKv/vizFZD3kprm8EPDc5v8Se07UgF c+p9rzRrAY5IlbQqCXswMZxsp4iBn9QEshjiedoJNuS8yuL9+rYaFAth1NbC+q0XMD1H Lbk4p6wi6YkMJI23sr6WmvEN/D6anU8XsAFj6kDvQTV1jbTh1swqIL9p96LjArh2HG0b nOpg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=T6w0s4UD; spf=pass (google.com: domain of jagan@amarulasolutions.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jagan@amarulasolutions.com Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id l190sor9677272pfd.84.2022.02.02.08.04.25 for <linux-amarula@amarulasolutions.com> (Google Transport Security); Wed, 02 Feb 2022 08:04:25 -0800 (PST) Received-SPF: pass (google.com: domain of jagan@amarulasolutions.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a63:7103:: with SMTP id m3mr24610194pgc.501.1643817865392; Wed, 02 Feb 2022 08:04:25 -0800 (PST) Received: from localhost.localdomain ([2405:201:c00a:a0a9:748c:1a4e:b1bf:e19f]) by smtp.gmail.com with ESMTPSA id z7sm26489344pfe.49.2022.02.02.08.04.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 02 Feb 2022 08:04:24 -0800 (PST) From: Jagan Teki <jagan@amarulasolutions.com> To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>, Laurent Pinchart <Laurent.pinchart@ideasonboard.com>, Linus Walleij <linus.walleij@linaro.org>, Andrzej Hajda <andrzej.hajda@intel.com>, Marek Szyprowski <m.szyprowski@samsung.com> Cc: dri-devel@lists.freedesktop.or, linux-amarula@amarulasolutions.com, Jagan Teki <jagan@amarulasolutions.com> Subject: [PATCH v4] drm: of: Lookup if child node has panel or bridge Date: Wed, 2 Feb 2022 21:34:14 +0530 Message-Id: <20220202160414.16493-1-jagan@amarulasolutions.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-Original-Sender: jagan@amarulasolutions.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=T6w0s4UD; spf=pass (google.com: domain of jagan@amarulasolutions.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jagan@amarulasolutions.com Content-Type: text/plain; charset="UTF-8" Precedence: list Mailing-list: list linux-amarula@amarulasolutions.com; contact linux-amarula+owners@amarulasolutions.com List-ID: <linux-amarula.amarulasolutions.com> X-Spam-Checked-In-Group: linux-amarula@amarulasolutions.com X-Google-Group-Id: 476853432473 List-Post: <https://groups.google.com/a/amarulasolutions.com/group/linux-amarula/post>, <mailto:linux-amarula@amarulasolutions.com> List-Help: <https://support.google.com/a/amarulasolutions.com/bin/topic.py?topic=25838>, <mailto:linux-amarula+help@amarulasolutions.com> List-Archive: <https://groups.google.com/a/amarulasolutions.com/group/linux-amarula/> List-Unsubscribe: <mailto:googlegroups-manage+476853432473+unsubscribe@googlegroups.com>, <https://groups.google.com/a/amarulasolutions.com/group/linux-amarula/subscribe> |
| Series |
[v4] drm: of: Lookup if child node has panel or bridge
|
|
Commit Message
Jagan Teki
Feb. 2, 2022, 4:04 p.m. UTC
Devices can also be child nodes when we also control that device
through the upstream device (ie, MIPI-DCS for a MIPI-DSI device).
drm_of_find_panel_or_bridge can lookup panel or bridge for a given
device has port and endpoint and it fails to lookup if the device
has a child nodes.
This patch add support to lookup for a child node of the given parent
that isn't either port or ports.
Example OF graph representation of DSI host, which has port but
not has ports and has child panel node.
dsi {
compatible = "allwinner,sun6i-a31-mipi-dsi";
#address-cells = <1>;
#size-cells = <0>;
port {
dsi_in_tcon0: endpoint {
remote-endpoint = <tcon0_out_dsi>;
};
panel@0 {
reg = <0>;
};
};
Example OF graph representation of DSI host, which has ports but
not has port and has child panel node.
dsi {
compatible = "samsung,exynos5433-mipi-dsi";
#address-cells = <1>;
#size-cells = <0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
dsi_to_mic: endpoint {
remote-endpoint = <&mic_to_dsi>;
};
};
};
panel@0 {
reg = <0>;
};
};
Example OF graph representation of DSI host, which has neither a port
nor a ports but has child panel node.
dsi0 {
compatible = "ste,mcde-dsi";
#address-cells = <1>;
#size-cells = <0>;
panel@0 {
reg = <0>;
};
};
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v4:
- update comments and commit message
Changes for v3:
- updated based on other usecase where 'ports' used along with child
Changes for v2:
- drop of helper
https://patchwork.kernel.org/project/dri-devel/cover/20211207054747.461029-1-jagan@amarulasolutions.com/
- support 'port' alone OF graph
- updated comments
- added simple code
drivers/gpu/drm/drm_of.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
Comments
On Wed, Feb 2, 2022 at 9:34 PM Jagan Teki <jagan@amarulasolutions.com> wrote: > > Devices can also be child nodes when we also control that device > through the upstream device (ie, MIPI-DCS for a MIPI-DSI device). > > drm_of_find_panel_or_bridge can lookup panel or bridge for a given > device has port and endpoint and it fails to lookup if the device > has a child nodes. > > This patch add support to lookup for a child node of the given parent > that isn't either port or ports. > > Example OF graph representation of DSI host, which has port but > not has ports and has child panel node. > > dsi { > compatible = "allwinner,sun6i-a31-mipi-dsi"; > #address-cells = <1>; > #size-cells = <0>; > > port { > dsi_in_tcon0: endpoint { > remote-endpoint = <tcon0_out_dsi>; > }; > > panel@0 { > reg = <0>; > }; > }; > > Example OF graph representation of DSI host, which has ports but > not has port and has child panel node. > > dsi { > compatible = "samsung,exynos5433-mipi-dsi"; > #address-cells = <1>; > #size-cells = <0>; > > ports { > #address-cells = <1>; > #size-cells = <0>; > > port@0 { > reg = <0>; > > dsi_to_mic: endpoint { > remote-endpoint = <&mic_to_dsi>; > }; > }; > }; > > panel@0 { > reg = <0>; > }; > }; > > Example OF graph representation of DSI host, which has neither a port > nor a ports but has child panel node. > > dsi0 { > compatible = "ste,mcde-dsi"; > #address-cells = <1>; > #size-cells = <0>; > > panel@0 { > reg = <0>; > }; > }; > > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > --- > Changes for v4: > - update comments and commit message > Changes for v3: > - updated based on other usecase where 'ports' used along with child > Changes for v2: > - drop of helper > https://patchwork.kernel.org/project/dri-devel/cover/20211207054747.461029-1-jagan@amarulasolutions.com/ > - support 'port' alone OF graph > - updated comments > - added simple code > > drivers/gpu/drm/drm_of.c | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c > index 59d368ea006b..9d90cd75c457 100644 > --- a/drivers/gpu/drm/drm_of.c > +++ b/drivers/gpu/drm/drm_of.c > @@ -249,6 +249,21 @@ int drm_of_find_panel_or_bridge(const struct device_node *np, > if (panel) > *panel = 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; > + } > + > /* > * 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, > @@ -259,6 +274,8 @@ int drm_of_find_panel_or_bridge(const struct device_node *np, > return -ENODEV; > > remote = of_graph_get_remote_node(np, port, endpoint); > + > +of_find_panel_or_bridge: > if (!remote) > return -ENODEV; > > -- > 2.25.1 > Any further comments on this? Thanks, Jagan.
On Wed, Feb 2, 2022 at 5:04 PM Jagan Teki <jagan@amarulasolutions.com> wrote: > Devices can also be child nodes when we also control that device > through the upstream device (ie, MIPI-DCS for a MIPI-DSI device). > > drm_of_find_panel_or_bridge can lookup panel or bridge for a given > device has port and endpoint and it fails to lookup if the device > has a child nodes. > > This patch add support to lookup for a child node of the given parent > that isn't either port or ports. > > Example OF graph representation of DSI host, which has port but > not has ports and has child panel node. > > dsi { > compatible = "allwinner,sun6i-a31-mipi-dsi"; > #address-cells = <1>; > #size-cells = <0>; > > port { > dsi_in_tcon0: endpoint { > remote-endpoint = <tcon0_out_dsi>; > }; > > panel@0 { > reg = <0>; > }; > }; > > Example OF graph representation of DSI host, which has ports but > not has port and has child panel node. > > dsi { > compatible = "samsung,exynos5433-mipi-dsi"; > #address-cells = <1>; > #size-cells = <0>; > > ports { > #address-cells = <1>; > #size-cells = <0>; > > port@0 { > reg = <0>; > > dsi_to_mic: endpoint { > remote-endpoint = <&mic_to_dsi>; > }; > }; > }; > > panel@0 { > reg = <0>; > }; > }; > > Example OF graph representation of DSI host, which has neither a port > nor a ports but has child panel node. > > dsi0 { > compatible = "ste,mcde-dsi"; > #address-cells = <1>; > #size-cells = <0>; > > panel@0 { > reg = <0>; > }; > }; > > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > --- > Changes for v4: > - update comments and commit message Looks good to me. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij
On Tue, Feb 22, 2022 at 04:32:44PM +0100, Linus Walleij wrote: > On Wed, Feb 2, 2022 at 5:04 PM Jagan Teki <jagan@amarulasolutions.com> wrote: > > > Devices can also be child nodes when we also control that device > > through the upstream device (ie, MIPI-DCS for a MIPI-DSI device). > > > > drm_of_find_panel_or_bridge can lookup panel or bridge for a given > > device has port and endpoint and it fails to lookup if the device > > has a child nodes. > > > > This patch add support to lookup for a child node of the given parent > > that isn't either port or ports. > > > > Example OF graph representation of DSI host, which has port but > > not has ports and has child panel node. > > > > dsi { > > compatible = "allwinner,sun6i-a31-mipi-dsi"; > > #address-cells = <1>; > > #size-cells = <0>; > > > > port { > > dsi_in_tcon0: endpoint { > > remote-endpoint = <tcon0_out_dsi>; > > }; > > > > panel@0 { > > reg = <0>; > > }; > > }; > > > > Example OF graph representation of DSI host, which has ports but > > not has port and has child panel node. > > > > dsi { > > compatible = "samsung,exynos5433-mipi-dsi"; > > #address-cells = <1>; > > #size-cells = <0>; > > > > ports { > > #address-cells = <1>; > > #size-cells = <0>; > > > > port@0 { > > reg = <0>; > > > > dsi_to_mic: endpoint { > > remote-endpoint = <&mic_to_dsi>; > > }; > > }; > > }; > > > > panel@0 { > > reg = <0>; > > }; > > }; > > > > Example OF graph representation of DSI host, which has neither a port > > nor a ports but has child panel node. > > > > dsi0 { > > compatible = "ste,mcde-dsi"; > > #address-cells = <1>; > > #size-cells = <0>; > > > > panel@0 { > > reg = <0>; > > }; > > }; > > > > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > > --- > > Changes for v4: > > - update comments and commit message > > Looks good to me. > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Applied, thanks Maxime
Hi Jagan, On Wed 02 Feb 22, 21:34, Jagan Teki wrote: > Devices can also be child nodes when we also control that device > through the upstream device (ie, MIPI-DCS for a MIPI-DSI device). > > drm_of_find_panel_or_bridge can lookup panel or bridge for a given > device has port and endpoint and it fails to lookup if the device > has a child nodes. This patch breaks the logicvc drm driver that I'm currently developping. The symptom is that drm_of_find_panel_or_bridge now always returns -EPROBE_DEFER even after the panel has probed and is running well. It seems that the function can no longer find the panel. I haven't figured out the details, but reverting your patch makes it work again. I suspect other drivers might be affected as well, so it would probably be a good idea to revert the patch until the root cause is clearly understood and the patch can be adapted accordingly. Here is what the device-tree looks like: / { panel: panel-lvds { compatible = "panel-lvds"; [...] port { #address-cells = <1>; #size-cells = <0>; panel_input: endpoint@0 { reg = <0>; remote-endpoint = <&logicvc_output>; }; }; }; }; &amba { logicvc: logicvc@43c00000 { compatible = "xylon,logicvc-3.02.a", "syscon", "simple-mfd"; reg = <0x43c00000 0x6000>; #address-cells = <1>; #size-cells = <1>; [...] logicvc_display: display-engine@0 { compatible = "xylon,logicvc-4.01.a-display"; [...] port { #address-cells = <1>; #size-ce/lls = <0>; logicvc_output: endpoint@0 { reg = <0>; remote-endpoint = <&panel_input>; }; }; }; }; }; Cheers, Paul > This patch add support to lookup for a child node of the given parent > that isn't either port or ports. > > Example OF graph representation of DSI host, which has port but > not has ports and has child panel node. > > dsi { > compatible = "allwinner,sun6i-a31-mipi-dsi"; > #address-cells = <1>; > #size-cells = <0>; > > port { > dsi_in_tcon0: endpoint { > remote-endpoint = <tcon0_out_dsi>; > }; > > panel@0 { > reg = <0>; > }; > }; > > Example OF graph representation of DSI host, which has ports but > not has port and has child panel node. > > dsi { > compatible = "samsung,exynos5433-mipi-dsi"; > #address-cells = <1>; > #size-cells = <0>; > > ports { > #address-cells = <1>; > #size-cells = <0>; > > port@0 { > reg = <0>; > > dsi_to_mic: endpoint { > remote-endpoint = <&mic_to_dsi>; > }; > }; > }; > > panel@0 { > reg = <0>; > }; > }; > > Example OF graph representation of DSI host, which has neither a port > nor a ports but has child panel node. > > dsi0 { > compatible = "ste,mcde-dsi"; > #address-cells = <1>; > #size-cells = <0>; > > panel@0 { > reg = <0>; > }; > }; > > Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> > Reviewed-by: Linus Walleij <linus.walleij@linaro.org> > --- > Changes for v4: > - update comments and commit message > Changes for v3: > - updated based on other usecase where 'ports' used along with child > Changes for v2: > - drop of helper > https://patchwork.kernel.org/project/dri-devel/cover/20211207054747.461029-1-jagan@amarulasolutions.com/ > - support 'port' alone OF graph > - updated comments > - added simple code > > drivers/gpu/drm/drm_of.c | 17 +++++++++++++++++ > 1 file changed, 17 insertions(+) > > diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c > index 59d368ea006b..9d90cd75c457 100644 > --- a/drivers/gpu/drm/drm_of.c > +++ b/drivers/gpu/drm/drm_of.c > @@ -249,6 +249,21 @@ int drm_of_find_panel_or_bridge(const struct device_node *np, > if (panel) > *panel = 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; > + } > + > /* > * 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, > @@ -259,6 +274,8 @@ int drm_of_find_panel_or_bridge(const struct device_node *np, > return -ENODEV; > > remote = of_graph_get_remote_node(np, port, endpoint); > + > +of_find_panel_or_bridge: > if (!remote) > return -ENODEV; >
Hi Paul, On Thu, Mar 03, 2022 at 09:26:30PM +0100, Paul Kocialkowski wrote: > On Wed 02 Feb 22, 21:34, Jagan Teki wrote: > > Devices can also be child nodes when we also control that device > > through the upstream device (ie, MIPI-DCS for a MIPI-DSI device). > > > > drm_of_find_panel_or_bridge can lookup panel or bridge for a given > > device has port and endpoint and it fails to lookup if the device > > has a child nodes. > > This patch breaks the logicvc drm driver that I'm currently developping. > The symptom is that drm_of_find_panel_or_bridge now always returns > -EPROBE_DEFER even after the panel has probed and is running well. > It seems that the function can no longer find the panel. > > I haven't figured out the details, but reverting your patch makes > it work again. I suspect other drivers might be affected as well, so > it would probably be a good idea to revert the patch until the root > cause is clearly understood and the patch can be adapted accordingly. > > Here is what the device-tree looks like: > > / { > panel: panel-lvds { > compatible = "panel-lvds"; > > [...] > > port { > #address-cells = <1>; > #size-cells = <0>; > > panel_input: endpoint@0 { > reg = <0>; > remote-endpoint = <&logicvc_output>; > }; > }; > }; > }; > > &amba { > logicvc: logicvc@43c00000 { > compatible = "xylon,logicvc-3.02.a", "syscon", "simple-mfd"; > reg = <0x43c00000 0x6000>; > > #address-cells = <1>; > #size-cells = <1>; > > [...] > > logicvc_display: display-engine@0 { > compatible = "xylon,logicvc-4.01.a-display"; > > [...] I think the issue lies in what you left out here: you have another node aside from the port one, called layers. I *think* the issue is that the code will now pick up the layers node, and try to use it as a panel, which will never probe. I've had a look at all the other bindings though, it seems like this driver is the only one that can be affected: the anx7625 seems to be the only other driver that has a child node that isn't either a port or a panel (aux-bus) but it doesn't use drm_of_find_panel_or_bridge either. Maxime
Hi Maxime, On Fri 04 Mar 22, 09:54, Maxime Ripard wrote: > Hi Paul, > > On Thu, Mar 03, 2022 at 09:26:30PM +0100, Paul Kocialkowski wrote: > > On Wed 02 Feb 22, 21:34, Jagan Teki wrote: > > > Devices can also be child nodes when we also control that device > > > through the upstream device (ie, MIPI-DCS for a MIPI-DSI device). > > > > > > drm_of_find_panel_or_bridge can lookup panel or bridge for a given > > > device has port and endpoint and it fails to lookup if the device > > > has a child nodes. > > > > This patch breaks the logicvc drm driver that I'm currently developping. > > The symptom is that drm_of_find_panel_or_bridge now always returns > > -EPROBE_DEFER even after the panel has probed and is running well. > > It seems that the function can no longer find the panel. > > > > I haven't figured out the details, but reverting your patch makes > > it work again. I suspect other drivers might be affected as well, so > > it would probably be a good idea to revert the patch until the root > > cause is clearly understood and the patch can be adapted accordingly. > > > > Here is what the device-tree looks like: > > > > / { > > panel: panel-lvds { > > compatible = "panel-lvds"; > > > > [...] > > > > port { > > #address-cells = <1>; > > #size-cells = <0>; > > > > panel_input: endpoint@0 { > > reg = <0>; > > remote-endpoint = <&logicvc_output>; > > }; > > }; > > }; > > }; > > > > &amba { > > logicvc: logicvc@43c00000 { > > compatible = "xylon,logicvc-3.02.a", "syscon", "simple-mfd"; > > reg = <0x43c00000 0x6000>; > > > > #address-cells = <1>; > > #size-cells = <1>; > > > > [...] > > > > logicvc_display: display-engine@0 { > > compatible = "xylon,logicvc-4.01.a-display"; > > > > [...] > > I think the issue lies in what you left out here: you have another node > aside from the port one, called layers. I *think* the issue is that the > code will now pick up the layers node, and try to use it as a panel, > which will never probe. > > I've had a look at all the other bindings though, it seems like this > driver is the only one that can be affected: the anx7625 seems to be the > only other driver that has a child node that isn't either a port or a > panel (aux-bus) but it doesn't use drm_of_find_panel_or_bridge either. Thanks a lot for looking into this so quickly! After some testing it clearly appears that you're right and the layers node is the one conflicting with the patch. Removing it brings the behavior back to normal. I'll try to dig-in a bit more to understand why this is happening since it's really not obvious when just looking at the patch. Cheers, Paul
On Fri 04 Mar 22, 12:00, Paul Kocialkowski wrote: > Hi Maxime, > > On Fri 04 Mar 22, 09:54, Maxime Ripard wrote: > > Hi Paul, > > > > On Thu, Mar 03, 2022 at 09:26:30PM +0100, Paul Kocialkowski wrote: > > > On Wed 02 Feb 22, 21:34, Jagan Teki wrote: > > > > Devices can also be child nodes when we also control that device > > > > through the upstream device (ie, MIPI-DCS for a MIPI-DSI device). > > > > > > > > drm_of_find_panel_or_bridge can lookup panel or bridge for a given > > > > device has port and endpoint and it fails to lookup if the device > > > > has a child nodes. > > > > > > This patch breaks the logicvc drm driver that I'm currently developping. > > > The symptom is that drm_of_find_panel_or_bridge now always returns > > > -EPROBE_DEFER even after the panel has probed and is running well. > > > It seems that the function can no longer find the panel. > > > > > > I haven't figured out the details, but reverting your patch makes > > > it work again. I suspect other drivers might be affected as well, so > > > it would probably be a good idea to revert the patch until the root > > > cause is clearly understood and the patch can be adapted accordingly. > > > > > > Here is what the device-tree looks like: > > > > > > / { > > > panel: panel-lvds { > > > compatible = "panel-lvds"; > > > > > > [...] > > > > > > port { > > > #address-cells = <1>; > > > #size-cells = <0>; > > > > > > panel_input: endpoint@0 { > > > reg = <0>; > > > remote-endpoint = <&logicvc_output>; > > > }; > > > }; > > > }; > > > }; > > > > > > &amba { > > > logicvc: logicvc@43c00000 { > > > compatible = "xylon,logicvc-3.02.a", "syscon", "simple-mfd"; > > > reg = <0x43c00000 0x6000>; > > > > > > #address-cells = <1>; > > > #size-cells = <1>; > > > > > > [...] > > > > > > logicvc_display: display-engine@0 { > > > compatible = "xylon,logicvc-4.01.a-display"; > > > > > > [...] > > > > I think the issue lies in what you left out here: you have another node > > aside from the port one, called layers. I *think* the issue is that the > > code will now pick up the layers node, and try to use it as a panel, > > which will never probe. > > > > I've had a look at all the other bindings though, it seems like this > > driver is the only one that can be affected: the anx7625 seems to be the > > only other driver that has a child node that isn't either a port or a > > panel (aux-bus) but it doesn't use drm_of_find_panel_or_bridge either. > > Thanks a lot for looking into this so quickly! > > After some testing it clearly appears that you're right and the layers > node is the one conflicting with the patch. Removing it brings the > behavior back to normal. I'll try to dig-in a bit more to understand > why this is happening since it's really not obvious when just looking > at the patch. Ah wait I do understand it actually. The patch will take the *first* node that doesn't have ports/port in it and use that as remote instead of of_graph_get_remote_node. So maybe the fix would be to first look via of_graph_get_remote_node and if nothing is returned then it should try to use the first node as remote. tl;dr just inverting the order of the logic. Do you think that would work? Cheers, Paul
On Fri, Mar 04, 2022 at 12:05:14PM +0100, Paul Kocialkowski wrote: > On Fri 04 Mar 22, 12:00, Paul Kocialkowski wrote: > > Hi Maxime, > > > > On Fri 04 Mar 22, 09:54, Maxime Ripard wrote: > > > Hi Paul, > > > > > > On Thu, Mar 03, 2022 at 09:26:30PM +0100, Paul Kocialkowski wrote: > > > > On Wed 02 Feb 22, 21:34, Jagan Teki wrote: > > > > > Devices can also be child nodes when we also control that device > > > > > through the upstream device (ie, MIPI-DCS for a MIPI-DSI device). > > > > > > > > > > drm_of_find_panel_or_bridge can lookup panel or bridge for a given > > > > > device has port and endpoint and it fails to lookup if the device > > > > > has a child nodes. > > > > > > > > This patch breaks the logicvc drm driver that I'm currently developping. > > > > The symptom is that drm_of_find_panel_or_bridge now always returns > > > > -EPROBE_DEFER even after the panel has probed and is running well. > > > > It seems that the function can no longer find the panel. > > > > > > > > I haven't figured out the details, but reverting your patch makes > > > > it work again. I suspect other drivers might be affected as well, so > > > > it would probably be a good idea to revert the patch until the root > > > > cause is clearly understood and the patch can be adapted accordingly. > > > > > > > > Here is what the device-tree looks like: > > > > > > > > / { > > > > panel: panel-lvds { > > > > compatible = "panel-lvds"; > > > > > > > > [...] > > > > > > > > port { > > > > #address-cells = <1>; > > > > #size-cells = <0>; > > > > > > > > panel_input: endpoint@0 { > > > > reg = <0>; > > > > remote-endpoint = <&logicvc_output>; > > > > }; > > > > }; > > > > }; > > > > }; > > > > > > > > &amba { > > > > logicvc: logicvc@43c00000 { > > > > compatible = "xylon,logicvc-3.02.a", "syscon", "simple-mfd"; > > > > reg = <0x43c00000 0x6000>; > > > > > > > > #address-cells = <1>; > > > > #size-cells = <1>; > > > > > > > > [...] > > > > > > > > logicvc_display: display-engine@0 { > > > > compatible = "xylon,logicvc-4.01.a-display"; > > > > > > > > [...] > > > > > > I think the issue lies in what you left out here: you have another node > > > aside from the port one, called layers. I *think* the issue is that the > > > code will now pick up the layers node, and try to use it as a panel, > > > which will never probe. > > > > > > I've had a look at all the other bindings though, it seems like this > > > driver is the only one that can be affected: the anx7625 seems to be the > > > only other driver that has a child node that isn't either a port or a > > > panel (aux-bus) but it doesn't use drm_of_find_panel_or_bridge either. > > > > Thanks a lot for looking into this so quickly! > > > > After some testing it clearly appears that you're right and the layers > > node is the one conflicting with the patch. Removing it brings the > > behavior back to normal. I'll try to dig-in a bit more to understand > > why this is happening since it's really not obvious when just looking > > at the patch. > > Ah wait I do understand it actually. The patch will take the *first* node > that doesn't have ports/port in it and use that as remote instead of > of_graph_get_remote_node. > > So maybe the fix would be to first look via of_graph_get_remote_node and > if nothing is returned then it should try to use the first node as remote. > tl;dr just inverting the order of the logic. > > Do you think that would work? We can have multiple strategies here. The one you have in mind does work indeed, but relying on the node order is still fairly fragile. I think it would work fine then if: - We first lookup any endpoint, and see if we have a panel or bridge. If so, we return it. - Then, we look at any available child node, and see if we have a panel or bridge attached. If so, we return it. - we return -EPROBE_DEFER That way, even if we have something like: node { totally-not-a-panel { } panel { } } It would work fine, without relying on the node name (well, except for port(s)?) What do you think? Maxime
Hi Maxime, On Fri 04 Mar 22, 12:38, Maxime Ripard wrote: > On Fri, Mar 04, 2022 at 12:05:14PM +0100, Paul Kocialkowski wrote: > > On Fri 04 Mar 22, 12:00, Paul Kocialkowski wrote: > > > Hi Maxime, > > > > > > On Fri 04 Mar 22, 09:54, Maxime Ripard wrote: > > > > Hi Paul, > > > > > > > > On Thu, Mar 03, 2022 at 09:26:30PM +0100, Paul Kocialkowski wrote: > > > > > On Wed 02 Feb 22, 21:34, Jagan Teki wrote: > > > > > > Devices can also be child nodes when we also control that device > > > > > > through the upstream device (ie, MIPI-DCS for a MIPI-DSI device). > > > > > > > > > > > > drm_of_find_panel_or_bridge can lookup panel or bridge for a given > > > > > > device has port and endpoint and it fails to lookup if the device > > > > > > has a child nodes. > > > > > > > > > > This patch breaks the logicvc drm driver that I'm currently developping. > > > > > The symptom is that drm_of_find_panel_or_bridge now always returns > > > > > -EPROBE_DEFER even after the panel has probed and is running well. > > > > > It seems that the function can no longer find the panel. > > > > > > > > > > I haven't figured out the details, but reverting your patch makes > > > > > it work again. I suspect other drivers might be affected as well, so > > > > > it would probably be a good idea to revert the patch until the root > > > > > cause is clearly understood and the patch can be adapted accordingly. > > > > > > > > > > Here is what the device-tree looks like: > > > > > > > > > > / { > > > > > panel: panel-lvds { > > > > > compatible = "panel-lvds"; > > > > > > > > > > [...] > > > > > > > > > > port { > > > > > #address-cells = <1>; > > > > > #size-cells = <0>; > > > > > > > > > > panel_input: endpoint@0 { > > > > > reg = <0>; > > > > > remote-endpoint = <&logicvc_output>; > > > > > }; > > > > > }; > > > > > }; > > > > > }; > > > > > > > > > > &amba { > > > > > logicvc: logicvc@43c00000 { > > > > > compatible = "xylon,logicvc-3.02.a", "syscon", "simple-mfd"; > > > > > reg = <0x43c00000 0x6000>; > > > > > > > > > > #address-cells = <1>; > > > > > #size-cells = <1>; > > > > > > > > > > [...] > > > > > > > > > > logicvc_display: display-engine@0 { > > > > > compatible = "xylon,logicvc-4.01.a-display"; > > > > > > > > > > [...] > > > > > > > > I think the issue lies in what you left out here: you have another node > > > > aside from the port one, called layers. I *think* the issue is that the > > > > code will now pick up the layers node, and try to use it as a panel, > > > > which will never probe. > > > > > > > > I've had a look at all the other bindings though, it seems like this > > > > driver is the only one that can be affected: the anx7625 seems to be the > > > > only other driver that has a child node that isn't either a port or a > > > > panel (aux-bus) but it doesn't use drm_of_find_panel_or_bridge either. > > > > > > Thanks a lot for looking into this so quickly! > > > > > > After some testing it clearly appears that you're right and the layers > > > node is the one conflicting with the patch. Removing it brings the > > > behavior back to normal. I'll try to dig-in a bit more to understand > > > why this is happening since it's really not obvious when just looking > > > at the patch. > > > > Ah wait I do understand it actually. The patch will take the *first* node > > that doesn't have ports/port in it and use that as remote instead of > > of_graph_get_remote_node. > > > > So maybe the fix would be to first look via of_graph_get_remote_node and > > if nothing is returned then it should try to use the first node as remote. > > tl;dr just inverting the order of the logic. > > > > Do you think that would work? > > We can have multiple strategies here. The one you have in mind does work > indeed, but relying on the node order is still fairly fragile. > > I think it would work fine then if: > > - We first lookup any endpoint, and see if we have a panel or bridge. > If so, we return it. > > - Then, we look at any available child node, and see if we have a > panel or bridge attached. If so, we return it. > > - we return -EPROBE_DEFER > > That way, even if we have something like: > > node { > totally-not-a-panel { > } > > panel { > } > } > > It would work fine, without relying on the node name (well, except for > port(s)?) > > What do you think? Yes it would definitely be better to try all possible cases, including when one of them fails instead of just selecting one to check and failing if the panel/bridge nodes aren't there. I'll have a try at this and send a fixup patch soon! Cheers, Paul
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c index 59d368ea006b..9d90cd75c457 100644 --- a/drivers/gpu/drm/drm_of.c +++ b/drivers/gpu/drm/drm_of.c @@ -249,6 +249,21 @@ int drm_of_find_panel_or_bridge(const struct device_node *np, if (panel) *panel = 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; + } + /* * 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, @@ -259,6 +274,8 @@ int drm_of_find_panel_or_bridge(const struct device_node *np, return -ENODEV; remote = of_graph_get_remote_node(np, port, endpoint); + +of_find_panel_or_bridge: if (!remote) return -ENODEV;