On Tue, 8 Jan 2013 11:07:03 +0100 Daniel Vetter <daniel.vetter at ffwll.ch> wrote: > On Tue, Jan 8, 2013 at 10:32 AM, Chris Wilson > <chris at chris-wilson.co.uk> wrote: > > On Tue, 8 Jan 2013 09:33:57 +0100, Daniel Vetter > > <daniel.vetter at ffwll.ch> wrote: > >> This could very well be caused by dirt left behind by the BIOS, so > >> tune it down to the debug level. > > > > If the issue is solely the one described, then it should be silence > > when we takeover, just like all the other error/debug status > > registers. > > Good point, I'll check whether pimping gt_reset is good enough. I agree with Chris FWIW. Changing this for the sake of the one instance during takeover isn't good enough. > > > DRM_DEBUG is a little too noisy for this, maybe we should look at > > trace_print or one of the other dynamic debugs for this class of > > info? > > The downside of trace_printk is that it doesn't pop up in dmesg. If > all that reg checking starts to hurt, we might want to exclude the GT > range from it - iirc this seemed most useful for display enabling. > -Daniel It was useful for display enabling because that's where the biggest delta was for IVB->HSW. I don't think that it will be the case for all platforms. The reason I found it interesting initially is it's also capable of catching when we try to write to powered down things.
