[Bug 67107] Xorg starts and crashes with DPM enable

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

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

--- Comment #8 from Christopher Chmielewski  ---
Created attachment 84754
  --> https://bugs.freedesktop.org/attachment.cgi?id=84754=edit
xorg log

Both the dmesg and xorg log are from rc7

-- 
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/20130827/76163d01/attachment.html>

[Bug 67107] Xorg starts and crashes with DPM enable

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

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

--- Comment #7 from Christopher Chmielewski  ---
Created attachment 84753
  --> https://bugs.freedesktop.org/attachment.cgi?id=84753=edit
dmesg

Like I said it freezes up my computer so I had to restart in single user mode
so there might be some extra stuff at the bottom.

-- 
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/20130827/fc930e39/attachment.html>

[Bug 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

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

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

--- Comment #9 from tux_mind  ---
hello there, i'm having the same issue and i recompiled mesa with debugging
symbols.
i'm using mesa-9.2.0_rc1 on gentoo.
i attached gdb and i found that the issue is at
src/gallium/drivers/r600/r600_query.c:743.

735 void r600_init_query_functions(struct r600_context *rctx)
736 {
737 rctx->context.create_query = r600_create_query;
738 rctx->context.destroy_query = r600_destroy_query;
739 rctx->context.begin_query = r600_begin_query;
740 rctx->context.end_query = r600_end_query;
741 rctx->context.get_query_result = r600_get_query_result;
742
743 if (rctx->screen->info.r600_num_backends > 0)

breaking gdb on line 743 i got this: http://pastebin.com/A4JANB5F

as you can see rctx->screen is null ( 0x0 ), please, can you fix that?

i hope this helps.

-- 
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/20130827/aa2114d5/attachment.html>

[Bug 68585] Recent Mesa git make Kwin crash with AMD R300g driver

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

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

--- Comment #8 from Richard Van Den Boom  ---
I did a git pull to be as possible up to date and applied the patch.
It does indeed seem to fix Kwin crash at startup.
Congratulations!

-- 
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/20130827/eb825322/attachment.html>

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

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

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

--- Comment #12 from Peter Kraus  ---
Hello,
I guess I'm just really unlucky. Compilation of "required merge" according to
git bisect fails with:

CXXLDlibOSMesa.la
/usr/bin/ld: i386:x86-64 architecture of input file
`../../../../src/mesa/.libs/libmesa.a(ast_expr.o)' is incompatible with i386
output

Which is similar to a bug report here: bug 50754. Adding those variables into
the build script doesn't help (in fact, they've been in before). Looks like I'm
stuffed yet 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/20130827/fc7230e4/attachment.html>

[Bug 68585] Recent Mesa git make Kwin crash with AMD R300g driver

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

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

--- Comment #7 from Richard Van Den Boom  ---
I'll see what I can do.

-- 
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/20130827/251a3443/attachment-0001.html>

[Bug 68585] Recent Mesa git make Kwin crash with AMD R300g driver

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

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

--- Comment #6 from Marek Ol??k  ---
Created attachment 84748
  --> https://bugs.freedesktop.org/attachment.cgi?id=84748=edit
possible fix

Could you please test this patch?

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

[Bug 52952] Ubuntu 10.04.4 LTS 32-bit and ATI Technologies Radeon Xpress 200 for Intel (RC410) ACPI S3 State Resume Failure

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

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

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

Does this patch help?

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

[PATCH] dma-buf: Check return value of anon_inode_getfile

[Tuomas Tynkkynen]

anon_inode_getfile might fail, so check its return value.

Signed-off-by: Tuomas Tynkkynen 
---
 drivers/base/dma-buf.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 1219ab7..2d5ac1a 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -133,7 +133,10 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
struct dma_buf_ops *ops,
dmabuf->exp_name = exp_name;

file = anon_inode_getfile("dmabuf", _buf_fops, dmabuf, flags);
-
+   if (IS_ERR(file)) {
+   kfree(dmabuf);
+   return ERR_CAST(file);
+   }
dmabuf->file = file;

mutex_init(>lock);
-- 
1.8.1.5

[PATCH 9/9] drm/nouveau: Simplify event handler interface

[Peter Hurley]

Remove index parameter; access index via handler->index instead.
Dissociate handler from related container; use handler->priv to
access container.

Signed-off-by: Peter Hurley 
---
 drivers/gpu/drm/nouveau/core/core/event.c   | 6 +++---
 drivers/gpu/drm/nouveau/core/engine/software/nv50.c | 7 +++
 drivers/gpu/drm/nouveau/core/engine/software/nvc0.c | 7 +++
 drivers/gpu/drm/nouveau/core/include/core/event.h   | 6 +++---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 9 +
 drivers/gpu/drm/nouveau/nouveau_drm.c   | 9 +
 drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +-
 7 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
index b7d8ae1..1240fef 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -26,7 +26,7 @@

 void
 nouveau_event_handler_install(struct nouveau_event *event, int index,
- int (*func)(struct nouveau_eventh*, int),
+ int (*func)(struct nouveau_eventh*),
  void *priv, struct nouveau_eventh *handler)
 {
unsigned long flags;
@@ -61,7 +61,7 @@ nouveau_event_handler_remove(struct nouveau_eventh *handler)

 int
 nouveau_event_handler_create(struct nouveau_event *event, int index,
-int (*func)(struct nouveau_eventh*, int),
+int (*func)(struct nouveau_eventh*),
 void *priv, struct nouveau_eventh **phandler)
 {
struct nouveau_eventh *handler;
@@ -157,7 +157,7 @@ nouveau_event_trigger(struct nouveau_event *event, int 
index)
rcu_read_lock();
list_for_each_entry_rcu(handler, >index[index].list, head) {
if (test_bit(NVKM_EVENT_ENABLE, >flags)) {
-   if (handler->func(handler, index) == NVKM_EVENT_DROP)
+   if (handler->func(handler) == NVKM_EVENT_DROP)
nouveau_event_put(handler);
}
}
diff --git a/drivers/gpu/drm/nouveau/core/engine/software/nv50.c 
b/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
index e969f0c..bf6f23b 100644
--- a/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
+++ b/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
@@ -131,10 +131,9 @@ nv50_software_sclass[] = {
  
**/

 static int
-nv50_software_vblsem_release(struct nouveau_eventh *event, int head)
+nv50_software_vblsem_release(struct nouveau_eventh *handler)
 {
-   struct nouveau_software_chan *chan =
-   container_of(event, struct nouveau_software_chan, 
vblank.event[head]);
+   struct nouveau_software_chan *chan = handler->priv;
struct nv50_software_priv *priv = (void *)nv_object(chan)->engine;
struct nouveau_bar *bar = nouveau_bar(priv);

@@ -172,7 +171,7 @@ nv50_software_context_ctor(struct nouveau_object *parent,
for (i = 0; i < ARRAY_SIZE(chan->base.vblank.event); i++) {
nouveau_event_handler_install(disp->vblank, i,
  nv50_software_vblsem_release,
- NULL,
+ chan,
  >base.vblank.event[i]);
}
return 0;
diff --git a/drivers/gpu/drm/nouveau/core/engine/software/nvc0.c 
b/drivers/gpu/drm/nouveau/core/engine/software/nvc0.c
index d06658a..1a2a7a8 100644
--- a/drivers/gpu/drm/nouveau/core/engine/software/nvc0.c
+++ b/drivers/gpu/drm/nouveau/core/engine/software/nvc0.c
@@ -143,10 +143,9 @@ nvc0_software_sclass[] = {
  
**/

 static int
-nvc0_software_vblsem_release(struct nouveau_eventh *event, int head)
+nvc0_software_vblsem_release(struct nouveau_eventh *handler)
 {
-   struct nouveau_software_chan *chan =
-   container_of(event, struct nouveau_software_chan, 
vblank.event[head]);
+   struct nouveau_software_chan *chan = handler->priv;
struct nvc0_software_priv *priv = (void *)nv_object(chan)->engine;
struct nouveau_bar *bar = nouveau_bar(priv);

@@ -178,7 +177,7 @@ nvc0_software_context_ctor(struct nouveau_object *parent,
for (i = 0; i < ARRAY_SIZE(chan->base.vblank.event); i++) {
nouveau_event_handler_install(disp->vblank, i,
  nvc0_software_vblsem_release,
- NULL,
+ chan,
  >base.vblank.event[i]);
}
return 0;
diff --git a/drivers/gpu/drm/nouveau/core/include/core/event.h 
b/drivers/gpu/drm/nouveau/core/include/core/event.h
index e839d70..d062176 100644
--- 

[PATCH 8/9] drm/nouveau: Simplify event interface

[Peter Hurley]

Store event back-pointer and index within struct event_handler;
remove superfluous parameters when event_handler is supplied.

Signed-off-by: Peter Hurley 
---
 drivers/gpu/drm/nouveau/core/core/event.c  | 36 +-
 .../gpu/drm/nouveau/core/engine/software/nv50.c| 11 ++-
 .../gpu/drm/nouveau/core/engine/software/nvc0.c| 11 ++-
 drivers/gpu/drm/nouveau/core/include/core/event.h  | 15 +
 drivers/gpu/drm/nouveau/nouveau_connector.c|  5 +--
 drivers/gpu/drm/nouveau/nouveau_display.c  | 16 +++---
 drivers/gpu/drm/nouveau/nouveau_drm.c  | 10 ++
 drivers/gpu/drm/nouveau/nouveau_fence.c|  2 +-
 8 files changed, 44 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
index 45bcb37..b7d8ae1 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -34,6 +34,9 @@ nouveau_event_handler_install(struct nouveau_event *event, 
int index,
if (index >= event->index_nr)
return;

+   handler->event = event;
+   handler->index = index;
+
handler->func = func;
handler->priv = priv;

@@ -43,12 +46,12 @@ nouveau_event_handler_install(struct nouveau_event *event, 
int index,
 }

 void
-nouveau_event_handler_remove(struct nouveau_event *event, int index,
-struct nouveau_eventh *handler)
+nouveau_event_handler_remove(struct nouveau_eventh *handler)
 {
+   struct nouveau_event *event = handler->event;
unsigned long flags;

-   if (index >= event->index_nr)
+   if (!event)
return;

spin_lock_irqsave(>lock, flags);
@@ -67,6 +70,10 @@ nouveau_event_handler_create(struct nouveau_event *event, 
int index,
handler = *phandler = kzalloc(sizeof(*handler), GFP_KERNEL);
if (!handler)
return -ENOMEM;
+
+   handler->event = event;
+   handler->index = index;
+
handler->func = func;
handler->priv = priv;
__set_bit(NVKM_EVENT_ENABLE, >flags);
@@ -82,13 +89,12 @@ nouveau_event_handler_create(struct nouveau_event *event, 
int index,
 }

 void
-nouveau_event_handler_destroy(struct nouveau_event *event, int index,
- struct nouveau_eventh *handler)
+nouveau_event_handler_destroy(struct nouveau_eventh *handler)
 {
+   struct nouveau_event *event = handler->event;
+   int index = handler->index;
unsigned long flags;

-   if (index >= event->index_nr)
-   return;

spin_lock_irqsave(>lock, flags);
if (!--event->index[index].refs) {
@@ -101,12 +107,13 @@ nouveau_event_handler_destroy(struct nouveau_event 
*event, int index,
 }

 void
-nouveau_event_put(struct nouveau_event *event, int index,
- struct nouveau_eventh *handler)
+nouveau_event_put(struct nouveau_eventh *handler)
 {
+   struct nouveau_event *event = handler->event;
+   int index = handler->index;
unsigned long flags;

-   if (index >= event->index_nr)
+   if (!event)
return;

spin_lock_irqsave(>lock, flags);
@@ -120,12 +127,13 @@ nouveau_event_put(struct nouveau_event *event, int index,
 }

 void
-nouveau_event_get(struct nouveau_event *event, int index,
- struct nouveau_eventh *handler)
+nouveau_event_get(struct nouveau_eventh *handler)
 {
+   struct nouveau_event *event = handler->event;
+   int index = handler->index;
unsigned long flags;

-   if (index >= event->index_nr)
+   if (!event)
return;

spin_lock_irqsave(>lock, flags);
@@ -150,7 +158,7 @@ nouveau_event_trigger(struct nouveau_event *event, int 
index)
list_for_each_entry_rcu(handler, >index[index].list, head) {
if (test_bit(NVKM_EVENT_ENABLE, >flags)) {
if (handler->func(handler, index) == NVKM_EVENT_DROP)
-   nouveau_event_put(event, index, handler);
+   nouveau_event_put(handler);
}
}
rcu_read_unlock();
diff --git a/drivers/gpu/drm/nouveau/core/engine/software/nv50.c 
b/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
index 87aeee1..e969f0c 100644
--- a/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
+++ b/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
@@ -92,12 +92,11 @@ nv50_software_mthd_vblsem_release(struct nouveau_object 
*object, u32 mthd,
  void *args, u32 size)
 {
struct nv50_software_chan *chan = (void *)nv_engctx(object->parent);
-   struct nouveau_disp *disp = nouveau_disp(object);
u32 crtc = *(u32 *)args;
if (crtc > 1)
return -EINVAL;

-   nouveau_event_get(disp->vblank, crtc, >base.vblank.event[crtc]);
+   nouveau_event_get(>base.vblank.event[crtc]);
return 0;
 }

@@ -183,14 

[PATCH 7/9] drm/nouveau: Fold nouveau_event_put_locked into caller

[Peter Hurley]

nouveau_event_put_locked() only has 1 call site; fold into caller.

Signed-off-by: Peter Hurley 
---
 drivers/gpu/drm/nouveau/core/core/event.c | 19 ++-
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
index ce0a0ef..45bcb37 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -100,18 +100,6 @@ nouveau_event_handler_destroy(struct nouveau_event *event, 
int index,
kfree_rcu(handler, rcu);
 }

-static void
-nouveau_event_put_locked(struct nouveau_event *event, int index,
-struct nouveau_eventh *handler)
-{
-   if (__test_and_clear_bit(NVKM_EVENT_ENABLE, >flags)) {
-   if (!--event->index[index].refs) {
-   if (event->disable)
-   event->disable(event, index);
-   }
-   }
-}
-
 void
 nouveau_event_put(struct nouveau_event *event, int index,
  struct nouveau_eventh *handler)
@@ -122,7 +110,12 @@ nouveau_event_put(struct nouveau_event *event, int index,
return;

spin_lock_irqsave(>lock, flags);
-   nouveau_event_put_locked(event, index, handler);
+   if (__test_and_clear_bit(NVKM_EVENT_ENABLE, >flags)) {
+   if (!--event->index[index].refs) {
+   if (event->disable)
+   event->disable(event, index);
+   }
+   }
spin_unlock_irqrestore(>lock, flags);
 }

-- 
1.8.1.2

[PATCH 6/9] drm/nouveau: Convert event handler list to RCU

[Peter Hurley]

Lockdep report [1] correctly identifies a potential deadlock between
nouveau_drm_vblank_enable() and nouveau_drm_vblank_handler() due
to inverted lock order of event->lock with drm core's
dev->vblank_time_lock.

Fix vblank event deadlock by converting event handler list to RCU.
List updates remain serialized by event->lock.
List traversal & handler execution is lockless which prevents
inverted lock order problems with the drm core.
Safe deletion of the event handler is accomplished with
synchronize_rcu() for those handlers stored in nouveau_object-based
containers (nouveau_drm & nv50_/nvc0_software_context); otherwise,
with kfree_rcu (for nouveau_connector & uevent temporary handlers).

[1]
==
[ INFO: possible circular locking dependency detected ]
3.10.0-0+tip-xeon+lockdep #0+tip Not tainted
---
swapper/7/0 is trying to acquire lock:
 (&(>vblank_time_lock)->rlock){-.}, at: [] 
drm_handle_vblank+0x69/0x400 [drm]

but task is already holding lock:
 (&(>lock)->rlock){-.}, at: [] 
nouveau_event_trigger+0x4d/0xd0 [nouveau]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&(>lock)->rlock){-.}:
   [] lock_acquire+0x92/0x1f0
   [] _raw_spin_lock_irqsave+0x46/0x60
   [] nouveau_event_get+0x27/0xa0 [nouveau]
   [] nouveau_drm_vblank_enable+0x8d/0xf0 [nouveau]
   [] drm_vblank_get+0xf8/0x2c0 [drm]
   [] drm_wait_vblank+0x84/0x6f0 [drm]
   [] drm_ioctl+0x559/0x690 [drm]
   [] do_vfs_ioctl+0x97/0x590
   [] SyS_ioctl+0x91/0xb0
   [] system_call_fastpath+0x16/0x1b

-> #0 (&(>vblank_time_lock)->rlock){-.}:
   [] __lock_acquire+0x1c43/0x1d30
   [] lock_acquire+0x92/0x1f0
   [] _raw_spin_lock_irqsave+0x46/0x60
   [] drm_handle_vblank+0x69/0x400 [drm]
   [] nouveau_drm_vblank_handler+0x27/0x30 [nouveau]
   [] nouveau_event_trigger+0x90/0xd0 [nouveau]
   [] nv50_disp_intr+0xdd/0x230 [nouveau]
   [] nouveau_mc_intr+0xa1/0x100 [nouveau]
   [] handle_irq_event_percpu+0x6c/0x3d0
   [] handle_irq_event+0x48/0x70
   [] handle_fasteoi_irq+0x5a/0x100
   [] handle_irq+0x22/0x40
   [] do_IRQ+0x5a/0xd0
   [] ret_from_intr+0x0/0x13
   [] arch_cpu_idle+0x26/0x30
   [] cpu_startup_entry+0xce/0x410
   [] start_secondary+0x255/0x25c

other info that might help us debug this:

 Possible unsafe locking scenario:

   CPU0CPU1
   
  lock(&(>lock)->rlock);
   lock(&(>vblank_time_lock)->rlock);
   lock(&(>lock)->rlock);
  lock(&(>vblank_time_lock)->rlock);

 *** DEADLOCK ***

1 lock held by swapper/7/0:
 #0:  (&(>lock)->rlock){-.}, at: [] 
nouveau_event_trigger+0x4d/0xd0 [nouveau]

stack backtrace:
CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.10.0-0+tip-xeon+lockdep #0+tip
Hardware name: Dell Inc. Precision WorkStation T5400  /0RW203, BIOS A11 
04/30/2012
 821ccf60 8802bfdc3b08 81755f39 8802bfdc3b58
 8174f526 0002 8802bfdc3be8 8802b330a7f8
 8802b330a820 8802b330a7f8  0001
Call Trace:
   [] dump_stack+0x19/0x1b
 [] print_circular_bug+0x1fb/0x20c
 [] __lock_acquire+0x1c43/0x1d30
 [] ? trace_hardirqs_off+0xd/0x10
 [] ? flat_send_IPI_mask+0x88/0xa0
 [] lock_acquire+0x92/0x1f0
 [] ? drm_handle_vblank+0x69/0x400 [drm]
 [] _raw_spin_lock_irqsave+0x46/0x60
 [] ? drm_handle_vblank+0x69/0x400 [drm]
 [] drm_handle_vblank+0x69/0x400 [drm]
 [] nouveau_drm_vblank_handler+0x27/0x30 [nouveau]
 [] nouveau_event_trigger+0x90/0xd0 [nouveau]
 [] nv50_disp_intr+0xdd/0x230 [nouveau]
 [] ? _raw_spin_unlock_irqrestore+0x42/0x80
 [] ? __hrtimer_start_range_ns+0x16c/0x530
 [] nouveau_mc_intr+0xa1/0x100 [nouveau]
 [] handle_irq_event_percpu+0x6c/0x3d0
 [] handle_irq_event+0x48/0x70
 [] ? handle_fasteoi_irq+0x1e/0x100
 [] handle_fasteoi_irq+0x5a/0x100
 [] handle_irq+0x22/0x40
 [] do_IRQ+0x5a/0xd0
 [] common_interrupt+0x6f/0x6f
   [] ? default_idle+0x1d/0x290
 [] ? default_idle+0x1b/0x290
 [] arch_cpu_idle+0x26/0x30
 [] cpu_startup_entry+0xce/0x410
 [] ? clockevents_register_device+0xdc/0x140
 [] start_secondary+0x255/0x25c

Reported-by: Dave Jones 
Signed-off-by: Peter Hurley 
---
 drivers/gpu/drm/nouveau/core/core/event.c  | 22 +++---
 .../gpu/drm/nouveau/core/engine/software/nv50.c|  1 +
 .../gpu/drm/nouveau/core/engine/software/nvc0.c|  1 +
 drivers/gpu/drm/nouveau/core/include/core/event.h  |  1 +
 drivers/gpu/drm/nouveau/nouveau_connector.c|  2 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c  |  1 +
 6 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
index 4cd1ebe..ce0a0ef 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ 

[PATCH 5/9] drm/nouveau: Add install/remove semantics for event handlers

[Peter Hurley]

Complete migration of nouveau_event_get/_put from add/remove
semantics to enable/disable semantics.

Introduce nouveau_event_handler_install/_remove interface to
add/remove non-local-scope event handlers (ie., those stored in
parent containers). This change in semantics makes explicit the
handler lifetime, and distinguishes "one-of" event handlers
(such as gpio) from "many temporary" event handlers (such as uevent).

Signed-off-by: Peter Hurley 
---
 drivers/gpu/drm/nouveau/core/core/event.c  | 63 +++---
 .../gpu/drm/nouveau/core/engine/software/nv50.c| 31 +--
 .../gpu/drm/nouveau/core/engine/software/nvc0.c| 31 +--
 drivers/gpu/drm/nouveau/core/include/core/event.h  |  6 +++
 .../gpu/drm/nouveau/core/include/engine/software.h |  2 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c| 10 +++-
 drivers/gpu/drm/nouveau/nouveau_drm.c  | 17 +-
 7 files changed, 140 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
index 0a65ede..4cd1ebe 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -23,19 +23,60 @@
 #include 
 #include 

+void
+nouveau_event_handler_install(struct nouveau_event *event, int index,
+ int (*func)(struct nouveau_eventh*, int),
+ void *priv, struct nouveau_eventh *handler)
+{
+   unsigned long flags;
+
+   if (index >= event->index_nr)
+   return;
+
+   handler->func = func;
+   handler->priv = priv;
+
+   spin_lock_irqsave(>lock, flags);
+   list_add(>head, >index[index].list);
+   spin_unlock_irqrestore(>lock, flags);
+}
+
+void
+nouveau_event_handler_remove(struct nouveau_event *event, int index,
+struct nouveau_eventh *handler)
+{
+   unsigned long flags;
+
+   if (index >= event->index_nr)
+   return;
+
+   spin_lock_irqsave(>lock, flags);
+   list_del(>head);
+   spin_unlock_irqrestore(>lock, flags);
+}
+
 int
 nouveau_event_handler_create(struct nouveau_event *event, int index,
 int (*func)(struct nouveau_eventh*, int),
 void *priv, struct nouveau_eventh **phandler)
 {
struct nouveau_eventh *handler;
+   unsigned long flags;

handler = *phandler = kzalloc(sizeof(*handler), GFP_KERNEL);
if (!handler)
return -ENOMEM;
handler->func = func;
handler->priv = priv;
-   nouveau_event_get(event, index, handler);
+   __set_bit(NVKM_EVENT_ENABLE, >flags);
+
+   spin_lock_irqsave(>lock, flags);
+   list_add(>head, >index[index].list);
+   if (!event->index[index].refs++) {
+   if (event->enable)
+   event->enable(event, index);
+   }
+   spin_unlock_irqrestore(>lock, flags);
return 0;
 }

@@ -43,7 +84,18 @@ void
 nouveau_event_handler_destroy(struct nouveau_event *event, int index,
  struct nouveau_eventh *handler)
 {
-   nouveau_event_put(event, index, handler);
+   unsigned long flags;
+
+   if (index >= event->index_nr)
+   return;
+
+   spin_lock_irqsave(>lock, flags);
+   if (!--event->index[index].refs) {
+   if (event->disable)
+   event->disable(event, index);
+   }
+   list_del(>head);
+   spin_unlock_irqrestore(>lock, flags);
kfree(handler);
 }

@@ -56,7 +108,6 @@ nouveau_event_put_locked(struct nouveau_event *event, int 
index,
if (event->disable)
event->disable(event, index);
}
-   list_del(>head);
}
 }

@@ -85,7 +136,6 @@ nouveau_event_get(struct nouveau_event *event, int index,

spin_lock_irqsave(>lock, flags);
if (!__test_and_set_bit(NVKM_EVENT_ENABLE, >flags)) {
-   list_add(>head, >index[index].list);
if (!event->index[index].refs++) {
if (event->enable)
event->enable(event, index);
@@ -105,8 +155,9 @@ nouveau_event_trigger(struct nouveau_event *event, int 
index)

spin_lock_irqsave(>lock, flags);
list_for_each_entry_safe(handler, temp, >index[index].list, 
head) {
-   if (handler->func(handler, index) == NVKM_EVENT_DROP) {
-   nouveau_event_put_locked(event, index, handler);
+   if (test_bit(NVKM_EVENT_ENABLE, >flags)) {
+   if (handler->func(handler, index) == NVKM_EVENT_DROP)
+   nouveau_event_put_locked(event, index, handler);
}
}
spin_unlock_irqrestore(>lock, flags);
diff --git a/drivers/gpu/drm/nouveau/core/engine/software/nv50.c 
b/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
index c48e749..dfce1f5 

[PATCH 4/9] drm/nouveau: Allow asymmetric nouveau_event_get/_put

[Peter Hurley]

Most nouveau event handlers have storage in 'static' containers
(structures with lifetimes nearly equivalent to the drm_device),
but are dangerously reused via nouveau_event_get/_put. For
example, if nouveau_event_get is called more than once for a
given handler, the event handler list will be corrupted.

Migrate nouveau_event_get/_put from add/remove semantics to
enable/disable semantics.

Signed-off-by: Peter Hurley 
---
 drivers/gpu/drm/nouveau/core/core/event.c | 20 
 drivers/gpu/drm/nouveau/core/include/core/event.h |  4 
 drivers/gpu/drm/nouveau/nouveau_drm.c |  8 ++--
 3 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
index 1a8d685..0a65ede 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -51,11 +51,13 @@ static void
 nouveau_event_put_locked(struct nouveau_event *event, int index,
 struct nouveau_eventh *handler)
 {
-   if (!--event->index[index].refs) {
-   if (event->disable)
-   event->disable(event, index);
+   if (__test_and_clear_bit(NVKM_EVENT_ENABLE, >flags)) {
+   if (!--event->index[index].refs) {
+   if (event->disable)
+   event->disable(event, index);
+   }
+   list_del(>head);
}
-   list_del(>head);
 }

 void
@@ -82,10 +84,12 @@ nouveau_event_get(struct nouveau_event *event, int index,
return;

spin_lock_irqsave(>lock, flags);
-   list_add(>head, >index[index].list);
-   if (!event->index[index].refs++) {
-   if (event->enable)
-   event->enable(event, index);
+   if (!__test_and_set_bit(NVKM_EVENT_ENABLE, >flags)) {
+   list_add(>head, >index[index].list);
+   if (!event->index[index].refs++) {
+   if (event->enable)
+   event->enable(event, index);
+   }
}
spin_unlock_irqrestore(>lock, flags);
 }
diff --git a/drivers/gpu/drm/nouveau/core/include/core/event.h 
b/drivers/gpu/drm/nouveau/core/include/core/event.h
index bdf1a0a..3e704d5 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/event.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/event.h
@@ -5,8 +5,12 @@
 #define NVKM_EVENT_DROP 0
 #define NVKM_EVENT_KEEP 1

+/* nouveau_eventh.flags bit #s */
+#define NVKM_EVENT_ENABLE 0
+
 struct nouveau_eventh {
struct list_head head;
+   unsigned long flags;
void *priv;
int (*func)(struct nouveau_eventh *, int index);
 };
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index b29d04b..ccea2c4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -88,7 +88,6 @@ nouveau_drm_vblank_enable(struct drm_device *dev, int head)

if (WARN_ON_ONCE(head > ARRAY_SIZE(drm->vblank)))
return -EIO;
-   WARN_ON_ONCE(drm->vblank[head].func);
drm->vblank[head].func = nouveau_drm_vblank_handler;
nouveau_event_get(pdisp->vblank, head, >vblank[head]);
return 0;
@@ -99,11 +98,8 @@ nouveau_drm_vblank_disable(struct drm_device *dev, int head)
 {
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_disp *pdisp = nouveau_disp(drm->device);
-   if (drm->vblank[head].func)
-   nouveau_event_put(pdisp->vblank, head, >vblank[head]);
-   else
-   WARN_ON_ONCE(1);
-   drm->vblank[head].func = NULL;
+
+   nouveau_event_put(pdisp->vblank, head, >vblank[head]);
 }

 static u64
-- 
1.8.1.2

[PATCH 3/9] drm/nouveau: Allocate local event handlers

[Peter Hurley]

Prepare for transition to RCU-based event handler list;
since RCU list traversal may have stale pointers, local
storage may go out of scope before handler completes.

Introduce nouveau_event_handler_create/_destroy which provides
suitable semantics for multiple, temporary event handlers.

Signed-off-by: Peter Hurley 
---
 drivers/gpu/drm/nouveau/core/core/event.c | 24 +++
 drivers/gpu/drm/nouveau/core/include/core/event.h |  6 ++
 drivers/gpu/drm/nouveau/nouveau_fence.c   | 15 +++---
 3 files changed, 38 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
index e69c463..1a8d685 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -23,6 +23,30 @@
 #include 
 #include 

+int
+nouveau_event_handler_create(struct nouveau_event *event, int index,
+int (*func)(struct nouveau_eventh*, int),
+void *priv, struct nouveau_eventh **phandler)
+{
+   struct nouveau_eventh *handler;
+
+   handler = *phandler = kzalloc(sizeof(*handler), GFP_KERNEL);
+   if (!handler)
+   return -ENOMEM;
+   handler->func = func;
+   handler->priv = priv;
+   nouveau_event_get(event, index, handler);
+   return 0;
+}
+
+void
+nouveau_event_handler_destroy(struct nouveau_event *event, int index,
+ struct nouveau_eventh *handler)
+{
+   nouveau_event_put(event, index, handler);
+   kfree(handler);
+}
+
 static void
 nouveau_event_put_locked(struct nouveau_event *event, int index,
 struct nouveau_eventh *handler)
diff --git a/drivers/gpu/drm/nouveau/core/include/core/event.h 
b/drivers/gpu/drm/nouveau/core/include/core/event.h
index ad4d8c2..bdf1a0a 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/event.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/event.h
@@ -34,4 +34,10 @@ void nouveau_event_get(struct nouveau_event *, int index,
 void nouveau_event_put(struct nouveau_event *, int index,
   struct nouveau_eventh *);

+int nouveau_event_handler_create(struct nouveau_event *, int index,
+int (*func)(struct nouveau_eventh*, int),
+void *priv, struct nouveau_eventh **);
+void nouveau_event_handler_destroy(struct nouveau_event *, int index,
+  struct nouveau_eventh *);
+
 #endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c 
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index c2e3167..6dde483 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -180,13 +180,14 @@ nouveau_fence_wait_uevent(struct nouveau_fence *fence, 
bool intr)
struct nouveau_channel *chan = fence->channel;
struct nouveau_fifo *pfifo = nouveau_fifo(chan->drm->device);
struct nouveau_fence_priv *priv = chan->drm->fence;
-   struct nouveau_eventh handler = {
-   .func = nouveau_fence_wait_uevent_handler,
-   .priv = priv,
-   };
-   int ret = 0;
+   struct nouveau_eventh *handler;
+   int ret;

-   nouveau_event_get(pfifo->uevent, 0, );
+   ret = nouveau_event_handler_create(pfifo->uevent, 0,
+  nouveau_fence_wait_uevent_handler,
+  priv, );
+   if (ret)
+   return ret;

if (fence->timeout) {
unsigned long timeout = fence->timeout - jiffies;
@@ -218,7 +219,7 @@ nouveau_fence_wait_uevent(struct nouveau_fence *fence, bool 
intr)
}
}

-   nouveau_event_put(pfifo->uevent, 0, );
+   nouveau_event_handler_destroy(pfifo->uevent, 0, handler);
if (unlikely(ret < 0))
return ret;

-- 
1.8.1.2

[PATCH 2/9] drm/nouveau: Move event index check from critical section

[Peter Hurley]

The index_nr field is constant for the lifetime of the event, so
serialized access is unnecessary.

Signed-off-by: Peter Hurley 
---
 drivers/gpu/drm/nouveau/core/core/event.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
index 7eb81c1..e69c463 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -40,9 +40,11 @@ nouveau_event_put(struct nouveau_event *event, int index,
 {
unsigned long flags;

+   if (index >= event->index_nr)
+   return;
+
spin_lock_irqsave(>lock, flags);
-   if (index < event->index_nr)
-   nouveau_event_put_locked(event, index, handler);
+   nouveau_event_put_locked(event, index, handler);
spin_unlock_irqrestore(>lock, flags);
 }

@@ -52,13 +54,14 @@ nouveau_event_get(struct nouveau_event *event, int index,
 {
unsigned long flags;

+   if (index >= event->index_nr)
+   return;
+
spin_lock_irqsave(>lock, flags);
-   if (index < event->index_nr) {
-   list_add(>head, >index[index].list);
-   if (!event->index[index].refs++) {
-   if (event->enable)
-   event->enable(event, index);
-   }
+   list_add(>head, >index[index].list);
+   if (!event->index[index].refs++) {
+   if (event->enable)
+   event->enable(event, index);
}
spin_unlock_irqrestore(>lock, flags);
 }
-- 
1.8.1.2

[PATCH 1/9] drm/nouveau: Add priv field for event handlers

[Peter Hurley]

Provide private field for event handlers exclusive use.
Convert nouveau_fence_wait_uevent() and
nouveau_fence_wait_uevent_handler(); drop struct nouveau_fence_uevent.

Signed-off-by: Peter Hurley 
---
 drivers/gpu/drm/nouveau/core/include/core/event.h |  1 +
 drivers/gpu/drm/nouveau/nouveau_fence.c   | 20 +++-
 2 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/include/core/event.h 
b/drivers/gpu/drm/nouveau/core/include/core/event.h
index 9e09440..ad4d8c2 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/event.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/event.h
@@ -7,6 +7,7 @@

 struct nouveau_eventh {
struct list_head head;
+   void *priv;
int (*func)(struct nouveau_eventh *, int index);
 };

diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c 
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index be31499..c2e3167 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -165,17 +165,11 @@ nouveau_fence_done(struct nouveau_fence *fence)
return !fence->channel;
 }

-struct nouveau_fence_uevent {
-   struct nouveau_eventh handler;
-   struct nouveau_fence_priv *priv;
-};
-
 static int
-nouveau_fence_wait_uevent_handler(struct nouveau_eventh *event, int index)
+nouveau_fence_wait_uevent_handler(struct nouveau_eventh *handler, int index)
 {
-   struct nouveau_fence_uevent *uevent =
-   container_of(event, struct nouveau_fence_uevent, handler);
-   wake_up_all(>priv->waiting);
+   struct nouveau_fence_priv *priv = handler->priv;
+   wake_up_all(>waiting);
return NVKM_EVENT_KEEP;
 }

@@ -186,13 +180,13 @@ nouveau_fence_wait_uevent(struct nouveau_fence *fence, 
bool intr)
struct nouveau_channel *chan = fence->channel;
struct nouveau_fifo *pfifo = nouveau_fifo(chan->drm->device);
struct nouveau_fence_priv *priv = chan->drm->fence;
-   struct nouveau_fence_uevent uevent = {
-   .handler.func = nouveau_fence_wait_uevent_handler,
+   struct nouveau_eventh handler = {
+   .func = nouveau_fence_wait_uevent_handler,
.priv = priv,
};
int ret = 0;

-   nouveau_event_get(pfifo->uevent, 0, );
+   nouveau_event_get(pfifo->uevent, 0, );

if (fence->timeout) {
unsigned long timeout = fence->timeout - jiffies;
@@ -224,7 +218,7 @@ nouveau_fence_wait_uevent(struct nouveau_fence *fence, bool 
intr)
}
}

-   nouveau_event_put(pfifo->uevent, 0, );
+   nouveau_event_put(pfifo->uevent, 0, );
if (unlikely(ret < 0))
return ret;

-- 
1.8.1.2

[PATCH 0/9] drm/nouveau: Cleanup event/handler design

[Peter Hurley]

This series was originally motivated by a deadlock, introduced in
commit 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b
'drm/nouveau/disp: port vblank handling to event interface',
due to inverted lock order between nouveau_drm_vblank_enable()
and nouveau_drm_vblank_handler() (the complete
lockdep report is included in the patch 4/5 changelog).

Because this series fixes the vblank event deadlock, it is
a competing solution to Maarten Lankhorst's 'drm/nouveau:
fix vblank deadlock'.

This series fixes the vblank event deadlock by converting the
event handler list to RCU. This solution allows the event trigger
to be lockless, and thus avoiding the lock inversion.

Typical hurdles to RCU conversion include: 1) ensuring the
object lifetime exceeds the lockless access; 2) preventing
premature object reuse; and 3) verifying that stale object
use not present logical errors.

Because object reuse is not safe in RCU-based operations,
the nouveau_event_get/_put interface is migrated from
add/remove semantics to enable/disable semantics with a separate
install/remove step (which also serves to document the
handler lifetime). This also corrects an unsafe interface design
where handlers can mistakenly be reused while in use.

The nouveau driver currently supports 4 events -- gpio, uevent, cevent,
and vblank. Every event is created by and stored within its
respective subdev/engine object -- gpio in the GPIO subdev, uevent
and cevent in the FIFO engine, and vblank in the DISP engine.
Thus event lifetime extends until the subdev is destructed during
devobj teardown.

Event handler lifetime varies and is detailed in the table below
(apologies for the wide-format):

Event  Handler function   Container Until
-     ---   
--
gpio   nouveau_connector_hotplug  struct nouveau_connector  
nouveau_connector_destroy
uevent nouveau_fence_wait_uevent_handler  local stack object
nouveau_fence_wait_uevent returns
cevent none   n/a   n/a
vblank nouveau_drm_vblank_handler struct nouveau_drm
nouveau_drm_remove
vblank nv50_software_vblsem_release   struct nouveau_software_chan  
_nouveau_engctx_dtor
  (call 
stack originates with
   
nouveau_abi16_chan_free ioctl)
vblank nvc0_software_vblsem_release   struct nouveau_software_chan  same as 
above


RCU lifetime considerations for handlers:

Event  HandlerLifetime
-     -
gpio   nouveau_connector_hotplug  kfree_rcu(nv_connector)
uevent nouveau_fence_wait_uevent_handler  explicit use of 
nouveau_event_hander_create/_destroy
cevent none   n/a
vblank nouveau_drm_vblank_handler synchronize_rcu() in 
nouveau_drm_unload
vblank nv50_software_vblsem_release   synchronize_rcu() in container dtor
vblank nvc0_software_vblsem_release   synchronize_rcu() in container dtor

synchronize_rcu() is used for nouveau_object-based containers for which
kfree_rcu() is not suitable/possible.

Stale event handler execution is not a concern for the existing handlers
because either: 1) the handler is responsible for disabling itself (via
returning NVKM_EVENT_DROP), or 2) the existing handler can already be stale,
as is the case with nouveau_connector_hotplug, which only schedules a work
item, and nouveau_drm_vblank_handler, which the drm core expects may be stale.


Peter Hurley (9):
  drm/nouveau: Add priv field for event handlers
  drm/nouveau: Move event index check from critical section
  drm/nouveau: Allocate local event handlers
  drm/nouveau: Allow asymmetric nouveau_event_get/_put
  drm/nouveau: Add install/remove semantics for event handlers
  drm/nouveau: Convert event handler list to RCU
  drm/nouveau: Fold nouveau_event_put_locked into caller
  drm/nouveau: Simplify event interface
  drm/nouveau: Simplify event handler interface

 drivers/gpu/drm/nouveau/core/core/event.c  | 121 +
 .../gpu/drm/nouveau/core/engine/software/nv50.c|  32 --
 .../gpu/drm/nouveau/core/engine/software/nvc0.c|  32 --
 drivers/gpu/drm/nouveau/core/include/core/event.h  |  27 -
 .../gpu/drm/nouveau/core/include/engine/software.h |   2 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c|  16 ++-
 drivers/gpu/drm/nouveau/nouveau_display.c  |  16 +--
 drivers/gpu/drm/nouveau/nouveau_drm.c  |  35 +++---
 drivers/gpu/drm/nouveau/nouveau_fence.c|  27 ++---
 9 files changed, 220 insertions(+), 88 deletions(-)

-- 
1.8.1.2

[Bug 68468] 9.2.0rc2 Locks Under Various Conditions (UVD, Stress)

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

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

--- Comment #4 from adam777 at gmail.com ---
Well, the digging phase is over, I pretty much hit a wall.

As stated above, the general bisecting idea is clear, but I'm having problem
actually building mesa.
Here what I've done:
I downloaded the PKGBUILD and needed packages (clang-svn, llvm-svn etc.) from
Laurent Carlier's folder (an Arch developer).
I modified the PKGBUILD a bit - comment out unnecessary packages
(intel-dri-git, for example).
In order to build a specific commit, I added the following line to the build()
section:

cd ${srcdir}/mesa
git checkout 5b2855bfe79bfc3995969f2bf775d89b1bc1808a

makepkg -s was invoked later, but failed pretty soon. A bit of googling and the
blame was with bison 3.0.
Since the commit I'm trying to build is from April 11th and the bison 3.0 fix
is from July 31st and since I have no idea how to backport the bison 3.0
patches, I downgraded to bison 2.7.1 from the AUR
(https://bugs.freedesktop.org/show_bug.cgi?id=67354).

makepkg -s then got over the problematic bison part but failed again, this time
with an error related to llvm 3.4
(https://bugs.freedesktop.org/show_bug.cgi?id=64590).
Again, The fix is from May 14th (http://cgit.freedesktop.org/mesa/mesa/c ?
773efbc181), so I reverted to LLVM 3.3 and modified PKGBUILD accordingly (llvm
instead of llvm-svn etc.).

This is, unfortunately, where I got stuck.
Build fails again, with an error that seems to be related to llvm 3.4, though
I'm on 3.3.
Log is here - http://pastebin.com/DwFAVKxC
PKGBUILD is here - http://pastebin.com/PwiZXVGv

-- 
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/20130827/91051e56/attachment.html>

commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support

[Sascha Hauer]

On Tue, Aug 27, 2013 at 01:26:32PM +0200, Daniel Vetter wrote:
> On Tue, Aug 27, 2013 at 1:22 PM, Rob Clark  wrote:
> >> right, but the cores on the SoC, and even any external encoder chips,
> >> are not actually hot-pluggable.  I have a similar scenario w/ msm drm,
> >
> > oh, and come to think of it, same approach it tilcdc.  And I'm sure
> > there are other drivers with the same scenario.
> 
> i915 and nouveau also support encoder slaves, and they also have them
> all built-in. And I think requesting the module at driver init time
> (where I mean any point in time between when the master module loads
> and userspace first starts using it) seems fraught with with deadlock
> issues if we have to wait for it.
> 
> So imo in the current drm state there is no way you can built slave
> drivers as modules. It's simply broken. I agree that it'd be nice to
> have a better solution, but atm I don't even have an idea what it is.
> But applying duct-tape in ->firstopen is certainly not the right way.

The imx-drm does not request modules itself. It also does not do
hotplug. It also does not change the drm device structure while being
opened.
The drm device structure is only ever changed when the device is closed.
Once it's opened it's completely static and will not be changed.
All this 'core' stuff in the drm driver is only done to be able to
separate the different encoders into linux platform_devices, module
support is only a side effect of this.

What the imx-drm driver does is:

- collect subcomponents via imx_drm_add_connector, imx_drm_add_crtc and
  imx_drm_add_encoder
- During drm device open time the try_module_get will make sure the
  modules providing encoders/crtcs do not get unloaded.
  once the device is opened imx_drm_add_* will return -EBUSY.
- When the drm device is closed module_put is called and components are
  allowed to be registered/unregistered again.

Indeed hotplug support for components would be nice, but as said this
is not supported by drm and by the imx-drm driver.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support

[Daniel Vetter]

On Tue, Aug 27, 2013 at 1:22 PM, Rob Clark  wrote:
>> right, but the cores on the SoC, and even any external encoder chips,
>> are not actually hot-pluggable.  I have a similar scenario w/ msm drm,
>
> oh, and come to think of it, same approach it tilcdc.  And I'm sure
> there are other drivers with the same scenario.

i915 and nouveau also support encoder slaves, and they also have them
all built-in. And I think requesting the module at driver init time
(where I mean any point in time between when the master module loads
and userspace first starts using it) seems fraught with with deadlock
issues if we have to wait for it.

So imo in the current drm state there is no way you can built slave
drivers as modules. It's simply broken. I agree that it'd be nice to
have a better solution, but atm I don't even have an idea what it is.
But applying duct-tape in ->firstopen is certainly not the right way.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH] drm/exynos: Add fallback option to get non physically contiguous memory for gem_dumb_create

[Inki Dae]

One more thing, changed the subject to "Consider fallback option to
allocation fail". The subject is too long :)

Thanks,
Inki Dae


> -Original Message-
> From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-soc-
> owner at vger.kernel.org] On Behalf Of Vikas Sajjan
> Sent: Tuesday, August 27, 2013 12:05 PM
> To: Inki Dae
> Cc: DRI mailing list; kgene.kim; Sylwester Nawrocki; Rob Clark; Tomasz
> Figa; Laurent Pinchart; Patch Tracking; linaro-dev at lists.linaro.org; sunil
> joshi; linux-samsung-soc at vger.kernel.org
> Subject: Re: [PATCH] drm/exynos: Add fallback option to get non physically
> contiguous memory for gem_dumb_create
> 
> Thanks.
> 
> On 27 August 2013 08:14, Inki Dae  wrote:
> > Applied.
> >
> > Thanks,
> > Inki Dae
> >
> >> -Original Message-
> >> From: Vikas Sajjan [mailto:vikas.sajjan at linaro.org]
> >> Sent: Friday, August 23, 2013 3:35 PM
> >> To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com
> >> Cc: kgene.kim at samsung.com; s.nawrocki at samsung.com; robdclark at 
> >> gmail.com;
> >> tomasz.figa at gmail.com; laurent.pinchart at ideasonboard.com;
> >> patches at linaro.org; linaro-dev at lists.linaro.org
> >> Subject: [PATCH] drm/exynos: Add fallback option to get non physically
> >> contiguous memory for gem_dumb_create
> >>
> >> To address the case where physically contiguous memory MAY NOT be a
> >> mandatory
> >> requirement for framebuffer for the application calling
> >> exynos_drm_gem_dumb_create,
> >> the patch adds a feature to get non physically contiguous memory for
> >> framebuffer,
> >> if physically contiguous memory allocation fails and if IOMMU is
> > supported.
> >>
> >> Signed-off-by: Vikas Sajjan 
> >> Signed-off-by: Arun Kumar 
> >> ---
> >>  drivers/gpu/drm/exynos/exynos_drm_gem.c |   13 +
> >>  1 file changed, 13 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> >> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> >> index 2eabe1a..66d1b40 100644
> >> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> >> @@ -17,6 +17,7 @@
> >>  #include "exynos_drm_drv.h"
> >>  #include "exynos_drm_gem.h"
> >>  #include "exynos_drm_buf.h"
> >> +#include "exynos_drm_iommu.h"
> >>
> >>  static unsigned int convert_to_vm_err_msg(int msg)
> >>  {
> >> @@ -666,6 +667,18 @@ int exynos_drm_gem_dumb_create(struct drm_file
> >> *file_priv,
> >>
> >>   exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG |
> >>   EXYNOS_BO_WC,
args->size);
> >> + /*
> >> +  * If physically contiguous memory allocation fails and if IOMMU
> is
> >> +  * supported then try to get buffer from non physically
contiguous
> >> +  * memory area.
> >> +  */
> >> + if (IS_ERR(exynos_gem_obj) && is_drm_iommu_supported(dev)) {
> >> + dev_warn(dev->dev, "contiguous FB allocation failed,
falling
> >> back to non-contiguous\n");
> >> + exynos_gem_obj = exynos_drm_gem_create(dev,
> >> + EXYNOS_BO_NONCONTIG |
EXYNOS_BO_WC,
> >> + args->size);
> >> + }
> >> +
> >>   if (IS_ERR(exynos_gem_obj))
> >>   return PTR_ERR(exynos_gem_obj);
> >>
> >> --
> >> 1.7.9.5
> >
> 
> 
> 
> --
> Thanks and Regards
>  Vikas Sajjan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-
> soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] drm/radeon: fix handling of variable sized arrays for router objects

[Alex Deucher]

The table has the following format:

typedef struct _ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT //usSrcDstTableOffset 
pointing to this structure
{
  UCHAR   ucNumberOfSrc;
  USHORT  usSrcObjectID[1];
  UCHAR   ucNumberOfDst;
  USHORT  usDstObjectID[1];
}ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT;

usSrcObjectID[] and usDstObjectID[] are variably sized, so we
can't access them directly.  Use pointers and update the offset
appropriately when accessing the Dst members.

Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/radeon/radeon_atombios.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 112c963..ad91354 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -711,13 +711,16 @@ bool 
radeon_get_atom_connector_info_from_object_table(struct drm_device *dev)

(ATOM_SRC_DST_TABLE_FOR_ONE_OBJECT *)
(ctx->bios + 
data_offset +
 
le16_to_cpu(router_obj->asObjects[k].usSrcDstTableOffset));
+   u8 *num_dst_objs = (u8 
*)
+   ((u8 
*)router_src_dst_table + 1 +
+
(router_src_dst_table->ucNumberOfSrc * 2));
+   u16 *dst_objs = (u16 
*)(num_dst_objs + 1);
int enum_id;

router.router_id = 
router_obj_id;
-   for (enum_id = 0; 
enum_id < router_src_dst_table->ucNumberOfDst;
-enum_id++) {
+   for (enum_id = 0; 
enum_id < (*num_dst_objs); enum_id++) {
if 
(le16_to_cpu(path->usConnObjectId) ==
-   
le16_to_cpu(router_src_dst_table->usDstObjectID[enum_id]))
+   
le16_to_cpu(dst_objs[enum_id]))
break;
}

-- 
1.8.3.1

HDMI 4k support v4

[Thierry Reding]

On Mon, Aug 19, 2013 at 04:58:51PM +0100, Damien Lespiau wrote:
> Follow up on v3:
>   http://lists.freedesktop.org/archives/dri-devel/2013-August/043696.html
> 
> Changes between v3 and v4:
>   - Future proof the sending of 3D_Ext_Data
>   - Renamed struct hdmi_hdmi_infoframe to hdmi_vendor_infoframe (by, in turn,
> renaming the hdmi_vendor_infoframe enum to hdmi_vendor_any_infoframe)
>   - Renamed HDMI_IDENTIFIER to HDMI_IEEE_OUI

The series looks good to me. Thanks for doing this Damien!

Reviewed-by: Thierry Reding 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/2767d9a3/attachment.pgp>

[PATCH 03/14] drm/edid: Parse the HDMI CEA block and look for 4k modes

[Thierry Reding]

On Mon, Aug 19, 2013 at 04:58:54PM +0100, Damien Lespiau wrote:
[...]
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
[...]
> +static int
> +do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len)
> +{
[...]
> + u8 vic;
> +
> + vic = db[9 + offset + i];
> +
> + vic--; /* VICs start at 1 */

This could've all gone on a single line, perhaps with the comment on
top, like so:

/* VICs start at 1 */
u8 vic = db[9 + offset + i] - 1;

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/59a1dfa4/attachment-0001.pgp>

[PATCH 1/6] drm/exynos: Remove non-DT support in exynos_drm_fimd

[Inki Dae]

Hi Sachin,

Could you rebase your patch set to the below patch series?
[PATCH 0/3] drm/exynos: fimd: get signal polarities from device tree

Your patch set is conflicted.

Thanks,
Inki Dae

> -Original Message-
> From: Sachin Kamat [mailto:sachin.kamat at linaro.org]
> Sent: Thursday, August 22, 2013 2:45 PM
> To: dri-devel at lists.freedesktop.org
> Cc: inki.dae at samsung.com; jy0922.shim at samsung.com; sw0312.kim at 
> samsung.com;
> sachin.kamat at linaro.org; patches at linaro.org
> Subject: [PATCH 1/6] drm/exynos: Remove non-DT support in exynos_drm_fimd
> 
> Since commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT
> for EXYNOS SoCs"), Exynos platform is DT only. Hence remove
> all the conditional macros and make the driver DT only.
> 
> Signed-off-by: Sachin Kamat 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |   54
+++---
> 
>  1 file changed, 13 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index f8889d2..90da9ef 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -123,7 +123,6 @@ struct fimd_context {
>   struct fimd_driver_data *driver_data;
>  };
> 
> -#ifdef CONFIG_OF
>  static const struct of_device_id fimd_driver_dt_match[] = {
>   { .compatible = "samsung,s3c6400-fimd",
> .data = _fimd_driver_data },
> @@ -133,21 +132,14 @@ static const struct of_device_id
> fimd_driver_dt_match[] = {
> .data = _fimd_driver_data },
>   {},
>  };
> -#endif
> 
>  static inline struct fimd_driver_data *drm_fimd_get_driver_data(
>   struct platform_device *pdev)
>  {
> -#ifdef CONFIG_OF
>   const struct of_device_id *of_id =
>   of_match_device(fimd_driver_dt_match, >dev);
> 
> - if (of_id)
> - return (struct fimd_driver_data *)of_id->data;
> -#endif
> -
> - return (struct fimd_driver_data *)
> - platform_get_device_id(pdev)->driver_data;
> + return (struct fimd_driver_data *)of_id->data;
>  }
> 
>  static bool fimd_display_is_connected(struct device *dev)
> @@ -891,23 +883,18 @@ static int fimd_probe(struct platform_device *pdev)
>   int win;
>   int ret = -EINVAL;
> 
> - if (dev->of_node) {
> - pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> - if (!pdata)
> - return -ENOMEM;
> + if (!dev->of_node)
> + return -ENODEV;
> 
> - ret = of_get_fb_videomode(dev->of_node,
>panel.timing,
> - OF_USE_NATIVE_MODE);
> - if (ret) {
> - DRM_ERROR("failed: of_get_fb_videomode() : %d\n",
ret);
> - return ret;
> - }
> - } else {
> - pdata = dev->platform_data;
> - if (!pdata) {
> - DRM_ERROR("no platform data specified\n");
> - return -EINVAL;
> - }
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return -ENOMEM;
> +
> + ret = of_get_fb_videomode(dev->of_node, >panel.timing,
> + OF_USE_NATIVE_MODE);
> + if (ret) {
> + DRM_ERROR("failed: of_get_fb_videomode() : %d\n", ret);
> + return ret;
>   }
> 
>   panel = >panel;
> @@ -1069,20 +1056,6 @@ static int fimd_runtime_resume(struct device *dev)
>  }
>  #endif
> 
> -static struct platform_device_id fimd_driver_ids[] = {
> - {
> - .name   = "s3c64xx-fb",
> - .driver_data= (unsigned long)_fimd_driver_data,
> - }, {
> - .name   = "exynos4-fb",
> - .driver_data= (unsigned long)_fimd_driver_data,
> - }, {
> - .name   = "exynos5-fb",
> - .driver_data= (unsigned long)_fimd_driver_data,
> - },
> - {},
> -};
> -
>  static const struct dev_pm_ops fimd_pm_ops = {
>   SET_SYSTEM_SLEEP_PM_OPS(fimd_suspend, fimd_resume)
>   SET_RUNTIME_PM_OPS(fimd_runtime_suspend, fimd_runtime_resume, NULL)
> @@ -1091,11 +1064,10 @@ static const struct dev_pm_ops fimd_pm_ops = {
>  struct platform_driver fimd_driver = {
>   .probe  = fimd_probe,
>   .remove = fimd_remove,
> - .id_table   = fimd_driver_ids,
>   .driver = {
>   .name   = "exynos4-fb",
>   .owner  = THIS_MODULE,
>   .pm = _pm_ops,
> - .of_match_table = of_match_ptr(fimd_driver_dt_match),
> + .of_match_table = fimd_driver_dt_match,
>   },
>  };
> --
> 1.7.9.5

[PATCH 0/3] drm/exynos: fimd: get signal polarities from device tree

[Inki Dae]

> -Original Message-
> From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-soc-
> owner at vger.kernel.org] On Behalf Of Andrzej Hajda
> Sent: Wednesday, August 21, 2013 11:22 PM
> To: open list:DRM DRIVERS FOR E...
> Cc: Andrzej Hajda; Inki Dae; Joonyoung Shim; Seung-Woo Kim; Kyungmin Park;
> David Airlie; moderated list:ARM/S5P EXYNOS AR...; t.figa at samsung.com;
> s.nawrocki at samsung.com
> Subject: [PATCH 0/3] drm/exynos: fimd: get signal polarities from device
> tree
> 
> Hi,
> 
> This patch series adds signal polarities parsing from display-timings
> devicetree node. To do it efficiently struct fb_videomode is replaced
> with struct videomode and some additional code cleaning is performed.
> 

Good patch set. Applied.

Thanks,
Inki Dae


> The patches are for drm-exynos/exynos-drm-next branch.
> 
> Regards
> Andrzej Hajda
> 
> Andrzej Hajda (3):
>   drm/exynos: fimd: replace struct fb_videomode with videomode
>   drm/exynos: fimd: get signal polarities from device tree
>   drm/exynos: fimd: move platform data parsing to separate function
> 
>  drivers/gpu/drm/exynos/exynos_drm_connector.c |  33 +
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 189
+-
> 
>  include/drm/exynos_drm.h  |   3 +-
>  3 files changed, 103 insertions(+), 122 deletions(-)
> 
> --
> 1.8.1.2
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-
> soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] drm/exynos: Add fallback option to get non physically contiguous memory for gem_dumb_create

[Inki Dae]

Applied.

Thanks,
Inki Dae

> -Original Message-
> From: Vikas Sajjan [mailto:vikas.sajjan at linaro.org]
> Sent: Friday, August 23, 2013 3:35 PM
> To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com
> Cc: kgene.kim at samsung.com; s.nawrocki at samsung.com; robdclark at 
> gmail.com;
> tomasz.figa at gmail.com; laurent.pinchart at ideasonboard.com;
> patches at linaro.org; linaro-dev at lists.linaro.org
> Subject: [PATCH] drm/exynos: Add fallback option to get non physically
> contiguous memory for gem_dumb_create
> 
> To address the case where physically contiguous memory MAY NOT be a
> mandatory
> requirement for framebuffer for the application calling
> exynos_drm_gem_dumb_create,
> the patch adds a feature to get non physically contiguous memory for
> framebuffer,
> if physically contiguous memory allocation fails and if IOMMU is
supported.
> 
> Signed-off-by: Vikas Sajjan 
> Signed-off-by: Arun Kumar 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c |   13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 2eabe1a..66d1b40 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -17,6 +17,7 @@
>  #include "exynos_drm_drv.h"
>  #include "exynos_drm_gem.h"
>  #include "exynos_drm_buf.h"
> +#include "exynos_drm_iommu.h"
> 
>  static unsigned int convert_to_vm_err_msg(int msg)
>  {
> @@ -666,6 +667,18 @@ int exynos_drm_gem_dumb_create(struct drm_file
> *file_priv,
> 
>   exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG |
>   EXYNOS_BO_WC, args->size);
> + /*
> +  * If physically contiguous memory allocation fails and if IOMMU is
> +  * supported then try to get buffer from non physically contiguous
> +  * memory area.
> +  */
> + if (IS_ERR(exynos_gem_obj) && is_drm_iommu_supported(dev)) {
> + dev_warn(dev->dev, "contiguous FB allocation failed, falling
> back to non-contiguous\n");
> + exynos_gem_obj = exynos_drm_gem_create(dev,
> + EXYNOS_BO_NONCONTIG | EXYNOS_BO_WC,
> + args->size);
> + }
> +
>   if (IS_ERR(exynos_gem_obj))
>   return PTR_ERR(exynos_gem_obj);
> 
> --
> 1.7.9.5

[PATCH/RFC v3 06/19] video: display: OF support

[Philipp Zabel]

Hi Laurent,

I have another small issue with the graph helpers below:

Am Samstag, den 10.08.2013, 01:03 +0200 schrieb Laurent Pinchart:
[...]
> +/* 
> -
>   * Graph Helpers
>   */
>  
> @@ -420,6 +599,161 @@ int display_entity_link_graph(struct device *dev, 
> struct list_head *entities)
>  }
>  EXPORT_SYMBOL_GPL(display_entity_link_graph);
>  
> +#ifdef CONFIG_OF
> +
> +static int display_of_entity_link_entity(struct device *dev,
> +  struct display_entity *entity,
> +  struct list_head *entities,
> +  struct display_entity *root)
> +{
> + u32 link_flags = MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED;
> + const struct device_node *node = entity->dev->of_node;
> + struct media_entity *local = >entity;
> + struct device_node *ep = NULL;
> + int ret = 0;
> +
> + dev_dbg(dev, "creating links for entity %s\n", local->name);
> +
> + while (1) {
> + struct media_entity *remote = NULL;
> + struct media_pad *remote_pad;
> + struct media_pad *local_pad;
> + struct display_of_link link;
> + struct display_entity *ent;
> + struct device_node *next;
> +
> + /* Get the next endpoint and parse its link. */
> + next = display_of_get_next_endpoint(node, ep);
> + if (next == NULL)
> + break;
> +
> + of_node_put(ep);
> + ep = next;
> +
> + dev_dbg(dev, "processing endpoint %s\n", ep->full_name);
> +
> + ret = display_of_parse_link(ep, );
> + if (ret < 0) {
> + dev_err(dev, "failed to parse link for %s\n",
> + ep->full_name);
> + continue;
> + }
> +
> + /* Skip source pads, they will be processed from the other end 
> of
> +  * the link.
> +  */
> + if (link.local_port >= local->num_pads) {
> + dev_err(dev, "invalid port number %u on %s\n",
> + link.local_port, link.local_node->full_name);
> + display_of_put_link();
> + ret = -EINVAL;
> + break;
> + }
> +
> + local_pad = >pads[link.local_port];
> +
> + if (local_pad->flags & MEDIA_PAD_FL_SOURCE) {
> + dev_dbg(dev, "skipping source port %s:%u\n",
> + link.local_node->full_name, link.local_port);
> + display_of_put_link();
> + continue;
> + }
> +
> + /* Find the remote entity. If not found, just skip the link as
> +  * it goes out of scope of the entities handled by the notifier.
> +  */
> + list_for_each_entry(ent, entities, list) {
> + if (ent->dev->of_node == link.remote_node) {
> + remote = >entity;
> + break;
> + }
> + }
> +
> + if (root->dev->of_node == link.remote_node)
> + remote = >entity;
> +
> + if (remote == NULL) {
> + dev_dbg(dev, "no entity found for %s\n",
> + link.remote_node->full_name);
> + display_of_put_link();
> + continue;
> + }
> +
> + if (link.remote_port >= remote->num_pads) {
> + dev_err(dev, "invalid port number %u on %s\n",
> + link.remote_port, link.remote_node->full_name);
> + display_of_put_link();
> + ret = -EINVAL;
> + break;
> + }
> +
> + remote_pad = >pads[link.remote_port];
> +
> + display_of_put_link();
> +
> + /* Create the media link. */
> + dev_dbg(dev, "creating %s:%u -> %s:%u link\n",
> + remote->name, remote_pad->index,
> + local->name, local_pad->index);
> +
> + ret = media_entity_create_link(remote, remote_pad->index,
> +local, local_pad->index,
> +link_flags);
> + if (ret < 0) {
> + dev_err(dev,
> + "failed to create %s:%u -> %s:%u link\n",
> + remote->name, remote_pad->index,
> + local->name, local_pad->index);
> + break;
> + }
> + }
> +
> + of_node_put(ep);
> + return ret;
> +}
> +
> +/**
> + * display_of_entity_link_graph - Link all entities in a graph
> + * @dev: device used to print debugging and 

[patch 2/2] gpu: host1x: returning success instead of -ENOMEM

[Thierry Reding]

On Fri, Aug 23, 2013 at 01:19:11PM +0300, Dan Carpenter wrote:
> There is a mistake here so it returns PTR_ERR(NULL) which is success
> instead of -ENOMEM.
> 
> Signed-off-by: Dan Carpenter 
> ---
> I can't compile this.

Good catch! Applied, thanks.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/8f7b12f5/attachment.pgp>

commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support

[Lucas Stach]

Am Dienstag, den 27.08.2013, 10:41 +0200 schrieb Daniel Vetter:
> On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach  
> wrote:
> >> If I understand stuff correctly you have a main driver plus a bunch of
> >> encoder/crtc modules and you expect that everything gets loaded and then
> >> only when the kms driver is first opened. The current drm core just
> >> doesn't support hotplugging of encoder/crtc objects after driver init has
> >> completed. If you try to do that it'll go down in flames due to all the
> >> races involved.
> >>
> > You know the logic you broke here was just a moderately sane approach to
> > get around the monolithic DRM driver nonsense, while not having to use
> > real hotplug in DRM.
> >
> > The thing is we don't know if we will ever have all submodules loaded,
> > as this driver is mostly used on embedded devices where people randomly
> > decide to exclude things from their kernel config, because they don't
> > use the feature on their board. The current logic is under the premise
> > that there are no early DRM clients in something like Plymouth, which is
> > a bit flaky, but worked very well for the targeted use-cases.
> 
> Imo the imxdrm->references logic is broken already and simply removing
> those checks would be the right course of action - pretending to have
> fixed races but not actually having fixed much is imo much worse than
> openly admitting that the code is racy and needs work.
> 
I don't see how this is overly racy. We are doing delayed DRM device
setup not delayed HW setup. We simply look around which modules are
there and what DRM we can build up from them.

With some small work we would even be able to make the Plymouth +
modules in initrd case work. The only case that would not really be
solvable without full hotplug is the Plymouth in initrd + modules on the
late rootfs.

> Wrt embedded guys shaving off a few kb by not loading a bunch of
> modules I think you should simply make that compile-time options
> instead of modules. More hassle but at least it should work.
> 
This would be really moving in the wrong direction. We want to get more
modular, not less. We have a lot different on- and off-chip encoders and
other stuff where we want distinct drivers and not some cludged together
thing.

> And if we ever see the need to hotplug crtcs I think the right way is
> to hotplug an entire drm driver. Connector/encoder hotplugging might
> eventually be required for real to support stuff like multi-stream DP,
> but until that happens I really don't see a need for funny games,
> especially on SoC boards where everything is soldered on and can't
> possibly be hotplugged. 

Regards,
Lucas
-- 
Pengutronix e.K.   | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

[Bug 68585] Recent Mesa git make Kwin crash with AMD R300g driver

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

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

--- Comment #5 from Richard Van Den Boom  ---
Created attachment 84696
  --> https://bugs.freedesktop.org/attachment.cgi?id=84696=edit
Git bisect log 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/20130827/d37f5ef2/attachment.html>

[Bug 68585] Recent Mesa git make Kwin crash with AMD R300g driver

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

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

--- Comment #4 from Richard Van Den Boom  ---
According to bisect, the commit that cause the crashes is this one :

git bisect good 98d2498404ba69a3efc1c765b1a1885d151181ed
# first bad commit: [a3ae5dc7dd5c2f8893f86a920247e690e550ebd4] draw: make sure
that the stages setup outputs

I've attached the full git bisect log output.
Whatever Kwin does in the R300 driver, the above commit seems to trigger an
issue.

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

commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support

[Sascha Hauer]

On Tue, Aug 27, 2013 at 10:41:20AM +0200, Daniel Vetter wrote:
> On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach  
> wrote:
> >> If I understand stuff correctly you have a main driver plus a bunch of
> >> encoder/crtc modules and you expect that everything gets loaded and then
> >> only when the kms driver is first opened. The current drm core just
> >> doesn't support hotplugging of encoder/crtc objects after driver init has
> >> completed. If you try to do that it'll go down in flames due to all the
> >> races involved.
> >>
> > You know the logic you broke here was just a moderately sane approach to
> > get around the monolithic DRM driver nonsense, while not having to use
> > real hotplug in DRM.
> >
> > The thing is we don't know if we will ever have all submodules loaded,
> > as this driver is mostly used on embedded devices where people randomly
> > decide to exclude things from their kernel config, because they don't
> > use the feature on their board. The current logic is under the premise
> > that there are no early DRM clients in something like Plymouth, which is
> > a bit flaky, but worked very well for the targeted use-cases.
> 
> Imo the imxdrm->references logic is broken already and simply removing
> those checks would be the right course of action - pretending to have
> fixed races but not actually having fixed much is imo much worse than
> openly admitting that the code is racy and needs work.
> 
> Wrt embedded guys shaving off a few kb by not loading a bunch of
> modules I think you should simply make that compile-time options
> instead of modules. More hassle but at least it should work.

It's not about the few kb. The problem is that our devices are not
monolithic, but instead we have multiple devices in and around the SoC
which form a DRM device.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support

[Daniel Vetter]

On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach  wrote:
>> If I understand stuff correctly you have a main driver plus a bunch of
>> encoder/crtc modules and you expect that everything gets loaded and then
>> only when the kms driver is first opened. The current drm core just
>> doesn't support hotplugging of encoder/crtc objects after driver init has
>> completed. If you try to do that it'll go down in flames due to all the
>> races involved.
>>
> You know the logic you broke here was just a moderately sane approach to
> get around the monolithic DRM driver nonsense, while not having to use
> real hotplug in DRM.
>
> The thing is we don't know if we will ever have all submodules loaded,
> as this driver is mostly used on embedded devices where people randomly
> decide to exclude things from their kernel config, because they don't
> use the feature on their board. The current logic is under the premise
> that there are no early DRM clients in something like Plymouth, which is
> a bit flaky, but worked very well for the targeted use-cases.

Imo the imxdrm->references logic is broken already and simply removing
those checks would be the right course of action - pretending to have
fixed races but not actually having fixed much is imo much worse than
openly admitting that the code is racy and needs work.

Wrt embedded guys shaving off a few kb by not loading a bunch of
modules I think you should simply make that compile-time options
instead of modules. More hassle but at least it should work.

And if we ever see the need to hotplug crtcs I think the right way is
to hotplug an entire drm driver. Connector/encoder hotplugging might
eventually be required for real to support stuff like multi-stream DP,
but until that happens I really don't see a need for funny games,
especially on SoC boards where everything is soldered on and can't
possibly be hotplugged.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[patch 1/2] gpu: host1x: fix an integer overflow check

[Thierry Reding]

On Fri, Aug 23, 2013 at 01:18:25PM +0300, Dan Carpenter wrote:
> Tegra is a 32 bit arch.  On 32 bit systems then size_t is 32 bits so
> "total" will never be higher than UINT_MAX because of integer overflows.
> We need cast to u64 first before doing the math.
> 
> Also the addition earlier:
> 
> unsigned int num_unpins = num_cmdbufs + num_relocs;
> 
> That can overflow as well, but I think it's still safe because we check
> both "num_cmdbufs" and "num_relocs" again in this test.
> 
> Signed-off-by: Dan Carpenter 
> ---
> This is something I spotted in code review.  I can't actually compile
> this code.  I assume this overflow test has security implications.

It did compile and looks good to me, so I've applied it.

Thanks,
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/bf6a6e9c/attachment.pgp>

commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support

[Lucas Stach]

Hi Daniel,

Am Dienstag, den 27.08.2013, 10:08 +0200 schrieb Daniel Vetter:
> On Tue, Aug 27, 2013 at 9:46 AM, Lothar Wa?mann  
> wrote:
> > the function imx_drm_driver_load() must have been called before
> > calling imx_drm_add_crtc(), but the following hunk in the commit:
> > @@ -446,6 +434,9 @@ static int imx_drm_driver_load(struct drm_device *drm, 
> > unsigned long flags)
> >  */
> > imxdrm->drm->vblank_disable_allowed = 1;
> >
> > +   if (!imx_drm_device_get())
> > +   ret = -EINVAL;
> > +
> > ret = 0;
> >
> >  err_init:
> >
> > makes imx_drm_add_crtc() bail out at:
> >
> > if (imxdrm->references) {
> > ret = -EBUSY;
> > goto err_busy;
> > }
> >
> > Thus it is not possible to register any CRTCs.
> 
> Ok I've now read around a bit in the imx core and I think my call to rip
> this out was right ;-)
> 
> If I understand stuff correctly you have a main driver plus a bunch of
> encoder/crtc modules and you expect that everything gets loaded and then
> only when the kms driver is first opened. The current drm core just
> doesn't support hotplugging of encoder/crtc objects after driver init has
> completed. If you try to do that it'll go down in flames due to all the
> races involved.
> 
You know the logic you broke here was just a moderately sane approach to
get around the monolithic DRM driver nonsense, while not having to use
real hotplug in DRM.

The thing is we don't know if we will ever have all submodules loaded,
as this driver is mostly used on embedded devices where people randomly
decide to exclude things from their kernel config, because they don't
use the feature on their board. The current logic is under the premise
that there are no early DRM clients in something like Plymouth, which is
a bit flaky, but worked very well for the targeted use-cases.

Regards,
Lucas

> So as a stopgap measuret I sugges you rip out the imxdrm->references
> trickery since it won't actually protect you from anything truly nasty
> happening. And I wouldn't worry about module unloading and refcounting for
> now since core drm is terminally broken in that area already anyway.
> 
> Then we can move ahead and how to really fix this init ordering. So I
> think we have another TODO here:
> 
> Cheers, Daniel
> 
> ---
> diff --git a/drivers/staging/imx-drm/TODO b/drivers/staging/imx-drm/TODO
> index f806415..f8ef245 100644
> --- a/drivers/staging/imx-drm/TODO
> +++ b/drivers/staging/imx-drm/TODO
> @@ -6,6 +6,11 @@ TODO:
>  - Factor out more code to common helper functions
>  - decide where to put the base driver. It is not specific to a subsystem
>and would be used by DRM/KMS and media/V4L2
> +- Fix up the driver load sequence to make sure all submodules for 
> encoders/crtcs
> +  are fully loaded before the drm driver is registered. Might require a core 
> drm
> +  rework to break away the drm core init sequence from its midlayer drug and
> +  assorted control inversion issues. Or we restructure imx to just built in
> +  everything, dunno. Requested by Daniel Vetter 
>  
>  Missing features (not necessarily for moving out of staging):
>  

-- 
Pengutronix e.K.   | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support

[Daniel Vetter]

On Tue, Aug 27, 2013 at 9:46 AM, Lothar Wa?mann  
wrote:
> the function imx_drm_driver_load() must have been called before
> calling imx_drm_add_crtc(), but the following hunk in the commit:
> @@ -446,6 +434,9 @@ static int imx_drm_driver_load(struct drm_device *drm, 
> unsigned long flags)
>  */
> imxdrm->drm->vblank_disable_allowed = 1;
>
> +   if (!imx_drm_device_get())
> +   ret = -EINVAL;
> +
> ret = 0;
>
>  err_init:
>
> makes imx_drm_add_crtc() bail out at:
>
> if (imxdrm->references) {
> ret = -EBUSY;
> goto err_busy;
> }
>
> Thus it is not possible to register any CRTCs.

Ok I've now read around a bit in the imx core and I think my call to rip
this out was right ;-)

If I understand stuff correctly you have a main driver plus a bunch of
encoder/crtc modules and you expect that everything gets loaded and then
only when the kms driver is first opened. The current drm core just
doesn't support hotplugging of encoder/crtc objects after driver init has
completed. If you try to do that it'll go down in flames due to all the
races involved.

So as a stopgap measuret I sugges you rip out the imxdrm->references
trickery since it won't actually protect you from anything truly nasty
happening. And I wouldn't worry about module unloading and refcounting for
now since core drm is terminally broken in that area already anyway.

Then we can move ahead and how to really fix this init ordering. So I
think we have another TODO here:

Cheers, Daniel

---
diff --git a/drivers/staging/imx-drm/TODO b/drivers/staging/imx-drm/TODO
index f806415..f8ef245 100644
--- a/drivers/staging/imx-drm/TODO
+++ b/drivers/staging/imx-drm/TODO
@@ -6,6 +6,11 @@ TODO:
 - Factor out more code to common helper functions
 - decide where to put the base driver. It is not specific to a subsystem
   and would be used by DRM/KMS and media/V4L2
+- Fix up the driver load sequence to make sure all submodules for 
encoders/crtcs
+  are fully loaded before the drm driver is registered. Might require a core 
drm
+  rework to break away the drm core init sequence from its midlayer drug and
+  assorted control inversion issues. Or we restructure imx to just built in
+  everything, dunno. Requested by Daniel Vetter 

 Missing features (not necessarily for moving out of staging):

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

[PATCH] host1x: hdmi: Make sure clock is enabled before dumping registers

[Thierry Reding]

On Tue, Jul 30, 2013 at 11:35:03AM +0300, Mikko Perttunen wrote:
> The debugfs register dumping function did not enable the HDMI clock.
> This led to a possible system hang when reading the debugfs entry
> while no HDMI cable was connected to the system. This patch makes
> sure that the clock is enabled during the read.
> 
> Signed-off-by: Mikko Perttunen 
> ---
>  drivers/gpu/host1x/drm/hdmi.c | 7 +++
>  1 file changed, 7 insertions(+)

Applied, thanks.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130827/f0e64604/attachment.pgp>

[PATCH] drm/exynos: Add fallback option to get non physically contiguous memory for gem_dumb_create

[Vikas Sajjan]

OK.

On 27 August 2013 09:44, Inki Dae  wrote:
>
> One more thing, changed the subject to "Consider fallback option to
> allocation fail". The subject is too long :)
>
> Thanks,
> Inki Dae
>
>
>> -Original Message-
>> From: linux-samsung-soc-owner at vger.kernel.org [mailto:linux-samsung-soc-
>> owner at vger.kernel.org] On Behalf Of Vikas Sajjan
>> Sent: Tuesday, August 27, 2013 12:05 PM
>> To: Inki Dae
>> Cc: DRI mailing list; kgene.kim; Sylwester Nawrocki; Rob Clark; Tomasz
>> Figa; Laurent Pinchart; Patch Tracking; linaro-dev at lists.linaro.org; sunil
>> joshi; linux-samsung-soc at vger.kernel.org
>> Subject: Re: [PATCH] drm/exynos: Add fallback option to get non physically
>> contiguous memory for gem_dumb_create
>>
>> Thanks.
>>
>> On 27 August 2013 08:14, Inki Dae  wrote:
>> > Applied.
>> >
>> > Thanks,
>> > Inki Dae
>> >
>> >> -Original Message-
>> >> From: Vikas Sajjan [mailto:vikas.sajjan at linaro.org]
>> >> Sent: Friday, August 23, 2013 3:35 PM
>> >> To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com
>> >> Cc: kgene.kim at samsung.com; s.nawrocki at samsung.com; robdclark at 
>> >> gmail.com;
>> >> tomasz.figa at gmail.com; laurent.pinchart at ideasonboard.com;
>> >> patches at linaro.org; linaro-dev at lists.linaro.org
>> >> Subject: [PATCH] drm/exynos: Add fallback option to get non physically
>> >> contiguous memory for gem_dumb_create
>> >>
>> >> To address the case where physically contiguous memory MAY NOT be a
>> >> mandatory
>> >> requirement for framebuffer for the application calling
>> >> exynos_drm_gem_dumb_create,
>> >> the patch adds a feature to get non physically contiguous memory for
>> >> framebuffer,
>> >> if physically contiguous memory allocation fails and if IOMMU is
>> > supported.
>> >>
>> >> Signed-off-by: Vikas Sajjan 
>> >> Signed-off-by: Arun Kumar 
>> >> ---
>> >>  drivers/gpu/drm/exynos/exynos_drm_gem.c |   13 +
>> >>  1 file changed, 13 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> >> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> >> index 2eabe1a..66d1b40 100644
>> >> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> >> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> >> @@ -17,6 +17,7 @@
>> >>  #include "exynos_drm_drv.h"
>> >>  #include "exynos_drm_gem.h"
>> >>  #include "exynos_drm_buf.h"
>> >> +#include "exynos_drm_iommu.h"
>> >>
>> >>  static unsigned int convert_to_vm_err_msg(int msg)
>> >>  {
>> >> @@ -666,6 +667,18 @@ int exynos_drm_gem_dumb_create(struct drm_file
>> >> *file_priv,
>> >>
>> >>   exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG |
>> >>   EXYNOS_BO_WC,
> args->size);
>> >> + /*
>> >> +  * If physically contiguous memory allocation fails and if IOMMU
>> is
>> >> +  * supported then try to get buffer from non physically
> contiguous
>> >> +  * memory area.
>> >> +  */
>> >> + if (IS_ERR(exynos_gem_obj) && is_drm_iommu_supported(dev)) {
>> >> + dev_warn(dev->dev, "contiguous FB allocation failed,
> falling
>> >> back to non-contiguous\n");
>> >> + exynos_gem_obj = exynos_drm_gem_create(dev,
>> >> + EXYNOS_BO_NONCONTIG |
> EXYNOS_BO_WC,
>> >> + args->size);
>> >> + }
>> >> +
>> >>   if (IS_ERR(exynos_gem_obj))
>> >>   return PTR_ERR(exynos_gem_obj);
>> >>
>> >> --
>> >> 1.7.9.5
>> >
>>
>>
>>
>> --
>> Thanks and Regards
>>  Vikas Sajjan
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-
>> soc" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Thanks and Regards
 Vikas Sajjan

[Bug 62976] UEFI + SUMO [6550D] freeze after loading radeon

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

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

David "okias" Heidelberger  changed:

   What|Removed |Added

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

--- Comment #9 from David "okias" Heidelberger  
---
it work well with 3.10, so it's fixed for me. Thank you. Closing bug.

-- 
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/20130827/d6c82343/attachment.html>

[PATCH] drm/exynos: Add fallback option to get non physically contiguous memory for gem_dumb_create

[Vikas Sajjan]

Thanks.

On 27 August 2013 08:14, Inki Dae  wrote:
> Applied.
>
> Thanks,
> Inki Dae
>
>> -Original Message-
>> From: Vikas Sajjan [mailto:vikas.sajjan at linaro.org]
>> Sent: Friday, August 23, 2013 3:35 PM
>> To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com
>> Cc: kgene.kim at samsung.com; s.nawrocki at samsung.com; robdclark at 
>> gmail.com;
>> tomasz.figa at gmail.com; laurent.pinchart at ideasonboard.com;
>> patches at linaro.org; linaro-dev at lists.linaro.org
>> Subject: [PATCH] drm/exynos: Add fallback option to get non physically
>> contiguous memory for gem_dumb_create
>>
>> To address the case where physically contiguous memory MAY NOT be a
>> mandatory
>> requirement for framebuffer for the application calling
>> exynos_drm_gem_dumb_create,
>> the patch adds a feature to get non physically contiguous memory for
>> framebuffer,
>> if physically contiguous memory allocation fails and if IOMMU is
> supported.
>>
>> Signed-off-by: Vikas Sajjan 
>> Signed-off-by: Arun Kumar 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_gem.c |   13 +
>>  1 file changed, 13 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> index 2eabe1a..66d1b40 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> @@ -17,6 +17,7 @@
>>  #include "exynos_drm_drv.h"
>>  #include "exynos_drm_gem.h"
>>  #include "exynos_drm_buf.h"
>> +#include "exynos_drm_iommu.h"
>>
>>  static unsigned int convert_to_vm_err_msg(int msg)
>>  {
>> @@ -666,6 +667,18 @@ int exynos_drm_gem_dumb_create(struct drm_file
>> *file_priv,
>>
>>   exynos_gem_obj = exynos_drm_gem_create(dev, EXYNOS_BO_CONTIG |
>>   EXYNOS_BO_WC, args->size);
>> + /*
>> +  * If physically contiguous memory allocation fails and if IOMMU is
>> +  * supported then try to get buffer from non physically contiguous
>> +  * memory area.
>> +  */
>> + if (IS_ERR(exynos_gem_obj) && is_drm_iommu_supported(dev)) {
>> + dev_warn(dev->dev, "contiguous FB allocation failed, falling
>> back to non-contiguous\n");
>> + exynos_gem_obj = exynos_drm_gem_create(dev,
>> + EXYNOS_BO_NONCONTIG | EXYNOS_BO_WC,
>> + args->size);
>> + }
>> +
>>   if (IS_ERR(exynos_gem_obj))
>>   return PTR_ERR(exynos_gem_obj);
>>
>> --
>> 1.7.9.5
>



-- 
Thanks and Regards
 Vikas Sajjan

[PATCH 1/6] drm/exynos: Remove non-DT support in exynos_drm_fimd

[Sachin Kamat]

Hi Inki,

Sure, I will rebase and send tomorrow.

Thanks

On 27 August 2013 08:18, Inki Dae  wrote:
> Hi Sachin,
>
> Could you rebase your patch set to the below patch series?
> [PATCH 0/3] drm/exynos: fimd: get signal polarities from device tree
>
> Your patch set is conflicted.
>
> Thanks,
> Inki Dae
>
>> -Original Message-
>> From: Sachin Kamat [mailto:sachin.kamat at linaro.org]
>> Sent: Thursday, August 22, 2013 2:45 PM
>> To: dri-devel at lists.freedesktop.org
>> Cc: inki.dae at samsung.com; jy0922.shim at samsung.com; sw0312.kim at 
>> samsung.com;
>> sachin.kamat at linaro.org; patches at linaro.org
>> Subject: [PATCH 1/6] drm/exynos: Remove non-DT support in exynos_drm_fimd
>>
>> Since commit 383ffda2fa ("ARM: EXYNOS: no more support non-DT
>> for EXYNOS SoCs"), Exynos platform is DT only. Hence remove
>> all the conditional macros and make the driver DT only.
>>
>> Signed-off-by: Sachin Kamat 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |   54
> +++---
>> 
>>  1 file changed, 13 insertions(+), 41 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index f8889d2..90da9ef 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -123,7 +123,6 @@ struct fimd_context {
>>   struct fimd_driver_data *driver_data;
>>  };
>>
>> -#ifdef CONFIG_OF
>>  static const struct of_device_id fimd_driver_dt_match[] = {
>>   { .compatible = "samsung,s3c6400-fimd",
>> .data = _fimd_driver_data },
>> @@ -133,21 +132,14 @@ static const struct of_device_id
>> fimd_driver_dt_match[] = {
>> .data = _fimd_driver_data },
>>   {},
>>  };
>> -#endif
>>
>>  static inline struct fimd_driver_data *drm_fimd_get_driver_data(
>>   struct platform_device *pdev)
>>  {
>> -#ifdef CONFIG_OF
>>   const struct of_device_id *of_id =
>>   of_match_device(fimd_driver_dt_match, >dev);
>>
>> - if (of_id)
>> - return (struct fimd_driver_data *)of_id->data;
>> -#endif
>> -
>> - return (struct fimd_driver_data *)
>> - platform_get_device_id(pdev)->driver_data;
>> + return (struct fimd_driver_data *)of_id->data;
>>  }
>>
>>  static bool fimd_display_is_connected(struct device *dev)
>> @@ -891,23 +883,18 @@ static int fimd_probe(struct platform_device *pdev)
>>   int win;
>>   int ret = -EINVAL;
>>
>> - if (dev->of_node) {
>> - pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>> - if (!pdata)
>> - return -ENOMEM;
>> + if (!dev->of_node)
>> + return -ENODEV;
>>
>> - ret = of_get_fb_videomode(dev->of_node,
> >panel.timing,
>> - OF_USE_NATIVE_MODE);
>> - if (ret) {
>> - DRM_ERROR("failed: of_get_fb_videomode() : %d\n",
> ret);
>> - return ret;
>> - }
>> - } else {
>> - pdata = dev->platform_data;
>> - if (!pdata) {
>> - DRM_ERROR("no platform data specified\n");
>> - return -EINVAL;
>> - }
>> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>> + if (!pdata)
>> + return -ENOMEM;
>> +
>> + ret = of_get_fb_videomode(dev->of_node, >panel.timing,
>> + OF_USE_NATIVE_MODE);
>> + if (ret) {
>> + DRM_ERROR("failed: of_get_fb_videomode() : %d\n", ret);
>> + return ret;
>>   }
>>
>>   panel = >panel;
>> @@ -1069,20 +1056,6 @@ static int fimd_runtime_resume(struct device *dev)
>>  }
>>  #endif
>>
>> -static struct platform_device_id fimd_driver_ids[] = {
>> - {
>> - .name   = "s3c64xx-fb",
>> - .driver_data= (unsigned long)_fimd_driver_data,
>> - }, {
>> - .name   = "exynos4-fb",
>> - .driver_data= (unsigned long)_fimd_driver_data,
>> - }, {
>> - .name   = "exynos5-fb",
>> - .driver_data= (unsigned long)_fimd_driver_data,
>> - },
>> - {},
>> -};
>> -
>>  static const struct dev_pm_ops fimd_pm_ops = {
>>   SET_SYSTEM_SLEEP_PM_OPS(fimd_suspend, fimd_resume)
>>   SET_RUNTIME_PM_OPS(fimd_runtime_suspend, fimd_runtime_resume, NULL)
>> @@ -1091,11 +1064,10 @@ static const struct dev_pm_ops fimd_pm_ops = {
>>  struct platform_driver fimd_driver = {
>>   .probe  = fimd_probe,
>>   .remove = fimd_remove,
>> - .id_table   = fimd_driver_ids,
>>   .driver = {
>>   .name   = "exynos4-fb",
>>   .owner  = THIS_MODULE,
>>   .pm = _pm_ops,
>> - .of_match_table = of_match_ptr(fimd_driver_dt_match),
>> + .of_match_table = fimd_driver_dt_match,
>>   },
>>  };
>> --
>> 1.7.9.5
>



-- 
With warm 

commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support

[Rob Clark]

On Tue, Aug 27, 2013 at 7:19 AM, Rob Clark  wrote:
> On Tue, Aug 27, 2013 at 4:56 AM, Sascha Hauer  
> wrote:
>> On Tue, Aug 27, 2013 at 10:41:20AM +0200, Daniel Vetter wrote:
>>> On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach  
>>> wrote:
>>> >> If I understand stuff correctly you have a main driver plus a bunch of
>>> >> encoder/crtc modules and you expect that everything gets loaded and then
>>> >> only when the kms driver is first opened. The current drm core just
>>> >> doesn't support hotplugging of encoder/crtc objects after driver init has
>>> >> completed. If you try to do that it'll go down in flames due to all the
>>> >> races involved.
>>> >>
>>> > You know the logic you broke here was just a moderately sane approach to
>>> > get around the monolithic DRM driver nonsense, while not having to use
>>> > real hotplug in DRM.
>>> >
>>> > The thing is we don't know if we will ever have all submodules loaded,
>>> > as this driver is mostly used on embedded devices where people randomly
>>> > decide to exclude things from their kernel config, because they don't
>>> > use the feature on their board. The current logic is under the premise
>>> > that there are no early DRM clients in something like Plymouth, which is
>>> > a bit flaky, but worked very well for the targeted use-cases.
>>>
>>> Imo the imxdrm->references logic is broken already and simply removing
>>> those checks would be the right course of action - pretending to have
>>> fixed races but not actually having fixed much is imo much worse than
>>> openly admitting that the code is racy and needs work.
>>>
>>> Wrt embedded guys shaving off a few kb by not loading a bunch of
>>> modules I think you should simply make that compile-time options
>>> instead of modules. More hassle but at least it should work.
>>
>> It's not about the few kb. The problem is that our devices are not
>> monolithic, but instead we have multiple devices in and around the SoC
>> which form a DRM device.
>
> right, but the cores on the SoC, and even any external encoder chips,
> are not actually hot-pluggable.  I have a similar scenario w/ msm drm,

oh, and come to think of it, same approach it tilcdc.  And I'm sure
there are other drivers with the same scenario.

BR,
-R

> where there is the core display controller (for ex, 'mdp4'), plus
> hdmi/dsi/etc blocks around that (with their own irq, io/register
> region, etc).  It would be nice if the kernel provided a better
> mechanism for composite drivers, but what I do is just register the
> platform drivers for those other blocks first (in the init code,
> before calling 'platform_driver_register(_platform_driver)'.  This
> way, if the device is actually present, I know before drm dev_load.  I
> do not attempt to build hdmi/dsi/etc as separate modules.  I could if
> I wanted to include/exclude them at compile time, but separate modules
> seems like a bad idea.
>
> BR,
> -R
>
>> Sascha
>>
>> --
>> Pengutronix e.K.   | |
>> Industrial Linux Solutions | http://www.pengutronix.de/  |
>> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
>> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support

[Rob Clark]

On Tue, Aug 27, 2013 at 4:56 AM, Sascha Hauer  wrote:
> On Tue, Aug 27, 2013 at 10:41:20AM +0200, Daniel Vetter wrote:
>> On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach  
>> wrote:
>> >> If I understand stuff correctly you have a main driver plus a bunch of
>> >> encoder/crtc modules and you expect that everything gets loaded and then
>> >> only when the kms driver is first opened. The current drm core just
>> >> doesn't support hotplugging of encoder/crtc objects after driver init has
>> >> completed. If you try to do that it'll go down in flames due to all the
>> >> races involved.
>> >>
>> > You know the logic you broke here was just a moderately sane approach to
>> > get around the monolithic DRM driver nonsense, while not having to use
>> > real hotplug in DRM.
>> >
>> > The thing is we don't know if we will ever have all submodules loaded,
>> > as this driver is mostly used on embedded devices where people randomly
>> > decide to exclude things from their kernel config, because they don't
>> > use the feature on their board. The current logic is under the premise
>> > that there are no early DRM clients in something like Plymouth, which is
>> > a bit flaky, but worked very well for the targeted use-cases.
>>
>> Imo the imxdrm->references logic is broken already and simply removing
>> those checks would be the right course of action - pretending to have
>> fixed races but not actually having fixed much is imo much worse than
>> openly admitting that the code is racy and needs work.
>>
>> Wrt embedded guys shaving off a few kb by not loading a bunch of
>> modules I think you should simply make that compile-time options
>> instead of modules. More hassle but at least it should work.
>
> It's not about the few kb. The problem is that our devices are not
> monolithic, but instead we have multiple devices in and around the SoC
> which form a DRM device.

right, but the cores on the SoC, and even any external encoder chips,
are not actually hot-pluggable.  I have a similar scenario w/ msm drm,
where there is the core display controller (for ex, 'mdp4'), plus
hdmi/dsi/etc blocks around that (with their own irq, io/register
region, etc).  It would be nice if the kernel provided a better
mechanism for composite drivers, but what I do is just register the
platform drivers for those other blocks first (in the init code,
before calling 'platform_driver_register(_platform_driver)'.  This
way, if the device is actually present, I know before drm dev_load.  I
do not attempt to build hdmi/dsi/etc as separate modules.  I could if
I wanted to include/exclude them at compile time, but separate modules
seems like a bad idea.

BR,
-R

> Sascha
>
> --
> Pengutronix e.K.   | |
> Industrial Linux Solutions | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 67800] Computer freezes after idle for several hours (trinity)

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

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

--- Comment #10 from Kertesz Laszlo  ---
It froze after 1 days and 13 hours. Subsequent reboots all ended in freeze in
6-12 hours time.

-- 
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/20130827/03a08587/attachment.html>

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

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

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

--- Comment #8 from Alexandre Demers  ---
Tested with
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.12-wip-gcc-fixes and
it does exactly the same thing: it boots fine, show the login screen. I can
even login in if it doesn't hang right away. Then, it will hang at some point
(either at login screen or after loading the desktop). It displays generally
grey vertical bars.

-- 
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/20130827/1d56bbf1/attachment.html>

[Bug 68585] Recent Mesa git make Kwin crash with AMD R300g driver

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

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

--- Comment #3 from Richard Van Den Boom  ---
I'm no git expert but this seems simple enough.
It may take a bit of time though as this is a slow laptop (8 years old).

-- 
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/20130827/d237d5c4/attachment.html>

[Bug 60929] [r600-llvm] mono games with opengl are blocking on start

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

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

--- Comment #18 from Nicholas Miell  ---
(In reply to comment #17)
> Thanks for tracking this down.  I think we'll need to extend the LLVM C API
> in order to get access to this variable.  However, looking through the LLVM
> code it looks like the PrettyStackTrace handler is registered by a static
> initializer, so I wonder if setting this variable is enough and if we can
> guarantee that r600g will set this variable before the handler is
> initialized.

I don't think this is true -- IIRC, all the stack traces I saw were the result
of one of the runOnFunction methods (either BBPassManager or FPPassManager, I
wasn't paying attention) creating a PassManagerPrettyStackEntry object.

> Also, this seems to me like it is a bug in LLVM.  Is it common practice for
> libraries to override signal handlers of applications?

Common enough that both Mono and LLVM stomp on each other, but its
unambiguously wrong for a shared library to globally modify signal handlers.
(Temporarily setting a new handler on entry to your library and later restoring
the saved handler before returning is fine, but that only works in the
single-threaded case since handlers aren't per-thread. Arguably modern
applications shouldn't use any signals at all.)

Mono (generally) gets away with it because it uses crazy signals that
applications never touch (SIGPWR is only sent to PID 1 by the kernel on power
failure, SIGXCPU is relic of obsolete job billing infrastructure that nobody
uses), but had the bad luck of LLVM deciding to future-proof itself against all
possible fatal signals.

If I were to be prescriptive, llvm::DisablePrettyStackTrace should be true by
default, should only ever be set by clang, and shouldn't be a global variable.

-- 
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/20130827/b765e6a2/attachment-0001.html>

[Bug 68544] cannot build mesa 9.2 without llvm

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

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

Matt Turner  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|dri-devel at lists.freedesktop |mattst88 at gmail.com
   |.org|
 CC||dri-devel at lists.freedesktop
   ||.org

--- Comment #7 from Matt Turner  ---
Committed, thanks! Should get picked to the 9.2 branch before release.

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

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

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

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

--- Comment #7 from Alexandre Demers  ---
Hi Alex. I'm about to test your suggestion. Meanwhile, I identified the
original commit that broke the driver before being fixed by
f90555cbe629e14c6af1dcec1933a3833ecd321f (but ending by the display hanging,
eventhough I can connect through ssh)

So the first bad commit was:
7ad8d0687bb5030c3328bc7229a3183ce179ab25 is the first bad commit
commit 7ad8d0687bb5030c3328bc7229a3183ce179ab25
Author: Alex Deucher 
Date:   Mon Jul 1 16:07:18 2013 -0400

drm/radeon/dpm: re-enable state transitions for Cayman

Was disabled due to stability issues on certain boards
caused by the a bug in the parsing of the atom mc reg tables.
That's fixed now so re-enable.

Signed-off-by: Alex Deucher 

:04 04 de8dfc2a15d5114e81636811d7e3b39c15fc515b
d0e1ee828f10456d39e2ab30cc6598203e50fa6e Mdrivers

Heading for your suggestion right away with
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.12-wip-gcc-fixes.

-- 
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/20130827/3a1803f5/attachment.html>

[Bug 60929] [r600-llvm] mono games with opengl are blocking on start

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

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

--- Comment #17 from Tom Stellard  ---
(In reply to comment #15)
> r600g initializes LLVM without first setting the
> llvm::DisablePrettyStackTrace variable to true. If this variable is false
> (the default), LLVM will register a bunch of signal handlers, including for
> SIGXCPU and SIGPWR, both of which are used by Mono's garbage collector.
> 
> gallivm correctly sets llvm::DisablePrettyStackTrace to true, but it runs
> after r600g has already started calling into LLVM and the signal handlers
> have been registered.
> 
> If you set a breakpoint on r600_create_context, manually set
> llvm::DisablePrettyStackTrace to true and then continue, the application
> will function correctly. I tested this using Fractal (a Unity game which
> deadlocks in sem_wait on startup), Bastion (a MonoGame, also deadlocks in
> sem_wait), and RepetierHost (an OpenTK app which dies in the SIGXCPU handler
> at startup).

Thanks for tracking this down.  I think we'll need to extend the LLVM C API in
order to get access to this variable.  However, looking through the LLVM code
it looks like the PrettyStackTrace handler is registered by a static
initializer, so I wonder if setting this variable is enough and if we can
guarantee that r600g will set this variable before the handler is initialized.

Also, this seems to me like it is a bug in LLVM.  Is it common practice for
libraries to override signal handlers of applications?

-- 
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/20130827/43bbac3a/attachment.html>

[Bug 60639] RV635: Kernel displays black screen when monitor is connect via DisplayPort

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

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

--- Comment #11 from douglas_peale at yahoo.com ---
Created attachment 107330
  --> https://bugzilla.kernel.org/attachment.cgi?id=107330=edit
Requested rom dump

Requested file.

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

[Bug 60791] Display corruption with Radeon driver during boot and on desktop

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

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

--- Comment #11 from Brian Hall  ---
Working the bisection now, may take me a day or two.

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

[PATCH] libdrm: Make some drm headers compatible with gcc -std=c89 -pedantic

[Daniel Kurtz]

The following minor changes were needed to these headers:
 * Convert // comments to /* */
 * No , after final member of enum

With these changes, these header files can be included by a program that
is built with gcc options:
  -std=c89 -Werror -pedantic

Signed-off-by: Daniel Kurtz 
---
 include/drm/drm.h | 4 ++--
 xf86drmMode.h | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/drm/drm.h b/include/drm/drm.h
index 71a2ac1..f400642 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -181,7 +181,7 @@ enum drm_map_type {
_DRM_AGP = 3, /**< AGP/GART */
_DRM_SCATTER_GATHER = 4,  /**< Scatter/gather memory for PCI DMA */
_DRM_CONSISTENT = 5,  /**< Consistent memory for PCI DMA */
-   _DRM_GEM = 6, /**< GEM object */
+   _DRM_GEM = 6  /**< GEM object */
 };

 /**
@@ -435,7 +435,7 @@ struct drm_draw {
  * DRM_IOCTL_UPDATE_DRAW ioctl argument type.
  */
 typedef enum {
-   DRM_DRAWABLE_CLIPRECTS,
+   DRM_DRAWABLE_CLIPRECTS
 } drm_drawable_info_type_t;

 struct drm_update_draw {
diff --git a/xf86drmMode.h b/xf86drmMode.h
index f8a817c..5bc60ee 100644
--- a/xf86drmMode.h
+++ b/xf86drmMode.h
@@ -218,11 +218,11 @@ typedef struct _drmModeProperty {
uint32_t flags;
char name[DRM_PROP_NAME_LEN];
int count_values;
-   uint64_t *values; // store the blob lengths
+   uint64_t *values; /* store the blob lengths */
int count_enums;
struct drm_mode_property_enum *enums;
int count_blobs;
-   uint32_t *blob_ids; // store the blob IDs
+   uint32_t *blob_ids; /* store the blob IDs */
 } drmModePropertyRes, *drmModePropertyPtr;

 typedef struct _drmModeCrtc {
-- 
1.8.3

[Bug 60929] [r600-llvm] mono games with opengl are blocking on start

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

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

--- Comment #16 from Nicholas Miell  ---
Created attachment 84675
  --> https://bugs.freedesktop.org/attachment.cgi?id=84675=edit
temporary workaround patch

Here's a temporary workaround patch. Not for merging, obviously.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 

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

[bugzilla-daemon]

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

--- Comment #8 from Alexandre Demers alexandre.f.dem...@gmail.com ---
Tested with
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.12-wip-gcc-fixes and
it does exactly the same thing: it boots fine, show the login screen. I can
even login in if it doesn't hang right away. Then, it will hang at some point
(either at login screen or after loading the desktop). It displays generally
grey vertical bars.

-- 
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 67800] Computer freezes after idle for several hours (trinity)

[bugzilla-daemon]

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

--- Comment #10 from Kertesz Laszlo laszlo.kert...@gmail.com ---
It froze after 1 days and 13 hours. Subsequent reboots all ended in freeze in
6-12 hours time.

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

Re: [PATCH] host1x: hdmi: Make sure clock is enabled before dumping registers

[Thierry Reding]

On Tue, Jul 30, 2013 at 11:35:03AM +0300, Mikko Perttunen wrote:
 The debugfs register dumping function did not enable the HDMI clock.
 This led to a possible system hang when reading the debugfs entry
 while no HDMI cable was connected to the system. This patch makes
 sure that the clock is enabled during the read.
 
 Signed-off-by: Mikko Perttunen mperttu...@nvidia.com
 ---
  drivers/gpu/host1x/drm/hdmi.c | 7 +++
  1 file changed, 7 insertions(+)

Applied, thanks.

Thierry


pgpegPtC9nR0h.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support

[Daniel Vetter]

On Tue, Aug 27, 2013 at 9:46 AM, Lothar Waßmann l...@karo-electronics.de 
wrote:
 the function imx_drm_driver_load() must have been called before
 calling imx_drm_add_crtc(), but the following hunk in the commit:
 @@ -446,6 +434,9 @@ static int imx_drm_driver_load(struct drm_device *drm, 
 unsigned long flags)
  */
 imxdrm-drm-vblank_disable_allowed = 1;

 +   if (!imx_drm_device_get())
 +   ret = -EINVAL;
 +
 ret = 0;

  err_init:

 makes imx_drm_add_crtc() bail out at:

 if (imxdrm-references) {
 ret = -EBUSY;
 goto err_busy;
 }

 Thus it is not possible to register any CRTCs.

Ok I've now read around a bit in the imx core and I think my call to rip
this out was right ;-)

If I understand stuff correctly you have a main driver plus a bunch of
encoder/crtc modules and you expect that everything gets loaded and then
only when the kms driver is first opened. The current drm core just
doesn't support hotplugging of encoder/crtc objects after driver init has
completed. If you try to do that it'll go down in flames due to all the
races involved.

So as a stopgap measuret I sugges you rip out the imxdrm-references
trickery since it won't actually protect you from anything truly nasty
happening. And I wouldn't worry about module unloading and refcounting for
now since core drm is terminally broken in that area already anyway.

Then we can move ahead and how to really fix this init ordering. So I
think we have another TODO here:

Cheers, Daniel

---
diff --git a/drivers/staging/imx-drm/TODO b/drivers/staging/imx-drm/TODO
index f806415..f8ef245 100644
--- a/drivers/staging/imx-drm/TODO
+++ b/drivers/staging/imx-drm/TODO
@@ -6,6 +6,11 @@ TODO:
 - Factor out more code to common helper functions
 - decide where to put the base driver. It is not specific to a subsystem
   and would be used by DRM/KMS and media/V4L2
+- Fix up the driver load sequence to make sure all submodules for 
encoders/crtcs
+  are fully loaded before the drm driver is registered. Might require a core 
drm
+  rework to break away the drm core init sequence from its midlayer drug and
+  assorted control inversion issues. Or we restructure imx to just built in
+  everything, dunno. Requested by Daniel Vetter daniel.vet...@ffwll.ch
 
 Missing features (not necessarily for moving out of staging):
 
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support

[Lucas Stach]

Hi Daniel,

Am Dienstag, den 27.08.2013, 10:08 +0200 schrieb Daniel Vetter:
 On Tue, Aug 27, 2013 at 9:46 AM, Lothar Waßmann l...@karo-electronics.de 
 wrote:
  the function imx_drm_driver_load() must have been called before
  calling imx_drm_add_crtc(), but the following hunk in the commit:
  @@ -446,6 +434,9 @@ static int imx_drm_driver_load(struct drm_device *drm, 
  unsigned long flags)
   */
  imxdrm-drm-vblank_disable_allowed = 1;
 
  +   if (!imx_drm_device_get())
  +   ret = -EINVAL;
  +
  ret = 0;
 
   err_init:
 
  makes imx_drm_add_crtc() bail out at:
 
  if (imxdrm-references) {
  ret = -EBUSY;
  goto err_busy;
  }
 
  Thus it is not possible to register any CRTCs.
 
 Ok I've now read around a bit in the imx core and I think my call to rip
 this out was right ;-)
 
 If I understand stuff correctly you have a main driver plus a bunch of
 encoder/crtc modules and you expect that everything gets loaded and then
 only when the kms driver is first opened. The current drm core just
 doesn't support hotplugging of encoder/crtc objects after driver init has
 completed. If you try to do that it'll go down in flames due to all the
 races involved.
 
You know the logic you broke here was just a moderately sane approach to
get around the monolithic DRM driver nonsense, while not having to use
real hotplug in DRM.

The thing is we don't know if we will ever have all submodules loaded,
as this driver is mostly used on embedded devices where people randomly
decide to exclude things from their kernel config, because they don't
use the feature on their board. The current logic is under the premise
that there are no early DRM clients in something like Plymouth, which is
a bit flaky, but worked very well for the targeted use-cases.

Regards,
Lucas

 So as a stopgap measuret I sugges you rip out the imxdrm-references
 trickery since it won't actually protect you from anything truly nasty
 happening. And I wouldn't worry about module unloading and refcounting for
 now since core drm is terminally broken in that area already anyway.
 
 Then we can move ahead and how to really fix this init ordering. So I
 think we have another TODO here:
 
 Cheers, Daniel
 
 ---
 diff --git a/drivers/staging/imx-drm/TODO b/drivers/staging/imx-drm/TODO
 index f806415..f8ef245 100644
 --- a/drivers/staging/imx-drm/TODO
 +++ b/drivers/staging/imx-drm/TODO
 @@ -6,6 +6,11 @@ TODO:
  - Factor out more code to common helper functions
  - decide where to put the base driver. It is not specific to a subsystem
and would be used by DRM/KMS and media/V4L2
 +- Fix up the driver load sequence to make sure all submodules for 
 encoders/crtcs
 +  are fully loaded before the drm driver is registered. Might require a core 
 drm
 +  rework to break away the drm core init sequence from its midlayer drug and
 +  assorted control inversion issues. Or we restructure imx to just built in
 +  everything, dunno. Requested by Daniel Vetter daniel.vet...@ffwll.ch
  
  Missing features (not necessarily for moving out of staging):
  

-- 
Pengutronix e.K.   | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

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

Re: [patch 1/2] gpu: host1x: fix an integer overflow check

[Thierry Reding]

On Fri, Aug 23, 2013 at 01:18:25PM +0300, Dan Carpenter wrote:
 Tegra is a 32 bit arch.  On 32 bit systems then size_t is 32 bits so
 total will never be higher than UINT_MAX because of integer overflows.
 We need cast to u64 first before doing the math.
 
 Also the addition earlier:
 
 unsigned int num_unpins = num_cmdbufs + num_relocs;
 
 That can overflow as well, but I think it's still safe because we check
 both num_cmdbufs and num_relocs again in this test.
 
 Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
 ---
 This is something I spotted in code review.  I can't actually compile
 this code.  I assume this overflow test has security implications.

It did compile and looks good to me, so I've applied it.

Thanks,
Thierry


pgp4xwYzLJ19e.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support

[Daniel Vetter]

On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach l.st...@pengutronix.de wrote:
 If I understand stuff correctly you have a main driver plus a bunch of
 encoder/crtc modules and you expect that everything gets loaded and then
 only when the kms driver is first opened. The current drm core just
 doesn't support hotplugging of encoder/crtc objects after driver init has
 completed. If you try to do that it'll go down in flames due to all the
 races involved.

 You know the logic you broke here was just a moderately sane approach to
 get around the monolithic DRM driver nonsense, while not having to use
 real hotplug in DRM.

 The thing is we don't know if we will ever have all submodules loaded,
 as this driver is mostly used on embedded devices where people randomly
 decide to exclude things from their kernel config, because they don't
 use the feature on their board. The current logic is under the premise
 that there are no early DRM clients in something like Plymouth, which is
 a bit flaky, but worked very well for the targeted use-cases.

Imo the imxdrm-references logic is broken already and simply removing
those checks would be the right course of action - pretending to have
fixed races but not actually having fixed much is imo much worse than
openly admitting that the code is racy and needs work.

Wrt embedded guys shaving off a few kb by not loading a bunch of
modules I think you should simply make that compile-time options
instead of modules. More hassle but at least it should work.

And if we ever see the need to hotplug crtcs I think the right way is
to hotplug an entire drm driver. Connector/encoder hotplugging might
eventually be required for real to support stuff like multi-stream DP,
but until that happens I really don't see a need for funny games,
especially on SoC boards where everything is soldered on and can't
possibly be hotplugged.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 62976] UEFI + SUMO [6550D] freeze after loading radeon

[bugzilla-daemon]

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

David okias Heidelberger david.heidelber...@ixit.cz changed:

   What|Removed |Added

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

--- Comment #9 from David okias Heidelberger david.heidelber...@ixit.cz ---
it work well with 3.10, so it's fixed for me. Thank you. Closing bug.

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

Re: commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support

[Sascha Hauer]

On Tue, Aug 27, 2013 at 10:41:20AM +0200, Daniel Vetter wrote:
 On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach l.st...@pengutronix.de wrote:
  If I understand stuff correctly you have a main driver plus a bunch of
  encoder/crtc modules and you expect that everything gets loaded and then
  only when the kms driver is first opened. The current drm core just
  doesn't support hotplugging of encoder/crtc objects after driver init has
  completed. If you try to do that it'll go down in flames due to all the
  races involved.
 
  You know the logic you broke here was just a moderately sane approach to
  get around the monolithic DRM driver nonsense, while not having to use
  real hotplug in DRM.
 
  The thing is we don't know if we will ever have all submodules loaded,
  as this driver is mostly used on embedded devices where people randomly
  decide to exclude things from their kernel config, because they don't
  use the feature on their board. The current logic is under the premise
  that there are no early DRM clients in something like Plymouth, which is
  a bit flaky, but worked very well for the targeted use-cases.
 
 Imo the imxdrm-references logic is broken already and simply removing
 those checks would be the right course of action - pretending to have
 fixed races but not actually having fixed much is imo much worse than
 openly admitting that the code is racy and needs work.
 
 Wrt embedded guys shaving off a few kb by not loading a bunch of
 modules I think you should simply make that compile-time options
 instead of modules. More hassle but at least it should work.

It's not about the few kb. The problem is that our devices are not
monolithic, but instead we have multiple devices in and around the SoC
which form a DRM device.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [patch 2/2] gpu: host1x: returning success instead of -ENOMEM

[Thierry Reding]

On Fri, Aug 23, 2013 at 01:19:11PM +0300, Dan Carpenter wrote:
 There is a mistake here so it returns PTR_ERR(NULL) which is success
 instead of -ENOMEM.
 
 Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
 ---
 I can't compile this.

Good catch! Applied, thanks.

Thierry


pgpe9f5h46uC2.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support

[Lucas Stach]

Am Dienstag, den 27.08.2013, 10:41 +0200 schrieb Daniel Vetter:
 On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach l.st...@pengutronix.de wrote:
  If I understand stuff correctly you have a main driver plus a bunch of
  encoder/crtc modules and you expect that everything gets loaded and then
  only when the kms driver is first opened. The current drm core just
  doesn't support hotplugging of encoder/crtc objects after driver init has
  completed. If you try to do that it'll go down in flames due to all the
  races involved.
 
  You know the logic you broke here was just a moderately sane approach to
  get around the monolithic DRM driver nonsense, while not having to use
  real hotplug in DRM.
 
  The thing is we don't know if we will ever have all submodules loaded,
  as this driver is mostly used on embedded devices where people randomly
  decide to exclude things from their kernel config, because they don't
  use the feature on their board. The current logic is under the premise
  that there are no early DRM clients in something like Plymouth, which is
  a bit flaky, but worked very well for the targeted use-cases.
 
 Imo the imxdrm-references logic is broken already and simply removing
 those checks would be the right course of action - pretending to have
 fixed races but not actually having fixed much is imo much worse than
 openly admitting that the code is racy and needs work.
 
I don't see how this is overly racy. We are doing delayed DRM device
setup not delayed HW setup. We simply look around which modules are
there and what DRM we can build up from them.

With some small work we would even be able to make the Plymouth +
modules in initrd case work. The only case that would not really be
solvable without full hotplug is the Plymouth in initrd + modules on the
late rootfs.

 Wrt embedded guys shaving off a few kb by not loading a bunch of
 modules I think you should simply make that compile-time options
 instead of modules. More hassle but at least it should work.
 
This would be really moving in the wrong direction. We want to get more
modular, not less. We have a lot different on- and off-chip encoders and
other stuff where we want distinct drivers and not some cludged together
thing.

 And if we ever see the need to hotplug crtcs I think the right way is
 to hotplug an entire drm driver. Connector/encoder hotplugging might
 eventually be required for real to support stuff like multi-stream DP,
 but until that happens I really don't see a need for funny games,
 especially on SoC boards where everything is soldered on and can't
 possibly be hotplugged. 

Regards,
Lucas
-- 
Pengutronix e.K.   | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 |
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

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

Re: [PATCH/RFC v3 06/19] video: display: OF support

[Philipp Zabel]

Hi Laurent,

I have another small issue with the graph helpers below:

Am Samstag, den 10.08.2013, 01:03 +0200 schrieb Laurent Pinchart:
[...]
 +/* 
 -
   * Graph Helpers
   */
  
 @@ -420,6 +599,161 @@ int display_entity_link_graph(struct device *dev, 
 struct list_head *entities)
  }
  EXPORT_SYMBOL_GPL(display_entity_link_graph);
  
 +#ifdef CONFIG_OF
 +
 +static int display_of_entity_link_entity(struct device *dev,
 +  struct display_entity *entity,
 +  struct list_head *entities,
 +  struct display_entity *root)
 +{
 + u32 link_flags = MEDIA_LNK_FL_IMMUTABLE | MEDIA_LNK_FL_ENABLED;
 + const struct device_node *node = entity-dev-of_node;
 + struct media_entity *local = entity-entity;
 + struct device_node *ep = NULL;
 + int ret = 0;
 +
 + dev_dbg(dev, creating links for entity %s\n, local-name);
 +
 + while (1) {
 + struct media_entity *remote = NULL;
 + struct media_pad *remote_pad;
 + struct media_pad *local_pad;
 + struct display_of_link link;
 + struct display_entity *ent;
 + struct device_node *next;
 +
 + /* Get the next endpoint and parse its link. */
 + next = display_of_get_next_endpoint(node, ep);
 + if (next == NULL)
 + break;
 +
 + of_node_put(ep);
 + ep = next;
 +
 + dev_dbg(dev, processing endpoint %s\n, ep-full_name);
 +
 + ret = display_of_parse_link(ep, link);
 + if (ret  0) {
 + dev_err(dev, failed to parse link for %s\n,
 + ep-full_name);
 + continue;
 + }
 +
 + /* Skip source pads, they will be processed from the other end 
 of
 +  * the link.
 +  */
 + if (link.local_port = local-num_pads) {
 + dev_err(dev, invalid port number %u on %s\n,
 + link.local_port, link.local_node-full_name);
 + display_of_put_link(link);
 + ret = -EINVAL;
 + break;
 + }
 +
 + local_pad = local-pads[link.local_port];
 +
 + if (local_pad-flags  MEDIA_PAD_FL_SOURCE) {
 + dev_dbg(dev, skipping source port %s:%u\n,
 + link.local_node-full_name, link.local_port);
 + display_of_put_link(link);
 + continue;
 + }
 +
 + /* Find the remote entity. If not found, just skip the link as
 +  * it goes out of scope of the entities handled by the notifier.
 +  */
 + list_for_each_entry(ent, entities, list) {
 + if (ent-dev-of_node == link.remote_node) {
 + remote = ent-entity;
 + break;
 + }
 + }
 +
 + if (root-dev-of_node == link.remote_node)
 + remote = root-entity;
 +
 + if (remote == NULL) {
 + dev_dbg(dev, no entity found for %s\n,
 + link.remote_node-full_name);
 + display_of_put_link(link);
 + continue;
 + }
 +
 + if (link.remote_port = remote-num_pads) {
 + dev_err(dev, invalid port number %u on %s\n,
 + link.remote_port, link.remote_node-full_name);
 + display_of_put_link(link);
 + ret = -EINVAL;
 + break;
 + }
 +
 + remote_pad = remote-pads[link.remote_port];
 +
 + display_of_put_link(link);
 +
 + /* Create the media link. */
 + dev_dbg(dev, creating %s:%u - %s:%u link\n,
 + remote-name, remote_pad-index,
 + local-name, local_pad-index);
 +
 + ret = media_entity_create_link(remote, remote_pad-index,
 +local, local_pad-index,
 +link_flags);
 + if (ret  0) {
 + dev_err(dev,
 + failed to create %s:%u - %s:%u link\n,
 + remote-name, remote_pad-index,
 + local-name, local_pad-index);
 + break;
 + }
 + }
 +
 + of_node_put(ep);
 + return ret;
 +}
 +
 +/**
 + * display_of_entity_link_graph - Link all entities in a graph
 + * @dev: device used to print debugging and error messages
 + * @root: optional root display entity
 + * @entities: list of display entities in the graph
 + *
 + * This function 

Re: [PATCH 03/14] drm/edid: Parse the HDMI CEA block and look for 4k modes

[Thierry Reding]

On Mon, Aug 19, 2013 at 04:58:54PM +0100, Damien Lespiau wrote:
[...]
 diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
[...]
 +static int
 +do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len)
 +{
[...]
 + u8 vic;
 +
 + vic = db[9 + offset + i];
 +
 + vic--; /* VICs start at 1 */

This could've all gone on a single line, perhaps with the comment on
top, like so:

/* VICs start at 1 */
u8 vic = db[9 + offset + i] - 1;

Thierry


pgpmIIFWKzAof.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: HDMI 4k support v4

[Thierry Reding]

On Mon, Aug 19, 2013 at 04:58:51PM +0100, Damien Lespiau wrote:
 Follow up on v3:
   http://lists.freedesktop.org/archives/dri-devel/2013-August/043696.html
 
 Changes between v3 and v4:
   - Future proof the sending of 3D_Ext_Data
   - Renamed struct hdmi_hdmi_infoframe to hdmi_vendor_infoframe (by, in turn,
 renaming the hdmi_vendor_infoframe enum to hdmi_vendor_any_infoframe)
   - Renamed HDMI_IDENTIFIER to HDMI_IEEE_OUI

The series looks good to me. Thanks for doing this Damien!

Reviewed-by: Thierry Reding tred...@nvidia.com


pgpHKWtPnCMHm.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 68585] Recent Mesa git make Kwin crash with AMD R300g driver

[bugzilla-daemon]

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

--- Comment #4 from Richard Van Den Boom r...@cryptolab.net ---
According to bisect, the commit that cause the crashes is this one :

git bisect good 98d2498404ba69a3efc1c765b1a1885d151181ed
# first bad commit: [a3ae5dc7dd5c2f8893f86a920247e690e550ebd4] draw: make sure
that the stages setup outputs

I've attached the full git bisect log output.
Whatever Kwin does in the R300 driver, the above commit seems to trigger an
issue.

-- 
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 68585] Recent Mesa git make Kwin crash with AMD R300g driver

[bugzilla-daemon]

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

--- Comment #5 from Richard Van Den Boom r...@cryptolab.net ---
Created attachment 84696
  -- https://bugs.freedesktop.org/attachment.cgi?id=84696action=edit
Git bisect log output

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

Re: commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support

[Rob Clark]

On Tue, Aug 27, 2013 at 4:56 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
 On Tue, Aug 27, 2013 at 10:41:20AM +0200, Daniel Vetter wrote:
 On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach l.st...@pengutronix.de wrote:
  If I understand stuff correctly you have a main driver plus a bunch of
  encoder/crtc modules and you expect that everything gets loaded and then
  only when the kms driver is first opened. The current drm core just
  doesn't support hotplugging of encoder/crtc objects after driver init has
  completed. If you try to do that it'll go down in flames due to all the
  races involved.
 
  You know the logic you broke here was just a moderately sane approach to
  get around the monolithic DRM driver nonsense, while not having to use
  real hotplug in DRM.
 
  The thing is we don't know if we will ever have all submodules loaded,
  as this driver is mostly used on embedded devices where people randomly
  decide to exclude things from their kernel config, because they don't
  use the feature on their board. The current logic is under the premise
  that there are no early DRM clients in something like Plymouth, which is
  a bit flaky, but worked very well for the targeted use-cases.

 Imo the imxdrm-references logic is broken already and simply removing
 those checks would be the right course of action - pretending to have
 fixed races but not actually having fixed much is imo much worse than
 openly admitting that the code is racy and needs work.

 Wrt embedded guys shaving off a few kb by not loading a bunch of
 modules I think you should simply make that compile-time options
 instead of modules. More hassle but at least it should work.

 It's not about the few kb. The problem is that our devices are not
 monolithic, but instead we have multiple devices in and around the SoC
 which form a DRM device.

right, but the cores on the SoC, and even any external encoder chips,
are not actually hot-pluggable.  I have a similar scenario w/ msm drm,
where there is the core display controller (for ex, 'mdp4'), plus
hdmi/dsi/etc blocks around that (with their own irq, io/register
region, etc).  It would be nice if the kernel provided a better
mechanism for composite drivers, but what I do is just register the
platform drivers for those other blocks first (in the init code,
before calling 'platform_driver_register(msm_platform_driver)'.  This
way, if the device is actually present, I know before drm dev_load.  I
do not attempt to build hdmi/dsi/etc as separate modules.  I could if
I wanted to include/exclude them at compile time, but separate modules
seems like a bad idea.

BR,
-R

 Sascha

 --
 Pengutronix e.K.   | |
 Industrial Linux Solutions | http://www.pengutronix.de/  |
 Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
 Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support

[Rob Clark]

On Tue, Aug 27, 2013 at 7:19 AM, Rob Clark robdcl...@gmail.com wrote:
 On Tue, Aug 27, 2013 at 4:56 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
 On Tue, Aug 27, 2013 at 10:41:20AM +0200, Daniel Vetter wrote:
 On Tue, Aug 27, 2013 at 10:26 AM, Lucas Stach l.st...@pengutronix.de 
 wrote:
  If I understand stuff correctly you have a main driver plus a bunch of
  encoder/crtc modules and you expect that everything gets loaded and then
  only when the kms driver is first opened. The current drm core just
  doesn't support hotplugging of encoder/crtc objects after driver init has
  completed. If you try to do that it'll go down in flames due to all the
  races involved.
 
  You know the logic you broke here was just a moderately sane approach to
  get around the monolithic DRM driver nonsense, while not having to use
  real hotplug in DRM.
 
  The thing is we don't know if we will ever have all submodules loaded,
  as this driver is mostly used on embedded devices where people randomly
  decide to exclude things from their kernel config, because they don't
  use the feature on their board. The current logic is under the premise
  that there are no early DRM clients in something like Plymouth, which is
  a bit flaky, but worked very well for the targeted use-cases.

 Imo the imxdrm-references logic is broken already and simply removing
 those checks would be the right course of action - pretending to have
 fixed races but not actually having fixed much is imo much worse than
 openly admitting that the code is racy and needs work.

 Wrt embedded guys shaving off a few kb by not loading a bunch of
 modules I think you should simply make that compile-time options
 instead of modules. More hassle but at least it should work.

 It's not about the few kb. The problem is that our devices are not
 monolithic, but instead we have multiple devices in and around the SoC
 which form a DRM device.

 right, but the cores on the SoC, and even any external encoder chips,
 are not actually hot-pluggable.  I have a similar scenario w/ msm drm,

oh, and come to think of it, same approach it tilcdc.  And I'm sure
there are other drivers with the same scenario.

BR,
-R

 where there is the core display controller (for ex, 'mdp4'), plus
 hdmi/dsi/etc blocks around that (with their own irq, io/register
 region, etc).  It would be nice if the kernel provided a better
 mechanism for composite drivers, but what I do is just register the
 platform drivers for those other blocks first (in the init code,
 before calling 'platform_driver_register(msm_platform_driver)'.  This
 way, if the device is actually present, I know before drm dev_load.  I
 do not attempt to build hdmi/dsi/etc as separate modules.  I could if
 I wanted to include/exclude them at compile time, but separate modules
 seems like a bad idea.

 BR,
 -R

 Sascha

 --
 Pengutronix e.K.   | |
 Industrial Linux Solutions | http://www.pengutronix.de/  |
 Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
 Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
 ___
 dri-devel mailing list
 dri-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support

[Daniel Vetter]

On Tue, Aug 27, 2013 at 1:22 PM, Rob Clark robdcl...@gmail.com wrote:
 right, but the cores on the SoC, and even any external encoder chips,
 are not actually hot-pluggable.  I have a similar scenario w/ msm drm,

 oh, and come to think of it, same approach it tilcdc.  And I'm sure
 there are other drivers with the same scenario.

i915 and nouveau also support encoder slaves, and they also have them
all built-in. And I think requesting the module at driver init time
(where I mean any point in time between when the master module loads
and userspace first starts using it) seems fraught with with deadlock
issues if we have to wait for it.

So imo in the current drm state there is no way you can built slave
drivers as modules. It's simply broken. I agree that it'd be nice to
have a better solution, but atm I don't even have an idea what it is.
But applying duct-tape in -firstopen is certainly not the right way.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: commit b5dc0d108cd3c0b50ddcb6f6c54be1bea4c39e01 breaks imx-drm support

[Sascha Hauer]

On Tue, Aug 27, 2013 at 01:26:32PM +0200, Daniel Vetter wrote:
 On Tue, Aug 27, 2013 at 1:22 PM, Rob Clark robdcl...@gmail.com wrote:
  right, but the cores on the SoC, and even any external encoder chips,
  are not actually hot-pluggable.  I have a similar scenario w/ msm drm,
 
  oh, and come to think of it, same approach it tilcdc.  And I'm sure
  there are other drivers with the same scenario.
 
 i915 and nouveau also support encoder slaves, and they also have them
 all built-in. And I think requesting the module at driver init time
 (where I mean any point in time between when the master module loads
 and userspace first starts using it) seems fraught with with deadlock
 issues if we have to wait for it.
 
 So imo in the current drm state there is no way you can built slave
 drivers as modules. It's simply broken. I agree that it'd be nice to
 have a better solution, but atm I don't even have an idea what it is.
 But applying duct-tape in -firstopen is certainly not the right way.

The imx-drm does not request modules itself. It also does not do
hotplug. It also does not change the drm device structure while being
opened.
The drm device structure is only ever changed when the device is closed.
Once it's opened it's completely static and will not be changed.
All this 'core' stuff in the drm driver is only done to be able to
separate the different encoders into linux platform_devices, module
support is only a side effect of this.

What the imx-drm driver does is:

- collect subcomponents via imx_drm_add_connector, imx_drm_add_crtc and
  imx_drm_add_encoder
- During drm device open time the try_module_get will make sure the
  modules providing encoders/crtcs do not get unloaded.
  once the device is opened imx_drm_add_* will return -EBUSY.
- When the drm device is closed module_put is called and components are
  allowed to be registered/unregistered again.

Indeed hotplug support for components would be nice, but as said this
is not supported by drm and by the imx-drm driver.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 68468] 9.2.0rc2 Locks Under Various Conditions (UVD, Stress)

[bugzilla-daemon]

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

--- Comment #4 from adam...@gmail.com ---
Well, the digging phase is over, I pretty much hit a wall.

As stated above, the general bisecting idea is clear, but I'm having problem
actually building mesa.
Here what I've done:
I downloaded the PKGBUILD and needed packages (clang-svn, llvm-svn etc.) from
Laurent Carlier's folder (an Arch developer).
I modified the PKGBUILD a bit - comment out unnecessary packages
(intel-dri-git, for example).
In order to build a specific commit, I added the following line to the build()
section:

cd ${srcdir}/mesa
git checkout 5b2855bfe79bfc3995969f2bf775d89b1bc1808a

makepkg -s was invoked later, but failed pretty soon. A bit of googling and the
blame was with bison 3.0.
Since the commit I'm trying to build is from April 11th and the bison 3.0 fix
is from July 31st and since I have no idea how to backport the bison 3.0
patches, I downgraded to bison 2.7.1 from the AUR
(https://bugs.freedesktop.org/show_bug.cgi?id=67354).

makepkg -s then got over the problematic bison part but failed again, this time
with an error related to llvm 3.4
(https://bugs.freedesktop.org/show_bug.cgi?id=64590).
Again, The fix is from May 14th (http://cgit.freedesktop.org/mesa/mesa/c …
773efbc181), so I reverted to LLVM 3.3 and modified PKGBUILD accordingly (llvm
instead of llvm-svn etc.).

This is, unfortunately, where I got stuck.
Build fails again, with an error that seems to be related to llvm 3.4, though
I'm on 3.3.
Log is here - http://pastebin.com/DwFAVKxC
PKGBUILD is here - http://pastebin.com/PwiZXVGv

-- 
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 52952] Ubuntu 10.04.4 LTS 32-bit and ATI Technologies Radeon Xpress 200 for Intel (RC410) ACPI S3 State Resume Failure

[bugzilla-daemon]

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

--- Comment #19 from Alex Deucher ag...@yahoo.com ---
Created attachment 84747
  -- https://bugs.freedesktop.org/attachment.cgi?id=84747action=edit
possible fix

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

[PATCH 1/9] drm/nouveau: Add priv field for event handlers

[Peter Hurley]

Provide private field for event handlers exclusive use.
Convert nouveau_fence_wait_uevent() and
nouveau_fence_wait_uevent_handler(); drop struct nouveau_fence_uevent.

Signed-off-by: Peter Hurley pe...@hurleysoftware.com
---
 drivers/gpu/drm/nouveau/core/include/core/event.h |  1 +
 drivers/gpu/drm/nouveau/nouveau_fence.c   | 20 +++-
 2 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/include/core/event.h 
b/drivers/gpu/drm/nouveau/core/include/core/event.h
index 9e09440..ad4d8c2 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/event.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/event.h
@@ -7,6 +7,7 @@
 
 struct nouveau_eventh {
struct list_head head;
+   void *priv;
int (*func)(struct nouveau_eventh *, int index);
 };
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c 
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index be31499..c2e3167 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -165,17 +165,11 @@ nouveau_fence_done(struct nouveau_fence *fence)
return !fence-channel;
 }
 
-struct nouveau_fence_uevent {
-   struct nouveau_eventh handler;
-   struct nouveau_fence_priv *priv;
-};
-
 static int
-nouveau_fence_wait_uevent_handler(struct nouveau_eventh *event, int index)
+nouveau_fence_wait_uevent_handler(struct nouveau_eventh *handler, int index)
 {
-   struct nouveau_fence_uevent *uevent =
-   container_of(event, struct nouveau_fence_uevent, handler);
-   wake_up_all(uevent-priv-waiting);
+   struct nouveau_fence_priv *priv = handler-priv;
+   wake_up_all(priv-waiting);
return NVKM_EVENT_KEEP;
 }
 
@@ -186,13 +180,13 @@ nouveau_fence_wait_uevent(struct nouveau_fence *fence, 
bool intr)
struct nouveau_channel *chan = fence-channel;
struct nouveau_fifo *pfifo = nouveau_fifo(chan-drm-device);
struct nouveau_fence_priv *priv = chan-drm-fence;
-   struct nouveau_fence_uevent uevent = {
-   .handler.func = nouveau_fence_wait_uevent_handler,
+   struct nouveau_eventh handler = {
+   .func = nouveau_fence_wait_uevent_handler,
.priv = priv,
};
int ret = 0;
 
-   nouveau_event_get(pfifo-uevent, 0, uevent.handler);
+   nouveau_event_get(pfifo-uevent, 0, handler);
 
if (fence-timeout) {
unsigned long timeout = fence-timeout - jiffies;
@@ -224,7 +218,7 @@ nouveau_fence_wait_uevent(struct nouveau_fence *fence, bool 
intr)
}
}
 
-   nouveau_event_put(pfifo-uevent, 0, uevent.handler);
+   nouveau_event_put(pfifo-uevent, 0, handler);
if (unlikely(ret  0))
return ret;
 
-- 
1.8.1.2

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

[PATCH 2/9] drm/nouveau: Move event index check from critical section

[Peter Hurley]

The index_nr field is constant for the lifetime of the event, so
serialized access is unnecessary.

Signed-off-by: Peter Hurley pe...@hurleysoftware.com
---
 drivers/gpu/drm/nouveau/core/core/event.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
index 7eb81c1..e69c463 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -40,9 +40,11 @@ nouveau_event_put(struct nouveau_event *event, int index,
 {
unsigned long flags;
 
+   if (index = event-index_nr)
+   return;
+
spin_lock_irqsave(event-lock, flags);
-   if (index  event-index_nr)
-   nouveau_event_put_locked(event, index, handler);
+   nouveau_event_put_locked(event, index, handler);
spin_unlock_irqrestore(event-lock, flags);
 }
 
@@ -52,13 +54,14 @@ nouveau_event_get(struct nouveau_event *event, int index,
 {
unsigned long flags;
 
+   if (index = event-index_nr)
+   return;
+
spin_lock_irqsave(event-lock, flags);
-   if (index  event-index_nr) {
-   list_add(handler-head, event-index[index].list);
-   if (!event-index[index].refs++) {
-   if (event-enable)
-   event-enable(event, index);
-   }
+   list_add(handler-head, event-index[index].list);
+   if (!event-index[index].refs++) {
+   if (event-enable)
+   event-enable(event, index);
}
spin_unlock_irqrestore(event-lock, flags);
 }
-- 
1.8.1.2

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

[PATCH 0/9] drm/nouveau: Cleanup event/handler design

[Peter Hurley]

This series was originally motivated by a deadlock, introduced in
commit 1d7c71a3e2f77336df536855b0efd2dc5bdeb41b
'drm/nouveau/disp: port vblank handling to event interface',
due to inverted lock order between nouveau_drm_vblank_enable()
and nouveau_drm_vblank_handler() (the complete
lockdep report is included in the patch 4/5 changelog).

Because this series fixes the vblank event deadlock, it is
a competing solution to Maarten Lankhorst's 'drm/nouveau:
fix vblank deadlock'.

This series fixes the vblank event deadlock by converting the
event handler list to RCU. This solution allows the event trigger
to be lockless, and thus avoiding the lock inversion.

Typical hurdles to RCU conversion include: 1) ensuring the
object lifetime exceeds the lockless access; 2) preventing
premature object reuse; and 3) verifying that stale object
use not present logical errors.

Because object reuse is not safe in RCU-based operations,
the nouveau_event_get/_put interface is migrated from
add/remove semantics to enable/disable semantics with a separate
install/remove step (which also serves to document the
handler lifetime). This also corrects an unsafe interface design
where handlers can mistakenly be reused while in use.

The nouveau driver currently supports 4 events -- gpio, uevent, cevent,
and vblank. Every event is created by and stored within its
respective subdev/engine object -- gpio in the GPIO subdev, uevent
and cevent in the FIFO engine, and vblank in the DISP engine.
Thus event lifetime extends until the subdev is destructed during
devobj teardown.

Event handler lifetime varies and is detailed in the table below
(apologies for the wide-format):

Event  Handler function   Container Until
-     ---   
--
gpio   nouveau_connector_hotplug  struct nouveau_connector  
nouveau_connector_destroy
uevent nouveau_fence_wait_uevent_handler  local stack object
nouveau_fence_wait_uevent returns
cevent none   n/a   n/a
vblank nouveau_drm_vblank_handler struct nouveau_drm
nouveau_drm_remove
vblank nv50_software_vblsem_release   struct nouveau_software_chan  
_nouveau_engctx_dtor
  (call 
stack originates with
   
nouveau_abi16_chan_free ioctl)
vblank nvc0_software_vblsem_release   struct nouveau_software_chan  same as 
above


RCU lifetime considerations for handlers:

Event  HandlerLifetime
-     -
gpio   nouveau_connector_hotplug  kfree_rcu(nv_connector)
uevent nouveau_fence_wait_uevent_handler  explicit use of 
nouveau_event_hander_create/_destroy
cevent none   n/a
vblank nouveau_drm_vblank_handler synchronize_rcu() in 
nouveau_drm_unload
vblank nv50_software_vblsem_release   synchronize_rcu() in container dtor
vblank nvc0_software_vblsem_release   synchronize_rcu() in container dtor

synchronize_rcu() is used for nouveau_object-based containers for which
kfree_rcu() is not suitable/possible.

Stale event handler execution is not a concern for the existing handlers
because either: 1) the handler is responsible for disabling itself (via
returning NVKM_EVENT_DROP), or 2) the existing handler can already be stale,
as is the case with nouveau_connector_hotplug, which only schedules a work
item, and nouveau_drm_vblank_handler, which the drm core expects may be stale.


Peter Hurley (9):
  drm/nouveau: Add priv field for event handlers
  drm/nouveau: Move event index check from critical section
  drm/nouveau: Allocate local event handlers
  drm/nouveau: Allow asymmetric nouveau_event_get/_put
  drm/nouveau: Add install/remove semantics for event handlers
  drm/nouveau: Convert event handler list to RCU
  drm/nouveau: Fold nouveau_event_put_locked into caller
  drm/nouveau: Simplify event interface
  drm/nouveau: Simplify event handler interface

 drivers/gpu/drm/nouveau/core/core/event.c  | 121 +
 .../gpu/drm/nouveau/core/engine/software/nv50.c|  32 --
 .../gpu/drm/nouveau/core/engine/software/nvc0.c|  32 --
 drivers/gpu/drm/nouveau/core/include/core/event.h  |  27 -
 .../gpu/drm/nouveau/core/include/engine/software.h |   2 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c|  16 ++-
 drivers/gpu/drm/nouveau/nouveau_display.c  |  16 +--
 drivers/gpu/drm/nouveau/nouveau_drm.c  |  35 +++---
 drivers/gpu/drm/nouveau/nouveau_fence.c|  27 ++---
 9 files changed, 220 insertions(+), 88 deletions(-)

-- 
1.8.1.2

___
dri-devel mailing list
dri-devel@lists.freedesktop.org

[PATCH 3/9] drm/nouveau: Allocate local event handlers

[Peter Hurley]

Prepare for transition to RCU-based event handler list;
since RCU list traversal may have stale pointers, local
storage may go out of scope before handler completes.

Introduce nouveau_event_handler_create/_destroy which provides
suitable semantics for multiple, temporary event handlers.

Signed-off-by: Peter Hurley pe...@hurleysoftware.com
---
 drivers/gpu/drm/nouveau/core/core/event.c | 24 +++
 drivers/gpu/drm/nouveau/core/include/core/event.h |  6 ++
 drivers/gpu/drm/nouveau/nouveau_fence.c   | 15 +++---
 3 files changed, 38 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
index e69c463..1a8d685 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -23,6 +23,30 @@
 #include core/os.h
 #include core/event.h
 
+int
+nouveau_event_handler_create(struct nouveau_event *event, int index,
+int (*func)(struct nouveau_eventh*, int),
+void *priv, struct nouveau_eventh **phandler)
+{
+   struct nouveau_eventh *handler;
+
+   handler = *phandler = kzalloc(sizeof(*handler), GFP_KERNEL);
+   if (!handler)
+   return -ENOMEM;
+   handler-func = func;
+   handler-priv = priv;
+   nouveau_event_get(event, index, handler);
+   return 0;
+}
+
+void
+nouveau_event_handler_destroy(struct nouveau_event *event, int index,
+ struct nouveau_eventh *handler)
+{
+   nouveau_event_put(event, index, handler);
+   kfree(handler);
+}
+
 static void
 nouveau_event_put_locked(struct nouveau_event *event, int index,
 struct nouveau_eventh *handler)
diff --git a/drivers/gpu/drm/nouveau/core/include/core/event.h 
b/drivers/gpu/drm/nouveau/core/include/core/event.h
index ad4d8c2..bdf1a0a 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/event.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/event.h
@@ -34,4 +34,10 @@ void nouveau_event_get(struct nouveau_event *, int index,
 void nouveau_event_put(struct nouveau_event *, int index,
   struct nouveau_eventh *);
 
+int nouveau_event_handler_create(struct nouveau_event *, int index,
+int (*func)(struct nouveau_eventh*, int),
+void *priv, struct nouveau_eventh **);
+void nouveau_event_handler_destroy(struct nouveau_event *, int index,
+  struct nouveau_eventh *);
+
 #endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_fence.c 
b/drivers/gpu/drm/nouveau/nouveau_fence.c
index c2e3167..6dde483 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fence.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fence.c
@@ -180,13 +180,14 @@ nouveau_fence_wait_uevent(struct nouveau_fence *fence, 
bool intr)
struct nouveau_channel *chan = fence-channel;
struct nouveau_fifo *pfifo = nouveau_fifo(chan-drm-device);
struct nouveau_fence_priv *priv = chan-drm-fence;
-   struct nouveau_eventh handler = {
-   .func = nouveau_fence_wait_uevent_handler,
-   .priv = priv,
-   };
-   int ret = 0;
+   struct nouveau_eventh *handler;
+   int ret;
 
-   nouveau_event_get(pfifo-uevent, 0, handler);
+   ret = nouveau_event_handler_create(pfifo-uevent, 0,
+  nouveau_fence_wait_uevent_handler,
+  priv, handler);
+   if (ret)
+   return ret;
 
if (fence-timeout) {
unsigned long timeout = fence-timeout - jiffies;
@@ -218,7 +219,7 @@ nouveau_fence_wait_uevent(struct nouveau_fence *fence, bool 
intr)
}
}
 
-   nouveau_event_put(pfifo-uevent, 0, handler);
+   nouveau_event_handler_destroy(pfifo-uevent, 0, handler);
if (unlikely(ret  0))
return ret;
 
-- 
1.8.1.2

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

[PATCH 4/9] drm/nouveau: Allow asymmetric nouveau_event_get/_put

[Peter Hurley]

Most nouveau event handlers have storage in 'static' containers
(structures with lifetimes nearly equivalent to the drm_device),
but are dangerously reused via nouveau_event_get/_put. For
example, if nouveau_event_get is called more than once for a
given handler, the event handler list will be corrupted.

Migrate nouveau_event_get/_put from add/remove semantics to
enable/disable semantics.

Signed-off-by: Peter Hurley pe...@hurleysoftware.com
---
 drivers/gpu/drm/nouveau/core/core/event.c | 20 
 drivers/gpu/drm/nouveau/core/include/core/event.h |  4 
 drivers/gpu/drm/nouveau/nouveau_drm.c |  8 ++--
 3 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
index 1a8d685..0a65ede 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -51,11 +51,13 @@ static void
 nouveau_event_put_locked(struct nouveau_event *event, int index,
 struct nouveau_eventh *handler)
 {
-   if (!--event-index[index].refs) {
-   if (event-disable)
-   event-disable(event, index);
+   if (__test_and_clear_bit(NVKM_EVENT_ENABLE, handler-flags)) {
+   if (!--event-index[index].refs) {
+   if (event-disable)
+   event-disable(event, index);
+   }
+   list_del(handler-head);
}
-   list_del(handler-head);
 }
 
 void
@@ -82,10 +84,12 @@ nouveau_event_get(struct nouveau_event *event, int index,
return;
 
spin_lock_irqsave(event-lock, flags);
-   list_add(handler-head, event-index[index].list);
-   if (!event-index[index].refs++) {
-   if (event-enable)
-   event-enable(event, index);
+   if (!__test_and_set_bit(NVKM_EVENT_ENABLE, handler-flags)) {
+   list_add(handler-head, event-index[index].list);
+   if (!event-index[index].refs++) {
+   if (event-enable)
+   event-enable(event, index);
+   }
}
spin_unlock_irqrestore(event-lock, flags);
 }
diff --git a/drivers/gpu/drm/nouveau/core/include/core/event.h 
b/drivers/gpu/drm/nouveau/core/include/core/event.h
index bdf1a0a..3e704d5 100644
--- a/drivers/gpu/drm/nouveau/core/include/core/event.h
+++ b/drivers/gpu/drm/nouveau/core/include/core/event.h
@@ -5,8 +5,12 @@
 #define NVKM_EVENT_DROP 0
 #define NVKM_EVENT_KEEP 1
 
+/* nouveau_eventh.flags bit #s */
+#define NVKM_EVENT_ENABLE 0
+
 struct nouveau_eventh {
struct list_head head;
+   unsigned long flags;
void *priv;
int (*func)(struct nouveau_eventh *, int index);
 };
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index b29d04b..ccea2c4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -88,7 +88,6 @@ nouveau_drm_vblank_enable(struct drm_device *dev, int head)
 
if (WARN_ON_ONCE(head  ARRAY_SIZE(drm-vblank)))
return -EIO;
-   WARN_ON_ONCE(drm-vblank[head].func);
drm-vblank[head].func = nouveau_drm_vblank_handler;
nouveau_event_get(pdisp-vblank, head, drm-vblank[head]);
return 0;
@@ -99,11 +98,8 @@ nouveau_drm_vblank_disable(struct drm_device *dev, int head)
 {
struct nouveau_drm *drm = nouveau_drm(dev);
struct nouveau_disp *pdisp = nouveau_disp(drm-device);
-   if (drm-vblank[head].func)
-   nouveau_event_put(pdisp-vblank, head, drm-vblank[head]);
-   else
-   WARN_ON_ONCE(1);
-   drm-vblank[head].func = NULL;
+
+   nouveau_event_put(pdisp-vblank, head, drm-vblank[head]);
 }
 
 static u64
-- 
1.8.1.2

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

[PATCH 5/9] drm/nouveau: Add install/remove semantics for event handlers

[Peter Hurley]

Complete migration of nouveau_event_get/_put from add/remove
semantics to enable/disable semantics.

Introduce nouveau_event_handler_install/_remove interface to
add/remove non-local-scope event handlers (ie., those stored in
parent containers). This change in semantics makes explicit the
handler lifetime, and distinguishes one-of event handlers
(such as gpio) from many temporary event handlers (such as uevent).

Signed-off-by: Peter Hurley pe...@hurleysoftware.com
---
 drivers/gpu/drm/nouveau/core/core/event.c  | 63 +++---
 .../gpu/drm/nouveau/core/engine/software/nv50.c| 31 +--
 .../gpu/drm/nouveau/core/engine/software/nvc0.c| 31 +--
 drivers/gpu/drm/nouveau/core/include/core/event.h  |  6 +++
 .../gpu/drm/nouveau/core/include/engine/software.h |  2 +-
 drivers/gpu/drm/nouveau/nouveau_connector.c| 10 +++-
 drivers/gpu/drm/nouveau/nouveau_drm.c  | 17 +-
 7 files changed, 140 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
index 0a65ede..4cd1ebe 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -23,19 +23,60 @@
 #include core/os.h
 #include core/event.h
 
+void
+nouveau_event_handler_install(struct nouveau_event *event, int index,
+ int (*func)(struct nouveau_eventh*, int),
+ void *priv, struct nouveau_eventh *handler)
+{
+   unsigned long flags;
+
+   if (index = event-index_nr)
+   return;
+
+   handler-func = func;
+   handler-priv = priv;
+
+   spin_lock_irqsave(event-lock, flags);
+   list_add(handler-head, event-index[index].list);
+   spin_unlock_irqrestore(event-lock, flags);
+}
+
+void
+nouveau_event_handler_remove(struct nouveau_event *event, int index,
+struct nouveau_eventh *handler)
+{
+   unsigned long flags;
+
+   if (index = event-index_nr)
+   return;
+
+   spin_lock_irqsave(event-lock, flags);
+   list_del(handler-head);
+   spin_unlock_irqrestore(event-lock, flags);
+}
+
 int
 nouveau_event_handler_create(struct nouveau_event *event, int index,
 int (*func)(struct nouveau_eventh*, int),
 void *priv, struct nouveau_eventh **phandler)
 {
struct nouveau_eventh *handler;
+   unsigned long flags;
 
handler = *phandler = kzalloc(sizeof(*handler), GFP_KERNEL);
if (!handler)
return -ENOMEM;
handler-func = func;
handler-priv = priv;
-   nouveau_event_get(event, index, handler);
+   __set_bit(NVKM_EVENT_ENABLE, handler-flags);
+
+   spin_lock_irqsave(event-lock, flags);
+   list_add(handler-head, event-index[index].list);
+   if (!event-index[index].refs++) {
+   if (event-enable)
+   event-enable(event, index);
+   }
+   spin_unlock_irqrestore(event-lock, flags);
return 0;
 }
 
@@ -43,7 +84,18 @@ void
 nouveau_event_handler_destroy(struct nouveau_event *event, int index,
  struct nouveau_eventh *handler)
 {
-   nouveau_event_put(event, index, handler);
+   unsigned long flags;
+
+   if (index = event-index_nr)
+   return;
+
+   spin_lock_irqsave(event-lock, flags);
+   if (!--event-index[index].refs) {
+   if (event-disable)
+   event-disable(event, index);
+   }
+   list_del(handler-head);
+   spin_unlock_irqrestore(event-lock, flags);
kfree(handler);
 }
 
@@ -56,7 +108,6 @@ nouveau_event_put_locked(struct nouveau_event *event, int 
index,
if (event-disable)
event-disable(event, index);
}
-   list_del(handler-head);
}
 }
 
@@ -85,7 +136,6 @@ nouveau_event_get(struct nouveau_event *event, int index,
 
spin_lock_irqsave(event-lock, flags);
if (!__test_and_set_bit(NVKM_EVENT_ENABLE, handler-flags)) {
-   list_add(handler-head, event-index[index].list);
if (!event-index[index].refs++) {
if (event-enable)
event-enable(event, index);
@@ -105,8 +155,9 @@ nouveau_event_trigger(struct nouveau_event *event, int 
index)
 
spin_lock_irqsave(event-lock, flags);
list_for_each_entry_safe(handler, temp, event-index[index].list, 
head) {
-   if (handler-func(handler, index) == NVKM_EVENT_DROP) {
-   nouveau_event_put_locked(event, index, handler);
+   if (test_bit(NVKM_EVENT_ENABLE, handler-flags)) {
+   if (handler-func(handler, index) == NVKM_EVENT_DROP)
+   nouveau_event_put_locked(event, index, handler);
}
}

[PATCH 6/9] drm/nouveau: Convert event handler list to RCU

[Peter Hurley]

Lockdep report [1] correctly identifies a potential deadlock between
nouveau_drm_vblank_enable() and nouveau_drm_vblank_handler() due
to inverted lock order of event-lock with drm core's
dev-vblank_time_lock.

Fix vblank event deadlock by converting event handler list to RCU.
List updates remain serialized by event-lock.
List traversal  handler execution is lockless which prevents
inverted lock order problems with the drm core.
Safe deletion of the event handler is accomplished with
synchronize_rcu() for those handlers stored in nouveau_object-based
containers (nouveau_drm  nv50_/nvc0_software_context); otherwise,
with kfree_rcu (for nouveau_connector  uevent temporary handlers).

[1]
==
[ INFO: possible circular locking dependency detected ]
3.10.0-0+tip-xeon+lockdep #0+tip Not tainted
---
swapper/7/0 is trying to acquire lock:
 ((dev-vblank_time_lock)-rlock){-.}, at: [a0086269] 
drm_handle_vblank+0x69/0x400 [drm]

but task is already holding lock:
 ((event-lock)-rlock){-.}, at: [a0101dbd] 
nouveau_event_trigger+0x4d/0xd0 [nouveau]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

- #1 ((event-lock)-rlock){-.}:
   [810b6d62] lock_acquire+0x92/0x1f0
   [8175e926] _raw_spin_lock_irqsave+0x46/0x60
   [a0101cf7] nouveau_event_get+0x27/0xa0 [nouveau]
   [a01807bd] nouveau_drm_vblank_enable+0x8d/0xf0 [nouveau]
   [a00856d8] drm_vblank_get+0xf8/0x2c0 [drm]
   [a00867f4] drm_wait_vblank+0x84/0x6f0 [drm]
   [a0081719] drm_ioctl+0x559/0x690 [drm]
   [811bed77] do_vfs_ioctl+0x97/0x590
   [811bf301] SyS_ioctl+0x91/0xb0
   [817677c2] system_call_fastpath+0x16/0x1b

- #0 ((dev-vblank_time_lock)-rlock){-.}:
   [810b65c3] __lock_acquire+0x1c43/0x1d30
   [810b6d62] lock_acquire+0x92/0x1f0
   [8175e926] _raw_spin_lock_irqsave+0x46/0x60
   [a0086269] drm_handle_vblank+0x69/0x400 [drm]
   [a0180847] nouveau_drm_vblank_handler+0x27/0x30 [nouveau]
   [a0101e00] nouveau_event_trigger+0x90/0xd0 [nouveau]
   [a012dafd] nv50_disp_intr+0xdd/0x230 [nouveau]
   [a0120451] nouveau_mc_intr+0xa1/0x100 [nouveau]
   [810f3c7c] handle_irq_event_percpu+0x6c/0x3d0
   [810f4028] handle_irq_event+0x48/0x70
   [810f71ca] handle_fasteoi_irq+0x5a/0x100
   [81004512] handle_irq+0x22/0x40
   [817691fa] do_IRQ+0x5a/0xd0
   [8175f76f] ret_from_intr+0x0/0x13
   [8100b876] arch_cpu_idle+0x26/0x30
   [810a5b4e] cpu_startup_entry+0xce/0x410
   [81743d4e] start_secondary+0x255/0x25c

other info that might help us debug this:

 Possible unsafe locking scenario:

   CPU0CPU1
   
  lock((event-lock)-rlock);
   lock((dev-vblank_time_lock)-rlock);
   lock((event-lock)-rlock);
  lock((dev-vblank_time_lock)-rlock);

 *** DEADLOCK ***

1 lock held by swapper/7/0:
 #0:  ((event-lock)-rlock){-.}, at: [a0101dbd] 
nouveau_event_trigger+0x4d/0xd0 [nouveau]

stack backtrace:
CPU: 7 PID: 0 Comm: swapper/7 Not tainted 3.10.0-0+tip-xeon+lockdep #0+tip
Hardware name: Dell Inc. Precision WorkStation T5400  /0RW203, BIOS A11 
04/30/2012
 821ccf60 8802bfdc3b08 81755f39 8802bfdc3b58
 8174f526 0002 8802bfdc3be8 8802b330a7f8
 8802b330a820 8802b330a7f8  0001
Call Trace:
 IRQ  [81755f39] dump_stack+0x19/0x1b
 [8174f526] print_circular_bug+0x1fb/0x20c
 [810b65c3] __lock_acquire+0x1c43/0x1d30
 [810b1f8d] ? trace_hardirqs_off+0xd/0x10
 [8102b1a8] ? flat_send_IPI_mask+0x88/0xa0
 [810b6d62] lock_acquire+0x92/0x1f0
 [a0086269] ? drm_handle_vblank+0x69/0x400 [drm]
 [8175e926] _raw_spin_lock_irqsave+0x46/0x60
 [a0086269] ? drm_handle_vblank+0x69/0x400 [drm]
 [a0086269] drm_handle_vblank+0x69/0x400 [drm]
 [a0180847] nouveau_drm_vblank_handler+0x27/0x30 [nouveau]
 [a0101e00] nouveau_event_trigger+0x90/0xd0 [nouveau]
 [a012dafd] nv50_disp_intr+0xdd/0x230 [nouveau]
 [8175f182] ? _raw_spin_unlock_irqrestore+0x42/0x80
 [8107800c] ? __hrtimer_start_range_ns+0x16c/0x530
 [a0120451] nouveau_mc_intr+0xa1/0x100 [nouveau]
 [810f3c7c] handle_irq_event_percpu+0x6c/0x3d0
 [810f4028] handle_irq_event+0x48/0x70
 [810f718e] ? handle_fasteoi_irq+0x1e/0x100
 [810f71ca] handle_fasteoi_irq+0x5a/0x100
 [81004512] handle_irq+0x22/0x40
 [817691fa] do_IRQ+0x5a/0xd0
 [8175f76f] common_interrupt+0x6f/0x6f
 EOI  

[PATCH 7/9] drm/nouveau: Fold nouveau_event_put_locked into caller

[Peter Hurley]

nouveau_event_put_locked() only has 1 call site; fold into caller.

Signed-off-by: Peter Hurley pe...@hurleysoftware.com
---
 drivers/gpu/drm/nouveau/core/core/event.c | 19 ++-
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
index ce0a0ef..45bcb37 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -100,18 +100,6 @@ nouveau_event_handler_destroy(struct nouveau_event *event, 
int index,
kfree_rcu(handler, rcu);
 }
 
-static void
-nouveau_event_put_locked(struct nouveau_event *event, int index,
-struct nouveau_eventh *handler)
-{
-   if (__test_and_clear_bit(NVKM_EVENT_ENABLE, handler-flags)) {
-   if (!--event-index[index].refs) {
-   if (event-disable)
-   event-disable(event, index);
-   }
-   }
-}
-
 void
 nouveau_event_put(struct nouveau_event *event, int index,
  struct nouveau_eventh *handler)
@@ -122,7 +110,12 @@ nouveau_event_put(struct nouveau_event *event, int index,
return;
 
spin_lock_irqsave(event-lock, flags);
-   nouveau_event_put_locked(event, index, handler);
+   if (__test_and_clear_bit(NVKM_EVENT_ENABLE, handler-flags)) {
+   if (!--event-index[index].refs) {
+   if (event-disable)
+   event-disable(event, index);
+   }
+   }
spin_unlock_irqrestore(event-lock, flags);
 }
 
-- 
1.8.1.2

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

[PATCH 8/9] drm/nouveau: Simplify event interface

[Peter Hurley]

Store event back-pointer and index within struct event_handler;
remove superfluous parameters when event_handler is supplied.

Signed-off-by: Peter Hurley pe...@hurleysoftware.com
---
 drivers/gpu/drm/nouveau/core/core/event.c  | 36 +-
 .../gpu/drm/nouveau/core/engine/software/nv50.c| 11 ++-
 .../gpu/drm/nouveau/core/engine/software/nvc0.c| 11 ++-
 drivers/gpu/drm/nouveau/core/include/core/event.h  | 15 +
 drivers/gpu/drm/nouveau/nouveau_connector.c|  5 +--
 drivers/gpu/drm/nouveau/nouveau_display.c  | 16 +++---
 drivers/gpu/drm/nouveau/nouveau_drm.c  | 10 ++
 drivers/gpu/drm/nouveau/nouveau_fence.c|  2 +-
 8 files changed, 44 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
index 45bcb37..b7d8ae1 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -34,6 +34,9 @@ nouveau_event_handler_install(struct nouveau_event *event, 
int index,
if (index = event-index_nr)
return;
 
+   handler-event = event;
+   handler-index = index;
+
handler-func = func;
handler-priv = priv;
 
@@ -43,12 +46,12 @@ nouveau_event_handler_install(struct nouveau_event *event, 
int index,
 }
 
 void
-nouveau_event_handler_remove(struct nouveau_event *event, int index,
-struct nouveau_eventh *handler)
+nouveau_event_handler_remove(struct nouveau_eventh *handler)
 {
+   struct nouveau_event *event = handler-event;
unsigned long flags;
 
-   if (index = event-index_nr)
+   if (!event)
return;
 
spin_lock_irqsave(event-lock, flags);
@@ -67,6 +70,10 @@ nouveau_event_handler_create(struct nouveau_event *event, 
int index,
handler = *phandler = kzalloc(sizeof(*handler), GFP_KERNEL);
if (!handler)
return -ENOMEM;
+
+   handler-event = event;
+   handler-index = index;
+
handler-func = func;
handler-priv = priv;
__set_bit(NVKM_EVENT_ENABLE, handler-flags);
@@ -82,13 +89,12 @@ nouveau_event_handler_create(struct nouveau_event *event, 
int index,
 }
 
 void
-nouveau_event_handler_destroy(struct nouveau_event *event, int index,
- struct nouveau_eventh *handler)
+nouveau_event_handler_destroy(struct nouveau_eventh *handler)
 {
+   struct nouveau_event *event = handler-event;
+   int index = handler-index;
unsigned long flags;
 
-   if (index = event-index_nr)
-   return;
 
spin_lock_irqsave(event-lock, flags);
if (!--event-index[index].refs) {
@@ -101,12 +107,13 @@ nouveau_event_handler_destroy(struct nouveau_event 
*event, int index,
 }
 
 void
-nouveau_event_put(struct nouveau_event *event, int index,
- struct nouveau_eventh *handler)
+nouveau_event_put(struct nouveau_eventh *handler)
 {
+   struct nouveau_event *event = handler-event;
+   int index = handler-index;
unsigned long flags;
 
-   if (index = event-index_nr)
+   if (!event)
return;
 
spin_lock_irqsave(event-lock, flags);
@@ -120,12 +127,13 @@ nouveau_event_put(struct nouveau_event *event, int index,
 }
 
 void
-nouveau_event_get(struct nouveau_event *event, int index,
- struct nouveau_eventh *handler)
+nouveau_event_get(struct nouveau_eventh *handler)
 {
+   struct nouveau_event *event = handler-event;
+   int index = handler-index;
unsigned long flags;
 
-   if (index = event-index_nr)
+   if (!event)
return;
 
spin_lock_irqsave(event-lock, flags);
@@ -150,7 +158,7 @@ nouveau_event_trigger(struct nouveau_event *event, int 
index)
list_for_each_entry_rcu(handler, event-index[index].list, head) {
if (test_bit(NVKM_EVENT_ENABLE, handler-flags)) {
if (handler-func(handler, index) == NVKM_EVENT_DROP)
-   nouveau_event_put(event, index, handler);
+   nouveau_event_put(handler);
}
}
rcu_read_unlock();
diff --git a/drivers/gpu/drm/nouveau/core/engine/software/nv50.c 
b/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
index 87aeee1..e969f0c 100644
--- a/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
+++ b/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
@@ -92,12 +92,11 @@ nv50_software_mthd_vblsem_release(struct nouveau_object 
*object, u32 mthd,
  void *args, u32 size)
 {
struct nv50_software_chan *chan = (void *)nv_engctx(object-parent);
-   struct nouveau_disp *disp = nouveau_disp(object);
u32 crtc = *(u32 *)args;
if (crtc  1)
return -EINVAL;
 
-   nouveau_event_get(disp-vblank, crtc, chan-base.vblank.event[crtc]);
+   

[PATCH 9/9] drm/nouveau: Simplify event handler interface

[Peter Hurley]

Remove index parameter; access index via handler-index instead.
Dissociate handler from related container; use handler-priv to
access container.

Signed-off-by: Peter Hurley pe...@hurleysoftware.com
---
 drivers/gpu/drm/nouveau/core/core/event.c   | 6 +++---
 drivers/gpu/drm/nouveau/core/engine/software/nv50.c | 7 +++
 drivers/gpu/drm/nouveau/core/engine/software/nvc0.c | 7 +++
 drivers/gpu/drm/nouveau/core/include/core/event.h   | 6 +++---
 drivers/gpu/drm/nouveau/nouveau_connector.c | 9 +
 drivers/gpu/drm/nouveau/nouveau_drm.c   | 9 +
 drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +-
 7 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/event.c 
b/drivers/gpu/drm/nouveau/core/core/event.c
index b7d8ae1..1240fef 100644
--- a/drivers/gpu/drm/nouveau/core/core/event.c
+++ b/drivers/gpu/drm/nouveau/core/core/event.c
@@ -26,7 +26,7 @@
 
 void
 nouveau_event_handler_install(struct nouveau_event *event, int index,
- int (*func)(struct nouveau_eventh*, int),
+ int (*func)(struct nouveau_eventh*),
  void *priv, struct nouveau_eventh *handler)
 {
unsigned long flags;
@@ -61,7 +61,7 @@ nouveau_event_handler_remove(struct nouveau_eventh *handler)
 
 int
 nouveau_event_handler_create(struct nouveau_event *event, int index,
-int (*func)(struct nouveau_eventh*, int),
+int (*func)(struct nouveau_eventh*),
 void *priv, struct nouveau_eventh **phandler)
 {
struct nouveau_eventh *handler;
@@ -157,7 +157,7 @@ nouveau_event_trigger(struct nouveau_event *event, int 
index)
rcu_read_lock();
list_for_each_entry_rcu(handler, event-index[index].list, head) {
if (test_bit(NVKM_EVENT_ENABLE, handler-flags)) {
-   if (handler-func(handler, index) == NVKM_EVENT_DROP)
+   if (handler-func(handler) == NVKM_EVENT_DROP)
nouveau_event_put(handler);
}
}
diff --git a/drivers/gpu/drm/nouveau/core/engine/software/nv50.c 
b/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
index e969f0c..bf6f23b 100644
--- a/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
+++ b/drivers/gpu/drm/nouveau/core/engine/software/nv50.c
@@ -131,10 +131,9 @@ nv50_software_sclass[] = {
  
**/
 
 static int
-nv50_software_vblsem_release(struct nouveau_eventh *event, int head)
+nv50_software_vblsem_release(struct nouveau_eventh *handler)
 {
-   struct nouveau_software_chan *chan =
-   container_of(event, struct nouveau_software_chan, 
vblank.event[head]);
+   struct nouveau_software_chan *chan = handler-priv;
struct nv50_software_priv *priv = (void *)nv_object(chan)-engine;
struct nouveau_bar *bar = nouveau_bar(priv);
 
@@ -172,7 +171,7 @@ nv50_software_context_ctor(struct nouveau_object *parent,
for (i = 0; i  ARRAY_SIZE(chan-base.vblank.event); i++) {
nouveau_event_handler_install(disp-vblank, i,
  nv50_software_vblsem_release,
- NULL,
+ chan,
  chan-base.vblank.event[i]);
}
return 0;
diff --git a/drivers/gpu/drm/nouveau/core/engine/software/nvc0.c 
b/drivers/gpu/drm/nouveau/core/engine/software/nvc0.c
index d06658a..1a2a7a8 100644
--- a/drivers/gpu/drm/nouveau/core/engine/software/nvc0.c
+++ b/drivers/gpu/drm/nouveau/core/engine/software/nvc0.c
@@ -143,10 +143,9 @@ nvc0_software_sclass[] = {
  
**/
 
 static int
-nvc0_software_vblsem_release(struct nouveau_eventh *event, int head)
+nvc0_software_vblsem_release(struct nouveau_eventh *handler)
 {
-   struct nouveau_software_chan *chan =
-   container_of(event, struct nouveau_software_chan, 
vblank.event[head]);
+   struct nouveau_software_chan *chan = handler-priv;
struct nvc0_software_priv *priv = (void *)nv_object(chan)-engine;
struct nouveau_bar *bar = nouveau_bar(priv);
 
@@ -178,7 +177,7 @@ nvc0_software_context_ctor(struct nouveau_object *parent,
for (i = 0; i  ARRAY_SIZE(chan-base.vblank.event); i++) {
nouveau_event_handler_install(disp-vblank, i,
  nvc0_software_vblsem_release,
- NULL,
+ chan,
  chan-base.vblank.event[i]);
}
return 0;
diff --git a/drivers/gpu/drm/nouveau/core/include/core/event.h 
b/drivers/gpu/drm/nouveau/core/include/core/event.h

[Bug 68585] Recent Mesa git make Kwin crash with AMD R300g driver

[bugzilla-daemon]

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

--- Comment #6 from Marek Olšák mar...@gmail.com ---
Created attachment 84748
  -- https://bugs.freedesktop.org/attachment.cgi?id=84748action=edit
possible fix

Could you please test this patch?

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

[Bug 68585] Recent Mesa git make Kwin crash with AMD R300g driver

[bugzilla-daemon]

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

--- Comment #7 from Richard Van Den Boom r...@cryptolab.net ---
I'll see what I can do.

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

[bugzilla-daemon]

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

--- Comment #12 from Peter Kraus peter.kr...@geeksonbikes.net ---
Hello,
I guess I'm just really unlucky. Compilation of required merge according to
git bisect fails with:

CXXLDlibOSMesa.la
/usr/bin/ld: i386:x86-64 architecture of input file
`../../../../src/mesa/.libs/libmesa.a(ast_expr.o)' is incompatible with i386
output

Which is similar to a bug report here: bug 50754. Adding those variables into
the build script doesn't help (in fact, they've been in before). Looks like I'm
stuffed yet again!

-- 
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 68585] Recent Mesa git make Kwin crash with AMD R300g driver

[bugzilla-daemon]

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

--- Comment #8 from Richard Van Den Boom r...@cryptolab.net ---
I did a git pull to be as possible up to date and applied the patch.
It does indeed seem to fix Kwin crash at startup.
Congratulations!

-- 
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 64810] EGL/Gles/Weston give segfault on RADEONSI with egl_gallium.so

[bugzilla-daemon]

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

--- Comment #9 from tux_mind massimo.drag...@gmail.com ---
hello there, i'm having the same issue and i recompiled mesa with debugging
symbols.
i'm using mesa-9.2.0_rc1 on gentoo.
i attached gdb and i found that the issue is at
src/gallium/drivers/r600/r600_query.c:743.

735 void r600_init_query_functions(struct r600_context *rctx)
736 {
737 rctx-context.create_query = r600_create_query;
738 rctx-context.destroy_query = r600_destroy_query;
739 rctx-context.begin_query = r600_begin_query;
740 rctx-context.end_query = r600_end_query;
741 rctx-context.get_query_result = r600_get_query_result;
742
743 if (rctx-screen-info.r600_num_backends  0)

breaking gdb on line 743 i got this: http://pastebin.com/A4JANB5F

as you can see rctx-screen is null ( 0x0 ), please, can you fix that?

i hope this helps.

-- 
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 67107] Xorg starts and crashes with DPM enable

