| Message ID | 1393340304-19005-4-git-send-email-p.zabel@pengutronix.de |
|---|---|
| State | Superseded, archived |
| Headers | show |
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
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@58000000 { 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
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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@58000000 { > 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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
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
Hi Tomi, Am Donnerstag, den 27.02.2014, 10:08 +0200 schrieb Tomi Valkeinen: > On 26/02/14 17:47, Philipp Zabel wrote: > > 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>; > }; > }; > }; > }; 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. > 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? > &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. 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. regards Philipp -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 26 Feb 2014 15:14:17 +0200, Tomi Valkeinen <tomi.valkeinen@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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 26 Feb 2014 16:50:52 +0200, Tomi Valkeinen <tomi.valkeinen@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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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
On Sat, 8 Mar 2014 11:35:38 +0200, Tomi Valkeinen <tomi.valkeinen@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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 = <&..>; > > }; > > };
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
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 devicetree" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/devicetree/bindings/graph.txt b/Documentation/devicetree/bindings/graph.txt new file mode 100644 index 0000000..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. +
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.zabel@pengutronix.de> --- Documentation/devicetree/bindings/graph.txt | 98 +++++++++++++++++++++++++++++ 1 file changed, 98 insertions(+) create mode 100644 Documentation/devicetree/bindings/graph.txt