[PATCH v2 02/19] fdt: Add debugging to fdtdec_get_int/addr()

[PATCH v2 02/19] fdt: Add debugging to fdtdec_get_int/addr()

[Simon Glass]

The new debugging shows the value of integers and addresses read
from the device tree.

Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---

 lib/fdtdec.c |   22 ++++++++++++++++------
 1 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index cc09e06..61056f1 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -80,11 +80,16 @@ fdt_addr_t fdtdec_get_addr(const void *blob, int node,
 	const fdt_addr_t *cell;
 	int len;
 
-	debug("get_addr: %s\n", prop_name);
+	debug("%s: %s\n", __func__, prop_name);
 	cell = fdt_getprop(blob, node, prop_name, &len);
 	if (cell && (len == sizeof(fdt_addr_t) ||
-			len == sizeof(fdt_addr_t) * 2))
-		return fdt_addr_to_cpu(*cell);
+			len == sizeof(fdt_addr_t) * 2)) {
+		fdt_addr_t addr = fdt_addr_to_cpu(*cell);
+
+		debug("%p\n", (void *)addr);
+		return addr;
+	}
+	debug("(not found)\n");
 	return FDT_ADDR_T_NONE;
 }
 
@@ -94,10 +99,15 @@ s32 fdtdec_get_int(const void *blob, int node, const char *prop_name,
 	const s32 *cell;
 	int len;
 
-	debug("get_size: %s\n", prop_name);
+	debug("%s: %s: ", __func__, prop_name);
 	cell = fdt_getprop(blob, node, prop_name, &len);
-	if (cell && len >= sizeof(s32))
-		return fdt32_to_cpu(cell[0]);
+	if (cell && len >= sizeof(s32)) {
+		s32 val = fdt32_to_cpu(cell[0]);
+
+		debug("%#x (%d)\n", val, val);
+		return val;
+	}
+	debug("(not found)\n");
 	return default_val;
 }
 
-- 
1.7.7.3

[PATCH v2 03/19] fdt: Add function to look up a phandle's register address

[Simon Glass]

This is a commonly-used requirement, so add a function to support it
easily.

Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---

 include/fdtdec.h |   13 +++++++++++++
 lib/fdtdec.c     |   11 +++++++++++
 2 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index fab577e..d7bef6c 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -276,6 +276,19 @@ const char *fdtdec_get_compatible(enum fdt_compat_id id);
 int fdtdec_lookup_phandle(const void *blob, int node, const char *prop_name);
 
 /**
+ * Look up a phandle and follow it to its node. Then return the register
+ * address of that node as a pointer. This can be used to access the
+ * peripheral directly.
+ *
+ * @param blob		FDT blob
+ * @param node		node to examine
+ * @param prop_name	name of property to find
+ * @return pointer to node's register address
+ */
+void *fdtdec_lookup_phandle_reg(const void *blob, int node,
+		const char *prop_name);
+
+/**
  * Look up a property in a node and return its contents in an integer
  * array of given length. The property must have at least enough data for
  * the array (4*count bytes). It may have more, but this will be ignored.
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 61056f1..8185d8f 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -347,6 +347,17 @@ int fdtdec_lookup_phandle(const void *blob, int node, const char *prop_name)
 	return lookup;
 }
 
+void *fdtdec_lookup_phandle_reg(const void *blob, int node,
+		const char *prop_name)
+{
+	int lookup;
+
+	lookup = fdtdec_lookup_phandle(blob, node, prop_name);
+	if (lookup < 0)
+		return NULL;
+	return (void *)fdtdec_get_addr(blob, lookup, "reg");
+}
+
 /**
  * Look up a property in a node and check that it has a minimum length.
  *
-- 
1.7.7.3

[PATCH v2 04/19] fdt: Add header guard to fdtdec.h

[Simon Glass]

This makes it easier to include this header from other headers.

Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---

 include/fdtdec.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index d7bef6c..627d077 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -19,6 +19,8 @@
  * MA 02111-1307 USA
  */
 
