On Tue, May 29, 2012 at 03:57:18PM +0800, zhangfei gao wrote:

On Tue, May 29, 2012 at 3:33 PM, Russell King - ARM Linux
[off-list ref] wrote:

quoted

On Tue, May 29, 2012 at 10:48:54AM +0530, Vinod Koul wrote:

quoted

On Tue, 2012-05-29 at 13:14 +0800, zhangfei gao wrote:

quoted

When debugging with putting snd_dmaengine_pcm_open to probe or
pcm_new, there is issue.
snd_dmaengine_pcm_open ->
snd_pcm_hw_constraint_integer(substream->runtime,

SNDRV_PCM_HW_PARAM_PERIODS);
The runtime is only exist at runtime.
So if using soc-dmaengine, I am afraid the snd_dmaengine_pcm_open has
to be put in open instead of probe.

I think you got it wrong, the snd_dmaengine_pcm_open needs to be called
from your CPU pcm_open. See other examples how this is used in other
drivers.

But, as I pointed out earlier, there's the issue of using the wrong
struct device to allocate memory for the DMA engine. ?That's something
that my soc-dmaengine.c got _right_, and soc-dmaengine-pcm.c gets _wrong_.

Could you help clarify what's the struct device should be used?
Any example, not find soc-dmaengine.c.
When debug,
rtd->card->snd_card->dev is same as substream->pcm->card->dev, which
we using now.

When your intention is to DMA to/from some memory, that memory _should_
be mapped via the DMA API (or, in the case of dma_alloc_coherent,
allocated) _using_ the device associated with the agent performing the
DMA.

This is so that the DMA API can know whether there's an IOMMU that has
to be programmed for the DMA agent to be able to see the memory, or
whether there's restrictions on the range of RAM which is visible to
the DMA agent.