From: "Mcgee, Jeff" <jeff.mcgee@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915: Restore rps/rc6 on reset
Date: Tue, 5 Nov 2013 20:38:30 +0000 [thread overview]
Message-ID: <1383684075.2524.10.camel@jeffdesk> (raw)
In-Reply-To: <CAKMK7uEJwknR8nH_6o+Fb+S=M-rXMYfy-NhNCvGrQx6ctAPxmg@mail.gmail.com>
On Mon, 2013-11-04 at 09:44 +0100, Daniel Vetter wrote:
> On Thu, Oct 31, 2013 at 8:52 PM, <jeff.mcgee@intel.com> wrote:
> > From: Jeff McGee <jeff.mcgee@intel.com>
> >
> > A check of rps/rc6 state after i915_reset determined that the ring
> > MAX_IDLE registers were returned to their hardware defaults and that
> > the GEN6_PMIMR register was set to mask all interrupts. This change
> > restores those values to their pre-reset states by re-initializing
> > rps/rc6 in i915_reset. A full re-initialization was opted for versus
> > a targeted set of restore operations for simplicity and maintain-
> > ability. Note that the re-initialization is not done for Ironlake,
> > due to a past comment that it causes problems.
> >
> > Also updated the rps initialization sequence to preserve existing
> > min/max values in the case of a re-init. We assume the values were
> > validated upon being set and do not do further range checking. The
> > debugfs interface for changing min/max was updated with range
> > checking to ensure this condition (already present in sysfs
> > interface).
> >
> > Issue: VIZ-3142
> > Issue: AXIA-4676
> > OTC-Tracker: VIZ-3143
> > Signed-off-by: Jeff McGee <jeff.mcgee@intel.com>
>
> Can I have a testcase in i-g-t for this please? I think the following
> should work:
>
> 1. Throw a dummy load onto the gpu, check that cagf goes up.
>
> 2. Limit min/max to a non-default value (and install an igt atexit
> handler to undo this).
>
> 3. Throw a dummy load onto the gpu, check that cagf jumps from the
> idle freq to the selected one directly.
>
> 4. Inject a gpu hang with the stop_rings stuff (see e.g. kms_flip.c or
> ZZ_hangman).
>
> 5. Reject that the limts still work as in step 3.
>
> Cheers, Daniel
I'll see what can be done. I understand the emphasis on adding
formalized tests. There will have to be some resourcing discussions on
the product side if this is now a requirement for upstream patch
acceptance.
Jeff
next prev parent reply other threads:[~2013-11-05 20:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-31 19:52 [PATCH] drm/i915: Restore rps/rc6 on reset jeff.mcgee
2013-10-31 19:52 ` jeff.mcgee
2013-11-04 8:44 ` Daniel Vetter
2013-11-05 20:38 ` Mcgee, Jeff [this message]
2013-11-06 19:37 ` Mcgee, Jeff
2014-02-04 17:32 ` [PATCH v2] " jeff.mcgee
2014-02-07 9:25 ` Daniel Vetter
2013-11-01 10:47 ` [PATCH] " Jani Nikula
2013-11-01 11:05 ` Daniel Vetter
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=1383684075.2524.10.camel@jeffdesk \
--to=jeff.mcgee@intel.com \
--cc=daniel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox