[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)

2013-08-24 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=68224

--- Comment #6 from Laurent carlier  ---
(In reply to comment #5)
> Created attachment 84544 [details] [review]
> LLVM Patch #3
> 
> If you apply all three of these patches, does it fix the crash?

It's better, now it crash before the intro start (so latter), new shader dump
attached

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

[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)

2013-08-24 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=68224

--- Comment #7 from Laurent carlier  ---
Created attachment 84551
  --> https://bugs.freedesktop.org/attachment.cgi?id=84551&action=edit
Shader dump with 3 patches applied

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

[Bug 68503] New: Graphical glitches in Serious Sam 3 when SB is enabled

2013-08-24 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=68503

  Priority: medium
Bug ID: 68503
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Graphical glitches in Serious Sam 3 when SB is enabled
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: kwah...@wp.pl
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: git
 Component: Drivers/Gallium/r600
   Product: Mesa

Created attachment 84557
  --> https://bugs.freedesktop.org/attachment.cgi?id=84557&action=edit
Graphical glitches with r600-sb

Sterted with R600_DEBUG=sb R600_LLVM=0 produces some small green/red/blue
rectangles (see the atachment).



OpenGL renderer string: Gallium 0.4 on AMD TURKS
OpenGL version string: 3.0 Mesa 9.3.0-devel (git-86751cb raring-oibaf-ppa)
OpenGL shading language version string: 1.30

I have spare SS3 Steam codes to gift if a developer need one. 

Console output:

Setting breakpad minidump AppID = 41070
Steam_SetMinidumpSteamID:  Caching Steam ID:  76561198064187789 [API loaded no]
Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=0x9047)
Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=0x87fc)
Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=0x9048)
Mesa: User error: GL_INVALID_ENUM in glGetIntegerv(pname=0x87fc)
Installing breakpad exception handler for
appid(gameoverlayui)/version(20130823160907_client)
Installing breakpad exception handler for
appid(gameoverlayui)/version(1.0_client)
Installing breakpad exception handler for
appid(gameoverlayui)/version(1.0_client)
Installing breakpad exception handler for
appid(gameoverlayui)/version(1.0_client)
Gtk-Message: Failed to load module "overlay-scrollbar"
[0824/134511:WARNING:proxy_service.cc(958)] PAC support disabled because there
is no system implementation
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in glMatrixMode(mode)
Mesa: User error: GL_INVALID_ENUM in

[Bug 68503] Graphical glitches in Serious Sam 3 when SB is enabled

2013-08-24 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=68503

--- Comment #1 from kwah...@wp.pl ---
Pics (if you cannot open the atachment): 
http://postimg.org/image/rpg5b0oz3/
http://postimg.org/image/h5acgr97n/

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

