From: Daniel Vetter <daniel@ffwll.ch>
To: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 4/4] drm/i915: Reduce frequency of unspecific HSW reg debugging
Date: Fri, 4 Sep 2015 10:59:53 +0200 [thread overview]
Message-ID: <20150904085953.GS22430@phenom.ffwll.local> (raw)
In-Reply-To: <87d1xya879.fsf@gaia.fi.intel.com>
On Fri, Sep 04, 2015 at 11:40:26AM +0300, Mika Kuoppala wrote:
> Daniel Vetter <daniel@ffwll.ch> writes:
>
> > On Thu, Sep 03, 2015 at 04:51:45PM -0300, Paulo Zanoni wrote:
> >> From: Chris Wilson <chris@chris-wilson.co.uk>
> >>
> >> Delay the expensive read on the FPGA_DBG register from once per mmio to
> >> once per forcewake section when we are doing the general wellbeing
> >> check rather than the targetted error detection. This almost reduces
> >> the overhead of the debug facility (for example when submitting execlists)
> >> to zero whilst keeping the debug checks around.
> >>
> >> v2: Enable one-shot mmio debugging from the interrupt check as well as a
> >> safeguard to catch invalid display writes from outside the powerwell.
> >> v3 (from Paulo): rebase since gen9 addition and intel_uncore_check_errors
> >> removal
> >>
> >> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> >> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> >> Cc: Mika Kuoppala <mika.kuoppala@intel.com>
> >> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> >
> > I'm unclear how this interacts (or how it sould interact) with patch 2:
> > Forcwake is mostly for GT registers, but patch 2 also tries to optimize
> > forcwake for GT registers. Do we really need both?
>
> Assuming the hardware detects access to unpowered domains and
> to unregistered ranges by setting this bit, I would say that patch 2
> is not needed. One could argue that patch 2 is somewhat harmful as
> current register access pattern affects the detection.
>
> Also the commit message in patch 2 is not valid wrt the code.
>
> With skl, the debug bit seems to decay with time, instead of being
> sticky. So in there we could argue that in patch 4/4, the reading
> should be done before (and after) the forcewake scope.
Do we know where the bits decay? Could it be that the firmware (dmc) does
something with it, or maybe it gets reset when we change display power
wells?
> Paulo, have you tried if this bit detects access to unpowered
> domain with hsw/bdw?
Yup, that's the main reason we have this, it's great for catching
rpm/power wells bugs.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-09-04 8:57 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-03 19:51 [PATCH 0/4] Unclaimed register improvements Paulo Zanoni
2015-09-03 19:51 ` [PATCH 1/4] drm/i915: make unclaimed registers be errors again Paulo Zanoni
2015-09-03 19:51 ` [PATCH 2/4] drm/i915: restrict unclaimed register checking Paulo Zanoni
2015-09-04 6:53 ` Mika Kuoppala
2015-09-04 13:38 ` Zanoni, Paulo R
2015-09-04 13:54 ` Ville Syrjälä
2015-09-03 19:51 ` [PATCH 3/4] drm/i915: remove intel_uncore_check_errors() Paulo Zanoni
2015-09-04 11:47 ` Mika Kuoppala
2015-09-03 19:51 ` [PATCH 4/4] drm/i915: Reduce frequency of unspecific HSW reg debugging Paulo Zanoni
2015-09-04 7:02 ` Mika Kuoppala
2015-09-04 13:39 ` Zanoni, Paulo R
2015-09-04 8:27 ` Daniel Vetter
2015-09-04 8:40 ` Mika Kuoppala
2015-09-04 8:59 ` Daniel Vetter [this message]
2015-09-04 11:45 ` Mika Kuoppala
2015-09-04 12:18 ` Mika Kuoppala
2015-09-04 14:53 ` Daniel Vetter
2015-09-04 15:16 ` Ville Syrjälä
2015-09-04 15:20 ` Ville Syrjälä
2015-09-04 15:23 ` Daniel Vetter
2015-09-04 13:46 ` Zanoni, Paulo R
2015-09-04 13:57 ` Mika Kuoppala
2015-09-04 14:08 ` 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=20150904085953.GS22430@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=daniel.vetter@ffwll.ch \
--cc=intel-gfx@lists.freedesktop.org \
--cc=mika.kuoppala@linux.intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox