Re: [PATCH] drm/i915: don't check inconsistent modeset state when force-restoring

[Tomas Melin]

On Wed, Apr 10, 2013 at 9:32 PM, Tomas Melin  wrote:
> On Tue, Apr 9, 2013 at 10:51 PM, Daniel Vetter  wrote:
>> v2: Try harder not to create a big patch (Chris).
>>
> Tested the patch applied to 3.9-rc6. Atleast on my machine that
> helped, although once I managed to get the error (but not warning and
> call trace as before):
> [drm:i9xx_crtc_mode_set] *ERROR* Couldn't find PLL settings for mode!
>

Update: the situation where I still get an error is if the machine is
in standby with the lid open. Then close and open will generate that
kind of error. The patch however fixes the original problem.

thanks,
Tomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: don't check inconsistent modeset state when force-restoring

[Tomas Melin]

On Tue, Apr 9, 2013 at 10:51 PM, Daniel Vetter  wrote:
> v2: Try harder not to create a big patch (Chris).
>
Tested the patch applied to 3.9-rc6. Atleast on my machine that
helped, although once I managed to get the error (but not warning and
call trace as before):
[drm:i9xx_crtc_mode_set] *ERROR* Couldn't find PLL settings for mode!


On Wed, Apr 10, 2013 at 8:27 PM, Richard Cochran
 wrote:
> I couldn't see right away how to fix it up, so I just compiled your
> drm-intel-next-queued plus this patch. If I close the netbook's lid
> and open it again, the screen is blank, no backlight, and the machine
> seems to be frozen.

The patch doesn't apply at all to 3.8 since function crtc_restore_mode
is missing and also 3.9-rc6 was quite different.
This version of the patch applies atleast to 3.9-rc6 if you want to test it:

>From 9f498da114cea3d82c291b7090d4441664d7870c Mon Sep 17 00:00:00 2001
From: Tomas Melin 
Date: Wed, 10 Apr 2013 18:53:42 +0300
Subject: [PATCH] applied patch

---
 drivers/gpu/drm/i915/intel_display.c |   36 +++---
 1 file changed, 29 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b20d501..83b11c5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7771,9 +7771,9 @@ intel_modeset_check_state(struct drm_device *dev)
 }
 }

-int intel_set_mode(struct drm_crtc *crtc,
-   struct drm_display_mode *mode,
-   int x, int y, struct drm_framebuffer *fb)
+static int __intel_set_mode(struct drm_crtc *crtc,
+struct drm_display_mode *mode,
+int x, int y, struct drm_framebuffer *fb)
 {
 struct drm_device *dev = crtc->dev;
 drm_i915_private_t *dev_priv = dev->dev_private;
@@ -7863,18 +7863,33 @@ done:
 if (ret && crtc->enabled) {
 crtc->hwmode = *saved_hwmode;
 crtc->mode = *saved_mode;
-} else {
-intel_modeset_check_state(dev);
 }

 out:
 kfree(saved_mode);
 return ret;
 }
+int intel_set_mode(struct drm_crtc *crtc,
+ struct drm_display_mode *mode,
+ int x, int y, struct drm_framebuffer *fb)
+{
+int ret;
+
+ret = __intel_set_mode(crtc, mode, x, y, fb);
+
+if (ret == 0)
+intel_modeset_check_state(crtc->dev);
+
+return ret;
+}
+
+

 void intel_crtc_restore_mode(struct drm_crtc *crtc)
 {
-intel_set_mode(crtc, &crtc->mode, crtc->x, crtc->y, crtc->fb);
+__intel_set_mode(crtc, &crtc->mode, crtc->x, crtc->y, crtc->fb);
+
+intel_modeset_check_state(crtc->dev);
 }

 #undef for_each_intel_crtc_masked
@@ -9172,8 +9187,15 @@ void intel_modeset_setup_hw_state(struct drm_device *dev,
 }

 if (force_restore) {
+/*
+ * We need to use raw interfaces for restoring state to avoid
+ * checking (bogus) intermediate states.
+ */
 for_each_pipe(pipe) {
-intel_crtc_restore_mode(dev_priv->pipe_to_crtc_mapping[pipe]);
+ struct drm_crtc *crtc =
+ dev_priv->pipe_to_crtc_mapping[pipe];
+__intel_set_mode(crtc, &crtc->mode, crtc->x, crtc->y,
+ crtc->fb);
 }

 i915_redisable_vga(dev);
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: don't check inconsistent modeset state when force-restoring

[Richard Cochran]

On Wed, Apr 10, 2013 at 02:07:24PM +0200, Daniel Vetter wrote:
> 
> It's written against drm-intel-next-queued at
> 
> http://cgit.freedesktop.org/~danvet/drm-intel
> 
> I've thought that it should apply pretty cleanly against older kernels,
> too. Apparently it conflicts a bit in intel_modeset_setup_hw_state, you
> can just do the s/intel_crtc_restore_mode/__intel_set_mode/ change
> manually.

I couldn't see right away how to fix it up, so I just compiled your
drm-intel-next-queued plus this patch. If I close the netbook's lid
and open it again, the screen is blank, no backlight, and the machine
seems to be frozen.

I think I can live with the warning.

Thanks anyhow,
Richard
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=62959

--- Comment #31 from Alexandre Demers  ---
(In reply to comment #29)
> Do either of Jerome's patches help?

Applied both, ran 2 times r600.test and everything went fine. I'll test with
only one patch applied at a time later today.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/abf82d79/attachment.html>

[PATCH] drm/i915: don't check inconsistent modeset state when force-restoring

[Daniel Vetter]

It will be only consistent once we've restored all the crtcs. Since a
bunch of other callers also want to just restore a single crtc, add a
boolean to disable checking only where it doesn't make sense.

Note that intel_modeset_setup_hw_state already has a call to
intel_modeset_check_state at the end, so we don't reduce the amount of
checking.

v2: Try harder not to create a big patch (Chris).

v3: Even smaller (still Chris). Also fix a trailing space.

v4: Rebased on top of 3.9-rc6.

References: https://lkml.org/lkml/2013/3/16/60
Cc: Tomas Melin 
Cc: Richard Cochran 
Cc: Chris Wilson 
Cc: stable at vger.kernel.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c |   32 ++--
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b20d501..5f1eb50 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7771,9 +7771,9 @@ intel_modeset_check_state(struct drm_device *dev)
}
 }

-int intel_set_mode(struct drm_crtc *crtc,
-  struct drm_display_mode *mode,
-  int x, int y, struct drm_framebuffer *fb)
+static int __intel_set_mode(struct drm_crtc *crtc,
+   struct drm_display_mode *mode,
+   int x, int y, struct drm_framebuffer *fb)
 {
struct drm_device *dev = crtc->dev;
drm_i915_private_t *dev_priv = dev->dev_private;
@@ -7863,8 +7863,6 @@ done:
if (ret && crtc->enabled) {
crtc->hwmode = *saved_hwmode;
crtc->mode = *saved_mode;
-   } else {
-   intel_modeset_check_state(dev);
}

 out:
@@ -7872,6 +7870,20 @@ out:
return ret;
 }

+int intel_set_mode(struct drm_crtc *crtc,
+struct drm_display_mode *mode,
+int x, int y, struct drm_framebuffer *fb)
+{
+   int ret;
+
+   ret = __intel_set_mode(crtc, mode, x, y, fb);
+
+   if (ret == 0)
+   intel_modeset_check_state(crtc->dev);
+
+   return ret;
+}
+
 void intel_crtc_restore_mode(struct drm_crtc *crtc)
 {
intel_set_mode(crtc, &crtc->mode, crtc->x, crtc->y, crtc->fb);
@@ -9172,8 +9184,16 @@ void intel_modeset_setup_hw_state(struct drm_device *dev,
}

if (force_restore) {
+   /*
+* We need to use raw interfaces for restoring state to avoid
+* checking (bogus) intermediate states.
+*/
for_each_pipe(pipe) {
-   
intel_crtc_restore_mode(dev_priv->pipe_to_crtc_mapping[pipe]);
+   struct drm_crtc *crtc =
+   dev_priv->pipe_to_crtc_mapping[pipe];
+
+   __intel_set_mode(crtc, &crtc->mode, crtc->x, crtc->y,
+crtc->fb);
}

i915_redisable_vga(dev);
-- 
1.7.10.4

[Intel-gfx] [PATCH] drm/i915: don't check inconsistent modeset state when force-restoring

[Daniel Vetter]

On Wed, Apr 10, 2013 at 7:27 PM, Richard Cochran
 wrote:
> On Wed, Apr 10, 2013 at 02:07:24PM +0200, Daniel Vetter wrote:
>>
>> It's written against drm-intel-next-queued at
>>
>> http://cgit.freedesktop.org/~danvet/drm-intel
>>
>> I've thought that it should apply pretty cleanly against older kernels,
>> too. Apparently it conflicts a bit in intel_modeset_setup_hw_state, you
>> can just do the s/intel_crtc_restore_mode/__intel_set_mode/ change
>> manually.
>
> I couldn't see right away how to fix it up, so I just compiled your
> drm-intel-next-queued plus this patch. If I close the netbook's lid
> and open it again, the screen is blank, no backlight, and the machine
> seems to be frozen.
>
> I think I can live with the warning.

That patch should crash at all, so this is not expected. Can you pls
check whether plain drm-intel-nightly is broken, too?

I'll quickly port the patch (in it's latest v3 version) to 3.9-rc
kernels for you to test.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/i915: don't check inconsistent modeset state when force-restoring

[Tomas Melin]

On Tue, Apr 9, 2013 at 10:51 PM, Daniel Vetter  
wrote:
> v2: Try harder not to create a big patch (Chris).
>
Tested the patch applied to 3.9-rc6. Atleast on my machine that
helped, although once I managed to get the error (but not warning and
call trace as before):
[drm:i9xx_crtc_mode_set] *ERROR* Couldn't find PLL settings for mode!


On Wed, Apr 10, 2013 at 8:27 PM, Richard Cochran
 wrote:
> I couldn't see right away how to fix it up, so I just compiled your
> drm-intel-next-queued plus this patch. If I close the netbook's lid
> and open it again, the screen is blank, no backlight, and the machine
> seems to be frozen.

The patch doesn't apply at all to 3.8 since function crtc_restore_mode
is missing and also 3.9-rc6 was quite different.
This version of the patch applies atleast to 3.9-rc6 if you want to test it:

>From 9f498da114cea3d82c291b7090d4441664d7870c Mon Sep 17 00:00:00 2001
From: Tomas Melin 
Date: Wed, 10 Apr 2013 18:53:42 +0300
Subject: [PATCH] applied patch

---
 drivers/gpu/drm/i915/intel_display.c |   36 +++---
 1 file changed, 29 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b20d501..83b11c5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7771,9 +7771,9 @@ intel_modeset_check_state(struct drm_device *dev)
 }
 }

-int intel_set_mode(struct drm_crtc *crtc,
-   struct drm_display_mode *mode,
-   int x, int y, struct drm_framebuffer *fb)
+static int __intel_set_mode(struct drm_crtc *crtc,
+struct drm_display_mode *mode,
+int x, int y, struct drm_framebuffer *fb)
 {
 struct drm_device *dev = crtc->dev;
 drm_i915_private_t *dev_priv = dev->dev_private;
@@ -7863,18 +7863,33 @@ done:
 if (ret && crtc->enabled) {
 crtc->hwmode = *saved_hwmode;
 crtc->mode = *saved_mode;
-} else {
-intel_modeset_check_state(dev);
 }

 out:
 kfree(saved_mode);
 return ret;
 }
+int intel_set_mode(struct drm_crtc *crtc,
+ struct drm_display_mode *mode,
+ int x, int y, struct drm_framebuffer *fb)
+{
+int ret;
+
+ret = __intel_set_mode(crtc, mode, x, y, fb);
+
+if (ret == 0)
+intel_modeset_check_state(crtc->dev);
+
+return ret;
+}
+
+

 void intel_crtc_restore_mode(struct drm_crtc *crtc)
 {
-intel_set_mode(crtc, &crtc->mode, crtc->x, crtc->y, crtc->fb);
+__intel_set_mode(crtc, &crtc->mode, crtc->x, crtc->y, crtc->fb);
+
+intel_modeset_check_state(crtc->dev);
 }

 #undef for_each_intel_crtc_masked
