linux/Documentation/acpi/enumeration.txt
<<
>>
Prefs
   1ACPI based device enumeration
   2~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   3ACPI 5 introduced a set of new resources (UartTSerialBus, I2cSerialBus,
   4SpiSerialBus, GpioIo and GpioInt) which can be used in enumerating slave
   5devices behind serial bus controllers.
   6
   7In addition we are starting to see peripherals integrated in the
   8SoC/Chipset to appear only in ACPI namespace. These are typically devices
   9that are accessed through memory-mapped registers.
  10
  11In order to support this and re-use the existing drivers as much as
  12possible we decided to do following:
  13
  14        o Devices that have no bus connector resource are represented as
  15          platform devices.
  16
  17        o Devices behind real busses where there is a connector resource
  18          are represented as struct spi_device or struct i2c_device
  19          (standard UARTs are not busses so there is no struct uart_device).
  20
  21As both ACPI and Device Tree represent a tree of devices (and their
  22resources) this implementation follows the Device Tree way as much as
  23possible.
  24
  25The ACPI implementation enumerates devices behind busses (platform, SPI and
  26I2C), creates the physical devices and binds them to their ACPI handle in
  27the ACPI namespace.
  28
  29This means that when ACPI_HANDLE(dev) returns non-NULL the device was
  30enumerated from ACPI namespace. This handle can be used to extract other
  31device-specific configuration. There is an example of this below.
  32
  33Platform bus support
  34~~~~~~~~~~~~~~~~~~~~
  35Since we are using platform devices to represent devices that are not
  36connected to any physical bus we only need to implement a platform driver
  37for the device and add supported ACPI IDs. If this same IP-block is used on
  38some other non-ACPI platform, the driver might work out of the box or needs
  39some minor changes.
  40
  41Adding ACPI support for an existing driver should be pretty
  42straightforward. Here is the simplest example:
  43
  44        #ifdef CONFIG_ACPI
  45        static struct acpi_device_id mydrv_acpi_match[] = {
  46                /* ACPI IDs here */
  47                { }
  48        };
  49        MODULE_DEVICE_TABLE(acpi, mydrv_acpi_match);
  50        #endif
  51
  52        static struct platform_driver my_driver = {
  53                ...
  54                .driver = {
  55                        .acpi_match_table = ACPI_PTR(mydrv_acpi_match),
  56                },
  57        };
  58
  59If the driver needs to perform more complex initialization like getting and
  60configuring GPIOs it can get its ACPI handle and extract this information
  61from ACPI tables.
  62
  63Currently the kernel is not able to automatically determine from which ACPI
  64device it should make the corresponding platform device so we need to add
  65the ACPI device explicitly to acpi_platform_device_ids list defined in
  66drivers/acpi/acpi_platform.c. This limitation is only for the platform
  67devices, SPI and I2C devices are created automatically as described below.
  68
  69DMA support
  70~~~~~~~~~~~
  71DMA controllers enumerated via ACPI should be registered in the system to
  72provide generic access to their resources. For example, a driver that would
  73like to be accessible to slave devices via generic API call
  74dma_request_slave_channel() must register itself at the end of the probe
  75function like this:
  76
  77        err = devm_acpi_dma_controller_register(dev, xlate_func, dw);
  78        /* Handle the error if it's not a case of !CONFIG_ACPI */
  79
  80and implement custom xlate function if needed (usually acpi_dma_simple_xlate()
  81is enough) which converts the FixedDMA resource provided by struct
  82acpi_dma_spec into the corresponding DMA channel. A piece of code for that case
  83could look like:
  84
  85        #ifdef CONFIG_ACPI
  86        struct filter_args {
  87                /* Provide necessary information for the filter_func */
  88                ...
  89        };
  90
  91        static bool filter_func(struct dma_chan *chan, void *param)
  92        {
  93                /* Choose the proper channel */
  94                ...
  95        }
  96
  97        static struct dma_chan *xlate_func(struct acpi_dma_spec *dma_spec,
  98                        struct acpi_dma *adma)
  99        {
 100                dma_cap_mask_t cap;
 101                struct filter_args args;
 102
 103                /* Prepare arguments for filter_func */
 104                ...
 105                return dma_request_channel(cap, filter_func, &args);
 106        }
 107        #else
 108        static struct dma_chan *xlate_func(struct acpi_dma_spec *dma_spec,
 109                        struct acpi_dma *adma)
 110        {
 111                return NULL;
 112        }
 113        #endif
 114
 115dma_request_slave_channel() will call xlate_func() for each registered DMA
 116controller. In the xlate function the proper channel must be chosen based on
 117information in struct acpi_dma_spec and the properties of the controller
 118provided by struct acpi_dma.
 119
 120Clients must call dma_request_slave_channel() with the string parameter that
 121corresponds to a specific FixedDMA resource. By default "tx" means the first
 122entry of the FixedDMA resource array, "rx" means the second entry. The table
 123below shows a layout:
 124
 125        Device (I2C0)
 126        {
 127                ...
 128                Method (_CRS, 0, NotSerialized)
 129                {
 130                        Name (DBUF, ResourceTemplate ()
 131                        {
 132                                FixedDMA (0x0018, 0x0004, Width32bit, _Y48)
 133                                FixedDMA (0x0019, 0x0005, Width32bit, )
 134                        })
 135                ...
 136                }
 137        }
 138
 139So, the FixedDMA with request line 0x0018 is "tx" and next one is "rx" in
 140this example.
 141
 142In robust cases the client unfortunately needs to call
 143acpi_dma_request_slave_chan_by_index() directly and therefore choose the
 144specific FixedDMA resource by its index.
 145
 146SPI serial bus support
 147~~~~~~~~~~~~~~~~~~~~~~
 148Slave devices behind SPI bus have SpiSerialBus resource attached to them.
 149This is extracted automatically by the SPI core and the slave devices are
 150enumerated once spi_register_master() is called by the bus driver.
 151
 152Here is what the ACPI namespace for a SPI slave might look like:
 153
 154        Device (EEP0)
 155        {
 156                Name (_ADR, 1)
 157                Name (_CID, Package() {
 158                        "ATML0025",
 159                        "AT25",
 160                })
 161                ...
 162                Method (_CRS, 0, NotSerialized)
 163                {
 164                        SPISerialBus(1, PolarityLow, FourWireMode, 8,
 165                                ControllerInitiated, 1000000, ClockPolarityLow,
 166                                ClockPhaseFirst, "\\_SB.PCI0.SPI1",)
 167                }
 168                ...
 169
 170The SPI device drivers only need to add ACPI IDs in a similar way than with
 171the platform device drivers. Below is an example where we add ACPI support
 172to at25 SPI eeprom driver (this is meant for the above ACPI snippet):
 173
 174        #ifdef CONFIG_ACPI
 175        static struct acpi_device_id at25_acpi_match[] = {
 176                { "AT25", 0 },
 177                { },
 178        };
 179        MODULE_DEVICE_TABLE(acpi, at25_acpi_match);
 180        #endif
 181
 182        static struct spi_driver at25_driver = {
 183                .driver = {
 184                        ...
 185                        .acpi_match_table = ACPI_PTR(at25_acpi_match),
 186                },
 187        };
 188
 189Note that this driver actually needs more information like page size of the
 190eeprom etc. but at the time writing this there is no standard way of
 191passing those. One idea is to return this in _DSM method like:
 192
 193        Device (EEP0)
 194        {
 195                ...
 196                Method (_DSM, 4, NotSerialized)
 197                {
 198                        Store (Package (6)
 199                        {
 200                                "byte-len", 1024,
 201                                "addr-mode", 2,
 202                                "page-size, 32
 203                        }, Local0)
 204
 205                        // Check UUIDs etc.
 206
 207                        Return (Local0)
 208                }
 209
 210Then the at25 SPI driver can get this configation by calling _DSM on its
 211ACPI handle like:
 212
 213        struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
 214        struct acpi_object_list input;
 215        acpi_status status;
 216
 217        /* Fill in the input buffer */
 218
 219        status = acpi_evaluate_object(ACPI_HANDLE(&spi->dev), "_DSM",
 220                                      &input, &output);
 221        if (ACPI_FAILURE(status))
 222                /* Handle the error */
 223
 224        /* Extract the data here */
 225
 226        kfree(output.pointer);
 227
 228I2C serial bus support
 229~~~~~~~~~~~~~~~~~~~~~~
 230The slaves behind I2C bus controller only need to add the ACPI IDs like
 231with the platform and SPI drivers. However the I2C bus controller driver
 232needs to call acpi_i2c_register_devices() after it has added the adapter.
 233
 234An I2C bus (controller) driver does:
 235
 236        ...
 237        ret = i2c_add_numbered_adapter(adapter);
 238        if (ret)
 239                /* handle error */
 240
 241        of_i2c_register_devices(adapter);
 242        /* Enumerate the slave devices behind this bus via ACPI */
 243        acpi_i2c_register_devices(adapter);
 244
 245Below is an example of how to add ACPI support to the existing mpu3050
 246input driver:
 247
 248        #ifdef CONFIG_ACPI
 249        static struct acpi_device_id mpu3050_acpi_match[] = {
 250                { "MPU3050", 0 },
 251                { },
 252        };
 253        MODULE_DEVICE_TABLE(acpi, mpu3050_acpi_match);
 254        #endif
 255
 256        static struct i2c_driver mpu3050_i2c_driver = {
 257                .driver = {
 258                        .name   = "mpu3050",
 259                        .owner  = THIS_MODULE,
 260                        .pm     = &mpu3050_pm,
 261                        .of_match_table = mpu3050_of_match,
 262                        .acpi_match_table  ACPI_PTR(mpu3050_acpi_match),
 263                },
 264                .probe          = mpu3050_probe,
 265                .remove         = mpu3050_remove,
 266                .id_table       = mpu3050_ids,
 267        };
 268
 269GPIO support
 270~~~~~~~~~~~~
 271ACPI 5 introduced two new resources to describe GPIO connections: GpioIo
 272and GpioInt. These resources are used be used to pass GPIO numbers used by
 273the device to the driver. For example:
 274
 275        Method (_CRS, 0, NotSerialized)
 276        {
 277                Name (SBUF, ResourceTemplate()
 278                {
 279                        ...
 280                        // Used to power on/off the device
 281                        GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
 282                                IoRestrictionOutputOnly, "\\_SB.PCI0.GPI0",
 283                                0x00, ResourceConsumer,,)
 284                        {
 285                                // Pin List
 286                                0x0055
 287                        }
 288
 289                        // Interrupt for the device
 290                        GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone,
 291                                 0x0000, "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer,,)
 292                        {
 293                                // Pin list
 294                                0x0058
 295                        }
 296
 297                        ...
 298
 299                }
 300
 301                Return (SBUF)
 302        }
 303
 304These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0"
 305specifies the path to the controller. In order to use these GPIOs in Linux
 306we need to translate them to the Linux GPIO numbers.
 307
 308The driver can do this by including <linux/acpi_gpio.h> and then calling
 309acpi_get_gpio(path, gpio). This will return the Linux GPIO number or
 310negative errno if there was no translation found.
 311
 312In a simple case of just getting the Linux GPIO number from device
 313resources one can use acpi_get_gpio_by_index() helper function. It takes
 314pointer to the device and index of the GpioIo/GpioInt descriptor in the
 315device resources list. For example:
 316
 317        int gpio_irq, gpio_power;
 318        int ret;
 319
 320        gpio_irq = acpi_get_gpio_by_index(dev, 1, NULL);
 321        if (gpio_irq < 0)
 322                /* handle error */
 323
 324        gpio_power = acpi_get_gpio_by_index(dev, 0, NULL);
 325        if (gpio_power < 0)
 326                /* handle error */
 327
 328        /* Now we can use the GPIO numbers */
 329
 330Other GpioIo parameters must be converted first by the driver to be
 331suitable to the gpiolib before passing them.
 332
 333In case of GpioInt resource an additional call to gpio_to_irq() must be
 334done before calling request_irq().
 335
lxr.linux.no kindly hosted by Redpill Linpro AS, provider of Linux consulting and operations services since 1995.