date:20210430

From: David Yat Sin 

When re-creating queues during CRIU restore, restore the queue
with the same CU mask value used during CRIU dump.

Signed-off-by: David Yat Sin 
Change-Id: I1822fa2488f90365dfe7a3c5971a2ed6c0046b4a
---
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 160 +--
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h|   3 +
 2 files changed, 154 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 130ab100abb2..1d2c2d986a44 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -1890,9 +1890,21 @@ static int kfd_devinfo_restore(struct kfd_process *p, 
struct kfd_criu_devinfo_bu
}
return 0;
 }
-static void criu_dump_queue(struct kfd_process_device *pdd,
+
+static int get_queue_data_sizes(struct kfd_process_device *pdd,
+   struct queue *q,
+   uint32_t *cu_mask_size)
+{
+   int ret = 0;
+
+   *cu_mask_size = sizeof(uint32_t) * (q->properties.cu_mask_count / 32);
+   return ret;
+}
+
+static int criu_dump_queue(struct kfd_process_device *pdd,
struct queue *q,
-   struct kfd_criu_q_bucket *q_bucket)
+   struct kfd_criu_q_bucket *q_bucket,
+  struct queue_restore_data *qrd)
 {
q_bucket->gpu_id = pdd->dev->id;
q_bucket->type = q->properties.type;
@@ -1920,18 +1932,30 @@ static void criu_dump_queue(struct kfd_process_device 
*pdd,
q->properties.ctx_save_restore_area_size;
 
q_bucket->ctl_stack_size = q->properties.ctl_stack_size;
+   if (qrd->cu_mask_size)
+   memcpy(qrd->cu_mask, q->properties.cu_mask, qrd->cu_mask_size);
+
+   q_bucket->cu_mask_size = qrd->cu_mask_size;
+   return 0;
 }
 
 static int criu_dump_queues_device(struct kfd_process_device *pdd,
unsigned *q_index,
unsigned int max_num_queues,
-   struct kfd_criu_q_bucket *user_buckets)
+   struct kfd_criu_q_bucket *user_buckets,
+   uint8_t *queues_data,
+   uint32_t *queues_data_offset,
+   uint32_t queues_data_size)
 {
struct queue *q;
+   struct queue_restore_data qrd;
struct kfd_criu_q_bucket q_bucket;
+   uint8_t *data_ptr = NULL;
+   unsigned int data_ptr_size = 0;
int ret = 0;
 
list_for_each_entry(q, >qpd.queues_list, list) {
+   unsigned int q_data_size;
if (q->properties.type != KFD_QUEUE_TYPE_COMPUTE &&
q->properties.type != KFD_QUEUE_TYPE_SDMA &&
q->properties.type != KFD_QUEUE_TYPE_SDMA_XGMI) {
@@ -1949,7 +1973,49 @@ static int criu_dump_queues_device(struct 
kfd_process_device *pdd,
}
 
memset(_bucket, 0, sizeof(q_bucket));
-   criu_dump_queue(pdd, q, _bucket);
+   memset(, 0, sizeof(qrd));
+
+   ret = get_queue_data_sizes(pdd, q, _mask_size);
+   if (ret) {
+   pr_err("Failed to get queue dump info (%d)\n", ret);
+   ret = -EFAULT;
+   break;
+   }
+
+   q_data_size = qrd.cu_mask_size;
+
+   /* Increase local buffer space if needed */
+   if (data_ptr_size < q_data_size) {
+   if (data_ptr)
+   kfree(data_ptr);
+
+   data_ptr = (uint8_t*)kzalloc(q_data_size, GFP_KERNEL);
+   if (!data_ptr) {
+   ret = -ENOMEM;
+   break;
+   }
+   data_ptr_size = q_data_size;
+   }
+
+   qrd.cu_mask = data_ptr;
+   ret = criu_dump_queue(pdd, q, _bucket, );
+   if (ret)
+   break;
+
+   if (*queues_data_offset + q_data_size > queues_data_size) {
+   pr_err("Required memory exceeds user provided\n");
+   ret = -ENOSPC;
+   break;
+   }
+   ret = copy_to_user((void __user *) (queues_data + 
*queues_data_offset),
+   data_ptr, q_data_size);
+   if (ret) {
+   ret = -EFAULT;
+   break;
+   }
+   q_bucket.queues_data_offset = *queues_data_offset;
+   *queues_data_offset += q_data_size;
+
ret = copy_to_user((void __user *)_buckets[*q_index],
_bucket, sizeof(q_bucket));
if (ret) {
@@ -1959,6 +2025,10 @@ static int

[RFC PATCH 16/17] drm/amdkfd: CRIU implement gpu_id remapping

From: David Yat Sin 

When doing a restore on a different node, the gpu_id's on the restore
node may be different. But the user space application will still refer
use the original gpu_id's in the ioctl calls. Adding code to create a
gpu id mapping so that kfd can determine actual gpu_id during the user
ioctl's.

Signed-off-by: David Yat Sin 
Signed-off-by: Rajneesh Bhardwaj 
Change-Id: I8f72afe847c9ef7b25a902b30516e9043f1b5834
---
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 245 +--
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h|   3 +
 drivers/gpu/drm/amd/amdkfd/kfd_process.c |  18 ++
 3 files changed, 157 insertions(+), 109 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index ce511b246beb..8e92c68eb9c5 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -294,13 +294,14 @@ static int kfd_ioctl_create_queue(struct file *filep, 
struct kfd_process *p,
return err;
 
pr_debug("Looking for gpu id 0x%x\n", args->gpu_id);
-   dev = kfd_device_by_id(args->gpu_id);
-   if (!dev) {
+
+   mutex_lock(>mutex);
+   pdd = kfd_process_device_data_by_id(p, args->gpu_id);
+   if (!pdd) {
pr_debug("Could not find gpu id 0x%x\n", args->gpu_id);
return -EINVAL;
}
-
-   mutex_lock(>mutex);
+   dev = pdd->dev;
 
pdd = kfd_bind_process_to_device(dev, p);
if (IS_ERR(pdd)) {
@@ -491,7 +492,6 @@ static int kfd_ioctl_set_memory_policy(struct file *filep,
struct kfd_process *p, void *data)
 {
struct kfd_ioctl_set_memory_policy_args *args = data;
-   struct kfd_dev *dev;
int err = 0;
struct kfd_process_device *pdd;
enum cache_policy default_policy, alternate_policy;
@@ -506,13 +506,15 @@ static int kfd_ioctl_set_memory_policy(struct file *filep,
return -EINVAL;
}
 
-   dev = kfd_device_by_id(args->gpu_id);
-   if (!dev)
-   return -EINVAL;
-
mutex_lock(>mutex);
+   pdd = kfd_process_device_data_by_id(p, args->gpu_id);
+   if (!pdd) {
+   pr_debug("Could not find gpu id 0x%x\n", args->gpu_id);
+   err = -EINVAL;
+   goto out;
+   }
 
-   pdd = kfd_bind_process_to_device(dev, p);
+   pdd = kfd_bind_process_to_device(pdd->dev, p);
if (IS_ERR(pdd)) {
err = -ESRCH;
goto out;
@@ -525,7 +527,7 @@ static int kfd_ioctl_set_memory_policy(struct file *filep,
(args->alternate_policy == KFD_IOC_CACHE_POLICY_COHERENT)
   ? cache_policy_coherent : cache_policy_noncoherent;
 
-   if (!dev->dqm->ops.set_cache_memory_policy(dev->dqm,
+   if (!pdd->dev->dqm->ops.set_cache_memory_policy(pdd->dev->dqm,
>qpd,
default_policy,
alternate_policy,
@@ -543,17 +545,18 @@ static int kfd_ioctl_set_trap_handler(struct file *filep,
struct kfd_process *p, void *data)
 {
struct kfd_ioctl_set_trap_handler_args *args = data;
-   struct kfd_dev *dev;
int err = 0;
struct kfd_process_device *pdd;
 
-   dev = kfd_device_by_id(args->gpu_id);
-   if (!dev)
-   return -EINVAL;
-
mutex_lock(>mutex);
 
-   pdd = kfd_bind_process_to_device(dev, p);
+   pdd = kfd_process_device_data_by_id(p, args->gpu_id);
+   if (!pdd) {
+   err = -EINVAL;
+   goto out;
+   }
+
+   pdd = kfd_bind_process_to_device(pdd->dev, p);
if (IS_ERR(pdd)) {
err = -ESRCH;
goto out;
@@ -577,16 +580,20 @@ static int kfd_ioctl_dbg_register(struct file *filep,
bool create_ok;
long status = 0;
 
-   dev = kfd_device_by_id(args->gpu_id);
-   if (!dev)
-   return -EINVAL;
+   mutex_lock(>mutex);
+   pdd = kfd_process_device_data_by_id(p, args->gpu_id);
+   if (!pdd) {
+   status = -EINVAL;
+   goto out_unlock_p;
+   }
+   dev = pdd->dev;
 
if (dev->device_info->asic_family == CHIP_CARRIZO) {
pr_debug("kfd_ioctl_dbg_register not supported on CZ\n");
-   return -EINVAL;
+   status = -EINVAL;
+   goto out_unlock_p;
}
 
-   mutex_lock(>mutex);
mutex_lock(kfd_get_dbgmgr_mutex());
 
/*
@@ -596,7 +603,7 @@ static int kfd_ioctl_dbg_register(struct file *filep,
pdd = kfd_bind_process_to_device(dev, p);
if (IS_ERR(pdd)) {
status = PTR_ERR(pdd);
-   goto out;
+   goto out_unlock_dbg;
}
 
if (!dev->dbgmgr) {
@@ -614,8 +621,9 @@ static int kfd_ioctl_dbg_register(struct file *filep,
status = -EINVAL;
}

[RFC PATCH 14/17] drm/amdkfd: CRIU dump/restore queue control stack

From: David Yat Sin 

Dump contents of queue control stacks on CRIU dump and restore them
during CRIU restore.

(rajneesh: rebased to 5.11 and fixed merge conflict)
Signed-off-by: Rajneesh Bhardwaj 
Signed-off-by: David Yat Sin 
Change-Id: Ia1f38f3d4309e1f026981b16d26306672f3bf266
---
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c  | 32 +++
 .../drm/amd/amdkfd/kfd_device_queue_manager.c | 10 +-
 .../drm/amd/amdkfd/kfd_device_queue_manager.h |  4 +--
 drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.h  |  3 ++
 .../gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c  |  8 +
 .../gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c  |  8 +
 .../gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c   | 18 +++
 .../gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c   |  8 +
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h |  6 ++--
 .../amd/amdkfd/kfd_process_queue_manager.c|  8 ++---
 10 files changed, 89 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index b7f3aa759c17..71f734eae071 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -1894,13 +1894,15 @@ static int kfd_devinfo_restore(struct kfd_process *p, 
struct kfd_criu_devinfo_bu
 static int get_queue_data_sizes(struct kfd_process_device *pdd,
struct queue *q,
uint32_t *cu_mask_size,
-   uint32_t *mqd_size)
+   uint32_t *mqd_size,
+   uint32_t *ctl_stack_size)
 {
int ret = 0;
 
*cu_mask_size = sizeof(uint32_t) * (q->properties.cu_mask_count / 32);
 
-   ret = pqm_get_queue_dump_info(>process->pqm, 
q->properties.queue_id, mqd_size);
+   ret = pqm_get_queue_dump_info(>process->pqm,
+   q->properties.queue_id, mqd_size, ctl_stack_size);
if (ret) {
pr_err("Failed to get queue dump info (%d)\n", ret);
return ret;
@@ -1941,6 +1943,8 @@ static int criu_dump_queue(struct kfd_process_device *pdd,
q->properties.ctx_save_restore_area_size;
 
q_bucket->ctl_stack_size = q->properties.ctl_stack_size;
+
+   /* queue_data contains data in this order cu_mask, mqd, ctl_stack */
if (qrd->cu_mask_size)
memcpy(qrd->cu_mask, q->properties.cu_mask, qrd->cu_mask_size);
 
@@ -1952,6 +1956,7 @@ static int criu_dump_queue(struct kfd_process_device *pdd,
 
q_bucket->cu_mask_size = qrd->cu_mask_size;
q_bucket->mqd_size = qrd->mqd_size;
+   q_bucket->ctl_stack_size = qrd->ctl_stack_size;
return ret;
 }
 
@@ -1991,14 +1996,15 @@ static int criu_dump_queues_device(struct 
kfd_process_device *pdd,
memset(_bucket, 0, sizeof(q_bucket));
memset(, 0, sizeof(qrd));
 
-   ret = get_queue_data_sizes(pdd, q, _mask_size, 
_size);
+   ret = get_queue_data_sizes(pdd, q, _mask_size,
+   _size, _stack_size);
if (ret) {
pr_err("Failed to get queue dump info (%d)\n", ret);
ret = -EFAULT;
break;
}
 
-   q_data_size = qrd.cu_mask_size + qrd.mqd_size;
+   q_data_size = qrd.cu_mask_size + qrd.mqd_size + 
qrd.ctl_stack_size;
 
/* Increase local buffer space if needed */
if (data_ptr_size < q_data_size) {
@@ -2013,8 +2019,11 @@ static int criu_dump_queues_device(struct 
kfd_process_device *pdd,
data_ptr_size = q_data_size;
}
 
+   /* data stored in this order: cu_mask, mqd, mqd_ctl_stack */
qrd.cu_mask = data_ptr;
qrd.mqd = data_ptr + qrd.cu_mask_size;
+   qrd.mqd_ctl_stack = qrd.mqd + qrd.mqd_size;
+
ret = criu_dump_queue(pdd, q, _bucket, );
if (ret)
break;
@@ -2334,7 +2343,8 @@ static int criu_restore_queues(struct kfd_process *p,
return ret;
}
 
-   q_data_size = q_bucket.cu_mask_size + q_bucket.mqd_size;
+   q_data_size = q_bucket.cu_mask_size + q_bucket.mqd_size
+   + q_bucket.ctl_stack_size;
 
/* Increase local buffer space if needed */
if (q_data_size > data_ptr_size) {
@@ -2363,6 +2373,9 @@ static int criu_restore_queues(struct kfd_process *p,
qrd.mqd_size = q_bucket.mqd_size;
qrd.mqd = data_ptr + qrd.cu_mask_size;
 
+   qrd.ctl_stack_size = q_bucket.ctl_stack_size;
+   qrd.mqd_ctl_stack = qrd.mqd + qrd.mqd_size;
+
ret = criu_restore_queue(p, dev, pdd, _bucket, );
if (ret) {
pr_err("Failed to restore queue (%d)\n", ret);
@@ -2701,11 +2714,16 @@ static

[RFC PATCH 15/17] drm/amdkfd: CRIU dump and restore events

From: David Yat Sin 

Add support to existing CRIU ioctl's to save and restore events during
criu checkpoint and restore.

Signed-off-by: David Yat Sin 
Change-Id: I1635b1fa91a81abcbd19290cb88c8ca142c390e0
---
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 185 ---
 drivers/gpu/drm/amd/amdkfd/kfd_events.c  | 163 
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h|  11 +-
 3 files changed, 279 insertions(+), 80 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 71f734eae071..ce511b246beb 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -997,6 +997,55 @@ static int kfd_ioctl_get_process_apertures_new(struct file 
*filp,
return 0;
 }
 
+static int kmap_event_page(struct kfd_process *p, uint64_t event_page_offset)
+{
+   struct kfd_dev *kfd;
+   struct kfd_process_device *pdd;
+   void *mem, *kern_addr;
+   uint64_t size;
+   int err = 0;
+
+   if (p->signal_page) {
+   pr_err("Event page is already set\n");
+   return -EINVAL;
+   }
+
+   kfd = kfd_device_by_id(GET_GPU_ID(event_page_offset));
+   if (!kfd) {
+   pr_err("Getting device by id failed in %s\n", __func__);
+   return -EINVAL;
+   }
+
+   pdd = kfd_bind_process_to_device(kfd, p);
+   if (IS_ERR(pdd)) {
+   mutex_unlock(>mutex);
+   return PTR_ERR(pdd);
+   }
+
+   mem = kfd_process_device_translate_handle(pdd,
+   GET_IDR_HANDLE(event_page_offset));
+   if (!mem) {
+   pr_err("Can't find BO, offset is 0x%llx\n", event_page_offset);
+
+   mutex_unlock(>mutex);
+   return -EINVAL;
+   }
+
+   err = amdgpu_amdkfd_gpuvm_map_gtt_bo_to_kernel(kfd->kgd,
+   mem, _addr, );
+   if (err) {
+   pr_err("Failed to map event page to kernel\n");
+   return err;
+   }
+
+   err = kfd_event_page_set(p, kern_addr, size, event_page_offset);
+   if (err) {
+   pr_err("Failed to set event page\n");
+   return err;
+   }
+   return err;
+}
+
 static int kfd_ioctl_create_event(struct file *filp, struct kfd_process *p,
void *data)
 {
@@ -1008,51 +1057,11 @@ static int kfd_ioctl_create_event(struct file *filp, 
struct kfd_process *p,
 * through the event_page_offset field.
 */
if (args->event_page_offset) {
-   struct kfd_dev *kfd;
-   struct kfd_process_device *pdd;
-   void *mem, *kern_addr;
-   uint64_t size;
-
-   if (p->signal_page) {
-   pr_err("Event page is already set\n");
-   return -EINVAL;
-   }
-
-   kfd = kfd_device_by_id(GET_GPU_ID(args->event_page_offset));
-   if (!kfd) {
-   pr_err("Getting device by id failed in %s\n", __func__);
-   return -EINVAL;
-   }
-
mutex_lock(>mutex);
-   pdd = kfd_bind_process_to_device(kfd, p);
-   if (IS_ERR(pdd)) {
-   err = PTR_ERR(pdd);
-   goto out_unlock;
-   }
-
-   mem = kfd_process_device_translate_handle(pdd,
-   GET_IDR_HANDLE(args->event_page_offset));
-   if (!mem) {
-   pr_err("Can't find BO, offset is 0x%llx\n",
-  args->event_page_offset);
-   err = -EINVAL;
-   goto out_unlock;
-   }
+   err = kmap_event_page(p, args->event_page_offset);
mutex_unlock(>mutex);
-
-   err = amdgpu_amdkfd_gpuvm_map_gtt_bo_to_kernel(kfd->kgd,
-   mem, _addr, );
-   if (err) {
-   pr_err("Failed to map event page to kernel\n");
-   return err;
-   }
-
-   err = kfd_event_page_set(p, kern_addr, size);
-   if (err) {
-   pr_err("Failed to set event page\n");
+   if (err)
return err;
-   }
}
 
err = kfd_event_create(filp, p, args->event_type,
@@ -1061,10 +1070,7 @@ static int kfd_ioctl_create_event(struct file *filp, 
struct kfd_process *p,
>event_page_offset,
>event_slot_index);
 
-   return err;
-
-out_unlock:
-   mutex_unlock(>mutex);
+   pr_debug("Created event (id:0x%08x) (%s)\n", args->event_id, __func__);
return err;
 }
 
@@ -2062,6 +2068,7 @@ static int kfd_ioctl_criu_dumper(struct file *filep,
struct kfd_process *p, void

[RFC PATCH 13/17] drm/amdkfd: CRIU dump and restore queue mqds

From: David Yat Sin 

Dump contents of queue MQD's on CRIU dump and restore them during CRIU
restore.

Signed-off-by: David Yat Sin 
Change-Id: If54f892fb6cb8a5bde8a993891dad0dbb997c239
---
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c  | 35 --
 .../drm/amd/amdkfd/kfd_device_queue_manager.c | 64 +++--
 .../drm/amd/amdkfd/kfd_device_queue_manager.h |  8 +++
 drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.h  |  8 +++
 .../gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c  | 66 ++
 .../gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c  | 67 ++
 .../gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c   | 68 +++
 .../gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c   | 67 ++
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h |  8 +++
 .../amd/amdkfd/kfd_process_queue_manager.c| 42 
 10 files changed, 422 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 1d2c2d986a44..b7f3aa759c17 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -1893,11 +1893,18 @@ static int kfd_devinfo_restore(struct kfd_process *p, 
struct kfd_criu_devinfo_bu
 
 static int get_queue_data_sizes(struct kfd_process_device *pdd,
struct queue *q,
-   uint32_t *cu_mask_size)
+   uint32_t *cu_mask_size,
+   uint32_t *mqd_size)
 {
int ret = 0;
 
*cu_mask_size = sizeof(uint32_t) * (q->properties.cu_mask_count / 32);
+
+   ret = pqm_get_queue_dump_info(>process->pqm, 
q->properties.queue_id, mqd_size);
+   if (ret) {
+   pr_err("Failed to get queue dump info (%d)\n", ret);
+   return ret;
+   }
return ret;
 }
 
@@ -1906,6 +1913,8 @@ static int criu_dump_queue(struct kfd_process_device *pdd,
struct kfd_criu_q_bucket *q_bucket,
   struct queue_restore_data *qrd)
 {
+   int ret = 0;
+
q_bucket->gpu_id = pdd->dev->id;
q_bucket->type = q->properties.type;
q_bucket->format = q->properties.format;
@@ -1935,8 +1944,15 @@ static int criu_dump_queue(struct kfd_process_device 
*pdd,
if (qrd->cu_mask_size)
memcpy(qrd->cu_mask, q->properties.cu_mask, qrd->cu_mask_size);
 
+   ret = pqm_dump_mqd(>process->pqm, q->properties.queue_id, qrd);
+   if (ret) {
+   pr_err("Failed dump queue_mqd (%d)\n", ret);
+   return ret;
+   }
+
q_bucket->cu_mask_size = qrd->cu_mask_size;
-   return 0;
+   q_bucket->mqd_size = qrd->mqd_size;
+   return ret;
 }
 
 static int criu_dump_queues_device(struct kfd_process_device *pdd,
@@ -1975,14 +1991,14 @@ static int criu_dump_queues_device(struct 
kfd_process_device *pdd,
memset(_bucket, 0, sizeof(q_bucket));
memset(, 0, sizeof(qrd));
 
-   ret = get_queue_data_sizes(pdd, q, _mask_size);
+   ret = get_queue_data_sizes(pdd, q, _mask_size, 
_size);
if (ret) {
pr_err("Failed to get queue dump info (%d)\n", ret);
ret = -EFAULT;
break;
}
 
-   q_data_size = qrd.cu_mask_size;
+   q_data_size = qrd.cu_mask_size + qrd.mqd_size;
 
/* Increase local buffer space if needed */
if (data_ptr_size < q_data_size) {
@@ -1998,6 +2014,7 @@ static int criu_dump_queues_device(struct 
kfd_process_device *pdd,
}
 
qrd.cu_mask = data_ptr;
+   qrd.mqd = data_ptr + qrd.cu_mask_size;
ret = criu_dump_queue(pdd, q, _bucket, );
if (ret)
break;
@@ -2317,7 +2334,7 @@ static int criu_restore_queues(struct kfd_process *p,
return ret;
}
 
-   q_data_size = q_bucket.cu_mask_size;
+   q_data_size = q_bucket.cu_mask_size + q_bucket.mqd_size;
 
/* Increase local buffer space if needed */
if (q_data_size > data_ptr_size) {
@@ -2343,6 +2360,9 @@ static int criu_restore_queues(struct kfd_process *p,
qrd.cu_mask_size = q_bucket.cu_mask_size;
qrd.cu_mask = data_ptr;
 
+   qrd.mqd_size = q_bucket.mqd_size;
+   qrd.mqd = data_ptr + qrd.cu_mask_size;
+
ret = criu_restore_queue(p, dev, pdd, _bucket, );
if (ret) {
pr_err("Failed to restore queue (%d)\n", ret);
@@ -2680,11 +2700,12 @@ static int kfd_ioctl_criu_helper(struct file *filep,
q->properties.type == KFD_QUEUE_TYPE_SDMA_XGMI) 
{
 
u32 cu_mask_size = 0;
-   ret = get_queue_data_sizes(pdd, q, 
_mask_size);

[RFC PATCH 17/17] Revert "drm/amdgpu: Remove verify_access shortcut for KFD BOs"

From: Rajneesh Bhardwaj 

This reverts commit 12ebe2b9df192a2a8580cd9ee3e9940c116913c8.

This is just a temporary work around and will be dropped later.

Signed-off-by: Rajneesh Bhardwaj 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 99ea29fd12bd..be7eb85af066 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -178,6 +178,13 @@ static int amdgpu_verify_access(struct ttm_buffer_object 
*bo, struct file *filp)
 {
struct amdgpu_bo *abo = ttm_to_amdgpu_bo(bo);
 
+   /*
+* Don't verify access for KFD BOs. They don't have a GEM
+* object associated with them.
+*/
+   if (abo->kfd_bo)
+   return 0;
+
if (amdgpu_ttm_tt_get_usermm(bo->ttm))
return -EPERM;
return drm_vma_node_verify_access(>tbo.base.vma_node,
-- 
2.17.1

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

[RFC PATCH 11/17] drm/amdkfd: CRIU restore queue doorbell id

From: David Yat Sin 

When re-creating queues during CRIU restore, restore the queue with the
same doorbell id value used during CRIU dump.

Signed-off-by: David Yat Sin 
Change-Id: I6a79de1f8c760d5a9d28e7951740296f2f8796a7
---
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c  |  1 +
 .../drm/amd/amdkfd/kfd_device_queue_manager.c | 58 +--
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h |  1 +
 3 files changed, 41 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index afcbdae436fa..130ab100abb2 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -2153,6 +2153,7 @@ int criu_restore_queue(struct kfd_process *p,
 
qrd->qid = q_bucket->q_id;
qrd->sdma_id = q_bucket->sdma_id;
+   qrd->doorbell_id = q_bucket->doorbell_id;
 
ret = pqm_create_queue(>pqm, dev, NULL, , _id, qrd, NULL);
if (ret) {
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index cabdfbacce37..56250c0b5ca0 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -153,7 +153,11 @@ static void decrement_queue_count(struct 
device_queue_manager *dqm,
dqm->active_cp_queue_count--;
 }
 
-static int allocate_doorbell(struct qcm_process_device *qpd, struct queue *q)
+/*
+ * Allocate a doorbell ID to this queue.
+ * If doorbell_id is passed in, make sure requested ID is valid then allocate 
it.
+ */
+static int allocate_doorbell(struct qcm_process_device *qpd, struct queue *q, 
uint32_t const *restore_id)
 {
struct kfd_dev *dev = qpd->dqm->dev;
 
@@ -161,6 +165,9 @@ static int allocate_doorbell(struct qcm_process_device 
*qpd, struct queue *q)
/* On pre-SOC15 chips we need to use the queue ID to
 * preserve the user mode ABI.
 */
+   if (restore_id && *restore_id != q->properties.queue_id)
+   return -EINVAL;
+
q->doorbell_id = q->properties.queue_id;
} else if (q->properties.type == KFD_QUEUE_TYPE_SDMA ||
q->properties.type == KFD_QUEUE_TYPE_SDMA_XGMI) {
@@ -169,25 +176,38 @@ static int allocate_doorbell(struct qcm_process_device 
*qpd, struct queue *q)
 * The doobell index distance between RLC (2*i) and (2*i+1)
 * for a SDMA engine is 512.
 */
-   uint32_t *idx_offset =
-   dev->shared_resources.sdma_doorbell_idx;
 
-   q->doorbell_id = idx_offset[q->properties.sdma_engine_id]
-   + (q->properties.sdma_queue_id & 1)
-   * KFD_QUEUE_DOORBELL_MIRROR_OFFSET
-   + (q->properties.sdma_queue_id >> 1);
+   uint32_t *idx_offset = dev->shared_resources.sdma_doorbell_idx;
+   uint32_t valid_id = idx_offset[q->properties.sdma_engine_id]
+   + (q->properties.sdma_queue_id 
& 1)
+   * 
KFD_QUEUE_DOORBELL_MIRROR_OFFSET
+   + (q->properties.sdma_queue_id 
>> 1);
+
+   if (restore_id && *restore_id != valid_id)
+   return -EINVAL;
+   q->doorbell_id = valid_id;
} else {
-   /* For CP queues on SOC15 reserve a free doorbell ID */
-   unsigned int found;
-
-   found = find_first_zero_bit(qpd->doorbell_bitmap,
-   KFD_MAX_NUM_OF_QUEUES_PER_PROCESS);
-   if (found >= KFD_MAX_NUM_OF_QUEUES_PER_PROCESS) {
-   pr_debug("No doorbells available");
-   return -EBUSY;
+   /* For CP queues on SOC15 */
+   if (restore_id) {
+   /* make sure that ID is free  */
+   if (__test_and_set_bit(*restore_id, 
qpd->doorbell_bitmap)) {
+   return -EINVAL;
+   }
+
+   q->doorbell_id = *restore_id;
+   } else {
+   /* or reserve a free doorbell ID */
+   unsigned int found;
+
+   found = find_first_zero_bit(qpd->doorbell_bitmap,
+   
KFD_MAX_NUM_OF_QUEUES_PER_PROCESS);
+   if (found >= KFD_MAX_NUM_OF_QUEUES_PER_PROCESS) {
+   pr_debug("No doorbells available");
+   return -EBUSY;
+   }
+   set_bit(found, qpd->doorbell_bitmap);
+   q->doorbell_id = found;
}
-   set_bit(found, qpd->doorbell_bitmap);
-   q->doorbell_id =

[RFC PATCH 09/17] drm/amdkfd: CRIU restore queue ids

From: David Yat Sin 

When re-creating queues during CRIU restore, restore the queue with the
same queue id value used during CRIU dump. Adding a new private
structure queue_restore_data to store queue restore information.

Signed-off-by: Rajneesh Bhardwaj 
Signed-off-by: David Yat Sin 
Change-Id: I6959da5d3aeebe5be6623483883ef79676591134
---
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c  | 18 ++-
 drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c   |  2 +-
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h |  6 +
 .../amd/amdkfd/kfd_process_queue_manager.c| 22 ++-
 4 files changed, 41 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index a9a04148e94c..a21d32ff0730 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -313,7 +313,7 @@ static int kfd_ioctl_create_queue(struct file *filep, 
struct kfd_process *p,
dev->id);
 
err = pqm_create_queue(>pqm, dev, filep, _properties, _id,
-   _offset_in_process);
+   NULL, _offset_in_process);
if (err != 0)
goto err_create_queue;
 
@@ -1905,7 +1905,7 @@ static void criu_dump_queue(struct kfd_process_device 
*pdd,
q_bucket->read_ptr_addr = (uint64_t)q->properties.read_ptr;
q_bucket->write_ptr_addr = (uint64_t)q->properties.write_ptr;
q_bucket->doorbell_id = q->doorbell_id;
-   q_bucket->doorbell_off = q->properties.doorbell_off;
+
q_bucket->sdma_id = q->sdma_id;
 
q_bucket->eop_ring_buffer_address =
@@ -2122,7 +2122,8 @@ static void set_queue_properties_from_criu(struct 
queue_properties *qp,
 int criu_restore_queue(struct kfd_process *p,
struct kfd_dev *dev,
struct kfd_process_device *pdd,
-   struct kfd_criu_q_bucket *q_bucket)
+   struct kfd_criu_q_bucket *q_bucket,
+   struct queue_restore_data *qrd)
 {
int ret = 0;
unsigned int queue_id;
@@ -2150,11 +2151,14 @@ int criu_restore_queue(struct kfd_process *p,
set_queue_properties_from_criu(, q_bucket);
print_queue_properties();
 
-   ret = pqm_create_queue(>pqm, dev, NULL, , _id, NULL);
+   qrd->qid = q_bucket->q_id;
+
+   ret = pqm_create_queue(>pqm, dev, NULL, , _id, qrd, NULL);
if (ret) {
pr_err("Failed to create new queue err:%d\n", ret);
return -EINVAL;
}
+
pr_debug("Queue id %d was restored successfully\n", queue_id);
 
return 0;
@@ -2178,6 +2182,10 @@ static int criu_restore_queues(struct kfd_process *p,
 
for (i = 0; i < args->num_of_queues; i++) {
struct kfd_criu_q_bucket q_bucket;
+   struct queue_restore_data qrd;
+
+   memset(, 0, sizeof(qrd));
+
ret = copy_from_user(_bucket, (void __user *)_buckets[i],
sizeof(struct kfd_criu_q_bucket));
 
@@ -2202,7 +2210,7 @@ static int criu_restore_queues(struct kfd_process *p,
ret = -EFAULT;
return ret;
}
-   ret = criu_restore_queue(p, dev, pdd, _bucket);
+   ret = criu_restore_queue(p, dev, pdd, _bucket, );
if (ret) {
pr_err("Failed to restore queue (%d)\n", ret);
break;
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c
index 159add0f5aaa..749a7a3bf191 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c
@@ -185,7 +185,7 @@ static int dbgdev_register_diq(struct kfd_dbgdev *dbgdev)
properties.type = KFD_QUEUE_TYPE_DIQ;
 
status = pqm_create_queue(dbgdev->pqm, dbgdev->dev, NULL,
-   , , NULL);
+   , , NULL, NULL);
 
if (status) {
pr_err("Failed to create DIQ\n");
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h 
b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
index 8278c43f4e50..d21b7eb08a76 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
@@ -468,6 +468,11 @@ enum KFD_QUEUE_PRIORITY {
  * it's user mode or kernel mode queue.
  *
  */
+
+struct queue_restore_data {
+   uint32_t qid;
+};
+
 struct queue_properties {
enum kfd_queue_type type;
enum kfd_queue_format format;
@@ -1055,6 +1060,7 @@ int pqm_create_queue(struct process_queue_manager *pqm,
struct file *f,
struct queue_properties *properties,
unsigned int *qid,
+   const struct queue_restore_data *qrd,

[RFC PATCH 08/17] drm/amdkfd: CRIU add queues support

From: David Yat Sin 

Add support to existing CRIU ioctl's to save number of queues and queue
properties for each queue during checkpoint and re-create queues on restore.

Signed-off-by: David Yat Sin 
Change-Id: Ifcd5e8359f492eef015867f354f44146dd1b6848
---
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 234 ++-
 1 file changed, 231 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 788baee2a025..a9a04148e94c 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -1840,7 +1840,6 @@ static int kfd_devinfo_restore(struct kfd_process *p, 
struct kfd_criu_devinfo_bu
   uint32_t num_of_devices)
 {
int i;
-
if (p->n_pdds != num_of_devices)
return -EINVAL;
 
@@ -1891,6 +1890,77 @@ static int kfd_devinfo_restore(struct kfd_process *p, 
struct kfd_criu_devinfo_bu
}
return 0;
 }
+static void criu_dump_queue(struct kfd_process_device *pdd,
+   struct queue *q,
+   struct kfd_criu_q_bucket *q_bucket)
+{
+   q_bucket->gpu_id = pdd->dev->id;
+   q_bucket->type = q->properties.type;
+   q_bucket->format = q->properties.format;
+   q_bucket->q_id =  q->properties.queue_id;
+   q_bucket->q_address = q->properties.queue_address;
+   q_bucket->q_size = q->properties.queue_size;
+   q_bucket->priority = q->properties.priority;
+   q_bucket->q_percent = q->properties.queue_percent;
+   q_bucket->read_ptr_addr = (uint64_t)q->properties.read_ptr;
+   q_bucket->write_ptr_addr = (uint64_t)q->properties.write_ptr;
+   q_bucket->doorbell_id = q->doorbell_id;
+   q_bucket->doorbell_off = q->properties.doorbell_off;
+   q_bucket->sdma_id = q->sdma_id;
+
+   q_bucket->eop_ring_buffer_address =
+   q->properties.eop_ring_buffer_address;
+
+   q_bucket->eop_ring_buffer_size = q->properties.eop_ring_buffer_size;
+
+   q_bucket->ctx_save_restore_area_address =
+   q->properties.ctx_save_restore_area_address;
+
+   q_bucket->ctx_save_restore_area_size =
+   q->properties.ctx_save_restore_area_size;
+
+   q_bucket->ctl_stack_size = q->properties.ctl_stack_size;
+}
+
+static int criu_dump_queues_device(struct kfd_process_device *pdd,
+   unsigned *q_index,
+   unsigned int max_num_queues,
+   struct kfd_criu_q_bucket *user_buckets)
+{
+   struct queue *q;
+   struct kfd_criu_q_bucket q_bucket;
+   int ret = 0;
+
+   list_for_each_entry(q, >qpd.queues_list, list) {
+   if (q->properties.type != KFD_QUEUE_TYPE_COMPUTE &&
+   q->properties.type != KFD_QUEUE_TYPE_SDMA &&
+   q->properties.type != KFD_QUEUE_TYPE_SDMA_XGMI) {
+
+   pr_err("Unsupported queue type (%d)\n", 
q->properties.type);
+   return -ENOTSUPP;
+   }
+
+   if (*q_index >= max_num_queues) {
+   pr_err("Number of queues(%d) exceed allocated(%d)\n",
+   *q_index, max_num_queues);
+
+   ret = -ENOMEM;
+   break;
+   }
+
+   memset(_bucket, 0, sizeof(q_bucket));
+   criu_dump_queue(pdd, q, _bucket);
+   ret = copy_to_user((void __user *)_buckets[*q_index],
+   _bucket, sizeof(q_bucket));
+   if (ret) {
+   pr_err("Failed to copy queue information to user\n");
+   ret = -EFAULT;
+   break;
+   }
+   *q_index = *q_index + 1;
+   }
+   return ret;
+}
 
 static int kfd_ioctl_criu_dumper(struct file *filep,
struct kfd_process *p, void *data)
@@ -1900,8 +1970,13 @@ static int kfd_ioctl_criu_dumper(struct file *filep,
struct amdgpu_bo *dumper_bo;
int ret, id, index, i = 0;
struct kgd_mem *kgd_mem;
+   int q_index = 0;
void *mem;
 
+   struct kfd_criu_q_bucket *user_buckets =
+   (struct kfd_criu_q_bucket*) args->kfd_criu_q_buckets_ptr;
+
+
pr_info("Inside %s\n",__func__);
 
if (args->num_of_bos == 0) {
@@ -1922,6 +1997,8 @@ static int kfd_ioctl_criu_dumper(struct file *filep,
if (!bo_bucket)
return -ENOMEM;
 
+   pr_debug("num of queues = %u\n", args->num_of_queues);
+
mutex_lock(>mutex);
 
if (!kfd_has_process_device_data(p)) {
@@ -1930,9 +2007,17 @@ static int kfd_ioctl_criu_dumper(struct file *filep,
goto err_unlock;
}
 
+   ret = kfd_process_evict_queues(p);
+   if (ret) {
+   pr_err("Failed to evict queues\n");
+   goto err_unlock;

[RFC PATCH 10/17] drm/amdkfd: CRIU restore sdma id for queues

From: David Yat Sin 

When re-creating queues during CRIU restore, restore the queue with the
same sdma id value used during CRIU dump.

Signed-off-by: David Yat Sin 
Change-Id: I8ed667edb8b9b7b5089e59b78de9be80493a2808
---
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c  |  1 +
 .../drm/amd/amdkfd/kfd_device_queue_manager.c | 48 ++-
 .../drm/amd/amdkfd/kfd_device_queue_manager.h |  3 +-
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h |  1 +
 .../amd/amdkfd/kfd_process_queue_manager.c|  4 +-
 5 files changed, 42 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index a21d32ff0730..afcbdae436fa 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -2152,6 +2152,7 @@ int criu_restore_queue(struct kfd_process *p,
print_queue_properties();
 
qrd->qid = q_bucket->q_id;
+   qrd->sdma_id = q_bucket->sdma_id;
 
ret = pqm_create_queue(>pqm, dev, NULL, , _id, qrd, NULL);
if (ret) {
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
index 98c2046c7331..cabdfbacce37 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c
@@ -58,7 +58,7 @@ static inline void deallocate_hqd(struct device_queue_manager 
*dqm,
struct queue *q);
 static int allocate_hqd(struct device_queue_manager *dqm, struct queue *q);
 static int allocate_sdma_queue(struct device_queue_manager *dqm,
-   struct queue *q);
+   struct queue *q, const uint32_t 
*restore_sdma_id);
 static void kfd_process_hw_exception(struct work_struct *work);
 
 static inline
@@ -296,7 +296,8 @@ static void deallocate_vmid(struct device_queue_manager 
*dqm,
 
 static int create_queue_nocpsch(struct device_queue_manager *dqm,
struct queue *q,
-   struct qcm_process_device *qpd)
+   struct qcm_process_device *qpd,
+   const struct queue_restore_data *qrd)
 {
struct mqd_manager *mqd_mgr;
int retval;
@@ -336,7 +337,7 @@ static int create_queue_nocpsch(struct device_queue_manager 
*dqm,
q->pipe, q->queue);
} else if (q->properties.type == KFD_QUEUE_TYPE_SDMA ||
q->properties.type == KFD_QUEUE_TYPE_SDMA_XGMI) {
-   retval = allocate_sdma_queue(dqm, q);
+   retval = allocate_sdma_queue(dqm, q, qrd ? >sdma_id : 
NULL);
if (retval)
goto deallocate_vmid;
dqm->asic_ops.init_sdma_vm(dqm, q, qpd);
@@ -1022,7 +1023,7 @@ static void pre_reset(struct device_queue_manager *dqm)
 }
 
 static int allocate_sdma_queue(struct device_queue_manager *dqm,
-   struct queue *q)
+   struct queue *q, const uint32_t 
*restore_sdma_id)
 {
int bit;
 
@@ -1032,9 +1033,21 @@ static int allocate_sdma_queue(struct 
device_queue_manager *dqm,
return -ENOMEM;
}
 
-   bit = __ffs64(dqm->sdma_bitmap);
-   dqm->sdma_bitmap &= ~(1ULL << bit);
-   q->sdma_id = bit;
+   if (restore_sdma_id) {
+   /* Re-use existing sdma_id */
+   if (!(dqm->sdma_bitmap & (1ULL << *restore_sdma_id))) {
+   pr_err("SDMA queue already in use\n");
+   return -EBUSY;
+   }
+   dqm->sdma_bitmap &= ~(1ULL << *restore_sdma_id);
+   q->sdma_id = *restore_sdma_id;
+   } else {
+   /* Find first available sdma_id */
+   bit = __ffs64(dqm->sdma_bitmap);
+   dqm->sdma_bitmap &= ~(1ULL << bit);
+   q->sdma_id = bit;
+   }
+
q->properties.sdma_engine_id = q->sdma_id %
get_num_sdma_engines(dqm);
q->properties.sdma_queue_id = q->sdma_id /
@@ -1044,9 +1057,19 @@ static int allocate_sdma_queue(struct 
device_queue_manager *dqm,
pr_err("No more XGMI SDMA queue to allocate\n");
return -ENOMEM;
}
-   bit = __ffs64(dqm->xgmi_sdma_bitmap);
-   dqm->xgmi_sdma_bitmap &= ~(1ULL << bit);
-   q->sdma_id = bit;
+   if (restore_sdma_id) {
+   /* Re-use existing sdma_id */
+   if (!(dqm->xgmi_sdma_bitmap & (1ULL << 
*restore_sdma_id))) {
+   pr_err("SDMA queue already in use\n");
+   return -EBUSY;
+   }
+

[RFC PATCH 07/17] drm/amdkfd: CRIU Implement KFD resume ioctl

From: Rajneesh Bhardwaj 

This adds support to create userptr BOs on restore and introduces a new
ioctl to restart memory notifiers for the restored userptr BOs.
When doing CRIU restore MMU notifications can happen anytime after we call
amdgpu_mn_register. Prevent MMU notifications until we reach stage-4 of the
restore process i.e. criu_resume ioctl is recieved, and the process is ready
to be resumed. This ioctl is different from other KFD CRIU ioctls since
its called by CRIU master restore process for all the target processes
being resumed by CRIU.

Signed-off-by: David Yat Sin 
Signed-off-by: Rajneesh Bhardwaj 
(cherry picked from commit 1f0300f5a4dc12b3c1140b0f0953300b4a6ac81f)
(cherry picked from commit 5c5ae6026ea795ae39acff06db862a7ef2fc6aa9)
Change-Id: I714bbd8bec35feb47e0a1af9c2ce63ea1098fa88
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h|  5 +-
 .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c  | 51 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   | 20 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h   |  2 +
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c  | 63 ---
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h |  1 +
 drivers/gpu/drm/amd/amdkfd/kfd_process.c  | 36 +--
 7 files changed, 159 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
index 313ee49b9f17..158130a4f4cc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
@@ -117,6 +117,7 @@ struct amdkfd_process_info {
atomic_t evicted_bos;
struct delayed_work restore_userptr_work;
struct pid *pid;
+   bool block_mmu_notifications;
 };
 
 int amdgpu_amdkfd_init(void);
@@ -249,7 +250,9 @@ uint64_t amdgpu_amdkfd_gpuvm_get_process_page_dir(void 
*drm_priv);
 int amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu(
struct kgd_dev *kgd, uint64_t va, uint64_t size,
void *drm_priv, struct kgd_mem **mem,
-   uint64_t *offset, uint32_t flags);
+   uint64_t *offset, uint32_t flags, bool criu_resume);
+void amdgpu_amdkfd_block_mmu_notifications(void *p);
+int amdgpu_amdkfd_criu_resume(void *p);
 int amdgpu_amdkfd_gpuvm_free_memory_of_gpu(
struct kgd_dev *kgd, struct kgd_mem *mem, void *drm_priv,
uint64_t *size);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
index dfa025d694f8..ad8818844526 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
@@ -597,7 +597,8 @@ static void remove_kgd_mem_from_kfd_bo_list(struct kgd_mem 
*mem,
  *
  * Returns 0 for success, negative errno for errors.
  */
-static int init_user_pages(struct kgd_mem *mem, uint64_t user_addr)
+static int init_user_pages(struct kgd_mem *mem, uint64_t user_addr,
+  bool criu_resume)
 {
struct amdkfd_process_info *process_info = mem->process_info;
struct amdgpu_bo *bo = mem->bo;
@@ -619,6 +620,17 @@ static int init_user_pages(struct kgd_mem *mem, uint64_t 
user_addr)
goto out;
}
 
+   if (criu_resume) {
+   /*
+* During a CRIU restore operation, the userptr buffer objects
+* will be validated in the restore_userptr_work worker at a
+* later stage when it is scheduled by another ioctl called by
+* CRIU master process for the target pid for restore.
+*/
+   atomic_inc(>invalid);
+   mutex_unlock(_info->lock);
+   return 0;
+   }
ret = amdgpu_ttm_tt_get_user_pages(bo, bo->tbo.ttm->pages);
if (ret) {
pr_err("%s: Failed to get user pages: %d\n", __func__, ret);
@@ -982,6 +994,7 @@ static int init_kfd_vm(struct amdgpu_vm *vm, void 
**process_info,
INIT_DELAYED_WORK(>restore_userptr_work,
  amdgpu_amdkfd_restore_userptr_worker);
 
+   info->block_mmu_notifications = false;
*process_info = info;
*ef = dma_fence_get(>eviction_fence->base);
}
@@ -1139,10 +1152,37 @@ uint64_t amdgpu_amdkfd_gpuvm_get_process_page_dir(void 
*drm_priv)
return avm->pd_phys_addr;
 }
 
+void amdgpu_amdkfd_block_mmu_notifications(void *p)
+{
+   struct amdkfd_process_info *pinfo = (struct amdkfd_process_info *)p;
+
+   pinfo->block_mmu_notifications = true;
+}
+
+int amdgpu_amdkfd_criu_resume(void *p)
+{
+   int ret = 0;
+   struct amdkfd_process_info *pinfo = (struct amdkfd_process_info *)p;
+
+   mutex_lock(>lock);
+   pr_debug("scheduling work\n");
+   atomic_inc(>evicted_bos);
+   if (!pinfo->block_mmu_notifications) {
+   ret = -EINVAL;
+   goto out_unlock;
+   }
+   pinfo->block_mmu_notifications = false;
+

[RFC PATCH 06/17] drm/amdkfd: CRIU Implement KFD restore ioctl

From: Rajneesh Bhardwaj 

This implements the KFD CRIU Restore ioctl that lays the basic
foundation for the CRIU restore operation. It provides support to
create the buffer objects corresponding to Non-Paged system memory
mapped for GPU and/or CPU access and lays basic foundation for the
userptrs buffer objects which will be added in a seperate patch.
This ioctl creates various types of buffer objects such as VRAM,
MMIO, Doorbell, GTT based on the date sent from the userspace plugin.
The data mostly contains the previously checkpointed KFD images from
some KFD processs.

While restoring a criu process, attach old IDR values to newly
created BOs. This also adds the minimal gpu mapping support for a single
gpu checkpoint restore use case.

Signed-off-by: David Yat Sin 
Signed-off-by: Rajneesh Bhardwaj 
(cherry picked from commit 47bb685701c336d1fde7e91be93d9cabe89a4c1b)
(cherry picked from commit b71ba8158a7ddf9e4fd8d872be4e40ddd9a29b4f)
Change-Id: Id392516c6af409f1e92303d8dc21411764f2d8fa
---
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 321 ++-
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h|   6 +
 2 files changed, 325 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 1454f5613e60..95d81d00daa9 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -1804,6 +1804,94 @@ static int kfd_ioctl_svm(struct file *filep, struct 
kfd_process *p, void *data)
return -EPERM;
 }
 #endif
+static int kfd_devinfo_dump(struct kfd_process *p, struct 
kfd_ioctl_criu_dumper_args *args)
+{
+   int ret = 0;
+   int index;
+   struct kfd_criu_devinfo_bucket *devinfos;
+
+   if (p->n_pdds != args->num_of_devices)
+   return -EINVAL;
+
+   devinfos = kvzalloc((sizeof(struct kfd_criu_devinfo_bucket) *
+args->num_of_devices), GFP_KERNEL);
+   if (!devinfos)
+   return -ENOMEM;
+
+   for (index = 0; index < p->n_pdds; index++) {
+   struct kfd_process_device *pdd = p->pdds[index];
+
+   devinfos[index].user_gpu_id = pdd->user_gpu_id;
+   devinfos[index].actual_gpu_id = pdd->dev->id;
+   }
+
+   ret = copy_to_user((void __user *)args->kfd_criu_devinfo_buckets_ptr,
+   devinfos,
+   (args->num_of_devices *
+   sizeof(struct kfd_criu_devinfo_bucket)));
+   if (ret)
+   ret = -EFAULT;
+
+   kvfree(devinfos);
+   return ret;
+}
+
+static int kfd_devinfo_restore(struct kfd_process *p, struct 
kfd_criu_devinfo_bucket *devinfos,
+  uint32_t num_of_devices)
+{
+   int i;
+
+   if (p->n_pdds != num_of_devices)
+   return -EINVAL;
+
+   for (i = 0; i < p->n_pdds; i++) {
+   struct kfd_dev *dev;
+   struct kfd_process_device *pdd;
+   struct file *drm_file;
+
+   dev = kfd_device_by_id(devinfos[i].actual_gpu_id);
+   if (!dev) {
+   pr_err("Failed to find device with gpu_id = %x\n",
+   devinfos[i].actual_gpu_id);
+   return -EINVAL;
+   }
+
+   pdd = kfd_get_process_device_data(dev, p);
+   if (!pdd) {
+   pr_err("Failed to get pdd for gpu_id = %x\n", 
devinfos[i].actual_gpu_id);
+   return -EINVAL;
+   }
+   pdd->user_gpu_id = devinfos[i].user_gpu_id;
+
+   drm_file = fget(devinfos[i].drm_fd);
+   if (!drm_file) {
+   pr_err("Invalid render node file descriptor sent from 
plugin (%d)\n",
+   devinfos[i].drm_fd);
+   return -EINVAL;
+   }
+
+   if (pdd->drm_file)
+   return -EINVAL;
+
+   /* create the vm using render nodes for kfd pdd */
+   if (kfd_process_device_init_vm(pdd, drm_file)) {
+   pr_err("could not init vm for given pdd\n");
+   /* On success, the PDD keeps the drm_file reference */
+   fput(drm_file);
+   return -EINVAL;
+   }
+   /*
+* pdd now already has the vm bound to render node so below api 
won't create a new
+* exclusive kfd mapping but use existing one with renderDXXX 
but is still needed
+* for iommu v2 binding  and runtime pm.
+*/
+   pdd = kfd_bind_process_to_device(dev, p);
+   if (IS_ERR(pdd))
+   return PTR_ERR(pdd);
+   }
+   return 0;
+}
+
 static int kfd_ioctl_criu_dumper(struct file *filep,
struct kfd_process *p, void *data)
 {
@@ -1842,6 +1930,10 @@ static int

[RFC PATCH 05/17] drm/amdkfd: CRIU Implement KFD dumper ioctl

From: Rajneesh Bhardwaj 

This adds support to discover the buffer objects that belong to a
process being checkpointed. The data corresponding to these buffer
objects is returned to user space plugin running under criu master
context which then stores this info to recreate these buffer objects
during a restore operation.

Signed-off-by: David Yat Sin 
Signed-off-by: Rajneesh Bhardwaj 
(cherry picked from commit 1f114a541bd21873de905db64bb9efa673274d4b)
(cherry picked from commit 20c435fad57d3201e5402e38ae778f1f0f84a09d)
Change-Id: Ifdbeee3606578db61bdc9aca7528272e20a38256
---
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 96 +++-
 1 file changed, 95 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 6b347ce5992f..1454f5613e60 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -42,6 +42,7 @@
 #include "kfd_svm.h"
 #include "amdgpu_amdkfd.h"
 #include "kfd_smi_events.h"
+#include "amdgpu_object.h"
 
 static long kfd_ioctl(struct file *, unsigned int, unsigned long);
 static int kfd_open(struct inode *, struct file *);
@@ -1806,9 +1807,102 @@ static int kfd_ioctl_svm(struct file *filep, struct 
kfd_process *p, void *data)
 static int kfd_ioctl_criu_dumper(struct file *filep,
struct kfd_process *p, void *data)
 {
+   struct kfd_ioctl_criu_dumper_args *args = data;
+   struct kfd_criu_bo_buckets *bo_bucket;
+   struct amdgpu_bo *dumper_bo;
+   int ret, id, index, i = 0;
+   struct kgd_mem *kgd_mem;
+   void *mem;
+
pr_info("Inside %s\n",__func__);
 
-   return 0;
+   if (args->num_of_bos == 0) {
+   pr_err("No BOs to be dumped\n");
+   return -EINVAL;
+   }
+
+   if (p->n_pdds != args->num_of_devices) {
+   pr_err("Invalid number of devices %d (expected = %d)\n",
+   
args->num_of_devices, p->n_pdds);
+   return -EINVAL;
+   }
+
+   pr_debug("num of bos = %llu\n", args->num_of_bos);
+
+   bo_bucket = kvzalloc((sizeof(struct kfd_criu_bo_buckets) *
+args->num_of_bos), GFP_KERNEL);
+   if (!bo_bucket)
+   return -ENOMEM;
+
+   mutex_lock(>mutex);
+
+   if (!kfd_has_process_device_data(p)) {
+   pr_err("No pdd for given process\n");
+   ret = -ENODEV;
+   goto err_unlock;
+   }
+
+   /* Run over all PDDs of the process */
+   for (index = 0; index < p->n_pdds; index++) {
+   struct kfd_process_device *pdd = p->pdds[index];
+
+   idr_for_each_entry(>alloc_idr, mem, id) {
+   if (!mem) {
+   ret = -ENOMEM;
+   goto err_unlock;
+   }
+
+   kgd_mem = (struct kgd_mem *)mem;
+   dumper_bo = kgd_mem->bo;
+
+   if ((uint64_t)kgd_mem->va > pdd->gpuvm_base) {
+   if (i >= args->num_of_bos) {
+   pr_err("Num of BOs changed since last 
helper ioctl call\n");
+   ret = -EINVAL;
+   goto err_unlock;
+   }
+
+   bo_bucket[i].bo_addr = (uint64_t)kgd_mem->va;
+   bo_bucket[i].bo_size = 
amdgpu_bo_size(dumper_bo);
+   bo_bucket[i].gpu_id = pdd->dev->id;
+   bo_bucket[i].bo_alloc_flags = 
(uint32_t)kgd_mem->alloc_flags;
+   bo_bucket[i].idr_handle = id;
+
+   if (bo_bucket[i].bo_alloc_flags & 
KFD_IOC_ALLOC_MEM_FLAGS_DOORBELL)
+   bo_bucket[i].bo_offset = 
KFD_MMAP_TYPE_DOORBELL |
+   KFD_MMAP_GPU_ID(pdd->dev->id);
+   else if (bo_bucket[i].bo_alloc_flags &
+   KFD_IOC_ALLOC_MEM_FLAGS_MMIO_REMAP)
+   bo_bucket[i].bo_offset = 
KFD_MMAP_TYPE_MMIO |
+   KFD_MMAP_GPU_ID(pdd->dev->id);
+   else
+   bo_bucket[i].bo_offset = 
amdgpu_bo_mmap_offset(dumper_bo);
+
+   pr_debug("bo_size = 0x%llx, bo_addr = 0x%llx 
bo_offset = 0x%llx\n"
+"gpu_id = 0x%x alloc_flags = 0x%x 
idr_handle = 0x%x",
+bo_bucket[i].bo_size,
+bo_bucket[i].bo_addr,
+bo_bucket[i].bo_offset,
+bo_bucket[i].gpu_id,
+

[RFC PATCH 04/17] drm/amdkfd: CRIU Implement KFD helper ioctl

From: Rajneesh Bhardwaj 

This IOCTL is expected to be called as a precursor to the actual
Checkpoint operation. This does the basic discovery into the target
process seized by CRIU and relays the information to the userspace that
utilizes it to start the Checkpoint operation via another dedicated
IOCTL.

The helper IOCTL determines the number of GPUs, buffer objects that are
associated with the target process, its process id in caller's namespace
since /proc/pid/mem interface maybe used to drain the contenets of the
discovered buffer objects in userspace and getpid returns the pid of
CRIU dumper process. Also the pid of a process inside a container might
be different than its global pid so return the ns pid.

Signed-off-by: Rajneesh Bhardwaj 
(cherry picked from commit b2fa92d0a8f1de51013cd6742b4996b38c285ffc)
(cherry picked from commit 8b44c466ce53162603cd8ae49624462902541a47)
Signed-off-by: David Yat Sin 
Change-Id: I2c6b28fe4df7333c9faf7eb6ee86decabe475338
---
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 42 ++--
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h|  2 ++
 drivers/gpu/drm/amd/amdkfd/kfd_process.c | 14 
 3 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 1fa2ba34a429..6b347ce5992f 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -1822,9 +1822,47 @@ static int kfd_ioctl_criu_restorer(struct file *filep,
 static int kfd_ioctl_criu_helper(struct file *filep,
struct kfd_process *p, void *data)
 {
-   pr_info("Inside %s\n",__func__);
+   struct kfd_ioctl_criu_helper_args *args = data;
+   struct kgd_mem *kgd_mem;
+   u64 num_of_bos = 0;
+   int id, i = 0;
+   void *mem;
+   int ret = 0;
 
-   return 0;
+   pr_debug("Inside %s\n", __func__);
+   mutex_lock(>mutex);
+
+   if (!kfd_has_process_device_data(p)) {
+   pr_err("No pdd for given process\n");
+   ret = -ENODEV;
+   goto err_unlock;
+   }
+
+   /* Run over all PDDs of the process */
+   for (i = 0; i < p->n_pdds; i++) {
+   struct kfd_process_device *pdd = p->pdds[i];
+
+   idr_for_each_entry(>alloc_idr, mem, id) {
+   if (!mem) {
+   ret = -ENOMEM;
+   goto err_unlock;
+   }
+
+   kgd_mem = (struct kgd_mem *)mem;
+   if ((uint64_t)kgd_mem->va > pdd->gpuvm_base)
+   num_of_bos++;
+   }
+   }
+
+   args->task_pid = task_pid_nr_ns(p->lead_thread,
+   task_active_pid_ns(p->lead_thread));
+   args->num_of_devices = p->n_pdds;
+   args->num_of_bos = num_of_bos;
+   dev_dbg(kfd_device, "Num of bos = %llu\n", num_of_bos);
+
+err_unlock:
+   mutex_unlock(>mutex);
+   return ret;
 }
 
 static int kfd_ioctl_criu_resume(struct file *filep,
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h 
b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
index a494d61543af..74d3eb383099 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_priv.h
@@ -932,6 +932,8 @@ void *kfd_process_device_translate_handle(struct 
kfd_process_device *p,
 void kfd_process_device_remove_obj_handle(struct kfd_process_device *pdd,
int handle);
 
+bool kfd_has_process_device_data(struct kfd_process *p);
+
 /* PASIDs */
 int kfd_pasid_init(void);
 void kfd_pasid_exit(void);
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_process.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
index 9d4f527bda7c..bc133c3789d8 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_process.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_process.c
@@ -1359,6 +1359,20 @@ static int init_doorbell_bitmap(struct 
qcm_process_device *qpd,
return 0;
 }
 
+bool kfd_has_process_device_data(struct kfd_process *p)
+{
+   int i;
+
+   for (i = 0; i < p->n_pdds; i++) {
+   struct kfd_process_device *pdd = p->pdds[i];
+
+   if (pdd)
+   return true;
+   }
+
+   return false;
+}
+
 struct kfd_process_device *kfd_get_process_device_data(struct kfd_dev *dev,
struct kfd_process *p)
 {
-- 
2.17.1

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

[RFC PATCH 03/17] drm/amdkfd: CRIU Introduce Checkpoint-Restore APIs

From: Rajneesh Bhardwaj 

Checkpoint-Restore in userspace (CRIU) is a powerful tool that can
snapshot a running process and later restore it on same or a remote
machine but expects the processes that have a device file (e.g. GPU)
associated with them, provide necessary driver support to assist CRIU
and its extensible plugin interface. Thus, In order to support the
Checkpoint-Restore of any ROCm process, the AMD Radeon Open Compute
Kernel driver, needs to provide a set of new APIs that provide
necessary VRAM metadata and its contents to a userspace component
(CRIU plugin) that can store it in form of image files.

This introduces some new ioctls which will be used to checkpoint-Restore
any KFD bound user process. KFD doesn't allow any arbitrary ioctl call
unless it is called by the group leader process. Since these ioctls are
expected to be called from a KFD criu plugin which has elevated ptrace
attached priviledges and CAP_SYS_ADMIN capabilities attached with the file
descriptors so modify KFD to allow such calls.

Signed-off-by: David Yat Sin 
Signed-off-by: Rajneesh Bhardwaj 
(cherry picked from commit 72f4907135aed9c037b9f442a6055b51733b518a)
(cherry picked from commit 33ff4953c5352f51d57a77ba8ae6614b7993e70d)
Change-Id: I1b25f6f65ad44b897752ac2c771a95157d0b1130
---
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c |  60 -
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h|  28 ++
 include/uapi/linux/kfd_ioctl.h   | 110 ++-
 3 files changed, 196 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
index 059c3f1ca27d..1fa2ba34a429 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "kfd_priv.h"
@@ -1802,6 +1803,37 @@ static int kfd_ioctl_svm(struct file *filep, struct 
kfd_process *p, void *data)
return -EPERM;
 }
 #endif
+static int kfd_ioctl_criu_dumper(struct file *filep,
+   struct kfd_process *p, void *data)
+{
+   pr_info("Inside %s\n",__func__);
+
+   return 0;
+}
+
+static int kfd_ioctl_criu_restorer(struct file *filep,
+   struct kfd_process *p, void *data)
+{
+   pr_info("Inside %s\n",__func__);
+
+   return 0;
+}
+
+static int kfd_ioctl_criu_helper(struct file *filep,
+   struct kfd_process *p, void *data)
+{
+   pr_info("Inside %s\n",__func__);
+
+   return 0;
+}
+
+static int kfd_ioctl_criu_resume(struct file *filep,
+   struct kfd_process *p, void *data)
+{
+   pr_info("Inside %s\n",__func__);
+
+   return 0;
+}
 
 #define AMDKFD_IOCTL_DEF(ioctl, _func, _flags) \
[_IOC_NR(ioctl)] = {.cmd = ioctl, .func = _func, .flags = _flags, \
@@ -1906,6 +1938,18 @@ static const struct amdkfd_ioctl_desc amdkfd_ioctls[] = {
 
AMDKFD_IOCTL_DEF(AMDKFD_IOC_SET_XNACK_MODE,
kfd_ioctl_set_xnack_mode, 0),
+
+   AMDKFD_IOCTL_DEF(AMDKFD_IOC_CRIU_DUMPER,
+kfd_ioctl_criu_dumper, KFD_IOC_FLAG_PTRACE_ATTACHED),
+
+   AMDKFD_IOCTL_DEF(AMDKFD_IOC_CRIU_RESTORER,
+kfd_ioctl_criu_restorer, KFD_IOC_FLAG_ROOT_ONLY),
+
+   AMDKFD_IOCTL_DEF(AMDKFD_IOC_CRIU_HELPER,
+kfd_ioctl_criu_helper, KFD_IOC_FLAG_PTRACE_ATTACHED),
+
+   AMDKFD_IOCTL_DEF(AMDKFD_IOC_CRIU_RESUME,
+kfd_ioctl_criu_resume, KFD_IOC_FLAG_ROOT_ONLY),
 };
 
 #define AMDKFD_CORE_IOCTL_COUNTARRAY_SIZE(amdkfd_ioctls)
@@ -1920,6 +1964,7 @@ static long kfd_ioctl(struct file *filep, unsigned int 
cmd, unsigned long arg)
char *kdata = NULL;
unsigned int usize, asize;
int retcode = -EINVAL;
+   bool ptrace_attached = false;
 
if (nr >= AMDKFD_CORE_IOCTL_COUNT)
goto err_i1;
@@ -1945,7 +1990,15 @@ static long kfd_ioctl(struct file *filep, unsigned int 
cmd, unsigned long arg)
 * processes need to create their own KFD device context.
 */
process = filep->private_data;
-   if (process->lead_thread != current->group_leader) {
+
+   rcu_read_lock();
+   if ((ioctl->flags & KFD_IOC_FLAG_PTRACE_ATTACHED) &&
+   ptrace_parent(process->lead_thread) == current)
+   ptrace_attached = true;
+   rcu_read_unlock();
+
+   if (process->lead_thread != current->group_leader
+   && !ptrace_attached) {
dev_dbg(kfd_device, "Using KFD FD in wrong process\n");
retcode = -EBADF;
goto err_i1;
@@ -1960,6 +2013,11 @@ static long kfd_ioctl(struct file *filep, unsigned int 
cmd, unsigned long arg)
goto err_i1;
}
 
+   /* KFD_IOC_FLAG_ROOT_ONLY is only for CAP_SYS_ADMIN */
+   if (unlikely((ioctl->flags & KFD_IOC_FLAG_ROOT_ONLY) &&
+

[RFC PATCH 02/17] x86/configs: CRIU update debug rock defconfig

From: Rajneesh Bhardwaj 

 - Update debug config for Checkpoint-Restore (CR) support
 - Also include necessary options for CR with docker containers.

Signed-off-by: Rajneesh Bhardwaj 
Change-Id: Ie993f9b99553d46c48c60a5a1c054de0d923bc86
---
 arch/x86/configs/rock-dbg_defconfig | 53 ++---
 1 file changed, 34 insertions(+), 19 deletions(-)

diff --git a/arch/x86/configs/rock-dbg_defconfig 
b/arch/x86/configs/rock-dbg_defconfig
index 54688993d6e2..87951da7de6a 100644
--- a/arch/x86/configs/rock-dbg_defconfig
+++ b/arch/x86/configs/rock-dbg_defconfig
@@ -236,6 +236,7 @@ CONFIG_BPF_SYSCALL=y
 CONFIG_ARCH_WANT_DEFAULT_BPF_JIT=y
 # CONFIG_BPF_PRELOAD is not set
 # CONFIG_USERFAULTFD is not set
+CONFIG_USERFAULTFD=y
 CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE=y
 CONFIG_KCMP=y
 CONFIG_RSEQ=y
@@ -994,6 +995,11 @@ CONFIG_PACKET_DIAG=y
 CONFIG_UNIX=y
 CONFIG_UNIX_SCM=y
 CONFIG_UNIX_DIAG=y
+CONFIG_SMC_DIAG=y
+CONFIG_XDP_SOCKETS_DIAG=y
+CONFIG_INET_MPTCP_DIAG=y
+CONFIG_TIPC_DIAG=y
+CONFIG_VSOCKETS_DIAG=y
 # CONFIG_TLS is not set
 CONFIG_XFRM=y
 CONFIG_XFRM_ALGO=y
@@ -1031,15 +1037,17 @@ CONFIG_SYN_COOKIES=y
 # CONFIG_NET_IPVTI is not set
 # CONFIG_NET_FOU is not set
 # CONFIG_NET_FOU_IP_TUNNELS is not set
-# CONFIG_INET_AH is not set
-# CONFIG_INET_ESP is not set
-# CONFIG_INET_IPCOMP is not set
-CONFIG_INET_TUNNEL=y
-CONFIG_INET_DIAG=y
-CONFIG_INET_TCP_DIAG=y
-# CONFIG_INET_UDP_DIAG is not set
-# CONFIG_INET_RAW_DIAG is not set
-# CONFIG_INET_DIAG_DESTROY is not set
+CONFIG_INET_AH=m
+CONFIG_INET_ESP=m
+CONFIG_INET_IPCOMP=m
+CONFIG_INET_ESP_OFFLOAD=m
+CONFIG_INET_TUNNEL=m
+CONFIG_INET_XFRM_TUNNEL=m
+CONFIG_INET_DIAG=m
+CONFIG_INET_TCP_DIAG=m
+CONFIG_INET_UDP_DIAG=m
+CONFIG_INET_RAW_DIAG=m
+CONFIG_INET_DIAG_DESTROY=y
 CONFIG_TCP_CONG_ADVANCED=y
 # CONFIG_TCP_CONG_BIC is not set
 CONFIG_TCP_CONG_CUBIC=y
@@ -1064,12 +1072,14 @@ CONFIG_TCP_MD5SIG=y
 CONFIG_IPV6=y
 # CONFIG_IPV6_ROUTER_PREF is not set
 # CONFIG_IPV6_OPTIMISTIC_DAD is not set
-CONFIG_INET6_AH=y
-CONFIG_INET6_ESP=y
-# CONFIG_INET6_ESP_OFFLOAD is not set
-# CONFIG_INET6_ESPINTCP is not set
-# CONFIG_INET6_IPCOMP is not set
-# CONFIG_IPV6_MIP6 is not set
+CONFIG_INET6_AH=m
+CONFIG_INET6_ESP=m
+CONFIG_INET6_ESP_OFFLOAD=m
+CONFIG_INET6_IPCOMP=m
+CONFIG_IPV6_MIP6=m
+CONFIG_INET6_XFRM_TUNNEL=m
+CONFIG_INET_DCCP_DIAG=m
+CONFIG_INET_SCTP_DIAG=m
 # CONFIG_IPV6_ILA is not set
 # CONFIG_IPV6_VTI is not set
 CONFIG_IPV6_SIT=y
@@ -1126,8 +1136,13 @@ CONFIG_NF_CT_PROTO_UDPLITE=y
 # CONFIG_NF_CONNTRACK_SANE is not set
 # CONFIG_NF_CONNTRACK_SIP is not set
 # CONFIG_NF_CONNTRACK_TFTP is not set
-# CONFIG_NF_CT_NETLINK is not set
-# CONFIG_NF_CT_NETLINK_TIMEOUT is not set
+CONFIG_COMPAT_NETLINK_MESSAGES=y
+CONFIG_NF_CT_NETLINK=m
+CONFIG_NF_CT_NETLINK_TIMEOUT=m
+CONFIG_NF_CT_NETLINK_HELPER=m
+CONFIG_NETFILTER_NETLINK_GLUE_CT=y
+CONFIG_SCSI_NETLINK=y
+CONFIG_QUOTA_NETLINK_INTERFACE=y
 CONFIG_NF_NAT=m
 CONFIG_NF_NAT_REDIRECT=y
 CONFIG_NF_NAT_MASQUERADE=y
@@ -1971,7 +1986,7 @@ CONFIG_NETCONSOLE_DYNAMIC=y
 CONFIG_NETPOLL=y
 CONFIG_NET_POLL_CONTROLLER=y
 # CONFIG_RIONET is not set
-# CONFIG_TUN is not set
+CONFIG_TUN=y
 # CONFIG_TUN_VNET_CROSS_LE is not set
 CONFIG_VETH=y
 # CONFIG_NLMON is not set
@@ -3955,7 +3970,7 @@ CONFIG_MANDATORY_FILE_LOCKING=y
 CONFIG_FSNOTIFY=y
 CONFIG_DNOTIFY=y
 CONFIG_INOTIFY_USER=y
-# CONFIG_FANOTIFY is not set
+CONFIG_FANOTIFY=y
 CONFIG_QUOTA=y
 CONFIG_QUOTA_NETLINK_INTERFACE=y
 # CONFIG_PRINT_QUOTA_WARNING is not set
-- 
2.17.1

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

[RFC PATCH 01/17] x86/configs: CRIU update release defconfig

From: Rajneesh Bhardwaj 

Update rock-rel_defconfig for monolithic kernel release that enables
CRIU support with kfd.

Signed-off-by: Rajneesh Bhardwaj 
(cherry picked from commit 4a6d309a82648a23a4fc0add83013ac6db6187d5)
Change-Id: Ie6fe1e44285f4fccc17092baee664e8d784851fa
---
 arch/x86/configs/rock-rel_defconfig | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/x86/configs/rock-rel_defconfig 
b/arch/x86/configs/rock-rel_defconfig
index 16fe62276006..9c46bb890879 100644
--- a/arch/x86/configs/rock-rel_defconfig
+++ b/arch/x86/configs/rock-rel_defconfig
@@ -1045,6 +1045,11 @@ CONFIG_PACKET_DIAG=m
 CONFIG_UNIX=y
 CONFIG_UNIX_SCM=y
 CONFIG_UNIX_DIAG=m
+CONFIG_SMC_DIAG=y
+CONFIG_XDP_SOCKETS_DIAG=y
+CONFIG_INET_MPTCP_DIAG=y
+CONFIG_TIPC_DIAG=y
+CONFIG_VSOCKETS_DIAG=y
 # CONFIG_TLS is not set
 CONFIG_XFRM=y
 CONFIG_XFRM_ALGO=m
@@ -1089,7 +1094,7 @@ CONFIG_NET_FOU=m
 CONFIG_NET_FOU_IP_TUNNELS=y
 CONFIG_INET_AH=m
 CONFIG_INET_ESP=m
-# CONFIG_INET_ESP_OFFLOAD is not set
+CONFIG_INET_ESP_OFFLOAD=m
 # CONFIG_INET_ESPINTCP is not set
 CONFIG_INET_IPCOMP=m
 CONFIG_INET_XFRM_TUNNEL=m
@@ -1097,8 +1102,8 @@ CONFIG_INET_TUNNEL=m
 CONFIG_INET_DIAG=m
 CONFIG_INET_TCP_DIAG=m
 CONFIG_INET_UDP_DIAG=m
-# CONFIG_INET_RAW_DIAG is not set
-# CONFIG_INET_DIAG_DESTROY is not set
+CONFIG_INET_RAW_DIAG=m
+CONFIG_INET_DIAG_DESTROY=m
 CONFIG_TCP_CONG_ADVANCED=y
 CONFIG_TCP_CONG_BIC=m
 CONFIG_TCP_CONG_CUBIC=y
@@ -1126,7 +1131,7 @@ CONFIG_IPV6_ROUTE_INFO=y
 # CONFIG_IPV6_OPTIMISTIC_DAD is not set
 CONFIG_INET6_AH=m
 CONFIG_INET6_ESP=m
-# CONFIG_INET6_ESP_OFFLOAD is not set
+CONFIG_INET6_ESP_OFFLOAD=m
 # CONFIG_INET6_ESPINTCP is not set
 CONFIG_INET6_IPCOMP=m
 CONFIG_IPV6_MIP6=m
-- 
2.17.1

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

[RFC PATCH 00/17] CRIU support for ROCm

This patch series is a prototype for supporting CRIU for ROCm
applications. More work is needed before this can be upstreamed and
released, including a new ioctl API that is extensible without breaking
the ABI.

The user mode code to go with this can be found at
https://github.com/RadeonOpenCompute/criu/tree/criu-dev/test/others/ext-kfd
It will be discussed with the CRIU community on c...@openvz.org and
evolve together with this patch series.

This patch series is also available on github:
https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver/commits/fxkamd/criu-wip

David Yat Sin (9):
  drm/amdkfd: CRIU add queues support
  drm/amdkfd: CRIU restore queue ids
  drm/amdkfd: CRIU restore sdma id for queues
  drm/amdkfd: CRIU restore queue doorbell id
  drm/amdkfd: CRIU restore CU mask for queues
  drm/amdkfd: CRIU dump and restore queue mqds
  drm/amdkfd: CRIU dump/restore queue control stack
  drm/amdkfd: CRIU dump and restore events
  drm/amdkfd: CRIU implement gpu_id remapping

Rajneesh Bhardwaj (8):
  x86/configs: CRIU update release defconfig
  x86/configs: CRIU update debug rock defconfig
  drm/amdkfd: CRIU Introduce Checkpoint-Restore APIs
  drm/amdkfd: CRIU Implement KFD helper ioctl
  drm/amdkfd: CRIU Implement KFD dumper ioctl
  drm/amdkfd: CRIU Implement KFD restore ioctl
  drm/amdkfd: CRIU Implement KFD resume ioctl
  Revert "drm/amdgpu: Remove verify_access shortcut for KFD BOs"

 arch/x86/configs/rock-dbg_defconfig   |   53 +-
 arch/x86/configs/rock-rel_defconfig   |   13 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h|5 +-
 .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c  |   51 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |   27 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h   |2 +
 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c  | 1445 ++---
 drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c   |2 +-
 .../drm/amd/amdkfd/kfd_device_queue_manager.c |  178 +-
 .../drm/amd/amdkfd/kfd_device_queue_manager.h |   11 +-
 drivers/gpu/drm/amd/amdkfd/kfd_events.c   |  163 +-
 drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager.h  |   11 +
 .../gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c  |   74 +
 .../gpu/drm/amd/amdkfd/kfd_mqd_manager_v10.c  |   75 +
 .../gpu/drm/amd/amdkfd/kfd_mqd_manager_v9.c   |   86 +
 .../gpu/drm/amd/amdkfd/kfd_mqd_manager_vi.c   |   75 +
 drivers/gpu/drm/amd/amdkfd/kfd_priv.h |   72 +-
 drivers/gpu/drm/amd/amdkfd/kfd_process.c  |   68 +-
 .../amd/amdkfd/kfd_process_queue_manager.c|   68 +-
 include/uapi/linux/kfd_ioctl.h|  110 +-
 20 files changed, 2304 insertions(+), 285 deletions(-)

-- 
2.17.1

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

[RFC] CRIU support for ROCm

We have been working on a prototype supporting CRIU (Checkpoint/Restore
In Userspace) for accelerated compute applications running on AMD GPUs
using ROCm (Radeon Open Compute Platform). We're happy to finally share
this work publicly to solicit feedback and advice. The end-goal is to
get this work included upstream in Linux and CRIU. A short whitepaper
describing our design and intention can be found on Github:
https://github.com/RadeonOpenCompute/criu/tree/criu-dev/test/others/ext-kfd/README.md.

We have RFC patch series for the kernel (based on Alex Deucher's
amd-staging-drm-next branch) and for CRIU including a new plugin and a
few core CRIU changes. I will send those to the respective mailing lists
separately in a minute. They can also be found on Github.

CRIU+plugin: https://github.com/RadeonOpenCompute/criu/commits/criu-dev
Kernel (KFD):

https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver/commits/fxkamd/criu-wip

At this point this is very much a work in progress and not ready for
upstream inclusion. There are still several missing features, known
issues, and open questions that we would like to start addressing with
your feedback.

What's working and tested at this point:

  * Checkpoint and restore accelerated machine learning apps: PyTorch
running Bert on systems with 1 or 2 GPUs (MI50 or MI100), 100%
unmodified user mode stack
  * Checkpoint on one system, restore on a different system
  * Checkpoint on one GPU, restore on a different GPU

Major Known issues:

  * The KFD ioctl API is not final: Needs a complete redesign to allow
future extension without breaking the ABI
  * Very slow: Need to implement DMA to dump VRAM contents

Missing or incomplete features:

  * Support for the new KFD SVM API
  * Check device topology during restore
  * Checkpoint and restore multiple processes
  * Support for applications using Mesa for video decode/encode
  * Testing with more different GPUs and workloads

Big Open questions:

  * What's the preferred way to publish our CRIU plugin? In-tree or
out-of-tree?
  * What's the preferred way to distribute our CRIU plugin? Source?
Binary .so? Whole CRIU? Just in-box support?
  * If our plugin can be upstreamed in the CRIU tree, what would be the
right directory?

Best regards,
  Felix


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

Re: [PATCH 1/1] i915/query: Correlate engine and cpu timestamps with better accuracy


On April 30, 2021 18:00:58 "Dixit, Ashutosh"  wrote:


On Fri, 30 Apr 2021 15:26:09 -0700, Umesh Nerlige Ramappa wrote:


Looks like the engine can be dropped since all timestamps are in sync. I
just have one more question here. The timestamp itself is 36 bits.  Should
the uapi also report the timestamp width to the user OR should I just
return the lower 32 bits of the timestamp?


Yeah, I think reporting the timestamp width is a good idea since we're 
reporting the period/frequency here.





How would exposing only the lower 32 bits of the timestamp work?

The way to avoid exposing the width would be to expose the timestamp as a
regular 64 bit value. In the kernel engine state, have a variable for the
counter and keep on accumulating that (on each query) to full 64 bits in
spite of the 36 bit HW counter overflow.


That's doesn't actually work since you can query the 64-bit timestamp value 
from the GPU. The way this is handled in Vulkan is that the number of 
timestamp bits is reported to the application as a queue property.


--Jason





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

Re: [PATCH 1/1] i915/query: Correlate engine and cpu timestamps with better accuracy

2021-04-30 Thread Dixit, Ashutosh

On Fri, 30 Apr 2021 16:00:46 -0700, Dixit, Ashutosh wrote:
>
> On Fri, 30 Apr 2021 15:26:09 -0700, Umesh Nerlige Ramappa wrote:
> >
> > Looks like the engine can be dropped since all timestamps are in sync. I
> > just have one more question here. The timestamp itself is 36 bits.  Should
> > the uapi also report the timestamp width to the user OR should I just
> > return the lower 32 bits of the timestamp?
>
> How would exposing only the lower 32 bits of the timestamp work?

It would work I guess but overflow every few seconds. So if the counters
are sampled at a low frequency (once every few seconds) it would yield
misleading timestamps.

> The way to avoid exposing the width would be to expose the timestamp as a
> regular 64 bit value. In the kernel engine state, have a variable for the
> counter and keep on accumulating that (on each query) to full 64 bits in
> spite of the 36 bit HW counter overflow.
>
> So not exposing the width (or exposing a 64 bit timestamp) is a cleaner
> interface but also more work in the kernel.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [PATCH 0/6] drm/msm: Trim down drm debugging logs

2021-04-30 Thread abhinavk


On 2021-04-30 12:30, Stephen Boyd wrote:

This patch series attempts to trim down the drm logging in the msm
driver to make it useable with DRM_UT_DRIVER, DRM_UT_KMS, and DRM_UT_DP
levels enabled. Right now the log is really spammy and prints multiple
lines for what feels like every frame. I moved those prints off to
other DRM_UT_* levels that felt appropriate. Please review.

Cc: Dmitry Baryshkov 
Cc: Abhinav Kumar 
Cc: Kuogee Hsieh 
Cc: aravi...@codeaurora.org
Cc: Sean Paul 


For the entire series,
Reviewed-by: Abhinav Kumar 


Stephen Boyd (6):
  drm/msm: Move vblank debug prints to drm_dbg_vbl()
  drm/msm: Use VERB() for extra verbose logging
  drm/msm/dp: Drop malformed debug print
  drm/msm: Move FB debug prints to drm_dbg_state()
  drm/msm/disp: Use plane debug print helper
  drm/msm/disp: Move various debug logs to atomic bucket

 drivers/gpu/drm/msm/adreno/adreno_gpu.c   |  2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c  | 16 
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 22 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  | 38 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   | 10 ++---
 .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c  |  2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c   |  6 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 19 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c  | 14 +++
 drivers/gpu/drm/msm/dp/dp_panel.c |  1 -
 drivers/gpu/drm/msm/msm_drv.c |  4 +-
 drivers/gpu/drm/msm/msm_fb.c  |  8 ++--
 12 files changed, 67 insertions(+), 75 deletions(-)


base-commit: 9f4ad9e425a1d3b6a34617b8ea226d56a119a717

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

Re: [PATCH 1/1] i915/query: Correlate engine and cpu timestamps with better accuracy

2021-04-30 Thread Dixit, Ashutosh

On Fri, 30 Apr 2021 15:26:09 -0700, Umesh Nerlige Ramappa wrote:
>
> Looks like the engine can be dropped since all timestamps are in sync. I
> just have one more question here. The timestamp itself is 36 bits.  Should
> the uapi also report the timestamp width to the user OR should I just
> return the lower 32 bits of the timestamp?

How would exposing only the lower 32 bits of the timestamp work?

The way to avoid exposing the width would be to expose the timestamp as a
regular 64 bit value. In the kernel engine state, have a variable for the
counter and keep on accumulating that (on each query) to full 64 bits in
spite of the 36 bit HW counter overflow.

So not exposing the width (or exposing a 64 bit timestamp) is a cleaner
interface but also more work in the kernel.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH v2 1/1] drm/i915: Use the correct max source link rate for MST

2021-04-30 Thread Cornij, Nikola

[AMD Official Use Only - Internal Distribution Only]

I'll fix the dpcd part to use kHz on Monday

My apologies as well, not only for coming up with the wrong patch in first 
place, but also for missing to CC all the maintainers.

-Original Message-
From: Lyude Paul 
Sent: Friday, April 30, 2021 6:41 PM
To: Cornij, Nikola ; amd-...@lists.freedesktop.org
Cc: Pillai, Aurabindo ; Lipski, Mikita 
; ville.syrj...@linux.intel.com; koba...@canonical.com; 
intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; 
jani.nik...@linux.intel.com; bske...@redhat.com
Subject: Re: [PATCH v2 1/1] drm/i915: Use the correct max source link rate for 
MST

Alright - I had Ville double check this and give their A-B on IRC (I just need 
to fix the open coded link_rate_to_bw() here). Since this got broken on drm- 
misc-next I'm going to go ahead and push the fix there, since I'm not going to 
be around next Monday or Tuesday and I don't want to leave i915 broken in the 
interim. Sorry about the noise with this Jani!

As well - I'll get to fixing the dpcd unit usage once I get back on Wednesday 
(unless Nikola's already gotten to it by then) so we use KHz instead. Although 
as ville has pointed out, I think we should teach the topology manager to allow 
passing for the current link rate/lane count during state computation in the 
long term.

On Fri, 2021-04-30 at 17:45 -0400, Nikola Cornij wrote:
> [why]
> Previously used value was not safe to provide the correct value, i.e.
> it could be 0 if not not configured, leading to no MST on this platform.
>
> [how]
> Do not use the value from BIOS, but from the structure populated at
> encoder initialization time.
>
> Fixes: 98025a62cb00 ("drm/dp_mst: Use Extended Base Receiver
> Capability DPCD
> space")
> Signed-off-by: Nikola Cornij 
> Reviewed-by: Lyude Paul 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index bf7f8487945c..3642d7578658 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -942,7 +942,7 @@ intel_dp_mst_encoder_init(struct
> intel_digital_port *dig_port, int conn_base_id)
> struct intel_dp *intel_dp = _port->dp;
> enum port port = dig_port->base.port;
> int ret;
> -   int bios_max_link_rate;
> +   int max_source_rate = intel_dp->source_rates[intel_dp-
> >num_source_rates - 1];
>
> if (!HAS_DP_MST(i915) || intel_dp_is_edp(intel_dp))
> return 0;
> @@ -957,11 +957,11 @@ intel_dp_mst_encoder_init(struct
> intel_digital_port *dig_port, int conn_base_id)
>
> /* create encoders */
> intel_dp_create_fake_mst_encoders(dig_port);
> -   bios_max_link_rate =
> intel_bios_dp_max_link_rate(_port->base);
> ret = drm_dp_mst_topology_mgr_init(_dp->mst_mgr,
> >drm,
>_dp->aux, 16, 3,
>(u8)dig_port->max_lanes,
> -  (u8)(bios_max_link_rate /
> 27000), conn_base_id);
> +  (u8)(max_source_rate /
> +27000),
> +  conn_base_id);
> if (ret)
> return ret;
>

--
Sincerely,
   Lyude Paul (she/her)
   Software Engineer at Red Hat

Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've 
asked me a question, are waiting for a review/merge on a patch, etc. and I 
haven't responded in a while, please feel free to send me another email to 
check on my status. I don't bite!

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

Re: [PATCH v2 1/1] drm/i915: Use the correct max source link rate for MST

Alright - I had Ville double check this and give their A-B on IRC (I just need
to fix the open coded link_rate_to_bw() here). Since this got broken on drm-
misc-next I'm going to go ahead and push the fix there, since I'm not going to
be around next Monday or Tuesday and I don't want to leave i915 broken in the
interim. Sorry about the noise with this Jani!

As well - I'll get to fixing the dpcd unit usage once I get back on Wednesday
(unless Nikola's already gotten to it by then) so we use KHz instead. Although
as ville has pointed out, I think we should teach the topology manager to allow
passing for the current link rate/lane count during state computation in the
long term.

On Fri, 2021-04-30 at 17:45 -0400, Nikola Cornij wrote:
> [why]
> Previously used value was not safe to provide the correct value, i.e. it
> could be 0 if not not configured, leading to no MST on this platform.
> 
> [how]
> Do not use the value from BIOS, but from the structure populated at
> encoder initialization time.
> 
> Fixes: 98025a62cb00 ("drm/dp_mst: Use Extended Base Receiver Capability DPCD
> space")
> Signed-off-by: Nikola Cornij 
> Reviewed-by: Lyude Paul 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index bf7f8487945c..3642d7578658 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -942,7 +942,7 @@ intel_dp_mst_encoder_init(struct intel_digital_port
> *dig_port, int conn_base_id)
> struct intel_dp *intel_dp = _port->dp;
> enum port port = dig_port->base.port;
> int ret;
> -   int bios_max_link_rate;
> +   int max_source_rate = intel_dp->source_rates[intel_dp-
> >num_source_rates - 1];
>  
> if (!HAS_DP_MST(i915) || intel_dp_is_edp(intel_dp))
> return 0;
> @@ -957,11 +957,11 @@ intel_dp_mst_encoder_init(struct intel_digital_port
> *dig_port, int conn_base_id)
>  
> /* create encoders */
> intel_dp_create_fake_mst_encoders(dig_port);
> -   bios_max_link_rate = intel_bios_dp_max_link_rate(_port->base);
> ret = drm_dp_mst_topology_mgr_init(_dp->mst_mgr, >drm,
>    _dp->aux, 16, 3,
>    (u8)dig_port->max_lanes,
> -  (u8)(bios_max_link_rate / 27000),
> conn_base_id);
> +  (u8)(max_source_rate / 27000),
> +  conn_base_id);
> if (ret)
> return ret;
>  

-- 
Sincerely,
   Lyude Paul (she/her)
   Software Engineer at Red Hat

Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!

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

[PATCH 2/2] drm/dp: Drop open-coded drm_dp_is_branch() in drm_dp_read_downstream_info()

Noticed this while fixing another issue in drm_dp_read_downstream_info(),
the open coded DP_DOWNSTREAMPORT_PRESENT check here just duplicates what we
already do in drm_dp_is_branch(), so just get rid of it.

Signed-off-by: Lyude Paul 
---
 drivers/gpu/drm/drm_dp_helper.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 27c8c5bdf7d9..0f84df8798ab 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -677,9 +677,7 @@ int drm_dp_read_downstream_info(struct drm_dp_aux *aux,
memset(downstream_ports, 0, DP_MAX_DOWNSTREAM_PORTS);
 
/* No downstream info to read */
-   if (!drm_dp_is_branch(dpcd) ||
-   dpcd[DP_DPCD_REV] < DP_DPCD_REV_10 ||
-   !(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
+   if (!drm_dp_is_branch(dpcd) || dpcd[DP_DPCD_REV] < DP_DPCD_REV_10)
return 0;
 
/* Some branches advertise having 0 downstream ports, despite also 
advertising they have a
-- 
2.30.2

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

[PATCH 1/2] drm/dp: Handle zeroed port counts in drm_dp_read_downstream_info()

While the DP specification isn't entirely clear on if this should be
allowed or not, some branch devices report having downstream ports present
while also reporting a downstream port count of 0. So to avoid breaking
those devices, we need to handle this in drm_dp_read_downstream_info().

So, to do this we assume there's no downstream port info when the
downstream port count is 0.

Signed-off-by: Lyude Paul 
Tested-by: Jérôme de Bretagne 
Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3416
Fixes: 3d3721ccb18a ("drm/i915/dp: Extract drm_dp_read_downstream_info()")
Cc:  # v5.10+
---
 drivers/gpu/drm/drm_dp_helper.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index cb56d74e9d38..27c8c5bdf7d9 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -682,7 +682,14 @@ int drm_dp_read_downstream_info(struct drm_dp_aux *aux,
!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
return 0;
 
+   /* Some branches advertise having 0 downstream ports, despite also 
advertising they have a
+* downstream port present. The DP spec isn't clear on if this is 
allowed or not, but since
+* some branches do it we need to handle it regardless.
+*/
len = drm_dp_downstream_port_count(dpcd);
+   if (!len)
+   return 0;
+
if (dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE)
len *= 4;
 
-- 
2.30.2

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

Re: [PATCH 1/1] i915/query: Correlate engine and cpu timestamps with better accuracy

2021-04-30 Thread Umesh Nerlige Ramappa


On Thu, Apr 29, 2021 at 02:07:58PM -0500, Jason Ekstrand wrote:

On Wed, Apr 28, 2021 at 7:34 PM Umesh Nerlige Ramappa
 wrote:


Perf measurements rely on CPU and engine timestamps to correlate
events of interest across these time domains. Current mechanisms get
these timestamps separately and the calculated delta between these
timestamps lack enough accuracy.

To improve the accuracy of these time measurements to within a few us,
add a query that returns the engine and cpu timestamps captured as
close to each other as possible.

v2: (Tvrtko)
- document clock reference used
- return cpu timestamp always
- capture cpu time just before lower dword of cs timestamp

v3: (Chris)
- use uncore-rpm
- use __query_cs_timestamp helper

v4: (Lionel)
- Kernel perf subsytem allows users to specify the clock id to be used
  in perf_event_open. This clock id is used by the perf subsystem to
  return the appropriate cpu timestamp in perf events. Similarly, let
  the user pass the clockid to this query so that cpu timestamp
  corresponds to the clock id requested.

v5: (Tvrtko)
- Use normal ktime accessors instead of fast versions
- Add more uApi documentation

v6: (Lionel)
- Move switch out of spinlock

v7: (Chris)
- cs_timestamp is a misnomer, use cs_cycles instead
- return the cs cycle frequency as well in the query

v8:
- Add platform and engine specific checks

v9: (Lionel)
- Return 2 cpu timestamps in the query - captured before and after the
  register read

v10: (Chris)
- Use local_clock() to measure time taken to read lower dword of
  register and return it to user.

v11: (Jani)
- IS_GEN deprecated. User GRAPHICS_VER instead.

v12: (Jason)
- Split cpu timestamp array into timestamp and delta for cleaner API

Signed-off-by: Umesh Nerlige Ramappa 
Reviewed-by: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_query.c | 148 ++
 include/uapi/drm/i915_drm.h   |  52 +++
 2 files changed, 200 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_query.c 
b/drivers/gpu/drm/i915/i915_query.c
index fed337ad7b68..357c44e8177c 100644
--- a/drivers/gpu/drm/i915/i915_query.c
+++ b/drivers/gpu/drm/i915/i915_query.c
@@ -6,6 +6,8 @@

 #include 

+#include "gt/intel_engine_pm.h"
+#include "gt/intel_engine_user.h"
 #include "i915_drv.h"
 #include "i915_perf.h"
 #include "i915_query.h"
@@ -90,6 +92,151 @@ static int query_topology_info(struct drm_i915_private 
*dev_priv,
return total_length;
 }

+typedef u64 (*__ktime_func_t)(void);
+static __ktime_func_t __clock_id_to_func(clockid_t clk_id)
+{
+   /*
+* Use logic same as the perf subsystem to allow user to select the
+* reference clock id to be used for timestamps.
+*/
+   switch (clk_id) {
+   case CLOCK_MONOTONIC:
+   return _get_ns;
+   case CLOCK_MONOTONIC_RAW:
+   return _get_raw_ns;
+   case CLOCK_REALTIME:
+   return _get_real_ns;
+   case CLOCK_BOOTTIME:
+   return _get_boottime_ns;
+   case CLOCK_TAI:
+   return _get_clocktai_ns;
+   default:
+   return NULL;
+   }
+}
+
+static inline int
+__read_timestamps(struct intel_uncore *uncore,
+ i915_reg_t lower_reg,
+ i915_reg_t upper_reg,
+ u64 *cs_ts,
+ u64 *cpu_ts,
+ u64 *cpu_delta,
+ __ktime_func_t cpu_clock)
+{
+   u32 upper, lower, old_upper, loop = 0;
+
+   upper = intel_uncore_read_fw(uncore, upper_reg);
+   do {
+   *cpu_delta = local_clock();
+   *cpu_ts = cpu_clock();
+   lower = intel_uncore_read_fw(uncore, lower_reg);
+   *cpu_delta = local_clock() - *cpu_delta;
+   old_upper = upper;
+   upper = intel_uncore_read_fw(uncore, upper_reg);
+   } while (upper != old_upper && loop++ < 2);
+
+   *cs_ts = (u64)upper << 32 | lower;
+
+   return 0;
+}
+
+static int
+__query_cs_cycles(struct intel_engine_cs *engine,
+ u64 *cs_ts, u64 *cpu_ts, u64 *cpu_delta,
+ __ktime_func_t cpu_clock)
+{
+   struct intel_uncore *uncore = engine->uncore;
+   enum forcewake_domains fw_domains;
+   u32 base = engine->mmio_base;
+   intel_wakeref_t wakeref;
+   int ret;
+
+   fw_domains = intel_uncore_forcewake_for_reg(uncore,
+   RING_TIMESTAMP(base),
+   FW_REG_READ);
+
+   with_intel_runtime_pm(uncore->rpm, wakeref) {
+   spin_lock_irq(>lock);
+   intel_uncore_forcewake_get__locked(uncore, fw_domains);
+
+   ret = __read_timestamps(uncore,
+   RING_TIMESTAMP(base),
+   RING_TIMESTAMP_UDW(base),
+   cs_ts,
+   cpu_ts,
+

[PATCH v2 1/1] drm/i915: Use the correct max source link rate for MST

[why]
Previously used value was not safe to provide the correct value, i.e. it
could be 0 if not not configured, leading to no MST on this platform.

[how]
Do not use the value from BIOS, but from the structure populated at
encoder initialization time.

Fixes: 98025a62cb00 ("drm/dp_mst: Use Extended Base Receiver Capability DPCD 
space")
Signed-off-by: Nikola Cornij 
Reviewed-by: Lyude Paul 
---
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index bf7f8487945c..3642d7578658 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -942,7 +942,7 @@ intel_dp_mst_encoder_init(struct intel_digital_port 
*dig_port, int conn_base_id)
struct intel_dp *intel_dp = _port->dp;
enum port port = dig_port->base.port;
int ret;
-   int bios_max_link_rate;
+   int max_source_rate = intel_dp->source_rates[intel_dp->num_source_rates 
- 1];
 
if (!HAS_DP_MST(i915) || intel_dp_is_edp(intel_dp))
return 0;
@@ -957,11 +957,11 @@ intel_dp_mst_encoder_init(struct intel_digital_port 
*dig_port, int conn_base_id)
 
/* create encoders */
intel_dp_create_fake_mst_encoders(dig_port);
-   bios_max_link_rate = intel_bios_dp_max_link_rate(_port->base);
ret = drm_dp_mst_topology_mgr_init(_dp->mst_mgr, >drm,
   _dp->aux, 16, 3,
   (u8)dig_port->max_lanes,
-  (u8)(bios_max_link_rate / 27000), 
conn_base_id);
+  (u8)(max_source_rate / 27000),
+  conn_base_id);
if (ret)
return ret;
 
-- 
2.25.1

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

[PATCH v2 0/1] drm/i915: Use the correct max source link rate for MST

This is a follow-up change to fix incorrectly used max link rate source 
capability at MST init time.

Change history:

v1:
  - Initial

v2:
  - Use local variabale for improved code readability
  - Fix the comment to point to the correct sub-directory

Nikola Cornij (1):
  drm/i915: Use the correct max source link rate for MST

 drivers/gpu/drm/i915/display/intel_dp_mst.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.25.1

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

Re: [v3 1/2] dt-bindings: backlight: add DisplayPort aux backlight

2021-04-30 Thread Doug Anderson

Hi,

On Fri, Apr 30, 2021 at 8:10 AM  wrote:
>
> On 30-04-2021 02:33, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Apr 29, 2021 at 11:04 AM Rob Herring  wrote:
> >>
> >> On Mon, Apr 26, 2021 at 11:29:15AM +0530, Rajeev Nandan wrote:
> >> > Add bindings for DisplayPort aux backlight driver.
> >> >
> >> > Changes in v2:
> >> > - New
> >> >
> >> > Signed-off-by: Rajeev Nandan 
> >> > ---
> >> >  .../bindings/leds/backlight/dp-aux-backlight.yaml  | 49 
> >> > ++
> >> >  1 file changed, 49 insertions(+)
> >> >  create mode 100644 
> >> > Documentation/devicetree/bindings/leds/backlight/dp-aux-backlight.yaml
> >> >
> >> > diff --git 
> >> > a/Documentation/devicetree/bindings/leds/backlight/dp-aux-backlight.yaml 
> >> > b/Documentation/devicetree/bindings/leds/backlight/dp-aux-backlight.yaml
> >> > new file mode 100644
> >> > index ..0fa8bf0
> >> > --- /dev/null
> >> > +++ 
> >> > b/Documentation/devicetree/bindings/leds/backlight/dp-aux-backlight.yaml
> >> > @@ -0,0 +1,49 @@
> >> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >> > +%YAML 1.2
> >> > +---
> >> > +$id: http://devicetree.org/schemas/leds/backlight/dp-aux-backlight.yaml#
> >> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >> > +
> >> > +title: DisplayPort aux backlight driver bindings
> >> > +
> >> > +maintainers:
> >> > +  - Rajeev Nandan 
> >> > +
> >> > +description:
> >> > +  Backlight driver to control the brightness over DisplayPort aux 
> >> > channel.
> >> > +
> >> > +allOf:
> >> > +  - $ref: common.yaml#
> >> > +
> >> > +properties:
> >> > +  compatible:
> >> > +const: dp-aux-backlight
> >> > +
> >> > +  ddc-i2c-bus:
> >> > +$ref: /schemas/types.yaml#/definitions/phandle
> >> > +description:
> >> > +  A phandle to the system I2C controller connected to the DDC bus 
> >> > used
> >> > +  for the DisplayPort AUX channel.
> >> > +
> >> > +  enable-gpios:
> >> > +maxItems: 1
> >> > +description: GPIO specifier for backlight enable pin.
> >> > +
> >> > +  max-brightness: true
> >> > +
> >> > +required:
> >> > +  - compatible
> >> > +  - ddc-i2c-bus
> >> > +
> >> > +additionalProperties: false
> >> > +
> >> > +examples:
> >> > +  - |
> >> > +backlight {
> >> > +compatible = "dp-aux-backlight";
> >> > +ddc-i2c-bus = <_bridge>;
> >> > +enable-gpios = < 12 GPIO_ACTIVE_HIGH>;
> >>
> >> So the DDC bus is connected to a backlight and also a panel? This
> >> binding is not reflecting the h/w, but rather what you want for some
> >> driver.
> >>
> >> There's only one thing here and that's an eDP panel which supports
> >> backlight control via DP aux channel. You can figure all that out from
> >> the panel's compatible and/or reading the EDID.
> >>
> >> You might also be interested in this thread:
> >>
> >> https://lore.kernel.org/lkml/yiksdtjcihgnv...@orome.fritz.box/
> >
> > I think Rajeev needs to rework everything anyway as per:
> >
> > https://lore.kernel.org/r/87zgxl5qar@intel.com
> >
> > ...but you're right that it makes sense not to model the backlight as
> > a separate node in the device tree. The panel driver can handle
> > setting up the backlight.
> >
> > -Doug
>
> It was not a good idea to create a separate backlight driver and use
> ddc-i2c-bus to get access to DP aux. I am working to move the code
> to the panel driver and to utilize the new DRM helper functions
> (drm_edp_backlight_*) Lyude has added [1].
>
> To use these helper functions, the panel driver should have access to
> the
> "struct drm_dp_aux *". The simple-panel has a "ddc-i2c-bus" property
> to give the panel access to the DDC bus and is currently being used to
> get the EDID from the panel. Can I use the same ddc bus i2c_adapter to
> get
> the "struct drm_dp_aux *"?
>
> As per the suggestion [2], I get the "struct drm_dp_aux *" from the
> i2c_adapter of ddc bus (maybe I didn't understand the suggestion
> correctly),
> and, it turned out, the way I have implemented is not the right way [3].
> So, I am afraid to use the same method in the panel driver.
>
>
> [1] https://lore.kernel.org/dri-devel/871rb5bcf9@intel.com/
> [2] https://www.spinics.net/lists/dri-devel/msg295429.html
> [3]
> https://lore.kernel.org/dri-devel/2021042616.4lc3ekxjugjr3...@maple.lan/

So it's definitely up to maintainers, not me. ...but I guess I would
have expected something like a new property called "ddc-aux-bus". Then
you'd have to create a new API call called something like
"of_find_ddc_aux_adapter_by_node()" that would allow you to find it.

I guess an alternate way to solve this (I'm not totally sure whether
it's better or worse) would be to add a function that would walk up
the chain of parent bridges and ask them for a pointer to the aux bus.
I definitely haven't thought it all the way through, but I'd imagine
something like drm_bridge_chain_get_ddc_aux(). This is _probably_
better than adding the "ddc-aux-bus" property but it assumes that the
aux bus is provided by one of

Re: [PATCH v1 1/1] drm/dp_mst: Use the correct max source link rate for i915

On Fri, 2021-04-30 at 17:22 -0400, Nikola Cornij wrote:
> [why]
> Previously used value was not safe to provide the correct value, i.e. it
> could be 0 if not not configured, leading to no MST on this platform.
> 
> [how]
> Do not use the value from BIOS, but from the structure populated at
> encoder initialization time.
> 
> Fixes: 98025a62cb00 ("drm/dp_mst: Use Extended Base Receiver Capability DPCD
> space")
> Signed-off-by: Nikola Cornij 
> ---
>  drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index bf7f8487945c..01a0ed99988f 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -942,7 +942,6 @@ intel_dp_mst_encoder_init(struct intel_digital_port
> *dig_port, int conn_base_id)
> struct intel_dp *intel_dp = _port->dp;
> enum port port = dig_port->base.port;
> int ret;
> -   int bios_max_link_rate;
>  
> if (!HAS_DP_MST(i915) || intel_dp_is_edp(intel_dp))
> return 0;
> @@ -957,11 +956,11 @@ intel_dp_mst_encoder_init(struct intel_digital_port
> *dig_port, int conn_base_id)
>  
> /* create encoders */
> intel_dp_create_fake_mst_encoders(dig_port);
> -   bios_max_link_rate = intel_bios_dp_max_link_rate(_port->base);
> ret = drm_dp_mst_topology_mgr_init(_dp->mst_mgr, >drm,
>    _dp->aux, 16, 3,
>    (u8)dig_port->max_lanes,
> -  (u8)(bios_max_link_rate / 27000),
> conn_base_id);
> +  (u8)(intel_dp-
> >source_rates[intel_dp->num_source_rates - 1] / 27000),
> +  conn_base_id);

This line is kind of long, I'd say we should just store the max link rate in a
local variable like max_link_rate, then just pass that to
drm_dp_mst_topology_mgr_init()

Also, the commit message should probably be:

drm/i915: Use the correct max source link rate for MST

With those two things fixed:

Reviewed-by: Lyude Paul 

> if (ret)
> return ret;
>  

-- 
Sincerely,
   Lyude Paul (she/her)
   Software Engineer at Red Hat
   
Note: I deal with a lot of emails and have a lot of bugs on my plate. If you've
asked me a question, are waiting for a review/merge on a patch, etc. and I
haven't responded in a while, please feel free to send me another email to check
on my status. I don't bite!

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

[PATCH v1 1/1] drm/dp_mst: Use the correct max source link rate for i915

[why]
Previously used value was not safe to provide the correct value, i.e. it
could be 0 if not not configured, leading to no MST on this platform.

[how]
Do not use the value from BIOS, but from the structure populated at
encoder initialization time.

Fixes: 98025a62cb00 ("drm/dp_mst: Use Extended Base Receiver Capability DPCD 
space")
Signed-off-by: Nikola Cornij 
---
 drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c 
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index bf7f8487945c..01a0ed99988f 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -942,7 +942,6 @@ intel_dp_mst_encoder_init(struct intel_digital_port 
*dig_port, int conn_base_id)
struct intel_dp *intel_dp = _port->dp;
enum port port = dig_port->base.port;
int ret;
-   int bios_max_link_rate;
 
if (!HAS_DP_MST(i915) || intel_dp_is_edp(intel_dp))
return 0;
@@ -957,11 +956,11 @@ intel_dp_mst_encoder_init(struct intel_digital_port 
*dig_port, int conn_base_id)
 
/* create encoders */
intel_dp_create_fake_mst_encoders(dig_port);
-   bios_max_link_rate = intel_bios_dp_max_link_rate(_port->base);
ret = drm_dp_mst_topology_mgr_init(_dp->mst_mgr, >drm,
   _dp->aux, 16, 3,
   (u8)dig_port->max_lanes,
-  (u8)(bios_max_link_rate / 27000), 
conn_base_id);
+  
(u8)(intel_dp->source_rates[intel_dp->num_source_rates - 1] / 27000),
+  conn_base_id);
if (ret)
return ret;
 
-- 
2.25.1

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

[PATCH v1 0/1] drm/dp_mst: Use the correct max source link rate for i915

This is a follow-up change to fix incorrectly used max link rate source
capability at MST init time.

Change history:

v1:
  - Initial

Nikola Cornij (1):
  drm/dp_mst: Use the correct max source link rate for i915

 drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

-- 
2.25.1

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

Re: [PATCH v5 01/20] drm/panel: panel-simple: Add missing pm_runtime_disable() calls

2021-04-30 Thread Doug Anderson

Hi,

On Thu, Apr 29, 2021 at 6:28 PM Linus Walleij  wrote:
>
> On Fri, Apr 30, 2021 at 3:25 AM Doug Anderson  wrote:
>
> > > I think pm_runtime_disable(); need to be added there?
> >
> > I'm a bit confused. You're saying that I need to add
> > pm_runtime_disable() to panel_simple_remove()? Doesn't this patch do
> > that?
>
> It does, sorry, too late at night :D
>
> I was looking at the previous patch and mixed up which was the
> patch and the patch to the patch...
>
> Thanks, apply this!

Pushed this one patch. Rest of the series is pending adult
supervision. Overall summary:

1. I could probably push some of the early sn65dsi86 cleanup patches
in this series since they have Bjorn's review and are pretty much
no-ops / simple cleanups, but there's probably not tons gained for
shoving those in early.

2. The whole concept of breaking up the patch into sub-drivers has no
official Reviewed-by tags yet. Presumably Bjorn will give those a
re-review when he has time again. Assuming nobody is really upset
about it, I could land those which might unblock some of Bjorn's
future PWM work. It would probably be good to get an extra set of eyes
on them, though, just so someone else agrees that they're not "too
hacky" or anything. IMO it's actually a pretty nice solution, but I'm
biased!

3. Laurent and I had a big discussion on #dri-devel yesterday about
the EDID reading. He's not totally convinced with the idea of doing
this in the panel when the bridge could just do it by itself, but it
sounded like he might be coming around. Right now this is waiting on
Laurent to have time to get back to this.

My summary of the IRC discussion with Laurent (please correct if I got
this wrong):

a) In general I argued that it was important to be able to provide the
EDID and the DDC bus to the panel driver. Providing the EDID to the
panel driver allows the panel driver is one of the prerequisites for
my proposal for solving the "panel second sourcing" problem [1]. Being
able to provide the DDC bus to the panel will likely be important in
the eventual solution to Rajeev's problem [2].

b) Today, if we provide the DDC bus to simple-panel then simple-panel
will assume it's in charge of reading the EDID.

c) Having the panel driver involved in reading the EDID feels like it
makes sense to me. The panel driver knows how to power the panel on
enough to read the EDID. It also might know extra quirks needed to
read the EDID on a given panel. This feels a little cleaner (to me)
than just re-using the panel's "prepare" and assuming that a prepared
panel was ready for EDID read, though I can see that both may have
their advantages.

d) Laurent proposed that some eDP controllers might have special ways
to read an EDID but might not be able to provide a DDC bus or an i2c
bus. If we run into controllers like this then we would be painted
into a corner and we'd have to come up with a new solution. This is
definitely a good point, though it remains to be seen if this is
common with eDP (like Laurent says it is for HDMI). Some eDP panels
need custom DDC commands in order to be configured and so hopefully
all eDP bridges out there at least provide a DDC bus. It does feel
like this could be solved later, though. My patch series is leveraging
the existing concept that the panel driver is in charge of reading the
EDID if it's given the DDC bus, so it's not creating a new mechanism
but instead just continuing to use the existing mechanism. If the
existing mechanism doesn't work then it can be improved when there is
a need.

e) Laurent worried about circular dependencies and wanted to see my
solution to the problem before deciding if it was too big of a hack.
Hopefully it looks OK since it solves not only this problem but also
the HPD GPIO problem and will be important for when Bjorn exports the
PWM from the bridge chip.

[1] 
https://lore.kernel.org/lkml/CAD=FV=vzyompwqzzwdhjgh5cjjww_ecm-wqveivz-bdgxjp...@mail.gmail.com/
[2] https://lore.kernel.org/r/78c4bd291bd4a17ae2a1d02d0217d...@codeaurora.org

OK, I'll shut up now. ;-)

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

Re: [PATCH 0/2] clk: Implement a clock request API

Quoting Maxime Ripard (2021-04-13 03:13:18)
> Hi,
> 
> This is a follow-up of the discussion here:
> https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmour/
> 
> This implements a mechanism to raise and lower clock rates based on consumer
> workloads, with an example of such an implementation for the RaspberryPi4 HDMI
> controller.
> 
> There's a couple of things worth discussing:
> 
>   - The name is in conflict with clk_request_rate, and even though it feels
> like the right name to me, we should probably avoid any confusion
> 
>   - The code so far implements a policy of always going for the lowest rate
> possible. While we don't have an use-case for something else, this should
> maybe be made more flexible?

I'm definitely confused how it is different from the
clk_set_rate_exclusive() API and associated
clk_rate_exclusive_get()/clk_rate_exclusive_put(). Can you explain
further the differences in the cover letter here?

> 
> Let me know what you think
> Maxime
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RESEND PATCH v6 3/4] mfd: rt4831: Adds DT binding document for Richtek RT4831

2021-04-30 Thread Rob Herring

On Mon, 26 Apr 2021 15:18:10 +0800, cy_huang wrote:
> From: ChiYuan Huang 
> 
> Adds DT binding document for Richtek RT4831.
> 
> Signed-off-by: ChiYuan Huang 
> ---
> Resend this v6 patch series to loop devicetree reviewers.
> ---
>  .../devicetree/bindings/mfd/richtek,rt4831.yaml| 90 
> ++
>  1 file changed, 90 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/richtek,rt4831.yaml
> 

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

Re: [RESEND PATCH v6 2/4] backlight: rt4831: Adds DT binding document for Richtek RT4831 backlight

2021-04-30 Thread Rob Herring

On Mon, Apr 26, 2021 at 03:18:09PM +0800, cy_huang wrote:
> From: ChiYuan Huang 
> 
> Adds DT binding document for Richtek RT4831 backlight.
> 
> Signed-off-by: ChiYuan Huang 
> Reviewed-by: Daniel Thompson 
> ---
> Resend this v6 patch series to loop devicetree reviewers.
> 
> For next, need to add the below line
> Reviewed-by: Daniel Thompson 
> ---
>  .../leds/backlight/richtek,rt4831-backlight.yaml   | 65 
> ++
>  include/dt-bindings/leds/rt4831-backlight.h| 23 
>  2 files changed, 88 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml
>  create mode 100644 include/dt-bindings/leds/rt4831-backlight.h
> 
> diff --git 
> a/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml
>  
> b/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml
> new file mode 100644
> index ..4da6a66
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml
> @@ -0,0 +1,65 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: 
> http://devicetree.org/schemas/leds/backlight/richtek,rt4831-backlight.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Richtek RT4831 Backlight
> +
> +maintainers:
> +  - ChiYuan Huang 
> +
> +description: |
> +  RT4831 is a mutifunctional device that can provide power to the LCD display
> +  and LCD backlight.
> +
> +  For the LCD backlight, it can provide four channel WLED driving capability.
> +  Each channel driving current is up to 30mA
> +
> +  Datasheet is available at
> +  https://www.richtek.com/assets/product_file/RT4831A/DS4831A-05.pdf
> +

Need to reference common backlight schema:

allOf:
  - $ref: common.yaml#

> +properties:
> +  compatible:
> +const: richtek,rt4831-backlight
> +
> +  default-brightness:
> +description: |
> +  The default brightness that applied to the system on start-up.
> +$ref: /schemas/types.yaml#/definitions/uint32

Drop description and $ref. Covered in common.yaml.

> +minimum: 0
> +maximum: 2048
> +
> +  max-brightness:
> +description: |
> +  The max brightness for the H/W limit
> +$ref: /schemas/types.yaml#/definitions/uint32

And here.

> +minimum: 0
> +maximum: 2048
> +
> +  richtek,pwm-enable:
> +description: |
> +  Specify the backlight dimming following by PWM duty or by SW control.
> +type: boolean
> +
> +  richtek,bled-ovp-sel:
> +description: |
> +  Backlight OVP level selection, currently support 17V/21V/25V/29V.
> +$ref: /schemas/types.yaml#/definitions/uint8
> +default: 1
> +minimum: 0
> +maximum: 3
> +
> +  richtek,channel-use:
> +description: |
> +  Backlight LED channel to be used.
> +  BIT 0/1/2/3 is used to indicate led channel 1/2/3/4 enable or disable.
> +$ref: /schemas/types.yaml#/definitions/uint8
> +minimum: 1
> +maximum: 15
> +
> +required:
> +  - compatible
> +  - richtek,channel-use
> +
> +additionalProperties: false
> diff --git a/include/dt-bindings/leds/rt4831-backlight.h 
> b/include/dt-bindings/leds/rt4831-backlight.h
> new file mode 100644
> index ..125c635
> --- /dev/null
> +++ b/include/dt-bindings/leds/rt4831-backlight.h
> @@ -0,0 +1,23 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/*
> + * This header provides constants for rt4831 backlight bindings.
> + *
> + * Copyright (C) 2020, Richtek Technology Corp.
> + * Author: ChiYuan Huang 
> + */
> +
> +#ifndef _DT_BINDINGS_RT4831_BACKLIGHT_H
> +#define _DT_BINDINGS_RT4831_BACKLIGHT_H
> +
> +#define RT4831_BLOVPLVL_17V  0
> +#define RT4831_BLOVPLVL_21V  1
> +#define RT4831_BLOVPLVL_25V  2
> +#define RT4831_BLOVPLVL_29V  3
> +
> +#define RT4831_BLED_CH1EN(1 << 0)
> +#define RT4831_BLED_CH2EN(1 << 1)
> +#define RT4831_BLED_CH3EN(1 << 2)
> +#define RT4831_BLED_CH4EN(1 << 3)
> +#define RT4831_BLED_ALLCHEN  ((1 << 4) - 1)
> +
> +#endif /* _DT_BINDINGS_RT4831_BACKLIGHT_H */
> -- 
> 2.7.4
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm tegra-next + fixes for 5.13-rc1

2021-04-30 Thread pr-tracker-bot

The pull request you sent on Fri, 30 Apr 2021 13:50:25 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-next-2021-04-30

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/95275402f66e88c56144a2d859c13594b651b29b

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/6] drm/msm/disp: Move various debug logs to atomic bucket

These prints flood the logs with drm debugging set to enable kms and
driver logging (DRM_UT_KMS and DRM_UT_DRIVER). Let's move these prints
to the atomic bucket (DRM_UT_ATOMIC) as they're related to the atomic
paths.

Cc: Dmitry Baryshkov 
Cc: Abhinav Kumar 
Cc: Kuogee Hsieh 
Cc: aravi...@codeaurora.org
Cc: Sean Paul 
Signed-off-by: Stephen Boyd 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 22 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  | 38 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   | 10 ++---
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c   |  6 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c |  2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c  | 14 +++
 6 files changed, 44 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index b6b3bbab0333..8bbba5a44d82 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
@@ -132,7 +132,7 @@ static void _dpu_core_perf_calc_crtc(struct dpu_kms *kms,
perf->core_clk_rate = _dpu_core_perf_calc_clk(kms, crtc, state);
}
 
-   DPU_DEBUG(
+   DRM_DEBUG_ATOMIC(
"crtc=%d clk_rate=%llu core_ib=%llu core_ab=%llu\n",
crtc->base.id, perf->core_clk_rate,
perf->max_per_pipe_ib, perf->bw_ctl);
@@ -178,7 +178,7 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
struct dpu_crtc_state *tmp_cstate =
to_dpu_crtc_state(tmp_crtc->state);
 
-   DPU_DEBUG("crtc:%d bw:%llu ctrl:%d\n",
+   DRM_DEBUG_ATOMIC("crtc:%d bw:%llu ctrl:%d\n",
tmp_crtc->base.id, tmp_cstate->new_perf.bw_ctl,
tmp_cstate->bw_control);
 
@@ -187,11 +187,11 @@ int dpu_core_perf_crtc_check(struct drm_crtc *crtc,
 
/* convert bandwidth to kb */
bw = DIV_ROUND_UP_ULL(bw_sum_of_intfs, 1000);
-   DPU_DEBUG("calculated bandwidth=%uk\n", bw);
+   DRM_DEBUG_ATOMIC("calculated bandwidth=%uk\n", bw);
 
threshold = kms->catalog->perf.max_bw_high;
 
-   DPU_DEBUG("final threshold bw limit = %d\n", threshold);
+   DRM_DEBUG_ATOMIC("final threshold bw limit = %d\n", threshold);
 
if (!threshold) {
DPU_ERROR("no bandwidth limits specified\n");
@@ -228,7 +228,7 @@ static int _dpu_core_perf_crtc_update_bus(struct dpu_kms 
*kms,
 
perf.bw_ctl += dpu_cstate->new_perf.bw_ctl;
 
-   DPU_DEBUG("crtc=%d bw=%llu paths:%d\n",
+   DRM_DEBUG_ATOMIC("crtc=%d bw=%llu paths:%d\n",
  tmp_crtc->base.id,
  dpu_cstate->new_perf.bw_ctl, kms->num_paths);
}
@@ -278,7 +278,7 @@ void dpu_core_perf_crtc_release_bw(struct drm_crtc *crtc)
/* Release the bandwidth */
if (kms->perf.enable_bw_release) {
trace_dpu_cmd_release_bw(crtc->base.id);
-   DPU_DEBUG("Release BW crtc=%d\n", crtc->base.id);
+   DRM_DEBUG_ATOMIC("Release BW crtc=%d\n", crtc->base.id);
dpu_crtc->cur_perf.bw_ctl = 0;
_dpu_core_perf_crtc_update_bus(kms, crtc);
}
@@ -314,7 +314,7 @@ static u64 _dpu_core_perf_get_core_clk_rate(struct dpu_kms 
*kms)
if (kms->perf.perf_tune.mode == DPU_PERF_MODE_FIXED)
clk_rate = kms->perf.fix_core_clk_rate;
 
-   DPU_DEBUG("clk:%llu\n", clk_rate);
+   DRM_DEBUG_ATOMIC("clk:%llu\n", clk_rate);
 
return clk_rate;
 }
@@ -344,7 +344,7 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
dpu_crtc = to_dpu_crtc(crtc);
dpu_cstate = to_dpu_crtc_state(crtc->state);
 
-   DPU_DEBUG("crtc:%d stop_req:%d core_clk:%llu\n",
+   DRM_DEBUG_ATOMIC("crtc:%d stop_req:%d core_clk:%llu\n",
crtc->base.id, stop_req, kms->perf.core_clk_rate);
 
old = _crtc->cur_perf;
@@ -362,7 +362,7 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
(new->max_per_pipe_ib > old->max_per_pipe_ib))) ||
(!params_changed && ((new->bw_ctl < old->bw_ctl) ||
(new->max_per_pipe_ib < old->max_per_pipe_ib {
-   DPU_DEBUG("crtc=%d p=%d new_bw=%llu,old_bw=%llu\n",
+   DRM_DEBUG_ATOMIC("crtc=%d p=%d 
new_bw=%llu,old_bw=%llu\n",
crtc->base.id, params_changed,
new->bw_ctl, old->bw_ctl);
old->bw_ctl = new->bw_ctl;
@@ -378,7 +378,7 @@ int dpu_core_perf_crtc_update(struct drm_crtc *crtc,
update_clk = true;
}
} else {
-   DPU_DEBUG("crtc=%d

[PATCH 1/6] drm/msm: Move vblank debug prints to drm_dbg_vbl()

Put these debug prints in the vblank code into the appropriate vblank
category via drm_dbg_vbl().

Cc: Dmitry Baryshkov 
Cc: Abhinav Kumar 
Cc: Kuogee Hsieh 
Cc: aravi...@codeaurora.org
Cc: Sean Paul 
Signed-off-by: Stephen Boyd 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 2 +-
 drivers/gpu/drm/msm/msm_drv.c| 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
index 9a69fad832cd..9bb2d13a1f44 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c
@@ -416,7 +416,7 @@ static int dpu_encoder_phys_vid_control_vblank_irq(
goto end;
}
 
-   DRM_DEBUG_KMS("id:%u enable=%d/%d\n", DRMID(phys_enc->parent), enable,
+   DRM_DEBUG_VBL("id:%u enable=%d/%d\n", DRMID(phys_enc->parent), enable,
  atomic_read(_enc->vblank_refcount));
 
if (enable && atomic_inc_return(_enc->vblank_refcount) == 1)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 196907689c82..ad79c37d4df9 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -683,7 +683,7 @@ int msm_crtc_enable_vblank(struct drm_crtc *crtc)
struct msm_kms *kms = priv->kms;
if (!kms)
return -ENXIO;
-   DBG("dev=%p, crtc=%u", dev, pipe);
+   drm_dbg_vbl(dev, "crtc=%u", pipe);
return vblank_ctrl_queue_work(priv, pipe, true);
 }
 
@@ -695,7 +695,7 @@ void msm_crtc_disable_vblank(struct drm_crtc *crtc)
struct msm_kms *kms = priv->kms;
if (!kms)
return;
-   DBG("dev=%p, crtc=%u", dev, pipe);
+   drm_dbg_vbl(dev, "crtc=%u", pipe);
vblank_ctrl_queue_work(priv, pipe, false);
 }
 
-- 
https://chromeos.dev

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

[PATCH 5/6] drm/msm/disp: Use plane debug print helper

Use the DPU_DEBUG_PLANE() helper to print the plane number instead of
open coding it.

Cc: Dmitry Baryshkov 
Cc: Abhinav Kumar 
Cc: Kuogee Hsieh 
Cc: aravi...@codeaurora.org
Cc: Sean Paul 
Signed-off-by: Stephen Boyd 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index f898a8f67b7f..3f5626832c9e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -283,8 +283,8 @@ static int _dpu_plane_calc_fill_level(struct drm_plane 
*plane,
}
}
 
-   DPU_DEBUG("plane%u: pnum:%d fmt: %4.4s w:%u fl:%u\n",
-   plane->base.id, pdpu->pipe - SSPP_VIG0,
+   DPU_DEBUG_PLANE(pdpu, "pnum:%d fmt: %4.4s w:%u fl:%u\n",
+   pdpu->pipe - SSPP_VIG0,
(char *)>base.pixel_format,
src_width, total_fl);
 
@@ -353,8 +353,7 @@ static void _dpu_plane_set_qos_lut(struct drm_plane *plane,
(fmt) ? fmt->base.pixel_format : 0,
pdpu->is_rt_pipe, total_fl, qos_lut, lut_usage);
 
-   DPU_DEBUG("plane%u: pnum:%d fmt: %4.4s rt:%d fl:%u lut:0x%llx\n",
-   plane->base.id,
+   DPU_DEBUG_PLANE(pdpu, "pnum:%d fmt: %4.4s rt:%d fl:%u lut:0x%llx\n",
pdpu->pipe - SSPP_VIG0,
fmt ? (char *)>base.pixel_format : NULL,
pdpu->is_rt_pipe, total_fl, qos_lut);
@@ -406,8 +405,7 @@ static void _dpu_plane_set_danger_lut(struct drm_plane 
*plane,
pdpu->pipe_qos_cfg.danger_lut,
pdpu->pipe_qos_cfg.safe_lut);
 
-   DPU_DEBUG("plane%u: pnum:%d fmt: %4.4s mode:%d luts[0x%x, 0x%x]\n",
-   plane->base.id,
+   DPU_DEBUG_PLANE(pdpu, "pnum:%d fmt: %4.4s mode:%d luts[0x%x, 0x%x]\n",
pdpu->pipe - SSPP_VIG0,
fmt ? (char *)>base.pixel_format : NULL,
fmt ? fmt->fetch_mode : -1,
@@ -450,8 +448,7 @@ static void _dpu_plane_set_qos_ctrl(struct drm_plane *plane,
pdpu->pipe_qos_cfg.danger_safe_en = false;
}
 
-   DPU_DEBUG("plane%u: pnum:%d ds:%d vb:%d pri[0x%x, 0x%x] is_rt:%d\n",
-   plane->base.id,
+   DPU_DEBUG_PLANE(pdpu, "pnum:%d ds:%d vb:%d pri[0x%x, 0x%x] is_rt:%d\n",
pdpu->pipe - SSPP_VIG0,
pdpu->pipe_qos_cfg.danger_safe_en,
pdpu->pipe_qos_cfg.vblank_en,
@@ -506,8 +503,8 @@ static void _dpu_plane_set_qos_remap(struct drm_plane 
*plane)
qos_params.num = pdpu->pipe_hw->idx - SSPP_VIG0;
qos_params.is_rt = pdpu->is_rt_pipe;
 
-   DPU_DEBUG("plane%d pipe:%d vbif:%d xin:%d rt:%d, clk_ctrl:%d\n",
-   plane->base.id, qos_params.num,
+   DPU_DEBUG_PLANE(pdpu, "pipe:%d vbif:%d xin:%d rt:%d, clk_ctrl:%d\n",
+   qos_params.num,
qos_params.vbif_idx,
qos_params.xin_id, qos_params.is_rt,
qos_params.clk_ctrl);
-- 
https://chromeos.dev

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

[PATCH 2/6] drm/msm: Use VERB() for extra verbose logging

These messages are useful for bringup/early development but in
production they don't provide much value. We know what sort of GPU we
have and interrupt information can be gathered other ways. This cuts
down on lines in the drm debug logs that happen too often, making the
debug logs practically useless.

Cc: Dmitry Baryshkov 
Cc: Abhinav Kumar 
Cc: Kuogee Hsieh 
Cc: aravi...@codeaurora.org
Cc: Sean Paul 
Signed-off-by: Stephen Boyd 
---
 drivers/gpu/drm/msm/adreno/adreno_gpu.c  |  2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 16 
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 0f184c3dd9d9..b5072cec982d 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -408,7 +408,7 @@ int adreno_hw_init(struct msm_gpu *gpu)
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
int ret, i;
 
-   DBG("%s", gpu->name);
+   VERB("%s", gpu->name);
 
ret = adreno_load_fw(adreno_gpu);
if (ret)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
index 84ea09d9692f..cad65ec2acac 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c
@@ -24,7 +24,7 @@ static void dpu_core_irq_callback_handler(void *arg, int 
irq_idx)
struct dpu_irq_callback *cb;
unsigned long irq_flags;
 
-   pr_debug("irq_idx=%d\n", irq_idx);
+   VERB("irq_idx=%d\n", irq_idx);
 
if (list_empty(_obj->irq_cb_tbl[irq_idx])) {
DRM_ERROR("no registered cb, idx:%d enable_count:%d\n", irq_idx,
@@ -85,7 +85,7 @@ static int _dpu_core_irq_enable(struct dpu_kms *dpu_kms, int 
irq_idx)
}
 
enable_count = atomic_read(_kms->irq_obj.enable_counts[irq_idx]);
-   DRM_DEBUG_KMS("irq_idx=%d enable_count=%d\n", irq_idx, enable_count);
+   VERB("irq_idx=%d enable_count=%d\n", irq_idx, enable_count);
trace_dpu_core_irq_enable_idx(irq_idx, enable_count);
 
if (atomic_inc_return(_kms->irq_obj.enable_counts[irq_idx]) == 1) {
@@ -96,7 +96,7 @@ static int _dpu_core_irq_enable(struct dpu_kms *dpu_kms, int 
irq_idx)
DPU_ERROR("Fail to enable IRQ for irq_idx:%d\n",
irq_idx);
 
-   DPU_DEBUG("irq_idx=%d ret=%d\n", irq_idx, ret);
+   VERB("irq_idx=%d ret=%d\n", irq_idx, ret);
 
spin_lock_irqsave(_kms->irq_obj.cb_lock, irq_flags);
/* empty callback list but interrupt is enabled */
@@ -120,7 +120,7 @@ int dpu_core_irq_enable(struct dpu_kms *dpu_kms, int 
*irq_idxs, u32 irq_count)
 
counts = atomic_read(_kms->irq_obj.enable_counts[irq_idxs[0]]);
if (counts)
-   DRM_ERROR("irq_idx=%d enable_count=%d\n", irq_idxs[0], counts);
+   VERB("irq_idx=%d enable_count=%d\n", irq_idxs[0], counts);
 
for (i = 0; (i < irq_count) && !ret; i++)
ret = _dpu_core_irq_enable(dpu_kms, irq_idxs[i]);
@@ -148,7 +148,7 @@ static int _dpu_core_irq_disable(struct dpu_kms *dpu_kms, 
int irq_idx)
}
 
enable_count = atomic_read(_kms->irq_obj.enable_counts[irq_idx]);
-   DRM_DEBUG_KMS("irq_idx=%d enable_count=%d\n", irq_idx, enable_count);
+   VERB("irq_idx=%d enable_count=%d\n", irq_idx, enable_count);
trace_dpu_core_irq_disable_idx(irq_idx, enable_count);
 
if (atomic_dec_return(_kms->irq_obj.enable_counts[irq_idx]) == 0) {
@@ -158,7 +158,7 @@ static int _dpu_core_irq_disable(struct dpu_kms *dpu_kms, 
int irq_idx)
if (ret)
DPU_ERROR("Fail to disable IRQ for irq_idx:%d\n",
irq_idx);
-   DPU_DEBUG("irq_idx=%d ret=%d\n", irq_idx, ret);
+   VERB("irq_idx=%d ret=%d\n", irq_idx, ret);
}
 
return ret;
@@ -222,7 +222,7 @@ int dpu_core_irq_register_callback(struct dpu_kms *dpu_kms, 
int irq_idx,
return -EINVAL;
}
 
-   DPU_DEBUG("[%pS] irq_idx=%d\n", __builtin_return_address(0), irq_idx);
+   VERB("[%pS] irq_idx=%d\n", __builtin_return_address(0), irq_idx);
 
spin_lock_irqsave(_kms->irq_obj.cb_lock, irq_flags);
trace_dpu_core_irq_register_callback(irq_idx, register_irq_cb);
@@ -257,7 +257,7 @@ int dpu_core_irq_unregister_callback(struct dpu_kms 
*dpu_kms, int irq_idx,
return -EINVAL;
}
 
-   DPU_DEBUG("[%pS] irq_idx=%d\n", __builtin_return_address(0), irq_idx);
+   VERB("[%pS] irq_idx=%d\n", __builtin_return_address(0), irq_idx);
 
spin_lock_irqsave(_kms->irq_obj.cb_lock, irq_flags);
trace_dpu_core_irq_unregister_callback(irq_idx, register_irq_cb);
-- 
https://chromeos.dev

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

[PATCH 4/6] drm/msm: Move FB debug prints to drm_dbg_state()

These are verbose prints that tell us about the framebuffer state. Let's
move them to drm_dbg_state() so that they're only printed if we're
interested in verbose state logging while drm debugging.

Cc: Dmitry Baryshkov 
Cc: Abhinav Kumar 
Cc: Kuogee Hsieh 
Cc: aravi...@codeaurora.org
Cc: Sean Paul 
Signed-off-by: Stephen Boyd 
---
 drivers/gpu/drm/msm/msm_fb.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_fb.c b/drivers/gpu/drm/msm/msm_fb.c
index d42f0665359a..90514d3179bb 100644
--- a/drivers/gpu/drm/msm/msm_fb.c
+++ b/drivers/gpu/drm/msm/msm_fb.c
@@ -60,7 +60,7 @@ int msm_framebuffer_prepare(struct drm_framebuffer *fb,
 
for (i = 0; i < n; i++) {
ret = msm_gem_get_and_pin_iova(fb->obj[i], aspace, );
-   DBG("FB[%u]: iova[%d]: %08llx (%d)", fb->base.id, i, iova, ret);
+   drm_dbg_state(fb->dev, "FB[%u]: iova[%d]: %08llx (%d)", 
fb->base.id, i, iova, ret);
if (ret)
return ret;
}
@@ -139,8 +139,8 @@ static struct drm_framebuffer *msm_framebuffer_init(struct 
drm_device *dev,
const struct msm_format *format;
int ret, i, n;
 
-   DBG("create framebuffer: dev=%p, mode_cmd=%p (%dx%d@%4.4s)",
-   dev, mode_cmd, mode_cmd->width, mode_cmd->height,
+   drm_dbg_state(dev, "create framebuffer: mode_cmd=%p (%dx%d@%4.4s)",
+   mode_cmd, mode_cmd->width, mode_cmd->height,
(char *)_cmd->pixel_format);
 
n = info->num_planes;
@@ -193,7 +193,7 @@ static struct drm_framebuffer *msm_framebuffer_init(struct 
drm_device *dev,
goto fail;
}
 
-   DBG("create: FB ID: %d (%p)", fb->base.id, fb);
+   drm_dbg_state(dev, "create: FB ID: %d (%p)", fb->base.id, fb);
 
return fb;
 
-- 
https://chromeos.dev

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

[PATCH 0/6] drm/msm: Trim down drm debugging logs

This patch series attempts to trim down the drm logging in the msm
driver to make it useable with DRM_UT_DRIVER, DRM_UT_KMS, and DRM_UT_DP
levels enabled. Right now the log is really spammy and prints multiple
lines for what feels like every frame. I moved those prints off to
other DRM_UT_* levels that felt appropriate. Please review.

Cc: Dmitry Baryshkov 
Cc: Abhinav Kumar 
Cc: Kuogee Hsieh 
Cc: aravi...@codeaurora.org
Cc: Sean Paul 

Stephen Boyd (6):
  drm/msm: Move vblank debug prints to drm_dbg_vbl()
  drm/msm: Use VERB() for extra verbose logging
  drm/msm/dp: Drop malformed debug print
  drm/msm: Move FB debug prints to drm_dbg_state()
  drm/msm/disp: Use plane debug print helper
  drm/msm/disp: Move various debug logs to atomic bucket

 drivers/gpu/drm/msm/adreno/adreno_gpu.c   |  2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c  | 16 
 drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 22 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  | 38 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c   | 10 ++---
 .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c  |  2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c   |  6 +--
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 19 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c  | 14 +++
 drivers/gpu/drm/msm/dp/dp_panel.c |  1 -
 drivers/gpu/drm/msm/msm_drv.c |  4 +-
 drivers/gpu/drm/msm/msm_fb.c  |  8 ++--
 12 files changed, 67 insertions(+), 75 deletions(-)


base-commit: 9f4ad9e425a1d3b6a34617b8ea226d56a119a717
-- 
https://chromeos.dev

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

[PATCH 3/6] drm/msm/dp: Drop malformed debug print

This print is missing a newline, and doesn't really provide any value.
Drop it.

Cc: Dmitry Baryshkov 
Cc: Abhinav Kumar 
Cc: Kuogee Hsieh 
Cc: aravi...@codeaurora.org
Cc: Sean Paul 
Signed-off-by: Stephen Boyd 
---
 drivers/gpu/drm/msm/dp/dp_panel.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dp/dp_panel.c 
b/drivers/gpu/drm/msm/dp/dp_panel.c
index 9cc816663668..88196f7e4406 100644
--- a/drivers/gpu/drm/msm/dp/dp_panel.c
+++ b/drivers/gpu/drm/msm/dp/dp_panel.c
@@ -141,7 +141,6 @@ static int dp_panel_update_modes(struct drm_connector 
*connector,
return rc;
}
rc = drm_add_edid_modes(connector, edid);
-   DRM_DEBUG_DP("%s -", __func__);
return rc;
}
 
-- 
https://chromeos.dev

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

Re: [v3 2/2] backlight: Add DisplayPort aux backlight driver

JFYI for anyone who is interested, I will be respinning my patches for adding
backlight helpers very soon since we've got pretty much all of the prep work
for it upstream now

On Mon, 2021-04-26 at 12:49 +0300, Jani Nikula wrote:
> On Mon, 26 Apr 2021, Rajeev Nandan  wrote:
> > Add backlight driver for the panels supporting backlight control
> > using DPCD registers on the DisplayPort aux channel.
> 
> No, please don't do this.
> 
> I wrote you last week in reply to v1 why I thought merging this would
> not be a good idea [1]. Why have you sent two versions since then
> without replying to me, or Cc'ing me or Lyude?
> 
> I think it's an even worse idea to merge this to
> drivers/video/backlight. With DP AUX backlight you can't pretend it's
> just an independent aux interface for backlight without everything else
> around it. It's not independent of eDP, and exposing it as a direct
> backlight sysfs interface bypasses the encoder.
> 
> And it still remains that there is existing DP AUX backlight code in
> use, in the tree, with more features than this, with plans and
> previously submitted patches to lift from one driver to drm core, and
> with patches to add support to another driver.
> 
> I don't say this lightly, or very often at all, but,
> 
> NAK.
> 
> 
> BR,
> Jani.
> 
> 
> [1] https://lore.kernel.org/dri-devel/871rb5bcf9@intel.com/
> 
> > 
> > Changes in v2:
> > - New (most of the code reused from drm_dp_aux_backlight.c of v1)
> > 
> > Changes in v3:
> > - Add missing ';' to fix module compilation (kernel test bot)
> > 
> > Signed-off-by: Rajeev Nandan 
> > ---
> >  drivers/video/backlight/Kconfig    |   7 +
> >  drivers/video/backlight/Makefile   |   1 +
> >  drivers/video/backlight/dp_aux_backlight.c | 245
> > +
> >  3 files changed, 253 insertions(+)
> >  create mode 100644 drivers/video/backlight/dp_aux_backlight.c
> > 
> > diff --git a/drivers/video/backlight/Kconfig
> > b/drivers/video/backlight/Kconfig
> > index d83c87b..82c88f0 100644
> > --- a/drivers/video/backlight/Kconfig
> > +++ b/drivers/video/backlight/Kconfig
> > @@ -456,6 +456,13 @@ config BACKLIGHT_LED
> >   If you have a LCD backlight adjustable by LED class driver, say
> > Y
> >   to enable this driver.
> >  
> > +config BACKLIGHT_DP_AUX
> > +   tristate "DisplayPort aux backlight driver"
> > +   depends on DRM && DRM_KMS_HELPER
> > +   help
> > + If you have a panel backlight controlled by DPCD registers
> > + on the DisplayPort aux channel, say Y to enable this driver.
> > +
> >  endif # BACKLIGHT_CLASS_DEVICE
> >  
> >  endmenu
> > diff --git a/drivers/video/backlight/Makefile
> > b/drivers/video/backlight/Makefile
> > index 685f3f1..ba23c7c 100644
> > --- a/drivers/video/backlight/Makefile
> > +++ b/drivers/video/backlight/Makefile
> > @@ -57,3 +57,4 @@ obj-$(CONFIG_BACKLIGHT_WM831X)+=
> > wm831x_bl.o
> >  obj-$(CONFIG_BACKLIGHT_ARCXCNN)+= arcxcnn_bl.o
> >  obj-$(CONFIG_BACKLIGHT_RAVE_SP)+= rave-sp-backlight.o
> >  obj-$(CONFIG_BACKLIGHT_LED)+= led_bl.o
> > +obj-$(CONFIG_BACKLIGHT_DP_AUX) += dp_aux_backlight.o
> > diff --git a/drivers/video/backlight/dp_aux_backlight.c
> > b/drivers/video/backlight/dp_aux_backlight.c
> > new file mode 100644
> > index ..3398383
> > --- /dev/null
> > +++ b/drivers/video/backlight/dp_aux_backlight.c
> > @@ -0,0 +1,245 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Backlight driver to control the brightness over DisplayPort aux
> > channel.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define DP_AUX_MAX_BRIGHTNESS  0x
> > +
> > +/**
> > + * struct dp_aux_backlight - DisplayPort aux backlight data
> > + * @dev: pointer to our device.
> > + * @aux: the DisplayPort aux channel.
> > + * @enable_gpio: the backlight enable gpio.
> > + * @enabled: true if backlight is enabled else false.
> > + */
> > +struct dp_aux_backlight {
> > +   struct device *dev;
> > +   struct drm_dp_aux *aux;
> > +   struct gpio_desc *enable_gpio;
> > +   bool enabled;
> > +};
> > +
> > +static struct drm_dp_aux *i2c_to_aux(struct i2c_adapter *i2c)
> > +{
> > +   return container_of(i2c, struct drm_dp_aux, ddc);
> > +}
> > +
> > +static int dp_aux_backlight_enable(struct dp_aux_backlight *aux_bl)
> > +{
> > +   u8 val = 0;
> > +   int ret;
> > +
> > +   if (aux_bl->enabled)
> > +   return 0;
> > +
> > +   /* Set backlight control mode */
> > +   ret = drm_dp_dpcd_readb(aux_bl->aux,
> > DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
> > +   );
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   val &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
> > +   val |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> > +   ret = drm_dp_dpcd_writeb(aux_bl->aux,
> >

[PATCH] drm/amd/pm: initialize variable

2021-04-30 Thread trix

From: Tom Rix 

Static analysis reports this problem

amdgpu_pm.c:478:16: warning: The right operand of '<' is a garbage value
  for (i = 0; i < data.nums; i++) {
^ ~

In some cases data is not set.  Initialize to 0 and flag not setting
data as an error with the existing check.

Signed-off-by: Tom Rix 
---
 drivers/gpu/drm/amd/pm/amdgpu_pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c 
b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
index 4e459ef632ef..9a54066ec0af 100644
--- a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
+++ b/drivers/gpu/drm/amd/pm/amdgpu_pm.c
@@ -451,7 +451,7 @@ static ssize_t amdgpu_get_pp_cur_state(struct device *dev,
struct drm_device *ddev = dev_get_drvdata(dev);
struct amdgpu_device *adev = drm_to_adev(ddev);
const struct amd_pm_funcs *pp_funcs = adev->powerplay.pp_funcs;
-   struct pp_states_info data;
+   struct pp_states_info data = {0};
enum amd_pm_state_type pm = 0;
int i = 0, ret = 0;
 
-- 
2.26.3

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

Re: [PATCH] drm: log errors in drm_gem_fb_init_with_funcs

2021-04-30 Thread kernel test robot

Hi Simon,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next 
tegra-drm/drm/tegra/for-next linus/master v5.12 next-20210430]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Simon-Ser/drm-log-errors-in-drm_gem_fb_init_with_funcs/20210430-224208
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: riscv-randconfig-r012-20210430 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 
8f5a2a5836cc8e4c1def2bdeb022e7b496623439)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install riscv cross compiling tool for clang build
# apt-get install binutils-riscv64-linux-gnu
# 
https://github.com/0day-ci/linux/commit/9a5b8d668b957989ae026f9f91da5ed59d831ef5
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Simon-Ser/drm-log-errors-in-drm_gem_fb_init_with_funcs/20210430-224208
git checkout 9a5b8d668b957989ae026f9f91da5ed59d831ef5
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
ARCH=riscv 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/drm_gem_framebuffer_helper.c:176:9: warning: format 
>> specifies type 'unsigned int' but the argument has type 'size_t' (aka 
>> 'unsigned long') [-Wformat]
   objs[i]->size, min_size, i);
   ^
   include/drm/drm_print.h:450:45: note: expanded from macro 'drm_dbg_kms'
   drm_dev_dbg((drm)->dev, DRM_UT_KMS, fmt, ##__VA_ARGS__)
   ~~~^~~
   1 warning generated.


vim +176 drivers/gpu/drm/drm_gem_framebuffer_helper.c

   118  
   119  /**
   120   * drm_gem_fb_init_with_funcs() - Helper function for implementing
   121   *_mode_config_funcs.fb_create
   122   *callback in cases when the driver
   123   *allocates a subclass of
   124   *struct drm_framebuffer
   125   * @dev: DRM device
   126   * @fb: framebuffer object
   127   * @file: DRM file that holds the GEM handle(s) backing the framebuffer
   128   * @mode_cmd: Metadata from the userspace framebuffer creation request
   129   * @funcs: vtable to be used for the new framebuffer object
   130   *
   131   * This function can be used to set _framebuffer_funcs for drivers 
that need
   132   * custom framebuffer callbacks. Use drm_gem_fb_create() if you don't 
need to
   133   * change _framebuffer_funcs. The function does buffer size 
validation.
   134   * The buffer size validation is for a general case, though, so users 
should
   135   * pay attention to the checks being appropriate for them or, at least,
   136   * non-conflicting.
   137   *
   138   * Returns:
   139   * Zero or a negative error code.
   140   */
   141  int drm_gem_fb_init_with_funcs(struct drm_device *dev,
   142 struct drm_framebuffer *fb,
   143 struct drm_file *file,
   144 const struct drm_mode_fb_cmd2 *mode_cmd,
   145 const struct drm_framebuffer_funcs 
*funcs)
   146  {
   147  const struct drm_format_info *info;
   148  struct drm_gem_object *objs[4];
   149  int ret, i;
   150  
   151  info = drm_get_format_info(dev, mode_cmd);
   152  if (!info) {
   153  drm_dbg_kms(dev, "Failed to get FB format info\n");
   154  return -EINVAL;
   155  }
   156  
   157  for (i = 0; i < info->num_planes; i++) {
   158  unsigned int width = mode_cmd->width / (i ? info->hsub 
: 1);
   159  unsigned int height = mode_cmd->height / (i ? 
info->vsub : 1);
   160  unsigned int min_size;
   161  
   162  objs[i] = drm_gem_object_lookup(file, 
mode_cmd->handles[i]);
   163  if (!objs[i]) {
   164  drm_dbg_kms(dev, "Failed to lookup GEM 
object\n");
   165  ret = -ENOENT;
   166  goto err_gem_object_put;
   167  }
   168  
   169  min_size = (height - 1) * mode_cmd-&

Re: [PATCH] drm/msm/dpu: Delete bonkers code

Quoting Rob Clark (2021-04-30 10:17:39)
> From: Rob Clark 
>
> dpu_crtc_atomic_flush() was directly poking it's attached planes in a
> code path that ended up in dpu_plane_atomic_update(), even if the plane
> was not involved in the current atomic update.  While a bit dubious,
> this worked before because plane->state would always point to something
> valid.  But now using drm_atomic_get_new_plane_state() we could get a
> NULL state pointer instead, leading to:
>
>[   20.873273] Call trace:
>[   20.875740]  dpu_plane_atomic_update+0x5c/0xed0
>[   20.880311]  dpu_plane_restore+0x40/0x88
>[   20.884266]  dpu_crtc_atomic_flush+0xf4/0x208
>[   20.888660]  drm_atomic_helper_commit_planes+0x150/0x238
>[   20.894014]  msm_atomic_commit_tail+0x1d4/0x7a0
>[   20.898579]  commit_tail+0xa4/0x168
>[   20.902102]  drm_atomic_helper_commit+0x164/0x178
>[   20.906841]  drm_atomic_commit+0x54/0x60
>[   20.910798]  drm_atomic_connector_commit_dpms+0x10c/0x118
>[   20.916236]  drm_mode_obj_set_property_ioctl+0x1e4/0x440
>[   20.921588]  drm_connector_property_set_ioctl+0x60/0x88
>[   20.926852]  drm_ioctl_kernel+0xd0/0x120
>[   20.930807]  drm_ioctl+0x21c/0x478
>[   20.934235]  __arm64_sys_ioctl+0xa8/0xe0
>[   20.938193]  invoke_syscall+0x64/0x130
>[   20.941977]  el0_svc_common.constprop.3+0x5c/0xe0
>[   20.946716]  do_el0_svc+0x80/0xa0
>[   20.950058]  el0_svc+0x20/0x30
>[   20.953145]  el0_sync_handler+0x88/0xb0
>[   20.957014]  el0_sync+0x13c/0x140
>
> The reason for the codepath seems dubious, the atomic suspend/resume
> heplers should handle the power-collapse case.  If not, the CRTC's
> atomic_check() should be adding the planes to the atomic update.
>
> Reported-by: Stephen Boyd 

Maybe better to use swb...@chromium.org for this one.

> Reported-by: John Stultz 
> Fixes: 37418bf14c13 drm: Use state helper instead of the plane state pointer

Should be

Fixes: 37418bf14c13 ("drm: Use state helper instead of the plane state pointer")

to match the preferred format.

> Signed-off-by: Rob Clark 

Otherwise looks good, thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915: Use might_alloc()

On Fri, Apr 30, 2021 at 12:31:27AM +0800, kernel test robot wrote:
> Hi Bernard,
> 
> Thank you for the patch! Yet something to improve:
> 
> [auto build test ERROR on drm-intel/for-linux-next]
> [also build test ERROR on v5.12 next-20210429]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
> 
> url:
> https://github.com/0day-ci/linux/commits/Bernard-Zhao/drm-i915-Use-might_alloc/20210429-104516
> base:   git://anongit.freedesktop.org/drm-intel for-linux-next
> config: x86_64-rhel-8.3-kselftests (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
> reproduce (this is a W=1 build):
> # 
> https://github.com/0day-ci/linux/commit/9fbd0c1741ce06241105d753ff3432ab55f3e94a
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review 
> Bernard-Zhao/drm-i915-Use-might_alloc/20210429-104516
> git checkout 9fbd0c1741ce06241105d753ff3432ab55f3e94a
> # save the attached .config to linux build tree
> make W=1 W=1 ARCH=x86_64 
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
> 
> All errors (new ones prefixed by >>):
> 
>drivers/gpu/drm/i915/i915_sw_fence.c: In function 
> '__i915_sw_fence_await_sw_fence':
> >> drivers/gpu/drm/i915/i915_sw_fence.c:344:2: error: implicit declaration of 
> >> function 'might_alloc'; did you mean 'might_lock'? 
> >> [-Werror=implicit-function-declaration]
>  344 |  might_alloc(gfp);
>  |  ^~~
>  |  might_lock
>cc1: some warnings being treated as errors

I think you're missing an include or something. The other patch you've
done seems good, I queued that up in drm-intel-gt-next for 5.14.

Thanks, Daniel

> 
> 
> vim +344 drivers/gpu/drm/i915/i915_sw_fence.c
> 
>335
>336static int __i915_sw_fence_await_sw_fence(struct i915_sw_fence 
> *fence,
>337  struct i915_sw_fence 
> *signaler,
>338  wait_queue_entry_t 
> *wq, gfp_t gfp)
>339{
>340unsigned int pending;
>341unsigned long flags;
>342
>343debug_fence_assert(fence);
>  > 344might_alloc(gfp);
>345
>346if (i915_sw_fence_done(signaler)) {
>347i915_sw_fence_set_error_once(fence, 
> signaler->error);
>348return 0;
>349}
>350
>351debug_fence_assert(signaler);
>352
>353/* The dependency graph must be acyclic. */
>354if (unlikely(i915_sw_fence_check_if_after(fence, 
> signaler)))
>355return -EINVAL;
>356
>357pending = I915_SW_FENCE_FLAG_FENCE;
>358if (!wq) {
>359wq = kmalloc(sizeof(*wq), gfp);
>360if (!wq) {
>361if (!gfpflags_allow_blocking(gfp))
>362return -ENOMEM;
>363
>364i915_sw_fence_wait(signaler);
>365i915_sw_fence_set_error_once(fence, 
> signaler->error);
>366return 0;
>367}
>368
>369pending |= I915_SW_FENCE_FLAG_ALLOC;
>370}
>371
>372INIT_LIST_HEAD(>entry);
>373wq->flags = pending;
>374wq->func = i915_sw_fence_wake;
>375wq->private = fence;
>376
>377i915_sw_fence_await(fence);
>378
>379spin_lock_irqsave(>wait.lock, flags);
>380if (likely(!i915_sw_fence_done(signaler))) {
>381__add_wait_queue_entry_tail(>wait, 
> wq);
>382pending = 1;
>383} else {
>384i915_sw_fence_wake(wq, 0, signaler->error, 
> NULL);
>385pending = 0;
>386}
>387spin_unlock_irqrestore(>wait.lock, flags);
>388
>389return pending;
>390}
>391
> 
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/msm/dpu: Delete bonkers code

2021-04-30 Thread John Stultz

On Fri, Apr 30, 2021 at 10:14 AM Rob Clark  wrote:
>
> From: Rob Clark 
>
> dpu_crtc_atomic_flush() was directly poking it's attached planes in a
> code path that ended up in dpu_plane_atomic_update(), even if the plane
> was not involved in the current atomic update.  While a bit dubious,
> this worked before because plane->state would always point to something
> valid.  But now using drm_atomic_get_new_plane_state() we could get a
> NULL state pointer instead, leading to:
>
>[   20.873273] Call trace:
>[   20.875740]  dpu_plane_atomic_update+0x5c/0xed0
>[   20.880311]  dpu_plane_restore+0x40/0x88
>[   20.884266]  dpu_crtc_atomic_flush+0xf4/0x208
>[   20.888660]  drm_atomic_helper_commit_planes+0x150/0x238
>[   20.894014]  msm_atomic_commit_tail+0x1d4/0x7a0
>[   20.898579]  commit_tail+0xa4/0x168
>[   20.902102]  drm_atomic_helper_commit+0x164/0x178
>[   20.906841]  drm_atomic_commit+0x54/0x60
>[   20.910798]  drm_atomic_connector_commit_dpms+0x10c/0x118
>[   20.916236]  drm_mode_obj_set_property_ioctl+0x1e4/0x440
>[   20.921588]  drm_connector_property_set_ioctl+0x60/0x88
>[   20.926852]  drm_ioctl_kernel+0xd0/0x120
>[   20.930807]  drm_ioctl+0x21c/0x478
>[   20.934235]  __arm64_sys_ioctl+0xa8/0xe0
>[   20.938193]  invoke_syscall+0x64/0x130
>[   20.941977]  el0_svc_common.constprop.3+0x5c/0xe0
>[   20.946716]  do_el0_svc+0x80/0xa0
>[   20.950058]  el0_svc+0x20/0x30
>[   20.953145]  el0_sync_handler+0x88/0xb0
>[   20.957014]  el0_sync+0x13c/0x140
>
> The reason for the codepath seems dubious, the atomic suspend/resume
> heplers should handle the power-collapse case.  If not, the CRTC's
> atomic_check() should be adding the planes to the atomic update.

Thanks! This patch gets things booting again!

Tested-by: John Stultz 

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

Re: [PATCH v5 20/27] drm: Scope all DRM IOCTLs with drm_dev_enter/exit

2021-04-30 Thread Andrey Grodzovsky

On 2021-04-30 6:25 a.m., Daniel Vetter wrote:

On Thu, Apr 29, 2021 at 04:34:55PM -0400, Andrey Grodzovsky wrote:

On 2021-04-29 3:05 p.m., Daniel Vetter wrote:

On Thu, Apr 29, 2021 at 12:04:33PM -0400, Andrey Grodzovsky wrote:

On 2021-04-29 7:32 a.m., Daniel Vetter wrote:

On Thu, Apr 29, 2021 at 01:23:19PM +0200, Daniel Vetter wrote:

On Wed, Apr 28, 2021 at 11:12:00AM -0400, Andrey Grodzovsky wrote:

With this calling drm_dev_unplug will flush and block
all in flight IOCTLs

Also, add feature such that if device supports graceful unplug
we enclose entire IOCTL in SRCU critical section.

Signed-off-by: Andrey Grodzovsky

Nope.

The idea of drm_dev_enter/exit is to mark up hw access. Not entire ioctl.

Then I am confused why we have
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.bootlin.com%2Flinux%2Fv5.12%2Fsource%2Fdrivers%2Fgpu%2Fdrm%2Fdrm_ioctl.c%23L826data=04%7C01%7Candrey.grodzovsky%40amd.com%7Cf4c0568093cc462f625808d90bc23a3c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637553751106596888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=PPKrQYBrgRMjpwlL0r8n5zenIhQMFWc6gniHgUTxTAY%3Dreserved=0
currently in code ?

I forgot about this one, again. Thanks for reminding.

Especially not with an opt-in flag so that it could be shrugged of as a
driver hack. Most of these ioctls should have absolutely no problem
working after hotunplug.

Also, doing this defeats the point since it pretty much guarantees
userspace will die in assert()s and stuff. E.g. on i915 the rough contract
is that only execbuf (and even that only when userspace has indicated
support for non-recoverable hw ctx) is allowed to fail. Anything else
might crash userspace.

Given that as I pointed above we already fail any IOCTls with -ENODEV
when device is unplugged, it seems those crashes don't happen that
often ? Also, in all my testing I don't think I saw a user space crash
I could attribute to this.

I guess it should be ok.

What should be ok ?

Your approach, but not your patch. If we go with this let's just lift it
to drm_ioctl() as the default behavior. No driver opt-in flag, because
that's definitely worse than any other approach because we really need to
get rid of driver specific behaviour for generic ioctls, especially
anything a compositor will use directly.

My reasons for making this work is both less trouble for userspace (did
you test with various wayland compositors out there, not just amdgpu x86

I didn't - will give it a try.

Weston worked without crashes, run the egl tester cube there.

driver?), but also testing.

We still need a bunch of these checks in various places or you'll wait a
very long time for a pending modeset or similar to complete. Being able to
run that code easily after hotunplug has completed should help a lot with
testing.

Plus various drivers already acquired drm_dev_enter/exit and now I wonder
whether that was properly tested or not ...

I guess maybe we need a drm module option to disable this check, so that
we can exercise the code as if the ioctl has raced with hotunplug at the
worst possible moment.

Also atomic is really tricky here: I assume your testing has just done
normal synchronous commits, but anything that goes through atomic can be
done nonblocking in a separate thread. Which the ioctl catch-all here wont
capture.

Yes, async commit was on my mind and thanks for reminding me. Indeed
I forgot this but i planned to scope the entire amdgpu_dm_atomic_tail in
drm_dev_enter/exit. Note that i have a bunch of patches, all name's
starting with 'Scope' that just methodically put all the background
work items and timers the drivers schedules in drm_dev_enter/exit scope.
This was supposed to be part of the 'Scope Display code' patch.

That's too much. You still have to arrange that the flip completion event
gets sent out. So it's a bit tricky.

In other places the same problem applies, e.g. probe functions need to
make sure they report "disconnected".

I see, well, this is all part of KMS support which I defer for now
anyway. Will tackle it then.

You probably need similar (and very precisely defined) rules for amdgpu.
And those must definitely exclude any shard ioctls from randomly failing
with EIO, because that just kills the box and defeats the point of trying
to gracefully handling hotunplug and making sure userspace has a chance of
survival. E.g. for atomic everything should continue, including flip
completion, but we set all outputs to "disconnected" and send out the
uevent. Maybe crtc enabling can fail too, but that can also be handled
through the async status we're using to signal DP link failures to
userspace.

As I pointed before, because of the complexity of the topic I prefer to
take it step by step and solve first for secondary device use case, not
for primary, display attached device.

Yeah makes sense. But then I think the right patch is to roll this out for
all

[PATCH] drm/msm/dpu: Delete bonkers code

2021-04-30 Thread Rob Clark

From: Rob Clark 

dpu_crtc_atomic_flush() was directly poking it's attached planes in a
code path that ended up in dpu_plane_atomic_update(), even if the plane
was not involved in the current atomic update.  While a bit dubious,
this worked before because plane->state would always point to something
valid.  But now using drm_atomic_get_new_plane_state() we could get a
NULL state pointer instead, leading to:

   [   20.873273] Call trace:
   [   20.875740]  dpu_plane_atomic_update+0x5c/0xed0
   [   20.880311]  dpu_plane_restore+0x40/0x88
   [   20.884266]  dpu_crtc_atomic_flush+0xf4/0x208
   [   20.888660]  drm_atomic_helper_commit_planes+0x150/0x238
   [   20.894014]  msm_atomic_commit_tail+0x1d4/0x7a0
   [   20.898579]  commit_tail+0xa4/0x168
   [   20.902102]  drm_atomic_helper_commit+0x164/0x178
   [   20.906841]  drm_atomic_commit+0x54/0x60
   [   20.910798]  drm_atomic_connector_commit_dpms+0x10c/0x118
   [   20.916236]  drm_mode_obj_set_property_ioctl+0x1e4/0x440
   [   20.921588]  drm_connector_property_set_ioctl+0x60/0x88
   [   20.926852]  drm_ioctl_kernel+0xd0/0x120
   [   20.930807]  drm_ioctl+0x21c/0x478
   [   20.934235]  __arm64_sys_ioctl+0xa8/0xe0
   [   20.938193]  invoke_syscall+0x64/0x130
   [   20.941977]  el0_svc_common.constprop.3+0x5c/0xe0
   [   20.946716]  do_el0_svc+0x80/0xa0
   [   20.950058]  el0_svc+0x20/0x30
   [   20.953145]  el0_sync_handler+0x88/0xb0
   [   20.957014]  el0_sync+0x13c/0x140

The reason for the codepath seems dubious, the atomic suspend/resume
heplers should handle the power-collapse case.  If not, the CRTC's
atomic_check() should be adding the planes to the atomic update.

Reported-by: Stephen Boyd 
Reported-by: John Stultz 
Fixes: 37418bf14c13 drm: Use state helper instead of the plane state pointer
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c  | 10 --
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 16 
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h |  6 --
 3 files changed, 32 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 7c29976be243..18bc76b7f1a3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -648,16 +648,6 @@ static void dpu_crtc_atomic_flush(struct drm_crtc *crtc,
if (unlikely(!cstate->num_mixers))
return;
 
-   /*
-* For planes without commit update, drm framework will not add
-* those planes to current state since hardware update is not
-* required. However, if those planes were power collapsed since
-* last commit cycle, driver has to restore the hardware state
-* of those planes explicitly here prior to plane flush.
-*/
-   drm_atomic_crtc_for_each_plane(plane, crtc)
-   dpu_plane_restore(plane, state);
-
/* update performance setting before crtc kickoff */
dpu_core_perf_crtc_update(crtc, 1, false);
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index df7f3d3afd8b..7a993547eb75 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1258,22 +1258,6 @@ static void dpu_plane_atomic_update(struct drm_plane 
*plane,
}
 }
 
-void dpu_plane_restore(struct drm_plane *plane, struct drm_atomic_state *state)
-{
-   struct dpu_plane *pdpu;
-
-   if (!plane || !plane->state) {
-   DPU_ERROR("invalid plane\n");
-   return;
-   }
-
-   pdpu = to_dpu_plane(plane);
-
-   DPU_DEBUG_PLANE(pdpu, "\n");
-
-   dpu_plane_atomic_update(plane, state);
-}
-
 static void dpu_plane_destroy(struct drm_plane *plane)
 {
struct dpu_plane *pdpu = plane ? to_dpu_plane(plane) : NULL;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
index 03b6365a750c..34e03ac05f4a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h
@@ -84,12 +84,6 @@ bool is_dpu_plane_virtual(struct drm_plane *plane);
 void dpu_plane_get_ctl_flush(struct drm_plane *plane, struct dpu_hw_ctl *ctl,
u32 *flush_sspp);
 
-/**
- * dpu_plane_restore - restore hw state if previously power collapsed
- * @plane: Pointer to drm plane structure
- */
-void dpu_plane_restore(struct drm_plane *plane, struct drm_atomic_state 
*state);
-
 /**
  * dpu_plane_flush - final plane operations before commit flush
  * @plane: Pointer to drm plane structure
-- 
2.30.2

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

Re: [Intel-gfx] [PATCH 16/21] drm/i915/gem: Delay context creation

On Fri, Apr 30, 2021 at 6:57 PM Jason Ekstrand  wrote:
>
> On Fri, Apr 30, 2021 at 11:33 AM Daniel Vetter  wrote:
> >
> > On Fri, Apr 30, 2021 at 6:27 PM Jason Ekstrand  wrote:
> > >
> > > On Fri, Apr 30, 2021 at 1:53 AM Daniel Vetter  wrote:
> > > >
> > > > On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand  
> > > > wrote:
> > > > >
> > > > > On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter  wrote:
> > > > > >
> > > > > > On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason Ekstrand wrote:
> > > > > > > On Thu, Apr 29, 2021 at 1:56 PM Daniel Vetter  
> > > > > > > wrote:
> > > > > > > > On Thu, Apr 29, 2021 at 01:16:04PM -0500, Jason Ekstrand wrote:
> > > > > > > > > On Thu, Apr 29, 2021 at 10:51 AM Daniel Vetter 
> > > > > > > > >  wrote:
> > > > > > > > > > > + ret = set_proto_ctx_param(file_priv, pc, args);
> > > > > > > > > >
> > > > > > > > > > I think we should have a FIXME here of not allowing this on 
> > > > > > > > > > some future
> > > > > > > > > > platforms because just use CTX_CREATE_EXT.
> > > > > > > > >
> > > > > > > > > Done.
> > > > > > > > >
> > > > > > > > > > > + if (ret == -ENOTSUPP) {
> > > > > > > > > > > + /* Some params, specifically SSEU, can only 
> > > > > > > > > > > be set on fully
> > > > > > > > > >
> > > > > > > > > > I think this needs a FIXME: that this only holds during the 
> > > > > > > > > > conversion?
> > > > > > > > > > Otherwise we kinda have a bit a problem me thinks ...
> > > > > > > > >
> > > > > > > > > I'm not sure what you mean by that.
> > > > > > > >
> > > > > > > > Well I'm at least assuming that we wont have this case anymore, 
> > > > > > > > i.e.
> > > > > > > > there's only two kinds of parameters:
> > > > > > > > - those which are valid only on proto context
> > > > > > > > - those which are valid on both (like priority)
> > > > > > > >
> > > > > > > > This SSEU thing looks like a 3rd parameter, which is only valid 
> > > > > > > > on
> > > > > > > > finalized context. That feels all kinds of wrong. Will it stay? 
> > > > > > > > If yes
> > > > > > > > *ugh* and why?
> > > > > > >
> > > > > > > Because I was being lazy.  The SSEU stuff is a fairly complex 
> > > > > > > param to
> > > > > > > parse and it's always set live.  I can factor out the SSEU parsing
> > > > > > > code if you want and it shouldn't be too bad in the end.
> > > > > >
> > > > > > Yeah I think the special case here is a bit too jarring.
> > > > >
> > > > > I rolled a v5 that allows you to set SSEU as a create param.  I'm not
> > > > > a huge fan of that much code duplication for the SSEU set but I guess
> > > > > that's what we get for deciding to "unify" our context creation
> > > > > parameter path with our on-the-fly parameter path
> > > > >
> > > > > You can look at it here:
> > > > >
> > > > > https://gitlab.freedesktop.org/jekstrand/linux/-/commit/c805f424a3374b2de405b7fc651eab551df2cdaf#474deb1194892a272db022ff175872d42004dfda_283_588
> > > >
> > > > Hm yeah the duplication of the render engine check is a bit annoying.
> > > > What's worse, if you tthrow another set_engines on top it's probably
> > > > all wrong then. The old thing solved that by just throwing that
> > > > intel_context away.
> > >
> > > I think that's already mostly taken care of.  When set_engines
> > > happens, we throw away the old array of engines and start with a new
> > > one where everything has been memset to 0.  The one remaining problem
> > > is that, if userspace resets the engine set, we need to memset
> > > legacy_rcs_sseu to 0.  I've added that.
> > >
> > > > You're also not keeping the engine id in the proto ctx for this, so
> > > > there's probably some gaps there. We'd need to clear the SSEU if
> > > > userspace puts another context there. But also no userspace does that.
> > >
> > > Again, I think that's handled.  See above.
> > >
> > > > Plus cursory review of userspace show
> > > > - mesa doesn't set this
> > > > - compute sets its right before running the batch
> > > > - media sets it as the last thing of context creation
> > > >
> > > > So it's kinda not needed. But also we're asking umd to switch over to
> > > > CTX_CREATE_EXT, and if sseu doesn't work for that media team will be
> > > > puzzled. And we've confused them enough already with our uapis.
> > > >
> > > > Another idea: proto_set_sseu just stores the uapi struct and a note
> > > > that it's set, and checks nothing. To validate sseu on proto context
> > > > we do (but only when an sseu parameter is set):
> > > > 1. finalize the context
> > > > 2. call the real set_sseu for validation
> > > > 3. throw the finalized context away again, it was just for validating
> > > > the overall thing
> > > >
> > > > That way we don't have to consider all the interactions of setting
> > > > sseu and engines in any order on proto context, validation code is
> > > > guaranteed shared. Only downside is that there's a slight chance in
> > > > behaviour: SSEU, then setting another engine in that slot will fail
> > > > instead

Re: Radeon NI: GIT kernel with the nislands_smc commit doesn't boot on a Freescale P5040 board and P.A.Semi Nemo board

2021-04-30 Thread Gustavo A. R. Silva



On 4/30/21 10:26, Deucher, Alexander wrote:
> [AMD Public Use]
> 
> + Gustavo, amd-gfx
> 
>> -Original Message-
>> From: Christian Zigotzky 
>> Sent: Friday, April 30, 2021 8:00 AM
>> To: gustavo...@kernel.org; Deucher, Alexander 
>> 
>> Cc: R.T.Dickinson ; Darren Stevens > zone.net>; mad skateman ; linuxppc-dev 
>> ; Olof Johansson ; 
>> Maling list - DRI developers ; Michel 
>> Dänzer ; Christian Zigotzky 
>> Subject: Radeon NI: GIT kernel with the nislands_smc commit doesn't 
>> boot on a Freescale P5040 board and P.A.Semi Nemo board
>>
>> Hello,
>>
>> The Nemo board (A-EON AmigaOne X1000) [1] and the FSL P5040 Cyrus+ 
>> board (A-EON AmigaOne X5000) [2] with installed AMD Radeon HD6970 NI 
>> graphics cards (Cayman XT) [3] don't boot with the latest git kernel 
>> anymore after the commit "drm/radeon/nislands_smc.h: Replace 
>> one-element array with flexible-array member in struct NISLANDS_SMC_SWSTATE 
>> branch" [4].
>> This git kernel boots in a virtual e5500 QEMU machine with a VirtIO-GPU [5].
>>
>> I bisected today [6].
>>
>> Result: drm/radeon/nislands_smc.h: Replace one-element array with 
>> flexible-array member in struct NISLANDS_SMC_SWSTATE branch
>> (434fb1e7444a2efc3a4ebd950c7f771ebfcffa31) [4] is the first bad commit.
>>
>> I was able to revert this commit [7] and after a new compiling, the 
>> kernel boots without any problems on my AmigaOnes.
>>
>> After that I created a patch for reverting this commit for new git test 
>> kernels.
>> [3]
>>
>> The kernel compiles and boots with this patch on my AmigaOnes. Please 
>> find attached the kernel config files.
>>
>> Please check the first bad commit.

I'll have a look.

Thanks for the report!
--
Gustavo

>>
>> Thanks,
>> Christian
>>
>> [1]
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.
>> wikipedia.org%2Fwiki%2FAmigaOne_X1000data=04%7C01%7Calexand
>> er.deucher%40amd.com%7C0622549383fb4320346b08d90bcf7be1%7C3dd89
>> 61fe4884e608e11a82d994e183d%7C0%7C0%7C637553808670161651%7CUnkn
>> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
>> 1haWwiLCJXVCI6Mn0%3D%7C1000sdata=PNSrApUdMrku20hH7dEKlJJ
>> TBi7Qp5JOkqpA4MvKqdE%3Dreserved=0
>> [2]
>> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.
>> a miga.org%2Findex.php%3Ftitle%3DX5000data=04%7C01%7Calexander
>> .deucher%40amd.com%7C0622549383fb4320346b08d90bcf7be1%7C3dd8961f
>> e4884e608e11a82d994e183d%7C0%7C0%7C637553808670161651%7CUnknow
>> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
>> WwiLCJXVCI6Mn0%3D%7C1000sdata=B8Uvhs25%2FP3RfnL1AgICN3Y4
>> CEXeCE1yIoi3vvwvGto%3Dreserved=0
>> [3]
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforu
>> m.hyperion-
>> entertainment.com%2Fviewtopic.php%3Ff%3D35%26t%3D4377data=
>> 04%7C01%7Calexander.deucher%40amd.com%7C0622549383fb4320346b08d
>> 90bcf7be1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63755380
>> 8670161651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
>> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=TokXplD
>> Tvg3%2BZMPLCgR1fs%2BN2X9MIfLXLW67MAM2Qsk%3Dreserved=0
>> [4]
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.
>> k ernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%
>> 2Fcommit%2F%3Fid%3D434fb1e7444a2efc3a4ebd950c7f771ebfcffa31d
>> ata=04%7C01%7Calexander.deucher%40amd.com%7C0622549383fb4320346
>> b08d90bcf7be1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6375
>> 53808670161651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
>> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=JC
>> M4xvPEnWdckcTPbQ2Ujv%2FAiMMsFMzzl4Pr%2FRPlcMQ%3Dreserve
>> d=0
>> [5] qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage - 
>> drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev
>> user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw 
>> root=/dev/vda" -device virtio-vga -usb -device usb-ehci,id=ehci 
>> -device usb- tablet -device virtio-keyboard-pci -smp 4 -vnc :1 [6] 
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforu
>> m.hyperion-
>> entertainment.com%2Fviewtopic.php%3Fp%3D53074%23p53074data
>> =04%7C01%7Calexander.deucher%40amd.com%7C0622549383fb4320346b08
>> d90bcf7be1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6375538
>> 08670161651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
>> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=RXfSlY
>> A3bDEFas0%2Fk2vMWsl2l0nuhS2ecjZgSBLc%2Bs4%3Dreserved=0
>> [7] git revert 434fb1e7444a2efc3a4ebd950c7f771ebfcffa3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 16/21] drm/i915/gem: Delay context creation

On Fri, Apr 30, 2021 at 11:33 AM Daniel Vetter  wrote:
>
> On Fri, Apr 30, 2021 at 6:27 PM Jason Ekstrand  wrote:
> >
> > On Fri, Apr 30, 2021 at 1:53 AM Daniel Vetter  wrote:
> > >
> > > On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand  
> > > wrote:
> > > >
> > > > On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter  wrote:
> > > > >
> > > > > On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason Ekstrand wrote:
> > > > > > On Thu, Apr 29, 2021 at 1:56 PM Daniel Vetter  
> > > > > > wrote:
> > > > > > > On Thu, Apr 29, 2021 at 01:16:04PM -0500, Jason Ekstrand wrote:
> > > > > > > > On Thu, Apr 29, 2021 at 10:51 AM Daniel Vetter 
> > > > > > > >  wrote:
> > > > > > > > > > + ret = set_proto_ctx_param(file_priv, pc, args);
> > > > > > > > >
> > > > > > > > > I think we should have a FIXME here of not allowing this on 
> > > > > > > > > some future
> > > > > > > > > platforms because just use CTX_CREATE_EXT.
> > > > > > > >
> > > > > > > > Done.
> > > > > > > >
> > > > > > > > > > + if (ret == -ENOTSUPP) {
> > > > > > > > > > + /* Some params, specifically SSEU, can only 
> > > > > > > > > > be set on fully
> > > > > > > > >
> > > > > > > > > I think this needs a FIXME: that this only holds during the 
> > > > > > > > > conversion?
> > > > > > > > > Otherwise we kinda have a bit a problem me thinks ...
> > > > > > > >
> > > > > > > > I'm not sure what you mean by that.
> > > > > > >
> > > > > > > Well I'm at least assuming that we wont have this case anymore, 
> > > > > > > i.e.
> > > > > > > there's only two kinds of parameters:
> > > > > > > - those which are valid only on proto context
> > > > > > > - those which are valid on both (like priority)
> > > > > > >
> > > > > > > This SSEU thing looks like a 3rd parameter, which is only valid on
> > > > > > > finalized context. That feels all kinds of wrong. Will it stay? 
> > > > > > > If yes
> > > > > > > *ugh* and why?
> > > > > >
> > > > > > Because I was being lazy.  The SSEU stuff is a fairly complex param 
> > > > > > to
> > > > > > parse and it's always set live.  I can factor out the SSEU parsing
> > > > > > code if you want and it shouldn't be too bad in the end.
> > > > >
> > > > > Yeah I think the special case here is a bit too jarring.
> > > >
> > > > I rolled a v5 that allows you to set SSEU as a create param.  I'm not
> > > > a huge fan of that much code duplication for the SSEU set but I guess
> > > > that's what we get for deciding to "unify" our context creation
> > > > parameter path with our on-the-fly parameter path
> > > >
> > > > You can look at it here:
> > > >
> > > > https://gitlab.freedesktop.org/jekstrand/linux/-/commit/c805f424a3374b2de405b7fc651eab551df2cdaf#474deb1194892a272db022ff175872d42004dfda_283_588
> > >
> > > Hm yeah the duplication of the render engine check is a bit annoying.
> > > What's worse, if you tthrow another set_engines on top it's probably
> > > all wrong then. The old thing solved that by just throwing that
> > > intel_context away.
> >
> > I think that's already mostly taken care of.  When set_engines
> > happens, we throw away the old array of engines and start with a new
> > one where everything has been memset to 0.  The one remaining problem
> > is that, if userspace resets the engine set, we need to memset
> > legacy_rcs_sseu to 0.  I've added that.
> >
> > > You're also not keeping the engine id in the proto ctx for this, so
> > > there's probably some gaps there. We'd need to clear the SSEU if
> > > userspace puts another context there. But also no userspace does that.
> >
> > Again, I think that's handled.  See above.
> >
> > > Plus cursory review of userspace show
> > > - mesa doesn't set this
> > > - compute sets its right before running the batch
> > > - media sets it as the last thing of context creation
> > >
> > > So it's kinda not needed. But also we're asking umd to switch over to
> > > CTX_CREATE_EXT, and if sseu doesn't work for that media team will be
> > > puzzled. And we've confused them enough already with our uapis.
> > >
> > > Another idea: proto_set_sseu just stores the uapi struct and a note
> > > that it's set, and checks nothing. To validate sseu on proto context
> > > we do (but only when an sseu parameter is set):
> > > 1. finalize the context
> > > 2. call the real set_sseu for validation
> > > 3. throw the finalized context away again, it was just for validating
> > > the overall thing
> > >
> > > That way we don't have to consider all the interactions of setting
> > > sseu and engines in any order on proto context, validation code is
> > > guaranteed shared. Only downside is that there's a slight chance in
> > > behaviour: SSEU, then setting another engine in that slot will fail
> > > instead of throwing the sseu parameters away. That's the right thing
> > > for CTX_CREATE_EXT anyway, and current userspace doesn't care.
> > >
> > > Thoughts?
> >
> > I thought about that.  The problem is that they can set_sseu multiple
> > times on different engines.  This means

Re: [PATCH] drm/i915/display Try YCbCr420 color when RGB fails

2021-04-30 Thread Ville Syrjälä

On Thu, Apr 29, 2021 at 02:05:53PM +0200, Werner Sembach wrote:
> When encoder validation of a display mode fails, retry with less bandwidth
> heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups
> to support 4k60Hz output, which previously failed silently.
> 
> AMDGPU had nearly the exact same issue. This problem description is
> therefore copied from my commit message of the AMDGPU patch.
> 
> On some setups, while the monitor and the gpu support display modes with
> pixel clocks of up to 600MHz, the link encoder might not. This prevents
> YCbCr444 and RGB encoding for 4k60Hz, but YCbCr420 encoding might still be
> possible. However, which color mode is used is decided before the link
> encoder capabilities are checked. This patch fixes the problem by retrying
> to find a display mode with YCbCr420 enforced and using it, if it is
> valid.
> 
> I'm not entierly sure if the second
> "if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv))" check in
> intel_hdmi_compute_config(...) after forcing ycbcr420 is necessary. I
> included it to better be safe then sorry.
> 
> Signed-off-by: Werner Sembach 
> Cc: 
> ---
> Rebased from 5.12 to drm-tip and resend to resolve merge conflict.
> 
> >From 876c1c8d970ff2a411ee8d08651bd4edbe9ecb3d Mon Sep 17 00:00:00 2001
> From: Werner Sembach 
> Date: Thu, 29 Apr 2021 13:59:30 +0200
> Subject: [PATCH] Retry using YCbCr420 encoding if clock setup for RGB fails
> 
> ---
>  drivers/gpu/drm/i915/display/intel_hdmi.c | 80 +--
>  1 file changed, 60 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c 
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index 46de56af33db..c9b5a7d7f9c6 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -1861,6 +1861,30 @@ static int intel_hdmi_port_clock(int clock, int bpc)
>   return clock * bpc / 8;
>  }
>  
> +static enum drm_mode_status
> +intel_hdmi_check_bpc(struct intel_hdmi *hdmi, int clock, bool has_hdmi_sink, 
> struct drm_i915_private *dev_priv)

Don't pass dev_priv. It can be extracted from the intel_hdmi.

The name of the function isn't really sitting super well with me.
I guess I'd just call it something like intel_hdmi_mode_clock_valid().

We should also split this big patch up into smaller parts. Just this
mechanical extraction of this function without any functional changes
could be a nice first patch in the series.

> +{
> + enum drm_mode_status status;
> +
> + /* check if we can do 8bpc */
> + status = hdmi_port_clock_valid(hdmi, intel_hdmi_port_clock(clock, 8),
> +true, has_hdmi_sink);
> +
> + if (has_hdmi_sink) {
> + /* if we can't do 8bpc we may still be able to do 12bpc */
> + if (status != MODE_OK && !HAS_GMCH(dev_priv))
> + status = hdmi_port_clock_valid(hdmi, 
> intel_hdmi_port_clock(clock, 12),
> +true, has_hdmi_sink);
> +
> + /* if we can't do 8,12bpc we may still be able to do 10bpc */
> + if (status != MODE_OK && DISPLAY_VER(dev_priv) >= 11)
> + status = hdmi_port_clock_valid(hdmi, 
> intel_hdmi_port_clock(clock, 10),
> +true, has_hdmi_sink);
> + }
> +
> + return status;
> +}
> +
>  static enum drm_mode_status
>  intel_hdmi_mode_valid(struct drm_connector *connector,
> struct drm_display_mode *mode)
> @@ -1891,23 +1915,18 @@ intel_hdmi_mode_valid(struct drm_connector *connector,
>   if (drm_mode_is_420_only(>display_info, mode))
>   clock /= 2;
>  
> - /* check if we can do 8bpc */
> - status = hdmi_port_clock_valid(hdmi, intel_hdmi_port_clock(clock, 8),
> -true, has_hdmi_sink);
> + status = intel_hdmi_check_bpc(hdmi, clock, has_hdmi_sink, dev_priv);
>  
> - if (has_hdmi_sink) {
> - /* if we can't do 8bpc we may still be able to do 12bpc */
> - if (status != MODE_OK && !HAS_GMCH(dev_priv))
> - status = hdmi_port_clock_valid(hdmi, 
> intel_hdmi_port_clock(clock, 12),
> -true, has_hdmi_sink);
> + if (status != MODE_OK) {
> + if (drm_mode_is_420_also(>display_info, mode)) {

We also need a connector->ycbcr_420_allowed check here.

> + /* if we can't do full color resolution we may still be 
> able to do reduced color resolution */
> + clock /= 2;
>  
> - /* if we can't do 8,12bpc we may still be able to do 10bpc */
> - if (status != MODE_OK && DISPLAY_VER(dev_priv) >= 11)
> - status = hdmi_port_clock_valid(hdmi, 
> intel_hdmi_port_clock(clock, 10),
> -true, has_hdmi_sink);
> + status =

Re: [PATCH v3 10/11] drm: Use state helper instead of the plane state pointer

2021-04-30 Thread Rob Clark

On Thu, Apr 8, 2021 at 6:20 AM Maxime Ripard  wrote:
>
> Hi Stephen,
>
> On Tue, Mar 30, 2021 at 11:56:15AM -0700, Stephen Boyd wrote:
> > Quoting Maxime Ripard (2021-03-30 08:35:27)
> > > Hi Stephen,
> > >
> > > On Mon, Mar 29, 2021 at 06:52:01PM -0700, Stephen Boyd wrote:
> > > > Trimming Cc list way down, sorry if that's too much.
> > > >
> > > > Quoting Maxime Ripard (2021-02-19 04:00:30)
> > > > > Many drivers reference the plane->state pointer in order to get the
> > > > > current plane state in their atomic_update or atomic_disable hooks,
> > > > > which would be the new plane state in the global atomic state since
> > > > > _swap_state happened when those hooks are run.
> > > >
> > > > Does this mean drm_atomic_helper_swap_state()?
> > >
> > > Yep. Previous to that call in drm_atomic_helper_commit, plane->state is
> > > the state currently programmed in the hardware, so the old state (that's
> > > the case you have with atomic_check for example)
> > >
> > > Once drm_atomic_helper_swap_state has run, plane->state is now the state
> > > that needs to be programmed into the hardware, so the new state.
> >
> > Ok, and I suppose that is called by drm_atomic_helper_commit()?
>
> Yep :)
>
> > So presumably a modeset is causing this? I get the NULL pointer around
> > the time we switch from the splash screen to the login screen. I think
> > there's a modeset during that transition.
>
> It's very likely yeah. I really don't get how that pointer could be null
> though :/

So I think I see what is going on.. the issue is the CRTC has changed,
but not the plane, so there is no new-state for the plane.

But dpu_crtc_atomic_flush() iterates over all the attached planes,
calling dpu_plane_restore() which leads into
dpu_plane_atomic_update().. this is kinda dpu breaking the rules..

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

Re: [Intel-gfx] [PATCH 16/21] drm/i915/gem: Delay context creation

On Fri, Apr 30, 2021 at 6:27 PM Jason Ekstrand  wrote:
>
> On Fri, Apr 30, 2021 at 1:53 AM Daniel Vetter  wrote:
> >
> > On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand  
> > wrote:
> > >
> > > On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter  wrote:
> > > >
> > > > On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason Ekstrand wrote:
> > > > > On Thu, Apr 29, 2021 at 1:56 PM Daniel Vetter  wrote:
> > > > > > On Thu, Apr 29, 2021 at 01:16:04PM -0500, Jason Ekstrand wrote:
> > > > > > > On Thu, Apr 29, 2021 at 10:51 AM Daniel Vetter  
> > > > > > > wrote:
> > > > > > > > > + ret = set_proto_ctx_param(file_priv, pc, args);
> > > > > > > >
> > > > > > > > I think we should have a FIXME here of not allowing this on 
> > > > > > > > some future
> > > > > > > > platforms because just use CTX_CREATE_EXT.
> > > > > > >
> > > > > > > Done.
> > > > > > >
> > > > > > > > > + if (ret == -ENOTSUPP) {
> > > > > > > > > + /* Some params, specifically SSEU, can only be 
> > > > > > > > > set on fully
> > > > > > > >
> > > > > > > > I think this needs a FIXME: that this only holds during the 
> > > > > > > > conversion?
> > > > > > > > Otherwise we kinda have a bit a problem me thinks ...
> > > > > > >
> > > > > > > I'm not sure what you mean by that.
> > > > > >
> > > > > > Well I'm at least assuming that we wont have this case anymore, i.e.
> > > > > > there's only two kinds of parameters:
> > > > > > - those which are valid only on proto context
> > > > > > - those which are valid on both (like priority)
> > > > > >
> > > > > > This SSEU thing looks like a 3rd parameter, which is only valid on
> > > > > > finalized context. That feels all kinds of wrong. Will it stay? If 
> > > > > > yes
> > > > > > *ugh* and why?
> > > > >
> > > > > Because I was being lazy.  The SSEU stuff is a fairly complex param to
> > > > > parse and it's always set live.  I can factor out the SSEU parsing
> > > > > code if you want and it shouldn't be too bad in the end.
> > > >
> > > > Yeah I think the special case here is a bit too jarring.
> > >
> > > I rolled a v5 that allows you to set SSEU as a create param.  I'm not
> > > a huge fan of that much code duplication for the SSEU set but I guess
> > > that's what we get for deciding to "unify" our context creation
> > > parameter path with our on-the-fly parameter path
> > >
> > > You can look at it here:
> > >
> > > https://gitlab.freedesktop.org/jekstrand/linux/-/commit/c805f424a3374b2de405b7fc651eab551df2cdaf#474deb1194892a272db022ff175872d42004dfda_283_588
> >
> > Hm yeah the duplication of the render engine check is a bit annoying.
> > What's worse, if you tthrow another set_engines on top it's probably
> > all wrong then. The old thing solved that by just throwing that
> > intel_context away.
>
> I think that's already mostly taken care of.  When set_engines
> happens, we throw away the old array of engines and start with a new
> one where everything has been memset to 0.  The one remaining problem
> is that, if userspace resets the engine set, we need to memset
> legacy_rcs_sseu to 0.  I've added that.
>
> > You're also not keeping the engine id in the proto ctx for this, so
> > there's probably some gaps there. We'd need to clear the SSEU if
> > userspace puts another context there. But also no userspace does that.
>
> Again, I think that's handled.  See above.
>
> > Plus cursory review of userspace show
> > - mesa doesn't set this
> > - compute sets its right before running the batch
> > - media sets it as the last thing of context creation
> >
> > So it's kinda not needed. But also we're asking umd to switch over to
> > CTX_CREATE_EXT, and if sseu doesn't work for that media team will be
> > puzzled. And we've confused them enough already with our uapis.
> >
> > Another idea: proto_set_sseu just stores the uapi struct and a note
> > that it's set, and checks nothing. To validate sseu on proto context
> > we do (but only when an sseu parameter is set):
> > 1. finalize the context
> > 2. call the real set_sseu for validation
> > 3. throw the finalized context away again, it was just for validating
> > the overall thing
> >
> > That way we don't have to consider all the interactions of setting
> > sseu and engines in any order on proto context, validation code is
> > guaranteed shared. Only downside is that there's a slight chance in
> > behaviour: SSEU, then setting another engine in that slot will fail
> > instead of throwing the sseu parameters away. That's the right thing
> > for CTX_CREATE_EXT anyway, and current userspace doesn't care.
> >
> > Thoughts?
>
> I thought about that.  The problem is that they can set_sseu multiple
> times on different engines.  This means we'd have to effectively build
> up an arbitrary list of SSEU set operations and replay it.  I'm not
> sure how I feel about building up a big data structure.

Hm, but how does this work with proto ctx then? I've only seen a
single sseu param set in the patch you linked.

> > > I'm also going to send it

Re: [Intel-gfx] [PATCH 16/21] drm/i915/gem: Delay context creation

On Fri, Apr 30, 2021 at 1:53 AM Daniel Vetter  wrote:
>
> On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand  wrote:
> >
> > On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter  wrote:
> > >
> > > On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason Ekstrand wrote:
> > > > On Thu, Apr 29, 2021 at 1:56 PM Daniel Vetter  wrote:
> > > > > On Thu, Apr 29, 2021 at 01:16:04PM -0500, Jason Ekstrand wrote:
> > > > > > On Thu, Apr 29, 2021 at 10:51 AM Daniel Vetter  
> > > > > > wrote:
> > > > > > > > + ret = set_proto_ctx_param(file_priv, pc, args);
> > > > > > >
> > > > > > > I think we should have a FIXME here of not allowing this on some 
> > > > > > > future
> > > > > > > platforms because just use CTX_CREATE_EXT.
> > > > > >
> > > > > > Done.
> > > > > >
> > > > > > > > + if (ret == -ENOTSUPP) {
> > > > > > > > + /* Some params, specifically SSEU, can only be 
> > > > > > > > set on fully
> > > > > > >
> > > > > > > I think this needs a FIXME: that this only holds during the 
> > > > > > > conversion?
> > > > > > > Otherwise we kinda have a bit a problem me thinks ...
> > > > > >
> > > > > > I'm not sure what you mean by that.
> > > > >
> > > > > Well I'm at least assuming that we wont have this case anymore, i.e.
> > > > > there's only two kinds of parameters:
> > > > > - those which are valid only on proto context
> > > > > - those which are valid on both (like priority)
> > > > >
> > > > > This SSEU thing looks like a 3rd parameter, which is only valid on
> > > > > finalized context. That feels all kinds of wrong. Will it stay? If yes
> > > > > *ugh* and why?
> > > >
> > > > Because I was being lazy.  The SSEU stuff is a fairly complex param to
> > > > parse and it's always set live.  I can factor out the SSEU parsing
> > > > code if you want and it shouldn't be too bad in the end.
> > >
> > > Yeah I think the special case here is a bit too jarring.
> >
> > I rolled a v5 that allows you to set SSEU as a create param.  I'm not
> > a huge fan of that much code duplication for the SSEU set but I guess
> > that's what we get for deciding to "unify" our context creation
> > parameter path with our on-the-fly parameter path
> >
> > You can look at it here:
> >
> > https://gitlab.freedesktop.org/jekstrand/linux/-/commit/c805f424a3374b2de405b7fc651eab551df2cdaf#474deb1194892a272db022ff175872d42004dfda_283_588
>
> Hm yeah the duplication of the render engine check is a bit annoying.
> What's worse, if you tthrow another set_engines on top it's probably
> all wrong then. The old thing solved that by just throwing that
> intel_context away.

I think that's already mostly taken care of.  When set_engines
happens, we throw away the old array of engines and start with a new
one where everything has been memset to 0.  The one remaining problem
is that, if userspace resets the engine set, we need to memset
legacy_rcs_sseu to 0.  I've added that.

> You're also not keeping the engine id in the proto ctx for this, so
> there's probably some gaps there. We'd need to clear the SSEU if
> userspace puts another context there. But also no userspace does that.

Again, I think that's handled.  See above.

> Plus cursory review of userspace show
> - mesa doesn't set this
> - compute sets its right before running the batch
> - media sets it as the last thing of context creation
>
> So it's kinda not needed. But also we're asking umd to switch over to
> CTX_CREATE_EXT, and if sseu doesn't work for that media team will be
> puzzled. And we've confused them enough already with our uapis.
>
> Another idea: proto_set_sseu just stores the uapi struct and a note
> that it's set, and checks nothing. To validate sseu on proto context
> we do (but only when an sseu parameter is set):
> 1. finalize the context
> 2. call the real set_sseu for validation
> 3. throw the finalized context away again, it was just for validating
> the overall thing
>
> That way we don't have to consider all the interactions of setting
> sseu and engines in any order on proto context, validation code is
> guaranteed shared. Only downside is that there's a slight chance in
> behaviour: SSEU, then setting another engine in that slot will fail
> instead of throwing the sseu parameters away. That's the right thing
> for CTX_CREATE_EXT anyway, and current userspace doesn't care.
>
> Thoughts?

I thought about that.  The problem is that they can set_sseu multiple
times on different engines.  This means we'd have to effectively build
up an arbitrary list of SSEU set operations and replay it.  I'm not
sure how I feel about building up a big data structure.

> > I'm also going to send it to trybot.
>
> If you resend pls include all my r-b, I think some got lost in v4.

I'll try and dig those up.

> Also, in the kernel at least we expect minimal commit message with a
> bit of context, there's no Part-of: link pointing at the entire MR
> with overview and discussion, the patchwork Link: we add is a pretty
> bad substitute. Some of the new patches in v4 are a bit too

Re: [PATCH v5 15/27] drm/scheduler: Fix hang when sched_entity released

2021-04-30 Thread Andrey Grodzovsky




On 2021-04-30 2:47 a.m., Christian König wrote:



Am 29.04.21 um 19:06 schrieb Andrey Grodzovsky:



On 2021-04-29 3:18 a.m., Christian König wrote:
I need to take another look at this part when I don't have a massive 
headache any more.


Maybe split the patch set up into different parts, something like:
1. Adding general infrastructure.
2. Making sure all memory is unpolated.
3. Job and fence handling


I am not sure you mean this patch here, maybe another one ?
Also note you already RBed it.


No what I meant was to send out the patches before this one as #1 and #2.

That is the easier stuff which can easily go into the drm-misc-next or 
amd-staging-drm-next branch.


The scheduler stuff certainly need to go into drm-misc-next.

Christian.


Got you. I am fine with it. What we have here is a working hot-unplug
code but, one with potential use after free MMIO ranges frpom the zombie
device. The followup patches after this patch are all about preventing
this and so the patch-set up until this patch including, is functional
on it's own. While it's necessary to solve the above issue, it's has
complications as can be seen from the discussion with Daniel on later
patch in this series. Still, in my opinion it's better to rollout some
initial support to hot-unplug without use after free protection then
having no support for hot-unplug at all. It will also make the merge
work easier as I need to constantly rebase the patches on top latest
kernel and solve new regressions.

Daniel - given the arguments above can you sound your opinion on this
approach ?

Andrey




Andrey



Christian.

Am 28.04.21 um 17:11 schrieb Andrey Grodzovsky:

Problem: If scheduler is already stopped by the time sched_entity
is released and entity's job_queue not empty I encountred
a hang in drm_sched_entity_flush. This is because 
drm_sched_entity_is_idle

never becomes false.

Fix: In drm_sched_fini detach all sched_entities from the
scheduler's run queues. This will satisfy drm_sched_entity_is_idle.
Also wakeup all those processes stuck in sched_entity flushing
as the scheduler main thread which wakes them up is stopped by now.

v2:
Reverse order of drm_sched_rq_remove_entity and marking
s_entity as stopped to prevent reinserion back to rq due
to race.

v3:
Drop drm_sched_rq_remove_entity, only modify entity->stopped
and check for it in drm_sched_entity_is_idle

Signed-off-by: Andrey Grodzovsky 
Reviewed-by: Christian König 
---
  drivers/gpu/drm/scheduler/sched_entity.c |  3 ++-
  drivers/gpu/drm/scheduler/sched_main.c   | 24 


  2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/scheduler/sched_entity.c 
b/drivers/gpu/drm/scheduler/sched_entity.c

index f0790e9471d1..cb58f692dad9 100644
--- a/drivers/gpu/drm/scheduler/sched_entity.c
+++ b/drivers/gpu/drm/scheduler/sched_entity.c
@@ -116,7 +116,8 @@ static bool drm_sched_entity_is_idle(struct 
drm_sched_entity *entity)

  rmb(); /* for list_empty to work without lock */
  if (list_empty(>list) ||
-    spsc_queue_count(>job_queue) == 0)
+    spsc_queue_count(>job_queue) == 0 ||
+    entity->stopped)
  return true;
  return false;
diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c

index 908b0b56032d..ba087354d0a8 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -897,9 +897,33 @@ EXPORT_SYMBOL(drm_sched_init);
   */
  void drm_sched_fini(struct drm_gpu_scheduler *sched)
  {
+    struct drm_sched_entity *s_entity;
+    int i;
+
  if (sched->thread)
  kthread_stop(sched->thread);
+    for (i = DRM_SCHED_PRIORITY_COUNT - 1; i >= 
DRM_SCHED_PRIORITY_MIN; i--) {

+    struct drm_sched_rq *rq = >sched_rq[i];
+
+    if (!rq)
+    continue;
+
+    spin_lock(>lock);
+    list_for_each_entry(s_entity, >entities, list)
+    /*
+ * Prevents reinsertion and marks job_queue as idle,
+ * it will removed from rq in drm_sched_entity_fini
+ * eventually
+ */
+    s_entity->stopped = true;
+    spin_unlock(>lock);
+
+    }
+
+    /* Wakeup everyone stuck in drm_sched_entity_flush for this 
scheduler */

+    wake_up_all(>job_scheduled);
+
  /* Confirm no work left behind accessing device structures */
  cancel_delayed_work_sync(>work_tdr);





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

Re: [Intel-gfx] [PATCH 09/21] drm/i915/gem: Disallow creating contexts with too many engines

On Fri, Apr 30, 2021 at 6:40 AM Tvrtko Ursulin
 wrote:
>
>
> On 29/04/2021 20:16, Jason Ekstrand wrote:
> > On Thu, Apr 29, 2021 at 3:01 AM Tvrtko Ursulin
> >  wrote:
> >> On 28/04/2021 18:09, Jason Ekstrand wrote:
> >>> On Wed, Apr 28, 2021 at 9:26 AM Tvrtko Ursulin
> >>>  wrote:
>  On 28/04/2021 15:02, Daniel Vetter wrote:
> > On Wed, Apr 28, 2021 at 11:42:31AM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 28/04/2021 11:16, Daniel Vetter wrote:
> >>> On Fri, Apr 23, 2021 at 05:31:19PM -0500, Jason Ekstrand wrote:
>  There's no sense in allowing userspace to create more engines than it
>  can possibly access via execbuf.
> 
>  Signed-off-by: Jason Ekstrand 
>  ---
>   drivers/gpu/drm/i915/gem/i915_gem_context.c | 7 +++
>   1 file changed, 3 insertions(+), 4 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
>  b/drivers/gpu/drm/i915/gem/i915_gem_context.c
>  index 5f8d0faf783aa..ecb3bf5369857 100644
>  --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
>  +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
>  @@ -1640,11 +1640,10 @@ set_engines(struct i915_gem_context *ctx,
>   return -EINVAL;
>   }
>  -  /*
>  -   * Note that I915_EXEC_RING_MASK limits execbuf to only using the
>  -   * first 64 engines defined here.
>  -   */
>   num_engines = (args->size - sizeof(*user)) / 
>  sizeof(*user->engines);
> >>>
> >>> Maybe add a comment like /* RING_MASK has not shift, so can be used
> >>> directly here */ since I had to check that :-)
> >>>
> >>> Same story about igt testcases needed, just to be sure.
> >>>
> >>> Reviewed-by: Daniel Vetter 
> >>
> >> I am not sure about the churn vs benefit ratio here. There are also 
> >> patches
> >> which extend the engine selection field in execbuf2 over the unused
> >> constants bits (with an explicit flag). So churn upstream and churn in
> >> internal (if interesting) for not much benefit.
> >
> > This isn't churn.
> >
> > This is "lock done uapi properly".
> >>>
> >>> Pretty much.
> >>
> >> Still haven't heard what concrete problems it solves.
> >>
>  IMO it is a "meh" patch. Doesn't fix any problems and will create work
>  for other people and man hours spent which no one will ever properly
>  account against.
> 
>  Number of contexts in the engine map should not really be tied to
>  execbuf2. As is demonstrated by the incoming work to address more than
>  63 engines, either as an extension to execbuf2 or future execbuf3.
> >>>
> >>> Which userspace driver has requested more than 64 engines in a single 
> >>> context?
> >>
> >> No need to artificially limit hardware capabilities in the uapi by
> >> implementing a policy in the kernel. Which will need to be
> >> removed/changed shortly anyway. This particular patch is work and
> >> creates more work (which other people who will get to fix the fallout
> >> will spend man hours to figure out what and why broke) for no benefit.
> >> Or you are yet to explain what the benefit is in concrete terms.
> >
> > You keep complaining about how much work it takes and yet I've spent
> > more time replying to your e-mails on this patch than I spent writing
> > the patch and the IGT test.  Also, if it takes so much time to add a
> > restriction, then why are we spending time figuring out how to modify
> > the uAPI to allow you to execbuf on a context with more than 64
> > engines?  If we're worried about engineering man-hours, then limiting
> > to 64 IS the pragmatic solution.
>
> a)
>
> Question of what problem does the patch fix is still unanswered.
>
> b)
>
> You miss the point. I'll continue in the next paragraph..
>
> >
> >> Why don't you limit it to number of physical engines then? Why don't you
> >> filter out duplicates? Why not limit the number of buffer objects per
> >> client or global based on available RAM + swap relative to minimum
> >> object size? Reductio ad absurdum yes, but illustrating the, in this
> >> case, a thin line between "locking down uapi" and adding too much policy
> >> where it is not appropriate.
> >
> > All this patch does is say that  you're not allowed to create a
> > context with more engines than the execbuf API will let you use.  We
> > already have an artificial limit.  All this does is push the error
> > handling further up the stack.  If someone comes up with a mechanism
> > to execbuf on engine 65 (they'd better have an open-source user if it
> > involves changing API), I'm very happy for them to bump this limit at
> > the same time.  It'll take them 5 minutes and it'll be something they
> > find while writing the IGT test.
>
> .. no it won't take five minutes.
>
> If I need to spell everything out - you will put this patch in,

Re: [Intel-gfx] [PATCH 03/21] drm/i915/gem: Set the watchdog timeout directly in intel_context_set_gem

On Fri, Apr 30, 2021 at 6:18 AM Tvrtko Ursulin
 wrote:
>
>
> On 29/04/2021 15:54, Jason Ekstrand wrote:
> > On Thu, Apr 29, 2021 at 3:04 AM Tvrtko Ursulin
> >  wrote:
> >>
> >>
> >> On 28/04/2021 18:24, Jason Ekstrand wrote:
> >>> On Wed, Apr 28, 2021 at 10:55 AM Tvrtko Ursulin
> >>>  wrote:
>  On 23/04/2021 23:31, Jason Ekstrand wrote:
> > Instead of handling it like a context param, unconditionally set it when
> > intel_contexts are created.  This doesn't fix anything but does simplify
> > the code a bit.
> >
> > Signed-off-by: Jason Ekstrand 
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_context.c   | 43 
> > +++
> > .../gpu/drm/i915/gem/i915_gem_context_types.h |  4 --
> > drivers/gpu/drm/i915/gt/intel_context_param.h |  3 +-
> > 3 files changed, 6 insertions(+), 44 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> > b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > index 35bcdeddfbf3f..1091cc04a242a 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> > @@ -233,7 +233,11 @@ static void intel_context_set_gem(struct 
> > intel_context *ce,
> > intel_engine_has_timeslices(ce->engine))
> > __set_bit(CONTEXT_USE_SEMAPHORES, >flags);
> >
> > - intel_context_set_watchdog_us(ce, ctx->watchdog.timeout_us);
> > + if (IS_ACTIVE(CONFIG_DRM_I915_REQUEST_TIMEOUT) &&
> > + ctx->i915->params.request_timeout_ms) {
> > + unsigned int timeout_ms = 
> > ctx->i915->params.request_timeout_ms;
> > + intel_context_set_watchdog_us(ce, (u64)timeout_ms * 1000);
> 
>  Blank line between declarations and code please, or just lose the local.
> 
>  Otherwise looks okay. Slight change that same GEM context can now have a
>  mix of different request expirations isn't interesting I think. At least
>  the change goes away by the end of the series.
> >>>
> >>> In order for that to happen, I think you'd have to have a race between
> >>> CREATE_CONTEXT and someone smashing the request_timeout_ms param via
> >>> sysfs.  Or am I missing something?  Given that timeouts are really
> >>> per-engine anyway, I don't think we need to care too much about that.
> >>
> >> We don't care, no.
> >>
> >> For completeness only - by the end of the series it is what you say. But
> >> at _this_ point in the series though it is if modparam changes at any
> >> point between context create and replacing engines. Which is a change
> >> compared to before this patch, since modparam was cached in the GEM
> >> context so far. So one GEM context was a single request_timeout_ms.
> >
> > I've added the following to the commit message:
> >
> > It also means that sync files exported from different engines on a
> > SINGLE_TIMELINE context will have different fence contexts.  This is
> > visible to userspace if it looks at the obj_name field of
> > sync_fence_info.
> >
> > How's that sound?
>
> Wrong thread but sounds good.
>
> I haven't looked into the fence merge logic apart from noticing context
> is used there. So I'd suggest a quick look there on top, just to make
> sure merging logic does not hold any surprises if contexts start to
> differ. Probably just results with more inefficiency somewhere, in theory.

Looked at it yesterday.  It really does just create a fence array with
all the fences. :-)

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

Re: [PATCH] drm: log errors in drm_gem_fb_init_with_funcs

2021-04-30 Thread Ville Syrjälä

On Fri, Apr 30, 2021 at 02:40:02PM +, Simon Ser wrote:
> Let the user know what went wrong in drm_gem_fb_init_with_funcs
> failure paths.
> 
> Signed-off-by: Simon Ser 
> Cc: Daniel Vetter 
> Cc: Sam Ravnborg 
> Cc: Noralf Trønnes 
> Cc: Andrzej Pietrasiewicz 
> ---
>  drivers/gpu/drm/drm_gem_framebuffer_helper.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> index 109d11fb4cd4..e4a3c7eb43b2 100644
> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> @@ -155,8 +155,10 @@ int drm_gem_fb_init_with_funcs(struct drm_device *dev,
>   int ret, i;
>  
>   info = drm_get_format_info(dev, mode_cmd);
> - if (!info)
> + if (!info) {
> + drm_dbg_kms(dev, "Failed to get FB format info\n");
>   return -EINVAL;
> + }

Assuming this thing gets plugged into .fb_create() getting
this far with a bogus format would be rather suprising.

>  
>   for (i = 0; i < info->num_planes; i++) {
>   unsigned int width = mode_cmd->width / (i ? info->hsub : 1);
> @@ -175,6 +177,9 @@ int drm_gem_fb_init_with_funcs(struct drm_device *dev,
>+ mode_cmd->offsets[i];
>  
>   if (objs[i]->size < min_size) {
> + drm_dbg_kms(dev,
> + "GEM object size (%u) smaller than minimum 
> size (%u) for plane %d\n",
> + objs[i]->size, min_size, i);
>   drm_gem_object_put(objs[i]);
>   ret = -EINVAL;
>   goto err_gem_object_put;
> -- 
> 2.31.1
> 
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: Radeon NI: GIT kernel with the nislands_smc commit doesn't boot on a Freescale P5040 board and P.A.Semi Nemo board

2021-04-30 Thread Deucher, Alexander

[AMD Public Use]

+ Gustavo, amd-gfx

> -Original Message-
> From: Christian Zigotzky 
> Sent: Friday, April 30, 2021 8:00 AM
> To: gustavo...@kernel.org; Deucher, Alexander 
> 
> Cc: R.T.Dickinson ; Darren Stevens  zone.net>; mad skateman ; linuxppc-dev 
> ; Olof Johansson ; 
> Maling list - DRI developers ; Michel 
> Dänzer ; Christian Zigotzky 
> Subject: Radeon NI: GIT kernel with the nislands_smc commit doesn't 
> boot on a Freescale P5040 board and P.A.Semi Nemo board
> 
> Hello,
> 
> The Nemo board (A-EON AmigaOne X1000) [1] and the FSL P5040 Cyrus+ 
> board (A-EON AmigaOne X5000) [2] with installed AMD Radeon HD6970 NI 
> graphics cards (Cayman XT) [3] don't boot with the latest git kernel 
> anymore after the commit "drm/radeon/nislands_smc.h: Replace 
> one-element array with flexible-array member in struct NISLANDS_SMC_SWSTATE 
> branch" [4].
> This git kernel boots in a virtual e5500 QEMU machine with a VirtIO-GPU [5].
> 
> I bisected today [6].
> 
> Result: drm/radeon/nislands_smc.h: Replace one-element array with 
> flexible-array member in struct NISLANDS_SMC_SWSTATE branch
> (434fb1e7444a2efc3a4ebd950c7f771ebfcffa31) [4] is the first bad commit.
> 
> I was able to revert this commit [7] and after a new compiling, the 
> kernel boots without any problems on my AmigaOnes.
> 
> After that I created a patch for reverting this commit for new git test 
> kernels.
> [3]
> 
> The kernel compiles and boots with this patch on my AmigaOnes. Please 
> find attached the kernel config files.
> 
> Please check the first bad commit.
> 
> Thanks,
> Christian
> 
> [1]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.
> wikipedia.org%2Fwiki%2FAmigaOne_X1000data=04%7C01%7Calexand
> er.deucher%40amd.com%7C0622549383fb4320346b08d90bcf7be1%7C3dd89
> 61fe4884e608e11a82d994e183d%7C0%7C0%7C637553808670161651%7CUnkn
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> 1haWwiLCJXVCI6Mn0%3D%7C1000sdata=PNSrApUdMrku20hH7dEKlJJ
> TBi7Qp5JOkqpA4MvKqdE%3Dreserved=0
> [2]
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.
> a miga.org%2Findex.php%3Ftitle%3DX5000data=04%7C01%7Calexander
> .deucher%40amd.com%7C0622549383fb4320346b08d90bcf7be1%7C3dd8961f
> e4884e608e11a82d994e183d%7C0%7C0%7C637553808670161651%7CUnknow
> n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
> WwiLCJXVCI6Mn0%3D%7C1000sdata=B8Uvhs25%2FP3RfnL1AgICN3Y4
> CEXeCE1yIoi3vvwvGto%3Dreserved=0
> [3]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforu
> m.hyperion-
> entertainment.com%2Fviewtopic.php%3Ff%3D35%26t%3D4377data=
> 04%7C01%7Calexander.deucher%40amd.com%7C0622549383fb4320346b08d
> 90bcf7be1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C63755380
> 8670161651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj
> oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=TokXplD
> Tvg3%2BZMPLCgR1fs%2BN2X9MIfLXLW67MAM2Qsk%3Dreserved=0
> [4]
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.
> k ernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git%
> 2Fcommit%2F%3Fid%3D434fb1e7444a2efc3a4ebd950c7f771ebfcffa31d
> ata=04%7C01%7Calexander.deucher%40amd.com%7C0622549383fb4320346
> b08d90bcf7be1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6375
> 53808670161651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=JC
> M4xvPEnWdckcTPbQ2Ujv%2FAiMMsFMzzl4Pr%2FRPlcMQ%3Dreserve
> d=0
> [5] qemu-system-ppc64 -M ppce500 -cpu e5500 -m 1024 -kernel uImage - 
> drive format=raw,file=MintPPC32-X5000.img,index=0,if=virtio -netdev
> user,id=mynet0 -device virtio-net-pci,netdev=mynet0 -append "rw 
> root=/dev/vda" -device virtio-vga -usb -device usb-ehci,id=ehci 
> -device usb- tablet -device virtio-keyboard-pci -smp 4 -vnc :1 [6] 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fforu
> m.hyperion-
> entertainment.com%2Fviewtopic.php%3Fp%3D53074%23p53074data
> =04%7C01%7Calexander.deucher%40amd.com%7C0622549383fb4320346b08
> d90bcf7be1%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C6375538
> 08670161651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=RXfSlY
> A3bDEFas0%2Fk2vMWsl2l0nuhS2ecjZgSBLc%2Bs4%3Dreserved=0
> [7] git revert 434fb1e7444a2efc3a4ebd950c7f771ebfcffa3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [v3 1/2] dt-bindings: backlight: add DisplayPort aux backlight

2021-04-30 Thread rajeevny

On 30-04-2021 02:33, Doug Anderson wrote:

Hi,

On Thu, Apr 29, 2021 at 11:04 AM Rob Herring  wrote:

On Mon, Apr 26, 2021 at 11:29:15AM +0530, Rajeev Nandan wrote:
> Add bindings for DisplayPort aux backlight driver.
>
> Changes in v2:
> - New
>
> Signed-off-by: Rajeev Nandan 
> ---
>  .../bindings/leds/backlight/dp-aux-backlight.yaml  | 49 
++
>  1 file changed, 49 insertions(+)
>  create mode 100644 
Documentation/devicetree/bindings/leds/backlight/dp-aux-backlight.yaml
>
> diff --git 
a/Documentation/devicetree/bindings/leds/backlight/dp-aux-backlight.yaml 
b/Documentation/devicetree/bindings/leds/backlight/dp-aux-backlight.yaml
> new file mode 100644
> index ..0fa8bf0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/backlight/dp-aux-backlight.yaml
> @@ -0,0 +1,49 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/backlight/dp-aux-backlight.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: DisplayPort aux backlight driver bindings
> +
> +maintainers:
> +  - Rajeev Nandan 
> +
> +description:
> +  Backlight driver to control the brightness over DisplayPort aux channel.
> +
> +allOf:
> +  - $ref: common.yaml#
> +
> +properties:
> +  compatible:
> +const: dp-aux-backlight
> +
> +  ddc-i2c-bus:
> +$ref: /schemas/types.yaml#/definitions/phandle
> +description:
> +  A phandle to the system I2C controller connected to the DDC bus used
> +  for the DisplayPort AUX channel.
> +
> +  enable-gpios:
> +maxItems: 1
> +description: GPIO specifier for backlight enable pin.
> +
> +  max-brightness: true
> +
> +required:
> +  - compatible
> +  - ddc-i2c-bus
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +backlight {
> +compatible = "dp-aux-backlight";
> +ddc-i2c-bus = <_bridge>;
> +enable-gpios = < 12 GPIO_ACTIVE_HIGH>;

So the DDC bus is connected to a backlight and also a panel? This
binding is not reflecting the h/w, but rather what you want for some
driver.

There's only one thing here and that's an eDP panel which supports
backlight control via DP aux channel. You can figure all that out from
the panel's compatible and/or reading the EDID.

You might also be interested in this thread:

https://lore.kernel.org/lkml/yiksdtjcihgnv...@orome.fritz.box/

I think Rajeev needs to rework everything anyway as per:

https://lore.kernel.org/r/87zgxl5qar@intel.com

...but you're right that it makes sense not to model the backlight as
a separate node in the device tree. The panel driver can handle
setting up the backlight.

-Doug

It was not a good idea to create a separate backlight driver and use
ddc-i2c-bus to get access to DP aux. I am working to move the code
to the panel driver and to utilize the new DRM helper functions
(drm_edp_backlight_*) Lyude has added [1].

To use these helper functions, the panel driver should have access to 
the

"struct drm_dp_aux *". The simple-panel has a "ddc-i2c-bus" property
to give the panel access to the DDC bus and is currently being used to
get the EDID from the panel. Can I use the same ddc bus i2c_adapter to 
get

the "struct drm_dp_aux *"?

As per the suggestion [2], I get the "struct drm_dp_aux *" from the
i2c_adapter of ddc bus (maybe I didn't understand the suggestion 
correctly),

and, it turned out, the way I have implemented is not the right way [3].
So, I am afraid to use the same method in the panel driver.

[1] https://lore.kernel.org/dri-devel/871rb5bcf9@intel.com/
[2] https://www.spinics.net/lists/dri-devel/msg295429.html
[3] 
https://lore.kernel.org/dri-devel/2021042616.4lc3ekxjugjr3...@maple.lan/

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

Re: [PATCH 07/13] drm/ttm: flip over the sys manager to self allocated nodes

On Fri, 30 Apr 2021 at 10:25, Christian König
 wrote:
>
> Make sure to allocate a resource object here.
>
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/ttm/ttm_sys_manager.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_sys_manager.c 
> b/drivers/gpu/drm/ttm/ttm_sys_manager.c
> index ed92615214e3..a926114edfe5 100644
> --- a/drivers/gpu/drm/ttm/ttm_sys_manager.c
> +++ b/drivers/gpu/drm/ttm/ttm_sys_manager.c
> @@ -3,18 +3,25 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  static int ttm_sys_man_alloc(struct ttm_resource_manager *man,
>  struct ttm_buffer_object *bo,
>  const struct ttm_place *place,
>  struct ttm_resource *mem)
>  {
> +   mem->mm_node = kzalloc(sizeof(*mem), GFP_KERNEL);
> +   if (!mem->mm_node)
> +   return -ENOMEM;
> +
> +   ttm_resource_init(bo, place, mem->mm_node);

Yeah, why are we passing the mm_node here, it's not the ttm_resource?

> return 0;
>  }
>
>  static void ttm_sys_man_free(struct ttm_resource_manager *man,
>  struct ttm_resource *mem)
>  {
> +   kfree(mem->mm_node);
>  }
>
>  static const struct ttm_resource_manager_func ttm_sys_manager_func = {
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 11/13] drm/nouveau: switch the TTM backends to self alloc

On Fri, 30 Apr 2021 at 10:25, Christian König
 wrote:
>
> Similar to the TTM range manager.
>
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/nouveau/nouveau_mem.h | 1 +
>  drivers/gpu/drm/nouveau/nouveau_ttm.c | 4 
>  2 files changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.h 
> b/drivers/gpu/drm/nouveau/nouveau_mem.h
> index 7df3848e85aa..3a6a1be2ed52 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_mem.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_mem.h
> @@ -13,6 +13,7 @@ nouveau_mem(struct ttm_resource *reg)
>  }
>
>  struct nouveau_mem {
> +   struct ttm_resource base;
> struct nouveau_cli *cli;
> u8 kind;
> u8 comp;
> diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
> b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> index 15c7627f8f58..5e5ce2ec89f0 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> @@ -59,6 +59,8 @@ nouveau_vram_manager_new(struct ttm_resource_manager *man,
> if (ret)
> return ret;
>
> +   ttm_resource_init(bo, place, reg->mm_node);
> +

What happened here? I assume this needs to be nouveau_mem.base not the mm_node?

> ret = nouveau_mem_vram(reg, nvbo->contig, nvbo->page);
> if (ret) {
> nouveau_mem_del(reg);
> @@ -87,6 +89,7 @@ nouveau_gart_manager_new(struct ttm_resource_manager *man,
> if (ret)
> return ret;
>
> +   ttm_resource_init(bo, place, reg->mm_node);
> reg->start = 0;
> return 0;
>  }
> @@ -112,6 +115,7 @@ nv04_gart_manager_new(struct ttm_resource_manager *man,
> if (ret)
> return ret;
>
> +   ttm_resource_init(bo, place, reg->mm_node);
> ret = nvif_vmm_get(>cli->vmm.vmm, PTES, false, 12, 0,
>(long)reg->num_pages << PAGE_SHIFT, >vma[0]);
> if (ret) {
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 10/13] drm/amdgpu: switch the VRAM backend to self alloc

On Fri, 30 Apr 2021 at 10:25, Christian König
 wrote:
>
> Similar to the TTM range manager.
>
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 51 
>  1 file changed, 30 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> index bb01e0fc621c..d59ec07c77bb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> @@ -23,6 +23,8 @@
>   */
>
>  #include 
> +#include 
> +
>  #include "amdgpu.h"
>  #include "amdgpu_vm.h"
>  #include "amdgpu_res_cursor.h"
> @@ -367,9 +369,9 @@ static int amdgpu_vram_mgr_new(struct 
> ttm_resource_manager *man,
> struct amdgpu_vram_mgr *mgr = to_vram_mgr(man);
> struct amdgpu_device *adev = to_amdgpu_device(mgr);
> uint64_t vis_usage = 0, mem_bytes, max_bytes;
> +   struct ttm_range_mgr_node *node;
> struct drm_mm *mm = >mm;
> enum drm_mm_insert_mode mode;
> -   struct drm_mm_node *nodes;
> unsigned i;
> int r;
>
> @@ -384,8 +386,8 @@ static int amdgpu_vram_mgr_new(struct 
> ttm_resource_manager *man,
> /* bail out quickly if there's likely not enough VRAM for this BO */
> mem_bytes = (u64)mem->num_pages << PAGE_SHIFT;
> if (atomic64_add_return(mem_bytes, >usage) > max_bytes) {
> -   atomic64_sub(mem_bytes, >usage);
> -   return -ENOSPC;
> +   r = -ENOSPC;
> +   goto error_sub;
> }
>
> if (place->flags & TTM_PL_FLAG_CONTIGUOUS) {
> @@ -403,13 +405,15 @@ static int amdgpu_vram_mgr_new(struct 
> ttm_resource_manager *man,
> num_nodes = DIV_ROUND_UP(mem->num_pages, pages_per_node);
> }
>
> -   nodes = kvmalloc_array((uint32_t)num_nodes, sizeof(*nodes),
> -  GFP_KERNEL | __GFP_ZERO);
> -   if (!nodes) {
> -   atomic64_sub(mem_bytes, >usage);
> -   return -ENOMEM;
> +   node = kvmalloc(struct_size(node, mm_nodes, num_nodes),
> + GFP_KERNEL | __GFP_ZERO);

Alignment.

> +   if (!node) {
> +   r = -ENOMEM;
> +   goto error_sub;
> }
>
> +   ttm_resource_init(tbo, place, >base);
> +
> mode = DRM_MM_INSERT_BEST;
> if (place->flags & TTM_PL_FLAG_TOPDOWN)
> mode = DRM_MM_INSERT_HIGH;
> @@ -428,8 +432,9 @@ static int amdgpu_vram_mgr_new(struct 
> ttm_resource_manager *man,
> if (pages >= pages_per_node)
> alignment = pages_per_node;
>
> -   r = drm_mm_insert_node_in_range(mm, [i], pages, 
> alignment,
> -   0, place->fpfn, lpfn, mode);
> +   r = drm_mm_insert_node_in_range(mm, >mm_nodes[i], pages,
> +   alignment, 0, place->fpfn,
> +   lpfn, mode);
> if (unlikely(r)) {
> if (pages > pages_per_node) {
> if (is_power_of_2(pages))
> @@ -438,11 +443,11 @@ static int amdgpu_vram_mgr_new(struct 
> ttm_resource_manager *man,
> pages = rounddown_pow_of_two(pages);
> continue;
> }
> -   goto error;
> +   goto error_free;
> }
>
> -   vis_usage += amdgpu_vram_mgr_vis_size(adev, [i]);
> -   amdgpu_vram_mgr_virt_start(mem, [i]);
> +   vis_usage += amdgpu_vram_mgr_vis_size(adev, 
> >mm_nodes[i]);
> +   amdgpu_vram_mgr_virt_start(mem, >mm_nodes[i]);
> pages_left -= pages;
> ++i;
>
> @@ -455,16 +460,17 @@ static int amdgpu_vram_mgr_new(struct 
> ttm_resource_manager *man,
> mem->placement |= TTM_PL_FLAG_CONTIGUOUS;
>
> atomic64_add(vis_usage, >vis_usage);
> -   mem->mm_node = nodes;
> +   mem->mm_node = >mm_nodes[0];
> return 0;
>
> -error:
> +error_free:
> while (i--)
> -   drm_mm_remove_node([i]);
> +   drm_mm_remove_node(>mm_nodes[i]);
> spin_unlock(>lock);
> -   atomic64_sub(mem->num_pages << PAGE_SHIFT, >usage);
> +   kvfree(node);
>
> -   kvfree(nodes);
> +error_sub:
> +   atomic64_sub(mem_bytes, >usage);
> return r;
>  }
>
> @@ -481,13 +487,17 @@ static void amdgpu_vram_mgr_del(struct 
> ttm_resource_manager *man,
>  {
> struct amdgpu_vram_mgr *mgr = to_vram_mgr(man);
> struct amdgpu_device *adev = to_amdgpu_device(mgr);
> -   struct drm_mm_node *nodes = mem->mm_node;
> +   struct ttm_range_mgr_node *node;
> uint64_t usage = 0, vis_usage = 0;
> unsigned pages = mem->num_pages;
> +   struct drm_mm_node *nodes;
>
> if

Re: [PATCH] drm: log errors in drm_gem_fb_init_with_funcs

2021-04-30 Thread Michel Dänzer

On 2021-04-30 4:40 p.m., Simon Ser wrote:
> Let the user know what went wrong in drm_gem_fb_init_with_funcs
> failure paths.
> 
> Signed-off-by: Simon Ser 
> Cc: Daniel Vetter 
> Cc: Sam Ravnborg 
> Cc: Noralf Trønnes 
> Cc: Andrzej Pietrasiewicz 
> ---
>  drivers/gpu/drm/drm_gem_framebuffer_helper.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> index 109d11fb4cd4..e4a3c7eb43b2 100644
> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> @@ -155,8 +155,10 @@ int drm_gem_fb_init_with_funcs(struct drm_device *dev,
>   int ret, i;
>  
>   info = drm_get_format_info(dev, mode_cmd);
> - if (!info)
> + if (!info) {
> + drm_dbg_kms(dev, "Failed to get FB format info\n");
>   return -EINVAL;
> + }
>  
>   for (i = 0; i < info->num_planes; i++) {
>   unsigned int width = mode_cmd->width / (i ? info->hsub : 1);
> @@ -175,6 +177,9 @@ int drm_gem_fb_init_with_funcs(struct drm_device *dev,
>+ mode_cmd->offsets[i];
>  
>   if (objs[i]->size < min_size) {
> + drm_dbg_kms(dev,
> + "GEM object size (%u) smaller than minimum 
> size (%u) for plane %d\n",
> + objs[i]->size, min_size, i);
>   drm_gem_object_put(objs[i]);
>   ret = -EINVAL;
>   goto err_gem_object_put;
> 

Reviewed-by: Michel Dänzer 


I made almost the same change (except for the strings) for tracking down the 
issue fixed by https://patchwork.freedesktop.org/patch/431677/ (note my 
follow-up there!). :)


-- 
Earthling Michel Dänzer   |   https://redhat.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 09/13] drm/amdgpu: switch the GTT backend to self alloc

On Fri, 30 Apr 2021 at 10:25, Christian König
 wrote:
>
> Similar to the TTM range manager.
>
> Signed-off-by: Christian König 
Reviewed-by: Matthew Auld 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: log errors in drm_gem_fb_init_with_funcs

2021-04-30 Thread Simon Ser

Let the user know what went wrong in drm_gem_fb_init_with_funcs
failure paths.

Signed-off-by: Simon Ser 
Cc: Daniel Vetter 
Cc: Sam Ravnborg 
Cc: Noralf Trønnes 
Cc: Andrzej Pietrasiewicz 
---
 drivers/gpu/drm/drm_gem_framebuffer_helper.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c 
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index 109d11fb4cd4..e4a3c7eb43b2 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -155,8 +155,10 @@ int drm_gem_fb_init_with_funcs(struct drm_device *dev,
int ret, i;
 
info = drm_get_format_info(dev, mode_cmd);
-   if (!info)
+   if (!info) {
+   drm_dbg_kms(dev, "Failed to get FB format info\n");
return -EINVAL;
+   }
 
for (i = 0; i < info->num_planes; i++) {
unsigned int width = mode_cmd->width / (i ? info->hsub : 1);
@@ -175,6 +177,9 @@ int drm_gem_fb_init_with_funcs(struct drm_device *dev,
 + mode_cmd->offsets[i];
 
if (objs[i]->size < min_size) {
+   drm_dbg_kms(dev,
+   "GEM object size (%u) smaller than minimum 
size (%u) for plane %d\n",
+   objs[i]->size, min_size, i);
drm_gem_object_put(objs[i]);
ret = -EINVAL;
goto err_gem_object_put;
-- 
2.31.1


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

Re: [Intel-gfx] [PATCH] drm/i915: Be more gentle with exiting non-persistent context

On Fri, Apr 30, 2021 at 3:27 PM Tvrtko Ursulin
 wrote:
> On 30/04/2021 12:48, Daniel Vetter wrote:
> > On Thu, Apr 29, 2021 at 10:46:40AM +0100, Tvrtko Ursulin wrote:
> >> From: Tvrtko Ursulin 
> >>
> >> When a non-persistent context exits we currently mark it as banned in
> >> order to trigger fast termination of any outstanding GPU jobs it may have
> >> left running.
> >>
> >> In doing so we apply a very strict 1ms limit in which the left over job
> >> has to preempt before we issues an engine resets.
> >>
> >> Some workloads are not able to cleanly preempt in that time window and it
> >> can be argued that it would instead be better to give them a bit more
> >> grace since avoiding engine resets is generally preferrable.
> >
> > Can you pls explain here why this is preferrable?
>
> I think there's always the risk of an innocent request getting axed with
> preempt to busy being very asynchronous and also engine reset can
> sometimes fail as well.
>
> >> To achieve this the patch splits handling of banned contexts from simply
> >> exited non-persistent ones and then applies different timeouts for both
> >> and also extends the criteria which determines if a request should be
> >> scheduled back in after preemption or not.
> >>
> >> 15ms preempt timeout grace is given to exited non-persistent contexts
> >> which have been empirically tested to satisfy customers requirements
> >> and still provides reasonably quick cleanup post exit.
> >
> > Same here, a bit more detail on what exactly was the problem to be fixed
> > is needed.
>
> It is a bit multi-faceted. Start with how in some cultures errors
> messages are much bigger error flags than in others and much more
> difficult to hand-wave "oh that's not a problem really". The the
> previous considerations about why not avoid engine reset if we can. Add
> on top how non-persistent context exiting is not really an error worthy
> of a reset, *if* it exits cleanly reasonably quickly.
>
> You could say make it clean up for itself before it exits, not a kernel
> problem. But on the balance of everything, to me it sounds saleable to
> just give it some longer time compared to banned contexts, which are the
> unquestionably naughty/dangerous ones. Also, how fast non-persistent
> contexts will be cleaned up hasn't been defined really. As long as 15ms
> is an order of magnitude, plus some, shorter than the normal preempt
> timeout I think it is fine.

Yeah I think makes all sense, I just asked since the commit message
hinted at reasons but didn't explain any of them. I also assume that
generally the full reset flow is also on the order of 1ms (haven't
checked, but it's not cheap), so not being aggressive with engaging
that hammer is imo itself a very good reason to be a notch more lax
here.
-Danie

>
> Regards,
>
> Tvrtko
>
> P.S. Otherwise I plan to respin v2 with consolidated CONTEXT_SCHEDULABLE
> flag so fast paths do not have to do too many individual checks.
>
> > -Daniel
> >
> >>
> >> Signed-off-by: Tvrtko Ursulin 
> >> Cc: Chris Wilson 
> >> Cc: Zhen Han 
> >> ---
> >>   drivers/gpu/drm/i915/gem/i915_gem_context.c | 15 +--
> >>   drivers/gpu/drm/i915/gt/intel_context.h | 17 +
> >>   drivers/gpu/drm/i915/gt/intel_context_types.h   |  1 +
> >>   .../drm/i915/gt/intel_execlists_submission.c| 12 ++--
> >>   drivers/gpu/drm/i915/i915_request.c |  2 +-
> >>   5 files changed, 38 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> >> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> >> index fd8ee52e17a4..5a6eba1232cd 100644
> >> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> >> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> >> @@ -426,7 +426,8 @@ static struct intel_engine_cs *active_engine(struct 
> >> intel_context *ce)
> >>  return engine;
> >>   }
> >>
> >> -static void kill_engines(struct i915_gem_engines *engines, bool ban)
> >> +static void
> >> +kill_engines(struct i915_gem_engines *engines, bool ban, bool persistent)
> >>   {
> >>  struct i915_gem_engines_iter it;
> >>  struct intel_context *ce;
> >> @@ -443,6 +444,8 @@ static void kill_engines(struct i915_gem_engines 
> >> *engines, bool ban)
> >>
> >>  if (ban && intel_context_set_banned(ce))
> >>  continue;
> >> +else if (!persistent && intel_context_set_non_persistent(ce))
> >> +continue;
> >>
> >>  /*
> >>   * Check the current active state of this context; if we
> >> @@ -454,7 +457,7 @@ static void kill_engines(struct i915_gem_engines 
> >> *engines, bool ban)
> >>  engine = active_engine(ce);
> >>
> >>  /* First attempt to gracefully cancel the context */
> >> -if (engine && !__cancel_engine(engine) && ban)
> >> +if (engine && !__cancel_engine(engine) && (ban || 
> >> !persistent))
> >>  /*
> >>

Re: [PATCH 1/9] drm/connector: Make the drm_sysfs connector->kdev device hold a reference to the connector

On Fri, Apr 30, 2021 at 3:32 PM Hans de Goede  wrote:
>
> Hi,
>
> On 4/30/21 1:38 PM, Daniel Vetter wrote:
> > On Fri, Apr 30, 2021 at 1:28 PM Hans de Goede  wrote:
> >>
> >> Hi,
> >>
> >> On 4/29/21 9:09 PM, Daniel Vetter wrote:
> >>> On Thu, Apr 29, 2021 at 02:33:17PM +0200, Hans de Goede wrote:
>  Hi,
> 
>  On 4/29/21 2:04 PM, Daniel Vetter wrote:
> > On Thu, Apr 29, 2021 at 01:54:46PM +0200, Greg Kroah-Hartman wrote:
> >> On Thu, Apr 29, 2021 at 01:40:28PM +0200, Daniel Vetter wrote:
> >>> On Wed, Apr 28, 2021 at 11:52:49PM +0200, Hans de Goede wrote:
>  Userspace could hold open a reference to the connector->kdev device,
>  through e.g. holding a sysfs-atrtribute open after
>  drm_sysfs_connector_remove() has been called. In this case the 
>  connector
>  could be free-ed while the connector->kdev device's drvdata is still
>  pointing to it.
> 
>  Give drm_connector devices there own device type, which allows
>  us to specify our own release function and make 
>  drm_sysfs_connector_add()
>  take a reference on the connector object, and have the new release
>  function put the reference when the device is released.
> 
>  Giving drm_connector devices there own device type, will also allow
>  checking if a device is a drm_connector device with a
>  "if (device->type == _sysfs_device_connector)" check.
> 
>  Note that the setting of the name member of the device_type struct 
>  will
>  cause udev events for drm_connector-s to now contain 
>  DEVTYPE=drm_connector
>  as extra info. So this extends the uevent part of the userspace API.
> 
>  Signed-off-by: Hans de Goede 
> >>>
> >>> Are you sure? I thought sysfs is supposed to flush out any pending
> >>> operations (they complete fast) and handle open fd internally?
> >>
> >> Yes, it "should" :)
> >
> > Thanks for confirming my vague memories :-)
> >
> > Hans, pls drop this one.
> 
>  Please see my earlier reply to your review of this patch, it is
>  still needed but for a different reason:
> 
>  """
>  We still need this change though to make sure that the
>  "drm/connector: Add drm_connector_find_by_fwnode() function"
>  does not end up following a dangling drvdat pointer from one
>  if the drm_connector kdev-s.
> 
>  The class_dev_iter_init() in drm_connector_find_by_fwnode() gets
>  a reference on all devices and between getting that reference
>  and it calling drm_connector_get() - drm_connector_unregister()
>  may run and drop the possibly last reference to the
>  drm_connector object, freeing it and leaving the kdev's
>  drvdata as a dangling pointer.
>  """
> 
>  This is actually why I added it initially, and while adding it
>  I came up with this wrong theory of why it was necessary independently
>  of the drm_connector_find_by_fwnode() addition, sorry about that.
> >>>
> >>> Generally that's handled by a kref_get_unless_zero under the protection of
> >>> the lock which protects the weak reference. Which I think is the right
> >>> model here (at a glance at least) since this is a lookup function.
> >>
> >> I'm afraid that things are a bit more complicated here. The idea here
> >> is that we have a subsystem outside of the DRM subsystem which received
> >> a hotplug event for a drm-connector.  The only info which this subsystem
> >> has is a reference on the fwnode level (either through device-tree or
> >> to platform-code instantiating software-fwnode-s + links for this).
> >>
> >> So in order to deliver the hotplug event to the connector we need
> >> to lookup the connector by fwnode.
> >>
> >> I've chosen to implement this by iterating over all drm_class
> >> devices with a dev_type of drm_connector using class_dev_iter_init()
> >> and friends. This makes sure that we either get a reference to
> >> the device, or that we skip the device if it is being deleted.
> >>
> >> But this just gives us a reference to the connector->kdev, not
> >> to the connector itself. A pointer to the connector itself is stored
> >> as drvdata inside the device, but without taking a reference as
> >> this patch does, there is no guarantee that that pointer does not
> >> point to possibly free-ed mem.
> >>
> >> We could set drvdata to 0 from drm_sysfs_connector_remove()
> >> Before calling device_unregister(connector->kdev) and then do
> >> something like this inside drm_connector_find_by_fwnode():
> >>
> >> /*
> >>  * Lock the device to ensure we either see the drvdata == NULL
> >>  * set by drm_sysfs_connector_remove(); or we block the removal
> >>  * from continuing until we are done with the device.
> >>  */
> >> device_lock(dev);
> >> connector = dev_get_drvdata(dev);
> >> if (connector && connector->fwnode == fwnode) {
> >>

[PATCH v2] drm/i915: Be more gentle with exiting non-persistent context

From: Tvrtko Ursulin 

When a non-persistent context exits we currently mark it as banned in
order to trigger fast termination of any outstanding GPU jobs it may have
left running.

In doing so we apply a very strict 1ms limit in which the left over job
has to preempt before we issues an engine resets.

Some workloads are not able to cleanly preempt in that time window and it
can be argued that it would instead be better to give them a bit more
grace since avoiding engine resets is generally preferrable.

To achieve this the patch splits handling of banned contexts from simply
exited non-persistent ones and then applies different timeouts for both
and also extends the criteria which determines if a request should be
scheduled back in after preemption or not.

15ms preempt timeout grace is given to exited non-persistent contexts
which have been empirically tested to satisfy customers requirements
and still provides reasonably quick cleanup post exit.

v2:
 * Streamline fast path checks.

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Zhen Han 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c   | 16 +--
 drivers/gpu/drm/i915/gt/intel_context.c   |  2 ++
 drivers/gpu/drm/i915/gt/intel_context.h   | 20 +++
 drivers/gpu/drm/i915/gt/intel_context_types.h |  2 ++
 .../drm/i915/gt/intel_execlists_submission.c  | 11 --
 drivers/gpu/drm/i915/i915_request.c   |  2 +-
 6 files changed, 44 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index fd8ee52e17a4..090c891f029b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -426,7 +426,8 @@ static struct intel_engine_cs *active_engine(struct 
intel_context *ce)
return engine;
 }
 
-static void kill_engines(struct i915_gem_engines *engines, bool ban)
+static void
+kill_engines(struct i915_gem_engines *engines, bool ban, bool persistent)
 {
struct i915_gem_engines_iter it;
struct intel_context *ce;
@@ -443,6 +444,9 @@ static void kill_engines(struct i915_gem_engines *engines, 
bool ban)
 
if (ban && intel_context_set_banned(ce))
continue;
+   else if (!persistent &&
+intel_context_set_closed_non_persistent(ce))
+   continue;
 
/*
 * Check the current active state of this context; if we
@@ -454,7 +458,7 @@ static void kill_engines(struct i915_gem_engines *engines, 
bool ban)
engine = active_engine(ce);
 
/* First attempt to gracefully cancel the context */
-   if (engine && !__cancel_engine(engine) && ban)
+   if (engine && !__cancel_engine(engine) && (ban || !persistent))
/*
 * If we are unable to send a preemptive pulse to bump
 * the context from the GPU, we have to resort to a full
@@ -466,8 +470,6 @@ static void kill_engines(struct i915_gem_engines *engines, 
bool ban)
 
 static void kill_context(struct i915_gem_context *ctx)
 {
-   bool ban = (!i915_gem_context_is_persistent(ctx) ||
-   !ctx->i915->params.enable_hangcheck);
struct i915_gem_engines *pos, *next;
 
spin_lock_irq(>stale.lock);
@@ -480,7 +482,8 @@ static void kill_context(struct i915_gem_context *ctx)
 
spin_unlock_irq(>stale.lock);
 
-   kill_engines(pos, ban);
+   kill_engines(pos, !ctx->i915->params.enable_hangcheck,
+i915_gem_context_is_persistent(ctx));
 
spin_lock_irq(>stale.lock);
GEM_BUG_ON(i915_sw_fence_signaled(>fence));
@@ -526,7 +529,8 @@ static void engines_idle_release(struct i915_gem_context 
*ctx,
 
 kill:
if (list_empty(>link)) /* raced, already closed */
-   kill_engines(engines, true);
+   kill_engines(engines, true,
+i915_gem_context_is_persistent(ctx));
 
i915_sw_fence_commit(>fence);
 }
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c 
b/drivers/gpu/drm/i915/gt/intel_context.c
index 17cf2640b082..efbda677a0a8 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -374,6 +374,8 @@ intel_context_init(struct intel_context *ce, struct 
intel_engine_cs *engine)
ce->sseu = engine->sseu;
ce->ring = __intel_context_ring_size(SZ_4K);
 
+   __set_bit(CONTEXT_SCHEDULABLE, >flags);
+
ewma_runtime_init(>runtime.avg);
 
ce->vm = i915_vm_get(engine->gt->vm);
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h 
b/drivers/gpu/drm/i915/gt/intel_context.h
index f83a73a2b39f..a6d4c2d7f2f5 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -217,9 +217,29 @@ static inline bool

Re: [PATCH 1/9] drm/connector: Make the drm_sysfs connector->kdev device hold a reference to the connector

2021-04-30 Thread Hans de Goede

p.s.

On 4/30/21 1:38 PM, Daniel Vetter wrote:

Offtopic:

> I'm also not sure why we have to use the kdev stuff here. For other
> random objects we need to look up we're building that functionality on
> that object. It means you need to keep another list_head around for
> that lookup, but that's really not a big cost. E.g. drm_bridge/panel
> work like that.

So I took a peek at the bridge/panel code and that actually seems to
have an issue with removal vs lookup. It is not even just a race,
it seems a lookup does not take a reference and there is nothing
stopping a user from doing an unbind or rmmod causing the panel
to be removed while other code which got a pointer to the panel
through of_drm_find_panel() will not be prepared to deal with
that pointer all of a sudden no longer being valid.

Now this would be a case of the user shooting his-self in the
foot (where as connectors can actually dynamically disappear
under normal circumstances), but ideally we really should do
better here.

Is there a TODO list somewhere for issues like this ?  Or shall
I submit a patch adding a FIXME comment, or is this considered
not worth the trouble of fixing it?

Regards,

Hans

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

Re: [PATCH 1/9] drm/connector: Make the drm_sysfs connector->kdev device hold a reference to the connector

2021-04-30 Thread Hans de Goede

Hi,

On 4/30/21 1:38 PM, Daniel Vetter wrote:
> On Fri, Apr 30, 2021 at 1:28 PM Hans de Goede  wrote:
>>
>> Hi,
>>
>> On 4/29/21 9:09 PM, Daniel Vetter wrote:
>>> On Thu, Apr 29, 2021 at 02:33:17PM +0200, Hans de Goede wrote:
 Hi,

 On 4/29/21 2:04 PM, Daniel Vetter wrote:
> On Thu, Apr 29, 2021 at 01:54:46PM +0200, Greg Kroah-Hartman wrote:
>> On Thu, Apr 29, 2021 at 01:40:28PM +0200, Daniel Vetter wrote:
>>> On Wed, Apr 28, 2021 at 11:52:49PM +0200, Hans de Goede wrote:
 Userspace could hold open a reference to the connector->kdev device,
 through e.g. holding a sysfs-atrtribute open after
 drm_sysfs_connector_remove() has been called. In this case the 
 connector
 could be free-ed while the connector->kdev device's drvdata is still
 pointing to it.

 Give drm_connector devices there own device type, which allows
 us to specify our own release function and make 
 drm_sysfs_connector_add()
 take a reference on the connector object, and have the new release
 function put the reference when the device is released.

 Giving drm_connector devices there own device type, will also allow
 checking if a device is a drm_connector device with a
 "if (device->type == _sysfs_device_connector)" check.

 Note that the setting of the name member of the device_type struct will
 cause udev events for drm_connector-s to now contain 
 DEVTYPE=drm_connector
 as extra info. So this extends the uevent part of the userspace API.

 Signed-off-by: Hans de Goede 
>>>
>>> Are you sure? I thought sysfs is supposed to flush out any pending
>>> operations (they complete fast) and handle open fd internally?
>>
>> Yes, it "should" :)
>
> Thanks for confirming my vague memories :-)
>
> Hans, pls drop this one.

 Please see my earlier reply to your review of this patch, it is
 still needed but for a different reason:

 """
 We still need this change though to make sure that the
 "drm/connector: Add drm_connector_find_by_fwnode() function"
 does not end up following a dangling drvdat pointer from one
 if the drm_connector kdev-s.

 The class_dev_iter_init() in drm_connector_find_by_fwnode() gets
 a reference on all devices and between getting that reference
 and it calling drm_connector_get() - drm_connector_unregister()
 may run and drop the possibly last reference to the
 drm_connector object, freeing it and leaving the kdev's
 drvdata as a dangling pointer.
 """

 This is actually why I added it initially, and while adding it
 I came up with this wrong theory of why it was necessary independently
 of the drm_connector_find_by_fwnode() addition, sorry about that.
>>>
>>> Generally that's handled by a kref_get_unless_zero under the protection of
>>> the lock which protects the weak reference. Which I think is the right
>>> model here (at a glance at least) since this is a lookup function.
>>
>> I'm afraid that things are a bit more complicated here. The idea here
>> is that we have a subsystem outside of the DRM subsystem which received
>> a hotplug event for a drm-connector.  The only info which this subsystem
>> has is a reference on the fwnode level (either through device-tree or
>> to platform-code instantiating software-fwnode-s + links for this).
>>
>> So in order to deliver the hotplug event to the connector we need
>> to lookup the connector by fwnode.
>>
>> I've chosen to implement this by iterating over all drm_class
>> devices with a dev_type of drm_connector using class_dev_iter_init()
>> and friends. This makes sure that we either get a reference to
>> the device, or that we skip the device if it is being deleted.
>>
>> But this just gives us a reference to the connector->kdev, not
>> to the connector itself. A pointer to the connector itself is stored
>> as drvdata inside the device, but without taking a reference as
>> this patch does, there is no guarantee that that pointer does not
>> point to possibly free-ed mem.
>>
>> We could set drvdata to 0 from drm_sysfs_connector_remove()
>> Before calling device_unregister(connector->kdev) and then do
>> something like this inside drm_connector_find_by_fwnode():
>>
>> /*
>>  * Lock the device to ensure we either see the drvdata == NULL
>>  * set by drm_sysfs_connector_remove(); or we block the removal
>>  * from continuing until we are done with the device.
>>  */
>> device_lock(dev);
>> connector = dev_get_drvdata(dev);
>> if (connector && connector->fwnode == fwnode) {
>> drm_connector_get(connector);
>> found = connector;
>> }
>> device_unlock(dev);
> 
> Yes this is what I mean. Except not a drm_connector_get, but a
> kref_get_unless_zero. The connector might already be on it's way out,
> but the drvdata not yet cleared.

The function we

Re: [Intel-gfx] [PATCH] drm/i915: Be more gentle with exiting non-persistent context




On 30/04/2021 12:48, Daniel Vetter wrote:

On Thu, Apr 29, 2021 at 10:46:40AM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

When a non-persistent context exits we currently mark it as banned in
order to trigger fast termination of any outstanding GPU jobs it may have
left running.

In doing so we apply a very strict 1ms limit in which the left over job
has to preempt before we issues an engine resets.

Some workloads are not able to cleanly preempt in that time window and it
can be argued that it would instead be better to give them a bit more
grace since avoiding engine resets is generally preferrable.


Can you pls explain here why this is preferrable?


I think there's always the risk of an innocent request getting axed with 
preempt to busy being very asynchronous and also engine reset can 
sometimes fail as well.



To achieve this the patch splits handling of banned contexts from simply
exited non-persistent ones and then applies different timeouts for both
and also extends the criteria which determines if a request should be
scheduled back in after preemption or not.

15ms preempt timeout grace is given to exited non-persistent contexts
which have been empirically tested to satisfy customers requirements
and still provides reasonably quick cleanup post exit.


Same here, a bit more detail on what exactly was the problem to be fixed
is needed.


It is a bit multi-faceted. Start with how in some cultures errors 
messages are much bigger error flags than in others and much more 
difficult to hand-wave "oh that's not a problem really". The the 
previous considerations about why not avoid engine reset if we can. Add 
on top how non-persistent context exiting is not really an error worthy 
of a reset, *if* it exits cleanly reasonably quickly.


You could say make it clean up for itself before it exits, not a kernel 
problem. But on the balance of everything, to me it sounds saleable to 
just give it some longer time compared to banned contexts, which are the 
unquestionably naughty/dangerous ones. Also, how fast non-persistent 
contexts will be cleaned up hasn't been defined really. As long as 15ms 
is an order of magnitude, plus some, shorter than the normal preempt 
timeout I think it is fine.


Regards,

Tvrtko

P.S. Otherwise I plan to respin v2 with consolidated CONTEXT_SCHEDULABLE 
flag so fast paths do not have to do too many individual checks.



-Daniel



Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Zhen Han 
---
  drivers/gpu/drm/i915/gem/i915_gem_context.c | 15 +--
  drivers/gpu/drm/i915/gt/intel_context.h | 17 +
  drivers/gpu/drm/i915/gt/intel_context_types.h   |  1 +
  .../drm/i915/gt/intel_execlists_submission.c| 12 ++--
  drivers/gpu/drm/i915/i915_request.c |  2 +-
  5 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index fd8ee52e17a4..5a6eba1232cd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -426,7 +426,8 @@ static struct intel_engine_cs *active_engine(struct 
intel_context *ce)
return engine;
  }
  
-static void kill_engines(struct i915_gem_engines *engines, bool ban)

+static void
+kill_engines(struct i915_gem_engines *engines, bool ban, bool persistent)
  {
struct i915_gem_engines_iter it;
struct intel_context *ce;
@@ -443,6 +444,8 @@ static void kill_engines(struct i915_gem_engines *engines, 
bool ban)
  
  		if (ban && intel_context_set_banned(ce))

continue;
+   else if (!persistent && intel_context_set_non_persistent(ce))
+   continue;
  
  		/*

 * Check the current active state of this context; if we
@@ -454,7 +457,7 @@ static void kill_engines(struct i915_gem_engines *engines, 
bool ban)
engine = active_engine(ce);
  
  		/* First attempt to gracefully cancel the context */

-   if (engine && !__cancel_engine(engine) && ban)
+   if (engine && !__cancel_engine(engine) && (ban || !persistent))
/*
 * If we are unable to send a preemptive pulse to bump
 * the context from the GPU, we have to resort to a full
@@ -466,8 +469,6 @@ static void kill_engines(struct i915_gem_engines *engines, 
bool ban)
  
  static void kill_context(struct i915_gem_context *ctx)

  {
-   bool ban = (!i915_gem_context_is_persistent(ctx) ||
-   !ctx->i915->params.enable_hangcheck);
struct i915_gem_engines *pos, *next;
  
  	spin_lock_irq(>stale.lock);

@@ -480,7 +481,8 @@ static void kill_context(struct i915_gem_context *ctx)
  
  		spin_unlock_irq(>stale.lock);
  
-		kill_engines(pos, ban);

+   kill_engines(pos, !ctx->i915->params.enable_hangcheck,
+i915_gem_context_is_persistent(ctx));

Re: [PATCH 07/13] drm/ttm: flip over the sys manager to self allocated nodes

On Fri, 30 Apr 2021 at 10:25, Christian König
 wrote:
>
> Make sure to allocate a resource object here.
>
> Signed-off-by: Christian König 

Ok, I guess I have to keep reading,
Reviewed-by: Matthew Auld 

> ---
>  drivers/gpu/drm/ttm/ttm_sys_manager.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_sys_manager.c 
> b/drivers/gpu/drm/ttm/ttm_sys_manager.c
> index ed92615214e3..a926114edfe5 100644
> --- a/drivers/gpu/drm/ttm/ttm_sys_manager.c
> +++ b/drivers/gpu/drm/ttm/ttm_sys_manager.c
> @@ -3,18 +3,25 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  static int ttm_sys_man_alloc(struct ttm_resource_manager *man,
>  struct ttm_buffer_object *bo,
>  const struct ttm_place *place,
>  struct ttm_resource *mem)
>  {
> +   mem->mm_node = kzalloc(sizeof(*mem), GFP_KERNEL);
> +   if (!mem->mm_node)
> +   return -ENOMEM;
> +
> +   ttm_resource_init(bo, place, mem->mm_node);
> return 0;
>  }
>
>  static void ttm_sys_man_free(struct ttm_resource_manager *man,
>  struct ttm_resource *mem)
>  {
> +   kfree(mem->mm_node);
>  }
>
>  static const struct ttm_resource_manager_func ttm_sys_manager_func = {
> --
> 2.25.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 16/21] drm/i915/gem: Delay context creation

On 30/04/2021 14:07, Daniel Vetter wrote:

On Fri, Apr 30, 2021 at 2:44 PM Tvrtko Ursulin
wrote:

On 30/04/2021 13:30, Daniel Vetter wrote:

On Fri, Apr 30, 2021 at 1:58 PM Tvrtko Ursulin
wrote:

On 30/04/2021 07:53, Daniel Vetter wrote:

On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand wrote:

On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter wrote:

On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason Ekstrand wrote:

On Thu, Apr 29, 2021 at 1:56 PM Daniel Vetter wrote:

On Thu, Apr 29, 2021 at 01:16:04PM -0500, Jason Ekstrand wrote:

On Thu, Apr 29, 2021 at 10:51 AM Daniel Vetter wrote:

+ ret = set_proto_ctx_param(file_priv, pc, args);

I think we should have a FIXME here of not allowing this on some future
platforms because just use CTX_CREATE_EXT.

Done.

+ if (ret == -ENOTSUPP) {
+ /* Some params, specifically SSEU, can only be set on fully

I think this needs a FIXME: that this only holds during the conversion?
Otherwise we kinda have a bit a problem me thinks ...

I'm not sure what you mean by that.

Well I'm at least assuming that we wont have this case anymore, i.e.
there's only two kinds of parameters:
- those which are valid only on proto context
- those which are valid on both (like priority)

This SSEU thing looks like a 3rd parameter, which is only valid on
finalized context. That feels all kinds of wrong. Will it stay? If yes
*ugh* and why?

Because I was being lazy. The SSEU stuff is a fairly complex param to
parse and it's always set live. I can factor out the SSEU parsing
code if you want and it shouldn't be too bad in the end.

Yeah I think the special case here is a bit too jarring.

I rolled a v5 that allows you to set SSEU as a create param. I'm not
a huge fan of that much code duplication for the SSEU set but I guess
that's what we get for deciding to "unify" our context creation
parameter path with our on-the-fly parameter path

You can look at it here:

https://gitlab.freedesktop.org/jekstrand/linux/-/commit/c805f424a3374b2de405b7fc651eab551df2cdaf#474deb1194892a272db022ff175872d42004dfda_283_588

Hm yeah the duplication of the render engine check is a bit annoying.
What's worse, if you tthrow another set_engines on top it's probably
all wrong then. The old thing solved that by just throwing that
intel_context away.

You're also not keeping the engine id in the proto ctx for this, so
there's probably some gaps there. We'd need to clear the SSEU if
userspace puts another context there. But also no userspace does that.

Plus cursory review of userspace show
- mesa doesn't set this
- compute sets its right before running the batch
- media sets it as the last thing of context creation

Noticed a long sub-thread so looked inside..

SSEU is a really an interesting one.

For current userspace limiting to context creation is fine, since it is
only allowed for Icelake/VME use case. But if you notice the comment inside:

/* ABI restriction - VME use case only. */

It is a hint there was, or could be, more to this uapi than that.

And from memory I think limiting to creation time will nip the hopes
media had to use this dynamically on other platforms in the bud. So not
that good really. They had convincing numbers what gets significantly
better if we allowed dynamic control to this, just that as always, open
source userspace was not there so we never allowed it. However if you
come up with a new world order where it can only be done at context
creation, as said already, the possibility for that improvement (aka
further improving the competitive advantage) is most likely dashed.

Hm are you sure that this is create-time only? media-driver uses it
like that, but from my checking compute-runtime updates SSEU mode
before every execbuf call. So it very much looked like we have to keep
this dynamic.

Ah okay, I assumed it's more of the overall drive to eliminate
set_param. If sseu set_param stays then it's fine for what I had in mind.

Or do you mean this is defacto dead code? this = compute setting it
before every batch I mean here.

No idea, wasn't aware of the compute usage.

Before every execbuf is not very ideal though since we have to inject a
foreign context operation to update context image, which means stream of
work belonging to the context cannot be coalesced (assuming it could to
start with). There is also a hw cost to reconfigure the sseu which adds
latency on top.

They filter out no-op changes. I just meant that from look at
compute-runtime, it seems like sseu can change whenever.

i915 does it as well for good measure - since the penalty is global we
have to. So I guess they don't know when VME block will be used ie it is
per batch.

Regards,

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

Re: [PATCH 06/13] drm/ttm: flip over the range manager to self allocated nodes

On Fri, 30 Apr 2021 at 10:25, Christian König
 wrote:
>
> Start with the range manager to make the resource object the base
> class for the allocated nodes.
>
> While at it cleanup a lot of the code around that.
>
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |  1 +
>  drivers/gpu/drm/drm_gem_vram_helper.c   |  2 +
>  drivers/gpu/drm/nouveau/nouveau_ttm.c   |  1 +
>  drivers/gpu/drm/qxl/qxl_ttm.c   |  1 +
>  drivers/gpu/drm/radeon/radeon_ttm.c |  1 +
>  drivers/gpu/drm/ttm/ttm_range_manager.c | 56 ++---
>  drivers/gpu/drm/ttm/ttm_resource.c  | 26 
>  include/drm/ttm/ttm_bo_driver.h | 26 
>  include/drm/ttm/ttm_range_manager.h | 43 +++
>  include/drm/ttm/ttm_resource.h  |  3 ++
>  10 files changed, 110 insertions(+), 50 deletions(-)
>  create mode 100644 include/drm/ttm/ttm_range_manager.h
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 3fe2482a40b4..3d5863262337 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -46,6 +46,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include 
>
> diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c 
> b/drivers/gpu/drm/drm_gem_vram_helper.c
> index 83e7258c7f90..17a4c5d47b6a 100644
> --- a/drivers/gpu/drm/drm_gem_vram_helper.c
> +++ b/drivers/gpu/drm/drm_gem_vram_helper.c
> @@ -17,6 +17,8 @@
>  #include 
>  #include 
>
> +#include 
> +
>  static const struct drm_gem_object_funcs drm_gem_vram_object_funcs;
>
>  /**
> diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
> b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> index b81ae90b8449..15c7627f8f58 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> @@ -32,6 +32,7 @@
>  #include "nouveau_ttm.h"
>
>  #include 
> +#include 
>
>  #include 
>
> diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
> index 8aa87b8edb9c..19fd39d9a00c 100644
> --- a/drivers/gpu/drm/qxl/qxl_ttm.c
> +++ b/drivers/gpu/drm/qxl/qxl_ttm.c
> @@ -32,6 +32,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "qxl_drv.h"
>  #include "qxl_object.h"
> diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
> b/drivers/gpu/drm/radeon/radeon_ttm.c
> index 5191e994bff7..c3d2f1fce71a 100644
> --- a/drivers/gpu/drm/radeon/radeon_ttm.c
> +++ b/drivers/gpu/drm/radeon/radeon_ttm.c
> @@ -46,6 +46,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "radeon_reg.h"
>  #include "radeon.h"
> diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c 
> b/drivers/gpu/drm/ttm/ttm_range_manager.c
> index b9d5da6e6a81..ce5d07ca384c 100644
> --- a/drivers/gpu/drm/ttm/ttm_range_manager.c
> +++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
> @@ -29,12 +29,13 @@
>   * Authors: Thomas Hellstrom 
>   */
>
> -#include 
> +#include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> -#include 
>
>  /*
>   * Currently we use a spinlock for the lock, but a mutex *may* be
> @@ -60,8 +61,8 @@ static int ttm_range_man_alloc(struct ttm_resource_manager 
> *man,
>struct ttm_resource *mem)
>  {
> struct ttm_range_manager *rman = to_range_manager(man);
> +   struct ttm_range_mgr_node *node;
> struct drm_mm *mm = >mm;
> -   struct drm_mm_node *node;
> enum drm_mm_insert_mode mode;
> unsigned long lpfn;
> int ret;
> @@ -70,7 +71,7 @@ static int ttm_range_man_alloc(struct ttm_resource_manager 
> *man,
> if (!lpfn)
> lpfn = man->size;
>
> -   node = kzalloc(sizeof(*node), GFP_KERNEL);
> +   node = kzalloc(struct_size(node, mm_nodes, 1), GFP_KERNEL);
> if (!node)
> return -ENOMEM;
>
> @@ -78,17 +79,19 @@ static int ttm_range_man_alloc(struct 
> ttm_resource_manager *man,
> if (place->flags & TTM_PL_FLAG_TOPDOWN)
> mode = DRM_MM_INSERT_HIGH;
>
> +   ttm_resource_init(bo, place, >base);
> +
> spin_lock(>lock);
> -   ret = drm_mm_insert_node_in_range(mm, node, mem->num_pages,
> - bo->page_alignment, 0,
> +   ret = drm_mm_insert_node_in_range(mm, >mm_nodes[0],
> + mem->num_pages, bo->page_alignment, 
> 0,
>   place->fpfn, lpfn, mode);
> spin_unlock(>lock);
>
> if (unlikely(ret)) {
> kfree(node);
> } else {
> -   mem->mm_node = node;
> -   mem->start = node->start;
> +   mem->mm_node = >mm_nodes[0];
> +   mem->start = node->mm_nodes[0].start;
> }
>
> return ret;
> @@ -98,15 +101,19 @@ static void ttm_range_man_free(struct 
> ttm_resource_manager *man,
>struct ttm_resource *mem)
>  {
> struct

Re: [Intel-gfx] [PATCH 16/21] drm/i915/gem: Delay context creation

On Fri, Apr 30, 2021 at 2:44 PM Tvrtko Ursulin
 wrote:
>
>
>
> On 30/04/2021 13:30, Daniel Vetter wrote:
> > On Fri, Apr 30, 2021 at 1:58 PM Tvrtko Ursulin
> >  wrote:
> >> On 30/04/2021 07:53, Daniel Vetter wrote:
> >>> On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand  
> >>> wrote:
> 
>  On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter  wrote:
> >
> > On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason Ekstrand wrote:
> >> On Thu, Apr 29, 2021 at 1:56 PM Daniel Vetter  wrote:
> >>> On Thu, Apr 29, 2021 at 01:16:04PM -0500, Jason Ekstrand wrote:
>  On Thu, Apr 29, 2021 at 10:51 AM Daniel Vetter  
>  wrote:
> >> + ret = set_proto_ctx_param(file_priv, pc, args);
> >
> > I think we should have a FIXME here of not allowing this on some 
> > future
> > platforms because just use CTX_CREATE_EXT.
> 
>  Done.
> 
> >> + if (ret == -ENOTSUPP) {
> >> + /* Some params, specifically SSEU, can only be set 
> >> on fully
> >
> > I think this needs a FIXME: that this only holds during the 
> > conversion?
> > Otherwise we kinda have a bit a problem me thinks ...
> 
>  I'm not sure what you mean by that.
> >>>
> >>> Well I'm at least assuming that we wont have this case anymore, i.e.
> >>> there's only two kinds of parameters:
> >>> - those which are valid only on proto context
> >>> - those which are valid on both (like priority)
> >>>
> >>> This SSEU thing looks like a 3rd parameter, which is only valid on
> >>> finalized context. That feels all kinds of wrong. Will it stay? If yes
> >>> *ugh* and why?
> >>
> >> Because I was being lazy.  The SSEU stuff is a fairly complex param to
> >> parse and it's always set live.  I can factor out the SSEU parsing
> >> code if you want and it shouldn't be too bad in the end.
> >
> > Yeah I think the special case here is a bit too jarring.
> 
>  I rolled a v5 that allows you to set SSEU as a create param.  I'm not
>  a huge fan of that much code duplication for the SSEU set but I guess
>  that's what we get for deciding to "unify" our context creation
>  parameter path with our on-the-fly parameter path
> 
>  You can look at it here:
> 
>  https://gitlab.freedesktop.org/jekstrand/linux/-/commit/c805f424a3374b2de405b7fc651eab551df2cdaf#474deb1194892a272db022ff175872d42004dfda_283_588
> >>>
> >>> Hm yeah the duplication of the render engine check is a bit annoying.
> >>> What's worse, if you tthrow another set_engines on top it's probably
> >>> all wrong then. The old thing solved that by just throwing that
> >>> intel_context away.
> >>>
> >>> You're also not keeping the engine id in the proto ctx for this, so
> >>> there's probably some gaps there. We'd need to clear the SSEU if
> >>> userspace puts another context there. But also no userspace does that.
> >>>
> >>> Plus cursory review of userspace show
> >>> - mesa doesn't set this
> >>> - compute sets its right before running the batch
> >>> - media sets it as the last thing of context creation
> >>
> >> Noticed a long sub-thread so looked inside..
> >>
> >> SSEU is a really an interesting one.
> >>
> >> For current userspace limiting to context creation is fine, since it is
> >> only allowed for Icelake/VME use case. But if you notice the comment 
> >> inside:
> >>
> >>  /* ABI restriction - VME use case only. */
> >>
> >> It is a hint there was, or could be, more to this uapi than that.
> >>
> >> And from memory I think limiting to creation time will nip the hopes
> >> media had to use this dynamically on other platforms in the bud. So not
> >> that good really. They had convincing numbers what gets significantly
> >> better if we allowed dynamic control to this, just that as always, open
> >> source userspace was not there so we never allowed it. However if you
> >> come up with a new world order where it can only be done at context
> >> creation, as said already, the possibility for that improvement (aka
> >> further improving the competitive advantage) is most likely dashed.
> >
> > Hm are you sure that this is create-time only? media-driver uses it
> > like that, but from my checking compute-runtime updates SSEU mode
> > before every execbuf call. So it very much looked like we have to keep
> > this dynamic.
>
> Ah okay, I assumed it's more of the overall drive to eliminate
> set_param. If sseu set_param stays then it's fine for what I had in mind.
>
> > Or do you mean this is defacto dead code? this = compute setting it
> > before every batch I mean here.
>
> No idea, wasn't aware of the compute usage.
>
> Before every execbuf is not very ideal though since we have to inject a
> foreign context operation to update context image, which means stream of
> work belonging to the context cannot be coalesced (assuming it could to
>

Re: [PATCH 02/13] drm/ttm: always initialize the full ttm_resource

2021-04-30 Thread Christian König


Am 30.04.21 um 14:05 schrieb Matthew Auld:

On Fri, 30 Apr 2021 at 10:25, Christian König
 wrote:

Init all fields in ttm_resource_alloc() when we create a new resource.

Signed-off-by: Christian König 
Reviewed-by: Matthew Auld 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |  2 --
  drivers/gpu/drm/ttm/ttm_bo.c| 26 -
  drivers/gpu/drm/ttm/ttm_bo_util.c   |  4 ++--
  drivers/gpu/drm/ttm/ttm_resource.c  |  9 +
  4 files changed, 15 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 7ba761e833ba..2f7580d2ee71 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -1015,8 +1015,6 @@ int amdgpu_ttm_alloc_gart(struct ttm_buffer_object *bo)
 } else {

 /* allocate GART space */
-   tmp = bo->mem;
-   tmp.mm_node = NULL;
 placement.num_placement = 1;
 placement.placement = 
 placement.num_busy_placement = 1;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index df63a07a70de..55f1ddcf22b6 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -507,11 +507,6 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
 return ttm_tt_create(bo, false);
 }

-   evict_mem = bo->mem;
-   evict_mem.mm_node = NULL;
-   evict_mem.bus.offset = 0;
-   evict_mem.bus.addr = NULL;
-
 ret = ttm_bo_mem_space(bo, , _mem, ctx);
 if (ret) {
 if (ret != -ERESTARTSYS) {
@@ -867,12 +862,8 @@ static int ttm_bo_bounce_temp_buffer(struct 
ttm_buffer_object *bo,
  struct ttm_place *hop)
  {
 struct ttm_placement hop_placement;
+   struct ttm_resource hop_mem;
 int ret;
-   struct ttm_resource hop_mem = *mem;
-
-   hop_mem.mm_node = NULL;
-   hop_mem.mem_type = TTM_PL_SYSTEM;
-   hop_mem.placement = 0;

 hop_placement.num_placement = hop_placement.num_busy_placement = 1;
 hop_placement.placement = hop_placement.busy_placement = hop;
@@ -894,19 +885,14 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object 
*bo,
   struct ttm_placement *placement,
   struct ttm_operation_ctx *ctx)
  {
-   int ret = 0;
 struct ttm_place hop;
 struct ttm_resource mem;
+   int ret;

 dma_resv_assert_held(bo->base.resv);

 memset(, 0, sizeof(hop));

-   mem.num_pages = PAGE_ALIGN(bo->base.size) >> PAGE_SHIFT;
-   mem.bus.offset = 0;
-   mem.bus.addr = NULL;
-   mem.mm_node = NULL;
-
 /*
  * Determine where to move the buffer.
  *
@@ -1027,6 +1013,7 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
  struct dma_resv *resv,
  void (*destroy) (struct ttm_buffer_object *))
  {
+   static const struct ttm_place sys_mem = { .mem_type = TTM_PL_SYSTEM };
 bool locked;
 int ret = 0;

@@ -1038,13 +1025,8 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
 bo->bdev = bdev;
 bo->type = type;
 bo->page_alignment = page_alignment;
-   bo->mem.mem_type = TTM_PL_SYSTEM;
-   bo->mem.num_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
-   bo->mem.mm_node = NULL;
-   bo->mem.bus.offset = 0;
-   bo->mem.bus.addr = NULL;
+   ttm_resource_alloc(bo, _mem, >mem);
 bo->moving = NULL;
-   bo->mem.placement = 0;
 bo->pin_count = 0;
 bo->sg = sg;
 if (resv) {
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index efb7e9c34ab4..ae8b61460724 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -664,6 +664,7 @@ EXPORT_SYMBOL(ttm_bo_move_accel_cleanup);

  int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
  {
+   static const struct ttm_place sys_mem = { .mem_type = TTM_PL_SYSTEM };
 struct ttm_buffer_object *ghost;
 int ret;

@@ -676,8 +677,7 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
 if (ret)
 ttm_bo_wait(bo, false, false);

-   memset(>mem, 0, sizeof(bo->mem));
-   bo->mem.mem_type = TTM_PL_SYSTEM;
+   ttm_resource_alloc(bo, _mem, >mem);
 bo->ttm = NULL;

 dma_resv_unlock(>base._resv);
diff --git a/drivers/gpu/drm/ttm/ttm_resource.c 
b/drivers/gpu/drm/ttm/ttm_resource.c
index fc351700d035..cec2e6fb1c52 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -33,6 +33,15 @@ int ttm_resource_alloc(struct ttm_buffer_object *bo,
 ttm_manager_type(bo->bdev, res->mem_type);

Hmm, should this not be place->mem_type, when fishing out the man?

For example in the above pipeline_gutting case we previously nuked the

Re: [Intel-gfx] [PATCH 16/21] drm/i915/gem: Delay context creation

On 30/04/2021 13:30, Daniel Vetter wrote:

On Fri, Apr 30, 2021 at 1:58 PM Tvrtko Ursulin
wrote:

On 30/04/2021 07:53, Daniel Vetter wrote:

On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand wrote:

On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter wrote:

On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason Ekstrand wrote:

On Thu, Apr 29, 2021 at 1:56 PM Daniel Vetter wrote:

On Thu, Apr 29, 2021 at 01:16:04PM -0500, Jason Ekstrand wrote:

On Thu, Apr 29, 2021 at 10:51 AM Daniel Vetter wrote:

+ ret = set_proto_ctx_param(file_priv, pc, args);

I think we should have a FIXME here of not allowing this on some future
platforms because just use CTX_CREATE_EXT.

Done.

+ if (ret == -ENOTSUPP) {
+ /* Some params, specifically SSEU, can only be set on fully

I think this needs a FIXME: that this only holds during the conversion?
Otherwise we kinda have a bit a problem me thinks ...

I'm not sure what you mean by that.

This SSEU thing looks like a 3rd parameter, which is only valid on
finalized context. That feels all kinds of wrong. Will it stay? If yes
*ugh* and why?

Because I was being lazy. The SSEU stuff is a fairly complex param to
parse and it's always set live. I can factor out the SSEU parsing
code if you want and it shouldn't be too bad in the end.

Yeah I think the special case here is a bit too jarring.

You can look at it here:

https://gitlab.freedesktop.org/jekstrand/linux/-/commit/c805f424a3374b2de405b7fc651eab551df2cdaf#474deb1194892a272db022ff175872d42004dfda_283_588

Plus cursory review of userspace show
- mesa doesn't set this
- compute sets its right before running the batch
- media sets it as the last thing of context creation

Noticed a long sub-thread so looked inside..

SSEU is a really an interesting one.

For current userspace limiting to context creation is fine, since it is
only allowed for Icelake/VME use case. But if you notice the comment inside:

/* ABI restriction - VME use case only. */

It is a hint there was, or could be, more to this uapi than that.

Ah okay, I assumed it's more of the overall drive to eliminate
set_param. If sseu set_param stays then it's fine for what I had in mind.

Or do you mean this is defacto dead code? this = compute setting it
before every batch I mean here.

No idea, wasn't aware of the compute usage.

Anyway, I was only aware of the current media usage, which is static as
you say, and future/wishlist media usage, which would be dynamic, but a
complicated story to get right (partly due downsides mentioned in the
previous paragraph mean balancing benefit vs cost of dynamic sseu is not
easy).

Regards,

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

Re: [Intel-gfx] [PATCH 16/21] drm/i915/gem: Delay context creation

On Fri, Apr 30, 2021 at 1:58 PM Tvrtko Ursulin
 wrote:
>
>
> On 30/04/2021 07:53, Daniel Vetter wrote:
> > On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand  
> > wrote:
> >>
> >> On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter  wrote:
> >>>
> >>> On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason Ekstrand wrote:
>  On Thu, Apr 29, 2021 at 1:56 PM Daniel Vetter  wrote:
> > On Thu, Apr 29, 2021 at 01:16:04PM -0500, Jason Ekstrand wrote:
> >> On Thu, Apr 29, 2021 at 10:51 AM Daniel Vetter  wrote:
>  + ret = set_proto_ctx_param(file_priv, pc, args);
> >>>
> >>> I think we should have a FIXME here of not allowing this on some 
> >>> future
> >>> platforms because just use CTX_CREATE_EXT.
> >>
> >> Done.
> >>
>  + if (ret == -ENOTSUPP) {
>  + /* Some params, specifically SSEU, can only be set on 
>  fully
> >>>
> >>> I think this needs a FIXME: that this only holds during the 
> >>> conversion?
> >>> Otherwise we kinda have a bit a problem me thinks ...
> >>
> >> I'm not sure what you mean by that.
> >
> > Well I'm at least assuming that we wont have this case anymore, i.e.
> > there's only two kinds of parameters:
> > - those which are valid only on proto context
> > - those which are valid on both (like priority)
> >
> > This SSEU thing looks like a 3rd parameter, which is only valid on
> > finalized context. That feels all kinds of wrong. Will it stay? If yes
> > *ugh* and why?
> 
>  Because I was being lazy.  The SSEU stuff is a fairly complex param to
>  parse and it's always set live.  I can factor out the SSEU parsing
>  code if you want and it shouldn't be too bad in the end.
> >>>
> >>> Yeah I think the special case here is a bit too jarring.
> >>
> >> I rolled a v5 that allows you to set SSEU as a create param.  I'm not
> >> a huge fan of that much code duplication for the SSEU set but I guess
> >> that's what we get for deciding to "unify" our context creation
> >> parameter path with our on-the-fly parameter path
> >>
> >> You can look at it here:
> >>
> >> https://gitlab.freedesktop.org/jekstrand/linux/-/commit/c805f424a3374b2de405b7fc651eab551df2cdaf#474deb1194892a272db022ff175872d42004dfda_283_588
> >
> > Hm yeah the duplication of the render engine check is a bit annoying.
> > What's worse, if you tthrow another set_engines on top it's probably
> > all wrong then. The old thing solved that by just throwing that
> > intel_context away.
> >
> > You're also not keeping the engine id in the proto ctx for this, so
> > there's probably some gaps there. We'd need to clear the SSEU if
> > userspace puts another context there. But also no userspace does that.
> >
> > Plus cursory review of userspace show
> > - mesa doesn't set this
> > - compute sets its right before running the batch
> > - media sets it as the last thing of context creation
>
> Noticed a long sub-thread so looked inside..
>
> SSEU is a really an interesting one.
>
> For current userspace limiting to context creation is fine, since it is
> only allowed for Icelake/VME use case. But if you notice the comment inside:
>
> /* ABI restriction - VME use case only. */
>
> It is a hint there was, or could be, more to this uapi than that.
>
> And from memory I think limiting to creation time will nip the hopes
> media had to use this dynamically on other platforms in the bud. So not
> that good really. They had convincing numbers what gets significantly
> better if we allowed dynamic control to this, just that as always, open
> source userspace was not there so we never allowed it. However if you
> come up with a new world order where it can only be done at context
> creation, as said already, the possibility for that improvement (aka
> further improving the competitive advantage) is most likely dashed.

Hm are you sure that this is create-time only? media-driver uses it
like that, but from my checking compute-runtime updates SSEU mode
before every execbuf call. So it very much looked like we have to keep
this dynamic.

Or do you mean this is defacto dead code? this = compute setting it
before every batch I mean here.
-Daniel




--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5 4/6] drm/sprd: add Unisoc's drm display controller driver

2021-04-30 Thread Kevin Tang

Cc  Robin & Joerg

Maxime Ripard  于2021年4月30日周五 下午5:22写道：

>
> On Sun, Apr 25, 2021 at 08:36:05PM +0800, Kevin Tang wrote:
> > Adds DPU(Display Processor Unit) support for the Unisoc's display
> > subsystem.
> > It's support multi planes, scaler, rotation, PQ(Picture Quality) and more.
> >
> > v2:
> >   - Use drm_xxx to replace all DRM_XXX.
> >   - Use kzalloc to replace devm_kzalloc for sprd_dpu structure init.
> >
> > v3:
> >   - Remove dpu_layer stuff layer and commit layers by aotmic_update
> >
> > v4:
> >   - Use drmm_helpers to allocate crtc and planes.
> >   - Move rotation enum definitions to crtc layer reg bitfields.
> >   - Move allocate crtc and planes to bind function.
> >
> > v5:
> >   - Fix the checkpatch warnings.
> >   - Use mode_set_nofb instead of mode_valid callback.
> >   - Follow the OF-Graph bindings, use of_graph_get_port_by_id
> > instead of of_parse_phandle.
> >   - Use zpos to represent the layer position.
> >   - Rebase to last drm misc branch.
> >
> > Cc: Orson Zhai 
> > Cc: Chunyan Zhang 
> > Signed-off-by: Kevin Tang 
> > ---
> >  drivers/gpu/drm/sprd/Kconfig|   1 +
> >  drivers/gpu/drm/sprd/Makefile   |   3 +-
> >  drivers/gpu/drm/sprd/sprd_dpu.c | 939 
> >  drivers/gpu/drm/sprd/sprd_dpu.h | 109 
> >  drivers/gpu/drm/sprd/sprd_drm.c |   1 +
> >  drivers/gpu/drm/sprd/sprd_drm.h |   2 +
> >  6 files changed, 1054 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.c
> >  create mode 100644 drivers/gpu/drm/sprd/sprd_dpu.h
> >
> > diff --git a/drivers/gpu/drm/sprd/Kconfig b/drivers/gpu/drm/sprd/Kconfig
> > index 726c3e76d..37762c333 100644
> > --- a/drivers/gpu/drm/sprd/Kconfig
> > +++ b/drivers/gpu/drm/sprd/Kconfig
> > @@ -5,6 +5,7 @@ config DRM_SPRD
> >   select DRM_GEM_CMA_HELPER
> >   select DRM_KMS_CMA_HELPER
> >   select DRM_KMS_HELPER
> > + select VIDEOMODE_HELPERS
> >   help
> > Choose this option if you have a Unisoc chipset.
> > If M is selected the module will be called sprd_drm.
> > diff --git a/drivers/gpu/drm/sprd/Makefile b/drivers/gpu/drm/sprd/Makefile
> > index 9850f00b8..ab12b95e6 100644
> > --- a/drivers/gpu/drm/sprd/Makefile
> > +++ b/drivers/gpu/drm/sprd/Makefile
> > @@ -1,3 +1,4 @@
> >  # SPDX-License-Identifier: GPL-2.0
> >
> > -obj-y := sprd_drm.o
> > +obj-y := sprd_drm.o \
> > + sprd_dpu.o
> > diff --git a/drivers/gpu/drm/sprd/sprd_dpu.c 
> > b/drivers/gpu/drm/sprd/sprd_dpu.c
> > new file mode 100644
> > index 0..e74c3dbb3
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sprd/sprd_dpu.c
> > @@ -0,0 +1,939 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2020 Unisoc Inc.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "sprd_drm.h"
> > +#include "sprd_dpu.h"
> > +
> > +/* Global control registers */
> > +#define REG_DPU_CTRL 0x04
> > +#define REG_DPU_CFG0 0x08
> > +#define REG_PANEL_SIZE   0x20
> > +#define REG_BLEND_SIZE   0x24
> > +#define REG_BG_COLOR 0x2C
> > +
> > +/* Layer0 control registers */
> > +#define REG_LAY_BASE_ADDR0   0x30
> > +#define REG_LAY_BASE_ADDR1   0x34
> > +#define REG_LAY_BASE_ADDR2   0x38
> > +#define REG_LAY_CTRL 0x40
> > +#define REG_LAY_SIZE 0x44
> > +#define REG_LAY_PITCH0x48
> > +#define REG_LAY_POS  0x4C
> > +#define REG_LAY_ALPHA0x50
> > +#define REG_LAY_CROP_START   0x5C
> > +
> > +/* Interrupt control registers */
> > +#define REG_DPU_INT_EN   0x1E0
> > +#define REG_DPU_INT_CLR  0x1E4
> > +#define REG_DPU_INT_STS  0x1E8
> > +
> > +/* DPI control registers */
> > +#define REG_DPI_CTRL 0x1F0
> > +#define REG_DPI_H_TIMING 0x1F4
> > +#define REG_DPI_V_TIMING 0x1F8
> > +
> > +/* MMU control registers */
> > +#define REG_MMU_EN   0x800
> > +#define REG_MMU_VPN_RANGE0x80C
> > +#define REG_MMU_VAOR_ADDR_RD 0x818
> > +#define REG_MMU_VAOR_ADDR_WR 0x81C
> > +#define REG_MMU_INV_ADDR_RD  0x820
> > +#define REG_MMU_INV_ADDR_WR  0x824
> > +#define REG_MMU_PPN1 0x83C
> > +#define REG_MMU_RANGE1   0x840
> > +#define REG_MMU_PPN2 0x844
> > +#define REG_MMU_RANGE2   0x848
> > +
> > +/* Global control bits */
> > +#define BIT_DPU_RUN  BIT(0)
> > +#define BIT_DPU_STOP BIT(1)
> > +#define BIT_DPU_REG_UPDATE   BIT(2)
> > +#define BIT_DPU_IF_EDPI  BIT(0)
> > +
> > +/* Layer control bits */
> > +#define BIT_DPU_LAY_EN   BIT(0)
> > +#define BIT_DPU_LAY_LAYER_ALPHA  (0x01 << 2)
> > +#define

Re: [PATCH 02/13] drm/ttm: always initialize the full ttm_resource

On Fri, 30 Apr 2021 at 10:25, Christian König
 wrote:
>
> Init all fields in ttm_resource_alloc() when we create a new resource.
>
> Signed-off-by: Christian König 
> Reviewed-by: Matthew Auld 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c |  2 --
>  drivers/gpu/drm/ttm/ttm_bo.c| 26 -
>  drivers/gpu/drm/ttm/ttm_bo_util.c   |  4 ++--
>  drivers/gpu/drm/ttm/ttm_resource.c  |  9 +
>  4 files changed, 15 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index 7ba761e833ba..2f7580d2ee71 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -1015,8 +1015,6 @@ int amdgpu_ttm_alloc_gart(struct ttm_buffer_object *bo)
> } else {
>
> /* allocate GART space */
> -   tmp = bo->mem;
> -   tmp.mm_node = NULL;
> placement.num_placement = 1;
> placement.placement = 
> placement.num_busy_placement = 1;
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index df63a07a70de..55f1ddcf22b6 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -507,11 +507,6 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
> return ttm_tt_create(bo, false);
> }
>
> -   evict_mem = bo->mem;
> -   evict_mem.mm_node = NULL;
> -   evict_mem.bus.offset = 0;
> -   evict_mem.bus.addr = NULL;
> -
> ret = ttm_bo_mem_space(bo, , _mem, ctx);
> if (ret) {
> if (ret != -ERESTARTSYS) {
> @@ -867,12 +862,8 @@ static int ttm_bo_bounce_temp_buffer(struct 
> ttm_buffer_object *bo,
>  struct ttm_place *hop)
>  {
> struct ttm_placement hop_placement;
> +   struct ttm_resource hop_mem;
> int ret;
> -   struct ttm_resource hop_mem = *mem;
> -
> -   hop_mem.mm_node = NULL;
> -   hop_mem.mem_type = TTM_PL_SYSTEM;
> -   hop_mem.placement = 0;
>
> hop_placement.num_placement = hop_placement.num_busy_placement = 1;
> hop_placement.placement = hop_placement.busy_placement = hop;
> @@ -894,19 +885,14 @@ static int ttm_bo_move_buffer(struct ttm_buffer_object 
> *bo,
>   struct ttm_placement *placement,
>   struct ttm_operation_ctx *ctx)
>  {
> -   int ret = 0;
> struct ttm_place hop;
> struct ttm_resource mem;
> +   int ret;
>
> dma_resv_assert_held(bo->base.resv);
>
> memset(, 0, sizeof(hop));
>
> -   mem.num_pages = PAGE_ALIGN(bo->base.size) >> PAGE_SHIFT;
> -   mem.bus.offset = 0;
> -   mem.bus.addr = NULL;
> -   mem.mm_node = NULL;
> -
> /*
>  * Determine where to move the buffer.
>  *
> @@ -1027,6 +1013,7 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
>  struct dma_resv *resv,
>  void (*destroy) (struct ttm_buffer_object *))
>  {
> +   static const struct ttm_place sys_mem = { .mem_type = TTM_PL_SYSTEM };
> bool locked;
> int ret = 0;
>
> @@ -1038,13 +1025,8 @@ int ttm_bo_init_reserved(struct ttm_device *bdev,
> bo->bdev = bdev;
> bo->type = type;
> bo->page_alignment = page_alignment;
> -   bo->mem.mem_type = TTM_PL_SYSTEM;
> -   bo->mem.num_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
> -   bo->mem.mm_node = NULL;
> -   bo->mem.bus.offset = 0;
> -   bo->mem.bus.addr = NULL;
> +   ttm_resource_alloc(bo, _mem, >mem);
> bo->moving = NULL;
> -   bo->mem.placement = 0;
> bo->pin_count = 0;
> bo->sg = sg;
> if (resv) {
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c 
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index efb7e9c34ab4..ae8b61460724 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -664,6 +664,7 @@ EXPORT_SYMBOL(ttm_bo_move_accel_cleanup);
>
>  int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
>  {
> +   static const struct ttm_place sys_mem = { .mem_type = TTM_PL_SYSTEM };
> struct ttm_buffer_object *ghost;
> int ret;
>
> @@ -676,8 +677,7 @@ int ttm_bo_pipeline_gutting(struct ttm_buffer_object *bo)
> if (ret)
> ttm_bo_wait(bo, false, false);
>
> -   memset(>mem, 0, sizeof(bo->mem));
> -   bo->mem.mem_type = TTM_PL_SYSTEM;
> +   ttm_resource_alloc(bo, _mem, >mem);
> bo->ttm = NULL;
>
> dma_resv_unlock(>base._resv);
> diff --git a/drivers/gpu/drm/ttm/ttm_resource.c 
> b/drivers/gpu/drm/ttm/ttm_resource.c
> index fc351700d035..cec2e6fb1c52 100644
> --- a/drivers/gpu/drm/ttm/ttm_resource.c
> +++ b/drivers/gpu/drm/ttm/ttm_resource.c
> @@ -33,6 +33,15 @@ int ttm_resource_alloc(struct ttm_buffer_object *bo,
> ttm_manager_type(bo->bdev,

Re: [Intel-gfx] [PATCH 16/21] drm/i915/gem: Delay context creation

On 30/04/2021 07:53, Daniel Vetter wrote:

On Thu, Apr 29, 2021 at 11:35 PM Jason Ekstrand wrote:

On Thu, Apr 29, 2021 at 2:07 PM Daniel Vetter wrote:

On Thu, Apr 29, 2021 at 02:01:16PM -0500, Jason Ekstrand wrote:

On Thu, Apr 29, 2021 at 1:56 PM Daniel Vetter wrote:

On Thu, Apr 29, 2021 at 01:16:04PM -0500, Jason Ekstrand wrote:

On Thu, Apr 29, 2021 at 10:51 AM Daniel Vetter wrote:

+ ret = set_proto_ctx_param(file_priv, pc, args);

I think we should have a FIXME here of not allowing this on some future
platforms because just use CTX_CREATE_EXT.

Done.

+ if (ret == -ENOTSUPP) {
+ /* Some params, specifically SSEU, can only be set on fully

I think this needs a FIXME: that this only holds during the conversion?
Otherwise we kinda have a bit a problem me thinks ...

I'm not sure what you mean by that.

This SSEU thing looks like a 3rd parameter, which is only valid on
finalized context. That feels all kinds of wrong. Will it stay? If yes
*ugh* and why?

Because I was being lazy. The SSEU stuff is a fairly complex param to
parse and it's always set live. I can factor out the SSEU parsing
code if you want and it shouldn't be too bad in the end.

Yeah I think the special case here is a bit too jarring.

You can look at it here:

https://gitlab.freedesktop.org/jekstrand/linux/-/commit/c805f424a3374b2de405b7fc651eab551df2cdaf#474deb1194892a272db022ff175872d42004dfda_283_588

Plus cursory review of userspace show
- mesa doesn't set this
- compute sets its right before running the batch
- media sets it as the last thing of context creation

Noticed a long sub-thread so looked inside..

SSEU is a really an interesting one.

For current userspace limiting to context creation is fine, since it is
only allowed for Icelake/VME use case. But if you notice the comment inside:

/* ABI restriction - VME use case only. */

It is a hint there was, or could be, more to this uapi than that.

Regards,

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

Re: [PATCH 1/2] drm/i915/overlay: Fix active retire callback alignment

On Thu, Apr 29, 2021 at 06:34:51PM +0100, Tvrtko Ursulin wrote:
> 
> On 29/04/2021 17:31, Ville Syrjälä wrote:
> > On Thu, Apr 29, 2021 at 09:35:29AM +0100, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin 
> > > 
> > > __i915_active_call annotation is required on the retire callback to ensure
> > > correct function alignment.
> > > 
> > > Signed-off-by: Tvrtko Ursulin 
> > > Fixes: a21ce8ad12d2 ("drm/i915/overlay: Switch to using i915_active 
> > > tracking")
> > > Cc: Chris Wilson 
> > > Cc: Matthew Auld 
> > > ---
> > >   drivers/gpu/drm/i915/display/intel_overlay.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c 
> > > b/drivers/gpu/drm/i915/display/intel_overlay.c
> > > index fffbde4256db..428819ba18dd 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_overlay.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_overlay.c
> > > @@ -383,7 +383,7 @@ static void intel_overlay_off_tail(struct 
> > > intel_overlay *overlay)
> > >   i830_overlay_clock_gating(dev_priv, true);
> > >   }
> > > -static void
> > > +__i915_active_call static void
> > 
> > Am I blind or are we just packing flag bits into a pointer, passing
> > that to a function, and then immediately unpack the bits again in
> > said function? Why not just pass the flags explicitly?
> > 
> > Looks like you missed auto_retire()?
> 
> Yeah, both points already either fixed or under consideration:
> https://patchwork.freedesktop.org/patch/431473/?series=89623=1
> 
> I left the splitting up vfunc vs flags for later.

Yeah pls remove this pointer packing asap.

This is yet another case of pointless complications and fragility in the
code base for not reason at all, and it needs to go.

I'll file a jira and assign to Matt Auld, since he reviewed this
originally. I'll ping you in case you want to take it over.

Thanks, Daniel

> 
> Regards,
> 
> Tvrtko
> 
> > >   intel_overlay_last_flip_retire(struct i915_active *active)
> > >   {
> > >   struct intel_overlay *overlay =
> > > -- 
> > > 2.30.2
> > > 
> > > ___
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 1/3] drm/bridge: nwl-dsi: Force a full modeset when crtc_state->active is changed to be true

2021-04-30 Thread Robert Foss

Even better :)

On Fri, Apr 30, 2021, 13:46 Liu Ying  wrote:

> Hi Robert,
>
> On Fri, 2021-04-30 at 11:56 +0200, Robert Foss wrote:
> > Hey Liu,
> >
> > This patch does not apply on upstream-drm-misc/drm-misc-next. When it
> > passes local testing & building, I'm ready to merge it.
>
> I see Neil has already pushed this entire patch series to
> drm-misc-next.
>
>
>
> https://cgit.freedesktop.org/drm/drm-misc/commit/?id=885811372fe101c4299c53eecc9fee72cf927a0c
>
> I also see Guido's R-b and T-b tags on this series, though they comes
> after Neil's push perhaps.
>
> Thanks,
> Liu Ying
>
> >
> > On Fri, 23 Apr 2021 at 11:42, Liu Ying  wrote:
> > > This patch replaces ->mode_fixup() with ->atomic_check() so that
> > > a full modeset can be requested from there when crtc_state->active
> > > is changed to be true(which implies only connector's DPMS is
> > > brought
> > > out of "Off" status, though not necessarily).  Bridge functions are
> > > added or changed to accommodate the ->atomic_check() callback.
> > > That
> > > full modeset is needed by the up-coming patch which gets MIPI DSI
> > > controller and PHY ready in ->mode_set(), because it makes sure
> > > ->mode_set() and ->atomic_disable() are called in pairs.
> > >
> > > Cc: Andrzej Hajda 
> > > Cc: Neil Armstrong 
> > > Cc: Robert Foss 
> > > Cc: Laurent Pinchart 
> > > Cc: Jonas Karlman 
> > > Cc: Jernej Skrabec 
> > > Cc: David Airlie 
> > > Cc: Daniel Vetter 
> > > Cc: Guido Günther 
> > > Cc: Robert Chiras 
> > > Cc: NXP Linux Team 
> > > Signed-off-by: Liu Ying 
> > > ---
> > > v2->v3:
> > > * Split from the single patch in v2 to clarify changes. (Neil)
> > >
> > >  drivers/gpu/drm/bridge/nwl-dsi.c | 61 --
> > > --
> > >  1 file changed, 39 insertions(+), 22 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c
> > > b/drivers/gpu/drm/bridge/nwl-dsi.c
> > > index 66b67402f1acd..c65ca860712d2 100644
> > > --- a/drivers/gpu/drm/bridge/nwl-dsi.c
> > > +++ b/drivers/gpu/drm/bridge/nwl-dsi.c
> > > @@ -21,6 +21,7 @@
> > >  #include 
> > >  #include 
> > >
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -742,7 +743,9 @@ static int nwl_dsi_disable(struct nwl_dsi *dsi)
> > > return 0;
> > >  }
> > >
> > > -static void nwl_dsi_bridge_disable(struct drm_bridge *bridge)
> > > +static void
> > > +nwl_dsi_bridge_atomic_disable(struct drm_bridge *bridge,
> > > + struct drm_bridge_state
> > > *old_bridge_state)
> > >  {
> > > struct nwl_dsi *dsi = bridge_to_dsi(bridge);
> > > int ret;
> > > @@ -803,17 +806,6 @@ static int nwl_dsi_get_dphy_params(struct
> > > nwl_dsi *dsi,
> > > return 0;
> > >  }
> > >
> > > -static bool nwl_dsi_bridge_mode_fixup(struct drm_bridge *bridge,
> > > - const struct drm_display_mode
> > > *mode,
> > > - struct drm_display_mode
> > > *adjusted_mode)
> > > -{
> > > -   /* At least LCDIF + NWL needs active high sync */
> > > -   adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC |
> > > DRM_MODE_FLAG_PVSYNC);
> > > -   adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC |
> > > DRM_MODE_FLAG_NVSYNC);
> > > -
> > > -   return true;
> > > -}
> > > -
> > >  static enum drm_mode_status
> > >  nwl_dsi_bridge_mode_valid(struct drm_bridge *bridge,
> > >   const struct drm_display_info *info,
> > > @@ -831,6 +823,24 @@ nwl_dsi_bridge_mode_valid(struct drm_bridge
> > > *bridge,
> > > return MODE_OK;
> > >  }
> > >
> > > +static int nwl_dsi_bridge_atomic_check(struct drm_bridge *bridge,
> > > +  struct drm_bridge_state
> > > *bridge_state,
> > > +  struct drm_crtc_state
> > > *crtc_state,
> > > +  struct drm_connector_state
> > > *conn_state)
> > > +{
> > > +   struct drm_display_mode *adjusted_mode = _state-
> > > >adjusted_mode;
> > > +
> > > +   /* At least LCDIF + NWL needs active high sync */
> > > +   adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC |
> > > DRM_MODE_FLAG_PVSYNC);
> > > +   adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC |
> > > DRM_MODE_FLAG_NVSYNC);
> > > +
> > > +   /* Do a full modeset if crtc_state->active is changed to be
> > > true. */
> > > +   if (crtc_state->active_changed && crtc_state->active)
> > > +   crtc_state->mode_changed = true;
> > > +
> > > +   return 0;
> > > +}
> > > +
> > >  static void
> > >  nwl_dsi_bridge_mode_set(struct drm_bridge *bridge,
> > > const struct drm_display_mode *mode,
> > > @@ -862,7 +872,9 @@ nwl_dsi_bridge_mode_set(struct drm_bridge
> > > *bridge,
> > > drm_mode_debug_printmodeline(adjusted_mode);
> > >  }
> > >
> > > -static void nwl_dsi_bridge_pre_enable(struct drm_bridge *bridge)
> > > +static void
> > > +nwl_dsi_bridge_atomic_pre_enable(struct drm_bridge *bridge,
> >

Re: [Intel-gfx] [PATCH] drm/i915: Be more gentle with exiting non-persistent context