[PATCH] drm: tegra: Use framebuffer pitch as line stride

[PATCH] drm: tegra: Use framebuffer pitch as line stride

[Thierry Reding]

Instead of using the stride derived from the display mode, use the pitch
associated with the currently active framebuffer. This fixes a bug where
the LCD display content would be skewed when enabling HDMI with a video
mode different from that of the LCD.

Signed-off-by: Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>
---
 drivers/gpu/drm/tegra/dc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 94686e5..41cde76 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -218,7 +218,7 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
 	}
 
 	bpp = crtc->fb->bits_per_pixel / 8;
-	win.stride = win.outw * bpp;
+	win.stride = crtc->fb->pitches[0];
 
 	/* program window registers */
 	value = tegra_dc_readl(dc, DC_CMD_DISPLAY_WINDOW_HEADER);
-- 
1.8.0

Re: [PATCH] drm: tegra: Use framebuffer pitch as line stride

[Terje Bergström]

On 22.11.2012 21:37, Thierry Reding wrote:
> Instead of using the stride derived from the display mode, use the pitch
> associated with the currently active framebuffer. This fixes a bug where
> the LCD display content would be skewed when enabling HDMI with a video
> mode different from that of the LCD.

Hi

This might fix the issue we had with the stride when doing our 2D
blitting on frame buffer. I'll test with your patch instead. We were
using a different stride due to limitations of 2D unit, so we hacked
this into our code:

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_he
index fd9d0af..65b12ba 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -214,7 +214,7 @@ static int drm_fbdev_cma_create(struct drm_fb_helper
*helper

        mode_cmd.width = sizes->surface_width;
        mode_cmd.height = sizes->surface_height;
-       mode_cmd.pitches[0] = sizes->surface_width * bytes_per_pixel;
+       mode_cmd.pitches[0] = roundup(sizes->surface_width *
bytes_per_pixel, 32);
        mode_cmd.pixel_format =
drm_mode_legacy_fb_format(sizes->surface_bpp,
                sizes->surface_depth);

diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index b9e5a79..d70c488 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -219,7 +219,7 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
        }

        bpp = crtc->fb->bits_per_pixel / 8;
-       win.stride = win.outw * bpp;
+       win.stride = roundup(win.outw * bpp, 32);

        /* program window registers */
        value = tegra_dc_readl(dc, DC_CMD_DISPLAY_WINDOW_HEADER);

Re: [PATCH] drm: tegra: Use framebuffer pitch as line stride

[Terje Bergström]

On 22.11.2012 21:37, Thierry Reding wrote:
> Instead of using the stride derived from the display mode, use the pitch
> associated with the currently active framebuffer. This fixes a bug where
> the LCD display content would be skewed when enabling HDMI with a video
> mode different from that of the LCD.
> 
> Signed-off-by: Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>

Hi,

I tested and verified that this fixes our stride problem. Thanks!

Tested-by: Terje Bergstrom <tbergstrom-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

Re: [PATCH] drm: tegra: Use framebuffer pitch as line stride

[Mark Zhang]

Tested-by: Mark Zhang <markz-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

On my Tegra 3 cardhu.

Mark
On 11/23/2012 03:37 AM, Thierry Reding wrote:
> Instead of using the stride derived from the display mode, use the pitch
> associated with the currently active framebuffer. This fixes a bug where
> the LCD display content would be skewed when enabling HDMI with a video
> mode different from that of the LCD.
> 
> Signed-off-by: Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org>
> ---
>  drivers/gpu/drm/tegra/dc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index 94686e5..41cde76 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -218,7 +218,7 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
>  	}
>  
>  	bpp = crtc->fb->bits_per_pixel / 8;
> -	win.stride = win.outw * bpp;
> +	win.stride = crtc->fb->pitches[0];
>  
>  	/* program window registers */
>  	value = tegra_dc_readl(dc, DC_CMD_DISPLAY_WINDOW_HEADER);
> 

Re: [PATCH] drm: tegra: Use framebuffer pitch as line stride

[Stephen Warren]

On 11/22/2012 12:37 PM, Thierry Reding wrote:
> Instead of using the stride derived from the display mode, use the pitch
> associated with the currently active framebuffer. This fixes a bug where
> the LCD display content would be skewed when enabling HDMI with a video
> mode different from that of the LCD.

This patch certainly doesn't cause any additional issues for me, so:

Tested-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

Howwever, it still doesn't allow both Cardhu's LCD panel and external
HDMI port (1080p) to be active at once. If I boot with both enabled, or
boot with just the LCD enabled and hot-plug HDMI, as soon as both heads
are active, then some kind of display corruption starts; it looks like a
clocking issue or perhaps memory underflow.

Mark, can you please investigate this. I haven't tested to see if the
issue is Tegra30-specific, or also happens on Tegra20.

Re: [PATCH] drm: tegra: Use framebuffer pitch as line stride

[Mark Zhang]

On 11/27/2012 06:37 AM, Stephen Warren wrote:
> On 11/22/2012 12:37 PM, Thierry Reding wrote:
>> Instead of using the stride derived from the display mode, use the pitch
>> associated with the currently active framebuffer. This fixes a bug where
>> the LCD display content would be skewed when enabling HDMI with a video
>> mode different from that of the LCD.
> 
> This patch certainly doesn't cause any additional issues for me, so:
> 
> Tested-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> 
> Howwever, it still doesn't allow both Cardhu's LCD panel and external
> HDMI port (1080p) to be active at once. If I boot with both enabled, or
> boot with just the LCD enabled and hot-plug HDMI, as soon as both heads
> are active, then some kind of display corruption starts; it looks like a
> clocking issue or perhaps memory underflow.
>

I haven't observed this issue. What kind of display corruption you mean?
Did it recover after some seconds or the display in LVDS panel was
always corrupted?

During my testing, I connected HDMI while booting cardhu and I can see
the LVDS and HDMI working with no corruptions.


> Mark, can you please investigate this. I haven't tested to see if the
> issue is Tegra30-specific, or also happens on Tegra20.
> 

Re: [PATCH] drm: tegra: Use framebuffer pitch as line stride

[Stephen Warren]

On 11/26/2012 08:16 PM, Mark Zhang wrote:
> On 11/27/2012 06:37 AM, Stephen Warren wrote:
>> On 11/22/2012 12:37 PM, Thierry Reding wrote:
>>> Instead of using the stride derived from the display mode, use the pitch
>>> associated with the currently active framebuffer. This fixes a bug where
>>> the LCD display content would be skewed when enabling HDMI with a video
>>> mode different from that of the LCD.
>>
>> This patch certainly doesn't cause any additional issues for me, so:
>>
>> Tested-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>
>> Howwever, it still doesn't allow both Cardhu's LCD panel and external
>> HDMI port (1080p) to be active at once. If I boot with both enabled, or
>> boot with just the LCD enabled and hot-plug HDMI, as soon as both heads
>> are active, then some kind of display corruption starts; it looks like a
>> clocking issue or perhaps memory underflow.
> 
> I haven't observed this issue. What kind of display corruption you mean?
> Did it recover after some seconds or the display in LVDS panel was
> always corrupted?
> 
> During my testing, I connected HDMI while booting cardhu and I can see
> the LVDS and HDMI working with no corruptions.

For your viewing pleasure (and playing with my new phone) :-)
http://www.youtube.com/watch?v=ZJxJnONz7DA

The external monitor is 1920x1200 I believe.

Re: [PATCH] drm: tegra: Use framebuffer pitch as line stride

[Stephen Warren]

On 11/27/2012 11:17 AM, Stephen Warren wrote:
> On 11/26/2012 08:16 PM, Mark Zhang wrote:
>> On 11/27/2012 06:37 AM, Stephen Warren wrote:
>>> On 11/22/2012 12:37 PM, Thierry Reding wrote:
>>>> Instead of using the stride derived from the display mode, use the pitch
>>>> associated with the currently active framebuffer. This fixes a bug where
>>>> the LCD display content would be skewed when enabling HDMI with a video
>>>> mode different from that of the LCD.
>>>
>>> This patch certainly doesn't cause any additional issues for me, so:
>>>
>>> Tested-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>
>>> Howwever, it still doesn't allow both Cardhu's LCD panel and external
>>> HDMI port (1080p) to be active at once. If I boot with both enabled, or
>>> boot with just the LCD enabled and hot-plug HDMI, as soon as both heads
>>> are active, then some kind of display corruption starts; it looks like a
>>> clocking issue or perhaps memory underflow.
>>
>> I haven't observed this issue. What kind of display corruption you mean?
>> Did it recover after some seconds or the display in LVDS panel was
>> always corrupted?
>>
>> During my testing, I connected HDMI while booting cardhu and I can see
>> the LVDS and HDMI working with no corruptions.
> 
> For your viewing pleasure (and playing with my new phone) :-)
> http://www.youtube.com/watch?v=ZJxJnONz7DA
> 
> The external monitor is 1920x1200 I believe.

Jon Mayo says the corruption in the video is display (memory fetch)
underflow. Perhaps this is because (IIRC) the BCT I'm using on Cardhu
programs the memory controller at a slow rate, and the bootloader and/or
kernel is supposed to bump up the rate to the max, but that's not
implemented anywhere yet upstream. If you're testing with "fastboot"
instead of U-Boot, that might be re-programming the memory frequencies,
and hence avoiding this.

I guess we have a fun time ahead of us with mode validation and memory
controller programming.

Re: [PATCH] drm: tegra: Use framebuffer pitch as line stride

[Lucas Stach]

Am Dienstag, den 27.11.2012, 14:39 -0700 schrieb Stephen Warren:
> > For your viewing pleasure (and playing with my new phone) :-)
> > http://www.youtube.com/watch?v=ZJxJnONz7DA
> > 
> > The external monitor is 1920x1200 I believe.
> 
> Jon Mayo says the corruption in the video is display (memory fetch)
> underflow. Perhaps this is because (IIRC) the BCT I'm using on Cardhu
> programs the memory controller at a slow rate, and the bootloader and/or
> kernel is supposed to bump up the rate to the max, but that's not
> implemented anywhere yet upstream. If you're testing with "fastboot"
> instead of U-Boot, that might be re-programming the memory frequencies,
> and hence avoiding this.
> 
> I guess we have a fun time ahead of us with mode validation and memory
> controller programming.

Maybe it's not insufficient memory bandwidth, but just the request
missing the deadline in the memory controller. You may try to adjust the
values in reg MC_LATENCY_ALLOWANCE_DC_0_0
for example.

Regards,
Lucas

Re: [PATCH] drm: tegra: Use framebuffer pitch as line stride

[Mark Zhang]

On 11/28/2012 05:39 AM, Stephen Warren wrote:
> On 11/27/2012 11:17 AM, Stephen Warren wrote:
>> On 11/26/2012 08:16 PM, Mark Zhang wrote:
>>> On 11/27/2012 06:37 AM, Stephen Warren wrote:
>>>> On 11/22/2012 12:37 PM, Thierry Reding wrote:
>>>>> Instead of using the stride derived from the display mode, use the pitch
>>>>> associated with the currently active framebuffer. This fixes a bug where
>>>>> the LCD display content would be skewed when enabling HDMI with a video
>>>>> mode different from that of the LCD.
>>>>
>>>> This patch certainly doesn't cause any additional issues for me, so:
>>>>
>>>> Tested-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>>
>>>> Howwever, it still doesn't allow both Cardhu's LCD panel and external
>>>> HDMI port (1080p) to be active at once. If I boot with both enabled, or
>>>> boot with just the LCD enabled and hot-plug HDMI, as soon as both heads
>>>> are active, then some kind of display corruption starts; it looks like a
>>>> clocking issue or perhaps memory underflow.
>>>
>>> I haven't observed this issue. What kind of display corruption you mean?
>>> Did it recover after some seconds or the display in LVDS panel was
>>> always corrupted?
>>>
>>> During my testing, I connected HDMI while booting cardhu and I can see
>>> the LVDS and HDMI working with no corruptions.
>>
>> For your viewing pleasure (and playing with my new phone) :-)
>> http://www.youtube.com/watch?v=ZJxJnONz7DA
>>
>> The external monitor is 1920x1200 I believe.
> 
> Jon Mayo says the corruption in the video is display (memory fetch)
> underflow. Perhaps this is because (IIRC) the BCT I'm using on Cardhu
> programs the memory controller at a slow rate, and the bootloader and/or
> kernel is supposed to bump up the rate to the max, but that's not
> implemented anywhere yet upstream. If you're testing with "fastboot"
> instead of U-Boot, that might be re-programming the memory frequencies,
> and hence avoiding this.
> 

All right, I just test the framebuffer console and "xinit", I didn't
install the whole ubuntu.

I'll install the ubuntu in my cardhu and see whether I have this kind of
issues.

Mark
> I guess we have a fun time ahead of us with mode validation and memory
> controller programming.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH] drm: tegra: Use framebuffer pitch as line stride

[Mark Zhang]

On 11/28/2012 02:37 PM, Mark Zhang wrote:
> On 11/28/2012 05:39 AM, Stephen Warren wrote:
>> On 11/27/2012 11:17 AM, Stephen Warren wrote:
>>> On 11/26/2012 08:16 PM, Mark Zhang wrote:
>>>> On 11/27/2012 06:37 AM, Stephen Warren wrote:
>>>>> On 11/22/2012 12:37 PM, Thierry Reding wrote:
>>>>>> Instead of using the stride derived from the display mode, use the pitch
>>>>>> associated with the currently active framebuffer. This fixes a bug where
>>>>>> the LCD display content would be skewed when enabling HDMI with a video
>>>>>> mode different from that of the LCD.
>>>>>
>>>>> This patch certainly doesn't cause any additional issues for me, so:
>>>>>
>>>>> Tested-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>>>
>>>>> Howwever, it still doesn't allow both Cardhu's LCD panel and external
>>>>> HDMI port (1080p) to be active at once. If I boot with both enabled, or
>>>>> boot with just the LCD enabled and hot-plug HDMI, as soon as both heads
>>>>> are active, then some kind of display corruption starts; it looks like a
>>>>> clocking issue or perhaps memory underflow.
>>>>
>>>> I haven't observed this issue. What kind of display corruption you mean?
>>>> Did it recover after some seconds or the display in LVDS panel was
>>>> always corrupted?
>>>>
>>>> During my testing, I connected HDMI while booting cardhu and I can see
>>>> the LVDS and HDMI working with no corruptions.
>>>
>>> For your viewing pleasure (and playing with my new phone) :-)
>>> http://www.youtube.com/watch?v=ZJxJnONz7DA
>>>
>>> The external monitor is 1920x1200 I believe.
>>
>> Jon Mayo says the corruption in the video is display (memory fetch)
>> underflow. Perhaps this is because (IIRC) the BCT I'm using on Cardhu
>> programs the memory controller at a slow rate, and the bootloader and/or
>> kernel is supposed to bump up the rate to the max, but that's not
>> implemented anywhere yet upstream. If you're testing with "fastboot"
>> instead of U-Boot, that might be re-programming the memory frequencies,
>> and hence avoiding this.
>>
> 
> All right, I just test the framebuffer console and "xinit", I didn't
> install the whole ubuntu.
> 
> I'll install the ubuntu in my cardhu and see whether I have this kind of
> issues.

Hi swarren, I installed ubuntu 12.04 in l4t and didn't observe the issue
you described. The display worked with no corruptions. I can show you
the video if you want.

What I used for testing is a cardhu board with our downstream U-Boot.

But the HDMI didn't work. The HDMI monitor showed this: "CANNOT DISPLAY
THIS VIDEO MODE, CHANGE COMPUTER DISPLAY INPUT TO 1920x1080@60HZ". So
sounds like the clock setting has some problems... I'll have a look at this.

Mark
> 
> Mark
>> I guess we have a fun time ahead of us with mode validation and memory
>> controller programming.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

Re: [PATCH] drm: tegra: Use framebuffer pitch as line stride

[Stephen Warren]

On 12/03/2012 08:00 PM, Mark Zhang wrote:
> On 11/28/2012 02:37 PM, Mark Zhang wrote:
>> On 11/28/2012 05:39 AM, Stephen Warren wrote:
>>> On 11/27/2012 11:17 AM, Stephen Warren wrote:
>>>> On 11/26/2012 08:16 PM, Mark Zhang wrote:
>>>>> On 11/27/2012 06:37 AM, Stephen Warren wrote:
>>>>>> On 11/22/2012 12:37 PM, Thierry Reding wrote:
>>>>>>> Instead of using the stride derived from the display mode, use the pitch
>>>>>>> associated with the currently active framebuffer. This fixes a bug where
>>>>>>> the LCD display content would be skewed when enabling HDMI with a video
>>>>>>> mode different from that of the LCD.
>>>>>>
>>>>>> This patch certainly doesn't cause any additional issues for me, so:
>>>>>>
>>>>>> Tested-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>>>>
>>>>>> Howwever, it still doesn't allow both Cardhu's LCD panel and external
>>>>>> HDMI port (1080p) to be active at once. If I boot with both enabled, or
>>>>>> boot with just the LCD enabled and hot-plug HDMI, as soon as both heads
>>>>>> are active, then some kind of display corruption starts; it looks like a
>>>>>> clocking issue or perhaps memory underflow.
>>>>>
>>>>> I haven't observed this issue. What kind of display corruption you mean?
>>>>> Did it recover after some seconds or the display in LVDS panel was
>>>>> always corrupted?
>>>>>
>>>>> During my testing, I connected HDMI while booting cardhu and I can see
>>>>> the LVDS and HDMI working with no corruptions.
>>>>
>>>> For your viewing pleasure (and playing with my new phone) :-)
>>>> http://www.youtube.com/watch?v=ZJxJnONz7DA
>>>>
>>>> The external monitor is 1920x1200 I believe.
>>>
>>> Jon Mayo says the corruption in the video is display (memory fetch)
>>> underflow. Perhaps this is because (IIRC) the BCT I'm using on Cardhu
>>> programs the memory controller at a slow rate, and the bootloader and/or
>>> kernel is supposed to bump up the rate to the max, but that's not
>>> implemented anywhere yet upstream. If you're testing with "fastboot"
>>> instead of U-Boot, that might be re-programming the memory frequencies,
>>> and hence avoiding this.
>>>
>>
>> All right, I just test the framebuffer console and "xinit", I didn't
>> install the whole ubuntu.
>>
>> I'll install the ubuntu in my cardhu and see whether I have this kind of
>> issues.
> 
> Hi swarren, I installed ubuntu 12.04 in l4t and didn't observe the issue
> you described. The display worked with no corruptions. I can show you
> the video if you want.
> 
> What I used for testing is a cardhu board with our downstream U-Boot.
> 
> But the HDMI didn't work. The HDMI monitor showed this: "CANNOT DISPLAY
> THIS VIDEO MODE, CHANGE COMPUTER DISPLAY INPUT TO 1920x1080@60HZ". So
> sounds like the clock setting has some problems... I'll have a look at this.

Oh, I thought I'd followed up on this - Jon Mayo said it was display
underflow due to lack of memory bandwidth. IIRC, this may be due to the
BCT programming the memory controller for conservative settings that
don't require non-default voltages from the PMIC, with the expectation
that the bootloader or kernel will reprogram everything for correct
performance.

Re: [PATCH] drm: tegra: Use framebuffer pitch as line stride

[Mark Zhang]

On 12/04/2012 11:50 AM, Stephen Warren wrote:
> On 12/03/2012 08:00 PM, Mark Zhang wrote:
>> On 11/28/2012 02:37 PM, Mark Zhang wrote:
>>> On 11/28/2012 05:39 AM, Stephen Warren wrote:
>>>> On 11/27/2012 11:17 AM, Stephen Warren wrote:
>>>>> On 11/26/2012 08:16 PM, Mark Zhang wrote:
>>>>>> On 11/27/2012 06:37 AM, Stephen Warren wrote:
>>>>>>> On 11/22/2012 12:37 PM, Thierry Reding wrote:
>>>>>>>> Instead of using the stride derived from the display mode, use the pitch
>>>>>>>> associated with the currently active framebuffer. This fixes a bug where
>>>>>>>> the LCD display content would be skewed when enabling HDMI with a video
>>>>>>>> mode different from that of the LCD.
>>>>>>>
>>>>>>> This patch certainly doesn't cause any additional issues for me, so:
>>>>>>>
>>>>>>> Tested-by: Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>>>>>
>>>>>>> Howwever, it still doesn't allow both Cardhu's LCD panel and external
>>>>>>> HDMI port (1080p) to be active at once. If I boot with both enabled, or
>>>>>>> boot with just the LCD enabled and hot-plug HDMI, as soon as both heads
>>>>>>> are active, then some kind of display corruption starts; it looks like a
>>>>>>> clocking issue or perhaps memory underflow.
>>>>>>
>>>>>> I haven't observed this issue. What kind of display corruption you mean?
>>>>>> Did it recover after some seconds or the display in LVDS panel was
>>>>>> always corrupted?
>>>>>>
>>>>>> During my testing, I connected HDMI while booting cardhu and I can see
>>>>>> the LVDS and HDMI working with no corruptions.
>>>>>
>>>>> For your viewing pleasure (and playing with my new phone) :-)
>>>>> http://www.youtube.com/watch?v=ZJxJnONz7DA
>>>>>
>>>>> The external monitor is 1920x1200 I believe.
>>>>
>>>> Jon Mayo says the corruption in the video is display (memory fetch)
>>>> underflow. Perhaps this is because (IIRC) the BCT I'm using on Cardhu
>>>> programs the memory controller at a slow rate, and the bootloader and/or
>>>> kernel is supposed to bump up the rate to the max, but that's not
>>>> implemented anywhere yet upstream. If you're testing with "fastboot"
>>>> instead of U-Boot, that might be re-programming the memory frequencies,
>>>> and hence avoiding this.
>>>>
>>>
>>> All right, I just test the framebuffer console and "xinit", I didn't
>>> install the whole ubuntu.
>>>
>>> I'll install the ubuntu in my cardhu and see whether I have this kind of
>>> issues.
>>
>> Hi swarren, I installed ubuntu 12.04 in l4t and didn't observe the issue
>> you described. The display worked with no corruptions. I can show you
>> the video if you want.
>>
>> What I used for testing is a cardhu board with our downstream U-Boot.
>>
>> But the HDMI didn't work. The HDMI monitor showed this: "CANNOT DISPLAY
>> THIS VIDEO MODE, CHANGE COMPUTER DISPLAY INPUT TO 1920x1080@60HZ". So
>> sounds like the clock setting has some problems... I'll have a look at this.
> 
> Oh, I thought I'd followed up on this - Jon Mayo said it was display
> underflow due to lack of memory bandwidth. IIRC, this may be due to the
> BCT programming the memory controller for conservative settings that
> don't require non-default voltages from the PMIC, with the expectation
> that the bootloader or kernel will reprogram everything for correct
> performance.
> 

OK, I see. But my HDMI doesn't work so I will spend some time digging it.

Mark