* [U-Boot] [PATCH v2 01/19] Add gpio_request() to asm-generic header
2012-06-13 16:19 [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Simon Glass
@ 2012-06-13 16:19 ` Simon Glass
2012-09-21 19:30 ` Anatolij Gustschin
2012-06-13 16:19 ` [U-Boot] [PATCH v2 05/19] tegra: Use const for pinmux_config_pingroup/table() Simon Glass
` (15 subsequent siblings)
16 siblings, 1 reply; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: u-boot
This function should also be part of the GPIO API, so add it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
include/asm-generic/gpio.h | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index c19e16c..23c9649 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -94,4 +94,13 @@ int gpio_get_value(unsigned gpio);
*/
int gpio_set_value(unsigned gpio, int value);
+/**
+ * Request a gpio. This should be called before any of the other functions
+ * are used on this gpio.
+ *
+ * @param gp GPIO number
+ * @param label User label for this GPIO
+ * @return 0 if ok, -1 on error
+ */
+int gpio_request(unsigned gpio, const char *label);
#endif /* _ASM_GENERIC_GPIO_H_ */
--
1.7.7.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 01/19] Add gpio_request() to asm-generic header
2012-06-13 16:19 ` [U-Boot] [PATCH v2 01/19] Add gpio_request() to asm-generic header Simon Glass
@ 2012-09-21 19:30 ` Anatolij Gustschin
2012-09-27 20:58 ` Simon Glass
0 siblings, 1 reply; 67+ messages in thread
From: Anatolij Gustschin @ 2012-09-21 19:30 UTC (permalink / raw)
To: u-boot
Hi Simon,
On Wed, 13 Jun 2012 09:19:37 -0700
Simon Glass <sjg@chromium.org> wrote:
> This function should also be part of the GPIO API, so add it.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> include/asm-generic/gpio.h | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
Applied to staging/agust at denx.de.
Thanks,
Anatolij
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 01/19] Add gpio_request() to asm-generic header
2012-09-21 19:30 ` Anatolij Gustschin
@ 2012-09-27 20:58 ` Simon Glass
0 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-09-27 20:58 UTC (permalink / raw)
To: u-boot
Hi Anatolij,
On Fri, Sep 21, 2012 at 12:30 PM, Anatolij Gustschin <agust@denx.de> wrote:
> Hi Simon,
>
> On Wed, 13 Jun 2012 09:19:37 -0700
> Simon Glass <sjg@chromium.org> wrote:
>
>> This function should also be part of the GPIO API, so add it.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> ---
>>
>> include/asm-generic/gpio.h | 9 +++++++++
>> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> Applied to staging/agust at denx.de.
Thanks. I'm sorry to say that another patch has already done this (and
done a better job). It isn't particularly important, but you could
revert this since the code already exists at the top of the file.
Sorry I didn't spot this earlier - I think the patch was on the
mailing list but not merged.
Regards,
Simon
>
> Thanks,
> Anatolij
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 05/19] tegra: Use const for pinmux_config_pingroup/table()
2012-06-13 16:19 [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 01/19] Add gpio_request() to asm-generic header Simon Glass
@ 2012-06-13 16:19 ` Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 06/19] tegra: Add display support to funcmux Simon Glass
` (14 subsequent siblings)
16 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: u-boot
These two functions don't actually modify their arguments so add a const
keyword.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Add new patch to use const in pinmux_config_pingroup/table()
arch/arm/cpu/armv7/tegra2/pinmux.c | 4 ++--
arch/arm/include/asm/arch-tegra2/pinmux.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/cpu/armv7/tegra2/pinmux.c b/arch/arm/cpu/armv7/tegra2/pinmux.c
index b053f90..bf6d40d 100644
--- a/arch/arm/cpu/armv7/tegra2/pinmux.c
+++ b/arch/arm/cpu/armv7/tegra2/pinmux.c
@@ -554,7 +554,7 @@ void pinmux_set_func(enum pmux_pingrp pin, enum pmux_func func)
writel(reg, muxctl);
}
-void pinmux_config_pingroup(struct pingroup_config *config)
+void pinmux_config_pingroup(const struct pingroup_config *config)
{
enum pmux_pingrp pin = config->pingroup;
@@ -563,7 +563,7 @@ void pinmux_config_pingroup(struct pingroup_config *config)
pinmux_set_tristate(pin, config->tristate);
}
-void pinmux_config_table(struct pingroup_config *config, int len)
+void pinmux_config_table(const struct pingroup_config *config, int len)
{
int i;
diff --git a/arch/arm/include/asm/arch-tegra2/pinmux.h b/arch/arm/include/asm/arch-tegra2/pinmux.h
index 469d742..13ee790 100644
--- a/arch/arm/include/asm/arch-tegra2/pinmux.h
+++ b/arch/arm/include/asm/arch-tegra2/pinmux.h
@@ -339,7 +339,7 @@ void pinmux_set_pullupdown(enum pmux_pingrp pin, enum pmux_pull pupd);
void pinmux_set_func(enum pmux_pingrp pin, enum pmux_func func);
/* Set the complete configuration for a pin group */
-void pinmux_config_pingroup(struct pingroup_config *config);
+void pinmux_config_pingroup(const struct pingroup_config *config);
void pinmux_set_tristate(enum pmux_pingrp pin, int enable);
@@ -349,6 +349,6 @@ void pinmux_set_tristate(enum pmux_pingrp pin, int enable);
* @param config List of config items
* @param len Number of config items in list
*/
-void pinmux_config_table(struct pingroup_config *config, int len);
+void pinmux_config_table(const struct pingroup_config *config, int len);
#endif /* PINMUX_H */
--
1.7.7.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 06/19] tegra: Add display support to funcmux
2012-06-13 16:19 [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 01/19] Add gpio_request() to asm-generic header Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 05/19] tegra: Use const for pinmux_config_pingroup/table() Simon Glass
@ 2012-06-13 16:19 ` Simon Glass
2012-06-14 23:24 ` Stephen Warren
2012-06-13 16:19 ` [U-Boot] " Simon Glass
` (13 subsequent siblings)
16 siblings, 1 reply; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: u-boot
Add support for a default pin mapping for display1.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Use const where possible in funcmux
arch/arm/cpu/armv7/tegra2/funcmux.c | 39 +++++++++++++++++++++++++++++++++++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/arm/cpu/armv7/tegra2/funcmux.c b/arch/arm/cpu/armv7/tegra2/funcmux.c
index 0ef7753..9a339cd 100644
--- a/arch/arm/cpu/armv7/tegra2/funcmux.c
+++ b/arch/arm/cpu/armv7/tegra2/funcmux.c
@@ -25,6 +25,31 @@
#include <asm/arch/funcmux.h>
#include <asm/arch/pinmux.h>
+/*
+ * The PINMUX macro is used to set up pinmux tables.
+ */
+#define PINMUX(grp, mux, pupd, tri) \
+ {PINGRP_##grp, PMUX_FUNC_##mux, PMUX_PULL_##pupd, PMUX_TRI_##tri}
+
+static const struct pingroup_config disp1_default[] = {
+ PINMUX(LDI, DISPA, NORMAL, NORMAL),
+ PINMUX(LHP0, DISPA, NORMAL, NORMAL),
+ PINMUX(LHP1, DISPA, NORMAL, NORMAL),
+ PINMUX(LHP2, DISPA, NORMAL, NORMAL),
+ PINMUX(LHS, DISPA, NORMAL, NORMAL),
+ PINMUX(LM0, RSVD4, NORMAL, NORMAL),
+ PINMUX(LPP, DISPA, NORMAL, NORMAL),
+ PINMUX(LPW0, DISPA, NORMAL, NORMAL),
+ PINMUX(LPW1, RSVD4, NORMAL, TRISTATE),
+ PINMUX(LPW2, DISPA, NORMAL, NORMAL),
+ PINMUX(LSC0, DISPA, NORMAL, NORMAL),
+ PINMUX(LSPI, DISPA, NORMAL, NORMAL),
+ PINMUX(LVP1, DISPA, NORMAL, NORMAL),
+ PINMUX(LVS, DISPA, NORMAL, NORMAL),
+ PINMUX(SLXD, SPDIF, NORMAL, NORMAL),
+};
+
+
int funcmux_select(enum periph_id id, int config)
{
int bad_config = config != FUNCMUX_DEFAULT;
@@ -185,6 +210,20 @@ int funcmux_select(enum periph_id id, int config)
break;
}
+ case PERIPH_ID_DISP1:
+ if (config == FUNCMUX_DEFAULT) {
+ int i;
+
+ for (i = PINGRP_LD0; i <= PINGRP_LD17; i++) {
+ pinmux_set_func(i, PMUX_FUNC_DISPA);
+ pinmux_tristate_disable(i);
+ pinmux_set_pullupdown(i, PMUX_PULL_NORMAL);
+ }
+ pinmux_config_table(disp1_default,
+ ARRAY_SIZE(disp1_default));
+ }
+ break;
+
default:
debug("%s: invalid periph_id %d", __func__, id);
return -1;
--
1.7.7.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 06/19] tegra: Add display support to funcmux
2012-06-13 16:19 ` [U-Boot] [PATCH v2 06/19] tegra: Add display support to funcmux Simon Glass
@ 2012-06-14 23:24 ` Stephen Warren
2012-07-11 3:48 ` Simon Glass
0 siblings, 1 reply; 67+ messages in thread
From: Stephen Warren @ 2012-06-14 23:24 UTC (permalink / raw)
To: u-boot
On 06/13/2012 10:19 AM, Simon Glass wrote:
> Add support for a default pin mapping for display1.
> +static const struct pingroup_config disp1_default[] = {
> + PINMUX(LM0, RSVD4, NORMAL, NORMAL),
> + PINMUX(LPW1, RSVD4, NORMAL, TRISTATE),
Do you really need to explicitly program these pingroups that aren't
used by display? It seems like it'll probably still work fine
irrespective of whether those are actually configured to output display
controller signals or not. However, if those pingroups are used by
something else, then changing their configuration here may stop the
other functionality from working.
> + PINMUX(SLXD, SPDIF, NORMAL, NORMAL),
Similarly here, yet SLXD doesn't ever support any display functionality,
so there should definitely be no need for this entry.
> @@ -185,6 +210,20 @@ int funcmux_select(enum periph_id id, int config)
> + case PERIPH_ID_DISP1:
> + if (config == FUNCMUX_DEFAULT) {
Shouldn't this option have some kind of name in funcmux.h; there are
many many many possible configurations for display, so just assuming
this as some kind of default seems a little presumptuous.
But, given the number of possibilities, I wonder if it isn't time to
replace funcmux with the device tree pinctrl bindings?
^ permalink raw reply [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 06/19] tegra: Add display support to funcmux
2012-06-14 23:24 ` Stephen Warren
@ 2012-07-11 3:48 ` Simon Glass
0 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-07-11 3:48 UTC (permalink / raw)
To: u-boot
Hi Stephen,
On Fri, Jun 15, 2012 at 1:24 AM, Stephen Warren <swarren@wwwdotorg.org>wrote:
> On 06/13/2012 10:19 AM, Simon Glass wrote:
> > Add support for a default pin mapping for display1.
>
> > +static const struct pingroup_config disp1_default[] = {
> > + PINMUX(LM0, RSVD4, NORMAL, NORMAL),
> > + PINMUX(LPW1, RSVD4, NORMAL, TRISTATE),
>
> Do you really need to explicitly program these pingroups that aren't
> used by display? It seems like it'll probably still work fine
> irrespective of whether those are actually configured to output display
> controller signals or not. However, if those pingroups are used by
> something else, then changing their configuration here may stop the
> other functionality from working.
>
> > + PINMUX(SLXD, SPDIF, NORMAL, NORMAL),
>
> Similarly here, yet SLXD doesn't ever support any display functionality,
> so there should definitely be no need for this entry.
>
I will remove LPW1, but if I remove any others the LCD stops working.
>
> > @@ -185,6 +210,20 @@ int funcmux_select(enum periph_id id, int config)
>
> > + case PERIPH_ID_DISP1:
> > + if (config == FUNCMUX_DEFAULT) {
>
> Shouldn't this option have some kind of name in funcmux.h; there are
> many many many possible configurations for display, so just assuming
> this as some kind of default seems a little presumptuous.
>
It could have a name, but what would we call it? Until there is a second
option implemented, it seems reasonable to call it the default. That is
what was done with keyboard.
>
> But, given the number of possibilities, I wonder if it isn't time to
> replace funcmux with the device tree pinctrl bindings?
>
I suggest we look at this after we get LCD, NAND and all the other pending
things in. I haven't seen an fdt binding for Tegra LCD in the kernel yet,
so our binding will need looking at as well when it eventually happens.
Regards,
Simon
^ permalink raw reply [flat|nested] 67+ messages in thread
* [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra
2012-06-13 16:19 [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Simon Glass
@ 2012-06-13 16:19 ` Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 05/19] tegra: Use const for pinmux_config_pingroup/table() Simon Glass
` (15 subsequent siblings)
16 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: U-Boot Mailing List; +Cc: Devicetree Discuss, Jerry Van Baren, Tom Warren
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
^ permalink raw reply related [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra
@ 2012-06-13 16:19 ` Simon Glass
0 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: u-boot
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 at 7000a000 {
+ compatible = "nvidia,tegra20-pwfm";
+ reg = <0x7000a000 0x4>;
+ };
+
+ pwfm1: pwm at 7000a010 {
+ compatible = "nvidia,tegra20-pwfm";
+ reg = <0x7000a010 0x4>;
+ };
+
+ pwfm2: pwm at 7000a020 {
+ compatible = "nvidia,tegra20-pwfm";
+ reg = <0x7000a020 0x4>;
+ };
+
+ pwfm3: pwm at 7000a030 {
+ compatible = "nvidia,tegra20-pwfm";
+ reg = <0x7000a030 0x4>;
+ };
+
+ display1: display at 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 at 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
^ permalink raw reply related [flat|nested] 67+ messages in thread* Re: [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra
2012-06-13 16:19 ` [U-Boot] " Simon Glass
@ 2012-06-14 23:32 ` Stephen Warren
-1 siblings, 0 replies; 67+ messages in thread
From: Stephen Warren @ 2012-06-14 23:32 UTC (permalink / raw)
To: Simon Glass
Cc: Devicetree Discuss, U-Boot Mailing List, Jerry Van Baren, Tom 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.
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra
@ 2012-06-14 23:32 ` Stephen Warren
0 siblings, 0 replies; 67+ messages in thread
From: Stephen Warren @ 2012-06-14 23:32 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra
2012-06-14 23:32 ` [U-Boot] " Stephen Warren
@ 2012-07-11 4:44 ` Simon Glass
-1 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-07-11 4:44 UTC (permalink / raw)
To: Stephen Warren
Cc: Stephen Warren, Devicetree Discuss, U-Boot Mailing List,
Jerry Van Baren, Tom Warren
[-- 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
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra
@ 2012-07-11 4:44 ` Simon Glass
0 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-07-11 4:44 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra
2012-07-11 4:44 ` [U-Boot] " Simon Glass
@ 2012-07-11 5:48 ` Thierry Reding
-1 siblings, 0 replies; 67+ messages in thread
From: Thierry Reding @ 2012-07-11 5:48 UTC (permalink / raw)
To: Simon Glass
Cc: Stephen Warren, Devicetree Discuss, U-Boot Mailing List,
Jerry Van Baren, Tom Warren
[-- 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
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra
@ 2012-07-11 5:48 ` Thierry Reding
0 siblings, 0 replies; 67+ messages in thread
From: Thierry Reding @ 2012-07-11 5:48 UTC (permalink / raw)
To: u-boot
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120711/62660cca/attachment.pgp>
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra
2012-07-11 5:48 ` [U-Boot] " Thierry Reding
@ 2012-07-12 8:21 ` Simon Glass
-1 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-07-12 8:21 UTC (permalink / raw)
To: Thierry Reding
Cc: Stephen Warren, Devicetree Discuss, U-Boot Mailing List,
Jerry Van Baren, Tom Warren
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
^ permalink raw reply [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra
@ 2012-07-12 8:21 ` Simon Glass
0 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-07-12 8:21 UTC (permalink / raw)
To: u-boot
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 at 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
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra
2012-07-12 8:21 ` [U-Boot] " Simon Glass
@ 2012-07-12 8:40 ` Thierry Reding
-1 siblings, 0 replies; 67+ messages in thread
From: Thierry Reding @ 2012-07-12 8:40 UTC (permalink / raw)
To: Simon Glass
Cc: Stephen Warren, Devicetree Discuss, U-Boot Mailing List,
Jerry Van Baren, Alex Courbot, Tom Warren
[-- 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
^ permalink raw reply [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra
@ 2012-07-12 8:40 ` Thierry Reding
0 siblings, 0 replies; 67+ messages in thread
From: Thierry Reding @ 2012-07-12 8:40 UTC (permalink / raw)
To: u-boot
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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120712/9de88e00/attachment.pgp>
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra
2012-07-12 8:40 ` [U-Boot] " Thierry Reding
@ 2012-07-12 9:22 ` Alex Courbot
-1 siblings, 0 replies; 67+ messages in thread
From: Alex Courbot @ 2012-07-12 9:22 UTC (permalink / raw)
To: Thierry Reding
Cc: Stephen Warren, Devicetree, Discuss, U-Boot Mailing List,
Jerry Van Baren, Tom Warren
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.
-----------------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 07/19] tegra: fdt: Add LCD definitions for Tegra
@ 2012-07-12 9:22 ` Alex Courbot
0 siblings, 0 replies; 67+ messages in thread
From: Alex Courbot @ 2012-07-12 9:22 UTC (permalink / raw)
To: u-boot
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.
-----------------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 08/19] tegra: Add support for PWFM
2012-06-13 16:19 [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Simon Glass
` (3 preceding siblings ...)
2012-06-13 16:19 ` [U-Boot] " Simon Glass
@ 2012-06-13 16:19 ` Simon Glass
2012-06-14 23:35 ` Stephen Warren
2012-06-13 16:19 ` [U-Boot] [PATCH v2 09/19] tegra: Add SOC support for display/lcd Simon Glass
` (11 subsequent siblings)
16 siblings, 1 reply; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: u-boot
The pulse width/frequency modulation peripheral supports generating
a repeating pulse. It is useful for controlling LCD brightness.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
arch/arm/cpu/armv7/tegra2/Makefile | 1 +
arch/arm/cpu/armv7/tegra2/pwfm.c | 40 +++++++++++++++++++++++
arch/arm/include/asm/arch-tegra2/pwfm.h | 54 +++++++++++++++++++++++++++++++
3 files changed, 95 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/cpu/armv7/tegra2/pwfm.c
create mode 100644 arch/arm/include/asm/arch-tegra2/pwfm.h
diff --git a/arch/arm/cpu/armv7/tegra2/Makefile b/arch/arm/cpu/armv7/tegra2/Makefile
index 08c4137..9779e9e 100644
--- a/arch/arm/cpu/armv7/tegra2/Makefile
+++ b/arch/arm/cpu/armv7/tegra2/Makefile
@@ -39,6 +39,7 @@ COBJS-$(CONFIG_TEGRA_CLOCK_SCALING) += emc.o
COBJS-$(CONFIG_TEGRA_PMU) += pmu.o
COBJS-$(CONFIG_USB_EHCI_TEGRA) += usb.o
COBJS-$(CONFIG_TEGRA2_LP0) += crypto.o warmboot.o warmboot_avp.o
+COBJS-$(CONFIG_VIDEO_TEGRA) += pwfm.o
COBJS := $(COBJS-y)
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
diff --git a/arch/arm/cpu/armv7/tegra2/pwfm.c b/arch/arm/cpu/armv7/tegra2/pwfm.c
new file mode 100644
index 0000000..cdb0cbe
--- /dev/null
+++ b/arch/arm/cpu/armv7/tegra2/pwfm.c
@@ -0,0 +1,40 @@
+/*
+ * Tegra2 pulse width frequency modulator definitions
+ *
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <asm/io.h>
+#include <asm/arch/clock.h>
+#include <asm/arch/pwfm.h>
+
+void pwfm_enable(struct pwfm_ctlr *pwfm, int rate, int pulse_width,
+ int freq_divider)
+{
+ u32 reg;
+
+ /* TODO: Can we use clock_adjust_periph_pll_div() here? */
+ clock_start_periph_pll(PERIPH_ID_PWM, CLOCK_ID_SFROM32KHZ, rate);
+
+ reg = PWFM_ENABLE_MASK;
+ reg |= pulse_width << PWFM_WIDTH_SHIFT;
+ reg |= freq_divider << PWFM_DIVIDER_SHIFT;
+ writel(reg, &pwfm->control);
+}
diff --git a/arch/arm/include/asm/arch-tegra2/pwfm.h b/arch/arm/include/asm/arch-tegra2/pwfm.h
new file mode 100644
index 0000000..69e2edd
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra2/pwfm.h
@@ -0,0 +1,54 @@
+/*
+ * Tegra pulse width frequency modulator definitions
+ *
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __ASM_ARCH_TEGRA_PWFM_H
+#define __ASM_ARCH_TEGRA_PWFM_H
+
+/* This is a single PWFM channel */
+struct pwfm_ctlr {
+ uint control; /* Control register */
+};
+
+/* PWM_CONTROLLER_PWM_CSR_0/1/2/3_0 */
+#define PWFM_ENABLE_SHIFT 31
+#define PWFM_ENABLE_MASK (0x1 << PWFM_ENABLE_SHIFT)
+
+#define PWFM_WIDTH_SHIFT 16
+#define PWFM_WIDTH_MASK (0x7FFF << PWFM_WIDTH_SHIFT)
+
+#define PWFM_DIVIDER_SHIFT 0
+#define PWFM_DIVIDER_MASK (0x1FFF << PWFM_DIVIDER_SHIFT)
+
+/**
+ * Program the PWFM with the given parameters.
+ *
+ * @param pwfm Pointer to PWFM register
+ * @param rate Clock rate to use for PWFM
+ * @param pulse_width high pulse width: 0=always low, 1=1/256 pulse high,
+ * n = n/256 pulse high
+ * @param freq_divider frequency divider value (1 to use rate as is)
+ */
+void pwfm_enable(struct pwfm_ctlr *pwfm, int rate, int pulse_width,
+ int freq_divider);
+
+#endif /* __ASM_ARCH_TEGRA_PWFM_H */
--
1.7.7.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 08/19] tegra: Add support for PWFM
2012-06-13 16:19 ` [U-Boot] [PATCH v2 08/19] tegra: Add support for PWFM Simon Glass
@ 2012-06-14 23:35 ` Stephen Warren
2012-07-11 4:45 ` Simon Glass
0 siblings, 1 reply; 67+ messages in thread
From: Stephen Warren @ 2012-06-14 23:35 UTC (permalink / raw)
To: u-boot
On 06/13/2012 10:19 AM, Simon Glass wrote:
> The pulse width/frequency modulation peripheral supports generating
> a repeating pulse. It is useful for controlling LCD brightness.
Surely this should be modeled as a driver that's instantiated from DT,
which provides n PWMs. As such, I'd expect the driver to have some kind
of init/probe function, and:
> +void pwfm_enable(struct pwfm_ctlr *pwfm, int rate, int pulse_width,
> + int freq_divider);
to take a pwm_id parameter too.
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 08/19] tegra: Add support for PWFM
2012-06-14 23:35 ` Stephen Warren
@ 2012-07-11 4:45 ` Simon Glass
0 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-07-11 4:45 UTC (permalink / raw)
To: u-boot
Hi Stephen,
On Fri, Jun 15, 2012 at 1:35 AM, Stephen Warren <swarren@wwwdotorg.org>wrote:
> On 06/13/2012 10:19 AM, Simon Glass wrote:
> > The pulse width/frequency modulation peripheral supports generating
> > a repeating pulse. It is useful for controlling LCD brightness.
>
> Surely this should be modeled as a driver that's instantiated from DT,
> which provides n PWMs. As such, I'd expect the driver to have some kind
> of init/probe function, and:
>
> > +void pwfm_enable(struct pwfm_ctlr *pwfm, int rate, int pulse_width,
> > + int freq_divider);
>
> to take a pwm_id parameter too.
>
OK I will do something along those lines.
Regards,
Simon
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 09/19] tegra: Add SOC support for display/lcd
2012-06-13 16:19 [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Simon Glass
` (4 preceding siblings ...)
2012-06-13 16:19 ` [U-Boot] [PATCH v2 08/19] tegra: Add support for PWFM Simon Glass
@ 2012-06-13 16:19 ` Simon Glass
2012-06-14 23:39 ` Stephen Warren
2012-06-13 16:19 ` [U-Boot] [PATCH v2 10/19] tegra: Add LCD driver Simon Glass
` (10 subsequent siblings)
16 siblings, 1 reply; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: u-boot
From: Wei Ni <wni@nvidia.com>
Add support for the LCD peripheral at the Tegra2 SOC level. A separate
LCD driver will use this functionality to configure the display.
Mayuresh Kulkarni:
- changes to remove bitfields and clean up for submission
Simon Glass:
- simplify code, move clock control into here, clean-up
Signed-off-by: Mayuresh Kulkarni <mkulkarni@nvidia.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
arch/arm/cpu/armv7/tegra2/Makefile | 2 +-
arch/arm/cpu/armv7/tegra2/display.c | 271 ++++++++++++++
arch/arm/include/asm/arch-tegra2/dc.h | 544 ++++++++++++++++++++++++++++
arch/arm/include/asm/arch-tegra2/display.h | 133 +++++++
4 files changed, 949 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/cpu/armv7/tegra2/display.c
create mode 100644 arch/arm/include/asm/arch-tegra2/dc.h
create mode 100644 arch/arm/include/asm/arch-tegra2/display.h
diff --git a/arch/arm/cpu/armv7/tegra2/Makefile b/arch/arm/cpu/armv7/tegra2/Makefile
index 9779e9e..413f8c9 100644
--- a/arch/arm/cpu/armv7/tegra2/Makefile
+++ b/arch/arm/cpu/armv7/tegra2/Makefile
@@ -39,7 +39,7 @@ COBJS-$(CONFIG_TEGRA_CLOCK_SCALING) += emc.o
COBJS-$(CONFIG_TEGRA_PMU) += pmu.o
COBJS-$(CONFIG_USB_EHCI_TEGRA) += usb.o
COBJS-$(CONFIG_TEGRA2_LP0) += crypto.o warmboot.o warmboot_avp.o
-COBJS-$(CONFIG_VIDEO_TEGRA) += pwfm.o
+COBJS-$(CONFIG_VIDEO_TEGRA) += display.o pwfm.o
COBJS := $(COBJS-y)
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
diff --git a/arch/arm/cpu/armv7/tegra2/display.c b/arch/arm/cpu/armv7/tegra2/display.c
new file mode 100644
index 0000000..f4f4c85
--- /dev/null
+++ b/arch/arm/cpu/armv7/tegra2/display.c
@@ -0,0 +1,271 @@
+/*
+ * (C) Copyright 2010
+ * NVIDIA Corporation <www.nvidia.com>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <asm/io.h>
+#include <asm/arch/clk_rst.h>
+#include <asm/arch/clock.h>
+#include <asm/arch/timer.h>
+#include <asm/arch/tegra2.h>
+#include <asm/arch/display.h>
+#include <asm/arch/dc.h>
+
+static void update_window(struct dc_ctlr *dc, struct disp_ctl_win *win)
+{
+ unsigned h_dda, v_dda;
+ unsigned long val;
+
+ val = readl(&dc->cmd.disp_win_header);
+ val |= WINDOW_A_SELECT;
+ writel(val, &dc->cmd.disp_win_header);
+
+ writel(win->fmt, &dc->win.color_depth);
+
+ val = readl(&dc->win.byte_swap);
+ val |= BYTE_SWAP_NOSWAP << BYTE_SWAP_SHIFT;
+ writel(val, &dc->win.byte_swap);
+
+ val = win->out_x << H_POSITION_SHIFT;
+ val |= win->out_y << V_POSITION_SHIFT;
+ writel(val, &dc->win.pos);
+
+ val = win->out_w << H_SIZE_SHIFT;
+ val |= win->out_h << V_SIZE_SHIFT;
+ writel(val, &dc->win.size);
+
+ val = (win->w * win->bpp / 8) << H_PRESCALED_SIZE_SHIFT;
+ val |= win->h << V_PRESCALED_SIZE_SHIFT;
+ writel(val, &dc->win.prescaled_size);
+
+ writel(0, &dc->win.h_initial_dda);
+ writel(0, &dc->win.v_initial_dda);
+
+ h_dda = (win->w * 0x1000) / max(win->out_w - 1, 1);
+ v_dda = (win->h * 0x1000) / max(win->out_h - 1, 1);
+
+ val = h_dda << H_DDA_INC_SHIFT;
+ val |= v_dda << V_DDA_INC_SHIFT;
+ writel(val, &dc->win.dda_increment);
+
+ writel(win->stride, &dc->win.line_stride);
+ writel(0, &dc->win.buf_stride);
+
+ val = WIN_ENABLE;
+ if (win->bpp < 24)
+ val |= COLOR_EXPAND;
+ writel(val, &dc->win.win_opt);
+
+ writel((unsigned long)win->phys_addr, &dc->winbuf.start_addr);
+ writel(win->x, &dc->winbuf.addr_h_offset);
+ writel(win->y, &dc->winbuf.addr_v_offset);
+
+ writel(0xff00, &dc->win.blend_nokey);
+ writel(0xff00, &dc->win.blend_1win);
+
+ val = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
+ val |= GENERAL_UPDATE | WIN_A_UPDATE;
+ writel(val, &dc->cmd.state_ctrl);
+}
+
+static void write_pair(struct fdt_lcd *config, int item, u32 *reg)
+{
+ writel(config->horiz_timing[item] |
+ (config->vert_timing[item] << 16), reg);
+}
+
+static int update_display_mode(struct dc_disp_reg *disp,
+ struct fdt_lcd *config)
+{
+ unsigned long val;
+ unsigned long rate;
+ unsigned long div;
+
+ writel(0x0, &disp->disp_timing_opt);
+ write_pair(config, FDT_LCD_TIMING_REF_TO_SYNC, &disp->ref_to_sync);
+ write_pair(config, FDT_LCD_TIMING_SYNC_WIDTH, &disp->sync_width);
+ write_pair(config, FDT_LCD_TIMING_BACK_PORCH, &disp->back_porch);
+ write_pair(config, FDT_LCD_TIMING_FRONT_PORCH, &disp->front_porch);
+
+ writel(config->width | (config->height << 16), &disp->disp_active);
+
+ val = DE_SELECT_ACTIVE << DE_SELECT_SHIFT;
+ val |= DE_CONTROL_NORMAL << DE_CONTROL_SHIFT;
+ writel(val, &disp->data_enable_opt);
+
+ val = DATA_FORMAT_DF1P1C << DATA_FORMAT_SHIFT;
+ val |= DATA_ALIGNMENT_MSB << DATA_ALIGNMENT_SHIFT;
+ val |= DATA_ORDER_RED_BLUE << DATA_ORDER_SHIFT;
+ writel(val, &disp->disp_interface_ctrl);
+
+ /*
+ * The pixel clock divider is in 7.1 format (where the bottom bit
+ * represents 0.5). Here we calculate the divider needed to get from
+ * the display clock (typically 600MHz) to the pixel clock. We round
+ * up or down as requried.
+ */
+ rate = clock_get_periph_rate(PERIPH_ID_DISP1, CLOCK_ID_CGENERAL);
+ div = ((rate * 2 + config->pixel_clock / 2) / config->pixel_clock) - 2;
+ debug("Display clock %lu, divider %lu\n", rate, div);
+
+ writel(0x00010001, &disp->shift_clk_opt);
+
+ val = PIXEL_CLK_DIVIDER_PCD1 << PIXEL_CLK_DIVIDER_SHIFT;
+ val |= div << SHIFT_CLK_DIVIDER_SHIFT;
+ writel(val, &disp->disp_clk_ctrl);
+
+ return 0;
+}
+
+/* Start up the display and turn on power to PWMs */
+static void basic_init(struct dc_cmd_reg *cmd)
+{
+ u32 val;
+
+ writel(0x00000100, &cmd->gen_incr_syncpt_ctrl);
+ writel(0x0000011a, &cmd->cont_syncpt_vsync);
+ writel(0x00000000, &cmd->int_type);
+ writel(0x00000000, &cmd->int_polarity);
+ writel(0x00000000, &cmd->int_mask);
+ writel(0x00000000, &cmd->int_enb);
+
+ val = PW0_ENABLE | PW1_ENABLE | PW2_ENABLE;
+ val |= PW3_ENABLE | PW4_ENABLE | PM0_ENABLE;
+ val |= PM1_ENABLE;
+ writel(val, &cmd->disp_pow_ctrl);
+
+ val = readl(&cmd->disp_cmd);
+ val |= CTRL_MODE_C_DISPLAY << CTRL_MODE_SHIFT;
+ writel(val, &cmd->disp_cmd);
+}
+
+static void basic_init_timer(struct dc_disp_reg *disp)
+{
+ writel(0x00000020, &disp->mem_high_pri);
+ writel(0x00000001, &disp->mem_high_pri_timer);
+}
+
+static const u32 rgb_enb_tab[PIN_REG_COUNT] = {
+ 0x00000000,
+ 0x00000000,
+ 0x00000000,
+ 0x00000000,
+};
+
+static const u32 rgb_polarity_tab[PIN_REG_COUNT] = {
+ 0x00000000,
+ 0x01000000,
+ 0x00000000,
+ 0x00000000,
+};
+
+static const u32 rgb_data_tab[PIN_REG_COUNT] = {
+ 0x00000000,
+ 0x00000000,
+ 0x00000000,
+ 0x00000000,
+};
+
+static const u32 rgb_sel_tab[PIN_OUTPUT_SEL_COUNT] = {
+ 0x00000000,
+ 0x00000000,
+ 0x00000000,
+ 0x00000000,
+ 0x00210222,
+ 0x00002200,
+ 0x00020000,
+};
+
+static void rgb_enable(struct dc_com_reg *com)
+{
+ int i;
+
+ for (i = 0; i < PIN_REG_COUNT; i++) {
+ writel(rgb_enb_tab[i], &com->pin_output_enb[i]);
+ writel(rgb_polarity_tab[i], &com->pin_output_polarity[i]);
+ writel(rgb_data_tab[i], &com->pin_output_data[i]);
+ }
+
+ for (i = 0; i < PIN_OUTPUT_SEL_COUNT; i++)
+ writel(rgb_sel_tab[i], &com->pin_output_sel[i]);
+}
+
+int setup_window(struct disp_ctl_win *win, struct fdt_lcd *config)
+{
+ win->x = 0;
+ win->y = 0;
+ win->w = config->width;
+ win->h = config->height;
+ win->out_x = 0;
+ win->out_y = 0;
+ win->out_w = config->width;
+ win->out_h = config->height;
+ win->phys_addr = config->frame_buffer;
+ win->stride = config->width * (1 << config->log2_bpp) / 8;
+ debug("%s: depth = %d\n", __func__, config->log2_bpp);
+ switch (config->log2_bpp) {
+ case 5:
+ case 24:
+ win->fmt = COLOR_DEPTH_R8G8B8A8;
+ win->bpp = 32;
+ break;
+ case 4:
+ win->fmt = COLOR_DEPTH_B5G6R5;
+ win->bpp = 16;
+ break;
+
+ default:
+ debug("Unsupported LCD bit depth");
+ return -1;
+ }
+
+ return 0;
+}
+
+int tegra2_display_register(struct fdt_lcd *config)
+{
+ struct disp_ctl_win window;
+ struct dc_ctlr *dc = (struct dc_ctlr *)config->disp;
+
+ /*
+ * A header file for clock constants was NAKed upstream.
+ * TODO: Put this into the FDT and fdt_lcd struct when we have clock
+ * support there
+ */
+ clock_start_periph_pll(PERIPH_ID_HOST1X, CLOCK_ID_PERIPH,
+ 144 * 1000000);
+ clock_start_periph_pll(PERIPH_ID_DISP1, CLOCK_ID_CGENERAL,
+ 600 * 1000000);
+ basic_init(&dc->cmd);
+ basic_init_timer(&dc->disp);
+ rgb_enable(&dc->com);
+
+ if (config->pixel_clock)
+ update_display_mode(&dc->disp, config);
+
+ if (setup_window(&window, config))
+ return -1;
+
+ update_window(dc, &window);
+
+ return 0;
+}
diff --git a/arch/arm/include/asm/arch-tegra2/dc.h b/arch/arm/include/asm/arch-tegra2/dc.h
new file mode 100644
index 0000000..46c4137
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra2/dc.h
@@ -0,0 +1,544 @@
+/*
+ * (C) Copyright 2010
+ * NVIDIA Corporation <www.nvidia.com>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __ASM_ARCH_TEGRA_DC_H
+#define __ASM_ARCH_TEGRA_DC_H
+
+/* Register definitions for the Tegra display controller */
+
+/* CMD register 0x000 ~ 0x43 */
+struct dc_cmd_reg {
+ /* Address 0x000 ~ 0x002 */
+ uint gen_incr_syncpt; /* _CMD_GENERAL_INCR_SYNCPT_0 */
+ uint gen_incr_syncpt_ctrl; /* _CMD_GENERAL_INCR_SYNCPT_CNTRL_0 */
+ uint gen_incr_syncpt_err; /* _CMD_GENERAL_INCR_SYNCPT_ERROR_0 */
+
+ uint reserved0[5]; /* reserved_0[5] */
+
+ /* Address 0x008 ~ 0x00a */
+ uint win_a_incr_syncpt; /* _CMD_WIN_A_INCR_SYNCPT_0 */
+ uint win_a_incr_syncpt_ctrl; /* _CMD_WIN_A_INCR_SYNCPT_CNTRL_0 */
+ uint win_a_incr_syncpt_err; /* _CMD_WIN_A_INCR_SYNCPT_ERROR_0 */
+
+ uint reserved1[5]; /* reserved_1[5] */
+
+ /* Address 0x010 ~ 0x012 */
+ uint win_b_incr_syncpt; /* _CMD_WIN_B_INCR_SYNCPT_0 */
+ uint win_b_incr_syncpt_ctrl; /* _CMD_WIN_B_INCR_SYNCPT_CNTRL_0 */
+ uint win_b_incr_syncpt_err; /* _CMD_WIN_B_INCR_SYNCPT_ERROR_0 */
+
+ uint reserved2[5]; /* reserved_2[5] */
+
+ /* Address 0x018 ~ 0x01a */
+ uint win_c_incr_syncpt; /* _CMD_WIN_C_INCR_SYNCPT_0 */
+ uint win_c_incr_syncpt_ctrl; /* _CMD_WIN_C_INCR_SYNCPT_CNTRL_0 */
+ uint win_c_incr_syncpt_err; /* _CMD_WIN_C_INCR_SYNCPT_ERROR_0 */
+
+ uint reserved3[13]; /* reserved_3[13] */
+
+ /* Address 0x028 */
+ uint cont_syncpt_vsync; /* _CMD_CONT_SYNCPT_VSYNC_0 */
+
+ uint reserved4[7]; /* reserved_4[7] */
+
+ /* Address 0x030 ~ 0x033 */
+ uint ctxsw; /* _CMD_CTXSW_0 */
+ uint disp_cmd_opt0; /* _CMD_DISPLAY_COMMAND_OPTION0_0 */
+ uint disp_cmd; /* _CMD_DISPLAY_COMMAND_0 */
+ uint sig_raise; /* _CMD_SIGNAL_RAISE_0 */
+
+ uint reserved5[2]; /* reserved_0[2] */
+
+ /* Address 0x036 ~ 0x03e */
+ uint disp_pow_ctrl; /* _CMD_DISPLAY_POWER_CONTROL_0 */
+ uint int_stat; /* _CMD_INT_STATUS_0 */
+ uint int_mask; /* _CMD_INT_MASK_0 */
+ uint int_enb; /* _CMD_INT_ENABLE_0 */
+ uint int_type; /* _CMD_INT_TYPE_0 */
+ uint int_polarity; /* _CMD_INT_POLARITY_0 */
+ uint sig_raise1; /* _CMD_SIGNAL_RAISE1_0 */
+ uint sig_raise2; /* _CMD_SIGNAL_RAISE2_0 */
+ uint sig_raise3; /* _CMD_SIGNAL_RAISE3_0 */
+
+ uint reserved6; /* reserved_6 */
+
+ /* Address 0x040 ~ 0x043 */
+ uint state_access; /* _CMD_STATE_ACCESS_0 */
+ uint state_ctrl; /* _CMD_STATE_CONTROL_0 */
+ uint disp_win_header; /* _CMD_DISPLAY_WINDOW_HEADER_0 */
+ uint reg_act_ctrl; /* _CMD_REG_ACT_CONTROL_0 */
+};
+
+enum {
+ PIN_REG_COUNT = 4,
+ PIN_OUTPUT_SEL_COUNT = 7,
+};
+
+/* COM register 0x300 ~ 0x329 */
+struct dc_com_reg {
+ /* Address 0x300 ~ 0x301 */
+ uint crc_ctrl; /* _COM_CRC_CONTROL_0 */
+ uint crc_checksum; /* _COM_CRC_CHECKSUM_0 */
+
+ /* _COM_PIN_OUTPUT_ENABLE0/1/2/3_0: Address 0x302 ~ 0x305 */
+ uint pin_output_enb[PIN_REG_COUNT];
+
+ /* _COM_PIN_OUTPUT_POLARITY0/1/2/3_0: Address 0x306 ~ 0x309 */
+ uint pin_output_polarity[PIN_REG_COUNT];
+
+ /* _COM_PIN_OUTPUT_DATA0/1/2/3_0: Address 0x30a ~ 0x30d */
+ uint pin_output_data[PIN_REG_COUNT];
+
+ /* _COM_PIN_INPUT_ENABLE0_0: Address 0x30e ~ 0x311 */
+ uint pin_input_enb[PIN_REG_COUNT];
+
+ /* Address 0x312 ~ 0x313 */
+ uint pin_input_data0; /* _COM_PIN_INPUT_DATA0_0 */
+ uint pin_input_data1; /* _COM_PIN_INPUT_DATA1_0 */
+
+ /* _COM_PIN_OUTPUT_SELECT0/1/2/3/4/5/6_0: Address 0x314 ~ 0x31a */
+ uint pin_output_sel[PIN_OUTPUT_SEL_COUNT];
+
+ /* Address 0x31b ~ 0x329 */
+ uint pin_misc_ctrl; /* _COM_PIN_MISC_CONTROL_0 */
+ uint pm0_ctrl; /* _COM_PM0_CONTROL_0 */
+ uint pm0_duty_cycle; /* _COM_PM0_DUTY_CYCLE_0 */
+ uint pm1_ctrl; /* _COM_PM1_CONTROL_0 */
+ uint pm1_duty_cycle; /* _COM_PM1_DUTY_CYCLE_0 */
+ uint spi_ctrl; /* _COM_SPI_CONTROL_0 */
+ uint spi_start_byte; /* _COM_SPI_START_BYTE_0 */
+ uint hspi_wr_data_ab; /* _COM_HSPI_WRITE_DATA_AB_0 */
+ uint hspi_wr_data_cd; /* _COM_HSPI_WRITE_DATA_CD */
+ uint hspi_cs_dc; /* _COM_HSPI_CS_DC_0 */
+ uint scratch_reg_a; /* _COM_SCRATCH_REGISTER_A_0 */
+ uint scratch_reg_b; /* _COM_SCRATCH_REGISTER_B_0 */
+ uint gpio_ctrl; /* _COM_GPIO_CTRL_0 */
+ uint gpio_debounce_cnt; /* _COM_GPIO_DEBOUNCE_COUNTER_0 */
+ uint crc_checksum_latched; /* _COM_CRC_CHECKSUM_LATCHED_0 */
+};
+
+enum dc_disp_h_pulse_pos {
+ H_PULSE0_POSITION_A,
+ H_PULSE0_POSITION_B,
+ H_PULSE0_POSITION_C,
+ H_PULSE0_POSITION_D,
+ H_PULSE0_POSITION_COUNT,
+};
+
+struct _disp_h_pulse {
+ /* _DISP_H_PULSE0/1/2_CONTROL_0 */
+ uint h_pulse_ctrl;
+ /* _DISP_H_PULSE0/1/2_POSITION_A/B/C/D_0 */
+ uint h_pulse_pos[H_PULSE0_POSITION_COUNT];
+};
+
+enum dc_disp_v_pulse_pos {
+ V_PULSE0_POSITION_A,
+ V_PULSE0_POSITION_B,
+ V_PULSE0_POSITION_C,
+ V_PULSE0_POSITION_COUNT,
+};
+
+struct _disp_v_pulse0 {
+ /* _DISP_H_PULSE0/1_CONTROL_0 */
+ uint v_pulse_ctrl;
+ /* _DISP_H_PULSE0/1_POSITION_A/B/C_0 */
+ uint v_pulse_pos[V_PULSE0_POSITION_COUNT];
+};
+
+struct _disp_v_pulse2 {
+ /* _DISP_H_PULSE2/3_CONTROL_0 */
+ uint v_pulse_ctrl;
+ /* _DISP_H_PULSE2/3_POSITION_A_0 */
+ uint v_pulse_pos_a;
+};
+
+enum dc_disp_h_pulse_reg {
+ H_PULSE0,
+ H_PULSE1,
+ H_PULSE2,
+ H_PULSE_COUNT,
+};
+
+enum dc_disp_pp_select {
+ PP_SELECT_A,
+ PP_SELECT_B,
+ PP_SELECT_C,
+ PP_SELECT_D,
+ PP_SELECT_COUNT,
+};
+
+/* DISP register 0x400 ~ 0x4c1 */
+struct dc_disp_reg {
+ /* Address 0x400 ~ 0x40a */
+ uint disp_signal_opt0; /* _DISP_DISP_SIGNAL_OPTIONS0_0 */
+ uint disp_signal_opt1; /* _DISP_DISP_SIGNAL_OPTIONS1_0 */
+ uint disp_win_opt; /* _DISP_DISP_WIN_OPTIONS_0 */
+ uint mem_high_pri; /* _DISP_MEM_HIGH_PRIORITY_0 */
+ uint mem_high_pri_timer; /* _DISP_MEM_HIGH_PRIORITY_TIMER_0 */
+ uint disp_timing_opt; /* _DISP_DISP_TIMING_OPTIONS_0 */
+ uint ref_to_sync; /* _DISP_REF_TO_SYNC_0 */
+ uint sync_width; /* _DISP_SYNC_WIDTH_0 */
+ uint back_porch; /* _DISP_BACK_PORCH_0 */
+ uint disp_active; /* _DISP_DISP_ACTIVE_0 */
+ uint front_porch; /* _DISP_FRONT_PORCH_0 */
+
+ /* Address 0x40b ~ 0x419: _DISP_H_PULSE0/1/2_ */
+ struct _disp_h_pulse h_pulse[H_PULSE_COUNT];
+
+ /* Address 0x41a ~ 0x421 */
+ struct _disp_v_pulse0 v_pulse0; /* _DISP_V_PULSE0_ */
+ struct _disp_v_pulse0 v_pulse1; /* _DISP_V_PULSE1_ */
+
+ /* Address 0x422 ~ 0x425 */
+ struct _disp_v_pulse2 v_pulse3; /* _DISP_V_PULSE2_ */
+ struct _disp_v_pulse2 v_pulse4; /* _DISP_V_PULSE3_ */
+
+ /* Address 0x426 ~ 0x429 */
+ uint m0_ctrl; /* _DISP_M0_CONTROL_0 */
+ uint m1_ctrl; /* _DISP_M1_CONTROL_0 */
+ uint di_ctrl; /* _DISP_DI_CONTROL_0 */
+ uint pp_ctrl; /* _DISP_PP_CONTROL_0 */
+
+ /* Address 0x42a ~ 0x42d: _DISP_PP_SELECT_A/B/C/D_0 */
+ uint pp_select[PP_SELECT_COUNT];
+
+ /* Address 0x42e ~ 0x435 */
+ uint disp_clk_ctrl; /* _DISP_DISP_CLOCK_CONTROL_0 */
+ uint disp_interface_ctrl; /* _DISP_DISP_INTERFACE_CONTROL_0 */
+ uint disp_color_ctrl; /* _DISP_DISP_COLOR_CONTROL_0 */
+ uint shift_clk_opt; /* _DISP_SHIFT_CLOCK_OPTIONS_0 */
+ uint data_enable_opt; /* _DISP_DATA_ENABLE_OPTIONS_0 */
+ uint serial_interface_opt; /* _DISP_SERIAL_INTERFACE_OPTIONS_0 */
+ uint lcd_spi_opt; /* _DISP_LCD_SPI_OPTIONS_0 */
+ uint border_color; /* _DISP_BORDER_COLOR_0 */
+
+ /* Address 0x436 ~ 0x439 */
+ uint color_key0_lower; /* _DISP_COLOR_KEY0_LOWER_0 */
+ uint color_key0_upper; /* _DISP_COLOR_KEY0_UPPER_0 */
+ uint color_key1_lower; /* _DISP_COLOR_KEY1_LOWER_0 */
+ uint color_key1_upper; /* _DISP_COLOR_KEY1_UPPER_0 */
+
+ uint reserved0[2]; /* reserved_0[2] */
+
+ /* Address 0x43c ~ 0x442 */
+ uint cursor_foreground; /* _DISP_CURSOR_FOREGROUND_0 */
+ uint cursor_background; /* _DISP_CURSOR_BACKGROUND_0 */
+ uint cursor_start_addr; /* _DISP_CURSOR_START_ADDR_0 */
+ uint cursor_start_addr_ns; /* _DISP_CURSOR_START_ADDR_NS_0 */
+ uint cursor_pos; /* _DISP_CURSOR_POSITION_0 */
+ uint cursor_pos_ns; /* _DISP_CURSOR_POSITION_NS_0 */
+ uint seq_ctrl; /* _DISP_INIT_SEQ_CONTROL_0 */
+
+ /* Address 0x442 ~ 0x446 */
+ uint spi_init_seq_data_a; /* _DISP_SPI_INIT_SEQ_DATA_A_0 */
+ uint spi_init_seq_data_b; /* _DISP_SPI_INIT_SEQ_DATA_B_0 */
+ uint spi_init_seq_data_c; /* _DISP_SPI_INIT_SEQ_DATA_C_0 */
+ uint spi_init_seq_data_d; /* _DISP_SPI_INIT_SEQ_DATA_D_0 */
+
+ uint reserved1[0x39]; /* reserved1[0x39], */
+
+ /* Address 0x480 ~ 0x484 */
+ uint dc_mccif_fifoctrl; /* _DISP_DC_MCCIF_FIFOCTRL_0 */
+ uint mccif_disp0a_hyst; /* _DISP_MCCIF_DISPLAY0A_HYST_0 */
+ uint mccif_disp0b_hyst; /* _DISP_MCCIF_DISPLAY0B_HYST_0 */
+ uint mccif_disp0c_hyst; /* _DISP_MCCIF_DISPLAY0C_HYST_0 */
+ uint mccif_disp1b_hyst; /* _DISP_MCCIF_DISPLAY1B_HYST_0 */
+
+ uint reserved2[0x3b]; /* reserved2[0x3b] */
+
+ /* Address 0x4c0 ~ 0x4c1 */
+ uint dac_crt_ctrl; /* _DISP_DAC_CRT_CTRL_0 */
+ uint disp_misc_ctrl; /* _DISP_DISP_MISC_CONTROL_0 */
+};
+
+enum dc_winc_filter_p {
+ WINC_FILTER_COUNT = 0x10,
+};
+
+/* Window A/B/C register 0x500 ~ 0x628 */
+struct dc_winc_reg {
+
+ /* Address 0x500 */
+ uint color_palette; /* _WINC_COLOR_PALETTE_0 */
+
+ uint reserved0[0xff]; /* reserved_0[0xff] */
+
+ /* Address 0x600 */
+ uint palette_color_ext; /* _WINC_PALETTE_COLOR_EXT_0 */
+
+ /* _WINC_H_FILTER_P00~0F_0 */
+ /* Address 0x601 ~ 0x610 */
+ uint h_filter_p[WINC_FILTER_COUNT];
+
+ /* Address 0x611 ~ 0x618 */
+ uint csc_yof; /* _WINC_CSC_YOF_0 */
+ uint csc_kyrgb; /* _WINC_CSC_KYRGB_0 */
+ uint csc_kur; /* _WINC_CSC_KUR_0 */
+ uint csc_kvr; /* _WINC_CSC_KVR_0 */
+ uint csc_kug; /* _WINC_CSC_KUG_0 */
+ uint csc_kvg; /* _WINC_CSC_KVG_0 */
+ uint csc_kub; /* _WINC_CSC_KUB_0 */
+ uint csc_kvb; /* _WINC_CSC_KVB_0 */
+
+ /* Address 0x619 ~ 0x628: _WINC_V_FILTER_P00~0F_0 */
+ uint v_filter_p[WINC_FILTER_COUNT];
+};
+
+/* WIN A/B/C Register 0x700 ~ 0x714*/
+struct dc_win_reg {
+ /* Address 0x700 ~ 0x714 */
+ uint win_opt; /* _WIN_WIN_OPTIONS_0 */
+ uint byte_swap; /* _WIN_BYTE_SWAP_0 */
+ uint buffer_ctrl; /* _WIN_BUFFER_CONTROL_0 */
+ uint color_depth; /* _WIN_COLOR_DEPTH_0 */
+ uint pos; /* _WIN_POSITION_0 */
+ uint size; /* _WIN_SIZE_0 */
+ uint prescaled_size; /* _WIN_PRESCALED_SIZE_0 */
+ uint h_initial_dda; /* _WIN_H_INITIAL_DDA_0 */
+ uint v_initial_dda; /* _WIN_V_INITIAL_DDA_0 */
+ uint dda_increment; /* _WIN_DDA_INCREMENT_0 */
+ uint line_stride; /* _WIN_LINE_STRIDE_0 */
+ uint buf_stride; /* _WIN_BUF_STRIDE_0 */
+ uint uv_buf_stride; /* _WIN_UV_BUF_STRIDE_0 */
+ uint buffer_addr_mode; /* _WIN_BUFFER_ADDR_MODE_0 */
+ uint dv_ctrl; /* _WIN_DV_CONTROL_0 */
+ uint blend_nokey; /* _WIN_BLEND_NOKEY_0 */
+ uint blend_1win; /* _WIN_BLEND_1WIN_0 */
+ uint blend_2win_x; /* _WIN_BLEND_2WIN_X_0 */
+ uint blend_2win_y; /* _WIN_BLEND_2WIN_Y_0 */
+ uint blend_3win_xy; /* _WIN_BLEND_3WIN_XY_0 */
+ uint hp_fetch_ctrl; /* _WIN_HP_FETCH_CONTROL_0 */
+};
+
+/* WINBUF A/B/C Register 0x800 ~ 0x80a */
+struct dc_winbuf_reg {
+ /* Address 0x800 ~ 0x80a */
+ uint start_addr; /* _WINBUF_START_ADDR_0 */
+ uint start_addr_ns; /* _WINBUF_START_ADDR_NS_0 */
+ uint start_addr_u; /* _WINBUF_START_ADDR_U_0 */
+ uint start_addr_u_ns; /* _WINBUF_START_ADDR_U_NS_0 */
+ uint start_addr_v; /* _WINBUF_START_ADDR_V_0 */
+ uint start_addr_v_ns; /* _WINBUF_START_ADDR_V_NS_0 */
+ uint addr_h_offset; /* _WINBUF_ADDR_H_OFFSET_0 */
+ uint addr_h_offset_ns; /* _WINBUF_ADDR_H_OFFSET_NS_0 */
+ uint addr_v_offset; /* _WINBUF_ADDR_V_OFFSET_0 */
+ uint addr_v_offset_ns; /* _WINBUF_ADDR_V_OFFSET_NS_0 */
+ uint uflow_status; /* _WINBUF_UFLOW_STATUS_0 */
+};
+
+/* Display Controller (DC_) regs */
+struct dc_ctlr {
+ struct dc_cmd_reg cmd; /* CMD register 0x000 ~ 0x43 */
+ uint reserved0[0x2bc];
+
+ struct dc_com_reg com; /* COM register 0x300 ~ 0x329 */
+ uint reserved1[0xd6];
+
+ struct dc_disp_reg disp; /* DISP register 0x400 ~ 0x4c1 */
+ uint reserved2[0x3e];
+
+ struct dc_winc_reg winc; /* Window A/B/C 0x500 ~ 0x628 */
+ uint reserved3[0xd7];
+
+ struct dc_win_reg win; /* WIN A/B/C 0x700 ~ 0x714*/
+ uint reserved4[0xeb];
+
+ struct dc_winbuf_reg winbuf; /* WINBUF A/B/C 0x800 ~ 0x80a */
+};
+
+#define BIT(pos) (1U << pos)
+
+/* DC_CMD_DISPLAY_COMMAND 0x032 */
+#define CTRL_MODE_SHIFT 5
+#define CTRL_MODE_MASK (0x3 << CTRL_MODE_SHIFT)
+enum {
+ CTRL_MODE_STOP,
+ CTRL_MODE_C_DISPLAY,
+ CTRL_MODE_NC_DISPLAY,
+};
+
+/* _WIN_COLOR_DEPTH_0 */
+enum win_color_depth_id {
+ COLOR_DEPTH_P1,
+ COLOR_DEPTH_P2,
+ COLOR_DEPTH_P4,
+ COLOR_DEPTH_P8,
+ COLOR_DEPTH_B4G4R4A4,
+ COLOR_DEPTH_B5G5R5A,
+ COLOR_DEPTH_B5G6R5,
+ COLOR_DEPTH_AB5G5R5,
+ COLOR_DEPTH_B8G8R8A8 = 12,
+ COLOR_DEPTH_R8G8B8A8,
+ COLOR_DEPTH_B6x2G6x2R6x2A8,
+ COLOR_DEPTH_R6x2G6x2B6x2A8,
+ COLOR_DEPTH_YCbCr422,
+ COLOR_DEPTH_YUV422,
+ COLOR_DEPTH_YCbCr420P,
+ COLOR_DEPTH_YUV420P,
+ COLOR_DEPTH_YCbCr422P,
+ COLOR_DEPTH_YUV422P,
+ COLOR_DEPTH_YCbCr422R,
+ COLOR_DEPTH_YUV422R,
+ COLOR_DEPTH_YCbCr422RA,
+ COLOR_DEPTH_YUV422RA,
+};
+
+/* DC_CMD_DISPLAY_POWER_CONTROL 0x036 */
+#define PW0_ENABLE BIT(0)
+#define PW1_ENABLE BIT(2)
+#define PW2_ENABLE BIT(4)
+#define PW3_ENABLE BIT(6)
+#define PW4_ENABLE BIT(8)
+#define PM0_ENABLE BIT(16)
+#define PM1_ENABLE BIT(18)
+#define SPI_ENABLE BIT(24)
+#define HSPI_ENABLE BIT(25)
+
+/* DC_CMD_STATE_CONTROL 0x041 */
+#define GENERAL_ACT_REQ BIT(0)
+#define WIN_A_ACT_REQ BIT(1)
+#define WIN_B_ACT_REQ BIT(2)
+#define WIN_C_ACT_REQ BIT(3)
+#define GENERAL_UPDATE BIT(8)
+#define WIN_A_UPDATE BIT(9)
+#define WIN_B_UPDATE BIT(10)
+#define WIN_C_UPDATE BIT(11)
+
+/* DC_CMD_DISPLAY_WINDOW_HEADER 0x042 */
+#define WINDOW_A_SELECT BIT(4)
+#define WINDOW_B_SELECT BIT(5)
+#define WINDOW_C_SELECT BIT(6)
+
+/* DC_DISP_DISP_CLOCK_CONTROL 0x42e */
+#define SHIFT_CLK_DIVIDER_SHIFT 0
+#define SHIFT_CLK_DIVIDER_MASK (0xff << SHIFT_CLK_DIVIDER_SHIFT)
+#define PIXEL_CLK_DIVIDER_SHIFT 8
+#define PIXEL_CLK_DIVIDER_MSK (0xf << PIXEL_CLK_DIVIDER_SHIFT)
+enum {
+ PIXEL_CLK_DIVIDER_PCD1,
+ PIXEL_CLK_DIVIDER_PCD1H,
+ PIXEL_CLK_DIVIDER_PCD2,
+ PIXEL_CLK_DIVIDER_PCD3,
+ PIXEL_CLK_DIVIDER_PCD4,
+ PIXEL_CLK_DIVIDER_PCD6,
+ PIXEL_CLK_DIVIDER_PCD8,
+ PIXEL_CLK_DIVIDER_PCD9,
+ PIXEL_CLK_DIVIDER_PCD12,
+ PIXEL_CLK_DIVIDER_PCD16,
+ PIXEL_CLK_DIVIDER_PCD18,
+ PIXEL_CLK_DIVIDER_PCD24,
+ PIXEL_CLK_DIVIDER_PCD13,
+};
+
+/* DC_DISP_DISP_INTERFACE_CONTROL 0x42f */
+#define DATA_FORMAT_SHIFT 0
+#define DATA_FORMAT_MASK (0xf << DATA_FORMAT_SHIFT)
+enum {
+ DATA_FORMAT_DF1P1C,
+ DATA_FORMAT_DF1P2C24B,
+ DATA_FORMAT_DF1P2C18B,
+ DATA_FORMAT_DF1P2C16B,
+ DATA_FORMAT_DF2S,
+ DATA_FORMAT_DF3S,
+ DATA_FORMAT_DFSPI,
+ DATA_FORMAT_DF1P3C24B,
+ DATA_FORMAT_DF1P3C18B,
+};
+#define DATA_ALIGNMENT_SHIFT 8
+enum {
+ DATA_ALIGNMENT_MSB,
+ DATA_ALIGNMENT_LSB,
+};
+#define DATA_ORDER_SHIFT 9
+enum {
+ DATA_ORDER_RED_BLUE,
+ DATA_ORDER_BLUE_RED,
+};
+
+/* DC_DISP_DATA_ENABLE_OPTIONS 0x432 */
+#define DE_SELECT_SHIFT 0
+#define DE_SELECT_MASK (0x3 << DE_SELECT_SHIFT)
+#define DE_SELECT_ACTIVE_BLANK 0x0
+#define DE_SELECT_ACTIVE 0x1
+#define DE_SELECT_ACTIVE_IS 0x2
+#define DE_CONTROL_SHIFT 2
+#define DE_CONTROL_MASK (0x7 << DE_CONTROL_SHIFT)
+enum {
+ DE_CONTROL_ONECLK,
+ DE_CONTROL_NORMAL,
+ DE_CONTROL_EARLY_EXT,
+ DE_CONTROL_EARLY,
+ DE_CONTROL_ACTIVE_BLANK,
+};
+
+/* DC_WIN_WIN_OPTIONS 0x700 */
+#define H_DIRECTION BIT(0)
+enum {
+ H_DIRECTION_INCREMENT,
+ H_DIRECTION_DECREMENT,
+};
+#define V_DIRECTION BIT(2)
+enum {
+ V_DIRECTION_INCREMENT,
+ V_DIRECTION_DECREMENT,
+};
+#define COLOR_EXPAND BIT(6)
+#define CP_ENABLE BIT(16)
+#define DV_ENABLE BIT(20)
+#define WIN_ENABLE BIT(30)
+
+/* DC_WIN_BYTE_SWAP 0x701 */
+#define BYTE_SWAP_SHIFT 0
+enum {
+ BYTE_SWAP_NOSWAP,
+ BYTE_SWAP_SWAP2,
+ BYTE_SWAP_SWAP4,
+ BYTE_SWAP_SWAP4HW
+};
+
+/* DC_WIN_POSITION 0x704 */
+#define H_POSITION_SHIFT 0
+#define H_POSITION_MASK (0x1FFF << H_POSITION_SHIFT)
+#define V_POSITION_SHIFT 16
+#define V_POSITION_MASK (0x1FFF << V_POSITION_SHIFT)
+
+/* DC_WIN_SIZE 0x705 */
+#define H_SIZE_SHIFT 0
+#define H_SIZE_MASK (0x1FFF << H_SIZE_SHIFT)
+#define V_SIZE_SHIFT 16
+#define V_SIZE_MASK (0x1FFF << V_SIZE_SHIFT)
+
+/* DC_WIN_PRESCALED_SIZE 0x706 */
+#define H_PRESCALED_SIZE_SHIFT 0
+#define H_PRESCALED_SIZE_MASK (0x7FFF << H_PRESCALED_SIZE)
+#define V_PRESCALED_SIZE_SHIFT 16
+#define V_PRESCALED_SIZE_MASK (0x1FFF << V_PRESCALED_SIZE)
+
+/* DC_WIN_DDA_INCREMENT 0x709 */
+#define H_DDA_INC_SHIFT 0
+#define H_DDA_INC_MASK (0xFFFF << H_DDA_INC_SHIFT)
+#define V_DDA_INC_SHIFT 16
+#define V_DDA_INC_MASK (0xFFFF << V_DDA_INC_SHIFT)
+
+#endif /* __ASM_ARCH_TEGRA_DC_H */
diff --git a/arch/arm/include/asm/arch-tegra2/display.h b/arch/arm/include/asm/arch-tegra2/display.h
new file mode 100644
index 0000000..4f9f395
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra2/display.h
@@ -0,0 +1,133 @@
+/*
+ * (C) Copyright 2010
+ * NVIDIA Corporation <www.nvidia.com>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __ASM_ARCH_TEGRA_DISPLAY_H
+#define __ASM_ARCH_TEGRA_DISPLAY_H
+
+#include <asm/arch-tegra2/dc.h>
+#include <fdtdec.h>
+
+/* This holds information about a window which can be displayed */
+struct disp_ctl_win {
+ enum win_color_depth_id fmt; /* Color depth/format */
+ unsigned bpp; /* Bits per pixel */
+ phys_addr_t phys_addr; /* Physical address in memory */
+ unsigned x; /* Horizontal address offset (bytes) */
+ unsigned y; /* Veritical address offset (bytes) */
+ unsigned w; /* Width of source window */
+ unsigned h; /* Height of source window */
+ unsigned stride; /* Number of bytes per line */
+ unsigned out_x; /* Left edge of output window (col) */
+ unsigned out_y; /* Top edge of output window (row) */
+ unsigned out_w; /* Width of output window in pixels */
+ unsigned out_h; /* Height of output window in pixels */
+};
+
+#define FDT_LCD_TIMINGS 4
+
+enum {
+ FDT_LCD_TIMING_REF_TO_SYNC,
+ FDT_LCD_TIMING_SYNC_WIDTH,
+ FDT_LCD_TIMING_BACK_PORCH,
+ FDT_LCD_TIMING_FRONT_PORCH,
+
+ FDT_LCD_TIMING_COUNT,
+};
+
+enum lcd_cache_t {
+ FDT_LCD_CACHE_OFF = 0,
+ FDT_LCD_CACHE_WRITE_THROUGH = 1 << 0,
+ FDT_LCD_CACHE_WRITE_BACK = 1 << 1,
+ FDT_LCD_CACHE_FLUSH = 1 << 2,
+ FDT_LCD_CACHE_WRITE_BACK_FLUSH = FDT_LCD_CACHE_WRITE_BACK |
+ FDT_LCD_CACHE_FLUSH,
+};
+
+/* Information about the LCD */
+struct fdt_lcd {
+ int width; /* width in pixels */
+ int height; /* height in pixels */
+ int bpp; /* number of bits per pixel */
+
+ /*
+ * log2 of number of bpp, in general, unless it bpp is 24 in which
+ * case this field holds 24 also! This is a U-Boot thing.
+ */
+ int log2_bpp;
+ struct pwfm_ctlr *pwfm; /* PWM to use for backlight */
+ struct disp_ctlr *disp; /* Display controller to use */
+ fdt_addr_t frame_buffer; /* Address of frame buffer */
+ unsigned pixel_clock; /* Pixel clock in Hz */
+ uint horiz_timing[FDT_LCD_TIMING_COUNT]; /* Horizontal timing */
+ uint vert_timing[FDT_LCD_TIMING_COUNT]; /* Vertical timing */
+ enum lcd_cache_t cache_type;
+
+ struct fdt_gpio_state backlight_en; /* GPIO for backlight enable */
+ struct fdt_gpio_state lvds_shutdown; /* GPIO for lvds shutdown */
+ struct fdt_gpio_state backlight_vdd; /* GPIO for backlight vdd */
+ struct fdt_gpio_state panel_vdd; /* GPIO for panel vdd */
+ /*
+ * Panel required timings
+ * Timing 1: delay between panel_vdd-rise and data-rise
+ * Timing 2: delay between data-rise and backlight_vdd-rise
+ * Timing 3: delay between backlight_vdd and pwm-rise
+ * Timing 4: delay between pwm-rise and backlight_en-rise
+ */
+ uint panel_timings[FDT_LCD_TIMINGS];
+};
+
+/**
+ * Register a new display based on the given configuration
+ *
+ * @param config Configuration to use
+ * @return 0 if ok, -1 on error (unsupported bits per pixel)
+ */
+int tegra2_display_register(struct fdt_lcd *config);
+
+/**
+ * Perform the next stage of the LCD init if it is time to do so.
+ *
+ * LCD init can be time-consuming because of the number of delays we need
+ * while waiting for the backlight power supply, etc. This function can
+ * be called@various times during U-Boot operation to advance the
+ * initialization of the LCD to the next stage if sufficient time has
+ * passed since the last stage. It keeps track of what stage it is up to
+ * and the time that it is permitted to move to the next stage.
+ *
+ * The final call should have wait=1 to complete the init.
+ *
+ * @param blob fdt blob containing LCD information
+ * @param wait 1 to wait until all init is complete, and then return
+ * 0 to return immediately, potentially doing nothing if it is
+ * not yet time for the next init.
+ */
+int tegra_lcd_check_next_stage(const void *blob, int wait);
+
+/*
+ * Set up the maximum LCD size so we can size the frame buffer.
+ *
+ * @param blob fdt blob containing LCD information
+ */
+void tegra_lcd_early_init(const void *blob);
+
+#endif /*__ASM_ARCH_TEGRA_DISPLAY_H*/
--
1.7.7.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 09/19] tegra: Add SOC support for display/lcd
2012-06-13 16:19 ` [U-Boot] [PATCH v2 09/19] tegra: Add SOC support for display/lcd Simon Glass
@ 2012-06-14 23:39 ` Stephen Warren
[not found] ` <CAPnjgZ2bqPx+dHD9m+NuFrAbBeP1PQxHokLMwvD1-3OnC6ZHtg@mail.gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Stephen Warren @ 2012-06-14 23:39 UTC (permalink / raw)
To: u-boot
On 06/13/2012 10:19 AM, Simon Glass wrote:
> From: Wei Ni <wni@nvidia.com>
>
> Add support for the LCD peripheral at the Tegra2 SOC level. A separate
> LCD driver will use this functionality to configure the display.
> diff --git a/arch/arm/include/asm/arch-tegra2/display.h b/arch/arm/include/asm/arch-tegra2/display.h
> +/**
> + * Perform the next stage of the LCD init if it is time to do so.
> + *
> + * LCD init can be time-consuming because of the number of delays we need
> + * while waiting for the backlight power supply, etc. This function can
> + * be called at various times during U-Boot operation to advance the
> + * initialization of the LCD to the next stage if sufficient time has
> + * passed since the last stage. It keeps track of what stage it is up to
> + * and the time that it is permitted to move to the next stage.
> + *
> + * The final call should have wait=1 to complete the init.
> + *
> + * @param blob fdt blob containing LCD information
> + * @param wait 1 to wait until all init is complete, and then return
> + * 0 to return immediately, potentially doing nothing if it is
> + * not yet time for the next init.
> + */
> +int tegra_lcd_check_next_stage(const void *blob, int wait);
The prototype in the header seems to be the only mention of this function.
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 10/19] tegra: Add LCD driver
2012-06-13 16:19 [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Simon Glass
` (5 preceding siblings ...)
2012-06-13 16:19 ` [U-Boot] [PATCH v2 09/19] tegra: Add SOC support for display/lcd Simon Glass
@ 2012-06-13 16:19 ` Simon Glass
2012-06-14 23:45 ` Stephen Warren
2012-06-13 16:19 ` [U-Boot] [PATCH v2 11/19] tegra: Add LCD support to Nvidia boards Simon Glass
` (9 subsequent siblings)
16 siblings, 1 reply; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: u-boot
This driver supports driving a single LCD and providing a U-Boot console
on it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Update LCD driver to deal with new fdt bindings
drivers/video/Makefile | 1 +
drivers/video/tegra.c | 383 ++++++++++++++++++++++++++++++++++++++++++++++++
include/fdtdec.h | 1 +
lib/fdtdec.c | 1 +
4 files changed, 386 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/tegra.c
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 4fad20d..d7518c4 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -46,6 +46,7 @@ COBJS-$(CONFIG_VIDEO_OMAP3) += omap3_dss.o videomodes.o
COBJS-$(CONFIG_VIDEO_SED13806) += sed13806.o
COBJS-$(CONFIG_VIDEO_SM501) += sm501.o
COBJS-$(CONFIG_VIDEO_SMI_LYNXEM) += smiLynxEM.o videomodes.o
+COBJS-$(CONFIG_VIDEO_TEGRA) += tegra.o
COBJS-$(CONFIG_VIDEO_VCXK) += bus_vcxk.o
COBJS := $(sort $(COBJS-y))
diff --git a/drivers/video/tegra.c b/drivers/video/tegra.c
new file mode 100644
index 0000000..12518b2
--- /dev/null
+++ b/drivers/video/tegra.c
@@ -0,0 +1,383 @@
+/*
+ * Copyright (c) 2011 The Chromium OS Authors.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include <common.h>
+#include <fdtdec.h>
+#include <lcd.h>
+
+#include <asm/system.h>
+#include <asm/gpio.h>
+
+#include <asm/arch/clock.h>
+#include <asm/arch/funcmux.h>
+#include <asm/arch/pinmux.h>
+#include <asm/arch/pwfm.h>
+#include <asm/arch/display.h>
+#include <asm/arch/timer.h>
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* These are the stages we go throuh in enabling the LCD */
+enum stage_t {
+ STAGE_START,
+ STAGE_LVDS,
+ STAGE_BACKLIGHT_VDD,
+ STAGE_PWFM,
+ STAGE_BACKLIGHT_EN,
+ STAGE_DONE,
+};
+
+static enum stage_t stage; /* Current stage we are at */
+static unsigned long timer_next; /* Time we can move onto next stage */
+static struct fdt_lcd config; /* Our LCD config, set up in handle_stage() */
+
+enum {
+ /* Maximum LCD size we support */
+ LCD_MAX_WIDTH = 1366,
+ LCD_MAX_HEIGHT = 768,
+ LCD_MAX_LOG2_BPP = 4, /* 2^4 = 16 bpp */
+};
+
+int lcd_line_length;
+int lcd_color_fg;
+int lcd_color_bg;
+
+void *lcd_base; /* Start of framebuffer memory */
+void *lcd_console_address; /* Start of console buffer */
+
+short console_col;
+short console_row;
+
+vidinfo_t panel_info = {
+ /* Insert a value here so that we don't end up in the BSS */
+ .vl_col = -1,
+};
+
+char lcd_cursor_enabled;
+
+ushort lcd_cursor_width;
+ushort lcd_cursor_height;
+
+#ifndef CONFIG_OF_CONTROL
+#error "You must enable CONFIG_OF_CONTROL to get Tegra LCD support"
+#endif
+
+void lcd_cursor_size(ushort width, ushort height)
+{
+ lcd_cursor_width = width;
+ lcd_cursor_height = height;
+}
+
+void lcd_toggle_cursor(void)
+{
+ ushort x, y;
+ uchar *dest;
+ ushort row;
+
+ x = console_col * lcd_cursor_width;
+ y = console_row * lcd_cursor_height;
+ dest = (uchar *)(lcd_base + y * lcd_line_length + x * (1 << LCD_BPP) /
+ 8);
+
+ for (row = 0; row < lcd_cursor_height; ++row, dest += lcd_line_length) {
+ ushort *d = (ushort *)dest;
+ ushort color;
+ int i;
+
+ for (i = 0; i < lcd_cursor_width; ++i) {
+ color = *d;
+ color ^= lcd_color_fg;
+ *d = color;
+ ++d;
+ }
+ }
+}
+
+void lcd_cursor_on(void)
+{
+ lcd_cursor_enabled = 1;
+ lcd_toggle_cursor();
+}
+void lcd_cursor_off(void)
+{
+ lcd_cursor_enabled = 0;
+ lcd_toggle_cursor();
+}
+
+char lcd_is_cursor_enabled(void)
+{
+ return lcd_cursor_enabled;
+}
+
+static void update_panel_size(struct fdt_lcd *config)
+{
+ panel_info.vl_col = config->width;
+ panel_info.vl_row = config->height;
+ panel_info.vl_bpix = config->log2_bpp;
+}
+
+/*
+ * Main init function called by lcd driver.
+ * Inits and then prints test pattern if required.
+ */
+
+void lcd_ctrl_init(void *lcdbase)
+{
+ int line_length, size;
+
+ /*
+ * The framebuffer address should be specified in the device tree.
+ * This FDT value should be the same as the one defined in Linux kernel;
+ * otherwise, it causes screen flicker. The FDT value overrides the
+ * framebuffer allocated at the top of memory by board_init_f().
+ *
+ * If the framebuffer address is not defined in the FDT, falls back to
+ * use the address allocated by board_init_f().
+ */
+ if (config.frame_buffer != FDT_ADDR_T_NONE) {
+ gd->fb_base = config.frame_buffer;
+ lcd_base = (void *)(gd->fb_base);
+ } else {
+ config.frame_buffer = (u32)lcd_base;
+ }
+
+ /* Make sure that we can acommodate the selected LCD */
+ assert(config.width <= LCD_MAX_WIDTH);
+ assert(config.height <= LCD_MAX_HEIGHT);
+ assert(config.log2_bpp <= LCD_MAX_LOG2_BPP);
+ if (config.width <= LCD_MAX_WIDTH && config.height <= LCD_MAX_HEIGHT &&
+ config.log2_bpp <= LCD_MAX_LOG2_BPP)
+ update_panel_size(&config);
+ size = lcd_get_size(&line_length);
+
+ /* Initialize the Tegra display controller */
+ if (tegra2_display_register(&config)) {
+ printf("%s: Failed to register with display driver\n",
+ __func__);
+ return;
+ }
+
+ debug("LCD frame buffer@%p\n", lcd_base);
+}
+
+ulong calc_fbsize(void)
+{
+ return (panel_info.vl_col * panel_info.vl_row *
+ NBITS(panel_info.vl_bpix)) / 8;
+}
+
+void lcd_setcolreg(ushort regno, ushort red, ushort green, ushort blue)
+{
+}
+
+void tegra_lcd_early_init(const void *blob)
+{
+ /*
+ * Go with the maximum size for now. We will fix this up after
+ * relocation. These values are only used for memory alocation.
+ */
+ panel_info.vl_col = LCD_MAX_WIDTH;
+ panel_info.vl_row = LCD_MAX_HEIGHT;
+ panel_info.vl_bpix = LCD_MAX_LOG2_BPP;
+}
+
+int fdt_decode_lcd(const void *blob, struct fdt_lcd *config)
+{
+ int err, bpp, bit;
+ int lcd_node, display_node;
+
+ display_node = fdtdec_next_compatible(gd->fdt_blob, 0,
+ COMPAT_NVIDIA_TEGRA20_DISPLAY);
+ if (display_node < 0)
+ return display_node;
+
+ lcd_node = fdt_next_node(blob, display_node, NULL);
+ if (lcd_node < 0)
+ return lcd_node;
+
+ config->width = fdtdec_get_int(blob, lcd_node, "nvidia,width", -1);
+ config->height = fdtdec_get_int(blob, lcd_node, "nvidia,height", -1);
+ bpp = fdtdec_get_int(blob, lcd_node, "nvidia,bits-per-pixel", -1);
+ bit = ffs(bpp) - 1;
+ if (bpp == (1 << bit))
+ config->log2_bpp = bit;
+ else
+ config->log2_bpp = bpp;
+ config->bpp = bpp;
+ config->pixel_clock = fdtdec_get_int(blob, lcd_node,
+ "nvidia,pixel-clock", 0);
+ if (!config->pixel_clock || bpp == -1 ||
+ config->width == -1 || config->height == -1)
+ return -FDT_ERR_NOTFOUND;
+ err = fdtdec_get_int_array(blob, lcd_node, "nvidia,horiz-timing",
+ config->horiz_timing, FDT_LCD_TIMING_COUNT);
+ if (!err)
+ err = fdtdec_get_int_array(blob, lcd_node, "nvidia,vert-timing",
+ config->vert_timing, FDT_LCD_TIMING_COUNT);
+ if (err)
+ return err;
+
+ config->disp = (struct disp_ctlr *)fdtdec_get_addr(blob,
+ display_node, "reg");
+ config->pwfm = fdtdec_lookup_phandle_reg(blob, display_node,
+ "nvidia,pwfm");
+ if ((fdt_addr_t)config->disp == FDT_ADDR_T_NONE ||
+ (fdt_addr_t)config->pwfm == FDT_ADDR_T_NONE)
+ return -1;
+ config->cache_type = fdtdec_get_int(blob, display_node,
+ "nvidia,cache-type",
+ FDT_LCD_CACHE_WRITE_BACK_FLUSH);
+ config->frame_buffer = fdtdec_get_addr(blob, display_node,
+ "nvidia,frame-buffer");
+
+ err |= fdtdec_decode_gpio(blob, display_node,
+ "nvidia,backlight-enable-gpios",
+ &config->backlight_en);
+ err |= fdtdec_decode_gpio(blob, display_node,
+ "nvidia,lvds-shutdown-gpios", &config->lvds_shutdown);
+ fdtdec_decode_gpio(blob, display_node, "nvidia,backlight-vdd-gpios",
+ &config->backlight_vdd);
+ err |= fdtdec_decode_gpio(blob, display_node, "nvidia,panel-vdd-gpios",
+ &config->panel_vdd);
+ if (err)
+ return -FDT_ERR_NOTFOUND;
+
+ return fdtdec_get_int_array(blob, display_node, "nvidia,panel-timings",
+ config->panel_timings, FDT_LCD_TIMINGS);
+}
+
+/**
+ * Handle the next stage of device init
+ */
+static int handle_stage(const void *blob)
+{
+ debug("%s: stage %d\n", __func__, stage);
+
+ /* do the things for this stage */
+ switch (stage) {
+ case STAGE_START:
+ /* get panel details */
+ if (fdt_decode_lcd(blob, &config)) {
+ printf("No LCD information in device tree\n");
+ return -1;
+ }
+
+ /*
+ * It is possible that the FDT has requested that the LCD be
+ * disabled. We currently don't support this. It would require
+ * changes to U-Boot LCD subsystem to have LCD support
+ * compiled in but not used. An easier option might be to
+ * still have a frame buffer, but leave the backlight off and
+ * remove all mention of lcd in the stdout environment
+ * variable.
+ */
+
+ funcmux_select(PERIPH_ID_DISP1, FUNCMUX_DEFAULT);
+
+ fdtdec_setup_gpio(&config.panel_vdd);
+ fdtdec_setup_gpio(&config.lvds_shutdown);
+ fdtdec_setup_gpio(&config.backlight_vdd);
+ fdtdec_setup_gpio(&config.backlight_en);
+
+ /*
+ * TODO: If fdt includes output flag we can omit this code
+ * since fdtdec_setup_gpio will do it for us.
+ */
+ gpio_direction_output(config.panel_vdd.gpio, 1);
+ gpio_direction_output(config.lvds_shutdown.gpio, 0);
+ gpio_direction_output(config.backlight_vdd.gpio, 0);
+ gpio_direction_output(config.backlight_en.gpio, 0);
+ break;
+
+ case STAGE_LVDS:
+ gpio_set_value(config.lvds_shutdown.gpio, 1);
+ break;
+
+ case STAGE_BACKLIGHT_VDD:
+ if (fdt_gpio_isvalid(&config.backlight_vdd))
+ gpio_set_value(config.backlight_vdd.gpio, 1);
+ break;
+
+ case STAGE_PWFM:
+ /* Enable PWM at 15/16 high, 32768 Hz with divider 1 */
+ pinmux_set_func(PINGRP_GPU, PMUX_FUNC_PWM);
+ pinmux_tristate_disable(PINGRP_GPU);
+ pwfm_enable(config.pwfm, 32768, 0xdf, 1);
+ break;
+
+ case STAGE_BACKLIGHT_EN:
+ gpio_set_value(config.backlight_en.gpio, 1);
+ break;
+
+ case STAGE_DONE:
+ break;
+ }
+
+ /* set up timer for next stage */
+ timer_next = timer_get_us() + config.panel_timings[stage] * 1000;
+
+ /* move to next stage */
+ stage++;
+ return 0;
+}
+
+int tegra_lcd_check_next_stage(const void *blob, int wait)
+{
+ if (stage == STAGE_DONE)
+ return 0;
+
+ do {
+ /* wait if we need to */
+ debug("%s: stage %d\n", __func__, stage);
+ if (stage != STAGE_START) {
+ int delay = timer_next - timer_get_us();
+
+ if (delay > 0) {
+ if (wait)
+ udelay(delay);
+ else
+ return 0;
+ }
+ }
+
+ if (handle_stage(blob))
+ return -1;
+ } while (wait && stage != STAGE_DONE);
+ return 0;
+}
+
+void lcd_enable(void)
+{
+ /*
+ * Backlight and power init will be done separately in
+ * tegra_lcd_check_next_stage(), which should be called in
+ * board_late_init().
+ *
+ * U-Boot code supports only colour depth, selected at compile time.
+ * The device tree setting should match this. Otherwise the display
+ * will not look right, and U-Boot may crash.
+ */
+ if (config.log2_bpp != LCD_BPP) {
+ printf("%s: Error: LCD depth configured in FDT (%d = %dbpp)"
+ " must match setting of LCD_BPP (%d)\n", __func__,
+ config.log2_bpp, config.bpp, LCD_BPP);
+ }
+}
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 627d077..c1aad5c 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -65,6 +65,7 @@ enum fdt_compat_id {
COMPAT_NVIDIA_TEGRA20_EMC, /* Tegra2 memory controller */
COMPAT_NVIDIA_TEGRA20_EMC_TABLE, /* Tegra2 memory timing table */
COMPAT_NVIDIA_TEGRA20_KBC, /* Tegra2 Keyboard */
+ COMPAT_NVIDIA_TEGRA20_DISPLAY, /* Tegra 2 Display controller */
COMPAT_COUNT,
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 8185d8f..2d68c17 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -43,6 +43,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(NVIDIA_TEGRA20_EMC, "nvidia,tegra20-emc"),
COMPAT(NVIDIA_TEGRA20_EMC_TABLE, "nvidia,tegra20-emc-table"),
COMPAT(NVIDIA_TEGRA20_KBC, "nvidia,tegra20-kbc"),
+ COMPAT(NVIDIA_TEGRA20_DISPLAY, "nvidia,tegra20-display"),
};
const char *fdtdec_get_compatible(enum fdt_compat_id id)
--
1.7.7.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 10/19] tegra: Add LCD driver
2012-06-13 16:19 ` [U-Boot] [PATCH v2 10/19] tegra: Add LCD driver Simon Glass
@ 2012-06-14 23:45 ` Stephen Warren
2012-07-11 4:56 ` Simon Glass
0 siblings, 1 reply; 67+ messages in thread
From: Stephen Warren @ 2012-06-14 23:45 UTC (permalink / raw)
To: u-boot
On 06/13/2012 10:19 AM, Simon Glass wrote:
> This driver supports driving a single LCD and providing a U-Boot console
> on it.
> +int fdt_decode_lcd(const void *blob, struct fdt_lcd *config)
> + fdtdec_decode_gpio(blob, display_node, "nvidia,backlight-vdd-gpios",
> + &config->backlight_vdd);
Given that's a power supply control, I expect this to be represented as
a regulator in the DT, not as a simple GPIO (it could be controlled by a
register bit in a PMU on some boards).
> +void lcd_enable(void)
> +{
> + /*
> + * Backlight and power init will be done separately in
> + * tegra_lcd_check_next_stage(), which should be called in
> + * board_late_init().
> + *
> + * U-Boot code supports only colour depth, selected at compile time.
> + * The device tree setting should match this. Otherwise the display
> + * will not look right, and U-Boot may crash.
> + */
> + if (config.log2_bpp != LCD_BPP) {
> + printf("%s: Error: LCD depth configured in FDT (%d = %dbpp)"
> + " must match setting of LCD_BPP (%d)\n", __func__,
> + config.log2_bpp, config.bpp, LCD_BPP);
> + }
> +}
I wonder why even read the configuration from DT if the value can't be used?
> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> @@ -43,6 +43,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
> + COMPAT(NVIDIA_TEGRA20_DISPLAY, "nvidia,tegra20-display"),
Surely all the DT plumbing for the display controller itself should be
in the previous patch that adds the display controller driver.
The LCD stuff that sits on top of that seems like it should be a
separate node in DT, and the two patches kept much more separate.
^ permalink raw reply [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 10/19] tegra: Add LCD driver
2012-06-14 23:45 ` Stephen Warren
@ 2012-07-11 4:56 ` Simon Glass
0 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-07-11 4:56 UTC (permalink / raw)
To: u-boot
Hi Stephen,
On Fri, Jun 15, 2012 at 1:45 AM, Stephen Warren <swarren@wwwdotorg.org>wrote:
> On 06/13/2012 10:19 AM, Simon Glass wrote:
> > This driver supports driving a single LCD and providing a U-Boot console
> > on it.
>
> > +int fdt_decode_lcd(const void *blob, struct fdt_lcd *config)
>
> > + fdtdec_decode_gpio(blob, display_node,
> "nvidia,backlight-vdd-gpios",
> > + &config->backlight_vdd);
>
> Given that's a power supply control, I expect this to be represented as
> a regulator in the DT, not as a simple GPIO (it could be controlled by a
> register bit in a PMU on some boards).
>
Hmm we don't have regulator support in U-Boot as yet. Any ideas? It is
possible that it might come towards the end of the year as part of some
other upstreaming work, but I am not sure. At lot of these sorts of things
are really hard in U-Boot until we have a device model.
> > +void lcd_enable(void)
> > +{
> > + /*
> > + * Backlight and power init will be done separately in
> > + * tegra_lcd_check_next_stage(), which should be called in
> > + * board_late_init().
> > + *
> > + * U-Boot code supports only colour depth, selected at compile
> time.
> > + * The device tree setting should match this. Otherwise the display
> > + * will not look right, and U-Boot may crash.
> > + */
> > + if (config.log2_bpp != LCD_BPP) {
> > + printf("%s: Error: LCD depth configured in FDT (%d =
> %dbpp)"
> > + " must match setting of LCD_BPP (%d)\n", __func__,
> > + config.log2_bpp, config.bpp, LCD_BPP);
> > + }
> > +}
>
> I wonder why even read the configuration from DT if the value can't be
> used?
>
The conflict is in one place and has a clear warning, so if U-Boot does
support this in the future, we can adjust it.
>
> > diff --git a/lib/fdtdec.c b/lib/fdtdec.c
>
> > @@ -43,6 +43,7 @@ static const char * const compat_names[COMPAT_COUNT] =
> {
>
> > + COMPAT(NVIDIA_TEGRA20_DISPLAY, "nvidia,tegra20-display"),
>
> Surely all the DT plumbing for the display controller itself should be
> in the previous patch that adds the display controller driver.
>
> The LCD stuff that sits on top of that seems like it should be a
> separate node in DT, and the two patches kept much more separate.
>
I have made the LCD a subnode of the display controller. Let's see what
Thierry says about the kernel binding.
I will move this compatible string to the previous patch.
Regards,
Simon
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 11/19] tegra: Add LCD support to Nvidia boards
2012-06-13 16:19 [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Simon Glass
` (6 preceding siblings ...)
2012-06-13 16:19 ` [U-Boot] [PATCH v2 10/19] tegra: Add LCD driver Simon Glass
@ 2012-06-13 16:19 ` Simon Glass
2012-06-14 23:47 ` Stephen Warren
2012-06-13 16:19 ` [U-Boot] [PATCH v2 12/19] arm: Add control over cachability of memory regions Simon Glass
` (8 subsequent siblings)
16 siblings, 1 reply; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: u-boot
Add calls to the LCD driver from Nvidia board code.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
board/nvidia/common/board.c | 21 ++++++++++++++++++++-
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
index 2e22133..7666691 100644
--- a/board/nvidia/common/board.c
+++ b/board/nvidia/common/board.c
@@ -29,6 +29,7 @@
#include <asm/arch/sys_proto.h>
#include <asm/arch/board.h>
+#include <asm/arch/display.h>
#include <asm/arch/clk_rst.h>
#include <asm/arch/clock.h>
#include <asm/arch/emc.h>
@@ -87,6 +88,9 @@ int board_init(void)
{
__maybe_unused int err;
+#ifdef CONFIG_VIDEO_TEGRA2
+ tegra_lcd_check_next_stage(gd->blob, 0);
+#endif
/* Do clocks and UART first so that printf() works */
clock_init();
clock_verify();
@@ -122,6 +126,9 @@ int board_init(void)
pin_mux_usb();
board_usb_init(gd->fdt_blob);
#endif
+#if defined(CONFIG_VIDEO_TEGRA)
+ tegra_lcd_check_next_stage(gd->fdt_blob, 0);
+#endif
#ifdef CONFIG_TEGRA2_LP0
/* prepare the WB code to LP0 location */
@@ -142,6 +149,18 @@ int board_early_init_f(void)
#else
gpio_config_uart();
#endif
- return 0;
+#if defined(CONFIG_VIDEO_TEGRA)
+ tegra_lcd_early_init(gd->fdt_blob);
+#endif
+return 0;
}
#endif /* EARLY_INIT */
+
+int board_late_init(void)
+{
+#ifdef CONFIG_VIDEO_TEGRA
+ /* Make sure we finish initing the LCD */
+ tegra_lcd_check_next_stage(gd->fdt_blob, 1);
+#endif
+ return 0;
+}
--
1.7.7.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 11/19] tegra: Add LCD support to Nvidia boards
2012-06-13 16:19 ` [U-Boot] [PATCH v2 11/19] tegra: Add LCD support to Nvidia boards Simon Glass
@ 2012-06-14 23:47 ` Stephen Warren
2012-07-11 4:58 ` Simon Glass
0 siblings, 1 reply; 67+ messages in thread
From: Stephen Warren @ 2012-06-14 23:47 UTC (permalink / raw)
To: u-boot
On 06/13/2012 10:19 AM, Simon Glass wrote:
> Add calls to the LCD driver from Nvidia board code.
> diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
> @@ -87,6 +88,9 @@ int board_init(void)
> +#ifdef CONFIG_VIDEO_TEGRA2
> + tegra_lcd_check_next_stage(gd->blob, 0);
> +#endif
This seems to be conflating video support with LCD support. It would be
quite possible to have a board with no LCD, yet supporting display over
HDMI for example. In other words, shouldn't the ifdef above be something
more like:
#if define(CONFIG_LCD_SUPPORT)
register_lcd_driver();
#endif
#if defined(CONFIG_VIDEO_TEGRA2)
tegra_display_init(...);
#endif
and internal to tegra_display_init(), the DT is searched for LCD
controller nodes, and if any are found, they're matched to the LCD
driver registered by the first call above.
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 11/19] tegra: Add LCD support to Nvidia boards
2012-06-14 23:47 ` Stephen Warren
@ 2012-07-11 4:58 ` Simon Glass
2012-07-23 20:25 ` Stephen Warren
0 siblings, 1 reply; 67+ messages in thread
From: Simon Glass @ 2012-07-11 4:58 UTC (permalink / raw)
To: u-boot
Hi Stephen,
On Fri, Jun 15, 2012 at 1:47 AM, Stephen Warren <swarren@wwwdotorg.org>wrote:
> On 06/13/2012 10:19 AM, Simon Glass wrote:
> > Add calls to the LCD driver from Nvidia board code.
>
> > diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
>
> > @@ -87,6 +88,9 @@ int board_init(void)
>
> > +#ifdef CONFIG_VIDEO_TEGRA2
> > + tegra_lcd_check_next_stage(gd->blob, 0);
> > +#endif
>
> This seems to be conflating video support with LCD support. It would be
> quite possible to have a board with no LCD, yet supporting display over
> HDMI for example. In other words, shouldn't the ifdef above be something
> more like:
>
> #if define(CONFIG_LCD_SUPPORT)
> register_lcd_driver();
> #endif
> #if defined(CONFIG_VIDEO_TEGRA2)
> tegra_display_init(...);
> #endif
>
> and internal to tegra_display_init(), the DT is searched for LCD
> controller nodes, and if any are found, they're matched to the LCD
> driver registered by the first call above.
>
Yes that sounds great, but again we don't really have this infrastructure
in U-Boot. We would be inventing it just for Tegra, and I would prefer to
wait until the device model stuff is done before being too fancy.
We don't have an HDMI driver at present, so perhaps if/when that appears in
U-Boot it would be a good time to add support for that?
Regards,
Simon
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 11/19] tegra: Add LCD support to Nvidia boards
2012-07-11 4:58 ` Simon Glass
@ 2012-07-23 20:25 ` Stephen Warren
2012-09-27 19:15 ` Simon Glass
0 siblings, 1 reply; 67+ messages in thread
From: Stephen Warren @ 2012-07-23 20:25 UTC (permalink / raw)
To: u-boot
On 07/10/2012 10:58 PM, Simon Glass wrote:
> Hi Stephen,
>
> On Fri, Jun 15, 2012 at 1:47 AM, Stephen Warren <swarren@wwwdotorg.org
> <mailto:swarren@wwwdotorg.org>> wrote:
>
> On 06/13/2012 10:19 AM, Simon Glass wrote:
> > Add calls to the LCD driver from Nvidia board code.
>
> > diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
>
> > @@ -87,6 +88,9 @@ int board_init(void)
>
> > +#ifdef CONFIG_VIDEO_TEGRA2
> > + tegra_lcd_check_next_stage(gd->blob, 0);
> > +#endif
>
> This seems to be conflating video support with LCD support. It would be
> quite possible to have a board with no LCD, yet supporting display over
> HDMI for example. In other words, shouldn't the ifdef above be something
> more like:
>
> #if define(CONFIG_LCD_SUPPORT)
> register_lcd_driver();
> #endif
> #if defined(CONFIG_VIDEO_TEGRA2)
> tegra_display_init(...);
> #endif
>
> and internal to tegra_display_init(), the DT is searched for LCD
> controller nodes, and if any are found, they're matched to the LCD
> driver registered by the first call above.
>
>
> Yes that sounds great, but again we don't really have this
> infrastructure in U-Boot. We would be inventing it just for Tegra, and I
> would prefer to wait until the device model stuff is done before being
> too fancy.
What is "the device model stuff" you mention?
> We don't have an HDMI driver at present, so perhaps if/when that appears
> in U-Boot it would be a good time to add support for that?
Certainly adding code for HDMI can wait until later. However, I do think
that we should use the correct ifdefs up-front, so that e.g. adding HDMI
support only means adding a bunch of code, not going through the
existing code and untangling conflated ifdefs.
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 11/19] tegra: Add LCD support to Nvidia boards
2012-07-23 20:25 ` Stephen Warren
@ 2012-09-27 19:15 ` Simon Glass
0 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-09-27 19:15 UTC (permalink / raw)
To: u-boot
Hi Stephen,
On Mon, Jul 23, 2012 at 1:25 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 07/10/2012 10:58 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On Fri, Jun 15, 2012 at 1:47 AM, Stephen Warren <swarren@wwwdotorg.org
>> <mailto:swarren@wwwdotorg.org>> wrote:
>>
>> On 06/13/2012 10:19 AM, Simon Glass wrote:
>> > Add calls to the LCD driver from Nvidia board code.
>>
>> > diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
>>
>> > @@ -87,6 +88,9 @@ int board_init(void)
>>
>> > +#ifdef CONFIG_VIDEO_TEGRA2
>> > + tegra_lcd_check_next_stage(gd->blob, 0);
>> > +#endif
>>
>> This seems to be conflating video support with LCD support. It would be
>> quite possible to have a board with no LCD, yet supporting display over
>> HDMI for example. In other words, shouldn't the ifdef above be something
>> more like:
>>
>> #if define(CONFIG_LCD_SUPPORT)
>> register_lcd_driver();
>> #endif
>> #if defined(CONFIG_VIDEO_TEGRA2)
>> tegra_display_init(...);
>> #endif
>>
>> and internal to tegra_display_init(), the DT is searched for LCD
>> controller nodes, and if any are found, they're matched to the LCD
>> driver registered by the first call above.
>>
>>
>> Yes that sounds great, but again we don't really have this
>> infrastructure in U-Boot. We would be inventing it just for Tegra, and I
>> would prefer to wait until the device model stuff is done before being
>> too fancy.
>
> What is "the device model stuff" you mention?
There is an effort in U-Boot to create a unified device model, which
would permit things like the register_lcd_driver() call you show
above. At present we have hard-coded calls to various things in
U-Boot. This means that in many cases it is only possible to have one
driver of each time.
This also applied to LCD - at present it wouldn't be possible to
support HDMI separate from LCD, unless the HDMI stuff was perhaps done
through the separate CONFIG_VIDEO option. That would be odd though,
since we are using the display controller.
Maybe I am wrong, but this doesn't seem like the right time to address
this issue. Once the device model is in, we will find this sort of
thing much easier and cleaner.
>
>> We don't have an HDMI driver at present, so perhaps if/when that appears
>> in U-Boot it would be a good time to add support for that?
>
> Certainly adding code for HDMI can wait until later. However, I do think
> that we should use the correct ifdefs up-front, so that e.g. adding HDMI
> support only means adding a bunch of code, not going through the
> existing code and untangling conflated ifdefs.
Well you are right, it is conflated, although not only in the ifdefs!
I'm afraid that all the code currently deals with setting up the
display driver for an LCD - e.g. the code in display.c which sets up
clocks and LCD outputs/pinmux, plus the whole of
drivers/video/tegra.c. To be honest, the ifdefs are the least of our
problems.
For HDMI the whole thing would need another look I believe. But the
purpose of this series is to provide LCD support on Tegra and
unfortunately it isn't clear to me what the differences might be for
HDMI.
I will change this to use CONFIG_LCD since it is definitely more correct.
Regards,
Simon
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 12/19] arm: Add control over cachability of memory regions
2012-06-13 16:19 [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Simon Glass
` (7 preceding siblings ...)
2012-06-13 16:19 ` [U-Boot] [PATCH v2 11/19] tegra: Add LCD support to Nvidia boards Simon Glass
@ 2012-06-13 16:19 ` Simon Glass
2012-06-14 23:49 ` Stephen Warren
2012-06-13 16:19 ` [U-Boot] [PATCH v2 13/19] lcd: Add CONFIG_LCD_ALIGNMENT to select frame buffer alignment Simon Glass
` (7 subsequent siblings)
16 siblings, 1 reply; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: u-boot
Add support for adjusting the cachability of an L1 section by updating
the MMU. The mmu_set_region_dcache() function allows drivers to make
these changes after the MMU is set up.
It is implemented only for ARMv7 at present.
This is needed for LCD support, where we want to make the LCD frame buffer
write-through (or off) rather than write-back.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
arch/arm/cpu/armv7/cache_v7.c | 11 +++++++
arch/arm/include/asm/system.h | 30 ++++++++++++++++++++
arch/arm/lib/cache-cp15.c | 62 +++++++++++++++++++++++++++++++++-------
3 files changed, 92 insertions(+), 11 deletions(-)
diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
index 1b4e808..5f6d039 100644
--- a/arch/arm/cpu/armv7/cache_v7.c
+++ b/arch/arm/cpu/armv7/cache_v7.c
@@ -297,6 +297,12 @@ void arm_init_before_mmu(void)
v7_inval_tlb();
}
+void mmu_page_table_flush(unsigned long start, unsigned long stop)
+{
+ flush_dcache_range(start, stop);
+ v7_inval_tlb();
+}
+
/*
* Flush range from all levels of d-cache/unified-cache used:
* Affects the range [start, start + size - 1]
@@ -329,6 +335,11 @@ void arm_init_before_mmu(void)
void flush_cache(unsigned long start, unsigned long size)
{
}
+
+void mmu_page_table_flush(unsigned long start, unsigned long stop)
+{
+}
+
#endif /* #ifndef CONFIG_SYS_DCACHE_OFF */
#ifndef CONFIG_SYS_ICACHE_OFF
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 2b28a26..f52a4fc 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -75,6 +75,36 @@ static inline void set_cr(unsigned int val)
isb();
}
+/* options available for data cache on each page */
+enum dcache_option {
+ DCACHE_OFF,
+ DCACHE_WRITETHROUGH,
+ DCACHE_WRITEBACK,
+};
+
+/* Size of an MMU section */
+enum {
+ MMU_SECTION_SHIFT = 20,
+ MMU_SECTION_SIZE = 1 << MMU_SECTION_SHIFT,
+};
+
+/**
+ * Change the cache settings for a region.
+ *
+ * \param start start address of memory region to change
+ * \param size size of memory region to change
+ * \param option dcache option to select
+ */
+void mmu_set_region_dcache(u32 start, int size, enum dcache_option option);
+
+/**
+ * Register an update to the page tables, and flush the TLB
+ *
+ * \param start start address of update in page table
+ * \param stop stop address of update in page table
+ */
+void mmu_page_table_flush(unsigned long start, unsigned long stop);
+
#endif /* __ASSEMBLY__ */
#define arch_align_stack(x) (x)
diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
index e6c3eae..facb1a7 100644
--- a/arch/arm/lib/cache-cp15.c
+++ b/arch/arm/lib/cache-cp15.c
@@ -26,12 +26,6 @@
#if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
-#if defined(CONFIG_SYS_ARM_CACHE_WRITETHROUGH)
-#define CACHE_SETUP 0x1a
-#else
-#define CACHE_SETUP 0x1e
-#endif
-
DECLARE_GLOBAL_DATA_PTR;
void __arm_init_before_mmu(void)
@@ -50,9 +44,52 @@ static void cp_delay (void)
asm volatile("" : : : "memory");
}
-static inline void dram_bank_mmu_setup(int bank)
+void set_section_dcache(int section, enum dcache_option option)
{
+ u32 value = section << MMU_SECTION_SHIFT | (3 << 10);
u32 *page_table = (u32 *)gd->tlb_addr;
+
+ switch (option) {
+ case DCACHE_WRITETHROUGH:
+ value |= 0x1a;
+ break;
+
+ case DCACHE_WRITEBACK:
+ value |= 0x1e;
+ break;
+
+ case DCACHE_OFF:
+ value |= 0x12;
+ break;
+ }
+
+ page_table[section] = value;
+}
+
+void __mmu_page_table_flush(unsigned long start, unsigned long stop)
+{
+ debug("%s: Warning: not implemented\n", __func__);
+}
+
+void mmu_page_table_flush(unsigned long start, unsigned long stop)
+ __attribute__((weak, alias("__mmu_page_table_flush")));
+
+void mmu_set_region_dcache(u32 start, int size, enum dcache_option option)
+{
+ u32 *page_table = (u32 *)gd->tlb_addr;
+ u32 upto, end;
+
+ end = ALIGN(start + size, MMU_SECTION_SIZE) >> MMU_SECTION_SHIFT;
+ start = start >> MMU_SECTION_SHIFT;
+ debug("mmu_set_region_dcache start=%x, size=%x, option=%d\n",
+ start, size, option);
+ for (upto = start; upto < end; upto++)
+ set_section_dcache(upto, option);
+ mmu_page_table_flush((u32)&page_table[start], (u32)&page_table[end]);
+}
+
+static inline void dram_bank_mmu_setup(int bank)
+{
bd_t *bd = gd->bd;
int i;
@@ -60,21 +97,24 @@ static inline void dram_bank_mmu_setup(int bank)
for (i = bd->bi_dram[bank].start >> 20;
i < (bd->bi_dram[bank].start + bd->bi_dram[bank].size) >> 20;
i++) {
- page_table[i] = i << 20 | (3 << 10) | CACHE_SETUP;
+#if defined(CONFIG_SYS_ARM_CACHE_WRITETHROUGH)
+ set_section_dcache(i, DCACHE_WRITETHROUGH);
+#else
+ set_section_dcache(i, DCACHE_WRITEBACK);
+#endif
}
}
/* to activate the MMU we need to set up virtual memory: use 1M areas */
static inline void mmu_setup(void)
{
- u32 *page_table = (u32 *)gd->tlb_addr;
int i;
u32 reg;
arm_init_before_mmu();
/* Set up an identity-mapping for all 4GB, rw for everyone */
for (i = 0; i < 4096; i++)
- page_table[i] = i << 20 | (3 << 10) | 0x12;
+ set_section_dcache(i, DCACHE_OFF);
for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
dram_bank_mmu_setup(i);
@@ -82,7 +122,7 @@ static inline void mmu_setup(void)
/* Copy the page table address to cp15 */
asm volatile("mcr p15, 0, %0, c2, c0, 0"
- : : "r" (page_table) : "memory");
+ : : "r" (gd->tlb_addr) : "memory");
/* Set the access control to all-supervisor */
asm volatile("mcr p15, 0, %0, c3, c0, 0"
: : "r" (~0));
--
1.7.7.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 12/19] arm: Add control over cachability of memory regions
2012-06-13 16:19 ` [U-Boot] [PATCH v2 12/19] arm: Add control over cachability of memory regions Simon Glass
@ 2012-06-14 23:49 ` Stephen Warren
2012-07-11 5:01 ` Simon Glass
0 siblings, 1 reply; 67+ messages in thread
From: Stephen Warren @ 2012-06-14 23:49 UTC (permalink / raw)
To: u-boot
On 06/13/2012 10:19 AM, Simon Glass wrote:
> Add support for adjusting the cachability of an L1 section by updating
> the MMU. The mmu_set_region_dcache() function allows drivers to make
> these changes after the MMU is set up.
>
> It is implemented only for ARMv7 at present.
>
> This is needed for LCD support, where we want to make the LCD frame buffer
> write-through (or off) rather than write-back.
Wouldn't performance be significantly better if the region was fully
cached, but flushed after each display surface update?
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 12/19] arm: Add control over cachability of memory regions
2012-06-14 23:49 ` Stephen Warren
@ 2012-07-11 5:01 ` Simon Glass
0 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-07-11 5:01 UTC (permalink / raw)
To: u-boot
Hi Stephen,
On Fri, Jun 15, 2012 at 1:49 AM, Stephen Warren <swarren@wwwdotorg.org>wrote:
> On 06/13/2012 10:19 AM, Simon Glass wrote:
> > Add support for adjusting the cachability of an L1 section by updating
> > the MMU. The mmu_set_region_dcache() function allows drivers to make
> > these changes after the MMU is set up.
> >
> > It is implemented only for ARMv7 at present.
> >
> > This is needed for LCD support, where we want to make the LCD frame
> buffer
> > write-through (or off) rather than write-back.
>
> Wouldn't performance be significantly better if the region was fully
> cached, but flushed after each display surface update?
>
That is the setting used on Tegra, yes. This function permits selection of
the three options.
Regards,
Simon
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 13/19] lcd: Add CONFIG_LCD_ALIGNMENT to select frame buffer alignment
2012-06-13 16:19 [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Simon Glass
` (8 preceding siblings ...)
2012-06-13 16:19 ` [U-Boot] [PATCH v2 12/19] arm: Add control over cachability of memory regions Simon Glass
@ 2012-06-13 16:19 ` Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 14/19] lcd: Add support for flushing LCD fb from dcache after update Simon Glass
` (6 subsequent siblings)
16 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: u-boot
The normal alignment is PAGE_SIZE, but if this is defined, we can support
other alignments.
The motivation for this change is to make the display section-aligned on
ARM so that we can easily turn off data caching for the frame buffer region
without resorting to level 2 page tables.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Use a more generic config CONFIG_LCD_ALIGNMENT for lcd alignment
README | 10 ++++++++++
common/lcd.c | 24 +++++++++++++++++++-----
include/lcd.h | 3 +++
3 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/README b/README
index 67dc444..ccdddbf 100644
--- a/README
+++ b/README
@@ -1398,6 +1398,16 @@ The following options need to be configured:
Normally display is black on white background; define
CONFIG_SYS_WHITE_ON_BLACK to get it inverted.
+
+ CONFIG_LCD_ALIGNMENT
+
+ Normally the LCD is page-aligned (tyically 4KB). If this is
+ defined then the LCD will be aligned to this value instead.
+ For ARM it is sometimes useful to use MMU_SECTION_SIZE
+ here, since it is cheaper to change data cache settings on
+ a per-section basis.
+
+
- Splash Screen Support: CONFIG_SPLASH_SCREEN
If this option is set, the environment is checked for
diff --git a/common/lcd.c b/common/lcd.c
index bf1a6a9..c915a49 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -35,6 +35,9 @@
#include <stdarg.h>
#include <linux/types.h>
#include <stdio_dev.h>
+#ifdef CONFIG_ARM
+#include <asm/system.h>
+#endif
#if defined(CONFIG_POST)
#include <post.h>
#endif
@@ -72,6 +75,10 @@
# endif
#endif
+#ifndef CONFIG_LCD_ALIGNMENT
+#define CONFIG_LCD_ALIGNMENT PAGE_SIZE
+#endif
+
DECLARE_GLOBAL_DATA_PTR;
ulong lcd_setmem (ulong addr);
@@ -330,6 +337,12 @@ static void test_pattern (void)
/* ** GENERIC Initialization Routines */
/************************************************************************/
+int lcd_get_size(int *line_length)
+{
+ *line_length = (panel_info.vl_col * NBITS(panel_info.vl_bpix)) / 8;
+ return *line_length * panel_info.vl_row;
+}
+
int drv_lcd_init (void)
{
struct stdio_dev lcddev;
@@ -337,7 +350,7 @@ int drv_lcd_init (void)
lcd_base = (void *)(gd->fb_base);
- lcd_line_length = (panel_info.vl_col * NBITS (panel_info.vl_bpix)) / 8;
+ lcd_get_size(&lcd_line_length);
lcd_init (lcd_base); /* LCD initialization */
@@ -449,15 +462,16 @@ static int lcd_init (void *lcdbase)
ulong lcd_setmem (ulong addr)
{
ulong size;
- int line_length = (panel_info.vl_col * NBITS (panel_info.vl_bpix)) / 8;
+ int line_length;
debug ("LCD panel info: %d x %d, %d bit/pix\n",
panel_info.vl_col, panel_info.vl_row, NBITS (panel_info.vl_bpix) );
- size = line_length * panel_info.vl_row;
+ size = lcd_get_size(&line_length);
- /* Round up to nearest full page */
- size = (size + (PAGE_SIZE - 1)) & ~(PAGE_SIZE - 1);
+ /* Round up to nearest full page, or MMU section if defined */
+ size = ALIGN(size, CONFIG_LCD_ALIGNMENT);
+ addr = ALIGN(addr - CONFIG_LCD_ALIGNMENT + 1, CONFIG_LCD_ALIGNMENT);
/* Allocate pages for the frame buffer. */
addr -= size;
diff --git a/include/lcd.h b/include/lcd.h
index 3d9ef16..5016d6b 100644
--- a/include/lcd.h
+++ b/include/lcd.h
@@ -281,6 +281,9 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y);
/* Allow boards to customize the information displayed */
void lcd_show_board_info(void);
+/* Return the size of the LCD frame buffer, and the line length */
+int lcd_get_size(int *line_length);
+
/************************************************************************/
/* ** BITMAP DISPLAY SUPPORT */
/************************************************************************/
--
1.7.7.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 14/19] lcd: Add support for flushing LCD fb from dcache after update
2012-06-13 16:19 [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Simon Glass
` (9 preceding siblings ...)
2012-06-13 16:19 ` [U-Boot] [PATCH v2 13/19] lcd: Add CONFIG_LCD_ALIGNMENT to select frame buffer alignment Simon Glass
@ 2012-06-13 16:19 ` Simon Glass
2012-06-14 23:51 ` Stephen Warren
2012-06-13 16:19 ` [U-Boot] [PATCH v2 15/19] tegra: Align LCD frame buffer to section boundary Simon Glass
` (5 subsequent siblings)
16 siblings, 1 reply; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: u-boot
This provides an option for the LCD to flush the dcache after each update
(puts, scroll or clear).
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Put the LCD cache flush logic into lcd_putc() instead of lcd_puts()
common/cmd_echo.c | 3 ++-
common/lcd.c | 45 ++++++++++++++++++++++++++++++++++++++-------
include/lcd.h | 8 ++++++++
3 files changed, 48 insertions(+), 8 deletions(-)
diff --git a/common/cmd_echo.c b/common/cmd_echo.c
index 43a6da5..12efbab 100644
--- a/common/cmd_echo.c
+++ b/common/cmd_echo.c
@@ -44,8 +44,9 @@ int do_echo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
}
}
+ /* Use puts() so that the LCD sees it as a new line */
if (putnl)
- putc('\n');
+ puts("\n");
return 0;
}
diff --git a/common/lcd.c b/common/lcd.c
index c915a49..758f158 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -97,6 +97,9 @@ static void lcd_setbgcolor (int color);
char lcd_is_enabled = 0;
+static char lcd_flush_dcache; /* 1 to flush dcache after each lcd update */
+
+
#ifdef NOT_USED_SO_FAR
static void lcd_getcolreg (ushort regno,
ushort *red, ushort *green, ushort *blue);
@@ -105,6 +108,28 @@ static int lcd_getfgcolor (void);
/************************************************************************/
+/* Flush LCD activity to the caches */
+void lcd_sync(void)
+{
+ /*
+ * flush_dcache_range() is declared in common.h but it seems that some
+ * architectures do not actually implement it. Is there a way to find
+ * out whether it exists? For now, ARM is safe.
+ */
+#ifdef CONFIG_ARM
+ int line_length;
+
+ if (lcd_flush_dcache)
+ flush_dcache_range((u32)lcd_base,
+ (u32)(lcd_base + lcd_get_size(&line_length)));
+#endif
+}
+
+void lcd_set_flush_dcache(int flush)
+{
+ lcd_flush_dcache = (flush != 0);
+}
+
/*----------------------------------------------------------------------*/
static void console_scrollup (void)
@@ -114,6 +139,7 @@ static void console_scrollup (void)
/* Clear the last one */
memset (CONSOLE_ROW_LAST, COLOR_MASK(lcd_color_bg), CONSOLE_ROW_SIZE);
+ lcd_sync();
}
/*----------------------------------------------------------------------*/
@@ -144,6 +170,8 @@ static inline void console_newline (void)
/* Scroll everything up */
console_scrollup () ;
--console_row;
+ } else {
+ lcd_sync();
}
}
@@ -369,13 +397,6 @@ int drv_lcd_init (void)
}
/*----------------------------------------------------------------------*/
-static
-int do_lcd_clear(cmd_tbl_t *cmdtp, int flag, int argc, char *const argv[])
-{
- lcd_clear();
- return 0;
-}
-
void lcd_clear(void)
{
#if LCD_BPP == LCD_MONOCHROME
@@ -417,6 +438,14 @@ void lcd_clear(void)
console_col = 0;
console_row = 0;
+ lcd_sync();
+}
+
+static int do_lcd_clear(cmd_tbl_t *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ lcd_clear();
+ return 0;
}
U_BOOT_CMD(
@@ -611,6 +640,7 @@ void bitmap_plot (int x, int y)
}
WATCHDOG_RESET();
+ lcd_sync();
}
#endif /* CONFIG_LCD_LOGO */
@@ -809,6 +839,7 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
break;
};
+ lcd_sync();
return (0);
}
#endif
diff --git a/include/lcd.h b/include/lcd.h
index 5016d6b..7c2dae2 100644
--- a/include/lcd.h
+++ b/include/lcd.h
@@ -56,6 +56,14 @@ extern void lcd_initcolregs (void);
/* gunzip_bmp used if CONFIG_VIDEO_BMP_GZIP */
extern struct bmp_image *gunzip_bmp(unsigned long addr, unsigned long *lenp);
+/**
+ * Set whether we need to flush the dcache when changing the LCD image. This
+ * defaults to off.
+ *
+ * @param flush non-zero to flush cache after update, 0 to skip
+ */
+void lcd_set_flush_dcache(int flush);
+
#if defined CONFIG_MPC823
/*
* LCD controller stucture for MPC823 CPU
--
1.7.7.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 14/19] lcd: Add support for flushing LCD fb from dcache after update
2012-06-13 16:19 ` [U-Boot] [PATCH v2 14/19] lcd: Add support for flushing LCD fb from dcache after update Simon Glass
@ 2012-06-14 23:51 ` Stephen Warren
2012-07-11 5:06 ` Simon Glass
0 siblings, 1 reply; 67+ messages in thread
From: Stephen Warren @ 2012-06-14 23:51 UTC (permalink / raw)
To: u-boot
On 06/13/2012 10:19 AM, Simon Glass wrote:
> This provides an option for the LCD to flush the dcache after each update
> (puts, scroll or clear).
> diff --git a/common/cmd_echo.c b/common/cmd_echo.c
> + /* Use puts() so that the LCD sees it as a new line */
> if (putnl)
> - putc('\n');
> + puts("\n");
That seems fragile - what if someone comes along and uses putc() in some
other code without having a clue that this requirement exists? What
stops putc() from detecting \n just like puts()?
^ permalink raw reply [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 14/19] lcd: Add support for flushing LCD fb from dcache after update
2012-06-14 23:51 ` Stephen Warren
@ 2012-07-11 5:06 ` Simon Glass
0 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-07-11 5:06 UTC (permalink / raw)
To: u-boot
Hi Stephen,
On Fri, Jun 15, 2012 at 1:51 AM, Stephen Warren <swarren@wwwdotorg.org>wrote:
> On 06/13/2012 10:19 AM, Simon Glass wrote:
> > This provides an option for the LCD to flush the dcache after each update
> > (puts, scroll or clear).
>
> > diff --git a/common/cmd_echo.c b/common/cmd_echo.c
>
> > + /* Use puts() so that the LCD sees it as a new line */
> > if (putnl)
> > - putc('\n');
> > + puts("\n");
>
> That seems fragile - what if someone comes along and uses putc() in some
> other code without having a clue that this requirement exists? What
> stops putc() from detecting \n just like puts()?
>
Yes, actually that change isn't needed, I will remove it.
Regards,
Simon
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 15/19] tegra: Align LCD frame buffer to section boundary
2012-06-13 16:19 [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Simon Glass
` (10 preceding siblings ...)
2012-06-13 16:19 ` [U-Boot] [PATCH v2 14/19] lcd: Add support for flushing LCD fb from dcache after update Simon Glass
@ 2012-06-13 16:19 ` Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 16/19] tegra: Support control of cache settings for LCD Simon Glass
` (4 subsequent siblings)
16 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: u-boot
For tegra we want to enable the cache for the LCD. This is easier if
we can avoid using L2 page tages, so align the LCD to a section
boundary.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
Changes in v2:
- Align tegra display using new CONFIG_LCD_ALIGNMENT feature
include/configs/tegra2-common.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/configs/tegra2-common.h b/include/configs/tegra2-common.h
index 068ce88..0420098 100644
--- a/include/configs/tegra2-common.h
+++ b/include/configs/tegra2-common.h
@@ -45,6 +45,9 @@
#define CONFIG_ARCH_CPU_INIT /* Fire up the A9 core */
+/* Align LCD to 1MB boundary */
+#define CONFIG_LCD_ALIGNMENT MMU_SECTION_SIZE
+
#include <asm/arch/tegra2.h> /* get chip and board defs */
/*
--
1.7.7.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 16/19] tegra: Support control of cache settings for LCD
2012-06-13 16:19 [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Simon Glass
` (11 preceding siblings ...)
2012-06-13 16:19 ` [U-Boot] [PATCH v2 15/19] tegra: Align LCD frame buffer to section boundary Simon Glass
@ 2012-06-13 16:19 ` Simon Glass
[not found] ` <1339604395-6621-1-git-send-email-sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
` (3 subsequent siblings)
16 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: u-boot
Add support for selecting the required cache mode for the LCD:
off, write-through or write-back.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
drivers/video/tegra.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/video/tegra.c b/drivers/video/tegra.c
index 12518b2..15e10f7 100644
--- a/drivers/video/tegra.c
+++ b/drivers/video/tegra.c
@@ -175,6 +175,15 @@ void lcd_ctrl_init(void *lcdbase)
return;
}
+ /* For write-through or cache off, change the LCD memory region */
+ if (!(config.cache_type & FDT_LCD_CACHE_WRITE_BACK))
+ mmu_set_region_dcache(config.frame_buffer, size,
+ config.cache_type & FDT_LCD_CACHE_WRITE_THROUGH ?
+ DCACHE_WRITETHROUGH : DCACHE_OFF);
+
+ /* Enable flushing after LCD writes if requested */
+ lcd_set_flush_dcache(config.cache_type & FDT_LCD_CACHE_FLUSH);
+
debug("LCD frame buffer at %p\n", lcd_base);
}
--
1.7.7.3
^ permalink raw reply related [flat|nested] 67+ messages in thread[parent not found: <1339604395-6621-1-git-send-email-sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>]
* [PATCH v2 02/19] fdt: Add debugging to fdtdec_get_int/addr()
2012-06-13 16:19 [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Simon Glass
@ 2012-06-13 16:19 ` Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 05/19] tegra: Use const for pinmux_config_pingroup/table() Simon Glass
` (15 subsequent siblings)
16 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: U-Boot Mailing List; +Cc: Devicetree Discuss, Tom Warren, Jerry Van Baren
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
^ permalink raw reply related [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 02/19] fdt: Add debugging to fdtdec_get_int/addr()
@ 2012-06-13 16:19 ` Simon Glass
0 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: u-boot
The new debugging shows the value of integers and addresses read
from the device tree.
Signed-off-by: Simon Glass <sjg@chromium.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
^ permalink raw reply related [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 02/19] fdt: Add debugging to fdtdec_get_int/addr()
2012-06-13 16:19 ` [U-Boot] " Simon Glass
(?)
@ 2012-09-21 19:39 ` Anatolij Gustschin
2012-09-21 19:56 ` Anatolij Gustschin
-1 siblings, 1 reply; 67+ messages in thread
From: Anatolij Gustschin @ 2012-09-21 19:39 UTC (permalink / raw)
To: u-boot
On Wed, 13 Jun 2012 09:19:38 -0700
Simon Glass <sjg@chromium.org> wrote:
> The new debugging shows the value of integers and addresses read
> from the device tree.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> lib/fdtdec.c | 22 ++++++++++++++++------
> 1 files changed, 16 insertions(+), 6 deletions(-)
Applied to staging/agust at denx.de.
Thanks,
Anatolij
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 02/19] fdt: Add debugging to fdtdec_get_int/addr()
2012-09-21 19:39 ` Anatolij Gustschin
@ 2012-09-21 19:56 ` Anatolij Gustschin
0 siblings, 0 replies; 67+ messages in thread
From: Anatolij Gustschin @ 2012-09-21 19:56 UTC (permalink / raw)
To: u-boot
On Fri, 21 Sep 2012 21:39:39 +0200
Anatolij Gustschin <agust@denx.de> wrote:
> On Wed, 13 Jun 2012 09:19:38 -0700
> Simon Glass <sjg@chromium.org> wrote:
>
> > The new debugging shows the value of integers and addresses read
> > from the device tree.
> >
> > Signed-off-by: Simon Glass <sjg@chromium.org>
> > ---
> >
> > lib/fdtdec.c | 22 ++++++++++++++++------
> > 1 files changed, 16 insertions(+), 6 deletions(-)
>
> Applied to staging/agust at denx.de.
now I see a newer version of this patch. I'll drop this one and
will apply v3 instead.
Thanks,
Anatolij
^ permalink raw reply [flat|nested] 67+ messages in thread
* [PATCH v2 03/19] fdt: Add function to look up a phandle's register address
2012-06-13 16:19 [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Simon Glass
@ 2012-06-13 16:19 ` Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 05/19] tegra: Use const for pinmux_config_pingroup/table() Simon Glass
` (15 subsequent siblings)
16 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: U-Boot Mailing List; +Cc: Devicetree Discuss, Tom Warren, Jerry Van Baren
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
^ permalink raw reply related [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 03/19] fdt: Add function to look up a phandle's register address
@ 2012-06-13 16:19 ` Simon Glass
0 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: u-boot
This is a commonly-used requirement, so add a function to support it
easily.
Signed-off-by: Simon Glass <sjg@chromium.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
^ permalink raw reply related [flat|nested] 67+ messages in thread* Re: [PATCH v2 03/19] fdt: Add function to look up a phandle's register address
2012-06-13 16:19 ` [U-Boot] " Simon Glass
@ 2012-06-14 23:17 ` Stephen Warren
-1 siblings, 0 replies; 67+ messages in thread
From: Stephen Warren @ 2012-06-14 23:17 UTC (permalink / raw)
To: Simon Glass
Cc: Devicetree Discuss, U-Boot Mailing List, Jerry Van Baren, Tom 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?
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 03/19] fdt: Add function to look up a phandle's register address
@ 2012-06-14 23:17 ` Stephen Warren
0 siblings, 0 replies; 67+ messages in thread
From: Stephen Warren @ 2012-06-14 23:17 UTC (permalink / raw)
To: u-boot
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?
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [PATCH v2 03/19] fdt: Add function to look up a phandle's register address
2012-06-14 23:17 ` [U-Boot] " Stephen Warren
@ 2012-07-11 5:10 ` Simon Glass
-1 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-07-11 5:10 UTC (permalink / raw)
To: Stephen Warren
Cc: Devicetree Discuss, U-Boot Mailing List, Jerry Van Baren, Tom Warren
[-- 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
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 03/19] fdt: Add function to look up a phandle's register address
@ 2012-07-11 5:10 ` Simon Glass
0 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-07-11 5:10 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 67+ messages in thread
* [PATCH v2 04/19] fdt: Add header guard to fdtdec.h
2012-06-13 16:19 [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Simon Glass
@ 2012-06-13 16:19 ` Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 05/19] tegra: Use const for pinmux_config_pingroup/table() Simon Glass
` (15 subsequent siblings)
16 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: U-Boot Mailing List; +Cc: Devicetree Discuss, Tom Warren, Jerry Van Baren
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
^ permalink raw reply related [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 04/19] fdt: Add header guard to fdtdec.h
@ 2012-06-13 16:19 ` Simon Glass
0 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: u-boot
This makes it easier to include this header from other headers.
Signed-off-by: Simon Glass <sjg@chromium.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
^ permalink raw reply related [flat|nested] 67+ messages in thread
* [PATCH v2 17/19] tegra: fdt: Add LCD definitions for Seaboard
2012-06-13 16:19 [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Simon Glass
@ 2012-06-13 16:19 ` Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 05/19] tegra: Use const for pinmux_config_pingroup/table() Simon Glass
` (15 subsequent siblings)
16 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: U-Boot Mailing List; +Cc: Devicetree Discuss, Jerry Van Baren, Tom Warren
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
^ permalink raw reply related [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 17/19] tegra: fdt: Add LCD definitions for Seaboard
@ 2012-06-13 16:19 ` Simon Glass
0 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: u-boot
The Seaboard has a 1366x768 16bpp LCD. The backlight is controlled
by one of the PWMs.
Signed-off-by: Simon Glass <sjg@chromium.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 at 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
^ permalink raw reply related [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 18/19] lcd: Add CONSOLE_SCROLL_LINES option to speed console
2012-06-13 16:19 [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Simon Glass
` (13 preceding siblings ...)
[not found] ` <1339604395-6621-1-git-send-email-sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
@ 2012-06-13 16:19 ` Simon Glass
2012-06-13 16:19 ` [U-Boot] [PATCH v2 19/19] tegra: Enable display/lcd support on Seaboard Simon Glass
2012-06-13 22:57 ` [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Stephen Warren
16 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: u-boot
When the cursor position gets to the end of the LCD console we normally
scroll by one line. This adds an option to increase that value.
Console scrolling is often slow, and if a large amount of output is
being sent, increasing this option to 10 or so will speed things up
considerably.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
README | 6 ++++++
common/lcd.c | 15 +++++++++++++--
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/README b/README
index ccdddbf..cb2c6cf 100644
--- a/README
+++ b/README
@@ -1407,6 +1407,12 @@ The following options need to be configured:
here, since it is cheaper to change data cache settings on
a per-section basis.
+ CONSOLE_SCROLL_LINES
+
+ When the console need to be scrolled, this is the number of
+ lines to scroll by. It defaults to 1. Increasing this makes
+ the console jump but can help speed up operation when scrolling
+ is slow.
- Splash Screen Support: CONFIG_SPLASH_SCREEN
diff --git a/common/lcd.c b/common/lcd.c
index 758f158..b4e0853 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -134,12 +134,23 @@ void lcd_set_flush_dcache(int flush)
static void console_scrollup (void)
{
+ int rows = 1;
+
+#ifdef CONSOLE_SCROLL_LINES
+ rows = CONSOLE_SCROLL_LINES;
+#endif
/* Copy up rows ignoring the first one */
- memcpy (CONSOLE_ROW_FIRST, CONSOLE_ROW_SECOND, CONSOLE_SCROLL_SIZE);
+ memcpy(CONSOLE_ROW_FIRST,
+ lcd_console_address + CONSOLE_ROW_SIZE * rows,
+ CONSOLE_SIZE - CONSOLE_ROW_SIZE * rows);
/* Clear the last one */
- memset (CONSOLE_ROW_LAST, COLOR_MASK(lcd_color_bg), CONSOLE_ROW_SIZE);
+ memset(lcd_console_address + CONSOLE_SIZE - CONSOLE_ROW_SIZE * rows,
+ COLOR_MASK(lcd_color_bg),
+ CONSOLE_ROW_SIZE * rows);
+
lcd_sync();
+ console_row -= rows;
}
/*----------------------------------------------------------------------*/
--
1.7.7.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 19/19] tegra: Enable display/lcd support on Seaboard
2012-06-13 16:19 [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Simon Glass
` (14 preceding siblings ...)
2012-06-13 16:19 ` [U-Boot] [PATCH v2 18/19] lcd: Add CONSOLE_SCROLL_LINES option to speed console Simon Glass
@ 2012-06-13 16:19 ` Simon Glass
2012-06-13 22:57 ` [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Stephen Warren
16 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-06-13 16:19 UTC (permalink / raw)
To: u-boot
From: Mayuresh Kulkarni <mkulkarni@nvidia.com>
Enable the Seaboard's 16-bit LCD and use it as the console.
Signed-off-by: Mayuresh Kulkarni <mkulkarni@nvidia.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
include/configs/seaboard.h | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/include/configs/seaboard.h b/include/configs/seaboard.h
index 1d1176a..ed87bbe 100644
--- a/include/configs/seaboard.h
+++ b/include/configs/seaboard.h
@@ -62,6 +62,7 @@
#define CONFIG_SYS_BOARD_ODMDATA 0x300d8011 /* lp1, 1GB */
#define CONFIG_BOARD_EARLY_INIT_F
+#define CONFIG_BOARD_LATE_INIT /* Make sure LCD init is complete */
/* SPI */
#define CONFIG_TEGRA2_SPI
@@ -111,6 +112,13 @@
#undef TEGRA2_DEVICE_SETTINGS
#define TEGRA2_DEVICE_SETTINGS "stdin=serial,tegra-kbc\0" \
- "stdout=serial\0" \
- "stderr=serial\0"
+ "stdout=serial,lcd\0" \
+ "stderr=serial,lcd\0"
+
+/* LCD support */
+#define CONFIG_LCD
+#define CONFIG_VIDEO_TEGRA
+#define LCD_BPP LCD_COLOR16
+#define CONFIG_SYS_WHITE_ON_BLACK
+#define CONSOLE_SCROLL_LINES 10
#endif /* __CONFIG_H */
--
1.7.7.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard
2012-06-13 16:19 [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Simon Glass
` (15 preceding siblings ...)
2012-06-13 16:19 ` [U-Boot] [PATCH v2 19/19] tegra: Enable display/lcd support on Seaboard Simon Glass
@ 2012-06-13 22:57 ` Stephen Warren
2012-06-13 23:03 ` Stephen Warren
2012-06-25 21:03 ` Tom Warren
16 siblings, 2 replies; 67+ messages in thread
From: Stephen Warren @ 2012-06-13 22:57 UTC (permalink / raw)
To: u-boot
On 06/13/2012 10:19 AM, Simon Glass wrote:
> This series adds support for the Tegra2x's display peripheral. This
> supports the LCD display on Seaboard and we use this to enable console
> output in U-Boot on the LCD.
Simon,
This series doesn't apply to u-boot-tegra/master cleanly; there are a
couple trivial conflicts in arch/arm/cpu/armv7/tegra2/Makefile to
resolve, but I had to apply the final patch completely by hand.
When I run the resultant binary, I see the LCD backlight turn on, but
the image on the LCD is wrong; it starts completely black without any
text showing, then slowly fills in to white/gray with many horizontal
and vertical black lines; I guess the LCD timing is incorrect - are
there multiple different LCD models? Note that I am using a real
Seaboard not a Springbank for this test.
^ permalink raw reply [flat|nested] 67+ messages in thread* [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard
2012-06-13 22:57 ` [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Stephen Warren
@ 2012-06-13 23:03 ` Stephen Warren
2012-06-13 23:09 ` Stephen Warren
2012-06-25 21:03 ` Tom Warren
1 sibling, 1 reply; 67+ messages in thread
From: Stephen Warren @ 2012-06-13 23:03 UTC (permalink / raw)
To: u-boot
On 06/13/2012 04:57 PM, Stephen Warren wrote:
> On 06/13/2012 10:19 AM, Simon Glass wrote:
>> This series adds support for the Tegra2x's display peripheral. This
>> supports the LCD display on Seaboard and we use this to enable console
>> output in U-Boot on the LCD.
>
> Simon,
>
> This series doesn't apply to u-boot-tegra/master cleanly; there are a
> couple trivial conflicts in arch/arm/cpu/armv7/tegra2/Makefile to
> resolve, but I had to apply the final patch completely by hand.
>
> When I run the resultant binary, I see the LCD backlight turn on, but
> the image on the LCD is wrong; it starts completely black without any
> text showing, then slowly fills in to white/gray with many horizontal
> and vertical black lines; I guess the LCD timing is incorrect - are
> there multiple different LCD models? Note that I am using a real
> Seaboard not a Springbank for this test.
Oh, false alarm on this second point - the LCD is screwed up after using
nvflash to flash the device, but when power-cycling it rather than just
resetting it, the LCD works fine. I guess this means the driver is not
initializing something that nvflash changed, and relying on a power-on
default. I suppose it might not be worth fixing that given it works from
cold power on.
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard
2012-06-13 23:03 ` Stephen Warren
@ 2012-06-13 23:09 ` Stephen Warren
0 siblings, 0 replies; 67+ messages in thread
From: Stephen Warren @ 2012-06-13 23:09 UTC (permalink / raw)
To: u-boot
On 06/13/2012 05:03 PM, Stephen Warren wrote:
> On 06/13/2012 04:57 PM, Stephen Warren wrote:
>> On 06/13/2012 10:19 AM, Simon Glass wrote:
>>> This series adds support for the Tegra2x's display peripheral. This
>>> supports the LCD display on Seaboard and we use this to enable console
>>> output in U-Boot on the LCD.
>>
>> Simon,
>>
>> This series doesn't apply to u-boot-tegra/master cleanly; there are a
>> couple trivial conflicts in arch/arm/cpu/armv7/tegra2/Makefile to
>> resolve, but I had to apply the final patch completely by hand.
>>
>> When I run the resultant binary, I see the LCD backlight turn on, but
>> the image on the LCD is wrong; it starts completely black without any
>> text showing, then slowly fills in to white/gray with many horizontal
>> and vertical black lines; I guess the LCD timing is incorrect - are
>> there multiple different LCD models? Note that I am using a real
>> Seaboard not a Springbank for this test.
>
> Oh, false alarm on this second point - the LCD is screwed up after using
> nvflash to flash the device, but when power-cycling it rather than just
> resetting it, the LCD works fine. I guess this means the driver is not
> initializing something that nvflash changed, and relying on a power-on
> default. I suppose it might not be worth fixing that given it works from
> cold power on.
Oops, there is a problem - executing "reset" in U-Boot, or "reboot" from
the kernel (one without any display support at least; mainline Linux)
will get into the "bad LCD" state too. So, I guess there is something
that needs to be fixed.
Sorry for the back-to-back emails.
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard
2012-06-13 22:57 ` [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard Stephen Warren
2012-06-13 23:03 ` Stephen Warren
@ 2012-06-25 21:03 ` Tom Warren
2012-06-27 5:11 ` Simon Glass
1 sibling, 1 reply; 67+ messages in thread
From: Tom Warren @ 2012-06-25 21:03 UTC (permalink / raw)
To: u-boot
Simon,
> -----Original Message-----
> From: Stephen Warren [mailto:swarren at wwwdotorg.org]
> Sent: Wednesday, June 13, 2012 3:58 PM
> To: Simon Glass
> Cc: U-Boot Mailing List; Tom Warren
> Subject: Re: [PATCH v2 0/19] tegra: Add display driver and LCD support for
> Seaboard
>
> On 06/13/2012 10:19 AM, Simon Glass wrote:
> > This series adds support for the Tegra2x's display peripheral. This
> > supports the LCD display on Seaboard and we use this to enable console
> > output in U-Boot on the LCD.
>
> Simon,
>
> This series doesn't apply to u-boot-tegra/master cleanly; there are a couple
> trivial conflicts in arch/arm/cpu/armv7/tegra2/Makefile to resolve, but I
> had to apply the final patch completely by hand.
>
> When I run the resultant binary, I see the LCD backlight turn on, but the
> image on the LCD is wrong; it starts completely black without any text
> showing, then slowly fills in to white/gray with many horizontal and
> vertical black lines; I guess the LCD timing is incorrect - are there
> multiple different LCD models? Note that I am using a real Seaboard not a
> Springbank for this test.
I don't see Stephen's LCD problems, but I don't see clear text on my Seaboard T20-A03 dev system LCD, either. The text is blurred / almost unreadable, especially the last line (cmd prompt). I don't know if it's the scrolling change or the cache change, as previous incarnations (in the Google repo, at least) were just fine. Power-cycling doesn't fix it. I didn't test Ventana or Harmony.
Please update the patchset so it (a) applies to u-boot-tegra/master and/or /next, and (b) fixes the text corruption on the LCD.
Tom
--
nvpublic
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard
2012-06-25 21:03 ` Tom Warren
@ 2012-06-27 5:11 ` Simon Glass
2012-07-11 10:04 ` Simon Glass
0 siblings, 1 reply; 67+ messages in thread
From: Simon Glass @ 2012-06-27 5:11 UTC (permalink / raw)
To: u-boot
Hi Tom,
On Mon, Jun 25, 2012 at 2:03 PM, Tom Warren <TWarren@nvidia.com> wrote:
> Simon,
>
> > -----Original Message-----
> > From: Stephen Warren [mailto:swarren at wwwdotorg.org]
> > Sent: Wednesday, June 13, 2012 3:58 PM
> > To: Simon Glass
> > Cc: U-Boot Mailing List; Tom Warren
> > Subject: Re: [PATCH v2 0/19] tegra: Add display driver and LCD support
> for
> > Seaboard
> >
> > On 06/13/2012 10:19 AM, Simon Glass wrote:
> > > This series adds support for the Tegra2x's display peripheral. This
> > > supports the LCD display on Seaboard and we use this to enable console
> > > output in U-Boot on the LCD.
> >
> > Simon,
> >
> > This series doesn't apply to u-boot-tegra/master cleanly; there are a
> couple
> > trivial conflicts in arch/arm/cpu/armv7/tegra2/Makefile to resolve, but I
> > had to apply the final patch completely by hand.
> >
> > When I run the resultant binary, I see the LCD backlight turn on, but the
> > image on the LCD is wrong; it starts completely black without any text
> > showing, then slowly fills in to white/gray with many horizontal and
> > vertical black lines; I guess the LCD timing is incorrect - are there
> > multiple different LCD models? Note that I am using a real Seaboard not a
> > Springbank for this test.
>
> I don't see Stephen's LCD problems, but I don't see clear text on my
> Seaboard T20-A03 dev system LCD, either. The text is blurred / almost
> unreadable, especially the last line (cmd prompt). I don't know if it's the
> scrolling change or the cache change, as previous incarnations (in the
> Google repo, at least) were just fine. Power-cycling doesn't fix it. I
> didn't test Ventana or Harmony.
>
> Please update the patchset so it (a) applies to u-boot-tegra/master and/or
> /next, and (b) fixes the text corruption on the LCD.
>
Yes will do.
I am not sure about the text corruption as I didn't see that, but perhaps
the rebase has caused something to change. Will take a look.
Regards
Simon
>
> Tom
> --
> nvpublic
>
^ permalink raw reply [flat|nested] 67+ messages in thread
* [U-Boot] [PATCH v2 0/19] tegra: Add display driver and LCD support for Seaboard
2012-06-27 5:11 ` Simon Glass
@ 2012-07-11 10:04 ` Simon Glass
0 siblings, 0 replies; 67+ messages in thread
From: Simon Glass @ 2012-07-11 10:04 UTC (permalink / raw)
To: u-boot
Hi Tom,
On Wed, Jun 27, 2012 at 7:11 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Tom,
>
> On Mon, Jun 25, 2012 at 2:03 PM, Tom Warren <TWarren@nvidia.com> wrote:
>
>> Simon,
>>
>> > -----Original Message-----
>> > From: Stephen Warren [mailto:swarren at wwwdotorg.org]
>> > Sent: Wednesday, June 13, 2012 3:58 PM
>> > To: Simon Glass
>> > Cc: U-Boot Mailing List; Tom Warren
>> > Subject: Re: [PATCH v2 0/19] tegra: Add display driver and LCD support
>> for
>> > Seaboard
>> >
>> > On 06/13/2012 10:19 AM, Simon Glass wrote:
>> > > This series adds support for the Tegra2x's display peripheral. This
>> > > supports the LCD display on Seaboard and we use this to enable console
>> > > output in U-Boot on the LCD.
>> >
>> > Simon,
>> >
>> > This series doesn't apply to u-boot-tegra/master cleanly; there are a
>> couple
>> > trivial conflicts in arch/arm/cpu/armv7/tegra2/Makefile to resolve, but
>> I
>> > had to apply the final patch completely by hand.
>> >
>> > When I run the resultant binary, I see the LCD backlight turn on, but
>> the
>> > image on the LCD is wrong; it starts completely black without any text
>> > showing, then slowly fills in to white/gray with many horizontal and
>> > vertical black lines; I guess the LCD timing is incorrect - are there
>> > multiple different LCD models? Note that I am using a real Seaboard not
>> a
>> > Springbank for this test.
>>
>> I don't see Stephen's LCD problems, but I don't see clear text on my
>> Seaboard T20-A03 dev system LCD, either. The text is blurred / almost
>> unreadable, especially the last line (cmd prompt). I don't know if it's the
>> scrolling change or the cache change, as previous incarnations (in the
>> Google repo, at least) were just fine. Power-cycling doesn't fix it. I
>> didn't test Ventana or Harmony.
>>
>> Please update the patchset so it (a) applies to u-boot-tegra/master
>> and/or /next, and (b) fixes the text corruption on the LCD.
>>
>
> Yes will do.
>
> I am not sure about the text corruption as I didn't see that, but perhaps
> the rebase has caused something to change. Will take a look.
>
I am still not seeing any text corruption here, nor Stephen's LCD problems.
Are you running with the cache on or off? (not that it should matter - have
tested both).
Regards,
Simon
>
> Regards
> Simon
>
>
>>
>> Tom
>> --
>> nvpublic
>>
>
>
^ permalink raw reply [flat|nested] 67+ messages in thread