[alsa-devel] [PATCH v2 01/11] ASoC: dpcm: Add helper function for initializing runtime pcm
We have the same code for initializing the runtime pcm on both the playback and the capture path. Factor this out into a common helper function.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de Cc: Jean-Francois Moine moinejf@free.fr --- New in v2 --- sound/soc/soc-pcm.c | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 604e7e9..898149e 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -1235,6 +1235,17 @@ unwind: return err; }
+static void dpcm_init_runtime_hw(struct snd_pcm_runtime *runtime, + struct snd_soc_pcm_stream *stream) +{ + runtime->hw.rate_min = stream->rate_min; + runtime->hw.rate_max = stream->rate_max; + runtime->hw.channels_min = stream->channels_min; + runtime->hw.channels_max = stream->channels_max; + runtime->hw.formats &= stream->formats; + runtime->hw.rates = stream->rates; +} + static void dpcm_set_fe_runtime(struct snd_pcm_substream *substream) { struct snd_pcm_runtime *runtime = substream->runtime; @@ -1242,21 +1253,10 @@ static void dpcm_set_fe_runtime(struct snd_pcm_substream *substream) struct snd_soc_dai *cpu_dai = rtd->cpu_dai; struct snd_soc_dai_driver *cpu_dai_drv = cpu_dai->driver;
- if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { - runtime->hw.rate_min = cpu_dai_drv->playback.rate_min; - runtime->hw.rate_max = cpu_dai_drv->playback.rate_max; - runtime->hw.channels_min = cpu_dai_drv->playback.channels_min; - runtime->hw.channels_max = cpu_dai_drv->playback.channels_max; - runtime->hw.formats &= cpu_dai_drv->playback.formats; - runtime->hw.rates = cpu_dai_drv->playback.rates; - } else { - runtime->hw.rate_min = cpu_dai_drv->capture.rate_min; - runtime->hw.rate_max = cpu_dai_drv->capture.rate_max; - runtime->hw.channels_min = cpu_dai_drv->capture.channels_min; - runtime->hw.channels_max = cpu_dai_drv->capture.channels_max; - runtime->hw.formats &= cpu_dai_drv->capture.formats; - runtime->hw.rates = cpu_dai_drv->capture.rates; - } + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + dpcm_init_runtime_hw(runtime, &cpu_dai_drv->playback); + else + dpcm_init_runtime_hw(runtime, &cpu_dai_drv->capture); }
static int dpcm_fe_dai_startup(struct snd_pcm_substream *fe_substream)
Allow PCMs that do not impose any restrictions on the supported formats to set the formats field to 0, Instead of assuming that this means that the PCM does not support any formats (which doesn't make much sense), assume that it supports all formats. This brings the behavior of DPCM closer to that of non-DPCM.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de Cc: Jean-Francois Moine moinejf@free.fr --- New in v2 --- sound/soc/soc-pcm.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 898149e..86b670e 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -1242,7 +1242,10 @@ static void dpcm_init_runtime_hw(struct snd_pcm_runtime *runtime, runtime->hw.rate_max = stream->rate_max; runtime->hw.channels_min = stream->channels_min; runtime->hw.channels_max = stream->channels_max; - runtime->hw.formats &= stream->formats; + if (runtime->hw.formats) + runtime->hw.formats &= stream->formats; + else + runtime->hw.formats = stream->formats; runtime->hw.rates = stream->rates; }
On Mon, Jan 06, 2014 at 02:19:07PM +0100, Lars-Peter Clausen wrote:
Allow PCMs that do not impose any restrictions on the supported formats to set the formats field to 0, Instead of assuming that this means that the PCM does not support any formats (which doesn't make much sense), assume that it supports all formats. This brings the behavior of DPCM closer to that of non-DPCM.
Applied, thanks.
The ASoC core assumes that the PCM component of the ASoC card transparently moves data around and does not impose any restrictions on the memory layout or the transfer speed. It ignores all fields from the snd_pcm_hardware struct for the PCM driver that are related to this. Setting these fields in the PCM driver might suggest otherwise though, so rather not set them.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de Acked-by: Bo Shen voice.shen@atmel.com Cc: Nicolas Ferre nicolas.ferre@atmel.com --- No changes in v2 --- sound/soc/atmel/atmel-pcm-dma.c | 1 - sound/soc/atmel/atmel-pcm-pdc.c | 1 - 2 files changed, 2 deletions(-)
diff --git a/sound/soc/atmel/atmel-pcm-dma.c b/sound/soc/atmel/atmel-pcm-dma.c index 06082e5..b79a2a8 100644 --- a/sound/soc/atmel/atmel-pcm-dma.c +++ b/sound/soc/atmel/atmel-pcm-dma.c @@ -50,7 +50,6 @@ static const struct snd_pcm_hardware atmel_pcm_dma_hardware = { SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_RESUME | SNDRV_PCM_INFO_PAUSE, - .formats = SNDRV_PCM_FMTBIT_S16_LE, .period_bytes_min = 256, /* lighting DMA overhead */ .period_bytes_max = 2 * 0xffff, /* if 2 bytes format */ .periods_min = 8, diff --git a/sound/soc/atmel/atmel-pcm-pdc.c b/sound/soc/atmel/atmel-pcm-pdc.c index 054ea4d..33ec592 100644 --- a/sound/soc/atmel/atmel-pcm-pdc.c +++ b/sound/soc/atmel/atmel-pcm-pdc.c @@ -58,7 +58,6 @@ static const struct snd_pcm_hardware atmel_pcm_hardware = { SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_PAUSE, - .formats = SNDRV_PCM_FMTBIT_S16_LE, .period_bytes_min = 32, .period_bytes_max = 8192, .periods_min = 2,
The ASoC core assumes that the PCM component of the ASoC card transparently moves data around and does not impose any restrictions on the memory layout or the transfer speed. It ignores all fields from the snd_pcm_hardware struct for the PCM driver that are related to this. Setting these fields in the PCM driver might suggest otherwise though, so rather not set them.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de Cc: Timur Tabi timur@tabi.org Cc: Shawn Guo shawn.guo@linaro.org Cc: Nicolin Chen b42378@freescale.com Cc: Markus Pargmann mpa@pengutronix.de --- Changes since v1: * Don't clear supported formats field, as formats supported by the DMA are more restrictive than those supported by DAI. Note that this won't have any effect though until the last patch in this series has been applied --- sound/soc/fsl/fsl_dma.c | 7 ------- sound/soc/fsl/imx-pcm-dma.c | 3 --- sound/soc/fsl/imx-pcm-fiq.c | 3 --- sound/soc/fsl/mpc5200_dma.c | 4 ---- 4 files changed, 17 deletions(-)
diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c index d570f8c..6bb0ea5 100644 --- a/sound/soc/fsl/fsl_dma.c +++ b/sound/soc/fsl/fsl_dma.c @@ -55,10 +55,6 @@ SNDRV_PCM_FMTBIT_S32_BE | \ SNDRV_PCM_FMTBIT_U32_LE | \ SNDRV_PCM_FMTBIT_U32_BE) - -#define FSLDMA_PCM_RATES (SNDRV_PCM_RATE_5512 | SNDRV_PCM_RATE_8000_192000 | \ - SNDRV_PCM_RATE_CONTINUOUS) - struct dma_object { struct snd_soc_platform_driver dai; dma_addr_t ssi_stx_phys; @@ -140,9 +136,6 @@ static const struct snd_pcm_hardware fsl_dma_hardware = { SNDRV_PCM_INFO_JOINT_DUPLEX | SNDRV_PCM_INFO_PAUSE, .formats = FSLDMA_PCM_FORMATS, - .rates = FSLDMA_PCM_RATES, - .rate_min = 5512, - .rate_max = 192000, .period_bytes_min = 512, /* A reasonable limit */ .period_bytes_max = (u32) -1, .periods_min = NUM_DMA_LINKS, diff --git a/sound/soc/fsl/imx-pcm-dma.c b/sound/soc/fsl/imx-pcm-dma.c index c5e47f8..2585ae4 100644 --- a/sound/soc/fsl/imx-pcm-dma.c +++ b/sound/soc/fsl/imx-pcm-dma.c @@ -41,9 +41,6 @@ static const struct snd_pcm_hardware imx_pcm_hardware = { SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME, .formats = SNDRV_PCM_FMTBIT_S16_LE, - .rate_min = 8000, - .channels_min = 2, - .channels_max = 2, .buffer_bytes_max = IMX_SSI_DMABUF_SIZE, .period_bytes_min = 128, .period_bytes_max = 65535, /* Limited by SDMA engine */ diff --git a/sound/soc/fsl/imx-pcm-fiq.c b/sound/soc/fsl/imx-pcm-fiq.c index c75d43b..6553202 100644 --- a/sound/soc/fsl/imx-pcm-fiq.c +++ b/sound/soc/fsl/imx-pcm-fiq.c @@ -162,9 +162,6 @@ static struct snd_pcm_hardware snd_imx_hardware = { SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME, .formats = SNDRV_PCM_FMTBIT_S16_LE, - .rate_min = 8000, - .channels_min = 2, - .channels_max = 2, .buffer_bytes_max = IMX_SSI_DMABUF_SIZE, .period_bytes_min = 128, .period_bytes_max = 16 * 1024, diff --git a/sound/soc/fsl/mpc5200_dma.c b/sound/soc/fsl/mpc5200_dma.c index 71bf2f2..f2b5d75 100644 --- a/sound/soc/fsl/mpc5200_dma.c +++ b/sound/soc/fsl/mpc5200_dma.c @@ -200,10 +200,6 @@ static const struct snd_pcm_hardware psc_dma_hardware = { SNDRV_PCM_INFO_BATCH, .formats = SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S32_BE, - .rate_min = 8000, - .rate_max = 48000, - .channels_min = 1, - .channels_max = 2, .period_bytes_max = 1024 * 1024, .period_bytes_min = 32, .periods_min = 2,
On Mon, Jan 06, 2014 at 02:19:09PM +0100, Lars-Peter Clausen wrote:
The ASoC core assumes that the PCM component of the ASoC card transparently moves data around and does not impose any restrictions on the memory layout or the transfer speed. It ignores all fields from the snd_pcm_hardware struct for the PCM driver that are related to this. Setting these fields in the PCM driver might suggest otherwise though, so rather not set them.
Applied, thanks.
The ASoC core assumes that the PCM component of the ASoC card transparently moves data around and does not impose any restrictions on the memory layout or the transfer speed. It ignores all fields from the snd_pcm_hardware struct for the PCM driver that are related to this. Setting these fields in the PCM driver might suggest otherwise though, so rather not set them.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de Cc: Vinod Koul vinod.koul@linux.intel.com --- No changes since v1 --- sound/soc/intel/sst_platform.c | 10 ---------- sound/soc/intel/sst_platform.h | 4 ---- 2 files changed, 14 deletions(-)
diff --git a/sound/soc/intel/sst_platform.c b/sound/soc/intel/sst_platform.c index b6b5eb6..f465a81 100644 --- a/sound/soc/intel/sst_platform.c +++ b/sound/soc/intel/sst_platform.c @@ -89,16 +89,6 @@ static struct snd_pcm_hardware sst_platform_pcm_hw = { SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_SYNC_START), - .formats = (SNDRV_PCM_FMTBIT_S16 | SNDRV_PCM_FMTBIT_U16 | - SNDRV_PCM_FMTBIT_S24 | SNDRV_PCM_FMTBIT_U24 | - SNDRV_PCM_FMTBIT_S32 | SNDRV_PCM_FMTBIT_U32), - .rates = (SNDRV_PCM_RATE_8000| - SNDRV_PCM_RATE_44100 | - SNDRV_PCM_RATE_48000), - .rate_min = SST_MIN_RATE, - .rate_max = SST_MAX_RATE, - .channels_min = SST_MIN_CHANNEL, - .channels_max = SST_MAX_CHANNEL, .buffer_bytes_max = SST_MAX_BUFFER, .period_bytes_min = SST_MIN_PERIOD_BYTES, .period_bytes_max = SST_MAX_PERIOD_BYTES, diff --git a/sound/soc/intel/sst_platform.h b/sound/soc/intel/sst_platform.h index cacc906..bee64fb 100644 --- a/sound/soc/intel/sst_platform.h +++ b/sound/soc/intel/sst_platform.h @@ -33,10 +33,6 @@ #define SST_STEREO 2 #define SST_MAX_CAP 5
-#define SST_MIN_RATE 8000 -#define SST_MAX_RATE 48000 -#define SST_MIN_CHANNEL 1 -#define SST_MAX_CHANNEL 5 #define SST_MAX_BUFFER (800*1024) #define SST_MIN_BUFFER (800*1024) #define SST_MIN_PERIOD_BYTES 32
On Mon, Jan 06, 2014 at 02:19:10PM +0100, Lars-Peter Clausen wrote:
The ASoC core assumes that the PCM component of the ASoC card transparently moves data around and does not impose any restrictions on the memory layout or the transfer speed. It ignores all fields from the snd_pcm_hardware struct for the PCM driver that are related to this. Setting these fields in the PCM driver might suggest otherwise though, so rather not set them.
Applied, thanks.
The ASoC core assumes that the PCM component of the ASoC card transparently moves data around and does not impose any restrictions on the memory layout or the transfer speed. It ignores all fields from the snd_pcm_hardware struct for the PCM driver that are related to this. Setting these fields in the PCM driver might suggest otherwise though, so rather not set them.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de Cc: Jean-Francois Moine moinejf@free.fr --- No changes since v1 --- sound/soc/kirkwood/kirkwood-dma.c | 16 ---------------- 1 file changed, 16 deletions(-)
diff --git a/sound/soc/kirkwood/kirkwood-dma.c b/sound/soc/kirkwood/kirkwood-dma.c index 4af1936..aac22fc 100644 --- a/sound/soc/kirkwood/kirkwood-dma.c +++ b/sound/soc/kirkwood/kirkwood-dma.c @@ -21,16 +21,6 @@ #include <sound/soc.h> #include "kirkwood.h"
-#define KIRKWOOD_RATES \ - (SNDRV_PCM_RATE_8000_192000 | \ - SNDRV_PCM_RATE_CONTINUOUS | \ - SNDRV_PCM_RATE_KNOT) - -#define KIRKWOOD_FORMATS \ - (SNDRV_PCM_FMTBIT_S16_LE | \ - SNDRV_PCM_FMTBIT_S24_LE | \ - SNDRV_PCM_FMTBIT_S32_LE) - static struct kirkwood_dma_data *kirkwood_priv(struct snd_pcm_substream *subs) { struct snd_soc_pcm_runtime *soc_runtime = subs->private_data; @@ -43,12 +33,6 @@ static struct snd_pcm_hardware kirkwood_dma_snd_hw = { SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_PAUSE), - .formats = KIRKWOOD_FORMATS, - .rates = KIRKWOOD_RATES, - .rate_min = 8000, - .rate_max = 384000, - .channels_min = 1, - .channels_max = 8, .buffer_bytes_max = KIRKWOOD_SND_MAX_BUFFER_BYTES, .period_bytes_min = KIRKWOOD_SND_MIN_PERIOD_BYTES, .period_bytes_max = KIRKWOOD_SND_MAX_PERIOD_BYTES,
On Mon, Jan 06, 2014 at 02:19:11PM +0100, Lars-Peter Clausen wrote:
The ASoC core assumes that the PCM component of the ASoC card transparently moves data around and does not impose any restrictions on the memory layout or the transfer speed. It ignores all fields from the snd_pcm_hardware struct for the PCM driver that are related to this. Setting these fields in the PCM driver might suggest otherwise though, so rather not set them.
Applied, thanks.
The ASoC core assumes that the PCM component of the ASoC card transparently moves data around and does not impose any restrictions on the memory layout or the transfer speed. It ignores all fields from the snd_pcm_hardware struct for the PCM driver that are related to this. Setting these fields in the PCM driver might suggest otherwise though, so rather not set them.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de Cc: Shawn Guo shawn.guo@linaro.org Cc: Fabio Estevam fabio.estevam@freescale.com --- No changes since v1 --- sound/soc/mxs/mxs-pcm.c | 5 ----- 1 file changed, 5 deletions(-)
diff --git a/sound/soc/mxs/mxs-pcm.c b/sound/soc/mxs/mxs-pcm.c index 04a6b0d..2e0863a 100644 --- a/sound/soc/mxs/mxs-pcm.c +++ b/sound/soc/mxs/mxs-pcm.c @@ -36,11 +36,6 @@ static const struct snd_pcm_hardware snd_mxs_hardware = { SNDRV_PCM_INFO_RESUME | SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_HALF_DUPLEX, - .formats = SNDRV_PCM_FMTBIT_S16_LE | - SNDRV_PCM_FMTBIT_S20_3LE | - SNDRV_PCM_FMTBIT_S24_LE, - .channels_min = 2, - .channels_max = 2, .period_bytes_min = 32, .period_bytes_max = 8192, .periods_min = 1,
On Mon, Jan 06, 2014 at 02:19:12PM +0100, Lars-Peter Clausen wrote:
The ASoC core assumes that the PCM component of the ASoC card transparently moves data around and does not impose any restrictions on the memory layout or the transfer speed. It ignores all fields from the snd_pcm_hardware struct for the PCM driver that are related to this. Setting these fields in the PCM driver might suggest otherwise though, so rather not set them.
Applied, thanks.
The ASoC core assumes that the PCM component of the ASoC card transparently moves data around and does not impose any restrictions on the memory layout or the transfer speed. It ignores all fields from the snd_pcm_hardware struct for the PCM driver that are related to this. Setting these fields in the PCM driver might suggest otherwise though, so rather not set them.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de Cc: Wan ZongShun mcuos.com@gmail.com --- No changes since v1 --- sound/soc/nuc900/nuc900-pcm.c | 3 --- 1 file changed, 3 deletions(-)
diff --git a/sound/soc/nuc900/nuc900-pcm.c b/sound/soc/nuc900/nuc900-pcm.c index f588ee4..f434ed7 100644 --- a/sound/soc/nuc900/nuc900-pcm.c +++ b/sound/soc/nuc900/nuc900-pcm.c @@ -32,9 +32,6 @@ static const struct snd_pcm_hardware nuc900_pcm_hardware = { SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME, - .formats = SNDRV_PCM_FMTBIT_S16_LE, - .channels_min = 1, - .channels_max = 2, .buffer_bytes_max = 4*1024, .period_bytes_min = 1*1024, .period_bytes_max = 4*1024,
On Mon, Jan 06, 2014 at 02:19:13PM +0100, Lars-Peter Clausen wrote:
The ASoC core assumes that the PCM component of the ASoC card transparently moves data around and does not impose any restrictions on the memory layout or the transfer speed. It ignores all fields from the snd_pcm_hardware struct for the PCM driver that are related to this. Setting these fields in the PCM driver might suggest otherwise though, so rather not set them.
Applied, thanks.
The ASoC core assumes that the PCM component of the ASoC card transparently moves data around and does not impose any restrictions on the memory layout or the transfer speed. It ignores all fields from the snd_pcm_hardware struct for the PCM driver that are related to this. Setting these fields in the PCM driver might suggest otherwise though, so rather not set them.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de Cc: Kuninori Morimoto kuninori.morimoto.gx@renesas.com --- No changes since v1 --- sound/soc/sh/dma-sh7760.c | 17 ----------------- sound/soc/sh/fsi.c | 6 ------ sound/soc/sh/rcar/core.c | 6 ------ 3 files changed, 29 deletions(-)
diff --git a/sound/soc/sh/dma-sh7760.c b/sound/soc/sh/dma-sh7760.c index 1a8b03e..c85f8eb 100644 --- a/sound/soc/sh/dma-sh7760.c +++ b/sound/soc/sh/dma-sh7760.c @@ -89,29 +89,12 @@ struct camelot_pcm { #define DMABRG_PREALLOC_BUFFER 32 * 1024 #define DMABRG_PREALLOC_BUFFER_MAX 32 * 1024
-/* support everything the SSI supports */ -#define DMABRG_RATES \ - SNDRV_PCM_RATE_8000_192000 - -#define DMABRG_FMTS \ - (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_U8 | \ - SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_U16_LE | \ - SNDRV_PCM_FMTBIT_S20_3LE | SNDRV_PCM_FMTBIT_U20_3LE | \ - SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_U24_3LE | \ - SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_U32_LE) - static struct snd_pcm_hardware camelot_pcm_hardware = { .info = (SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_BATCH), - .formats = DMABRG_FMTS, - .rates = DMABRG_RATES, - .rate_min = 8000, - .rate_max = 192000, - .channels_min = 2, - .channels_max = 8, /* max of the SSI */ .buffer_bytes_max = DMABRG_PERIOD_MAX, .period_bytes_min = DMABRG_PERIOD_MIN, .period_bytes_max = DMABRG_PERIOD_MAX / 2, diff --git a/sound/soc/sh/fsi.c b/sound/soc/sh/fsi.c index 6101055..1967f44 100644 --- a/sound/soc/sh/fsi.c +++ b/sound/soc/sh/fsi.c @@ -1787,12 +1787,6 @@ static struct snd_pcm_hardware fsi_pcm_hardware = { SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_PAUSE, - .formats = FSI_FMTS, - .rates = FSI_RATES, - .rate_min = 8000, - .rate_max = 192000, - .channels_min = 2, - .channels_max = 2, .buffer_bytes_max = 64 * 1024, .period_bytes_min = 32, .period_bytes_max = 8192, diff --git a/sound/soc/sh/rcar/core.c b/sound/soc/sh/rcar/core.c index b3653d3..743de5e 100644 --- a/sound/soc/sh/rcar/core.c +++ b/sound/soc/sh/rcar/core.c @@ -628,12 +628,6 @@ static struct snd_pcm_hardware rsnd_pcm_hardware = { SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_PAUSE, - .formats = RSND_FMTS, - .rates = RSND_RATES, - .rate_min = 8000, - .rate_max = 192000, - .channels_min = 2, - .channels_max = 2, .buffer_bytes_max = 64 * 1024, .period_bytes_min = 32, .period_bytes_max = 8192,
On Mon, Jan 06, 2014 at 02:19:14PM +0100, Lars-Peter Clausen wrote:
The ASoC core assumes that the PCM component of the ASoC card transparently moves data around and does not impose any restrictions on the memory layout or the transfer speed. It ignores all fields from the snd_pcm_hardware struct for the PCM driver that are related to this. Setting these fields in the PCM driver might suggest otherwise though, so rather not set them.
Applied, thanks.
The ASoC core assumes that the PCM component of the ASoC card transparently moves data around and does not impose any restrictions on the memory layout or the transfer speed. It ignores all fields from the snd_pcm_hardware struct for the PCM driver that are related to this. Setting these fields in the PCM driver might suggest otherwise though, so rather not set them.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de Cc: Lee Jones lee.jones@linaro.org --- No changes since v1 --- sound/soc/ux500/ux500_pcm.c | 15 --------------- 1 file changed, 15 deletions(-)
diff --git a/sound/soc/ux500/ux500_pcm.c b/sound/soc/ux500/ux500_pcm.c index ce554de..fa71640 100644 --- a/sound/soc/ux500/ux500_pcm.c +++ b/sound/soc/ux500/ux500_pcm.c @@ -28,12 +28,6 @@ #include "ux500_msp_i2s.h" #include "ux500_pcm.h"
-#define UX500_PLATFORM_MIN_RATE 8000 -#define UX500_PLATFORM_MAX_RATE 48000 - -#define UX500_PLATFORM_MIN_CHANNELS 1 -#define UX500_PLATFORM_MAX_CHANNELS 8 - #define UX500_PLATFORM_PERIODS_BYTES_MIN 128 #define UX500_PLATFORM_PERIODS_BYTES_MAX (64 * PAGE_SIZE) #define UX500_PLATFORM_PERIODS_MIN 2 @@ -45,15 +39,6 @@ static const struct snd_pcm_hardware ux500_pcm_hw = { SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_RESUME | SNDRV_PCM_INFO_PAUSE, - .formats = SNDRV_PCM_FMTBIT_S16_LE | - SNDRV_PCM_FMTBIT_U16_LE | - SNDRV_PCM_FMTBIT_S16_BE | - SNDRV_PCM_FMTBIT_U16_BE, - .rates = SNDRV_PCM_RATE_KNOT, - .rate_min = UX500_PLATFORM_MIN_RATE, - .rate_max = UX500_PLATFORM_MAX_RATE, - .channels_min = UX500_PLATFORM_MIN_CHANNELS, - .channels_max = UX500_PLATFORM_MAX_CHANNELS, .buffer_bytes_max = UX500_PLATFORM_BUFFER_BYTES_MAX, .period_bytes_min = UX500_PLATFORM_PERIODS_BYTES_MIN, .period_bytes_max = UX500_PLATFORM_PERIODS_BYTES_MAX,
On Mon, Jan 06, 2014 at 02:19:15PM +0100, Lars-Peter Clausen wrote:
The ASoC core assumes that the PCM component of the ASoC card transparently moves data around and does not impose any restrictions on the memory layout or the transfer speed. It ignores all fields from the snd_pcm_hardware struct for the PCM driver that are related to this. Setting these fields in the PCM driver might suggest otherwise though, so rather not set them.
Applied, thanks.
Some DMA cores might add additional restrictions on which in memory audio formats can be supported by the compound sound card. If the PCM component specifies a set of formats it supports (by setting the formats field to non 0) take these into account when calculating the format set for the compound sound card.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de Cc: Timur Tabi timur@tabi.org Cc: Shawn Guo shawn.guo@linaro.org Cc: Nicolin Chen b42378@freescale.com Cc: Markus Pargmann mpa@pengutronix.de --- New in v1. Note that this patch will only affect fsl/, all other platforms set the formats field to 0 now. --- sound/soc/soc-pcm.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index 86b670e..0457e70 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -240,7 +240,10 @@ static void soc_pcm_init_runtime_hw(struct snd_pcm_runtime *runtime, cpu_stream->channels_min); hw->channels_max = min(codec_stream->channels_max, cpu_stream->channels_max); - hw->formats = codec_stream->formats & cpu_stream->formats; + if (hw->formats) + hw->formats &= codec_stream->formats & cpu_stream->formats; + else + hw->formats = codec_stream->formats & cpu_stream->formats; hw->rates = codec_stream->rates & cpu_stream->rates; if (codec_stream->rates & (SNDRV_PCM_RATE_KNOT | SNDRV_PCM_RATE_CONTINUOUS))
On Mon, Jan 06, 2014 at 02:19:16PM +0100, Lars-Peter Clausen wrote:
Some DMA cores might add additional restrictions on which in memory audio formats can be supported by the compound sound card. If the PCM component specifies a set of formats it supports (by setting the formats field to non 0) take these into account when calculating the format set for the compound sound card.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de Cc: Timur Tabi timur@tabi.org Cc: Shawn Guo shawn.guo@linaro.org
For patches 4, 7, and 11:
Tested-by: Shawn Guo shawn.guo@linaro.org
On Mon, Jan 06, 2014 at 02:19:16PM +0100, Lars-Peter Clausen wrote:
Some DMA cores might add additional restrictions on which in memory audio formats can be supported by the compound sound card. If the PCM component specifies a set of formats it supports (by setting the formats field to non 0) take these into account when calculating the format set for the compound sound card.
Applied, thanks.
On Mon, Jan 06, 2014 at 02:19:06PM +0100, Lars-Peter Clausen wrote:
We have the same code for initializing the runtime pcm on both the playback and the capture path. Factor this out into a common helper function.
Applied, thanks.
participants (3)
-
Lars-Peter Clausen -
Mark Brown -
Shawn Guo