Hi,
It appears OMAP ALSA driver does not seem to disable and idle the SDMA
channel on a 'suspend' call. The problem seems to be with the
'omap_stop_dma()' call under 'SNDRV_PCM_TRIGGER_SUSPEND' in
'omap_pcm_trigger()'. ALSA audio driver uses self linking and the
function 'omap_stop_dma()', only unlinks the channels, but DOES NOT
disable an active channel for linked channels.
memset(dma_chan_link_map, 0, sizeof(dma_chan_link_map));
do {
/* The loop case: we've been here already */
if (dma_chan_link_map[cur_lch])
break;
/* Mark the current channel */
dma_chan_link_map[cur_lch] = 1;
disable_lnk(cur_lch);
next_lch = dma_chan[cur_lch].next_lch;
cur_lch = next_lch;
} while (next_lch != -1);
return; <---
}
This means after a return from the 'omap_stop_dma()', there can still
be an active DMA transaction on the channel. Is this the intent Or a
bug? I can think of situations, where in, we may want to complete the
DMA transfer and then disable the channel. In such a case, we need to
wait until the channel is inactive.
The problem with the current implementation is that after the audio
platform trigger (suspend) is called, SOC core calls the CPU DAI
trigger (suspend) and this stops the McBSP. Depending on the current
DMA pointer, this may leave the DMA channel in active state, since DMA
is configured for DEST HW Synchronization and and the this never gets
asserted after the McBSP is stopped..
I see two ways to resolve this issue:
a) Wait after the 'omap_stop_dma()' in audio platform trigger(suspend)
until the DMA channel is inactive (i.e buffer transfer complete). But,
i believe 'trigger' is supposed to be an atomic operation, so we may
need to wait in a worker thread. And we need to flag the McBSP stop
based on DMA transfer completion.
b) Explicitly disable the DMA channel in 'omap_stop_dma().
Option 'b' above may mean losing some data on resume, if we hit 'OFF'
state during suspend. This may not be a big deal for audio (loss of
few secs audio), but for other drivers (ex: USB data file transfer?),
this may not be acceptable. 'Option 'a' means more rework in audio
driver, but no changes in DAM driver and no loss of data.
Current Audio driver also does not seem to support 'OFF' mode during
suspend. It seems to assume that all DMA and McBSP configurations are
retained in a suspend to resume transition.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
