All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
To: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: Russell King - ARM Linux
	<linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	Mauro Carvalho Chehab
	<m.chehab-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	Grant Likely
	<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Sylwester Nawrocki
	<s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	Laurent Pinchart
	<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>,
	Kyungmin Park
	<kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Guennadi Liakhovetski
	<g.liakhovetski-Mmb7MZpHnFY@public.gmane.org>
Subject: Re: [PATCH v4 3/3] Documentation: of: Document graph bindings
Date: Thu, 27 Feb 2014 10:08:52 +0200	[thread overview]
Message-ID: <530EF294.7070801@ti.com> (raw)
In-Reply-To: <1393429676.3248.110.camel-+qGW7pzALmz7o/J7KWpOmN53zsg1cpMQ@public.gmane.org>

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

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



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

WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Mauro Carvalho Chehab <m.chehab@samsung.com>,
	Grant Likely <grant.likely@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Sylwester Nawrocki <s.nawrocki@samsung.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	<linux-kernel@vger.kernel.org>, <linux-media@vger.kernel.org>,
	<devicetree@vger.kernel.org>,
	Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Subject: Re: [PATCH v4 3/3] Documentation: of: Document graph bindings
Date: Thu, 27 Feb 2014 10:08:52 +0200	[thread overview]
Message-ID: <530EF294.7070801@ti.com> (raw)
In-Reply-To: <1393429676.3248.110.camel@paszta.hi.pengutronix.de>

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

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



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

  parent reply	other threads:[~2014-02-27  8:08 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-25 14:58 [PATCH v4 0/3] Move device tree graph parsing helpers to drivers/of Philipp Zabel
     [not found] ` < 1393428297.3248.92.camel@paszta.hi.pengutronix.de>
     [not found]   ` <20140307171804. EF245C40A32@trevor.secretlab.ca>
     [not found] ` < 1393340304-19005-4-git-send-email-p.zabel@pengutronix.de>
     [not found] ` < 1393340304-19005-2-git-send-email-p.zabel@pengutronix.de>
     [not found]   ` <20140226113729. A9D5AC40A89@trevor.secretlab.ca>
     [not found] ` < 20140226113729.A9D5AC40A89@trevor.secretlab.ca>
2014-02-25 14:58 ` [PATCH v4 1/3] [media] of: move graph helpers from drivers/media/v4l2-core " Philipp Zabel
2014-02-26 11:37   ` Grant Likely
2014-02-26 11:37     ` Grant Likely
2014-02-26 15:24     ` Philipp Zabel
2014-03-07 17:18       ` Grant Likely
2014-03-08 10:46         ` Tomi Valkeinen
2014-03-08 10:46           ` Tomi Valkeinen
2014-03-08 12:23           ` Grant Likely
2014-03-08 15:50             ` Laurent Pinchart
2014-03-20 22:23               ` Grant Likely
     [not found]                 ` <20140320222347.CAB6DC412EA-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2014-03-20 22:32                   ` Laurent Pinchart
2014-03-20 22:32                     ` Laurent Pinchart
2014-03-21 13:37                     ` Tomi Valkeinen
2014-03-21 13:37                       ` Tomi Valkeinen
2014-03-21 14:10                       ` Sylwester Nawrocki
     [not found]                       ` <532C408D.4070002-l0cyMroinI0@public.gmane.org>
2014-03-21 14:13                         ` Laurent Pinchart
2014-03-21 14:13                           ` Laurent Pinchart
2014-03-21 14:22                           ` Tomi Valkeinen
2014-03-21 14:22                             ` Tomi Valkeinen
     [not found]                             ` <532C4B3C.4030406-l0cyMroinI0@public.gmane.org>
2014-03-21 14:30                               ` Laurent Pinchart
2014-03-21 14:30                                 ` Laurent Pinchart
2014-03-10  6:34             ` Tomi Valkeinen
2014-03-10  6:34               ` Tomi Valkeinen
2014-03-20 22:26               ` Grant Likely
2014-03-08 12:07         ` Philipp Zabel
     [not found]           ` <CA+gwMcfgKre8S4KHPvTVuAuz672aehGrN1UfFpwKAueTAcrMZQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-03-08 15:54             ` Laurent Pinchart
2014-03-08 15:54               ` Laurent Pinchart
2014-03-10  6:00               ` Tomi Valkeinen
2014-03-10  6:00                 ` Tomi Valkeinen
     [not found]                 ` <531D54E2.8030303-l0cyMroinI0@public.gmane.org>
2014-03-10 13:57                   ` Laurent Pinchart
2014-03-10 13:57                     ` Laurent Pinchart
2014-03-10  8:58               ` Andrzej Hajda
2014-03-10  8:58                 ` Andrzej Hajda
     [not found]                 ` <531D7E9F.3090708-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2014-03-10  9:29                   ` Tomi Valkeinen
2014-03-10  9:29                     ` Tomi Valkeinen
2014-03-10 11:42                   ` Laurent Pinchart
2014-03-10 11:42                     ` Laurent Pinchart
2014-03-11 13:55                     ` Andrzej Hajda
2014-03-11 13:55                       ` Andrzej Hajda
2014-03-20 22:33             ` Grant Likely
2014-03-20 22:33               ` Grant Likely
2014-02-25 14:58 ` [PATCH v4 2/3] [media] of: move common endpoint parsing " Philipp Zabel
2014-02-25 14:58 ` [PATCH v4 3/3] Documentation: of: Document graph bindings Philipp Zabel
2014-02-26 13:14   ` Tomi Valkeinen
2014-02-26 13:14     ` Tomi Valkeinen
2014-02-26 14:57     ` Philipp Zabel
     [not found]       ` <1393426623.3248.70.camel-+qGW7pzALmz7o/J7KWpOmN53zsg1cpMQ@public.gmane.org>
2014-02-26 14:50         ` Tomi Valkeinen
2014-02-26 14:50           ` Tomi Valkeinen
2014-02-26 15:47           ` Philipp Zabel
     [not found]             ` <1393429676.3248.110.camel-+qGW7pzALmz7o/J7KWpOmN53zsg1cpMQ@public.gmane.org>
2014-02-27  8:08               ` Tomi Valkeinen [this message]
2014-02-27  8:08                 ` Tomi Valkeinen
2014-02-27 10:52                 ` Philipp Zabel
2014-02-27 10:41                   ` Tomi Valkeinen
2014-02-27 10:41                     ` Tomi Valkeinen
     [not found]       ` < 530DFF4C.8080807@ti.com>
     [not found]         ` <530DFF4C.8080807-l0cyMroinI0@public.gmane.org>
2014-03-07 18:11           ` Grant Likely
2014-03-07 18:11             ` Grant Likely
2014-03-08  9:35             ` Tomi Valkeinen
2014-03-08  9:35               ` Tomi Valkeinen
2014-03-08 12:25               ` Grant Likely
2014-03-08 15:43                 ` Laurent Pinchart
2014-03-10  6:53                 ` Tomi Valkeinen
2014-03-10  6:53                   ` Tomi Valkeinen
     [not found]                   ` <531D6178.3070906-l0cyMroinI0@public.gmane.org>
2014-03-11 13:47                     ` Sylwester Nawrocki
2014-03-11 13:47                       ` Sylwester Nawrocki
2014-03-07 17:20     ` Grant Likely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=530EF294.7070801@ti.com \
    --to=tomi.valkeinen-l0cymroini0@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=g.liakhovetski-Mmb7MZpHnFY@public.gmane.org \
    --cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=kyungmin.park-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
    --cc=linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=m.chehab-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    --cc=p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.