[bugzilla-daemon]

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

--- Comment #7 from Christopher Chmielewski c.chmielew...@outlook.com ---
Created attachment 84753
  -- https://bugs.freedesktop.org/attachment.cgi?id=84753action=edit
dmesg

Like I said it freezes up my computer so I had to restart in single user mode
so there might be some extra stuff at the bottom.

-- 
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 67107] Xorg starts and crashes with DPM enable

[bugzilla-daemon]

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

--- Comment #8 from Christopher Chmielewski c.chmielew...@outlook.com ---
Created attachment 84754
  -- https://bugs.freedesktop.org/attachment.cgi?id=84754action=edit
xorg log

Both the dmesg and xorg log are from rc7

-- 
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 60791] Display corruption with Radeon driver during boot and on desktop

[bugzilla-daemon]

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

--- Comment #12 from Brian Hall hal...@gmail.com ---
Bisect results below. According to my Xorg.0.log, my board is a 
ATI Radeon HD 4200 (ChipID = 0x9710) and lspci calls it a RS880.

6f8bbaf568c7f2c497558bfd04654c0b9841ad57 is the first bad commit
commit 6f8bbaf568c7f2c497558bfd04654c0b9841ad57
Author: Alex Deucher alexander.deuc...@amd.com
Date:   Tue Jul 30 00:22:53 2013 -0400

