From: Stephen Warren <swarren@wwwdotorg.org>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] media: add V4L2 DT binding documentation
Date: Wed, 12 Sep 2012 20:53:39 +0000 [thread overview]
Message-ID: <5050F653.5070404@wwwdotorg.org> (raw)
In-Reply-To: <Pine.LNX.4.64.1209122111100.28968@axis700.grange>
On 09/12/2012 01:28 PM, Guennadi Liakhovetski wrote:
> Hi Stephen
>
> On Wed, 12 Sep 2012, Stephen Warren wrote:
>
>> On 09/11/2012 09:51 AM, Guennadi Liakhovetski wrote:
>>> This patch adds a document, describing common V4L2 device tree bindings.
>>>
>>> Co-authored-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>>
>> Overall, I think this looks pretty reasonable, so:
...
>>
>>> + clock-frequency = <50000000>; /* max clock frequency */
>>> + clock-output-names = "mclk";
>>> + };
>>> +
>>> + port {
>> ...
>>> + ceu0_0: link@0 {
>>> + reg = <0>;
>>> + remote = <&csi2_2>;
>>> + immutable;
>>
>> Did we decide "immutable" was actually needed? Presumably the driver for
>> the HW in question knows the HW isn't configurable, and would simply not
>> attempt to apply any configuration even if the .dts author erroneously
>> provided some?
>
> Well, I've been thinking about this today. I think, bridge drivers will
Sorry, I'm not sure what a "bridge" driver is; is it any v4l2 device?
> call centrally provided helper functions to enumerate links inside ports.
Presumably a given driver would only parse the ports/links of its own DT
node, and hence would be able to provide a parameter to any helper
function that indicated the same information that "immutable" would?
> While doing that they will want to differentiate between links to external
> devices with explicit configuration, and links to internal devices, whose
> configuration drivers might be able to figure out themselves. How should a
> driver find out what device this link is pointing to? Should it follow the
> "remote" phandle and then check the "compatible" property? The word
> "immutable" is a hint, that this is a link to an internal device, but it
> might either be unneeded or be transformed into something more
> informative.
I would imagine that a given driver would only ever parse its own DT
node; the far end of any link is purely the domain of the other driver.
I thought that each link node would contain whatever hsync-active,
data-lanes, ... properties that were needed to configure the local device?
WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] media: add V4L2 DT binding documentation
Date: Wed, 12 Sep 2012 14:53:39 -0600 [thread overview]
Message-ID: <5050F653.5070404@wwwdotorg.org> (raw)
In-Reply-To: <Pine.LNX.4.64.1209122111100.28968@axis700.grange>
On 09/12/2012 01:28 PM, Guennadi Liakhovetski wrote:
> Hi Stephen
>
> On Wed, 12 Sep 2012, Stephen Warren wrote:
>
>> On 09/11/2012 09:51 AM, Guennadi Liakhovetski wrote:
>>> This patch adds a document, describing common V4L2 device tree bindings.
>>>
>>> Co-authored-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>>
>> Overall, I think this looks pretty reasonable, so:
...
>>
>>> + clock-frequency = <50000000>; /* max clock frequency */
>>> + clock-output-names = "mclk";
>>> + };
>>> +
>>> + port {
>> ...
>>> + ceu0_0: link at 0 {
>>> + reg = <0>;
>>> + remote = <&csi2_2>;
>>> + immutable;
>>
>> Did we decide "immutable" was actually needed? Presumably the driver for
>> the HW in question knows the HW isn't configurable, and would simply not
>> attempt to apply any configuration even if the .dts author erroneously
>> provided some?
>
> Well, I've been thinking about this today. I think, bridge drivers will
Sorry, I'm not sure what a "bridge" driver is; is it any v4l2 device?
> call centrally provided helper functions to enumerate links inside ports.
Presumably a given driver would only parse the ports/links of its own DT
node, and hence would be able to provide a parameter to any helper
function that indicated the same information that "immutable" would?
> While doing that they will want to differentiate between links to external
> devices with explicit configuration, and links to internal devices, whose
> configuration drivers might be able to figure out themselves. How should a
> driver find out what device this link is pointing to? Should it follow the
> "remote" phandle and then check the "compatible" property? The word
> "immutable" is a hint, that this is a link to an internal device, but it
> might either be unneeded or be transformed into something more
> informative.
I would imagine that a given driver would only ever parse its own DT
node; the far end of any link is purely the domain of the other driver.
I thought that each link node would contain whatever hsync-active,
data-lanes, ... properties that were needed to configure the local device?
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren@wwwdotorg.org>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>,
Sylwester Nawrocki <s.nawrocki@samsung.com>,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Magnus Damm <magnus.damm@gmail.com>,
devicetree-discuss <devicetree-discuss@lists.ozlabs.org>,
linux-sh@vger.kernel.org,
Mark Brown <broonie@opensource.wolfsonmicro.com>,
Hans Verkuil <hverkuil@xs4all.nl>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Arnd Bergmann <arnd@arndb.de>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] media: add V4L2 DT binding documentation
Date: Wed, 12 Sep 2012 14:53:39 -0600 [thread overview]
Message-ID: <5050F653.5070404@wwwdotorg.org> (raw)
In-Reply-To: <Pine.LNX.4.64.1209122111100.28968@axis700.grange>
On 09/12/2012 01:28 PM, Guennadi Liakhovetski wrote:
> Hi Stephen
>
> On Wed, 12 Sep 2012, Stephen Warren wrote:
>
>> On 09/11/2012 09:51 AM, Guennadi Liakhovetski wrote:
>>> This patch adds a document, describing common V4L2 device tree bindings.
>>>
>>> Co-authored-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>>
>> Overall, I think this looks pretty reasonable, so:
...
>>
>>> + clock-frequency = <50000000>; /* max clock frequency */
>>> + clock-output-names = "mclk";
>>> + };
>>> +
>>> + port {
>> ...
>>> + ceu0_0: link@0 {
>>> + reg = <0>;
>>> + remote = <&csi2_2>;
>>> + immutable;
>>
>> Did we decide "immutable" was actually needed? Presumably the driver for
>> the HW in question knows the HW isn't configurable, and would simply not
>> attempt to apply any configuration even if the .dts author erroneously
>> provided some?
>
> Well, I've been thinking about this today. I think, bridge drivers will
Sorry, I'm not sure what a "bridge" driver is; is it any v4l2 device?
> call centrally provided helper functions to enumerate links inside ports.
Presumably a given driver would only parse the ports/links of its own DT
node, and hence would be able to provide a parameter to any helper
function that indicated the same information that "immutable" would?
> While doing that they will want to differentiate between links to external
> devices with explicit configuration, and links to internal devices, whose
> configuration drivers might be able to figure out themselves. How should a
> driver find out what device this link is pointing to? Should it follow the
> "remote" phandle and then check the "compatible" property? The word
> "immutable" is a hint, that this is a link to an internal device, but it
> might either be unneeded or be transformed into something more
> informative.
I would imagine that a given driver would only ever parse its own DT
node; the far end of any link is purely the domain of the other driver.
I thought that each link node would contain whatever hsync-active,
data-lanes, ... properties that were needed to configure the local device?
next prev parent reply other threads:[~2012-09-12 20:53 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-11 15:51 [PATCH] media: add V4L2 DT binding documentation Guennadi Liakhovetski
2012-09-11 15:51 ` Guennadi Liakhovetski
2012-09-11 15:51 ` Guennadi Liakhovetski
2012-09-11 17:04 ` Sylwester Nawrocki
2012-09-11 17:04 ` Sylwester Nawrocki
2012-09-11 17:04 ` Sylwester Nawrocki
2012-09-25 14:59 ` Guennadi Liakhovetski
2012-09-25 14:59 ` Guennadi Liakhovetski
2012-09-25 14:59 ` Guennadi Liakhovetski
2012-09-12 18:53 ` Stephen Warren
2012-09-12 18:53 ` Stephen Warren
2012-09-12 18:53 ` Stephen Warren
2012-09-12 19:28 ` Guennadi Liakhovetski
2012-09-12 19:28 ` Guennadi Liakhovetski
2012-09-12 19:28 ` Guennadi Liakhovetski
2012-09-12 20:53 ` Stephen Warren [this message]
2012-09-12 20:53 ` Stephen Warren
2012-09-12 20:53 ` Stephen Warren
2012-09-12 21:17 ` Guennadi Liakhovetski
2012-09-12 21:17 ` Guennadi Liakhovetski
2012-09-12 21:17 ` Guennadi Liakhovetski
2012-09-12 22:59 ` Stephen Warren
2012-09-12 22:59 ` Stephen Warren
2012-09-12 22:59 ` Stephen Warren
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=5050F653.5070404@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=linux-arm-kernel@lists.infradead.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.