Re: [PATCH 1/2] drm/v3d: wait for all jobs to finish before unregistering
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(&v3d->mm); >
[PATCH] accel/ivpu: Disable PLL after VPU IP reset during FLR
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
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(&entity->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(&entity->rb_tree_node); > > - if(num_sched_list) > - entity->rq = &sched_list[0]->sched_rq[entity->priority]; > + if (num_sched_list) { > + if (sched_list[0]->sched_policy != > + DRM_SCHED_POLICY_SINGLE_ENTITY) { > + entity->rq = &sched_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->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(&entity->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(&entity->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 *
Re: [PATCH v2 04/11] drm/mediatek: Add secure identify flag and funcution to mtk_drm_plane
Re: [PATCH v6 3/7] drm/sched: Move schedule policy to scheduler
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
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(&submit->sched_job, >>> &ctx->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(&bos[i]->base.base); >>> >>> - err = drm_sched_job_init(&task->base, &context->base, vm); >>> + err = drm_sched_job_init(&task->base, &context->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(&submit->base, queue->entity, queue); >>> + ret = drm_sched_job_init(&submit->base,
Re: [PATCH drm-misc-next v2] drm/sched: implement dynamic job-flow control
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(&submit->sched_job, >>> &ctx->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(&bos[i]->base.base); >>> >>> - err = drm_sched_job_init(&task->base, &context->base, vm); >>> + err = drm_sched_job_init(&task->base, &context->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(&submit->base, queue->entity, queue); >>> + ret = drm_sched_job_init(&submit->base, queue->entity, 1, queue); >>> if (ret) { >>> kfree(submit->hw_fenc
pull for vmemdup-user-array into drm-next
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
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(&mgr->lock); ret = drm_dp_mst_atomic_check_mstb_bw_limit(mgr->mst_primary, mst_state, failing_port); mutex_unlock(&mgr->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
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, &mstb->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 &drm_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
[PATCH 02/29] drm/dp_mst: Add helper to determine if an MST port is downstream of another port
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(&mgr->lock); + ret = drm_dp_mst_port_downstream_of_parent_locked(mgr, port, parent); + mutex_unlock(&mgr->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
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
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
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
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
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
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
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)
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 kms_rotation_
[PATCH v3 04/10] drm/ci: uprev IGT and make sure core_getversion is run
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
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
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
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 drive
[PATCH v3 01/10] drm/ci: uprev mesa version: fix container build & crosvm
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: &drm-ci-project-path mesa/mesa - DRM_CI_COMMIT_SHA: &drm-ci-commit-sha 0dc961645c4f0241f8512cb0ec3ad59635842072 + DRM_CI_COMMIT_SHA: &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
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(&intf->hw, INTF_MISR_CTRL, enable, frame_count); > > > + dpu_hw_setup_misr(&intf->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 leve
Re: [PATCH drm-misc-next v2] drm/sched: implement dynamic job-flow control
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(&submit->sched_job, > > &ctx->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(&bos[i]->base.base); > > > > - err = drm_sched_job_init(&task->base, &context->base, vm); > > + err = drm_sched_job_init(&task->base, &context->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(&submit->base, queue->entity, queue); > > + ret = drm_sched_job_init(&submit->base, queue->entity, 1, queue); > > if (ret) { > > kfree(submit->hw_fence); > > kfree(submit); > > diff
Re: [PATCH] drm/msm/dpu: Fix encoder CRC to account for CTM enablement
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(&intf->hw, INTF_MISR_CTRL, enable, frame_count); > > + dpu_hw_setup_misr(&intf->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
Re: [PATCH v5 0/2] drm/rockchip: vop: Add NV15, NV20 and NV30 support
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
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(&submit->sched_job, > > &ctx->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(&bos[i]->base.base); > > > > - err = drm_sched_job_init(&task->base, &context->base, vm); > > + err = drm_sched_job_init(&task->base, &context->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(&submit->base, queue->entity, queue); > > + ret = drm_sched_job_init(&submit->base, queue->entity, 1, queue); > > if (ret) {
Re: [RFC PATCH v2 04/17] drm/vkms: Add kunit tests for VKMS LUT handling
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(&test_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(&test_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
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(&intf->hw, INTF_MISR_CTRL, enable, frame_count); > + dpu_hw_setup_misr(&intf->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 a/drivers/gpu/drm/msm/disp/dpu
[PATCH] drm/msm/dpu: Fix encoder CRC to account for CTM enablement
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(&intf->hw, INTF_MISR_CTRL, enable, frame_count); + dpu_hw_setup_misr(&intf->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(&ctx->hw, LM_MISR_CTRL, enable, frame_count); + dpu_hw_setup_misr(&ctx->hw, LM_MISR_CTRL, enable,
Re: [PATCH v6 5/7] drm/sched: Split free_job into own work item
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(&sched->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->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, > > > > > &sched_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(&sched->hw_rq_count); > > > > > + drm_sched_job_begin(sched_job); > > > > > > > > > > - wake_up(&sched->job_scheduled); > > > > > + trace_drm_run_job(sched_job, entity); > > > > > + fence = sched->ops->run_job(sched_job); > > > > > + complete_all(&entity->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, &sched_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 =
Re: [PATCH 12/18] dt-bindings: pwm: add binding for mt8365 SoC
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
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
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
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
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
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
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
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 > > Signed-
Re: [PATCH] drm/msm/adreno: Drop WARN_ON from patchid lookup for new GPUs
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
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 @@ * &drm_gem_object list of &drm_gpuvm_bos for an existing instance of this * particular combination. If not existent a new instance is created and linked * to the &drm_gem_object. + * + * &drm_gpuvm_bo structures, since unique for a given &drm_gpuvm, are also used + * as entry for the &drm_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 &drm_gpuvm. For instance, all + * &drm_gem_object's &dma_resv of a given &drm_gpuvm can be locked by calling + * drm_gpuvm_exec_lock(). Once locked drivers can call drm_gpuvm_validate() in + * order to validate all evicted &drm_gem_objects. It is also possible to lock + * additional &drm_gem_objects by providing the corresponding parameters to + * drm_gpuvm_exec_lock() as well as open code the &drm_exec loop while making + * use of helper functions such as drm_gpuvm_prepare_range() or + * drm_gpuvm_prepare_objects(). + * + * Every bound &drm_gem_object is treated as external object when its &dma_resv + * structure is different than the &drm_gpuvm's common &dma_resv structure. */ /** @@ -429,6 +444,20 @@ * Subsequent calls to drm_gpuvm_bo_obtain() for the same &drm_gpuvm and * &drm_gem_object must be able to observe previous creations and destructions * of &drm_gpuvm_bos in order to keep instances unique. + * + * The &drm_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 &DRM_GPUVM_RESV_PROTECTED flag to indicate + * that the corresponding &dma_resv locks are held in order to protect the + * lists. If &DRM_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 &dma_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 &drm_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); \ +
[PATCH drm-misc-next v7 7/7] drm/nouveau: use GPUVM common infrastructure
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 = &bo->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 = &job->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, &uvmm->base) { - if (unlikely(va == &uvmm->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 = &job->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
[PATCH drm-misc-next v7 4/7] drm/gpuvm: add an abstraction for a VM / BO combination
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 @@ * &drm_gem_object, such as the &drm_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 &drm_gem_object each + * &drm_gem_object maintains a list of &drm_gpuvm_bo structures, and each + * &drm_gpuvm_bo contains a list of &drm_gpuva structures. + * + * A &drm_gpuvm_bo is an abstraction that represents a combination of a + * &drm_gpuvm and a &drm_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 + * &drm_gem_object list of &drm_gpuvm_bos for an existing instance of this + * particular combination. If not existent a new instance is created and linked + * to the &drm_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 - * &drm_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 - * &drm_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 &drm_gem_objects GPU VA list is - * accessed by functions such as drm_gpuva_link() or drm_gpuva_unlink(). + * In terms of managing &drm_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 &drm_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 + * &drm_gem_object buffers GPU VA lists and &drm_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 &drm_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 &drm_gpuvm_bo + * the &drm_gpuvm_bo is attached / removed from the &drm_gem_objects gpuva list. + * Subsequent calls to drm_gpuvm_bo_obtain() for the same &drm_gpuvm and + * &drm_gem_object must be able to observe previous creations and destructions + * of &drm_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
[PATCH drm-misc-next v7 6/7] drm/nouveau: make use of the GPUVM's shared dma-resv
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(&bo->base); - else + } else { dma_resv_fini(&bo->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 && &uvmm->resv != nvbo->bo.base.resv) + if (nvbo->no_share && uvmm && + drm_gpuvm_resv(&uvmm->base) != nvbo->bo.base.resv) return -EPERM; ret = ttm_bo_reserve(&nvbo->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 = &uvmm->resv; + resv = drm_gpuvm_resv(&uvmm->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(&uvmm->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(&uvmm->mutex); - dma_resv_init(&uvmm->resv); mt_init_flags(&uvmm->region_mt, MT_FLAGS_LOCK_EXTERN); mt_set_external_lock(&uvmm->region_mt, &uvmm->mutex); @@ -1885,14 +1884,14 @@ nouveau_uvmm_init(struct nouveau_uvmm *uvmm, struct nouveau_cli *cli, kernel_managed_addr, kernel_managed_size, NULL, 0, &cli->uvmm.vmm.vmm); if (ret) - goto out_free_gpuva_mgr; + goto out_gpuvm_fini; cli->uvmm.vmm.cli = cli; mutex_unlock(&cli->mutex); return 0; -out_free_gpuva_mgr: +out_gpuvm_fini: drm_gpuvm_destroy(&uvmm->base); out_unlock: mutex_unlock(&cli->mutex); @@ -1950,6 +1949,4 @@ nouveau_uvmm_fini(struct nouveau_uvmm *uvmm) nouveau_vmm_fini(&uvmm->vmm); drm_gpuvm_destroy(&uvmm->base); mutex_unlock(&cli->mutex); - - dma_resv_
[PATCH drm-misc-next v7 1/7] drm/gpuvm: convert WARN() to drm_WARN() variants
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, &end), - "GPUVA address limited to %zu bytes.\n", sizeof(end)); + return drm_WARN(gpuvm->drm, check_add_overflow(addr, range, &end), + "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 &drm_gpuvm * @gpuvm: pointer to the &drm_gpuvm to initialize * @name: the name of the GPU VA space + * @drm: the &drm_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, * &name 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(&gpuvm->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(&gpuvm->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(&gpuvm->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, &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(&gpuvm->kernel_alloc_node); - WARN(!RB_EMPTY_ROOT(&gpuvm->rb.tree.rb_root), -"GPUVA tree is not empty, potentially leaking memory."); + drm_WARN(gpuvm->drm, !RB_EMPTY_ROOT(&gpuvm->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 == &gpuvm->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
[PATCH drm-misc-next v7 3/7] drm/gpuvm: add drm_gpuvm_flags to drm_gpuvm
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 &drm_gpuvm * @gpuvm: pointer to the &drm_gpuvm to initialize * @name: the name of the GPU VA space + * @flags: the &drm_gpuvm_flags for this GPUVM * @drm: the &drm_device this VM resides in * @r_obj: the resv &drm_gem_object providing the GPUVM's common &dma_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(&gpuvm->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(&uvmm->base, cli->name, drm, r_obj, + drm_gpuvm_init(&uvmm->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 &drm_gpuvm_flags of this GPUVM +*/ + enum drm_gpuvm_flags flags; + /** * @drm: the &drm_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
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 &drm_gpuva * entries from within dma-fence signalling critical sections it is enough to * pre-allocate the &drm_gpuva structures. + * + * &drm_gem_objects which are private to a single VM can share a common + * &dma_resv in order to improve locking efficiency (e.g. with &drm_exec). + * For this purpose drivers must pass a &drm_gem_object to drm_gpuvm_init(), in + * the following called 'resv object', which serves as the container of the + * GPUVM's shared &dma_resv. This resv object can be a driver specific + * &drm_gem_object, such as the &drm_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 &drm_gem_object + * @drm: the drivers &drm_device + * + * Allocates a dummy &drm_gem_object which can be passed to drm_gpuvm_init() in + * order to serve as root GEM object providing the &drm_resv shared across + * &drm_gem_objects local to a single GPUVM. + * + * Returns: the &drm_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 = &drm_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 &drm_gpuvm * @gpuvm: pointer to the &drm_gpuvm to initialize * @name: the name of the GPU VA space * @drm: the &drm_device this VM resides in + * @r_obj: the resv &drm_gem_object providing the GPUVM's common &dma_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(&gpuvm->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(&uvmm->mutex); dma_resv_init(&uvmm->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; + g
[PATCH drm-misc-next v7 0/7] [RFC] DRM GPUVM features
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 succ
Re: [PATCH] drm/msm/adreno: Drop WARN_ON from patchid lookup for new GPUs
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
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
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 *)&lcd800x1280_rightside_up, + }, {/* AYN Loki Max */ + .matches = { + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ayn"), + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Loki Max"), + }, + .driver_data = (void *)&lcd1080x1920_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
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 *)&lcd800x1280_rightside_up, + }, {/* AYN Loki Zero */ + .matches = { + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ayn"), + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Loki Zero"), + }, + .driver_data = (void *)&lcd1080x1920_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
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
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(&tcpm->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
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 > --- a/drivers/gpu/drm/rockchip/rockchip_vop_r
Re: [PATCH v5 1/2] drm/fourcc: Add NV20 and NV30 YUV formats
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
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
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
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
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
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 = <&mmsys CLK_MM_DISP_PWM026M>, > <&mmsys CLK_MM_DISP_PWM0MM>; > clock-names = "main", "mm"; > +power-domains = <&spm MT8173_POWER_DOMAIN_MM>; > }; > > -- > 2.25.1 > signature.asc Description: PGP signature
Re: [PATCH 12/18] dt-bindings: pwm: add binding for mt8365 SoC
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
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
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
> -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
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
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
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
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(&fdev->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 = &buf_mock; + + gem_obj = drm_gem_shmem_prime_import_sg_table(&fdev->drm_dev, &attach_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(&fdev->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_vm
[PATCH] drm: docs: Remove item from TODO list
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
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 = <&pwm1 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
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
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 > e
[RFC] Clean up check for already prepared panel
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 = &ctx->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
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
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 = &ctx->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
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 = <&hdmi_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 = <&pio 129 GPIO_ACTIVE_HIGH>; + regulator-max-microvolt = <500>; + regulator-min-microvolt = <500>; + regulator-name = "vsys_lcm"; + }; +}; + +&dpi0 { + pinctrl-0 = <&dpi_default_pins>; + pinctrl-1 = <&dpi_idle_pins>; + pinctrl-names = "default", "sleep"; + status = "okay"; + + port { + dpi_out: endpoint { + remote-endpoint = <&it66121_in>; + }; + }; +}; + + +&dsi0 { + #address-cells = <1>; + #size-cells = <0>; + status = "okay"; + + panel@0 { + compatible = "startek,kd070fhfid015"; + status = "okay"; + reg = <0>; + enable-gpios = <&pio 67 GPIO_ACTIVE_HIGH>; + reset-gpios = <&pio 20 GPIO_ACTIVE_HIGH>; + iovcc-supply = <&mt6357_vsim1_reg>; + power-supply = <&vsys_lcm_reg>; + + port { + panel_in: endpoint { + remote-endpoint = <&dsi_out>; + }; + }; + }; + + port { + dsi_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; }; &cpu0 { @@ -138,6 +201,50 @@ &i2c0 { status = "okay"; }; +&i2c1 { + #address-cells = <1>; + #size-cells = <0>; + clock-div = <2>; + clock-frequency = <10>; + pinctrl-0 = <&i2c1_pins>; + pinctrl-names = "default"; + status = "okay"; + + it66121hdmitx: it66121hdmitx@4c { + #sound-dai-cells = <0>; + compatible = "ite,it66121"; + interrupt-parent = <&pio>; + interrupts = <68 IRQ_TYPE_LEVEL_LOW>; + pinctrl-0 = <&ite_pins>; + pinctrl-names = "default"; + reg = <0x4c>; + reset-gpios = <&pio 69 GPIO_ACTIVE_LOW>; + vcn18-supply = <&mt6357_vsim2_reg>; + vcn33-supply = <&mt6357_vibr_reg>; + vrf12-supply = <&mt6357_vrf12_reg>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + it66121_in: endpoint { + bus-width = <12>; + remote-endpoint = <&dpi_out>; + }; + }; + + port@1 { + reg = <1>; + hdmi_connector_out: endpoint { + remote-endpoint = <&hdmi_connector_in>; + }; + }; + }; + }; +}; + &mmc0 { assigned-clock-parents = <&topckgen CLK_TOP_MSDCPLL>; assigned-clocks = <&topckgen CLK_TOP_MSDC50_0_SEL>; @@ -180,7 +287,55 @@ &mt6357_pmic { #interrupt-cells = <2>; }; +&mt6357_vsim1_reg { + regulator-min-microvolt = <180>; + regulator-max-microvolt = <180>; +}; + &pio { + dpi_default_pins: dpi-default-pins { + pins { + pinmux = , +, +, +, +
[PATCH 02/18] dt-bindings: display: mediatek: ccorr: add binding for MT8365 SoC
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
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
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
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
- 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 = &aal0; + ccorr0 = &ccorr0; + color0 = &color0; + dither0 = &dither0; + dpi0 = &dpi0; + dsi0 = &dsi0; + gamma0 = &gamma0; + ovl0 = &ovl0; + rdma0 = &rdma0; + rdma1 = &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 = <&topckgen CLK_TOP_DISP_PWM_SEL>, +<&infracfg CLK_IFR_DISP_PWM>; + power-domains = <&spm 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 = <&clk26m>; + #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 = <&spm 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 = <&mmsys CLK_MM_MM_DISP_OVL0>; + interrupts = ; + iommus = <&iommu M4U_PORT_DISP_OVL0>; + power-domains = <&spm MT8365_POWER_DOMAIN_MM>; + }; + + rdma0: rdma@1400d000 { + compatible = "mediatek,mt8365-disp-rdma", +"mediatek,mt8183-disp-rdma"; + reg = <0 0x1400d000 0 0x1000>; + clocks = <&mmsys CLK_MM_MM_DISP_RDMA0>; + interrupts = ; + iommus = <&iommu M4U_PORT_DISP_RDMA0>; + mediatek,rdma-fifo-size = <5120>; + power-domains = <&spm MT8365_POWER_DOMAIN_MM>; + }; + + color0: color@1400f000 { + compatible = "mediatek,mt8365-disp-color", +"mediatek,mt8173-dis
[PATCH 06/18] dt-bindings: display: mediatek: dpi: add power-domains property
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 = <&spm MT8173_POWER_DOMAIN_MM>; clocks = <&mmsys CLK_MM_DPI_PIXEL>, <&mmsys CLK_MM_DPI_ENGINE>, <&apmixedsys CLK_APMIXED_TVDPLL>; -- 2.25.1
[PATCH 03/18] dt-bindings: display: mediatek: color: add binding for MT8365 SoC
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
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 = &mt2701_mmsys_driver_data}, @@ -336,6 +360,8 @@ static const struct of_device_id mtk_drm_of_ids[] = { .data = &mt8195_vdosys0_driver_data}, { .compatible = "mediatek,mt8195-vdosys1", .data = &mt8195_vdosys1_driver_data}, + { .compatible = "mediatek,mt8365-mmsys", + .data = &mt8365_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
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
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
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
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
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 = <&mmsys CLK_MM_DISP_PWM026M>, <&mmsys CLK_MM_DISP_PWM0MM>; clock-names = "main", "mm"; +power-domains = <&spm MT8173_POWER_DOMAIN_MM>; }; -- 2.25.1
[PATCH 07/18] dt-bindings: display: mediatek: dpi: add binding for MT8365
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
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
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
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
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
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
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(&sched->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->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, > > > > &sched_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(&sched->hw_rq_count); > > > > + drm_sched_job_begin(sched_job); > > > > > > > > - wake_up(&sched->job_scheduled); > > > > + trace_drm_run_job(sched_job, entity); > > > > + fence = sched->ops->run_job(sched_job); > > > > + complete_all(&entity->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, &sched_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_
Re: [PATCH v6 5/7] drm/sched: Split free_job into own work item
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(&sched->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->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, &sched_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(&sched->hw_rq_count); > > > + drm_sched_job_begin(sched_job); > > > > > > - wake_up(&sched->job_scheduled); > > > + trace_drm_run_job(sched_job, entity); > > > + fence = sched->ops->run_job(sched_job); > > > + complete_all(&entity->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, &sched_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(&job->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 timeo