[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12

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

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

--- Comment #37 from Paul Menzel  ---
(In reply to comment #36)
> (In reply to comment #35)

[?]

> > I've also pushed a branch with some other DP related patches that might help
> > if you want to try it:
> > http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.14-wip
> 
> I did not tried that yet.

The Linux kernel built from your branch 3.14-wip does not work either.

-- 
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/20140117/88844391/attachment.html>

[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12

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

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

--- Comment #38 from Paul Menzel  ---
Is there a way to look at the Windows driver to know what the timing should be?

-- 
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/20140117/b35b20da/attachment-0001.html>

[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12

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

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

--- Comment #39 from Paul Menzel  ---
Once the display works, it seems to work always during consecutive off/on
cycles.

-- 
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/20140117/3762fb46/attachment.html>

[Bug 73625] rv730 agp unstable while uvd video playback

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

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

--- Comment #8 from Dieter N?tzel  ---
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Will try, but this machine is so slow
> > 
> > Can you be more specific what you did, which movie you looked?
> For example this movie most of time triger instability
> http://d-h.st/bvr

Nice BD snipping...;-)

> I do nothing special: player in full-screen mode, mouse in idle.

Tried (all) combinations.
big window (start up)
switch to full-screen
switch back
change window to smaller KDE 4.12.1 default size
switch to full-screen
switch back...

I even can 'scroll' with the mouse wheel forth and back

=> NO blocks (squares).

Linux 3.13.0-rc7
Mesa git and 10.0.2 (openSUSE 12.3)
X.org 1.15 (openSUSE 12.3, Xorg repo)
xf86-video-ati-7.2.0 (latest openSUSE 12.3, Xorg repo)

> > Did severall tests for Christian and Alex with UVD.
> > 
> > Only this "Sometimes there are visible screen corruptions (color
> > squares)...) makes me wonder. Do you get it during UVD playback or later
> > (xdm/kdm) logout?
> It is about UVD playback. I does not see any desktop corruption without GPU
> hanging. If it hangs, reboot are required in most cases, as image does not
> restored properly after gpu reset and restarting of Xorg does not help.

But I found something with your test.mkv and another .mkv file.

It seems to be that we have a start up/initialization problem with UVD (2.2,
here). When your test.mkv file is the first one after start up/login it takes
several seconds to start and I had one hang. Whole system was not dead but X. 
Sadly no log.

After running other files with UVD *.mkv (big files?) start up is somewhat
better. But slower then others (e.g. Serenity - HD DVD Trailer.mp4).

But NO squares/blocks at all.

Some redraw stuttering during switch from full-screen to (small) window and
fewer back to full-screen. Much WORSE with Glamor. Generally speaking UVD takes
much more cycles under Glamor.

Glamor (a bug/leak; glamor-0.5.1-39.14) is the culprit for my reported color
squares during logout from KDE 4.12.1. If system starts without Glamor (the X
server 1.15.0 thing, https://bugs.freedesktop.org/show_bug.cgi?id=70706 ;-) I
get NOT any such things during fade out/logout from KDE.

Last thing:

Sometimes UVD starts reliable with sound (I even can scroll with the mouse
wheel forth and back) but with empty black video window (only the white mplayer
scale during scroll).
Worst case was:
1 normal start
then 5 BAD
then OK, again...

Christian?

System:
AMD  Duron 1800 (without SSE2!) - my little one...;-)
2 GB RAM
RV730  AGP 1 GB
2 x 24" BenQ DVI 1920x1080
all SSDs

openSUSE 12.3 (plus latest devel stuff)

-- 
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/20140117/c2016298/attachment.html>

[Bug 73625] rv730 agp unstable while uvd video playback

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

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

--- Comment #9 from Dieter N?tzel  ---
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV730
Pro AGP [Radeon HD 4600 Series] (prog-if 00 [VGA controller])
Subsystem: PC Partner Limited Device 0028
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR- http://lists.freedesktop.org/archives/dri-devel/attachments/20140117/1a2f696f/attachment.html>

[Bug 73625] rv730 agp unstable while uvd video playback

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

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

--- Comment #10 from Dieter N?tzel  ---
Created attachment 92254
  --> https://bugs.freedesktop.org/attachment.cgi?id=92254&action=edit
Xorg.0.log

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

[Bug 73625] rv730 agp unstable while uvd video playback

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

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

--- Comment #11 from Dieter N?tzel  ---
Created attachment 92255
  --> https://bugs.freedesktop.org/attachment.cgi?id=92255&action=edit
dmesg-3.13.0-rc7.log

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

[Bug 73625] rv730 agp unstable while uvd video playback

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

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

--- Comment #12 from Dieter N?tzel  ---
Now I get partially some color squares:

Glamor (glamor-0.5.1-39.14)
KDE 4.12.1
kwin
GL desktop effects ON
UVD/video window on all virtual desktops (sticky)

scroll with mouse wheel through all (4 virtual desktops) GL cube

Sometimes some redraws show partially color squares, as long as I gave the
system time for full refresh...

=> system is on its limits?! 

Or glamor is in the way or need optimization.

-- 
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/20140117/100aef58/attachment-0001.html>

[Bug 66963] Rv6xx dpm problems

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

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

--- Comment #185 from Thierry Vignaud  ---
(In reply to comment #183)
> > I've issues doing it, like there's no part enough.
> > So I would like to test your latest work.
> 
> It's the same as the patch in comment 94.

I meant your drm branch. I would have loved to have a patch against
3.13~rc8. git.fo delivers at 30kb/s :-(


Anway, I'd quite a lot successes with 3.13~rc8 until yesterday evening where it
fails several time in a loop (disabled accel then freeze after resuming,
several boot failures).
I then tested your 3.14 branch that doesn't 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/20140117/f1ca3e4f/attachment.html>

Fwd: munmap_chunk(): invalid pointer in libgl1-mesa-dri_9.2.1-1

[scarp]

ibglapi.so.0.0.0
7f88a2d33000-7f88a2d34000 rw-p 00024000 08:01 6300781
/usr/lib/x86_64-linux-gnu/libglapi.so.0.0.0
7f88a2d34000-7f88a2d35000 rw-p  00:00 0 
7f88a2d35000-7f88a2d4a000 r-xp  08:01 2228268
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f88a2d4a000-7f88a2f4a000 ---p 00015000 08:01 2228268
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f88a2f4a000-7f88a2f4b000 rw-p 00015000 08:01 2228268
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f88a2f4b000-7f88a303 r-xp  08:01 6295931
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.18
7f88a303-7f88a322f000 ---p 000e5000 08:01 6295931
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.18
7f88a322f000-7f88a3237000 r--p 000e4000 08:01 6295931
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.18Aborted
-- next part --
A non-text attachment was scrubbed...
Name: glxinfo.txt.sig
Type: application/pgp-signature
Size: 543 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140117/804dc188/attachment-0001.pgp>

[Bug 49747] dpms on only works on DP0 on a hd5700

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

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

Daniel Vetter  changed:

   What|Removed |Added

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

--- Comment #20 from Daniel Vetter  ---
Just aside: It seems to mostly work nowadays. 2nd outputs still have a hard
time syncing occasionally, but that only happens every few weeks now. And a bit
of vt-switching or in bad cases another suspend cycles helps. I'll call this
resolved.

-- 
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/20140117/22a92f15/attachment.html>

[Bug 73625] rv730 agp unstable while uvd video playback

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

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

--- Comment #13 from Roman Elshin  ---
I think there are two kinds of problems here:
first: looping, corruption, black window (also have this).
and seems there are 'sleep 1; xset dpms force off' in terminal  before using
vdpau workaround for that.
second: gpu hangs, which seems to be a mesa regression after 9.2.5

> Last thing:
> 
> Sometimes UVD starts reliable with sound (I even can scroll with the mouse
> wheel forth and back) but with empty black video window (only the white
> mplayer scale during scroll).
> Worst case was:
> 1 normal start
> then 5 BAD
> then OK, again...
Did you try to set dpms off after boot before seeing that?

-- 
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/20140117/a1979dd8/attachment.html>

[PATCH v3] ACPI: Fix acpi_evaluate_object() return value check

[Jani Nikula]

On Fri, 17 Jan 2014, Yijing Wang  wrote:
> Fix acpi_evaluate_object() return value check,
> shoud acpi_status not int.

Please spellcheck.

>
> Signed-off-by: Yijing Wang 
> ---
> v2->v3: Fix compile error pointed out by Hanjun.
> v1->v2: Add CC to related subsystem MAINTAINERS
> ---
>  drivers/gpu/drm/i915/intel_acpi.c  |   24 
> ++--
>  drivers/gpu/drm/nouveau/core/subdev/mxm/base.c |9 +
>  drivers/gpu/drm/nouveau/nouveau_acpi.c |   23 +--
>  drivers/pci/pci-label.c|9 ++---
>  4 files changed, 38 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
> b/drivers/gpu/drm/i915/intel_acpi.c
> index dfff090..87e8f74 100644
> --- a/drivers/gpu/drm/i915/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/intel_acpi.c
> @@ -35,7 +35,8 @@ static int intel_dsm(acpi_handle handle, int func)
>   union acpi_object params[4];
>   union acpi_object *obj;
>   u32 result;
> - int ret = 0;
> + acpi_status status;
> + int ret;
>  
>   input.count = 4;
>   input.pointer = params;
> @@ -50,10 +51,11 @@ static int intel_dsm(acpi_handle handle, int func)
>   params[3].package.count = 0;
>   params[3].package.elements = NULL;
>  
> - ret = acpi_evaluate_object(handle, "_DSM", &input, &output);
> - if (ret) {
> - DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
> - return ret;
> + status = acpi_evaluate_object(handle, "_DSM", &input, &output);
> + if (ACPI_FAILURE(status)) {
> + DRM_DEBUG_DRIVER("failed to evaluate _DSM: %s\n",
> + acpi_format_exception(status));
> + return -EINVAL;
>   }
>  
>   obj = (union acpi_object *)output.pointer;
> @@ -141,7 +143,8 @@ static void intel_dsm_platform_mux_info(void)
>   struct acpi_object_list input;
>   union acpi_object params[4];
>   union acpi_object *pkg;
> - int i, ret;
> + acpi_status status;
> + int i;
>  
>   input.count = 4;
>   input.pointer = params;
> @@ -156,10 +159,11 @@ static void intel_dsm_platform_mux_info(void)
>   params[3].package.count = 0;
>   params[3].package.elements = NULL;
>  
> - ret = acpi_evaluate_object(intel_dsm_priv.dhandle, "_DSM", &input,
> -&output);
> - if (ret) {
> - DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
> + acpi_status = acpi_evaluate_object(intel_dsm_priv.dhandle,
> + "_DSM", &input, &output);
> + if (ACPI_FAILURE(status)) {
> + DRM_DEBUG_DRIVER("failed to evaluate _DSM: %s\n",
> + acpi_format_exception(status));
>   goto out;
>   }

In the two hunks above, one of the error paths calls
kfree(output.pointer), the other doesn't. Which one is wrong?

The fix for that should probably be a follow-up patch; this patch is

Reviewed-by: Jani Nikula 


>  
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c 
> b/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
> index 1291204..c5e7a2b 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
> @@ -114,15 +114,16 @@ mxm_shadow_dsm(struct nouveau_mxm *mxm, u8 version)
>   struct acpi_buffer retn = { ACPI_ALLOCATE_BUFFER, NULL };
>   union acpi_object *obj;
>   acpi_handle handle;
> - int ret;
> + acpi_status status;
>  
>   handle = ACPI_HANDLE(&device->pdev->dev);
>   if (!handle)
>   return false;
>  
> - ret = acpi_evaluate_object(handle, "_DSM", &list, &retn);
> - if (ret) {
> - nv_debug(mxm, "DSM MXMS failed: %d\n", ret);
> + status = acpi_evaluate_object(handle, "_DSM", &list, &retn);
> + if (ACPI_FAILURE(status)) {
> + nv_debug(mxm, "DSM MXMS failed: %s\n",
> + acpi_format_exception(status));
>   return false;
>   }
>  
> diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c 
> b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> index ba0183f..de3068b 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> @@ -82,7 +82,8 @@ static int nouveau_optimus_dsm(acpi_handle handle, int 
> func, int arg, uint32_t *
>   struct acpi_object_list input;
>   union acpi_object params[4];
>   union acpi_object *obj;
> - int i, err;
> + acpi_status status;
> + int i;
>   char args_buff[4];
>  
>   input.count = 4;
> @@ -101,10 +102,11 @@ static int nouveau_optimus_dsm(acpi_handle handle, int 
> func, int arg, uint32_t *
>   args_buff[i] = (arg >> i * 8) & 0xFF;
>   params[3].buffer.pointer = args_buff;
>  
> - err = acpi_evaluate_object(handle, "_DSM", &input, &output);
> - if (err) {
> - printk(KERN_INFO "failed to evaluate _DSM: %d\n", err);
> - return err;
> +

[Bug 73625] rv730 agp unstable while uvd video playback

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

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

--- Comment #14 from Christian K?nig  ---
I suggest you put the dpms off into your X startup script and then try to
bisect the GPU lockup first.

-- 
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/20140117/442feff0/attachment.html>

[PATCH] drm/vmwgfx: Invalidate surface on non-readback unbind

[Thomas Hellstrom]

From: Jakob Bornecrantz 

Fixes error messages in vmware.log

Signed-off-by: Jakob Bornecrantz 
Reviewed-by: Michael Banack 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 26 ++
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
index a729b20..3bb3331 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_surface.c
@@ -1043,15 +1043,19 @@ static int vmw_gb_surface_unbind(struct vmw_resource 
*res,
} *cmd1;
struct {
SVGA3dCmdHeader header;
-   SVGA3dCmdBindGBSurface body;
+   SVGA3dCmdInvalidateGBSurface body;
} *cmd2;
+   struct {
+   SVGA3dCmdHeader header;
+   SVGA3dCmdBindGBSurface body;
+   } *cmd3;
uint32_t submit_size;
uint8_t *cmd;


BUG_ON(bo->mem.mem_type != VMW_PL_MOB);

-   submit_size = sizeof(*cmd2) + (readback ? sizeof(*cmd1) : 0);
+   submit_size = sizeof(*cmd3) + (readback ? sizeof(*cmd1) : 
sizeof(*cmd2));
cmd = vmw_fifo_reserve(dev_priv, submit_size);
if (unlikely(cmd == NULL)) {
DRM_ERROR("Failed reserving FIFO space for surface "
@@ -1059,18 +1063,24 @@ static int vmw_gb_surface_unbind(struct vmw_resource 
*res,
return -ENOMEM;
}

-   cmd2 = (void *) cmd;
if (readback) {
cmd1 = (void *) cmd;
cmd1->header.id = SVGA_3D_CMD_READBACK_GB_SURFACE;
cmd1->header.size = sizeof(cmd1->body);
cmd1->body.sid = res->id;
-   cmd2 = (void *) &cmd1[1];
+   cmd3 = (void *) &cmd1[1];
+   } else {
+   cmd2 = (void *) cmd;
+   cmd2->header.id = SVGA_3D_CMD_INVALIDATE_GB_SURFACE;
+   cmd2->header.size = sizeof(cmd2->body);
+   cmd2->body.sid = res->id;
+   cmd3 = (void *) &cmd2[1];
}
-   cmd2->header.id = SVGA_3D_CMD_BIND_GB_SURFACE;
-   cmd2->header.size = sizeof(cmd2->body);
-   cmd2->body.sid = res->id;
-   cmd2->body.mobid = SVGA3D_INVALID_ID;
+
+   cmd3->header.id = SVGA_3D_CMD_BIND_GB_SURFACE;
+   cmd3->header.size = sizeof(cmd3->body);
+   cmd3->body.sid = res->id;
+   cmd3->body.mobid = SVGA3D_INVALID_ID;

vmw_fifo_commit(dev_priv, submit_size);

-- 
1.8.3.2

[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12

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

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

--- Comment #40 from Paul Menzel  ---
Created attachment 92262
  --> https://bugs.freedesktop.org/attachment.cgi?id=92262&action=edit
Picture of a wrong timing(?)

With

commit 7424173698775ad90a039d8e00cbee333de536ec
Author: Alex Deucher 
Date:   Tue Jan 14 10:45:51 2014 -0500

drm/radeon/dp: sleep after powering up the display

According to the DP 1.1 spec, the sink must power
up within 1ms.  Noticed while reviewing Thierry's
drm/dp patches.

Signed-off-by: Alex Deucher 

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index fb3ae07..ba7157a 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -671,9 +671,11 @@ static int radeon_dp_link_train_init(struct
radeon_dp_link_train_info *dp_info)
u8 tmp;

/* power up the sink */
-   if (dp_info->dpcd[0] >= 0x11)
+   if (dp_info->dpcd[0] >= 0x11) {
radeon_write_dpcd_reg(dp_info->radeon_connector,
  DP_SET_POWER, DP_SET_POWER_D0);
+   usleep_range(1000, 2000);
+   }

/* possibly enable downspread on the sink */
if (dp_info->dpcd[3] & 0x1)

I got the attached image after two xrandr off/on cycles. After the next off/on
cycle the display worked. I did not notice such a behavior in my other tests.

-- 
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/20140117/df2df85e/attachment-0001.html>

[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12

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

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

--- Comment #41 from Paul Menzel  ---
Created attachment 92264
  --> https://bugs.freedesktop.org/attachment.cgi?id=92264&action=edit
Picture of another wrong timing(?)

This morning I noticed the same behavior with the same patch.

commit 7424173698775ad90a039d8e00cbee333de536ec
Author: Alex Deucher 
Date:   Tue Jan 14 10:45:51 2014 -0500

drm/radeon/dp: sleep after powering up the display

According to the DP 1.1 spec, the sink must power
up within 1ms.  Noticed while reviewing Thierry's
drm/dp patches.

Signed-off-by: Alex Deucher 

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index fb3ae07..ba7157a 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -671,9 +671,11 @@ static int radeon_dp_link_train_init(struct
radeon_dp_link_train_info *dp_info)
u8 tmp;

/* power up the sink */
-   if (dp_info->dpcd[0] >= 0x11)
+   if (dp_info->dpcd[0] >= 0x11) {
radeon_write_dpcd_reg(dp_info->radeon_connector,
  DP_SET_POWER, DP_SET_POWER_D0);
+   usleep_range(1000, 2000);
+   }

/* possibly enable downspread on the sink */
if (dp_info->dpcd[3] & 0x1)

The attached picture was gotten after the first xrandr off/on cycle. The next
xrandr off/on cycle got the display to work too.

-- 
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/20140117/75ed33a0/attachment.html>

[Bug 73649] SIGSEGV: r600_sb::bc_parser::decode_shader()

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

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

--- Comment #2 from octoploid  ---
Created attachment 92266
  --> https://bugs.freedesktop.org/attachment.cgi?id=92266&action=edit
R600_DEBUG=ps,vs output

-- 
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/20140117/78fa815d/attachment.html>

[PULL] vmwgfx-next request 2

[Thomas Hellstrom]

Dave,

Pull request for 3.14. One not so urgent fix, One huge device update.

The pull request corresponds to the patches sent out on dri-devel, except:
[PATCH 02/33], review tag typo pointed out by Matt Turner.
[PATCH 04/33], dropped. The new surface formats are never used.

The upcoming vmware svga2 hardware version 11 will introduce the concept
of "guest backed objects" or -resources. The device will in principle
get all
of its memory from the guest, which has big advantages from the device
point of view.

This means that vmwgfx contexts, shaders and surfaces need to be backed
by guest memory in the form of buffer objects called MOBs, presumably
short for MemoryOBjects, which are bound to the device in a special way.

This patch series introduces guest backed object support. Some new IOCTLs
are added to allocate these new guest backed object, and to optionally
provide
them with a backing MOB.

There is an update to the gallium driver that comes with this update, and
it will be pushed in the near timeframe presumably to a separate mesa branch
before merged to master.

The following changes since commit c5416d661daa9ccef4f42259ad0d48e28b5f950f:

  gpu: fix qxl missing crc32_le (2014-01-14 13:08:37 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~thomash/linux tags/vmwgfx-next-2014-01-17

for you to fetch changes up to 1985f99987ff04e1bb0405101dd8e25cf1b6b037:

  drm/vmwgfx: Invalidate surface on non-readback unbind (2014-01-17
09:12:26 +0100)


Pull request of 2014-01-17


Jakob Bornecrantz (1):
  drm/vmwgfx: Invalidate surface on non-readback unbind

Thomas Hellstrom (31):
  drm/vmwgfx: Fix the driver for large dma addresses
  drm/vmwgfx: Update the svga3d register header file for new device
version
  drm/vmwgfx: Update the driver user-space interface for
guest-backed objects
  drm/vmwgfx: Replace vram_size with prim_bb_mem for calculation of
max resolution
  drm/vmwgfx: Update the svga register definition
  drm/vmwgfx: Adapt capability reporting to new hardware version
  drm/vmwgfx: Add MOB management
  drm/vmwgfx: Hook up MOBs to TTM as a separate memory type
  drm/vmwgfx: Read bounding box memory from the appropriate register
  drm/vmwgfx: Add the possibility to validate a buffer as a MOB
  drm/vmwgfx: Hook up guest-backed queries
  drm/vmwgfx: Detach backing store from its resources when it is evicted
  drm/vmwgfx: Hook up guest-backed contexts
  drm/vmwgfx: Hook up guest-backed surfaces
  drm/vmwgfx: Add guest-backed shaders
  drm/vmwgfx: Validate guest-backed shader const commands
  drm/vmwgfx: Add new unused (by user-space) commands to the verifier
  drm/vmwgfx: Enable 3D for new hardware version
  drm/vmwgfx: Fix up the vmwgfx_drv.h header for new files
  drm/vmwgfx: Extend the command verifier to handle guest-backed on
/ off
  drm/vmwgfx: Implement a buffer object synccpu ioctl.
  drm/vmwgfx: Add a parameter to get max MOB memory size
  drm/vmwgfx: Block the BIND_SHADERCONSTS command
  drm/vmwgfx: Track context bindings and scrub them upon exiting execbuf
  drm/vmwgfx: Persistent tracking of context bindings
  drm/vmwgfx: Ditch the vmw_dummy_query_bo_prepare function
  drm/vmwgfx: Use the linux DMA api also for MOBs
  drm/vmwgfx: Update otable definitions
  drm/vmwgfx: Fix surface framebuffer check for guest-backed surfaces
  drm/vmwgfx: Implement 64-bit Otable- and MOB binding v2
  drm/vmwgfx: Silence the device command verifier

Zack Rusin (1):
  drm/vmwgfx: Make sure that the multisampling is off

 drivers/gpu/drm/vmwgfx/Makefile   |   2 +-
 drivers/gpu/drm/vmwgfx/svga3d_reg.h   | 718 -
 drivers/gpu/drm/vmwgfx/svga_reg.h |  10 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c| 174 -
 drivers/gpu/drm/vmwgfx/vmwgfx_context.c   | 531 
 drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c|   8 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   | 209 --
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h   | 211 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c   | 872
+++---
 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c  | 107 +++-
 drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c   | 160 +
 drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |  15 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c |  42 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |   8 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_mob.c   | 659 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c  | 195 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_shader.c| 440 +
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c   | 467 +-
 include/uapi/drm/vmwgfx_drm.h | 261 
 19 files changed, 4716 insertions(+), 373 d

[PATCH v2] ACPI: Fix acpi_evaluate_object() return value check

[Yijing Wang]

>> diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
>> b/drivers/gpu/drm/i915/intel_acpi.c
>> index dfff090..7ea00e5 100644
>> --- a/drivers/gpu/drm/i915/intel_acpi.c
>> +++ b/drivers/gpu/drm/i915/intel_acpi.c
>> @@ -35,7 +35,7 @@ static int intel_dsm(acpi_handle handle, int func)
>>  union acpi_object params[4];
>>  union acpi_object *obj;
>>  u32 result;
>> -int ret = 0;
> 
> The 'ret' is removed, but

Ah, it's my mistake, will updata it right now, thanks!

> 
>> +acpi_status status;
>>  
>>  input.count = 4;
>>  input.pointer = params;
>> @@ -50,8 +50,8 @@ static int intel_dsm(acpi_handle handle, int func)
>>  params[3].package.count = 0;
>>  params[3].package.elements = NULL;
>>  
>> -ret = acpi_evaluate_object(handle, "_DSM", &input, &output);
>> -if (ret) {
>> +status = acpi_evaluate_object(handle, "_DSM", &input, &output);
>> +if (ACPI_FAILURE(status)) {
>>  DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
>>  return ret;
> 
> you still use it here, so you should -EINVAL or something else here.

OK

> 
>>  }
>> @@ -141,7 +141,8 @@ static void intel_dsm_platform_mux_info(void)
>>  struct acpi_object_list input;
>>  union acpi_object params[4];
>>  union acpi_object *pkg;
>> -int i, ret;
>> +acpi_status status;
>>  
>> -err = acpi_evaluate_object(handle, "_DSM", &input, &output);
>> -if (err) {
>> +status = acpi_evaluate_object(handle, "_DSM", &input, &output);
>> +if (ACPI_FAILURE(status)) {
>>  printk(KERN_INFO "failed to evaluate _DSM: %d\n", err);
>>  return err;
> 
> here too.

OK, thanks.

> 
>>  }
>> @@ -134,7 +135,7 @@ static int nouveau_dsm(acpi_handle handle, int func, int 
>> arg, uint32_t *result)
>>  struct acpi_object_list input;
>>  union acpi_object params[4];
>>  union acpi_object *obj;
>> -int err;
>> +acpi_status status;
>>  
>>  input.count = 4;
>>  input.pointer = params;
>> @@ -148,8 +149,8 @@ static int nouveau_dsm(acpi_handle handle, int func, int 
>> arg, uint32_t *result)
>>  params[3].type = ACPI_TYPE_INTEGER;
>>  params[3].integer.value = arg;
>>  
>> -err = acpi_evaluate_object(handle, "_DSM", &input, &output);
>> -if (err) {
>> +status = acpi_evaluate_object(handle, "_DSM", &input, &output);
>> +if (ACPI_FAILURE(status)) {
>>  printk(KERN_INFO "failed to evaluate _DSM: %d\n", err);
>>  return err;
> 
> and here.

thanks.

> 
>>  }
>> diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
>> index d51f45a..3c21f1b 100644
>> --- a/drivers/pci/pci-label.c
>> +++ b/drivers/pci/pci-label.c
>> @@ -213,7 +213,7 @@ dsm_get_label(acpi_handle handle, int func,
>>  union acpi_object *obj;
>>  int len = 0;
>>  
>> -int err;
>> +acpi_status status;
>>  
>>  input.count = 4;
>>  input.pointer = params;
>> @@ -228,8 +228,8 @@ dsm_get_label(acpi_handle handle, int func,
>>  params[3].package.count = 0;
>>  params[3].package.elements = NULL;
>>  
>> -err = acpi_evaluate_object(handle, "_DSM", &input, output);
>> -if (err)
>> +status = acpi_evaluate_object(handle, "_DSM", &input, output);
>> +if (ACPI_FAILURE(status))
>>  return -1;
> 
> can we return specific error such as -EINVAL instead of hard code?

I will try to add some more useful debug info here. thanks!

> 
> Thanks
> Hanjun
> 
> .
> 


-- 
Thanks!
Yijing

[PATCH v2] ACPI: Fix acpi_evaluate_object() return value check

[Yijing Wang]

Fix acpi_evaluate_object() return value check,
shoud acpi_status not int.

Signed-off-by: Yijing Wang 
---

v1->v2: Add CC to the related subsystem MAINTAINERS.

---
 drivers/gpu/drm/i915/intel_acpi.c  |   13 +++--
 drivers/gpu/drm/nouveau/core/subdev/mxm/base.c |6 +++---
 drivers/gpu/drm/nouveau/nouveau_acpi.c |   13 +++--
 drivers/pci/pci-label.c|6 +++---
 4 files changed, 20 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
b/drivers/gpu/drm/i915/intel_acpi.c
index dfff090..7ea00e5 100644
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -35,7 +35,7 @@ static int intel_dsm(acpi_handle handle, int func)
union acpi_object params[4];
union acpi_object *obj;
u32 result;
-   int ret = 0;
+   acpi_status status;

input.count = 4;
input.pointer = params;
@@ -50,8 +50,8 @@ static int intel_dsm(acpi_handle handle, int func)
params[3].package.count = 0;
params[3].package.elements = NULL;

-   ret = acpi_evaluate_object(handle, "_DSM", &input, &output);
-   if (ret) {
+   status = acpi_evaluate_object(handle, "_DSM", &input, &output);
+   if (ACPI_FAILURE(status)) {
DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
return ret;
}
@@ -141,7 +141,8 @@ static void intel_dsm_platform_mux_info(void)
struct acpi_object_list input;
union acpi_object params[4];
union acpi_object *pkg;
-   int i, ret;
+   acpi_status status;
+   int i;

input.count = 4;
input.pointer = params;
@@ -156,9 +157,9 @@ static void intel_dsm_platform_mux_info(void)
params[3].package.count = 0;
params[3].package.elements = NULL;

-   ret = acpi_evaluate_object(intel_dsm_priv.dhandle, "_DSM", &input,
+   acpi_status = acpi_evaluate_object(intel_dsm_priv.dhandle, "_DSM", 
&input,
   &output);
-   if (ret) {
+   if (ACPI_FAILURE(status)) {
DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
goto out;
}
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
index 1291204..3920943 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
@@ -114,14 +114,14 @@ mxm_shadow_dsm(struct nouveau_mxm *mxm, u8 version)
struct acpi_buffer retn = { ACPI_ALLOCATE_BUFFER, NULL };
union acpi_object *obj;
acpi_handle handle;
-   int ret;
+   acpi_status status;

handle = ACPI_HANDLE(&device->pdev->dev);
if (!handle)
return false;

-   ret = acpi_evaluate_object(handle, "_DSM", &list, &retn);
-   if (ret) {
+   status = acpi_evaluate_object(handle, "_DSM", &list, &retn);
+   if (ACPI_FAILURE(status)) {
nv_debug(mxm, "DSM MXMS failed: %d\n", ret);
return false;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c 
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index ba0183f..6f810f2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -82,7 +82,8 @@ static int nouveau_optimus_dsm(acpi_handle handle, int func, 
int arg, uint32_t *
struct acpi_object_list input;
union acpi_object params[4];
union acpi_object *obj;
-   int i, err;
+   acpi_status status;
+   int i;
char args_buff[4];

input.count = 4;
@@ -101,8 +102,8 @@ static int nouveau_optimus_dsm(acpi_handle handle, int 
func, int arg, uint32_t *
args_buff[i] = (arg >> i * 8) & 0xFF;
params[3].buffer.pointer = args_buff;

-   err = acpi_evaluate_object(handle, "_DSM", &input, &output);
-   if (err) {
+   status = acpi_evaluate_object(handle, "_DSM", &input, &output);
+   if (ACPI_FAILURE(status)) {
printk(KERN_INFO "failed to evaluate _DSM: %d\n", err);
return err;
}
@@ -134,7 +135,7 @@ static int nouveau_dsm(acpi_handle handle, int func, int 
arg, uint32_t *result)
struct acpi_object_list input;
union acpi_object params[4];
union acpi_object *obj;
-   int err;
+   acpi_status status;

input.count = 4;
input.pointer = params;
@@ -148,8 +149,8 @@ static int nouveau_dsm(acpi_handle handle, int func, int 
arg, uint32_t *result)
params[3].type = ACPI_TYPE_INTEGER;
params[3].integer.value = arg;

-   err = acpi_evaluate_object(handle, "_DSM", &input, &output);
-   if (err) {
+   status = acpi_evaluate_object(handle, "_DSM", &input, &output);
+   if (ACPI_FAILURE(status)) {
printk(KERN_INFO "failed to evaluate _DSM: %d\n", err);
return err;
}
diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-labe

[PATCH v2] ACPI: Fix acpi_evaluate_object() return value check

[Hanjun Guo]

On 2014-1-17 9:29, Yijing Wang wrote:
> Fix acpi_evaluate_object() return value check,
> shoud acpi_status not int.
> 
> Signed-off-by: Yijing Wang 
> ---
> 
> v1->v2: Add CC to the related subsystem MAINTAINERS.
> 
> ---
>  drivers/gpu/drm/i915/intel_acpi.c  |   13 +++--
>  drivers/gpu/drm/nouveau/core/subdev/mxm/base.c |6 +++---
>  drivers/gpu/drm/nouveau/nouveau_acpi.c |   13 +++--
>  drivers/pci/pci-label.c|6 +++---
>  4 files changed, 20 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
> b/drivers/gpu/drm/i915/intel_acpi.c
> index dfff090..7ea00e5 100644
> --- a/drivers/gpu/drm/i915/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/intel_acpi.c
> @@ -35,7 +35,7 @@ static int intel_dsm(acpi_handle handle, int func)
>   union acpi_object params[4];
>   union acpi_object *obj;
>   u32 result;
> - int ret = 0;

The 'ret' is removed, but

> + acpi_status status;
>  
>   input.count = 4;
>   input.pointer = params;
> @@ -50,8 +50,8 @@ static int intel_dsm(acpi_handle handle, int func)
>   params[3].package.count = 0;
>   params[3].package.elements = NULL;
>  
> - ret = acpi_evaluate_object(handle, "_DSM", &input, &output);
> - if (ret) {
> + status = acpi_evaluate_object(handle, "_DSM", &input, &output);
> + if (ACPI_FAILURE(status)) {
>   DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
>   return ret;

you still use it here, so you should -EINVAL or something else here.

>   }
> @@ -141,7 +141,8 @@ static void intel_dsm_platform_mux_info(void)
>   struct acpi_object_list input;
>   union acpi_object params[4];
>   union acpi_object *pkg;
> - int i, ret;
> + acpi_status status;
> + int i;
>  
>   input.count = 4;
>   input.pointer = params;
> @@ -156,9 +157,9 @@ static void intel_dsm_platform_mux_info(void)
>   params[3].package.count = 0;
>   params[3].package.elements = NULL;
>  
> - ret = acpi_evaluate_object(intel_dsm_priv.dhandle, "_DSM", &input,
> + acpi_status = acpi_evaluate_object(intel_dsm_priv.dhandle, "_DSM", 
> &input,
>  &output);
> - if (ret) {
> + if (ACPI_FAILURE(status)) {
>   DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
>   goto out;
>   }
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c 
> b/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
> index 1291204..3920943 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
> +++ b/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
> @@ -114,14 +114,14 @@ mxm_shadow_dsm(struct nouveau_mxm *mxm, u8 version)
>   struct acpi_buffer retn = { ACPI_ALLOCATE_BUFFER, NULL };
>   union acpi_object *obj;
>   acpi_handle handle;
> - int ret;
> + acpi_status status;
>  
>   handle = ACPI_HANDLE(&device->pdev->dev);
>   if (!handle)
>   return false;
>  
> - ret = acpi_evaluate_object(handle, "_DSM", &list, &retn);
> - if (ret) {
> + status = acpi_evaluate_object(handle, "_DSM", &list, &retn);
> + if (ACPI_FAILURE(status)) {
>   nv_debug(mxm, "DSM MXMS failed: %d\n", ret);
>   return false;
>   }
> diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c 
> b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> index ba0183f..6f810f2 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> @@ -82,7 +82,8 @@ static int nouveau_optimus_dsm(acpi_handle handle, int 
> func, int arg, uint32_t *
>   struct acpi_object_list input;
>   union acpi_object params[4];
>   union acpi_object *obj;
> - int i, err;
> + acpi_status status;
> + int i;
>   char args_buff[4];
>  
>   input.count = 4;
> @@ -101,8 +102,8 @@ static int nouveau_optimus_dsm(acpi_handle handle, int 
> func, int arg, uint32_t *
>   args_buff[i] = (arg >> i * 8) & 0xFF;
>   params[3].buffer.pointer = args_buff;
>  
> - err = acpi_evaluate_object(handle, "_DSM", &input, &output);
> - if (err) {
> + status = acpi_evaluate_object(handle, "_DSM", &input, &output);
> + if (ACPI_FAILURE(status)) {
>   printk(KERN_INFO "failed to evaluate _DSM: %d\n", err);
>   return err;

here too.

>   }
> @@ -134,7 +135,7 @@ static int nouveau_dsm(acpi_handle handle, int func, int 
> arg, uint32_t *result)
>   struct acpi_object_list input;
>   union acpi_object params[4];
>   union acpi_object *obj;
> - int err;
> + acpi_status status;
>  
>   input.count = 4;
>   input.pointer = params;
> @@ -148,8 +149,8 @@ static int nouveau_dsm(acpi_handle handle, int func, int 
> arg, uint32_t *result)
>   params[3].type = ACPI_TYPE_INTEGER;
>   params[3].integer.value = arg;
>  
> - err = acpi_evaluate_object(handle, "_DSM", &input, &output);
> - if (err) {
> + st

[PATCH v3] ACPI: Fix acpi_evaluate_object() return value check

[Yijing Wang]

Fix acpi_evaluate_object() return value check,
shoud acpi_status not int.

Signed-off-by: Yijing Wang 
---
v2->v3: Fix compile error pointed out by Hanjun.
v1->v2: Add CC to related subsystem MAINTAINERS
---
 drivers/gpu/drm/i915/intel_acpi.c  |   24 ++--
 drivers/gpu/drm/nouveau/core/subdev/mxm/base.c |9 +
 drivers/gpu/drm/nouveau/nouveau_acpi.c |   23 +--
 drivers/pci/pci-label.c|9 ++---
 4 files changed, 38 insertions(+), 27 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
b/drivers/gpu/drm/i915/intel_acpi.c
index dfff090..87e8f74 100644
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -35,7 +35,8 @@ static int intel_dsm(acpi_handle handle, int func)
union acpi_object params[4];
union acpi_object *obj;
u32 result;
-   int ret = 0;
+   acpi_status status;
+   int ret;

input.count = 4;
input.pointer = params;
@@ -50,10 +51,11 @@ static int intel_dsm(acpi_handle handle, int func)
params[3].package.count = 0;
params[3].package.elements = NULL;

-   ret = acpi_evaluate_object(handle, "_DSM", &input, &output);
-   if (ret) {
-   DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
-   return ret;
+   status = acpi_evaluate_object(handle, "_DSM", &input, &output);
+   if (ACPI_FAILURE(status)) {
+   DRM_DEBUG_DRIVER("failed to evaluate _DSM: %s\n",
+   acpi_format_exception(status));
+   return -EINVAL;
}

obj = (union acpi_object *)output.pointer;
@@ -141,7 +143,8 @@ static void intel_dsm_platform_mux_info(void)
struct acpi_object_list input;
union acpi_object params[4];
union acpi_object *pkg;
-   int i, ret;
+   acpi_status status;
+   int i;

input.count = 4;
input.pointer = params;
@@ -156,10 +159,11 @@ static void intel_dsm_platform_mux_info(void)
params[3].package.count = 0;
params[3].package.elements = NULL;

-   ret = acpi_evaluate_object(intel_dsm_priv.dhandle, "_DSM", &input,
-  &output);
-   if (ret) {
-   DRM_DEBUG_DRIVER("failed to evaluate _DSM: %d\n", ret);
+   acpi_status = acpi_evaluate_object(intel_dsm_priv.dhandle,
+   "_DSM", &input, &output);
+   if (ACPI_FAILURE(status)) {
+   DRM_DEBUG_DRIVER("failed to evaluate _DSM: %s\n",
+   acpi_format_exception(status));
goto out;
}

diff --git a/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
index 1291204..c5e7a2b 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mxm/base.c
@@ -114,15 +114,16 @@ mxm_shadow_dsm(struct nouveau_mxm *mxm, u8 version)
struct acpi_buffer retn = { ACPI_ALLOCATE_BUFFER, NULL };
union acpi_object *obj;
acpi_handle handle;
-   int ret;
+   acpi_status status;

handle = ACPI_HANDLE(&device->pdev->dev);
if (!handle)
return false;

-   ret = acpi_evaluate_object(handle, "_DSM", &list, &retn);
-   if (ret) {
-   nv_debug(mxm, "DSM MXMS failed: %d\n", ret);
+   status = acpi_evaluate_object(handle, "_DSM", &list, &retn);
+   if (ACPI_FAILURE(status)) {
+   nv_debug(mxm, "DSM MXMS failed: %s\n",
+   acpi_format_exception(status));
return false;
}

diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c 
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index ba0183f..de3068b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -82,7 +82,8 @@ static int nouveau_optimus_dsm(acpi_handle handle, int func, 
int arg, uint32_t *
struct acpi_object_list input;
union acpi_object params[4];
union acpi_object *obj;
-   int i, err;
+   acpi_status status;
+   int i;
char args_buff[4];

input.count = 4;
@@ -101,10 +102,11 @@ static int nouveau_optimus_dsm(acpi_handle handle, int 
func, int arg, uint32_t *
args_buff[i] = (arg >> i * 8) & 0xFF;
params[3].buffer.pointer = args_buff;

-   err = acpi_evaluate_object(handle, "_DSM", &input, &output);
-   if (err) {
-   printk(KERN_INFO "failed to evaluate _DSM: %d\n", err);
-   return err;
+   status = acpi_evaluate_object(handle, "_DSM", &input, &output);
+   if (ACPI_FAILURE(status)) {
+   pr_info("failed to evaluate _DSM: %s\n",
+   acpi_format_exception(status));
+   return -EINVAL;
}

obj = (union acpi_object *)output.pointer;
@@ -134,7 +136,7 @@ static int nouveau_dsm(acpi_handle handle, int 

Query regarding initial mode setting by X server & /dev/dri/control

[Akash Hajari]

Hi Rob,

Thanks for your answer and your example
(https://github.com/robclark/kmscube/blob/master/kmscube.c). I
understood standalone KMS without x11 (as written by you @
http://lists.freedesktop.org/archives/dri-devel/2012-September/027348.html
).

But, looking at Linux Graphics stack
(http://en.wikipedia.org/wiki/File:Linux_Graphics_Stack_2013.svg), I
am confused. Does libGL calls always directly calls libDRM and never
to x-server?

If so, then how simple gl example ?drawf.c?
(http://www.glprogramming.com/red/chapter08.html) using glBitmap()
work well when x11 server running?


Also, when switching between multiple windows, x server running in
backgroung, why drm_mode_addfb (DRM_IOCTL_MODE_ADDFB) getting called
many times?
(as I think, fb might have already created for multiple windows.)

Thanks for your patience, Rob.

Akash Hajari.

On 1/14/14, Rob Clark  wrote:
> On Tue, Jan 14, 2014 at 5:15 AM, Akash Hajari 
> wrote:
>> Hi,
>> I am new to DRM & KMS and I had seen your pdf named "why & how to use kms
>> as
>> your user space display api if choice".
>> I have to understand initial mode setting  flow of x server. So is it
>> located in /xorg-server/hw/xfree86/modes/ or some where else?
>
>
> currently it is in each different DDX driver (for example,
> xf86-video-intel, xf86-video-modesetting, etc)
>
> Perhaps either tests/modetest/modetest.c (in libdrm tree) or kmscube
> (https://github.com/robclark/kmscube/blob/master/kmscube.c) might be a
> simpler stand-alone example to look at (the former does only modeset,
> the later does modeset + gl)
>
>> And, I don't know use control node. What's use of /dev/dri/control node?
>
> I don't think it is really used for much yet.. but mostly people just
> use drmOpen() in libdrm and it figures out what device file to open.
>
> BR,
> -R
>
>>
>> Akash Hajari.
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>

[Bug 73739] New: RV630 flickering on "Wargame European Escalation"

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

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

  Priority: medium
Bug ID: 73739
  Assignee: dri-devel at lists.freedesktop.org
   Summary: RV630 flickering on "Wargame European Escalation"
  Severity: normal
Classification: Unclassified
OS: All
  Reporter: karzisss at hotmail.com
  Hardware: Other
Status: NEW
   Version: git
 Component: Drivers/DRI/R600
   Product: Mesa

On Wargame European Escalation there is flickering while you play and you
select a "unit" to move.

I've tested it with following setups:

-(x)Ubuntu 13.10 stock mesa-kernel
-(x)Ubuntu 13.10 Oibaf's ppa + 3.13-RC7 kernel

-- 
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/20140117/98f25126/attachment.html>

[PATCH v3 3/4] drm/dp: Add DisplayPort link helpers

[Jani Nikula]

On Tue, 14 Jan 2014, Thierry Reding  wrote:
> Add a helper to probe a DP link (read out the supported DPCD revision,
> maximum rate, link count and capabilities) as well as power up the DP
> link and configure it accordingly.
>
> Signed-off-by: Thierry Reding 
> ---
> Changes in v3:
> - split into drm_dp_link_power_up() and drm_dp_link_configure()
> - do not change sink state for DPCD versions earlier than 1.1
> - sleep for 1-2 ms after setting local sink to D0 state
> - read and write consecutive registers where possible
> - read DPCD revision when link is probed
> - remove duplicate kerneldoc
>
>  drivers/gpu/drm/drm_dp_helper.c | 94 
> +
>  include/drm/drm_dp_helper.h | 17 
>  2 files changed, 111 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 572637456713..ac2e12789634 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -472,3 +472,97 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
>   DP_LINK_STATUS_SIZE);
>  }
>  EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
> +
> +/**
> + * drm_dp_link_probe() - probe a DisplayPort link for capabilities
> + * @aux: DisplayPort AUX channel
> + * @link: pointer to structure in which to return link capabilities
> + *
> + * The structure filled in by this function can usually be passed directly
> + * into drm_dp_link_power_up() and drm_dp_link_configure() to power up and
> + * configure the link based on the link's capabilities.
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int drm_dp_link_probe(struct drm_dp_aux *aux, struct drm_dp_link *link)
> +{
> + u8 values[3];
> + int err;
> +
> + memset(link, 0, sizeof(*link));
> +
> + err = drm_dp_dpcd_read(aux, DP_DPCD_REV, values, sizeof(values));
> + if (err < 0)
> + return err;
> +
> + link->revision = values[0];
> + link->rate = drm_dp_bw_code_to_link_rate(values[1]);
> + link->num_lanes = values[2] & DP_MAX_LANE_COUNT_MASK;
> +
> + if (values[2] & DP_ENHANCED_FRAME_CAP)
> + link->capabilities |= DP_LINK_CAP_ENHANCED_FRAMING;

Since DP_DPCD_REV == 0, you could use the #defines for the indexes (if
you're going to send another version anyway). Ditto below for
drm_dp_link_configure.

Other than that nitpick, the series looks good to me. If we face any
issues migrating i915 on top of this, we can iron them out later on.

On the series,

Reviewed-by: Jani Nikula 


> +
> + return 0;
> +}
> +
> +/**
> + * drm_dp_link_power_up() - power up a DisplayPort link
> + * @aux: DisplayPort AUX channel
> + * @link: pointer to a structure containing the link configuration
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int drm_dp_link_power_up(struct drm_dp_aux *aux, struct drm_dp_link *link)
> +{
> + u8 value;
> + int err;
> +
> + /* DP_SET_POWER register is only available on DPCD v1.1 and later */
> + if (link->revision < 0x11)
> + return 0;
> +
> + err = drm_dp_dpcd_readb(aux, DP_SET_POWER, &value);
> + if (err < 0)
> + return err;
> +
> + value &= ~DP_SET_POWER_MASK;
> + value |= DP_SET_POWER_D0;
> +
> + err = drm_dp_dpcd_writeb(aux, DP_SET_POWER, value);
> + if (err < 0)
> + return err;
> +
> + /*
> +  * According to the DP 1.1 specification, a "Sink Device must exit the
> +  * power saving state within 1 ms" (Section 2.5.3.1, Table 5-52, "Sink
> +  * Control Field" (register 0x600).
> +  */
> + usleep_range(1000, 2000);
> +
> + return 0;
> +}
> +
> +/**
> + * drm_dp_link_configure() - configure a DisplayPort link
> + * @aux: DisplayPort AUX cahnnel
> + * @link: pointer to a structure containing the link configuration
> + *
> + * Returns 0 on seccuss or a negative error code on failure.
> + */
> +int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link)
> +{
> + u8 values[2];
> + int err;
> +
> + values[0] = drm_dp_link_rate_to_bw_code(link->rate);
> + values[1] = link->num_lanes;
> +
> + if (link->capabilities & DP_LINK_CAP_ENHANCED_FRAMING)
> + values[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> +
> + err = drm_dp_dpcd_write(aux, DP_LINK_BW_SET, values, sizeof(values));
> + if (err < 0)
> + return err;
> +
> + return 0;
> +}
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 8af695277a84..c7b3c736c40a 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -291,6 +291,7 @@
>  #define DP_SET_POWER0x600
>  # define DP_SET_POWER_D00x1
>  # define DP_SET_POWER_D30x2
> +# define DP_SET_POWER_MASK  0x3
>  
>  #define DP_PSR_ERROR_STATUS 0x2006  /* XXX 1.2? */
>  # define DP_PSR_LINK_CRC_ERROR

[Bug 73739] RV630 flickering on "Wargame European Escalation"

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

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

--- Comment #1 from Alex Deucher  ---
Please attach your xorg log and dmesg output.  Is this a regression?  Did it
used to work on an older distro?

-- 
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/20140117/26fdd200/attachment.html>

[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12

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

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #92264|text/plain  |image/jpeg
  mime type||

-- 
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/20140117/800dc605/attachment.html>

[Bug 73053] dpm hangs with BTC parts

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

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

--- Comment #25 from Juan Orti  ---
(In reply to comment #24)
> Does disabling hyperZ help?  E.g., set env var R600_DEBUG=nohyperz in
> /etc/environment or however your distro handles global env vars.

With that variable set the behaviour is the same. I can log in KDE, but crash
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/20140117/42675bab/attachment.html>

[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)

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

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

--- Comment #95 from Alexandre Demers  ---
Second night without any problem (Video, Glamor and games were all tested).
Now, I'll try to find what seems to be part of the solution by reverting one
change at a time until the system begins to hang again.

-- 
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/20140117/be7a0e42/attachment.html>

[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)

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

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

--- Comment #96 from Alex Deucher  ---
(In reply to comment #95)
> Second night without any problem (Video, Glamor and games were all tested).
> Now, I'll try to find what seems to be part of the solution by reverting one
> change at a time until the system begins to hang again.

It may some sort of synchronization issue between the EXA acceleration code in
ddx and the 3D acceleration code in mesa.  When you use glamor, all
acceleration uses the code in mesa.

-- 
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/20140117/efee8bde/attachment.html>

[Bug 73053] dpm hangs with BTC parts

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

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

--- Comment #26 from Alex Deucher  ---
Does using glamor for acceleration help?  Make sure you have an glamor enabled
ddx (xf86-video-ati), and then add:
Option "AccelMethod" "glamor"
to the device section of your xorg config.

-- 
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/20140117/d0d690a0/attachment.html>

[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12

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

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

--- Comment #42 from Paul Menzel  ---
Do you still need the debugging output of the native(?) mode lines and want me
to apply your patch and test it?

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

[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12

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

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

--- Comment #43 from Paul Menzel  ---
Would other tests like using a different modeline 1680x1050 be useful? Can that
be set on the Linux command line? Reading `/sbin/modinfo radeon` I could not
find the parameter.

-- 
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/20140117/bf4ebc73/attachment-0001.html>

[Bug 69723] GPU lockups with kernel 3.11.0 / 3.12-rc1 when dpm=1 on r600g (Cayman)

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

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

--- Comment #97 from Alexandre Demers  ---
(In reply to comment #96)
> (In reply to comment #95)
> > Second night without any problem (Video, Glamor and games were all tested).
> > Now, I'll try to find what seems to be part of the solution by reverting one
> > change at a time until the system begins to hang again.
> 
> It may some sort of synchronization issue between the EXA acceleration code
> in ddx and the 3D acceleration code in mesa.  When you use glamor, all
> acceleration uses the code in mesa.

Indeed. I'll begin by reverting this change first then.

-- 
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/20140117/2fd00f34/attachment.html>

[PULL] drm-intel-next

[Daniel Vetter]

Hi Dave,

As promised the final feature pull request for 3.14.

drm-intel-next-2014-01-10:
- final bits for runtime D3 on Haswell from Paul (now enabled fully)
- parse the backlight modulation freq information in the VBT from Jani
  (but not yet used)
- more watermark improvements from Ville for ilk-ivb and bdw
- bugfixes for fastboot from Jesse
- watermark fix for i830M (but not yet everything)
- vlv vga hotplug w/a (Imre)
- piles of other small improvements, cleanups and fixes all over

Note that the pull request includes a backmerge of the last drm-fixes
pulled into Linus' tree - things where getting a bit too messy. So the
shortlog also contains a bunch of patches from Linus tree. Please yell if
you want me to frob it for you a bit.

Cheers, Daniel


The following changes since commit 319e2e3f63c348a9b66db4667efa73178e18b17d:

  Linux 3.13-rc4 (2013-12-15 12:31:33 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel drm-intel-next

for you to fetch changes up to 0d9d349d8788d30f3fc3bb39279c370f94d9dbec:

  Merge commit origin/master into drm-intel-next (2014-01-16 22:06:30 +0100)



Abhilash Kesavan (4):
  clk: samsung: exynos5250: Fix ACP gate register offset
  clk: samsung: exynos5250: Add MDMA0 clocks
  ARM: dts: exynos5250: Fix MDMA0 clock number
  clk: samsung: exynos5250: Add CLK_IGNORE_UNUSED flag for the sysreg clock

Al Viro (1):
  ext4: fix del_timer() misuse for ->s_err_report

Alan (1):
  sata_sis: missing PM support

Alex Deucher (10):
  drm/radeon: Fix sideport problems on certain RS690 boards
  drm/radeon/cik: plug in missing blit callback
  drm/radeon: add missing display tiling setup for oland
  Revert "drm/radeon: Implement radeon_pci_shutdown"
  drm/radeon/dce6: set correct number of audio pins
  drm/radeon/dpm: disable ss on Cayman
  drm/radeon: check for 0 count in speaker allocation and SAD code
  drm/radeon: fix asic gfx values for scrapper asics
  drm/radeon: 0x9649 is SUMO2 not SUMO
  drm/radeon: Bump version for CIK DCE tiling fix

Alexander Graf (4):
  KVM: PPC: Book3S: PR: Don't clobber our exit handler id
  KVM: PPC: Book3S: PR: Export kvmppc_copy_to|from_svcpu
  KVM: PPC: Book3S: PR: Make svcpu -> vcpu store preempt savvy
  KVM: PPC: Book3S: PR: Enable interrupts earlier

Alexander Mezin (1):
  ACPI / AC: change notification handler type to ACPI_ALL_NOTIFY

Alexander Shishkin (1):
  perf: Disable all pmus on unthrottling and rescheduling

Alexander van Heukelum (1):
  Revert "drm/i915: assume all GM45 Acer laptops use inverted backlight PWM"

Alexey Khoroshilov (1):
  can: ems_usb: fix urb leaks on failure paths

Andre Przywara (1):
  ARM/cpuidle: remove __init tag from Calxeda cpuidle probe function

Andrew Bresticker (1):
  clk: exynos5250: fix sysmmu_mfc{l,r} gate clocks

Andrey Vagin (1):
  block: fix memory leaks on unplugging block device

Andy Grover (1):
  target: Remove extra percpu_ref_init

Aneesh Kumar K.V (1):
  powerpc: book3s: kvm: Don't abuse host r2 in exit path

Anton Blanchard (9):
  powerpc: Fix endian issue in setup-common.c
  powerpc: Fix topology core_id endian issue on LE builds
  powerpc/pseries: Fix endian issues in /proc/ppc64/lparcfg
  powerpc/pseries: Fix endian issues in nvram code
  powerpc/pseries: Fix PCIE link speed endian issue
  powerpc/pseries: Fix endian issues in MSI code
  powerpc: Fix endian issues in crash dump code
  powerpc/powernv: Fix endian issue in opal_xscom_read
  powerpc: Align p_end

Antonio Quartulli (4):
  batman-adv: fix size of batadv_icmp_header
  batman-adv: fix alignment for batadv_tvlv_tt_change
  batman-adv: clean nf state when removing protocol header
  batman-adv: fix vlan header access

Ard Biesheuvel (1):
  auxvec.h: account for AT_HWCAP2 in AT_VECTOR_SIZE_BASE

Arron Wang (1):
  NFC: Fix target mode p2p link establishment

Austin Boyle (1):
  max17042_battery: Fix build errors caused by missing REGMAP_I2C config

Axel Lin (1):
  clocksource: time-efm32: Select CLKSRC_MMIO

Ben Dooks (1):
  ARM: shmobile: r8a7790: fix shdi resource sizes

Ben Skeggs (2):
  drm/nouveau: populate master subdev pointer only when fully constructed
  drm/nouveau: fix null ptr dereferences on some boards

Ben Widawsky (3):
  drm/i915: Reorder/respace MI instruction definition
  drm/i915: Don't emit mbox updates without semaphores
  drm/i915/bdw: Flush system agent on gen8 also

Benjamin Herrenschmidt (3):
  powerpc/powernv: Fix OPAL LPC access in Little Endian
  Merge remote-tracking branch 'agust/merge' into merge
  powerpc: Check return value of instance-to-package OF call

Benjamin LaHaise (2):
  aio: fix kioctx leak introduced by "aio: Fix a trinity splat"
  aio/migratepages: make aio migrate page

[PATCH v2 13/28] drm/i2c: tda998x: use irq for connection status and EDID read

[Jean-Francois Moine]

On Sun, 12 Jan 2014 20:26:21 +0100
Sebastian Hesselbarth  wrote:

> On 01/12/2014 07:51 PM, Jean-Francois Moine wrote:
> > On Sat, 11 Jan 2014 19:35:21 +0100
> > Sebastian Hesselbarth  wrote:
> >
> >> At least for the DT part, I'd suggest to not ask for interrupt directly
> >> but use a proper gpios property. The can of course be converted to
> >> priv->int_irq in some tda998x_dt_probe.
> >
> > May you give me more information?
> 
> Sure, see [1].
> 
> [1] http://lists.freedesktop.org/archives/dri-devel/2013-May/038822.html

Thanks for the link, but I still don't see the advantage of the gpio
(which value?) over the irq number.

-- 
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12

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

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

--- Comment #44 from Alex Deucher  ---
(In reply to comment #43)
> Would other tests like using a different modeline 1680x1050 be useful? Can
> that be set on the Linux command line? Reading `/sbin/modinfo radeon` I
> could not find the parameter.

The panel has fixed timing so you can only program it with it's native mode. 
All other modes are scaled using the GPU.

-- 
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/20140117/e5a70571/attachment.html>

[Bug 73625] rv730 agp unstable while uvd video playback

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

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

--- Comment #15 from Roman Elshin  ---
(In reply to comment #14)
> I suggest you put the dpms off into your X startup script and then try to
> bisect the GPU lockup first.

I try to do that, but seems my testing was not enough in some case as
R600_DEBUG=nosb helps.
BISECT_LOG:

git bisect start
# bad: [32637f56a5422b09ad945d21d8e60a8b990b0182] os: First check for __GLIBC__
and then for PIPE_OS_BSD
git bisect bad 32637f56a5422b09ad945d21d8e60a8b990b0182
# good: [a32330eb93ad4cdb7f4c5bc4c730d7f3ff4042d0] Bump version to 9.2.5
git bisect good a32330eb93ad4cdb7f4c5bc4c730d7f3ff4042d0
# good: [9f07ca11c1797ac12de1e1c6aef13cf58824b5f5] mesa: Dispatch
ARB_framebuffer_object and EXT_framebuffer_object differently
git bisect good 9f07ca11c1797ac12de1e1c6aef13cf58824b5f5
# good: [e29931aa7423209d29a23be2ad754abb0f79315e] i965: Dump more information
about batch buffer usage.
git bisect good e29931aa7423209d29a23be2ad754abb0f79315e
# good: [e496583975dcbca657cb29a3b15580030394e2b0] docs: Add news item for 9.2
release
git bisect good e496583975dcbca657cb29a3b15580030394e2b0
# bad: [51a279254fecc05691524dab1bf291c7dfefccd5] mesa: Setup remaining
infrastucture and enable KHR_debug
git bisect bad 51a279254fecc05691524dab1bf291c7dfefccd5
# bad: [b3a4d5c78544ee957c4880cec7eb67f00ae04afd] i965: Move vec4 register
allocation data structures to brw->vec4.
git bisect bad b3a4d5c78544ee957c4880cec7eb67f00ae04afd
# bad: [7801a8cc8957fc58e5a493c4da2b4941f5cf9f4a] intel: Reuse intel_glFlush().
git bisect bad 7801a8cc8957fc58e5a493c4da2b4941f5cf9f4a
# good: [e95b7d89b9cd7d82b6122f9ad9bbf2249a0a8802] freedreno: updates for msm
drm/kms driver
git bisect good e95b7d89b9cd7d82b6122f9ad9bbf2249a0a8802
# good: [74be77a99e1196d07ebd941aee24313f7aa123c9] nvc0/ir: Initialize
NVC0LegalizePostRA member variables.
git bisect good 74be77a99e1196d07ebd941aee24313f7aa123c9
# bad: [09e2df5961cfe04925bdd820e6ea59af3ba783f6] i965/vs: Fix regression on
pre-gen6 with no VS uniforms in use.
git bisect bad 09e2df5961cfe04925bdd820e6ea59af3ba783f6
# bad: [f7217b99f243738f941a5d009c68387dfadcb50a] r600g: enable SB backend by
default
git bisect bad f7217b99f243738f941a5d009c68387dfadcb50a
# bad: [29ff2e907d6c54f95be6dfa72201fd25bbd50fcd] r600g: fix color exports when
we have no CBs
git bisect bad 29ff2e907d6c54f95be6dfa72201fd25bbd50fcd
# first bad commit: [29ff2e907d6c54f95be6dfa72201fd25bbd50fcd] r600g: fix color
exports when we have no CBs

-- 
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/20140117/ab0ab848/attachment.html>

[Bug 73739] RV630 flickering on "Wargame European Escalation"

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

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

--- Comment #2 from John  ---
Created attachment 92309
  --> https://bugs.freedesktop.org/attachment.cgi?id=92309&action=edit
xorg log

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

[Bug 73739] RV630 flickering on "Wargame European Escalation"

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

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

--- Comment #3 from John  ---
Created attachment 92310
  --> https://bugs.freedesktop.org/attachment.cgi?id=92310&action=edit
dmesg

-- 
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/20140117/c83b3963/attachment.html>

[Bug 73739] RV630 flickering on "Wargame European Escalation"

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

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

--- Comment #4 from John  ---
No it didn't work before.

-- 
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/20140117/46740d57/attachment.html>

[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11 and 3.12

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

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

--- Comment #45 from Paul Menzel  ---
Anything I should try/look at over the weekend?

-- 
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/20140117/588666ba/attachment.html>

[Bug 73060] RV630 HDMI audio lost after system suspend

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

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

John  changed:

   What|Removed |Added

   Hardware|x86 (IA32)  |All
Version|XOrg CVS|unspecified

-- 
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/20140117/348ecfec/attachment.html>

[Bug 73060] RV630 HDMI audio lost after system suspend

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

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

--- Comment #3 from John  ---
Created attachment 92312
  --> https://bugs.freedesktop.org/attachment.cgi?id=92312&action=edit
dmesg

-- 
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/20140117/0f150f4b/attachment-0001.html>

[Bug 67121] Broken suspend/resume with radeon/KMS on RS482M

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

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

--- Comment #7 from Adrian Knoth  ---
Random observation: high CPU usage "uncripples" the video output.

That is: I suspend to RAM, I resume and unplug the AC, causing the screen to be
heavily distorted.

When I blindly start burnK7 (from Debian's cpuburn package), CPU usage on one
of the cores jumps to 100% and I have a wonderful clear and perfect screen. As
soon as I terminate burnK7, the corruption is back. (with AC unplugged all the
time; of course, plugging the AC back in always fixes the corruption).

So it's a power management issue. For some reasons, the radeon driver (or the
hardware) is sensitive to CPU power saving states (idle states?) and the
presence of an external power supply. And all this only happens with KMS, not
with UMS.

So is it an ACPI/PM bug? Or DRI?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 43441] [RADEON:KMS:RV370:RESUME] garbage on screen (console or X) after suspend-resume with radeon (KMS only)

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

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

--- Comment #7 from Adrian Knoth  ---
cyberbat: As mentioned in ,
I'm not sure if I'm seeing the same or a different bug.

Could you try to run some kind of cpuburn (there's a Debian package ) to see if
it fixes the output? If not, it's likely a different issue.

TIA

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

Sharing Framebuffers between Client / Server

[Rian Quinn]

I am working on a client/server program, where the server creates (and has 
access to a framebuffer), and then needs to share this framebuffer with a 
client program so that this client program can draw into the framebuffer 
directly (i.e. no memcpy).?

I am trying to figureout what the ?cleanest? way to do this is, such that I can 
support Intel?s proprietary driver, the open source AMD and NVidia drivers, and 
the VMWare driver (I have no need for the proprietary ADM/NVidia drivers right 
now). From what I can tell, GEM is one way to do this. The problem is VMWare 
doesn?t support GEM.?


I tried (knowing it would not work), using KMS to create the framebuffer, and 
then sending the information needed to mmap to the client. This of course 
failed because the framebuffer is marked non-sharable in the kernel.?


To be clear, I am fine having to manually write ioctls for each driver, if 
thats what it takes. But at this point, I am at a loss on the best method to 
share scannot buffers (or at least in a way that doesn?t make someone cringe 
when they see my code).


Thanks,
- Rian?

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140117/7b5fd36b/attachment.html>