blob: b731b292e8128e30439ae54c1f0f328b56e79b72 [file] [log] [blame]
Mika Westerberg59c39872012-12-07 23:11:51 +01001ACPI 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
Mathias Krause1a147ed2015-06-13 14:27:00 +020045 static const struct acpi_device_id mydrv_acpi_match[] = {
Mika Westerberg59c39872012-12-07 23:11:51 +010046 /* 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
Andy Shevchenko1b2e98b2013-04-09 14:05:43 +030063DMA support
64~~~~~~~~~~~
65DMA controllers enumerated via ACPI should be registered in the system to
66provide generic access to their resources. For example, a driver that would
67like to be accessible to slave devices via generic API call
68dma_request_slave_channel() must register itself at the end of the probe
69function like this:
70
71 err = devm_acpi_dma_controller_register(dev, xlate_func, dw);
72 /* Handle the error if it's not a case of !CONFIG_ACPI */
73
74and implement custom xlate function if needed (usually acpi_dma_simple_xlate()
75is enough) which converts the FixedDMA resource provided by struct
76acpi_dma_spec into the corresponding DMA channel. A piece of code for that case
77could look like:
78
79 #ifdef CONFIG_ACPI
80 struct filter_args {
81 /* Provide necessary information for the filter_func */
82 ...
83 };
84
85 static bool filter_func(struct dma_chan *chan, void *param)
86 {
87 /* Choose the proper channel */
88 ...
89 }
90
91 static struct dma_chan *xlate_func(struct acpi_dma_spec *dma_spec,
92 struct acpi_dma *adma)
93 {
94 dma_cap_mask_t cap;
95 struct filter_args args;
96
97 /* Prepare arguments for filter_func */
98 ...
99 return dma_request_channel(cap, filter_func, &args);
100 }
101 #else
102 static struct dma_chan *xlate_func(struct acpi_dma_spec *dma_spec,
103 struct acpi_dma *adma)
104 {
105 return NULL;
106 }
107 #endif
108
109dma_request_slave_channel() will call xlate_func() for each registered DMA
110controller. In the xlate function the proper channel must be chosen based on
111information in struct acpi_dma_spec and the properties of the controller
112provided by struct acpi_dma.
113
114Clients must call dma_request_slave_channel() with the string parameter that
115corresponds to a specific FixedDMA resource. By default "tx" means the first
116entry of the FixedDMA resource array, "rx" means the second entry. The table
117below shows a layout:
118
119 Device (I2C0)
120 {
121 ...
122 Method (_CRS, 0, NotSerialized)
123 {
124 Name (DBUF, ResourceTemplate ()
125 {
126 FixedDMA (0x0018, 0x0004, Width32bit, _Y48)
127 FixedDMA (0x0019, 0x0005, Width32bit, )
128 })
129 ...
130 }
131 }
132
133So, the FixedDMA with request line 0x0018 is "tx" and next one is "rx" in
134this example.
135
136In robust cases the client unfortunately needs to call
137acpi_dma_request_slave_chan_by_index() directly and therefore choose the
138specific FixedDMA resource by its index.
139
Mika Westerberg59c39872012-12-07 23:11:51 +0100140SPI serial bus support
141~~~~~~~~~~~~~~~~~~~~~~
142Slave devices behind SPI bus have SpiSerialBus resource attached to them.
143This is extracted automatically by the SPI core and the slave devices are
144enumerated once spi_register_master() is called by the bus driver.
145
146Here is what the ACPI namespace for a SPI slave might look like:
147
148 Device (EEP0)
149 {
150 Name (_ADR, 1)
151 Name (_CID, Package() {
152 "ATML0025",
153 "AT25",
154 })
155 ...
156 Method (_CRS, 0, NotSerialized)
157 {
158 SPISerialBus(1, PolarityLow, FourWireMode, 8,
159 ControllerInitiated, 1000000, ClockPolarityLow,
160 ClockPhaseFirst, "\\_SB.PCI0.SPI1",)
161 }
162 ...
163
164The SPI device drivers only need to add ACPI IDs in a similar way than with
165the platform device drivers. Below is an example where we add ACPI support
166to at25 SPI eeprom driver (this is meant for the above ACPI snippet):
167
168 #ifdef CONFIG_ACPI
Mathias Krause1a147ed2015-06-13 14:27:00 +0200169 static const struct acpi_device_id at25_acpi_match[] = {
Mika Westerberg59c39872012-12-07 23:11:51 +0100170 { "AT25", 0 },
171 { },
172 };
173 MODULE_DEVICE_TABLE(acpi, at25_acpi_match);
174 #endif
175
176 static struct spi_driver at25_driver = {
177 .driver = {
178 ...
179 .acpi_match_table = ACPI_PTR(at25_acpi_match),
180 },
181 };
182
183Note that this driver actually needs more information like page size of the
184eeprom etc. but at the time writing this there is no standard way of
185passing those. One idea is to return this in _DSM method like:
186
187 Device (EEP0)
188 {
189 ...
190 Method (_DSM, 4, NotSerialized)
191 {
192 Store (Package (6)
193 {
194 "byte-len", 1024,
195 "addr-mode", 2,
196 "page-size, 32
197 }, Local0)
198
199 // Check UUIDs etc.
200
201 Return (Local0)
202 }
203
Stefan Huber2d6674b2013-06-27 12:54:52 +0200204Then the at25 SPI driver can get this configuration by calling _DSM on its
Mika Westerberg59c39872012-12-07 23:11:51 +0100205ACPI handle like:
206
207 struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
208 struct acpi_object_list input;
209 acpi_status status;
210
211 /* Fill in the input buffer */
212
213 status = acpi_evaluate_object(ACPI_HANDLE(&spi->dev), "_DSM",
214 &input, &output);
215 if (ACPI_FAILURE(status))
216 /* Handle the error */
217
218 /* Extract the data here */
219
220 kfree(output.pointer);
221
222I2C serial bus support
223~~~~~~~~~~~~~~~~~~~~~~
224The slaves behind I2C bus controller only need to add the ACPI IDs like
Mika Westerberg55e71ed2013-08-21 17:28:23 +0300225with the platform and SPI drivers. The I2C core automatically enumerates
226any slave devices behind the controller device once the adapter is
227registered.
Mika Westerberg59c39872012-12-07 23:11:51 +0100228
229Below is an example of how to add ACPI support to the existing mpu3050
230input driver:
231
232 #ifdef CONFIG_ACPI
Mathias Krause1a147ed2015-06-13 14:27:00 +0200233 static const struct acpi_device_id mpu3050_acpi_match[] = {
Mika Westerberg59c39872012-12-07 23:11:51 +0100234 { "MPU3050", 0 },
235 { },
236 };
237 MODULE_DEVICE_TABLE(acpi, mpu3050_acpi_match);
238 #endif
239
240 static struct i2c_driver mpu3050_i2c_driver = {
241 .driver = {
242 .name = "mpu3050",
243 .owner = THIS_MODULE,
244 .pm = &mpu3050_pm,
245 .of_match_table = mpu3050_of_match,
Yaowei Baide14da22015-01-15 21:59:16 +0800246 .acpi_match_table = ACPI_PTR(mpu3050_acpi_match),
Mika Westerberg59c39872012-12-07 23:11:51 +0100247 },
248 .probe = mpu3050_probe,
Greg Kroah-Hartman63a29f72012-12-21 15:15:02 -0800249 .remove = mpu3050_remove,
Mika Westerberg59c39872012-12-07 23:11:51 +0100250 .id_table = mpu3050_ids,
251 };
252
253GPIO support
254~~~~~~~~~~~~
255ACPI 5 introduced two new resources to describe GPIO connections: GpioIo
Antonio Ospite2375a212015-04-29 10:37:24 +0200256and GpioInt. These resources can be used to pass GPIO numbers used by
Mika Westerberg56b858d2015-03-17 12:40:12 +0200257the device to the driver. ACPI 5.1 extended this with _DSD (Device
258Specific Data) which made it possible to name the GPIOs among other things.
Mika Westerberg59c39872012-12-07 23:11:51 +0100259
Mika Westerberg56b858d2015-03-17 12:40:12 +0200260For example:
261
262Device (DEV)
263{
Mika Westerberg59c39872012-12-07 23:11:51 +0100264 Method (_CRS, 0, NotSerialized)
265 {
266 Name (SBUF, ResourceTemplate()
267 {
Mika Westerberg12028d22013-04-03 13:56:54 +0300268 ...
269 // Used to power on/off the device
Mika Westerberg59c39872012-12-07 23:11:51 +0100270 GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
271 IoRestrictionOutputOnly, "\\_SB.PCI0.GPI0",
272 0x00, ResourceConsumer,,)
273 {
274 // Pin List
275 0x0055
276 }
Mika Westerberg12028d22013-04-03 13:56:54 +0300277
278 // Interrupt for the device
279 GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone,
280 0x0000, "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer,,)
281 {
282 // Pin list
283 0x0058
284 }
285
Mika Westerberg59c39872012-12-07 23:11:51 +0100286 ...
287
Mika Westerberg59c39872012-12-07 23:11:51 +0100288 }
Mika Westerberg12028d22013-04-03 13:56:54 +0300289
290 Return (SBUF)
Mika Westerberg59c39872012-12-07 23:11:51 +0100291 }
292
Mika Westerberg56b858d2015-03-17 12:40:12 +0200293 // ACPI 5.1 _DSD used for naming the GPIOs
294 Name (_DSD, Package ()
295 {
296 ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
297 Package ()
298 {
299 Package () {"power-gpios", Package() {^DEV, 0, 0, 0 }},
300 Package () {"irq-gpios", Package() {^DEV, 1, 0, 0 }},
301 }
302 })
303 ...
304
Mika Westerberg59c39872012-12-07 23:11:51 +0100305These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0"
306specifies the path to the controller. In order to use these GPIOs in Linux
Mika Westerbergccb6fbb2014-01-08 12:40:57 +0200307we need to translate them to the corresponding Linux GPIO descriptors.
Mika Westerberg59c39872012-12-07 23:11:51 +0100308
Mika Westerbergccb6fbb2014-01-08 12:40:57 +0200309There is a standard GPIO API for that and is documented in
Jarkko Nikula51caa052014-05-21 16:58:25 +0300310Documentation/gpio/.
Mika Westerberg12028d22013-04-03 13:56:54 +0300311
Mika Westerbergccb6fbb2014-01-08 12:40:57 +0200312In the above example we can get the corresponding two GPIO descriptors with
313a code like this:
Mika Westerberg45f39432013-10-10 11:01:11 +0300314
315 #include <linux/gpio/consumer.h>
316 ...
317
318 struct gpio_desc *irq_desc, *power_desc;
319
Mika Westerberg56b858d2015-03-17 12:40:12 +0200320 irq_desc = gpiod_get(dev, "irq");
Mika Westerberg45f39432013-10-10 11:01:11 +0300321 if (IS_ERR(irq_desc))
322 /* handle error */
323
Mika Westerberg56b858d2015-03-17 12:40:12 +0200324 power_desc = gpiod_get(dev, "power");
Mika Westerberg45f39432013-10-10 11:01:11 +0300325 if (IS_ERR(power_desc))
326 /* handle error */
327
328 /* Now we can use the GPIO descriptors */
329
Mika Westerbergccb6fbb2014-01-08 12:40:57 +0200330There are also devm_* versions of these functions which release the
331descriptors once the device is released.
Mika Westerberg6ab34302014-09-16 14:52:36 +0300332
Mika Westerberg56b858d2015-03-17 12:40:12 +0200333See Documentation/acpi/gpio-properties.txt for more information about the
334_DSD binding related to GPIOs.
335
Mika Westerberg6ab34302014-09-16 14:52:36 +0300336MFD devices
337~~~~~~~~~~~
338The MFD devices register their children as platform devices. For the child
339devices there needs to be an ACPI handle that they can use to reference
340parts of the ACPI namespace that relate to them. In the Linux MFD subsystem
341we provide two ways:
342
343 o The children share the parent ACPI handle.
344 o The MFD cell can specify the ACPI id of the device.
345
346For the first case, the MFD drivers do not need to do anything. The
347resulting child platform device will have its ACPI_COMPANION() set to point
348to the parent device.
349
350If the ACPI namespace has a device that we can match using an ACPI id,
351the id should be set like:
352
353 static struct mfd_cell my_subdevice_cell = {
354 .name = "my_subdevice",
355 /* set the resources relative to the parent */
356 .acpi_pnpid = "XYZ0001",
357 };
358
359The ACPI id "XYZ0001" is then used to lookup an ACPI device directly under
360the MFD device and if found, that ACPI companion device is bound to the
361resulting child platform device.
Rafael J. Wysockieb348662015-06-15 13:48:00 +0200362
363Device Tree namespace link device ID
364~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
365The Device Tree protocol uses device indentification based on the "compatible"
366property whose value is a string or an array of strings recognized as device
367identifiers by drivers and the driver core. The set of all those strings may be
368regarded as a device indentification namespace analogous to the ACPI/PNP device
369ID namespace. Consequently, in principle it should not be necessary to allocate
370a new (and arguably redundant) ACPI/PNP device ID for a devices with an existing
371identification string in the Device Tree (DT) namespace, especially if that ID
372is only needed to indicate that a given device is compatible with another one,
373presumably having a matching driver in the kernel already.
374
375In ACPI, the device identification object called _CID (Compatible ID) is used to
376list the IDs of devices the given one is compatible with, but those IDs must
377belong to one of the namespaces prescribed by the ACPI specification (see
378Section 6.1.2 of ACPI 6.0 for details) and the DT namespace is not one of them.
379Moreover, the specification mandates that either a _HID or an _ADR identificaion
380object be present for all ACPI objects representing devices (Section 6.1 of ACPI
3816.0). For non-enumerable bus types that object must be _HID and its value must
382be a device ID from one of the namespaces prescribed by the specification too.
383
384The special DT namespace link device ID, PRP0001, provides a means to use the
385existing DT-compatible device identification in ACPI and to satisfy the above
386requirements following from the ACPI specification at the same time. Namely,
387if PRP0001 is returned by _HID, the ACPI subsystem will look for the
388"compatible" property in the device object's _DSD and will use the value of that
389property to identify the corresponding device in analogy with the original DT
390device identification algorithm. If the "compatible" property is not present
391or its value is not valid, the device will not be enumerated by the ACPI
392subsystem. Otherwise, it will be enumerated automatically as a platform device
393(except when an I2C or SPI link from the device to its parent is present, in
394which case the ACPI core will leave the device enumeration to the parent's
395driver) and the identification strings from the "compatible" property value will
396be used to find a driver for the device along with the device IDs listed by _CID
397(if present).
398
399Analogously, if PRP0001 is present in the list of device IDs returned by _CID,
400the identification strings listed by the "compatible" property value (if present
401and valid) will be used to look for a driver matching the device, but in that
402case their relative priority with respect to the other device IDs listed by
403_HID and _CID depends on the position of PRP0001 in the _CID return package.
404Specifically, the device IDs returned by _HID and preceding PRP0001 in the _CID
405return package will be checked first. Also in that case the bus type the device
406will be enumerated to depends on the device ID returned by _HID.
407
408It is valid to define device objects with a _HID returning PRP0001 and without
409the "compatible" property in the _DSD or a _CID as long as one of their
410ancestors provides a _DSD with a valid "compatible" property. Such device
411objects are then simply regarded as additional "blocks" providing hierarchical
412configuration information to the driver of the composite ancestor device.