[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1

2013-08-24 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=68451

--- Comment #4 from Peter Kraus  ---
Hello,
did not have a time to bisect yet (seems to be a bit more complex than I
thought, or I'm just daft).

The behaviour is not fixed by yesterday's game update, and it's not fixed in
9.2rc2 either.

What's the best way of doing the bisect if I don't want to pollute my Arch
Linux install?

Cheers.

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

[Bug 68503] Graphical glitches in Serious Sam 3 when SB is enabled

2013-08-24 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=68503

--- Comment #2 from Vadim Girlin  ---
Please attach the output with R600_DEBUG=sb,ps,vs.

Could you also record the GL trace that reproduces the issue using apitrace -
http://apitrace.github.io/

You can just upload the trace if it's not too big, then it might help me to
reproduce the bug if it's not hw-specific, but also you can use recorded trace
to find the exact failing shader as described in "Regression debugging" section
here - http://people.freedesktop.org/~vadimg/r600-sb.html - you'll need to
replay it with R600_DEBUG=sb,sbstat first to figure out initial range of shader
indices used by the app, and then apply R600_SB_DSKIP_* env vars when replaying
the trace to bisect the range as described in that section. After locating
broken shader just add "ps,vs" to R600_DEBUG and attach the output. You'll have
a cmd line like this in the end (with some other shader index instead of 37):
R600_DEBUG=sb,ps,vs R600_SB_DSKIP_MODE=2 R600_SB_DSKIP_START=37
R600_SB_DSKIP_END=37  &> log_file

I can try to do everything myself if you can send me the key for SS3 (to
vadimgirlin at gmail dot com), this can save some time, but the bug may be
specific to your GPU or system configuration and in such case possibly I won't
be able to reproduce it on my hardware, then I'll still need your help with
debugging as described above.

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

[Bug 68503] Graphical glitches in Serious Sam 3 when SB is enabled

2013-08-24 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=68503

--- Comment #3 from kwah...@wp.pl ---
Created attachment 84563
  --> https://bugs.freedesktop.org/attachment.cgi?id=84563&action=edit
output with R600_DEBUG=sb,ps,vs

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

[Bug 68503] Graphical glitches in Serious Sam 3 when SB is enabled

2013-08-24 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=68503

--- Comment #4 from kwah...@wp.pl ---
Created attachment 84566
  --> https://bugs.freedesktop.org/attachment.cgi?id=84566&action=edit
shader no 76 enabled

Seems that shader number 76 is the culprit. 
R600_DEBUG=sb R600_SB_DSKIP_START=76 R600_SB_DSKIP_END=76 R600_SB_DSKIP_MODE=2
produces glitches.

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

[PATCHv4 0/5] drm/msm: A DRM/KMS driver for snapdragon SoCs

2013-08-24 Thread Rob Clark 
This patchset can also be found here, for easier browsing:

  http://cgit.freedesktop.org/~robclark/linux/log/?h=drm-next
  git://people.freedesktop.org/~robclark/linux drm-next

In userspace, I've a libdrm branch with libdrm_freedreno updated to
work on top of either this driver or the downstream android kgsl+fbdev
drivers:

  https://github.com/freedreno/libdrm/commits/msm-drm

And the DDX has been updated to either use kms with this driver, or
the downstream android drivers.  Note that page flipping requires kms:

  https://github.com/freedreno/xf86-video-freedreno/commits/msm-drm

And finally mesa/gallium with a few minor tweaks, mostly updates to
the loader to load on either "msm" or legacy/downstream "kgsl":

  https://github.com/freedreno/mesa/commits/msm-drm

I have started adding DSI panel support, although there are still some
things to debug, and in general it isn't ready to merge yet.  But if
you are curious, it can be found here:

  https://github.com/freedreno/kernel-msm/commits/mako-kernel-drm

History:
v1: original
v2: only changed patch is a3xx gpu (fix timespec vs ioctl issue,
drop setparam ioctl for now).  I've left out the two debugfs
patches, until I have a chance to attempt to make drm core
move minor creation (or at least debugfs) until after load.
I've also added a small note about why cmdstream validation
is not required in the commit-msg of the a3xx gpu patch.
v3: fix the unlock/unpin order as pointed out by Maarten Lankhorst,
and a few little tweaks to prepare things better for DSI
support.
v4: just minor changes (rebase on drm_fasync removal, and small
Makefile tweak to fix build error on older versions of gcc),
and add a basic hangcheck/recovery mechanism in case of gpu
lockup.

NOTES from the original RFC:

In the current snapdragon SoC's, we have (at least) 3 different
display controller blocks at play:
 + MDP3 - ?? seems to be what is on geeksphone peak device
 + MDP4 - S3 (APQ8060, touchpad), S4-pro (APQ8064, nexus4 & ifc6410)
 + MDSS - snapdragon 800

(I don't have a completely clear picture on which display controller
maps to which part #)

Plus a handful of blocks around them for HDMI/DSI/etc output.

And on gpu side of things:
 + zero, one, or two 2d cores (z180)
 + and either a2xx or a3xx 3d core.

But, HDMI/DSI/etc blocks seem like they can be shared across multiple
display controller blocks.  And I for sure don't want to have to deal
with N different kms devices from xf86-video-freedreno.  Plus, it
seems like we can do some clever tricks like use GPU to trigger
pageflip after rendering completes (ie. have the kms/crtc code build
up gpu cmdstream to update scanout and write FLUSH register after).

So, the approach is one drm driver, with some modularity.  Different
'struct msm_kms' implementations, depending on display controller.
And one or more 'struct msm_gpu' for the various different gpu sub-
modules.

The kms module provides the plane, crtc, and encoder objects, and
loads whatever connectors are appropriate.

For MDP4, the mapping is:

  plane   -> PIPE{RGBn,VGn}  \
  crtc-> OVLP{n} + DMA{P,S,E} (??)   |-> MDP "device"
  encoder -> DTV/LCDC/DSI (within MDP4)  /
  connector -> HDMI/DSI/etc  --> other device(s)

Since the irq's that drm core mostly cares about are vblank/framedone,
we'll let msm_mdp4_kms provide the irq install/uninstall/etc functions
and treat the MDP4 block's irq as "the" irq.  Even though the connectors
may have their own irqs which they install themselves.  For this reason
the display controller is the "master" device.

Each connector probably ends up being a separate device, just for the
logistics of finding/mapping io region, irq, etc.  Idealy we would
have a better way than just stashing the platform device in a global
(ie. like DT super-node.. but I don't have any snapdragon hw yet that
is using DT).

Note that so far I've not been able to get any docs on the hw, and it
seems that access to such docs would prevent me from working on the
freedreno gallium driver.  So there may be some mistakes in register
names (I had to invent a few, since no sufficient hint was given in
the downstream android fbdev driver), bitfield sizes, etc.  My current
state of understanding the registers is given in the envytools rnndb
files at:

  https://github.com/freedreno/envytools/tree/master/rnndb

These files are used both for a parser tool (in the same tree) to
parse logged register reads/writes (both from downstream android fbdev
driver, and this driver with register logging enabled), as well as to
generate the register level headers.

Rob Clark (5):
  drm/msm: add register definitions
  drm/msm: basic KMS driver for snapdragon
  drm/msm: add register definitions for gpu
  drm/msm: add a3xx gpu support
  drm/msm: add basic hangcheck/recovery mechanism

 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/msm/Kconf

[PATCHv4 5/5] drm/msm: add basic hangcheck/recovery mechanism

2013-08-24 Thread Rob Clark 
A basic, no-frills recovery mechanism in case the gpu gets wedged.  We
could try to be a bit more fancy and restart the next submit after the
one that got wedged, but for now keep it simple.  This is enough to
recover things if, for example, the gpu hangs mid way through a piglit
run.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   |  1 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 26 +++--
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |  3 +-
 drivers/gpu/drm/msm/msm_gpu.c   | 52 +
 drivers/gpu/drm/msm/msm_gpu.h   | 10 +++
 5 files changed, 87 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 13d61bb..035bd13 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -371,6 +371,7 @@ static const struct adreno_gpu_funcs funcs = {
.hw_init = a3xx_hw_init,
.pm_suspend = msm_gpu_pm_suspend,
.pm_resume = msm_gpu_pm_resume,
+   .recover = adreno_recover,
.last_fence = adreno_last_fence,
.submit = adreno_submit,
.flush = adreno_flush,
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 282163e..a605847 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -111,6 +111,28 @@ uint32_t adreno_last_fence(struct msm_gpu *gpu)
return adreno_gpu->memptrs->fence;
 }
 
+void adreno_recover(struct msm_gpu *gpu)
+{
+   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+   struct drm_device *dev = gpu->dev;
+   int ret;
+
+   gpu->funcs->pm_suspend(gpu);
+
+   /* reset ringbuffer: */
+   gpu->rb->cur = gpu->rb->start;
+
+   /* reset completed fence seqno, just discard anything pending: */
+   adreno_gpu->memptrs->fence = gpu->submitted_fence;
+
+   gpu->funcs->pm_resume(gpu);
+   ret = gpu->funcs->hw_init(gpu);
+   if (ret) {
+   dev_err(dev->dev, "gpu hw init failed: %d\n", ret);
+   /* hmm, oh well? */
+   }
+}
+
 int adreno_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
struct msm_file_private *ctx)
 {
@@ -119,8 +141,6 @@ int adreno_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit,
struct msm_ringbuffer *ring = gpu->rb;
unsigned i, ibs = 0;
 
-   adreno_gpu->last_fence = submit->fence;
-
for (i = 0; i < submit->nr_cmds; i++) {
switch (submit->cmd[i].type) {
case MSM_SUBMIT_CMD_IB_TARGET_BUF:
@@ -225,7 +245,7 @@ void adreno_show(struct msm_gpu *gpu, struct seq_file *m)
adreno_gpu->rev.patchid);
 
seq_printf(m, "fence:%d/%d\n", adreno_gpu->memptrs->fence,
-   adreno_gpu->last_fence);
+   gpu->submitted_fence);
seq_printf(m, "rptr: %d\n", adreno_gpu->memptrs->rptr);
seq_printf(m, "wptr: %d\n", adreno_gpu->memptrs->wptr);
seq_printf(m, "rb wptr:  %d\n", get_wptr(gpu->rb));
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index 6b49c4f..f73abfb 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -54,8 +54,6 @@ struct adreno_gpu {
uint32_t revn;  /* numeric revision name */
const struct adreno_gpu_funcs *funcs;
 
-   uint32_t last_fence;
-
/* firmware: */
const struct firmware *pm4, *pfp;
 
@@ -99,6 +97,7 @@ static inline bool adreno_is_a330(struct adreno_gpu *gpu)
 int adreno_get_param(struct msm_gpu *gpu, uint32_t param, uint64_t *value);
 int adreno_hw_init(struct msm_gpu *gpu);
 uint32_t adreno_last_fence(struct msm_gpu *gpu);
+void adreno_recover(struct msm_gpu *gpu);
 int adreno_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
struct msm_file_private *ctx);
 void adreno_flush(struct msm_gpu *gpu);
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 7c6541e..e1e1ec9 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -203,6 +203,51 @@ int msm_gpu_pm_suspend(struct msm_gpu *gpu)
 }
 
 /*
+ * Hangcheck detection for locked gpu:
+ */
+
+static void recover_worker(struct work_struct *work)
+{
+   struct msm_gpu *gpu = container_of(work, struct msm_gpu, recover_work);
+   struct drm_device *dev = gpu->dev;
+
+   dev_err(dev->dev, "%s: hangcheck recover!\n", gpu->name);
+
+   mutex_lock(&dev->struct_mutex);
+   gpu->funcs->recover(gpu);
+   mutex_unlock(&dev->struct_mutex);
+
+   msm_gpu_retire(gpu);
+}
+
+static void hangcheck_timer_reset(struct msm_gpu *gpu)
+{
+   DBG("%s", gpu->name);
+   mod_timer(&gpu->hangcheck_timer,
+   round_jiffies_up(jiffies + DRM_MSM_HANGCHECK_JIFFI

[Bug 64582] [r600g/vdpau] Inconsistency detected by ld.so: dl-close.c: 765: _dl_close: Assertion `map->l_init_called' failed!

2013-08-24 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=64582

--- Comment #4 from John  ---
Same issue here:
Inconsistency detected by ld.so: dl-close.c: 771: _dl_close: Assertion
`map->l_init_called' failed!

Mesa 9.2rc2 (same with rc1), dri2proto 2.8, libvdpau 0.7.
I believe my distribution's libvdpau was compiled with dri2proto support, but
is there a way to confirm?

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

[Bug 68503] Graphical glitches in Serious Sam 3 when SB is enabled

2013-08-24 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=68503

--- Comment #5 from Vadim Girlin  ---
Created attachment 84573
  --> https://bugs.freedesktop.org/attachment.cgi?id=84573&action=edit
patch

Does this patch help?

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

[Bug 68235] Display freezes after login with kernel 3.11.0-rc5 on Cayman with dpm=1

2013-08-24 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=68235

--- Comment #4 from Alexandre Demers  ---
After bisect in one direction, I've ended up with the following commit:
f90555cbe629e14c6af1dcec1933a3833ecd321f is the first bad commit
commit f90555cbe629e14c6af1dcec1933a3833ecd321f
Author: Alex Deucher 
Date:   Wed Jul 17 16:34:12 2013 -0400

drm/radeon/dpm/atom: fix broken gcc harder

See bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=66932
https://bugs.freedesktop.org/show_bug.cgi?id=66972
https://bugs.freedesktop.org/show_bug.cgi?id=66945

Signed-off-by: Alex Deucher 

:04 04 c32ad9a80c5356236e935eeb5198683727b9d00d
eb5aa1083eb33e7b9aebebdb310dda0399152e87 Mdrivers

Now, I must say this commit actually fixes a visual problem after commit
69e0b57 (which is a good commit over here without any known problem). So, I'll
dig in the other direction to find which commit broke the known good state.

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

[PATCH v2 5/6] drm/i915: Support render nodes

2013-08-24 Thread Daniel Vetter 
On Fri, Aug 23, 2013 at 01:13:27PM +0200, David Herrmann wrote:
> From: Kristian H?gsberg 
> 
> Enable support for drm render nodes for i915 by flagging the ioctls that
> are safe and just needed for rendering.
> 
> Cc: Daniel Vetter 
> Signed-off-by: Kristian H?gsberg 
> Signed-off-by: David Herrmann 
> ---
>  drivers/gpu/drm/i915/i915_dma.c | 36 ++--
>  drivers/gpu/drm/i915/i915_drv.c |  3 ++-
>  2 files changed, 20 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 0adfe40..ecf5ecd 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1840,7 +1840,7 @@ const struct drm_ioctl_desc i915_ioctls[] = {
>   DRM_IOCTL_DEF_DRV(I915_BATCHBUFFER, i915_batchbuffer, DRM_AUTH),
>   DRM_IOCTL_DEF_DRV(I915_IRQ_EMIT, i915_irq_emit, DRM_AUTH),
>   DRM_IOCTL_DEF_DRV(I915_IRQ_WAIT, i915_irq_wait, DRM_AUTH),
> - DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, DRM_AUTH),
> + DRM_IOCTL_DEF_DRV(I915_GETPARAM, i915_getparam, 
> DRM_AUTH|DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(I915_SETPARAM, i915_setparam, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>   DRM_IOCTL_DEF_DRV(I915_ALLOC, drm_noop, DRM_AUTH),
>   DRM_IOCTL_DEF_DRV(I915_FREE, drm_noop, DRM_AUTH),
> @@ -1853,34 +1853,34 @@ const struct drm_ioctl_desc i915_ioctls[] = {
>   DRM_IOCTL_DEF_DRV(I915_HWS_ADDR, i915_set_status_page, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
>   DRM_IOCTL_DEF_DRV(I915_GEM_INIT, i915_gem_init_ioctl, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
>   DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER, i915_gem_execbuffer, 
> DRM_AUTH|DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
> DRM_AUTH|DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(I915_GEM_EXECBUFFER2, i915_gem_execbuffer2, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(I915_GEM_PIN, i915_gem_pin_ioctl, 
> DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
>   DRM_IOCTL_DEF_DRV(I915_GEM_UNPIN, i915_gem_unpin_ioctl, 
> DRM_AUTH|DRM_ROOT_ONLY|DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(I915_GEM_BUSY, i915_gem_busy_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(I915_GEM_SET_CACHING, i915_gem_set_caching_ioctl, 
> DRM_UNLOCKED),
>   DRM_IOCTL_DEF_DRV(I915_GEM_GET_CACHING, i915_gem_get_caching_ioctl, 
> DRM_UNLOCKED),

Those two here also need to work on render nodes. With that and REG_READ
also marked up like Chris said this is

Reviewed-by: Daniel Vetter 


> - DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
> DRM_AUTH|DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(I915_GEM_THROTTLE, i915_gem_throttle_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
>   DRM_IOCTL_DEF_DRV(I915_GEM_ENTERVT, i915_gem_entervt_ioctl, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
>   DRM_IOCTL_DEF_DRV(I915_GEM_LEAVEVT, i915_gem_leavevt_ioctl, 
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY|DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 
> DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 
> DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 
> DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, 
> DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, 
> DRM_UNLOCKED),
> - DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl, 
> DRM_UNLOCKED),
> + DRM_IOCTL_DEF_DRV(I915_GEM_CREATE, i915_gem_create_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_PREAD, i915_gem_pread_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_PWRITE, i915_gem_pwrite_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_MMAP, i915_gem_mmap_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_MMAP_GTT, i915_gem_mmap_gtt_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_SET_DOMAIN, i915_gem_set_domain_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_SW_FINISH, i915_gem_sw_finish_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_SET_TILING, i915_gem_set_tiling, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_GET_TILING, i915_gem_get_tiling, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(I915_GEM_GET_APERTURE, i915_gem_get_aperture_ioctl, 
> DRM_UNLOCKED|DRM_RENDER_ALLOW),
>

[patch -next] drm/prime: double lock typo

2013-08-24 Thread Daniel Vetter 
On Fri, Aug 23, 2013 at 11:46:02PM +0300, Dan Carpenter wrote:
> There is a typo so deadlocks on error instead of unlocking.
> 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
> index 7ae2bfc..276d470 100644
> --- a/drivers/gpu/drm/drm_prime.c
> +++ b/drivers/gpu/drm/drm_prime.c
> @@ -552,7 +552,7 @@ fail:
>*/
>   drm_gem_handle_delete(file_priv, *handle);
>  out_unlock:
> - mutex_lock(&dev->object_name_lock);
> + mutex_unlock(&dev->object_name_lock);

Duh. Unfortunately exercising error paths is pretty hard :( So thanks for
catching this.

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

[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)

2013-08-24 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=68224

--- Comment #4 from Tom Stellard  ---
Created attachment 84543
  --> https://bugs.freedesktop.org/attachment.cgi?id=84543&action=edit
Patch #2

-- 
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/20130824/1a964fbe/attachment.html>

[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)

2013-08-24 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=68224

--- Comment #5 from Tom Stellard  ---
Created attachment 84544
  --> https://bugs.freedesktop.org/attachment.cgi?id=84544&action=edit
LLVM Patch #3

If you apply all three of these patches, does it fix the crash?

-- 
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/20130824/8c2f7879/attachment.html>

[Nouveau] [PATCH] drm/nouveau: do not move buffers when not needed

2013-08-24 Thread Martin Peres 
On 15/07/2013 10:39, Maarten Lankhorst wrote:
> Op 15-07-13 08:05, Ben Skeggs schreef:
>> On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst
>>  wrote:
>>> I have no idea what this bogus restriction on placement is, but it breaks 
>>> decoding 1080p
>>> VDPAU at boot speed. With this patch applied I only need to bump the vdec 
>>> clock to
>>> get real-time 1080p decoding. It prevents a lot of VRAM <-> VRAM buffer 
>>> moves.
>> It's not bogus, and is required for pre-GF8 boards with VRAM > BAR size.
>>
>> What configuration does the buffer that's getting moved here have
>> exactly?  The placement restriction isn't necessary on GF8, the rest
>> of the restrictions may currently be required still however.
>>
>> = vdpau on NVC0 with tiling. I upload the raw bitstream to a tiling bo. This 
>> is ok because
> the vm hides all the tiling translations, and the engines will read the raw 
> bitstream correctly.
> 8<---
> This prevents buffer moves from being done on NV50+, where remapping is not 
> needed because
> the bar has its own VM, instead of only having the first BAR1-size chunk of 
> VRAM accessible.
> nouveau_bo_tile_layout is always 0 on < NV_50.
>
> Signed-off-by: Maarten Lankhorst 
There are still some rendering issues on my nvc4, but the framerate is 
much smoother than it was before this patch.

Tested-by: Martin Peres 
> ---
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
> b/drivers/gpu/drm/nouveau/nouveau_bo.c
> index d506da5..762bfcd 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
> @@ -1346,14 +1361,13 @@ nouveau_ttm_fault_reserve_notify(struct 
> ttm_buffer_object *bo)
>   struct nouveau_device *device = nv_device(drm->device);
>   u32 mappable = pci_resource_len(device->pdev, 1) >> PAGE_SHIFT;
>   
> - /* as long as the bo isn't in vram, and isn't tiled, we've got
> -  * nothing to do here.
> + /*
> +  * if the bo is not in vram, or remapping can be done (nv50+)
> +  * do not worry about placement, any location is valid
>*/
> - if (bo->mem.mem_type != TTM_PL_VRAM) {
> - if (nv_device(drm->device)->card_type < NV_50 ||
> - !nouveau_bo_tile_layout(nvbo))
> - return 0;
> - }
> + if (nv_device(drm->device)->card_type >= NV_50 ||
> + bo->mem.mem_type != TTM_PL_VRAM)
> + return 0;
>   
>   /* make sure bo is in mappable vram */
>   if (bo->mem.start + bo->mem.num_pages < mappable)
>
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau

[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)

2013-08-24 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=68224

--- Comment #6 from Laurent carlier  ---
(In reply to comment #5)
> Created attachment 84544 [details] [review]
> LLVM Patch #3
> 
> If you apply all three of these patches, does it fix the crash?

It's better, now it crash before the intro start (so latter), new shader dump
attached

-- 
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/20130824/cf487ad5/attachment.html>

[Bug 68224] [radeonsi] Serious Sam3 is segfaulting (LLVM assert)

2013-08-24 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=68224

--- Comment #7 from Laurent carlier  ---
Created attachment 84551
  --> https://bugs.freedesktop.org/attachment.cgi?id=84551&action=edit
Shader dump with 3 patches applied

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

[Bug 68503] New: Graphical glitches in Serious Sam 3 when SB is enabled

2013-08-24 Thread bugzilla-dae...@freedesktop.org 
RKS
INF:  Version: 3.0 Mesa 9.3.0-devel (git-86751cb raring-oibaf-ppa)
INF:  Video memory size: 512 MB
INF:  Available for textures: 512 MB
INF:  Active GPU(s): 1
WRN:  Display driver is too old, please update it ASAP!
INF:  
INF:  Sfx API: OpenAL
INF:  Device: PulseAudio Default
INF:  Mixer frequency: 44100 Hz
INF:  Mixer voices: 64
INF:  Max sound sources: 25
INF:  Max total volume: 3
INF:  Speaker config: (unknown)
INF:  Environment FX: not supported
INF:  
INF:  Using cheats will invalidate your score for this level and achievements
won't be awarded for the remainder of the game.
INF:  AutoDetect: Hardware values unchanged, nothing to do.
INF:  Started simulation on 'Content/SeriousSam3/Levels/Menu/Intro.wld' in 0.61
seconds.
ERR:  Failed to precache texture
Content/SeriousSam3/Models/Vehicles/FrontLoader02/Textures/Wheel_01_CM.tex; it
doesn't exist in memory
INF:  Started simulation on 'Content/SeriousSam3/Levels/Menu/MenuLevel.wld' in
0.39 seconds.
ERR:  Failed to precache texture
Content/SeriousSam3/Models/Vehicles/UH_60_BlackHawk_cutscenes/Textures/OuterParts_CM.tex;
it doesn't exist in memory
ERR:  Failed to precache texture
Content/SeriousSam3/Models/NPCS/Soldiers/Textures/Clothing/Spa/Uniform_AO.tex;
it doesn't exist in memory
ERR:  Workshop error 2: failed to download
'temp:/Workshop/41070/Subscribed/zz0f84f1fa8d9c58cc.gro'
Game removed: AppID 41070 "Serious Sam 3: BFE", ProcID 4123

-- 
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/20130824/ea051a96/attachment-0001.html>

[Bug 68503] Graphical glitches in Serious Sam 3 when SB is enabled

2013-08-24 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=68503

--- Comment #1 from kwahoo2 at wp.pl ---
Pics (if you cannot open the atachment): 
http://postimg.org/image/rpg5b0oz3/
http://postimg.org/image/h5acgr97n/

-- 
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/20130824/4ad137fd/attachment.html>

[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1

2013-08-24 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=68451

--- Comment #4 from Peter Kraus  ---
Hello,
did not have a time to bisect yet (seems to be a bit more complex than I
thought, or I'm just daft).

The behaviour is not fixed by yesterday's game update, and it's not fixed in
9.2rc2 either.

What's the best way of doing the bisect if I don't want to pollute my Arch
Linux install?

Cheers.

-- 
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/20130824/951f0c89/attachment.html>

[Bug 68503] Graphical glitches in Serious Sam 3 when SB is enabled

2013-08-24 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=68503

--- Comment #2 from Vadim Girlin  ---
Please attach the output with R600_DEBUG=sb,ps,vs.

Could you also record the GL trace that reproduces the issue using apitrace -
http://apitrace.github.io/

You can just upload the trace if it's not too big, then it might help me to
reproduce the bug if it's not hw-specific, but also you can use recorded trace
to find the exact failing shader as described in "Regression debugging" section
here - http://people.freedesktop.org/~vadimg/r600-sb.html - you'll need to
replay it with R600_DEBUG=sb,sbstat first to figure out initial range of shader
indices used by the app, and then apply R600_SB_DSKIP_* env vars when replaying
the trace to bisect the range as described in that section. After locating
broken shader just add "ps,vs" to R600_DEBUG and attach the output. You'll have
a cmd line like this in the end (with some other shader index instead of 37):
R600_DEBUG=sb,ps,vs R600_SB_DSKIP_MODE=2 R600_SB_DSKIP_START=37
R600_SB_DSKIP_END=37  &> log_file

I can try to do everything myself if you can send me the key for SS3 (to
vadimgirlin at gmail dot com), this can save some time, but the bug may be
specific to your GPU or system configuration and in such case possibly I won't
be able to reproduce it on my hardware, then I'll still need your help with
debugging as described above.

-- 
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/20130824/2b1009da/attachment.html>

[Bug 68503] Graphical glitches in Serious Sam 3 when SB is enabled

2013-08-24 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=68503

--- Comment #3 from kwahoo2 at wp.pl ---
Created attachment 84563
  --> https://bugs.freedesktop.org/attachment.cgi?id=84563&action=edit
output with R600_DEBUG=sb,ps,vs

-- 
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/20130824/825c3f33/attachment.html>

[Bug 68503] Graphical glitches in Serious Sam 3 when SB is enabled

2013-08-24 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=68503

--- Comment #4 from kwahoo2 at wp.pl ---
Created attachment 84566
  --> https://bugs.freedesktop.org/attachment.cgi?id=84566&action=edit
shader no 76 enabled

Seems that shader number 76 is the culprit. 
R600_DEBUG=sb R600_SB_DSKIP_START=76 R600_SB_DSKIP_END=76 R600_SB_DSKIP_MODE=2
produces glitches.

-- 
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/20130824/67f5fb80/attachment.html>

[PATCHv4 0/5] drm/msm: A DRM/KMS driver for snapdragon SoCs

2013-08-24 Thread Rob Clark 
This patchset can also be found here, for easier browsing:

  http://cgit.freedesktop.org/~robclark/linux/log/?h=drm-next
  git://people.freedesktop.org/~robclark/linux drm-next

In userspace, I've a libdrm branch with libdrm_freedreno updated to
work on top of either this driver or the downstream android kgsl+fbdev
drivers:

  https://github.com/freedreno/libdrm/commits/msm-drm

And the DDX has been updated to either use kms with this driver, or
the downstream android drivers.  Note that page flipping requires kms:

  https://github.com/freedreno/xf86-video-freedreno/commits/msm-drm

And finally mesa/gallium with a few minor tweaks, mostly updates to
the loader to load on either "msm" or legacy/downstream "kgsl":

  https://github.com/freedreno/mesa/commits/msm-drm

I have started adding DSI panel support, although there are still some
things to debug, and in general it isn't ready to merge yet.  But if
you are curious, it can be found here:

  https://github.com/freedreno/kernel-msm/commits/mako-kernel-drm

History:
v1: original
v2: only changed patch is a3xx gpu (fix timespec vs ioctl issue,
drop setparam ioctl for now).  I've left out the two debugfs
patches, until I have a chance to attempt to make drm core
move minor creation (or at least debugfs) until after load.
I've also added a small note about why cmdstream validation
is not required in the commit-msg of the a3xx gpu patch.
v3: fix the unlock/unpin order as pointed out by Maarten Lankhorst,
and a few little tweaks to prepare things better for DSI
support.
v4: just minor changes (rebase on drm_fasync removal, and small
Makefile tweak to fix build error on older versions of gcc),
and add a basic hangcheck/recovery mechanism in case of gpu
lockup.

NOTES from the original RFC:

In the current snapdragon SoC's, we have (at least) 3 different
display controller blocks at play:
 + MDP3 - ?? seems to be what is on geeksphone peak device
 + MDP4 - S3 (APQ8060, touchpad), S4-pro (APQ8064, nexus4 & ifc6410)
 + MDSS - snapdragon 800

(I don't have a completely clear picture on which display controller
maps to which part #)

Plus a handful of blocks around them for HDMI/DSI/etc output.

And on gpu side of things:
 + zero, one, or two 2d cores (z180)
 + and either a2xx or a3xx 3d core.

But, HDMI/DSI/etc blocks seem like they can be shared across multiple
display controller blocks.  And I for sure don't want to have to deal
with N different kms devices from xf86-video-freedreno.  Plus, it
seems like we can do some clever tricks like use GPU to trigger
pageflip after rendering completes (ie. have the kms/crtc code build
up gpu cmdstream to update scanout and write FLUSH register after).

So, the approach is one drm driver, with some modularity.  Different
'struct msm_kms' implementations, depending on display controller.
And one or more 'struct msm_gpu' for the various different gpu sub-
modules.

The kms module provides the plane, crtc, and encoder objects, and
loads whatever connectors are appropriate.

For MDP4, the mapping is:

  plane   -> PIPE{RGBn,VGn}  \
  crtc-> OVLP{n} + DMA{P,S,E} (??)   |-> MDP "device"
  encoder -> DTV/LCDC/DSI (within MDP4)  /
  connector -> HDMI/DSI/etc  --> other device(s)

Since the irq's that drm core mostly cares about are vblank/framedone,
we'll let msm_mdp4_kms provide the irq install/uninstall/etc functions
and treat the MDP4 block's irq as "the" irq.  Even though the connectors
may have their own irqs which they install themselves.  For this reason
the display controller is the "master" device.

Each connector probably ends up being a separate device, just for the
logistics of finding/mapping io region, irq, etc.  Idealy we would
have a better way than just stashing the platform device in a global
(ie. like DT super-node.. but I don't have any snapdragon hw yet that
is using DT).

Note that so far I've not been able to get any docs on the hw, and it
seems that access to such docs would prevent me from working on the
freedreno gallium driver.  So there may be some mistakes in register
names (I had to invent a few, since no sufficient hint was given in
the downstream android fbdev driver), bitfield sizes, etc.  My current
state of understanding the registers is given in the envytools rnndb
files at:

  https://github.com/freedreno/envytools/tree/master/rnndb

These files are used both for a parser tool (in the same tree) to
parse logged register reads/writes (both from downstream android fbdev
driver, and this driver with register logging enabled), as well as to
generate the register level headers.

Rob Clark (5):
  drm/msm: add register definitions
  drm/msm: basic KMS driver for snapdragon
  drm/msm: add register definitions for gpu
  drm/msm: add a3xx gpu support
  drm/msm: add basic hangcheck/recovery mechanism

 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/msm/Kconf

[PATCHv4 1/5] drm/msm: add register definitions

2013-08-24 Thread Rob Clark 
Generated from rnndb files in:

https://github.com/freedreno/envytools

Keep this split out as a separate commit to make it easier to review the
actual driver.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/dsi/dsi.xml.h |  502 
 drivers/gpu/drm/msm/dsi/mmss_cc.xml.h |  114 
 drivers/gpu/drm/msm/dsi/sfpb.xml.h|   48 ++
 drivers/gpu/drm/msm/hdmi/hdmi.xml.h   |  508 
 drivers/gpu/drm/msm/hdmi/qfprom.xml.h |   50 ++
 drivers/gpu/drm/msm/mdp4/mdp4.xml.h   | 1061 +
 6 files changed, 2283 insertions(+)
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi.xml.h
 create mode 100644 drivers/gpu/drm/msm/dsi/mmss_cc.xml.h
 create mode 100644 drivers/gpu/drm/msm/dsi/sfpb.xml.h
 create mode 100644 drivers/gpu/drm/msm/hdmi/hdmi.xml.h
 create mode 100644 drivers/gpu/drm/msm/hdmi/qfprom.xml.h
 create mode 100644 drivers/gpu/drm/msm/mdp4/mdp4.xml.h

diff --git a/drivers/gpu/drm/msm/dsi/dsi.xml.h 
b/drivers/gpu/drm/msm/dsi/dsi.xml.h
new file mode 100644
index 000..6f8396b
--- /dev/null
+++ b/drivers/gpu/drm/msm/dsi/dsi.xml.h
@@ -0,0 +1,502 @@
+#ifndef DSI_XML
+#define DSI_XML
+
+/* Autogenerated file, DO NOT EDIT manually!
+
+This file was generated by the rules-ng-ng headergen tool in this git 
repository:
+http://0x04.net/cgit/index.cgi/rules-ng-ng
+git clone git://0x04.net/rules-ng-ng
+
+The rules-ng-ng source files this header was generated from are:
+- /home/robclark/src/freedreno/envytools/rnndb/msm.xml (
595 bytes, from 2013-07-05 19:21:12)
+- /home/robclark/src/freedreno/envytools/rnndb/freedreno_copyright.xml (   
1453 bytes, from 2013-03-31 16:51:27)
+- /home/robclark/src/freedreno/envytools/rnndb/mdp4/mdp4.xml   (  
19332 bytes, from 2013-08-16 22:16:36)
+- /home/robclark/src/freedreno/envytools/rnndb/dsi/dsi.xml (  
11712 bytes, from 2013-08-17 17:13:43)
+- /home/robclark/src/freedreno/envytools/rnndb/dsi/sfpb.xml(
344 bytes, from 2013-08-11 19:26:32)
+- /home/robclark/src/freedreno/envytools/rnndb/dsi/mmss_cc.xml (   
1544 bytes, from 2013-08-16 19:17:05)
+- /home/robclark/src/freedreno/envytools/rnndb/hdmi/qfprom.xml (
600 bytes, from 2013-07-05 19:21:12)
+- /home/robclark/src/freedreno/envytools/rnndb/hdmi/hdmi.xml   (  
19288 bytes, from 2013-08-11 18:14:15)
+
+Copyright (C) 2013 by the following authors:
+- Rob Clark  (robclark)
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice (including the
+next paragraph) shall be included in all copies or substantial
+portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE COPYRIGHT OWNER(S) AND/OR ITS SUPPLIERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+*/
+
+
+enum dsi_traffic_mode {
+   NON_BURST_SYNCH_PULSE = 0,
+   NON_BURST_SYNCH_EVENT = 1,
+   BURST_MODE = 2,
+};
+
+enum dsi_dst_format {
+   DST_FORMAT_RGB565 = 0,
+   DST_FORMAT_RGB666 = 1,
+   DST_FORMAT_RGB666_LOOSE = 2,
+   DST_FORMAT_RGB888 = 3,
+};
+
+enum dsi_rgb_swap {
+   SWAP_RGB = 0,
+   SWAP_RBG = 1,
+   SWAP_BGR = 2,
+   SWAP_BRG = 3,
+   SWAP_GRB = 4,
+   SWAP_GBR = 5,
+};
+
+enum dsi_cmd_trigger {
+   TRIGGER_NONE = 0,
+   TRIGGER_TE = 2,
+   TRIGGER_SW = 4,
+   TRIGGER_SW_SEOF = 5,
+   TRIGGER_SW_TE = 6,
+};
+
+#define DSI_IRQ_CMD_DMA_DONE   0x0001
+#define DSI_IRQ_MASK_CMD_DMA_DONE  0x0002
+#define DSI_IRQ_CMD_MDP_DONE   0x0100
+#define DSI_IRQ_MASK_CMD_MDP_DONE  0x0200
+#define DSI_IRQ_VIDEO_DONE 0x0001
+#define DSI_IRQ_MASK_VIDEO_DONE
0x0002
+#define DSI_IRQ_ERROR  0x0100
+#define DSI_IRQ_MASK_ERROR 0x0200
+#define REG_DSI_CTRL   0x
+#define DSI_CTRL_ENABLE
0x0001
+#define DSI_CTRL_VID_MODE_EN   0x0002
+#define DSI_CTRL_CMD_MODE_

[PATCHv4 2/5] drm/msm: basic KMS driver for snapdragon

2013-08-24 Thread Rob Clark 
The snapdragon chips have multiple different display controllers,
depending on which chip variant/version.  (As far as I can tell, current
devices have either MDP3 or MDP4, and upcoming devices have MDSS.)  And
then external to the display controller are HDMI, DSI, etc. blocks which
may be shared across devices which have different display controller
blocks.

To more easily add support for different display controller blocks, the
display controller specific bits are split out into a "kms" module,
which provides the kms plane/crtc/encoder objects.

The external HDMI, DSI, etc. blocks are part encoder, and part connector
currently.  But I think I will pull in the drm_bridge patches from
chromeos tree, and split them into a bridge+connector, with the
registers that need to be set in modeset handled by the bridge.  This
would remove the 'msm_connector' base class.  But some things need to be
double checked to make sure I could get the correct ON/OFF sequencing..

This patch adds support for mdp4 crtc (including hw cursor), dtv encoder
(part of MDP4 block), and hdmi.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/Kconfig |   2 +
 drivers/gpu/drm/Makefile|   1 +
 drivers/gpu/drm/msm/Kconfig |  34 ++
 drivers/gpu/drm/msm/Makefile|  25 +
 drivers/gpu/drm/msm/NOTES   |  69 +++
 drivers/gpu/drm/msm/hdmi/hdmi.c | 235 ++
 drivers/gpu/drm/msm/hdmi/hdmi.h | 112 +
 drivers/gpu/drm/msm/hdmi/hdmi_connector.c   | 461 +++
 drivers/gpu/drm/msm/hdmi/hdmi_i2c.c | 281 
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c| 141 ++
 drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c| 214 +
 drivers/gpu/drm/msm/mdp4/mdp4_crtc.c| 684 
 drivers/gpu/drm/msm/mdp4/mdp4_dtv_encoder.c | 317 +
 drivers/gpu/drm/msm/mdp4/mdp4_format.c  |  56 +++
 drivers/gpu/drm/msm/mdp4/mdp4_irq.c | 203 +
 drivers/gpu/drm/msm/mdp4/mdp4_kms.c | 368 +++
 drivers/gpu/drm/msm/mdp4/mdp4_kms.h | 194 
 drivers/gpu/drm/msm/mdp4/mdp4_plane.c   | 243 ++
 drivers/gpu/drm/msm/msm_connector.c |  34 ++
 drivers/gpu/drm/msm/msm_connector.h |  68 +++
 drivers/gpu/drm/msm/msm_drv.c   | 532 ++
 drivers/gpu/drm/msm/msm_drv.h   | 187 
 drivers/gpu/drm/msm/msm_fb.c| 202 
 drivers/gpu/drm/msm/msm_fbdev.c | 258 +++
 drivers/gpu/drm/msm/msm_gem.c   | 521 +
 drivers/gpu/drm/msm/msm_gem.h   |  41 ++
 26 files changed, 5483 insertions(+)
 create mode 100644 drivers/gpu/drm/msm/Kconfig
 create mode 100644 drivers/gpu/drm/msm/Makefile
 create mode 100644 drivers/gpu/drm/msm/NOTES
 create mode 100644 drivers/gpu/drm/msm/hdmi/hdmi.c
 create mode 100644 drivers/gpu/drm/msm/hdmi/hdmi.h
 create mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_connector.c
 create mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_i2c.c
 create mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_phy_8960.c
 create mode 100644 drivers/gpu/drm/msm/hdmi/hdmi_phy_8x60.c
 create mode 100644 drivers/gpu/drm/msm/mdp4/mdp4_crtc.c
 create mode 100644 drivers/gpu/drm/msm/mdp4/mdp4_dtv_encoder.c
 create mode 100644 drivers/gpu/drm/msm/mdp4/mdp4_format.c
 create mode 100644 drivers/gpu/drm/msm/mdp4/mdp4_irq.c
 create mode 100644 drivers/gpu/drm/msm/mdp4/mdp4_kms.c
 create mode 100644 drivers/gpu/drm/msm/mdp4/mdp4_kms.h
 create mode 100644 drivers/gpu/drm/msm/mdp4/mdp4_plane.c
 create mode 100644 drivers/gpu/drm/msm/msm_connector.c
 create mode 100644 drivers/gpu/drm/msm/msm_connector.h
 create mode 100644 drivers/gpu/drm/msm/msm_drv.c
 create mode 100644 drivers/gpu/drm/msm/msm_drv.h
 create mode 100644 drivers/gpu/drm/msm/msm_fb.c
 create mode 100644 drivers/gpu/drm/msm/msm_fbdev.c
 create mode 100644 drivers/gpu/drm/msm/msm_gem.c
 create mode 100644 drivers/gpu/drm/msm/msm_gem.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 626bc0c..39573c5 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -223,3 +223,5 @@ source "drivers/gpu/drm/omapdrm/Kconfig"
 source "drivers/gpu/drm/tilcdc/Kconfig"

 source "drivers/gpu/drm/qxl/Kconfig"
+
+source "drivers/gpu/drm/msm/Kconfig"
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 7b2343a..f089adf 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -54,4 +54,5 @@ obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/
 obj-$(CONFIG_DRM_OMAP) += omapdrm/
 obj-$(CONFIG_DRM_TILCDC)   += tilcdc/
 obj-$(CONFIG_DRM_QXL) += qxl/
+obj-$(CONFIG_DRM_MSM) += msm/
 obj-y  += i2c/
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
new file mode 100644
index 000..a06c19c
--- /dev/null
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -0,0 +1,34 @@
+
+config DRM_MSM
+   tristate "MSM DRM"
+   depend

[PATCHv4 3/5] drm/msm: add register definitions for gpu

2013-08-24 Thread Rob Clark 
Generated from rnndb files in:

https://github.com/freedreno/envytools

Keep this split out as a separate commit to make it easier to review the
actual driver.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/adreno/a2xx.xml.h  | 1438 
 drivers/gpu/drm/msm/adreno/a3xx.xml.h  | 2193 
 drivers/gpu/drm/msm/adreno/adreno_common.xml.h |  432 +
 drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h|  254 +++
 4 files changed, 4317 insertions(+)
 create mode 100644 drivers/gpu/drm/msm/adreno/a2xx.xml.h
 create mode 100644 drivers/gpu/drm/msm/adreno/a3xx.xml.h
 create mode 100644 drivers/gpu/drm/msm/adreno/adreno_common.xml.h
 create mode 100644 drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h

diff --git a/drivers/gpu/drm/msm/adreno/a2xx.xml.h 
b/drivers/gpu/drm/msm/adreno/a2xx.xml.h
new file mode 100644
index 000..3546386
--- /dev/null
+++ b/drivers/gpu/drm/msm/adreno/a2xx.xml.h
@@ -0,0 +1,1438 @@
+#ifndef A2XX_XML
+#define A2XX_XML
+
+/* Autogenerated file, DO NOT EDIT manually!
+
+This file was generated by the rules-ng-ng headergen tool in this git 
repository:
+http://0x04.net/cgit/index.cgi/rules-ng-ng
+git clone git://0x04.net/rules-ng-ng
+
+The rules-ng-ng source files this header was generated from are:
+- /home/robclark/src/freedreno/envytools/rnndb/adreno.xml  (
327 bytes, from 2013-07-05 19:21:12)
+- /home/robclark/src/freedreno/envytools/rnndb/freedreno_copyright.xml (   
1453 bytes, from 2013-03-31 16:51:27)
+- /home/robclark/src/freedreno/envytools/rnndb/a2xx/a2xx.xml   (  
30005 bytes, from 2013-07-19 21:30:48)
+- /home/robclark/src/freedreno/envytools/rnndb/adreno_common.xml   (   
8983 bytes, from 2013-07-24 01:38:36)
+- /home/robclark/src/freedreno/envytools/rnndb/adreno_pm4.xml  (   
9712 bytes, from 2013-05-26 15:22:37)
+- /home/robclark/src/freedreno/envytools/rnndb/a3xx/a3xx.xml   (  
51415 bytes, from 2013-08-03 14:26:05)
+
+Copyright (C) 2013 by the following authors:
+- Rob Clark  (robclark)
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice (including the
+next paragraph) shall be included in all copies or substantial
+portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE COPYRIGHT OWNER(S) AND/OR ITS SUPPLIERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+*/
+
+
+enum a2xx_rb_dither_type {
+   DITHER_PIXEL = 0,
+   DITHER_SUBPIXEL = 1,
+};
+
+enum a2xx_colorformatx {
+   COLORX_4_4_4_4 = 0,
+   COLORX_1_5_5_5 = 1,
+   COLORX_5_6_5 = 2,
+   COLORX_8 = 3,
+   COLORX_8_8 = 4,
+   COLORX_8_8_8_8 = 5,
+   COLORX_S8_8_8_8 = 6,
+   COLORX_16_FLOAT = 7,
+   COLORX_16_16_FLOAT = 8,
+   COLORX_16_16_16_16_FLOAT = 9,
+   COLORX_32_FLOAT = 10,
+   COLORX_32_32_FLOAT = 11,
+   COLORX_32_32_32_32_FLOAT = 12,
+   COLORX_2_3_3 = 13,
+   COLORX_8_8_8 = 14,
+};
+
+enum a2xx_sq_surfaceformat {
+   FMT_1_REVERSE = 0,
+   FMT_1 = 1,
+   FMT_8 = 2,
+   FMT_1_5_5_5 = 3,
+   FMT_5_6_5 = 4,
+   FMT_6_5_5 = 5,
+   FMT_8_8_8_8 = 6,
+   FMT_2_10_10_10 = 7,
+   FMT_8_A = 8,
+   FMT_8_B = 9,
+   FMT_8_8 = 10,
+   FMT_Cr_Y1_Cb_Y0 = 11,
+   FMT_Y1_Cr_Y0_Cb = 12,
+   FMT_5_5_5_1 = 13,
+   FMT_8_8_8_8_A = 14,
+   FMT_4_4_4_4 = 15,
+   FMT_10_11_11 = 16,
+   FMT_11_11_10 = 17,
+   FMT_DXT1 = 18,
+   FMT_DXT2_3 = 19,
+   FMT_DXT4_5 = 20,
+   FMT_24_8 = 22,
+   FMT_24_8_FLOAT = 23,
+   FMT_16 = 24,
+   FMT_16_16 = 25,
+   FMT_16_16_16_16 = 26,
+   FMT_16_EXPAND = 27,
+   FMT_16_16_EXPAND = 28,
+   FMT_16_16_16_16_EXPAND = 29,
+   FMT_16_FLOAT = 30,
+   FMT_16_16_FLOAT = 31,
+   FMT_16_16_16_16_FLOAT = 32,
+   FMT_32 = 33,
+   FMT_32_32 = 34,
+   FMT_32_32_32_32 = 35,
+   FMT_32_FLOAT = 36,
+   FMT_32_32_FLOAT = 37,
+   FMT_32_32_32_32_FLOAT = 38,
+   FMT_32_AS_8 = 39,
+   FMT_32_AS_8_8 = 40,
+   FMT_16_MPEG = 41,
+   FMT_16_16_MPEG = 42,
+   FMT_8_INTERLACED = 43,
+   FMT_32_AS_8_INTERLACED = 44,
+   FMT_32_AS_8_8_INTERLACED = 45,
+   FMT_16_INTERLACED = 46,
+   FMT_16_MPE

[PATCHv4 4/5] drm/msm: add a3xx gpu support

2013-08-24 Thread Rob Clark 
Add initial support for a3xx 3d core.

So far, with hardware that I've seen to date, we can have:
 + zero, one, or two z180 2d cores
 + a3xx or a2xx 3d core, which share a common CP (the firmware
   for the CP seems to implement some different PM4 packet types
   but the basics of cmdstream submission are the same)

Which means that the eventual complete "class" hierarchy, once
support for all past and present hw is in place, becomes:
 + msm_gpu
   + adreno_gpu
 + a3xx_gpu
 + a2xx_gpu
   + z180_gpu

This commit splits out the parts that will eventually be common
between a2xx/a3xx into adreno_gpu, and the parts that are even
common to z180 into msm_gpu.

Note that there is no cmdstream validation required.  All memory access
from the GPU is via IOMMU/MMU.  So as long as you don't map silly things
to the GPU, there isn't much damage that the GPU can do.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/Makefile|   7 +-
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   | 501 
 drivers/gpu/drm/msm/adreno/a3xx_gpu.h   |  30 ++
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 350 ++
 drivers/gpu/drm/msm/adreno/adreno_gpu.h | 142 +
 drivers/gpu/drm/msm/msm_drv.c   | 246 +++-
 drivers/gpu/drm/msm/msm_drv.h   |  44 ++-
 drivers/gpu/drm/msm/msm_gem.c   |  84 +-
 drivers/gpu/drm/msm/msm_gem.h   |  58 
 drivers/gpu/drm/msm/msm_gem_submit.c| 412 ++
 drivers/gpu/drm/msm/msm_gpu.c   | 411 ++
 drivers/gpu/drm/msm/msm_gpu.h   | 114 
 drivers/gpu/drm/msm/msm_ringbuffer.c|  61 
 drivers/gpu/drm/msm/msm_ringbuffer.h|  43 +++
 include/uapi/drm/Kbuild |   1 +
 include/uapi/drm/msm_drm.h  | 207 +
 16 files changed, 2695 insertions(+), 16 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/adreno/a3xx_gpu.c
 create mode 100644 drivers/gpu/drm/msm/adreno/a3xx_gpu.h
 create mode 100644 drivers/gpu/drm/msm/adreno/adreno_gpu.c
 create mode 100644 drivers/gpu/drm/msm/adreno/adreno_gpu.h
 create mode 100644 drivers/gpu/drm/msm/msm_gem_submit.c
 create mode 100644 drivers/gpu/drm/msm/msm_gpu.c
 create mode 100644 drivers/gpu/drm/msm/msm_gpu.h
 create mode 100644 drivers/gpu/drm/msm/msm_ringbuffer.c
 create mode 100644 drivers/gpu/drm/msm/msm_ringbuffer.h
 create mode 100644 include/uapi/drm/msm_drm.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 4068122..439dfb5 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -4,6 +4,8 @@ ifeq (, $(findstring -W,$(EXTRA_CFLAGS)))
 endif

 msm-y := \
+   adreno/adreno_gpu.o \
+   adreno/a3xx_gpu.o \
hdmi/hdmi.o \
hdmi/hdmi_connector.o \
hdmi/hdmi_i2c.o \
@@ -18,7 +20,10 @@ msm-y := \
msm_connector.o \
msm_drv.o \
msm_fb.o \
-   msm_gem.o
+   msm_gem.o \
+   msm_gem_submit.o \
+   msm_gpu.o \
+   msm_ringbuffer.o

 msm-$(CONFIG_DRM_MSM_FBDEV) += msm_fbdev.o

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
new file mode 100644
index 000..13d61bb
--- /dev/null
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -0,0 +1,501 @@
+/*
+ * Copyright (C) 2013 Red Hat
+ * Author: Rob Clark 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include "a3xx_gpu.h"
+
+#define A3XX_INT0_MASK \
+   (A3XX_INT0_RBBM_AHB_ERROR |\
+A3XX_INT0_RBBM_ATB_BUS_OVERFLOW | \
+A3XX_INT0_CP_T0_PACKET_IN_IB |\
+A3XX_INT0_CP_OPCODE_ERROR |   \
+A3XX_INT0_CP_RESERVED_BIT_ERROR | \
+A3XX_INT0_CP_HW_FAULT |   \
+A3XX_INT0_CP_IB1_INT |\
+A3XX_INT0_CP_IB2_INT |\
+A3XX_INT0_CP_RB_INT | \
+A3XX_INT0_CP_REG_PROTECT_FAULT |  \
+A3XX_INT0_CP_AHB_ERROR_HALT | \
+A3XX_INT0_UCHE_OOB_ACCESS)
+
+static struct platform_device *a3xx_pdev;
+
+static void a3xx_me_init(struct msm_gpu *gpu)
+{
+   struct msm_ringbuffer *ring = gpu->rb;
+
+   OUT_PKT3(ring, CP_ME_INIT, 17);
+   OUT_RING(ring, 0x03f7);
+   OUT_RING(ring, 0x);
+   OUT_RING(ring, 0x);
+   OUT_RING(ring, 0x);
+   OUT_RING(ring, 0x0080);
+   OUT_RING(ring, 0x0100);
+   OUT_RING(ring, 0x0180);
+

[PATCHv4 5/5] drm/msm: add basic hangcheck/recovery mechanism

2013-08-24 Thread Rob Clark 
A basic, no-frills recovery mechanism in case the gpu gets wedged.  We
could try to be a bit more fancy and restart the next submit after the
one that got wedged, but for now keep it simple.  This is enough to
recover things if, for example, the gpu hangs mid way through a piglit
run.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c   |  1 +
 drivers/gpu/drm/msm/adreno/adreno_gpu.c | 26 +++--
 drivers/gpu/drm/msm/adreno/adreno_gpu.h |  3 +-
 drivers/gpu/drm/msm/msm_gpu.c   | 52 +
 drivers/gpu/drm/msm/msm_gpu.h   | 10 +++
 5 files changed, 87 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index 13d61bb..035bd13 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -371,6 +371,7 @@ static const struct adreno_gpu_funcs funcs = {
.hw_init = a3xx_hw_init,
.pm_suspend = msm_gpu_pm_suspend,
.pm_resume = msm_gpu_pm_resume,
+   .recover = adreno_recover,
.last_fence = adreno_last_fence,
.submit = adreno_submit,
.flush = adreno_flush,
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 282163e..a605847 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -111,6 +111,28 @@ uint32_t adreno_last_fence(struct msm_gpu *gpu)
return adreno_gpu->memptrs->fence;
 }

+void adreno_recover(struct msm_gpu *gpu)
+{
+   struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
+   struct drm_device *dev = gpu->dev;
+   int ret;
+
+   gpu->funcs->pm_suspend(gpu);
+
+   /* reset ringbuffer: */
+   gpu->rb->cur = gpu->rb->start;
+
+   /* reset completed fence seqno, just discard anything pending: */
+   adreno_gpu->memptrs->fence = gpu->submitted_fence;
+
+   gpu->funcs->pm_resume(gpu);
+   ret = gpu->funcs->hw_init(gpu);
+   if (ret) {
+   dev_err(dev->dev, "gpu hw init failed: %d\n", ret);
+   /* hmm, oh well? */
+   }
+}
+
 int adreno_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
struct msm_file_private *ctx)
 {
@@ -119,8 +141,6 @@ int adreno_submit(struct msm_gpu *gpu, struct 
msm_gem_submit *submit,
struct msm_ringbuffer *ring = gpu->rb;
unsigned i, ibs = 0;

-   adreno_gpu->last_fence = submit->fence;
-
for (i = 0; i < submit->nr_cmds; i++) {
switch (submit->cmd[i].type) {
case MSM_SUBMIT_CMD_IB_TARGET_BUF:
@@ -225,7 +245,7 @@ void adreno_show(struct msm_gpu *gpu, struct seq_file *m)
adreno_gpu->rev.patchid);

seq_printf(m, "fence:%d/%d\n", adreno_gpu->memptrs->fence,
-   adreno_gpu->last_fence);
+   gpu->submitted_fence);
seq_printf(m, "rptr: %d\n", adreno_gpu->memptrs->rptr);
seq_printf(m, "wptr: %d\n", adreno_gpu->memptrs->wptr);
seq_printf(m, "rb wptr:  %d\n", get_wptr(gpu->rb));
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index 6b49c4f..f73abfb 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -54,8 +54,6 @@ struct adreno_gpu {
uint32_t revn;  /* numeric revision name */
const struct adreno_gpu_funcs *funcs;

-   uint32_t last_fence;
-
/* firmware: */
const struct firmware *pm4, *pfp;

@@ -99,6 +97,7 @@ static inline bool adreno_is_a330(struct adreno_gpu *gpu)
 int adreno_get_param(struct msm_gpu *gpu, uint32_t param, uint64_t *value);
 int adreno_hw_init(struct msm_gpu *gpu);
 uint32_t adreno_last_fence(struct msm_gpu *gpu);
+void adreno_recover(struct msm_gpu *gpu);
 int adreno_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
struct msm_file_private *ctx);
 void adreno_flush(struct msm_gpu *gpu);
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 7c6541e..e1e1ec9 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -203,6 +203,51 @@ int msm_gpu_pm_suspend(struct msm_gpu *gpu)
 }

 /*
+ * Hangcheck detection for locked gpu:
+ */
+
+static void recover_worker(struct work_struct *work)
+{
+   struct msm_gpu *gpu = container_of(work, struct msm_gpu, recover_work);
+   struct drm_device *dev = gpu->dev;
+
+   dev_err(dev->dev, "%s: hangcheck recover!\n", gpu->name);
+
+   mutex_lock(&dev->struct_mutex);
+   gpu->funcs->recover(gpu);
+   mutex_unlock(&dev->struct_mutex);
+
+   msm_gpu_retire(gpu);
+}
+
+static void hangcheck_timer_reset(struct msm_gpu *gpu)
+{
+   DBG("%s", gpu->name);
+   mod_timer(&gpu->hangcheck_timer,
+   round_jiffies_up(jiffies + DRM_MSM_HANGCHECK_JIFFIES));

[Bug 64582] [r600g/vdpau] Inconsistency detected by ld.so: dl-close.c: 765: _dl_close: Assertion `map->l_init_called' failed!

2013-08-24 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=64582

--- Comment #4 from John  ---
Same issue here:
Inconsistency detected by ld.so: dl-close.c: 771: _dl_close: Assertion
`map->l_init_called' failed!

Mesa 9.2rc2 (same with rc1), dri2proto 2.8, libvdpau 0.7.
I believe my distribution's libvdpau was compiled with dri2proto support, but
is there a way to confirm?

-- 
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/20130824/09482fd5/attachment.html>

[Bug 68503] Graphical glitches in Serious Sam 3 when SB is enabled

2013-08-24 Thread bugzilla-dae...@freedesktop.org 
https://bugs.freedesktop.org/show_bug.cgi?id=68503

--- Comment #5 from Vadim Girlin  ---
Created attachment 84573
  --> https://bugs.freedesktop.org/attachment.cgi?id=84573&action=edit
patch

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/20130824/7f52e010/attachment.html>

[PATCH V3] i2c: move of helpers into the core

2013-08-24 Thread Mauro Carvalho Chehab 
Em Thu, 22 Aug 2013 18:00:14 +0200
Wolfram Sang  escreveu:

> I2C of helpers used to live in of_i2c.c but experience (from SPI) shows
> that it is much cleaner to have this in the core. This also removes a
> circular dependency between the helpers and the core, and so we can
> finally register child nodes in the core instead of doing this manually
> in each driver. So, fix the drivers and documentation, too.
> 
> Acked-by: Rob Herring 
> Reviewed-by: Felipe Balbi 
> Acked-by: Rafael J. Wysocki 
> Tested-by: Sylwester Nawrocki 
> Signed-off-by: Wolfram Sang 

Acked-by: Mauro Carvalho Chehab 

> ---
> 
> V2->V3: Was trying to be too smart by only fixing includes needed.
>   Took a more general approach this time, converting of_i2c.h
>   to i2c.h in case i2c.h was not already there. Otherwise
>   remove it. Improved my build scripts and no build failures,
>   no complaints from buildbot as well.
> 
> 
>  Documentation/acpi/enumeration.txt  |1 -
>  arch/powerpc/platforms/44x/warp.c   |1 -
>  drivers/gpu/drm/tilcdc/tilcdc_slave.c   |1 -
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c  |1 -
>  drivers/gpu/host1x/drm/output.c |2 +-
>  drivers/i2c/busses/i2c-at91.c   |3 -
>  drivers/i2c/busses/i2c-cpm.c|6 --
>  drivers/i2c/busses/i2c-davinci.c|2 -
>  drivers/i2c/busses/i2c-designware-platdrv.c |2 -
>  drivers/i2c/busses/i2c-gpio.c   |3 -
>  drivers/i2c/busses/i2c-i801.c   |2 -
>  drivers/i2c/busses/i2c-ibm_iic.c|4 -
>  drivers/i2c/busses/i2c-imx.c|3 -
>  drivers/i2c/busses/i2c-mpc.c|2 -
>  drivers/i2c/busses/i2c-mv64xxx.c|3 -
>  drivers/i2c/busses/i2c-mxs.c|3 -
>  drivers/i2c/busses/i2c-nomadik.c|3 -
>  drivers/i2c/busses/i2c-ocores.c |3 -
>  drivers/i2c/busses/i2c-octeon.c |3 -
>  drivers/i2c/busses/i2c-omap.c   |3 -
>  drivers/i2c/busses/i2c-pnx.c|3 -
>  drivers/i2c/busses/i2c-powermac.c   |9 +-
>  drivers/i2c/busses/i2c-pxa.c|2 -
>  drivers/i2c/busses/i2c-s3c2410.c|2 -
>  drivers/i2c/busses/i2c-sh_mobile.c  |2 -
>  drivers/i2c/busses/i2c-sirf.c   |3 -
>  drivers/i2c/busses/i2c-stu300.c |2 -
>  drivers/i2c/busses/i2c-tegra.c  |3 -
>  drivers/i2c/busses/i2c-versatile.c  |2 -
>  drivers/i2c/busses/i2c-wmt.c|3 -
>  drivers/i2c/busses/i2c-xiic.c   |3 -
>  drivers/i2c/i2c-core.c  |  109 +-
>  drivers/i2c/i2c-mux.c   |3 -
>  drivers/i2c/muxes/i2c-arb-gpio-challenge.c  |1 -
>  drivers/i2c/muxes/i2c-mux-gpio.c|1 -
>  drivers/i2c/muxes/i2c-mux-pinctrl.c |1 -
>  drivers/media/platform/exynos4-is/fimc-is-i2c.c |4 +-
>  drivers/media/platform/exynos4-is/fimc-is.c |2 +-
>  drivers/media/platform/exynos4-is/media-dev.c   |1 -
>  drivers/of/Kconfig  |6 --
>  drivers/of/Makefile |1 -
>  drivers/of/of_i2c.c |  114 
> ---
>  drivers/staging/imx-drm/imx-tve.c   |2 +-
>  include/linux/i2c.h |   20 
>  include/linux/of_i2c.h  |   46 -
>  sound/soc/fsl/imx-sgtl5000.c|2 +-
>  sound/soc/fsl/imx-wm8962.c  |2 +-
>  47 files changed, 138 insertions(+), 262 deletions(-)
>  delete mode 100644 drivers/of/of_i2c.c
>  delete mode 100644 include/linux/of_i2c.h
> 
> diff --git a/Documentation/acpi/enumeration.txt 
> b/Documentation/acpi/enumeration.txt
> index d9be7a9..958266e 100644
> --- a/Documentation/acpi/enumeration.txt
> +++ b/Documentation/acpi/enumeration.txt
> @@ -238,7 +238,6 @@ An I2C bus (controller) driver does:
>   if (ret)
>   /* handle error */
>  
> - of_i2c_register_devices(adapter);
>   /* Enumerate the slave devices behind this bus via ACPI */
>   acpi_i2c_register_devices(adapter);
>  
> diff --git a/arch/powerpc/platforms/44x/warp.c 
> b/arch/powerpc/platforms/44x/warp.c
> index 4cfa499..534574a 100644
> --- a/arch/powerpc/platforms/44x/warp.c
> +++ b/arch/powerpc/platforms/44x/warp.c
> @@ -16,7 +16,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_slave.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> index dfffaf0..a19f657 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_slave.c
> @@ -16,7 +16,6 @@
>   */
>  
>