diff options
Diffstat (limited to 'Documentation/acpi')
-rw-r--r-- | Documentation/acpi/enumeration.txt | 77 |
1 files changed, 77 insertions, 0 deletions
diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index 94a656131885..2874c904f3ef 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt | |||
@@ -66,6 +66,83 @@ the ACPI device explicitly to acpi_platform_device_ids list defined in | |||
66 | drivers/acpi/acpi_platform.c. This limitation is only for the platform | 66 | drivers/acpi/acpi_platform.c. This limitation is only for the platform |
67 | devices, SPI and I2C devices are created automatically as described below. | 67 | devices, SPI and I2C devices are created automatically as described below. |
68 | 68 | ||
69 | DMA support | ||
70 | ~~~~~~~~~~~ | ||
71 | DMA controllers enumerated via ACPI should be registered in the system to | ||
72 | provide generic access to their resources. For example, a driver that would | ||
73 | like to be accessible to slave devices via generic API call | ||
74 | dma_request_slave_channel() must register itself at the end of the probe | ||
75 | function 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 | |||
80 | and implement custom xlate function if needed (usually acpi_dma_simple_xlate() | ||
81 | is enough) which converts the FixedDMA resource provided by struct | ||
82 | acpi_dma_spec into the corresponding DMA channel. A piece of code for that case | ||
83 | could 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 | |||
115 | dma_request_slave_channel() will call xlate_func() for each registered DMA | ||
116 | controller. In the xlate function the proper channel must be chosen based on | ||
117 | information in struct acpi_dma_spec and the properties of the controller | ||
118 | provided by struct acpi_dma. | ||
119 | |||
120 | Clients must call dma_request_slave_channel() with the string parameter that | ||
121 | corresponds to a specific FixedDMA resource. By default "tx" means the first | ||
122 | entry of the FixedDMA resource array, "rx" means the second entry. The table | ||
123 | below 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 | |||
139 | So, the FixedDMA with request line 0x0018 is "tx" and next one is "rx" in | ||
140 | this example. | ||
141 | |||
142 | In robust cases the client unfortunately needs to call | ||
143 | acpi_dma_request_slave_chan_by_index() directly and therefore choose the | ||
144 | specific FixedDMA resource by its index. | ||
145 | |||
69 | SPI serial bus support | 146 | SPI serial bus support |
70 | ~~~~~~~~~~~~~~~~~~~~~~ | 147 | ~~~~~~~~~~~~~~~~~~~~~~ |
71 | Slave devices behind SPI bus have SpiSerialBus resource attached to them. | 148 | Slave devices behind SPI bus have SpiSerialBus resource attached to them. |