date:20231023

Re: [PATCH 1/2] drm/v3d: wait for all jobs to finish before unregistering

2023-10-23 Thread Iago Toral

El lun, 23-10-2023 a las 07:58 -0300, Maíra Canal escribió:
> Currently, we are only warning the user if the BIN or RENDER jobs
> don't
> finish before we unregister V3D. We must wait for all jobs to finish
> before unregistering. Therefore, warn the user if TFU or CSD jobs
> are not done by the time the driver is unregistered.
> 
> Signed-off-by: Maíra Canal 
> ---
>  drivers/gpu/drm/v3d/v3d_gem.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/v3d/v3d_gem.c
> b/drivers/gpu/drm/v3d/v3d_gem.c
> index 2e94ce788c71..afa7d170d1ff 100644
> --- a/drivers/gpu/drm/v3d/v3d_gem.c
> +++ b/drivers/gpu/drm/v3d/v3d_gem.c
> @@ -1072,6 +1072,8 @@ v3d_gem_destroy(struct drm_device *dev)
>  */
> WARN_ON(v3d->bin_job);
> WARN_ON(v3d->render_job);
> +   WARN_ON(v3d->tfu_job);
> +   WARN_ON(v3d->csd_job);

I guess we should do this for cache clean jobs too, right?

Iago

>  
> drm_mm_takedown(>mm);
>

[PATCH] accel/ivpu: Disable PLL after VPU IP reset during FLR

2023-10-23 Thread Stanislaw Gruszka

From: Jacek Lawrynowicz 

IP reset has to followed by ivpu_pll_disable() to properly enter
reset state.

Fixes: 828d63042aec ("accel/ivpu: Don't enter d0i3 during FLR")
Cc: sta...@vger.kernel.org
Signed-off-by: Jacek Lawrynowicz 
Reviewed-by: Stanislaw Gruszka 
Signed-off-by: Stanislaw Gruszka 
---
 drivers/accel/ivpu/ivpu_hw_37xx.c | 21 +++--
 drivers/accel/ivpu/ivpu_hw_40xx.c | 23 ---
 2 files changed, 39 insertions(+), 5 deletions(-)

diff --git a/drivers/accel/ivpu/ivpu_hw_37xx.c 
b/drivers/accel/ivpu/ivpu_hw_37xx.c
index 7e4e87aa7602..899369a3c5dc 100644
--- a/drivers/accel/ivpu/ivpu_hw_37xx.c
+++ b/drivers/accel/ivpu/ivpu_hw_37xx.c
@@ -598,7 +598,7 @@ static int ivpu_hw_37xx_info_init(struct ivpu_device *vdev)
return 0;
 }
 
-static int ivpu_hw_37xx_reset(struct ivpu_device *vdev)
+static int ivpu_hw_37xx_ip_reset(struct ivpu_device *vdev)
 {
int ret;
u32 val;
@@ -623,6 +623,23 @@ static int ivpu_hw_37xx_reset(struct ivpu_device *vdev)
return ret;
 }
 
+static int ivpu_hw_37xx_reset(struct ivpu_device *vdev)
+{
+   int ret = 0;
+
+   if (ivpu_hw_37xx_ip_reset(vdev)) {
+   ivpu_err(vdev, "Failed to reset VPU IP\n");
+   ret = -EIO;
+   }
+
+   if (ivpu_pll_disable(vdev)) {
+   ivpu_err(vdev, "Failed to disable PLL\n");
+   ret = -EIO;
+   }
+
+   return ret;
+}
+
 static int ivpu_hw_37xx_d0i3_enable(struct ivpu_device *vdev)
 {
int ret;
@@ -722,7 +739,7 @@ static int ivpu_hw_37xx_power_down(struct ivpu_device *vdev)
 {
int ret = 0;
 
-   if (!ivpu_hw_37xx_is_idle(vdev) && ivpu_hw_37xx_reset(vdev))
+   if (!ivpu_hw_37xx_is_idle(vdev) && ivpu_hw_37xx_ip_reset(vdev))
ivpu_err(vdev, "Failed to reset the VPU\n");
 
if (ivpu_pll_disable(vdev)) {
diff --git a/drivers/accel/ivpu/ivpu_hw_40xx.c 
b/drivers/accel/ivpu/ivpu_hw_40xx.c
index e691c49c9841..b25d02dc541b 100644
--- a/drivers/accel/ivpu/ivpu_hw_40xx.c
+++ b/drivers/accel/ivpu/ivpu_hw_40xx.c
@@ -742,7 +742,7 @@ static int ivpu_hw_40xx_info_init(struct ivpu_device *vdev)
return 0;
 }
 
-static int ivpu_hw_40xx_reset(struct ivpu_device *vdev)
+static int ivpu_hw_40xx_ip_reset(struct ivpu_device *vdev)
 {
int ret;
u32 val;
@@ -764,6 +764,23 @@ static int ivpu_hw_40xx_reset(struct ivpu_device *vdev)
return ret;
 }
 
+static int ivpu_hw_40xx_reset(struct ivpu_device *vdev)
+{
+   int ret = 0;
+
+   if (ivpu_hw_40xx_ip_reset(vdev)) {
+   ivpu_err(vdev, "Failed to reset VPU IP\n");
+   ret = -EIO;
+   }
+
+   if (ivpu_pll_disable(vdev)) {
+   ivpu_err(vdev, "Failed to disable PLL\n");
+   ret = -EIO;
+   }
+
+   return ret;
+}
+
 static int ivpu_hw_40xx_d0i3_enable(struct ivpu_device *vdev)
 {
int ret;
@@ -824,7 +841,7 @@ static int ivpu_hw_40xx_power_up(struct ivpu_device *vdev)
 {
int ret;
 
-   ret = ivpu_hw_40xx_reset(vdev);
+   ret = ivpu_hw_40xx_ip_reset(vdev);
if (ret) {
ivpu_err(vdev, "Failed to reset HW: %d\n", ret);
return ret;
@@ -902,7 +919,7 @@ static int ivpu_hw_40xx_power_down(struct ivpu_device *vdev)
 {
int ret = 0;
 
-   if (!ivpu_hw_40xx_is_idle(vdev) && ivpu_hw_40xx_reset(vdev))
+   if (!ivpu_hw_40xx_is_idle(vdev) && ivpu_hw_40xx_ip_reset(vdev))
ivpu_warn(vdev, "Failed to reset the VPU\n");
 
if (ivpu_pll_disable(vdev)) {
-- 
2.25.1

Re: [PATCH v6 4/7] drm/sched: Add DRM_SCHED_POLICY_SINGLE_ENTITY scheduling policy

2023-10-23 Thread Luben Tuikov

Hi,

On 2023-10-17 11:09, Matthew Brost wrote:
> DRM_SCHED_POLICY_SINGLE_ENTITY creates a 1 to 1 relationship between
> scheduler and entity. No priorities or run queue used in this mode.
> Intended for devices with firmware schedulers.
> 
> v2:
>   - Drop sched / rq union (Luben)
> v3:
>   - Don't pick entity if stopped in drm_sched_select_entity (Danilo)
> v4:
>   - Rework if statement in drm_sched_entity_init (Luben)
>   - Update comment for drm_sched_entity_to_scheduler (Luben)
>   - Reword a few things in DOC comment (Luben)
>   - Do not check sched policy in for statement (Luben)
> v5:
>   - Fix extra blank lines (Luben / Checkpatch)
> 
> Signed-off-by: Matthew Brost 
> ---
>  drivers/gpu/drm/scheduler/sched_entity.c | 69 +++
>  drivers/gpu/drm/scheduler/sched_fence.c  |  2 +-
>  drivers/gpu/drm/scheduler/sched_main.c   | 87 ++--
>  include/drm/gpu_scheduler.h  |  8 +++
>  4 files changed, 130 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c 
> b/drivers/gpu/drm/scheduler/sched_entity.c
> index cf42e2265d64..940f63dd6965 100644
> --- a/drivers/gpu/drm/scheduler/sched_entity.c
> +++ b/drivers/gpu/drm/scheduler/sched_entity.c
> @@ -83,6 +83,7 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
>   memset(entity, 0, sizeof(struct drm_sched_entity));
>   INIT_LIST_HEAD(>list);
>   entity->rq = NULL;
> + entity->single_sched = NULL;
>   entity->guilty = guilty;
>   entity->num_sched_list = num_sched_list;
>   entity->priority = priority;
> @@ -90,8 +91,17 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
>   RCU_INIT_POINTER(entity->last_scheduled, NULL);
>   RB_CLEAR_NODE(>rb_tree_node);
>  
> - if(num_sched_list)
> - entity->rq = _list[0]->sched_rq[entity->priority];
> + if (num_sched_list) {
> + if (sched_list[0]->sched_policy !=
> + DRM_SCHED_POLICY_SINGLE_ENTITY) {
> + entity->rq = _list[0]->sched_rq[entity->priority];
> + } else if (num_sched_list == 1 && 
> !sched_list[0]->single_entity) {
> + sched_list[0]->single_entity = entity;
> + entity->single_sched = sched_list[0];

To simplify the rest of the GPU scheduler design and generalize the logic,
we can do
entity->rq = sched_list[0]->sched_rq[entity->priority];
where the "priority" is 0, thus having a single rq.

We shouldn't splice scheduler and entity, but rather make it so that
we can set the number of rqs to 1, thus resulting in a single rq.

(https://lore.kernel.org/r/20231023032251.164775-1-luben.tui...@amd.com)

> + } else {
> + return -EINVAL;
> + }
> + }
>  
>   init_completion(>entity_idle);
>  
> @@ -124,7 +134,8 @@ void drm_sched_entity_modify_sched(struct 
> drm_sched_entity *entity,
>   struct drm_gpu_scheduler **sched_list,
>   unsigned int num_sched_list)
>  {
> - WARN_ON(!num_sched_list || !sched_list);
> + WARN_ON(!num_sched_list || !sched_list ||
> + !!entity->single_sched);

We wouldn't need this check.

>  
>   entity->sched_list = sched_list;
>   entity->num_sched_list = num_sched_list;
> @@ -231,13 +242,15 @@ static void drm_sched_entity_kill(struct 
> drm_sched_entity *entity)
>  {
>   struct drm_sched_job *job;
>   struct dma_fence *prev;
> + bool single_entity = !!entity->single_sched;
>  
> - if (!entity->rq)
> + if (!entity->rq && !single_entity)
>   return;
>  
>   spin_lock(>rq_lock);
>   entity->stopped = true;
> - drm_sched_rq_remove_entity(entity->rq, entity);
> + if (!single_entity)
> + drm_sched_rq_remove_entity(entity->rq, entity);
>   spin_unlock(>rq_lock);

We should be able to carry on the existing infrastructure when
having num_rqs = 1, with dynamic rqs. So we shouldn't warrant
any changes here.

>  
>   /* Make sure this entity is not used by the scheduler at the moment */
> @@ -259,6 +272,20 @@ static void drm_sched_entity_kill(struct 
> drm_sched_entity *entity)
>   dma_fence_put(prev);
>  }
>  
> +/**
> + * drm_sched_entity_to_scheduler - Schedule entity to GPU scheduler
> + * @entity: scheduler entity
> + *
> + * Returns GPU scheduler for the entity
> + */
> +struct drm_gpu_scheduler *
> +drm_sched_entity_to_scheduler(struct drm_sched_entity *entity)
> +{
> + bool single_entity = !!entity->single_sched;
> +
> + return single_entity ? entity->single_sched : entity->rq->sched;

It would be "entity->rq->sched" for any and all cases which simplifies things.

> +}
> +
>  /**
>   * drm_sched_entity_flush - Flush a context entity
>   *
> @@ -276,11 +303,12 @@ long drm_sched_entity_flush(struct drm_sched_entity 
> *entity, long timeout)
>   struct drm_gpu_scheduler *sched;
>   struct task_struct *last_user;
>

Re: [PATCH v2 04/11] drm/mediatek: Add secure identify flag and funcution to mtk_drm_plane

2023-10-23 Thread 胡俊光

Re: [PATCH v6 3/7] drm/sched: Move schedule policy to scheduler

2023-10-23 Thread Luben Tuikov

On 2023-10-17 11:09, Matthew Brost wrote:
> Rather than a global modparam for scheduling policy, move the scheduling
> policy to scheduler so user can control each scheduler policy.
> 
> v2:
>   - s/DRM_SCHED_POLICY_MAX/DRM_SCHED_POLICY_COUNT (Luben)
>   - Only include policy in scheduler (Luben)
> v3:
>   - use a ternary operator as opposed to an if-control (Luben)
>   - s/DRM_SCHED_POLICY_DEFAULT/DRM_SCHED_POLICY_UNSET/ (Luben)
>   - s/default_drm_sched_policy/drm_sched_policy_default/ (Luben)
>   - Update commit message (Boris)
>   - Fix v3d build (CI)
>   - s/bad_policies/drm_sched_policy_mismatch/ (Luben)
>   - Don't update modparam doc (Luben)
> v4:
>   - Fix alignment in msm_ringbuffer_new (Luben / checkpatch)
> 
> Signed-off-by: Matthew Brost 
> Reviewed-by: Luben Tuikov 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  1 +
>  drivers/gpu/drm/etnaviv/etnaviv_sched.c|  3 ++-
>  drivers/gpu/drm/lima/lima_sched.c  |  3 ++-
>  drivers/gpu/drm/msm/msm_ringbuffer.c   |  2 +-
>  drivers/gpu/drm/nouveau/nouveau_sched.c|  3 ++-
>  drivers/gpu/drm/panfrost/panfrost_job.c|  3 ++-
>  drivers/gpu/drm/scheduler/sched_entity.c   | 24 ++
>  drivers/gpu/drm/scheduler/sched_main.c | 19 -
>  drivers/gpu/drm/v3d/v3d_sched.c| 15 +-
>  include/drm/gpu_scheduler.h| 20 --
>  10 files changed, 68 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index b54c4d771104..e4e6f91450a4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -2283,6 +2283,7 @@ static int amdgpu_device_init_schedulers(struct 
> amdgpu_device *adev)
>  ring->num_hw_submission, 0,
>  timeout, adev->reset_domain->wq,
>  ring->sched_score, ring->name,
> +DRM_SCHED_POLICY_UNSET,
>  adev->dev);

I think we should drop this patch.

Drivers shouldn't be able to select their own policy, when there's a kernel 
parameter,
which says what the scheduling policy should be. Imagine you're a user setting
the policy at kernel command line, only to learn that some driver has decided
to ignore (programmed, mind you) your choice and set whatever it decides. Plus,
this opens the Pandora box for other drivers to do this, and it's not a good
software engineering direction.

For the 1-1-1 case in S-R-E (sched-rq-entity) which Xe is using, DRM scheduling 
policy is
irrelevant. We can show this by showing that,
  a) In the case of RR, we always sample the only entity there, namely the 
single
 entity in the single run-queue.
  b) In the case of FIFO, we always pick the only node in the RB tree, namely 
the single
 entity in the single run-queue.

So whether it is RR or FIFO, for the 1-1-1 case, it always works as expected, 
and
the actual selection policy (scheduling policy) is irrelevant. This is a good 
design.

However, what prevents the Xe driver from doing this cleanly, is this ghastly
array of "priorities" in the scheduler struct,

struct drm_gpu_scheduler {
...
struct drm_sched_rq sched_rq[DRM_SCHED_PRIORITY_COUNT];
...

which is very speculative and ambitious... Why should the scheduler have
a set, constant, number of "priorities" and no more or less? Who said that
those are _the_only_ options, and why? It makes for a very rigid design
which doesn't yield well to novel and varied implementations, and that's
not a sign of a good design.

With the "[PATCH] drm/sched: Convert the GPU scheduler to variable number
of run-queues" 
(https://lore.kernel.org/r/20231023032251.164775-1-luben.tui...@amd.com)
drivers can specify the number of run-queues in the S-R-E relationship.

Note, that in the S-R-E relationship, the driver already controls
the number of E's. With the patch above, drivers will also control the number 
of R's,
and I think that will have much more flexible implications for drivers to play 
with
rather than keeping the R constant.

The idea is that the Xe driver would specify that they're using a scheduler
with a single R, at drm_sched_init() and then attach a single E to that,
leaving much of the rest of the code alone. This generalizes (leaves alone) the 
rest of
the code, which is a good design.

There's a bug in the amdgpu code which when using dynamic rq, it oopses, because
it was using the scheduler without ever calling drm_sched_init()--the only 
reason
amdgpu was getting away with it was because the array was statically defined. 
I've posted
a patch for that. 
(https://lore.kernel.org/r/20231023032344.164925-1-luben.tui...@amd.com)

(There was also another bug where amdgpu did sched_rq[-2], and the fix is 
already in,
fa8391ad68c167.)

Regards,
Luben

>   if (r) {
>

Re: [PATCH drm-misc-next v2] drm/sched: implement dynamic job-flow control

2023-10-23 Thread Luben Tuikov

On 2023-10-23 18:35, Danilo Krummrich wrote:
> On Wed, Oct 11, 2023 at 09:52:36PM -0400, Luben Tuikov wrote:
>> Hi,
>>
>> Thanks for fixing the title and submitting a v2 of this patch. Comments 
>> inlined below.
>>
>> On 2023-10-09 18:35, Danilo Krummrich wrote:
>>> Currently, job flow control is implemented simply by limiting the number
>>> of jobs in flight. Therefore, a scheduler is initialized with a
>>> submission limit that corresponds to the number of jobs which can be
>>> sent to the hardware.
>>>
>>> This implies that for each job, drivers need to account for the maximum
>>> job size possible in order to not overflow the ring buffer.
>>>
>>> However, there are drivers, such as Nouveau, where the job size has a
>>> rather large range. For such drivers it can easily happen that job
>>> submissions not even filling the ring by 1% can block subsequent
>>> submissions, which, in the worst case, can lead to the ring run dry.
>>>
>>> In order to overcome this issue, allow for tracking the actual job size
>>> instead of the number of jobs. Therefore, add a field to track a job's
>>> submission credits, which represents the number of credits a job
>>> contributes to the scheduler's submission limit.
>>>
>>> Signed-off-by: Danilo Krummrich 
>>> ---
>>> Changes in V2:
>>> ==
>>>   - fixed up influence on scheduling fairness due to consideration of a 
>>> job's
>>> size
>>> - If we reach a ready entity in drm_sched_select_entity() but can't 
>>> actually
>>>   queue a job from it due to size limitations, just give up and go to 
>>> sleep
>>>   until woken up due to a pending job finishing, rather than continue 
>>> to try
>>>   other entities.
>>>   - added a callback to dynamically update a job's credits (Boris)
>>>   - renamed 'units' to 'credits'
>>>   - fixed commit message and comments as requested by Luben
>>> ---
>>>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c   |   2 +-
>>>  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c  |   2 +-
>>>  drivers/gpu/drm/lima/lima_sched.c |   2 +-
>>>  drivers/gpu/drm/msm/msm_gem_submit.c  |   2 +-
>>>  drivers/gpu/drm/nouveau/nouveau_sched.c   |   2 +-
>>>  drivers/gpu/drm/panfrost/panfrost_drv.c   |   2 +-
>>>  .../gpu/drm/scheduler/gpu_scheduler_trace.h   |   2 +-
>>>  drivers/gpu/drm/scheduler/sched_entity.c  |   5 +-
>>>  drivers/gpu/drm/scheduler/sched_main.c| 101 +-
>>>  drivers/gpu/drm/v3d/v3d_gem.c |   2 +-
>>>  include/drm/gpu_scheduler.h   |  33 --
>>>  11 files changed, 115 insertions(+), 40 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c 
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>>> index 78476bc75b4e..d54daaf64bf1 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>>> @@ -115,7 +115,7 @@ int amdgpu_job_alloc(struct amdgpu_device *adev, struct 
>>> amdgpu_vm *vm,
>>> if (!entity)
>>> return 0;
>>>  
>>> -   return drm_sched_job_init(&(*job)->base, entity, owner);
>>> +   return drm_sched_job_init(&(*job)->base, entity, 1, owner);
>>>  }
>>>  
>>>  int amdgpu_job_alloc_with_ib(struct amdgpu_device *adev,
>>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
>>> b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
>>> index 45403ea38906..74a446711207 100644
>>> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
>>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
>>> @@ -538,7 +538,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, 
>>> void *data,
>>>  
>>> ret = drm_sched_job_init(>sched_job,
>>>  >sched_entity[args->pipe],
>>> -submit->ctx);
>>> +1, submit->ctx);
>>> if (ret)
>>> goto err_submit_put;
>>>  
>>> diff --git a/drivers/gpu/drm/lima/lima_sched.c 
>>> b/drivers/gpu/drm/lima/lima_sched.c
>>> index 50c2075228aa..5dc6678e1eb9 100644
>>> --- a/drivers/gpu/drm/lima/lima_sched.c
>>> +++ b/drivers/gpu/drm/lima/lima_sched.c
>>> @@ -123,7 +123,7 @@ int lima_sched_task_init(struct lima_sched_task *task,
>>> for (i = 0; i < num_bos; i++)
>>> drm_gem_object_get([i]->base.base);
>>>  
>>> -   err = drm_sched_job_init(>base, >base, vm);
>>> +   err = drm_sched_job_init(>base, >base, 1, vm);
>>> if (err) {
>>> kfree(task->bos);
>>> return err;
>>> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
>>> b/drivers/gpu/drm/msm/msm_gem_submit.c
>>> index 3f1aa4de3b87..6d230c38e4f5 100644
>>> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
>>> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
>>> @@ -48,7 +48,7 @@ static struct msm_gem_submit *submit_create(struct 
>>> drm_device *dev,
>>> return ERR_PTR(ret);
>>> }
>>>  
>>> -   ret = drm_sched_job_init(>base, queue->entity, queue);
>>> +   ret = drm_sched_job_init(>base, queue->entity, 1, queue);
>>> if (ret) {
>>>

Re: [PATCH drm-misc-next v2] drm/sched: implement dynamic job-flow control

2023-10-23 Thread Luben Tuikov

On 2023-10-23 18:57, Danilo Krummrich wrote:
> On Tue, Oct 10, 2023 at 09:41:51AM +0200, Boris Brezillon wrote:
>> On Tue, 10 Oct 2023 00:35:53 +0200
>> Danilo Krummrich  wrote:
>>
>>> Currently, job flow control is implemented simply by limiting the number
>>> of jobs in flight. Therefore, a scheduler is initialized with a
>>> submission limit that corresponds to the number of jobs which can be
>>> sent to the hardware.
>>>
>>> This implies that for each job, drivers need to account for the maximum
>>> job size possible in order to not overflow the ring buffer.
>>>
>>> However, there are drivers, such as Nouveau, where the job size has a
>>> rather large range. For such drivers it can easily happen that job
>>> submissions not even filling the ring by 1% can block subsequent
>>> submissions, which, in the worst case, can lead to the ring run dry.
>>>
>>> In order to overcome this issue, allow for tracking the actual job size
>>> instead of the number of jobs. Therefore, add a field to track a job's
>>> submission credits, which represents the number of credits a job
>>> contributes to the scheduler's submission limit.
>>>
>>> Signed-off-by: Danilo Krummrich 
>>> ---
>>> Changes in V2:
>>> ==
>>>   - fixed up influence on scheduling fairness due to consideration of a 
>>> job's
>>> size
>>> - If we reach a ready entity in drm_sched_select_entity() but can't 
>>> actually
>>>   queue a job from it due to size limitations, just give up and go to 
>>> sleep
>>>   until woken up due to a pending job finishing, rather than continue 
>>> to try
>>>   other entities.
>>>   - added a callback to dynamically update a job's credits (Boris)
>>>   - renamed 'units' to 'credits'
>>>   - fixed commit message and comments as requested by Luben
>>> ---
>>>  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c   |   2 +-
>>>  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c  |   2 +-
>>>  drivers/gpu/drm/lima/lima_sched.c |   2 +-
>>>  drivers/gpu/drm/msm/msm_gem_submit.c  |   2 +-
>>>  drivers/gpu/drm/nouveau/nouveau_sched.c   |   2 +-
>>>  drivers/gpu/drm/panfrost/panfrost_drv.c   |   2 +-
>>>  .../gpu/drm/scheduler/gpu_scheduler_trace.h   |   2 +-
>>>  drivers/gpu/drm/scheduler/sched_entity.c  |   5 +-
>>>  drivers/gpu/drm/scheduler/sched_main.c| 101 +-
>>>  drivers/gpu/drm/v3d/v3d_gem.c |   2 +-
>>>  include/drm/gpu_scheduler.h   |  33 --
>>>  11 files changed, 115 insertions(+), 40 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c 
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>>> index 78476bc75b4e..d54daaf64bf1 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
>>> @@ -115,7 +115,7 @@ int amdgpu_job_alloc(struct amdgpu_device *adev, struct 
>>> amdgpu_vm *vm,
>>> if (!entity)
>>> return 0;
>>>  
>>> -   return drm_sched_job_init(&(*job)->base, entity, owner);
>>> +   return drm_sched_job_init(&(*job)->base, entity, 1, owner);
>>>  }
>>>  
>>>  int amdgpu_job_alloc_with_ib(struct amdgpu_device *adev,
>>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
>>> b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
>>> index 45403ea38906..74a446711207 100644
>>> --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
>>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
>>> @@ -538,7 +538,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, 
>>> void *data,
>>>  
>>> ret = drm_sched_job_init(>sched_job,
>>>  >sched_entity[args->pipe],
>>> -submit->ctx);
>>> +1, submit->ctx);
>>> if (ret)
>>> goto err_submit_put;
>>>  
>>> diff --git a/drivers/gpu/drm/lima/lima_sched.c 
>>> b/drivers/gpu/drm/lima/lima_sched.c
>>> index 50c2075228aa..5dc6678e1eb9 100644
>>> --- a/drivers/gpu/drm/lima/lima_sched.c
>>> +++ b/drivers/gpu/drm/lima/lima_sched.c
>>> @@ -123,7 +123,7 @@ int lima_sched_task_init(struct lima_sched_task *task,
>>> for (i = 0; i < num_bos; i++)
>>> drm_gem_object_get([i]->base.base);
>>>  
>>> -   err = drm_sched_job_init(>base, >base, vm);
>>> +   err = drm_sched_job_init(>base, >base, 1, vm);
>>> if (err) {
>>> kfree(task->bos);
>>> return err;
>>> diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
>>> b/drivers/gpu/drm/msm/msm_gem_submit.c
>>> index 3f1aa4de3b87..6d230c38e4f5 100644
>>> --- a/drivers/gpu/drm/msm/msm_gem_submit.c
>>> +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
>>> @@ -48,7 +48,7 @@ static struct msm_gem_submit *submit_create(struct 
>>> drm_device *dev,
>>> return ERR_PTR(ret);
>>> }
>>>  
>>> -   ret = drm_sched_job_init(>base, queue->entity, queue);
>>> +   ret = drm_sched_job_init(>base, queue->entity, 1, queue);
>>> if (ret) {
>>> kfree(submit->hw_fence);
>>> kfree(submit);
>>> diff --git

pull for vmemdup-user-array into drm-next

2023-10-23 Thread Dave Airlie

topic/vmemdup-user-array-2023-10-24-1:
vmemdup-user-array API and changes with it.

This is just a process PR to merge the topic branch into drm-next, this 
contains some core kernel and drm changes.

Signed-off-by: Dave Airlie 
The following changes since commit 94f6f0550c625fab1f373bb86a6669b45e9748b3:

  Linux 6.6-rc5 (2023-10-08 13:49:43 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm 
tags/topic/vmemdup-user-array-2023-10-24-1

for you to fetch changes up to 06ab64a0d836ac430c5f94669710a78aa43942cb:

  drm: vmwgfx_surface.c: copy user-array safely (2023-10-09 17:00:05 +1000)


vmemdup-user-array API and changes with it.

This is just a process PR to merge the topic branch into drm-next, this 
contains some core kernel and drm changes.

Signed-off-by: Dave Airlie 


Philipp Stanner (5):
  string.h: add array-wrappers for (v)memdup_user()
  kernel: kexec: copy user-array safely
  kernel: watch_queue: copy user-array safely
  drm_lease.c: copy user-array safely
  drm: vmwgfx_surface.c: copy user-array safely

 drivers/gpu/drm/drm_lease.c |  4 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_surface.c |  4 ++--
 include/linux/string.h  | 40 +
 kernel/kexec.c  |  2 +-
 kernel/watch_queue.c|  2 +-
 5 files changed, 46 insertions(+), 6 deletions(-)

[PATCH 04/29] drm/dp_mst: Swap the order of checking root vs. non-root port BW limitations

2023-10-23 Thread Imre Deak

drm_dp_mst_atomic_check_mgr() should check for BW limitation starting
from sink ports continuing towards the root port, so that drivers can
use the @failing_port returned to resolve a BW overallocation in an
ideal way. For instance from streams A,B,C in a topology A,B going
through @failing_port and C not going through it, a BW overallocation of
A,B due to a limit of the port must be resolved first before considering
the limits of other ports closer to the root port. This way can avoid
reducing the BW of stream C unnecessarily due to a BW limit closer to the
root port.

Based on the above swap the order of the BW check for the root port and
the check for all the ports downstream of it (the latter going through
the topology already in the sink->root port direction).

Cc: Lyude Paul 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Lyude Paul 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/display/drm_dp_mst_topology.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index a86a67d3516ff..5972c93615f18 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -5469,9 +5469,13 @@ EXPORT_SYMBOL(drm_dp_mst_atomic_enable_dsc);
  *   - %-ENOSPC, if the new state is invalid, because of BW limitation
  * @failing_port is set to:
  * - The non-root port where a BW limit check failed
+ *   with all the ports downstream of @failing_port passing
+ *   the BW limit check.
  *   The returned port pointer is valid until at least
  *   one payload downstream of it exists.
  * - %NULL if the BW limit check failed at the root port
+ *   with all the ports downstream of the root port passing
+ *   the BW limit check.
  *   - %-EINVAL, if the new state is invalid, because the root port has
  * too many payloads.
  */
@@ -5487,17 +5491,16 @@ int drm_dp_mst_atomic_check_mgr(struct drm_atomic_state 
*state,
if (!mgr->mst_state)
return 0;
 
-   ret = drm_dp_mst_atomic_check_payload_alloc_limits(mgr, mst_state);
-   if (ret)
-   return ret;
-
mutex_lock(>lock);
ret = drm_dp_mst_atomic_check_mstb_bw_limit(mgr->mst_primary,
mst_state,
failing_port);
mutex_unlock(>lock);
 
-   return ret < 0 ? ret : 0;
+   if (ret < 0)
+   return ret;
+
+   return drm_dp_mst_atomic_check_payload_alloc_limits(mgr, mst_state);
 }
 EXPORT_SYMBOL(drm_dp_mst_atomic_check_mgr);
 
-- 
2.39.2

[PATCH 03/29] drm/dp_mst: Factor out a helper to check the atomic state of a topology manager

2023-10-23 Thread Imre Deak

Factor out a helper to check the atomic state for one MST topology
manager, returning the MST port where the BW limit check has failed.
This will be used in a follow-up patch by the i915 driver to improve the
BW sharing between MST streams.

Cc: Lyude Paul 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Lyude Paul 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/display/drm_dp_mst_topology.c | 93 +++
 include/drm/display/drm_dp_mst_helper.h   |  4 +
 2 files changed, 78 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index f733f620347f6..a86a67d3516ff 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -5180,11 +5180,13 @@ EXPORT_SYMBOL(drm_dp_mst_port_downstream_of_parent);
 
 static int
 drm_dp_mst_atomic_check_port_bw_limit(struct drm_dp_mst_port *port,
- struct drm_dp_mst_topology_state *state);
+ struct drm_dp_mst_topology_state *state,
+ struct drm_dp_mst_port **failing_port);
 
 static int
 drm_dp_mst_atomic_check_mstb_bw_limit(struct drm_dp_mst_branch *mstb,
- struct drm_dp_mst_topology_state *state)
+ struct drm_dp_mst_topology_state *state,
+ struct drm_dp_mst_port **failing_port)
 {
struct drm_dp_mst_atomic_payload *payload;
struct drm_dp_mst_port *port;
@@ -5213,7 +5215,7 @@ drm_dp_mst_atomic_check_mstb_bw_limit(struct 
drm_dp_mst_branch *mstb,
drm_dbg_atomic(mstb->mgr->dev, "[MSTB:%p] Checking bandwidth 
limits\n", mstb);
 
list_for_each_entry(port, >ports, next) {
-   ret = drm_dp_mst_atomic_check_port_bw_limit(port, state);
+   ret = drm_dp_mst_atomic_check_port_bw_limit(port, state, 
failing_port);
if (ret < 0)
return ret;
 
@@ -5225,7 +5227,8 @@ drm_dp_mst_atomic_check_mstb_bw_limit(struct 
drm_dp_mst_branch *mstb,
 
 static int
 drm_dp_mst_atomic_check_port_bw_limit(struct drm_dp_mst_port *port,
- struct drm_dp_mst_topology_state *state)
+ struct drm_dp_mst_topology_state *state,
+ struct drm_dp_mst_port **failing_port)
 {
struct drm_dp_mst_atomic_payload *payload;
int pbn_used = 0;
@@ -5246,13 +5249,15 @@ drm_dp_mst_atomic_check_port_bw_limit(struct 
drm_dp_mst_port *port,
drm_dbg_atomic(port->mgr->dev,
   "[MSTB:%p] [MST PORT:%p] no BW available 
for the port\n",
   port->parent, port);
+   *failing_port = port;
return -EINVAL;
}
 
pbn_used = payload->pbn;
} else {
pbn_used = drm_dp_mst_atomic_check_mstb_bw_limit(port->mstb,
-state);
+state,
+failing_port);
if (pbn_used <= 0)
return pbn_used;
}
@@ -5261,6 +5266,7 @@ drm_dp_mst_atomic_check_port_bw_limit(struct 
drm_dp_mst_port *port,
drm_dbg_atomic(port->mgr->dev,
   "[MSTB:%p] [MST PORT:%p] required PBN of %d 
exceeds port limit of %d\n",
   port->parent, port, pbn_used, port->full_pbn);
+   *failing_port = port;
return -ENOSPC;
}
 
@@ -5438,20 +5444,79 @@ int drm_dp_mst_atomic_enable_dsc(struct 
drm_atomic_state *state,
 }
 EXPORT_SYMBOL(drm_dp_mst_atomic_enable_dsc);
 
+/**
+ * drm_dp_mst_atomic_check_mgr - Check the atomic state of an MST topology 
manager
+ * @state: The global atomic state
+ * @mgr: Manager to check
+ * @mst_state: The MST atomic state for @mgr
+ * @failing_port: Returns the port with a BW limitation
+ *
+ * Checks the given MST manager's topology state for an atomic update to ensure
+ * that it's valid. This includes checking whether there's enough bandwidth to
+ * support the new timeslot allocations in the atomic update.
+ *
+ * Any atomic drivers supporting DP MST must make sure to call this or
+ * the drm_dp_mst_atomic_check() function after checking the rest of their 
state
+ * in their _mode_config_funcs.atomic_check() callback.
+ *
+ * See also:
+ * drm_dp_mst_atomic_check()
+ * drm_dp_atomic_find_time_slots()
+ * drm_dp_atomic_release_time_slots()
+ *
+ * Returns:
+ *   - 0 if the new state is valid
+ *   - %-ENOSPC, if the new state is invalid, because of BW limitation
+ * @failing_port is set to:
+ * - The non-root port where a BW limit check

[PATCH 02/29] drm/dp_mst: Add helper to determine if an MST port is downstream of another port

2023-10-23 Thread Imre Deak

Add drm_dp_mst_port_downstream_of_parent() required by the i915
driver in a follow-up patch to resolve a BW overallocation of MST
streams going through a given MST port.

Cc: Lyude Paul 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Lyude Paul 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/display/drm_dp_mst_topology.c | 52 +++
 include/drm/display/drm_dp_mst_helper.h   |  3 ++
 2 files changed, 55 insertions(+)

diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 772b00ebd57bd..f733f620347f6 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -5126,6 +5126,58 @@ static bool drm_dp_mst_port_downstream_of_branch(struct 
drm_dp_mst_port *port,
return false;
 }
 
+static bool
+drm_dp_mst_port_downstream_of_parent_locked(struct drm_dp_mst_topology_mgr 
*mgr,
+   struct drm_dp_mst_port *port,
+   struct drm_dp_mst_port *parent)
+{
+   if (!mgr->mst_primary)
+   return false;
+
+   port = drm_dp_mst_topology_get_port_validated_locked(mgr->mst_primary,
+port);
+   if (!port)
+   return false;
+
+   if (!parent)
+   return true;
+
+   parent = drm_dp_mst_topology_get_port_validated_locked(mgr->mst_primary,
+  parent);
+   if (!parent)
+   return false;
+
+   if (!parent->mstb)
+   return false;
+
+   return drm_dp_mst_port_downstream_of_branch(port, parent->mstb);
+}
+
+/**
+ * drm_dp_mst_port_downstream_of_parent - check if a port is downstream of a 
parent port
+ * @mgr: MST topology manager
+ * @port: the port being looked up
+ * @parent: the parent port
+ *
+ * The function returns %true if @port is downstream of @parent. If @parent is
+ * %NULL - denoting the root port - the function returns %true if @port is in
+ * @mgr's topology.
+ */
+bool
+drm_dp_mst_port_downstream_of_parent(struct drm_dp_mst_topology_mgr *mgr,
+struct drm_dp_mst_port *port,
+struct drm_dp_mst_port *parent)
+{
+   bool ret;
+
+   mutex_lock(>lock);
+   ret = drm_dp_mst_port_downstream_of_parent_locked(mgr, port, parent);
+   mutex_unlock(>lock);
+
+   return ret;
+}
+EXPORT_SYMBOL(drm_dp_mst_port_downstream_of_parent);
+
 static int
 drm_dp_mst_atomic_check_port_bw_limit(struct drm_dp_mst_port *port,
  struct drm_dp_mst_topology_state *state);
diff --git a/include/drm/display/drm_dp_mst_helper.h 
b/include/drm/display/drm_dp_mst_helper.h
index 655862b3d2a49..e44485aa74e94 100644
--- a/include/drm/display/drm_dp_mst_helper.h
+++ b/include/drm/display/drm_dp_mst_helper.h
@@ -892,6 +892,9 @@ drm_atomic_get_new_mst_topology_state(struct 
drm_atomic_state *state,
 struct drm_dp_mst_atomic_payload *
 drm_atomic_get_mst_payload_state(struct drm_dp_mst_topology_state *state,
 struct drm_dp_mst_port *port);
+bool drm_dp_mst_port_downstream_of_parent(struct drm_dp_mst_topology_mgr *mgr,
+ struct drm_dp_mst_port *port,
+ struct drm_dp_mst_port *parent);
 int __must_check
 drm_dp_atomic_find_time_slots(struct drm_atomic_state *state,
  struct drm_dp_mst_topology_mgr *mgr,
-- 
2.39.2

Re: linux-next: build failure after merge of the amdgpu tree

2023-10-23 Thread Stephen Rothwell

Hi all,

On Thu, 19 Oct 2023 12:06:18 +1100 Stephen Rothwell  
wrote:
>
> On Tue, 10 Oct 2023 12:43:57 +1100 Stephen Rothwell  
> wrote:
> >
> > After merging the amdgpu tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_core.c: In 
> > function 'dml_core_mode_support':
> > drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/display_mode_core.c:8229:1: 
> > error: the frame size of 2736 bytes is larger than 2048 bytes 
> > [-Werror=frame-larger-than=]
> >  8229 | } // dml_core_mode_support
> >   | ^
> > cc1: all warnings being treated as errors
> > 
> > Caused by commit
> > 
> >   7966f319c66d ("drm/amd/display: Introduce DML2")
> > 
> > (or maybe something later that changed storage size).
> > 
> > I have used the amdgpu tree from next-20231009 for today.  
> 
> This build failure now (presumably) exists in the drm tree.  I am still
> applying the 2 patches from Rodrigo to my tree as a work around.
> 
> I would have expected that this was fixed in the amdgpu tree before
> Dave was asked to merge it ...

Any progress here?  I am still applying the 2 patches.

-- 
Cheers,
Stephen Rothwell


pgpK0hIJAb4p4.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the drm tree with the mm-stable tree

2023-10-23 Thread Stephen Rothwell

Hi all,

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

  drivers/gpu/drm/msm/msm_drv.c

between commit:

  cd61a76c210a ("drm/msm: dynamically allocate the drm-msm_gem shrinker")

from the mm-stable tree and commit:

  506efcba3129 ("drm/msm: carve out KMS code from msm_drv.c")

from the drm tree.

I fixed it up (see below) 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

diff --cc drivers/gpu/drm/msm/msm_drv.c
index 7f20249d6071,443bbc3ed750..
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@@ -457,23 -265,12 +265,14 @@@ static int msm_drm_init(struct device *
if (ret)
goto err_deinit_vram;
  
-   /* the fw fb could be anywhere in memory */
-   ret = drm_aperture_remove_framebuffers(drv);
-   if (ret)
-   goto err_msm_uninit;
- 
 -  msm_gem_shrinker_init(ddev);
 +  ret = msm_gem_shrinker_init(ddev);
 +  if (ret)
 +  goto err_msm_uninit;
  
if (priv->kms_init) {
-   ret = priv->kms_init(ddev);
-   if (ret) {
-   DRM_DEV_ERROR(dev, "failed to load kms\n");
-   priv->kms = NULL;
+   ret = msm_drm_kms_init(dev, drv);
+   if (ret)
goto err_msm_uninit;
-   }
-   kms = priv->kms;
} else {
/* valid only for the dummy headless case, where of_node=NULL */
WARN_ON(dev->of_node);


pgpuFSqjfc4My.pgp
Description: OpenPGP digital signature

[PATCH v3 10/10] drm/ci: docs: add step about how to request privileges

2023-10-23 Thread Helen Koike

Clarify the procedure developer must follow to request privileges to
run tests on Freedesktop gitlab CI.

This measure was added to avoid untrusted people to misuse the
infrastructure.

Signed-off-by: Helen Koike 
Reviewed-by: David Heidelberg 
---

v2:
- fix typo in commit message
v3:
-no changes
---
 Documentation/gpu/automated_testing.rst | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/Documentation/gpu/automated_testing.rst 
b/Documentation/gpu/automated_testing.rst
index 469b6fb65c30..8ec1878b44ab 100644
--- a/Documentation/gpu/automated_testing.rst
+++ b/Documentation/gpu/automated_testing.rst
@@ -86,10 +86,13 @@ 
https://gitlab.freedesktop.org/janedoe/linux/-/settings/ci_cd), change the
 CI/CD configuration file from .gitlab-ci.yml to
 drivers/gpu/drm/ci/gitlab-ci.yml.
 
-3. Next time you push to this repository, you will see a CI pipeline being
+3. Request to be added to the drm/ci-ok group so that your user has the
+necessary privileges to run the CI on https://gitlab.freedesktop.org/drm/ci-ok
+
+4. Next time you push to this repository, you will see a CI pipeline being
 created (eg. https://gitlab.freedesktop.org/janedoe/linux/-/pipelines)
 
-4. The various jobs will be run and when the pipeline is finished, all jobs
+5. The various jobs will be run and when the pipeline is finished, all jobs
 should be green unless a regression has been found.
 
 
-- 
2.39.2

[PATCH v3 09/10] drm/ci: do not automatically retry on error

2023-10-23 Thread Helen Koike

Since the kernel doesn't use a bot like Mesa that requires tests to pass
in order to merge the patches, leave it to developers and/or maintainers
to manually retry.

Suggested-by: Rob Clark 
Signed-off-by: Helen Koike 
Reviewed-by: David Heidelberg 

---

v2:
- no changes
v3:
-no changes
---
 drivers/gpu/drm/ci/gitlab-ci.yml | 14 --
 1 file changed, 14 deletions(-)

diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml
index cb41fa1b068b..aeb9bab1b069 100644
--- a/drivers/gpu/drm/ci/gitlab-ci.yml
+++ b/drivers/gpu/drm/ci/gitlab-ci.yml
@@ -55,20 +55,6 @@ default:
   export CI_JOB_JWT="$(<${CI_JOB_JWT_FILE})" &&
   rm "${CI_JOB_JWT_FILE}"
 
-  # Retry when job fails.
-  retry:
-max: 1
-# Ignore runner_unsupported, stale_schedule, archived_failure, or
-# unmet_prerequisites
-when:
-  - api_failure
-  - runner_system_failure
-  - script_failure
-  - job_execution_timeout
-  - scheduler_failure
-  - data_integrity_failure
-  - unknown_failure
-
 include:
   - project: 'freedesktop/ci-templates'
 ref: 16bc29078de5e0a067ff84a1a199a3760d3b3811
-- 
2.39.2

[PATCH v3 08/10] drm/ci: export kernel config

2023-10-23 Thread Helen Koike

Export the resultant kernel config, making it easier to verify if the
resultant config was correctly generated.

Suggested-by: Rob Clark 
Signed-off-by: Helen Koike 
Acked-by: Dmitry Baryshkov 
Reviewed-by: David Heidelberg 

---

v2:
- no changes
v3:
-no changes
---
 drivers/gpu/drm/ci/build.sh   | 1 +
 drivers/gpu/drm/ci/image-tags.yml | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ci/build.sh b/drivers/gpu/drm/ci/build.sh
index e3908f4d71cb..e5c5dcedd108 100644
--- a/drivers/gpu/drm/ci/build.sh
+++ b/drivers/gpu/drm/ci/build.sh
@@ -153,6 +153,7 @@ mkdir -p artifacts/install/lib
 mv install/* artifacts/install/.
 rm -rf artifacts/install/modules
 ln -s common artifacts/install/ci-common
+cp .config artifacts/${CI_JOB_NAME}_config
 
 for image in ${KERNEL_IMAGE_NAME}; do
 cp /lava-files/$image artifacts/install/.
diff --git a/drivers/gpu/drm/ci/image-tags.yml 
b/drivers/gpu/drm/ci/image-tags.yml
index 7dd3f995f8a2..7ab4f2514da8 100644
--- a/drivers/gpu/drm/ci/image-tags.yml
+++ b/drivers/gpu/drm/ci/image-tags.yml
@@ -4,7 +4,7 @@ variables:
DEBIAN_BASE_TAG: "${CONTAINER_TAG}"
 
DEBIAN_X86_64_BUILD_IMAGE_PATH: "debian/x86_64_build"
-   DEBIAN_BUILD_TAG: "2023-10-08-igt"
+   DEBIAN_BUILD_TAG: "2023-10-08-config"
 
KERNEL_ROOTFS_TAG: "2023-10-06-amd"
 
-- 
2.39.2

[PATCH v3 07/10] drm/ci: increase i915 job timeout to 1h30m

2023-10-23 Thread Helen Koike

With the new sharding, the default job timeout is not enough for i915
and their jobs are failing before completing.

See below the current execution time:

 job i915:tgl 8/8 has new status: success (37m3s)
 job i915:tgl 7/8 has new status: success (19m43s)
 job i915:tgl 6/8 has new status: success (21m47s)
 job i915:tgl 5/8 has new status: success (18m16s)
 job i915:tgl 4/8 has new status: success (21m43s)
 job i915:tgl 3/8 has new status: success (17m59s)
 job i915:tgl 2/8 has new status: success (22m15s)
 job i915:tgl 1/8 has new status: success (18m52s)
 job i915:cml 2/2 has new status: success (1h19m58s)
 job i915:cml 1/2 has new status: success (55m45s)
 job i915:whl 2/2 has new status: success (1h8m56s)
 job i915:whl 1/2 has new status: success (54m3s)
 job i915:kbl 3/3 has new status: success (37m43s)
 job i915:kbl 2/3 has new status: success (36m37s)
 job i915:kbl 1/3 has new status: success (34m52s)
 job i915:amly 2/2 has new status: success (1h7m60s)
 job i915:amly 1/2 has new status: success (59m18s)
 job i915:glk 2/2 has new status: success (58m26s)
 job i915:glk 1/2 has new status: success (50m23s)
 job i915:apl 3/3 has new status: success (1h6m39s)
 job i915:apl 2/3 has new status: success (1h4m45s)
 job i915:apl 1/3 has new status: success (1h7m38s)

(generated with ci_run_n_monitor.py script)

The longest job is 1h19m58s, so adjust the timeout.

Signed-off-by: Helen Koike 

---

v3:
- new patch
---
 drivers/gpu/drm/ci/test.yml | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml
index 19dc0862e710..f285ed67eb3d 100644
--- a/drivers/gpu/drm/ci/test.yml
+++ b/drivers/gpu/drm/ci/test.yml
@@ -179,6 +179,7 @@ i915:apl:
   extends:
 - .i915
   parallel: 3
+  timeout: "1h30m"
   variables:
 DEVICE_TYPE: asus-C523NA-A20057-coral
 GPU_VERSION: apl
@@ -188,6 +189,7 @@ i915:glk:
   extends:
 - .i915
   parallel: 2
+  timeout: "1h30m"
   variables:
 DEVICE_TYPE: hp-x360-12b-ca0010nr-n4020-octopus
 GPU_VERSION: glk
@@ -197,6 +199,7 @@ i915:amly:
   extends:
 - .i915
   parallel: 2
+  timeout: "1h30m"
   variables:
 DEVICE_TYPE: asus-C433TA-AJ0005-rammus
 GPU_VERSION: amly
@@ -215,6 +218,7 @@ i915:whl:
   extends:
 - .i915
   parallel: 2
+  timeout: "1h30m"
   variables:
 DEVICE_TYPE: dell-latitude-5400-8665U-sarien
 GPU_VERSION: whl
@@ -224,6 +228,7 @@ i915:cml:
   extends:
 - .i915
   parallel: 2
+  timeout: "1h30m"
   variables:
 DEVICE_TYPE: asus-C436FA-Flip-hatch
 GPU_VERSION: cml
-- 
2.39.2

[PATCH v3 06/10] drm/ci: add subset-1-gfx to LAVA_TAGS and adjust shards

2023-10-23 Thread Helen Koike

The Collabora Lava farm added a tag called `subset-1-gfx` to half of
devices the graphics community use.

Lets use this tag so we don't occupy all the resources.

This is particular important because Mesa3D shares the resources with
DRM-CI and use them to do pre-merge tests, so it can block developers
from getting their patches merged.

Signed-off-by: Helen Koike 
Reviewed-by: David Heidelberg 

---

v2:
- add subset-1-gfx tag to LAVA_TAGS
- update commit message
v3: no changes
---
 drivers/gpu/drm/ci/gitlab-ci.yml |  2 +-
 drivers/gpu/drm/ci/test.yml  | 23 ++-
 2 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml
index c08ea6097b1d..cb41fa1b068b 100644
--- a/drivers/gpu/drm/ci/gitlab-ci.yml
+++ b/drivers/gpu/drm/ci/gitlab-ci.yml
@@ -26,7 +26,7 @@ variables:
   JOB_ARTIFACTS_BASE: ${PIPELINE_ARTIFACTS_BASE}/${CI_JOB_ID}
   # default kernel for rootfs before injecting the current kernel tree
   KERNEL_IMAGE_BASE: 
https://${S3_HOST}/mesa-lava/gfx-ci/linux/v6.4.12-for-mesa-ci-f6b4ad45f48d
-
+  LAVA_TAGS: subset-1-gfx
   LAVA_JOB_PRIORITY: 30
 
 default:
diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml
index 3479d2a0108d..19dc0862e710 100644
--- a/drivers/gpu/drm/ci/test.yml
+++ b/drivers/gpu/drm/ci/test.yml
@@ -86,7 +86,7 @@ msm:sc7180:
   extends:
 - .lava-igt:arm64
   stage: msm
-  parallel: 2
+  parallel: 4
   variables:
 DRIVER_NAME: msm
 DEVICE_TYPE: sc7180-trogdor-lazor-limozeen
@@ -155,7 +155,7 @@ rockchip:rk3399:
   extends:
 - .lava-igt:arm64
   stage: rockchip
-  parallel: 3
+  parallel: 2
   variables:
 DRIVER_NAME: rockchip
 DEVICE_TYPE: rk3399-gru-kevin
@@ -178,7 +178,7 @@ rockchip:rk3399:
 i915:apl:
   extends:
 - .i915
-  parallel: 12
+  parallel: 3
   variables:
 DEVICE_TYPE: asus-C523NA-A20057-coral
 GPU_VERSION: apl
@@ -187,7 +187,7 @@ i915:apl:
 i915:glk:
   extends:
 - .i915
-  parallel: 5
+  parallel: 2
   variables:
 DEVICE_TYPE: hp-x360-12b-ca0010nr-n4020-octopus
 GPU_VERSION: glk
@@ -196,7 +196,7 @@ i915:glk:
 i915:amly:
   extends:
 - .i915
-  parallel: 8
+  parallel: 2
   variables:
 DEVICE_TYPE: asus-C433TA-AJ0005-rammus
 GPU_VERSION: amly
@@ -205,7 +205,7 @@ i915:amly:
 i915:kbl:
   extends:
 - .i915
-  parallel: 5
+  parallel: 3
   variables:
 DEVICE_TYPE: hp-x360-14-G1-sona
 GPU_VERSION: kbl
@@ -214,7 +214,7 @@ i915:kbl:
 i915:whl:
   extends:
 - .i915
-  parallel: 8
+  parallel: 2
   variables:
 DEVICE_TYPE: dell-latitude-5400-8665U-sarien
 GPU_VERSION: whl
@@ -223,7 +223,7 @@ i915:whl:
 i915:cml:
   extends:
 - .i915
-  parallel: 6
+  parallel: 2
   variables:
 DEVICE_TYPE: asus-C436FA-Flip-hatch
 GPU_VERSION: cml
@@ -232,7 +232,7 @@ i915:cml:
 i915:tgl:
   extends:
 - .i915
-  parallel: 6
+  parallel: 8
   variables:
 DEVICE_TYPE: asus-cx9400-volteer
 GPU_VERSION: tgl
@@ -251,6 +251,7 @@ i915:tgl:
 amdgpu:stoney:
   extends:
 - .amdgpu
+  parallel: 2
   variables:
 DEVICE_TYPE: hp-11A-G6-EE-grunt
 GPU_VERSION: stoney
@@ -269,6 +270,7 @@ amdgpu:stoney:
 mediatek:mt8173:
   extends:
 - .mediatek
+  parallel: 4
   variables:
 DEVICE_TYPE: mt8173-elm-hana
 GPU_VERSION: mt8173
@@ -280,6 +282,7 @@ mediatek:mt8173:
 mediatek:mt8183:
   extends:
 - .mediatek
+  parallel: 3
   variables:
 DEVICE_TYPE: mt8183-kukui-jacuzzi-juniper-sku16
 GPU_VERSION: mt8183
@@ -289,6 +292,7 @@ mediatek:mt8183:
 .mediatek:mt8192:
   extends:
 - .mediatek
+  parallel: 3
   variables:
 DEVICE_TYPE: mt8192-asurada-spherion-r0
 GPU_VERSION: mt8192
@@ -307,6 +311,7 @@ mediatek:mt8183:
 meson:g12b:
   extends:
 - .meson
+  parallel: 3
   variables:
 DEVICE_TYPE: meson-g12b-a311d-khadas-vim3
 GPU_VERSION: g12b
-- 
2.39.2

[PATCH v3 05/10] drm/ci: clean up xfails (specially flakes list)

2023-10-23 Thread Helen Koike

Since the script that collected the list of the expectation files was
bogus and placing test to the flakes list incorrectly, restart the
expectation files with the correct script.

This reduces a lot the number of tests in the flakes list.

Signed-off-by: Helen Koike 
Reviewed-by: David Heidelberg 

---

v2:
- fix typo in the commit message
- re-add kms_cursor_legacy@flip-vs-cursor-toggle back to msm-sdm845-flakes.txt
- removed kms_async_flips@crc,Fail from i915-cml-fails.txt

v3:
- add kms_rmfb@close-fd,Fail to amdgpu-stoney-fails.txt
- add kms_async_flips@crc to i915-kbl-flakes.txt

Signed-off-by: Helen Koike 
---
 .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt | 12 +-
 .../drm/ci/xfails/amdgpu-stoney-flakes.txt| 20 -
 drivers/gpu/drm/ci/xfails/i915-amly-fails.txt |  9 
 .../gpu/drm/ci/xfails/i915-amly-flakes.txt| 32 ---
 drivers/gpu/drm/ci/xfails/i915-apl-fails.txt  | 11 -
 drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt |  1 -
 drivers/gpu/drm/ci/xfails/i915-cml-fails.txt  | 14 ++-
 drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt | 38 -
 drivers/gpu/drm/ci/xfails/i915-glk-fails.txt  | 17 
 drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt | 41 ---
 drivers/gpu/drm/ci/xfails/i915-kbl-fails.txt  |  7 
 drivers/gpu/drm/ci/xfails/i915-kbl-flakes.txt | 25 ---
 drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt  |  1 -
 drivers/gpu/drm/ci/xfails/i915-tgl-flakes.txt |  5 ---
 drivers/gpu/drm/ci/xfails/i915-whl-flakes.txt |  1 -
 .../drm/ci/xfails/mediatek-mt8173-flakes.txt  |  0
 .../drm/ci/xfails/mediatek-mt8183-fails.txt   |  5 ++-
 .../drm/ci/xfails/mediatek-mt8183-flakes.txt  | 14 ---
 .../gpu/drm/ci/xfails/meson-g12b-fails.txt| 14 ---
 .../gpu/drm/ci/xfails/meson-g12b-flakes.txt   |  4 --
 .../gpu/drm/ci/xfails/msm-apq8016-flakes.txt  |  4 --
 .../gpu/drm/ci/xfails/msm-apq8096-fails.txt   |  2 +
 .../gpu/drm/ci/xfails/msm-apq8096-flakes.txt  |  4 --
 .../gpu/drm/ci/xfails/msm-sc7180-fails.txt| 15 ---
 .../gpu/drm/ci/xfails/msm-sc7180-flakes.txt   | 24 +++
 .../gpu/drm/ci/xfails/msm-sc7180-skips.txt| 18 +---
 .../gpu/drm/ci/xfails/msm-sdm845-fails.txt|  9 +---
 .../gpu/drm/ci/xfails/msm-sdm845-flakes.txt   | 19 +
 .../drm/ci/xfails/rockchip-rk3288-fails.txt   |  6 +++
 .../drm/ci/xfails/rockchip-rk3288-flakes.txt  |  9 
 .../drm/ci/xfails/rockchip-rk3399-fails.txt   | 40 +-
 .../drm/ci/xfails/rockchip-rk3399-flakes.txt  | 28 +++--
 .../drm/ci/xfails/virtio_gpu-none-flakes.txt  |  0
 33 files changed, 162 insertions(+), 287 deletions(-)
 delete mode 100644 drivers/gpu/drm/ci/xfails/i915-amly-flakes.txt
 delete mode 100644 drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt
 delete mode 100644 drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt
 delete mode 100644 drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt
 delete mode 100644 drivers/gpu/drm/ci/xfails/i915-tgl-flakes.txt
 delete mode 100644 drivers/gpu/drm/ci/xfails/i915-whl-flakes.txt
 delete mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt
 delete mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8183-flakes.txt
 delete mode 100644 drivers/gpu/drm/ci/xfails/meson-g12b-flakes.txt
 delete mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8016-flakes.txt
 delete mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8096-flakes.txt
 delete mode 100644 drivers/gpu/drm/ci/xfails/rockchip-rk3288-flakes.txt
 delete mode 100644 drivers/gpu/drm/ci/xfails/virtio_gpu-none-flakes.txt

diff --git a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt 
b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt
index bd9392536e7c..ea87dc46bc2b 100644
--- a/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt
+++ b/drivers/gpu/drm/ci/xfails/amdgpu-stoney-fails.txt
@@ -1,8 +1,14 @@
 kms_addfb_basic@bad-pitch-65536,Fail
 kms_addfb_basic@bo-too-small,Fail
+kms_addfb_basic@too-high,Fail
+kms_async_flips@async-flip-with-page-flip-events,Fail
+kms_async_flips@crc,Fail
 kms_async_flips@invalid-async-flip,Fail
-kms_atomic@plane-immutable-zpos,Fail
+kms_atomic_transition@plane-all-modeset-transition-internal-panels,Fail
+kms_atomic_transition@plane-all-transition,Fail
+kms_atomic_transition@plane-all-transition-nonblocking,Fail
 kms_atomic_transition@plane-toggle-modeset-transition,Fail
+kms_atomic_transition@plane-use-after-nonblocking-unbind,Fail
 kms_bw@linear-tiling-1-displays-2560x1440p,Fail
 kms_bw@linear-tiling-1-displays-3840x2160p,Fail
 kms_bw@linear-tiling-2-displays-3840x2160p,Fail
@@ -11,9 +17,11 @@ kms_color@degamma,Fail
 kms_cursor_crc@cursor-size-change,Fail
 kms_cursor_crc@pipe-A-cursor-size-change,Fail
 kms_cursor_crc@pipe-B-cursor-size-change,Fail
-kms_cursor_legacy@forked-move,Fail
+kms_flip@flip-vs-modeset-vs-hang,Fail
+kms_flip@flip-vs-panning-vs-hang,Fail
 kms_hdr@bpc-switch,Fail
 kms_hdr@bpc-switch-dpms,Fail
+kms_plane@pixel-format,Fail
 kms_plane_multiple@atomic-pipe-A-tiling-none,Fail
 kms_rmfb@close-fd,Fail

[PATCH v3 04/10] drm/ci: uprev IGT and make sure core_getversion is run

2023-10-23 Thread Helen Koike

IGT has recently merged a patch that makes code_getversion test to fails
if the driver isn't loaded or if it isn't the expected one defined in
variable IGT_FORCE_DRIVER.

Without this test, jobs were passing when the driver didn't load or
probe for some reason, giving the illusion that everything was ok.

Uprev IGT to include this modification and include core_getversion test
in all the shards.

Signed-off-by: Helen Koike 
Reviewed-by: David Heidelberg 

---

v2:
- fixed typo in the commit message
v3:
- no changes
---
 drivers/gpu/drm/ci/gitlab-ci.yml  |  2 +-
 drivers/gpu/drm/ci/igt_runner.sh  | 31 ---
 drivers/gpu/drm/ci/image-tags.yml |  2 +-
 3 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml
index 452b9c2532ae..c08ea6097b1d 100644
--- a/drivers/gpu/drm/ci/gitlab-ci.yml
+++ b/drivers/gpu/drm/ci/gitlab-ci.yml
@@ -5,7 +5,7 @@ variables:
   UPSTREAM_REPO: git://anongit.freedesktop.org/drm/drm
   TARGET_BRANCH: drm-next
 
-  IGT_VERSION: 471bfababd070e1dac0ebb87470ac4f2ae85e663
+  IGT_VERSION: d1db7333d9c5fbbb05e50b0804123950d9dc1c46
 
   DEQP_RUNNER_GIT_URL: https://gitlab.freedesktop.org/anholt/deqp-runner.git
   DEQP_RUNNER_GIT_TAG: v0.15.0
diff --git a/drivers/gpu/drm/ci/igt_runner.sh b/drivers/gpu/drm/ci/igt_runner.sh
index 2bb759165063..2f815ee3a8a3 100755
--- a/drivers/gpu/drm/ci/igt_runner.sh
+++ b/drivers/gpu/drm/ci/igt_runner.sh
@@ -20,11 +20,16 @@ set +e
 cat /sys/kernel/debug/dri/*/state
 set -e
 
-# Cannot use HWCI_KERNEL_MODULES as at that point we don't have the module in 
/lib
-if [ "$IGT_FORCE_DRIVER" = "amdgpu" ]; then
-mv /install/modules/lib/modules/* /lib/modules/.
-modprobe amdgpu
-fi
+case "$DRIVER_NAME" in
+rockchip|mediatek|meson)
+export IGT_FORCE_DRIVER="panfrost"
+;;
+amdgpu)
+# Cannot use HWCI_KERNEL_MODULES as at that point we don't have the 
module in /lib
+mv /install/modules/lib/modules/* /lib/modules/.
+modprobe amdgpu
+;;
+esac
 
 if [ -e "/install/xfails/$DRIVER_NAME-$GPU_VERSION-skips.txt" ]; then
 IGT_SKIPS="--skips /install/xfails/$DRIVER_NAME-$GPU_VERSION-skips.txt"
@@ -48,6 +53,20 @@ fi
 
 curl -L --retry 4 -f --retry-all-errors --retry-delay 60 -s 
${FDO_HTTP_CACHE_URI:-}$PIPELINE_ARTIFACTS_BASE/$ARCH/igt.tar.gz | tar --zstd 
-v -x -C /
 
+
+# If the job is parallel at the gitab job level, take the corresponding 
fraction
+# of the caselist.
+if [ -n "$CI_NODE_INDEX" ]; then
+sed -ni $CI_NODE_INDEX~$CI_NODE_TOTAL"p" /install/testlist.txt
+fi
+
+# core_getversion checks if the driver is loaded and probed correctly
+# so run it in all shards
+if ! grep -q "core_getversion" /install/testlist.txt; then
+# Add the line to the file
+echo "core_getversion" >> /install/testlist.txt
+fi
+
 set +e
 igt-runner \
 run \
@@ -57,8 +76,6 @@ igt-runner \
 $IGT_SKIPS \
 $IGT_FLAKES \
 $IGT_FAILS \
---fraction-start $CI_NODE_INDEX \
---fraction $CI_NODE_TOTAL \
 --jobs 1
 ret=$?
 set -e
diff --git a/drivers/gpu/drm/ci/image-tags.yml 
b/drivers/gpu/drm/ci/image-tags.yml
index e1b387581c11..7dd3f995f8a2 100644
--- a/drivers/gpu/drm/ci/image-tags.yml
+++ b/drivers/gpu/drm/ci/image-tags.yml
@@ -4,7 +4,7 @@ variables:
DEBIAN_BASE_TAG: "${CONTAINER_TAG}"
 
DEBIAN_X86_64_BUILD_IMAGE_PATH: "debian/x86_64_build"
-   DEBIAN_BUILD_TAG: "2023-10-06-amd"
+   DEBIAN_BUILD_TAG: "2023-10-08-igt"
 
KERNEL_ROOTFS_TAG: "2023-10-06-amd"
 
-- 
2.39.2

[PATCH v3 03/10] drm/ci: add helper script update-xfails.py

2023-10-23 Thread Helen Koike

Add helper script that given a gitlab pipeline url, analyse which are
the failures and flakes and update the xfails folder accordingly.

Example:
Trigger a pipeline in gitlab infrastructure, than re-try a few jobs more
than once (so we can have data if failures are consistent across jobs
with the same name or if they are flakes) and execute:

update-xfails.py 
https://gitlab.freedesktop.org/helen.fornazier/linux/-/pipelines/970661

git diff should show you that it updated files in xfails folder.

Signed-off-by: Helen Koike 
Tested-by: Vignesh Raman 
Reviewed-by: David Heidelberg 

---

Hello,

This script is being very handy for me, so I suppose it could be handy
to others, since I'm publishing it in the xfails folder.

Let me know your thoughts.

Derivative work from the RFC: 
https://patchwork.kernel.org/project/dri-devel/patch/20230925195556.106090-1-helen.ko...@collabora.com/
what changed:
- refactor and fix the script, it had several bugs
- change the output to show a diff of what has changed

Regards,
Helen
---

v2:
- fixed typos
- remove test from fails.txt before adding to flakes.txt if present
- fix when the failures.csv is an empty string

v3:
- point requirements.txt to the latest ci-collate with the fix for empty 
artifacts file
- fix typo on parse help
---
 drivers/gpu/drm/ci/xfails/requirements.txt |  17 ++
 drivers/gpu/drm/ci/xfails/update-xfails.py | 204 +
 2 files changed, 221 insertions(+)
 create mode 100644 drivers/gpu/drm/ci/xfails/requirements.txt
 create mode 100755 drivers/gpu/drm/ci/xfails/update-xfails.py

diff --git a/drivers/gpu/drm/ci/xfails/requirements.txt 
b/drivers/gpu/drm/ci/xfails/requirements.txt
new file mode 100644
index ..d8856d1581fd
--- /dev/null
+++ b/drivers/gpu/drm/ci/xfails/requirements.txt
@@ -0,0 +1,17 @@
+git+https://gitlab.freedesktop.org/gfx-ci/ci-collate@09e7142715c16f54344ddf97013331ba063b162b
+termcolor==2.3.0
+
+# ci-collate dependencies
+certifi==2023.7.22
+charset-normalizer==3.2.0
+idna==3.4
+pip==23.2.1
+python-gitlab==3.15.0
+requests==2.31.0
+requests-toolbelt==1.0.0
+ruamel.yaml==0.17.32
+ruamel.yaml.clib==0.2.7
+setuptools==68.0.0
+tenacity==8.2.3
+urllib3==2.0.4
+wheel==0.41.1
\ No newline at end of file
diff --git a/drivers/gpu/drm/ci/xfails/update-xfails.py 
b/drivers/gpu/drm/ci/xfails/update-xfails.py
new file mode 100755
index ..e9f0ec7fed8d
--- /dev/null
+++ b/drivers/gpu/drm/ci/xfails/update-xfails.py
@@ -0,0 +1,204 @@
+#!/usr/bin/env python3
+
+import argparse
+from collections import defaultdict
+import difflib
+import os
+import re
+from glcollate import Collate
+from termcolor import colored
+from urllib.parse import urlparse
+
+
+def get_canonical_name(job_name):
+return re.split(r" \d+/\d+", job_name)[0]
+
+
+def get_xfails_file_path(job_name, suffix):
+canonical_name = get_canonical_name(job_name)
+name = canonical_name.replace(":", "-")
+script_dir = os.path.dirname(os.path.abspath(__file__))
+return os.path.join(script_dir, f"{name}-{suffix}.txt")
+
+
+def get_unit_test_name_and_results(unit_test):
+if "Artifact results/failures.csv not found" in unit_test or '' == 
unit_test:
+return None, None
+unit_test_name, unit_test_result = unit_test.strip().split(",")
+return unit_test_name, unit_test_result
+
+
+def read_file(file_path):
+try:
+with open(file_path, "r") as file:
+f = file.readlines()
+if len(f):
+f[-1] = f[-1].strip() + "\n"
+return f
+except FileNotFoundError:
+return []
+
+
+def save_file(content, file_path):
+# delete file is content is empty
+if not content or not any(content):
+if os.path.exists(file_path):
+os.remove(file_path)
+return
+
+with open(file_path, "w") as file:
+file.writelines(content)
+
+
+def is_test_present_on_file(file_content, unit_test_name):
+return any(unit_test_name in line for line in file_content)
+
+
+def is_unit_test_present_in_other_jobs(unit_test, job_ids):
+return all(unit_test in job_ids[job_id] for job_id in job_ids)
+
+
+def remove_unit_test_if_present(lines, unit_test_name):
+if not is_test_present_on_file(lines, unit_test_name):
+return
+lines[:] = [line for line in lines if unit_test_name not in line]
+
+
+def add_unit_test_if_not_present(lines, unit_test_name, file_name):
+# core_getversion is mandatory
+if "core_getversion" in unit_test_name:
+print("WARNING: core_getversion should pass, not adding it to", 
os.path.basename(file_name))
+elif all(unit_test_name not in line for line in lines):
+lines.append(unit_test_name + "\n")
+
+
+def update_unit_test_result_in_fails_txt(fails_txt, unit_test):
+unit_test_name, unit_test_result = 
get_unit_test_name_and_results(unit_test)
+for i, line in enumerate(fails_txt):
+if unit_test_name in line:
+_, current_result = get_unit_test_name_and_results(line)

[PATCH v3 02/10] drm/ci: fix DEBIAN_ARCH and get amdgpu probing

2023-10-23 Thread Helen Koike

amdgpu driver wasn't loading because amdgpu firmware wasn't being
installed in the rootfs due to the wrong DEBIAN_ARCH variable.

rename ARCH to DEBIAN_ARCH also, so we don't have the confusing
DEBIAN_ARCH, KERNEL_ARCH and ARCH.

Signed-off-by: Helen Koike 
Reviewed-by: David Heidelberg 

---

v2:
- fix typos in commit message
v3:
- no changes
---
 drivers/gpu/drm/ci/build.sh   | 2 +-
 drivers/gpu/drm/ci/image-tags.yml | 4 ++--
 drivers/gpu/drm/ci/lava-submit.sh | 4 ++--
 drivers/gpu/drm/ci/test.yml   | 6 +++---
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ci/build.sh b/drivers/gpu/drm/ci/build.sh
index 20a6ba8a7b04..e3908f4d71cb 100644
--- a/drivers/gpu/drm/ci/build.sh
+++ b/drivers/gpu/drm/ci/build.sh
@@ -35,7 +35,7 @@ elif [[ "$KERNEL_ARCH" = "arm" ]]; then
 apt-get install -y libssl-dev:armhf
 else
 GCC_ARCH="x86_64-linux-gnu"
-DEBIAN_ARCH="x86_64"
+DEBIAN_ARCH="amd64"
 DEVICE_TREES=""
 fi
 
diff --git a/drivers/gpu/drm/ci/image-tags.yml 
b/drivers/gpu/drm/ci/image-tags.yml
index 157d987149f0..e1b387581c11 100644
--- a/drivers/gpu/drm/ci/image-tags.yml
+++ b/drivers/gpu/drm/ci/image-tags.yml
@@ -4,9 +4,9 @@ variables:
DEBIAN_BASE_TAG: "${CONTAINER_TAG}"
 
DEBIAN_X86_64_BUILD_IMAGE_PATH: "debian/x86_64_build"
-   DEBIAN_BUILD_TAG: "${CONTAINER_TAG}"
+   DEBIAN_BUILD_TAG: "2023-10-06-amd"
 
-   KERNEL_ROOTFS_TAG: "${CONTAINER_TAG}"
+   KERNEL_ROOTFS_TAG: "2023-10-06-amd"
 
DEBIAN_X86_64_TEST_BASE_IMAGE: "debian/x86_64_test-base"
DEBIAN_X86_64_TEST_IMAGE_GL_PATH: "debian/x86_64_test-gl"
diff --git a/drivers/gpu/drm/ci/lava-submit.sh 
b/drivers/gpu/drm/ci/lava-submit.sh
index 379f26ea87cc..3d39b0c916a8 100755
--- a/drivers/gpu/drm/ci/lava-submit.sh
+++ b/drivers/gpu/drm/ci/lava-submit.sh
@@ -37,8 +37,8 @@ PYTHONPATH=artifacts/ artifacts/lava/lava_job_submitter.py \
--dump-yaml \
--pipeline-info "$CI_JOB_NAME: $CI_PIPELINE_URL on $CI_COMMIT_REF_NAME 
${CI_NODE_INDEX}/${CI_NODE_TOTAL}" \
--rootfs-url-prefix "https://${BASE_SYSTEM_HOST_PATH}; \
-   --kernel-url-prefix "https://${PIPELINE_ARTIFACTS_BASE}/${ARCH}; \
-   --build-url 
"${FDO_HTTP_CACHE_URI:-}https://${PIPELINE_ARTIFACTS_BASE}/${ARCH}/kernel-files.tar.zst;
 \
+   --kernel-url-prefix "https://${PIPELINE_ARTIFACTS_BASE}/${DEBIAN_ARCH}; 
\
+   --build-url 
"${FDO_HTTP_CACHE_URI:-}https://${PIPELINE_ARTIFACTS_BASE}/${DEBIAN_ARCH}/kernel-files.tar.zst;
 \
--job-rootfs-overlay-url 
"${FDO_HTTP_CACHE_URI:-}https://${JOB_ROOTFS_OVERLAY_PATH}; \
--job-timeout-min ${JOB_TIMEOUT:-80} \
--first-stage-init artifacts/ci-common/init-stage1.sh \
diff --git a/drivers/gpu/drm/ci/test.yml b/drivers/gpu/drm/ci/test.yml
index 6473cddaa7a9..3479d2a0108d 100644
--- a/drivers/gpu/drm/ci/test.yml
+++ b/drivers/gpu/drm/ci/test.yml
@@ -23,7 +23,7 @@
 - .lava-test:arm32
   variables:
 HWCI_TEST_SCRIPT: "/install/igt_runner.sh"
-ARCH: "armhf"
+DEBIAN_ARCH: "armhf"
   dependencies:
 - testing:arm32
   needs:
@@ -38,7 +38,7 @@
 - .lava-test:arm64
   variables:
 HWCI_TEST_SCRIPT: "/install/igt_runner.sh"
-ARCH: "arm64"
+DEBIAN_ARCH: "arm64"
   dependencies:
 - testing:arm64
   needs:
@@ -53,7 +53,7 @@
 - .lava-test:x86_64
   variables:
 HWCI_TEST_SCRIPT: "/install/igt_runner.sh"
-ARCH: "x86_64"
+DEBIAN_ARCH: "amd64"
   dependencies:
 - testing:x86_64
   needs:
-- 
2.39.2

[PATCH v3 00/10] drm/ci: fixes and improvements

2023-10-23 Thread Helen Koike

This series contains the several fixes, making drm/ci much
more reliable and useful.

Highlights:

* Current DRM/CI in drm-misc is broken, this series fixes it with mesa
  uprev (commit 1/9).

* The fails.txt and flakes.txt lists were generated by a bogus script,
  this series restart that initial list from scratch (commit 5/9),
  which reduced considerably the number of flakes.

* Jobs are run in a subset of available DUTs in the Lava farm
  (commit 6/9) to not block merge requests for Mesa3D.

* Add python script update-xfails.py to update the xfails lists
  (commit 3/9).

Tested on 
https://gitlab.freedesktop.org/helen.fornazier/linux/-/pipelines/1014358

To work properly, the following patches are also required:

[PATCH 2/2] drm/ci: force-enable CONFIG_MSM_MMCC_8996 as built-in
https://patchwork.kernel.org/project/linux-arm-msm/patch/20231008132320.762542-2-dmitry.barysh...@linaro.org/

[PATCH] drm/ci: Enable CONFIG_BACKLIGHT_CLASS_DEVICE
https://patchwork.kernel.org/project/dri-devel/patch/20231002164715.157298-1-robdcl...@gmail.com/

v3 changes:
- adjust timeout of i915 so jobs can pass
- small adjustments in the flakes list
- point requirements.txt to new ci-collate to fix flakes
- update to latest version of mesa to get the patch that disables bare-metal 
retries
- fix typos

Helen Koike (10):
  drm/ci: uprev mesa version: fix container build & crosvm
  drm/ci: fix DEBIAN_ARCH and get amdgpu probing
  drm/ci: add helper script update-xfails.py
  drm/ci: uprev IGT and make sure core_getversion is run
  drm/ci: clean up xfails (specially flakes list)
  drm/ci: add subset-1-gfx to LAVA_TAGS and adjust shards
  drm/ci: increase i915 job timeout to 1h30m
  drm/ci: export kernel config
  drm/ci: do not automatically retry on error
  drm/ci: docs: add step about how to request privileges

 Documentation/gpu/automated_testing.rst   |   7 +-
 drivers/gpu/drm/ci/build.sh   |   3 +-
 drivers/gpu/drm/ci/build.yml  |   1 +
 drivers/gpu/drm/ci/gitlab-ci.yml  |  38 ++--
 drivers/gpu/drm/ci/igt_runner.sh  |  31 ++-
 drivers/gpu/drm/ci/image-tags.yml |   6 +-
 drivers/gpu/drm/ci/lava-submit.sh |   6 +-
 drivers/gpu/drm/ci/test.yml   |  34 +--
 .../gpu/drm/ci/xfails/amdgpu-stoney-fails.txt |  12 +-
 .../drm/ci/xfails/amdgpu-stoney-flakes.txt|  20 --
 drivers/gpu/drm/ci/xfails/i915-amly-fails.txt |   9 +
 .../gpu/drm/ci/xfails/i915-amly-flakes.txt|  32 ---
 drivers/gpu/drm/ci/xfails/i915-apl-fails.txt  |  11 -
 drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt |   1 -
 drivers/gpu/drm/ci/xfails/i915-cml-fails.txt  |  14 +-
 drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt |  38 
 drivers/gpu/drm/ci/xfails/i915-glk-fails.txt  |  17 ++
 drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt |  41 
 drivers/gpu/drm/ci/xfails/i915-kbl-fails.txt  |   7 +
 drivers/gpu/drm/ci/xfails/i915-kbl-flakes.txt |  25 ---
 drivers/gpu/drm/ci/xfails/i915-tgl-fails.txt  |   1 -
 drivers/gpu/drm/ci/xfails/i915-tgl-flakes.txt |   5 -
 drivers/gpu/drm/ci/xfails/i915-whl-flakes.txt |   1 -
 .../drm/ci/xfails/mediatek-mt8173-flakes.txt  |   0
 .../drm/ci/xfails/mediatek-mt8183-fails.txt   |   5 +-
 .../drm/ci/xfails/mediatek-mt8183-flakes.txt  |  14 --
 .../gpu/drm/ci/xfails/meson-g12b-fails.txt|  14 +-
 .../gpu/drm/ci/xfails/meson-g12b-flakes.txt   |   4 -
 .../gpu/drm/ci/xfails/msm-apq8016-flakes.txt  |   4 -
 .../gpu/drm/ci/xfails/msm-apq8096-fails.txt   |   2 +
 .../gpu/drm/ci/xfails/msm-apq8096-flakes.txt  |   4 -
 .../gpu/drm/ci/xfails/msm-sc7180-fails.txt|  15 +-
 .../gpu/drm/ci/xfails/msm-sc7180-flakes.txt   |  24 ++-
 .../gpu/drm/ci/xfails/msm-sc7180-skips.txt|  18 +-
 .../gpu/drm/ci/xfails/msm-sdm845-fails.txt|   9 +-
 .../gpu/drm/ci/xfails/msm-sdm845-flakes.txt   |  19 +-
 drivers/gpu/drm/ci/xfails/requirements.txt|  17 ++
 .../drm/ci/xfails/rockchip-rk3288-fails.txt   |   6 +
 .../drm/ci/xfails/rockchip-rk3288-flakes.txt  |   9 -
 .../drm/ci/xfails/rockchip-rk3399-fails.txt   |  40 +++-
 .../drm/ci/xfails/rockchip-rk3399-flakes.txt  |  28 +--
 drivers/gpu/drm/ci/xfails/update-xfails.py| 204 ++
 .../drm/ci/xfails/virtio_gpu-none-flakes.txt  |   0
 43 files changed, 464 insertions(+), 332 deletions(-)
 delete mode 100644 drivers/gpu/drm/ci/xfails/i915-amly-flakes.txt
 delete mode 100644 drivers/gpu/drm/ci/xfails/i915-apl-flakes.txt
 delete mode 100644 drivers/gpu/drm/ci/xfails/i915-cml-flakes.txt
 delete mode 100644 drivers/gpu/drm/ci/xfails/i915-glk-flakes.txt
 delete mode 100644 drivers/gpu/drm/ci/xfails/i915-tgl-flakes.txt
 delete mode 100644 drivers/gpu/drm/ci/xfails/i915-whl-flakes.txt
 delete mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8173-flakes.txt
 delete mode 100644 drivers/gpu/drm/ci/xfails/mediatek-mt8183-flakes.txt
 delete mode 100644 drivers/gpu/drm/ci/xfails/meson-g12b-flakes.txt
 delete mode 100644 drivers/gpu/drm/ci/xfails/msm-apq8016-flakes.txt
 delete mode 100644

[PATCH v3 01/10] drm/ci: uprev mesa version: fix container build & crosvm

2023-10-23 Thread Helen Koike

When building containers, some rust packages were installed without
locking the dependencies version, which got updated and started giving
errors like:

error: failed to compile `bindgen-cli v0.62.0`, intermediate artifacts can be 
found at `/tmp/cargo-installkNKRwf`
Caused by:
  package `rustix v0.38.13` cannot be built because it requires rustc 1.63 or 
newer, while the currently active rustc version is 1.60.0

A patch to Mesa was added fixing this error, so update it.

Also, commit in linux kernel 6.6 rc3 broke booting in crosvm.
Mesa has upreved crosvm to fix this issue.

Signed-off-by: Helen Koike 
[crosvm mesa update]
Co-Developed-by: Vignesh Raman 
Signed-off-by: Vignesh Raman 
[v1 container build uprev]
Tested-by: Jessica Zhang 
Acked-by: Jessica Zhang 
Reviewed-by: David Heidelberg 

---

v2:
- update to an even newer version of mesa to integrate crosvm uprev

v3:
- update to newest version of mesa, to get the patch that disables
  bare-metal retries
---
 drivers/gpu/drm/ci/build.yml  |  1 +
 drivers/gpu/drm/ci/gitlab-ci.yml  | 20 +++-
 drivers/gpu/drm/ci/image-tags.yml |  2 +-
 drivers/gpu/drm/ci/lava-submit.sh |  2 +-
 4 files changed, 22 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ci/build.yml b/drivers/gpu/drm/ci/build.yml
index e6503f1c5927..17ab38304885 100644
--- a/drivers/gpu/drm/ci/build.yml
+++ b/drivers/gpu/drm/ci/build.yml
@@ -1,6 +1,7 @@
 .build:
   extends:
 - .build-rules
+- .container+build-rules
   stage: build
   artifacts:
 paths:
diff --git a/drivers/gpu/drm/ci/gitlab-ci.yml b/drivers/gpu/drm/ci/gitlab-ci.yml
index 2c4df53f5dfe..452b9c2532ae 100644
--- a/drivers/gpu/drm/ci/gitlab-ci.yml
+++ b/drivers/gpu/drm/ci/gitlab-ci.yml
@@ -1,6 +1,6 @@
 variables:
   DRM_CI_PROJECT_PATH:  mesa/mesa
-  DRM_CI_COMMIT_SHA:  
0dc961645c4f0241f8512cb0ec3ad59635842072
+  DRM_CI_COMMIT_SHA:  
edfbf74df1d4d6ce54ffe24566108be0e1a98c3d
 
   UPSTREAM_REPO: git://anongit.freedesktop.org/drm/drm
   TARGET_BRANCH: drm-next
@@ -24,6 +24,8 @@ variables:
   PIPELINE_ARTIFACTS_BASE: 
${S3_HOST}/artifacts/${CI_PROJECT_PATH}/${CI_PIPELINE_ID}
   # per-job artifact storage on MinIO
   JOB_ARTIFACTS_BASE: ${PIPELINE_ARTIFACTS_BASE}/${CI_JOB_ID}
+  # default kernel for rootfs before injecting the current kernel tree
+  KERNEL_IMAGE_BASE: 
https://${S3_HOST}/mesa-lava/gfx-ci/linux/v6.4.12-for-mesa-ci-f6b4ad45f48d
 
   LAVA_JOB_PRIORITY: 30
 
@@ -86,6 +88,17 @@ include:
   - '/.gitlab-ci/container/gitlab-ci.yml'
   - '/.gitlab-ci/test/gitlab-ci.yml'
   - '/.gitlab-ci/lava/lava-gitlab-ci.yml'
+  - '/src/microsoft/ci/gitlab-ci-inc.yml'
+  - '/src/gallium/drivers/zink/ci/gitlab-ci-inc.yml'
+  - '/src/gallium/drivers/crocus/ci/gitlab-ci-inc.yml'
+  - '/src/gallium/drivers/softpipe/ci/gitlab-ci-inc.yml'
+  - '/src/gallium/drivers/llvmpipe/ci/gitlab-ci-inc.yml'
+  - '/src/gallium/drivers/virgl/ci/gitlab-ci-inc.yml'
+  - '/src/gallium/drivers/nouveau/ci/gitlab-ci-inc.yml'
+  - '/src/gallium/frontends/lavapipe/ci/gitlab-ci-inc.yml'
+  - '/src/intel/ci/gitlab-ci-inc.yml'
+  - '/src/freedreno/ci/gitlab-ci-inc.yml'
+  - '/src/amd/ci/gitlab-ci-inc.yml'
   - drivers/gpu/drm/ci/image-tags.yml
   - drivers/gpu/drm/ci/container.yml
   - drivers/gpu/drm/ci/static-checks.yml
@@ -154,6 +167,11 @@ stages:
 # Run automatically once all dependency jobs have passed
 - when: on_success
 
+# When to automatically run the CI for container jobs
+.container+build-rules:
+  rules:
+- !reference [.no_scheduled_pipelines-rules, rules]
+- when: manual
 
 .ci-deqp-artifacts:
   artifacts:
diff --git a/drivers/gpu/drm/ci/image-tags.yml 
b/drivers/gpu/drm/ci/image-tags.yml
index f051b6c547c5..157d987149f0 100644
--- a/drivers/gpu/drm/ci/image-tags.yml
+++ b/drivers/gpu/drm/ci/image-tags.yml
@@ -1,5 +1,5 @@
 variables:
-   CONTAINER_TAG: "2023-08-10-mesa-uprev"
+   CONTAINER_TAG: "2023-10-11-mesa-uprev"
DEBIAN_X86_64_BUILD_BASE_IMAGE: "debian/x86_64_build-base"
DEBIAN_BASE_TAG: "${CONTAINER_TAG}"
 
diff --git a/drivers/gpu/drm/ci/lava-submit.sh 
b/drivers/gpu/drm/ci/lava-submit.sh
index 0c4456b21b0f..379f26ea87cc 100755
--- a/drivers/gpu/drm/ci/lava-submit.sh
+++ b/drivers/gpu/drm/ci/lava-submit.sh
@@ -22,7 +22,7 @@ cp "$SCRIPTS_DIR"/setup-test-env.sh 
results/job-rootfs-overlay/
 
 # Prepare env vars for upload.
 section_start variables "Variables passed through:"
-KERNEL_IMAGE_BASE_URL="https://${BASE_SYSTEM_HOST_PATH}; \
+KERNEL_IMAGE_BASE="https://${BASE_SYSTEM_HOST_PATH}; \
artifacts/ci-common/generate-env.sh | tee 
results/job-rootfs-overlay/set-job-env-vars.sh
 section_end variables
 
-- 
2.39.2

Re: [PATCH] drm/msm/dpu: Fix encoder CRC to account for CTM enablement

2023-10-23 Thread Dmitry Baryshkov

On Tue, 24 Oct 2023 at 01:36, Rob Clark  wrote:
>
> On Mon, Oct 23, 2023 at 3:30 PM Dmitry Baryshkov
>  wrote:
> >
> > On Tue, 24 Oct 2023 at 01:12, Rob Clark  wrote:
> > >
> > > From: Rob Clark 
> > >
> > > Seems like we need to pick INPUT_SEL=1 when CTM is enabled.  But not
> > > otherwise.
> > >
> > > Suggested-by: Dmitry Baryshkov 
> > > Signed-off-by: Rob Clark 
> > > ---
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 2 +-
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 ++--
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 3 ++-
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 4 ++--
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 2 +-
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c   | 2 +-
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c | 5 -
> > >  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 3 ++-
> > >  8 files changed, 15 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
> > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > index 2b83a13b3aa9..d93a92ffd5df 100644
> > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > > @@ -134,7 +134,7 @@ static void dpu_crtc_setup_encoder_misr(struct 
> > > drm_crtc *crtc)
> > > struct drm_encoder *drm_enc;
> > >
> > > drm_for_each_encoder_mask(drm_enc, crtc->dev, 
> > > crtc->state->encoder_mask)
> > > -   dpu_encoder_setup_misr(drm_enc);
> > > +   dpu_encoder_setup_misr(drm_enc, !!crtc->state->ctm);
> > >  }
> > >
> > >  static int dpu_crtc_set_crc_source(struct drm_crtc *crtc, const char 
> > > *src_name)
> > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
> > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > > index b0a7908418ed..12ee7acb5ea6 100644
> > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > > @@ -241,7 +241,7 @@ int dpu_encoder_get_crc_values_cnt(const struct 
> > > drm_encoder *drm_enc)
> > > return num_intf;
> > >  }
> > >
> > > -void dpu_encoder_setup_misr(const struct drm_encoder *drm_enc)
> > > +void dpu_encoder_setup_misr(const struct drm_encoder *drm_enc, bool 
> > > has_ctm)
> > >  {
> > > struct dpu_encoder_virt *dpu_enc;
> > >
> > > @@ -255,7 +255,7 @@ void dpu_encoder_setup_misr(const struct drm_encoder 
> > > *drm_enc)
> > > if (!phys->hw_intf || !phys->hw_intf->ops.setup_misr)
> > > continue;
> > >
> > > -   phys->hw_intf->ops.setup_misr(phys->hw_intf, true, 1);
> > > +   phys->hw_intf->ops.setup_misr(phys->hw_intf, true, 1, 
> > > has_ctm);
> > > }
> > >  }
> > >
> > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h 
> > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> > > index 4c05fd5e9ed1..510783b2fb24 100644
> > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> > > @@ -169,8 +169,9 @@ int dpu_encoder_get_crc_values_cnt(const struct 
> > > drm_encoder *drm_enc);
> > >  /**
> > >   * dpu_encoder_setup_misr - enable misr calculations
> > >   * @drm_enc:Pointer to previously created drm encoder structure
> > > + * @has_ctm:Is CTM enabled
> > >   */
> > > -void dpu_encoder_setup_misr(const struct drm_encoder *drm_encoder);
> > > +void dpu_encoder_setup_misr(const struct drm_encoder *drm_encoder, bool 
> > > has_ctm);
> > >
> > >  /**
> > >   * dpu_encoder_get_crc - get the crc value from interface blocks
> > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
> > > b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> > > index e8b8908d3e12..cb06f80cc671 100644
> > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> > > @@ -318,9 +318,9 @@ static u32 dpu_hw_intf_get_line_count(struct 
> > > dpu_hw_intf *intf)
> > > return DPU_REG_READ(c, INTF_LINE_COUNT);
> > >  }
> > >
> > > -static void dpu_hw_intf_setup_misr(struct dpu_hw_intf *intf, bool 
> > > enable, u32 frame_count)
> > > +static void dpu_hw_intf_setup_misr(struct dpu_hw_intf *intf, bool 
> > > enable, u32 frame_count, bool has_ctm)
> > >  {
> > > -   dpu_hw_setup_misr(>hw, INTF_MISR_CTRL, enable, frame_count);
> > > +   dpu_hw_setup_misr(>hw, INTF_MISR_CTRL, enable, frame_count, 
> > > has_ctm);
> >
> > I'm not sure about the dpu_encoder and dpu_hw_intf interfaces. But
> > dpu_hw_setup_misr definitely needs the `u8 input_sel` parameter
> > instead of `bool has_ctm`.
>
> That seems a bit premature without knowing what the other values are.
> (And I also question a bit the whole abstraction layer thing if it is
> taking directly register bitfield enum's..)

dpu_hw_intf and especially dpu_hw_util are not real abstractions. I
always viewed them as useful low-level helpers.

I think that has_ctm is valid at the dpu_encoder level, which selects
which input to use. on the lower levels has_ctm

Re: [PATCH drm-misc-next v2] drm/sched: implement dynamic job-flow control

2023-10-23 Thread Danilo Krummrich

On Tue, Oct 10, 2023 at 09:41:51AM +0200, Boris Brezillon wrote:
> On Tue, 10 Oct 2023 00:35:53 +0200
> Danilo Krummrich  wrote:
> 
> > Currently, job flow control is implemented simply by limiting the number
> > of jobs in flight. Therefore, a scheduler is initialized with a
> > submission limit that corresponds to the number of jobs which can be
> > sent to the hardware.
> > 
> > This implies that for each job, drivers need to account for the maximum
> > job size possible in order to not overflow the ring buffer.
> > 
> > However, there are drivers, such as Nouveau, where the job size has a
> > rather large range. For such drivers it can easily happen that job
> > submissions not even filling the ring by 1% can block subsequent
> > submissions, which, in the worst case, can lead to the ring run dry.
> > 
> > In order to overcome this issue, allow for tracking the actual job size
> > instead of the number of jobs. Therefore, add a field to track a job's
> > submission credits, which represents the number of credits a job
> > contributes to the scheduler's submission limit.
> > 
> > Signed-off-by: Danilo Krummrich 
> > ---
> > Changes in V2:
> > ==
> >   - fixed up influence on scheduling fairness due to consideration of a 
> > job's
> > size
> > - If we reach a ready entity in drm_sched_select_entity() but can't 
> > actually
> >   queue a job from it due to size limitations, just give up and go to 
> > sleep
> >   until woken up due to a pending job finishing, rather than continue 
> > to try
> >   other entities.
> >   - added a callback to dynamically update a job's credits (Boris)
> >   - renamed 'units' to 'credits'
> >   - fixed commit message and comments as requested by Luben
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c   |   2 +-
> >  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c  |   2 +-
> >  drivers/gpu/drm/lima/lima_sched.c |   2 +-
> >  drivers/gpu/drm/msm/msm_gem_submit.c  |   2 +-
> >  drivers/gpu/drm/nouveau/nouveau_sched.c   |   2 +-
> >  drivers/gpu/drm/panfrost/panfrost_drv.c   |   2 +-
> >  .../gpu/drm/scheduler/gpu_scheduler_trace.h   |   2 +-
> >  drivers/gpu/drm/scheduler/sched_entity.c  |   5 +-
> >  drivers/gpu/drm/scheduler/sched_main.c| 101 +-
> >  drivers/gpu/drm/v3d/v3d_gem.c |   2 +-
> >  include/drm/gpu_scheduler.h   |  33 --
> >  11 files changed, 115 insertions(+), 40 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> > index 78476bc75b4e..d54daaf64bf1 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> > @@ -115,7 +115,7 @@ int amdgpu_job_alloc(struct amdgpu_device *adev, struct 
> > amdgpu_vm *vm,
> > if (!entity)
> > return 0;
> >  
> > -   return drm_sched_job_init(&(*job)->base, entity, owner);
> > +   return drm_sched_job_init(&(*job)->base, entity, 1, owner);
> >  }
> >  
> >  int amdgpu_job_alloc_with_ib(struct amdgpu_device *adev,
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
> > b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> > index 45403ea38906..74a446711207 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> > @@ -538,7 +538,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, 
> > void *data,
> >  
> > ret = drm_sched_job_init(>sched_job,
> >  >sched_entity[args->pipe],
> > -submit->ctx);
> > +1, submit->ctx);
> > if (ret)
> > goto err_submit_put;
> >  
> > diff --git a/drivers/gpu/drm/lima/lima_sched.c 
> > b/drivers/gpu/drm/lima/lima_sched.c
> > index 50c2075228aa..5dc6678e1eb9 100644
> > --- a/drivers/gpu/drm/lima/lima_sched.c
> > +++ b/drivers/gpu/drm/lima/lima_sched.c
> > @@ -123,7 +123,7 @@ int lima_sched_task_init(struct lima_sched_task *task,
> > for (i = 0; i < num_bos; i++)
> > drm_gem_object_get([i]->base.base);
> >  
> > -   err = drm_sched_job_init(>base, >base, vm);
> > +   err = drm_sched_job_init(>base, >base, 1, vm);
> > if (err) {
> > kfree(task->bos);
> > return err;
> > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
> > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > index 3f1aa4de3b87..6d230c38e4f5 100644
> > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > @@ -48,7 +48,7 @@ static struct msm_gem_submit *submit_create(struct 
> > drm_device *dev,
> > return ERR_PTR(ret);
> > }
> >  
> > -   ret = drm_sched_job_init(>base, queue->entity, queue);
> > +   ret = drm_sched_job_init(>base, queue->entity, 1, queue);
> > if (ret) {
> > kfree(submit->hw_fence);
> > kfree(submit);
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_sched.c 
> >

Re: [PATCH] drm/msm/dpu: Fix encoder CRC to account for CTM enablement

2023-10-23 Thread Rob Clark

On Mon, Oct 23, 2023 at 3:30 PM Dmitry Baryshkov
 wrote:
>
> On Tue, 24 Oct 2023 at 01:12, Rob Clark  wrote:
> >
> > From: Rob Clark 
> >
> > Seems like we need to pick INPUT_SEL=1 when CTM is enabled.  But not
> > otherwise.
> >
> > Suggested-by: Dmitry Baryshkov 
> > Signed-off-by: Rob Clark 
> > ---
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 2 +-
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 ++--
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 3 ++-
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 4 ++--
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 2 +-
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c   | 2 +-
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c | 5 -
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 3 ++-
> >  8 files changed, 15 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > index 2b83a13b3aa9..d93a92ffd5df 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> > @@ -134,7 +134,7 @@ static void dpu_crtc_setup_encoder_misr(struct drm_crtc 
> > *crtc)
> > struct drm_encoder *drm_enc;
> >
> > drm_for_each_encoder_mask(drm_enc, crtc->dev, 
> > crtc->state->encoder_mask)
> > -   dpu_encoder_setup_misr(drm_enc);
> > +   dpu_encoder_setup_misr(drm_enc, !!crtc->state->ctm);
> >  }
> >
> >  static int dpu_crtc_set_crc_source(struct drm_crtc *crtc, const char 
> > *src_name)
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > index b0a7908418ed..12ee7acb5ea6 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> > @@ -241,7 +241,7 @@ int dpu_encoder_get_crc_values_cnt(const struct 
> > drm_encoder *drm_enc)
> > return num_intf;
> >  }
> >
> > -void dpu_encoder_setup_misr(const struct drm_encoder *drm_enc)
> > +void dpu_encoder_setup_misr(const struct drm_encoder *drm_enc, bool 
> > has_ctm)
> >  {
> > struct dpu_encoder_virt *dpu_enc;
> >
> > @@ -255,7 +255,7 @@ void dpu_encoder_setup_misr(const struct drm_encoder 
> > *drm_enc)
> > if (!phys->hw_intf || !phys->hw_intf->ops.setup_misr)
> > continue;
> >
> > -   phys->hw_intf->ops.setup_misr(phys->hw_intf, true, 1);
> > +   phys->hw_intf->ops.setup_misr(phys->hw_intf, true, 1, 
> > has_ctm);
> > }
> >  }
> >
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> > index 4c05fd5e9ed1..510783b2fb24 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> > @@ -169,8 +169,9 @@ int dpu_encoder_get_crc_values_cnt(const struct 
> > drm_encoder *drm_enc);
> >  /**
> >   * dpu_encoder_setup_misr - enable misr calculations
> >   * @drm_enc:Pointer to previously created drm encoder structure
> > + * @has_ctm:Is CTM enabled
> >   */
> > -void dpu_encoder_setup_misr(const struct drm_encoder *drm_encoder);
> > +void dpu_encoder_setup_misr(const struct drm_encoder *drm_encoder, bool 
> > has_ctm);
> >
> >  /**
> >   * dpu_encoder_get_crc - get the crc value from interface blocks
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> > index e8b8908d3e12..cb06f80cc671 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> > @@ -318,9 +318,9 @@ static u32 dpu_hw_intf_get_line_count(struct 
> > dpu_hw_intf *intf)
> > return DPU_REG_READ(c, INTF_LINE_COUNT);
> >  }
> >
> > -static void dpu_hw_intf_setup_misr(struct dpu_hw_intf *intf, bool enable, 
> > u32 frame_count)
> > +static void dpu_hw_intf_setup_misr(struct dpu_hw_intf *intf, bool enable, 
> > u32 frame_count, bool has_ctm)
> >  {
> > -   dpu_hw_setup_misr(>hw, INTF_MISR_CTRL, enable, frame_count);
> > +   dpu_hw_setup_misr(>hw, INTF_MISR_CTRL, enable, frame_count, 
> > has_ctm);
>
> I'm not sure about the dpu_encoder and dpu_hw_intf interfaces. But
> dpu_hw_setup_misr definitely needs the `u8 input_sel` parameter
> instead of `bool has_ctm`.

That seems a bit premature without knowing what the other values are.
(And I also question a bit the whole abstraction layer thing if it is
taking directly register bitfield enum's..)

BR,
-R

> Most likely, I'd use u8 for dpu_hw_intf operation too.
>
> Could you please adjust?
>
> >  }
> >
> >  static int dpu_hw_intf_collect_misr(struct dpu_hw_intf *intf, u32 
> > *misr_value)
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
> > index c539025c418b..95aafc4cf58e 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
> > @@ -95,7 +95,7 @@ struct dpu_hw_intf_ops {

Re: [PATCH v5 0/2] drm/rockchip: vop: Add NV15, NV20 and NV30 support

2023-10-23 Thread Jonas Karlman

Hi Chris,

On 2023-10-23 19:52, Christopher Obbard wrote:
> Hi Jonas,
> 
> On Mon, 2023-10-23 at 17:37 +, Jonas Karlman wrote:
>> This series add support for displaying 10-bit 4:2:0 and 4:2:2 formats
>> produced
>> by the Rockchip Video Decoder on RK322X, RK3288, RK3328, RK3368 and RK3399.
>> Also include 10-bit 4:4:4 support since VOP can support that also.
>>
>> First patch adds new fourcc 10-bit YUV formats with 4:2:2/4:4:4 sub-
>> sampling.
>> Second patch adds support for displaying the new fourcc formats.
>>
>> These patches have been in use by LibreELEC and other distros for the
>> past 3+ years, hoping they can be merged this time around.
>>
>> A rough libdrm/modetest patch [2] have been used to validate use of
>> NV15, NV20 and NV30 formats on RK3288, RK3328 and RK3399 boards.
>>
>>   modetest -s @:-@
>>
>> Tinker Board R2.0 (rk3288w):
>>   modetest -s 50:1920x1080-60@NV15
>>
>> Rock Pi 4 (rk3399):
>>   modetest -s 52@44:1920x1080-60@NV15
>>
>> Rock64 (rk3328):
>>   modetest -s 42:1920x1080-60@NV15
>>
>> Changes in v5:
>> - Use drm_format_info_min_pitch() for correct bpp
>> - Add missing NV21, NV61 and NV42 formats
>>
>> Changes in v4:
>> - Rework RK3328/RK3399 win0/1 data to not affect RK3368
>>
>> Changes in v3:
>> - No changes, rebased on next-20230616
>> - R-B tags was collected
>>
>> Changes in v2:
>> - Add NV30 format
>> - R-B tags was not collected due to NV30 changes
>>
>> This series is also available at [1] and libdrm/modetest patch at [2].
>>
>> [1] https://github.com/Kwiboo/linux-rockchip/commits/v6.6-rc7-vop-nv15
>> [2] https://github.com/Kwiboo/libdrm/commits/nv15
> 
> Could you open a draft merge request for libdrm upstream at
> https://gitlab.freedesktop.org/mesa/drm pointing to this series? If there are
> subsequent revisions of this series, it'd be great to link that merge request
> in the cover letter.

Have created a draft merge reguest for libdrm/modetest changes now.
https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/329

The pattern code could really need some improvements/refactoring, in
current form it should at least be enough to create a test pattern to
help test/validate this series :-)

Regards,
Jonas

> 
> 
> Cheers!
> 
> Chris
> 
>>
>> Jonas Karlman (2):
>>   drm/fourcc: Add NV20 and NV30 YUV formats
>>   drm/rockchip: vop: Add NV15, NV20 and NV30 support
>>
>>  drivers/gpu/drm/drm_fourcc.c    |  8 +++
>>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 36 ---
>>  drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  1 +
>>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 66 +
>>  include/uapi/drm/drm_fourcc.h   |  2 +
>>  5 files changed, 96 insertions(+), 17 deletions(-)
>>

Re: [PATCH drm-misc-next v2] drm/sched: implement dynamic job-flow control

2023-10-23 Thread Danilo Krummrich

On Wed, Oct 11, 2023 at 09:52:36PM -0400, Luben Tuikov wrote:
> Hi,
> 
> Thanks for fixing the title and submitting a v2 of this patch. Comments 
> inlined below.
> 
> On 2023-10-09 18:35, Danilo Krummrich wrote:
> > Currently, job flow control is implemented simply by limiting the number
> > of jobs in flight. Therefore, a scheduler is initialized with a
> > submission limit that corresponds to the number of jobs which can be
> > sent to the hardware.
> > 
> > This implies that for each job, drivers need to account for the maximum
> > job size possible in order to not overflow the ring buffer.
> > 
> > However, there are drivers, such as Nouveau, where the job size has a
> > rather large range. For such drivers it can easily happen that job
> > submissions not even filling the ring by 1% can block subsequent
> > submissions, which, in the worst case, can lead to the ring run dry.
> > 
> > In order to overcome this issue, allow for tracking the actual job size
> > instead of the number of jobs. Therefore, add a field to track a job's
> > submission credits, which represents the number of credits a job
> > contributes to the scheduler's submission limit.
> > 
> > Signed-off-by: Danilo Krummrich 
> > ---
> > Changes in V2:
> > ==
> >   - fixed up influence on scheduling fairness due to consideration of a 
> > job's
> > size
> > - If we reach a ready entity in drm_sched_select_entity() but can't 
> > actually
> >   queue a job from it due to size limitations, just give up and go to 
> > sleep
> >   until woken up due to a pending job finishing, rather than continue 
> > to try
> >   other entities.
> >   - added a callback to dynamically update a job's credits (Boris)
> >   - renamed 'units' to 'credits'
> >   - fixed commit message and comments as requested by Luben
> > ---
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c   |   2 +-
> >  drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c  |   2 +-
> >  drivers/gpu/drm/lima/lima_sched.c |   2 +-
> >  drivers/gpu/drm/msm/msm_gem_submit.c  |   2 +-
> >  drivers/gpu/drm/nouveau/nouveau_sched.c   |   2 +-
> >  drivers/gpu/drm/panfrost/panfrost_drv.c   |   2 +-
> >  .../gpu/drm/scheduler/gpu_scheduler_trace.h   |   2 +-
> >  drivers/gpu/drm/scheduler/sched_entity.c  |   5 +-
> >  drivers/gpu/drm/scheduler/sched_main.c| 101 +-
> >  drivers/gpu/drm/v3d/v3d_gem.c |   2 +-
> >  include/drm/gpu_scheduler.h   |  33 --
> >  11 files changed, 115 insertions(+), 40 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> > index 78476bc75b4e..d54daaf64bf1 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
> > @@ -115,7 +115,7 @@ int amdgpu_job_alloc(struct amdgpu_device *adev, struct 
> > amdgpu_vm *vm,
> > if (!entity)
> > return 0;
> >  
> > -   return drm_sched_job_init(&(*job)->base, entity, owner);
> > +   return drm_sched_job_init(&(*job)->base, entity, 1, owner);
> >  }
> >  
> >  int amdgpu_job_alloc_with_ib(struct amdgpu_device *adev,
> > diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c 
> > b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> > index 45403ea38906..74a446711207 100644
> > --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> > +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
> > @@ -538,7 +538,7 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, 
> > void *data,
> >  
> > ret = drm_sched_job_init(>sched_job,
> >  >sched_entity[args->pipe],
> > -submit->ctx);
> > +1, submit->ctx);
> > if (ret)
> > goto err_submit_put;
> >  
> > diff --git a/drivers/gpu/drm/lima/lima_sched.c 
> > b/drivers/gpu/drm/lima/lima_sched.c
> > index 50c2075228aa..5dc6678e1eb9 100644
> > --- a/drivers/gpu/drm/lima/lima_sched.c
> > +++ b/drivers/gpu/drm/lima/lima_sched.c
> > @@ -123,7 +123,7 @@ int lima_sched_task_init(struct lima_sched_task *task,
> > for (i = 0; i < num_bos; i++)
> > drm_gem_object_get([i]->base.base);
> >  
> > -   err = drm_sched_job_init(>base, >base, vm);
> > +   err = drm_sched_job_init(>base, >base, 1, vm);
> > if (err) {
> > kfree(task->bos);
> > return err;
> > diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c 
> > b/drivers/gpu/drm/msm/msm_gem_submit.c
> > index 3f1aa4de3b87..6d230c38e4f5 100644
> > --- a/drivers/gpu/drm/msm/msm_gem_submit.c
> > +++ b/drivers/gpu/drm/msm/msm_gem_submit.c
> > @@ -48,7 +48,7 @@ static struct msm_gem_submit *submit_create(struct 
> > drm_device *dev,
> > return ERR_PTR(ret);
> > }
> >  
> > -   ret = drm_sched_job_init(>base, queue->entity, queue);
> > +   ret = drm_sched_job_init(>base, queue->entity, 1, queue);
> > if (ret) {
> > kfree(submit->hw_fence);
> >

Re: [RFC PATCH v2 04/17] drm/vkms: Add kunit tests for VKMS LUT handling

2023-10-23 Thread Arthur Grillo




On 19/10/23 18:21, Harry Wentland wrote:
> Debugging LUT math is much easier when we can unit test
> it. Add kunit functionality to VKMS and add tests for
>  - get_lut_index
>  - lerp_u16
> 
> Signed-off-by: Harry Wentland 
> Cc: Ville Syrjala 
> Cc: Pekka Paalanen 
> Cc: Simon Ser 
> Cc: Harry Wentland 
> Cc: Melissa Wen 
> Cc: Jonas Ådahl 
> Cc: Sebastian Wick 
> Cc: Shashank Sharma 
> Cc: Alexander Goins 
> Cc: Joshua Ashton 
> Cc: Michel Dänzer 
> Cc: Aleix Pol 
> Cc: Xaver Hugl 
> Cc: Victoria Brekenfeld 
> Cc: Sima 
> Cc: Uma Shankar 
> Cc: Naseer Ahmed 
> Cc: Christopher Braga 
> Cc: Abhinav Kumar 
> Cc: Arthur Grillo 
> Cc: Hector Martin 
> Cc: Liviu Dudau 
> Cc: Sasha McIntosh 
> ---
>  drivers/gpu/drm/vkms/Kconfig  |  5 ++
>  drivers/gpu/drm/vkms/Makefile |  2 +
>  drivers/gpu/drm/vkms/tests/.kunitconfig   |  4 ++
>  drivers/gpu/drm/vkms/tests/Makefile   |  4 ++
>  drivers/gpu/drm/vkms/tests/vkms_color_tests.c | 64 +++
>  drivers/gpu/drm/vkms/vkms_composer.c  |  4 +-
>  drivers/gpu/drm/vkms/vkms_composer.h  | 11 
>  7 files changed, 92 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/gpu/drm/vkms/tests/.kunitconfig
>  create mode 100644 drivers/gpu/drm/vkms/tests/Makefile
>  create mode 100644 drivers/gpu/drm/vkms/tests/vkms_color_tests.c
>  create mode 100644 drivers/gpu/drm/vkms/vkms_composer.h
> 
> diff --git a/drivers/gpu/drm/vkms/Kconfig b/drivers/gpu/drm/vkms/Kconfig
> index 1816562381a2..372cc5fa92f1 100644
> --- a/drivers/gpu/drm/vkms/Kconfig
> +++ b/drivers/gpu/drm/vkms/Kconfig
> @@ -13,3 +13,8 @@ config DRM_VKMS
> a VKMS.
>  
> If M is selected the module will be called vkms.
> +
> +config DRM_VKMS_KUNIT_TESTS
> + tristate "Tests for VKMS" if !KUNIT_ALL_TESTS
> + depends on DRM_VKMS && KUNIT
> + default KUNIT_ALL_TESTS
> diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
> index 1b28a6a32948..d3440f228f46 100644
> --- a/drivers/gpu/drm/vkms/Makefile
> +++ b/drivers/gpu/drm/vkms/Makefile
> @@ -9,3 +9,5 @@ vkms-y := \
>   vkms_writeback.o
>  
>  obj-$(CONFIG_DRM_VKMS) += vkms.o
> +
> +obj-y += tests/
> \ No newline at end of file
> diff --git a/drivers/gpu/drm/vkms/tests/.kunitconfig 
> b/drivers/gpu/drm/vkms/tests/.kunitconfig
> new file mode 100644
> index ..70e378228cbd
> --- /dev/null
> +++ b/drivers/gpu/drm/vkms/tests/.kunitconfig
> @@ -0,0 +1,4 @@
> +CONFIG_KUNIT=y
> +CONFIG_DRM=y
> +CONFIG_DRM_VKMS=y
> +CONFIG_DRM_VKMS_KUNIT_TESTS=y
> diff --git a/drivers/gpu/drm/vkms/tests/Makefile 
> b/drivers/gpu/drm/vkms/tests/Makefile
> new file mode 100644
> index ..761465332ff2
> --- /dev/null
> +++ b/drivers/gpu/drm/vkms/tests/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +
> +obj-$(CONFIG_DRM_VKMS_KUNIT_TESTS) += \
> + vkms_color_tests.o
> \ No newline at end of file
> diff --git a/drivers/gpu/drm/vkms/tests/vkms_color_tests.c 
> b/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
> new file mode 100644
> index ..843b2e1d607e
> --- /dev/null
> +++ b/drivers/gpu/drm/vkms/tests/vkms_color_tests.c
> @@ -0,0 +1,64 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +
> +#include 
> +
> +#include 
> +
> +#include "../vkms_composer.h"
> +
> +#define TEST_LUT_SIZE 16
> +
> +static struct drm_color_lut test_linear_array[TEST_LUT_SIZE] = {
> + { 0x0, 0x0, 0x0, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> + { 0x, 0x, 0x, 0 },
> +};
> +
> +const struct vkms_color_lut test_linear_lut = {
> + .base = test_linear_array,
> + .lut_length = TEST_LUT_SIZE,
> + .channel_value2index_ratio = 0xf000fll
> +};
> +
> +
> +static void vkms_color_test_get_lut_index(struct kunit *test)
> +{
> + int i;
> +
> + KUNIT_EXPECT_EQ(test, drm_fixp2int(get_lut_index(_linear_lut, 
> test_linear_array[0].red)), 0);
> +
> + for (i = 0; i < TEST_LUT_SIZE; i++)
> + KUNIT_EXPECT_EQ(test, 
> drm_fixp2int_ceil(get_lut_index(_linear_lut, test_linear_array[i].red)), 
> i);
> +}
> +
> +static void vkms_color_test_lerp(struct kunit *test)
> +{
> + KUNIT_EXPECT_EQ(test, lerp_u16(0x0, 0x10, 0x8000), 0x8);
> +}
> +
> +static struct kunit_case vkms_color_test_cases[] = {
> + KUNIT_CASE(vkms_color_test_get_lut_index),
> + KUNIT_CASE(vkms_color_test_lerp),
> + {}
> +};
> +
> +static struct kunit_suite vkms_color_test_suite = {
> + .name = "vkms-color",
> +

Re: [PATCH] drm/msm/dpu: Fix encoder CRC to account for CTM enablement

2023-10-23 Thread Dmitry Baryshkov

On Tue, 24 Oct 2023 at 01:12, Rob Clark  wrote:
>
> From: Rob Clark 
>
> Seems like we need to pick INPUT_SEL=1 when CTM is enabled.  But not
> otherwise.
>
> Suggested-by: Dmitry Baryshkov 
> Signed-off-by: Rob Clark 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 2 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 ++--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 3 ++-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 4 ++--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 2 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c   | 2 +-
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c | 5 -
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 3 ++-
>  8 files changed, 15 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index 2b83a13b3aa9..d93a92ffd5df 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -134,7 +134,7 @@ static void dpu_crtc_setup_encoder_misr(struct drm_crtc 
> *crtc)
> struct drm_encoder *drm_enc;
>
> drm_for_each_encoder_mask(drm_enc, crtc->dev, 
> crtc->state->encoder_mask)
> -   dpu_encoder_setup_misr(drm_enc);
> +   dpu_encoder_setup_misr(drm_enc, !!crtc->state->ctm);
>  }
>
>  static int dpu_crtc_set_crc_source(struct drm_crtc *crtc, const char 
> *src_name)
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index b0a7908418ed..12ee7acb5ea6 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -241,7 +241,7 @@ int dpu_encoder_get_crc_values_cnt(const struct 
> drm_encoder *drm_enc)
> return num_intf;
>  }
>
> -void dpu_encoder_setup_misr(const struct drm_encoder *drm_enc)
> +void dpu_encoder_setup_misr(const struct drm_encoder *drm_enc, bool has_ctm)
>  {
> struct dpu_encoder_virt *dpu_enc;
>
> @@ -255,7 +255,7 @@ void dpu_encoder_setup_misr(const struct drm_encoder 
> *drm_enc)
> if (!phys->hw_intf || !phys->hw_intf->ops.setup_misr)
> continue;
>
> -   phys->hw_intf->ops.setup_misr(phys->hw_intf, true, 1);
> +   phys->hw_intf->ops.setup_misr(phys->hw_intf, true, 1, 
> has_ctm);
> }
>  }
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> index 4c05fd5e9ed1..510783b2fb24 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
> @@ -169,8 +169,9 @@ int dpu_encoder_get_crc_values_cnt(const struct 
> drm_encoder *drm_enc);
>  /**
>   * dpu_encoder_setup_misr - enable misr calculations
>   * @drm_enc:Pointer to previously created drm encoder structure
> + * @has_ctm:Is CTM enabled
>   */
> -void dpu_encoder_setup_misr(const struct drm_encoder *drm_encoder);
> +void dpu_encoder_setup_misr(const struct drm_encoder *drm_encoder, bool 
> has_ctm);
>
>  /**
>   * dpu_encoder_get_crc - get the crc value from interface blocks
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> index e8b8908d3e12..cb06f80cc671 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
> @@ -318,9 +318,9 @@ static u32 dpu_hw_intf_get_line_count(struct dpu_hw_intf 
> *intf)
> return DPU_REG_READ(c, INTF_LINE_COUNT);
>  }
>
> -static void dpu_hw_intf_setup_misr(struct dpu_hw_intf *intf, bool enable, 
> u32 frame_count)
> +static void dpu_hw_intf_setup_misr(struct dpu_hw_intf *intf, bool enable, 
> u32 frame_count, bool has_ctm)
>  {
> -   dpu_hw_setup_misr(>hw, INTF_MISR_CTRL, enable, frame_count);
> +   dpu_hw_setup_misr(>hw, INTF_MISR_CTRL, enable, frame_count, 
> has_ctm);

I'm not sure about the dpu_encoder and dpu_hw_intf interfaces. But
dpu_hw_setup_misr definitely needs the `u8 input_sel` parameter
instead of `bool has_ctm`.
Most likely, I'd use u8 for dpu_hw_intf operation too.

Could you please adjust?

>  }
>
>  static int dpu_hw_intf_collect_misr(struct dpu_hw_intf *intf, u32 
> *misr_value)
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
> index c539025c418b..95aafc4cf58e 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
> @@ -95,7 +95,7 @@ struct dpu_hw_intf_ops {
>
> void (*bind_pingpong_blk)(struct dpu_hw_intf *intf,
> const enum dpu_pingpong pp);
> -   void (*setup_misr)(struct dpu_hw_intf *intf, bool enable, u32 
> frame_count);
> +   void (*setup_misr)(struct dpu_hw_intf *intf, bool enable, u32 
> frame_count, bool has_ctm);
> int (*collect_misr)(struct dpu_hw_intf *intf, u32 *misr_value);
>
> // Tearcheck on INTF since DPU 5.0.0
> diff --git

[PATCH] drm/msm/dpu: Fix encoder CRC to account for CTM enablement

2023-10-23 Thread Rob Clark

From: Rob Clark 

Seems like we need to pick INPUT_SEL=1 when CTM is enabled.  But not
otherwise.

Suggested-by: Dmitry Baryshkov 
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 ++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 3 ++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 4 ++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c   | 2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c | 5 -
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 3 ++-
 8 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index 2b83a13b3aa9..d93a92ffd5df 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -134,7 +134,7 @@ static void dpu_crtc_setup_encoder_misr(struct drm_crtc 
*crtc)
struct drm_encoder *drm_enc;
 
drm_for_each_encoder_mask(drm_enc, crtc->dev, crtc->state->encoder_mask)
-   dpu_encoder_setup_misr(drm_enc);
+   dpu_encoder_setup_misr(drm_enc, !!crtc->state->ctm);
 }
 
 static int dpu_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index b0a7908418ed..12ee7acb5ea6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -241,7 +241,7 @@ int dpu_encoder_get_crc_values_cnt(const struct drm_encoder 
*drm_enc)
return num_intf;
 }
 
-void dpu_encoder_setup_misr(const struct drm_encoder *drm_enc)
+void dpu_encoder_setup_misr(const struct drm_encoder *drm_enc, bool has_ctm)
 {
struct dpu_encoder_virt *dpu_enc;
 
@@ -255,7 +255,7 @@ void dpu_encoder_setup_misr(const struct drm_encoder 
*drm_enc)
if (!phys->hw_intf || !phys->hw_intf->ops.setup_misr)
continue;
 
-   phys->hw_intf->ops.setup_misr(phys->hw_intf, true, 1);
+   phys->hw_intf->ops.setup_misr(phys->hw_intf, true, 1, has_ctm);
}
 }
 
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index 4c05fd5e9ed1..510783b2fb24 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -169,8 +169,9 @@ int dpu_encoder_get_crc_values_cnt(const struct drm_encoder 
*drm_enc);
 /**
  * dpu_encoder_setup_misr - enable misr calculations
  * @drm_enc:Pointer to previously created drm encoder structure
+ * @has_ctm:Is CTM enabled
  */
-void dpu_encoder_setup_misr(const struct drm_encoder *drm_encoder);
+void dpu_encoder_setup_misr(const struct drm_encoder *drm_encoder, bool 
has_ctm);
 
 /**
  * dpu_encoder_get_crc - get the crc value from interface blocks
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index e8b8908d3e12..cb06f80cc671 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -318,9 +318,9 @@ static u32 dpu_hw_intf_get_line_count(struct dpu_hw_intf 
*intf)
return DPU_REG_READ(c, INTF_LINE_COUNT);
 }
 
-static void dpu_hw_intf_setup_misr(struct dpu_hw_intf *intf, bool enable, u32 
frame_count)
+static void dpu_hw_intf_setup_misr(struct dpu_hw_intf *intf, bool enable, u32 
frame_count, bool has_ctm)
 {
-   dpu_hw_setup_misr(>hw, INTF_MISR_CTRL, enable, frame_count);
+   dpu_hw_setup_misr(>hw, INTF_MISR_CTRL, enable, frame_count, 
has_ctm);
 }
 
 static int dpu_hw_intf_collect_misr(struct dpu_hw_intf *intf, u32 *misr_value)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
index c539025c418b..95aafc4cf58e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
@@ -95,7 +95,7 @@ struct dpu_hw_intf_ops {
 
void (*bind_pingpong_blk)(struct dpu_hw_intf *intf,
const enum dpu_pingpong pp);
-   void (*setup_misr)(struct dpu_hw_intf *intf, bool enable, u32 
frame_count);
+   void (*setup_misr)(struct dpu_hw_intf *intf, bool enable, u32 
frame_count, bool has_ctm);
int (*collect_misr)(struct dpu_hw_intf *intf, u32 *misr_value);
 
// Tearcheck on INTF since DPU 5.0.0
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
index d1c3bd8379ea..2efe29396c6a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c
@@ -83,7 +83,7 @@ static void dpu_hw_lm_setup_border_color(struct dpu_hw_mixer 
*ctx,
 
 static void dpu_hw_lm_setup_misr(struct dpu_hw_mixer *ctx, bool enable, u32 
frame_count)
 {
-   dpu_hw_setup_misr(>hw, LM_MISR_CTRL, enable, frame_count);
+   dpu_hw_setup_misr(>hw, LM_MISR_CTRL, enable, frame_count, false);

Re: [PATCH v6 5/7] drm/sched: Split free_job into own work item

2023-10-23 Thread Matthew Brost

On Mon, Oct 23, 2023 at 04:22:16PM +0200, Boris Brezillon wrote:
> On Mon, 23 Oct 2023 13:54:13 +
> Matthew Brost  wrote:
> 
> > On Mon, Oct 23, 2023 at 02:39:37PM +0200, Boris Brezillon wrote:
> > > On Mon, 23 Oct 2023 14:16:06 +0200
> > > Boris Brezillon  wrote:
> > >   
> > > > Hi,
> > > > 
> > > > On Tue, 17 Oct 2023 08:09:56 -0700
> > > > Matthew Brost  wrote:
> > > >   
> > > > > +static void drm_sched_run_job_work(struct work_struct *w)
> > > > > +{
> > > > > + struct drm_gpu_scheduler *sched =
> > > > > + container_of(w, struct drm_gpu_scheduler, work_run_job);
> > > > > + struct drm_sched_entity *entity;
> > > > > + struct dma_fence *fence;
> > > > > + struct drm_sched_fence *s_fence;
> > > > > + struct drm_sched_job *sched_job;
> > > > > + int r;
> > > > >  
> > > > > - atomic_inc(>hw_rq_count);
> > > > > - drm_sched_job_begin(sched_job);
> > > > > + if (READ_ONCE(sched->pause_submit))
> > > > > + return;
> > > > > +
> > > > > + entity = drm_sched_select_entity(sched, true);
> > > > > + if (!entity)
> > > > > + return;
> > > > >  
> > > > > - trace_drm_run_job(sched_job, entity);
> > > > > - fence = sched->ops->run_job(sched_job);
> > > > > + sched_job = drm_sched_entity_pop_job(entity);
> > > > > + if (!sched_job) {
> > > > >   complete_all(>entity_idle);
> > > > > - drm_sched_fence_scheduled(s_fence, fence);
> > > > > + return; /* No more work */
> > > > > + }
> > > > >  
> > > > > - if (!IS_ERR_OR_NULL(fence)) {
> > > > > - /* Drop for original kref_init of the fence */
> > > > > - dma_fence_put(fence);
> > > > > + s_fence = sched_job->s_fence;
> > > > >  
> > > > > - r = dma_fence_add_callback(fence, 
> > > > > _job->cb,
> > > > > -
> > > > > drm_sched_job_done_cb);
> > > > > - if (r == -ENOENT)
> > > > > - drm_sched_job_done(sched_job, 
> > > > > fence->error);
> > > > > - else if (r)
> > > > > - DRM_DEV_ERROR(sched->dev, "fence add 
> > > > > callback failed (%d)\n",
> > > > > -   r);
> > > > > - } else {
> > > > > - drm_sched_job_done(sched_job, IS_ERR(fence) ?
> > > > > -PTR_ERR(fence) : 0);
> > > > > - }
> > > > > + atomic_inc(>hw_rq_count);
> > > > > + drm_sched_job_begin(sched_job);
> > > > >  
> > > > > - wake_up(>job_scheduled);
> > > > > + trace_drm_run_job(sched_job, entity);
> > > > > + fence = sched->ops->run_job(sched_job);
> > > > > + complete_all(>entity_idle);
> > > > > + drm_sched_fence_scheduled(s_fence, fence);
> > > > > +
> > > > > + if (!IS_ERR_OR_NULL(fence)) {
> > > > > + /* Drop for original kref_init of the fence */
> > > > > + dma_fence_put(fence);
> > > > > +
> > > > > + r = dma_fence_add_callback(fence, _job->cb,
> > > > > +drm_sched_job_done_cb);
> > > > > + if (r == -ENOENT)
> > > > > + drm_sched_job_done(sched_job, fence->error);
> > > > > + else if (r)
> > > > > + DRM_DEV_ERROR(sched->dev, "fence add callback 
> > > > > failed (%d)\n", r);
> > > > > + } else {
> > > > > + drm_sched_job_done(sched_job, IS_ERR(fence) ?
> > > > > +PTR_ERR(fence) : 0);
> > > > >   }
> > > > 
> > > > Just ran into a race condition when using a non-ordered workqueue
> > > > for drm_sched:
> > > > 
> > > > thread Athread B
> > > > 
> > > > drm_sched_run_job_work()
> > > >   drm_sched_job_begin()
> > > > // inserts jobA in pending_list
> > > > 
> > > > 
> > > > drm_sched_free_job_work()
> > > >   
> > > > drm_sched_get_cleanup_job()
> > > > // 
> > > > check first job in pending list
> > > > // 
> > > > if s_fence->parent == NULL, consider
> > > > // 
> > > > for cleanup  
> > > >   
> > > > ->free_job(jobA)
> > > > 
> > > > drm_sched_job_cleanup()
> > > >   
> > > > // set sched_job->s_fence = NULL
> > > >   
> > > > ->run_job()
> >

Re: [PATCH 12/18] dt-bindings: pwm: add binding for mt8365 SoC

2023-10-23 Thread Uwe Kleine-König

On Mon, Oct 23, 2023 at 04:40:12PM +0200, Alexandre Mergnat wrote:
> Display PWM for MT8365 is compatible with MT8183. Then, add MT8365 binding
> along with MT8183 SoC.
> 
> Signed-off-by: Alexandre Mergnat 

Acked-by: Uwe Kleine-König 

What is the merge plan here? Should the whole series go in via drm?

Thanks
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Re: [Nouveau] [PATCH] drm/nouveau: Fixing indentation and adding License Identifier tag

2023-10-23 Thread Danilo Krummrich


On 10/8/23 19:27, Bragatheswaran Manickavel wrote:

On running checkpatch.pl to nouveau_drm.h identified
few warnings. Fixing them in this patch

WARNING: Missing or malformed SPDX-License-Identifier tag in line 1
+/*

WARNING: space prohibited between function name and open parenthesis '('
+#define DRM_IOCTL_NOUVEAU_CHANNEL_FREE   DRM_IOW (DRM_COMMAND_BASE +
DRM_NOUVEAU_CHANNEL_FREE, struct drm_nouveau_channel_free)


Even though this fixes a checkpatch warning, I don't see how this change
improves readability, rather the opposite. Personally, I prefer keeping this
as it is.

- Danilo



Signed-off-by: Bragatheswaran Manickavel 
---
  include/uapi/drm/nouveau_drm.h | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/uapi/drm/nouveau_drm.h b/include/uapi/drm/nouveau_drm.h
index 8d7402c13e56..900ca4f1ebe5 100644
--- a/include/uapi/drm/nouveau_drm.h
+++ b/include/uapi/drm/nouveau_drm.h
@@ -1,3 +1,4 @@
+/* SPDX-License-Identifier: MIT */
  /*
   * Copyright 2005 Stephane Marchesin.
   * All Rights Reserved.
@@ -448,15 +449,15 @@ struct drm_nouveau_svm_bind {
  
  #define DRM_IOCTL_NOUVEAU_GETPARAM   DRM_IOWR(DRM_COMMAND_BASE + DRM_NOUVEAU_GETPARAM, struct drm_nouveau_getparam)

  #define DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_NOUVEAU_CHANNEL_ALLOC, struct drm_nouveau_channel_alloc)
-#define DRM_IOCTL_NOUVEAU_CHANNEL_FREE   DRM_IOW (DRM_COMMAND_BASE + 
DRM_NOUVEAU_CHANNEL_FREE, struct drm_nouveau_channel_free)
+#define DRM_IOCTL_NOUVEAU_CHANNEL_FREE   DRM_IOW(DRM_COMMAND_BASE + 
DRM_NOUVEAU_CHANNEL_FREE, struct drm_nouveau_channel_free)
  
  #define DRM_IOCTL_NOUVEAU_SVM_INIT   DRM_IOWR(DRM_COMMAND_BASE + DRM_NOUVEAU_SVM_INIT, struct drm_nouveau_svm_init)

  #define DRM_IOCTL_NOUVEAU_SVM_BIND   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_NOUVEAU_SVM_BIND, struct drm_nouveau_svm_bind)
  
  #define DRM_IOCTL_NOUVEAU_GEM_NEWDRM_IOWR(DRM_COMMAND_BASE + DRM_NOUVEAU_GEM_NEW, struct drm_nouveau_gem_new)

  #define DRM_IOCTL_NOUVEAU_GEM_PUSHBUFDRM_IOWR(DRM_COMMAND_BASE + 
DRM_NOUVEAU_GEM_PUSHBUF, struct drm_nouveau_gem_pushbuf)
-#define DRM_IOCTL_NOUVEAU_GEM_CPU_PREP   DRM_IOW (DRM_COMMAND_BASE + 
DRM_NOUVEAU_GEM_CPU_PREP, struct drm_nouveau_gem_cpu_prep)
-#define DRM_IOCTL_NOUVEAU_GEM_CPU_FINI   DRM_IOW (DRM_COMMAND_BASE + 
DRM_NOUVEAU_GEM_CPU_FINI, struct drm_nouveau_gem_cpu_fini)
+#define DRM_IOCTL_NOUVEAU_GEM_CPU_PREP   DRM_IOW(DRM_COMMAND_BASE + 
DRM_NOUVEAU_GEM_CPU_PREP, struct drm_nouveau_gem_cpu_prep)
+#define DRM_IOCTL_NOUVEAU_GEM_CPU_FINI   DRM_IOW(DRM_COMMAND_BASE + 
DRM_NOUVEAU_GEM_CPU_FINI, struct drm_nouveau_gem_cpu_fini)
  #define DRM_IOCTL_NOUVEAU_GEM_INFO   DRM_IOWR(DRM_COMMAND_BASE + 
DRM_NOUVEAU_GEM_INFO, struct drm_nouveau_gem_info)
  
  #define DRM_IOCTL_NOUVEAU_VM_INITDRM_IOWR(DRM_COMMAND_BASE + DRM_NOUVEAU_VM_INIT, struct drm_nouveau_vm_init)

Re: [PATCH] drm/doc: describe PATH format for DP MST

2023-10-23 Thread Dmitry Baryshkov

On Mon, 23 Oct 2023 at 23:37, Simon Ser  wrote:
>
> This is already uAPI, xserver parses it. It's useful to document
> since user-space might want to lookup the parent connector.
>
> Additionally, people (me included) have misunderstood the PATH
> property for being stable across reboots, but since a KMS object
> ID is baked in there that's not the case. So PATH shouldn't be
> used as-is in config files and such.
>
> Signed-off-by: Simon Ser 
> Cc: Pekka Paalanen 
> Cc: Dmitry Baryshkov 
> Cc: Daniel Vetter 

Reviewed-by: Dmitry Baryshkov 

> ---
>  drivers/gpu/drm/drm_connector.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index c3725086f413..392bec1355a3 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1198,6 +1198,11 @@ static const u32 dp_colorspaces =
>   * drm_connector_set_path_property(), in the case of DP MST with the
>   * path property the MST manager created. Userspace cannot change this
>   * property.
> + *
> + * In the case of DP MST, the property has the format
> + * ``mst:-`` where  is the KMS object ID of 
> the
> + * parent connector and  is a hyphen-separated list of DP MST
> + * port numbers. Note, KMS object IDs are not stable across reboots.

Nit:  maybe `... is not guaranteed to be stable...'

>   * TILE:
>   * Connector tile group property to indicate how a set of DRM connector
>   * compose together into one logical screen. This is used by both 
> high-res
> --
> 2.42.0
>
>


-- 
With best wishes
Dmitry

Re: [PATCH v6 9/9] drm: Introduce documentation for hotspot properties

2023-10-23 Thread Javier Martinez Canillas

Albert Esteve  writes:

> From: Michael Banack 
>
> To clarify the intent and reasoning behind the hotspot properties
> introduce userspace documentation that goes over cursor handling
> in para-virtualized environments.
>
> The documentation is generic enough to not special case for any
> specific hypervisor and should apply equally to all.
>
> Signed-off-by: Zack Rusin 

The author is Michael Banack but it's missing a SoB from them.
I don't think there's a need to resend for this, can be added
when applying. But either Michael or Zack should confirm that
is the correct thing to do for this patch.

The doc itself looks great to me and it clarifies a lot about
cursor hotspots.

Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: [Nouveau] [PATCH] drm/nouveau/dispnv04: fix a possible null pointer dereference

2023-10-23 Thread Danilo Krummrich


On 10/13/23 03:18, Ma Ke wrote:

In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate()
is assigned to mode, which will lead to a NULL pointer dereference on
failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().
Add a check to avoid null pointer dereference.

Signed-off-by: Ma Ke 


For this one and the previous patch, please add the corresponding
'Fixes:' [1] and stable [2] tags and split the commits accordingly.

[1] 
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes
[2] https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html


---
  drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c 
b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
index 670c9739e5e1..9c3dc9a5bb46 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
@@ -258,6 +258,8 @@ static int nv17_tv_get_hd_modes(struct drm_encoder *encoder,
if (modes[i].hdisplay == output_mode->hdisplay &&
modes[i].vdisplay == output_mode->vdisplay) {
mode = drm_mode_duplicate(encoder->dev, output_mode);
+   if (!mode)
+   continue;
mode->type |= DRM_MODE_TYPE_PREFERRED;
  
  		} else {

@@ -265,6 +267,8 @@ static int nv17_tv_get_hd_modes(struct drm_encoder *encoder,
modes[i].vdisplay, 60, false,
(output_mode->flags &
 DRM_MODE_FLAG_INTERLACE), false);
+   if (!mode)
+   continue;
}
  
  		/* CVT modes are sometimes unsuitable... */

[PATCH] drm/rockchip: vop: Fix color for RGB888/BGR888 format on VOP full

2023-10-23 Thread Jonas Karlman

Use of DRM_FORMAT_RGB888 and DRM_FORMAT_BGR888 on e.g. RK3288, RK3328
and RK3399 result in wrong colors being displayed.

The issue can be observed using modetest:

  modetest -s @:1920x1080-60@RG24
  modetest -s @:1920x1080-60@BG24

Vendor 4.4 kernel apply an inverted rb swap for these formats on VOP
full (major = 3).

Fix colors by applying rb swap similar to vendor 4.4 kernel.

Signed-off-by: Jonas Karlman 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index b3d0b6ae9294..a1ce09a22f83 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -247,14 +247,17 @@ static inline void vop_cfg_done(struct vop *vop)
VOP_REG_SET(vop, common, cfg_done, 1);
 }
 
-static bool has_rb_swapped(uint32_t format)
+static bool has_rb_swapped(uint32_t version, uint32_t format)
 {
switch (format) {
case DRM_FORMAT_XBGR:
case DRM_FORMAT_ABGR:
-   case DRM_FORMAT_BGR888:
case DRM_FORMAT_BGR565:
return true;
+   case DRM_FORMAT_RGB888:
+   return VOP_MAJOR(version) == 3;
+   case DRM_FORMAT_BGR888:
+   return VOP_MAJOR(version) != 3;
default:
return false;
}
@@ -1035,7 +1038,7 @@ static void vop_plane_atomic_update(struct drm_plane 
*plane,
VOP_WIN_SET(vop, win, dsp_info, dsp_info);
VOP_WIN_SET(vop, win, dsp_st, dsp_st);
 
-   rb_swap = has_rb_swapped(fb->format->format);
+   rb_swap = has_rb_swapped(vop->data->version, fb->format->format);
VOP_WIN_SET(vop, win, rb_swap, rb_swap);
 
/*
-- 
2.42.0

[PATCH] drm/doc: describe PATH format for DP MST

2023-10-23 Thread Simon Ser

This is already uAPI, xserver parses it. It's useful to document
since user-space might want to lookup the parent connector.

Additionally, people (me included) have misunderstood the PATH
property for being stable across reboots, but since a KMS object
ID is baked in there that's not the case. So PATH shouldn't be
used as-is in config files and such.

Signed-off-by: Simon Ser 
Cc: Pekka Paalanen 
Cc: Dmitry Baryshkov 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_connector.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index c3725086f413..392bec1355a3 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1198,6 +1198,11 @@ static const u32 dp_colorspaces =
  * drm_connector_set_path_property(), in the case of DP MST with the
  * path property the MST manager created. Userspace cannot change this
  * property.
+ *
+ * In the case of DP MST, the property has the format
+ * ``mst:-`` where  is the KMS object ID of the
+ * parent connector and  is a hyphen-separated list of DP MST
+ * port numbers. Note, KMS object IDs are not stable across reboots.
  * TILE:
  * Connector tile group property to indicate how a set of DRM connector
  * compose together into one logical screen. This is used by both high-res
-- 
2.42.0

Re: [PATCH] drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL

2023-10-23 Thread Alex Deucher

Applied.  Thanks!

Alex

On Mon, Oct 23, 2023 at 9:06 AM  wrote:
>
> In certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file 
> could result in an abnormal null pointer access when the smc_rreg pointer is 
> NULL. Below are the steps to reproduce this issue and the corresponding 
> exception log:
>
> 1. Navigate to the directory: /sys/kernel/debug/dri/0
> 2. Execute command: cat amdgpu_regs_smc
> 3. Exception Log::
> [4005007.702554] BUG: kernel NULL pointer dereference, address: 
> 
> [4005007.702562] #PF: supervisor instruction fetch in kernel mode
> [4005007.702567] #PF: error_code(0x0010) - not-present page
> [4005007.702570] PGD 0 P4D 0
> [4005007.702576] Oops: 0010 [#1] SMP NOPTI
> [4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G   OE 
> 5.15.0-43-generic #46-Ubunt   u
> [4005007.702590] RIP: 0010:0x0
> [4005007.702598] Code: Unable to access opcode bytes at RIP 
> 0xffd6.
> [4005007.702600] RSP: 0018:a82b46d27da0 EFLAGS: 00010206
> [4005007.702605] RAX:  RBX:  RCX: 
> a82b46d27e68
> [4005007.702609] RDX: 0001 RSI:  RDI: 
> 9940656e
> [4005007.702612] RBP: a82b46d27dd8 R08:  R09: 
> 994060c07980
> [4005007.702615] R10: 0002 R11:  R12: 
> 7f5e06753000
> [4005007.702618] R13: 9940656e R14: a82b46d27e68 R15: 
> 7f5e06753000
> [4005007.702622] FS:  7f5e0755b740() GS:99479d30() 
> knlGS:
> [4005007.702626] CS:  0010 DS:  ES:  CR0: 80050033
> [4005007.702629] CR2: ffd6 CR3: 0003253fc000 CR4: 
> 003506e0
> [4005007.702633] Call Trace:
> [4005007.702636]  
> [4005007.702640]  amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu]
> [4005007.703002]  full_proxy_read+0x5c/0x80
> [4005007.703011]  vfs_read+0x9f/0x1a0
> [4005007.703019]  ksys_read+0x67/0xe0
> [4005007.703023]  __x64_sys_read+0x19/0x20
> [4005007.703028]  do_syscall_64+0x5c/0xc0
> [4005007.703034]  ? do_user_addr_fault+0x1e3/0x670
> [4005007.703040]  ? exit_to_user_mode_prepare+0x37/0xb0
> [4005007.703047]  ? irqentry_exit_to_user_mode+0x9/0x20
> [4005007.703052]  ? irqentry_exit+0x19/0x30
> [4005007.703057]  ? exc_page_fault+0x89/0x160
> [4005007.703062]  ? asm_exc_page_fault+0x8/0x30
> [4005007.703068]  entry_SYSCALL_64_after_hwframe+0x44/0xae
> [4005007.703075] RIP: 0033:0x7f5e07672992
> [4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 
> 00 0f 1f 44 00 00 f3 0f1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 
> 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e   c 28 48 89 54 24
> [4005007.703083] RSP: 002b:7ffe03097898 EFLAGS: 0246 ORIG_RAX: 
> 
> [4005007.703088] RAX: ffda RBX: 0002 RCX: 
> 7f5e07672992
> [4005007.703091] RDX: 0002 RSI: 7f5e06753000 RDI: 
> 0003
> [4005007.703094] RBP: 7f5e06753000 R08: 7f5e06752010 R09: 
> 7f5e06752010
> [4005007.703096] R10: 0022 R11: 0246 R12: 
> 00022000
> [4005007.703099] R13: 0003 R14: 0002 R15: 
> 0002
> [4005007.703105]  
> [4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash 
> af_alg binfmt_misc nls_   iso8859_1 ipmi_ssif ast intel_rapl_msr 
> intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t   tm 
> edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl 
> sch_fq_codel ipmi_devintf ipm   i_msghandler msr parport_pc ppdev lp 
> parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo   mon 
> ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) 
> amdttm(OE) iommu_v   2 amd_sched(OE) amdkcl(OE) drm_kms_helper 
> syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_coredrm igb ahci 
> xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca
> [4005007.703184] CR2: 
> [4005007.703188] ---[ end trace ac65a538d240da39 ]---
> [4005007.800865] RIP: 0010:0x0
> [4005007.800871] Code: Unable to access opcode bytes at RIP 
> 0xffd6.
> [4005007.800874] RSP: 0018:a82b46d27da0 EFLAGS: 00010206
> [4005007.800878] RAX:  RBX:  RCX: 
> a82b46d27e68
> [4005007.800881] RDX: 0001 RSI:  RDI: 
> 9940656e
> [4005007.800883] RBP: a82b46d27dd8 R08:  R09: 
> 994060c07980
> [4005007.800886] R10: 0002 R11:  R12: 
> 7f5e06753000
> [4005007.800888] R13: 9940656e R14: a82b46d27e68 R15: 
> 7f5e06753000
> [4005007.800891] FS:  7f5e0755b740() GS:99479d30() 
> knlGS:
> [4005007.800895] CS:  0010 DS:  ES:  CR0: 80050033
> [4005007.800898] CR2: ffd6 CR3: 0003253fc000 CR4: 
> 003506e0
>
>

Re: [PATCH] drm/msm/adreno: Drop WARN_ON from patchid lookup for new GPUs

2023-10-23 Thread Rob Clark

On Mon, Oct 23, 2023 at 12:56 PM Konrad Dybcio  wrote:
>
>
>
> On 10/23/23 21:42, Rob Clark wrote:
> > On Mon, Oct 23, 2023 at 7:29 AM Konrad Dybcio  
> > wrote:
> >>
> >> New GPUs still use the lower 2 bytes of the chip id (in whatever form
> >> it comes) to signify silicon revision. Drop the warning that makes it
> >> sound as if that was unintended.
> >>
> >> Fixes: 90b593ce1c9e ("drm/msm/adreno: Switch to chip-id for identifying 
> >> GPU")
> >> Signed-off-by: Konrad Dybcio 
> >> ---
> >>   drivers/gpu/drm/msm/adreno/adreno_gpu.h | 5 -
> >>   1 file changed, 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
> >> b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> >> index 80b3f6312116..9a1ec42155fd 100644
> >> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> >> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> >> @@ -203,11 +203,6 @@ struct adreno_platform_config {
> >>
> >>   static inline uint8_t adreno_patchid(const struct adreno_gpu *gpu)
> >>   {
> >> -   /* It is probably ok to assume legacy "adreno_rev" format
> >> -* for all a6xx devices, but probably best to limit this
> >> -* to older things.
> >> -*/
> >> -   WARN_ON_ONCE(gpu->info->family >= ADRENO_6XX_GEN1);
> >
> > Maybe just change it to ADRENO_6XX_GEN4?
> That also applies to 700

Then the warn is warning about what it is supposed to ;-)

I guess this is coming from a6xx_gmu_fw_start()?  I think we need a
different way to construct the gmu chipid, since the point of this was
to not depend on the low 8b having any particular meaning.  Perhaps we
should just get the gmu chipid from the device table.

BR,
-R

[PATCH drm-misc-next v7 5/7] drm/gpuvm: track/lock/validate external/evicted objects

2023-10-23 Thread Danilo Krummrich

Currently the DRM GPUVM offers common infrastructure to track GPU VA
allocations and mappings, generically connect GPU VA mappings to their
backing buffers and perform more complex mapping operations on the GPU VA
space.

However, there are more design patterns commonly used by drivers, which
can potentially be generalized in order to make the DRM GPUVM represent
a basis for GPU-VM implementations. In this context, this patch aims
at generalizing the following elements.

1) Provide a common dma-resv for GEM objects not being used outside of
   this GPU-VM.

2) Provide tracking of external GEM objects (GEM objects which are
   shared with other GPU-VMs).

3) Provide functions to efficiently lock all GEM objects dma-resv the
   GPU-VM contains mappings of.

4) Provide tracking of evicted GEM objects the GPU-VM contains mappings
   of, such that validation of evicted GEM objects is accelerated.

5) Provide some convinience functions for common patterns.

Big thanks to Boris Brezillon for his help to figure out locking for
drivers updating the GPU VA space within the fence signalling path.

Suggested-by: Matthew Brost 
Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/drm_gpuvm.c | 633 
 include/drm/drm_gpuvm.h | 250 ++
 2 files changed, 883 insertions(+)

diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
index 7f4f5919f84c..01cbeb98755a 100644
--- a/drivers/gpu/drm/drm_gpuvm.c
+++ b/drivers/gpu/drm/drm_gpuvm.c
@@ -82,6 +82,21 @@
  * _gem_object list of _gpuvm_bos for an existing instance of this
  * particular combination. If not existent a new instance is created and linked
  * to the _gem_object.
+ *
+ * _gpuvm_bo structures, since unique for a given _gpuvm, are also used
+ * as entry for the _gpuvm's lists of external and evicted objects. Those
+ * lists are maintained in order to accelerate locking of dma-resv locks and
+ * validation of evicted objects bound in a _gpuvm. For instance, all
+ * _gem_object's _resv of a given _gpuvm can be locked by calling
+ * drm_gpuvm_exec_lock(). Once locked drivers can call drm_gpuvm_validate() in
+ * order to validate all evicted _gem_objects. It is also possible to lock
+ * additional _gem_objects by providing the corresponding parameters to
+ * drm_gpuvm_exec_lock() as well as open code the _exec loop while making
+ * use of helper functions such as drm_gpuvm_prepare_range() or
+ * drm_gpuvm_prepare_objects().
+ *
+ * Every bound _gem_object is treated as external object when its _resv
+ * structure is different than the _gpuvm's common _resv structure.
  */
 
 /**
@@ -429,6 +444,20 @@
  * Subsequent calls to drm_gpuvm_bo_obtain() for the same _gpuvm and
  * _gem_object must be able to observe previous creations and destructions
  * of _gpuvm_bos in order to keep instances unique.
+ *
+ * The _gpuvm's lists for keeping track of external and evicted objects are
+ * protected against concurrent insertion / removal and iteration internally.
+ *
+ * However, drivers still need ensure to protect concurrent calls to functions
+ * iterating those lists, namely drm_gpuvm_prepare_objects() and
+ * drm_gpuvm_validate().
+ *
+ * Alternatively, drivers can set the _GPUVM_RESV_PROTECTED flag to 
indicate
+ * that the corresponding _resv locks are held in order to protect the
+ * lists. If _GPUVM_RESV_PROTECTED is set, internal locking is disabled and
+ * the corresponding lockdep checks are enabled. This is an optimization for
+ * drivers which are capable of taking the corresponding _resv locks and
+ * hence do not require internal locking.
  */
 
 /**
@@ -641,6 +670,201 @@
  * }
  */
 
+/**
+ * get_next_vm_bo_from_list() - get the next vm_bo element
+ * @__gpuvm: the _gpuvm
+ * @__list_name: the name of the list we're iterating on
+ * @__local_list: a pointer to the local list used to store already iterated 
items
+ * @__prev_vm_bo: the previous element we got from get_next_vm_bo_from_list()
+ *
+ * This helper is here to provide lockless list iteration. Lockless as in, the
+ * iterator releases the lock immediately after picking the first element from
+ * the list, so list insertion deletion can happen concurrently.
+ *
+ * Elements popped from the original list are kept in a local list, so removal
+ * and is_empty checks can still happen while we're iterating the list.
+ */
+#define get_next_vm_bo_from_list(__gpuvm, __list_name, __local_list, 
__prev_vm_bo) \
+   ({  
\
+   struct drm_gpuvm_bo *__vm_bo = NULL;
\
+   
\
+   drm_gpuvm_bo_put(__prev_vm_bo); 
\
+   
\
+   spin_lock(&(__gpuvm)->__list_name.lock);

[PATCH drm-misc-next v7 7/7] drm/nouveau: use GPUVM common infrastructure

2023-10-23 Thread Danilo Krummrich

GPUVM provides common infrastructure to track external and evicted GEM
objects as well as locking and validation helpers.

Especially external and evicted object tracking is a huge improvement
compared to the current brute force approach of iterating all mappings
in order to lock and validate the GPUVM's GEM objects. Hence, make us of
it.

Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c|   4 +-
 drivers/gpu/drm/nouveau/nouveau_exec.c  |  57 -
 drivers/gpu/drm/nouveau/nouveau_exec.h  |   4 -
 drivers/gpu/drm/nouveau/nouveau_sched.c |   9 +-
 drivers/gpu/drm/nouveau/nouveau_sched.h |   7 +-
 drivers/gpu/drm/nouveau/nouveau_uvmm.c  | 104 +++-
 6 files changed, 94 insertions(+), 91 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 7afad86da64b..b7dda486a7ea 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1061,17 +1061,18 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool 
evict,
 {
struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
struct nouveau_bo *nvbo = nouveau_bo(bo);
+   struct drm_gem_object *obj = >base;
struct ttm_resource *old_reg = bo->resource;
struct nouveau_drm_tile *new_tile = NULL;
int ret = 0;
 
-
if (new_reg->mem_type == TTM_PL_TT) {
ret = nouveau_ttm_tt_bind(bo->bdev, bo->ttm, new_reg);
if (ret)
return ret;
}
 
+   drm_gpuvm_bo_gem_evict(obj, evict);
nouveau_bo_move_ntfy(bo, new_reg);
ret = ttm_bo_wait_ctx(bo, ctx);
if (ret)
@@ -1136,6 +1137,7 @@ nouveau_bo_move(struct ttm_buffer_object *bo, bool evict,
 out_ntfy:
if (ret) {
nouveau_bo_move_ntfy(bo, bo->resource);
+   drm_gpuvm_bo_gem_evict(obj, !evict);
}
return ret;
 }
diff --git a/drivers/gpu/drm/nouveau/nouveau_exec.c 
b/drivers/gpu/drm/nouveau/nouveau_exec.c
index bf6c12f4342a..9d9835fb5970 100644
--- a/drivers/gpu/drm/nouveau/nouveau_exec.c
+++ b/drivers/gpu/drm/nouveau/nouveau_exec.c
@@ -1,7 +1,5 @@
 // SPDX-License-Identifier: MIT
 
-#include 
-
 #include "nouveau_drv.h"
 #include "nouveau_gem.h"
 #include "nouveau_mem.h"
@@ -86,14 +84,12 @@
  */
 
 static int
-nouveau_exec_job_submit(struct nouveau_job *job)
+nouveau_exec_job_submit(struct nouveau_job *job,
+   struct drm_gpuvm_exec *vme)
 {
struct nouveau_exec_job *exec_job = to_nouveau_exec_job(job);
struct nouveau_cli *cli = job->cli;
struct nouveau_uvmm *uvmm = nouveau_cli_uvmm(cli);
-   struct drm_exec *exec = >exec;
-   struct drm_gem_object *obj;
-   unsigned long index;
int ret;
 
/* Create a new fence, but do not emit yet. */
@@ -102,52 +98,29 @@ nouveau_exec_job_submit(struct nouveau_job *job)
return ret;
 
nouveau_uvmm_lock(uvmm);
-   drm_exec_init(exec, DRM_EXEC_INTERRUPTIBLE_WAIT |
-   DRM_EXEC_IGNORE_DUPLICATES);
-   drm_exec_until_all_locked(exec) {
-   struct drm_gpuva *va;
-
-   drm_gpuvm_for_each_va(va, >base) {
-   if (unlikely(va == >base.kernel_alloc_node))
-   continue;
-
-   ret = drm_exec_prepare_obj(exec, va->gem.obj, 1);
-   drm_exec_retry_on_contention(exec);
-   if (ret)
-   goto err_uvmm_unlock;
-   }
+   ret = drm_gpuvm_exec_lock(vme);
+   if (ret) {
+   nouveau_uvmm_unlock(uvmm);
+   return ret;
}
nouveau_uvmm_unlock(uvmm);
 
-   drm_exec_for_each_locked_object(exec, index, obj) {
-   struct nouveau_bo *nvbo = nouveau_gem_object(obj);
-
-   ret = nouveau_bo_validate(nvbo, true, false);
-   if (ret)
-   goto err_exec_fini;
+   ret = drm_gpuvm_exec_validate(vme);
+   if (ret) {
+   drm_gpuvm_exec_unlock(vme);
+   return ret;
}
 
return 0;
-
-err_uvmm_unlock:
-   nouveau_uvmm_unlock(uvmm);
-err_exec_fini:
-   drm_exec_fini(exec);
-   return ret;
-
 }
 
 static void
-nouveau_exec_job_armed_submit(struct nouveau_job *job)
+nouveau_exec_job_armed_submit(struct nouveau_job *job,
+ struct drm_gpuvm_exec *vme)
 {
-   struct drm_exec *exec = >exec;
-   struct drm_gem_object *obj;
-   unsigned long index;
-
-   drm_exec_for_each_locked_object(exec, index, obj)
-   dma_resv_add_fence(obj->resv, job->done_fence, job->resv_usage);
-
-   drm_exec_fini(exec);
+   drm_gpuvm_exec_resv_add_fence(vme, job->done_fence,
+ job->resv_usage, job->resv_usage);
+   drm_gpuvm_exec_unlock(vme);
 }
 
 static struct dma_fence *
diff --git

[PATCH drm-misc-next v7 4/7] drm/gpuvm: add an abstraction for a VM / BO combination

2023-10-23 Thread Danilo Krummrich

Add an abstraction layer between the drm_gpuva mappings of a particular
drm_gem_object and this GEM object itself. The abstraction represents a
combination of a drm_gem_object and drm_gpuvm. The drm_gem_object holds
a list of drm_gpuvm_bo structures (the structure representing this
abstraction), while each drm_gpuvm_bo contains list of mappings of this
GEM object.

This has multiple advantages:

1) We can use the drm_gpuvm_bo structure to attach it to various lists
   of the drm_gpuvm. This is useful for tracking external and evicted
   objects per VM, which is introduced in subsequent patches.

2) Finding mappings of a certain drm_gem_object mapped in a certain
   drm_gpuvm becomes much cheaper.

3) Drivers can derive and extend the structure to easily represent
   driver specific states of a BO for a certain GPUVM.

The idea of this abstraction was taken from amdgpu, hence the credit for
this idea goes to the developers of amdgpu.

Cc: Christian König 
Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/drm_gpuvm.c| 335 +
 drivers/gpu/drm/nouveau/nouveau_uvmm.c |  64 +++--
 include/drm/drm_gem.h  |  32 +--
 include/drm/drm_gpuvm.h| 188 +-
 4 files changed, 533 insertions(+), 86 deletions(-)

diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
index c03332883432..7f4f5919f84c 100644
--- a/drivers/gpu/drm/drm_gpuvm.c
+++ b/drivers/gpu/drm/drm_gpuvm.c
@@ -70,6 +70,18 @@
  * _gem_object, such as the _gem_object containing the root page table,
  * but it can also be a 'dummy' object, which can be allocated with
  * drm_gpuvm_resv_object_alloc().
+ *
+ * In order to connect a struct drm_gpuva its backing _gem_object each
+ * _gem_object maintains a list of _gpuvm_bo structures, and each
+ * _gpuvm_bo contains a list of _gpuva structures.
+ *
+ * A _gpuvm_bo is an abstraction that represents a combination of a
+ * _gpuvm and a _gem_object. Every such combination should be unique.
+ * This is ensured by the API through drm_gpuvm_bo_obtain() and
+ * drm_gpuvm_bo_obtain_prealloc() which first look into the corresponding
+ * _gem_object list of _gpuvm_bos for an existing instance of this
+ * particular combination. If not existent a new instance is created and linked
+ * to the _gem_object.
  */
 
 /**
@@ -395,21 +407,28 @@
 /**
  * DOC: Locking
  *
- * Generally, the GPU VA manager does not take care of locking itself, it is
- * the drivers responsibility to take care about locking. Drivers might want to
- * protect the following operations: inserting, removing and iterating
- * _gpuva objects as well as generating all kinds of operations, such as
- * split / merge or prefetch.
- *
- * The GPU VA manager also does not take care of the locking of the backing
- * _gem_object buffers GPU VA lists by itself; drivers are responsible to
- * enforce mutual exclusion using either the GEMs dma_resv lock or 
alternatively
- * a driver specific external lock. For the latter see also
- * drm_gem_gpuva_set_lock().
- *
- * However, the GPU VA manager contains lockdep checks to ensure callers of its
- * API hold the corresponding lock whenever the _gem_objects GPU VA list is
- * accessed by functions such as drm_gpuva_link() or drm_gpuva_unlink().
+ * In terms of managing _gpuva entries DRM GPUVM does not take care of
+ * locking itself, it is the drivers responsibility to take care about locking.
+ * Drivers might want to protect the following operations: inserting, removing
+ * and iterating _gpuva objects as well as generating all kinds of
+ * operations, such as split / merge or prefetch.
+ *
+ * DRM GPUVM also does not take care of the locking of the backing
+ * _gem_object buffers GPU VA lists and _gpuvm_bo abstractions by
+ * itself; drivers are responsible to enforce mutual exclusion using either the
+ * GEMs dma_resv lock or alternatively a driver specific external lock. For the
+ * latter see also drm_gem_gpuva_set_lock().
+ *
+ * However, DRM GPUVM contains lockdep checks to ensure callers of its API hold
+ * the corresponding lock whenever the _gem_objects GPU VA list is accessed
+ * by functions such as drm_gpuva_link() or drm_gpuva_unlink(), but also
+ * drm_gpuvm_bo_obtain() and drm_gpuvm_bo_put().
+ *
+ * The latter is required since on creation and destruction of a _gpuvm_bo
+ * the _gpuvm_bo is attached / removed from the _gem_objects gpuva 
list.
+ * Subsequent calls to drm_gpuvm_bo_obtain() for the same _gpuvm and
+ * _gem_object must be able to observe previous creations and destructions
+ * of _gpuvm_bos in order to keep instances unique.
  */
 
 /**
@@ -439,6 +458,7 @@
  * {
  * struct drm_gpuva_ops *ops;
  * struct drm_gpuva_op *op
+ * struct drm_gpuvm_bo *vm_bo;
  *
  * driver_lock_va_space();
  * ops = drm_gpuvm_sm_map_ops_create(gpuvm, addr, range,
@@ -446,6 +466,10 @@
  * if (IS_ERR(ops))
  * return

[PATCH drm-misc-next v7 6/7] drm/nouveau: make use of the GPUVM's shared dma-resv

2023-10-23 Thread Danilo Krummrich

DRM GEM objects private to a single GPUVM can use a shared dma-resv.
Make use of the shared dma-resv of GPUVM rather than a driver specific
one.

The shared dma-resv originates from a "root" GEM object serving as
container for the dma-resv to make it compatible with drm_exec.

In order to make sure the object proving the shared dma-resv can't be
freed up before the objects making use of it, let every such GEM object
take a reference on it.

Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/nouveau/nouveau_bo.c   | 11 +--
 drivers/gpu/drm/nouveau/nouveau_bo.h   |  5 +
 drivers/gpu/drm/nouveau/nouveau_gem.c  | 10 --
 drivers/gpu/drm/nouveau/nouveau_uvmm.c |  7 ++-
 drivers/gpu/drm/nouveau/nouveau_uvmm.h |  1 -
 5 files changed, 24 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 0f3bd187ede6..7afad86da64b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -148,10 +148,17 @@ nouveau_bo_del_ttm(struct ttm_buffer_object *bo)
 * If nouveau_bo_new() allocated this buffer, the GEM object was never
 * initialized, so don't attempt to release it.
 */
-   if (bo->base.dev)
+   if (bo->base.dev) {
+   /* Gem objects not being shared with other VMs get their
+* dma_resv from a root GEM object.
+*/
+   if (nvbo->no_share)
+   drm_gem_object_put(nvbo->r_obj);
+
drm_gem_object_release(>base);
-   else
+   } else {
dma_resv_fini(>base._resv);
+   }
 
kfree(nvbo);
 }
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.h 
b/drivers/gpu/drm/nouveau/nouveau_bo.h
index 07f671cf895e..70c551921a9e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.h
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.h
@@ -26,6 +26,11 @@ struct nouveau_bo {
struct list_head entry;
int pbbo_index;
bool validate_mapped;
+
+   /* Root GEM object we derive the dma_resv of in case this BO is not
+* shared between VMs.
+*/
+   struct drm_gem_object *r_obj;
bool no_share;
 
/* GPU address space is independent of CPU word size */
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index a0d303e5ce3d..49c2bcbef129 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -111,7 +111,8 @@ nouveau_gem_object_open(struct drm_gem_object *gem, struct 
drm_file *file_priv)
if (vmm->vmm.object.oclass < NVIF_CLASS_VMM_NV50)
return 0;
 
-   if (nvbo->no_share && uvmm && >resv != nvbo->bo.base.resv)
+   if (nvbo->no_share && uvmm &&
+   drm_gpuvm_resv(>base) != nvbo->bo.base.resv)
return -EPERM;
 
ret = ttm_bo_reserve(>bo, false, false, NULL);
@@ -245,7 +246,7 @@ nouveau_gem_new(struct nouveau_cli *cli, u64 size, int 
align, uint32_t domain,
if (unlikely(!uvmm))
return -EINVAL;
 
-   resv = >resv;
+   resv = drm_gpuvm_resv(>base);
}
 
if (!(domain & (NOUVEAU_GEM_DOMAIN_VRAM | NOUVEAU_GEM_DOMAIN_GART)))
@@ -288,6 +289,11 @@ nouveau_gem_new(struct nouveau_cli *cli, u64 size, int 
align, uint32_t domain,
if (drm->client.device.info.family >= NV_DEVICE_INFO_V0_TESLA)
nvbo->valid_domains &= domain;
 
+   if (nvbo->no_share) {
+   nvbo->r_obj = drm_gpuvm_resv_obj(>base);
+   drm_gem_object_get(nvbo->r_obj);
+   }
+
*pnvbo = nvbo;
return 0;
 }
diff --git a/drivers/gpu/drm/nouveau/nouveau_uvmm.c 
b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
index 1e95b0a1b047..005bb9c77990 100644
--- a/drivers/gpu/drm/nouveau/nouveau_uvmm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
@@ -1842,7 +1842,6 @@ nouveau_uvmm_init(struct nouveau_uvmm *uvmm, struct 
nouveau_cli *cli,
int ret;
 
mutex_init(>mutex);
-   dma_resv_init(>resv);
mt_init_flags(>region_mt, MT_FLAGS_LOCK_EXTERN);
mt_set_external_lock(>region_mt, >mutex);
 
@@ -1885,14 +1884,14 @@ nouveau_uvmm_init(struct nouveau_uvmm *uvmm, struct 
nouveau_cli *cli,
kernel_managed_addr, kernel_managed_size,
NULL, 0, >uvmm.vmm.vmm);
if (ret)
-   goto out_free_gpuva_mgr;
+   goto out_gpuvm_fini;
 
cli->uvmm.vmm.cli = cli;
mutex_unlock(>mutex);
 
return 0;
 
-out_free_gpuva_mgr:
+out_gpuvm_fini:
drm_gpuvm_destroy(>base);
 out_unlock:
mutex_unlock(>mutex);
@@ -1950,6 +1949,4 @@ nouveau_uvmm_fini(struct nouveau_uvmm *uvmm)
nouveau_vmm_fini(>vmm);
drm_gpuvm_destroy(>base);
mutex_unlock(>mutex);
-
-   dma_resv_fini(>resv);
 }
diff --git a/drivers/gpu/drm/nouveau/nouveau_uvmm.h 
b/drivers/gpu/drm/nouveau/nouveau_uvmm.h

[PATCH drm-misc-next v7 1/7] drm/gpuvm: convert WARN() to drm_WARN() variants

2023-10-23 Thread Danilo Krummrich

Use drm_WARN() and drm_WARN_ON() variants to indicate drivers the
context the failing VM resides in.

Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/drm_gpuvm.c| 32 ++
 drivers/gpu/drm/nouveau/nouveau_uvmm.c |  3 ++-
 include/drm/drm_gpuvm.h|  7 ++
 3 files changed, 26 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
index 08c088319652..d7367a202fee 100644
--- a/drivers/gpu/drm/drm_gpuvm.c
+++ b/drivers/gpu/drm/drm_gpuvm.c
@@ -614,12 +614,12 @@ static int __drm_gpuva_insert(struct drm_gpuvm *gpuvm,
 static void __drm_gpuva_remove(struct drm_gpuva *va);
 
 static bool
-drm_gpuvm_check_overflow(u64 addr, u64 range)
+drm_gpuvm_check_overflow(struct drm_gpuvm *gpuvm, u64 addr, u64 range)
 {
u64 end;
 
-   return WARN(check_add_overflow(addr, range, ),
-   "GPUVA address limited to %zu bytes.\n", sizeof(end));
+   return drm_WARN(gpuvm->drm, check_add_overflow(addr, range, ),
+   "GPUVA address limited to %zu bytes.\n", sizeof(end));
 }
 
 static bool
@@ -647,7 +647,7 @@ static bool
 drm_gpuvm_range_valid(struct drm_gpuvm *gpuvm,
  u64 addr, u64 range)
 {
-   return !drm_gpuvm_check_overflow(addr, range) &&
+   return !drm_gpuvm_check_overflow(gpuvm, addr, range) &&
   drm_gpuvm_in_mm_range(gpuvm, addr, range) &&
   !drm_gpuvm_in_kernel_node(gpuvm, addr, range);
 }
@@ -656,6 +656,7 @@ drm_gpuvm_range_valid(struct drm_gpuvm *gpuvm,
  * drm_gpuvm_init() - initialize a _gpuvm
  * @gpuvm: pointer to the _gpuvm to initialize
  * @name: the name of the GPU VA space
+ * @drm: the _device this VM resides in
  * @start_offset: the start offset of the GPU VA space
  * @range: the size of the GPU VA space
  * @reserve_offset: the start of the kernel reserved GPU VA area
@@ -668,8 +669,8 @@ drm_gpuvm_range_valid(struct drm_gpuvm *gpuvm,
  *  is expected to be managed by the surrounding driver structures.
  */
 void
-drm_gpuvm_init(struct drm_gpuvm *gpuvm,
-  const char *name,
+drm_gpuvm_init(struct drm_gpuvm *gpuvm, const char *name,
+  struct drm_device *drm,
   u64 start_offset, u64 range,
   u64 reserve_offset, u64 reserve_range,
   const struct drm_gpuvm_ops *ops)
@@ -677,20 +678,20 @@ drm_gpuvm_init(struct drm_gpuvm *gpuvm,
gpuvm->rb.tree = RB_ROOT_CACHED;
INIT_LIST_HEAD(>rb.list);
 
-   drm_gpuvm_check_overflow(start_offset, range);
-   gpuvm->mm_start = start_offset;
-   gpuvm->mm_range = range;
-
gpuvm->name = name ? name : "unknown";
gpuvm->ops = ops;
+   gpuvm->drm = drm;
 
-   memset(>kernel_alloc_node, 0, sizeof(struct drm_gpuva));
+   drm_gpuvm_check_overflow(gpuvm, start_offset, range);
+   gpuvm->mm_start = start_offset;
+   gpuvm->mm_range = range;
 
+   memset(>kernel_alloc_node, 0, sizeof(struct drm_gpuva));
if (reserve_range) {
gpuvm->kernel_alloc_node.va.addr = reserve_offset;
gpuvm->kernel_alloc_node.va.range = reserve_range;
 
-   if (likely(!drm_gpuvm_check_overflow(reserve_offset,
+   if (likely(!drm_gpuvm_check_overflow(gpuvm, reserve_offset,
 reserve_range)))
__drm_gpuva_insert(gpuvm, >kernel_alloc_node);
}
@@ -712,8 +713,8 @@ drm_gpuvm_destroy(struct drm_gpuvm *gpuvm)
if (gpuvm->kernel_alloc_node.va.range)
__drm_gpuva_remove(>kernel_alloc_node);
 
-   WARN(!RB_EMPTY_ROOT(>rb.tree.rb_root),
-"GPUVA tree is not empty, potentially leaking memory.");
+   drm_WARN(gpuvm->drm, !RB_EMPTY_ROOT(>rb.tree.rb_root),
+"GPUVA tree is not empty, potentially leaking memory.\n");
 }
 EXPORT_SYMBOL_GPL(drm_gpuvm_destroy);
 
@@ -795,7 +796,8 @@ drm_gpuva_remove(struct drm_gpuva *va)
struct drm_gpuvm *gpuvm = va->vm;
 
if (unlikely(va == >kernel_alloc_node)) {
-   WARN(1, "Can't destroy kernel reserved node.\n");
+   drm_WARN(gpuvm->drm, 1,
+"Can't destroy kernel reserved node.\n");
return;
}
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_uvmm.c 
b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
index 5cf892c50f43..aaf5d28bd587 100644
--- a/drivers/gpu/drm/nouveau/nouveau_uvmm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
@@ -1808,6 +1808,7 @@ int
 nouveau_uvmm_init(struct nouveau_uvmm *uvmm, struct nouveau_cli *cli,
  u64 kernel_managed_addr, u64 kernel_managed_size)
 {
+   struct drm_device *drm = cli->drm->dev;
int ret;
u64 kernel_managed_end = kernel_managed_addr + kernel_managed_size;
 
@@ -1836,7 +1837,7 @@ nouveau_uvmm_init(struct nouveau_uvmm *uvmm, struct 
nouveau_cli *cli,
uvmm->kernel_managed_addr = kernel_managed_addr;

[PATCH drm-misc-next v7 3/7] drm/gpuvm: add drm_gpuvm_flags to drm_gpuvm

2023-10-23 Thread Danilo Krummrich

Introduce flags for struct drm_gpuvm, this required by subsequent
commits.

Reviewed-by: Thomas Hellström 
Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/drm_gpuvm.c|  3 +++
 drivers/gpu/drm/nouveau/nouveau_uvmm.c |  2 +-
 include/drm/drm_gpuvm.h| 16 
 3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
index b9742742a0e8..c03332883432 100644
--- a/drivers/gpu/drm/drm_gpuvm.c
+++ b/drivers/gpu/drm/drm_gpuvm.c
@@ -702,6 +702,7 @@ EXPORT_SYMBOL_GPL(drm_gpuvm_resv_object_alloc);
  * drm_gpuvm_init() - initialize a _gpuvm
  * @gpuvm: pointer to the _gpuvm to initialize
  * @name: the name of the GPU VA space
+ * @flags: the _gpuvm_flags for this GPUVM
  * @drm: the _device this VM resides in
  * @r_obj: the resv _gem_object providing the GPUVM's common _resv
  * @start_offset: the start offset of the GPU VA space
@@ -717,6 +718,7 @@ EXPORT_SYMBOL_GPL(drm_gpuvm_resv_object_alloc);
  */
 void
 drm_gpuvm_init(struct drm_gpuvm *gpuvm, const char *name,
+  enum drm_gpuvm_flags flags,
   struct drm_device *drm,
   struct drm_gem_object *r_obj,
   u64 start_offset, u64 range,
@@ -727,6 +729,7 @@ drm_gpuvm_init(struct drm_gpuvm *gpuvm, const char *name,
INIT_LIST_HEAD(>rb.list);
 
gpuvm->name = name ? name : "unknown";
+   gpuvm->flags = flags;
gpuvm->ops = ops;
gpuvm->drm = drm;
gpuvm->r_obj = r_obj;
diff --git a/drivers/gpu/drm/nouveau/nouveau_uvmm.c 
b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
index b4e7d662961a..ed439bf4032f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_uvmm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
@@ -1844,7 +1844,7 @@ nouveau_uvmm_init(struct nouveau_uvmm *uvmm, struct 
nouveau_cli *cli,
uvmm->kernel_managed_addr = kernel_managed_addr;
uvmm->kernel_managed_size = kernel_managed_size;
 
-   drm_gpuvm_init(>base, cli->name, drm, r_obj,
+   drm_gpuvm_init(>base, cli->name, 0, drm, r_obj,
   NOUVEAU_VA_SPACE_START,
   NOUVEAU_VA_SPACE_END,
   kernel_managed_addr, kernel_managed_size,
diff --git a/include/drm/drm_gpuvm.h b/include/drm/drm_gpuvm.h
index 5f43a224d0f4..47cbacb244b9 100644
--- a/include/drm/drm_gpuvm.h
+++ b/include/drm/drm_gpuvm.h
@@ -184,6 +184,16 @@ static inline bool drm_gpuva_invalidated(struct drm_gpuva 
*va)
return va->flags & DRM_GPUVA_INVALIDATED;
 }
 
+/**
+ * enum drm_gpuvm_flags - flags for struct drm_gpuvm
+ */
+enum drm_gpuvm_flags {
+   /**
+* @DRM_GPUVM_USERBITS: user defined bits
+*/
+   DRM_GPUVM_USERBITS = BIT(0),
+};
+
 /**
  * struct drm_gpuvm - DRM GPU VA Manager
  *
@@ -202,6 +212,11 @@ struct drm_gpuvm {
 */
const char *name;
 
+   /**
+* @flags: the _gpuvm_flags of this GPUVM
+*/
+   enum drm_gpuvm_flags flags;
+
/**
 * @drm: the _device this VM lives in
 */
@@ -252,6 +267,7 @@ struct drm_gpuvm {
 };
 
 void drm_gpuvm_init(struct drm_gpuvm *gpuvm, const char *name,
+   enum drm_gpuvm_flags flags,
struct drm_device *drm,
struct drm_gem_object *r_obj,
u64 start_offset, u64 range,
-- 
2.41.0

[PATCH drm-misc-next v7 2/7] drm/gpuvm: add common dma-resv per struct drm_gpuvm

2023-10-23 Thread Danilo Krummrich

Provide a common dma-resv for GEM objects not being used outside of this
GPU-VM. This is used in a subsequent patch to generalize dma-resv,
external and evicted object handling and GEM validation.

Reviewed-by: Thomas Hellström 
Signed-off-by: Danilo Krummrich 
---
 drivers/gpu/drm/drm_gpuvm.c| 53 ++
 drivers/gpu/drm/nouveau/nouveau_uvmm.c | 13 ++-
 include/drm/drm_gpuvm.h| 33 
 3 files changed, 97 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_gpuvm.c b/drivers/gpu/drm/drm_gpuvm.c
index d7367a202fee..b9742742a0e8 100644
--- a/drivers/gpu/drm/drm_gpuvm.c
+++ b/drivers/gpu/drm/drm_gpuvm.c
@@ -61,6 +61,15 @@
  * contained within struct drm_gpuva already. Hence, for inserting _gpuva
  * entries from within dma-fence signalling critical sections it is enough to
  * pre-allocate the _gpuva structures.
+ *
+ * _gem_objects which are private to a single VM can share a common
+ * _resv in order to improve locking efficiency (e.g. with _exec).
+ * For this purpose drivers must pass a _gem_object to drm_gpuvm_init(), in
+ * the following called 'resv object', which serves as the container of the
+ * GPUVM's shared _resv. This resv object can be a driver specific
+ * _gem_object, such as the _gem_object containing the root page table,
+ * but it can also be a 'dummy' object, which can be allocated with
+ * drm_gpuvm_resv_object_alloc().
  */
 
 /**
@@ -652,11 +661,49 @@ drm_gpuvm_range_valid(struct drm_gpuvm *gpuvm,
   !drm_gpuvm_in_kernel_node(gpuvm, addr, range);
 }
 
+static void
+drm_gpuvm_gem_object_free(struct drm_gem_object *obj)
+{
+   drm_gem_object_release(obj);
+   kfree(obj);
+}
+
+static const struct drm_gem_object_funcs drm_gpuvm_object_funcs = {
+   .free = drm_gpuvm_gem_object_free,
+};
+
+/**
+ * drm_gpuvm_resv_object_alloc() - allocate a dummy _gem_object
+ * @drm: the drivers _device
+ *
+ * Allocates a dummy _gem_object which can be passed to drm_gpuvm_init() in
+ * order to serve as root GEM object providing the _resv shared across
+ * _gem_objects local to a single GPUVM.
+ *
+ * Returns: the _gem_object on success, NULL on failure
+ */
+struct drm_gem_object *
+drm_gpuvm_resv_object_alloc(struct drm_device *drm)
+{
+   struct drm_gem_object *obj;
+
+   obj = kzalloc(sizeof(*obj), GFP_KERNEL);
+   if (!obj)
+   return NULL;
+
+   obj->funcs = _gpuvm_object_funcs;
+   drm_gem_private_object_init(drm, obj, 0);
+
+   return obj;
+}
+EXPORT_SYMBOL_GPL(drm_gpuvm_resv_object_alloc);
+
 /**
  * drm_gpuvm_init() - initialize a _gpuvm
  * @gpuvm: pointer to the _gpuvm to initialize
  * @name: the name of the GPU VA space
  * @drm: the _device this VM resides in
+ * @r_obj: the resv _gem_object providing the GPUVM's common _resv
  * @start_offset: the start offset of the GPU VA space
  * @range: the size of the GPU VA space
  * @reserve_offset: the start of the kernel reserved GPU VA area
@@ -671,6 +718,7 @@ drm_gpuvm_range_valid(struct drm_gpuvm *gpuvm,
 void
 drm_gpuvm_init(struct drm_gpuvm *gpuvm, const char *name,
   struct drm_device *drm,
+  struct drm_gem_object *r_obj,
   u64 start_offset, u64 range,
   u64 reserve_offset, u64 reserve_range,
   const struct drm_gpuvm_ops *ops)
@@ -681,6 +729,9 @@ drm_gpuvm_init(struct drm_gpuvm *gpuvm, const char *name,
gpuvm->name = name ? name : "unknown";
gpuvm->ops = ops;
gpuvm->drm = drm;
+   gpuvm->r_obj = r_obj;
+
+   drm_gem_object_get(r_obj);
 
drm_gpuvm_check_overflow(gpuvm, start_offset, range);
gpuvm->mm_start = start_offset;
@@ -715,6 +766,8 @@ drm_gpuvm_destroy(struct drm_gpuvm *gpuvm)
 
drm_WARN(gpuvm->drm, !RB_EMPTY_ROOT(>rb.tree.rb_root),
 "GPUVA tree is not empty, potentially leaking memory.\n");
+
+   drm_gem_object_put(gpuvm->r_obj);
 }
 EXPORT_SYMBOL_GPL(drm_gpuvm_destroy);
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_uvmm.c 
b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
index aaf5d28bd587..b4e7d662961a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_uvmm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_uvmm.c
@@ -1809,8 +1809,9 @@ nouveau_uvmm_init(struct nouveau_uvmm *uvmm, struct 
nouveau_cli *cli,
  u64 kernel_managed_addr, u64 kernel_managed_size)
 {
struct drm_device *drm = cli->drm->dev;
-   int ret;
+   struct drm_gem_object *r_obj;
u64 kernel_managed_end = kernel_managed_addr + kernel_managed_size;
+   int ret;
 
mutex_init(>mutex);
dma_resv_init(>resv);
@@ -1834,14 +1835,22 @@ nouveau_uvmm_init(struct nouveau_uvmm *uvmm, struct 
nouveau_cli *cli,
goto out_unlock;
}
 
+   r_obj = drm_gpuvm_resv_object_alloc(drm);
+   if (!r_obj) {
+   ret = -ENOMEM;
+   goto out_unlock;
+   }
+
uvmm->kernel_managed_addr = kernel_managed_addr;

[PATCH drm-misc-next v7 0/7] [RFC] DRM GPUVM features

2023-10-23 Thread Danilo Krummrich

Currently GPUVM offers common infrastructure to track GPU VA allocations
and mappings, generically connect GPU VA mappings to their backing
buffers and perform more complex mapping operations on the GPU VA space.

However, there are more design patterns commonly used by drivers, which
can potentially be generalized in order to make GPUVM represent the
basis of a VM implementation. In this context, this patch series aims at
generalizing the following elements.

1) Provide a common dma-resv for GEM objects not being used outside of
   this GPU-VM.

2) Provide tracking of external GEM objects (GEM objects which are
   shared with other GPU-VMs).

3) Provide functions to efficiently lock all GEM objects dma-resv the
   GPU-VM contains mappings of.

4) Provide tracking of evicted GEM objects the GPU-VM contains mappings
   of, such that validation of evicted GEM objects is accelerated.

5) Provide some convinience functions for common patterns.

The implementation introduces struct drm_gpuvm_bo, which serves as abstraction
combining a struct drm_gpuvm and struct drm_gem_object, similar to what
amdgpu does with struct amdgpu_bo_vm. While this adds a bit of complexity it
improves the efficiency of tracking external and evicted GEM objects.

This patch series is also available at [3].

[1] https://gitlab.freedesktop.org/nouvelles/kernel/-/commits/gpuvm-next

Changes in V2:
==
  - rename 'drm_gpuva_manager' -> 'drm_gpuvm' which generally leads to more
consistent naming
  - properly separate commits (introduce common dma-resv, drm_gpuvm_bo
abstraction, etc.)
  - remove maple tree for tracking external objects, use a list drm_gpuvm_bos
per drm_gpuvm instead
  - rework dma-resv locking helpers (Thomas)
  - add a locking helper for a given range of the VA space (Christian)
  - make the GPUVA manager buildable as module, rather than drm_exec
builtin (Christian)

Changes in V3:
==
  - rename missing function and files (Boris)
  - warn if vm_obj->obj != obj in drm_gpuva_link() (Boris)
  - don't expose drm_gpuvm_bo_destroy() (Boris)
  - unlink VM_BO from GEM in drm_gpuvm_bo_destroy() rather than
drm_gpuva_unlink() and link within drm_gpuvm_bo_obtain() to keep
drm_gpuvm_bo instances unique
  - add internal locking to external and evicted object lists to support drivers
updating the VA space from within the fence signalling critical path (Boris)
  - unlink external objects and evicted objects from the GPUVM's list in
drm_gpuvm_bo_destroy()
  - add more documentation and fix some kernel doc issues

Changes in V4:
==
  - add a drm_gpuvm_resv() helper (Boris)
  - add a drm_gpuvmlocal_list field (Boris)
  - remove drm_gpuvm_bo_get_unless_zero() helper (Boris)
  - fix missing NULL assignment in get_next_vm_bo_from_list() (Boris)
  - keep a drm_gem_object reference on potential vm_bo destroy (alternatively we
could free the vm_bo and drop the vm_bo's drm_gem_object reference through
async work)
  - introduce DRM_GPUVM_RESV_PROTECTED flag to indicate external locking through
the corresponding dma-resv locks to optimize for drivers already holding
them when needed; add the corresponding lock_assert_held() calls (Thomas)
  - make drm_gpuvm_bo_evict() per vm_bo and add a drm_gpuvm_bo_gem_evict()
helper (Thomas)
  - pass a drm_gpuvm_bo in drm_gpuvm_ops::vm_bo_validate() (Thomas)
  - documentation fixes

Changes in V5:
==
  - use a root drm_gem_object provided by the driver as a base for the VM's
common dma-resv (Christian)
  - provide a helper to allocate a "dummy" root GEM object in case a driver
specific root GEM object isn't available
  - add a dedicated patch for nouveau to make use of the GPUVM's shared dma-resv
  - improve documentation (Boris)
  - the following patches are removed from the series, since they already landed
in drm-misc-next
- f72c2db47080 ("drm/gpuvm: rename struct drm_gpuva_manager to struct 
drm_gpuvm")
- fe7acaa727e1 ("drm/gpuvm: allow building as module")
- 78f54469b871 ("drm/nouveau: uvmm: rename 'umgr' to 'base'")

Changes in V6:
==
  - add drm_gpuvm_bo::evicted field protected by the drm_gem_object's dma-resv
lock (Thomas)
- additionally to the original proposal, always use drm_gpuvm_bo::evicted
  regardless of the used locking scheme and always keep it up to date
  - remove unneccesary get->put dance in drm_gpuva_unlink() (Thomas)
  - fix commit message wording (Thomas)
  - fix kernel doc warnings (kernel test robot)

Changes in V7:
==
  - add a patch converting WARN() macros to drm_WARN() variants
  - allow drivers to pass the number of fences to reserve and the drm_exec flags
through struct drm_gpuvm_exec
  - rename 'root' GEM object to 'resv' GEM object
  - fix order of private_usage and extobj_usage in drm_gpuvm_resv_add_fence()
  - always set drm_gpuvm_bo::evicted accordingly
  - explicitly clear drm_gpuvm_bo from evict list after

Re: [PATCH] drm/msm/adreno: Drop WARN_ON from patchid lookup for new GPUs

2023-10-23 Thread Konrad Dybcio





On 10/23/23 21:42, Rob Clark wrote:

On Mon, Oct 23, 2023 at 7:29 AM Konrad Dybcio  wrote:


New GPUs still use the lower 2 bytes of the chip id (in whatever form
it comes) to signify silicon revision. Drop the warning that makes it
sound as if that was unintended.

Fixes: 90b593ce1c9e ("drm/msm/adreno: Switch to chip-id for identifying GPU")
Signed-off-by: Konrad Dybcio 
---
  drivers/gpu/drm/msm/adreno/adreno_gpu.h | 5 -
  1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index 80b3f6312116..9a1ec42155fd 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -203,11 +203,6 @@ struct adreno_platform_config {

  static inline uint8_t adreno_patchid(const struct adreno_gpu *gpu)
  {
-   /* It is probably ok to assume legacy "adreno_rev" format
-* for all a6xx devices, but probably best to limit this
-* to older things.
-*/
-   WARN_ON_ONCE(gpu->info->family >= ADRENO_6XX_GEN1);


Maybe just change it to ADRENO_6XX_GEN4?

That also applies to 700

Konrad

Re: [PATCH] drm/msm/adreno: Drop WARN_ON from patchid lookup for new GPUs

2023-10-23 Thread Rob Clark

On Mon, Oct 23, 2023 at 7:29 AM Konrad Dybcio  wrote:
>
> New GPUs still use the lower 2 bytes of the chip id (in whatever form
> it comes) to signify silicon revision. Drop the warning that makes it
> sound as if that was unintended.
>
> Fixes: 90b593ce1c9e ("drm/msm/adreno: Switch to chip-id for identifying GPU")
> Signed-off-by: Konrad Dybcio 
> ---
>  drivers/gpu/drm/msm/adreno/adreno_gpu.h | 5 -
>  1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> index 80b3f6312116..9a1ec42155fd 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> @@ -203,11 +203,6 @@ struct adreno_platform_config {
>
>  static inline uint8_t adreno_patchid(const struct adreno_gpu *gpu)
>  {
> -   /* It is probably ok to assume legacy "adreno_rev" format
> -* for all a6xx devices, but probably best to limit this
> -* to older things.
> -*/
> -   WARN_ON_ONCE(gpu->info->family >= ADRENO_6XX_GEN1);

Maybe just change it to ADRENO_6XX_GEN4?

BR,
-R

> return gpu->chip_id & 0xff;
>  }
>
>
> ---
> base-commit: e8361b005d7c92997d12f2b85a9e4a525738bd9d
> change-id: 20231023-topic-adreno_warn-42a09bb4bf64
>
> Best regards,
> --
> Konrad Dybcio 
>

[PATCH RESEND 2/2] drm: panel-orientation-quirks: Add quirk for Ayn Loki Max

2023-10-23 Thread Bouke Sybren Haarsma

Add quirk orientation for Ayn Loki Max model.

This has been tested by JELOS team that uses their
own patched kernel for a while now and confirmed by
users in the ChimeraOS discord servers.

Signed-off-by: Bouke Sybren Haarsma 
---
 drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index 7466354c7e5b..5adf9ff07c3e 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -196,6 +196,12 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_MATCH(DMI_BOARD_NAME, "NEXT"),
},
.driver_data = (void *)_rightside_up,
+   }, {/* AYN Loki Max */
+   .matches = {
+   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ayn"),
+   DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Loki Max"),
+   },
+   .driver_data = (void *)_leftside_up,
}, {/* AYN Loki Zero */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ayn"),
-- 
2.41.0

[PATCH RESEND 1/2] drm: panel-orientation-quirks: Add quirk for Ayn Loki Zero

2023-10-23 Thread Bouke Sybren Haarsma

Add quirk orientation for the Ayn Loki Zero.

This also has been tested/used by the JELOS team.

Signed-off-by: Bouke Sybren Haarsma 
---
 drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
b/drivers/gpu/drm/drm_panel_orientation_quirks.c
index d5c15292ae93..7466354c7e5b 100644
--- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
+++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
@@ -196,6 +196,12 @@ static const struct dmi_system_id orientation_data[] = {
  DMI_MATCH(DMI_BOARD_NAME, "NEXT"),
},
.driver_data = (void *)_rightside_up,
+   }, {/* AYN Loki Zero */
+   .matches = {
+   DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ayn"),
+   DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Loki Zero"),
+   },
+   .driver_data = (void *)_leftside_up,
}, {/* Chuwi HiBook (CWI514) */
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, "Hampoo"),
-- 
2.41.0

[PATCH RESEND 0/2] drm: panel-orientation-quirks: Add quirks for AYN loki zero/max

2023-10-23 Thread Bouke Sybren Haarsma

Add orientation quirks for AYN loki devices:
- Ayn Loki Zero
- Ayn Loki Max

The quirks have been tested by the JELOS team and ChimeraOS
who have been patching their own kernel. This has been
confirmed working by users in the ChimeraOS discord
servers.

Since there are additional Ayn Loki devices I have
made separate matches for the devices.

Bouke Sybren Haarsma (2):
  drm: panel-orientation-quirks: Add quirk for Ayn Loki Zero
  drm: panel-orientation-quirks: Add quirk for Ayn Loki Max

 drivers/gpu/drm/drm_panel_orientation_quirks.c | 12 
 1 file changed, 12 insertions(+)

-- 
2.41.0

Re: [RFC PATCH v1 12/12] usb: typec: qcom: define the bridge's path

2023-10-23 Thread Dmitry Baryshkov

On 15 September 2023 15:14:35 EEST, Heikki Krogerus 
 wrote:
>Hi Dmitry,
>
>On Mon, Sep 04, 2023 at 12:41:50AM +0300, Dmitry Baryshkov wrote:
>> In order to notify the userspace about the DRM connector's USB-C port,
>> export the corresponding port's name as the bridge's path field.
>> 
>> Signed-off-by: Dmitry Baryshkov 
>> ---
>>  drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c | 11 +++
>>  drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_drm.c |  4 +++-
>>  drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_drm.h |  6 --
>>  3 files changed, 14 insertions(+), 7 deletions(-)
>> 
>> diff --git a/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c 
>> b/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c
>> index b9d4856101c7..452dc6437861 100644
>> --- a/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c
>> +++ b/drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c
>> @@ -156,6 +156,7 @@ static int qcom_pmic_typec_probe(struct platform_device 
>> *pdev)
>>  struct device_node *np = dev->of_node;
>>  const struct pmic_typec_resources *res;
>>  struct regmap *regmap;
>> +char *tcpm_name;
>>  u32 base[2];
>>  int ret;
>>  
>> @@ -211,10 +212,6 @@ static int qcom_pmic_typec_probe(struct platform_device 
>> *pdev)
>>  mutex_init(>lock);
>>  platform_set_drvdata(pdev, tcpm);
>>  
>> -tcpm->pmic_typec_drm = qcom_pmic_typec_init_drm(dev);
>> -if (IS_ERR(tcpm->pmic_typec_drm))
>> -return PTR_ERR(tcpm->pmic_typec_drm);
>> -
>>  tcpm->tcpc.fwnode = device_get_named_child_node(tcpm->dev, "connector");
>>  if (!tcpm->tcpc.fwnode)
>>  return -EINVAL;
>> @@ -225,6 +222,12 @@ static int qcom_pmic_typec_probe(struct platform_device 
>> *pdev)
>>  goto fwnode_remove;
>>  }
>>  
>> +tcpm_name = tcpm_port_get_name(tcpm->tcpm_port);
>> +tcpm->pmic_typec_drm = qcom_pmic_typec_init_drm(dev, tcpm_name);
>
>So I got some questions and concerns off-list. This was one of the
>concerns. That tcpm_name is now the actual port device name, so I'm
>afraid this is not acceptable.
>
>You can't use device name as a reference, ever. There is no way to
>guarantee that a device with a specific name is what you meant it to
>be by the time it's accessed.

Hmm, could you please be more specific, why? I mean, class devices are not that 
easy to be renamed in sysfs, are they? Or are you concerned about the device 
being destroyed behind userspace's back? At least for MSM this will be a huge 
problem already, with the bridge driver suddenly being removed.

>
>If you need to deal with a device, then you have to get an actual
>reference to it (class_find_device_by_fwnode() should work in this
>case).
>
>Ideally you would get the reference in the place where you actually
>use it (so drm_connector.c or more likely drm_sysfs.c) but that would
>mean a dependency on typec in there, if the component framework or
>something like that (device links?) is not an option. You could of
>course try to confine the dependency somehow. drm_class does not have
>implementation for dev_uevent, so you could take over that as a
>temporary solution.
>
>The only way to avoid the dependency completely would be to pass that
>device reference from here through your drm bridge chain somehow.
>But that's also really fragile. But it could be acceptable as a
>temporary solution perhaps, if it's even possible.
>
>Br,
>

Re: [PATCH v5 2/2] drm/rockchip: vop: Add NV15, NV20 and NV30 support

2023-10-23 Thread Christopher Obbard

Hi Jonas,

On Mon, 2023-10-23 at 17:37 +, Jonas Karlman wrote:
> Add support for displaying 10-bit 4:2:0 and 4:2:2 formats produced by
> the Rockchip Video Decoder on RK322X, RK3288, RK3328 and RK3399.
> Also add support for 10-bit 4:4:4 format while at it.
> 
> V5: Use drm_format_info_min_pitch() for correct bpp
>     Add missing NV21, NV61 and NV42 formats
> V4: Rework RK3328/RK3399 win0/1 data to not affect RK3368
> V2: Added NV30 support
> 
> Signed-off-by: Jonas Karlman 
> Reviewed-by: Sandy Huang 

Reviewed-by: Christopher Obbard 
Tested-by: Christopher Obbard 


Cheers!

Chris

> ---
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 36 ---
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  1 +
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 66 +
>  3 files changed, 86 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 14320bc73e5b..b3d0b6ae9294 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -272,6 +272,18 @@ static bool has_uv_swapped(uint32_t format)
>   }
>  }
>  
> +static bool is_fmt_10(uint32_t format)
> +{
> + switch (format) {
> + case DRM_FORMAT_NV15:
> + case DRM_FORMAT_NV20:
> + case DRM_FORMAT_NV30:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
>  static enum vop_data_format vop_convert_format(uint32_t format)
>  {
>   switch (format) {
> @@ -287,12 +299,15 @@ static enum vop_data_format
> vop_convert_format(uint32_t format)
>   case DRM_FORMAT_BGR565:
>   return VOP_FMT_RGB565;
>   case DRM_FORMAT_NV12:
> + case DRM_FORMAT_NV15:
>   case DRM_FORMAT_NV21:
>   return VOP_FMT_YUV420SP;
>   case DRM_FORMAT_NV16:
> + case DRM_FORMAT_NV20:
>   case DRM_FORMAT_NV61:
>   return VOP_FMT_YUV422SP;
>   case DRM_FORMAT_NV24:
> + case DRM_FORMAT_NV30:
>   case DRM_FORMAT_NV42:
>   return VOP_FMT_YUV444SP;
>   default:
> @@ -944,7 +959,12 @@ static void vop_plane_atomic_update(struct drm_plane
> *plane,
>   dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
>   dsp_st = dsp_sty << 16 | (dsp_stx & 0x);
>  
> - offset = (src->x1 >> 16) * fb->format->cpp[0];
> + if (fb->format->char_per_block[0])
> + offset = drm_format_info_min_pitch(fb->format, 0,
> +    src->x1 >> 16);
> + else
> + offset = (src->x1 >> 16) * fb->format->cpp[0];
> +
>   offset += (src->y1 >> 16) * fb->pitches[0];
>   dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
>  
> @@ -970,6 +990,7 @@ static void vop_plane_atomic_update(struct drm_plane
> *plane,
>   }
>  
>   VOP_WIN_SET(vop, win, format, format);
> + VOP_WIN_SET(vop, win, fmt_10, is_fmt_10(fb->format->format));
>   VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
>   VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
>   VOP_WIN_YUV2YUV_SET(vop, win_yuv2yuv, y2r_en, is_yuv);
> @@ -979,15 +1000,16 @@ static void vop_plane_atomic_update(struct drm_plane
> *plane,
>       (new_state->rotation & DRM_MODE_REFLECT_X) ? 1 : 0);
>  
>   if (is_yuv) {
> - int hsub = fb->format->hsub;
> - int vsub = fb->format->vsub;
> - int bpp = fb->format->cpp[1];
> -
>   uv_obj = fb->obj[1];
>   rk_uv_obj = to_rockchip_obj(uv_obj);
>  
> - offset = (src->x1 >> 16) * bpp / hsub;
> - offset += (src->y1 >> 16) * fb->pitches[1] / vsub;
> + if (fb->format->char_per_block[1])
> + offset = drm_format_info_min_pitch(fb->format, 1,
> +    src->x1 >> 16);
> + else
> + offset = (src->x1 >> 16) * fb->format->cpp[1];
> + offset /= fb->format->hsub;
> + offset += (src->y1 >> 16) * fb->pitches[1] / fb->format-
> >vsub;
>  
>   dma_addr = rk_uv_obj->dma_addr + offset + fb->offsets[1];
>   VOP_WIN_SET(vop, win, uv_vir, DIV_ROUND_UP(fb->pitches[1],
> 4));
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> index 5f56e0597df8..4b2daefeb8c1 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
> @@ -186,6 +186,7 @@ struct vop_win_phy {
>   struct vop_reg enable;
>   struct vop_reg gate;
>   struct vop_reg format;
> + struct vop_reg fmt_10;
>   struct vop_reg rb_swap;
>   struct vop_reg uv_swap;
>   struct vop_reg act_info;
> diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
> index 7b2805006776..f8cef0cb7bff 100644
> ---

Re: [PATCH v5 1/2] drm/fourcc: Add NV20 and NV30 YUV formats

2023-10-23 Thread Christopher Obbard

Hi Jonas,

On Mon, 2023-10-23 at 17:37 +, Jonas Karlman wrote:
> DRM_FORMAT_NV20 and DRM_FORMAT_NV30 formats is the 2x1 and non-subsampled
> variant of NV15, a 10-bit 2-plane YUV format that has no padding between
> components. Instead, luminance and chrominance samples are grouped into 4s
> so that each group is packed into an integer number of bytes:
> 
>  = UVUV = 4 * 10 bits = 40 bits = 5 bytes
> 
> The '20' and '30' suffix refers to the optimum effective bits per pixel
> which is achieved when the total number of luminance samples is a multiple
> of 4.
> 
> V2: Added NV30 format
> 
> Signed-off-by: Jonas Karlman 
> Reviewed-by: Sandy Huang 

Reviewed-by: Christopher Obbard 
Tested-by: Christopher Obbard 


Cheers!

Chris

> ---
>  drivers/gpu/drm/drm_fourcc.c  | 8 
>  include/uapi/drm/drm_fourcc.h | 2 ++
>  2 files changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 0f17dfa8702b..193cf8ed7912 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -299,6 +299,14 @@ const struct drm_format_info *__drm_format_info(u32
> format)
>     .num_planes = 2, .char_per_block = { 5, 5, 0 },
>     .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub =
> 2,
>     .vsub = 2, .is_yuv = true },
> + { .format = DRM_FORMAT_NV20,.depth = 0,
> +   .num_planes = 2, .char_per_block = { 5, 5, 0 },
> +   .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub =
> 2,
> +   .vsub = 1, .is_yuv = true },
> + { .format = DRM_FORMAT_NV30,.depth = 0,
> +   .num_planes = 2, .char_per_block = { 5, 5, 0 },
> +   .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub =
> 1,
> +   .vsub = 1, .is_yuv = true },
>   { .format = DRM_FORMAT_Q410,.depth = 0,
>     .num_planes = 3, .char_per_block = { 2, 2, 2 },
>     .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub =
> 1,
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 8db7fd3f743e..3151f1fc7ebb 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -323,6 +323,8 @@ extern "C" {
>   * index 1 = Cr:Cb plane, [39:0] Cr1:Cb1:Cr0:Cb0 little endian
>   */
>  #define DRM_FORMAT_NV15  fourcc_code('N', 'V', '1', '5') /*
> 2x2 subsampled Cr:Cb plane */
> +#define DRM_FORMAT_NV20  fourcc_code('N', 'V', '2', '0') /*
> 2x1 subsampled Cr:Cb plane */
> +#define DRM_FORMAT_NV30  fourcc_code('N', 'V', '3', '0') /*
> non-subsampled Cr:Cb plane */
>  
>  /*
>   * 2 plane YCbCr MSB aligned

Re: [PATCH v5 0/2] drm/rockchip: vop: Add NV15, NV20 and NV30 support

2023-10-23 Thread Christopher Obbard

Hi Jonas,

On Mon, 2023-10-23 at 17:37 +, Jonas Karlman wrote:
> This series add support for displaying 10-bit 4:2:0 and 4:2:2 formats
> produced
> by the Rockchip Video Decoder on RK322X, RK3288, RK3328, RK3368 and RK3399.
> Also include 10-bit 4:4:4 support since VOP can support that also.
> 
> First patch adds new fourcc 10-bit YUV formats with 4:2:2/4:4:4 sub-
> sampling.
> Second patch adds support for displaying the new fourcc formats.
> 
> These patches have been in use by LibreELEC and other distros for the
> past 3+ years, hoping they can be merged this time around.
> 
> A rough libdrm/modetest patch [2] have been used to validate use of
> NV15, NV20 and NV30 formats on RK3288, RK3328 and RK3399 boards.
> 
>   modetest -s @:-@
> 
> Tinker Board R2.0 (rk3288w):
>   modetest -s 50:1920x1080-60@NV15
> 
> Rock Pi 4 (rk3399):
>   modetest -s 52@44:1920x1080-60@NV15
> 
> Rock64 (rk3328):
>   modetest -s 42:1920x1080-60@NV15
> 
> Changes in v5:
> - Use drm_format_info_min_pitch() for correct bpp
> - Add missing NV21, NV61 and NV42 formats
> 
> Changes in v4:
> - Rework RK3328/RK3399 win0/1 data to not affect RK3368
> 
> Changes in v3:
> - No changes, rebased on next-20230616
> - R-B tags was collected
> 
> Changes in v2:
> - Add NV30 format
> - R-B tags was not collected due to NV30 changes
> 
> This series is also available at [1] and libdrm/modetest patch at [2].
> 
> [1] https://github.com/Kwiboo/linux-rockchip/commits/v6.6-rc7-vop-nv15
> [2] https://github.com/Kwiboo/libdrm/commits/nv15

Could you open a draft merge request for libdrm upstream at
https://gitlab.freedesktop.org/mesa/drm pointing to this series? If there are
subsequent revisions of this series, it'd be great to link that merge request
in the cover letter.


Cheers!

Chris

> 
> Jonas Karlman (2):
>   drm/fourcc: Add NV20 and NV30 YUV formats
>   drm/rockchip: vop: Add NV15, NV20 and NV30 support
> 
>  drivers/gpu/drm/drm_fourcc.c    |  8 +++
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 36 ---
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  1 +
>  drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 66 +
>  include/uapi/drm/drm_fourcc.h   |  2 +
>  5 files changed, 96 insertions(+), 17 deletions(-)
>

[PATCH v5 1/2] drm/fourcc: Add NV20 and NV30 YUV formats

2023-10-23 Thread Jonas Karlman

DRM_FORMAT_NV20 and DRM_FORMAT_NV30 formats is the 2x1 and non-subsampled
variant of NV15, a 10-bit 2-plane YUV format that has no padding between
components. Instead, luminance and chrominance samples are grouped into 4s
so that each group is packed into an integer number of bytes:

 = UVUV = 4 * 10 bits = 40 bits = 5 bytes

The '20' and '30' suffix refers to the optimum effective bits per pixel
which is achieved when the total number of luminance samples is a multiple
of 4.

V2: Added NV30 format

Signed-off-by: Jonas Karlman 
Reviewed-by: Sandy Huang 
---
 drivers/gpu/drm/drm_fourcc.c  | 8 
 include/uapi/drm/drm_fourcc.h | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 0f17dfa8702b..193cf8ed7912 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -299,6 +299,14 @@ const struct drm_format_info *__drm_format_info(u32 format)
  .num_planes = 2, .char_per_block = { 5, 5, 0 },
  .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
  .vsub = 2, .is_yuv = true },
+   { .format = DRM_FORMAT_NV20,.depth = 0,
+ .num_planes = 2, .char_per_block = { 5, 5, 0 },
+ .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 2,
+ .vsub = 1, .is_yuv = true },
+   { .format = DRM_FORMAT_NV30,.depth = 0,
+ .num_planes = 2, .char_per_block = { 5, 5, 0 },
+ .block_w = { 4, 2, 0 }, .block_h = { 1, 1, 0 }, .hsub = 1,
+ .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Q410,.depth = 0,
  .num_planes = 3, .char_per_block = { 2, 2, 2 },
  .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 1,
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8db7fd3f743e..3151f1fc7ebb 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -323,6 +323,8 @@ extern "C" {
  * index 1 = Cr:Cb plane, [39:0] Cr1:Cb1:Cr0:Cb0 little endian
  */
 #define DRM_FORMAT_NV15fourcc_code('N', 'V', '1', '5') /* 2x2 
subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV20fourcc_code('N', 'V', '2', '0') /* 2x1 
subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV30fourcc_code('N', 'V', '3', '0') /* 
non-subsampled Cr:Cb plane */
 
 /*
  * 2 plane YCbCr MSB aligned
-- 
2.42.0

[PATCH v5 0/2] drm/rockchip: vop: Add NV15, NV20 and NV30 support

2023-10-23 Thread Jonas Karlman

This series add support for displaying 10-bit 4:2:0 and 4:2:2 formats produced
by the Rockchip Video Decoder on RK322X, RK3288, RK3328, RK3368 and RK3399.
Also include 10-bit 4:4:4 support since VOP can support that also.

First patch adds new fourcc 10-bit YUV formats with 4:2:2/4:4:4 sub-sampling.
Second patch adds support for displaying the new fourcc formats.

These patches have been in use by LibreELEC and other distros for the
past 3+ years, hoping they can be merged this time around.

A rough libdrm/modetest patch [2] have been used to validate use of
NV15, NV20 and NV30 formats on RK3288, RK3328 and RK3399 boards.

  modetest -s @:-@

Tinker Board R2.0 (rk3288w):
  modetest -s 50:1920x1080-60@NV15

Rock Pi 4 (rk3399):
  modetest -s 52@44:1920x1080-60@NV15

Rock64 (rk3328):
  modetest -s 42:1920x1080-60@NV15

Changes in v5:
- Use drm_format_info_min_pitch() for correct bpp
- Add missing NV21, NV61 and NV42 formats

Changes in v4:
- Rework RK3328/RK3399 win0/1 data to not affect RK3368

Changes in v3:
- No changes, rebased on next-20230616
- R-B tags was collected

Changes in v2:
- Add NV30 format
- R-B tags was not collected due to NV30 changes

This series is also available at [1] and libdrm/modetest patch at [2].

[1] https://github.com/Kwiboo/linux-rockchip/commits/v6.6-rc7-vop-nv15
[2] https://github.com/Kwiboo/libdrm/commits/nv15

Jonas Karlman (2):
  drm/fourcc: Add NV20 and NV30 YUV formats
  drm/rockchip: vop: Add NV15, NV20 and NV30 support

 drivers/gpu/drm/drm_fourcc.c|  8 +++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 36 ---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  1 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 66 +
 include/uapi/drm/drm_fourcc.h   |  2 +
 5 files changed, 96 insertions(+), 17 deletions(-)

-- 
2.42.0

[PATCH v5 2/2] drm/rockchip: vop: Add NV15, NV20 and NV30 support

2023-10-23 Thread Jonas Karlman

Add support for displaying 10-bit 4:2:0 and 4:2:2 formats produced by
the Rockchip Video Decoder on RK322X, RK3288, RK3328 and RK3399.
Also add support for 10-bit 4:4:4 format while at it.

V5: Use drm_format_info_min_pitch() for correct bpp
Add missing NV21, NV61 and NV42 formats
V4: Rework RK3328/RK3399 win0/1 data to not affect RK3368
V2: Added NV30 support

Signed-off-by: Jonas Karlman 
Reviewed-by: Sandy Huang 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 36 ---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |  1 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 66 +
 3 files changed, 86 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 14320bc73e5b..b3d0b6ae9294 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -272,6 +272,18 @@ static bool has_uv_swapped(uint32_t format)
}
 }
 
+static bool is_fmt_10(uint32_t format)
+{
+   switch (format) {
+   case DRM_FORMAT_NV15:
+   case DRM_FORMAT_NV20:
+   case DRM_FORMAT_NV30:
+   return true;
+   default:
+   return false;
+   }
+}
+
 static enum vop_data_format vop_convert_format(uint32_t format)
 {
switch (format) {
@@ -287,12 +299,15 @@ static enum vop_data_format vop_convert_format(uint32_t 
format)
case DRM_FORMAT_BGR565:
return VOP_FMT_RGB565;
case DRM_FORMAT_NV12:
+   case DRM_FORMAT_NV15:
case DRM_FORMAT_NV21:
return VOP_FMT_YUV420SP;
case DRM_FORMAT_NV16:
+   case DRM_FORMAT_NV20:
case DRM_FORMAT_NV61:
return VOP_FMT_YUV422SP;
case DRM_FORMAT_NV24:
+   case DRM_FORMAT_NV30:
case DRM_FORMAT_NV42:
return VOP_FMT_YUV444SP;
default:
@@ -944,7 +959,12 @@ static void vop_plane_atomic_update(struct drm_plane 
*plane,
dsp_sty = dest->y1 + crtc->mode.vtotal - crtc->mode.vsync_start;
dsp_st = dsp_sty << 16 | (dsp_stx & 0x);
 
-   offset = (src->x1 >> 16) * fb->format->cpp[0];
+   if (fb->format->char_per_block[0])
+   offset = drm_format_info_min_pitch(fb->format, 0,
+  src->x1 >> 16);
+   else
+   offset = (src->x1 >> 16) * fb->format->cpp[0];
+
offset += (src->y1 >> 16) * fb->pitches[0];
dma_addr = rk_obj->dma_addr + offset + fb->offsets[0];
 
@@ -970,6 +990,7 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
}
 
VOP_WIN_SET(vop, win, format, format);
+   VOP_WIN_SET(vop, win, fmt_10, is_fmt_10(fb->format->format));
VOP_WIN_SET(vop, win, yrgb_vir, DIV_ROUND_UP(fb->pitches[0], 4));
VOP_WIN_SET(vop, win, yrgb_mst, dma_addr);
VOP_WIN_YUV2YUV_SET(vop, win_yuv2yuv, y2r_en, is_yuv);
@@ -979,15 +1000,16 @@ static void vop_plane_atomic_update(struct drm_plane 
*plane,
(new_state->rotation & DRM_MODE_REFLECT_X) ? 1 : 0);
 
if (is_yuv) {
-   int hsub = fb->format->hsub;
-   int vsub = fb->format->vsub;
-   int bpp = fb->format->cpp[1];
-
uv_obj = fb->obj[1];
rk_uv_obj = to_rockchip_obj(uv_obj);
 
-   offset = (src->x1 >> 16) * bpp / hsub;
-   offset += (src->y1 >> 16) * fb->pitches[1] / vsub;
+   if (fb->format->char_per_block[1])
+   offset = drm_format_info_min_pitch(fb->format, 1,
+  src->x1 >> 16);
+   else
+   offset = (src->x1 >> 16) * fb->format->cpp[1];
+   offset /= fb->format->hsub;
+   offset += (src->y1 >> 16) * fb->pitches[1] / fb->format->vsub;
 
dma_addr = rk_uv_obj->dma_addr + offset + fb->offsets[1];
VOP_WIN_SET(vop, win, uv_vir, DIV_ROUND_UP(fb->pitches[1], 4));
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
index 5f56e0597df8..4b2daefeb8c1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
@@ -186,6 +186,7 @@ struct vop_win_phy {
struct vop_reg enable;
struct vop_reg gate;
struct vop_reg format;
+   struct vop_reg fmt_10;
struct vop_reg rb_swap;
struct vop_reg uv_swap;
struct vop_reg act_info;
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c 
b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
index 7b2805006776..f8cef0cb7bff 100644
--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
@@ -53,6 +53,26 @@ static const uint32_t formats_win_full[] = {
DRM_FORMAT_NV42,
 };
 
+static const uint32_t formats_win_full_10[] = {
+   DRM_FORMAT_XRGB,
+   DRM_FORMAT_ARGB,
+

Re: [PATCH 11/18] dt-bindings: pwm: add power-domains property

2023-10-23 Thread Conor Dooley

Yo,

On Mon, Oct 23, 2023 at 04:40:11PM +0200, Alexandre Mergnat wrote:
> According to the Mediatek datasheet, the display PWM block has a power
> domain.

Datasheet for which soc? The mt8173? Is it valid for all devices in this
binding?

Cheers,
Conor.

> 
> Signed-off-by: Alexandre Mergnat 
> ---
>  Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml 
> b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml
> index 153e146df7d4..efe0cacf55b7 100644
> --- a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml
> +++ b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml
> @@ -53,6 +53,12 @@ properties:
>- const: main
>- const: mm
>  
> +  power-domains:
> +maxItems: 1
> +description: A phandle and PM domain specifier as defined by bindings of
> +  the power controller specified by phandle. See
> +  Documentation/devicetree/bindings/power/power-domain.yaml for details.
> +
>  required:
>- compatible
>- reg
> @@ -67,6 +73,7 @@ examples:
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  pwm0: pwm@1401e000 {
>  compatible = "mediatek,mt8173-disp-pwm";
> @@ -75,4 +82,5 @@ examples:
>  clocks = < CLK_MM_DISP_PWM026M>,
>   < CLK_MM_DISP_PWM0MM>;
>  clock-names = "main", "mm";
> +power-domains = < MT8173_POWER_DOMAIN_MM>;
>  };
> 
> -- 
> 2.25.1
> 


signature.asc
Description: PGP signature

Re: [PATCH 12/18] dt-bindings: pwm: add binding for mt8365 SoC

2023-10-23 Thread Conor Dooley

On Mon, Oct 23, 2023 at 04:40:12PM +0200, Alexandre Mergnat wrote:
> Display PWM for MT8365 is compatible with MT8183. Then, add MT8365 binding
> along with MT8183 SoC.


Additionally here, for the subject,
"dt-bindings: pwm: mediatek,pwm-disp: add compatible for mt8365 SoC"

Cheers
Conor.

> 
> Signed-off-by: Alexandre Mergnat 
> ---
>  Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml 
> b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml
> index efe0cacf55b7..e4069bcbf8d5 100644
> --- a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml
> +++ b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml
> @@ -32,6 +32,7 @@ properties:
>- mediatek,mt8188-disp-pwm
>- mediatek,mt8192-disp-pwm
>- mediatek,mt8195-disp-pwm
> +  - mediatek,mt8365-disp-pwm
>- const: mediatek,mt8183-disp-pwm
>  
>reg:
> 
> -- 
> 2.25.1
> 


signature.asc
Description: PGP signature

Re: [PATCH 02/18] dt-bindings: display: mediatek: ccorr: add binding for MT8365 SoC

2023-10-23 Thread Conor Dooley

On Mon, Oct 23, 2023 at 06:31:45PM +0100, Conor Dooley wrote:
> On Mon, Oct 23, 2023 at 04:40:02PM +0200, Alexandre Mergnat wrote:
> > Display Color Correction for MT8365 is compatible with another SoC.
> > Then, add MT8365 binding along with MT8183 SoC.
> 
> This commit message's first line is too vague & the second doesn't make
> sense. I suspect something as succinct as "Document the display colour
> correction on mt, which is compatible with that of the mt"
> does what you are looking for.
> 
> I suspect this is going to apply to the rest of the series...

It does, as does the comment about s/binding/compatible/ I left on patch
1.


> 
> Cheers,
> Conor.
> 
> 
> > 
> > Signed-off-by: Alexandre Mergnat 
> > ---
> >  Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml | 3 
> > +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml 
> > b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> > index 8c2a737237f2..9f8366763831 100644
> > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> > @@ -24,6 +24,9 @@ properties:
> >- enum:
> >- mediatek,mt8183-disp-ccorr
> >- mediatek,mt8192-disp-ccorr
> > +  - items:
> > +  - const: mediatek,mt8365-disp-ccorr
> > +  - const: mediatek,mt8183-disp-ccorr
> >- items:
> >- enum:
> >- mediatek,mt8186-disp-ccorr
> > 
> > -- 
> > 2.25.1
> > 




signature.asc
Description: PGP signature

Re: [PATCH 02/18] dt-bindings: display: mediatek: ccorr: add binding for MT8365 SoC

2023-10-23 Thread Conor Dooley

On Mon, Oct 23, 2023 at 04:40:02PM +0200, Alexandre Mergnat wrote:
> Display Color Correction for MT8365 is compatible with another SoC.
> Then, add MT8365 binding along with MT8183 SoC.

This commit message's first line is too vague & the second doesn't make
sense. I suspect something as succinct as "Document the display colour
correction on mt, which is compatible with that of the mt"
does what you are looking for.

I suspect this is going to apply to the rest of the series...

Cheers,
Conor.


> 
> Signed-off-by: Alexandre Mergnat 
> ---
>  Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml | 3 
> +++
>  1 file changed, 3 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml 
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> index 8c2a737237f2..9f8366763831 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
> @@ -24,6 +24,9 @@ properties:
>- enum:
>- mediatek,mt8183-disp-ccorr
>- mediatek,mt8192-disp-ccorr
> +  - items:
> +  - const: mediatek,mt8365-disp-ccorr
> +  - const: mediatek,mt8183-disp-ccorr
>- items:
>- enum:
>- mediatek,mt8186-disp-ccorr
> 
> -- 
> 2.25.1
> 


signature.asc
Description: PGP signature

RE: [RFC PATCH v2 1/1] drm/virtio: new fence for every plane update

2023-10-23 Thread Kim, Dongwon

> -Original Message-
> From: Dmitry Osipenko 
> Sent: Monday, October 23, 2023 5:24 AM
> To: Kim, Dongwon ; dri-devel@lists.freedesktop.org
> Cc: kra...@redhat.com; Kasireddy, Vivek 
> Subject: Re: [RFC PATCH v2 1/1] drm/virtio: new fence for every plane update
> 
> On 10/3/23 04:00, Dongwon Kim wrote:
> > Having a fence linked to a virtio_gpu_framebuffer in the plane update
> > sequence would cause conflict when several planes referencing the same
> > framebuffer (e.g. Xorg screen covering multi-displays configured for
> > an extended mode) and those planes are updated concurrently. So it is
> > needed to allocate a fence for every plane state instead of the framebuffer.
> >
> > The plane state for virtio-gpu, "struct virtio_gpu_plane_state" is
> > added for this. This structure represents drm_plane_state and it
> > contains the reference to virtio_gpu_fence, which was previously in "struct
> virtio_gpu_framebuffer".
> >
> > "virtio_gpu_plane_duplicate_state" is added as well to create a
> > virtio_gpu_plane_state on top of duplicated drm plane state.
> >
> > Several drm helpers were slightly modified accordingly to use the
> > fence in new plane state structure. virtio_gpu_plane_cleanup_fb was
> > completely removed as dma_fence_put shouldn't be called here as it can
> > mess up with the ref count of the fence. The fence should be put after
> > the fence is signaled in virtio_gpu_resource_flush then released in
> > virtio_gpu_array_add_fence while the next virtio message is being queued.
> >
> > Also, the condition for adding fence, (plane->state->fb !=
> > new_state->fb) was removed since we now allocate a new fence for the
> > new plane state even if both old and new planes are pointing to the same
> framebuffer.
> >
> > v2: removed virtio_gpu_plane_duplicate_state as the existing helper,
> > drm_atomic_helper_plane_destroy_state does the same.
> >
> > Cc: Dmitry Osipenko 
> > Cc: Gerd Hoffmann 
> > Cc: Vivek Kasireddy 
> > Signed-off-by: Dongwon Kim 
> > ---
> >  drivers/gpu/drm/virtio/virtgpu_drv.h   |  7 +++
> >  drivers/gpu/drm/virtio/virtgpu_plane.c | 66
> > +-
> >  2 files changed, 51 insertions(+), 22 deletions(-)
> 
> Please write a guide how to test it. Are you using spice for the multi-display
> viewer?

[DW] Yeah, let me come up with a simple test case. So we use virtio-gpu as KMS 
device. It is used to share the guest frame with QEMU.
SPICE is one of client solutions we use but we primarily use QEMU GTK-UI w/ 
multi displays (QEMU with this params '-device 
virtio-vga,max_outputs=2,blob=true').
Thanks!

> 
> --
> Best regards,
> Dmitry

Re: [PATCH] drm: docs: Remove item from TODO list

2023-10-23 Thread Doug Anderson

Hi,

On Mon, Oct 23, 2023 at 9:31 AM Yuran Pereira  wrote:
>
> Since "Clean up checks for already prepared/enabled in panels" has
> already been done and merged [1], I think there is no longer a need
> for this item to be in the gpu TODO.
>
> [1] https://patchwork.freedesktop.org/patch/551421/
>
> Signed-off-by: Yuran Pereira 
> ---
>  Documentation/gpu/todo.rst | 25 -
>  1 file changed, 25 deletions(-)

It's not actually all done. It's in a bit of a limbo state right now,
unfortunately. I landed all of the "simple" cases where panels were
needlessly tracking prepare/enable, but the less simple cases are
still outstanding.

Specifically the issue is that many panels have code to properly power
cycle themselves off at shutdown time and in order to do that they
need to keep track of the prepare/enable state. After a big, long
discussion [1] it was decided that we could get rid of all the panel
code handling shutdown if only all relevant DRM KMS drivers would
properly call drm_atomic_helper_shutdown().

I made an attempt to get DRM KMS drivers to call
drm_atomic_helper_shutdown() [2] [3] [4]. I was able to land the
patches that went through drm-misc, but currently many of the
non-drm-misc ones are blocked waiting for attention.

...so things that could be done to help out:

a) Could review patches that haven't landed in [4]. Maybe adding a
Reviewed-by tag would help wake up maintainers?

b) Could see if you can identify panels that are exclusively used w/
DRM drivers that have already been converted and then we could post
patches for just those panels. I have no idea how easy this task would
be. Is it enough to look at upstream dts files by "compatible" string?

I've gotten side-tracked at the moment so I haven't been driving
progress on this very quickly. I still plan to poke some of the
drm_atomic_helper_shutdown() patches eventually...

[1] 
https://lore.kernel.org/r/20230804140605.RFC.4.I930069a32baab6faf46d6b234f89613b5cec0f14@changeid
[2] https://lore.kernel.org/r/20230901234015.566018-1-diand...@chromium.org
[3] https://lore.kernel.org/r/20230901234202.566951-1-diand...@chromium.org
[4] https://lore.kernel.org/r/20230921192749.1542462-1-diand...@chromium.org

[Bug 201957] amdgpu: ring gfx timeout

2023-10-23 Thread bugzilla-daemon

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

Mario Limonciello (AMD) (mario.limoncie...@amd.com) changed:

   What|Removed |Added

 CC||mario.limoncie...@amd.com

--- Comment #99 from Mario Limonciello (AMD) (mario.limoncie...@amd.com) ---
#98

The amdgpu.mcbp=0  will only help GFX9 products.  For GFX10 this is a different
problem, please open at AMD Gitlab.

-- 
You may reply to this email to add a comment.

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

Re: [PATCH 01/18] dt-bindings: display: mediatek: aal: add binding for MT8365 SoC

2023-10-23 Thread Conor Dooley

On Mon, Oct 23, 2023 at 04:40:01PM +0200, Alexandre Mergnat wrote:
> Display Adaptive Ambient Light for MT8365 is compatible with another SoC.

> Then, add MT8365 binding along with MT8183 SoC.

s/binding/compatible/, here and in the subject.

Cheers,
Conor.

> 
> Signed-off-by: Alexandre Mergnat 
> ---
>  Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml 
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> index 7fd42c8fdc32..840b48a878ca 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
> @@ -35,6 +35,7 @@ properties:
>- mediatek,mt8188-disp-aal
>- mediatek,mt8192-disp-aal
>- mediatek,mt8195-disp-aal
> +  - mediatek,mt8365-disp-aal
>- const: mediatek,mt8183-disp-aal
>  
>reg:
> 
> -- 
> 2.25.1
> 


signature.asc
Description: PGP signature

[RFC PATCH] drm/test: add a test suite for GEM objects backed by shmem

2023-10-23 Thread Marco Pagani

This patch introduces an initial KUnit test suite for GEM objects
backed by shmem buffers.

Signed-off-by: Marco Pagani 
---
 drivers/gpu/drm/Kconfig|   1 +
 drivers/gpu/drm/tests/Makefile |   3 +-
 drivers/gpu/drm/tests/drm_gem_shmem_test.c | 303 +
 3 files changed, 306 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/tests/drm_gem_shmem_test.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 3eee8636f847..f0a77e3e04d7 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -84,6 +84,7 @@ config DRM_KUNIT_TEST
select DRM_EXPORT_FOR_TESTS if m
select DRM_KUNIT_TEST_HELPERS
select DRM_EXEC
+   select DRM_GEM_SHMEM_HELPER
default KUNIT_ALL_TESTS
help
  This builds unit tests for DRM. This option is not useful for
diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile
index ba7baa622675..b8227aab369e 100644
--- a/drivers/gpu/drm/tests/Makefile
+++ b/drivers/gpu/drm/tests/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_DRM_KUNIT_TEST) += \
drm_plane_helper_test.o \
drm_probe_helper_test.o \
drm_rect_test.o \
-   drm_exec_test.o
+   drm_exec_test.o \
+   drm_gem_shmem_test.o
 
 CFLAGS_drm_mm_test.o := $(DISABLE_STRUCTLEAK_PLUGIN)
diff --git a/drivers/gpu/drm/tests/drm_gem_shmem_test.c 
b/drivers/gpu/drm/tests/drm_gem_shmem_test.c
new file mode 100644
index ..0bf6727f08d2
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_gem_shmem_test.c
@@ -0,0 +1,303 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit test suite for GEM objects backed by shmem buffers
+ *
+ * Copyright (C) 2023 Red Hat, Inc.
+ *
+ * Author: Marco Pagani 
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TEST_SIZE  SZ_1M
+#define TEST_BYTE  0xae
+
+struct fake_dev {
+   struct drm_device drm_dev;
+   struct device *dev;
+};
+
+/* Test creating a shmem GEM object */
+static void drm_gem_shmem_test_obj_create(struct kunit *test)
+{
+   struct fake_dev *fdev = test->priv;
+   struct drm_gem_shmem_object *shmem;
+
+   shmem = drm_gem_shmem_create(>drm_dev, TEST_SIZE);
+   KUNIT_ASSERT_NOT_ERR_OR_NULL(test, shmem);
+   KUNIT_ASSERT_EQ(test, shmem->base.size, TEST_SIZE);
+   KUNIT_ASSERT_NOT_NULL(test, shmem->base.filp);
+   KUNIT_ASSERT_NOT_NULL(test, shmem->base.funcs);
+
+   drm_gem_shmem_free(shmem);
+}
+
+/* Test creating a private shmem GEM object from a scatter/gather table */
+static void drm_gem_shmem_test_obj_create_private(struct kunit *test)
+{
+   struct fake_dev *fdev = test->priv;
+   struct drm_gem_shmem_object *shmem;
+   struct drm_gem_object *gem_obj;
+   struct dma_buf buf_mock;
+   struct dma_buf_attachment attach_mock;
+   struct sg_table *sgt;
+   char *buf;
+   int ret;
+
+   /* Create a mock scatter/gather table */
+   buf = kunit_kzalloc(test, TEST_SIZE, GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, buf);
+
+   sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, sgt);
+
+   ret = sg_alloc_table(sgt, 1, GFP_KERNEL);
+   KUNIT_ASSERT_EQ(test, ret, 0);
+   sg_init_one(sgt->sgl, buf, TEST_SIZE);
+
+   /* Init a mock DMA-BUF */
+   buf_mock.size = TEST_SIZE;
+   attach_mock.dmabuf = _mock;
+
+   gem_obj = drm_gem_shmem_prime_import_sg_table(>drm_dev, 
_mock, sgt);
+   KUNIT_ASSERT_NOT_ERR_OR_NULL(test, gem_obj);
+   KUNIT_ASSERT_EQ(test, gem_obj->size, TEST_SIZE);
+   KUNIT_ASSERT_NULL(test, gem_obj->filp);
+   KUNIT_ASSERT_NOT_NULL(test, gem_obj->funcs);
+
+   shmem = to_drm_gem_shmem_obj(gem_obj);
+   KUNIT_ASSERT_PTR_EQ(test, shmem->sgt, sgt);
+
+   /* The scatter/gather table is freed by drm_gem_shmem_free */
+   drm_gem_shmem_free(shmem);
+}
+
+/* Test pinning backing pages */
+static void drm_gem_shmem_test_pin_pages(struct kunit *test)
+{
+   struct fake_dev *fdev = test->priv;
+   struct drm_gem_shmem_object *shmem;
+   int i, ret;
+
+   shmem = drm_gem_shmem_create(>drm_dev, TEST_SIZE);
+   KUNIT_ASSERT_NOT_ERR_OR_NULL(test, shmem);
+   KUNIT_ASSERT_NULL(test, shmem->pages);
+   KUNIT_ASSERT_EQ(test, shmem->pages_use_count, 0);
+
+   ret = drm_gem_shmem_pin(shmem);
+   KUNIT_ASSERT_EQ(test, ret, 0);
+   KUNIT_ASSERT_NOT_NULL(test, shmem->pages);
+   KUNIT_ASSERT_EQ(test, shmem->pages_use_count, 1);
+
+   for (i = 0; i < (shmem->base.size >> PAGE_SHIFT); i++)
+   KUNIT_ASSERT_NOT_NULL(test, shmem->pages[i]);
+
+   drm_gem_shmem_unpin(shmem);
+   KUNIT_ASSERT_NULL(test, shmem->pages);
+   KUNIT_ASSERT_EQ(test, shmem->pages_use_count, 0);
+
+   drm_gem_shmem_free(shmem);
+}
+
+/* Test creating a virtual mapping */
+static void drm_gem_shmem_test_vmap(struct kunit *test)
+{
+

[PATCH] drm: docs: Remove item from TODO list

2023-10-23 Thread Yuran Pereira

Since "Clean up checks for already prepared/enabled in panels" has
already been done and merged [1], I think there is no longer a need
for this item to be in the gpu TODO.

[1] https://patchwork.freedesktop.org/patch/551421/

Signed-off-by: Yuran Pereira 
---
 Documentation/gpu/todo.rst | 25 -
 1 file changed, 25 deletions(-)

diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 03fe5d1247be..280020b0ad4d 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -460,31 +460,6 @@ Contact: Thomas Zimmermann 
 
 Level: Starter
 
-Clean up checks for already prepared/enabled in panels
---
-
-In a whole pile of panel drivers, we have code to make the
-prepare/unprepare/enable/disable callbacks behave as no-ops if they've already
-been called. To get some idea of the duplicated code, try::
-
-  git grep 'if.*>prepared' -- drivers/gpu/drm/panel
-  git grep 'if.*>enabled' -- drivers/gpu/drm/panel
-
-In the patch ("drm/panel: Check for already prepared/enabled in drm_panel")
-we've moved this check to the core. Now we can most definitely remove the
-check from the individual panels and save a pile of code.
-
-In adition to removing the check from the individual panels, it is believed
-that even the core shouldn't need this check and that should be considered
-an error if other code ever relies on this check. The check in the core
-currently prints a warning whenever something is relying on this check with
-dev_warn(). After a little while, we likely want to promote this to a
-WARN(1) to help encourage folks not to rely on this behavior.
-
-Contact: Douglas Anderson 
-
-Level: Starter/Intermediate
-
 
 Core refactorings
 =
-- 
2.25.1

Re: [PATCH 1/1] dt-bindings: backlight: mp3309c: remove two required properties

2023-10-23 Thread Conor Dooley

On Mon, Oct 23, 2023 at 09:28:03AM +, Flavio Suligoi wrote:
> > On Fri, Oct 20, 2023 at 03:54:33PM +0200, Flavio Suligoi wrote:
> > > The two properties:
> > >
> > > - max-brightness
> > > - default brightness
> > >
> > > are not really required, so they can be removed from the "required"
> > > section.
> > 
> > Why are they not required? You need to provide an explanation.
> 
> The "max-brightness" is not more used now in the driver (I used it in the 
> first version
> of the driver).

If it is not used any more, what happens when someone passes an old
devicetree to the kernel, that contains max-brightness, but not any of
your new properties?

> The "default-brightness", if omitted in the DT, is managed by the device 
> driver,
> using a default value. This depends on the dimming mode used:

For default-brightness, has here always been support in the driver for
the property being omitted, or is this newly added?

> - for the "analog mode", via I2C commands, this value is fixed by hardware 
> (=31)
> - while in case of pwm mode the default used is the last value of the 
>   brightness-levels array.
> 
> Also the brightness-levels array is not required; if it is omitted, the 
> driver uses 
> a default array of 0..255 and the "default-brightness" is the last one, which 
> is "255".

Firstly, this is the sort of rationale that needs to be put into your
commit messages, rather than bullet pointed lists of what you have done.

Secondly, what about other operating systems etc, do any of those support
this platform and depend on presence of these properties?

> 
> > > Other changes:
> > >
> > > - improve the backlight working mode description, in the "description"
> > >   section
> > 
> > > - update the example, removing the "max-brightness" and introducing the
> > >   "brightess-levels" property
> > 
> > Why is this more useful?
> 
> I introduced the "brightness-levels" instead of "max-brightness" for 
> homogeneity,
> since the "analog mode" dimming has a brightness-levels array fixed by 
> hardware (0..31).
> In this way also the "pwm" mode can use the same concepts of array of levels.

What I would like is an explanation in the commit message as to why the
revised example is more helpful than the existing (and
must-remain-valid) one.

Cheers,
Conor.

> > 
> > >
> > > Signed-off-by: Flavio Suligoi 
> > > ---
> > >  .../bindings/leds/backlight/mps,mp3309c.yaml   | 10 --
> > >  1 file changed, 4 insertions(+), 6 deletions(-)
> > >
> > > diff --git
> > a/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml
> > b/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml
> > > index 4191e33626f5..527a37368ed7 100644
> > > ---
> > a/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml
> > > +++
> > b/Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml
> > > @@ -14,8 +14,8 @@ description: |
> > >programmable switching frequency to optimize efficiency.
> > >It supports two different dimming modes:
> > >
> > > -  - analog mode, via I2C commands (default)
> > > -  - PWM controlled mode.
> > > +  - analog mode, via I2C commands, as default mode (32 dimming levels)
> > > +  - PWM controlled mode (optional)
> > >
> > >The datasheet is available at:
> > >https://www.monolithicpower.com/en/mp3309c.html
> > > @@ -50,8 +50,6 @@ properties:
> > >  required:
> > >- compatible
> > >- reg
> > > -  - max-brightness
> > > -  - default-brightness
> > >
> > >  unevaluatedProperties: false
> > >
> > > @@ -66,8 +64,8 @@ examples:
> > >  compatible = "mps,mp3309c";
> > >  reg = <0x17>;
> > >  pwms = < 0 333 0>; /* 300 Hz --> (1/f) * 1*10^9 */
> > > -max-brightness = <100>;
> > > -default-brightness = <80>;
> > > +brightness-levels = <0 4 8 16 32 64 128 255>;
> > > +default-brightness = <6>;
> > >  mps,overvoltage-protection-microvolt = <2400>;
> > >  };
> > >  };
> > > --
> > > 2.34.1
> > >


signature.asc
Description: PGP signature

Re: [PATCH v3 3/9] drm/vc4: hdmi: Add Broadcast RGB property to allow override of RGB range

2023-10-23 Thread Sebastian Wick

Honestly, the less time people spend on this property the better. Lift
the Intel one into core and be done with it. We'll hopefully be able
to remove it in the not-to-distant future with the new color pipeline
API and adding a new property which only sets the connector metadata
instead of influencing the color pipeline as well.

On Mon, Oct 23, 2023 at 4:58 PM Maxime Ripard  wrote:
>
> Hi Hans,
>
> On Thu, Oct 19, 2023 at 10:26:40AM +0200, Hans Verkuil wrote:
> > Hi Maxime,
> >
> > On 19/10/2023 10:02, Maxime Ripard wrote:
> > > Hi,
> > >
> > > On Wed, Oct 11, 2023 at 03:23:18PM +0200, Daniel Vetter wrote:
> > >> On Mon, 6 Mar 2023 at 11:49, Maxime Ripard  wrote:
> > >>>
> > >>> From: Dave Stevenson 
> > >>>
> > >>> Copy Intel's "Broadcast RGB" property semantics to add manual override
> > >>> of the HDMI pixel range for monitors that don't abide by the content
> > >>> of the AVI Infoframe.
> > >>>
> > >>> Signed-off-by: Dave Stevenson 
> > >>> Signed-off-by: Maxime Ripard 
> > >>
> > >> Stumbled over this grepping around, but would have been nice to lift
> > >> this into drm code and document the property. It's one of the legacy
> > >> ones from the table of horrors after all ...
> > >>
> > >> Shouldn't be an uapi problem because it's copypasted to much, just not 
> > >> great.
> > >
> > > We already discussed it on IRC, but just for the record I have a current
> > > series that should address exactly that:
> > >
> > > https://lore.kernel.org/dri-devel/20230920-kms-hdmi-connector-state-v2-3-17932dadd...@kernel.org/
> > >
> > > Maxime
> >
> > I've pasted a snippet from that patch below for a quick review:
> >
> > >  /**
> > >   * DOC: HDMI connector properties
> > >   *
> > > + * Broadcast RGB (HDMI Specific):
> >
> > Full vs Limited is actually not HDMI specific, DisplayPort can signal this 
> > as
> > well for whatever it is worth.
>
> Sure, what I (and the original patch I guess) meant is that it's only
> ever used on HDMI connectors these days. If that ever changes, then we
> can update the doc.
>
> > > + *  Indicates the RGB Range (Full vs Limited) used.
> >
> > RGB Range -> RGB Quantization Range
> >
> > > + *
> > > + *  The value of this property can be one of the following:
> > > + *
> > > + *  Automatic:
> > > + *  RGB Range is selected automatically based on the mode
> > > + *  according to the HDMI specifications.
> > > + *
> > > + *  Full:
> > > + *  Full RGB Range is forced.
> > > + *
> > > + *  Limited 16:235:
> >
> > It is very unfortunate that this is called "Limited 16:235" instead of just 
> > "Limited"
> > since for color component bit depths > 8 these values are different.
> >
> > I have no idea if it is possible to add an alias "Limited" that you can use 
> > instead.
> > In any case, this should document that it works just as well for higher bit 
> > depths,
> > but with different limits.
>
> I had a look and it doesn't look like the property infrastructure can
> deal with aliases. I'll add something in the doc
>
> Thanks!
> Maxime

Re: [RFC v4 0/5] Proposal to use netlink for RAS and Telemetry across drm subsystem

2023-10-23 Thread Alex Deucher

On Fri, Oct 20, 2023 at 7:42 PM Aravind Iddamsetty
 wrote:
>
> Our hardware supports RAS(Reliability, Availability, Serviceability) by
> reporting the errors to the host, which the KMD processes and exposes a
> set of error counters which can be used by observability tools to take
> corrective actions or repairs. Traditionally there were being exposed
> via PMU (for relative counters) and sysfs interface (for absolute
> value) in our internal branch. But, due to the limitations in this
> approach to use two interfaces and also not able to have an event based
> reporting or configurability, an alternative approach to try netlink
> was suggested by community for drm subsystem wide UAPI for RAS and
> telemetry as discussed in [1].
>
> This [1] is the inspiration to this series. It uses the generic
> netlink(genl) family subsystem and exposes a set of commands that can
> be used by every drm driver, the framework provides a means to have
> custom commands too. Each drm driver instance in this example xe driver
> instance registers a family and operations to the genl subsystem through
> which it enumerates and reports the error counters. An event based
> notification is also supported to which userpace can subscribe to and
> be notified when any error occurs and read the error counter this avoids
> continuous polling on error counter. This can also be extended to
> threshold based notification.

@Hawking Zhang, @Lazar, Lijo

Can you take a look at this series and API and see if it would align
with our RAS requirements going forward?

Alex


>
> [1]: 
> https://airlied.blogspot.com/2022/09/accelerators-bof-outcomes-summary.html
>
> this series is on top of https://patchwork.freedesktop.org/series/125373/,
>
> v4:
> 1. Rebase
> 2. rename drm_genl_send to drm_genl_reply
> 3. catch error from xa_store and handle appropriately
> 4. presently xe_list_errors fills blank data for IGFX, prevent it by
> having an early check of IS_DGFX (Michael J. Ruhl)
>
> v3:
> 1. Rebase on latest RAS series for XE
> 2. drop DRIVER_NETLINK flag and use the driver_genl_ops structure to
> register to netlink subsystem
>
> v2: define common interfaces to genl netlink subsystem that all drm drivers
> can leverage.
>
> Below is an example tool drm_ras which demonstrates the use of the
> supported commands. The tool will be sent to ML with the subject
> "[RFC i-g-t v2 0/1] A tool to demonstrate use of netlink sockets to read RAS 
> error counters"
> https://patchwork.freedesktop.org/series/118437/#rev2
>
> read single error counter:
>
> $ ./drm_ras READ_ONE --device=drm:/dev/dri/card1 --error_id=0x0005
> counter value 0
>
> read all error counters:
>
> $ ./drm_ras READ_ALL --device=drm:/dev/dri/card1
> nameconfig-id 
>   counter
>
> error-gt0-correctable-guc   0x0001
>   0
> error-gt0-correctable-slm   0x0003
>   0
> error-gt0-correctable-eu-ic 0x0004
>   0
> error-gt0-correctable-eu-grf0x0005
>   0
> error-gt0-fatal-guc 0x0009
>   0
> error-gt0-fatal-slm 0x000d
>   0
> error-gt0-fatal-eu-grf  0x000f
>   0
> error-gt0-fatal-fpu 0x0010
>   0
> error-gt0-fatal-tlb 0x0011
>   0
> error-gt0-fatal-l3-fabric   0x0012
>   0
> error-gt0-correctable-subslice  0x0013
>   0
> error-gt0-correctable-l3bank0x0014
>   0
> error-gt0-fatal-subslice0x0015
>   0
> error-gt0-fatal-l3bank  0x0016
>   0
> error-gt0-sgunit-correctable0x0017
>   0
> error-gt0-sgunit-nonfatal   0x0018
>   0
> error-gt0-sgunit-fatal  0x0019
>   0
> error-gt0-soc-fatal-psf-csc-0   0x001a
>   0
> error-gt0-soc-fatal-psf-csc-1   0x001b
>   0
> error-gt0-soc-fatal-psf-csc-2   0x001c
>   0
> error-gt0-soc-fatal-punit   0x001d
>   0
> error-gt0-soc-fatal-psf-0   0x001e
>   0
> error-gt0-soc-fatal-psf-1   0x001f
>   0
> error-gt0-soc-fatal-psf-2   0x0020
>   0
> error-gt0-soc-fatal-cd0 0x0021
>   0
>

[RFC] Clean up check for already prepared panel

2023-10-23 Thread Yuran Pereira

Since the core function drm_panel_prepare already checks if the
panel is prepared, we can remove this duplicate check from tm5p5_nt35596_prepare
which acts as a no-op. As suggested in the GPU TODO [1]

[1] 
https://docs.kernel.org/gpu/todo.html#clean-up-checks-for-already-prepared-enabled-in-panels

Suggested-by: Douglas Anderson 
Signed-off-by: Yuran Pereira 
---
 drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c 
b/drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c
index 075a7af81eff..af83451b3374 100644
--- a/drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c
+++ b/drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c
@@ -112,9 +112,6 @@ static int tm5p5_nt35596_prepare(struct drm_panel *panel)
struct device *dev = >dsi->dev;
int ret;
 
-   if (ctx->prepared)
-   return 0;
-
ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
if (ret < 0) {
dev_err(dev, "Failed to enable regulators: %d\n", ret);
@@ -132,7 +129,6 @@ static int tm5p5_nt35596_prepare(struct drm_panel *panel)
return ret;
}
 
-   ctx->prepared = true;
return 0;
 }
 
-- 
2.25.1

Re: [PATCH v3 3/9] drm/vc4: hdmi: Add Broadcast RGB property to allow override of RGB range

2023-10-23 Thread Maxime Ripard

Hi Hans,

On Thu, Oct 19, 2023 at 10:26:40AM +0200, Hans Verkuil wrote:
> Hi Maxime,
> 
> On 19/10/2023 10:02, Maxime Ripard wrote:
> > Hi,
> > 
> > On Wed, Oct 11, 2023 at 03:23:18PM +0200, Daniel Vetter wrote:
> >> On Mon, 6 Mar 2023 at 11:49, Maxime Ripard  wrote:
> >>>
> >>> From: Dave Stevenson 
> >>>
> >>> Copy Intel's "Broadcast RGB" property semantics to add manual override
> >>> of the HDMI pixel range for monitors that don't abide by the content
> >>> of the AVI Infoframe.
> >>>
> >>> Signed-off-by: Dave Stevenson 
> >>> Signed-off-by: Maxime Ripard 
> >>
> >> Stumbled over this grepping around, but would have been nice to lift
> >> this into drm code and document the property. It's one of the legacy
> >> ones from the table of horrors after all ...
> >>
> >> Shouldn't be an uapi problem because it's copypasted to much, just not 
> >> great.
> > 
> > We already discussed it on IRC, but just for the record I have a current
> > series that should address exactly that:
> > 
> > https://lore.kernel.org/dri-devel/20230920-kms-hdmi-connector-state-v2-3-17932dadd...@kernel.org/
> > 
> > Maxime
> 
> I've pasted a snippet from that patch below for a quick review:
> 
> >  /**
> >   * DOC: HDMI connector properties
> >   *
> > + * Broadcast RGB (HDMI Specific):
> 
> Full vs Limited is actually not HDMI specific, DisplayPort can signal this as
> well for whatever it is worth.

Sure, what I (and the original patch I guess) meant is that it's only
ever used on HDMI connectors these days. If that ever changes, then we
can update the doc.

> > + *  Indicates the RGB Range (Full vs Limited) used.
> 
> RGB Range -> RGB Quantization Range
> 
> > + *
> > + *  The value of this property can be one of the following:
> > + *
> > + *  Automatic:
> > + *  RGB Range is selected automatically based on the mode
> > + *  according to the HDMI specifications.
> > + *
> > + *  Full:
> > + *  Full RGB Range is forced.
> > + *
> > + *  Limited 16:235:
> 
> It is very unfortunate that this is called "Limited 16:235" instead of just 
> "Limited"
> since for color component bit depths > 8 these values are different.
> 
> I have no idea if it is possible to add an alias "Limited" that you can use 
> instead.
> In any case, this should document that it works just as well for higher bit 
> depths,
> but with different limits.

I had a look and it doesn't look like the property infrastructure can
deal with aliases. I'll add something in the doc

Thanks!
Maxime


signature.asc
Description: PGP signature

Re: [RFC] Clean up check for already prepared panel

2023-10-23 Thread neil . armstrong


Hi,

On 23/10/2023 16:51, Yuran Pereira wrote:

Since the core function drm_panel_prepare already checks if the
panel is prepared, we can remove this duplicate check from tm5p5_nt35596_prepare
which acts as a no-op. As suggested in the GPU TODO [1]

[1] 
https://docs.kernel.org/gpu/todo.html#clean-up-checks-for-already-prepared-enabled-in-panels

Suggested-by: Douglas Anderson 
Signed-off-by: Yuran Pereira 
---
  drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c | 4 
  1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c 
b/drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c
index 075a7af81eff..af83451b3374 100644
--- a/drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c
+++ b/drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c
@@ -112,9 +112,6 @@ static int tm5p5_nt35596_prepare(struct drm_panel *panel)
struct device *dev = >dsi->dev;
int ret;
  
-	if (ctx->prepared)

-   return 0;
-
ret = regulator_bulk_enable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
if (ret < 0) {
dev_err(dev, "Failed to enable regulators: %d\n", ret);
@@ -132,7 +129,6 @@ static int tm5p5_nt35596_prepare(struct drm_panel *panel)
return ret;
}
  
-	ctx->prepared = true;

return 0;
  }
  


This has already been done and merged in:
https://patchwork.freedesktop.org/patch/msgid/20230804140605.RFC.1.Ia54954fd2f7645c1b86597494902973f57feeb71@changeid

Thanks,
Neil

[PATCH 18/18] arm64: dts: mediatek: add display support for mt8365-evk

2023-10-23 Thread Alexandre Mergnat

MIPI DSI:
- Add "vsys_lcm_reg" regulator support and setup the "mt6357_vsim1_reg",
to power the pannel plugged to the DSI connector.
- Setup the Display Parallel Interface.
  - Add the startek kd070fhfid015 pannel support.

HDMI:
- Add HDMI connector support.
- Add the "ite,it66121" HDMI bridge support, driven by I2C1.
- Setup the Display Parallel Interface.

Signed-off-by: Alexandre Mergnat 
---
 arch/arm64/boot/dts/mediatek/mt8365-evk.dts | 183 
 1 file changed, 183 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8365-evk.dts 
b/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
index 50cbaefa1a99..823d7623b8b8 100644
--- a/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8365-evk.dts
@@ -26,6 +26,18 @@ chosen {
stdout-path = "serial0:921600n8";
};
 
+   connector {
+   compatible = "hdmi-connector";
+   label = "hdmi";
+   type = "d";
+
+   port {
+   hdmi_connector_in: endpoint {
+   remote-endpoint = <_connector_out>;
+   };
+   };
+   };
+
firmware {
optee {
compatible = "linaro,optee-tz";
@@ -86,6 +98,57 @@ optee_reserved: optee@4320 {
reg = <0 0x4320 0 0x00c0>;
};
};
+
+   vsys_lcm_reg: regulator-vsys-lcm {
+   compatible = "regulator-fixed";
+   enable-active-high;
+   gpio = < 129 GPIO_ACTIVE_HIGH>;
+   regulator-max-microvolt = <500>;
+   regulator-min-microvolt = <500>;
+   regulator-name = "vsys_lcm";
+   };
+};
+
+ {
+   pinctrl-0 = <_default_pins>;
+   pinctrl-1 = <_idle_pins>;
+   pinctrl-names = "default", "sleep";
+   status = "okay";
+
+   port {
+   dpi_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+};
+
+
+ {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "okay";
+
+   panel@0 {
+   compatible = "startek,kd070fhfid015";
+   status = "okay";
+   reg = <0>;
+   enable-gpios = < 67 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 20 GPIO_ACTIVE_HIGH>;
+   iovcc-supply = <_vsim1_reg>;
+   power-supply = <_lcm_reg>;
+
+   port {
+   panel_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+
+   port {
+   dsi_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
 };
 
  {
@@ -138,6 +201,50 @@  {
status = "okay";
 };
 
+ {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clock-div = <2>;
+   clock-frequency = <10>;
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   status = "okay";
+
+   it66121hdmitx: it66121hdmitx@4c {
+   #sound-dai-cells = <0>;
+   compatible = "ite,it66121";
+   interrupt-parent = <>;
+   interrupts = <68 IRQ_TYPE_LEVEL_LOW>;
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   reg = <0x4c>;
+   reset-gpios = < 69 GPIO_ACTIVE_LOW>;
+   vcn18-supply = <_vsim2_reg>;
+   vcn33-supply = <_vibr_reg>;
+   vrf12-supply = <_vrf12_reg>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   it66121_in: endpoint {
+   bus-width = <12>;
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   hdmi_connector_out: endpoint {
+   remote-endpoint = <_connector_in>;
+   };
+   };
+   };
+   };
+};
+
  {
assigned-clock-parents = < CLK_TOP_MSDCPLL>;
assigned-clocks = < CLK_TOP_MSDC50_0_SEL>;
@@ -180,7 +287,55 @@ _pmic {
#interrupt-cells = <2>;
 };
 
+_vsim1_reg {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+};
+
  {
+   dpi_default_pins: dpi-default-pins {
+   pins {
+   pinmux = ,
+,
+,
+,
+,
+,
+,
+,
+

[PATCH 02/18] dt-bindings: display: mediatek: ccorr: add binding for MT8365 SoC

2023-10-23 Thread Alexandre Mergnat

Display Color Correction for MT8365 is compatible with another SoC.
Then, add MT8365 binding along with MT8183 SoC.

Signed-off-by: Alexandre Mergnat 
---
 Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
index 8c2a737237f2..9f8366763831 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
@@ -24,6 +24,9 @@ properties:
   - enum:
   - mediatek,mt8183-disp-ccorr
   - mediatek,mt8192-disp-ccorr
+  - items:
+  - const: mediatek,mt8365-disp-ccorr
+  - const: mediatek,mt8183-disp-ccorr
   - items:
   - enum:
   - mediatek,mt8186-disp-ccorr

-- 
2.25.1

[PATCH 12/18] dt-bindings: pwm: add binding for mt8365 SoC

2023-10-23 Thread Alexandre Mergnat

Display PWM for MT8365 is compatible with MT8183. Then, add MT8365 binding
along with MT8183 SoC.

Signed-off-by: Alexandre Mergnat 
---
 Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml 
b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml
index efe0cacf55b7..e4069bcbf8d5 100644
--- a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml
+++ b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml
@@ -32,6 +32,7 @@ properties:
   - mediatek,mt8188-disp-pwm
   - mediatek,mt8192-disp-pwm
   - mediatek,mt8195-disp-pwm
+  - mediatek,mt8365-disp-pwm
   - const: mediatek,mt8183-disp-pwm
 
   reg:

-- 
2.25.1

[PATCH 13/18] drm/mediatek: dsi: Improves the DSI lane setup robustness

2023-10-23 Thread Alexandre Mergnat

Currently, mtk_dsi_lane_ready (which setup the DSI lane) is triggered
before mtk_dsi_poweron. lanes_ready flag toggle to true during
mtk_dsi_lane_ready function, and the DSI module is set up during
mtk_dsi_poweron.

Later, during panel driver init, mtk_dsi_lane_ready is triggered but does
nothing because lanes are considered ready. Unfortunately, when the panel
driver try to communicate, the DSI returns a timeout.

The solution found here is to put lanes_ready flag to false after the DSI
module setup into mtk_dsi_poweron to init the DSI lanes after the power /
setup of the DSI module.

Signed-off-by: Alexandre Mergnat 
---
 drivers/gpu/drm/mediatek/mtk_dsi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c 
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index d8bfc2cce54d..81cf0ddcc399 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -668,6 +668,8 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
mtk_dsi_config_vdo_timing(dsi);
mtk_dsi_set_interrupt_enable(dsi);
 
+   dsi->lanes_ready = false;
+
return 0;
 err_disable_engine_clk:
clk_disable_unprepare(dsi->engine_clk);

-- 
2.25.1

[PATCH 08/18] dt-bindings: display: mediatek: gamma: add binding for MT8365 SoC

2023-10-23 Thread Alexandre Mergnat

Display GAMMA for MT8365 is compatible with another SoC.
Then, add MT8365 binding along with MT8183 SoC.

Signed-off-by: Alexandre Mergnat 
---
 Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
index c6641acd75d6..f447f4320e8b 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
@@ -34,6 +34,7 @@ properties:
   - mediatek,mt8188-disp-gamma
   - mediatek,mt8192-disp-gamma
   - mediatek,mt8195-disp-gamma
+  - mediatek,mt8365-disp-gamma
   - const: mediatek,mt8183-disp-gamma
 
   reg:

-- 
2.25.1

[PATCH 17/18] arm64: dts: mediatek: add display blocks support for the MT8365 SoC

2023-10-23 Thread Alexandre Mergnat

- Add aliases for each display components to help display drivers.
- Add the Display Pulse Width Modulation (DISP_PWM) to provide PWM signals
  for the LED driver of mobile LCM.
- Add the MIPI Display Serial Interface (DSI) PHY support. (up to 4-lane
  output)
- Add the display mutex support.
- Add the following display component support:
  - OVL0 (Overlay)
  - RDMA0 (Data Path Read DMA)
  - Color0
  - CCorr0 (Color Correction)
  - AAL0 (Adaptive Ambient Light)
  - GAMMA0
  - Dither0
  - DSI0 (Display Serial Interface)
  - RDMA1 (Data Path Read DMA)
  - DPI0 (Display Parallel Interface)

Signed-off-by: Alexandre Mergnat 
---
 arch/arm64/boot/dts/mediatek/mt8365.dtsi | 146 +++
 1 file changed, 146 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8365.dtsi 
b/arch/arm64/boot/dts/mediatek/mt8365.dtsi
index 24581f7410aa..6096358f7d07 100644
--- a/arch/arm64/boot/dts/mediatek/mt8365.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8365.dtsi
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -17,6 +18,19 @@ / {
#address-cells = <2>;
#size-cells = <2>;
 
+   aliases {
+   aal0 = 
+   ccorr0 = 
+   color0 = 
+   dither0 = 
+   dpi0 = 
+   dsi0 = 
+   gamma0 = 
+   ovl0 = 
+   rdma0 = 
+   rdma1 = 
+   };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -607,6 +621,17 @@ spi: spi@1100a000 {
status = "disabled";
};
 
+   disp_pwm: pwm@1100e000 {
+   compatible = "mediatek,mt8365-disp-pwm",
+"mediatek,mt8183-disp-pwm";
+   reg = <0 0x1100e000 0 0x1000>;
+   clock-names = "main", "mm";
+   clocks = < CLK_TOP_DISP_PWM_SEL>,
+< CLK_IFR_DISP_PWM>;
+   power-domains = < MT8365_POWER_DOMAIN_MM>;
+   #pwm-cells = <2>;
+   };
+
i2c3: i2c@1100f000 {
compatible = "mediatek,mt8365-i2c", 
"mediatek,mt8168-i2c";
reg = <0 0x1100f000 0 0xa0>, <0 0x11000200 0 0x80>;
@@ -703,6 +728,15 @@ ethernet: ethernet@112a {
status = "disabled";
};
 
+   mipi_tx0: dsi-phy@11c0 {
+   compatible = "mediatek,mt8365-mipi-tx", 
"mediatek,mt8183-mipi-tx";
+   reg = <0 0x11c0 0 0x800>;
+   clock-output-names = "mipi_tx0_pll";
+   clocks = <>;
+   #clock-cells = <0>;
+   #phy-cells = <0>;
+   };
+
u3phy: t-phy@11cc {
compatible = "mediatek,mt8365-tphy", 
"mediatek,generic-tphy-v2";
#address-cells = <1>;
@@ -732,6 +766,13 @@ mmsys: syscon@1400 {
#clock-cells = <1>;
};
 
+   mutex: mutex@14001000 {
+   compatible =  "mediatek,mt8365-disp-mutex";
+   reg = <0 0x14001000 0 0x1000>;
+   interrupts = ;
+   power-domains = < MT8365_POWER_DOMAIN_MM>;
+   };
+
smi_common: smi@14002000 {
compatible = "mediatek,mt8365-smi-common";
reg = <0 0x14002000 0 0x1000>;
@@ -755,6 +796,111 @@ larb0: larb@14003000 {
mediatek,larb-id = <0>;
};
 
+   ovl0: ovl@1400b000 {
+   compatible = "mediatek,mt8365-disp-ovl",
+"mediatek,mt8192-disp-ovl";
+   reg = <0 0x1400b000 0 0x1000>;
+   clocks = < CLK_MM_MM_DISP_OVL0>;
+   interrupts = ;
+   iommus = < M4U_PORT_DISP_OVL0>;
+   power-domains = < MT8365_POWER_DOMAIN_MM>;
+   };
+
+   rdma0: rdma@1400d000 {
+   compatible = "mediatek,mt8365-disp-rdma",
+"mediatek,mt8183-disp-rdma";
+   reg = <0 0x1400d000 0 0x1000>;
+   clocks = < CLK_MM_MM_DISP_RDMA0>;
+   interrupts = ;
+   iommus = < M4U_PORT_DISP_RDMA0>;
+   mediatek,rdma-fifo-size = <5120>;
+   power-domains = < MT8365_POWER_DOMAIN_MM>;
+   };
+
+   color0: color@1400f000 {
+   compatible = "mediatek,mt8365-disp-color",
+"mediatek,mt8173-disp-color";
+   reg = <0 0x1400f000 0 0x1000>;
+   clocks = < CLK_MM_MM_DISP_COLOR0>;
+

[PATCH 06/18] dt-bindings: display: mediatek: dpi: add power-domains property

2023-10-23 Thread amergnat

From: Fabien Parent 

DPI is part of the display / multimedia block in MediaTek SoCs, and
always have a power-domain (at least in the upstream device-trees).
Add the power-domains property to the binding documentation.

Signed-off-by: Fabien Parent 
Signed-off-by: Alexandre Mergnat 
---
 Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml | 5 +
 1 file changed, 5 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
index 803c00f26206..e126486e8eac 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
@@ -64,6 +64,9 @@ properties:
   Output port node. This port should be connected to the input port of an
   attached HDMI, LVDS or DisplayPort encoder chip.
 
+  power-domains:
+maxItems: 1
+
 required:
   - compatible
   - reg
@@ -78,11 +81,13 @@ examples:
   - |
 #include 
 #include 
+#include 
 
 dpi0: dpi@1401d000 {
 compatible = "mediatek,mt8173-dpi";
 reg = <0x1401d000 0x1000>;
 interrupts = ;
+power-domains = < MT8173_POWER_DOMAIN_MM>;
 clocks = < CLK_MM_DPI_PIXEL>,
  < CLK_MM_DPI_ENGINE>,
  < CLK_APMIXED_TVDPLL>;

-- 
2.25.1

[PATCH 03/18] dt-bindings: display: mediatek: color: add binding for MT8365 SoC

2023-10-23 Thread Alexandre Mergnat

Display Color for MT8365 is compatible with another SoC.
Then, add MT8365 binding along with MT8183 SoC.

Signed-off-by: Alexandre Mergnat 
---
 Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
index f21e44092043..fbf15242af52 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
@@ -39,6 +39,7 @@ properties:
   - mediatek,mt8188-disp-color
   - mediatek,mt8192-disp-color
   - mediatek,mt8195-disp-color
+  - mediatek,mt8365-disp-color
   - const: mediatek,mt8173-disp-color
   reg:
 maxItems: 1

-- 
2.25.1

[PATCH 15/18] drm/mediatek: add MT8365 SoC support

2023-10-23 Thread amergnat

From: Fabien Parent 

Add DRM support for MT8365 SoC.

Signed-off-by: Fabien Parent 
Signed-off-by: Alexandre Mergnat 
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 93552d76b6e7..682ab464186f 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -227,6 +227,22 @@ static const unsigned int mt8195_mtk_ddp_ext[] = {
DDP_COMPONENT_DP_INTF1,
 };
 
+static const unsigned int mt8365_mtk_ddp_main[] = {
+   DDP_COMPONENT_OVL0,
+   DDP_COMPONENT_RDMA0,
+   DDP_COMPONENT_COLOR0,
+   DDP_COMPONENT_CCORR,
+   DDP_COMPONENT_AAL0,
+   DDP_COMPONENT_GAMMA,
+   DDP_COMPONENT_DITHER0,
+   DDP_COMPONENT_DSI0,
+};
+
+static const unsigned int mt8365_mtk_ddp_ext[] = {
+   DDP_COMPONENT_RDMA1,
+   DDP_COMPONENT_DPI0,
+};
+
 static const struct mtk_mmsys_driver_data mt2701_mmsys_driver_data = {
.main_path = mt2701_mtk_ddp_main,
.main_len = ARRAY_SIZE(mt2701_mtk_ddp_main),
@@ -311,6 +327,14 @@ static const struct mtk_mmsys_driver_data 
mt8195_vdosys1_driver_data = {
.mmsys_dev_num = 2,
 };
 
+static const struct mtk_mmsys_driver_data mt8365_mmsys_driver_data = {
+   .main_path = mt8365_mtk_ddp_main,
+   .main_len = ARRAY_SIZE(mt8365_mtk_ddp_main),
+   .ext_path = mt8365_mtk_ddp_ext,
+   .ext_len = ARRAY_SIZE(mt8365_mtk_ddp_ext),
+   .mmsys_dev_num = 1,
+};
+
 static const struct of_device_id mtk_drm_of_ids[] = {
{ .compatible = "mediatek,mt2701-mmsys",
  .data = _mmsys_driver_data},
@@ -336,6 +360,8 @@ static const struct of_device_id mtk_drm_of_ids[] = {
  .data = _vdosys0_driver_data},
{ .compatible = "mediatek,mt8195-vdosys1",
  .data = _vdosys1_driver_data},
+   { .compatible = "mediatek,mt8365-mmsys",
+ .data = _mmsys_driver_data},
{ }
 };
 MODULE_DEVICE_TABLE(of, mtk_drm_of_ids);
@@ -703,6 +729,8 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
  .data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt8195-disp-mutex",
  .data = (void *)MTK_DISP_MUTEX },
+   { .compatible = "mediatek,mt8365-disp-mutex",
+ .data = (void *)MTK_DISP_MUTEX },
{ .compatible = "mediatek,mt8173-disp-od",
  .data = (void *)MTK_DISP_OD },
{ .compatible = "mediatek,mt2701-disp-ovl",
@@ -765,6 +793,8 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
  .data = (void *)MTK_DSI },
{ .compatible = "mediatek,mt8186-dsi",
  .data = (void *)MTK_DSI },
+   { .compatible = "mediatek,mt8365-dpi",
+ .data = (void *)MTK_DPI },
{ }
 };
 

-- 
2.25.1

[PATCH 09/18] dt-bindings: display: mediatek: ovl: add binding for MT8365 SoC

2023-10-23 Thread Alexandre Mergnat

Display Overlay for MT8365 is compatible with another SoC.
Then, add MT8365 binding along with MT8192 SoC.

Signed-off-by: Alexandre Mergnat 
---
 Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
index 3e1069b00b56..2873bbdf3979 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
@@ -43,6 +43,7 @@ properties:
   - items:
   - enum:
   - mediatek,mt8186-disp-ovl
+  - mediatek,mt8365-disp-ovl
   - const: mediatek,mt8192-disp-ovl
 
   reg:

-- 
2.25.1

[PATCH 16/18] arm64: defconfig: enable display connector support

2023-10-23 Thread Alexandre Mergnat

Enable this feature for the i350-evk HDMI connector support.

Signed-off-by: Alexandre Mergnat 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 5315789f4868..0a60e7616abe 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -839,6 +839,7 @@ CONFIG_DRM_PANEL_RAYDIUM_RM67191=m
 CONFIG_DRM_PANEL_SITRONIX_ST7703=m
 CONFIG_DRM_PANEL_TRULY_NT35597_WQXGA=m
 CONFIG_DRM_PANEL_VISIONOX_VTDR6130=m
+CONFIG_DRM_DISPLAY_CONNECTOR=m
 CONFIG_DRM_LONTIUM_LT8912B=m
 CONFIG_DRM_LONTIUM_LT9611=m
 CONFIG_DRM_LONTIUM_LT9611UXC=m

-- 
2.25.1

[PATCH 14/18] drm/mediatek: dpi: add support for dpi clock

2023-10-23 Thread amergnat

From: Fabien Parent 

MT8365 requires an additional clock for DPI. Add support for that
additional clock.

Signed-off-by: Fabien Parent 
Signed-off-by: Alexandre Mergnat 
---
 drivers/gpu/drm/mediatek/mtk_dpi.c | 50 +-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 2f931e4e2b60..ddd7c54febe6 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -70,6 +70,7 @@ struct mtk_dpi {
struct device *mmsys_dev;
struct clk *engine_clk;
struct clk *pixel_clk;
+   struct clk *dpi_clk;
struct clk *tvd_clk;
int irq;
struct drm_display_mode mode;
@@ -137,6 +138,7 @@ struct mtk_dpi_yc_limit {
  * @csc_enable_bit: Enable bit of CSC.
  * @pixels_per_iter: Quantity of transferred pixels per iteration.
  * @edge_cfg_in_mmsys: If the edge configuration for DPI's output needs to be 
set in MMSYS.
+ * @is_dpi_clk_req: Support the additionnal DPI clock.
  */
 struct mtk_dpi_conf {
unsigned int (*cal_factor)(int clock);
@@ -156,6 +158,7 @@ struct mtk_dpi_conf {
u32 csc_enable_bit;
u32 pixels_per_iter;
bool edge_cfg_in_mmsys;
+   bool is_dpi_clk_req;
 };
 
 static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)
@@ -472,6 +475,7 @@ static void mtk_dpi_power_off(struct mtk_dpi *dpi)
mtk_dpi_disable(dpi);
clk_disable_unprepare(dpi->pixel_clk);
clk_disable_unprepare(dpi->engine_clk);
+   clk_disable_unprepare(dpi->dpi_clk);
 }
 
 static int mtk_dpi_power_on(struct mtk_dpi *dpi)
@@ -481,10 +485,16 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi)
if (++dpi->refcount != 1)
return 0;
 
+   ret = clk_prepare_enable(dpi->dpi_clk);
+   if (ret) {
+   dev_err(dpi->dev, "failed to enable dpi clock: %d\n", ret);
+   goto err_refcount;
+   }
+
ret = clk_prepare_enable(dpi->engine_clk);
if (ret) {
dev_err(dpi->dev, "Failed to enable engine clock: %d\n", ret);
-   goto err_refcount;
+   goto err_engine;
}
 
ret = clk_prepare_enable(dpi->pixel_clk);
@@ -497,6 +507,8 @@ static int mtk_dpi_power_on(struct mtk_dpi *dpi)
 
 err_pixel:
clk_disable_unprepare(dpi->engine_clk);
+err_engine:
+   clk_disable_unprepare(dpi->dpi_clk);
 err_refcount:
dpi->refcount--;
return ret;
@@ -902,6 +914,7 @@ static const struct mtk_dpi_conf mt8173_conf = {
.channel_swap_shift = CH_SWAP,
.yuv422_en_bit = YUV422_EN,
.csc_enable_bit = CSC_ENABLE,
+   .is_dpi_clk_req = false,
 };
 
 static const struct mtk_dpi_conf mt2701_conf = {
@@ -920,6 +933,7 @@ static const struct mtk_dpi_conf mt2701_conf = {
.channel_swap_shift = CH_SWAP,
.yuv422_en_bit = YUV422_EN,
.csc_enable_bit = CSC_ENABLE,
+   .is_dpi_clk_req = false,
 };
 
 static const struct mtk_dpi_conf mt8183_conf = {
@@ -937,6 +951,7 @@ static const struct mtk_dpi_conf mt8183_conf = {
.channel_swap_shift = CH_SWAP,
.yuv422_en_bit = YUV422_EN,
.csc_enable_bit = CSC_ENABLE,
+   .is_dpi_clk_req = false,
 };
 
 static const struct mtk_dpi_conf mt8186_conf = {
@@ -969,6 +984,7 @@ static const struct mtk_dpi_conf mt8188_dpintf_conf = {
.channel_swap_shift = DPINTF_CH_SWAP,
.yuv422_en_bit = DPINTF_YUV422_EN,
.csc_enable_bit = DPINTF_CSC_ENABLE,
+   .is_dpi_clk_req = false,
 };
 
 static const struct mtk_dpi_conf mt8192_conf = {
@@ -986,6 +1002,7 @@ static const struct mtk_dpi_conf mt8192_conf = {
.channel_swap_shift = CH_SWAP,
.yuv422_en_bit = YUV422_EN,
.csc_enable_bit = CSC_ENABLE,
+   .is_dpi_clk_req = false,
 };
 
 static const struct mtk_dpi_conf mt8195_dpintf_conf = {
@@ -1000,6 +1017,25 @@ static const struct mtk_dpi_conf mt8195_dpintf_conf = {
.channel_swap_shift = DPINTF_CH_SWAP,
.yuv422_en_bit = DPINTF_YUV422_EN,
.csc_enable_bit = DPINTF_CSC_ENABLE,
+   .is_dpi_clk_req = false,
+};
+
+static const struct mtk_dpi_conf mt8365_conf = {
+   .cal_factor = mt8183_calculate_factor,
+   .channel_swap_shift = CH_SWAP,
+   .csc_enable_bit = CSC_ENABLE,
+   .dimension_mask = HPW_MASK,
+   .hvsize_mask = HSIZE_MASK,
+   .is_ck_de_pol = true,
+   .is_dpi_clk_req = true,
+   .max_clock_khz = 15,
+   .num_output_fmts = ARRAY_SIZE(mt8183_output_fmts),
+   .output_fmts = mt8183_output_fmts,
+   .pixels_per_iter = 1,
+   .reg_h_fre_con = 0xe0,
+   .support_direct_pin = true,
+   .swap_input_support = true,
+   .yuv422_en_bit = YUV422_EN,
 };
 
 static int mtk_dpi_probe(struct platform_device *pdev)
@@ -1056,6 +1092,17 @@ static int mtk_dpi_probe(struct platform_device *pdev)
return dev_err_probe(dev, PTR_ERR(dpi->tvd_clk),

[PATCH 04/18] dt-bindings: display: mediatek: dither: add binding for MT8365 SoC

2023-10-23 Thread Alexandre Mergnat

Display Dither for MT8365 is compatible with another SoC.
Then, add MT8365 binding along with MT8183 SoC.

Signed-off-by: Alexandre Mergnat 
---
 Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
index 1588b3f7cec7..6fceb1f95d2a 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
@@ -30,6 +30,7 @@ properties:
   - mediatek,mt8188-disp-dither
   - mediatek,mt8192-disp-dither
   - mediatek,mt8195-disp-dither
+  - mediatek,mt8365-disp-dither
   - const: mediatek,mt8183-disp-dither
 
   reg:

-- 
2.25.1

[PATCH 11/18] dt-bindings: pwm: add power-domains property

2023-10-23 Thread Alexandre Mergnat

According to the Mediatek datasheet, the display PWM block has a power
domain.

Signed-off-by: Alexandre Mergnat 
---
 Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml | 8 
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml 
b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml
index 153e146df7d4..efe0cacf55b7 100644
--- a/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml
+++ b/Documentation/devicetree/bindings/pwm/mediatek,pwm-disp.yaml
@@ -53,6 +53,12 @@ properties:
   - const: main
   - const: mm
 
+  power-domains:
+maxItems: 1
+description: A phandle and PM domain specifier as defined by bindings of
+  the power controller specified by phandle. See
+  Documentation/devicetree/bindings/power/power-domain.yaml for details.
+
 required:
   - compatible
   - reg
@@ -67,6 +73,7 @@ examples:
 #include 
 #include 
 #include 
+#include 
 
 pwm0: pwm@1401e000 {
 compatible = "mediatek,mt8173-disp-pwm";
@@ -75,4 +82,5 @@ examples:
 clocks = < CLK_MM_DISP_PWM026M>,
  < CLK_MM_DISP_PWM0MM>;
 clock-names = "main", "mm";
+power-domains = < MT8173_POWER_DOMAIN_MM>;
 };

-- 
2.25.1

[PATCH 07/18] dt-bindings: display: mediatek: dpi: add binding for MT8365

2023-10-23 Thread amergnat

From: Fabien Parent 

DPI for MT8365 is compatible with MT8192 but requires an additional
clock. Modify the documentation to requires this clock only on MT8365 SoCs.

Signed-off-by: Fabien Parent 
Signed-off-by: Alexandre Mergnat 
---
 .../bindings/display/mediatek/mediatek,dpi.yaml   | 19 +++
 1 file changed, 19 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
index e126486e8eac..c86527c33acf 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
@@ -27,6 +27,7 @@ properties:
   - mediatek,mt8188-dp-intf
   - mediatek,mt8192-dpi
   - mediatek,mt8195-dp-intf
+  - mediatek,mt8365-dpi
   - items:
   - enum:
   - mediatek,mt6795-dpi
@@ -39,16 +40,20 @@ properties:
 maxItems: 1
 
   clocks:
+minItems: 3
 items:
   - description: Pixel Clock
   - description: Engine Clock
   - description: DPI PLL
+  - description: DPI Clock
 
   clock-names:
+minItems: 3
 items:
   - const: pixel
   - const: engine
   - const: pll
+  - const: dpi
 
   pinctrl-0: true
   pinctrl-1: true
@@ -77,6 +82,20 @@ required:
 
 additionalProperties: false
 
+allOf:
+  - if:
+  properties:
+compatible:
+  contains:
+const: mediatek,mt8365-dpi
+
+then:
+  properties:
+clocks:
+  minItems: 4
+clock-names:
+  minItems: 4
+
 examples:
   - |
 #include 

-- 
2.25.1

[PATCH 05/18] dt-bindings: display: mediatek: dsi: add binding for MT8365 SoC

2023-10-23 Thread Alexandre Mergnat

Display Serial Interface for MT8365 is compatible with another SoC.
Then, add MT8365 binding along with MT8183 SoC.

Signed-off-by: Alexandre Mergnat 
---
 Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
index 12441b937684..2479b9e4abd2 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
@@ -34,6 +34,8 @@ properties:
   - enum:
   - mediatek,mt6795-dsi
   - const: mediatek,mt8173-dsi
+  - mediatek,mt8365-dsi
+  - const: mediatek,mt8183-dsi
 
   reg:
 maxItems: 1

-- 
2.25.1

[PATCH 10/18] dt-bindings: display: mediatek: rdma: add binding for MT8365 SoC

2023-10-23 Thread Alexandre Mergnat

Display Data Path Read DMA for MT8365 is compatible with another SoC.
Then, add MT8365 binding along with MT8183 SoC.

Signed-off-by: Alexandre Mergnat 
---
 Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
index 39dbb5c8bcf8..4cadb245d028 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
@@ -45,6 +45,7 @@ properties:
   - enum:
   - mediatek,mt8186-disp-rdma
   - mediatek,mt8192-disp-rdma
+  - mediatek,mt8365-disp-rdma
   - const: mediatek,mt8183-disp-rdma
 
   reg:

-- 
2.25.1

[PATCH 01/18] dt-bindings: display: mediatek: aal: add binding for MT8365 SoC

2023-10-23 Thread Alexandre Mergnat

Display Adaptive Ambient Light for MT8365 is compatible with another SoC.
Then, add MT8365 binding along with MT8183 SoC.

Signed-off-by: Alexandre Mergnat 
---
 Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml 
b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
index 7fd42c8fdc32..840b48a878ca 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
@@ -35,6 +35,7 @@ properties:
   - mediatek,mt8188-disp-aal
   - mediatek,mt8192-disp-aal
   - mediatek,mt8195-disp-aal
+  - mediatek,mt8365-disp-aal
   - const: mediatek,mt8183-disp-aal
 
   reg:

-- 
2.25.1

[PATCH 00/18] Add display support for the MT8365-EVK board

2023-10-23 Thread Alexandre Mergnat

The purpose of this series is to add the display support for the mt8365-evk.

This is the list of HWs / IPs support added:
- Connectors (HW):
  - HDMI
  - MIPI DSI (Mobile Industry Processor Interface Display Serial Interface)
- HDMI bridge (it66121)
- DSI pannel (startek,kd070fhfid015)
- SoC display blocks (IP):
  - OVL0 (Overlay)
  - RDMA0 (Data Path Read DMA)
  - Color0
  - CCorr0 (Color Correction)
  - AAL0 (Adaptive Ambient Light)
  - GAMMA0
  - Dither0
  - DSI0 (Display Serial Interface)
  - RDMA1 (Data Path Read DMA)
  - DPI0 (Display Parallel Interface)

The Mediatek DSI, DPI and DRM drivers are also improved.

Regards,
Alex

Signed-off-by: Alexandre Mergnat 
---
Alexandre Mergnat (14):
  dt-bindings: display: mediatek: aal: add binding for MT8365 SoC
  dt-bindings: display: mediatek: ccorr: add binding for MT8365 SoC
  dt-bindings: display: mediatek: color: add binding for MT8365 SoC
  dt-bindings: display: mediatek: dither: add binding for MT8365 SoC
  dt-bindings: display: mediatek: dsi: add binding for MT8365 SoC
  dt-bindings: display: mediatek: gamma: add binding for MT8365 SoC
  dt-bindings: display: mediatek: ovl: add binding for MT8365 SoC
  dt-bindings: display: mediatek: rdma: add binding for MT8365 SoC
  dt-bindings: pwm: add power-domains property
  dt-bindings: pwm: add binding for mt8365 SoC
  drm/mediatek: dsi: Improves the DSI lane setup robustness
  arm64: defconfig: enable display connector support
  arm64: dts: mediatek: add display blocks support for the MT8365 SoC
  arm64: dts: mediatek: add display support for mt8365-evk

Fabien Parent (4):
  dt-bindings: display: mediatek: dpi: add power-domains property
  dt-bindings: display: mediatek: dpi: add binding for MT8365
  drm/mediatek: dpi: add support for dpi clock
  drm/mediatek: add MT8365 SoC support

 .../bindings/display/mediatek/mediatek,aal.yaml|   1 +
 .../bindings/display/mediatek/mediatek,ccorr.yaml  |   3 +
 .../bindings/display/mediatek/mediatek,color.yaml  |   1 +
 .../bindings/display/mediatek/mediatek,dither.yaml |   1 +
 .../bindings/display/mediatek/mediatek,dpi.yaml|  24 +++
 .../bindings/display/mediatek/mediatek,dsi.yaml|   2 +
 .../bindings/display/mediatek/mediatek,gamma.yaml  |   1 +
 .../bindings/display/mediatek/mediatek,ovl.yaml|   1 +
 .../bindings/display/mediatek/mediatek,rdma.yaml   |   1 +
 .../devicetree/bindings/pwm/mediatek,pwm-disp.yaml |   9 +
 arch/arm64/boot/dts/mediatek/mt8365-evk.dts| 183 +
 arch/arm64/boot/dts/mediatek/mt8365.dtsi   | 146 
 arch/arm64/configs/defconfig   |   1 +
 drivers/gpu/drm/mediatek/mtk_dpi.c |  50 +-
 drivers/gpu/drm/mediatek/mtk_drm_drv.c |  30 
 drivers/gpu/drm/mediatek/mtk_dsi.c |   2 +
 16 files changed, 455 insertions(+), 1 deletion(-)
---
base-commit: d27bed55ce32b0732ef65561851fec3dc8d01852
change-id: 20231023-display-support-c6418b30e419

Best regards,
-- 
Alexandre Mergnat

[PATCH] drm/msm/adreno: Drop WARN_ON from patchid lookup for new GPUs

2023-10-23 Thread Konrad Dybcio

New GPUs still use the lower 2 bytes of the chip id (in whatever form
it comes) to signify silicon revision. Drop the warning that makes it
sound as if that was unintended.

Fixes: 90b593ce1c9e ("drm/msm/adreno: Switch to chip-id for identifying GPU")
Signed-off-by: Konrad Dybcio 
---
 drivers/gpu/drm/msm/adreno/adreno_gpu.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h 
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index 80b3f6312116..9a1ec42155fd 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -203,11 +203,6 @@ struct adreno_platform_config {
 
 static inline uint8_t adreno_patchid(const struct adreno_gpu *gpu)
 {
-   /* It is probably ok to assume legacy "adreno_rev" format
-* for all a6xx devices, but probably best to limit this
-* to older things.
-*/
-   WARN_ON_ONCE(gpu->info->family >= ADRENO_6XX_GEN1);
return gpu->chip_id & 0xff;
 }
 

---
base-commit: e8361b005d7c92997d12f2b85a9e4a525738bd9d
change-id: 20231023-topic-adreno_warn-42a09bb4bf64

Best regards,
-- 
Konrad Dybcio

Re: [PATCH v6 5/7] drm/sched: Split free_job into own work item

2023-10-23 Thread Boris Brezillon

On Mon, 23 Oct 2023 13:54:13 +
Matthew Brost  wrote:

> On Mon, Oct 23, 2023 at 02:39:37PM +0200, Boris Brezillon wrote:
> > On Mon, 23 Oct 2023 14:16:06 +0200
> > Boris Brezillon  wrote:
> >   
> > > Hi,
> > > 
> > > On Tue, 17 Oct 2023 08:09:56 -0700
> > > Matthew Brost  wrote:
> > >   
> > > > +static void drm_sched_run_job_work(struct work_struct *w)
> > > > +{
> > > > +   struct drm_gpu_scheduler *sched =
> > > > +   container_of(w, struct drm_gpu_scheduler, work_run_job);
> > > > +   struct drm_sched_entity *entity;
> > > > +   struct dma_fence *fence;
> > > > +   struct drm_sched_fence *s_fence;
> > > > +   struct drm_sched_job *sched_job;
> > > > +   int r;
> > > >  
> > > > -   atomic_inc(>hw_rq_count);
> > > > -   drm_sched_job_begin(sched_job);
> > > > +   if (READ_ONCE(sched->pause_submit))
> > > > +   return;
> > > > +
> > > > +   entity = drm_sched_select_entity(sched, true);
> > > > +   if (!entity)
> > > > +   return;
> > > >  
> > > > -   trace_drm_run_job(sched_job, entity);
> > > > -   fence = sched->ops->run_job(sched_job);
> > > > +   sched_job = drm_sched_entity_pop_job(entity);
> > > > +   if (!sched_job) {
> > > > complete_all(>entity_idle);
> > > > -   drm_sched_fence_scheduled(s_fence, fence);
> > > > +   return; /* No more work */
> > > > +   }
> > > >  
> > > > -   if (!IS_ERR_OR_NULL(fence)) {
> > > > -   /* Drop for original kref_init of the fence */
> > > > -   dma_fence_put(fence);
> > > > +   s_fence = sched_job->s_fence;
> > > >  
> > > > -   r = dma_fence_add_callback(fence, 
> > > > _job->cb,
> > > > -  
> > > > drm_sched_job_done_cb);
> > > > -   if (r == -ENOENT)
> > > > -   drm_sched_job_done(sched_job, 
> > > > fence->error);
> > > > -   else if (r)
> > > > -   DRM_DEV_ERROR(sched->dev, "fence add 
> > > > callback failed (%d)\n",
> > > > - r);
> > > > -   } else {
> > > > -   drm_sched_job_done(sched_job, IS_ERR(fence) ?
> > > > -  PTR_ERR(fence) : 0);
> > > > -   }
> > > > +   atomic_inc(>hw_rq_count);
> > > > +   drm_sched_job_begin(sched_job);
> > > >  
> > > > -   wake_up(>job_scheduled);
> > > > +   trace_drm_run_job(sched_job, entity);
> > > > +   fence = sched->ops->run_job(sched_job);
> > > > +   complete_all(>entity_idle);
> > > > +   drm_sched_fence_scheduled(s_fence, fence);
> > > > +
> > > > +   if (!IS_ERR_OR_NULL(fence)) {
> > > > +   /* Drop for original kref_init of the fence */
> > > > +   dma_fence_put(fence);
> > > > +
> > > > +   r = dma_fence_add_callback(fence, _job->cb,
> > > > +  drm_sched_job_done_cb);
> > > > +   if (r == -ENOENT)
> > > > +   drm_sched_job_done(sched_job, fence->error);
> > > > +   else if (r)
> > > > +   DRM_DEV_ERROR(sched->dev, "fence add callback 
> > > > failed (%d)\n", r);
> > > > +   } else {
> > > > +   drm_sched_job_done(sched_job, IS_ERR(fence) ?
> > > > +  PTR_ERR(fence) : 0);
> > > > }
> > > 
> > > Just ran into a race condition when using a non-ordered workqueue
> > > for drm_sched:
> > > 
> > > thread A  thread B
> > > 
> > > drm_sched_run_job_work()  
> > >   drm_sched_job_begin()
> > > // inserts jobA in pending_list
> > > 
> > >   
> > > drm_sched_free_job_work()
> > > 
> > > drm_sched_get_cleanup_job()
> > >   // check 
> > > first job in pending list
> > >   // if 
> > > s_fence->parent == NULL, consider
> > >   // for 
> > > cleanup  
> > > 
> > > ->free_job(jobA)
> > >   
> > > drm_sched_job_cleanup()
> > > // set 
> > > sched_job->s_fence = NULL
> > >   
> > > ->run_job()
> > > drm_sched_fence_scheduled()  
> > 
> > Correction: the NULL pointer deref happens in drm_sched_job_done()
> > (when the driver returns an error directly) not in
> > drm_sched_fence_scheduled(), but the problem remains the same.
>

Re: [PATCH v6 5/7] drm/sched: Split free_job into own work item

2023-10-23 Thread Matthew Brost

On Mon, Oct 23, 2023 at 02:39:37PM +0200, Boris Brezillon wrote:
> On Mon, 23 Oct 2023 14:16:06 +0200
> Boris Brezillon  wrote:
> 
> > Hi,
> > 
> > On Tue, 17 Oct 2023 08:09:56 -0700
> > Matthew Brost  wrote:
> > 
> > > +static void drm_sched_run_job_work(struct work_struct *w)
> > > +{
> > > + struct drm_gpu_scheduler *sched =
> > > + container_of(w, struct drm_gpu_scheduler, work_run_job);
> > > + struct drm_sched_entity *entity;
> > > + struct dma_fence *fence;
> > > + struct drm_sched_fence *s_fence;
> > > + struct drm_sched_job *sched_job;
> > > + int r;
> > >  
> > > - atomic_inc(>hw_rq_count);
> > > - drm_sched_job_begin(sched_job);
> > > + if (READ_ONCE(sched->pause_submit))
> > > + return;
> > > +
> > > + entity = drm_sched_select_entity(sched, true);
> > > + if (!entity)
> > > + return;
> > >  
> > > - trace_drm_run_job(sched_job, entity);
> > > - fence = sched->ops->run_job(sched_job);
> > > + sched_job = drm_sched_entity_pop_job(entity);
> > > + if (!sched_job) {
> > >   complete_all(>entity_idle);
> > > - drm_sched_fence_scheduled(s_fence, fence);
> > > + return; /* No more work */
> > > + }
> > >  
> > > - if (!IS_ERR_OR_NULL(fence)) {
> > > - /* Drop for original kref_init of the fence */
> > > - dma_fence_put(fence);
> > > + s_fence = sched_job->s_fence;
> > >  
> > > - r = dma_fence_add_callback(fence, _job->cb,
> > > -drm_sched_job_done_cb);
> > > - if (r == -ENOENT)
> > > - drm_sched_job_done(sched_job, fence->error);
> > > - else if (r)
> > > - DRM_DEV_ERROR(sched->dev, "fence add callback 
> > > failed (%d)\n",
> > > -   r);
> > > - } else {
> > > - drm_sched_job_done(sched_job, IS_ERR(fence) ?
> > > -PTR_ERR(fence) : 0);
> > > - }
> > > + atomic_inc(>hw_rq_count);
> > > + drm_sched_job_begin(sched_job);
> > >  
> > > - wake_up(>job_scheduled);
> > > + trace_drm_run_job(sched_job, entity);
> > > + fence = sched->ops->run_job(sched_job);
> > > + complete_all(>entity_idle);
> > > + drm_sched_fence_scheduled(s_fence, fence);
> > > +
> > > + if (!IS_ERR_OR_NULL(fence)) {
> > > + /* Drop for original kref_init of the fence */
> > > + dma_fence_put(fence);
> > > +
> > > + r = dma_fence_add_callback(fence, _job->cb,
> > > +drm_sched_job_done_cb);
> > > + if (r == -ENOENT)
> > > + drm_sched_job_done(sched_job, fence->error);
> > > + else if (r)
> > > + DRM_DEV_ERROR(sched->dev, "fence add callback failed 
> > > (%d)\n", r);
> > > + } else {
> > > + drm_sched_job_done(sched_job, IS_ERR(fence) ?
> > > +PTR_ERR(fence) : 0);
> > >   }  
> > 
> > Just ran into a race condition when using a non-ordered workqueue
> > for drm_sched:
> > 
> > thread Athread B
> > 
> > drm_sched_run_job_work()
> >   drm_sched_job_begin()
> > // inserts jobA in pending_list
> > 
> > 
> > drm_sched_free_job_work()
> >   
> > drm_sched_get_cleanup_job()
> > // check 
> > first job in pending list
> > // if 
> > s_fence->parent == NULL, consider
> > // for 
> > cleanup
> >   
> > ->free_job(jobA)  
> > 
> > drm_sched_job_cleanup()
> >   // set 
> > sched_job->s_fence = NULL
> > 
> > ->run_job()  
> > drm_sched_fence_scheduled()
> 
> Correction: the NULL pointer deref happens in drm_sched_job_done()
> (when the driver returns an error directly) not in
> drm_sched_fence_scheduled(), but the problem remains the same.
> 
> 

Trying to understand this. I don't see how drm_sched_get_cleanup_job can
return a job until dma_fence_is_signaled(>s_fence->finished) is
true. That fence is no signaled until drm_sched_fence_finished(s_fence,
result); called in drm_sched_job_done().

What am I missing here?

Matt

> >   // sched_job->s_fence->parent = parent_fence
> >   // BOOM => NULL pointer deref
> > 
> > For now, I'll just use a dedicated ordered wq, but if we claim
> > multi-threaded workqueues are supported, this is probably worth fixing.
> > I know there's been some discussions about when the timeout should be
> > started, and the job insertion in

1 2 >

1 - 100 of 157 matches

Mail list logo