From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Grant Likely <grant.likely@linaro.org>,
Philipp Zabel <p.zabel@pengutronix.de>
Cc: 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>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Kyungmin Park <kyungmin.park@samsung.com>,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
devicetree@vger.kernel.org,
Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
Philipp Zabel <philipp.zabel@gmail.com>
Subject: Re: [PATCH v4 1/3] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/of
Date: Sat, 8 Mar 2014 12:46:05 +0200 [thread overview]
Message-ID: <531AF4ED.5020608@ti.com> (raw)
In-Reply-To: <20140307171804.EF245C40A32@trevor.secretlab.ca>
[-- Attachment #1: Type: text/plain, Size: 2254 bytes --]
On 07/03/14 19:18, Grant Likely wrote:
> From a pattern perspective I have no problem with that.... From an
> individual driver binding perspective that is just dumb! It's fine for
> the ports node to be optional, but an individual driver using the
> binding should be explicit about which it will accept. Please use either
> a flag or a separate wrapper so that the driver can select the
> behaviour.
Why is that? The meaning of the DT data stays the same, regardless of
the existence of the 'ports' node. The driver uses the graph helpers to
parse the port/endpoint data, so individual drivers don't even have to
care about the format used.
As I see it, the graph helpers should allow the drivers to iterate the
ports and the endpoints for a port. These should work the same way, no
matter which abbreviated format is used in the dts.
>> The helper should find the two endpoints in both cases.
>> Tomi suggests an even more compact form for devices with just one port:
>>
>> device {
>> endpoint { ... };
>>
>> some-other-child { ... };
>> };
>
> That's fine. In that case the driver would specifically require the
> endpoint to be that one node.... although the above looks a little weird
The driver can't require that. It's up to the board designer to decide
how many endpoints are used. A driver may say that it has a single input
port. But the number of endpoints for that port is up to the use case.
> to me. I would recommend that if there are other non-port child nodes
> then the ports should still be encapsulated by a ports node. The device
> binding should not be ambiguous about which nodes are ports.
Hmm, ambiguous in what way?
If the dts uses 'ports' node, all the ports and endpoints are inside
that 'ports' node. If there is no 'ports' node, there may be one or more
'port' nodes, which then contain endpoints. If there are no 'port'
nodes, there may be a single 'endpoint' node.
True, there are many "if"s there. But I don't think it's ambiguous. The
reason we have these abbreviations is that the full 'ports' node is not
needed that often, and it is rather verbose. In almost all the use
cases, panels and connectors can use the single endpoint format.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
next prev parent reply other threads:[~2014-03-08 10:46 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-25 14:58 [PATCH v4 0/3] Move device tree graph parsing helpers to drivers/of Philipp Zabel
[not found] ` < 1393428297.3248.92.camel@paszta.hi.pengutronix.de>
[not found] ` <20140307171804. EF245C40A32@trevor.secretlab.ca>
[not found] ` < 1393340304-19005-2-git-send-email-p.zabel@pengutronix.de>
[not found] ` <20140226113729. A9D5AC40A89@trevor.secretlab.ca>
[not found] ` < 20140226113729.A9D5AC40A89@trevor.secretlab.ca>
[not found] ` < 1393340304-19005-4-git-send-email-p.zabel@pengutronix.de>
2014-02-25 14:58 ` [PATCH v4 1/3] [media] of: move graph helpers from drivers/media/v4l2-core " Philipp Zabel
2014-02-26 11:37 ` Grant Likely
2014-02-26 15:24 ` Philipp Zabel
2014-03-07 17:18 ` Grant Likely
2014-03-08 10:46 ` Tomi Valkeinen [this message]
2014-03-08 12:23 ` Grant Likely
2014-03-08 15:50 ` Laurent Pinchart
2014-03-20 22:23 ` Grant Likely
[not found] ` <20140320222347.CAB6DC412EA-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2014-03-20 22:32 ` Laurent Pinchart
2014-03-21 13:37 ` Tomi Valkeinen
2014-03-21 14:10 ` Sylwester Nawrocki
[not found] ` <532C408D.4070002-l0cyMroinI0@public.gmane.org>
2014-03-21 14:13 ` Laurent Pinchart
2014-03-21 14:22 ` Tomi Valkeinen
[not found] ` <532C4B3C.4030406-l0cyMroinI0@public.gmane.org>
2014-03-21 14:30 ` Laurent Pinchart
2014-03-10 6:34 ` Tomi Valkeinen
2014-03-20 22:26 ` Grant Likely
2014-03-08 12:07 ` Philipp Zabel
[not found] ` <CA+gwMcfgKre8S4KHPvTVuAuz672aehGrN1UfFpwKAueTAcrMZQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-03-08 15:54 ` Laurent Pinchart
2014-03-10 6:00 ` Tomi Valkeinen
[not found] ` <531D54E2.8030303-l0cyMroinI0@public.gmane.org>
2014-03-10 13:57 ` Laurent Pinchart
2014-03-10 8:58 ` Andrzej Hajda
[not found] ` <531D7E9F.3090708-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-03-10 9:29 ` Tomi Valkeinen
2014-03-10 11:42 ` Laurent Pinchart
2014-03-11 13:55 ` Andrzej Hajda
2014-03-20 22:33 ` Grant Likely
2014-02-25 14:58 ` [PATCH v4 2/3] [media] of: move common endpoint parsing " Philipp Zabel
2014-02-25 14:58 ` [PATCH v4 3/3] Documentation: of: Document graph bindings Philipp Zabel
2014-02-26 13:14 ` Tomi Valkeinen
2014-02-26 14:57 ` Philipp Zabel
[not found] ` <1393426623.3248.70.camel-+qGW7pzALmz7o/J7KWpOmN53zsg1cpMQ@public.gmane.org>
2014-02-26 14:50 ` Tomi Valkeinen
2014-02-26 15:47 ` Philipp Zabel
[not found] ` <1393429676.3248.110.camel-+qGW7pzALmz7o/J7KWpOmN53zsg1cpMQ@public.gmane.org>
2014-02-27 8:08 ` Tomi Valkeinen
2014-02-27 10:52 ` Philipp Zabel
2014-02-27 10:41 ` Tomi Valkeinen
[not found] ` < 530DFF4C.8080807@ti.com>
[not found] ` <530DFF4C.8080807-l0cyMroinI0@public.gmane.org>
2014-03-07 18:11 ` Grant Likely
2014-03-08 9:35 ` Tomi Valkeinen
2014-03-08 12:25 ` Grant Likely
2014-03-08 15:43 ` Laurent Pinchart
2014-03-10 6:53 ` Tomi Valkeinen
[not found] ` <531D6178.3070906-l0cyMroinI0@public.gmane.org>
2014-03-11 13:47 ` Sylwester Nawrocki
2014-03-07 17:20 ` Grant Likely
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=531AF4ED.5020608@ti.com \
--to=tomi.valkeinen@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=g.liakhovetski@gmx.de \
--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=p.zabel@pengutronix.de \
--cc=philipp.zabel@gmail.com \
--cc=robh+dt@kernel.org \
--cc=s.nawrocki@samsung.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).