diff --git a/packages/linux-firmware/kernel-firmware/package.mk b/packages/linux-firmware/kernel-firmware/package.mk index 1ab715b128..a063c4663a 100644 --- a/packages/linux-firmware/kernel-firmware/package.mk +++ b/packages/linux-firmware/kernel-firmware/package.mk @@ -69,5 +69,6 @@ makeinstall_target() { done # The following file is installed by brcmfmac_sdio-firmware-rpi - rm -fr $FW_TARGET_DIR/brcm/brcmfmac43430-sdio.bin + rm -fr $FW_TARGET_DIR/brcm/brcmfmac43430*-sdio.bin + rm -fr $FW_TARGET_DIR/brcm/brcmfmac43455*-sdio.bin } diff --git a/packages/linux-firmware/wlan-firmware/package.mk b/packages/linux-firmware/wlan-firmware/package.mk index 040b375594..c108feaa00 100644 --- a/packages/linux-firmware/wlan-firmware/package.mk +++ b/packages/linux-firmware/wlan-firmware/package.mk @@ -17,7 +17,7 @@ ################################################################################ PKG_NAME="wlan-firmware" -PKG_VERSION="34a47d9" +PKG_VERSION="cfc1842" PKG_ARCH="any" PKG_LICENSE="Free-to-use" PKG_SITE="https://github.com/LibreELEC/wlan-firmware" diff --git a/packages/linux/patches/default/linux-999.20-i915-pm-Be-less-agressive-with-clockfreq-changes-on-Bay-Trail.patch b/packages/linux/patches/default/linux-999.20-i915-pm-Be-less-agressive-with-clockfreq-changes-on-Bay-Trail.patch new file mode 100644 index 0000000000..0a68a040d8 --- /dev/null +++ b/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 +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 +--- + 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 + diff --git a/packages/linux/patches/default/linux-999.21-intel_idle:-Disable-C6N-and-C6S-on-Bay-Trail.patch b/packages/linux/patches/default/linux-999.21-intel_idle:-Disable-C6N-and-C6S-on-Bay-Trail.patch new file mode 100644 index 0000000000..8b820cdc82 --- /dev/null +++ b/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 +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 +--- + 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 +