public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Kamble, Sagar A" <sagar.a.kamble@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	intel-gfx@lists.freedesktop.org, Zhe Wang <zhe1.wang@intel.com>,
	Akash Goel <akash.goel@intel.com>,
	"Satyanantha, Rama Gopal M" <rama.gopal.m.satyanantha@intel.com>,
	Deepak S <deepak.s@intel.com>
Subject: Re: [PATCH v3 1/1] drm/i915: Update GEN6_PMINTRMSK setup with GuC enabled
Date: Tue, 31 May 2016 10:54:24 +0530	[thread overview]
Message-ID: <574D2008.5070602@intel.com> (raw)
In-Reply-To: <20160530201835.GK30389@nuc-i3427.alporthouse.com>



On 5/31/2016 1:48 AM, Chris Wilson wrote:
> On Tue, May 31, 2016 at 12:16:11AM +0530, Sagar Arun Kamble wrote:
>>   void gen6_disable_rps_interrupts(struct drm_i915_private *dev_priv)
>> @@ -4580,6 +4568,28 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
>>   	else
>>   		dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS;
>>   
>> +	dev_priv->rps.pm_intr_keep = 0;
>> +
>> +	/*
>> +	 * SNB,IVB can while VLV,CHV may hard hang on looping batchbuffer
>> +	 * if GEN6_PM_UP_EI_EXPIRED is masked.
>> +	 *
>> +	 * TODO: verify if this can be reproduced on VLV,CHV.
>> +	 */
>> +	if (INTEL_INFO(dev_priv)->gen <= 7 && !IS_HASWELL(dev_priv))
>> +		dev_priv->rps.pm_intr_keep |= GEN6_PM_RP_UP_EI_EXPIRED;
>> +
>> +	/*
>> +	 * If GuC submission is enabled keep PM interrupts routed to GuC
>> +	 * and unmask ARAT Expired interrupt as it is needed by GuC.
>> +	*/
>> +	if (INTEL_INFO(dev_priv)->gen >= 8) {
>> +		if (i915.enable_guc_submission)
>> +			dev_priv->rps.pm_intr_keep |= GEN8_ARAT_EXPIRED_INT_MASK;
>> +		else
>> +			dev_priv->rps.pm_intr_keep |= GEN8_PMINTR_REDIRECT_TO_NON_DISP;
> The logic doesn't match the comment. Don't you want
>
> if (i915.enable_guc_submission) {
> 	dev_priv->rps.pm_intr_keep |= GEN8_ARAT_EXPIRED_INT_MASK;
> 	dev_priv->rps.pm_intr_keep |= GEN8_PMINTR_REDIRECT_TO_NON_DISP;
> }
We don't want to keep GEN8_PMINTR_REDIRECT_TO_NON_DISP if GuC submission 
is used.
I added WARN_ON for bits of GEN6_PMINTRMASK if GuC has set expected.
With GuC loaded bit 31 will be set and bit 9 is reset. GuC might reset 
other bits if it needs
those interrupts. I am extending the logic to other interrupts to make 
it extensible.
Certainly this patch is looking more neat now :) ... Thank you.
>
> as implied by the comment? Although I'm guessing the
> i915.enable_guc_submission will be refined in future, it should do for
> now.
>
>> +		WARN_ON(!(I915_READ(GEN6_PMINTRMSK) |
>> +				GEN8_PMINTR_REDIRECT_TO_NON_DISP));
> Always false;
>
>> +		WARN_ON(I915_READ(GEN6_PMINTRMSK) |
>> +				GEN8_ARAT_EXPIRED_INT_MASK);
> Always true.
>
> I don't this was quite what you meant :)
>
> But the patch is a lot neater now!
> -Chris
>

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-05-31  5:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-30  9:52 [PATCH 1/1] drm/i915: Update GEN6_PMINTRMSK setup with GuC submission Sagar Arun Kamble
2016-05-30 10:08 ` Chris Wilson
2016-05-30 11:21   ` [PATCH v2 1/1] drm/i915: Update GEN6_PMINTRMSK setup with GuC enabled Sagar Arun Kamble
2016-05-30 12:48     ` Chris Wilson
2016-05-30 18:46       ` [PATCH 1/2] SNB (and IVB too I suppose) starts to misbehave if the GPU gets stuck in an infinite batch buffer loop. The GPU apparently hogs something critical and CPUs start to lose interrupts and whatnot. We can keep the system limping along by unmasking some interrupts in GEN6_PMINTRMSK. The EI up interrupt has been previously chosen for that task, so let's never mask it Sagar Arun Kamble
2016-05-30 18:46         ` [PATCH v3 1/1] drm/i915: Update GEN6_PMINTRMSK setup with GuC enabled Sagar Arun Kamble
2016-05-30 20:18           ` Chris Wilson
2016-05-31  5:24             ` Kamble, Sagar A [this message]
2016-05-31  8:28               ` [PATCH v4 " Sagar Arun Kamble
2016-05-31  8:51                 ` Chris Wilson
2016-05-31 23:18                   ` Matt Roper
2016-06-01  6:54                     ` Chris Wilson
2016-06-01  8:14                       ` Kamble, Sagar A
2016-06-01 14:29                       ` Matt Roper
2016-06-02 12:12                         ` Kamble, Sagar A
2016-06-02 12:59                           ` Chris Wilson
2016-05-30 18:55         ` [PATCH 1/1] drm/i915: Never fully mask the the EI up rps interrupt on SNB/IVB Sagar Arun Kamble
2016-05-31 11:05         ` ✗ Ro.CI.BAT: warning for series starting with [1/1] " Patchwork
2016-06-01  8:12           ` Kamble, Sagar A
2016-05-31 11:38 ` ✗ Ro.CI.BAT: warning for series starting with [v4,1/1] drm/i915: Update GEN6_PMINTRMSK setup with GuC enabled (rev5) Patchwork
2016-05-31 15:15   ` Kamble, Sagar A

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=574D2008.5070602@intel.com \
    --to=sagar.a.kamble@intel.com \
    --cc=akash.goel@intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=deepak.s@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=rama.gopal.m.satyanantha@intel.com \
    --cc=zhe1.wang@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