@@ -9172,8 +9187,15 @@ void intel_modeset_setup_hw_state(struct drm_device *dev,
 }

 if (force_restore) {
+/*
+ * We need to use raw interfaces for restoring state to avoid
+ * checking (bogus) intermediate states.
+ */
 for_each_pipe(pipe) {
-intel_crtc_restore_mode(dev_priv->pipe_to_crtc_mapping[pipe]);
+ struct drm_crtc *crtc =
+ dev_priv->pipe_to_crtc_mapping[pipe];
+__intel_set_mode(crtc, &crtc->mode, crtc->x, crtc->y,
+ crtc->fb);
 }

 i915_redisable_vga(dev);
--
1.7.9.5

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #45 from Alexandre Demers  ---
(In reply to comment #44)
> Does disabling acceleration help?
> 
> Option "NoAccel" "True"
> 
> In the device section of you xorg.conf

I was able to log in, launch "xset dpms force off". My screen turned off. After
waking it up, the display was still shifted.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/c7c8355e/attachment.html>

[PATCH v2] gma500:fix build failure for 3.9-rc5

[Xiong Zhou]

From: Xiong Zhou 

Last version of this patch is not clear enough and X86 duplicated.

This patch fixes build failure of v3.9-rc5 and rc6.
When config ACPI_VIDEO as m, DRM_GMA500 as y, here comes the failure.
GMA5/600 needs acpi_video just like nouveau.
And some tab type fix by the way.

Failure message:
drivers/built-in.o: In function `psb_driver_load':
kernel-3.9-rc5/drivers/gpu/drm/gma500/psb_drv.c:340: \
undefined reference to `acpi_video_register'
make: *** [vmlinux] Error 1

Signed-off-by: Xiong Zhou 
---
drivers/gpu/drm/gma500/Kconfig |   13 +
1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index 1188f0f..1f6e2df 100644
--- a/drivers/gpu/drm/gma500/Kconfig
+++ b/drivers/gpu/drm/gma500/Kconfig
@@ -2,10 +2,15 @@ config DRM_GMA500
tristate "Intel GMA5/600 KMS Framebuffer"
depends on DRM && PCI && X86
select FB_CFB_COPYAREA
-select FB_CFB_FILLRECT
-select FB_CFB_IMAGEBLIT
-select DRM_KMS_HELPER
-select DRM_TTM
+   select FB_CFB_FILLRECT
+   select FB_CFB_IMAGEBLIT
+   select DRM_KMS_HELPER
+   select DRM_TTM
+   # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915
+   select ACPI_VIDEO if ACPI
+   select BACKLIGHT_CLASS_DEVICE if ACPI
+   select VIDEO_OUTPUT_CONTROL if ACPI
+   select INPUT if ACPI
help
  Say yes for an experimental 2D KMS framebuffer driver for the
  Intel GMA500 ('Poulsbo') and other Intel IMG based graphics

[Bug 57919] Visual glitches in unity with Radeon HD 7600M

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57919

--- Comment #15 from Thilo Cestonaro  ---
The first is already part of the kernel, so it's the kernel + the second patch.

Greetings
Thilo

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/59b97192/attachment.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #44 from Alex Deucher  ---
Does disabling acceleration help?

Option "NoAccel" "True"

In the device section of you xorg.conf

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/ae8265b4/attachment.html>

[Bug 57919] Visual glitches in unity with Radeon HD 7600M

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57919

--- Comment #14 from Thilo Cestonaro  ---
Sadly I must say, that this patch changes the behave in no way, too. :( ...

It's still flickering and showing theses glitches as in the video.

Could I add any debug output, any printks which would help to identify the
problem? 
Anything else I should test? 
Currently I'm testing on raring latest with following kernel + the two patches
mentioned in this thread.

Kernel:
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-raring.git;a=commit;h=82983bbf61f02dec860e266217f002c18a06006e

Greetings
Thilo

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/fbd5609c/attachment.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #43 from Vladimir  ---
Exactly same happens here

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/fdcb7d31/attachment.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #42 from Alexandre Demers  ---
(In reply to comment #41)
> (In reply to comment #40)
> > (In reply to comment #39)
> > > (In reply to comment #38)
> > > > How to do dpms cycle ?
> > > 
> > > On the console, just wait for the screen to blank.  In X:
> > > xset dpms force off
> > > will force a dpms cycle.
> > 
> > That would valid if we were able to log in X. Is there a way to do it if we
> > are still in the console?
> 
> I think you can adjust the console blanking with setterm.  Can you start X
> and force a dpms cycle even if the screen is garbled?

X starts, but I'm never getting to the log screen. Once X is started, if I go
into console and come back, only my mouse pointer is being displayed correctly,
the background stays as what was in the console. I suppose something is hanging
or crashing X.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/bb8a912d/attachment.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #41 from Alex Deucher  ---
(In reply to comment #40)
> (In reply to comment #39)
> > (In reply to comment #38)
> > > How to do dpms cycle ?
> > 
> > On the console, just wait for the screen to blank.  In X:
> > xset dpms force off
> > will force a dpms cycle.
> 
> That would valid if we were able to log in X. Is there a way to do it if we
> are still in the console?

I think you can adjust the console blanking with setterm.  Can you start X and
force a dpms cycle even if the screen is garbled?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/c97a42e1/attachment-0001.html>

[PATCH] drivers/gpu/drm/gma500:fix build failure for 3.9-rc5

[Xiong Zhou]

On Tue, 9 Apr 2013, Patrik Jakobsson wrote:

> On Tue, Apr 9, 2013 at 8:35 AM, Xiong Zhou  wrote:
> > From: Xiong Zhou 
> >
> > This patch fixes build failure of v3.9-rc5.
> > When config ACPI_VIDEO as m, DRM_GMA500 as y, here comes the failure.
> > gma5/600 needs acpi_video just like nouveau.
> >
> > Failure message:
> > drivers/built-in.o: In function `psb_driver_load':
> > kernel-3.9-rc5/drivers/gpu/drm/gma500/psb_drv.c:340: \
> > undefined reference to `acpi_video_register'
> > make: *** [vmlinux] Error 1
> >
> > Signed-off-by: Xiong Zhou 
> > ---
> > drivers/gpu/drm/gma500/Kconfig |1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
> > index 1188f0f..d64fc45 100644
> > --- a/drivers/gpu/drm/gma500/Kconfig
> > +++ b/drivers/gpu/drm/gma500/Kconfig
> > @@ -6,6 +6,7 @@ config DRM_GMA500
> >  select FB_CFB_IMAGEBLIT
> >  select DRM_KMS_HELPER
> >  select DRM_TTM
> > +select ACPI_VIDEO if ACPI && X86 && BACKLIGHT_CLASS_DEVICE && 
> > VIDEO_OUTPUT_CONTROL && INPUT
> > help
> >   Say yes for an experimental 2D KMS framebuffer driver for the
> >   Intel GMA500 ('Poulsbo') and other Intel IMG based graphics
> > --
> 
> Hi
> 
> Thanks for catching this, but if I can be picky, I'd prefer if you wrote it
> like i915 does. E.g.
> 
>   select ACPI_VIDEO if ACPI
>   select BACKLIGHT_CLASS_DEVICE if ACPI
>   ...
> 
> And you can skip X86 since we already 'depend' on it.
> 
> Thanks
> Patrik
> 

Nice advices, Thanks!


Xiong

[PATCH 15/15] gma500:fix build failure for 3.9-rc5

[Patrik Jakobsson]

From: Xiong Zhou 

Last version of this patch is not clear enough and X86 duplicated.

This patch fixes build failure of v3.9-rc5 and rc6.
When config ACPI_VIDEO as m, DRM_GMA500 as y, here comes the failure.
GMA5/600 needs acpi_video just like nouveau.
And some tab type fix by the way.

Failure message:
drivers/built-in.o: In function `psb_driver_load':
kernel-3.9-rc5/drivers/gpu/drm/gma500/psb_drv.c:340: \
undefined reference to `acpi_video_register'
make: *** [vmlinux] Error 1

Signed-off-by: Xiong Zhou 
Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/Kconfig |   13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index 42e665c..92760ff 100644
--- a/drivers/gpu/drm/gma500/Kconfig
+++ b/drivers/gpu/drm/gma500/Kconfig
@@ -2,10 +2,15 @@ config DRM_GMA500
tristate "Intel GMA5/600 KMS Framebuffer"
depends on DRM && PCI && X86 && EXPERIMENTAL
select FB_CFB_COPYAREA
-select FB_CFB_FILLRECT
-select FB_CFB_IMAGEBLIT
-select DRM_KMS_HELPER
-select DRM_TTM
+   select FB_CFB_FILLRECT
+   select FB_CFB_IMAGEBLIT
+   select DRM_KMS_HELPER
+   select DRM_TTM
+   # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915
+   select ACPI_VIDEO if ACPI
+   select BACKLIGHT_CLASS_DEVICE if ACPI
+   select VIDEO_OUTPUT_CONTROL if ACPI
+   select INPUT if ACPI
help
  Say yes for an experimental 2D KMS framebuffer driver for the
  Intel GMA500 ('Poulsbo') and other Intel IMG based graphics
-- 
1.7.10.4

[PATCH 14/15] drm/gma500: Fix hibernation problems on sdvo encoders

[Patrik Jakobsson]

The state of the SDVO chip is more difficult to save than the LVDS so we do a
full mode set on the crtc to get SDVO operational again. The SDVOB/C register is
also stored just in case we have special bits set in the future.

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/psb_intel_sdvo.c |   34 +++
 1 file changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/gma500/psb_intel_sdvo.c 
b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
index a4cc777a..cd1b407 100644
--- a/drivers/gpu/drm/gma500/psb_intel_sdvo.c
+++ b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
@@ -134,6 +134,9 @@ struct psb_intel_sdvo {

/* Input timings for adjusted_mode */
struct psb_intel_sdvo_dtd input_dtd;
+
+   /* Saved SDVO output states */
+   uint32_t saveSDVO; /* Can be SDVOB or SDVOC depending on sdvo_reg */
 };

 struct psb_intel_sdvo_connector {
@@ -1830,6 +1833,35 @@ done:
 #undef CHECK_PROPERTY
 }

+static void psb_intel_sdvo_save(struct drm_connector *connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct psb_intel_encoder *psb_intel_encoder =
+   psb_intel_attached_encoder(connector);
+   struct psb_intel_sdvo *sdvo =
+   to_psb_intel_sdvo(&psb_intel_encoder->base);
+
+   sdvo->saveSDVO = REG_READ(sdvo->sdvo_reg);
+}
+
+static void psb_intel_sdvo_restore(struct drm_connector *connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_encoder *encoder =
+   &psb_intel_attached_encoder(connector)->base;
+   struct psb_intel_sdvo *sdvo = to_psb_intel_sdvo(encoder);
+   struct drm_crtc *crtc = encoder->crtc;
+
+   REG_WRITE(sdvo->sdvo_reg, sdvo->saveSDVO);
+
+   /* Force dpms on upon resume */
+   psb_intel_sdvo_dpms(encoder, DRM_MODE_DPMS_ON);
+
+   /* Force a full mode set on the crtc. We're supposed to have the
+  mode_config lock already. */
+   drm_crtc_helper_set_mode(crtc, &crtc->mode, crtc->x, crtc->y, NULL);
+}
+
 static const struct drm_encoder_helper_funcs psb_intel_sdvo_helper_funcs = {
.dpms = psb_intel_sdvo_dpms,
.mode_fixup = psb_intel_sdvo_mode_fixup,
@@ -1840,6 +1872,8 @@ static const struct drm_encoder_helper_funcs 
psb_intel_sdvo_helper_funcs = {

 static const struct drm_connector_funcs psb_intel_sdvo_connector_funcs = {
.dpms = drm_helper_connector_dpms,
+   .save = psb_intel_sdvo_save,
+   .restore = psb_intel_sdvo_restore,
.detect = psb_intel_sdvo_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.set_property = psb_intel_sdvo_set_property,
-- 
1.7.10.4

[PATCH 13/15] drm/gma500: Add hooks for hibernation

[Patrik Jakobsson]

Currently we do whatever is done during suspend/resume but we might need some
more work for hibernation so keep them in separate functions.

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/power.c   |   15 +++
 drivers/gpu/drm/gma500/power.h   |3 +++
 drivers/gpu/drm/gma500/psb_drv.c |3 +++
 3 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/gma500/power.c b/drivers/gpu/drm/gma500/power.c
index 4c575a9..b6b135f 100644
--- a/drivers/gpu/drm/gma500/power.c
+++ b/drivers/gpu/drm/gma500/power.c
@@ -315,3 +315,18 @@ int psb_runtime_idle(struct device *dev)
else
return 1;
 }
+
+int gma_power_thaw(struct device *_dev)
+{
+   return gma_power_resume(_dev);
+}
+
+int gma_power_freeze(struct device *_dev)
+{
+   return gma_power_suspend(_dev);
+}
+
+int gma_power_restore(struct device *_dev)
+{
+   return gma_power_resume(_dev);
+}
diff --git a/drivers/gpu/drm/gma500/power.h b/drivers/gpu/drm/gma500/power.h
index 1969d2e..56d8708 100644
--- a/drivers/gpu/drm/gma500/power.h
+++ b/drivers/gpu/drm/gma500/power.h
@@ -41,6 +41,9 @@ void gma_power_uninit(struct drm_device *dev);
  */
 int gma_power_suspend(struct device *dev);
 int gma_power_resume(struct device *dev);
+int gma_power_thaw(struct device *dev);
+int gma_power_freeze(struct device *dev);
+int gma_power_restore(struct device *_dev);

 /*
  * These are the functions the driver should use to wrap all hw access
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 111e3df..bddea58 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -601,6 +601,9 @@ static void psb_remove(struct pci_dev *pdev)
 static const struct dev_pm_ops psb_pm_ops = {
.resume = gma_power_resume,
.suspend = gma_power_suspend,
+   .thaw = gma_power_thaw,
+   .freeze = gma_power_freeze,
+   .restore = gma_power_restore,
.runtime_suspend = psb_runtime_suspend,
.runtime_resume = psb_runtime_resume,
.runtime_idle = psb_runtime_idle,
-- 
1.7.10.4

[PATCH 12/15] drm/gma500: Activate the gtt rebuild on suspend/resume

[Patrik Jakobsson]

This patch activates the rebuilding of the gtt. Currently we reinitialize the
gtt by inserting the stolen pages again and map the rest to our scratch page.
Then we go about restoring the needed ranges. This is a bit overkill but right
now we don't have that much to restore so better safe than sorry.

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/power.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/gma500/power.c b/drivers/gpu/drm/gma500/power.c
index 889b854..4c575a9 100644
--- a/drivers/gpu/drm/gma500/power.c
+++ b/drivers/gpu/drm/gma500/power.c
@@ -110,6 +110,8 @@ static void gma_resume_display(struct pci_dev *pdev)
PSB_WVDC32(dev_priv->pge_ctl | _PSB_PGETBL_ENABLED, PSB_PGETBL_CTL);
pci_write_config_word(pdev, PSB_GMCH_CTRL,
dev_priv->gmch_ctrl | _PSB_GMCH_ENABLED);
+
+   psb_gtt_restore(dev); /* Rebuild our GTT mappings */
dev_priv->ops->restore_regs(dev);
 }

-- 
1.7.10.4

[PATCH 11/15] drm/gma500: Add support for rebuilding the gtt

[Patrik Jakobsson]

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/gtt.c |   45 ++
 drivers/gpu/drm/gma500/gtt.h |2 +-
 2 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
index 04a371a..2f12faf 100644
--- a/drivers/gpu/drm/gma500/gtt.c
+++ b/drivers/gpu/drm/gma500/gtt.c
@@ -80,7 +80,8 @@ static u32 __iomem *psb_gtt_entry(struct drm_device *dev, 
struct gtt_range *r)
  * the GTT. This is protected via the gtt mutex which the caller
  * must hold.
  */
-static int psb_gtt_insert(struct drm_device *dev, struct gtt_range *r)
+static int psb_gtt_insert(struct drm_device *dev, struct gtt_range *r,
+ int resume)
 {
u32 __iomem *gtt_slot;
u32 pte;
@@ -97,8 +98,10 @@ static int psb_gtt_insert(struct drm_device *dev, struct 
gtt_range *r)
gtt_slot = psb_gtt_entry(dev, r);
pages = r->pages;

-   /* Make sure changes are visible to the GPU */
-   set_pages_array_wc(pages, r->npage);
+   if (!resume) {
+   /* Make sure changes are visible to the GPU */
+   set_pages_array_wc(pages, r->npage);
+   }

/* Write our page entries into the GTT itself */
for (i = r->roll; i < r->npage; i++) {
@@ -269,7 +272,7 @@ int psb_gtt_pin(struct gtt_range *gt)
ret = psb_gtt_attach_pages(gt);
if (ret < 0)
goto out;
-   ret = psb_gtt_insert(dev, gt);
+   ret = psb_gtt_insert(dev, gt, 0);
if (ret < 0) {
psb_gtt_detach_pages(gt);
goto out;
@@ -421,9 +424,11 @@ int psb_gtt_init(struct drm_device *dev, int resume)
int ret = 0;
uint32_t pte;

-   mutex_init(&dev_priv->gtt_mutex);
+   if (!resume) {
+   mutex_init(&dev_priv->gtt_mutex);
+   psb_gtt_alloc(dev);
+   }

-   psb_gtt_alloc(dev);
pg = &dev_priv->gtt;

/* Enable the GTT */
@@ -505,7 +510,8 @@ int psb_gtt_init(struct drm_device *dev, int resume)
/*
 *  Map the GTT and the stolen memory area
 */
-   dev_priv->gtt_map = ioremap_nocache(pg->gtt_phys_start,
+   if (!resume)
+   dev_priv->gtt_map = ioremap_nocache(pg->gtt_phys_start,
gtt_pages << PAGE_SHIFT);
if (!dev_priv->gtt_map) {
dev_err(dev->dev, "Failure to map gtt.\n");
@@ -513,7 +519,9 @@ int psb_gtt_init(struct drm_device *dev, int resume)
goto out_err;
}

-   dev_priv->vram_addr = ioremap_wc(dev_priv->stolen_base, stolen_size);
+   if (!resume)
+   dev_priv->vram_addr = ioremap_wc(dev_priv->stolen_base,
+stolen_size);
if (!dev_priv->vram_addr) {
dev_err(dev->dev, "Failure to map stolen base.\n");
ret = -ENOMEM;
@@ -549,3 +557,24 @@ out_err:
psb_gtt_takedown(dev);
return ret;
 }
+
+int psb_gtt_restore(struct drm_device *dev)
+{
+   struct drm_psb_private *dev_priv = dev->dev_private;
+   struct resource *r = dev_priv->gtt_mem->child;
+   struct gtt_range *range;
+
+   /* On resume, the gtt_mutex is already initialized */
+   mutex_lock(&dev_priv->gtt_mutex);
+   psb_gtt_init(dev, 1);
+
+   while (r != NULL) {
+   range = container_of(r, struct gtt_range, resource);
+   if (range->pages)
+   psb_gtt_insert(dev, range, 1);
+   r = r->sibling;
+   }
+   mutex_unlock(&dev_priv->gtt_mutex);
+
+   return 0;
+}
diff --git a/drivers/gpu/drm/gma500/gtt.h b/drivers/gpu/drm/gma500/gtt.h
index aa17423..6191d10 100644
--- a/drivers/gpu/drm/gma500/gtt.h
+++ b/drivers/gpu/drm/gma500/gtt.h
@@ -60,5 +60,5 @@ extern int psb_gtt_pin(struct gtt_range *gt);
 extern void psb_gtt_unpin(struct gtt_range *gt);
 extern void psb_gtt_roll(struct drm_device *dev,
struct gtt_range *gt, int roll);
-
+extern int psb_gtt_restore(struct drm_device *dev);
 #endif
-- 
1.7.10.4

[PATCH 10/15] drm/gma500: Change fb name so pm-utils doesn't apply quirks

[Patrik Jakobsson]

By having 'drm' and 'fb' in the fb screeninfo id, pm-utils will leave us
alone. Otherwise we'll have quirks up to our ears and resume will break.

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/framebuffer.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 2590cac..31ac392 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -431,7 +431,7 @@ static int psbfb_create(struct psb_fbdev *fbdev,
fbdev->psb_fb_helper.fbdev = info;

drm_fb_helper_fill_fix(info, fb->pitches[0], fb->depth);
-   strcpy(info->fix.id, "psbfb");
+   strcpy(info->fix.id, "psbdrmfb");

info->flags = FBINFO_DEFAULT;
if (dev_priv->ops->accel_2d && pitch_lines > 8) /* 2D engine */
-- 
1.7.10.4

[PATCH 09/15] gma500: Make VGA and HDMI connector hotpluggable

[Patrik Jakobsson]

From: Kero van Gelder 

Both VGA and HDMI connectors are available on my Asus EeePC X101CH.
This patch will cause output to be shown on either when plugged in.
For both, it shows the leftmost 800x600, of the 1024x600 on LVDS.

Signed-off-by: Kero van Gelder 
Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/cdv_intel_crt.c  |1 +
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c |1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_crt.c 
b/drivers/gpu/drm/gma500/cdv_intel_crt.c
index 8c17534..7b8386f 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_crt.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_crt.c
@@ -276,6 +276,7 @@ void cdv_intel_crt_init(struct drm_device *dev,
goto failed_connector;

connector = &psb_intel_connector->base;
+   connector->polled = DRM_CONNECTOR_POLL_HPD;
drm_connector_init(dev, connector,
&cdv_intel_crt_connector_funcs, DRM_MODE_CONNECTOR_VGA);

diff --git a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c 
b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
index e223b50..464153d 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
@@ -319,6 +319,7 @@ void cdv_hdmi_init(struct drm_device *dev,
goto err_priv;

connector = &psb_intel_connector->base;
+   connector->polled = DRM_CONNECTOR_POLL_HPD;
encoder = &psb_intel_encoder->base;
drm_connector_init(dev, connector,
   &cdv_hdmi_connector_funcs,
-- 
1.7.10.4

[PATCH 08/15] drm/gma500: Clean up various defines

[Patrik Jakobsson]

Remove unused defines that we'll never use and fix naming in some include guards

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/intel_bios.h|6 +++---
 drivers/gpu/drm/gma500/psb_intel_display.c |2 --
 drivers/gpu/drm/gma500/psb_intel_drv.h |8 
 drivers/gpu/drm/gma500/psb_intel_reg.h |1 -
 drivers/gpu/drm/gma500/psb_irq.h   |6 +++---
 5 files changed, 6 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/gma500/intel_bios.h 
b/drivers/gpu/drm/gma500/intel_bios.h
index c6267c9..978ae4b 100644
--- a/drivers/gpu/drm/gma500/intel_bios.h
+++ b/drivers/gpu/drm/gma500/intel_bios.h
@@ -19,8 +19,8 @@
  *
  */

-#ifndef _I830_BIOS_H_
-#define _I830_BIOS_H_
+#ifndef _INTEL_BIOS_H_
+#define _INTEL_BIOS_H_

 #include 
 #include 
@@ -618,4 +618,4 @@ extern void psb_intel_destroy_bios(struct drm_device *dev);
 #definePORT_IDPC   8
 #definePORT_IDPD   9

-#endif /* _I830_BIOS_H_ */
+#endif /* _INTEL_BIOS_H_ */
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c 
b/drivers/gpu/drm/gma500/psb_intel_display.c
index ccc1c6b..6e8f42b 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -50,8 +50,6 @@ struct psb_intel_p2_t {
int p2_slow, p2_fast;
 };

-#define INTEL_P2_NUM 2
-
 struct psb_intel_limit_t {
struct psb_intel_range_t dot, vco, n, m, m1, m2, p, p1;
struct psb_intel_p2_t p2;
diff --git a/drivers/gpu/drm/gma500/psb_intel_drv.h 
b/drivers/gpu/drm/gma500/psb_intel_drv.h
index 90f2d11..4dcae42 100644
--- a/drivers/gpu/drm/gma500/psb_intel_drv.h
+++ b/drivers/gpu/drm/gma500/psb_intel_drv.h
@@ -32,9 +32,6 @@
 /* maximum connectors per crtcs in the mode set */
 #define INTELFB_CONN_LIMIT 4

-#define INTEL_I2C_BUS_DVO 1
-#define INTEL_I2C_BUS_SDVO 2
-
 /* Intel Pipe Clone Bit */
 #define INTEL_HDMIB_CLONE_BIT 1
 #define INTEL_HDMIC_CLONE_BIT 2
@@ -68,11 +65,6 @@
 #define INTEL_OUTPUT_DISPLAYPORT 9
 #define INTEL_OUTPUT_EDP 10

-#define INTEL_DVO_CHIP_NONE 0
-#define INTEL_DVO_CHIP_LVDS 1
-#define INTEL_DVO_CHIP_TMDS 2
-#define INTEL_DVO_CHIP_TVOUT 4
-
 #define INTEL_MODE_PIXEL_MULTIPLIER_SHIFT (0x0)
 #define INTEL_MODE_PIXEL_MULTIPLIER_MASK (0xf << 
INTEL_MODE_PIXEL_MULTIPLIER_SHIFT)

diff --git a/drivers/gpu/drm/gma500/psb_intel_reg.h 
b/drivers/gpu/drm/gma500/psb_intel_reg.h
index d914719..0be30e4 100644
--- a/drivers/gpu/drm/gma500/psb_intel_reg.h
+++ b/drivers/gpu/drm/gma500/psb_intel_reg.h
@@ -493,7 +493,6 @@
 #define PIPEACONF_DISABLE  0
 #define PIPEACONF_DOUBLE_WIDE  (1 << 30)
 #define PIPECONF_ACTIVE(1 << 30)
-#define I965_PIPECONF_ACTIVE   (1 << 30)
 #define PIPECONF_DSIPLL_LOCK   (1 << 29)
 #define PIPEACONF_SINGLE_WIDE  0
 #define PIPEACONF_PIPE_UNLOCKED0
diff --git a/drivers/gpu/drm/gma500/psb_irq.h b/drivers/gpu/drm/gma500/psb_irq.h
index 603045b..debb7f1 100644
--- a/drivers/gpu/drm/gma500/psb_irq.h
+++ b/drivers/gpu/drm/gma500/psb_irq.h
@@ -21,8 +21,8 @@
  *
  **/

-#ifndef _SYSIRQ_H_
-#define _SYSIRQ_H_
+#ifndef _PSB_IRQ_H_
+#define _PSB_IRQ_H_

 #include 

@@ -44,4 +44,4 @@ u32  psb_get_vblank_counter(struct drm_device *dev, int pipe);

 int mdfld_enable_te(struct drm_device *dev, int pipe);
 void mdfld_disable_te(struct drm_device *dev, int pipe);
-#endif /* _SYSIRQ_H_ */
+#endif /* _PSB_IRQ_H_ */
-- 
1.7.10.4

[PATCH 07/15] drm/gma500: Remove unnecessary function exposure

[Patrik Jakobsson]

psb_intel_crtc_gamma_set() and psb_intel_crtc_destroy() aren't used outside of
psb_intel_display.c right now so no need to expose them.

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/psb_intel_display.c |4 ++--
 drivers/gpu/drm/gma500/psb_intel_display.h |3 ---
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c 
b/drivers/gpu/drm/gma500/psb_intel_display.c
index 28c2c27..ccc1c6b 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -974,7 +974,7 @@ static int psb_intel_crtc_cursor_move(struct drm_crtc 
*crtc, int x, int y)
return 0;
 }

-void psb_intel_crtc_gamma_set(struct drm_crtc *crtc, u16 *red,
+static void psb_intel_crtc_gamma_set(struct drm_crtc *crtc, u16 *red,
 u16 *green, u16 *blue, uint32_t type, uint32_t size)
 {
struct psb_intel_crtc *psb_intel_crtc = to_psb_intel_crtc(crtc);
@@ -1131,7 +1131,7 @@ struct drm_display_mode *psb_intel_crtc_mode_get(struct 
drm_device *dev,
return mode;
 }

-void psb_intel_crtc_destroy(struct drm_crtc *crtc)
+static void psb_intel_crtc_destroy(struct drm_crtc *crtc)
 {
struct psb_intel_crtc *psb_intel_crtc = to_psb_intel_crtc(crtc);
struct gtt_range *gt;
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.h 
b/drivers/gpu/drm/gma500/psb_intel_display.h
index 535b49a..3724b97 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.h
+++ b/drivers/gpu/drm/gma500/psb_intel_display.h
@@ -21,8 +21,5 @@
 #define _INTEL_DISPLAY_H_

 bool psb_intel_pipe_has_type(struct drm_crtc *crtc, int type);
-void psb_intel_crtc_gamma_set(struct drm_crtc *crtc, u16 *red,
-u16 *green, u16 *blue, uint32_t type, uint32_t size);
-void psb_intel_crtc_destroy(struct drm_crtc *crtc);

 #endif
-- 
1.7.10.4

[PATCH 06/15] drm/gma500: Type clock limits directly into array and remove defines

[Patrik Jakobsson]

This makes it easier to read. We do the same for cdv so it becomes more
consistent as well.

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/psb_intel_display.c |   66 +---
 1 file changed, 20 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c 
b/drivers/gpu/drm/gma500/psb_intel_display.c
index b29be00..28c2c27 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -57,62 +57,36 @@ struct psb_intel_limit_t {
struct psb_intel_p2_t p2;
 };

-#define I9XX_DOT_MIN 2
-#define I9XX_DOT_MAX40
-#define I9XX_VCO_MIN   140
-#define I9XX_VCO_MAX   280
-#define I9XX_N_MIN   1
-#define I9XX_N_MAX   6
-#define I9XX_M_MIN  70
-#define I9XX_M_MAX 120
-#define I9XX_M1_MIN  8
-#define I9XX_M1_MAX 18
-#define I9XX_M2_MIN  3
-#define I9XX_M2_MAX  7
-#define I9XX_P_SDVO_DAC_MIN  5
-#define I9XX_P_SDVO_DAC_MAX 80
-#define I9XX_P_LVDS_MIN  7
-#define I9XX_P_LVDS_MAX 98
-#define I9XX_P1_MIN  1
-#define I9XX_P1_MAX  8
-#define I9XX_P2_SDVO_DAC_SLOW   10
-#define I9XX_P2_SDVO_DAC_FAST5
-#define I9XX_P2_SDVO_DAC_SLOW_LIMIT 20
-#define I9XX_P2_LVDS_SLOW   14
-#define I9XX_P2_LVDS_FAST7
-#define I9XX_P2_LVDS_SLOW_LIMIT 112000
-
 #define INTEL_LIMIT_I9XX_SDVO_DAC   0
 #define INTEL_LIMIT_I9XX_LVDS  1

 static const struct psb_intel_limit_t psb_intel_limits[] = {
{   /* INTEL_LIMIT_I9XX_SDVO_DAC */
-.dot = {.min = I9XX_DOT_MIN, .max = I9XX_DOT_MAX},
-.vco = {.min = I9XX_VCO_MIN, .max = I9XX_VCO_MAX},
-.n = {.min = I9XX_N_MIN, .max = I9XX_N_MAX},
-.m = {.min = I9XX_M_MIN, .max = I9XX_M_MAX},
-.m1 = {.min = I9XX_M1_MIN, .max = I9XX_M1_MAX},
-.m2 = {.min = I9XX_M2_MIN, .max = I9XX_M2_MAX},
-.p = {.min = I9XX_P_SDVO_DAC_MIN, .max = I9XX_P_SDVO_DAC_MAX},
-.p1 = {.min = I9XX_P1_MIN, .max = I9XX_P1_MAX},
-.p2 = {.dot_limit = I9XX_P2_SDVO_DAC_SLOW_LIMIT,
-   .p2_slow = I9XX_P2_SDVO_DAC_SLOW, .p2_fast =
-   I9XX_P2_SDVO_DAC_FAST},
+.dot = {.min = 2, .max = 40},
+.vco = {.min = 140, .max = 280},
+.n = {.min = 1, .max = 6},
+.m = {.min = 70, .max = 120},
+.m1 = {.min = 8, .max = 18},
+.m2 = {.min = 3, .max = 7},
+.p = {.min = 5, .max = 80},
+.p1 = {.min = 1, .max = 8},
+.p2 = {.dot_limit = 20,
+   .p2_slow = 10, .p2_fast = 5},
 },
{   /* INTEL_LIMIT_I9XX_LVDS */
-.dot = {.min = I9XX_DOT_MIN, .max = I9XX_DOT_MAX},
-.vco = {.min = I9XX_VCO_MIN, .max = I9XX_VCO_MAX},
-.n = {.min = I9XX_N_MIN, .max = I9XX_N_MAX},
-.m = {.min = I9XX_M_MIN, .max = I9XX_M_MAX},
-.m1 = {.min = I9XX_M1_MIN, .max = I9XX_M1_MAX},
-.m2 = {.min = I9XX_M2_MIN, .max = I9XX_M2_MAX},
-.p = {.min = I9XX_P_LVDS_MIN, .max = I9XX_P_LVDS_MAX},
-.p1 = {.min = I9XX_P1_MIN, .max = I9XX_P1_MAX},
+.dot = {.min = 2, .max = 40},
+.vco = {.min = 140, .max = 280},
+.n = {.min = 1, .max = 6},
+.m = {.min = 70, .max = 120},
+.m1 = {.min = 8, .max = 18},
+.m2 = {.min = 3, .max = 7},
+.p = {.min = 7, .max = 98},
+.p1 = {.min = 1, .max = 8},
 /* The single-channel range is 25-112Mhz, and dual-channel
  * is 80-224Mhz.  Prefer single channel as much as possible.
  */
-.p2 = {.dot_limit = I9XX_P2_LVDS_SLOW_LIMIT,
-   .p2_slow = I9XX_P2_LVDS_SLOW, .p2_fast = I9XX_P2_LVDS_FAST},
+.p2 = {.dot_limit = 112000,
+   .p2_slow = 14, .p2_fast = 7},
 },
 };

-- 
1.7.10.4

[PATCH 05/15] drm/gma500: Calculate clock in one function instead of three identical

[Patrik Jakobsson]

i9xx_clock() and i8xx_clock() did the same calc and psb_intel_clock() just
called i9xx_clock() so just move it all into psb_intel_clock().

The same calculation is duplicated in cdv_intel_display.c as well so maybe we
can share it later on.

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/psb_intel_display.c |   28 +---
 1 file changed, 5 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c 
b/drivers/gpu/drm/gma500/psb_intel_display.c
index 414df48..b29be00 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -127,19 +127,7 @@ static const struct psb_intel_limit_t 
*psb_intel_limit(struct drm_crtc *crtc)
return limit;
 }

-/** Derive the pixel clock for the given refclk and divisors for 8xx chips. */
-
-static void i8xx_clock(int refclk, struct psb_intel_clock_t *clock)
-{
-   clock->m = 5 * (clock->m1 + 2) + (clock->m2 + 2);
-   clock->p = clock->p1 * clock->p2;
-   clock->vco = refclk * clock->m / (clock->n + 2);
-   clock->dot = clock->vco / clock->p;
-}
-
-/** Derive the pixel clock for the given refclk and divisors for 9xx chips. */
-
-static void i9xx_clock(int refclk, struct psb_intel_clock_t *clock)
+static void psb_intel_clock(int refclk, struct psb_intel_clock_t *clock)
 {
clock->m = 5 * (clock->m1 + 2) + (clock->m2 + 2);
clock->p = clock->p1 * clock->p2;
@@ -147,12 +135,6 @@ static void i9xx_clock(int refclk, struct 
psb_intel_clock_t *clock)
clock->dot = clock->vco / clock->p;
 }

-static void psb_intel_clock(struct drm_device *dev, int refclk,
-   struct psb_intel_clock_t *clock)
-{
-   return i9xx_clock(refclk, clock);
-}
-
 /**
  * Returns whether any output on the specified pipe is of the specified type
  */
@@ -258,7 +240,7 @@ static bool psb_intel_find_best_PLL(struct drm_crtc *crtc, 
int target,
 clock.p1++) {
int this_err;

-   psb_intel_clock(dev, refclk, &clock);
+   psb_intel_clock(refclk, &clock);

if (!psb_intel_PLL_is_valid
(crtc, &clock))
@@ -1099,9 +1081,9 @@ static int psb_intel_crtc_clock_get(struct drm_device 
*dev,
if ((dpll & PLL_REF_INPUT_MASK) ==
PLLB_REF_INPUT_SPREADSPECTRUMIN) {
/* XXX: might not be 66MHz */
-   i8xx_clock(66000, &clock);
+   psb_intel_clock(66000, &clock);
} else
-   i8xx_clock(48000, &clock);
+   psb_intel_clock(48000, &clock);
} else {
if (dpll & PLL_P1_DIVIDE_BY_TWO)
clock.p1 = 2;
@@ -1116,7 +1098,7 @@ static int psb_intel_crtc_clock_get(struct drm_device 
*dev,
else
clock.p2 = 2;

-   i8xx_clock(48000, &clock);
+   psb_intel_clock(48000, &clock);
}

/* XXX: It would be nice to validate the clocks, but we can't reuse
-- 
1.7.10.4

[PATCH 04/15] drm/gma500: Remove unused i8xx clock limits

[Patrik Jakobsson]

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/psb_intel_display.c |   54 ++--
 1 file changed, 2 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c 
b/drivers/gpu/drm/gma500/psb_intel_display.c
index 9edb190..414df48 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -57,30 +57,6 @@ struct psb_intel_limit_t {
struct psb_intel_p2_t p2;
 };

-#define I8XX_DOT_MIN 25000
-#define I8XX_DOT_MAX35
-#define I8XX_VCO_MIN93
-#define I8XX_VCO_MAX   140
-#define I8XX_N_MIN   3
-#define I8XX_N_MAX  16
-#define I8XX_M_MIN  96
-#define I8XX_M_MAX 140
-#define I8XX_M1_MIN 18
-#define I8XX_M1_MAX 26
-#define I8XX_M2_MIN  6
-#define I8XX_M2_MAX 16
-#define I8XX_P_MIN   4
-#define I8XX_P_MAX 128
-#define I8XX_P1_MIN  2
-#define I8XX_P1_MAX 33
-#define I8XX_P1_LVDS_MIN 1
-#define I8XX_P1_LVDS_MAX 6
-#define I8XX_P2_SLOW 4
-#define I8XX_P2_FAST 2
-#define I8XX_P2_LVDS_SLOW14
-#define I8XX_P2_LVDS_FAST14/* No fast option */
-#define I8XX_P2_SLOW_LIMIT  165000
-
 #define I9XX_DOT_MIN 2
 #define I9XX_DOT_MAX40
 #define I9XX_VCO_MIN   140
@@ -106,36 +82,10 @@ struct psb_intel_limit_t {
 #define I9XX_P2_LVDS_FAST7
 #define I9XX_P2_LVDS_SLOW_LIMIT 112000

-#define INTEL_LIMIT_I8XX_DVO_DAC0
-#define INTEL_LIMIT_I8XX_LVDS  1
-#define INTEL_LIMIT_I9XX_SDVO_DAC   2
-#define INTEL_LIMIT_I9XX_LVDS  3
+#define INTEL_LIMIT_I9XX_SDVO_DAC   0
+#define INTEL_LIMIT_I9XX_LVDS  1

 static const struct psb_intel_limit_t psb_intel_limits[] = {
-   {   /* INTEL_LIMIT_I8XX_DVO_DAC */
-.dot = {.min = I8XX_DOT_MIN, .max = I8XX_DOT_MAX},
-.vco = {.min = I8XX_VCO_MIN, .max = I8XX_VCO_MAX},
-.n = {.min = I8XX_N_MIN, .max = I8XX_N_MAX},
-.m = {.min = I8XX_M_MIN, .max = I8XX_M_MAX},
-.m1 = {.min = I8XX_M1_MIN, .max = I8XX_M1_MAX},
-.m2 = {.min = I8XX_M2_MIN, .max = I8XX_M2_MAX},
-.p = {.min = I8XX_P_MIN, .max = I8XX_P_MAX},
-.p1 = {.min = I8XX_P1_MIN, .max = I8XX_P1_MAX},
-.p2 = {.dot_limit = I8XX_P2_SLOW_LIMIT,
-   .p2_slow = I8XX_P2_SLOW, .p2_fast = I8XX_P2_FAST},
-},
-   {   /* INTEL_LIMIT_I8XX_LVDS */
-.dot = {.min = I8XX_DOT_MIN, .max = I8XX_DOT_MAX},
-.vco = {.min = I8XX_VCO_MIN, .max = I8XX_VCO_MAX},
-.n = {.min = I8XX_N_MIN, .max = I8XX_N_MAX},
-.m = {.min = I8XX_M_MIN, .max = I8XX_M_MAX},
-.m1 = {.min = I8XX_M1_MIN, .max = I8XX_M1_MAX},
-.m2 = {.min = I8XX_M2_MIN, .max = I8XX_M2_MAX},
-.p = {.min = I8XX_P_MIN, .max = I8XX_P_MAX},
-.p1 = {.min = I8XX_P1_LVDS_MIN, .max = I8XX_P1_LVDS_MAX},
-.p2 = {.dot_limit = I8XX_P2_SLOW_LIMIT,
-   .p2_slow = I8XX_P2_LVDS_SLOW, .p2_fast = I8XX_P2_LVDS_FAST},
-},
{   /* INTEL_LIMIT_I9XX_SDVO_DAC */
 .dot = {.min = I9XX_DOT_MIN, .max = I9XX_DOT_MAX},
 .vco = {.min = I9XX_VCO_MIN, .max = I9XX_VCO_MAX},
-- 
1.7.10.4

[PATCH 03/15] gma500: medfield: Fix possible NULL pointer dereference

[Patrik Jakobsson]

From: Syam Sidhardhan 

The use of pointer sender should be after the NULL check.

Signed-off-by: Syam Sidhardhan 
Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/mdfld_dsi_output.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c 
b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
index 2d4ab48..3abf831 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
@@ -92,8 +92,8 @@ void mdfld_dsi_brightness_init(struct mdfld_dsi_config 
*dsi_config, int pipe)
 {
struct mdfld_dsi_pkg_sender *sender =
mdfld_dsi_get_pkg_sender(dsi_config);
-   struct drm_device *dev = sender->dev;
-   struct drm_psb_private *dev_priv = dev->dev_private;
+   struct drm_device *dev;
+   struct drm_psb_private *dev_priv;
u32 gen_ctrl_val;

if (!sender) {
@@ -101,6 +101,9 @@ void mdfld_dsi_brightness_init(struct mdfld_dsi_config 
*dsi_config, int pipe)
return;
}

+   dev = sender->dev;
+   dev_priv = dev->dev_private;
+
/* Set default display backlight value to 85% (0xd8)*/
mdfld_dsi_send_mcs_short(sender, write_display_brightness, 0xd8, 1,
true);
-- 
1.7.10.4

[PATCH 02/15] drivers: gpu: drm: gma500: Replaced calls kzalloc & memcpy with kmemdup

[Patrik Jakobsson]

From: Alexandru Gheorghiu 

Replaced calls kzalloc followed by memcpy with call to kmemdup.
Patch found using coccinelle.

Signed-off-by: Alexandru Gheorghiu 
Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/intel_bios.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/intel_bios.c 
b/drivers/gpu/drm/gma500/intel_bios.c
index 403fffb..d349734 100644
--- a/drivers/gpu/drm/gma500/intel_bios.c
+++ b/drivers/gpu/drm/gma500/intel_bios.c
@@ -218,12 +218,11 @@ static void parse_backlight_data(struct drm_psb_private 
*dev_priv,
bl_start = find_section(bdb, BDB_LVDS_BACKLIGHT);
vbt_lvds_bl = (struct bdb_lvds_backlight *)(bl_start + 1) + p_type;

-   lvds_bl = kzalloc(sizeof(*vbt_lvds_bl), GFP_KERNEL);
+   lvds_bl = kmemdup(vbt_lvds_bl, sizeof(*vbt_lvds_bl), GFP_KERNEL);
if (!lvds_bl) {
dev_err(dev_priv->dev->dev, "out of memory for backlight 
data\n");
return;
}
-   memcpy(lvds_bl, vbt_lvds_bl, sizeof(*vbt_lvds_bl));
dev_priv->lvds_bl = lvds_bl;
 }

-- 
1.7.10.4

[PATCH 01/15] gma500: remove unused drm_psb_no_fb

[Patrik Jakobsson]

From: Wang YanQing 

commit f9f23a77f07506a32d9dc1d925bf85c0e7507b66(gma500: remove no_fb bits)
remove all the drm_psb_no_fb relations code in gma500 except this line code,
so remove it also.

Signed-off-by: Wang YanQing 
Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/psb_drv.h |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index a7fd6c4..6053b8a 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -876,7 +876,6 @@ extern const struct psb_ops cdv_chip_ops;
 #define PSB_D_MSVDX   (1 << 9)
 #define PSB_D_TOPAZ   (1 << 10)

-extern int drm_psb_no_fb;
 extern int drm_idle_check_interval;

 /*
-- 
1.7.10.4

[PATCH 00/15] drm/gma500: Requesting review for gma500-next

[Patrik Jakobsson]

This is what's in store for gma500 and to be included in drm-next. I'd greatly
appreciate review of these patches (and testing if possible). Most of them are
cleanups and the rest are fixes and features for restoring our state after
suspend / hibernate. There still seems to be issues with hibernating on
Cedarview but hopefully no regressions.

The repository can be found at:
https://github.com/patjak/drm-gma500.git gma500-next

Thanks
Patrik Jakobsson

Alexandru Gheorghiu (1):
  drivers: gpu: drm: gma500: Replaced calls kzalloc & memcpy with
kmemdup

Kero van Gelder (1):
  gma500: Make VGA and HDMI connector hotpluggable

Patrik Jakobsson (10):
  drm/gma500: Remove unused i8xx clock limits
  drm/gma500: Calculate clock in one function instead of three
identical
  drm/gma500: Type clock limits directly into array and remove defines
  drm/gma500: Remove unnecessary function exposure
  drm/gma500: Clean up various defines
  drm/gma500: Change fb name so pm-utils doesn't apply quirks
  drm/gma500: Add support for rebuilding the gtt
  drm/gma500: Activate the gtt rebuild on suspend/resume
  drm/gma500: Add hooks for hibernation
  drm/gma500: Fix hibernation problems on sdvo encoders

Syam Sidhardhan (1):
  gma500: medfield: Fix possible NULL pointer dereference

Wang YanQing (1):
  gma500: remove unused drm_psb_no_fb

Xiong Zhou (1):
  gma500:fix build failure for 3.9-rc5

 drivers/gpu/drm/gma500/Kconfig |   13 ++-
 drivers/gpu/drm/gma500/cdv_intel_crt.c |1 +
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c|1 +
 drivers/gpu/drm/gma500/framebuffer.c   |2 +-
 drivers/gpu/drm/gma500/gtt.c   |   45 ++--
 drivers/gpu/drm/gma500/gtt.h   |2 +-
 drivers/gpu/drm/gma500/intel_bios.c|3 +-
 drivers/gpu/drm/gma500/intel_bios.h|6 +-
 drivers/gpu/drm/gma500/mdfld_dsi_output.c  |7 +-
 drivers/gpu/drm/gma500/power.c |   17 +++
 drivers/gpu/drm/gma500/power.h |3 +
 drivers/gpu/drm/gma500/psb_drv.c   |3 +
 drivers/gpu/drm/gma500/psb_drv.h   |1 -
 drivers/gpu/drm/gma500/psb_intel_display.c |  154 ++--
 drivers/gpu/drm/gma500/psb_intel_display.h |3 -
 drivers/gpu/drm/gma500/psb_intel_drv.h |8 --
 drivers/gpu/drm/gma500/psb_intel_reg.h |1 -
 drivers/gpu/drm/gma500/psb_intel_sdvo.c|   34 ++
 drivers/gpu/drm/gma500/psb_irq.h   |6 +-
 19 files changed, 148 insertions(+), 162 deletions(-)

-- 
1.7.10.4

[PATCH v2] gma500:fix build failure for 3.9-rc5

[Patrik Jakobsson]

On Wed, Apr 10, 2013 at 2:37 PM, Xiong Zhou  wrote:
> From: Xiong Zhou 
>
> Last version of this patch is not clear enough and X86 duplicated.
>
> This patch fixes build failure of v3.9-rc5 and rc6.
> When config ACPI_VIDEO as m, DRM_GMA500 as y, here comes the failure.
> GMA5/600 needs acpi_video just like nouveau.
> And some tab type fix by the way.
>
> Failure message:
> drivers/built-in.o: In function `psb_driver_load':
> kernel-3.9-rc5/drivers/gpu/drm/gma500/psb_drv.c:340: \
> undefined reference to `acpi_video_register'
> make: *** [vmlinux] Error 1
>
> Signed-off-by: Xiong Zhou 
> ---
> drivers/gpu/drm/gma500/Kconfig |   13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
> index 1188f0f..1f6e2df 100644
> --- a/drivers/gpu/drm/gma500/Kconfig
> +++ b/drivers/gpu/drm/gma500/Kconfig
> @@ -2,10 +2,15 @@ config DRM_GMA500
> tristate "Intel GMA5/600 KMS Framebuffer"
> depends on DRM && PCI && X86
> select FB_CFB_COPYAREA
> -select FB_CFB_FILLRECT
> -select FB_CFB_IMAGEBLIT
> -select DRM_KMS_HELPER
> -select DRM_TTM
> +   select FB_CFB_FILLRECT
> +   select FB_CFB_IMAGEBLIT
> +   select DRM_KMS_HELPER
> +   select DRM_TTM
> +   # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915
> +   select ACPI_VIDEO if ACPI
> +   select BACKLIGHT_CLASS_DEVICE if ACPI
> +   select VIDEO_OUTPUT_CONTROL if ACPI
> +   select INPUT if ACPI
> help
>   Say yes for an experimental 2D KMS framebuffer driver for the
>   Intel GMA500 ('Poulsbo') and other Intel IMG based graphics

Your patch has been applied to:
https://github.com/patjak/drm-gma500.git gma500-next

I didn't have c97fc5f regarding the experimental dep in my tree so I had to fix
that. Will sort out the missing patch later.

Thanks
Patrik

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #40 from Alexandre Demers  ---
(In reply to comment #39)
> (In reply to comment #38)
> > How to do dpms cycle ?
> 
> On the console, just wait for the screen to blank.  In X:
> xset dpms force off
> will force a dpms cycle.

That would valid if we were able to log in X. Is there a way to do it if we are
still in the console?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/25c510dd/attachment.html>

[Bug 63396] Xorg crashes in radeon_get_pixmap_bo on exporting graph at 1200 dpi in Mathematica

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63396

--- Comment #2 from auxsvr at gmail.com ---
There might be some connection, other than the way of triggering, with bug
63393.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/e8003d1c/attachment.html>

[PATCH] drm/i915: don't check inconsistent modeset state when force-restoring

[Richard Cochran]

On Wed, Apr 10, 2013 at 02:07:24PM +0200, Daniel Vetter wrote:
> 
> It's written against drm-intel-next-queued at
> 
> http://cgit.freedesktop.org/~danvet/drm-intel
> 
> I've thought that it should apply pretty cleanly against older kernels,
> too. Apparently it conflicts a bit in intel_modeset_setup_hw_state, you
> can just do the s/intel_crtc_restore_mode/__intel_set_mode/ change
> manually.

I couldn't see right away how to fix it up, so I just compiled your
drm-intel-next-queued plus this patch. If I close the netbook's lid
and open it again, the screen is blank, no backlight, and the machine
seems to be frozen.

I think I can live with the warning.

Thanks anyhow,
Richard

[Bug 63396] Xorg crashes in radeon_get_pixmap_bo on exporting graph at 1200 dpi in Mathematica

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63396

--- Comment #1 from auxsvr at gmail.com ---
Created attachment 77766
  --> https://bugs.freedesktop.org/attachment.cgi?id=77766&action=edit
Xorg.log

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/b8ac6267/attachment.html>

[Bug 63396] New: Xorg crashes in radeon_get_pixmap_bo on exporting graph at 1200 dpi in Mathematica

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=63396

  Priority: medium
Bug ID: 63396
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Xorg crashes in radeon_get_pixmap_bo on exporting
graph at 1200 dpi in Mathematica
  Severity: major
Classification: Unclassified
OS: Linux (All)
  Reporter: auxsvr at gmail.com
  Hardware: x86 (IA32)
Status: NEW
   Version: 9.1
 Component: Drivers/DRI/r300
   Product: Mesa

Created attachment 77765
  --> https://bugs.freedesktop.org/attachment.cgi?id=77765&action=edit
Full backtrace

If I attempt to export a graph in Mathematica with high resolution (1200 dpi),
then Xorg crashes reliably. The graphics card is a radeon 9600XT.

Mesa-9.1.1
xorg-x11-server-7.6_1.13.2
xf86-video-ati-7.0.0-2.1.1
libdrm2-2.4.43
linux 3.7.10

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/e379895d/attachment.html>

[PATCH 2/2] radeon: add si tiling support v5

[j.gli...@gmail.com]

From: Jerome Glisse 

v2: Only writte tile index if flags for it is set
v3: Remove useless allow2d scanout flags
v4: Split radeon_drm.h update to its own patch
v5: update against lastest next tree for radeon

Signed-off-by: Jerome Glisse 
---
 radeon/radeon_surface.c | 658 
 radeon/radeon_surface.h |  31 +++
 2 files changed, 644 insertions(+), 45 deletions(-)

diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 5935c23..288b5e2 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -83,12 +83,14 @@ typedef int (*hw_best_surface_t)(struct 
radeon_surface_manager *surf_man,

 struct radeon_hw_info {
 /* apply to r6, eg */
-uint32_tgroup_bytes;
-uint32_tnum_banks;
-uint32_tnum_pipes;
+uint32_tgroup_bytes;
+uint32_tnum_banks;
+uint32_tnum_pipes;
 /* apply to eg */
-uint32_trow_size;
-unsignedallow_2d;
+uint32_trow_size;
+unsignedallow_2d;
+/* apply to si */
+uint32_ttile_mode_array[32];
 };

 struct radeon_surface_manager {
@@ -1000,12 +1002,403 @@ static int eg_surface_best(struct 
radeon_surface_manager *surf_man,
 /* ===
  * Southern Islands family
  */
+#define SI__GB_TILE_MODE__PIPE_CONFIG(x)(((x) >> 6) & 0x1f)
+#define SI__PIPE_CONFIG__ADDR_SURF_P2   0
+#define SI__PIPE_CONFIG__ADDR_SURF_P4_8x16  4
+#define SI__PIPE_CONFIG__ADDR_SURF_P4_16x16 5
+#define SI__PIPE_CONFIG__ADDR_SURF_P4_16x32 6
+#define SI__PIPE_CONFIG__ADDR_SURF_P4_32x32 7
+#define SI__PIPE_CONFIG__ADDR_SURF_P8_16x16_8x168
+#define SI__PIPE_CONFIG__ADDR_SURF_P8_16x32_8x169
+#define SI__PIPE_CONFIG__ADDR_SURF_P8_32x32_8x1610
+#define SI__PIPE_CONFIG__ADDR_SURF_P8_16x32_16x16   11
+#define SI__PIPE_CONFIG__ADDR_SURF_P8_32x32_16x16   12
+#define SI__PIPE_CONFIG__ADDR_SURF_P8_32x32_16x32   13
+#define SI__PIPE_CONFIG__ADDR_SURF_P8_32x64_32x32   14
+#define SI__GB_TILE_MODE__TILE_SPLIT(x) (((x) >> 11) & 0x7)
+#define SI__TILE_SPLIT__64B 0
+#define SI__TILE_SPLIT__128B1
+#define SI__TILE_SPLIT__256B2
+#define SI__TILE_SPLIT__512B3
+#define SI__TILE_SPLIT__1024B   4
+#define SI__TILE_SPLIT__2048B   5
+#define SI__TILE_SPLIT__4096B   6
+#define SI__GB_TILE_MODE__BANK_WIDTH(x) (((x) >> 14) & 0x3)
+#define SI__BANK_WIDTH__1   0
+#define SI__BANK_WIDTH__2   1
+#define SI__BANK_WIDTH__4   2
+#define SI__BANK_WIDTH__8   3
+#define SI__GB_TILE_MODE__BANK_HEIGHT(x)(((x) >> 16) & 0x3)
+#define SI__BANK_HEIGHT__1  0
+#define SI__BANK_HEIGHT__2  1
+#define SI__BANK_HEIGHT__4  2
+#define SI__BANK_HEIGHT__8  3
+#define SI__GB_TILE_MODE__MACRO_TILE_ASPECT(x)  (((x) >> 18) & 0x3)
+#define SI__MACRO_TILE_ASPECT__10
+#define SI__MACRO_TILE_ASPECT__21
+#define SI__MACRO_TILE_ASPECT__42
+#define SI__MACRO_TILE_ASPECT__83
+#define SI__GB_TILE_MODE__NUM_BANKS(x)  (((x) >> 20) & 0x3)
+#define SI__NUM_BANKS__2_BANK   0
+#define SI__NUM_BANKS__4_BANK   1
+#define SI__NUM_BANKS__8_BANK   2
+#define SI__NUM_BANKS__16_BANK  3
+
+
+static void si_gb_tile_mode(uint32_t gb_tile_mode,
+unsigned *num_pipes,
+unsigned *num_banks,
+uint32_t *macro_tile_aspect,
+uint32_t *bank_w,
+uint32_t *bank_h,
+uint32_t *tile_split)
+{
+if (num_pipes) {
+switch (SI__GB_TILE_MODE__PIPE_CONFIG(gb_tile_mode)) {
+case SI__PIPE_CONFIG__ADDR_SURF_P2:
+default:
+*num_pipes = 2;
+break;
+case SI__PIPE_CONFIG__ADDR_SURF_P4_8x16:
+case SI__PIPE_CONFIG__ADDR_SURF_P4_16x16:
+case SI__PIPE_CONFIG__ADDR_SURF_P4_16x32:
+case SI__PIPE_CONFIG__ADDR_SURF_P4_32x32:
+*num_pipes = 4;
+break;
+case SI__PIPE_CONFIG__ADDR_SURF_P8_16x16_8x16:
+case SI__PIPE_CONFIG__ADDR_SURF_P8_16x32_8x16:
+case SI__PIPE_CONFIG__ADDR_SURF_P8_32x32_8x16:
+case

[PATCH 1/2] radeon: update radeon_drm.h to kernel last API additions v2

[j.gli...@gmail.com]

From: Jerome Glisse 

v2: sync with radeon-next tree for 3.10

http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.10-wip

Signed-off-by: Jerome Glisse 
---
 include/drm/radeon_drm.h | 81 
 1 file changed, 81 insertions(+)

diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 00d66b3..86cef15 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -509,6 +509,7 @@ typedef struct {
 #define DRM_RADEON_GEM_SET_TILING  0x28
 #define DRM_RADEON_GEM_GET_TILING  0x29
 #define DRM_RADEON_GEM_BUSY0x2a
+#define DRM_RADEON_GEM_VA  0x2b

 #define DRM_IOCTL_RADEON_CP_INITDRM_IOW( DRM_COMMAND_BASE + 
DRM_RADEON_CP_INIT, drm_radeon_init_t)
 #define DRM_IOCTL_RADEON_CP_START   DRM_IO(  DRM_COMMAND_BASE + 
DRM_RADEON_CP_START)
@@ -550,6 +551,7 @@ typedef struct {
 #define DRM_IOCTL_RADEON_SET_TILINGDRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_SET_TILING, struct drm_radeon_gem_set_tiling)
 #define DRM_IOCTL_RADEON_GET_TILINGDRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_GET_TILING, struct drm_radeon_gem_get_tiling)
 #define DRM_IOCTL_RADEON_GEM_BUSY  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_BUSY, struct drm_radeon_gem_busy)
+#define DRM_IOCTL_RADEON_GEM_VADRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_VA, struct drm_radeon_gem_va)

 typedef struct drm_radeon_init {
enum {
@@ -882,8 +884,43 @@ struct drm_radeon_gem_pwrite {
uint64_t data_ptr;
 };

+#define RADEON_VA_MAP  1
+#define RADEON_VA_UNMAP2
+
+#define RADEON_VA_RESULT_OK0
+#define RADEON_VA_RESULT_ERROR 1
+#define RADEON_VA_RESULT_VA_EXIST  2
+
+#define RADEON_VM_PAGE_VALID   (1 << 0)
+#define RADEON_VM_PAGE_READABLE(1 << 1)
+#define RADEON_VM_PAGE_WRITEABLE   (1 << 2)
+#define RADEON_VM_PAGE_SYSTEM  (1 << 3)
+#define RADEON_VM_PAGE_SNOOPED (1 << 4)
+
+struct drm_radeon_gem_va {
+   uint32_thandle;
+   uint32_toperation;
+   uint32_tvm_id;
+   uint32_tflags;
+   uint64_toffset;
+};
+
 #define RADEON_CHUNK_ID_RELOCS 0x01
 #define RADEON_CHUNK_ID_IB 0x02
+#define RADEON_CHUNK_ID_FLAGS  0x03
+#define RADEON_CHUNK_ID_CONST_IB   0x04
+
+/* The first dword of RADEON_CHUNK_ID_FLAGS is a uint32 of these flags: */
+#define RADEON_CS_KEEP_TILING_FLAGS 0x01
+#define RADEON_CS_USE_VM0x02
+#define RADEON_CS_END_OF_FRAME  0x04 /* a hint from userspace which CS is 
the last one */
+/* The second dword of RADEON_CHUNK_ID_FLAGS is a uint32 that sets the ring 
type */
+#define RADEON_CS_RING_GFX  0
+#define RADEON_CS_RING_COMPUTE  1
+#define RADEON_CS_RING_DMA  2
+#define RADEON_CS_RING_UVD  3
+/* The third dword of RADEON_CHUNK_ID_FLAGS is a sint32 that sets the priority 
*/
+/* 0 = normal, + = higher priority, - = lower priority */

 struct drm_radeon_cs_chunk {
uint32_tchunk_id;
@@ -891,6 +928,8 @@ struct drm_radeon_cs_chunk {
uint64_tchunk_data;
 };

+/* drm_radeon_cs_reloc.flags */
+
 struct drm_radeon_cs_reloc {
uint32_thandle;
uint32_tread_domains;
@@ -916,6 +955,30 @@ struct drm_radeon_cs {
 #define RADEON_INFO_ACCEL_WORKING2 0x05
 #define RADEON_INFO_TILING_CONFIG  0x06
 #define RADEON_INFO_WANT_HYPERZ0x07
+#define RADEON_INFO_WANT_CMASK 0x08 /* get access to CMASK on r300 */
+#define RADEON_INFO_CLOCK_CRYSTAL_FREQ 0x09 /* clock crystal frequency */
+#define RADEON_INFO_NUM_BACKENDS   0x0a /* DB/backends for r600+ - need 
for OQ */
+#define RADEON_INFO_NUM_TILE_PIPES 0x0b /* tile pipes for r600+ */
+#define RADEON_INFO_FUSION_GART_WORKING0x0c /* fusion writes to GTT 
were broken before this */
+#define RADEON_INFO_BACKEND_MAP0x0d /* pipe to backend map, 
needed by mesa */
+/* virtual address start, va < start are reserved by the kernel */
+#define RADEON_INFO_VA_START   0x0e
+/* maximum size of ib using the virtual memory cs */
+#define RADEON_INFO_IB_VM_MAX_SIZE 0x0f
+/* max pipes - needed for compute shaders */
+#define RADEON_INFO_MAX_PIPES  0x10
+/* timestamp for GL_ARB_timer_query (OpenGL), returns the current GPU clock */
+#define RADEON_INFO_TIMESTAMP  0x11
+/* max shader engines (SE) - needed for geometry shaders, etc. */
+#define RADEON_INFO_MAX_SE 0x12
+/* max SH per SE */
+#define RADEON_INFO_MAX_SH_PER_SE  0x13
+/* fast fb access is enabled */
+#define RADEON_INFO_FASTFB_WORKING 0x14
+/* query if a RADEON_CS_RING_* submission is supported */
+#define RADEON_INFO_RING_WORKING   0x15
+/* SI tile mode array */
+#define RADEON_INFO_SI_TILE_MODE_ARRAY 0x16

 struct drm_radeon_info {
uint32_trequest;
@@ -923,4 +986,22 @@

[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62959

--- Comment #32 from Marek Olšák  ---
Attachment 77608 fixes the lockups, which suggests the DRM driver doesn't
actually flush caches when it should.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #39 from Alex Deucher  ---
(In reply to comment #38)
> How to do dpms cycle ?

On the console, just wait for the screen to blank.  In X:
xset dpms force off
will force a dpms cycle.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/ca45adc5/attachment.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #38 from Vladimir  ---
How to do dpms cycle ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/4f4eaeb4/attachment.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #37 from Alex Deucher  ---
When the display is shifted, does a dpms cycle fix it?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/6acff822/attachment.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #36 from Vladimir  ---
Created attachment 77761
  --> https://bugs.freedesktop.org/attachment.cgi?id=77761&action=edit
dmesg with 3 patches

Looks like there is none.

dmesg from boot with sshifted screen.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/61f7f9bd/attachment.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #35 from Alex Deucher  ---
Are there any "frame never updated!" messages in your dmesg with the patches
applied?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/a12de0af/attachment.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #34 from Alex Deucher  ---
(In reply to comment #33)
> btw, am I supposed to apply it against 3.9-rc5 or 3.9-rc6, or it doesn't
> matter ?

Doesn't matter.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/ac75bfba/attachment.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #33 from Vladimir  ---
Tried all three patches, still same, shifted after 3.8-ati reboot.

and same as 3.8 after cold start.

btw, am I supposed to apply it against 3.9-rc5 or 3.9-rc6, or it doesn't matter
?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/4f67565c/attachment.html>

[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=62959

--- Comment #31 from Alexandre Demers  ---
(In reply to comment #29)
> Do either of Jerome's patches help?

Applied both, ran 2 times r600.test and everything went fine. I'll test with
only one patch applied at a time later today.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] radeon: add si tiling support v5

[j . glisse]

From: Jerome Glisse 

v2: Only writte tile index if flags for it is set
v3: Remove useless allow2d scanout flags
v4: Split radeon_drm.h update to its own patch
v5: update against lastest next tree for radeon

Signed-off-by: Jerome Glisse 
---
 radeon/radeon_surface.c | 658 
 radeon/radeon_surface.h |  31 +++
 2 files changed, 644 insertions(+), 45 deletions(-)

diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
index 5935c23..288b5e2 100644
--- a/radeon/radeon_surface.c
+++ b/radeon/radeon_surface.c
@@ -83,12 +83,14 @@ typedef int (*hw_best_surface_t)(struct 
radeon_surface_manager *surf_man,
 
 struct radeon_hw_info {
 /* apply to r6, eg */
-uint32_tgroup_bytes;
-uint32_tnum_banks;
-uint32_tnum_pipes;
+uint32_tgroup_bytes;
+uint32_tnum_banks;
+uint32_tnum_pipes;
 /* apply to eg */
-uint32_trow_size;
-unsignedallow_2d;
+uint32_trow_size;
+unsignedallow_2d;
+/* apply to si */
+uint32_ttile_mode_array[32];
 };
 
 struct radeon_surface_manager {
@@ -1000,12 +1002,403 @@ static int eg_surface_best(struct 
radeon_surface_manager *surf_man,
 /* ===
  * Southern Islands family
  */
+#define SI__GB_TILE_MODE__PIPE_CONFIG(x)(((x) >> 6) & 0x1f)
+#define SI__PIPE_CONFIG__ADDR_SURF_P2   0
+#define SI__PIPE_CONFIG__ADDR_SURF_P4_8x16  4
+#define SI__PIPE_CONFIG__ADDR_SURF_P4_16x16 5
+#define SI__PIPE_CONFIG__ADDR_SURF_P4_16x32 6
+#define SI__PIPE_CONFIG__ADDR_SURF_P4_32x32 7
+#define SI__PIPE_CONFIG__ADDR_SURF_P8_16x16_8x168
+#define SI__PIPE_CONFIG__ADDR_SURF_P8_16x32_8x169
+#define SI__PIPE_CONFIG__ADDR_SURF_P8_32x32_8x1610
+#define SI__PIPE_CONFIG__ADDR_SURF_P8_16x32_16x16   11
+#define SI__PIPE_CONFIG__ADDR_SURF_P8_32x32_16x16   12
+#define SI__PIPE_CONFIG__ADDR_SURF_P8_32x32_16x32   13
+#define SI__PIPE_CONFIG__ADDR_SURF_P8_32x64_32x32   14
+#define SI__GB_TILE_MODE__TILE_SPLIT(x) (((x) >> 11) & 0x7)
+#define SI__TILE_SPLIT__64B 0
+#define SI__TILE_SPLIT__128B1
+#define SI__TILE_SPLIT__256B2
+#define SI__TILE_SPLIT__512B3
+#define SI__TILE_SPLIT__1024B   4
+#define SI__TILE_SPLIT__2048B   5
+#define SI__TILE_SPLIT__4096B   6
+#define SI__GB_TILE_MODE__BANK_WIDTH(x) (((x) >> 14) & 0x3)
+#define SI__BANK_WIDTH__1   0
+#define SI__BANK_WIDTH__2   1
+#define SI__BANK_WIDTH__4   2
+#define SI__BANK_WIDTH__8   3
+#define SI__GB_TILE_MODE__BANK_HEIGHT(x)(((x) >> 16) & 0x3)
+#define SI__BANK_HEIGHT__1  0
+#define SI__BANK_HEIGHT__2  1
+#define SI__BANK_HEIGHT__4  2
+#define SI__BANK_HEIGHT__8  3
+#define SI__GB_TILE_MODE__MACRO_TILE_ASPECT(x)  (((x) >> 18) & 0x3)
+#define SI__MACRO_TILE_ASPECT__10
+#define SI__MACRO_TILE_ASPECT__21
+#define SI__MACRO_TILE_ASPECT__42
+#define SI__MACRO_TILE_ASPECT__83
+#define SI__GB_TILE_MODE__NUM_BANKS(x)  (((x) >> 20) & 0x3)
+#define SI__NUM_BANKS__2_BANK   0
+#define SI__NUM_BANKS__4_BANK   1
+#define SI__NUM_BANKS__8_BANK   2
+#define SI__NUM_BANKS__16_BANK  3
+
+
+static void si_gb_tile_mode(uint32_t gb_tile_mode,
+unsigned *num_pipes,
+unsigned *num_banks,
+uint32_t *macro_tile_aspect,
+uint32_t *bank_w,
+uint32_t *bank_h,
+uint32_t *tile_split)
+{
+if (num_pipes) {
+switch (SI__GB_TILE_MODE__PIPE_CONFIG(gb_tile_mode)) {
+case SI__PIPE_CONFIG__ADDR_SURF_P2:
+default:
+*num_pipes = 2;
+break;
+case SI__PIPE_CONFIG__ADDR_SURF_P4_8x16:
+case SI__PIPE_CONFIG__ADDR_SURF_P4_16x16:
+case SI__PIPE_CONFIG__ADDR_SURF_P4_16x32:
+case SI__PIPE_CONFIG__ADDR_SURF_P4_32x32:
+*num_pipes = 4;
+break;
+case SI__PIPE_CONFIG__ADDR_SURF_P8_16x16_8x16:
+case SI__PIPE_CONFIG__ADDR_SURF_P8_16x32_8x16:
+case SI__PIPE_CONFIG__ADDR_SURF_P8_32x32_8x16:
+ca

[PATCH 1/2] radeon: update radeon_drm.h to kernel last API additions v2

[j . glisse]

From: Jerome Glisse 

v2: sync with radeon-next tree for 3.10

http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.10-wip

Signed-off-by: Jerome Glisse 
---
 include/drm/radeon_drm.h | 81 
 1 file changed, 81 insertions(+)

diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 00d66b3..86cef15 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -509,6 +509,7 @@ typedef struct {
 #define DRM_RADEON_GEM_SET_TILING  0x28
 #define DRM_RADEON_GEM_GET_TILING  0x29
 #define DRM_RADEON_GEM_BUSY0x2a
+#define DRM_RADEON_GEM_VA  0x2b
 
 #define DRM_IOCTL_RADEON_CP_INITDRM_IOW( DRM_COMMAND_BASE + 
DRM_RADEON_CP_INIT, drm_radeon_init_t)
 #define DRM_IOCTL_RADEON_CP_START   DRM_IO(  DRM_COMMAND_BASE + 
DRM_RADEON_CP_START)
@@ -550,6 +551,7 @@ typedef struct {
 #define DRM_IOCTL_RADEON_SET_TILINGDRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_SET_TILING, struct drm_radeon_gem_set_tiling)
 #define DRM_IOCTL_RADEON_GET_TILINGDRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_GET_TILING, struct drm_radeon_gem_get_tiling)
 #define DRM_IOCTL_RADEON_GEM_BUSY  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_BUSY, struct drm_radeon_gem_busy)
+#define DRM_IOCTL_RADEON_GEM_VADRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_VA, struct drm_radeon_gem_va)
 
 typedef struct drm_radeon_init {
enum {
@@ -882,8 +884,43 @@ struct drm_radeon_gem_pwrite {
uint64_t data_ptr;
 };
 
+#define RADEON_VA_MAP  1
+#define RADEON_VA_UNMAP2
+
+#define RADEON_VA_RESULT_OK0
+#define RADEON_VA_RESULT_ERROR 1
+#define RADEON_VA_RESULT_VA_EXIST  2
+
+#define RADEON_VM_PAGE_VALID   (1 << 0)
+#define RADEON_VM_PAGE_READABLE(1 << 1)
+#define RADEON_VM_PAGE_WRITEABLE   (1 << 2)
+#define RADEON_VM_PAGE_SYSTEM  (1 << 3)
+#define RADEON_VM_PAGE_SNOOPED (1 << 4)
+
+struct drm_radeon_gem_va {
+   uint32_thandle;
+   uint32_toperation;
+   uint32_tvm_id;
+   uint32_tflags;
+   uint64_toffset;
+};
+
 #define RADEON_CHUNK_ID_RELOCS 0x01
 #define RADEON_CHUNK_ID_IB 0x02
+#define RADEON_CHUNK_ID_FLAGS  0x03
+#define RADEON_CHUNK_ID_CONST_IB   0x04
+
+/* The first dword of RADEON_CHUNK_ID_FLAGS is a uint32 of these flags: */
+#define RADEON_CS_KEEP_TILING_FLAGS 0x01
+#define RADEON_CS_USE_VM0x02
+#define RADEON_CS_END_OF_FRAME  0x04 /* a hint from userspace which CS is 
the last one */
+/* The second dword of RADEON_CHUNK_ID_FLAGS is a uint32 that sets the ring 
type */
+#define RADEON_CS_RING_GFX  0
+#define RADEON_CS_RING_COMPUTE  1
+#define RADEON_CS_RING_DMA  2
+#define RADEON_CS_RING_UVD  3
+/* The third dword of RADEON_CHUNK_ID_FLAGS is a sint32 that sets the priority 
*/
+/* 0 = normal, + = higher priority, - = lower priority */
 
 struct drm_radeon_cs_chunk {
uint32_tchunk_id;
@@ -891,6 +928,8 @@ struct drm_radeon_cs_chunk {
uint64_tchunk_data;
 };
 
+/* drm_radeon_cs_reloc.flags */
+
 struct drm_radeon_cs_reloc {
uint32_thandle;
uint32_tread_domains;
@@ -916,6 +955,30 @@ struct drm_radeon_cs {
 #define RADEON_INFO_ACCEL_WORKING2 0x05
 #define RADEON_INFO_TILING_CONFIG  0x06
 #define RADEON_INFO_WANT_HYPERZ0x07
+#define RADEON_INFO_WANT_CMASK 0x08 /* get access to CMASK on r300 */
+#define RADEON_INFO_CLOCK_CRYSTAL_FREQ 0x09 /* clock crystal frequency */
+#define RADEON_INFO_NUM_BACKENDS   0x0a /* DB/backends for r600+ - need 
for OQ */
+#define RADEON_INFO_NUM_TILE_PIPES 0x0b /* tile pipes for r600+ */
+#define RADEON_INFO_FUSION_GART_WORKING0x0c /* fusion writes to GTT 
were broken before this */
+#define RADEON_INFO_BACKEND_MAP0x0d /* pipe to backend map, 
needed by mesa */
+/* virtual address start, va < start are reserved by the kernel */
+#define RADEON_INFO_VA_START   0x0e
+/* maximum size of ib using the virtual memory cs */
+#define RADEON_INFO_IB_VM_MAX_SIZE 0x0f
+/* max pipes - needed for compute shaders */
+#define RADEON_INFO_MAX_PIPES  0x10
+/* timestamp for GL_ARB_timer_query (OpenGL), returns the current GPU clock */
+#define RADEON_INFO_TIMESTAMP  0x11
+/* max shader engines (SE) - needed for geometry shaders, etc. */
+#define RADEON_INFO_MAX_SE 0x12
+/* max SH per SE */
+#define RADEON_INFO_MAX_SH_PER_SE  0x13
+/* fast fb access is enabled */
+#define RADEON_INFO_FASTFB_WORKING 0x14
+/* query if a RADEON_CS_RING_* submission is supported */
+#define RADEON_INFO_RING_WORKING   0x15
+/* SI tile mode array */
+#define RADEON_INFO_SI_TILE_MODE_ARRAY 0x16
 
 struct drm_radeon_info {
uint32_trequest;
@@ -923,4 +986

[PATCH] drm: cleanup: use drm_framebuffer_reference instead of a kref_get

[Archit Taneja]

drm_framebuffer_lookup() does a kref_get() for the framebuffer if it finds one
corresponding to the fb id passed to it. Use drm_framebuffer_reference() instead
for clarity since it's the function used in other places to take a reference.

Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/drm_crtc.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index dd64a06..a3b63cf 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -412,7 +412,7 @@ struct drm_framebuffer *drm_framebuffer_lookup(struct 
drm_device *dev,
mutex_lock(&dev->mode_config.fb_lock);
fb = __drm_framebuffer_lookup(dev, id);
if (fb)
-   kref_get(&fb->refcount);
+   drm_framebuffer_reference(fb);
mutex_unlock(&dev->mode_config.fb_lock);

return fb;
-- 
1.7.10.4

[PATCH] drm/i915: don't check inconsistent modeset state when force-restoring

[Daniel Vetter]

On Wed, Apr 10, 2013 at 01:59:02PM +0200, Richard Cochran wrote:
> On Tue, Apr 09, 2013 at 09:51:30PM +0200, Daniel Vetter wrote:
> > It will be only consistent once we've restored all the crtcs. Since a
> > bunch of other callers also want to just restore a single crtc, add a
> > boolean to disable checking only where it doesn't make sense.
> > 
> > Note that intel_modeset_setup_hw_state already has a call to
> > intel_modeset_check_state at the end, so we don't reduce the amount of
> > checking.
> > 
> > v2: Try harder not to create a big patch (Chris).
> 
> To what does tree does this patch apply?
> 
> Tried v3.8.6 and master d02a9a89.

It's written against drm-intel-next-queued at

http://cgit.freedesktop.org/~danvet/drm-intel

I've thought that it should apply pretty cleanly against older kernels,
too. Apparently it conflicts a bit in intel_modeset_setup_hw_state, you
can just do the s/intel_crtc_restore_mode/__intel_set_mode/ change
manually.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #32 from Alex Deucher  ---
Created attachment 77743
  --> https://bugs.freedesktop.org/attachment.cgi?id=77743&action=edit
additional fix

Try this one in addition to the previous two (apply all 3).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/76851605/attachment.html>

[PATCH] drm/i915: don't check inconsistent modeset state when force-restoring

[Richard Cochran]

On Tue, Apr 09, 2013 at 09:51:30PM +0200, Daniel Vetter wrote:
> It will be only consistent once we've restored all the crtcs. Since a
> bunch of other callers also want to just restore a single crtc, add a
> boolean to disable checking only where it doesn't make sense.
> 
> Note that intel_modeset_setup_hw_state already has a call to
> intel_modeset_check_state at the end, so we don't reduce the amount of
> checking.
> 
> v2: Try harder not to create a big patch (Chris).

To what does tree does this patch apply?

Tried v3.8.6 and master d02a9a89.

Thanks,
Richard

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #45 from Alexandre Demers  ---
(In reply to comment #44)
> Does disabling acceleration help?
> 
> Option "NoAccel" "True"
> 
> In the device section of you xorg.conf

I was able to log in, launch "xset dpms force off". My screen turned off. After
waking it up, the display was still shifted.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 57919] Visual glitches in unity with Radeon HD 7600M

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57919

--- Comment #15 from Thilo Cestonaro  ---
The first is already part of the kernel, so it's the kernel + the second patch.

Greetings
Thilo

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #44 from Alex Deucher  ---
Does disabling acceleration help?

Option "NoAccel" "True"

In the device section of you xorg.conf

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 57919] Visual glitches in unity with Radeon HD 7600M

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57919

--- Comment #14 from Thilo Cestonaro  ---
Sadly I must say, that this patch changes the behave in no way, too. :( ...

It's still flickering and showing theses glitches as in the video.

Could I add any debug output, any printks which would help to identify the
problem? 
Anything else I should test? 
Currently I'm testing on raring latest with following kernel + the two patches
mentioned in this thread.

Kernel:
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-raring.git;a=commit;h=82983bbf61f02dec860e266217f002c18a06006e

Greetings
Thilo

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #43 from Vladimir  ---
Exactly same happens here

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #42 from Alexandre Demers  ---
(In reply to comment #41)
> (In reply to comment #40)
> > (In reply to comment #39)
> > > (In reply to comment #38)
> > > > How to do dpms cycle ?
> > > 
> > > On the console, just wait for the screen to blank.  In X:
> > > xset dpms force off
> > > will force a dpms cycle.
> > 
> > That would valid if we were able to log in X. Is there a way to do it if we
> > are still in the console?
> 
> I think you can adjust the console blanking with setterm.  Can you start X
> and force a dpms cycle even if the screen is garbled?

X starts, but I'm never getting to the log screen. Once X is started, if I go
into console and come back, only my mouse pointer is being displayed correctly,
the background stays as what was in the console. I suppose something is hanging
or crashing X.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=62959

--- Comment #30 from Alexandre Demers  ---
(In reply to comment #29)
> Do either of Jerome's patches help?

Didn't have time to test them yesterday, I'll try them probably at the end of
the day.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/252a806c/attachment-0001.html>

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #41 from Alex Deucher  ---
(In reply to comment #40)
> (In reply to comment #39)
> > (In reply to comment #38)
> > > How to do dpms cycle ?
> > 
> > On the console, just wait for the screen to blank.  In X:
> > xset dpms force off
> > will force a dpms cycle.
> 
> That would valid if we were able to log in X. Is there a way to do it if we
> are still in the console?

I think you can adjust the console blanking with setterm.  Can you start X and
force a dpms cycle even if the screen is garbled?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/i915: don't check inconsistent modeset state when force-restoring

[Daniel Vetter]

It will be only consistent once we've restored all the crtcs. Since a
bunch of other callers also want to just restore a single crtc, add a
boolean to disable checking only where it doesn't make sense.

Note that intel_modeset_setup_hw_state already has a call to
intel_modeset_check_state at the end, so we don't reduce the amount of
checking.

v2: Try harder not to create a big patch (Chris).

v3: Even smaller (still Chris). Also fix a trailing space.

v4: Rebased on top of 3.9-rc6.

References: https://lkml.org/lkml/2013/3/16/60
Cc: Tomas Melin 
Cc: Richard Cochran 
Cc: Chris Wilson 
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c |   32 ++--
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b20d501..5f1eb50 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7771,9 +7771,9 @@ intel_modeset_check_state(struct drm_device *dev)
}
 }
 
-int intel_set_mode(struct drm_crtc *crtc,
-  struct drm_display_mode *mode,
-  int x, int y, struct drm_framebuffer *fb)
+static int __intel_set_mode(struct drm_crtc *crtc,
+   struct drm_display_mode *mode,
+   int x, int y, struct drm_framebuffer *fb)
 {
struct drm_device *dev = crtc->dev;
drm_i915_private_t *dev_priv = dev->dev_private;
@@ -7863,8 +7863,6 @@ done:
if (ret && crtc->enabled) {
crtc->hwmode = *saved_hwmode;
crtc->mode = *saved_mode;
-   } else {
-   intel_modeset_check_state(dev);
}
 
 out:
@@ -7872,6 +7870,20 @@ out:
return ret;
 }
 
+int intel_set_mode(struct drm_crtc *crtc,
+struct drm_display_mode *mode,
+int x, int y, struct drm_framebuffer *fb)
+{
+   int ret;
+
+   ret = __intel_set_mode(crtc, mode, x, y, fb);
+
+   if (ret == 0)
+   intel_modeset_check_state(crtc->dev);
+
+   return ret;
+}
+
 void intel_crtc_restore_mode(struct drm_crtc *crtc)
 {
intel_set_mode(crtc, &crtc->mode, crtc->x, crtc->y, crtc->fb);
@@ -9172,8 +9184,16 @@ void intel_modeset_setup_hw_state(struct drm_device *dev,
}
 
if (force_restore) {
+   /*
+* We need to use raw interfaces for restoring state to avoid
+* checking (bogus) intermediate states.
+*/
for_each_pipe(pipe) {
-   
intel_crtc_restore_mode(dev_priv->pipe_to_crtc_mapping[pipe]);
+   struct drm_crtc *crtc =
+   dev_priv->pipe_to_crtc_mapping[pipe];
+
+   __intel_set_mode(crtc, &crtc->mode, crtc->x, crtc->y,
+crtc->fb);
}
 
i915_redisable_vga(dev);
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62959] r600g (HD 6950 Cayman) fails piglit tests and hangs system

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=62959

--- Comment #29 from Alex Deucher  ---
Do either of Jerome's patches help?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/2e08e7d2/attachment.html>

Re: [Intel-gfx] [PATCH] drm/i915: don't check inconsistent modeset state when force-restoring

[Daniel Vetter]

On Wed, Apr 10, 2013 at 7:27 PM, Richard Cochran
 wrote:
> On Wed, Apr 10, 2013 at 02:07:24PM +0200, Daniel Vetter wrote:
>>
>> It's written against drm-intel-next-queued at
>>
>> http://cgit.freedesktop.org/~danvet/drm-intel
>>
>> I've thought that it should apply pretty cleanly against older kernels,
>> too. Apparently it conflicts a bit in intel_modeset_setup_hw_state, you
>> can just do the s/intel_crtc_restore_mode/__intel_set_mode/ change
>> manually.
>
> I couldn't see right away how to fix it up, so I just compiled your
> drm-intel-next-queued plus this patch. If I close the netbook's lid
> and open it again, the screen is blank, no backlight, and the machine
> seems to be frozen.
>
> I think I can live with the warning.

That patch should crash at all, so this is not expected. Can you pls
check whether plain drm-intel-nightly is broken, too?

I'll quickly port the patch (in it's latest v3 version) to 3.9-rc
kernels for you to test.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

How to manage OMAP display drivers in the future

[Tomi Valkeinen]

Hi Dave,

On 2013-03-13 10:57, Tomi Valkeinen wrote:
> Hi Dave,
> 
> I'm writing this mail to get some ideas how we should manage OMAP's
> display drivers in the future.
> 
> As a short intro, we have the following players around:
> 
> omapdss - omapdss handles the DSS (display subsystem) hardware. omapdss
> doesn't do any buffer management or expose any userspace API (except a
> few sysfs files), so it doesn't do anything by itself.
> (drivers/video/omap2/dss/)
> 
> panel drivers - Drivers for various panel models. The panel drivers use
> omapdss API to manage the video bus. (drivers/video/omap2/displays/)
> 
> omapfb - Framebuffer driver, uses omapdss to handle the HW.
> (drivers/video/omap2/omapfb/)
> 
> omap_vout - V4L2 driver for showing video, uses omapdss to handle the
> HW. (drivers/media/platform/omap/)
> 
> omapdrm - DRM driver, uses omapdss to handle the HW.
> (drivers/gpu/drm/omapdrm/)
> 
> omapdss and the panel drivers form the lowest level layer. omapfb and
> omap_vout can be used at the same time, but omapdrm must be used alone,
> without omapfb or omap_vout.
> 
> omapfb and omap_vout are not much developed anymore, even though they
> are still commonly used. Most of the development happens in omapdss,
> panel drivers and omapdrm.
> 
> So that's what we have now. In the distant future I see omapfb and
> omap_vout disappear totally, the panel drivers would be made generic
> using Common Display Framework, and omapdss and omapdrm would more or
> less be merged together. However, all that is still far away, and we
> need some plan to go forward for now.
> 
> Most pressing question is how to get OMAP display patches merged. It
> seems that there's not really an fbdev maintainer for the time being,
> and fbdev tree has been the route for omapdss, panels and omapfb in the
> past. Now that omapdrm is the new main driver for omap display, fbdev
> would be somewhat wrong in any case.
> 
> Dave, how would you feel about merging changes to all the above
> components through DRM tree? Merging all the above together would be the
> easiest way, as the changes may have dependencies to each other.
> 
> As I said, most of the development should be in omapdss, panels and
> omapdrm. There would be an occasional fix for omapfb and omap_vout, or
> small changes when omapdss changes require changes elsewhere.

Ping. Do you have any thoughts of the above?

We have a few patches for omapdrm for 3.10 that depend on omapdss
patches. I'm currently acting as a fbdev maintainer (well, more like
somebody who collects the fbdev patches that are quite surely ok), so I
can take the problematic omapdrm patches via fbdev tree with the omapdss
patches, if that's ok for you. And send the other omapdrm patches to be
merged via drm tree.

Or, I could take all the omapdrm patches via fbdev tree, if that's
better. There aren't too many of them for 3.10.

 Tomi


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130410/52857bed/attachment.pgp>

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #40 from Alexandre Demers  ---
(In reply to comment #39)
> (In reply to comment #38)
> > How to do dpms cycle ?
> 
> On the console, just wait for the screen to blank.  In X:
> xset dpms force off
> will force a dpms cycle.

That would valid if we were able to log in X. Is there a way to do it if we are
still in the console?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

[Daniel Vetter]

On Mon, Apr 08, 2013 at 01:50:26PM +0200, Daniel Vetter wrote:
> On Mon, Apr 08, 2013 at 12:39:24PM +0200, Peter Zijlstra wrote:
> > On Thu, 2013-04-04 at 18:56 +0200, Daniel Vetter wrote:
> > > Presuming I'm still following we should be able to fix this with the
> > > new sleep state TASK_DEADLOCK and a flag somewhere in the thread info
> > > (let's call it PF_GTFO for simplicity).
> > 
> > I'm reading "Get The F*ck Out" ? I like the name, except PF_flags are
> > unsuitable since they are not atomic and we'd need to set it from
> > another thread.
> 
> I think the PF_ flag is a non-starter for a different reason, too. To make
> different clases of ww_mutexes nest properly, we need to make sure that we
> don't dead/live-lock trying to wake up a task holdinga ww_mutex of class
> A, while that task is trying to acquire ww_mutexes of class B. Picture:
> 
>   task 1  task 2  task 3
>   holds lock B
>   ticket_A = acquire_start(class A)
>   ww_mutex_lock(lock A, ticket_A) busy doing something
> 
>   ticket_B = acquire_start(class B)
>   ww_mutex_lock(lock B, ticket_B)
>   -> contention with task 3
>   
>   ticket_task2 = acquire_start(class A)
>   ww_mutex_lock(lock A, ticket_task2)
>   -> contention with task 1
> 
> If we go with the PF_GTFO task flag, task 2 will set it on task 1
> (handwave locking/atomicity again here ;-). But taks 1 will only back off
> from any locks in class B. Or at least I think we should impose that
> restriction, since otherwise a ww_mutex acquire loop will leak out badly
> abstraction-wise and making nesting pretty much impossible in practice.
> 
> But if we really want nesting to work transparently, then task 1 should be
> allowed to continue taking locks from class A (after an acquire_end(class
> B) call ofc). But then it will have missed the wakeup from task 2, so task
> 2 blocks for too long and task 1 doesn't back off from further acquiring
> locks in class A.
> 
> Presuming my reasoning for the rt case isn't broken, this break deadlock
> avoidance if we sort by (rt_prio, ticket).
> 
> So I think we need to move the PF_GTFO flag to the ticket to make sure
> that task1 will notice that there's contention with one of the locks it
> holds from class A and that it better gtfo asap (i.e. back off, drop all
> currently held locks in class A and go into the slowpath).
> 
> But I still need to think the nesting case through a bit more (and draw
> some diagrams), so not sure yet. One thing I still need to ponder is how
> to best stack tickets (for tasks doing nested ww_mutex locking) and where
> all we need a pointer to relevant tickets and what kind of fun this
> entails ... I need to ponder this some more.

Ok, so I think the nesting case should all work if we have a
per-task/ticket flag to signal contention. The point I've mused over a bit
is how to get at both the flag and the corresponding task to do the
wakeup. I think for non-rt the simplest way is to store a pointer to the
ticket in the ww_mutex, and the ticket the holds both the contention flag
and a pointer to the task. Lifetime of that stuff would be protected by
the wait_lock from disappearing untimely, which should allow the
lock/unlock fastpaths to set/clear it non-atomically - only careful places
is in the contented unlock slowpath. So rough api sketch for nesting
ww_mutexes:

struct ww_class {
atomic_t next_ticket;
/* virtual lock to annotate the acquire_start/end sections. */
struct lock_class_key acquire_key;
/* lockdep class of all ww_mutexes in this class */
struct lock_class_key mutex_key;
/* for debug/tracepts */
const char *name 
};

DEFINE_WW_CLASS(name) /* ... and all the other usual magic init funcitons */

struct ww_acquire_ctx {
struct task_struct *task; /* invariant */
usinged ticket; /* invariant */
/* atomic is probably overkill, but need to review the resulting
 * code with all the barriers first. */
atomic_t contention;
}

void ww_acquire_start(struct ww_acuire_ctx *ctx, struct ww_class *class);
void ww_acquire_end(struct ww_acuire_ctx *ctx);

Originally I've thought we could store the pointer to the current acquire
ctx in task_struct (since we need that handy for PI boosting anyway), but
that makes things a bit ugly with nesting. Having a (somewhat) redundant
pointer to the acquiring taks in the ctx seemed less evil.

struct ww_mutex {
struct mutex base;
struct ww_acquire_ctx *holding_ctx;
}

I've considered whether we should try to pull clever tricks like with
lockdep keys and make the ww_class more implicit (by auto-instantiating it
somewhere and adding a pointer to it in each ww_mutex). But I think we
should not hide this complexity, but instead make it expli

[Bug 63396] Xorg crashes in radeon_get_pixmap_bo on exporting graph at 1200 dpi in Mathematica

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63396

--- Comment #2 from aux...@gmail.com ---
There might be some connection, other than the way of triggering, with bug
63393.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63396] Xorg crashes in radeon_get_pixmap_bo on exporting graph at 1200 dpi in Mathematica

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63396

--- Comment #1 from aux...@gmail.com ---
Created attachment 77766
  --> https://bugs.freedesktop.org/attachment.cgi?id=77766&action=edit
Xorg.log

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 63396] New: Xorg crashes in radeon_get_pixmap_bo on exporting graph at 1200 dpi in Mathematica

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=63396

  Priority: medium
Bug ID: 63396
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Xorg crashes in radeon_get_pixmap_bo on exporting
graph at 1200 dpi in Mathematica
  Severity: major
Classification: Unclassified
OS: Linux (All)
  Reporter: aux...@gmail.com
  Hardware: x86 (IA32)
Status: NEW
   Version: 9.1
 Component: Drivers/DRI/r300
   Product: Mesa

Created attachment 77765
  --> https://bugs.freedesktop.org/attachment.cgi?id=77765&action=edit
Full backtrace

If I attempt to export a graph in Mathematica with high resolution (1200 dpi),
then Xorg crashes reliably. The graphics card is a radeon 9600XT.

Mesa-9.1.1
xorg-x11-server-7.6_1.13.2
xf86-video-ati-7.0.0-2.1.1
libdrm2-2.4.43
linux 3.7.10

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/3] mutex: add support for reservation style locks, v2

[Daniel Vetter]

On Tue, Apr 09, 2013 at 06:28:08PM -0400, Steven Rostedt wrote:
> On Thu, Apr 04, 2013 at 06:41:02PM +0200, Peter Zijlstra wrote:
> > On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> > > The thing is now that you're not expected to hold these locks for a
> > > long
> > > time - if you need to synchronously stall while holding a lock
> > > performance
> > > will go down the gutters anyway. And since most current
> > > gpus/co-processors
> > > still can't really preempt fairness isn't that high a priority,
> > > either.
> > > So we didn't think too much about that.
> > 
> > Yeah but you're proposing a new synchronization primitive for the core
> > kernel.. all such 'fun' details need to be considered, not only those
> > few that bear on the one usecase.
> 
> Which bares the question, what other use cases are there?

Tbh I don't see any other either - but I agree with Peter and thinking
things through and making the api a bit more generic seems to help in
clarifying the semantics. Reminds me that I still need to draw a few
diagrams ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm: cleanup: use drm_framebuffer_reference instead of a kref_get

[Daniel Vetter]

On Wed, Apr 10, 2013 at 02:29:39PM +0530, Archit Taneja wrote:
> drm_framebuffer_lookup() does a kref_get() for the framebuffer if it finds one
> corresponding to the fb id passed to it. Use drm_framebuffer_reference() 
> instead
> for clarity since it's the function used in other places to take a reference.
> 
> Signed-off-by: Archit Taneja 

Reviewed-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_crtc.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index dd64a06..a3b63cf 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -412,7 +412,7 @@ struct drm_framebuffer *drm_framebuffer_lookup(struct 
> drm_device *dev,
>   mutex_lock(&dev->mode_config.fb_lock);
>   fb = __drm_framebuffer_lookup(dev, id);
>   if (fb)
> - kref_get(&fb->refcount);
> + drm_framebuffer_reference(fb);
>   mutex_unlock(&dev->mode_config.fb_lock);
>  
>   return fb;
> -- 
> 1.7.10.4
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #39 from Alex Deucher  ---
(In reply to comment #38)
> How to do dpms cycle ?

On the console, just wait for the screen to blank.  In X:
xset dpms force off
will force a dpms cycle.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #38 from Vladimir  ---
How to do dpms cycle ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 15/15] gma500:fix build failure for 3.9-rc5

[Patrik Jakobsson]

From: Xiong Zhou 

Last version of this patch is not clear enough and X86 duplicated.

This patch fixes build failure of v3.9-rc5 and rc6.
When config ACPI_VIDEO as m, DRM_GMA500 as y, here comes the failure.
GMA5/600 needs acpi_video just like nouveau.
And some tab type fix by the way.

Failure message:
drivers/built-in.o: In function `psb_driver_load':
kernel-3.9-rc5/drivers/gpu/drm/gma500/psb_drv.c:340: \
undefined reference to `acpi_video_register'
make: *** [vmlinux] Error 1

Signed-off-by: Xiong Zhou 
Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/Kconfig |   13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index 42e665c..92760ff 100644
--- a/drivers/gpu/drm/gma500/Kconfig
+++ b/drivers/gpu/drm/gma500/Kconfig
@@ -2,10 +2,15 @@ config DRM_GMA500
tristate "Intel GMA5/600 KMS Framebuffer"
depends on DRM && PCI && X86 && EXPERIMENTAL
select FB_CFB_COPYAREA
-select FB_CFB_FILLRECT
-select FB_CFB_IMAGEBLIT
-select DRM_KMS_HELPER
-select DRM_TTM
+   select FB_CFB_FILLRECT
+   select FB_CFB_IMAGEBLIT
+   select DRM_KMS_HELPER
+   select DRM_TTM
+   # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915
+   select ACPI_VIDEO if ACPI
+   select BACKLIGHT_CLASS_DEVICE if ACPI
+   select VIDEO_OUTPUT_CONTROL if ACPI
+   select INPUT if ACPI
help
  Say yes for an experimental 2D KMS framebuffer driver for the
  Intel GMA500 ('Poulsbo') and other Intel IMG based graphics
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 14/15] drm/gma500: Fix hibernation problems on sdvo encoders

[Patrik Jakobsson]

The state of the SDVO chip is more difficult to save than the LVDS so we do a
full mode set on the crtc to get SDVO operational again. The SDVOB/C register is
also stored just in case we have special bits set in the future.

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/psb_intel_sdvo.c |   34 +++
 1 file changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/gma500/psb_intel_sdvo.c 
b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
index a4cc777a..cd1b407 100644
--- a/drivers/gpu/drm/gma500/psb_intel_sdvo.c
+++ b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
@@ -134,6 +134,9 @@ struct psb_intel_sdvo {
 
/* Input timings for adjusted_mode */
struct psb_intel_sdvo_dtd input_dtd;
+
+   /* Saved SDVO output states */
+   uint32_t saveSDVO; /* Can be SDVOB or SDVOC depending on sdvo_reg */
 };
 
 struct psb_intel_sdvo_connector {
@@ -1830,6 +1833,35 @@ done:
 #undef CHECK_PROPERTY
 }
 
+static void psb_intel_sdvo_save(struct drm_connector *connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct psb_intel_encoder *psb_intel_encoder =
+   psb_intel_attached_encoder(connector);
+   struct psb_intel_sdvo *sdvo =
+   to_psb_intel_sdvo(&psb_intel_encoder->base);
+
+   sdvo->saveSDVO = REG_READ(sdvo->sdvo_reg);
+}
+
+static void psb_intel_sdvo_restore(struct drm_connector *connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_encoder *encoder =
+   &psb_intel_attached_encoder(connector)->base;
+   struct psb_intel_sdvo *sdvo = to_psb_intel_sdvo(encoder);
+   struct drm_crtc *crtc = encoder->crtc;
+
+   REG_WRITE(sdvo->sdvo_reg, sdvo->saveSDVO);
+
+   /* Force dpms on upon resume */
+   psb_intel_sdvo_dpms(encoder, DRM_MODE_DPMS_ON);
+
+   /* Force a full mode set on the crtc. We're supposed to have the
+  mode_config lock already. */
+   drm_crtc_helper_set_mode(crtc, &crtc->mode, crtc->x, crtc->y, NULL);
+}
+
 static const struct drm_encoder_helper_funcs psb_intel_sdvo_helper_funcs = {
.dpms = psb_intel_sdvo_dpms,
.mode_fixup = psb_intel_sdvo_mode_fixup,
@@ -1840,6 +1872,8 @@ static const struct drm_encoder_helper_funcs 
psb_intel_sdvo_helper_funcs = {
 
 static const struct drm_connector_funcs psb_intel_sdvo_connector_funcs = {
.dpms = drm_helper_connector_dpms,
+   .save = psb_intel_sdvo_save,
+   .restore = psb_intel_sdvo_restore,
.detect = psb_intel_sdvo_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.set_property = psb_intel_sdvo_set_property,
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 13/15] drm/gma500: Add hooks for hibernation

[Patrik Jakobsson]

Currently we do whatever is done during suspend/resume but we might need some
more work for hibernation so keep them in separate functions.

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/power.c   |   15 +++
 drivers/gpu/drm/gma500/power.h   |3 +++
 drivers/gpu/drm/gma500/psb_drv.c |3 +++
 3 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/gma500/power.c b/drivers/gpu/drm/gma500/power.c
index 4c575a9..b6b135f 100644
--- a/drivers/gpu/drm/gma500/power.c
+++ b/drivers/gpu/drm/gma500/power.c
@@ -315,3 +315,18 @@ int psb_runtime_idle(struct device *dev)
else
return 1;
 }
+
+int gma_power_thaw(struct device *_dev)
+{
+   return gma_power_resume(_dev);
+}
+
+int gma_power_freeze(struct device *_dev)
+{
+   return gma_power_suspend(_dev);
+}
+
+int gma_power_restore(struct device *_dev)
+{
+   return gma_power_resume(_dev);
+}
diff --git a/drivers/gpu/drm/gma500/power.h b/drivers/gpu/drm/gma500/power.h
index 1969d2e..56d8708 100644
--- a/drivers/gpu/drm/gma500/power.h
+++ b/drivers/gpu/drm/gma500/power.h
@@ -41,6 +41,9 @@ void gma_power_uninit(struct drm_device *dev);
  */
 int gma_power_suspend(struct device *dev);
 int gma_power_resume(struct device *dev);
+int gma_power_thaw(struct device *dev);
+int gma_power_freeze(struct device *dev);
+int gma_power_restore(struct device *_dev);
 
 /*
  * These are the functions the driver should use to wrap all hw access
diff --git a/drivers/gpu/drm/gma500/psb_drv.c b/drivers/gpu/drm/gma500/psb_drv.c
index 111e3df..bddea58 100644
--- a/drivers/gpu/drm/gma500/psb_drv.c
+++ b/drivers/gpu/drm/gma500/psb_drv.c
@@ -601,6 +601,9 @@ static void psb_remove(struct pci_dev *pdev)
 static const struct dev_pm_ops psb_pm_ops = {
.resume = gma_power_resume,
.suspend = gma_power_suspend,
+   .thaw = gma_power_thaw,
+   .freeze = gma_power_freeze,
+   .restore = gma_power_restore,
.runtime_suspend = psb_runtime_suspend,
.runtime_resume = psb_runtime_resume,
.runtime_idle = psb_runtime_idle,
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 12/15] drm/gma500: Activate the gtt rebuild on suspend/resume

[Patrik Jakobsson]

This patch activates the rebuilding of the gtt. Currently we reinitialize the
gtt by inserting the stolen pages again and map the rest to our scratch page.
Then we go about restoring the needed ranges. This is a bit overkill but right
now we don't have that much to restore so better safe than sorry.

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/power.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/gma500/power.c b/drivers/gpu/drm/gma500/power.c
index 889b854..4c575a9 100644
--- a/drivers/gpu/drm/gma500/power.c
+++ b/drivers/gpu/drm/gma500/power.c
@@ -110,6 +110,8 @@ static void gma_resume_display(struct pci_dev *pdev)
PSB_WVDC32(dev_priv->pge_ctl | _PSB_PGETBL_ENABLED, PSB_PGETBL_CTL);
pci_write_config_word(pdev, PSB_GMCH_CTRL,
dev_priv->gmch_ctrl | _PSB_GMCH_ENABLED);
+
+   psb_gtt_restore(dev); /* Rebuild our GTT mappings */
dev_priv->ops->restore_regs(dev);
 }
 
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 11/15] drm/gma500: Add support for rebuilding the gtt

[Patrik Jakobsson]

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/gtt.c |   45 ++
 drivers/gpu/drm/gma500/gtt.h |2 +-
 2 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/gma500/gtt.c b/drivers/gpu/drm/gma500/gtt.c
index 04a371a..2f12faf 100644
--- a/drivers/gpu/drm/gma500/gtt.c
+++ b/drivers/gpu/drm/gma500/gtt.c
@@ -80,7 +80,8 @@ static u32 __iomem *psb_gtt_entry(struct drm_device *dev, 
struct gtt_range *r)
  * the GTT. This is protected via the gtt mutex which the caller
  * must hold.
  */
-static int psb_gtt_insert(struct drm_device *dev, struct gtt_range *r)
+static int psb_gtt_insert(struct drm_device *dev, struct gtt_range *r,
+ int resume)
 {
u32 __iomem *gtt_slot;
u32 pte;
@@ -97,8 +98,10 @@ static int psb_gtt_insert(struct drm_device *dev, struct 
gtt_range *r)
gtt_slot = psb_gtt_entry(dev, r);
pages = r->pages;
 
-   /* Make sure changes are visible to the GPU */
-   set_pages_array_wc(pages, r->npage);
+   if (!resume) {
+   /* Make sure changes are visible to the GPU */
+   set_pages_array_wc(pages, r->npage);
+   }
 
/* Write our page entries into the GTT itself */
for (i = r->roll; i < r->npage; i++) {
@@ -269,7 +272,7 @@ int psb_gtt_pin(struct gtt_range *gt)
ret = psb_gtt_attach_pages(gt);
if (ret < 0)
goto out;
-   ret = psb_gtt_insert(dev, gt);
+   ret = psb_gtt_insert(dev, gt, 0);
if (ret < 0) {
psb_gtt_detach_pages(gt);
goto out;
@@ -421,9 +424,11 @@ int psb_gtt_init(struct drm_device *dev, int resume)
int ret = 0;
uint32_t pte;
 
-   mutex_init(&dev_priv->gtt_mutex);
+   if (!resume) {
+   mutex_init(&dev_priv->gtt_mutex);
+   psb_gtt_alloc(dev);
+   }
 
-   psb_gtt_alloc(dev);
pg = &dev_priv->gtt;
 
/* Enable the GTT */
@@ -505,7 +510,8 @@ int psb_gtt_init(struct drm_device *dev, int resume)
/*
 *  Map the GTT and the stolen memory area
 */
-   dev_priv->gtt_map = ioremap_nocache(pg->gtt_phys_start,
+   if (!resume)
+   dev_priv->gtt_map = ioremap_nocache(pg->gtt_phys_start,
gtt_pages << PAGE_SHIFT);
if (!dev_priv->gtt_map) {
dev_err(dev->dev, "Failure to map gtt.\n");
@@ -513,7 +519,9 @@ int psb_gtt_init(struct drm_device *dev, int resume)
goto out_err;
}
 
-   dev_priv->vram_addr = ioremap_wc(dev_priv->stolen_base, stolen_size);
+   if (!resume)
+   dev_priv->vram_addr = ioremap_wc(dev_priv->stolen_base,
+stolen_size);
if (!dev_priv->vram_addr) {
dev_err(dev->dev, "Failure to map stolen base.\n");
ret = -ENOMEM;
@@ -549,3 +557,24 @@ out_err:
psb_gtt_takedown(dev);
return ret;
 }
+
+int psb_gtt_restore(struct drm_device *dev)
+{
+   struct drm_psb_private *dev_priv = dev->dev_private;
+   struct resource *r = dev_priv->gtt_mem->child;
+   struct gtt_range *range;
+
+   /* On resume, the gtt_mutex is already initialized */
+   mutex_lock(&dev_priv->gtt_mutex);
+   psb_gtt_init(dev, 1);
+
+   while (r != NULL) {
+   range = container_of(r, struct gtt_range, resource);
+   if (range->pages)
+   psb_gtt_insert(dev, range, 1);
+   r = r->sibling;
+   }
+   mutex_unlock(&dev_priv->gtt_mutex);
+
+   return 0;
+}
diff --git a/drivers/gpu/drm/gma500/gtt.h b/drivers/gpu/drm/gma500/gtt.h
index aa17423..6191d10 100644
--- a/drivers/gpu/drm/gma500/gtt.h
+++ b/drivers/gpu/drm/gma500/gtt.h
@@ -60,5 +60,5 @@ extern int psb_gtt_pin(struct gtt_range *gt);
 extern void psb_gtt_unpin(struct gtt_range *gt);
 extern void psb_gtt_roll(struct drm_device *dev,
struct gtt_range *gt, int roll);
-
+extern int psb_gtt_restore(struct drm_device *dev);
 #endif
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 10/15] drm/gma500: Change fb name so pm-utils doesn't apply quirks

[Patrik Jakobsson]

By having 'drm' and 'fb' in the fb screeninfo id, pm-utils will leave us
alone. Otherwise we'll have quirks up to our ears and resume will break.

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/framebuffer.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index 2590cac..31ac392 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -431,7 +431,7 @@ static int psbfb_create(struct psb_fbdev *fbdev,
fbdev->psb_fb_helper.fbdev = info;
 
drm_fb_helper_fill_fix(info, fb->pitches[0], fb->depth);
-   strcpy(info->fix.id, "psbfb");
+   strcpy(info->fix.id, "psbdrmfb");
 
info->flags = FBINFO_DEFAULT;
if (dev_priv->ops->accel_2d && pitch_lines > 8) /* 2D engine */
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 09/15] gma500: Make VGA and HDMI connector hotpluggable

[Patrik Jakobsson]

From: Kero van Gelder 

Both VGA and HDMI connectors are available on my Asus EeePC X101CH.
This patch will cause output to be shown on either when plugged in.
For both, it shows the leftmost 800x600, of the 1024x600 on LVDS.

Signed-off-by: Kero van Gelder 
Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/cdv_intel_crt.c  |1 +
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c |1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/gma500/cdv_intel_crt.c 
b/drivers/gpu/drm/gma500/cdv_intel_crt.c
index 8c17534..7b8386f 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_crt.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_crt.c
@@ -276,6 +276,7 @@ void cdv_intel_crt_init(struct drm_device *dev,
goto failed_connector;
 
connector = &psb_intel_connector->base;
+   connector->polled = DRM_CONNECTOR_POLL_HPD;
drm_connector_init(dev, connector,
&cdv_intel_crt_connector_funcs, DRM_MODE_CONNECTOR_VGA);
 
diff --git a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c 
b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
index e223b50..464153d 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
@@ -319,6 +319,7 @@ void cdv_hdmi_init(struct drm_device *dev,
goto err_priv;
 
connector = &psb_intel_connector->base;
+   connector->polled = DRM_CONNECTOR_POLL_HPD;
encoder = &psb_intel_encoder->base;
drm_connector_init(dev, connector,
   &cdv_hdmi_connector_funcs,
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 08/15] drm/gma500: Clean up various defines

[Patrik Jakobsson]

Remove unused defines that we'll never use and fix naming in some include guards

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/intel_bios.h|6 +++---
 drivers/gpu/drm/gma500/psb_intel_display.c |2 --
 drivers/gpu/drm/gma500/psb_intel_drv.h |8 
 drivers/gpu/drm/gma500/psb_intel_reg.h |1 -
 drivers/gpu/drm/gma500/psb_irq.h   |6 +++---
 5 files changed, 6 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/gma500/intel_bios.h 
b/drivers/gpu/drm/gma500/intel_bios.h
index c6267c9..978ae4b 100644
--- a/drivers/gpu/drm/gma500/intel_bios.h
+++ b/drivers/gpu/drm/gma500/intel_bios.h
@@ -19,8 +19,8 @@
  *
  */
 
-#ifndef _I830_BIOS_H_
-#define _I830_BIOS_H_
+#ifndef _INTEL_BIOS_H_
+#define _INTEL_BIOS_H_
 
 #include 
 #include 
@@ -618,4 +618,4 @@ extern void psb_intel_destroy_bios(struct drm_device *dev);
 #definePORT_IDPC   8
 #definePORT_IDPD   9
 
-#endif /* _I830_BIOS_H_ */
+#endif /* _INTEL_BIOS_H_ */
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c 
b/drivers/gpu/drm/gma500/psb_intel_display.c
index ccc1c6b..6e8f42b 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -50,8 +50,6 @@ struct psb_intel_p2_t {
int p2_slow, p2_fast;
 };
 
-#define INTEL_P2_NUM 2
-
 struct psb_intel_limit_t {
struct psb_intel_range_t dot, vco, n, m, m1, m2, p, p1;
struct psb_intel_p2_t p2;
diff --git a/drivers/gpu/drm/gma500/psb_intel_drv.h 
b/drivers/gpu/drm/gma500/psb_intel_drv.h
index 90f2d11..4dcae42 100644
--- a/drivers/gpu/drm/gma500/psb_intel_drv.h
+++ b/drivers/gpu/drm/gma500/psb_intel_drv.h
@@ -32,9 +32,6 @@
 /* maximum connectors per crtcs in the mode set */
 #define INTELFB_CONN_LIMIT 4
 
-#define INTEL_I2C_BUS_DVO 1
-#define INTEL_I2C_BUS_SDVO 2
-
 /* Intel Pipe Clone Bit */
 #define INTEL_HDMIB_CLONE_BIT 1
 #define INTEL_HDMIC_CLONE_BIT 2
@@ -68,11 +65,6 @@
 #define INTEL_OUTPUT_DISPLAYPORT 9
 #define INTEL_OUTPUT_EDP 10
 
-#define INTEL_DVO_CHIP_NONE 0
-#define INTEL_DVO_CHIP_LVDS 1
-#define INTEL_DVO_CHIP_TMDS 2
-#define INTEL_DVO_CHIP_TVOUT 4
-
 #define INTEL_MODE_PIXEL_MULTIPLIER_SHIFT (0x0)
 #define INTEL_MODE_PIXEL_MULTIPLIER_MASK (0xf << 
INTEL_MODE_PIXEL_MULTIPLIER_SHIFT)
 
diff --git a/drivers/gpu/drm/gma500/psb_intel_reg.h 
b/drivers/gpu/drm/gma500/psb_intel_reg.h
index d914719..0be30e4 100644
--- a/drivers/gpu/drm/gma500/psb_intel_reg.h
+++ b/drivers/gpu/drm/gma500/psb_intel_reg.h
@@ -493,7 +493,6 @@
 #define PIPEACONF_DISABLE  0
 #define PIPEACONF_DOUBLE_WIDE  (1 << 30)
 #define PIPECONF_ACTIVE(1 << 30)
-#define I965_PIPECONF_ACTIVE   (1 << 30)
 #define PIPECONF_DSIPLL_LOCK   (1 << 29)
 #define PIPEACONF_SINGLE_WIDE  0
 #define PIPEACONF_PIPE_UNLOCKED0
diff --git a/drivers/gpu/drm/gma500/psb_irq.h b/drivers/gpu/drm/gma500/psb_irq.h
index 603045b..debb7f1 100644
--- a/drivers/gpu/drm/gma500/psb_irq.h
+++ b/drivers/gpu/drm/gma500/psb_irq.h
@@ -21,8 +21,8 @@
  *
  **/
 
-#ifndef _SYSIRQ_H_
-#define _SYSIRQ_H_
+#ifndef _PSB_IRQ_H_
+#define _PSB_IRQ_H_
 
 #include 
 
@@ -44,4 +44,4 @@ u32  psb_get_vblank_counter(struct drm_device *dev, int pipe);
 
 int mdfld_enable_te(struct drm_device *dev, int pipe);
 void mdfld_disable_te(struct drm_device *dev, int pipe);
-#endif /* _SYSIRQ_H_ */
+#endif /* _PSB_IRQ_H_ */
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 07/15] drm/gma500: Remove unnecessary function exposure

[Patrik Jakobsson]

psb_intel_crtc_gamma_set() and psb_intel_crtc_destroy() aren't used outside of
psb_intel_display.c right now so no need to expose them.

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/psb_intel_display.c |4 ++--
 drivers/gpu/drm/gma500/psb_intel_display.h |3 ---
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c 
b/drivers/gpu/drm/gma500/psb_intel_display.c
index 28c2c27..ccc1c6b 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -974,7 +974,7 @@ static int psb_intel_crtc_cursor_move(struct drm_crtc 
*crtc, int x, int y)
return 0;
 }
 
-void psb_intel_crtc_gamma_set(struct drm_crtc *crtc, u16 *red,
+static void psb_intel_crtc_gamma_set(struct drm_crtc *crtc, u16 *red,
 u16 *green, u16 *blue, uint32_t type, uint32_t size)
 {
struct psb_intel_crtc *psb_intel_crtc = to_psb_intel_crtc(crtc);
@@ -1131,7 +1131,7 @@ struct drm_display_mode *psb_intel_crtc_mode_get(struct 
drm_device *dev,
return mode;
 }
 
-void psb_intel_crtc_destroy(struct drm_crtc *crtc)
+static void psb_intel_crtc_destroy(struct drm_crtc *crtc)
 {
struct psb_intel_crtc *psb_intel_crtc = to_psb_intel_crtc(crtc);
struct gtt_range *gt;
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.h 
b/drivers/gpu/drm/gma500/psb_intel_display.h
index 535b49a..3724b97 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.h
+++ b/drivers/gpu/drm/gma500/psb_intel_display.h
@@ -21,8 +21,5 @@
 #define _INTEL_DISPLAY_H_
 
 bool psb_intel_pipe_has_type(struct drm_crtc *crtc, int type);
-void psb_intel_crtc_gamma_set(struct drm_crtc *crtc, u16 *red,
-u16 *green, u16 *blue, uint32_t type, uint32_t size);
-void psb_intel_crtc_destroy(struct drm_crtc *crtc);
 
 #endif
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 06/15] drm/gma500: Type clock limits directly into array and remove defines

[Patrik Jakobsson]

This makes it easier to read. We do the same for cdv so it becomes more
consistent as well.

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/psb_intel_display.c |   66 +---
 1 file changed, 20 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c 
b/drivers/gpu/drm/gma500/psb_intel_display.c
index b29be00..28c2c27 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -57,62 +57,36 @@ struct psb_intel_limit_t {
struct psb_intel_p2_t p2;
 };
 
-#define I9XX_DOT_MIN 2
-#define I9XX_DOT_MAX40
-#define I9XX_VCO_MIN   140
-#define I9XX_VCO_MAX   280
-#define I9XX_N_MIN   1
-#define I9XX_N_MAX   6
-#define I9XX_M_MIN  70
-#define I9XX_M_MAX 120
-#define I9XX_M1_MIN  8
-#define I9XX_M1_MAX 18
-#define I9XX_M2_MIN  3
-#define I9XX_M2_MAX  7
-#define I9XX_P_SDVO_DAC_MIN  5
-#define I9XX_P_SDVO_DAC_MAX 80
-#define I9XX_P_LVDS_MIN  7
-#define I9XX_P_LVDS_MAX 98
-#define I9XX_P1_MIN  1
-#define I9XX_P1_MAX  8
-#define I9XX_P2_SDVO_DAC_SLOW   10
-#define I9XX_P2_SDVO_DAC_FAST5
-#define I9XX_P2_SDVO_DAC_SLOW_LIMIT 20
-#define I9XX_P2_LVDS_SLOW   14
-#define I9XX_P2_LVDS_FAST7
-#define I9XX_P2_LVDS_SLOW_LIMIT 112000
-
 #define INTEL_LIMIT_I9XX_SDVO_DAC   0
 #define INTEL_LIMIT_I9XX_LVDS  1
 
 static const struct psb_intel_limit_t psb_intel_limits[] = {
{   /* INTEL_LIMIT_I9XX_SDVO_DAC */
-.dot = {.min = I9XX_DOT_MIN, .max = I9XX_DOT_MAX},
-.vco = {.min = I9XX_VCO_MIN, .max = I9XX_VCO_MAX},
-.n = {.min = I9XX_N_MIN, .max = I9XX_N_MAX},
-.m = {.min = I9XX_M_MIN, .max = I9XX_M_MAX},
-.m1 = {.min = I9XX_M1_MIN, .max = I9XX_M1_MAX},
-.m2 = {.min = I9XX_M2_MIN, .max = I9XX_M2_MAX},
-.p = {.min = I9XX_P_SDVO_DAC_MIN, .max = I9XX_P_SDVO_DAC_MAX},
-.p1 = {.min = I9XX_P1_MIN, .max = I9XX_P1_MAX},
-.p2 = {.dot_limit = I9XX_P2_SDVO_DAC_SLOW_LIMIT,
-   .p2_slow = I9XX_P2_SDVO_DAC_SLOW, .p2_fast =
-   I9XX_P2_SDVO_DAC_FAST},
+.dot = {.min = 2, .max = 40},
+.vco = {.min = 140, .max = 280},
+.n = {.min = 1, .max = 6},
+.m = {.min = 70, .max = 120},
+.m1 = {.min = 8, .max = 18},
+.m2 = {.min = 3, .max = 7},
+.p = {.min = 5, .max = 80},
+.p1 = {.min = 1, .max = 8},
+.p2 = {.dot_limit = 20,
+   .p2_slow = 10, .p2_fast = 5},
 },
{   /* INTEL_LIMIT_I9XX_LVDS */
-.dot = {.min = I9XX_DOT_MIN, .max = I9XX_DOT_MAX},
-.vco = {.min = I9XX_VCO_MIN, .max = I9XX_VCO_MAX},
-.n = {.min = I9XX_N_MIN, .max = I9XX_N_MAX},
-.m = {.min = I9XX_M_MIN, .max = I9XX_M_MAX},
-.m1 = {.min = I9XX_M1_MIN, .max = I9XX_M1_MAX},
-.m2 = {.min = I9XX_M2_MIN, .max = I9XX_M2_MAX},
-.p = {.min = I9XX_P_LVDS_MIN, .max = I9XX_P_LVDS_MAX},
-.p1 = {.min = I9XX_P1_MIN, .max = I9XX_P1_MAX},
+.dot = {.min = 2, .max = 40},
+.vco = {.min = 140, .max = 280},
+.n = {.min = 1, .max = 6},
+.m = {.min = 70, .max = 120},
+.m1 = {.min = 8, .max = 18},
+.m2 = {.min = 3, .max = 7},
+.p = {.min = 7, .max = 98},
+.p1 = {.min = 1, .max = 8},
 /* The single-channel range is 25-112Mhz, and dual-channel
  * is 80-224Mhz.  Prefer single channel as much as possible.
  */
-.p2 = {.dot_limit = I9XX_P2_LVDS_SLOW_LIMIT,
-   .p2_slow = I9XX_P2_LVDS_SLOW, .p2_fast = I9XX_P2_LVDS_FAST},
+.p2 = {.dot_limit = 112000,
+   .p2_slow = 14, .p2_fast = 7},
 },
 };
 
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/prime: keep a reference from the handle to exported dma-buf (v2.1)

[Dave Airlie]

Currently we have a problem with this:
1. i915: create gem object
2. i915: export gem object to prime
3. radeon: import gem object
4. close prime fd
5. radeon: unref object
6. i915: unref object

i915 has an imported object reference in its file priv, that isn't
cleaned up properly until fd close. The reference gets added at step 2,
but at step 6 we don't have enough info to clean it up.

The solution is to take a reference on the dma-buf when we export it,
and drop the reference when the gem handle goes away.

So when we export a dma_buf from a gem object, we keep track of it
with the handle, we take a reference to the dma_buf. When we close
the handle (i.e. userspace is finished with the buffer), we drop
the reference to the dma_buf, and it gets collected.

This patch isn't meant to fix any other problem or bikesheds, and it doesn't
fix any races with other scenarios.

v1.1: move export symbol line back up.

v2: okay I had to do a bit more, as the first patch showed a leak
on one of my tests, that I found using the dma-buf debugfs support,
the problem case is exporting a buffer twice with the same handle,
we'd add another export handle for it unnecessarily, however
we now fail if we try to export the same object with a different gem handle,
however I'm not sure if that is a case I want to support, and I've
gotten the code to WARN_ON if we hit something like that.

v2.1: rebase this patch, write better commit msg.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_gem.c   |  2 +-
 drivers/gpu/drm/drm_prime.c | 94 -
 include/drm/drmP.h  |  3 +-
 3 files changed, 71 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index af779ae..f0f7a86 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -209,7 +209,7 @@ drm_gem_remove_prime_handles(struct drm_gem_object *obj, 
struct drm_file *filp)
obj->import_attach->dmabuf);
}
if (obj->export_dma_buf) {
-   drm_prime_remove_imported_buf_handle(&filp->prime,
+   drm_prime_remove_exported_buf_handle(&filp->prime,
obj->export_dma_buf);
}
 }
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 366910d..05ee250 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -157,6 +157,8 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =  
{
.vunmap = drm_gem_dmabuf_vunmap,
 };

+static int drm_prime_add_exported_buf_handle(struct drm_prime_file_private 
*prime_fpriv, struct dma_buf *dma_buf, uint32_t handle);
+
 /**
  * DOC: PRIME Helpers
  *
@@ -201,6 +203,8 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
struct drm_gem_object *obj;
void *buf;
int ret;
+   struct dma_buf *dmabuf;
+   uint32_t exp_handle;

obj = drm_gem_object_lookup(dev, file_priv, handle);
if (!obj)
@@ -209,41 +213,52 @@ int drm_gem_prime_handle_to_fd(struct drm_device *dev,
mutex_lock(&file_priv->prime.lock);
/* re-export the original imported object */
if (obj->import_attach) {
-   get_dma_buf(obj->import_attach->dmabuf);
-   *prime_fd = dma_buf_fd(obj->import_attach->dmabuf, flags);
-   drm_gem_object_unreference_unlocked(obj);
-   mutex_unlock(&file_priv->prime.lock);
-   return 0;
+   dmabuf = obj->import_attach->dmabuf;
+   goto out_have_obj;
}

if (obj->export_dma_buf) {
-   get_dma_buf(obj->export_dma_buf);
-   *prime_fd = dma_buf_fd(obj->export_dma_buf, flags);
+   dmabuf = obj->export_dma_buf;
+   goto out_have_obj;
+   }
+
+   buf = dev->driver->gem_prime_export(dev, obj, flags);
+   if (IS_ERR(buf)) {
+   /* normally the created dma-buf takes ownership of the ref,
+* but if that fails then drop the ref
+*/
drm_gem_object_unreference_unlocked(obj);
-   } else {
-   buf = dev->driver->gem_prime_export(dev, obj, flags);
-   if (IS_ERR(buf)) {
-   /* normally the created dma-buf takes ownership of the 
ref,
-* but if that fails then drop the ref
-*/
-   drm_gem_object_unreference_unlocked(obj);
-   mutex_unlock(&file_priv->prime.lock);
-   return PTR_ERR(buf);
-   }
-   obj->export_dma_buf = buf;
-   *prime_fd = dma_buf_fd(buf, flags);
+   mutex_unlock(&file_priv->prime.lock);
+   return PTR_ERR(buf);
}
+   obj->export_dma_buf = buf;
+
/* if we've exported this buffer the cheat and add it to the import list
 * so we get the correct handle back
 */
-   ret = dr

repost fix for a real prime issue

[Dave Airlie]

Please don't bikeshed this with requirements to fix problems that
are there now anyways. This is the simplest patch to fix an obvious
problem, it doesn't fix all the other problems.

I should have merged this months ago, but people keep wanting a
superpatch to fix everything.

Dave.

[PATCH 05/15] drm/gma500: Calculate clock in one function instead of three identical

[Patrik Jakobsson]

i9xx_clock() and i8xx_clock() did the same calc and psb_intel_clock() just
called i9xx_clock() so just move it all into psb_intel_clock().

The same calculation is duplicated in cdv_intel_display.c as well so maybe we
can share it later on.

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/psb_intel_display.c |   28 +---
 1 file changed, 5 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c 
b/drivers/gpu/drm/gma500/psb_intel_display.c
index 414df48..b29be00 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -127,19 +127,7 @@ static const struct psb_intel_limit_t 
*psb_intel_limit(struct drm_crtc *crtc)
return limit;
 }
 
-/** Derive the pixel clock for the given refclk and divisors for 8xx chips. */
-
-static void i8xx_clock(int refclk, struct psb_intel_clock_t *clock)
-{
-   clock->m = 5 * (clock->m1 + 2) + (clock->m2 + 2);
-   clock->p = clock->p1 * clock->p2;
-   clock->vco = refclk * clock->m / (clock->n + 2);
-   clock->dot = clock->vco / clock->p;
-}
-
-/** Derive the pixel clock for the given refclk and divisors for 9xx chips. */
-
-static void i9xx_clock(int refclk, struct psb_intel_clock_t *clock)
+static void psb_intel_clock(int refclk, struct psb_intel_clock_t *clock)
 {
clock->m = 5 * (clock->m1 + 2) + (clock->m2 + 2);
clock->p = clock->p1 * clock->p2;
@@ -147,12 +135,6 @@ static void i9xx_clock(int refclk, struct 
psb_intel_clock_t *clock)
clock->dot = clock->vco / clock->p;
 }
 
-static void psb_intel_clock(struct drm_device *dev, int refclk,
-   struct psb_intel_clock_t *clock)
-{
-   return i9xx_clock(refclk, clock);
-}
-
 /**
  * Returns whether any output on the specified pipe is of the specified type
  */
@@ -258,7 +240,7 @@ static bool psb_intel_find_best_PLL(struct drm_crtc *crtc, 
int target,
 clock.p1++) {
int this_err;
 
-   psb_intel_clock(dev, refclk, &clock);
+   psb_intel_clock(refclk, &clock);
 
if (!psb_intel_PLL_is_valid
(crtc, &clock))
@@ -1099,9 +1081,9 @@ static int psb_intel_crtc_clock_get(struct drm_device 
*dev,
if ((dpll & PLL_REF_INPUT_MASK) ==
PLLB_REF_INPUT_SPREADSPECTRUMIN) {
/* XXX: might not be 66MHz */
-   i8xx_clock(66000, &clock);
+   psb_intel_clock(66000, &clock);
} else
-   i8xx_clock(48000, &clock);
+   psb_intel_clock(48000, &clock);
} else {
if (dpll & PLL_P1_DIVIDE_BY_TWO)
clock.p1 = 2;
@@ -1116,7 +1098,7 @@ static int psb_intel_crtc_clock_get(struct drm_device 
*dev,
else
clock.p2 = 2;
 
-   i8xx_clock(48000, &clock);
+   psb_intel_clock(48000, &clock);
}
 
/* XXX: It would be nice to validate the clocks, but we can't reuse
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 04/15] drm/gma500: Remove unused i8xx clock limits

[Patrik Jakobsson]

Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/psb_intel_display.c |   54 ++--
 1 file changed, 2 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c 
b/drivers/gpu/drm/gma500/psb_intel_display.c
index 9edb190..414df48 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -57,30 +57,6 @@ struct psb_intel_limit_t {
struct psb_intel_p2_t p2;
 };
 
-#define I8XX_DOT_MIN 25000
-#define I8XX_DOT_MAX35
-#define I8XX_VCO_MIN93
-#define I8XX_VCO_MAX   140
-#define I8XX_N_MIN   3
-#define I8XX_N_MAX  16
-#define I8XX_M_MIN  96
-#define I8XX_M_MAX 140
-#define I8XX_M1_MIN 18
-#define I8XX_M1_MAX 26
-#define I8XX_M2_MIN  6
-#define I8XX_M2_MAX 16
-#define I8XX_P_MIN   4
-#define I8XX_P_MAX 128
-#define I8XX_P1_MIN  2
-#define I8XX_P1_MAX 33
-#define I8XX_P1_LVDS_MIN 1
-#define I8XX_P1_LVDS_MAX 6
-#define I8XX_P2_SLOW 4
-#define I8XX_P2_FAST 2
-#define I8XX_P2_LVDS_SLOW14
-#define I8XX_P2_LVDS_FAST14/* No fast option */
-#define I8XX_P2_SLOW_LIMIT  165000
-
 #define I9XX_DOT_MIN 2
 #define I9XX_DOT_MAX40
 #define I9XX_VCO_MIN   140
@@ -106,36 +82,10 @@ struct psb_intel_limit_t {
 #define I9XX_P2_LVDS_FAST7
 #define I9XX_P2_LVDS_SLOW_LIMIT 112000
 
-#define INTEL_LIMIT_I8XX_DVO_DAC0
-#define INTEL_LIMIT_I8XX_LVDS  1
-#define INTEL_LIMIT_I9XX_SDVO_DAC   2
-#define INTEL_LIMIT_I9XX_LVDS  3
+#define INTEL_LIMIT_I9XX_SDVO_DAC   0
+#define INTEL_LIMIT_I9XX_LVDS  1
 
 static const struct psb_intel_limit_t psb_intel_limits[] = {
-   {   /* INTEL_LIMIT_I8XX_DVO_DAC */
-.dot = {.min = I8XX_DOT_MIN, .max = I8XX_DOT_MAX},
-.vco = {.min = I8XX_VCO_MIN, .max = I8XX_VCO_MAX},
-.n = {.min = I8XX_N_MIN, .max = I8XX_N_MAX},
-.m = {.min = I8XX_M_MIN, .max = I8XX_M_MAX},
-.m1 = {.min = I8XX_M1_MIN, .max = I8XX_M1_MAX},
-.m2 = {.min = I8XX_M2_MIN, .max = I8XX_M2_MAX},
-.p = {.min = I8XX_P_MIN, .max = I8XX_P_MAX},
-.p1 = {.min = I8XX_P1_MIN, .max = I8XX_P1_MAX},
-.p2 = {.dot_limit = I8XX_P2_SLOW_LIMIT,
-   .p2_slow = I8XX_P2_SLOW, .p2_fast = I8XX_P2_FAST},
-},
-   {   /* INTEL_LIMIT_I8XX_LVDS */
-.dot = {.min = I8XX_DOT_MIN, .max = I8XX_DOT_MAX},
-.vco = {.min = I8XX_VCO_MIN, .max = I8XX_VCO_MAX},
-.n = {.min = I8XX_N_MIN, .max = I8XX_N_MAX},
-.m = {.min = I8XX_M_MIN, .max = I8XX_M_MAX},
-.m1 = {.min = I8XX_M1_MIN, .max = I8XX_M1_MAX},
-.m2 = {.min = I8XX_M2_MIN, .max = I8XX_M2_MAX},
-.p = {.min = I8XX_P_MIN, .max = I8XX_P_MAX},
-.p1 = {.min = I8XX_P1_LVDS_MIN, .max = I8XX_P1_LVDS_MAX},
-.p2 = {.dot_limit = I8XX_P2_SLOW_LIMIT,
-   .p2_slow = I8XX_P2_LVDS_SLOW, .p2_fast = I8XX_P2_LVDS_FAST},
-},
{   /* INTEL_LIMIT_I9XX_SDVO_DAC */
 .dot = {.min = I9XX_DOT_MIN, .max = I9XX_DOT_MAX},
 .vco = {.min = I9XX_VCO_MIN, .max = I9XX_VCO_MAX},
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 03/15] gma500: medfield: Fix possible NULL pointer dereference

[Patrik Jakobsson]

From: Syam Sidhardhan 

The use of pointer sender should be after the NULL check.

Signed-off-by: Syam Sidhardhan 
Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/mdfld_dsi_output.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c 
b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
index 2d4ab48..3abf831 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
@@ -92,8 +92,8 @@ void mdfld_dsi_brightness_init(struct mdfld_dsi_config 
*dsi_config, int pipe)
 {
struct mdfld_dsi_pkg_sender *sender =
mdfld_dsi_get_pkg_sender(dsi_config);
-   struct drm_device *dev = sender->dev;
-   struct drm_psb_private *dev_priv = dev->dev_private;
+   struct drm_device *dev;
+   struct drm_psb_private *dev_priv;
u32 gen_ctrl_val;
 
if (!sender) {
@@ -101,6 +101,9 @@ void mdfld_dsi_brightness_init(struct mdfld_dsi_config 
*dsi_config, int pipe)
return;
}
 
+   dev = sender->dev;
+   dev_priv = dev->dev_private;
+
/* Set default display backlight value to 85% (0xd8)*/
mdfld_dsi_send_mcs_short(sender, write_display_brightness, 0xd8, 1,
true);
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 02/15] drivers: gpu: drm: gma500: Replaced calls kzalloc & memcpy with kmemdup

[Patrik Jakobsson]

From: Alexandru Gheorghiu 

Replaced calls kzalloc followed by memcpy with call to kmemdup.
Patch found using coccinelle.

Signed-off-by: Alexandru Gheorghiu 
Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/intel_bios.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/intel_bios.c 
b/drivers/gpu/drm/gma500/intel_bios.c
index 403fffb..d349734 100644
--- a/drivers/gpu/drm/gma500/intel_bios.c
+++ b/drivers/gpu/drm/gma500/intel_bios.c
@@ -218,12 +218,11 @@ static void parse_backlight_data(struct drm_psb_private 
*dev_priv,
bl_start = find_section(bdb, BDB_LVDS_BACKLIGHT);
vbt_lvds_bl = (struct bdb_lvds_backlight *)(bl_start + 1) + p_type;
 
-   lvds_bl = kzalloc(sizeof(*vbt_lvds_bl), GFP_KERNEL);
+   lvds_bl = kmemdup(vbt_lvds_bl, sizeof(*vbt_lvds_bl), GFP_KERNEL);
if (!lvds_bl) {
dev_err(dev_priv->dev->dev, "out of memory for backlight 
data\n");
return;
}
-   memcpy(lvds_bl, vbt_lvds_bl, sizeof(*vbt_lvds_bl));
dev_priv->lvds_bl = lvds_bl;
 }
 
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 01/15] gma500: remove unused drm_psb_no_fb

[Patrik Jakobsson]

From: Wang YanQing 

commit f9f23a77f07506a32d9dc1d925bf85c0e7507b66(gma500: remove no_fb bits)
remove all the drm_psb_no_fb relations code in gma500 except this line code,
so remove it also.

Signed-off-by: Wang YanQing 
Signed-off-by: Patrik Jakobsson 
---
 drivers/gpu/drm/gma500/psb_drv.h |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index a7fd6c4..6053b8a 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -876,7 +876,6 @@ extern const struct psb_ops cdv_chip_ops;
 #define PSB_D_MSVDX   (1 << 9)
 #define PSB_D_TOPAZ   (1 << 10)
 
-extern int drm_psb_no_fb;
 extern int drm_idle_check_interval;
 
 /*
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 00/15] drm/gma500: Requesting review for gma500-next

[Patrik Jakobsson]

This is what's in store for gma500 and to be included in drm-next. I'd greatly
appreciate review of these patches (and testing if possible). Most of them are
cleanups and the rest are fixes and features for restoring our state after
suspend / hibernate. There still seems to be issues with hibernating on
Cedarview but hopefully no regressions.

The repository can be found at:
https://github.com/patjak/drm-gma500.git gma500-next

Thanks
Patrik Jakobsson

Alexandru Gheorghiu (1):
  drivers: gpu: drm: gma500: Replaced calls kzalloc & memcpy with
kmemdup

Kero van Gelder (1):
  gma500: Make VGA and HDMI connector hotpluggable

Patrik Jakobsson (10):
  drm/gma500: Remove unused i8xx clock limits
  drm/gma500: Calculate clock in one function instead of three
identical
  drm/gma500: Type clock limits directly into array and remove defines
  drm/gma500: Remove unnecessary function exposure
  drm/gma500: Clean up various defines
  drm/gma500: Change fb name so pm-utils doesn't apply quirks
  drm/gma500: Add support for rebuilding the gtt
  drm/gma500: Activate the gtt rebuild on suspend/resume
  drm/gma500: Add hooks for hibernation
  drm/gma500: Fix hibernation problems on sdvo encoders

Syam Sidhardhan (1):
  gma500: medfield: Fix possible NULL pointer dereference

Wang YanQing (1):
  gma500: remove unused drm_psb_no_fb

Xiong Zhou (1):
  gma500:fix build failure for 3.9-rc5

 drivers/gpu/drm/gma500/Kconfig |   13 ++-
 drivers/gpu/drm/gma500/cdv_intel_crt.c |1 +
 drivers/gpu/drm/gma500/cdv_intel_hdmi.c|1 +
 drivers/gpu/drm/gma500/framebuffer.c   |2 +-
 drivers/gpu/drm/gma500/gtt.c   |   45 ++--
 drivers/gpu/drm/gma500/gtt.h   |2 +-
 drivers/gpu/drm/gma500/intel_bios.c|3 +-
 drivers/gpu/drm/gma500/intel_bios.h|6 +-
 drivers/gpu/drm/gma500/mdfld_dsi_output.c  |7 +-
 drivers/gpu/drm/gma500/power.c |   17 +++
 drivers/gpu/drm/gma500/power.h |3 +
 drivers/gpu/drm/gma500/psb_drv.c   |3 +
 drivers/gpu/drm/gma500/psb_drv.h   |1 -
 drivers/gpu/drm/gma500/psb_intel_display.c |  154 ++--
 drivers/gpu/drm/gma500/psb_intel_display.h |3 -
 drivers/gpu/drm/gma500/psb_intel_drv.h |8 --
 drivers/gpu/drm/gma500/psb_intel_reg.h |1 -
 drivers/gpu/drm/gma500/psb_intel_sdvo.c|   34 ++
 drivers/gpu/drm/gma500/psb_irq.h   |6 +-
 19 files changed, 148 insertions(+), 162 deletions(-)

-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #37 from Alex Deucher  ---
When the display is shifted, does a dpms cycle fix it?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #36 from Vladimir  ---
Created attachment 77761
  --> https://bugs.freedesktop.org/attachment.cgi?id=77761&action=edit
dmesg with 3 patches

Looks like there is none.

dmesg from boot with sshifted screen.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] gma500:fix build failure for 3.9-rc5

[Patrik Jakobsson]

On Wed, Apr 10, 2013 at 2:37 PM, Xiong Zhou  wrote:
> From: Xiong Zhou 
>
> Last version of this patch is not clear enough and X86 duplicated.
>
> This patch fixes build failure of v3.9-rc5 and rc6.
> When config ACPI_VIDEO as m, DRM_GMA500 as y, here comes the failure.
> GMA5/600 needs acpi_video just like nouveau.
> And some tab type fix by the way.
>
> Failure message:
> drivers/built-in.o: In function `psb_driver_load':
> kernel-3.9-rc5/drivers/gpu/drm/gma500/psb_drv.c:340: \
> undefined reference to `acpi_video_register'
> make: *** [vmlinux] Error 1
>
> Signed-off-by: Xiong Zhou 
> ---
> drivers/gpu/drm/gma500/Kconfig |   13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
> index 1188f0f..1f6e2df 100644
> --- a/drivers/gpu/drm/gma500/Kconfig
> +++ b/drivers/gpu/drm/gma500/Kconfig
> @@ -2,10 +2,15 @@ config DRM_GMA500
> tristate "Intel GMA5/600 KMS Framebuffer"
> depends on DRM && PCI && X86
> select FB_CFB_COPYAREA
> -select FB_CFB_FILLRECT
> -select FB_CFB_IMAGEBLIT
> -select DRM_KMS_HELPER
> -select DRM_TTM
> +   select FB_CFB_FILLRECT
> +   select FB_CFB_IMAGEBLIT
> +   select DRM_KMS_HELPER
> +   select DRM_TTM
> +   # GMA500 depends on ACPI_VIDEO when ACPI is enabled, just like i915
> +   select ACPI_VIDEO if ACPI
> +   select BACKLIGHT_CLASS_DEVICE if ACPI
> +   select VIDEO_OUTPUT_CONTROL if ACPI
> +   select INPUT if ACPI
> help
>   Say yes for an experimental 2D KMS framebuffer driver for the
>   Intel GMA500 ('Poulsbo') and other Intel IMG based graphics

Your patch has been applied to:
https://github.com/patjak/drm-gma500.git gma500-next

I didn't have c97fc5f regarding the experimental dep in my tree so I had to fix
that. Will sort out the missing patch later.

Thanks
Patrik
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #35 from Alex Deucher  ---
Are there any "frame never updated!" messages in your dmesg with the patches
applied?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #34 from Alex Deucher  ---
(In reply to comment #33)
> btw, am I supposed to apply it against 3.9-rc5 or 3.9-rc6, or it doesn't
> matter ?

Doesn't matter.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 57567] 3.7 radeonfb broken on efivga screens

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=57567

--- Comment #33 from Vladimir  ---
Tried all three patches, still same, shifted after 3.8-ati reboot.

and same as 3.8 after cold start.

btw, am I supposed to apply it against 3.9-rc5 or 3.9-rc6, or it doesn't matter
?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel