On ma, 2016-03-21 at 10:28 +0100, Daniel Vetter wrote: > On Fri, Mar 18, 2016 at 11:15:35AM +0200, Imre Deak wrote: > > On Fri, 2016-03-18 at 10:59 +0200, Joonas Lahtinen wrote: > > > On pe, 2016-03-18 at 00:18 +0200, Imre Deak wrote: > > > > On Thu, 2016-03-17 at 22:14 +0000, Chris Wilson wrote: > > > > > > > > > > On Fri, Mar 18, 2016 at 12:09:30AM +0200, Imre Deak wrote: > > > > > > > > > > > > On Thu, 2016-03-17 at 21:48 +0000, Chris Wilson wrote: > > > > > > > > > > > > > > I would also like this to be the preferred > > > > > > > DRM_ERROR reporting mechanism i.e. anytime we emit an > > > > > > > ERROR > > > > > > > we > > > > > > > should > > > > > > > be > > > > > > > encouraging the user to file a bug, and do so in a user > > > > > > > friendly > > > > > > > fashion. > > > > > > Ok, but only in i915 I assume. Should we also convert then > > > > > > all > > > > > > DRM_ERROR to dev_err - with an *ERROR* prefix - or still > > > > > > use > > > > > > DRM_ERROR? > > > > > Within i915. I am thinking along the lines that no DRM_ERROR > > > > > should > > > > > exist that doesn't acknowlege that it is a user facing error > > > > > message > > > > > (i.e. written in plain English and is informative, and > > > > > includes a > > > > > bug > > > > > reporting reference). So i915_report_error() or somesuch. > > > > Ok, will give it a go. > > > > > > Daniel didn't want i915 debugging/erroring mechanisms to deviate > > > from > > > core DRM. So I guess this would follow in the same category. > > > > > > I'm all in for structuring a coherent debugging/error message > > > logic > > > and > > > functions for it and then everyone can follow the suit. > > > > The dev_err/dbg method has obvious advantages, like dynamic debug > > or > > showing the device instance, so I think that's something we want in > > any > > case. I don't see a problem with first rolling it out in i915 then > > proposing it for more generic use. > > Well that's just silly me trying to apply some pressure into making > something that's compatible with DRM_*. Or well, porting those macros > over > to whatever the newfangled fancy thing is. Including keeping > drm.debug > alive with some hacks (we can write our own store functions, which > could > enable the right stuff with dynamic debugging, if we export a few > funcs) > so that the gazillion of howtos out there don't all break. Yea, currently we'd output debug messages even in case of drm.debug==0. I sent a patch that makes __i915_printk() behave the same as DRM_DEBUG_DRIVER for debug messages. I think on top of that a more fancy dynamic debug based filtering can be implemented later as you suggest. --Imre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
