[PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra

[Stephen Warren]

On 09/27/2012 07:58 AM, Simon Glass wrote:
> Hi Stephen,
> 
> On Tue, Jul 31, 2012 at 9:12 AM, Stephen Warren <swarren at wwwdotorg.org> wrote:
>> 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.
> 
> Did you get any resolution here?

I think an updated version of those patches was published.

>>>> 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?
> 
> The U-Boot display driver needs to set this value in the display
> registers - at reset I don't think we can rely on any particular
> value.
> 
> Do you mean the kernel display driver?

Yes.

> Well it could, but it doesn't.

Well, there is no display driver in the upstream kernel at the moment,
so it's not possible to make assertions about what it does or not.

Any downstream kernels aren't relevant, since their DT bindings and/or
behaviour have not been through public review.

> Really this is just a way of getting U-Boot and Linux to agree on the
> address, by having U-Boot know the address that the kernel will happen
> to use. It isn't very robust, but we have found it useful as a means
> of avoiding problems in this area.

Right, but again, why can't the display driver simply read the address
out of the register; why is there a need to duplicate the data?

I guess one possibility is that the register only gives the base address
and not the size/mode of the allocated surface, but I don't recall if
this proposed binding did that either?