gma500: display displaced vertically by a few lines

[Patrik Jakobsson]

On Tue, May 14, 2013 at 2:13 PM, Holger Schurig <holgerschurig at gmail.com> wrote:
> Okay, I found the patch that produces my regression:
>
> ----------------------------------------------------------------------------
> From bc794829141f28e14fe7d0e07e35870bd9aee78c Mon Sep 17 00:00:00 2001
> From: Patrik Jakobsson <patrik.r.jakobsson at gmail.com>
> Date: Mon, 21 May 2012 15:27:30 +0100
> Subject: [PATCH 143/209] gma500: handle poulsbo cursor restriction
>
> Poulsbo needs a physical address in the cursor base register. We allocate a
> stolen memory buffer and copy the cursor image provided by userspace into it.
> When/If we get our own userspace driver we can map this stolen memory directly.
> The patch also adds a mark in chip ops so we can identify devices that has this
> requirement.
> ----------------------------------------------------------------------------
>
> When I modify the patch that psb_chip_ops.cursor_needs_phys doesn't
> get initialized to 1, then the display doesn't get displaced.

Hmm, I would have guessed on the gtt rolling code, but this makes sense.

If we need phys cursor, we allocate a cursor bo in stolen memory and this
happens before the framebuffer is allocated, thus moving the framebuffer 4
pages. Since the gtt rolling code tries to put a pitch of 1 page so it can
perform it's trick we loose 4 lines at the top. The actual problem is in
psbfb_vm_fault() where we assume the framebuffer to be at the start of stolen
memory. The following patch should fix your problem, though I recommend you use
the modesetting driver because you get a hardware accelerated cursor.

Thanks
Patrik

>From 1d68e97f39cb70862f7b02bb430e64dfa07fd08d Mon Sep 17 00:00:00 2001
From: Patrik Jakobsson <patrik.r.jakobsson at gmail.com>
Date: Tue, 14 May 2013 14:37:10 +0200
Subject: [PATCH] drm/gma500: Add fb gtt offset to fb base

Old code assumed framebuffer starts at base of stolen memory. Since the
addition of hardware cursors, this might not be true anymore so add the
gtt offset to the calculation.

Reported-by: Holger Schurig <holgerschurig at gmail.com>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson at gmail.com>
---
 drivers/gpu/drm/gma500/framebuffer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c
b/drivers/gpu/drm/gma500/framebuffer.c
index 1534e22..8b1b6d9 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -121,8 +121,8 @@ static int psbfb_vm_fault(struct vm_area_struct
*vma, struct vm_fault *vmf)
 	unsigned long address;
 	int ret;
 	unsigned long pfn;
-	/* FIXME: assumes fb at stolen base which may not be true */
-	unsigned long phys_addr = (unsigned long)dev_priv->stolen_base;
+	unsigned long phys_addr = (unsigned long)dev_priv->stolen_base +
+				  psbfb->gtt->offset;

 	page_num = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
 	address = (unsigned long)vmf->virtual_address - (vmf->pgoff << PAGE_SHIFT);
-- 
1.8.1.2