+#ifndef __fdtdec_h
+#define __fdtdec_h
 
 /*
  * This file contains convenience functions for decoding useful and
@@ -395,3 +397,4 @@ int fdtdec_get_byte_array(const void *blob, int node, const char *prop_name,
  */
 const u8 *fdtdec_locate_byte_array(const void *blob, int node,
 			     const char *prop_name, int count);
+#endif
-- 
1.7.7.3

[PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra

[Simon Glass]

Add LCD definitions and also a proposed binding for LCD displays.

The PWFM is in progress on the device-tree-discuss list, so only a
very basic binding is offered here.

I am not sure if it is better to have the lcd within the display
controller as with i2c/spi, or a separate node. From a hardware point
of view the LCD is certainly connected to the display controller, so
perhaps this version makes most sense. We could have a stand-alone
top-level lcd node with a phandle pointing to the display controller,
but these doesn't seem to be an obvious advantage to that approach.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Add nvidia prefix to device tree properties

 arch/arm/dts/tegra20.dtsi                       |   25 +++++++
 doc/device-tree-bindings/video/nvidia-video.txt |   88 +++++++++++++++++++++++
 2 files changed, 113 insertions(+), 0 deletions(-)
 create mode 100644 doc/device-tree-bindings/video/nvidia-video.txt

diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index f95be58..4e59e9b 100644
--- a/arch/arm/dts/tegra20.dtsi
+++ b/arch/arm/dts/tegra20.dtsi
@@ -204,4 +204,29 @@
 		compatible = "nvidia,tegra20-kbc";
 		reg = <0x7000e200 0x0078>;
 	};
+
+	pwfm0: pwm@7000a000 {
+		compatible = "nvidia,tegra20-pwfm";
+		reg = <0x7000a000 0x4>;
+	};
+
+	pwfm1: pwm@7000a010 {
+		compatible = "nvidia,tegra20-pwfm";
+		reg = <0x7000a010 0x4>;
+	};
+
+	pwfm2: pwm@7000a020 {
+		compatible = "nvidia,tegra20-pwfm";
+		reg = <0x7000a020 0x4>;
+	};
+
+	pwfm3: pwm@7000a030 {
+		compatible = "nvidia,tegra20-pwfm";
+		reg = <0x7000a030 0x4>;
+	};
+
+	display1: display@0x54200000 {
+		compatible = "nvidia,tegra20-display";
+		reg = <0x54200000 0x40000>;
+	};
 };
diff --git a/doc/device-tree-bindings/video/nvidia-video.txt b/doc/device-tree-bindings/video/nvidia-video.txt
new file mode 100644
index 0000000..2e1b999
--- /dev/null
+++ b/doc/device-tree-bindings/video/nvidia-video.txt
@@ -0,0 +1,88 @@
+LCD Display
+-----------
+
+(there isn't yet a generic binding in Linux, so this describes what is in
+U-Boot)
+
+The device node for a display device is as described in the document
+"Open Firmware Recommended Practice : Universal Serial Bus" with the
+following modifications and additions :
+
+Required properties :
+ - compatible : Should be "nvidia,tegra20-display"
+ - nvidia,pwfm: phandle of PWFM to use for backlight
+
+Note: This is just a phande and provides no information, nor a backlight
+node. The PWM is still under discussion I think:
+	http://patchwork.ozlabs.org/patch/132386/
+
+We don't support any parameters as yet - the setting is hard-coded.
+
+ - nvidia,width: width of display in pixels
+ - nvidia,height: height of display in pixels
+ - nvidia,bits-per-pixel: number of bits per pixel (depth)
+ - nvidia,pixel-clock : Pixel clock in Hz
+ - nvidia,horiz-timing; horizontal timing: ref_to_sync, sync_width. back_porch,
+	front_porch
+ - nvidia,vert-timing; vertical timing: ref_to_sync, sync_width. back_porch,
+	front_porch
+
+This node should sit inside its controller.
+
+
+Nvidia Tegra2x Display Controller
+---------------------------------
+
+The device node for a NAND flash controller is as described in the document
+"Open Firmware Recommended Practice : Universal Serial Bus" with the
+following modifications and additions :
+
+Required properties:
+ - compatible: should be "tegra20-display"
+ - 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
+
+(should we use us here, or perhaps call it panel-timings-ms?)
+
+Optional properties:
+ - 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
+
+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
+
+(Perhap use polariy bit so that lvds-shutdown becomes lvds-enable?)
+
+I have put these into the display controller since I don't think they are
+generic enough to go in the lcd node.
+
+Example:
+
+display@0x54200000 {
+	nvidia,pwfm = <&pwfm2>;
+	nvidia,frame-buffer = <0x2f680000>;
+	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>;
+
+	lcd {
+		compatible = "nvidia,lcd";
+		nvidia,width = <1366>;
+		nvidia,height = <768>;
+		nvidia,bits-per-pixel = <16>;
+		nvidia,pixel-clock = <70600000>;
+
+		nvidia,horiz-timing = <11 58 58 58>;
+		nvidia,vert-timing = <1 4 4 4>;
+	};
+};
-- 
1.7.7.3

