From: Ben Widawsky <ben@bwidawsk.net>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915: tune down unknown unclaime write hsw debug message
Date: Fri, 11 Jan 2013 18:35:10 -0800 [thread overview]
Message-ID: <20130111183510.00007d90@unknown> (raw)
In-Reply-To: <CAKMK7uE+J7zZGVbSBFrYshedYucwtSfY0h4-OzJ3YQ_a_Skmwg@mail.gmail.com>
On Tue, 8 Jan 2013 11:07:03 +0100
Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> On Tue, Jan 8, 2013 at 10:32 AM, Chris Wilson
> <chris@chris-wilson.co.uk> wrote:
> > On Tue, 8 Jan 2013 09:33:57 +0100, Daniel Vetter
> > <daniel.vetter@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.
next prev parent reply other threads:[~2013-01-12 2:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-08 8:33 [PATCH] drm/i915: tune down unknown unclaime write hsw debug message Daniel Vetter
2013-01-08 9:32 ` Chris Wilson
2013-01-08 10:07 ` Daniel Vetter
2013-01-12 2:35 ` Ben Widawsky [this message]
2013-01-14 20:58 ` Paulo Zanoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130111183510.00007d90@unknown \
--to=ben@bwidawsk.net \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.