- Mar 07, 2019
-
-
Flavio Suligoi authored
The file: Documentation/acpi/aml-debugger.txt reports an obsolete path for the acpidbg tool, so fix it. Signed-off-by:
Flavio Suligoi <f.suligoi@asem.it> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- Jan 14, 2019
-
-
Shunyong Yang authored
In some scenario, we need to build initrd with kernel in a single image. This can simplify system deployment process by downloading the whole system once, such as in IC verification. This patch adds support to override ACPI tables from built-in initrd. Signed-off-by:
Shunyong Yang <shunyong.yang@hxt-semitech.com> [ rjw: Minor cleanups ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- Jul 23, 2018
-
-
Sakari Ailus authored
Instead of port and endpoint properties for representing ports and endpoints, use the keys of the hierarchical data extension references when referring to the port and endpoint nodes. Additionally, use "reg" properties as in Device Tree to specify the number of the port or the endpoint. The keys of the port nodes begin with "port" and the keys of the endpoint nodes begin with "endpoint", both followed by "@" character and the number of the port or the endpoint. These changes have the advantage that no ACPI specific properties need to be added to refer to non-device nodes. Additionally, using the name of the node instead of an integer property inside the node is easier to parse in code and easier for humans to understand. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Sakari Ailus authored
Document that if a port has a single endpoint only, its value shall be zero. Similarly, if a device object only has a single port, its value shlla be zero. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Sakari Ailus authored
Address a few issues in the ACPI _DSD properties graph documentation: - the extension for port nodes is a data extension (and not property extension), - clean up language in port hierarchical data extension definition, - add examples of port and endpoint packages, - port property value is the number of the "port" and not the number of the "port node", - remove word "individual" from endpoint data node description, it was redundant, - remove the extra "The" in the endpoint property description, - refer to hierarchical data extension keys and targets instead of first and second package list entries. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Sakari Ailus authored
Hierarchical data extension 1.1 allows using references as the second entries of the hierearchical data extension packages. Update the references and the examples. The quotes are left in documentation for clarity. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Sakari Ailus authored
As part of the hierarchical data extension key naming, introduce numbering scheme for the nodes that may be referred to using hierarchical data extension references. This allows iterating over particular kind of nodes recognised by the node name whilst allowing numbering the nodes, bringing ACPI to feature parity with DT in this respect. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Sakari Ailus authored
Add documentation on how to refer to hierarchical data nodes in a generic way. This brings ACPI to feature parity with Device Tree in terms of being able to refer to any node in the tree. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- Jun 06, 2018
-
-
Erik Kaneda authored
Reviewed-by:
Changzhong Li <changzhong.li@intel.com> Reviewed-by:
Rui Zhang <rui.zhang@intel.com> Signed-off-by:
Erik Schmauss <erik.schmauss@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- Apr 24, 2018
-
-
Prashanth Prakash authored
Add a file to describe the CPPC sysfs interface and steps to compute average delivered performance using the feedback counters. Signed-off-by:
Prashanth Prakash <pprakash@codeaurora.org> [ rjw: Minor adjustments ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- Oct 11, 2017
-
-
Srinivas Pandruvada authored
Add functionality to read LPIT table, which provides: - Sysfs interface to read residency counters via /sys/devices/system/cpu/cpuidle/low_power_idle_cpu_residency_us /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us Here the count "low_power_idle_cpu_residency_us" shows the time spent by CPU package in low power state. This is read via MSR interface, which points to MSR for PKG C10. Here the count "low_power_idle_system_residency_us" show the count the system was in low power state. This is read via MMIO interface. This is mapped to SLP_S0 residency on modern Intel systems. This residency is achieved only when CPU is in PKG C10 and all functional blocks are in low power state. It is possible that none of the above counters present or anyone of the counter present or all counters present. For example: On my Kabylake system both of the above counters present. After suspend to idle these counts updated and prints: 6916179 6998564 This counter can be read by tools like turbostat to display. Or it can be used to debug, if modern systems are reaching desired low power state. - Provides an interface to read residency counter memory address This address can be used to get the base address of PMC memory mapped IO. This is utilized by intel_pmc_core driver to print more debug information. In addition, to avoid code duplication to read iomem, removed the read of iomem from acpi_os_read_memory() in osl.c and made a common function acpi_os_read_iomem(). This new function is used for reading iomem in in both osl.c and acpi_lpit.c. Link: http://www.uefi.org/sites/default/files/resources/Intel_ACPI_Low_Power_S0_Idle.pdf Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- May 29, 2017
-
-
Andy Shevchenko authored
Documentation lacks of explanation how we actually use device properties for GPIO resources. Add a section to the documentation about that. Suggested-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by:
Jarkko Nikula <jarkko.nikula@linux.intel.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
- May 12, 2017
-
-
Lv Zheng authored
This reverts commit ecb10b69. The only expected ACPI control method lid device's usage model is 1. Listen to the lid notification, 2. Evaluate _LID after being notified by BIOS, 3. Suspend the system (if users configure to do so) after seeing "close". It's not ensured that BIOS will notify OS after boot/resume, and it's not ensured that BIOS will always generate "open" event upon opening the lid. But there are 2 wrong usage models: 1. When the lid device is responsible for suspend/resume the system, userspace requires to see "open" event to be paired with "close" after the system is resumed, or it will suspend the system again. 2. When an external monitor connects to the laptop attached docks, userspace requires to see "close" event after the system is resumed so that it can determine whether the internal display should remain dark and the external display should be lit on. After we made default kernel behavior to be suitable for usage model 1, users of usage model 2 start to report regressions for such behavior change. Reversion of button.lid_init_state=method doesn't actually reverts to old default behavior as doing so can enter a regression loop, but facilitates users to work the reported regressions around with button.lid_init_state=method. Fixes: ecb10b69 (ACPI / button: Remove lid_init_state=method mode) Cc: 4.11+ <stable@vger.kernel.org> # 4.11+ Link: https://bugzilla.kernel.org/show_bug.cgi?id=195455 Link: https://bugzilla.redhat.com/show_bug.cgi?id=1430259 Tested-by:
Steffen Weber <steffen.weber@gmail.com> Tested-by:
Julian Wiedmann <julian.wiedmann@jwi.name> Reported-by:
Joachim Frieben <jfrieben@hotmail.com> Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- Apr 19, 2017
-
-
Cao jin authored
Fix some typos in the linuxized-acpica.txt document. Signed-off-by:
Cao jin <caoj.fnst@cn.fujitsu.com> [ rjw: Subject / changelog ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- Mar 28, 2017
-
-
Sakari Ailus authored
Document the use of references into the hierarchical data extension structure, as well as the use of port and endpoint concepts that are very similar to those in Devicetree. Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- Mar 17, 2017
-
-
Tamara Diaconita authored
Fix typos in acpi directory to make documentation grammatically correct. Signed-off-by:
Tamara Diaconita <diaconita.tamara@gmail.com> Signed-off-by:
Jonathan Corbet <corbet@lwn.net>
-
- Feb 28, 2017
-
-
Masahiro Yamada authored
Fix typos and add the following to the scripts/spelling.txt: followings||following While we are here, add a missing colon in the boilerplate in DT binding documents. The "you SoC" in allwinner,sunxi-pinctrl.txt was fixed as well. I reworded "as the followings:" to "as follows:" for drivers/usb/gadget/udc/renesas_usb3.c. Link: http://lkml.kernel.org/r/1481573103-11329-32-git-send-email-yamada.masahiro@socionext.com Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Masahiro Yamada authored
Fix typos and add the following to the scripts/spelling.txt: overrided||overridden Link: http://lkml.kernel.org/r/1481573103-11329-22-git-send-email-yamada.masahiro@socionext.com Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Jan 31, 2017
-
-
Lv Zheng authored
The mode is buggy, and lid_init__state=open is more useful than this mode, so this patch makes it deprecated. Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- Dec 06, 2016
-
-
Rafael J. Wysocki authored
Following some discussions during the Kernel Summit and LPC, document what can be returned from ACPI _DSD as device properties and when it is valid to use the special PRP0001 device ID. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviwed-by:
Mark Brown <broonie@kernel.org>
-
- Dec 03, 2016
-
-
Len Brown authored
Based on a recent session at the Linux Plumber's Conference, we need to be more clear about how a BIOS should use _OSI to properly support Linux. Signed-off-by:
Len Brown <len.brown@intel.com> Reviewed-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- Oct 24, 2016
-
-
Mika Westerberg authored
Now that we have the new helper function that sets nice names for GPIO lines based on "gpio-line-names" device property, we can take advantage of this in acpi_gpiochip_add(). Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Mika Westerberg authored
GPIO hogging means that the GPIO controller can "hog" and configure certain GPIOs without need for a driver or userspace to do that. This is useful in open-connected boards where BIOS cannot possibly know beforehand which devices will be connected to the board. This adds GPIO hogging mechanism to ACPI analogous to Device Tree. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Mika Westerberg authored
Make it possible to have an empty GPIOs in a GPIO list for device. For example a SPI master may use both GPIOs and native pins as chip selects and we need to be able to distinguish between the two. This makes it mandatory to have exactly 3 arguments for GPIOs and then converts gpiolib to use of __acpi_node_get_property_reference() instead. In addition we make acpi_gpio_package_count() to handle holes as well (this matches the DT version). Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org>
-
Mauro Carvalho Chehab authored
The previous patch renamed several files that are cross-referenced along the Kernel documentation. Adjust the links to point to the right places. Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com>
-
- Sep 29, 2016
-
-
Mika Westerberg authored
The recommended property name for all kinds of GPIOs is to end it with "-gpios" even if there is only one GPIO. Update the documentation to follow this fact. Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- Aug 30, 2016
-
-
Lv Zheng authored
This patch adds documentation for the usage model of the control method lid device on some buggy platforms. Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Acked-by:
Benjamin Tissoires <benjamin.tissoires@gmail.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- Jul 08, 2016
-
-
Lv Zheng authored
This patch documents the AML debugger. Signed-off-by:
Lv Zheng <lv.zheng@intel.com> [ rjw: Editorial changes ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Lv Zheng authored
This patch documents the ACPICA release automation. Signed-off-by:
Lv Zheng <lv.zheng@intel.com> [ rjw: Editorial changes ] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Octavian Purdila authored
New tables can be loaded by creating directories under /config/table/ and writing the AML code into the aml table attribute. Various table attributes will be readable once the table is successfully loaded. Unloading tables is not supported at the moment, but it can be easily implemented once ACPI loading functions provide a table handle to be used for unloading. Signed-off-by:
Octavian Purdila <octavian.purdila@intel.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Octavian Purdila authored
This patch allows SSDTs to be loaded from EFI variables. It works by specifying the EFI variable name containing the SSDT to be loaded. All variables with the same name (regardless of the vendor GUID) will be loaded. Note that we can't use acpi_install_table and we must rely on the dynamic ACPI table loading and bus re-scanning mechanisms. That is because I2C/SPI controllers are initialized earlier then the EFI subsystems and all I2C/SPI ACPI devices are enumerated when the I2C/SPI controllers are initialized. Signed-off-by:
Octavian Purdila <octavian.purdila@intel.com> Reviewed-by:
Matt Fleming <matt@codeblueprint.co.uk> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Octavian Purdila authored
Signed-off-by:
Octavian Purdila <octavian.purdila@intel.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- Apr 18, 2016
-
-
Lv Zheng authored
This patch converts the initrd table override mechanism to the table upgrade mechanism by restricting its usage to the tables released with compatibility and more recent revision. This use case has been encouraged by the ACPI specification: 1. OEMID: An OEM-supplied string that identifies the OEM. 2. OEM Table ID: An OEM-supplied string that the OEM uses to identify the particular data table. This field is particularly useful when defining a definition block to distinguish definition block functions. OEM assigns each dissimilar table a new OEM Table Id. 3. OEM Revision: An OEM-supplied revision number. Larger numbers are assumed to be newer revisions. For OEMs, good practices will ensure consistency when assigning OEMID and OEM Table ID fields in any table. The intent of these fields is to allow for a binary control system that support services can use. Because many support function can be automated, it is useful when a tool can programatically determine which table release is a compatible and more recent revision of a prior table on the same OEMID and OEM Table ID. The facility can now be used by the vendors to upgrade wrong tables for bug fixing purpose, thus lockdep disabling taint is not suitable for it and it should be a default 'y' option to implement the spec encouraged use case. Note that, by implementing table upgrade inside of ACPICA itself, it is possible to remove acpi_table_initrd_override() and tables can be upgraded by acpi_install_table() automatically. Though current ACPICA impelentation hasn't implemented this, this patched changes the table flag setting timing to allow this to be implemented in ACPICA without changing the code here. Documentation of initrd override mechanism is upgraded accordingly. Original-by:
Octavian Purdila <octavian.purdila@intel.com> Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- Oct 26, 2015
-
-
Andy Shevchenko authored
There is at least one board on the market, i.e. Intel Galileo Gen2, that uses _ADR to distinguish the devices under one actual device. Due to this we have to improve the quirk in the MFD core to handle that board. Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
- Oct 25, 2015
-
-
Dustin Byford authored
Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or device property compatible string match), enumerating I2C client devices connected through an I2C mux needs a little extra work. This change implements a method for describing an I2C device hierarchy that includes mux devices by using an ACPI Device() for each mux channel along with an _ADR to set the channel number for the device. See Documentation/acpi/i2c-muxes.txt for a simple example. To make this work the ismt, i801, and designware pci/platform devs now share an ACPI companion with their I2C adapter dev similar to how it's done in OF. This is done on the assumption that power management functions will not be called directly on the I2C dev that is sharing the ACPI node. Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Dustin Byford <dustin@cumulusnetworks.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
- Oct 23, 2015
-
-
Andy Shevchenko authored
There is at least one board on the market, i.e. Intel Galileo Gen2, that uses _ADR to distinguish the devices under one actual device. Due to this we have to improve the quirk in the MFD core to handle that board. Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de>
-
- Aug 07, 2015
-
-
Lv Zheng authored
This patch updates method tracing documentation. Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
- Jun 18, 2015
-
-
Mathias Krause authored
ACPI device ID arrays normally don't need to be written to as they're only ever read. The common usage -- embedding pointers to acpi_device_id arrays in other data structures -- reference them as 'const', e.g. as in struct acpi_driver / acpi_scan_handler / device_driver. The matchers are taking const pointers, too. So it's only natural, to propose using const arrays. Change the documentation accordingly. Signed-off-by:
Mathias Krause <minipli@googlemail.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-
Rafael J. Wysocki authored
Document how the ACPI device enumeration code uses the special PRP0001 device ID. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by:
Hanjun Guo <hanjun.guo@linaro.org> Reviewed-by:
Darren Hart <dvhart@linux.intel.com>
-
- May 04, 2015
-
-
Rafael J. Wysocki authored
The first paragraph in Documentation/acpi/gpio-properties.txt is ambiguous, so make it more clear. Reported-by:
Antonio Ospite <ao2@ao2.it> Acked-by:
Antonio Ospite <ao2@ao2.it> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com>
-