drm/radeon/atom: initialize more atom interpretor elements to 0

commit 42a21826dc54583cdb79cc8477732e911ac9c376 upstream.

The ProcessAuxChannel table on some rv635 boards assumes
the divmul members are initialized to 0 otherwise we get
an invalid fb offset since it has a bad mask set when
setting the fb base.  While here initialize all the
atom interpretor elements to 0.

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

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org

:04 04 d2bb057047f71419a89def40e6e21dc948c5784c
7e49987ae73078e644723f0cb6c791e15e102ab0 Mdrivers

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

[PATCH 0/6] Nouveau on ARM fixes

[Lucas Stach]

This is the first set of patches to make Nouveau work
on Tegra. Those are only the obvious correctness fixes,
a lot of optimization work remains to be done, but at least
it's enough to get accel working and let the machine survive
a piglit run.

A new BO flag is introduced to allow userspace to hint the
kernel about possible optimizations.

Lucas Stach (6):
  drm/ttm: recognize ARM arch in ioprot handler
  drm/ttm: introduce dma cache sync helpers
  drm/nouveau: hook up cache sync functions
  drm/nouveau: introduce NOUVEAU_GEM_TILE_WCUS
  drm/nouveau: map IB write-combined
  drm/nouveau: use MSI interrupts

 drivers/gpu/drm/nouveau/core/include/subdev/mc.h |  1 +
 drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 ++
 drivers/gpu/drm/nouveau/nouveau_bo.c | 15 -
 drivers/gpu/drm/nouveau/nouveau_bo.h |  1 +
 drivers/gpu/drm/nouveau/nouveau_chan.c   |  3 ++-
 drivers/gpu/drm/nouveau/nouveau_gem.c|  5 +
 drivers/gpu/drm/ttm/ttm_bo_util.c|  2 +-
 drivers/gpu/drm/ttm/ttm_tt.c | 25 +
 include/drm/ttm/ttm_bo_driver.h  | 28 
 include/uapi/drm/nouveau_drm.h   |  1 +
 10 files changed, 95 insertions(+), 3 deletions(-)

-- 
1.8.3.1

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

[PATCH 5/6] drm/nouveau: map IB write-combined

[Lucas Stach]

Signed-off-by: Lucas Stach d...@lynxeye.de
---
 drivers/gpu/drm/nouveau/nouveau_chan.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_chan.c 
b/drivers/gpu/drm/nouveau/nouveau_chan.c
index e84f4c3..3b54e8f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_chan.c
+++ b/drivers/gpu/drm/nouveau/nouveau_chan.c
@@ -114,7 +114,8 @@ nouveau_channel_prep(struct nouveau_drm *drm, struct 
nouveau_cli *cli,
if (nouveau_vram_pushbuf)
target = TTM_PL_FLAG_VRAM;
 
-   ret = nouveau_bo_new(drm-dev, size, 0, target, 0, 0, NULL,
+   ret = nouveau_bo_new(drm-dev, size, 0, target, 0,
+   NOUVEAU_GEM_TILE_WCUS, NULL,
chan-push.buffer);
if (ret == 0) {
ret = nouveau_bo_pin(chan-push.buffer, target);
-- 
1.8.3.1

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

[PATCH 6/6] drm/nouveau: use MSI interrupts

[Lucas Stach]

MSIs were only problematic on some old, broken chipsets. But now that we
already see systems where PCI legacy interrupts are somewhat flaky, it's
really time to move to MSIs.

Signed-off-by: Lucas Stach d...@lynxeye.de
---
 drivers/gpu/drm/nouveau/core/include/subdev/mc.h |  1 +
 drivers/gpu/drm/nouveau/core/subdev/mc/base.c| 17 +
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h 
b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
index 9d2cd20..ce6569f 100644
--- a/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
+++ b/drivers/gpu/drm/nouveau/core/include/subdev/mc.h
@@ -12,6 +12,7 @@ struct nouveau_mc_intr {
 struct nouveau_mc {
struct nouveau_subdev base;
const struct nouveau_mc_intr *intr_map;
+   bool use_msi;
 };
 
 static inline struct nouveau_mc *
diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c 
b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
index ec9cd6f..02b337e 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/mc/base.c
@@ -23,6 +23,7 @@
  */
 
 #include subdev/mc.h
+#include core/option.h
 
 static irqreturn_t
 nouveau_mc_intr(int irq, void *arg)
@@ -43,6 +44,9 @@ nouveau_mc_intr(int irq, void *arg)
map++;
}
 
+   if (pmc-use_msi)
+   nv_wr08(pmc-base.base.parent, 0x00088068, 0xff);
+
if (intr) {
nv_error(pmc, unknown intr 0x%08x\n, stat);
}
@@ -75,6 +79,8 @@ _nouveau_mc_dtor(struct nouveau_object *object)
struct nouveau_device *device = nv_device(object);
struct nouveau_mc *pmc = (void *)object;
free_irq(device-pdev-irq, pmc);
+   if (pmc-use_msi)
+   pci_disable_msi(device-pdev);
nouveau_subdev_destroy(pmc-base);
 }
 
@@ -96,6 +102,17 @@ nouveau_mc_create_(struct nouveau_object *parent, struct 
nouveau_object *engine,
 
pmc-intr_map = intr_map;
 
+   pmc-use_msi = nouveau_boolopt(device-cfgopt, NvMSI, true);
+   if (pmc-use_msi) {
+   ret = pci_enable_msi(device-pdev);
+   if (ret) {
+   pmc-use_msi = false;
+   } else {
+   nv_wr08(device, 0x00088068, 0xff);
+   nv_info(pmc, MSI interrupts enabled\n);
+   }
+   }
+
ret = request_irq(device-pdev-irq, nouveau_mc_intr,
  IRQF_SHARED, nouveau, pmc);
if (ret  0)
-- 
1.8.3.1

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