[PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra

[Thierry Reding]

On Wed, Jul 11, 2012 at 06:44:10AM +0200, Simon Glass wrote:
> Hi Stephen,
> 
> On Fri, Jun 15, 2012 at 1:32 AM, Stephen Warren <swarren at wwwdotorg.org>wrote:
> 
> > On 06/13/2012 10:19 AM, Simon Glass wrote:
> > > Add LCD definitions and also a proposed binding for LCD displays.
> > >
> > > The PWFM is in progress on the device-tree-discuss list, so only a
> > > very basic binding is offered here.
> >
> > I believe we have settled on a final representation, it just hasn't been
> > added into linux-next yet. See:
> >
> >
> > http://gitorious.org/linux-pwm/linux-pwm/commit/d3ce73e5dc86646a6302f2b0f7dd40e8c552fa04
> 
> 
> Thanks for the pointer. I suppose this doesn't address clocks as yet, but
> that's fine.

I was waiting for the common clock framework and DT bindings to get
ready. This should happen RSN for Tegra so I will probably look at
adding support for it in.

By the way, the PWM tree has now been in linux-next for a couple of
weeks and I plan to submit it for inclusion in 3.6.

> > > I am not sure if it is better to have the lcd within the display
> > > controller as with i2c/spi, or a separate node. From a hardware point
> > > of view the LCD is certainly connected to the display controller, so
> > > perhaps this version makes most sense. We could have a stand-alone
> > > top-level lcd node with a phandle pointing to the display controller,
> > > but these doesn't seem to be an obvious advantage to that approach.
> >
> > Equally, there's been extensive discussion re: how to represent the
> > NVIDIA display controller in DT. I strongly believe that U-Boot
> > shouldn't go ahead in isolation with a binding that's completely
> > unrelated to what's happening in the kernel. Please can you take what
> > Thierry is working on for the kernel, and/or contribute to that binding
> > etc., so we don't end up with multiple ways of doing the same thing.
> > Part of the whole point of DT is to have a single way of representing HW
> > that multiple OSs (or perhaps bootloaders) cna use. If everyone just
> > goes and does their own thing, we've lost.
> >
> 
> I can see the email here.
> 
> http://lists.freedesktop.org/archives/dri-devel/2012-April/021223.html
> 
> I posted this series originally in January. That email is from April, and I
> don't see activity in the last 2 months. As previously discussed it is not
> productive to chase a moving target.

I had hoped I could get this finished much faster, but then things
happened. However there has been quite some progress in the meantime.

I actually based that very first version on what you had in the earlier
Tegra LCD series with a couple of additions to support DRM
specificities. However the proposal was shot down pretty early mainly
because the display timing description was very Tegra specific. One
proposal was to include an EDID blob directly into the DT and pass it on
to DRM, which is what the current code does.

Lately there's been some work on adding a generic description for
display timings:

	http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html

I haven't tested that code yet, but it might turn out to be an
interesting replacement for the EDID blob.

> Thierry, have you settled on a binding yet? If not do you have something
> sort-of close that I could use in U-Boot?

The currently accepted form (as in "Stephen said it looks reasonable")
is here:

	http://lists.freedesktop.org/archives/dri-devel/2012-July/024899.html

It currently only defines the bindings for the RGB and HDMI outputs, but
that should be fine since from what I can tell your U-Boot driver
supports RGB only anyway. It is probably also way more than you really
need in U-Boot because it has DT nodes for all the graphics-related
modules.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/devicetree-discuss/attachments/20120711/62660cca/attachment-0001.sig>