[Intel-gfx] [PATCH 1/2] drm/i915/gem: initial conversion to new logging macros using coccinelle

[Jani Nikula]

On Wed, 29 Jan 2020, Jani Nikula <jani.nikula at linux.intel.com> wrote:
> On Tue, 28 Jan 2020, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>> Quoting Jani Nikula (2020-01-28 13:48:10)
>>> On Tue, 28 Jan 2020, Tvrtko Ursulin <tvrtko.ursulin at linux.intel.com> wrote:
>>> >> -DRM_DEBUG(
>>> >> +drm_dbg(&T->drm,
>>> >
>>> > This changes DRM_UT_CORE to DRM_UT_DRIVER so our typical drm.debug=0xe 
>>> > becomes much more spammy.
>>> 
>>> This is what I've instructed Wambui to do in i915. It's my mistake that
>>> I haven't requested this to be pointed out in the commit message.
>>> 
>>> DRM_DEBUG() and DRM_DEBUG_DRIVER() have been conflated over the
>>> years. The former is supposed to be for drm core code only, but drivers
>>> are littered with it. I'm hoping drivers are less likely to use the new
>>> drm_dbg_core() which maps to DRM_DEBUG(). The shorter drm_dbg() is the
>>> new DRM_DEBUG_DRIVER().
>>> 
>>> If you think drm.debug=0xe is too spammy now, the fix is not to abuse
>>> DRM_UT_CORE as a spare category
>>
>> That mistake was made when that category was assigned to user debug like
>> ioctls.
>>
>> Shall I send a revert to remove the spam?
>
> Fine. Please suggest an alternative to DRM_UT_CORE to use here.

How about this for the time being, to continue the conversion:

1. Selectively revert the DRM_DEBUG() calls that were converted to
   drm_dbg() back to DRM_DEBUG() in gt/ and gem/. Let the others be. I
   think elsewhere the conversion is fine.

2. Continue the conversion otherwise, but leave current DRM_DEBUG()
   intact. Except in display/ where I think the conversion is fine.

3. Deal with the DRM_DEBUG() later once we figure out what we want.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center