summaryrefslogtreecommitdiff
path: root/drivers/acpi
AgeCommit message (Collapse)Author
2015-03-20Revert "x86/PCI: Refine the way to release PCI IRQ resources"Rafael J. Wysocki
Commit b4b55cda5874 (Refine the way to release PCI IRQ resources) introduced a regression in the PCI IRQ resource management by causing the IRQ resource of a device, established when pci_enabled_device() is called on a fully disabled device, to be released when the driver is unbound from the device, regardless of the enable_cnt. This leads to the situation that an ill-behaved driver can now make a device unusable to subsequent drivers by an imbalance in their use of pci_enable/disable_device(). That is a serious problem for secondary drivers like vfio-pci, which are innocent of the transgressions of the previous driver. Since the solution of this problem is not immediate and requires further discussion, revert commit b4b55cda5874 and the issue it was supposed to address (a bug related to xen-pciback) will be taken care of in a different way going forward. Reported-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-09ACPI / LPSS: provide con_id for the clkdevHeikki Krogerus
Commit 7d78cbefaa (serial: 8250_dw: add ability to handle the peripheral clock) introduces handling for a second clk to 8250_dw.c which is the driver also for LPSS UART. The second clk forces us to provide identifier (con_id) for the clkdev we create. This fixes an issue where 8250_dw.c is getting the same handler for both clocks. Fixes: 7d78cbefaa (serial: 8250_dw: add ability to handle the peripheral clock) Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Cc: 3.17+ <stable@vger.kernel.org> # 3.17+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-06Merge branch 'acpi-video'Rafael J. Wysocki
* acpi-video: ACPI / video: Propagate the error code for acpi_video_register ACPI / video: Load the module even if ACPI is disabled
2015-03-04ACPI / video: Propagate the error code for acpi_video_registerChris Wilson
Report the actual error code from acpi_bus_register_driver(), it may help future debugging (typically ENODEV as previously reported, but the unusual cases are where it may help most). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-04ACPI / video: Load the module even if ACPI is disabledChris Wilson
i915.ko depends upon the acpi/video.ko module and so refuses to load if ACPI is disabled at runtime if for example the BIOS is broken beyond repair. acpi/video provides an optional service for i915.ko and so we should just allow the modules to load, but do no nothing in order to let the machines boot correctly. Reported-by: Bill Augur <bill-auger@programmer.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@intel.com> Cc: All applicable <stable@vger.kernel.org> Acked-by: Aaron Lu <aaron.lu@intel.com> [ rjw: Fixed up the new comment in acpi_video_init() ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-04x86/PCI/ACPI: Relax ACPI resource descriptor checks to work around BIOS bugsJiang Liu
Some BIOSes report incorrect length for ACPI address space descriptors, so relax the checks to avoid regressions. This issue has appeared several times as: 3162b6f0c5e1 ("PNPACPI: truncate _CRS windows with _LEN > _MAX - _MIN + 1") d558b483d5a7 ("x86/PCI: truncate _CRS windows with _LEN > _MAX - _MIN + 1") f238b414a74a ("PNPACPI: compute Address Space length rather than using _LEN") 48728e077480 ("x86/PCI: compute Address Space length rather than using _LEN") Please refer to https://bugzilla.kernel.org/show_bug.cgi?id=94221 for more details and example malformed ACPI resource descriptors. Link: https://bugzilla.kernel.org/show_bug.cgi?id=94221 Fixes: 593669c2ac0f (x86/PCI/ACPI: Use common ACPI resource interfaces ...) Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com> Tested-by: Dave Airlie <airlied@redhat.com> Tested-by: Prakash Punnoor <prakash@punnoor.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-21Merge tag 'pm+acpi-3.20-rc1-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull one more batch of power management and ACPI updates from Rafael Wysocki: "These are mostly fixes on top of the previously merged recent PM and ACPI material. First, one commit that broke the ACPI LPSS (Low-Power Subsystem) driver on a Dell box is reverted and there are two stable-candidate fixes for that driver. Another fix cleans up two recently added ACPI EC messages that look odd and the printk level of a noisy debug message in the core ACPI resources handling code is reduced. In addition to that we have two stable-candidate fixes for the s3c cpufreq driver, two cpuidle powernv driver updates related to Device Trees and a PNP subsystem cleanup that will allow us to get rid of some old ugliness going forward. Also there is a new blacklist entry for the ACPI backlight code. Specifics: - Revert a recent ACPI LPSS driver commit that prevented the touchpad driver from loading on Dell XPS13 (Jarkko Nikula). - Make the ACPI LPSS driver disable the I2C controllers and deassert SPI host controllers resets at startup on Intel BayTrail and Braswell SoCs in case they have been left in wrong states by the platform firmware which then may casuse fatal controller driver failures during resume from hibernation (Mika Westerberg). - Make two recently added ACPI EC messages look better (Scot Doyle). - Reduce the printk level of a recently added debug message related to ACPI resources that may become noisy in some cases (Rafael J Wysocki). - Add a new ACPI backlight blacklist entry for Samsung Series 9 (900X3C/900X3D/900X3E/900X4C/900X4D) laptops where the native backlight interface doesn't work while the ACPI based one does (Jens Reyer). - Make the PNP sybsystem's core code use __request_region() followed by __release_region() instead of __check_region() which then will allow us to get rid of the latter as it has no more users (Jakub Sitnicki). - Fix a build breakage and an issue with two __init functions that may be called after initialization in the s3c cpufreq driver (Arnd Bergmann). - Make the powernv cpuidle driver read target_residency values for idle states from a Device Tree (as we have the suitable DT bindings for that now) and improve the parsing of the powermgmt DT node in that driver (Preeti U Murthy)" * tag 'pm+acpi-3.20-rc1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: cpuidle: powernv: Avoid endianness conversions while parsing DT cpufreq: s3c: remove last use of resume_clocks callback cpufreq: s3c: remove incorrect __init annotations ACPI / LPSS: Deassert resets for SPI host controllers on Braswell ACPI / LPSS: Always disable I2C host controllers ACPI / resources: Change pr_info() to pr_debug() for debug information ACPI / video: Disable native backlight on Samsung Series 9 laptops cpuidle: powernv: Read target_residency value of idle states from DT if available Revert "ACPI / LPSS: Remove non-existing clock control from Intel Lynxpoint I2C" ACPI / EC: Remove non-standard log emphasis PNP: Switch from __check_region() to __request_region()
2015-02-21Merge branches 'acpi-ec', 'acpi-soc', 'acpi-video' and 'acpi-resources'Rafael J. Wysocki
* acpi-ec: ACPI / EC: Remove non-standard log emphasis * acpi-soc: ACPI / LPSS: Deassert resets for SPI host controllers on Braswell ACPI / LPSS: Always disable I2C host controllers Revert "ACPI / LPSS: Remove non-existing clock control from Intel Lynxpoint I2C" * acpi-video: ACPI / video: Disable native backlight on Samsung Series 9 laptops * acpi-resources: ACPI / resources: Change pr_info() to pr_debug() for debug information
2015-02-19Merge branch 'next' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux Pull thermal managament updates from Zhang Rui: "Specifics: - Abstract the code and introduce helper functions for all int340x thermal drivers. From: Srinivas Pandruvada. - Reorganize the ACPI LPAT table support code so that it can be shared for both ACPI PMIC driver and int340x thermal driver. - Add support for Braswell in intel_soc_dts thermal driver. - a couple of small fixes/cleanups for step_wise governor and int340x thermal driver" * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux: Thermal/int340x_thermal: remove unused uuids. thermal: step_wise: spelling fixes thermal: int340x: fix sparse warning Thermal/int340x: LPAT conversion for temperature ACPI / PMIC: Use common LPAT table handling functions ACPI / LPAT: Common table processing functions thermal: Intel SoC DTS: Add Braswell support Thermal/int340x/int3402: Provide notification support Thermal/int340x/processor_thermal: Add thermal zone support Thermal/int340x/int3403: Use int340x thermal API Thermal/int340x/int3402: Use int340x thermal API Thermal/int340x: Add common thermal zone handler
2015-02-18ACPI / LPSS: Deassert resets for SPI host controllers on BraswellMika Westerberg
On some Braswell systems BIOS leaves resets for SPI host controllers active. This prevents the SPI driver from transferring messages on wire. Fix this in similar way that we do for I2C already by deasserting resets for the SPI host controllers. Reported-by: Yang A Fang <yang.a.fang@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: 3.17+ <stable@vger.kernel.org> # 3.17+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-18ACPI / LPSS: Always disable I2C host controllersMika Westerberg
On Baytrail and Braswell the BIOS might leave the I2C host controllers enabled, probably because it uses them for its own purposes. This is fine in normal cases because the I2C driver will disable the hardware when it is probed anyway. However, in case of suspend to disk it is different story. If the driver happens to be compiled as a module the boot kernel never loads the driver thus leaving host controllers enabled upon loading the hibernation image. The I2C host controller interrupt mask register has default value of 0x8ff, in other words it has most of the interrupts unmasked. When combined with the fact that the host controller is enabled, the driver immediately starts getting interrupts even before its resume hook is called (once IO-APIC is resumed). Since the driver is not prepared for this it will crash the kernel due to NULL pointer derefence because dev->msgs is NULL. Unfortunately we were not able to get full backtrace to from the console which could be reproduced here. In order to fix this even when the driver is compiled as module, we disable the I2C host controllers in byt_i2c_setup() before devices are created. Reported-by: Yu Chen <yu.c.chen@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: 3.17+ <stable@vger.kernel.org> # 3.17+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-18ACPI / resources: Change pr_info() to pr_debug() for debug informationRafael J. Wysocki
Annoying and noisy ACPI debug messages are printed with pr_info() after the recent ACPI resources handling rework. Replace the pr_info() with pr_debug() to reduce to noise level. Reported-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-18ACPI / video: Disable native backlight on Samsung Series 9 laptopsJens Reyer
Add video_disable_native_backlight quirk for SAMSUNG 900X3C/900X3D/ 900X3E/900X4C/900X4D laptops. The native intel backlight controls do not work correctly on SAMSUNG Series 9 (900X3C/900X3D/900X3E/900X4C/900X4D) laptops: One machine has an completely dimmed (= black) display after boot at the GDM login screen and brightness controls work only between 0 and 5% (= no effect). Another machine has the same brightness control issues if an external HDMI monitor is or gets connected, although the initial brightness is ok. After login to Gnome both machines always work fine. Tested on both machines. Link: https://bugs.freedesktop.org/show_bug.cgi?id=87286 Link: https://bugs.debian.org/772440 Signed-off-by: Jens Reyer <jens.reyer@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-17Revert "ACPI / LPSS: Remove non-existing clock control from Intel Lynxpoint I2C"Jarkko Nikula
Revert commit b893e80e3147 ("ACPI / LPSS: Remove non-existing clock control from Intel Lynxpoint I2C") because it causes touchpad to not load on Dell XPS13. Regression is a clear indication that not only some early prototype version of Lynxpoint I2C but also newer versions can be doing clock gating even documentation does not state it. Therefore it is best to revert since this clock gating haven't caused known issues on those Lynxpoint version which don't do clock gating. Reported-by-and-tested-by: Chris Rorvick <chris@rorvick.com> Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-17ACPI / EC: Remove non-standard log emphasisScot Doyle
Remove unusual pr_info() visual emphasis introduced in ad479e7f47ca "ACPI / EC: Introduce STARTED/STOPPED flags to replace BLOCKED flag". Signed-off-by: Scot Doyle <lkml14@scotdoyle.com> [ rjw: Change pr_info() to pr_debug() too in those places. ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-15ACPI / idle: Implement ->enter_freeze callback routineRafael J. Wysocki
Add an ->enter_freeze callback routine, acpi_idle_enter_freeze(), to the ACPI cpuidle driver and point ->enter_freeze to it for all the C2-type and C3-type states that don't need to fall back to C1 (which may be halt-induced and that will re-enable interrupts on exit from idle, which ->enter_freeze cannot do). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
2015-02-13Merge tag 'pm+acpi-3.20-rc1-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull more ACPI and power management updates from Rafael Wysocki: "These are two reverts related to system suspend breakage by one of a recent commits, a fix for a recently introduced bug in devfreq and a bunch of other things that didn't make it into my previous pull request, but otherwise are ready to go. Specifics: - Revert two ACPI EC driver commits, one that broke system suspend on Acer Aspire S5 and one that depends on it (Rafael J Wysocki). - Fix a typo leading to an incorrect check in the exynos-ppmu devfreq driver (Dan Carpenter). - Add support for one more Broadwell CPU model to intel_idle (Len Brown). - Fix an obscure problem with state transitions related to interrupts in the speedstep-smi cpufreq driver (Mikulas Patocka). - Remove some unnecessary messages related to the "out of memory" condition from the core PM code (Quentin Lambert). - Update turbostat parameters and documentation, add support for one more Broadwell CPU model to it and modify it to skip printing disabled package C-states (Len Brown)" * tag 'pm+acpi-3.20-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: PM / devfreq: event: testing the wrong variable cpufreq: speedstep-smi: enable interrupts when waiting PM / OPP / clk: Remove unnecessary OOM message Revert "ACPI / EC: Add query flushing support" Revert "ACPI / EC: Add GPE reference counting debugging messages" tools/power turbostat: support additional Broadwell model intel_idle: support additional Broadwell model tools/power turbostat: update parameters, documentation tools/power turbostat: Skip printing disabled package C-states
2015-02-13Merge branch 'acpi-ec'Rafael J. Wysocki
* acpi-ec: Revert "ACPI / EC: Add query flushing support" Revert "ACPI / EC: Add GPE reference counting debugging messages"
2015-02-13kernel.h: remove ancient __FUNCTION__ hackRasmus Villemoes
__FUNCTION__ hasn't been treated as a string literal since gcc 3.4, so this only helps people who only test-compile using 3.3 (compiler-gcc3.h barks at anything older than that). Besides, there are almost no occurrences of __FUNCTION__ left in the tree. [akpm@linux-foundation.org: convert remaining __FUNCTION__ references] Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Cc: Michal Nazarewicz <mina86@mina86.com> Cc: Joe Perches <joe@perches.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2015-02-11Revert "ACPI / EC: Add query flushing support"Rafael J. Wysocki
Revert commit f252cb09e1cb (ACPI / EC: Add query flushing support), because it breaks system suspend on Acer Aspire S5. The machine just hangs solid at the last stage of suspend (after taking non-boot CPUs offline). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-11Revert "ACPI / EC: Add GPE reference counting debugging messages"Rafael J. Wysocki
Revert commit b5bca896ef3c (ACPI / EC: Add GPE reference counting debugging messages), because it depends on commit f252cb09e1cb (ACPI / EC: Add query flushing support) which breaks system suspend on Acer Aspire S5 and needs to be reverted. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-11Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-nextLinus Torvalds
Pull networking updates from David Miller: 1) More iov_iter conversion work from Al Viro. [ The "crypto: switch af_alg_make_sg() to iov_iter" commit was wrong, and this pull actually adds an extra commit on top of the branch I'm pulling to fix that up, so that the pre-merge state is ok. - Linus ] 2) Various optimizations to the ipv4 forwarding information base trie lookup implementation. From Alexander Duyck. 3) Remove sock_iocb altogether, from CHristoph Hellwig. 4) Allow congestion control algorithm selection via routing metrics. From Daniel Borkmann. 5) Make ipv4 uncached route list per-cpu, from Eric Dumazet. 6) Handle rfs hash collisions more gracefully, also from Eric Dumazet. 7) Add xmit_more support to r8169, e1000, and e1000e drivers. From Florian Westphal. 8) Transparent Ethernet Bridging support for GRO, from Jesse Gross. 9) Add BPF packet actions to packet scheduler, from Jiri Pirko. 10) Add support for uniqu flow IDs to openvswitch, from Joe Stringer. 11) New NetCP ethernet driver, from Muralidharan Karicheri and Wingman Kwok. 12) More sanely handle out-of-window dupacks, which can result in serious ACK storms. From Neal Cardwell. 13) Various rhashtable bug fixes and enhancements, from Herbert Xu, Patrick McHardy, and Thomas Graf. 14) Support xmit_more in be2net, from Sathya Perla. 15) Group Policy extensions for vxlan, from Thomas Graf. 16) Remove Checksum Offload support for vxlan, from Tom Herbert. 17) Like ipv4, support lockless transmit over ipv6 UDP sockets. From Vlad Yasevich. * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next: (1494+1 commits) crypto: fix af_alg_make_sg() conversion to iov_iter ipv4: Namespecify TCP PMTU mechanism i40e: Fix for stats init function call in Rx setup tcp: don't include Fast Open option in SYN-ACK on pure SYN-data openvswitch: Only set TUNNEL_VXLAN_OPT if VXLAN-GBP metadata is set ipv6: Make __ipv6_select_ident static ipv6: Fix fragment id assignment on LE arches. bridge: Fix inability to add non-vlan fdb entry net: Mellanox: Delete unnecessary checks before the function call "vunmap" cxgb4: Add support in cxgb4 to get expansion rom version via ethtool ethtool: rename reserved1 memeber in ethtool_drvinfo for expansion ROM version net: dsa: Remove redundant phy_attach() IB/mlx4: Reset flow support for IB kernel ULPs IB/mlx4: Always use the correct port for mirrored multicast attachments net/bonding: Fix potential bad memory access during bonding events tipc: remove tipc_snprintf tipc: nl compat add noop and remove legacy nl framework tipc: convert legacy nl stats show to nl compat tipc: convert legacy nl net id get to nl compat tipc: convert legacy nl net id set to nl compat ...
2015-02-10Merge tag 'pm+acpi-3.20-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI and power management updates from Rafael Wysocki: "We have a few new features this time, including a new SFI-based cpufreq driver, a new devfreq driver for Tegra Activity Monitor, a new devfreq class for providing its governors with raw utilization data and a new ACPI driver for AMD SoCs. Still, the majority of changes here are reworks of existing code to make it more straightforward or to prepare it for implementing new features on top of it. The primary example is the rework of ACPI resources handling from Jiang Liu, Thomas Gleixner and Lv Zheng with support for IOAPIC hotplug implemented on top of it, but there is quite a number of changes of this kind in the cpufreq core, ACPICA, ACPI EC driver, ACPI processor driver and the generic power domains core code too. The most active developer is Viresh Kumar with his cpufreq changes. Specifics: - Rework of the core ACPI resources parsing code to fix issues in it and make using resource offsets more convenient and consolidation of some resource-handing code in a couple of places that have grown analagous data structures and code to cover the the same gap in the core (Jiang Liu, Thomas Gleixner, Lv Zheng). - ACPI-based IOAPIC hotplug support on top of the resources handling rework (Jiang Liu, Yinghai Lu). - ACPICA update to upstream release 20150204 including an interrupt handling rework that allows drivers to install raw handlers for ACPI GPEs which then become entirely responsible for the given GPE and the ACPICA core code won't touch it (Lv Zheng, David E Box, Octavian Purdila). - ACPI EC driver rework to fix several concurrency issues and other problems related to events handling on top of the ACPICA's new support for raw GPE handlers (Lv Zheng). - New ACPI driver for AMD SoCs analogous to the LPSS (Low-Power Subsystem) driver for Intel chips (Ken Xue). - Two minor fixes of the ACPI LPSS driver (Heikki Krogerus, Jarkko Nikula). - Two new blacklist entries for machines (Samsung 730U3E/740U3E and 510R) where the native backlight interface doesn't work correctly while the ACPI one does (Hans de Goede). - Rework of the ACPI processor driver's handling of idle states to make the code more straightforward and less bloated overall (Rafael J Wysocki). - Assorted minor fixes related to ACPI and SFI (Andreas Ruprecht, Andy Shevchenko, Hanjun Guo, Jan Beulich, Rafael J Wysocki, Yaowei Bai). - PCI core power management modification to avoid resuming (some) runtime-suspended devices during system suspend if they are in the right states already (Rafael J Wysocki). - New SFI-based cpufreq driver for Intel platforms using SFI (Srinidhi Kasagar). - cpufreq core fixes, cleanups and simplifications (Viresh Kumar, Doug Anderson, Wolfram Sang). - SkyLake CPU support and other updates for the intel_pstate driver (Kristen Carlson Accardi, Srinivas Pandruvada). - cpufreq-dt driver cleanup (Markus Elfring). - Init fix for the ARM big.LITTLE cpuidle driver (Sudeep Holla). - Generic power domains core code fixes and cleanups (Ulf Hansson). - Operating Performance Points (OPP) core code cleanups and kernel documentation update (Nishanth Menon). - New dabugfs interface to make the list of PM QoS constraints available to user space (Nishanth Menon). - New devfreq driver for Tegra Activity Monitor (Tomeu Vizoso). - New devfreq class (devfreq_event) to provide raw utilization data to devfreq governors (Chanwoo Choi). - Assorted minor fixes and cleanups related to power management (Andreas Ruprecht, Krzysztof Kozlowski, Rickard Strandqvist, Pavel Machek, Todd E Brandt, Wonhong Kwon). - turbostat updates (Len Brown) and cpupower Makefile improvement (Sriram Raghunathan)" * tag 'pm+acpi-3.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (151 commits) tools/power turbostat: relax dependency on APERF_MSR tools/power turbostat: relax dependency on invariant TSC Merge branch 'pci/host-generic' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci into acpi-resources tools/power turbostat: decode MSR_*_PERF_LIMIT_REASONS tools/power turbostat: relax dependency on root permission ACPI / video: Add disable_native_backlight quirk for Samsung 510R ACPI / PM: Remove unneeded nested #ifdef USB / PM: Remove unneeded #ifdef and associated dead code intel_pstate: provide option to only use intel_pstate with HWP ACPI / EC: Add GPE reference counting debugging messages ACPI / EC: Add query flushing support ACPI / EC: Refine command storm prevention support ACPI / EC: Add command flushing support. ACPI / EC: Introduce STARTED/STOPPED flags to replace BLOCKED flag ACPI: add AMD ACPI2Platform device support for x86 system ACPI / table: remove duplicate NULL check for the handler of acpi_table_parse() ACPI / EC: Update revision due to raw handler mode. ACPI / EC: Reduce ec_poll() by referencing the last register access timestamp. ACPI / EC: Fix several GPE handling issues by deploying ACPI_GPE_DISPATCH_RAW_HANDLER mode. ACPICA: Events: Enable APIs to allow interrupt/polling adaptive request based GPE handling model ...
2015-02-10Merge branches 'pm-sleep' and 'pm-runtime'Rafael J. Wysocki
* pm-sleep: PM / hibernate: exclude freed pages from allocated pages printout PM / sleep: export suspend_resume trace event PM / sleep: Mention async suspend in PM_TRACE documentation PM / hibernate: Remove unused function * pm-runtime: ACPI / PM: Remove unneeded nested #ifdef USB / PM: Remove unneeded #ifdef and associated dead code
2015-02-10Merge branch 'acpi-resources'Rafael J. Wysocki
* acpi-resources: (23 commits) Merge branch 'pci/host-generic' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci into acpi-resources x86/irq, ACPI: Implement ACPI driver to support IOAPIC hotplug ACPI: Add interfaces to parse IOAPIC ID for IOAPIC hotplug x86/PCI: Refine the way to release PCI IRQ resources x86/PCI/ACPI: Use common ACPI resource interfaces to simplify implementation x86/PCI: Fix the range check for IO resources PCI: Use common resource list management code instead of private implementation resources: Move struct resource_list_entry from ACPI into resource core ACPI: Introduce helper function acpi_dev_filter_resource_type() ACPI: Add field offset to struct resource_list_entry ACPI: Translate resource into master side address for bridge window resources ACPI: Return translation offset when parsing ACPI address space resources ACPI: Enforce stricter checks for address space descriptors ACPI: Set flag IORESOURCE_UNSET for unassigned resources ACPI: Normalize return value of resource parser functions ACPI: Fix a bug in parsing ACPI Memory24 resource ACPI: Add prefetch decoding to the address space parser ACPI: Move the window flag logic to the combined parser ACPI: Unify the parsing of address_space and ext_address_space ACPI: Let the parser return false for disabled resources ...
2015-02-10Merge branch 'acpi-processor'Rafael J. Wysocki
* acpi-processor: ACPI / cpuidle: Common callback routine for entering states ACPI / cpuidle: Merge acpi_idle_enter_c1() and acpi_idle_enter_simple() ACPI / cpuidle: Drop flags.bm_check tests from acpi_idle_enter_bm() ACPI / cpuidle: Clean up white space in a switch statement ACPI / cpuidle: Drop irrelevant comment from acpi_idle_enter_simple() ACPI / cpuidle: Clean up fallback to C1 checks ACPI / cpuidle: Drop unnecessary calls from ->enter callback routines ACPI / cpuidle: Drop unnecessary calls from acpi_idle_do_entry()
2015-02-10Merge branches 'acpi-doc', 'acpi-pm', 'acpi-pcc' and 'acpi-tables'Rafael J. Wysocki
* acpi-doc: MAINTAINERS / ACPI: add the necessary '/' according to entry rules ACPI / Documentation: add a missing '=' * acpi-pm: ACPI / sleep: mark acpi_sleep_dmi_check() __init * acpi-pcc: ACPI / PCC: Use pr_debug() for debug messages in pcc_init() * acpi-tables: ACPI / table: remove duplicate NULL check for the handler of acpi_table_parse()
2015-02-10Merge branches 'acpi-video' and 'acpi-soc'Rafael J. Wysocki
* acpi-video: ACPI / video: Add disable_native_backlight quirk for Samsung 510R ACPI / video: Add disable_native_backlight quirk for Samsung 730U3E/740U3E * acpi-soc: ACPI: add AMD ACPI2Platform device support for x86 system ACPI / LPSS: Remove non-existing clock control from Intel Lynxpoint I2C ACPI / LPSS: check the result of ioremap()
2015-02-10Merge branch 'acpi-ec'Rafael J. Wysocki
* acpi-ec: ACPI / EC: Add GPE reference counting debugging messages ACPI / EC: Add query flushing support ACPI / EC: Refine command storm prevention support ACPI / EC: Add command flushing support. ACPI / EC: Introduce STARTED/STOPPED flags to replace BLOCKED flag ACPI / EC: Update revision due to raw handler mode. ACPI / EC: Reduce ec_poll() by referencing the last register access timestamp. ACPI / EC: Fix several GPE handling issues by deploying ACPI_GPE_DISPATCH_RAW_HANDLER mode. ACPI / EC: Cleanup QR_EC related code ACPI / EC: Fix issues related to the SCI_EVT handling ACPI / EC: Fix a code path that global lock is not held ACPI / EC: Fix returning values in acpi_ec_sync_query() ACPI / EC: Add reference counting for query handlers ACPI / EC: Cleanup transaction wakeup code
2015-02-10Merge branch 'acpica'Rafael J. Wysocki
* acpica: ACPICA: Events: Enable APIs to allow interrupt/polling adaptive request based GPE handling model ACPICA: Events: Introduce acpi_set_gpe()/acpi_finish_gpe() to reduce divergences ACPICA: Events: Introduce ACPI_GPE_DISPATCH_RAW_HANDLER to fix 2 issues for the current GPE APIs ACPICA: Update version to 20150204 ACPICA: Update Copyright headers to 2015 ACPICA: Hardware: Cast GPE enable_mask before storing ACPICA: Events: Cleanup GPE dispatcher type obtaining code ACPICA: Events: Cleanup to move acpi_gbl_global_event_handler invocation out of acpi_ev_gpe_dispatch() ACPICA: Events: Cleanup of resetting the GPE handler to NULL before removing ACPICA: Events: Fix uninitialized variable ACPICA: Events: Remove acpi_ev_valid_gpe_event() due to current restriction ACPICA: Events: Remove duplicated sanity check in acpi_ev_enable_gpe() ACPICA: Events: Back port "ACPICA: Save current masks of enabled GPEs after enable register writes" ACPICA: Resources: Provide common part for struct acpi_resource_address structures. ACPI: Introduce acpi_unload_parent_table() usages in Linux kernel ACPICA: take ACPI_MTX_INTERPRETER in acpi_unload_table_id()
2015-02-10Merge branch 'x86-ras-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 RAS update from Ingo Molnar: "The changes in this cycle were: - allow mmcfg access to APEI error injection handlers - improve MCE error messages - smaller cleanups" * 'x86-ras-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86, mce: Fix sparse errors x86, mce: Improve timeout error messages ACPI, EINJ: Enhance error injection tolerance level
2015-02-08ACPI / video: Add disable_native_backlight quirk for Samsung 510RHans de Goede
Backlight control through the native intel interface does not work properly on the Samsung 510R, where as using the acpi_video interface does work, add a quirk for this. Link: https://bugzilla.redhat.com/show_bug.cgi?id=1186097 Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-08ACPI / PM: Remove unneeded nested #ifdefAndreas Ruprecht
In commit 5de21bb998b8 ("ACPI / PM: Drop CONFIG_PM_RUNTIME from the ACPI core"), all occurrences of CONFIG_PM_RUNTIME were replaced with CONFIG_PM. This created the following structure of #ifdef blocks in the code: [...] #ifdef CONFIG_PM #ifdef CONFIG_PM /* always on / undead */ #ifdef CONFIG_PM_SLEEP [...] #endif #endif [...] #endif This patch removes the inner "#ifdef CONFIG_PM" block as it will always be enabled when the outer block is enabled. This inconsistency was found using the undertaker-checkpatch tool. Signed-off-by: Andreas Ruprecht <rupran@einserver.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-06ACPI / EC: Add GPE reference counting debugging messagesLv Zheng
This patch enhances debugging with the GPE reference count messages added. No functional changes. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-06ACPI / EC: Add query flushing supportLv Zheng
This patch implementes the QR_EC flushing support. Grace periods are implemented from the detection of an SCI_EVT to the submission/completion of the QR_EC transaction. During this period, all EC command transactions are allowed to be submitted. Note that query periods and event periods are intentionally distiguished to allow further improvements. 1. Query period: from the detection of an SCI_EVT to the sumission of the QR_EC command. This period is used for storming prevention, as currently QR_EC is deferred to a work queue rather than directly issued from the IRQ context even there is no other transactions pending, so malicous SCI_EVT GPE can act like "level triggered" to trigger a GPE storm. We need to be prepared for this. And in the future, we may change it to be a part of the advance_transaction() where we will try QR_EC submission in appropriate positions to avoid such GPE storming. 2. Event period: from the detection of an SCI_EVT to the completion of the QR_EC command. We may extend it to the completion of _Qxx evaluation. This is actually a grace period for event flushing, but we only flush queries due to the reason stated in known issue 1. That's also why we use EC_FLAGS_EVENT_xxx. During this period, QR_EC transactions need to pass the flushable submission check. In this patch, the following flags are implemented: 1. EC_FLAGS_EVENT_ENABLED: this is derived from the old EC_FLAGS_QUERY_PENDING flag which can block SCI_EVT handlings. With this flag, the logics implemented by the original flag are extended: 1. Old logic: unless both of the flags are set, the event poller will not be scheduled, and 2. New logic: as soon as both of the flags are set, the evet poller will be scheduled. 2. EC_FLAGS_EVENT_DETECTED: this is also derived from the old EC_FLAGS_QUERY_PENDING flag which can block SCI_EVT detection. It thus can be used to indicate the storming prevention period for query submission. acpi_ec_submit_request()/acpi_ec_complete_request() are invoked to implement this period so that acpi_set_gpe() can be invoked under the "reference count > 0" condition. 3. EC_FLAGS_EVENT_PENDING: this is newly added to indicate the grace period for event flushing (query flushing for now). acpi_ec_submit_request()/acpi_ec_complete_request() are invoked to implement this period so that the flushing process can wait until the event handling (query transaction for now) to be completed. Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611 Link: https://bugzilla.kernel.org/show_bug.cgi?id=77431 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Tested-by: Ortwin Glück <odi@odi.ch> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-06ACPI / EC: Refine command storm prevention supportLv Zheng
This patch refines EC command storm prevention support. Current command storming code is wrong, when the storming condition is detected, it only flags the condition without doing anything for the current command but performing storming prevention for the follow-up commands. So: 1. The first command which suffers from the storming still suffers from storming. 2. The follow-up commands which may not suffer from the storming are unconditionally forced into the storming prevention mode. Ideally, we should only enable storm prevention immediately after detection for the current command so that the next command can try the power/performance efficient interrupt mode again. This patch improves the command storm prevention by disabling GPE right after the detection and re-enabling it right before completing the command transaction using the GPE storming prevention APIs. This thus deploys the following GPE handling model: 1. acpi_enable_gpe()/acpi_disable_gpe() for reference count changes: This set of APIs are used for EC usage reference counting. 2. acpi_set_gpe(ACPI_GPE_ENABLE)/acpi_set_gpe(ACPI_GPE_DISABLE): This set of APIs are used for preventing GPE storm. They must be invoked when the reference count > 0. Note that as the storming prevention should always happen when there is an outstanding request, or GPE enabling value will be messed up by the races. This patch also adds BUG_ON() to enforces this rule to prevent future bugs. The msleep(1) used after completing a transaction is useless now as this sounds like a guard time only useful for platforms that need the EC_FLAGS_MSI quirks while we have fixed GPE race issues using the previous raw handler mode enabling. It is kept to avoid regressions. A seperate patch which deletes EC_FLAGS_MSI quirks should take care of deleting it. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-06ACPI / EC: Add command flushing support.Lv Zheng
This patch implements the EC command flushing support. During the grace period indicated by EC_FLAGS_STARTED and EC_FLAGS_STOPPED, all submitted EC command transactions can be completed and new submissions are prevented before suspending so that the EC hardware can be ensured to be in the idle state when the system is resumed. There is a good indicator for flush support: All acpi_ec_submit_request() is invoked after checking driver state with acpi_ec_started() except the first one. This means all code paths can be flushed as fast as possible by discarding the requests occurred after the flush operation. The reference increased for such kind of code path is wrapped by acpi_ec_submit_flushable_request(). Signed-off-by: Lv Zheng <lv.zheng@intel.com> Tested-by: Ortwin Glück <odi@odi.ch> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-06ACPI / EC: Introduce STARTED/STOPPED flags to replace BLOCKED flagLv Zheng
By using the 2 flags, we can indicate an inter-mediate state where the current transactions should be completed while the new transactions should be dropped. The comparison of the old flag and the new flags: Old New about to set BLOCKED STOPPED set / STARTED set BLOCKED set STOPPED clear / STARTED clear BLOCKED clear STOPPED clear / STARTED set A new period can be indicated by the 2 flags. The new period is between the point where we are about to set BLOCKED and the point when the BLOCKED is set. The new flags facilitate us with acpi_ec_started() check to allow the EC transaction to be submitted during the new period. This period thus can be used as a grace period for the EC transaction flushing. The only functional change after applying this patch is: 1. The GPE enabling/disabling is protected by the EC specific lock. We can do this because of recent ACPICA GPE API enhancement. This is reasonable as the GPE disabling/enabling state should only be determined by the EC driver's state machine which is protected by the EC spinlock. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Tested-by: Ortwin Glück <odi@odi.ch> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-06ACPI: add AMD ACPI2Platform device support for x86 systemKen Xue
This new feature is to interpret AMD specific ACPI device to platform device such as I2C, UART, GPIO found on AMD CZ and later chipsets. It based on example intel LPSS. Now, it can support AMD I2C, UART and GPIO. Signed-off-by: Ken Xue <Ken.Xue@amd.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-06Merge back earlier 'acpi-lpss' material for v3.20Rafael J. Wysocki
2015-02-06ACPI / table: remove duplicate NULL check for the handler of acpi_table_parse()Hanjun Guo
In acpi_table_parse(), pointer of the table to pass to handler() is checked before handler() called, so remove all the duplicate NULL check in the handler function. CC: Tony Luck <tony.luck@intel.com> CC: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-05Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller
Conflicts: drivers/net/vxlan.c drivers/vhost/net.c include/linux/if_vlan.h net/core/dev.c The net/core/dev.c conflict was the overlap of one commit marking an existing function static whilst another was adding a new function. In the include/linux/if_vlan.h case, the type used for a local variable was changed in 'net', whereas the function got rewritten to fix a stacked vlan bug in 'net-next'. In drivers/vhost/net.c, Al Viro's iov_iter conversions in 'net-next' overlapped with an endainness fix for VHOST 1.0 in 'net'. In drivers/net/vxlan.c, vxlan_find_vni() added a 'flags' parameter in 'net-next' whereas in 'net' there was a bug fix to pass in the correct network namespace pointer in calls to this function. Signed-off-by: David S. Miller <davem@davemloft.net>
2015-02-05ACPI / EC: Update revision due to raw handler mode.Lv Zheng
The bug fixes around GPE races have been done to the EC driver by the previous commits. This patch increases the revision to 3 to indicate the behavior differences between the old and the new drivers. The copyright/authorship notices are also updated. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-05ACPI / EC: Reduce ec_poll() by referencing the last register access timestamp.Lv Zheng
Timeout in the ec_poll() doesn't refer to the last register access time. It thus can win the competition against the acpi_ec_gpe_handler() if a transaction takes longer than 1ms but individual register accesses are less than 1ms. In some cases, it can make the following silicon bug easier to be triggered: GPE EN is not wired to the GPE trigger line, so when GPE STS is already set when 1 is written to GPE EN, no GPE can be triggered. This patch adds register access timestamp reference support for ec_poll() to reduce the number of ec_poll() invocations. Reported-by: Venkat Raghavulu <venkat.raghavulu@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-05ACPI / EC: Fix several GPE handling issues by deploying ↵Lv Zheng
ACPI_GPE_DISPATCH_RAW_HANDLER mode. This patch switches EC driver into ACPI_GPE_DISPATCH_RAW_HANDLER mode where the GPE lock is not held for acpi_ec_gpe_handler() and the ACPICA internal GPE enabling/disabling/clearing operations are bypassed so that further improvements are possible with the GPE APIs. There are 2 strong reasons for deploying raw GPE handler mode in the EC driver: 1. Some hardware logics can control their interrupts via their own registers, so their interrupts can be disabled/enabled/acknowledged without using the super IRQ controller provided functions. While there is no mean (EC commands) for the EC driver to achieve this. 2. During suspending, the EC driver is still working for a while to complete the platform firmware provided functionailities using ec_poll() after all GPEs are disabled (see acpi_ec_block_transactions()), which means the EC driver will drive the EC GPE out of the GPE core's control. Without deploying the raw GPE handler mode, we can see many races between the EC driver and the GPE core due to the above restrictions: 1. There is a race condition due to ACPICA internal GPE disabling/clearing/enabling logics in acpi_ev_gpe_dispatch(): Orignally EC GPE is disabled (EN=0), cleared (STS=0) before invoking a GPE handler and re-enabled (EN=1) after invoking a GPE handler in acpi_ev_gpe_dispatch(). When re-enabling appears, GPE may be flagged (STS=1). ================================================================= (event pending A) ================================================================= acpi_ev_gpe_dispatch() ec_poll() EN=0 STS=0 acpi_ec_gpe_handler() ***************************************************************** (event handling A) Lock(EC) advance_transaction() EC_SC read ================================================================= (event pending B) ================================================================= EC_SC handled Unlock(EC) ***************************************************************** ***************************************************************** (event handling B) Lock(EC) advance_transaction() EC_SC read ================================================================= (event pending C) ================================================================= EC_SC handled Unlock(EC) ***************************************************************** EN=1 This race condition is the root cause of different issues on different silicon variations. A. Silicon variation A: On some platforms, GPE will be triggered due to "writing 1 to EN when STS=1". This is because both EN and STS lines are wired to the GPE trigger line. 1. Issue 1: We can see no-op acpi_ec_gpe_handler() invoked on such platforms. This is because: a. event pending B: An event can arrive after ACPICA's GPE clearing performed in acpi_ev_gpe_dispatch(), this event may fail to be detected by EC_SC read that is performed before its arrival; b. event handling B: The event can be handled in ec_poll() because EC lock is released after acpi_ec_gpe_handler() invocation; c. There is no code in ec_poll() to clear STS but the GPE can still be triggered by the EN=1 write performed in acpi_ev_finish_gpe(), this leads to a no-op EC GPE handler invocation; d. As no-op GPE handler invocations are counted by the EC driver to trigger the command storming conditions, the wrong no-op GPE handler invocations thus can easily trigger wrong command storming conditions. Note 1: If we removed GPE disabling/enabling code from acpi_ev_gpe_dispatch(), we could still see no-op GPE handlers triggered by the event arriving after the GPE clearing and before the GPE handling on both silicon variation A and B. This can only occur if the CPU is very slow (timing slice between STS=0 write and EC_SC read should be short enough before hardware sets another GPE indication). Thus this is very rare and is not what we need to fix. B. Silicon variation B: On other platforms, GPE may not be triggered due to "writing 1 to EN when STS=1". This is because only STS line is wired to the GPE trigger line. 2. Issue 2: We can see GPE loss on such platforms. This is because: a. event pending B vs. event handling A: An event can arrive after ACPICA's GPE handling performed in acpi_ev_gpe_dispatch(), or event pending C vs. event handling B: An event can arrive after Linux's GPE handling performed in ec_poll(), these events may fail to be detected by EC_SC read that is performed before their arrival; b. The GPE cannot be triggered by EN=1 write performed in acpi_ev_finish_gpe(); c. If no polling mechanism is implemented in the driver for the pending event (for example, SCI_EVT), this event is lost due to no GPE being triggered. Note 2: On most platforms, there might be another rule that GPE may not be triggered due to "writing 1 to STS when STS=1 and EN=1". Then on silicon variation B, an even worse case is if the issue 2 event loss happens, further events may never trigger GPE again on such platforms due to being blocked by the current STS=1. Unless someone clears STS, all events have to be polled. 2. There is a race condition due to lacking in GPE status checking in EC driver: Originally, GPE status is checked in ACPICA core but not checked in the GPE handler. Thus since the status checking and handling is not locked, it can be interrupted by another handling path. ================================================================= (event pending A) ================================================================= acpi_ev_gpe_detect() ec_poll() if (EN==1 && STS==1) ***************************************************************** (event handling A) Lock(EC) advance_transaction() EC_SC read EC_SC handled Unlock(EC) ***************************************************************** acpi_ev_gpe_dispatch() EN=0 STS=0 acpi_ec_gpe_handler() ***************************************************************** (event handling B) Lock(EC) advance_transaction() EC_SC read Unlock(EC) ***************************************************************** 3. Issue 3: We can see no-op acpi_ec_gpe_handler() invoked on both silicon variation A and B. This is because: a. event pending A: An event can arrive to trigger an EC GPE and ACPICA checks it and is about to invoke the EC GPE handler; b. event handling A: The event can be handled in ec_poll() because EC lock is not held after the GPE status checking; c. event handling B: Then when the EC GPE handler is invoked, it becomes a no-op GPE handler invocation. d. As no-op GPE handler invocations are counted by the EC driver to trigger the command storming conditions, the wrong no-op GPE handler invocations thus can easily trigger wrong command storming conditions. Note 3: This no-op GPE handler invocation is rare because the time between the IRQ arrival and the acpi_ec_gpe_handler() invocation is less than the timeout value waited in ec_poll(). So most of the no-op GPE handler invocations are caused by the reason described in issue 1. 3. There is a race condition due to ACPICA internal GPE clearing logic in acpi_enable_gpe(): During runtime, acpi_enable_gpe() can be invoked by the EC storming prevention code. When it is invoked, GPE may be flagged (STS=1). ================================================================= (event pending A) ================================================================= acpi_ev_gpe_dispatch() acpi_ec_transaction() EN=0 STS=0 acpi_ec_gpe_handler() ***************************************************************** (event handling A) Lock(EC) advance_transaction() EC_SC read EC_SC handled Unlock(EC) ***************************************************************** EN=1 ? Lock(EC) Unlock(EC) ================================================================= (event pending B) ================================================================= acpi_enable_gpe() STS=0 EN=1 4. Issue 4: We can see GPE loss on both silicon variation A and B platforms. This is because: a. event pending B: An event can arrive right before ACPICA's GPE clearing performed in acpi_enable_gpe(); b. If the GPE is cleared when GPE is disabled, then EN=1 write in acpi_enable_gpe() cannot trigger this GPE; c. If no polling mechanism is implemented in the driver for this event (for example, SCI_EVT), this event is lost due to no GPE being triggered. Note 4: Currently we don't have this issue, but after we switch the EC driver into ACPI_GPE_DISPATCH_RAW_HANDLER mode, we need to take care of handling this because the EN=1 write in acpi_ev_gpe_dispatch() will be abandoned. There might be more race issues for the current GPE handler usages. This is because the EC IRQ's enabling/disabling/checking/clearing/handling operations should be locked by a single lock that is under the EC driver's control to achieve the serialization. Which means we need to invoke GPE APIs with EC driver's lock held and all ACPICA internal GPE operations related to the GPE handler should be abandoned. Invoking GPE APIs inside of the EC driver lock and bypassing ACPICA internal GPE operations requires the ACPI_GPE_DISPATCH_RAW_HANDLER mode where the same lock used by the APIs are released prior than invoking the handlers. Otherwise, we can see dead locks due to circular locking dependencies (see Reference below). This patch then switches the EC driver into the ACPI_GPE_DISPATCH_RAW_HANDLER mode so that it can perform correct GPE operations using the GPE APIs: 1. Bypasses EN modifications performed in acpi_ev_gpe_dispatch() by using acpi_install_gpe_raw_handler() and invoking all GPE APIs with EC spin lock held. This can fix issue 1 as it makes a non frequent GPE enabling/disabling environment. 2. Bypasses STS clearing performed in acpi_enable_gpe() by replacing acpi_enable_gpe()/acpi_disable_gpe() with acpi_set_gpe(). This can fix issue 4. And this can also help to fix issue 1 as it makes a no sudden GPE clearing environment when GPE is frequently enabled/disabled. 3. Ensures STS acknowledged before handling by invoking acpi_clear_gpe() in advance_transaction(). This can finally fix issue 1 even in a frequent GPE enabling/disabling environment. And this can also finally fix issue 3 when issue 2 is fixed. Note 3: GPE clearing is edge triggered W1C, which means we can clear it right before handling it. Since all EC GPE indications are handled in advance_transaction() by previous commits, we can now move GPE clearing into it to implement the correct GPE clearing. Note 4: We can use acpi_set_gpe() which is not shared GPE safer instead of acpi_enable_gpe()/acpi_disable_gpe() because EC GPE is not shared by other hardware, which is mentioned in the ACPI specification 5.0, 12.6 Interrupt Model: "OSPM driver treats this as an edge event (the EC SCI cannot be shared)". So we can stop using shared GPE safer APIs acpi_enable_gpe()/acpi_disable_gpe() in the EC driver. Otherwise cleanups need to be made in acpi_ev_enable_gpe() to bypass the GPE clearing logic before keeping acpi_enable_gpe(). This patch also invokes advance_transaction() when GPE is re-enabled in the task context which: 1. Ensures EN=1 can trigger GPE by checking and handling EC status register right after EN=1 writes. This can fix issue 2. After applying this patch, without frequent GPE enablings considered: ================================================================= (event pending A) ================================================================= acpi_ec_gpe_handler() ec_poll() ***************************************************************** (event handling A) Lock(EC) advance_transaction() if STS==1 STS=0 EC_SC read ================================================================= (event pending B) ================================================================= EC_SC handled Unlock(EC) ***************************************************************** ***************************************************************** (event handling B) Lock(EC) advance_transaction() if STS==1 STS=0 EC_SC read ================================================================= (event pending C) ================================================================= EC_SC handled Unlock(EC) ***************************************************************** The event pending for issue 1 (event pending B) can arrive as a next GPE due to the previous IRQ context STS=0 write. And if it is handled by ec_poll() (event handling B), as it is also acknowledged by ec_poll(), the event pending for issue 2 (event pending C) can properly arrive as a next GPE after the task context STS=0 write. So no GPE will be lost and never triggered due to GPE clearing performed in the wrong position. And since all GPE handling is performed after a locked GPE status checking, we can hardly see no-op GPE handler invocations due to issue 1 and 3. We may still see no-op GPE handler invocations due to "Note 1", but as it is inevitable, it needn't be fixed. After applying this patch, with frequent GPE enablings considered: ================================================================= (event pending A) ================================================================= acpi_ec_gpe_handler() acpi_ec_transaction() ***************************************************************** (event handling A) Lock(EC) advance_transaction() if STS==1 STS=0 EC_SC read ================================================================= (event pending B) ================================================================= EC_SC handled Unlock(EC) ***************************************************************** ***************************************************************** (event handling B) Lock(EC) EN=1 if STS==1 advance_transaction() if STS==1 STS=0 EC_SC read ================================================================= (event pending C) ================================================================= EC_SC handled Unlock(EC) ***************************************************************** The event pending for issue 2 can be manually handled by advance_transaction(). And after the STS=0 write performed in the manual triggered advance_transaction(), GPE can always arrive. So no GPE will be lost due to frequent GPE disabling/enabling performed in the driver like issue 4. Note 5: It's ideally when EN=1 write occurred, an IRQ thread should be woken up to handle the GPE when the GPE was raised. But this requires the IRQ thread to contain the poller code for all EC GPE indications, while currently some of the indications are handled in the user tasks. It then is very hard for the code to determine whether a user task should be invoked or the poller work item should be scheduled. So we have to invoke advance_transaction() directly now and it leaves us such a restriction for the GPE re-enabling: it must be performed in the task context to avoid starving the GPEs. As a conclusion: we can see the EC GPE is always handled in serial after deploying the raw GPE handler mode: Lock(EC) if (STS==1) STS=0 EC_SC read EC_SC handled Unlock(EC) The EC driver specific lock is responsible to make the EC GPE handling processes serialized so that EC can handle its GPE from both IRQ and task contexts and the next IRQ can be ensured to arrive after this process. Note 6: We have many EC_FLAGS_MSI qurik users in the current driver. They all seem to be suffering from unexpected GPE triggering source lost. And they are false root caused to a timing issue. Since EC communication protocol has already flow control defined, timing shouldn't be the root cause, while this fix might be fixing the root cause of the old bugs. Link: https://lkml.org/lkml/2014/11/4/974 Link: https://lkml.org/lkml/2014/11/18/316 Link: https://www.spinics.net/lists/linux-acpi/msg54340.html Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-05Merge branch 'acpica' into acpi-ecRafael J. Wysocki
2015-02-05ACPICA: Events: Enable APIs to allow interrupt/polling adaptive request ↵Lv Zheng
based GPE handling model ACPICA commit da9a83e1a845f2d7332bdbc0632466b2595e5424 For acpi_set_gpe()/acpi_enable_gpe(), our target is to purify them to be APIs that can be used for various GPE handling models, so we need them to be pure GPE enabling APIs. GPE enabling/disabling has 2 use cases: 1. Driver may permanently enable/disable GPEs according to the usage counts. 1. When upper layers (the users of the driver) submit requests to the driver, it means they care about the underlying hardware. GPE need to be enabled for the first request submission and disabled for the last request completion. 2. When the GPE is shared between 2+ silicon logics. GPE need to be enabled for either silicon logic's driver and disabled when all of the drivers are not started. For these cases, acpi_enable_gpe()/acpi_disable_gpe() should be used. When the usage count is increased from 0 to 1, the GPE is enabled and it is disabled when the usage count is decrased from 1 to 0. 2. Driver may temporarily disables the GPE to enter an GPE polling mode and wants to re-enable it later. 1. Prevent GPE storming: when a driver cannot fully solve the condition that triggered the GPE in the GPE context, in order not to trigger GPE storm, driver has to disable GPE to switch into the polling mode and re-enables it in the non interrupt context after the storming condition is cleared. 2. Meet throughput requirement: some IO drivers need to poll hardware again and again until nothing indicated instead of just handling once for one interruption, this need to be done in the polling mode or the IO flood may prevent the GPE handler from returning. 3. Meet realtime requirement: in order not to block CPU to handle higher realtime prioritized GPEs, lower priority GPEs can be handled in the polling mode. For these cases, acpi_set_gpe() should be used to switch to/from the polling mode. This patch adds unconditional GPE enabling support into acpi_set_gpe() so that this API can be used by the drivers to switch back from the GPE polling mode unconditionally. Originally this function includes GPE clearing logic in it. First, the GPE clearing is typically used in the GPE handling code to: 1. Acknowledge the GPE when we know there is an edge triggered GPE raised and is about to handle it, otherwise the unexpected clearing may lead to a GPE loss; 2. Issue actions after we have handled a level triggered GPE, otherwise the unexpected clearing may trigger unwanted OSPM actions to the hardware (for example, clocking in out-dated write FIFO data). Thus the GPE clearing is not suitable to be used in the GPE enabling APIs. Second, the combination of acknowledging and enabling may also not be expected by the hardware drivers. For GPE clearing, we have a seperate API acpi_clear_gpe(). There are cases drivers do want the 2 operations to be split. So splitting these 2 operations could facilitates drivers the maximum possibilities to achieve success. For a combined one, we already have acpi_finish_gpe() ready to be invoked. Given the fact that drivers should complete all outstanding requests before putting themselves into the sleep states, as this API is executed for outstanding requests, it should also have nothing to do with the "RUN"/"WAKE" distinguishing. That's why the acpi_set_gpe(ACPI_GPE_ENABLE) should not be implemented by acpi_hw_low_set_gpe(ACPI_GPE_CONDITIONAL_ENABLE). This patch thus converts acpi_set_gpe(ACPI_GPE_ENABLE) into acpi_hw_low_set_gpe(ACPI_GPE_ENABLE) to achieve a seperate GPE enabling API. Drivers then are encouraged to use this API when they need to switch to/from the GPE polling mode. Note that the acpi_set_gpe()/acpi_finish_gpe() should be first introduced to Linux using a divergence reduction patch before sending a linuxized version of this patch. Lv Zheng. Link: https://github.com/acpica/acpica/commit/da9a83e1 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-05ACPICA: Events: Introduce acpi_set_gpe()/acpi_finish_gpe() to reduce divergencesLv Zheng
This can help to reduce source code differences between Linux and ACPICA upstream. Further driver cleanups also require these APIs to eliminate GPE storms. 1. acpi_set_gpe(): An API that driver should invoke in the case it wants to disable/enable IRQ without honoring the reference count implemented in the acpi_disable_gpe() and acpi_enable_gpe(). Note that this API should only be invoked inside a acpi_enable_gpe()/acpi_disable_gpe() pair. 2. acpi_finish_gpe(): Drivers returned ACPI_REENABLE_GPE unset from the GPE handler should use this API instead of invoking acpi_set_gpe()/acpi_enable_gpe() to re-enable the GPE. The GPE APIs can be invoked inside of a GPE handler or in the task context with a driver provided lock held. This driver provided lock is safe to be held in the GPE handler by the driver. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-05ACPICA: Events: Introduce ACPI_GPE_DISPATCH_RAW_HANDLER to fix 2 issues for ↵Lv Zheng
the current GPE APIs ACPICA commit 199cad16530a45aea2bec98e528866e20c5927e1 Since whether the GPE should be disabled/enabled/cleared should only be determined by the GPE driver's state machine: 1. GPE should be disabled if the driver wants to switch to the GPE polling mode when a GPE storm condition is indicated and should be enabled if the driver wants to switch back to the GPE interrupt mode when all of the storm conditions are cleared. The conditions should be protected by the driver's specific lock. 2. GPE should be enabled if the driver has accepted more than one request and should be disabled if the driver has completed all of the requests. The request count should be protected by the driver's specific lock. 3. GPE should be cleared either when the driver is about to handle an edge triggered GPE or when the driver has completed to handle a level triggered GPE. The handling code should be protected by the driver's specific lock. Thus the GPE enabling/disabling/clearing operations are likely to be performed with the driver's specific lock held while we currently cannot do this. This is because: 1. We have the acpi_gbl_gpe_lock held before invoking the GPE driver's handler. Driver's specific lock is likely to be held inside of the handler, thus we can see some dead lock issues due to the reversed locking order or recursive locking. In order to solve such dead lock issues, we need to unlock the acpi_gbl_gpe_lock before invoking the handler. BZ 1100. 2. Since GPE disabling/enabling/clearing should be determined by the GPE driver's state machine, we shouldn't perform such operations inside of ACPICA for a GPE handler to mess up the driver's state machine. BZ 1101. Originally this patch includes a logic to flush GPE handlers, it is dropped due to the following reasons: 1. This is a different issue; 2. Linux OSL has fixed this by flushing SCI in acpi_os_wait_events_complete(). We will pick up this topic when the Linux OSL fix turns out to be not sufficient. Note that currently the internal operations and the acpi_gbl_gpe_lock are also used by ACPI_GPE_DISPATCH_METHOD and ACPI_GPE_DISPATCH_NOTIFY. In order not to introduce regressions, we add one ACPI_GPE_DISPATCH_RAW_HANDLER type to be distiguished from ACPI_GPE_DISPATCH_HANDLER. For which the acpi_gbl_gpe_lock is unlocked before invoking the GPE handler and the internal enabling/disabling operations are bypassed to allow drivers to perform them at a proper position using the GPE APIs and ACPI_GPE_DISPATCH_RAW_HANDLER users should invoke acpi_set_gpe() instead of acpi_enable_gpe()/acpi_disable_gpe() to bypass the internal GPE clearing code in acpi_enable_gpe(). Lv Zheng. Known issues: 1. Edge-triggered GPE lost for frequent enablings On some buggy silicon platforms, GPE enable line may not be directly wired to the GPE trigger line. In that case, when GPE enabling is frequently performed for edge-triggered GPEs, GPE status may stay set without being triggered. This patch may maginify this problem as it allows GPE enabling to be parallel performed during the process the GPEs are handled. This is an existing issue, because: 1. For task context: Current ACPI_GPE_DISPATCH_METHOD practices have proven that this isn't a real issue - we can re-enable edge-triggered GPE in a work queue where the GPE status bit might already be set. 2. For IRQ context: This can even happen when the GPE enabling occurs before returning from the GPE handler and after unlocking the GPE lock. Thus currently no code is included to protect this. Link: https://github.com/acpica/acpica/commit/199cad16 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-02-05ACPICA: Update Copyright headers to 2015David E. Box
ACPICA commit 8990e73ab2aa15d6a0068b860ab54feff25bee36 Link: https://github.com/acpica/acpica/commit/8990e73a Signed-off-by: David E. Box <david.e.box@linux.intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>