From: Rob Herring <robh@kernel.org> To: Liviu Dudau <liviu.dudau@arm.com> Cc: David Airlie <airlied@linux.ie>, Daniel Vetter <daniel.vetter@intel.com>, Sean Paul <seanpaul@chromium.org>, dri-devel <dri-devel@lists.freedesktop.org>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Frank Rowand <frowand.list@gmail.com>, Boris Brezillon <boris.brezillon@free-electrons.com>, Archit Taneja <architt@codeaurora.org>, Jingoo Han <jingoohan1@gmail.com>, Inki Dae <inki.dae@samsung.com>, Joonyoung Shim <jy0922.shim@samsung.com>, Seung-Woo Kim <sw0312.kim@samsung.com>, Kyungmin Park <kyungmin.park@samsung.com>, Kukjin Kim <kgene@kernel.org>, Krzysztof Kozlowski <krzk@kernel.org>, Javier Martinez Canillas <javier@osg.samsung.com>, Stefan Agner <stefan@agner.ch>, Alison Wang <alison.wang@freescale.com>, Xinliang Liu <z.liuxinliang@hisilicon.com>, Rongrong Zou <zourongrong@gmail.com>, Xinwei Kong <kong.kongxinwei@hisilicon.com>, Chen Feng <puck.chen@hisilicon.com>, Philipp Zabel <p.zabel@pengutronix.de>, CK Hu <ck.hu@mediatek.com>, Matthias Brugger <matthias.bgg@gmail.com>, Marek Vasut <marex@denx.de>, Mark Yao <mark.yao@rock-chips.com>, Heiko Stuebner <heiko@sntech.de>, Maxime Ripard <maxime.ripard@free-electrons.com>, Chen-Yu Tsai <wens@csie.org>, Mali DP Maintainers <malidp@foss.arm.com>, Neil Armstrong <narmstrong@baylibre.com>, Carlo Caione <carlo@caione.org>, Kevin Hilman <khilman@baylibre.com>, Rob Clark <robdclark@gmail.com>, Jyri Sarha <jsarha@ti.com>, Tomi Valkeinen <tomi.valkeinen@ti.com>, Eric Anholt <eric@anholt.net>, Russell King <rmk+kernel@armlinux.org.uk> Subject: Re: [PATCH 3/5] drm: convert drivers to use of_graph_get_remote_node Date: Mon, 6 Feb 2017 11:42:36 -0600 [thread overview] Message-ID: <CAL_JsqJe5KFNhzc9vLimXzi0cot2HjsgD-Het9M=yeXCgDCXqQ@mail.gmail.com> (raw) In-Reply-To: <20170206172306.GY3140@e110455-lin.cambridge.arm.com> On Mon, Feb 6, 2017 at 11:23 AM, Liviu Dudau <liviu.dudau@arm.com> wrote: > On Mon, Feb 06, 2017 at 11:09:49AM -0600, Rob Herring wrote: >> On Mon, Feb 06, 2017 at 10:29:33AM +0000, Liviu Dudau wrote: >> > On Fri, Feb 03, 2017 at 09:36:33PM -0600, Rob Herring wrote: >> > > Convert drivers to use the new of_graph_get_remote_node() helper >> > > instead of parsing the endpoint node and then getting the remote device >> > > node. Now drivers can just specify the device node and which >> > > port/endpoint and get back the connected remote device node. The details >> > > of the graph binding are nicely abstracted into the core OF graph code. >> > > >> > > This changes some error messages to debug messages (in the graph core). >> > > Graph connections are often "no connects" depending on the particular >> > > board, so we want to avoid spurious messages. Plus the kernel is not a >> > > DT validator. [...] >> > > - /* add the remote encoder port as component */ >> > > - port = of_graph_get_remote_port_parent(ep); >> > > - of_node_put(ep); >> > > - if (!port || !of_device_is_available(port)) { >> > > - of_node_put(port); >> > > - return -EAGAIN; >> > >> > The HDLCD change looks reasonable except for this -EAGAIN business. I'll have to >> > test your changes on my setup to see how this affects having the encoder as a module. >> >> What are you expecting to happen with -EAGAIN? This one was a bit of an >> oddball. > > When both the HDLCD and the TDA998x drivers are compiled as modules, the order in which > they are inserted can be somewhat random (due to testing). It is at that time when you > want the probe of HDLCD to be retried on the insmod-ing of the tda998x.ko rather than > fail entirely. > >> >> This condition would only change if you had an overlay. That's a use >> case that needs to be handled in a common way ('cause I don't want to >> clean-up every driver doing overlays in their own way latter). Just >> having "status" changing at runtime would have all sorts of implications >> in the kernel. > > Hmm, not sure what you mean here with overlays. Are you thinking that the > remote port is initially disabled and then re-enabled by an overlay? That is > not the only way of_device_is_available() can fail, see above regarding modules. Russell pretty much answered most of this, but specifically for of_device_is_available, the only way of_device_is_available() can change is a DT change with "status" changing. The only way of_graph_get_remote_port_parent changes is also from a DT change. Rob
WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> To: Liviu Dudau <liviu.dudau-5wv7dgnIgG8@public.gmane.org> Cc: David Airlie <airlied-cv59FeDIM0c@public.gmane.org>, Daniel Vetter <daniel.vetter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>, Sean Paul <seanpaul-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>, dri-devel <dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org>, "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Boris Brezillon <boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>, Archit Taneja <architt-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>, Jingoo Han <jingoohan1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Inki Dae <inki.dae-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>, Joonyoung Shim <jy0922.shim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>, Seung-Woo Kim <sw0312.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>, Kyungmin Park <kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>, Kukjin Kim <kgene-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Krzysztof Kozlowski <krzk-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>, Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> Subject: Re: [PATCH 3/5] drm: convert drivers to use of_graph_get_remote_node Date: Mon, 6 Feb 2017 11:42:36 -0600 [thread overview] Message-ID: <CAL_JsqJe5KFNhzc9vLimXzi0cot2HjsgD-Het9M=yeXCgDCXqQ@mail.gmail.com> (raw) In-Reply-To: <20170206172306.GY3140-A/Nd4k6kWRHZROr8t4l/smS4ubULX0JqMm0uRHvK7Nw@public.gmane.org> On Mon, Feb 6, 2017 at 11:23 AM, Liviu Dudau <liviu.dudau-5wv7dgnIgG8@public.gmane.org> wrote: > On Mon, Feb 06, 2017 at 11:09:49AM -0600, Rob Herring wrote: >> On Mon, Feb 06, 2017 at 10:29:33AM +0000, Liviu Dudau wrote: >> > On Fri, Feb 03, 2017 at 09:36:33PM -0600, Rob Herring wrote: >> > > Convert drivers to use the new of_graph_get_remote_node() helper >> > > instead of parsing the endpoint node and then getting the remote device >> > > node. Now drivers can just specify the device node and which >> > > port/endpoint and get back the connected remote device node. The details >> > > of the graph binding are nicely abstracted into the core OF graph code. >> > > >> > > This changes some error messages to debug messages (in the graph core). >> > > Graph connections are often "no connects" depending on the particular >> > > board, so we want to avoid spurious messages. Plus the kernel is not a >> > > DT validator. [...] >> > > - /* add the remote encoder port as component */ >> > > - port = of_graph_get_remote_port_parent(ep); >> > > - of_node_put(ep); >> > > - if (!port || !of_device_is_available(port)) { >> > > - of_node_put(port); >> > > - return -EAGAIN; >> > >> > The HDLCD change looks reasonable except for this -EAGAIN business. I'll have to >> > test your changes on my setup to see how this affects having the encoder as a module. >> >> What are you expecting to happen with -EAGAIN? This one was a bit of an >> oddball. > > When both the HDLCD and the TDA998x drivers are compiled as modules, the order in which > they are inserted can be somewhat random (due to testing). It is at that time when you > want the probe of HDLCD to be retried on the insmod-ing of the tda998x.ko rather than > fail entirely. > >> >> This condition would only change if you had an overlay. That's a use >> case that needs to be handled in a common way ('cause I don't want to >> clean-up every driver doing overlays in their own way latter). Just >> having "status" changing at runtime would have all sorts of implications >> in the kernel. > > Hmm, not sure what you mean here with overlays. Are you thinking that the > remote port is initially disabled and then re-enabled by an overlay? That is > not the only way of_device_is_available() can fail, see above regarding modules. Russell pretty much answered most of this, but specifically for of_device_is_available, the only way of_device_is_available() can change is a DT change with "status" changing. The only way of_graph_get_remote_port_parent changes is also from a DT change. Rob -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-02-06 17:43 UTC|newest] Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-02-04 3:36 [PATCH 0/5] DRM OF graph clean-up Rob Herring 2017-02-04 3:36 ` Rob Herring 2017-02-04 3:36 ` [PATCH 1/5] of: introduce of_graph_get_remote_node Rob Herring 2017-02-04 3:36 ` Rob Herring 2017-02-04 16:10 ` Vladimir Zapolskiy 2017-02-04 16:10 ` Vladimir Zapolskiy 2017-02-06 8:50 ` Daniel Vetter 2017-02-06 8:50 ` Daniel Vetter 2017-02-06 13:41 ` Rob Herring 2017-02-06 13:41 ` Rob Herring 2017-02-06 10:32 ` Philipp Zabel 2017-02-06 10:32 ` Philipp Zabel 2017-02-06 13:54 ` Rob Herring 2017-02-06 13:54 ` Rob Herring 2017-02-06 14:03 ` Philipp Zabel 2017-02-06 14:03 ` Philipp Zabel 2017-02-04 3:36 ` [PATCH 2/5] drm: of: introduce drm_of_find_panel_or_bridge Rob Herring 2017-02-04 3:36 ` Rob Herring 2017-02-06 10:18 ` Liviu Dudau 2017-02-06 10:18 ` Liviu Dudau 2017-02-06 16:20 ` Rob Herring 2017-02-06 16:20 ` Rob Herring 2017-02-06 10:42 ` Philipp Zabel 2017-02-06 10:42 ` Philipp Zabel 2017-02-06 16:53 ` Rob Herring 2017-02-06 16:53 ` Rob Herring 2017-02-06 17:45 ` Philipp Zabel 2017-02-06 17:45 ` Philipp Zabel 2017-02-10 19:42 ` Frank Rowand 2017-02-10 19:42 ` Frank Rowand 2017-02-04 3:36 ` [PATCH 3/5] drm: convert drivers to use of_graph_get_remote_node Rob Herring 2017-02-04 3:36 ` Rob Herring 2017-02-06 8:31 ` Jyri Sarha 2017-02-06 8:31 ` Jyri Sarha 2017-02-06 10:17 ` Neil Armstrong 2017-02-06 10:17 ` Neil Armstrong 2017-02-06 10:29 ` Liviu Dudau 2017-02-06 10:29 ` Liviu Dudau 2017-02-06 17:09 ` Rob Herring 2017-02-06 17:09 ` Rob Herring 2017-02-06 17:23 ` Liviu Dudau 2017-02-06 17:23 ` Liviu Dudau 2017-02-06 17:34 ` Russell King - ARM Linux 2017-02-06 17:34 ` Russell King - ARM Linux 2017-02-06 17:55 ` Liviu Dudau 2017-02-06 17:55 ` Liviu Dudau 2017-02-06 18:09 ` Russell King - ARM Linux 2017-02-06 18:09 ` Russell King - ARM Linux 2017-02-06 17:42 ` Rob Herring [this message] 2017-02-06 17:42 ` Rob Herring 2017-02-06 10:52 ` Philipp Zabel 2017-02-06 10:52 ` Philipp Zabel 2017-02-06 13:40 ` Rob Herring 2017-02-06 13:40 ` Rob Herring 2017-02-08 11:57 ` Liviu Dudau 2017-02-08 11:57 ` Liviu Dudau 2017-02-08 20:44 ` Eric Anholt 2017-02-08 20:44 ` Eric Anholt 2017-02-04 3:36 ` [PATCH 4/5] drm: convert drivers to use drm_of_find_panel_or_bridge Rob Herring 2017-02-04 3:36 ` Rob Herring 2017-02-04 20:26 ` Fabio Estevam 2017-02-04 20:26 ` Fabio Estevam 2017-02-05 22:25 ` Rob Herring 2017-02-05 22:25 ` Rob Herring 2017-02-06 0:01 ` Fabio Estevam 2017-02-06 0:01 ` Fabio Estevam 2017-02-06 1:22 ` Fabio Estevam 2017-02-06 1:22 ` Fabio Estevam 2017-02-06 10:03 ` Maxime Ripard 2017-02-06 10:03 ` Maxime Ripard 2017-02-06 17:32 ` Rob Herring 2017-02-06 17:32 ` Rob Herring 2017-02-08 7:46 ` Maxime Ripard 2017-02-08 7:46 ` Maxime Ripard 2017-02-06 11:07 ` Philipp Zabel 2017-02-06 11:07 ` Philipp Zabel 2017-02-04 3:36 ` [PATCH 5/5] drm: omap: use common OF graph helpers Rob Herring 2017-02-04 3:36 ` Rob Herring 2017-02-04 10:47 ` [PATCH 0/5] DRM OF graph clean-up Russell King - ARM Linux 2017-02-04 10:47 ` Russell King - ARM Linux
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAL_JsqJe5KFNhzc9vLimXzi0cot2HjsgD-Het9M=yeXCgDCXqQ@mail.gmail.com' \ --to=robh@kernel.org \ --cc=airlied@linux.ie \ --cc=alison.wang@freescale.com \ --cc=architt@codeaurora.org \ --cc=boris.brezillon@free-electrons.com \ --cc=carlo@caione.org \ --cc=ck.hu@mediatek.com \ --cc=daniel.vetter@intel.com \ --cc=devicetree@vger.kernel.org \ --cc=dri-devel@lists.freedesktop.org \ --cc=eric@anholt.net \ --cc=frowand.list@gmail.com \ --cc=heiko@sntech.de \ --cc=inki.dae@samsung.com \ --cc=javier@osg.samsung.com \ --cc=jingoohan1@gmail.com \ --cc=jsarha@ti.com \ --cc=jy0922.shim@samsung.com \ --cc=kgene@kernel.org \ --cc=khilman@baylibre.com \ --cc=kong.kongxinwei@hisilicon.com \ --cc=krzk@kernel.org \ --cc=kyungmin.park@samsung.com \ --cc=linux-kernel@vger.kernel.org \ --cc=liviu.dudau@arm.com \ --cc=malidp@foss.arm.com \ --cc=marex@denx.de \ --cc=mark.yao@rock-chips.com \ --cc=matthias.bgg@gmail.com \ --cc=maxime.ripard@free-electrons.com \ --cc=narmstrong@baylibre.com \ --cc=p.zabel@pengutronix.de \ --cc=puck.chen@hisilicon.com \ --cc=rmk+kernel@armlinux.org.uk \ --cc=robdclark@gmail.com \ --cc=seanpaul@chromium.org \ --cc=stefan@agner.ch \ --cc=sw0312.kim@samsung.com \ --cc=tomi.valkeinen@ti.com \ --cc=wens@csie.org \ --cc=z.liuxinliang@hisilicon.com \ --cc=zourongrong@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.