DMA Engine API performance issues
in [Kernel]
|
Prev: mx5: Add USB to Freescale MX51 Babbage
Next: : x86: remove extra bootmem.h from arch/x86/mm/init_64.c
From: melwyn lobo on 14 Apr 2010 02:50 Hello Dan, I have some doubts regarding DMA API usage on its clients for example MMC, ALSA, USB etc. I am going to take example of the ALSA framework. Audio data transfer is initiated in soc_pcm_trigger(). This is called in an atomic context, with spinlock held and irqs disabled. Here most drivers enable data transfer from the MSP peripheral to the audio codec via tx_submit implementation of the DMA engine driver. This enqueues the transaction in an active list which calls for using spinlocks with bottom half disabled. It is in this function when spin_unlock_bh() is called the kernel detects irq's disabled and generates a warning. So the workaround here for ALSA drivers would be to use tasklet or workqueues to defer calling this in an interruptible context, which would cause performance problems (the same function soc_pcm_trigger is called for stoppping the transfer) in cases where the stream has to be repeatedly stopped and started. So the core issue is use of spin_unlock_bh in an atomic context. Workaround for removing the warnings would be: 1. Use spin_lock with irqsave and corresponding unlock function which does not generate a warning in a similar situation. But this could be futile in one case where the tasklet is scheduled from ksoftirqd which could lead to corruption. Also this means the interrupts would be disabled (on the local cpu) till the function executed which is not something desirable. 2. Use local_irq_enable() before calling the DMA APIs and disable once done. This is a crude solution and understandably undesirable and dangerous. The DMA Engine framework assumes that the channel interrupt handling is done in a tasklet (dma_run_dependencies), which I believe is the reason for the issue. Regards, M. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |