aboutsummaryrefslogtreecommitdiff
path: root/Documentation/acpi
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/acpi')
-rw-r--r--Documentation/acpi/apei/einj.txt19
-rw-r--r--Documentation/acpi/dsdt-override.txt2
-rw-r--r--Documentation/acpi/enumeration.txt60
-rw-r--r--Documentation/acpi/namespace.txt9
4 files changed, 40 insertions, 50 deletions
diff --git a/Documentation/acpi/apei/einj.txt b/Documentation/acpi/apei/einj.txt
index a58b63da1a3..f51861bcb07 100644
--- a/Documentation/acpi/apei/einj.txt
+++ b/Documentation/acpi/apei/einj.txt
@@ -45,11 +45,22 @@ directory apei/einj. The following files are provided.
injection. Before this, please specify all necessary error
parameters.
+- flags
+ Present for kernel version 3.13 and above. Used to specify which
+ of param{1..4} are valid and should be used by BIOS during injection.
+ Value is a bitmask as specified in ACPI5.0 spec for the
+ SET_ERROR_TYPE_WITH_ADDRESS data structure:
+ Bit 0 - Processor APIC field valid (see param3 below)
+ Bit 1 - Memory address and mask valid (param1 and param2)
+ Bit 2 - PCIe (seg,bus,dev,fn) valid (param4 below)
+ If set to zero, legacy behaviour is used where the type of injection
+ specifies just one bit set, and param1 is multiplexed.
+
- param1
This file is used to set the first error parameter value. Effect of
parameter depends on error_type specified. For example, if error
type is memory related type, the param1 should be a valid physical
- memory address.
+ memory address. [Unless "flag" is set - see above]
- param2
This file is used to set the second error parameter value. Effect of
@@ -58,6 +69,12 @@ directory apei/einj. The following files are provided.
address mask. Linux requires page or narrower granularity, say,
0xfffffffffffff000.
+- param3
+ Used when the 0x1 bit is set in "flag" to specify the APIC id
+
+- param4
+ Used when the 0x4 bit is set in "flag" to specify target PCIe device
+
- notrigger
The EINJ mechanism is a two step process. First inject the error, then
perform some actions to trigger it. Setting "notrigger" to 1 skips the
diff --git a/Documentation/acpi/dsdt-override.txt b/Documentation/acpi/dsdt-override.txt
index febbb1ba4d2..784841caa6e 100644
--- a/Documentation/acpi/dsdt-override.txt
+++ b/Documentation/acpi/dsdt-override.txt
@@ -4,4 +4,4 @@ CONFIG_ACPI_CUSTOM_DSDT builds the image into the kernel.
When to use this method is described in detail on the
Linux/ACPI home page:
-http://www.lesswatts.org/projects/acpi/overridingDSDT.php
+https://01.org/linux-acpi/documentation/overriding-dsdt
diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt
index d9be7a97dff..e182be5e3c8 100644
--- a/Documentation/acpi/enumeration.txt
+++ b/Documentation/acpi/enumeration.txt
@@ -60,12 +60,6 @@ If the driver needs to perform more complex initialization like getting and
configuring GPIOs it can get its ACPI handle and extract this information
from ACPI tables.
-Currently the kernel is not able to automatically determine from which ACPI
-device it should make the corresponding platform device so we need to add
-the ACPI device explicitly to acpi_platform_device_ids list defined in
-drivers/acpi/acpi_platform.c. This limitation is only for the platform
-devices, SPI and I2C devices are created automatically as described below.
-
DMA support
~~~~~~~~~~~
DMA controllers enumerated via ACPI should be registered in the system to
@@ -207,7 +201,7 @@ passing those. One idea is to return this in _DSM method like:
Return (Local0)
}
-Then the at25 SPI driver can get this configation by calling _DSM on its
+Then the at25 SPI driver can get this configuration by calling _DSM on its
ACPI handle like:
struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
@@ -228,19 +222,9 @@ ACPI handle like:
I2C serial bus support
~~~~~~~~~~~~~~~~~~~~~~
The slaves behind I2C bus controller only need to add the ACPI IDs like
-with the platform and SPI drivers. However the I2C bus controller driver
-needs to call acpi_i2c_register_devices() after it has added the adapter.
-
-An I2C bus (controller) driver does:
-
- ...
- ret = i2c_add_numbered_adapter(adapter);
- if (ret)
- /* handle error */
-
- of_i2c_register_devices(adapter);
- /* Enumerate the slave devices behind this bus via ACPI */
- acpi_i2c_register_devices(adapter);
+with the platform and SPI drivers. The I2C core automatically enumerates
+any slave devices behind the controller device once the adapter is
+registered.
Below is an example of how to add ACPI support to the existing mpu3050
input driver:
@@ -303,32 +287,28 @@ the device to the driver. For example:
These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0"
specifies the path to the controller. In order to use these GPIOs in Linux
-we need to translate them to the Linux GPIO numbers.
+we need to translate them to the corresponding Linux GPIO descriptors.
+
+There is a standard GPIO API for that and is documented in
+Documentation/gpio/.
-The driver can do this by including <linux/acpi_gpio.h> and then calling
-acpi_get_gpio(path, gpio). This will return the Linux GPIO number or
-negative errno if there was no translation found.
+In the above example we can get the corresponding two GPIO descriptors with
+a code like this:
-In a simple case of just getting the Linux GPIO number from device
-resources one can use acpi_get_gpio_by_index() helper function. It takes
-pointer to the device and index of the GpioIo/GpioInt descriptor in the
-device resources list. For example:
+ #include <linux/gpio/consumer.h>
+ ...
- int gpio_irq, gpio_power;
- int ret;
+ struct gpio_desc *irq_desc, *power_desc;
- gpio_irq = acpi_get_gpio_by_index(dev, 1, NULL);
- if (gpio_irq < 0)
+ irq_desc = gpiod_get_index(dev, NULL, 1);
+ if (IS_ERR(irq_desc))
/* handle error */
- gpio_power = acpi_get_gpio_by_index(dev, 0, NULL);
- if (gpio_power < 0)
+ power_desc = gpiod_get_index(dev, NULL, 0);
+ if (IS_ERR(power_desc))
/* handle error */
- /* Now we can use the GPIO numbers */
-
-Other GpioIo parameters must be converted first by the driver to be
-suitable to the gpiolib before passing them.
+ /* Now we can use the GPIO descriptors */
-In case of GpioInt resource an additional call to gpio_to_irq() must be
-done before calling request_irq().
+There are also devm_* versions of these functions which release the
+descriptors once the device is released.
diff --git a/Documentation/acpi/namespace.txt b/Documentation/acpi/namespace.txt
index 260f6a3661f..1860cb3865c 100644
--- a/Documentation/acpi/namespace.txt
+++ b/Documentation/acpi/namespace.txt
@@ -235,10 +235,6 @@ Wysocki <rafael.j.wysocki@intel.com>.
named object's type in the second column). In that case the object's
directory in sysfs will contain the 'path' attribute whose value is
the full path to the node from the namespace root.
- struct acpi_device objects are created for the ACPI namespace nodes
- whose _STA control methods return PRESENT or FUNCTIONING. The power
- resource nodes or nodes without _STA are assumed to be both PRESENT
- and FUNCTIONING.
F:
The struct acpi_device object is created for a fixed hardware
feature (as indicated by the fixed feature flag's name in the second
@@ -340,7 +336,7 @@ Wysocki <rafael.j.wysocki@intel.com>.
| +-------------+-------+----------------+
| |
| | +- - - - - - - +- - - - - - +- - - - - - - -+
- | +-| * PNP0C0D:00 | \_SB_.LID0 | acpi:PNP0C0D: |
+ | +-| PNP0C0D:00 | \_SB_.LID0 | acpi:PNP0C0D: |
| | +- - - - - - - +- - - - - - +- - - - - - - -+
| |
| | +------------+------------+-----------------------+
@@ -390,6 +386,3 @@ Wysocki <rafael.j.wysocki@intel.com>.
attribute (as described earlier in this document).
NOTE: N/A indicates the device object does not have the 'path' or the
'modalias' attribute.
- NOTE: The PNP0C0D device listed above is highlighted (marked by "*")
- to indicate it will be created only when its _STA methods return
- PRESENT or FUNCTIONING.