Changes between Version 2 and Version 3 of dma_device_api

Timestamp:

Jan 26, 2020, 6:40:05 PM (4 years ago)

Author:

alain

Comment:

--

dma_device_api

@@ -9 +9 @@
 The "kernel" API contains two, synchronous and asynchronous, operation types, detailed in section C below.
 
-The '''asynchronous'''  operation is not directly executed by the client thread. The requests are registered in the waiting queue rooted in the DMA chdev descriptor. These requests are actually handled by a dedicated '''server thread''' running in the cluster containing the chdev descriptor, that calls the blocking ''ioc_driver_cmd()'' function for each registered request.
-The driver is supposed to deschedule the server thread to wait the DMA transfer completion.  
+The '''asynchronous'''  operation is not directly executed by the client thread. The requests are registered in the waiting queue rooted in the DMA chdev descriptor. These requests are actually handled by a dedicated server thread running in the cluster containing the DMA chdev descriptor. This server thread calls the blocking ''ioc_driver_cmd()'' function for each registered request. The driver is supposed to deschedule the server thread after launching the DMA transfer, to wait the transfer completion.  
 
-The '''synchronous''' operations does not use the waiting queue, and does not use the server thread. The client thread calls itself the ''dma_driver_cmd()'' blocking function. The driver is supposed to use a polling strategy to wait the DMA transfer completion, without using the DMA_IRQ.. 
+The '''synchronous''' operations does not use the waiting queue, and does not use the server thread. The client thread calls itself the ''dma_driver_cmd()'' blocking function. The driver is supposed to use a polling strategy to wait the DMA transfer completion, without using the DMA_IRQ. 
 
 To access the various drivers, the DMA device defines a lower-level "driver" API, that is detailed in section D below.