diff options
Diffstat (limited to 'Documentation/acpi/enumeration.txt')
| -rw-r--r-- | Documentation/acpi/enumeration.txt | 60 |
1 files changed, 20 insertions, 40 deletions
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. |