summaryrefslogtreecommitdiff
path: root/drivers/acpi/pmic
AgeCommit message (Collapse)AuthorFilesLines
2017-11-16Merge tag 'mfd-next-4.15' of ↵Linus Torvalds1-0/+137
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd Pull MFD updates from Lee Jones: "New drivers: - Add support for Cherry Trail Dollar Cove TI PMIC - Add support for Add Spreadtrum SC27xx series PMICs New device support: - Add support Regulator to axp20x New functionality: - Add DT support; aspeed-scu sc27xx-pmic - Add power saving support; rts5249 Fix-ups: - DT clean-up/rework; tps65217, max77693, iproc-cdru, iproc-mhb, tps65218 - Staticise/constify; stw481x - Use new succinct IRQ API; fsl-imx25-tsadc - Kconfig fix-ups; MFD_TPS65218 - Identify SPI method; lpc_ich - Use managed resources (devm_*) calls; ssbi - Remove unused/obsolete code/documentation; mc13xxx Bug fixes: - Fix typo in MAINTAINERS - Fix error handling; mxs-lradc - Clean-up IRQs on .remove; fsl-imx25-tsadc" * tag 'mfd-next-4.15' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (21 commits) dt-bindings: mfd: mc13xxx: Remove obsolete property mfd: axp20x: Add axp20x-regulator cell for AXP813 mfd: Add Spreadtrum SC27xx series PMICs driver dt-bindings: mfd: Add Spreadtrum SC27xx PMIC documentation mfd: ssbi: Use devm_of_platform_populate() mfd: fsl-imx25: Clean up irq settings during removal mfd: mxs-lradc: Fix error handling in mxs_lradc_probe() mfd: lpc_ich: Avoton/Rangeley uses SPI_BYT method mfd: tps65218: Introduce dependency on CONFIG_OF mfd: tps65218: Correct the config description MAINTAINERS: Fix Dialog search term for watchdog binding file mfd: fsl-imx25: Set irq handler and data in one go mfd: rts5249: Add support for RTS5250S power saving ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMIC mfd: Add support for Cherry Trail Dollar Cove TI PMIC syscon: dt-bindings: Add binding document for iProc MHB block syscon: dt-bindings: Add binding doc for Broadcom iProc CDRU mfd: max77693: Add muic of_compatible in mfd_cell mfd: stw481x: Make three arrays static const, reduces object code size mfd: tps65217: Introduce dependency on CONFIG_OF ...
2017-11-13Merge branches 'acpi-pmic', 'acpi-apei' and 'acpi-x86'Rafael J. Wysocki1-0/+455
* acpi-pmic: ACPI / PMIC: Add TI PMIC TPS68470 operation region driver * acpi-apei: 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 / APEI: adjust a local variable type in ghes_ioremap_pfn_irq() * acpi-x86: ACPI / x86: Extend KIOX000A quirk to cover all affected BIOS versions
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman1-0/+1
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-10-13ACPI / PMIC: Add opregion driver for Intel Dollar Cove TI PMICTakashi Iwai1-0/+137
This patch adds the opregion driver for Dollar Cove TI PMIC on Intel Cherry Trail devices. The patch is based on the original work by Intel, found at: https://github.com/01org/ProductionKernelQuilts with many cleanups and rewrites. The driver is currently provided only as built-in to follow other PMIC opregion drivers convention. The re-enumeration of devices at probe is required for fixing the issues on HP x2 210 G2. See bug#195689. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=193891 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195689 Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org>
2017-10-03ACPI / PMIC: Add TI PMIC TPS68470 operation region driverRajmohan Mani1-0/+455
The Kabylake platform coreboot (Chrome OS equivalent of BIOS) has defined 4 operation regions for the TI TPS68470 PMIC. These operation regions are to enable/disable voltage regulators, configure voltage regulators, enable/disable clocks and to configure clocks. This config adds ACPI operation region support for TI TPS68470 PMIC. TPS68470 device is an advanced power management unit that powers a Compact Camera Module (CCM), generates clocks for image sensors, drives a dual LED for flash and incorporates two LED drivers for general purpose indicators. This driver enables ACPI operation region support to control voltage regulators and clocks for the TPS68470 PMIC. Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-07-24ACPI / PMIC: xpower: Do pinswitch magic when reading GPADCHans de Goede1-3/+18
Testing has shown that the TS-pin's bias-current needs to be disabled when reading the GPIO0 pin in GPADC mode. It seems that there is only 1 bias current source and to be able to use it for the GPIO0 pin in GPADC mode it must be temporarily turned off for the TS pin, but the datasheet does not mention this. This commit adds the necessary writes to turn the TS pin BIAS current off before and back on after reading the GPADC. This fixes the GPADC always returning a reading of 0. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-06-22ACPI / PMIC: xpower: Add support for the GPI1 regulator to the OpRegion handlerHans de Goede1-1/+20
Some Bay Trail devices use a GPI1 regulator field (address 0x4c) in their 0x8d power OpRegion, add support for this. This fixes AE_BAD_PARAMETER errors getting thrown on these devices and fixes these errors causing these devices to not suspend. 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>
2017-04-29ACPI / PMIC: xpower: Fix power_table addressesHans de Goede1-25/+25
The power table addresses should be contiguous, but there was a hole where 0x34 was missing. On most devices this is not a problem as addresses above 0x34 are used for the BUC# convertors which are not used in the DSDTs I've access to but after the BUC# convertors there is a field named GPI1 in the DSTDs, which does get used in some cases and ended up turning BUC6 on and off due to the wrong addresses, resulting in turning the entire device off (or causing it to reboot). Removing the hole in the addresses fixes this, fixing one of my Bay Trail tablets turning off while booting the mainline kernel. While at it add comments with the field names used in the DSDTs to make it easier to compare the register and bits used at each address with the datasheet. 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>
2017-04-20ACPI / PMIC: Stop xpower OPRegion handler relying on IIOHans de Goede1-17/+4
The intel_pmic_xpower code provides an OPRegion handler, which must be available before other drivers using it are loaded, which can only be ensured if both the mfd and opregion drivers are built in, which is why the Kconfig option for intel_pmic_xpower is a bool. The use of IIO is causing trouble for generic distro configs here as distros will typically want to build IIO drivers as modules and there really is no reason to use IIO here. The reading of the ADC value is a single regmap_bulk_read, which is already protected against races by the regmap-lock. This commit removes the use of IIO, allowing distros to enable the driver without needing to built IIO in and also actually simplifies the code. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-04-20ACPI / PMIC: Add opregion driver for Intel CHT Whiskey Cove PMICHans de Goede1-0/+280
Add opregion driver for Intel CHT Whiskey Cove PMIC, based on various non upstreamed CHT Whiskey Cove PMIC patches. This does not include support for the Thermal opregion (DPTF) due to lacking documentation. 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>
2016-07-16ACPI / PMIC: remove modular references from non-modular codePaul Gortmaker3-13/+4
The Kconfig currently controlling compilation of these files are: drivers/acpi/Kconfig:menuconfig PMIC_OPREGION drivers/acpi/Kconfig: bool "PMIC (Power Management Integrated Circuit) operation region support" drivers/acpi/Kconfig:config BXT_WC_PMIC_OPREGION drivers/acpi/Kconfig: bool "ACPI operation region support for BXT WhiskeyCove PMIC" drivers/acpi/Kconfig:config XPOWER_PMIC_OPREGION drivers/acpi/Kconfig: bool "ACPI operation region support for XPower AXP288 PMIC" ...meaning they currently are not being built as a module by anyone. Lets remove the couple traces of modular infrastructure use, so that when reading the code there is no doubt it is builtin-only. We delete the MODULE_LICENSE tag etc. since all that information is already contained at the top of the file in the comments. One file was using module_init. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. In one case we replace the module.h with export.h since that file is exporting some symbols, but does not use __init. The other two are using __init and so module.h gets replaced with init.h there. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-06-27ACPI / PMIC: intel: initialize result to 0Felipe Balbi1-1/+1
Fixes compiler warning. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-06-27ACPI / PMIC: intel: add REGS operation region supportFelipe Balbi1-1/+66
At least some of the Broxtons have a third custom OpRegion named REGS. This adds handling for it. Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-06-24ACPI / PMIC: Add opregion driver for Intel BXT WhiskeyCove PMICBin Gao1-0/+424
This patch adds operation region driver for Intel BXT WhiskeyCove PMIC. The register mapping is done as per the BXT WC data sheet. Signed-off-by: Ajay Thomas <ajay.thomas.david.rajamanickam@intel.com> Signed-off-by: Bin Gao <bin.gao@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-06-24ACPI / PMIC: modify the pen function signature to take bit fieldBin Gao3-10/+12
Issue description: On some pmics, the policy enable for thermal alerts refers to different bit fields of the same registers, whereas on other pmics, the policy enable refers to the same bit field on different registers. Previous implementation did not provide the flexibility for supporting the first approach. Solution: Modified the policy enable function to take bit field as well. The use of bit field is left to the pmic specific opregion driver. Signed-off-by: Yegnesh Iyer <yegnesh.s.iyer@intel.com> Signed-off-by: Bin Gao <bin.gao@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-03-10drivers/acpi: make pmic/intel_pmic_crc.c explicitly non-modularPaul Gortmaker1-5/+2
The Kconfig currently controlling compilation of this code is: drivers/acpi/Kconfig:config CRC_PMIC_OPREGION drivers/acpi/Kconfig: bool "ACPI operation region support for CrystalCove PMIC" ...meaning that it currently is not being built as a module by anyone. Lets remove the couple modular references, so that when reading the driver there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. We also delete the MODULE_LICENSE tag etc. since all that information is already contained at the top of the file in the comments. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Acked-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-03-26ACPI/PMIC: Fix typo in MODULE_DESCRIPTION in intel_pmic_crc.cMasanari Iida1-1/+1
This patch fix a spelling typo in MODULE_DESCRIPTION within intel_pmic_crc.c Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-01-29ACPI / PMIC: Use common LPAT table handling functionsSrinivas Pandruvada1-115/+18
The LPAT table processing functions from this modules are moved to a standalone module with exported interface functions. Using new interface functions in this module. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
2014-11-27ACPI / PMIC: AXP288: support virtual GPIO in ACPI tableAaron Lu1-4/+26
The same virtual GPIO strategy is also used for the AXP288 PMIC in that various control methods that are used to do power rail handling and sensor reading/setting will touch GPIO fields defined under the PMIC device. The GPIO fileds are only defined by the ACPI code while the actual hardware doesn't really have a GPIO controller, but to make those control method execution succeed, we have to install a GPIO handler for the PMIC device handle. Since we do not need the virtual GPIO strategy, we can simply do nothing in that handler. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-27ACPI / PMIC: support PMIC operation region for XPower AXP288Aaron Lu1-0/+246
The Baytrail-T-CR platform firmware has defined two customized operation regions for PMIC chip Dollar Cove XPower - one is for power resource handling and one is for thermal just like the CrystalCove one. This patch adds support for them on top of the common PMIC opregion region code. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Lee Jones <lee.jones@linaro.org> for the MFD part Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-27ACPI / PMIC: support PMIC operation region for CrystalCoveAaron Lu3-0/+590
The Baytrail-T platform firmware has defined two customized operation regions for PMIC chip Crystal Cove - one is for power resource handling and one is for thermal: sensor temperature reporting, trip point setting, etc. This patch adds support for them on top of the existing Crystal Cove PMIC driver. The reason to split code into a separate file intel_pmic.c is that there are more PMIC drivers with ACPI operation region support coming and we can re-use those code. The intel_pmic_opregion_data structure is created also for this purpose: when we need to support a new PMIC's operation region, we just need to fill those callbacks and the two register mapping tables. Signed-off-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Lee Jones <lee.jones@linaro.org> for the MFD part Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>