gma500: display displaced vertically by a few lines

Commit Message

Patrik Jakobsson May 14, 2013, 12:50 p.m. UTC

On Tue, May 14, 2013 at 2:13 PM, Holger Schurig <[e-mail]> wrote:
> Okay, I found the patch that produces my regression:
>
> ----------------------------------------------------------------------------
> From bc794829141f28e14fe7d0e07e35870bd9aee78c Mon Sep 17 00:00:00 2001
> From: Patrik Jakobsson <[e-mail]>
> 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 <[e-mail]>
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 <[e-mail]>
Signed-off-by: Patrik Jakobsson <[e-mail]>
---
 drivers/gpu/drm/gma500/framebuffer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

 	address = (unsigned long)vmf->virtual_address - (vmf->pgoff << PAGE_SHIFT);

Comments

Holger Schurig May 14, 2013, 1:07 p.m. UTC | #1

Patrick, have a

Tested-by: Holger Schurig <[e-mail]>

for this.




As for your suggestion:

> though I recommend you use the modesetting driver because you get
> a hardware accelerated cursor.

The current Debian Wheezy xserver-xorg doesn't autoload the
modesettings X11 driver. And I haven't found out how to manually load
that driver ...   also, there is about zilch documentation on that
driver available, also the error messages in the Xorg.0.log don't help
in any way. So, all in all this is too much hassle.

So I'll wait until support for that comes in up Debian SID a.k.a.
Unstable. I actually don't care about an "accelerated cursor" at all.
I don't perceive the mouse cursor (or the text cursor in rxvt-unicode)
to be "slow", so there's not much reason (for me!) in accellerating it
in the first place.

Patrik Jakobsson May 14, 2013, 1:19 p.m. UTC | #2

On Tue, May 14, 2013 at 3:07 PM, Holger Schurig <[e-mail]> wrote:
> Patrick, have a
>
> Tested-by: Holger Schurig <[e-mail]>
>
> for this.

I'll add that.

> As for your suggestion:
>
>> though I recommend you use the modesetting driver because you get
>> a hardware accelerated cursor.
>
> The current Debian Wheezy xserver-xorg doesn't autoload the
> modesettings X11 driver. And I haven't found out how to manually load
> that driver ...   also, there is about zilch documentation on that
> driver available, also the error messages in the Xorg.0.log don't help
> in any way. So, all in all this is too much hassle.

That still confuses me, but let's hope it automagically goes away some day.

> So I'll wait until support for that comes in up Debian SID a.k.a.
> Unstable. I actually don't care about an "accelerated cursor" at all.
> I don't perceive the mouse cursor (or the text cursor in rxvt-unicode)
> to be "slow", so there's not much reason (for me!) in accellerating it
> in the first place.

Sure, you'll only see a difference if you're running a compositing window
manager or your system is under heavy load.

-Patrik

Patch

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;