Re: [U-Boot] [PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra
Hi Stephen, On Tue, Jul 31, 2012 at 9:12 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 07/31/2012 03:27 AM, Simon Glass wrote: On Thu, Jul 12, 2012 at 4:25 PM, Simon Glass s...@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? 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra
On 09/27/2012 07:58 AM, Simon Glass wrote: Hi Stephen, On Tue, Jul 31, 2012 at 9:12 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 07/31/2012 03:27 AM, Simon Glass wrote: On Thu, Jul 12, 2012 at 4:25 PM, Simon Glass s...@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? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra
Hi Thierry,
On Tue, Jul 31, 2012 at 2:51 AM, Thierry Reding
thierry.red...@avionic-design.de wrote:
On Tue, Jul 31, 2012 at 10:27:23AM +0100, Simon Glass wrote:
+Thierry
Hi,
On Thu, Jul 12, 2012 at 4:25 PM, Simon Glass s...@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.
There's no such thing as the panel bindings on Linux. I think nobody's
done that before, there's also no suitable software abstraction, but I
suppose that should be irrelevant for this discussion.
+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
+
+
+The panel node describes the panel itself.
+
+Required properties (panel) :
+ - nvidia,pwm : pwm to use to set display contrast (see tegra20-pwm.txt)
+ - nvidia,panel-timings: 4 cells containing required timings in ms:
+ * delay between panel_vdd-rise and data-rise
+ * delay between data-rise and backlight_vdd-rise
+ * delay between backlight_vdd and pwm-rise
+ * delay between pwm-rise and backlight_en-rise
+
+Optional GPIO properies all have (phandle, GPIO number, flags):
+ - nvidia,backlight-enable-gpios: backlight enable GPIO
+ - nvidia,lvds-shutdown-gpios: LVDS power shutdown GPIO
+ - nvidia,backlight-vdd-gpios: backlight power GPIO
+ - nvidia,panel-vdd-gpios: panel power GPIO
+
+Example:
+
+host1x {
+ compatible = nvidia,tegra20-host1x, simple-bus;
+ reg = 0x5000 0x00024000;
+ interrupts = 0 65 0x04 /* mpcore syncpt */
+ 0 67 0x04; /* mpcore general */
+
+ #address-cells = 1;
+ #size-cells = 1;
+
+ ranges = 0x5400 0x5400 0x0400;
+
+ dc@5420 {
+ compatible = nvidia,tegra20-dc;
+ reg = 0x5420 0x0004;
+ interrupts = 0 73 0x04;
+
+ rgb {
+ status = okay;
+ /* Seaboard has 1366x768 */
+ clock = 7060;
+ xres = 1366;
+ yres = 768;
+ left-margin = 58;
+ right-margin = 58;
+ hsync-len = 58;
+ lower-margin = 4;
+ upper-margin = 4;
+ vsync-len = 4;
+ hsync-active-high;
+ nvidia,frame-buffer = 0x2f68;
+ nvidia,bits-per-pixel = 16;
+ nvidia,panel = lcd_panel;
+ };
Perhaps it would be useful to add an extra node for the mode definition,
if only to keep the data separate from that of the rgb node. I know that
there currently are no other properties, but the rgb node was supposed
to define the output or connector. If ever the same needs to be done for
any of the TVO or DSI outputs, more properties may be needed.
Furthermore the code to parse this would be more generic because you
could pass it any DT node. Of course the nvidia,-prefixed properties
wouldn't be part of that subnode because they don't define the mode as
such.
Thinking about it some more, maybe the mode information should really be
part of the panel description below.
OK I will move it there, thanks.
+ };
+};
+
+lcd_panel: panel {
+ nvidia,pwm = pwm 2 0;
+ nvidia,backlight-enable-gpios = gpio 28 0; /* PD4 */
+ nvidia,lvds-shutdown-gpios = gpio 10 0; /* PB2 */
+ nvidia,backlight-vdd-gpios = gpio 176 0; /* PW0 */
+ nvidia,panel-vdd-gpios = gpio 22 0; /* PC6 */
+ nvidia,panel-timings = 4 203 17 15;
+};
If we can reach some kind of agreement on the power-sequencing code that
Alexandre (Cc'ed) is working on, then this can be replaced with a more
generic description. This also has the usual problem of being a non-
addressable top-level node...
Yes, I have been following that. However, it would need quite a bit of
code to be written. I would like to leave this for a future owner if
possible.
Regards,
Simon
Thierry
___
U-Boot mailing list
U-Boot@lists.denx.de
Re: [U-Boot] [PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra
Hi Stephen, On Thu, Sep 27, 2012 at 8:49 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/27/2012 07:58 AM, Simon Glass wrote: Hi Stephen, On Tue, Jul 31, 2012 at 9:12 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 07/31/2012 03:27 AM, Simon Glass wrote: On Thu, Jul 12, 2012 at 4:25 PM, Simon Glass s...@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. OK, but typically the kernel selects its own address for the display. It might be quite hard for the kernel to use the one defined by U-Boot. 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? So here is my explanation: 1. U-Boot would normally put the display right near the top of memory. Instead, it figures out where the kernel will put it (somehow this seems to often be at a fixed address) and uses that address. 2. That means that U-Boot will now have the display exactly where the kernel wants it. 3. When U-Boot boots the kernel, it leaves the display running, knowing that the kernel will not overwrite the frame buffer with its own code / data. 4. The effect is that there is a seamless display transition from U-Boot to the kernel. Note this is only a hint - it can be omitted i.w.c. it isn't used. So what do you think? Should we remove this entirely, or is it a useful hack? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra
On 09/27/2012 02:27 PM, Simon Glass wrote: On Thu, Sep 27, 2012 at 8:49 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/27/2012 07:58 AM, Simon Glass wrote: ... 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? So here is my explanation: 1. U-Boot would normally put the display right near the top of memory. Instead, it figures out where the kernel will put it (somehow this seems to often be at a fixed address) and uses that address. 2. That means that U-Boot will now have the display exactly where the kernel wants it. Oh, the DT property is telling U-Boot where to put the surface so that when the kernel determines where to put it, it'll already be there? That seems completely backwards. It's also extremely fragile; what if the kernel suddenly starts allocating at some other random address, which stops matching what U-Boot expects? Far better would be for U-Boot to put the surface wherever it wants, then manipulate the DT that's passed to the kernel to: a) Add a /memreserve/ so that memory doesn't get re-used for anything else during boot. b) Add a property to the display node indicating which memreserve represents the frame-buffer location. When the kernel boots, it can: * Copy the content from the U-Boot-allocated buffer to whatever display buffer the kernel allocated before writing the new address to the HW. * Undo the memory reservation triggered by the /memreserve/ to allow the memory to be re-used. So what do you think? Should we remove this entirely, or is it a useful hack? Yes, I think in its current form, it isn't useful. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra
Hi Stephen, On Thu, Sep 27, 2012 at 4:21 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/27/2012 02:27 PM, Simon Glass wrote: On Thu, Sep 27, 2012 at 8:49 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/27/2012 07:58 AM, Simon Glass wrote: ... 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? So here is my explanation: 1. U-Boot would normally put the display right near the top of memory. Instead, it figures out where the kernel will put it (somehow this seems to often be at a fixed address) and uses that address. 2. That means that U-Boot will now have the display exactly where the kernel wants it. Oh, the DT property is telling U-Boot where to put the surface so that when the kernel determines where to put it, it'll already be there? That seems completely backwards. It's also extremely fragile; what if the kernel suddenly starts allocating at some other random address, which stops matching what U-Boot expects? The screen will flicker, or may fill up with junk as the kernel boots. We did have that happen once when the driver changed. Far better would be for U-Boot to put the surface wherever it wants, then manipulate the DT that's passed to the kernel to: a) Add a /memreserve/ so that memory doesn't get re-used for anything else during boot. b) Add a property to the display node indicating which memreserve represents the frame-buffer location. Yes, I believe the Tegra video driver we used (and I take your point that it doesn't exist upstream so there is no point in discussing it :-) always had to use the same frame buffer address. The memory was statically allocated. Certainly this could be encoded in the fdt. When the kernel boots, it can: * Copy the content from the U-Boot-allocated buffer to whatever display buffer the kernel allocated before writing the new address to the HW. * Undo the memory reservation triggered by the /memreserve/ to allow the memory to be re-used. So what do you think? Should we remove this entirely, or is it a useful hack? Yes, I think in its current form, it isn't useful. Thanks for the thorough response. Let's remove it, particularly as there isn't even a kernel driver upstream yet. I will do that before sending out the LCD v4 series. Thanks for your timely comments. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra
On Thu, Sep 27, 2012 at 04:37:41PM -0700, Simon Glass wrote: Hi Stephen, On Thu, Sep 27, 2012 at 4:21 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/27/2012 02:27 PM, Simon Glass wrote: On Thu, Sep 27, 2012 at 8:49 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 09/27/2012 07:58 AM, Simon Glass wrote: ... 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? So here is my explanation: 1. U-Boot would normally put the display right near the top of memory. Instead, it figures out where the kernel will put it (somehow this seems to often be at a fixed address) and uses that address. 2. That means that U-Boot will now have the display exactly where the kernel wants it. Oh, the DT property is telling U-Boot where to put the surface so that when the kernel determines where to put it, it'll already be there? That seems completely backwards. It's also extremely fragile; what if the kernel suddenly starts allocating at some other random address, which stops matching what U-Boot expects? The screen will flicker, or may fill up with junk as the kernel boots. We did have that happen once when the driver changed. Far better would be for U-Boot to put the surface wherever it wants, then manipulate the DT that's passed to the kernel to: a) Add a /memreserve/ so that memory doesn't get re-used for anything else during boot. b) Add a property to the display node indicating which memreserve represents the frame-buffer location. Yes, I believe the Tegra video driver we used (and I take your point that it doesn't exist upstream so there is no point in discussing it :-) always had to use the same frame buffer address. The memory was statically allocated. Certainly this could be encoded in the fdt. When the kernel boots, it can: * Copy the content from the U-Boot-allocated buffer to whatever display buffer the kernel allocated before writing the new address to the HW. * Undo the memory reservation triggered by the /memreserve/ to allow the memory to be re-used. So what do you think? Should we remove this entirely, or is it a useful hack? Yes, I think in its current form, it isn't useful. Thanks for the thorough response. Let's remove it, particularly as there isn't even a kernel driver upstream yet. We've been discussing some of these issues for quite some time and came to the conclusion that the Tegra DRM driver should not be using static allocations like the previous drivers did. One of the reasons is that the amount of carveout memory needs to be fixed at boot time, which isn't going to suit a wide range of devices well. Another, perhaps more important reason is that starting with Tegra30 that's no longer necessary because of the SMMU. So in the end it wouldn't be possible to reliably determine the memory area where the kernel will put the framebuffer. If we want a flicker- free boot then we need to go with something more elaborate like what Stephen suggested. Thierry pgp01FiKND58b.pgp Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra
+Thierry
Hi,
On Thu, Jul 12, 2012 at 4:25 PM, Simon Glass s...@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.
Regards,
Simon
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Add nvidia prefix to device tree properties
Changes in v3:
- Add new panel binding to fit with tegra display controller binding
- Bring in proposed tegra display controller binding
- Use displaymode binding for fdt
arch/arm/dts/tegra20.dtsi | 89
doc/device-tree-bindings/video/displaymode.txt | 42 +++
doc/device-tree-bindings/video/tegra20-dc.txt | 89
3 files changed, 220 insertions(+), 0 deletions(-)
create mode 100644 doc/device-tree-bindings/video/displaymode.txt
create mode 100644 doc/device-tree-bindings/video/tegra20-dc.txt
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index e7d1688..0b2ca3b 100644
--- a/arch/arm/dts/tegra20.dtsi
+++ b/arch/arm/dts/tegra20.dtsi
@@ -211,4 +211,93 @@
#pwm-cells = 2;
};
+ host1x {
+ compatible = nvidia,tegra20-host1x, simple-bus;
+ reg = 0x5000 0x00024000;
+ interrupts = 0 65 0x04 /* mpcore syncpt */
+ 0 67 0x04; /* mpcore general */
+
+ #address-cells = 1;
+ #size-cells = 1;
+
+ ranges = 0x5400 0x5400 0x0400;
+
+ /* video-encoding/decoding */
+ mpe {
+ reg = 0x5404 0x0004;
+ interrupts = 0 68 0x04;
+ };
+
+ /* video input */
+ vi {
+ reg = 0x5408 0x0004;
+ interrupts = 0 69 0x04;
+ };
+
+ /* EPP */
+ epp {
+ reg = 0x540c 0x0004;
+ interrupts = 0 70 0x04;
+ };
+
+ /* ISP */
+ isp {
+ reg = 0x5410 0x0004;
+ interrupts = 0 71 0x04;
+ };
+
+ /* 2D engine */
+ gr2d {
+ reg = 0x5414 0x0004;
+ interrupts = 0 72 0x04;
+ };
+
+ /* 3D engine */
+ gr3d {
+ reg = 0x5418 0x0004;
+ };
+
+ /* display controllers */
+ dc@5420 {
+ compatible = nvidia,tegra20-dc;
+ reg = 0x5420 0x0004;
+ interrupts = 0 73 0x04;
+
+ rgb {
+ status = disabled;
+ };
+ };
+
+ dc@5424 {
+ compatible = nvidia,tegra20-dc;
+ reg = 0x5424 0x0004;
+ interrupts = 0 74 0x04;
+
+ rgb {
+ status = disabled;
+ };
+ };
+
+ /* outputs */
+ hdmi {
+ compatible = nvidia,tegra20-hdmi;
+ reg = 0x5428 0x0004;
+ interrupts = 0 75 0x04;
+ status = disabled;
+ };
+
+ tvo {
+ compatible = nvidia,tegra20-tvo;
+ reg = 0x542c 0x0004;
+ interrupts = 0 76 0x04;
+ status = disabled;
+ };
+
+ dsi {
+ compatible = nvidia,tegra20-dsi;
+ reg = 0x5430 0x0004;
+ status = disabled;
+ };
+ };
+
};
diff --git a/doc/device-tree-bindings/video/displaymode.txt
b/doc/device-tree-bindings/video/displaymode.txt
new file mode 100644
index 000..45ca42d
--- /dev/null
+++ b/doc/device-tree-bindings/video/displaymode.txt
@@ -0,0 +1,42 @@
+videomode bindings
+==
+
+(from http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html)
+
+Required properties:
+ - xres, yres: Display resolution
+ - left-margin,
Re: [U-Boot] [PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra
On Tue, Jul 31, 2012 at 10:27:23AM +0100, Simon Glass wrote:
+Thierry
Hi,
On Thu, Jul 12, 2012 at 4:25 PM, Simon Glass s...@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.
There's no such thing as the panel bindings on Linux. I think nobody's
done that before, there's also no suitable software abstraction, but I
suppose that should be irrelevant for this discussion.
+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
+
+
+The panel node describes the panel itself.
+
+Required properties (panel) :
+ - nvidia,pwm : pwm to use to set display contrast (see tegra20-pwm.txt)
+ - nvidia,panel-timings: 4 cells containing required timings in ms:
+ * delay between panel_vdd-rise and data-rise
+ * delay between data-rise and backlight_vdd-rise
+ * delay between backlight_vdd and pwm-rise
+ * delay between pwm-rise and backlight_en-rise
+
+Optional GPIO properies all have (phandle, GPIO number, flags):
+ - nvidia,backlight-enable-gpios: backlight enable GPIO
+ - nvidia,lvds-shutdown-gpios: LVDS power shutdown GPIO
+ - nvidia,backlight-vdd-gpios: backlight power GPIO
+ - nvidia,panel-vdd-gpios: panel power GPIO
+
+Example:
+
+host1x {
+ compatible = nvidia,tegra20-host1x, simple-bus;
+ reg = 0x5000 0x00024000;
+ interrupts = 0 65 0x04 /* mpcore syncpt */
+ 0 67 0x04; /* mpcore general */
+
+ #address-cells = 1;
+ #size-cells = 1;
+
+ ranges = 0x5400 0x5400 0x0400;
+
+ dc@5420 {
+ compatible = nvidia,tegra20-dc;
+ reg = 0x5420 0x0004;
+ interrupts = 0 73 0x04;
+
+ rgb {
+ status = okay;
+ /* Seaboard has 1366x768 */
+ clock = 7060;
+ xres = 1366;
+ yres = 768;
+ left-margin = 58;
+ right-margin = 58;
+ hsync-len = 58;
+ lower-margin = 4;
+ upper-margin = 4;
+ vsync-len = 4;
+ hsync-active-high;
+ nvidia,frame-buffer = 0x2f68;
+ nvidia,bits-per-pixel = 16;
+ nvidia,panel = lcd_panel;
+ };
Perhaps it would be useful to add an extra node for the mode definition,
if only to keep the data separate from that of the rgb node. I know that
there currently are no other properties, but the rgb node was supposed
to define the output or connector. If ever the same needs to be done for
any of the TVO or DSI outputs, more properties may be needed.
Furthermore the code to parse this would be more generic because you
could pass it any DT node. Of course the nvidia,-prefixed properties
wouldn't be part of that subnode because they don't define the mode as
such.
Thinking about it some more, maybe the mode information should really be
part of the panel description below.
+ };
+};
+
+lcd_panel: panel {
+ nvidia,pwm = pwm 2 0;
+ nvidia,backlight-enable-gpios = gpio 28 0; /* PD4 */
+ nvidia,lvds-shutdown-gpios = gpio 10 0; /* PB2 */
+ nvidia,backlight-vdd-gpios = gpio 176 0; /* PW0 */
+ nvidia,panel-vdd-gpios = gpio 22 0; /* PC6 */
+ nvidia,panel-timings = 4 203 17 15;
+};
If we can reach some kind of agreement on the power-sequencing code that
Alexandre (Cc'ed) is working on, then this can be replaced with a more
generic description. This also has the usual problem of being a non-
addressable top-level node...
Thierry
pgpgCdC1yM7kJ.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra
On 07/31/2012 03:27 AM, Simon Glass wrote: On Thu, Jul 12, 2012 at 4:25 PM, Simon Glass s...@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? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 06/18] tegra: fdt: Add LCD definitions for Tegra
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.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Add nvidia prefix to device tree properties
Changes in v3:
- Add new panel binding to fit with tegra display controller binding
- Bring in proposed tegra display controller binding
- Use displaymode binding for fdt
arch/arm/dts/tegra20.dtsi | 89
doc/device-tree-bindings/video/displaymode.txt | 42 +++
doc/device-tree-bindings/video/tegra20-dc.txt | 89
3 files changed, 220 insertions(+), 0 deletions(-)
create mode 100644 doc/device-tree-bindings/video/displaymode.txt
create mode 100644 doc/device-tree-bindings/video/tegra20-dc.txt
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index e7d1688..0b2ca3b 100644
--- a/arch/arm/dts/tegra20.dtsi
+++ b/arch/arm/dts/tegra20.dtsi
@@ -211,4 +211,93 @@
#pwm-cells = 2;
};
+ host1x {
+ compatible = nvidia,tegra20-host1x, simple-bus;
+ reg = 0x5000 0x00024000;
+ interrupts = 0 65 0x04 /* mpcore syncpt */
+ 0 67 0x04; /* mpcore general */
+
+ #address-cells = 1;
+ #size-cells = 1;
+
+ ranges = 0x5400 0x5400 0x0400;
+
+ /* video-encoding/decoding */
+ mpe {
+ reg = 0x5404 0x0004;
+ interrupts = 0 68 0x04;
+ };
+
+ /* video input */
+ vi {
+ reg = 0x5408 0x0004;
+ interrupts = 0 69 0x04;
+ };
+
+ /* EPP */
+ epp {
+ reg = 0x540c 0x0004;
+ interrupts = 0 70 0x04;
+ };
+
+ /* ISP */
+ isp {
+ reg = 0x5410 0x0004;
+ interrupts = 0 71 0x04;
+ };
+
+ /* 2D engine */
+ gr2d {
+ reg = 0x5414 0x0004;
+ interrupts = 0 72 0x04;
+ };
+
+ /* 3D engine */
+ gr3d {
+ reg = 0x5418 0x0004;
+ };
+
+ /* display controllers */
+ dc@5420 {
+ compatible = nvidia,tegra20-dc;
+ reg = 0x5420 0x0004;
+ interrupts = 0 73 0x04;
+
+ rgb {
+ status = disabled;
+ };
+ };
+
+ dc@5424 {
+ compatible = nvidia,tegra20-dc;
+ reg = 0x5424 0x0004;
+ interrupts = 0 74 0x04;
+
+ rgb {
+ status = disabled;
+ };
+ };
+
+ /* outputs */
+ hdmi {
+ compatible = nvidia,tegra20-hdmi;
+ reg = 0x5428 0x0004;
+ interrupts = 0 75 0x04;
+ status = disabled;
+ };
+
+ tvo {
+ compatible = nvidia,tegra20-tvo;
+ reg = 0x542c 0x0004;
+ interrupts = 0 76 0x04;
+ status = disabled;
+ };
+
+ dsi {
+ compatible = nvidia,tegra20-dsi;
+ reg = 0x5430 0x0004;
+ status = disabled;
+ };
+ };
+
};
diff --git a/doc/device-tree-bindings/video/displaymode.txt
b/doc/device-tree-bindings/video/displaymode.txt
new file mode 100644
index 000..45ca42d
--- /dev/null
+++ b/doc/device-tree-bindings/video/displaymode.txt
@@ -0,0 +1,42 @@
+videomode bindings
+==
+
+(from http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html)
+
+Required properties:
+ - xres, yres: Display resolution
+ - left-margin, right-margin, hsync-len: Horizontal Display timing
+ parameters in pixels
+ - upper-margin, lower-margin, vsync-len: Vertical display timing
+ parameters in lines
+ - clock: display clock in Hz
+
+Optional properties:
+ - width-mm, height-mm: Display dimensions in mm
+ - hsync-active-high (bool): Hsync pulse is active high
+ - vsync-active-high (bool): Vsync pulse
