date:20230328

Simplify two functions msm_parse_deps() and msm_parse_post_deps():
extract single item parsing function and clean up error path.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/msm_gem_submit.c | 186 +++
 1 file changed, 101 insertions(+), 85 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
b/drivers/gpu/drm/msm/msm_gem_submit.c
index f2a6775a10eb..da5fcd65f8b6 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -546,6 +546,41 @@ struct msm_submit_post_dep {
struct dma_fence_chain *chain;
 };
 
+static struct drm_syncobj *msm_parse_dep_one(struct msm_gem_submit *submit,
+struct drm_file *file,
+uint64_t address,
+size_t syncobj_stride)
+{
+   struct drm_msm_gem_submit_syncobj syncobj_desc = {0};
+   struct drm_syncobj *syncobj = NULL;
+   int ret;
+
+   if (copy_from_user(&syncobj_desc,
+  u64_to_user_ptr(address),
+  min(syncobj_stride, sizeof(syncobj_desc
+   return ERR_PTR(-EFAULT);
+
+   if (syncobj_desc.point &&
+   !drm_core_check_feature(submit->dev, DRIVER_SYNCOBJ_TIMELINE))
+   return ERR_PTR(-EOPNOTSUPP);
+
+   if (syncobj_desc.flags & ~MSM_SUBMIT_SYNCOBJ_FLAGS)
+   return ERR_PTR(-EINVAL);
+
+   ret = drm_sched_job_add_syncobj_dependency(&submit->base, file,
+  syncobj_desc.handle, 
syncobj_desc.point);
+   if (ret)
+   return ERR_PTR(ret);
+
+   if (syncobj_desc.flags & MSM_SUBMIT_SYNCOBJ_RESET) {
+   syncobj = drm_syncobj_find(file, syncobj_desc.handle);
+   if (!syncobj)
+   return ERR_PTR(-EINVAL);
+   }
+
+   return syncobj;
+}
+
 static struct drm_syncobj **msm_parse_deps(struct msm_gem_submit *submit,
struct drm_file *file,
uint64_t in_syncobjs_addr,
@@ -553,9 +588,8 @@ static struct drm_syncobj **msm_parse_deps(struct 
msm_gem_submit *submit,
size_t syncobj_stride)
 {
struct drm_syncobj **syncobjs = NULL;
-   struct drm_msm_gem_submit_syncobj syncobj_desc = {0};
-   int ret = 0;
-   uint32_t i, j;
+   int ret;
+   int i;
 
syncobjs = kcalloc(nr_in_syncobjs, sizeof(*syncobjs),
   GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY);
@@ -564,49 +598,26 @@ static struct drm_syncobj **msm_parse_deps(struct 
msm_gem_submit *submit,
 
for (i = 0; i < nr_in_syncobjs; ++i) {
uint64_t address = in_syncobjs_addr + i * syncobj_stride;
+   struct drm_syncobj *syncobj;
 
-   if (copy_from_user(&syncobj_desc,
-  u64_to_user_ptr(address),
-  min(syncobj_stride, sizeof(syncobj_desc {
-   ret = -EFAULT;
-   break;
-   }
-
-   if (syncobj_desc.point &&
-   !drm_core_check_feature(submit->dev, 
DRIVER_SYNCOBJ_TIMELINE)) {
-   ret = -EOPNOTSUPP;
-   break;
-   }
-
-   if (syncobj_desc.flags & ~MSM_SUBMIT_SYNCOBJ_FLAGS) {
-   ret = -EINVAL;
-   break;
+   syncobj = msm_parse_dep_one(submit, file, address, 
syncobj_stride);
+   if (IS_ERR(syncobj)) {
+   ret = PTR_ERR(syncobj);
+   goto err;
}
 
-   ret = drm_sched_job_add_syncobj_dependency(&submit->base, file,
-  syncobj_desc.handle, 
syncobj_desc.point);
-   if (ret)
-   break;
-
-   if (syncobj_desc.flags & MSM_SUBMIT_SYNCOBJ_RESET) {
-   syncobjs[i] =
-   drm_syncobj_find(file, syncobj_desc.handle);
-   if (!syncobjs[i]) {
-   ret = -EINVAL;
-   break;
-   }
-   }
+   syncobjs[i] = syncobj;
}
 
-   if (ret) {
-   for (j = 0; j <= i; ++j) {
-   if (syncobjs[j])
-   drm_syncobj_put(syncobjs[j]);
-   }
-   kfree(syncobjs);
-   return ERR_PTR(ret);
-   }
return syncobjs;
+
+err:
+   while (--i >= 0)
+   if (syncobjs[i])
+   drm_syncobj_put(syncobjs[i]);
+   kfree(syncobjs);
+
+   return ERR_PTR(ret);
 }
 
 static void msm_reset_syncobjs(struct drm_syncobj **syncobjs,
@@ -620,6 +631,43 @@ static void ms

[PATCH v3 1/2] drm/msm: drop unused ring variable in msm_ioctl_gem_submit()

The variable ring is not used by msm_parse_deps() and
msm_ioctl_gem_submit() and thus can be dropped.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/msm_gem_submit.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 514ff5245c8a..f2a6775a10eb 100644
--- a/drivers/gpu/drm/msm/msm_gem_submit.c
+++ b/drivers/gpu/drm/msm/msm_gem_submit.c
@@ -550,8 +550,7 @@ static struct drm_syncobj **msm_parse_deps(struct 
msm_gem_submit *submit,
struct drm_file *file,
uint64_t in_syncobjs_addr,
uint32_t nr_in_syncobjs,
-   size_t syncobj_stride,
-   struct msm_ringbuffer *ring)
+   size_t syncobj_stride)
 {
struct drm_syncobj **syncobjs = NULL;
struct drm_msm_gem_submit_syncobj syncobj_desc = {0};
@@ -798,7 +797,7 @@ int msm_ioctl_gem_submit(struct drm_device *dev, void *data,
syncobjs_to_reset = msm_parse_deps(submit, file,
   args->in_syncobjs,
   args->nr_in_syncobjs,
-  args->syncobj_stride, ring);
+  args->syncobj_stride);
if (IS_ERR(syncobjs_to_reset)) {
ret = PTR_ERR(syncobjs_to_reset);
goto out_unlock;
-- 
2.39.2

[PATCH v3 0/2] drm/msm: rework msm_parse_deps() and msm_parse_post_deps()

As discusssed in the the review of [1], rework these two functions to
separate single point parser and provide clean error path.

Depenencies: [1], [2]

[1] https://lore.kernel.org/all/20230215235048.1166484-1-robdcl...@gmail.com
[2] https://patchwork.freedesktop.org/patch/524090/?series=114362&rev=1

Changes since v2:
- Rebased on top of [2], which is a nice cleanup

Changes since v1:
- Restored dumping of ring->id in trace_msm_gpu_submit (requested by Rob
  Clark)

Dmitry Baryshkov (2):
  drm/msm: drop unused ring variable in msm_ioctl_gem_submit()
  drm/msm: simplify msm_parse_deps() and msm_parse_post_deps()

 drivers/gpu/drm/msm/msm_gem_submit.c | 191 +++
 1 file changed, 103 insertions(+), 88 deletions(-)

-- 
2.39.2

Re: [PATCH 1/1] drm/i915: fix race condition UAF in i915_perf_add_config_ioctl

2023-03-28 Thread Umesh Nerlige Ramappa


On Tue, Mar 28, 2023 at 02:08:47PM +0100, Tvrtko Ursulin wrote:


On 28/03/2023 10:36, Min Li wrote:

Userspace can guess the id value and try to race oa_config object creation
with config remove, resulting in a use-after-free if we dereference the
object after unlocking the metrics_lock.  For that reason, unlocking the
metrics_lock must be done after we are done dereferencing the object.

Signed-off-by: Min Li 


Fixes: f89823c21224 ("drm/i915/perf: Implement I915_PERF_ADD/REMOVE_CONFIG 
interface")
Cc: Lionel Landwerlin 
Cc: Umesh Nerlige Ramappa 
Cc:  # v4.14+


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

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 824a34ec0b83..93748ca2c5da 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -4634,13 +4634,13 @@ int i915_perf_add_config_ioctl(struct drm_device *dev, 
void *data,
err = oa_config->id;
goto sysfs_err;
}
-
-   mutex_unlock(&perf->metrics_lock);
+   id = oa_config->id;
drm_dbg(&perf->i915->drm,
"Added config %s id=%i\n", oa_config->uuid, oa_config->id);
+   mutex_unlock(&perf->metrics_lock);
-   return oa_config->id;
+   return id;
 sysfs_err:
mutex_unlock(&perf->metrics_lock);


LGTM.

Reviewed-by: Tvrtko Ursulin 

Umesh or Lionel could you please double check? I can merge if confirmed okay.


LGTM,

Reviewed-by: Umesh Nerlige Ramappa 

Thanks,
Umesh



Regards,

Tvrtko

[PATCH v3 08/10] drm/display/dsc: add YCbCr 4:2:2 and 4:2:0 RC parameters

Include RC parameters for YCbCr 4:2:2 and 4:2:0 configurations.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_dsc_helper.c | 438 +++
 include/drm/display/drm_dsc_helper.h |   2 +
 2 files changed, 440 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index aec6f8c201af..65e810a54257 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -740,6 +740,438 @@ static const struct rc_parameters_data 
rc_parameters_1_2_444[] = {
{ /* sentinel */ }
 };
 
+static const struct rc_parameters_data rc_parameters_1_2_422[] = {
+   {
+   .bpp = DSC_BPP(6), .bpc = 8,
+   { 512, 15, 6144, 3, 12, 11, 11, {
+   { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
+   { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+   { 3, 9, -8 }, { 3, 10, -10 }, { 5, 10, -10 }, { 5, 11, 
-12 },
+   { 5, 11, -12 }, { 9, 12, -12 }, { 12, 13, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 10,
+   { 512, 15, 6144, 7, 16, 15, 15, {
+   { 0, 8, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
+   { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, 
-8 },
+   { 7, 13, -8 }, { 7, 14, -10 }, { 9, 14, -10 }, { 9, 15, 
-12 },
+   { 9, 15, -12 }, { 13, 16, -12 }, { 16, 17, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 12,
+   { 512, 15, 6144, 11, 20, 19, 19, {
+   { 0, 12, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 9, 14, -2 },
+   { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11, 
16, -8 },
+   { 11, 17, -8 }, { 11, 18, -10 }, { 13, 18, -10 },
+   { 13, 19, -12 }, { 13, 19, -12 }, { 17, 20, -12 },
+   { 20, 21, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 14,
+   { 512, 15, 6144, 15, 24, 23, 23, {
+   { 0, 12, 2 }, { 5, 13, 0 }, { 11, 15, 0 }, { 12, 17, -2 
},
+   { 15, 19, -4 }, { 15, 19, -6 }, { 15, 19, -8 }, { 15, 
20, -8 },
+   { 15, 21, -8 }, { 15, 22, -10 }, { 17, 22, -10 },
+   { 17, 23, -12 }, { 17, 23, -12 }, { 21, 24, -12 },
+   { 24, 25, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 16,
+   { 512, 15, 6144, 19, 28, 27, 27, {
+   { 0, 12, 2 }, { 6, 14, 0 }, { 13, 17, 0 }, { 15, 20, -2 
},
+   { 19, 23, -4 }, { 19, 23, -6 }, { 19, 23, -8 }, { 19, 
24, -8 },
+   { 19, 25, -8 }, { 19, 26, -10 }, { 21, 26, -10 },
+   { 21, 27, -12 }, { 21, 27, -12 }, { 25, 28, -12 },
+   { 28, 29, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(7), .bpc = 8,
+   { 410, 15, 5632, 3, 12, 11, 11, {
+   { 0, 3, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 2, 6, -2 },
+   { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+   { 3, 9, -8 }, { 3, 9, -10 }, { 5, 10, -10 }, { 5, 10, 
-10 },
+   { 5, 11, -12 }, { 7, 11, -12 }, { 11, 12, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(7), .bpc = 10,
+   { 410, 15, 5632, 7, 16, 15, 15, {
+   { 0, 7, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 6, 10, -2 },
+   { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, 
-8 },
+   { 7, 13, -8 }, { 7, 13, -10 }, { 9, 14, -10 }, { 9, 14, 
-10 },
+   { 9, 15, -12 }, { 11, 15, -12 }, { 15, 16, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(7), .bpc = 12,
+   { 410, 15, 5632, 11, 20, 19, 19, {
+   { 0, 11, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 10, 14, -2 
},
+   { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11, 
16, -8 },
+   { 11, 17, -8 }, { 11, 17, -10 }, { 13, 18, -10 },
+   { 13, 18, -10 }, { 13, 19, -12 }, { 15, 19, -12 },
+   { 19, 20, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(7), .bpc = 14,
+   { 410, 15, 5632, 15, 24, 23, 23, {
+   { 0, 11, 2 }, { 5, 13, 0 }, { 11, 15, 0 }, { 13, 18, -2 
},
+   { 15, 19, -4 }, { 15, 19, -6 }, { 15, 19, -8 }, { 15, 
20, -8 },
+

[PATCH v3 06/10] drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR) parameters

The array of rc_parameters contains a mixture of parameters from DSC 1.1
and DSC 1.2 standards. Split these tow configuration arrays in
preparation to adding more configuration data.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_dsc_helper.c  | 127 ++
 drivers/gpu/drm/i915/display/intel_vdsc.c |  10 +-
 include/drm/display/drm_dsc_helper.h  |   7 +-
 3 files changed, 119 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index acb93d4116e0..35b39f3109c4 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -324,11 +324,81 @@ struct rc_parameters_data {
 
 #define DSC_BPP(bpp)   ((bpp) << 4)
 
+static const struct rc_parameters_data rc_parameters_pre_scr[] = {
+   {
+   .bpp = DSC_BPP(8), .bpc = 8,
+   { 512, 12, 6144, 3, 12, 11, 11, {
+   { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
+   { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+   { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12, 
-12 },
+   { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(8), .bpc = 10,
+   { 512, 12, 6144, 7, 16, 15, 15, {
+   /*
+* DSC model/pre-SCR-cfg has 8 for range_max_qp[0], 
however
+* VESA DSC 1.1 Table E-5 sets it to 4.
+*/
+   { 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
+   { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, 
-8 },
+   { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, 
-12 },
+   { 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(8), .bpc = 12,
+   { 512, 12, 6144, 11, 20, 19, 19, {
+   { 0, 12, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 9, 14, -2 },
+   { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11, 
16, -8 },
+   { 11, 17, -8 }, { 11, 18, -10 }, { 13, 19, -10 },
+   { 13, 20, -12 }, { 13, 21, -12 }, { 15, 21, -12 },
+   { 21, 23, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(12), .bpc = 8,
+   { 341, 15, 2048, 3, 12, 11, 11, {
+   { 0, 2, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
+   { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+   { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 },
+   { 5, 12, -12 }, { 5, 13, -12 }, { 7, 13, -12 }, { 13, 
15, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(12), .bpc = 10,
+   { 341, 15, 2048, 7, 16, 15, 15, {
+   { 0, 2, 2 }, { 2, 5, 0 }, { 3, 7, 0 }, { 4, 8, -2 },
+   { 6, 9, -4 }, { 7, 10, -6 }, { 7, 11, -8 }, { 7, 12, -8 
},
+   { 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, 
-12 },
+   { 9, 17, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(12), .bpc = 12,
+   { 341, 15, 2048, 11, 20, 19, 19, {
+   { 0, 6, 2 }, { 4, 9, 0 }, { 7, 11, 0 }, { 8, 12, -2 },
+   { 10, 13, -4 }, { 11, 14, -6 }, { 11, 15, -8 }, { 11, 
16, -8 },
+   { 11, 17, -8 }, { 11, 18, -10 }, { 13, 19, -10 },
+   { 13, 20, -12 }, { 13, 21, -12 }, { 15, 21, -12 },
+   { 21, 23, -12 }
+   }
+   }
+   },
+   { /* sentinel */ }
+};
+
 /*
  * Selected Rate Control Related Parameter Recommended Values
  * from DSC_v1.11 spec & C Model release: DSC_model_20161212
  */
-static const struct rc_parameters_data rc_parameters[] = {
+static const struct rc_parameters_data rc_parameters_1_2_444[] = {
{
.bpp = DSC_BPP(6), .bpc = 8,
{ 768, 15, 6144, 3, 13, 11, 11, {
@@ -388,22 +458,18 @@ static const struct rc_parameters_data rc_parameters[] = {
{ 512, 12, 6144, 3, 12, 11, 11, {
{ 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
{ 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
-   { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12, 
-12 },
-   { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+   { 3, 9, -8 }, { 3, 10, -10 }, { 5, 10, -10 }, { 5, 11, 
-12 },
+   { 5, 11, -12 }, { 9, 12, -12 },

[PATCH v3 09/10] drm/display/dsc: add helper to set semi-const parameters

Add a helper setting config values which are typically constant across
operating modes (table E-4 of the standard) and mux_word_size (which is
a const according to 3.5.2).

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_dsc_helper.c | 21 +
 include/drm/display/drm_dsc_helper.h |  1 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index 65e810a54257..10ba413d8bf1 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -270,6 +270,27 @@ void drm_dsc_pps_payload_pack(struct 
drm_dsc_picture_parameter_set *pps_payload,
 }
 EXPORT_SYMBOL(drm_dsc_pps_payload_pack);
 
+/**
+ * drm_dsc_set_const_params() - Set DSC parameters considered typically
+ * constant across operation modes
+ *
+ * @vdsc_cfg:
+ * DSC Configuration data partially filled by driver
+ */
+void drm_dsc_set_const_params(struct drm_dsc_config *vdsc_cfg)
+{
+   vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
+   vdsc_cfg->rc_edge_factor = DSC_RC_EDGE_FACTOR_CONST;
+   vdsc_cfg->rc_tgt_offset_high = DSC_RC_TGT_OFFSET_HI_CONST;
+   vdsc_cfg->rc_tgt_offset_low = DSC_RC_TGT_OFFSET_LO_CONST;
+
+   if (vdsc_cfg->bits_per_component <= 10)
+   vdsc_cfg->mux_word_size = DSC_MUX_WORD_SIZE_8_10_BPC;
+   else
+   vdsc_cfg->mux_word_size = DSC_MUX_WORD_SIZE_12_BPC;
+}
+EXPORT_SYMBOL(drm_dsc_set_const_params);
+
 /* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
 static const u16 drm_dsc_rc_buf_thresh[] = {
896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
diff --git a/include/drm/display/drm_dsc_helper.h 
b/include/drm/display/drm_dsc_helper.h
index 0bb0c3afd740..4448c482b092 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -21,6 +21,7 @@ void drm_dsc_dp_pps_header_init(struct dp_sdp_header 
*pps_header);
 int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
 void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,
  const struct drm_dsc_config *dsc_cfg);
+void drm_dsc_set_const_params(struct drm_dsc_config *vdsc_cfg);
 void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
 int drm_dsc_setup_rc_params(struct drm_dsc_config *vdsc_cfg, enum 
drm_dsc_params_kind kind);
 int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
-- 
2.39.2

[PATCH v3 05/10] drm/display/dsc: use flat array for rc_parameters lookup

Next commits are going to add support for additional RC parameter lookup
tables. These tables are going to use different bpp/bpc combinations,
thus it makes little sense to keep the 2d array for RC parameters.
Switch to using the flat array.

Reviewed-by: Jani Nikula 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_dsc_helper.c | 228 +++
 1 file changed, 108 insertions(+), 120 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index 122a292bbc8f..acb93d4116e0 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -305,24 +305,6 @@ void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config 
*vdsc_cfg)
 }
 EXPORT_SYMBOL(drm_dsc_set_rc_buf_thresh);
 
-enum ROW_INDEX_BPP {
-   ROW_INDEX_6BPP = 0,
-   ROW_INDEX_8BPP,
-   ROW_INDEX_10BPP,
-   ROW_INDEX_12BPP,
-   ROW_INDEX_15BPP,
-   MAX_ROW_INDEX
-};
-
-enum COLUMN_INDEX_BPC {
-   COLUMN_INDEX_8BPC = 0,
-   COLUMN_INDEX_10BPC,
-   COLUMN_INDEX_12BPC,
-   COLUMN_INDEX_14BPC,
-   COLUMN_INDEX_16BPC,
-   MAX_COLUMN_INDEX
-};
-
 struct rc_parameters {
u16 initial_xmit_delay;
u8 first_line_bpg_offset;
@@ -334,21 +316,31 @@ struct rc_parameters {
struct drm_dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
 };
 
+struct rc_parameters_data {
+   u8 bpp;
+   u8 bpc;
+   struct rc_parameters params;
+};
+
+#define DSC_BPP(bpp)   ((bpp) << 4)
+
 /*
  * Selected Rate Control Related Parameter Recommended Values
  * from DSC_v1.11 spec & C Model release: DSC_model_20161212
  */
-static const struct rc_parameters rc_parameters[][MAX_COLUMN_INDEX] = {
+static const struct rc_parameters_data rc_parameters[] = {
{
-   /* 6BPP/8BPC */
+   .bpp = DSC_BPP(6), .bpc = 8,
{ 768, 15, 6144, 3, 13, 11, 11, {
{ 0, 4, 0 }, { 1, 6, -2 }, { 3, 8, -2 }, { 4, 8, -4 },
{ 5, 9, -6 }, { 5, 9, -6 }, { 6, 9, -6 }, { 6, 10, -8 },
{ 7, 11, -8 }, { 8, 12, -10 }, { 9, 12, -10 }, { 10, 
12, -12 },
{ 10, 12, -12 }, { 11, 12, -12 }, { 13, 14, -12 }
}
-   },
-   /* 6BPP/10BPC */
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 10,
{ 768, 15, 6144, 7, 17, 15, 15, {
{ 0, 8, 0 }, { 3, 10, -2 }, { 7, 12, -2 }, { 8, 12, -4 
},
{ 9, 13, -6 }, { 9, 13, -6 }, { 10, 13, -6 }, { 10, 14, 
-8 },
@@ -356,8 +348,10 @@ static const struct rc_parameters 
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 14, 16, -12 }, { 14, 16, -12 }, { 15, 16, -12 },
{ 17, 18, -12 }
}
-   },
-   /* 6BPP/12BPC */
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 12,
{ 768, 15, 6144, 11, 21, 19, 19, {
{ 0, 12, 0 }, { 5, 14, -2 }, { 11, 16, -2 }, { 12, 16, 
-4 },
{ 13, 17, -6 }, { 13, 17, -6 }, { 14, 17, -6 }, { 14, 
18, -8 },
@@ -365,8 +359,10 @@ static const struct rc_parameters 
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 18, 20, -12 }, { 18, 20, -12 }, { 19, 20, -12 },
{ 21, 22, -12 }
}
-   },
-   /* 6BPP/14BPC */
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 14,
{ 768, 15, 6144, 15, 25, 23, 23, {
{ 0, 16, 0 }, { 7, 18, -2 }, { 15, 20, -2 }, { 16, 20, 
-4 },
{ 17, 21, -6 }, { 17, 21, -6 }, { 18, 21, -6 }, { 18, 
22, -8 },
@@ -374,8 +370,10 @@ static const struct rc_parameters 
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 22, 24, -12 }, { 22, 24, -12 }, { 23, 24, -12 },
{ 25, 26, -12 }
}
-   },
-   /* 6BPP/16BPC */
+   }
+   },
+   {
+   .bpp = DSC_BPP(6), .bpc = 16,
{ 768, 15, 6144, 19, 29, 27, 27, {
{ 0, 20, 0 }, { 9, 22, -2 }, { 19, 24, -2 }, { 20, 24, 
-4 },
{ 21, 25, -6 }, { 21, 25, -6 }, { 22, 25, -6 }, { 22, 
26, -8 },
@@ -383,18 +381,20 @@ static const struct rc_parameters 
rc_parameters[][MAX_COLUMN_INDEX] = {
{ 26, 28, -12 }, { 26, 28, -12 }, { 27, 28, -12 },
{ 29, 30, -12 }
}
-   },
+   }
},
{
-   /* 8BPP/8BPC */
+   .bpp = DSC_BPP(8), .bpc = 8,
{ 512, 12, 6144, 3, 12, 11, 11, {
{ 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
{ 3, 7, -4 }, { 3, 7, -6 }, { 3, 7,

[PATCH v3 10/10] drm/msm/dsi: use new helpers for DSC setup

Use new DRM DSC helpers to setup DSI DSC configuration. The
initial_scale_value needs to be adjusted according to the standard, but
this is a separate change.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 61 --
 1 file changed, 8 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 18fa30e1e858..dda989727921 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -1735,28 +1735,9 @@ static int dsi_host_parse_lane_data(struct msm_dsi_host 
*msm_host,
return -EINVAL;
 }
 
-static u32 dsi_dsc_rc_buf_thresh[DSC_NUM_BUF_RANGES - 1] = {
-   0x0e, 0x1c, 0x2a, 0x38, 0x46, 0x54, 0x62,
-   0x69, 0x70, 0x77, 0x79, 0x7b, 0x7d, 0x7e
-};
-
-/* only 8bpc, 8bpp added */
-static char min_qp[DSC_NUM_BUF_RANGES] = {
-   0, 0, 1, 1, 3, 3, 3, 3, 3, 3, 5, 5, 5, 7, 13
-};
-
-static char max_qp[DSC_NUM_BUF_RANGES] = {
-   4, 4, 5, 6, 7, 7, 7, 8, 9, 10, 11, 12, 13, 13, 15
-};
-
-static char bpg_offset[DSC_NUM_BUF_RANGES] = {
-   2, 0, 0, -2, -4, -6, -8, -8, -8, -10, -10, -12, -12, -12, -12
-};
-
 static int dsi_populate_dsc_params(struct msm_dsi_host *msm_host, struct 
drm_dsc_config *dsc)
 {
-   int i;
-   u16 bpp = dsc->bits_per_pixel >> 4;
+   int ret;
 
if (dsc->bits_per_pixel & 0xf) {
DRM_DEV_ERROR(&msm_host->pdev->dev, "DSI does not support 
fractional bits_per_pixel\n");
@@ -1768,49 +1749,23 @@ static int dsi_populate_dsc_params(struct msm_dsi_host 
*msm_host, struct drm_dsc
return -EOPNOTSUPP;
}
 
-   dsc->rc_model_size = 8192;
-   dsc->first_line_bpg_offset = 12;
-   dsc->rc_edge_factor = 6;
-   dsc->rc_tgt_offset_high = 3;
-   dsc->rc_tgt_offset_low = 3;
dsc->simple_422 = 0;
dsc->convert_rgb = 1;
dsc->vbr_enable = 0;
 
-   /* handle only bpp = bpc = 8 */
-   for (i = 0; i < DSC_NUM_BUF_RANGES - 1 ; i++)
-   dsc->rc_buf_thresh[i] = dsi_dsc_rc_buf_thresh[i];
+   drm_dsc_set_const_params(dsc);
+   drm_dsc_set_rc_buf_thresh(dsc);
 
-   for (i = 0; i < DSC_NUM_BUF_RANGES; i++) {
-   dsc->rc_range_params[i].range_min_qp = min_qp[i];
-   dsc->rc_range_params[i].range_max_qp = max_qp[i];
-   /*
-* Range BPG Offset contains two's-complement signed values 
that fill
-* 8 bits, yet the registers and DCS PPS field are only 6 bits 
wide.
-*/
-   dsc->rc_range_params[i].range_bpg_offset = bpg_offset[i] & 
DSC_RANGE_BPG_OFFSET_MASK;
+   /* handle only bpp = bpc = 8, pre-SCR panels */
+   ret = drm_dsc_setup_rc_params(dsc, DRM_DSC_1_1_PRE_SCR);
+   if (ret) {
+   DRM_DEV_ERROR(&msm_host->pdev->dev, "could not find DSC RC 
parameters\n");
+   return ret;
}
 
-   dsc->initial_offset = 6144; /* Not bpp 12 */
-   if (bpp != 8)
-   dsc->initial_offset = 2048; /* bpp = 12 */
-
-   if (dsc->bits_per_component <= 10)
-   dsc->mux_word_size = DSC_MUX_WORD_SIZE_8_10_BPC;
-   else
-   dsc->mux_word_size = DSC_MUX_WORD_SIZE_12_BPC;
-
-   dsc->initial_xmit_delay = 512;
dsc->initial_scale_value = 32;
-   dsc->first_line_bpg_offset = 12;
dsc->line_buf_depth = dsc->bits_per_component + 1;
 
-   /* bpc 8 */
-   dsc->flatness_min_qp = 3;
-   dsc->flatness_max_qp = 12;
-   dsc->rc_quant_incr_limit0 = 11;
-   dsc->rc_quant_incr_limit1 = 11;
-
return drm_dsc_compute_rc_parameters(dsc);
 }
 
-- 
2.39.2

[PATCH v3 03/10] drm/i915/dsc: move DSC tables to DRM DSC helper

Move DSC RC tables to DRM DSC helper. No additional code changes
and/or cleanups are a part of this commit, it will be cleaned up in the
followup commits.

Reviewed-by: Jani Nikula 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_dsc_helper.c  | 372 ++
 drivers/gpu/drm/i915/display/intel_vdsc.c | 319 +--
 include/drm/display/drm_dsc_helper.h  |   1 +
 3 files changed, 380 insertions(+), 312 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index be91abe2cfb2..122a292bbc8f 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -305,6 +305,378 @@ void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config 
*vdsc_cfg)
 }
 EXPORT_SYMBOL(drm_dsc_set_rc_buf_thresh);
 
+enum ROW_INDEX_BPP {
+   ROW_INDEX_6BPP = 0,
+   ROW_INDEX_8BPP,
+   ROW_INDEX_10BPP,
+   ROW_INDEX_12BPP,
+   ROW_INDEX_15BPP,
+   MAX_ROW_INDEX
+};
+
+enum COLUMN_INDEX_BPC {
+   COLUMN_INDEX_8BPC = 0,
+   COLUMN_INDEX_10BPC,
+   COLUMN_INDEX_12BPC,
+   COLUMN_INDEX_14BPC,
+   COLUMN_INDEX_16BPC,
+   MAX_COLUMN_INDEX
+};
+
+struct rc_parameters {
+   u16 initial_xmit_delay;
+   u8 first_line_bpg_offset;
+   u16 initial_offset;
+   u8 flatness_min_qp;
+   u8 flatness_max_qp;
+   u8 rc_quant_incr_limit0;
+   u8 rc_quant_incr_limit1;
+   struct drm_dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
+};
+
+/*
+ * Selected Rate Control Related Parameter Recommended Values
+ * from DSC_v1.11 spec & C Model release: DSC_model_20161212
+ */
+static const struct rc_parameters rc_parameters[][MAX_COLUMN_INDEX] = {
+   {
+   /* 6BPP/8BPC */
+   { 768, 15, 6144, 3, 13, 11, 11, {
+   { 0, 4, 0 }, { 1, 6, -2 }, { 3, 8, -2 }, { 4, 8, -4 },
+   { 5, 9, -6 }, { 5, 9, -6 }, { 6, 9, -6 }, { 6, 10, -8 },
+   { 7, 11, -8 }, { 8, 12, -10 }, { 9, 12, -10 }, { 10, 
12, -12 },
+   { 10, 12, -12 }, { 11, 12, -12 }, { 13, 14, -12 }
+   }
+   },
+   /* 6BPP/10BPC */
+   { 768, 15, 6144, 7, 17, 15, 15, {
+   { 0, 8, 0 }, { 3, 10, -2 }, { 7, 12, -2 }, { 8, 12, -4 
},
+   { 9, 13, -6 }, { 9, 13, -6 }, { 10, 13, -6 }, { 10, 14, 
-8 },
+   { 11, 15, -8 }, { 12, 16, -10 }, { 13, 16, -10 },
+   { 14, 16, -12 }, { 14, 16, -12 }, { 15, 16, -12 },
+   { 17, 18, -12 }
+   }
+   },
+   /* 6BPP/12BPC */
+   { 768, 15, 6144, 11, 21, 19, 19, {
+   { 0, 12, 0 }, { 5, 14, -2 }, { 11, 16, -2 }, { 12, 16, 
-4 },
+   { 13, 17, -6 }, { 13, 17, -6 }, { 14, 17, -6 }, { 14, 
18, -8 },
+   { 15, 19, -8 }, { 16, 20, -10 }, { 17, 20, -10 },
+   { 18, 20, -12 }, { 18, 20, -12 }, { 19, 20, -12 },
+   { 21, 22, -12 }
+   }
+   },
+   /* 6BPP/14BPC */
+   { 768, 15, 6144, 15, 25, 23, 23, {
+   { 0, 16, 0 }, { 7, 18, -2 }, { 15, 20, -2 }, { 16, 20, 
-4 },
+   { 17, 21, -6 }, { 17, 21, -6 }, { 18, 21, -6 }, { 18, 
22, -8 },
+   { 19, 23, -8 }, { 20, 24, -10 }, { 21, 24, -10 },
+   { 22, 24, -12 }, { 22, 24, -12 }, { 23, 24, -12 },
+   { 25, 26, -12 }
+   }
+   },
+   /* 6BPP/16BPC */
+   { 768, 15, 6144, 19, 29, 27, 27, {
+   { 0, 20, 0 }, { 9, 22, -2 }, { 19, 24, -2 }, { 20, 24, 
-4 },
+   { 21, 25, -6 }, { 21, 25, -6 }, { 22, 25, -6 }, { 22, 
26, -8 },
+   { 23, 27, -8 }, { 24, 28, -10 }, { 25, 28, -10 },
+   { 26, 28, -12 }, { 26, 28, -12 }, { 27, 28, -12 },
+   { 29, 30, -12 }
+   }
+   },
+   },
+   {
+   /* 8BPP/8BPC */
+   { 512, 12, 6144, 3, 12, 11, 11, {
+   { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
+   { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+   { 3, 9, -8 }, { 3, 10, -10 }, { 5, 11, -10 }, { 5, 12, 
-12 },
+   { 5, 13, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+   }
+   },
+   /* 8BPP/10BPC */
+   { 512, 12, 6144, 7, 16, 15, 15, {
+   /*
+* DSC model/pre-SCR-cfg has 8 for range_max_qp[0], 
however
+* VESA DSC 1.1 Table E-5 sets it to 4.
+*/
+   { 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
+

[PATCH v3 07/10] drm/display/dsc: include the rest of pre-SCR parameters

DSC model contains pre-SCR RC parameters for other bpp/bpc combinations,
include them here for completeness.

Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_dsc_helper.c | 72 
 1 file changed, 72 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index 35b39f3109c4..aec6f8c201af 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -325,6 +325,16 @@ struct rc_parameters_data {
 #define DSC_BPP(bpp)   ((bpp) << 4)
 
 static const struct rc_parameters_data rc_parameters_pre_scr[] = {
+   {
+   .bpp = DSC_BPP(6), .bpc = 8,
+   { 683, 15, 6144, 3, 13, 11, 11, {
+   { 0, 2, 0 }, { 1, 4, -2 }, { 3, 6, -2 }, { 4, 6, -4 },
+   { 5, 7, -6 }, { 5, 7, -6 }, { 6, 7, -6 }, { 6, 8, -8 },
+   { 7, 9, -8 }, { 8, 10, -10 }, { 9, 11, -10 }, { 10, 12, 
-12 },
+   { 10, 13, -12 }, { 12, 14, -12 }, { 15, 15, -12 }
+   }
+   }
+   },
{
.bpp = DSC_BPP(8), .bpc = 8,
{ 512, 12, 6144, 3, 12, 11, 11, {
@@ -360,6 +370,37 @@ static const struct rc_parameters_data 
rc_parameters_pre_scr[] = {
}
}
},
+   {
+   .bpp = DSC_BPP(10), .bpc = 8,
+   { 410, 12, 5632, 3, 12, 11, 11, {
+   { 0, 3, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 2, 6, -2 },
+   { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
+   { 3, 9, -8 }, { 3, 9, -10 }, { 5, 10, -10 }, { 5, 11, 
-10 },
+   { 5, 12, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(10), .bpc = 10,
+   { 410, 12, 5632, 7, 16, 15, 15, {
+   { 0, 7, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 6, 10, -2 },
+   { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, 
-8 },
+   { 7, 13, -8 }, { 7, 13, -10 }, { 9, 14, -10 }, { 9, 15, 
-10 },
+   { 9, 16, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(10), .bpc = 12,
+   { 410, 12, 5632, 11, 20, 19, 19, {
+   { 0, 11, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 10, 14, -2 
},
+   { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11, 
16, -8 },
+   { 11, 17, -8 }, { 11, 17, -10 }, { 13, 18, -10 },
+   { 13, 19, -10 }, { 13, 20, -12 }, { 15, 21, -12 },
+   { 21, 23, -12 }
+   }
+   }
+   },
{
.bpp = DSC_BPP(12), .bpc = 8,
{ 341, 15, 2048, 3, 12, 11, 11, {
@@ -391,6 +432,37 @@ static const struct rc_parameters_data 
rc_parameters_pre_scr[] = {
}
}
},
+   {
+   .bpp = DSC_BPP(15), .bpc = 8,
+   { 273, 15, 2048, 3, 12, 11, 11, {
+   { 0, 0, 10 }, { 0, 1, 8 }, { 0, 1, 6 }, { 0, 2, 4 },
+   { 1, 2, 2 }, { 1, 3, 0 }, { 1, 4, -2 }, { 2, 4, -4 },
+   { 3, 4, -6 }, { 3, 5, -8 }, { 4, 6, -10 }, { 5, 7, -10 
},
+   { 5, 8, -12 }, { 7, 13, -12 }, { 13, 15, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(15), .bpc = 10,
+   { 273, 15, 2048, 7, 16, 15, 15, {
+   { 0, 2, 10 }, { 2, 5, 8 }, { 3, 5, 6 }, { 4, 6, 4 },
+   { 5, 6, 2 }, { 5, 7, 0 }, { 5, 8, -2 }, { 6, 8, -4 },
+   { 7, 8, -6 }, { 7, 9, -8 }, { 8, 10, -10 }, { 9, 11, 
-10 },
+   { 9, 12, -12 }, { 11, 17, -12 }, { 17, 19, -12 }
+   }
+   }
+   },
+   {
+   .bpp = DSC_BPP(15), .bpc = 12,
+   { 273, 15, 2048, 11, 20, 19, 19, {
+   { 0, 4, 10 }, { 2, 7, 8 }, { 4, 9, 6 }, { 6, 11, 4 },
+   { 9, 11, 2 }, { 9, 11, 0 }, { 9, 12, -2 }, { 10, 12, -4 
},
+   { 11, 12, -6 }, { 11, 13, -8 }, { 12, 14, -10 },
+   { 13, 15, -10 }, { 13, 16, -12 }, { 15, 21, -12 },
+   { 21, 23, -12 }
+   }
+   }
+   },
{ /* sentinel */ }
 };
 
-- 
2.39.2

[PATCH v3 04/10] drm/i915/dsc: stop using interim structure for calculated params

Stop using an interim structure rc_parameters for storing calculated
params and then setting drm_dsc_config using that structure. Instead put
calculated params into the struct drm_dsc_config directly.

Reviewed-by: Jani Nikula 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/i915/display/intel_vdsc.c | 100 ++
 1 file changed, 26 insertions(+), 74 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 2ff795e0f5fb..e4b698d04103 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -19,17 +19,6 @@
 #include "intel_vdsc.h"
 #include "intel_vdsc_regs.h"
 
-struct rc_parameters {
-   u16 initial_xmit_delay;
-   u8 first_line_bpg_offset;
-   u16 initial_offset;
-   u8 flatness_min_qp;
-   u8 flatness_max_qp;
-   u8 rc_quant_incr_limit0;
-   u8 rc_quant_incr_limit1;
-   struct drm_dsc_rc_range_parameters rc_range_params[DSC_NUM_BUF_RANGES];
-};
-
 bool intel_dsc_source_support(const struct intel_crtc_state *crtc_state)
 {
const struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
@@ -64,8 +53,7 @@ static bool is_pipe_dsc(struct intel_crtc *crtc, enum 
transcoder cpu_transcoder)
 }
 
 static void
-calculate_rc_params(struct rc_parameters *rc,
-   struct drm_dsc_config *vdsc_cfg)
+calculate_rc_params(struct drm_dsc_config *vdsc_cfg)
 {
int bpc = vdsc_cfg->bits_per_component;
int bpp = vdsc_cfg->bits_per_pixel >> 4;
@@ -85,56 +73,57 @@ calculate_rc_params(struct rc_parameters *rc,
u32 res, buf_i, bpp_i;
 
if (vdsc_cfg->slice_height >= 8)
-   rc->first_line_bpg_offset =
+   vdsc_cfg->first_line_bpg_offset =
12 + DIV_ROUND_UP((9 * min(34, vdsc_cfg->slice_height - 
8)), 100);
else
-   rc->first_line_bpg_offset = 2 * (vdsc_cfg->slice_height - 1);
+   vdsc_cfg->first_line_bpg_offset = 2 * (vdsc_cfg->slice_height - 
1);
 
/* Our hw supports only 444 modes as of today */
if (bpp >= 12)
-   rc->initial_offset = 2048;
+   vdsc_cfg->initial_offset = 2048;
else if (bpp >= 10)
-   rc->initial_offset = 5632 - DIV_ROUND_UP(((bpp - 10) * 3584), 
2);
+   vdsc_cfg->initial_offset = 5632 - DIV_ROUND_UP(((bpp - 10) * 
3584), 2);
else if (bpp >= 8)
-   rc->initial_offset = 6144 - DIV_ROUND_UP(((bpp - 8) * 512), 2);
+   vdsc_cfg->initial_offset = 6144 - DIV_ROUND_UP(((bpp - 8) * 
512), 2);
else
-   rc->initial_offset = 6144;
+   vdsc_cfg->initial_offset = 6144;
 
/* initial_xmit_delay = rc_model_size/2/compression_bpp */
-   rc->initial_xmit_delay = DIV_ROUND_UP(DSC_RC_MODEL_SIZE_CONST, 2 * bpp);
+   vdsc_cfg->initial_xmit_delay = DIV_ROUND_UP(DSC_RC_MODEL_SIZE_CONST, 2 
* bpp);
 
-   rc->flatness_min_qp = 3 + qp_bpc_modifier;
-   rc->flatness_max_qp = 12 + qp_bpc_modifier;
+   vdsc_cfg->flatness_min_qp = 3 + qp_bpc_modifier;
+   vdsc_cfg->flatness_max_qp = 12 + qp_bpc_modifier;
 
-   rc->rc_quant_incr_limit0 = 11 + qp_bpc_modifier;
-   rc->rc_quant_incr_limit1 = 11 + qp_bpc_modifier;
+   vdsc_cfg->rc_quant_incr_limit0 = 11 + qp_bpc_modifier;
+   vdsc_cfg->rc_quant_incr_limit1 = 11 + qp_bpc_modifier;
 
bpp_i  = (2 * (bpp - 6));
for (buf_i = 0; buf_i < DSC_NUM_BUF_RANGES; buf_i++) {
+   u8 range_bpg_offset;
+
/* Read range_minqp and range_max_qp from qp tables */
-   rc->rc_range_params[buf_i].range_min_qp =
+   vdsc_cfg->rc_range_params[buf_i].range_min_qp =
intel_lookup_range_min_qp(bpc, buf_i, bpp_i);
-   rc->rc_range_params[buf_i].range_max_qp =
+   vdsc_cfg->rc_range_params[buf_i].range_max_qp =
intel_lookup_range_max_qp(bpc, buf_i, bpp_i);
 
-   /* Calculate range_bgp_offset */
+   /* Calculate range_bpg_offset */
if (bpp <= 6) {
-   rc->rc_range_params[buf_i].range_bpg_offset = 
ofs_und6[buf_i];
+   range_bpg_offset = ofs_und6[buf_i];
} else if (bpp <= 8) {
res = DIV_ROUND_UP(((bpp - 6) * (ofs_und8[buf_i] - 
ofs_und6[buf_i])), 2);
-   rc->rc_range_params[buf_i].range_bpg_offset =
-   ofs_und6[buf_i] 
+ res;
+   range_bpg_offset = ofs_und6[buf_i] + res;
} else if (bpp <= 12) {
-   rc->rc_range_params[buf_i].range_bpg_offset =
-   ofs_und8[buf_i];
+   range_bpg_offset = ofs_und8[buf_i];
} else if (bpp <= 15) {
res = DIV_ROUND_UP((

[PATCH v3 02/10] drm/i915/dsc: move rc_buf_thresh values to common helper

The rc_buf_thresh values are common to all DSC implementations. Move
them to the common helper together with the code to propagage them to
the drm_dsc_config.

Reviewed-by: Jani Nikula 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/display/drm_dsc_helper.c  | 35 +++
 drivers/gpu/drm/i915/display/intel_vdsc.c | 24 +---
 include/drm/display/drm_dsc_helper.h  |  1 +
 3 files changed, 37 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dsc_helper.c 
b/drivers/gpu/drm/display/drm_dsc_helper.c
index c869c6e51e2b..be91abe2cfb2 100644
--- a/drivers/gpu/drm/display/drm_dsc_helper.c
+++ b/drivers/gpu/drm/display/drm_dsc_helper.c
@@ -270,6 +270,41 @@ void drm_dsc_pps_payload_pack(struct 
drm_dsc_picture_parameter_set *pps_payload,
 }
 EXPORT_SYMBOL(drm_dsc_pps_payload_pack);
 
+/* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
+static const u16 drm_dsc_rc_buf_thresh[] = {
+   896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
+   7744, 7872, 8000, 8064
+};
+
+/**
+ * drm_dsc_set_rc_buf_thresh() - Set thresholds for the RC model
+ * in accordance with the DSC 1.2 specification.
+ *
+ * @vdsc_cfg: DSC Configuration data partially filled by driver
+ */
+void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg)
+{
+   int i;
+
+   BUILD_BUG_ON(ARRAY_SIZE(drm_dsc_rc_buf_thresh) !=
+DSC_NUM_BUF_RANGES - 1);
+   BUILD_BUG_ON(ARRAY_SIZE(drm_dsc_rc_buf_thresh) !=
+ARRAY_SIZE(vdsc_cfg->rc_buf_thresh));
+
+   for (i = 0; i < ARRAY_SIZE(drm_dsc_rc_buf_thresh); i++)
+   vdsc_cfg->rc_buf_thresh[i] = drm_dsc_rc_buf_thresh[i] >> 6;
+
+   /*
+* For 6bpp, RC Buffer threshold 12 and 13 need a different value
+* as per C Model
+*/
+   if (vdsc_cfg->bits_per_pixel == 6 << 4) {
+   vdsc_cfg->rc_buf_thresh[12] = 7936 >> 6;
+   vdsc_cfg->rc_buf_thresh[13] = 8000 >> 6;
+   }
+}
+EXPORT_SYMBOL(drm_dsc_set_rc_buf_thresh);
+
 /**
  * drm_dsc_compute_rc_parameters() - Write rate control
  * parameters to the dsc configuration defined in
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 20ce13b0a16b..5388dc88f4a6 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -37,12 +37,6 @@ enum COLUMN_INDEX_BPC {
MAX_COLUMN_INDEX
 };
 
-/* From DSC_v1.11 spec, rc_parameter_Set syntax element typically constant */
-static const u16 rc_buf_thresh[] = {
-   896, 1792, 2688, 3584, 4480, 5376, 6272, 6720, 7168, 7616,
-   7744, 7872, 8000, 8064
-};
-
 struct rc_parameters {
u16 initial_xmit_delay;
u8 first_line_bpg_offset;
@@ -475,23 +469,7 @@ int intel_dsc_compute_params(struct intel_crtc_state 
*pipe_config)
vdsc_cfg->bits_per_pixel = compressed_bpp << 4;
vdsc_cfg->bits_per_component = pipe_config->pipe_bpp / 3;
 
-   for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
-   /*
-* six 0s are appended to the lsb of each threshold value
-* internally in h/w.
-* Only 8 bits are allowed for programming RcBufThreshold
-*/
-   vdsc_cfg->rc_buf_thresh[i] = rc_buf_thresh[i] >> 6;
-   }
-
-   /*
-* For 6bpp, RC Buffer threshold 12 and 13 need a different value
-* as per C Model
-*/
-   if (compressed_bpp == 6) {
-   vdsc_cfg->rc_buf_thresh[12] = 0x7C;
-   vdsc_cfg->rc_buf_thresh[13] = 0x7D;
-   }
+   drm_dsc_set_rc_buf_thresh(vdsc_cfg);
 
/*
 * From XE_LPD onwards we supports compression bpps in steps of 1
diff --git a/include/drm/display/drm_dsc_helper.h 
b/include/drm/display/drm_dsc_helper.h
index 8b41edbbabab..706ba1d34742 100644
--- a/include/drm/display/drm_dsc_helper.h
+++ b/include/drm/display/drm_dsc_helper.h
@@ -14,6 +14,7 @@ void drm_dsc_dp_pps_header_init(struct dp_sdp_header 
*pps_header);
 int drm_dsc_dp_rc_buffer_size(u8 rc_buffer_block_size, u8 rc_buffer_size);
 void drm_dsc_pps_payload_pack(struct drm_dsc_picture_parameter_set *pps_sdp,
  const struct drm_dsc_config *dsc_cfg);
+void drm_dsc_set_rc_buf_thresh(struct drm_dsc_config *vdsc_cfg);
 int drm_dsc_compute_rc_parameters(struct drm_dsc_config *vdsc_cfg);
 
 #endif /* _DRM_DSC_HELPER_H_ */
-- 
2.39.2

[PATCH v3 00/10] drm/i915: move DSC RC tables to drm_dsc_helper.c

Other platforms (msm) will benefit from sharing the DSC config setup
functions. This series moves parts of static DSC config data from the
i915 driver to the common helpers to be used by other drivers.

Note: the RC parameters were cross-checked against config files found in
DSC model 2021062, 20161212 (and 20150914). The first patch modifies
tables according to those config files, while preserving parameter
values using the code. I have not changed one of the values in the
pre-SCR config file as it clearly looks like a typo in the config file,
considering the table E in DSC 1.1 and in the DSC 1.1 SCR.

Chances since v2:
- Rebased on top of drm-intel-next

Chances since v1:
- Made drm_dsc_rc_buf_thresh static rather than exporting it
- Switched drm_dsc_rc_buf_thresh loop to use ARRAY_SIZE. Added
  BUILD_BUG_ON's to be sure that array sizes are correct
- Fixed rc_parameters_data indentation to be logical and tidy
- Fixed drm_dsc_setup_rc_params() kerneldoc
- Added a clause to drm_dsc_setup_rc_params() to verify bpp and bpc
  being set.
- Fixed range_bpg_offset programming in calculate_rc_params()
- Fixed bpp vs bpc bug in intel_dsc_compute_params()
- Added FIXME comment next to the customizations in
  intel_dsc_compute_params().

Dmitry Baryshkov (10):
  drm/i915/dsc: change DSC param tables to follow the DSC model
  drm/i915/dsc: move rc_buf_thresh values to common helper
  drm/i915/dsc: move DSC tables to DRM DSC helper
  drm/i915/dsc: stop using interim structure for calculated params
  drm/display/dsc: use flat array for rc_parameters lookup
  drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR) parameters
  drm/display/dsc: include the rest of pre-SCR parameters
  drm/display/dsc: add YCbCr 4:2:2 and 4:2:0 RC parameters
  drm/display/dsc: add helper to set semi-const parameters
  drm/msm/dsi: use new helpers for DSC setup

 drivers/gpu/drm/display/drm_dsc_helper.c  | 1007 +
 drivers/gpu/drm/i915/display/intel_vdsc.c |  443 +
 drivers/gpu/drm/msm/dsi/dsi_host.c|   61 +-
 include/drm/display/drm_dsc_helper.h  |   10 +
 4 files changed, 1072 insertions(+), 449 deletions(-)

-- 
2.39.2

[PATCH v3 01/10] drm/i915/dsc: change DSC param tables to follow the DSC model

After cross-checking DSC models (20150914, 20161212, 20210623) change
values in rc_parameters tables to follow config files present inside
the DSC model. Handle two places, where i915 tables diverged from the
model, by patching the rc values in the code.

Note: I left one case uncorrected, 8bpp/10bpc/range_max_qp[0], because
the table in the VESA DSC 1.1 sets it to 4.

Reviewed-by: Jani Nikula 
Signed-off-by: Dmitry Baryshkov 
---
 drivers/gpu/drm/i915/display/intel_vdsc.c | 22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c 
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index 09b32ffdc552..20ce13b0a16b 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -87,7 +87,7 @@ static const struct rc_parameters 
rc_parameters[][MAX_COLUMN_INDEX] = {
}
},
/* 6BPP/14BPC */
-   { 768, 15, 6144, 15, 25, 23, 27, {
+   { 768, 15, 6144, 15, 25, 23, 23, {
{ 0, 16, 0 }, { 7, 18, -2 }, { 15, 20, -2 }, { 16, 20, -4 },
{ 17, 21, -6 }, { 17, 21, -6 }, { 18, 21, -6 }, { 18, 22, -8 },
{ 19, 23, -8 }, { 20, 24, -10 }, { 21, 24, -10 },
@@ -116,6 +116,10 @@ static const struct rc_parameters 
rc_parameters[][MAX_COLUMN_INDEX] = {
},
/* 8BPP/10BPC */
{ 512, 12, 6144, 7, 16, 15, 15, {
+   /*
+* DSC model/pre-SCR-cfg has 8 for range_max_qp[0], however
+* VESA DSC 1.1 Table E-5 sets it to 4.
+*/
{ 0, 4, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
{ 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12, -8 },
{ 7, 13, -8 }, { 7, 14, -10 }, { 9, 15, -10 }, { 9, 16, -12 },
@@ -133,7 +137,7 @@ static const struct rc_parameters 
rc_parameters[][MAX_COLUMN_INDEX] = {
},
/* 8BPP/14BPC */
{ 512, 12, 6144, 15, 24, 23, 23, {
-   { 0, 12, 0 }, { 5, 13, 0 }, { 11, 15, 0 }, { 12, 17, -2 },
+   { 0, 12, 2 }, { 5, 13, 0 }, { 11, 15, 0 }, { 12, 17, -2 },
{ 15, 19, -4 }, { 15, 19, -6 }, { 15, 19, -8 }, { 15, 20, -8 },
{ 15, 21, -8 }, { 15, 22, -10 }, { 17, 22, -10 },
{ 17, 23, -12 }, { 17, 23, -12 }, { 21, 24, -12 },
@@ -530,6 +534,20 @@ int intel_dsc_compute_params(struct intel_crtc_state 
*pipe_config)
DSC_RANGE_BPG_OFFSET_MASK;
}
 
+   if (DISPLAY_VER(dev_priv) < 13) {
+   /*
+* FIXME: verify that the hardware actually needs these
+* modifications rather than them being simple typos.
+*/
+   if (compressed_bpp == 6 &&
+   vdsc_cfg->bits_per_component == 8)
+   vdsc_cfg->rc_quant_incr_limit1 = 23;
+
+   if (compressed_bpp == 8 &&
+   vdsc_cfg->bits_per_component == 14)
+   vdsc_cfg->rc_range_params[0].range_bpg_offset = 0;
+   }
+
/*
 * BitsPerComponent value determines mux_word_size:
 * When BitsPerComponent is less than or 10bpc, muxWordSize will be 
equal to
-- 
2.39.2

[PATCH] drm/i915/hwmon: Use 0 to designate disabled PL1 power limit

2023-03-28 Thread Ashutosh Dixit

On ATSM the PL1 limit is disabled at power up. The previous uapi assumed
that the PL1 limit is always enabled and therefore did not have a notion of
a disabled PL1 limit. This results in erroneous PL1 limit values when the
PL1 limit is disabled. For example at power up, the disabled ATSM PL1 limit
was previously shown as 0 which means a low PL1 limit whereas the limit
being disabled actually implies a high effective PL1 limit value.

To get round this problem, the PL1 limit uapi is expanded to include a
special value 0 to designate a disabled PL1 limit.

Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/8062
Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/8060
Signed-off-by: Ashutosh Dixit 
---
 .../ABI/testing/sysfs-driver-intel-i915-hwmon |  3 ++-
 drivers/gpu/drm/i915/i915_hwmon.c | 24 +++
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon 
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 2d6a472eef885..96fec0bb74c2c 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -14,7 +14,8 @@ Description:  RW. Card reactive sustained  (PL1/Tau) power 
limit in microwatts.
 
The power controller will throttle the operating frequency
if the power averaged over a window (typically seconds)
-   exceeds this limit.
+   exceeds this limit. A read value of 0 means that the PL1 power
+   limit is disabled. Writing 0 disables the limit if possible.
 
Only supported for particular Intel i915 graphics platforms.
 
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c 
b/drivers/gpu/drm/i915/i915_hwmon.c
index 596dd2c070106..c099057888914 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -349,6 +349,8 @@ hwm_power_is_visible(const struct hwm_drvdata *ddat, u32 
attr, int chan)
}
 }
 
+#define PL1_DISABLE 0
+
 /*
  * HW allows arbitrary PL1 limits to be set but silently clamps these values to
  * "typical but not guaranteed" min/max values in rg.pkg_power_sku. Follow the
@@ -362,6 +364,14 @@ hwm_power_max_read(struct hwm_drvdata *ddat, long *val)
intel_wakeref_t wakeref;
u64 r, min, max;
 
+   /* Check if PL1 limit is disabled */
+   with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+   r = intel_uncore_read(ddat->uncore, hwmon->rg.pkg_rapl_limit);
+   if (!(r & PKG_PWR_LIM_1_EN)) {
+   *val = PL1_DISABLE;
+   return 0;
+   }
+
*val = hwm_field_read_and_scale(ddat,
hwmon->rg.pkg_rapl_limit,
PKG_PWR_LIM_1,
@@ -385,8 +395,22 @@ static int
 hwm_power_max_write(struct hwm_drvdata *ddat, long val)
 {
struct i915_hwmon *hwmon = ddat->hwmon;
+   intel_wakeref_t wakeref;
u32 nval;
 
+   if (val == PL1_DISABLE) {
+   /* Disable PL1 limit */
+   hwm_locked_with_pm_intel_uncore_rmw(ddat, 
hwmon->rg.pkg_rapl_limit,
+   PKG_PWR_LIM_1_EN, 0);
+
+   /* Verify, because PL1 limit cannot be disabled on all 
platforms */
+   with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
+   nval = intel_uncore_read(ddat->uncore, 
hwmon->rg.pkg_rapl_limit);
+   if (nval & PKG_PWR_LIM_1_EN)
+   return -EPERM;
+   return 0;
+   }
+
/* Computation in 64-bits to avoid overflow. Round to nearest. */
nval = DIV_ROUND_CLOSEST_ULL((u64)val << hwmon->scl_shift_power, 
SF_POWER);
nval = PKG_PWR_LIM_1_EN | REG_FIELD_PREP(PKG_PWR_LIM_1, nval);
-- 
2.38.0

RE: [PATCH 3/3] drm/xe: Update GuC/HuC firmware autoselect logic

2023-03-28 Thread Srivatsa, Anusha




> -Original Message-
> From: De Marchi, Lucas 
> Sent: Thursday, March 23, 2023 10:18 PM
> To: intel...@lists.freedesktop.org
> Cc: Srivatsa, Anusha ; Harrison, John C
> ; Ceraolo Spurio, Daniele
> ; dri-devel@lists.freedesktop.org; Daniel
> Vetter ; Dave Airlie ; De Marchi,
> Lucas 
> Subject: [PATCH 3/3] drm/xe: Update GuC/HuC firmware autoselect logic
> 
> Update the logic to autoselect GuC/HuC for the platforms with the following
> improvements:
> 
> - Document what is the firmware file that is expected to be
>   loaded and what is checked from blob headers
> - When the platform is under force-probe it's desired to enforce
>   the full-version requirement so the correct firmware is used
>   before widespread adoption and backward-compatibility
>
Extra line ^

>   commitments
> - Directory from which we expect firmware blobs to be available in
>   upstream linux-firmware repository depends on the platform: for
>   the ones supported by i915 it uses the i915/ directory, but the ones
>   expected to be supported by xe, it's on the xe/ directory. This
>   means that for platforms in the intersection, the firmware is
>   loaded from a different directory, but that is not much important
>   in the firmware repo and it avoids firmware duplication.
> 
> - Make the table with the firmware definitions clearly state the
>   versions being expected. Now with macros to select the version it's
>   possible to choose between full-version/major-version for GuC and
>   full-version/no-version for HuC. These are similar to the macros used
>   in i915, but implemented in a slightly different way to avoid
>   duplicating the macros for each firmware/type and functionality,
>   besides adding the support for different directories.
> 
> - There is no check added regarding force-probe since xe should
>   reuse the same firmware files published for i915 for past
>   platforms. This can be improved later with additional
>   kunit checking against a hardcoded list of platforms that
Extra line here.

>   falls in this category.
> - As mentioned in the TODO, the major version fallback was not
>   implemented before as currently each platform only supports one
>   major. That can be easily added later.
> 
> - GuC version for MTL and PVC were updated to 70.6.4, using the exact
>   full version, while the
> 
> After this the GuC firmware used by PVC changes to pvc_guc_70.5.2.bin since 
> it's
> using a file not published yet.
> 
> Signed-off-by: Lucas De Marchi 
> ---
>  drivers/gpu/drm/xe/xe_uc_fw.c   | 315 +---
>  drivers/gpu/drm/xe/xe_uc_fw.h   |   2 +-
>  drivers/gpu/drm/xe/xe_uc_fw_types.h |   7 +
>  3 files changed, 204 insertions(+), 120 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_uc_fw.c b/drivers/gpu/drm/xe/xe_uc_fw.c
> index 174c42873ebb..653bc3584cc5 100644
> --- a/drivers/gpu/drm/xe/xe_uc_fw.c
> +++ b/drivers/gpu/drm/xe/xe_uc_fw.c
> @@ -17,6 +17,137 @@
>  #include "xe_mmio.h"
>  #include "xe_uc_fw.h"
> 
> +/*
> + * List of required GuC and HuC binaries per-platform. They must be
> +ordered
> + * based on platform, from newer to older.
> + *
> + * Versioning follows the guidelines from
> + * Documentation/driver-api/firmware/firmware-usage-guidelines.rst.
> +There is a
> + * distinction for platforms being officially supported by the driver or not.
> + * Platforms not available publicly or not yet officially supported by
> +the
> + * driver (under force-probe), use the mmp_ver(): the firmware
> +autoselect logic
> + * will select the firmware from disk with filename that matches the
> +full
> + * "mpp version", i.e. major.minor.patch. mmp_ver() should only be used
> +for
> + * this case.
> + *
> + * For platforms officially supported by the driver, the filename
> +always only
> + * ever contains the major version (GuC) or no version at all (HuC).
> + *
> + * After loading the file, the driver parses the versions embedded in the 
> blob.
> + * The major version needs to match a major version supported by the
> +driver (if
> + * any). The minor version is also checked and a notice emitted to the
> +log if
> + * the version found is smaller than the version wanted. This is done
> +only for
> + * informational purposes so users may have a chance to upgrade, but
> +the driver
> + * still loads and use the older firmware.
> + *
> + * Examples:
> + *
> + *   1) Platform officially supported by i915 - using Tigerlake as example.
> + *  Driver loads the following firmware blobs from disk:
> + *
> + *   - i915/tgl_guc_.bin
> + *   - i915/tgl_huc.bin
> + *
> + *   number for GuC is checked that it matches the version inside
> + *  the blob.  version is checked and if smaller than the expected
> + *  an info message is emitted about that.
> + *
> + *   1) XE_, still under require_force_probe.
> Using
> + *  "wipplat" as a short-name. Driver loads the following firmware blobs
> + *  from disk:
> + *
> + *   - xe/wipplat_guc_...bin
> + *

Re: [PATCH] drm/msm/a6xx: add CONFIG_PM dependency

2023-03-28 Thread Randy Dunlap




On 3/24/23 02:54, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> Selecting CONFIG_PM_GENERIC_DOMAINS causes a build failure when CONFIG_PM
> is not enabled:
> 
> WARNING: unmet direct dependencies detected for PM_GENERIC_DOMAINS
>   Depends on [n]: PM [=n]
>   Selected by [m]:
>   - DRM_MSM [=m] && HAS_IOMEM [=y] && DRM [=m] && (ARCH_QCOM [=y] || SOC_IMX5 
> || COMPILE_TEST [=y]) && COMMON_CLK [=y] && IOMMU_SUPPORT [=y] && (QCOM_OCMEM 
> [=y] || QCOM_OCMEM [=y]=n) && (QCOM_LLCC [=n] || QCOM_LLCC [=n]=n) && 
> (QCOM_COMMAND_DB [=y] || QCOM_COMMAND_DB [=y]=n) && 
> DEVFREQ_GOV_SIMPLE_ONDEMAND [=y]
> 
> drivers/base/power/domain.c:654:13: error: use of undeclared identifier 
> 'pm_wq'
> queue_work(pm_wq, &genpd->power_off_work);
>^
> drivers/base/power/domain.c:853:26: error: no member named 'ignore_children' 
> in 'struct dev_pm_info'
> if (!dev || dev->power.ignore_children)
> ~~ ^
> 
> Fixes: c11fa1204fe9 ("drm/msm/a6xx: Use genpd notifier to ensure cx-gdsc 
> collapse")
> Signed-off-by: Arnd Bergmann 


Tested-by: Randy Dunlap 
Acked-by: Randy Dunlap 

Thanks.

> ---
>  drivers/gpu/drm/msm/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
> index 1c417ba53b5b..85f5ab1d552c 100644
> --- a/drivers/gpu/drm/msm/Kconfig
> +++ b/drivers/gpu/drm/msm/Kconfig
> @@ -9,6 +9,7 @@ config DRM_MSM
>   depends on QCOM_OCMEM || QCOM_OCMEM=n
>   depends on QCOM_LLCC || QCOM_LLCC=n
>   depends on QCOM_COMMAND_DB || QCOM_COMMAND_DB=n
> + depends on PM
>   select IOMMU_IO_PGTABLE
>   select QCOM_MDT_LOADER if ARCH_QCOM
>   select REGULATOR

-- 
~Randy

linux-next: manual merge of the drm-msm tree with the drm-misc tree

2023-03-28 Thread Stephen Rothwell

Hi all,

Today's linux-next merge of the drm-msm tree got a conflict in:

  drivers/gpu/drm/msm/adreno/adreno_gpu.c

between commit:

  7fa5047a436b ("drm: Use of_property_present() for testing DT property 
presence")

from the drm-misc tree and commit:

  9f251f934012 ("drm/msm/adreno: Use OPP for every GPU generation")

from the drm-msm tree.

I fixed it up (the latter removed the code updated by the former, so I
just did that) and can carry the fix as necessary. This is now fixed as
far as linux-next is concerned, but any non trivial conflicts should be
mentioned to your upstream maintainer when your tree is submitted for
merging.  You may also want to consider cooperating with the maintainer
of the conflicting tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgp07K5_dNlq5.pgp
Description: OpenPGP digital signature

Re: [pull] drm: dma-fence-deadline-core for v6.4

On Tue, Mar 28, 2023 at 10:19 AM Daniel Vetter  wrote:
>
> On Sat, Mar 25, 2023 at 11:24:56AM -0700, Rob Clark wrote:
> > Hi Dave and Daniel,
> >
> > Here is the series for dma-fence deadline hint, without driver
> > specific patches, with the intent that it can be merged into drm-next
> > as well as -driver next trees to enable landing driver specific
> > support through their corresponding -next trees.
> >
> > The following changes since commit eeac8ede17557680855031c6f305ece2378af326:
> >
> >   Linux 6.3-rc2 (2023-03-12 16:36:44 -0700)
> >
> > are available in the Git repository at:
> >
> >   https://gitlab.freedesktop.org/drm/msm.git tags/dma-fence-deadline-core
> >
> > for you to fetch changes up to 0bcc8f52a8d9d1f9cd5af7f88c6599a89e64284a:
> >
> >   drm/atomic-helper: Set fence deadline for vblank (2023-03-25 10:55:08 
> > -0700)
>
> Ok apparently there's only igts for the sync_file uabi and the only only
> userspace for syncobj is the mesa mr that is still under discussion :-/
>
> Yes I know there's a clearly established need for something like this, but
> also in drm we don't merge conjectured uabi. Especially with tricky stuff
> that's meant to improve best effort performance/tuning problems, where you
> really have to benchmark the entire thing and make sure you didn't screw
> up some interaction.
>
> To make sure this isn't stuck another full cycle, is there a way to wittle
> this just down to the kms atomic flip boosting parts? That way we could at
> least start landing the core&driver bits ...

I went ahead and sent a PR without the uapi bits.. IMHO I don't think
that any further discussion on the MR would change the uapi, but I
guess it doesn't hurt giving it some extra days while unblocking the
driver parts.  I still kinda hope that we can land at least the
syncobj UAPI this cycle.

BR,
-R

> -Daniel
>
> >
> > 
> > Immutable branch with dma-fence deadline hint support between drm-next
> > and driver -next trees.
> >
> > 
> > Rob Clark (11):
> >   dma-buf/dma-fence: Add deadline awareness
> >   dma-buf/fence-array: Add fence deadline support
> >   dma-buf/fence-chain: Add fence deadline support
> >   dma-buf/dma-resv: Add a way to set fence deadline
> >   dma-buf/sync_file: Surface sync-file uABI
> >   dma-buf/sync_file: Add SET_DEADLINE ioctl
> >   dma-buf/sw_sync: Add fence deadline support
> >   drm/scheduler: Add fence deadline support
> >   drm/syncobj: Add deadline support for syncobj waits
> >   drm/vblank: Add helper to get next vblank time
> >   drm/atomic-helper: Set fence deadline for vblank
> >
> >  Documentation/driver-api/dma-buf.rst| 16 ++-
> >  drivers/dma-buf/dma-fence-array.c   | 11 +
> >  drivers/dma-buf/dma-fence-chain.c   | 12 +
> >  drivers/dma-buf/dma-fence.c | 60 
> >  drivers/dma-buf/dma-resv.c  | 22 +
> >  drivers/dma-buf/sw_sync.c   | 81 
> > +
> >  drivers/dma-buf/sync_debug.h|  2 +
> >  drivers/dma-buf/sync_file.c | 19 
> >  drivers/gpu/drm/drm_atomic_helper.c | 37 +++
> >  drivers/gpu/drm/drm_syncobj.c   | 64 --
> >  drivers/gpu/drm/drm_vblank.c| 53 +
> >  drivers/gpu/drm/scheduler/sched_fence.c | 46 +++
> >  drivers/gpu/drm/scheduler/sched_main.c  |  2 +-
> >  include/drm/drm_vblank.h|  1 +
> >  include/drm/gpu_scheduler.h | 17 +++
> >  include/linux/dma-fence.h   | 22 +
> >  include/linux/dma-resv.h|  2 +
> >  include/uapi/drm/drm.h  | 17 +++
> >  include/uapi/linux/sync_file.h  | 59 +++-
> >  19 files changed, 496 insertions(+), 47 deletions(-)
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Re: [PATCH] drm/msm: Rename drm_msm_gem_submit_reloc::or in C++ code



On Sun, 26 Mar 2023 09:38:13 -0700, Rob Clark wrote:
> Clashes with C++ `or` keyword
> 
> 

Applied, thanks!

[1/1] drm/msm: Rename drm_msm_gem_submit_reloc::or in C++ code
  https://gitlab.freedesktop.org/lumag/msm/-/commit/be7772e53681

Best regards,
-- 
Dmitry Baryshkov

Re: [PATCH v4 0/4] Move TE setup to prepare_for_kickoff()



On Tue, 21 Feb 2023 10:42:52 -0800, Jessica Zhang wrote:
> Move TE setup to prepare_for_kickoff() and remove empty prepare_commit()
> functions in both MDP4 and DPU drivers.
> 
> Changes in V2:
> - Added changes to remove empty prepare_commit() functions
> 
> Changes in V3:
> - Reordered "drm/msm/dpu: Move TE setup to prepare_for_kickoff()" for
>   clarity
> - Fixed spelling mistakes and wording issues
> - Picked up "Reviewed-by" tags for patches [2/4] and [4/4]
> 
> [...]

Applied, thanks!

[1/4] drm/msm/dpu: Move TE setup to prepare_for_kickoff()
  https://gitlab.freedesktop.org/lumag/msm/-/commit/dd7904e0f824
[2/4] drm/msm: Check for NULL before calling prepare_commit()
  https://gitlab.freedesktop.org/lumag/msm/-/commit/63c3df12d13a
[3/4] drm/msm/dpu: Remove empty prepare_commit() function
  https://gitlab.freedesktop.org/lumag/msm/-/commit/f4d83f101233
[4/4] drm/msm/mdp4: Remove empty prepare_commit() function
  https://gitlab.freedesktop.org/lumag/msm/-/commit/191604898585

Best regards,
-- 
Dmitry Baryshkov

Re: [PATCH] drm/msm: Avoid rounding down to zero jiffies



On Fri, 24 Mar 2023 15:00:13 -0700, Rob Clark wrote:
> If userspace asked for a timeout greater than zero, but less than a
> jiffy, they clearly weren't planning on spinning.  So it is better
> to round up to one.
> 
> This fixes an issue with supertuxkart that was (for some reason)
> spinning on a gl sync with 1ms timeout.  CPU time for a demo lap
> drops from:
> 
> [...]

Applied, thanks!

[1/1] drm/msm: Avoid rounding down to zero jiffies
  https://gitlab.freedesktop.org/lumag/msm/-/commit/a5c5593477b0

Best regards,
-- 
Dmitry Baryshkov

Re: [RFC PATCH v3 0/4] Move TE setup to prepare_for_kickoff()



On Mon, 13 Feb 2023 11:48:15 -0800, Jessica Zhang wrote:
> Move TE setup to prepare_for_kickoff() and remove empty prepare_commit()
> functions in both MDP4 and DPU drivers.
> 
> Changes in V2:
> - Added changes to remove empty prepare_commit() functions
> 
> Changes in V3:
> - Reordered "drm/msm/dpu: Move TE setup to prepare_for_kickoff()" for
>   clarity
> - Fixed spelling mistakes and wording issues
> - Picked up "Reviewed-by" tags for patches [2/4] and [4/4]
> 
> [...]

Applied, thanks!

[1/4] drm/msm/dpu: Move TE setup to prepare_for_kickoff()
  https://gitlab.freedesktop.org/lumag/msm/-/commit/dd7904e0f824
[2/4] drm/msm: Check for NULL before calling prepare_commit()
  https://gitlab.freedesktop.org/lumag/msm/-/commit/63c3df12d13a
[3/4] drm/msm/dpu: Remove empty prepare_commit() function
  https://gitlab.freedesktop.org/lumag/msm/-/commit/f4d83f101233
[4/4] drm/msm/mdp4: Remove empty prepare_commit() function
  https://gitlab.freedesktop.org/lumag/msm/-/commit/191604898585

Best regards,
-- 
Dmitry Baryshkov

Re: [PATCH v3 0/7] drm/msm: add support for SM8550



On Mon, 09 Jan 2023 11:15:17 +0100, Neil Armstrong wrote:
> This adds support for the MDSS/DPU/DSI on the Qualcomm SM8550 platform.
> 
> This patchset is based on the SM8450 display support serie at [1].
> 
> In order to work, the following patchsets are required:
> - PM8550 LDO fix at [2]
> - DISPCC driver at [3]
> 
> [...]

Applied, thanks!

[2/7] dt-bindings: display/msm: document DPU on SM8550
  https://gitlab.freedesktop.org/lumag/msm/-/commit/4557e40338d2
[3/7] dt-bindings: display/msm: document MDSS on SM8550
  https://gitlab.freedesktop.org/lumag/msm/-/commit/0e4205eb8663

Best regards,
-- 
Dmitry Baryshkov

Re: [PATCH] drm/msm/dpu: Fix bit-shifting UB in DPU_HW_VER() macro



On Mon, 06 Mar 2023 10:06:33 +0100, Geert Uytterhoeven wrote:
> With gcc-5 and CONFIG_UBSAN_SHIFT=y:
> 
> drivers/gpu/drm/msm/msm_mdss.c: In function 'msm_mdss_enable':
> drivers/gpu/drm/msm/msm_mdss.c:296:2: error: case label does not reduce 
> to an integer constant
>   case DPU_HW_VER_800:
>   ^
> drivers/gpu/drm/msm/msm_mdss.c:299:2: error: case label does not reduce 
> to an integer constant
>   case DPU_HW_VER_810:
>   ^
> drivers/gpu/drm/msm/msm_mdss.c:300:2: error: case label does not reduce 
> to an integer constant
>   case DPU_HW_VER_900:
>   ^
> 
> [...]

Applied, thanks!

[1/1] drm/msm/dpu: Fix bit-shifting UB in DPU_HW_VER() macro
  https://gitlab.freedesktop.org/lumag/msm/-/commit/c8f370bde5b9

Best regards,
-- 
Dmitry Baryshkov

Re: [PATCH v2 0/4] arm64: qcom: sm8450: bindings check cleanup



On Fri, 24 Mar 2023 10:28:45 +0100, Neil Armstrong wrote:
> A few fixes to pass the DT bindings check successfully
> for sm8450 qrd & hdk DTs.
> 
> The following are still needed to pass all the checks:
> - 
> https://lore.kernel.org/r/20230308082424.140224-3-manivannan.sadhasi...@linaro.org
> - 
> https://lore.kernel.org/r/20230130-topic-sm8450-upstream-pmic-glink-v5-5-552f3b721...@linaro.org
> - 
> https://lore.kernel.org/all/20230308075648.134119-1-manivannan.sadhasi...@linaro.org/
> - 
> https://lore.kernel.org/r/20230306112129.3687744-1-dmitry.barysh...@linaro.org
> - 
> https://lore.kernel.org/all/20221209-dt-binding-ufs-v3-0-499dff23a...@fairphone.com/
> - 
> https://lore.kernel.org/all/20221118071849.25506-2-srinivas.kandaga...@linaro.org/
> 
> [...]

Applied, thanks!

[1/4] dt-bindings: display: msm: sm8450-mdss: Fix DSI compatible
  https://gitlab.freedesktop.org/lumag/msm/-/commit/6ae1aa7703f8

Best regards,
-- 
Dmitry Baryshkov

Re: [PATCH 1/2] drm/lima: Use drm_sched_job_add_syncobj_dependency()



On Fri, 24 Feb 2023 18:41:32 -0300, Maíra Canal wrote:
> As lima_gem_add_deps() performs the same steps as
> drm_sched_job_add_syncobj_dependency(), replace the open-coded
> implementation in Lima in order to simply use the DRM function.
> 
> 

Applied, thanks!

[2/2] drm/msm: Use drm_sched_job_add_syncobj_dependency()
  https://gitlab.freedesktop.org/lumag/msm/-/commit/8fd531e6bc56

Best regards,
-- 
Dmitry Baryshkov

Re: [PATCH v6 0/9] Fix DSI host idx detection on HW revision clash



On Sat, 18 Mar 2023 14:42:46 +0100, Konrad Dybcio wrote:
> v5 -> v6:
> - Squash both fixes that concerned the deprecated QCM2290 compatible to
>   avoid warnings
> 
> v5: 
> https://lore.kernel.org/r/20230307-topic-dsi_qcm-v5-0-9d4235b77...@linaro.org
> 
> v4 -> v5:
> - Drop superfluous items: level in [8/10]
> - Remove the header define for the qcm2290 config in [6/10] instead of
>   [7/10]
> - Pick up tags
> 
> [...]

Applied, thanks!

[1/9] dt-bindings: display/msm: dsi-controller-main: Fix deprecated QCM2290 
compatible
  https://gitlab.freedesktop.org/lumag/msm/-/commit/236502012d47
[2/9] drm/msm/dsi: Get rid of msm_dsi_config::num_dsi
  https://gitlab.freedesktop.org/lumag/msm/-/commit/607ce0e9d462
[3/9] drm/msm/dsi: Fix DSI index detection when version clash occurs
  https://gitlab.freedesktop.org/lumag/msm/-/commit/2e6105fe7570
[4/9] drm/msm/dsi: dsi_cfg: Deduplicate identical structs
  https://gitlab.freedesktop.org/lumag/msm/-/commit/41301c6d5e5d
[5/9] drm/msm/dsi: dsi_cfg: Merge SC7180 config into SDM845
  https://gitlab.freedesktop.org/lumag/msm/-/commit/38ba402f807d
[6/9] drm/msm/dsi: Switch the QCM2290-specific compatible to index autodetection
  https://gitlab.freedesktop.org/lumag/msm/-/commit/34f84fcf81c8
[7/9] drm/msm/dsi: Remove custom DSI config handling
  https://gitlab.freedesktop.org/lumag/msm/-/commit/ff280b6cc5ef
[8/9] dt-bindings: display/msm: dsi-controller-main: Add SM6115
  https://gitlab.freedesktop.org/lumag/msm/-/commit/c7baf742a07b

Best regards,
-- 
Dmitry Baryshkov

Re: [PATCH 00/10] drm/msm: fix bind error handling



On Mon, 06 Mar 2023 11:07:12 +0100, Johan Hovold wrote:
> I had reasons to look closer at the MSM DRM driver error handling and
> realised that it had suffered from a fair amount of bit rot over the
> years.
> 
> Unfortunately, I started fixing this in my 6.2 branch and failed to
> notice two partial and, as it turned out, broken attempts to address
> this that are now in 6.3-rc1.
> 
> [...]

Applied, thanks!

[01/10] Revert "drm/msm: Add missing check and destroy for 
alloc_ordered_workqueue"
https://gitlab.freedesktop.org/lumag/msm/-/commit/ebf761d6a02f
[02/10] Revert "drm/msm: Fix failure paths in msm_drm_init()"
https://gitlab.freedesktop.org/lumag/msm/-/commit/35a08e19a1c6
[03/10] drm/msm: fix NULL-deref on snapshot tear down
https://gitlab.freedesktop.org/lumag/msm/-/commit/d3234fe12b3b
[04/10] drm/msm: fix NULL-deref on irq uninstall
https://gitlab.freedesktop.org/lumag/msm/-/commit/0b5ffe5be6fd
[05/10] drm/msm: fix drm device leak on bind errors
https://gitlab.freedesktop.org/lumag/msm/-/commit/6a44f0dbd141
[06/10] drm/msm: fix vram leak on bind errors
https://gitlab.freedesktop.org/lumag/msm/-/commit/e6091a855649
[07/10] drm/msm: fix missing wq allocation error handling
https://gitlab.freedesktop.org/lumag/msm/-/commit/9c6027d5a3f4
[08/10] drm/msm: fix workqueue leak on bind errors
https://gitlab.freedesktop.org/lumag/msm/-/commit/023691129696
[10/10] drm/msm: move include directive
https://gitlab.freedesktop.org/lumag/msm/-/commit/110fd0d5b032

Best regards,
-- 
Dmitry Baryshkov

Re: [PATCH v6 0/5] arm64: dts: qcom: add DP Controller to SM8350 & SM8450 DTS



On Fri, 17 Mar 2023 16:06:31 +0100, Neil Armstrong wrote:
> Switch the QMP PHY to the newly documented USB3/DP Combo PHY
> bindings at [1] and add the DP controller nodes.
> 
> The DP output is shared with the USB3 SuperSpeed lanes and is
> usually connected to an USB-C port which Altmode is controlled
> by the PMIC Glink infrastructure in discution at [1] & [2].
> 
> [...]

Applied, thanks!

[1/5] dt-bindings: display: msm: dp-controller: document SM8450 compatible
  https://gitlab.freedesktop.org/lumag/msm/-/commit/8554420f1912

Best regards,
-- 
Dmitry Baryshkov

Re: [PATCH v7 00/32] drm/msm/dpu: wide planes support



On Thu, 16 Mar 2023 19:16:21 +0300, Dmitry Baryshkov wrote:
> This patchset brings in multirect usage to support using two SSPP
> rectangles for a single plane. Full virtual planes support is omitted
> from this pull request, it will come later (I'm at the final stages of
> polishing and testing, will be posted today).
> 
> Changes since v6:
> - Really fixed line width check for UBWC formats (Abhinav)
> - Also dropped R0/R1/R_MAX previously used by
>   dpu_plane_validate_multirect_v2()
> - Explicitly enabled SmartDMA for SC7280 following Abhinav's testing
> - Reapplied Abhinav's Tested-by tags with the # sc7280 comment
> 
> [...]

Applied, thanks!

[01/32] drm/msm/dpu: rename struct dpu_hw_pipe(_cfg) to dpu_hw_sspp(_cfg)
https://gitlab.freedesktop.org/lumag/msm/-/commit/995658a1c749
[02/32] drm/msm/dpu: move SSPP allocation to the RM
https://gitlab.freedesktop.org/lumag/msm/-/commit/476754a8ac86
[03/32] drm/msm/dpu: move SSPP debugfs creation to dpu_kms.c
https://gitlab.freedesktop.org/lumag/msm/-/commit/ff77cf2eb1a3
[04/32] drm/msm/dpu: drop EAGAIN check from dpu_format_populate_layout
https://gitlab.freedesktop.org/lumag/msm/-/commit/e29bb8dfd072
[05/32] drm/msm/dpu: move pipe_hw to dpu_plane_state
https://gitlab.freedesktop.org/lumag/msm/-/commit/6d8635715af1
[06/32] drm/msm/dpu: drop dpu_plane_pipe function
https://gitlab.freedesktop.org/lumag/msm/-/commit/a2d023b21887
[07/32] drm/msm/dpu: introduce struct dpu_sw_pipe
https://gitlab.freedesktop.org/lumag/msm/-/commit/f2f524de417a
[08/32] drm/msm/dpu: use dpu_sw_pipe for dpu_hw_sspp callbacks
https://gitlab.freedesktop.org/lumag/msm/-/commit/0e2e459260e3
[09/32] drm/msm/dpu: pass dpu_format to _dpu_hw_sspp_setup_scaler3()
https://gitlab.freedesktop.org/lumag/msm/-/commit/ad03f6653014
[10/32] drm/msm/dpu: clean up SRC addresses when setting up SSPP for solid fill
https://gitlab.freedesktop.org/lumag/msm/-/commit/49f06532da0c
[11/32] drm/msm/dpu: move stride programming to dpu_hw_sspp_setup_sourceaddress
https://gitlab.freedesktop.org/lumag/msm/-/commit/8148109600eb
[12/32] drm/msm/dpu: remove dpu_hw_fmt_layout from struct dpu_hw_sspp_cfg
https://gitlab.freedesktop.org/lumag/msm/-/commit/3a0421182198
[13/32] drm/msm/dpu: rename dpu_hw_sspp_cfg to dpu_sw_pipe_cfg
https://gitlab.freedesktop.org/lumag/msm/-/commit/6f32a14dcaa6
[14/32] drm/msm/dpu: drop src_split and multirect check from 
dpu_crtc_atomic_check
https://gitlab.freedesktop.org/lumag/msm/-/commit/ec72f615f49b
[15/32] drm/msm/dpu: don't use unsupported blend stages
https://gitlab.freedesktop.org/lumag/msm/-/commit/6a67280b594e
[16/32] drm/msm/dpu: move the rest of plane checks to dpu_plane_atomic_check()
https://gitlab.freedesktop.org/lumag/msm/-/commit/274a82886182
[17/32] drm/msm/dpu: drop redundant plane dst check from dpu_crtc_atomic_check()
https://gitlab.freedesktop.org/lumag/msm/-/commit/36ca301a498e
[18/32] drm/msm/dpu: rewrite plane's QoS-related functions to take dpu_sw_pipe 
and dpu_format
https://gitlab.freedesktop.org/lumag/msm/-/commit/9a6b14e3c2d8
[19/32] drm/msm/dpu: make _dpu_plane_calc_clk accept mode directly
https://gitlab.freedesktop.org/lumag/msm/-/commit/ddb9302ca7be
[20/32] drm/msm/dpu: add dpu_hw_sspp_cfg to dpu_plane_state
https://gitlab.freedesktop.org/lumag/msm/-/commit/949859a56a29
[21/32] drm/msm/dpu: simplify dpu_plane_validate_src()
https://gitlab.freedesktop.org/lumag/msm/-/commit/d92254e80244
[22/32] drm/msm/dpu: rework dpu_plane_sspp_atomic_update()
https://gitlab.freedesktop.org/lumag/msm/-/commit/4a59602f7c6f
[23/32] drm/msm/dpu: rework dpu_plane_atomic_check()
https://gitlab.freedesktop.org/lumag/msm/-/commit/5aa11fa2f523
[24/32] drm/msm/dpu: rework plane CSC setting
https://gitlab.freedesktop.org/lumag/msm/-/commit/0ef79e954d75
[25/32] drm/msm/dpu: rework static color fill code
https://gitlab.freedesktop.org/lumag/msm/-/commit/43a636a55622
[26/32] drm/msm/dpu: split pipe handling from _dpu_crtc_blend_setup_mixer
https://gitlab.freedesktop.org/lumag/msm/-/commit/9081cb73a25d
[28/32] drm/msm/dpu: populate SmartDMA features in hw catalog
https://gitlab.freedesktop.org/lumag/msm/-/commit/b9d4f598cb69
[30/32] drm/msm/dpu: drop smart_dma_rev from dpu_caps
https://gitlab.freedesktop.org/lumag/msm/-/commit/a4188f96d0a0
[31/32] drm/msm/dpu: log the multirect_index in _dpu_crtc_blend_setup_pipe
https://gitlab.freedesktop.org/lumag/msm/-/commit/a0d1028e968c
[32/32] drm/msm/dpu: remove unused dpu_plane_validate_multirect_v2 function
https://gitlab.freedesktop.org/lumag/msm/-/commit/0a48a0014533

Best regards,
-- 
Dmitry Baryshkov

Re: [v12] drm/msm/disp/dpu1: add support for dspp sub block flush in sc7280



On Fri, 27 Jan 2023 02:14:47 -0800, Kalyan Thota wrote:
> Flush mechanism for DSPP blocks has changed in sc7280 family, it
> allows individual sub blocks to be flushed in coordination with
> master flush control.
> 
> Representation: master_flush && (PCC_flush | IGC_flush .. etc )
> 
> This change adds necessary support for the above design.
> 
> [...]

Applied, thanks!

[1/1] drm/msm/disp/dpu1: add support for dspp sub block flush in sc7280
  https://gitlab.freedesktop.org/lumag/msm/-/commit/4d5e5f04e596

Best regards,
-- 
Dmitry Baryshkov

Re: [PATCH v2 0/3] drm/msm/mdss: rework UBWC setup



On Wed, 18 Jan 2023 03:04:25 +0200, Dmitry Baryshkov wrote:
> The commit 92bab9142456 ("drm/msm: less magic numbers in
> msm_mdss_enable") reworked the static UBWC setup to replace magic
> numbers with calulating written values from the SoC/device parameters.
> This simplified adding new platforms.
> However I did not estimate that the values would still be cryptic and
> would be C&P-sted instead of being determined from the vendor DT. Some
> of the platform (sc8180x) completely missed this setup step.
> 
> [...]

Applied, thanks!

[1/3] drm/msm/mdss: convert UBWC setup to use match data
  https://gitlab.freedesktop.org/lumag/msm/-/commit/f4abcfab7667
[2/3] drm/msm/mdss: add data for sc8180xp
  https://gitlab.freedesktop.org/lumag/msm/-/commit/2c3415835aaf
[3/3] drm/msm/mdss: add the sdm845 data for completeness
  https://gitlab.freedesktop.org/lumag/msm/-/commit/4b411abf95f9

Best regards,
-- 
Dmitry Baryshkov

Re: [PATCH v2 1/2] drm/msm/dp: Clean up handling of DP AUX interrupts



On Thu, 26 Jan 2023 17:09:12 -0800, Douglas Anderson wrote:
> The DP AUX interrupt handling was a bit of a mess.
> * There were two functions (one for "native" transfers and one for
>   "i2c" transfers) that were quite similar. It was hard to say how
>   many of the differences between the two functions were on purpose
>   and how many of them were just an accident of how they were coded.
> * Each function sometimes used "else if" to test for error bits and
>   sometimes didn't and again it was hard to say if this was on purpose
>   or just an accident.
> * The two functions wouldn't notice whether "unknown" bits were
>   set. For instance, there seems to be a bit "DP_INTR_PLL_UNLOCKED"
>   and if it was set there would be no indication.
> * The two functions wouldn't notice if more than one error was set.
> 
> [...]

Applied, thanks!

[1/2] drm/msm/dp: Clean up handling of DP AUX interrupts
  https://gitlab.freedesktop.org/lumag/msm/-/commit/9dd5895a5687
[2/2] drm/msm/dp: Return IRQ_NONE for unhandled interrupts
  https://gitlab.freedesktop.org/lumag/msm/-/commit/f185c87fa119

Best regards,
-- 
Dmitry Baryshkov

Re: [PATCH][next] drm/msm/dp: Fix spelling mistake "Capabiity" -> "Capability"



On Tue, 14 Mar 2023 08:20:50 +, Colin Ian King wrote:
> There is a spelling mistake in a drm_dbg_dp message. Fix it.
> 
> 

Applied, thanks!

[1/1] drm/msm/dp: Fix spelling mistake "Capabiity" -> "Capability"
  https://gitlab.freedesktop.org/lumag/msm/-/commit/6ee9666a4f4c

Best regards,
-- 
Dmitry Baryshkov

[pull] drm: dma-fence-deadline for v6.4

Hi Dave and Daniel,

Here is the series for dma-fence deadline hint, without driver
specific patches, or UAPI, with the intent that it can be merged into
drm-next as well as -driver next trees to enable landing driver
specific support through their corresponding -next trees.

The following changes since commit eeac8ede17557680855031c6f305ece2378af326:

  Linux 6.3-rc2 (2023-03-12 16:36:44 -0700)

are available in the Git repository at:

  https://gitlab.freedesktop.org/drm/msm.git tags/dma-fence-deadline

for you to fetch changes up to d39e48ca80c0960b039cb38633957f0040f63e1a:

  drm/atomic-helper: Set fence deadline for vblank (2023-03-28 14:52:59 -0700)


This series adds a deadline hint to fences, so realtime deadlines
such as vblank can be communicated to the fence signaller for power/
frequency management decisions.

This is partially inspired by a trick i915 does, but implemented
via dma-fence for a couple of reasons:

1) To continue to be able to use the atomic helpers
2) To support cases where display and gpu are different drivers

See https://patchwork.freedesktop.org/series/93035/

This does not yet add any UAPI, although this will be needed in
a number of cases:

1) Workloads "ping-ponging" between CPU and GPU, where we don't
   want the GPU freq governor to interpret time stalled waiting
   for GPU as "idle" time
2) Cases where the compositor is waiting for fences to be signaled
   before issuing the atomic ioctl, for example to maintain 60fps
   cursor updates even when the GPU is not able to maintain that
   framerate.


Rob Clark (8):
  dma-buf/dma-fence: Add deadline awareness
  dma-buf/fence-array: Add fence deadline support
  dma-buf/fence-chain: Add fence deadline support
  dma-buf/dma-resv: Add a way to set fence deadline
  dma-buf/sync_file: Surface sync-file uABI
  drm/scheduler: Add fence deadline support
  drm/vblank: Add helper to get next vblank time
  drm/atomic-helper: Set fence deadline for vblank

 Documentation/driver-api/dma-buf.rst| 16 +++--
 drivers/dma-buf/dma-fence-array.c   | 11 ++
 drivers/dma-buf/dma-fence-chain.c   | 12 +++
 drivers/dma-buf/dma-fence.c | 59 +
 drivers/dma-buf/dma-resv.c  | 22 
 drivers/gpu/drm/drm_atomic_helper.c | 37 +
 drivers/gpu/drm/drm_vblank.c| 53 -
 drivers/gpu/drm/scheduler/sched_fence.c | 46 +
 drivers/gpu/drm/scheduler/sched_main.c  |  2 +-
 include/drm/drm_vblank.h|  1 +
 include/drm/gpu_scheduler.h | 17 ++
 include/linux/dma-fence.h   | 22 
 include/linux/dma-resv.h|  2 ++
 include/uapi/linux/sync_file.h  | 37 +
 14 files changed, 303 insertions(+), 34 deletions(-)

Re: [PATCH 6.2 regression fix] drm/nouveau/kms: Fix backlight registration

2023-03-28 Thread Lyude Paul

Reviewed-by: Lyude Paul 

(Also note to Mark: this is my way of letting you know someone fixed the
regression with backlight controls upstream, looking into the weird bright
screen after resume issue)

On Sun, 2023-03-26 at 22:54 +0200, Hans de Goede wrote:
> The nouveau code used to call drm_fb_helper_initial_config() from
> nouveau_fbcon_init() before calling drm_dev_register(). This would
> probe all connectors so that drm_connector->status could be used during
> backlight registration which runs from nouveau_connector_late_register().
> 
> After commit 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
> the fbdev emulation code, which now is a drm-client, can only run after
> drm_dev_register(). So during backlight registration the connectors are
> not probed yet and the drm_connector->status == connected check in
> nv50_backlight_init() would now always fail.
> 
> Replace the drm_connector->status == connected check with
> a drm_helper_probe_detect() == connected check to fix nv_backlight
> no longer getting registered because of this.
> 
> Fixes: 4a16dd9d18a0 ("drm/nouveau/kms: switch to drm fbdev helpers")
> Link: https://gitlab.freedesktop.org/drm/nouveau/-/issues/202
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/nouveau/nouveau_backlight.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index 40409a29f5b6..91b5ecc57538 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -33,6 +33,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "nouveau_drv.h"
>  #include "nouveau_reg.h"
> @@ -299,8 +300,12 @@ nv50_backlight_init(struct nouveau_backlight *bl,
>   struct nouveau_drm *drm = nouveau_drm(nv_encoder->base.base.dev);
>   struct nvif_object *device = &drm->client.device.object;
>  
> + /*
> +  * Note when this runs the connectors have not been probed yet,
> +  * so nv_conn->base.status is not set yet.
> +  */
>   if (!nvif_rd32(device, NV50_PDISP_SOR_PWM_CTL(ffs(nv_encoder->dcb->or) 
> - 1)) ||
> - nv_conn->base.status != connector_status_connected)
> + drm_helper_probe_detect(&nv_conn->base, NULL, false) != 
> connector_status_connected)
>   return -ENODEV;
>  
>   if (nv_conn->type == DCB_CONNECTOR_eDP) {

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

[PATCH 2/2] drm/amd/display: Add previous prototype to 'optc3_wait_drr_doublebuffer_pending_clear'

2023-03-28 Thread Caio Novais

Compiling AMD GPU drivers displays a warning:

drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_optc.c:294:6: warning: no 
previous prototype for ‘optc3_wait_drr_doublebuffer_pending_clear’ 
[-Wmissing-prototypes]

Get rid of it by adding a function prototype

'optc3_wait_drr_doublebuffer_pending_clear(struct timing_generator *optc)' on 
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h

Signed-off-by: Caio Novais 
---
 drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h 
b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h
index fb06dc9a4893..2e3ba6e2f336 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h
+++ b/drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h
@@ -331,6 +331,8 @@ void optc3_lock_doublebuffer_enable(struct timing_generator 
*optc);
 
 void optc3_lock_doublebuffer_disable(struct timing_generator *optc);
 
+void optc3_wait_drr_doublebuffer_pending_clear(struct timing_generator *optc);
+
 void optc3_set_drr_trigger_window(struct timing_generator *optc,
uint32_t window_start, uint32_t window_end);
 
-- 
2.40.0

[PATCH 1/2] drm/amd/display: Remove unused variable 'scl_enable'

2023-03-28 Thread Caio Novais

Compiling AMD GPU drivers displays a warning:

drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_rq_dlg_calc_314.c: 
In function ‘dml_rq_dlg_get_dlg_params’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/display_rq_dlg_calc_314.c:991:14:
 warning: variable ‘scl_enable’ set but not used [-Wunused-but-set-variable]

Get rid of it by removing the variable 'scl_enable'.

Signed-off-by: Caio Novais 
---
 .../gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c | 2 --
 1 file changed, 2 deletions(-)

diff --git 
a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c 
b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c
index d1c2693a2e28..ea4eb66066c4 100644
--- a/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c
+++ b/drivers/gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c
@@ -988,7 +988,6 @@ static void dml_rq_dlg_get_dlg_params(
double hratio_c;
double vratio_l;
double vratio_c;
-   bool scl_enable;
 
unsigned int swath_width_ub_l;
unsigned int dpte_groups_per_row_ub_l;
@@ -1117,7 +1116,6 @@ static void dml_rq_dlg_get_dlg_params(
hratio_c = scl->hscl_ratio_c;
vratio_l = scl->vscl_ratio;
vratio_c = scl->vscl_ratio_c;
-   scl_enable = scl->scl_enable;
 
swath_width_ub_l = rq_dlg_param->rq_l.swath_width_ub;
dpte_groups_per_row_ub_l = rq_dlg_param->rq_l.dpte_groups_per_row_ub;
-- 
2.40.0

[PATCH 0/2] drm/amd/display: Remove a unused variable and add a function prototype

2023-03-28 Thread Caio Novais

This patchset removes one unused variable and adds a function prototype.

Caio Novais (2):
  drm/amd/display: Remove unused variable 'scl_enable'
  drm/amd/display: Add previous prototype to
'optc3_wait_drr_doublebuffer_pending_clear'

 drivers/gpu/drm/amd/display/dc/dcn30/dcn30_optc.h   | 2 ++
 .../gpu/drm/amd/display/dc/dml/dcn314/display_rq_dlg_calc_314.c | 2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
2.40.0

Re: [pull] drm: dma-fence-deadline-core for v6.4

On Tue, Mar 28, 2023 at 10:19 AM Daniel Vetter  wrote:
>
> On Sat, Mar 25, 2023 at 11:24:56AM -0700, Rob Clark wrote:
> > Hi Dave and Daniel,
> >
> > Here is the series for dma-fence deadline hint, without driver
> > specific patches, with the intent that it can be merged into drm-next
> > as well as -driver next trees to enable landing driver specific
> > support through their corresponding -next trees.
> >
> > The following changes since commit eeac8ede17557680855031c6f305ece2378af326:
> >
> >   Linux 6.3-rc2 (2023-03-12 16:36:44 -0700)
> >
> > are available in the Git repository at:
> >
> >   https://gitlab.freedesktop.org/drm/msm.git tags/dma-fence-deadline-core
> >
> > for you to fetch changes up to 0bcc8f52a8d9d1f9cd5af7f88c6599a89e64284a:
> >
> >   drm/atomic-helper: Set fence deadline for vblank (2023-03-25 10:55:08 
> > -0700)
>
> Ok apparently there's only igts for the sync_file uabi and the only only
> userspace for syncobj is the mesa mr that is still under discussion :-/
>
> Yes I know there's a clearly established need for something like this, but
> also in drm we don't merge conjectured uabi. Especially with tricky stuff
> that's meant to improve best effort performance/tuning problems, where you
> really have to benchmark the entire thing and make sure you didn't screw
> up some interaction.
>
> To make sure this isn't stuck another full cycle, is there a way to wittle
> this just down to the kms atomic flip boosting parts? That way we could at
> least start landing the core&driver bits ...

I can drop the sync_file part for now.  I'm not sure that there is
really any discussion on the mesa MR which would change the kernel or
uapi side of this, but I can re-order things so the syncobj patch is
last in case you want to pull HEAD~1 and hold off for a few days on
the syncobj patch

BR,
-R


> -Daniel
>
> >
> > 
> > Immutable branch with dma-fence deadline hint support between drm-next
> > and driver -next trees.
> >
> > 
> > Rob Clark (11):
> >   dma-buf/dma-fence: Add deadline awareness
> >   dma-buf/fence-array: Add fence deadline support
> >   dma-buf/fence-chain: Add fence deadline support
> >   dma-buf/dma-resv: Add a way to set fence deadline
> >   dma-buf/sync_file: Surface sync-file uABI
> >   dma-buf/sync_file: Add SET_DEADLINE ioctl
> >   dma-buf/sw_sync: Add fence deadline support
> >   drm/scheduler: Add fence deadline support
> >   drm/syncobj: Add deadline support for syncobj waits
> >   drm/vblank: Add helper to get next vblank time
> >   drm/atomic-helper: Set fence deadline for vblank
> >
> >  Documentation/driver-api/dma-buf.rst| 16 ++-
> >  drivers/dma-buf/dma-fence-array.c   | 11 +
> >  drivers/dma-buf/dma-fence-chain.c   | 12 +
> >  drivers/dma-buf/dma-fence.c | 60 
> >  drivers/dma-buf/dma-resv.c  | 22 +
> >  drivers/dma-buf/sw_sync.c   | 81 
> > +
> >  drivers/dma-buf/sync_debug.h|  2 +
> >  drivers/dma-buf/sync_file.c | 19 
> >  drivers/gpu/drm/drm_atomic_helper.c | 37 +++
> >  drivers/gpu/drm/drm_syncobj.c   | 64 --
> >  drivers/gpu/drm/drm_vblank.c| 53 +
> >  drivers/gpu/drm/scheduler/sched_fence.c | 46 +++
> >  drivers/gpu/drm/scheduler/sched_main.c  |  2 +-
> >  include/drm/drm_vblank.h|  1 +
> >  include/drm/gpu_scheduler.h | 17 +++
> >  include/linux/dma-fence.h   | 22 +
> >  include/linux/dma-resv.h|  2 +
> >  include/uapi/drm/drm.h  | 17 +++
> >  include/uapi/linux/sync_file.h  | 59 +++-
> >  19 files changed, 496 insertions(+), 47 deletions(-)
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH 1/1] drm/i915: fix race condition UAF in i915_perf_add_config_ioctl

2023-03-28 Thread Andi Shyti

On Tue, Mar 28, 2023 at 05:36:27PM +0800, Min Li wrote:
> Userspace can guess the id value and try to race oa_config object creation
> with config remove, resulting in a use-after-free if we dereference the
> object after unlocking the metrics_lock.  For that reason, unlocking the
> metrics_lock must be done after we are done dereferencing the object.
> 
> Signed-off-by: Min Li 

I think we should also add

Fixes: f89823c21224 ("drm/i915/perf: Implement I915_PERF_ADD/REMOVE_CONFIG 
interface")
Cc:  # v4.14+

Andi

> ---
>  drivers/gpu/drm/i915/i915_perf.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index 824a34ec0b83..93748ca2c5da 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -4634,13 +4634,13 @@ int i915_perf_add_config_ioctl(struct drm_device 
> *dev, void *data,
>   err = oa_config->id;
>   goto sysfs_err;
>   }
> -
> - mutex_unlock(&perf->metrics_lock);
> + id = oa_config->id;
>  
>   drm_dbg(&perf->i915->drm,
>   "Added config %s id=%i\n", oa_config->uuid, oa_config->id);
> + mutex_unlock(&perf->metrics_lock);
>  
> - return oa_config->id;
> + return id;
>  
>  sysfs_err:
>   mutex_unlock(&perf->metrics_lock);
> -- 
> 2.25.1

Re: [Intel-gfx] [PATCH 1/1] drm/i915: fix race condition UAF in i915_perf_add_config_ioctl

2023-03-28 Thread Andi Shyti

Hi Min,

On Tue, Mar 28, 2023 at 05:36:27PM +0800, Min Li wrote:
> Userspace can guess the id value and try to race oa_config object creation
> with config remove, resulting in a use-after-free if we dereference the
> object after unlocking the metrics_lock.  For that reason, unlocking the
> metrics_lock must be done after we are done dereferencing the object.
> 
> Signed-off-by: Min Li 

Thank you for your patch!

Reviewed-by: Andi Shyti 

Andi

> ---
>  drivers/gpu/drm/i915/i915_perf.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index 824a34ec0b83..93748ca2c5da 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -4634,13 +4634,13 @@ int i915_perf_add_config_ioctl(struct drm_device 
> *dev, void *data,
>   err = oa_config->id;
>   goto sysfs_err;
>   }
> -
> - mutex_unlock(&perf->metrics_lock);
> + id = oa_config->id;
>  
>   drm_dbg(&perf->i915->drm,
>   "Added config %s id=%i\n", oa_config->uuid, oa_config->id);
> + mutex_unlock(&perf->metrics_lock);
>  
> - return oa_config->id;
> + return id;
>  
>  sysfs_err:
>   mutex_unlock(&perf->metrics_lock);
> -- 
> 2.25.1

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Implement fbdev emulation as in-kernel client

2023-03-28 Thread kernel test robot

Hi Thomas,

I love your patch! Yet something to improve:

[auto build test ERROR on 6e5f96153989e454041848f66a5227be9bd0bbc3]

url:
https://github.com/intel-lab-lkp/linux/commits/Thomas-Zimmermann/drm-i915-Move-fbdev-functions/20230328-191627
base:   6e5f96153989e454041848f66a5227be9bd0bbc3
patch link:
https://lore.kernel.org/r/20230328111422.23986-5-tzimmermann%40suse.de
patch subject: [Intel-gfx] [PATCH 4/4] drm/i915: Implement fbdev emulation as 
in-kernel client
config: x86_64-defconfig 
(https://download.01.org/0day-ci/archive/20230329/202303290420.6rd5p4br-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-8) 11.3.0
reproduce (this is a W=1 build):
# 
https://github.com/intel-lab-lkp/linux/commit/6db03fde4587438371c6f7871675cba6389a1319
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review 
Thomas-Zimmermann/drm-i915-Move-fbdev-functions/20230328-191627
git checkout 6db03fde4587438371c6f7871675cba6389a1319
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=x86_64 olddefconfig
make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/gpu/drm/i915/

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot 
| Link: 
https://lore.kernel.org/oe-kbuild-all/202303290420.6rd5p4br-...@intel.com/

All errors (new ones prefixed by >>):

   In file included from drivers/gpu/drm/i915/i915_driver.c:55:
>> drivers/gpu/drm/i915/display/intel_fbdev.h:22:1: error: expected identifier 
>> or '(' before '{' token
  22 | {
 | ^


vim +22 drivers/gpu/drm/i915/display/intel_fbdev.h

6dfccb95cf17cd drivers/gpu/drm/i915/intel_fbdev.h Jani Nikula   
2019-04-05  15  
6dfccb95cf17cd drivers/gpu/drm/i915/intel_fbdev.h Jani Nikula   
2019-04-05  16  #ifdef CONFIG_DRM_FBDEV_EMULATION
6db03fde458743 drivers/gpu/drm/i915/display/intel_fbdev.h Thomas Zimmermann 
2023-03-28  17  void intel_fbdev_setup(struct drm_i915_private *dev_priv);
6dfccb95cf17cd drivers/gpu/drm/i915/intel_fbdev.h Jani Nikula   
2019-04-05  18  void intel_fbdev_set_suspend(struct drm_device *dev, int state, 
bool synchronous);
c1c04560ac038d drivers/gpu/drm/i915/display/intel_fbdev.h Jani Nikula   
2022-02-15  19  struct intel_framebuffer *intel_fbdev_framebuffer(struct 
intel_fbdev *fbdev);
6dfccb95cf17cd drivers/gpu/drm/i915/intel_fbdev.h Jani Nikula   
2019-04-05  20  #else
6db03fde458743 drivers/gpu/drm/i915/display/intel_fbdev.h Thomas Zimmermann 
2023-03-28  21  void intel_fbdev_setup(struct drm_i915_private *dev_priv);
6dfccb95cf17cd drivers/gpu/drm/i915/intel_fbdev.h Jani Nikula   
2019-04-05 @22  {
6dfccb95cf17cd drivers/gpu/drm/i915/intel_fbdev.h Jani Nikula   
2019-04-05  23  }
6dfccb95cf17cd drivers/gpu/drm/i915/intel_fbdev.h Jani Nikula   
2019-04-05  24  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests

Re: [PATCH] drm/sun4i: uncouple DSI dotclock divider from TCON0_DCLK_REG

2023-03-28 Thread Frank Oltmanns



Hi,

On 2023-03-27 at 22:20:45 +0200, Maxime Ripard  wrote:
> Hi,
>
> On Sat, Mar 25, 2023 at 12:40:04PM +0100, Frank Oltmanns wrote:
[...]
>> Actually, I had the following third patch prepared that adjusted the 
>> dotclock rate so that the
>> required PLL rate is set. But again, this seems very indirect, so that’s why 
>> I refrained from
>> submitting it and I submitted the linked patch above instead.
>>
>> Anyway, here is the third proposal:
>>
>> — a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
>> +++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
>> @@ -819,6 +819,34 @@ static void sun6i_dsi_encoder_disable(struct 
>> drm_encoder *encoder)
>>  regulator_disable(dsi->regulator);
>>  }
>>
>> +static bool sun6i_dsi_encoder_mode_fixup(
>> ⁃ struct drm_encoder *encoder,
>> ⁃ const struct drm_display_mode *mode,
>> ⁃ struct drm_display_mode *adjusted_mode)
>> +{
>> ⁃ if (encoder->encoder_type == DRM_MODE_ENCODER_DSI) {
>> ⁃ /*
>> ⁃ * For DSI the PLL rate has to respect the bits per pixel and
>> ⁃ * number of lanes.
>> ⁃ *
>> ⁃ * According to the BSP code:
>> ⁃ * PLL rate = DOTCLOCK * bpp / lanes
>> ⁃ *
>> ⁃ * Therefore, the clock has to be adjusted in order to set the
>> ⁃ * correct PLL rate when actually setting the clock.
>> ⁃ */
>> ⁃ struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
>> ⁃ struct mipi_dsi_device *device = dsi->device;
>> ⁃ u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
>> ⁃ u8 lanes = device->lanes;
>> ⁃
>>
>> ⁃ adjusted_mode->crtc_clock = mode->crtc_clock
>> ⁃ * bpp / (lanes * SUN6I_DSI_TCON_DIV);
>> ⁃ }
>> ⁃
>>
>> ⁃ return true;
>> +}
>> ⁃ static int sun6i_dsi_get_modes(struct drm_connector *connector)
>>   {
>>   struct sun6i_dsi *dsi = connector_to_sun6i_dsi(connector);
>> @@ -851,6 +879,7 @@ static const struct drm_connector_funcs 
>> sun6i_dsi_connector_funcs = {
>>  static const struct drm_encoder_helper_funcs sun6i_dsi_enc_helper_funcs = {
>>  .disable= sun6i_dsi_encoder_disable,
>>  .enable = sun6i_dsi_encoder_enable,
>> ⁃ .mode_fixup = sun6i_dsi_encoder_mode_fixup,
>>   };
>
> It's not clear to me what this patch is supposed to be doing, there's no 
> mode_fixup implementation
> upstream?
>

Sorry, my mail client tried some fancy formatting. :(

This is the patch again.

--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -819,6 +819,34 @@ static void sun6i_dsi_encoder_disable(struct drm_encoder 
*encoder)
regulator_disable(dsi->regulator);
 }

+static bool sun6i_dsi_encoder_mode_fixup(
+  struct drm_encoder *encoder,
+  const struct drm_display_mode *mode,
+  struct drm_display_mode *adjusted_mode)
+{
+   if (encoder->encoder_type == DRM_MODE_ENCODER_DSI) {
+   /*
+* For DSI the PLL rate has to respect the bits per pixel and
+* number of lanes.
+*
+* According to the BSP code:
+* PLL rate = DOTCLOCK * bpp / lanes
+*
+* Therefore, the clock has to be adjusted in order to set the
+* correct PLL rate when actually setting the clock.
+*/
+   struct sun6i_dsi *dsi = encoder_to_sun6i_dsi(encoder);
+   struct mipi_dsi_device *device = dsi->device;
+   u8 bpp = mipi_dsi_pixel_format_to_bpp(device->format);
+   u8 lanes = device->lanes;
+
+   adjusted_mode->crtc_clock = mode->crtc_clock
+* bpp / (lanes * SUN6I_DSI_TCON_DIV);
+   }
+
+   return true;
+}
+
 static int sun6i_dsi_get_modes(struct drm_connector *connector)
 {
struct sun6i_dsi *dsi = connector_to_sun6i_dsi(connector);
@@ -851,6 +879,7 @@ static const struct drm_connector_funcs 
sun6i_dsi_connector_funcs = {
 static const struct drm_encoder_helper_funcs sun6i_dsi_enc_helper_funcs = {
.disable= sun6i_dsi_encoder_disable,
.enable = sun6i_dsi_encoder_enable,
+   .mode_fixup = sun6i_dsi_encoder_mode_fixup,
 };

 static u32 sun6i_dsi_dcs_build_pkt_hdr(struct sun6i_dsi *dsi,


I still like the original patch better, but I'd be happy to submit this
as a proper patch, if this is more to your liking.

Thanks,
  Frank


> Maxime
>
--

Re: Linux 6.3-rc3

2023-03-28 Thread Nathan Chancellor

On Fri, Mar 24, 2023 at 05:23:12PM +0200, Kalle Valo wrote:
> Nathan Chancellor  writes:
> 
> >> This is nitpicking but it would be nice if the tarball contents wouldn't
> >> conflict with each other. Now both llvm-16.0.0-aarch64.tar.gz and
> >> llvm-16.0.0-x86_64.tar extract to the same directory llvm-16.0.0 with
> >> same binary names. It would be much better if they would extract to
> >> llvm-16.0.0-aarch64 and llvm-16.0.0-x86_64, respectively.
> >> 
> >> For example, Arnd's crosstool packages don't conflict with each other:
> >> 
> >> https://mirrors.edge.kernel.org/pub/tools/crosstool/
> >
> > I could certainly do that but what is the use case for extracting both?
> > You cannot run the aarch64 version on an x86_64 host and vice versa, so
> > why bother extracting them?
> 
> Ah, I didn't realise that. I assumed llvm-16.0.0-aarch64.tar.gz was a
> cross compiler. I'm sure you documented that in the page but hey who
> reads the documentation ;)

:)

I have adjusted the README to hopefully make that clearer.

> > I had figured the architecture would be irrelevant once installed on
> > the host, so I opted only to include it in the tarball name. Perhaps I
> > should make it clearer that these are the host architectures, not the
> > target architectures (because clang is multi-targeted, unlike GCC)?
> 
> Makes sense now. But I still think it's good style that a tarball named
> llvm-16.0.0-aarch64.tar.gz extracts to llvm-16.0.0-aarch64.

Indeed, I have adjusted it for future builds:

https://github.com/nathanchance/env/commit/314837e6706889138121a32140d2acdc7895d390

> >> And maybe request a similar llvm directory under pub/tools to make it
> >> more official? :)

We now have https://kernel.org/pub/tools/llvm/, which is about as
official as we can get I suppose :)

https://kernel.org/pub/linux/kernel/people/nathan/llvm/ now points
people there.

Cheers,
Nathan

Re: [PATCH 3/4] dt-bindings: display: elida,kd35t133: document port and rotation

On Mon, Mar 27, 2023 at 2:12 AM Krzysztof Kozlowski
 wrote:
>
> Panels are supposed to have one port (defined in panel-common.yaml
> binding) and can have also rotation:
>
>   rk3326-odroid-go2.dtb: panel@0: 'port', 'rotation' do not match any of the 
> regexes: 'pinctrl-[0-9]+'
>
> Signed-off-by: Krzysztof Kozlowski 
> ---

Reviewed-by: Jagan Teki

Re: [PATCH 1/4] dt-bindings: display: xinpeng, xpp055c272: document port

On Mon, Mar 27, 2023 at 2:12 AM Krzysztof Kozlowski
 wrote:
>
> Panels are supposed to have one port (defined in panel-common.yaml
> binding):
>
>   px30-evb.dtb: panel@0: 'port' does not match any of the regexes: 
> 'pinctrl-[0-9]+'
>
> Signed-off-by: Krzysztof Kozlowski 
> ---

Reviewed-by: Jagan Teki

Re: [PATCH 2/4] dt-bindings: display: feiyang,fy07024di26a30d: document port

On Mon, Mar 27, 2023 at 2:12 AM Krzysztof Kozlowski
 wrote:
>
> Panels are supposed to have one port (defined in panel-common.yaml
> binding):
>
>   rk3399-rockpro64.dtb: panel@0: 'port' does not match any of the regexes: 
> 'pinctrl-[0-9]+'
>
> Signed-off-by: Krzysztof Kozlowski 
> ---

Reviewed-by: Jagan Teki

Re: [PATCH 4/4] dt-bindings: display: sitronix, st7701: document port and rotation

On Mon, Mar 27, 2023 at 2:12 AM Krzysztof Kozlowski
 wrote:
>
> Panels are supposed to have one port (defined in panel-common.yaml
> binding) and can have also rotation:
>
>   rk3326-odroid-go3.dtb: panel@0: 'port', 'rotation' do not match any of the 
> regexes: 'pinctrl-[0-9]+'
>
> Signed-off-by: Krzysztof Kozlowski 
> ---

Reviewed-by: Jagan Teki

Re: [Intel-gfx] [PATCH v6 5/8] drm/i915/pxp: Add ARB session creation and cleanup

2023-03-28 Thread Rodrigo Vivi

On Tue, Mar 28, 2023 at 05:01:36PM +, Teres Alexis, Alan Previn wrote:
> On Mon, 2023-03-27 at 17:15 +0100, Tvrtko Ursulin wrote:
> > These two:
> > e6177ec586d1 ("drm/i915/huc: stall media submission until HuC is loaded")
> > b76c14c8fb2a ("drm/i915/huc: better define HuC status getparam possible 
> > return values.")
> > They do not help here? It is not possible to use or extend the refined 
> > I915_PARAM_HUC_STATUS return values combined with huc load fence for this 
> > all to keep working?
> Checking is-huc-loaded won't reflect is-pxp-available (in case fw/fusing 
> isn't allowing it). But the connection between them is hw-internal so i915 
> asking PXP-fw to attempt a PXP
> session depends on HuC (and the 3 other things i mentioned). However, 
> Tvrtko's point on using fences-or-equivalent is the same thing John Harrison 
> brought up offline with Daniele
> as the proper kernel way to do this type of dependency checking. However, any 
> form of dependency-checking won't improve UMD's experience. We still need to 
> decide if i915-PXP should
> wait-in-kernel or return some-new-spec-error. A useful data point: we are 
> debugging a related issue on actual customer stack. The compositor using mesa 
> is hitting this code path
> very early.. even before gsc-proxy component is loaded and we are trying to 
> figure out why delaying inside intel_pxp_start is not helping (more delays 
> causes the gsc-proxy
> component to also get delayed) but that is a different conversation. I'm only 
> mentioning this because we have a strict requirement to get the desktop login 
> window up within 1-2
> seconds of bootloader->kernel handoff. That said, if use -EAGAIN, I'm not 
> sure if that would work as it would delay the compositor startup beyond the 
> typical end user experience
> unless MESA has a timeout to give up on a cap-testing when seeing repeated 
> -EAGAIN (doubt mesa folks like this?). Perhaps we could just immediately 
> return with a different error
> (instead of current PXP-UAPI spec of -EINVAL or -ENODEV)... perhaps use 
> -ENXIO which apparently is already part of the original pxp code but was 
> never mentioned in UAPI - but we
> return this immediately and document it in UAPI as "hw/fw insfratructure is 
> not yet ready to create pxp arb session, user space can retry but may need 
> delays of up to x-seconds on
> ADl/TGL or y-seconds on MTL, before getting a SUCCESS or one of the other 
> errors).

fair enough. It looks like we need a new get_param! :)

Re: [GIT PULL] exynos-drm-next

2023-03-28 Thread Daniel Vetter

On Tue, Mar 28, 2023 at 01:05:24PM +0900, Inki Dae wrote:
> Hi Dave and Daniel,
> 
>Just one patch series that moves the existing Exynos DSI driver
>to drm/bridge directory to support both SoCs family - Exynos
>and I.MX - because same Exynos MIPI DSI ip can be used by the two
>different SoC family.
> 
>Of course, there are some concerns about this patch series because Exynos
>and I.MX SoCs have different HW characteristic but use the same HW driver.
>However, I believe that there should be no problem as Exynos and I.MX
>developers have conducted tests and reviews enough for about a year
>since last April.
> 
>This would be the first case that we allow different vendor SoCs to use
>same device driver at least in DRM world so we anticipate experiencing
>and resolving new issues through ongoing maintenance, and ultimately,
>the experiences gained here will undoubtedly be able to contribute
>the development of the community as well.
> 
>Please kindly let me know if there is any problem.
> 
> Thanks,
> Inki Dae
> 
> The following changes since commit 46f28427f6f824b6cff06fa025a55350b7de454a:
> 
>   Merge tag 'drm-rcar-next-20230325' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/pinchartl/linux into drm-next 
> (2023-03-27 18:20:20 +0200)
> 
> are available in the Git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
> tags/exynos-drm-next-for-v6.4

Merged, but usually all drm bridge stuff goes through drm-misc, least so
that there's some amount of collaboration and not so much inter-tree
syncing.

Please apply for drm-misc commit rights (at least a quick check shows no
one from samsung) and land future bridge patches through that tree.

Cheers, Daniel

> 
> for you to fetch changes up to b2cfec52feb3bb737c4b65018ef4bfe9789e4be8:
> 
>   drm: bridge: samsung-dsim: Add i.MX8M Plus support (2023-03-28 09:05:41 
> +0900)
> 
> 
> A patch series for moving MIPI-DSI driver for Exynos DRM to drm/bridge
> directory so that I.MX SoC family can also share the same device driver.
> Samsung MIPI DSIM device is a common IP that can be used by Exynos and I.MX8M
> Mini/Nano/Plus SoC. Regarding this, this patch series has added several
> things below to existing MIPI DSI driver,
>   - Add exynos_dsi_type enum type to provide controller data from 
> different
> platforms.
>   - Add two pipeline detection ways support - existing Exynos DSI child 
> node
> and I.MX family of-graph port or ports.
>   - Consider component and bridged based DRM drivers.
>   - Add device tree binding support of I.MX family.
> 
> 
> Jagan Teki (14):
>   drm: exynos: dsi: Drop explicit call to bridge detach
>   drm: exynos: dsi: Lookup OF-graph or Child node devices
>   drm: exynos: dsi: Mark PHY as optional
>   drm: exynos: dsi: Add platform PLL_P (PMS_P) offset
>   drm: exynos: dsi: Introduce hw_type platform data
>   drm: exynos: dsi: Add atomic check
>   drm: exynos: dsi: Add input_bus_flags
>   drm: exynos: dsi: Add atomic_get_input_bus_fmts
>   drm: exynos: dsi: Consolidate component and bridge
>   drm: exynos: dsi: Add host helper for te_irq_handler
>   drm: bridge: Generalize Exynos-DSI driver into a Samsung DSIM bridge
>   dt-bindings: display: exynos: dsim: Add NXP i.MX8M Mini/Nano support
>   drm: bridge: samsung-dsim: Add i.MX8M Mini/Nano support
>   dt-bindings: display: exynos: dsim: Add NXP i.MX8M Plus support
> 
> Marek Szyprowski (1):
>   drm: exynos: dsi: Handle proper host initialization
> 
> Marek Vasut (1):
>   drm: bridge: samsung-dsim: Add i.MX8M Plus support
> 
>  .../bindings/display/exynos/exynos_dsim.txt|2 +
>  MAINTAINERS|9 +
>  drivers/gpu/drm/bridge/Kconfig |   12 +
>  drivers/gpu/drm/bridge/Makefile|1 +
>  drivers/gpu/drm/bridge/samsung-dsim.c  | 1967 
> 
>  drivers/gpu/drm/exynos/Kconfig |1 +
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c| 1813 +-
>  include/drm/bridge/samsung-dsim.h  |  115 ++
>  8 files changed, 2191 insertions(+), 1729 deletions(-)
>  create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c
>  create mode 100644 include/drm/bridge/samsung-dsim.h

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [pull] drm: dma-fence-deadline-core for v6.4

2023-03-28 Thread Daniel Vetter

On Sat, Mar 25, 2023 at 11:24:56AM -0700, Rob Clark wrote:
> Hi Dave and Daniel,
> 
> Here is the series for dma-fence deadline hint, without driver
> specific patches, with the intent that it can be merged into drm-next
> as well as -driver next trees to enable landing driver specific
> support through their corresponding -next trees.
> 
> The following changes since commit eeac8ede17557680855031c6f305ece2378af326:
> 
>   Linux 6.3-rc2 (2023-03-12 16:36:44 -0700)
> 
> are available in the Git repository at:
> 
>   https://gitlab.freedesktop.org/drm/msm.git tags/dma-fence-deadline-core
> 
> for you to fetch changes up to 0bcc8f52a8d9d1f9cd5af7f88c6599a89e64284a:
> 
>   drm/atomic-helper: Set fence deadline for vblank (2023-03-25 10:55:08 -0700)

Ok apparently there's only igts for the sync_file uabi and the only only
userspace for syncobj is the mesa mr that is still under discussion :-/

Yes I know there's a clearly established need for something like this, but
also in drm we don't merge conjectured uabi. Especially with tricky stuff
that's meant to improve best effort performance/tuning problems, where you
really have to benchmark the entire thing and make sure you didn't screw
up some interaction.

To make sure this isn't stuck another full cycle, is there a way to wittle
this just down to the kms atomic flip boosting parts? That way we could at
least start landing the core&driver bits ...
-Daniel

> 
> 
> Immutable branch with dma-fence deadline hint support between drm-next
> and driver -next trees.
> 
> 
> Rob Clark (11):
>   dma-buf/dma-fence: Add deadline awareness
>   dma-buf/fence-array: Add fence deadline support
>   dma-buf/fence-chain: Add fence deadline support
>   dma-buf/dma-resv: Add a way to set fence deadline
>   dma-buf/sync_file: Surface sync-file uABI
>   dma-buf/sync_file: Add SET_DEADLINE ioctl
>   dma-buf/sw_sync: Add fence deadline support
>   drm/scheduler: Add fence deadline support
>   drm/syncobj: Add deadline support for syncobj waits
>   drm/vblank: Add helper to get next vblank time
>   drm/atomic-helper: Set fence deadline for vblank
> 
>  Documentation/driver-api/dma-buf.rst| 16 ++-
>  drivers/dma-buf/dma-fence-array.c   | 11 +
>  drivers/dma-buf/dma-fence-chain.c   | 12 +
>  drivers/dma-buf/dma-fence.c | 60 
>  drivers/dma-buf/dma-resv.c  | 22 +
>  drivers/dma-buf/sw_sync.c   | 81 
> +
>  drivers/dma-buf/sync_debug.h|  2 +
>  drivers/dma-buf/sync_file.c | 19 
>  drivers/gpu/drm/drm_atomic_helper.c | 37 +++
>  drivers/gpu/drm/drm_syncobj.c   | 64 --
>  drivers/gpu/drm/drm_vblank.c| 53 +
>  drivers/gpu/drm/scheduler/sched_fence.c | 46 +++
>  drivers/gpu/drm/scheduler/sched_main.c  |  2 +-
>  include/drm/drm_vblank.h|  1 +
>  include/drm/gpu_scheduler.h | 17 +++
>  include/linux/dma-fence.h   | 22 +
>  include/linux/dma-resv.h|  2 +
>  include/uapi/drm/drm.h  | 17 +++
>  include/uapi/linux/sync_file.h  | 59 +++-
>  19 files changed, 496 insertions(+), 47 deletions(-)

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v2 1/2] drm/bridge: Fix improper bridge init order with pre_enable_prev_first

For a given bridge pipeline if any bridge sets pre_enable_prev_first
flag then the pre_enable for the previous bridge will be called before
pre_enable of this bridge and opposite is done for post_disable.

These are the potential bridge flags to alter bridge init order in order
to satisfy the MIPI DSI host and downstream panel or bridge to function.
However the existing pre_enable_prev_first logic with associated bridge
ordering has broken for both pre_enable and post_disable calls.

[pre_enable]

The altered bridge ordering has failed if two consecutive bridges on a
given pipeline enables the pre_enable_prev_first flag.

Example:
- Panel
- Bridge 1
- Bridge 2 pre_enable_prev_first
- Bridge 3
- Bridge 4 pre_enable_prev_first
- Bridge 5 pre_enable_prev_first
- Bridge 6
- Encoder

In this example, Bridge 4 and Bridge 5 have pre_enable_prev_first.

The logic looks for a bridge which enabled pre_enable_prev_first flag
on each iteration and assigned the previou bridge to limit pointer
if the bridge doesn't enable pre_enable_prev_first flags.

If control found Bridge 2 is pre_enable_prev_first then the iteration
looks for Bridge 3 and found it is not pre_enable_prev_first and assigns
it's previous Bridge 4 to limit pointer and calls pre_enable of Bridge 3
and Bridge 2 and assign iter pointer with limit which is Bridge 4.

Here is the actual problem, for the next iteration control look for
Bridge 5 instead of Bridge 4 has iter pointer in previous iteration
moved to Bridge 4 so this iteration skips the Bridge 4. The iteration
found Bridge 6 doesn't pre_enable_prev_first flags so the limit assigned
to Encoder. From next iteration Encoder skips as it is the last bridge
for reverse order pipeline.

So, the resulting pre_enable bridge order would be,
- Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5.

This patch fixes this by assigning limit to next pointer instead of
previous bridge since the iteration always looks for bridge that does
NOT request prev so assigning next makes sure the last bridge on a
given iteration what exactly the limit bridge is.

So, the resulting pre_enable bridge order with fix would be,
- Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5, Bridge 4,
  Encoder.

[post_disable]

The altered bridge ordering has failed if two consecutive bridges on a
given pipeline enables the pre_enable_prev_first flag.

Example:
- Panel
- Bridge 1
- Bridge 2 pre_enable_prev_first
- Bridge 3
- Bridge 4 pre_enable_prev_first
- Bridge 5 pre_enable_prev_first
- Bridge 6
- Encoder

In this example Bridge 5 and Bridge 4 have pre_enable_prev_first.

The logic looks for a bridge which enabled pre_enable_prev_first flags
on each iteration and assigned the previou bridge to next and next to
limit pointer if the bridge does enable pre_enable_prev_first flag.

If control starts from Bridge 6 then it found next Bridge 5 is
pre_enable_prev_first and immediately the next assigned to previous
Bridge 6 and limit assignments to next Bridge 6 and call post_enable
of Bridge 6 even though the next consecutive Bridge 5 is enabled with
pre_enable_prev_first. This clearly misses the logic to find the state
of next conducive bridge as everytime the next and limit assigns
previous bridge if given bridge enabled pre_enable_prev_first.

So, the resulting post_disable bridge order would be,
- Encoder, Bridge 6, Bridge 5, Bridge 4, Bridge 3, Bridge 2, Bridge 1,
  Panel.

This patch fixes this by assigning next with previou bridge only if the
bridge doesn't enable pre_enable_prev_first flag and the next further
assign it to limit. This way we can find the bridge that NOT requested
prev to disable last.

So, the resulting pre_enable bridge order with fix would be,
- Encoder, Bridge 4, Bridge 5, Bridge 6, Bridge 2, Bridge 3, Bridge 1,
  Panel.

Validated the bridge init ordering by incorporating dummy bridges in
the sun6i-mipi-dsi pipeline

Fixes: 4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to
alter bridge init order")
Signed-off-by: Jagan Teki 
---
Changes for v2:
- add missing dri-devel in CC

 drivers/gpu/drm/drm_bridge.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index c3d69af02e79..052a8e6c9961 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -684,11 +684,17 @@ void drm_atomic_bridge_chain_post_disable(struct 
drm_bridge *bridge,
 */
list_for_each_entry_from(next, 
&encoder->bridge_chain,
 chain_node) {
-   if (next->pre_enable_prev_first) {
+   if (!next->pre_enable_prev_first) {
next = list_prev_entry(next, 
chain_node);
limit = next;
break;

[PATCH v2 2/2] drm/bridge: Document bridge init order with pre_enable_prev_first

In order to satisfy the MIPI DSI initialization sequence the bridge
init order has been altered with the help of pre_enable_prev_first
in pre_enable and post_disable bridge operations.

Document the affected bridge init order with an example on the
bridge operations helpers.

Signed-off-by: Jagan Teki 
---
Changes for v2:
- add missing dri-devel in CC
- prefix @ for bridge helper names

 drivers/gpu/drm/drm_bridge.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 052a8e6c9961..caf0f341e524 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -654,6 +654,13 @@ static void drm_atomic_bridge_call_post_disable(struct 
drm_bridge *bridge,
  * bridge will be called before the previous one to reverse the @pre_enable
  * calling direction.
  *
+ * Example:
+ * Bridge A ---> Bridge B ---> Bridge C ---> Bridge D ---> Bridge E
+ *
+ * With pre_enable_prev_first flag enable in Bridge B, D, E then the resulting
+ * @post_disable order would be,
+ * Bridge B, Bridge A, Bridge E, Bridge D, Bridge C.
+ *
  * Note: the bridge passed should be the one closest to the encoder
  */
 void drm_atomic_bridge_chain_post_disable(struct drm_bridge *bridge,
@@ -750,6 +757,13 @@ static void drm_atomic_bridge_call_pre_enable(struct 
drm_bridge *bridge,
  * If a bridge sets @pre_enable_prev_first, then the pre_enable for the
  * prev bridge will be called before pre_enable of this bridge.
  *
+ * Example:
+ * Bridge A ---> Bridge B ---> Bridge C ---> Bridge D ---> Bridge E
+ *
+ * With pre_enable_prev_first flag enable in Bridge B, D, E then the resulting
+ * @pre_enable order would be,
+ * Bridge C, Bridge D, Bridge E, Bridge A, Bridge B.
+ *
  * Note: the bridge passed should be the one closest to the encoder
  */
 void drm_atomic_bridge_chain_pre_enable(struct drm_bridge *bridge,
-- 
2.25.1

Re: [PATCH v8 2/2] drm: add kms driver for loongson display controller

2023-03-28 Thread Nathan Chancellor

On Tue, Mar 28, 2023 at 11:22:50PM +0800, Sui Jingfeng wrote:
> HI,
> 
> On 2023/3/28 17:27, kernel test robot wrote:
> > Hi Sui,
> > 
> > Thank you for the patch! Perhaps something to improve:
> > 
> > [auto build test WARNING on drm-misc/drm-misc-next]
> > [also build test WARNING on linus/master v6.3-rc4 next-20230328]
> > [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#_base_tree_information]
> > 
> > url:
> > https://github.com/intel-lab-lkp/linux/commits/Sui-Jingfeng/MAINTAINERS-add-maintainers-for-DRM-LOONGSON-driver/20230320-180408
> > base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
> > patch link:
> > https://lore.kernel.org/r/20230320100131.1277034-3-15330273260%40189.cn
> > patch subject: [PATCH v8 2/2] drm: add kms driver for loongson display 
> > controller
> > config: i386-allyesconfig 
> > (https://download.01.org/0day-ci/archive/20230328/202303281754.jwi20j2c-...@intel.com/config)
> > compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project 
> > f28c006a5895fc0e329fe15fead81e37457cb1d1)
> > 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
> >  # 
> > https://github.com/intel-lab-lkp/linux/commit/80b4115f44993f4ebf47b1cb9e8f02953575b977
> >  git remote add linux-review https://github.com/intel-lab-lkp/linux
> >  git fetch --no-tags linux-review 
> > Sui-Jingfeng/MAINTAINERS-add-maintainers-for-DRM-LOONGSON-driver/20230320-180408
> >  git checkout 80b4115f44993f4ebf47b1cb9e8f02953575b977
> >  # save the config file
> >  mkdir build_dir && cp config build_dir/.config
> >  COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
> > O=build_dir ARCH=i386 olddefconfig
> >  COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
> > O=build_dir ARCH=i386 SHELL=/bin/bash drivers/accel/ 
> > drivers/gpu/drm/loongson/ drivers/iio/light/ drivers/media/pci/intel/
> > 
> > If you fix the issue, kindly add following tag where applicable
> > | Reported-by: kernel test robot 
> > | Link: 
> > https://lore.kernel.org/oe-kbuild-all/202303281754.jwi20j2c-...@intel.com/
> > 
> > All warnings (new ones prefixed by >>):
> > 
> > > > drivers/gpu/drm/loongson/lsdc_drv.c:232:11: warning: variable 'gpu' is 
> > > > used uninitialized whenever 'if' condition is false 
> > > > [-Wsometimes-uninitialized]
> > else if (descp->chip == CHIP_LS7A2000)
> >  ^~~~
> > drivers/gpu/drm/loongson/lsdc_drv.c:235:7: note: uninitialized use 
> > occurs here
> > if (!gpu) {
> >  ^~~
> > drivers/gpu/drm/loongson/lsdc_drv.c:232:7: note: remove the 'if' if its 
> > condition is always true
> > else if (descp->chip == CHIP_LS7A2000)
> >  ^
> > drivers/gpu/drm/loongson/lsdc_drv.c:217:21: note: initialize the 
> > variable 'gpu' to silence this warning
> > struct pci_dev *gpu;
> >^
> > = NULL
> > 1 warning generated.
> > --
> 
> In practice,  either  descp->chip == CHIP_LS7A2000 or descp->chip ==
> CHIP_LS7A1000 will be happened at runtime.
> 
> the variable 'gpu' is guaranteed to be initialized when code run at 
> drivers/gpu/drm/loongson/lsdc_drv.c:235
> 
> This warnning is almost wrong here.

Clang's semantic analysis happens before optimizations, meaning it does
not perform interprocedural analysis, so it does not have enough
information at this point to tell that. Either just initialize gpu to
NULL and let the existing 'if (!gpu)' handle it or add a separate else
branch that warns about an unhandled chip value so that it is obvious
what needs to be done if someone forgets to update this statement when a
new chip is supported by this driver.

> > > > drivers/gpu/drm/loongson/lsdc_pll.c:188:14: warning: variable 'diff' is 
> > > > used uninitialized whenever 'if' condition is false 
> > > > [-Wsometimes-uninitialized]
> > else if (clock_khz < computed)
> &g

Re: [Intel-gfx] [PATCH v6 5/8] drm/i915/pxp: Add ARB session creation and cleanup

2023-03-28 Thread Teres Alexis, Alan Previn

On Mon, 2023-03-27 at 17:15 +0100, Tvrtko Ursulin wrote:
> These two:
> e6177ec586d1 ("drm/i915/huc: stall media submission until HuC is loaded")
> b76c14c8fb2a ("drm/i915/huc: better define HuC status getparam possible 
> return values.")
> They do not help here? It is not possible to use or extend the refined 
> I915_PARAM_HUC_STATUS return values combined with huc load fence for this all 
> to keep working?
Checking is-huc-loaded won't reflect is-pxp-available (in case fw/fusing isn't 
allowing it). But the connection between them is hw-internal so i915 asking 
PXP-fw to attempt a PXP
session depends on HuC (and the 3 other things i mentioned). However, Tvrtko's 
point on using fences-or-equivalent is the same thing John Harrison brought up 
offline with Daniele
as the proper kernel way to do this type of dependency checking. However, any 
form of dependency-checking won't improve UMD's experience. We still need to 
decide if i915-PXP should
wait-in-kernel or return some-new-spec-error. A useful data point: we are 
debugging a related issue on actual customer stack. The compositor using mesa 
is hitting this code path
very early.. even before gsc-proxy component is loaded and we are trying to 
figure out why delaying inside intel_pxp_start is not helping (more delays 
causes the gsc-proxy
component to also get delayed) but that is a different conversation. I'm only 
mentioning this because we have a strict requirement to get the desktop login 
window up within 1-2
seconds of bootloader->kernel handoff. That said, if use -EAGAIN, I'm not sure 
if that would work as it would delay the compositor startup beyond the typical 
end user experience
unless MESA has a timeout to give up on a cap-testing when seeing repeated 
-EAGAIN (doubt mesa folks like this?). Perhaps we could just immediately return 
with a different error
(instead of current PXP-UAPI spec of -EINVAL or -ENODEV)... perhaps use -ENXIO 
which apparently is already part of the original pxp code but was never 
mentioned in UAPI - but we
return this immediately and document it in UAPI as "hw/fw insfratructure is not 
yet ready to create pxp arb session, user space can retry but may need delays 
of up to x-seconds on
ADl/TGL or y-seconds on MTL, before getting a SUCCESS or one of the other 
errors).

Re: [PATCH] drm/msm: Avoid rounding down to zero jiffies

On Tue, Mar 28, 2023 at 8:28 AM Dmitry Baryshkov
 wrote:
>
> On 25/03/2023 00:00, Rob Clark wrote:
> > From: Rob Clark 
> >
> > If userspace asked for a timeout greater than zero, but less than a
> > jiffy, they clearly weren't planning on spinning.  So it is better
> > to round up to one.
> >
> > This fixes an issue with supertuxkart that was (for some reason)
> > spinning on a gl sync with 1ms timeout.  CPU time for a demo lap
> > drops from:
> >
> >15.83user 20.98system 0:47.46elapsed 77%CPU
> >
> > to:
> >
> >8.84user 2.30system 0:46.67elapsed 23%CPU
>
> Interesting. We potentially increased the timeout, but the overall
> (elapsed) time has decreased. Nevertheless:

There is some randomness from run to run so small variations in total
--profile-laps=N time are normal.  So I wouldn't read too much into
that, compared to %CPU.  This shouldn't really change how long it
takes for the fence to signal, as much as just prevent the CPU from
busy looping until the fence does signal ;-)

(In theory the CPU busy looping could cause GPU thermal throttling,
but I don't think that was happening in this case.)

> Reviewed-by: Dmitry Baryshkov 

thx

> >
> > Signed-off-by: Rob Clark 
> > ---
> >   drivers/gpu/drm/msm/msm_drv.h | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> > index 9f0c184b02a0..7936aa6cad03 100644
> > --- a/drivers/gpu/drm/msm/msm_drv.h
> > +++ b/drivers/gpu/drm/msm/msm_drv.h
> > @@ -548,7 +548,7 @@ static inline unsigned long timeout_to_jiffies(const 
> > ktime_t *timeout)
> >   remaining_jiffies = ktime_divns(rem, NSEC_PER_SEC / HZ);
> >   }
> >
> > - return clamp(remaining_jiffies, 0LL, (s64)INT_MAX);
> > + return clamp(remaining_jiffies, 1LL, (s64)INT_MAX);
> >   }
> >
> >   /* Driver helpers */
>
> --
> With best wishes
> Dmitry
>

RE: [PATCH 12/34] drm/amdgpu: add configurable grace period for unmap queues

2023-03-28 Thread Kim, Jonathan

[Public]

Thanks for catch Kent.
I'll fix up the typos with a follow-on.

Jon

> -Original Message-
> From: Russell, Kent 
> Sent: Tuesday, March 28, 2023 11:19 AM
> To: Kim, Jonathan ; amd-...@lists.freedesktop.org;
> dri-devel@lists.freedesktop.org
> Cc: Kuehling, Felix ; Kim, Jonathan
> 
> Subject: RE: [PATCH 12/34] drm/amdgpu: add configurable grace period for
> unmap queues
>
> [AMD Official Use Only - General]
>
> 3 tiny grammar/spelling things inline (not critical)
>
>  Kent
>
> > -Original Message-
> > From: amd-gfx  On Behalf Of
> > Jonathan Kim
> > Sent: Monday, March 27, 2023 2:43 PM
> > To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> > Cc: Kuehling, Felix ; Kim, Jonathan
> > 
> > Subject: [PATCH 12/34] drm/amdgpu: add configurable grace period for
> unmap
> > queues
> >
> > The HWS schedule allows a grace period for wave completion prior to
> > preemption for better performance by avoiding CWSR on waves that can
> > potentially complete quickly. The debugger, on the other hand, will
> > want to inspect wave status immediately after it actively triggers
> > preemption (a suspend function to be provided).
> >
> > To minimize latency between preemption and debugger wave inspection,
> allow
> > immediate preemption by setting the grace period to 0.
> >
> > Note that setting the preepmtion grace period to 0 will result in an
> > infinite grace period being set due to a CP FW bug so set it to 1 for now.
> >
> > v2: clarify purpose in the description of this patch
> >
> > Signed-off-by: Jonathan Kim 
> > Reviewed-by: Felix Kuehling 
> > ---
> >  .../drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c  |  2 +
> >  .../drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c   |  2 +
> >  .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 43 
> >  .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.h|  6 ++
> >  .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c  |  2 +
> >  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 43 
> >  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.h |  9 ++-
> >  .../drm/amd/amdkfd/kfd_device_queue_manager.c | 62 +-
> >  .../drm/amd/amdkfd/kfd_device_queue_manager.h |  2 +
> >  .../gpu/drm/amd/amdkfd/kfd_packet_manager.c   | 32 +
> >  .../drm/amd/amdkfd/kfd_packet_manager_v9.c| 39 +++
> >  .../gpu/drm/amd/amdkfd/kfd_pm4_headers_ai.h   | 65
> +++
> >  drivers/gpu/drm/amd/amdkfd/kfd_priv.h |  5 ++
> >  13 files changed, 291 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
> > index a6f98141c29c..b811a0985050 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
> > @@ -82,5 +82,7 @@ const struct kfd2kgd_calls aldebaran_kfd2kgd = {
> > .get_cu_occupancy = kgd_gfx_v9_get_cu_occupancy,
> > .enable_debug_trap = kgd_aldebaran_enable_debug_trap,
> > .disable_debug_trap = kgd_aldebaran_disable_debug_trap,
> > +   .get_iq_wait_times = kgd_gfx_v9_get_iq_wait_times,
> > +   .build_grace_period_packet_info =
> > kgd_gfx_v9_build_grace_period_packet_info,
> > .program_trap_handler_settings =
> > kgd_gfx_v9_program_trap_handler_settings,
> >  };
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
> > index d2918e5c0dea..a62bd0068515 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
> > @@ -410,6 +410,8 @@ const struct kfd2kgd_calls arcturus_kfd2kgd = {
> >
> > kgd_gfx_v9_set_vm_context_page_table_base,
> > .enable_debug_trap = kgd_arcturus_enable_debug_trap,
> > .disable_debug_trap = kgd_arcturus_disable_debug_trap,
> > +   .get_iq_wait_times = kgd_gfx_v9_get_iq_wait_times,
> > +   .build_grace_period_packet_info =
> > kgd_gfx_v9_build_grace_period_packet_info,
> > .get_cu_occupancy = kgd_gfx_v9_get_cu_occupancy,
> > .program_trap_handler_settings =
> > kgd_gfx_v9_program_trap_handler_settings
> >  };
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
> > index 969015281510..605387e55d33 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
> > @@ -802,6 +802,47 @@ uint32_t kgd_gfx_v10_disable_debug_trap(struct
> > amdgpu_device *adev,
> > return 0;
> >  }
> >
> > +/* kgd_gfx_v10_get_iq_wait_times: Returns the mmCP_IQ_WAIT_TIME1/2
> > values
> > + * The values read are:
> > + * ib_offload_wait_time -- Wait Count for Indirect Buffer Offloads.
> > + * atomic_offload_wait_time -- Wait Count for L2 and GDS Atomics
> > Offloads.
> > + * wrm_offload_wait_time-- Wait Count for WAIT_REG_MEM Offloads.
> > + * gws_wait_time-- Wait Count for Global Wave Syncs.
>

Re: [PATCH v4 06/14] drm/msm/a6xx: Remove both GBIF and RBBM GBIF halt on hw init


On 14/03/2023 17:28, Konrad Dybcio wrote:

Currently we're only deasserting REG_A6XX_RBBM_GBIF_HALT, but we also
need REG_A6XX_GBIF_HALT to be set to 0. For GMU-equipped GPUs this is
done in a6xx_bus_clear_pending_transactions(), but for the GMU-less
ones we have to do it *somewhere*. Unhalting both side by side sounds
like a good plan and it won't cause any issues if it's unnecessary.

Also, add a memory barrier to ensure it's gone through.

Signed-off-by: Konrad Dybcio 
---
  drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)


Reviewed-by: Dmitry Baryshkov 

--
With best wishes
Dmitry

Re: [PATCH v4 14/14] drm/msm/a6xx: Add A610 speedbin support


On 14/03/2023 17:28, Konrad Dybcio wrote:

A610 is implemented on at least three SoCs: SM6115 (bengal), SM6125
(trinket) and SM6225 (khaje). Trinket does not support speed binning
(only a single SKU exists) and we don't yet support khaje upstream.
Hence, add a fuse mapping table for bengal to allow for per-chip
frequency limiting.

Reviewed-by: Dmitry Baryshkov 
Signed-off-by: Konrad Dybcio 
---
  drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 27 +++
  1 file changed, 27 insertions(+)


Reviewed-by: Dmitry Baryshkov 

--
With best wishes
Dmitry

Re: [PATCH 4/4] drm/i915: Implement fbdev emulation as in-kernel client

2023-03-28 Thread Jani Nikula

On Tue, 28 Mar 2023, Thomas Zimmermann  wrote:
> Replace all code that initializes or releases fbdev emulation
> throughout the driver. Instead initialize the fbdev client by a
> single call to i915_fbdev_setup() after i915 has registered its
> DRM device. Just like in most drivers, i915 fbdev emulation now
> acts like a regular DRM client.
>
> The fbdev client setup consists of the initial preparation and the
> hot-plugging of the display. The latter creates the fbdev device
> and sets up the fbdev framebuffer. The setup performs display
> hot-plugging once. If no display can be detected, DRM probe helpers
> re-run the detection on each hotplug event.
>
> A call to drm_dev_unregister() releases the client automatically.
> No further action is required within i915. If the fbdev framebuffer
> has been fully set up, struct fb_ops.fb_destroy implements the
> release. For partially initialized emulation, the fbdev client
> reverts the initial setup.
>
> Signed-off-by: Thomas Zimmermann 

I like the direction in the series, but I'm afraid I don't have the time
for proper detailed review of this right now. Just a couple of nits I
stumbled on inline.

Anyone else have a chance to get this reviewed?

BR,
Jani.


> ---
>  drivers/gpu/drm/i915/display/intel_display.c |  30 ---
>  drivers/gpu/drm/i915/display/intel_fbdev.c   | 184 +--
>  drivers/gpu/drm/i915/display/intel_fbdev.h   |  20 +-
>  drivers/gpu/drm/i915/i915_driver.c   |   2 +
>  4 files changed, 87 insertions(+), 149 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 430a1016e013..1bbeb7a061e3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -85,7 +85,6 @@
>  #include "intel_dvo.h"
>  #include "intel_fb.h"
>  #include "intel_fbc.h"
> -#include "intel_fbdev.h"
>  #include "intel_fdi.h"
>  #include "intel_fifo_underrun.h"
>  #include "intel_frontbuffer.h"
> @@ -8588,11 +8587,6 @@ int intel_modeset_init(struct drm_i915_private *i915)
>  
>   intel_overlay_setup(i915);
>  
> - ret = intel_fbdev_init(&i915->drm);
> - if (ret)
> - return ret;
> -
> - /* Only enable hotplug handling once the fbdev is fully set up. */
>   intel_hpd_init(i915);
>   intel_hpd_poll_disable(i915);
>  
> @@ -8796,9 +8790,6 @@ void intel_modeset_driver_remove_noirq(struct 
> drm_i915_private *i915)
>*/
>   intel_hpd_poll_fini(i915);
>  
> - /* poll work can call into fbdev, hence clean that up afterwards */
> - intel_fbdev_fini(i915);
> -
>   intel_unregister_dsm_handler();
>  
>   /* flush any delayed tasks or pending work */
> @@ -8864,21 +8855,6 @@ void intel_display_driver_register(struct 
> drm_i915_private *i915)
>  
>   intel_display_debugfs_register(i915);
>  
> - /*
> -  * Some ports require correctly set-up hpd registers for
> -  * detection to work properly (leading to ghost connected
> -  * connector status), e.g. VGA on gm45.  Hence we can only set
> -  * up the initial fbdev config after hpd irqs are fully
> -  * enabled. We do it last so that the async config cannot run
> -  * before the connectors are registered.
> -  */
> - intel_fbdev_initial_config_async(i915);
> -
> - /*
> -  * We need to coordinate the hotplugs with the asynchronous
> -  * fbdev configuration, for which we use the
> -  * fbdev->async_cookie.
> -  */
>   drm_kms_helper_poll_init(&i915->drm);
>  }
>  
> @@ -8887,14 +8863,8 @@ void intel_display_driver_unregister(struct 
> drm_i915_private *i915)
>   if (!HAS_DISPLAY(i915))
>   return;
>  
> - intel_fbdev_unregister(i915);
>   intel_audio_deinit(i915);
>  
> - /*
> -  * After flushing the fbdev (incl. a late async config which
> -  * will have delayed queuing of a hotplug event), then flush
> -  * the hotplug events.
> -  */
>   drm_kms_helper_poll_fini(&i915->drm);
>   drm_atomic_helper_shutdown(&i915->drm);
>  
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
> b/drivers/gpu/drm/i915/display/intel_fbdev.c
> index bdb9e6f43602..8b618db30ee5 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> @@ -24,7 +24,6 @@
>   * David Airlie
>   */
>  
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -38,6 +37,7 @@
>  #include 
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -55,7 +55,6 @@ struct intel_fbdev {
>   struct intel_framebuffer *fb;
>   struct i915_vma *vma;
>   unsigned long vma_flags;
> - async_cookie_t cookie;
>   int preferred_bpp;
>  
>   /* Whether or not fbdev hpd processing is temporarily suspended */
> @@ -120,6 +119,26 @@ static int intel_fbdev_pan_display(struct 
> fb_var_screeninfo *var,
>   return ret;
>  }
>  
> +static void intel_fbdev_fb_destroy(struct fb_info *info

Re: [PATCH v4 13/14] drm/msm/a6xx: Add A619_holi speedbin support


On 14/03/2023 17:28, Konrad Dybcio wrote:

A619_holi is implemented on at least two SoCs: SM4350 (holi) and SM6375
(blair). This is what seems to be a first occurrence of this happening,
but it's easy to overcome by guarding the SoC-specific fuse values with
of_machine_is_compatible(). Do just that to enable frequency limiting
on these SoCs.

Signed-off-by: Konrad Dybcio 
---
  drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 31 +++
  1 file changed, 31 insertions(+)


Reviewed-by: Dmitry Baryshkov 

--
With best wishes
Dmitry

Re: [PATCH v4 12/14] drm/msm/a6xx: Use adreno_is_aXYZ macros in speedbin matching


On 14/03/2023 17:28, Konrad Dybcio wrote:

Before transitioning to using per-SoC and not per-Adreno speedbin
fuse values (need another patchset to land elsewhere), a good
improvement/stopgap solution is to use adreno_is_aXYZ macros in
place of explicit revision matching. Do so to allow differentiating
between A619 and A619_holi.

Signed-off-by: Konrad Dybcio 
---
  drivers/gpu/drm/msm/adreno/a6xx_gpu.c   | 18 +-
  drivers/gpu/drm/msm/adreno/adreno_gpu.h | 14 --
  2 files changed, 21 insertions(+), 11 deletions(-)


Reviewed-by: Dmitry Baryshkov 

--
With best wishes
Dmitry

Re: [PATCH] drm/msm: Avoid rounding down to zero jiffies


On 25/03/2023 00:00, Rob Clark wrote:

From: Rob Clark 

If userspace asked for a timeout greater than zero, but less than a
jiffy, they clearly weren't planning on spinning.  So it is better
to round up to one.

This fixes an issue with supertuxkart that was (for some reason)
spinning on a gl sync with 1ms timeout.  CPU time for a demo lap
drops from:

   15.83user 20.98system 0:47.46elapsed 77%CPU

to:

   8.84user 2.30system 0:46.67elapsed 23%CPU


Interesting. We potentially increased the timeout, but the overall 
(elapsed) time has decreased. Nevertheless:


Reviewed-by: Dmitry Baryshkov 



Signed-off-by: Rob Clark 
---
  drivers/gpu/drm/msm/msm_drv.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 9f0c184b02a0..7936aa6cad03 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -548,7 +548,7 @@ static inline unsigned long timeout_to_jiffies(const 
ktime_t *timeout)
remaining_jiffies = ktime_divns(rem, NSEC_PER_SEC / HZ);
}
  
-	return clamp(remaining_jiffies, 0LL, (s64)INT_MAX);

+   return clamp(remaining_jiffies, 1LL, (s64)INT_MAX);
  }
  
  /* Driver helpers */


--
With best wishes
Dmitry

Re: [PATCH] drm/mediatek: Add ovl_adaptor get format function

2023-03-28 Thread AngeloGioacchino Del Regno


Il 28/03/23 04:51, Nancy.Lin ha scritto:

Add ovl_adaptor get_format and get_num_formats component function.
The two functions are need for getting the supported format in
mtk_plane_init().

Signed-off-by: Nancy.Lin 
Change-Id: Ia8e9f6cabcc71b262155a022b103ae81d1616b8f


The code looks good to me, but please drop that Change-Id tag (which has no
meaning upstream) and resend.

Thanks,
Angelo

Re: [PATCH v8 2/2] drm: add kms driver for loongson display controller

2023-03-28 Thread Sui Jingfeng


HI,

On 2023/3/28 17:27, kernel test robot wrote:

Hi Sui,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on linus/master v6.3-rc4 next-20230328]
[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#_base_tree_information]

url:
https://github.com/intel-lab-lkp/linux/commits/Sui-Jingfeng/MAINTAINERS-add-maintainers-for-DRM-LOONGSON-driver/20230320-180408
base:   git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link:
https://lore.kernel.org/r/20230320100131.1277034-3-15330273260%40189.cn
patch subject: [PATCH v8 2/2] drm: add kms driver for loongson display 
controller
config: i386-allyesconfig 
(https://download.01.org/0day-ci/archive/20230328/202303281754.jwi20j2c-...@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project 
f28c006a5895fc0e329fe15fead81e37457cb1d1)
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
 # 
https://github.com/intel-lab-lkp/linux/commit/80b4115f44993f4ebf47b1cb9e8f02953575b977
 git remote add linux-review https://github.com/intel-lab-lkp/linux
 git fetch --no-tags linux-review 
Sui-Jingfeng/MAINTAINERS-add-maintainers-for-DRM-LOONGSON-driver/20230320-180408
 git checkout 80b4115f44993f4ebf47b1cb9e8f02953575b977
 # save the config file
 mkdir build_dir && cp config build_dir/.config
 COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=i386 olddefconfig
 COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 
O=build_dir ARCH=i386 SHELL=/bin/bash drivers/accel/ drivers/gpu/drm/loongson/ 
drivers/iio/light/ drivers/media/pci/intel/

If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot 
| Link: 
https://lore.kernel.org/oe-kbuild-all/202303281754.jwi20j2c-...@intel.com/

All warnings (new ones prefixed by >>):


drivers/gpu/drm/loongson/lsdc_drv.c:232:11: warning: variable 'gpu' is used 
uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]

else if (descp->chip == CHIP_LS7A2000)
 ^~~~
drivers/gpu/drm/loongson/lsdc_drv.c:235:7: note: uninitialized use occurs 
here
if (!gpu) {
 ^~~
drivers/gpu/drm/loongson/lsdc_drv.c:232:7: note: remove the 'if' if its 
condition is always true
else if (descp->chip == CHIP_LS7A2000)
 ^
drivers/gpu/drm/loongson/lsdc_drv.c:217:21: note: initialize the variable 
'gpu' to silence this warning
struct pci_dev *gpu;
   ^
= NULL
1 warning generated.
--


In practice,  either  descp->chip == CHIP_LS7A2000 or descp->chip == 
CHIP_LS7A1000 will be happened at runtime.


the variable 'gpu' is guaranteed to be initialized when code run at  
drivers/gpu/drm/loongson/lsdc_drv.c:235


This warnning is almost wrong here.


drivers/gpu/drm/loongson/lsdc_pll.c:188:14: warning: variable 'diff' is used 
uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]

else if (clock_khz < computed)
 ^~~~
drivers/gpu/drm/loongson/lsdc_pll.c:191:9: note: uninitialized use occurs 
here
if (diff < min) {
^~~~
drivers/gpu/drm/loongson/lsdc_pll.c:188:10: note: remove the 'if' if its 
condition is always true
else if (clock_khz < computed)
 ^
drivers/gpu/drm/loongson/lsdc_pll.c:177:22: note: initialize the variable 
'diff' to silence this warning
unsigned int diff;
 ^
  = 0
1 warning generated.


Here the robot is also wrong here in practice,

because either  if (clock_khz >= computed) or else if (clock_khz < 
computed) will be happen.


'diff' variable is guaranteed to be initialized.



vim +232 drivers/gpu/drm/loongson/lsdc_drv.c

212 
213 static int lsdc_get_dedicated_vram(struct lsdc_device *ldev,
214const struct lsdc_desc *descp)
215 {
216 struct drm_device *ddev = &ldev->base;
217 struct pci_dev *gpu;
218 resourc

Re: [PATCH 2/4] drm/i915: Initialize fbdev DRM client with callback functions

2023-03-28 Thread Jani Nikula

On Tue, 28 Mar 2023, Thomas Zimmermann  wrote:
> Initialize i915's fbdev client by giving an instance of struct
> drm_client_funcsi to drm_client_init(). Also clean up with
> drm_client_release().
>
> Doing this in i915 prevents fbdev helpers from initializing and
> releasing the client internally (see drm_fb_helper_init()). No
> functional change yet; the client callbacks will be filled later.
>
> Signed-off-by: Thomas Zimmermann 
> ---
>  drivers/gpu/drm/i915/display/intel_fbdev.c | 43 --
>  1 file changed, 39 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
> b/drivers/gpu/drm/i915/display/intel_fbdev.c
> index 88de79279ce5..290da5e94bc5 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
> @@ -364,6 +364,7 @@ static void intel_fbdev_destroy(struct intel_fbdev 
> *ifbdev)
>   if (ifbdev->fb)
>   drm_framebuffer_remove(&ifbdev->fb->base);
>  
> + drm_client_release(&ifbdev->helper.client);
>   drm_fb_helper_unprepare(&ifbdev->helper);
>   kfree(ifbdev);
>  }
> @@ -656,6 +657,30 @@ void intel_fbdev_restore_mode(struct drm_i915_private 
> *dev_priv)
>   intel_fbdev_invalidate(ifbdev);
>  }
>  
> +/*
> + * Fbdev client and struct drm_client_funcs
> + */
> +
> +static void intel_fbdev_client_unregister(struct drm_client_dev *client)
> +{ }
> +
> +static int intel_fbdev_client_restore(struct drm_client_dev *client)
> +{
> + return 0;
> +}
> +
> +static int intel_fbdev_client_hotplug(struct drm_client_dev *client)
> +{
> + return 0;
> +}
> +
> +static const struct drm_client_funcs intel_fbdev_client_funcs = {
> + .owner  = THIS_MODULE,
> + .unregister = intel_fbdev_client_unregister,
> + .restore= intel_fbdev_client_restore,
> + .hotplug= intel_fbdev_client_hotplug,
> +};
> +
>  int intel_fbdev_init(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -677,16 +702,26 @@ int intel_fbdev_init(struct drm_device *dev)
>   else
>   ifbdev->preferred_bpp = ifbdev->helper.preferred_bpp;
>  
> + ret = drm_client_init(dev, &ifbdev->helper.client, "i915-fbdev",
> +   &intel_fbdev_client_funcs);
> + if (ret)
> + goto err_drm_fb_helper_unprepare;
> +
>   ret = drm_fb_helper_init(dev, &ifbdev->helper);
> - if (ret) {
> - kfree(ifbdev);
> - return ret;
> - }
> + if (ret)
> + goto err_drm_client_release;
>  
>   dev_priv->display.fbdev.fbdev = ifbdev;
>   INIT_WORK(&dev_priv->display.fbdev.suspend_work, 
> intel_fbdev_suspend_worker);
>  
>   return 0;
> +
> +err_drm_client_release:
> + drm_client_release(&ifbdev->helper.client);
> +err_drm_fb_helper_unprepare:
> + drm_client_release(&ifbdev->helper.client);

I suppose this should be

drm_fb_helper_unprepare(&ifbdev->helper);

instead of the double drm_client_release(). And we're missing this
cleanup already.

BR,
Jani.


> + kfree(ifbdev);
> + return ret;
>  }
>  
>  static void intel_fbdev_initial_config(void *data, async_cookie_t cookie)

-- 
Jani Nikula, Intel Open Source Graphics Center

RE: [PATCH 12/34] drm/amdgpu: add configurable grace period for unmap queues

2023-03-28 Thread Russell, Kent

[AMD Official Use Only - General]

3 tiny grammar/spelling things inline (not critical)

 Kent

> -Original Message-
> From: amd-gfx  On Behalf Of
> Jonathan Kim
> Sent: Monday, March 27, 2023 2:43 PM
> To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Cc: Kuehling, Felix ; Kim, Jonathan
> 
> Subject: [PATCH 12/34] drm/amdgpu: add configurable grace period for unmap
> queues
> 
> The HWS schedule allows a grace period for wave completion prior to
> preemption for better performance by avoiding CWSR on waves that can
> potentially complete quickly. The debugger, on the other hand, will
> want to inspect wave status immediately after it actively triggers
> preemption (a suspend function to be provided).
> 
> To minimize latency between preemption and debugger wave inspection, allow
> immediate preemption by setting the grace period to 0.
> 
> Note that setting the preepmtion grace period to 0 will result in an
> infinite grace period being set due to a CP FW bug so set it to 1 for now.
> 
> v2: clarify purpose in the description of this patch
> 
> Signed-off-by: Jonathan Kim 
> Reviewed-by: Felix Kuehling 
> ---
>  .../drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c  |  2 +
>  .../drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c   |  2 +
>  .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 43 
>  .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.h|  6 ++
>  .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10_3.c  |  2 +
>  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 43 
>  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.h |  9 ++-
>  .../drm/amd/amdkfd/kfd_device_queue_manager.c | 62 +-
>  .../drm/amd/amdkfd/kfd_device_queue_manager.h |  2 +
>  .../gpu/drm/amd/amdkfd/kfd_packet_manager.c   | 32 +
>  .../drm/amd/amdkfd/kfd_packet_manager_v9.c| 39 +++
>  .../gpu/drm/amd/amdkfd/kfd_pm4_headers_ai.h   | 65 +++
>  drivers/gpu/drm/amd/amdkfd/kfd_priv.h |  5 ++
>  13 files changed, 291 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
> index a6f98141c29c..b811a0985050 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_aldebaran.c
> @@ -82,5 +82,7 @@ const struct kfd2kgd_calls aldebaran_kfd2kgd = {
>   .get_cu_occupancy = kgd_gfx_v9_get_cu_occupancy,
>   .enable_debug_trap = kgd_aldebaran_enable_debug_trap,
>   .disable_debug_trap = kgd_aldebaran_disable_debug_trap,
> + .get_iq_wait_times = kgd_gfx_v9_get_iq_wait_times,
> + .build_grace_period_packet_info =
> kgd_gfx_v9_build_grace_period_packet_info,
>   .program_trap_handler_settings =
> kgd_gfx_v9_program_trap_handler_settings,
>  };
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
> index d2918e5c0dea..a62bd0068515 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c
> @@ -410,6 +410,8 @@ const struct kfd2kgd_calls arcturus_kfd2kgd = {
> 
>   kgd_gfx_v9_set_vm_context_page_table_base,
>   .enable_debug_trap = kgd_arcturus_enable_debug_trap,
>   .disable_debug_trap = kgd_arcturus_disable_debug_trap,
> + .get_iq_wait_times = kgd_gfx_v9_get_iq_wait_times,
> + .build_grace_period_packet_info =
> kgd_gfx_v9_build_grace_period_packet_info,
>   .get_cu_occupancy = kgd_gfx_v9_get_cu_occupancy,
>   .program_trap_handler_settings =
> kgd_gfx_v9_program_trap_handler_settings
>  };
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
> index 969015281510..605387e55d33 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
> @@ -802,6 +802,47 @@ uint32_t kgd_gfx_v10_disable_debug_trap(struct
> amdgpu_device *adev,
>   return 0;
>  }
> 
> +/* kgd_gfx_v10_get_iq_wait_times: Returns the mmCP_IQ_WAIT_TIME1/2
> values
> + * The values read are:
> + * ib_offload_wait_time -- Wait Count for Indirect Buffer Offloads.
> + * atomic_offload_wait_time -- Wait Count for L2 and GDS Atomics
> Offloads.
> + * wrm_offload_wait_time-- Wait Count for WAIT_REG_MEM Offloads.
> + * gws_wait_time-- Wait Count for Global Wave Syncs.
> + * que_sleep_wait_time  -- Wait Count for Dequeue Retry.
> + * sch_wave_wait_time   -- Wait Count for Scheduling Wave Message.
> + * sem_rearm_wait_time  -- Wait Count for Semaphore re-arm.
> + * deq_retry_wait_time  -- Wait Count for Global Wave Syncs.
> + */
> +void kgd_gfx_v10_get_iq_wait_times(struct amdgpu_device *adev,
> + uint32_t *wait_times)
> +
> +{
> + *wait_times = RREG32(SOC15_REG_OFFSET(GC, 0,
> mmCP_IQ_WAIT_TIME2));
> +}
> +
> +void kgd_gfx_v10_build_grace_period

Re: [PATCH v2 07/11] video/aperture: Disable and unregister sysfb devices via aperture helpers

2023-03-28 Thread Samuel Čavoj

On 2023-03-20 13:12, Javier Martinez Canillas wrote:

Samuel Čavoj writes:

[...]

This call to sysfb_disable() has been causing trouble with regard
to

VFIO. VFIO has been calling aperture_remove_conflicting_pci_devices
to
get rid of any console drivers (d173780620792c) using the device in
question, but now even unrelated drivers are getting killed.
Example

situation:

Which drivers do you use?

This happens with either no drivers loaded or the proprietary nvidia
driver. Nouveau is fine as it doesn't rely on efifb but brings its
own.

Which is what all DRM drivers should do. If they want to make sure that
a
fbdev will be present after the DRM driver probes, then should register
an

emulated fbdev.

I don't see how this is specific to Nvidia or DRM drivers.

The efifb is killed if vfio-pci (or another driver which uses the
aperture system to remove conflicting drivers) is bound to ANY pci
device, regardless of whether it's nvidia's fault for not implementing
a framebuffer. Fair enough, I agree that they should, but
I for one expect my efifb to not die at a random time
when a random unrelated driver does a random thing with another
unrelated GPU.

Or is the efifb considered a stop-gap solution the only purpose of
which is early boot--before another GPU driver is loaded?

There was an attempt to workaround that in [0], in particular patch [1]
but that effort was not continued since the only DRM driver that would
be
affected is the Nvidia proprietary driver that relies on
efifb/simpledrm

to have a VT.

[0]:
https://patchwork.kernel.org/project/dri-devel/list/?series=711019&archive=both
[1]:
https://patchwork.kernel.org/project/dri-devel/patch/2023054112.90575-11-daniel.vet...@ffwll.ch/

[PATCH v5 8/8] drm/i915/gt: Hold a wakeref for the active VM

From: Chris Wilson 

There may be a disconnect between the GT used by the engine and the GT
used for the VM, requiring us to hold a wakeref on both while the GPU is
active with this request.

Signed-off-by: Chris Wilson 
Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/gt/intel_context.h   | 15 +++
 drivers/gpu/drm/i915/gt/intel_context_types.h |  2 ++
 drivers/gpu/drm/i915/gt/intel_engine_pm.c |  4 
 3 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_context.h 
b/drivers/gpu/drm/i915/gt/intel_context.h
index 0a8d553da3f439..582faa21181e58 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -14,6 +14,7 @@
 #include "i915_drv.h"
 #include "intel_context_types.h"
 #include "intel_engine_types.h"
+#include "intel_gt_pm.h"
 #include "intel_ring_types.h"
 #include "intel_timeline_types.h"
 #include "i915_trace.h"
@@ -207,8 +208,11 @@ void intel_context_exit_engine(struct intel_context *ce);
 static inline void intel_context_enter(struct intel_context *ce)
 {
lockdep_assert_held(&ce->timeline->mutex);
-   if (!ce->active_count++)
-   ce->ops->enter(ce);
+   if (ce->active_count++)
+   return;
+
+   ce->ops->enter(ce);
+   ce->wakeref = intel_gt_pm_get(ce->vm->gt);
 }
 
 static inline void intel_context_mark_active(struct intel_context *ce)
@@ -222,8 +226,11 @@ static inline void intel_context_exit(struct intel_context 
*ce)
 {
lockdep_assert_held(&ce->timeline->mutex);
GEM_BUG_ON(!ce->active_count);
-   if (!--ce->active_count)
-   ce->ops->exit(ce);
+   if (--ce->active_count)
+   return;
+
+   intel_gt_pm_put_async(ce->vm->gt, ce->wakeref);
+   ce->ops->exit(ce);
 }
 
 static inline struct intel_context *intel_context_get(struct intel_context *ce)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h 
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index e36670f2e6260b..5dc39a9d7a501c 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -17,6 +17,7 @@
 #include "i915_utils.h"
 #include "intel_engine_types.h"
 #include "intel_sseu.h"
+#include "intel_wakeref.h"
 
 #include "uc/intel_guc_fwif.h"
 
@@ -110,6 +111,7 @@ struct intel_context {
u32 ring_size;
struct intel_ring *ring;
struct intel_timeline *timeline;
+   intel_wakeref_t wakeref;
 
unsigned long flags;
 #define CONTEXT_BARRIER_BIT0
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c 
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 7063dea2112943..c2d17c97bfe989 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -114,6 +114,10 @@ __queue_and_release_pm(struct i915_request *rq,
 
ENGINE_TRACE(engine, "parking\n");
 
+   GEM_BUG_ON(rq->context->active_count != 1);
+   __intel_gt_pm_get(engine->gt);
+   rq->context->wakeref = intel_wakeref_track(&engine->gt->wakeref);
+
/*
 * We have to serialise all potential retirement paths with our
 * submission, as we don't want to underflow either the

-- 
2.34.1

[PATCH v5 7/8] drm/i915: track gt pm wakerefs

Track every intel_gt_pm_get() until its corresponding release in
intel_gt_pm_put() by returning a cookie to the caller for acquire that
must be passed by on released. When there is an imbalance, we can see who
either tried to free a stale wakeref, or who forgot to free theirs.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/Kconfig.debug | 15 +
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c |  7 ++--
 .../drm/i915/gem/selftests/i915_gem_coherency.c| 10 +++---
 drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 14 
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.c| 13 +---
 drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h  |  3 +-
 drivers/gpu/drm/i915/gt/intel_engine_pm.c  |  6 ++--
 drivers/gpu/drm/i915/gt/intel_engine_types.h   |  2 ++
 .../gpu/drm/i915/gt/intel_execlists_submission.c   |  2 +-
 drivers/gpu/drm/i915/gt/intel_gt_pm.c  | 12 ---
 drivers/gpu/drm/i915/gt/intel_gt_pm.h  | 38 +-
 drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c  |  4 +--
 drivers/gpu/drm/i915/gt/selftest_engine_cs.c   | 20 +++-
 drivers/gpu/drm/i915/gt/selftest_gt_pm.c   |  5 +--
 drivers/gpu/drm/i915/gt/selftest_reset.c   | 10 +++---
 drivers/gpu/drm/i915/gt/selftest_rps.c | 17 ++
 drivers/gpu/drm/i915/gt/selftest_slpc.c|  5 +--
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c  |  9 ++---
 drivers/gpu/drm/i915/i915_pmu.c| 16 +
 drivers/gpu/drm/i915/intel_wakeref.c   |  7 +++-
 drivers/gpu/drm/i915/intel_wakeref.h   | 38 --
 21 files changed, 177 insertions(+), 76 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
b/drivers/gpu/drm/i915/Kconfig.debug
index e2da6fb04438b9..d26fb4569873ea 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -40,6 +40,7 @@ config DRM_I915_DEBUG
select DRM_I915_DEBUG_GEM_ONCE
select DRM_I915_DEBUG_MMIO
select DRM_I915_DEBUG_RUNTIME_PM
+   select DRM_I915_DEBUG_WAKEREF
select DRM_I915_SW_FENCE_DEBUG_OBJECTS
select DRM_I915_SELFTEST
select BROKEN # for prototype uAPI
@@ -244,3 +245,17 @@ config DRM_I915_DEBUG_RUNTIME_PM
  Recommended for driver developers only.
 
  If in doubt, say "N"
+
+config DRM_I915_DEBUG_WAKEREF
+   bool "Enable extra tracking for wakerefs"
+   depends on DRM_I915
+   default n
+   select REF_TRACKER
+   select STACKDEPOT
+   select STACKTRACE
+   help
+ Choose this option to turn on extra state checking and usage
+ tracking for the wakerefPM functionality. This may introduce
+ overhead during driver runtime.
+
+ If in doubt, say "N"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 3aeede6aee4dcc..33a034a9c42f11 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -253,6 +253,7 @@ struct i915_execbuffer {
struct intel_gt *gt; /* gt for the execbuf */
struct intel_context *context; /* logical state for the request */
struct i915_gem_context *gem_context; /** caller's context */
+   intel_wakeref_t wakeref;
 
/** our requests to build */
struct i915_request *requests[MAX_ENGINE_INSTANCE + 1];
@@ -2709,7 +2710,7 @@ eb_select_engine(struct i915_execbuffer *eb)
 
for_each_child(ce, child)
intel_context_get(child);
-   intel_gt_pm_get(ce->engine->gt);
+   eb->wakeref = intel_gt_pm_get(ce->engine->gt);
 
if (!test_bit(CONTEXT_ALLOC_BIT, &ce->flags)) {
err = intel_context_alloc_state(ce);
@@ -2748,7 +2749,7 @@ eb_select_engine(struct i915_execbuffer *eb)
return err;
 
 err:
-   intel_gt_pm_put(ce->engine->gt);
+   intel_gt_pm_put(ce->engine->gt, eb->wakeref);
for_each_child(ce, child)
intel_context_put(child);
intel_context_put(ce);
@@ -2761,7 +2762,7 @@ eb_put_engine(struct i915_execbuffer *eb)
struct intel_context *child;
 
i915_vm_put(eb->context->vm);
-   intel_gt_pm_put(eb->gt);
+   intel_gt_pm_put(eb->context->engine->gt, eb->wakeref);
for_each_child(eb->context, child)
intel_context_put(child);
intel_context_put(eb->context);
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
index 3bef1beec7cbb5..3fd68a099a85ef 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_coherency.c
@@ -85,6 +85,7 @@ static int cpu_get(struct context *ctx, unsigned long offset, 
u32 *v)
 
 static int gtt_set(struct context *ctx, unsigned long offset, u32 v)
 {
+   intel_wakeref_t wakeref;
struct

[PATCH v5 5/8] drm/i915: Correct type of wakeref variable

Wakeref has dedicated type. Assumption it will be int
compatible forever is incorrect.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Andi Shyti 
---
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 88e881b100cf0a..74d28a3af2d57b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -3248,7 +3248,7 @@ static void destroyed_worker_func(struct work_struct *w)
struct intel_guc *guc = container_of(w, struct intel_guc,
 submission_state.destroyed_worker);
struct intel_gt *gt = guc_to_gt(guc);
-   int tmp;
+   intel_wakeref_t tmp;
 
with_intel_gt_pm(gt, tmp)
deregister_destroyed_contexts(guc);

-- 
2.34.1

[PATCH v5 6/8] drm/i915: Replace custom intel runtime_pm tracker with ref_tracker library

Beside reusing existing code, the main advantage of ref_tracker is
tracking per instance of wakeref. It allows also to catch double
put.
On the other side we lose information about the first acquire and
the last release, but the advantages outweigh it.

Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/Kconfig.debug |   4 +
 drivers/gpu/drm/i915/display/intel_display_power.c |   2 +-
 drivers/gpu/drm/i915/i915_driver.c |   2 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c| 221 ++---
 drivers/gpu/drm/i915/intel_runtime_pm.h|  11 +-
 drivers/gpu/drm/i915/intel_wakeref.h   |  61 +-
 6 files changed, 84 insertions(+), 217 deletions(-)

diff --git a/drivers/gpu/drm/i915/Kconfig.debug 
b/drivers/gpu/drm/i915/Kconfig.debug
index 93dfb7ed970547..e2da6fb04438b9 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -24,7 +24,9 @@ config DRM_I915_DEBUG
select DEBUG_FS
select PREEMPT_COUNT
select I2C_CHARDEV
+   select REF_TRACKER
select STACKDEPOT
+   select STACKTRACE
select DRM_DP_AUX_CHARDEV
select X86_MSR # used by igt/pm_rpm
select DRM_VGEM # used by igt/prime_vgem (dmabuf interop checks)
@@ -231,7 +233,9 @@ config DRM_I915_DEBUG_RUNTIME_PM
bool "Enable extra state checking for runtime PM"
depends on DRM_I915
default n
+   select REF_TRACKER
select STACKDEPOT
+   select STACKTRACE
help
  Choose this option to turn on extra state checking for the
  runtime PM functionality. This may introduce overhead during
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
b/drivers/gpu/drm/i915/display/intel_display_power.c
index f86060195987cb..e388d41e403f4f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -404,7 +404,7 @@ print_async_put_domains_state(struct i915_power_domains 
*power_domains)
 struct drm_i915_private,
 display.power.domains);
 
-   drm_dbg(&i915->drm, "async_put_wakeref %u\n",
+   drm_dbg(&i915->drm, "async_put_wakeref %lu\n",
power_domains->async_put_wakeref);
 
print_power_domains(power_domains, "async_put_domains[0]",
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index da249337c23bdd..1e9d51ef4062be 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1024,7 +1024,7 @@ void i915_driver_shutdown(struct drm_i915_private *i915)
intel_power_domains_driver_remove(i915);
enable_rpm_wakeref_asserts(&i915->runtime_pm);
 
-   intel_runtime_pm_driver_release(&i915->runtime_pm);
+   intel_runtime_pm_driver_last_release(&i915->runtime_pm);
 }
 
 static bool suspend_to_idle(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c 
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index cf5122299b6b8c..c5785ddaa717e4 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -52,182 +52,37 @@
 
 #if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
 
-#include 
-
-#define STACKDEPTH 8
-
-static noinline depot_stack_handle_t __save_depot_stack(void)
-{
-   unsigned long entries[STACKDEPTH];
-   unsigned int n;
-
-   n = stack_trace_save(entries, ARRAY_SIZE(entries), 1);
-   return stack_depot_save(entries, n, GFP_NOWAIT | __GFP_NOWARN);
-}
-
 static void init_intel_runtime_pm_wakeref(struct intel_runtime_pm *rpm)
 {
-   spin_lock_init(&rpm->debug.lock);
-   stack_depot_init();
+   ref_tracker_dir_init(&rpm->debug, INTEL_REFTRACK_DEAD_COUNT, 
dev_name(rpm->kdev));
 }
 
-static noinline depot_stack_handle_t
+static intel_wakeref_t
 track_intel_runtime_pm_wakeref(struct intel_runtime_pm *rpm)
 {
-   depot_stack_handle_t stack, *stacks;
-   unsigned long flags;
-
-   if (rpm->no_wakeref_tracking)
-   return -1;
-
-   stack = __save_depot_stack();
-   if (!stack)
+   if (!rpm->available || rpm->no_wakeref_tracking)
return -1;
 
-   spin_lock_irqsave(&rpm->debug.lock, flags);
-
-   if (!rpm->debug.count)
-   rpm->debug.last_acquire = stack;
-
-   stacks = krealloc(rpm->debug.owners,
- (rpm->debug.count + 1) * sizeof(*stacks),
- GFP_NOWAIT | __GFP_NOWARN);
-   if (stacks) {
-   stacks[rpm->debug.count++] = stack;
-   rpm->debug.owners = stacks;
-   } else {
-   stack = -1;
-   }
-
-   spin_unlock_irqrestore(&rpm->debug.lock, flags);
-
-   return stack;
+   return intel_ref_tracker_alloc(&rpm->debug);
 }
 
 static void untrack_intel_runtime_pm_wakeref(struct intel_runtime_pm *rpm,
-

[PATCH v5 3/8] lib/ref_tracker: add printing to memory buffer

Similar to stack_(depot|trace)_snprint the patch
adds helper to printing stats to memory buffer.
It will be helpful in case of debugfs.

Signed-off-by: Andrzej Hajda 
---
 include/linux/ref_tracker.h |  8 +++
 lib/ref_tracker.c   | 56 ++---
 2 files changed, 56 insertions(+), 8 deletions(-)

diff --git a/include/linux/ref_tracker.h b/include/linux/ref_tracker.h
index fc9ef9952f01fd..4cd260efc4023f 100644
--- a/include/linux/ref_tracker.h
+++ b/include/linux/ref_tracker.h
@@ -50,6 +50,8 @@ void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
 void ref_tracker_dir_print(struct ref_tracker_dir *dir,
   unsigned int display_limit);
 
+int ref_tracker_dir_snprint(struct ref_tracker_dir *dir, char *buf, size_t 
size);
+
 int ref_tracker_alloc(struct ref_tracker_dir *dir,
  struct ref_tracker **trackerp, gfp_t gfp);
 
@@ -78,6 +80,12 @@ static inline void ref_tracker_dir_print(struct 
ref_tracker_dir *dir,
 {
 }
 
+static inline int ref_tracker_dir_snprint(struct ref_tracker_dir *dir,
+ char *buf, size_t size)
+{
+   return 0;
+}
+
 static inline int ref_tracker_alloc(struct ref_tracker_dir *dir,
struct ref_tracker **trackerp,
gfp_t gfp)
diff --git a/lib/ref_tracker.c b/lib/ref_tracker.c
index 2ffe79c90c1771..cce4614b07940f 100644
--- a/lib/ref_tracker.c
+++ b/lib/ref_tracker.c
@@ -62,8 +62,27 @@ ref_tracker_get_stats(struct ref_tracker_dir *dir, unsigned 
int limit)
return stats;
 }
 
-void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
- unsigned int display_limit)
+struct ostream {
+   char *buf;
+   int size, used;
+};
+
+#define pr_ostream(stream, fmt, args...) \
+({ \
+   struct ostream *_s = (stream); \
+\
+   if (!_s->buf) { \
+   pr_err(fmt, ##args); \
+   } else { \
+   int ret, len = _s->size - _s->used; \
+   ret = snprintf(_s->buf + _s->used, len, pr_fmt(fmt), ##args); \
+   _s->used += min(ret, len); \
+   } \
+})
+
+static void
+__ref_tracker_dir_pr_ostream(struct ref_tracker_dir *dir,
+unsigned int display_limit, struct ostream *s)
 {
struct ref_tracker_dir_stats *stats;
unsigned int i = 0, skipped;
@@ -77,8 +96,8 @@ void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
 
stats = ref_tracker_get_stats(dir, display_limit);
if (IS_ERR(stats)) {
-   pr_err("%s@%pK: couldn't get stats, error %pe\n",
-  dir->name, dir, stats);
+   pr_ostream(s, "%s@%pK: couldn't get stats, error %pe\n",
+  dir->name, dir, stats);
return;
}
 
@@ -88,19 +107,27 @@ void ref_tracker_dir_print_locked(struct ref_tracker_dir 
*dir,
stack = stats->stacks[i].stack_handle;
if (sbuf && !stack_depot_snprint(stack, sbuf, STACK_BUF_SIZE, 
4))
sbuf[0] = 0;
-   pr_err("%s@%pK has %d/%d users at\n%s\n", dir->name, dir,
-  stats->stacks[i].count, stats->total, sbuf);
+   pr_ostream(s, "%s@%pK has %d/%d users at\n%s\n", dir->name, dir,
+  stats->stacks[i].count, stats->total, sbuf);
skipped -= stats->stacks[i].count;
}
 
if (skipped)
-   pr_err("%s@%pK skipped reports about %d/%d users.\n",
-  dir->name, dir, skipped, stats->total);
+   pr_ostream(s, "%s@%pK skipped reports about %d/%d users.\n",
+  dir->name, dir, skipped, stats->total);
 
kfree(sbuf);
 
kfree(stats);
 }
+
+void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
+ unsigned int display_limit)
+{
+   struct ostream os = {};
+
+   __ref_tracker_dir_pr_ostream(dir, display_limit, &os);
+}
 EXPORT_SYMBOL(ref_tracker_dir_print_locked);
 
 void ref_tracker_dir_print(struct ref_tracker_dir *dir,
@@ -114,6 +141,19 @@ void ref_tracker_dir_print(struct ref_tracker_dir *dir,
 }
 EXPORT_SYMBOL(ref_tracker_dir_print);
 
+int ref_tracker_dir_snprint(struct ref_tracker_dir *dir, char *buf, size_t 
size)
+{
+   struct ostream os = { .buf = buf, .size = size };
+   unsigned long flags;
+
+   spin_lock_irqsave(&dir->lock, flags);
+   __ref_tracker_dir_pr_ostream(dir, 16, &os);
+   spin_unlock_irqrestore(&dir->lock, flags);
+
+   return os.used;
+}
+EXPORT_SYMBOL(ref_tracker_dir_snprint);
+
 void ref_tracker_dir_exit(struct ref_tracker_dir *dir)
 {
struct ref_tracker *tracker, *n;

-- 
2.34.1

[PATCH v5 1/8] lib/ref_tracker: add unlocked leak print helper

To have reliable detection of leaks, caller must be able to check under the same
lock both: tracked counter and the leaks. dir.lock is natural candidate for such
lock and unlocked print helper can be called with this lock taken.
As a bonus we can reuse this helper in ref_tracker_dir_exit.

Signed-off-by: Andrzej Hajda 
---
 include/linux/ref_tracker.h |  8 ++
 lib/ref_tracker.c   | 66 ++---
 2 files changed, 46 insertions(+), 28 deletions(-)

diff --git a/include/linux/ref_tracker.h b/include/linux/ref_tracker.h
index 9ca353ab712b5e..87a92f2bec1b88 100644
--- a/include/linux/ref_tracker.h
+++ b/include/linux/ref_tracker.h
@@ -36,6 +36,9 @@ static inline void ref_tracker_dir_init(struct 
ref_tracker_dir *dir,
 
 void ref_tracker_dir_exit(struct ref_tracker_dir *dir);
 
+void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
+ unsigned int display_limit);
+
 void ref_tracker_dir_print(struct ref_tracker_dir *dir,
   unsigned int display_limit);
 
@@ -56,6 +59,11 @@ static inline void ref_tracker_dir_exit(struct 
ref_tracker_dir *dir)
 {
 }
 
+static inline void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
+   unsigned int display_limit)
+{
+}
+
 static inline void ref_tracker_dir_print(struct ref_tracker_dir *dir,
 unsigned int display_limit)
 {
diff --git a/lib/ref_tracker.c b/lib/ref_tracker.c
index dc7b14aa3431e2..d4eb0929af8f96 100644
--- a/lib/ref_tracker.c
+++ b/lib/ref_tracker.c
@@ -14,6 +14,38 @@ struct ref_tracker {
depot_stack_handle_tfree_stack_handle;
 };
 
+void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
+ unsigned int display_limit)
+{
+   struct ref_tracker *tracker;
+   unsigned int i = 0;
+
+   lockdep_assert_held(&dir->lock);
+
+   list_for_each_entry(tracker, &dir->list, head) {
+   if (i < display_limit) {
+   pr_err("leaked reference.\n");
+   if (tracker->alloc_stack_handle)
+   stack_depot_print(tracker->alloc_stack_handle);
+   i++;
+   } else {
+   break;
+   }
+   }
+}
+EXPORT_SYMBOL(ref_tracker_dir_print_locked);
+
+void ref_tracker_dir_print(struct ref_tracker_dir *dir,
+  unsigned int display_limit)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(&dir->lock, flags);
+   ref_tracker_dir_print_locked(dir, display_limit);
+   spin_unlock_irqrestore(&dir->lock, flags);
+}
+EXPORT_SYMBOL(ref_tracker_dir_print);
+
 void ref_tracker_dir_exit(struct ref_tracker_dir *dir)
 {
struct ref_tracker *tracker, *n;
@@ -27,13 +59,13 @@ void ref_tracker_dir_exit(struct ref_tracker_dir *dir)
kfree(tracker);
dir->quarantine_avail++;
}
-   list_for_each_entry_safe(tracker, n, &dir->list, head) {
-   pr_err("leaked reference.\n");
-   if (tracker->alloc_stack_handle)
-   stack_depot_print(tracker->alloc_stack_handle);
+   if (!list_empty(&dir->list)) {
+   ref_tracker_dir_print_locked(dir, 16);
leak = true;
-   list_del(&tracker->head);
-   kfree(tracker);
+   list_for_each_entry_safe(tracker, n, &dir->list, head) {
+   list_del(&tracker->head);
+   kfree(tracker);
+   }
}
spin_unlock_irqrestore(&dir->lock, flags);
WARN_ON_ONCE(leak);
@@ -42,28 +74,6 @@ void ref_tracker_dir_exit(struct ref_tracker_dir *dir)
 }
 EXPORT_SYMBOL(ref_tracker_dir_exit);
 
-void ref_tracker_dir_print(struct ref_tracker_dir *dir,
-  unsigned int display_limit)
-{
-   struct ref_tracker *tracker;
-   unsigned long flags;
-   unsigned int i = 0;
-
-   spin_lock_irqsave(&dir->lock, flags);
-   list_for_each_entry(tracker, &dir->list, head) {
-   if (i < display_limit) {
-   pr_err("leaked reference.\n");
-   if (tracker->alloc_stack_handle)
-   stack_depot_print(tracker->alloc_stack_handle);
-   i++;
-   } else {
-   break;
-   }
-   }
-   spin_unlock_irqrestore(&dir->lock, flags);
-}
-EXPORT_SYMBOL(ref_tracker_dir_print);
-
 int ref_tracker_alloc(struct ref_tracker_dir *dir,
  struct ref_tracker **trackerp,
  gfp_t gfp)

-- 
2.34.1

[PATCH v5 4/8] lib/ref_tracker: remove warnings in case of allocation failure

Library can handle allocation failures. To avoid allocation warnings
__GFP_NOWARN has been added everywhere. Moreover GFP_ATOMIC has been
replaced with GFP_NOWAIT in case of stack allocation on tracker free
call.

Signed-off-by: Andrzej Hajda 
Reviewed-by: Andi Shyti 
---
 lib/ref_tracker.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/ref_tracker.c b/lib/ref_tracker.c
index cce4614b07940f..cf5609b1ca7936 100644
--- a/lib/ref_tracker.c
+++ b/lib/ref_tracker.c
@@ -189,7 +189,7 @@ int ref_tracker_alloc(struct ref_tracker_dir *dir,
unsigned long entries[REF_TRACKER_STACK_ENTRIES];
struct ref_tracker *tracker;
unsigned int nr_entries;
-   gfp_t gfp_mask = gfp;
+   gfp_t gfp_mask = gfp | __GFP_NOWARN;
unsigned long flags;
 
WARN_ON_ONCE(dir->dead);
@@ -237,7 +237,8 @@ int ref_tracker_free(struct ref_tracker_dir *dir,
return -EEXIST;
}
nr_entries = stack_trace_save(entries, ARRAY_SIZE(entries), 1);
-   stack_handle = stack_depot_save(entries, nr_entries, GFP_ATOMIC);
+   stack_handle = stack_depot_save(entries, nr_entries,
+   GFP_NOWAIT | __GFP_NOWARN);
 
spin_lock_irqsave(&dir->lock, flags);
if (tracker->dead) {

-- 
2.34.1

[PATCH v5 2/8] lib/ref_tracker: improve printing stats

In case the library is tracking busy subsystem, simply
printing stack for every active reference will spam log
with long, hard to read, redundant stack traces. To improve
readabilty following changes have been made:
- reports are printed per stack_handle - log is more compact,
- added display name for ref_tracker_dir - it will differentiate
  multiple subsystems,
- stack trace is printed indented, in the same printk call,
- info about dropped references is printed as well.

Signed-off-by: Andrzej Hajda 
---
 include/linux/ref_tracker.h | 15 ++--
 lib/ref_tracker.c   | 90 +++--
 2 files changed, 91 insertions(+), 14 deletions(-)

diff --git a/include/linux/ref_tracker.h b/include/linux/ref_tracker.h
index 87a92f2bec1b88..fc9ef9952f01fd 100644
--- a/include/linux/ref_tracker.h
+++ b/include/linux/ref_tracker.h
@@ -17,12 +17,19 @@ struct ref_tracker_dir {
booldead;
struct list_headlist; /* List of active trackers */
struct list_headquarantine; /* List of dead trackers */
+   charname[32];
 #endif
 };
 
 #ifdef CONFIG_REF_TRACKER
-static inline void ref_tracker_dir_init(struct ref_tracker_dir *dir,
-   unsigned int quarantine_count)
+
+/* Temporary allow two and three arguments, until consumers are converted */
+#define ref_tracker_dir_init(_d, _q, args...) _ref_tracker_dir_init(_d, _q, 
##args, #_d)
+#define _ref_tracker_dir_init(_d, _q, _n, ...) __ref_tracker_dir_init(_d, _q, 
_n)
+
+static inline void __ref_tracker_dir_init(struct ref_tracker_dir *dir,
+   unsigned int quarantine_count,
+   const char *name)
 {
INIT_LIST_HEAD(&dir->list);
INIT_LIST_HEAD(&dir->quarantine);
@@ -31,6 +38,7 @@ static inline void ref_tracker_dir_init(struct 
ref_tracker_dir *dir,
dir->dead = false;
refcount_set(&dir->untracked, 1);
refcount_set(&dir->no_tracker, 1);
+   strlcpy(dir->name, name, sizeof(dir->name));
stack_depot_init();
 }
 
@@ -51,7 +59,8 @@ int ref_tracker_free(struct ref_tracker_dir *dir,
 #else /* CONFIG_REF_TRACKER */
 
 static inline void ref_tracker_dir_init(struct ref_tracker_dir *dir,
-   unsigned int quarantine_count)
+   unsigned int quarantine_count,
+   ...)
 {
 }
 
diff --git a/lib/ref_tracker.c b/lib/ref_tracker.c
index d4eb0929af8f96..2ffe79c90c1771 100644
--- a/lib/ref_tracker.c
+++ b/lib/ref_tracker.c
@@ -1,11 +1,16 @@
 // SPDX-License-Identifier: GPL-2.0-or-later
+
+#define pr_fmt(fmt) "ref_tracker: " fmt
+
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 
 #define REF_TRACKER_STACK_ENTRIES 16
+#define STACK_BUF_SIZE 1024
 
 struct ref_tracker {
struct list_headhead;   /* anchor into dir->list or 
dir->quarantine */
@@ -14,24 +19,87 @@ struct ref_tracker {
depot_stack_handle_tfree_stack_handle;
 };
 
-void ref_tracker_dir_print_locked(struct ref_tracker_dir *dir,
- unsigned int display_limit)
+struct ref_tracker_dir_stats {
+   int total;
+   int count;
+   struct {
+   depot_stack_handle_t stack_handle;
+   unsigned int count;
+   } stacks[];
+};
+
+static struct ref_tracker_dir_stats *
+ref_tracker_get_stats(struct ref_tracker_dir *dir, unsigned int limit)
 {
+   struct ref_tracker_dir_stats *stats;
struct ref_tracker *tracker;
-   unsigned int i = 0;
 
-   lockdep_assert_held(&dir->lock);
+   stats = kmalloc(struct_size(stats, stacks, limit),
+   GFP_NOWAIT | __GFP_NOWARN);
+   if (!stats)
+   return ERR_PTR(-ENOMEM);
+   stats->total = 0;
+   stats->count = 0;
 
list_for_each_entry(tracker, &dir->list, head) {
-   if (i < display_limit) {
-   pr_err("leaked reference.\n");
-   if (tracker->alloc_stack_handle)
-   stack_depot_print(tracker->alloc_stack_handle);
-   i++;
-   } else {
-   break;
+   depot_stack_handle_t stack = tracker->alloc_stack_handle;
+   int i;
+
+   ++stats->total;
+   for (i = 0; i < stats->count; ++i)
+   if (stats->stacks[i].stack_handle == stack)
+   break;
+   if (i >= limit)
+   continue;
+   if (i >= stats->count) {
+   stats->stacks[i].stack_handle = stack;
+   stats->stacks[i].count = 0;
+   ++stats->count;
}
+   ++stats->stacks[i].count;
+   }
+
+   return stats;
+}
+
+void ref_tracker_dir_print_locked(struct ref_t

[PATCH v5 0/8] drm/i915: use ref_tracker library for tracking wakerefs

Gently ping for network developers, could you look at ref_tracker patches,
as the ref_tracker library was developed for network.

This is revived patchset improving ref_tracker library and converting
i915 internal tracker to ref_tracker.
The old thread ended without consensus about small kernel allocations,
which are performed under spinlock.
I have tried to solve the problem by splitting the calls, but it results
in complicated API, so I went back to original solution.
If there are better solutions I am glad to discuss them.
Meanwhile I send original patchset with addressed remaining comments.

To: Jani Nikula 
To: Joonas Lahtinen 
To: Rodrigo Vivi 
To: Tvrtko Ursulin 
To: David Airlie 
To: Daniel Vetter 
Cc: linux-ker...@vger.kernel.org
Cc: intel-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: Chris Wilson 
Cc: net...@vger.kernel.org
Cc: Eric Dumazet 
Cc: Jakub Kicinski 
Cc: Dmitry Vyukov 
Cc: "David S. Miller" 
Signed-off-by: Andrzej Hajda 

---
Changes in v5 (thx Andi for review):
- use *_locked convention instead of __*,
- improved commit messages,
- re-worked i915 patches, squashed separation and conversion patches,
- added tags,
- Link to v4: 
https://lore.kernel.org/r/20230224-track_gt-v4-0-464e8ab4c...@intel.com

Changes in v4:
- split "Separate wakeref tracking" to smaller parts
- fixed typos,
- Link to v1-v3: https://patchwork.freedesktop.org/series/100327/

---
Andrzej Hajda (7):
  lib/ref_tracker: add unlocked leak print helper
  lib/ref_tracker: improve printing stats
  lib/ref_tracker: add printing to memory buffer
  lib/ref_tracker: remove warnings in case of allocation failure
  drm/i915: Correct type of wakeref variable
  drm/i915: Replace custom intel runtime_pm tracker with ref_tracker library
  drm/i915: track gt pm wakerefs

Chris Wilson (1):
  drm/i915/gt: Hold a wakeref for the active VM

 drivers/gpu/drm/i915/Kconfig.debug |  19 ++
 drivers/gpu/drm/i915/display/intel_display_power.c |   2 +-
 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c |   7 +-
 .../drm/i915/gem/selftests/i915_gem_coherency.c|  10 +-
 drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c |  14 +-
 drivers/gpu/drm/i915/gt/intel_breadcrumbs.c|  13 +-
 drivers/gpu/drm/i915/gt/intel_breadcrumbs_types.h  |   3 +-
 drivers/gpu/drm/i915/gt/intel_context.h|  15 +-
 drivers/gpu/drm/i915/gt/intel_context_types.h  |   2 +
 drivers/gpu/drm/i915/gt/intel_engine_pm.c  |  10 +-
 drivers/gpu/drm/i915/gt/intel_engine_types.h   |   2 +
 .../gpu/drm/i915/gt/intel_execlists_submission.c   |   2 +-
 drivers/gpu/drm/i915/gt/intel_gt_pm.c  |  12 +-
 drivers/gpu/drm/i915/gt/intel_gt_pm.h  |  38 +++-
 drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c  |   4 +-
 drivers/gpu/drm/i915/gt/selftest_engine_cs.c   |  20 +-
 drivers/gpu/drm/i915/gt/selftest_gt_pm.c   |   5 +-
 drivers/gpu/drm/i915/gt/selftest_reset.c   |  10 +-
 drivers/gpu/drm/i915/gt/selftest_rps.c |  17 +-
 drivers/gpu/drm/i915/gt/selftest_slpc.c|   5 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c  |  11 +-
 drivers/gpu/drm/i915/i915_driver.c |   2 +-
 drivers/gpu/drm/i915/i915_pmu.c|  16 +-
 drivers/gpu/drm/i915/intel_runtime_pm.c| 221 ++---
 drivers/gpu/drm/i915/intel_runtime_pm.h|  11 +-
 drivers/gpu/drm/i915/intel_wakeref.c   |   7 +-
 drivers/gpu/drm/i915/intel_wakeref.h   |  99 -
 include/linux/ref_tracker.h|  31 ++-
 lib/ref_tracker.c  | 179 ++---
 29 files changed, 456 insertions(+), 331 deletions(-)
---
base-commit: c6137ecf40b2dc5bdf1ed8928122b700bfc91fea
change-id: 20230224-track_gt-1b3da8bdacd7

Best regards,
-- 
Andrzej Hajda

Re: [PATCH v10 09/15] drm/syncobj: Add deadline support for syncobj waits

2023-03-28 Thread Tvrtko Ursulin




On 08/03/2023 15:53, Rob Clark wrote:

From: Rob Clark 

Add a new flag to let userspace provide a deadline as a hint for syncobj
and timeline waits.  This gives a hint to the driver signaling the
backing fences about how soon userspace needs it to compete work, so it
can addjust GPU frequency accordingly.  An immediate deadline can be


adjust


given to provide something equivalent to i915 "wait boost".

v2: Use absolute u64 ns value for deadline hint, drop cap and driver
 feature flag in favor of allowing count_handles==0 as a way for
 userspace to probe kernel for support of new flag
v3: More verbose comments about UAPI

Signed-off-by: Rob Clark 
---
  drivers/gpu/drm/drm_syncobj.c | 64 ---
  include/uapi/drm/drm.h| 17 ++
  2 files changed, 68 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 0c2be8360525..a85e9464f07b 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -126,6 +126,11 @@
   * synchronize between the two.
   * This requirement is inherited from the Vulkan fence API.
   *
+ * If &DRM_SYNCOBJ_WAIT_FLAGS_WAIT_DEADLINE is set, the ioctl will also set
+ * a fence deadline hint on the backing fences before waiting, to provide the
+ * fence signaler with an appropriate sense of urgency.  The deadline is
+ * specified as an absolute &CLOCK_MONOTONIC value in units of ns.
+ *
   * Similarly, &DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT takes an array of syncobj
   * handles as well as an array of u64 points and does a host-side wait on all
   * of syncobj fences at the given points simultaneously.
@@ -973,7 +978,8 @@ static signed long drm_syncobj_array_wait_timeout(struct 
drm_syncobj **syncobjs,
  uint32_t count,
  uint32_t flags,
  signed long timeout,
- uint32_t *idx)
+ uint32_t *idx,
+ ktime_t *deadline)
  {
struct syncobj_wait_entry *entries;
struct dma_fence *fence;
@@ -1053,6 +1059,15 @@ static signed long drm_syncobj_array_wait_timeout(struct 
drm_syncobj **syncobjs,
drm_syncobj_fence_add_wait(syncobjs[i], &entries[i]);
}
  
+	if (deadline) {

+   for (i = 0; i < count; ++i) {
+   fence = entries[i].fence;
+   if (!fence)
+   continue;
+   dma_fence_set_deadline(fence, *deadline);
+   }
+   }
+
do {
set_current_state(TASK_INTERRUPTIBLE);
  
@@ -1151,7 +1166,8 @@ static int drm_syncobj_array_wait(struct drm_device *dev,

  struct drm_file *file_private,
  struct drm_syncobj_wait *wait,
  struct drm_syncobj_timeline_wait 
*timeline_wait,
- struct drm_syncobj **syncobjs, bool timeline)
+ struct drm_syncobj **syncobjs, bool timeline,
+ ktime_t *deadline)
  {
signed long timeout = 0;
uint32_t first = ~0;
@@ -1162,7 +1178,8 @@ static int drm_syncobj_array_wait(struct drm_device *dev,
 NULL,
 wait->count_handles,
 wait->flags,
-timeout, &first);
+timeout, &first,
+deadline);
if (timeout < 0)
return timeout;
wait->first_signaled = first;
@@ -1172,7 +1189,8 @@ static int drm_syncobj_array_wait(struct drm_device *dev,
 
u64_to_user_ptr(timeline_wait->points),
 
timeline_wait->count_handles,
 timeline_wait->flags,
-timeout, &first);
+timeout, &first,
+deadline);
if (timeout < 0)
return timeout;
timeline_wait->first_signaled = first;
@@ -1243,17 +1261,22 @@ drm_syncobj_wait_ioctl(struct drm_device *dev, void 
*data,
  {
struct drm_syncobj_wait *args = data;
struct drm_syncobj **syncobjs;
+   unsigned possible_flags;
+   ktime_t t, *tp = NULL;
int ret = 0;
  
  	if (!drm_core_check_feature(d

Re: [PATCH v10 07/15] dma-buf/sw_sync: Add fence deadline support

2023-03-28 Thread Tvrtko Ursulin




On 08/03/2023 15:52, Rob Clark wrote:

From: Rob Clark 

This consists of simply storing the most recent deadline, and adding an
ioctl to retrieve the deadline.  This can be used in conjunction with
the SET_DEADLINE ioctl on a fence fd for testing.  Ie. create various
sw_sync fences, merge them into a fence-array, set deadline on the
fence-array and confirm that it is propagated properly to each fence.

v2: Switch UABI to express deadline as u64
v3: More verbose UAPI docs, show how to convert from timespec
v4: Better comments, track the soonest deadline, as a normal fence
 implementation would, return an error if no deadline set.

Signed-off-by: Rob Clark 
Reviewed-by: Christian König 
Acked-by: Pekka Paalanen 
---
  drivers/dma-buf/sw_sync.c| 81 
  drivers/dma-buf/sync_debug.h |  2 +
  2 files changed, 83 insertions(+)

diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index 348b3a9170fa..f53071bca3af 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -52,12 +52,33 @@ struct sw_sync_create_fence_data {
__s32   fence; /* fd of new fence */
  };
  
+/**

+ * struct sw_sync_get_deadline - get the deadline hint of a sw_sync fence
+ * @deadline_ns: absolute time of the deadline
+ * @pad:   must be zero
+ * @fence_fd:  the sw_sync fence fd (in)
+ *
+ * Return the earliest deadline set on the fence.  The timebase for the
+ * deadline is CLOCK_MONOTONIC (same as vblank).  If there is no deadline


Mentioning vblank reads odd since this is drivers/dma-buf/. Dunno.


+ * set on the fence, this ioctl will return -ENOENT.
+ */
+struct sw_sync_get_deadline {
+   __u64   deadline_ns;
+   __u32   pad;
+   __s32   fence_fd;
+};
+
  #define SW_SYNC_IOC_MAGIC 'W'
  
  #define SW_SYNC_IOC_CREATE_FENCE	_IOWR(SW_SYNC_IOC_MAGIC, 0,\

struct sw_sync_create_fence_data)
  
  #define SW_SYNC_IOC_INC			_IOW(SW_SYNC_IOC_MAGIC, 1, __u32)

+#define SW_SYNC_GET_DEADLINE   _IOWR(SW_SYNC_IOC_MAGIC, 2, \
+   struct sw_sync_get_deadline)
+
+
+#define SW_SYNC_HAS_DEADLINE_BIT   DMA_FENCE_FLAG_USER_BITS
  
  static const struct dma_fence_ops timeline_fence_ops;
  
@@ -171,6 +192,22 @@ static void timeline_fence_timeline_value_str(struct dma_fence *fence,

snprintf(str, size, "%d", parent->value);
  }
  
+static void timeline_fence_set_deadline(struct dma_fence *fence, ktime_t deadline)

+{
+   struct sync_pt *pt = dma_fence_to_sync_pt(fence);
+   unsigned long flags;
+
+   spin_lock_irqsave(fence->lock, flags);
+   if (test_bit(SW_SYNC_HAS_DEADLINE_BIT, &fence->flags)) {
+   if (ktime_before(deadline, pt->deadline))
+   pt->deadline = deadline;
+   } else {
+   pt->deadline = deadline;
+   set_bit(SW_SYNC_HAS_DEADLINE_BIT, &fence->flags);


FWIW could use __set_bit to avoid needless atomic under spinlock.


+   }
+   spin_unlock_irqrestore(fence->lock, flags);
+}
+
  static const struct dma_fence_ops timeline_fence_ops = {
.get_driver_name = timeline_fence_get_driver_name,
.get_timeline_name = timeline_fence_get_timeline_name,
@@ -179,6 +216,7 @@ static const struct dma_fence_ops timeline_fence_ops = {
.release = timeline_fence_release,
.fence_value_str = timeline_fence_value_str,
.timeline_value_str = timeline_fence_timeline_value_str,
+   .set_deadline = timeline_fence_set_deadline,
  };
  
  /**

@@ -387,6 +425,46 @@ static long sw_sync_ioctl_inc(struct sync_timeline *obj, 
unsigned long arg)
return 0;
  }
  
+static int sw_sync_ioctl_get_deadline(struct sync_timeline *obj, unsigned long arg)

+{
+   struct sw_sync_get_deadline data;
+   struct dma_fence *fence;
+   struct sync_pt *pt;
+   int ret = 0;
+
+   if (copy_from_user(&data, (void __user *)arg, sizeof(data)))
+   return -EFAULT;
+
+   if (data.deadline_ns || data.pad)
+   return -EINVAL;
+
+   fence = sync_file_get_fence(data.fence_fd);
+   if (!fence)
+   return -EINVAL;
+
+   pt = dma_fence_to_sync_pt(fence);
+   if (!pt)
+   return -EINVAL;
+
+   spin_lock(fence->lock);


This may need to be _irq.


+   if (test_bit(SW_SYNC_HAS_DEADLINE_BIT, &fence->flags)) {
+   data.deadline_ns = ktime_to_ns(pt->deadline);
+   } else {
+   ret = -ENOENT;
+   }
+   spin_unlock(fence->lock);
+
+   dma_fence_put(fence);
+
+   if (ret)
+   return ret;
+
+   if (copy_to_user((void __user *)arg, &data, sizeof(data)))
+   return -EFAULT;
+
+   return 0;
+}
+
  static long sw_sync_ioctl(struct file *file, unsigned int cmd,
  unsigned long arg)
  {
@@ -399,6 +477,9 @@ static long sw_sync_ioctl(struct file *file, unsigned int 
cmd,
case SW_SYNC_IOC_INC:
return sw_sync_ioctl_inc(obj, arg);

Re: [PATCH v7 32/32] drm/msm/dpu: remove unused dpu_plane_validate_multirect_v2 function


On 16/03/2023 18:16, Dmitry Baryshkov wrote:

From: Abhinav Kumar 

After cleaning up the older multirect support the function
dpu_plane_validate_multirect_v2() is unused. Lets remove it.

Signed-off-by: Abhinav Kumar 
[DB: also drop struct dpu_multirect_plane_states and R0/R1/R_MAX]
Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 118 --
  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h |  17 
  2 files changed, 135 deletions(-)


For the sake of completeness:
Reviewed-by: Dmitry Baryshkov 

--
With best wishes
Dmitry

Re: [PATCH v7 31/32] drm/msm/dpu: log the multirect_index in _dpu_crtc_blend_setup_pipe


On 16/03/2023 18:16, Dmitry Baryshkov wrote:

From: Abhinav Kumar 

Lets print the multirect_index as well in _dpu_crtc_blend_setup_pipe()
as it will give the complete information of the sw_pipe as well.

Signed-off-by: Abhinav Kumar 


For the sake of completeness:
Reviewed-by: Dmitry Baryshkov 


Signed-off-by: Dmitry Baryshkov 
---
  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 90b406e409d3..508e5b950e52 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -426,12 +426,13 @@ static void _dpu_crtc_blend_setup_pipe(struct drm_crtc 
*crtc,
   format->base.pixel_format,
   modifier);
  
-	DRM_DEBUG_ATOMIC("crtc %d stage:%d - plane %d sspp %d fb %d\n",

+   DRM_DEBUG_ATOMIC("crtc %d stage:%d - plane %d sspp %d fb %d multirect_idx 
%d\n",
 crtc->base.id,
 stage,
 plane->base.id,
 sspp_idx - SSPP_NONE,
-state->fb ? state->fb->base.id : -1);
+state->fb ? state->fb->base.id : -1,
+pipe->multirect_index);
  
  	stage_cfg->stage[stage][stage_idx] = sspp_idx;

stage_cfg->multirect_index[stage][stage_idx] = pipe->multirect_index;


--
With best wishes
Dmitry

Re: [PATCH 0/7] Enable YCbCr420 format for VDSC

On Tue, 28 Mar 2023 at 16:20, Kandpal, Suraj  wrote:
> > -Original Message-
> > From: dri-devel  On Behalf Of Jani
> > Nikula
> > Sent: Wednesday, March 8, 2023 5:00 PM
> > To: Kandpal, Suraj ; dri-
> > de...@lists.freedesktop.org; intel-...@lists.freedesktop.org
> > Cc: Dmitry Baryshkov ; Nautiyal, Ankit K
> > ; Shankar, Uma ;
> > Kandpal, Suraj 
> > Subject: Re: [PATCH 0/7] Enable YCbCr420 format for VDSC
> >
> > On Wed, 22 Feb 2023, Suraj Kandpal  wrote:
> > > This patch series aims to enable the YCbCr420 format for DSC. Changes
> > > are mostly compute params related for hdmi,dp and dsi along with the
> > > addition of new rc_tables for native_420 and corresponding changes to
> > > macros used to fetch them.
> > > There have been discussions prior to this series in which some patches
> > > have gotten rb and can be found in the below link
> > > https://patchwork.freedesktop.org/series/113729
> >
> > I think it would be useful to get [1] from Dmitry merged to drm-misc-next
> > first, have that in drm-next, and again backmerged to drm-intel-next before
> > this. At least patches 1-5.
> >
> > There's not much point in all drivers duplicating the parameters, and we
> > need to move towards common code. Dmitry has been helpful in
> > contributing this to us.
> >
> > BR,
> > Jani.
> >
> >
>
> Hi Jani,
> Maarten has acked the patch series to be merged through drm-intel and in the 
> meantime
> I will work with Dmitry to pull the common code to avoid duplication

Thank you! If necessary feel free to ping me on IRC ('lumag').

>
> Regards,
> Suraj Kandpal
>
> > [1] https://patchwork.freedesktop.org/series/114473/
> >
> > >
> > > Ankit Nautiyal (2):
> > >   drm/dp_helper: Add helper to check DSC support with given o/p format
> > >   drm/i915/dp: Check if DSC supports the given output_format
> > >
> > > Suraj Kandpal (4):
> > >   drm/i915: Adding the new registers for DSC
> > >   drm/i915: Enable YCbCr420 for VDSC
> > >   drm/i915/display: Fill in native_420 field
> > >   drm/i915/vdsc: Check slice design requirement
> > >
> > > Swati Sharma (1):
> > >   drm/i915/dsc: Add debugfs entry to validate DSC output formats
> > >
> > >  drivers/gpu/drm/i915/display/icl_dsi.c|   2 -
> > >  .../drm/i915/display/intel_crtc_state_dump.c  |   4 +-
> > >  .../drm/i915/display/intel_crtc_state_dump.h  |   2 +
> > >  .../drm/i915/display/intel_display_debugfs.c  |  78 
> > >  .../drm/i915/display/intel_display_types.h|   1 +
> > >  drivers/gpu/drm/i915/display/intel_dp.c   |  39 +++-
> > >  .../gpu/drm/i915/display/intel_qp_tables.c| 187 --
> > >  .../gpu/drm/i915/display/intel_qp_tables.h|   4 +-
> > >  drivers/gpu/drm/i915/display/intel_vdsc.c | 108 +-
> > >  drivers/gpu/drm/i915/i915_reg.h   |  28 +++
> > >  include/drm/display/drm_dp_helper.h   |  13 ++
> > >  11 files changed, 442 insertions(+), 24 deletions(-)
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center



-- 
With best wishes
Dmitry

RE: [PATCH 0/7] Enable YCbCr420 format for VDSC

2023-03-28 Thread Kandpal, Suraj




> -Original Message-
> From: dri-devel  On Behalf Of Jani
> Nikula
> Sent: Wednesday, March 8, 2023 5:00 PM
> To: Kandpal, Suraj ; dri-
> de...@lists.freedesktop.org; intel-...@lists.freedesktop.org
> Cc: Dmitry Baryshkov ; Nautiyal, Ankit K
> ; Shankar, Uma ;
> Kandpal, Suraj 
> Subject: Re: [PATCH 0/7] Enable YCbCr420 format for VDSC
> 
> On Wed, 22 Feb 2023, Suraj Kandpal  wrote:
> > This patch series aims to enable the YCbCr420 format for DSC. Changes
> > are mostly compute params related for hdmi,dp and dsi along with the
> > addition of new rc_tables for native_420 and corresponding changes to
> > macros used to fetch them.
> > There have been discussions prior to this series in which some patches
> > have gotten rb and can be found in the below link
> > https://patchwork.freedesktop.org/series/113729
> 
> I think it would be useful to get [1] from Dmitry merged to drm-misc-next
> first, have that in drm-next, and again backmerged to drm-intel-next before
> this. At least patches 1-5.
> 
> There's not much point in all drivers duplicating the parameters, and we
> need to move towards common code. Dmitry has been helpful in
> contributing this to us.
> 
> BR,
> Jani.
> 
> 

Hi Jani,
Maarten has acked the patch series to be merged through drm-intel and in the 
meantime
I will work with Dmitry to pull the common code to avoid duplication

Regards,
Suraj Kandpal

> [1] https://patchwork.freedesktop.org/series/114473/
> 
> >
> > Ankit Nautiyal (2):
> >   drm/dp_helper: Add helper to check DSC support with given o/p format
> >   drm/i915/dp: Check if DSC supports the given output_format
> >
> > Suraj Kandpal (4):
> >   drm/i915: Adding the new registers for DSC
> >   drm/i915: Enable YCbCr420 for VDSC
> >   drm/i915/display: Fill in native_420 field
> >   drm/i915/vdsc: Check slice design requirement
> >
> > Swati Sharma (1):
> >   drm/i915/dsc: Add debugfs entry to validate DSC output formats
> >
> >  drivers/gpu/drm/i915/display/icl_dsi.c|   2 -
> >  .../drm/i915/display/intel_crtc_state_dump.c  |   4 +-
> >  .../drm/i915/display/intel_crtc_state_dump.h  |   2 +
> >  .../drm/i915/display/intel_display_debugfs.c  |  78 
> >  .../drm/i915/display/intel_display_types.h|   1 +
> >  drivers/gpu/drm/i915/display/intel_dp.c   |  39 +++-
> >  .../gpu/drm/i915/display/intel_qp_tables.c| 187 --
> >  .../gpu/drm/i915/display/intel_qp_tables.h|   4 +-
> >  drivers/gpu/drm/i915/display/intel_vdsc.c | 108 +-
> >  drivers/gpu/drm/i915/i915_reg.h   |  28 +++
> >  include/drm/display/drm_dp_helper.h   |  13 ++
> >  11 files changed, 442 insertions(+), 24 deletions(-)
> 
> --
> Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH 1/1] drm/i915: fix race condition UAF in i915_perf_add_config_ioctl

2023-03-28 Thread Tvrtko Ursulin




On 28/03/2023 10:36, Min Li wrote:

Userspace can guess the id value and try to race oa_config object creation
with config remove, resulting in a use-after-free if we dereference the
object after unlocking the metrics_lock.  For that reason, unlocking the
metrics_lock must be done after we are done dereferencing the object.

Signed-off-by: Min Li 


Fixes: f89823c21224 ("drm/i915/perf: Implement I915_PERF_ADD/REMOVE_CONFIG 
interface")
Cc: Lionel Landwerlin 
Cc: Umesh Nerlige Ramappa 
Cc:  # v4.14+


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

diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 824a34ec0b83..93748ca2c5da 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -4634,13 +4634,13 @@ int i915_perf_add_config_ioctl(struct drm_device *dev, 
void *data,
err = oa_config->id;
goto sysfs_err;
}
-
-   mutex_unlock(&perf->metrics_lock);
+   id = oa_config->id;
  
  	drm_dbg(&perf->i915->drm,

"Added config %s id=%i\n", oa_config->uuid, oa_config->id);
+   mutex_unlock(&perf->metrics_lock);
  
-	return oa_config->id;

+   return id;
  
  sysfs_err:

mutex_unlock(&perf->metrics_lock);


LGTM.

Reviewed-by: Tvrtko Ursulin 

Umesh or Lionel could you please double check? I can merge if confirmed okay.

Regards,

Tvrtko

Re: [PATCH] drm/msm/dsi: simplify pixel clk rate handling