[Bug 57567] 3.7 radeonfb broken on efivga screens

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

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #77602|0   |1
is obsolete||

--- Comment #29 from Alex Deucher  ---
Created attachment 77705
  --> https://bugs.freedesktop.org/attachment.cgi?id=77705=edit
possible fix

Does this patch 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/20130409/e4dba931/attachment-0001.html>

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

[Patrik Jakobsson]

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

[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).

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 |   34 +++---
 1 file changed, 27 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8809813..2959fb8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7916,9 +7916,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;
@@ -8012,8 +8012,6 @@ done:
if (ret && crtc->enabled) {
crtc->hwmode = *saved_hwmode;
crtc->mode = *saved_mode;
-   } else {
-   intel_modeset_check_state(dev);
}

 out:
@@ -8022,9 +8020,25 @@ 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, >mode, crtc->x, crtc->y, crtc->fb);
+   __intel_set_mode(crtc, >mode, crtc->x, crtc->y, crtc->fb);
+
+   intel_modeset_check_state(crtc->dev);
 }

 #undef for_each_intel_crtc_masked
@@ -9333,10 +9347,16 @@ setup_pipes:
}

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

[Bug 63279] xf86-video-savage-2.3.6 driver does not work

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

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

--- Comment #5 from Musikolo  ---
Hi Tormod,

Thanks once again for your prompt response.

When say "it doesn't work", I mean the screen is scrambled and nothing is
distinguishable. As the telling goes, a picture is worth more than a thousand
words, so please, have a look at the attached picture of the my screen.

Kindly, let me know if there is any patch that can be used to fix this issue.

Best regards,
Carlos.

-- 
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/20130409/fe77f1c3/attachment.html>

[Bug 63279] xf86-video-savage-2.3.6 driver does not work

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

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

--- Comment #4 from Musikolo  ---
Created attachment 77694
  --> https://bugs.freedesktop.org/attachment.cgi?id=77694=edit
My scrambled 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/20130409/69fa2870/attachment.html>

[PATCH 7/7] staging: drm/imx: Add support for Television Encoder (TVEv2)

[Shawn Guo]

On Mon, Apr 08, 2013 at 06:04:38PM +0200, Philipp Zabel wrote:
> This driver adds support for the Television Encoder integrated
> on i.MX53 SoCs (TVEv2).
> 
> Currently only the VGA output mode is supported, which only uses
> the TVDAC to generate RGB levels. HSYNC and VSYNC signals are
> routed directly from the IPU signal generator pins through IOMUXC.
> 
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/staging/imx-drm/Kconfig   |   7 +
>  drivers/staging/imx-drm/Makefile  |   1 +
>  drivers/staging/imx-drm/imx-tve.c | 755 
> ++
>  3 files changed, 763 insertions(+)
>  create mode 100644 drivers/staging/imx-drm/imx-tve.c

Bindings doc is missing.

Shawn

[Bug 63279] xf86-video-savage-2.3.6 driver does not work

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

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

--- Comment #3 from Tormod Volden  ---
Simply using EXA (and a 1.14 fix backported to 1.13) worked for me. Maybe more
is broken in 1.14. What exactly happens in your case? Please be more specific
than "does not work".

There is no schedule for such bug fixes, most developers do not care about
hardware which is more than a few years old. I will look closer into it
sometime in the next weeks, although no guarantees given. There seems to be
more continued use of the savage driver than I thought :)

-- 
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/20130409/49f68ecf/attachment.html>

drm/i915: new warning (regression) in 3.7.10 and 3.8.3

[Daniel Vetter]

On Tue, Apr 09, 2013 at 03:21:35PM +0200, Richard Cochran wrote:
> On Tue, Apr 09, 2013 at 02:50:03PM +0200, Daniel Vetter wrote:
> > 
> > This should be fixed with the above mentioned patch. The issue is that the
> > bios fumbles around with the output configuration behind our backs, so the
> > new paranoid modeset code in 3.7+ freaks out about the state mismatch
> > between sw and hw.
> > 
> > The patch above should detect this situation and undo any bios-induced
> > damage.
> 
> Even with the patch, I still am seeing the issue (in 3.8).

Indeed, there's still a bug there with the state checking. Can you please
test the below patch?

Thanks, Daniel

commit d206df2685801a832a728c7dca13428a6f5bf3ef
Author: Daniel Vetter 
Date:   Tue Apr 9 19:25:12 2013 +0200

drm/i915: don't check inconstent modeset state when force-restoring

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.

References: https://lkml.org/lkml/2013/3/16/60
Cc: Tomas Melin 
Cc: Richard Cochran 
Cc: stable at vger.kernel.org
Signed-off-by: Daniel Vetter 

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8809813..1e29201 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7916,9 +7916,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;
@@ -8012,8 +8012,6 @@ done:
if (ret && crtc->enabled) {
crtc->hwmode = *saved_hwmode;
crtc->mode = *saved_mode;
-   } else {
-   intel_modeset_check_state(dev);
}

 out:
@@ -8022,9 +8020,27 @@ out:
return ret;
 }

-void intel_crtc_restore_mode(struct drm_crtc *crtc)
+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,
+bool check)
 {
-   intel_set_mode(crtc, >mode, crtc->x, crtc->y, crtc->fb);
+   __intel_set_mode(crtc, >mode, crtc->x, crtc->y, crtc->fb);
+
+   if (check)
+   intel_modeset_check_state(crtc->dev);
 }

 #undef for_each_intel_crtc_masked
