[alsa-devel] [PATCH 01/19] ASoC: atmel: Don't set unused struct snd_pcm_hardware fields
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: Bo Shen voice.shen@atmel.com Cc: Nicolas Ferre nicolas.ferre@atmel.com --- 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: Manuel Lauss manuel.lauss@googlemail.com --- sound/soc/au1x/dbdma2.c | 9 --------- sound/soc/au1x/dma.c | 14 -------------- 2 files changed, 23 deletions(-)
diff --git a/sound/soc/au1x/dbdma2.c b/sound/soc/au1x/dbdma2.c index 3b4eafa..17a24d8 100644 --- a/sound/soc/au1x/dbdma2.c +++ b/sound/soc/au1x/dbdma2.c @@ -65,19 +65,10 @@ struct au1xpsc_audio_dmadata { #define AU1XPSC_PERIOD_MIN_BYTES 1024 #define AU1XPSC_BUFFER_MIN_BYTES 65536
-#define AU1XPSC_PCM_FMTS \ - (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_U8 | \ - SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE | \ - SNDRV_PCM_FMTBIT_U16_LE | SNDRV_PCM_FMTBIT_U16_BE | \ - SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S32_BE | \ - SNDRV_PCM_FMTBIT_U32_LE | SNDRV_PCM_FMTBIT_U32_BE | \ - 0) - /* PCM hardware DMA capabilities - platform specific */ static const struct snd_pcm_hardware au1xpsc_pcm_hardware = { .info = SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BATCH, - .formats = AU1XPSC_PCM_FMTS, .period_bytes_min = AU1XPSC_PERIOD_MIN_BYTES, .period_bytes_max = 4096 * 1024 - 1, .periods_min = 2, diff --git a/sound/soc/au1x/dma.c b/sound/soc/au1x/dma.c index befd107..e920b60 100644 --- a/sound/soc/au1x/dma.c +++ b/sound/soc/au1x/dma.c @@ -21,14 +21,6 @@
#include "psc.h"
-#define ALCHEMY_PCM_FMTS \ - (SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_U8 | \ - SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE | \ - SNDRV_PCM_FMTBIT_U16_LE | SNDRV_PCM_FMTBIT_U16_BE | \ - SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S32_BE | \ - SNDRV_PCM_FMTBIT_U32_LE | SNDRV_PCM_FMTBIT_U32_BE | \ - 0) - struct pcm_period { u32 start; u32 relative_end; /* relative to start of buffer */ @@ -171,12 +163,6 @@ static irqreturn_t au1000_dma_interrupt(int irq, void *ptr) static const struct snd_pcm_hardware alchemy_pcm_hardware = { .info = SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BATCH, - .formats = ALCHEMY_PCM_FMTS, - .rates = SNDRV_PCM_RATE_8000_192000, - .rate_min = SNDRV_PCM_RATE_8000, - .rate_max = SNDRV_PCM_RATE_192000, - .channels_min = 2, - .channels_max = 2, .period_bytes_min = 1024, .period_bytes_max = 16 * 1024 - 1, .periods_min = 4,
My Alchemy hardware likes it.
Tested-by: Manuel Lauss manuel.lauss@gmail.com
On Fri, Dec 20, 2013 at 2:20 PM, Lars-Peter Clausen lars@metafoo.de 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.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de Cc: Manuel Lauss manuel.lauss@googlemail.com
sound/soc/au1x/dbdma2.c | 9 --------- sound/soc/au1x/dma.c | 14 -------------- 2 files changed, 23 deletions(-)
diff --git a/sound/soc/au1x/dbdma2.c b/sound/soc/au1x/dbdma2.c index 3b4eafa..17a24d8 100644 --- a/sound/soc/au1x/dbdma2.c +++ b/sound/soc/au1x/dbdma2.c @@ -65,19 +65,10 @@ struct au1xpsc_audio_dmadata { #define AU1XPSC_PERIOD_MIN_BYTES 1024 #define AU1XPSC_BUFFER_MIN_BYTES 65536
-#define AU1XPSC_PCM_FMTS \
(SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_U8 | \SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE | \SNDRV_PCM_FMTBIT_U16_LE | SNDRV_PCM_FMTBIT_U16_BE | \SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S32_BE | \SNDRV_PCM_FMTBIT_U32_LE | SNDRV_PCM_FMTBIT_U32_BE | \0)/* PCM hardware DMA capabilities - platform specific */ static const struct snd_pcm_hardware au1xpsc_pcm_hardware = { .info = SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BATCH,
.formats = AU1XPSC_PCM_FMTS, .period_bytes_min = AU1XPSC_PERIOD_MIN_BYTES, .period_bytes_max = 4096 * 1024 - 1, .periods_min = 2,diff --git a/sound/soc/au1x/dma.c b/sound/soc/au1x/dma.c index befd107..e920b60 100644 --- a/sound/soc/au1x/dma.c +++ b/sound/soc/au1x/dma.c @@ -21,14 +21,6 @@
#include "psc.h"
-#define ALCHEMY_PCM_FMTS \
(SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_U8 | \SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE | \SNDRV_PCM_FMTBIT_U16_LE | SNDRV_PCM_FMTBIT_U16_BE | \SNDRV_PCM_FMTBIT_S32_LE | SNDRV_PCM_FMTBIT_S32_BE | \SNDRV_PCM_FMTBIT_U32_LE | SNDRV_PCM_FMTBIT_U32_BE | \0)struct pcm_period { u32 start; u32 relative_end; /* relative to start of buffer */ @@ -171,12 +163,6 @@ static irqreturn_t au1000_dma_interrupt(int irq, void *ptr) static const struct snd_pcm_hardware alchemy_pcm_hardware = { .info = SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BATCH,
.formats = ALCHEMY_PCM_FMTS,.rates = SNDRV_PCM_RATE_8000_192000,.rate_min = SNDRV_PCM_RATE_8000,.rate_max = SNDRV_PCM_RATE_192000,.channels_min = 2,.channels_max = 2, .period_bytes_min = 1024, .period_bytes_max = 16 * 1024 - 1, .periods_min = 4,-- 1.8.0
On Fri, Dec 20, 2013 at 02:20:08PM +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 --- sound/soc/blackfin/bf5xx-ac97-pcm.c | 1 - sound/soc/blackfin/bf5xx-i2s-pcm.c | 3 --- 2 files changed, 4 deletions(-)
diff --git a/sound/soc/blackfin/bf5xx-ac97-pcm.c b/sound/soc/blackfin/bf5xx-ac97-pcm.c index 1d4c676..cdb8ee7 100644 --- a/sound/soc/blackfin/bf5xx-ac97-pcm.c +++ b/sound/soc/blackfin/bf5xx-ac97-pcm.c @@ -107,7 +107,6 @@ static const struct snd_pcm_hardware bf5xx_pcm_hardware = { #endif SNDRV_PCM_INFO_BLOCK_TRANSFER,
- .formats = SNDRV_PCM_FMTBIT_S16_LE, .period_bytes_min = 32, .period_bytes_max = 0x10000, .periods_min = 1, diff --git a/sound/soc/blackfin/bf5xx-i2s-pcm.c b/sound/soc/blackfin/bf5xx-i2s-pcm.c index 2a5b434..a3881c4 100644 --- a/sound/soc/blackfin/bf5xx-i2s-pcm.c +++ b/sound/soc/blackfin/bf5xx-i2s-pcm.c @@ -52,9 +52,6 @@ static const struct snd_pcm_hardware bf5xx_pcm_hardware = { .info = SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_BLOCK_TRANSFER, - .formats = SNDRV_PCM_FMTBIT_S16_LE | - SNDRV_PCM_FMTBIT_S24_LE | - SNDRV_PCM_FMTBIT_S32_LE, .period_bytes_min = 32, .period_bytes_max = 0x10000, .periods_min = 1,
On Fri, Dec 20, 2013 at 02:20: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: Peter Ujfalusi peter.ujfalusi@ti.com Cc: Olof Johansson olof@lixom.net --- sound/soc/davinci/davinci-pcm.c | 28 ---------------------------- 1 file changed, 28 deletions(-)
diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c index fb5d107..14145cd 100644 --- a/sound/soc/davinci/davinci-pcm.c +++ b/sound/soc/davinci/davinci-pcm.c @@ -46,33 +46,11 @@ static void print_buf_info(int slot, char *name) } #endif
-#define DAVINCI_PCM_FMTBITS (\ - SNDRV_PCM_FMTBIT_S8 |\ - SNDRV_PCM_FMTBIT_U8 |\ - SNDRV_PCM_FMTBIT_S16_LE |\ - SNDRV_PCM_FMTBIT_S16_BE |\ - SNDRV_PCM_FMTBIT_U16_LE |\ - SNDRV_PCM_FMTBIT_U16_BE |\ - SNDRV_PCM_FMTBIT_S24_LE |\ - SNDRV_PCM_FMTBIT_S24_BE |\ - SNDRV_PCM_FMTBIT_U24_LE |\ - SNDRV_PCM_FMTBIT_U24_BE |\ - SNDRV_PCM_FMTBIT_S32_LE |\ - SNDRV_PCM_FMTBIT_S32_BE |\ - SNDRV_PCM_FMTBIT_U32_LE |\ - SNDRV_PCM_FMTBIT_U32_BE) - static struct snd_pcm_hardware pcm_hardware_playback = { .info = (SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME| SNDRV_PCM_INFO_BATCH), - .formats = DAVINCI_PCM_FMTBITS, - .rates = SNDRV_PCM_RATE_8000_192000 | SNDRV_PCM_RATE_KNOT, - .rate_min = 8000, - .rate_max = 192000, - .channels_min = 2, - .channels_max = 384, .buffer_bytes_max = 128 * 1024, .period_bytes_min = 32, .period_bytes_max = 8 * 1024, @@ -86,12 +64,6 @@ static struct snd_pcm_hardware pcm_hardware_capture = { SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_BATCH), - .formats = DAVINCI_PCM_FMTBITS, - .rates = SNDRV_PCM_RATE_8000_192000 | SNDRV_PCM_RATE_KNOT, - .rate_min = 8000, - .rate_max = 192000, - .channels_min = 2, - .channels_max = 384, .buffer_bytes_max = 128 * 1024, .period_bytes_min = 32, .period_bytes_max = 8 * 1024,
On 12/20/2013 03:20 PM, 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.
Acked-by: Peter Ujfalusi peter.ujfalusi@ti.com
Signed-off-by: Lars-Peter Clausen lars@metafoo.de Cc: Peter Ujfalusi peter.ujfalusi@ti.com Cc: Olof Johansson olof@lixom.net
sound/soc/davinci/davinci-pcm.c | 28 ---------------------------- 1 file changed, 28 deletions(-)
diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c index fb5d107..14145cd 100644 --- a/sound/soc/davinci/davinci-pcm.c +++ b/sound/soc/davinci/davinci-pcm.c @@ -46,33 +46,11 @@ static void print_buf_info(int slot, char *name) } #endif
-#define DAVINCI_PCM_FMTBITS (\
SNDRV_PCM_FMTBIT_S8 |\SNDRV_PCM_FMTBIT_U8 |\SNDRV_PCM_FMTBIT_S16_LE |\SNDRV_PCM_FMTBIT_S16_BE |\SNDRV_PCM_FMTBIT_U16_LE |\SNDRV_PCM_FMTBIT_U16_BE |\SNDRV_PCM_FMTBIT_S24_LE |\SNDRV_PCM_FMTBIT_S24_BE |\SNDRV_PCM_FMTBIT_U24_LE |\SNDRV_PCM_FMTBIT_U24_BE |\SNDRV_PCM_FMTBIT_S32_LE |\SNDRV_PCM_FMTBIT_S32_BE |\SNDRV_PCM_FMTBIT_U32_LE |\SNDRV_PCM_FMTBIT_U32_BE)static struct snd_pcm_hardware pcm_hardware_playback = { .info = (SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME| SNDRV_PCM_INFO_BATCH),
- .formats = DAVINCI_PCM_FMTBITS,
- .rates = SNDRV_PCM_RATE_8000_192000 | SNDRV_PCM_RATE_KNOT,
- .rate_min = 8000,
- .rate_max = 192000,
- .channels_min = 2,
- .channels_max = 384, .buffer_bytes_max = 128 * 1024, .period_bytes_min = 32, .period_bytes_max = 8 * 1024,
@@ -86,12 +64,6 @@ static struct snd_pcm_hardware pcm_hardware_capture = { SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_BATCH),
- .formats = DAVINCI_PCM_FMTBITS,
- .rates = SNDRV_PCM_RATE_8000_192000 | SNDRV_PCM_RATE_KNOT,
- .rate_min = 8000,
- .rate_max = 192000,
- .channels_min = 2,
- .channels_max = 384, .buffer_bytes_max = 128 * 1024, .period_bytes_min = 32, .period_bytes_max = 8 * 1024,
On Fri, Dec 20, 2013 at 02:20: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: Ryan Mallon rmallon@gmail.com Cc: H Hartley Sweeten hsweeten@visionengravers.com --- sound/soc/cirrus/ep93xx-pcm.c | 9 --------- 1 file changed, 9 deletions(-)
diff --git a/sound/soc/cirrus/ep93xx-pcm.c b/sound/soc/cirrus/ep93xx-pcm.c index ca6698d..5f66447 100644 --- a/sound/soc/cirrus/ep93xx-pcm.c +++ b/sound/soc/cirrus/ep93xx-pcm.c @@ -30,15 +30,6 @@ static const struct snd_pcm_hardware ep93xx_pcm_hardware = { SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER), - - .rates = SNDRV_PCM_RATE_8000_192000, - .rate_min = SNDRV_PCM_RATE_8000, - .rate_max = SNDRV_PCM_RATE_192000, - - .formats = (SNDRV_PCM_FMTBIT_S16_LE | - SNDRV_PCM_FMTBIT_S24_LE | - SNDRV_PCM_FMTBIT_S32_LE), - .buffer_bytes_max = 131072, .period_bytes_min = 32, .period_bytes_max = 32768,
On Fri, Dec 20, 2013 at 02:20: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: Timur Tabi timur@tabi.org Cc: Shawn Guo shawn.guo@linaro.org Cc: Nicolin Chen b42378@freescale.com Cc: Markus Pargmann mpa@pengutronix.de --- sound/soc/fsl/fsl_dma.c | 26 -------------------------- sound/soc/fsl/imx-pcm-dma.c | 4 ---- sound/soc/fsl/imx-pcm-fiq.c | 4 ---- sound/soc/fsl/mpc5200_dma.c | 6 ------ 4 files changed, 40 deletions(-)
diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c index d570f8c..2326831 100644 --- a/sound/soc/fsl/fsl_dma.c +++ b/sound/soc/fsl/fsl_dma.c @@ -37,28 +37,6 @@ #include "fsl_dma.h" #include "fsl_ssi.h" /* For the offset of stx0 and srx0 */
-/* - * The formats that the DMA controller supports, which is anything - * that is 8, 16, or 32 bits. - */ -#define FSLDMA_PCM_FORMATS (SNDRV_PCM_FMTBIT_S8 | \ - SNDRV_PCM_FMTBIT_U8 | \ - SNDRV_PCM_FMTBIT_S16_LE | \ - SNDRV_PCM_FMTBIT_S16_BE | \ - SNDRV_PCM_FMTBIT_U16_LE | \ - SNDRV_PCM_FMTBIT_U16_BE | \ - SNDRV_PCM_FMTBIT_S24_LE | \ - SNDRV_PCM_FMTBIT_S24_BE | \ - SNDRV_PCM_FMTBIT_U24_LE | \ - SNDRV_PCM_FMTBIT_U24_BE | \ - SNDRV_PCM_FMTBIT_S32_LE | \ - 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; @@ -139,10 +117,6 @@ static const struct snd_pcm_hardware fsl_dma_hardware = { SNDRV_PCM_INFO_MMAP_VALID | 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..0849b7b 100644 --- a/sound/soc/fsl/imx-pcm-dma.c +++ b/sound/soc/fsl/imx-pcm-dma.c @@ -40,10 +40,6 @@ static const struct snd_pcm_hardware imx_pcm_hardware = { SNDRV_PCM_INFO_MMAP_VALID | 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..0d668bd 100644 --- a/sound/soc/fsl/imx-pcm-fiq.c +++ b/sound/soc/fsl/imx-pcm-fiq.c @@ -161,10 +161,6 @@ static struct snd_pcm_hardware snd_imx_hardware = { SNDRV_PCM_INFO_MMAP_VALID | 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..30d52e7 100644 --- a/sound/soc/fsl/mpc5200_dma.c +++ b/sound/soc/fsl/mpc5200_dma.c @@ -198,12 +198,6 @@ static const struct snd_pcm_hardware psc_dma_hardware = { .info = SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER | 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,
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.
Is this new? There are formats that the codec and the SSI support that the DMA controller does NOT support, like packed 24-bit samples. How do we ensure that we never get those?
On 12/20/2013 03:25 PM, Timur Tabi wrote:
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.
Is this new? There are formats that the codec and the SSI support that the DMA controller does NOT support, like packed 24-bit samples. How do we ensure that we never get those?
No, this is how it has always been. If there are restrictions imposed by the DMA controller we need to add support for expressing this inside the ASoC framework. But I think it will probably be more complex than just saying the DMA controller supports format A, B, C and the DAI controller supports format B, C, D and then just do the intersection of both. E.g. the DAI controller probably does not care whether the samples are packed or not if it only sees one sample at a time, while
- Lars
On Fri, Dec 20, 2013 at 03:04:08PM +0100, Lars-Peter Clausen wrote:
On 12/20/2013 03:25 PM, Timur Tabi wrote:
Is this new? There are formats that the codec and the SSI support that the DMA controller does NOT support, like packed 24-bit samples. How do we ensure that we never get those?
No, this is how it has always been. If there are restrictions imposed by the DMA controller we need to add support for expressing this inside the ASoC framework. But I think it will probably be more complex than just saying the DMA controller supports format A, B, C and the DAI controller supports format B, C, D and then just do the intersection of both. E.g. the DAI controller probably does not care whether the samples are packed or not if it only sees one sample at a time, while
The most common pattern I've seen is that the DAIs expect to see whole samples at a time get written into their FIFOs since the FIFOs tend to be stored in samples rather than bytes. With that pattern it'd be a bit cleaner to have them advertise sample sizes and transfer sizes and then have the core work out that if you can for example do 24 bit samples with four byte transfers and have a DMA controller that needs a 1:1 mapping between data read and written then we can't do packed format.
I think in general we want to be moving the DAIs to a sample size based interface and then mapping that onto the DMA controller when we connect the DMA and CPU DAIs. This would help with clarity on the CODEC side as well.
On 12/20/2013 07:27 PM, Mark Brown wrote:
On Fri, Dec 20, 2013 at 03:04:08PM +0100, Lars-Peter Clausen wrote:
On 12/20/2013 03:25 PM, Timur Tabi wrote:
Is this new? There are formats that the codec and the SSI support that the DMA controller does NOT support, like packed 24-bit samples. How do we ensure that we never get those?
No, this is how it has always been. If there are restrictions imposed by the DMA controller we need to add support for expressing this inside the ASoC framework. But I think it will probably be more complex than just saying the DMA controller supports format A, B, C and the DAI controller supports format B, C, D and then just do the intersection of both. E.g. the DAI controller probably does not care whether the samples are packed or not if it only sees one sample at a time, while
The most common pattern I've seen is that the DAIs expect to see whole samples at a time get written into their FIFOs since the FIFOs tend to be stored in samples rather than bytes. With that pattern it'd be a bit cleaner to have them advertise sample sizes and transfer sizes and then have the core work out that if you can for example do 24 bit samples with four byte transfers and have a DMA controller that needs a 1:1 mapping between data read and written then we can't do packed format.
Yep. The other one I've seen is where the audio controller expects the DMA to pack samples, that are smaller than the bus width, to one bus width word. E.g. if the bus width is 32 and the sample width is 16 the DMA controller is supposed to write 2 samples at once.
And then there might be different variations of the first one. Some controllers might expect narrow writes/reads while others might expect full bus width access with the upper bytes padded/discarded. But I think most controllers are fine with both.
The audio controller should probably advertise what sample sizes it supports and how it expects them to be written/read. And the DMA controller then based on that list needs to figure out what kind of in memory representations of the audio data it can support.
I think in general we want to be moving the DAIs to a sample size based interface and then mapping that onto the DMA controller when we connect the DMA and CPU DAIs. This would help with clarity on the CODEC side as well.
Yep, something similar should probably be done for format negotiation between DAI and CODEC.
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 --- 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
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 --- 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 Fri, 20 Dec 2013 14:20:14 +0100 Lars-Peter Clausen lars@metafoo.de 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.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de Cc: Jean-Francois Moine moinejf@free.fr
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
[snip]
@@ -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,
Lars,
You removed too many things. The 'formats' field is mandatory.
On 12/20/2013 07:05 PM, Jean-Francois Moine wrote:
On Fri, 20 Dec 2013 14:20:14 +0100 Lars-Peter Clausen lars@metafoo.de 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.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de Cc: Jean-Francois Moine moinejf@free.fr
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
[snip]
@@ -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,
Lars,
You removed too many things. The 'formats' field is mandatory.
No it is not. While snd_soc_set_runtime_hwparams() uses it it is later overwritten again in soc_pcm_init_runtime_hw().
- Lars
On Fri, 20 Dec 2013 18:18:49 +0100 Lars-Peter Clausen lars@metafoo.de wrote:
On 12/20/2013 07:05 PM, Jean-Francois Moine wrote:
On Fri, 20 Dec 2013 14:20:14 +0100 Lars-Peter Clausen lars@metafoo.de 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.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de Cc: Jean-Francois Moine moinejf@free.fr
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
[snip]
@@ -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,
Lars,
You removed too many things. The 'formats' field is mandatory.
No it is not. While snd_soc_set_runtime_hwparams() uses it it is later overwritten again in soc_pcm_init_runtime_hw().
I have a DPCM system and soc_pcm_init_runtime_hw() is not called (either 'dynamic' or 'no_pcm' is set in the DAI links).
On 12/20/2013 08:13 PM, Jean-Francois Moine wrote:
On Fri, 20 Dec 2013 18:18:49 +0100 Lars-Peter Clausen lars@metafoo.de wrote:
On 12/20/2013 07:05 PM, Jean-Francois Moine wrote:
On Fri, 20 Dec 2013 14:20:14 +0100 Lars-Peter Clausen lars@metafoo.de 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.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de Cc: Jean-Francois Moine moinejf@free.fr
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
[snip]
@@ -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,
Lars,
You removed too many things. The 'formats' field is mandatory.
No it is not. While snd_soc_set_runtime_hwparams() uses it it is later overwritten again in soc_pcm_init_runtime_hw().
I have a DPCM system and soc_pcm_init_runtime_hw() is not called (either 'dynamic' or 'no_pcm' is set in the DAI links).
Ok, I see dpcm_set_fe_runtime() does things slightly different.
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 --- 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,
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 --- 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,
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: Peter Ujfalusi peter.ujfalusi@ti.com Cc: Jarkko Nikula jarkko.nikula@bitmer.com --- sound/soc/omap/omap-pcm.c | 2 -- 1 file changed, 2 deletions(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index b8fa986..07b8b7b 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -45,8 +45,6 @@ static const struct snd_pcm_hardware omap_pcm_hardware = { SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME | SNDRV_PCM_INFO_NO_PERIOD_WAKEUP, - .formats = SNDRV_PCM_FMTBIT_S16_LE | - SNDRV_PCM_FMTBIT_S32_LE, .period_bytes_min = 32, .period_bytes_max = 64 * 1024, .periods_min = 2,
On Fri, 20 Dec 2013 14:20:17 +0100 Lars-Peter Clausen lars@metafoo.de 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.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de Cc: Peter Ujfalusi peter.ujfalusi@ti.com Cc: Jarkko Nikula jarkko.nikula@bitmer.com
sound/soc/omap/omap-pcm.c | 2 -- 1 file changed, 2 deletions(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index b8fa986..07b8b7b 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -45,8 +45,6 @@ static const struct snd_pcm_hardware omap_pcm_hardware = { SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME | SNDRV_PCM_INFO_NO_PERIOD_WAKEUP,
- .formats = SNDRV_PCM_FMTBIT_S16_LE |
SNDRV_PCM_FMTBIT_S32_LE,
Ok, I see it's overwritten here:
soc_pcm_init_runtime_hw() hw->formats = codec_stream->formats & cpu_stream->formats;
Acked-by: Jarkko Nikula jarkko.nikula@bitmer.com
On 12/20/2013 03:20 PM, 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.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de Cc: Peter Ujfalusi peter.ujfalusi@ti.com Cc: Jarkko Nikula jarkko.nikula@bitmer.com
sound/soc/omap/omap-pcm.c | 2 -- 1 file changed, 2 deletions(-)
diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index b8fa986..07b8b7b 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -45,8 +45,6 @@ static const struct snd_pcm_hardware omap_pcm_hardware = { SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME | SNDRV_PCM_INFO_NO_PERIOD_WAKEUP,
- .formats = SNDRV_PCM_FMTBIT_S16_LE |
SNDRV_PCM_FMTBIT_S32_LE,
Acked-by: Peter Ujfalusi peter.ujfalusi@ti.com
On Fri, Dec 20, 2013 at 02:20:17PM +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: Qiao Zhou zhouqiao@marvell.com --- sound/soc/pxa/mmp-pcm.c | 6 ------ 1 file changed, 6 deletions(-)
diff --git a/sound/soc/pxa/mmp-pcm.c b/sound/soc/pxa/mmp-pcm.c index 682ee52..5e8d813 100644 --- a/sound/soc/pxa/mmp-pcm.c +++ b/sound/soc/pxa/mmp-pcm.c @@ -36,14 +36,9 @@ struct mmp_dma_data { SNDRV_PCM_INFO_PAUSE | \ SNDRV_PCM_INFO_RESUME)
-#define MMP_PCM_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \ - SNDRV_PCM_FMTBIT_S24_LE | \ - SNDRV_PCM_FMTBIT_S32_LE) - static struct snd_pcm_hardware mmp_pcm_hardware[] = { { .info = MMP_PCM_INFO, - .formats = MMP_PCM_FORMATS, .period_bytes_min = 1024, .period_bytes_max = 2048, .periods_min = 2, @@ -53,7 +48,6 @@ static struct snd_pcm_hardware mmp_pcm_hardware[] = { }, { .info = MMP_PCM_INFO, - .formats = MMP_PCM_FORMATS, .period_bytes_min = 1024, .period_bytes_max = 2048, .periods_min = 2,
On Fri, Dec 20, 2013 at 02:20:18PM +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: Daniel Glöckner daniel-gl@gmx.net --- sound/soc/s6000/s6000-pcm.c | 7 ------- 1 file changed, 7 deletions(-)
diff --git a/sound/soc/s6000/s6000-pcm.c b/sound/soc/s6000/s6000-pcm.c index d219880..fb8461e 100644 --- a/sound/soc/s6000/s6000-pcm.c +++ b/sound/soc/s6000/s6000-pcm.c @@ -33,13 +33,6 @@ static struct snd_pcm_hardware s6000_pcm_hardware = { .info = (SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_JOINT_DUPLEX), - .formats = (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE), - .rates = (SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_5512 | \ - SNDRV_PCM_RATE_8000_192000), - .rate_min = 0, - .rate_max = 1562500, - .channels_min = 2, - .channels_max = 8, .buffer_bytes_max = 0x7ffffff0, .period_bytes_min = 16, .period_bytes_max = 0xfffff0,
On Fri, Dec 20, 2013 at 02:20:19PM +0100, Lars-Peter Clausen wrote:
- .formats = (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE),
I'm still interested in the outcome of the DPCM issue mentioned in the Kirkwood thread, but as the only known board using this driver is not affected:
Acked-by: Daniel Glöckner daniel-gl@gmx.net
On Fri, Dec 20, 2013 at 02:20:19PM +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: Sangbeom Kim sbkim73@samsung.com --- sound/soc/samsung/dma.c | 6 ------ sound/soc/samsung/idma.c | 8 -------- 2 files changed, 14 deletions(-)
diff --git a/sound/soc/samsung/dma.c b/sound/soc/samsung/dma.c index ee23194..dc09b71 100644 --- a/sound/soc/samsung/dma.c +++ b/sound/soc/samsung/dma.c @@ -35,12 +35,6 @@ static const struct snd_pcm_hardware dma_hardware = { SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID, - .formats = SNDRV_PCM_FMTBIT_S16_LE | - SNDRV_PCM_FMTBIT_U16_LE | - SNDRV_PCM_FMTBIT_U8 | - SNDRV_PCM_FMTBIT_S8, - .channels_min = 2, - .channels_max = 2, .buffer_bytes_max = 128*1024, .period_bytes_min = PAGE_SIZE, .period_bytes_max = PAGE_SIZE*2, diff --git a/sound/soc/samsung/idma.c b/sound/soc/samsung/idma.c index e4f318f..3d5cf15 100644 --- a/sound/soc/samsung/idma.c +++ b/sound/soc/samsung/idma.c @@ -35,14 +35,6 @@ static const struct snd_pcm_hardware idma_hardware = { SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_PAUSE | SNDRV_PCM_INFO_RESUME, - .formats = SNDRV_PCM_FMTBIT_S16_LE | - SNDRV_PCM_FMTBIT_U16_LE | - SNDRV_PCM_FMTBIT_S24_LE | - SNDRV_PCM_FMTBIT_U24_LE | - SNDRV_PCM_FMTBIT_U8 | - SNDRV_PCM_FMTBIT_S8, - .channels_min = 2, - .channels_max = 2, .buffer_bytes_max = MAX_IDMA_BUFFER, .period_bytes_min = 128, .period_bytes_max = MAX_IDMA_PERIOD,
On Fri, Dec 20, 2013 at 02:20:20PM +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 --- 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,
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: Stephen Warren swarren@wwwdotorg.org --- sound/soc/tegra/tegra_pcm.c | 3 --- 1 file changed, 3 deletions(-)
diff --git a/sound/soc/tegra/tegra_pcm.c b/sound/soc/tegra/tegra_pcm.c index 7b2d23b..c09ffd1 100644 --- a/sound/soc/tegra/tegra_pcm.c +++ b/sound/soc/tegra/tegra_pcm.c @@ -42,9 +42,6 @@ static const struct snd_pcm_hardware tegra_pcm_hardware = { .info = SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | SNDRV_PCM_INFO_INTERLEAVED, - .formats = SNDRV_PCM_FMTBIT_S16_LE, - .channels_min = 2, - .channels_max = 2, .period_bytes_min = 1024, .period_bytes_max = PAGE_SIZE, .periods_min = 2,
On 12/20/2013 06:20 AM, 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.
I suppose that makes sense; the data format is determined by the FIFO in the DAI/controller, not the DMA engine that's pushing the data there (unless DMA can do data conversions, though I think our HW can't?).
Tested-by: Stephen Warren swarren@nvidia.com Acked-by: Stephen Warren swarren@nvidia.com
On Fri, Dec 20, 2013 at 02:20:22PM +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 --- sound/soc/txx9/txx9aclc.c | 5 ----- 1 file changed, 5 deletions(-)
diff --git a/sound/soc/txx9/txx9aclc.c b/sound/soc/txx9/txx9aclc.c index fbd077f..f0829de 100644 --- a/sound/soc/txx9/txx9aclc.c +++ b/sound/soc/txx9/txx9aclc.c @@ -40,11 +40,6 @@ static const struct snd_pcm_hardware txx9aclc_pcm_hardware = { .info = SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BATCH | SNDRV_PCM_INFO_PAUSE, -#ifdef __BIG_ENDIAN - .formats = SNDRV_PCM_FMTBIT_S16_BE, -#else - .formats = SNDRV_PCM_FMTBIT_S16_LE, -#endif .period_bytes_min = 1024, .period_bytes_max = 8 * 1024, .periods_min = 2,
On Fri, Dec 20, 2013 at 02:20:23PM +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 --- 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,
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 --- sound/soc/soc-utils.c | 4 ---- 1 file changed, 4 deletions(-)
diff --git a/sound/soc/soc-utils.c b/sound/soc/soc-utils.c index 5e63365..6ebdfd9 100644 --- a/sound/soc/soc-utils.c +++ b/sound/soc/soc-utils.c @@ -59,10 +59,6 @@ int snd_soc_params_to_bclk(struct snd_pcm_hw_params *params) EXPORT_SYMBOL_GPL(snd_soc_params_to_bclk);
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,
On Fri, Dec 20, 2013 at 02:20:25PM +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.
On 12/20/2013 02:20 PM, 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.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de Cc: Bo Shen voice.shen@atmel.com Cc: Nicolas Ferre nicolas.ferre@atmel.com
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,
Atmel is one of the few platforms where the formats specified for the DMA controller are more restrictive than the formats specified for the DAI. As the restrictions specified by the PCM part have been ignored so far I'm wondering if this is a real restriction and things have only worked by chance or whether the restriction should be removed?
- Lars
Hi Lars,
On 01/05/2014 02:15 AM, Lars-Peter Clausen wrote:
On 12/20/2013 02:20 PM, 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.
Signed-off-by: Lars-Peter Clausen lars@metafoo.de Cc: Bo Shen voice.shen@atmel.com Cc: Nicolas Ferre nicolas.ferre@atmel.com
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,
Atmel is one of the few platforms where the formats specified for the DMA controller are more restrictive than the formats specified for the DAI. As the restrictions specified by the PCM part have been ignored so far I'm wondering if this is a real restriction and things have only worked by chance or whether the restriction should be removed?
This is not a real restriction for DMA, this can be removed. Only the SSC have the restriction, and we check it in DAI driver.
For this patch, Acked-by: Bo Shen voice.shen@atmel.com
- Lars
Best Regards, Bo Shen
On Fri, Dec 20, 2013 at 02:20:07PM +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.
participants (10)
-
Bo Shen -
Daniel Glöckner -
Jarkko Nikula -
Jean-Francois Moine -
Lars-Peter Clausen -
Manuel Lauss -
Mark Brown -
Peter Ujfalusi -
Stephen Warren -
Timur Tabi