[PATCH v2 17/19] tegra: fdt: Add LCD definitions for Seaboard

[Simon Glass]

The Seaboard has a 1366x768 16bpp LCD. The backlight is controlled
by one of the PWMs.

Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
Changes in v2:
- Update seaboard LCD definitions for new fdt binding

 board/nvidia/dts/tegra2-seaboard.dts |   21 +++++++++++++++++++++
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/board/nvidia/dts/tegra2-seaboard.dts b/board/nvidia/dts/tegra2-seaboard.dts
index 3352539..3b16f84 100644
--- a/board/nvidia/dts/tegra2-seaboard.dts
+++ b/board/nvidia/dts/tegra2-seaboard.dts
@@ -153,4 +153,25 @@
 			0x1f04008a>;
 		linux,fn-keymap = <0x05040002>;
 	};
+
+	display@0x54200000 {
+		nvidia,pwfm = <&pwfm2>;
+		nvidia,frame-buffer = <0x2f680000>;
+		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>;
+
+		lcd {
+			compatible = "nvidia,lcd";
+			nvidia,width = <1366>;
+			nvidia,height = <768>;
+			nvidia,bits-per-pixel = <16>;
+			nvidia,pixel-clock = <70600000>;
+
+			nvidia,horiz-timing = <11 58 58 58>;
+			nvidia,vert-timing = <1 4 4 4>;
+		};
+	};
 };
-- 
1.7.7.3

Re: [PATCH v2 03/19] fdt: Add function to look up a phandle's register address

[Stephen Warren]

On 06/13/2012 10:19 AM, Simon Glass wrote:
> This is a commonly-used requirement, so add a function to support it
> easily.

Uggh. Why would this ever be needed; shouldn't the driver for the node
referenced by the phandle fully control its own registers; why would any
other driver randomly trample on them?

