diff mbox

drm/i915: Disable WaGsvRC0ResidencyMethod for vlv

Message ID 1426761584-16693-1-git-send-email-deepak.s@linux.intel.com (mailing list archive)
State New, archived
Headers show

Commit Message

deepak.s@linux.intel.com March 19, 2015, 10:39 a.m. UTC
From: Deepak S <deepak.s@linux.intel.com>

Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
of the baytrail systems :(. Switching back to legacy mode rps.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88012
Signed-off-by: Deepak S <deepak.s@linux.intel.com>
---
 drivers/gpu/drm/i915/i915_irq.c | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

Comments

Jani Nikula March 19, 2015, 11:17 a.m. UTC | #1
On Thu, 19 Mar 2015, deepak.s@linux.intel.com wrote:
> From: Deepak S <deepak.s@linux.intel.com>
>
> Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
> of the baytrail systems :(. Switching back to legacy mode rps.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88012
> Signed-off-by: Deepak S <deepak.s@linux.intel.com>

Introduced in

commit 31685c258e0b0ad6aa486c5ec001382cf8a64212
Author: Deepak S <deepak.s@linux.intel.com>
Date:   Thu Jul 3 17:33:01 2014 -0400

    drm/i915/vlv: WA for Turbo and RC6 to work together.

Cc: stable@vger.kernel.org

> ---
>  drivers/gpu/drm/i915/i915_irq.c | 6 +-----
>  1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 6d8340d..7bbdede 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -4241,11 +4241,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
>  	INIT_WORK(&dev_priv->l3_parity.error_work, ivybridge_parity_work);
>  
>  	/* Let's track the enabled rps events */
> -	if (IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
> -		/* WaGsvRC0ResidencyMethod:vlv */
> -		dev_priv->pm_rps_events = GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED;
> -	else
> -		dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS;
> +	dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS;
>  
>  	INIT_DELAYED_WORK(&dev_priv->gpu_error.hangcheck_work,
>  			  i915_hangcheck_elapsed);
> -- 
> 1.9.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Ville Syrjälä March 19, 2015, 11:18 a.m. UTC | #2
On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepak.s@linux.intel.com wrote:
> From: Deepak S <deepak.s@linux.intel.com>
> 
> Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
> of the baytrail systems :(. Switching back to legacy mode rps.

Do we want to throw out the actual code as well then?

> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88012
> Signed-off-by: Deepak S <deepak.s@linux.intel.com>
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 6 +-----
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 6d8340d..7bbdede 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -4241,11 +4241,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
>  	INIT_WORK(&dev_priv->l3_parity.error_work, ivybridge_parity_work);
>  
>  	/* Let's track the enabled rps events */
> -	if (IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
> -		/* WaGsvRC0ResidencyMethod:vlv */
> -		dev_priv->pm_rps_events = GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED;
> -	else
> -		dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS;
> +	dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS;
>  
>  	INIT_DELAYED_WORK(&dev_priv->gpu_error.hangcheck_work,
>  			  i915_hangcheck_elapsed);
> -- 
> 1.9.1
David Weinehall March 19, 2015, 11:44 a.m. UTC | #3
On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepak.s@linux.intel.com wrote:
> From: Deepak S <deepak.s@linux.intel.com>
> 
> Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
> of the baytrail systems :(. Switching back to legacy mode rps.

Is there any way to identify either what systems it's OK to use on,
or to identif what Baytrail systems it isn't OK to use on?

Just reverting this completely seems overly broad if it's possible to
tell the difference between working and non-working systems.


Kind regards, David Weinehall
deepak.s@linux.intel.com March 19, 2015, 11:53 a.m. UTC | #4
On Thursday 19 March 2015 04:48 PM, Ville Syrjälä wrote:
> On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepak.s@linux.intel.com wrote:
>> From: Deepak S <deepak.s@linux.intel.com>
>>
>> Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
>> of the baytrail systems :(. Switching back to legacy mode rps.
> Do we want to throw out the actual code as well then?
>
Chris as cleaned up patches for VLV rps WA. I think its worth a try

>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88012
>> Signed-off-by: Deepak S <deepak.s@linux.intel.com>
>> ---
>>   drivers/gpu/drm/i915/i915_irq.c | 6 +-----
>>   1 file changed, 1 insertion(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
>> index 6d8340d..7bbdede 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -4241,11 +4241,7 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
>>   	INIT_WORK(&dev_priv->l3_parity.error_work, ivybridge_parity_work);
>>   
>>   	/* Let's track the enabled rps events */
>> -	if (IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
>> -		/* WaGsvRC0ResidencyMethod:vlv */
>> -		dev_priv->pm_rps_events = GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED;
>> -	else
>> -		dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS;
>> +	dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS;
>>   
>>   	INIT_DELAYED_WORK(&dev_priv->gpu_error.hangcheck_work,
>>   			  i915_hangcheck_elapsed);
>> -- 
>> 1.9.1
deepak.s@linux.intel.com March 19, 2015, 12:47 p.m. UTC | #5
On Thursday 19 March 2015 05:14 PM, David Weinehall wrote:
> On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepak.s@linux.intel.com wrote:
>> From: Deepak S <deepak.s@linux.intel.com>
>>
>> Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
>> of the baytrail systems :(. Switching back to legacy mode rps.
> Is there any way to identify either what systems it's OK to use on,
> or to identif what Baytrail systems it isn't OK to use on?
>
> Just reverting this completely seems overly broad if it's possible to
> tell the difference between working and non-working systems.
>
>
> Kind regards, David Weinehall

Restricting the changes to few system will be the right way to go.
How do we get details of now working system?

- Deepak
David Weinehall March 19, 2015, 1:38 p.m. UTC | #6
On Thu, Mar 19, 2015 at 06:17:00PM +0530, Deepak S wrote:
> 
> 
> On Thursday 19 March 2015 05:14 PM, David Weinehall wrote:
> >On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepak.s@linux.intel.com wrote:
> >>From: Deepak S <deepak.s@linux.intel.com>
> >>
> >>Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
> >>of the baytrail systems :(. Switching back to legacy mode rps.
> >Is there any way to identify either what systems it's OK to use on,
> >or to identif what Baytrail systems it isn't OK to use on?
> >
> >Just reverting this completely seems overly broad if it's possible to
> >tell the difference between working and non-working systems.
> 
> Restricting the changes to few system will be the right way to go.
> How do we get details of now working system?

That depends.  Who reported the non-working Baytrail-systems?
And just as importantly, do we have Baytrail systems where this is
confirmed to work?

If we can identify the respective revisions of the systems
we might be able to discern the pattern and continue from there.


Kind regards, David Weinehall
Daniel Vetter March 19, 2015, 4:38 p.m. UTC | #7
On Thu, Mar 19, 2015 at 03:38:19PM +0200, David Weinehall wrote:
> On Thu, Mar 19, 2015 at 06:17:00PM +0530, Deepak S wrote:
> > 
> > 
> > On Thursday 19 March 2015 05:14 PM, David Weinehall wrote:
> > >On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepak.s@linux.intel.com wrote:
> > >>From: Deepak S <deepak.s@linux.intel.com>
> > >>
> > >>Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
> > >>of the baytrail systems :(. Switching back to legacy mode rps.
> > >Is there any way to identify either what systems it's OK to use on,
> > >or to identif what Baytrail systems it isn't OK to use on?
> > >
> > >Just reverting this completely seems overly broad if it's possible to
> > >tell the difference between working and non-working systems.
> > 
> > Restricting the changes to few system will be the right way to go.
> > How do we get details of now working system?
> 
> That depends.  Who reported the non-working Baytrail-systems?
> And just as importantly, do we have Baytrail systems where this is
> confirmed to work?
> 
> If we can identify the respective revisions of the systems
> we might be able to discern the pattern and continue from there.

My experience with random crashes with rps on snb/ivb is that there's no
solid systems, just systems where no one has bothered to be really evil
yet.

I'd be really cautious with whitelisting since it tends to not really
solve the underlying bug (if there is one), usually blows up really fast
in size and is long-term unmaintainable. We've been there a few times with
other hacks and issues :(
-Daniel
Shuang He March 19, 2015, 7:51 p.m. UTC | #8
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
Task id: 6004
-------------------------------------Summary-------------------------------------
Platform          Delta          drm-intel-nightly          Series Applied
PNV                 -1              272/272              271/272
ILK                                  301/301              301/301
SNB                                  303/303              303/303
IVB                                  342/342              342/342
BYT                                  287/287              287/287
HSW                                  362/362              362/362
BDW                                  308/308              308/308
-------------------------------------Detailed-------------------------------------
Platform  Test                                drm-intel-nightly          Series Applied
 PNV  igt_gem_userptr_blits_minor-sync-interruptible      DMESG_WARN(1)PASS(2)      DMESG_WARN(1)PASS(1)
Note: You need to pay more attention to line start with '*'
Jani Nikula April 13, 2015, 12:06 p.m. UTC | #9
On Thu, 19 Mar 2015, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, Mar 19, 2015 at 03:38:19PM +0200, David Weinehall wrote:
>> On Thu, Mar 19, 2015 at 06:17:00PM +0530, Deepak S wrote:
>> > 
>> > 
>> > On Thursday 19 March 2015 05:14 PM, David Weinehall wrote:
>> > >On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepak.s@linux.intel.com wrote:
>> > >>From: Deepak S <deepak.s@linux.intel.com>
>> > >>
>> > >>Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
>> > >>of the baytrail systems :(. Switching back to legacy mode rps.
>> > >Is there any way to identify either what systems it's OK to use on,
>> > >or to identif what Baytrail systems it isn't OK to use on?
>> > >
>> > >Just reverting this completely seems overly broad if it's possible to
>> > >tell the difference between working and non-working systems.
>> > 
>> > Restricting the changes to few system will be the right way to go.
>> > How do we get details of now working system?
>> 
>> That depends.  Who reported the non-working Baytrail-systems?
>> And just as importantly, do we have Baytrail systems where this is
>> confirmed to work?
>> 
>> If we can identify the respective revisions of the systems
>> we might be able to discern the pattern and continue from there.
>
> My experience with random crashes with rps on snb/ivb is that there's no
> solid systems, just systems where no one has bothered to be really evil
> yet.
>
> I'd be really cautious with whitelisting since it tends to not really
> solve the underlying bug (if there is one), usually blows up really fast
> in size and is long-term unmaintainable. We've been there a few times with
> other hacks and issues :(

Plenty of talk but no final verdict on the patch either way, and the bug
is still open too. :(

Deepak, is this patch still needed?

BR,
Jani.





> -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
deepak.s@linux.intel.com April 15, 2015, 7:56 a.m. UTC | #10
On Monday 13 April 2015 05:36 PM, Jani Nikula wrote:
> On Thu, 19 Mar 2015, Daniel Vetter <daniel@ffwll.ch> wrote:
>> On Thu, Mar 19, 2015 at 03:38:19PM +0200, David Weinehall wrote:
>>> On Thu, Mar 19, 2015 at 06:17:00PM +0530, Deepak S wrote:
>>>>
>>>> On Thursday 19 March 2015 05:14 PM, David Weinehall wrote:
>>>>> On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepak.s@linux.intel.com wrote:
>>>>>> From: Deepak S <deepak.s@linux.intel.com>
>>>>>>
>>>>>> Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
>>>>>> of the baytrail systems :(. Switching back to legacy mode rps.
>>>>> Is there any way to identify either what systems it's OK to use on,
>>>>> or to identif what Baytrail systems it isn't OK to use on?
>>>>>
>>>>> Just reverting this completely seems overly broad if it's possible to
>>>>> tell the difference between working and non-working systems.
>>>> Restricting the changes to few system will be the right way to go.
>>>> How do we get details of now working system?
>>> That depends.  Who reported the non-working Baytrail-systems?
>>> And just as importantly, do we have Baytrail systems where this is
>>> confirmed to work?
>>>
>>> If we can identify the respective revisions of the systems
>>> we might be able to discern the pattern and continue from there.
>> My experience with random crashes with rps on snb/ivb is that there's no
>> solid systems, just systems where no one has bothered to be really evil
>> yet.
>>
>> I'd be really cautious with whitelisting since it tends to not really
>> solve the underlying bug (if there is one), usually blows up really fast
>> in size and is long-term unmaintainable. We've been there a few times with
>> other hacks and issues :(
> Plenty of talk but no final verdict on the patch either way, and the bug
> is still open too. :(
>
> Deepak, is this patch still needed?
>
> BR,
> Jani.

Hi Jani,

Chris has cleaned up patches for "WA for Turbo and RC6 to work" & these patches are helping to resolve freeze issue. We can ignore this patch. :)

Thanks
Deepak

>
>
>
>
>> -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
diff mbox

Patch

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6d8340d..7bbdede 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4241,11 +4241,7 @@  void intel_irq_init(struct drm_i915_private *dev_priv)
 	INIT_WORK(&dev_priv->l3_parity.error_work, ivybridge_parity_work);
 
 	/* Let's track the enabled rps events */
-	if (IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
-		/* WaGsvRC0ResidencyMethod:vlv */
-		dev_priv->pm_rps_events = GEN6_PM_RP_DOWN_EI_EXPIRED | GEN6_PM_RP_UP_EI_EXPIRED;
-	else
-		dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS;
+	dev_priv->pm_rps_events = GEN6_PM_RPS_EVENTS;
 
 	INIT_DELAYED_WORK(&dev_priv->gpu_error.hangcheck_work,
 			  i915_hangcheck_elapsed);