On 09/27/2012 07:58 AM, Simon Glass wrote:
Hi Stephen,
On Tue, Jul 31, 2012 at 9:12 AM, Stephen Warren swarren@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@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 andavoid boot-time corruption / flickerWhy 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?