On Fri, 13 Mar 2026 07:20:24 -0600, Jim Cromie <[email protected]> wrote:
> [...]
> Anyway, to play nice with DRM, we change all the constants, from
> macros calling BIT(X), to an explicit "enum ivpu_dbg_category"
> starting at 16 to avoid DRM_UT_CORE..RES. This is all in an indef to
> avoid changing the constants for the non-dyndbg case.
>
> Signed-off-by: Jim Cromie <[email protected]>
Hello,
I have a maybe dumb question: if you enable CONFIG_DRM_USE_DYNAMIC_DEBUG,
then the meaning of ivpu_dbg_mask will change no?
In one case you will have to use ivpu_dbg_mask=0x01 and in the other case
you need ivpu_dbg_mask=0x10. I think this is very missleading.
In this case, I think it will be way easier to completly change the
expected value for ivpu_dbg_mask to have the same behavior with or without
dyndbg.
In addition, I think this could be nice to have a "rule" like: "cores"
should use LSB for their classes, "drivers" should use MSB for theirs
clases.
This way, if DRM decide to create a new class there is less chance of
conflicts.
>
>
> diff --git a/drivers/accel/ivpu/ivpu_drv.h b/drivers/accel/ivpu/ivpu_drv.h
> index 5b34b6f50e69..ef5a96b961fc 100644
> --- a/drivers/accel/ivpu/ivpu_drv.h
> +++ b/drivers/accel/ivpu/ivpu_drv.h
> @@ -81,6 +85,41 @@
> [ ... skip 9 lines ... ]
> +
> +enum ivpu_dbg_category {
> + /*
> + * since accels are drm-devices (CONFIG_DRM_ACCEL_*), adjust
> + * IVPU_DBG_* to avoid DRMs 0..10 class_id reservations.
> + */
Here that could be nice to start the enum at 48, so there is a real hole
between "core" and "drivers" categories.
--
Louis Chauvet <[email protected]>
