From: Philipp Zabel <p.zabel@pengutronix.de>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Grant Likely <grant.likely@linaro.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Rob Herring <robherring2@gmail.com>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Mauro Carvalho Chehab <m.chehab@samsung.com>,
Rob Herring <robh+dt@kernel.org>,
Sylwester Nawrocki <s.nawrocki@samsung.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Philipp Zabel <philipp.zabel@gmail.com>
Subject: Re: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
Date: Tue, 11 Mar 2014 14:44:23 +0100 [thread overview]
Message-ID: <1394545463.3772.24.camel@paszta.hi.pengutronix.de> (raw)
In-Reply-To: <531F0F4F.3070008@ti.com>
Hi,
Am Dienstag, den 11.03.2014, 15:27 +0200 schrieb Tomi Valkeinen:
> On 11/03/14 15:16, Laurent Pinchart wrote:
>
> >> And if I gathered Grant's opinion correctly (correct me if I'm wrong),
> >> he thinks things should be explicit, i.e. the bindings for, say, an
> >> encoder should state that the encoder's output endpoint _must_ contain a
> >> remote-endpoint property, whereas the encoder's input endpoint _must
> >> not_ contain a remote-endpoint property.
> >
> > Actually my understand was that DT links would have the same direction as the
> > data flow. There would be no ambiguity in that case as the direction of the
>
> Ok. At least at some point in the discussion the rule of thumb was to
> have the "master" point at the "slave", which are a bit vague terms, but
> I think both display and camera controllers were given as examples of
> "master".
>
> > data flow is known. What happens for bidirectional data flows still need to be
> > discussed though. And if we want to use the of-graph bindings to describe
> > graphs without a data flow, a decision will need to be taken there too.
>
> Yep. My worry is that if the link direction is defined in the bindings
> for the device, somebody will at some point have a complex board which
> happens to use two devices in such a way, that either neither of them
> point to each other, or both point to each other.
>
> Maybe we can make sure that never happens, but I feel a bit nervous
> about it especially for bi-directional cases. If the link has no clear
> main-dataflow direction, it may be a bit difficult to say which way to link.
>
> With double-linking all those concerns just disappear.
another possibility would be to just leave it open in the generic
bindings:
"Two endpoints are considered linked together if any of them contains a
'remote-endpoint' phandle property that points to the other. If both
contain a 'remote-endpoint' property, both must point at each other."
As long as we make sure that the generic code is able to generate the
undirected graph from this, we could then let more specific bindings
(like video-interfaces.txt) define that the phandle links always should
point in both directions, in data flow direction, north, or outwards
from the 'master'.
regards
Philipp
next prev parent reply other threads:[~2014-03-11 13:44 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-11 11:45 [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of Philipp Zabel
[not found] ` < 20140310145815.17595C405FA@trevor.secretlab.ca>
[not found] ` < 20140320153804.35d5b835@samsung.com>
[not found] ` < CAL_Jsq+U9zU1i+STLHMBjY5BeEP6djYnJVE5X1ix-D2q_zWztQ@mail.gmail.com>
[not found] ` < 20140217181451.7EB7FC4044D@trevor.secretlab.ca>
[not found] ` < 4339286.FzhQ2m6hoA@avalon>
2014-02-11 13:56 ` Rob Herring
2014-02-11 14:52 ` Russell King - ARM Linux
2014-02-11 15:23 ` Laurent Pinchart
2014-02-11 16:36 ` Philipp Zabel
[not found] ` <1392136617.6943.33.camel-/rZezPiN1rtR6QfukMTsflXZhhPuCNm+@public.gmane.org>
2014-02-11 17:22 ` Sylwester Nawrocki
2014-02-11 17:41 ` Mauro Carvalho Chehab
2014-02-11 21:00 ` Guennadi Liakhovetski
2014-02-11 21:46 ` Philipp Zabel
2014-02-11 17:24 ` Laurent Pinchart
2014-02-11 16:30 ` Rob Herring
2014-02-11 15:27 ` Philipp Zabel
2014-02-17 18:14 ` Grant Likely
2014-02-18 7:06 ` Sascha Hauer
2014-02-18 16:26 ` Grant Likely
[not found] ` < 1393263389.3091.82.camel@pizza.hi.pengutronix.de>
[not found] ` <20140226110114. CF2C7C40A89@trevor.secretlab.ca>
[not found] ` <20140218162627.32BA4C40517-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2014-02-24 17:36 ` Philipp Zabel
2014-02-26 11:01 ` Grant Likely
2014-02-26 14:48 ` Philipp Zabel
[not found] ` <1393426129.3248.64.camel-+qGW7pzALmz7o/J7KWpOmN53zsg1cpMQ@public.gmane.org>
2014-02-27 8:36 ` Tomi Valkeinen
2014-03-07 17:06 ` Grant Likely
2014-03-08 10:57 ` Tomi Valkeinen
2014-03-07 17:05 ` Grant Likely
2014-03-08 10:33 ` Tomi Valkeinen
2014-03-08 11:41 ` Grant Likely
2014-03-08 23:25 ` Sylwester Nawrocki
2014-03-10 10:18 ` Tomi Valkeinen
[not found] ` <531D916C.2010903-l0cyMroinI0@public.gmane.org>
2014-03-10 13:52 ` Laurent Pinchart
2014-03-10 14:10 ` Tomi Valkeinen
2014-03-10 14:58 ` Grant Likely
2014-03-10 15:15 ` Laurent Pinchart
2014-03-10 15:40 ` Philipp Zabel
2014-03-11 11:43 ` Laurent Pinchart
2014-03-11 12:59 ` Tomi Valkeinen
[not found] ` <1883687.VdfitvQEN3@samsung.com>
[not found] ` <avalon@samsung.com>
[not found] ` <531F08A8.300-l0cyMroinI0@public.gmane.org>
2014-03-11 13:16 ` Laurent Pinchart
2014-03-11 13:27 ` Tomi Valkeinen
2014-03-11 13:44 ` Philipp Zabel [this message]
2014-03-20 17:23 ` Grant Likely
2014-03-21 10:44 ` Andrzej Hajda
2014-03-21 11:47 ` Grant Likely
2014-03-21 12:16 ` Tomi Valkeinen
[not found] ` <532C2D94.4020705-l0cyMroinI0@public.gmane.org>
2014-03-21 14:33 ` Grant Likely
2014-03-20 17:09 ` Grant Likely
2014-03-11 13:04 ` Andrzej Hajda
[not found] ` <531F09E2.3070407-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-03-20 17:33 ` Grant Likely
2014-03-20 17:01 ` Grant Likely
2014-03-21 12:10 ` Tomi Valkeinen
2014-03-11 15:07 ` Philipp Zabel
[not found] ` <1394550420.3772.29.camel-+qGW7pzALmz7o/J7KWpOmN53zsg1cpMQ@public.gmane.org>
2014-03-11 15:21 ` Laurent Pinchart
2014-03-11 18:52 ` Philipp Zabel
2014-03-20 17:53 ` Grant Likely
2014-03-20 17:36 ` Grant Likely
2014-03-12 10:25 ` Russell King - ARM Linux
2014-03-12 10:47 ` Tomi Valkeinen
[not found] ` <53203B2D.6080201-l0cyMroinI0@public.gmane.org>
2014-03-12 11:21 ` Laurent Pinchart
2014-03-20 17:54 ` Grant Likely
[not found] ` <20140320175432.0559CC4067A-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2014-03-20 18:16 ` Laurent Pinchart
2014-03-20 18:18 ` Russell King - ARM Linux
[not found] ` <20140320181820.GY7528-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2014-03-20 18:50 ` Laurent Pinchart
2014-03-20 19:27 ` Laurent Pinchart
2014-03-20 18:38 ` Mauro Carvalho Chehab
2014-03-20 18:43 ` Russell King - ARM Linux
2014-03-20 18:49 ` Laurent Pinchart
2014-03-21 8:20 ` Tomi Valkeinen
[not found] ` <20140320153804.35d5b835@ samsung.com>
[not found] ` <20140320153804.35d5b835-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-03-20 18:48 ` Grant Likely
[not found] ` <20140320184816.7AB02C4067A-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2014-03-20 18:52 ` Laurent Pinchart
2014-03-20 23:12 ` Grant Likely
[not found] ` <20140320231250.8F0E0C412EA-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2014-03-20 23:26 ` Laurent Pinchart
2014-03-21 8:15 ` Grant Likely
2014-03-21 12:44 ` Laurent Pinchart
2014-03-21 13:26 ` Grant Likely
2014-03-10 14:41 ` Grant Likely
2014-03-08 11:54 ` Russell King - ARM Linux
[not found] ` <20140217181451.7EB7FC4044D-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2014-02-18 10:43 ` Sylwester Nawrocki
2014-02-18 13:41 ` Philipp Zabel
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=1394545463.3772.24.camel@paszta.hi.pengutronix.de \
--to=p.zabel@pengutronix.de \
--cc=devicetree@vger.kernel.org \
--cc=grant.likely@linaro.org \
--cc=kyungmin.park@samsung.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=m.chehab@samsung.com \
--cc=philipp.zabel@gmail.com \
--cc=robh+dt@kernel.org \
--cc=robherring2@gmail.com \
--cc=s.hauer@pengutronix.de \
--cc=s.nawrocki@samsung.com \
--cc=tomi.valkeinen@ti.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).