On Thursday 07 February 2013 14:18:05 Peter Ujfalusi wrote: > I looked briefly around in the mentioned code and I wonder how this is going > to work with audio (ASoC). > When we boot with DT it looks like we are _not_ creating the DMA resources for > the device as it is done for the IRQ and IO/MEM. So this means that we can not > use get_resource*() for DMA anymore when we move to DT. Yes, this is very much intentional. The use of DMA resources is not really possible across platforms, and I would like to kill it off entirely, as it is not clearly defined what they actually mean. In many cases, a single number cannot express the configuration for a DMA channel, e.g. when you have multiple DMA engines in the system, or you have one that can drive multiple masters for instance. While we could in theory extend the infrastructure around DMA resources to behave like IRQ resources, which can deal with all of that, this would require a lot of code, and go against the trend: in case of GPIO numbers and IRQ numbers, people are generally trying to find ways to get rid of a flat number space and use a more structured interface. > This might be OK for (OMAP)mmc, (OMAP)spi, etc. But in audio we have a common > library used by all platforms to deal with the dmaengine. > > I don't think we can switch to use dma_request_slave_channel_compat() in > soc-dmaengine-pcm.c. We need to pass the dma channel number to the lib from > the ASoC platform drivers. Or we need to synchronize the order of the dmas and > the dma-names around all SOCs in existence? > > Has anyone thought about this? It's the first time I look at the sounds specific portion of this, but it seems straightforward: snd_dmaengine_pcm_open is a wrapper around dma_request_channel and requires a filter function plus data as arguments. We don't want to use filter functions here any more because they don't do what we need, so the logical conclusion is to add a similar wrapper around dma_request_slave_channel, and port drivers to use that instead. I see no connection in ASoC between the use of IORESOURCE_DMA and snd_dmaengine_pcm_open. About half of the drivers calling that function get the argument from a dma resource, while the other ones don't. Similarly, not all ASoC drivers using DMA resources pass the contents of that into snd_dmaengine_pcm_open. Arnd -- 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
