From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Mcgee, Jeff" Subject: Re: [PATCH] drm/i915: Restore rps/rc6 on reset Date: Tue, 5 Nov 2013 20:38:30 +0000 Message-ID: <1383684075.2524.10.camel@jeffdesk> References: <1383249135-11986-1-git-send-email-jeff.mcgee@intel.com> <1383249135-11986-2-git-send-email-jeff.mcgee@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by gabe.freedesktop.org (Postfix) with ESMTP id B7E21102141 for ; Tue, 5 Nov 2013 12:38:33 -0800 (PST) In-Reply-To: Content-Language: en-US Content-ID: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: Daniel Vetter Cc: intel-gfx List-Id: intel-gfx@lists.freedesktop.org On Mon, 2013-11-04 at 09:44 +0100, Daniel Vetter wrote: > On Thu, Oct 31, 2013 at 8:52 PM, wrote: > > From: Jeff McGee > > > > 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 > > 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