public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Grant Likely <grant.likely@linaro.org>,
	Philipp Zabel <p.zabel@pengutronix.de>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Mauro Carvalho Chehab <m.chehab@samsung.com>,
	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>,
	Philipp Zabel <philipp.zabel@gmail.com>
Subject: Re: [PATCH v4 1/3] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/of
Date: Mon, 10 Mar 2014 08:34:54 +0200	[thread overview]
Message-ID: <531D5D0E.8000605@ti.com> (raw)
In-Reply-To: <20140308122321.9D433C40612@trevor.secretlab.ca>

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

On 08/03/14 14:23, Grant Likely wrote:

>>> That's fine. In that case the driver would specifically require the
>>> endpoint to be that one node.... although the above looks a little weird
>>
>> The driver can't require that. It's up to the board designer to decide
>> how many endpoints are used. A driver may say that it has a single input
>> port. But the number of endpoints for that port is up to the use case.
> 
> Come now, when you're writing a driver you know if it will ever be
> possible to have more than one port. If that is the case then the
> binding should be specifically laid out for that. If there will never be
> multiple ports and the binding is unambiguous, then, and only then,
> should the shortcut be used, and only the shortcut should be accepted.

I was talking about endpoints, not ports. There's no unclarity about the
number of ports, that comes directly from the hardware for that specific
component. The number of endpoints, however, come from the board
hardware. The driver writer cannot know that.

>>> to me. I would recommend that if there are other non-port child nodes
>>> then the ports should still be encapsulated by a ports node.  The device
>>> binding should not be ambiguous about which nodes are ports.
>>
>> Hmm, ambiguous in what way?
> 
> Parsing the binding now consists of a ladder of 'ifs' that gives three
> distinct different behaviours for no benefit. You don't want that in

It considerably lessens the amount of text in the DT for many use cases,
making it easier to write and maintain the dts files.

> bindings because it makes it more difficult to get the parsing right in
> the first place, and to make sure that all users parse it in the same
> way (Linux, U-Boot, BSD, etc). Bindings should be as absolutely simple
> as possible.

Well, yes, I agree there. This is not the simplest of bindings. I'd be
more than happy if we would come up with simpler version of this, which
would still allow us to have the same descriptive power.

> Just to be clear, I have no problem with having the option in the
> pattern, but the driver needs to be specific about what layout it
> expects.

If we forget the shortened endpoint format, I think it can be quite
specific.

A device has either one port, in which case it should require the
'ports' node to be omitted, or the device has more than one port, in
which case it should require 'ports' node.

Note that the original v4l2 binding doc says that 'ports' is always
optional.

 Tomi



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

  parent reply	other threads:[~2014-03-10  6:35 UTC|newest]

Thread overview: 42+ 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] ` < 1393340304-19005-4-git-send-email-p.zabel@pengutronix.de>
     [not found] ` < 20140226113729.A9D5AC40A89@trevor.secretlab.ca>
     [not found] ` < 1393428297.3248.92.camel@paszta.hi.pengutronix.de>
     [not found]   ` <20140307171804. EF245C40A32@trevor.secretlab.ca>
     [not found] ` < 1393340304-19005-2-git-send-email-p.zabel@pengutronix.de>
     [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 15:24     ` Philipp Zabel
2014-03-07 17:18       ` Grant Likely
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
2014-03-20 22:32                 ` Laurent Pinchart
2014-03-21 13:37                   ` Tomi Valkeinen
2014-03-21 14:10                     ` Sylwester Nawrocki
2014-03-21 14:13                     ` Laurent Pinchart
2014-03-21 14:22                       ` Tomi Valkeinen
2014-03-21 14:30                         ` Laurent Pinchart
2014-03-10  6:34             ` Tomi Valkeinen [this message]
2014-03-20 22:26               ` Grant Likely
2014-03-08 12:07         ` Philipp Zabel
2014-03-08 15:54           ` Laurent Pinchart
2014-03-10  6:00             ` Tomi Valkeinen
2014-03-10 13:57               ` Laurent Pinchart
2014-03-10  8:58             ` Andrzej Hajda
2014-03-10  9:29               ` Tomi Valkeinen
2014-03-10 11:42               ` Laurent Pinchart
2014-03-11 13:55                 ` Andrzej Hajda
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 14:57     ` Philipp Zabel
2014-02-26 14:50       ` Tomi Valkeinen
2014-02-26 15:47         ` Philipp Zabel
2014-02-27  8:08           ` Tomi Valkeinen
2014-02-27 10:52             ` Philipp Zabel
2014-02-27 10:41               ` Tomi Valkeinen
2014-03-07 18:11         ` Grant Likely
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-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=531D5D0E.8000605@ti.com \
    --to=tomi.valkeinen@ti.com \
    --cc=devicetree@vger.kernel.org \
    --cc=g.liakhovetski@gmx.de \
    --cc=grant.likely@linaro.org \
    --cc=kyungmin.park@samsung.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=m.chehab@samsung.com \
    --cc=p.zabel@pengutronix.de \
    --cc=philipp.zabel@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=s.nawrocki@samsung.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox