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@avionic-design.de --- 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);
On 22.11.2012 21:37, Thierry Reding wrote:
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);
On 22.11.2012 21:37, Thierry Reding wrote:
Hi,
I tested and verified that this fixes our stride problem. Thanks!
Tested-by: Terje Bergstrom tbergstrom@nvidia.com
Tested-by: Mark Zhang markz@nvidia.com
On my Tegra 3 cardhu.
Mark On 11/23/2012 03:37 AM, Thierry Reding wrote:
On 11/22/2012 12:37 PM, Thierry Reding wrote:
This patch certainly doesn't cause any additional issues for me, so:
Tested-by: Stephen Warren swarren@nvidia.com
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.
On 11/27/2012 06:37 AM, Stephen Warren wrote:
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.
On 11/26/2012 08:16 PM, Mark Zhang wrote:
For your viewing pleasure (and playing with my new phone) :-) http://www.youtube.com/watch?v=ZJxJnONz7DA
The external monitor is 1920x1200 I believe.
On 11/27/2012 11:17 AM, Stephen Warren wrote:
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.
On 11/28/2012 02:37 PM, Mark Zhang wrote:
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
On 12/03/2012 08:00 PM, Mark Zhang wrote:
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.
dri-devel@lists.freedesktop.org
-
Lucas Stach -
Mark Zhang -
Mark Zhang -
Stephen Warren -
Terje Bergström -
Thierry Reding