On Fri, Mar 20, 2026 at 10:43 AM Louis Chauvet
<[email protected]> wrote:
>
> 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.
yes, it takes a bit more explaining certainly.
The reason I kept the old numbers for the old way was to preserve obviousness.
The /sys/modules/ivpu/parameter/<name> maps bits 0..N, not 16..N+16
I didnt want to fiddle with the conversion, and possibly get it wrong
(miss something).
> 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.
>
some guidance makes sense, Im not so sure a hard rule wouldnt just over-specify.
a simple rule would be reserve-in-8-bit-chunks.
drm.debug has 10-12 bits (not sure exactly) leaving 4-6 for "growth".
So I started IVPU_DBG_* at 16 iirc.
Theres also some question if ACCEL should have their own set of debug-classes,
or should be reusing DRM_UT_*. currently we have both,
1 or 2 accel/* drivers use DRM_UT_CORE (but no others IIRC),
ivpu had many, so I took it as a real-world example of the need
for multiple classes (not just the test-dynamic-debug* scenario).
This maybe isnt optimal. But it might be premature to fit the strait-jacket.
> >
> >
> > 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.
Im unconvinced the distinction is that clear -
DRM_UT_CORE is used in drivers, as are KMS and ATOMIC ( iirc)
And is ACCEL classes core or drivers ? probably a bit of both ??
>
> --
> Louis Chauvet <[email protected]>
