date:20160704

[Bug 96782] [regression bisected] R600 fp64 and glsl-4.00 piglit failures

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

Marek OlÅ¡Ã¡k  changed:

   What|Removed |Added

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

--- Comment #3 from Marek OlÅ¡Ã¡k  ---
I've pushed the fix. Closing.

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

[Bug 95528] BioShock Infinite graphical glitches on radeonsi

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

Mike Lothian  changed:

   What|Removed |Added

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

--- Comment #19 from Mike Lothian  ---
D21961 which isn't currently in llvm master fixes the issue for me

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

[Bug 96794] VM_CONTEXT1_PROTECTION_FAULT_ADDR

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

Thorsten Hirsch  changed:

   What|Removed |Added

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

--- Comment #3 from Thorsten Hirsch  ---
Yes, the patch works. Alien Isolation now runs flawless with amdgpu driver (w/o
amdgpu-pro).

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

[PATCH 6/6] drm/tilcdc: use drm_crtc_handle_vblank()

2016-07-04 Thread Gustavo Padovan

From: Gustavo Padovan 

Remove legacy usage of drm_handle_vblank()

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 79027b1..107c8bd 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -697,7 +697,7 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)

spin_unlock_irqrestore(_crtc->irq_lock, flags);

-   drm_handle_vblank(dev, 0);
+   drm_crtc_handle_vblank(crtc);

if (!skip_event) {
struct drm_pending_vblank_event *event;
-- 
2.5.5

[PATCH 5/6] drm/rcar-du: use drm_crtc_handle_vblank()

2016-07-04 Thread Gustavo Padovan

From: Gustavo Padovan 

Remove legacy usage of drm_handle_vblank()

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 0d8bdda..e39fcef 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -552,7 +552,7 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
rcar_du_crtc_write(rcrtc, DSRCR, status & DSRCR_MASK);

if (status & DSSR_FRM) {
-   drm_handle_vblank(rcrtc->crtc.dev, rcrtc->index);
+   drm_crtc_handle_vblank(>crtc);
rcar_du_crtc_finish_page_flip(rcrtc);
ret = IRQ_HANDLED;
}
-- 
2.5.5

[PATCH 4/6] drm/nouveau: use drm_crtc_handle_vblank()

2016-07-04 Thread Gustavo Padovan

From: Gustavo Padovan 

Remove legacy usage of drm_handle_vblank()

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index bd8d5bb..6e97862 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -47,7 +47,7 @@ nouveau_display_vblank_handler(struct nvif_notify *notify)
 {
struct nouveau_crtc *nv_crtc =
container_of(notify, typeof(*nv_crtc), vblank);
-   drm_handle_vblank(nv_crtc->base.dev, nv_crtc->index);
+   drm_crtc_handle_vblank(_crtc->base);
return NVIF_NOTIFY_KEEP;
 }

-- 
2.5.5

[PATCH 3/6] drm/atmel: use drm_crtc_handle_vblank()

2016-07-04 Thread Gustavo Padovan

From: Gustavo Padovan 

Remove legacy usage of drm_handle_vblank()

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 613f6c9..a978381 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -383,7 +383,7 @@ static void atmel_hlcdc_crtc_finish_page_flip(struct 
atmel_hlcdc_crtc *crtc)

 void atmel_hlcdc_crtc_irq(struct drm_crtc *c)
 {
-   drm_handle_vblank(c->dev, 0);
+   drm_crtc_handle_vblank(c);
atmel_hlcdc_crtc_finish_page_flip(drm_crtc_to_atmel_hlcdc_crtc(c));
 }

-- 
2.5.5

[PATCH 2/6] drm/armada: use drm_crtc_handle_vblank()

2016-07-04 Thread Gustavo Padovan

From: Gustavo Padovan 

Remove legacy usage of drm_handle_vblank()

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/armada/armada_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/armada/armada_crtc.c 
b/drivers/gpu/drm/armada/armada_crtc.c
index 34405e4..2f58e9e 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -410,7 +410,7 @@ static void armada_drm_crtc_irq(struct armada_crtc *dcrtc, 
u32 stat)
DRM_ERROR("graphics underflow on crtc %u\n", dcrtc->num);

if (stat & VSYNC_IRQ)
-   drm_handle_vblank(dcrtc->crtc.dev, dcrtc->num);
+   drm_crtc_handle_vblank(>crtc);

spin_lock(>irq_lock);
ovl_plane = dcrtc->plane;
-- 
2.5.5

[PATCH 1/6] drm: make drm_vblank_count_and_time() static

2016-07-04 Thread Gustavo Padovan

From: Gustavo Padovan 

As they are not used anywhere outside drm_irq.c make them static.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/drm_irq.c | 7 ++-
 include/drm/drmP.h| 2 --
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 149453c..7d6a406 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -945,8 +945,8 @@ EXPORT_SYMBOL(drm_crtc_vblank_count);
  *
  * This is the legacy version of drm_crtc_vblank_count_and_time().
  */
-u32 drm_vblank_count_and_time(struct drm_device *dev, unsigned int pipe,
- struct timeval *vblanktime)
+static u32 drm_vblank_count_and_time(struct drm_device *dev, unsigned int pipe,
+struct timeval *vblanktime)
 {
struct drm_vblank_crtc *vblank = >vblank[pipe];
u32 vblank_count;
@@ -963,7 +963,6 @@ u32 drm_vblank_count_and_time(struct drm_device *dev, 
unsigned int pipe,

return vblank_count;
 }
-EXPORT_SYMBOL(drm_vblank_count_and_time);

 /**
  * drm_crtc_vblank_count_and_time - retrieve "cooked" vblank counter value
@@ -975,8 +974,6 @@ EXPORT_SYMBOL(drm_vblank_count_and_time);
  * vblank events since the system was booted, including lost events due to
  * modesetting activity. Returns corresponding system timestamp of the time
  * of the vblank interval that corresponds to the current vblank counter value.
- *
- * This is the native KMS version of drm_vblank_count_and_time().
  */
 u32 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
   struct timeval *vblanktime)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index cf918e3e..c2fe2cf 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -942,8 +942,6 @@ extern int drm_wait_vblank(struct drm_device *dev, void 
*data,
   struct drm_file *filp);
 extern u32 drm_vblank_count(struct drm_device *dev, unsigned int pipe);
 extern u32 drm_crtc_vblank_count(struct drm_crtc *crtc);
-extern u32 drm_vblank_count_and_time(struct drm_device *dev, unsigned int pipe,
-struct timeval *vblanktime);
 extern u32 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
  struct timeval *vblanktime);
 extern void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
-- 
2.5.5

[PATCH v3 4/4] Documentation: add doc for sync_file_get_fence()

2016-07-04 Thread Gustavo Padovan

From: Gustavo Padovan 

Document the new function added to sync_file.c

v2: Adapt to fence_array

Signed-off-by: Gustavo Padovan 
---
 Documentation/sync_file.txt | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/Documentation/sync_file.txt b/Documentation/sync_file.txt
index e8e2eba..ae2dbad1 100644
--- a/Documentation/sync_file.txt
+++ b/Documentation/sync_file.txt
@@ -64,6 +64,21 @@ The sync_file fd now can be sent to userspace.
 If the creation process fail, or the sync_file needs to be released by any
 other reason fput(sync_file->file) should be used.

+Receiving Sync Files from Userspace
+---
+
+When userspace needs to send an in-fence to the driver it pass file descriptor
+of the Sync File to the kernel. The kernel then can retrieve the fences
+from it.
+
+Interface:
+   struct fence *sync_file_get_fence(int fd);
+
+
+The function return a struct fence pointer referencing the fence(s) in the Sync
+File.
+
+
 References:
 [1] struct sync_file in include/linux/sync_file.h
 [2] All interfaces mentioned above defined in include/linux/sync_file.h
-- 
2.5.5

[PATCH v3 3/4] dma-buf/sync_file: add sync_file_get_fence()

2016-07-04 Thread Gustavo Padovan

From: Gustavo Padovan 

Creates a function that given an sync file descriptor returns a
fence containing all fences in the sync_file.

v2: Comments by Daniel Vetter
- Adapt to new version of fence_collection_init()
- Hold a reference for the fence we return

v3:
- Adapt to use fput() directly
- rename to sync_file_get_fence() as we always return one fence

v4: Adapt to use fence_array

v5: set fence through fence_get()

Signed-off-by: Gustavo Padovan 
Reviewed-by: Chris Wilson 
---
 drivers/dma-buf/sync_file.c | 23 +++
 include/linux/sync_file.h   |  1 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index a223f48..61a687c 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -116,6 +116,29 @@ err:
return NULL;
 }

