[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <531D54E2.8030303@ti.com>
Date: Mon, 10 Mar 2014 08:00:02 +0200
From: Tomi Valkeinen <tomi.valkeinen@...com>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Philipp Zabel <philipp.zabel@...il.com>
CC: Grant Likely <grant.likely@...aro.org>,
Philipp Zabel <p.zabel@...gutronix.de>,
Russell King - ARM Linux <linux@....linux.org.uk>,
Mauro Carvalho Chehab <m.chehab@...sung.com>,
Rob Herring <robh+dt@...nel.org>,
Sylwester Nawrocki <s.nawrocki@...sung.com>,
Kyungmin Park <kyungmin.park@...sung.com>,
LKML <linux-kernel@...r.kernel.org>,
<linux-media@...r.kernel.org>, <devicetree@...r.kernel.org>,
Guennadi Liakhovetski <g.liakhovetski@....de>
Subject: Re: [PATCH v4 1/3] [media] of: move graph helpers from drivers/media/v4l2-core
to drivers/of
On 08/03/14 17:54, Laurent Pinchart wrote:
>> Sylwester suggested as an alternative, if I understood correctly, to
>> drop the endpoint node and instead keep the port:
>>
>> device-a {
>> implicit_output_ep: port {
>> remote-endpoint = <&explicit_input_ep>;
>> };
>> };
>>
>> device-b {
>> port {
>> explicit_input_ep: endpoint {
>> remote-endpoint = <&implicit_output_ep>;
>> };
>> };
>> };
>>
>> This would have the advantage to reduce verbosity for devices with multiple
>> ports that are only connected via one endport each, and you'd always have
>> the connected ports in the device tree as 'port' nodes.
>
> I like that idea. I would prefer making the 'port' nodes mandatory and the
> 'ports' and 'endpoint' nodes optional. Leaving the 'port' node out slightly
> decreases readability in my opinion, but making the 'endpoint' node optional
> increases it. That's just my point of view though.
I, on the other hand, don't like it =). With that format, the
remote-endpoint doesn't point to an EP, but a port. And you'll have
endpoint's properties in a port node, among the port's properties.
Tomi
Download attachment "signature.asc" of type "application/pgp-signature" (902 bytes)
Powered by blists - more mailing lists