From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Thierry Reding
<thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
Jon Mayo <jmayo-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Subject: Re: Tegra DRM device tree bindings
Date: Tue, 26 Jun 2012 12:10:42 -0600 [thread overview]
Message-ID: <4FE9FB22.1090902@wwwdotorg.org> (raw)
In-Reply-To: <20120626105513.GA9552-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
On 06/26/2012 04:55 AM, Thierry Reding wrote:
> Hi,
>
> while I haven't got much time to work on the actual code right now, I
> think it might still be useful if we could get the device tree binding
> to a point where everybody is happy with it. That'll also save me some
> time once I get to writing the code because I won't have to redo it over
> again. =)
>
> So here's the current proposal:
>
> host1x {
> compatible = "nvidia,tegra20-host1x", "simple-bus";
> reg = <0x50000000 0x00024000>;
> interrupts = <0 64 0x04 /* cop syncpt */
> 0 65 0x04 /* mpcore syncpt */
> 0 66 0x04 /* cop general */
> 0 67 0x04>; /* mpcore general */
>
> #address-cells = <1>;
> #size-cells = <1>;
>
> ranges = <0x54000000 0x54000000 0x04000000>;
>
> status = "disabled";
The idea behind status="disabled" is that some HW only makes sense to
use on particular boards. This concept really only applies to HW modules
that drive external interfaces on the SoC, which in turn the board can
choose whether to connect anything to (or whether to even connect to any
external pins using the pinmux, or not).
As such, I don't think it makes sense to set status="disabled" on
host1x, nor many other internal-only engines such as say mpe, epp, i2sp,
gr2d, gr3d, dc1, dc2.
However it does make sense for the output resources rgb, hdmi, tvo, dsi.
> /* outputs */
> rgb {
> compatible = "nvidia,tegra20-rgb";
> status = "disabled";
> };
...
> The rgb node is something that I don't quite know how to handle yet.
> Since it is really part of the display controller and uses its register
> space, it isn't quite correct to represent it as a separate device. But
> we will need a separate node to make it available as a connector, which
> will become more obvious below.
Are you referring to the DC_COM_PIN_OUTPUT* registers? Sorry, I'm not at
all familiar with our display HW yet.
Some possible solutions spring to mind:
a) The output nodes don't have to be direct children of host1x. Instead,
each DC could have an rgb child node that represents its own individual
output capability.
b) If the RGB-related registers in DC are completely independent of any
other DC registers and grouped together well enough, we can just carve a
chunk out of the DC register space and give that to the RGB node instead:
i.e. not:
> dc1: dc@54200000 {
> compatible = "nvidia,tegra20-dc";
> reg = <0x54200000 0x00040000>;
> interrupts = <0 73 0x04>;
> status = "disabled";
> };
but something more like (the completely made up example):
dc1: dc@54200000 {
compatible = "nvidia,tegra20-dc";
reg = <0x54200000 0x00020000 0x54203000 0x10000>;
interrupts = <0 73 0x04>;
status = "disabled";
};
rgb {
compatible = "nvidia,tegra20-rgb";
reg = <0x54220000 0x00010000>;
status = "disabled";
};
c) The rgb node could simply reference the dc nodes using a phandle, and
call into the dc driver to obtain RGB configuration services from it:
rgb {
compatible = "nvidia,tegra20-rgb";
status = "disabled";
nvidia,dcs = <&dc1 &dc2>;
};
By the way, if the RGB registers are in the DC, aren't there two
separate RGB outputs. Certainly the TRM implies that both DCs can be
driving LCDs, by reducing the width of the LCD signals that each DC uses
(lower bits-per-pixel, or perhaps DDR encoding on the data lines).
> Board DTS files could then extend this with board-specific requirements
> and connectors. The following describes the Medcom Wide:
> connectors {
> #address-cells = <1>;
> #size-cells = <0>;
>
> };
The connector seems to be a property of the individual output resources.
I'd expect to see the connector configuration be a child of the outputs
that a particular board had enabled; something more like:
host1x {
rgb {
status = "okay";
connector@0 {
nvidia,edid = /incbin/("tegra-medcom.edid");
};
};
hdmi {
status = "okay";
connector@0 {
nvidia,ddc-i2c-bus = <&tegra_i2c1>;
};
};
};
Perhaps even completely omit the connector node, and put the properties
directly within the rgb/hdmi node itself. After all the HDMI output
really is the connector as far as Tegra goes.
next prev parent reply other threads:[~2012-06-26 18:10 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-26 10:55 Tegra DRM device tree bindings Thierry Reding
[not found] ` <20120626105513.GA9552-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2012-06-26 12:47 ` Lucas Stach
2012-06-26 13:57 ` Thierry Reding
2012-06-26 13:01 ` Terje Bergström
[not found] ` <4FE9B291.2020305-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-06-26 13:41 ` Thierry Reding
[not found] ` <20120626134122.GA1115-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2012-06-26 14:02 ` Terje Bergström
[not found] ` <4FE9C0E9.7060301-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-06-26 17:41 ` Stephen Warren
[not found] ` <4FE9F457.6090104-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-26 19:27 ` Thierry Reding
[not found] ` <20120626192712.GA5247-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
2012-06-26 19:38 ` Stephen Warren
[not found] ` <4FEA0F99.3080603-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-27 5:10 ` Terje Bergström
2012-06-26 17:43 ` Stephen Warren
[not found] ` <4FE9F4CA.10907-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-26 19:31 ` Thierry Reding
[not found] ` <20120626193145.GB5247-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
2012-06-26 19:39 ` Stephen Warren
2012-06-27 5:24 ` Terje Bergström
2012-06-26 17:46 ` Stephen Warren
[not found] ` <4FE9F582.6010805-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-26 19:39 ` Thierry Reding
2012-06-27 6:13 ` Terje Bergström
[not found] ` <4FEAA4A0.3060407-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-06-27 6:37 ` Thierry Reding
2012-06-26 13:02 ` Hiroshi Doyu
[not found] ` <20120626160224.40ba10a26e3dd3a56b1f312c-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-06-26 14:00 ` Thierry Reding
[not found] ` <20120626140033.GC1115-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2012-06-27 1:46 ` Mark Zhang
[not found] ` <23B010BBA481A74B98487467C29BA57BF2361DA3AA-Q4EWCATADntDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2012-06-27 2:20 ` Stephen Warren
[not found] ` <4FEA6E09.30800-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-06-27 2:32 ` Mark Zhang
[not found] ` <23B010BBA481A74B98487467C29BA57BF2361DA3C4-Q4EWCATADntDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2012-06-27 2:48 ` Stephen Warren
[not found] ` <4FEA7472.7050201-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-06-27 5:14 ` Thierry Reding
[not found] ` <20120627051418.GB7177-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2012-06-27 5:28 ` Mark Zhang
2012-06-27 8:13 ` Lucas Stach
2012-06-30 17:54 ` Thierry Reding
2012-06-27 12:59 ` Hiroshi Doyu
[not found] ` <20120627155907.871b2a506374b7db14c202c4-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-06-27 14:08 ` Thierry Reding
[not found] ` <20120627140809.GD19319-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2012-06-27 14:29 ` Hiroshi Doyu
[not found] ` <20120627172914.30a2ccfd1344161ca7724722-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-06-27 14:44 ` Thierry Reding
[not found] ` <20120627144414.GA20681-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2012-06-27 15:59 ` Lucas Stach
2012-06-28 6:06 ` Hiroshi Doyu
[not found] ` <20120628090650.b915ad756c91d62d658eb53a-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-06-28 8:11 ` Lucas Stach
2012-06-28 11:12 ` Thierry Reding
[not found] ` <20120628111253.GC15137-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2012-06-28 16:51 ` Stephen Warren
[not found] ` <4FEC8B91.6010107-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-28 17:19 ` Lucas Stach
2012-06-28 17:33 ` Stephen Warren
[not found] ` <4FEC9584.4080100-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-28 18:19 ` Thierry Reding
2012-06-29 1:17 ` Mark Zhang
2012-06-29 5:57 ` Mark Zhang
2012-06-29 13:20 ` Terje Bergström
[not found] ` <4FEDAB9F.5040406-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-06-30 18:01 ` Thierry Reding
[not found] ` <20120630180143.GA23990-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
2012-07-01 17:06 ` Lucas Stach
2012-07-01 17:00 ` Lucas Stach
2012-06-28 17:01 ` Lucas Stach
2012-06-28 6:18 ` Hiroshi Doyu
[not found] ` <20120628091853.d4c3d85749f9d41a5dfafd28-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-06-28 16:46 ` Stephen Warren
[not found] ` <4FEC8A82.9090202-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-30 18:04 ` Thierry Reding
2012-06-27 17:56 ` Stephen Warren
[not found] ` <4FEB4953.7060508-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-28 6:24 ` Hiroshi Doyu
2012-06-27 5:52 ` Thierry Reding
2012-06-27 12:50 ` Hiroshi Doyu
2012-06-27 12:46 ` Hiroshi Doyu
2012-06-27 12:44 ` Hiroshi Doyu
[not found] ` <20120627154400.d9d7db67128404079d98ab39-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-06-27 18:02 ` Stephen Warren
[not found] ` <4FEB4AC6.2060909-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-28 6:37 ` Hiroshi Doyu
2012-06-28 11:58 ` Thierry Reding
2012-06-26 18:10 ` Stephen Warren [this message]
[not found] ` <4FE9FB22.1090902-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-26 19:51 ` Thierry Reding
[not found] ` <20120626195108.GB5308-RM9K5IK7kjIyiCvfTdI0JKcOhU4Rzj621B7CTYaBSLdn68oJJulU0Q@public.gmane.org>
2012-06-26 22:48 ` Stephen Warren
[not found] ` <4FEA3C2E.3030109-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-27 5:07 ` Thierry Reding
[not found] ` <20120627050733.GA7177-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2012-06-27 17:49 ` Stephen Warren
[not found] ` <4FEB47B7.4080104-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-06-28 12:07 ` Thierry Reding
2012-07-05 12:15 ` Thierry Reding
[not found] ` <20120705121506.GA23732-RM9K5IK7kjIQXX3q8xo1gnVAuStQJXxyR5q1nwbD4aMs9pC9oP6+/A@public.gmane.org>
2012-07-06 5:29 ` Mark Zhang
2012-07-06 19:59 ` Stephen Warren
[not found] ` <4FF74391.5040004-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-07-08 5:53 ` Thierry Reding
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=4FE9FB22.1090902@wwwdotorg.org \
--to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
--cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=jmayo-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox