Re: [PATCH v4 3/3] Documentation: of: Document graph bindings

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 3442 bytes --]

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



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]