[alsa-devel] [PATCH] ASoC: Provide a more complete DMA driver stub
Allow userspace applications to do more parameter setting by providing a more complete stub DMA driver specifying a wildcard set of formats and channels and essentially random values for the DMA parameters. This is required for useful runtime operation of the dummy DMA driver until we are able to figure out how to power up links and do hw_params() from DAPM.
Signed-off-by: Mark Brown broonie@opensource.wolfsonmicro.com --- sound/soc/soc-utils.c | 31 ++++++++++++++++++++++++++++++- 1 files changed, 30 insertions(+), 1 deletions(-)
diff --git a/sound/soc/soc-utils.c b/sound/soc/soc-utils.c index 0c12b98..4220bb0 100644 --- a/sound/soc/soc-utils.c +++ b/sound/soc/soc-utils.c @@ -58,7 +58,36 @@ int snd_soc_params_to_bclk(struct snd_pcm_hw_params *params) } EXPORT_SYMBOL_GPL(snd_soc_params_to_bclk);
-static struct snd_soc_platform_driver dummy_platform; +static const struct snd_pcm_hardware dummy_dma_hardware = { + .formats = 0xffffffff, + .channels_min = 1, + .channels_max = UINT_MAX, + + /* Random values to keep userspace happy when checking constraints */ + .info = SNDRV_PCM_INFO_INTERLEAVED | + SNDRV_PCM_INFO_BLOCK_TRANSFER, + .buffer_bytes_max = 128*1024, + .period_bytes_min = PAGE_SIZE, + .period_bytes_max = PAGE_SIZE*2, + .periods_min = 2, + .periods_max = 128, +}; + +static int dummy_dma_open(struct snd_pcm_substream *substream) +{ + snd_soc_set_runtime_hwparams(substream, &dummy_dma_hardware); + + return 0; +} + +static struct snd_pcm_ops dummy_dma_ops = { + .open = dummy_dma_open, + .ioctl = snd_pcm_lib_ioctl, +}; + +static struct snd_soc_platform_driver dummy_platform = { + .ops = &dummy_dma_ops, +};
static __devinit int snd_soc_dummy_probe(struct platform_device *pdev) {
On Mon, 2011-12-05 at 20:56 +0000, Mark Brown wrote:
Allow userspace applications to do more parameter setting by providing a more complete stub DMA driver specifying a wildcard set of formats and channels and essentially random values for the DMA parameters. This is required for useful runtime operation of the dummy DMA driver until we are able to figure out how to power up links and do hw_params() from DAPM.
Signed-off-by: Mark Brown broonie@opensource.wolfsonmicro.com
Is this also intended to be used for hostless DAI links e.g.
MODEM <-> MCBSP <-> DSP
Regards
Liam
On Mon, Dec 05, 2011 at 10:02:50PM +0000, Liam Girdwood wrote:
On Mon, 2011-12-05 at 20:56 +0000, Mark Brown wrote:
Allow userspace applications to do more parameter setting by providing a more complete stub DMA driver specifying a wildcard set of formats and channels and essentially random values for the DMA parameters. This is required for useful runtime operation of the dummy DMA driver until we are able to figure out how to power up links and do hw_params() from DAPM.
Is this also intended to be used for hostless DAI links e.g.
MODEM <-> MCBSP <-> DSP
It's for any sort of link that doesn't go through a DMA controller the kernel can see - this is the DMA driver that gets stubbed in when the DAI doesn't have a DMA driver. In the case above I guess it depends on if the DMA controller is hidden by the DSP or not.
On 5 December 2011 23:19, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Mon, Dec 05, 2011 at 10:02:50PM +0000, Liam Girdwood wrote:
On Mon, 2011-12-05 at 20:56 +0000, Mark Brown wrote:
Allow userspace applications to do more parameter setting by providing a more complete stub DMA driver specifying a wildcard set of formats and channels and essentially random values for the DMA parameters. This is required for useful runtime operation of the dummy DMA driver until we are able to figure out how to power up links and do hw_params() from DAPM.
Is this also intended to be used for hostless DAI links e.g.
MODEM <-> MCBSP <-> DSP
It's for any sort of link that doesn't go through a DMA controller the kernel can see - this is the DMA driver that gets stubbed in when the DAI doesn't have a DMA driver. In the case above I guess it depends on if the DMA controller is hidden by the DSP or not.
Ok, that's what I was thinking.
Acked-by: Liam Girdwood lrg@ti.com
participants (3)
-
Girdwood, Liam
-
Liam Girdwood
-
Mark Brown