[PATCH 9/9] drm/amdgpu: update version for timeline syncobj support in amdgpu

[Chunming Zhou]

Signed-off-by: Chunming Zhou 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 8a0732088640..4d8db87048d3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -74,9 +74,10 @@
  * - 3.28.0 - Add AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIES
  * - 3.29.0 - Add AMDGPU_IB_FLAG_RESET_GDS_MAX_WAVE_ID
  * - 3.30.0 - Add AMDGPU_SCHED_OP_CONTEXT_PRIORITY_OVERRIDE.
+ * - 3.31.0 - Add syncobj timeline support to AMDGPU_CS.
  */
 #define KMS_DRIVER_MAJOR   3
-#define KMS_DRIVER_MINOR   30
+#define KMS_DRIVER_MINOR   31
 #define KMS_DRIVER_PATCHLEVEL  0
 
 int amdgpu_vram_limit = 0;
-- 
2.17.1

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

[PATCH 8/9] drm/syncobj: add timeline signal ioctl for syncobj v4

[Chunming Zhou]

v2: individually allocate chain array, since chain node is free independently.
v3: all existing points must be already signaled before cpu perform signal 
operation,
so add check condition for that.
v4: remove v3 change and add checking to prevent out-of-order

Signed-off-by: Chunming Zhou 
Cc: Tobias Hector 
Cc: Jason Ekstrand 
Cc: Dave Airlie 
Cc: Chris Wilson 
Cc: Lionel Landwerlin 
---
 drivers/gpu/drm/drm_internal.h |  2 +
 drivers/gpu/drm/drm_ioctl.c|  2 +
 drivers/gpu/drm/drm_syncobj.c  | 93 ++
 include/uapi/drm/drm.h |  1 +
 4 files changed, 98 insertions(+)

diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index dd11ae5f1eef..d9a483a5fce0 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -190,6 +190,8 @@ int drm_syncobj_reset_ioctl(struct drm_device *dev, void 
*data,
struct drm_file *file_private);
 int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file_private);
+int drm_syncobj_timeline_signal_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
 int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
 
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 92b3b7b2fd81..d337f161909c 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -696,6 +696,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL, drm_syncobj_signal_ioctl,
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL, 
drm_syncobj_timeline_signal_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_QUERY, drm_syncobj_query_ioctl,
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE, drm_crtc_get_sequence_ioctl, 
DRM_UNLOCKED),
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index ee2d66e047e7..a3702c75fd1e 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1183,6 +1183,99 @@ drm_syncobj_signal_ioctl(struct drm_device *dev, void 
*data,
return ret;
 }
 
