aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/acpi
diff options
context:
space:
mode:
authorAndy Shevchenko <andriy.shevchenko@linux.intel.com>2013-04-09 07:05:43 -0400
committerVinod Koul <vinod.koul@intel.com>2013-04-15 12:34:10 -0400
commit1b2e98bc1e35ebe1f65c3db62c8317096ad7f2c8 (patch)
tree326e1f7e6f311f1107f27eb048d521e880944360 /Documentation/acpi
parenteceec44ecd7f3285468a684e7216df2316b178f3 (diff)
dma: acpi-dma: introduce ACPI DMA helpers
There is a new generic API to get a DMA channel for a slave device (commit 9a6cecc8 "dmaengine: add helper function to request a slave DMA channel"). In similar fashion to the DT case (commit aa3da644 "of: Add generic device tree DMA helpers") we introduce helpers to the DMAC drivers which are enumerated by ACPI. The proposed extension provides the following API calls: acpi_dma_controller_register(), devm_acpi_dma_controller_register() acpi_dma_controller_free(), devm_acpi_dma_controller_free() acpi_dma_simple_xlate() acpi_dma_request_slave_chan_by_index() acpi_dma_request_slave_chan_by_name() The first two should be used, for example, at probe() and remove() of the corresponding DMAC driver. At the register stage the DMAC driver supplies a custom xlate() function to translate a struct dma_spec into struct dma_chan. Accordingly to the ACPI Fixed DMA resource specification the only two pieces of information the slave device has are the channel id and the request line (slave id). Those two are represented by struct dma_spec. The acpi_dma_request_slave_chan_by_index() provides access to the specifix FixedDMA resource by its index. Whereas dma_request_slave_channel() takes a string parameter to identify the DMA resources required by the slave device. To make a slave device driver work with both DeviceTree and ACPI enumeration a simple convention is established: "tx" corresponds to the index 0 and "rx" to the index 1. In case of robust configuration the slave device driver unfortunately needs to call acpi_dma_request_slave_chan_by_index() directly. Additionally the patch provides "managed" version of the register/free pair i.e. devm_acpi_dma_controller_register() and devm_acpi_dma_controller_free(). Usually, the driver uses only devm_acpi_dma_controller_register(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Diffstat (limited to 'Documentation/acpi')
-rw-r--r--Documentation/acpi/enumeration.txt77
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
66drivers/acpi/acpi_platform.c. This limitation is only for the platform 66drivers/acpi/acpi_platform.c. This limitation is only for the platform
67devices, SPI and I2C devices are created automatically as described below. 67devices, SPI and I2C devices are created automatically as described below.
68 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
69SPI serial bus support 146SPI serial bus support
70~~~~~~~~~~~~~~~~~~~~~~ 147~~~~~~~~~~~~~~~~~~~~~~
71Slave devices behind SPI bus have SpiSerialBus resource attached to them. 148Slave devices behind SPI bus have SpiSerialBus resource attached to them.