Re: [PATCH] drm/komeda: remove unused struct 'gamma_curve_segment'
On Thu, May 16, 2024 at 02:37:24PM +0100, li...@treblig.org wrote:
> From: "Dr. David Alan Gilbert"
>
> 'gamma_curve_segment' looks like it has never been used.
> Remove it.
>
> Signed-off-by: Dr. David Alan Gilbert
Acked-by: Liviu Dudau
Thanks for the clean up!
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> index d8e449e6ebda..50cb8f7ee6b2 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_color_mgmt.c
> @@ -72,11 +72,6 @@ struct gamma_curve_sector {
> u32 segment_width;
> };
>
> -struct gamma_curve_segment {
> - u32 start;
> - u32 end;
> -};
> -
> static struct gamma_curve_sector sector_tbl[] = {
> { 0,4, 4 },
> { 16, 4, 4 },
> --
> 2.45.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH v2] drm/arm/comeda: don't use confusing 'timeout' variable name
On Tue, May 07, 2024 at 11:02:01AM +0200, Wolfram Sang wrote:
> There is a confusing pattern in the kernel to use a variable named 'timeout'
> to
> store the result of wait_for_completion_timeout() causing patterns like:
>
> timeout = wait_for_completion_timeout(...)
> if (!timeout) return -ETIMEDOUT;
>
> with all kinds of permutations. Check the return value directly to drop
> 'timeout' which also fixes its wrong type.
>
> Signed-off-by: Wolfram Sang
Acked-by: Liviu Dudau
I will change the subject line to s/comeda/komeda/ when merging it.
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 2c661f28410e..9bec59cf9c06 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -294,7 +294,6 @@ komeda_crtc_flush_and_wait_for_flip_done(struct
> komeda_crtc *kcrtc,
> struct komeda_dev *mdev = kcrtc->master->mdev;
> struct completion *flip_done;
> struct completion temp;
> - int timeout;
>
> /* if caller doesn't send a flip_done, use a private flip_done */
> if (input_flip_done) {
> @@ -308,8 +307,7 @@ komeda_crtc_flush_and_wait_for_flip_done(struct
> komeda_crtc *kcrtc,
> mdev->funcs->flush(mdev, kcrtc->master->id, 0);
>
> /* wait the flip take affect.*/
> - timeout = wait_for_completion_timeout(flip_done, HZ);
> - if (timeout == 0) {
> + if (wait_for_completion_timeout(flip_done, HZ) == 0) {
> DRM_ERROR("wait pipe%d flip done timeout\n", kcrtc->master->id);
> if (!input_flip_done) {
> unsigned long flags;
> --
> 2.43.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH 1/1] drm: arm: display: komeda: komeda_crtc: use 'time_left' variable with wait_for_completion_timeout()
On Thu, May 02, 2024 at 11:02:53PM +0200, Wolfram Sang wrote:
> There is a confusing pattern in the kernel to use a variable named 'timeout'
> to
> store the result of wait_for_completion_timeout() causing patterns like:
>
> timeout = wait_for_completion_timeout(...)
> if (!timeout) return -ETIMEDOUT;
>
> with all kinds of permutations. Use 'time_left' as a variable to make the code
> self explaining.
>
> Fix to the proper variable type 'unsigned long' while here.
>
> Signed-off-by: Wolfram Sang
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_crtc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 2c661f28410e..c867acb737d6 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -294,7 +294,7 @@ komeda_crtc_flush_and_wait_for_flip_done(struct
> komeda_crtc *kcrtc,
> struct komeda_dev *mdev = kcrtc->master->mdev;
> struct completion *flip_done;
> struct completion temp;
> - int timeout;
> + unsigned long time_left;
>
> /* if caller doesn't send a flip_done, use a private flip_done */
> if (input_flip_done) {
> @@ -308,8 +308,8 @@ komeda_crtc_flush_and_wait_for_flip_done(struct
> komeda_crtc *kcrtc,
> mdev->funcs->flush(mdev, kcrtc->master->id, 0);
>
> /* wait the flip take affect.*/
> - timeout = wait_for_completion_timeout(flip_done, HZ);
> - if (timeout == 0) {
> + time_left = wait_for_completion_timeout(flip_done, HZ);
> + if (time_left == 0) {
Honestly, if the name of the variable is confusing I would get rid of it
completely. Can you
send a patch that removes the timeout variable and here just does:
if (wait_for_completion_timeout(flip_done, HZ) == 0) {
Thanks,
Liviu
> DRM_ERROR("wait pipe%d flip done timeout\n", kcrtc->master->id);
> if (!input_flip_done) {
> unsigned long flags;
> --
> 2.43.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH 4/4] drm/panthor: Call panthor_sched_post_reset() even if the reset failed
On Thu, May 02, 2024 at 08:38:12PM +0200, Boris Brezillon wrote:
> We need to undo what was done in panthor_sched_pre_reset() even if the
> reset failed. We just flag all previously running groups as terminated
> when that happens to unblock things.
>
> Signed-off-by: Boris Brezillon
Reviewed-by: Liviu Dudau
> ---
> drivers/gpu/drm/panthor/panthor_device.c | 7 +--
> drivers/gpu/drm/panthor/panthor_sched.c | 19 ++-
> drivers/gpu/drm/panthor/panthor_sched.h | 2 +-
> 3 files changed, 16 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_device.c
> b/drivers/gpu/drm/panthor/panthor_device.c
> index 4c5b54e7abb7..4082c8f2951d 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.c
> +++ b/drivers/gpu/drm/panthor/panthor_device.c
> @@ -129,13 +129,8 @@ static void panthor_device_reset_work(struct work_struct
> *work)
> panthor_gpu_l2_power_on(ptdev);
> panthor_mmu_post_reset(ptdev);
> ret = panthor_fw_post_reset(ptdev);
> - if (ret)
> - goto out_dev_exit;
> -
> atomic_set(>reset.pending, 0);
> - panthor_sched_post_reset(ptdev);
> -
> -out_dev_exit:
> + panthor_sched_post_reset(ptdev, ret != 0);
> drm_dev_exit(cookie);
>
> if (ret) {
> diff --git a/drivers/gpu/drm/panthor/panthor_sched.c
> b/drivers/gpu/drm/panthor/panthor_sched.c
> index 6ea094b00cf9..fc43ff62c77d 100644
> --- a/drivers/gpu/drm/panthor/panthor_sched.c
> +++ b/drivers/gpu/drm/panthor/panthor_sched.c
> @@ -2728,15 +2728,22 @@ void panthor_sched_pre_reset(struct panthor_device
> *ptdev)
> mutex_unlock(>reset.lock);
> }
>
> -void panthor_sched_post_reset(struct panthor_device *ptdev)
> +void panthor_sched_post_reset(struct panthor_device *ptdev, bool
> reset_failed)
> {
> struct panthor_scheduler *sched = ptdev->scheduler;
> struct panthor_group *group, *group_tmp;
>
> mutex_lock(>reset.lock);
>
> - list_for_each_entry_safe(group, group_tmp,
> >reset.stopped_groups, run_node)
> + list_for_each_entry_safe(group, group_tmp,
> >reset.stopped_groups, run_node) {
> + /* Consider all previously running group as terminated if the
> + * reset failed.
> + */
> + if (reset_failed)
> + group->state = PANTHOR_CS_GROUP_TERMINATED;
> +
> panthor_group_start(group);
> + }
>
> /* We're done resetting the GPU, clear the reset.in_progress bit so we
> can
>* kick the scheduler.
> @@ -2744,9 +2751,11 @@ void panthor_sched_post_reset(struct panthor_device
> *ptdev)
> atomic_set(>reset.in_progress, false);
> mutex_unlock(>reset.lock);
>
> - sched_queue_delayed_work(sched, tick, 0);
> -
> - sched_queue_work(sched, sync_upd);
> + /* No need to queue a tick and update syncs if the reset failed. */
> + if (!reset_failed) {
> + sched_queue_delayed_work(sched, tick, 0);
> + sched_queue_work(sched, sync_upd);
> + }
> }
>
> static void group_sync_upd_work(struct work_struct *work)
> diff --git a/drivers/gpu/drm/panthor/panthor_sched.h
> b/drivers/gpu/drm/panthor/panthor_sched.h
> index 66438b1f331f..3a30d2328b30 100644
> --- a/drivers/gpu/drm/panthor/panthor_sched.h
> +++ b/drivers/gpu/drm/panthor/panthor_sched.h
> @@ -40,7 +40,7 @@ void panthor_group_pool_destroy(struct panthor_file *pfile);
> int panthor_sched_init(struct panthor_device *ptdev);
> void panthor_sched_unplug(struct panthor_device *ptdev);
> void panthor_sched_pre_reset(struct panthor_device *ptdev);
> -void panthor_sched_post_reset(struct panthor_device *ptdev);
> +void panthor_sched_post_reset(struct panthor_device *ptdev, bool
> reset_failed);
> void panthor_sched_suspend(struct panthor_device *ptdev);
> void panthor_sched_resume(struct panthor_device *ptdev);
>
> --
> 2.44.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH 3/4] drm/panthor: Reset the FW VM to NULL on unplug
On Fri, May 03, 2024 at 10:22:13AM +0100, Steven Price wrote: > On 02/05/2024 19:38, Boris Brezillon wrote: > > This way get NULL derefs instead of use-after-free if the FW VM is > > referenced after the device has been unplugged. > > > > Signed-off-by: Boris Brezillon > > Reviewed-by: Steven Price Acked-by: Liviu Dudau > > > --- > > drivers/gpu/drm/panthor/panthor_fw.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/gpu/drm/panthor/panthor_fw.c > > b/drivers/gpu/drm/panthor/panthor_fw.c > > index b41685304a83..93165961a6b5 100644 > > --- a/drivers/gpu/drm/panthor/panthor_fw.c > > +++ b/drivers/gpu/drm/panthor/panthor_fw.c > > @@ -1141,6 +1141,7 @@ void panthor_fw_unplug(struct panthor_device *ptdev) > > * state to keep the active_refcnt balanced. > > */ > > panthor_vm_put(ptdev->fw->vm); > > + ptdev->fw->vm = NULL; > > > > panthor_gpu_power_off(ptdev, L2, ptdev->gpu_info.l2_present, 2); > > } > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯
Re: [PATCH 2/4] drm/panthor: Keep a ref to the VM at the panthor_kernel_bo level
On Thu, May 02, 2024 at 08:38:10PM +0200, Boris Brezillon wrote:
> Avoids use-after-free situations when panthor_fw_unplug() is called
> and the kernel BO was mapped to the FW VM.
>
> Signed-off-by: Boris Brezillon
Reviewed-by: Liviu Dudau
> ---
> drivers/gpu/drm/panthor/panthor_fw.c| 4 ++--
> drivers/gpu/drm/panthor/panthor_gem.c | 8 +---
> drivers/gpu/drm/panthor/panthor_gem.h | 8 ++--
> drivers/gpu/drm/panthor/panthor_heap.c | 8
> drivers/gpu/drm/panthor/panthor_sched.c | 11 +--
> 5 files changed, 22 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_fw.c
> b/drivers/gpu/drm/panthor/panthor_fw.c
> index 181395e2859a..b41685304a83 100644
> --- a/drivers/gpu/drm/panthor/panthor_fw.c
> +++ b/drivers/gpu/drm/panthor/panthor_fw.c
> @@ -453,7 +453,7 @@ panthor_fw_alloc_queue_iface_mem(struct panthor_device
> *ptdev,
>
> ret = panthor_kernel_bo_vmap(mem);
> if (ret) {
> - panthor_kernel_bo_destroy(panthor_fw_vm(ptdev), mem);
> + panthor_kernel_bo_destroy(mem);
> return ERR_PTR(ret);
> }
>
> @@ -1133,7 +1133,7 @@ void panthor_fw_unplug(struct panthor_device *ptdev)
> panthor_fw_stop(ptdev);
>
> list_for_each_entry(section, >fw->sections, node)
> - panthor_kernel_bo_destroy(panthor_fw_vm(ptdev), section->mem);
> + panthor_kernel_bo_destroy(section->mem);
>
> /* We intentionally don't call panthor_vm_idle() and let
>* panthor_mmu_unplug() release the AS we acquired with
> diff --git a/drivers/gpu/drm/panthor/panthor_gem.c
> b/drivers/gpu/drm/panthor/panthor_gem.c
> index d6483266d0c2..38f560864879 100644
> --- a/drivers/gpu/drm/panthor/panthor_gem.c
> +++ b/drivers/gpu/drm/panthor/panthor_gem.c
> @@ -26,18 +26,18 @@ static void panthor_gem_free_object(struct drm_gem_object
> *obj)
>
> /**
> * panthor_kernel_bo_destroy() - Destroy a kernel buffer object
> - * @vm: The VM this BO was mapped to.
> * @bo: Kernel buffer object to destroy. If NULL or an ERR_PTR(), the
> destruction
> * is skipped.
> */
> -void panthor_kernel_bo_destroy(struct panthor_vm *vm,
> -struct panthor_kernel_bo *bo)
> +void panthor_kernel_bo_destroy(struct panthor_kernel_bo *bo)
> {
> + struct panthor_vm *vm;
> int ret;
>
> if (IS_ERR_OR_NULL(bo))
> return;
>
> + vm = bo->vm;
> panthor_kernel_bo_vunmap(bo);
>
> if (drm_WARN_ON(bo->obj->dev,
> @@ -53,6 +53,7 @@ void panthor_kernel_bo_destroy(struct panthor_vm *vm,
> drm_gem_object_put(bo->obj);
>
> out_free_bo:
> + panthor_vm_put(vm);
> kfree(bo);
> }
>
> @@ -106,6 +107,7 @@ panthor_kernel_bo_create(struct panthor_device *ptdev,
> struct panthor_vm *vm,
> if (ret)
> goto err_free_va;
>
> + kbo->vm = panthor_vm_get(vm);
> bo->exclusive_vm_root_gem = panthor_vm_root_gem(vm);
> drm_gem_object_get(bo->exclusive_vm_root_gem);
> bo->base.base.resv = bo->exclusive_vm_root_gem->resv;
> diff --git a/drivers/gpu/drm/panthor/panthor_gem.h
> b/drivers/gpu/drm/panthor/panthor_gem.h
> index 3bccba394d00..e43021cf6d45 100644
> --- a/drivers/gpu/drm/panthor/panthor_gem.h
> +++ b/drivers/gpu/drm/panthor/panthor_gem.h
> @@ -61,6 +61,11 @@ struct panthor_kernel_bo {
>*/
> struct drm_gem_object *obj;
>
> + /**
> + * @vm: VM this private buffer is attached to.
> + */
> + struct panthor_vm *vm;
> +
> /**
>* @va_node: VA space allocated to this GEM.
>*/
> @@ -136,7 +141,6 @@ panthor_kernel_bo_create(struct panthor_device *ptdev,
> struct panthor_vm *vm,
>size_t size, u32 bo_flags, u32 vm_map_flags,
>u64 gpu_va);
>
> -void panthor_kernel_bo_destroy(struct panthor_vm *vm,
> -struct panthor_kernel_bo *bo);
> +void panthor_kernel_bo_destroy(struct panthor_kernel_bo *bo);
>
> #endif /* __PANTHOR_GEM_H__ */
> diff --git a/drivers/gpu/drm/panthor/panthor_heap.c
> b/drivers/gpu/drm/panthor/panthor_heap.c
> index 143fa35f2e74..65921296a18c 100644
> --- a/drivers/gpu/drm/panthor/panthor_heap.c
> +++ b/drivers/gpu/drm/panthor/panthor_heap.c
> @@ -127,7 +127,7 @@ static void panthor_free_heap_chunk(struct panthor_vm *vm,
> heap->chunk_count--;
> mutex_unlock(>lock);
>
> - panthor_kernel_bo_destroy(vm, chunk->bo);
> + panthor_kernel_bo_destroy(chunk->bo);
> kfree(chunk);
>
Re: [PATCH 1/4] drm/panthor: Force an immediate reset on unrecoverable faults
On Thu, May 02, 2024 at 08:38:09PM +0200, Boris Brezillon wrote:
> If the FW reports an unrecoverable fault, we need to reset the GPU
> before we can start re-using it again.
>
> Signed-off-by: Boris Brezillon
Reviewed-by: Liviu Dudau
> ---
> drivers/gpu/drm/panthor/panthor_device.c | 1 +
> drivers/gpu/drm/panthor/panthor_device.h | 1 +
> drivers/gpu/drm/panthor/panthor_sched.c | 11 ++-
> 3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_device.c
> b/drivers/gpu/drm/panthor/panthor_device.c
> index 75276cbeba20..4c5b54e7abb7 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.c
> +++ b/drivers/gpu/drm/panthor/panthor_device.c
> @@ -293,6 +293,7 @@ static const struct panthor_exception_info
> panthor_exception_infos[] = {
> PANTHOR_EXCEPTION(ACTIVE),
> PANTHOR_EXCEPTION(CS_RES_TERM),
> PANTHOR_EXCEPTION(CS_CONFIG_FAULT),
> + PANTHOR_EXCEPTION(CS_UNRECOVERABLE),
> PANTHOR_EXCEPTION(CS_ENDPOINT_FAULT),
> PANTHOR_EXCEPTION(CS_BUS_FAULT),
> PANTHOR_EXCEPTION(CS_INSTR_INVALID),
> diff --git a/drivers/gpu/drm/panthor/panthor_device.h
> b/drivers/gpu/drm/panthor/panthor_device.h
> index 2fdd671b38fd..e388c0472ba7 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.h
> +++ b/drivers/gpu/drm/panthor/panthor_device.h
> @@ -216,6 +216,7 @@ enum drm_panthor_exception_type {
> DRM_PANTHOR_EXCEPTION_CS_RES_TERM = 0x0f,
> DRM_PANTHOR_EXCEPTION_MAX_NON_FAULT = 0x3f,
> DRM_PANTHOR_EXCEPTION_CS_CONFIG_FAULT = 0x40,
> + DRM_PANTHOR_EXCEPTION_CS_UNRECOVERABLE = 0x41,
> DRM_PANTHOR_EXCEPTION_CS_ENDPOINT_FAULT = 0x44,
> DRM_PANTHOR_EXCEPTION_CS_BUS_FAULT = 0x48,
> DRM_PANTHOR_EXCEPTION_CS_INSTR_INVALID = 0x49,
> diff --git a/drivers/gpu/drm/panthor/panthor_sched.c
> b/drivers/gpu/drm/panthor/panthor_sched.c
> index 7f16a4a14e9a..1d2708c3ab0a 100644
> --- a/drivers/gpu/drm/panthor/panthor_sched.c
> +++ b/drivers/gpu/drm/panthor/panthor_sched.c
> @@ -1281,7 +1281,16 @@ cs_slot_process_fatal_event_locked(struct
> panthor_device *ptdev,
> if (group)
> group->fatal_queues |= BIT(cs_id);
>
> - sched_queue_delayed_work(sched, tick, 0);
> + if (CS_EXCEPTION_TYPE(fatal) == DRM_PANTHOR_EXCEPTION_CS_UNRECOVERABLE)
> {
> + /* If this exception is unrecoverable, queue a reset, and make
> + * sure we stop scheduling groups until the reset has happened.
> + */
> + panthor_device_schedule_reset(ptdev);
> + cancel_delayed_work(>tick_work);
> + } else {
> + sched_queue_delayed_work(sched, tick, 0);
> + }
> +
> drm_warn(>base,
>"CSG slot %d CS slot: %d\n"
>"CS_FATAL.EXCEPTION_TYPE: 0x%x (%s)\n"
> --
> 2.44.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH v4 5/5] drm/panthor: Document drm_panthor_tiler_heap_destroy::handle validity constraints
On Thu, May 02, 2024 at 06:51:58PM +0200, Boris Brezillon wrote:
> Make sure the user is aware that drm_panthor_tiler_heap_destroy::handle
> must be a handle previously returned by
> DRM_IOCTL_PANTHOR_TILER_HEAP_CREATE.
>
> v4:
> - Add Steve's R-b
>
> v3:
> - New patch
>
> Signed-off-by: Boris Brezillon
> Reviewed-by: Steven Price
Reviewed-by: Liviu Dudau
> ---
> include/uapi/drm/panthor_drm.h | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/include/uapi/drm/panthor_drm.h b/include/uapi/drm/panthor_drm.h
> index b8220d2e698f..aaed8e12ad0b 100644
> --- a/include/uapi/drm/panthor_drm.h
> +++ b/include/uapi/drm/panthor_drm.h
> @@ -939,7 +939,11 @@ struct drm_panthor_tiler_heap_create {
> * struct drm_panthor_tiler_heap_destroy - Arguments passed to
> DRM_IOCTL_PANTHOR_TILER_HEAP_DESTROY
> */
> struct drm_panthor_tiler_heap_destroy {
> - /** @handle: Handle of the tiler heap to destroy */
> + /**
> + * @handle: Handle of the tiler heap to destroy.
> + *
> + * Must be a valid heap handle returned by
> DRM_IOCTL_PANTHOR_TILER_HEAP_CREATE.
> + */
> __u32 handle;
>
> /** @pad: Padding field, MBZ. */
> --
> 2.44.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH v4 4/5] drm/panthor: Fix an off-by-one in the heap context retrieval logic
On Thu, May 02, 2024 at 06:51:57PM +0200, Boris Brezillon wrote:
> The heap ID is used to index the heap context pool, and allocating
> in the [1:MAX_HEAPS_PER_POOL] leads to an off-by-one. This was
> originally to avoid returning a zero heap handle, but given the handle
> is formed with (vm_id << 16) | heap_id, with vm_id > 0, we already can't
> end up with a valid heap handle that's zero.
>
> v4:
> - s/XA_FLAGS_ALLOC1/XA_FLAGS_ALLOC/
>
> v3:
> - Allocate in the [0:MAX_HEAPS_PER_POOL-1] range
>
> v2:
> - New patch
>
> Fixes: 9cca48fa4f89 ("drm/panthor: Add the heap logical block")
> Reported-by: Eric Smith
> Signed-off-by: Boris Brezillon
> Tested-by: Eric Smith
Reviewed-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/panthor/panthor_heap.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_heap.c
> b/drivers/gpu/drm/panthor/panthor_heap.c
> index b0fc5b9ee847..95a1c6c9f35e 100644
> --- a/drivers/gpu/drm/panthor/panthor_heap.c
> +++ b/drivers/gpu/drm/panthor/panthor_heap.c
> @@ -323,7 +323,8 @@ int panthor_heap_create(struct panthor_heap_pool *pool,
> if (!pool->vm) {
> ret = -EINVAL;
> } else {
> - ret = xa_alloc(>xa, , heap, XA_LIMIT(1,
> MAX_HEAPS_PER_POOL), GFP_KERNEL);
> + ret = xa_alloc(>xa, , heap,
> +XA_LIMIT(0, MAX_HEAPS_PER_POOL - 1), GFP_KERNEL);
> if (!ret) {
> void *gpu_ctx = panthor_get_heap_ctx(pool, id);
>
> @@ -543,7 +544,7 @@ panthor_heap_pool_create(struct panthor_device *ptdev,
> struct panthor_vm *vm)
> pool->vm = vm;
> pool->ptdev = ptdev;
> init_rwsem(>lock);
> - xa_init_flags(>xa, XA_FLAGS_ALLOC1);
> + xa_init_flags(>xa, XA_FLAGS_ALLOC);
> kref_init(>refcount);
>
> pool->gpu_contexts = panthor_kernel_bo_create(ptdev, vm, bosize,
> --
> 2.44.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH] drm/panthor: Fix the FW reset logic
On Tue, Apr 30, 2024 at 01:37:27PM +0200, Boris Brezillon wrote:
> In the post_reset function, if the fast reset didn't succeed, we
> are not clearing the fast_reset flag, which prevents firmware
> sections from being reloaded. While at it, use panthor_fw_stop()
> instead of manually writing DISABLE to the MCU_CONTROL register.
>
> Fixes: 2718d91816ee ("drm/panthor: Add the FW logical block")
> Signed-off-by: Boris Brezillon
Reviewed-by: Liviu Dudau
> ---
> drivers/gpu/drm/panthor/panthor_fw.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_fw.c
> b/drivers/gpu/drm/panthor/panthor_fw.c
> index 181395e2859a..fedf9627453f 100644
> --- a/drivers/gpu/drm/panthor/panthor_fw.c
> +++ b/drivers/gpu/drm/panthor/panthor_fw.c
> @@ -1083,10 +1083,11 @@ int panthor_fw_post_reset(struct panthor_device
> *ptdev)
> if (!ret)
> goto out;
>
> - /* Force a disable, so we get a fresh boot on the next
> - * panthor_fw_start() call.
> + /* Forcibly reset the MCU and force a slow reset, so we get a
> + * fresh boot on the next panthor_fw_start() call.
>*/
> - gpu_write(ptdev, MCU_CONTROL, MCU_CONTROL_DISABLE);
> + panthor_fw_stop(ptdev);
> + ptdev->fw->fast_reset = false;
> drm_err(>base, "FW fast reset failed, trying a slow
> reset");
> }
>
> --
> 2.44.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH v2 4/4] drm/panthor: Fix an off-by-one in the heap context retrieval logic
On Tue, Apr 30, 2024 at 01:28:52PM +0200, Boris Brezillon wrote:
> ID 0 is reserved to encode 'no-tiler-heap', the heap ID range is
> [1:MAX_HEAPS_PER_POOL], which we occasionally need to turn into an index
> in the [0:MAX_HEAPS_PER_POOL-1] when we want to access the context object.
>
> v2:
> - New patch
>
> Fixes: 9cca48fa4f89 ("drm/panthor: Add the heap logical block")
> Reported-by: Eric Smith
> Signed-off-by: Boris Brezillon
> Tested-by: Eric Smith
> ---
> drivers/gpu/drm/panthor/panthor_heap.c | 35 +++---
> 1 file changed, 26 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_heap.c
> b/drivers/gpu/drm/panthor/panthor_heap.c
> index 683bb94761bc..b1a7dbf25fb2 100644
> --- a/drivers/gpu/drm/panthor/panthor_heap.c
> +++ b/drivers/gpu/drm/panthor/panthor_heap.c
> @@ -109,7 +109,11 @@ static int panthor_heap_ctx_stride(struct panthor_device
> *ptdev)
>
> static int panthor_get_heap_ctx_offset(struct panthor_heap_pool *pool, int
> id)
Can we make id and the return type here u32? I keep thinking about returning
large negative
values here and how they can end up being exploited.
> {
> - return panthor_heap_ctx_stride(pool->ptdev) * id;
> + /* ID 0 is reserved to encode 'no-tiler-heap', the valid range
> + * is [1:MAX_HEAPS_PER_POOL], which we need to turn into a
> + * [0:MAX_HEAPS_PER_POOL-1] context index, hence the minus one here.
> + */
> + return panthor_heap_ctx_stride(pool->ptdev) * (id - 1);
> }
>
> static void *panthor_get_heap_ctx(struct panthor_heap_pool *pool, int id)
> @@ -118,6 +122,21 @@ static void *panthor_get_heap_ctx(struct
> panthor_heap_pool *pool, int id)
> panthor_get_heap_ctx_offset(pool, id);
> }
>
> +static int panthor_get_heap_ctx_id(struct panthor_heap_pool *pool,
> +u64 heap_ctx_gpu_va)
> +{
> + u64 offset = heap_ctx_gpu_va -
> panthor_kernel_bo_gpuva(pool->gpu_contexts);
> + u32 heap_idx = (u32)offset / panthor_heap_ctx_stride(pool->ptdev);
> +
> + if (offset > U32_MAX || heap_idx >= MAX_HEAPS_PER_POOL)
> + return -EINVAL;
> +
> + /* ID 0 is reserved to encode 'no-tiler-heap', the valid range
> + * is [1:MAX_HEAPS_PER_POOL], hence the plus one here.
> + */
> + return heap_idx + 1;
> +}
> +
> static void panthor_free_heap_chunk(struct panthor_vm *vm,
> struct panthor_heap *heap,
> struct panthor_heap_chunk *chunk)
> @@ -364,14 +383,13 @@ int panthor_heap_return_chunk(struct panthor_heap_pool
> *pool,
> u64 heap_gpu_va,
> u64 chunk_gpu_va)
> {
> - u64 offset = heap_gpu_va - panthor_kernel_bo_gpuva(pool->gpu_contexts);
> - u32 heap_id = (u32)offset / panthor_heap_ctx_stride(pool->ptdev);
> + int heap_id = panthor_get_heap_ctx_id(pool, heap_gpu_va);
I would keep heap_id here u32. Why do we need to change it? Also, I don't see
how
panthor_get_heap_ctx_id() can ever return negative values unless we expect
MAX_HEAPS_PER_POOL
to be S32_MAX at some moment.
> struct panthor_heap_chunk *chunk, *tmp, *removed = NULL;
> struct panthor_heap *heap;
> int ret;
>
> - if (offset > U32_MAX || heap_id >= MAX_HEAPS_PER_POOL)
> - return -EINVAL;
> + if (heap_id < 0)
> + return heap_id;
This can then be removed if heap_id is u32.
>
> down_read(>lock);
> heap = xa_load(>xa, heap_id);
> @@ -427,14 +445,13 @@ int panthor_heap_grow(struct panthor_heap_pool *pool,
> u32 pending_frag_count,
> u64 *new_chunk_gpu_va)
> {
> - u64 offset = heap_gpu_va - panthor_kernel_bo_gpuva(pool->gpu_contexts);
> - u32 heap_id = (u32)offset / panthor_heap_ctx_stride(pool->ptdev);
> + int heap_id = panthor_get_heap_ctx_id(pool, heap_gpu_va);
Again, keep u32 unless you have good reasons ...
> struct panthor_heap_chunk *chunk;
> struct panthor_heap *heap;
> int ret;
>
> - if (offset > U32_MAX || heap_id >= MAX_HEAPS_PER_POOL)
> - return -EINVAL;
> + if (heap_id < 0)
> + return heap_id;
... and we will not need this.
Best regards,
Liviu
>
> down_read(>lock);
> heap = xa_load(>xa, heap_id);
> --
> 2.44.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH v2 3/4] drm/panthor: Relax the constraints on the tiler chunk size
On Tue, Apr 30, 2024 at 01:28:51PM +0200, Boris Brezillon wrote:
> The field used to store the chunk size if 12 bits wide, and the encoding
> is chunk_size = chunk_header.chunk_size << 12, which gives us a
> theoretical [4k:8M] range. This range is further limited by
> implementation constraints, and all known implementations seem to
> impose a [128k:8M] range, so do the same here.
>
> We also relax the power-of-two constraint, which doesn't seem to
> exist on v10. This will allow userspace to fine-tune initial/max
> tiler memory on memory-constrained devices.
>
> v2:
> - Turn the power-of-two constraint into a page-aligned constraint to allow
> fine-tune of the initial/max heap memory size
> - Fix the panthor_heap_create() kerneldoc
>
> Fixes: 9cca48fa4f89 ("drm/panthor: Add the heap logical block")
> Signed-off-by: Boris Brezillon
With the typo that Adrián mentioned fixed,
Reviewed-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/panthor/panthor_heap.c | 8
> include/uapi/drm/panthor_drm.h | 6 +-
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_heap.c
> b/drivers/gpu/drm/panthor/panthor_heap.c
> index 3be86ec383d6..683bb94761bc 100644
> --- a/drivers/gpu/drm/panthor/panthor_heap.c
> +++ b/drivers/gpu/drm/panthor/panthor_heap.c
> @@ -253,8 +253,8 @@ int panthor_heap_destroy(struct panthor_heap_pool *pool,
> u32 handle)
> * @pool: Pool to instantiate the heap context from.
> * @initial_chunk_count: Number of chunk allocated at initialization time.
> * Must be at least 1.
> - * @chunk_size: The size of each chunk. Must be a power of two between 256k
> - * and 2M.
> + * @chunk_size: The size of each chunk. Must be page-aligned and lie in the
> + * [128k:2M] range.
> * @max_chunks: Maximum number of chunks that can be allocated.
> * @target_in_flight: Maximum number of in-flight render passes.
> * @heap_ctx_gpu_va: Pointer holding the GPU address of the allocated heap
> @@ -284,8 +284,8 @@ int panthor_heap_create(struct panthor_heap_pool *pool,
> if (initial_chunk_count > max_chunks)
> return -EINVAL;
>
> - if (hweight32(chunk_size) != 1 ||
> - chunk_size < SZ_256K || chunk_size > SZ_2M)
> + if (!IS_ALIGNED(chunk_size, PAGE_SIZE) ||
> + chunk_size < SZ_128K || chunk_size > SZ_8M)
> return -EINVAL;
>
> down_read(>lock);
> diff --git a/include/uapi/drm/panthor_drm.h b/include/uapi/drm/panthor_drm.h
> index 5db80a0682d5..b8220d2e698f 100644
> --- a/include/uapi/drm/panthor_drm.h
> +++ b/include/uapi/drm/panthor_drm.h
> @@ -898,7 +898,11 @@ struct drm_panthor_tiler_heap_create {
> /** @initial_chunk_count: Initial number of chunks to allocate. Must be
> at least one. */
> __u32 initial_chunk_count;
>
> - /** @chunk_size: Chunk size. Must be a power of two at least 256KB
> large. */
> + /**
> + * @chunk_size: Chunk size.
> + *
> + * Must be page-aligned and lie in the [128k:8M] range.
> + */
> __u32 chunk_size;
>
> /**
> --
> 2.44.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH v2 2/4] drm/panthor: Make sure the tiler initial/max chunks are consistent
On Tue, Apr 30, 2024 at 01:28:50PM +0200, Boris Brezillon wrote:
> It doesn't make sense to have a maximum number of chunks smaller than
> the initial number of chunks attached to the context.
>
> Fix the uAPI header to reflect the new constraint, and mention the
> undocumented "initial_chunk_count > 0" constraint while at it.
>
> v2:
> - Fix the check
>
> Fixes: 9cca48fa4f89 ("drm/panthor: Add the heap logical block")
> Signed-off-by: Boris Brezillon
> ---
> drivers/gpu/drm/panthor/panthor_heap.c | 3 +++
> include/uapi/drm/panthor_drm.h | 8 ++--
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_heap.c
> b/drivers/gpu/drm/panthor/panthor_heap.c
> index c3c0ba744937..3be86ec383d6 100644
> --- a/drivers/gpu/drm/panthor/panthor_heap.c
> +++ b/drivers/gpu/drm/panthor/panthor_heap.c
> @@ -281,6 +281,9 @@ int panthor_heap_create(struct panthor_heap_pool *pool,
> if (initial_chunk_count == 0)
> return -EINVAL;
>
> + if (initial_chunk_count > max_chunks)
> + return -EINVAL;
> +
Is is just me that feels like a lost opportunity to merge the check with the
one above?
if (!initial_chunk_count || initial_chunk_count > max_chunks)
return -EINVAL;
Otherwise, Reviewed-by: Liviu Dudau
Best regards,
Liviu
> if (hweight32(chunk_size) != 1 ||
> chunk_size < SZ_256K || chunk_size > SZ_2M)
> return -EINVAL;
> diff --git a/include/uapi/drm/panthor_drm.h b/include/uapi/drm/panthor_drm.h
> index dadb05ab1235..5db80a0682d5 100644
> --- a/include/uapi/drm/panthor_drm.h
> +++ b/include/uapi/drm/panthor_drm.h
> @@ -895,13 +895,17 @@ struct drm_panthor_tiler_heap_create {
> /** @vm_id: VM ID the tiler heap should be mapped to */
> __u32 vm_id;
>
> - /** @initial_chunk_count: Initial number of chunks to allocate. */
> + /** @initial_chunk_count: Initial number of chunks to allocate. Must be
> at least one. */
> __u32 initial_chunk_count;
>
> /** @chunk_size: Chunk size. Must be a power of two at least 256KB
> large. */
> __u32 chunk_size;
>
> - /** @max_chunks: Maximum number of chunks that can be allocated. */
> + /**
> + * @max_chunks: Maximum number of chunks that can be allocated.
> + *
> + * Must be at least @initial_chunk_count.
> + */
> __u32 max_chunks;
>
> /**
> --
> 2.44.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH v2 1/4] drm/panthor: Fix tiler OOM handling to allow incremental rendering
On Tue, Apr 30, 2024 at 01:28:49PM +0200, Boris Brezillon wrote:
> From: Antonino Maniscalco
>
> If the kernel couldn't allocate memory because we reached the maximum
> number of chunks but no render passes are in flight
> (panthor_heap_grow() returning -ENOMEM), we should defer the OOM
> handling to the FW by returning a NULL chunk. The FW will then call
> the tiler OOM exception handler, which is supposed to implement
> incremental rendering (execute an intermediate fragment job to flush
> the pending primitives, release the tiler memory that was used to
> store those primitives, and start over from where it stopped).
>
> Instead of checking for both ENOMEM and EBUSY, make panthor_heap_grow()
> return ENOMEM no matter the reason of this allocation failure, the FW
> doesn't care anyway.
>
> v2:
> - Make panthor_heap_grow() return -ENOMEM for all kind of allocation
> failures
> - Document the panthor_heap_grow() semantics
>
> Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block")
> Signed-off-by: Antonino Maniscalco
> Signed-off-by: Boris Brezillon
Reviewed-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/panthor/panthor_heap.c | 12
> drivers/gpu/drm/panthor/panthor_sched.c | 7 ++-
> 2 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_heap.c
> b/drivers/gpu/drm/panthor/panthor_heap.c
> index 143fa35f2e74..c3c0ba744937 100644
> --- a/drivers/gpu/drm/panthor/panthor_heap.c
> +++ b/drivers/gpu/drm/panthor/panthor_heap.c
> @@ -410,6 +410,13 @@ int panthor_heap_return_chunk(struct panthor_heap_pool
> *pool,
> * @renderpasses_in_flight: Number of render passes currently in-flight.
> * @pending_frag_count: Number of fragment jobs waiting for
> execution/completion.
> * @new_chunk_gpu_va: Pointer used to return the chunk VA.
> + *
> + * Return:
> + * - 0 if a new heap was allocated
> + * - -ENOMEM if the tiler context reached the maximum number of chunks
> + * or if too many render passes are in-flight
> + * or if the allocation failed
> + * - -EINVAL if any of the arguments passed to panthor_heap_grow() is invalid
> */
> int panthor_heap_grow(struct panthor_heap_pool *pool,
> u64 heap_gpu_va,
> @@ -439,10 +446,7 @@ int panthor_heap_grow(struct panthor_heap_pool *pool,
>* handler provided by the userspace driver, if any).
>*/
> if (renderpasses_in_flight > heap->target_in_flight ||
> - (pending_frag_count > 0 && heap->chunk_count >= heap->max_chunks)) {
> - ret = -EBUSY;
> - goto out_unlock;
> - } else if (heap->chunk_count >= heap->max_chunks) {
> + heap->chunk_count >= heap->max_chunks) {
> ret = -ENOMEM;
> goto out_unlock;
> }
> diff --git a/drivers/gpu/drm/panthor/panthor_sched.c
> b/drivers/gpu/drm/panthor/panthor_sched.c
> index b3a51a6de523..fd928362d45e 100644
> --- a/drivers/gpu/drm/panthor/panthor_sched.c
> +++ b/drivers/gpu/drm/panthor/panthor_sched.c
> @@ -1354,7 +1354,12 @@ static int group_process_tiler_oom(struct
> panthor_group *group, u32 cs_id)
> pending_frag_count, _chunk_va);
> }
>
> - if (ret && ret != -EBUSY) {
> + /* If the heap context doesn't have memory for us, we want to let the
> + * FW try to reclaim memory by waiting for fragment jobs to land or by
> + * executing the tiler OOM exception handler, which is supposed to
> + * implement incremental rendering.
> + */
> + if (ret && ret != -ENOMEM) {
> drm_warn(>base, "Failed to extend the tiler heap\n");
> group->fatal_queues |= BIT(cs_id);
> sched_queue_delayed_work(sched, tick, 0);
> --
> 2.44.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH] drm/panthor: Kill the faulty_slots variable in panthor_sched_suspend()
On Thu, Apr 25, 2024 at 12:39:20PM +0200, Boris Brezillon wrote:
> We can use upd_ctx.timedout_mask directly, and the faulty_slots update
> in the flush_caches_failed situation is never used.
>
> Suggested-by: Suggested-by: Steven Price
> Signed-off-by: Boris Brezillon
Reviewed-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/panthor/panthor_sched.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_sched.c
> b/drivers/gpu/drm/panthor/panthor_sched.c
> index fad4678ca4c8..fed28c16d5d1 100644
> --- a/drivers/gpu/drm/panthor/panthor_sched.c
> +++ b/drivers/gpu/drm/panthor/panthor_sched.c
> @@ -2584,8 +2584,8 @@ void panthor_sched_suspend(struct panthor_device *ptdev)
> {
> struct panthor_scheduler *sched = ptdev->scheduler;
> struct panthor_csg_slots_upd_ctx upd_ctx;
> - u32 suspended_slots, faulty_slots;
> struct panthor_group *group;
> + u32 suspended_slots;
> u32 i;
>
> mutex_lock(>lock);
> @@ -2605,10 +2605,9 @@ void panthor_sched_suspend(struct panthor_device
> *ptdev)
>
> csgs_upd_ctx_apply_locked(ptdev, _ctx);
> suspended_slots &= ~upd_ctx.timedout_mask;
> - faulty_slots = upd_ctx.timedout_mask;
>
> - if (faulty_slots) {
> - u32 slot_mask = faulty_slots;
> + if (upd_ctx.timedout_mask) {
> + u32 slot_mask = upd_ctx.timedout_mask;
>
> drm_err(>base, "CSG suspend failed, escalating to
> termination");
> csgs_upd_ctx_init(_ctx);
> @@ -2659,9 +2658,6 @@ void panthor_sched_suspend(struct panthor_device *ptdev)
>
> slot_mask &= ~BIT(csg_id);
> }
> -
> - if (flush_caches_failed)
> - faulty_slots |= suspended_slots;
> }
>
> for (i = 0; i < sched->csg_slot_count; i++) {
> --
> 2.44.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH v2 3/3] drm/panthor: Enable fdinfo for memory stats
Hello,
On Tue, Apr 23, 2024 at 10:32:36PM +0100, Adrián Larumbe wrote:
> When vm-binding an already-created BO, the entirety of its virtual size is
> then backed by system memory, so its RSS is always the same as its virtual
> size.
How is that relevant to this patch? Or to put it differently: how are your
words describing your code change here?
>
> Also, we consider a PRIME imported BO to be resident if its matching
> dma_buf has an open attachment, which means its backing storage had already
> been allocated.
Reviewed-by: Liviu Dudau
Best regards,
Liviu
>
> Signed-off-by: Adrián Larumbe
> ---
> drivers/gpu/drm/panthor/panthor_gem.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_gem.c
> b/drivers/gpu/drm/panthor/panthor_gem.c
> index d6483266d0c2..386c0dfeeb5f 100644
> --- a/drivers/gpu/drm/panthor/panthor_gem.c
> +++ b/drivers/gpu/drm/panthor/panthor_gem.c
> @@ -143,6 +143,17 @@ panthor_gem_prime_export(struct drm_gem_object *obj, int
> flags)
> return drm_gem_prime_export(obj, flags);
> }
>
> +static enum drm_gem_object_status panthor_gem_status(struct drm_gem_object
> *obj)
> +{
> + struct panthor_gem_object *bo = to_panthor_bo(obj);
> + enum drm_gem_object_status res = 0;
> +
> + if (bo->base.base.import_attach || bo->base.pages)
> + res |= DRM_GEM_OBJECT_RESIDENT;
> +
> + return res;
> +}
> +
> static const struct drm_gem_object_funcs panthor_gem_funcs = {
> .free = panthor_gem_free_object,
> .print_info = drm_gem_shmem_object_print_info,
> @@ -152,6 +163,7 @@ static const struct drm_gem_object_funcs
> panthor_gem_funcs = {
> .vmap = drm_gem_shmem_object_vmap,
> .vunmap = drm_gem_shmem_object_vunmap,
> .mmap = panthor_gem_mmap,
> + .status = panthor_gem_status,
> .export = panthor_gem_prime_export,
> .vm_ops = _gem_shmem_vm_ops,
> };
> --
> 2.44.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH v2 1/3] drm/panthor: introduce job cycle and timestamp accounting
ruct panthor_group *group,
> -const struct drm_panthor_queue_create *args)
> +const struct drm_panthor_queue_create *args,
> +unsigned int slots_so_far)
> {
> struct drm_gpu_scheduler *drm_sched;
> struct panthor_queue *queue;
> @@ -2987,9 +3050,12 @@ group_create_queue(struct panthor_group *group,
> goto err_free_queue;
> }
>
> + queue->time_offset = group->syncobjs.times_offset +
> + (slots_so_far * sizeof(struct panthor_job_times));
> +
> ret = drm_sched_init(>scheduler, _queue_sched_ops,
>group->ptdev->scheduler->wq, 1,
> - args->ringbuf_size / (NUM_INSTRS_PER_SLOT *
> sizeof(u64)),
> + args->ringbuf_size / SLOTSIZE,
>0, msecs_to_jiffies(JOB_TIMEOUT_MS),
>group->ptdev->reset.wq,
>NULL, "panthor-queue", group->ptdev->base.dev);
> @@ -3017,7 +3083,9 @@ int panthor_group_create(struct panthor_file *pfile,
> struct panthor_scheduler *sched = ptdev->scheduler;
> struct panthor_fw_csg_iface *csg_iface =
> panthor_fw_get_csg_iface(ptdev, 0);
> struct panthor_group *group = NULL;
> + unsigned int total_slots;
> u32 gid, i, suspend_size;
> + size_t syncobj_bo_size;
> int ret;
>
> if (group_args->pad)
> @@ -3083,33 +3151,75 @@ int panthor_group_create(struct panthor_file *pfile,
> goto err_put_group;
> }
>
> - group->syncobjs = panthor_kernel_bo_create(ptdev, group->vm,
> -group_args->queues.count *
> -sizeof(struct
> panthor_syncobj_64b),
> -DRM_PANTHOR_BO_NO_MMAP,
> -
> DRM_PANTHOR_VM_BIND_OP_MAP_NOEXEC |
> -
> DRM_PANTHOR_VM_BIND_OP_MAP_UNCACHED,
> -PANTHOR_VM_KERNEL_AUTO_VA);
> - if (IS_ERR(group->syncobjs)) {
> - ret = PTR_ERR(group->syncobjs);
> + /*
> + * Need to add size for the panthor_job_times structs, as many as the
> sum
> + * of the number of job slots for every single queue ringbuffer.
> + */
> + for (i = 0, total_slots = 0; i < group_args->queues.count; i++)
> + total_slots += (queue_args[i].ringbuf_size / (SLOTSIZE));
> +
> + syncobj_bo_size = (group_args->queues.count * sizeof(struct
> panthor_syncobj_64b))
> + + (total_slots * sizeof(struct panthor_job_times));
> +
> + /*
> + * Memory layout of group's syncobjs BO
> + * group->syncobjs.bo {
> + * struct panthor_syncobj_64b sync1;
> + * struct panthor_syncobj_64b sync2;
> + * ...
> + * As many as group_args->queues.count
> + * ...
> + * struct panthor_syncobj_64b syncn;
> + * struct panthor_job_times queue1_slot1
> + * struct panthor_job_times queue1_slot2
> + * ...
> + * As many as queue[i].ringbuf_size / SLOTSIZE
> + * ...
> + * struct panthor_job_times queue1_slotP
> + * ...
> + * As many as group_args->queues.count
> + * ...
> + * struct panthor_job_times queueN_slot1
> + * struct panthor_job_times queueN_slot2
> + * ...
> + * As many as queue[n].ringbuf_size / SLOTSIZE
> + * struct panthor_job_times queueN_slotQ
> + *
> + * Linearly, group->syncobjs.bo = {syncojb1,..,syncobjN,
> + * {queue1 = {js1,..,jsP},..,queueN = {js1,..,jsQ}}}
> + * }
> + *
> + */
> +
> + group->syncobjs.bo = panthor_kernel_bo_create(ptdev, group->vm,
> + syncobj_bo_size,
> + DRM_PANTHOR_BO_NO_MMAP,
> +
> DRM_PANTHOR_VM_BIND_OP_MAP_NOEXEC |
> +
> DRM_PANTHOR_VM_BIND_OP_MAP_UNCACHED,
> +
> PANTHOR_VM_KERNEL_AUTO_VA);
> + if (IS_ERR(group->syncobjs.bo)) {
> + ret = PTR_ERR(group->syncobjs.bo);
> goto err_put_group;
> }
>
> - ret = panthor_kernel_bo_vmap(group->syncobjs);
> + ret = panthor_kernel_bo_vmap(group->syncobjs.bo);
> if (ret)
> goto err_put_group;
>
> - memset(group->syncobjs->kmap, 0,
> -group_args->queues.count * sizeof(struct panthor_syncobj_64b));
> + memset(group->syncobjs.bo->kmap, 0, syncobj_bo_size);
> +
> + group->syncobjs.times_offset =
> + group_args->queues.count * sizeof(struct panthor_syncobj_64b);
>
> - for (i = 0; i < group_args->queues.count; i++) {
> - group->queues[i] = group_create_queue(group, _args[i]);
> + for (i = 0, total_slots = 0; i < group_args->queues.count; i++) {
> + group->queues[i] = group_create_queue(group, _args[i],
> total_slots);
> if (IS_ERR(group->queues[i])) {
> ret = PTR_ERR(group->queues[i]);
> group->queues[i] = NULL;
> goto err_put_group;
> }
>
> + total_slots += (queue_args[i].ringbuf_size / (SLOTSIZE));
> group->queue_count++;
> }
>
> --
> 2.44.0
>
With those comments addressed,
Reviewed-by: Liviu Dudau
Best regards,
Liviu
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH V2] drm/arm/malidp: fix a possible null pointer dereference
On Sun, Apr 07, 2024 at 02:30:53PM +0800, Huai-Yuan Liu wrote:
> In malidp_mw_connector_reset, new memory is allocated with kzalloc, but
> no check is performed. In order to prevent null pointer dereferencing,
> ensure that mw_state is checked before calling
> __drm_atomic_helper_connector_reset.
>
> Fixes: 8cbc5caf36ef ("drm: mali-dp: Add writeback connector")
> Signed-off-by: Huai-Yuan Liu
Reviewed-by: Liviu Dudau
Thanks for the patch. I will pull it into drm-misc-fixes before the end of the
week.
Best regards,
Liviu
> ---
> V2:
> * In patch V2, we additionally set connector->state to NULL. In this way
> we can ensure that there is no state pointing to freed memory.
> Thanks to Liviu Dudau for helpful suggestion.
> ---
> drivers/gpu/drm/arm/malidp_mw.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
> index 626709bec6f5..2577f0cef8fc 100644
> --- a/drivers/gpu/drm/arm/malidp_mw.c
> +++ b/drivers/gpu/drm/arm/malidp_mw.c
> @@ -72,7 +72,10 @@ static void malidp_mw_connector_reset(struct drm_connector
> *connector)
> __drm_atomic_helper_connector_destroy_state(connector->state);
>
> kfree(connector->state);
> - __drm_atomic_helper_connector_reset(connector, _state->base);
> + connector->state = NULL;
> +
> + if (mw_state)
> + __drm_atomic_helper_connector_reset(connector, _state->base);
> }
>
> static enum drm_connector_status
> --
> 2.34.1
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH] drm/arm/malidp: fix a possible null pointer dereference
Hi,
On Wed, Apr 03, 2024 at 09:43:01AM +0800, Huai-Yuan Liu wrote:
>
> In malidp_mw_connector_reset, new memory is allocated with kzalloc, but
> no check is performed. In order to prevent null pointer dereferencing,
> ensure that mw_state is checked before calling
> __drm_atomic_helper_connector_reset.
Thanks for the patch, it does look like an oversight. Can I suggest you
respin your patch and add a
connector->state = NULL;
right after kfree(connector->state) ?
That way we can be sure we're not leaving state pointing to freed memory.
Best regards,
Liviu
>
> Fixes: 8cbc5caf36ef ("drm: mali-dp: Add writeback connector")
> Signed-off-by: Huai-Yuan Liu
> ---
> drivers/gpu/drm/arm/malidp_mw.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
> index 626709bec6f5..25623ef9be80 100644
> --- a/drivers/gpu/drm/arm/malidp_mw.c
> +++ b/drivers/gpu/drm/arm/malidp_mw.c
> @@ -72,7 +72,9 @@ static void malidp_mw_connector_reset(struct drm_connector
> *connector)
> __drm_atomic_helper_connector_destroy_state(connector->state);
>
> kfree(connector->state);
> - __drm_atomic_helper_connector_reset(connector, _state->base);
> +
> + if (mw_state)
> + __drm_atomic_helper_connector_reset(connector, _state->base);
> }
>
> static enum drm_connector_status
> --
> 2.34.1
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
[PATCH 2/2] drm/panthor: Fix some kerneldoc warnings
When compiling with W=1 the build process will flag empty comments,
misnamed documented variables and incorrect tagging of functions.
Fix them in one go.
Fixes: de8548813824 ("drm/panthor: Add the scheduler logical block")
Cc: Boris Brezillon
Cc: Steven Price
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/panthor/panthor_sched.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_sched.c
b/drivers/gpu/drm/panthor/panthor_sched.c
index e5a710f190d2a8..a787f2fea33e98 100644
--- a/drivers/gpu/drm/panthor/panthor_sched.c
+++ b/drivers/gpu/drm/panthor/panthor_sched.c
@@ -517,7 +517,7 @@ struct panthor_group {
/** @max_compute_cores: Maximum number of shader cores used for compute
jobs. */
u8 max_compute_cores;
- /** @max_compute_cores: Maximum number of shader cores used for
fragment jobs. */
+ /** @max_fragment_cores: Maximum number of shader cores used for
fragment jobs. */
u8 max_fragment_cores;
/** @max_tiler_cores: Maximum number of tiler cores used for tiler
jobs. */
@@ -993,7 +993,7 @@ cs_slot_prog_locked(struct panthor_device *ptdev, u32
csg_id, u32 cs_id)
}
/**
- * @cs_slot_reset_locked() - Reset a queue slot
+ * cs_slot_reset_locked() - Reset a queue slot
* @ptdev: Device.
* @csg_id: Group slot.
* @cs_id: Queue slot.
@@ -1591,7 +1591,7 @@ static void sched_process_idle_event_locked(struct
panthor_device *ptdev)
}
/**
- * panthor_sched_process_global_irq() - Process the scheduling part of a
global IRQ
+ * sched_process_global_irq_locked() - Process the scheduling part of a global
IRQ
* @ptdev: Device.
*/
static void sched_process_global_irq_locked(struct panthor_device *ptdev)
@@ -1660,8 +1660,6 @@ static const struct dma_fence_ops panthor_queue_fence_ops
= {
.get_timeline_name = queue_fence_get_timeline_name,
};
-/**
- */
struct panthor_csg_slots_upd_ctx {
u32 update_mask;
u32 timedout_mask;
--
2.44.0
[PATCH 1/2] drm/panthor: Cleanup unused variable 'cookie'
Commit 962f88b9c916 ("drm/panthor: Drop the dev_enter/exit() sections in
_irq_suspend/resume()") removed the code that used the 'cookie' variable
but left the declaration in place. Remove it.
Fixes: 962f88b9c916 ("drm/panthor: Drop the dev_enter/exit() sections in
_irq_suspend/resume()")
Cc: Boris Brezillon
Cc: Steven Price
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/panthor/panthor_device.h | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_device.h
b/drivers/gpu/drm/panthor/panthor_device.h
index dc3e9c666b5bd4..2fdd671b38fd9b 100644
--- a/drivers/gpu/drm/panthor/panthor_device.h
+++ b/drivers/gpu/drm/panthor/panthor_device.h
@@ -323,8 +323,6 @@ static irqreturn_t panthor_ ## __name ##
_irq_threaded_handler(int irq, void *da
\
static inline void panthor_ ## __name ## _irq_suspend(struct panthor_irq
*pirq)\
{
\
- int cookie;
\
-
\
pirq->mask = 0;
\
gpu_write(pirq->ptdev, __reg_prefix ## _INT_MASK, 0);
\
synchronize_irq(pirq->irq);
\
@@ -333,8 +331,6 @@ static inline void panthor_ ## __name ##
_irq_suspend(struct panthor_irq *pirq)
\
static inline void panthor_ ## __name ## _irq_resume(struct panthor_irq *pirq,
u32 mask) \
{
\
- int cookie;
\
-
\
atomic_set(>suspended, false);
\
pirq->mask = mask;
\
gpu_write(pirq->ptdev, __reg_prefix ## _INT_CLEAR, mask);
\
--
2.44.0
Re: [PATCH 1/2] drm/panthor: Enable fdinfo for cycle and time measurements
Hi Adrián,
Appologies for the delay in reviewing this.
On Tue, Mar 05, 2024 at 09:05:49PM +, Adrián Larumbe wrote:
> These values are sampled by the firmware right before jumping into the UM
> command stream and immediately after returning from it, and then kept inside a
> per-job accounting structure. That structure is held inside the group's
> syncobjs
> buffer object, at an offset that depends on the job's queue slot number and
> the
> queue's index within the group.
I think this commit message is misleadingly short compared to the size of the
changes. If I may, I would like to suggest that you split this commit into two
parts, one introducing the changes in the ringbuf and syncobjs structures and
the other exporting the statistics in the fdinfo.
>
> Signed-off-by: Adrián Larumbe
> ---
> drivers/gpu/drm/panthor/panthor_devfreq.c | 10 +
> drivers/gpu/drm/panthor/panthor_device.h | 11 ++
> drivers/gpu/drm/panthor/panthor_drv.c | 31
> drivers/gpu/drm/panthor/panthor_sched.c | 217 +++---
> 4 files changed, 241 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_devfreq.c
> b/drivers/gpu/drm/panthor/panthor_devfreq.c
> index 7ac4fa290f27..51a7b734edcd 100644
> --- a/drivers/gpu/drm/panthor/panthor_devfreq.c
> +++ b/drivers/gpu/drm/panthor/panthor_devfreq.c
> @@ -91,6 +91,7 @@ static int panthor_devfreq_get_dev_status(struct device
> *dev,
> spin_lock_irqsave(>lock, irqflags);
>
> panthor_devfreq_update_utilization(pdevfreq);
> + ptdev->current_frequency = status->current_frequency;
>
> status->total_time = ktime_to_ns(ktime_add(pdevfreq->busy_time,
> pdevfreq->idle_time));
> @@ -130,6 +131,7 @@ int panthor_devfreq_init(struct panthor_device *ptdev)
> struct panthor_devfreq *pdevfreq;
> struct dev_pm_opp *opp;
> unsigned long cur_freq;
> + unsigned long freq = ULONG_MAX;
> int ret;
>
> pdevfreq = drmm_kzalloc(>base, sizeof(*ptdev->devfreq),
> GFP_KERNEL);
> @@ -204,6 +206,14 @@ int panthor_devfreq_init(struct panthor_device *ptdev)
>
> dev_pm_opp_put(opp);
>
> + /* Find the fastest defined rate */
> + opp = dev_pm_opp_find_freq_floor(dev, );
> + if (IS_ERR(opp))
> + return PTR_ERR(opp);
> + ptdev->fast_rate = freq;
> +
> + dev_pm_opp_put(opp);
> +
> /*
>* Setup default thresholds for the simple_ondemand governor.
>* The values are chosen based on experiments.
> diff --git a/drivers/gpu/drm/panthor/panthor_device.h
> b/drivers/gpu/drm/panthor/panthor_device.h
> index 51c9d61b6796..10e970921ca3 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.h
> +++ b/drivers/gpu/drm/panthor/panthor_device.h
> @@ -162,6 +162,14 @@ struct panthor_device {
>*/
> u32 *dummy_latest_flush;
> } pm;
> +
> + unsigned long current_frequency;
> + unsigned long fast_rate;
> +};
> +
> +struct panthor_gpu_usage {
> + u64 time;
> + u64 cycles;
> };
>
> /**
> @@ -176,6 +184,9 @@ struct panthor_file {
>
> /** @groups: Scheduling group pool attached to this file. */
> struct panthor_group_pool *groups;
> +
> + /** @stats: cycle and timestamp measures for job execution. */
> + struct panthor_gpu_usage stats;
> };
>
> int panthor_device_init(struct panthor_device *ptdev);
> diff --git a/drivers/gpu/drm/panthor/panthor_drv.c
> b/drivers/gpu/drm/panthor/panthor_drv.c
> index ff484506229f..fa06b9e2c6cd 100644
> --- a/drivers/gpu/drm/panthor/panthor_drv.c
> +++ b/drivers/gpu/drm/panthor/panthor_drv.c
> @@ -3,6 +3,10 @@
> /* Copyright 2019 Linaro, Ltd., Rob Herring */
> /* Copyright 2019 Collabora ltd. */
>
> +#ifdef CONFIG_HAVE_ARM_ARCH_TIMER
> +#include
> +#endif
> +
> #include
> #include
> #include
> @@ -28,6 +32,8 @@
> #include "panthor_regs.h"
> #include "panthor_sched.h"
>
> +#define NS_PER_SEC 10ULL
> +
> /**
> * DOC: user <-> kernel object copy helpers.
> */
> @@ -1336,6 +1342,29 @@ static int panthor_mmap(struct file *filp, struct
> vm_area_struct *vma)
> return ret;
> }
>
> +static void panthor_gpu_show_fdinfo(struct panthor_device *ptdev,
> + struct panthor_file *pfile,
> + struct drm_printer *p)
> +{
> +#ifdef CONFIG_HAVE_ARM_ARCH_TIMER
> + drm_printf(p, "drm-engine-panthor:\t%llu ns\n",
> +DIV_ROUND_UP_ULL((pfile->stats.time * NS_PER_SEC),
> + arch_timer_get_cntfrq()));
> +#endif
> + drm_printf(p, "drm-cycles-panthor:\t%llu\n", pfile->stats.cycles);
> + drm_printf(p, "drm-maxfreq-panthor:\t%lu Hz\n", ptdev->fast_rate);
> + drm_printf(p, "drm-curfreq-panthor:\t%lu Hz\n",
> ptdev->current_frequency);
> +}
> +
> +static void panthor_show_fdinfo(struct drm_printer *p, struct drm_file *file)
> +{
> + struct drm_device *dev =
Re: [PATCH v3 3/3] drm/panthor: Drop the dev_enter/exit() sections in _irq_suspend/resume()
On Tue, Mar 26, 2024 at 12:12:05PM +0100, Boris Brezillon wrote:
> There's no reason for _irq_suspend/resume() to be called after the
> device has been unplugged, and keeping this dev_enter/exit()
> section in _irq_suspend() is turns _irq_suspend() into a NOP
> when called from the _unplug() functions, which we don't want.
>
> v3:
> - New patch
>
> Fixes: 5fe909cae118 ("drm/panthor: Add the device logical block")
> Signed-off-by: Boris Brezillon
Reviewed-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/panthor/panthor_device.h | 17 -
> 1 file changed, 4 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_device.h
> b/drivers/gpu/drm/panthor/panthor_device.h
> index 3a930a368ae1..99ddc41f2626 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.h
> +++ b/drivers/gpu/drm/panthor/panthor_device.h
> @@ -326,13 +326,8 @@ static inline void panthor_ ## __name ##
> _irq_suspend(struct panthor_irq *pirq)
> int cookie;
> \
>
> \
> pirq->mask = 0;
> \
> -
> \
> - if (drm_dev_enter(>ptdev->base, )) {
> \
> - gpu_write(pirq->ptdev, __reg_prefix ## _INT_MASK, 0);
> \
> - synchronize_irq(pirq->irq);
> \
> - drm_dev_exit(cookie);
> \
> - }
> \
> -
> \
> + gpu_write(pirq->ptdev, __reg_prefix ## _INT_MASK, 0);
> \
> + synchronize_irq(pirq->irq);
> \
> atomic_set(>suspended, true);
> \
> }
> \
>
> \
> @@ -342,12 +337,8 @@ static inline void panthor_ ## __name ##
> _irq_resume(struct panthor_irq *pirq, u
>
> \
> atomic_set(>suspended, false);
> \
> pirq->mask = mask;
> \
> -
> \
> - if (drm_dev_enter(>ptdev->base, )) {
> \
> - gpu_write(pirq->ptdev, __reg_prefix ## _INT_CLEAR, mask);
> \
> - gpu_write(pirq->ptdev, __reg_prefix ## _INT_MASK, mask);
> \
> - drm_dev_exit(cookie);
> \
> - }
> \
> + gpu_write(pirq->ptdev, __reg_prefix ## _INT_CLEAR, mask);
> \
> + gpu_write(pirq->ptdev, __reg_prefix ## _INT_MASK, mask);
> \
> }
> \
>
> \
> static int panthor_request_ ## __name ## _irq(struct panthor_device *ptdev,
> \
> --
> 2.44.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH v3 2/3] drm/panthor: Fix ordering in _irq_suspend()
On Tue, Mar 26, 2024 at 12:12:04PM +0100, Boris Brezillon wrote:
> Make sure we set suspended=true last to avoid generating an irq storm
> in the unlikely case where an IRQ happens between the suspended=true
> assignment and the _INT_MASK update.
>
> We also move the mask=0 assignment before writing to the _INT_MASK
> register to prevent the thread handler from unmasking the interrupt
> behind our back. This means we might lose events if there were some
> pending when we get to suspend the IRQ, but that's fine.
> The synchronize_irq() we have in the _irq_suspend() path was not
> there to make sure all IRQs are processed, just to make sure we don't
> have registers accesses coming from the irq handlers after
> _irq_suspend() has been called. If there's a need to have all pending
> IRQs processed, it should happen before _irq_suspend() is called.
>
> v3:
> - Add Steve's R-b
>
> v2:
> - New patch
>
> Fixes: 5fe909cae118 ("drm/panthor: Add the device logical block")
> Reported-by: Steven Price
> Signed-off-by: Boris Brezillon
> Reviewed-by: Steven Price
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/panthor/panthor_device.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_device.h
> b/drivers/gpu/drm/panthor/panthor_device.h
> index 7ee4987a3796..3a930a368ae1 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.h
> +++ b/drivers/gpu/drm/panthor/panthor_device.h
> @@ -325,7 +325,7 @@ static inline void panthor_ ## __name ##
> _irq_suspend(struct panthor_irq *pirq)
> {
> \
> int cookie;
> \
>
> \
> - atomic_set(>suspended, true);
> \
> + pirq->mask = 0;
> \
>
> \
> if (drm_dev_enter(>ptdev->base, )) {
> \
> gpu_write(pirq->ptdev, __reg_prefix ## _INT_MASK, 0);
> \
> @@ -333,7 +333,7 @@ static inline void panthor_ ## __name ##
> _irq_suspend(struct panthor_irq *pirq)
> drm_dev_exit(cookie);
> \
> }
> \
>
> \
> - pirq->mask = 0;
> \
> + atomic_set(>suspended, true);
> \
> }
> \
>
> \
> static inline void panthor_ ## __name ## _irq_resume(struct panthor_irq
> *pirq, u32 mask) \
> --
> 2.44.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH v3 1/3] drm/panthor: Fix IO-page mmap() for 32-bit userspace on 64-bit kernel
On Tue, Mar 26, 2024 at 12:12:03PM +0100, Boris Brezillon wrote:
> When mapping an IO region, the pseudo-file offset is dependent on the
> userspace architecture. panthor_device_mmio_offset() abstracts that
> away for us by turning a userspace MMIO offset into its kernel
> equivalent, but we were not updating vm_area_struct::vm_pgoff
> accordingly, leading us to attach the MMIO region to the wrong file
> offset.
>
> This has implications when we start mixing 64 bit and 32 bit apps, but
> that's only really a problem when we start having more that 2^43 bytes of
> memory allocated, which is very unlikely to happen.
>
> What's more problematic is the fact this turns our
> unmap_mapping_range(DRM_PANTHOR_USER_MMIO_OFFSET) calls, which are
> supposed to kill the MMIO mapping when entering suspend, into NOPs.
> Which means we either keep the dummy flush_id mapping active at all
> times, or we risk a BUS_FAULT if the MMIO region was mapped, and the
> GPU is suspended after that.
>
> Solve that by patching vm_pgoff early in panthor_mmap(). With
> this in place, we no longer need the panthor_device_mmio_offset()
> helper.
>
> v3:
> - No changes
>
> v2:
> - Kill panthor_device_mmio_offset()
>
> Fixes: 5fe909cae118 ("drm/panthor: Add the device logical block")
> Reported-by: Adrián Larumbe
> Reported-by: Lukas F. Hartmann
> Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10835
> Signed-off-by: Boris Brezillon
> Reviewed-by: Steven Price
Reviewed-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/panthor/panthor_device.c | 8
> drivers/gpu/drm/panthor/panthor_device.h | 24
> drivers/gpu/drm/panthor/panthor_drv.c| 17 -
> 3 files changed, 20 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_device.c
> b/drivers/gpu/drm/panthor/panthor_device.c
> index bfe8da4a6e4c..3ddc4ba0acbe 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.c
> +++ b/drivers/gpu/drm/panthor/panthor_device.c
> @@ -334,7 +334,7 @@ static vm_fault_t panthor_mmio_vm_fault(struct vm_fault
> *vmf)
> {
> struct vm_area_struct *vma = vmf->vma;
> struct panthor_device *ptdev = vma->vm_private_data;
> - u64 id = (u64)vma->vm_pgoff << PAGE_SHIFT;
> + u64 offset = (u64)vma->vm_pgoff << PAGE_SHIFT;
> unsigned long pfn;
> pgprot_t pgprot;
> vm_fault_t ret;
> @@ -347,7 +347,7 @@ static vm_fault_t panthor_mmio_vm_fault(struct vm_fault
> *vmf)
> mutex_lock(>pm.mmio_lock);
> active = atomic_read(>pm.state) ==
> PANTHOR_DEVICE_PM_STATE_ACTIVE;
>
> - switch (panthor_device_mmio_offset(id)) {
> + switch (offset) {
> case DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET:
> if (active)
> pfn = __phys_to_pfn(ptdev->phys_addr +
> CSF_GPU_LATEST_FLUSH_ID);
> @@ -378,9 +378,9 @@ static const struct vm_operations_struct
> panthor_mmio_vm_ops = {
>
> int panthor_device_mmap_io(struct panthor_device *ptdev, struct
> vm_area_struct *vma)
> {
> - u64 id = (u64)vma->vm_pgoff << PAGE_SHIFT;
> + u64 offset = (u64)vma->vm_pgoff << PAGE_SHIFT;
>
> - switch (panthor_device_mmio_offset(id)) {
> + switch (offset) {
> case DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET:
> if (vma->vm_end - vma->vm_start != PAGE_SIZE ||
> (vma->vm_flags & (VM_WRITE | VM_EXEC)))
> diff --git a/drivers/gpu/drm/panthor/panthor_device.h
> b/drivers/gpu/drm/panthor/panthor_device.h
> index 51c9d61b6796..7ee4987a3796 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.h
> +++ b/drivers/gpu/drm/panthor/panthor_device.h
> @@ -365,30 +365,6 @@ static int panthor_request_ ## __name ## _irq(struct
> panthor_device *ptdev, \
>pirq);
> \
> }
>
> -/**
> - * panthor_device_mmio_offset() - Turn a user MMIO offset into a kernel one
> - * @offset: Offset to convert.
> - *
> - * With 32-bit systems being limited by the 32-bit representation of mmap2's
> - * pgoffset field, we need to make the MMIO offset arch specific. This
> function
> - * converts a user MMIO offset into something the kernel driver understands.
> - *
> - * If the kernel and userspace architecture match, the offset is unchanged.
> If
> - * the kernel is 64-bit and userspace is 32-bit, the offset is adjusted to
> match
> - * 64-bit offsets. 32-bit kernel with 64-bit userspace is impossible.
> - *
> - * Return: Adjusted offset.
> - */
> -static inline u64 panthor_device_
Re: [PATCH][next] drm/panthor: Fix spelling mistake "readyness" -> "readiness"
On Tue, Mar 26, 2024 at 10:02:19AM +, Colin Ian King wrote:
> There is a spelling mistake in a drm_err message. Fix it.
>
> Signed-off-by: Colin Ian King
Acked-by: Liviu Dudau
Boris, can you also pick this one up when you're pushing your kernel doc fix?
Best regards,
Liviu
> ---
> drivers/gpu/drm/panthor/panthor_gpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_gpu.c
> b/drivers/gpu/drm/panthor/panthor_gpu.c
> index 6dbbc4cfbe7e..0f7c962440d3 100644
> --- a/drivers/gpu/drm/panthor/panthor_gpu.c
> +++ b/drivers/gpu/drm/panthor/panthor_gpu.c
> @@ -333,7 +333,7 @@ int panthor_gpu_block_power_on(struct panthor_device
> *ptdev,
>val, (mask32 & val) == mask32,
>100, timeout_us);
> if (ret) {
> - drm_err(>base, "timeout waiting on %s:%llx
> readyness",
> + drm_err(>base, "timeout waiting on %s:%llx
> readiness",
> blk_name, mask);
> return ret;
> }
> --
> 2.39.2
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH] drm/panthor: Fix wrong kernel-doc format in the uAPI header
On Tue, Mar 26, 2024 at 10:30:55AM +0100, Boris Brezillon wrote:
> The kernel doc prefix is /** not /*.
>
> Reported-by: Stephen Rothwell
> Signed-off-by: Boris Brezillon
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> include/uapi/drm/panthor_drm.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/uapi/drm/panthor_drm.h b/include/uapi/drm/panthor_drm.h
> index 373df80f41ed..dadb05ab1235 100644
> --- a/include/uapi/drm/panthor_drm.h
> +++ b/include/uapi/drm/panthor_drm.h
> @@ -336,10 +336,10 @@ struct drm_panthor_gpu_info {
> /** @tiler_present: Bitmask encoding the tiler units exposed by the
> GPU. */
> __u64 tiler_present;
>
> - /* @core_features: Used to discriminate core variants when they exist.
> */
> + /** @core_features: Used to discriminate core variants when they exist.
> */
> __u32 core_features;
>
> - /* @pad: MBZ. */
> + /** @pad: MBZ. */
> __u32 pad;
> };
>
> --
> 2.44.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH v2 2/3] drm/panthor: Fix ordering in _irq_suspend()
On Mon, Mar 25, 2024 at 07:02:13PM +0100, Boris Brezillon wrote:
> On Mon, 25 Mar 2024 17:16:16 +
> Liviu Dudau wrote:
>
> > On Mon, Mar 25, 2024 at 02:57:04PM +0100, Boris Brezillon wrote:
> > > Make sure we set suspended=true last to avoid generating an irq storm
> > > in the unlikely case where an IRQ happens between the suspended=true
> > > assignment and the _INT_MASK update.
> > >
> > > v2:
> > > - New patch
> > >
> > > Reported-by: Steven Price
> > > Signed-off-by: Boris Brezillon
> > > ---
> > > drivers/gpu/drm/panthor/panthor_device.h | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/panthor/panthor_device.h
> > > b/drivers/gpu/drm/panthor/panthor_device.h
> > > index 7ee4987a3796..3a930a368ae1 100644
> > > --- a/drivers/gpu/drm/panthor/panthor_device.h
> > > +++ b/drivers/gpu/drm/panthor/panthor_device.h
> > > @@ -325,7 +325,7 @@ static inline void panthor_ ## __name ##
> > > _irq_suspend(struct panthor_irq *pirq)
> > > {
> > > \
> > > int cookie;
> > > \
> > >
> > > \
> > > - atomic_set(>suspended, true);
> > > \
> > > + pirq->mask = 0;
> > > \
> >
> > I think you might still have a race between _irq_suspend() and
> > _irq_threaded_handler() where the
> > status will be zero due to pirq->mask being zero, so no interrupt will be
> > cleared but they will
> > be masked (kind of the opposite problem to patch 3/3).
>
> Right, but I'm trying to find a case where this is an issue. Yes, we
> might lose events, but at the same time, when _irq_suspend() is called,
> we are supposed to be idle, so all this mask=0 assignment does is
> speed-up the synchronization with the irq-thread. If there's anything
> we need to be done before suspending the IRQ, this should really use
> its own synchronization model.
Perf counter collection before going idle ;)
I know that's not yet on your radar, but we need to keep it in mind to
test that scenario when we add support for keeping runtime PM alive
during perf counters dumping.
>
> >
> > I'm starting to think that pirq->mask should be local to
> > _irq_threaded_handler() and not be messed
> > with in the other functions.
>
> It kinda is, as we don't modify panthor_irq::mask outside the
> suspend/resume (and now unplug) path, and each of these accesses has a
> reason to exist:
>
> - in the resume path, we know all IRQs are masked, and we reset the
> SW-side mask to the interrupts we want to accept before updating
> _INT_MASK. No risk of race in that one
> - in the unplug path, I don't think we care about unhandled interrupts,
> because the device will become unusable after that point, so updating
> the panthor_irq::mask early and losing events should be okay.
> - the suspend case has been described above. As explained, I don't think
> it matters if we lose events there, because really, if there's any
> synchronization needed, it should have happened explicitly before
> _irq_suspend() is called. The synchronize_irq() we have is just here
> to make sure there's nothing accessing registers when we turn the
> device clk/power-domain off.
>
> >
> > >
> > > \
> > > if (drm_dev_enter(>ptdev->base, )) {
> > > \
> > > gpu_write(pirq->ptdev, __reg_prefix ## _INT_MASK, 0);
> > > \
> >
> > If you move the line above before the if condition, do you still need patch
> > 3/3?
>
> The whole point of the drm_dev_enter/exit() section was to prevent
> access to registers after the device has been unplugged, so, if I move
> the gpu_write() outside of this block, I'd rather drop the entire
> drm_dev_enter/exit() section (both here and in _irq_resume()). That
> should be safe actually, as I don't expect the PM hooks or the reset
> handler to be called after the device and its resource have been
> removed, and those are the two only paths where _irq_suspend/resume()
> can be called.
Re: [PATCH v2 3/3] drm/panthor: Actually suspend IRQs in the unplug path
On Mon, Mar 25, 2024 at 02:57:05PM +0100, Boris Brezillon wrote:
> panthor_xxx_irq_suspend() doesn't mask the interrupts if drm_dev_unplug()
> has been called, which is always the case when our panthor_xxx_unplug()
> helpers are called. Fix that by introducing a panthor_xxx_unplug() helper
> that does what panthor_xxx_irq_suspend() except it does it
> unconditionally.
I understand that drm_dev_unplug() messes up with the cleanup, but I'm a bit
reluctant to see a function that completely ignores if the device has been
unplugged or not. Like mentioned on the review of 2/3, can we move the masking
of the interrupts outside the critical section and not add drm_dev_unplug() ?
>
> v2:
> - Add Steve's R-b
>
> Fixes: 5fe909cae118 ("drm/panthor: Add the device logical block")
> Signed-off-by: Boris Brezillon
> Reviewed-by: Steven Price
> ---
> Found inadvertently while debugging another issue. I guess I managed to
> call rmmod during a PING and that led to the FW interrupt handler
> being executed after the device suspend happened.
> ---
> drivers/gpu/drm/panthor/panthor_device.h | 8
> drivers/gpu/drm/panthor/panthor_fw.c | 2 +-
> drivers/gpu/drm/panthor/panthor_gpu.c| 2 +-
> drivers/gpu/drm/panthor/panthor_mmu.c| 2 +-
> 4 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_device.h
> b/drivers/gpu/drm/panthor/panthor_device.h
> index 3a930a368ae1..5634e9490c7f 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.h
> +++ b/drivers/gpu/drm/panthor/panthor_device.h
> @@ -321,6 +321,14 @@ static irqreturn_t panthor_ ## __name ##
> _irq_threaded_handler(int irq, void *da
> return ret;
> \
> }
> \
>
> \
> +static inline void panthor_ ## __name ## _irq_unplug(struct panthor_irq
> *pirq) \
> +{
> \
> + pirq->mask = 0;
> \
> + gpu_write(pirq->ptdev, __reg_prefix ## _INT_MASK, 0);
> \
> + synchronize_irq(pirq->irq);
> \
> + atomic_set(>suspended, true);
> \
> +}
> \
> +
> \
> static inline void panthor_ ## __name ## _irq_suspend(struct panthor_irq
> *pirq) \
> {
> \
> int cookie;
> \
> diff --git a/drivers/gpu/drm/panthor/panthor_fw.c
> b/drivers/gpu/drm/panthor/panthor_fw.c
> index 33c87a59834e..7a9710a38c5f 100644
> --- a/drivers/gpu/drm/panthor/panthor_fw.c
> +++ b/drivers/gpu/drm/panthor/panthor_fw.c
> @@ -1128,7 +1128,7 @@ void panthor_fw_unplug(struct panthor_device *ptdev)
>
> /* Make sure the IRQ handler can be called after that point. */
While reviewing this I've spotted that the comment needs updating: "... handler
*can't* be called ..."
Best regards,
Liviu
> if (ptdev->fw->irq.irq)
> - panthor_job_irq_suspend(>fw->irq);
> + panthor_job_irq_unplug(>fw->irq);
>
> panthor_fw_stop(ptdev);
>
> diff --git a/drivers/gpu/drm/panthor/panthor_gpu.c
> b/drivers/gpu/drm/panthor/panthor_gpu.c
> index 6dbbc4cfbe7e..b84c5b650fd9 100644
> --- a/drivers/gpu/drm/panthor/panthor_gpu.c
> +++ b/drivers/gpu/drm/panthor/panthor_gpu.c
> @@ -174,7 +174,7 @@ void panthor_gpu_unplug(struct panthor_device *ptdev)
> unsigned long flags;
>
> /* Make sure the IRQ handler is not running after that point. */
> - panthor_gpu_irq_suspend(>gpu->irq);
> + panthor_gpu_irq_unplug(>gpu->irq);
>
> /* Wake-up all waiters. */
> spin_lock_irqsave(>gpu->reqs_lock, flags);
> diff --git a/drivers/gpu/drm/panthor/panthor_mmu.c
> b/drivers/gpu/drm/panthor/panthor_mmu.c
> index fdd35249169f..1f333cdded0f 100644
> --- a/drivers/gpu/drm/panthor/panthor_mmu.c
> +++ b/drivers/gpu/drm/panthor/panthor_mmu.c
> @@ -2622,7 +2622,7 @@ int panthor_vm_prepare_mapped_bos_resvs(struct drm_exec
> *exec, struct panthor_vm
> */
> void panthor_mmu_unplug(struct panthor_device *ptdev)
> {
> - panthor_mmu_irq_suspend(>mmu->irq);
> + panthor_mmu_irq_unplug(>mmu->irq);
>
> mutex_lock(>mmu->as.slots_lock);
> for (u32 i = 0; i < ARRAY_SIZE(ptdev->mmu->as.slots); i++) {
> --
> 2.44.0
>
--
Re: [PATCH v2 2/3] drm/panthor: Fix ordering in _irq_suspend()
On Mon, Mar 25, 2024 at 02:57:04PM +0100, Boris Brezillon wrote:
> Make sure we set suspended=true last to avoid generating an irq storm
> in the unlikely case where an IRQ happens between the suspended=true
> assignment and the _INT_MASK update.
>
> v2:
> - New patch
>
> Reported-by: Steven Price
> Signed-off-by: Boris Brezillon
> ---
> drivers/gpu/drm/panthor/panthor_device.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_device.h
> b/drivers/gpu/drm/panthor/panthor_device.h
> index 7ee4987a3796..3a930a368ae1 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.h
> +++ b/drivers/gpu/drm/panthor/panthor_device.h
> @@ -325,7 +325,7 @@ static inline void panthor_ ## __name ##
> _irq_suspend(struct panthor_irq *pirq)
> {
> \
> int cookie;
> \
>
> \
> - atomic_set(>suspended, true);
> \
> + pirq->mask = 0;
> \
I think you might still have a race between _irq_suspend() and
_irq_threaded_handler() where the
status will be zero due to pirq->mask being zero, so no interrupt will be
cleared but they will
be masked (kind of the opposite problem to patch 3/3).
I'm starting to think that pirq->mask should be local to
_irq_threaded_handler() and not be messed
with in the other functions.
>
> \
> if (drm_dev_enter(>ptdev->base, )) {
> \
> gpu_write(pirq->ptdev, __reg_prefix ## _INT_MASK, 0);
> \
If you move the line above before the if condition, do you still need patch 3/3?
Best regards,
Liviu
> @@ -333,7 +333,7 @@ static inline void panthor_ ## __name ##
> _irq_suspend(struct panthor_irq *pirq)
> drm_dev_exit(cookie);
> \
> }
> \
>
> \
> - pirq->mask = 0;
> \
> + atomic_set(>suspended, true);
> \
> }
> \
>
> \
> static inline void panthor_ ## __name ## _irq_resume(struct panthor_irq
> *pirq, u32 mask) \
> --
> 2.44.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH] drm/panthor: Fix the CONFIG_PM=n case
On Mon, Mar 18, 2024 at 09:58:55AM +0100, Boris Brezillon wrote:
> Putting a hard dependency on CONFIG_PM is not possible because of a
> circular dependency issue, and it's actually not desirable either. In
> order to support this use case, we forcibly resume at init time, and
> suspend at unplug time.
>
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202403031944.eoimq8wk-...@intel.com/
> Signed-off-by: Boris Brezillon
> ---
> Tested by faking CONFIG_PM=n in the driver (basically commenting
> all pm_runtime calls, and making the panthor_device_suspend/resume()
> calls unconditional in the panthor_device_unplug/init() path) since
> CONFIG_ARCH_ROCKCHIP selects CONFIG_PM. Seems to work fine, but I
> can't be 100% sure this will work correctly on a platform that has
> CONFIG_PM=n.
Yes, there are no realistic platforms to test where you can enable panthor
but disable runtime power management. All our emulator configuration are
based on Juno (ARCH_VEXPRESS) which select CONFIG_PM.
Reviewed-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/panthor/panthor_device.c | 13 +++--
> drivers/gpu/drm/panthor/panthor_drv.c| 4 +++-
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_device.c
> b/drivers/gpu/drm/panthor/panthor_device.c
> index 69deb8e17778..ba7aedbb4931 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.c
> +++ b/drivers/gpu/drm/panthor/panthor_device.c
> @@ -87,6 +87,10 @@ void panthor_device_unplug(struct panthor_device *ptdev)
> pm_runtime_dont_use_autosuspend(ptdev->base.dev);
> pm_runtime_put_sync_suspend(ptdev->base.dev);
>
> + /* If PM is disabled, we need to call the suspend handler manually. */
> + if (!IS_ENABLED(CONFIG_PM))
> + panthor_device_suspend(ptdev->base.dev);
> +
> /* Report the unplug operation as done to unblock concurrent
>* panthor_device_unplug() callers.
>*/
> @@ -218,6 +222,13 @@ int panthor_device_init(struct panthor_device *ptdev)
> if (ret)
> return ret;
>
> + /* If PM is disabled, we need to call panthor_device_resume() manually.
> */
> + if (!IS_ENABLED(CONFIG_PM)) {
> + ret = panthor_device_resume(ptdev->base.dev);
> + if (ret)
> + return ret;
> + }
> +
> ret = panthor_gpu_init(ptdev);
> if (ret)
> goto err_rpm_put;
> @@ -402,7 +413,6 @@ int panthor_device_mmap_io(struct panthor_device *ptdev,
> struct vm_area_struct *
> return 0;
> }
>
> -#ifdef CONFIG_PM
> int panthor_device_resume(struct device *dev)
> {
> struct panthor_device *ptdev = dev_get_drvdata(dev);
> @@ -547,4 +557,3 @@ int panthor_device_suspend(struct device *dev)
> mutex_unlock(>pm.mmio_lock);
> return ret;
> }
> -#endif
> diff --git a/drivers/gpu/drm/panthor/panthor_drv.c
> b/drivers/gpu/drm/panthor/panthor_drv.c
> index ff484506229f..2ea6a9f436db 100644
> --- a/drivers/gpu/drm/panthor/panthor_drv.c
> +++ b/drivers/gpu/drm/panthor/panthor_drv.c
> @@ -1407,17 +1407,19 @@ static const struct of_device_id dt_match[] = {
> };
> MODULE_DEVICE_TABLE(of, dt_match);
>
> +#ifdef CONFIG_PM
> static DEFINE_RUNTIME_DEV_PM_OPS(panthor_pm_ops,
>panthor_device_suspend,
>panthor_device_resume,
>NULL);
> +#endif
>
> static struct platform_driver panthor_driver = {
> .probe = panthor_probe,
> .remove_new = panthor_remove,
> .driver = {
> .name = "panthor",
> - .pm = _pm_ops,
> + .pm = pm_ptr(_pm_ops),
> .of_match_table = dt_match,
> },
> };
> --
> 2.43.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH 22/43] drm/arm/komeda: Use fbdev-dma
On Tue, Mar 12, 2024 at 04:45:17PM +0100, Thomas Zimmermann wrote: > Implement fbdev emulation with fbdev-dma. Fbdev-dma now supports > damage handling, which is required by komeda. Avoids the overhead of > fbdev-generic's additional shadow buffering. No functional changes. > > Signed-off-by: Thomas Zimmermann > Cc: Liviu Dudau Acked-by: Liviu Dudau Best regards, Liviu > --- > drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c > b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c > index cc57ea4e13ae6..ffdeec3b3f2ea 100644 > --- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c > @@ -9,7 +9,7 @@ > #include > #include > #include > -#include > +#include > #include > #include > #include "komeda_dev.h" > @@ -80,7 +80,7 @@ static int komeda_platform_probe(struct platform_device > *pdev) > } > > dev_set_drvdata(dev, mdrv); > - drm_fbdev_generic_setup(>kms->base, 32); > + drm_fbdev_dma_setup(>kms->base, 32); > > return 0; > > -- > 2.44.0 > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯
Re: [PATCH] Revert "drm/panthor: Fix undefined panthor_device_suspend/resume symbol issue"
On Mon, Mar 11, 2024 at 05:52:59PM +0200, Jani Nikula wrote: > On Mon, 11 Mar 2024, Liviu Dudau wrote: > > On Mon, Mar 11, 2024 at 04:49:30PM +0200, Jani Nikula wrote: > >> On Mon, 11 Mar 2024, Liviu Dudau wrote: > >> > So with this revert we're OK with an undefined symbol if !CONFIG_PM, but > >> > we're not happy > >> > with a recursive dependency that is only triggered for COMPILE_TEST? I > >> > would've thought > >> > IOMMU_SUPPORT options is a better one. > >> > >> It's a real config. > >> > >> # CONFIG_COMPILE_TEST is not set > > > > So I can select CONFIG_ARM64 and CONFIG_X86_LOCAL_APIC at the same time? > > DRM_PANTHOR depends on ARM || ARM64 > > and X86_LOCAL_APIC depends on X86_64. At some moment the recursive > > dependency detector should've stopped as > > there are no common dependencies between DRM_PANTHOR and X86_LOCAL_APIC and > > going further just triggers false > > positives. I'm curious how you've created your config now. > > The thing is, I don't have *any* of the dependencies ARM || ARM64 || > COMPILE_TEST set in the config that triggered this. I don't have > DRM_PANTHOR set. But make olddefconfig detects a circular dependency > nonetheless. > > It's possible the issue is in kconfig. I don't know. But not being able > to even dodge the warning makes it a show stopper. I wouldn't even know > what to change in the config. Understood, thanks for clarifying the condition under which you've discovered the issue. I assumed (appologies!) that you were generating or using a crafted .config for testing new drivers. Reverting is then a better option for olddefconfig case, thanks for the patch and the quick merge. Best regards, Liviu > > > BR, > Jani. > > > -- > Jani Nikula, Intel -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯
Re: [PATCH] Revert "drm/panthor: Fix undefined panthor_device_suspend/resume symbol issue"
On Mon, Mar 11, 2024 at 04:49:30PM +0200, Jani Nikula wrote:
> On Mon, 11 Mar 2024, Liviu Dudau wrote:
> > On Mon, Mar 11, 2024 at 02:26:50PM +0200, Jani Nikula wrote:
> >> On Mon, 11 Mar 2024, Boris Brezillon wrote:
> >> > On Mon, 11 Mar 2024 13:51:46 +0200
> >> > Jani Nikula wrote:
> >> >
> >> >> On Mon, 11 Mar 2024, Boris Brezillon
> >> >> wrote:
> >> >> > On Mon, 11 Mar 2024 13:16:19 +0200
> >> >> > Jani Nikula wrote:
> >> >> >
> >> >> >> This reverts commit 674dc7f61aefea81901c21402946074927e63f1a.
> >> >> >>
> >> >> >> The commit causes a recursive dependency in kconfig:
> >> >> >>
> >> >> >> drivers/iommu/Kconfig:14:error: recursive dependency detected!
> >> >> >> drivers/iommu/Kconfig:14:symbol IOMMU_SUPPORT is selected by
> >> >> >> DRM_PANTHOR
> >> >> >> drivers/gpu/drm/panthor/Kconfig:3: symbol DRM_PANTHOR depends on PM
> >> >> >> kernel/power/Kconfig:183:symbol PM is selected by PM_SLEEP
> >> >> >> kernel/power/Kconfig:117:symbol PM_SLEEP depends on
> >> >> >> HIBERNATE_CALLBACKS
> >> >> >> kernel/power/Kconfig:35: symbol HIBERNATE_CALLBACKS is selected
> >> >> >> by XEN_SAVE_RESTORE
> >> >> >> arch/x86/xen/Kconfig:67: symbol XEN_SAVE_RESTORE depends on XEN
> >> >> >> arch/x86/xen/Kconfig:6: symbol XEN depends on PARAVIRT
> >> >> >> arch/x86/Kconfig:781:symbol PARAVIRT is selected by HYPERV
> >> >> >> drivers/hv/Kconfig:5:symbol HYPERV depends on X86_LOCAL_APIC
> >> >> >> arch/x86/Kconfig:1106: symbol X86_LOCAL_APIC depends on
> >> >> >> X86_UP_APIC
> >> >> >> arch/x86/Kconfig:1081: symbol X86_UP_APIC prompt is visible
> >> >> >> depending on PCI_MSI
> >> >> >> drivers/pci/Kconfig:39: symbol PCI_MSI is selected by AMD_IOMMU
> >> >> >> drivers/iommu/amd/Kconfig:3: symbol AMD_IOMMU depends on
> >> >> >> IOMMU_SUPPORT
> >> >> >> For a resolution refer to Documentation/kbuild/kconfig-language.rst
> >> >> >> subsection "Kconfig recursive dependency limitations"
> >> >> >>
> >> >> >> Fixes: 674dc7f61aef ("drm/panthor: Fix undefined
> >> >> >> panthor_device_suspend/resume symbol issue")
> >> >> >> Cc: Boris Brezillon
> >> >> >> Cc: Liviu Dudau
> >> >> >> Cc: Steven Price
> >> >> >> Signed-off-by: Jani Nikula
> >> >> >
> >> >> > Acked-by: Boris Brezillon
> >> >>
> >> >> Your suggestion select -> depends on IOMMU_SUPPORT seems to also work,
> >> >> at least for me. Want to send a patch for that instead of me merging the
> >> >> revert?
> >> >
> >> > I replied on the other thread :-). I think we're better off reverting
> >> > the faulty commit, so we can discuss how to fix the original issue
> >> > properly without blocking the build.
> >>
> >> Thanks, pushed to drm-misc-next.
> >
> > So with this revert we're OK with an undefined symbol if !CONFIG_PM, but
> > we're not happy
> > with a recursive dependency that is only triggered for COMPILE_TEST? I
> > would've thought
> > IOMMU_SUPPORT options is a better one.
>
> It's a real config.
>
> # CONFIG_COMPILE_TEST is not set
So I can select CONFIG_ARM64 and CONFIG_X86_LOCAL_APIC at the same time?
DRM_PANTHOR depends on ARM || ARM64
and X86_LOCAL_APIC depends on X86_64. At some moment the recursive dependency
detector should've stopped as
there are no common dependencies between DRM_PANTHOR and X86_LOCAL_APIC and
going further just triggers false
positives. I'm curious how you've created your config now.
Best regards,
Liviu
>
> BR,
> Jani.
>
> >
> > Best regards,
> > Liviu
> >
> >>
> >> BR,
> >> Jani.
> >>
> >>
> >> --
> >> Jani Nikula, Intel
>
> --
> Jani Nikula, Intel
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH] Revert "drm/panthor: Fix undefined panthor_device_suspend/resume symbol issue"
On Mon, Mar 11, 2024 at 02:26:50PM +0200, Jani Nikula wrote:
> On Mon, 11 Mar 2024, Boris Brezillon wrote:
> > On Mon, 11 Mar 2024 13:51:46 +0200
> > Jani Nikula wrote:
> >
> >> On Mon, 11 Mar 2024, Boris Brezillon wrote:
> >> > On Mon, 11 Mar 2024 13:16:19 +0200
> >> > Jani Nikula wrote:
> >> >
> >> >> This reverts commit 674dc7f61aefea81901c21402946074927e63f1a.
> >> >>
> >> >> The commit causes a recursive dependency in kconfig:
> >> >>
> >> >> drivers/iommu/Kconfig:14:error: recursive dependency detected!
> >> >> drivers/iommu/Kconfig:14: symbol IOMMU_SUPPORT is selected by
> >> >> DRM_PANTHOR
> >> >> drivers/gpu/drm/panthor/Kconfig:3: symbol DRM_PANTHOR depends on PM
> >> >> kernel/power/Kconfig:183: symbol PM is selected by PM_SLEEP
> >> >> kernel/power/Kconfig:117: symbol PM_SLEEP depends on
> >> >> HIBERNATE_CALLBACKS
> >> >> kernel/power/Kconfig:35:symbol HIBERNATE_CALLBACKS is selected
> >> >> by XEN_SAVE_RESTORE
> >> >> arch/x86/xen/Kconfig:67:symbol XEN_SAVE_RESTORE depends on XEN
> >> >> arch/x86/xen/Kconfig:6: symbol XEN depends on PARAVIRT
> >> >> arch/x86/Kconfig:781: symbol PARAVIRT is selected by HYPERV
> >> >> drivers/hv/Kconfig:5: symbol HYPERV depends on X86_LOCAL_APIC
> >> >> arch/x86/Kconfig:1106: symbol X86_LOCAL_APIC depends on X86_UP_APIC
> >> >> arch/x86/Kconfig:1081: symbol X86_UP_APIC prompt is visible depending
> >> >> on PCI_MSI
> >> >> drivers/pci/Kconfig:39: symbol PCI_MSI is selected by AMD_IOMMU
> >> >> drivers/iommu/amd/Kconfig:3:symbol AMD_IOMMU depends on
> >> >> IOMMU_SUPPORT
> >> >> For a resolution refer to Documentation/kbuild/kconfig-language.rst
> >> >> subsection "Kconfig recursive dependency limitations"
> >> >>
> >> >> Fixes: 674dc7f61aef ("drm/panthor: Fix undefined
> >> >> panthor_device_suspend/resume symbol issue")
> >> >> Cc: Boris Brezillon
> >> >> Cc: Liviu Dudau
> >> >> Cc: Steven Price
> >> >> Signed-off-by: Jani Nikula
> >> >
> >> > Acked-by: Boris Brezillon
> >>
> >> Your suggestion select -> depends on IOMMU_SUPPORT seems to also work,
> >> at least for me. Want to send a patch for that instead of me merging the
> >> revert?
> >
> > I replied on the other thread :-). I think we're better off reverting
> > the faulty commit, so we can discuss how to fix the original issue
> > properly without blocking the build.
>
> Thanks, pushed to drm-misc-next.
So with this revert we're OK with an undefined symbol if !CONFIG_PM, but we're
not happy
with a recursive dependency that is only triggered for COMPILE_TEST? I would've
thought
IOMMU_SUPPORT options is a better one.
Best regards,
Liviu
>
> BR,
> Jani.
>
>
> --
> Jani Nikula, Intel
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH] drm/panthor: Add support for performance counters
On Fri, Mar 08, 2024 at 04:15:15PM +0100, Boris Brezillon wrote: > On Fri, 8 Mar 2024 13:52:18 + > Liviu Dudau wrote: > > > Hi Adrián, > > > > Thanks for the patch and appologies for taking a bit longer to respond, > > I was trying to gather some internal Arm feedback before replying. > > > > On Tue, Mar 05, 2024 at 04:58:16PM +, Adrián Larumbe wrote: > > > This brings in support for Panthor's HW performance counters and querying > > > them from UM through a specific ioctl(). The code is inspired by existing > > > functionality for the Panfrost driver, with some noteworthy differences: > > > > > > - Sample size is now reported by the firmware rather than having to > > > reckon > > > it by hand > > > - Counter samples are chained in a ring buffer that can be accessed > > > concurrently, but only from threads within a single context (this is > > > because of a HW limitation). > > > - List of enabled counters must be explicitly told from UM > > > - Rather than allocating the BO that will contain the perfcounter values > > > in the render context's address space, the samples ring buffer is mapped > > > onto the MCU's VM. > > > - If more than one thread within the same context tries to dump a sample, > > > then the kernel will copy the same frame to every single thread that was > > > able to join the dump queue right before the FW finished processing the > > > sample request. > > > - UM must provide a BO handle for retrieval of perfcnt values rather > > > than passing a user virtual address. > > > > > > The reason multicontext access to the driver's perfcnt ioctl interface > > > isn't tolerated is because toggling a different set of counters than the > > > current one implies a counter reset, which also messes up with the ring > > > buffer's extraction and insertion pointers. This is an unfortunate > > > hardware limitation. > > > > There are a few issues that we would like to improve with this patch. > > > > I'm not sure what user space app has been used for testing this (I'm > > guessing > > gputop from igt?) but whatever is used it needs to understand the counters > > being exposed. > > We are using perfetto to expose perfcounters. > > > In your patch there is no information given to the user space > > about the layout of the counters and / or their order. Where is this being > > planned to be defined? > > That's done on purpose. We want to keep the kernel side as dumb as > possible so we don't have to maintain a perfcounter database there. All > the kernel needs to know is how much data it should transfer pass to > userspace, and that's pretty much it. I was not thinking about a perfcounter database but hints about counter value size. In the future we might have 64bits counters and you will not be able to tell only from the sample size if you're talking with an old firmware or not. (Read: future GPUs are likely to go bigger on number of perf counters before they gain higher definition). > > > Long term, I think it would be good to have details > > about the counters available. > > The perfcounter definitions are currently declared in mesa (see the G57 > perfcounter definitions for instance [1]). Mesa also contains a perfetto > datasource for Panfrost [2]. Sorry, I've missed that perfetto got updated. > > > > > The other issue we can see is with the perfcnt_process_sample() and its > > handling of threshold event and overflows. If the userspace doesn't sample > > quick enough and we cross the threshold we are going to lose samples and > > there is no mechanism to communicate to user space that the values they > > are getting have gaps. I believe the default mode for the firmware is to > > give you counter values relative to the last read value, so if you drop > > samples you're not going to make any sense of the data. > > If we get relative values, that's indeed a problem. I thought we were > getting absolute values though, in which case, if you miss two 32-bit > wraparounds, either your sampling rate is very slow, or events occur at > a high rate. First CSF GPUs have some erratas around perf counters that firmware tries to hide. I need to dig a bit deeper into what firmware does for each GPU before confirming the counting mode. The main issue with the code is that we should not be dropping samples at all, even if they are absolute values, as there will be gaps in the analysis. Looking at perfcnt_process_sample(), it does not increase the sampling rate if we reach the threshold, nor does it tell the user spa
Re: [PATCH] drm/panthor: Add support for performance counters
Hi Adrián,
Thanks for the patch and appologies for taking a bit longer to respond,
I was trying to gather some internal Arm feedback before replying.
On Tue, Mar 05, 2024 at 04:58:16PM +, Adrián Larumbe wrote:
> This brings in support for Panthor's HW performance counters and querying
> them from UM through a specific ioctl(). The code is inspired by existing
> functionality for the Panfrost driver, with some noteworthy differences:
>
> - Sample size is now reported by the firmware rather than having to reckon
> it by hand
> - Counter samples are chained in a ring buffer that can be accessed
> concurrently, but only from threads within a single context (this is
> because of a HW limitation).
> - List of enabled counters must be explicitly told from UM
> - Rather than allocating the BO that will contain the perfcounter values
> in the render context's address space, the samples ring buffer is mapped
> onto the MCU's VM.
> - If more than one thread within the same context tries to dump a sample,
> then the kernel will copy the same frame to every single thread that was
> able to join the dump queue right before the FW finished processing the
> sample request.
> - UM must provide a BO handle for retrieval of perfcnt values rather
> than passing a user virtual address.
>
> The reason multicontext access to the driver's perfcnt ioctl interface
> isn't tolerated is because toggling a different set of counters than the
> current one implies a counter reset, which also messes up with the ring
> buffer's extraction and insertion pointers. This is an unfortunate
> hardware limitation.
There are a few issues that we would like to improve with this patch.
I'm not sure what user space app has been used for testing this (I'm guessing
gputop from igt?) but whatever is used it needs to understand the counters
being exposed. In your patch there is no information given to the user space
about the layout of the counters and / or their order. Where is this being
planned to be defined? Long term, I think it would be good to have details
about the counters available.
The other issue we can see is with the perfcnt_process_sample() and its
handling of threshold event and overflows. If the userspace doesn't sample
quick enough and we cross the threshold we are going to lose samples and
there is no mechanism to communicate to user space that the values they
are getting have gaps. I believe the default mode for the firmware is to
give you counter values relative to the last read value, so if you drop
samples you're not going to make any sense of the data.
The third topic that is worth discussing is the runtime PM. Currently your
patch will increment the runtime PM usage count when the performance
counter dump is enabled, which means you will not be able to instrument
your power saving modes. It might not be a concern for the current users
of the driver, but it is worth discussing how to enable that workflow
for future.
Otherwise, from a quick look over the code it looks good to me.
Best regards,
Liviu
>
> Signed-off-by: Adrián Larumbe
> ---
> drivers/gpu/drm/panthor/Makefile | 3 +-
> drivers/gpu/drm/panthor/panthor_device.c | 6 +
> drivers/gpu/drm/panthor/panthor_device.h | 6 +
> drivers/gpu/drm/panthor/panthor_drv.c | 61 +++
> drivers/gpu/drm/panthor/panthor_fw.c | 27 ++
> drivers/gpu/drm/panthor/panthor_fw.h | 12 +
> drivers/gpu/drm/panthor/panthor_perfcnt.c | 551 ++
> drivers/gpu/drm/panthor/panthor_perfcnt.h | 31 ++
> drivers/gpu/drm/panthor/panthor_sched.c | 1 +
> include/uapi/drm/panthor_drm.h| 72 +++
> 10 files changed, 769 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/panthor/panthor_perfcnt.c
> create mode 100644 drivers/gpu/drm/panthor/panthor_perfcnt.h
>
> diff --git a/drivers/gpu/drm/panthor/Makefile
> b/drivers/gpu/drm/panthor/Makefile
> index 15294719b09c..7f841fd053d4 100644
> --- a/drivers/gpu/drm/panthor/Makefile
> +++ b/drivers/gpu/drm/panthor/Makefile
> @@ -9,6 +9,7 @@ panthor-y := \
> panthor_gpu.o \
> panthor_heap.o \
> panthor_mmu.o \
> - panthor_sched.o
> + panthor_sched.o \
> + panthor_perfcnt.o
>
> obj-$(CONFIG_DRM_PANTHOR) += panthor.o
> diff --git a/drivers/gpu/drm/panthor/panthor_device.c
> b/drivers/gpu/drm/panthor/panthor_device.c
> index bfe8da4a6e4c..5dfd82891063 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.c
> +++ b/drivers/gpu/drm/panthor/panthor_device.c
> @@ -20,6 +20,7 @@
> #include "panthor_mmu.h"
> #include "panthor_regs.h"
> #include "panthor_sched.h"
> +#include "panthor_perfcnt.h"
>
> static int panthor_clk_init(struct panthor_device *ptdev)
> {
> @@ -78,6 +79,7 @@ void panthor_device_unplug(struct panthor_device *ptdev)
> /* Now, try to cleanly shutdown the GPU before the device resources
>* get reclaimed.
>*/
> + panthor_perfcnt_unplug(ptdev);
>
Re: [PATCH 1/3] drm/arm/komeda: Fix komeda probe failing if there are no links in the secondary pipeline
Hi Faiz,
On Mon, Feb 19, 2024 at 03:39:13PM +0530, Faiz Abbas wrote:
> Since commit f7936d6beda9 ("drm/arm/komeda: Remove component framework and
> add a simple encoder"), the devm_drm_of_get_bridge() call happens
> regardless of whether any remote nodes are available on the pipeline. Fix
> this by moving the bridge attach to its own function and calling it
> conditional on there being an output link.
>
> Fixes: f7936d6beda9 ("drm/arm/komeda: Remove component framework and add a
> simple encoder")
I don't know what tree you're using, but the commit that you're quoting here is
actually 4cfe5cc02e3f. I will fix it when I merge the patch.
Best regards,
Liviu
> Signed-off-by: Faiz Abbas
> ---
> .../gpu/drm/arm/display/komeda/komeda_crtc.c | 43 ++-
> 1 file changed, 32 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 2c661f28410e..b645c5998230 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -5,6 +5,7 @@
> *
> */
> #include
> +#include
> #include
> #include
>
> @@ -610,12 +611,34 @@ get_crtc_primary(struct komeda_kms_dev *kms, struct
> komeda_crtc *crtc)
> return NULL;
> }
>
> +static int komeda_attach_bridge(struct device *dev,
> + struct komeda_pipeline *pipe,
> + struct drm_encoder *encoder)
> +{
> + struct drm_bridge *bridge;
> + int err;
> +
> + bridge = devm_drm_of_get_bridge(dev, pipe->of_node,
> + KOMEDA_OF_PORT_OUTPUT, 0);
> + if (IS_ERR(bridge))
> + return dev_err_probe(dev, PTR_ERR(bridge), "remote bridge not
> found for pipe: %s\n",
> + of_node_full_name(pipe->of_node));
> +
> + err = drm_bridge_attach(encoder, bridge, NULL, 0);
> + if (err)
> + dev_err(dev, "bridge_attach() failed for pipe: %s\n",
> + of_node_full_name(pipe->of_node));
> +
> + return err;
> +}
> +
> static int komeda_crtc_add(struct komeda_kms_dev *kms,
> struct komeda_crtc *kcrtc)
> {
> struct drm_crtc *crtc = >base;
> struct drm_device *base = >base;
> - struct drm_bridge *bridge;
> + struct komeda_pipeline *pipe = kcrtc->master;
> + struct drm_encoder *encoder = >encoder;
> int err;
>
> err = drm_crtc_init_with_planes(base, crtc,
> @@ -626,27 +649,25 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
>
> drm_crtc_helper_add(crtc, _crtc_helper_funcs);
>
> - crtc->port = kcrtc->master->of_output_port;
> + crtc->port = pipe->of_output_port;
>
> /* Construct an encoder for each pipeline and attach it to the remote
>* bridge
>*/
> kcrtc->encoder.possible_crtcs = drm_crtc_mask(crtc);
> - err = drm_simple_encoder_init(base, >encoder,
> - DRM_MODE_ENCODER_TMDS);
> + err = drm_simple_encoder_init(base, encoder, DRM_MODE_ENCODER_TMDS);
> if (err)
> return err;
>
> - bridge = devm_drm_of_get_bridge(base->dev, kcrtc->master->of_node,
> - KOMEDA_OF_PORT_OUTPUT, 0);
> - if (IS_ERR(bridge))
> - return PTR_ERR(bridge);
> -
> - err = drm_bridge_attach(>encoder, bridge, NULL, 0);
> + if (pipe->of_output_links[0]) {
> + err = komeda_attach_bridge(base->dev, pipe, encoder);
> + if (err)
> + return err;
> + }
>
> drm_crtc_enable_color_mgmt(crtc, 0, true, KOMEDA_COLOR_LUT_SIZE);
>
> - return err;
> + return 0;
> }
>
> int komeda_kms_add_crtcs(struct komeda_kms_dev *kms, struct komeda_dev *mdev)
> --
> 2.25.1
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH 1/3] drm/panthor: Fix panthor_devfreq kerneldoc
On Mon, Mar 04, 2024 at 10:08:10AM +0100, Boris Brezillon wrote:
> Missing '*' to have a valid kerneldoc prefix.
>
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202403031019.6jvroqgt-...@intel.com/
> Signed-off-by: Boris Brezillon
LGTM :)
Best regards,
Liviu
> ---
> drivers/gpu/drm/panthor/panthor_devfreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/panthor/panthor_devfreq.c
> b/drivers/gpu/drm/panthor/panthor_devfreq.c
> index 7ac4fa290f27..c6d3c327cc24 100644
> --- a/drivers/gpu/drm/panthor/panthor_devfreq.c
> +++ b/drivers/gpu/drm/panthor/panthor_devfreq.c
> @@ -34,7 +34,7 @@ struct panthor_devfreq {
> /** @last_busy_state: True if the GPU was busy last time we updated the
> state. */
> bool last_busy_state;
>
> - /*
> + /**
>* @lock: Lock used to protect busy_time, idle_time, time_last_update
> and
>* last_busy_state.
>*
> --
> 2.43.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH 2/3] drm/panthor: Explicitly include page.h for the {virt,__phys)_to_pfn() defs
On Mon, Mar 04, 2024 at 10:08:11AM +0100, Boris Brezillon wrote: > Something on arm[64] must be including , but things fail > to compile on sparc64. Make sure this header is included explicitly > so this driver can be compile-tested on all supported architectures. Is compilation on sparc64 possible because of 'depends on COMPILE_TEST'? Otherwise it doesn't make sense to try to build this for any arch other than arm[64]. Regardless, patch looks harmless, so Reviewed-by: Liviu Dudau Best regards, Liviu > > Reported-by: kernel test robot > Closes: > https://lore.kernel.org/oe-kbuild-all/202403031142.vl4pw7x6-...@intel.com/ > Signed-off-by: Boris Brezillon > --- > drivers/gpu/drm/panthor/panthor_device.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/panthor/panthor_device.c > b/drivers/gpu/drm/panthor/panthor_device.c > index bfe8da4a6e4c..68e467ee458a 100644 > --- a/drivers/gpu/drm/panthor/panthor_device.c > +++ b/drivers/gpu/drm/panthor/panthor_device.c > @@ -3,6 +3,8 @@ > /* Copyright 2019 Linaro, Ltd, Rob Herring */ > /* Copyright 2023 Collabora ltd. */ > > +#include > + > #include > #include > #include > -- > 2.43.0 > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯
Re: [PATCH 3/3] drm/panthor: Fix undefined panthor_device_suspend/resume symbol issue
On Mon, Mar 04, 2024 at 10:08:12AM +0100, Boris Brezillon wrote:
> panthor_device_resume/suspend() are only compiled when CONFIG_PM is
> enabled but panthro_drv.c doesn't use the pm_ptr() macro to conditionally
> discard resume/suspend assignments, which causes undefined symbol
> errors at link time when !PM.
>
> We could fix that by using pm_ptr(), but supporting the !PM case makes
> little sense (the whole point of these embedded GPUs is to be low power,
> so proper PM is a basic requirement in that case). So let's just enforce
> the presence of CONFIG_PM with a Kconfig dependency instead.
>
> If someone needs to relax this dependency, it can be done in a follow-up.
>
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202403031944.eoimq8wk-...@intel.com/
> Signed-off-by: Boris Brezillon
Reviewed-by: Liviu Dudau
Agree on this, there is no point on running on kernels without CONFIG_PM
enabled.
Best regards,
Liviu
> ---
> drivers/gpu/drm/panthor/Kconfig | 1 +
> drivers/gpu/drm/panthor/panthor_device.c | 2 --
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panthor/Kconfig b/drivers/gpu/drm/panthor/Kconfig
> index 55b40ad07f3b..fdce7c1b2310 100644
> --- a/drivers/gpu/drm/panthor/Kconfig
> +++ b/drivers/gpu/drm/panthor/Kconfig
> @@ -6,6 +6,7 @@ config DRM_PANTHOR
> depends on ARM || ARM64 || COMPILE_TEST
> depends on !GENERIC_ATOMIC64 # for IOMMU_IO_PGTABLE_LPAE
> depends on MMU
> + depends on PM
> select DEVFREQ_GOV_SIMPLE_ONDEMAND
> select DRM_EXEC
> select DRM_GEM_SHMEM_HELPER
> diff --git a/drivers/gpu/drm/panthor/panthor_device.c
> b/drivers/gpu/drm/panthor/panthor_device.c
> index 68e467ee458a..efea29143a54 100644
> --- a/drivers/gpu/drm/panthor/panthor_device.c
> +++ b/drivers/gpu/drm/panthor/panthor_device.c
> @@ -403,7 +403,6 @@ int panthor_device_mmap_io(struct panthor_device *ptdev,
> struct vm_area_struct *
> return 0;
> }
>
> -#ifdef CONFIG_PM
> int panthor_device_resume(struct device *dev)
> {
> struct panthor_device *ptdev = dev_get_drvdata(dev);
> @@ -548,4 +547,3 @@ int panthor_device_suspend(struct device *dev)
> mutex_unlock(>pm.mmio_lock);
> return ret;
> }
> -#endif
> --
> 2.43.0
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH 0/3] Fixes for the komeda driver
Hi Faiz, On Mon, Feb 19, 2024 at 03:39:12PM +0530, Faiz Abbas wrote: > The following patches add fixes to the komeda DPU driver. > > Patch 1 fixes an issue where the crtc always expects both pipelines to > always have remote nodes populated. > > Patch 2 is a cosmetic fix that ensures komeda does not print verbose > pipeline information unless the entire pipeline is actually up. > > Patch 3 adds a 40 bit DMA mask for each pipeline. Sorry for the delay in replying, I was on holiday last week. Patch series looks good, I will push it into drm-misc-next-fixes at the end of the week. Best regards, Liviu > > Amjad Ouled-Ameur (1): > drm/arm/komeda: update DMA mask to 40 bits > > Faiz Abbas (2): > drm/arm/komeda: Fix komeda probe failing if there are no links in the > secondary pipeline > drm/arm/komeda: Move pipeline prints to after the entire pipeline has > been enabled > > .../gpu/drm/arm/display/komeda/komeda_crtc.c | 45 ++- > .../gpu/drm/arm/display/komeda/komeda_drv.c | 4 ++ > .../gpu/drm/arm/display/komeda/komeda_kms.h | 1 + > .../drm/arm/display/komeda/komeda_pipeline.c | 4 +- > 4 files changed, 41 insertions(+), 13 deletions(-) > > -- > 2.25.1 > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯
Re: [PATCH v5 00/14] drm: Add a driver for CSF-based Mali GPUs
On Sun, Feb 18, 2024 at 10:41:14PM +0100, Boris Brezillon wrote: > Hello, Hi Boris, > > This is the 5th version of the kernel driver for Mali CSF-based GPUs, > and, unless someone has good reasons to block the merging of this > driver, I expect it to be the last one (the gallium driver is now > in a decent state, and is mostly waiting for the kernel driver to > be accepted). Series looks good to me and can be merged as far as I'm concerned. Best regards, Liviu > > A branch based on drm-misc-next is available here[1], and here is > another one [2] containing extra patches to have things working on > rk3588. The CSF firmware binary is now merged in linux-firmware [3]. > > The mesa MR adding v10 support on top of panthor is available here [4]. > > Here is a non-exhaustive changelog, check each commit for a detailed > changelog. > > v5: > - No fundamental changes in this v5 > - Various bug fixes (see the per-commit changelogs) > - Various docs/typos fixes > > v4: > - Fix various bugs in the VM logic > - Address comments from Steven, Liviu, Ketil and Chris > - Move tiler OOM handling out of the scheduler interrupt handling path > so we can properly recover when the system runs out of memory, and > panthor is blocked trying to allocate heap chunks > - Rework the heap locking to support concurrent chunk allocation. Not > sure if this is supposed to happen, but we need to be robust against > userspace passing the same heap context to two scheduling groups. > Wasn't needed before the tiler_oom rework, because heap allocation > base serialized by the scheduler lock. > - Make kernel BO destruction robust to NULL/ERR pointers > > v3; > - Quite a few changes at the MMU/sched level to make the fix some > race conditions and deadlocks > - Addition of the a sync-only VM_BIND operation (to support > vkQueueSparseBind with zero commands). > - Addition of a VM_GET_STATE ioctl > > [1]https://gitlab.freedesktop.org/panfrost/linux/-/tree/panthor-v5 > [2]https://gitlab.freedesktop.org/panfrost/linux/-/tree/panthor-v5+rk3588 > [3]https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/arm/mali/arch10.8 > [4]https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26358 > > Boris Brezillon (13): > drm/panthor: Add uAPI > drm/panthor: Add GPU register definitions > drm/panthor: Add the device logical block > drm/panthor: Add the GPU logical block > drm/panthor: Add GEM logical block > drm/panthor: Add the devfreq logical block > drm/panthor: Add the MMU/VM logical block > drm/panthor: Add the FW logical block > drm/panthor: Add the heap logical block > drm/panthor: Add the scheduler logical block > drm/panthor: Add the driver frontend block > drm/panthor: Allow driver compilation > drm/panthor: Add an entry to MAINTAINERS > > Liviu Dudau (1): > dt-bindings: gpu: mali-valhall-csf: Add support for Arm Mali CSF GPUs > > .../bindings/gpu/arm,mali-valhall-csf.yaml| 147 + > Documentation/gpu/driver-uapi.rst |5 + > MAINTAINERS | 11 + > drivers/gpu/drm/Kconfig |2 + > drivers/gpu/drm/Makefile |1 + > drivers/gpu/drm/panthor/Kconfig | 23 + > drivers/gpu/drm/panthor/Makefile | 15 + > drivers/gpu/drm/panthor/panthor_devfreq.c | 283 ++ > drivers/gpu/drm/panthor/panthor_devfreq.h | 25 + > drivers/gpu/drm/panthor/panthor_device.c | 549 +++ > drivers/gpu/drm/panthor/panthor_device.h | 393 ++ > drivers/gpu/drm/panthor/panthor_drv.c | 1473 +++ > drivers/gpu/drm/panthor/panthor_fw.c | 1362 +++ > drivers/gpu/drm/panthor/panthor_fw.h | 504 +++ > drivers/gpu/drm/panthor/panthor_gem.c | 228 ++ > drivers/gpu/drm/panthor/panthor_gem.h | 144 + > drivers/gpu/drm/panthor/panthor_gpu.c | 482 +++ > drivers/gpu/drm/panthor/panthor_gpu.h | 52 + > drivers/gpu/drm/panthor/panthor_heap.c| 597 +++ > drivers/gpu/drm/panthor/panthor_heap.h| 39 + > drivers/gpu/drm/panthor/panthor_mmu.c | 2766 + > drivers/gpu/drm/panthor/panthor_mmu.h | 102 + > drivers/gpu/drm/panthor/panthor_regs.h| 239 ++ > drivers/gpu/drm/panthor/panthor_sched.c | 3501 + > drivers/gpu/drm/panthor/panthor_sched.h | 48 + > include/uapi/drm/panthor_drm.h| 945 + > 26 files changed, 13936 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml > create mode 100644 drivers/gpu/drm/panthor/Kconfig > create mode 100644 drivers/gpu/d
Re: [PATCH v4 05/14] drm/panthor: Add GEM logical block
On Mon, Jan 22, 2024 at 05:30:36PM +0100, Boris Brezillon wrote:
> Anything relating to GEM object management is placed here. Nothing
> particularly interesting here, given the implementation is based on
> drm_gem_shmem_object, which is doing most of the work.
>
> v4:
> - Force kernel BOs to be GPU mapped
> - Make panthor_kernel_bo_destroy() robust against ERR/NULL BO pointers
> to simplify the call sites
>
> v3:
> - Add acks for the MIT/GPL2 relicensing
> - Provide a panthor_kernel_bo abstraction for buffer objects managed by
> the kernel (will replace panthor_fw_mem and be used everywhere we were
> using panthor_gem_create_and_map() before)
> - Adjust things to match drm_gpuvm changes
> - Change return of panthor_gem_create_with_handle() to int
>
> Co-developed-by: Steven Price
> Signed-off-by: Steven Price
> Signed-off-by: Boris Brezillon
> Acked-by: Steven Price # MIT+GPL2 relicensing,Arm
> Acked-by: Grant Likely # MIT+GPL2 relicensing,Linaro
> Acked-by: Boris Brezillon # MIT+GPL2
> relicensing,Collabora
Reviewed-by: Liviu Dudau
> ---
> drivers/gpu/drm/panthor/panthor_gem.c | 228 ++
> drivers/gpu/drm/panthor/panthor_gem.h | 144
> 2 files changed, 372 insertions(+)
> create mode 100644 drivers/gpu/drm/panthor/panthor_gem.c
> create mode 100644 drivers/gpu/drm/panthor/panthor_gem.h
>
> diff --git a/drivers/gpu/drm/panthor/panthor_gem.c
> b/drivers/gpu/drm/panthor/panthor_gem.c
> new file mode 100644
> index ..42e342fcad19
> --- /dev/null
> +++ b/drivers/gpu/drm/panthor/panthor_gem.c
> @@ -0,0 +1,228 @@
> +// SPDX-License-Identifier: GPL-2.0 or MIT
> +/* Copyright 2019 Linaro, Ltd, Rob Herring */
> +/* Copyright 2023 Collabora ltd. */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include "panthor_device.h"
> +#include "panthor_gem.h"
> +#include "panthor_mmu.h"
> +
> +static void panthor_gem_free_object(struct drm_gem_object *obj)
> +{
> + struct panthor_gem_object *bo = to_panthor_bo(obj);
> + struct drm_gem_object *vm_root_gem = bo->exclusive_vm_root_gem;
> +
> + drm_gem_free_mmap_offset(>base.base);
> + mutex_destroy(>gpuva_list_lock);
> + drm_gem_shmem_free(>base);
> + drm_gem_object_put(vm_root_gem);
> +}
> +
> +/**
> + * panthor_kernel_bo_destroy() - Destroy a kernel buffer object
> + * @vm: The VM this BO was mapped to.
> + * @bo: Kernel buffer object to destroy. If NULL or an ERR_PTR(), the
> destruction
> + * is skipped.
> + */
> +void panthor_kernel_bo_destroy(struct panthor_vm *vm,
> +struct panthor_kernel_bo *bo)
> +{
> + int ret;
> +
> + if (IS_ERR_OR_NULL(bo))
> + return;
> +
> + panthor_kernel_bo_vunmap(bo);
> +
> + if (drm_WARN_ON(bo->obj->dev,
> + to_panthor_bo(bo->obj)->exclusive_vm_root_gem !=
> panthor_vm_root_gem(vm)))
> + goto out_free_bo;
> +
> + ret = panthor_vm_unmap_range(vm, bo->va_node.start,
> + panthor_kernel_bo_size(bo));
> + if (ret)
> + goto out_free_bo;
> +
> + panthor_vm_free_va(vm, >va_node);
> + drm_gem_object_put(bo->obj);
> +
> +out_free_bo:
> + kfree(bo);
> +}
> +
> +/**
> + * panthor_kernel_bo_create() - Create and map a GEM object to a VM
> + * @ptdev: Device.
> + * @vm: VM to map the GEM to. If NULL, the kernel object is not GPU mapped.
> + * @size: Size of the buffer object.
> + * @bo_flags: Combination of drm_panthor_bo_flags flags.
> + * @vm_map_flags: Combination of drm_panthor_vm_bind_op_flags (only those
> + * that are related to map operations).
> + * @gpu_va: GPU address assigned when mapping to the VM.
> + * If gpu_va == PANTHOR_VM_KERNEL_AUTO_VA, the virtual address will be
> + * automatically allocated.
> + *
> + * Return: A valid pointer in case of success, an ERR_PTR() otherwise.
> + */
> +struct panthor_kernel_bo *
> +panthor_kernel_bo_create(struct panthor_device *ptdev, struct panthor_vm *vm,
> + size_t size, u32 bo_flags, u32 vm_map_flags,
> + u64 gpu_va)
> +{
> + struct drm_gem_shmem_object *obj;
> + struct panthor_kernel_bo *kbo;
> + struct panthor_gem_object *bo;
> + int ret;
> +
> + if (drm_WARN_ON(>base, !vm))
> + return ERR_PTR(-EINVAL);
> +
> + kbo = kzalloc(sizeof(*kbo), GFP_KERNEL);
> + if (!kbo)
> + return ERR_PTR(-ENOMEM);
> +
> + obj = drm_gem_shmem_create(>base, size);
> + if (IS_ERR(obj)
Re: [PATCH v4 03/14] drm/panthor: Add the device logical block
On Thu, Feb 08, 2024 at 05:00:23PM +0100, Boris Brezillon wrote:
> On Thu, 8 Feb 2024 15:55:36 +
> Liviu Dudau wrote:
>
> > On Thu, Feb 08, 2024 at 04:14:59PM +0100, Boris Brezillon wrote:
> > > On Thu, 8 Feb 2024 14:30:02 +
> > > Liviu Dudau wrote:
> > >
> > > > > +int panthor_device_init(struct panthor_device *ptdev)
> > > > > +{
> > > > > + struct resource *res;
> > > > > + struct page *p;
> > > > > + int ret;
> > > > > +
> > > > > + ptdev->coherent = device_get_dma_attr(ptdev->base.dev) ==
> > > > > DEV_DMA_COHERENT;
> > > > > +
> > > > > + init_completion(>unplug.done);
> > > > > + ret = drmm_mutex_init(>base, >unplug.lock);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > + ret = drmm_mutex_init(>base, >pm.mmio_lock);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > + atomic_set(>pm.state, PANTHOR_DEVICE_PM_STATE_SUSPENDED);
> > > > > + p = alloc_page(GFP_KERNEL | __GFP_ZERO);
> > > > > + if (!p)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + ptdev->pm.dummy_latest_flush = page_address(p);
> > > > > + ret = drmm_add_action_or_reset(>base,
> > > > > panthor_device_free_page,
> > > > > +ptdev->pm.dummy_latest_flush);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > + /*
> > > > > + * Set the dummy page holding the latest flush to 1. This will
> > > > > cause the
> > > > > + * flush to avoided as we know it isn't necessary if the
> > > > > submission
> > > > > + * happens while the dummy page is mapped. Zero cannot be used
> > > > > because
> > > > > + * that means 'always flush'.
> > > > > + */
> > > > > + *ptdev->pm.dummy_latest_flush = 1;
> > > > > +
> > > > > + INIT_WORK(>reset.work, panthor_device_reset_work);
> > > > > + ptdev->reset.wq = alloc_ordered_workqueue("panthor-reset-wq",
> > > > > 0);
> > > > > + if (!ptdev->reset.wq)
> > > > > + return -ENOMEM;
> > > > > +
> > > > > + ret = drmm_add_action_or_reset(>base,
> > > > > panthor_device_reset_cleanup, NULL);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > + ret = panthor_clk_init(ptdev);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > + ret = panthor_devfreq_init(ptdev);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > + ptdev->iomem =
> > > > > devm_platform_get_and_ioremap_resource(to_platform_device(ptdev->base.dev),
> > > > > + 0, );
> > > > > + if (IS_ERR(ptdev->iomem))
> > > > > + return PTR_ERR(ptdev->iomem);
> > > > > +
> > > > > + ptdev->phys_addr = res->start;
> > > > > +
> > > > > + ret = devm_pm_runtime_enable(ptdev->base.dev);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > + ret = pm_runtime_resume_and_get(ptdev->base.dev);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > +
> > > > > + ret = panthor_gpu_init(ptdev);
> > > > > + if (ret)
> > > > > + goto err_rpm_put;
> > > > > +
> > > > > + ret = panthor_mmu_init(ptdev);
> > > > > + if (ret)
> > > > > + goto err_unplug_gpu;
> > > > > +
> > > > > + ret = panthor_fw_init(ptdev);
> > > > > + if (ret)
> > > > > + goto err_unplug_mmu;
> > > > > +
> &
Re: [PATCH v4 00/14] drm: Add a driver for CSF-based Mali GPUs
On Mon, Jan 22, 2024 at 05:30:31PM +0100, Boris Brezillon wrote: > Hello, Hi, > > This is the 4th version of the kernel driver for Mali CSF-based GPUs. > > A branch based on drm-misc-next and containing all the dependencies > that are not yet available in drm-misc-next here[1], and another [2] > containing extra patches to have things working on rk3588. The CSF > firmware binary can be found here[3], and should be placed under > /lib/firmware/arm/mali/arch10.8/mali_csffw.bin. Since today the linux-firmware 'main' branch also contains an official copy of the CSF firmware for the 10.8 architecture. Thanks to Mario for the quick inclusion! Best regards, Liviu > > The mesa MR adding v10 support on top of panthor is available here [4]. > > Steve, I intentionally dropped your R-b on "drm/panthor: Add the heap > logical block" and "drm/panthor: Add the scheduler logical block" > because the tiler-OOM handling changed enough to require a new review > IMHO. > > Regarding the GPL2+MIT relicensing, I collected Clément's R-b for the > devfreq code, but am still lacking Alexey Sheplyakov for some bits in > panthor_gpu.c. The rest of the code is either new, or covered by the > Linaro, Arm and Collabora acks. > > And here is a non-exhaustive changelog, check each commit for a detailed > changelog. > > v4: > - Fix various bugs in the VM logic > - Address comments from Steven, Liviu, Ketil and Chris > - Move tiler OOM handling out of the scheduler interrupt handling path > so we can properly recover when the system runs out of memory, and > panthor is blocked trying to allocate heap chunks > - Rework the heap locking to support concurrent chunk allocation. Not > sure if this is supposed to happen, but we need to be robust against > userspace passing the same heap context to two scheduling groups. > Wasn't needed before the tiler_oom rework, because heap allocation > base serialized by the scheduler lock. > - Make kernel BO destruction robust to NULL/ERR pointers > > v3; > - Quite a few changes at the MMU/sched level to make the fix some > race conditions and deadlocks > - Addition of the a sync-only VM_BIND operation (to support > vkQueueSparseBind with zero commands). > - Addition of a VM_GET_STATE ioctl > - Various cosmetic changes (see the commit changelogs for more details) > - Various fixes (see the commit changelogs for more details) > > v2: > - Rename the driver (pancsf -> panthor) > - Split the commit adding the driver to ease review > - Use drm_sched for dependency tracking/job submission > - Add a VM_BIND ioctl > - Add the concept of exclusive VM for BOs that are only ever mapped to a > single VM > - Document the code and uAPI > - Add a DT binding doc > > Regards, > > Boris > > [1]https://gitlab.freedesktop.org/panfrost/linux/-/tree/panthor-v4 > [2]https://gitlab.freedesktop.org/panfrost/linux/-/tree/panthor-v4+rk3588 > [3]https://gitlab.com/firefly-linux/external/libmali/-/raw/firefly/firmware/g610/mali_csffw.bin > [4]https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26358 > > Boris Brezillon (13): > drm/panthor: Add uAPI > drm/panthor: Add GPU register definitions > drm/panthor: Add the device logical block > drm/panthor: Add the GPU logical block > drm/panthor: Add GEM logical block > drm/panthor: Add the devfreq logical block > drm/panthor: Add the MMU/VM logical block > drm/panthor: Add the FW logical block > drm/panthor: Add the heap logical block > drm/panthor: Add the scheduler logical block > drm/panthor: Add the driver frontend block > drm/panthor: Allow driver compilation > drm/panthor: Add an entry to MAINTAINERS > > Liviu Dudau (1): > dt-bindings: gpu: mali-valhall-csf: Add support for Arm Mali CSF GPUs > > .../bindings/gpu/arm,mali-valhall-csf.yaml| 147 + > Documentation/gpu/driver-uapi.rst |5 + > MAINTAINERS | 11 + > drivers/gpu/drm/Kconfig |2 + > drivers/gpu/drm/Makefile |1 + > drivers/gpu/drm/panthor/Kconfig | 23 + > drivers/gpu/drm/panthor/Makefile | 15 + > drivers/gpu/drm/panthor/panthor_devfreq.c | 283 ++ > drivers/gpu/drm/panthor/panthor_devfreq.h | 25 + > drivers/gpu/drm/panthor/panthor_device.c | 544 +++ > drivers/gpu/drm/panthor/panthor_device.h | 393 ++ > drivers/gpu/drm/panthor/panthor_drv.c | 1470 +++ > drivers/gpu/drm/panthor/panthor_fw.c | 1334 +++ > drivers/gpu/drm/panthor/panthor_fw.h | 504 +++ > drivers/gpu/drm/panthor/panthor_gem.c | 228 ++ > drivers/gpu/drm/panthor
Re: [PATCH v4 03/14] drm/panthor: Add the device logical block
On Thu, Feb 08, 2024 at 04:14:59PM +0100, Boris Brezillon wrote:
> On Thu, 8 Feb 2024 14:30:02 +
> Liviu Dudau wrote:
>
> > > +int panthor_device_init(struct panthor_device *ptdev)
> > > +{
> > > + struct resource *res;
> > > + struct page *p;
> > > + int ret;
> > > +
> > > + ptdev->coherent = device_get_dma_attr(ptdev->base.dev) ==
> > > DEV_DMA_COHERENT;
> > > +
> > > + init_completion(>unplug.done);
> > > + ret = drmm_mutex_init(>base, >unplug.lock);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = drmm_mutex_init(>base, >pm.mmio_lock);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + atomic_set(>pm.state, PANTHOR_DEVICE_PM_STATE_SUSPENDED);
> > > + p = alloc_page(GFP_KERNEL | __GFP_ZERO);
> > > + if (!p)
> > > + return -ENOMEM;
> > > +
> > > + ptdev->pm.dummy_latest_flush = page_address(p);
> > > + ret = drmm_add_action_or_reset(>base, panthor_device_free_page,
> > > +ptdev->pm.dummy_latest_flush);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + /*
> > > + * Set the dummy page holding the latest flush to 1. This will cause the
> > > + * flush to avoided as we know it isn't necessary if the submission
> > > + * happens while the dummy page is mapped. Zero cannot be used because
> > > + * that means 'always flush'.
> > > + */
> > > + *ptdev->pm.dummy_latest_flush = 1;
> > > +
> > > + INIT_WORK(>reset.work, panthor_device_reset_work);
> > > + ptdev->reset.wq = alloc_ordered_workqueue("panthor-reset-wq", 0);
> > > + if (!ptdev->reset.wq)
> > > + return -ENOMEM;
> > > +
> > > + ret = drmm_add_action_or_reset(>base,
> > > panthor_device_reset_cleanup, NULL);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = panthor_clk_init(ptdev);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = panthor_devfreq_init(ptdev);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ptdev->iomem =
> > > devm_platform_get_and_ioremap_resource(to_platform_device(ptdev->base.dev),
> > > + 0, );
> > > + if (IS_ERR(ptdev->iomem))
> > > + return PTR_ERR(ptdev->iomem);
> > > +
> > > + ptdev->phys_addr = res->start;
> > > +
> > > + ret = devm_pm_runtime_enable(ptdev->base.dev);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = pm_runtime_resume_and_get(ptdev->base.dev);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = panthor_gpu_init(ptdev);
> > > + if (ret)
> > > + goto err_rpm_put;
> > > +
> > > + ret = panthor_mmu_init(ptdev);
> > > + if (ret)
> > > + goto err_unplug_gpu;
> > > +
> > > + ret = panthor_fw_init(ptdev);
> > > + if (ret)
> > > + goto err_unplug_mmu;
> > > +
> > > + ret = panthor_sched_init(ptdev);
> > > + if (ret)
> > > + goto err_unplug_fw;
> > > +
> > > + /* ~3 frames */
> > > + pm_runtime_set_autosuspend_delay(ptdev->base.dev, 50);
> > > +
> > > + ret = drm_dev_register(>base, 0);
> > > + if (ret)
> > > + goto err_unplug_sched;
> >
> > For sake of replicating the panthor_device_unplus() calls, should we do
> > here:
> >
> > if (ret) {
> > pm_runtime_dont_use_autosuspend(ptdev->base.dev);
>
> But pm_runtime_use_autosuspend() is called after that, why do we need
> to call pm_runtime_dont_use_autosuspend() here?
This is in the case where ret != 0, so we're going to skip over
pm_runtime_use_autosuspend(). We've just called
pm_runtime_set_autosuspend_delay() which by my reading also enables
runtime PM when it calls update_autosuspend(), so this is needed.
Best regards,
Liviu
>
> > goto err_unplug_sched;
> > }
> >
> >
> > > +
> > > + pm_runtime_use_autosuspend(ptdev->base.dev);
> > > + pm_runtime_put_autosuspend(ptdev->base.dev);
> > > + return 0;
> > > +
> > > +err_unplug_sched:
> > > + panthor_sched_unplug(ptdev);
> > > +
> > > +err_unplug_fw:
> > > + panthor_fw_unplug(ptdev);
> > > +
> > > +err_unplug_mmu:
> > > + panthor_mmu_unplug(ptdev);
> > > +
> > > +err_unplug_gpu:
> > > + panthor_gpu_unplug(ptdev);
> > > +
> > > +err_rpm_put:
> > > + pm_runtime_put_sync_suspend(ptdev->base.dev);
> > > + return ret;
> > > +}
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH v4 03/14] drm/panthor: Add the device logical block
return "Unknown exception type";
> +
> + return panthor_exception_infos[exception_code].name;
> +}
> +
> +static vm_fault_t panthor_mmio_vm_fault(struct vm_fault *vmf)
> +{
> + struct vm_area_struct *vma = vmf->vma;
> + struct panthor_device *ptdev = vma->vm_private_data;
> + u64 id = (u64)vma->vm_pgoff << PAGE_SHIFT;
> + unsigned long pfn;
> + pgprot_t pgprot;
> + vm_fault_t ret;
> + bool active;
> + int cookie;
> +
> + if (!drm_dev_enter(>base, ))
> + return VM_FAULT_SIGBUS;
> +
> + mutex_lock(>pm.mmio_lock);
> + active = atomic_read(>pm.state) ==
> PANTHOR_DEVICE_PM_STATE_ACTIVE;
> +
> + switch (panthor_device_mmio_offset(id)) {
> + case DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET:
> + if (active)
> + pfn = __phys_to_pfn(ptdev->phys_addr +
> CSF_GPU_LATEST_FLUSH_ID);
> + else
> + pfn = virt_to_pfn(ptdev->pm.dummy_latest_flush);
> + break;
> +
> + default:
> + ret = VM_FAULT_SIGBUS;
> + goto out_unlock;
> + }
> +
> + pgprot = vma->vm_page_prot;
> + if (active)
> + pgprot = pgprot_noncached(pgprot);
> +
> + ret = vmf_insert_pfn_prot(vma, vmf->address, pfn, pgprot);
> +
> +out_unlock:
> + mutex_unlock(>pm.mmio_lock);
> + drm_dev_exit(cookie);
> + return ret;
> +}
> +
> +static const struct vm_operations_struct panthor_mmio_vm_ops = {
> + .fault = panthor_mmio_vm_fault,
> +};
> +
> +int panthor_device_mmap_io(struct panthor_device *ptdev, struct
> vm_area_struct *vma)
> +{
> + u64 id = (u64)vma->vm_pgoff << PAGE_SHIFT;
> +
> + switch (panthor_device_mmio_offset(id)) {
> + case DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET:
> + if (vma->vm_end - vma->vm_start != PAGE_SIZE ||
> + (vma->vm_flags & (VM_WRITE | VM_EXEC)))
> + return -EINVAL;
> +
> + break;
> +
> + default:
> + return -EINVAL;
> + }
> +
> + /* Defer actual mapping to the fault handler. */
> + vma->vm_private_data = ptdev;
> + vma->vm_ops = _mmio_vm_ops;
> + vm_flags_set(vma,
> + VM_IO | VM_DONTCOPY | VM_DONTEXPAND |
> + VM_NORESERVE | VM_DONTDUMP | VM_PFNMAP);
> + return 0;
> +}
> +
> +#ifdef CONFIG_PM
> +int panthor_device_resume(struct device *dev)
> +{
> + struct panthor_device *ptdev = dev_get_drvdata(dev);
> + int ret, cookie;
> +
> + if (atomic_read(>pm.state) != PANTHOR_DEVICE_PM_STATE_SUSPENDED)
> + return -EINVAL;
> +
> + atomic_set(>pm.state, PANTHOR_DEVICE_PM_STATE_RESUMING);
> +
> + ret = clk_prepare_enable(ptdev->clks.core);
> + if (ret)
> + goto err_set_suspended;
> +
> + ret = clk_prepare_enable(ptdev->clks.stacks);
> + if (ret)
> + goto err_disable_core_clk;
> +
> + ret = clk_prepare_enable(ptdev->clks.coregroup);
> + if (ret)
> + goto err_disable_stacks_clk;
> +
> + ret = panthor_devfreq_resume(ptdev);
> + if (ret)
> + goto err_disable_coregroup_clk;
> +
> + if (panthor_device_is_initialized(ptdev) &&
> + drm_dev_enter(>base, )) {
> + panthor_gpu_resume(ptdev);
> + panthor_mmu_resume(ptdev);
> + ret = drm_WARN_ON(>base, panthor_fw_resume(ptdev));
> + if (!ret)
> + panthor_sched_resume(ptdev);
> +
> + drm_dev_exit(cookie);
> +
> + if (ret)
> + goto err_devfreq_suspend;
> + }
> +
> + if (atomic_read(>reset.pending))
> + queue_work(ptdev->reset.wq, >reset.work);
> +
> + /* Clear all IOMEM mappings pointing to this device after we've
> + * resumed. This way the fake mappings pointing to the dummy pages
> + * are removed and the real iomem mapping will be restored on next
> + * access.
> + */
> + mutex_lock(>pm.mmio_lock);
> + unmap_mapping_range(ptdev->base.anon_inode->i_mapping,
> + DRM_PANTHOR_USER_MMIO_OFFSET, 0, 1);
> + atomic_set(>pm.state, PANTHOR_DEVICE_PM_STATE_ACTIVE);
> + mutex_unlock(>pm.mmio_lock);
> + return 0;
> +
> +err_devfreq_suspend:
> + panthor_devfreq_suspend(ptdev);
Should we also call panthor_mmu_suspend(ptdev) and panthor_gpu_suspend(ptdev)
before panthor_devfreq_suspend()? Otherwise those blocks will
Re: [PATCH v4 01/14] drm/panthor: Add uAPI
Hi Boris,
Minor spelling issues to raise in the documentation text uAPI:
On Mon, Jan 22, 2024 at 05:30:32PM +0100, Boris Brezillon wrote:
> Panthor follows the lead of other recently submitted drivers with
> ioctls allowing us to support modern Vulkan features, like sparse memory
> binding:
>
> - Pretty standard GEM management ioctls (BO_CREATE and BO_MMAP_OFFSET),
> with the 'exclusive-VM' bit to speed-up BO reservation on job submission
> - VM management ioctls (VM_CREATE, VM_DESTROY and VM_BIND). The VM_BIND
> ioctl is loosely based on the Xe model, and can handle both
> asynchronous and synchronous requests
> - GPU execution context creation/destruction, tiler heap context creation
> and job submission. Those ioctls reflect how the hardware/scheduler
> works and are thus driver specific.
>
> We also have a way to expose IO regions, such that the usermode driver
> can directly access specific/well-isolate registers, like the
> LATEST_FLUSH register used to implement cache-flush reduction.
>
> This uAPI intentionally keeps usermode queues out of the scope, which
> explains why doorbell registers and command stream ring-buffers are not
> directly exposed to userspace.
>
> v4:
> - Add a VM_GET_STATE ioctl
> - Fix doc
> - Expose the CORE_FEATURES register so we can deal with variants in the
> UMD
> - Add Steve's R-b
>
[snip]
> +
> +/**
> + * enum drm_panthor_vm_state - VM states.
> + */
> +enum drm_panthor_vm_state {
> + /**
> + * @DRM_PANTHOR_VM_STATE_USABLE: VM is usable.
> + *
> + * New VM operations will be accepted on this VM.
> + */
> + DRM_PANTHOR_VM_STATE_USABLE,
> +
> + /**
> + * @DRM_PANTHOR_VM_STATE_UNSABLE: VM is unsable.
s/UNSABLE/UNUSABLE/ and s/unsable/unusable/
> + *
> + * Something put the VM in an unusable state (like an asynchronous
> + * VM_BIND request failing for any reason).
> + *
> + * Once the VM is in this state, all new MAP operations will be
> + * rejected, and any GPU job targeting this VM will fail.
> + * UNMAP operations are still accepted.
> + *
> + * The only way to recover from an unusable VM is to create a new
> + * VM, and destroy the old one.
> + */
> + DRM_PANTHOR_VM_STATE_UNUSABLE,
> +};
> +
[snip]
The rest of the patch looks good to me!
Reviewed-by: Liviu Dudau
Best regards,
Liviu
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH v3 03/14] drm/panthor: Add the device logical block
Hi Boris,
On Mon, Dec 04, 2023 at 06:32:56PM +0100, Boris Brezillon wrote:
> The panthor driver is designed in a modular way, where each logical
> block is dealing with a specific HW-block or software feature. In order
> for those blocks to communicate with each other, we need a central
> panthor_device collecting all the blocks, and exposing some common
> features, like interrupt handling, power management, reset, ...
>
> This what this panthor_device logical block is about.
>
> v3:
> - Add acks for the MIT+GPL2 relicensing
> - Fix 32-bit support
> - Shorten the sections protected by panthor_device::pm::mmio_lock to fix
> lock ordering issues.
> - Rename panthor_device::pm::lock into panthor_device::pm::mmio_lock to
> better reflect what this lock is protecting
> - Use dev_err_probe()
> - Make sure we call drm_dev_exit() when something fails half-way in
> panthor_device_reset_work()
> - Replace CSF_GPU_LATEST_FLUSH_ID_DEFAULT with a constant '1' and a
> comment to explain. Also remove setting the dummy flush ID on suspend.
> - Remove drm_WARN_ON() in panthor_exception_name()
> - Check pirq->suspended in panthor_xxx_irq_raw_handler()
>
> Signed-off-by: Boris Brezillon
> Signed-off-by: Steven Price
> Acked-by: Steven Price # MIT+GPL2 relicensing,Arm
> Acked-by: Grant Likely # MIT+GPL2 relicensing,Linaro
> Acked-by: Boris Brezillon # MIT+GPL2
> relicensing,Collabora
> ---
> drivers/gpu/drm/panthor/panthor_device.c | 497 +++
> drivers/gpu/drm/panthor/panthor_device.h | 381 +
> 2 files changed, 878 insertions(+)
> create mode 100644 drivers/gpu/drm/panthor/panthor_device.c
> create mode 100644 drivers/gpu/drm/panthor/panthor_device.h
>
> diff --git a/drivers/gpu/drm/panthor/panthor_device.c
> b/drivers/gpu/drm/panthor/panthor_device.c
> new file mode 100644
> index ..40038bac147a
> --- /dev/null
> +++ b/drivers/gpu/drm/panthor/panthor_device.c
> @@ -0,0 +1,497 @@
> +// SPDX-License-Identifier: GPL-2.0 or MIT
> +/* Copyright 2018 Marty E. Plummer */
> +/* Copyright 2019 Linaro, Ltd, Rob Herring */
> +/* Copyright 2023 Collabora ltd. */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#include "panthor_sched.h"
> +#include "panthor_device.h"
> +#include "panthor_devfreq.h"
> +#include "panthor_gpu.h"
> +#include "panthor_fw.h"
> +#include "panthor_mmu.h"
> +#include "panthor_regs.h"
> +
> +static int panthor_clk_init(struct panthor_device *ptdev)
> +{
> + ptdev->clks.core = devm_clk_get(ptdev->base.dev, NULL);
> + if (IS_ERR(ptdev->clks.core))
> + return dev_err_probe(ptdev->base.dev,
> + PTR_ERR(ptdev->clks.core),
> + "get 'core' clock failed");
> +
> + ptdev->clks.stacks = devm_clk_get_optional(ptdev->base.dev, "stacks");
> + if (IS_ERR(ptdev->clks.stacks))
> + return dev_err_probe(ptdev->base.dev,
> + PTR_ERR(ptdev->clks.stacks),
> + "get 'stacks' clock failed");
> +
> + ptdev->clks.coregroup = devm_clk_get_optional(ptdev->base.dev,
> "coregroup");
> + if (IS_ERR(ptdev->clks.coregroup))
> + return dev_err_probe(ptdev->base.dev,
> + PTR_ERR(ptdev->clks.coregroup),
> + "get 'coregroup' clock failed");
> +
> + drm_info(>base, "clock rate = %lu\n",
> clk_get_rate(ptdev->clks.core));
> + return 0;
> +}
> +
> +void panthor_device_unplug(struct panthor_device *ptdev)
> +{
> + /* FIXME: This is racy. */
> + if (drm_dev_is_unplugged(>base))
> + return;
> +
> + drm_WARN_ON(>base, pm_runtime_get_sync(ptdev->base.dev) < 0);
> +
> + /* Call drm_dev_unplug() so any access to HW block happening after
> + * that point get rejected.
> + */
> + drm_dev_unplug(>base);
> +
> + /* Now, try to cleanly shutdown the GPU before the device resources
> + * get reclaimed.
> + */
> + panthor_sched_unplug(ptdev);
> + panthor_fw_unplug(ptdev);
> + panthor_mmu_unplug(ptdev);
> + panthor_gpu_unplug(ptdev);
> +
> + pm_runtime_dont_use_autosuspend(ptdev->base.dev);
> + pm_runtime_put_sync_suspend(ptdev->base.dev);
> +}
> +
> +static void panthor_device_reset_cleanup(struct drm_device *ddev, void *data)
> +{
> + struct panthor_device *ptdev = container_of(ddev, struct
> panthor_device, base);
> +
> + cancel_work_sync(>reset.work);
> + destroy_workqueue(ptdev->reset.wq);
> +}
> +
> +static void panthor_device_reset_work(struct work_struct *work)
> +{
> + struct panthor_device *ptdev = container_of(work, struct
> panthor_device, reset.work);
> + int ret = 0, cookie;
> +
> + if (atomic_read(>pm.state) != PANTHOR_DEVICE_PM_STATE_ACTIVE) {
> + /*
> + * No need for a reset as the device has been (or will be)
> +
Re: [PATCH v3 11/14] drm/panthor: Add the driver frontend block
On Mon, Dec 04, 2023 at 06:33:04PM +0100, Boris Brezillon wrote:
> This is the last piece missing to expose the driver to the outside
> world.
>
> This is basically a wrapper between the ioctls and the other logical
> blocks.
>
> v3:
> - Add acks for the MIT/GPL2 relicensing
> - Fix 32-bit support
> - Account for panthor_vm and panthor_sched changes
> - Simplify the resv preparation/update logic
> - Use a linked list rather than xarray for list of signals.
> - Simplify panthor_get_uobj_array by returning the newly allocated
> array.
> - Drop the "DOC" for job submission helpers and move the relevant
> comments to panthor_ioctl_group_submit().
> - Add helpers sync_op_is_signal()/sync_op_is_wait().
> - Simplify return type of panthor_submit_ctx_add_sync_signal() and
> panthor_submit_ctx_get_sync_signal().
> - Drop WARN_ON from panthor_submit_ctx_add_job().
> - Fix typos in comments.
>
> Signed-off-by: Boris Brezillon
> Signed-off-by: Steven Price
> Acked-by: Steven Price # MIT+GPL2 relicensing,Arm
> Acked-by: Grant Likely # MIT+GPL2 relicensing,Linaro
> Acked-by: Boris Brezillon # MIT+GPL2
> relicensing,Collabora
Hello,
Just some small name mismatch spotted here.
Otherwise,
Reviewed-by: Liviu Dudau
> ---
> drivers/gpu/drm/panthor/panthor_drv.c | 1454 +
> 1 file changed, 1454 insertions(+)
> create mode 100644 drivers/gpu/drm/panthor/panthor_drv.c
>
> diff --git a/drivers/gpu/drm/panthor/panthor_drv.c
> b/drivers/gpu/drm/panthor/panthor_drv.c
> new file mode 100644
> index ..9447a4e90018
> --- /dev/null
> +++ b/drivers/gpu/drm/panthor/panthor_drv.c
> @@ -0,0 +1,1454 @@
> +// SPDX-License-Identifier: GPL-2.0 or MIT
> +/* Copyright 2018 Marty E. Plummer */
> +/* Copyright 2019 Linaro, Ltd., Rob Herring */
> +/* Copyright 2019 Collabora ltd. */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "panthor_sched.h"
> +#include "panthor_device.h"
> +#include "panthor_gem.h"
> +#include "panthor_heap.h"
> +#include "panthor_fw.h"
> +#include "panthor_mmu.h"
> +#include "panthor_gpu.h"
> +#include "panthor_regs.h"
> +
> +/**
> + * DOC: user <-> kernel object copy helpers.
> + */
> +
> +/**
> + * panthor_set_uobj() - Copy kernel object to user object.
> + * @usr_ptr: Users pointer.
> + * @usr_size: Size of the user object.
> + * @min_size: Minimum size for this object.
> + * @kern_size: Size of the kernel object.
> + * @in: Address of the kernel object to copy.
> + *
> + * Helper automating kernel -> user object copies.
> + *
> + * Don't use this function directly, use PANTHOR_UOBJ_SET() instead.
> + *
> + * Return: 0 on success, a negative error code otherwise.
> + */
> +static int
> +panthor_set_uobj(u64 usr_ptr, u32 usr_size, u32 min_size, u32 kern_size,
> const void *in)
> +{
> + /* User size shouldn't be smaller than the minimal object size. */
> + if (usr_size < min_size)
> + return -EINVAL;
> +
> + if (copy_to_user(u64_to_user_ptr(usr_ptr), in, min_t(u32, usr_size,
> kern_size)))
> + return -EFAULT;
> +
> + /* When the kernel object is smaller than the user object, we fill the
> gap with
> + * zeros.
> + */
> + if (usr_size > kern_size &&
> + clear_user(u64_to_user_ptr(usr_ptr + kern_size), usr_size -
> kern_size)) {
> + return -EFAULT;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * panthor_get_uobj_array() - Copy a user object array into a kernel
> accessible object array.
> + * @in: The object array to copy.
> + * @min_stride: Minimum array stride.
> + * @obj_size: Kernel object size.
> + *
> + * Helper automating user -> kernel object copies.
> + *
> + * Don't use this function directly, use PANTHOR_UOBJ_ARRAY_GET() instead.
Looks like the macro is called PANTHOR_UOBJ_GET_ARRAY().
Best regards,
Liviu
> + *
> + * Return: newly allocated object array or an ERR_PTR on error.
> + */
> +static void *
> +panthor_get_uobj_array(const struct drm_panthor_obj_array *in, u32
> min_stride,
> +u32 obj_size)
> +{
> + int ret = 0;
> + void *out_alloc;
> +
> + /* User stride must be at least the minimum object size, otherwise it
> might
> + * lack useful information.
> + */
> + if (in->stride < min_stride)
> + return ERR_PTR(-EINVAL);
> +
&
Re: [PATCH v3 08/14] drm/panthor: Add the FW logical block
On Mon, Dec 04, 2023 at 06:33:01PM +0100, Boris Brezillon wrote:
> Contains everything that's FW related, that includes the code dealing
> with the microcontroller unit (MCU) that's running the FW, and anything
> related to allocating memory shared between the FW and the CPU.
>
> A few global FW events are processed in the IRQ handler, the rest is
> forwarded to the scheduler, since scheduling is the primary reason for
> the FW existence, and also the main source of FW <-> kernel
> interactions.
>
> v3:
> - Make the FW path more future-proof (Liviu)
> - Use one waitqueue for all FW events
> - Simplify propagation of FW events to the scheduler logic
> - Drop the panthor_fw_mem abstraction and use panthor_kernel_bo instead
> - Account for the panthor_vm changes
> - Replace magic number with 0x7fff with ~0 to better signify that
> it's the maximum permitted value.
> - More accurate rounding when computing the firmware timeout.
> - Add a 'sub iterator' helper function. This also adds a check that a
> firmware entry doesn't overflow the firmware image.
> - Drop __packed from FW structures, natural alignment is good enough.
> - Other minor code improvements.
>
> Signed-off-by: Boris Brezillon
> Signed-off-by: Steven Price
Hi Boris,
While looking at Chris' comments, I have discovered another issue.
> ---
> drivers/gpu/drm/panthor/panthor_fw.c | 1332 ++
> drivers/gpu/drm/panthor/panthor_fw.h | 504 ++
> 2 files changed, 1836 insertions(+)
> create mode 100644 drivers/gpu/drm/panthor/panthor_fw.c
> create mode 100644 drivers/gpu/drm/panthor/panthor_fw.h
>
> diff --git a/drivers/gpu/drm/panthor/panthor_fw.c
> b/drivers/gpu/drm/panthor/panthor_fw.c
> new file mode 100644
> index ..85afe769f567
> --- /dev/null
> +++ b/drivers/gpu/drm/panthor/panthor_fw.c
> +static int panthor_fw_load_section_entry(struct panthor_device *ptdev,
> + const struct firmware *fw,
> + struct panthor_fw_binary_iter *iter,
> + u32 ehdr)
> +{
> + struct panthor_fw_binary_section_entry_hdr hdr;
> + struct panthor_fw_section *section;
> + u32 section_size;
> + u32 name_len;
> + int ret;
> +
> + ret = panthor_fw_binary_iter_read(ptdev, iter, , sizeof(hdr));
> + if (ret)
> + return ret;
> +
> + if (hdr.data.end < hdr.data.start) {
> + drm_err(>base, "Firmware corrupted, data.end <
> data.start (0x%x < 0x%x)\n",
> + hdr.data.end, hdr.data.start);
> + return -EINVAL;
> + }
> +
> + if (hdr.va.end < hdr.va.start) {
> + drm_err(>base, "Firmware corrupted, hdr.va.end <
> hdr.va.start (0x%x < 0x%x)\n",
> + hdr.va.end, hdr.va.start);
> + return -EINVAL;
> + }
> +
> + if (hdr.data.end > fw->size) {
> + drm_err(>base, "Firmware corrupted, file truncated?
> data_end=0x%x > fw size=0x%zx\n",
> + hdr.data.end, fw->size);
> + return -EINVAL;
> + }
> +
> + if ((hdr.va.start & ~PAGE_MASK) != 0 ||
> + (hdr.va.end & ~PAGE_MASK) != 0) {
> + drm_err(>base, "Firmware corrupted, virtual addresses
> not page aligned: 0x%x-0x%x\n",
> + hdr.va.start, hdr.va.end);
> + return -EINVAL;
> + }
> +
> + if (hdr.flags & ~CSF_FW_BINARY_IFACE_ENTRY_RD_SUPPORTED_FLAGS) {
> + drm_err(>base, "Firmware contains interface with
> unsupported flags (0x%x)\n",
> + hdr.flags);
> + return -EINVAL;
> + }
> +
> + if (hdr.flags & CSF_FW_BINARY_IFACE_ENTRY_RD_PROT) {
> + drm_warn(>base,
> + "Firmware protected mode entry not be supported,
> ignoring");
> + return 0;
> + }
> +
> + if (hdr.va.start == CSF_MCU_SHARED_REGION_START &&
> + !(hdr.flags & CSF_FW_BINARY_IFACE_ENTRY_RD_SHARED)) {
> + drm_err(>base,
> + "Interface at 0x%llx must be shared",
> CSF_MCU_SHARED_REGION_START);
> + return -EINVAL;
> + }
> +
> + name_len = iter->size - iter->offset;
> +
> + section = drmm_kzalloc(>base, sizeof(*section), GFP_KERNEL);
> + if (!section)
> + return -ENOMEM;
> +
> + list_add_tail(>node, >fw->sections);
> + section->flags = hdr.flags;
> + section->data.size = hdr.data.end - hdr.data.start;
> +
> + if (section->data.size > 0) {
> + void *data = drmm_kmalloc(>base, section->data.size,
> GFP_KERNEL);
> +
> + if (!data)
> + return -ENOMEM;
> +
> + memcpy(data, fw->data + hdr.data.start, section->data.size);
> + section->data.buf = data;
> + }
> +
> + if (name_len > 0) {
> + char *name = drmm_kmalloc(>base, name_len + 1,
> GFP_KERNEL);
> +
> + if (!name)
> +
Re: [PATCH v3 13/14] dt-bindings: gpu: mali-valhall-csf: Add support for Arm Mali CSF GPUs
Hi Rob, Thanks for reviewing this! On Tue, Dec 05, 2023 at 02:48:27PM -0600, Rob Herring wrote: > On Mon, Dec 04, 2023 at 06:33:06PM +0100, Boris Brezillon wrote: > > From: Liviu Dudau > > > > Arm has introduced a new v10 GPU architecture that replaces the Job Manager > > interface with a new Command Stream Frontend. It adds firmware driven > > command stream queues that can be used by kernel and user space to submit > > jobs to the GPU. > > > > Add the initial schema for the device tree that is based on support for > > RK3588 SoC. The minimum number of clocks is one for the IP, but on Rockchip > > platforms they will tend to expose the semi-independent clocks for better > > power management. > > > > v3: > > - Cleanup commit message to remove redundant text > > - Added opp-table property and re-ordered entries > > - Clarified power-domains and power-domain-names requirements for RK3588. > > - Cleaned up example > > > > Note: power-domains and power-domain-names requirements for other platforms > > are still work in progress, hence the bindings are left incomplete here. > > > > v2: > > - New commit > > > > Signed-off-by: Liviu Dudau > > Cc: Krzysztof Kozlowski > > Cc: Rob Herring > > Cc: Conor Dooley > > Cc: devicet...@vger.kernel.org > > --- > > .../bindings/gpu/arm,mali-valhall-csf.yaml| 147 ++ > > 1 file changed, 147 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml > > b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml > > new file mode 100644 > > index ..d72de094c8ea > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml > > @@ -0,0 +1,147 @@ > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/gpu/arm,mali-valhall-csf.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: ARM Mali Valhall GPU > > + > > +maintainers: > > + - Liviu Dudau > > + - Boris Brezillon > > + > > +properties: > > + $nodename: > > +pattern: '^gpu@[a-f0-9]+$' > > + > > + compatible: > > +oneOf: > > Don't need oneOf. This has come up on the review of the previous version. We're planning on adding support for more SoCs once the initial panthor driver gets merged, but I don't think it's worth advertising it now. Krzyszof raised the same point and then agreed to keep it, as seen here[1]. > > > + - items: > > + - enum: > > + - rockchip,rk3588-mali > > + - const: arm,mali-valhall-csf # Mali Valhall GPU > > model/revision is fully discoverable > > + > > + reg: > > +maxItems: 1 > > + > > + interrupts: > > +items: > > + - description: Job interrupt > > + - description: MMU interrupt > > + - description: GPU interrupt > > + > > + interrupt-names: > > +items: > > + - const: job > > + - const: mmu > > + - const: gpu > > + > > + clocks: > > +minItems: 1 > > +maxItems: 3 > > The function of each clock based on just the names below aren't too > evident. 'core' is, but then what is 'stacks'? Please add some > descriptions. > The names match the hardware architecture, where the core clock powers most of the GPU, the 'stacks' clock is for shader core stacks and the 'coregroup' is used by stacks and tilers. All this is defined as "logical power domains" and the implementer of the IP can decide to map them to individual physical power domains or to group everything into a minimum of one power domain. Hence the flexibility in describing the hardware. As for describing what the function of each power domain is, I'm afraid we need to keep it at "matches the architecture" for now and I will look into what more information can be added later. At the high level, the more power domains you have the more you can fine tune the power consumption of the GPU. > I expect there is better visibility into what's correct here than we had > on earlier h/w. IOW, I don't want to see different clocks for every SoC. > Same applies to power-domains. Afraid that's up to the SoC implementation to decide how they wire the power domains. Hardware is capable to automatically powering up the domains needed, as long as the relevant clocks are provided. B
Re: [PATCH v2] drm: panel-orientation-quirks: Add quirk for One Mix 2S
On Sun, Oct 01, 2023 at 02:21:43PM +0200, Hans de Goede wrote:
> Hi,
>
> On 10/1/23 13:47, Kai Uwe Broulik wrote:
> > The One Mix 2S is a mini laptop with a 1200x1920 portrait screen
> > mounted in a landscape oriented clamshell case. Because of the too
> > generic DMI strings this entry is also doing bios-date matching.
> >
> > Signed-off-by: Kai Uwe Broulik
> > ---
> > Changes since v1:
> > * Got two more BIOS dates reported
>
> Thanks, patch still looks good to me:
>
> Reviewed-by: Hans de Goede
>
> drm-misc maintainers, I'm currently traveling can
> one of you push this to drm-misc-fixes please?
Done. Have a safe trip.
Best regards,
Liviu
>
> Regards,
>
> Hans
>
>
>
>
> >
> > drivers/gpu/drm/drm_panel_orientation_quirks.c | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> > b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> > index 0cb646cb04ee..d5c15292ae93 100644
> > --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> > +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> > @@ -38,6 +38,14 @@ static const struct drm_dmi_panel_orientation_data
> > gpd_micropc = {
> > .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
> > };
> >
> > +static const struct drm_dmi_panel_orientation_data gpd_onemix2s = {
> > + .width = 1200,
> > + .height = 1920,
> > + .bios_dates = (const char * const []){ "05/21/2018", "10/26/2018",
> > + "03/04/2019", NULL },
> > + .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
> > +};
> > +
> > static const struct drm_dmi_panel_orientation_data gpd_pocket = {
> > .width = 1200,
> > .height = 1920,
> > @@ -401,6 +409,14 @@ static const struct dmi_system_id orientation_data[] =
> > {
> > DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "LTH17"),
> > },
> > .driver_data = (void *)_rightside_up,
> > + }, {/* One Mix 2S (generic strings, also match on bios date) */
> > + .matches = {
> > + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Default string"),
> > + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Default string"),
> > + DMI_EXACT_MATCH(DMI_BOARD_VENDOR, "Default string"),
> > + DMI_EXACT_MATCH(DMI_BOARD_NAME, "Default string"),
> > + },
> > + .driver_data = (void *)_onemix2s,
> > },
> > {}
> > };
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH v2 14/15] dt-bindings: gpu: mali-valhall-csf: Add initial bindings for panthor driver
On Wed, Sep 20, 2023 at 03:51:36PM +0200, Krzysztof Kozlowski wrote: > On 20/09/2023 15:41, Liviu Dudau wrote: > >>> +properties: > >>> + $nodename: > >>> +pattern: '^gpu@[a-f0-9]+$' > >>> + > >>> + compatible: > >>> +oneOf: > >> > >> Drop oneOf. > > > > The idea was to allow for future compatible strings to be added later, but > > I guess we can re-introduce the oneOf entry later. Will remove it. > > If you already predict that new list will be added (so new fallback > compatible!), then it's fine. > > > > >> > >>> + - items: > >>> + - enum: > >>> + - rockchip,rk3588-mali > >>> + - const: arm,mali-valhall-csf # Mali Valhall GPU > >>> model/revision is fully discoverable > >>> + > >>> + reg: > >>> +maxItems: 1 > >>> + > >>> + interrupts: > >>> +items: > >>> + - description: Job interrupt > >>> + - description: MMU interrupt > >>> + - description: GPU interrupt > >>> + > >>> + interrupt-names: > >>> +items: > >>> + - const: job > >>> + - const: mmu > >>> + - const: gpu > >>> + > >>> + clocks: > >>> +minItems: 1 > >>> +maxItems: 3 > >>> + > >>> + clock-names: > >>> +minItems: 1 > >>> +items: > >>> + - const: core > >>> + - const: coregroup > >>> + - const: stacks > >>> + > >>> + mali-supply: true > >>> + > >>> + sram-supply: true > >>> + > >>> + operating-points-v2: true > >> > >> Missing opp-table. > > > > This is the main topic I want to clarify. See further down for the main > > comment, > > but I would like to understand what you are asking here. To copy the schema > > from bindings/opp/opp-v2.yaml and bindings/opp/opp-v2-base.yaml? > > No, "opp-table" property. > git grep "opp-table:" You mean adding opp-table: type: object as property? What's the difference between opp-table: true (like in 'display/msm/dp-controller.yaml') and 'opp-table: type: object' like in other places that I can find? Does that mean you need to have an opp-table node somewhere but it doesn't have to be inside the gpu node? 'arm,mali-midgard.yaml' that was my original source of inspiration has an 'opp-table: type: object' in the properties but the example still shows a separate node for table. > > > > >> > >>> + > >>> + power-domains: > >>> +minItems: 1 > >>> +maxItems: 5 > >>> + > >>> + power-domain-names: > >>> +minItems: 1 > >>> +maxItems: 5 > >>> + > >>> + "#cooling-cells": > >>> +const: 2 > >>> + > >>> + dynamic-power-coefficient: > >>> +$ref: /schemas/types.yaml#/definitions/uint32 > >>> +description: > >>> + A u32 value that represents the running time dynamic > >>> + power coefficient in units of uW/MHz/V^2. The > >>> + coefficient can either be calculated from power > >>> + measurements or derived by analysis. > >>> + > >>> + The dynamic power consumption of the GPU is > >>> + proportional to the square of the Voltage (V) and > >>> + the clock frequency (f). The coefficient is used to > >>> + calculate the dynamic power as below - > >>> + > >>> + Pdyn = dynamic-power-coefficient * V^2 * f > >>> + > >>> + where voltage is in V, frequency is in MHz. > >>> + > >>> + dma-coherent: true > >>> + > >>> +required: > >>> + - compatible > >>> + - reg > >>> + - interrupts > >>> + - interrupt-names > >>> + - clocks > >>> + - mali-supply > >>> + > >>> +additionalProperties: false > >>> + > >>> +allOf: > >>> + - if: > >>> + properties: > >>> +compatible: > >>> + contains: > >>> +const: rockchip,rk3588-mali > >>> +then: > >>> + properties: > >>> +clocks: > >>&g
Re: [PATCH v2 14/15] dt-bindings: gpu: mali-valhall-csf: Add initial bindings for panthor driver
On Wed, Sep 20, 2023 at 03:56:24PM +0200, Boris Brezillon wrote: > On Wed, 20 Sep 2023 14:41:05 +0100 > Liviu Dudau wrote: > > > > > > > Please describe also power domains - constrains and names. > > > > I'm not sure the power domains and how to handle them have been > > entirely settled for Rockchip, hence why they were not included. Will > > check with Collabora to see if they have anything to add here, > > On rk3588, it's just one power domain feeding all GPU blocks. Not sure if this has been missed, but earlier in the file there is an entry for power-domains and power-domain-names, but with only a minimum of requirements and no mandate on the actual names. Best regards, Liviu > > > but > > for non-Rockchip platforms (like Juno with FPGAs) the constraints > > are going to be different. -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯
Re: [PATCH v2 14/15] dt-bindings: gpu: mali-valhall-csf: Add initial bindings for panthor driver
Hi Krzysztof, Thanks for taking the time to review this patch. I'm about to update it to address your comments and I need some clarifications from you. On Sun, Aug 20, 2023 at 10:01:25AM +0200, Krzysztof Kozlowski wrote: > On 09/08/2023 18:53, Boris Brezillon wrote: > > From: Liviu Dudau > > > > Arm has introduced a new v10 GPU architecture that replaces the Job Manager > > interface with a new Command Stream Frontend. It adds firmware driven > > command stream queues that can be used by kernel and user space to submit > > jobs to the GPU. > > > > Add the initial schema for the device tree that is based on support for > > RK3588 SoC. The minimum number of clocks is one for the IP, but on Rockchip > > platforms they will tend to expose the semi-independent clocks for better > > power management. > > A nit, subject: drop second/last, redundant "bindings for". The > "dt-bindings" prefix is already stating that these are bindings. > > Also drop "driver" form the subject. Bindings are for hardware, not drivers. Not exactly true as the 'compatible' string is for the driver, but I understand your point. > > > > > v2: > > - New commit > > > > Signed-off-by: Liviu Dudau > > SoB chain is incomplete. > > > Cc: Krzysztof Kozlowski > > Cc: Rob Herring > > Cc: Conor Dooley > > Cc: devicet...@vger.kernel.org > > --- > > .../bindings/gpu/arm,mali-valhall-csf.yaml| 148 ++ > > 1 file changed, 148 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml > > > > diff --git > > a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml > > b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml > > new file mode 100644 > > index ..2b9f77aa0b7a > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml > > @@ -0,0 +1,148 @@ > > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/gpu/arm,mali-valhall-csf.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: ARM Mali Valhall GPU > > + > > +maintainers: > > + - Liviu Dudau > > + - Boris Brezillon > > + > > +properties: > > + $nodename: > > +pattern: '^gpu@[a-f0-9]+$' > > + > > + compatible: > > +oneOf: > > Drop oneOf. The idea was to allow for future compatible strings to be added later, but I guess we can re-introduce the oneOf entry later. Will remove it. > > > + - items: > > + - enum: > > + - rockchip,rk3588-mali > > + - const: arm,mali-valhall-csf # Mali Valhall GPU > > model/revision is fully discoverable > > + > > + reg: > > +maxItems: 1 > > + > > + interrupts: > > +items: > > + - description: Job interrupt > > + - description: MMU interrupt > > + - description: GPU interrupt > > + > > + interrupt-names: > > +items: > > + - const: job > > + - const: mmu > > + - const: gpu > > + > > + clocks: > > +minItems: 1 > > +maxItems: 3 > > + > > + clock-names: > > +minItems: 1 > > +items: > > + - const: core > > + - const: coregroup > > + - const: stacks > > + > > + mali-supply: true > > + > > + sram-supply: true > > + > > + operating-points-v2: true > > Missing opp-table. This is the main topic I want to clarify. See further down for the main comment, but I would like to understand what you are asking here. To copy the schema from bindings/opp/opp-v2.yaml and bindings/opp/opp-v2-base.yaml? > > > + > > + power-domains: > > +minItems: 1 > > +maxItems: 5 > > + > > + power-domain-names: > > +minItems: 1 > > +maxItems: 5 > > + > > + "#cooling-cells": > > +const: 2 > > + > > + dynamic-power-coefficient: > > +$ref: /schemas/types.yaml#/definitions/uint32 > > +description: > > + A u32 value that represents the running time dynamic > > + power coefficient in units of uW/MHz/V^2. The > > + coefficient can either be calculated from power > > + measurements or derived by analysis. > > + > > + The dynamic power consumption of the GPU is > > + proportional to the square of the Voltage (V) and
Re: [PATCH v2 04/15] drm/panthor: Add the device logical block
On Wed, Aug 30, 2023 at 02:17:57PM +0100, Steven Price wrote:
> On 29/08/2023 15:00, Boris Brezillon wrote:
> > On Fri, 11 Aug 2023 16:47:56 +0100
> > Steven Price wrote:
> >
> >> On 09/08/2023 17:53, Boris Brezillon wrote:
> >>> The panthor driver is designed in a modular way, where each logical
> >>> block is dealing with a specific HW-block or software feature. In order
> >>> for those blocks to communicate with each other, we need a central
> >>> panthor_device collecting all the blocks, and exposing some common
> >>> features, like interrupt handling, power management, reset, ...
> >>>
> >>> This what this panthor_device logical block is about.
> >>>
> >>> v2:
> >>> - Rename the driver (pancsf -> panthor)
> >>> - Change the license (GPL2 -> MIT + GPL2)
> >>> - Split the driver addition commit
> >>> - Add devfreq/PM support
> >>> - Use drm_dev_{unplug,enter,exit}() to provide safe device removal
> >>>
> >>> Signed-off-by: Boris Brezillon
> >>> ---
> >>> drivers/gpu/drm/panthor/panthor_device.c | 479 +++
> >>> drivers/gpu/drm/panthor/panthor_device.h | 354 +
> >>> 2 files changed, 833 insertions(+)
> >>> create mode 100644 drivers/gpu/drm/panthor/panthor_device.c
> >>> create mode 100644 drivers/gpu/drm/panthor/panthor_device.h
> >>>
> >>> diff --git a/drivers/gpu/drm/panthor/panthor_device.c
> >>> b/drivers/gpu/drm/panthor/panthor_device.c
> >>> new file mode 100644
> >>> index ..15f102116fa0
> >>> --- /dev/null
> >>> +++ b/drivers/gpu/drm/panthor/panthor_device.c
> >>> @@ -0,0 +1,479 @@
> >>> +// SPDX-License-Identifier: GPL-2.0 or MIT
> >>> +/* Copyright 2018 Marty E. Plummer */
> >>> +/* Copyright 2019 Linaro, Ltd, Rob Herring */
> >>> +/* Copyright 2023 Collabora ltd. */
> >>> +
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +
> >>> +#include
> >>> +#include
> >>> +
> >>> +#include "panthor_sched.h"
> >>> +#include "panthor_device.h"
> >>> +#include "panthor_devfreq.h"
> >>> +#include "panthor_gpu.h"
> >>> +#include "panthor_fw.h"
> >>> +#include "panthor_mmu.h"
> >>> +#include "panthor_regs.h"
> >>> +
> >>> +static int panthor_clk_init(struct panthor_device *ptdev)
> >>> +{
> >>> + ptdev->clks.core = devm_clk_get(ptdev->base.dev, NULL);
> >>> + if (IS_ERR(ptdev->clks.core)) {
> >>> + drm_err(>base, "get 'core' clock failed %ld\n",
> >>> + PTR_ERR(ptdev->clks.core));
> >>
> >> I suspect it would be a good idea to use dev_err_probe() here (and
> >> below) as I believe devm_clk_get can return -EPROBE_DEFER.
> >
> > Nice, didn't know there was a logging function that was silencing
> > probe-defer errors.
> >
> >>
> >>> + return PTR_ERR(ptdev->clks.core);
> >>> + }
> >>> +
> >>> + ptdev->clks.stacks = devm_clk_get_optional(ptdev->base.dev, "stacks");
> >>> + if (IS_ERR(ptdev->clks.stacks)) {
> >>> + drm_err(>base, "get 'stacks' clock failed %ld\n",
> >>> + PTR_ERR(ptdev->clks.stacks));
> >>> + return PTR_ERR(ptdev->clks.stacks);
> >>> + }
> >>> +
> >>> + ptdev->clks.coregroup = devm_clk_get_optional(ptdev->base.dev,
> >>> "coregroup");
> >>> + if (IS_ERR(ptdev->clks.coregroup)) {
> >>> + drm_err(>base, "get 'coregroup' clock failed %ld\n",
> >>> + PTR_ERR(ptdev->clks.coregroup));
> >>> + return PTR_ERR(ptdev->clks.coregroup);
> >>> + }
> >>> +
> >>> + drm_info(>base, "clock rate = %lu\n",
> >>> clk_get_rate(ptdev->clks.core));
> >>> + return 0;
> >>> +}
> >>> +
> >>> +void panthor_device_unplug(struct panthor_device *ptdev)
> >>> +{
> >>> + /* FIXME: This is racy. */
> >>
> >> Can we fix this? From a quick look it seems like a sequence like below
> >> should avoid the race.
> >>
> >>if (!drm_dev_enter())
> >>/* Already unplugged */
> >>return;
> >>ptdev->base.unplugged = true;
> >>drm_dev_exit();
> >>
> >> Although possibly that should be in the DRM core rather than open-coded
> >> here.
> >
> > Are you sure that's protecting us against two concurrent calls to
> > drm_dev_unplug() (drm_dev_enter() is taking a read-lock)?
>
> Well now I'm not sure ;) This was based on the implementations of
> drm_dev_is_unplugged() and drm_dev_unplug(). drm_dev_is_unplugged()
> simply tries to enter then exit. drm_dev_unplug() sets dev->unplugged
> (without first taking any locks). So my naïve combination resulted in
> the above.
>
> The part I was missing is the synchronize_srcu() call in
> drm_dev_unplug() is what matches up with the read lock in drm_dev_enter().
>
> > And that's not
> > the only thing I need actually. If there are 2 threads entering
> > panthor_device_unplug(), I need to make sure the one who losts (arrived
> > after unplugged was set to false) is waiting for all operations after
> > the drm_dev_unplug() call to be done, otherwise we might return from
> > platform_driver->remove() before the unplug cleanups are done, and
> > there might
Re: [PATCH v2 02/15] drm/panthor: Add uAPI
_features;
> +
> + /** @tiler_features: Tiler features. */
> + __u32 tiler_features;
> +
> + /** @mem_features: Memory features. */
> + __u32 mem_features;
> +
> + /** @mmu_features: MMU features. */
> + __u32 mmu_features;
> +#define DRM_PANTHOR_MMU_VA_BITS(x) ((x) & 0xff)
> +
> + /** @thread_features: Thread features. */
> + __u32 thread_features;
> +
> + /** @max_threads: Maximum number of threads. */
> + __u32 max_threads;
> +
> + /** @thread_max_workgroup_size: Maximum workgroup size. */
> + __u32 thread_max_workgroup_size;
> +
> + /**
> + * @thread_max_barrier_size: Maximum number of threads that can wait
> + * simultaneously on a barrier.
> + */
> + __u32 thread_max_barrier_size;
> +
> + /** @coherency_features: Coherency features. */
> + __u32 coherency_features;
> +
> + /** @texture_features: Texture features. */
> + __u32 texture_features[4];
> +
> + /** @as_present: Bitmask encoding the number of address-space exposed
> by the MMU. */
> + __u32 as_present;
> +
> + /** @core_group_count: Number of core groups. */
> + __u32 core_group_count;
> +
> + /** @pad: Zero on return. */
> + __u32 pad;
> +
> + /** @shader_present: Bitmask encoding the shader cores exposed by the
> GPU. */
> + __u64 shader_present;
> +
> + /** @l2_present: Bitmask encoding the L2 caches exposed by the GPU. */
> + __u64 l2_present;
> +
> + /** @tiler_present: Bitmask encoding the tiler unit exposed by the GPU.
> */
> + __u64 tiler_present;
> +};
> +
> +/**
> + * struct drm_panthor_csif_info - Command stream interface information
> + *
> + * Structure grouping all queryable information relating to the command
> stream interface.
> + */
> +struct drm_panthor_csif_info {
> + /** @csg_slot_count: Number of command stream group slots exposed by
> the firmware. */
> + __u32 csg_slot_count;
> +
> + /** @cs_slot_count: Number of command stream slot per group. */
> + __u32 cs_slot_count;
> +
> + /** @cs_reg_count: Number of command stream register. */
> + __u32 cs_reg_count;
> +
> + /** @scoreboard_slot_count: Number of scoreboard slot. */
> + __u32 scoreboard_slot_count;
> +
> + /**
> + * @unpreserved_cs_reg_count: Number of command stream registers
> reserved by
> + * the kernel driver to call a userspace command stream.
> + *
> + * All registers can be used by a userspace command stream, but the
> + * [cs_slot_count - unpreserved_cs_reg_count .. cs_slot_count]
> registers are
> + * used by the kernel when DRM_PANTHOR_IOCTL_GROUP_SUBMIT is called.
> + */
> + __u32 unpreserved_cs_reg_count;
> +
> + /**
> + * @pad: Padding field, set to zero.
> + */
> + __u32 pad;
> +};
> +
> +/**
> + * struct drm_panthor_dev_query - Arguments passed to
> DRM_PANTHOR_IOCTL_DEV_QUERY
> + */
> +struct drm_panthor_dev_query {
> + /** @type: the query type (see drm_panthor_dev_query_type). */
> + __u32 type;
> +
> + /**
> + * @size: size of the type being queried.
> + *
> + * If pointer is NULL, size is updated by the driver to provide the
> + * output structure size. If pointer is not NULL, the driver will
> + * only copy min(size, actual_structure_size) bytes to the pointer,
> + * and update the size accordingly. This allows us to extend query
> + * types without breaking userspace.
> + */
> + __u32 size;
> +
> + /**
> + * @pointer: user pointer to a query type struct.
> + *
> + * Pointer can be NULL, in which case, nothing is copied, but the
> + * actual structure size is returned. If not NULL, it must point to
> + * a location that's large enough to hold size bytes.
> + */
> + __u64 pointer;
> +};
> +
> +/**
> + * struct drm_panthor_vm_create - Arguments passed to
> DRM_PANTHOR_IOCTL_VM_CREATE
> + */
> +struct drm_panthor_vm_create {
> + /** @flags: VM flags, MBZ. */
> + __u32 flags;
> +
> + /** @id: Returned VM ID. */
> + __u32 id;
> +
> + /**
> + * @kernel_va_range: Size of the VA space reserved for kernel objects.
> + *
> + * If kernel_va_range is zero, we pick half of the VA space for kernel
> objects.
> + *
> + * Kernel VA space is always placed at the top of the supported VA
> range.
> + */
> + __u64 kernel_va_range;
> +};
> +
> +/**
> + * struct drm_panthor_vm_destroy - Arguments passed to
> DRM_PANTHOR_IOCTL_VM_DESTROY
>
Re: [PATCH v2 15/15] drm/panthor: Add an entry to MAINTAINERS
Hi Boris, On Wed, Aug 09, 2023 at 06:53:28PM +0200, Boris Brezillon wrote: > Add an entry for the Panthor driver to the MAINTAINERS file. > > v2: > - New commit > > Signed-off-by: Boris Brezillon > --- > > If anyone from Arm wants to volunteer to become a co-maintainer, that > would be highly appreciated > --- > MAINTAINERS | 8 > 1 file changed, 8 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index cd882b87a3c6..6149ab68d461 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1624,6 +1624,14 @@ T: git git://anongit.freedesktop.org/drm/drm-misc > F: drivers/gpu/drm/panfrost/ > F: include/uapi/drm/panfrost_drm.h > > +ARM MALI PANTHOR DRM DRIVER > +M: Boris Brezillon > +L: dri-devel@lists.freedesktop.org > +S: Supported > +T: git git://anongit.freedesktop.org/drm/drm-misc > +F: drivers/gpu/drm/panthor/ > +F: include/uapi/drm/panthor_drm.h Can we also add an entry for the bindings? +F: Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml Also, I would like to volunteer as maintainer alongside Steven, so can I please get added too? Best regards, Liviu > + > ARM MALI-DP DRM DRIVER > M: Liviu Dudau > S: Supported > -- > 2.41.0 > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯
Re: [PATCH v3 3/3] drm/komeda: Fix IS_ERR() vs NULL check in komeda_component_get_avail_scaler()
Hi Gaosheng,
On Fri, Jul 14, 2023 at 09:48:20AM +0800, Gaosheng Cui wrote:
> The komeda_pipeline_get_state() returns an ERR_PTR() on failure, we should
> use IS_ERR() to check the return value.
>
> Fixes: 502932a03fce ("drm/komeda: Add the initial scaler support for CORE")
> Signed-off-by: Gaosheng Cui
> Reviewed-by: Liviu Dudau
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> index 3276a3e82c62..e9c92439398d 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> @@ -259,7 +259,7 @@ komeda_component_get_avail_scaler(struct komeda_component
> *c,
> u32 avail_scalers;
>
> pipe_st = komeda_pipeline_get_state(c->pipeline, state);
> - if (!pipe_st)
> + if (IS_ERR(pipe_st))
If you're going to update the other patches to use IS_ERR_OR_NULL() please do so
here too. You can keep my R-b for that change.
Best regards,
Liviu
> return NULL;
>
> avail_scalers = (pipe_st->active_comps & KOMEDA_PIPELINE_SCALERS) ^
> --
> 2.25.1
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH v3] drm/arm/komeda: Remove component framework and add a simple encoder
On Wed, Jul 12, 2023 at 12:19:37PM +0530, Faiz Abbas wrote:
> The Komeda driver always expects the remote connector node to initialize
> an encoder. It uses the component aggregator framework which consists
> of component->bind() calls used to initialize the remote encoder and attach
> it to the crtc. This makes it incompatible with connector drivers which
> implement drm_bridge APIs.
>
> Remove all component framework calls from the komeda driver and declare and
> attach an encoder inside komeda_crtc_add().
>
> The remote connector driver has to implement the DRM bridge APIs which
> can be used to glue the encoder to the remote connector. Since we
> usually pair this with a component encoder that also implements a
> drm_bridge, dropping support is not expected to affect users of this
> driver.
>
> Signed-off-by: Faiz Abbas
Sorry for the delay in replying, I thought I already did. Patch looks good
and thanks for the effort.
Reviewed-by: Liviu Dudau
I'm going to pull this into drm-misc-next by the end of the week.
Best regards,
Liviu
> ---
> v3 -> v2:
> * Rebased to latest drm-misc-next
>
> v2 -> v1:
>
> * Removed additional instances of component APIs
>
> .../gpu/drm/arm/display/komeda/komeda_crtc.c | 23 +++-
> .../gpu/drm/arm/display/komeda/komeda_drv.c | 55 ++-
> .../gpu/drm/arm/display/komeda/komeda_kms.c | 11 +---
> .../gpu/drm/arm/display/komeda/komeda_kms.h | 3 +
> 4 files changed, 30 insertions(+), 62 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index cea3fd5772b57..b615d625c244f 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -12,6 +12,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "komeda_dev.h"
> #include "komeda_kms.h"
> @@ -612,9 +614,11 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
> struct komeda_crtc *kcrtc)
> {
> struct drm_crtc *crtc = >base;
> + struct drm_device *base = >base;
> + struct drm_bridge *bridge;
> int err;
>
> - err = drm_crtc_init_with_planes(>base, crtc,
> + err = drm_crtc_init_with_planes(base, crtc,
> get_crtc_primary(kms, kcrtc), NULL,
> _crtc_funcs, NULL);
> if (err)
> @@ -624,6 +628,23 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
>
> crtc->port = kcrtc->master->of_output_port;
>
> +
> + /* Construct an encoder for each pipeline and attach it to the remote
> + * bridge
> + */
> + kcrtc->encoder.possible_crtcs = drm_crtc_mask(crtc);
> + err = drm_simple_encoder_init(base, >encoder,
> + DRM_MODE_ENCODER_TMDS);
> + if (err)
> + return err;
> +
> + bridge = devm_drm_of_get_bridge(base->dev, kcrtc->master->of_node,
> + KOMEDA_OF_PORT_OUTPUT, 0);
> + if (IS_ERR(bridge))
> + return PTR_ERR(bridge);
> +
> + err = drm_bridge_attach(>encoder, bridge, NULL, 0);
> +
> drm_crtc_enable_color_mgmt(crtc, 0, true, KOMEDA_COLOR_LUT_SIZE);
>
> return err;
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> index c597c362f6892..cb2a2be24c5ff 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> @@ -8,7 +8,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -28,13 +27,11 @@ struct komeda_dev *dev_to_mdev(struct device *dev)
> return mdrv ? mdrv->mdev : NULL;
> }
>
> -static void komeda_unbind(struct device *dev)
> +static void komeda_platform_remove(struct platform_device *pdev)
> {
> + struct device *dev = >dev;
> struct komeda_drv *mdrv = dev_get_drvdata(dev);
>
> - if (!mdrv)
> - return;
> -
> komeda_kms_detach(mdrv->kms);
>
> if (pm_runtime_enabled(dev))
> @@ -48,8 +45,9 @@ static void komeda_unbind(struct device *dev)
> devm_kfree(dev, mdrv);
> }
>
> -static int komeda_bind(struct device *dev)
> +static int komeda_platform_probe(struct platform_device *pdev)
> {
> + struct device *dev = >dev;
> struct komeda_drv *mdrv;
> int err;
>
> @@ -91,51 +89,6 @@ static int komeda_bind(struct device *dev)
> return err;
> }
>
Re: [PATCH] drm: Explicitly include correct DT includes
On Fri, Jul 14, 2023 at 11:45:34AM -0600, Rob Herring wrote: > The DT of_device.h and of_platform.h date back to the separate > of_platform_bus_type before it as merged into the regular platform bus. > As part of that merge prepping Arm DT support 13 years ago, they > "temporarily" include each other. They also include platform_device.h > and of.h. As a result, there's a pretty much random mix of those include > files used throughout the tree. In order to detangle these headers and > replace the implicit includes with struct declarations, users need to > explicitly include the correct includes. > > Signed-off-by: Rob Herring > --- > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c > b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c > index cc7664c95a54..14ee79becacb 100644 > --- a/drivers/gpu/drm/arm/display/komeda/komeda_dev.c > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_dev.c > @@ -6,7 +6,7 @@ > */ > #include > #include > -#include > +#include > #include > #include > #include > diff --git a/drivers/gpu/drm/arm/malidp_drv.c > b/drivers/gpu/drm/arm/malidp_drv.c > index c03cfd57b752..a5a9534d4353 100644 > --- a/drivers/gpu/drm/arm/malidp_drv.c > +++ b/drivers/gpu/drm/arm/malidp_drv.c > @@ -12,6 +12,7 @@ > #include > #include > #include > +#include > #include > #include > For the komeda and malidp drivers: Acked-by: Liviu Dudau Best regards, Liviu > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c > b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c > index 99964f5a5457..2a6b91f752cb 100644 > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c > @@ -7,7 +7,6 @@ > > #include > #include > -#include > #include > #include > > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > index 2254457ab5d0..b9957da0f55a 100644 > --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c > @@ -9,7 +9,7 @@ > #include > #include > #include > -#include > +#include > #include > > #include > diff --git a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c > b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c > index f50d65f54314..7457d38622b0 100644 > --- a/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c > +++ b/drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c > @@ -14,8 +14,7 @@ > #include > #include > #include > -#include > -#include > +#include > #include > #include > #include > diff --git a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c > b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c > index f6822dfa3805..4aff817f82ce 100644 > --- a/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c > +++ b/drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c > @@ -29,7 +29,6 @@ > #include > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/bridge/chipone-icn6211.c > b/drivers/gpu/drm/bridge/chipone-icn6211.c > index 8bfce21d6b90..d205e755e524 100644 > --- a/drivers/gpu/drm/bridge/chipone-icn6211.c > +++ b/drivers/gpu/drm/bridge/chipone-icn6211.c > @@ -17,7 +17,7 @@ > #include > #include > #include > -#include > +#include > #include > #include > > diff --git a/drivers/gpu/drm/bridge/display-connector.c > b/drivers/gpu/drm/bridge/display-connector.c > index f7f436cf96e0..08bd5695ddae 100644 > --- a/drivers/gpu/drm/bridge/display-connector.c > +++ b/drivers/gpu/drm/bridge/display-connector.c > @@ -10,7 +10,6 @@ > #include > #include > #include > -#include > #include > #include > > diff --git a/drivers/gpu/drm/bridge/fsl-ldb.c > b/drivers/gpu/drm/bridge/fsl-ldb.c > index b8e52156b07a..0e4bac7dd04f 100644 > --- a/drivers/gpu/drm/bridge/fsl-ldb.c > +++ b/drivers/gpu/drm/bridge/fsl-ldb.c > @@ -8,7 +8,6 @@ > #include > #include > #include > -#include > #include > #include > #include > diff --git a/drivers/gpu/drm/bridge/imx/imx8qm-ldb.c > b/drivers/gpu/drm/bridge/imx/imx8qm-ldb.c > index 386032a02599..21471a9a28b2 100644 > --- a/drivers/gpu/drm/bridge/imx/imx8qm-ldb.c > +++ b/drivers/gpu/drm/bridge/imx/imx8qm-ldb.c > @@ -9,9 +9,9 @@ > #include > #include > #include > -#include > #include > #include > +#include > #include > #include > > diff --git a/drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c > b/drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c > index c806576b1e22..7984da9c0a35 100644 > --- a/drivers/gpu/drm
Re: [PATCH v2 3/3] drm/komeda: Fix IS_ERR() vs NULL check in komeda_component_get_avail_scaler()
On Thu, Jul 13, 2023 at 05:51:34PM +0800, cuigaosheng wrote:
> Thanks for taking time to review this patch.
>
> Maybe we can submit another separate patch to fix ERR_CAST(st), because I'm
> not
> sure which commit should be used as a fixes-tag.
>
> Also, Maybe we should fix ERR_CAST(st) in
> komeda_pipeline_get_state_and_set_crtc()
> and komeda_component_get_state_and_set_user(), please make another separate
> patch.
Yeah, you're right, there are other places where this needs to be fixed.
I will add this to my list of ToDos.
Best regards,
Liviu
>
> Let me know if there's anything I can do, thanks for your work again!
>
> Gaosheng,
>
> On 2023/7/13 16:54, Liviu Dudau wrote:
> > Hello,
> >
> > On Thu, Jul 13, 2023 at 10:05:56AM +0800, Gaosheng Cui wrote:
> > > The komeda_pipeline_get_state() returns an ERR_PTR() on failure, we should
> > > use IS_ERR() to check the return value.
> > While reviewing the change I've realised that
> > komeda_pipeline_get_state_and_set_crtc()
> > is also mishandling the return value from komeda_pipeline_get_state(). If
> > IS_ERR(st) is
> > true it should use return ERR_CAST(st), following the same pattern as
> > komeda_pipeline_get_state().
> >
> > If you don't want to update this patch I can send a separate patch.
> > Otherwise,
> > the change looks good to me.
> >
> > Reviewed-by: Liviu Dudau
> >
> > Best regards,
> > Liviu
> >
> >
> > > Fixes: 502932a03fce ("drm/komeda: Add the initial scaler support for
> > > CORE")
> > > Signed-off-by: Gaosheng Cui
> > > ---
> > > drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > > b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > > index 3276a3e82c62..e9c92439398d 100644
> > > --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> > > @@ -259,7 +259,7 @@ komeda_component_get_avail_scaler(struct
> > > komeda_component *c,
> > > u32 avail_scalers;
> > > pipe_st = komeda_pipeline_get_state(c->pipeline, state);
> > > - if (!pipe_st)
> > > + if (IS_ERR(pipe_st))
> > > return NULL;
> > > avail_scalers = (pipe_st->active_comps &
> > > KOMEDA_PIPELINE_SCALERS) ^
> > > --
> > > 2.25.1
> > >
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH v2 3/3] drm/komeda: Fix IS_ERR() vs NULL check in komeda_component_get_avail_scaler()
Hello,
On Thu, Jul 13, 2023 at 10:05:56AM +0800, Gaosheng Cui wrote:
> The komeda_pipeline_get_state() returns an ERR_PTR() on failure, we should
> use IS_ERR() to check the return value.
While reviewing the change I've realised that
komeda_pipeline_get_state_and_set_crtc()
is also mishandling the return value from komeda_pipeline_get_state(). If
IS_ERR(st) is
true it should use return ERR_CAST(st), following the same pattern as
komeda_pipeline_get_state().
If you don't want to update this patch I can send a separate patch. Otherwise,
the change looks good to me.
Reviewed-by: Liviu Dudau
Best regards,
Liviu
>
> Fixes: 502932a03fce ("drm/komeda: Add the initial scaler support for CORE")
> Signed-off-by: Gaosheng Cui
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> index 3276a3e82c62..e9c92439398d 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> @@ -259,7 +259,7 @@ komeda_component_get_avail_scaler(struct komeda_component
> *c,
> u32 avail_scalers;
>
> pipe_st = komeda_pipeline_get_state(c->pipeline, state);
> - if (!pipe_st)
> + if (IS_ERR(pipe_st))
> return NULL;
>
> avail_scalers = (pipe_st->active_comps & KOMEDA_PIPELINE_SCALERS) ^
> --
> 2.25.1
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH v2] drm/arm/komeda: Remove component framework and add a simple encoder
Hi Faiz,
On Tue, Jul 04, 2023 at 10:04:54PM +0530, Faiz Abbas wrote:
> The Komeda driver always expects the remote connector node to initialize
> an encoder. It uses the component aggregator framework which consists
> of component->bind() calls used to initialize the remote encoder and attach
> it to the crtc. This makes it incompatible with connector drivers which
> implement drm_bridge APIs.
>
> Remove all component framework calls from the komeda driver and declare and
> attach an encoder inside komeda_crtc_add().
>
> The remote connector driver has to implement the DRM bridge APIs which
> can be used to glue the encoder to the remote connector. Since we
> usually pair this with a component encoder that also implements a
> drm_bridge, dropping support is not expected to affect users of this
> driver.
Thanks for updating the commit description, I think it shows the intent better.
When I'm trying to apply your patch to drm-misc next (or any branch that
matters)
it fails because ...
>
> Signed-off-by: Faiz Abbas
> ---
> .../gpu/drm/arm/display/komeda/komeda_crtc.c | 23 +++-
> .../gpu/drm/arm/display/komeda/komeda_drv.c | 57 ++-
> .../gpu/drm/arm/display/komeda/komeda_kms.c | 10 +---
> .../gpu/drm/arm/display/komeda/komeda_kms.h | 3 +
> 4 files changed, 32 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index 4cc07d6bb9d82..e5a8a80b173f4 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -13,6 +13,8 @@
> #include
... this line is different in my tree. It looks like your tree is missing
commit e3b63718827880 ("drm/arm/komeda: Remove unnecessary include
statements for drm_crtc_helper.h"), which has been applied in early January.
Best regards,
Liviu
> #include
> #include
> +#include
> +#include
>
> #include "komeda_dev.h"
> #include "komeda_kms.h"
> @@ -613,9 +615,11 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
> struct komeda_crtc *kcrtc)
> {
> struct drm_crtc *crtc = >base;
> + struct drm_device *base = >base;
> + struct drm_bridge *bridge;
> int err;
>
> - err = drm_crtc_init_with_planes(>base, crtc,
> + err = drm_crtc_init_with_planes(base, crtc,
> get_crtc_primary(kms, kcrtc), NULL,
> _crtc_funcs, NULL);
> if (err)
> @@ -625,6 +629,23 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
>
> crtc->port = kcrtc->master->of_output_port;
>
> +
> + /* Construct an encoder for each pipeline and attach it to the remote
> + * bridge
> + */
> + kcrtc->encoder.possible_crtcs = drm_crtc_mask(crtc);
> + err = drm_simple_encoder_init(base, >encoder,
> + DRM_MODE_ENCODER_TMDS);
> + if (err)
> + return err;
> +
> + bridge = devm_drm_of_get_bridge(base->dev, kcrtc->master->of_node,
> + KOMEDA_OF_PORT_OUTPUT, 0);
> + if (IS_ERR(bridge))
> + return PTR_ERR(bridge);
> +
> + err = drm_bridge_attach(>encoder, bridge, NULL, 0);
> +
> drm_crtc_enable_color_mgmt(crtc, 0, true, KOMEDA_COLOR_LUT_SIZE);
>
> return err;
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> index 9fce4239d4ad4..98e7ca1ad8fe7 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> @@ -7,7 +7,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -27,13 +26,11 @@ struct komeda_dev *dev_to_mdev(struct device *dev)
> return mdrv ? mdrv->mdev : NULL;
> }
>
> -static void komeda_unbind(struct device *dev)
> +static int komeda_platform_remove(struct platform_device *pdev)
> {
> + struct device *dev = >dev;
> struct komeda_drv *mdrv = dev_get_drvdata(dev);
>
> - if (!mdrv)
> - return;
> -
> komeda_kms_detach(mdrv->kms);
>
> if (pm_runtime_enabled(dev))
> @@ -45,10 +42,13 @@ static void komeda_unbind(struct device *dev)
>
> dev_set_drvdata(dev, NULL);
> devm_kfree(dev, mdrv);
> +
> + return 0;
> }
>
> -static int komeda_bind(struct device *dev)
> +static int komeda_platform_probe(struct platform_device *pdev)
> {
> + struct device *dev = >dev;
> struct komeda_drv *mdrv;
> int err;
>
> @@ -88,52 +88,7 @@ static int komeda_bind(struct device *dev)
> free_mdrv:
> devm_kfree(dev, mdrv);
> return err;
> -}
> -
> -static const struct component_master_ops komeda_master_ops = {
> - .bind = komeda_bind,
> - .unbind = komeda_unbind,
> -};
>
> -static void komeda_add_slave(struct device *master,
> - struct
Re: [PATCH v4 3/5] drm/arm: Make ARM devices menu depend on DRM
On Tue, Jul 04, 2023 at 01:05:27AM +0200, Javier Martinez Canillas wrote: > Otherwise if CONFIG_DRM is disabled, menuconfig will show an empty menu. > > Signed-off-by: Javier Martinez Canillas Acked-by: Liviu Dudau Best regards, Liviu > --- > > (no changes since v1) > > drivers/gpu/drm/arm/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig > index c1b89274d2a4..ddf20708370f 100644 > --- a/drivers/gpu/drm/arm/Kconfig > +++ b/drivers/gpu/drm/arm/Kconfig > @@ -1,5 +1,6 @@ > # SPDX-License-Identifier: GPL-2.0 > menu "ARM devices" > + depends on DRM > > config DRM_HDLCD > tristate "ARM HDLCD" > -- > 2.41.0 > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯
Re: [PATCH] drm/arm/komeda: Remove component framework and add a simple encoder
Hi Faiz,
Thanks for the patch and for addressing what was at some moment on my "nice to
improve / cleanup" list. Sorry for the delay in responding, I had to revive
the bits of an old setup to be able to test this properly, with 2 encoders
attached.
On Wed, Jun 21, 2023 at 02:11:16PM +0530, Faiz Abbas wrote:
> The Komeda driver always expects the remote connector node to initialize
> an encoder. It uses the component aggregator framework which consists
> of component->bind() calls used to initialize the remote encoder and attach
> it to the crtc. This is different from other drm implementations which expect
> the display driver to supply a crtc and connect an encoder to it.
I think both approaches are valid in DRM. We don't want to remove the component
framework because it is doing the wrong thing, but because we cannot use it
with drivers that implement the drm_bridge API. Given that we usually pair with
a component encoder that also implements a drm_bridge, dropping support for
component framework should not affect the users of the driver.
>
> Remove all component framework calls from the komeda driver and declare and
> attach an encoder inside komeda_crtc_add().
Unfortunately you haven't removed all component framework calls. The hint for
that is that you have not removed the #include line from
any of the files. Specifically, komeda_kms_attach()/detach() still calls
component_unbind_all() which will crash with your patch applied.
>
> The remote connector driver has to implement the DRM bridge APIs which
> can be used to glue the encoder to the remote connector.
>
> Signed-off-by: Faiz Abbas
> ---
> .../gpu/drm/arm/display/komeda/komeda_crtc.c | 22 +++-
> .../gpu/drm/arm/display/komeda/komeda_drv.c | 56 ++-
> .../gpu/drm/arm/display/komeda/komeda_kms.c | 4 --
> .../gpu/drm/arm/display/komeda/komeda_kms.h | 3 +
> 4 files changed, 30 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index cea3fd5772b57..144736a69b0ee 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -12,6 +12,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "komeda_dev.h"
> #include "komeda_kms.h"
> @@ -612,9 +614,11 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
> struct komeda_crtc *kcrtc)
> {
> struct drm_crtc *crtc = >base;
> + struct drm_device *base = >base;
> + struct drm_bridge *bridge;
> int err;
>
> - err = drm_crtc_init_with_planes(>base, crtc,
> + err = drm_crtc_init_with_planes(base, crtc,
> get_crtc_primary(kms, kcrtc), NULL,
> _crtc_funcs, NULL);
> if (err)
> @@ -626,6 +630,22 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
>
> drm_crtc_enable_color_mgmt(crtc, 0, true, KOMEDA_COLOR_LUT_SIZE);
I would move this line after the bridges are being initialised, just in case in
the future
colour management will propagate some info down to the bridges.
>
> + /* Construct an encoder for each pipeline and attach it to the remote
> + * bridge
> + */
> + kcrtc->encoder.possible_crtcs = drm_crtc_mask(crtc);
> + err = drm_simple_encoder_init(base, >encoder,
> + DRM_MODE_ENCODER_TMDS);
> + if (err)
> + return err;
> +
> + bridge = devm_drm_of_get_bridge(base->dev, kcrtc->master->of_node,
> + KOMEDA_OF_PORT_OUTPUT, 0);
> + if (IS_ERR(bridge))
> + return PTR_ERR(bridge);
I'm a bit undecided on whether to make the absence of a bridge here fatal or
not.
For the second pipeline it should be possible to act as a slave to the first
pipeline even if it doesn't have a bridge attached, but I need to investigate a
bit more here. The bindings suggest that this is mandatory, so keep it for now.
> +
> + err = drm_bridge_attach(>encoder, bridge, NULL, 0);
> +
> return err;
> }
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> index 28f76e07dd958..70b1b693c6eff 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> @@ -28,13 +28,11 @@ struct komeda_dev *dev_to_mdev(struct device *dev)
> return mdrv ? mdrv->mdev : NULL;
> }
>
> -static void komeda_unbind(struct device *dev)
> +static int komeda_platform_remove(struct platform_device *pdev)
> {
> + struct device *dev = >dev;
> struct komeda_drv *mdrv = dev_get_drvdata(dev);
>
> - if (!mdrv)
> - return;
> -
> komeda_kms_detach(mdrv->kms);
>
> if (pm_runtime_enabled(dev))
> @@ -46,10 +44,13 @@ static void komeda_unbind(struct device *dev)
>
>
Re: [PATCH 02/36] drm/drm_property: make replace_property_blob_from_id a DRM helper
On Tue, May 23, 2023 at 09:14:46PM -0100, Melissa Wen wrote:
> Place it in drm_property where drm_property_replace_blob and
> drm_property_lookup_blob live. Then we can use the DRM helper for
> driver-specific KMS properties too.
>
> Signed-off-by: Melissa Wen
I know that I've got Cc-ed because of a comment, but I did have a look at the
whole
patch. If it is useful, then you can add
Reviewed-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/malidp_crtc.c | 2 +-
> drivers/gpu/drm/drm_atomic_uapi.c | 43 ---
> drivers/gpu/drm/drm_property.c| 49 +++
> include/drm/drm_property.h| 6
> 4 files changed, 61 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_crtc.c
> b/drivers/gpu/drm/arm/malidp_crtc.c
> index dc01c43f6193..d72c22dcf685 100644
> --- a/drivers/gpu/drm/arm/malidp_crtc.c
> +++ b/drivers/gpu/drm/arm/malidp_crtc.c
> @@ -221,7 +221,7 @@ static int malidp_crtc_atomic_check_ctm(struct drm_crtc
> *crtc,
>
> /*
>* The size of the ctm is checked in
> - * drm_atomic_replace_property_blob_from_id.
> + * drm_property_replace_blob_from_id.
>*/
> ctm = (struct drm_color_ctm *)state->ctm->data;
> for (i = 0; i < ARRAY_SIZE(ctm->matrix); ++i) {
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index c06d0639d552..b76d50ae244c 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -362,39 +362,6 @@ static s32 __user *get_out_fence_for_connector(struct
> drm_atomic_state *state,
> return fence_ptr;
> }
>
> -static int
> -drm_atomic_replace_property_blob_from_id(struct drm_device *dev,
> - struct drm_property_blob **blob,
> - uint64_t blob_id,
> - ssize_t expected_size,
> - ssize_t expected_elem_size,
> - bool *replaced)
> -{
> - struct drm_property_blob *new_blob = NULL;
> -
> - if (blob_id != 0) {
> - new_blob = drm_property_lookup_blob(dev, blob_id);
> - if (new_blob == NULL)
> - return -EINVAL;
> -
> - if (expected_size > 0 &&
> - new_blob->length != expected_size) {
> - drm_property_blob_put(new_blob);
> - return -EINVAL;
> - }
> - if (expected_elem_size > 0 &&
> - new_blob->length % expected_elem_size != 0) {
> - drm_property_blob_put(new_blob);
> - return -EINVAL;
> - }
> - }
> -
> - *replaced |= drm_property_replace_blob(blob, new_blob);
> - drm_property_blob_put(new_blob);
> -
> - return 0;
> -}
> -
> static int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> struct drm_crtc_state *state, struct drm_property *property,
> uint64_t val)
> @@ -415,7 +382,7 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
> *crtc,
> } else if (property == config->prop_vrr_enabled) {
> state->vrr_enabled = val;
> } else if (property == config->degamma_lut_property) {
> - ret = drm_atomic_replace_property_blob_from_id(dev,
> + ret = drm_property_replace_blob_from_id(dev,
> >degamma_lut,
> val,
> -1, sizeof(struct drm_color_lut),
> @@ -423,7 +390,7 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
> *crtc,
> state->color_mgmt_changed |= replaced;
> return ret;
> } else if (property == config->ctm_property) {
> - ret = drm_atomic_replace_property_blob_from_id(dev,
> + ret = drm_property_replace_blob_from_id(dev,
> >ctm,
> val,
> sizeof(struct drm_color_ctm), -1,
> @@ -431,7 +398,7 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
> *crtc,
> state->color_mgmt_changed |= replaced;
> return ret;
> } else if (property == config->gamma_lut_property) {
> - ret = drm_atomic_replace_property_blob_from_id(dev,
> + ret = drm_property_replace_blob_from_id(dev,
> >gamma_lut,
>
Re: [PATCH 03/53] drm/arm/malidp: Convert to platform remove callback returning void
On Sun, May 07, 2023 at 06:25:26PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/malidp_drv.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 589c1c66a6dc..389ef1c3d9b6 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -936,10 +936,9 @@ static int malidp_platform_probe(struct platform_device
> *pdev)
> match);
> }
>
> -static int malidp_platform_remove(struct platform_device *pdev)
> +static void malidp_platform_remove(struct platform_device *pdev)
> {
> component_master_del(>dev, _master_ops);
> - return 0;
> }
>
> static int __maybe_unused malidp_pm_suspend(struct device *dev)
> @@ -982,7 +981,7 @@ static const struct dev_pm_ops malidp_pm_ops = {
>
> static struct platform_driver malidp_platform_driver = {
> .probe = malidp_platform_probe,
> - .remove = malidp_platform_remove,
> + .remove_new = malidp_platform_remove,
> .driver = {
> .name = "mali-dp",
> .pm = _pm_ops,
> --
> 2.39.2
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH 02/53] drm/arm/hdlcd: Convert to platform remove callback returning void
On Sun, May 07, 2023 at 06:25:25PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/hdlcd_drv.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index e3507dd6f82a..5e265c81a1b3 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -369,10 +369,9 @@ static int hdlcd_probe(struct platform_device *pdev)
> match);
> }
>
> -static int hdlcd_remove(struct platform_device *pdev)
> +static void hdlcd_remove(struct platform_device *pdev)
> {
> component_master_del(>dev, _master_ops);
> - return 0;
> }
>
> static const struct of_device_id hdlcd_of_match[] = {
> @@ -401,7 +400,7 @@ static SIMPLE_DEV_PM_OPS(hdlcd_pm_ops, hdlcd_pm_suspend,
> hdlcd_pm_resume);
>
> static struct platform_driver hdlcd_platform_driver = {
> .probe = hdlcd_probe,
> - .remove = hdlcd_remove,
> + .remove_new = hdlcd_remove,
> .driver = {
> .name = "hdlcd",
> .pm = _pm_ops,
> --
> 2.39.2
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH 01/53] drm/komeda: Convert to platform remove callback returning void
On Sun, May 07, 2023 at 06:25:24PM +0200, Uwe Kleine-König wrote:
> The .remove() callback for a platform driver returns an int which makes
> many driver authors wrongly assume it's possible to do error handling by
> returning an error code. However the value returned is (mostly) ignored
> and this typically results in resource leaks. To improve here there is a
> quest to make the remove callback return void. In the first step of this
> quest all drivers are converted to .remove_new() which already returns
> void.
>
> Trivially convert this driver from always returning zero in the remove
> callback to the void returning variant.
>
> Signed-off-by: Uwe Kleine-König
Acked-by: Liviu Dudau
Thanks for the clean up!
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> index 28f76e07dd95..c597c362f689 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> @@ -131,10 +131,9 @@ static int komeda_platform_probe(struct platform_device
> *pdev)
> return component_master_add_with_match(dev, _master_ops, match);
> }
>
> -static int komeda_platform_remove(struct platform_device *pdev)
> +static void komeda_platform_remove(struct platform_device *pdev)
> {
> component_master_del(>dev, _master_ops);
> - return 0;
> }
>
> static const struct of_device_id komeda_of_match[] = {
> @@ -189,7 +188,7 @@ static const struct dev_pm_ops komeda_pm_ops = {
>
> static struct platform_driver komeda_platform_driver = {
> .probe = komeda_platform_probe,
> - .remove = komeda_platform_remove,
> + .remove_new = komeda_platform_remove,
> .driver = {
> .name = "komeda",
> .of_match_table = komeda_of_match,
> --
> 2.39.2
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [RFC PATCH 00/10] Xe DRM scheduler and long running workload plans
On Mon, Apr 03, 2023 at 05:22:01PM -0700, Matthew Brost wrote: > Hello, Hello, Jumping a bit late on this thread as I was waiting on some approvals and then holidays kicked in, but I would like to (re)introduce myself and the people I work with and to let you know that we are interested in the changes proposed here and we would like to help if we can. I currently maintain a number of Arm Mali Display drivers but in recent times I have moved to the Mali GPU team and now we've got approval to start making contributions to the upstream driver(s). We're planning to collaborate on Boris' new Mali driver and make it work well on Mali GPUs. One of the first things to look at (besides bringing the driver up on internal dev platforms) are the scheduler changes proposed here. As such, I would like to ask that people start including John Reitan, Ketil Johnsen and me on patches. As soon as we have something working and we can make comments on, we will do so. Best regards, Liviu > > As a prerequisite to merging the new Intel Xe DRM driver [1] [2], we > have been asked to merge our common DRM scheduler patches first as well > as develop a common solution for long running workloads with the DRM > scheduler. This RFC series is our first attempt at doing this. We > welcome any and all feedback. > > This can we thought of as 4 parts detailed below. > > - DRM scheduler changes for 1 to 1 relationship between scheduler and > entity (patches 1-3) > > In Xe all of the scheduling of jobs is done by a firmware scheduler (the > GuC) which is a new paradigm WRT to the DRM scheduler and presents > severals problems as the DRM was originally designed to schedule jobs on > hardware queues. The main problem being that DRM scheduler expects the > submission order of jobs to be the completion order of jobs even across > multiple entities. This assumption falls apart with a firmware scheduler > as a firmware scheduler has no concept of jobs and jobs can complete out > of order. A novel solution for was originally thought of by Faith during > the initial prototype of Xe, create a 1 to 1 relationship between scheduler > and entity. I believe the AGX driver [3] is using this approach and > Boris may use approach as well for the Mali driver [4]. > > To support a 1 to 1 relationship we move the main execution function > from a kthread to a work queue and add a new scheduling mode which > bypasses code in the DRM which isn't needed in a 1 to 1 relationship. > The new scheduling mode should unify all drivers usage with a 1 to 1 > relationship and can be thought of as using scheduler as a dependency / > infligt job tracker rather than a true scheduler. > > - Generic messaging interface for DRM scheduler > > Idea is to be able to communicate to the submission backend with in band > (relative to main execution function) messages. Messages are backend > defined and flexable enough for any use case. In Xe we use these > messages to clean up entites, set properties for entites, and suspend / > resume execution of an entity [5]. I suspect other driver can leverage > this messaging concept too as it a convenient way to avoid races in the > backend. > > - Support for using TDR for all error paths of a scheduler / entity > > Fix a few races / bugs, add function to dynamically set the TDR timeout. > > - Annotate dma-fences for long running workloads. > > The idea here is to use dma-fences only as sync points within the > scheduler and never export them for long running workloads. By > annotating these fences as long running we ensure that these dma-fences > are never used in a way that breaks the dma-fence rules. A benefit of > thus approach is the scheduler can still safely flow control the > execution ring buffer via the job limit without breaking the dma-fence > rules. > > Again this a first draft and looking forward to feedback. > > Enjoy - Matt > > [1] https://gitlab.freedesktop.org/drm/xe/kernel > [2] https://patchwork.freedesktop.org/series/112188/ > [3] https://patchwork.freedesktop.org/series/114772/ > [4] https://patchwork.freedesktop.org/patch/515854/?series=112188=1 > [5] > https://gitlab.freedesktop.org/drm/xe/kernel/-/blob/drm-xe-next/drivers/gpu/drm/xe/xe_guc_submit.c#L1031 > > Matthew Brost (8): > drm/sched: Convert drm scheduler to use a work queue rather than > kthread > drm/sched: Move schedule policy to scheduler / entity > drm/sched: Add DRM_SCHED_POLICY_SINGLE_ENTITY scheduling policy > drm/sched: Add generic scheduler message interface > drm/sched: Start run wq before TDR in drm_sched_start > drm/sched: Submit job before starting TDR > drm/sched: Add helper to set TDR timeout > drm/syncobj: Warn on long running dma-fences > > Thomas Hellström (2): > dma-buf/dma-fence: Introduce long-running completion fences > drm/sched: Support long-running sched entities > > drivers/dma-buf/dma-fence.c | 142 +++--- > drivers/dma-buf/dma-resv.c | 5 + >
Re: [PATCH] drm/komeda: Take over EFI framebuffer properly
On Wed, Mar 15, 2023 at 09:34:37AM +, Steven Price wrote:
> On 13/03/2023 10:22, patrik.bergl...@arm.com wrote:
> > From: Patrik Berglund
> >
> > The Arm Morello board EDK2 port already provides an EFI GOP display for
> > Ceti/Cetus (Komeda) with more boards incoming.
> > However, once the Komeda driver probes and takes over the hardware,
> > it should take over the logical framebuffer as well, otherwise,
> > the now-defunct GOP device hangs around and virtual console output
> > inevitably disappears into the wrong place most of the time.
> >
> > We'll do this right before doing the SRST because that is the point
> > when the GOP will stop working.
> > The GOP might also fail because the encoder driver do things but this
> > is better than nothing.
> >
> > Signed-off-by: Patrik Berglund
>
> +CC the maintainers.
>
> Looks right to me, hdlcd has something very similar.
>
> Reviewed-by: Steven Price
Hi Steven,
Patrik contacted me privately and made me aware of the patch. I had a discussion
with him about the layering violation (d71 knowing about kms) and we came to the
conclusion that an additional patch is needed to re-order some code before this
one can go in. Patrik and/or I need to revive a test environment to check that
patch.
Best regards,
Liviu
>
> > ---
> > drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c | 12
> > drivers/gpu/drm/arm/display/komeda/komeda_kms.c | 6 ++
> > drivers/gpu/drm/arm/display/komeda/komeda_kms.h | 1 +
> > 3 files changed, 19 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > index 6c56f5662bc7..72035af9bc5f 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
> > @@ -8,6 +8,7 @@
> > #include
> > #include
> > #include "d71_dev.h"
> > +#include "komeda_kms.h"
> > #include "malidp_io.h"
> >
> > static u64 get_lpu_event(struct d71_pipeline *d71_pipeline)
> > @@ -310,6 +311,17 @@ static int d71_reset(struct d71_dev *d71)
> > u32 __iomem *gcu = d71->gcu_addr;
> > int ret;
> >
> > + /*
> > +* If we are already running, the most likely reason is that the EFI
> > left
> > +* us running (GOP), so make sure to take over from simple framebuffer
> > +* drivers.
> > +*/
> > + if (malidp_read32(gcu, BLK_STATUS) & GCU_STATUS_ACTIVE) {
> > + ret = komeda_kms_remove_framebuffers();
> > + if (ret)
> > + return ret;
> > + }
> > +
> > malidp_write32(gcu, BLK_CONTROL, GCU_CONTROL_SRST);
> >
> > ret = dp_wait_cond(!(malidp_read32(gcu, BLK_CONTROL) &
> > GCU_CONTROL_SRST),
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > index 62dc64550793..12af409aeabb 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > @@ -7,6 +7,7 @@
> > #include
> > #include
> >
> > +#include
> > #include
> > #include
> > #include
> > @@ -349,3 +350,8 @@ void komeda_kms_detach(struct komeda_kms_dev *kms)
> > komeda_kms_cleanup_private_objs(kms);
> > drm->dev_private = NULL;
> > }
> > +
> > +int komeda_kms_remove_framebuffers(void)
> > +{
> > + return drm_aperture_remove_framebuffers(false, _kms_driver);
> > +}
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> > b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> > index 3a872c292091..1a43707ed68f 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> > @@ -187,5 +187,6 @@ void komeda_crtc_flush_and_wait_for_flip_done(struct
> > komeda_crtc *kcrtc,
> >
> > struct komeda_kms_dev *komeda_kms_attach(struct komeda_dev *mdev);
> > void komeda_kms_detach(struct komeda_kms_dev *kms);
> > +int komeda_kms_remove_framebuffers(void);
> >
> > #endif /*_KOMEDA_KMS_H_*/
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH -next 1/2] drm/arm/malidp: Use devm_platform_get_and_ioremap_resource()
On Tue, Mar 14, 2023 at 04:02:31PM +0800, Yang Li wrote:
> According to commit 890cc39a8799 ("drivers: provide
> devm_platform_get_and_ioremap_resource()"), convert
> platform_get_resource(), devm_ioremap_resource() to a single
> call to devm_platform_get_and_ioremap_resource(), as this is exactly
> what this function does.
>
> Since 'struct platform_device *pdev = to_platform_device(dev)',
> 'pdev->dev' is equivalent to 'dev'.
>
> Signed-off-by: Yang Li
Acked-by: Liviu Dudau
Thanks for the cleanup! I will pull this patch and the hdlcd one into
drm-misc-next by the end of the week.
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/malidp_drv.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index cf040e2e9efe..e220bfc85b2e 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -724,8 +724,7 @@ static int malidp_bind(struct device *dev)
> hwdev->hw = (struct malidp_hw *)of_device_get_match_data(dev);
> malidp->dev = hwdev;
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - hwdev->regs = devm_ioremap_resource(dev, res);
> + hwdev->regs = devm_platform_get_and_ioremap_resource(pdev, 0, );
> if (IS_ERR(hwdev->regs))
> return PTR_ERR(hwdev->regs);
>
> --
> 2.20.1.7.g153144c
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH -next 2/2] drm/arm/hdlcd: Use devm_platform_ioremap_resource()
On Tue, Mar 14, 2023 at 04:02:30PM +0800, Yang Li wrote:
> According to commit 7945f929f1a7 ("drivers: provide
> devm_platform_ioremap_resource()"), convert platform_get_resource(),
> devm_ioremap_resource() to a single call to Use
> devm_platform_ioremap_resource(), as this is exactly what this function
> does.
>
> Since 'struct platform_device *pdev = to_platform_device(drm->dev)',
> 'drm->dev' is equivalent to 'pdev->deva'.
>
> Signed-off-by: Yang Li
Acked-by: Liviu Dudau
Thanks for cleaning this up!
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/hdlcd_drv.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index e3507dd6f82a..a86b317c1312 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -100,7 +100,6 @@ static int hdlcd_load(struct drm_device *drm, unsigned
> long flags)
> {
> struct hdlcd_drm_private *hdlcd = drm_to_hdlcd_priv(drm);
> struct platform_device *pdev = to_platform_device(drm->dev);
> - struct resource *res;
> u32 version;
> int ret;
>
> @@ -115,8 +114,7 @@ static int hdlcd_load(struct drm_device *drm, unsigned
> long flags)
> atomic_set(>dma_end_count, 0);
> #endif
>
> - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> - hdlcd->mmio = devm_ioremap_resource(drm->dev, res);
> + hdlcd->mmio = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(hdlcd->mmio)) {
> DRM_ERROR("failed to map control registers area\n");
> ret = PTR_ERR(hdlcd->mmio);
> --
> 2.20.1.7.g153144c
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH] drm/arm/malidp: use sysfs_emit in show function callback
On Sat, Jan 28, 2023 at 02:21:26AM +0530, Deepak R Varma wrote: > According to Documentation/filesystems/sysfs.rst, the show() callback > function of kobject attributes should strictly use sysfs_emit() instead > of sprintf() family functions. > Issue identified using the device_attr_show.cocci Coccinelle script. > > Signed-off-by: Deepak R Varma Acked-by: Liviu Dudau I will push the change into drm-misc-next by the end of the week. Best regards, Liviu > --- > drivers/gpu/drm/arm/malidp_drv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/arm/malidp_drv.c > b/drivers/gpu/drm/arm/malidp_drv.c > index 589c1c66a6dc..cf040e2e9efe 100644 > --- a/drivers/gpu/drm/arm/malidp_drv.c > +++ b/drivers/gpu/drm/arm/malidp_drv.c > @@ -649,7 +649,7 @@ static ssize_t core_id_show(struct device *dev, struct > device_attribute *attr, > struct drm_device *drm = dev_get_drvdata(dev); > struct malidp_drm *malidp = drm_to_malidp(drm); > > - return snprintf(buf, PAGE_SIZE, "%08x\n", malidp->core_id); > + return sysfs_emit(buf, "%08x\n", malidp->core_id); > } > > static DEVICE_ATTR_RO(core_id); > -- > 2.34.1 > > > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯
Re: [PATCH v3 3/3] drm: Convert users of drm_of_component_match_add to component_match_add_of
On Thu, Jan 19, 2023 at 02:10:39PM -0500, Sean Anderson wrote:
> Every user of this function either uses component_compare_of or
> something equivalent. Most of them immediately put the device node as
> well. Convert these users to component_match_add_of and remove
> drm_of_component_match_add.
>
> Signed-off-by: Sean Anderson
> Acked-by: Jyri Sarha
> Tested-by: Jyri Sarha
> ---
>
> (no changes since v1)
>
> .../gpu/drm/arm/display/komeda/komeda_drv.c | 6 ++--
> drivers/gpu/drm/arm/hdlcd_drv.c | 9 +-
> drivers/gpu/drm/arm/malidp_drv.c | 11 +--
> drivers/gpu/drm/armada/armada_drv.c | 10 ---
> drivers/gpu/drm/drm_of.c | 29 +++
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 4 +--
> .../gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 3 +-
> drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 3 +-
> drivers/gpu/drm/mediatek/mtk_drm_drv.c| 4 +--
> drivers/gpu/drm/msm/msm_drv.c | 14 -
> drivers/gpu/drm/sti/sti_drv.c | 3 +-
> drivers/gpu/drm/sun4i/sun4i_drv.c | 3 +-
> drivers/gpu/drm/tilcdc/tilcdc_external.c | 10 ++-
> include/drm/drm_of.h | 12
> 14 files changed, 33 insertions(+), 88 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> index 3f4e719eebd8..e3bfc72c378f 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> @@ -103,10 +103,8 @@ static void komeda_add_slave(struct device *master,
> struct device_node *remote;
>
> remote = of_graph_get_remote_node(np, port, endpoint);
> - if (remote) {
> - drm_of_component_match_add(master, match, component_compare_of,
> remote);
> - of_node_put(remote);
> - }
> + if (remote)
> + component_match_add_of(master, match, remote);
> }
>
> static int komeda_platform_probe(struct platform_device *pdev)
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index e3507dd6f82a..5f760bb66af4 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -347,11 +347,6 @@ static const struct component_master_ops
> hdlcd_master_ops = {
> .unbind = hdlcd_drm_unbind,
> };
>
> -static int compare_dev(struct device *dev, void *data)
> -{
> - return dev->of_node == data;
> -}
> -
> static int hdlcd_probe(struct platform_device *pdev)
> {
> struct device_node *port;
> @@ -362,9 +357,7 @@ static int hdlcd_probe(struct platform_device *pdev)
> if (!port)
> return -ENODEV;
>
> - drm_of_component_match_add(>dev, , compare_dev, port);
> - of_node_put(port);
> -
> + component_match_add_of(>dev, , port);
> return component_master_add_with_match(>dev, _master_ops,
> match);
> }
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 589c1c66a6dc..3a49c29ba5b8 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -909,13 +909,6 @@ static const struct component_master_ops
> malidp_master_ops = {
> .unbind = malidp_unbind,
> };
>
> -static int malidp_compare_dev(struct device *dev, void *data)
> -{
> - struct device_node *np = data;
> -
> - return dev->of_node == np;
> -}
> -
> static int malidp_platform_probe(struct platform_device *pdev)
> {
> struct device_node *port;
> @@ -929,9 +922,7 @@ static int malidp_platform_probe(struct platform_device
> *pdev)
> if (!port)
> return -ENODEV;
>
> - drm_of_component_match_add(>dev, , malidp_compare_dev,
> -port);
> - of_node_put(port);
> + component_match_add_of(>dev, , port);
> return component_master_add_with_match(>dev, _master_ops,
> match);
> }
For komeda, mali_dp and hdlcd: Acked-by: Liviu Dudau
Best regards,
Liviu
> diff --git a/drivers/gpu/drm/armada/armada_drv.c
> b/drivers/gpu/drm/armada/armada_drv.c
> index 0643887800b4..c0211ad7a45d 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -184,10 +184,12 @@ static void armada_add_endpoints(struct device *dev,
>
> for_each_endpoint_of_node(dev_node, ep) {
> remote = of_graph_get_remote_port_parent(ep);
> - if (remote &&am
Re: [PATCH v2 02/10] drm: Include where needed
On Wed, Jan 11, 2023 at 02:01:58PM +0100, Thomas Zimmermann wrote: > Include in source files that need it. Some of DRM's > source code gets OF header via drm_crtc_helper.h and , > which can leed to unnecessary recompilation. > > In drm_modes.c, add a comment on the reason for still including > . The header file is required to get KHZ2PICOS(). The > macro is part of the UAPI headers, so it cannot be moved to a less > prominent location. > > v2: > * include in komeda_drv.c (kernel test robot) > > Signed-off-by: Thomas Zimmermann > --- > drivers/gpu/drm/arm/display/komeda/komeda_drv.c | 1 + > drivers/gpu/drm/drm_modes.c | 5 +++-- > drivers/gpu/drm/panel/panel-ronbo-rb070d30.c| 1 + > 3 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c > b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c > index 3f4e719eebd8..28f76e07dd95 100644 > --- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c > @@ -6,6 +6,7 @@ > */ > #include > #include > +#include > #include > #include > #include For komeda: Acked-by: Liviu Dudau Best regards, Liviu > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c > index be030f4a5311..40d482a01178 100644 > --- a/drivers/gpu/drm/drm_modes.c > +++ b/drivers/gpu/drm/drm_modes.c > @@ -31,10 +31,11 @@ > */ > > #include > +#include > +#include /* for KHZ2PICOS() */ > #include > #include > -#include > -#include > +#include > > #include > #include > diff --git a/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c > b/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c > index a8a98c91b13c..866d1bf5530e 100644 > --- a/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c > +++ b/drivers/gpu/drm/panel/panel-ronbo-rb070d30.c > @@ -15,6 +15,7 @@ > #include > #include > #include > +#include > > #include > #include > -- > 2.39.0 > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯
Re: [PATCH 3/9] drm/arm/hdlcd: use new debugfs device-centered functions
On Mon, Dec 26, 2022 at 12:50:23PM -0300, Maíra Canal wrote:
> Replace the use of drm_debugfs_create_files() with the new
> drm_debugfs_add_files() function, which center the debugfs files
> management on the drm_device instead of drm_minor. Moreover, remove the
> debugfs_init hook and add the debugfs files directly on hdlcd_drm_bind(),
> before drm_dev_register().
>
> Signed-off-by: Maíra Canal
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/hdlcd_drv.c | 24 +---
> 1 file changed, 9 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index 7043d1c9ed8f..e3507dd6f82a 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -195,8 +195,8 @@ static int hdlcd_setup_mode_config(struct drm_device *drm)
> #ifdef CONFIG_DEBUG_FS
> static int hdlcd_show_underrun_count(struct seq_file *m, void *arg)
> {
> - struct drm_info_node *node = (struct drm_info_node *)m->private;
> - struct drm_device *drm = node->minor->dev;
> + struct drm_debugfs_entry *entry = m->private;
> + struct drm_device *drm = entry->dev;
> struct hdlcd_drm_private *hdlcd = drm_to_hdlcd_priv(drm);
>
> seq_printf(m, "underrun : %d\n",
> atomic_read(>buffer_underrun_count));
> @@ -208,8 +208,8 @@ static int hdlcd_show_underrun_count(struct seq_file *m,
> void *arg)
>
> static int hdlcd_show_pxlclock(struct seq_file *m, void *arg)
> {
> - struct drm_info_node *node = (struct drm_info_node *)m->private;
> - struct drm_device *drm = node->minor->dev;
> + struct drm_debugfs_entry *entry = m->private;
> + struct drm_device *drm = entry->dev;
> struct hdlcd_drm_private *hdlcd = drm_to_hdlcd_priv(drm);
> unsigned long clkrate = clk_get_rate(hdlcd->clk);
> unsigned long mode_clock = hdlcd->crtc.mode.crtc_clock * 1000;
> @@ -219,17 +219,10 @@ static int hdlcd_show_pxlclock(struct seq_file *m, void
> *arg)
> return 0;
> }
>
> -static struct drm_info_list hdlcd_debugfs_list[] = {
> +static struct drm_debugfs_info hdlcd_debugfs_list[] = {
> { "interrupt_count", hdlcd_show_underrun_count, 0 },
> { "clocks", hdlcd_show_pxlclock, 0 },
> };
> -
> -static void hdlcd_debugfs_init(struct drm_minor *minor)
> -{
> - drm_debugfs_create_files(hdlcd_debugfs_list,
> - ARRAY_SIZE(hdlcd_debugfs_list),
> - minor->debugfs_root, minor);
> -}
> #endif
>
> DEFINE_DRM_GEM_DMA_FOPS(fops);
> @@ -237,9 +230,6 @@ DEFINE_DRM_GEM_DMA_FOPS(fops);
> static const struct drm_driver hdlcd_driver = {
> .driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
> DRM_GEM_DMA_DRIVER_OPS,
> -#ifdef CONFIG_DEBUG_FS
> - .debugfs_init = hdlcd_debugfs_init,
> -#endif
> .fops = ,
> .name = "hdlcd",
> .desc = "ARM HDLCD Controller DRM",
> @@ -303,6 +293,10 @@ static int hdlcd_drm_bind(struct device *dev)
> drm_mode_config_reset(drm);
> drm_kms_helper_poll_init(drm);
>
> +#ifdef CONFIG_DEBUG_FS
> + drm_debugfs_add_files(drm, hdlcd_debugfs_list,
> ARRAY_SIZE(hdlcd_debugfs_list));
> +#endif
> +
> ret = drm_dev_register(drm, 0);
> if (ret)
> goto err_register;
> --
> 2.38.1
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH] drm: mali-dp: Add check for kzalloc
Hi Jiasheng,
I appreciate the effort you have put into this and I find nothing wrong with the
intention of the patch. However, I don't intend to move base from being the
first
member of the malidp_mw_connector_state struct as it has other benefits in the
code
and we can use container_of() in implementation of generic APIs. As Robin has
rightly
pointed, it is unlikely that a compiler will dereference the pointer before
doing
offset_of(), so having mw_state == NULL is safe, even if quirky.
So I'm going to thank you for the patch but I will not merge it.
As a side comment, please use --in-reply-to and link to previous email when
re-sending
patches with small spelling fixes as otherwise it gets confusing on which email
is the last
one and it also relies on the servers delivering messages in the order you've
sent,
not always a strong guarantee.
Best regards,
Liviu
On Thu, Dec 08, 2022 at 11:16:21AM +0800, Jiasheng Jiang wrote:
> As kzalloc may fail and return NULL pointer, the "mw_state" can be NULL.
> If the layout of struct malidp_mw_connector_state ever changes, it
> will cause NULL poineter derefernce of "_state->base".
> Therefore, the "mw_state" should be checked whether it is NULL in order
> to improve the robust.
>
> Fixes: 8cbc5caf36ef ("drm: mali-dp: Add writeback connector")
> Signed-off-by: Jiasheng Jiang
> ---
> drivers/gpu/drm/arm/malidp_mw.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
> index ef76d0e6ee2f..fe4474c2ddcf 100644
> --- a/drivers/gpu/drm/arm/malidp_mw.c
> +++ b/drivers/gpu/drm/arm/malidp_mw.c
> @@ -72,7 +72,11 @@ static void malidp_mw_connector_reset(struct drm_connector
> *connector)
> __drm_atomic_helper_connector_destroy_state(connector->state);
>
> kfree(connector->state);
> - __drm_atomic_helper_connector_reset(connector, _state->base);
> +
> + if (mw_state)
> + __drm_atomic_helper_connector_reset(connector, _state->base);
> + else
> + __drm_atomic_helper_connector_reset(connector, NULL);
> }
>
> static enum drm_connector_status
> --
> 2.25.1
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH] drm: mali-dp: Add check for kzalloc
On Wed, Dec 07, 2022 at 01:59:04PM +, Robin Murphy wrote:
> On 2022-12-07 09:21, Jiasheng Jiang wrote:
> > As kzalloc may fail and return NULL pointer, it should be better to check
> > the return value in order to avoid the NULL pointer dereference in
> > __drm_atomic_helper_connector_reset.
>
> This commit message is nonsense; if __drm_atomic_helper_connector_reset()
> would dereference the NULL implied by _state->base, it would equally
> still dereference the explicit NULL pointer passed after this patch.
Where?
>
> The current code works out OK because "base" is the first member of struct
> malidp_mw_connector_state, thus if mw_state is NULL then _state->base ==
> NULL + 0 == NULL. Now you *could* argue that this isn't robust if the layout
> of struct malidp_mw_connector_state ever changes, and that could be a valid
> justification for making this change, but the reason given certainly isn't.
I appreciate the input and I agree with your analysis, however I don't have the
same
confidence that compilers will always do the NULL + 0 math to get address of
base.
Would this always work when you have authenticated pointers or is the compiler
going
to generate some plumbing code that checks the pointer before doing the math?
>
> Arithmetic on a (potentially) NULL pointer may well be a sign that it's
> worth a closer look to check whether it really is what the code intended to
> do, but don't automatically assume it has to be a bug. Otherwise, good luck
> with "fixing" every user of container_of() throughout the entire kernel.
My understanding is that you're supposed to use container_of() only when you're
sure
that your pointer is valid. container_of_safe() seems to be the one to use when
you
don't care about NULL pointers.
Best regards,
Liviu
>
> Thanks,
> Robin.
>
> > Fixes: 8cbc5caf36ef ("drm: mali-dp: Add writeback connector")
> > Signed-off-by: Jiasheng Jiang
> > ---
> > drivers/gpu/drm/arm/malidp_mw.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/arm/malidp_mw.c
> > b/drivers/gpu/drm/arm/malidp_mw.c
> > index ef76d0e6ee2f..fe4474c2ddcf 100644
> > --- a/drivers/gpu/drm/arm/malidp_mw.c
> > +++ b/drivers/gpu/drm/arm/malidp_mw.c
> > @@ -72,7 +72,11 @@ static void malidp_mw_connector_reset(struct
> > drm_connector *connector)
> > __drm_atomic_helper_connector_destroy_state(connector->state);
> > kfree(connector->state);
> > - __drm_atomic_helper_connector_reset(connector, _state->base);
> > +
> > + if (mw_state)
> > + __drm_atomic_helper_connector_reset(connector, _state->base);
> > + else
> > + __drm_atomic_helper_connector_reset(connector, NULL);
> > }
> > static enum drm_connector_status
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH] drm: mali-dp: Add check for kzalloc
On Wed, Dec 07, 2022 at 05:21:18PM +0800, Jiasheng Jiang wrote:
> As kzalloc may fail and return NULL pointer, it should be better to check
> the return value in order to avoid the NULL pointer dereference in
> __drm_atomic_helper_connector_reset.
>
> Fixes: 8cbc5caf36ef ("drm: mali-dp: Add writeback connector")
> Signed-off-by: Jiasheng Jiang
Thanks for catching this!
Acked-by: Liviu Dudau
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/malidp_mw.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
> index ef76d0e6ee2f..fe4474c2ddcf 100644
> --- a/drivers/gpu/drm/arm/malidp_mw.c
> +++ b/drivers/gpu/drm/arm/malidp_mw.c
> @@ -72,7 +72,11 @@ static void malidp_mw_connector_reset(struct drm_connector
> *connector)
> __drm_atomic_helper_connector_destroy_state(connector->state);
>
> kfree(connector->state);
> - __drm_atomic_helper_connector_reset(connector, _state->base);
> +
> + if (mw_state)
> + __drm_atomic_helper_connector_reset(connector, _state->base);
> + else
> + __drm_atomic_helper_connector_reset(connector, NULL);
> }
>
> static enum drm_connector_status
> --
> 2.25.1
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH drm-misc-next v3 0/5] drm/arm/malidp: use drm managed resources
On Wed, Oct 26, 2022 at 05:59:29PM +0200, Danilo Krummrich wrote:
> Hi,
Hi Danilo,
Sorry for the additional delay in reviewing and testing this series. I've now
managed
to get enough of both to be happy with the series.
For the whole series: Reviewed-by: Liviu Dudau
I will push the series today to drm-misc-next.
Best regards,
Liviu
>
> This patch series converts the driver to use drm managed resources to prevent
> potential use-after-free issues on driver unbind/rebind and to get rid of the
> usage of deprecated APIs.
>
> Changes in v2:
> - While protecting critical sections with drm_dev_{enter,exit} I forgot to
> handle alternate return paths within the read-side critical sections,
> hence
> fix them.
> - Add a patch to remove explicit calls to drm_mode_config_cleanup() and
> switch
> to drmm_mode_config_init() explicitly.
>
> Changes in v3:
> - Remove patches to protect platform device bound resources with
> drm_dev_{enter,exit}, since this would leave the hardware enabled when
> regularly unloading the driver e.g. via rmmod.
> Instead do this in a later series, once we got drm_dev_unplug() in place
> to deal with a regular driver shutdown.
>
> Danilo Krummrich (5):
> drm/arm/malidp: use drmm_* to allocate driver structures
> drm/arm/malidp: replace drm->dev_private with drm_to_malidp()
> drm/arm/malidp: crtc: use drmm_crtc_init_with_planes()
> drm/arm/malidp: plane: use drm managed resources
> drm/arm/malidp: remove calls to drm_mode_config_cleanup()
>
> drivers/gpu/drm/arm/malidp_crtc.c | 7 ++-
> drivers/gpu/drm/arm/malidp_drv.c| 69 +++--
> drivers/gpu/drm/arm/malidp_drv.h| 2 +
> drivers/gpu/drm/arm/malidp_hw.c | 10 ++---
> drivers/gpu/drm/arm/malidp_mw.c | 6 +--
> drivers/gpu/drm/arm/malidp_planes.c | 32 -
> 6 files changed, 48 insertions(+), 78 deletions(-)
>
>
> base-commit: e1e7bc481d49c3e3ada11029ce0d9b85a0a539d7
> --
> 2.37.3
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH 4/5] drm/komeda: Fix IS_ERR() vs NULL check in komeda_component_get_avail_scaler()
On Thu, Nov 10, 2022 at 05:44:44PM +0800, Gaosheng Cui wrote:
> The komeda_pipeline_get_state() returns an ERR_PTR() on failure, we should
> use IS_ERR() to check the return value.
>
> Fixes: 502932a03fce ("drm/komeda: Add the initial scaler support for CORE")
> Signed-off-by: Gaosheng Cui
Acked-by: Liviu Dudau
Thanks for the fix!
Best regards,
Liviu
> ---
> drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> index 3276a3e82c62..e9c92439398d 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_pipeline_state.c
> @@ -259,7 +259,7 @@ komeda_component_get_avail_scaler(struct komeda_component
> *c,
> u32 avail_scalers;
>
> pipe_st = komeda_pipeline_get_state(c->pipeline, state);
> - if (!pipe_st)
> + if (IS_ERR(pipe_st))
> return NULL;
>
> avail_scalers = (pipe_st->active_comps & KOMEDA_PIPELINE_SCALERS) ^
> --
> 2.25.1
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH drm-misc-next v4 0/4] drm/arm/hdlcd: use drm managed resources
On Tue, Nov 08, 2022 at 08:57:55PM +0100, Danilo Krummrich wrote: > Hi Liviu, Hi, > > > The only issue that I'm seeing that is not critical is that at > > reboot/shutdown time > > I'm getting an "Unexpected global fault, this could be serious" from the > > smmu: > > > > [ 6893.467910] arm-smmu 7fb3.iommu: disabling translation > > [ 6893.473550] ohci-platform 7ffb.usb: Removing from iommu group 1 > > [ 6893.479909] ehci-platform 7ffc.usb: Removing from iommu group 1 > > [ 6893.486931] arm-smmu 7fb1.iommu: disabling translation > > [ 6893.492521] hdlcd 7ff5.hdlcd: Removing from iommu group 3 > > [ 6893.492650] arm-smmu 7fb1.iommu: Unexpected global fault, this could > > be serious > > [ 6893.505959] arm-smmu 7fb1.iommu: GFSR 0x8001, GFSYNR0 > > 0x, GFSYNR1 0x, GFSYNR2 0x > > [ 6893.516511] arm-smmu 7fb0.iommu: disabling translation > > [ 6893.522195] dma-pl330 7ff0.dma-controller: Removing from iommu group > > 2 > > [ 6893.529607] arm-smmu 2b50.iommu: disabling translation > > [ 6893.535221] pcieport :00:00.0: Removing from iommu group 0 > > [ 6893.541135] pci :01:00.0: Removing from iommu group 0 > > [ 6893.546604] pcieport :02:01.0: Removing from iommu group 0 > > [ 6893.552511] pcieport :02:02.0: Removing from iommu group 0 > > [ 6893.558418] pcieport :02:03.0: Removing from iommu group 0 > > [ 6893.564329] pcieport :02:0c.0: Removing from iommu group 0 > > [ 6893.570393] pcieport :02:10.0: Removing from iommu group 0 > > [ 6893.576314] pcieport :02:1f.0: Removing from iommu group 0 > > [ 6893.582214] sata_sil24 :03:00.0: Removing from iommu group 0 > > [ 6893.588270] sky2 :08:00.0: Removing from iommu group 0 > > [ 6893.594616] reboot: Power down > > > > > > The reboot/shutdown succeeds, so I'm not too worried about it for now, but > > hope that > > this is something you'll keep in mind in the later series when you do > > drm_dev_unplug(). > > Yes, I'd expect this to be related to the missing protection of platform > device bound resources. > > > > > With that, for the whole series: > > > > Acked-by: Liviu Dudau > > > > Thanks for the patience and going through the series iterations with me. > > > > I can pull this series into drm-misc-next on Monday if you don't have any > > other plans. > Thanks, I saw you already applied the series. > > Have you had a look on the same series for malidp? Yes, I've looked at the code and it looks reasonable, I just wanted to run it once through the minimum of tests that I use, which involves switching some FPGA images around. Hope to do that today or tomorrow. Best regards, Liviu > > - Danilo > > > > > Best regards, > > Liviu > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯
Re: [PATCH drm-misc-next v4 0/4] drm/arm/hdlcd: use drm managed resources
On Wed, Oct 26, 2022 at 05:34:27PM +0200, Danilo Krummrich wrote:
> Hi,
Hi Danilo,
>
> This patch series converts the driver to use drm managed resources to prevent
> potential use-after-free issues on driver unbind/rebind and to get rid of the
> usage of deprecated APIs.
>
> Changes in v2:
> - drop patch "drm/arm/hdlcd: crtc: use drmm_crtc_init_with_planes()"
>
> Changes in v3:
> - Fix alternate return paths in srcu read-side critical sections causing a
> stall when unregistering the driver.
> - Fix potential null pointer dereference in hdlcd_crtc_cleanup() introduced
> dropping the patch in v2.
> - Add a patch to remove explicit calls to drm_mode_config_cleanup().
>
> Changes in v4:
> - Remove patches to protect platform device bound resources with
> drm_dev_{enter,exit}, since this would leave the hardware enabled when
> regularly unloading the driver e.g. via rmmod.
> Instead do this in a later series, once we got drm_dev_unplug() in place
> to deal with a regular driver shutdown.
This series is in a much better shape compared to the existing status quo. rmmod
works without any issue and I can re-insmod the driver again.
The only issue that I'm seeing that is not critical is that at reboot/shutdown
time
I'm getting an "Unexpected global fault, this could be serious" from the smmu:
[ 6893.467910] arm-smmu 7fb3.iommu: disabling translation
[ 6893.473550] ohci-platform 7ffb.usb: Removing from iommu group 1
[ 6893.479909] ehci-platform 7ffc.usb: Removing from iommu group 1
[ 6893.486931] arm-smmu 7fb1.iommu: disabling translation
[ 6893.492521] hdlcd 7ff5.hdlcd: Removing from iommu group 3
[ 6893.492650] arm-smmu 7fb1.iommu: Unexpected global fault, this could be
serious
[ 6893.505959] arm-smmu 7fb1.iommu: GFSR 0x8001, GFSYNR0
0x, GFSYNR1 0x, GFSYNR2 0x
[ 6893.516511] arm-smmu 7fb0.iommu: disabling translation
[ 6893.522195] dma-pl330 7ff0.dma-controller: Removing from iommu group 2
[ 6893.529607] arm-smmu 2b50.iommu: disabling translation
[ 6893.535221] pcieport :00:00.0: Removing from iommu group 0
[ 6893.541135] pci :01:00.0: Removing from iommu group 0
[ 6893.546604] pcieport :02:01.0: Removing from iommu group 0
[ 6893.552511] pcieport :02:02.0: Removing from iommu group 0
[ 6893.558418] pcieport :02:03.0: Removing from iommu group 0
[ 6893.564329] pcieport :02:0c.0: Removing from iommu group 0
[ 6893.570393] pcieport :02:10.0: Removing from iommu group 0
[ 6893.576314] pcieport :02:1f.0: Removing from iommu group 0
[ 6893.582214] sata_sil24 :03:00.0: Removing from iommu group 0
[ 6893.588270] sky2 :08:00.0: Removing from iommu group 0
[ 6893.594616] reboot: Power down
The reboot/shutdown succeeds, so I'm not too worried about it for now, but hope
that
this is something you'll keep in mind in the later series when you do
drm_dev_unplug().
With that, for the whole series:
Acked-by: Liviu Dudau
Thanks for the patience and going through the series iterations with me.
I can pull this series into drm-misc-next on Monday if you don't have any other
plans.
Best regards,
Liviu
>
> Danilo Krummrich (4):
> drm/arm/hdlcd: use drmm_* to allocate driver structures
> drm/arm/hdlcd: replace drm->dev_private with drm_to_hdlcd_priv()
> drm/arm/hdlcd: plane: use drm managed resources
> drm/arm/hdlcd: remove calls to drm_mode_config_cleanup()
>
> drivers/gpu/drm/arm/hdlcd_crtc.c | 24 +++
> drivers/gpu/drm/arm/hdlcd_drv.c | 41
> drivers/gpu/drm/arm/hdlcd_drv.h | 2 ++
> 3 files changed, 32 insertions(+), 35 deletions(-)
>
>
> base-commit: e1e7bc481d49c3e3ada11029ce0d9b85a0a539d7
> --
> 2.37.3
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH drm-misc-next v3 4/7] drm/arm/hdlcd: use drm_dev_unplug()
On Fri, Oct 14, 2022 at 02:07:09AM +0200, Danilo Krummrich wrote:
> Hi Liviu,
>
> On 10/12/22 17:07, Liviu Dudau wrote:
> > Hi Danilo,
> >
> > Appologies again for the delay in reviewing this as I was at XDC last week.
>
> No worries, thanks for following up.
>
> > Looking at the documentation for drm_dev_unplug, you can get a hint about
> > what is going on:
> >
> > /*
> > * [] There is one
> > * shortcoming however, drm_dev_unplug() marks the drm_device as unplugged
> > before
> > * drm_atomic_helper_shutdown() is called. This means that if the disable
> > code
> > * paths are protected, they will not run on regular driver module unload,
> > * possibly leaving the hardware enabled.
> > */
> >
>
> Yes, that's the issue we have and pretty unfortunate. What we'd want for
> platform device drivers is to still be able to enter the sections locked
> with drm_dev_{enter,exit} on driver unbind, which we can't for at the
> moment.
>
> I discussed this with Daniel Vetter on #dri-devel and for now he suggests to
> just not lock access to platform device bound resources and respin the
> patchset removing those parts.
>
> Besides that I'll also work on a solution for drm_dev_unplug() /
> drm_dev_{enter,exit} to overcome this issue in the future.
>
> > I'm finally getting to a conclusion: I'm still not sure what problem you
> > were trying
> > to solve when you have started this series and if you have found a scenario
> > where
> > you've got use after free then I would like to be able to reproduce it on
> > my setup.
> > Otherwise, I think this whole series introduces a regression on the
> > behaviour of the
> > driver and I would be inclined to reject it.
>
> The problem is that DRM modeset objects should never be allocated with
> devm_*, since this can result in use-after free issues on driver unload.
> They should be freed when the last reference to the object is dropped, which
> DRM managed APIs take care of. As a consequence, DRM managed objects can
> potentially out-live platform device bound resources, which then should be
> protected from access. The first at least we can and should do.
>
> It's not an issue that's unique to hdlcd, it's just a known issue to be
> addressed by all drivers. There's still the shortcoming concerning
> protecting platform bound resources as discussed above, but "the drmm parts
> should be a good idea no matter what" to cite Daniel.
>
> I'll send a v4 without the drm_dev_{enter,exit} parts removed if that's fine
> for you.
Thanks for the description of the problem!
Also bear in mind that hdlcd and malidp use the component framework, which
means that
the unbind is happening through the component_master_del() function.
I'm still keen to get a reproducer for the original issue of use-after free on
hdlcd
(or malidp) that I can play with so that I can validate the final fix.
Best regards,
Liviu
>
> - Danilo
>
> >
> > Best regards,
> > Liviu
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH drm-misc-next v3 4/7] drm/arm/hdlcd: use drm_dev_unplug()
Hi Danilo,
Appologies again for the delay in reviewing this as I was at XDC last week.
This patch is causing a regression at 'rmmod' time as the drm_crtc_vblank_off()
does
not get called when we disable outputs and the HDLCD remains active as I keep
getting
unhandled context faults from the arm-smmu driver that sits in front of the
HDLCD.
This is the stack trace for it:
root@alarm ~]# rmmod hdlcd
[ 198.981343] Console: switching to colour dummy device 80x25
[ 199.012492] [ cut here ]
[ 199.017209] driver forgot to call drm_crtc_vblank_off()
[ 199.023513] WARNING: CPU: 5 PID: 176 at
drivers/gpu/drm/drm_atomic_helper.c:1236 disable_outputs+0x2c4/0x2d0
[drm_kms_helper]
[ 199.035055] Modules linked in: hdlcd(-) drm_dma_helper tda998x cec
drm_kms_helper drm
[ 199.042929] CPU: 5 PID: 176 Comm: kworker/5:2 Not tainted
6.0.0-rc2-7-ge17e6f0211cd #6
[ 199.051212] Hardware name: ARM Juno development board (r2) (DT)
[ 199.057143] Workqueue: events drm_mode_rmfb_work_fn [drm]
[ 199.062831] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 199.069809] pc : disable_outputs+0x2c4/0x2d0 [drm_kms_helper]
[ 199.075664] lr : disable_outputs+0x2c4/0x2d0 [drm_kms_helper]
[ 199.081519] sp : 8a8f3b60
[ 199.084836] x29: 8a8f3b60 x28: 0028 x27: 0008013962b8
[ 199.091996] x26: 81049688 x25: 81080520 x24: 0038
[ 199.099155] x23: x22: 000801396000 x21: 0008013966f0
[ 199.106314] x20: x19: 00080a65a800 x18:
[ 199.113472] x17: x16: x15:
[ 199.120630] x14: 00e1 x13: x12:
[ 199.127788] x11: 0001 x10: 0a60 x9 : 8a8f3910
[ 199.134947] x8 : 00080149d480 x7 : 00097efb5bc0 x6 : 0083
[ 199.142106] x5 : x4 : 00097efaea18 x3 : 00097efb1c20
[ 199.149264] x2 : x1 : x0 : 00080149c9c0
[ 199.156423] Call trace:
[ 199.158870] disable_outputs+0x2c4/0x2d0 [drm_kms_helper]
[ 199.164380] drm_atomic_helper_commit_tail+0x24/0xa0 [drm_kms_helper]
[ 199.170933] commit_tail+0x150/0x180 [drm_kms_helper]
[ 199.176093] drm_atomic_helper_commit+0x13c/0x370 [drm_kms_helper]
[ 199.182384] drm_atomic_commit+0xa4/0xe0 [drm]
[ 199.187074] drm_framebuffer_remove+0x434/0x4d4 [drm]
[ 199.192374] drm_mode_rmfb_work_fn+0x74/0x9c [drm]
[ 199.197413] process_one_work+0x1d4/0x330
[ 199.201437] worker_thread+0x220/0x430
[ 199.205195] kthread+0x108/0x10c
[ 199.208430] ret_from_fork+0x10/0x20
[ 199.212015] ---[ end trace ]---
[ 199.221088] arm-smmu 7fb1.iommu: Unhandled context fault: fsr=0x2,
iova=0xffa53600, fsynr=0x182, cbfrsynra=0x0, cb=0
[ 199.232958] arm-smmu 7fb1.iommu: Unhandled context fault: fsr=0x2,
iova=0xff80, fsynr=0x182, cbfrsynra=0x0, cb=0
[ 199.233228] [ cut here ]
[ 199.248618] hdlcd 7ff5.hdlcd: drm_WARN_ON(({ do {
__attribute__((__noreturn__)) extern void __compiletime_assert_384(void)
__attribute__((__error__("Unsupported access size for {READ,WRITE}_ONCE().")));
if (!((sizeof(vblank->enabled) == sizeof(char) || sizeof(vblank->enabled) ==
sizeof(short) || sizeof(vblank->
enabled) == sizeof(int) || sizeof(vblank->enabled) == sizeof(long)) ||
sizeof(vblank->enabled) == sizeof(long long))) __compiletime_assert_384(); }
while (0); (*(const volatile typeof( _Generic((vblank->enabled), char: (char)0,
unsigned char: (unsigned char)0, signed char: (signed char)0, unsigned short:
(unsigned sho
rt)0, signed short: (signed short)0, unsigned int: (unsigned int)0, signed int:
(signed int)0, unsigned long: (unsigned long)0, signed long: (signed long)0,
unsigned long long: (unsigned long long)0, signed long long: (signed long
long)0, default: (vblank->enabled))) *)&(vblank->enabled)); }) &&
drm_core_check_feature
(dev, DRIVER_MODESET))
[ 199.248790] WARNING: CPU: 4 PID: 285 at drivers/gpu/drm/drm_vblank.c:504
drm_vblank_init_release+0x84/0xb0 [drm]
[ 199.249751] arm-smmu 7fb1.iommu: Unhandled context fault: fsr=0x2,
iova=0xff80, fsynr=0x182, cbfrsynra=0x0, cb=0
[ 199.291902] arm-scmi firmware:scmi: timed out in resp(caller:
scmi_perf_level_set+0xfc/0x120)
[ 199.291926] cpufreq: __target_index: Failed to change cpu frequency: -110
[ 199.334654] Modules linked in: hdlcd(-)
[ 199.345063] scmi-cpufreq scmi_dev.2: Message for 857 type 0 is not expected!
[ 199.355734] drm_dma_helper
[ 199.371060] tda998x
[ 199.384738] cec
[ 199.408686] drm_kms_helper
[ 199.421404] drm
[ 199.436732]
[ 199.450409] CPU: 4 PID: 285 Comm: rmmod Tainted: GW
6.0.0-rc2-7-ge17e6f0211cd #6
[ 199.475499] Hardware name: ARM Juno development board (r2) (DT)
[ 199.501541] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 199.508531] pc :
Re: [PATCH RESEND drm-misc-next 4/7] drm/arm/hdlcd: plane: use drm managed resources
On Wed, Sep 14, 2022 at 12:03:58AM +0200, Danilo Krummrich wrote:
> On 9/13/22 10:58, Liviu Dudau wrote:
> > On Mon, Sep 12, 2022 at 09:50:26PM +0200, Danilo Krummrich wrote:
> > > Hi Liviu,
> >
> > Hi Danilo,
> >
> > >
> > > Thanks for having a look!
> > >
> > > This is not about this patch, it's about patch 3/7 "drm/arm/hdlcd: crtc:
> > > use
> > > drmm_crtc_init_with_planes()".
> >
> > Agree! However, this is the patch that removes the .destroy hook, so I've
> > replied here.
>
> This is a different .destroy hook, it's the struct drm_plane_funcs one, not
> the struct drm_crtc_funcs one, which the warning is about. Anyway, as said,
> we can just drop the mentioned patch. :-)
>
> >
> > >
> > > And there it's the other way around. When using
> > > drmm_crtc_init_with_planes()
> > > we shouldn't have a destroy hook in place, that's the whole purpose of
> > > drmm_crtc_init_with_planes().
> > >
> > > We should just drop patch 3/7 "drm/arm/hdlcd: crtc: use
> > > drmm_crtc_init_with_planes()", it's wrong.
> >
> > So we end up with mixed use of managed and unmanaged APIs?
>
> In this case, yes. However, I don't think this makes it inconsistent. They
> only thing drmm_crtc_init_with_planes() does different than
> drm_crtc_init_with_planes() is that it set's things up to automatically call
> drm_crtc_cleanup() on .destroy. Since this driver also does a register write
> in the .destroy callback and hence we can't get rid of the callback we can
> just keep it as it is.
>
> >
> > >
> > > Do you want me to send a v2 for that?
> >
> > Yes please! It would help me to understand your thinking around the whole
> > lifecycle of the driver.
> >
> > BTW, I appreciate the care in patches 5-7 to make sure that the driver
> > doesn't access freed resources,
> > however I'm not sure I like the fact that rmmod-ing the hdlcd driver while
> > I have an fbcon running
> > hangs now the command and prevents a kernel reboot, while it works without
> > your series. Can you explain
> > to me again what are you trying to fix?
>
> Sure! DRM managed resources are cleaned up whenever the last reference is
> put. This is not necessarily the case when the driver is unbound, hence
> there might still be calls into the driver and therefore we must protect
> resources that are bound to the driver/device lifecycle (e.g. a MMIO region
> mapped via devm_ioremap_resource()) from being accessed. That's why the
> hdlcd_write() and hdlcd_read() calls in the crtc callbacks need to be
> protected.
>
> However, of course, the changes needed to achieve that should not result
> into hanging rmmod. Unfortunately, just by looking at the patches again I
> don't see how this could happen.
>
> Do you mind trying again with my v2 (although v2 shouldn't make a difference
> for this issue) and provide the back-trace when it hangs?
Hi Danilo,
I've finally got a replacement Juno board that it is stable enough.
I've tried your v2 on top of 7860d720a84c ("drm/msm: Fix build break with
recent mm tree") which
is the head of drm-next today and rmmod hangs. /proc//stack shows:
[<0>] __synchronize_srcu.part.0+0x78/0xec
[<0>] synchronize_srcu+0xe0/0x134
[<0>] drm_dev_unplug+0x2c/0x60 [drm]
[<0>] hdlcd_drm_unbind+0x20/0xc0 [hdlcd]
[<0>] component_master_del+0xa4/0xc0
[<0>] hdlcd_remove+0x1c/0x2c [hdlcd]
[<0>] platform_remove+0x28/0x60
[<0>] device_remove+0x4c/0x80
[<0>] device_release_driver_internal+0x1e4/0x250
[<0>] driver_detach+0x50/0xe0
[<0>] bus_remove_driver+0x5c/0xbc
[<0>] driver_unregister+0x30/0x60
[<0>] platform_driver_unregister+0x14/0x20
[<0>] hdlcd_platform_driver_exit+0x1c/0xe40 [hdlcd]
[<0>] __arm64_sys_delete_module+0x18c/0x240
[<0>] invoke_syscall+0x48/0x114
[<0>] el0_svc_common.constprop.0+0xcc/0xec
[<0>] do_el0_svc+0x2c/0xc0
[<0>] el0_svc+0x2c/0x84
[<0>] el0t_64_sync_handler+0x11c/0x150
[<0>] el0t_64_sync+0x18c/0x190
My quick guess would be that the mixing of managed and unmanaged APIs manages to
confuse the sleepable RCUs and we get the hang. Will chat with Daniel Vetter
next
week at XDC on what would be the best approach here.
Best regards,
Liviu
>
> Thanks,
> Danilo
>
> >
> > Best regards,
> > Liviu
> >
> >
> > >
> > > - Danilo
> > >
> > >
> > >
> > > On 9/12/22 19:36, Liviu Dudau wrote:
> > > > Hi Danilo,
> > > >
> > > > I have applied your pat
Re: [PATCH] drm/fourcc: Fix vsub/hsub for Q410 and Q401
On Mon, Sep 26, 2022 at 04:21:19PM +0100, Brian Starkey wrote:
> On Tue, Sep 13, 2022 at 04:36:57PM +0100, Liviu Dudau wrote:
> > On Tue, Sep 13, 2022 at 03:43:06PM +0100, Brian Starkey wrote:
> > > These formats are not subsampled, but that means hsub and vsub should be
> > > 1, not 0.
> > >
> > > Fixes: 94b292b27734 ("drm: drm_fourcc: add NV15, Q410, Q401 YUV formats")
> > > Reported-by: George Kennedy
> > > Reported-by: butt3rflyh4ck
> > > Signed-off-by: Brian Starkey
> >
> > Reviewed-by: Liviu Dudau
> >
> > Should this be backported into stable releases? How far back to we go?
>
> Probably, git says 94b292b27734 is in since 5.10.
>
> Could someone merge this so it doesn't get lost again?
I'll merge this into drm-misc-next-fixes this week and notify stable about it.
Best regards,
Liviu
>
> Thanks,
> -Brian
>
> >
> > Best regards,
> > Liviu
> >
> >
> > > ---
> > > drivers/gpu/drm/drm_fourcc.c | 8
> > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > >
> > > Sorry, I lost track of this - I thought it got fixed after the previous
> > > thread[1].
> > >
> > > -Brian
> > >
> > > [1]
> > > https://lore.kernel.org/all/26fdb955-10c8-a5d6-07b6-85a4374e7...@oracle.com/
> > >
> > > diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> > > index 07741b678798..6768b7d18b6f 100644
> > > --- a/drivers/gpu/drm/drm_fourcc.c
> > > +++ b/drivers/gpu/drm/drm_fourcc.c
> > > @@ -263,12 +263,12 @@ const struct drm_format_info *__drm_format_info(u32
> > > format)
> > > .vsub = 2, .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 = 0,
> > > - .vsub = 0, .is_yuv = true },
> > > + .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 1,
> > > + .vsub = 1, .is_yuv = true },
> > > { .format = DRM_FORMAT_Q401,.depth = 0,
> > > .num_planes = 3, .char_per_block = { 2, 2, 2 },
> > > - .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
> > > - .vsub = 0, .is_yuv = true },
> > > + .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 1,
> > > + .vsub = 1, .is_yuv = true },
> > > { .format = DRM_FORMAT_P030,.depth = 0,
> > > .num_planes = 2,
> > > .char_per_block = { 4, 8, 0 }, .block_w = { 3, 3, 0 },
> > > .block_h = { 1, 1, 0 },
> > > .hsub = 2, .vsub = 2, .is_yuv = true},
> > > --
> > > 2.25.1
> > >
> >
> > --
> >
> > | I would like to |
> > | fix the world, |
> > | but they're not |
> > | giving me the |
> > \ source code! /
> > ---
> > ¯\_(ツ)_/¯
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH RESEND drm-misc-next 4/7] drm/arm/hdlcd: plane: use drm managed resources
On Wed, Sep 14, 2022 at 12:03:58AM +0200, Danilo Krummrich wrote: > On 9/13/22 10:58, Liviu Dudau wrote: > > On Mon, Sep 12, 2022 at 09:50:26PM +0200, Danilo Krummrich wrote: > > > Hi Liviu, > > > > Hi Danilo, > > > > > > > > Thanks for having a look! > > > > > > This is not about this patch, it's about patch 3/7 "drm/arm/hdlcd: crtc: > > > use > > > drmm_crtc_init_with_planes()". > > > > Agree! However, this is the patch that removes the .destroy hook, so I've > > replied here. > > This is a different .destroy hook, it's the struct drm_plane_funcs one, not > the struct drm_crtc_funcs one, which the warning is about. Anyway, as said, > we can just drop the mentioned patch. :-) Sorry, my mistake. > > > > > > > > > And there it's the other way around. When using > > > drmm_crtc_init_with_planes() > > > we shouldn't have a destroy hook in place, that's the whole purpose of > > > drmm_crtc_init_with_planes(). > > > > > > We should just drop patch 3/7 "drm/arm/hdlcd: crtc: use > > > drmm_crtc_init_with_planes()", it's wrong. > > > > So we end up with mixed use of managed and unmanaged APIs? > > In this case, yes. However, I don't think this makes it inconsistent. They > only thing drmm_crtc_init_with_planes() does different than > drm_crtc_init_with_planes() is that it set's things up to automatically call > drm_crtc_cleanup() on .destroy. Since this driver also does a register write > in the .destroy callback and hence we can't get rid of the callback we can > just keep it as it is. I'm trying to test your v2 on a flaky platform (my Juno R1 has developed some memory issues that leads to crashes on most boots) and I'm seeing some issues that I'm trying to replicate (and understand) before posting the stack trace. I'm not sure yet if they are related to the mixing of managed and unmanaged APIs, I need a bit more time for testing. > > > > > > > > > Do you want me to send a v2 for that? > > > > Yes please! It would help me to understand your thinking around the whole > > lifecycle of the driver. > > > > BTW, I appreciate the care in patches 5-7 to make sure that the driver > > doesn't access freed resources, > > however I'm not sure I like the fact that rmmod-ing the hdlcd driver while > > I have an fbcon running > > hangs now the command and prevents a kernel reboot, while it works without > > your series. Can you explain > > to me again what are you trying to fix? > > Sure! DRM managed resources are cleaned up whenever the last reference is > put. This is not necessarily the case when the driver is unbound, hence > there might still be calls into the driver and therefore we must protect > resources that are bound to the driver/device lifecycle (e.g. a MMIO region > mapped via devm_ioremap_resource()) from being accessed. That's why the > hdlcd_write() and hdlcd_read() calls in the crtc callbacks need to be > protected. Thanks for the explanation on what the code ultimately does. I was trying to understand what was the impetus for the change in the first place. Why did you thought adding the calls to managed APIs was needed and what were you trying to fix? > > However, of course, the changes needed to achieve that should not result > into hanging rmmod. Unfortunately, just by looking at the patches again I > don't see how this could happen. > > Do you mind trying again with my v2 (although v2 shouldn't make a difference > for this issue) and provide the back-trace when it hangs? I'm trying to do that. I've got one good trace that I'm trying to reproduce, but unfortunately my main Juno board has developed a memory fault and the replacement for it is taking longer than I wanted. Best regards, Liviu > > Thanks, > Danilo > > > > > Best regards, > > Liviu > > > > > > > > > > - Danilo > > > > > > > > > > > > On 9/12/22 19:36, Liviu Dudau wrote: > > > > Hi Danilo, > > > > > > > > I have applied your patch series for HDLCD on top of drm-next (commit > > > > 213cb76ddc8b) > > > > and on start up I get a warning: > > > > > > > > [ 12.882554] hdlcd 7ff5.hdlcd: drm_WARN_ON(funcs && > > > > funcs->destroy) > > > > [ 12.882596] WARNING: CPU: 1 PID: 211 at > > > > drivers/gpu/drm/drm_crtc.c:393 __drmm_crtc_init_with_planes+0x70/0xf0 > > > > [drm] > > > > > > > > It looks like the .destroy hook is still required or I'm missing some > > > > other required > > > > series where the WARN has been removed? > > > > > > > > Best regards, > > > > Liviu > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯
Re: [PATCH] drm/fourcc: Fix vsub/hsub for Q410 and Q401
On Tue, Sep 13, 2022 at 03:43:06PM +0100, Brian Starkey wrote:
> These formats are not subsampled, but that means hsub and vsub should be
> 1, not 0.
>
> Fixes: 94b292b27734 ("drm: drm_fourcc: add NV15, Q410, Q401 YUV formats")
> Reported-by: George Kennedy
> Reported-by: butt3rflyh4ck
> Signed-off-by: Brian Starkey
Reviewed-by: Liviu Dudau
Should this be backported into stable releases? How far back to we go?
Best regards,
Liviu
> ---
> drivers/gpu/drm/drm_fourcc.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> Sorry, I lost track of this - I thought it got fixed after the previous
> thread[1].
>
> -Brian
>
> [1]
> https://lore.kernel.org/all/26fdb955-10c8-a5d6-07b6-85a4374e7...@oracle.com/
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index 07741b678798..6768b7d18b6f 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -263,12 +263,12 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> .vsub = 2, .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 = 0,
> - .vsub = 0, .is_yuv = true },
> + .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 1,
> + .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_Q401,.depth = 0,
> .num_planes = 3, .char_per_block = { 2, 2, 2 },
> - .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 0,
> - .vsub = 0, .is_yuv = true },
> + .block_w = { 1, 1, 1 }, .block_h = { 1, 1, 1 }, .hsub = 1,
> + .vsub = 1, .is_yuv = true },
> { .format = DRM_FORMAT_P030,.depth = 0,
> .num_planes = 2,
> .char_per_block = { 4, 8, 0 }, .block_w = { 3, 3, 0 },
> .block_h = { 1, 1, 0 },
> .hsub = 2, .vsub = 2, .is_yuv = true},
> --
> 2.25.1
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH RESEND drm-misc-next 4/7] drm/arm/hdlcd: plane: use drm managed resources
On Mon, Sep 12, 2022 at 09:50:26PM +0200, Danilo Krummrich wrote:
> Hi Liviu,
Hi Danilo,
>
> Thanks for having a look!
>
> This is not about this patch, it's about patch 3/7 "drm/arm/hdlcd: crtc: use
> drmm_crtc_init_with_planes()".
Agree! However, this is the patch that removes the .destroy hook, so I've
replied here.
>
> And there it's the other way around. When using drmm_crtc_init_with_planes()
> we shouldn't have a destroy hook in place, that's the whole purpose of
> drmm_crtc_init_with_planes().
>
> We should just drop patch 3/7 "drm/arm/hdlcd: crtc: use
> drmm_crtc_init_with_planes()", it's wrong.
So we end up with mixed use of managed and unmanaged APIs?
>
> Do you want me to send a v2 for that?
Yes please! It would help me to understand your thinking around the whole
lifecycle of the driver.
BTW, I appreciate the care in patches 5-7 to make sure that the driver doesn't
access freed resources,
however I'm not sure I like the fact that rmmod-ing the hdlcd driver while I
have an fbcon running
hangs now the command and prevents a kernel reboot, while it works without your
series. Can you explain
to me again what are you trying to fix?
Best regards,
Liviu
>
> - Danilo
>
>
>
> On 9/12/22 19:36, Liviu Dudau wrote:
> > Hi Danilo,
> >
> > I have applied your patch series for HDLCD on top of drm-next (commit
> > 213cb76ddc8b)
> > and on start up I get a warning:
> >
> > [ 12.882554] hdlcd 7ff5.hdlcd: drm_WARN_ON(funcs && funcs->destroy)
> > [ 12.882596] WARNING: CPU: 1 PID: 211 at drivers/gpu/drm/drm_crtc.c:393
> > __drmm_crtc_init_with_planes+0x70/0xf0 [drm]
> >
> > It looks like the .destroy hook is still required or I'm missing some other
> > required
> > series where the WARN has been removed?
> >
> > Best regards,
> > Liviu
> >
> > On Mon, Sep 05, 2022 at 05:27:16PM +0200, Danilo Krummrich wrote:
> > > Use drm managed resource allocation (drmm_universal_plane_alloc()) in
> > > order to get rid of the explicit destroy hook in struct drm_plane_funcs.
> > >
> > > Signed-off-by: Danilo Krummrich
> > > ---
> > > drivers/gpu/drm/arm/hdlcd_crtc.c | 20 +++-
> > > 1 file changed, 7 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c
> > > b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > > index c0a5ca7f578a..17d3ccf12245 100644
> > > --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> > > +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> > > @@ -289,7 +289,6 @@ static const struct drm_plane_helper_funcs
> > > hdlcd_plane_helper_funcs = {
> > > static const struct drm_plane_funcs hdlcd_plane_funcs = {
> > > .update_plane = drm_atomic_helper_update_plane,
> > > .disable_plane = drm_atomic_helper_disable_plane,
> > > - .destroy= drm_plane_cleanup,
> > > .reset = drm_atomic_helper_plane_reset,
> > > .atomic_duplicate_state =
> > > drm_atomic_helper_plane_duplicate_state,
> > > .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> > > @@ -297,24 +296,19 @@ static const struct drm_plane_funcs
> > > hdlcd_plane_funcs = {
> > > static struct drm_plane *hdlcd_plane_init(struct drm_device *drm)
> > > {
> > > - struct hdlcd_drm_private *hdlcd = drm->dev_private;
> > > + struct hdlcd_drm_private *hdlcd = drm_to_hdlcd_priv(drm);
> > > struct drm_plane *plane = NULL;
> > > u32 formats[ARRAY_SIZE(supported_formats)], i;
> > > - int ret;
> > > -
> > > - plane = devm_kzalloc(drm->dev, sizeof(*plane), GFP_KERNEL);
> > > - if (!plane)
> > > - return ERR_PTR(-ENOMEM);
> > > for (i = 0; i < ARRAY_SIZE(supported_formats); i++)
> > > formats[i] = supported_formats[i].fourcc;
> > > - ret = drm_universal_plane_init(drm, plane, 0xff, _plane_funcs,
> > > -formats, ARRAY_SIZE(formats),
> > > -NULL,
> > > -DRM_PLANE_TYPE_PRIMARY, NULL);
> > > - if (ret)
> > > - return ERR_PTR(ret);
> > > + plane = drmm_universal_plane_alloc(drm, struct drm_plane, dev, 0xff,
> > > +_plane_funcs,
> > > +formats, ARRAY_SIZE(formats),
> > > +NULL, DRM_PLANE_TYPE_PRIMARY, NULL);
> > > + if (IS_ERR(plane))
> > > + return plane;
> > > drm_plane_helper_add(plane, _plane_helper_funcs);
> > > hdlcd->plane = plane;
> > > --
> > > 2.37.2
> > >
> >
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH RESEND drm-misc-next 4/7] drm/arm/hdlcd: plane: use drm managed resources
Hi Danilo,
I have applied your patch series for HDLCD on top of drm-next (commit
213cb76ddc8b)
and on start up I get a warning:
[ 12.882554] hdlcd 7ff5.hdlcd: drm_WARN_ON(funcs && funcs->destroy)
[ 12.882596] WARNING: CPU: 1 PID: 211 at drivers/gpu/drm/drm_crtc.c:393
__drmm_crtc_init_with_planes+0x70/0xf0 [drm]
It looks like the .destroy hook is still required or I'm missing some other
required
series where the WARN has been removed?
Best regards,
Liviu
On Mon, Sep 05, 2022 at 05:27:16PM +0200, Danilo Krummrich wrote:
> Use drm managed resource allocation (drmm_universal_plane_alloc()) in
> order to get rid of the explicit destroy hook in struct drm_plane_funcs.
>
> Signed-off-by: Danilo Krummrich
> ---
> drivers/gpu/drm/arm/hdlcd_crtc.c | 20 +++-
> 1 file changed, 7 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c
> b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index c0a5ca7f578a..17d3ccf12245 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -289,7 +289,6 @@ static const struct drm_plane_helper_funcs
> hdlcd_plane_helper_funcs = {
> static const struct drm_plane_funcs hdlcd_plane_funcs = {
> .update_plane = drm_atomic_helper_update_plane,
> .disable_plane = drm_atomic_helper_disable_plane,
> - .destroy= drm_plane_cleanup,
> .reset = drm_atomic_helper_plane_reset,
> .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> @@ -297,24 +296,19 @@ static const struct drm_plane_funcs hdlcd_plane_funcs =
> {
>
> static struct drm_plane *hdlcd_plane_init(struct drm_device *drm)
> {
> - struct hdlcd_drm_private *hdlcd = drm->dev_private;
> + struct hdlcd_drm_private *hdlcd = drm_to_hdlcd_priv(drm);
> struct drm_plane *plane = NULL;
> u32 formats[ARRAY_SIZE(supported_formats)], i;
> - int ret;
> -
> - plane = devm_kzalloc(drm->dev, sizeof(*plane), GFP_KERNEL);
> - if (!plane)
> - return ERR_PTR(-ENOMEM);
>
> for (i = 0; i < ARRAY_SIZE(supported_formats); i++)
> formats[i] = supported_formats[i].fourcc;
>
> - ret = drm_universal_plane_init(drm, plane, 0xff, _plane_funcs,
> -formats, ARRAY_SIZE(formats),
> -NULL,
> -DRM_PLANE_TYPE_PRIMARY, NULL);
> - if (ret)
> - return ERR_PTR(ret);
> + plane = drmm_universal_plane_alloc(drm, struct drm_plane, dev, 0xff,
> +_plane_funcs,
> +formats, ARRAY_SIZE(formats),
> +NULL, DRM_PLANE_TYPE_PRIMARY, NULL);
> + if (IS_ERR(plane))
> + return plane;
>
> drm_plane_helper_add(plane, _plane_helper_funcs);
> hdlcd->plane = plane;
> --
> 2.37.2
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
Re: [PATCH RESEND drm-misc-next 0/8] drm/arm/malidp: use drm managed resources
On Mon, Sep 05, 2022 at 05:19:02PM +0200, Danilo Krummrich wrote: > Hi, Hi Danilo, > > This patch series converts the driver to use drm managed resources to prevent > potential use-after-free issues on driver unbind/rebind and to get rid of the > usage of deprecated APIs. Appologies for the extended silence, I was on holiday for 3 weeks and stayed away from mailing lists. Will review the two series this week. Best regards, Liviu > > Danilo Krummrich (8): > drm/arm/malidp: use drmm_* to allocate driver structures > drm/arm/malidp: replace drm->dev_private with drm_to_malidp() > drm/arm/malidp: crtc: use drmm_crtc_init_with_planes() > drm/arm/malidp: plane: use drm managed resources > drm/arm/malidp: use drm_dev_unplug() > drm/arm/malidp: plane: protect device resources after removal > drm/arm/malidp: crtc: protect device resources after removal > drm/arm/malidp: drv: protect device resources after removal > > drivers/gpu/drm/arm/malidp_crtc.c | 48 +--- > drivers/gpu/drm/arm/malidp_drv.c| 58 ++--- > drivers/gpu/drm/arm/malidp_drv.h| 2 + > drivers/gpu/drm/arm/malidp_hw.c | 10 ++--- > drivers/gpu/drm/arm/malidp_mw.c | 6 +-- > drivers/gpu/drm/arm/malidp_planes.c | 45 +++--- > 6 files changed, 100 insertions(+), 69 deletions(-) > > > base-commit: 8fe444eb326869823f3788a4b4da5dca03339d10 > -- > 2.37.2 > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯
Re: [PATCH drm-misc-next v7 2/5] drm/fb: rename FB CMA helpers to FB DMA helpers
em_cma_object *obj = drm_fb_dma_get_gem_obj(fb, i);
> /* memory write buffers are never rotated */
> u8 alignment = malidp_hw_get_pitch_align(malidp->dev, 0);
>
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> b/drivers/gpu/drm/arm/malidp_planes.c
> index a1cee1a5b523..72e0162735fa 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -13,7 +13,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> @@ -722,19 +722,19 @@ static void malidp_set_plane_base_addr(struct
> drm_framebuffer *fb,
> ptr = mp->layer->ptr + (plane_index << 4);
>
> /*
> - * drm_fb_cma_get_gem_addr() alters the physical base address of the
> + * drm_fb_dma_get_gem_addr() alters the physical base address of the
>* framebuffer as per the plane's src_x, src_y co-ordinates (ie to
>* take care of source cropping).
>* For AFBC, this is not needed as the cropping is handled by _AD_CROP_H
>* and _AD_CROP_V registers.
>*/
> if (!afbc) {
> - paddr = drm_fb_cma_get_gem_addr(fb, plane->state,
> + paddr = drm_fb_dma_get_gem_addr(fb, plane->state,
> plane_index);
> } else {
> struct drm_gem_cma_object *obj;
>
> - obj = drm_fb_cma_get_gem_obj(fb, plane_index);
> + obj = drm_fb_dma_get_gem_obj(fb, plane_index);
>
> if (WARN_ON(!obj))
> return;
Hi Danilo,
For the drivers/gpu/drm/arm drivers:
Reviewed-by: Liviu Dudau
Best regards,
Liviu
> diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
> b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
> index f3788d7d82d6..cc4d0fa6262c 100644
> --- a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
> +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
> @@ -7,7 +7,7 @@
>
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> @@ -185,7 +185,7 @@ static void aspeed_gfx_pipe_update(struct
> drm_simple_display_pipe *pipe,
> if (!fb)
> return;
>
> - gem = drm_fb_cma_get_gem_obj(fb, 0);
> + gem = drm_fb_dma_get_gem_obj(fb, 0);
> if (!gem)
> return;
> writel(gem->paddr, priv->base + CRT_ADDR);
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> index 10f31faf140c..ddcbfe7ea0c8 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
> @@ -12,7 +12,7 @@
> #include
> #include
> #include
> -#include
> +#include
> #include
> #include
> #include
> @@ -448,7 +448,7 @@ static void atmel_hlcdc_plane_update_buffers(struct
> atmel_hlcdc_plane *plane,
> sr = atmel_hlcdc_layer_read_reg(>layer, ATMEL_HLCDC_LAYER_CHSR);
>
> for (i = 0; i < state->nplanes; i++) {
> - struct drm_gem_cma_object *gem = drm_fb_cma_get_gem_obj(fb, i);
> + struct drm_gem_cma_object *gem = drm_fb_dma_get_gem_obj(fb, i);
>
> state->dscrs[i]->addr = gem->paddr + state->offsets[i];
>
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> b/drivers/gpu/drm/drm_fb_dma_helper.c
> similarity index 70%
> rename from drivers/gpu/drm/drm_fb_cma_helper.c
> rename to drivers/gpu/drm/drm_fb_dma_helper.c
> index 69c57273b184..85fd21cd9dda 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_dma_helper.c
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0-or-later
> /*
> - * drm kms/fb cma (contiguous memory allocator) helper functions
> + * drm kms/fb dma helper functions
> *
> * Copyright (C) 2012 Analog Devices Inc.
> * Author: Lars-Peter Clausen
> @@ -10,7 +10,7 @@
> */
>
> #include
> -#include
> +#include
> #include
> #include
> #include
> @@ -20,17 +20,22 @@
> #include
>
> /**
> - * DOC: framebuffer cma helper functions
> + * DOC: framebuffer dma helper functions
> *
> - * Provides helper functions for creating a cma (contiguous memory allocator)
> - * backed framebuffer.
> + * Provides helper functions for creating a DMA-contiguous framebuffer.
> + *
> + * Depending on the platform, the buffers may be physically non-contiguous
> and
> + * mapped through an IOMMU or a similar mechanism, or allocated from
> + * physically-contiguous memory (using, for instance, CMA or a pool of memory
> + * reserved at early boot). This is handled behind the scen
[PATCH] drm/komeda: Fix handling of atomic commits in the atomic_commit_tail hook
Komeda driver relies on the generic DRM atomic helper functions to handle
commits. It only implements an atomic_commit_tail hook for the
mode_config_helper_funcs and even that one is pretty close to the generic
implementation with the exception of additional dma_fence signalling.
What the generic helper framework doesn't do is waiting for the actual
hardware to signal that the commit parameters have been written into the
appropriate registers. As we signal CRTC events only on the irq handlers,
we need to flush the configuration and wait for the hardware to respond.
Add the Komeda specific implementation for atomic_commit_hw_done() that
flushes and waits for flip done before calling
drm_atomic_helper_commit_hw_done().
The fix was prompted by a patch from Carsten Haitzler where he was trying to
solve the same issue but in a different way that I think can lead to wrong
event signaling to userspace.
Reported-by: Carsten Haitzler
Tested-by: Carsten Haitzler
Signed-off-by: Liviu Dudau
---
.../gpu/drm/arm/display/komeda/komeda_crtc.c | 4 ++--
.../gpu/drm/arm/display/komeda/komeda_kms.c | 21 ++-
.../gpu/drm/arm/display/komeda/komeda_kms.h | 2 ++
3 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
index 59172acb9738..292f533d8cf0 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
@@ -235,7 +235,7 @@ void komeda_crtc_handle_event(struct komeda_crtc *kcrtc,
crtc->state->event = NULL;
drm_crtc_send_vblank_event(crtc, event);
} else {
- DRM_WARN("CRTC[%d]: FLIP happen but no pending
commit.\n",
+ DRM_WARN("CRTC[%d]: FLIP happened but no pending
commit.\n",
drm_crtc_index(>base));
}
spin_unlock_irqrestore(>dev->event_lock, flags);
@@ -286,7 +286,7 @@ komeda_crtc_atomic_enable(struct drm_crtc *crtc,
komeda_crtc_do_flush(crtc, old);
}
-static void
+void
komeda_crtc_flush_and_wait_for_flip_done(struct komeda_crtc *kcrtc,
struct completion *input_flip_done)
{
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
index 93b7f09b96ca..327051bba5b6 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
@@ -69,6 +69,25 @@ static const struct drm_driver komeda_kms_driver = {
.minor = 1,
};
+static void komeda_kms_atomic_commit_hw_done(struct drm_atomic_state *state)
+{
+ struct drm_device *dev = state->dev;
+ struct komeda_kms_dev *kms = to_kdev(dev);
+ int i;
+
+ for (i = 0; i < kms->n_crtcs; i++) {
+ struct komeda_crtc *kcrtc = >crtcs[i];
+
+ if (kcrtc->base.state->active) {
+ struct completion *flip_done = NULL;
+ if (kcrtc->base.state->event)
+ flip_done =
kcrtc->base.state->event->base.completion;
+ komeda_crtc_flush_and_wait_for_flip_done(kcrtc,
flip_done);
+ }
+ }
+ drm_atomic_helper_commit_hw_done(state);
+}
+
static void komeda_kms_commit_tail(struct drm_atomic_state *old_state)
{
struct drm_device *dev = old_state->dev;
@@ -81,7 +100,7 @@ static void komeda_kms_commit_tail(struct drm_atomic_state
*old_state)
drm_atomic_helper_commit_modeset_enables(dev, old_state);
- drm_atomic_helper_commit_hw_done(old_state);
+ komeda_kms_atomic_commit_hw_done(old_state);
drm_atomic_helper_wait_for_flip_done(dev, old_state);
diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
index 7889e380ab23..7339339ef6b8 100644
--- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
+++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.h
@@ -183,6 +183,8 @@ void komeda_kms_cleanup_private_objs(struct komeda_kms_dev
*kms);
void komeda_crtc_handle_event(struct komeda_crtc *kcrtc,
struct komeda_events *evts);
+void komeda_crtc_flush_and_wait_for_flip_done(struct komeda_crtc *kcrtc,
+ struct completion
*input_flip_done);
struct komeda_kms_dev *komeda_kms_attach(struct komeda_dev *mdev);
void komeda_kms_detach(struct komeda_kms_dev *kms);
--
2.37.1
Re: [PATCH 3/3] drm/komeda - Fix handling of pending crtc state commit to avoid lock-up
On Fri, Jul 08, 2022 at 07:03:37PM +0100, Carsten Haitzler wrote:
>
>
> On 7/8/22 17:02, Liviu Dudau wrote:
> > On Mon, Jun 06, 2022 at 12:47:14PM +0100, carsten.haitz...@foss.arm.com
> > wrote:
> > > From: Carsten Haitzler
> >
> > Hi Carsten,
> >
> > >
> > > Sometimes there is an extra dcm crtc state in the pipeline whose
> > > penting vblank event has not been handled yet. We would previously
> > > throw this out and the vblank event never triggers leading to hard
> > > lockups higher up the stack where an expected vlank event never comes
> > > back (screen freezes).
> > >
> > > This fixes that by tracking a pending crtc state that needs handling
> > > and handle it producing a vlank event next vblank if it had not
> > > laready been handled before. This fixes the hangs and ensures our
> > > display keeps updating seamlessly and is certainly a much better state
> > > to be in than after some time ending up with a mysteriously frozen
> > > screen and a lot of kernle messages complaining about this too.
> >
> > Sorry it took me so long to review and reply to this patch, but I had this
> > nagging
>
> No worries. :)
>
> > feeling that the patch is not actually correct so I've tried to track the
> > actual
> > issue. It turns out that the problem is easy to reproduce in a different
> > setup with
> > Mali D71 and it comes from the fact that Komeda doesn't properly wait for
> > the
> > hardware to signal acceptance of config valid on setting new commits. I
> > have created
> > a new patch that I would be happy if you can test to try to fix the actual
> > issue.
>
> This works (tested).
Thank you very much for testing this! Can I add your Tested-by?
> One errant "flip without commit":
>
> [9.402559] fbcon: Taking over console
> [9.525373] [drm:komeda_print_events [komeda]] *ERROR* err detect: gcu:
> MERR, pipes[0]: FLIP, pipes[1]: None
> [9.525455] [drm] CRTC[0]: FLIP happened but no pending commit.
> [9.542215] Console: switching to colour frame buffer device 240x67
>
Is this with your 2/3 patch applied and coming out from the firmware having
already
initialised the hardware? If so, the handover probably doesn't quiescence the
interrupts correctly so an interrupt is pending when the kernel driver is
initialised. That's another area worth looking at for the handover purposes.
> But nothing worrying. It does work, though doesn't compile due to:
>
> drivers/gpu/drm/arm/display/komeda/komeda_kms.c: In function
> ‘komeda_kms_atomic_commit_hw_done’:
> drivers/gpu/drm/arm/display/komeda/komeda_kms.c:77:9: error: ‘for’ loop
> initial declarations are only allowed in C99 or C11 mode
>77 | for (int i = 0; i < kms->n_crtcs; i++) {
> | ^~~
> drivers/gpu/drm/arm/display/komeda/komeda_kms.c:77:9: note: use option
> ‘-std=c9
> ’, ‘-std=gnu99’, ‘-std=c11’ or ‘-std=gnu11’ to compile your code
>
> but that was a trivial fixup.
Interesting that I'm not seeing that, probably due to using GCC12? Anyway, I'll
fix
that and send a proper patch.
>
> Your commit handler does sit and wait. I guess I avoided that and had it
> still deferred and handled next time the vblank interrupt fires. Yours is a
> bit shorter and less complex so it wins. :)
Yes, that's the essence of my issue with your patch. Delaying the handling of
the
event until the next vblank means older software that doesn't use the
timestamping
from the vblank event will get wrong framerates (playing video might be
affected).
Waiting here when we're also calling drm_atomic_helper_wait_for_flip_done()
after
drm_atomic_helper_commit_hw_done() feels wrong, but then the later is checking
if we
have consumed the event so we have to. Maybe the introduction of the
drm_atomic_helper_fake_vblank() is needed in komeda as well like the generic
commit_tail helper function does? I need to investigate more the next time I
get some
spare cycles on komeda.
I will send a new email with the updated patch and your Tested-by if that's OK.
Best regards,
Liviu
>
> > --8<---
> >
> > From 76f9e5fed216a815e9eb56152f85454521079f10 Mon Sep 17 00:00:00 2001
> > From: Liviu Dudau
> > Date: Fri, 8 Jul 2022 16:39:21 +0100
> > Subject: [PATCH] drm/komeda: Fix handling of atomic commits in the
> > atomic_commit_tail hook
> >
> > Komeda driver relies on the generic DRM atomic helper functions to handle
> > commits. It only implements an atomic_commit_tail hook for the
> > mode_config_helper_funcs and even that one is prett
Re: [PATCH 2/3] drm/komeda - At init write GCU control block to handle already on DPU
On Mon, Jun 06, 2022 at 12:47:13PM +0100, carsten.haitz...@foss.arm.com wrote: > From: Carsten Haitzler > > If something has already set up the DPU before the komeda driver comes > up, it will fail to init because it was just writing to the SRST bit in > the GCU control register and ignoring others. This resulted in TBU > bringup stalling and init failing. By writing completely we also set the > mode back to 0 (inactive) too and thus TBU bringup works. This is a rather large hammer, tbh. I would like to see if there is a better way of handling the handover from EFIFB that this patch is trying to fix, but I lack an usable plaform for that. It will generate a flicker at module load time, but if users of Morello are happy with that, then Acked-by: Liviu Dudau Best regards, Liviu > > Signed-off-by: Carsten Haitzler > --- > drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c > b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c > index 00fa56c29b3e..39618c1a4c81 100644 > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c > @@ -309,8 +309,7 @@ static int d71_reset(struct d71_dev *d71) > u32 __iomem *gcu = d71->gcu_addr; > int ret; > > - malidp_write32_mask(gcu, BLK_CONTROL, > - GCU_CONTROL_SRST, GCU_CONTROL_SRST); > + malidp_write32(gcu, BLK_CONTROL, GCU_CONTROL_SRST); > > ret = dp_wait_cond(!(malidp_read32(gcu, BLK_CONTROL) & > GCU_CONTROL_SRST), > 100, 1000, 1); > -- > 2.32.0 > -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯
