linux: add BayTrail patches

packages/linux/patches/default/linux-999.20-i915-pm-Be-less-agressive-with-clockfreq-changes-on-Bay-Trail.patch

@@ -0,0 +1,89 @@
+From 28ad70a06fb84fe63cd036970db2561b2fd1562b Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Sun, 5 Nov 2017 16:51:23 +0100
+Subject: [PATCH v3 1/2] i915: pm: Be less agressive with clockfreq changes on
+ Bay Trail
+
+Bay Trail devices are known to hang when changing the frequency often,
+this is discussed in great length in:
+https://bugzilla.kernel.org/show_bug.cgi?id=109051
+
+Commit 6067a27d1f01 ("drm/i915: Avoid tweaking evaluation thresholds
+on Baytrail v3") is an attempt to workaround this. Several users in
+bko109051 report that an earlier version of this patch, v1:
+https://bugzilla.kernel.org/attachment.cgi?id=251471
+
+Works better for them and they still see hangs with the merged v3.
+
+Comparing the 2 versions shows that they are indeed not equivalent,
+v1 not only skips writing the GEN6_RP* registers from valleyview_set_rps,
+as v3 does. It also contained these modifications to i915_irq.c:
+
+     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;
+     }
+
+     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))
+             events |= GEN6_PM_RP_UP_THRESHOLD;
+         dev_priv->rps.up_ei = now;
+     }
+
+Which use less aggressive up/down thresholds, which results in less
+GEN6_PM_RP_*_THRESHOLD events and thus in less calls to intel_set_rps() ->
+valleyview_set_rps() -> vlv_punit_write(PUNIT_REG_GPU_FREQ_REQ).
+With the last call being the likely cause of the hang.
+
+This commit hardcodes the threshold_up and _down values for Bay Trail to
+less aggressive values, reducing the amount of clock frequency changes,
+thus avoiding the hangs some people are still seeing with the merged fix.
+
+Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=109051
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+---
+ drivers/gpu/drm/i915/i915_reg.h | 3 +++
+ drivers/gpu/drm/i915/intel_pm.c | 5 ++++-
+ 2 files changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
+index 68a58cce6ab1..2561af075ebb 100644
+--- a/drivers/gpu/drm/i915/i915_reg.h
++++ b/drivers/gpu/drm/i915/i915_reg.h
+@@ -1355,6 +1355,9 @@ enum i915_power_well_id {
+ #define 	VLV_BIAS_CPU_125_SOC_875 (6 << 2)
+ #define 	CHV_BIAS_CPU_50_SOC_50 (3 << 2)
+ 
++#define VLV_RP_UP_EI_THRESHOLD			90
++#define VLV_RP_DOWN_EI_THRESHOLD		70
++
+ /* vlv2 north clock has */
+ #define CCK_FUSE_REG				0x8
+ #define  CCK_FUSE_HPLL_FREQ_MASK		0x3
+diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
+index 01966b89be14..177b6caa0a38 100644
+--- a/drivers/gpu/drm/i915/intel_pm.c
++++ b/drivers/gpu/drm/i915/intel_pm.c
+@@ -6096,8 +6096,11 @@ static void gen6_set_rps_thresholds(struct drm_i915_private *dev_priv, u8 val)
+ 	/* When byt can survive without system hang with dynamic
+ 	 * sw freq adjustments, this restriction can be lifted.
+ 	 */
+-	if (IS_VALLEYVIEW(dev_priv))
++	if (IS_VALLEYVIEW(dev_priv)) {
++		threshold_up = VLV_RP_UP_EI_THRESHOLD;
++		threshold_down = VLV_RP_DOWN_EI_THRESHOLD;
+ 		goto skip_hw_write;
++	}
+ 
+ 	I915_WRITE(GEN6_RP_UP_EI,
+ 		   GT_INTERVAL_FROM_US(dev_priv, ei_up));
+-- 
+2.14.3
+

packages/linux/patches/default/linux-999.21-intel_idle:-Disable-C6N-and-C6S-on-Bay-Trail.patch

@@ -0,0 +1,53 @@
+From 945d0eb39d8920854c72ecb743c07d54b738cf7f Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Thu, 9 Nov 2017 14:21:24 +0100
+Subject: [PATCH v3 2/2] intel_idle: Disable C6N and C6S on Bay Trail
+
+It seems that Bay Trail SoCs sometimes have issues waking from C6,
+a lot of users even report Bay Trail devices only being stable
+when passing intel_idle.max_cstate=1 to the kernel.
+
+This commits disables the C6 states while leaving the C7 states
+available so that the cores can still reach deep sleep states.
+
+There are several indicators that this is part of the solution for
+all the users who need to pass intel_idle.max_cstate=1:
+
+1) The "VLP52 EOI Transactions May Not be Sent if Software
+   Enters Core C6 During an Interrupt Service Routine" errata.
+
+2) Several users who need intel_idle.max_cstate=1 indicate in bko109051
+   (which has over 800 comments!) that using a shell script which
+   disables C6N and C6S through sysfs allows them to remove
+   intel_idle.max_cstate=1 and still have a stable system which does
+   use the C7 states for power-saving.
+
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=109051
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+---
+ drivers/idle/intel_idle.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
+index 5dc7ea4b6bc4..fe05984c9e81 100644
+--- a/drivers/idle/intel_idle.c
++++ b/drivers/idle/intel_idle.c
+@@ -221,6 +221,7 @@ static struct cpuidle_state byt_cstates[] = {
+ 		.flags = MWAIT2flg(0x58) | CPUIDLE_FLAG_TLB_FLUSHED,
+ 		.exit_latency = 300,
+ 		.target_residency = 275,
++		.disabled = true,
+ 		.enter = &intel_idle,
+ 		.enter_s2idle = intel_idle_s2idle, },
+ 	{
+@@ -229,6 +230,7 @@ static struct cpuidle_state byt_cstates[] = {
+ 		.flags = MWAIT2flg(0x52) | CPUIDLE_FLAG_TLB_FLUSHED,
+ 		.exit_latency = 500,
+ 		.target_residency = 560,
++		.disabled = true,
+ 		.enter = &intel_idle,
+ 		.enter_s2idle = intel_idle_s2idle, },
+ 	{
+-- 
+2.14.3
+