Hi Stephen, On Tue, Jul 31, 2012 at 9:12 AM, Stephen Warren <[email protected]> wrote: > On 07/31/2012 03:27 AM, Simon Glass wrote: >> On Thu, Jul 12, 2012 at 4:25 PM, Simon Glass <[email protected]> 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? > >>> 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? Well it could, but it doesn't. 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. Regards, Simon _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
