All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mika Kuoppala <mika.kuoppala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"Len Brown" <len.brown@intel.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Jani Nikula" <jani.nikula@intel.com>,
	fritsch@xbmc.org, miku@iki.fi,
	"Ezequiel Garcia" <ezequiel@vanguardiasur.com.ar>,
	"Michal Feix" <michal@feix.cz>,
	"Hans de Goede" <hdegoede@redhat.com>,
	"Deepak S" <deepak.s@linux.intel.com>,
	"Jarkko Nikula" <jarkko.nikula@linux.intel.com>,
	"# v4 . 2+" <stable@vger.kernel.org>
Subject: Re: [PATCH] drm/i915: Avoid tweaking evaluation thresholds on Baytrail v2
Date: Wed, 15 Feb 2017 15:51:26 +0200	[thread overview]
Message-ID: <87inobo941.fsf@gaia.fi.intel.com> (raw)
In-Reply-To: <20170215125226.GZ18048@nuc-i3427.alporthouse.com>

Chris Wilson <chris@chris-wilson.co.uk> writes:

> On Wed, Feb 15, 2017 at 02:37:50PM +0200, Mika Kuoppala wrote:
>> Certain Baytrails, namely the 4 cpu core variants, have been
>> plaqued by spurious system hangs, mostly occurring with light loads.
>> 
>> Multiple bisects by various people point to a commit which changes the
>> reclocking strategy for Baytrail to follow its bigger brethen:
>> commit 8fb55197e64d ("drm/i915: Agressive downclocking on Baytrail")
>> 
>> There is also a review comment attached to this commit from Deepak S
>> on avoiding punit access on Cherryview and thus it was excluded on
>> common reclocking path. By taking the same approach and omitting
>> the punit access by not tweaking the thresholds when the hardware
>> has been asked to move into different frequency, considerable gains
>> in stability have been observed.
>> 
>> With J1900 box, light render/video load would end up in system hang
>> in usually less than 12 hours. With this patch applied, the cumulative
>> uptime has now been 34 days without issues. To provoke system hang,
>> light loads on both render and bsd engines in parallel have been used:
>> glxgears >/dev/null 2>/dev/null &
>> mpv --vo=vaapi --hwdec=vaapi --loop=inf vid.mp4
>> 
>> So far, author has not witnessed system hang with above load
>> and this patch applied. Reports from the tenacious people at
>> kernel bugzilla are also promising.
>> 
>> Considering that the punit access frequency with this patch is
>> considerably less, there is a possibility that this will push
>> the, still unknown, root cause past the triggering point on most loads.
>> 
>> But as we now can reliably reproduce the hang independently,
>> we can reduce the pain that users are having and use a
>> static thresholds until a root cause is found.
>> 
>> References: https://bugzilla.kernel.org/show_bug.cgi?id=109051
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> Cc: Len Brown <len.brown@intel.com>
>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Cc: Jani Nikula <jani.nikula@intel.com>
>> Cc: fritsch@xbmc.org
>> Cc: miku@iki.fi
>> Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
>> CC: Michal Feix <michal@feix.cz>
>> Cc: Hans de Goede <hdegoede@redhat.com>
>> Cc: Deepak S <deepak.s@linux.intel.com>
>> Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com>
>> Cc: <stable@vger.kernel.org> # v4.2+
>> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
>> ---
>>  drivers/gpu/drm/i915/i915_irq.c | 4 ++--
>>  drivers/gpu/drm/i915/i915_reg.h | 2 ++
>>  drivers/gpu/drm/i915/intel_pm.c | 6 +++++-
>>  3 files changed, 9 insertions(+), 3 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
>> index a887aef..319c02d 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -1095,7 +1095,7 @@ static u32 vlv_wa_c0_ei(struct drm_i915_private *dev_priv, u32 pm_iir)
>>  	if (pm_iir & GEN6_PM_RP_DOWN_EI_EXPIRED) {
>>  		if (!vlv_c0_above(dev_priv,
>>  				  &dev_priv->rps.down_ei, &now,
>> -				  dev_priv->rps.down_threshold))
>> +				  VLV_RP_DOWN_EI_THRESHOLD))
>>  			events |= GEN6_PM_RP_DOWN_THRESHOLD;
>>  		dev_priv->rps.down_ei = now;
>>  	}
>> @@ -1103,7 +1103,7 @@ static u32 vlv_wa_c0_ei(struct drm_i915_private *dev_priv, u32 pm_iir)
>>  	if (pm_iir & GEN6_PM_RP_UP_EI_EXPIRED) {
>>  		if (vlv_c0_above(dev_priv,
>>  				 &dev_priv->rps.up_ei, &now,
>> -				 dev_priv->rps.up_threshold))
>> +				 VLV_RP_UP_EI_THRESHOLD))
>
> A patch to set them as we set the default values during rps enable so
> that you don't break the debug interfaces.
>
>>  			events |= GEN6_PM_RP_UP_THRESHOLD;
>>  		dev_priv->rps.up_ei = now;
>>  	}
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
>> index 141a5c1..1297f6a 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -1135,6 +1135,8 @@ enum skl_disp_power_wells {
>>  #define 	CHV_BIAS_CPU_50_SOC_50 (3 << 2)
>>  
>>  #define VLV_CZ_CLOCK_TO_MILLI_SEC		100000
>> +#define VLV_RP_UP_EI_THRESHOLD			90
>> +#define VLV_RP_DOWN_EI_THRESHOLD		70
>>  
>>  /* vlv2 north clock has */
>>  #define CCK_FUSE_REG				0x8
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
>> index 3d311e1..bce6aae 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -4971,7 +4971,11 @@ static int valleyview_set_rps(struct drm_i915_private *dev_priv, u8 val)
>>  		if (err)
>>  			return err;
>>  
>> -		gen6_set_rps_thresholds(dev_priv, val);
>> +		/* When byt can survive without system hang with dynamic
>> +		 * sw freq adjustments, this restriction can be lifted.
>> +		 */
>> +		if (!IS_VALLEYVIEW(dev_priv))
>
> Are all vlv affected?

Not all. From what I have gathered, the 4 core variants are
the susceptile ones. For example N28xx works, N29xx freezes.

-Mika

> -Chris
>
> -- 
> Chris Wilson, Intel Open Source Technology Centre

  reply	other threads:[~2017-02-15 13:51 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-15 12:37 [PATCH] drm/i915: Avoid tweaking evaluation thresholds on Baytrail v2 Mika Kuoppala
2017-02-15 12:52 ` Chris Wilson
2017-02-15 12:52   ` Chris Wilson
2017-02-15 13:51   ` Mika Kuoppala [this message]
2017-02-15 13:52 ` [PATCH] drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3 Mika Kuoppala
2017-02-15 13:52   ` Mika Kuoppala
2017-02-27  9:25   ` Chris Wilson
2017-02-27  9:25     ` Chris Wilson
2017-02-27 13:22     ` Mika Kuoppala
2017-02-27 13:22       ` Mika Kuoppala
2017-02-15 15:28 ` ✓ Fi.CI.BAT: success for drm/i915: Avoid tweaking evaluation thresholds on Baytrail v2 (rev2) Patchwork

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=87inobo941.fsf@gaia.fi.intel.com \
    --to=mika.kuoppala@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --cc=deepak.s@linux.intel.com \
    --cc=ezequiel@vanguardiasur.com.ar \
    --cc=fritsch@xbmc.org \
    --cc=hdegoede@redhat.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --cc=jarkko.nikula@linux.intel.com \
    --cc=len.brown@intel.com \
    --cc=michal@feix.cz \
    --cc=miku@iki.fi \
    --cc=stable@vger.kernel.org \
    --cc=ville.syrjala@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.