+/**
+ * sync_file_get_fence - get the fence related to the sync_file fd
+ * @fd:sync_file fd to get the fence from
+ *
+ * Ensures @fd references a valid sync_file and returns a fence that
+ * represents all fence in the sync_file. On error NULL is returned.
+ */
+struct fence *sync_file_get_fence(int fd)
+{
+   struct sync_file *sync_file;
+   struct fence *fence;
+
+   sync_file = sync_file_fdget(fd);
+   if (!sync_file)
+   return NULL;
+
+   fence = fence_get(sync_file->fence);
+   fput(sync_file->file);
+
+   return fence;
+}
+EXPORT_SYMBOL(sync_file_get_fence);
+
 static int sync_file_set_fence(struct sync_file *sync_file,
   struct fence **fences, int num_fences)
 {
diff --git a/include/linux/sync_file.h b/include/linux/sync_file.h
index 2efc5ec..f7de5a0 100644
--- a/include/linux/sync_file.h
+++ b/include/linux/sync_file.h
@@ -46,5 +46,6 @@ struct sync_file {
 };

 struct sync_file *sync_file_create(struct fence *fence);
+struct fence *sync_file_get_fence(int fd);

 #endif /* _LINUX_SYNC_H */
-- 
2.5.5

[PATCH v3 2/4] dma-buf/sync_file: rework fence storage in struct file

2016-07-04 Thread Gustavo Padovan

From: Gustavo Padovan 

Create sync_file->fence to abstract the type of fence we are using for
each sync_file. If only one fence is present we use a normal struct fence
but if there is more fences to be added to the sync_file a fence_array
is created.

This change cleans up sync_file a bit. We don't need to have sync_file_cb
array anymore. Instead, as we always have  one fence, only one fence
callback is registered per sync_file.

v4: fixes checkpatch warnings

v4: Comments from Chris Wilson
- use sizeof(*fence) to reallocate array
- fix typo in comments
- protect num_fences sum against overflows
- use array->base instead of casting the to struct fence

v3: Comments from Chris Wilson and Christian KÃ¶nig
- struct sync_file lost status member in favor of fence_is_signaled()
- drop use of fence_array_teardown()
- use sizeof(*fence) to allocate only an array on fence pointers

v2: Comments from Chris Wilson and Christian KÃ¶nig
- Not using fence_ops anymore
- fence_is_array() was created to differentiate fence from fence_array
- fence_array_teardown() is now exported and used under fence_is_array()
- struct sync_file lost num_fences member

Cc: Chris Wilson 
Cc: Christian KÃ¶nig 
Signed-off-by: Gustavo Padovan 
Reviewed-by: Chris Wilson 
---
 drivers/dma-buf/sync_file.c  | 169 +++
 drivers/staging/android/sync_debug.c |  12 ++-
 include/linux/sync_file.h|  17 ++--
 3 files changed, 124 insertions(+), 74 deletions(-)

diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index 9aaa608..a223f48 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -28,11 +28,11 @@

 static const struct file_operations sync_file_fops;

-static struct sync_file *sync_file_alloc(int size)
+static struct sync_file *sync_file_alloc(void)
 {
struct sync_file *sync_file;

-   sync_file = kzalloc(size, GFP_KERNEL);
+   sync_file = kzalloc(sizeof(*sync_file), GFP_KERNEL);
if (!sync_file)
return NULL;

@@ -45,6 +45,8 @@ static struct sync_file *sync_file_alloc(int size)

init_waitqueue_head(_file->wq);

+   INIT_LIST_HEAD(_file->cb.node);
+
return sync_file;

 err:
@@ -54,14 +56,11 @@ err:

 static void fence_check_cb_func(struct fence *f, struct fence_cb *cb)
 {
-   struct sync_file_cb *check;
struct sync_file *sync_file;

-   check = container_of(cb, struct sync_file_cb, cb);
-   sync_file = check->sync_file;
+   sync_file = container_of(cb, struct sync_file, cb);

-   if (atomic_dec_and_test(_file->status))
-   wake_up_all(_file->wq);
+   wake_up_all(_file->wq);
 }

 /**
@@ -76,22 +75,18 @@ struct sync_file *sync_file_create(struct fence *fence)
 {
struct sync_file *sync_file;

-   sync_file = sync_file_alloc(offsetof(struct sync_file, cbs[1]));
+   sync_file = sync_file_alloc();
if (!sync_file)
return NULL;

-   sync_file->num_fences = 1;
-   atomic_set(_file->status, 1);
+   sync_file->fence = fence;
+
snprintf(sync_file->name, sizeof(sync_file->name), "%s-%s%llu-%d",
 fence->ops->get_driver_name(fence),
 fence->ops->get_timeline_name(fence), fence->context,
 fence->seqno);

-   sync_file->cbs[0].fence = fence;
-   sync_file->cbs[0].sync_file = sync_file;
-   if (fence_add_callback(fence, _file->cbs[0].cb,
-  fence_check_cb_func))
-   atomic_dec(_file->status);
+   fence_add_callback(fence, _file->cb, fence_check_cb_func);

return sync_file;
 }
@@ -121,14 +116,49 @@ err:
return NULL;
 }

-static void sync_file_add_pt(struct sync_file *sync_file, int *i,
-struct fence *fence)
+static int sync_file_set_fence(struct sync_file *sync_file,
+  struct fence **fences, int num_fences)
+{
+   struct fence_array *array;
+
+   /*
+* The reference for the fences in the new sync_file and held
+* in add_fence() during the merge procedure, so for num_fences == 1
+* we already own a new reference to the fence. For num_fence > 1
+* we own the reference of the fence_array creation.
+*/
+   if (num_fences == 1) {
+   sync_file->fence = fences[0];
+   } else {
+   array = fence_array_create(num_fences, fences,
+  fence_context_alloc(1), 1, false);
+   if (!array)
+   return -ENOMEM;
+
+   sync_file->fence = >base;
+   }
+
+   return 0;
+}
+
+static struct fence **get_fences(struct sync_file *sync_file, int *num_fences)
 {
-   sync_file->cbs[*i].fence = fence;
-   sync_file->cbs[*i].sync_file = sync_file;
+   if

[PATCH v3 1/4] dma-buf/fence-array: add fence_is_array()

2016-07-04 Thread Gustavo Padovan

From: Gustavo Padovan 

Add helper to check if fence is array.

v2: Comments from Chris Wilson
- remove ternary if from ops comparison
- add EXPORT_SYMBOL(fence_array_ops)

Cc: Chris Wilson 
Cc: Christian KÃ¶nig 
Signed-off-by: Gustavo Padovan 
Reviewed-by: Chris Wilson 
---
 drivers/dma-buf/fence-array.c |  1 +
 include/linux/fence-array.h   | 10 ++
 2 files changed, 11 insertions(+)

diff --git a/drivers/dma-buf/fence-array.c b/drivers/dma-buf/fence-array.c
index a8731c8..ee50022 100644
--- a/drivers/dma-buf/fence-array.c
+++ b/drivers/dma-buf/fence-array.c
@@ -99,6 +99,7 @@ const struct fence_ops fence_array_ops = {
.wait = fence_default_wait,
.release = fence_array_release,
 };
+EXPORT_SYMBOL(fence_array_ops);

 /**
  * fence_array_create - Create a custom fence array
diff --git a/include/linux/fence-array.h b/include/linux/fence-array.h
index 86baaa4..a44794e 100644
--- a/include/linux/fence-array.h
+++ b/include/linux/fence-array.h
@@ -52,6 +52,16 @@ struct fence_array {
 extern const struct fence_ops fence_array_ops;

 /**
+ * fence_is_array - check if a fence is from the array subsclass
+ *
+ * Return true if it is a fence_array and false otherwise.
+ */
+static inline bool fence_is_array(struct fence *fence)
+{
+   return fence->ops == _array_ops;
+}
+
+/**
  * to_fence_array - cast a fence to a fence_array
  * @fence: fence to cast to a fence_array
  *
-- 
2.5.5

[PATCH v3 0/4] dma-buf/sync_file: rework fences on struct sync_file

2016-07-04 Thread Gustavo Padovan

From: Gustavo Padovan 

Hi all,

This patchset improves fence support on Sync File. The basic idea
is to have only sync_file->fence and store all fences there, either as
normal fences or fence_arrays. That way we can remove some potential
duplication when using fence_array with sync_file: the duplication of the array
of fences and the duplication of fence_add_callback() for all fences.

Now when creating a new sync_file during the merge process sync_file_set_fence()
will set sync_file->fence based on the number of fences for that sync_file. If
there is more than one fence a fence_array is created. One important advantage
approach is that we only add one fence callback now, no matter how many fences
there are in a sync_file - the individual callbacks are added by fence_array.

This patchset also adds sync_file_get_fence() to retrieve fence from a sync_file
file descriptor.

Please review! Thanks!

Gustavo

---
Changes sunce PATCH v2 (Coments from Chris Wilson)
 - fix checkpatch warnings
 - use fence_get() to set the fence directly

Changes since PATCH v1 (Comments from Chris Wilson)
 - use sizeof(*fence) to reallocate array
 - fix typo in comments
 - protect num_fences sum against overflows
 - use array->base instead of casting the to struct fence
 - remove ternary if from ops comparison in fence_is_array()
 - add EXPORT_SYMBOL(fence_array_ops)

Changes since RFC v2 (Comments from Chris Wilson and Christian KÃ¶nig):
 - struct sync_file lost status member in favor of fence_is_signaled()
 - drop use of fence_array_teardown()
 - use sizeof(*fence) to allocate only an array on fence pointers

Changes since RFC v1 (Comments from Chris Wilson and Christian KÃ¶nig):
 - Not using fence_ops anymore.
 - fence_is_array() was created to differentiate fence from fence_array
 - fence_array_teardown() is now exported and used under fence_is_array()
 - struct sync_file lost num_fences member

Gustavo Padovan (4):
  dma-buf/fence-array: add fence_is_array()
  dma-buf/sync_file: rework fence storage in struct file
  dma-buf/sync_file: add sync_file_get_fence()
  Documentation: add doc for sync_file_get_fence()


Gustavo Padovan (4):
  dma-buf/fence-array: add fence_is_array()
  dma-buf/sync_file: rework fence storage in struct file
  dma-buf/sync_file: add sync_file_get_fence()
  Documentation: add doc for sync_file_get_fence()

 Documentation/sync_file.txt  |  15 +++
 drivers/dma-buf/fence-array.c|   1 +
 drivers/dma-buf/sync_file.c  | 192 ---
 drivers/staging/android/sync_debug.c |  12 ++-
 include/linux/fence-array.h  |  10 ++
 include/linux/sync_file.h|  18 ++--
 6 files changed, 174 insertions(+), 74 deletions(-)

-- 
2.5.5

[Bug 80419] XCOM: Enemy Unknown Causes lockup

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #140 from Jan Vesely  ---
(In reply to Nicolai HÃ¤hnle from comment #139)
> Are you running with some kind of virtualization enabled? I'm not familiar
> with these AMD-Vi messages.

Those are printed by the IOMMU driver (device accessed unmapped page). Not
necessarily virtualization related.

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

[Bug 93341] GPU lockups on RadeonHD 7770 (radeonsi driver) when running OpenGL games or after extended periods of time

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #11 from Jean-FranÃ§ois Fortin Tam  ---
You are right Nicolai, the stressor to trigger the bug is more subtle than I
thought after all... while I was able to trigger this within minutes a few days
ago, now my machine has been running with those 3-4 webGL benchmarks for the
entire day today without issues.

Just to make sure it's really not a hardware issue, I tried with different
power supplies, I measured the consumption (the machine eats between 150 and
220 watts at the very maximum, whereas the PSU can easily supply 500 watts),
and tested the "Other OS", which doesn't exhibit the issue... so it does still
look like a software bug, at least. I'd be happy to provide any other info you
may need.

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

[Bug 80419] XCOM: Enemy Unknown Causes lockup

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #139 from Nicolai HÃ¤hnle  ---
Are you running with some kind of virtualization enabled? I'm not familiar with
these AMD-Vi messages.

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

[GIT PULL] drm-hisilicon-next

2016-07-04 Thread Xinliang Liu

Hi Dave,

This drm-hisilicon-next-2016-07-04 tag includes 3 small fixes for 4.8.
Please help to pull and let me know if there is any problem.

Thanks,
-xinliang



The following changes since commit dac2c48ca5ac9bb2d6339aaa733c60d5b801ee86:

  Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu
into drm-next (2016-07-02 16:21:35 +1000)

are available in the git repository at:

  git at github.com:xin3liang/linux.git tags/drm-hisilicon-next-2016-07-04

for you to fetch changes up to 85d8747d2a24e913fffac68024b2154db266c50c:

  drm/hisilicon: Fix ADE vblank on/off handling (2016-07-04 18:49:21 +0800)


Wei Yongjun (1):
  drm/hisilicon: Fix return value check in ade_dts_parse()

Xinliang Liu (1):
  drm/hisilicon: Fix ADE vblank on/off handling

Zoltan Kuscsik (1):
  drm/hisilicon: add select HISI_KIRIN_DW_DSI

 drivers/gpu/drm/hisilicon/kirin/Kconfig |  1 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 14 --
 2 files changed, 9 insertions(+), 6 deletions(-)

[PATCH] apple-gmux: Sphinxify docs

2016-07-04 Thread Andy Shevchenko

On Mon, Jul 4, 2016 at 1:40 PM, Lukas Wunner  wrote:
> Convert asciidoc-formatted docs to rst in accordance with Jonathan's and
> Jani's effort to use sphinx for kernel-doc rendering in 4.8.

Darren, I'm fine with this one. FWIW:
Reviewed-by: Andy Shevchenko 

>
> Cc: Jonathan Corbet 
> Cc: Jani Nikula 
> Signed-off-by: Lukas Wunner 
> ---
>  drivers/platform/x86/apple-gmux.c | 55 
> +--
>  1 file changed, 29 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/platform/x86/apple-gmux.c 
> b/drivers/platform/x86/apple-gmux.c
> index 4034d2d..a66be13 100644
> --- a/drivers/platform/x86/apple-gmux.c
> +++ b/drivers/platform/x86/apple-gmux.c
> @@ -31,19 +31,21 @@
>  /**
>   * DOC: Overview
>   *
> - * :1:  http://www.latticesemi.com/en/Products/FPGAandCPLD/LatticeXP2.aspx
> - * :2:  http://www.renesas.com/products/mpumcu/h8s/h8s2100/h8s2113/index.jsp
> - *
>   * gmux is a microcontroller built into the MacBook Pro to support dual GPUs:
> - * A {1}[Lattice XP2] on pre-retinas, a {2}[Renesas R4F2113] on retinas.
> + * A `Lattice XP2`_ on pre-retinas, a `Renesas R4F2113`_ on retinas.
>   *
>   * (The MacPro6,1 2013 also has a gmux, however it is unclear why since it 
> has
>   * dual GPUs but no built-in display.)
>   *
>   * gmux is connected to the LPC bus of the southbridge. Its I/O ports are
>   * accessed differently depending on the microcontroller: Driver functions
> - * to access a pre-retina gmux are infixed `_pio_`, those for a retina gmux
> - * are infixed `_index_`.
> + * to access a pre-retina gmux are infixed ``_pio_``, those for a retina gmux
> + * are infixed ``_index_``.
> + *
> + * .. _Lattice XP2:
> + * http://www.latticesemi.com/en/Products/FPGAandCPLD/LatticeXP2.aspx
> + * .. _Renesas R4F2113:
> + * http://www.renesas.com/products/mpumcu/h8s/h8s2100/h8s2113/index.jsp
>   */
>
>  struct apple_gmux_data {
> @@ -272,15 +274,15 @@ static bool gmux_is_indexed(struct apple_gmux_data 
> *gmux_data)
>  /**
>   * DOC: Backlight control
>   *
> - * :3:  http://www.ti.com/lit/ds/symlink/lp8543.pdf
> - * :4:  http://www.ti.com/lit/ds/symlink/lp8545.pdf
> - *
>   * On single GPU MacBooks, the PWM signal for the backlight is generated by
>   * the GPU. On dual GPU MacBook Pros by contrast, either GPU may be suspended
>   * to conserve energy. Hence the PWM signal needs to be generated by a 
> separate
>   * backlight driver which is controlled by gmux. The earliest generation
> - * MBP5 2008/09 uses a {3}[TI LP8543] backlight driver. All newer models
> - * use a {4}[TI LP8545].
> + * MBP5 2008/09 uses a `TI LP8543`_ backlight driver. All newer models
> + * use a `TI LP8545`_.
> + *
> + * .. _TI LP8543: http://www.ti.com/lit/ds/symlink/lp8543.pdf
> + * .. _TI LP8545: http://www.ti.com/lit/ds/symlink/lp8545.pdf
>   */
>
>  static int gmux_get_brightness(struct backlight_device *bd)
> @@ -312,28 +314,20 @@ static const struct backlight_ops gmux_bl_ops = {
>  /**
>   * DOC: Graphics mux
>   *
> - * :5:  http://pimg-fpiw.uspto.gov/fdd/07/870/086/0.pdf
> - * :6:  http://www.nxp.com/documents/data_sheet/CBTL06141.pdf
> - * :7:  http://www.ti.com/lit/ds/symlink/hd3ss212.pdf
> - * :8:  https://www.pericom.com/assets/Datasheets/PI3VDP12412.pdf
> - * :9:  http://www.ti.com/lit/ds/symlink/sn74lv4066a.pdf
> - * :10: 
> http://pdf.datasheetarchive.com/indexerfiles/Datasheets-SW16/DSASW00308511.pdf
> - * :11: http://www.ti.com/lit/ds/symlink/ts3ds10224.pdf
> - *
>   * On pre-retinas, the LVDS outputs of both GPUs feed into gmux which muxes
>   * either of them to the panel. One of the tricks gmux has up its sleeve is
>   * to lengthen the blanking interval of its output during a switch to
>   * synchronize it with the GPU switched to. This allows for a flicker-free
> - * switch that is imperceptible by the user ({5}[US 8,687,007 B2]).
> + * switch that is imperceptible by the user (`US 8,687,007 B2`_).
>   *
>   * On retinas, muxing is no longer done by gmux itself, but by a separate
>   * chip which is controlled by gmux. The chip is triple sourced, it is
> - * either an {6}[NXP CBTL06142], {7}[TI HD3SS212] or {8}[Pericom 
> PI3VDP12412].
> + * either an `NXP CBTL06142`_, `TI HD3SS212`_ or `Pericom PI3VDP12412`_.
>   * The panel is driven with eDP instead of LVDS since the pixel clock
>   * required for retina resolution exceeds LVDS' limits.
>   *
>   * Pre-retinas are able to switch the panel's DDC pins separately.
> - * This is handled by a {9}[TI SN74LV4066A] which is controlled by gmux.
> + * This is handled by a `TI SN74LV4066A`_ which is controlled by gmux.
>   * The inactive GPU can thus probe the panel's EDID without switching over
>   * the entire panel. Retinas lack this functionality as the chips used for
>   * eDP muxing are incapable of switching the AUX channel separately (see
> @@ -344,15 +338,15 @@ static const struct backlight_ops gmux_bl_ops = {
>   *
>   * The external DP port is only fully switchable on the first two unibody
>   * MacBook Pro

[PATCH 7/7] drm/vc4: Fix a "the the" typo in a comment.

2016-07-04 Thread Eric Anholt

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_validate_shaders.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_validate_shaders.c 
b/drivers/gpu/drm/vc4/vc4_validate_shaders.c
index 302ce68e24cd..d126145c60ca 100644
--- a/drivers/gpu/drm/vc4/vc4_validate_shaders.c
+++ b/drivers/gpu/drm/vc4/vc4_validate_shaders.c
@@ -194,7 +194,7 @@ check_tmu_write(struct vc4_validated_shader_info 
*validated_shader,
return false;
}

-   /* We assert that the the clamped address is the first
+   /* We assert that the clamped address is the first
 * argument, and the UBO base address is the second argument.
 * This is arbitrary, but simpler than supporting flipping the
 * two either way.
-- 
2.8.1

[PATCH 6/7] drm/vc4: Fix definition of QPU_R_MS_REV_FLAGS

2016-07-04 Thread Eric Anholt

We don't use it in shader validation currently, so it had no effect,
but best to fix it anyway in case we do some day.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_qpu_defines.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/vc4/vc4_qpu_defines.h 
b/drivers/gpu/drm/vc4/vc4_qpu_defines.h
index 6d0745720a17..f4e795a0d3f6 100644
--- a/drivers/gpu/drm/vc4/vc4_qpu_defines.h
+++ b/drivers/gpu/drm/vc4/vc4_qpu_defines.h
@@ -70,7 +70,7 @@ enum qpu_raddr {
QPU_R_ELEM_QPU = 38,
QPU_R_NOP,
QPU_R_XY_PIXEL_COORD = 41,
-   QPU_R_MS_REV_FLAGS = 41,
+   QPU_R_MS_REV_FLAGS = 42,
QPU_R_VPM = 48,
QPU_R_VPM_LD_BUSY,
QPU_R_VPM_LD_WAIT,
-- 
2.8.1

[PATCH 5/7] drm/vc4: Add a getparam to signal support for branches.

2016-07-04 Thread Eric Anholt

Userspace needs to know if it can create shaders that do branching.
Otherwise, for backwards compatibility with old kernels it needs to
lower if statements to conditional assignments.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 3 +++
 include/uapi/drm/vc4_drm.h| 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 8a2f2b5a8f32..fd6e34600d50 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -59,6 +59,9 @@ static int vc4_get_param_ioctl(struct drm_device *dev, void 
*data,
case DRM_VC4_PARAM_V3D_IDENT2:
args->value = V3D_READ(V3D_IDENT2);
break;
+   case DRM_VC4_PARAM_SUPPORTS_BRANCHES:
+   args->value = true;
+   break;
default:
DRM_DEBUG("Unknown parameter %d\n", args->param);
return -EINVAL;
diff --git a/include/uapi/drm/vc4_drm.h b/include/uapi/drm/vc4_drm.h
index c4427d31b346..86cc0cd0d125 100644
--- a/include/uapi/drm/vc4_drm.h
+++ b/include/uapi/drm/vc4_drm.h
@@ -285,6 +285,7 @@ struct drm_vc4_get_hang_state {
 #define DRM_VC4_PARAM_V3D_IDENT0   0
 #define DRM_VC4_PARAM_V3D_IDENT1   1
 #define DRM_VC4_PARAM_V3D_IDENT2   2
+#define DRM_VC4_PARAM_SUPPORTS_BRANCHES3

 struct drm_vc4_get_param {
__u32 param;
-- 
2.8.1

[PATCH 4/7] drm/vc4: Add support for branching in shader validation.

2016-07-04 Thread Eric Anholt

We're already checking that branch instructions are between the start
of the shader and the proper PROG_END sequence.  The other thing we
need to make branching safe is to verify that the shader doesn't read
past the end of the uniforms stream.

To do that, we require that at any basic block reading uniforms have
the following instructions:

load_imm temp, 
add unif_addr, temp, unif

The instructions are generated by userspace, and the kernel verifies
that the load_imm is of the expected offset, and that the add adds it
to a uniform.  We track which uniform in the stream that is, and at
draw call time fix up the uniform stream to have the address of the
start of the shader's uniforms at that location.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_drv.h  |   3 +
 drivers/gpu/drm/vc4/vc4_qpu_defines.h  |   3 +
 drivers/gpu/drm/vc4/vc4_validate.c |  13 +-
 drivers/gpu/drm/vc4/vc4_validate_shaders.c | 281 +++--
 4 files changed, 283 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index 37cac59401d7..efc61a09162e 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -355,6 +355,9 @@ struct vc4_validated_shader_info {
uint32_t uniforms_src_size;
uint32_t num_texture_samples;
struct vc4_texture_sample_info *texture_samples;
+
+   uint32_t num_uniform_addr_offsets;
+   uint32_t *uniform_addr_offsets;
 };

 /**
diff --git a/drivers/gpu/drm/vc4/vc4_qpu_defines.h 
b/drivers/gpu/drm/vc4/vc4_qpu_defines.h
index 82ef0e525d55..6d0745720a17 100644
--- a/drivers/gpu/drm/vc4/vc4_qpu_defines.h
+++ b/drivers/gpu/drm/vc4/vc4_qpu_defines.h
@@ -270,6 +270,9 @@ enum qpu_unpack_r4 {
 #define QPU_OP_ADD_SHIFT24
 #define QPU_OP_ADD_MASK QPU_MASK(28, 24)

+#define QPU_LOAD_IMM_SHIFT  0
+#define QPU_LOAD_IMM_MASK   QPU_MASK(31, 0)
+
 #define QPU_BRANCH_TARGET_SHIFT 0
 #define QPU_BRANCH_TARGET_MASK  QPU_MASK(31, 0)

diff --git a/drivers/gpu/drm/vc4/vc4_validate.c 
b/drivers/gpu/drm/vc4/vc4_validate.c
index 24c2c746e8f3..9ce1d0adf882 100644
--- a/drivers/gpu/drm/vc4/vc4_validate.c
+++ b/drivers/gpu/drm/vc4/vc4_validate.c
@@ -802,7 +802,7 @@ validate_gl_shader_rec(struct drm_device *dev,
uint32_t src_offset = *(uint32_t *)(pkt_u + o);
uint32_t *texture_handles_u;
void *uniform_data_u;
-   uint32_t tex;
+   uint32_t tex, uni;

*(uint32_t *)(pkt_v + o) = bo[i]->paddr + src_offset;

@@ -840,6 +840,17 @@ validate_gl_shader_rec(struct drm_device *dev,
}
}

+   /* Fill in the uniform slots that need this shader's
+* start-of-uniforms address (used for resetting the uniform
+* stream in the presence of control flow).
+*/
+   for (uni = 0;
+uni < validated_shader->num_uniform_addr_offsets;
+uni++) {
+   uint32_t o = 
validated_shader->uniform_addr_offsets[uni];
+   ((uint32_t *)exec->uniforms_v)[o] = exec->uniforms_p;
+   }
+
*(uint32_t *)(pkt_v + o + 4) = exec->uniforms_p;

exec->uniforms_u += validated_shader->uniforms_src_size;
diff --git a/drivers/gpu/drm/vc4/vc4_validate_shaders.c 
b/drivers/gpu/drm/vc4/vc4_validate_shaders.c
index bcf3c31b2765..302ce68e24cd 100644
--- a/drivers/gpu/drm/vc4/vc4_validate_shaders.c
+++ b/drivers/gpu/drm/vc4/vc4_validate_shaders.c
@@ -39,6 +39,8 @@
 #include "vc4_drv.h"
 #include "vc4_qpu_defines.h"

+#define LIVE_REG_COUNT (32 + 32 + 4)
+
 struct vc4_shader_validation_state {
/* Current IP being validated. */
uint32_t ip;
@@ -57,8 +59,9 @@ struct vc4_shader_validation_state {
 *
 * This is used for the validation of direct address memory reads.
 */
-   uint32_t live_min_clamp_offsets[32 + 32 + 4];
-   bool live_max_clamp_regs[32 + 32 + 4];
+   uint32_t live_min_clamp_offsets[LIVE_REG_COUNT];
+   bool live_max_clamp_regs[LIVE_REG_COUNT];
+   uint32_t live_immediates[LIVE_REG_COUNT];

/* Bitfield of which IPs are used as branch targets.
 *
@@ -66,6 +69,20 @@ struct vc4_shader_validation_state {
 * points and clearing the texturing/clamping state.
 */
unsigned long *branch_targets;
+
+   /* Set when entering a basic block, and cleared when the uniform
+* address update is found.  This is used to make sure that we don't
+* read uniforms when the address is undefined.
+*/
+   bool needs_uniform_address_update;
+
+   /* Set when we find a backwards branch.  If the branch is backwards,
+* the taraget is probably doing an address reset to read uniforms,
+* and so we need to be sure that a uniforms

[PATCH 3/7] drm/vc4: Add a bitmap of branch targets during shader validation.

2016-07-04 Thread Eric Anholt

This isn't used yet, it's just a first step toward loop validation.
During the main parsing of instructions, we need to know when we hit a
new basic block so that we can reset validated state.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_qpu_defines.h  |  12 +++
 drivers/gpu/drm/vc4/vc4_validate_shaders.c | 114 -
 2 files changed, 124 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_qpu_defines.h 
b/drivers/gpu/drm/vc4/vc4_qpu_defines.h
index d5c2f3c85ebb..82ef0e525d55 100644
--- a/drivers/gpu/drm/vc4/vc4_qpu_defines.h
+++ b/drivers/gpu/drm/vc4/vc4_qpu_defines.h
@@ -230,6 +230,15 @@ enum qpu_unpack_r4 {
 #define QPU_COND_MUL_SHIFT  46
 #define QPU_COND_MUL_MASK   QPU_MASK(48, 46)

+#define QPU_BRANCH_COND_SHIFT   52
+#define QPU_BRANCH_COND_MASKQPU_MASK(55, 52)
+
+#define QPU_BRANCH_REL  ((uint64_t)1 << 51)
+#define QPU_BRANCH_REG  ((uint64_t)1 << 50)
+
+#define QPU_BRANCH_RADDR_A_SHIFT45
+#define QPU_BRANCH_RADDR_A_MASK QPU_MASK(49, 45)
+
 #define QPU_SF  ((uint64_t)1 << 45)

 #define QPU_WADDR_ADD_SHIFT 38
@@ -261,4 +270,7 @@ enum qpu_unpack_r4 {
 #define QPU_OP_ADD_SHIFT24
 #define QPU_OP_ADD_MASK QPU_MASK(28, 24)

+#define QPU_BRANCH_TARGET_SHIFT 0
+#define QPU_BRANCH_TARGET_MASK  QPU_MASK(31, 0)
+
 #endif /* VC4_QPU_DEFINES_H */
diff --git a/drivers/gpu/drm/vc4/vc4_validate_shaders.c 
b/drivers/gpu/drm/vc4/vc4_validate_shaders.c
index 771d904653f2..bcf3c31b2765 100644
--- a/drivers/gpu/drm/vc4/vc4_validate_shaders.c
+++ b/drivers/gpu/drm/vc4/vc4_validate_shaders.c
@@ -59,6 +59,13 @@ struct vc4_shader_validation_state {
 */
uint32_t live_min_clamp_offsets[32 + 32 + 4];
bool live_max_clamp_regs[32 + 32 + 4];
+
+   /* Bitfield of which IPs are used as branch targets.
+*
+* Used for validation that the uniform stream is updated at the right
+* points and clearing the texturing/clamping state.
+*/
+   unsigned long *branch_targets;
 };

 static uint32_t
@@ -418,13 +425,104 @@ check_instruction_reads(uint64_t inst,
return true;
 }

+/* Make sure that all branches are absolute and point within the shader, and
+ * note their targets for later.
+ */
+static bool
+vc4_validate_branches(struct vc4_shader_validation_state *validation_state)
+{
+   uint32_t max_branch_target = 0;
+   bool found_shader_end = false;
+   int ip;
+   int shader_end_ip = 0;
+   int last_branch = -2;
+
+   for (ip = 0; ip < validation_state->max_ip; ip++) {
+   uint64_t inst = validation_state->shader[ip];
+   int32_t branch_imm = QPU_GET_FIELD(inst, QPU_BRANCH_TARGET);
+   uint32_t sig = QPU_GET_FIELD(inst, QPU_SIG);
+   uint32_t after_delay_ip = ip + 4;
+   uint32_t branch_target_ip;
+
+   if (sig == QPU_SIG_PROG_END) {
+   shader_end_ip = ip;
+   found_shader_end = true;
+   continue;
+   }
+
+   if (sig != QPU_SIG_BRANCH)
+   continue;
+
+   if (ip - last_branch < 4) {
+   DRM_ERROR("Branch at %d during delay slots\n", ip);
+   return false;
+   }
+   last_branch = ip;
+
+   if (inst & QPU_BRANCH_REG) {
+   DRM_ERROR("branching from register relative "
+ "not supported\n");
+   return false;
+   }
+
+   if (!(inst & QPU_BRANCH_REL)) {
+   DRM_ERROR("relative branching required\n");
+   return false;
+   }
+
+   /* The actual branch target is the instruction after the delay
+* slots, plus whatever byte offset is in the low 32 bits of
+* the instruction.  Make sure we're not branching beyond the
+* end of the shader object.
+*/
+   if (branch_imm % sizeof(inst) != 0) {
+   DRM_ERROR("branch target not aligned\n");
+   return false;
+   };
+
+   branch_target_ip = after_delay_ip + (branch_imm >> 3);
+   if (branch_target_ip >= validation_state->max_ip) {
+   DRM_ERROR("Branch at %d outside of shader (ip %d/%d)\n",
+ ip, branch_target_ip,
+ validation_state->max_ip);
+   return false;
+   }
+   set_bit(branch_target_ip, validation_state->branch_targets);
+
+   /* Make sure that the non-branching path is also not outside
+* the shader.
+*/
+   if (after_delay_ip

[PATCH 2/7] drm/vc4: Move validation's current/max ip into the validation struct.

2016-07-04 Thread Eric Anholt

Reduces the argument count for some of the functions, and will be used
more with the upcoming looping support.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_validate_shaders.c | 54 +-
 1 file changed, 30 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_validate_shaders.c 
b/drivers/gpu/drm/vc4/vc4_validate_shaders.c
index f67124b4c534..771d904653f2 100644
--- a/drivers/gpu/drm/vc4/vc4_validate_shaders.c
+++ b/drivers/gpu/drm/vc4/vc4_validate_shaders.c
@@ -40,6 +40,14 @@
 #include "vc4_qpu_defines.h"

 struct vc4_shader_validation_state {
+   /* Current IP being validated. */
+   uint32_t ip;
+
+   /* IP at the end of the BO, do not read shader[max_ip] */
+   uint32_t max_ip;
+
+   uint64_t *shader;
+
struct vc4_texture_sample_info tmu_setup[2];
int tmu_write_count[2];

@@ -129,11 +137,11 @@ record_texture_sample(struct vc4_validated_shader_info 
*validated_shader,
 }

 static bool
-check_tmu_write(uint64_t inst,
-   struct vc4_validated_shader_info *validated_shader,
+check_tmu_write(struct vc4_validated_shader_info *validated_shader,
struct vc4_shader_validation_state *validation_state,
bool is_mul)
 {
+   uint64_t inst = validation_state->shader[validation_state->ip];
uint32_t waddr = (is_mul ?
  QPU_GET_FIELD(inst, QPU_WADDR_MUL) :
  QPU_GET_FIELD(inst, QPU_WADDR_ADD));
@@ -228,11 +236,11 @@ check_tmu_write(uint64_t inst,
 }

 static bool
-check_reg_write(uint64_t inst,
-   struct vc4_validated_shader_info *validated_shader,
+check_reg_write(struct vc4_validated_shader_info *validated_shader,
struct vc4_shader_validation_state *validation_state,
bool is_mul)
 {
+   uint64_t inst = validation_state->shader[validation_state->ip];
uint32_t waddr = (is_mul ?
  QPU_GET_FIELD(inst, QPU_WADDR_MUL) :
  QPU_GET_FIELD(inst, QPU_WADDR_ADD));
@@ -261,7 +269,7 @@ check_reg_write(uint64_t inst,
case QPU_W_TMU1_T:
case QPU_W_TMU1_R:
case QPU_W_TMU1_B:
-   return check_tmu_write(inst, validated_shader, validation_state,
+   return check_tmu_write(validated_shader, validation_state,
   is_mul);

case QPU_W_HOST_INT:
@@ -294,10 +302,10 @@ check_reg_write(uint64_t inst,
 }

 static void
-track_live_clamps(uint64_t inst,
- struct vc4_validated_shader_info *validated_shader,
+track_live_clamps(struct vc4_validated_shader_info *validated_shader,
  struct vc4_shader_validation_state *validation_state)
 {
+   uint64_t inst = validation_state->shader[validation_state->ip];
uint32_t op_add = QPU_GET_FIELD(inst, QPU_OP_ADD);
uint32_t waddr_add = QPU_GET_FIELD(inst, QPU_WADDR_ADD);
uint32_t waddr_mul = QPU_GET_FIELD(inst, QPU_WADDR_MUL);
@@ -369,10 +377,10 @@ track_live_clamps(uint64_t inst,
 }

 static bool
-check_instruction_writes(uint64_t inst,
-struct vc4_validated_shader_info *validated_shader,
+check_instruction_writes(struct vc4_validated_shader_info *validated_shader,
 struct vc4_shader_validation_state *validation_state)
 {
+   uint64_t inst = validation_state->shader[validation_state->ip];
uint32_t waddr_add = QPU_GET_FIELD(inst, QPU_WADDR_ADD);
uint32_t waddr_mul = QPU_GET_FIELD(inst, QPU_WADDR_MUL);
bool ok;
@@ -382,12 +390,10 @@ check_instruction_writes(uint64_t inst,
return false;
}

-   ok = (check_reg_write(inst, validated_shader, validation_state,
- false) &&
- check_reg_write(inst, validated_shader, validation_state,
- true));
+   ok = (check_reg_write(validated_shader, validation_state, false) &&
+ check_reg_write(validated_shader, validation_state, true));

-   track_live_clamps(inst, validated_shader, validation_state);
+   track_live_clamps(validated_shader, validation_state);

return ok;
 }
@@ -417,30 +423,30 @@ vc4_validate_shader(struct drm_gem_cma_object *shader_obj)
 {
bool found_shader_end = false;
int shader_end_ip = 0;
-   uint32_t ip, max_ip;
-   uint64_t *shader;
+   uint32_t ip;
struct vc4_validated_shader_info *validated_shader;
struct vc4_shader_validation_state validation_state;
int i;

memset(_state, 0, sizeof(validation_state));
+   validation_state.shader = shader_obj->vaddr;
+   validation_state.max_ip = shader_obj->base.size / sizeof(uint64_t);

for (i = 0; i < 8; i++)
validation_state.tmu_setup[i / 4].p_offset[i % 4] = ~0;
for (i = 0; i < ARRAY_SIZE(validation_state.live_min_clamp_offsets); 
i++)

[PATCH 1/7] drm/vc4: Add a getparam ioctl for getting the V3D identity regs.

2016-07-04 Thread Eric Anholt

As I extend the driver to support different V3D revisions, userspace
needs to know what version it's targeting.  This is most easily
detected using the V3D identity registers.

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/vc4/vc4_drv.c | 25 +
 include/uapi/drm/vc4_drm.h| 11 +++
 2 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 3446ece21b4a..8a2f2b5a8f32 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -43,6 +43,30 @@ void __iomem *vc4_ioremap_regs(struct platform_device *dev, 
int index)
return map;
 }

+static int vc4_get_param_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file_priv)
+{
+   struct vc4_dev *vc4 = to_vc4_dev(dev);
+   struct drm_vc4_get_param *args = data;
+
+   switch (args->param) {
+   case DRM_VC4_PARAM_V3D_IDENT0:
+   args->value = V3D_READ(V3D_IDENT0);
+   break;
+   case DRM_VC4_PARAM_V3D_IDENT1:
+   args->value = V3D_READ(V3D_IDENT1);
+   break;
+   case DRM_VC4_PARAM_V3D_IDENT2:
+   args->value = V3D_READ(V3D_IDENT2);
+   break;
+   default:
+   DRM_DEBUG("Unknown parameter %d\n", args->param);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 static void vc4_lastclose(struct drm_device *dev)
 {
struct vc4_dev *vc4 = to_vc4_dev(dev);
@@ -74,6 +98,7 @@ static const struct drm_ioctl_desc vc4_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(VC4_CREATE_SHADER_BO, vc4_create_shader_bo_ioctl, 0),
DRM_IOCTL_DEF_DRV(VC4_GET_HANG_STATE, vc4_get_hang_state_ioctl,
  DRM_ROOT_ONLY),
+   DRM_IOCTL_DEF_DRV(VC4_GET_PARAM, vc4_get_param_ioctl, DRM_RENDER_ALLOW),
 };

 static struct drm_driver vc4_drm_driver = {
diff --git a/include/uapi/drm/vc4_drm.h b/include/uapi/drm/vc4_drm.h
index af12e8a184c8..c4427d31b346 100644
--- a/include/uapi/drm/vc4_drm.h
+++ b/include/uapi/drm/vc4_drm.h
@@ -37,6 +37,7 @@ extern "C" {
 #define DRM_VC4_MMAP_BO   0x04
 #define DRM_VC4_CREATE_SHADER_BO  0x05
 #define DRM_VC4_GET_HANG_STATE0x06
+#define DRM_VC4_GET_PARAM 0x07

 #define DRM_IOCTL_VC4_SUBMIT_CL   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_SUBMIT_CL, struct drm_vc4_submit_cl)
 #define DRM_IOCTL_VC4_WAIT_SEQNO  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_WAIT_SEQNO, struct drm_vc4_wait_seqno)
@@ -45,6 +46,7 @@ extern "C" {
 #define DRM_IOCTL_VC4_MMAP_BO DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_MMAP_BO, struct drm_vc4_mmap_bo)
 #define DRM_IOCTL_VC4_CREATE_SHADER_BODRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_CREATE_SHADER_BO, struct drm_vc4_create_shader_bo)
 #define DRM_IOCTL_VC4_GET_HANG_STATE  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_GET_HANG_STATE, struct drm_vc4_get_hang_state)
+#define DRM_IOCTL_VC4_GET_PARAM   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_VC4_GET_PARAM, struct drm_vc4_get_param)

 struct drm_vc4_submit_rcl_surface {
__u32 hindex; /* Handle index, or ~0 if not present. */
@@ -280,6 +282,15 @@ struct drm_vc4_get_hang_state {
__u32 pad[16];
 };

+#define DRM_VC4_PARAM_V3D_IDENT0   0
+#define DRM_VC4_PARAM_V3D_IDENT1   1
+#define DRM_VC4_PARAM_V3D_IDENT2   2
+
+struct drm_vc4_get_param {
+   __u32 param;
+   __u32 value;
+};
+
 #if defined(__cplusplus)
 }
 #endif
-- 
2.8.1

[PATCH 0/7] drm/vc4: loops and getparam support.

2016-07-04 Thread Eric Anholt

At long last, I've got loops passing the piglit tests.  (4 tests fail
due to register allocation, and one fails for reasons I haven't
debugged yet, but that's still a lot of new tests passing).

The userspace side of loops can be found at
http://github.com/anholt/mesa/tree/vc4-loops and I'll try to get an
identity getparam patch sent out tomorrow.

Eric Anholt (7):
  drm/vc4: Add a getparam ioctl for getting the V3D identity regs.
  drm/vc4: Move validation's current/max ip into the validation struct.
  drm/vc4: Add a bitmap of branch targets during shader validation.
  drm/vc4: Add support for branching in shader validation.
  drm/vc4: Add a getparam to signal support for branches.
  drm/vc4: Fix definition of QPU_R_MS_REV_FLAGS
  drm/vc4: Fix a "the the" typo in a comment.

 drivers/gpu/drm/vc4/vc4_drv.c  |  28 ++
 drivers/gpu/drm/vc4/vc4_drv.h  |   3 +
 drivers/gpu/drm/vc4/vc4_qpu_defines.h  |  17 +-
 drivers/gpu/drm/vc4/vc4_validate.c |  13 +-
 drivers/gpu/drm/vc4/vc4_validate_shaders.c | 449 ++---
 include/uapi/drm/vc4_drm.h |  12 +
 6 files changed, 478 insertions(+), 44 deletions(-)

-- 
2.8.1

[Bug 80419] XCOM: Enemy Unknown Causes lockup

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #138 from Daniel Exner <dex+fdobugzilla at dragonslave.de> ---
Created attachment 124896
  --> https://bugs.freedesktop.org/attachment.cgi?id=124896=edit
crash journal kernel 4.7.0-rc6

Seems you where right: crashed again today.

I managed to log some of it, perhaps its of any use.

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

[PATCH 1/1] gpu: drm: omapdrm: dss-of: add missing of_node_put after calling of_parse_phandle

2016-07-04 Thread Peter Chen

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
 drivers/gpu/drm/omapdrm/dss/dss-of.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dss-of.c 
b/drivers/gpu/drm/omapdrm/dss/dss-of.c
index bf407b6..1ee6e5e 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss-of.c
+++ b/drivers/gpu/drm/omapdrm/dss/dss-of.c
@@ -126,15 +126,16 @@ u32 dss_of_port_get_port_number(struct device_node *port)

 static struct device_node *omapdss_of_get_remote_port(const struct device_node 
*node)
 {
-   struct device_node *np;
+   struct device_node *np, *np_parent;

np = of_parse_phandle(node, "remote-endpoint", 0);
if (!np)
return NULL;

-   np = of_get_next_parent(np);
+   np_parent = of_get_next_parent(np);
+   of_node_put(np);

-   return np;
+   return np_parent;
 }

 struct device_node *
-- 
1.9.1

[PATCH 00/31] Move LRU page reclaim from zones to nodes v8

2016-07-04 Thread Minchan Kim

On Mon, Jul 04, 2016 at 05:34:05AM +0100, Mel Gorman wrote:
> On Mon, Jul 04, 2016 at 10:37:03AM +0900, Minchan Kim wrote:
> > > The reason we have zone-based reclaim is that we used to have
> > > large highmem zones in common configurations and it was necessary
> > > to quickly find ZONE_NORMAL pages for reclaim. Today, this is much
> > > less of a concern as machines with lots of memory will (or should) use
> > > 64-bit kernels. Combinations of 32-bit hardware and 64-bit hardware are
> > > rare. Machines that do use highmem should have relatively low 
> > > highmem:lowmem
> > > ratios than we worried about in the past.
> > 
> > Hello Mel,
> > 
> > I agree the direction absolutely. However, I have a concern on highmem
> > system as you already mentioned.
> > 
> > Embedded products still use 2 ~ 3 ratio (highmem:lowmem).
> > In such system, LRU churning by skipping other zone pages frequently
> > might be significant for the performance.
> > 
> > How big ratio between highmem:lowmem do you think a problem?
> > 
> 
> That's a "how long is a piece of string" type question.  The ratio does
> not matter as much as whether the workload is both under memory pressure
> and requires large amounts of lowmem pages. Even on systems with very high
> ratios, it may not be a problem if HIGHPTE is enabled.

As well page table, pgd/kernelstack/zbud/slab and so on, every kernel
allocations wanted to mask __GFP_HIGHMEM off would be a problem in
32bit system.

It also depends on that how many drivers needed lowmem only we have
in the system.

I don't know how many such driver in the world. When I simply do grep,
I found several cases which mask __GFP_HIGHMEM off and among them,
I guess DRM might be a popular for us. However, it might be really rare
usecase among various i915 usecases.

> 
> > > 
> > > Conceptually, moving to node LRUs should be easier to understand. The
> > > page allocator plays fewer tricks to game reclaim and reclaim behaves
> > > similarly on all nodes. 
> > > 
> > > The series has been tested on a 16 core UMA machine and a 2-socket 48
> > > core NUMA machine. The UMA results are presented in most cases as the NUMA
> > > machine behaved similarly.
> > 
> > I guess you would already test below with various highmem system(e.g.,
> > 2:1, 3:1, 4:1 and so on). If you have, could you mind sharing it?
> > 
> 
> I haven't that data, the baseline distribution used doesn't even have
> 32-bit support. Even if it was, the results may not be that interesting.
> The workloads used were not necessarily going to trigger lowmem pressure
> as HIGHPTE was set on the 32-bit configs.

That means we didn't test this on 32-bit with highmem.

I'm not sure it's really too rare case to spend a time for testing.
In fact, I really want to test all series to our production system
which is 32bit and highmem but as we know well, most of embedded
system kernel is rather old so backporting needs lots of time and
care. However, if we miss testing in those system at the moment,
we will be suprised after 1~2 years.

I don't know what kinds of benchmark can we can check it so I cannot
insist on it but you might know it.

Okay, do you have any idea to fix it if we see such regression report
in 32-bit system in future?

[PATCH 1/1] gpu: drm: omapdrm: connector-dvi: add missing of_node_put after calling of_parse_phandle

2016-07-04 Thread Peter Chen

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
 drivers/gpu/drm/omapdrm/displays/connector-dvi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c 
b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
index 747f26a..8c15bdb 100644
--- a/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
+++ b/drivers/gpu/drm/omapdrm/displays/connector-dvi.c
@@ -255,6 +255,7 @@ static int dvic_probe_of(struct platform_device *pdev)
adapter_node = of_parse_phandle(node, "ddc-i2c-bus", 0);
if (adapter_node) {
adapter = of_get_i2c_adapter_by_node(adapter_node);
+   of_node_put(adapter_node);
if (adapter == NULL) {
dev_err(>dev, "failed to parse ddc-i2c-bus\n");
omap_dss_put_device(ddata->in);
-- 
1.9.1

[PATCH 3/3] drm/vmwgfx: Delay pinning fbdev framebuffer until after mode set

2016-07-04 Thread Emil Velikov

Hi Sinclair,

On 1 July 2016 at 19:24,   wrote:
> From: Sinclair Yeh 
>
> For the Screen Object display unit, we need to reserve a
> guest-invisible region equal to the size of the framebuffer for
> the host.  This region can only be reserved in VRAM, whereas
> the guest-visible framebuffer can be reserved in either VRAM or
> GMR.
>
> As such priority should be given to the guest-invisible
> region otherwise in a limited VRAM situation, we can fail to
> allocate this region.
>
> This patch makes it so that vmw_sou_backing_alloc() is called
> before the framebuffer is pinned.
>
> Signed-off-by: Sinclair Yeh 
> Reviewed-by: Thomas Hellstrom 
> Cc: 
> ---
> This is the last patch of a 3-patch series to fix console black
> screen issue on Ubuntu 16.04 server
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 47 
> --
>  1 file changed, 25 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> index 679a4cb..66eaa30 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> @@ -517,28 +517,6 @@ static int vmw_fb_kms_framebuffer(struct fb_info *info)
>
> par->set_fb = >base;
>
> -   if (!par->bo_ptr) {
> -   /*
> -* Pin before mapping. Since we don't know in what placement
> -* to pin, call into KMS to do it for us.
> -*/
> -   ret = vfb->pin(vfb);
> -   if (ret) {
> -   DRM_ERROR("Could not pin the fbdev framebuffer.\n");
> -   return ret;
> -   }
> -
> -   ret = ttm_bo_kmap(>vmw_bo->base, 0,
> - par->vmw_bo->base.num_pages, >map);
> -   if (ret) {
> -   vfb->unpin(vfb);
> -   DRM_ERROR("Could not map the fbdev framebuffer.\n");
> -   return ret;
> -   }
> -
> -   par->bo_ptr = ttm_kmap_obj_virtual(>map, 
> >bo_iowrite);
> -   }
> -
> return 0;
>  }
>
> @@ -601,6 +579,31 @@ static int vmw_fb_set_par(struct fb_info *info)
> if (ret)
> goto out_unlock;
>
> +   if (!par->bo_ptr) {
> +   struct vmw_framebuffer *vfb = vmw_framebuffer_to_vfb(set.fb);
> +
> +   /*
> +* Pin before mapping. Since we don't know in what placement
> +* to pin, call into KMS to do it for us.
> +*/
> +   ret = vfb->pin(vfb);
> +   if (ret) {
> +   DRM_ERROR("Could not pin the fbdev framebuffer.\n");
> +   return ret;
> +   }
> +
> +   ret = ttm_bo_kmap(>vmw_bo->base, 0,
> + par->vmw_bo->base.num_pages, >map);
> +   if (ret) {
> +   vfb->unpin(vfb);
> +   DRM_ERROR("Could not map the fbdev framebuffer.\n");
> +   return ret;
> +   }
> +
> +   par->bo_ptr = ttm_kmap_obj_virtual(>map, 
> >bo_iowrite);
> +   }
> +
> +
Seems like you forgot to update the error paths. Thankfully we
shouldn't be reaching those too often, if at all.

-Emil

[PATCH v2 1/1] gpu: drm: msm_drv: add missing of_node_put after calling of_parse_phandle

2016-07-04 Thread Peter Chen

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
Changes for v2:
- There are two missings in the code, handle it both in one patch

 drivers/gpu/drm/msm/msm_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9c65409..46c6037 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -284,6 +284,7 @@ static int msm_init_vram(struct drm_device *dev)
if (node) {
struct resource r;
ret = of_address_to_resource(node, 0, );
+   of_node_put(node);
if (ret)
return ret;
size = r.end - r.start;
@@ -819,6 +820,7 @@ static int add_components(struct device *dev, struct 
component_match **matchptr,
break;

component_match_add(dev, matchptr, compare_of, node);
+   of_node_put(node);
}

return 0;
-- 
1.9.1

[PATCH 1/1] gpu: drm: msm_drv: add missing of_node_put after calling of_parse_phandle

2016-07-04 Thread Peter Chen

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
 drivers/gpu/drm/msm/msm_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 9c65409..d9ba6c4 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -284,6 +284,7 @@ static int msm_init_vram(struct drm_device *dev)
if (node) {
struct resource r;
ret = of_address_to_resource(node, 0, );
+   of_node_put(node);
if (ret)
return ret;
size = r.end - r.start;
-- 
1.9.1

[Bug 96731] [RADEONSI] [LLVM] [bisected] GPU lockups when running Alien: Isolation

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #13 from Arek RuÅniak  ---
Nocolai, thanks for fix. That did the job. The game now looks even better:) 
Really! I'll try revert llvm to old revision and play it again, maybe it's just
my imagination.

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

[Bug 93341] GPU lockups on RadeonHD 7770 (radeonsi driver) when running OpenGL games or after extended periods of time

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

Nicolai HÃ¤hnle  changed:

   What|Removed |Added

 CC||deathsimple at vodafone.de

--- Comment #10 from Nicolai HÃ¤hnle  ---
I've been running the last three in Firefox on a Tonga system that was
simultaneously used for other tests for 45 minutes now, without a hang.

@Christian: It's a long shot, but by the rough shape of GPU lockup reports over
the last few months I have the impression that the radeon module still has a
lockup bug under pressure (especially with multiple apps running
simultaneously, but that might just be X/the compositor) which was fixed in
amdgpu. Any idea what that might have been?

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

[Bug 96678] Awesomenauts cannot launch AMD PITCAIRN

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #7 from Nicolai HÃ¤hnle  ---
Hi Joost, nice to see you here :)

He's indeed running the open-source radeonsi driver. The shader being compiled
is very simple and probably from the glClear() call. Those don't usually crash,
and I can compile the LLVM IR from the log here just fine.

Quentin: Could you please install debug packages of 32-bit LLVM and Mesa so
that we can get a more informative backtrace?

With the debug packages installed, also try running the game from gdb, and
produce a detailed backtrace using `bt full` after the crash.

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

[Bug 96762] [radeonsi,apitrace] Firewatch: nothing rendered in scrollable (text) areas

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #5 from Nicolai HÃ¤hnle  ---
Thanks. I can reproduce the empty "Resolutions" scroll area.

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

[Bug 96794] VM_CONTEXT1_PROTECTION_FAULT_ADDR

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #2 from Nicolai HÃ¤hnle  ---
Yes, the symptoms were the same. Please try the patch there:
http://reviews.llvm.org/D21975

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

[PATCH 1/1] gpn: drm: fsl_tcon: add missing of_node_put after calling of_parse_phandle

2016-07-04 Thread Peter Chen

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using, but current code only
calls it at error path, fix it by adding it at correct code path.

Signed-off-by: Peter Chen 
---
 drivers/gpu/drm/fsl-dcu/fsl_tcon.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_tcon.c 
b/drivers/gpu/drm/fsl-dcu/fsl_tcon.c
index bbe34f1..bca09ea 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_tcon.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_tcon.c
@@ -92,6 +92,7 @@ struct fsl_tcon *fsl_tcon_init(struct device *dev)
goto err_node_put;
}

+   of_node_put(np);
clk_prepare_enable(tcon->ipg_clk);

dev_info(dev, "Using TCON in bypass mode\n");
-- 
1.9.1

[PATCH v3 10/10] drm/imx: atomic phase 3 step 3: Advertise DRIVER_ATOMIC

2016-07-04 Thread Liu Ying

With all the beforehand phases and steps done, we can adverstise DRIVER_ATOMIC.

Signed-off-by: Liu Ying 
---
v2->v3:
* None.

v1->v2:
* None.

 drivers/gpu/drm/imx/imx-drm-core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index f14ad2b..9f7dafc 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -428,7 +428,8 @@ static const struct drm_ioctl_desc imx_drm_ioctls[] = {
 };

 static struct drm_driver imx_drm_driver = {
-   .driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME,
+   .driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
+ DRIVER_ATOMIC,
.load   = imx_drm_driver_load,
.unload = imx_drm_driver_unload,
.lastclose  = imx_drm_driver_lastclose,
-- 
2.7.4

[PATCH v3 09/10] drm/imx: atomic phase 3 step 2: Legacy callback fixups

2016-07-04 Thread Liu Ying

Now that we can use atomic configurations, all the legacy callbacks
of CRTCs, encoders and connectors can be switched to the atomic version.
For the imx-ldb driver, there is a clock parent setting mismatch bewteen
->enable and ->disable after the switch, so a fixup is added.  For the
imx-tve driver, since the encoder's callback ->dpms is replaced by
->disable, we need to move the setting for the IPU_CLK_EN bit(in register
TVE_COM_CONF_REG) from ->enable/->disable to ->mode_set, otherwise, the
relevant CRTC cannot be disabled correctly with a warning on DC stop timeout.

Signed-off-by: Liu Ying 
---
v2->v3:
* Trivial change due to rebasing.

v1->v2:
* A fixup on the TVE register bit IPU_CLK_EN to avoid a warning on DC
  stop timeout when doing mode setting.

 drivers/gpu/drm/imx/dw_hdmi-imx.c  |  4 ++--
 drivers/gpu/drm/imx/imx-ldb.c  | 16 ++---
 drivers/gpu/drm/imx/imx-tve.c  | 27 +++--
 drivers/gpu/drm/imx/ipuv3-crtc.c   | 44 +-
 drivers/gpu/drm/imx/parallel-display.c | 18 +++---
 5 files changed, 27 insertions(+), 82 deletions(-)

diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index 5f64674..5f1d437 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -117,7 +117,7 @@ static void dw_hdmi_imx_encoder_mode_set(struct drm_encoder 
*encoder,
 {
 }

-static void dw_hdmi_imx_encoder_commit(struct drm_encoder *encoder)
+static void dw_hdmi_imx_encoder_enable(struct drm_encoder *encoder)
 {
struct imx_drm_encoder *imx_encoder = enc_to_imx_enc(encoder);
struct imx_hdmi *hdmi = imx_enc_to_imx_hdmi(imx_encoder);
@@ -130,7 +130,7 @@ static void dw_hdmi_imx_encoder_commit(struct drm_encoder 
*encoder)

 static const struct drm_encoder_helper_funcs dw_hdmi_imx_encoder_helper_funcs 
= {
.mode_set   = dw_hdmi_imx_encoder_mode_set,
-   .commit = dw_hdmi_imx_encoder_commit,
+   .enable = dw_hdmi_imx_encoder_enable,
.disable= dw_hdmi_imx_encoder_disable,
 };

diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index 4a98eaa..9a4190c 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -142,10 +142,6 @@ static struct drm_encoder *imx_ldb_connector_best_encoder(
return _ldb_ch->imx_encoder.encoder;
 }

-static void imx_ldb_encoder_dpms(struct drm_encoder *encoder, int mode)
-{
-}
-
 static void imx_ldb_set_clock(struct imx_ldb *ldb, int mux, int chno,
unsigned long serial_clk, unsigned long di_clk)
 {
@@ -174,7 +170,7 @@ static void imx_ldb_set_clock(struct imx_ldb *ldb, int mux, 
int chno,
chno);
 }

-static void imx_ldb_encoder_commit(struct drm_encoder *encoder)
+static void imx_ldb_encoder_enable(struct drm_encoder *encoder)
 {
struct imx_drm_encoder *imx_encoder = enc_to_imx_enc(encoder);
struct imx_ldb_channel *imx_ldb_ch = imx_enc_to_imx_ldb_ch(imx_encoder);
@@ -185,8 +181,13 @@ static void imx_ldb_encoder_commit(struct drm_encoder 
*encoder)
drm_panel_prepare(imx_ldb_ch->panel);

if (dual) {
+   clk_set_parent(ldb->clk_sel[mux], ldb->clk[0]);
+   clk_set_parent(ldb->clk_sel[mux], ldb->clk[1]);
+
clk_prepare_enable(ldb->clk[0]);
clk_prepare_enable(ldb->clk[1]);
+   } else {
+   clk_set_parent(ldb->clk_sel[mux], ldb->clk[imx_ldb_ch->chno]);
}

if (imx_ldb_ch == >channel[0] || dual) {
@@ -326,7 +327,7 @@ static void imx_ldb_encoder_disable(struct drm_encoder 
*encoder)
 }

 static const struct drm_connector_funcs imx_ldb_connector_funcs = {
-   .dpms = drm_helper_connector_dpms,
+   .dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = imx_ldb_connector_detect,
.destroy = imx_drm_connector_destroy,
@@ -345,9 +346,8 @@ static const struct drm_encoder_funcs imx_ldb_encoder_funcs 
= {
 };

 static const struct drm_encoder_helper_funcs imx_ldb_encoder_helper_funcs = {
-   .dpms = imx_ldb_encoder_dpms,
-   .commit = imx_ldb_encoder_commit,
.mode_set = imx_ldb_encoder_mode_set,
+   .enable = imx_ldb_encoder_enable,
.disable = imx_ldb_encoder_disable,
 };

diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index 82a1edd..cd92aac 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -147,8 +147,7 @@ static void tve_enable(struct imx_tve *tve)
tve->enabled = true;
clk_prepare_enable(tve->clk);
ret = regmap_update_bits(tve->regmap, TVE_COM_CONF_REG,
-TVE_IPU_CLK_EN | TVE_EN,
-TVE_IPU_CLK_EN | TVE_EN);
+TVE_EN, TVE_EN);
}

/* clear interrupt status register */

[PATCH v3 08/10] drm/bridge: dw-hdmi: Remove the legacy drm_connector_funcs structure

2016-07-04 Thread Liu Ying

There is no one using the legacy drm_connector_funcs structure since
the imx-drm has been converted to atomic, so we may remove it.

Signed-off-by: Liu Ying 
---
v2->v3:
* Newly introduced to remove the legacy drm_connector_funcs structure
  step-by-step.

 drivers/gpu/drm/bridge/dw-hdmi.c | 22 +++---
 1 file changed, 3 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index dd5b21a..77ab473 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1495,17 +1495,6 @@ static void dw_hdmi_connector_force(struct drm_connector 
*connector)
 }

 static const struct drm_connector_funcs dw_hdmi_connector_funcs = {
-   .dpms = drm_helper_connector_dpms,
-   .fill_modes = drm_helper_probe_single_connector_modes,
-   .detect = dw_hdmi_connector_detect,
-   .destroy = dw_hdmi_connector_destroy,
-   .force = dw_hdmi_connector_force,
-   .reset = drm_atomic_helper_connector_reset,
-   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
-   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
-};
-
-static const struct drm_connector_funcs dw_hdmi_atomic_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = dw_hdmi_connector_detect,
@@ -1637,14 +1626,9 @@ static int dw_hdmi_register(struct drm_device *drm, 
struct dw_hdmi *hdmi)
drm_connector_helper_add(>connector,
 _hdmi_connector_helper_funcs);

-   if (drm_core_check_feature(drm, DRIVER_ATOMIC))
-   drm_connector_init(drm, >connector,
-  _hdmi_atomic_connector_funcs,
-  DRM_MODE_CONNECTOR_HDMIA);
-   else
-   drm_connector_init(drm, >connector,
-  _hdmi_connector_funcs,
-  DRM_MODE_CONNECTOR_HDMIA);
+   drm_connector_init(drm, >connector,
+  _hdmi_connector_funcs,
+  DRM_MODE_CONNECTOR_HDMIA);

drm_mode_connector_attach_encoder(>connector, encoder);

-- 
2.7.4

[PATCH v3 07/10] drm/imx: atomic phase 3 step 1: Use atomic configuration

2016-07-04 Thread Liu Ying

Replacing drm_crtc_helper_set_config() by drm_atomic_helper_set_config()
and converting the suspend/resume operations to atomic make us be able
to use atomic configurations.  All of these allow us to remove the
crtc_funcs->mode_set callback as it is no longer used.  Also, change
the plane_funcs->update/disable_plane callbacks from the transitional
version to the atomic version.  Furthermore, switching to the pure atomic
version of set_config callback means that we may implement CRTC/plane
atomic checks by using the new CRTC/plane states instead of the legacy
ones and we may remove the private ipu_crtc->enabled state which was left
there for the transitional atomic helpers in phase 1.  Page flip is also
switched to the atomic version.  Last, the legacy function
drm_helper_disable_unused_functions() is removed from ->load in order
not to confuse the atomic driver.

Signed-off-by: Liu Ying 
---
v2->v3:
* Newly introduced, but this contains some important logic in patch 06/10
  , 07/10 and 09/10 of v2 to support nonblock atomic commit(including page
  flip) - the ->set_config and ->update_plane/disable_plane hooks are updated
  to be pure atomic version, and ->atomic_check/atomic_commit hooks of
  drm_mode_config_funcs are wired up.

 drivers/gpu/drm/imx/imx-drm-core.c |  76 +-
 drivers/gpu/drm/imx/ipuv3-crtc.c   | 209 +
 drivers/gpu/drm/imx/ipuv3-plane.c  | 135 +++-
 drivers/gpu/drm/imx/ipuv3-plane.h  |   2 -
 4 files changed, 114 insertions(+), 308 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index f6e44c2..f14ad2b 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -15,10 +15,14 @@
  */
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -41,6 +45,7 @@ struct imx_drm_device {
struct imx_drm_crtc *crtc[MAX_CRTC];
unsigned intpipes;
struct drm_fbdev_cma*fbhelper;
+   struct drm_atomic_state *state;
 };

 struct imx_drm_crtc {
@@ -169,6 +174,63 @@ static void imx_drm_output_poll_changed(struct drm_device 
*drm)
 static const struct drm_mode_config_funcs imx_drm_mode_config_funcs = {
.fb_create = drm_fb_cma_create,
.output_poll_changed = imx_drm_output_poll_changed,
+   .atomic_check = drm_atomic_helper_check,
+   .atomic_commit = drm_atomic_helper_commit,
+};
+
+static void imx_drm_atomic_commit_tail(struct drm_atomic_state *state)
+{
+   struct drm_device *dev = state->dev;
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   struct drm_plane_state *plane_state;
+   struct drm_gem_cma_object *cma_obj;
+   struct fence *excl;
+   unsigned shared_count;
+   struct fence **shared;
+   unsigned int i, j;
+   int ret;
+
+   /* Wait for fences. */
+   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   plane_state = crtc->primary->state;
+   if (plane_state->fb) {
+   cma_obj = drm_fb_cma_get_gem_obj(plane_state->fb, 0);
+   if (cma_obj->base.dma_buf) {
+   ret = reservation_object_get_fences_rcu(
+   cma_obj->base.dma_buf->resv, ,
+   _count, );
+   if (unlikely(ret))
+   DRM_ERROR("failed to get fences "
+ "for buffer\n");
+
+   if (excl) {
+   fence_wait(excl, false);
+   fence_put(excl);
+   }
+   for (j = 0; j < shared_count; i++) {
+   fence_wait(shared[j], false);
+   fence_put(shared[j]);
+   }
+   }
+   }
+   }
+
+   drm_atomic_helper_commit_modeset_disables(dev, state);
+
+   drm_atomic_helper_commit_planes(dev, state, true);
+
+   drm_atomic_helper_commit_modeset_enables(dev, state);
+
+   drm_atomic_helper_commit_hw_done(state);
+
+   drm_atomic_helper_wait_for_vblanks(dev, state);
+
+   drm_atomic_helper_cleanup_planes(dev, state);
+}
+
+static struct drm_mode_config_helper_funcs imx_drm_mode_config_helpers = {
+   .atomic_commit_tail = imx_drm_atomic_commit_tail,
 };

 /*
@@ -210,6 +272,7 @@ static int imx_drm_driver_load(struct drm_device *drm, 
unsigned long flags)
drm->mode_config.max_width = 4096;
drm->mode_config.max_height = 4096;
drm->mode_config.funcs = _drm_mode_config_funcs;
+   drm->mode_config.helper_private =

[PATCH v3 06/10] drm/imx: Remove encoders' ->prepare callbacks

2016-07-04 Thread Liu Ying

The main task of imx encoders' ->prepare callbacks is to set bus_format,
bus_flags, di_vsync_pin and di_hsync_pin.  We may create a structure named
imx_encoder to cache them.  The atomic encoder callback ->disable may
replace ->prepare later, so let's remove ->prepare.

Signed-off-by: Liu Ying 
---
v2->v3:
* Newly introduced.
  The logic is picked from patch 07/10 in v2 to generate a self-contained
  patch.

 drivers/gpu/drm/imx/dw_hdmi-imx.c  |  18 +++---
 drivers/gpu/drm/imx/imx-drm-core.c |  39 
 drivers/gpu/drm/imx/imx-drm.h  |  18 +++---
 drivers/gpu/drm/imx/imx-ldb.c  | 109 +++--
 drivers/gpu/drm/imx/imx-tve.c  |  58 +++---
 drivers/gpu/drm/imx/ipuv3-crtc.c   |  38 
 drivers/gpu/drm/imx/parallel-display.c |  56 +
 7 files changed, 133 insertions(+), 203 deletions(-)

diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c 
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index a24631fd..5f64674 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -22,9 +22,11 @@

 #include "imx-drm.h"

+#define imx_enc_to_imx_hdmi(x) container_of(x, struct imx_hdmi, imx_encoder)
+
 struct imx_hdmi {
struct device *dev;
-   struct drm_encoder encoder;
+   struct imx_drm_encoder imx_encoder;
struct regmap *regmap;
 };

@@ -117,7 +119,8 @@ static void dw_hdmi_imx_encoder_mode_set(struct drm_encoder 
*encoder,

 static void dw_hdmi_imx_encoder_commit(struct drm_encoder *encoder)
 {
-   struct imx_hdmi *hdmi = container_of(encoder, struct imx_hdmi, encoder);
+   struct imx_drm_encoder *imx_encoder = enc_to_imx_enc(encoder);
+   struct imx_hdmi *hdmi = imx_enc_to_imx_hdmi(imx_encoder);
int mux = drm_of_encoder_active_port_id(hdmi->dev->of_node, encoder);

regmap_update_bits(hdmi->regmap, IOMUXC_GPR3,
@@ -125,14 +128,8 @@ static void dw_hdmi_imx_encoder_commit(struct drm_encoder 
*encoder)
   mux << IMX6Q_GPR3_HDMI_MUX_CTL_SHIFT);
 }

-static void dw_hdmi_imx_encoder_prepare(struct drm_encoder *encoder)
-{
-   imx_drm_set_bus_format(encoder, MEDIA_BUS_FMT_RGB888_1X24);
-}
-
 static const struct drm_encoder_helper_funcs dw_hdmi_imx_encoder_helper_funcs 
= {
.mode_set   = dw_hdmi_imx_encoder_mode_set,
-   .prepare= dw_hdmi_imx_encoder_prepare,
.commit = dw_hdmi_imx_encoder_commit,
.disable= dw_hdmi_imx_encoder_disable,
 };
@@ -215,7 +212,10 @@ static int dw_hdmi_imx_bind(struct device *dev, struct 
device *master,
match = of_match_node(dw_hdmi_imx_dt_ids, pdev->dev.of_node);
plat_data = match->data;
hdmi->dev = >dev;
-   encoder = >encoder;
+   encoder = >imx_encoder.encoder;
+   hdmi->imx_encoder.bus_format = MEDIA_BUS_FMT_RGB888_1X24;
+   hdmi->imx_encoder.di_hsync_pin = 2;
+   hdmi->imx_encoder.di_vsync_pin = 3;

irq = platform_get_irq(pdev, 0);
if (irq < 0)
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index b5a5173..f6e44c2 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -85,45 +85,6 @@ static int imx_drm_driver_unload(struct drm_device *drm)
return 0;
 }

-static struct imx_drm_crtc *imx_drm_find_crtc(struct drm_crtc *crtc)
-{
-   struct imx_drm_device *imxdrm = crtc->dev->dev_private;
-   unsigned i;
-
-   for (i = 0; i < MAX_CRTC; i++)
-   if (imxdrm->crtc[i] && imxdrm->crtc[i]->crtc == crtc)
-   return imxdrm->crtc[i];
-
-   return NULL;
-}
-
-int imx_drm_set_bus_config(struct drm_encoder *encoder, u32 bus_format,
-   int hsync_pin, int vsync_pin, u32 bus_flags)
-{
-   struct imx_drm_crtc_helper_funcs *helper;
-   struct imx_drm_crtc *imx_crtc;
-
-   imx_crtc = imx_drm_find_crtc(encoder->crtc);
-   if (!imx_crtc)
-   return -EINVAL;
-
-   helper = _crtc->imx_drm_helper_funcs;
-   if (helper->set_interface_pix_fmt)
-   return helper->set_interface_pix_fmt(encoder->crtc,
-   bus_format, hsync_pin, vsync_pin,
-   bus_flags);
-   return 0;
-}
-EXPORT_SYMBOL_GPL(imx_drm_set_bus_config);
-
-int imx_drm_set_bus_format(struct drm_encoder *encoder, u32 bus_format)
-{
-   return imx_drm_set_bus_config(encoder, bus_format, 2, 3,
- DRM_BUS_FLAG_DE_HIGH |
- DRM_BUS_FLAG_PIXDATA_NEGEDGE);
-}
-EXPORT_SYMBOL_GPL(imx_drm_set_bus_format);
-
 int imx_drm_crtc_vblank_get(struct imx_drm_crtc *imx_drm_crtc)
 {
return drm_crtc_vblank_get(imx_drm_crtc->crtc);
diff --git a/drivers/gpu/drm/imx/imx-drm.h b/drivers/gpu/drm/imx/imx-drm.h
index 74320a1..39cef15 100644
--- a/drivers/gpu/drm/imx/imx-drm.h
+++ b/drivers/gpu/drm/imx/imx-drm.h
@@ -15,12 +15,19 @@ struct platform_device;

[PATCH v3 05/10] drm/imx: atomic phase 2 step 2: Track plane_state->fb correctly in ->page_flip

2016-07-04 Thread Liu Ying

Use drm_atomic_set_fb_for_plane() in the legacy ->page_flip path to track
the pointer plane_state->fb correctly.

Signed-off-by: Liu Ying 
---
v2->v3:
* None.

v1->v2:
* None.

 drivers/gpu/drm/imx/ipuv3-crtc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 8a0ef13..7df51e8 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -217,6 +218,9 @@ static int ipu_page_flip(struct drm_crtc *crtc,
ipu_crtc->flip_state = IPU_FLIP_SUBMITTED;
}

+   if (crtc->primary->state)
+   drm_atomic_set_fb_for_plane(crtc->primary->state, fb);
+
return 0;

 free_flip_work:
-- 
2.7.4

[PATCH v3 04/10] drm/imx: atomic phase 2 step 1: Wire up state ->reset, ->duplicate and ->destroy

2016-07-04 Thread Liu Ying

Wire up CRTCs', planes' and connectors' ->reset, ->duplicate and ->destroy state
hooks to use the default implementations from the atomic helper library.
The helpers track each DRM object state.

Signed-off-by: Liu Ying 
---
v2->v3:
* For dw-hdmi bridge driver, simply add the hooks to the legacy connector
  function structure instead of using the atomic version directly, because
  we are not yet ready to use the atomic version's ->dpms hook.

v1->v2:
* Remove the 'atomic' from the name of the structure
  dw_hdmi_atomic_connector_funcs to address Philipp's comment.

 drivers/gpu/drm/bridge/dw-hdmi.c   | 3 +++
 drivers/gpu/drm/imx/imx-drm-core.c | 2 ++
 drivers/gpu/drm/imx/imx-ldb.c  | 4 
 drivers/gpu/drm/imx/imx-tve.c  | 4 
 drivers/gpu/drm/imx/ipuv3-crtc.c   | 4 
 drivers/gpu/drm/imx/ipuv3-plane.c  | 4 
 drivers/gpu/drm/imx/parallel-display.c | 4 
 7 files changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index 70b1f7d..dd5b21a 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -1500,6 +1500,9 @@ static const struct drm_connector_funcs 
dw_hdmi_connector_funcs = {
.detect = dw_hdmi_connector_detect,
.destroy = dw_hdmi_connector_destroy,
.force = dw_hdmi_connector_force,
+   .reset = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };

 static const struct drm_connector_funcs dw_hdmi_atomic_connector_funcs = {
diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 7746418..b5a5173 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -279,6 +279,8 @@ static int imx_drm_driver_load(struct drm_device *drm, 
unsigned long flags)
}
}

+   drm_mode_config_reset(drm);
+
/*
 * All components are now initialised, so setup the fb helper.
 * The fb helper takes copies of key hardware information, so the
diff --git a/drivers/gpu/drm/imx/imx-ldb.c b/drivers/gpu/drm/imx/imx-ldb.c
index beff793..12bf368 100644
--- a/drivers/gpu/drm/imx/imx-ldb.c
+++ b/drivers/gpu/drm/imx/imx-ldb.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -362,6 +363,9 @@ static const struct drm_connector_funcs 
imx_ldb_connector_funcs = {
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = imx_ldb_connector_detect,
.destroy = imx_drm_connector_destroy,
+   .reset = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };

 static const struct drm_connector_helper_funcs imx_ldb_connector_helper_funcs 
= {
diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
index baf7881..0b0aeee 100644
--- a/drivers/gpu/drm/imx/imx-tve.c
+++ b/drivers/gpu/drm/imx/imx-tve.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -360,6 +361,9 @@ static const struct drm_connector_funcs 
imx_tve_connector_funcs = {
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = imx_tve_connector_detect,
.destroy = imx_drm_connector_destroy,
+   .reset = drm_atomic_helper_connector_reset,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
 };

 static const struct drm_connector_helper_funcs imx_tve_connector_helper_funcs 
= {
diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index ba880fa..8a0ef13 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -232,6 +233,9 @@ static const struct drm_crtc_funcs ipu_crtc_funcs = {
.set_config = drm_crtc_helper_set_config,
.destroy = drm_crtc_cleanup,
.page_flip = ipu_page_flip,
+   .reset = drm_atomic_helper_crtc_reset,
+   .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
 };

 static void ipu_crtc_handle_pageflip(struct ipu_crtc *ipu_crtc)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 59f2353..1a126fe 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -14,6 +14,7 @@
  */

 #include 
+#include 
 #include 
 #include 
 #include 
@@ -362,6 +363,9 @@ static const struct drm_plane_funcs ipu_plane_funcs = {
.update_plane   = drm_plane_helper_update,
.disable_plane  = drm_plane_helper_disable,
.destroy

[PATCH v3 03/10] drm/imx: atomic phase 1: Use transitional atomic CRTC and plane helpers

2016-07-04 Thread Liu Ying

Use the drm_plane_helper_update/disable() and drm_helper_crtc_mode_set()
transitional atomic helpers.  The crtc->mode_set_nofb callback is added
so that the primary plane is no longer tied to the CRTC.  Check/update
logics are separated to make sure crtc->mode_set_nofb and plane->atomic_update
are always successful.  Also, some necessary logics are tweaked for a smooth
transition.

Signed-off-by: Liu Ying 
---
v2->v3:
* A minor change to simplify the way we find crtc->enabled in
  drm_plane_helper_funcs->atomic_check.

v1->v2:
* Get the overlay ipu plane resource when initializing the relevant CRTC
  and do not get ipu plane resource any more when updating plane to avoid
  resource allocation failure.
* Remove obsolete comments from ipu_crtc_enable/disable().

 drivers/gpu/drm/imx/ipuv3-crtc.c  | 197 ---
 drivers/gpu/drm/imx/ipuv3-plane.c | 511 +++---
 drivers/gpu/drm/imx/ipuv3-plane.h |  16 +-
 drivers/gpu/ipu-v3/ipu-dc.c   |   5 +-
 drivers/gpu/ipu-v3/ipu-di.c   |   3 -
 5 files changed, 410 insertions(+), 322 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index fc04041..ba880fa 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -73,7 +73,7 @@ struct ipu_crtc {

 #define to_ipu_crtc(x) container_of(x, struct ipu_crtc, base)

-static void ipu_fb_enable(struct ipu_crtc *ipu_crtc)
+static void ipu_crtc_enable(struct ipu_crtc *ipu_crtc)
 {
struct ipu_soc *ipu = dev_get_drvdata(ipu_crtc->dev->parent);

@@ -81,30 +81,30 @@ static void ipu_fb_enable(struct ipu_crtc *ipu_crtc)
return;

ipu_dc_enable(ipu);
-   ipu_plane_enable(ipu_crtc->plane[0]);
-   /* Start DC channel and DI after IDMAC */
ipu_dc_enable_channel(ipu_crtc->dc);
ipu_di_enable(ipu_crtc->di);
-   drm_crtc_vblank_on(_crtc->base);
-
ipu_crtc->enabled = 1;
+
+   /*
+* In order not to be warned on enabling vblank failure,
+* we should call drm_crtc_vblank_on() after ->enabled is set to 1.
+*/
+   drm_crtc_vblank_on(_crtc->base);
 }

-static void ipu_fb_disable(struct ipu_crtc *ipu_crtc)
+static void ipu_crtc_disable(struct ipu_crtc *ipu_crtc)
 {
struct ipu_soc *ipu = dev_get_drvdata(ipu_crtc->dev->parent);

if (!ipu_crtc->enabled)
return;

-   /* Stop DC channel and DI before IDMAC */
ipu_dc_disable_channel(ipu_crtc->dc);
ipu_di_disable(ipu_crtc->di);
-   ipu_plane_disable(ipu_crtc->plane[0]);
ipu_dc_disable(ipu);
-   drm_crtc_vblank_off(_crtc->base);
-
ipu_crtc->enabled = 0;
+
+   drm_crtc_vblank_off(_crtc->base);
 }

 static void ipu_crtc_dpms(struct drm_crtc *crtc, int mode)
@@ -115,12 +115,12 @@ static void ipu_crtc_dpms(struct drm_crtc *crtc, int mode)

switch (mode) {
case DRM_MODE_DPMS_ON:
-   ipu_fb_enable(ipu_crtc);
+   ipu_crtc_enable(ipu_crtc);
break;
case DRM_MODE_DPMS_STANDBY:
case DRM_MODE_DPMS_SUSPEND:
case DRM_MODE_DPMS_OFF:
-   ipu_fb_disable(ipu_crtc);
+   ipu_crtc_disable(ipu_crtc);
break;
}
 }
@@ -234,79 +234,6 @@ static const struct drm_crtc_funcs ipu_crtc_funcs = {
.page_flip = ipu_page_flip,
 };

-static int ipu_crtc_mode_set(struct drm_crtc *crtc,
-  struct drm_display_mode *orig_mode,
-  struct drm_display_mode *mode,
-  int x, int y,
-  struct drm_framebuffer *old_fb)
-{
-   struct drm_device *dev = crtc->dev;
-   struct drm_encoder *encoder;
-   struct ipu_crtc *ipu_crtc = to_ipu_crtc(crtc);
-   struct ipu_di_signal_cfg sig_cfg = {};
-   unsigned long encoder_types = 0;
-   int ret;
-
-   dev_dbg(ipu_crtc->dev, "%s: mode->hdisplay: %d\n", __func__,
-   mode->hdisplay);
-   dev_dbg(ipu_crtc->dev, "%s: mode->vdisplay: %d\n", __func__,
-   mode->vdisplay);
-
-   list_for_each_entry(encoder, >mode_config.encoder_list, head)
-   if (encoder->crtc == crtc)
-   encoder_types |= BIT(encoder->encoder_type);
-
-   dev_dbg(ipu_crtc->dev, "%s: attached to encoder types 0x%lx\n",
-   __func__, encoder_types);
-
-   /*
-* If we have DAC or LDB, then we need the IPU DI clock to be
-* the same as the LDB DI clock. For TVDAC, derive the IPU DI
-* clock from 27 MHz TVE_DI clock, but allow to divide it.
-*/
-   if (encoder_types & (BIT(DRM_MODE_ENCODER_DAC) |
-BIT(DRM_MODE_ENCODER_LVDS)))
-   sig_cfg.clkflags = IPU_DI_CLKMODE_SYNC | IPU_DI_CLKMODE_EXT;
-   else if (encoder_types & BIT(DRM_MODE_ENCODER_TVDAC))
-   sig_cfg.clkflags = IPU_DI_CLKMODE_EXT;
-   else
-

[PATCH v3 02/10] gpu: ipu-v3: ipu-dmfc: Use static DMFC FIFO allocation mechanism

2016-07-04 Thread Liu Ying

For all video modes we support currently, we always get 2 slots for
a plane by using the current existing dynamic DMFC FIFO allocation
mechanism.  So, let's change to use the static one to simplify the
code.  This also makes it easier to implement the atomic mode setting
as we don't need to handle allocation failure cases then.

Signed-off-by: Liu Ying 
---
v2->v3:
* None.

v1->v2:
* Improve the commit message to better explain why the static allocation
  mechanism can replace the dynamic one.

 drivers/gpu/drm/imx/ipuv3-plane.c |  26 -
 drivers/gpu/ipu-v3/ipu-dmfc.c | 213 ++
 include/video/imx-ipu-v3.h|   3 -
 3 files changed, 7 insertions(+), 235 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index cd7eb26..02701de 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -53,24 +53,6 @@ int ipu_plane_irq(struct ipu_plane *ipu_plane)
 IPU_IRQ_EOF);
 }

-static int calc_vref(struct drm_display_mode *mode)
-{
-   unsigned long htotal, vtotal;
-
-   htotal = mode->htotal;
-   vtotal = mode->vtotal;
-
-   if (!htotal || !vtotal)
-   return 60;
-
-   return DIV_ROUND_UP(mode->clock * 1000, vtotal * htotal);
-}
-
-static inline int calc_bandwidth(int width, int height, unsigned int vref)
-{
-   return width * height * vref;
-}
-
 int ipu_plane_set_base(struct ipu_plane *ipu_plane, struct drm_framebuffer *fb,
   int x, int y)
 {
@@ -291,14 +273,6 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct 
drm_crtc *crtc,
}
}

-   ret = ipu_dmfc_alloc_bandwidth(ipu_plane->dmfc,
-   calc_bandwidth(crtc_w, crtc_h,
-  calc_vref(mode)), 64);
-   if (ret) {
-   dev_err(dev, "allocating dmfc bandwidth failed with %d\n", ret);
-   return ret;
-   }
-
ipu_dmfc_config_wait4eot(ipu_plane->dmfc, crtc_w);

ipu_cpmem_zero(ipu_plane->ipu_ch);
diff --git a/drivers/gpu/ipu-v3/ipu-dmfc.c b/drivers/gpu/ipu-v3/ipu-dmfc.c
index 837b1ec2..42705bb 100644
--- a/drivers/gpu/ipu-v3/ipu-dmfc.c
+++ b/drivers/gpu/ipu-v3/ipu-dmfc.c
@@ -45,17 +45,6 @@
 #define DMFC_DP_CHAN_6B_24 16
 #define DMFC_DP_CHAN_6F_29 24

-#define DMFC_FIFO_SIZE_64  (3 << 3)
-#define DMFC_FIFO_SIZE_128 (2 << 3)
-#define DMFC_FIFO_SIZE_256 (1 << 3)
-#define DMFC_FIFO_SIZE_512 (0 << 3)
-
-#define DMFC_SEGMENT(x)((x & 0x7) << 0)
-#define DMFC_BURSTSIZE_128 (0 << 6)
-#define DMFC_BURSTSIZE_64  (1 << 6)
-#define DMFC_BURSTSIZE_32  (2 << 6)
-#define DMFC_BURSTSIZE_16  (3 << 6)
-
 struct dmfc_channel_data {
int ipu_channel;
unsigned long   channel_reg;
@@ -104,9 +93,6 @@ struct ipu_dmfc_priv;

 struct dmfc_channel {
unsignedslots;
-   unsignedslotmask;
-   unsignedsegment;
-   int burstsize;
struct ipu_soc  *ipu;
struct ipu_dmfc_priv*priv;
const struct dmfc_channel_data  *data;
@@ -117,7 +103,6 @@ struct ipu_dmfc_priv {
struct device *dev;
struct dmfc_channel channels[DMFC_NUM_CHANNELS];
struct mutex mutex;
-   unsigned long bandwidth_per_slot;
void __iomem *base;
int use_count;
 };
@@ -172,184 +157,6 @@ void ipu_dmfc_disable_channel(struct dmfc_channel *dmfc)
 }
 EXPORT_SYMBOL_GPL(ipu_dmfc_disable_channel);

-static int ipu_dmfc_setup_channel(struct dmfc_channel *dmfc, int slots,
-   int segment, int burstsize)
-{
-   struct ipu_dmfc_priv *priv = dmfc->priv;
-   u32 val, field;
-
-   dev_dbg(priv->dev,
-   "dmfc: using %d slots starting from segment %d for IPU 
channel %d\n",
-   slots, segment, dmfc->data->ipu_channel);
-
-   switch (slots) {
-   case 1:
-   field = DMFC_FIFO_SIZE_64;
-   break;
-   case 2:
-   field = DMFC_FIFO_SIZE_128;
-   break;
-   case 4:
-   field = DMFC_FIFO_SIZE_256;
-   break;
-   case 8:
-   field = DMFC_FIFO_SIZE_512;
-   break;
-   default:
-   return -EINVAL;
-   }
-
-   switch (burstsize) {
-   case 16:
-   field |= DMFC_BURSTSIZE_16;
-   break;
-   case 32:
-   field |= DMFC_BURSTSIZE_32;
-   break;
-   case 64:
-   field |= DMFC_BURSTSIZE_64;
-   break;
-   case 128:
-   field |= DMFC_BURSTSIZE_128;
-   break;
-   }
-
-   field |= DMFC_SEGMENT(segment);
-
-   val =

[PATCH v3 01/10] drm/imx: ipuv3 plane: Check different types of plane separately

2016-07-04 Thread Liu Ying

The IPUv3 primary plane doesn't support partial off screen.
So, this patch separates plane check logics for primary plane and overlay
plane and adds more limitations on the primary plane.

Signed-off-by: Liu Ying 
---
v2->v3:
* None.

v1->v2:
* Remove an unnecessary copy to address Philipp's comment.

 drivers/gpu/drm/imx/ipuv3-plane.c | 67 ++-
 1 file changed, 38 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index a4bb441..cd7eb26 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -199,37 +199,46 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, 
struct drm_crtc *crtc,
if (src_w != crtc_w || src_h != crtc_h)
return -EINVAL;

-   /* clip to crtc bounds */
-   if (crtc_x < 0) {
-   if (-crtc_x > crtc_w)
+   if (ipu_plane->base.type == DRM_PLANE_TYPE_PRIMARY) {
+   /* full plane doesn't support partial off screen */
+   if (crtc_x || crtc_y || crtc_w != mode->hdisplay ||
+   crtc_h != mode->vdisplay)
return -EINVAL;
-   src_x += -crtc_x;
-   src_w -= -crtc_x;
-   crtc_w -= -crtc_x;
-   crtc_x = 0;
-   }
-   if (crtc_y < 0) {
-   if (-crtc_y > crtc_h)
-   return -EINVAL;
-   src_y += -crtc_y;
-   src_h -= -crtc_y;
-   crtc_h -= -crtc_y;
-   crtc_y = 0;
-   }
-   if (crtc_x + crtc_w > mode->hdisplay) {
-   if (crtc_x > mode->hdisplay)
-   return -EINVAL;
-   crtc_w = mode->hdisplay - crtc_x;
-   src_w = crtc_w;
-   }
-   if (crtc_y + crtc_h > mode->vdisplay) {
-   if (crtc_y > mode->vdisplay)
+
+   /* full plane minimum width is 13 pixels */
+   if (crtc_w < 13)
return -EINVAL;
-   crtc_h = mode->vdisplay - crtc_y;
-   src_h = crtc_h;
-   }
-   /* full plane minimum width is 13 pixels */
-   if (crtc_w < 13 && (ipu_plane->dp_flow != IPU_DP_FLOW_SYNC_FG))
+   } else if (ipu_plane->base.type == DRM_PLANE_TYPE_OVERLAY) {
+   /* clip to crtc bounds */
+   if (crtc_x < 0) {
+   if (-crtc_x > crtc_w)
+   return -EINVAL;
+   src_x += -crtc_x;
+   src_w -= -crtc_x;
+   crtc_w -= -crtc_x;
+   crtc_x = 0;
+   }
+   if (crtc_y < 0) {
+   if (-crtc_y > crtc_h)
+   return -EINVAL;
+   src_y += -crtc_y;
+   src_h -= -crtc_y;
+   crtc_h -= -crtc_y;
+   crtc_y = 0;
+   }
+   if (crtc_x + crtc_w > mode->hdisplay) {
+   if (crtc_x > mode->hdisplay)
+   return -EINVAL;
+   crtc_w = mode->hdisplay - crtc_x;
+   src_w = crtc_w;
+   }
+   if (crtc_y + crtc_h > mode->vdisplay) {
+   if (crtc_y > mode->vdisplay)
+   return -EINVAL;
+   crtc_h = mode->vdisplay - crtc_y;
+   src_h = crtc_h;
+   }
+   } else
return -EINVAL;
if (crtc_h < 2)
return -EINVAL;
-- 
2.7.4

[PATCH v3 00/10] imx drm atomic mode setting conversion

2016-07-04 Thread Liu Ying

Hi,

This is the v3 patch set to convert imx drm into atomic mode setting.
It takes 3 phases to achieve the goal.

v2->v3:
* Rebase onto Daniel Vetter's open git branch topic/drm-misc so that
  we may better support nonblock atomic commit with the aid from
  drm atomic helper.
* Remove dw-hdmi bridge driver's legacy drm_connector_funcs struture
  step-by-step instead of doing that in patch 04/10 directly.
  So, patch 08/10 in this set is newly introduced.

v1->v2:
* Rebase onto Philipp Zabel's open git branch imx-drm/next as Philipp
  required.
* Drop patch 05/14 and 10/14 in v1 which touch drm core to disable
  plane in transitional helper drm_helper_crtc_mode_set and in
  drm_atomic_helper_disable_all, because we won't get ipu plane
  resource in v2 when updating plane and failure won't happen.
* Wait for pending commit on each CRTC for both block and nonblock
  atomic mode settings.  This way, a block commit will not overwrite
  the hardware setting when a nonblock page flip is about to finish,
  so that the page flip may wait for vblank successfully.
* See changelogs in each patch for other trivial updates.

Liu Ying (10):
  drm/imx: ipuv3 plane: Check different types of plane separately
  gpu: ipu-v3: ipu-dmfc: Use static DMFC FIFO allocation mechanism
  drm/imx: atomic phase 1: Use transitional atomic CRTC and plane
helpers
  drm/imx: atomic phase 2 step 1: Wire up state ->reset, ->duplicate and
->destroy
  drm/imx: atomic phase 2 step 2: Track plane_state->fb correctly in
->page_flip
  drm/imx: Remove encoders' ->prepare callbacks
  drm/imx: atomic phase 3 step 1: Use atomic configuration
  drm/bridge: dw-hdmi: Remove the legacy drm_connector_funcs structure
  drm/imx: atomic phase 3 step 2: Legacy callback fixups
  drm/imx: atomic phase 3 step 3: Advertise DRIVER_ATOMIC

 drivers/gpu/drm/bridge/dw-hdmi.c   |  19 +-
 drivers/gpu/drm/imx/dw_hdmi-imx.c  |  22 +-
 drivers/gpu/drm/imx/imx-drm-core.c | 120 +---
 drivers/gpu/drm/imx/imx-drm.h  |  18 +-
 drivers/gpu/drm/imx/imx-ldb.c  | 129 
 drivers/gpu/drm/imx/imx-tve.c  |  85 ++
 drivers/gpu/drm/imx/ipuv3-crtc.c   | 370 ++
 drivers/gpu/drm/imx/ipuv3-plane.c  | 543 -
 drivers/gpu/drm/imx/ipuv3-plane.h  |  16 -
 drivers/gpu/drm/imx/parallel-display.c |  74 +++--
 drivers/gpu/ipu-v3/ipu-dc.c|   5 +-
 drivers/gpu/ipu-v3/ipu-di.c|   3 -
 drivers/gpu/ipu-v3/ipu-dmfc.c  | 213 +
 include/video/imx-ipu-v3.h |   3 -
 14 files changed, 592 insertions(+), 1028 deletions(-)

-- 
2.7.4

[PATCH] drm: sti: fix prototypes after API change

2016-07-04 Thread Mark Brown

On Mon, Jul 04, 2016 at 03:36:57PM +0200, Arnd Bergmann wrote:
> On Monday, July 4, 2016 3:22:30 PM CEST Mark Brown wrote:

> > I sent a pull request for the API change to the DRM people which might
> > be easier given that it's a single commit topic branch rather than the
> > whole of DRM.

> Agreed, that is probably the best way forward. Does your pull request
> also contain an equivalent of my two patches?

No, I just sent a pull request for the API change - I don't have the new
patches in my tree.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160704/6e71be1e/attachment-0001.sig>

[PATCH] drm: sti: fix prototypes after API change

2016-07-04 Thread Arnd Bergmann

On Monday, July 4, 2016 3:22:30 PM CEST Mark Brown wrote:
> On Mon, Jul 04, 2016 at 03:16:51PM +0200, Arnd Bergmann wrote:
> 
> > This follows the API change, adding the extra function arguments.
> > I suppose we want this to be part of the ASoC merge in linux-next
> > for now too.
> 
> I sent a pull request for the API change to the DRM people which might
> be easier given that it's a single commit topic branch rather than the
> whole of DRM.

Agreed, that is probably the best way forward. Does your pull request
also contain an equivalent of my two patches?

Arnd

[PATCH] drm: sti: fix prototypes after API change

2016-07-04 Thread Benjamin Gaignard

Acked-by: Benjamin Gaignard 

2016-07-04 15:22 GMT+02:00 Mark Brown :

> On Mon, Jul 04, 2016 at 03:16:51PM +0200, Arnd Bergmann wrote:
>
> > This follows the API change, adding the extra function arguments.
> > I suppose we want this to be part of the ASoC merge in linux-next
> > for now too.
>
> I sent a pull request for the API change to the DRM people which might
> be easier given that it's a single commit topic branch rather than the
> whole of DRM.
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>


-- 

Benjamin Gaignard

Graphic Working Group

Linaro.org <http://www.linaro.org/> *â *Open source software for ARM SoCs

Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> | Twitter
<http://twitter.com/#!/linaroorg> | Blog
<http://www.linaro.org/linaro-blog/>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160704/c99d51ed/attachment.html>

[PATCH] drm: sti: fix prototypes after API change

2016-07-04 Thread Mark Brown

On Mon, Jul 04, 2016 at 03:16:51PM +0200, Arnd Bergmann wrote:

> This follows the API change, adding the extra function arguments.
> I suppose we want this to be part of the ASoC merge in linux-next
> for now too.

I sent a pull request for the API change to the DRM people which might
be easier given that it's a single commit topic branch rather than the
whole of DRM.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160704/b8feaca1/attachment.sig>

[PATCH -next] drm/tegra: sor: Fix invalid kfree of devm_kzalloc allocated data

2016-07-04 Thread weiyj...@163.com

From: Wei Yongjun 

data allocated with devm_kzalloc should not be freed using kfree,
because doing so causes a dangling pointer, and a subsequent
double free, use devm_kfree instead.

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/tegra/sor.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 8425eda..af98587 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -363,7 +363,7 @@ static struct clk *tegra_clk_sor_brick_register(struct 
tegra_sor *sor,

clk = devm_clk_register(sor->dev, >hw);
if (IS_ERR(clk))
-   kfree(brick);
+   devm_kfree(sor->dev, brick);

return clk;
 }

[PATCH] drm/amd/powerplay: fix integer overflow warning

2016-07-04 Thread Arnd Bergmann

A late bugfix for v4.7 introduced a build-time regression, producing
a (probably harmless) warning:

powerplay/hwmgr/polaris10_hwmgr.c: In function 
'polaris10_populate_clock_stretcher_data_table':
powerplay/hwmgr/polaris10_hwmgr.c:1817:4: error: this decimal constant is 
unsigned only in ISO C90 [-Werror]
volt_without_cks = (uint32_t)((2753594000 + 
(sclk_table->entries[i].clk/100) * 136418 -(ro - 70) * 100) / \
^~~~
powerplay/hwmgr/polaris10_hwmgr.c:1822:4: error: this decimal constant is 
unsigned only in ISO C90 [-Werror]
volt_without_cks = (uint32_t)((2416794800 + 
(sclk_table->entries[i].clk/100) * 1476925/10 -(ro - 50) * 100) / \
^~~~
powerplay/hwmgr/polaris10_hwmgr.c:1824:4: error: this decimal constant is 
unsigned only in ISO C90 [-Werror]
volt_with_cks = (uint32_t)((2999656000 + sclk_table->entries[i].clk * 
392803/100 - (ro - 44) * 100) / \

This marks the new integer literals unsigned, which makes the calculation
more sensible and avoids the warning.

Signed-off-by: Arnd Bergmann 
Fixes: 0812a945fbb8 ("drm/amd/powerplay: Update CKS on/ CKS off voltage offset 
calculation")
---
 drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
index ec2a7ada346a..5b26bbbc3e79 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c
@@ -1814,14 +1814,14 @@ static int 
polaris10_populate_clock_stretcher_data_table(struct pp_hwmgr *hwmgr)
data->smc_state_table.Sclk_CKS_masterEn0_7 |=
sclk_table->entries[i].cks_enable << i;
if (hwmgr->chip_id == CHIP_POLARIS10) {
-   volt_without_cks = (uint32_t)((2753594000 + 
(sclk_table->entries[i].clk/100) * 136418 -(ro - 70) * 100) / \
+   volt_without_cks = (uint32_t)((2753594000u + 
(sclk_table->entries[i].clk/100) * 136418 -(ro - 70) * 100) / \
(2424180 - 
(sclk_table->entries[i].clk/100) * 1132925/1000));
-   volt_with_cks = (uint32_t)((279720200 + 
sclk_table->entries[i].clk * 3232 - (ro - 65) * 1) / \
+   volt_with_cks = (uint32_t)((279720200u + 
sclk_table->entries[i].clk * 3232 - (ro - 65) * 1) / \
(252248000 - 
sclk_table->entries[i].clk/100 * 115764));
} else {
-   volt_without_cks = (uint32_t)((2416794800 + 
(sclk_table->entries[i].clk/100) * 1476925/10 -(ro - 50) * 100) / \
+   volt_without_cks = (uint32_t)((2416794800u + 
(sclk_table->entries[i].clk/100) * 1476925/10 -(ro - 50) * 100) / \
(2625416 - 
(sclk_table->entries[i].clk/100) * 12586807/1));
-   volt_with_cks = (uint32_t)((2999656000 + 
sclk_table->entries[i].clk * 392803/100 - (ro - 44) * 100) / \
+   volt_with_cks = (uint32_t)((2999656000u + 
sclk_table->entries[i].clk * 392803/100 - (ro - 44) * 100) / \
(3422454 - 
sclk_table->entries[i].clk/100 * 18886376/1));
}

-- 
2.9.0

[PATCH] drm: sti: fix prototypes after API change

2016-07-04 Thread Arnd Bergmann

Like the mediatek hdmi driver, the sti driver now suffers from
an API change in linux-next:

drivers/gpu/drm/sti/sti_hdmi.c:1250:15: error: initialization from incompatible 
pointer type [-Werror=incompatible-pointer-types]
  .hw_params = hdmi_audio_hw_params,
   ^~~~
drivers/gpu/drm/sti/sti_hdmi.c:1250:15: note: (near initialization for 
'audio_codec_ops.hw_params')

This follows the API change, adding the extra function arguments.
I suppose we want this to be part of the ASoC merge in linux-next
for now too.

Signed-off-by: Arnd Bergmann 
Fixes: 2c348e505328 ("drm: sti: Add ASoC generic hdmi codec support.")
Fixes: efc9194bcff8 ("ASoC: hdmi-codec: callback function will be called with 
private data")
Link: https://lkml.org/lkml/2016/6/29/441
---
 drivers/gpu/drm/sti/sti_hdmi.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 927e2b2e5af2..fedc17f98d9b 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -1169,7 +1169,7 @@ static int hdmi_audio_configure(struct sti_hdmi *hdmi,
return hdmi_audio_infoframe_config(hdmi);
 }

-static void hdmi_audio_shutdown(struct device *dev)
+static void hdmi_audio_shutdown(struct device *dev, void *data)
 {
struct sti_hdmi *hdmi = dev_get_drvdata(dev);
int audio_cfg;
@@ -1186,6 +1186,7 @@ static void hdmi_audio_shutdown(struct device *dev)
 }

 static int hdmi_audio_hw_params(struct device *dev,
+   void *data,
struct hdmi_codec_daifmt *daifmt,
struct hdmi_codec_params *params)
 {
@@ -1221,7 +1222,7 @@ static int hdmi_audio_hw_params(struct device *dev,
return 0;
 }

-static int hdmi_audio_digital_mute(struct device *dev, bool enable)
+static int hdmi_audio_digital_mute(struct device *dev, void *data, bool enable)
 {
struct sti_hdmi *hdmi = dev_get_drvdata(dev);

@@ -1235,7 +1236,7 @@ static int hdmi_audio_digital_mute(struct device *dev, 
bool enable)
return 0;
 }

-static int hdmi_audio_get_eld(struct device *dev, uint8_t *buf, size_t len)
+static int hdmi_audio_get_eld(struct device *dev, void *data, uint8_t *buf, 
size_t len)
 {
struct sti_hdmi *hdmi = dev_get_drvdata(dev);
struct drm_connector *connector = hdmi->drm_connector;
-- 
2.9.0

[PATCH 1/1] gpu: drm: exynos_hdmi: add missing of_node_put after calling of_parse_phandle

2016-07-04 Thread Peter Chen

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 58de5a4..e9591c7 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1828,6 +1828,7 @@ static int hdmi_probe(struct platform_device *pdev)
DRM_ERROR("Failed to find ddc node in device tree\n");
return -ENODEV;
}
+   of_node_put(dev->of_node);

 out_get_ddc_adpt:
hdata->ddc_adpt = of_find_i2c_adapter_by_node(ddc_node);
@@ -1846,6 +1847,7 @@ out_get_ddc_adpt:
ret = -ENODEV;
goto err_ddc;
}
+   of_node_put(dev->of_node);

 out_get_phy_port:
if (hdata->drv_data->is_apb_phy) {
-- 
1.9.1

[PATCH 1/1] gpu: drm: arcpgu_drv: add missing of_node_put after calling of_parse_phandle

2016-07-04 Thread Peter Chen

of_node_put needs to be called when the device node which is got
from of_parse_phandle has finished using.

Signed-off-by: Peter Chen 
---
 drivers/gpu/drm/arc/arcpgu_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 76e187a..b2c3c3b 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -155,6 +155,7 @@ static int arcpgu_load(struct drm_device *drm)
}

ret = arcpgu_drm_hdmi_init(drm, encoder_node);
+   of_node_put(encoder_node);
if (ret < 0)
return ret;

-- 
1.9.1

[Bug 96731] [RADEONSI] [LLVM] [bisected] GPU lockups when running Alien: Isolation

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #12 from Nicolai HÃ¤hnle  ---
The first bug that I noticed in the shaders was in return handling for
non-monolithic shader parts. Fix for that bug is here:
http://reviews.llvm.org/D21975

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

[Bug 94471] Tonga UVD 4Kx4K = failed to allocate a buffer

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #6 from Andy Furniss  ---
Mesa commit 

commit 51227b41c6b026f5b0a3925093b91800cdfcc923
Author: Indrajit Das 
Date:   Fri May 27 18:27:15 2016 +0530

radeon/uvd: fix overflow error while calculating bit stream buffer size


gets rid of the errors and so mpv/mplayer will attempt to use uvd, but no video
is displayed, just a black screen.

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

next-20160704 build: 2 failures 7 warnings (next-20160704)

2016-07-04 Thread Mark Brown

On Mon, Jul 04, 2016 at 12:50:46PM +0100, Build bot for Mark Brown wrote:

Today's -next fails to build an ARM allmodconfig due to:

>   arm-allmodconfig
> ../drivers/gpu/drm/sti/sti_hdmi.c:1250:15: error: initialization from 
> incompatible pointer type [-Werror=incompatible-pointer-types]
> ../drivers/gpu/drm/sti/sti_hdmi.c:1251:20: error: initialization from 
> incompatible pointer type [-Werror=incompatible-pointer-types]
> ../drivers/gpu/drm/sti/sti_hdmi.c:1252:18: error: initialization from 
> incompatible pointer type [-Werror=incompatible-pointer-types]
> ../drivers/gpu/drm/sti/sti_hdmi.c:1253:13: error: initialization from 
> incompatible pointer type [-Werror=incompatible-pointer-types]

due to adding new code which doesn't take account of the recent API
change in the HDMI CODEC.  There's another change already in DRM for
which the expectation was that the API change and an update Arnd posted
would be pulled over so I guess the same approach makes sense here:

The following changes since commit 1a695a905c18548062509178b98bc91e67510864:

  Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 
tags/asoc-hdmi-codec-pdata

for you to fetch changes up to efc9194bcff84666832c6493bafa92029ac6634c:

  ASoC: hdmi-codec: callback function will be called with private data 
(2016-06-27 18:53:15 +0100)


ASoC: Add private data for HDMI CODEC callbacks

Allow the HDMI CODECs to get private data passed in in callbacks.


Kuninori Morimoto (1):
  ASoC: hdmi-codec: callback function will be called with private data

 include/sound/hdmi-codec.h| 13 -
 sound/soc/codecs/hdmi-codec.c | 15 ---
 2 files changed, 16 insertions(+), 12 deletions(-)
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160704/e022128a/attachment.sig>

[GIT PULL] drm/mediatek: MT8173 gamma & dither support

2016-07-04 Thread CK Hu

Hi, Emil:

On Sun, 2016-07-03 at 23:43 +0100, Emil Velikov wrote:
> Hi Bibby,
> 
> On 27 June 2016 at 12:29, Bibby Hsieh  wrote:
> > On Mon, 2016-06-27 at 12:20 +0200, Matthias Brugger wrote:
> >>
> >> On 06/24/2016 09:27 AM, Bibby Hsieh wrote:
> >> > Hi Dave,
> >> >
> >> > Please consider merging this tag, which contains the v2 MT8173 gamma & 
> >> > dither function patches I sent on 2016-06-17, rebased onto v4.7-rc1. 
> >> > There have been no further comments.
> >> >
> >> > Thanks
> >> > Bibby
> >> >
> >> > The following changes since commit 
> >> > 1a695a905c18548062509178b98bc91e67510864:
> >> >
> >> >   Linux 4.7-rc1 (2016-05-29 16:29:24 GMT)
> >> >
> >> > are available in the git repository at:
> >> >
> >> >   git at github.com:BibbyHsieh/linux4.7-rc1.git
> >> >
> >> > for you to fetch changes up to dd0eb773bc125f5e6bca735d19c08500dc3730f9:
> >> >
> >> >   drm/mediatek: Add gamma correction
> >> >
> >> > -
> >>
> >> As far as I can see, your branch has 3 patches on top from Eddie. It
> >> seems to me as if you didn't send your patches to the mailinglist before?
> >> Anyway this branch does not fulfill the rules to get merged into the
> >> linux kernel.
> >>
> >> Why do you send a pull request? The normal process is to send the
> >> patches via email and if the maintainer wants you can send a pull
> >> request once the patches are ready to be merged.
> >>
> >> Regards,
> >> Matthias
> >>
> >
> > I sent v1 and v2 on 2016-06-14 and 06-17 respectively [0-8].
> > After I made some modifications according to Daniel Vetter's comments,
> > there had been no further comments and I sent the pull request as the
> > other sub-sys.
> >
> > I'm sorry for my mistake, I will re-arrange the tree for upstream.
> > Next time, I will check with maintainer by email first, and sent the
> > pull request.
> >
> It might be a bit hard to find out who's the maintainer considering
> MAINTAINERS has no entry for this driver.
> 
> Looking at how things are going Philipp Zabel will be the more likely
> person for the task, yet I would be nice if someone from the Mediatek
> squad is helping him out - CK Hu perhaps ?
> 
> Regards,
> Emil

I'm willing to be one of Mediatek DRM driver maintainer. I wish this
would make things easier.

Regards,
CK

[PATCH 1/6] lib: string: add function strtolower()

2016-07-04 Thread Markus Mayer

On 1 July 2016 at 14:08, Rasmus Villemoes  wrote:

> A few suggestions:
>
> - Make the function take separate src and dst parameters, making it explicitly
>   allowed to pass the same value (but not other kinds of overlap, of
>   course). That way one can avoid "strcpy(dst, src); strtolower(dst);".
>
> - Drop the NULL check. If someone does "foo->bar = something;
>   strtolower(foo->bar); put foo in a global data structure...", the
>   dereference of foo->bar may happen much later. Doing the NULL deref
>   sooner means it's much easier to find and fix the bug. (Also, other
>   str* and mem* functions don't usually check for NULL).
>
> - While it's true that strcpy and memcpy by definition return dst, that's
>   mostly useless. If you want it to return anything, please make it
>   something that might be used - for example, having stpcpy semantics
>   (returning a pointer to dst's terminating \0) means a caller might avoid
>   a strlen call.
>
> - Maybe do strtoupper while you're at it. Quick grepping didn't find any
>   use for the copy-while-lowercasing, but copy-while-uppercasing can at
>   least be used in drivers/acpi/acpica/nsrepair2.c,
>   drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c,
>   drivers/power/power_supply_sysfs.c along with a bunch of inplace
>   uppercasing.
>
>
> Rasmus

Thanks for the suggestions to you and Jani. Based on the feedback I
received, I am reworking the series now and will post v2 probably
tomorrow.

Regards,
-Markus

[PATCH] drm/radeon: Remove deprecated create_singlethread_workqueue

2016-07-04 Thread Michel Dänzer

On 02.07.2016 22:46, Tejun Heo wrote:
> On Sat, Jul 02, 2016 at 04:33:50PM +0530, Bhaktipriya Shridhar wrote:
>> alloc_workqueue replaces deprecated create_singlethread_workqueue().
>>
>> A dedicated workqueue has been used since work items need to be flushed
>> as a group rather than individually.
>>
>> Since the flip_queue workqueue is involved in page-flipping and is not
>> being used on a memory reclaim path, WQ_MEM_RECLAIM has not been set.
>>
>> Since there are only a fixed number of work items, explicit concurrency
>> limit is unnecessary here.
> 
> What are the involved work items?

drivers/gpu/drm/radeon/radeon_display.c:radeon_flip_work_func()


> Is it safe to run them concurrently?

Concurrently with what exactly?


-- 
Earthling Michel DÃ¤nzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH] apple-gmux: Sphinxify docs

2016-07-04 Thread Lukas Wunner

Convert asciidoc-formatted docs to rst in accordance with Jonathan's and
Jani's effort to use sphinx for kernel-doc rendering in 4.8.

Cc: Jonathan Corbet 
Cc: Jani Nikula 
Signed-off-by: Lukas Wunner 
---
 drivers/platform/x86/apple-gmux.c | 55 +--
 1 file changed, 29 insertions(+), 26 deletions(-)

diff --git a/drivers/platform/x86/apple-gmux.c 
b/drivers/platform/x86/apple-gmux.c
index 4034d2d..a66be13 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -31,19 +31,21 @@
 /**
  * DOC: Overview
  *
- * :1:  http://www.latticesemi.com/en/Products/FPGAandCPLD/LatticeXP2.aspx
- * :2:  http://www.renesas.com/products/mpumcu/h8s/h8s2100/h8s2113/index.jsp
- *
  * gmux is a microcontroller built into the MacBook Pro to support dual GPUs:
- * A {1}[Lattice XP2] on pre-retinas, a {2}[Renesas R4F2113] on retinas.
+ * A `Lattice XP2`_ on pre-retinas, a `Renesas R4F2113`_ on retinas.
  *
  * (The MacPro6,1 2013 also has a gmux, however it is unclear why since it has
  * dual GPUs but no built-in display.)
  *
  * gmux is connected to the LPC bus of the southbridge. Its I/O ports are
  * accessed differently depending on the microcontroller: Driver functions
- * to access a pre-retina gmux are infixed `_pio_`, those for a retina gmux
- * are infixed `_index_`.
+ * to access a pre-retina gmux are infixed ``_pio_``, those for a retina gmux
+ * are infixed ``_index_``.
+ *
+ * .. _Lattice XP2:
+ * http://www.latticesemi.com/en/Products/FPGAandCPLD/LatticeXP2.aspx
+ * .. _Renesas R4F2113:
+ * http://www.renesas.com/products/mpumcu/h8s/h8s2100/h8s2113/index.jsp
  */

 struct apple_gmux_data {
@@ -272,15 +274,15 @@ static bool gmux_is_indexed(struct apple_gmux_data 
*gmux_data)
 /**
  * DOC: Backlight control
  *
- * :3:  http://www.ti.com/lit/ds/symlink/lp8543.pdf
- * :4:  http://www.ti.com/lit/ds/symlink/lp8545.pdf
- *
  * On single GPU MacBooks, the PWM signal for the backlight is generated by
  * the GPU. On dual GPU MacBook Pros by contrast, either GPU may be suspended
  * to conserve energy. Hence the PWM signal needs to be generated by a separate
  * backlight driver which is controlled by gmux. The earliest generation
- * MBP5 2008/09 uses a {3}[TI LP8543] backlight driver. All newer models
- * use a {4}[TI LP8545].
+ * MBP5 2008/09 uses a `TI LP8543`_ backlight driver. All newer models
+ * use a `TI LP8545`_.
+ *
+ * .. _TI LP8543: http://www.ti.com/lit/ds/symlink/lp8543.pdf
+ * .. _TI LP8545: http://www.ti.com/lit/ds/symlink/lp8545.pdf
  */

 static int gmux_get_brightness(struct backlight_device *bd)
@@ -312,28 +314,20 @@ static const struct backlight_ops gmux_bl_ops = {
 /**
  * DOC: Graphics mux
  *
- * :5:  http://pimg-fpiw.uspto.gov/fdd/07/870/086/0.pdf
- * :6:  http://www.nxp.com/documents/data_sheet/CBTL06141.pdf
- * :7:  http://www.ti.com/lit/ds/symlink/hd3ss212.pdf
- * :8:  https://www.pericom.com/assets/Datasheets/PI3VDP12412.pdf
- * :9:  http://www.ti.com/lit/ds/symlink/sn74lv4066a.pdf
- * :10: 
http://pdf.datasheetarchive.com/indexerfiles/Datasheets-SW16/DSASW00308511.pdf
- * :11: http://www.ti.com/lit/ds/symlink/ts3ds10224.pdf
- *
  * On pre-retinas, the LVDS outputs of both GPUs feed into gmux which muxes
  * either of them to the panel. One of the tricks gmux has up its sleeve is
  * to lengthen the blanking interval of its output during a switch to
  * synchronize it with the GPU switched to. This allows for a flicker-free
- * switch that is imperceptible by the user ({5}[US 8,687,007 B2]).
+ * switch that is imperceptible by the user (`US 8,687,007 B2`_).
  *
  * On retinas, muxing is no longer done by gmux itself, but by a separate
  * chip which is controlled by gmux. The chip is triple sourced, it is
- * either an {6}[NXP CBTL06142], {7}[TI HD3SS212] or {8}[Pericom PI3VDP12412].
+ * either an `NXP CBTL06142`_, `TI HD3SS212`_ or `Pericom PI3VDP12412`_.
  * The panel is driven with eDP instead of LVDS since the pixel clock
  * required for retina resolution exceeds LVDS' limits.
  *
  * Pre-retinas are able to switch the panel's DDC pins separately.
- * This is handled by a {9}[TI SN74LV4066A] which is controlled by gmux.
+ * This is handled by a `TI SN74LV4066A`_ which is controlled by gmux.
  * The inactive GPU can thus probe the panel's EDID without switching over
  * the entire panel. Retinas lack this functionality as the chips used for
  * eDP muxing are incapable of switching the AUX channel separately (see
@@ -344,15 +338,15 @@ static const struct backlight_ops gmux_bl_ops = {
  *
  * The external DP port is only fully switchable on the first two unibody
  * MacBook Pro generations, MBP5 2008/09 and MBP6 2010. This is done by an
- * {6}[NXP CBTL06141] which is controlled by gmux. It's the predecessor of the
+ * `NXP CBTL06141`_ which is controlled by gmux. It's the predecessor of the
  * eDP mux on retinas, the difference being support for 2.7 versus 5.4 Gbit/s.
  *
  * The following MacBook Pro generations

[Nouveau] [PATCH 2/6] drm/nouveau/core: make use of new strtolower() function

2016-07-04 Thread Alexandre Courbot

On Mon, Jul 4, 2016 at 10:37 AM, Alexandre Courbot  wrote:
> On Sun, Jul 3, 2016 at 12:21 AM, Markus Mayer  
> wrote:
>> On 1 July 2016 at 18:18, Alexandre Courbot  wrote:
>>> On Fri, Jul 1, 2016 at 8:50 AM, Markus Mayer  wrote:
 Call strtolower() rather than walking the string explicitly to convert
 it to lowercase.

 Signed-off-by: Markus Mayer 
 ---
  drivers/gpu/drm/nouveau/nvkm/core/firmware.c | 7 +--
  1 file changed, 1 insertion(+), 6 deletions(-)

 diff --git a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c 
 b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
 index 34ecd4a..c50594c 100644
 --- a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
 +++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
 @@ -36,16 +36,11 @@ nvkm_firmware_get(struct nvkm_device *device, const 
 char *fwname,
  {
 char f[64];
 char cname[16];
 -   int i;

 /* Convert device name to lowercase */
 strncpy(cname, device->chip->name, sizeof(cname));
 cname[sizeof(cname) - 1] = '\0';
 -   i = strlen(cname);
 -   while (i) {
 -   --i;
 -   cname[i] = tolower(cname[i]);
 -   }
 +   strtolower(cname);
>>>
>>> This function doesn't seem to exist as of next-20160701, where have
>>> you found it?
>>
>> I didn't find it. I wrote it, because it didn't exist and I needed it.
>> See: https://lkml.org/lkml/2016/6/30/727 and
>> https://lkml.org/lkml/2016/6/30/733 (cover letter and first patch in
>> series).
>
> Ah, right - would have been easier to understand if you had sent the
> whole series (or at least patches 0 to 2) to us as well. Please do
> that for the next version.

... found patches 0 and 1 in my spam folder, for some weird reason.
Apologies for jumping to conclusions.

[PATCH v7 2/2] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

2016-07-04 Thread Vinay Simha

On Mon, Jul 4, 2016 at 4:22 AM, Emil Velikov  
wrote:
> On 28 June 2016 at 16:59, Vinay Simha  wrote:
>> hi,
>>
>> Any further comments or reviews?
>>
> You still haven't covered my earlier suggestions, as such I cannot
> give you a r-b :-( They are not blockers by any means, but it'll be
> up-to the maintainer to ack/pick this up.
i do have covered the suggestions from you.
As i had mentioned earlier we cannot drop few returns and keep it
void(drm_panel_funcs - unprepare), since drm framework requires
return. if do you have any alternate solution please suggest, will
incorporate.
>
> Thierry ?
>
> Regards,
> Emil



-- 
Regards,

Vinay Simha.B.N.

[PATCH 1/2] drm: Add drm driver for OpenCores VGA/LCD display controller

2016-07-04 Thread Andrea Merello

On Fri, Jun 10, 2016 at 4:27 PM, Daniel Vetter  wrote:
> On Thu, Jun 09, 2016 at 03:32:55PM +0200, Andrea Merello wrote:
>> This driver supports the VGA/LCD core available from OpenCores:
>> http://opencores.org/project,vga_lcd
>>
>> It's intended as a replacement for the "ocfb" framebuffer driver
>>
>> Signed-off-by: Andrea Merello 
>> Cc: Stefan Kristiansson 
>> Cc: Tomi Valkeinen 
>> Cc: Francesco Diotalevi 
>> Cc: Claudio Lorini 
>
> Bunch of comments below, but this driver might be a good candidate for the
> drm_simple_display_pipe helpers that Noralf Tronnes is working on. Would
> allow you to cut down a pile more boilerplate I think. Please take a look.
> I think the only thing you'd need is a new small function to set the
> drm_bridge for the encoder in struct drm_simple_display_pipe

Almost done, but I've got a bunch of:
[drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc
-0] flip_done timed out

I guessed that I needed to send vblank events, but where are vblank
events supposed to be sent when using those new
drm_simple_display_pipe
helpers? (this IP seems to have support for vblank interrupts, but the
ocfb driver don't use it, and I'm unsure if we can assume all
implementations of this IP actually have the irq really attached).

Currently I've done as arcgpu driver does; that means adding
.atomic_begin to drm_crtc_helper_funcs and sending vblank events from
there. But this ends up to be inside drm_simple_kms_helper.c.. And I
guess this could be not ok for all drivers.

Maybe we could add another callback to the
drm_simple_display_pipe_funcs, that ends up to be called from
.atomic_begin (and possibly export a new helper that sends vblank
events, for drivers that don't want to do this by themselves) ?

.. But I'm not really familiar with drm-event stuff (and honestly with
the whole drm subsytem) .. Any advice welcome :)

Andrea

> -Daniel
>
>> ---
>>  drivers/gpu/drm/Kconfig   |   2 +
>>  drivers/gpu/drm/Makefile  |   1 +
>>  drivers/gpu/drm/ocdrm/Kconfig |   7 +
>>  drivers/gpu/drm/ocdrm/Makefile|   7 +
>>  drivers/gpu/drm/ocdrm/ocdrm_crtc.c| 336 
>> ++
>>  drivers/gpu/drm/ocdrm/ocdrm_crtc.h|  48 +
>>  drivers/gpu/drm/ocdrm/ocdrm_drv.c | 312 +++
>>  drivers/gpu/drm/ocdrm/ocdrm_drv.h |  89 +
>>  drivers/gpu/drm/ocdrm/ocdrm_encoder.c |  95 ++
>>  drivers/gpu/drm/ocdrm/ocdrm_encoder.h |  48 +
>>  10 files changed, 945 insertions(+)
>>  create mode 100644 drivers/gpu/drm/ocdrm/Kconfig
>>  create mode 100644 drivers/gpu/drm/ocdrm/Makefile
>>  create mode 100644 drivers/gpu/drm/ocdrm/ocdrm_crtc.c
>>  create mode 100644 drivers/gpu/drm/ocdrm/ocdrm_crtc.h
>>  create mode 100644 drivers/gpu/drm/ocdrm/ocdrm_drv.c
>>  create mode 100644 drivers/gpu/drm/ocdrm/ocdrm_drv.h
>>  create mode 100644 drivers/gpu/drm/ocdrm/ocdrm_encoder.c
>>  create mode 100644 drivers/gpu/drm/ocdrm/ocdrm_encoder.h
>>
>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> index fc35731..48f56e4 100644
>> --- a/drivers/gpu/drm/Kconfig
>> +++ b/drivers/gpu/drm/Kconfig
>> @@ -290,3 +290,5 @@ source "drivers/gpu/drm/arc/Kconfig"
>>  source "drivers/gpu/drm/hisilicon/Kconfig"
>>
>>  source "drivers/gpu/drm/mediatek/Kconfig"
>> +
>> +source "drivers/gpu/drm/ocdrm/Kconfig"
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index be43afb..871da6a 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -82,3 +82,4 @@ obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/
>>  obj-$(CONFIG_DRM_ETNAVIV) += etnaviv/
>>  obj-$(CONFIG_DRM_ARCPGU)+= arc/
>>  obj-y+= hisilicon/
>> +obj-$(CONFIG_DRM_OCDRM) += ocdrm/
>> diff --git a/drivers/gpu/drm/ocdrm/Kconfig b/drivers/gpu/drm/ocdrm/Kconfig
>> new file mode 100644
>> index 000..a918503
>> --- /dev/null
>> +++ b/drivers/gpu/drm/ocdrm/Kconfig
>> @@ -0,0 +1,7 @@
>> +config DRM_OCDRM
>> + tristate "DRM Support for opencores OCFB"
>> + depends on DRM
>> + default n
>> + select DRM_KMS_HELPER
>> + select DRM_KMS_CMA_HELPER
>> + select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
>> diff --git a/drivers/gpu/drm/ocdrm/Makefile b/drivers/gpu/drm/ocdrm/Makefile
>> new file mode 100644
>> index 000..4ea17d2
>> --- /dev/null
>> +++ b/drivers/gpu/drm/ocdrm/Makefile
>> @@ -0,0 +1,7 @@
>> +#
>> +# Makefile for the drm device driver.  This driver provides support for the
>> +# Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
>> +
>> +ocdrm-y := ocdrm_crtc.o ocdrm_drv.o ocdrm_encoder.o
>> +
>> +obj-$(CONFIG_DRM_OCDRM) += ocdrm.o
>> diff --git a/drivers/gpu/drm/ocdrm/ocdrm_crtc.c 
>> b/drivers/gpu/drm/ocdrm/ocdrm_crtc.c
>> new file mode 100644
>> index 000..ebfe03e
>> --- /dev/null
>> +++ b/drivers/gpu/drm/ocdrm/ocdrm_crtc.c
>> @@ -0,0 +1,336 @@
>> +/*
>> + * Open cores VGA/LCD 2.0 core DRM driver
>> + * Copyright (c) 2016 Istituto Italiano

[PATCH 00/31] Move LRU page reclaim from zones to nodes v8

2016-07-04 Thread Mel Gorman

On Mon, Jul 04, 2016 at 05:04:12PM +0900, Minchan Kim wrote:
> > > How big ratio between highmem:lowmem do you think a problem?
> > > 
> > 
> > That's a "how long is a piece of string" type question.  The ratio does
> > not matter as much as whether the workload is both under memory pressure
> > and requires large amounts of lowmem pages. Even on systems with very high
> > ratios, it may not be a problem if HIGHPTE is enabled.
> 
> As well page table, pgd/kernelstack/zbud/slab and so on, every kernel
> allocations wanted to mask __GFP_HIGHMEM off would be a problem in
> 32bit system.
> 

The same point applies -- it depends on the rate of these allocations,
not the ratio of highmem:lowmem per se.

> It also depends on that how many drivers needed lowmem only we have
> in the system.
> 
> I don't know how many such driver in the world. When I simply do grep,
> I found several cases which mask __GFP_HIGHMEM off and among them,
> I guess DRM might be a popular for us. However, it might be really rare
> usecase among various i915 usecases.
> 

It's also perfectly possible that such allocations are long-lived in which
case they are not going to cause many skips. Hence why I cannot make a
general prediction.

> > > > Conceptually, moving to node LRUs should be easier to understand. The
> > > > page allocator plays fewer tricks to game reclaim and reclaim behaves
> > > > similarly on all nodes. 
> > > > 
> > > > The series has been tested on a 16 core UMA machine and a 2-socket 48
> > > > core NUMA machine. The UMA results are presented in most cases as the 
> > > > NUMA
> > > > machine behaved similarly.
> > > 
> > > I guess you would already test below with various highmem system(e.g.,
> > > 2:1, 3:1, 4:1 and so on). If you have, could you mind sharing it?
> > > 
> > 
> > I haven't that data, the baseline distribution used doesn't even have
> > 32-bit support. Even if it was, the results may not be that interesting.
> > The workloads used were not necessarily going to trigger lowmem pressure
> > as HIGHPTE was set on the 32-bit configs.
> 
> That means we didn't test this on 32-bit with highmem.
> 

No. I tested the skip logic and noticed that when forced on purpose that
system CPU usage was higher but it functionally worked.

> I'm not sure it's really too rare case to spend a time for testing.
> In fact, I really want to test all series to our production system
> which is 32bit and highmem but as we know well, most of embedded
> system kernel is rather old so backporting needs lots of time and
> care. However, if we miss testing in those system at the moment,
> we will be suprised after 1~2 years.
> 

It would be appreciated if it could be tested on such platforms if at all
possible. Even if I did set up a 32-bit x86 system, it won't have the same
allocation/reclaim profile as the platforms you are considering.

> I don't know what kinds of benchmark can we can check it so I cannot
> insist on it but you might know it.
> 

One method would be to use fsmark with very large numbers of small files
to force slab to require low memory. It's not representative of many real
workloads unfortunately. Usually such a configuration is for checking the
slab shrinker is working as expected.

> Okay, do you have any idea to fix it if we see such regression report
> in 32-bit system in future?

Two options, neither whose complexity is justified without a "real"
workload to use as a reference.

1. Long-term isolation of highmem pages when reclaim is lowmem

   When pages are skipped, they are immediately added back onto the LRU
   list. If lowmem reclaim persisted for long periods of time, the same
   highmem pages get continually scanned. The idea would be that lowmem
   keeps those pages on a separate list until a reclaim for highmem pages
   arrives that splices the highmem pages back onto the LRU.

   That would reduce the skip rate, the potential corner case is that
   highmem pages have to be scanned and reclaimed to free lowmem slab pages.

2. Linear scan lowmem pages if the initial LRU shrink fails

   This will break LRU ordering but may be preferable and faster during
   memory pressure than skipping LRU pages.

-- 
Mel Gorman
SUSE Labs

[patch] drm/tegra: sor: Double free on error

2016-07-04 Thread Dan Carpenter

"brick" is allocated with devm_kzalloc() so freeing it with kfree()
leads to a double free.  We can just delete it.

Fixes: a7ba8310c7f5 ('drm/tegra: sor: Implement sor1_brick clock')
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 8425eda..e750ced 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -345,7 +345,6 @@ static struct clk *tegra_clk_sor_brick_register(struct 
tegra_sor *sor,
 {
struct tegra_clk_sor_brick *brick;
struct clk_init_data init;
-   struct clk *clk;

brick = devm_kzalloc(sor->dev, sizeof(*brick), GFP_KERNEL);
if (!brick)
@@ -361,11 +360,7 @@ static struct clk *tegra_clk_sor_brick_register(struct 
tegra_sor *sor,

brick->hw.init = 

-   clk = devm_clk_register(sor->dev, >hw);
-   if (IS_ERR(clk))
-   kfree(brick);
-
-   return clk;
+   return devm_clk_register(sor->dev, >hw);
 }

 static int tegra_sor_dp_train_fast(struct tegra_sor *sor,

[PATCH] drm/tegra: fix error handling

2016-07-04 Thread Alexandre Courbot

On Sun, Jul 3, 2016 at 3:18 PM, Christophe JAILLET
 wrote:
> This is likely that checking 'gr3d->clk_secondary' instead of 'gr3d->clk'
> is expected here.

Very likely indeed.

Reviewed-by: Alexandre Courbot 

Thanks!

[Nouveau] [PATCH 2/6] drm/nouveau/core: make use of new strtolower() function

2016-07-04 Thread Alexandre Courbot

On Sun, Jul 3, 2016 at 12:21 AM, Markus Mayer  
wrote:
> On 1 July 2016 at 18:18, Alexandre Courbot  wrote:
>> On Fri, Jul 1, 2016 at 8:50 AM, Markus Mayer  wrote:
>>> Call strtolower() rather than walking the string explicitly to convert
>>> it to lowercase.
>>>
>>> Signed-off-by: Markus Mayer 
>>> ---
>>>  drivers/gpu/drm/nouveau/nvkm/core/firmware.c | 7 +--
>>>  1 file changed, 1 insertion(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c 
>>> b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
>>> index 34ecd4a..c50594c 100644
>>> --- a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
>>> +++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
>>> @@ -36,16 +36,11 @@ nvkm_firmware_get(struct nvkm_device *device, const 
>>> char *fwname,
>>>  {
>>> char f[64];
>>> char cname[16];
>>> -   int i;
>>>
>>> /* Convert device name to lowercase */
>>> strncpy(cname, device->chip->name, sizeof(cname));
>>> cname[sizeof(cname) - 1] = '\0';
>>> -   i = strlen(cname);
>>> -   while (i) {
>>> -   --i;
>>> -   cname[i] = tolower(cname[i]);
>>> -   }
>>> +   strtolower(cname);
>>
>> This function doesn't seem to exist as of next-20160701, where have
>> you found it?
>
> I didn't find it. I wrote it, because it didn't exist and I needed it.
> See: https://lkml.org/lkml/2016/6/30/727 and
> https://lkml.org/lkml/2016/6/30/733 (cover letter and first patch in
> series).

Ah, right - would have been easier to understand if you had sent the
whole series (or at least patches 0 to 2) to us as well. Please do
that for the next version.

[PATCH 1/2] drm/amdgpu: remove unneeded conversions to bool

2016-07-04 Thread Christian König

Am 01.07.2016 um 16:22 schrieb Andrew F. Davis:
> Found with scripts/coccinelle/misc/boolconv.cocci.
>
> Signed-off-by: Andrew F. Davis 

For both patches Reviewed-by: Christian KÃ¶nig .

> ---
>   drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  8 
>   drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  4 ++--
>   drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c |  4 ++--
>   drivers/gpu/drm/amd/amdgpu/vi.c| 14 +++---
>   4 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index 1a5cbaf..f3c8c37 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -5144,13 +5144,13 @@ static int gfx_v8_0_set_powergating_state(void 
> *handle,
>   case CHIP_POLARIS11:
>   if (adev->pg_flags & AMD_PG_SUPPORT_GFX_SMG)
>   polaris11_enable_gfx_static_mg_power_gating(adev,
> - state == AMD_PG_STATE_GATE ? true : 
> false);
> + state == AMD_PG_STATE_GATE);
>   else if (adev->pg_flags & AMD_PG_SUPPORT_GFX_DMG)
>   polaris11_enable_gfx_dynamic_mg_power_gating(adev,
> - state == AMD_PG_STATE_GATE ? true : 
> false);
> + state == AMD_PG_STATE_GATE);
>   else
>   polaris11_enable_gfx_quick_mg_power_gating(adev,
> - state == AMD_PG_STATE_GATE ? true : 
> false);
> + state == AMD_PG_STATE_GATE);
>   break;
>   default:
>   break;
> @@ -5583,7 +5583,7 @@ static int gfx_v8_0_set_clockgating_state(void *handle,
>   case CHIP_CARRIZO:
>   case CHIP_STONEY:
>   gfx_v8_0_update_gfx_clock_gating(adev,
> -  state == AMD_CG_STATE_GATE ? 
> true : false);
> +  state == AMD_CG_STATE_GATE);
>   break;
>   default:
>   break;
> diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> index 9945d5b..6c3c730 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c
> @@ -1406,9 +1406,9 @@ static int gmc_v8_0_set_clockgating_state(void *handle,
>   switch (adev->asic_type) {
>   case CHIP_FIJI:
>   fiji_update_mc_medium_grain_clock_gating(adev,
> - state == AMD_CG_STATE_GATE ? true : false);
> + state == AMD_CG_STATE_GATE);
>   fiji_update_mc_light_sleep(adev,
> - state == AMD_CG_STATE_GATE ? true : false);
> + state == AMD_CG_STATE_GATE);
>   break;
>   default:
>   break;
> diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c 
> b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> index 532ea88..e57cab6 100644
> --- a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> @@ -1547,9 +1547,9 @@ static int sdma_v3_0_set_clockgating_state(void *handle,
>   case CHIP_CARRIZO:
>   case CHIP_STONEY:
>   sdma_v3_0_update_sdma_medium_grain_clock_gating(adev,
> - state == AMD_CG_STATE_GATE ? true : false);
> + state == AMD_CG_STATE_GATE);
>   sdma_v3_0_update_sdma_medium_grain_light_sleep(adev,
> - state == AMD_CG_STATE_GATE ? true : false);
> + state == AMD_CG_STATE_GATE);
>   break;
>   default:
>   break;
> diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
> index a65c960..d3404ef 100644
> --- a/drivers/gpu/drm/amd/amdgpu/vi.c
> +++ b/drivers/gpu/drm/amd/amdgpu/vi.c
> @@ -1393,22 +1393,22 @@ static int vi_common_set_clockgating_state(void 
> *handle,
>   switch (adev->asic_type) {
>   case CHIP_FIJI:
>   vi_update_bif_medium_grain_light_sleep(adev,
> - state == AMD_CG_STATE_GATE ? true : false);
> + state == AMD_CG_STATE_GATE);
>   vi_update_hdp_medium_grain_clock_gating(adev,
> - state == AMD_CG_STATE_GATE ? true : false);
> + state == AMD_CG_STATE_GATE);
>   vi_update_hdp_light_sleep(adev,
> - state == AMD_CG_STATE_GATE ? true : false);
> + state == AMD_CG_STATE_GATE);
>   vi_update_rom_medium_grain_clock_gating(adev,
> - state == AMD_CG_STATE_GATE ? true : false);
> + state == AMD_CG_STATE_GATE);
>   break;
>   case CHIP_CARRIZO:
>   case CHIP_STONEY:
>

[Bug 96678] Awesomenauts cannot launch AMD PITCAIRN

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #6 from Joost van Dongen  ---
Joost here, lead programmer on Awesomenauts. Based on these logs it seems like
a driver problem since the crash is in an extremely early part of our OpenGL
code, before we do anything exciting. Also, nothing recently changed in that
part of our OpenGL code.

I'm not a Linux expert myself but it seems like you might not be running
proprietary AMD drivers or something like that? Maybe try other drivers?

Based on these logs the crash is somewhere in this bit of code:

GLint swapInterval = 0;
switch (interval)
{
case VSI_ONE:   swapInterval = 1;   break;
case VSI_TWO:   swapInterval = 2;   break;
case VSI_NONE:
default:   
break;
}   
if (GLXEW_EXT_swap_control)
{
glXSwapIntervalEXT(glXGetCurrentDisplay(),
glXGetCurrentDrawable(), swapInterval);
}
else if (GLXEW_SGI_swap_control)
{
glXSwapIntervalSGI(swapInterval);
}

glViewport(0, 0, windowWidth, windowHeight);
glScissor(0, 0, windowWidth, windowHeight);
glClearColor(0.f, 0.f, 0.f, 0.f);
glEnable(GL_DEPTH_TEST);

// perform an initial rendering to clear the screen on startup
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT |
GL_STENCIL_BUFFER_BIT);
SDL_GL_SwapBuffers();

glDisable(GL_CULL_FACE);
glDisable(GL_DEPTH_TEST);

I don't see any shader code here so if the problem is that a shader isn't
compiling then maybe glClear generates a basic shader to perform the clear, and
fails at that?

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

[Bug 96790] frame stuttering in ut2004

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #8 from network723 at rkmail.ru ---
Created attachment 124891
  --> https://bugs.freedesktop.org/attachment.cgi?id=124891=edit
screenshot

This is closest I could get. Taking the screenshot was a bit tricky. Looks like
GALLIUM_HUD update time is to low to detect fps drops. You can see it in
in-game counter "cur_fps" when it gets violet, but it's almost impossible to
take a screenshot exactly in that moment.

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

[Bug 96790] frame stuttering in ut2004

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #7 from Michel DÃ¤nzer  ---
Can you run the game with the environment variable


GALLIUM_HUD=fps,requested-VRAM+VRAM-usage,requested-GTT+GTT-usage,cpu+temperature+GPU-load,num-bytes-moved,buffer-wait-time,num-compilations+num-shaders-created

, grab a screenshot within a minute of the framerate dropping below 30 fps, and
attach it here?

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

[Bug 96790] frame stuttering in ut2004

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #6 from network723 at rkmail.ru ---
radeon kernel module was patched to provide everything needed for OpenGL
4.3/compute shader. If you want, I may test with vanilla kernel.

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

[Bug 96790] frame stuttering in ut2004

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #5 from network723 at rkmail.ru ---
Created attachment 124887
  --> https://bugs.freedesktop.org/attachment.cgi?id=124887=edit
lspci

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

[Bug 96790] frame stuttering in ut2004

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #4 from network723 at rkmail.ru ---
Created attachment 124886
  --> https://bugs.freedesktop.org/attachment.cgi?id=124886=edit
glxinfo

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

[Bug 96790] frame stuttering in ut2004

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #3 from network723 at rkmail.ru ---
Created attachment 124885
  --> https://bugs.freedesktop.org/attachment.cgi?id=124885=edit
Xorg.log

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

[Bug 96790] frame stuttering in ut2004

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #2 from network723 at rkmail.ru ---
Created attachment 124884
  --> https://bugs.freedesktop.org/attachment.cgi?id=124884=edit
dmesg

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

[git pull] vmwgfx-fixes

2016-07-04 Thread Sinclair Yeh

Hi Dave,

The following changes since commit 81e257e964268d050f8e9188becd44d50f241d72:

  drm/atomic: Make drm_atomic_legacy_backoff reset crtc->acquire_ctx 
(2016-06-24 11:10:36 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~syeh/repos_linux drm-vmwgfx-fixes

for you to fetch changes up to beca4cf55323147ca9c8a98de1871be6e4fe8f34:

  drm/vmwgfx: Fix corner case screen target management (2016-07-01 10:47:51 
-0700)


Sinclair Yeh (6):
  drm/vmwgfx: Add a check to handle host message failure
  drm/vmwgfx: Work around mode set failure in 2D VMs
  drm/vmwgfx: Add an option to change assumed FB bpp
  drm/ttm: Make ttm_bo_mem_compat available
  drm/vmwgfx: Check pin count before attempting to move a buffer
  drm/vmwgfx: Delay pinning fbdev framebuffer until after mode set

Thomas Hellstrom (1):
  drm/vmwgfx: Fix corner case screen target management

 drivers/gpu/drm/ttm/ttm_bo.c   |  7 ---
 drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c | 25 ++---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c| 12 
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h|  1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 47 
+--
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 10 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_msg.c|  3 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c   |  8 
 include/drm/ttm/ttm_bo_api.h   | 14 ++
 9 files changed, 88 insertions(+), 39 deletions(-)

[Bug 80419] XCOM: Enemy Unknown Causes lockup

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #137 from Nicolai HÃ¤hnle  ---
Nothing that I'm aware of. May have been just luck...

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

[Bug 96790] frame stuttering in ut2004

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #1 from Michel DÃ¤nzer  ---
Please attach the corresponding Xorg log file and output of glxinfo and dmesg.

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

[Bug 96768] Black screen past login with RX 480, Ubuntu 16.04 and AMDgpu-pro 16.30

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

Michel DÃ¤nzer  changed:

   What|Removed |Added

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

--- Comment #1 from Michel DÃ¤nzer  ---
>From what I read on the Phoronix forums, this happens because some COGL shaders
fail to compile. So it's a bug in either COGL or the AMDGPU-PRO OpenGL driver.
In neither case is this the appropriate place to track it.

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

[Bug 96678] Awesomenauts cannot launch AMD PITCAIRN

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

Quentin Quaadgras  changed:

   What|Removed |Added

 Attachment #124880|0   |1
is obsolete||

--- Comment #5 from Quentin Quaadgras  ---
Created attachment 124881
  --> https://bugs.freedesktop.org/attachment.cgi?id=124881=edit
Padoka with R600_DEBUG set

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

[Bug 96678] Awesomenauts cannot launch AMD PITCAIRN

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #4 from Quentin Quaadgras  ---
Comment on attachment 124880
  --> https://bugs.freedesktop.org/attachment.cgi?id=124880
Padoka with R600_DEBUG set

SystemManager constructor starts
SystemManager constructor ends
Start SSL initialise
End SSL initialise
Checking current matchmaking beta state
SDLWindowAndEventManager constructor starts
Game version:  Version 3.1.5a
SDLWindowAndEventManager constructor ends
SDLWindowAndEventManager::run() starts
SDLWindowAndEventManager::createWindow() starts
LoadBinaryFile: "Data/Config.txt"
[Config]  Input:  version  =  2
[Config]  Input:  resolutionx  =  1920
[Config]  Input:  resolutiony  =  1080
[Config]  Input:  windowmode  =  windowed
[Config]  Input:  texturequality  =  low
[Config]  Input:  vsync  =  off
[Config]  Input:  backgroundquality  =  low
[Config]  Input:  sharpen  =  off
[Config]  Input:  multithreading  =  off
[Config]  Input:  supersampling  =  off
[Config]  xRes:  1920  yRes:  1080  textureQuality:  LOW  windowMode:  windowed
[Config]  vSyncEnabled:  0
[Config]  sharpen:  0  supersampling:  0  backgroundQuality  LOW 
multithreading  0
GraphicsQualityHandler constructor starts
GraphicsQualityHandler constructor ends
GraphicsQualityHandler::setBackgroundsQuality switches from  MEDIUM  to  LOW
SDL_SetVideoMode starts
SDL_SetVideoMode ends
Resolution of actual screen:  1920  1080
unbindGLFromCallingThread starts, threadID:  4119840704
unbindGLFromCallingThread ends
SDLWindowAndEventManager::createWindow() ends
GameLoop constructor starts
Constructor of SteamLinuxSingleGameInstanceEnforcer starts
Main Thread ID is  3800734528
Thread that calls SceneManager::render Thread ID is  3800734528
SceneManager constructor starts
RenderThreadManager constructor starts
StatisticsManager constructor starts
StatisticsManager constructor ends
bindGLToCallingThread starts, threadID:  3800734528
bindGLToCallingThread ends
Renderer constructor starts
Renderer constructor ends
ShaderBasedRenderer constructor starts
ShaderBasedRenderer constructor ends
GLRenderer constructor starts
GLRenderer constructor ends
PCMacRenderer constructor starts
PCMacRenderer constructor ends
LinuxRenderer constructor starts
LinuxRenderer constructor ends
PCMacRenderer::initialise starts
OpenGL GL_VENDOR  X.Org
OpenGL GL_RENDERER  Gallium 0.4 on AMD PITCAIRN (DRM 2.43.0 / 4.4.0-28-generic,
LLVM 3.9.0)
OpenGL GL_VERSION  3.0 Mesa 12.1.0-devel - padoka PPA (git-d8d6091)
OpenGL GL_EXTENSIONS  GL_ARB_multisample GL_EXT_abgr GL_EXT_bgra
GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract
GL_EXT_copy_texture GL_EXT_polygon_offset GL_EXT_subtexture
GL_EXT_texture_object GL_EXT_vertex_array GL_EXT_compiled_vertex_array
GL_EXT_texture GL_EXT_texture3D GL_IBM_rasterpos_clip GL_ARB_point_parameters
GL_EXT_draw_range_elements GL_EXT_packed_pixels GL_EXT_point_parameters
GL_EXT_rescale_normal GL_EXT_separate_specular_color GL_EXT_texture_edge_clamp
GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp
GL_SGIS_texture_lod GL_ARB_framebuffer_sRGB GL_ARB_multitexture
GL_EXT_framebuffer_sRGB GL_IBM_multimode_draw_arrays
GL_IBM_texture_mirrored_repeat GL_ARB_texture_cube_map GL_ARB_texture_env_add
GL_ARB_transpose_matrix GL_EXT_blend_func_separate GL_EXT_fog_coord
GL_EXT_multi_draw_arrays GL_EXT_secondary_color GL_EXT_texture_env_add
GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias
GL_INGR_blend_func_separate GL_NV_blend_square GL_NV_light_max_exponent
GL_NV_texgen_reflection GL_NV_texture_env_combine4 GL_S3_s3tc
GL_SUN_multi_draw_arrays GL_ARB_texture_border_clamp GL_ARB_texture_compression
GL_EXT_framebuffer_object GL_EXT_texture_compression_s3tc
GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_MESA_window_pos
GL_NV_packed_depth_stencil GL_NV_texture_rectangle GL_ARB_depth_texture
GL_ARB_occlusion_query GL_ARB_shadow GL_ARB_texture_env_combine
GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3
GL_ARB_texture_mirrored_repeat GL_ARB_window_pos GL_ATI_fragment_shader
GL_EXT_stencil_two_side GL_EXT_texture_cube_map GL_NV_depth_clamp
GL_NV_fog_distance GL_APPLE_packed_pixels GL_APPLE_vertex_array_object
GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_shader
GL_ARB_shader_objects GL_ARB_vertex_program GL_ARB_vertex_shader
GL_ATI_draw_buffers GL_ATI_texture_env_combine3 GL_ATI_texture_float
GL_EXT_depth_bounds_test GL_EXT_shadow_funcs GL_EXT_stencil_wrap
GL_MESA_pack_invert GL_NV_primitive_restart GL_ARB_depth_clamp
GL_ARB_fragment_program_shadow GL_ARB_half_float_pixel GL_ARB_occlusion_query2
GL_ARB_point_sprite GL_ARB_shading_language_100 GL_ARB_sync
GL_ARB_texture_non_power_of_two GL_ARB_vertex_buffer_object
GL_ATI_blend_equation_separate GL_EXT_blend_equation_separate
GL_OES_read_format GL_ARB_color_buffer_float GL_ARB_pixel_buffer_object
GL_ARB_texture_compression_rgtc GL_ARB_texture_float GL_ARB_texture_rectangle
GL_ATI_texture_compression_3dc GL_EXT_packed_float GL_EXT_pixel_buffer_object

[Bug 96678] Awesomenauts cannot launch AMD PITCAIRN

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #3 from Quentin Quaadgras  ---
(In reply to Nicolai HÃ¤hnle from comment #1)
> This is a crash while compiling a shader.
> 
> Could you please check whether the crash also occurs with latest LLVM? The
> padoka PPA has it. If it does, please provide the output with the
> environment variable R600_DEBUG=ps,vs,gs,tes,tcs,cs set.

I added the trace of the crash with the version of mesa and LLVM in the Padoka
PPA.
There does not appear to be any difference.

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

[Bug 96678] Awesomenauts cannot launch AMD PITCAIRN

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #2 from Quentin Quaadgras  ---
Created attachment 124880
  --> https://bugs.freedesktop.org/attachment.cgi?id=124880=edit
Padoka with R600_DEBUG set

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

[Bug 96794] VM_CONTEXT1_PROTECTION_FAULT_ADDR

2016-07-04 Thread bugzilla-dae...@freedesktop.org

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

--- Comment #1 from Michel DÃ¤nzer  ---
Could be bug 96731.

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

[Bug 119631] RadeonSI get a huge performance dip with used with the nine state tracker

2016-07-04 Thread bugzilla-dae...@bugzilla.kernel.org

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

--- Comment #16 from Michel DÃ¤nzer  ---
(In reply to Thorsten Leemhuis from comment #15)
> What's the status of this issue? Just wondering, as this issue is listed
> in my regression reports for 4.7 [...]

This isn't a kernel regression. It's a Wine/nine issue.

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

[PATCH v7 2/2] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel

2016-07-04 Thread Emil Velikov

On 28 June 2016 at 16:59, Vinay Simha  wrote:
> hi,
>
> Any further comments or reviews?
>
You still haven't covered my earlier suggestions, as such I cannot
give you a r-b :-( They are not blockers by any means, but it'll be
up-to the maintainer to ack/pick this up.

Thierry ?

Regards,
Emil

[GIT PULL] drm/mediatek: MT8173 gamma & dither support

2016-07-04 Thread Emil Velikov

Hi Bibby,

On 27 June 2016 at 12:29, Bibby Hsieh  wrote:
> On Mon, 2016-06-27 at 12:20 +0200, Matthias Brugger wrote:
>>
>> On 06/24/2016 09:27 AM, Bibby Hsieh wrote:
>> > Hi Dave,
>> >
>> > Please consider merging this tag, which contains the v2 MT8173 gamma & 
>> > dither function patches I sent on 2016-06-17, rebased onto v4.7-rc1. There 
>> > have been no further comments.
>> >
>> > Thanks
>> > Bibby
>> >
>> > The following changes since commit 
>> > 1a695a905c18548062509178b98bc91e67510864:
>> >
>> >   Linux 4.7-rc1 (2016-05-29 16:29:24 GMT)
>> >
>> > are available in the git repository at:
>> >
>> >   git at github.com:BibbyHsieh/linux4.7-rc1.git
>> >
>> > for you to fetch changes up to dd0eb773bc125f5e6bca735d19c08500dc3730f9:
>> >
>> >   drm/mediatek: Add gamma correction
>> >
>> > -
>>
>> As far as I can see, your branch has 3 patches on top from Eddie. It
>> seems to me as if you didn't send your patches to the mailinglist before?
>> Anyway this branch does not fulfill the rules to get merged into the
>> linux kernel.
>>
>> Why do you send a pull request? The normal process is to send the
>> patches via email and if the maintainer wants you can send a pull
>> request once the patches are ready to be merged.
>>
>> Regards,
>> Matthias
>>
>
> I sent v1 and v2 on 2016-06-14 and 06-17 respectively [0-8].
> After I made some modifications according to Daniel Vetter's comments,
> there had been no further comments and I sent the pull request as the
> other sub-sys.
>
> I'm sorry for my mistake, I will re-arrange the tree for upstream.
> Next time, I will check with maintainer by email first, and sent the
> pull request.
>
It might be a bit hard to find out who's the maintainer considering
MAINTAINERS has no entry for this driver.

Looking at how things are going Philipp Zabel will be the more likely
person for the task, yet I would be nice if someone from the Mediatek
squad is helping him out - CK Hu perhaps ?

Regards,
Emil

95 matches

Mail list logo