summaryrefslogtreecommitdiff
path: root/drivers/acpi/acpi_lpss.c
AgeCommit message (Collapse)Author
2020-04-24PM: sleep: core: Rename dev_pm_smart_suspend_and_suspended()Rafael J. Wysocki
Because all callers of dev_pm_smart_suspend_and_suspended use it only for checking whether or not to skip driver suspend callbacks for a device, rename it to dev_pm_skip_suspend() in analogy with dev_pm_skip_resume(). No functional impact. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2020-04-24PM: sleep: core: Rename dev_pm_may_skip_resume()Rafael J. Wysocki
The name of dev_pm_may_skip_resume() may be easily confused with the power.may_skip_resume flag which is not checked by that function, so rename the former as dev_pm_skip_resume(). No functional impact. Suggested-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2020-04-24PM: sleep: core: Do not skip callbacks in the resume phaseRafael J. Wysocki
The current code in device_resume_noirq() causes the entire early resume and resume phases of device suspend to be skipped for devices for which the noirq resume phase have been skipped (due to the LEAVE_SUSPENDED flag being set) on the premise that those devices should stay in runtime-suspend after system-wide resume. However, that may not be correct in two situations. First, the middle layer (subsystem) noirq resume callback may be missing for a given device, but its early resume callback may be present and it may need to do something even if it decides to skip the driver callback. Second, if the device's wakeup settings were adjusted in the suspend phase without resuming the device (that was in runtime suspend at that time), they most likely need to be adjusted again in the resume phase and so the driver callback in that phase needs to be run. For the above reason, modify the core to allow the middle layer ->resume_late callback to run even if its ->resume_noirq callback is missing (and the core has skipped the driver-level callback in that phase) and to allow all device callbacks to run in the resume phase. Also make the core set the PM-runtime status of devices with SMART_SUSPEND set whose resume callbacks are not skipped to "active" in the "noirq" resume phase and update the affected subsystems (PCI and ACPI) accordingly. After this change, middle-layer (subsystem) callbacks will always be invoked in all phases of system suspend and resume and driver callbacks will always run in the prepare, suspend, resume, and complete phases for all devices. For devices with SMART_SUSPEND set, driver callbacks will be skipped in the late and noirq phases of system suspend if those devices remain in runtime suspend in __device_suspend_late(). Driver callbacks will also be skipped for them during the noirq and early phases of the "thaw" transition related to hibernation in that case. Setting LEAVE_SUSPENDED means that the driver allows its callbacks to be skipped in the noirq and early phases of system resume, but some additional conditions need to be met for that to happen (among other things, the power.may_skip_resume flag needs to be set for the device during system suspend for the driver callbacks to be skipped during the subsequent resume transition). For all devices with SMART_SUSPEND set whose driver callbacks are invoked during system resume, the PM-runtime status will be set to "active" (by the core). Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Bjorn Helgaas <bhelgaas@google.com>
2020-03-24ACPI: Convert to new X86 CPU match macrosThomas Gleixner
The new macro set has a consistent namespace and uses C99 initializers instead of the grufty C89 ones. Rename the local macro wrapper to X86_MATCH for consistency. It stays for readability sake. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lkml.kernel.org/r/20200320131509.467730627@linutronix.de
2019-12-17ACPI / LPSS: Rename pwm_backlight pwm-lookup to pwm_soc_backlightHans de Goede
At least Bay Trail (BYT) and Cherry Trail (CHT) devices can use 1 of 2 different PWM controllers for controlling the LCD's backlight brightness. Either the one integrated into the PMIC or the one integrated into the SoC (the 1st LPSS PWM controller). So far in the LPSS code on BYT we have skipped registering the LPSS PWM controller "pwm_backlight" lookup entry when a Crystal Cove PMIC is present, assuming that in this case the PMIC PWM controller will be used. On CHT we have been relying on only 1 of the 2 PWM controllers being enabled in the DSDT at the same time; and always registered the lookup. So far this has been working, but the correct way to determine which PWM controller needs to be used is by checking a bit in the VBT table and recently I've learned about 2 different BYT devices: Point of View MOBII TAB-P800W Acer Switch 10 SW5-012 Which use a Crystal Cove PMIC, yet the LCD is connected to the SoC/LPSS PWM controller (and the VBT correctly indicates this), so here our old heuristics fail. Since only the i915 driver has access to the VBT, this commit renames the "pwm_backlight" lookup entries for the 1st BYT/CHT LPSS PWM controller to "pwm_soc_backlight" so that the i915 driver can do a pwm_get() for the right controller depending on the VBT bit, instead of the i915 driver relying on a "pwm_backlight" lookup getting registered which magically points to the right controller. Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191216202906.1662893-2-hdegoede@redhat.com
2019-11-26Merge branches 'acpi-utils', 'acpi-platform', 'acpi-video' and 'acpi-doc'Rafael J. Wysocki
* acpi-utils: iommu/amd: Switch to use acpi_dev_hid_uid_match() mmc: sdhci-acpi: Switch to use acpi_dev_hid_uid_match() ACPI / LPSS: Switch to use acpi_dev_hid_uid_match() ACPI / utils: Introduce acpi_dev_hid_uid_match() helper ACPI / utils: Move acpi_dev_get_first_match_dev() under CONFIG_ACPI ACPI / utils: Describe function parameters in kernel-doc * acpi-platform: ACPI: platform: Unregister stale platform devices ACPI: Always build evged in * acpi-video: ACPI: video: update doc for acpi_video_bus_DOS() * acpi-doc: ACPI: Documentation: Minor spelling fix in namespace.rst
2019-10-25ACPI: LPSS: Add dmi quirk for skipping _DEP check for some device-linksHans de Goede
The iGPU / GFX0 device's _PS0 method on the ASUS T200TA depends on the I2C1 controller (which is connected to the embedded controller). But unlike in the T100TA/T100CHI this dependency is not listed in the _DEP of the GFX0 device. This results in the dev_WARN_ONCE(..., "Transfer while suspended\n") call in i2c-designware-master.c triggering and the AML code not working as it should. This commit fixes this by adding a dmi based quirk mechanism for devices which miss a _DEP, and adding a quirk for the LNXVIDEO depending on the I2C1 device on the Asus T200TA. Fixes: 2d71ee0ce72f ("ACPI / LPSS: Add a device link from the GPU to the BYT I2C5 controller") Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: 4.20+ <stable@vger.kernel.org> # 4.20+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-10-25ACPI: LPSS: Add LNXVIDEO -> BYT I2C1 to lpss_device_linksHans de Goede
Various Asus Bay Trail devices (T100TA, T100CHI, T200TA) have an embedded controller connected to I2C1 and the iGPU (LNXVIDEO) _PS0/_PS3 methods access it, so we need to add a consumer link from LNXVIDEO to I2C1 on these devices to avoid suspend/resume ordering problems. Fixes: 2d71ee0ce72f ("ACPI / LPSS: Add a device link from the GPU to the BYT I2C5 controller") Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: 4.20+ <stable@vger.kernel.org> # 4.20+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-10-25ACPI: LPSS: Add LNXVIDEO -> BYT I2C7 to lpss_device_linksHans de Goede
So far on Bay Trail (BYT) we only have been adding a device_link adding the iGPU (LNXVIDEO) device as consumer for the I2C controller for the PMIC for I2C5, but the PMIC only uses I2C5 on BYT CR (cost reduced) on regular BYT platforms I2C7 is used and we were not adding the device_link sometimes causing resume ordering issues. This commit adds LNXVIDEO -> BYT I2C7 to the lpss_device_links table, fixing this. Fixes: 2d71ee0ce72f ("ACPI / LPSS: Add a device link from the GPU to the BYT I2C5 controller") Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: 4.20+ <stable@vger.kernel.org> # 4.20+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-10-15ACPI / LPSS: Switch to use acpi_dev_hid_uid_match()Andy Shevchenko
Since we have a generic helper, drop custom implementation in the driver. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-08-23ACPI / LPSS: Save/restore LPSS private registers also on LynxpointJarkko Nikula
My assumption in commit b53548f9d9e4 ("spi: pxa2xx: Remove LPSS private register restoring during resume") that Intel Lynxpoint and compatible based chipsets may not need LPSS private registers saving and restoring over suspend/resume cycle turned out to be false on Intel Broadwell. Curtis Malainey sent a patch bringing above change back and reported the LPSS SPI Chip Select control was lost over suspend/resume cycle on Broadwell machine. Instead of reverting above commit lets add LPSS private register saving/restoring also for all LPSS SPI, I2C and UART controllers on Lynxpoint and compatible chipset to make sure context is not lost in case nothing else preserves it like firmware or if LPSS is always on. Fixes: b53548f9d9e4 ("spi: pxa2xx: Remove LPSS private register restoring during resume") Reported-by: Curtis Malainey <cujomalainey@chromium.org> Tested-by: Curtis Malainey <cujomalainey@chromium.org> Cc: 5.0+ <stable@vger.kernel.org> # 5.0+ Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-07-12Merge tag 'driver-core-5.3-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core and debugfs updates from Greg KH: "Here is the "big" driver core and debugfs changes for 5.3-rc1 It's a lot of different patches, all across the tree due to some api changes and lots of debugfs cleanups. Other than the debugfs cleanups, in this set of changes we have: - bus iteration function cleanups - scripts/get_abi.pl tool to display and parse Documentation/ABI entries in a simple way - cleanups to Documenatation/ABI/ entries to make them parse easier due to typos and other minor things - default_attrs use for some ktype users - driver model documentation file conversions to .rst - compressed firmware file loading - deferred probe fixes All of these have been in linux-next for a while, with a bunch of merge issues that Stephen has been patient with me for" * tag 'driver-core-5.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (102 commits) debugfs: make error message a bit more verbose orangefs: fix build warning from debugfs cleanup patch ubifs: fix build warning after debugfs cleanup patch driver: core: Allow subsystems to continue deferring probe drivers: base: cacheinfo: Ensure cpu hotplug work is done before Intel RDT arch_topology: Remove error messages on out-of-memory conditions lib: notifier-error-inject: no need to check return value of debugfs_create functions swiotlb: no need to check return value of debugfs_create functions ceph: no need to check return value of debugfs_create functions sunrpc: no need to check return value of debugfs_create functions ubifs: no need to check return value of debugfs_create functions orangefs: no need to check return value of debugfs_create functions nfsd: no need to check return value of debugfs_create functions lib: 842: no need to check return value of debugfs_create functions debugfs: provide pr_fmt() macro debugfs: log errors when something goes wrong drivers: s390/cio: Fix compilation warning about const qualifiers drivers: Add generic helper to match by of_node driver_find_device: Unify the match function with class_find_device() bus_find_device: Unify the match callback with class_find_device ...
2019-07-08Merge branch 'pm-sleep'Rafael J. Wysocki
* pm-sleep: PM: sleep: Drop dev_pm_skip_next_resume_phases() ACPI: PM: Drop unused function and function header ACPI: PM: Introduce "poweroff" callbacks for ACPI PM domain and LPSS ACPI: PM: Simplify and fix PM domain hibernation callbacks PCI: PM: Simplify bus-level hibernation callbacks PM: ACPI/PCI: Resume all devices during hibernation kernel: power: swap: use kzalloc() instead of kmalloc() followed by memset() PM: sleep: Update struct wakeup_source documentation drivers: base: power: remove wakeup_sources_stats_dentry variable PM: suspend: Rename pm_suspend_via_s2idle() PM: sleep: Show how long dpm_suspend_start() and dpm_suspend_end() take PM: hibernate: powerpc: Expose pfn_is_nosave() prototype
2019-07-03ACPI: PM: Introduce "poweroff" callbacks for ACPI PM domain and LPSSRafael J. Wysocki
In general, it is not correct to call pm_generic_suspend(), pm_generic_suspend_late() and pm_generic_suspend_noirq() during the hibernation's "poweroff" transition, because device drivers may provide special callbacks to be invoked then and the wrappers in question cause system suspend callbacks to be run. Unfortunately, that happens in the ACPI PM domain and ACPI LPSS. To address this potential issue, introduce "poweroff" callbacks for the ACPI PM and LPSS that will use pm_generic_poweroff(), pm_generic_poweroff_late() and pm_generic_poweroff_noirq() as appropriate. Fixes: 05087360fd7a (ACPI / PM: Take SMART_SUSPEND driver flag into account) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2019-07-03ACPI: PM: Simplify and fix PM domain hibernation callbacksRafael J. Wysocki
First, after a previous change causing all runtime-suspended devices in the ACPI PM domain (and ACPI LPSS devices) to be resumed before creating a snapshot image of memory during hibernation, it is not necessary to worry about the case in which them might be left in runtime-suspend any more, so get rid of the code related to that from ACPI PM domain and ACPI LPSS hibernation callbacks. Second, it is not correct to use pm_generic_resume_early() and acpi_subsys_resume_noirq() in hibernation "restore" callbacks (which currently happens in the ACPI PM domain and ACPI LPSS), so introduce proper _restore_late and _restore_noirq callbacks for the ACPI PM domain and ACPI LPSS. Fixes: 05087360fd7a (ACPI / PM: Take SMART_SUSPEND driver flag into account) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2019-06-24bus_find_device: Unify the match callback with class_find_deviceSuzuki K Poulose
There is an arbitrary difference between the prototypes of bus_find_device() and class_find_device() preventing their callers from passing the same pair of data and match() arguments to both of them, which is the const qualifier used in the prototype of class_find_device(). If that qualifier is also used in the bus_find_device() prototype, it will be possible to pass the same match() callback function to both bus_find_device() and class_find_device(), which will allow some optimizations to be made in order to avoid code duplication going forward. Also with that, constify the "data" parameter as it is passed as a const to the match function. For this reason, change the prototype of bus_find_device() to match the prototype of class_find_device() and adjust its callers to use the const qualifier in accordance with the new prototype of it. Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Andreas Noever <andreas.noever@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Corey Minyard <minyard@acm.org> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: David Kershner <david.kershner@unisys.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: David Airlie <airlied@linux.ie> Cc: Felipe Balbi <balbi@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Harald Freudenberger <freude@linux.ibm.com> Cc: Hartmut Knaack <knaack.h@gmx.de> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Jonathan Cameron <jic23@kernel.org> Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: Len Brown <lenb@kernel.org> Cc: Mark Brown <broonie@kernel.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Michael Jamet <michael.jamet@intel.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Peter Oberparleiter <oberpar@linux.ibm.com> Cc: Sebastian Ott <sebott@linux.ibm.com> Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Yehezkel Bernat <YehezkelShB@gmail.com> Cc: rafael@kernel.org Acked-by: Corey Minyard <minyard@acm.org> Acked-by: David Kershner <david.kershner@unisys.com> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Acked-by: Wolfram Sang <wsa@the-dreams.de> # for the I2C parts Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-19treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500Thomas Gleixner
Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-18ACPI / LPSS: Use acpi_lpss_* instead of acpi_subsys_* functions for hibernateHans de Goede
Commit 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from resume_noirq") makes acpi_lpss_{suspend_late,resume_early}() bail early on BYT/CHT as resume_from_noirq is set. This means that on resume from hibernate dw_i2c_plat_resume() doesn't get called by the restore_early callback, acpi_lpss_resume_early(). Instead it should be called by the restore_noirq callback matching how things are done when resume_from_noirq is set and we are doing a regular resume. Change the restore_noirq callback to acpi_lpss_resume_noirq so that dw_i2c_plat_resume() gets properly called when resume_from_noirq is set and we are resuming from hibernate. Likewise also change the poweroff_noirq callback so that dw_i2c_plat_suspend gets called properly. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202139 Fixes: 48402cee6889 ("ACPI / LPSS: Resume BYT/CHT I2C controllers from resume_noirq") Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Cc: 4.20+ <stable@vger.kernel.org> # 4.20+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-02-22clk: x86: Move clk-lpss.h to platform_data/x86Andy Shevchenko
clk-lpss.h is solely x86 related header. Move it to correct folder. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org>
2018-12-12ACPI / LPSS: Ignore acpi_device_fix_up_power() return valueHans de Goede
Ignore acpi_device_fix_up_power() return value. If we return an error we end up with acpi_default_enumeration() still creating a platform- device for the device and we end up with the device still being used but without the special LPSS related handling which is not useful. Specicifically ignoring the error fixes the touchscreen no longer working after a suspend/resume on a Prowise PT301 tablet. This tablet has a broken _PS0 method on the touchscreen's I2C controller, causing acpi_device_fix_up_power() to fail, causing fallback to standard platform-dev handling and specifically causing acpi_lpss_save/restore_ctx to not run. The I2C controllers _PS0 method does actually turn on the device, but then does some more nonsense which fails when run during early boot trying to use I2C opregion handling on another not-yet registered I2C controller. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-10-23Merge branch 'perf-core-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf updates from Ingo Molnar: "The main updates in this cycle were: - Lots of perf tooling changes too voluminous to list (big perf trace and perf stat improvements, lots of libtraceevent reorganization, etc.), so I'll list the authors and refer to the changelog for details: Benjamin Peterson, Jérémie Galarneau, Kim Phillips, Peter Zijlstra, Ravi Bangoria, Sangwon Hong, Sean V Kelley, Steven Rostedt, Thomas Gleixner, Ding Xiang, Eduardo Habkost, Thomas Richter, Andi Kleen, Sanskriti Sharma, Adrian Hunter, Tzvetomir Stoyanov, Arnaldo Carvalho de Melo, Jiri Olsa. ... with the bulk of the changes written by Jiri Olsa, Tzvetomir Stoyanov and Arnaldo Carvalho de Melo. - Continued intel_rdt work with a focus on playing well with perf events. This also imported some non-perf RDT work due to dependencies. (Reinette Chatre) - Implement counter freezing for Arch Perfmon v4 (Skylake and newer). This allows to speed up the PMI handler by avoiding unnecessary MSR writes and make it more accurate. (Andi Kleen) - kprobes cleanups and simplification (Masami Hiramatsu) - Intel Goldmont PMU updates (Kan Liang) - ... plus misc other fixes and updates" * 'perf-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (155 commits) kprobes/x86: Use preempt_enable() in optimized_callback() x86/intel_rdt: Prevent pseudo-locking from using stale pointers kprobes, x86/ptrace.h: Make regs_get_kernel_stack_nth() not fault on bad stack perf/x86/intel: Export mem events only if there's PEBS support x86/cpu: Drop pointless static qualifier in punit_dev_state_show() x86/intel_rdt: Fix initial allocation to consider CDP x86/intel_rdt: CBM overlap should also check for overlap with CDP peer x86/intel_rdt: Introduce utility to obtain CDP peer tools lib traceevent, perf tools: Move struct tep_handler definition in a local header file tools lib traceevent: Separate out tep_strerror() for strerror_r() issues perf python: More portable way to make CFLAGS work with clang perf python: Make clang_has_option() work on Python 3 perf tools: Free temporary 'sys' string in read_event_files() perf tools: Avoid double free in read_event_file() perf tools: Free 'printk' string in parse_ftrace_printk() perf tools: Cleanup trace-event-info 'tdata' leak perf strbuf: Match va_{add,copy} with va_end perf test: S390 does not support watchpoints in test 22 perf auxtrace: Include missing asm/bitsperlong.h to get BITS_PER_LONG tools include: Adopt linux/bits.h ...
2018-10-02x86/cpu: Sanitize FAM6_ATOM namingPeter Zijlstra
Going primarily by: https://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors with additional information gleaned from other related pages; notably: - Bonnell shrink was called Saltwell - Moorefield is the Merriefield refresh which makes it Airmont The general naming scheme is: FAM6_ATOM_UARCH_SOCTYPE for i in `git grep -l FAM6_ATOM` ; do sed -i -e 's/ATOM_PINEVIEW/ATOM_BONNELL/g' \ -e 's/ATOM_LINCROFT/ATOM_BONNELL_MID/' \ -e 's/ATOM_PENWELL/ATOM_SALTWELL_MID/g' \ -e 's/ATOM_CLOVERVIEW/ATOM_SALTWELL_TABLET/g' \ -e 's/ATOM_CEDARVIEW/ATOM_SALTWELL/g' \ -e 's/ATOM_SILVERMONT1/ATOM_SILVERMONT/g' \ -e 's/ATOM_SILVERMONT2/ATOM_SILVERMONT_X/g' \ -e 's/ATOM_MERRIFIELD/ATOM_SILVERMONT_MID/g' \ -e 's/ATOM_MOOREFIELD/ATOM_AIRMONT_MID/g' \ -e 's/ATOM_DENVERTON/ATOM_GOLDMONT_X/g' \ -e 's/ATOM_GEMINI_LAKE/ATOM_GOLDMONT_PLUS/g' ${i} done Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Cc: dave.hansen@linux.intel.com Cc: len.brown@intel.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-09-30ACPI / LPSS: Resume BYT/CHT I2C controllers from resume_noirqHans de Goede
On some Cherry Trail systems the GPU ACPI fwnode has power-resources which point to the PMIC, which is connected over a LPSS I2C controller. We add a device-link to make sure that the I2C controller is resumed before the GPU is. But the pci-core changes the power-state of PCI devices from D3 to D0 at noirq time (to restore the PCI config registers) and before this commit we were bringing up the I2C controllers from a resume_early handler which runs later. More specifically the pm-core will first run all resume_noirq handlers in order and then all resume_early handlers. So we must not only make sure that the handlers are run in the right order, but also that the resume of the I2C controller is done at noirq time. The behavior before this commit, resuming the I2C controller from a resume_early handler leads to the following errors: i2c_designware 808622C1:06: controller timed out ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion] ACPI Error: Method parse/execution failed \_SB.P18W._ON, AE_ERROR video LNXVIDEO:00: Failed to change power state to D0 This commit changes the acpi_lpss.c code to resume the BYT/CHT I2C controllers at resume_noirq time fixing this. Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-09-30ACPI / LPSS: Add a device link from the GPU to the BYT I2C5 controllerHans de Goede
On some Bay Trail systems the GPU ACPI fwnode has power-resources which point to the PMIC, which is connected over the LPSS I2C5 controller. This one was quite nasty to debug, unlike on CHT where the same problem leads to errors like these: i2c_designware 808622C1:06: controller timed out ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion] ACPI Error: Method parse/execution failed \_SB.P18W._ON, AE_ERROR video LNXVIDEO:00: Failed to change power state to D0 On BYT the read-modify-write done by drivers/acpi/pmic/intel_pmic_xpower.c on the AXP288 PMIC register to change the power-resource state *seems* to succeed. But in reality, because the I2C controller has not been resumed yet, the read silently fails and returns the wrong value, where as the write does succeed, writing back the wrong value for all the other power-resources in the same register, turning off a bunch of them. Which of course does not end well. This commit adds a RPM consumer link from the GPU (which has a LNXVIDEO HID) to the BYT LPSS I2C5 controller, so that the I2C controller gets resumed before the GPU is resumed and thus before we try to change the power-resource. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-09-30ACPI / LPSS: Add a device link from the GPU to the CHT I2C7 controllerHans de Goede
On some Cherry Trail systems the GPU ACPI fwnode has power-resources which point to the PMIC, which is connected over the LPSS I2C7 controller. Due to probe ordering currently we resume the GPU and thus try to access the ACPI power-resources before the I2C controller has been resumed. This leads to the following errors: i2c_designware 808622C1:06: controller timed out ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion] ACPI Error: Method parse/execution failed \_SB.P18W._ON, AE_ERROR video LNXVIDEO:00: Failed to change power state to D0 This commit adds a RPM consumer link from the GPU (which has a LNXVIDEO HID) to the CHT LPSS I2C7 controller, so that the I2C controller gets resumed before the GPU is resumed. Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-09-30ACPI / LPSS: Make acpi_lpss_find_device() also find PCI devicesHans de Goede
On some Cherry Trail systems the GPU ACPI fwnode has power-resources which point to the PMIC, which is connected over one of the LPSS I2C controllers. To get the suspend/resume ordering correct for this we need to be able to add device-links between the GPU and the I2c controller. The GPU is a PCI device, so this requires acpi_lpss_find_device() to also work on PCI devs. Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-09-30ACPI / LPSS: Make hid_uid_match helper accept a NULL uid argumentHans de Goede
Make hid_uid_match helper accept a NULL uid argument, so that we can also check for matches against devices with are not expected to have a uid such as the LNXVIDEO device. Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-09-30ACPI / LPSS: Make hid_uid_match helper take an acpi_device as first argumentHans de Goede
The hid_uid_match() helper is only used to check if a given acpi_device matches a certain hid + uid combination. Make the first argument the acpi_device to check to make this more clear. Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-09-17ACPI / LPSS: Exclude I2C busses shared with PUNIT from pmc_atom_d3_maskHans de Goede
lpss_iosf_enter_d3_state() checks if all hw-blocks using the DMA controllers are in d3 before powering down the DMA controllers. But on devices, where the I2C bus connected to the PMIC is shared by the PUNIT, the controller for that bus will never reach d3 since it has an effectively empty _PS3 method. Instead it appears to automatically power-down during S0i3 and we never see it as being in d3. This causes the DMA controllers to never be powered-down on these devices, causing them to never reach S0i3. This commit uses the ACPI _SEM method to detect if an I2C bus is shared with the PUNIT and if it is, it removes it from the mask of devices which lpss_iosf_enter_d3_state() checks for. This fixes these devices never reaching any S0ix states. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-09-10ACPI / LPSS: Add alternative ACPI HIDs for Cherry Trail DMA controllersHans de Goede
Bay and Cherry Trail DSTDs represent a different set of devices depending on which OS the device think it is booting. One set of decices for Windows and another set of devices for Android which targets the Android-x86 Linux kernel fork (which e.g. used to have its own display driver instead of using the i915 driver). Which set of devices we are actually going to get is out of our control, this is controlled by the ACPI OSID variable, which gets either set through an EFI setup option, or sometimes is autodetected. So we need to support both. This commit adds support for the 80862286 and 808622C0 ACPI HIDs which we get for the first resp. second DMA controller on Cherry Trail devices when OSID is set to Android. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-09-06ACPI / LPSS: Force LPSS quirks on bootZhang Rui
Commit 12864ff8545f (ACPI / LPSS: Avoid PM quirks on suspend and resume from hibernation) bypasses lpss quirks for S3 and S4, by setting a flag for S3/S4 in acpi_lpss_suspend(), and check that flag in acpi_lpss_resume(). But this overlooks the boot case where acpi_lpss_resume() may get called without a corresponding acpi_lpss_suspend() having been called. Thus force setting the flag during boot. Fixes: 12864ff8545f (ACPI / LPSS: Avoid PM quirks on suspend and resume from hibernation) Link: https://bugzilla.kernel.org/show_bug.cgi?id=200989 Reported-and-tested-by: William Lieurance <william.lieurance@namikoda.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Cc: 4.15+ <stable@vger.kernel.org> # 4.15+: 12864ff8545f (ACPI / LPSS: Avoid ...) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-07-27ACPI / LPSS: Avoid PM quirks on suspend and resume from hibernationRafael J. Wysocki
Commit a09c59130688 (ACPI / LPSS: Avoid PM quirks on suspend and resume from S3) modified the ACPI driver for Intel SoCs (LPSS) to avoid applying PM quirks on suspend and resume from S3 to address system-wide suspend and resume problems on some systems, but it is reported that the same issue also affects hibernation, so extend the approach used by that commit to cover hibernation as well. Fixes: a09c59130688 (ACPI / LPSS: Avoid PM quirks on suspend and resume from S3) Link: https://bugs.launchpad.net/bugs/1774950 Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: 4.15+ <stable@vger.kernel.org> # 4.15+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2018-06-21Merge branches 'acpi-soc' and 'acpi-processor'Rafael J. Wysocki
These are a stable-candidate suspend/resume fix of the ACPI driver for Intel SoCs (LPSS) and an inline stub fix for the ACPI processor driver. * acpi-soc: ACPI / LPSS: Avoid PM quirks on suspend and resume from S3 * acpi-processor: ACPI / processor: Finish making acpi_processor_ppc_has_changed() void
2018-06-14ACPI / LPSS: Avoid PM quirks on suspend and resume from S3Rafael J. Wysocki
It is reported that commit a192aa923b66a (ACPI / LPSS: Consolidate runtime PM and system sleep handling) introduced a system suspend regression on some machines, but the only functional change made by it was to cause the PM quirks in the LPSS to also be used during system suspend and resume. While that should always work for suspend-to-idle, it turns out to be problematic for S3 (suspend-to-RAM). To address that issue restore the previous S3 suspend and resume behavior of the LPSS to avoid applying PM quirks then. Fixes: a192aa923b66a (ACPI / LPSS: Consolidate runtime PM and system sleep handling) Link: https://bugs.launchpad.net/bugs/1774950 Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: 4.15+ <stable@vger.kernel.org> # 4.15+
2018-06-14Merge tag 'pwm/for-4.18-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm Pull pwm updates from Thierry Reding: "This contains a couple of fixes and cleanups for the Meson and ACPI/LPSS drivers as well as capture support for STM32. Note that given the cross- subsystem changes, the STM32 patches were merged through the MFD and PWM trees, both sharing an immutable branch" * tag 'pwm/for-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm: pwm: stm32: Fix build warning with CONFIG_DMA_ENGINE disabled pwm: stm32: Enforce dependency on CONFIG_MFD_STM32_TIMERS ACPI / LPSS: Add missing prv_offset setting for byt/cht PWM devices pwm: lpss: platform: Save/restore the ctrl register over a suspend/resume dt-bindings: mfd: stm32-timers: Add support for dmas pwm: simplify getting .drvdata pwm: meson: Fix allocation of PWM channel array
2018-06-06ACPI / LPSS: Add missing prv_offset setting for byt/cht PWM devicesHans de Goede
The LPSS PWM device on on Bay Trail and Cherry Trail devices has a set of private registers at offset 0x800, the current lpss_device_desc for them already sets the LPSS_SAVE_CTX flag to have these saved/restored over device-suspend, but the current lpss_device_desc was not setting the prv_offset field, leading to the regular device registers getting saved/restored instead. This is causing the PWM controller to no longer work, resulting in a black screen, after a suspend/resume on systems where the firmware clears the APB clock and reset bits at offset 0x804. This commit fixes this by properly setting prv_offset to 0x800 for the PWM devices. Cc: stable@vger.kernel.org Fixes: e1c748179754 ("ACPI / LPSS: Add Intel BayTrail ACPI mode PWM") Fixes: 1bfbd8eb8a7f ("ACPI / LPSS: Add ACPI IDs for Intel Braswell") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Rafael J . Wysocki <rjw@rjwysocki.net> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
2018-05-10ACPI / LPSS: Only call pwm_add_table() for Bay Trail PWM if PMIC HRV is 2Hans de Goede
The Point of View mobii wintab p800w Bay Trail tablet comes with a Crystal Cove PMIC, yet uses the LPSS PWM for backlight control, rather then the Crystal Cove's PWM, so we need to call pwm_add_table() to add a pwm_backlight mapping for the LPSS pwm despite there being an INT33FD ACPI device present. On all Bay Trail devices the _HRV object of the INT33FD ACPI device will normally return 2, to indicate the Bay Trail variant of the CRC PMIC is present, except on this tablet where _HRV is 0xffff. I guess this is a hack to make the windows Crystal Cove PWM driver not bind. Out of the 44 DSTDs with an INT33FD device in there which I have (from different model devices) only the pov mobii wintab p800w uses 0xffff for the HRV. The byt_pwm_setup code calls acpi_dev_present to check for the presence of a INT33FD ACPI device which indicates that a CRC PMIC is present and if the INT33FD ACPI device is present then byt_pwm_setup will not add a pwm_backlight mapping for the LPSS pwm, so that the CRC PWM will get used instead. acpi_dev_present has a hrv parameter, this commit make us pass 2 instead of -1, so that things still match on normal tablets, but on this special case with its _HRV of 0xffff, the check will now fail so that the pwm_backlight mapping for the LPSS pwm gets added fixing backlight brightness control on this device. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-01-15ACPI / LPSS: Do not instiate platform_dev for devs without MMIO resourcesHans de Goede
acpi_lpss_create_device() skips handling LPSS devices which do not have a mmio resources in their resource list (typically these devices are disabled by the firmware). But since the LPSS code does not bind to the device, acpi_bus_attach() ends up still creating a platform device for it and the regular platform_driver for the ACPI HID still tries to bind to it. This happens e.g. on some boards which do not use the pwm-controller and have an empty or invalid resource-table for it. Currently this causes these error messages to get logged: [ 3.281966] pwm-lpss 80862288:00: invalid resource [ 3.287098] pwm-lpss: probe of 80862288:00 failed with error -22 This commit stops the undesirable creation of a platform_device for disabled LPSS devices by setting pnp.type.platform_id to 0. Note that acpi_scan_attach_handler() also sets pnp.type.platform_id to 0 when there is a matching handler for the device and that handler has no attach callback, so we simply behave as a handler without an attach function in this case. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-12-16ACPI / LPSS: Add device link for CHT SD card dependency on I2CAdrian Hunter
Some Cherry Trail boards have a dependency between the SDHCI host controller used for SD cards and an external PMIC accessed via I2C. Add a device link between the SDHCI host controller (consumer) and the I2C adapter (supplier). This patch depends on a fix to devices links, namely commit 0ff26c662d5f ("driver core: Fix device link deferred probe"). And also either, commit 126dbc6b49c8 ("PM: i2c-designware-platdrv: Clean up PM handling in probe"), or patch "PM / runtime: Fix handling of suppliers with disabled runtime PM". Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-11-13Merge tag 'acpi-4.15-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI updates from Rafael Wysocki: "These update ACPICA to upstream revision 20170831, fix APEI to use the fixmap instead of ioremap_page_range(), add an operation region driver for TI PMIC TPS68470, add support for PCC subspace IDs to the ACPI CPPC driver, fix a few assorted issues and clean up some code. Specifics: - Update the ACPICA code to upstream revision 20170831 including * PDTT table header support (Bob Moore). * Cleanup and extension of internal string-to-integer conversion functions (Bob Moore). * Support for 64-bit hardware accesses (Lv Zheng). * ACPI PM Timer code adjustment to deal with 64-bit return values of acpi_hw_read() (Bob Moore). * Support for deferred table verification in acpiexec (Lv Zheng). - Fix APEI to use the fixmap instead of ioremap_page_range() which cannot work correctly the way the code in there attempted to use it and drop some code that's not necessary any more after that change (James Morse). - Clean up the APEI support code and make it use 64-bit timestamps (Arnd Bergmann, Dongjiu Geng, Jan Beulich). - Add operation region driver for TI PMIC TPS68470 (Rajmohan Mani). - Add support for PCC subspace IDs to the ACPI CPPC driver (George Cherian). - Fix an ACPI EC driver regression related to the handling of EC events during the "noirq" phases of system suspend/resume (Lv Zheng). - Delay the initialization of the lid state in the ACPI button driver to fix issues appearing on some systems (Hans de Goede). - Extend the KIOX000A "device always present" quirk to cover all affected BIOS versions (Hans de Goede). - Clean up some code in the ACPI core and drivers (Colin Ian King, Gustavo Silva)" * tag 'acpi-4.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (24 commits) ACPI: Mark expected switch fall-throughs ACPI / LPSS: Remove redundant initialization of clk ACPI / CPPC: Make CPPC ACPI driver aware of PCC subspace IDs mailbox: PCC: Move the MAX_PCC_SUBSPACES definition to header file ACPI / sysfs: Make function param_set_trace_method_name() static ACPI / button: Delay acpi_lid_initialize_state() until first user space open ACPI / EC: Fix regression related to triggering source of EC event handling APEI / ERST: use 64-bit timestamps ACPI / APEI: Remove arch_apei_flush_tlb_one() arm64: mm: Remove arch_apei_flush_tlb_one() ACPI / APEI: Remove ghes_ioremap_area ACPI / APEI: Replace ioremap_page_range() with fixmap ACPI / APEI: remove the unused dead-code for SEA/NMI notification type ACPI / x86: Extend KIOX000A quirk to cover all affected BIOS versions ACPI / APEI: adjust a local variable type in ghes_ioremap_pfn_irq() ACPICA: Update version to 20170831 ACPICA: Update acpi_get_timer for 64-bit interface to acpi_hw_read ACPICA: String conversions: Update to add new behaviors ACPICA: String conversions: Cleanup/format comments. No functional changes ACPICA: Restructure/cleanup all string-to-integer conversion functions ...
2017-11-09ACPI / LPSS: Remove redundant initialization of clkColin Ian King
The pointer clk is being initialized to ERR_PTR(-ENODEV) however this value is never read before it is set to clk_data->clk. Thus the initialization is redundant and can be mored. Cleans up clang warning: Value stored to 'clk' during its initialization is never read Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-11-06ACPI / PM: Take SMART_SUSPEND driver flag into accountRafael J. Wysocki
Make the ACPI PM domain take DPM_FLAG_SMART_SUSPEND into account in its system suspend callbacks. [Note that the pm_runtime_suspended() check in acpi_dev_needs_resume() is an optimization, because if is not passed, all of the subsequent checks may be skipped and some of them are much more overhead in general.] Also use the observation that if the device is in runtime suspend at the beginning of the "late" phase of a system-wide suspend-like transition, its state cannot change going forward (runtime PM is disabled for it at that time) until the transition is over and the subsequent system-wide PM callbacks should be skipped for it (as they generally assume the device to not be suspended), so add checks for that in acpi_subsys_suspend_late/noirq() and acpi_subsys_freeze_late/noirq(). Moreover, if acpi_subsys_resume_noirq() is called during the subsequent system-wide resume transition and if the device was left in runtime suspend previously, its runtime PM status needs to be changed to "active" as it is going to be put into the full-power state going forward, so add a check for that too in there. In turn, if acpi_subsys_thaw_noirq() runs after the device has been left in runtime suspend, the subsequent "thaw" callbacks need to be skipped for it (as they may not work correctly with a suspended device), so set the power.direct_complete flag for the device then to make the PM core skip those callbacks. On top of the above, make the analogous changes in the acpi_lpss driver that uses the ACPI PM domain callbacks. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-24ACPI / LPSS: Consolidate runtime PM and system sleep handlingRafael J. Wysocki
Move the LPSS-specific code from acpi_lpss_runtime_suspend() and acpi_lpss_runtime_resume() into separate functions, acpi_lpss_suspend() and acpi_lpss_resume(), respectively, and make acpi_lpss_suspend_late() and acpi_lpss_resume_early() use them too in order to unify the runtime PM and system sleep handling in the LPSS driver. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-10-17ACPI / PM: Combine device suspend routinesRafael J. Wysocki
On top of a previous change getting rid of the PM QoS flag PM_QOS_FLAG_REMOTE_WAKEUP, combine two ACPI device suspend routines, acpi_dev_runtime_suspend() and acpi_dev_suspend_late(), into one, acpi_dev_suspend(), to eliminate some code duplication. It also avoids enabling wakeup for devices handled by the ACPI LPSS middle layer on driver removal. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-10-11ACPI / PM: Restore acpi_subsys_complete()Ulf Hansson
Commit 58a1fbbb2ee8 (PM / PCI / ACPI: Kick devices that might have been reset by firmware), made PCI's and ACPI's ->complete() callbacks to be assigned to a new API called pm_complete_with_resume_check(), which was introduced in the same change. Later it turned out that using pm_complete_with_resume_check() wasn't good enough for PCI, as it needed additional PCI specific checks, before deciding whether runtime resuming the device is needed when running the ->complete() callback. This leaves ACPI as the only user of pm_complete_with_resume_check(). Therefore let's restore ACPI's acpi_subsys_complete(), which was dropped in commit 58a1fbbb2ee8 (PM / PCI / ACPI: Kick devices that might have been reset by firmware). This enables us to remove the pm_complete_with_resume_check() API in a following change, but it also enables ACPI to add more ACPI specific checks in acpi_subsys_complete() if that turns out to be necessary. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-10-11ACPI / PM: Combine two identical device resume routinesRafael J. Wysocki
Notice that acpi_dev_runtime_resume() and acpi_dev_resume_early() are actually literally identical after some more-or-less recent changes, so rename acpi_dev_runtime_resume() to acpi_dev_resume(), use it everywhere instead of acpi_dev_resume_early() and drop the latter. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-08-10ACPI / LPSS: Don't abort ACPI scan on missing mem resourceRonald Tschalär
The keyboard and touchpad on MacBook's from 2015 onwards are connected via an SPI bus. On MacBook8's (2015) the ACPI device for the SPI master for this bus has _CID "INT33C1", and hence the acpi-lpss handler here is triggered for it. However, the DSDT lists no memory resources for this device, resulting in an error being returned by the attach callback and therefore the SPI master device being ignored. This prevents us from being able to register the keyboard and touchpad driver. Furthermore, the controller (a Wildcat Point-LP controller) does not appear to need the functionality provided by the apci-lpss handler. Therefore we now just skip the handler if no memory resources are found and let the ACPI scan complete successfully for this device. All of this is not an issue on later MacBook(Pro)'s because their ACPI SPI devices don't have any _CID and therefore no attempt is made to attach this handler. Returning an error was introduced in commit d3e13ff3c1aa - this restores the original behaviour. Link: https://github.com/cb22/macbook12-spi-driver Signed-off-by: Ronald Tschalär <ronald@innovation.ch> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-08-03Merge branches 'acpi-soc', 'acpi-wdat' and 'acpi-cppc'Rafael J. Wysocki
* acpi-soc: ACPI: APD: Fix HID for Hisilicon Hip07/08 ACPI / LPSS: Only call pwm_add_table() for the first PWM controller * acpi-wdat: ACPI / watchdog: Fix init failure with overlapping register regions * acpi-cppc: mailbox: pcc: Fix crash when request PCC channel 0
2017-07-06ACPI / LPSS: Only call pwm_add_table() for the first PWM controllerHans de Goede
At least on the UP board SBC both PWMs are enabled leading to us trying to add the same pwm_lookup twice, which leads to the following: [ 0.902224] list_add double add: new=ffffffffb8efd400, prev=ffffffffb8efd400, next=ffffffffb8eeede0. [ 0.912466] ------------[ cut here ]------------ [ 0.917624] kernel BUG at lib/list_debug.c:31! [ 0.922588] invalid opcode: 0000 [#1] SMP ... [ 1.027450] Call Trace: [ 1.030185] pwm_add_table+0x4c/0x90 [ 1.034181] bsw_pwm_setup+0x1a/0x20 [ 1.038175] acpi_lpss_create_device+0xfe/0x420 ... This commit fixes this by only calling pwm_add_table() for the first PWM controller (which is the one used for the backlight). Link: https://bugzilla.redhat.com/show_bug.cgi?id=1458599 Fixes: bf7696a12071 (acpi: lpss: call pwm_add_table() for BSW...) Fixes: 04434ab5120a (ACPI / LPSS: Call pwm_add_table() for Bay Trail...) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: 4.11+ <stable@vger.kernel.org> # 4.11+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-04ACPI / LPSS: constify attribute_group structuresArvind Yadav
attribute_groups are not supposed to change at runtime. All functions working with attribute_groups provided by <linux/sysfs.h> work with const attribute_group. So mark the non-const structs as const. Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>