| Message ID | 1361978748-25281-10-git-send-email-shawn.guo@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wednesday 27 February 2013, Shawn Guo wrote: > With generic DMA device tree binding and helper function > dma_request_slave_channel() in place, dmaengine_pcm should support > that in requesting DMA channel for users that support generic DMA > device tree binding. > > Instead of inventing a new API, it defines the parameters needed by > dma_request_slave_channel() into struct snd_dma_channel_params, > interprets filter_data into snd_dma_channel_params, and calls the > helper in case that dmaengine_pcm users pass in a NULL filter_fn. > > Then, dmaengine_pcm users can call snd_dmaengine_pcm_open() with NULL > filter_fn and snd_dma_channel_params being filter_data to direct the > API to request DMA channel using generic DMA helper. > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org> > Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> > Cc: alsa-devel@alsa-project.org I would actually prefer having a new API in the soc-dmaengine-pcm module, like static int dmaengine_pcm_request_slave_channel(struct dmaengine_pcm_runtime_data *prtd, struct device *dev, const char *id); For sound drivers that are fully converted to using DT, it would be a more natural interface to use IMHO. Your patch looks technically correct though, so it's up to Mark to decide what he prefers. Arnd
On Wed, Feb 27, 2013 at 09:02:40PM +0000, Arnd Bergmann wrote: > On Wednesday 27 February 2013, Shawn Guo wrote: > > With generic DMA device tree binding and helper function > > dma_request_slave_channel() in place, dmaengine_pcm should support > > that in requesting DMA channel for users that support generic DMA > > device tree binding. > > > > Instead of inventing a new API, it defines the parameters needed by > > dma_request_slave_channel() into struct snd_dma_channel_params, > > interprets filter_data into snd_dma_channel_params, and calls the > > helper in case that dmaengine_pcm users pass in a NULL filter_fn. > > > > Then, dmaengine_pcm users can call snd_dmaengine_pcm_open() with NULL > > filter_fn and snd_dma_channel_params being filter_data to direct the > > API to request DMA channel using generic DMA helper. > > > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org> > > Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> > > Cc: alsa-devel@alsa-project.org > > I would actually prefer having a new API in the soc-dmaengine-pcm > module, like > > static int dmaengine_pcm_request_slave_channel(struct dmaengine_pcm_runtime_data *prtd, > struct device *dev, const char *id); > > For sound drivers that are fully converted to using DT, it would be > a more natural interface to use IMHO. > Ok, let's do this. While my patch saves a new API, it adds a new struct anyway, which I'm not happy with. Shawn
On Wed, Feb 27, 2013 at 09:02:40PM +0000, Arnd Bergmann wrote: > I would actually prefer having a new API in the soc-dmaengine-pcm > module, like > static int dmaengine_pcm_request_slave_channel(struct dmaengine_pcm_runtime_data *prtd, > struct device *dev, const char *id); > For sound drivers that are fully converted to using DT, it would be > a more natural interface to use IMHO. Yes, please.
On Wed, Feb 27, 2013 at 09:02:40PM +0000, Arnd Bergmann wrote: > On Wednesday 27 February 2013, Shawn Guo wrote: > > With generic DMA device tree binding and helper function > > dma_request_slave_channel() in place, dmaengine_pcm should support > > that in requesting DMA channel for users that support generic DMA > > device tree binding. > > > > Instead of inventing a new API, it defines the parameters needed by > > dma_request_slave_channel() into struct snd_dma_channel_params, > > interprets filter_data into snd_dma_channel_params, and calls the > > helper in case that dmaengine_pcm users pass in a NULL filter_fn. > > > > Then, dmaengine_pcm users can call snd_dmaengine_pcm_open() with NULL > > filter_fn and snd_dma_channel_params being filter_data to direct the > > API to request DMA channel using generic DMA helper. > > > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org> > > Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> > > Cc: alsa-devel@alsa-project.org > > I would actually prefer having a new API in the soc-dmaengine-pcm > module, like > > static int dmaengine_pcm_request_slave_channel(struct dmaengine_pcm_runtime_data *prtd, > struct device *dev, const char *id); > > For sound drivers that are fully converted to using DT, it would be > a more natural interface to use IMHO. Just to be clear, if we choose to have a new API, it's not the above one but something like int snd_dmaengine_generic_pcm_open(struct snd_pcm_substream *substream, struct device *dev, const char *id) as snd_dmaengine_pcm_open() is the interface to soc-dmaengine-pcm clients, not dmaengine_pcm_request_channel(). Shawn
diff --git a/include/sound/dmaengine_pcm.h b/include/sound/dmaengine_pcm.h index b877334..6c0f795 100644 --- a/include/sound/dmaengine_pcm.h +++ b/include/sound/dmaengine_pcm.h @@ -18,6 +18,11 @@ #include <sound/pcm.h> #include <linux/dmaengine.h> +struct snd_dma_channel_params { + struct device *dev; + char *name; +}; + /** * snd_pcm_substream_to_dma_direction - Get dma_transfer_direction for a PCM * substream diff --git a/sound/soc/soc-dmaengine-pcm.c b/sound/soc/soc-dmaengine-pcm.c index 111b7d92..7ef8034 100644 --- a/sound/soc/soc-dmaengine-pcm.c +++ b/sound/soc/soc-dmaengine-pcm.c @@ -247,12 +247,19 @@ EXPORT_SYMBOL_GPL(snd_dmaengine_pcm_pointer); static int dmaengine_pcm_request_channel(struct dmaengine_pcm_runtime_data *prtd, dma_filter_fn filter_fn, void *filter_data) { - dma_cap_mask_t mask; - - dma_cap_zero(mask); - dma_cap_set(DMA_SLAVE, mask); - dma_cap_set(DMA_CYCLIC, mask); - prtd->dma_chan = dma_request_channel(mask, filter_fn, filter_data); + if (filter_fn) { + dma_cap_mask_t mask; + + dma_cap_zero(mask); + dma_cap_set(DMA_SLAVE, mask); + dma_cap_set(DMA_CYCLIC, mask); + prtd->dma_chan = dma_request_channel(mask, filter_fn, + filter_data); + } else { + struct snd_dma_channel_params *params = filter_data; + prtd->dma_chan = dma_request_slave_channel(params->dev, + params->name); + } if (!prtd->dma_chan) return -ENXIO;
With generic DMA device tree binding and helper function dma_request_slave_channel() in place, dmaengine_pcm should support that in requesting DMA channel for users that support generic DMA device tree binding. Instead of inventing a new API, it defines the parameters needed by dma_request_slave_channel() into struct snd_dma_channel_params, interprets filter_data into snd_dma_channel_params, and calls the helper in case that dmaengine_pcm users pass in a NULL filter_fn. Then, dmaengine_pcm users can call snd_dmaengine_pcm_open() with NULL filter_fn and snd_dma_channel_params being filter_data to direct the API to request DMA channel using generic DMA helper. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Cc: alsa-devel@alsa-project.org --- include/sound/dmaengine_pcm.h | 5 +++++ sound/soc/soc-dmaengine-pcm.c | 19 +++++++++++++------ 2 files changed, 18 insertions(+), 6 deletions(-)