Use of tasklets for DMA callbacks.

It is found that tasklets are used for all DMA callbacks by DMA 

engine. The DMA engine's VCH is scheduling the tasklets for the 

Callbacks. 

The reason of doing so looks like the use of shared Interrupts

for all channel by the Dma Engine drivers. If this is not done, 

then it would be difficult to integrate the platform driver with

the DMA engine.

Incase of one IRQ for DMA engine for different channels, it is 

important that tasklet can be interrupted by the IRQ and

it will be scheduled later for the same core, however if the 

tasklet is scheduled in another core then its unlikely that 

the tasklet will be interrupted.Hence in that way with only 

one single IRQ handler we can achieve the abstraction using 

the DMA engine.

However the only disadvantage comes in case of a LinkList DMA 

where the intermittent callbacks of the all the lists

shall not be guaranteed in Hard IRQ context if the tasklet 

is interrupted by any Hard IRQ. Note that this is a case where 

a tasklet runs will the interrupt enabled.

_______________________________

|client driver1, driver2...etc|
|_____________________________|                
       |
       |
 ______|_________
 |              |
 |   DMAengine  |
 |              |
 |              |
 ----------------
       |
       |
       |
 ______|______
 |           |
 |PLatformDMA|-- > IRQ ----- > schedule irq_handler_tasket1 
 |           |           | 
 |           |           |----- > schedule irq_handler_tasklet2 
 ------------- 

                          Fig-1(show the flow)

Reference :-

http://lists.infradead.org/pipermail/linux-arm-kernel/2012-June/103081.html

https://lists.kernelnewbies.org/pipermail/kernelnewbies/2011-November/003812.html

> hi,
> can any one please explain why tasklets cant sleep.softirqs and
> tasklets processing aided by the a set of per processor
> kernel threads(ksoftirqd) so it means tasklets/softirqs run in process
> context. it means tasklet can sleep right?

Generally speaking, tasklets "borrow" the stack of whatever process
happened to be running.

Stepping back a bit, hardware interrupts come along and interrupt
whatever task happened to be running. When the hardware IRQ stack gets
back down to the task level again (i.e. all nested HW IRQs are
processed, then it enabled interrupts and starts any queued tasklets.
So tasklets are really still "interrupt" context, but with interrupts
enabled.

Since the tasklet is borrowing a stack, that process can't run until
the tasklet is finished, so to simplify things no context switches can
occur while tasklets are running.

If your kernel was configured with a separate irq stack, then it's
conceivable that tasklets could run essentially in a thread context.
But because not all architectures implement a separate hw irq stack,
and you want drivers and stuff to be portable, you have to cater to
the lowest common denominator.

If you want your tasklet to run in process context, then use a kernel
thread instead of a tasklet.