Only use HPET MSI timers on systems with deep C-state support
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest4 patches 3 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/4 | acpi: acpi_cpu_soft_notify() not getting called on resumedrivers/ | +1 | 0 replies | |
| 2/4 | x86: Do not use hpet MSI as clockevent broadcast devicearch/ include/ kernel/ | +5 | 2 replies | |
| 3/4 | clockevent: Add tick_check_fallback_timer to look for fallback timerinclude/ kernel/ kernel/ +1 more | +77 | 0 replies | |
| 4/4 | x86: Adjust HPET MSI timer rating to work with tick_check_fallback_timerarch/ | +5 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [patch 0/4] Only use HPET MSI timers on systems with deep C-state support
There is a functionality issue reported on some AMD platforms
http://lkml.indiana.edu/hypermail/linux/kernel/0912.2/01118.html
wherein, fdformat fails when HPET MSI based percpu timer is used.
We do not have the real root-cause for that problem. But, that report exposed an issue with our current usage HPET MSI timers. We use HPET MSI timers even on platforms that do not have support for C2/C3 states. On those systems we should rather be using LAPIC timers.
So, this series of patches does just that.
* Use LAPIC timer when there is always running APIC timer
* Use LAPIC timer on platforms that do not have support for deep C states
* Only use HPET MSI timers as percpu timers on systems that have LAPICs that stop in deep C-states _and_ system supports deep C-states
The change turned out to be more than what I expected, due to the current static nature of clockevent rating and unrelated issues in acpi processor driver resume path. I also ended up touching different subsystems to handle this.
If the patchset resolves the issue for Mark and if it looks sane can one of the maintainers queue it up for .34