Re: [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra

[Stephen Warren]

On 06/13/2012 10:19 AM, Simon Glass wrote:
> Add LCD definitions and also a proposed binding for LCD displays.
> 
> The PWFM is in progress on the device-tree-discuss list, so only a
> very basic binding is offered here.

I believe we have settled on a final representation, it just hasn't been
added into linux-next yet. See:

http://gitorious.org/linux-pwm/linux-pwm/commit/d3ce73e5dc86646a6302f2b0f7dd40e8c552fa04

> I am not sure if it is better to have the lcd within the display
> controller as with i2c/spi, or a separate node. From a hardware point
> of view the LCD is certainly connected to the display controller, so
> perhaps this version makes most sense. We could have a stand-alone
> top-level lcd node with a phandle pointing to the display controller,
> but these doesn't seem to be an obvious advantage to that approach.

Equally, there's been extensive discussion re: how to represent the
NVIDIA display controller in DT. I strongly believe that U-Boot
shouldn't go ahead in isolation with a binding that's completely
unrelated to what's happening in the kernel. Please can you take what
Thierry is working on for the kernel, and/or contribute to that binding
etc., so we don't end up with multiple ways of doing the same thing.
Part of the whole point of DT is to have a single way of representing HW
that multiple OSs (or perhaps bootloaders) cna use. If everyone just
goes and does their own thing, we've lost.

Re: [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra

[Simon Glass]

[-- Attachment #1.1: Type: text/plain, Size: 2091 bytes --]

Hi Stephen,

On Fri, Jun 15, 2012 at 1:32 AM, Stephen Warren <swarren@wwwdotorg.org>wrote:

> On 06/13/2012 10:19 AM, Simon Glass wrote:
> > Add LCD definitions and also a proposed binding for LCD displays.
> >
> > The PWFM is in progress on the device-tree-discuss list, so only a
> > very basic binding is offered here.
>
> I believe we have settled on a final representation, it just hasn't been
> added into linux-next yet. See:
>
>
> http://gitorious.org/linux-pwm/linux-pwm/commit/d3ce73e5dc86646a6302f2b0f7dd40e8c552fa04


Thanks for the pointer. I suppose this doesn't address clocks as yet, but
that's fine.


>
>
> > I am not sure if it is better to have the lcd within the display
> > controller as with i2c/spi, or a separate node. From a hardware point
> > of view the LCD is certainly connected to the display controller, so
> > perhaps this version makes most sense. We could have a stand-alone
> > top-level lcd node with a phandle pointing to the display controller,
> > but these doesn't seem to be an obvious advantage to that approach.
>
> Equally, there's been extensive discussion re: how to represent the
> NVIDIA display controller in DT. I strongly believe that U-Boot
> shouldn't go ahead in isolation with a binding that's completely
> unrelated to what's happening in the kernel. Please can you take what
> Thierry is working on for the kernel, and/or contribute to that binding
> etc., so we don't end up with multiple ways of doing the same thing.
> Part of the whole point of DT is to have a single way of representing HW
> that multiple OSs (or perhaps bootloaders) cna use. If everyone just
> goes and does their own thing, we've lost.
>

I can see the email here.

http://lists.freedesktop.org/archives/dri-devel/2012-April/021223.html

I posted this series originally in January. That email is from April, and I
don't see activity in the last 2 months. As previously discussed it is not
productive to chase a moving target.

Thierry, have you settled on a binding yet? If not do you have something
sort-of close that I could use in U-Boot?

Regards.
Simon

[-- Attachment #2: Type: text/plain, Size: 134 bytes --]

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [PATCH v2 03/19] fdt: Add function to look up a phandle's register address

[Simon Glass]

[-- Attachment #1.1: Type: text/plain, Size: 741 bytes --]

Hi Stephen,

On Fri, Jun 15, 2012 at 1:17 AM, Stephen Warren <swarren@wwwdotorg.org>wrote:

> On 06/13/2012 10:19 AM, Simon Glass wrote:
> > This is a commonly-used requirement, so add a function to support it
> > easily.
>
> Uggh. Why would this ever be needed; shouldn't the driver for the node
> referenced by the phandle fully control its own registers; why would any
> other driver randomly trample on them?
>

You are making assumptions. This is used for the pwm and only accessed by
the pwm driver.

It's basically to allow a simple and efficient way of getting access to a
peripheral. Since the new binding you pointed me to uses a single pwm with
multiple channels, this doesn't offer any benefit so I will punt it.

Regards,
Simon

[-- Attachment #2: Type: text/plain, Size: 134 bytes --]

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 3832 bytes --]

On Wed, Jul 11, 2012 at 06:44:10AM +0200, Simon Glass wrote:
> Hi Stephen,
> 
> On Fri, Jun 15, 2012 at 1:32 AM, Stephen Warren <swarren@wwwdotorg.org>wrote:
> 
> > On 06/13/2012 10:19 AM, Simon Glass wrote:
> > > Add LCD definitions and also a proposed binding for LCD displays.
> > >
> > > The PWFM is in progress on the device-tree-discuss list, so only a
> > > very basic binding is offered here.
> >
> > I believe we have settled on a final representation, it just hasn't been
> > added into linux-next yet. See:
> >
> >
> > http://gitorious.org/linux-pwm/linux-pwm/commit/d3ce73e5dc86646a6302f2b0f7dd40e8c552fa04
> 
> 
> Thanks for the pointer. I suppose this doesn't address clocks as yet, but
> that's fine.

I was waiting for the common clock framework and DT bindings to get
ready. This should happen RSN for Tegra so I will probably look at
adding support for it in.

By the way, the PWM tree has now been in linux-next for a couple of
weeks and I plan to submit it for inclusion in 3.6.

> > > I am not sure if it is better to have the lcd within the display
> > > controller as with i2c/spi, or a separate node. From a hardware point
> > > of view the LCD is certainly connected to the display controller, so
> > > perhaps this version makes most sense. We could have a stand-alone
> > > top-level lcd node with a phandle pointing to the display controller,
> > > but these doesn't seem to be an obvious advantage to that approach.
> >
> > Equally, there's been extensive discussion re: how to represent the
> > NVIDIA display controller in DT. I strongly believe that U-Boot
> > shouldn't go ahead in isolation with a binding that's completely
> > unrelated to what's happening in the kernel. Please can you take what
> > Thierry is working on for the kernel, and/or contribute to that binding
> > etc., so we don't end up with multiple ways of doing the same thing.
> > Part of the whole point of DT is to have a single way of representing HW
> > that multiple OSs (or perhaps bootloaders) cna use. If everyone just
> > goes and does their own thing, we've lost.
> >
> 
> I can see the email here.
> 
> http://lists.freedesktop.org/archives/dri-devel/2012-April/021223.html
> 
> I posted this series originally in January. That email is from April, and I
> don't see activity in the last 2 months. As previously discussed it is not
> productive to chase a moving target.

I had hoped I could get this finished much faster, but then things
happened. However there has been quite some progress in the meantime.

I actually based that very first version on what you had in the earlier
Tegra LCD series with a couple of additions to support DRM
specificities. However the proposal was shot down pretty early mainly
because the display timing description was very Tegra specific. One
proposal was to include an EDID blob directly into the DT and pass it on
to DRM, which is what the current code does.

Lately there's been some work on adding a generic description for
display timings:

	http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html

I haven't tested that code yet, but it might turn out to be an
interesting replacement for the EDID blob.

> Thierry, have you settled on a binding yet? If not do you have something
> sort-of close that I could use in U-Boot?

The currently accepted form (as in "Stephen said it looks reasonable")
is here:

	http://lists.freedesktop.org/archives/dri-devel/2012-July/024899.html

It currently only defines the bindings for the RGB and HDMI outputs, but
that should be fine since from what I can tell your U-Boot driver
supports RGB only anyway. It is probably also way more than you really
need in U-Boot because it has DT nodes for all the graphics-related
modules.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 134 bytes --]

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra

[Simon Glass]

Hi Thierry,

On Wed, Jul 11, 2012 at 7:48 AM, Thierry Reding
<thierry.reding@avionic-design.de> wrote:
> On Wed, Jul 11, 2012 at 06:44:10AM +0200, Simon Glass wrote:
>> Hi Stephen,
>>
>> On Fri, Jun 15, 2012 at 1:32 AM, Stephen Warren <swarren@wwwdotorg.org>wrote:
>>
>> > On 06/13/2012 10:19 AM, Simon Glass wrote:
>> > > Add LCD definitions and also a proposed binding for LCD displays.
>> > >
>> > > The PWFM is in progress on the device-tree-discuss list, so only a
>> > > very basic binding is offered here.
>> >
>> > I believe we have settled on a final representation, it just hasn't been
>> > added into linux-next yet. See:
>> >
>> >
>> > http://gitorious.org/linux-pwm/linux-pwm/commit/d3ce73e5dc86646a6302f2b0f7dd40e8c552fa04
>>
>>
>> Thanks for the pointer. I suppose this doesn't address clocks as yet, but
>> that's fine.
>
> I was waiting for the common clock framework and DT bindings to get
> ready. This should happen RSN for Tegra so I will probably look at
> adding support for it in.

OK, are you looking at adding it in U-Boot?

>
> By the way, the PWM tree has now been in linux-next for a couple of
> weeks and I plan to submit it for inclusion in 3.6.

Yes Stephen pointed me to that so I picked it up, thanks.

>
>> > > I am not sure if it is better to have the lcd within the display
>> > > controller as with i2c/spi, or a separate node. From a hardware point
>> > > of view the LCD is certainly connected to the display controller, so
>> > > perhaps this version makes most sense. We could have a stand-alone
>> > > top-level lcd node with a phandle pointing to the display controller,
>> > > but these doesn't seem to be an obvious advantage to that approach.
>> >
>> > Equally, there's been extensive discussion re: how to represent the
>> > NVIDIA display controller in DT. I strongly believe that U-Boot
>> > shouldn't go ahead in isolation with a binding that's completely
>> > unrelated to what's happening in the kernel. Please can you take what
>> > Thierry is working on for the kernel, and/or contribute to that binding
>> > etc., so we don't end up with multiple ways of doing the same thing.
>> > Part of the whole point of DT is to have a single way of representing HW
>> > that multiple OSs (or perhaps bootloaders) cna use. If everyone just
>> > goes and does their own thing, we've lost.
>> >
>>
>> I can see the email here.
>>
>> http://lists.freedesktop.org/archives/dri-devel/2012-April/021223.html
>>
>> I posted this series originally in January. That email is from April, and I
>> don't see activity in the last 2 months. As previously discussed it is not
>> productive to chase a moving target.
>
> I had hoped I could get this finished much faster, but then things
> happened. However there has been quite some progress in the meantime.
>
> I actually based that very first version on what you had in the earlier
> Tegra LCD series with a couple of additions to support DRM
> specificities. However the proposal was shot down pretty early mainly
> because the display timing description was very Tegra specific. One
> proposal was to include an EDID blob directly into the DT and pass it on
> to DRM, which is what the current code does.
>
> Lately there's been some work on adding a generic description for
> display timings:
>
>         http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html
>
> I haven't tested that code yet, but it might turn out to be an
> interesting replacement for the EDID blob.

Yes I prefer it, it is much easier to see what is going on. I will put
something together based on that.

>
>> Thierry, have you settled on a binding yet? If not do you have something
>> sort-of close that I could use in U-Boot?
>
> The currently accepted form (as in "Stephen said it looks reasonable")
> is here:
>
>         http://lists.freedesktop.org/archives/dri-devel/2012-July/024899.html
>
> It currently only defines the bindings for the RGB and HDMI outputs, but
> that should be fine since from what I can tell your U-Boot driver
> supports RGB only anyway. It is probably also way more than you really
> need in U-Boot because it has DT nodes for all the graphics-related
> modules.

I also need a place to put the pwm and GPIOs for the panel itself.
Something like this:

		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>;  (number of ms before turning
on the next gpio)
		nvidia,bits-per-pixel = <16>;    (er, TBD)

I am thinking of something like a phandle in your rgb node:

	host1x {
		dc@54200000 {
			rgb {
				nvidia-panel = <&lcd_panel>;
...

	lcd_panel: panel {
		nvidia,pwm = <&pwm 2 0>;
                ...
        }

Or have you already solved this problem another way?

Regards,
Simon

>
> Thierry

Re: [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 2872 bytes --]

On Thu, Jul 12, 2012 at 10:21:01AM +0200, Simon Glass wrote:
> Hi Thierry,
> 
> On Wed, Jul 11, 2012 at 7:48 AM, Thierry Reding
> <thierry.reding@avionic-design.de> wrote:
> > On Wed, Jul 11, 2012 at 06:44:10AM +0200, Simon Glass wrote:
> >> Hi Stephen,
> >>
> >> On Fri, Jun 15, 2012 at 1:32 AM, Stephen Warren <swarren@wwwdotorg.org>wrote:
> >>
> >> > On 06/13/2012 10:19 AM, Simon Glass wrote:
> >> > > Add LCD definitions and also a proposed binding for LCD displays.
> >> > >
> >> > > The PWFM is in progress on the device-tree-discuss list, so only a
> >> > > very basic binding is offered here.
> >> >
> >> > I believe we have settled on a final representation, it just hasn't been
> >> > added into linux-next yet. See:
> >> >
> >> >
> >> > http://gitorious.org/linux-pwm/linux-pwm/commit/d3ce73e5dc86646a6302f2b0f7dd40e8c552fa04
> >>
> >>
> >> Thanks for the pointer. I suppose this doesn't address clocks as yet, but
> >> that's fine.
> >
> > I was waiting for the common clock framework and DT bindings to get
> > ready. This should happen RSN for Tegra so I will probably look at
> > adding support for it in.
> 
> OK, are you looking at adding it in U-Boot?

No. I don't have much time to spend on U-Boot right now.

[...]
> I also need a place to put the pwm and GPIOs for the panel itself.
> Something like this:
> 
> 		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>;  (number of ms before turning
> on the next gpio)
> 		nvidia,bits-per-pixel = <16>;    (er, TBD)
> 
> I am thinking of something like a phandle in your rgb node:
> 
> 	host1x {
> 		dc@54200000 {
> 			rgb {
> 				nvidia-panel = <&lcd_panel>;
> ...
> 
> 	lcd_panel: panel {
> 		nvidia,pwm = <&pwm 2 0>;
>                 ...
>         }
> 
> Or have you already solved this problem another way?

Linux has a generic PWM backlight driver. This is currently solved by
using this in the DT:

	backlight {
		compatible = "pwm-backlight";
		pwms = <&pwm 0 5000000>;

		brightness-levels = <0 4 8 16 32 64 128 255>;
		default-brightness-level = <6>;
	};

Alex Courbot (Cc'd) has been working on adding a generic way to add GPIO
and regulator support to that. I don't know exactly what the
lvds-shutdown-gpios and panel-vdd-gpios properties do. If they control
hardware connected behind the display controller I suppose they could go
into the rgb node.

The panel alternative that you propose sounds interesting as well. Maybe
the panel should itself contain either a phandle or a subnode for the
backlight and collect the properties that you listed above.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 134 bytes --]

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra

[Alex Courbot]

On Thu 12 Jul 2012 05:40:51 PM JST, Thierry Reding wrote:
> Linux has a generic PWM backlight driver. This is currently solved by
> using this in the DT:
>
> 	backlight {
> 		compatible = "pwm-backlight";
> 		pwms = <&pwm 0 5000000>;
>
> 		brightness-levels = <0 4 8 16 32 64 128 255>;
> 		default-brightness-level = <6>;
> 	};
>
> Alex Courbot (Cc'd) has been working on adding a generic way to add GPIO
> and regulator support to that. I don't know exactly what the
> lvds-shutdown-gpios and panel-vdd-gpios properties do. If they control
> hardware connected behind the display controller I suppose they could go
> into the rgb node.

Thanks for bringing that back to light - the patches did not receive any 
feedback so far. If Simon wants to have a look, the one in the series 
that touches the device tree is here: https://lkml.org/lkml/2012/7/9/30

The idea is to extend pwm-backlight to support the GPIOs and regulators 
that may be related to the backlight, and order them into proper power 
sequences that were so far done by callbacks in board files. So your 
nvidia,pwm , nvidia,backlight-enable-gpios and 
nvidia,backlight-vdd-gpios properties would be moved into the backlight 
node and their appropriate power sequences (including any delay required 
by the panel specification) would be written.

Actually, the power sequences code is independent from the backlight and 
could be used in other areas as well. Looking at your panel node, which 
also uses gpios and has a timings table, it might make sense to use them 
there as well.

> The panel alternative that you propose sounds interesting as well. Maybe
> the panel should itself contain either a phandle or a subnode for the
> backlight and collect the properties that you listed above.

The panel and backlight should definitely be connected in some way. But 
since they are controlled independantly, I'm not sure about the 
implications of having them represented hierarchically in the DT.

Alex.

-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------