lkml.org 
[lkml]   [2014]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v4 3/3] Documentation: of: Document graph bindings
From
Date
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



\
 
 \ /
  Last update: 2014-02-27 11:41    [W:0.067 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site