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 linux@arm.linux.org.uk wrote:
On Tue, May 29, 2012 at 10:48:54AM +0530, Vinod Koul wrote:
On Tue, 2012-05-29 at 13:14 +0800, zhangfei gao wrote:
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. -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html