@@ -9336,7 +9352,7 @@ setup_pipes:
for_each_pipe(pipe) {
struct drm_crtc *crtc =
dev_priv->pipe_to_crtc_mapping[pipe];
-   intel_crtc_restore_mode(crtc);
+   intel_crtc_restore_mode(crtc, false);
}
list_for_each_entry(plane, >mode_config.plane_list, head)
intel_plane_restore(plane);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 173add1..99b9f09 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2466,7 +2466,7 @@ intel_dp_set_property(struct drm_connector *connector,

 done:
if (intel_encoder->base.crtc)
-   intel_crtc_restore_mode(intel_encoder->base.crtc);
+   intel_crtc_restore_mode(intel_encoder->base.crtc, true);

return 0;
 }
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d7bd031..d7b1094 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -540,7 +540,7 @@ struct intel_set_config {
 extern int intel_set_mode(struct drm_crtc *crtc, struct drm_display_mode *mode,
  int x, int y, struct drm_framebuffer *old_fb);
 extern void intel_modeset_disable(struct drm_device *dev);
-extern void intel_crtc_restore_mode(struct drm_crtc *crtc);
+extern void intel_crtc_restore_mode(struct drm_crtc *crtc, bool check);
 extern void intel_crtc_load_lut(struct drm_crtc *crtc);
 extern void intel_crtc_update_dpms(struct drm_crtc *crtc);
 extern void intel_encoder_destroy(struct drm_encoder *encoder);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index ee4a8da..de07bd4 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ 

Status of exporting an fbdev framebuffer with dma_buf?

[Laurent Pinchart]

Hi Tom,

On Tuesday 09 April 2013 12:21:08 Tom Cooksey wrote:
> Hi All,
> 
> Last year Laurent posted an RFC patch[i] to add support for exporting an
> fbdev framebuffer through dma_buf. Looking through the mailing list
> archives, it doesn't appear to have progressed beyond an RFC? What would be
> needed to get this merged? It would be useful for our Mali T6xx driver
> (which supports importing dma_buf buffers) to allow the GPU to draw
> directly into the framebuffer on platforms which lack a DRM/KMS driver.

The patch was pretty simple, I don't think it would take lots of efforts to 
get it to mainline. On the other hand, fbdev is a dying API, so I'm not sure 
how much energy we want to spend on upgrading it. I suppose all that would be 
needed is a developer with enough interest in the topic to fix the patch 
according to the comments.

> [i] Subject: "[RFC/PATCH] fb: Add dma-buf support", sent 20/06/2012.

-- 
Regards,

Laurent Pinchart

[PATCH] drm/radeon: add ring working query

[Christian König]

Am 09.04.2013 16:26, schrieb Alex Deucher:
> On Tue, Apr 9, 2013 at 10:13 AM, Jerome Glisse  wrote:
>> On Tue, Apr 9, 2013 at 8:44 AM, Christian K?nig  
>> wrote:
>>> From: Christian K?nig 
>>>
>>> Add new ioctl option and bumb minor version number.
>>
>> I already have the tiling patch that bump the version, but i think it's just 
>> a matter for Alex.
> I'll take care of it.

IIRC we also have another internal patch that wants to bumb the version 
number.

Alex could you start with a drm-next-3.10 branch and try to merge all 
that stuff?

Thanks,
Christian.

> Alex
>
>> Reviewed-by: Jerome Glisse 
>>
>>>
>>> Signed-off-by: Christian K?nig 
>>> ---
>>>   drivers/gpu/drm/radeon/radeon_drv.c |2 +-
>>>   drivers/gpu/drm/radeon/radeon_kms.c |   17 +
>>>   include/uapi/drm/radeon_drm.h   |2 ++
>>>   3 files changed, 20 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
>>> b/drivers/gpu/drm/radeon/radeon_drv.c
>>> index 66a7f0f..31b193b 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_drv.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
>>> @@ -73,7 +73,7 @@
>>>*   2.30.0 - fix for FMASK texturing
>>>*/
>>>   #define KMS_DRIVER_MAJOR   2
>>> -#define KMS_DRIVER_MINOR   30
>>> +#define KMS_DRIVER_MINOR   31
>>>   #define KMS_DRIVER_PATCHLEVEL  0
>>>   int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
>>>   int radeon_driver_unload_kms(struct drm_device *dev);
>>> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
>>> b/drivers/gpu/drm/radeon/radeon_kms.c
>>> index 3019759..8cb9d12 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_kms.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
>>> @@ -376,6 +376,23 @@ int radeon_info_ioctl(struct drm_device *dev, void 
>>> *data, struct drm_file *filp)
>>>  else
>>>  return -EINVAL;
>>>  break;
>>> +   case RADEON_INFO_RING_WORKING:
>>> +   switch (value) {
>>> +   case RADEON_CS_RING_GFX:
>>> +   case RADEON_CS_RING_COMPUTE:
>>> +   value = 
>>> rdev->ring[RADEON_RING_TYPE_GFX_INDEX]..ready;
>>> +   break;
>>> +   case RADEON_CS_RING_DMA:
>>> +   value = rdev->ring[R600_RING_TYPE_DMA_INDEX].ready;
>>> +   value |= 
>>> rdev->ring[CAYMAN_RING_TYPE_DMA1_INDEX].ready;
>>> +   break;
>>> +   case RADEON_CS_RING_UVD:
>>> +   value = rdev->ring[R600_RING_TYPE_UVD_INDEX].ready;
>>> +   break;
>>> +   default:
>>> +   return -EINVAL;
>>> +   }
>>> +   break;
>>>  default:
>>>  DRM_DEBUG_KMS("Invalid request %d\n", info->request);
>>>  return -EINVAL;
>>> diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm..h
>>> index cd085d1..8459415 100644
>>> --- a/include/uapi/drm/radeon_drm.h
>>> +++ b/include/uapi/drm/radeon_drm.h
>>> @@ -973,6 +973,8 @@ struct drm_radeon_cs {
>>>   #define RADEON_INFO_MAX_SE 0x12
>>>   /* max SH per SE */
>>>   #define RADEON_INFO_MAX_SH_PER_SE  0x13
>>> +/* query if a RADEON_CS_RING_* submission is supported */
>>> +#define RADEON_INFO_RING_WORKING   0x14
>>>
>>>   struct drm_radeon_info {
>>>  uint32_trequest;
>>> --
>>> 1.7.9.5
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
> On Tue, Apr 9, 2013 at 10:13 AM, Jerome Glisse  wrote:
>> On Tue, Apr 9, 2013 at 8:44 AM, Christian K?nig 
>> wrote:
>>> From: Christian K?nig 
>>>
>>> Add new ioctl option and bumb minor version number.
>>
>> I already have the tiling patch that bump the version, but i think it's just
>> a matter for Alex.
>>
>> Reviewed-by: Jerome Glisse 
>>
>>>
>>> Signed-off-by: Christian K?nig 
>>> ---
>>>   drivers/gpu/drm/radeon/radeon_drv.c |2 +-
>>>   drivers/gpu/drm/radeon/radeon_kms.c |   17 +
>>>   include/uapi/drm/radeon_drm.h   |2 ++
>>>   3 files changed, 20 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
>>> b/drivers/gpu/drm/radeon/radeon_drv.c
>>> index 66a7f0f..31b193b 100644
>>> --- a/drivers/gpu/drm/radeon/radeon_drv.c
>>> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
>>> @@ -73,7 +73,7 @@
>>>*   2.30.0 - fix for FMASK texturing
>>>*/
>>>   #define KMS_DRIVER_MAJOR   2
>>> -#define KMS_DRIVER_MINOR   30
>>> +#define KMS_DRIVER_MINOR   31
>>>   #define KMS_DRIVER_PATCHLEVEL  0
>>>   int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
>>>   int 

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

[Steven Rostedt]

On Thu, Apr 04, 2013 at 06:56:58PM +0200, Daniel Vetter wrote:
> 
> I think for starters we need to have a slightly more interesting example:
> 
> 3 threads O, M, Y: O has the oldest ww_age/ticket, Y the youngest, M
> is in between.
> 2 ww_mutexes: A, B
> 
> Y has already acquired ww_mutex A, M has already acquired ww_mutex B.
> 

Now I probably missed it in the thread somewhere, but what makes task O
the oldest and Y the youngest? Is it the actual time from when the task
was created? What about setting an age as soon as it starts the process
of grabbing one of these locks? And it keeps the age until it
successfully grabs and releases all the locks again. It wont reset if it
had to drop the locks and start over.

Or am I totally not understanding what's going on here? Which could also
be the case ;-)

-- Steve

[Bug 63279] xf86-video-savage-2.3.6 driver does not work

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

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

--- Comment #2 from Musikolo  ---
Hi Tormod,

Thanks for your prompt response and assistance.

I have tried the suggested options, but I'm still having the same issue, no
change at all.

- http://pastebin.com/yAgshj2V

Is there any other work around? When is it expected to have a fix for it?

Regards.

-- 
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/20130409/2db435c9/attachment.html>

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

[Steven Rostedt]

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?

-- Steve

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

[Steven Rostedt]

On Thu, Apr 04, 2013 at 06:38:36PM +0200, Peter Zijlstra wrote:
> On Thu, 2013-04-04 at 15:31 +0200, Daniel Vetter wrote:
> > Hm, I guess your aim with the TASK_DEADLOCK wakeup is to bound the
> > wait
> > times of older task.
> 
> No, imagine the following:
> 
> struct ww_mutex A, B;
> struct mutex C;
> 
>   task-O  task-Y  task-X
>   A
>   B
>   C
>   C
>   B
> 
> At this point O finds that Y owns B and thus we want to make Y 'yield'
> B to make allow B progress. Since Y is blocked, we'll send a wakeup.
> However Y is blocked on a different locking primitive; one that doesn't
> collaborate in the -EDEADLK scheme therefore we don't want the wakeup to
> succeed.

I'm confused to why the above is a problem. Task-X will eventually
release C, and then Y will release B and O will get to continue. Do we
have to drop them once the owner is blocked? Can't we follow the chain
like the PI code does?

-- Steve

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

[Steven Rostedt]

On Tue, Apr 02, 2013 at 06:59:14PM +0200, Peter Zijlstra wrote:
> 
> So how about we call the thing something like:
> 
>   struct ww_mutex; /* wound/wait */

Reading this I can't help but think of Elmer Fudd saying "Round Robin"
as "Wound Wobin"

-- Steve

> 
>   int mutex_wound_lock(struct ww_mutex *); /* returns -EDEADLK */
>   int mutex_wait_lock(struct ww_mutex *);  /* does not fail */
> 

[PATCH] drm/omap: Take a fb reference in omap_plane_update()

[Archit Taneja]

When userspace calls SET_PLANE ioctl, drm core takes a reference of the fb and
passes control to the update_plane op defined by the drm driver.

In omapdrm, we have a worker thread which queues framebuffers objects received
from update_plane and displays them at the appropriate time.

It is possible that the framebuffer is destoryed by userspace between the time
of calling the ioctl and apply-worker being scheduled. If this happens, the
apply-worker holds a pointer to a framebuffer which is already destroyed.

Take an extra refernece/unreference of the fb in omap_plane_update() to prevent
this from happening. A reference is taken of the fb passed to update_plane(),
the previous framebuffer (held by plane->fb) is unreferenced. This will prevent
drm from destroying the framebuffer till the time it's unreferenced by the
apply-worker.

This is in addition to the exisitng reference/unreference in update_pin(),
which is taken for the scanout of the plane's current framebuffer, and an
unreference the previous framebuffer.

Signed-off-by: Archit Taneja 
Cc: Rob Clark 
---
 drivers/gpu/drm/omapdrm/omap_plane.c |6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
b/drivers/gpu/drm/omapdrm/omap_plane.c
index 2882cda..8d225d7 100644
--- a/drivers/gpu/drm/omapdrm/omap_plane.c
+++ b/drivers/gpu/drm/omapdrm/omap_plane.c
@@ -247,6 +247,12 @@ static int omap_plane_update(struct drm_plane *plane,
 {
struct omap_plane *omap_plane = to_omap_plane(plane);
omap_plane->enabled = true;
+
+   if (plane->fb)
+   drm_framebuffer_unreference(plane->fb);
+
+   drm_framebuffer_reference(fb);
+
return omap_plane_mode_set(plane, crtc, fb,
crtc_x, crtc_y, crtc_w, crtc_h,
src_x, src_y, src_w, src_h,
-- 
1.7.10.4

[PATCH]drm: Re-add DMT modes for monitors back

[Wang YanQing]

Commit 196e077dc165a307efbd9e7569f81bbdbcf18f65
"drm: don't add inferred modes for monitors that don't support them"

It remove the call add_inferred_modes when DRM_EDID_FEATURE_DEFAULT_GTF
in feature support field is zero, this remove all inferred modes
come from GTF or CVT range information, and also remove DMT modes,
this make me lost some avaiable modes for my TV.
Without this patch I get:
Screen 0: minimum 320 x 200, current 2720 x 1024, maximum 32767 x 32767
VGA1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 414mm x 
257mm
   1440x900   75.0*+   59.9
   1400x1050  60.3
   1280x1024  75.0
   1280x800   59.8
   1152x864   75.0
   1280x720   60.0
   1024x768   75.1 70.1 60.0
   832x62474.6
   800x60072.2 75.0 60.3
   640x48072.8 75.0 66.7 60.0
   720x40070.1
HDMI1 connected 1280x1024+1440+0 (normal left inverted right x axis y axis) 
1600mm x 900mm
   1920x1080  60.0 +   50.0
   1920x1080i 30.0 25.0
   1280x1024  60.0*
   1280x720   60.0 50.0
   1440x576i  25.0
   1024x768   60.0
   1440x480i  30.0
   800x60060.3
   720x57650.0
   720x48059.9
   640x48060.0 59.9
DP1 disconnected (normal left inverted right x axis y axis)

With this patch I get below:
Screen 0: minimum 320 x 200, current 2880 x 900, maximum 32767 x 32767
VGA1 connected 1440x900+0+0 (normal left inverted right x axis y axis) 414mm x 
257mm
   1440x900   75.0*+   59.9
   1400x1050  60.3
   1280x1024  75.0
   1280x800   59.8
   1152x864   75.0
   1280x720   60.0
   1024x768   75.1 70.1 60.0
   832x62474.6
   800x60072.2 75.0 60.3
   640x48072.8 75.0 66.7 60.0
   720x40070.1
HDMI1 connected 1440x900+1440+0 (normal left inverted right x axis y axis) 
1600mm x 900mm
   1440x900   59.9*+
   1920x1080  60.0 +   50.0
   1920x1080i 30.0 25.0
   1680x1050  59.9
   1400x1050  59.9
   1280x1024  60.0
   1280x960   60.0
   1360x768   60.0
   1280x800   59.9
   1280x768   60.0
   1280x720   60.0 50.0
   1440x576i  25.0
   1024x768   60.0
   1440x480i  30.0
   800x60060.3 56.2
   720x57650.0
   848x48060.0
   720x48059.9
   640x48060.0 59.9
DP1 disconnected (normal left inverted right x axis y axis)

Signed-off-by: Wang YanQing 
---
 drivers/gpu/drm/drm_edid.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index dfd9ed3..10c2147 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1182,7 +1182,8 @@ do_inferred_modes(struct detailed_timing *timing, void *c)
  closure->edid,
  timing);

-   if (!version_greater(closure->edid, 1, 1))
+   if (!version_greater(closure->edid, 1, 1) ||
+   !(closure->edid->features & DRM_EDID_FEATURE_DEFAULT_GTF))
return; /* GTF not defined yet */

switch (range->flags) {
@@ -2022,8 +2023,7 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
num_modes += add_cvt_modes(connector, edid);
num_modes += add_standard_modes(connector, edid);
num_modes += add_established_modes(connector, edid);
-   if (edid->features & DRM_EDID_FEATURE_DEFAULT_GTF)
-   num_modes += add_inferred_modes(connector, edid);
+   num_modes += add_inferred_modes(connector, edid);
num_modes += add_cea_modes(connector, edid);

if (quirks & (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75))
-- 
1.7.12.4.dirty

[PATCH 3/7] drm/radeon: implement unpin function

[Daniel Vetter]

On Tue, Apr 9, 2013 at 4:26 PM, Maarten Lankhorst
 wrote:
> Op 09-04-13 16:16, Jerome Glisse schreef:
>> On Tue, Apr 9, 2013 at 7:37 AM, Maarten Lankhorst
>> wrote:
>>
>>> Signed-off-by: Maarten Lankhorst 
>>>
>> Can userspace pin directly ? If so then that sounds as a bad idea.
>>
>> Reviewed-by: Jerome Glisse 
>>
> It's slightly better than before, it used to pin as soon as you export a 
> buffer for as long as the buffer exists, with the series the pinning will 
> only happen when importing to another device, until the device releases their 
> reference.

To make fully dynamic pinning work (and especially reclaiming) we
first need dma_buf fences, the new ww_mutexes and all that stuff since
otherwise you can trivially deadlock in buffer reservations. But I
think with Maarten's stuff we have a plan to get there, and this is
just the first tiny step of a long journey.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 3/7] drm/radeon: implement unpin function

[Maarten Lankhorst]

Op 09-04-13 16:16, Jerome Glisse schreef:
> On Tue, Apr 9, 2013 at 7:37 AM, Maarten Lankhorst
> wrote:
>
>> Signed-off-by: Maarten Lankhorst 
>>
> Can userspace pin directly ? If so then that sounds as a bad idea.
>
> Reviewed-by: Jerome Glisse 
>
It's slightly better than before, it used to pin as soon as you export a buffer 
for as long as the buffer exists, with the series the pinning will only happen 
when importing to another device, until the device releases their reference.

~Maarten

[PATCH 0/7] i.MX53 IPU + TVE patches

[Greg Kroah-Hartman]

On Tue, Apr 09, 2013 at 09:44:46AM +0200, Philipp Zabel wrote:
> Hi Greg,
> 
> Am Montag, den 08.04.2013, 10:40 -0700 schrieb Greg Kroah-Hartman:
> > On Mon, Apr 08, 2013 at 06:04:31PM +0200, Philipp Zabel wrote:
> > > Hi,
> > > 
> > > the following patches allow to use the integrated Television Encoder
> > > (TVEv2) on the i.MX53 SoC as VGA output encoder for the IPU. This is
> > > useful for the Freescale i.MX53-QSB and TQ MBa53 boards, which have
> > > VGA and DVI-I connectors, respectively.
> > > 
> > > regards
> > > Philipp
> > > 
> > > ---
> > >  drivers/staging/imx-drm/Kconfig |   7 +
> > >  drivers/staging/imx-drm/Makefile|   1 +
> > >  drivers/staging/imx-drm/imx-drm-core.c  |  15 +-
> > >  drivers/staging/imx-drm/imx-drm.h   |  14 +-
> > >  drivers/staging/imx-drm/imx-tve.c   | 755 
> > > 
> > >  drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h |   3 +
> > >  drivers/staging/imx-drm/ipu-v3/ipu-dc.c |  55 +-
> > >  drivers/staging/imx-drm/ipu-v3/ipu-di.c | 100 +++-
> > >  drivers/staging/imx-drm/ipuv3-crtc.c|  11 +-
> > >  9 files changed, 932 insertions(+), 29 deletions(-)
> > 
> > That's a lot of new features being added here, yet no work seems to be
> > happening to move this out of the staging tree.  What is left to do
> > here, and why isn't that being worked on first, before stuff like this?
> 
> the IPU code could still use a bit of testing, and I hope adding
> features like VGA output on common development boards will increase the
> amount of scrutiny this code will get.
> I expect the structure of the IPU drivers to change when the common
> display framework gets introduced at last, also requiring changes to the
> device tree bindings, and I'm a bit reluctant to push for mainline
> proper while the bindings are still not clear.

Ok, thanks for the information.  Is the TODO file still correct with
these changes?  If not, care to send a patch to update it as well?

thanks,

greg k-h

[PATCH] drm/omap: Take a fb reference in omap_plane_update()

[Daniel Vetter]

On Tue, Apr 9, 2013 at 3:17 PM, Rob Clark  wrote:
>>> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
>>> b/drivers/gpu/drm/omapdrm/omap_plane.c
>>> index 2882cda..8d225d7 100644
>>> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
>>> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
>>> @@ -247,6 +247,12 @@ static int omap_plane_update(struct drm_plane *plane,
>>>  {
>>>   struct omap_plane *omap_plane = to_omap_plane(plane);
>>>   omap_plane->enabled = true;
>>> +
>>> + if (plane->fb)
>>> + drm_framebuffer_unreference(plane->fb);
>>
>> Shouldn't the unref only happen once the flip has completed? Otherwise we
>> might free the memory which is still being scanned out and put some other
>> crap there.
>
> yup, there is a 2nd ref grabbed when we start scanout and dropped when
> we finish scanout..  so that part was already covered.  What wasn't
> covered before was the time between the ioctl and the worker thread
> (which was grabbing/dropping the scanout ref)

Ah, I see. And the ordering doesn't seem to matter here since it's all
protected by locks (against races with the worker thread) anyway.
Thanks for the explanation.
-Daniel

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

drm/i915: new warning (regression) in 3.7.10 and 3.8.3

[Richard Cochran]

On Tue, Apr 09, 2013 at 02:50:03PM +0200, Daniel Vetter wrote:
> 
> This should be fixed with the above mentioned patch. The issue is that the
> bios fumbles around with the output configuration behind our backs, so the
> new paranoid modeset code in 3.7+ freaks out about the state mismatch
> between sw and hw.
> 
> The patch above should detect this situation and undo any bios-induced
> damage.

Even with the patch, I still am seeing the issue (in 3.8).

Thanks,
Richard

[Bug 62997] Crashes on ARUBA unless R600_DEBUG=nodma

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

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

--- Comment #9 from udo  ---
3.8.6 with and without patch had crashes of various kind. (hard freeze even!)
Now doing 3.8.5 without patch, waiting for the raid check to complete.

-- 
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/20130409/ab0fdd60/attachment.html>

[PATCH 2/2] drm: prime: fix lookup of existing imports for self imported buffers

[Imre Deak]

Since atm we don't take a reference on the dma buf pointer when we add
it to the import lookup table the dma buf can vanish leaving the stale
pointer behind. This can in turn lead to returning stale GEM handles
when userspace imports a newly exported buffer.

Fix this by keeping a reference on the dma buffer whenever we have a
pointer to it in the lookup table.

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

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/drm_prime.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index bba45f6..e4e1a69 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -501,6 +501,7 @@ int drm_prime_add_imported_buf_handle(struct 
drm_prime_file_private *prime_fpriv
if (!member)
return -ENOMEM;

+   get_dma_buf(dma_buf);
member->dma_buf = dma_buf;
member->handle = handle;
list_add(>entry, _fpriv->head);
@@ -529,6 +530,7 @@ void drm_prime_remove_imported_buf_handle(struct 
drm_prime_file_private *prime_f
mutex_lock(_fpriv->lock);
list_for_each_entry_safe(member, safe, _fpriv->head, entry) {
if (member->dma_buf == dma_buf) {
+   dma_buf_put(dma_buf);
list_del(>entry);
kfree(member);
}
-- 
1.7.10.4

[PATCH 1/2] drm: prime: fix refcounting on the dmabuf import error path

[Imre Deak]

In commit be8a42ae60 we inroduced a refcount problem, where on the
drm_gem_prime_fd_to_handle() error path we'll call dma_buf_put() for
self imported dma buffers.

Fix this by taking a reference on the dma buffer in the .gem_import
hook instead of assuming the caller had taken one. Besides fixing the
bug this is also more logical.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/drm_prime.c|8 +++-
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |4 +++-
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |5 -
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |1 -
 drivers/gpu/drm/udl/udl_gem.c  |4 
 5 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 25d0218..bba45f6 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -268,7 +268,6 @@ struct drm_gem_object *drm_gem_prime_import(struct 
drm_device *dev,
 * refcount on gem itself instead of f_count of dmabuf.
 */
drm_gem_object_reference(obj);
-   dma_buf_put(dma_buf);
return obj;
}
}
@@ -277,6 +276,8 @@ struct drm_gem_object *drm_gem_prime_import(struct 
drm_device *dev,
if (IS_ERR(attach))
return ERR_PTR(PTR_ERR(attach));

+   get_dma_buf(dma_buf);
+
sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
if (IS_ERR_OR_NULL(sgt)) {
ret = PTR_ERR(sgt);
@@ -297,6 +298,8 @@ fail_unmap:
dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
 fail_detach:
dma_buf_detach(dma_buf, attach);
+   dma_buf_put(dma_buf);
+
return ERR_PTR(ret);
 }
 EXPORT_SYMBOL(drm_gem_prime_import);
@@ -339,6 +342,9 @@ int drm_gem_prime_fd_to_handle(struct drm_device *dev,
goto fail;

mutex_unlock(_priv->prime.lock);
+
+   dma_buf_put(dma_buf);
+
return 0;

 fail:
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index ba0a3aa..ff7f2a8 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -235,7 +235,6 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct 
drm_device *drm_dev,
 * refcount on gem itself instead of f_count of dmabuf.
 */
drm_gem_object_reference(obj);
-   dma_buf_put(dma_buf);
return obj;
}
}
@@ -244,6 +243,7 @@ struct drm_gem_object *exynos_dmabuf_prime_import(struct 
drm_device *drm_dev,
if (IS_ERR(attach))
return ERR_PTR(-EINVAL);

+   get_dma_buf(dma_buf);

sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
if (IS_ERR_OR_NULL(sgt)) {
@@ -298,6 +298,8 @@ err_unmap_attach:
dma_buf_unmap_attachment(attach, sgt, DMA_BIDIRECTIONAL);
 err_buf_detach:
dma_buf_detach(dma_buf, attach);
+   dma_buf_put(dma_buf);
+
return ERR_PTR(ret);
 }

diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index c6dfc14..30485e9 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -272,7 +272,6 @@ struct drm_gem_object *i915_gem_prime_import(struct 
drm_device *dev,
 * refcount on gem itself instead of f_count of dmabuf.
 */
drm_gem_object_reference(>base);
-   dma_buf_put(dma_buf);
return >base;
}
}
@@ -282,6 +281,8 @@ struct drm_gem_object *i915_gem_prime_import(struct 
drm_device *dev,
if (IS_ERR(attach))
return ERR_CAST(attach);

+   get_dma_buf(dma_buf);
+
obj = i915_gem_object_alloc(dev);
if (obj == NULL) {
ret = -ENOMEM;
@@ -301,5 +302,7 @@ struct drm_gem_object *i915_gem_prime_import(struct 
drm_device *dev,

 fail_detach:
dma_buf_detach(dma_buf, attach);
+   dma_buf_put(dma_buf);
+
return ERR_PTR(ret);
 }
diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c 
b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index ac74d1b..1bdf7e1 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
@@ -212,7 +212,6 @@ struct drm_gem_object *omap_gem_prime_import(struct 
drm_device *dev,
 * refcount on gem itself instead of f_count of dmabuf.
 */
drm_gem_object_reference(obj);
-   dma_buf_put(buffer);
return obj;
}
}
diff --git a/drivers/gpu/drm/udl/udl_gem.c b/drivers/gpu/drm/udl/udl_gem.c
index 3816270..ef034fa 100644
--- a/drivers/gpu/drm/udl/udl_gem.c
+++ 

[PATCH 1/7] drm: add unpin function to prime helpers

[Daniel Vetter]

On Tue, Apr 09, 2013 at 01:37:40PM +0200, Maarten Lankhorst wrote:
> Prevents buffers from being pinned forever.
> 
> Signed-off-by: Maarten Lankhorst 

Did I mention in my review of Aaron's patch that is feels a bit inflexible
to move the dma_buf vtable to here and has a midlayer touch to it? Looks
like we fix this by adding an vtable which pretty much just forwards the
dma-buf calls 1:1 ;-)

Whatever, i915.ko does use this, so patches 1-2 are

Reviewed-by: Daniel Vetter 

The others are acked on principle, but I'm too lazy to dig into that
driver code to do a real review.
-Daniel

> ---
>  drivers/gpu/drm/drm_prime.c | 13 +++--
>  include/drm/drmP.h  |  1 +
>  2 files changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 366910d..85bbc52 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -91,10 +91,13 @@ static void drm_gem_unmap_dma_buf(struct 
> dma_buf_attachment *attach,
>  static void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
>  {
>   struct drm_gem_object *obj = dma_buf->priv;
> + struct drm_device *dev = obj->dev;
>  
>   if (obj->export_dma_buf == dma_buf) {
>   /* drop the reference on the export fd holds */
>   obj->export_dma_buf = NULL;
> + if (dev->driver->gem_prime_unpin)
> + dev->driver->gem_prime_unpin(obj);
>   drm_gem_object_unreference_unlocked(obj);
>   }
>  }
> @@ -184,13 +187,19 @@ static const struct dma_buf_ops 
> drm_gem_prime_dmabuf_ops =  {
>  struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
>struct drm_gem_object *obj, int flags)
>  {
> + struct dma_buf *buf;
> +
>   if (dev->driver->gem_prime_pin) {
>   int ret = dev->driver->gem_prime_pin(obj);
>   if (ret)
>   return ERR_PTR(ret);
>   }
> - return dma_buf_export(obj, _gem_prime_dmabuf_ops, obj->size,
> -   0600);
> + buf = dma_buf_export(obj, _gem_prime_dmabuf_ops, obj->size,
> +  0600);
> +
> + if (IS_ERR(buf) && dev->driver->gem_prime_unpin)
> + dev->driver->gem_prime_unpin(obj);
> + return buf;
>  }
>  EXPORT_SYMBOL(drm_gem_prime_export);
>  
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 2d94d74..99dc622 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -932,6 +932,7 @@ struct drm_driver {
>   struct dma_buf *dma_buf);
>   /* low-level interface used by drm_gem_prime_{import,export} */
>   int (*gem_prime_pin)(struct drm_gem_object *obj);
> + void (*gem_prime_unpin)(struct drm_gem_object *obj);
>   struct sg_table *(*gem_prime_get_sg_table)(struct drm_gem_object *obj);
>   struct drm_gem_object *(*gem_prime_import_sg_table)(
>   struct drm_device *dev, size_t size,
> -- 
> 1.8.2
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

drm/i915: new warning (regression) in 3.7.10 and 3.8.3

[Tomas Melin]

On Mon, 18 Mar 2013 09:32:51 +0100, Daniel Vetter wrote:
>
> On Sat, Mar 16, 2013 at 01:28:50PM +0100, Richard Cochran wrote:
>>
>> I have an Acer Aspire One netbook, and on it I get the following
>> warning when closing and opening the lid. I think this warning first
>> appeared in 3.7.
>>
>> Does this need fixing? If so, who can do it?
>
> Another pesky BIOS which changes the display state behind our back on lid
> closing! Should be duct-tapped over with
>
> commit 45e2b5f640b3766da3eda48f6c35f088155c06f3
> Author: Daniel Vetter 
> Date:   Fri Nov 23 18:16:34 2012 +0100
>
> drm/i915: force restore on lid open
>
> which is in 3.8.

I'm seeing the same problems on my eeepc using 3.8. Happens (most) of
the time when opening and closing the lid. Any ideas on how to fix
this?

-Tomas

[20314.679749] [drm:i9xx_crtc_mode_set] *ERROR* Couldn't find PLL
settings for mode!

[20314.679787] [ cut here ]
[20314.679819] WARNING: at drivers/gpu/drm/i915/intel_display.c:7864
intel_modeset_check_state+0x4ad/0x620()
[20314.679831] Hardware name: 901
[20314.679843] encoder's hw state doesn't match sw tracking (expected
1, found 0)
[20314.679853] Modules linked in: bridge ipv6 rfcomm fuse btusb
rt2800pci rt2800lib rt2x00pci rt2x00lib atl1e
[20314.679917] Pid: 10069, comm: kworker/0:0 Tainted: GW3.8.0 #8
[20314.679930] Call Trace:
[20314.679958]  [] warn_slowpath_common+0x6d/0xa0
[20314.679983]  [] ? intel_modeset_check_state+0x4ad/0x620
[20314.680006]  [] ? intel_modeset_check_state+0x4ad/0x620
[20314.680017]  [] warn_slowpath_fmt+0x2e/0x30
[20314.680017]  [] intel_modeset_check_state+0x4ad/0x620
[20314.680103]  [] intel_set_mode+0x701/0x990
[20314.680170]  [] intel_modeset_setup_hw_state+0x5d5/0x8e0
[20314.680215]  [] ? acpi_lid_open+0x28/0x40
[20314.680236]  [] intel_lid_notify+0x9b/0xc0
[20314.680258]  [] notifier_call_chain+0x45/0x60
[20314.680283]  [] __blocking_notifier_call_chain+0x3e/0x60
[20314.680306]  [] blocking_notifier_call_chain+0x1a/0x20
[20314.680329]  [] acpi_lid_send_state+0x78/0x9d
[20314.680351]  [] acpi_button_notify+0x30/0xa4
[20314.680376]  [] acpi_device_notify+0x12/0x15
[20314.680402]  [] acpi_ev_notify_dispatch+0x2e/0x45
[20314.680424]  [] acpi_os_execute_deferred+0x1b/0x26
[20314.680449]  [] process_one_work+0x110/0x380
[20314.680475]  [] ? apic_timer_interrupt+0x2d/0x34
[20314.680498]  [] ? acpi_os_wait_events_complete+0x19/0x19
[20314.680522]  [] worker_thread+0x119/0x340
[20314.680545]  [] ? manage_workers+0x260/0x260
[20314.680572]  [] kthread+0x8f/0xa0
[20314.680598]  [] ret_from_kernel_thread+0x1b/0x28
[20314.680622]  [] ? flush_kthread_work+0xc0/0xc0
[20314.680640] ---[ end trace 037b36714b28cbdf ]---
[20314.680661] [ cut here ]
[20314.680684] WARNING: at drivers/gpu/drm/i915/intel_display.c:7898
intel_modeset_check_state+0x47b/0x620()
[20314.680697] Hardware name: 901
[20314.680709] crtc's computed active state doesn't match tracked
active state (expected 1, found 0)
[20314.680719] Modules linked in: bridge ipv6 rfcomm fuse btusb
rt2800pci rt2800lib rt2x00pci rt2x00lib atl1e
[20314.680898] Pid: 10069, comm: kworker/0:0 Tainted: GW3.8.0 #8
[20314.680910] Call Trace:
[20314.680934]  [] warn_slowpath_common+0x6d/0xa0
[20314.680960]  [] ? intel_modeset_check_state+0x47b/0x620
[20314.680983]  [] ? intel_modeset_check_state+0x47b/0x620
[20314.681006]  [] warn_slowpath_fmt+0x2e/0x30
[20314.681041]  [] intel_modeset_check_state+0x47b/0x620
[20314.681052]  [] intel_set_mode+0x701/0x990
[20314.681095]  [] intel_modeset_setup_hw_state+0x5d5/0x8e0
[20314.681122]  [] ? acpi_lid_open+0x28/0x40
[20314.681147]  [] intel_lid_notify+0x9b/0xc0
[20314.681170]  [] notifier_call_chain+0x45/0x60
[20314.681196]  [] __blocking_notifier_call_chain+0x3e/0x60
[20314.681221]  [] blocking_notifier_call_chain+0x1a/0x20
[20314.681246]  [] acpi_lid_send_state+0x78/0x9d
[20314.681270]  [] acpi_button_notify+0x30/0xa4
[20314.681295]  [] acpi_device_notify+0x12/0x15
[20314.681320]  [] acpi_ev_notify_dispatch+0x2e/0x45
[20314.681344]  [] acpi_os_execute_deferred+0x1b/0x26
[20314.681366]  [] process_one_work+0x110/0x380
[20314.681392]  [] ? apic_timer_interrupt+0x2d/0x34
[20314.681416]  [] ? acpi_os_wait_events_complete+0x19/0x19
[20314.681465]  [] worker_thread+0x119/0x340
[20314.681516]  [] ? manage_workers+0x260/0x260
[20314.681568]  [] kthread+0x8f/0xa0
[20314.681614]  [] ret_from_kernel_thread+0x1b/0x28
[20314.681660]  [] ? flush_kthread_work+0xc0/0xc0
[20314.681681] ---[ end trace 037b36714b28cbe0 ]---

[PATCH] drm/omap: Take a fb reference in omap_plane_update()

[Daniel Vetter]

On Tue, Apr 09, 2013 at 05:56:02PM +0530, Archit Taneja wrote:
> When userspace calls SET_PLANE ioctl, drm core takes a reference of the fb and
> passes control to the update_plane op defined by the drm driver.
> 
> In omapdrm, we have a worker thread which queues framebuffers objects received
> from update_plane and displays them at the appropriate time.
> 
> It is possible that the framebuffer is destoryed by userspace between the time
> of calling the ioctl and apply-worker being scheduled. If this happens, the
> apply-worker holds a pointer to a framebuffer which is already destroyed.
> 
> Take an extra refernece/unreference of the fb in omap_plane_update() to 
> prevent
> this from happening. A reference is taken of the fb passed to update_plane(),
> the previous framebuffer (held by plane->fb) is unreferenced. This will 
> prevent
> drm from destroying the framebuffer till the time it's unreferenced by the
> apply-worker.
> 
> This is in addition to the exisitng reference/unreference in update_pin(),
> which is taken for the scanout of the plane's current framebuffer, and an
> unreference the previous framebuffer.
> 
> Signed-off-by: Archit Taneja 
> Cc: Rob Clark 
> ---
>  drivers/gpu/drm/omapdrm/omap_plane.c |6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
> b/drivers/gpu/drm/omapdrm/omap_plane.c
> index 2882cda..8d225d7 100644
> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
> @@ -247,6 +247,12 @@ static int omap_plane_update(struct drm_plane *plane,
>  {
>   struct omap_plane *omap_plane = to_omap_plane(plane);
>   omap_plane->enabled = true;
> +
> + if (plane->fb)
> + drm_framebuffer_unreference(plane->fb);

Shouldn't the unref only happen once the flip has completed? Otherwise we
might free the memory which is still being scanned out and put some other
crap there.

Note that I've been too lazy to read the code, but I expected the unref of
the old one to happen after the ref-taking for the new one, with a vblank
wait/delay in between ... Might be that I'm completely off ;-)
-Daniel

> +
> + drm_framebuffer_reference(fb);
> +
>   return omap_plane_mode_set(plane, crtc, fb,
>   crtc_x, crtc_y, crtc_w, crtc_h,
>   src_x, src_y, src_w, src_h,
> -- 
> 1.7.10.4
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

drm/i915: new warning (regression) in 3.7.10 and 3.8.3

[Daniel Vetter]

On Tue, Apr 09, 2013 at 02:54:34PM +0300, Tomas Melin wrote:
> On Mon, 18 Mar 2013 09:32:51 +0100, Daniel Vetter wrote:
> >
> > On Sat, Mar 16, 2013 at 01:28:50PM +0100, Richard Cochran wrote:
> >>
> >> I have an Acer Aspire One netbook, and on it I get the following
> >> warning when closing and opening the lid. I think this warning first
> >> appeared in 3.7.
> >>
> >> Does this need fixing? If so, who can do it?
> >
> > Another pesky BIOS which changes the display state behind our back on lid
> > closing! Should be duct-tapped over with
> >
> > commit 45e2b5f640b3766da3eda48f6c35f088155c06f3
> > Author: Daniel Vetter 
> > Date:   Fri Nov 23 18:16:34 2012 +0100
> >
> > drm/i915: force restore on lid open
> >
> > which is in 3.8.
> 
> I'm seeing the same problems on my eeepc using 3.8. Happens (most) of
> the time when opening and closing the lid. Any ideas on how to fix
> this?

This should be fixed with the above mentioned patch. The issue is that the
bios fumbles around with the output configuration behind our backs, so the
new paranoid modeset code in 3.7+ freaks out about the state mismatch
between sw and hw.

The patch above should detect this situation and undo any bios-induced
damage.
-Daniel

> 
> -Tomas
> 
> [20314.679749] [drm:i9xx_crtc_mode_set] *ERROR* Couldn't find PLL
> settings for mode!
> 
> [20314.679787] [ cut here ]
> [20314.679819] WARNING: at drivers/gpu/drm/i915/intel_display.c:7864
> intel_modeset_check_state+0x4ad/0x620()
> [20314.679831] Hardware name: 901
> [20314.679843] encoder's hw state doesn't match sw tracking (expected
> 1, found 0)
> [20314.679853] Modules linked in: bridge ipv6 rfcomm fuse btusb
> rt2800pci rt2800lib rt2x00pci rt2x00lib atl1e
> [20314.679917] Pid: 10069, comm: kworker/0:0 Tainted: GW3.8.0 #8
> [20314.679930] Call Trace:
> [20314.679958]  [] warn_slowpath_common+0x6d/0xa0
> [20314.679983]  [] ? intel_modeset_check_state+0x4ad/0x620
> [20314.680006]  [] ? intel_modeset_check_state+0x4ad/0x620
> [20314.680017]  [] warn_slowpath_fmt+0x2e/0x30
> [20314.680017]  [] intel_modeset_check_state+0x4ad/0x620
> [20314.680103]  [] intel_set_mode+0x701/0x990
> [20314.680170]  [] intel_modeset_setup_hw_state+0x5d5/0x8e0
> [20314.680215]  [] ? acpi_lid_open+0x28/0x40
> [20314.680236]  [] intel_lid_notify+0x9b/0xc0
> [20314.680258]  [] notifier_call_chain+0x45/0x60
> [20314.680283]  [] __blocking_notifier_call_chain+0x3e/0x60
> [20314.680306]  [] blocking_notifier_call_chain+0x1a/0x20
> [20314.680329]  [] acpi_lid_send_state+0x78/0x9d
> [20314.680351]  [] acpi_button_notify+0x30/0xa4
> [20314.680376]  [] acpi_device_notify+0x12/0x15
> [20314.680402]  [] acpi_ev_notify_dispatch+0x2e/0x45
> [20314.680424]  [] acpi_os_execute_deferred+0x1b/0x26
> [20314.680449]  [] process_one_work+0x110/0x380
> [20314.680475]  [] ? apic_timer_interrupt+0x2d/0x34
> [20314.680498]  [] ? acpi_os_wait_events_complete+0x19/0x19
> [20314.680522]  [] worker_thread+0x119/0x340
> [20314.680545]  [] ? manage_workers+0x260/0x260
> [20314.680572]  [] kthread+0x8f/0xa0
> [20314.680598]  [] ret_from_kernel_thread+0x1b/0x28
> [20314.680622]  [] ? flush_kthread_work+0xc0/0xc0
> [20314.680640] ---[ end trace 037b36714b28cbdf ]---
> [20314.680661] [ cut here ]
> [20314.680684] WARNING: at drivers/gpu/drm/i915/intel_display.c:7898
> intel_modeset_check_state+0x47b/0x620()
> [20314.680697] Hardware name: 901
> [20314.680709] crtc's computed active state doesn't match tracked
> active state (expected 1, found 0)
> [20314.680719] Modules linked in: bridge ipv6 rfcomm fuse btusb
> rt2800pci rt2800lib rt2x00pci rt2x00lib atl1e
> [20314.680898] Pid: 10069, comm: kworker/0:0 Tainted: GW3.8.0 #8
> [20314.680910] Call Trace:
> [20314.680934]  [] warn_slowpath_common+0x6d/0xa0
> [20314.680960]  [] ? intel_modeset_check_state+0x47b/0x620
> [20314.680983]  [] ? intel_modeset_check_state+0x47b/0x620
> [20314.681006]  [] warn_slowpath_fmt+0x2e/0x30
> [20314.681041]  [] intel_modeset_check_state+0x47b/0x620
> [20314.681052]  [] intel_set_mode+0x701/0x990
> [20314.681095]  [] intel_modeset_setup_hw_state+0x5d5/0x8e0
> [20314.681122]  [] ? acpi_lid_open+0x28/0x40
> [20314.681147]  [] intel_lid_notify+0x9b/0xc0
> [20314.681170]  [] notifier_call_chain+0x45/0x60
> [20314.681196]  [] __blocking_notifier_call_chain+0x3e/0x60
> [20314.681221]  [] blocking_notifier_call_chain+0x1a/0x20
> [20314.681246]  [] acpi_lid_send_state+0x78/0x9d
> [20314.681270]  [] acpi_button_notify+0x30/0xa4
> [20314.681295]  [] acpi_device_notify+0x12/0x15
> [20314.681320]  [] acpi_ev_notify_dispatch+0x2e/0x45
> [20314.681344]  [] acpi_os_execute_deferred+0x1b/0x26
> [20314.681366]  [] process_one_work+0x110/0x380
> [20314.681392]  [] ? apic_timer_interrupt+0x2d/0x34
> [20314.681416]  [] ? acpi_os_wait_events_complete+0x19/0x19
> [20314.681465]  [] worker_thread+0x119/0x340
> [20314.681516]  [] ? manage_workers+0x260/0x260
> [20314.681568]  [] kthread+0x8f/0xa0
> [20314.681614] 

[PATCH] drm/radeon: add ring working query

[Christian König]

From: Christian K?nig 

Add new ioctl option and bumb minor version number.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon_drv.c |2 +-
 drivers/gpu/drm/radeon/radeon_kms.c |   17 +
 include/uapi/drm/radeon_drm.h   |2 ++
 3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 66a7f0f..31b193b 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -73,7 +73,7 @@
  *   2.30.0 - fix for FMASK texturing
  */
 #define KMS_DRIVER_MAJOR   2
-#define KMS_DRIVER_MINOR   30
+#define KMS_DRIVER_MINOR   31
 #define KMS_DRIVER_PATCHLEVEL  0
 int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
 int radeon_driver_unload_kms(struct drm_device *dev);
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index 3019759..8cb9d12 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -376,6 +376,23 @@ int radeon_info_ioctl(struct drm_device *dev, void *data, 
struct drm_file *filp)
else
return -EINVAL;
break;
+   case RADEON_INFO_RING_WORKING:
+   switch (value) {
+   case RADEON_CS_RING_GFX:
+   case RADEON_CS_RING_COMPUTE:
+   value = rdev->ring[RADEON_RING_TYPE_GFX_INDEX].ready;
+   break;
+   case RADEON_CS_RING_DMA:
+   value = rdev->ring[R600_RING_TYPE_DMA_INDEX].ready;
+   value |= rdev->ring[CAYMAN_RING_TYPE_DMA1_INDEX].ready;
+   break;
+   case RADEON_CS_RING_UVD:
+   value = rdev->ring[R600_RING_TYPE_UVD_INDEX].ready;
+   break;
+   default:
+   return -EINVAL;
+   }
+   break;
default:
DRM_DEBUG_KMS("Invalid request %d\n", info->request);
return -EINVAL;
diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index cd085d1..8459415 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
@@ -973,6 +973,8 @@ struct drm_radeon_cs {
 #define RADEON_INFO_MAX_SE 0x12
 /* max SH per SE */
 #define RADEON_INFO_MAX_SH_PER_SE  0x13
+/* query if a RADEON_CS_RING_* submission is supported */
+#define RADEON_INFO_RING_WORKING   0x14

 struct drm_radeon_info {
uint32_trequest;
-- 
1.7.9.5

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

[Xiong Zhou]

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

[Bug 63090] mesa 9.2git: qvdpautest fails to work with UVD but also fails with shader decoding

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

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

Christian K?nig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTOURBUG

--- Comment #2 from Christian K?nig  ---
That's a bug in qvdpautest. It tries to get the surface data in YUYV format,
which is simply not supported by the hardware.

We could implement a software fallback, but mesuring that would be pretty much
nonsense.

-- 
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/20130409/2cd7bb2f/attachment.html>

[Bug 62997] Crashes on ARUBA unless R600_DEBUG=nodma

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

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

--- Comment #8 from udo  ---
Will start testing on 3.8.6 in a few minutes.

-- 
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/20130409/0bfb66ba/attachment.html>

[PATCH 7/7] drm/nouveau: complain loudly if buffer is pinned during destruction

[Maarten Lankhorst]

Shouldn't happen, and we invert the struct_mutex with reservation here,
potentially leading to deadlocks. Once reservations become lockdep annotated,
lockdep will go splat on this.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/nouveau/nouveau_gem.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index b4b4d0c..7054706 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -50,7 +50,8 @@ nouveau_gem_object_del(struct drm_gem_object *gem)
return;
nvbo->gem = NULL;

-   if (unlikely(nvbo->pin_refcnt)) {
+   /* Lockdep hates you for doing reserve with gem object lock held */
+   if (WARN_ON_ONCE(nvbo->pin_refcnt)) {
nvbo->pin_refcnt = 1;
nouveau_bo_unpin(nvbo);
}
-- 
1.8.2

[PATCH 6/7] drm/nouveau: fixup fbcon failure paths

[Maarten Lankhorst]

Add missing calls, and fix a leak from forgetting to call the unpin function.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/nouveau/nouveau_fbcon.c | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index b035317..ecbfe69 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -289,16 +289,13 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
ret = nouveau_bo_pin(nvbo, TTM_PL_FLAG_VRAM);
if (ret) {
NV_ERROR(drm, "failed to pin fb: %d\n", ret);
-   nouveau_bo_ref(NULL, );
-   goto out;
+   goto out_unref;
}

ret = nouveau_bo_map(nvbo);
if (ret) {
NV_ERROR(drm, "failed to map fb: %d\n", ret);
-   nouveau_bo_unpin(nvbo);
-   nouveau_bo_ref(NULL, );
-   goto out;
+   goto out_unpin;
}

chan = nouveau_nofbaccel ? NULL : drm->channel;
@@ -316,13 +313,14 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
info = framebuffer_alloc(0, >dev);
if (!info) {
ret = -ENOMEM;
-   goto out_unref;
+   goto out_unlock;
}

ret = fb_alloc_cmap(>cmap, 256, 0);
if (ret) {
ret = -ENOMEM;
-   goto out_unref;
+   framebuffer_release(info);
+   goto out_unlock;
}

info->par = fbcon;
@@ -337,7 +335,7 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
fbcon->helper.fbdev = info;

strcpy(info->fix.id, "nouveaufb");
-   if (nouveau_nofbaccel)
+   if (!chan)
info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_DISABLED;
else
info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_COPYAREA |
@@ -383,8 +381,14 @@ nouveau_fbcon_create(struct drm_fb_helper *helper,
vga_switcheroo_client_fb_set(dev->pdev, info);
return 0;

-out_unref:
+out_unlock:
mutex_unlock(>struct_mutex);
+   if (chan)
+   nouveau_bo_vma_del(nvbo, >nouveau_fb.vma);
+out_unpin:
+   nouveau_bo_unpin(nvbo);
+out_unref:
+   nouveau_bo_ref(NULL, );
 out:
return ret;
 }
@@ -413,6 +417,7 @@ nouveau_fbcon_destroy(struct drm_device *dev, struct 
nouveau_fbdev *fbcon)
if (nouveau_fb->nvbo) {
nouveau_bo_unmap(nouveau_fb->nvbo);
nouveau_bo_vma_del(nouveau_fb->nvbo, _fb->vma);
+   nouveau_bo_unpin(nouveau_fb->nvbo);
drm_gem_object_unreference_unlocked(nouveau_fb->nvbo->gem);
nouveau_fb->nvbo = NULL;
}
-- 
1.8.2

[PATCH 5/7] drm/nouveau: unpin notify object in chan_fini

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/nouveau/nouveau_abi16.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_abi16.c 
b/drivers/gpu/drm/nouveau/nouveau_abi16.c
index 3b6dc88..9750bb9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_abi16.c
+++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c
@@ -128,6 +128,7 @@ nouveau_abi16_chan_fini(struct nouveau_abi16 *abi16,

if (chan->ntfy) {
nouveau_bo_vma_del(chan->ntfy, >ntfy_vma);
+   nouveau_bo_unpin(chan->ntfy);
drm_gem_object_unreference_unlocked(chan->ntfy->gem);
}

-- 
1.8.2

[PATCH 4/7] drm/nouveau: implement prime helper unpin function

[Maarten Lankhorst]

---
 drivers/gpu/drm/nouveau/nouveau_drm.c   | 1 +
 drivers/gpu/drm/nouveau/nouveau_gem.h   | 1 +
 drivers/gpu/drm/nouveau/nouveau_prime.c | 9 -
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index d109936..476f792 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -693,6 +693,7 @@ driver = {
.gem_prime_export = drm_gem_prime_export,
.gem_prime_import = drm_gem_prime_import,
.gem_prime_pin = nouveau_gem_prime_pin,
+   .gem_prime_unpin = nouveau_gem_prime_unpin,
.gem_prime_get_sg_table = nouveau_gem_prime_get_sg_table,
.gem_prime_import_sg_table = nouveau_gem_prime_import_sg_table,
.gem_prime_vmap = nouveau_gem_prime_vmap,
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.h 
b/drivers/gpu/drm/nouveau/nouveau_gem.h
index 8d7a3f0..502e429 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.h
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.h
@@ -36,6 +36,7 @@ extern int nouveau_gem_ioctl_info(struct drm_device *, void *,
  struct drm_file *);

 extern int nouveau_gem_prime_pin(struct drm_gem_object *);
+extern void nouveau_gem_prime_unpin(struct drm_gem_object *);
 extern struct sg_table *nouveau_gem_prime_get_sg_table(struct drm_gem_object 
*);
 extern struct drm_gem_object *nouveau_gem_prime_import_sg_table(
struct drm_device *, size_t size, struct sg_table *);
diff --git a/drivers/gpu/drm/nouveau/nouveau_prime.c 
b/drivers/gpu/drm/nouveau/nouveau_prime.c
index f53e108..e90468d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_prime.c
+++ b/drivers/gpu/drm/nouveau/nouveau_prime.c
@@ -84,7 +84,7 @@ struct drm_gem_object 
*nouveau_gem_prime_import_sg_table(struct drm_device *dev,
 int nouveau_gem_prime_pin(struct drm_gem_object *obj)
 {
struct nouveau_bo *nvbo = nouveau_gem_object(obj);
-   int ret = 0;
+   int ret;

/* pin buffer into GTT */
ret = nouveau_bo_pin(nvbo, TTM_PL_FLAG_TT);
@@ -93,3 +93,10 @@ int nouveau_gem_prime_pin(struct drm_gem_object *obj)

return 0;
 }
+
+void nouveau_gem_prime_unpin(struct drm_gem_object *obj)
+{
+   struct nouveau_bo *nvbo = nouveau_gem_object(obj);
+
+   nouveau_bo_unpin(nvbo);
+}
-- 
1.8.2

[PATCH 3/7] drm/radeon: implement unpin function

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/radeon/radeon_drv.c   |  2 ++
 drivers/gpu/drm/radeon/radeon_prime.c | 18 ++
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
b/drivers/gpu/drm/radeon/radeon_drv.c
index 66a7f0f..6800c5e 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -124,6 +124,7 @@ struct drm_gem_object 
*radeon_gem_prime_import_sg_table(struct drm_device *dev,
size_t size,
struct sg_table *sg);
 int radeon_gem_prime_pin(struct drm_gem_object *obj);
+void radeon_gem_prime_unpin(struct drm_gem_object *obj);
 void *radeon_gem_prime_vmap(struct drm_gem_object *obj);
 void radeon_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
 extern long radeon_kms_compat_ioctl(struct file *filp, unsigned int cmd,
@@ -415,6 +416,7 @@ static struct drm_driver kms_driver = {
.gem_prime_export = drm_gem_prime_export,
.gem_prime_import = drm_gem_prime_import,
.gem_prime_pin = radeon_gem_prime_pin,
+   .gem_prime_unpin = radeon_gem_prime_unpin,
.gem_prime_get_sg_table = radeon_gem_prime_get_sg_table,
.gem_prime_import_sg_table = radeon_gem_prime_import_sg_table,
.gem_prime_vmap = radeon_gem_prime_vmap,
diff --git a/drivers/gpu/drm/radeon/radeon_prime.c 
b/drivers/gpu/drm/radeon/radeon_prime.c
index 4940af7..e557da5 100644
--- a/drivers/gpu/drm/radeon/radeon_prime.c
+++ b/drivers/gpu/drm/radeon/radeon_prime.c
@@ -88,10 +88,20 @@ int radeon_gem_prime_pin(struct drm_gem_object *obj)

/* pin buffer into GTT */
ret = radeon_bo_pin(bo, RADEON_GEM_DOMAIN_GTT, NULL);
-   if (ret) {
-   radeon_bo_unreserve(bo);
-   return ret;
-   }
+   radeon_bo_unreserve(bo);
+   return ret;
+}
+
+void radeon_gem_prime_unpin(struct drm_gem_object *obj)
+{
+   struct radeon_bo *bo = gem_to_radeon_bo(obj);
+   int ret = 0;
+
+   ret = radeon_bo_reserve(bo, false);
+   if (unlikely(ret != 0))
+   return;
+
+   radeon_bo_unpin(bo);
radeon_bo_unreserve(bo);

return 0;
-- 
1.8.2

[PATCH 2/7] drm: move pinning/unpinning to buffer attach

[Maarten Lankhorst]

This allows importing bo's to own device to work without requiring that the 
buffer is pinned in GART.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_prime.c | 41 ++---
 1 file changed, 26 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 85bbc52..16b302a 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -63,6 +63,29 @@ struct drm_prime_member {
uint32_t handle;
 };

+static int drm_gem_map_attach(struct dma_buf *dma_buf,
+ struct device *target_dev,
+ struct dma_buf_attachment *attach)
+{
+   struct drm_gem_object *obj = dma_buf->priv;
+   struct drm_device *dev = obj->dev;
+
+   if (!dev->driver->gem_prime_pin)
+   return 0;
+
+   return dev->driver->gem_prime_pin(obj);
+}
+
+static void drm_gem_map_detach(struct dma_buf *dma_buf,
+  struct dma_buf_attachment *attach)
+{
+   struct drm_gem_object *obj = dma_buf->priv;
+   struct drm_device *dev = obj->dev;
+
+   if (dev->driver->gem_prime_unpin)
+   dev->driver->gem_prime_unpin(obj);
+}
+
 static struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach,
enum dma_data_direction dir)
 {
@@ -91,13 +114,10 @@ static void drm_gem_unmap_dma_buf(struct 
dma_buf_attachment *attach,
 static void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
 {
struct drm_gem_object *obj = dma_buf->priv;
-   struct drm_device *dev = obj->dev;

if (obj->export_dma_buf == dma_buf) {
/* drop the reference on the export fd holds */
obj->export_dma_buf = NULL;
-   if (dev->driver->gem_prime_unpin)
-   dev->driver->gem_prime_unpin(obj);
drm_gem_object_unreference_unlocked(obj);
}
 }
@@ -148,6 +168,8 @@ static int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf,
 }

 static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =  {
+   .attach = drm_gem_map_attach,
+   .detach = drm_gem_map_detach,
.map_dma_buf = drm_gem_map_dma_buf,
.unmap_dma_buf = drm_gem_unmap_dma_buf,
.release = drm_gem_dmabuf_release,
@@ -187,19 +209,8 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops = 
 {
 struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
 struct drm_gem_object *obj, int flags)
 {
-   struct dma_buf *buf;
-
-   if (dev->driver->gem_prime_pin) {
-   int ret = dev->driver->gem_prime_pin(obj);
-   if (ret)
-   return ERR_PTR(ret);
-   }
-   buf = dma_buf_export(obj, _gem_prime_dmabuf_ops, obj->size,
+   return dma_buf_export(obj, _gem_prime_dmabuf_ops, obj->size,
 0600);
-
-   if (IS_ERR(buf) && dev->driver->gem_prime_unpin)
-   dev->driver->gem_prime_unpin(obj);
-   return buf;
 }
 EXPORT_SYMBOL(drm_gem_prime_export);

-- 
1.8.2

[PATCH 1/7] drm: add unpin function to prime helpers

[Maarten Lankhorst]

Prevents buffers from being pinned forever.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_prime.c | 13 +++--
 include/drm/drmP.h  |  1 +
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 366910d..85bbc52 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -91,10 +91,13 @@ static void drm_gem_unmap_dma_buf(struct dma_buf_attachment 
*attach,
 static void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
 {
struct drm_gem_object *obj = dma_buf->priv;
+   struct drm_device *dev = obj->dev;

if (obj->export_dma_buf == dma_buf) {
/* drop the reference on the export fd holds */
obj->export_dma_buf = NULL;
+   if (dev->driver->gem_prime_unpin)
+   dev->driver->gem_prime_unpin(obj);
drm_gem_object_unreference_unlocked(obj);
}
 }
@@ -184,13 +187,19 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops 
=  {
 struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
 struct drm_gem_object *obj, int flags)
 {
+   struct dma_buf *buf;
+
if (dev->driver->gem_prime_pin) {
int ret = dev->driver->gem_prime_pin(obj);
if (ret)
return ERR_PTR(ret);
}
-   return dma_buf_export(obj, _gem_prime_dmabuf_ops, obj->size,
- 0600);
+   buf = dma_buf_export(obj, _gem_prime_dmabuf_ops, obj->size,
+0600);
+
+   if (IS_ERR(buf) && dev->driver->gem_prime_unpin)
+   dev->driver->gem_prime_unpin(obj);
+   return buf;
 }
 EXPORT_SYMBOL(drm_gem_prime_export);

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 2d94d74..99dc622 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -932,6 +932,7 @@ struct drm_driver {
struct dma_buf *dma_buf);
/* low-level interface used by drm_gem_prime_{import,export} */
int (*gem_prime_pin)(struct drm_gem_object *obj);
+   void (*gem_prime_unpin)(struct drm_gem_object *obj);
struct sg_table *(*gem_prime_get_sg_table)(struct drm_gem_object *obj);
struct drm_gem_object *(*gem_prime_import_sg_table)(
struct drm_device *dev, size_t size,
-- 
1.8.2

[Bug 63090] mesa 9.2git: qvdpautest fails to work with UVD but also fails with shader decoding

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

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

--- Comment #1 from ryszardzonk at yahoo.com ---
I have same platform as Arkadiusz [E-350] and I can confirm his results of 53
frames/s. 

software used:
Kernel 3.9-rc6 + drm uvd patches
libdrm Git 08.04.2013
xorg-server 1.13.3
Mesa Git 08.04.2013 + uvd patch

On the other hand mplayer -vo vdpau was not enough to get smooth playback of
H264 content. I had to specify "mplayer -vo vdpau -vc ffh264vdpau" with perfect
results. Using standard combination of "mplayer -vo vdpau -vc
ffmpeg12vdpau,ffvc1vdpau,ffh264vdpau,ffodivxvdpau" on the H264 content made
mplayer use ffmpeg12vdpau which resulted in jerky playback. 
Using XBMC from FernetMenta tree https://github.com/FernetMenta/xbmc which has
number of vdpau playback fixes resulted in jerky playback for high bitrate
content at 1920 at 1080.

As of VC1 content any player I used created either dark screen with green
artifacts at playback

Please let me know if You need any logs (dmesg/Xorg/lspci) or configs
(kernel/Xorg) or any other for that 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/20130409/f41dd152/attachment.html>

[PATCH] drm/radeon: add ring working query

[Alex Deucher]

On Tue, Apr 9, 2013 at 1:10 PM, Christian K?nig  
wrote:
> Am 09.04.2013 16:26, schrieb Alex Deucher:
>
>> On Tue, Apr 9, 2013 at 10:13 AM, Jerome Glisse  wrote:
>>>
>>> On Tue, Apr 9, 2013 at 8:44 AM, Christian K?nig 
>>> wrote:

 From: Christian K?nig 

 Add new ioctl option and bumb minor version number.
>>>
>>>
>>> I already have the tiling patch that bump the version, but i think it's
>>> just a matter for Alex.
>>
>> I'll take care of it.
>
>
> IIRC we also have another internal patch that wants to bumb the version
> number.
>
> Alex could you start with a drm-next-3.10 branch and try to merge all that
> stuff?

Yes, I'm working on a 3.10 branch today.  I'll post it as soon as I've
finished merging everything.

Alex

>
> Thanks,
> Christian.
>
>> Alex
>>
>>> Reviewed-by: Jerome Glisse 
>>>

 Signed-off-by: Christian K?nig 
 ---
   drivers/gpu/drm/radeon/radeon_drv.c |2 +-
   drivers/gpu/drm/radeon/radeon_kms.c |   17 +
   include/uapi/drm/radeon_drm.h   |2 ++
   3 files changed, 20 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
 b/drivers/gpu/drm/radeon/radeon_drv.c
 index 66a7f0f..31b193b 100644
 --- a/drivers/gpu/drm/radeon/radeon_drv.c
 +++ b/drivers/gpu/drm/radeon/radeon_drv.c
 @@ -73,7 +73,7 @@
*   2.30.0 - fix for FMASK texturing
*/
   #define KMS_DRIVER_MAJOR   2
 -#define KMS_DRIVER_MINOR   30
 +#define KMS_DRIVER_MINOR   31
   #define KMS_DRIVER_PATCHLEVEL  0
   int radeon_driver_load_kms(struct drm_device *dev, unsigned long
 flags);
   int radeon_driver_unload_kms(struct drm_device *dev);
 diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
 b/drivers/gpu/drm/radeon/radeon_kms.c
 index 3019759..8cb9d12 100644
 --- a/drivers/gpu/drm/radeon/radeon_kms.c
 +++ b/drivers/gpu/drm/radeon/radeon_kms.c
 @@ -376,6 +376,23 @@ int radeon_info_ioctl(struct drm_device *dev, void
 *data, struct drm_file *filp)
  else
  return -EINVAL;
  break;
 +   case RADEON_INFO_RING_WORKING:
 +   switch (value) {
 +   case RADEON_CS_RING_GFX:
 +   case RADEON_CS_RING_COMPUTE:
 +   value =
 rdev->ring[RADEON_RING_TYPE_GFX_INDEX]..ready;

 +   break;
 +   case RADEON_CS_RING_DMA:
 +   value =
 rdev->ring[R600_RING_TYPE_DMA_INDEX].ready;
 +   value |=
 rdev->ring[CAYMAN_RING_TYPE_DMA1_INDEX].ready;
 +   break;
 +   case RADEON_CS_RING_UVD:
 +   value =
 rdev->ring[R600_RING_TYPE_UVD_INDEX].ready;
 +   break;
 +   default:
 +   return -EINVAL;
 +   }
 +   break;
  default:
  DRM_DEBUG_KMS("Invalid request %d\n", info->request);
  return -EINVAL;
 diff --git a/include/uapi/drm/radeon_drm.h
 b/include/uapi/drm/radeon_drm..h

 index cd085d1..8459415 100644
 --- a/include/uapi/drm/radeon_drm.h
 +++ b/include/uapi/drm/radeon_drm.h
 @@ -973,6 +973,8 @@ struct drm_radeon_cs {
   #define RADEON_INFO_MAX_SE 0x12
   /* max SH per SE */
   #define RADEON_INFO_MAX_SH_PER_SE  0x13
 +/* query if a RADEON_CS_RING_* submission is supported */
 +#define RADEON_INFO_RING_WORKING   0x14

   struct drm_radeon_info {
  uint32_trequest;
 --
 1.7.9.5

 ___
 dri-devel mailing list
 dri-devel at lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>>>
>>>
>>> ___
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>> On Tue, Apr 9, 2013 at 10:13 AM, Jerome Glisse  wrote:
>>>
>>> On Tue, Apr 9, 2013 at 8:44 AM, Christian K?nig 
>>> wrote:

 From: Christian K?nig 

 Add new ioctl option and bumb minor version number.
>>>
>>>
>>> I already have the tiling patch that bump the version, but i think it's
>>> just
>>> a matter for Alex.
>>>
>>> Reviewed-by: Jerome Glisse 
>>>

 Signed-off-by: Christian K?nig 
 ---
   drivers/gpu/drm/radeon/radeon_drv.c |2 +-
   drivers/gpu/drm/radeon/radeon_kms.c |   17 +
   include/uapi/drm/radeon_drm.h   |2 ++
   3 files changed, 20 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
 b/drivers/gpu/drm/radeon/radeon_drv.c
 index 66a7f0f..31b193b 100644
 --- a/drivers/gpu/drm/radeon/radeon_drv.c
 +++ 

[Bug 62997] Crashes on ARUBA unless R600_DEBUG=nodma

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

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

--- Comment #7 from Alex Deucher  ---
This may be related to bug 62959.  Does attachment 72794 (kernel patch) fix the
issue?

-- 
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/20130409/959ef6c6/attachment.html>

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

[Paul Menzel]

Am Montag, den 08.04.2013, 13:37 -0400 schrieb j.glisse at gmail.com:
> From: Jerome Glisse 

Could you add the commit adding these definitions to the commit message,
please?

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

[?]


Thanks,

Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130409/144f7d83/attachment.pgp>

[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 #23 from Alex Deucher  ---
(In reply to comment #22)
> It seems running kernel 3.9-rc6 with attachment 72794 [details] [review]
> with latest mesa (UMAD fixed on Cayman, thanks to commit pushed by Marek)
> allowed me to run all r600 piglit tests without any issue.

Great.  I'll add that patch to my queue and also a similar patch for SI.

-- 
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/20130409/2626be5c/attachment.html>

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

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

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #62 from Alex Deucher  ---
At this point these are all core kernel changes being discussed and have
nothing to do with the radeon driver.  Closing.

-- 
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/20130409/82cb5565/attachment.html>

Status of exporting an fbdev framebuffer with dma_buf?

[Tom Cooksey]

Hi All,

Last year Laurent posted an RFC patch[i] to add support for exporting an fbdev 
framebuffer through
dma_buf. Looking through the mailing list archives, it doesn't appear to have 
progressed beyond an
RFC? What would be needed to get this merged? It would be useful for our Mali 
T6xx driver (which
supports importing dma_buf buffers) to allow the GPU to draw directly into the 
framebuffer on
platforms which lack a DRM/KMS driver.

[i] Subject: "[RFC/PATCH] fb: Add dma-buf support", sent 20/06/2012.


Cheers,

Tom

[PATCH] drm/radeon: add ring working query

[Alex Deucher]

On Tue, Apr 9, 2013 at 10:13 AM, Jerome Glisse  wrote:
>
> On Tue, Apr 9, 2013 at 8:44 AM, Christian K?nig  
> wrote:
>>
>> From: Christian K?nig 
>>
>> Add new ioctl option and bumb minor version number.
>
>
> I already have the tiling patch that bump the version, but i think it's just 
> a matter for Alex.

I'll take care of it.

Alex

>
> Reviewed-by: Jerome Glisse 
>
>>
>>
>> Signed-off-by: Christian K?nig 
>> ---
>>  drivers/gpu/drm/radeon/radeon_drv.c |2 +-
>>  drivers/gpu/drm/radeon/radeon_kms.c |   17 +
>>  include/uapi/drm/radeon_drm.h   |2 ++
>>  3 files changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c 
>> b/drivers/gpu/drm/radeon/radeon_drv.c
>> index 66a7f0f..31b193b 100644
>> --- a/drivers/gpu/drm/radeon/radeon_drv.c
>> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
>> @@ -73,7 +73,7 @@
>>   *   2.30.0 - fix for FMASK texturing
>>   */
>>  #define KMS_DRIVER_MAJOR   2
>> -#define KMS_DRIVER_MINOR   30
>> +#define KMS_DRIVER_MINOR   31
>>  #define KMS_DRIVER_PATCHLEVEL  0
>>  int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
>>  int radeon_driver_unload_kms(struct drm_device *dev);
>> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
>> b/drivers/gpu/drm/radeon/radeon_kms.c
>> index 3019759..8cb9d12 100644
>> --- a/drivers/gpu/drm/radeon/radeon_kms.c
>> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
>> @@ -376,6 +376,23 @@ int radeon_info_ioctl(struct drm_device *dev, void 
>> *data, struct drm_file *filp)
>> else
>> return -EINVAL;
>> break;
>> +   case RADEON_INFO_RING_WORKING:
>> +   switch (value) {
>> +   case RADEON_CS_RING_GFX:
>> +   case RADEON_CS_RING_COMPUTE:
>> +   value = rdev->ring[RADEON_RING_TYPE_GFX_INDEX].ready;
>> +   break;
>> +   case RADEON_CS_RING_DMA:
>> +   value = rdev->ring[R600_RING_TYPE_DMA_INDEX].ready;
>> +   value |= 
>> rdev->ring[CAYMAN_RING_TYPE_DMA1_INDEX].ready;
>> +   break;
>> +   case RADEON_CS_RING_UVD:
>> +   value = rdev->ring[R600_RING_TYPE_UVD_INDEX].ready;
>> +   break;
>> +   default:
>> +   return -EINVAL;
>> +   }
>> +   break;
>> default:
>> DRM_DEBUG_KMS("Invalid request %d\n", info->request);
>> return -EINVAL;
>> diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
>> index cd085d1..8459415 100644
>> --- a/include/uapi/drm/radeon_drm.h
>> +++ b/include/uapi/drm/radeon_drm.h
>> @@ -973,6 +973,8 @@ struct drm_radeon_cs {
>>  #define RADEON_INFO_MAX_SE 0x12
>>  /* max SH per SE */
>>  #define RADEON_INFO_MAX_SH_PER_SE  0x13
>> +/* query if a RADEON_CS_RING_* submission is supported */
>> +#define RADEON_INFO_RING_WORKING   0x14
>>
>>  struct drm_radeon_info {
>> uint32_trequest;
>> --
>> 1.7.9.5
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

On Tue, Apr 9, 2013 at 10:13 AM, Jerome Glisse  wrote:
> On Tue, Apr 9, 2013 at 8:44 AM, Christian K?nig 
> wrote:
>>
>> From: Christian K?nig 
>>
>> Add new ioctl option and bumb minor version number.
>
>
> I already have the tiling patch that bump the version, but i think it's just
> a matter for Alex.
>
> Reviewed-by: Jerome Glisse 
>
>>
>>
>> Signed-off-by: Christian K?nig 
>> ---
>>  drivers/gpu/drm/radeon/radeon_drv.c |2 +-
>>  drivers/gpu/drm/radeon/radeon_kms.c |   17 +
>>  include/uapi/drm/radeon_drm.h   |2 ++
>>  3 files changed, 20 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
>> b/drivers/gpu/drm/radeon/radeon_drv.c
>> index 66a7f0f..31b193b 100644
>> --- a/drivers/gpu/drm/radeon/radeon_drv.c
>> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
>> @@ -73,7 +73,7 @@
>>   *   2.30.0 - fix for FMASK texturing
>>   */
>>  #define KMS_DRIVER_MAJOR   2
>> -#define KMS_DRIVER_MINOR   30
>> +#define KMS_DRIVER_MINOR   31
>>  #define KMS_DRIVER_PATCHLEVEL  0
>>  int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
>>  int radeon_driver_unload_kms(struct drm_device *dev);
>> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
>> b/drivers/gpu/drm/radeon/radeon_kms.c
>> index 3019759..8cb9d12 100644
>> --- a/drivers/gpu/drm/radeon/radeon_kms.c
>> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
>> @@ -376,6 +376,23 @@ int radeon_info_ioctl(struct drm_device *dev, void
>> *data, struct drm_file *filp)
>>   

[PATCH 3/7] drm/radeon: implement unpin function

[Jerome Glisse]

On Tue, Apr 9, 2013 at 7:37 AM, Maarten Lankhorst
wrote:

> Signed-off-by: Maarten Lankhorst 
>

Can userspace pin directly ? If so then that sounds as a bad idea.

Reviewed-by: Jerome Glisse 


> ---
>  drivers/gpu/drm/radeon/radeon_drv.c   |  2 ++
>  drivers/gpu/drm/radeon/radeon_prime.c | 18 ++
>  2 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 66a7f0f..6800c5e 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -124,6 +124,7 @@ struct drm_gem_object
> *radeon_gem_prime_import_sg_table(struct drm_device *dev,
> size_t size,
> struct sg_table
> *sg);
>  int radeon_gem_prime_pin(struct drm_gem_object *obj);
> +void radeon_gem_prime_unpin(struct drm_gem_object *obj);
>  void *radeon_gem_prime_vmap(struct drm_gem_object *obj);
>  void radeon_gem_prime_vunmap(struct drm_gem_object *obj, void *vaddr);
>  extern long radeon_kms_compat_ioctl(struct file *filp, unsigned int cmd,
> @@ -415,6 +416,7 @@ static struct drm_driver kms_driver = {
> .gem_prime_export = drm_gem_prime_export,
> .gem_prime_import = drm_gem_prime_import,
> .gem_prime_pin = radeon_gem_prime_pin,
> +   .gem_prime_unpin = radeon_gem_prime_unpin,
> .gem_prime_get_sg_table = radeon_gem_prime_get_sg_table,
> .gem_prime_import_sg_table = radeon_gem_prime_import_sg_table,
> .gem_prime_vmap = radeon_gem_prime_vmap,
> diff --git a/drivers/gpu/drm/radeon/radeon_prime.c
> b/drivers/gpu/drm/radeon/radeon_prime.c
> index 4940af7..e557da5 100644
> --- a/drivers/gpu/drm/radeon/radeon_prime.c
> +++ b/drivers/gpu/drm/radeon/radeon_prime.c
> @@ -88,10 +88,20 @@ int radeon_gem_prime_pin(struct drm_gem_object *obj)
>
> /* pin buffer into GTT */
> ret = radeon_bo_pin(bo, RADEON_GEM_DOMAIN_GTT, NULL);
> -   if (ret) {
> -   radeon_bo_unreserve(bo);
> -   return ret;
> -   }
> +   radeon_bo_unreserve(bo);
> +   return ret;
> +}
> +
> +void radeon_gem_prime_unpin(struct drm_gem_object *obj)
> +{
> +   struct radeon_bo *bo = gem_to_radeon_bo(obj);
> +   int ret = 0;
> +
> +   ret = radeon_bo_reserve(bo, false);
> +   if (unlikely(ret != 0))
> +   return;
> +
> +   radeon_bo_unpin(bo);
> radeon_bo_unreserve(bo);
>
> return 0;
> --
> 1.8.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130409/4550f22b/attachment-0001.html>

[PATCH] drm/radeon: add ring working query

[Jerome Glisse]

On Tue, Apr 9, 2013 at 8:44 AM, Christian K?nig wrote:

> From: Christian K?nig 
>
> Add new ioctl option and bumb minor version number.
>

I already have the tiling patch that bump the version, but i think it's
just a matter for Alex.

Reviewed-by: Jerome Glisse 


>
> Signed-off-by: Christian K?nig 
> ---
>  drivers/gpu/drm/radeon/radeon_drv.c |2 +-
>  drivers/gpu/drm/radeon/radeon_kms.c |   17 +
>  include/uapi/drm/radeon_drm.h   |2 ++
>  3 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 66a7f0f..31b193b 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -73,7 +73,7 @@
>   *   2.30.0 - fix for FMASK texturing
>   */
>  #define KMS_DRIVER_MAJOR   2
> -#define KMS_DRIVER_MINOR   30
> +#define KMS_DRIVER_MINOR   31
>  #define KMS_DRIVER_PATCHLEVEL  0
>  int radeon_driver_load_kms(struct drm_device *dev, unsigned long flags);
>  int radeon_driver_unload_kms(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 3019759..8cb9d12 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -376,6 +376,23 @@ int radeon_info_ioctl(struct drm_device *dev, void
> *data, struct drm_file *filp)
> else
> return -EINVAL;
> break;
> +   case RADEON_INFO_RING_WORKING:
> +   switch (value) {
> +   case RADEON_CS_RING_GFX:
> +   case RADEON_CS_RING_COMPUTE:
> +   value =
> rdev->ring[RADEON_RING_TYPE_GFX_INDEX].ready;
> +   break;
> +   case RADEON_CS_RING_DMA:
> +   value = rdev->ring[R600_RING_TYPE_DMA_INDEX].ready;
> +   value |=
> rdev->ring[CAYMAN_RING_TYPE_DMA1_INDEX].ready;
> +   break;
> +   case RADEON_CS_RING_UVD:
> +   value = rdev->ring[R600_RING_TYPE_UVD_INDEX].ready;
> +   break;
> +   default:
> +   return -EINVAL;
> +   }
> +   break;
> default:
> DRM_DEBUG_KMS("Invalid request %d\n", info->request);
> return -EINVAL;
> diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
> index cd085d1..8459415 100644
> --- a/include/uapi/drm/radeon_drm.h
> +++ b/include/uapi/drm/radeon_drm.h
> @@ -973,6 +973,8 @@ struct drm_radeon_cs {
>  #define RADEON_INFO_MAX_SE 0x12
>  /* max SH per SE */
>  #define RADEON_INFO_MAX_SH_PER_SE  0x13
> +/* query if a RADEON_CS_RING_* submission is supported */
> +#define RADEON_INFO_RING_WORKING   0x14
>
>  struct drm_radeon_info {
> uint32_trequest;
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130409/99739f55/attachment.html>

[PATCH 0/7] i.MX53 IPU + TVE patches

[Philipp Zabel]

Hi Greg,

Am Montag, den 08.04.2013, 10:40 -0700 schrieb Greg Kroah-Hartman:
> On Mon, Apr 08, 2013 at 06:04:31PM +0200, Philipp Zabel wrote:
> > Hi,
> > 
> > the following patches allow to use the integrated Television Encoder
> > (TVEv2) on the i.MX53 SoC as VGA output encoder for the IPU. This is
> > useful for the Freescale i.MX53-QSB and TQ MBa53 boards, which have
> > VGA and DVI-I connectors, respectively.
> > 
> > regards
> > Philipp
> > 
> > ---
> >  drivers/staging/imx-drm/Kconfig |   7 +
> >  drivers/staging/imx-drm/Makefile|   1 +
> >  drivers/staging/imx-drm/imx-drm-core.c  |  15 +-
> >  drivers/staging/imx-drm/imx-drm.h   |  14 +-
> >  drivers/staging/imx-drm/imx-tve.c   | 755 
> > 
> >  drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h |   3 +
> >  drivers/staging/imx-drm/ipu-v3/ipu-dc.c |  55 +-
> >  drivers/staging/imx-drm/ipu-v3/ipu-di.c | 100 +++-
> >  drivers/staging/imx-drm/ipuv3-crtc.c|  11 +-
> >  9 files changed, 932 insertions(+), 29 deletions(-)
> 
> That's a lot of new features being added here, yet no work seems to be
> happening to move this out of the staging tree.  What is left to do
> here, and why isn't that being worked on first, before stuff like this?

the IPU code could still use a bit of testing, and I hope adding
features like VGA output on common development boards will increase the
amount of scrutiny this code will get.
I expect the structure of the IPU drivers to change when the common
display framework gets introduced at last, also requiring changes to the
device tree bindings, and I'm a bit reluctant to push for mainline
proper while the bindings are still not clear.

regards
Philipp

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

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

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

--- Comment #61 from Ludovic Watteaux  ---
Work again on Linux 3.9.0-rc6 without patch.

-- 
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/20130409/5b234fcf/attachment-0001.html>

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

[Michel Dänzer]

On Mon, 2013-04-08 at 13:37 -0400, j.glisse at gmail.com wrote: 
> From: Jerome Glisse 
> 
> Signed-off-by: Jerome Glisse 

For the series:

Reviewed-by: Michel D?nzer  

-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

[PATCH] drm/omap: Take a fb reference in omap_plane_update()

[Rob Clark]

On Tue, Apr 9, 2013 at 8:53 AM, Daniel Vetter  wrote:
> On Tue, Apr 09, 2013 at 05:56:02PM +0530, Archit Taneja wrote:
>> When userspace calls SET_PLANE ioctl, drm core takes a reference of the fb 
>> and
>> passes control to the update_plane op defined by the drm driver.
>>
>> In omapdrm, we have a worker thread which queues framebuffers objects 
>> received
>> from update_plane and displays them at the appropriate time.
>>
>> It is possible that the framebuffer is destoryed by userspace between the 
>> time
>> of calling the ioctl and apply-worker being scheduled. If this happens, the
>> apply-worker holds a pointer to a framebuffer which is already destroyed.
>>
>> Take an extra refernece/unreference of the fb in omap_plane_update() to 
>> prevent
>> this from happening. A reference is taken of the fb passed to update_plane(),
>> the previous framebuffer (held by plane->fb) is unreferenced. This will 
>> prevent
>> drm from destroying the framebuffer till the time it's unreferenced by the
>> apply-worker.
>>
>> This is in addition to the exisitng reference/unreference in update_pin(),
>> which is taken for the scanout of the plane's current framebuffer, and an
>> unreference the previous framebuffer.
>>
>> Signed-off-by: Archit Taneja 
>> Cc: Rob Clark 
>> ---
>>  drivers/gpu/drm/omapdrm/omap_plane.c |6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
>> b/drivers/gpu/drm/omapdrm/omap_plane.c
>> index 2882cda..8d225d7 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
>> @@ -247,6 +247,12 @@ static int omap_plane_update(struct drm_plane *plane,
>>  {
>>   struct omap_plane *omap_plane = to_omap_plane(plane);
>>   omap_plane->enabled = true;
>> +
>> + if (plane->fb)
>> + drm_framebuffer_unreference(plane->fb);
>
> Shouldn't the unref only happen once the flip has completed? Otherwise we
> might free the memory which is still being scanned out and put some other
> crap there.

yup, there is a 2nd ref grabbed when we start scanout and dropped when
we finish scanout..  so that part was already covered.  What wasn't
covered before was the time between the ioctl and the worker thread
(which was grabbing/dropping the scanout ref)

BR,
-R

> Note that I've been too lazy to read the code, but I expected the unref of
> the old one to happen after the ref-taking for the new one, with a vblank
> wait/delay in between ... Might be that I'm completely off ;-)
> -Daniel
>
>> +
>> + drm_framebuffer_reference(fb);
>> +
>>   return omap_plane_mode_set(plane, crtc, fb,
>>   crtc_x, crtc_y, crtc_w, crtc_h,
>>   src_x, src_y, src_w, src_h,
>> --
>> 1.7.10.4
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/nouveau: idle all channels before suspending

[Ben Skeggs]

On Mon, Apr 8, 2013 at 10:04 PM, Maarten Lankhorst <
maarten.lankhorst at canonical.com> wrote:

> Seems to make suspend slightly more reliable on my system.
>
NACK.

"Seems to", and "slightly" don't make a very good argument for this.
 Likely all you've done is change the timing of certain things happening.

The PFIFO and engine (PGRAPH etc) modules already take care of idling and
unloading active channels.  If something is broken there, that's where it
needs fixing, not this hack that "maybe" "possibly" "slightly" works.

Ben.


> Cc: stable at vger.kernel.org [3.7+]
> Signed-off-by: Maarten Lankhorst 
> ---
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index b6bdc9f..5032c31 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -464,6 +464,23 @@ nouveau_do_suspend(struct drm_device *dev)
> NV_INFO(drm, "evicting buffers...\n");
> ttm_bo_evict_mm(>ttm.bdev, TTM_PL_VRAM);
>
> +   list_for_each_entry(cli, >clients, head) {
> +   struct nouveau_abi16 *abi16 = cli->abi16;
> +   struct nouveau_abi16_chan *chan;
> +
> +   if (!abi16)
> +   continue;
> +
> +   list_for_each_entry(chan, >channels, head)
> +   nouveau_channel_idle(chan->chan);
> +   }
> +
> +   if (drm->channel)
> +   nouveau_channel_idle(drm->channel);
> +
> +   if (drm->cechan)
> +   nouveau_channel_idle(drm->cechan);
> +
> if (drm->fence && nouveau_fence(drm)->suspend) {
> if (!nouveau_fence(drm)->suspend(drm))
> return -ENOMEM;
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130409/711f4be4/attachment.html>

[PATCH] drm/nouveau: idle all channels before suspending

[Maarten Lankhorst]

Op 09-04-13 01:14, Ben Skeggs schreef:
> On Mon, Apr 8, 2013 at 10:04 PM, Maarten Lankhorst <
> maarten.lankhorst at canonical.com> wrote:
>
>> Seems to make suspend slightly more reliable on my system.
>>
> NACK.
>
> "Seems to", and "slightly" don't make a very good argument for this.
>  Likely all you've done is change the timing of certain things happening.
>
> The PFIFO and engine (PGRAPH etc) modules already take care of idling and
> unloading active channels.  If something is broken there, that's where it
> needs fixing, not this hack that "maybe" "possibly" "slightly" works.
The channel idle was not for PFIFO or PGRAPH, it's for nouveau_fence suspend.
If you want to save the fence seqnos, you have to be sure that all channels are 
idle first,
or move the saving of fence seqnos until after you're done with unloading all 
the fifo engines.

~Maarten

[PATCH] drm/omap: Take a fb reference in omap_plane_update()

[Rob Clark]

On Tue, Apr 9, 2013 at 8:26 AM, Archit Taneja  wrote:
> When userspace calls SET_PLANE ioctl, drm core takes a reference of the fb and
> passes control to the update_plane op defined by the drm driver.
>
> In omapdrm, we have a worker thread which queues framebuffers objects received
> from update_plane and displays them at the appropriate time.
>
> It is possible that the framebuffer is destoryed by userspace between the time
> of calling the ioctl and apply-worker being scheduled. If this happens, the
> apply-worker holds a pointer to a framebuffer which is already destroyed.
>
> Take an extra refernece/unreference of the fb in omap_plane_update() to 
> prevent
> this from happening. A reference is taken of the fb passed to update_plane(),
> the previous framebuffer (held by plane->fb) is unreferenced. This will 
> prevent
> drm from destroying the framebuffer till the time it's unreferenced by the
> apply-worker.
>
> This is in addition to the exisitng reference/unreference in update_pin(),
> which is taken for the scanout of the plane's current framebuffer, and an
> unreference the previous framebuffer.
>
> Signed-off-by: Archit Taneja 
> Cc: Rob Clark 

Good catch

Signed-off-by: Rob Clark 

> ---
>  drivers/gpu/drm/omapdrm/omap_plane.c |6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c 
> b/drivers/gpu/drm/omapdrm/omap_plane.c
> index 2882cda..8d225d7 100644
> --- a/drivers/gpu/drm/omapdrm/omap_plane.c
> +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
> @@ -247,6 +247,12 @@ static int omap_plane_update(struct drm_plane *plane,
>  {
> struct omap_plane *omap_plane = to_omap_plane(plane);
> omap_plane->enabled = true;
> +
> +   if (plane->fb)
> +   drm_framebuffer_unreference(plane->fb);
> +
> +   drm_framebuffer_reference(fb);
> +
> return omap_plane_mode_set(plane, crtc, fb,
> crtc_x, crtc_y, crtc_w, crtc_h,
> src_x, src_y, src_w, src_h,
> --
> 1.7.10.4
>

[git pull] drm nouveau fix

[Dave Airlie]

Hi Linus,

just a spare semicolon in nouveau that caused some issues.

Dave.

The following changes since commit f011a08c804d50eeff4abf2d308cdce492f015aa:

  Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes (2013-04-08 
16:10:43 -0700)

are available in the git repository at:


  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to c9cdee17653409dedeb65c0733a253f6fe3fc7d6:

  Merge branch 'drm-nouveau-fixes-3.9' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2013-04-09 
09:28:55 +1000)



Calvin Owens (1):
  drm/nouveau: fix unconditional return waiting on memory

Dave Airlie (1):
  Merge branch 'drm-nouveau-fixes-3.9' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes

 drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

[Bug 43741] /sys/class/backlight/ is empty with AMD (ATI) Radeon HD 4350

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

https://bugzilla.kernel.org/show_bug.cgi?id=43741


Zhang Rui  changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 43276] Screen black after suspending/resuming Toshiba Satellite C675D-S7109 laptop

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

https://bugzilla.kernel.org/show_bug.cgi?id=43276


Zhang Rui  changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 42627] Hibernation fails to resume - Toshiba Satellite L755-161 notebook

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

https://bugzilla.kernel.org/show_bug.cgi?id=42627


Zhang Rui  changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 22022] 2.6.32 regression: sometimes Suspend-To-RAM causes system hangup - ATI RS480

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

https://bugzilla.kernel.org/show_bug.cgi?id=22022


Zhang Rui  changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 20432] NVIDIA GPU doesn't work if loaded at last after all other device drivers have already been loaded

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

https://bugzilla.kernel.org/show_bug.cgi?id=20432


Zhang Rui  changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 21002] external monitor don't turn on at boot

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

https://bugzilla.kernel.org/show_bug.cgi?id=21002


Zhang Rui  changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 16560] nvidia video card not working

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

https://bugzilla.kernel.org/show_bug.cgi?id=16560


Zhang Rui  changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 15120] laptop hangs up on s2disk - Lenovo thinkpad T61

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

https://bugzilla.kernel.org/show_bug.cgi?id=15120


Zhang Rui  changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

[Bug 14993] suspend-to-ram broken on my d630 since 2.6.31

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

https://bugzilla.kernel.org/show_bug.cgi?id=14993


Zhang Rui  changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 13880] repeated freezes after bios update - Toshiba Satellite L300

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

https://bugzilla.kernel.org/show_bug.cgi?id=13880


Zhang Rui  changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 13446] resume after suspend-to-ram broken on Toshiba Satellite A100 with 2.6.30-rc8 (works in 2.6.28)

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

https://bugzilla.kernel.org/show_bug.cgi?id=13446


Zhang Rui  changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 13170] Macbook 5,2 only boots with acpi=off, or nosmp, or maxcpus=1

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

https://bugzilla.kernel.org/show_bug.cgi?id=13170


Zhang Rui  changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 12778] suspend regression from 29rc5 to 29rc6

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

https://bugzilla.kernel.org/show_bug.cgi?id=12778


yury  changed:

   What|Removed |Added

 Status|NEEDINFO|CLOSED
 Resolution||INVALID

Zhang Rui  changed:

   What|Removed |Added

 Blocks||56331




--- Comment #14 from yury   2009-04-23 15:03:49 ---
after xorg/intel-driver update i have no more hangs.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 12434] Resume from suspend to RAM broken on ThinkPad R500

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

https://bugzilla.kernel.org/show_bug.cgi?id=12434


Zhang Rui  changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[Bug 10319] MacBookPro1, 1: on resume (from console) s2ram -f -p does not anymore give me my display back - 2.6.25 regression

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

https://bugzilla.kernel.org/show_bug.cgi?id=10319


Zhang Rui  changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.

[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 #22 from Alexandre Demers  ---
It seems running kernel 3.9-rc6 with attachment 72794 with latest mesa (UMAD
fixed on Cayman, thanks to commit pushed by Marek) allowed me to run all r600
piglit tests without any issue.

-- 
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/20130409/3398fa7e/attachment.html>

[PATCH] drm:exynos: Fix messages in exynos_drm_gsc.c

[Masanari Iida]

It is better to remove "occured" from messages.

Signed-off-by: Masanari Iida 
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 7841c3b..898b307 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1314,13 +1314,13 @@ static irqreturn_t gsc_irq_handler(int irq, void 
*dev_id)

status = gsc_read(GSC_IRQ);
if (status & GSC_IRQ_STATUS_OR_IRQ) {
-   dev_err(ippdrv->dev, "occured overflow at %d, status 0x%x.\n",
+   dev_err(ippdrv->dev, "overflow at %d, status 0x%x.\n",
ctx->id, status);
return IRQ_NONE;
}

if (status & GSC_IRQ_STATUS_OR_FRM_DONE) {
-   dev_dbg(ippdrv->dev, "occured frame done at %d, status 0x%x.\n",
+   dev_dbg(ippdrv->dev, "frame done at %d, status 0x%x.\n",
ctx->id, status);

buf_id[EXYNOS_DRM_OPS_SRC] = gsc_get_src_buf_index(ctx);
-- 
1.8.2.451.gbfd70c5

[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 #21 from Alexandre Demers  ---
(In reply to comment #20)
> Sorry I meant to say the "order" test hangs and is unrelated to the other
> hangs and the patches posted here won't help you with it. Anyway, I have
> committed the fix for the "order" test now.

The previous comment was a bit rough around the edge when considering my
knowledge about that bug known by dev, but no harm taken. It was...
spontaneous. ;)

Thank you for letting me know about the committed fix, I'll update mesa and
relaunch the piglit run.

-- 
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/20130409/a8266236/attachment.html>

[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 #20 from Marek Ol??k  ---
Sorry I meant to say the "order" test hangs and is unrelated to the other hangs
and the patches posted here won't help you with it. Anyway, I have committed
the fix for the "order" test now.

-- 
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/20130409/8aec4514/attachment.html>

[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 #19 from Marek Ol??k  ---
(In reply to comment #18)
> Attachment 72794 [details] applied on kernel 3.9-rc6 hangs (2 on 2) at
> spec/glsl-1.10/execution/built-in-functions/vs-max-vec2-vec2
> 
> 
> Applying [...] @@ -459,6 +459,7 @@ static int radeon_cs_ib_vm_chunk(struct
> radeon_device *rdev,
> if (r) {
> goto out;
> }
> +   radeon_fence_wait(vm->fence, false);
> radeon_cs_sync_rings(parser);
> 
> on 3.9-rc5 hangs everytime (3 on 3) on spec/EXT_transform_feedback/order
> arrays triangles

Of course it hangs the "order" test! The test triggers a bug in the shader
backend, causing an infinite loop. It has nothing to do with the virtual memory
issues. Just skip the test, we already have a fix for it on mesa-dev.

-- 
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/20130409/98e9f20d/attachment-0001.html>

[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 #18 from Alexandre Demers  ---
Attachment 72794 applied on kernel 3.9-rc6 hangs (2 on 2) at
spec/glsl-1.10/execution/built-in-functions/vs-max-vec2-vec2


Applying [...] @@ -459,6 +459,7 @@ static int radeon_cs_ib_vm_chunk(struct
radeon_device *rdev,
if (r) {
goto out;
}
+   radeon_fence_wait(vm->fence, false);
radeon_cs_sync_rings(parser);

on 3.9-rc5 hangs everytime (3 on 3) on spec/EXT_transform_feedback/order arrays
triangles


I still have to test Jerome's patches.

-- 
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/20130409/5037c893/attachment.html>

[Bug 10319] MacBookPro1, 1: on resume (from console) s2ram -f -p does not anymore give me my display back - 2.6.25 regression

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=10319


Zhang Rui rui.zh...@intel.com changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 12434] Resume from suspend to RAM broken on ThinkPad R500

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=12434


Zhang Rui rui.zh...@intel.com changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 12778] suspend regression from 29rc5 to 29rc6

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=12778


yury ury...@gmail.com changed:

   What|Removed |Added

 Status|NEEDINFO|CLOSED
 Resolution||INVALID

Zhang Rui rui.zh...@intel.com changed:

   What|Removed |Added

 Blocks||56331




--- Comment #14 from yury ury...@gmail.com  2009-04-23 15:03:49 ---
after xorg/intel-driver update i have no more hangs.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 13170] Macbook 5,2 only boots with acpi=off, or nosmp, or maxcpus=1

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=13170


Zhang Rui rui.zh...@intel.com changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 13446] resume after suspend-to-ram broken on Toshiba Satellite A100 with 2.6.30-rc8 (works in 2.6.28)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=13446


Zhang Rui rui.zh...@intel.com changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 13880] repeated freezes after bios update - Toshiba Satellite L300

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=13880


Zhang Rui rui.zh...@intel.com changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 14993] suspend-to-ram broken on my d630 since 2.6.31

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=14993


Zhang Rui rui.zh...@intel.com changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 15120] laptop hangs up on s2disk - Lenovo thinkpad T61

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=15120


Zhang Rui rui.zh...@intel.com changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 16560] nvidia video card not working

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=16560


Zhang Rui rui.zh...@intel.com changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 20432] NVIDIA GPU doesn't work if loaded at last after all other device drivers have already been loaded

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=20432


Zhang Rui rui.zh...@intel.com changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 21002] external monitor don't turn on at boot

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=21002


Zhang Rui rui.zh...@intel.com changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 22022] 2.6.32 regression: sometimes Suspend-To-RAM causes system hangup - ATI RS480

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=22022


Zhang Rui rui.zh...@intel.com changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 42627] Hibernation fails to resume - Toshiba Satellite L755-161 notebook

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=42627


Zhang Rui rui.zh...@intel.com changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43276] Screen black after suspending/resuming Toshiba Satellite C675D-S7109 laptop

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=43276


Zhang Rui rui.zh...@intel.com changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43741] /sys/class/backlight/ is empty with AMD (ATI) Radeon HD 4350

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=43741


Zhang Rui rui.zh...@intel.com changed:

   What|Removed |Added

 Blocks||56331




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/nouveau: idle all channels before suspending

[Maarten Lankhorst]

Op 09-04-13 01:14, Ben Skeggs schreef:
 On Mon, Apr 8, 2013 at 10:04 PM, Maarten Lankhorst 
 maarten.lankho...@canonical.com wrote:

 Seems to make suspend slightly more reliable on my system.

 NACK.

 Seems to, and slightly don't make a very good argument for this.
  Likely all you've done is change the timing of certain things happening.

 The PFIFO and engine (PGRAPH etc) modules already take care of idling and
 unloading active channels.  If something is broken there, that's where it
 needs fixing, not this hack that maybe possibly slightly works.
The channel idle was not for PFIFO or PGRAPH, it's for nouveau_fence suspend.
If you want to save the fence seqnos, you have to be sure that all channels are 
idle first,
or move the saving of fence seqnos until after you're done with unloading all 
the fifo engines.

~Maarten

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

[git pull] drm nouveau fix

[Dave Airlie]

Hi Linus,

just a spare semicolon in nouveau that caused some issues.

Dave.

The following changes since commit f011a08c804d50eeff4abf2d308cdce492f015aa:

  Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/next-fixes (2013-04-08 
16:10:43 -0700)

are available in the git repository at:


  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to c9cdee17653409dedeb65c0733a253f6fe3fc7d6:

  Merge branch 'drm-nouveau-fixes-3.9' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes (2013-04-09 
09:28:55 +1000)



Calvin Owens (1):
  drm/nouveau: fix unconditional return waiting on memory

Dave Airlie (1):
  Merge branch 'drm-nouveau-fixes-3.9' of 
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes

 drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Michel Dänzer]

On Mon, 2013-04-08 at 13:37 -0400, j.gli...@gmail.com wrote: 
 From: Jerome Glisse jgli...@redhat.com
 
 Signed-off-by: Jerome Glisse jgli...@redhat.com

For the series:

Reviewed-by: Michel Dänzer michel.daen...@amd.com 

-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/7] i.MX53 IPU + TVE patches

[Philipp Zabel]

Hi Greg,

Am Montag, den 08.04.2013, 10:40 -0700 schrieb Greg Kroah-Hartman:
 On Mon, Apr 08, 2013 at 06:04:31PM +0200, Philipp Zabel wrote:
  Hi,
  
  the following patches allow to use the integrated Television Encoder
  (TVEv2) on the i.MX53 SoC as VGA output encoder for the IPU. This is
  useful for the Freescale i.MX53-QSB and TQ MBa53 boards, which have
  VGA and DVI-I connectors, respectively.
  
  regards
  Philipp
  
  ---
   drivers/staging/imx-drm/Kconfig |   7 +
   drivers/staging/imx-drm/Makefile|   1 +
   drivers/staging/imx-drm/imx-drm-core.c  |  15 +-
   drivers/staging/imx-drm/imx-drm.h   |  14 +-
   drivers/staging/imx-drm/imx-tve.c   | 755 
  
   drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h |   3 +
   drivers/staging/imx-drm/ipu-v3/ipu-dc.c |  55 +-
   drivers/staging/imx-drm/ipu-v3/ipu-di.c | 100 +++-
   drivers/staging/imx-drm/ipuv3-crtc.c|  11 +-
   9 files changed, 932 insertions(+), 29 deletions(-)
 
 That's a lot of new features being added here, yet no work seems to be
 happening to move this out of the staging tree.  What is left to do
 here, and why isn't that being worked on first, before stuff like this?

the IPU code could still use a bit of testing, and I hope adding
features like VGA output on common development boards will increase the
amount of scrutiny this code will get.
I expect the structure of the IPU drivers to change when the common
display framework gets introduced at last, also requiring changes to the
device tree bindings, and I'm a bit reluctant to push for mainline
proper while the bindings are still not clear.

regards
Philipp

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

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

[bugzilla-daemon]

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

--- Comment #61 from Ludovic Watteaux lucky...@free.fr ---
Work again on Linux 3.9.0-rc6 without patch.

-- 
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

Status of exporting an fbdev framebuffer with dma_buf?

[Tom Cooksey]

Hi All,

Last year Laurent posted an RFC patch[i] to add support for exporting an fbdev 
framebuffer through
dma_buf. Looking through the mailing list archives, it doesn't appear to have 
progressed beyond an
RFC? What would be needed to get this merged? It would be useful for our Mali 
T6xx driver (which
supports importing dma_buf buffers) to allow the GPU to draw directly into the 
framebuffer on
platforms which lack a DRM/KMS driver.

[i] Subject: [RFC/PATCH] fb: Add dma-buf support, sent 20/06/2012.


Cheers,

Tom





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