Lines Matching refs:a

6   a) Transfers hot queuing
7      A driver submitting a transfer and issuing it should be granted the transfer
8      is queued even on a running DMA channel.
12      A transfer which is submitted and issued on a phy doesn't wait for a phy to
13      stop and restart, but is submitted on a "running channel". The other
15      a new transfer.
18      Any issued transfer with DMA_PREP_INTERRUPT should trigger a callback call.
24      A driver should be able to query if a channel is running or not. For the
25      multimedia case, such as video capture, if a transfer is submitted and then
26      a check of the DMA channel reports a "stopped channel", the transfer should
28      know if a channel is in running or stopped state.
34      A driver should be able to request a priority, especially the real-time
39   a) Virtual channels
40      Same concept as in sa11x0 driver, ie. a driver was assigned a "virtual
44   b) Transfer anatomy for a scatter-gather transfer
54         Transfers a single u32 to a well known dma coherent memory to leave
55         a trace that this transfer is done. The "well known" is unique per
56         physical channel, meaning that a read of this value will tell which
70      After a call to dmaengine_submit(b3), the chain will look like :
87          "align bit" must be set, and the channel restarted As a consequence,
88          such a transfer tx_submit() will be queued on the submitted queue, and
92      Each time a transfer is completed on a channel, an interrupt might be
94      descriptor of a transfer, the "status updater", will write the latest
99      any lock to find out what is the latest completed transfer in a running
103      When a transfer flagged as "DMA_PREP_INTERRUPT" is finished, the dma irq
104      is raised. Upon this interrupt, a tasklet is scheduled for the physical
110      If a transfer is completed while this handling is done, a dma irq will
111      be raised, and the tasklet will be scheduled once again, having a new
122        - a driver submitted an aligned tx1, not chained
123        - a driver submitted an aligned tx2 => tx2 is cold chained to tx1
124        - a driver issued tx1+tx2 => channel is running in aligned mode
125        - a driver submitted an aligned tx3 => tx3 is hot-chained
126        - a driver submitted an unaligned tx4 => tx4 is put in submitted queue,
128        - a driver issued tx4 => tx4 is put in issued queue, not chained
129        - a driver submitted an aligned tx5 => tx5 is put in submitted queue, not
131        - a driver submitted an aligned tx6 => tx6 is put in submitted queue,