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
next prev parent reply other threads:[~2017-02-15 13:51 UTC|newest]
Thread overview: 7+ 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 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-27 9:25 ` Chris Wilson
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox