On Thu, 02 Jan 2020, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
> Quoting Jani Nikula (2020-01-02 09:56:05)
>> On Sat, 07 Dec 2019, Chris Wilson <ch...@chris-wilson.co.uk> wrote:
>> > The cmdparser rejection debug is not for driver development, but for the
>> > user, for which we use a plain DRM_DEBUG().
>> 
>> ...
>> 
>> > -     DRM_DEBUG_DRIVER("CMD: Abnormal rcs cmd length! 0x%08X\n", 
>> > cmd_header);
>> > +     DRM_DEBUG("CMD: Abnormal rcs cmd length! 0x%08X\n", cmd_header);
>> 
>> That's not what the documentation says about the difference between
>> DRM_DEBUG and DRM_DEBUG_DRIVER.
>
> The documentation seems to be a misconception.

How so? DRM_DEBUG() translates to DRM_UT_CORE category, which has been
intended for "generic drm code" since the beginning:

4fefcb27050b ("drm: add separate drm debugging levels")
87fdff81cd2d ("DRM: Add the explanation about DRM debug level")

Because there's so much DRM_DEBUG() usage across drivers, I've named the
new drm_device specific logging macros drm_dbg_core() for DRM_UT_CORE
and drm_dbg() for DRM_UT_DRIVER, with the idea that drm_dbg_core() would
be used exclusively for drivers/gpu/drm/drm_*.[ch].

BR,
Jani.



-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to