+int
+drm_syncobj_timeline_signal_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private)
+{
+   struct drm_syncobj_timeline_array *args = data;
+   struct drm_syncobj **syncobjs;
+   struct dma_fence_chain **chains;
+   uint64_t *points;
+   uint32_t i, j, timeline_count = 0;
+   int ret;
+
+   if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   return -EOPNOTSUPP;
+
+   if (args->pad != 0)
+   return -EINVAL;
+
+   if (args->count_handles == 0)
+   return -EINVAL;
+
+   ret = drm_syncobj_array_find(file_private,
+u64_to_user_ptr(args->handles),
+args->count_handles,
+);
+   if (ret < 0)
+   return ret;
+
+   points = kmalloc_array(args->count_handles, sizeof(*points),
+  GFP_KERNEL);
+   if (!points) {
+   ret = -ENOMEM;
+   goto out;
+   }
+   if (!u64_to_user_ptr(args->points)) {
+   memset(points, 0, args->count_handles * sizeof(uint64_t));
+   } else if (copy_from_user(points, u64_to_user_ptr(args->points),
+ sizeof(uint64_t) * args->count_handles)) {
+   ret = -EFAULT;
+   goto err_points;
+   }
+
+   for (i = 0; i < args->count_handles; i++) {
+   struct dma_fence_chain *chain;
+   struct dma_fence *fence;
+
+   fence = drm_syncobj_fence_get(syncobjs[i]);
+   chain = to_dma_fence_chain(fence);
+   if (chain) {
+   if (points[i] <= fence->seqno) {
+   DRM_ERROR("signal point canot be 
out-of-order!\n");
+   ret = -EPERM;
+   goto err_points;
+   }
+   }
+   if (points[i])
+   timeline_count++;
+   }
+
+   chains = kmalloc_array(timeline_count, sizeof(void *), GFP_KERNEL);
+   if (!chains) {
+   ret = -ENOMEM;
+   goto err_points;
+   }
+   for (i = 0; i < timeline_count; i++) {
+   chains[i] = kzalloc(sizeof(struct dma_fence_chain), GFP_KERNEL);
+   if (!chains[i]) {
+   for (j = 0; j < i; j++)
+   kfree(chains[j]);
+   ret = -ENOMEM;
+ 

[PATCH 6/9] drm/amdgpu: add timeline support in amdgpu CS v3

[Chunming Zhou]

syncobj wait/signal operation is appending in command submission.
v2: separate to two kinds in/out_deps functions
v3: fix checking for timeline syncobj

Signed-off-by: Chunming Zhou 
Cc: Tobias Hector 
Cc: Jason Ekstrand 
Cc: Dave Airlie 
Cc: Chris Wilson 
Cc: Lionel Landwerlin 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h|  10 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 152 +
 include/uapi/drm/amdgpu_drm.h  |   8 ++
 3 files changed, 144 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 8d0d7f3dd5fb..deec2c796253 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -433,6 +433,12 @@ struct amdgpu_cs_chunk {
void*kdata;
 };
 
+struct amdgpu_cs_post_dep {
+   struct drm_syncobj *syncobj;
+   struct dma_fence_chain *chain;
+   u64 point;
+};
+
 struct amdgpu_cs_parser {
struct amdgpu_device*adev;
struct drm_file *filp;
@@ -462,8 +468,8 @@ struct amdgpu_cs_parser {
/* user fence */
struct amdgpu_bo_list_entry uf_entry;
 
-   unsigned num_post_dep_syncobjs;
-   struct drm_syncobj **post_dep_syncobjs;
+   unsignednum_post_deps;
+   struct amdgpu_cs_post_dep   *post_deps;
 };
 
 static inline u32 amdgpu_get_ib_value(struct amdgpu_cs_parser *p,
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 52a5e4fdc95b..2f6239b6be6f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -215,6 +215,8 @@ static int amdgpu_cs_parser_init(struct amdgpu_cs_parser 
*p, union drm_amdgpu_cs
case AMDGPU_CHUNK_ID_SYNCOBJ_IN:
case AMDGPU_CHUNK_ID_SYNCOBJ_OUT:
case AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIES:
+   case AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_WAIT:
+   case AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_SIGNAL:
break;
 
default:
@@ -804,9 +806,11 @@ static void amdgpu_cs_parser_fini(struct amdgpu_cs_parser 
*parser, int error,
ttm_eu_backoff_reservation(>ticket,
   >validated);
 
-   for (i = 0; i < parser->num_post_dep_syncobjs; i++)
-   drm_syncobj_put(parser->post_dep_syncobjs[i]);
-   kfree(parser->post_dep_syncobjs);
+   for (i = 0; i < parser->num_post_deps; i++) {
+   drm_syncobj_put(parser->post_deps[i].syncobj);
+   kfree(parser->post_deps[i].chain);
+   }
+   kfree(parser->post_deps);
 
dma_fence_put(parser->fence);
 
@@ -1117,13 +1121,18 @@ static int amdgpu_cs_process_fence_dep(struct 
amdgpu_cs_parser *p,
 }
 
 static int amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
-uint32_t handle)
+uint32_t handle, u64 point,
+u64 flags)
 {
-   int r;
struct dma_fence *fence;
-   r = drm_syncobj_find_fence(p->filp, handle, 0, 0, );
-   if (r)
+   int r;
+
+   r = drm_syncobj_find_fence(p->filp, handle, point, flags, );
+   if (r) {
+   DRM_ERROR("syncobj %u failed to find fence @ %llu (%d)!\n",
+ handle, point, r);
return r;
+   }
 
r = amdgpu_sync_fence(p->adev, >job->sync, fence, true);
dma_fence_put(fence);
@@ -1134,46 +1143,118 @@ static int 
amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
 static int amdgpu_cs_process_syncobj_in_dep(struct amdgpu_cs_parser *p,
struct amdgpu_cs_chunk *chunk)
 {
+   struct drm_amdgpu_cs_chunk_sem *deps;
unsigned num_deps;
int i, r;
-   struct drm_amdgpu_cs_chunk_sem *deps;
 
deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
num_deps = chunk->length_dw * 4 /
sizeof(struct drm_amdgpu_cs_chunk_sem);
+   for (i = 0; i < num_deps; ++i) {
+   r = amdgpu_syncobj_lookup_and_add_to_sync(p, deps[i].handle,
+ 0, 0);
+   if (r)
+   return r;
+   }
+
+   return 0;
+}
+
 
+static int amdgpu_cs_process_syncobj_timeline_in_dep(struct amdgpu_cs_parser 
*p,
+struct amdgpu_cs_chunk 
*chunk)
+{
+   struct drm_amdgpu_cs_chunk_syncobj *syncobj_deps;
+   unsigned num_deps;
+   int i, r;
+
+   syncobj_deps = (struct drm_amdgpu_cs_chunk_syncobj *)chunk->kdata;
+   num_deps = chunk->length_dw * 4 /
+   sizeof(struct drm_amdgpu_cs_chunk_syncobj);
for (i = 0; i < num_deps; ++i) {
-   r = amdgpu_syncobj_lookup_and_add_to_sync(p, deps[i].handle);

[PATCH 4/9] drm/syncobj: add timeline payload query ioctl v6

[Chunming Zhou]

user mode can query timeline payload.
v2: check return value of copy_to_user
v3: handle querying entry by entry
v4: rebase on new chain container, simplify interface
v5: query last signaled timeline point, not last point.
v6: add unorder point check

Signed-off-by: Chunming Zhou 
Cc: Tobias Hector 
Cc: Jason Ekstrand 
Cc: Dave Airlie 
Cc: Chris Wilson 
Cc: Lionel Landwerlin 
---
 drivers/gpu/drm/drm_internal.h |  2 ++
 drivers/gpu/drm/drm_ioctl.c|  2 ++
 drivers/gpu/drm/drm_syncobj.c  | 62 ++
 include/uapi/drm/drm.h | 10 ++
 4 files changed, 76 insertions(+)

diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 331ac6225b58..695179bb88dc 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -188,6 +188,8 @@ int drm_syncobj_reset_ioctl(struct drm_device *dev, void 
*data,
struct drm_file *file_private);
 int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file_private);
+int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *file_private);
 
 /* drm_framebuffer.c */
 void drm_framebuffer_print_info(struct drm_printer *p, unsigned int indent,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index c984654646fa..7a534c184e52 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -694,6 +694,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL, drm_syncobj_signal_ioctl,
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_QUERY, drm_syncobj_query_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE, drm_crtc_get_sequence_ioctl, 
DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_CRTC_QUEUE_SEQUENCE, 
drm_crtc_queue_sequence_ioctl, DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_LEASE, drm_mode_create_lease_ioctl, 
DRM_MASTER|DRM_UNLOCKED),
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index eae51978cda4..0e62a793c8dd 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1064,3 +1064,65 @@ drm_syncobj_signal_ioctl(struct drm_device *dev, void 
*data,
 
return ret;
 }
+
+int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *file_private)
+{
+   struct drm_syncobj_timeline_array *args = data;
+   struct drm_syncobj **syncobjs;
+   uint64_t __user *points = u64_to_user_ptr(args->points);
+   uint32_t i;
+   int ret;
+
+   if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   return -ENODEV;
+
+   if (args->pad != 0)
+   return -EINVAL;
+
+   if (args->count_handles == 0)
+   return -EINVAL;
+
+   ret = drm_syncobj_array_find(file_private,
+u64_to_user_ptr(args->handles),
+args->count_handles,
+);
+   if (ret < 0)
+   return ret;
+
+   for (i = 0; i < args->count_handles; i++) {
+   struct dma_fence_chain *chain;
+   struct dma_fence *fence;
+   uint64_t point;
+
+   fence = drm_syncobj_fence_get(syncobjs[i]);
+   chain = to_dma_fence_chain(fence);
+   if (chain) {
+   struct dma_fence *iter, *last_signaled = NULL;
+
+   dma_fence_chain_for_each(iter, fence) {
+   if (!iter)
+   break;
+   dma_fence_put(last_signaled);
+   last_signaled = dma_fence_get(iter);
+   if 
(!to_dma_fence_chain(last_signaled)->prev_seqno)
+   /* It is most likely that timeline has
+* unorder points. */
+   break;
+   }
+   point = dma_fence_is_signaled(last_signaled) ?
+   last_signaled->seqno :
+   to_dma_fence_chain(last_signaled)->prev_seqno;
+   dma_fence_put(last_signaled);
+   } else {
+   point = 0;
+   }
+   ret = copy_to_user([i], , sizeof(uint64_t));
+   ret = ret ? -EFAULT : 0;
+   if (ret)
+   break;
+   }
+   drm_syncobj_array_free(syncobjs, args->count_handles);
+
+   return ret;
+}
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 44ebcdd9bd1d..c62be0840ba5 100644
--- a/include/uapi/drm/drm.h
+++ 

[PATCH 5/9] drm/syncobj: use the timeline point in drm_syncobj_find_fence v4

[Chunming Zhou]

From: Christian König 

Implement finding the right timeline point in drm_syncobj_find_fence.

v2: return -EINVAL when the point is not submitted yet.
v3: fix reference counting bug, add flags handling as well
v4: add timeout for find fence

Signed-off-by: Christian König 
Cc: Lionel Landwerlin 
---
 drivers/gpu/drm/drm_syncobj.c | 50 ---
 1 file changed, 47 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 0e62a793c8dd..087fd4e7eaf3 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -213,6 +213,8 @@ static void drm_syncobj_assign_null_handle(struct 
drm_syncobj *syncobj)
dma_fence_put(fence);
 }
 
+/* 5s default for wait submission */
+#define DRM_SYNCOBJ_WAIT_FOR_SUBMIT_TIMEOUT 50ULL
 /**
  * drm_syncobj_find_fence - lookup and reference the fence in a sync object
  * @file_private: drm file private pointer
@@ -233,16 +235,58 @@ int drm_syncobj_find_fence(struct drm_file *file_private,
   struct dma_fence **fence)
 {
struct drm_syncobj *syncobj = drm_syncobj_find(file_private, handle);
-   int ret = 0;
+   struct syncobj_wait_entry wait;
+   u64 timeout = nsecs_to_jiffies64(DRM_SYNCOBJ_WAIT_FOR_SUBMIT_TIMEOUT);
+   int ret;
 
if (!syncobj)
return -ENOENT;
 
*fence = drm_syncobj_fence_get(syncobj);
-   if (!*fence) {
+   drm_syncobj_put(syncobj);
+
+   if (*fence) {
+   ret = dma_fence_chain_find_seqno(fence, point);
+   if (!ret)
+   return 0;
+   dma_fence_put(*fence);
+   } else {
ret = -EINVAL;
}
-   drm_syncobj_put(syncobj);
+
+   if (!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT))
+   return ret;
+
+   memset(, 0, sizeof(wait));
+   wait.task = current;
+   wait.point = point;
+   drm_syncobj_fence_add_wait(syncobj, );
+
+   do {
+   set_current_state(TASK_INTERRUPTIBLE);
+   if (wait.fence) {
+   ret = 0;
+   break;
+   }
+if (timeout == 0) {
+ret = -ETIME;
+break;
+}
+
+   if (signal_pending(current)) {
+   ret = -ERESTARTSYS;
+   break;
+   }
+
+timeout = schedule_timeout(timeout);
+   } while (1);
+
+   __set_current_state(TASK_RUNNING);
+   *fence = wait.fence;
+
+   if (wait.node.next)
+   drm_syncobj_remove_wait(syncobj, );
+
return ret;
 }
 EXPORT_SYMBOL(drm_syncobj_find_fence);
-- 
2.17.1

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

[PATCH 7/9] drm/syncobj: add transition iotcls between binary and timeline v2

[Chunming Zhou]

we need to import/export timeline point.

v2: unify to one transfer ioctl

Signed-off-by: Chunming Zhou 
Cc: Lionel Landwerlin 
---
 drivers/gpu/drm/drm_internal.h |  2 +
 drivers/gpu/drm/drm_ioctl.c|  2 +
 drivers/gpu/drm/drm_syncobj.c  | 74 ++
 include/uapi/drm/drm.h | 10 +
 4 files changed, 88 insertions(+)

diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 695179bb88dc..dd11ae5f1eef 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -180,6 +180,8 @@ int drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev, 
void *data,
   struct drm_file *file_private);
 int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_private);
+int drm_syncobj_transfer_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file_private);
 int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_private);
 int drm_syncobj_timeline_wait_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 7a534c184e52..92b3b7b2fd81 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -686,6 +686,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, 
drm_syncobj_fd_to_handle_ioctl,
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TRANSFER, drm_syncobj_transfer_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT, 
drm_syncobj_timeline_wait_ioctl,
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 087fd4e7eaf3..ee2d66e047e7 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -679,6 +679,80 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, 
void *data,
>handle);
 }
 
+static int drm_syncobj_transfer_to_timeline(struct drm_file *file_private,
+   struct drm_syncobj_transfer *args)
+{
+   struct drm_syncobj *timeline_syncobj = NULL;
+   struct dma_fence *fence;
+   struct dma_fence_chain *chain;
+   int ret;
+
+   timeline_syncobj = drm_syncobj_find(file_private, args->dst_handle);
+   if (!timeline_syncobj) {
+   return -ENOENT;
+   }
+   ret = drm_syncobj_find_fence(file_private, args->src_handle,
+args->src_point, args->flags,
+);
+   if (ret)
+   goto err;
+   chain = kzalloc(sizeof(struct dma_fence_chain), GFP_KERNEL);
+   if (!chain) {
+   ret = -ENOMEM;
+   goto err1;
+   }
+   drm_syncobj_add_point(timeline_syncobj, chain, fence, args->dst_point);
+err1:
+   dma_fence_put(fence);
+err:
+   drm_syncobj_put(timeline_syncobj);
+
+   return ret;
+}
+
+static int
+drm_syncobj_transfer_to_binary(struct drm_file *file_private,
+  struct drm_syncobj_transfer *args)
+{
+   struct drm_syncobj *binary_syncobj = NULL;
+   struct dma_fence *fence;
+   int ret;
+
+   binary_syncobj = drm_syncobj_find(file_private, args->dst_handle);
+   if (!binary_syncobj)
+   return -ENOENT;
+   ret = drm_syncobj_find_fence(file_private, args->src_handle,
+args->src_point, args->flags, );
+   if (ret)
+   goto err;
+   drm_syncobj_replace_fence(binary_syncobj, fence);
+   dma_fence_put(fence);
+err:
+   drm_syncobj_put(binary_syncobj);
+
+   return ret;
+}
+int
+drm_syncobj_transfer_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file_private)
+{
+   struct drm_syncobj_transfer *args = data;
+   int ret;
+
+   if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   return -ENODEV;
+
+   if (args->pad)
+   return -EINVAL;
+
+   if (args->dst_point)
+   ret = drm_syncobj_transfer_to_timeline(file_private, args);
+   else
+   ret = drm_syncobj_transfer_to_binary(file_private, args);
+
+   return ret;
+}
+
 static void syncobj_wait_fence_func(struct dma_fence *fence,
struct dma_fence_cb *cb)
 {
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index c62be0840ba5..e8d0d6b51875 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -735,6 +735,15 @@ struct drm_syncobj_handle {
__u32 pad;
 };
 
+struct 

[PATCH 3/9] drm/syncobj: add support for timeline point wait v8

[Chunming Zhou]

points array is one-to-one match with syncobjs array.
v2:
add seperate ioctl for timeline point wait, otherwise break uapi.
v3:
userspace can specify two kinds waits::
a. Wait for time point to be completed.
b. and wait for time point to become available
v4:
rebase
v5:
add comment for xxx_WAIT_AVAILABLE
v6: rebase and rework on new container
v7: drop _WAIT_COMPLETED, it is the default anyway
v8: correctly handle garbage collected fences

Signed-off-by: Chunming Zhou 
Signed-off-by: Christian König 
Cc: Tobias Hector 
Cc: Jason Ekstrand 
Cc: Dave Airlie 
Cc: Chris Wilson 
Cc: Lionel Landwerlin 
---
 drivers/gpu/drm/drm_internal.h |   2 +
 drivers/gpu/drm/drm_ioctl.c|   2 +
 drivers/gpu/drm/drm_syncobj.c  | 153 ++---
 include/uapi/drm/drm.h |  15 
 4 files changed, 143 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 251d67e04c2d..331ac6225b58 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -182,6 +182,8 @@ int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, 
void *data,
   struct drm_file *file_private);
 int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_private);
+int drm_syncobj_timeline_wait_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *file_private);
 int drm_syncobj_reset_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
 int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 687943df58e1..c984654646fa 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -688,6 +688,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT, 
drm_syncobj_timeline_wait_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_RESET, drm_syncobj_reset_ioctl,
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL, drm_syncobj_signal_ioctl,
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 19a9ce638119..eae51978cda4 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -61,6 +61,7 @@ struct syncobj_wait_entry {
struct task_struct *task;
struct dma_fence *fence;
struct dma_fence_cb fence_cb;
+   u64point;
 };
 
 static void syncobj_wait_syncobj_func(struct drm_syncobj *syncobj,
@@ -95,6 +96,8 @@ EXPORT_SYMBOL(drm_syncobj_find);
 static void drm_syncobj_fence_add_wait(struct drm_syncobj *syncobj,
   struct syncobj_wait_entry *wait)
 {
+   struct dma_fence *fence;
+
if (wait->fence)
return;
 
@@ -103,11 +106,15 @@ static void drm_syncobj_fence_add_wait(struct drm_syncobj 
*syncobj,
 * have the lock, try one more time just to be sure we don't add a
 * callback when a fence has already been set.
 */
-   if (syncobj->fence)
-   wait->fence = dma_fence_get(
-   rcu_dereference_protected(syncobj->fence, 1));
-   else
+   fence = dma_fence_get(rcu_dereference_protected(syncobj->fence, 1));
+   if (!fence || dma_fence_chain_find_seqno(, wait->point)) {
+   dma_fence_put(fence);
list_add_tail(>node, >cb_list);
+   } else if (!fence) {
+   wait->fence = dma_fence_get_stub();
+   } else {
+   wait->fence = fence;
+   }
spin_unlock(>lock);
 }
 
@@ -149,10 +156,8 @@ void drm_syncobj_add_point(struct drm_syncobj *syncobj,
dma_fence_chain_init(chain, prev, fence, point);
rcu_assign_pointer(syncobj->fence, >base);
 
-   list_for_each_entry_safe(cur, tmp, >cb_list, node) {
-   list_del_init(>node);
+   list_for_each_entry_safe(cur, tmp, >cb_list, node)
syncobj_wait_syncobj_func(syncobj, cur);
-   }
spin_unlock(>lock);
 
/* Walk the chain once to trigger garbage collection */
@@ -184,10 +189,8 @@ void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
rcu_assign_pointer(syncobj->fence, fence);
 
if (fence != old_fence) {
-   list_for_each_entry_safe(cur, tmp, >cb_list, node) {
-   list_del_init(>node);
+   list_for_each_entry_safe(cur, tmp, >cb_list, node)
syncobj_wait_syncobj_func(syncobj, cur);
-   }
}
 
spin_unlock(>lock);
@@ -644,13 +647,27 @@ static void syncobj_wait_fence_func(struct dma_fence 

[PATCH 1/9] dma-buf: add new dma_fence_chain container v6

[Chunming Zhou]

From: Christian König 

Lockless container implementation similar to a dma_fence_array, but with
only two elements per node and automatic garbage collection.

v2: properly document dma_fence_chain_for_each, add dma_fence_chain_find_seqno,
drop prev reference during garbage collection if it's not a chain fence.
v3: use head and iterator for dma_fence_chain_for_each
v4: fix reference count in dma_fence_chain_enable_signaling
v5: fix iteration when walking each chain node
v6: add __rcu for member 'prev' of struct chain node

Signed-off-by: Christian König 
Cc: Lionel Landwerlin 
---
 drivers/dma-buf/Makefile  |   3 +-
 drivers/dma-buf/dma-fence-chain.c | 241 ++
 include/linux/dma-fence-chain.h   |  81 ++
 3 files changed, 324 insertions(+), 1 deletion(-)
 create mode 100644 drivers/dma-buf/dma-fence-chain.c
 create mode 100644 include/linux/dma-fence-chain.h

diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 0913a6ccab5a..1f006e083eb9 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1,4 +1,5 @@
-obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o
+obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \
+reservation.o seqno-fence.o
 obj-$(CONFIG_SYNC_FILE)+= sync_file.o
 obj-$(CONFIG_SW_SYNC)  += sw_sync.o sync_debug.o
 obj-$(CONFIG_UDMABUF)  += udmabuf.o
diff --git a/drivers/dma-buf/dma-fence-chain.c 
b/drivers/dma-buf/dma-fence-chain.c
new file mode 100644
index ..0c5e3c902fa0
--- /dev/null
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -0,0 +1,241 @@
+/*
+ * fence-chain: chain fences together in a timeline
+ *
+ * Copyright (C) 2018 Advanced Micro Devices, Inc.
+ * Authors:
+ * Christian König 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+
+static bool dma_fence_chain_enable_signaling(struct dma_fence *fence);
+
+/**
+ * dma_fence_chain_get_prev - use RCU to get a reference to the previous fence
+ * @chain: chain node to get the previous node from
+ *
+ * Use dma_fence_get_rcu_safe to get a reference to the previous fence of the
+ * chain node.
+ */
+static struct dma_fence *dma_fence_chain_get_prev(struct dma_fence_chain 
*chain)
+{
+   struct dma_fence *prev;
+
+   rcu_read_lock();
+   prev = dma_fence_get_rcu_safe(>prev);
+   rcu_read_unlock();
+   return prev;
+}
+
+/**
+ * dma_fence_chain_walk - chain walking function
+ * @fence: current chain node
+ *
+ * Walk the chain to the next node. Returns the next fence or NULL if we are at
+ * the end of the chain. Garbage collects chain nodes which are already
+ * signaled.
+ */
+struct dma_fence *dma_fence_chain_walk(struct dma_fence *fence)
+{
+   struct dma_fence_chain *chain, *prev_chain;
+   struct dma_fence *prev, *replacement, *tmp;
+
+   chain = to_dma_fence_chain(fence);
+   if (!chain) {
+   dma_fence_put(fence);
+   return NULL;
+   }
+
+   while ((prev = dma_fence_chain_get_prev(chain))) {
+
+   prev_chain = to_dma_fence_chain(prev);
+   if (prev_chain) {
+   if (!dma_fence_is_signaled(prev_chain->fence))
+   break;
+
+   replacement = dma_fence_chain_get_prev(prev_chain);
+   } else {
+   if (!dma_fence_is_signaled(prev))
+   break;
+
+   replacement = NULL;
+   }
+
+   tmp = cmpxchg(>prev, prev, replacement);
+   if (tmp == prev)
+   dma_fence_put(tmp);
+   else
+   dma_fence_put(replacement);
+   dma_fence_put(prev);
+   }
+
+   dma_fence_put(fence);
+   return prev;
+}
+EXPORT_SYMBOL(dma_fence_chain_walk);
+
+/**
+ * dma_fence_chain_find_seqno - find fence chain node by seqno
+ * @pfence: pointer to the chain node where to start
+ * @seqno: the sequence number to search for
+ *
+ * Advance the fence pointer to the chain node which will signal this sequence
+ * number. If no sequence number is provided then this is a no-op.
+ *
+ * Returns EINVAL if the fence is not a chain node or the sequence number has
+ * not yet advanced far enough.
+ */
+int dma_fence_chain_find_seqno(struct dma_fence **pfence, uint64_t seqno)
+{
+   struct dma_fence_chain *chain;
+
+   if (!seqno)
+   return 0;
+
+   chain = to_dma_fence_chain(*pfence);
+   if (!chain || chain->base.seqno < seqno)
+  

[PATCH 2/9] drm/syncobj: add new drm_syncobj_add_point interface v4

[Chunming Zhou]

From: Christian König 

Use the dma_fence_chain object to create a timeline of fence objects
instead of just replacing the existing fence.

v2: rebase and cleanup
v3: fix garbage collection parameters
v4: add unorder point check, print a warn calltrace

Signed-off-by: Christian König 
Cc: Lionel Landwerlin 
---
 drivers/gpu/drm/drm_syncobj.c | 39 +++
 include/drm/drm_syncobj.h |  5 +
 2 files changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 5329e66598c6..19a9ce638119 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -122,6 +122,45 @@ static void drm_syncobj_remove_wait(struct drm_syncobj 
*syncobj,
spin_unlock(>lock);
 }
 
+/**
+ * drm_syncobj_add_point - add new timeline point to the syncobj
+ * @syncobj: sync object to add timeline point do
+ * @chain: chain node to use to add the point
+ * @fence: fence to encapsulate in the chain node
+ * @point: sequence number to use for the point
+ *
+ * Add the chain node as new timeline point to the syncobj.
+ */
+void drm_syncobj_add_point(struct drm_syncobj *syncobj,
+  struct dma_fence_chain *chain,
+  struct dma_fence *fence,
+  uint64_t point)
+{
+   struct syncobj_wait_entry *cur, *tmp;
+   struct dma_fence *prev;
+
+   dma_fence_get(fence);
+
+   spin_lock(>lock);
+
+   prev = drm_syncobj_fence_get(syncobj);
+   /* You are adding an unorder point to timeline, which could cause 
payload returned from query_ioctl is 0! */
+   WARN_ON_ONCE(prev && prev->seqno >= point);
+   dma_fence_chain_init(chain, prev, fence, point);
+   rcu_assign_pointer(syncobj->fence, >base);
+
+   list_for_each_entry_safe(cur, tmp, >cb_list, node) {
+   list_del_init(>node);
+   syncobj_wait_syncobj_func(syncobj, cur);
+   }
+   spin_unlock(>lock);
+
+   /* Walk the chain once to trigger garbage collection */
+   dma_fence_chain_for_each(fence, prev);
+   dma_fence_put(prev);
+}
+EXPORT_SYMBOL(drm_syncobj_add_point);
+
 /**
  * drm_syncobj_replace_fence - replace fence in a sync object.
  * @syncobj: Sync object to replace fence in
diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index 0311c9fdbd2f..6cf7243a1dc5 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -27,6 +27,7 @@
 #define __DRM_SYNCOBJ_H__
 
 #include 
+#include 
 
 struct drm_file;
 
@@ -112,6 +113,10 @@ drm_syncobj_fence_get(struct drm_syncobj *syncobj)
 
 struct drm_syncobj *drm_syncobj_find(struct drm_file *file_private,
 u32 handle);
+void drm_syncobj_add_point(struct drm_syncobj *syncobj,
+  struct dma_fence_chain *chain,
+  struct dma_fence *fence,
+  uint64_t point);
 void drm_syncobj_replace_fence(struct drm_syncobj *syncobj,
   struct dma_fence *fence);
 int drm_syncobj_find_fence(struct drm_file *file_private,
-- 
2.17.1

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

[Bug 110201] mesa 19.0.0 breaks rendering in kitty

[bugzilla-daemon]

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

--- Comment #1 from Kovid Goyal  ---
Created attachment 143737
  --> https://bugs.freedesktop.org/attachment.cgi?id=143737=edit
api trace output of running kitty on mesa 19

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

[Bug 110201] mesa 19.0.0 breaks rendering in kitty

[bugzilla-daemon]

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

Bug ID: 110201
   Summary: mesa 19.0.0 breaks rendering in kitty
   Product: Mesa
   Version: 19.0
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/i915
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ko...@kovidgoyal.net
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 143736
  --> https://bugs.freedesktop.org/attachment.cgi?id=143736=edit
glxinfo output

Since upgrading to mesa 19.0.0 rendering in kitty
(https://sw.kovidgoyal.net/kitty/) an OpenGL terminal is broken, with various
artifacts, for details, see https://github.com/kovidgoyal/kitty/issues/1484

Downgrading mesa to 18.3.4 fixes it. I have a report from a user that mesa
18.3.5 also breaks it, but I cannot confirm myself. This is on Arch Linux x64
up-to-date.

I have attached output of glxinfo. 

To reproduce, simply install kitty and run it with mesa 19 -- under Wayland I
get the first line in the terminal blinking with the cursor. Under X11 I get
the first four characters being not rendered.

I have attached glxinfo and apitrace output running kitty with mesa 19.

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

Re: [PATCH 8/9] drm/syncobj: add timeline signal ioctl for syncobj v3

[zhoucm1]

On 2019年03月19日 19:54, Lionel Landwerlin wrote:

On 15/03/2019 12:09, Chunming Zhou wrote:
v2: individually allocate chain array, since chain node is free 
independently.
v3: all existing points must be already signaled before cpu perform 
signal operation,

 so add check condition for that.

Signed-off-by: Chunming Zhou 
---
  drivers/gpu/drm/drm_internal.h |   2 +
  drivers/gpu/drm/drm_ioctl.c    |   2 +
  drivers/gpu/drm/drm_syncobj.c  | 103 +
  include/uapi/drm/drm.h |   1 +
  4 files changed, 108 insertions(+)

diff --git a/drivers/gpu/drm/drm_internal.h 
b/drivers/gpu/drm/drm_internal.h

index dd11ae5f1eef..d9a483a5fce0 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -190,6 +190,8 @@ int drm_syncobj_reset_ioctl(struct drm_device 
*dev, void *data,

  struct drm_file *file_private);
  int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_private);
+int drm_syncobj_timeline_signal_ioctl(struct drm_device *dev, void 
*data,

+  struct drm_file *file_private);
  int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
  struct drm_file *file_private);
  diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 92b3b7b2fd81..d337f161909c 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -696,6 +696,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
    DRM_UNLOCKED|DRM_RENDER_ALLOW),
  DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL, drm_syncobj_signal_ioctl,
    DRM_UNLOCKED|DRM_RENDER_ALLOW),
+    DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL, 
drm_syncobj_timeline_signal_ioctl,

+  DRM_UNLOCKED|DRM_RENDER_ALLOW),
  DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_QUERY, drm_syncobj_query_ioctl,
    DRM_UNLOCKED|DRM_RENDER_ALLOW),
  DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE, 
drm_crtc_get_sequence_ioctl, DRM_UNLOCKED),
diff --git a/drivers/gpu/drm/drm_syncobj.c 
b/drivers/gpu/drm/drm_syncobj.c

index 306c7b7e2770..eaeb038f97d7 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1183,6 +1183,109 @@ drm_syncobj_signal_ioctl(struct drm_device 
*dev, void *data,

  return ret;
  }
  +int
+drm_syncobj_timeline_signal_ioctl(struct drm_device *dev, void *data,
+  struct drm_file *file_private)
+{
+    struct drm_syncobj_timeline_array *args = data;
+    struct drm_syncobj **syncobjs;
+    struct dma_fence_chain **chains;
+    uint64_t *points;
+    uint32_t i, j, timeline_count = 0;
+    int ret;
+
+    if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+    return -EOPNOTSUPP;
+
+    if (args->pad != 0)
+    return -EINVAL;
+
+    if (args->count_handles == 0)
+    return -EINVAL;
+
+    ret = drm_syncobj_array_find(file_private,
+ u64_to_user_ptr(args->handles),
+ args->count_handles,
+ );
+    if (ret < 0)
+    return ret;
+
+    for (i = 0; i < args->count_handles; i++) {
+    struct dma_fence_chain *chain;
+    struct dma_fence *fence;
+
+    fence = drm_syncobj_fence_get(syncobjs[i]);
+    chain = to_dma_fence_chain(fence);
+    if (chain) {
+    struct dma_fence *iter;
+
+    dma_fence_chain_for_each(iter, fence) {
+    if (!iter)
+    break;
+    if (!dma_fence_is_signaled(iter)) {
+    dma_fence_put(iter);
+    DRM_ERROR("Client must guarantee all existing 
timeline points signaled before performing host signal operation!");

+    ret = -EPERM;
+    goto out;



Sorry if I'm failing to remember whether we discussed this before.


Signaling a point from the host should be fine even if the previous 
points in the timeline are not signaled.

ok, will remove that checking.



After all this can happen on the device side as well (out of order 
signaling).



I thought the thing we didn't want is out of order submission.

Just checking the last chain node seqno against the host signal point 
should be enough.



What about simply returning -EPERM, we can warn the application from 
userspace?

OK, will add that.





+    }
+    }
+    }
+    }
+
+    points = kmalloc_array(args->count_handles, sizeof(*points),
+   GFP_KERNEL);
+    if (!points) {
+    ret = -ENOMEM;
+    goto out;
+    }
+    if (!u64_to_user_ptr(args->points)) {
+    memset(points, 0, args->count_handles * sizeof(uint64_t));
+    } else if (copy_from_user(points, u64_to_user_ptr(args->points),
+  sizeof(uint64_t) * args->count_handles)) {
+    ret = -EFAULT;
+    goto err_points;
+    }
+
+
+    for (i = 0; i < 

Re: [PATCH] gpu/drm: mediatek: call mtk_dsi_stop() after mtk_drm_crtc_atomic_disable()

[CK Hu]

Hi, Hsin-yi:

On Mon, 2019-03-18 at 12:09 +0800, Hsin-Yi Wang wrote:
> mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(), which 
> needs
> ovl irq for drm_crtc_wait_one_vblank(), since after mtk_dsi_stop() is called,
> ovl irq will be disabled. If drm_crtc_wait_one_vblank() is called after last
> irq, it will timeout with this message: "vblank wait timed out on crtc 0". 
> This
> happens sometimes when turning off the screen.
> 
> In drm_atomic_helper.c#disable_outputs(),
> the calling sequence when turning off the screen is:
> 
> 1. mtk_dsi_encoder_disable()
>  --> mtk_output_dsi_disable()
>--> mtk_dsi_stop();  // sometimes make vblank timeout in atomic_disable
>  --> mtk_dsi_poweroff();
> 2. mtk_drm_crtc_atomic_disable()
>  --> drm_crtc_wait_one_vblank();
>  ...
>--> mtk_dsi_ddp_stop()
>  --> mtk_dsi_poweroff();
> 

Thanks for your inference, but I wonder this patch meet all
consideration. In MT8173 with a bridge chip, the timing to disable dsi
signal output would influence bridge chip output garbage or not. It's
better that you could test this on MT8173, or let this patch go for
weeks and wait for someone to test. If no one care about MT8173, I could
accept this patch.

> Change to make mtk_dsi_stop() called in mtk_dsi_ddp_stop() instead of
> mtk_output_dsi_disable().

mtk_dsi_poweroff() has reference count, why not just move mtk_dsi_stop()
into mtk_dsi_poweroff()?

Regards,
CK

> 
> Fixes: 0707632b5bac ("drm/mediatek: update DSI sub driver flow for sending 
> commands to panel")
> Signed-off-by: Hsin-Yi Wang 
> ---
>  drivers/gpu/drm/mediatek/mtk_dsi.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
> b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index b00eb2d2e086..cdd9637dd517 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -696,7 +696,6 @@ static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
>   }
>   }
>  
> - mtk_dsi_stop(dsi);
>   mtk_dsi_poweroff(dsi);
>  
>   dsi->enabled = false;
> @@ -857,6 +856,7 @@ static void mtk_dsi_ddp_stop(struct mtk_ddp_comp *comp)
>  {
>   struct mtk_dsi *dsi = container_of(comp, struct mtk_dsi, ddp_comp);
>  
> + mtk_dsi_stop(dsi);
>   mtk_dsi_poweroff(dsi);
>  }
>  
> @@ -1178,6 +1178,8 @@ static int mtk_dsi_remove(struct platform_device *pdev)
>   struct mtk_dsi *dsi = platform_get_drvdata(pdev);
>  
>   mtk_output_dsi_disable(dsi);
> + mtk_dsi_stop(dsi);
> + mtk_dsi_poweroff(dsi);
>   component_del(>dev, _dsi_component_ops);
>  
>   return 0;


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

[PATCH libdrm] tests/amdgpu: minor fix for dispatch/draw test

[Cui, Flora]

1. clear cmd buffer
2. make amdgpu_memcpy_dispatch_test static
3. tab/space fix

Change-Id: Idf55f8881f66458b585092eccb55b6042520e4ad
Signed-off-by: Flora Cui 
---
 tests/amdgpu/basic_tests.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/tests/amdgpu/basic_tests.c b/tests/amdgpu/basic_tests.c
index a364f67..2d47269 100644
--- a/tests/amdgpu/basic_tests.c
+++ b/tests/amdgpu/basic_tests.c
@@ -2177,6 +2177,7 @@ static void 
amdgpu_memset_dispatch_test(amdgpu_device_handle device_handle,
_cmd, (void **)_cmd,
_address_cmd, _cmd);
CU_ASSERT_EQUAL(r, 0);
+   memset(ptr_cmd, 0, bo_cmd_size);
 
r = amdgpu_bo_alloc_and_map(device_handle, bo_shader_size, 4096,
AMDGPU_GEM_DOMAIN_VRAM, 0,
@@ -2227,7 +2228,7 @@ static void 
amdgpu_memset_dispatch_test(amdgpu_device_handle device_handle,
ptr_cmd[i++] = 1;
 
while (i & 7)
-   ptr_cmd[i++] =  0x1000; /* type3 nop packet */
+   ptr_cmd[i++] = 0x1000; /* type3 nop packet */
 
resources[0] = bo_dst;
resources[1] = bo_shader;
@@ -2283,9 +2284,9 @@ static void 
amdgpu_memset_dispatch_test(amdgpu_device_handle device_handle,
CU_ASSERT_EQUAL(r, 0);
 }
 
-void amdgpu_memcpy_dispatch_test(amdgpu_device_handle device_handle,
-uint32_t ip_type,
-uint32_t ring)
+static void amdgpu_memcpy_dispatch_test(amdgpu_device_handle device_handle,
+   uint32_t ip_type,
+   uint32_t ring)
 {
amdgpu_context_handle context_handle;
amdgpu_bo_handle bo_src, bo_dst, bo_shader, bo_cmd, resources[4];
@@ -2313,6 +2314,7 @@ void amdgpu_memcpy_dispatch_test(amdgpu_device_handle 
device_handle,
_cmd, (void **)_cmd,
_address_cmd, _cmd);
CU_ASSERT_EQUAL(r, 0);
+   memset(ptr_cmd, 0, bo_cmd_size);
 
r = amdgpu_bo_alloc_and_map(device_handle, bo_shader_size, 4096,
AMDGPU_GEM_DOMAIN_VRAM, 0,
@@ -2371,7 +2373,7 @@ void amdgpu_memcpy_dispatch_test(amdgpu_device_handle 
device_handle,
ptr_cmd[i++] = 1;
 
while (i & 7)
-   ptr_cmd[i++] =  0x1000; /* type3 nop packet */
+   ptr_cmd[i++] = 0x1000; /* type3 nop packet */
 
resources[0] = bo_shader;
resources[1] = bo_src;
@@ -2799,7 +2801,8 @@ void amdgpu_memset_draw(amdgpu_device_handle 
device_handle,
AMDGPU_GEM_DOMAIN_GTT, 0,
_cmd, (void **)_cmd,
_address_cmd, _cmd);
-CU_ASSERT_EQUAL(r, 0);
+   CU_ASSERT_EQUAL(r, 0);
+   memset(ptr_cmd, 0, bo_cmd_size);
 
r = amdgpu_bo_alloc_and_map(device_handle, bo_dst_size, 4096,
AMDGPU_GEM_DOMAIN_VRAM, 0,
@@ -2828,7 +2831,7 @@ void amdgpu_memset_draw(amdgpu_device_handle 
device_handle,
i += amdgpu_draw_draw(ptr_cmd + i);
 
while (i & 7)
-   ptr_cmd[i++] =  0x1000; /* type3 nop packet */
+   ptr_cmd[i++] = 0x1000; /* type3 nop packet */
 
resources[0] = bo_dst;
resources[1] = bo_shader_ps;
@@ -2952,6 +2955,7 @@ static void amdgpu_memcpy_draw(amdgpu_device_handle 
device_handle,
_cmd, (void **)_cmd,
_address_cmd, _cmd);
CU_ASSERT_EQUAL(r, 0);
+   memset(ptr_cmd, 0, bo_cmd_size);
 
r = amdgpu_bo_alloc_and_map(device_handle, bo_size, 4096,
AMDGPU_GEM_DOMAIN_VRAM, 0,
@@ -2999,7 +3003,7 @@ static void amdgpu_memcpy_draw(amdgpu_device_handle 
device_handle,
i += amdgpu_draw_draw(ptr_cmd + i);
 
while (i & 7)
-   ptr_cmd[i++] =  0x1000; /* type3 nop packet */
+   ptr_cmd[i++] = 0x1000; /* type3 nop packet */
 
resources[0] = bo_dst;
resources[1] = bo_src;
-- 
2.7.4

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

[Bug 110142] "Oops: Kernel access of bad area sig 7" on Kernel 5.0.0 PPC64LE when loading amdgpu, xorg hangs after being unable to load after OS boots.

[bugzilla-daemon]

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

--- Comment #9 from Peter Easton  ---
(In reply to Michel Dänzer from comment #7)
> Please try https://patchwork.freedesktop.org/patch/292720/ , it should fix
> the problem.

Splice the mainbrace! It worked like a charm! 

It worked, xfce4 started without a hitch this time with the new kernel. Thank
you so much! 

What shall we do now? Is there a way to get that patch merged upstream?

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

RE: Clang warning in drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c

[Pan, Xinhui]

these two enumerated types are same for now. both of them might change in the 
future.

I have not used clang, but would  .block_id =  (int)head->block fix your 
warning? If such change is acceptable, I can make one then.

Thanks
xinhui


-Original Message-
From: Nathan Chancellor  
Sent: 2019年3月20日 8:54
To: Deucher, Alexander ; Koenig, Christian 
; Zhou, David(ChunMing) ; Pan, 
Xinhui 
Cc: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; 
linux-ker...@vger.kernel.org; clang-built-li...@googlegroups.com
Subject: Clang warning in drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c

Hi all,

The introduction of this file in commit dbd249c24427 ("drm/amdgpu: add 
amdgpu_ras.c to support ras (v2)") introduces the following Clang
warnings:

drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:544:23: warning: implicit conversion 
from enumeration type 'enum amdgpu_ras_block' to different enumeration type 
'enum ta_ras_block' [-Wenum-conversion]
.block_id =  head->block,
 ~~^
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:545:24: warning: implicit conversion 
from enumeration type 'enum amdgpu_ras_error_type' to different enumeration 
type 'enum ta_ras_error_type' [-Wenum-conversion]
.error_type = head->type,
  ~~^~~~
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:549:23: warning: implicit conversion 
from enumeration type 'enum amdgpu_ras_block' to different enumeration type 
'enum ta_ras_block' [-Wenum-conversion]
.block_id =  head->block,
 ~~^
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:550:24: warning: implicit conversion 
from enumeration type 'enum amdgpu_ras_error_type' to different enumeration 
type 'enum ta_ras_error_type' [-Wenum-conversion]
.error_type = head->type,
  ~~^~~~
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:650:26: warning: implicit conversion 
from enumeration type 'enum amdgpu_ras_block' to different enumeration type 
'enum ta_ras_block' [-Wenum-conversion]
.block_id = info->head.block,
~~~^
drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:651:35: warning: implicit conversion 
from enumeration type 'enum amdgpu_ras_error_type' to different enumeration 
type 'enum ta_ras_error_type' [-Wenum-conversion]
.inject_error_type = info->head.type,
 ~~~^~~~
6 warnings generated.

Normally, I would sent a fix for this myself but I am not entirely sure why 
these two enumerated types exist when one would do since they have the same 
values minus the prefix. In fact, the ta_ras_{block,error_type} values are 
never used aside from being defined. Some clarification would be appreciated.

Thank you,
Nathan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110142] "Oops: Kernel access of bad area sig 7" on Kernel 5.0.0 PPC64LE when loading amdgpu, xorg hangs after being unable to load after OS boots.

[bugzilla-daemon]

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

--- Comment #8 from Peter Easton  ---
Great, I'll go try it on 5.0.2 and report back, thanks!

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

Re: [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION)

[John Stultz]

On Tue, Mar 19, 2019 at 2:58 PM Rob Clark  wrote:
>
> On Tue, Mar 19, 2019 at 1:00 PM Andrew F. Davis  wrote:
> >
> > On 3/19/19 11:54 AM, Benjamin Gaignard wrote:
> > > Le mer. 13 mars 2019 à 23:31, John Stultz  a 
> > > écrit :
> > >>
> > >> On Wed, Mar 13, 2019 at 1:11 PM Liam Mark  wrote:
> > >>> On Tue, 5 Mar 2019, John Stultz wrote:
> > 
> >  Eventual TODOS:
> >  * Reimplement page-pool for system heap (working on this)
> >  * Add stats accounting to system/cma heaps
> >  * Make the kselftest actually useful
> >  * Add other heaps folks see as useful (would love to get
> >    some help from actual carveout/chunk users)!
> > >>>
> > >>> We use a modified carveout heap for certain secure use cases.
> > >>
> > >> Cool! It would be great to see if you have any concerns about adding
> > >> such a secure-carveout heap to this framework. I suspect it would be
> > >> fairly similar to how its integrated into ION, but particularly I'd be
> > >> interested in issues around the lack of private flags and other
> > >> allocation arguments like alignment.
> > >>
> > >>> Although there would probably be some benefit in discssing how the 
> > >>> dma-buf
> > >>> heap framework may want to support
> > >>> secure heaps in the future it is a large topic which I assume you don't
> > >>> want to tackle now.
> > >>
> > >> So I suspect others (Benjamin?) would have a more informed opinion on
> > >> the details, but the intent is to allow secure heap implementations.
> > >> I'm not sure what areas of concern you have for this allocation
> > >> framework in particular?
> > >
> > > yes I would be great to understand how you provide the information to
> > > tell that a dmabuf
> > > is secure (or not) since we can't add flag in dmabuf structure itself.
> > > An option is manage
> > > the access rights when a device attach itself to the dmabuf but in
> > > this case you need define
> > > a list of allowed devices per heap...
> > > If you have a good solution for secure heaps you are welcome :-)
> > >
> >
> > Do we really need any of that? A secure buffer is secured by the
> > hardware firewalls that keep out certain IP (including often the
> > processor running Linux). So the only thing we need to track internally
> > is that we should not allow mmap/kmap on the buffer. That can be done in
> > the per-heap layer, everything else stays the same as a standard
> > carveout heap.
>
> For at least some hw the importing driver needs to configure things
> differently for secure buffers :-/

Does the import ioctl need/use a flag for that then? Userland already
has to keep meta-data about dmabufs around.

thanks
-john
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 18/20] lib: image-formats: Add v4l2 formats support

[Maxime Ripard]

V4L2 uses different fourcc's than DRM, and has a different set of formats.
For now, let's add the v4l2 fourcc's for the already existing formats.

Signed-off-by: Maxime Ripard 
---
 include/linux/image-formats.h |  9 +-
 lib/image-formats.c   | 67 -
 2 files changed, 76 insertions(+)

diff --git a/include/linux/image-formats.h b/include/linux/image-formats.h
index 53fd73a71b3d..fbc3a4501ebd 100644
--- a/include/linux/image-formats.h
+++ b/include/linux/image-formats.h
@@ -26,6 +26,13 @@ struct image_format_info {
};
 
/**
+* @v4l2_fmt:
+*
+* V4L2 4CC format identifier (V4L2_PIX_FMT_*)
+*/
+   u32 v4l2_fmt;
+
+   /**
 * @depth:
 *
 * Color depth (number of bits per pixel excluding padding bits),
@@ -222,6 +229,8 @@ image_format_info_is_yuv_sampling_444(const struct 
image_format_info *info)
 
 const struct image_format_info *__image_format_drm_lookup(u32 drm);
 const struct image_format_info *image_format_drm_lookup(u32 drm);
+const struct image_format_info *__image_format_v4l2_lookup(u32 v4l2);
+const struct image_format_info *image_format_v4l2_lookup(u32 v4l2);
 unsigned int image_format_plane_cpp(const struct image_format_info *format,
int plane);
 unsigned int image_format_plane_width(int width,
diff --git a/lib/image-formats.c b/lib/image-formats.c
index 9b9a73220c5d..39f1d38ae861 100644
--- a/lib/image-formats.c
+++ b/lib/image-formats.c
@@ -8,6 +8,7 @@
 static const struct image_format_info formats[] = {
{
.drm_fmt = DRM_FORMAT_C8,
+   .v4l2_fmt = V4L2_PIX_FMT_GREY,
.depth = 8,
.num_planes = 1,
.cpp = { 1, 0, 0 },
@@ -15,6 +16,7 @@ static const struct image_format_info formats[] = {
.vsub = 1,
}, {
.drm_fmt = DRM_FORMAT_RGB332,
+   .v4l2_fmt = V4L2_PIX_FMT_RGB332,
.depth = 8,
.num_planes = 1,
.cpp = { 1, 0, 0 },
@@ -29,6 +31,7 @@ static const struct image_format_info formats[] = {
.vsub = 1,
}, {
.drm_fmt = DRM_FORMAT_XRGB,
+   .v4l2_fmt = V4L2_PIX_FMT_XRGB444,
.depth = 0,
.num_planes = 1,
.cpp = { 2, 0, 0 },
@@ -57,6 +60,7 @@ static const struct image_format_info formats[] = {
.vsub = 1,
}, {
.drm_fmt = DRM_FORMAT_ARGB,
+   .v4l2_fmt = V4L2_PIX_FMT_ARGB444,
.depth = 0,
.num_planes = 1,
.cpp = { 2, 0, 0 },
@@ -89,6 +93,7 @@ static const struct image_format_info formats[] = {
.has_alpha = true,
}, {
.drm_fmt = DRM_FORMAT_XRGB1555,
+   .v4l2_fmt = V4L2_PIX_FMT_XRGB555,
.depth = 15,
.num_planes = 1,
.cpp = { 2, 0, 0 },
@@ -117,6 +122,7 @@ static const struct image_format_info formats[] = {
.vsub = 1,
}, {
.drm_fmt = DRM_FORMAT_ARGB1555,
+   .v4l2_fmt = V4L2_PIX_FMT_ARGB555,
.depth = 15,
.num_planes = 1,
.cpp = { 2, 0, 0 },
@@ -149,6 +155,7 @@ static const struct image_format_info formats[] = {
.has_alpha = true,
}, {
.drm_fmt = DRM_FORMAT_RGB565,
+   .v4l2_fmt = V4L2_PIX_FMT_RGB565,
.depth = 16,
.num_planes = 1,
.cpp = { 2, 0, 0 },
@@ -163,6 +170,7 @@ static const struct image_format_info formats[] = {
.vsub = 1,
}, {
.drm_fmt = DRM_FORMAT_RGB888,
+   .v4l2_fmt = V4L2_PIX_FMT_RGB24,
.depth = 24,
.num_planes = 1,
.cpp = { 3, 0, 0 },
@@ -170,6 +178,7 @@ static const struct image_format_info formats[] = {
.vsub = 1,
}, {
.drm_fmt = DRM_FORMAT_BGR888,
+   .v4l2_fmt = V4L2_PIX_FMT_BGR24,
.depth = 24,
.num_planes = 1,
.cpp = { 3, 0, 0 },
@@ -177,6 +186,7 @@ static const struct image_format_info formats[] = {
.vsub = 1,
}, {
.drm_fmt = DRM_FORMAT_XRGB,
+   .v4l2_fmt = V4L2_PIX_FMT_XRGB32,
.depth = 24,
.num_planes = 1,
.cpp = { 4, 0, 0 },
@@ -281,6 +291,7 @@ static const struct image_format_info formats[] = {
.has_alpha = true,
}, {
.drm_fmt = DRM_FORMAT_ARGB,
+   .v4l2_fmt = V4L2_PIX_FMT_ARGB32,
.depth = 32,
.num_planes = 1,
.cpp = { 4, 0, 0 },
@@ -361,6 +372,7 @@ static const struct image_format_info formats[] = {
.has_alpha = true,
}, {

Re: [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION)

[Rob Clark]

On Tue, Mar 19, 2019 at 1:00 PM Andrew F. Davis  wrote:
>
> On 3/19/19 11:54 AM, Benjamin Gaignard wrote:
> > Le mer. 13 mars 2019 à 23:31, John Stultz  a écrit :
> >>
> >> On Wed, Mar 13, 2019 at 1:11 PM Liam Mark  wrote:
> >>> On Tue, 5 Mar 2019, John Stultz wrote:
> 
>  Eventual TODOS:
>  * Reimplement page-pool for system heap (working on this)
>  * Add stats accounting to system/cma heaps
>  * Make the kselftest actually useful
>  * Add other heaps folks see as useful (would love to get
>    some help from actual carveout/chunk users)!
> >>>
> >>> We use a modified carveout heap for certain secure use cases.
> >>
> >> Cool! It would be great to see if you have any concerns about adding
> >> such a secure-carveout heap to this framework. I suspect it would be
> >> fairly similar to how its integrated into ION, but particularly I'd be
> >> interested in issues around the lack of private flags and other
> >> allocation arguments like alignment.
> >>
> >>> Although there would probably be some benefit in discssing how the dma-buf
> >>> heap framework may want to support
> >>> secure heaps in the future it is a large topic which I assume you don't
> >>> want to tackle now.
> >>
> >> So I suspect others (Benjamin?) would have a more informed opinion on
> >> the details, but the intent is to allow secure heap implementations.
> >> I'm not sure what areas of concern you have for this allocation
> >> framework in particular?
> >
> > yes I would be great to understand how you provide the information to
> > tell that a dmabuf
> > is secure (or not) since we can't add flag in dmabuf structure itself.
> > An option is manage
> > the access rights when a device attach itself to the dmabuf but in
> > this case you need define
> > a list of allowed devices per heap...
> > If you have a good solution for secure heaps you are welcome :-)
> >
>
> Do we really need any of that? A secure buffer is secured by the
> hardware firewalls that keep out certain IP (including often the
> processor running Linux). So the only thing we need to track internally
> is that we should not allow mmap/kmap on the buffer. That can be done in
> the per-heap layer, everything else stays the same as a standard
> carveout heap.

For at least some hw the importing driver needs to configure things
differently for secure buffers :-/

BR,
-R

>
> Andrew
>
> > Benjamin
> >>
> >>> We don't have any non-secure carveout heap use cases but the client use
> >>> case I have seen usually revolve around
> >>> wanting large allocations to succeed very quickly.
> >>> For example I have seen camera use cases which do very large allocations
> >>> on camera bootup from the carveout heap, these allocations would come from
> >>> the carveout heap and fallback to the system heap when the carveout heap
> >>> was full.
> >>> Actual non-secure carveout heap can perhaps provide more detail.
> >>
> >> Yea, I'm aware that folks still see carveout as preferable to CMA due
> >> to more consistent/predictable allocation latency.  I think we still
> >> have the issue that we don't have bindings to establish/configure
> >> carveout regions w/ dts, and I'm not really wanting to hold up the
> >> allocation API on that issue.
> >>
> >>
> >>> Since we are making some fundamental changes to how ION worked and since
> >>> Android is likely also be the largest user of the dma-buf heaps framework
> >>> I think it would be good
> >>> to have a path to resolve the issues which are currently preventing
> >>> commercial Android releases from moving to the upstream version of ION.
> >>
> >> Yea, I do see solving the cache management efficiency issues as
> >> critical for the dmabuf heaps to be actually usable (my previous
> >> version of this patchset accidentally had my hacks to improve
> >> performance rolled in!).  And there are discussions going on in
> >> various channels to try to figure out how to either change Android to
> >> use dma-bufs more in line with how upstream expects, or what more
> >> generic dma-buf changes we may need to allow Android to use dmabufs
> >> with the expected performance they need.
> >>
> >>> I can understand if you don't necessarily want to put all/any of these
> >>> changes into the dma-buf heaps framework as part of this series, but my
> >>> hope is we can get
> >>> the upstream community and the Android framework team to agree on what
> >>> upstreamable changes to dma-buf heaps framework, and/or the Android
> >>> framework, would be required in order for Android to move to the upstream
> >>> dma-buf heaps framework for commercial devices.
> >>
> >> Yes. Though I also don't want to get the bigger dma-buf usage
> >> discussion (which really affects all dmabuf exporters) too tied up
> >> with this patch sets attempt to provide a usable allocation interface.
> >> Part of the problem that I think we've seen with ION is that there is
> >> a nest of of related issues, and the entire thing is just too big to
> >> address at once, 

[RFC PATCH 14/20] drm/omap: Convert to generic image format library

[Maxime Ripard]

Now that we have a generic image format libary, let's convert drivers to
use it so that we can deprecate the old DRM one.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/omapdrm/dss/dispc.c |  9 +
 drivers/gpu/drm/omapdrm/omap_fb.c   |  7 ---
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c 
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index ba82d916719c..bf60d49ad6ca 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1898,9 +1899,9 @@ static void dispc_ovl_set_scaling_uv(struct dispc_device 
*dispc,
int scale_x = out_width != orig_width;
int scale_y = out_height != orig_height;
bool chroma_upscale = plane != OMAP_DSS_WB;
-   const struct drm_format_info *info;
+   const struct image_format_info *info;
 
-   info = drm_format_info(fourcc);
+   info = image_format_drm_lookup(fourcc);
 
if (!dispc_has_feature(dispc, FEAT_HANDLE_UV_SEPARATE))
return;
@@ -2623,9 +2624,9 @@ static int dispc_ovl_setup_common(struct dispc_device 
*dispc,
bool ilace = !!(vm->flags & DISPLAY_FLAGS_INTERLACED);
unsigned long pclk = dispc_plane_pclk_rate(dispc, plane);
unsigned long lclk = dispc_plane_lclk_rate(dispc, plane);
-   const struct drm_format_info *info;
+   const struct image_format_info *info;
 
-   info = drm_format_info(fourcc);
+   info = image_format_drm_lookup(fourcc);
 
/* when setting up WB, dispc_plane_pclk_rate() returns 0 */
if (plane == OMAP_DSS_WB)
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
b/drivers/gpu/drm/omapdrm/omap_fb.c
index 1d4143adf829..8caecfc8d1db 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -15,6 +15,7 @@
  * this program.  If not, see .
  */
 
+#include 
 #include 
 
 #include 
@@ -60,7 +61,7 @@ struct plane {
 struct omap_framebuffer {
struct drm_framebuffer base;
int pin_count;
-   const struct drm_format_info *format;
+   const struct image_format_info *format;
struct plane planes[2];
/* lock for pinning (pin_count and planes.dma_addr) */
struct mutex lock;
@@ -72,7 +73,7 @@ static const struct drm_framebuffer_funcs 
omap_framebuffer_funcs = {
 };
 
 static u32 get_linear_addr(struct drm_framebuffer *fb,
-   const struct drm_format_info *format, int n, int x, int y)
+   const struct image_format_info *format, int n, int x, int y)
 {
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
struct plane *plane = _fb->planes[n];
@@ -126,7 +127,7 @@ void omap_framebuffer_update_scanout(struct drm_framebuffer 
*fb,
struct drm_plane_state *state, struct omap_overlay_info *info)
 {
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
-   const struct drm_format_info *format = omap_fb->format;
+   const struct image_format_info *format = omap_fb->format;
struct plane *plane = _fb->planes[0];
u32 x, y, orient = 0;
 
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 19/20] lib: image-formats: Add more functions

[Maxime Ripard]

V4L2 drivers typically need a few more helpers compared to DRM drivers, so
let's add them.

Signed-off-by: Maxime Ripard 
---
 include/linux/image-formats.h |  4 +++-
 lib/image-formats.c   | 42 -
 2 files changed, 46 insertions(+)

diff --git a/include/linux/image-formats.h b/include/linux/image-formats.h
index fbc3a4501ebd..f1d4a2a03cc0 100644
--- a/include/linux/image-formats.h
+++ b/include/linux/image-formats.h
@@ -236,9 +236,13 @@ unsigned int image_format_plane_cpp(const struct 
image_format_info *format,
 unsigned int image_format_plane_width(int width,
  const struct image_format_info *format,
  int plane);
+unsigned int image_format_plane_stride(const struct image_format_info *format,
+  int width, int plane);
 unsigned int image_format_plane_height(int height,
   const struct image_format_info *format,
   int plane);
+unsigned int image_format_plane_size(const struct image_format_info *format,
+int width, int height, int plane);
 unsigned int image_format_block_width(const struct image_format_info *format,
  int plane);
 unsigned int image_format_block_height(const struct image_format_info *format,
diff --git a/lib/image-formats.c b/lib/image-formats.c
index 39f1d38ae861..c4e213a89edb 100644
--- a/lib/image-formats.c
+++ b/lib/image-formats.c
@@ -740,6 +740,26 @@ unsigned int image_format_plane_width(int width,
 EXPORT_SYMBOL(image_format_plane_width);
 
 /**
+ * image_format_plane_stride - determine the stride value
+ * @format: pointer to the image_format
+ * @width: plane width
+ * @plane: plane index
+ *
+ * Returns:
+ * The bytes per pixel value for the specified plane.
+ */
+unsigned int image_format_plane_stride(const struct image_format_info *format,
+  unsigned int width, int plane)
+{
+   if (!format || plane >= format->num_planes)
+   return 0;
+
+   return image_format_plane_width(width, format, plane) *
+   image_format_plane_cpp(format, plane);
+}
+EXPORT_SYMBOL(image_format_plane_stride);
+
+/**
  * image_format_plane_height - height of the plane given the first plane
  * @format: pointer to the image_format
  * @height: height of the first plane
@@ -763,6 +783,28 @@ unsigned int image_format_plane_height(int height,
 EXPORT_SYMBOL(image_format_plane_height);
 
 /**
+ * image_format_plane_size - determine the size value
+ * @format: pointer to the image_format
+ * @width: plane width
+ * @height: plane width
+ * @plane: plane index
+ *
+ * Returns:
+ * The size of the plane buffer.
+ */
+unsigned int image_format_plane_size(const struct image_format_info *format,
+unsigned int width, unsigned int height,
+int plane)
+{
+   if (!format || plane >= format->num_planes)
+   return 0;
+
+   return image_format_plane_stride(format, width, plane) *
+   image_format_plane_height(format, height, plane);
+}
+EXPORT_SYMBOL(image_format_plane_size);
+
+/**
  * image_format_block_width - width in pixels of block.
  * @format: pointer to the image_format
  * @plane: plane index
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 16/20] drm/tegra: Convert to generic image format library

[Maxime Ripard]

Now that we have a generic image format libary, let's convert drivers to
use it so that we can deprecate the old DRM one.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/tegra/plane.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/plane.c b/drivers/gpu/drm/tegra/plane.c
index d068e8aa3553..e1d82cbdabe8 100644
--- a/drivers/gpu/drm/tegra/plane.c
+++ b/drivers/gpu/drm/tegra/plane.c
@@ -6,6 +6,8 @@
  * published by the Free Software Foundation.
  */
 
+#include 
+
 #include 
 #include 
 #include 
@@ -76,7 +78,7 @@ static bool tegra_plane_format_mod_supported(struct drm_plane 
*plane,
 uint32_t format,
 uint64_t modifier)
 {
-   const struct drm_format_info *info = drm_format_info(format);
+   const struct image_format_info *info = image_format_drm_lookup(format);
 
if (modifier == DRM_FORMAT_MOD_LINEAR)
return true;
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 17/20] drm/fourcc: Remove old DRM format API

[Maxime Ripard]

Now that all the clients of the old drm_format* API have been converted to
the generic one, let's remove it.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/Kconfig |   1 +-
 drivers/gpu/drm/drm_fourcc.c| 253 +
 drivers/gpu/drm/selftests/Makefile  |   3 +-
 drivers/gpu/drm/selftests/drm_modeset_selftests.h   |   3 +-
 drivers/gpu/drm/selftests/test-drm_format.c | 280 +-
 drivers/gpu/drm/selftests/test-drm_modeset_common.h |   3 +-
 include/drm/drm_fourcc.h| 216 +--
 7 files changed, 2 insertions(+), 757 deletions(-)
 delete mode 100644 drivers/gpu/drm/selftests/test-drm_format.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 7992a95ea965..cfc50fc92497 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -54,6 +54,7 @@ config DRM_DEBUG_SELFTEST
tristate "kselftests for DRM"
depends on DRM
depends on DEBUG_KERNEL
+   select IMAGE_FORMATS_SELFTESTS
select PRIME_NUMBERS
select DRM_LIB_RANDOM
select DRM_KMS_HELPER
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 6ddb1c28be49..4f262e1a202a 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -150,136 +150,6 @@ const char *drm_get_format_name(uint32_t format, struct 
drm_format_name_buf *buf
 }
 EXPORT_SYMBOL(drm_get_format_name);
 
-/*
- * Internal function to query information for a given format. See
- * drm_format_info() for the public API.
- */
-const struct drm_format_info *__drm_format_info(u32 format)
-{
-   static const struct drm_format_info formats[] = {
-   { .format = DRM_FORMAT_C8,  .depth = 8,  
.num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
-   { .format = DRM_FORMAT_RGB332,  .depth = 8,  
.num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
-   { .format = DRM_FORMAT_BGR233,  .depth = 8,  
.num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
-   { .format = DRM_FORMAT_XRGB,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-   { .format = DRM_FORMAT_XBGR,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-   { .format = DRM_FORMAT_RGBX,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-   { .format = DRM_FORMAT_BGRX,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-   { .format = DRM_FORMAT_ARGB,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
-   { .format = DRM_FORMAT_ABGR,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
-   { .format = DRM_FORMAT_RGBA,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
-   { .format = DRM_FORMAT_BGRA,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
-   { .format = DRM_FORMAT_XRGB1555,.depth = 15, 
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-   { .format = DRM_FORMAT_XBGR1555,.depth = 15, 
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-   { .format = DRM_FORMAT_RGBX5551,.depth = 15, 
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-   { .format = DRM_FORMAT_BGRX5551,.depth = 15, 
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-   { .format = DRM_FORMAT_ARGB1555,.depth = 15, 
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
-   { .format = DRM_FORMAT_ABGR1555,.depth = 15, 
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
-   { .format = DRM_FORMAT_RGBA5551,.depth = 15, 
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
-   { .format = DRM_FORMAT_BGRA5551,.depth = 15, 
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
-   { .format = DRM_FORMAT_RGB565,  .depth = 16, 
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-   { .format = DRM_FORMAT_BGR565,  .depth = 16, 
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 },
-   { .format = DRM_FORMAT_RGB888,  .depth = 24, 
.num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1 },
-   { .format = DRM_FORMAT_BGR888,  .depth = 24, 
.num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1 },
-   { .format = DRM_FORMAT_XRGB,.depth = 24, 
.num_planes = 1, .cpp = { 4, 0, 0 }, 

[RFC PATCH 20/20] media: sun6i: Convert to the image format API

[Maxime Ripard]

The image format API allows us to remove some of the computation we need to
handle the various video formats.

Signed-off-by: Maxime Ripard 
---
 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 88 +++
 drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h | 46 +
 2 files changed, 22 insertions(+), 112 deletions(-)

diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
index 6950585edb5a..d4693efb9e02 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -466,72 +466,27 @@ static void sun6i_csi_set_format(struct sun6i_csi_dev 
*sdev)
 static void sun6i_csi_set_window(struct sun6i_csi_dev *sdev)
 {
struct sun6i_csi_config *config = >csi.config;
-   u32 bytesperline_y;
-   u32 bytesperline_c;
+   const struct image_format_info *info =
+   image_format_v4l2_lookup(config->pixelformat);
int *planar_offset = sdev->planar_offset;
-   u32 width = config->width;
-   u32 height = config->height;
-   u32 hor_len = width;
+   u32 bytesperline_y = image_format_plane_stride(info, config->width, 0);
+   u32 bytesperline_c = image_format_plane_stride(info, config->width, 1);
+   unsigned int i;
 
-   switch (config->pixelformat) {
-   case V4L2_PIX_FMT_YUYV:
-   case V4L2_PIX_FMT_YVYU:
-   case V4L2_PIX_FMT_UYVY:
-   case V4L2_PIX_FMT_VYUY:
-   dev_dbg(sdev->dev,
-   "Horizontal length should be 2 times of width for 
packed YUV formats!\n");
-   hor_len = width * 2;
-   break;
-   default:
-   break;
+   offset = 0;
+   for (i = 0; i < info->num_planes; i++) {
+   planar_offset[i] = offset;
+
+   offset += info_format_plane_size(info, config->width,
+config->height, i);
}
 
regmap_write(sdev->regmap, CSI_CH_HSIZE_REG,
-CSI_CH_HSIZE_HOR_LEN(hor_len) |
+CSI_CH_HSIZE_HOR_LEN(bytesperline_c) |
 CSI_CH_HSIZE_HOR_START(0));
regmap_write(sdev->regmap, CSI_CH_VSIZE_REG,
-CSI_CH_VSIZE_VER_LEN(height) |
+CSI_CH_VSIZE_VER_LEN(config->height) |
 CSI_CH_VSIZE_VER_START(0));
-
-   planar_offset[0] = 0;
-   switch (config->pixelformat) {
-   case V4L2_PIX_FMT_HM12:
-   case V4L2_PIX_FMT_NV12:
-   case V4L2_PIX_FMT_NV21:
-   case V4L2_PIX_FMT_NV16:
-   case V4L2_PIX_FMT_NV61:
-   bytesperline_y = width;
-   bytesperline_c = width;
-   planar_offset[1] = bytesperline_y * height;
-   planar_offset[2] = -1;
-   break;
-   case V4L2_PIX_FMT_YUV420:
-   case V4L2_PIX_FMT_YVU420:
-   bytesperline_y = width;
-   bytesperline_c = width / 2;
-   planar_offset[1] = bytesperline_y * height;
-   planar_offset[2] = planar_offset[1] +
-   bytesperline_c * height / 2;
-   break;
-   case V4L2_PIX_FMT_YUV422P:
-   bytesperline_y = width;
-   bytesperline_c = width / 2;
-   planar_offset[1] = bytesperline_y * height;
-   planar_offset[2] = planar_offset[1] +
-   bytesperline_c * height;
-   break;
-   default: /* raw */
-   dev_dbg(sdev->dev,
-   "Calculating pixelformat(0x%x)'s bytesperline as a 
packed format\n",
-   config->pixelformat);
-   bytesperline_y = (sun6i_csi_get_bpp(config->pixelformat) *
- config->width) / 8;
-   bytesperline_c = 0;
-   planar_offset[1] = -1;
-   planar_offset[2] = -1;
-   break;
-   }
-
regmap_write(sdev->regmap, CSI_CH_BUF_LEN_REG,
 CSI_CH_BUF_LEN_BUF_LEN_C(bytesperline_c) |
 CSI_CH_BUF_LEN_BUF_LEN_Y(bytesperline_y));
@@ -557,15 +512,16 @@ int sun6i_csi_update_config(struct sun6i_csi *csi,
 void sun6i_csi_update_buf_addr(struct sun6i_csi *csi, dma_addr_t addr)
 {
struct sun6i_csi_dev *sdev = sun6i_csi_to_dev(csi);
+   struct sun6i_csi_config *config = >csi.config;
+   const struct image_format_info *info =
+   image_format_v4l2_lookup(config->pixelformat);
+   unsigned int i;
+
+   for (i = 0; i < info->num_planes; i++) {
+   regmap_write(sdev->regmap, CSI_CH_BUF_REG(i, 0),
+(addr + sdev->planar_offset[i]) >> 2);
 
-   regmap_write(sdev->regmap, CSI_CH_F0_BUFA_REG,
-(addr + sdev->planar_offset[0]) >> 2);
-   if (sdev->planar_offset[1] != -1)
-   regmap_write(sdev->regmap, CSI_CH_F1_BUFA_REG,
-  

[RFC PATCH 08/20] drm/malidp: Convert to generic image format library

[Maxime Ripard]

Now that we have a generic image format libary, let's convert drivers to
use it so that we can deprecate the old DRM one.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/arm/malidp_drv.c | 3 ++-
 drivers/gpu/drm/arm/malidp_hw.c  | 4 ++--
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index fec4fe15a71b..1fcbe364a137 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -10,6 +10,7 @@
  * ARM Mali DP500/DP550/DP650 KMS/DRM driver
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -314,7 +315,7 @@ malidp_verify_afbc_framebuffer_size(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *mode_cmd)
 {
int n_superblocks = 0;
-   const struct drm_format_info *info;
+   const struct image_format_info *info;
struct drm_gem_object *objs = NULL;
u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
u32 afbc_superblock_width = 0, afbc_size = 0;
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 07971ad53b29..d25bc4af1bc9 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -326,14 +326,14 @@ static void malidp500_modeset(struct malidp_hw_device 
*hwdev, struct videomode *
 
 static int malidp500_rotmem_required(struct malidp_hw_device *hwdev, u16 w, 
u16 h, u32 fmt)
 {
-   const struct drm_format_info *info = drm_format_info(fmt);
+   const struct image_format_info *info = image_format_drm_lookup(fmt);
 
/*
 * Each layer needs enough rotation memory to fit 8 lines
 * worth of pixel data. Required size is then:
 *size = rotated_width * (bpp / 8) * 8;
 */
-   return w * drm_format_plane_cpp(info, 0) * 8;
+   return w * image_format_plane_cpp(info, 0) * 8;
 }
 
 static void malidp500_se_write_pp_coefftab(struct malidp_hw_device *hwdev,
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 06/20] lib: Add video format information library

[Maxime Ripard]

Move the DRM formats API to turn this into a more generic image formats API
to be able to leverage it into some other places of the kernel, such as
v4l2 drivers.

Signed-off-by: Maxime Ripard 
---
 include/linux/image-formats.h | 240 +++-
 lib/Kconfig   |   7 +-
 lib/Makefile  |   3 +-
 lib/image-formats-selftests.c | 326 +++-
 lib/image-formats.c   | 760 +++-
 5 files changed, 1336 insertions(+)
 create mode 100644 include/linux/image-formats.h
 create mode 100644 lib/image-formats-selftests.c
 create mode 100644 lib/image-formats.c

diff --git a/include/linux/image-formats.h b/include/linux/image-formats.h
new file mode 100644
index ..53fd73a71b3d
--- /dev/null
+++ b/include/linux/image-formats.h
@@ -0,0 +1,240 @@
+#ifndef _IMAGE_FORMATS_H_
+#define _IMAGE_FORMATS_H_
+
+#include 
+
+/**
+ * struct image_format_info - information about a image format
+ */
+struct image_format_info {
+   union {
+   /**
+* @drm_fmt:
+*
+* DRM 4CC format identifier (DRM_FORMAT_*)
+*/
+   u32 drm_fmt;
+
+   /**
+* @format:
+*
+* DRM 4CC format identifier (DRM_FORMAT_*). Kept
+* around for compatibility reasons with the current
+* DRM drivers.
+*/
+   u32 format;
+   };
+
+   /**
+* @depth:
+*
+* Color depth (number of bits per pixel excluding padding bits),
+* valid for a subset of RGB formats only. This is a legacy field, do
+* not use in new code and set to 0 for new formats.
+*/
+   u8 depth;
+
+   /** @num_planes: Number of color planes (1 to 3) */
+   u8 num_planes;
+
+   union {
+   /**
+* @cpp:
+*
+* Number of bytes per pixel (per plane), this is aliased with
+* @char_per_block. It is deprecated in favour of using the
+* triplet @char_per_block, @block_w, @block_h for better
+* describing the pixel format.
+*/
+   u8 cpp[3];
+
+   /**
+* @char_per_block:
+*
+* Number of bytes per block (per plane), where blocks are
+* defined as a rectangle of pixels which are stored next to
+* each other in a byte aligned memory region. Together with
+* @block_w and @block_h this is used to properly describe tiles
+* in tiled formats or to describe groups of pixels in packed
+* formats for which the memory needed for a single pixel is not
+* byte aligned.
+*
+* @cpp has been kept for historical reasons because there are
+* a lot of places in drivers where it's used. In drm core for
+* generic code paths the preferred way is to use
+* @char_per_block, image_format_block_width() and
+* image_format_block_height() which allows handling both
+* block and non-block formats in the same way.
+*
+* For formats that are intended to be used only with non-linear
+* modifiers both @cpp and @char_per_block must be 0 in the
+* generic format table. Drivers could supply accurate
+* information from their drm_mode_config.get_format_info hook
+* if they want the core to be validating the pitch.
+*/
+   u8 char_per_block[3];
+   };
+
+   /**
+* @block_w:
+*
+* Block width in pixels, this is intended to be accessed through
+* image_format_block_width()
+*/
+   u8 block_w[3];
+
+   /**
+* @block_h:
+*
+* Block height in pixels, this is intended to be accessed through
+* image_format_block_height()
+*/
+   u8 block_h[3];
+
+   /** @hsub: Horizontal chroma subsampling factor */
+   u8 hsub;
+   /** @vsub: Vertical chroma subsampling factor */
+   u8 vsub;
+
+   /** @has_alpha: Does the format embeds an alpha component? */
+   bool has_alpha;
+
+   /** @is_yuv: Is it a YUV format? */
+   bool is_yuv;
+};
+
+/**
+ * image_format_info_is_yuv_packed - check that the format info matches a YUV
+ * format with data laid in a single plane
+ * @info: format info
+ *
+ * Returns:
+ * A boolean indicating whether the format info matches a packed YUV format.
+ */
+static inline bool
+image_format_info_is_yuv_packed(const struct image_format_info *info)
+{
+   return info->is_yuv && info->num_planes == 1;
+}
+
+/**
+ * image_format_info_is_yuv_semiplanar - check that the format info matches a 
YUV
+ * format with data laid in two 

[RFC PATCH 13/20] drm/msm: Convert to generic image format library

[Maxime Ripard]

Now that we have a generic image format libary, let's convert drivers to
use it so that we can deprecate the old DRM one.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c |  6 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c   |  3 ++-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c   |  3 ++-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c  |  9 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c|  3 ++-
 5 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
index 1aed51b49be4..8c3c953b05d9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
@@ -12,6 +12,8 @@
 
 #define pr_fmt(fmt)"[drm:%s:%d] " fmt, __func__, __LINE__
 
+#include 
+
 #include 
 
 #include "msm_media_info.h"
@@ -1040,7 +1042,7 @@ int dpu_format_check_modified_format(
const struct drm_mode_fb_cmd2 *cmd,
struct drm_gem_object **bos)
 {
-   const struct drm_format_info *info;
+   const struct image_format_info *info;
const struct dpu_format *fmt;
struct dpu_hw_fmt_layout layout;
uint32_t bos_total_size = 0;
@@ -1052,7 +1054,7 @@ int dpu_format_check_modified_format(
}
 
fmt = to_dpu_format(msm_fmt);
-   info = drm_format_info(fmt->base.pixel_format);
+   info = image_format_drm_lookup(fmt->base.pixel_format);
if (!info)
return -EINVAL;
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index a9492c488441..1dfaa306ed4b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -20,6 +20,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -553,7 +554,7 @@ static void _dpu_plane_setup_scaler(struct dpu_plane *pdpu,
struct dpu_plane_state *pstate,
const struct dpu_format *fmt, bool color_fill)
 {
-   const struct drm_format_info *info = 
drm_format_info(fmt->base.pixel_format);
+   const struct image_format_info *info = 
image_format_drm_lookup(fmt->base.pixel_format);
 
/* don't chroma subsample if decimating */
/* update scaler. calculate default config for QSEED3 */
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
index aadae21f8818..542c22c4febe 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c
@@ -16,6 +16,7 @@
  * this program.  If not, see .
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -782,7 +783,7 @@ static void get_roi(struct drm_crtc *crtc, uint32_t *roi_w, 
uint32_t *roi_h)
 
 static void mdp5_crtc_restore_cursor(struct drm_crtc *crtc)
 {
-   const struct drm_format_info *info = 
drm_format_info(DRM_FORMAT_ARGB);
+   const struct image_format_info *info = 
image_format_drm_lookup(DRM_FORMAT_ARGB);
struct mdp5_crtc_state *mdp5_cstate = to_mdp5_crtc_state(crtc->state);
struct mdp5_crtc *mdp5_crtc = to_mdp5_crtc(crtc);
struct mdp5_kms *mdp5_kms = get_kms(crtc);
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
index 9d9fb6c5fd68..00091637a00c 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c
@@ -17,6 +17,7 @@
  */
 
 #include 
+#include 
 #include "mdp5_kms.h"
 
 struct mdp5_plane {
@@ -650,7 +651,7 @@ static int calc_scalex_steps(struct drm_plane *plane,
uint32_t pixel_format, uint32_t src, uint32_t dest,
uint32_t phasex_steps[COMP_MAX])
 {
-   const struct drm_format_info *info = drm_format_info(pixel_format);
+   const struct image_format_info *info = 
image_format_drm_lookup(pixel_format);
struct mdp5_kms *mdp5_kms = get_kms(plane);
struct device *dev = mdp5_kms->dev->dev;
uint32_t phasex_step;
@@ -673,7 +674,7 @@ static int calc_scaley_steps(struct drm_plane *plane,
uint32_t pixel_format, uint32_t src, uint32_t dest,
uint32_t phasey_steps[COMP_MAX])
 {
-   const struct drm_format_info *info = drm_format_info(pixel_format);
+   const struct image_format_info *info = 
image_format_drm_lookup(pixel_format);
struct mdp5_kms *mdp5_kms = get_kms(plane);
struct device *dev = mdp5_kms->dev->dev;
uint32_t phasey_step;
@@ -695,7 +696,7 @@ static int calc_scaley_steps(struct drm_plane *plane,
 static uint32_t get_scale_config(const struct mdp_format *format,
uint32_t src, uint32_t dst, bool horz)
 {
-   const struct drm_format_info *info = 
drm_format_info(format->base.pixel_format);
+   const struct image_format_info *info = 
image_format_drm_lookup(format->base.pixel_format);
bool scaling = format->is_yuv ? true : (src != dst);
uint32_t 

[RFC PATCH 09/20] drm/client: Convert to generic image format library

[Maxime Ripard]

Now that we have a generic image format libary, let's convert the rest of
the DRM core to use it so that we can deprecate the old DRM one.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_client.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 9df52b7fd074..a48181e18934 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -243,7 +243,7 @@ static void drm_client_buffer_delete(struct 
drm_client_buffer *buffer)
 static struct drm_client_buffer *
 drm_client_buffer_create(struct drm_client_dev *client, u32 width, u32 height, 
u32 format)
 {
-   const struct drm_format_info *info = drm_format_info(format);
+   const struct image_format_info *info = image_format_drm_lookup(format);
struct drm_mode_create_dumb dumb_args = { };
struct drm_device *dev = client->dev;
struct drm_client_buffer *buffer;
@@ -259,7 +259,7 @@ drm_client_buffer_create(struct drm_client_dev *client, u32 
width, u32 height, u
 
dumb_args.width = width;
dumb_args.height = height;
-   dumb_args.bpp = drm_format_plane_cpp(info, 0) * 8;
+   dumb_args.bpp = image_format_plane_cpp(info, 0) * 8;
ret = drm_mode_create_dumb(dev, _args, client->file);
if (ret)
goto err_delete;
@@ -319,10 +319,10 @@ static int drm_client_buffer_addfb(struct 
drm_client_buffer *buffer,
 {
struct drm_client_dev *client = buffer->client;
struct drm_mode_fb_cmd fb_req = { };
-   const struct drm_format_info *info;
+   const struct image_format_info *info;
int ret;
 
-   info = drm_format_info(format);
+   info = image_format_drm_lookup(format);
fb_req.bpp = info->cpp[0] * 8;
fb_req.depth = info->depth;
fb_req.width = width;
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 03/20] drm/fourcc: Pass the format_info pointer to drm_format_plane_cpp

[Maxime Ripard]

So far, the drm_format_plane_cpp function was operating on the format's
fourcc and was doing a lookup to retrieve the drm_format_info structure and
return the cpp.

However, this is inefficient since in most cases, we will have the
drm_format_info pointer already available so we shouldn't have to perform a
new lookup. Some drm_fourcc functions also already operate on the
drm_format_info pointer for that reason, so the API is quite inconsistent
there.

Let's follow the latter pattern and remove the extra lookup while being a
bit more consistent.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 4 +++-
 drivers/gpu/drm/arm/malidp_hw.c| 4 +++-
 drivers/gpu/drm/cirrus/cirrus_fbdev.c  | 4 +++-
 drivers/gpu/drm/cirrus/cirrus_main.c   | 4 +++-
 drivers/gpu/drm/drm_client.c   | 3 ++-
 drivers/gpu/drm/drm_fb_helper.c| 2 +-
 drivers/gpu/drm/drm_fourcc.c   | 7 ++-
 drivers/gpu/drm/i915/intel_sprite.c| 3 ++-
 drivers/gpu/drm/mediatek/mtk_drm_fb.c  | 2 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c  | 3 ++-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c   | 2 +-
 drivers/gpu/drm/msm/msm_fb.c   | 2 +-
 drivers/gpu/drm/radeon/radeon_fb.c | 4 +++-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 2 +-
 drivers/gpu/drm/stm/ltdc.c | 2 +-
 drivers/gpu/drm/tegra/fb.c | 2 +-
 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 2 +-
 drivers/gpu/drm/zte/zx_plane.c | 2 +-
 include/drm/drm_fourcc.h   | 2 +-
 19 files changed, 33 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 5cbde74b97dd..48170a843b48 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -123,6 +123,8 @@ static int amdgpufb_create_pinned_object(struct 
amdgpu_fbdev *rfbdev,
 struct drm_mode_fb_cmd2 *mode_cmd,
 struct drm_gem_object **gobj_p)
 {
+   const struct drm_format_info *info = drm_get_format_info(dev,
+mode_cmd);
struct amdgpu_device *adev = rfbdev->adev;
struct drm_gem_object *gobj = NULL;
struct amdgpu_bo *abo = NULL;
@@ -133,7 +135,7 @@ static int amdgpufb_create_pinned_object(struct 
amdgpu_fbdev *rfbdev,
int height = mode_cmd->height;
u32 cpp;
 
-   cpp = drm_format_plane_cpp(mode_cmd->pixel_format, 0);
+   cpp = drm_format_plane_cpp(info, 0);
 
/* need to align pitch with crtc limits */
mode_cmd->pitches[0] = amdgpu_align_pitch(adev, mode_cmd->width, cpp,
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index b9bed1138fa3..07971ad53b29 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -326,12 +326,14 @@ static void malidp500_modeset(struct malidp_hw_device 
*hwdev, struct videomode *
 
 static int malidp500_rotmem_required(struct malidp_hw_device *hwdev, u16 w, 
u16 h, u32 fmt)
 {
+   const struct drm_format_info *info = drm_format_info(fmt);
+
/*
 * Each layer needs enough rotation memory to fit 8 lines
 * worth of pixel data. Required size is then:
 *size = rotated_width * (bpp / 8) * 8;
 */
-   return w * drm_format_plane_cpp(fmt, 0) * 8;
+   return w * drm_format_plane_cpp(info, 0) * 8;
 }
 
 static void malidp500_se_write_pp_coefftab(struct malidp_hw_device *hwdev,
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index 39df62acac69..759847bafda8 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -137,6 +137,8 @@ static int cirrusfb_create_object(struct cirrus_fbdev 
*afbdev,
   const struct drm_mode_fb_cmd2 *mode_cmd,
   struct drm_gem_object **gobj_p)
 {
+   const struct drm_format_info *info = drm_get_format_info(dev,
+mode_cmd);
struct drm_device *dev = afbdev->helper.dev;
struct cirrus_device *cdev = dev->dev_private;
u32 bpp;
@@ -144,7 +146,7 @@ static int cirrusfb_create_object(struct cirrus_fbdev 
*afbdev,
struct drm_gem_object *gobj;
int ret = 0;
 
-   bpp = drm_format_plane_cpp(mode_cmd->pixel_format, 0) * 8;
+   bpp = drm_format_plane_cpp(info, 0) * 8;
 
if (!cirrus_check_framebuffer(cdev, mode_cmd->width, mode_cmd->height,
  bpp, mode_cmd->pitches[0]))
diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c 
b/drivers/gpu/drm/cirrus/cirrus_main.c
index 57f8fe6d020b..66d0d2c5211d 100644
--- a/drivers/gpu/drm/cirrus/cirrus_main.c
+++ 

[RFC PATCH 05/20] drm: Replace instances of drm_format_info by drm_get_format_info

[Maxime Ripard]

drm_get_format_info directly calls into drm_format_info, but takes directly
a struct drm_mode_fb_cmd2 pointer, instead of the fourcc directly. It's
shorter to not dereference it, and we can customise the behaviour at the
driver level if we want to, so let's switch to it where it makes sense.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/gma500/framebuffer.c | 2 +-
 drivers/gpu/drm/omapdrm/omap_fb.c| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/gma500/framebuffer.c 
b/drivers/gpu/drm/gma500/framebuffer.c
index c934b3df1f81..46f0078f7a91 100644
--- a/drivers/gpu/drm/gma500/framebuffer.c
+++ b/drivers/gpu/drm/gma500/framebuffer.c
@@ -232,7 +232,7 @@ static int psb_framebuffer_init(struct drm_device *dev,
 * Reject unknown formats, YUV formats, and formats with more than
 * 4 bytes per pixel.
 */
-   info = drm_format_info(mode_cmd->pixel_format);
+   info = drm_get_format_info(dev, mode_cmd);
if (!info || !info->depth || info->cpp[0] > 4)
return -EINVAL;
 
diff --git a/drivers/gpu/drm/omapdrm/omap_fb.c 
b/drivers/gpu/drm/omapdrm/omap_fb.c
index cfb641363a32..6557b2d6e16e 100644
--- a/drivers/gpu/drm/omapdrm/omap_fb.c
+++ b/drivers/gpu/drm/omapdrm/omap_fb.c
@@ -339,7 +339,7 @@ struct drm_framebuffer *omap_framebuffer_init(struct 
drm_device *dev,
dev, mode_cmd, mode_cmd->width, mode_cmd->height,
(char *)_cmd->pixel_format);
 
-   format = drm_format_info(mode_cmd->pixel_format);
+   format = drm_get_format_info(dev, mode_cmd);
 
for (i = 0; i < ARRAY_SIZE(formats); i++) {
if (formats[i] == mode_cmd->pixel_format)
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 15/20] drm/rockchip: Convert to generic image format library

[Maxime Ripard]

Now that we have a generic image format libary, let's convert drivers to
use it so that we can deprecate the old DRM one.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 88c3902057f3..8f4cfadfd6cd 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -317,7 +318,7 @@ static void scl_vop_cal_scl_fac(struct vop *vop, const 
struct vop_win_data *win,
 uint32_t src_w, uint32_t src_h, uint32_t dst_w,
 uint32_t dst_h, uint32_t pixel_format)
 {
-   const struct drm_format_info *info = drm_format_info(pixel_format);
+   const struct image_format_info *info = 
image_format_drm_lookup(pixel_format);
uint16_t yrgb_hor_scl_mode, yrgb_ver_scl_mode;
uint16_t cbcr_hor_scl_mode = SCALE_NONE;
uint16_t cbcr_ver_scl_mode = SCALE_NONE;
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 00/20] drm: Split out the formats API and move it to a common place

[Maxime Ripard]

Hi,

DRM comes with an extensive format support to retrieve the various
parameters associated with a given format (such as the subsampling, or the
bits per pixel), as well as some helpers and utilities to ease the driver
development.

v4l2, on the other side, doesn't provide such facilities, leaving each
driver reimplement a subset of the formats parameters for the one supported
by that particular driver. This leads to a lot of duplication and
boilerplate code in the v4l2 drivers.

This series tries to address this by moving the DRM format API into lib and
turning it into a more generic API. In order to do this, we've needed to do
some preliminary changes on the DRM drivers, then moved the API and finally
converted a v4l2 driver to give an example of how such library could be
used.

Let me know what you think,
Maxime

Maxime Ripard (20):
  drm: Remove users of drm_format_num_planes
  drm: Remove users of drm_format_(horz|vert)_chroma_subsampling
  drm/fourcc: Pass the format_info pointer to drm_format_plane_cpp
  drm/fourcc: Pass the format_info pointer to drm_format_plane_width/height
  drm: Replace instances of drm_format_info by drm_get_format_info
  lib: Add video format information library
  drm/fb: Move from drm_format_info to image_format_info
  drm/malidp: Convert to generic image format library
  drm/client: Convert to generic image format library
  drm/exynos: Convert to generic image format library
  drm/i915: Convert to generic image format library
  drm/ipuv3: Convert to generic image format library
  drm/msm: Convert to generic image format library
  drm/omap: Convert to generic image format library
  drm/rockchip: Convert to generic image format library
  drm/tegra: Convert to generic image format library
  drm/fourcc: Remove old DRM format API
  lib: image-formats: Add v4l2 formats support
  lib: image-formats: Add more functions
  media: sun6i: Convert to the image format API

 drivers/gpu/drm/Kconfig |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c  |   4 +-
 drivers/gpu/drm/arm/malidp_drv.c|   5 +-
 drivers/gpu/drm/arm/malidp_hw.c |   4 +-
 drivers/gpu/drm/arm/malidp_mw.c |   2 +-
 drivers/gpu/drm/arm/malidp_planes.c |   8 +-
 drivers/gpu/drm/armada/armada_fb.c  |   3 +-
 drivers/gpu/drm/armada/armada_overlay.c |   3 +-
 drivers/gpu/drm/armada/armada_plane.c   |   3 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  13 +-
 drivers/gpu/drm/bochs/bochs.h   |   4 +-
 drivers/gpu/drm/bochs/bochs_hw.c|   3 +-
 drivers/gpu/drm/cirrus/cirrus_fbdev.c   |   4 +-
 drivers/gpu/drm/cirrus/cirrus_main.c|   4 +-
 drivers/gpu/drm/drm_atomic.c|   1 +-
 drivers/gpu/drm/drm_client.c|   8 +-
 drivers/gpu/drm/drm_crtc.c  |   1 +-
 drivers/gpu/drm/drm_fb_cma_helper.c |   5 +-
 drivers/gpu/drm/drm_fb_helper.c |  15 +-
 drivers/gpu/drm/drm_fourcc.c| 318 +-
 drivers/gpu/drm/drm_framebuffer.c   |  11 +-
 drivers/gpu/drm/drm_gem_framebuffer_helper.c|   5 +-
 drivers/gpu/drm/drm_plane.c |   1 +-
 drivers/gpu/drm/exynos/exynos_drm_fb.c  |   3 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.c |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.h |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_scaler.c  |   3 +-
 drivers/gpu/drm/gma500/framebuffer.c|   4 +-
 drivers/gpu/drm/i915/i915_drv.h |   6 +-
 drivers/gpu/drm/i915/intel_display.c|  15 +-
 drivers/gpu/drm/i915/intel_sprite.c |   3 +-
 drivers/gpu/drm/imx/ipuv3-plane.c   |  20 +-
 drivers/gpu/drm/mediatek/mtk_drm_fb.c   |   8 +-
 drivers/gpu/drm/meson/meson_overlay.c   |  14 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c |  11 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c   |  10 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c   |   4 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c  |  25 +-
 drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c|   8 +-
 drivers/gpu/drm/msm/msm_fb.c|  18 +-
 drivers/gpu/drm/omapdrm/dss/dispc.c |   9 +-
 drivers/gpu/drm/omapdrm/omap_fb.c   |  15 +-
 drivers/gpu/drm/radeon/radeon_fb.c  |   4 +-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |  17 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  14 +-
 drivers/gpu/drm/selftests/Makefile  |   3 +-
 drivers/gpu/drm/selftests/drm_modeset_selftests.h   |   3 +-
 drivers/gpu/drm/selftests/test-drm_format.c | 280 +
 drivers/gpu/drm/selftests/test-drm_modeset_common.h |   3 +-
 

[RFC PATCH 01/20] drm: Remove users of drm_format_num_planes

[Maxime Ripard]

drm_format_num_planes() is basically a lookup in the drm_format_info table
plus an access to the num_planes field of the appropriate entry.

Most drivers are using this function while having access to the entry
already, which means that we will perform an unnecessary lookup. Removing
the call to drm_format_num_planes is therefore more efficient.

Some drivers will not have access to that entry in the function, but in
this case the overhead is minimal (we just have to call drm_format_info()
to perform the lookup) and we can even avoid multiple, inefficient lookups
in some places that need multiple fields from the drm_format_info
structure.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/arm/malidp_mw.c |  2 +-
 drivers/gpu/drm/armada/armada_fb.c  |  3 ++-
 drivers/gpu/drm/drm_fourcc.c| 16 
 drivers/gpu/drm/mediatek/mtk_drm_fb.c   |  6 --
 drivers/gpu/drm/meson/meson_overlay.c   |  2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c |  9 ++---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c|  3 ++-
 drivers/gpu/drm/msm/msm_fb.c|  8 ++--
 drivers/gpu/drm/omapdrm/omap_fb.c   |  4 +++-
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |  6 +++---
 drivers/gpu/drm/tegra/fb.c  |  3 ++-
 drivers/gpu/drm/vc4/vc4_plane.c |  2 +-
 drivers/gpu/drm/zte/zx_plane.c  |  4 +---
 include/drm/drm_fourcc.h|  1 -
 14 files changed, 32 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index 041a64dc7167..91580b7a3781 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -153,7 +153,7 @@ malidp_mw_encoder_atomic_check(struct drm_encoder *encoder,
return -EINVAL;
}
 
-   n_planes = drm_format_num_planes(fb->format->format);
+   n_planes = fb->format->num_planes;
for (i = 0; i < n_planes; i++) {
struct drm_gem_cma_object *obj = drm_fb_cma_get_gem_obj(fb, i);
/* memory write buffers are never rotated */
diff --git a/drivers/gpu/drm/armada/armada_fb.c 
b/drivers/gpu/drm/armada/armada_fb.c
index 058ac7d9920f..a2f6472eb482 100644
--- a/drivers/gpu/drm/armada/armada_fb.c
+++ b/drivers/gpu/drm/armada/armada_fb.c
@@ -87,6 +87,7 @@ struct armada_framebuffer *armada_framebuffer_create(struct 
drm_device *dev,
 struct drm_framebuffer *armada_fb_create(struct drm_device *dev,
struct drm_file *dfile, const struct drm_mode_fb_cmd2 *mode)
 {
+   const struct drm_format_info *info = drm_get_format_info(dev, mode);
struct armada_gem_object *obj;
struct armada_framebuffer *dfb;
int ret;
@@ -97,7 +98,7 @@ struct drm_framebuffer *armada_fb_create(struct drm_device 
*dev,
mode->pitches[2]);
 
/* We can only handle a single plane at the moment */
-   if (drm_format_num_planes(mode->pixel_format) > 1 &&
+   if (info->num_planes > 1 &&
(mode->handles[0] != mode->handles[1] ||
 mode->handles[0] != mode->handles[2])) {
ret = -EINVAL;
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index ba7e19d4336c..22c7fa459f65 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -306,22 +306,6 @@ drm_get_format_info(struct drm_device *dev,
 EXPORT_SYMBOL(drm_get_format_info);
 
 /**
- * drm_format_num_planes - get the number of planes for format
- * @format: pixel format (DRM_FORMAT_*)
- *
- * Returns:
- * The number of planes used by the specified pixel format.
- */
-int drm_format_num_planes(uint32_t format)
-{
-   const struct drm_format_info *info;
-
-   info = drm_format_info(format);
-   return info ? info->num_planes : 1;
-}
-EXPORT_SYMBOL(drm_format_num_planes);
-
-/**
  * drm_format_plane_cpp - determine the bytes per pixel value
  * @format: pixel format (DRM_FORMAT_*)
  * @plane: plane index
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_fb.c 
b/drivers/gpu/drm/mediatek/mtk_drm_fb.c
index e20fcaef2851..68fdef8b12bd 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_fb.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_fb.c
@@ -32,10 +32,11 @@ static struct drm_framebuffer 
*mtk_drm_framebuffer_init(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *mode,
struct drm_gem_object *obj)
 {
+   const struct drm_format_info *info = drm_get_format_info(dev, mode);
struct drm_framebuffer *fb;
int ret;
 
-   if (drm_format_num_planes(mode->pixel_format) != 1)
+   if (info->num_planes != 1)
return ERR_PTR(-EINVAL);
 
fb = kzalloc(sizeof(*fb), GFP_KERNEL);
@@ -88,6 +89,7 @@ struct drm_framebuffer *mtk_drm_mode_fb_create(struct 
drm_device *dev,
   struct drm_file *file,
   const struct 

[RFC PATCH 11/20] drm/i915: Convert to generic image format library

[Maxime Ripard]

Now that we have a generic image format libary, let's convert drivers to
use it so that we can deprecate the old DRM one.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/i915/intel_display.c | 4 ++--
 drivers/gpu/drm/i915/intel_sprite.c  | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 86febe2ee510..37c7f6bbf650 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7997,7 +7997,7 @@ i9xx_get_initial_plane_config(struct intel_crtc *crtc,
 
pixel_format = val & DISPPLANE_PIXFORMAT_MASK;
fourcc = i9xx_format_to_fourcc(pixel_format);
-   fb->format = drm_format_info(fourcc);
+   fb->format = image_format_drm_lookup(fourcc);
 
if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
offset = I915_READ(DSPOFFSET(i9xx_plane));
@@ -9078,7 +9078,7 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
 
fourcc = skl_format_to_fourcc(pixel_format,
  val & PLANE_CTL_ORDER_RGBX, alpha);
-   fb->format = drm_format_info(fourcc);
+   fb->format = image_format_drm_lookup(fourcc);
 
tiling = val & PLANE_CTL_TILED_MASK;
switch (tiling) {
diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
b/drivers/gpu/drm/i915/intel_sprite.c
index ee0e99b13532..aaae2bd4ed05 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -297,8 +297,8 @@ skl_plane_max_stride(struct intel_plane *plane,
 u32 pixel_format, u64 modifier,
 unsigned int rotation)
 {
-   const struct drm_format_info *info = drm_format_info(pixel_format);
-   int cpp = drm_format_plane_cpp(info, 0);
+   const struct image_format_info *info = 
image_format_drm_lookup(pixel_format);
+   int cpp = image_format_plane_cpp(info, 0);
 
/*
 * "The stride in bytes must not exceed the
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 02/20] drm: Remove users of drm_format_(horz|vert)_chroma_subsampling

[Maxime Ripard]

drm_format_horz_chroma_subsampling and drm_format_vert_chroma_subsampling
are basically a lookup in the drm_format_info table plus an access to the
hsub and vsub fields of the appropriate entry.

Most drivers are using this function while having access to the entry
already, which means that we will perform an unnecessary lookup. Removing
the call to these functions is therefore more efficient.

Some drivers will not have access to that entry in the function, but in
this case the overhead is minimal (we just have to call drm_format_info()
to perform the lookup) and we can even avoid multiple, inefficient lookups
in some places that need multiple fields from the drm_format_info
structure.

This is amplified by the fact that most of the time the callers will have
to retrieve both the vsub and hsub fields, meaning that they would perform
twice the lookup.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  9 +
 drivers/gpu/drm/drm_fourcc.c| 34 +--
 drivers/gpu/drm/imx/ipuv3-plane.c   | 15 +++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c   |  9 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c  | 24 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c|  2 +-
 drivers/gpu/drm/msm/msm_fb.c|  8 +---
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |  9 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 13 ++-
 drivers/gpu/drm/tegra/fb.c  |  9 +
 drivers/gpu/drm/vc4/vc4_plane.c | 13 ++-
 include/drm/drm_fourcc.h|  2 +-
 12 files changed, 37 insertions(+), 110 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index e836e2de35ce..fdd607ad27fe 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -603,8 +603,6 @@ static int atmel_hlcdc_plane_atomic_check(struct drm_plane 
*p,
const struct drm_display_mode *mode;
struct drm_crtc_state *crtc_state;
unsigned int tmp;
-   int hsub = 1;
-   int vsub = 1;
int ret;
int i;
 
@@ -642,13 +640,10 @@ static int atmel_hlcdc_plane_atomic_check(struct 
drm_plane *p,
if (state->nplanes > ATMEL_HLCDC_LAYER_MAX_PLANES)
return -EINVAL;
 
-   hsub = drm_format_horz_chroma_subsampling(fb->format->format);
-   vsub = drm_format_vert_chroma_subsampling(fb->format->format);
-
for (i = 0; i < state->nplanes; i++) {
unsigned int offset = 0;
-   int xdiv = i ? hsub : 1;
-   int ydiv = i ? vsub : 1;
+   int xdiv = i ? fb->format->hsub : 1;
+   int ydiv = i ? fb->format->vsub : 1;
 
state->bpp[i] = fb->format->cpp[i];
if (!state->bpp[i])
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 22c7fa459f65..04be330b7cae 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -326,40 +326,6 @@ int drm_format_plane_cpp(uint32_t format, int plane)
 EXPORT_SYMBOL(drm_format_plane_cpp);
 
 /**
- * drm_format_horz_chroma_subsampling - get the horizontal chroma subsampling 
factor
- * @format: pixel format (DRM_FORMAT_*)
- *
- * Returns:
- * The horizontal chroma subsampling factor for the
- * specified pixel format.
- */
-int drm_format_horz_chroma_subsampling(uint32_t format)
-{
-   const struct drm_format_info *info;
-
-   info = drm_format_info(format);
-   return info ? info->hsub : 1;
-}
-EXPORT_SYMBOL(drm_format_horz_chroma_subsampling);
-
-/**
- * drm_format_vert_chroma_subsampling - get the vertical chroma subsampling 
factor
- * @format: pixel format (DRM_FORMAT_*)
- *
- * Returns:
- * The vertical chroma subsampling factor for the
- * specified pixel format.
- */
-int drm_format_vert_chroma_subsampling(uint32_t format)
-{
-   const struct drm_format_info *info;
-
-   info = drm_format_info(format);
-   return info ? info->vsub : 1;
-}
-EXPORT_SYMBOL(drm_format_vert_chroma_subsampling);
-
-/**
  * drm_format_plane_width - width of the plane given the first plane
  * @width: width of the first plane
  * @format: pixel format
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 21e964f6ab5c..2530143281b2 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -115,8 +115,8 @@ drm_plane_state_to_ubo(struct drm_plane_state *state)
cma_obj = drm_fb_cma_get_gem_obj(fb, 1);
BUG_ON(!cma_obj);
 
-   x /= drm_format_horz_chroma_subsampling(fb->format->format);
-   y /= drm_format_vert_chroma_subsampling(fb->format->format);
+   x /= fb->format->hsub;
+   y /= fb->format->vsub;
 
return cma_obj->paddr + fb->offsets[1] + fb->pitches[1] * y +
   fb->format->cpp[1] * x - eba;
@@ -134,8 +134,8 @@ 

[RFC PATCH 07/20] drm/fb: Move from drm_format_info to image_format_info

[Maxime Ripard]

Start converting the DRM drivers by changing the struct drm_framebuffer
structure to hold a pointer to image_format_info instead, and converting
everyone that depends on it.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/Kconfig |  1 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c  |  4 ++--
 drivers/gpu/drm/arm/malidp_drv.c|  2 +-
 drivers/gpu/drm/arm/malidp_planes.c |  8 
 drivers/gpu/drm/armada/armada_fb.c  |  2 +-
 drivers/gpu/drm/armada/armada_overlay.c |  3 ++-
 drivers/gpu/drm/armada/armada_plane.c   |  3 ++-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  4 +++-
 drivers/gpu/drm/bochs/bochs.h   |  4 +++-
 drivers/gpu/drm/bochs/bochs_hw.c|  3 ++-
 drivers/gpu/drm/cirrus/cirrus_fbdev.c   |  4 ++--
 drivers/gpu/drm/cirrus/cirrus_main.c|  4 ++--
 drivers/gpu/drm/drm_atomic.c|  1 +-
 drivers/gpu/drm/drm_client.c|  1 +-
 drivers/gpu/drm/drm_crtc.c  |  1 +-
 drivers/gpu/drm/drm_fb_cma_helper.c |  5 +++--
 drivers/gpu/drm/drm_fb_helper.c | 15 +++---
 drivers/gpu/drm/drm_fourcc.c|  8 
 drivers/gpu/drm/drm_framebuffer.c   | 11 +-
 drivers/gpu/drm/drm_gem_framebuffer_helper.c|  5 +++--
 drivers/gpu/drm/drm_plane.c |  1 +-
 drivers/gpu/drm/exynos/exynos_drm_fb.c  |  3 ++-
 drivers/gpu/drm/gma500/framebuffer.c|  2 +-
 drivers/gpu/drm/i915/i915_drv.h |  6 --
 drivers/gpu/drm/i915/intel_display.c| 11 +-
 drivers/gpu/drm/imx/ipuv3-plane.c   |  5 +++--
 drivers/gpu/drm/mediatek/mtk_drm_fb.c   |  4 ++--
 drivers/gpu/drm/meson/meson_overlay.c   | 12 +--
 drivers/gpu/drm/msm/msm_fb.c|  8 
 drivers/gpu/drm/omapdrm/omap_fb.c   |  6 +++---
 drivers/gpu/drm/radeon/radeon_fb.c  |  4 ++--
 drivers/gpu/drm/rockchip/rockchip_drm_fb.c  |  4 ++--
 drivers/gpu/drm/stm/ltdc.c  |  2 +-
 drivers/gpu/drm/sun4i/sun4i_backend.c   |  7 ---
 drivers/gpu/drm/sun4i/sun4i_frontend.c  | 19 +-
 drivers/gpu/drm/sun4i/sun8i_ui_layer.c  |  2 ++-
 drivers/gpu/drm/sun4i/sun8i_vi_layer.c  |  6 --
 drivers/gpu/drm/sun4i/sun8i_vi_scaler.c |  6 --
 drivers/gpu/drm/sun4i/sun8i_vi_scaler.h |  5 +++--
 drivers/gpu/drm/tegra/fb.c  |  2 +-
 drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c  |  2 +-
 drivers/gpu/drm/zte/zx_plane.c  |  2 +-
 include/drm/drm_fourcc.h|  4 +++-
 include/drm/drm_framebuffer.h   |  3 ++-
 include/drm/drm_mode_config.h   |  4 ++--
 45 files changed, 126 insertions(+), 93 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index bd943a71756c..7992a95ea965 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -12,6 +12,7 @@ menuconfig DRM
select FB_CMDLINE
select I2C
select I2C_ALGOBIT
+   select IMAGE_FORMATS
select DMA_SHARED_BUFFER
select SYNC_FILE
help
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 48170a843b48..2d2e091da19b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -123,8 +123,8 @@ static int amdgpufb_create_pinned_object(struct 
amdgpu_fbdev *rfbdev,
 struct drm_mode_fb_cmd2 *mode_cmd,
 struct drm_gem_object **gobj_p)
 {
-   const struct drm_format_info *info = drm_get_format_info(dev,
-mode_cmd);
+   const struct image_format_info *info = drm_get_format_info(dev,
+  mode_cmd);
struct amdgpu_device *adev = rfbdev->adev;
struct drm_gem_object *gobj = NULL;
struct amdgpu_bo *abo = NULL;
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index ab50ad06e271..fec4fe15a71b 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -264,7 +264,7 @@ static bool
 malidp_verify_afbc_framebuffer_caps(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *mode_cmd)
 {
-   const struct drm_format_info *info;
+   const struct image_format_info *info;
 
if ((mode_cmd->modifier[0] >> 56) != DRM_FORMAT_MOD_VENDOR_ARM) {
DRM_DEBUG_KMS("Unknown modifier (not Arm)\n");
diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index c9a6d3e0cada..6d2dad4642be 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ 

[RFC PATCH 12/20] drm/ipuv3: Convert to generic image format library

[Maxime Ripard]

Now that we have a generic image format libary, let's convert drivers to
use it so that we can deprecate the old DRM one.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/ipu-v3/ipu-pre.c | 3 ++-
 drivers/gpu/ipu-v3/ipu-prg.c | 3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-pre.c b/drivers/gpu/ipu-v3/ipu-pre.c
index 4a28f3fbb0a2..d561295abee0 100644
--- a/drivers/gpu/ipu-v3/ipu-pre.c
+++ b/drivers/gpu/ipu-v3/ipu-pre.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -174,7 +175,7 @@ void ipu_pre_configure(struct ipu_pre *pre, unsigned int 
width,
   unsigned int height, unsigned int stride, u32 format,
   uint64_t modifier, unsigned int bufaddr)
 {
-   const struct drm_format_info *info = drm_format_info(format);
+   const struct image_format_info *info = image_format_drm_lookup(format);
u32 active_bpp = info->cpp[0] >> 1;
u32 val;
 
diff --git a/drivers/gpu/ipu-v3/ipu-prg.c b/drivers/gpu/ipu-v3/ipu-prg.c
index 38a3a9764e49..608a9213025d 100644
--- a/drivers/gpu/ipu-v3/ipu-prg.c
+++ b/drivers/gpu/ipu-v3/ipu-prg.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -132,7 +133,7 @@ EXPORT_SYMBOL_GPL(ipu_prg_present);
 bool ipu_prg_format_supported(struct ipu_soc *ipu, uint32_t format,
  uint64_t modifier)
 {
-   const struct drm_format_info *info = drm_format_info(format);
+   const struct image_format_info *info = image_format_drm_lookup(format);
 
if (info->num_planes != 1)
return false;
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH 04/20] drm/fourcc: Pass the format_info pointer to drm_format_plane_width/height

[Maxime Ripard]

So far, the drm_format_plane_height/width functions were operating on the
format's fourcc and was doing a lookup to retrieve the drm_format_info
structure and return the cpp.

However, this is inefficient since in most cases, we will have the
drm_format_info pointer already available so we shouldn't have to perform a
new lookup. Some drm_fourcc functions also already operate on the
drm_format_info pointer for that reason, so the API is quite inconsistent
there.

Let's follow the latter pattern and remove the extra lookup while being a
bit more consistent.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/drm_fourcc.c  | 16 ++--
 drivers/gpu/drm/meson/meson_overlay.c |  6 +++---
 include/drm/drm_fourcc.h  |  6 --
 3 files changed, 13 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index d8ada4cb689e..57389b9753b2 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -325,17 +325,15 @@ EXPORT_SYMBOL(drm_format_plane_cpp);
 /**
  * drm_format_plane_width - width of the plane given the first plane
  * @width: width of the first plane
- * @format: pixel format
+ * @format: pixel format info
  * @plane: plane index
  *
  * Returns:
  * The width of @plane, given that the width of the first plane is @width.
  */
-int drm_format_plane_width(int width, uint32_t format, int plane)
+int drm_format_plane_width(int width, const struct drm_format_info *info,
+  int plane)
 {
-   const struct drm_format_info *info;
-
-   info = drm_format_info(format);
if (!info || plane >= info->num_planes)
return 0;
 
@@ -349,17 +347,15 @@ EXPORT_SYMBOL(drm_format_plane_width);
 /**
  * drm_format_plane_height - height of the plane given the first plane
  * @height: height of the first plane
- * @format: pixel format
+ * @format: pixel format info
  * @plane: plane index
  *
  * Returns:
  * The height of @plane, given that the height of the first plane is @height.
  */
-int drm_format_plane_height(int height, uint32_t format, int plane)
+int drm_format_plane_height(int height, const struct drm_format_info *info,
+   int plane)
 {
-   const struct drm_format_info *info;
-
-   info = drm_format_info(format);
if (!info || plane >= info->num_planes)
return 0;
 
diff --git a/drivers/gpu/drm/meson/meson_overlay.c 
b/drivers/gpu/drm/meson/meson_overlay.c
index 8ff15d01a8f9..6987c15b6ab9 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -475,7 +475,7 @@ static void meson_overlay_atomic_update(struct drm_plane 
*plane,
priv->viu.vd1_stride2 = fb->pitches[2];
priv->viu.vd1_height2 =
drm_format_plane_height(fb->height,
-   fb->format->format, 2);
+   fb->format, 2);
DRM_DEBUG("plane 2 addr 0x%x stride %d height %d\n",
 priv->viu.vd1_addr2,
 priv->viu.vd1_stride2,
@@ -487,7 +487,7 @@ static void meson_overlay_atomic_update(struct drm_plane 
*plane,
priv->viu.vd1_stride1 = fb->pitches[1];
priv->viu.vd1_height1 =
drm_format_plane_height(fb->height,
-   fb->format->format, 1);
+   fb->format, 1);
DRM_DEBUG("plane 1 addr 0x%x stride %d height %d\n",
 priv->viu.vd1_addr1,
 priv->viu.vd1_stride1,
@@ -499,7 +499,7 @@ static void meson_overlay_atomic_update(struct drm_plane 
*plane,
priv->viu.vd1_stride0 = fb->pitches[0];
priv->viu.vd1_height0 =
drm_format_plane_height(fb->height,
-   fb->format->format, 0);
+   fb->format, 0);
DRM_DEBUG("plane 0 addr 0x%x stride %d height %d\n",
 priv->viu.vd1_addr0,
 priv->viu.vd1_stride0,
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index 97a58f3e7462..2291f2618211 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -269,8 +269,10 @@ uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t 
depth);
 uint32_t drm_driver_legacy_fb_format(struct drm_device *dev,
 uint32_t bpp, uint32_t depth);
 int drm_format_plane_cpp(const struct drm_format_info *info, int plane);
-int drm_format_plane_width(int width, uint32_t format, int plane);
-int drm_format_plane_height(int height, uint32_t format, int plane);
+int drm_format_plane_width(int width, const struct drm_format_info *info,
+  int plane);
+int drm_format_plane_height(int height, 

[RFC PATCH 10/20] drm/exynos: Convert to generic image format library

[Maxime Ripard]

Now that we have a generic image format libary, let's convert drivers to
use it so that we can deprecate the old DRM one.

Signed-off-by: Maxime Ripard 
---
 drivers/gpu/drm/exynos/exynos_drm_ipp.c| 2 +-
 drivers/gpu/drm/exynos/exynos_drm_ipp.h| 4 +++-
 drivers/gpu/drm/exynos/exynos_drm_scaler.c | 3 ++-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 23226a0212e8..ba012840fe07 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -562,7 +562,7 @@ static int exynos_drm_ipp_check_format(struct 
exynos_drm_ipp_task *task,
if (buf->buf.width == 0 || buf->buf.height == 0)
return -EINVAL;
 
-   buf->format = drm_format_info(buf->buf.fourcc);
+   buf->format = image_format_drm_lookup(buf->buf.fourcc);
for (i = 0; i < buf->format->num_planes; i++) {
unsigned int width = (i == 0) ? buf->buf.width :
 DIV_ROUND_UP(buf->buf.width, buf->format->hsub);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.h 
b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
index 0b27d4a9bf94..c6cd21f185e6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
@@ -71,12 +71,14 @@ struct exynos_drm_ipp {
wait_queue_head_t done_wq;
 };
 
+struct image_format_info;
+
 struct exynos_drm_ipp_buffer {
struct drm_exynos_ipp_task_buffer buf;
struct drm_exynos_ipp_task_rect rect;
 
struct exynos_drm_gem *exynos_gem[MAX_FB_BUFFER];
-   const struct drm_format_info *format;
+   const struct image_format_info *format;
dma_addr_t dma_addr[MAX_FB_BUFFER];
 };
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_scaler.c 
b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
index ed1dd1aec902..c9791a2013cf 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_scaler.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_scaler.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -301,7 +302,7 @@ static inline void scaler_set_rotation(struct 
scaler_context *scaler,
 }
 
 static inline void scaler_set_csc(struct scaler_context *scaler,
-   const struct drm_format_info *fmt)
+   const struct image_format_info *fmt)
 {
static const u32 csc_mtx[2][3][3] = {
{ /* YCbCr to RGB */
-- 
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] pci/quirks: Add quirk to reset nvgpu at boot for the Lenovo ThinkPad P50

[Lyude Paul]

Bump, sorry to bug you but is there any update on this or any information you
still need from me which would help get this upstream?

On Wed, 2019-03-13 at 18:25 -0400, Lyude Paul wrote:
> [note to David Ober: you -should- be able to reply to this, hopefully, but I
> haven't actually tested that so results may vary]
> 
> Hi again! Sorry I didn't fully answer all of the questions you originally
> asked in this email, I had to get in contact with Lenovo to make sure that
> it
> was OK for me to disclose more details on this bug (and I had PTO scheduled
> immediately after I asked). I've added David Ober from Lenovo to this thread
> as well. So now that I've got Lenovo's approval I can answer those
> questions,
> and give some better answers for the others! (see below)
> 
> 
> On Fri, 2019-02-15 at 16:17 -0500, Lyude Paul wrote:
> > On Thu, 2019-02-14 at 18:43 -0600, Bjorn Helgaas wrote:
> > > Hi Lyude,
> > > 
> > > On Tue, Feb 12, 2019 at 05:02:30PM -0500, Lyude Paul wrote:
> > > > On a very specific subset of ThinkPad P50 SKUs, particularly ones that
> > > > come with a Quadro M1000M chip instead of the M2000M variant, the BIOS
> > > > seems to have a very nasty habit of not always resetting the secondary
> > > > Nvidia GPU between full reboots if the laptop is configured in Hybrid
> > > > Graphics mode. The reason for this happening is unknown, but the
> > > > following steps and possibly a good bit of patience will reproduce the
> > > > issue:
> > > > 
> > > > 1. Boot up the laptop normally in Hybrid graphics mode
> > > > 2. Make sure nouveau is loaded and that the GPU is awake
> > > > 2. Allow the nvidia GPU to runtime suspend itself after being idle
> > > > 3. Reboot the machine, the more sudden the better (e.g sysrq-b may
> > > > help)
> > > > 4. If nouveau loads up properly, reboot the machine again and go back
> > > > to
> > > > step 2 until you reproduce the issue
> > > > 
> > > > This results in some very strange behavior: the GPU will
> > > > quite literally be left in exactly the same state it was in when the
> > > > previously booted kernel started the reboot. This has all sorts of bad
> > > > sideaffects: for starters, this completely breaks nouveau starting
> > > > with
> > > > a
> > > > mysterious EVO channel failure that happens well before we've actually
> > > > used the EVO channel for anything:
> > > 
> > > There are a lot of moving parts here that are probably obvious to you
> > > but not to me.  I need help untangling this a bit so I'm comfortable
> > > that we got to the root cause and that we're doing something logical
> > > as opposed to something that just happens to make things work.  I
> > > really don't know enough to even ask the right questions...
> > 
> > I completely understand! I'm pretty sure I'd be just as skeptical if I was
> > in
> > your position reviewing a patch like this :P
> > 
> > > Is there a bug report for this?  Bugzilla.kernel.org would be ideal,
> > > including "lspci -vvxxx" and dmidecode for the system.
> > > 
> > Not yet, but there has been discussion about this between nouveau
> > developers
> > on our IRC channel.
> I lied: yes there actually is a bug report for this, but it's currently on
> the
> Red Hat bugzilla. I can get more information from it if you need (with
> lenovo's approval of course).
> 
> > > Is this running a current BIOS?  The date in your log below looks
> > > pretty recent, so I assume it is current.
> > 
> > Yes, this is the most up to date BIOS available for this system.
> 
> And additionally: I've been working with Lenovo on this issue for a couple
> of
> months now, and we've gone through dozens of different trial BIOSes with no
> success thus far. However, Lenovo is currently working on trying to add this
> workaround into their BIOS but I've been told that this change is going to
> take a decent amount of time since they need to test it across multiple
> operating systems. I'd be happy to come back and add a conditional later to
> turn this workaround off for later BIOS versions once Lenovo has released a
> proper fix.
> 
> With all of that being said, [how] do you think we should proceed?
> 
> > > I assume "hybrid graphics" means you have two GPUs.  Do you select
> > > hybrid graphics mode in the BIOS?
> > 
> > Yes, the P50 has two available modes in the BIOS: Dedicated (e.g. only
> > the nvidia GPU is used for everything), and Hybrid (i915 drives the
> > built-in display panel, nouveau drives everything else). This bug only
> > seems to occur in Hybrid mode.
> > 
> > > I assume when you say the Nvidia GPU doesn't get reset on a full
> > > reboot, you're talking about a "warm reboot", and that if you actually
> > > remove the power and do a cold reboot, there's no problem?
> > 
> > If you meant "unplugging the power adapter" when you said cutting the
> > power we don't need to go that far, but shutting down the machine and
> > restarting it by hand does avoid the problem yes.
> > 
> > > I assume Nvidia GPU being active means you 

Re: randr: Virtual monitor not present with MST display

[Wentland, Harry]

On 2019-03-18 5:58 p.m., Paul Menzel wrote:
> 
> Dear Harry,
> 

... snip ...

>>
>> Michel, do you know if this is supposed to work with
>> xf86-video-amdgpu? When I've tried it before I didn't have any luck but
>> didn't have time to look into it.
> 
> Sorry, what is your question. With the commit from the merge request applied 
> it works here. Also, the commit was added to the master branch in the mean 
> time.
> 

Ah, of course. Somehow I thought this was still targetting the modesetting 
driver and didn't notice it's on video-amdgpu.

Apologies for the confusion.

Harry

> 
> Kind regards,
> 
> Paul
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102646] Screen flickering under amdgpu-experimental [buggy auto power profile]

[bugzilla-daemon]

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

--- Comment #69 from Bastian  ---
Distro/Kernel: Ubuntu 18.04.2/5.0.2
GPU AMD:   Readon RX570 - Mesa 19.0
Display:   Iiyama G23530HSU  75hz
Desktop:   Gnome

video: https://www.youtube.com/watch?v=gNJ2kJ8hsHA

Have the same problem as the op. The problems started with the 4.20 Kernels.
Had not this problem with 4.19 LTS Kernels. The flickering doesn't appear on
wayland if I choose only 60hz. On xorg it is irrelevant how much hz I use, it
flickers regardless. 

sudo -i
echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level 
echo "2" > /sys/class/drm/card0/device/pp_dpm_mclk

Fixes the flickering.

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

[Bug 107731] radeon (amdgpu) DisplayPort loss of max-resolution on DP monitor (after monitor power saving / idle)

[bugzilla-daemon]

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

--- Comment #10 from Alex Deucher  ---
(In reply to L.S.S. from comment #9)
> Just tested... it seems if I connect to the monitor directly the problem
> doesn't occur.
> 
> Guess the KVM does play a part in this. However, I still need the KVM as
> I've four PCs connected to this monitor.
> 
> It's not a major issue as switching it back and forth would put the system
> back to the correct resolution, and it currently doesn't have any serious
> impacts. Just that I'm wondering why this problem is only happening on AMD
> video cards and not on nVidia video cards.

Possibly different behavior in the the hw or hw settings on what is considered
a short vs. long pulse for DP.

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

[Bug 110199] [amdgpu] Screen flickering when using a 75Hz monitor paired with an RX 480 GPU

[bugzilla-daemon]

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

Maxim Ivanov  changed:

   What|Removed |Added

   Priority|medium  |high

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

[Bug 110199] [amdgpu] Screen flickering when using a 75Hz monitor paired with an RX 480 GPU

[bugzilla-daemon]

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

Bug ID: 110199
   Summary: [amdgpu] Screen flickering when using a 75Hz monitor
paired with an RX 480 GPU
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: m.ivano...@gmail.com

My monitor is LG 24MP59G-P (75Hz, FreeSync) and my GPU is Sapphire Nitro+ RX
480 8GB.

Basically, whenever there is movement on my screen (oddly though, cursor
movement doesn't cause it), it would flicker very badly. 

Here is a video of what I am talking about: https://streamable.com/5eu7p

Apart from trying different refresh rates, as seen in the video, I have also
tried switching kernel versions, switching from DisplayPort to HDMI, changing
compositor settings and turning off FreeSync from the monitor OSD, but nothing
seems to resolve the bug.

What works for me as a workaround is changing
/sys/class/drm/card0/device/power_dpm_force_performance_level from auto to
either low or high. When I do watch -n 1
"/sys/class/drm/card0/device/pp_dpm_mclk" with the performance level on auto,
it normally stays on the lowest (300MHz) and when I move a window around, it
constantly switches from 300MHz to 2000MHz (the max on my GPU). Apparently,
that's what's causing it to behave this way.

I should emphasize, that I observed the bug in Antergos, Debian 9 Buster
(Stretch is good), Manjaro XFCE, Manjaro KDE, Ubuntu 18.10, KUbuntu 18.04 and
KUbuntu 18.10. At first I thought it was only related to Arch Linux
derivatives, since they all use bleeding-edge packages, but then I noticed,
that after switching Debian 9 Stretch's (stable) sources to Buster (testing)
and after updating KUbuntu 18.10, the bug appeared in both distros as well.

Here is a link to a thread I created in the Manjaro forums, where I asked for
help:
https://forum.manjaro.org/t/manjaro-kde-screen-flickering-cant-seem-to-find-a-solution/78349
- You can find all kinds of different things I tried there, as well as more
in-depth system information.

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

[Bug 107731] radeon (amdgpu) DisplayPort loss of max-resolution on DP monitor (after monitor power saving / idle)

[bugzilla-daemon]

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

--- Comment #9 from L.S.S.  ---
Just tested... it seems if I connect to the monitor directly the problem
doesn't occur.

Guess the KVM does play a part in this. However, I still need the KVM as I've
four PCs connected to this monitor.

It's not a major issue as switching it back and forth would put the system back
to the correct resolution, and it currently doesn't have any serious impacts.
Just that I'm wondering why this problem is only happening on AMD video cards
and not on nVidia video cards.

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

Re: [PATCH, RESEND] drm/vmwgfx: Don't double-free the mode stored in par->set_mode

[Thomas Hellstrom]

Hi, Deepak,

On Mon, 2019-03-18 at 09:59 -0700, Deepak Singh Rawat wrote:
> Hi Thomas,
> 
> Thanks for doing this and somehow I missed the last patch, sorry
> about
> that. Have some questions below otherwise the patch looks good to me.
> 
> Reviewed-by: Deepak Rawat 
> 
> I will include your changes in vmwgfx-next and run tests.

I think we need to run this through vmwgfx-fixes and CC stable. I'll
pick up the patch for that.


> 
> On Mon, 2019-03-18 at 15:47 +0100, Thomas Zimmermann wrote:
> > When calling vmw_fb_set_par(), the mode stored in par->set_mode
> > gets
> > free'd
> > twice. The first free is in vmw_fb_kms_detach(), the second is near
> > the
> > end of vmw_fb_set_par() under the name of 'old_mode'. The mode-
> > setting code
> > only works correctly if the mode doesn't actually change.
> 
> You mean to say that without your patch vmwgfx fb driver fail to
> change
> the mode?
> 
> >  Removing 'old_mode'
> > in favor of using par->set_mode directly fixes the problem.
> > 
> > Signed-off-by: Thomas Zimmermann 
> > ---
> >  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 12 +++-
> >  1 file changed, 3 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > index b913a56f3426..2a9112515f46 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
> > @@ -564,11 +564,9 @@ static int vmw_fb_set_par(struct fb_info
> > *info)
> > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
> > DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC)
> > };
> > -   struct drm_display_mode *old_mode;
> > struct drm_display_mode *mode;
> > int ret;
> > 
> > -   old_mode = par->set_mode;
> > mode = drm_mode_duplicate(vmw_priv->dev, _mode);
> > if (!mode) {
> > DRM_ERROR("Could not create new fb mode.\n");
> > @@ -579,11 +577,7 @@ static int vmw_fb_set_par(struct fb_info
> > *info)
> > mode->vdisplay = var->yres;
> > vmw_guess_mode_timing(mode);
> > 
> > -   if (old_mode && drm_mode_equal(old_mode, mode)) {
> > -   drm_mode_destroy(vmw_priv->dev, mode);
> > -   mode = old_mode;
> > -   old_mode = NULL;
> 
> I am having hard time understanding original intention for this piece
> of code. Was there a restriction to send pointer to old mode if mode
> were same and that restriction don't hold anymore. Sorry I am not
> familiar with this code area.

It looks like that code is there to reuse the old mode if possible. In
that case things work, but if a new mode is indeed created, the old
mode will be double-freed :(

/Thomas



> 
> > -   } else if (!vmw_kms_validate_mode_vram(vmw_priv,
> > +   if (!vmw_kms_validate_mode_vram(vmw_priv,
> > mode->hdisplay *
> > DIV_ROUND_UP(var-
> > > bits_per_pixel, 8),
> > mode->vdisplay)) {
> > @@ -620,8 +614,8 @@ static int vmw_fb_set_par(struct fb_info *info)
> > schedule_delayed_work(>local_work, 0);
> > 
> >  out_unlock:
> > -   if (old_mode)
> > -   drm_mode_destroy(vmw_priv->dev, old_mode);
> > +   if (par->set_mode)
> > +   drm_mode_destroy(vmw_priv->dev, par->set_mode);
> > par->set_mode = mode;
> > 
> > mutex_unlock(>bo_mutex);
> > --
> > 2.20.1
> > 
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > 
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=02%7C01%7Cdrawat%40vmware.com%7Cb1508247a3954fb0b08b08d6abb0bcd0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636885172908359973sdata=AN6UTrMzxcVK7MC6bX3OxNbcyq0j4HdKt0dk1yyHOHc%3Dreserved=0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 108917] gamma adjustments cause stuttering with amdgpu.dc=1, especially problematic with RedShift etc.

[bugzilla-daemon]

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

--- Comment #10 from tempel.jul...@gmail.com ---
Thanks for the information, really a relief to know that this is being worked
on.
Does this aim to achieve as good performance as with "legacy DC" for every
window operation as well?

Would it work to do something like "patch -Np1 -i -R fastcursorpath.patch" and
then apply the new set of patches?

In that case my question would be how to find the right patch to revert. The PR
for the kernel included much more (yeah, sorry for such beginner questions):
https://github.com/torvalds/linux/commit/74136a3d47f51ae72ee8b9ebc1ec2a29bcf30676

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

Re: [PATCH, RESEND] drm/vmwgfx: Don't double-free the mode stored in par->set_mode

[Thomas Zimmermann]

Hi Deepak

Am 18.03.19 um 17:59 schrieb Deepak Singh Rawat:
> Hi Thomas,
> 
> Thanks for doing this and somehow I missed the last patch, sorry about
> that. Have some questions below otherwise the patch looks good to me.
> 
> Reviewed-by: Deepak Rawat 
> 
> I will include your changes in vmwgfx-next and run tests.

Thank you.

> 
> On Mon, 2019-03-18 at 15:47 +0100, Thomas Zimmermann wrote:
>> When calling vmw_fb_set_par(), the mode stored in par->set_mode gets
>> free'd
>> twice. The first free is in vmw_fb_kms_detach(), the second is near
>> the
>> end of vmw_fb_set_par() under the name of 'old_mode'. The mode-
>> setting code
>> only works correctly if the mode doesn't actually change.
> 
> You mean to say that without your patch vmwgfx fb driver fail to change
> the mode?

Yes. It's hard to trigger as the usual resolution always appears to be
800x600. We (SUSE) have a customer with a custom X11 modeline setting,
which sets the resolution to something different. In this case, the
double-free bug happens.

> 
>>  Removing 'old_mode'
>> in favor of using par->set_mode directly fixes the problem.
>>
>> Signed-off-by: Thomas Zimmermann 
>> ---
>>  drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 12 +++-
>>  1 file changed, 3 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
>> b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
>> index b913a56f3426..2a9112515f46 100644
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fb.c
>> @@ -564,11 +564,9 @@ static int vmw_fb_set_par(struct fb_info *info)
>>  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
>>  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC)
>>  };
>> -struct drm_display_mode *old_mode;
>>  struct drm_display_mode *mode;
>>  int ret;
>>
>> -old_mode = par->set_mode;
>>  mode = drm_mode_duplicate(vmw_priv->dev, _mode);
>>  if (!mode) {
>>  DRM_ERROR("Could not create new fb mode.\n");
>> @@ -579,11 +577,7 @@ static int vmw_fb_set_par(struct fb_info *info)
>>  mode->vdisplay = var->yres;
>>  vmw_guess_mode_timing(mode);
>>
>> -if (old_mode && drm_mode_equal(old_mode, mode)) {
>> -drm_mode_destroy(vmw_priv->dev, mode);
>> -mode = old_mode;
>> -old_mode = NULL;
> 
> I am having hard time understanding original intention for this piece
> of code. Was there a restriction to send pointer to old mode if mode
> were same and that restriction don't hold anymore. Sorry I am not
> familiar with this code area.

Hmm, I can only guess about motivation: it looks like the author wanted
to keep the original value of 'par->set_mode' unless the mode really
changes. But it doesn't make a difference whether the pointer's value
changes or not.

Best regards
Thomas

> 
>> -} else if (!vmw_kms_validate_mode_vram(vmw_priv,
>> +if (!vmw_kms_validate_mode_vram(vmw_priv,
>>  mode->hdisplay *
>>  DIV_ROUND_UP(var-
>>> bits_per_pixel, 8),
>>  mode->vdisplay)) {
>> @@ -620,8 +614,8 @@ static int vmw_fb_set_par(struct fb_info *info)
>>  schedule_delayed_work(>local_work, 0);
>>
>>  out_unlock:
>> -if (old_mode)
>> -drm_mode_destroy(vmw_priv->dev, old_mode);
>> +if (par->set_mode)
>> +drm_mode_destroy(vmw_priv->dev, par->set_mode);
>>  par->set_mode = mode;
>>
>>  mutex_unlock(>bo_mutex);
>> --
>> 2.20.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-develdata=02%7C01%7Cdrawat%40vmware.com%7Cb1508247a3954fb0b08b08d6abb0bcd0%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636885172908359973sdata=AN6UTrMzxcVK7MC6bX3OxNbcyq0j4HdKt0dk1yyHOHc%3Dreserved=0
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nürnberg
Tel: +49-911-74053-0; Fax: +49-911-7417755;  https://www.suse.com/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Graham Norton, HRB 21284 (AG Nürnberg)



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/fourcc: add ARM GPU tile modifier

[Alyssa Rosenzweig]

> We don't know if this is a "category" per-se, or just a single Utgard
> tiling format - as discussed I'm trying to get an answer for that.

FWIW, as I think I mentioned on an message, this format is used on
Midgard as well, and presumably also Bifrost.

On Midgard, when a texture is uploaded (just as a plain bitmap), the
driver tiles it in this format and uploads that, to improve cache
locality.

That said, unlike on Lima/Utgard, Panfrost does not need this exposed in
kernel space, since I don't believe the format is renderable on Midgard.
Any time Qiang would need to import/export something in this tiled
format, I would just use AFBC for the same effect + bw savings.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/sun4i: hdmi: add support for ddc-i2c-bus property

[Måns Rullgård]

Maxime Ripard  writes:

> On Mon, Mar 18, 2019 at 04:23:56PM +, Måns Rullgård wrote:
>> Maxime Ripard  writes:
>>
>> > On Thu, Mar 14, 2019 at 04:09:13PM +, Måns Rullgård wrote:
>> >> Maxime Ripard  writes:
>> >>
>> >> > On Mon, Mar 11, 2019 at 04:11:06PM +, Måns Rullgård wrote:
>> >> >> Maxime Ripard  writes:
>> >> >>
>> >> >> > Hi!
>> >> >> >
>> >> >> > On Mon, Mar 11, 2019 at 01:47:13PM +, Mans Rullgard wrote:
>> >> >> >> Sometimes it is desirabled to use a separate i2c controller for ddc
>> >> >> >> access.  This adds support for the ddc-i2c-bus property of the
>> >> >> >> hdmi-connector node, using the specified controller if provided.
>> >> >> >>
>> >> >> >> Signed-off-by: Mans Rullgard 
>> >> >> >> ---
>> >> >> >>  drivers/gpu/drm/sun4i/sun4i_hdmi.h |  1 +
>> >> >> >>  drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 37 
>> >> >> >> +++---
>> >> >> >>  2 files changed, 35 insertions(+), 3 deletions(-)
>> >> >> >>
>> >> >> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h 
>> >> >> >> b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
>> >> >> >> index b685ee11623d..b08c4453d47c 100644
>> >> >> >> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
>> >> >> >> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
>> >> >> >> @@ -269,6 +269,7 @@ struct sun4i_hdmi {
>> >> >> >> struct clk  *tmds_clk;
>> >> >> >>
>> >> >> >> struct i2c_adapter  *i2c;
>> >> >> >> +   struct i2c_adapter  *ddc_i2c;
>> >> >> >>
>> >> >> >> /* Regmap fields for I2C adapter */
>> >> >> >> struct regmap_field *field_ddc_en;
>> >> >> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
>> >> >> >> b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
>> >> >> >> index 061d2e0d9011..5b2fac79f5d6 100644
>> >> >> >> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
>> >> >> >> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
>> >> >> >> @@ -212,7 +212,7 @@ static int sun4i_hdmi_get_modes(struct 
>> >> >> >> drm_connector *connector)
>> >> >> >> struct edid *edid;
>> >> >> >> int ret;
>> >> >> >>
>> >> >> >> -   edid = drm_get_edid(connector, hdmi->i2c);
>> >> >> >> +   edid = drm_get_edid(connector, hdmi->ddc_i2c ?: hdmi->i2c);
>> >> >> >
>> >> >> > You can't test whether ddc_i2c is NULL or not...
>> >> >> >
>> >> >> >> if (!edid)
>> >> >> >> return 0;
>> >> >> >>
>> >> >> >> @@ -228,6 +228,28 @@ static int sun4i_hdmi_get_modes(struct 
>> >> >> >> drm_connector *connector)
>> >> >> >> return ret;
>> >> >> >>  }
>> >> >> >>
>> >> >> >> +static struct i2c_adapter *sun4i_hdmi_get_ddc(struct device *dev)
>> >> >> >> +{
>> >> >> >> +   struct device_node *phandle, *remote;
>> >> >> >> +   struct i2c_adapter *ddc;
>> >> >> >> +
>> >> >> >> +   remote = of_graph_get_remote_node(dev->of_node, 1, -1);
>> >> >> >> +   if (!remote)
>> >> >> >> +   return ERR_PTR(-EINVAL);
>> >> >> >> +
>> >> >> >> +   phandle = of_parse_phandle(remote, "ddc-i2c-bus", 0);
>> >> >> >> +   of_node_put(remote);
>> >> >> >> +   if (!phandle)
>> >> >> >> +   return NULL;
>> >> >> >> +
>> >> >> >> +   ddc = of_get_i2c_adapter_by_node(phandle);
>> >> >> >> +   of_node_put(phandle);
>> >> >> >> +   if (!ddc)
>> >> >> >> +   return ERR_PTR(-EPROBE_DEFER);
>> >> >> >> +
>> >> >> >> +   return ddc;
>> >> >> >
>> >> >> > ... Since even in (most) error cases you're returning a !NULL 
>> >> >> > pointer.
>> >> >> >
>> >> >> >> +}
>> >> >> >> +
>> >> >> >>  static const struct drm_connector_helper_funcs 
>> >> >> >> sun4i_hdmi_connector_helper_funcs = {
>> >> >> >> .get_modes  = sun4i_hdmi_get_modes,
>> >> >> >>  };
>> >> >> >> @@ -575,6 +597,12 @@ static int sun4i_hdmi_bind(struct device *dev, 
>> >> >> >> struct device *master,
>> >> >> >> goto err_disable_mod_clk;
>> >> >> >> }
>> >> >> >>
>> >> >> >> +   hdmi->ddc_i2c = sun4i_hdmi_get_ddc(dev);
>> >> >> >> +   if (IS_ERR(hdmi->ddc_i2c)) {
>> >> >>
>> >> >> ... which is checked here.
>> >> >>
>> >> >> The property is optional, so the idea was to return null in that case
>> >> >> and use the built-in controller.  If the property exists but some error
>> >> >> occurs, we want to abort rather than proceed with the fallback which
>> >> >> almost certainly won't work.
>> >> >>
>> >> >> Maybe I got something wrong in that logic.
>> >> >
>> >> > Indeed, I just got confused. I guess returning ENODEV in such a case,
>> >> > and testing for that, would make things more obvious.
>> >>
>> >> There's also a case I hadn't thought of: property exists but isn't a
>> >> valid phandle.  What do you think is the correct action in that case?
>> >
>> > I think we would have that one covered. of_parse_phandle will return
>> > !NULL, but then of_get_i2c_adapter_by_node will return NULL since we
>> > wouldn't have an associated i2c adapter to the bogus phandle, and you
>> > are checking for that already.
>>
>> of_parse_phandle() doesn't differentiate between a missing property and
>> an existing non-phandle value.  The following cases are possible with

[PATCH 1/2] drm/msm: simplify getting .driver_data

[Wolfram Sang]

We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.

Signed-off-by: Wolfram Sang 
---

Build tested only. buildbot is happy.

 drivers/gpu/drm/msm/adreno/adreno_device.c |  6 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 13 +
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c   |  6 ++
 drivers/gpu/drm/msm/dsi/dsi_host.c |  6 ++
 drivers/gpu/drm/msm/msm_drv.c  |  3 +--
 5 files changed, 12 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 714ed6505e47..13802af8294c 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -412,16 +412,14 @@ static const struct of_device_id dt_match[] = {
 #ifdef CONFIG_PM
 static int adreno_resume(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct msm_gpu *gpu = platform_get_drvdata(pdev);
+   struct msm_gpu *gpu = dev_get_drvdata(dev);
 
return gpu->funcs->pm_resume(gpu);
 }
 
 static int adreno_suspend(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct msm_gpu *gpu = platform_get_drvdata(pdev);
+   struct msm_gpu *gpu = dev_get_drvdata(dev);
 
return gpu->funcs->pm_suspend(gpu);
 }
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 885bf88afa3e..0154eb9b343f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -1036,16 +1036,15 @@ static int dpu_bind(struct device *dev, struct device 
*master, void *data)
 
 static void dpu_unbind(struct device *dev, struct device *master, void *data)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
+   struct dpu_kms *dpu_kms = dev_get_drvdata(dev);
struct dss_module_power *mp = _kms->mp;
 
msm_dss_put_clk(mp->clk_config, mp->num_clk);
-   devm_kfree(>dev, mp->clk_config);
+   devm_kfree(dev, mp->clk_config);
mp->num_clk = 0;
 
if (dpu_kms->rpm_enabled)
-   pm_runtime_disable(>dev);
+   pm_runtime_disable(dev);
 }
 
 static const struct component_ops dpu_ops = {
@@ -1067,8 +1066,7 @@ static int dpu_dev_remove(struct platform_device *pdev)
 static int __maybe_unused dpu_runtime_suspend(struct device *dev)
 {
int rc = -1;
-   struct platform_device *pdev = to_platform_device(dev);
-   struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
+   struct dpu_kms *dpu_kms = dev_get_drvdata(dev);
struct drm_device *ddev;
struct dss_module_power *mp = _kms->mp;
 
@@ -1088,8 +1086,7 @@ static int __maybe_unused dpu_runtime_suspend(struct 
device *dev)
 static int __maybe_unused dpu_runtime_resume(struct device *dev)
 {
int rc = -1;
-   struct platform_device *pdev = to_platform_device(dev);
-   struct dpu_kms *dpu_kms = platform_get_drvdata(pdev);
+   struct dpu_kms *dpu_kms = dev_get_drvdata(dev);
struct drm_encoder *encoder;
struct drm_device *ddev;
struct dss_module_power *mp = _kms->mp;
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 97179bec8902..8f7a01d7a663 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -1063,8 +1063,7 @@ static int mdp5_dev_remove(struct platform_device *pdev)
 
 static __maybe_unused int mdp5_runtime_suspend(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct mdp5_kms *mdp5_kms = platform_get_drvdata(pdev);
+   struct mdp5_kms *mdp5_kms = dev_get_drvdata(dev);
 
DBG("");
 
@@ -1073,8 +1072,7 @@ static __maybe_unused int mdp5_runtime_suspend(struct 
device *dev)
 
 static __maybe_unused int mdp5_runtime_resume(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct mdp5_kms *mdp5_kms = platform_get_drvdata(pdev);
+   struct mdp5_kms *mdp5_kms = dev_get_drvdata(dev);
 
DBG("");
 
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 610183db1daf..4a158c41ef30 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -485,8 +485,7 @@ static void dsi_bus_clk_disable(struct msm_dsi_host 
*msm_host)
 
 int msm_dsi_runtime_suspend(struct device *dev)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct msm_dsi *msm_dsi = platform_get_drvdata(pdev);
+   struct msm_dsi *msm_dsi = dev_get_drvdata(dev);
struct mipi_dsi_host *host = msm_dsi->host;
struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
 
@@ -500,8 +499,7 @@ int msm_dsi_runtime_suspend(struct device *dev)
 
 int 

[PATCH] fbdev: fix divide error in fb_var_to_videomode

[shile . zhang]

From: Shile Zhang 

To fix following divide-by-zero error found by Syzkaller:

  divide error:  [#1] SMP PTI
  CPU: 7 PID: 8447 Comm: test Kdump: loaded Not tainted 4.19.24-8.al7.x86_64 #1
  Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 
rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
  RIP: 0010:fb_var_to_videomode+0xae/0xc0
  Code: 04 44 03 46 78 03 4e 7c 44 03 46 68 03 4e 70 89 ce d1 ee 69 c0 e8 03 00 
00 f6 c2 01 0f 45 ce 83 e2 02 8d 34 09 0f 45 ce 31 d2 <41> f7 f0 31 d2 f7 f1 89 
47 08 f3 c3 66 0f 1f 44 00 00 0f 1f 44 00
  RSP: 0018:b7e189347bf0 EFLAGS: 00010246
  RAX: e1692410 RBX: b7e189347d60 RCX: 
  RDX:  RSI:  RDI: b7e189347c10
  RBP: 99972a091c00 R08:  R09: 
  R10:  R11:  R12: 0100
  R13: 0001 R14: 7ffd66baf6d0 R15: 
  FS:  7f2054d11740() GS:99972fbc() knlGS:
  CS:  0010 DS:  ES:  CR0: 80050033
  CR2: 7f205481fd20 CR3: 0004288a0001 CR4: 001606a0
  Call Trace:
   fb_set_var+0x257/0x390
   ? lookup_fast+0xbb/0x2b0
   ? fb_open+0xc0/0x140
   ? chrdev_open+0xa6/0x1a0
   do_fb_ioctl+0x445/0x5a0
   do_vfs_ioctl+0x92/0x5f0
   ? __alloc_fd+0x3d/0x160
   ksys_ioctl+0x60/0x90
   __x64_sys_ioctl+0x16/0x20
   do_syscall_64+0x5b/0x190
   entry_SYSCALL_64_after_hwframe+0x44/0xa9
  RIP: 0033:0x7f20548258d7
  Code: 44 00 00 48 8b 05 b9 15 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff 
c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 
c3 48 8b 0d 89 15 2d 00 f7 d8 64 89 01 48

It can be triggered easily with following test code:

  #include 
  #include 
  #include 
  int main(void)
  {
  struct fb_var_screeninfo var = {.activate = 0x100, .pixclock = 60};
  int fd = open("/dev/fb0", O_RDWR);
  if (fd < 0)
  return 1;

  if (ioctl(fd, FBIOPUT_VSCREENINFO, ))
  return 1;

  return 0;
  }

Signed-off-by: Shile Zhang 
---
 drivers/video/fbdev/core/modedb.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/video/fbdev/core/modedb.c 
b/drivers/video/fbdev/core/modedb.c
index 283d9307..ac04987 100644
--- a/drivers/video/fbdev/core/modedb.c
+++ b/drivers/video/fbdev/core/modedb.c
@@ -935,6 +935,9 @@ void fb_var_to_videomode(struct fb_videomode *mode,
if (var->vmode & FB_VMODE_DOUBLE)
vtotal *= 2;
 
+   if (!htotal || !vtotal)
+   return;
+
hfreq = pixclock/htotal;
mode->refresh = hfreq/vtotal;
 }
-- 
1.8.3.1

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

Aw: Re: Re: [PATCH 2/2] drm/mediatek: Add Mediatek framebuffer device

[Frank Wunderlich]

Hi,

i try to get hdmi running on bananapi-r2 with 5.1 but also without CK Hu's 
frambuffer-Patch i get no x-server working

my codebase: https://github.com/frank-w/BPI-R2-4.14/commits/5.1-hdmi
reused some Patches working on 5.0 (here X-server is working, but not fbcon)

WARNING: CPU: 2 PID: 895 at drivers/gpu/drm/drm_atomic_helper.c:1430 
drm_atomic_helper_wait_for_vblanks.part.1+0x2a4/0x2a8

any hint how to fix this? if needed i can send full bootlog (with drm.debug=7)

regards Frank
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: etnaviv: fix strncpy sizeof argument

[Bo YU]

On Tue, Mar 19, 2019 at 6:22 PM Russell King - ARM Linux admin
 wrote:
>
> On Mon, Mar 18, 2019 at 10:57:55PM -0400, Bo YU wrote:
> > Calling strncpy with a maximum size argument of 64 bytes on destination
> > array "domain->name" of size 64 bytes might leave the destination string
> > unterminated.
> >
> > Detected by CoverityScan, CID# 1443992:  Memory - illegal accesses
> > (BUFFER_SIZE_WARNING)
> >
> > Fixes: 9e2c2e2730126 (drm/etnaviv: add infrastructure to query perf counter)
> > Signed-off-by: Bo YU 
> > ---
> >  drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c 
> > b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > index 4227a4006c34..08ca3c44be48 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
> > @@ -414,7 +414,7 @@ int etnaviv_pm_query_dom(struct etnaviv_gpu *gpu,
> >
> >   domain->id = domain->iter;
> >   domain->nr_signals = dom->nr_signals;
> > - strncpy(domain->name, dom->name, sizeof(domain->name));
> > + strncpy(domain->name, dom->name, sizeof(dom->name));
>
> This introduces an overflow bug if sizeof(dom->name) >
> sizeof(domain->name).  If both sizes are the same, then there is no
> effect.
Oops,It seems more worse than original code.
>
> strlcpy() would be a better replacement, it guarantees that the
> destination will be correctly terminated.
But there are too many strcpy like usage in kernel, Does it matter?
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v8 02/15] drm/sun4i: tcon: Compute DCLK dividers based on format, lanes

[Sergey Suloev]

Hi, guys,

On 3/19/19 1:53 PM, Maxime Ripard wrote:

On Mon, Mar 11, 2019 at 09:36:27PM +0530, Jagan Teki wrote:

On Mon, Mar 11, 2019 at 9:08 PM Maxime Ripard  wrote:

On Mon, Mar 11, 2019 at 07:06:24PM +0530, Jagan Teki wrote:

pll-video => pll-mipi => tcon0 => tcon0-pixel-clock is the typical
MIPI clock topology in Allwinner DSI controller.

TCON dotclock driver is computing the desired DCLK divider based on
panel pixel clock along with input DCLK min, max divider values from
tcon driver and that would eventually set the pll-mipi clock rate.

The current code allows the TCON clock divider to have a default 4
for min, max ranges that would fail to compute the desired pll-mipi
rate while supporting new panels.

So, add the computation logic 'format/lanes' to dclk min and max dividers
and instead of default 4. This computation logic align with Allwinner A64
BSP, hoping that would work even for A33.

Last time we discussed this, we found out that this wasn't the case,
even in the BSP.

This was the case for BSP to compute pll-mipi not for TCON_DSI clock
register, SUN4I_TCON0_DCLK_REG, which marked the divider 4 by default.


What compelling evidence have you found that makes you say otherwise?

divider 4 isn't worked, this I would mentioned before as well.

Maybe you mentionned it before, but it's nowhere to be found in your
commit log.


Tested this on 4 different panels, and below are the desired divider values
and pll-mipi clock rate with respect to pixel clock frequency.

- 55MHz pixel clock with 4-lane panel, and the desired DSI clock divider
   is 6 with the output parent clock rate of 330MHz.
- 30MHz pixel clock with 4-lane panel, and the desired DSI clock divider
   is 6 with parent clock rate of 180MHz.
- 27.5Mhz pixel clock with 2-lane pane, and the desired DSI clock divider
   is 12 with the output parent clock rate of 330MHz.
- 147MHz pixel clock with 4-lane panel, and the desired DSI clock divider
   is 6 with the output parent clock rate of 882MHz.

BSP trying to use this format/lane to compute dsi divider that in-turn
using pll-mipi set_rate but TCON0_DCLK_REG keep constant 4.

Feel free to reply to
http://lists.infradead.org/pipermail/linux-arm-kernel/2019-February/629596.html

And correct whatever is said there that isn't what is happening.



excuse me if my message is out of topic.

I just want let you know  that the code

tcon->dclk_min_div = SUN6I_DSI_TCON_DIV;
tcon->dclk_max_div = SUN6I_DSI_TCON_DIV;

where SUN6I_DSI_TCON_DIV = 4  isn't working with my 2-lane panel: I am 
always getting the error:


 [CRTC:38:crtc-0] vblank wait timed out

As soon as I set

tcon->dclk_min_div = tcon->dclk_max_div = bpp/lanes, i.e. 12

the error disappears.



Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/omap: simplify getting .driver_data

[Wolfram Sang]

We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.

Signed-off-by: Wolfram Sang 
---

Build tested only. buildbot is happy.

 drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c 
b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
index 29692a5217c5..88d4b0c60689 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c
@@ -412,8 +412,7 @@ static const struct backlight_ops dsicm_bl_ops = {
 static ssize_t dsicm_num_errors_show(struct device *dev,
struct device_attribute *attr, char *buf)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+   struct panel_drv_data *ddata = dev_get_drvdata(dev);
struct omap_dss_device *src = ddata->dssdev.src;
u8 errors = 0;
int r;
@@ -444,8 +443,7 @@ static ssize_t dsicm_num_errors_show(struct device *dev,
 static ssize_t dsicm_hw_revision_show(struct device *dev,
struct device_attribute *attr, char *buf)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+   struct panel_drv_data *ddata = dev_get_drvdata(dev);
struct omap_dss_device *src = ddata->dssdev.src;
u8 id1, id2, id3;
int r;
@@ -476,8 +474,7 @@ static ssize_t dsicm_store_ulps(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+   struct panel_drv_data *ddata = dev_get_drvdata(dev);
struct omap_dss_device *src = ddata->dssdev.src;
unsigned long t;
int r;
@@ -511,8 +508,7 @@ static ssize_t dsicm_show_ulps(struct device *dev,
struct device_attribute *attr,
char *buf)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+   struct panel_drv_data *ddata = dev_get_drvdata(dev);
unsigned int t;
 
mutex_lock(>lock);
@@ -526,8 +522,7 @@ static ssize_t dsicm_store_ulps_timeout(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+   struct panel_drv_data *ddata = dev_get_drvdata(dev);
struct omap_dss_device *src = ddata->dssdev.src;
unsigned long t;
int r;
@@ -558,8 +553,7 @@ static ssize_t dsicm_show_ulps_timeout(struct device *dev,
struct device_attribute *attr,
char *buf)
 {
-   struct platform_device *pdev = to_platform_device(dev);
-   struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+   struct panel_drv_data *ddata = dev_get_drvdata(dev);
unsigned int t;
 
mutex_lock(>lock);
-- 
2.11.0

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

Re: [linux-sunxi] [PATCH v3 02/28] clk: sunxi-ng: Adjust MP clock parent rate when allowed

[Priit Laes]

On Mon, Jan 21, 2019 at 07:13:07PM +0100, Jernej Škrabec wrote:
> Dne ponedeljek, 21. januar 2019 ob 14:34:33 CET je Priit Laes napisal(a):
> > On Mon, Jan 21, 2019 at 08:37:29AM +, Priit Laes wrote:
> > > On Fri, Jan 18, 2019 at 10:51:10PM +0100, Jernej Škrabec wrote:
> > > > Dne četrtek, 17. januar 2019 ob 08:24:02 CET je Priit Laes napisal(a):
> > > > > On Wed, Jan 16, 2019 at 06:00:32PM +0100, Jernej Škrabec wrote:
> > > > > > Dne sreda, 16. januar 2019 ob 13:09:58 CET je Priit Laes napisal(a):
> > > > > > > On Thu, Jan 10, 2019 at 06:10:59PM +0100, Jernej Škrabec wrote:
> > > > > > > > Dne četrtek, 10. januar 2019 ob 10:15:48 CET je Priit Laes 
> napisal(a):
> > > > > > > > > On Sun, Nov 04, 2018 at 07:26:39PM +0100, Jernej Skrabec 
> wrote:
> > > > > > > > > > Currently MP clocks don't consider adjusting parent rate
> > > > > > > > > > even if
> > > > > > > > > > they
> > > > > > > > > > are allowed to do so. Such behaviour considerably lowers
> > > > > > > > > > amount of
> > > > > > > > > > possible rates, which is very inconvenient when such clock
> > > > > > > > > > is used
> > > > > > > > > > for
> > > > > > > > > > pixel clock, for example.
> > > > > > > > > > 
> > > > > > > > > > In order to improve the situation, adjusting parent rate is
> > > > > > > > > > considered
> > > > > > > > > > when allowed.
> > > > > > > > > > 
> > > > > > > > > > This code is inspired by clk_divider_bestdiv() function,
> > > > > > > > > > which
> > > > > > > > > > does
> > > > > > > > > > basically the same thing for different clock type.
> > > > > > > > > 
> > > > > > > > > This patch seems to break the eMMC support on
> > > > > > > > > Olinuxino-Lime2-eMMC
> > > > > > > > > boards:
> > > > > > > > > 
> > > > > > > > > EXT4-fs (mmcblk1p4): INFO: recovery required on readonly
> > > > > > > > > filesystem
> > > > > > > > > EXT4-fs (mmcblk1p4): write access will be enabled during
> > > > > > > > > recovery
> > > > > > > > > sunxi-mmc 1c11000.mmc: data error, sending stop command
> > > > > > > > > sunxi-mmc 1c11000.mmc: send stop command failed
> > > > > > > > 
> > > > > > > > I'm not familiar with A20. What is interesting is that emmc
> > > > > > > > clocks
> > > > > > > > don't
> > > > > > > > have CLK_SET_RATE_PARENT flag set, so you shouldn't see any
> > > > > > > > difference.
> > > > > > > > 
> > > > > > > > Can you post content of clk_summary with and without this patch?
> > > > > > > 
> > > > > > > In both cases I booted from FEL with rootfs on sdcard and tried to
> > > > > > > mount
> > > > > > > partition from eMMC to /mnt. With your patch, last step it fails.
> > > > > > > 
> > > > > > > pre-patch working:
> > > > > > > pll-ddr-other[768MHz] -> mmc2[512MHz]. (For some reason ahb-mmc2
> > > > > > > is
> > > > > > > off?)
> > > > > > > 
> > > > > > > post-patch not working:
> > > > > > > pll-periph[600MHz] ->  mmc2[500Mhz], (ahb-mmc2 is enabled)
> > > > > > > 
> > > > > > > Also, attached the logs.
> > > > > > 
> > > > > > Thanks. Just one more request. Can you enable debug messages in mmc
> > > > > > driver?
> > > > > > I'm interested in output of this line:
> > > > > > 
> > > > > > dev_dbg(mmc_dev(mmc), "setting clk to %d, rounded %ld\n",
> > > > > > 
> > > > > > clock, rate);
> > > > > 
> > > > > 1c11000 is eMMC:
> > > > > [snip]
> > > > > [1.961644] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded
> > > > > 40
> > > > > [2.004091] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded
> > > > > 40
> > > > > [2.020296] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded
> > > > > 40
> > > > > [2.039917] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded
> > > > > 40
> > > > > [2.047847] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded
> > > > > 40
> > > > > [2.055053] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded
> > > > > 40
> > > > > [2.065256] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded
> > > > > 40
> > > > > [2.092351] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded
> > > > > 40
> > > > > [2.168725] sunxi-mmc 1c11000.mmc: setting clk to 40, rounded
> > > > > 40
> > > > > [2.189403] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded
> > > > > 5200 [2.203340] sunxi-mmc 1c11000.mmc: setting clk to
> > > > > 5200,
> > > > > rounded 5200 [2.211412] sunxi-mmc 1c11000.mmc: setting clk to
> > > > > 5200, rounded 5200 [4.967865] sunxi-mmc 1c11000.mmc:
> > > > > setting
> > > > > clk to 5200, rounded 5200 [8.755345] sunxi-mmc
> > > > > 1c11000.mmc:
> > > > > setting clk to 5200, rounded 5200 [9.082510] sunxi-mmc
> > > > > 1c11000.mmc: setting clk to 5200, rounded 5200
> > > > > 
> > > > > Here I tried to mount partition from eMMC...
> > > > > 
> > > > > [   72.167311] sunxi-mmc 1c11000.mmc: setting clk to 5200, rounded
> > > > > 5200 [   72.269629] sunxi-mmc 1c11000.mmc: data error, sending
> > > > > 

Re: [PATCH v2 7/8] drm/meson: Add YUV420 output support

[Maxime Jourdan]

Hi Neil,

On Fri, Feb 1, 2019 at 1:08 PM Neil Armstrong  wrote:
>
> This patch adds support for the YUV420 output from the Amlogic Meson SoCs
> Video Processing Unit to the HDMI Controller.
>
> The YUV420 is obtained by generating a YUV444 pixel stream like
> the classic HDMI display modes, but then the Video Encoder output
> can be configured to down-sample the YUV444 pixel stream to a YUV420
> stream.
> In addition if pixel stream down-sampling, the Y Cb Cr components must
> also be mapped differently to align with the HDMI2.0 specifications.
>
> This mode needs a different clock generation scheme since the TMDS PHY
> clock must match the 10x ration with the YUV420 pixel clock, but
> the video encoder must run at 2x the pixel clock.
>
> This patch adds the TMDS PHY clock value in all the video clock setup
> in order to better support these specific uses cases and switch
> to the Common Clock framework for clocks handling in the future.
>
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/meson/meson_dw_hdmi.c   | 110 
> ++--
>  drivers/gpu/drm/meson/meson_vclk.c  |  93 ---
>  drivers/gpu/drm/meson/meson_vclk.h  |   7 +-
>  drivers/gpu/drm/meson/meson_venc.c  |   6 +-
>  drivers/gpu/drm/meson/meson_venc.h  |  11 
>  drivers/gpu/drm/meson/meson_venc_cvbs.c |   3 +-
>  6 files changed, 184 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c 
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index e28814f..540971a 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -141,6 +141,8 @@ struct meson_dw_hdmi {
> struct regulator *hdmi_supply;
> u32 irq_stat;
> struct dw_hdmi *hdmi;
> +   unsigned long input_bus_format;
> +   unsigned long output_bus_format;
>  };
>  #define encoder_to_meson_dw_hdmi(x) \
> container_of(x, struct meson_dw_hdmi, encoder)
> @@ -323,25 +325,36 @@ static void dw_hdmi_set_vclk(struct meson_dw_hdmi 
> *dw_hdmi,
>  {
> struct meson_drm *priv = dw_hdmi->priv;
> int vic = drm_match_cea_mode(mode);
> +   unsigned int phy_freq;
> unsigned int vclk_freq;
> unsigned int venc_freq;
> unsigned int hdmi_freq;
>
> vclk_freq = mode->clock;
>
> +   /* For 420, pixel clock is half unlike venc clock */
> +   if (dw_hdmi->input_bus_format == MEDIA_BUS_FMT_UYYVYY8_0_5X24)
> +   vclk_freq /= 2;
> +
> +   /* TMDS clock is pixel_clock * 10 */
> +   phy_freq = vclk_freq * 10;
> +
> if (!vic) {
> -   meson_vclk_setup(priv, MESON_VCLK_TARGET_DMT, vclk_freq,
> -vclk_freq, vclk_freq, false);
> +   meson_vclk_setup(priv, MESON_VCLK_TARGET_DMT, phy_freq,
> +vclk_freq, vclk_freq, vclk_freq, false);
> return;
> }
>
> +   /* 480i/576i needs global pixel doubling */
> if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> vclk_freq *= 2;
>
> venc_freq = vclk_freq;
> hdmi_freq = vclk_freq;
>
> -   if (meson_venc_hdmi_venc_repeat(vic))
> +   /* VENC double pixels for 1080i, 720p and YUV420 modes */
> +   if (meson_venc_hdmi_venc_repeat(vic) ||
> +   dw_hdmi->input_bus_format == MEDIA_BUS_FMT_UYYVYY8_0_5X24)
> venc_freq *= 2;
>
> vclk_freq = max(venc_freq, hdmi_freq);
> @@ -349,11 +362,11 @@ static void dw_hdmi_set_vclk(struct meson_dw_hdmi 
> *dw_hdmi,
> if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> venc_freq /= 2;
>
> -   DRM_DEBUG_DRIVER("vclk:%d venc=%d hdmi=%d enci=%d\n",
> -   vclk_freq, venc_freq, hdmi_freq,
> +   DRM_DEBUG_DRIVER("vclk:%d phy=%d venc=%d hdmi=%d enci=%d\n",
> +   phy_freq, vclk_freq, venc_freq, hdmi_freq,
> priv->venc.hdmi_use_enci);
>
> -   meson_vclk_setup(priv, MESON_VCLK_TARGET_HDMI, vclk_freq,
> +   meson_vclk_setup(priv, MESON_VCLK_TARGET_HDMI, phy_freq, vclk_freq,
>  venc_freq, hdmi_freq, priv->venc.hdmi_use_enci);
>  }
>
> @@ -386,8 +399,9 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void 
> *data,
> /* Enable normal output to PHY */
> dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_BIST_CNTL, BIT(12));
>
> -   /* TMDS pattern setup (TOFIX Handle the YUV420 case) */
> -   if (mode->clock > 34) {
> +   /* TMDS pattern setup */
> +   if (mode->clock > 34 &&
> +   dw_hdmi->input_bus_format == MEDIA_BUS_FMT_YUV8_1X24) {
> dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_01, 0);
> dw_hdmi_top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_23,
>   0x03ff03ff);
> @@ -560,6 +574,8 @@ dw_hdmi_mode_valid(struct drm_connector *connector,
>const struct drm_display_mode *mode)
>  {
> struct meson_drm *priv = 

[Bug 109338] hdmi/displayport audio is a semitone lower when amdgpu driver is used

[bugzilla-daemon]

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

--- Comment #1 from Thanos Apostolou  ---
Still present with linux 5.0.x

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

Re: [PATCH 1/2] drm/doc: fix kerneldoc syntax

[Luca Ceresoli]

On 14/03/19 11:41, Daniel Vetter wrote:
> On Wed, Mar 13, 2019 at 04:35:36PM +0100, Luca Ceresoli wrote:
>> The probe() reference renders incorrectly and without a link, fix it.
>>
>> Also fix a typo reported by checkpatch in the context lines.
>>
>> Signed-off-by: Luca Ceresoli 
>> ---
>>  drivers/gpu/drm/drm_drv.c | 14 +++---
>>  1 file changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index 381581b01d48..585f5d079046 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -264,13 +264,13 @@ void drm_minor_release(struct drm_minor *minor)
>>   * DOC: driver instance overview
>>   *
>>   * A device instance for a drm driver is represented by  drm_device. 
>> This
>> - * is initialized with drm_dev_init(), usually from bus-specific ->probe()
>> - * callbacks implemented by the driver. The driver then needs to initialize 
>> all
>> - * the various subsystems for the drm device like memory management, vblank
>> - * handling, modesetting support and intial output configuration plus 
>> obviously
>> - * initialize all the corresponding hardware bits. Finally when everything 
>> is up
>> - * and running and ready for userspace the device instance can be published
>> - * using drm_dev_register().
>> + * is initialized with drm_dev_init(), usually from bus-specific
>> + * _driver.probe() callbacks implemented by the driver. The driver then
> 
> drm_driver.probe isn't a thing, and definitely not bus specific. What
> could work here is:

You're obviously right, thanks for taking the time to correct me.

> "... instead of a bus specific probe function like e.g.
> _driver.probe or _driver.probe."

Uhm, these don't want to render as hyperlinks. I guess it's because
these structs are not kernel-doc-annotated, nor are their .probe
methods. Probably not worth just doing that for the sake of this humble
patch.

Is it OK if I resend with just the basic syntax fix:
- ... bus-specific ->probe()
+ ... bus-specific probe()
?

Thanks,
-- 
Luca
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 108323] RX580 starts doing a constant noise after setting fans to a fixed value, then back to auto

[bugzilla-daemon]

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

bmil...@gmail.com changed:

   What|Removed |Added

   Priority|medium  |high
   Severity|normal  |major

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

Re: [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION)

[Andrew F. Davis]

On 3/19/19 11:54 AM, Benjamin Gaignard wrote:
> Le mer. 13 mars 2019 à 23:31, John Stultz  a écrit :
>>
>> On Wed, Mar 13, 2019 at 1:11 PM Liam Mark  wrote:
>>> On Tue, 5 Mar 2019, John Stultz wrote:

 Eventual TODOS:
 * Reimplement page-pool for system heap (working on this)
 * Add stats accounting to system/cma heaps
 * Make the kselftest actually useful
 * Add other heaps folks see as useful (would love to get
   some help from actual carveout/chunk users)!
>>>
>>> We use a modified carveout heap for certain secure use cases.
>>
>> Cool! It would be great to see if you have any concerns about adding
>> such a secure-carveout heap to this framework. I suspect it would be
>> fairly similar to how its integrated into ION, but particularly I'd be
>> interested in issues around the lack of private flags and other
>> allocation arguments like alignment.
>>
>>> Although there would probably be some benefit in discssing how the dma-buf
>>> heap framework may want to support
>>> secure heaps in the future it is a large topic which I assume you don't
>>> want to tackle now.
>>
>> So I suspect others (Benjamin?) would have a more informed opinion on
>> the details, but the intent is to allow secure heap implementations.
>> I'm not sure what areas of concern you have for this allocation
>> framework in particular?
> 
> yes I would be great to understand how you provide the information to
> tell that a dmabuf
> is secure (or not) since we can't add flag in dmabuf structure itself.
> An option is manage
> the access rights when a device attach itself to the dmabuf but in
> this case you need define
> a list of allowed devices per heap...
> If you have a good solution for secure heaps you are welcome :-)
> 

Do we really need any of that? A secure buffer is secured by the
hardware firewalls that keep out certain IP (including often the
processor running Linux). So the only thing we need to track internally
is that we should not allow mmap/kmap on the buffer. That can be done in
the per-heap layer, everything else stays the same as a standard
carveout heap.

Andrew

> Benjamin
>>
>>> We don't have any non-secure carveout heap use cases but the client use
>>> case I have seen usually revolve around
>>> wanting large allocations to succeed very quickly.
>>> For example I have seen camera use cases which do very large allocations
>>> on camera bootup from the carveout heap, these allocations would come from
>>> the carveout heap and fallback to the system heap when the carveout heap
>>> was full.
>>> Actual non-secure carveout heap can perhaps provide more detail.
>>
>> Yea, I'm aware that folks still see carveout as preferable to CMA due
>> to more consistent/predictable allocation latency.  I think we still
>> have the issue that we don't have bindings to establish/configure
>> carveout regions w/ dts, and I'm not really wanting to hold up the
>> allocation API on that issue.
>>
>>
>>> Since we are making some fundamental changes to how ION worked and since
>>> Android is likely also be the largest user of the dma-buf heaps framework
>>> I think it would be good
>>> to have a path to resolve the issues which are currently preventing
>>> commercial Android releases from moving to the upstream version of ION.
>>
>> Yea, I do see solving the cache management efficiency issues as
>> critical for the dmabuf heaps to be actually usable (my previous
>> version of this patchset accidentally had my hacks to improve
>> performance rolled in!).  And there are discussions going on in
>> various channels to try to figure out how to either change Android to
>> use dma-bufs more in line with how upstream expects, or what more
>> generic dma-buf changes we may need to allow Android to use dmabufs
>> with the expected performance they need.
>>
>>> I can understand if you don't necessarily want to put all/any of these
>>> changes into the dma-buf heaps framework as part of this series, but my
>>> hope is we can get
>>> the upstream community and the Android framework team to agree on what
>>> upstreamable changes to dma-buf heaps framework, and/or the Android
>>> framework, would be required in order for Android to move to the upstream
>>> dma-buf heaps framework for commercial devices.
>>
>> Yes. Though I also don't want to get the bigger dma-buf usage
>> discussion (which really affects all dmabuf exporters) too tied up
>> with this patch sets attempt to provide a usable allocation interface.
>> Part of the problem that I think we've seen with ION is that there is
>> a nest of of related issues, and the entire thing is just too big to
>> address at once, which I think is part of why ION has sat in staging
>> for so long. This patchset just tries to provide an dmabuf allocation
>> interface, and a few example exporter heap types.
>>
>>> I don't mean to make this specific to Android, but my assumption is that
>>> many of the ION/dma-buf heaps issues which affect Android would likely
>>> affect other new large 

Re: Indirect call in vesafb driver

[Alan Cox]

On Wed, 13 Mar 2019 17:54:18 +0300
Alexander Pateenok  wrote:

> Hi,
> 
> There're several indirect calls in inline assembly in vesafb driver
> (drivers/video/fbdev/vesafb.c), and these calls cannot be automatically
> changed to retpolines. It's in vesafb_pan_display():
> 
>73__asm__ __volatile__(
>74"call *(%%edi)"
> 
> and in vesa_setpalette():
> 
>   113__asm__ __volatile__(
>   114 "call *(%%esi)"
> 
> Is there need to use CALL_NOSPEC ?

Vesafb is from the time on the dinosaurs but yes any vesa bios code will
not be speculatively hardened. I'd also doubt anyone is actually using
vesafb in the first place but it should use nospec

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

Re: [RFC][PATCH 0/5 v2] DMA-BUF Heaps (destaging ION)

[Benjamin Gaignard]

Le mer. 13 mars 2019 à 23:31, John Stultz  a écrit :
>
> On Wed, Mar 13, 2019 at 1:11 PM Liam Mark  wrote:
> > On Tue, 5 Mar 2019, John Stultz wrote:
> > >
> > > Eventual TODOS:
> > > * Reimplement page-pool for system heap (working on this)
> > > * Add stats accounting to system/cma heaps
> > > * Make the kselftest actually useful
> > > * Add other heaps folks see as useful (would love to get
> > >   some help from actual carveout/chunk users)!
> >
> > We use a modified carveout heap for certain secure use cases.
>
> Cool! It would be great to see if you have any concerns about adding
> such a secure-carveout heap to this framework. I suspect it would be
> fairly similar to how its integrated into ION, but particularly I'd be
> interested in issues around the lack of private flags and other
> allocation arguments like alignment.
>
> > Although there would probably be some benefit in discssing how the dma-buf
> > heap framework may want to support
> > secure heaps in the future it is a large topic which I assume you don't
> > want to tackle now.
>
> So I suspect others (Benjamin?) would have a more informed opinion on
> the details, but the intent is to allow secure heap implementations.
> I'm not sure what areas of concern you have for this allocation
> framework in particular?

yes I would be great to understand how you provide the information to
tell that a dmabuf
is secure (or not) since we can't add flag in dmabuf structure itself.
An option is manage
the access rights when a device attach itself to the dmabuf but in
this case you need define
a list of allowed devices per heap...
If you have a good solution for secure heaps you are welcome :-)

Benjamin
>
> > We don't have any non-secure carveout heap use cases but the client use
> > case I have seen usually revolve around
> > wanting large allocations to succeed very quickly.
> > For example I have seen camera use cases which do very large allocations
> > on camera bootup from the carveout heap, these allocations would come from
> > the carveout heap and fallback to the system heap when the carveout heap
> > was full.
> > Actual non-secure carveout heap can perhaps provide more detail.
>
> Yea, I'm aware that folks still see carveout as preferable to CMA due
> to more consistent/predictable allocation latency.  I think we still
> have the issue that we don't have bindings to establish/configure
> carveout regions w/ dts, and I'm not really wanting to hold up the
> allocation API on that issue.
>
>
> > Since we are making some fundamental changes to how ION worked and since
> > Android is likely also be the largest user of the dma-buf heaps framework
> > I think it would be good
> > to have a path to resolve the issues which are currently preventing
> > commercial Android releases from moving to the upstream version of ION.
>
> Yea, I do see solving the cache management efficiency issues as
> critical for the dmabuf heaps to be actually usable (my previous
> version of this patchset accidentally had my hacks to improve
> performance rolled in!).  And there are discussions going on in
> various channels to try to figure out how to either change Android to
> use dma-bufs more in line with how upstream expects, or what more
> generic dma-buf changes we may need to allow Android to use dmabufs
> with the expected performance they need.
>
> > I can understand if you don't necessarily want to put all/any of these
> > changes into the dma-buf heaps framework as part of this series, but my
> > hope is we can get
> > the upstream community and the Android framework team to agree on what
> > upstreamable changes to dma-buf heaps framework, and/or the Android
> > framework, would be required in order for Android to move to the upstream
> > dma-buf heaps framework for commercial devices.
>
> Yes. Though I also don't want to get the bigger dma-buf usage
> discussion (which really affects all dmabuf exporters) too tied up
> with this patch sets attempt to provide a usable allocation interface.
> Part of the problem that I think we've seen with ION is that there is
> a nest of of related issues, and the entire thing is just too big to
> address at once, which I think is part of why ION has sat in staging
> for so long. This patchset just tries to provide an dmabuf allocation
> interface, and a few example exporter heap types.
>
> > I don't mean to make this specific to Android, but my assumption is that
> > many of the ION/dma-buf heaps issues which affect Android would likely
> > affect other new large users of the dma-buf heaps framework, so if we
> > resolve it for Android we would be helping these future users as well.
> > And I do understand that some the issues facing Android may need to be
> > resolved by making changes to Android framework.
>
> While true, I also think some of the assumptions in how the dma-bufs
> are used (pre-attachment of all devices, etc) are maybe not so
> realistic given how Android is using them.  I do want to explore if
> Android 

[Bug 108917] gamma adjustments cause stuttering with amdgpu.dc=1, especially problematic with RedShift etc.

[bugzilla-daemon]

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

--- Comment #9 from Nicholas Kazlauskas  ---
(In reply to tempel.julian from comment #8)
> Unfortunately, Linux 5.0.3 with
> 
> drm: Block fb changes for async plane updates
> commit 25dc194b34dd5919dd07b8873ee338182e15df9d
> 
> hasn't changed the situation, as far as I can tell. :(

That's the DRM level bugfix for use after free on async updates for plane
framebuffer swaps. It actually hurts performance rather than helps it.

There's a fix that allows framebuffer swaps again being developed right now
with some patches in dri-devel:

https://patchwork.freedesktop.org/series/57524/

You'd have to revert

"drm/amd/display: Skip fast cursor updates for fb changes"

as well though to actually allow this series to work.

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

[Bug 108917] gamma adjustments cause stuttering with amdgpu.dc=1, especially problematic with RedShift etc.

[bugzilla-daemon]

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

--- Comment #8 from tempel.jul...@gmail.com ---
Unfortunately, Linux 5.0.3 with

drm: Block fb changes for async plane updates
commit 25dc194b34dd5919dd07b8873ee338182e15df9d

hasn't changed the situation, as far as I can tell. :(

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

Re: [PATCH] drm/fourcc: Fix conflicting Y41x definitions

[Ville Syrjälä]

On Tue, Mar 19, 2019 at 05:06:36PM +0100, Maarten Lankhorst wrote:
> Op 19-03-2019 om 14:02 schreef Ville Syrjälä:
> > On Tue, Mar 19, 2019 at 01:17:02PM +0100, Maarten Lankhorst wrote:
> >> There has unfortunately been a conflict with the following 3 commits:
> >>
> >> commit e9961ab95af81b8d29054361cd5f0c575102cf87
> >> Author: Ayan Kumar Halder 
> >> Date:   Fri Nov 9 17:21:12 2018 +
> >> drm: Added a new format DRM_FORMAT_XVYU2101010
> >>
> >> commit 7ba0fee247ee7a36b3bfbed68f6988d980aa3aa3
> >> Author: Brian Starkey 
> >> Date:   Fri Oct 5 10:27:00 2018 +0100
> >>
> >> drm/fourcc: Add AFBC yuv fourccs for Mali
> >>
> >> and
> >>
> >> commit 50bf5d7d595fd0705ef3785f80e679b6da501e5b
> >> Author: Swati Sharma 
> >> Date:   Mon Mar 4 17:26:33 2019 +0530
> >>
> >> drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
> >>
> >> Unfortunately gcc didn't warn about the redefinitions, because the
> >>
> >> Fix this by using new XYVU for i915, without alpha, and making the
> >> Y41x definitions match msdn, with alpha.
> > The naming of all these is rather unfortunate because now the alpha vs.
> > non-alpha formats have totally different looking names :( Fourccs are
> > stupid!
> >
> >> Fortunately we caught it early, and the conflict hasn't even landed in
> >> drm-next yet.
> >>
> >> Signed-off-by: Maarten Lankhorst 
> >> Cc: Brian Starkey 
> >> Cc: Swati Sharma 
> >> Cc: Ayan Kumar Halder 
> >> Cc: mal...@foss.arm.com
> >> Cc: Daniel Vetter 
> >> Cc: Maxime Ripard 
> >> Cc: Sean Paul 
> >> Cc: Dave Airlie 
> >> Cc: Liviu Dudau 
> >> ---
> >>  drivers/gpu/drm/drm_fourcc.c | 12 +--
> >>  drivers/gpu/drm/i915/intel_display.c | 18 -
> >>  drivers/gpu/drm/i915/intel_sprite.c  | 30 ++--
> >>  include/uapi/drm/drm_fourcc.h| 21 +--
> >>  4 files changed, 41 insertions(+), 40 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> >> index b914b16db9b2..6ea55fb4526d 100644
> >> --- a/drivers/gpu/drm/drm_fourcc.c
> >> +++ b/drivers/gpu/drm/drm_fourcc.c
> >> @@ -229,17 +229,17 @@ const struct drm_format_info *__drm_format_info(u32 
> >> format)
> >>{ .format = DRM_FORMAT_UYVY,.depth = 0,  
> >> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true 
> >> },
> >>{ .format = DRM_FORMAT_VYUY,.depth = 0,  
> >> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true 
> >> },
> >>{ .format = DRM_FORMAT_XYUV,.depth = 0,  
> >> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true 
> >> },
> >> -  { .format = DRM_FORMAT_Y210,.depth = 0,  
> >> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true 
> >> },
> >>{ .format = DRM_FORMAT_VUY888,  .depth = 0,  
> >> .num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true 
> >> },
> >> -  { .format = DRM_FORMAT_Y410,.depth = 0,  
> >> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> >> true, .is_yuv = true },
> >>{ .format = DRM_FORMAT_AYUV,.depth = 0,  
> >> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> >> true, .is_yuv = true },
> >> -  { .format = DRM_FORMAT_XVYU2101010, .depth = 0,  
> >> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true 
> >> },
> >>{ .format = DRM_FORMAT_Y210,.depth = 0,  
> >> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true 
> >> },
> >>{ .format = DRM_FORMAT_Y212,.depth = 0,  
> >> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true 
> >> },
> >>{ .format = DRM_FORMAT_Y216,.depth = 0,  
> >> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true 
> >> },
> >> -  { .format = DRM_FORMAT_Y410,.depth = 0,  
> >> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true 
> >> },
> >> -  { .format = DRM_FORMAT_Y412,.depth = 0,  
> >> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true 
> >> },
> >> -  { .format = DRM_FORMAT_Y416,.depth = 0,  
> >> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true 
> >> },
> >> +  { .format = DRM_FORMAT_Y410,.depth = 0,  
> >> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> >> true, .is_yuv = true },
> >> +  { .format = DRM_FORMAT_Y412,.depth = 0,  
> >> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> >> true, .is_yuv = true },
> >> +  { .format = DRM_FORMAT_Y416,.depth = 0,  
> >> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
> >> true, .is_yuv = true },

Re: [PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali

[Maarten Lankhorst]

Hey,

Op 19-03-2019 om 00:27 schreef Ayan Halder:
> On Mon, Mar 18, 2019 at 07:12:24PM +0100, Maarten Lankhorst wrote:
>> Op 18-03-2019 om 16:40 schreef Brian Starkey:
>>> Hi,
>>>
>>> On Mon, Mar 18, 2019 at 11:17:55AM +0100, Maarten Lankhorst wrote:
>>>
>>> 
>>>
 Hey..

 There's a conflict with this patch and the merge of topic/hdr-formats, 
 resulting in double definitions for Y210, Y410 and P010.

 Worse still is that one has set has_alpha to true for Y41x and other to 
 false.

 ~Maarten

>>> Oh that's sad :-( I think this fell through the cracks on our side
>>> when someone left our team. Also turns out I'm not subscribed to
>>> igt-dev.
>>>
>>> I see you commented the same on one of the previous patches, and that
>>> there was some discussion of this on the test patches too.
>>>
>>> I have been referring to Microsoft's page[1] as "the" source for these
>>> formats, which does indeed call out Y410 as having 2 bits of alpha.
>>> Our GPU expects alpha.
>> Ah. Yeah there has been discussion on whether there was supposed to be alpha 
>> or not, but the original discussion on HDR formats has been completely 
>> ignored by arm.
>>
>> The patch had originally a few arm devs on cc and was sent to dri-devel with 
>> linux-media cc'd. Was sad to see it completely ignored so after having been 
>> sent twice I pushed it.
> Apologies, I see that I was cc-ed in the mail 'drm: Add Y2xx and Y4xx
> (xx:10/12/16) format definitions and fourcc' sent by
> swati2.sha...@intel.com. It got lost in my pile of unread mails. :(
>
> About this patch, I had tagged you in irc channel
> (https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel_names==2019-03-11_html=true)
> for reviewing this seies. Did not hear back from you then ?

Looks like we both unfortunately not looked at each others series then, or at 
least I missed the HDR formats part.

>>> Was there a specific reason for opting to change the test instead of
>>> the definition? Any way to get this changed now?
>>>
>>> It doesn't seem that sensible for the kernel to call something Y410
>>> which doesn't match an "existing" definition by the same name. If
>>> alpha needs to be ignored on scanout, the alpha blend mode property
>>> can be used (more archaeology - I see that was still giving CRC
>>> failures, but that might be a "known issue" for all YUV on your HW?)
>> Were a few bugs, but should be fixed now. :)
>>
>> Well only that we didn't have hw supporting alpha, and didn't hear back from 
>> others so we went without alpha.
> In light of the suggestions made by brian.star...@arm.com, I think
> changing the format from Y410 to X410 (in your case) might make sense
> as the alpha bits are absent.
> If this suggestion looks reasonable to you, I can volunteer myself to make
> this change in topic/hdr-formats.

I sent a patch to fix the conflicts. There's already XVYU2101010 in that 
series, which is
Y410 without alpha. I've extended it and used it to convert i915. It's 
unfortunate those
conflicts happen, but fortunately it didn't spread to drm-next or linux-next.

Link: https://patchwork.freedesktop.org/patch/292977/?series=58182=1

Tested it, basic tests seems to work for i915.

~Maarten

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

Re: [PATCH] drm/fourcc: Fix conflicting Y41x definitions

[Maarten Lankhorst]

Op 19-03-2019 om 14:02 schreef Ville Syrjälä:
> On Tue, Mar 19, 2019 at 01:17:02PM +0100, Maarten Lankhorst wrote:
>> There has unfortunately been a conflict with the following 3 commits:
>>
>> commit e9961ab95af81b8d29054361cd5f0c575102cf87
>> Author: Ayan Kumar Halder 
>> Date:   Fri Nov 9 17:21:12 2018 +
>> drm: Added a new format DRM_FORMAT_XVYU2101010
>>
>> commit 7ba0fee247ee7a36b3bfbed68f6988d980aa3aa3
>> Author: Brian Starkey 
>> Date:   Fri Oct 5 10:27:00 2018 +0100
>>
>> drm/fourcc: Add AFBC yuv fourccs for Mali
>>
>> and
>>
>> commit 50bf5d7d595fd0705ef3785f80e679b6da501e5b
>> Author: Swati Sharma 
>> Date:   Mon Mar 4 17:26:33 2019 +0530
>>
>> drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
>>
>> Unfortunately gcc didn't warn about the redefinitions, because the
>>
>> Fix this by using new XYVU for i915, without alpha, and making the
>> Y41x definitions match msdn, with alpha.
> The naming of all these is rather unfortunate because now the alpha vs.
> non-alpha formats have totally different looking names :( Fourccs are
> stupid!
>
>> Fortunately we caught it early, and the conflict hasn't even landed in
>> drm-next yet.
>>
>> Signed-off-by: Maarten Lankhorst 
>> Cc: Brian Starkey 
>> Cc: Swati Sharma 
>> Cc: Ayan Kumar Halder 
>> Cc: mal...@foss.arm.com
>> Cc: Daniel Vetter 
>> Cc: Maxime Ripard 
>> Cc: Sean Paul 
>> Cc: Dave Airlie 
>> Cc: Liviu Dudau 
>> ---
>>  drivers/gpu/drm/drm_fourcc.c | 12 +--
>>  drivers/gpu/drm/i915/intel_display.c | 18 -
>>  drivers/gpu/drm/i915/intel_sprite.c  | 30 ++--
>>  include/uapi/drm/drm_fourcc.h| 21 +--
>>  4 files changed, 41 insertions(+), 40 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
>> index b914b16db9b2..6ea55fb4526d 100644
>> --- a/drivers/gpu/drm/drm_fourcc.c
>> +++ b/drivers/gpu/drm/drm_fourcc.c
>> @@ -229,17 +229,17 @@ const struct drm_format_info *__drm_format_info(u32 
>> format)
>>  { .format = DRM_FORMAT_UYVY,.depth = 0,  
>> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
>>  { .format = DRM_FORMAT_VYUY,.depth = 0,  
>> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
>>  { .format = DRM_FORMAT_XYUV,.depth = 0,  
>> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
>> -{ .format = DRM_FORMAT_Y210,.depth = 0,  
>> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
>>  { .format = DRM_FORMAT_VUY888,  .depth = 0,  
>> .num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
>> -{ .format = DRM_FORMAT_Y410,.depth = 0,  
>> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
>> true, .is_yuv = true },
>>  { .format = DRM_FORMAT_AYUV,.depth = 0,  
>> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
>> true, .is_yuv = true },
>> -{ .format = DRM_FORMAT_XVYU2101010, .depth = 0,  
>> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
>>  { .format = DRM_FORMAT_Y210,.depth = 0,  
>> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
>>  { .format = DRM_FORMAT_Y212,.depth = 0,  
>> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
>>  { .format = DRM_FORMAT_Y216,.depth = 0,  
>> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
>> -{ .format = DRM_FORMAT_Y410,.depth = 0,  
>> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
>> -{ .format = DRM_FORMAT_Y412,.depth = 0,  
>> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
>> -{ .format = DRM_FORMAT_Y416,.depth = 0,  
>> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
>> +{ .format = DRM_FORMAT_Y410,.depth = 0,  
>> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
>> true, .is_yuv = true },
>> +{ .format = DRM_FORMAT_Y412,.depth = 0,  
>> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
>> true, .is_yuv = true },
>> +{ .format = DRM_FORMAT_Y416,.depth = 0,  
>> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = 
>> true, .is_yuv = true },
>> +{ .format = DRM_FORMAT_XVYU2101010, .depth = 0,  
>> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
>> +{ .format = DRM_FORMAT_XVYU12_16161616, .depth = 0,  
>> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true 

Re: [RFC][PATCH 1/5 v2] dma-buf: Add dma-buf heaps framework

[Andrew F. Davis]

On 3/19/19 7:08 AM, Brian Starkey wrote:
> Hi John,
> 
> On Tue, Mar 05, 2019 at 12:54:29PM -0800, John Stultz wrote:
>> From: "Andrew F. Davis" 
> 
> [snip]
> 
>> +
>> +#define NUM_HEAP_MINORS 128
>> +static DEFINE_IDR(dma_heap_idr);
>> +static DEFINE_MUTEX(minor_lock); /* Protect idr accesses */
> 
> I saw that Matthew Wilcox is trying to nuke idr:
> https://patchwork.freedesktop.org/series/57073/
> 
> Perhaps a different data structure could be considered? (I don't have
> an informed opinion on which).
> 

Looks like XArray is the suggested replacement. Should be easy enough,
the minor number would just index to our heap struct directly, I'll give
it a shot and see.

>> +
>> +dev_t dma_heap_devt;
>> +struct class *dma_heap_class;
>> +struct list_head dma_heap_list;
>> +struct dentry *dma_heap_debug_root;
>> +
>> +static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
>> + unsigned int flags)
>> +{
>> +len = PAGE_ALIGN(len);
>> +if (!len)
>> +return -EINVAL;
> 
> I think aligning len to pages only makes sense if heaps are going to
> allocate aligned to pages too. Perhaps that's an implicit assumption?
> If so, lets document it.
> 
> Why not let the heaps take care of aligning len however they want
> though?
> 

This is how I originally had it, but I think we couldn't find any case
where you would want an the start or end of a buffer to not fall on a
page boundary here. It would only lead to problems. As you say though,
nothing keeping us from moving that into the heaps themselves.

> ...
> 
>> +
>> +int dma_heap_add(struct dma_heap *heap)
>> +{
>> +struct device *dev_ret;
>> +int ret;
>> +
>> +if (!heap->name || !strcmp(heap->name, "")) {
>> +pr_err("dma_heap: Cannot add heap without a name\n");
>> +return -EINVAL;
>> +}
>> +
>> +if (!heap->ops || !heap->ops->allocate) {
>> +pr_err("dma_heap: Cannot add heap with invalid ops struct\n");
>> +return -EINVAL;
>> +}
>> +
>> +/* Find unused minor number */
>> +mutex_lock(_lock);
>> +ret = idr_alloc(_heap_idr, heap, 0, NUM_HEAP_MINORS, GFP_KERNEL);
>> +mutex_unlock(_lock);
>> +if (ret < 0) {
>> +pr_err("dma_heap: Unable to get minor number for heap\n");
>> +return ret;
>> +}
>> +heap->minor = ret;
>> +
>> +/* Create device */
>> +heap->heap_devt = MKDEV(MAJOR(dma_heap_devt), heap->minor);
>> +dev_ret = device_create(dma_heap_class,
>> +NULL,
>> +heap->heap_devt,
>> +NULL,
>> +heap->name);
>> +if (IS_ERR(dev_ret)) {
>> +pr_err("dma_heap: Unable to create char device\n");
>> +return PTR_ERR(dev_ret);
>> +}
>> +
>> +/* Add device */
>> +cdev_init(>heap_cdev, _heap_fops);
>> +ret = cdev_add(>heap_cdev, dma_heap_devt, NUM_HEAP_MINORS);
> 
> Shouldn't this be s/dma_heap_devt/heap->heap_devt/ and a count of 1?
> 

Hmm, strange this ever worked before..

> Also would it be better to have cdev_add/device_create the other way
> around? First create the char device, then once it's all set up
> register it with sysfs.
> 

Yes that does seem to be more common, lets flip it.

>> +if (ret < 0) {
>> +device_destroy(dma_heap_class, heap->heap_devt);
>> +pr_err("dma_heap: Unable to add char device\n");
>> +return ret;
>> +}
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL(dma_heap_add);
> 
> Until we've figured out how modules are going to work, I still think
> it would be a good idea to not export this.
> 

Agree.

Andrew

> Cheers,
> -Brian
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC][PATCH 2/5 v2] dma-buf: heaps: Add heap helpers

[Andrew F. Davis]

On 3/15/19 4:06 AM, Christoph Hellwig wrote:
>> +ret = remap_pfn_range(vma, addr, page_to_pfn(page), len,
>> +  vma->vm_page_prot);
> 
> So the same chunk could be mapped to userspace and vmap, and later on
> also DMA mapped.  Who is going to take care of cache aliasing as I
> see nothing of that in this series?
> 

We should only have one type of memory per heap so all mappings will
have the same type. That should solve the ARM specific issues, but I'm
guessing you are thinking of more tricky architectures where all
mappings need to be tracked and cleaned/invalidated..

For that I think we will have to track each right? How do others handle
that, we can't be the first to offer cached buffers to userspace.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC][PATCH 4/5 v2] dma-buf: heaps: Add CMA heap to dmabuf heapss

[Brian Starkey]

On Tue, Mar 05, 2019 at 12:54:32PM -0800, John Stultz wrote:
> This adds a CMA heap, which allows userspace to allocate
> a dma-buf of contiguous memory out of a CMA region.
> 
> This code is an evolution of the Android ION implementation, so
> thanks to its original author and maintainters:
>   Benjamin Gaignard, Laura Abbott, and others!
> 
> Cc: Laura Abbott 
> Cc: Benjamin Gaignard 
> Cc: Greg KH 
> Cc: Sumit Semwal 
> Cc: Liam Mark 
> Cc: Brian Starkey 
> Cc: Andrew F. Davis 
> Cc: Chenbo Feng 
> Cc: Alistair Strachan 
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: John Stultz 
> ---
> v2:
> * Switch allocate to return dmabuf fd
> * Simplify init code
> * Checkpatch fixups
> ---
>  drivers/dma-buf/heaps/Kconfig|   8 ++
>  drivers/dma-buf/heaps/Makefile   |   1 +
>  drivers/dma-buf/heaps/cma_heap.c | 164 
> +++
>  3 files changed, 173 insertions(+)
>  create mode 100644 drivers/dma-buf/heaps/cma_heap.c
> 
> diff --git a/drivers/dma-buf/heaps/Kconfig b/drivers/dma-buf/heaps/Kconfig
> index 2050527..a5eef06 100644
> --- a/drivers/dma-buf/heaps/Kconfig
> +++ b/drivers/dma-buf/heaps/Kconfig
> @@ -4,3 +4,11 @@ config DMABUF_HEAPS_SYSTEM
>   help
> Choose this option to enable the system dmabuf heap. The system heap
> is backed by pages from the buddy allocator. If in doubt, say Y.
> +
> +config DMABUF_HEAPS_CMA
> + bool "DMA-BUF CMA Heap"
> + depends on DMABUF_HEAPS && DMA_CMA
> + help
> +   Choose this option to enable dma-buf CMA heap. This heap is backed
> +   by the Contiguous Memory Allocator (CMA). If your system has these
> +   regions, you should say Y here.
> diff --git a/drivers/dma-buf/heaps/Makefile b/drivers/dma-buf/heaps/Makefile
> index d1808ec..6e54cde 100644
> --- a/drivers/dma-buf/heaps/Makefile
> +++ b/drivers/dma-buf/heaps/Makefile
> @@ -1,3 +1,4 @@
>  # SPDX-License-Identifier: GPL-2.0
>  obj-y+= heap-helpers.o
>  obj-$(CONFIG_DMABUF_HEAPS_SYSTEM)+= system_heap.o
> +obj-$(CONFIG_DMABUF_HEAPS_CMA)   += cma_heap.o
> diff --git a/drivers/dma-buf/heaps/cma_heap.c 
> b/drivers/dma-buf/heaps/cma_heap.c
> new file mode 100644
> index 000..33c18ec
> --- /dev/null
> +++ b/drivers/dma-buf/heaps/cma_heap.c
> @@ -0,0 +1,164 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * DMABUF CMA heap exporter
> + *
> + * Copyright (C) 2012, 2019 Linaro Ltd.
> + * Author:  for ST-Ericsson.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "heap-helpers.h"
> +
> +struct cma_heap {
> + struct dma_heap heap;
> + struct cma *cma;
> +};
> +
> +

extra line

> +#define to_cma_heap(x) container_of(x, struct cma_heap, heap)
> +
> +

extra line

> +static void cma_heap_free(struct heap_helper_buffer *buffer)
> +{
> + struct cma_heap *cma_heap = to_cma_heap(buffer->heap_buffer.heap);
> + struct page *pages = buffer->priv_virt;
> + unsigned long nr_pages;
> +
> + nr_pages = PAGE_ALIGN(buffer->heap_buffer.size) >> PAGE_SHIFT;

As you align at alloc time, I don't think the PAGE_ALIGN is really
necessary here.

> +
> + /* release memory */
> + cma_release(cma_heap->cma, pages, nr_pages);
> + /* release sg table */
> + sg_free_table(buffer->sg_table);
> + kfree(buffer->sg_table);
> + kfree(buffer);
> +}
> +
> +/* dmabuf heap CMA operations functions */
> +static int cma_heap_allocate(struct dma_heap *heap,
> + unsigned long len,
> + unsigned long flags)
> +{
> + struct cma_heap *cma_heap = to_cma_heap(heap);
> + struct heap_helper_buffer *helper_buffer;
> + struct sg_table *table;
> + struct page *pages;
> + size_t size = PAGE_ALIGN(len);
> + unsigned long nr_pages = size >> PAGE_SHIFT;
> + unsigned long align = get_order(size);
> + DEFINE_DMA_BUF_EXPORT_INFO(exp_info);
> + struct dma_buf *dmabuf;
> + int ret = -ENOMEM;
> +
> + if (align > CONFIG_CMA_ALIGNMENT)
> + align = CONFIG_CMA_ALIGNMENT;
> +
> + helper_buffer = kzalloc(sizeof(*helper_buffer), GFP_KERNEL);
> + if (!helper_buffer)
> + return -ENOMEM;
> +
> + INIT_HEAP_HELPER_BUFFER(helper_buffer, cma_heap_free);
> + helper_buffer->heap_buffer.flags = flags;
> + helper_buffer->heap_buffer.heap = heap;
> + helper_buffer->heap_buffer.size = len;
> +
> +

extra line

> + pages = cma_alloc(cma_heap->cma, nr_pages, align, false);
> + if (!pages)
> + goto free_buf;
> +
> + if (PageHighMem(pages)) {
> + unsigned long nr_clear_pages = nr_pages;
> + struct page *page = pages;
> +
> + while (nr_clear_pages > 0) {
> + void *vaddr = kmap_atomic(page);
> +
> + memset(vaddr, 0, PAGE_SIZE);
> + kunmap_atomic(vaddr);
> +

Re: [PATCH] drm: hdlcd: Stop failing atomic disable check

[Liviu Dudau]

On Tue, Mar 19, 2019 at 01:14:54PM +, Robin Murphy wrote:
> [ +Sudeep - just FYI ]
> 
> Hi Liviu,
> 
> On 27/02/2019 09:40, Liviu Dudau wrote:
> > Hi Robin,
> > 
> > Sorry for the delay in reviewing this patch, I am drowning a bit this
> > week in meetings :)
> > 
> > On Mon, Feb 25, 2019 at 02:39:13PM +, Robin Murphy wrote:
> > > When __drm_atomic_helper_disable_all() tries to commit the disabled
> > > state, we end up in hdlcd_crtc_atomic_check() with a mode clock rate
> > > of 0. If the input clock has a nonzero minimum rate, this fails the
> > > clk_round_rate() check and prevents the CRTC being torn down cleanly.
> > > 
> > > If we're disabling the output, though, then the clock rate should be
> > > pretty much irrelevant, so skip it in that case. The kerneldoc seems
> > > to imply that we probably shouldn't be looking at the rest of the
> > > state anyway if enable=false.
> > > 
> > > Signed-off-by: Robin Murphy 
> > 
> > Acked-by: Liviu Dudau 
> > 
> > 
> > I'll pull your patch into my tree but it will be after v5.1-rc1 that
> > I'll send fixes to airlied.
> > 
> > > ---
> > > 
> > > I'm still occasionally trying to get to the bottom of why the HDLCD on
> > > Juno doesn't work properly with recent upstream EDK2 (the Linux driver
> > > thinks it's initialised and taken over, but the hardware stays stuck
> > > displaying the last contents of the EFI framebuffer). I was hoping that
> > > just unbinding and reprobing the HDLCD/TDA998x drivers might help reset
> > > things hard enough to start working again, but sadly no...
> > 
> > I think both HDLCD and Mali DP drivers misbehave when the bootloader
> > enables the device before the Linux driver probes. I'm interested in
> > sorting this one out and it involves talking to the SMMU as well, so
> > I'll get in touch with you outside this thread to see how I can
> > reproduce your EDK2 environment.
> 
> Well, I've had another quick play and to my great surprise this time I
> actually made things work :)
> 
> After making sense of the finer points of the DRM debug infrastructure, it
> seems that what I was seeing was the HDLCD failing to initialise the CRTC
> but then continuing on anyway with the client in some kind of
> half-configured headless state. And the reason for the CRTC failing is in
> fact this same clk_rate check again - turns out it's got nothing to do with
> EFI per se, but in order to use the EFI display I had to update from SCPI to
> SCMI, and therein lies a critical difference between the respective clock
> drivers. When HDLCD asks for 131MHz, scpi_clk_round_rate() was just saying
> "yeah, whatever" (which is presumably also why we hadn't spotted the disable
> problem before either), whereas scmi_clk_round_rate() is coming back with
> 130.89MHz and thus failing the test.
> 
> I assume that SCMI is telling the truth about the real rate here, so I'm not
> sure what the most appropriate solution is - for now I've just hacked it in
> my tree and will keep that alongside the rest of Sudeep's Juno SCMI patches
> that I'm using lcoally.

Hmm, clk_round_rate() is so confusing! It returns a clock rate "rounded"
to the *exact* value that the hardware supports :)

I'm not sure how much SCMI was lying before vs the amount of hidden tuning
that went into the implementation side in SCP in order to match a lot of
common refresh rates, but I can see that we can probably update the
state->adjusted_mode->clock to the value returned by clk_round_rate()
and not fail. Or accept some small delta vs the requested rate instead
of failing.

If you update state->adjusted_mode->clock to the value returned from
clk_round_rate(), do you see any artefacts in the display?

Best regards,
Liviu

> 
> Robin.
> 
> > 
> > Best regards,
> > Liviu
> > 
> > 
> > > 
> > > Robin.
> > > 
> > >   drivers/gpu/drm/arm/hdlcd_crtc.c | 3 +++
> > >   1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c 
> > > b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > > index e4d67b70244d..30a0d9570b57 100644
> > > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> > > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > > @@ -193,6 +193,9 @@ static int hdlcd_crtc_atomic_check(struct drm_crtc 
> > > *crtc,
> > >   struct drm_display_mode *mode = >adjusted_mode;
> > >   long rate, clk_rate = mode->clock * 1000;
> > > + if (!state->enable)
> > > + return 0;
> > > +
> > >   rate = clk_round_rate(hdlcd->clk, clk_rate);
> > >   if (rate != clk_rate) {
> > >   /* clock required by mode not supported by hardware */
> > > -- 
> > > 2.20.1.dirty
> > > 
> > 

-- 

| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 5/6] dt-bindings: display: sii902x: Add HDMI audio bindings

[Jyri Sarha]

On 17/03/2019 18:16, Laurent Pinchart wrote:
> Hi Jyri,
> 
> Thank you for the patch.
> 
> On Thu, Mar 14, 2019 at 01:27:51PM +0200, Jyri Sarha wrote:
>> The sii902x chip family supports also HDMI audio. Add binding for
>> describing the necessary i2s and mclk wiring for it.
>>
>> Signed-off-by: Jyri Sarha 
>> ---
>>  .../bindings/display/bridge/sii902x.txt   | 33 +++
>>  1 file changed, 33 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt 
>> b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
>> index c4c1855ca654..1a37bbe7c597 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
>> @@ -9,6 +9,33 @@ Optional properties:
>>about hotplug events.
>>  - reset-gpios: OF device-tree gpio specification for RST_N pin.
>>  
>> +HDMI audio properties:
>> +- i2s-data-lanes: Array of up to 4 integers with values of 0-3
>> +   Each integer indicates which i2s pin is connected to which
>> +   audio fifo. The first integer selects i2s audio pin for the
>> +   first audio fifo#0 (HDMI channels 1&2), second for fifo#1
>> +   (HDMI channels 3&4), and so on. There is 4 fifos and 4 i2s
>> +   pins (SD0 - SD3). Any i2s pin can be connected to any fifo,
>> +   but there can be no gaps. E.g. an i2s pin must be mapped to
>> +   fifo#0 and fifo#1 before mapping a channel to fifo#2.
>> +   I2S HDMI audio is configured only if this property is found.
> This looks good to me, but shouldn't the property be defined somewhere
> in Documentation/devicetree/bindings/sound/ ? The sound bindings seem to
> be a bit messy though, with little common or high-level documentation,
> so I don't want to ask you to fix all that :-) Maybe just adding a
> common-i2s.txt file there would be enough ? 
> 
> Apart from this the rest looks good to me, but I'd appreciate if it
> could be reviewed by audio people.
> 
When I think about this property, it hardly is a generic enough to for
all i2s devices or even codecs. That would probably require gaps in the
i2s-data-lane order. I would not want to create common-i2s.txt just for
this property. The is some many other properties that should be added
there first. Maybe this should be made vendor specific property after all.

I think I make a resend with alsa-devel included.

Best regards,
Jyri

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 110184] kernel BUG at drivers/dma-buf/reservation.c:172 (kernel 5.0.2)

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

  Component|DRM/AMDgpu  |DRM/Radeon

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

Re: [RFC][PATCH 2/5 v2] dma-buf: heaps: Add heap helpers

[Brian Starkey]

Hi John,

On Tue, Mar 05, 2019 at 12:54:30PM -0800, John Stultz wrote:

...

> +
> +void dma_heap_buffer_destroy(struct dma_heap_buffer *heap_buffer)
> +{
> + struct heap_helper_buffer *buffer = to_helper_buffer(heap_buffer);
> +
> + if (buffer->kmap_cnt > 0) {
> + pr_warn_once("%s: buffer still mapped in the kernel\n",
> +  __func__);

Could be worth something louder like a full WARN.

> + vunmap(buffer->vaddr);
> + }
> +
> + buffer->free(buffer);
> +}
> +

...

> +
> +static void *dma_heap_dma_buf_kmap(struct dma_buf *dmabuf,
> + unsigned long offset)
> +{
> + struct dma_heap_buffer *heap_buffer = dmabuf->priv;
> + struct heap_helper_buffer *buffer = to_helper_buffer(heap_buffer);
> +
> + return buffer->vaddr + offset * PAGE_SIZE;

I think it'd be good to check for NULL vaddr and return NULL in that
case. Less chance of an invalid pointer being accidentally used then.

Thanks,
-Brian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/fourcc: Fix conflicting Y41x definitions

[Ayan Halder]

On Tue, Mar 19, 2019 at 01:17:02PM +0100, Maarten Lankhorst wrote:
> There has unfortunately been a conflict with the following 3 commits:
> 
> commit e9961ab95af81b8d29054361cd5f0c575102cf87
> Author: Ayan Kumar Halder 
> Date:   Fri Nov 9 17:21:12 2018 +
> drm: Added a new format DRM_FORMAT_XVYU2101010
> 
> commit 7ba0fee247ee7a36b3bfbed68f6988d980aa3aa3
> Author: Brian Starkey 
> Date:   Fri Oct 5 10:27:00 2018 +0100
> 
> drm/fourcc: Add AFBC yuv fourccs for Mali
> 
> and
> 
> commit 50bf5d7d595fd0705ef3785f80e679b6da501e5b
> Author: Swati Sharma 
> Date:   Mon Mar 4 17:26:33 2019 +0530
> 
> drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
> 
> Unfortunately gcc didn't warn about the redefinitions, because the
> 
> Fix this by using new XYVU for i915, without alpha, and making the
> Y41x definitions match msdn, with alpha.
> 
> Fortunately we caught it early, and the conflict hasn't even landed in
> drm-next yet.
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Brian Starkey 
> Cc: Swati Sharma 
> Cc: Ayan Kumar Halder 
> Cc: mal...@foss.arm.com
> Cc: Daniel Vetter 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: Dave Airlie 
> Cc: Liviu Dudau 
> ---
>  drivers/gpu/drm/drm_fourcc.c | 12 +--
>  drivers/gpu/drm/i915/intel_display.c | 18 -
>  drivers/gpu/drm/i915/intel_sprite.c  | 30 ++--
>  include/uapi/drm/drm_fourcc.h| 21 +--
>  4 files changed, 41 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index b914b16db9b2..6ea55fb4526d 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -229,17 +229,17 @@ const struct drm_format_info *__drm_format_info(u32 
> format)
>   { .format = DRM_FORMAT_UYVY,.depth = 0,  
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
>   { .format = DRM_FORMAT_VYUY,.depth = 0,  
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
>   { .format = DRM_FORMAT_XYUV,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> - { .format = DRM_FORMAT_Y210,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
>   { .format = DRM_FORMAT_VUY888,  .depth = 0,  
> .num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> - { .format = DRM_FORMAT_Y410,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true, 
> .is_yuv = true },
>   { .format = DRM_FORMAT_AYUV,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true, 
> .is_yuv = true },
> - { .format = DRM_FORMAT_XVYU2101010, .depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
>   { .format = DRM_FORMAT_Y210,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
>   { .format = DRM_FORMAT_Y212,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
>   { .format = DRM_FORMAT_Y216,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> - { .format = DRM_FORMAT_Y410,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> - { .format = DRM_FORMAT_Y412,.depth = 0,  
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> - { .format = DRM_FORMAT_Y416,.depth = 0,  
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> + { .format = DRM_FORMAT_Y410,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true, 
> .is_yuv = true },
> + { .format = DRM_FORMAT_Y412,.depth = 0,  
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true, 
> .is_yuv = true },
> + { .format = DRM_FORMAT_Y416,.depth = 0,  
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true, 
> .is_yuv = true },
> + { .format = DRM_FORMAT_XVYU2101010, .depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> + { .format = DRM_FORMAT_XVYU12_16161616, .depth = 0,  
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> + { .format = DRM_FORMAT_XVYU16161616,.depth = 0,  
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
>   { .format = DRM_FORMAT_Y0L0,.depth = 0,  
> .num_planes = 1,
> 

[Bug 107731] radeon (amdgpu) DisplayPort loss of max-resolution on DP monitor (after monitor power saving / idle)

[bugzilla-daemon]

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

--- Comment #8 from Harry Wentland  ---
(In reply to L.S.S. from comment #7)

> from what I could find out. Before using a KVM (that I'm swapping between
> its HDMI and DP inputs that were connected to different places), whenever I
> switch the active signal, the built-in USB hub power-cycles (devices
> disconnect then reconnect), and the monitor becomes disconnected to the
> system connected to the now inactive signal.

Are you saying you're using a KVM in your setup?

Does the problem occur when the monitor is directly connected?

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

Re: [PATCH 3/4] drm/amd/display: In VRR mode, do DRM core vblank handling at end of vblank.

[Kazlauskas, Nicholas]

On 3/19/19 9:23 AM, Kazlauskas, Nicholas wrote:
> On 3/18/19 1:19 PM, Mario Kleiner wrote:
>> In VRR mode, proper vblank/pageflip timestamps can only be computed
>> after the display scanout position has left front-porch. Therefore
>> delay calls to drm_crtc_handle_vblank(), and thereby calls to
>> drm_update_vblank_count() and pageflip event delivery, to after the
>> end of front-porch when in VRR mode.
>>
>> We add a new vupdate irq, which triggers at the end of the vupdate
>> interval, ie. at the end of vblank, and calls the core vblank handler
>> function. The new irq handler is not executed in standard non-VRR
>> mode, so vblank handling for fixed refresh rate mode is identical
>> to the past implementation.
>>
>> Signed-off-by: Mario Kleiner 

Looks I lost some of my comments I wanted to send in my last email. Just 
a few nitpicks (including some things Paul mentioned).

Also meant to CC Harry on this as well.

>> ---
>>drivers/gpu/drm/amd/amdgpu/amdgpu.h|   1 +
>>drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 129 
>> -
>>drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h  |   9 ++
>>.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c  |  22 
>>.../amd/display/dc/irq/dce110/irq_service_dce110.c |   7 +-
>>.../amd/display/dc/irq/dce120/irq_service_dce120.c |   7 +-
>>.../amd/display/dc/irq/dce80/irq_service_dce80.c   |   6 +-
>>.../amd/display/dc/irq/dcn10/irq_service_dcn10.c   |  40 +--
>>8 files changed, 205 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> index f88761a..64167dd 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
>> @@ -827,6 +827,7 @@ struct amdgpu_device {
>>  /* For pre-DCE11. DCE11 and later are in "struct amdgpu_device->dm" */
>>  struct work_struct  hotplug_work;
>>  struct amdgpu_irq_src   crtc_irq;
>> +struct amdgpu_irq_src   vupdate_irq;
>>  struct amdgpu_irq_src   pageflip_irq;
>>  struct amdgpu_irq_src   hpd_irq;
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> index 85e4f87..555d9e9f 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>> @@ -315,6 +315,32 @@ static void dm_pflip_high_irq(void *interrupt_params)
>>  drm_crtc_vblank_put(_crtc->base);
>>}
>>
>> +static void dm_vupdate_high_irq(void *interrupt_params)
>> +{
>> +struct common_irq_params *irq_params = interrupt_params;
>> +struct amdgpu_device *adev = irq_params->adev;
>> +struct amdgpu_crtc *acrtc;
>> +struct dm_crtc_state *acrtc_state;
>> +
>> +acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src - 
>> IRQ_TYPE_VUPDATE);
>> +
>> +if (acrtc) {
>> +acrtc_state = to_dm_crtc_state(acrtc->base.state);
>> +
>> +DRM_DEBUG_DRIVER("crtc:%d, vupdate-vrr:%d\n", acrtc->crtc_id,
>> + amdgpu_dm_vrr_active(acrtc_state));
>> +
>> +/* Core vblank handling is done here after end of front-porch in
>> + * vrr mode, as vblank timestamping will give valid results
>> + * while now done after front-porch. This will also deliver
>> + * page-flip completion events that have been queued to us
>> + * if a pageflip happened inside front-porch.
>> + */
>> +if (amdgpu_dm_vrr_active(acrtc_state))
>> +drm_crtc_handle_vblank(>base)
> I was thinking that 3 and 4 might have to be merged, but VRR pflip
> timestamping seems to be the same as it was before (off by a line or
> two) since it's not handled here yet. This seems to fix vblank events
> and timestamping at least.
> 
>> +}
>> +}
>> +
>>static void dm_crtc_high_irq(void *interrupt_params)
>>{
>>  struct common_irq_params *irq_params = interrupt_params;
>> @@ -325,11 +351,24 @@ static void dm_crtc_high_irq(void *interrupt_params)
>>  acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src - 
>> IRQ_TYPE_VBLANK);
>>
>>  if (acrtc) {
>> -drm_crtc_handle_vblank(>base);
>> -amdgpu_dm_crtc_handle_crc_irq(>base);
>> -
>>  acrtc_state = to_dm_crtc_state(acrtc->base.state);
>>
>> +DRM_DEBUG_DRIVER("crtc:%d, vupdate-vrr:%d\n", acrtc->crtc_id,
>> + amdgpu_dm_vrr_active(acrtc_state));
>> +
>> +/* Core vblank handling at start of front-porch is only possible
>> + * in non-vrr mode, as only there vblank timestamping will give
>> + * valid results while done in front-porch. Otherwise defer it
>> + * to dm_vupdate_high_irq after end of front-porch.
>> + */
>> +if (!amdgpu_dm_vrr_active(acrtc_state))
>> + 

[PATCH] ARM: dts: exynos: Increase minimal ACLK400_DISP1 frequency on Exynos542x

[Marek Szyprowski]

ACLK400_DISP1 bus feeds some internal buses of the display subsystem, some
of which are also related to TV/Mixer hardware modules. When that bus
is set to 120MHz, Exynos Mixer is not able to properly handle two XRGB
display planes at FullHD-60MHz. DMA underrun happens, which in turn might
result in reading data out of the configured buffer, what causes IOMMU
page fault and kernel panic.

This change fixes the following IOMMU fault, observed, when 2 Mixer planes
were enabled:

exynos-sysmmu 1465.sysmmu: 1445.mixer: PAGE FAULT occurred at 0x20fe9000
[ cut here ]
kernel BUG at ../drivers/iommu/exynos-iommu.c:450!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 5 PID: 0 Comm: swapper/5 Not tainted 5.0.0-3-g1b03088168ea #149
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
PC is at exynos_sysmmu_irq+0x1c0/0x264
LR is at lock_is_held_type+0x44/0x64
...

Reported-by: Marian Mihailescu 
Fixes: 5d99cc59a3c6 ("ARM: dts: exynos: Move Exynos5250 and Exynos5420 nodes 
under soc")
Fixes: b04a62d3ade3 ("ARM: dts: exynos: Add bus nodes using VDD_INT for 
Exynos542x SoC")
Signed-off-by: Marek Szyprowski 
---
 arch/arm/boot/dts/exynos5420.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index aaff15880761..250f4d7182e0 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -1294,7 +1294,7 @@
compatible = "operating-points-v2";
 
opp00 {
-   opp-hz = /bits/ 64 <12000>;
+   opp-hz = /bits/ 64 <15000>;
};
opp01 {
opp-hz = /bits/ 64 <2>;
-- 
2.17.1

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

Re: [PATCH 3/4] drm/amd/display: In VRR mode, do DRM core vblank handling at end of vblank.

[Kazlauskas, Nicholas]

On 3/18/19 1:19 PM, Mario Kleiner wrote:
> In VRR mode, proper vblank/pageflip timestamps can only be computed
> after the display scanout position has left front-porch. Therefore
> delay calls to drm_crtc_handle_vblank(), and thereby calls to
> drm_update_vblank_count() and pageflip event delivery, to after the
> end of front-porch when in VRR mode.
> 
> We add a new vupdate irq, which triggers at the end of the vupdate
> interval, ie. at the end of vblank, and calls the core vblank handler
> function. The new irq handler is not executed in standard non-VRR
> mode, so vblank handling for fixed refresh rate mode is identical
> to the past implementation.
> 
> Signed-off-by: Mario Kleiner 
> ---
>   drivers/gpu/drm/amd/amdgpu/amdgpu.h|   1 +
>   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 129 
> -
>   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h  |   9 ++
>   .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c  |  22 
>   .../amd/display/dc/irq/dce110/irq_service_dce110.c |   7 +-
>   .../amd/display/dc/irq/dce120/irq_service_dce120.c |   7 +-
>   .../amd/display/dc/irq/dce80/irq_service_dce80.c   |   6 +-
>   .../amd/display/dc/irq/dcn10/irq_service_dcn10.c   |  40 +--
>   8 files changed, 205 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> index f88761a..64167dd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> @@ -827,6 +827,7 @@ struct amdgpu_device {
>   /* For pre-DCE11. DCE11 and later are in "struct amdgpu_device->dm" */
>   struct work_struct  hotplug_work;
>   struct amdgpu_irq_src   crtc_irq;
> + struct amdgpu_irq_src   vupdate_irq;
>   struct amdgpu_irq_src   pageflip_irq;
>   struct amdgpu_irq_src   hpd_irq;
>   
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 85e4f87..555d9e9f 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -315,6 +315,32 @@ static void dm_pflip_high_irq(void *interrupt_params)
>   drm_crtc_vblank_put(_crtc->base);
>   }
>   
> +static void dm_vupdate_high_irq(void *interrupt_params)
> +{
> + struct common_irq_params *irq_params = interrupt_params;
> + struct amdgpu_device *adev = irq_params->adev;
> + struct amdgpu_crtc *acrtc;
> + struct dm_crtc_state *acrtc_state;
> +
> + acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src - 
> IRQ_TYPE_VUPDATE);
> +
> + if (acrtc) {
> + acrtc_state = to_dm_crtc_state(acrtc->base.state);
> +
> + DRM_DEBUG_DRIVER("crtc:%d, vupdate-vrr:%d\n", acrtc->crtc_id,
> +  amdgpu_dm_vrr_active(acrtc_state));
> +
> + /* Core vblank handling is done here after end of front-porch in
> +  * vrr mode, as vblank timestamping will give valid results
> +  * while now done after front-porch. This will also deliver
> +  * page-flip completion events that have been queued to us
> +  * if a pageflip happened inside front-porch.
> +  */
> + if (amdgpu_dm_vrr_active(acrtc_state))
> + drm_crtc_handle_vblank(>base)
I was thinking that 3 and 4 might have to be merged, but VRR pflip 
timestamping seems to be the same as it was before (off by a line or 
two) since it's not handled here yet. This seems to fix vblank events 
and timestamping at least.

> + }
> +}
> +
>   static void dm_crtc_high_irq(void *interrupt_params)
>   {
>   struct common_irq_params *irq_params = interrupt_params;
> @@ -325,11 +351,24 @@ static void dm_crtc_high_irq(void *interrupt_params)
>   acrtc = get_crtc_by_otg_inst(adev, irq_params->irq_src - 
> IRQ_TYPE_VBLANK);
>   
>   if (acrtc) {
> - drm_crtc_handle_vblank(>base);
> - amdgpu_dm_crtc_handle_crc_irq(>base);
> -
>   acrtc_state = to_dm_crtc_state(acrtc->base.state);
>   
> + DRM_DEBUG_DRIVER("crtc:%d, vupdate-vrr:%d\n", acrtc->crtc_id,
> +  amdgpu_dm_vrr_active(acrtc_state));
> +
> + /* Core vblank handling at start of front-porch is only possible
> +  * in non-vrr mode, as only there vblank timestamping will give
> +  * valid results while done in front-porch. Otherwise defer it
> +  * to dm_vupdate_high_irq after end of front-porch.
> +  */
> + if (!amdgpu_dm_vrr_active(acrtc_state))
> + drm_crtc_handle_vblank(>base);
> +
> + /* Following stuff must happen at start of vblank, for crc
> +  * computation and below-the-range btr support in vrr mode.
> +  */
> + amdgpu_dm_crtc_handle_crc_irq(>base);
> +
>   if 

Re: [PATCH] drm: hdlcd: Stop failing atomic disable check

[Robin Murphy]

[ +Sudeep - just FYI ]

Hi Liviu,

On 27/02/2019 09:40, Liviu Dudau wrote:

Hi Robin,

Sorry for the delay in reviewing this patch, I am drowning a bit this
week in meetings :)

On Mon, Feb 25, 2019 at 02:39:13PM +, Robin Murphy wrote:

When __drm_atomic_helper_disable_all() tries to commit the disabled
state, we end up in hdlcd_crtc_atomic_check() with a mode clock rate
of 0. If the input clock has a nonzero minimum rate, this fails the
clk_round_rate() check and prevents the CRTC being torn down cleanly.

If we're disabling the output, though, then the clock rate should be
pretty much irrelevant, so skip it in that case. The kerneldoc seems
to imply that we probably shouldn't be looking at the rest of the
state anyway if enable=false.

Signed-off-by: Robin Murphy 


Acked-by: Liviu Dudau 


I'll pull your patch into my tree but it will be after v5.1-rc1 that
I'll send fixes to airlied.


---

I'm still occasionally trying to get to the bottom of why the HDLCD on
Juno doesn't work properly with recent upstream EDK2 (the Linux driver
thinks it's initialised and taken over, but the hardware stays stuck
displaying the last contents of the EFI framebuffer). I was hoping that
just unbinding and reprobing the HDLCD/TDA998x drivers might help reset
things hard enough to start working again, but sadly no...


I think both HDLCD and Mali DP drivers misbehave when the bootloader
enables the device before the Linux driver probes. I'm interested in
sorting this one out and it involves talking to the SMMU as well, so
I'll get in touch with you outside this thread to see how I can
reproduce your EDK2 environment.


Well, I've had another quick play and to my great surprise this time I 
actually made things work :)


After making sense of the finer points of the DRM debug infrastructure, 
it seems that what I was seeing was the HDLCD failing to initialise the 
CRTC but then continuing on anyway with the client in some kind of 
half-configured headless state. And the reason for the CRTC failing is 
in fact this same clk_rate check again - turns out it's got nothing to 
do with EFI per se, but in order to use the EFI display I had to update 
from SCPI to SCMI, and therein lies a critical difference between the 
respective clock drivers. When HDLCD asks for 131MHz, 
scpi_clk_round_rate() was just saying "yeah, whatever" (which is 
presumably also why we hadn't spotted the disable problem before 
either), whereas scmi_clk_round_rate() is coming back with 130.89MHz and 
thus failing the test.


I assume that SCMI is telling the truth about the real rate here, so I'm 
not sure what the most appropriate solution is - for now I've just 
hacked it in my tree and will keep that alongside the rest of Sudeep's 
Juno SCMI patches that I'm using lcoally.


Robin.



Best regards,
Liviu




Robin.

  drivers/gpu/drm/arm/hdlcd_crtc.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index e4d67b70244d..30a0d9570b57 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -193,6 +193,9 @@ static int hdlcd_crtc_atomic_check(struct drm_crtc *crtc,
struct drm_display_mode *mode = >adjusted_mode;
long rate, clk_rate = mode->clock * 1000;
  
+	if (!state->enable)

+   return 0;
+
rate = clk_round_rate(hdlcd->clk, clk_rate);
if (rate != clk_rate) {
/* clock required by mode not supported by hardware */
--
2.20.1.dirty




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

Re: [PATCH 4/4] drm/amd/display: Make pageflip event delivery compatible with VRR.

[Kazlauskas, Nicholas]

On 3/18/19 1:19 PM, Mario Kleiner wrote:
> We want vblank counts and timestamps of flip completion as sent
> in pageflip completion events to be consistent with the vblank
> count and timestamp of the vblank of flip completion, like in non
> VRR mode.
> 
> In VRR mode, drm_update_vblank_count() - and thereby vblank
> count and timestamp updates - must be delayed until after the
> end of front-porch of each vblank, as it is only safe to
> calculate vblank timestamps outside of the front-porch, when
> we actually know when the vblank will end or has ended.
> 
> The function drm_update_vblank_count() which updates timestamps
> and counts gets called by drm_crtc_accurate_vblank_count() or by
> drm_crtc_handle_vblank().
> 
> Therefore we must make sure that pageflip events for a completed
> flip are only sent out after drm_crtc_accurate_vblank_count() or
> drm_crtc_handle_vblank() is executed, after end of front-porch
> for the vblank of flip completion.
> 
> Two cases:
> 
> a) Pageflip irq handler executes inside front-porch:
> In this case we must defer sending pageflip events until
> drm_crtc_handle_vblank() executes after end of front-porch,
> and thereby calculates proper vblank count and timestamp.
> Iow. the pflip irq handler must just arm a pageflip event
> to be sent out by drm_crtc_handle_vblank() later on.
> 
> b) Pageflip irq handler executes after end of front-porch, e.g.,
> after flip completion in back-porch or due to a massively
> delayed handler invocation into the active scanout of the new
> frame. In this case we can call drm_crtc_accurate_vblank_count()
> to safely force calculation of a proper vblank count and
> timestamp, and must send the pageflip completion event
> ourselves from the pageflip irq handler.
> 
> This is the same behaviour as needed for standard fixed refresh
> rate mode.
> 
> To decide from within pageflip handler if we are in case a) or b),
> we check the current scanout position against the boundary of
> front-porch. In non-VRR mode we just do what we did in the past.
> 
> Signed-off-by: Mario Kleiner 

Reviewed-by: Nicholas Kazlauskas 

This patch looks fine to me for the most part, but it's still pending on 
the other patches in the series.

> ---
>   drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 68 
> ++-
>   1 file changed, 55 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 555d9e9f..499284d 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -263,6 +263,10 @@ static void dm_pflip_high_irq(void *interrupt_params)
>   struct common_irq_params *irq_params = interrupt_params;
>   struct amdgpu_device *adev = irq_params->adev;
>   unsigned long flags;
> + struct drm_pending_vblank_event *e;
> + struct dm_crtc_state *acrtc_state;
> + uint32_t vpos, hpos, v_blank_start, v_blank_end;
> + bool vrr_active;
>   
>   amdgpu_crtc = get_crtc_by_otg_inst(adev, irq_params->irq_src - 
> IRQ_TYPE_PFLIP);
>   
> @@ -285,18 +289,57 @@ static void dm_pflip_high_irq(void *interrupt_params)
>   return;
>   }
>   
> - /* Update to correct count(s) if racing with vblank irq */
> - drm_crtc_accurate_vblank_count(_crtc->base);
> + /* page flip completed. */
> + e = amdgpu_crtc->event;
> + amdgpu_crtc->event = NULL;
>   
> - /* wake up userspace */
> - if (amdgpu_crtc->event) {
> - drm_crtc_send_vblank_event(_crtc->base, 
> amdgpu_crtc->event);
> + if (!e)
> + WARN_ON(1);
>   
> - /* page flip completed. clean up */
> - amdgpu_crtc->event = NULL;
> + acrtc_state = to_dm_crtc_state(amdgpu_crtc->base.state);
> + vrr_active = amdgpu_dm_vrr_active(acrtc_state);
> +
> + /* Fixed refresh rate, or VRR scanout position outside front-porch? */
> + if (!vrr_active ||
> + !dc_stream_get_scanoutpos(acrtc_state->stream, _blank_start,
> +   _blank_end, , ) ||
> + (vpos < v_blank_start)) {
> + /* Update to correct count and vblank timestamp if racing with
> +  * vblank irq. This also updates to the correct vblank timestamp
> +  * even in VRR mode, as scanout is past the front-porch atm.
> +  */
> + drm_crtc_accurate_vblank_count(_crtc->base);
>   
> - } else
> - WARN_ON(1);
> + /* Wake up userspace by sending the pageflip event with proper
> +  * count and timestamp of vblank of flip completion.
> +  */
> + if (e) {
> + drm_crtc_send_vblank_event(_crtc->base, e);
> +
> + /* Event sent, so done with vblank for this flip */
> + drm_crtc_vblank_put(_crtc->base);
> + 

[PATCH v2] drm/exynos/mixer: fix MIXER shadow registry synchronisation code

[Andrzej Hajda]

MIXER on Exynos5 SoCs uses different synchronisation method than Exynos4
to update internal state (shadow registers).
Apparently the driver implements it incorrectly. The rule should be
as follows:
- do not request updating registers until previous request was finished,
  ie. MXR_CFG_LAYER_UPDATE_COUNT must be 0.
- before setting registers synchronisation on VSYNC should be turned off,
  ie. MXR_STATUS_SYNC_ENABLE should be reset,
- after finishing MXR_STATUS_SYNC_ENABLE should be set again.
The patch hopefully implements it correctly.
Below sample kernel log from page fault caused by the bug:

[   25.670038] exynos-sysmmu 1465.sysmmu: 1445.mixer: PAGE FAULT 
occurred at 0x2247b800
[   25.677888] [ cut here ]
[   25.682164] kernel BUG at ../drivers/iommu/exynos-iommu.c:450!
[   25.687971] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[   25.693778] Modules linked in:
[   25.696816] CPU: 5 PID: 1553 Comm: fb-release_test Not tainted 
5.0.0-rc7-01157-g5f86b1566bdd #136
[   25.705646] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   25.711710] PC is at exynos_sysmmu_irq+0x1c0/0x264
[   25.716470] LR is at lock_is_held_type+0x44/0x64

v2: added missing MXR_CFG_LAYER_UPDATE bit setting in mixer_enable_sync

Reported-by: Marian Mihailescu 
Signed-off-by: Andrzej Hajda 
---
Hi Inki and Marian,

This is fixed version of my previous patch. The only difference is
added missing MXR_CFG_LAYER_UPDATE setting in mixer_enable_sync.
I hope this time it is correct. It should solve one page fault issue
in MIXER, Marek is preparing fix for another issue (to low clock set by
devfreq). I hope with both patches page faults will not happen anymore ;)

Regards
Andrzej
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 110 +++---
 1 file changed, 66 insertions(+), 44 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 0573eab0e190..f35e4ab55b27 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -20,6 +20,7 @@
 #include "regs-vp.h"
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -352,15 +353,62 @@ static void mixer_cfg_vp_blend(struct mixer_context *ctx, 
unsigned int alpha)
mixer_reg_write(ctx, MXR_VIDEO_CFG, val);
 }
 
-static void mixer_vsync_set_update(struct mixer_context *ctx, bool enable)
+static bool mixer_is_synced(struct mixer_context *ctx)
 {
-   /* block update on vsync */
-   mixer_reg_writemask(ctx, MXR_STATUS, enable ?
-   MXR_STATUS_SYNC_ENABLE : 0, MXR_STATUS_SYNC_ENABLE);
+   u32 base, shadow;
 
+   if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
+   ctx->mxr_ver == MXR_VER_128_0_0_184)
+   return !(mixer_reg_read(ctx, MXR_CFG) &
+MXR_CFG_LAYER_UPDATE_COUNT_MASK);
+
+   if (test_bit(MXR_BIT_VP_ENABLED, >flags) &&
+   vp_reg_read(ctx, VP_SHADOW_UPDATE))
+   return false;
+
+   base = mixer_reg_read(ctx, MXR_CFG);
+   shadow = mixer_reg_read(ctx, MXR_CFG_S);
+   if (base != shadow)
+   return false;
+
+   base = mixer_reg_read(ctx, MXR_GRAPHIC_BASE(0));
+   shadow = mixer_reg_read(ctx, MXR_GRAPHIC_BASE_S(0));
+   if (base != shadow)
+   return false;
+
+   base = mixer_reg_read(ctx, MXR_GRAPHIC_BASE(1));
+   shadow = mixer_reg_read(ctx, MXR_GRAPHIC_BASE_S(1));
+   if (base != shadow)
+   return false;
+
+   return true;
+}
+
+static int mixer_wait_for_sync(struct mixer_context *ctx)
+{
+   ktime_t timeout = ktime_add_us(ktime_get(), 10);
+
+   while (!mixer_is_synced(ctx)) {
+   usleep_range(1000, 2000);
+   if (ktime_compare(ktime_get(), timeout) > 0)
+   return -ETIMEDOUT;
+   }
+   return 0;
+}
+
+static void mixer_disable_sync(struct mixer_context *ctx)
+{
+   mixer_reg_writemask(ctx, MXR_STATUS, 0, MXR_STATUS_SYNC_ENABLE);
+}
+
+static void mixer_enable_sync(struct mixer_context *ctx)
+{
+   if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
+   ctx->mxr_ver == MXR_VER_128_0_0_184)
+   mixer_reg_writemask(ctx, MXR_CFG, ~0, MXR_CFG_LAYER_UPDATE);
+   mixer_reg_writemask(ctx, MXR_STATUS, ~0, MXR_STATUS_SYNC_ENABLE);
if (test_bit(MXR_BIT_VP_ENABLED, >flags))
-   vp_reg_write(ctx, VP_SHADOW_UPDATE, enable ?
-   VP_SHADOW_UPDATE_ENABLE : 0);
+   vp_reg_write(ctx, VP_SHADOW_UPDATE, VP_SHADOW_UPDATE_ENABLE);
 }
 
 static void mixer_cfg_scan(struct mixer_context *ctx, int width, int height)
@@ -498,7 +546,6 @@ static void vp_video_buffer(struct mixer_context *ctx,
 
spin_lock_irqsave(>reg_slock, flags);
 
-   vp_reg_write(ctx, VP_SHADOW_UPDATE, 1);
/* interlace or progressive scan mode */
val = (test_bit(MXR_BIT_INTERLACE, >flags) ? ~0 : 0);
vp_reg_writemask(ctx, VP_MODE, val, 

Re: [PATCH] drm/fourcc: Fix conflicting Y41x definitions

[Ville Syrjälä]

On Tue, Mar 19, 2019 at 01:17:02PM +0100, Maarten Lankhorst wrote:
> There has unfortunately been a conflict with the following 3 commits:
> 
> commit e9961ab95af81b8d29054361cd5f0c575102cf87
> Author: Ayan Kumar Halder 
> Date:   Fri Nov 9 17:21:12 2018 +
> drm: Added a new format DRM_FORMAT_XVYU2101010
> 
> commit 7ba0fee247ee7a36b3bfbed68f6988d980aa3aa3
> Author: Brian Starkey 
> Date:   Fri Oct 5 10:27:00 2018 +0100
> 
> drm/fourcc: Add AFBC yuv fourccs for Mali
> 
> and
> 
> commit 50bf5d7d595fd0705ef3785f80e679b6da501e5b
> Author: Swati Sharma 
> Date:   Mon Mar 4 17:26:33 2019 +0530
> 
> drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc
> 
> Unfortunately gcc didn't warn about the redefinitions, because the
> 
> Fix this by using new XYVU for i915, without alpha, and making the
> Y41x definitions match msdn, with alpha.

The naming of all these is rather unfortunate because now the alpha vs.
non-alpha formats have totally different looking names :( Fourccs are
stupid!

> 
> Fortunately we caught it early, and the conflict hasn't even landed in
> drm-next yet.
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Brian Starkey 
> Cc: Swati Sharma 
> Cc: Ayan Kumar Halder 
> Cc: mal...@foss.arm.com
> Cc: Daniel Vetter 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: Dave Airlie 
> Cc: Liviu Dudau 
> ---
>  drivers/gpu/drm/drm_fourcc.c | 12 +--
>  drivers/gpu/drm/i915/intel_display.c | 18 -
>  drivers/gpu/drm/i915/intel_sprite.c  | 30 ++--
>  include/uapi/drm/drm_fourcc.h| 21 +--
>  4 files changed, 41 insertions(+), 40 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index b914b16db9b2..6ea55fb4526d 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -229,17 +229,17 @@ const struct drm_format_info *__drm_format_info(u32 
> format)
>   { .format = DRM_FORMAT_UYVY,.depth = 0,  
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
>   { .format = DRM_FORMAT_VYUY,.depth = 0,  
> .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
>   { .format = DRM_FORMAT_XYUV,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> - { .format = DRM_FORMAT_Y210,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
>   { .format = DRM_FORMAT_VUY888,  .depth = 0,  
> .num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> - { .format = DRM_FORMAT_Y410,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true, 
> .is_yuv = true },
>   { .format = DRM_FORMAT_AYUV,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true, 
> .is_yuv = true },
> - { .format = DRM_FORMAT_XVYU2101010, .depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
>   { .format = DRM_FORMAT_Y210,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
>   { .format = DRM_FORMAT_Y212,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
>   { .format = DRM_FORMAT_Y216,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
> - { .format = DRM_FORMAT_Y410,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> - { .format = DRM_FORMAT_Y412,.depth = 0,  
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> - { .format = DRM_FORMAT_Y416,.depth = 0,  
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> + { .format = DRM_FORMAT_Y410,.depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true, 
> .is_yuv = true },
> + { .format = DRM_FORMAT_Y412,.depth = 0,  
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true, 
> .is_yuv = true },
> + { .format = DRM_FORMAT_Y416,.depth = 0,  
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true, 
> .is_yuv = true },
> + { .format = DRM_FORMAT_XVYU2101010, .depth = 0,  
> .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
> + { .format = DRM_FORMAT_XVYU12_16161616, .depth = 0,  
> .num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },

Damn these 10/12 in 16 formats are annoying. 

Maybe it would look nicer to put the 12 at the end?

> +  

Re: [PATCH] drm/sun4i: hdmi: add support for ddc-i2c-bus property

[Maxime Ripard]

On Mon, Mar 18, 2019 at 04:23:56PM +, Måns Rullgård wrote:
> Maxime Ripard  writes:
>
> > On Thu, Mar 14, 2019 at 04:09:13PM +, Måns Rullgård wrote:
> >> Maxime Ripard  writes:
> >>
> >> > On Mon, Mar 11, 2019 at 04:11:06PM +, Måns Rullgård wrote:
> >> >> Maxime Ripard  writes:
> >> >>
> >> >> > Hi!
> >> >> >
> >> >> > On Mon, Mar 11, 2019 at 01:47:13PM +, Mans Rullgard wrote:
> >> >> >> Sometimes it is desirabled to use a separate i2c controller for ddc
> >> >> >> access.  This adds support for the ddc-i2c-bus property of the
> >> >> >> hdmi-connector node, using the specified controller if provided.
> >> >> >>
> >> >> >> Signed-off-by: Mans Rullgard 
> >> >> >> ---
> >> >> >>  drivers/gpu/drm/sun4i/sun4i_hdmi.h |  1 +
> >> >> >>  drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 37 
> >> >> >> +++---
> >> >> >>  2 files changed, 35 insertions(+), 3 deletions(-)
> >> >> >>
> >> >> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h 
> >> >> >> b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> >> >> >> index b685ee11623d..b08c4453d47c 100644
> >> >> >> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> >> >> >> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> >> >> >> @@ -269,6 +269,7 @@ struct sun4i_hdmi {
> >> >> >>  struct clk  *tmds_clk;
> >> >> >>
> >> >> >>  struct i2c_adapter  *i2c;
> >> >> >> +struct i2c_adapter  *ddc_i2c;
> >> >> >>
> >> >> >>  /* Regmap fields for I2C adapter */
> >> >> >>  struct regmap_field *field_ddc_en;
> >> >> >> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c 
> >> >> >> b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> >> >> >> index 061d2e0d9011..5b2fac79f5d6 100644
> >> >> >> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> >> >> >> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> >> >> >> @@ -212,7 +212,7 @@ static int sun4i_hdmi_get_modes(struct 
> >> >> >> drm_connector *connector)
> >> >> >>  struct edid *edid;
> >> >> >>  int ret;
> >> >> >>
> >> >> >> -edid = drm_get_edid(connector, hdmi->i2c);
> >> >> >> +edid = drm_get_edid(connector, hdmi->ddc_i2c ?: hdmi->i2c);
> >> >> >
> >> >> > You can't test whether ddc_i2c is NULL or not...
> >> >> >
> >> >> >>  if (!edid)
> >> >> >>  return 0;
> >> >> >>
> >> >> >> @@ -228,6 +228,28 @@ static int sun4i_hdmi_get_modes(struct 
> >> >> >> drm_connector *connector)
> >> >> >>  return ret;
> >> >> >>  }
> >> >> >>
> >> >> >> +static struct i2c_adapter *sun4i_hdmi_get_ddc(struct device *dev)
> >> >> >> +{
> >> >> >> +struct device_node *phandle, *remote;
> >> >> >> +struct i2c_adapter *ddc;
> >> >> >> +
> >> >> >> +remote = of_graph_get_remote_node(dev->of_node, 1, -1);
> >> >> >> +if (!remote)
> >> >> >> +return ERR_PTR(-EINVAL);
> >> >> >> +
> >> >> >> +phandle = of_parse_phandle(remote, "ddc-i2c-bus", 0);
> >> >> >> +of_node_put(remote);
> >> >> >> +if (!phandle)
> >> >> >> +return NULL;
> >> >> >> +
> >> >> >> +ddc = of_get_i2c_adapter_by_node(phandle);
> >> >> >> +of_node_put(phandle);
> >> >> >> +if (!ddc)
> >> >> >> +return ERR_PTR(-EPROBE_DEFER);
> >> >> >> +
> >> >> >> +return ddc;
> >> >> >
> >> >> > ... Since even in (most) error cases you're returning a !NULL pointer.
> >> >> >
> >> >> >> +}
> >> >> >> +
> >> >> >>  static const struct drm_connector_helper_funcs 
> >> >> >> sun4i_hdmi_connector_helper_funcs = {
> >> >> >>  .get_modes  = sun4i_hdmi_get_modes,
> >> >> >>  };
> >> >> >> @@ -575,6 +597,12 @@ static int sun4i_hdmi_bind(struct device *dev, 
> >> >> >> struct device *master,
> >> >> >>  goto err_disable_mod_clk;
> >> >> >>  }
> >> >> >>
> >> >> >> +hdmi->ddc_i2c = sun4i_hdmi_get_ddc(dev);
> >> >> >> +if (IS_ERR(hdmi->ddc_i2c)) {
> >> >>
> >> >> ... which is checked here.
> >> >>
> >> >> The property is optional, so the idea was to return null in that case
> >> >> and use the built-in controller.  If the property exists but some error
> >> >> occurs, we want to abort rather than proceed with the fallback which
> >> >> almost certainly won't work.
> >> >>
> >> >> Maybe I got something wrong in that logic.
> >> >
> >> > Indeed, I just got confused. I guess returning ENODEV in such a case,
> >> > and testing for that, would make things more obvious.
> >>
> >> There's also a case I hadn't thought of: property exists but isn't a
> >> valid phandle.  What do you think is the correct action in that case?
> >
> > I think we would have that one covered. of_parse_phandle will return
> > !NULL, but then of_get_i2c_adapter_by_node will return NULL since we
> > wouldn't have an associated i2c adapter to the bogus phandle, and you
> > are checking for that already.
>
> of_parse_phandle() doesn't differentiate between a missing property and
> an existing non-phandle value.  The following cases are possible with
> this patch:
>
> - ddc-i2c-bus points to valid i2c controller node: use this for ddc
> - no ddc-i2c-bus property: return 

Re: [PATCH 1/9] dma-buf: add new dma_fence_chain container v5

[Christian König]

Am 19.03.19 um 13:27 schrieb Lionel Landwerlin:

On 15/03/2019 12:09, Chunming Zhou wrote:

[SNIP]
+/**
+ * struct dma_fence_chain - fence to represent an node of a fence chain
+ * @base: fence base class
+ * @lock: spinlock for fence handling
+ * @prev: previous fence of the chain
+ * @prev_seqno: original previous seqno before garbage collection
+ * @fence: encapsulated fence
+ * @cb: callback structure for signaling
+ * @work: irq work item for signaling
+ */
+struct dma_fence_chain {
+    struct dma_fence base;
+    spinlock_t lock;
+    struct dma_fence *prev;



Not an expert on the rcu thing, but drm_syncobj has a __rcu on its 
fence field.


Should this be? :


struct dma_fence __rcu *prev;


Yeah, the kbuild robot has already complained about this as well.

Needs to be fixed before pushed, but its only a minor change.

Christian.





+    u64 prev_seqno;
+    struct dma_fence *fence;
+    struct dma_fence_cb cb;
+    struct irq_work work;
+};
+
+extern const struct dma_fence_ops dma_fence_chain_ops;
+
+/**
+ * to_dma_fence_chain - cast a fence to a dma_fence_chain
+ * @fence: fence to cast to a dma_fence_array
+ *
+ * Returns NULL if the fence is not a dma_fence_chain,
+ * or the dma_fence_chain otherwise.
+ */
+static inline struct dma_fence_chain *
+to_dma_fence_chain(struct dma_fence *fence)
+{
+    if (!fence || fence->ops != _fence_chain_ops)
+    return NULL;
+
+    return container_of(fence, struct dma_fence_chain, base);
+}
+
+/**
+ * dma_fence_chain_for_each - iterate over all fences in chain
+ * @iter: current fence
+ * @head: starting point
+ *
+ * Iterate over all fences in the chain. We keep a reference to the 
current

+ * fence while inside the loop which must be dropped when breaking out.
+ */
+#define dma_fence_chain_for_each(iter, head)    \
+    for (iter = dma_fence_get(head); iter; \
+ iter = dma_fence_chain_walk(iter))
+
+struct dma_fence *dma_fence_chain_walk(struct dma_fence *fence);
+int dma_fence_chain_find_seqno(struct dma_fence **pfence, uint64_t 
seqno);

+void dma_fence_chain_init(struct dma_fence_chain *chain,
+  struct dma_fence *prev,
+  struct dma_fence *fence,
+  uint64_t seqno);
+
+#endif /* __LINUX_DMA_FENCE_CHAIN_H */





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

Re: [PATCH 1/9] dma-buf: add new dma_fence_chain container v5

[Lionel Landwerlin]

On 15/03/2019 12:09, Chunming Zhou wrote:

From: Christian König 

Lockless container implementation similar to a dma_fence_array, but with
only two elements per node and automatic garbage collection.

v2: properly document dma_fence_chain_for_each, add dma_fence_chain_find_seqno,
 drop prev reference during garbage collection if it's not a chain fence.
v3: use head and iterator for dma_fence_chain_for_each
v4: fix reference count in dma_fence_chain_enable_signaling
v5: fix iteration when walking each chain node

Signed-off-by: Christian König 
---
  drivers/dma-buf/Makefile  |   3 +-
  drivers/dma-buf/dma-fence-chain.c | 241 ++
  include/linux/dma-fence-chain.h   |  81 ++
  3 files changed, 324 insertions(+), 1 deletion(-)
  create mode 100644 drivers/dma-buf/dma-fence-chain.c
  create mode 100644 include/linux/dma-fence-chain.h

diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 0913a6ccab5a..1f006e083eb9 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1,4 +1,5 @@
-obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o
+obj-y := dma-buf.o dma-fence.o dma-fence-array.o dma-fence-chain.o \
+reservation.o seqno-fence.o
  obj-$(CONFIG_SYNC_FILE)   += sync_file.o
  obj-$(CONFIG_SW_SYNC) += sw_sync.o sync_debug.o
  obj-$(CONFIG_UDMABUF) += udmabuf.o
diff --git a/drivers/dma-buf/dma-fence-chain.c 
b/drivers/dma-buf/dma-fence-chain.c
new file mode 100644
index ..0c5e3c902fa0
--- /dev/null
+++ b/drivers/dma-buf/dma-fence-chain.c
@@ -0,0 +1,241 @@
+/*
+ * fence-chain: chain fences together in a timeline
+ *
+ * Copyright (C) 2018 Advanced Micro Devices, Inc.
+ * Authors:
+ * Christian König 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ */
+
+#include 
+
+static bool dma_fence_chain_enable_signaling(struct dma_fence *fence);
+
+/**
+ * dma_fence_chain_get_prev - use RCU to get a reference to the previous fence
+ * @chain: chain node to get the previous node from
+ *
+ * Use dma_fence_get_rcu_safe to get a reference to the previous fence of the
+ * chain node.
+ */
+static struct dma_fence *dma_fence_chain_get_prev(struct dma_fence_chain 
*chain)
+{
+   struct dma_fence *prev;
+
+   rcu_read_lock();
+   prev = dma_fence_get_rcu_safe(>prev);
+   rcu_read_unlock();
+   return prev;
+}
+
+/**
+ * dma_fence_chain_walk - chain walking function
+ * @fence: current chain node
+ *
+ * Walk the chain to the next node. Returns the next fence or NULL if we are at
+ * the end of the chain. Garbage collects chain nodes which are already
+ * signaled.
+ */
+struct dma_fence *dma_fence_chain_walk(struct dma_fence *fence)
+{
+   struct dma_fence_chain *chain, *prev_chain;
+   struct dma_fence *prev, *replacement, *tmp;
+
+   chain = to_dma_fence_chain(fence);
+   if (!chain) {
+   dma_fence_put(fence);
+   return NULL;
+   }
+
+   while ((prev = dma_fence_chain_get_prev(chain))) {
+
+   prev_chain = to_dma_fence_chain(prev);
+   if (prev_chain) {
+   if (!dma_fence_is_signaled(prev_chain->fence))
+   break;
+
+   replacement = dma_fence_chain_get_prev(prev_chain);
+   } else {
+   if (!dma_fence_is_signaled(prev))
+   break;
+
+   replacement = NULL;
+   }
+
+   tmp = cmpxchg(>prev, prev, replacement);
+   if (tmp == prev)
+   dma_fence_put(tmp);
+   else
+   dma_fence_put(replacement);
+   dma_fence_put(prev);
+   }
+
+   dma_fence_put(fence);
+   return prev;
+}
+EXPORT_SYMBOL(dma_fence_chain_walk);
+
+/**
+ * dma_fence_chain_find_seqno - find fence chain node by seqno
+ * @pfence: pointer to the chain node where to start
+ * @seqno: the sequence number to search for
+ *
+ * Advance the fence pointer to the chain node which will signal this sequence
+ * number. If no sequence number is provided then this is a no-op.
+ *
+ * Returns EINVAL if the fence is not a chain node or the sequence number has
+ * not yet advanced far enough.
+ */
+int dma_fence_chain_find_seqno(struct dma_fence **pfence, uint64_t seqno)
+{
+   struct dma_fence_chain *chain;
+
+   if (!seqno)
+   return 0;
+
+   chain = to_dma_fence_chain(*pfence);
+   if (!chain || chain->base.seqno < seqno)
+   return -EINVAL;

[PATCH] drm/fourcc: Fix conflicting Y41x definitions

[Maarten Lankhorst]

There has unfortunately been a conflict with the following 3 commits:

commit e9961ab95af81b8d29054361cd5f0c575102cf87
Author: Ayan Kumar Halder 
Date:   Fri Nov 9 17:21:12 2018 +
drm: Added a new format DRM_FORMAT_XVYU2101010

commit 7ba0fee247ee7a36b3bfbed68f6988d980aa3aa3
Author: Brian Starkey 
Date:   Fri Oct 5 10:27:00 2018 +0100

drm/fourcc: Add AFBC yuv fourccs for Mali

and

commit 50bf5d7d595fd0705ef3785f80e679b6da501e5b
Author: Swati Sharma 
Date:   Mon Mar 4 17:26:33 2019 +0530

drm: Add Y2xx and Y4xx (xx:10/12/16) format definitions and fourcc

Unfortunately gcc didn't warn about the redefinitions, because the

Fix this by using new XYVU for i915, without alpha, and making the
Y41x definitions match msdn, with alpha.

Fortunately we caught it early, and the conflict hasn't even landed in
drm-next yet.

Signed-off-by: Maarten Lankhorst 
Cc: Brian Starkey 
Cc: Swati Sharma 
Cc: Ayan Kumar Halder 
Cc: mal...@foss.arm.com
Cc: Daniel Vetter 
Cc: Maxime Ripard 
Cc: Sean Paul 
Cc: Dave Airlie 
Cc: Liviu Dudau 
---
 drivers/gpu/drm/drm_fourcc.c | 12 +--
 drivers/gpu/drm/i915/intel_display.c | 18 -
 drivers/gpu/drm/i915/intel_sprite.c  | 30 ++--
 include/uapi/drm/drm_fourcc.h| 21 +--
 4 files changed, 41 insertions(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index b914b16db9b2..6ea55fb4526d 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -229,17 +229,17 @@ const struct drm_format_info *__drm_format_info(u32 
format)
{ .format = DRM_FORMAT_UYVY,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_VYUY,.depth = 0,  
.num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_XYUV,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
-   { .format = DRM_FORMAT_Y210,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_VUY888,  .depth = 0,  
.num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
-   { .format = DRM_FORMAT_Y410,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true, 
.is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true, 
.is_yuv = true },
-   { .format = DRM_FORMAT_XVYU2101010, .depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y210,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y212,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y216,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
-   { .format = DRM_FORMAT_Y410,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
-   { .format = DRM_FORMAT_Y412,.depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
-   { .format = DRM_FORMAT_Y416,.depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
+   { .format = DRM_FORMAT_Y410,.depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true, 
.is_yuv = true },
+   { .format = DRM_FORMAT_Y412,.depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true, 
.is_yuv = true },
+   { .format = DRM_FORMAT_Y416,.depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true, 
.is_yuv = true },
+   { .format = DRM_FORMAT_XVYU2101010, .depth = 0,  
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
+   { .format = DRM_FORMAT_XVYU12_16161616, .depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
+   { .format = DRM_FORMAT_XVYU16161616,.depth = 0,  
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y0L0,.depth = 0,  
.num_planes = 1,
  .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 }, 
.block_h = { 2, 0, 0 },
  .hsub = 2, .vsub = 2, .has_alpha = true, .is_yuv = true },
diff --git a/drivers/gpu/drm/i915/intel_display.c 

Re: [PATCH v3] drm/fourcc: add ARM GPU tile modifier

[Brian Starkey]

On Tue, Mar 19, 2019 at 08:05:32PM +0800, Qiang Yu wrote:
> Hi Brian,
> 
> > Since your first patch set, I did raise this internally. The request
> > has been making it's way through:
> >
> >  - GPU engineering, to determine what exactly this format is, and
> >what other variants there might be which are supported on different
> >GPU generations, so that we can determine a sane naming convention.
> >
> >  - Our legal team, to determine what detail we are happy to share from
> >an IP perspective. I can't imagine there being an issue here, but
> >process is process, and there's not a lot I can do to move that
> >along.
> >
> > There was talk on the legal side last week. I will ask for an update.
> > I realise this is taking a very long time, and for that I can only
> > apologise; I really am trying to get you an answer.
> 
> Thanks for the update and your effort to make a generic solution on
> the ARM side. It's really some time passed since last time we talked
> about this, but I think it's worth to wait for more time to get a reliable
> solution with more internal information known by us.

Thank you for your patience :-)

> 
> > For other layouts which don't have this kind of combinatorial effect,
> > I'd rather have #defines for the specific layouts, all individually
> > setting the top bit, without giving that top bit any kind of "name".
> > The top bit would effectively mean "not AFBC", rather than meaning
> > "AGTB", allowing us to use the lower bits more freely.
> >
> Seems like another kind of category, but with different meaning.

Indeed, just a category without a name ;-)

Thanks,
-Brian
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 108323] RX580 starts doing a constant noise after setting fans to a fixed value, then back to auto

[bugzilla-daemon]

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

--- Comment #5 from jpalacios...@gmail.com ---
(In reply to bmilreu from comment #3)
> Yes, seems like the same issue. It would be useful to know if someone with a
> non-Sapphire RX580 has the same problem.

MSI RX 480 Gaming X is also affected.

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

Re: [RFC][PATCH 1/5 v2] dma-buf: Add dma-buf heaps framework

[Brian Starkey]

Hi John,

On Tue, Mar 05, 2019 at 12:54:29PM -0800, John Stultz wrote:
> From: "Andrew F. Davis" 

[snip]

> +
> +#define NUM_HEAP_MINORS 128
> +static DEFINE_IDR(dma_heap_idr);
> +static DEFINE_MUTEX(minor_lock); /* Protect idr accesses */

I saw that Matthew Wilcox is trying to nuke idr:
https://patchwork.freedesktop.org/series/57073/

Perhaps a different data structure could be considered? (I don't have
an informed opinion on which).

> +
> +dev_t dma_heap_devt;
> +struct class *dma_heap_class;
> +struct list_head dma_heap_list;
> +struct dentry *dma_heap_debug_root;
> +
> +static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len,
> +  unsigned int flags)
> +{
> + len = PAGE_ALIGN(len);
> + if (!len)
> + return -EINVAL;

I think aligning len to pages only makes sense if heaps are going to
allocate aligned to pages too. Perhaps that's an implicit assumption?
If so, lets document it.

Why not let the heaps take care of aligning len however they want
though?

...

> +
> +int dma_heap_add(struct dma_heap *heap)
> +{
> + struct device *dev_ret;
> + int ret;
> +
> + if (!heap->name || !strcmp(heap->name, "")) {
> + pr_err("dma_heap: Cannot add heap without a name\n");
> + return -EINVAL;
> + }
> +
> + if (!heap->ops || !heap->ops->allocate) {
> + pr_err("dma_heap: Cannot add heap with invalid ops struct\n");
> + return -EINVAL;
> + }
> +
> + /* Find unused minor number */
> + mutex_lock(_lock);
> + ret = idr_alloc(_heap_idr, heap, 0, NUM_HEAP_MINORS, GFP_KERNEL);
> + mutex_unlock(_lock);
> + if (ret < 0) {
> + pr_err("dma_heap: Unable to get minor number for heap\n");
> + return ret;
> + }
> + heap->minor = ret;
> +
> + /* Create device */
> + heap->heap_devt = MKDEV(MAJOR(dma_heap_devt), heap->minor);
> + dev_ret = device_create(dma_heap_class,
> + NULL,
> + heap->heap_devt,
> + NULL,
> + heap->name);
> + if (IS_ERR(dev_ret)) {
> + pr_err("dma_heap: Unable to create char device\n");
> + return PTR_ERR(dev_ret);
> + }
> +
> + /* Add device */
> + cdev_init(>heap_cdev, _heap_fops);
> + ret = cdev_add(>heap_cdev, dma_heap_devt, NUM_HEAP_MINORS);

Shouldn't this be s/dma_heap_devt/heap->heap_devt/ and a count of 1?

Also would it be better to have cdev_add/device_create the other way
around? First create the char device, then once it's all set up
register it with sysfs.

> + if (ret < 0) {
> + device_destroy(dma_heap_class, heap->heap_devt);
> + pr_err("dma_heap: Unable to add char device\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(dma_heap_add);

Until we've figured out how modules are going to work, I still think
it would be a good idea to not export this.

Cheers,
-Brian

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

Re: [PATCH v3] drm/fourcc: add ARM GPU tile modifier

[Qiang Yu]

Hi Brian,

> Since your first patch set, I did raise this internally. The request
> has been making it's way through:
>
>  - GPU engineering, to determine what exactly this format is, and
>what other variants there might be which are supported on different
>GPU generations, so that we can determine a sane naming convention.
>
>  - Our legal team, to determine what detail we are happy to share from
>an IP perspective. I can't imagine there being an issue here, but
>process is process, and there's not a lot I can do to move that
>along.
>
> There was talk on the legal side last week. I will ask for an update.
> I realise this is taking a very long time, and for that I can only
> apologise; I really am trying to get you an answer.

Thanks for the update and your effort to make a generic solution on
the ARM side. It's really some time passed since last time we talked
about this, but I think it's worth to wait for more time to get a reliable
solution with more internal information known by us.

> For other layouts which don't have this kind of combinatorial effect,
> I'd rather have #defines for the specific layouts, all individually
> setting the top bit, without giving that top bit any kind of "name".
> The top bit would effectively mean "not AFBC", rather than meaning
> "AGTB", allowing us to use the lower bits more freely.
>
Seems like another kind of category, but with different meaning.

> If you can hang on a while longer, I hope Arm can push a patch which
> you can just use directly, and then handling the bit assignments will
> be our mess rather than yours :-)
>
That's better, I can wait :-)

Thanks,
Qiang

> > +#define DRM_FORMAT_MOD_ARM_CODE(type, val) \
> > + fourcc_mod_code(ARM, ((__u64)type << 48) | ((val) & 
> > 0xULL))
> > +
> >  /*
> >   * Arm Framebuffer Compression (AFBC) modifiers
> >   *
> > @@ -615,7 +628,8 @@ extern "C" {
> >   * Further information on the use of AFBC modifiers can be found in
> >   * Documentation/gpu/afbc.rst
> >   */
> > -#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode) fourcc_mod_code(ARM, 
> > __afbc_mode)
> > +#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode) \
> > + DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_AFBC, __afbc_mode)
> >
> >  /*
> >   * AFBC superblock size
> > @@ -709,6 +723,21 @@ extern "C" {
> >   */
> >  #define AFBC_FORMAT_MOD_BCH (1ULL << 11)
> >
> > +/*
> > + * Arm Graphics Tiled Buffer (AGTB) modifiers
> > + */
> > +#define DRM_FORMAT_MOD_ARM_AGTB(mode) \
> > + DRM_FORMAT_MOD_ARM_CODE(DRM_FORMAT_MOD_ARM_TYPE_AGTB, mode)
> > +
> > +/*
> > + * AGTB mode 0 modifier
> > + *
> > + * This is used by ARM Mali Utgard/Midgard GPU. It divides buffer into
> > + * 16x16 pixel blocks. Blocks are stored linearly in order, but pixels
> > + * in the block are reordered.
> > + */
> > +#define DRM_FORMAT_MOD_ARM_AGTB_MODE0 DRM_FORMAT_MOD_ARM_AGTB(1)
> > +
> >  /*
> >   * Allwinner tiled modifier
> >   *
> > --
> > 2.17.1
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 8/9] drm/syncobj: add timeline signal ioctl for syncobj v3

[Lionel Landwerlin]

On 15/03/2019 12:09, Chunming Zhou wrote:

v2: individually allocate chain array, since chain node is free independently.
v3: all existing points must be already signaled before cpu perform signal 
operation,
 so add check condition for that.

Signed-off-by: Chunming Zhou 
---
  drivers/gpu/drm/drm_internal.h |   2 +
  drivers/gpu/drm/drm_ioctl.c|   2 +
  drivers/gpu/drm/drm_syncobj.c  | 103 +
  include/uapi/drm/drm.h |   1 +
  4 files changed, 108 insertions(+)

diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index dd11ae5f1eef..d9a483a5fce0 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -190,6 +190,8 @@ int drm_syncobj_reset_ioctl(struct drm_device *dev, void 
*data,
struct drm_file *file_private);
  int drm_syncobj_signal_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file_private);
+int drm_syncobj_timeline_signal_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
  int drm_syncobj_query_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
  
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c

index 92b3b7b2fd81..d337f161909c 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -696,6 +696,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_SIGNAL, drm_syncobj_signal_ioctl,
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_TIMELINE_SIGNAL, 
drm_syncobj_timeline_signal_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_QUERY, drm_syncobj_query_ioctl,
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE, drm_crtc_get_sequence_ioctl, 
DRM_UNLOCKED),
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 306c7b7e2770..eaeb038f97d7 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1183,6 +1183,109 @@ drm_syncobj_signal_ioctl(struct drm_device *dev, void 
*data,
return ret;
  }
  
+int

+drm_syncobj_timeline_signal_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private)
+{
+   struct drm_syncobj_timeline_array *args = data;
+   struct drm_syncobj **syncobjs;
+   struct dma_fence_chain **chains;
+   uint64_t *points;
+   uint32_t i, j, timeline_count = 0;
+   int ret;
+
+   if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+   return -EOPNOTSUPP;
+
+   if (args->pad != 0)
+   return -EINVAL;
+
+   if (args->count_handles == 0)
+   return -EINVAL;
+
+   ret = drm_syncobj_array_find(file_private,
+u64_to_user_ptr(args->handles),
+args->count_handles,
+);
+   if (ret < 0)
+   return ret;
+
+   for (i = 0; i < args->count_handles; i++) {
+   struct dma_fence_chain *chain;
+struct dma_fence *fence;
+
+fence = drm_syncobj_fence_get(syncobjs[i]);
+chain = to_dma_fence_chain(fence);
+if (chain) {
+struct dma_fence *iter;
+
+dma_fence_chain_for_each(iter, fence) {
+if (!iter)
+break;
+   if (!dma_fence_is_signaled(iter)) {
+   dma_fence_put(iter);
+   DRM_ERROR("Client must guarantee all 
existing timeline points signaled before performing host signal operation!");
+   ret = -EPERM;
+   goto out;



Sorry if I'm failing to remember whether we discussed this before.


Signaling a point from the host should be fine even if the previous 
points in the timeline are not signaled.


After all this can happen on the device side as well (out of order 
signaling).



I thought the thing we didn't want is out of order submission.

Just checking the last chain node seqno against the host signal point 
should be enough.



What about simply returning -EPERM, we can warn the application from 
userspace?




+   }
+}
+}
+}
+
+   points = kmalloc_array(args->count_handles, sizeof(*points),
+  GFP_KERNEL);
+   if (!points) {
+   ret = -ENOMEM;
+   goto out;
+   }
+   if (!u64_to_user_ptr(args->points)) {
+   memset(points, 0, 

Re: [PATCH v4 1/4] drm: rockchip: introduce rk3066 hdmi

[Heiko Stübner]

Hi Johan,

Am Mittwoch, 6. März 2019, 23:41:10 CET schrieb Johan Jonker:
> From: Zheng Yang 
> 
> The RK3066 HDMI TX serves as interface between a LCD Controller and
> a HDMI bus. A HDMI TX consists of one HDMI transmitter controller and
> one HDMI transmitter PHY. The interface has three (3) 8-bit data channels
> which can be configured for a number of bus widths (8/10/12/16/20/24-bit)
> and different video formats (RGB, YCbCr).
> 
> Features:
> HDMI version 1.4a, HDCP revision 1.4 and
> DVI version 1.0 compliant transmitter.
> Supports DTV resolutions from 480i to 1080i/p HD.
> Master I2C interface for a DDC connection.
> HDMI TX supports multiple power save modes.
> The HDMI TX input can switch between LCDC0 and LCDC1.
> (Sound support is not included in this patch)
> 
> Signed-off-by: Zheng Yang 
> Signed-off-by: Johan Jonker 

Looks good in general, but there are some minor things to improve yet,
please see below for specifics.

[...]

> +static void rk3066_hdmi_config_phy(struct rk3066_hdmi *hdmi)
> +{
> + /* TMDS uses the same frequency as dclk. */
> + hdmi_writeb(hdmi, HDMI_DEEP_COLOR_MODE, 0x22);

These magic values below are no fault of yours, but in any case this
could use a comment that the semi-public documentation does not
describe hdmi-registers at all, so we're stuck with these magic-values
for now.

> + if (hdmi->tmdsclk > 1) {
> + rk3066_hdmi_phy_write(hdmi, 0x158, 0x0E);
> + rk3066_hdmi_phy_write(hdmi, 0x15c, 0x00);
> + rk3066_hdmi_phy_write(hdmi, 0x160, 0x60);
> + rk3066_hdmi_phy_write(hdmi, 0x164, 0x00);
> + rk3066_hdmi_phy_write(hdmi, 0x168, 0xDA);
> + rk3066_hdmi_phy_write(hdmi, 0x16c, 0xA1);
> + rk3066_hdmi_phy_write(hdmi, 0x170, 0x0e);
> + rk3066_hdmi_phy_write(hdmi, 0x174, 0x22);
> + rk3066_hdmi_phy_write(hdmi, 0x178, 0x00);
> + } else if (hdmi->tmdsclk > 5000) {
> + rk3066_hdmi_phy_write(hdmi, 0x158, 0x06);
> + rk3066_hdmi_phy_write(hdmi, 0x15c, 0x00);
> + rk3066_hdmi_phy_write(hdmi, 0x160, 0x60);
> + rk3066_hdmi_phy_write(hdmi, 0x164, 0x00);
> + rk3066_hdmi_phy_write(hdmi, 0x168, 0xCA);
> + rk3066_hdmi_phy_write(hdmi, 0x16c, 0xA3);
> + rk3066_hdmi_phy_write(hdmi, 0x170, 0x0e);
> + rk3066_hdmi_phy_write(hdmi, 0x174, 0x20);
> + rk3066_hdmi_phy_write(hdmi, 0x178, 0x00);
> + } else {
> + rk3066_hdmi_phy_write(hdmi, 0x158, 0x02);
> + rk3066_hdmi_phy_write(hdmi, 0x15c, 0x00);
> + rk3066_hdmi_phy_write(hdmi, 0x160, 0x60);
> + rk3066_hdmi_phy_write(hdmi, 0x164, 0x00);
> + rk3066_hdmi_phy_write(hdmi, 0x168, 0xC2);
> + rk3066_hdmi_phy_write(hdmi, 0x16c, 0xA2);
> + rk3066_hdmi_phy_write(hdmi, 0x170, 0x0e);
> + rk3066_hdmi_phy_write(hdmi, 0x174, 0x20);
> + rk3066_hdmi_phy_write(hdmi, 0x178, 0x00);
> + }
> +}

> +static void rk3066_hdmi_encoder_enable(struct drm_encoder *encoder)
> +{
> + struct rk3066_hdmi *hdmi = to_rk3066_hdmi(encoder);
> + int mux, val;
> +
> + mux = drm_of_encoder_active_endpoint_id(hdmi->dev->of_node, encoder);
> + if (mux)
> + val = BIT(30) | BIT(14);
> + else
> + val = BIT(30);
> +
> + regmap_write(hdmi->grf, 0x150, val);


Please define constants for both BIT(14) and the 0x150 GRF register,
which is GRF_SOC_CON0, so in the header

#define GRF_SOC_CON00x150
#define HDMI_VIDEO_SEL  BIT(14)

and then do
if (mux)
val = (HDMI_VIDEO_SEL << 16) | HDMI_VIDEO_SEL;
else
val = HDMI_VIDEO_SEL << 16;

regmap_write(hdmi->grf, GRF_SOC_CON0, val);

> +
> + dev_dbg(hdmi->dev, "hdmi encoder enable select: vop%s\n",
> + (mux) ? "1" : "0");
> +
> + rk3066_hdmi_setup(hdmi, >previous_mode);
> +}
> +


> +static const struct drm_display_mode edid_cea_modes[] = {
> + /* 4 - 1280x720@60Hz 16:9 */
> + { DRM_MODE("1280x720", DRM_MODE_TYPE_DRIVER, 74250, 1280, 1390,
> +1430, 1650, 0, 720, 725, 730, 750, 0,
> +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC),
> +   .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
> +};

please drop that, see below

> +static int rk3066_hdmi_connector_get_modes(struct drm_connector *connector)
> +{
> + struct rk3066_hdmi *hdmi = to_rk3066_hdmi(connector);
> + struct drm_display_mode *mode = NULL;
> + struct edid *edid;
> + int ret = 0;
> +
> + if (!hdmi->ddc)
> + return 0;
> +
> + hdmi->hdmi_data.sink_is_hdmi = false;
> +
> + edid = drm_get_edid(connector, hdmi->ddc);
> + if (edid) {
> + hdmi->hdmi_data.sink_is_hdmi = drm_detect_hdmi_monitor(edid);
> +
> + dev_info(hdmi->dev, "monitor type : %s : %dx%d cm\n",
> + 

[Bug 110188] AMD graphics card driver cannot be installed on Fedora 29

[bugzilla-daemon]

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

Qiao Xie  changed:

   What|Removed |Added

 CC||xieq...@yahoo.com

--- Comment #1 from Qiao Xie  ---
Created attachment 143733
  --> https://bugs.freedesktop.org/attachment.cgi?id=143733=edit
https://amdgpu-install.readthedocs.io/en/latest/install-bugrep.html

filing a bug report stricly based on AMD's instructions on the following page:

https://amdgpu-install.readthedocs.io/en/latest/install-bugrep.html

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

Re: [PATCH v9 0/5] drm/sun4i: sun6i_mipi_dsi: Fixes/updates

[Maxime Ripard]

On Mon, Mar 18, 2019 at 11:58:39PM +0530, Jagan Teki wrote:
> Hi,
>
> On Sun, Mar 3, 2019 at 11:06 PM Jagan Teki  wrote:
> >
> > Unfortunately due to various reasons[3] the previous fixes[1] and burst[2]
> > changes are failed to apply.
> >
> > So, this series is filtered version of previous [1] and [2] changes on top
> > of drm-misc.
> >
> > patch-1: Fix for burst mode instruction delay computation
> >
> > patch-2: Fix for TCOn DRQ set bits
> >
> > patch-3: Support vblk timing for 4-lane devices
> >
> > patch-4: GENERIC_SHORT_WRITE_2 dsi transfer support
> >
> > patch-5: Code simplification for dsi timings
> >
> > Changes for v9:
> > - rebase on drm-misc
> > - update commit messages
> > - add hsync_porch overflow patch
> > Changes for v8:
> > - rebase on master
> > - rework on commit messages
> > - rework video start delay
> > - include drq changes from previous version
> > Changes for v7:
> > - rebase on master
> > - collect Merlijn Wajer Tested-by credits.
> > Changes for v6:
> > - fixed all burst mode patches as per previous version comments
> > - rebase on master
> > - update proper commit message
> > - dropped unneeded comments
> > - order the patches that make review easy
> > Changes for v5, v4, v3, v2:
> > - use existing driver code construct for hblk computation
> > - create separate function for vblk computation
> > - cleanup commit messages
> > - update proper commit messages
> > - fixed checkpatch warnings/errors
> > - use proper return value for tcon0 probe
> > - add logic to get tcon0 divider values
> > - simplify timings code to support burst mode
> > - fix drq computation return values
> > - rebase on master
> >
> > [1] https://patchwork.kernel.org/cover/10813573/
> > [2] https://patchwork.kernel.org/cover/10813623/
> > [3] https://patchwork.kernel.org/cover/10805995/
> >
> > Any inputs?
> > Jagan.
>
> Any further comments on this series? Can I send next version with some 
> changes?

Unless you address what we've asked for the very beginning and provide
some accurate description of your problem, and references to why you
think your changes are the right thing to do, it's not worth sending a
new version, the discussion cannot make further progress.

Maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v9 2/5] drm/sun4i: sun6i_mipi_dsi: Fix TCON DRQ set bits

[Maxime Ripard]

On Mon, Mar 11, 2019 at 08:28:22PM +0530, Jagan Teki wrote:
> On Mon, Mar 11, 2019 at 7:39 PM Maxime Ripard  
> wrote:
> >
> > On Thu, Mar 07, 2019 at 09:24:02PM +0530, Jagan Teki wrote:
> > > On Thu, Mar 7, 2019 at 9:09 PM Maxime Ripard  
> > > wrote:
> > > >
> > > > On Thu, Mar 07, 2019 at 05:49:07PM +0530, Jagan Teki wrote:
> > > > > On Mon, Mar 4, 2019 at 9:13 PM Maxime Ripard 
> > > > >  wrote:
> > > > > >
> > > > > > On Sun, Mar 03, 2019 at 11:05:24PM +0530, Jagan Teki wrote:
> > > > > > > TCON DRQ for non-burst DSI mode can computed based on horizontal
> > > > > > > front porch value, but the current driver trying to include sync
> > > > > > > timings along with front porch resulting wrong drq.
> > > > > > >
> > > > > > > This patch is trying to update the drq by subtracting hsync_start
> > > > > > > with hdisplay, which is horizontal front porch.
> > > > > > >
> > > > > > > Current code:
> > > > > > > 
> > > > > > > mode->hsync_end - mode->hdisplay => horizontal front porch + sync
> > > > > > >
> > > > > > > With this patch:
> > > > > > > 
> > > > > > > mode->hsync_start - mode->hdisplay => horizontal front porch
> > > > > > >
> > > > > > > BSP code form BPI-M64-bsp is computing TCON DRQ set bits
> > > > > > > for non-burts as (from linux-sunxi/
> > > > > > > drivers/video/sunxi/disp2/disp/de/lowlevel_sun50iw1/de_dsi.c)
> > > > > > >
> > > > > > > => panel->lcd_ht -panel->lcd_x - panel->lcd_hbp
> > > > > > > => (timmings->hor_front_porch + panel->lcd_hbp + panel->lcd_x)
> > > > > >   ^ + sync length +
> > > > > > >- panel->lcd_x - panel->hbp
> > > > > > > => timmings->hor_front_porch
> > > > > >^ + sync
> > > > > > > => mode->hsync_start - mode->hdisplay
> > > > > >
> > > > > > s/hsync_start/hsync_end/
> > > > >
> > > > > No, it should be front porch so it is hsync_start. This change is
> > > > > trying to update DRQ set to use front porch and above evaluation from
> > > > > BSP, result the same front front porch
> > > > >
> > > > > Current driver has hsync_end - hdisplay which is not front porch
> > > > > timing (it is adding extra sync timing).
> > > >
> > > > It would be if you considered that the back porch actually was the
> > > > back porch plus the sync length. I have found no such evidence, quite
> > > > the opposite actually, everything seems to point at the fact that
> > > > unlike the TCON, the DSI block uses the back porch as only the back
> > > > porch.
> > >
> > > Sorry, I'm not clear about back porch here.
> > >
> > > The current code has mode->hsync_end - mode->hdisplay which is Front
> > > porch + sync time do you think it's not?
> >
> > It is.
> >
> > > DRQ set time is pure front porch value (according BSP) as I didn't
> > > see any information about DRQ set bits in manual or anywhere.
> >
> > This is what I'm telling you. If you consider the back porch as only
> > the back porch, then the result of that BSP calculation you mentionned
> > earlier is the front porch and the sync length.
> >
> > You imply that the back porch should actually be treated as the back
> > porch and the sync length in your calculation. What makes you say so?
>
> I'm consider the computations accordingly to drm_modes.h and which
> matches similar like BSP code.
>
> mode->hsync_end - mode->hdisplay = front porch + sync
>
> but the actual computation is
> mode->hsync_start - mode->hdisplay =>  front porch
>
> Which is similar to what BSP is using.
>
> => panel->lcd_ht -panel->lcd_x - panel->lcd_hbp
> => (timmings->hor_front_porch + panel->lcd_hbp + panel->lcd_x)
>- panel->lcd_x - panel->hbp
> => timmings->hor_front_porch
> => mode->hsync_start - mode->hdisplay

You're missing the point. What I'm asking for is why you think that
panel->lcd_ht == (timmings->hor_front_porch + panel->lcd_hbp +
panel->lcd_x) and not timmings->hor_front_porch + panel->lcd_hbp +
sync_width + panel->lcd_x

maxime

--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel