tegra: Add display driver and LCD support for Seaboard

This function should also be part of the GPIO API, so add it.

Signed-off-by Simon Glass <[email protected]>

---

 include/asm-generic/gpio.h |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

Hi Simon,

Quoted 2 lines · On Wed, 13 Jun 2012 09:19:37 -0700 Simon Glass <[email protected]> wrote:

This function should also be part of the GPIO API, so add it.

Quoted 5 lines

Signed-off-by Simon Glass <[email protected]>

---

 include/asm-generic/gpio.h |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

Applied to staging/agust at denx.de.

Thanks,
Anatolij

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

Signed-off-by Simon Glass <[email protected]>

---

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

Quoted 3 lines · On Wed, 13 Jun 2012 09:19:38 -0700 Simon Glass <[email protected]> wrote:

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

Quoted 5 lines

Signed-off-by Simon Glass <[email protected]>

---

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

Applied to staging/agust at denx.de.

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

Quoted 2 lines · Simon Glass

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?

arch/arm/cpu/armv7/tegra2/funcmux.c line 43

Quoted 5 lines · Simon Glass

Add support for a default pin mapping for display1.

arch/arm/cpu/armv7/tegra2/funcmux.c +3 -0

+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.

Quoted 1 line

+ 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.

arch/arm/cpu/armv7/tegra2/funcmux.c int funcmux_select(enum periph_id id, int config) · line 212

Quoted 5 lines

arch/arm/cpu/armv7/tegra2/funcmux.c +2 -0

@@ -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?

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.

Quoted 4 lines · Simon Glass

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

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

I 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

Quoted 8 lines

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.

Hi Stephen,

Quoted 10 lines · Stephen Warren

Quoted 4 lines · Simon Glass

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

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

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

Quoted 1 line

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.

Quoted 7 lines

Quoted 6 lines

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.

Quoted 10 lines

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?

Quoted 17 lines · Simon Glass

Hi Stephen,

Quoted 11 lines · Stephen Warren

Quoted 4 lines · Simon Glass

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

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

I 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

Quoted 2 lines

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.

Quoted 19 lines

Quoted 8 lines

Quoted 7 lines

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.

Quoted 10 lines

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.

Quoted 7 lines

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.

Quoted 3 lines

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

Hi Thierry,

Quoted 18 lines · Thierry Reding

Quoted 17 lines · Simon Glass

Hi Stephen,

Quoted 11 lines · Stephen Warren

Quoted 4 lines · Simon Glass

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

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

I 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

Quoted 6 lines

Quoted 2 lines

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?

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.

The pulse width/frequency modulation peripheral supports generating a repeating pulse. It is useful for controlling LCD brightness.

Quoted 2 lines · Simon Glass

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:

arch/arm/include/asm/arch-tegra2/pwfm.h line 52

Quoted 2 lines

arch/arm/include/asm/arch-tegra2/pwfm.h new file +2 -0

+void pwfm_enable(struct pwfm_ctlr *pwfm, int rate, int pulse_width,
+             int freq_divider);

to take a pwm_id parameter too.

From: Wei Ni <[email protected]>

Add support for the LCD peripheral at the Tegra2 SOC level. A separate LCD driver will use this functionality to configure the display.

arch/arm/include/asm/arch-tegra2/display.h +8 -0

 
+/**
+ * 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

Hi Stephen,

Quoted 25 lines · Stephen Warren

Review

Quoted 6 lines · Simon Glass

From: Wei Ni <[email protected]>

Add support for the LCD peripheral at the Tegra2 SOC level. A separate LCD driver will use this functionality to configure the display.

(quoted diff) +0 -0

b/arch/arm/include/asm/arch-tegra2/display.h

Quoted 4 lines

+/**
+ * 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

Quoted 4 lines

+ * 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

Quoted 6 lines

+ * 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

Quoted 9 lines

return

Quoted 1 line

+ * 0 to return immediately, potentially doing nothing if it

is

Quoted 3 lines

+ * 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.

In my copy of the patches it is defined in the driver (drivers/video/tegra.c). I will move it to the same patch.

Regards,
Simon

drivers/video/tegra.c new file +7 -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().
+	 *

Quoted 4 lines · Simon Glass

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)

Quoted 1 line

+ fdtdec_decode_gpio(blob, display_node,

"nvidia,backlight-vdd-gpios",

Quoted 1 line

+ &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).

drivers/video/tegra.c

Quoted 8 lines

drivers/video/tegra.c new file +8 -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.

drivers/video/tegra.c

Quoted 5 lines

drivers/video/tegra.c new file +5 -0

+      * 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)"

drivers/video/tegra.c line 383

Quoted 4 lines

drivers/video/tegra.c new file +4 -0

+                     " 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?

lib/fdtdec.c static const char * const compat_names[COMPAT_COUNT] =

Quoted 4 lines

lib/fdtdec.c +0 -0

@@ -43,6 +43,7 @@ static const char * const compat_names[COMPAT_COUNT] =

{

lib/fdtdec.c static const char * const compat_names[COMPAT_COUNT] = { · line 46

Quoted 1 line

lib/fdtdec.c +1 -0

+     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.

board/nvidia/common/board.c int board_init(void) · line 91

Quoted 9 lines · Simon Glass

Add calls to the LCD driver from Nvidia board code.

board/nvidia/common/board.c +3 -0

@@ -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.

Hi Stephen,

On Fri, Jun 15, 2012 at 1:47 AM, Stephen Warren <[email protected] <mailto:[email protected]>> 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?

Quoted 33 lines · Simon Glass

Hi Stephen,

On Fri, Jun 15, 2012 at 1:47 AM, Stephen Warren <[email protected] <mailto:[email protected]>> 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.

Quoted 4 lines

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?

Quoted 3 lines

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.

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.

Quoted 4 lines · Simon Glass

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.

Quoted 3 lines

It is implemented only for ARMv7 at present.

This is needed for LCD support, where we want to make the LCD frame

buffer

Quoted 1 line

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?

Quoted 4 lines · Simon Glass

This provides an option for the LCD to flush the dcache after each update (puts, scroll or clear).

common/cmd_echo.c +0 -0

common/cmd_echo.c int do_echo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) · line 49

Quoted 4 lines

common/cmd_echo.c +2 -1

+     /* 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()?

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.

Quoted 3 lines · Simon Glass

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.

Quoted 11 lines · Stephen Warren

Quoted 3 lines · Simon Glass

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.

Quoted 6 lines

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.

-----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

Quoted 3 lines · Simon Glass

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.

Simon,

Quoted 6 lines

-----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

Quoted 10 lines

Seaboard

Quoted 3 lines · Simon Glass

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

Quoted 9 lines

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

Hi Tom,

Quoted 40 lines · Tom Warren

Simon,

Quoted 6 lines

-----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

Quoted 10 lines

Seaboard

Quoted 3 lines · Simon Glass

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

Quoted 1 line

trivial conflicts in arch/arm/cpu/armv7/tegra2/Makefile to resolve, but

I

Quoted 3 lines

had to apply the final patch completely by hand.

When I run the resultant binary, I see the LCD backlight turn on, but

the

Quoted 4 lines

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

Quoted 1 line

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.

Quoted 3 lines

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

Quoted 5 lines

Tom
--
nvpublic