On Wed, 29 Jan 2020, Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote: > On Tue, 28 Jan 2020, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: >> Quoting Jani Nikula (2020-01-28 13:48:10) >>> On Tue, 28 Jan 2020, Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
