From: Len Brown <len.brown(a)intel.com>
If native_calibrate_tsc() can not discover the TSC frequency,
via CPUID or via built-in table, it must return without
setting X86_FEATURE_TSC_KNOWN_FREQ. Otherwise, X86_FEATURE_TSC_KNOWN_FREQ
will prevent TSC refined calibration.
This patch allows Linux to correctly support future Intel hardware,
that has (cpu_khz != tsc_khz), and support for CPUID.15
without support for CPUID.15.crystal_khz.
This patch is needed since X86_FEATURE_TSC_KNOWN_FREQ was added in Linux-4.10:
commit 4ca4df0b7eb0
("x86/tsc: Mark TSC frequency determined by CPUID as known")
If not applied, such systems will run with tsc_khz = cpu_khz,
which may result in under-stated TSC rate, and time-of-day drift.
Signed-off-by: Len Brown <len.brown(a)intel.com>
Cc: Bin Gao <bin.gao(a)intel.com>
Cc: <stable(a)vger.kernel.org> # v4.10+
---
arch/x86/kernel/tsc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 8ea117f8142e..ce4b71119c36 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -612,6 +612,8 @@ unsigned long native_calibrate_tsc(void)
}
}
+ if (crystal_khz == 0)
+ return 0;
/*
* TSC frequency determined by CPUID is a "hardware reported"
* frequency and is the most accurate one so far we have. This
--
2.14.0-rc0
From: Len Brown <len.brown(a)intel.com>
Linux-4.9 added INTEL_FAM6_SKYLAKE_X to native_calibrate_tsc(),
allowing the kernel to calculate the TSC frequency,
instead of calibrating:
commit 6baf3d61821f
("x86/tsc: Add additional Intel CPU models to the crystal quirk list")
There are several problems with doing this.
The first is that while SKX servers use a 25 MHz crystal,
SKX workstations (with same model #) use a 24 MHz crystal.
This results in a -4.0% time drift rate on SKX workstations.
But even SKX servers have a problem.
SKX subjects the crystal to an EMI reduction circuit that
reduces its actual value by (approximately) -0.25%.
This results in -1 second per 10 minute time drift
as compared to network time on SKX servers.
This also results in an even more subtle symptom on systems
that use the LAPIC timer (versus the TSC deadline timer).
Clock ticks scheduled with the LAPIC timer arrive a few usec
before the time they are expected (according to the slow TSC).
This causes Linux to poll-idle, when it should be in an idle
power saving state. The idle and clock code do not graciously
recover from this error, sometimes resulting in significant polling
and significant power impact.
So stop using native_calibrate_tsc() for INTEL_FAM6_SKYLAKE_X.
native_calibrate_tsc() will return 0, boot will run with
tsc_khz = cpu_khz, and the TSC refined calibration will
update tsc_khz to correct for the difference.
Yes, a future patch can detect 24 vs 25 MHz crystals,
and it can estimate a correction for the EMI circuit impact.
However, that would effect boot-time only, as we'd probably
choose to keep the refined TSC calibration, because the EMI
correction estimate may not be precise.
Signed-off-by: Len Brown <len.brown(a)intel.com>
Cc: Prarit Bhargava <prarit(a)redhat.com>
Cc: <stable(a)vger.kernel.org> # v4.9+
---
arch/x86/kernel/tsc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 49d772672367..19ca0004caf6 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -602,7 +602,6 @@ unsigned long native_calibrate_tsc(void)
case INTEL_FAM6_KABYLAKE_DESKTOP:
crystal_khz = 24000; /* 24.0 MHz */
break;
- case INTEL_FAM6_SKYLAKE_X:
case INTEL_FAM6_ATOM_DENVERTON:
crystal_khz = 25000; /* 25.0 MHz */
break;
--
2.14.0-rc0
This reverts commit fd865802c66bc451dc515ed89360f84376ce1a56.
This commit causes a regression on some QCA ROME chips. The USB device
reset happens in btusb_open(), hence firmware loading gets interrupted.
Furthermore, this commit stops working after commit
("a0085f2510e8976614ad8f766b209448b385492f Bluetooth: btusb: driver to
enable the usb-wakeup feature"). Reset-resume quirk only gets enabled in
btusb_suspend() when it's not a wakeup source.
If we really want to reset the USB device, we need to do it before
btusb_open(). Let's handle it in drivers/usb/core/quirks.c.
Cc: stable(a)vger.kernel.org
Cc: Leif Liddy <leif.linux(a)gmail.com>
Cc: Matthias Kaehlcke <mka(a)chromium.org>
Cc: Brian Norris <briannorris(a)chromium.org>
Cc: Daniel Drake <drake(a)endlessm.com>
Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com>
---
Daniel, Cc you because this also affects your original quirk patch for
Realtek btusb.
drivers/bluetooth/btusb.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index f7120c9eb9bd..da353c4acdc7 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -3117,12 +3117,6 @@ static int btusb_probe(struct usb_interface *intf,
if (id->driver_info & BTUSB_QCA_ROME) {
data->setup_on_usb = btusb_setup_qca;
hdev->set_bdaddr = btusb_set_bdaddr_ath3012;
-
- /* QCA Rome devices lose their updated firmware over suspend,
- * but the USB hub doesn't notice any status change.
- * Explicitly request a device reset on resume.
- */
- set_bit(BTUSB_RESET_RESUME, &data->flags);
}
#ifdef CONFIG_BT_HCIBTUSB_RTL
--
2.14.1
When the watchdog device is suspended, its timeout is set to the maximum
value. During resume, the previously set timeout should be restored.
This does not work at the moment.
The suspend function calls
imx2_wdt_set_timeout(wdog, IMX2_WDT_MAX_TIME);
and resume reverts this by calling
imx2_wdt_set_timeout(wdog, wdog->timeout);
However, imx2_wdt_set_timeout() updates wdog->timeout. Therefore,
wdog->timeout is set to IMX2_WDT_MAX_TIME when we enter the resume
function.
Fix this by setting wdog->timeout to the previous value at the end of
the suspend function. This manual update makes wdog->timeout different
from the actual setting in the hardware. This should be ok in our case
as kernel code is not running while we're suspended.
Signed-off-by: Martin Kaiser <martin(a)kaiser.cx>
Cc: stable(a)vger.kernel.org
---
drivers/watchdog/imx2_wdt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
index 4874b0f..66efcc0 100644
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -368,6 +368,7 @@ static int imx2_wdt_suspend(struct device *dev)
{
struct watchdog_device *wdog = dev_get_drvdata(dev);
struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
+ unsigned int resume_timeout = wdog->timeout;
/* The watchdog IP block is running */
if (imx2_wdt_is_running(wdev)) {
@@ -377,6 +378,7 @@ static int imx2_wdt_suspend(struct device *dev)
clk_disable_unprepare(wdev->clk);
+ wdog->timeout = resume_timeout;
return 0;
}
--
2.1.4
This is a rework of reverted commit fd865802c66bc451dc515ed89360f84376ce1a56
The issue is that some QCA Rome bluetooth controllers stop functioning upon resume from suspend.
These devices seem to be losing power during suspend. This patch will enable
reset_resume in usb core (instead of btusb) and will target the specific device 0x0cf3:0xe300
Signed-off-by: Leif Liddy <leif.linux(a)gmail.com>
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index a10b346b9777..d94e6658d054 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -248,6 +248,9 @@ static const struct usb_device_id usb_quirk_list[] = {
/* INTEL VALUE SSD */
{ USB_DEVICE(0x8086, 0xf1a5), .driver_info = USB_QUIRK_RESET_RESUME },
+ /* QCA Rome Bluetooth in QCA6174 wireless module */
+ { USB_DEVICE(0x0cf3, 0xe300), .driver_info = USB_QUIRK_RESET_RESUME },
+
{ } /* terminating entry must be last */
};
--
2.14.3
On 12/30/2017 04:41 PM, Ben Hutchings wrote:
> For i915, I think you should either:
> - open a bug at bugs.freedesktop.org (under DRI, DRM/Intel)
> - mail intel-gfx(a)lists.freedesktop.org and cc stable
Done.
https://bugs.freedesktop.org/show_bug.cgi?id=104425
--
========================================================================
Ian Pilcher arequipeno(a)gmail.com
-------- "I grew up before Mark Zuckerberg invented friendship" --------
========================================================================