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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux