Re: [PATCH v4 3/3] Documentation: of: Document graph bindings
On 10/03/14 07:53, Tomi Valkeinen wrote: On 08/03/14 14:25, Grant Likely wrote: Sure. If endpoints are logical, then only create the ones actually hooked up. No problem there. But nor do I see any issue with having empty connections if the board author things it makes sense to have them in the dtsi. I don't think they are usually logical, although they probably might be in some cases. The endpoint nodes are supposed to be logical, they just group properties describing a port's configuration. As I see it, a port is a group of pins in a hardware component, and two endpoints define a connection between two ports, which on the HW level are the wires between the ports. So a port with two endpoints is a group of pins, with wires that go from the same pins to two different components. It could be approximated like this, but I don't think it is needed. I would rather stay with only port nodes mapped to hardware and the endpoint nodes logical. -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] Documentation: of: Document graph bindings
On 08/03/14 14:25, Grant Likely wrote: Sure. If endpoints are logical, then only create the ones actually hooked up. No problem there. But nor do I see any issue with having empty connections if the board author things it makes sense to have them in the dtsi. I don't think they are usually logical, although they probably might be in some cases. As I see it, a port is a group of pins in a hardware component, and two endpoints define a connection between two ports, which on the HW level are the wires between the ports. So a port with two endpoints is a group of pins, with wires that go from the same pins to two different components. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH v4 3/3] Documentation: of: Document graph bindings
On 07/03/14 20:11, Grant Likely wrote:
Any board not using that port can just leave the endpoint disconnected.
Hmm I see. I'm against that.
I think the SoC dtsi should not contain endpoint node, or even port node
(at least usually). It doesn't know how many endpoints, if any, a
particular board has. That part should be up to the board dts.
Why? We have established precedence for unused devices still being in
the tree. I really see no issue with it.
I'm fine with having ports defined in the SoC dtsi. A port is a physical
thing, a group of pins, for example.
But an endpoint is a description of the other end of a link. To me, a
single endpoint makes no sense, there has to be a pair of endpoints. The
board may need 0 to n endpoints, and the SoC dtsi cannot know how many
are needed.
If the SoC dtsi defines a single endpoint for a port, and the board
needs to use two endpoints for that port, it gets really messy: one
endpoint is defined in the SoC dtsi, and used in the board dts. The
second endpoint for the same port needs to be defined separately in the
board file. I.e. something like:
/* the first ep */
port1_ep {
remote-endpoint = ..;
};
port1 {
/* the second ep */
endpoint@2 {
remote-endpoint = ..;
};
};
Versus:
port1 {
/* the first ep */
endpoint@1 {
remote-endpoint = ..;
};
/* the second ep */
endpoint@2 {
remote-endpoint = ..;
};
};
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v4 3/3] Documentation: of: Document graph bindings
On Sat, 8 Mar 2014 11:35:38 +0200, Tomi Valkeinen tomi.valkei...@ti.com wrote:
On 07/03/14 20:11, Grant Likely wrote:
Any board not using that port can just leave the endpoint disconnected.
Hmm I see. I'm against that.
I think the SoC dtsi should not contain endpoint node, or even port node
(at least usually). It doesn't know how many endpoints, if any, a
particular board has. That part should be up to the board dts.
Why? We have established precedence for unused devices still being in
the tree. I really see no issue with it.
I'm fine with having ports defined in the SoC dtsi. A port is a physical
thing, a group of pins, for example.
But an endpoint is a description of the other end of a link. To me, a
single endpoint makes no sense, there has to be a pair of endpoints. The
board may need 0 to n endpoints, and the SoC dtsi cannot know how many
are needed.
If the SoC dtsi defines a single endpoint for a port, and the board
needs to use two endpoints for that port, it gets really messy: one
endpoint is defined in the SoC dtsi, and used in the board dts. The
second endpoint for the same port needs to be defined separately in the
board file. I.e. something like:
Sure. If endpoints are logical, then only create the ones actually
hooked up. No problem there. But nor do I see any issue with having
empty connections if the board author things it makes sense to have them
in the dtsi.
/* the first ep */
port1_ep {
remote-endpoint = ..;
};
port1 {
/* the second ep */
endpoint@2 {
remote-endpoint = ..;
};
};
Versus:
port1 {
/* the first ep */
endpoint@1 {
remote-endpoint = ..;
};
/* the second ep */
endpoint@2 {
remote-endpoint = ..;
};
};
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] Documentation: of: Document graph bindings
Hi Grant,
On Saturday 08 March 2014 12:25:32 Grant Likely wrote:
On Sat, 8 Mar 2014 11:35:38 +0200, Tomi Valkeinen wrote:
On 07/03/14 20:11, Grant Likely wrote:
Any board not using that port can just leave the endpoint
disconnected.
Hmm I see. I'm against that.
I think the SoC dtsi should not contain endpoint node, or even port
node (at least usually). It doesn't know how many endpoints, if any, a
particular board has. That part should be up to the board dts.
Why? We have established precedence for unused devices still being in
the tree. I really see no issue with it.
I'm fine with having ports defined in the SoC dtsi. A port is a physical
thing, a group of pins, for example.
But an endpoint is a description of the other end of a link. To me, a
single endpoint makes no sense, there has to be a pair of endpoints. The
board may need 0 to n endpoints, and the SoC dtsi cannot know how many
are needed.
If the SoC dtsi defines a single endpoint for a port, and the board
needs to use two endpoints for that port, it gets really messy: one
endpoint is defined in the SoC dtsi, and used in the board dts. The
second endpoint for the same port needs to be defined separately in the
board file. I.e. something like:
Sure. If endpoints are logical, then only create the ones actually hooked
up. No problem there. But nor do I see any issue with having empty
connections if the board author things it makes sense to have them in the
dtsi.
I don't mind allowing board authors to add empty connections if they want to,
but I think it's a good practice not to include them given that endpoint are
logical. I would at least not include them in the of-graph DT bindings
examples.
/* the first ep */
port1_ep {
remote-endpoint = ..;
};
port1 {
/* the second ep */
endpoint@2 {
remote-endpoint = ..;
};
};
Versus:
port1 {
/* the first ep */
endpoint@1 {
remote-endpoint = ..;
};
/* the second ep */
endpoint@2 {
remote-endpoint = ..;
};
};
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] Documentation: of: Document graph bindings
On Wed, 26 Feb 2014 15:14:17 +0200, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On 25/02/14 16:58, Philipp Zabel wrote:
+Optional endpoint properties
+
+
+- remote-endpoint: phandle to an 'endpoint' subnode of a remote device
node.
Why is that optional? What use is an endpoint, if it's not connected to
something?
Also, if this is being worked on, I'd like to propose the addition of
simpler single-endpoint cases which I've been using with OMAP DSS. So if
there's just a single endpoint for the device, which is very common, you
can have just:
device {
...
endpoint { ... };
};
However, I guess that the patch just keeps growing and growing, so maybe
it's better to add such things later =).
It's good to talk about it now while boiling down the core behaviour
into a useful pattern. That said, I think if the stuff I've commented on
already is addressed then it will probably be sufficient for me to ack
or merge the change.
g.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] Documentation: of: Document graph bindings
On Wed, 26 Feb 2014 16:50:52 +0200, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On 26/02/14 16:57, Philipp Zabel wrote:
Hi Tomi,
Am Mittwoch, den 26.02.2014, 15:14 +0200 schrieb Tomi Valkeinen:
On 25/02/14 16:58, Philipp Zabel wrote:
+Optional endpoint properties
+
+
+- remote-endpoint: phandle to an 'endpoint' subnode of a remote device
node.
Why is that optional? What use is an endpoint, if it's not connected to
something?
This allows to include the an empty endpoint template in a SoC dtsi for
the convenience of board dts writers. Also, the same property is
currently listed as optional in video-interfaces.txt.
soc.dtsi:
display-controller {
port {
disp0: endpoint { };
};
};
board.dts:
#include soc.dtsi
disp0 {
remote-endpoint = panel_input;
};
panel {
port {
panel_in: endpoint {
remote-endpoint = disp0;
};
};
};
Any board not using that port can just leave the endpoint disconnected.
Hmm I see. I'm against that.
I think the SoC dtsi should not contain endpoint node, or even port node
(at least usually). It doesn't know how many endpoints, if any, a
particular board has. That part should be up to the board dts.
Why? We have established precedence for unused devices still being in
the tree. I really see no issue with it.
g.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] Documentation: of: Document graph bindings
On 26/02/14 17:47, Philipp Zabel wrote:
Ok, that looks compact enough. I still don't see the need to change make
the remote-endpoint property required to achieve this, though. On the
other hand, I wouldn't object to making it mandatory either.
Sure, having remote-endpoint as required doesn't achieve anything
particular as such. I just feel it's cleaner. If you have an endpoint,
it must point to somewhere. Maybe it makes the code a tiny bit simpler.
If we do already have users for this that do not have the
remote-endpoint, then we're stuck with having it as optional. If we
don't, I'd rather have it as mandatory.
In any case, it's not a very important thing either way.
Of course, it's up to the developer how his dts looks like. But to me it
makes sense to require the remote-endpoint property, as the endpoint, or
even the port, doesn't make much sense if there's nothing to connect to.
Please let's not make it mandatory for a port node to contain an
endpoint. For any device with multiple ports we can't use the simplified
form above, and only adding the (correctly numbered) port in all the
board device trees would be a pain.
That's true. I went with having the ports in the board file, for example
on omap3 the dss has two ports, and N900 board uses the second one:
dss {
status = ok;
pinctrl-names = default;
pinctrl-0 = dss_sdi_pins;
vdds_sdi-supply = vaux1;
ports {
#address-cells = 1;
#size-cells = 0;
port@1 {
reg = 1;
sdi_out: endpoint {
remote-endpoint = lcd_in;
datapairs = 2;
};
};
};
};
Here I guess I could have:
dss {
status = ok;
pinctrl-names = default;
pinctrl-0 = dss_sdi_pins;
vdds_sdi-supply = vaux1;
};
dss_sdi_port {
sdi_out: endpoint {
remote-endpoint = lcd_in;
datapairs = 2;
};
};
But I didn't like that as it splits the pincontrol and regulator supply
from the port/endpoint, which are functionally linked together.
Actually, somewhat aside the subject, I'd like to have the pinctrl and
maybe regulator supply also per endpoint, but I didn't see how that
would be possible with the current framework. If a board would need to
endpoints for the same port, most likely it would also need to different
sets of pinctrls.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v4 3/3] Documentation: of: Document graph bindings
On 27/02/14 12:52, Philipp Zabel wrote:
This is a bit verbose, and if your output port is on an encoder device
with multiple inputs, the correct port number would become a bit
unintuitive. For example, we'd have to use port@4 as the output encoder
units that have a 4-port input multiplexer and port@1 for those that
don't.
Hmm, sorry, I don't follow...
The port numbers should be fixed for a particular device. If the device
has 4 input ports, the output port would always be port@4, no matter how
many of the input ports are actually used.
I don't have anything against having the ports described in the SoC
dtsi. But I do think it may make it a bit unclear that the ports are
from the same device, and share things like pinmuxing. Both approaches
should work fine, afaics.
However, if, instead, we could have the pinmuxing and other relevant
information in the port or endpoint nodes, making the ports independent
of each other and of the device behind them, I argument above would
disappear.
Also, while I'm all for making the dts files clear, I do think the one
writing the dts still needs to go carefully through the binding docs.
Say, a device may need a gpio list with a bunch of gpios. The developer
just needs to read the docs and know that gpio #3 on the list is GPIO_XYZ.
So I don't see it as a major problem that the board developer needs to
know that port@1 on OMAP3's DSS is SDI output.
Here I guess I could have:
dss {
status = ok;
pinctrl-names = default;
pinctrl-0 = dss_sdi_pins;
vdds_sdi-supply = vaux1;
};
What is supplied by this regulator. Is it the PHY?
Yes.
Actually, somewhat aside the subject, I'd like to have the pinctrl and
maybe regulator supply also per endpoint, but I didn't see how that
would be possible with the current framework. If a board would need to
endpoints for the same port, most likely it would also need to different
sets of pinctrls.
I have a usecase for this the other way around. The i.MX6 DISP0 parallel
display pads can be connected to two different display controllers via
multiplexers in the pin control block.
parallel-display {
compatible = fsl,imx-parallel-display;
#address-cells = 1;
#size-cells = 0;
port@0 {
endpoint {
remote-endpoint = ipu1_di0;
};
};
port@1 {
endpoint {
remote-endpoint = ipu2_di0;
};
};
disp0: port@2 {
endpoint {
pinctrl-names = 0, 1;
pinctrl-0 = pinctrl_disp0_ipu1;
pinctrl-1 = pinctrl_disp0_ipu2;
remote-endpoint = lcd_in;
};
}
};
Here, depending on the active input port, the corresponding pin control
on the output port could be set. This is probably quite driver specific,
so I don't see yet how the framework should help with this. In any case,
maybe this is a bit out of scope for the generic graph bindings.
Hmm, why wouldn't you have the pinctrl definitions in the ports 0 and 1,
then, if it's about selecting the active input pins?
I think the pinctrl framework could offer ways to have pinctrl
definitions anywhere in the DT structure. It'd be up to the driver to
point to the pinctrl in the DT, ask the framework to parse them, and
eventually enable/disable the pins.
But yes, it's a bit out of scope =).
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v4 3/3] Documentation: of: Document graph bindings
On 25/02/14 16:58, Philipp Zabel wrote:
+Optional endpoint properties
+
+
+- remote-endpoint: phandle to an 'endpoint' subnode of a remote device node.
Why is that optional? What use is an endpoint, if it's not connected to
something?
Also, if this is being worked on, I'd like to propose the addition of
simpler single-endpoint cases which I've been using with OMAP DSS. So if
there's just a single endpoint for the device, which is very common, you
can have just:
device {
...
endpoint { ... };
};
However, I guess that the patch just keeps growing and growing, so maybe
it's better to add such things later =).
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v4 3/3] Documentation: of: Document graph bindings
Hi Tomi,
Am Mittwoch, den 26.02.2014, 15:14 +0200 schrieb Tomi Valkeinen:
On 25/02/14 16:58, Philipp Zabel wrote:
+Optional endpoint properties
+
+
+- remote-endpoint: phandle to an 'endpoint' subnode of a remote device
node.
Why is that optional? What use is an endpoint, if it's not connected to
something?
This allows to include the an empty endpoint template in a SoC dtsi for
the convenience of board dts writers. Also, the same property is
currently listed as optional in video-interfaces.txt.
soc.dtsi:
display-controller {
port {
disp0: endpoint { };
};
};
board.dts:
#include soc.dtsi
disp0 {
remote-endpoint = panel_input;
};
panel {
port {
panel_in: endpoint {
remote-endpoint = disp0;
};
};
};
Any board not using that port can just leave the endpoint disconnected.
On the other hand, the same could be achieved with Heiko Stübner's
conditional nodes dtc patch:
soc.dtsi:
display-controller {
port {
/delete-unreferenced/ disp0: endpoint { };
};
};
Also, if this is being worked on, I'd like to propose the addition of
simpler single-endpoint cases which I've been using with OMAP DSS. So if
there's just a single endpoint for the device, which is very common, you
can have just:
device {
...
endpoint { ... };
};
However, I guess that the patch just keeps growing and growing, so maybe
it's better to add such things later =).
Yes, that looks good. I'd be happy if we could add this in a second step
as a backwards compatible simplification.
regards
Philipp
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/3] Documentation: of: Document graph bindings
On 26/02/14 16:57, Philipp Zabel wrote:
Hi Tomi,
Am Mittwoch, den 26.02.2014, 15:14 +0200 schrieb Tomi Valkeinen:
On 25/02/14 16:58, Philipp Zabel wrote:
+Optional endpoint properties
+
+
+- remote-endpoint: phandle to an 'endpoint' subnode of a remote device
node.
Why is that optional? What use is an endpoint, if it's not connected to
something?
This allows to include the an empty endpoint template in a SoC dtsi for
the convenience of board dts writers. Also, the same property is
currently listed as optional in video-interfaces.txt.
soc.dtsi:
display-controller {
port {
disp0: endpoint { };
};
};
board.dts:
#include soc.dtsi
disp0 {
remote-endpoint = panel_input;
};
panel {
port {
panel_in: endpoint {
remote-endpoint = disp0;
};
};
};
Any board not using that port can just leave the endpoint disconnected.
Hmm I see. I'm against that.
I think the SoC dtsi should not contain endpoint node, or even port node
(at least usually). It doesn't know how many endpoints, if any, a
particular board has. That part should be up to the board dts.
I've done this with OMAP as (much simplified):
SoC.dtsi:
dss: dss@5800 {
status = disabled;
};
Nothing else (relevant here). The binding documentation states that dss
has one port, and information what data is needed for the port and endpoint.
board.dts:
dss {
status = ok;
pinctrl-names = default;
pinctrl-0 = dss_dpi_pins;
dpi_out: endpoint {
remote-endpoint = tfp410_in;
data-lines = 24;
};
};
That's using the shortened version without port node.
Of course, it's up to the developer how his dts looks like. But to me it
makes sense to require the remote-endpoint property, as the endpoint, or
even the port, doesn't make much sense if there's nothing to connect to.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v4 3/3] Documentation: of: Document graph bindings
Am Mittwoch, den 26.02.2014, 16:50 +0200 schrieb Tomi Valkeinen:
On 26/02/14 16:57, Philipp Zabel wrote:
Hi Tomi,
Am Mittwoch, den 26.02.2014, 15:14 +0200 schrieb Tomi Valkeinen:
On 25/02/14 16:58, Philipp Zabel wrote:
+Optional endpoint properties
+
+
+- remote-endpoint: phandle to an 'endpoint' subnode of a remote device
node.
Why is that optional? What use is an endpoint, if it's not connected to
something?
This allows to include the an empty endpoint template in a SoC dtsi for
the convenience of board dts writers. Also, the same property is
currently listed as optional in video-interfaces.txt.
soc.dtsi:
display-controller {
port {
disp0: endpoint { };
};
};
board.dts:
#include soc.dtsi
disp0 {
remote-endpoint = panel_input;
};
panel {
port {
panel_in: endpoint {
remote-endpoint = disp0;
};
};
};
Any board not using that port can just leave the endpoint disconnected.
Hmm I see. I'm against that.
I think the SoC dtsi should not contain endpoint node, or even port node
(at least usually).
Well, at least the port is a physical thing. I see no reason not to have
it in the dtsi.
It doesn't know how many endpoints, if any, a
particular board has. That part should be up to the board dts.
...
I've done this with OMAP as (much simplified):
SoC.dtsi:
dss: dss@5800 {
status = disabled;
};
Nothing else (relevant here). The binding documentation states that dss
has one port, and information what data is needed for the port and endpoint.
board.dts:
dss {
status = ok;
pinctrl-names = default;
pinctrl-0 = dss_dpi_pins;
dpi_out: endpoint {
remote-endpoint = tfp410_in;
data-lines = 24;
};
};
That's using the shortened version without port node.
Ok, that looks compact enough. I still don't see the need to change make
the remote-endpoint property required to achieve this, though. On the
other hand, I wouldn't object to making it mandatory either.
Of course, it's up to the developer how his dts looks like. But to me it
makes sense to require the remote-endpoint property, as the endpoint, or
even the port, doesn't make much sense if there's nothing to connect to.
Please let's not make it mandatory for a port node to contain an
endpoint. For any device with multiple ports we can't use the simplified
form above, and only adding the (correctly numbered) port in all the
board device trees would be a pain.
regards
Philipp
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/3] Documentation: of: Document graph bindings
The device tree graph bindings as used by V4L2 and documented in
Documentation/device-tree/bindings/media/video-interfaces.txt contain
generic parts that are not media specific but could be useful for any
subsystem with data flow between multiple devices. This document
describe the generic bindings.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
Documentation/devicetree/bindings/graph.txt | 98 +
1 file changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/graph.txt
diff --git a/Documentation/devicetree/bindings/graph.txt
b/Documentation/devicetree/bindings/graph.txt
new file mode 100644
index 000..97c877e
--- /dev/null
+++ b/Documentation/devicetree/bindings/graph.txt
@@ -0,0 +1,98 @@
+Common bindings for device graphs
+
+General concept
+---
+
+The hierarchical organisation of the device tree is well suited to describe
+control flow to devices, but data flow between devices that work together to
+form a logical compound device can follow arbitrarily complex graphs.
+The device tree graph bindings allow to describe data bus connections between
+individual devices, that can not be inferred from device tree parent-child
+relationships. The common bindings do not contain any information about the
+direction or type of data flow, they just map connections. Specific properties
+of the connections are described by specialized bindings depending on the type
+of connection. To see how this binding applies to video pipelines, see for
+example Documentation/device-tree/bindings/media/video-interfaces.txt.
+
+Devices can have multiple data interfaces, each of which can be connected to
+the data interfaces of one or more remote devices via a data bus.
+Data interfaces are described by the device nodes' child 'port' nodes. A port
+node contains an 'endpoint' subnode for each remote device port connected to
+this port via a bus. If a port is connected to more than one remote device on
+the same bus, an 'endpoint' child node must be provided for each of them. If
+more than one port is present in a device node or there is more than one
+endpoint at a port, or port node needs to be associated with a selected
+hardware interface, a common scheme using '#address-cells', '#size-cells'
+and 'reg' properties is used.
+
+device {
+...
+#address-cells = 1;
+#size-cells = 0;
+
+port@0 {
+...
+endpoint@0 { ... };
+endpoint@1 { ... };
+};
+
+port@1 { ... };
+};
+
+All 'port' nodes can be grouped under optional 'ports' node, which allows to
+specify #address-cells, #size-cells properties independently for the 'port'
+and 'endpoint' nodes and any child device nodes a device might have.
+
+device {
+...
+ports {
+#address-cells = 1;
+#size-cells = 0;
+
+port@0 {
+...
+endpoint@0 { ... };
+endpoint@1 { ... };
+};
+
+port@1 { ... };
+};
+};
+
+Each endpoint can contain a 'remote-endpoint' phandle property that points to
+the corresponding endpoint in the port of the remote device. Two 'endpoint'
+nodes are linked with each other through their 'remote-endpoint' phandles.
+
+device_1 {
+port {
+device_1_output: endpoint {
+remote-endpoint = device_2_input;
+};
+};
+};
+
+device_1 {
+port {
+device_2_input: endpoint {
+remote-endpoint = device_1_output;
+};
+};
+};
+
+
+Required properties
+---
+
+If there is more than one 'port' or more than one 'endpoint' node or 'reg'
+property is present in port and/or endpoint nodes the following properties
+are required in a relevant parent node:
+
+ - #address-cells : number of cells required to define port/endpoint
+identifier, should be 1.
+ - #size-cells: should be zero.
+
+Optional endpoint properties
+
+
+- remote-endpoint: phandle to an 'endpoint' subnode of a remote device node.
+
--
1.8.5.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
