diff options
author | Maxime Ripard <maxime.ripard@free-electrons.com> | 2014-11-17 08:42:55 -0500 |
---|---|---|
committer | Vinod Koul <vinod.koul@intel.com> | 2014-12-22 02:04:22 -0500 |
commit | 1faab1f2e3be3a10197840648d03a31fd0a29e93 (patch) | |
tree | 49e303cadf1197f00161c9371abe3326790f24bf | |
parent | 2c44ad914c56f4e53ef43285b5e4fe3459109769 (diff) |
Documentation: dmaengine: Update the documentation
Now that we have splitted device_control and removed device_slave_caps in favor
of a few dma_device variables, update the documentation accordingly.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
-rw-r--r-- | Documentation/dmaengine/provider.txt | 93 |
1 files changed, 51 insertions, 42 deletions
diff --git a/Documentation/dmaengine/provider.txt b/Documentation/dmaengine/provider.txt index 766658ccf235..2c391cfe37eb 100644 --- a/Documentation/dmaengine/provider.txt +++ b/Documentation/dmaengine/provider.txt | |||
@@ -113,6 +113,31 @@ need to initialize a few fields in there: | |||
113 | * channels: should be initialized as a list using the | 113 | * channels: should be initialized as a list using the |
114 | INIT_LIST_HEAD macro for example | 114 | INIT_LIST_HEAD macro for example |
115 | 115 | ||
116 | * src_addr_widths: | ||
117 | - should contain a bitmask of the supported source transfer width | ||
118 | |||
119 | * dst_addr_widths: | ||
120 | - should contain a bitmask of the supported destination transfer | ||
121 | width | ||
122 | |||
123 | * directions: | ||
124 | - should contain a bitmask of the supported slave directions | ||
125 | (i.e. excluding mem2mem transfers) | ||
126 | |||
127 | * residue_granularity: | ||
128 | - Granularity of the transfer residue reported to dma_set_residue. | ||
129 | - This can be either: | ||
130 | + Descriptor | ||
131 | -> Your device doesn't support any kind of residue | ||
132 | reporting. The framework will only know that a particular | ||
133 | transaction descriptor is done. | ||
134 | + Segment | ||
135 | -> Your device is able to report which chunks have been | ||
136 | transferred | ||
137 | + Burst | ||
138 | -> Your device is able to report which burst have been | ||
139 | transferred | ||
140 | |||
116 | * dev: should hold the pointer to the struct device associated | 141 | * dev: should hold the pointer to the struct device associated |
117 | to your current driver instance. | 142 | to your current driver instance. |
118 | 143 | ||
@@ -274,48 +299,32 @@ supported. | |||
274 | account the current period. | 299 | account the current period. |
275 | - This function can be called in an interrupt context. | 300 | - This function can be called in an interrupt context. |
276 | 301 | ||
277 | * device_control | 302 | * device_config |
278 | - Used by client drivers to control and configure the channel it | 303 | - Reconfigures the channel with the configuration given as |
279 | has a handle on. | 304 | argument |
280 | - Called with a command and an argument | 305 | - This command should NOT perform synchronously, or on any |
281 | + The command is one of the values listed by the enum | 306 | currently queued transfers, but only on subsequent ones |
282 | dma_ctrl_cmd. The valid commands are: | 307 | - In this case, the function will receive a dma_slave_config |
283 | + DMA_PAUSE | 308 | structure pointer as an argument, that will detail which |
284 | + Pauses a transfer on the channel | 309 | configuration to use. |
285 | + This command should operate synchronously on the channel, | 310 | - Even though that structure contains a direction field, this |
286 | pausing right away the work of the given channel | 311 | field is deprecated in favor of the direction argument given to |
287 | + DMA_RESUME | 312 | the prep_* functions |
288 | + Restarts a transfer on the channel | 313 | |
289 | + This command should operate synchronously on the channel, | 314 | * device_pause |
290 | resuming right away the work of the given channel | 315 | - Pauses a transfer on the channel |
291 | + DMA_TERMINATE_ALL | 316 | - This command should operate synchronously on the channel, |
292 | + Aborts all the pending and ongoing transfers on the | 317 | pausing right away the work of the given channel |
293 | channel | 318 | |
294 | + This command should operate synchronously on the channel, | 319 | * device_resume |
295 | terminating right away all the channels | 320 | - Resumes a transfer on the channel |
296 | + DMA_SLAVE_CONFIG | 321 | - This command should operate synchronously on the channel, |
297 | + Reconfigures the channel with passed configuration | 322 | pausing right away the work of the given channel |
298 | + This command should NOT perform synchronously, or on any | 323 | |
299 | currently queued transfers, but only on subsequent ones | 324 | * device_terminate_all |
300 | + In this case, the function will receive a | 325 | - Aborts all the pending and ongoing transfers on the channel |
301 | dma_slave_config structure pointer as an argument, that | 326 | - This command should operate synchronously on the channel, |
302 | will detail which configuration to use. | 327 | terminating right away all the channels |
303 | + Even though that structure contains a direction field, | ||
304 | this field is deprecated in favor of the direction | ||
305 | argument given to the prep_* functions | ||
306 | + FSLDMA_EXTERNAL_START | ||
307 | + TODO: Why does that even exist? | ||
308 | + The argument is an opaque unsigned long. This actually is a | ||
309 | pointer to a struct dma_slave_config that should be used only | ||
310 | in the DMA_SLAVE_CONFIG. | ||
311 | |||
312 | * device_slave_caps | ||
313 | - Called through the framework by client drivers in order to have | ||
314 | an idea of what are the properties of the channel allocated to | ||
315 | them. | ||
316 | - Such properties are the buswidth, available directions, etc. | ||
317 | - Required for every generic layer doing DMA transfers, such as | ||
318 | ASoC. | ||
319 | 328 | ||
320 | Misc notes (stuff that should be documented, but don't really know | 329 | Misc notes (stuff that should be documented, but don't really know |
321 | where to put them) | 330 | where to put them) |