On Thu, 02 Jan 2020, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
> Quoting Jani Nikula (2020-01-02 09:56:05)
>> On Sat, 07 Dec 2019, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
