[prev in list] [next in list] [prev in thread] [next in thread] 

List:       devicetree
Subject:    [PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra
From:       swarren () wwwdotorg ! org (Stephen Warren)
Date:       2012-07-31 16:12:35
Message-ID: 501803F3.6090803 () wwwdotorg ! org
[Download RAW message or body]

On 07/31/2012 03:27 AM, Simon Glass wrote:
> On Thu, Jul 12, 2012 at 4:25 PM, Simon Glass <sjg at chromium.org> wrote:
> > Add LCD definitions and also a proposed binding for LCD displays.
> > 
> > The PWM is as per what will likely be committed to linux-next soon.
> > 
> > The displaymode binding comes from a proposal here:
> > 
> > http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html
> > 
> > The panel binding is new, and fills a need to specify the panel
> > timings and other tegra-specific information. Should a binding appear
> > that allows the pwm to handle this automatically, we can revisit
> > this.
> 
> Any comments on this binding please? The main addition from Thierry's
> one posted on LMKL is the LCD resolution selection.

I have some concerns about the way the mode is represented in the
binding; the timing parameters are quite different to how e.g. an EDID
DTD would represent them, which I think will lead to conversion mistakes
when writing the DT.

I'm trying to get along of Sascha's original email so I can join in on
that discussion.

> > diff --git a/doc/device-tree-bindings/video/tegra20-dc.txt \
> > b/doc/device-tree-bindings/video/tegra20-dc.txt

> > +Optional properties (rgb):
> > + - nvidia,frame-buffer: address of frame buffer (if omitted it will be
> > +               calculated)
> > +       - This may be useful to share an address between U-Boot and Linux and
> > +               avoid boot-time corruption / flicker

Why can't the display driver read this out of the display registers,
instead of requiring the same information to be passed using DT too?


[prev in list] [next in list] [prev in thread] [next in thread]