February 2012 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [RFC 00/11]O MAP/ASoC: Move and merge McBSP driver under ASoC
by Peter Ujfalusi 20 Feb '12

20 Feb '12

Hello, The aim of this series is to move the plat-omap/mcbsp.c driver out to sound/soc/omap/ By doing this we can combine the two levels of McBSP driver stack into a single one. Formally we had omap-mcbsp.[1-X] drivers (plat-omap/mcbsp.c), and omap-mcbsp-dai.[0-(X-1) drivers (sound/soc/omap/omap-mcbsp.c). We had global, shared structures, variables, pointers. The API between the two driver was a set of exported function calls where one of the parameter was the McBSP port id. With this series we will have one driver for McBSP (omap-mcbsp.[1-X]) which is basically the ASoC dai driver. All exported/shared global structures are gone since we can use driver data for all ports in this way. With the code in one place we can do further clean up in the McBSP driver, and adding new features will be much easier in the future. Also the DT support for McBSP will be significantly easier if we have one set of driver. McBSP is only used by audio, there are no known other users of the OMAP McBSP (well, Nokia n700 has the WLAN connected through McBSP but we do not have driver for that anyway). The series was created against Takashi's topic/asoc branch. I have tested it on Beagle xM, and compile tested it for OMAP1, OMAP2, and OMAP4 as well. I'm going to do more work on the cleanup, and the plan is to merge the two files into one (mcbsp.c -> omap-mcbsp.c) eventually. Comments, testers are welcome... CC-ing Samuel as well since he is the original author of the plat-omap/mcbsp.c driver. Regards, Peter --- Peter Ujfalusi (11): ARM: OMAP: mcbsp: Convert core driver to proper platform driver OMAP: mcbsp: Move core driver under sound/soc/omap ASoC: OMAP: McBSP: Consolidate plat/mcbsp.h content ASoC: core - Add API call to register dai kcontrols. ASoC: omap-mcbsp: Create a single driver for McBSP ARM: OMAP: Do not register omap-mcbsp-dai device ASoC: OMAP: mcbsp.h: Clean up bit definitions ASoC: OMAP McBSP: Remove redundant accessors ASoC: omap-mcbsp: Cleanup of module probe/remove code ASoC: omap-mcbsp: Merge the omap_mcbsp_data into omap_mcbsp structure ASoC: omap-mcbsp: Simplify DMA configuration arch/arm/mach-omap1/devices.c | 9 - arch/arm/mach-omap1/mcbsp.c | 14 +- arch/arm/mach-omap2/devices.c | 22 -- arch/arm/mach-omap2/mcbsp.c | 8 +- arch/arm/plat-omap/Kconfig | 8 - arch/arm/plat-omap/Makefile | 2 - arch/arm/plat-omap/include/plat/mcbsp.h | 321 ---------------- include/sound/soc.h | 2 + sound/soc/omap/Kconfig | 4 + sound/soc/omap/Makefile | 1 + sound/soc/omap/am3517evm.c | 2 +- sound/soc/omap/ams-delta.c | 2 +- sound/soc/omap/igep0020.c | 2 +- {arch/arm/plat-omap => sound/soc/omap}/mcbsp.c | 463 ++++-------------------- sound/soc/omap/mcbsp.h | 337 +++++++++++++++++ sound/soc/omap/n810.c | 2 +- sound/soc/omap/omap-mcbsp.c | 287 ++++++++------- sound/soc/omap/omap-mcbsp.h | 2 +- sound/soc/omap/omap-pcm.h | 2 + sound/soc/omap/omap3beagle.c | 2 +- sound/soc/omap/omap3evm.c | 2 +- sound/soc/omap/omap3pandora.c | 4 +- sound/soc/omap/osk5912.c | 2 +- sound/soc/omap/overo.c | 2 +- sound/soc/omap/rx51.c | 4 +- sound/soc/omap/sdp3430.c | 4 +- sound/soc/omap/zoom2.c | 4 +- sound/soc/soc-core.c | 31 ++ 28 files changed, 631 insertions(+), 914 deletions(-) rename {arch/arm/plat-omap => sound/soc/omap}/mcbsp.c (69%) create mode 100644 sound/soc/omap/mcbsp.h -- 1.7.8.4

2 3

[alsa-devel] [RFC 00/11]O MAP/ASoC: Move and merge McBSP driver under ASoC
by Peter Ujfalusi 20 Feb '12

20 Feb '12

Hello, The aim of this series is to move the plat-omap/mcbsp.c driver out to sound/soc/omap/ By doing this we can combine the two levels of McBSP driver stack into a single one. Formally we had omap-mcbsp.[1-X] drivers (plat-omap/mcbsp.c), and omap-mcbsp-dai.[0-(X-1) drivers (sound/soc/omap/omap-mcbsp.c). We had global, shared structures, variables, pointers. The API between the two driver was a set of exported function calls where one of the parameter was the McBSP port id. With this series we will have one driver for McBSP (omap-mcbsp.[1-X]) which is basically the ASoC dai driver. All exported/shared global structures are gone since we can use driver data for all ports in this way. With the code in one place we can do further clean up in the McBSP driver, and adding new features will be much easier in the future. Also the DT support for McBSP will be significantly easier if we have one set of driver. McBSP is only used by audio, there are no known other users of the OMAP McBSP (well, Nokia n700 has the WLAN connected through McBSP but we do not have driver for that anyway). The series was created against Takashi's topic/asoc branch. I have tested it on Beagle xM, and compile tested it for OMAP1, OMAP2, and OMAP4 as well. I'm going to do more work on the cleanup, and the plan is to merge the two files into one (mcbsp.c -> omap-mcbsp.c) eventually. Comments, testers are welcome... CC-ing Samuel as well since he is the original author of the plat-omap/mcbsp.c driver. Regards, Peter --- Peter Ujfalusi (11): ARM: OMAP: mcbsp: Convert core driver to proper platform driver OMAP: mcbsp: Move core driver under sound/soc/omap ASoC: OMAP: McBSP: Consolidate plat/mcbsp.h content ASoC: core - Add API call to register dai kcontrols. ASoC: omap-mcbsp: Create a single driver for McBSP ARM: OMAP: Do not register omap-mcbsp-dai device ASoC: OMAP: mcbsp.h: Clean up bit definitions ASoC: OMAP McBSP: Remove redundant accessors ASoC: omap-mcbsp: Cleanup of module probe/remove code ASoC: omap-mcbsp: Merge the omap_mcbsp_data into omap_mcbsp structure ASoC: omap-mcbsp: Simplify DMA configuration arch/arm/mach-omap1/devices.c | 9 - arch/arm/mach-omap1/mcbsp.c | 14 +- arch/arm/mach-omap2/devices.c | 22 -- arch/arm/mach-omap2/mcbsp.c | 8 +- arch/arm/plat-omap/Kconfig | 8 - arch/arm/plat-omap/Makefile | 2 - arch/arm/plat-omap/include/plat/mcbsp.h | 321 ---------------- include/sound/soc.h | 2 + sound/soc/omap/Kconfig | 4 + sound/soc/omap/Makefile | 1 + sound/soc/omap/am3517evm.c | 2 +- sound/soc/omap/ams-delta.c | 2 +- sound/soc/omap/igep0020.c | 2 +- {arch/arm/plat-omap => sound/soc/omap}/mcbsp.c | 463 ++++-------------------- sound/soc/omap/mcbsp.h | 337 +++++++++++++++++ sound/soc/omap/n810.c | 2 +- sound/soc/omap/omap-mcbsp.c | 287 ++++++++------- sound/soc/omap/omap-mcbsp.h | 2 +- sound/soc/omap/omap-pcm.h | 2 + sound/soc/omap/omap3beagle.c | 2 +- sound/soc/omap/omap3evm.c | 2 +- sound/soc/omap/omap3pandora.c | 4 +- sound/soc/omap/osk5912.c | 2 +- sound/soc/omap/overo.c | 2 +- sound/soc/omap/rx51.c | 4 +- sound/soc/omap/sdp3430.c | 4 +- sound/soc/omap/zoom2.c | 4 +- sound/soc/soc-core.c | 31 ++ 28 files changed, 631 insertions(+), 914 deletions(-) rename {arch/arm/plat-omap => sound/soc/omap}/mcbsp.c (69%) create mode 100644 sound/soc/omap/mcbsp.h -- 1.7.8.4

7 19

[alsa-devel] [PATCH] ASoC: twl4030: Debug code cleanup
by Peter Ujfalusi 20 Feb '12

20 Feb '12

Replace the printk(KERN_ERR* instances with dev_err in the driver. While we are here clean up some of the debug messages as well. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- sound/soc/codecs/twl4030.c | 33 +++++++++++++++++---------------- 1 files changed, 17 insertions(+), 16 deletions(-) diff --git a/sound/soc/codecs/twl4030.c b/sound/soc/codecs/twl4030.c index a193f5f..df2dd19 100644 --- a/sound/soc/codecs/twl4030.c +++ b/sound/soc/codecs/twl4030.c @@ -1002,8 +1002,8 @@ static int snd_soc_put_twl4030_opmode_enum_double(struct snd_kcontrol *kcontrol, unsigned short mask, bitmask; if (twl4030->configured) { - printk(KERN_ERR "twl4030 operation mode cannot be " - "changed on-the-fly\n"); + dev_err(codec->dev, + "operation mode cannot be changed on-the-fly\n"); return -EBUSY; } @@ -1800,7 +1800,7 @@ static int twl4030_hw_params(struct snd_pcm_substream *substream, mode |= TWL4030_APLL_RATE_96000; break; default: - printk(KERN_ERR "TWL4030 hw params: unknown rate %d\n", + dev_err(codec->dev, "%s: unknown rate %d\n", __func__, params_rate(params)); return -EINVAL; } @@ -1817,7 +1817,7 @@ static int twl4030_hw_params(struct snd_pcm_substream *substream, format |= TWL4030_DATA_WIDTH_32S_24W; break; default: - printk(KERN_ERR "TWL4030 hw params: unknown format %d\n", + dev_err(codec->dev, "%s: unknown format %d\n", __func__, params_format(params)); return -EINVAL; } @@ -1867,13 +1867,13 @@ static int twl4030_set_dai_sysclk(struct snd_soc_dai *codec_dai, case 38400000: break; default: - dev_err(codec->dev, "Unsupported APLL mclk: %u\n", freq); + dev_err(codec->dev, "Unsupported HFCLKIN: %u\n", freq); return -EINVAL; } if ((freq / 1000) != twl4030->sysclk) { dev_err(codec->dev, - "Mismatch in APLL mclk: %u (configured: %u)\n", + "Mismatch in HFCLKIN: %u (configured: %u)\n", freq, twl4030->sysclk * 1000); return -EINVAL; } @@ -1983,9 +1983,9 @@ static int twl4030_voice_startup(struct snd_pcm_substream *substream, * not available. */ if (twl4030->sysclk != 26000) { - dev_err(codec->dev, "The board is configured for %u Hz, while" - "the Voice interface needs 26MHz APLL mclk\n", - twl4030->sysclk * 1000); + dev_err(codec->dev, + "%s: HFCLKIN is %u KHz, voice interface needs 26MHz\n", + __func__, twl4030->sysclk); return -EINVAL; } @@ -1996,8 +1996,8 @@ static int twl4030_voice_startup(struct snd_pcm_substream *substream, & TWL4030_OPT_MODE; if (mode != TWL4030_OPTION_2) { - printk(KERN_ERR "TWL4030 voice startup: " - "the codec mode is not option2\n"); + dev_err(codec->dev, "%s: the codec mode is not option2\n", + __func__); return -EINVAL; } @@ -2038,7 +2038,7 @@ static int twl4030_voice_hw_params(struct snd_pcm_substream *substream, mode |= TWL4030_SEL_16K; break; default: - printk(KERN_ERR "TWL4030 voice hw params: unknown rate %d\n", + dev_err(codec->dev, "%s: unknown rate %d\n", __func__, params_rate(params)); return -EINVAL; } @@ -2067,13 +2067,14 @@ static int twl4030_voice_set_dai_sysclk(struct snd_soc_dai *codec_dai, struct twl4030_priv *twl4030 = snd_soc_codec_get_drvdata(codec); if (freq != 26000000) { - dev_err(codec->dev, "Unsupported APLL mclk: %u, the Voice" - "interface needs 26MHz APLL mclk\n", freq); + dev_err(codec->dev, + "%s: HFCLKIN is %u KHz, voice interface needs 26MHz\n", + __func__, freq / 1000); return -EINVAL; } if ((freq / 1000) != twl4030->sysclk) { dev_err(codec->dev, - "Mismatch in APLL mclk: %u (configured: %u)\n", + "Mismatch in HFCLKIN: %u (configured: %u)\n", freq, twl4030->sysclk * 1000); return -EINVAL; } @@ -2221,7 +2222,7 @@ static int twl4030_soc_probe(struct snd_soc_codec *codec) twl4030 = kzalloc(sizeof(struct twl4030_priv), GFP_KERNEL); if (twl4030 == NULL) { - printk("Can not allocate memroy\n"); + dev_err(codec->dev, "Can not allocate memroy\n"); return -ENOMEM; } snd_soc_codec_set_drvdata(codec, twl4030); -- 1.7.8.4

2 1

[alsa-devel] [PATCH] ASoC: imx/mxs: remove redundant SND_PCM selection
by Shawn Guo 20 Feb '12

20 Feb '12

SND_PCM is already selected by SND_SOC, there is no need for SND_IMX_SOC and SND_MXS_SOC to select it again. Signed-off-by: Shawn Guo <shawn.guo(a)linaro.org> --- sound/soc/imx/Kconfig | 1 - sound/soc/mxs/Kconfig | 1 - 2 files changed, 0 insertions(+), 2 deletions(-) diff --git a/sound/soc/imx/Kconfig b/sound/soc/imx/Kconfig index 7383917..91b66ef 100644 --- a/sound/soc/imx/Kconfig +++ b/sound/soc/imx/Kconfig @@ -1,7 +1,6 @@ menuconfig SND_IMX_SOC tristate "SoC Audio for Freescale i.MX CPUs" depends on ARCH_MXC - select SND_PCM select FIQ select SND_SOC_AC97_BUS help diff --git a/sound/soc/mxs/Kconfig b/sound/soc/mxs/Kconfig index e4ba8d5..21d20f3 100644 --- a/sound/soc/mxs/Kconfig +++ b/sound/soc/mxs/Kconfig @@ -1,7 +1,6 @@ menuconfig SND_MXS_SOC tristate "SoC Audio for Freescale MXS CPUs" depends on ARCH_MXS - select SND_PCM help Say Y or M if you want to add support for codecs attached to the MXS SAIF interface. -- 1.7.5.4

2 1

[alsa-devel] [PATCH] Remove the cvscompile file
by Vikram Narayanan 20 Feb '12

20 Feb '12

package: alsa-utils Removed the cvscompile file. Signed-off-by: Vikram Narayanan <vikram186(a)gmail.com> --- cvscompile | 25 ------------------------- 1 files changed, 0 insertions(+), 25 deletions(-) delete mode 100755 cvscompile diff --git a/cvscompile b/cvscompile deleted file mode 100755 index 64ade4f..0000000 --- a/cvscompile +++ /dev/null @@ -1,25 +0,0 @@ -#!/bin/bash - -if test -d ../alsa-lib/utils && ! test -r `aclocal --print-ac-dir`/alsa.m4; then - alsa_m4_flags="-I ../alsa-lib/utils" -fi -aclocal $alsa_m4_flags $ACLOCAL_FLAGS -# save original files to avoid stupid modifications by gettextize -cp Makefile.am Makefile.am.ok -cp configure.in configure.in.ok -gettextize -c -f --no-changelog -echo "EXTRA_DIST = gettext.m4" > m4/Makefile.am -cp Makefile.am.ok Makefile.am -cp configure.in.ok configure.in -autoheader -automake --foreign --copy --add-missing -touch depcomp # for older automake -autoconf -export CFLAGS='-O2 -Wall -pipe -g' -echo "CFLAGS=$CFLAGS" -echo "./configure $@" -./configure $@ || exit 1 -unset CFLAGS -if [ -z "$CVSCOMPILE_NO_MAKE" ]; then - make -fi -- 1.7.4.1

2 1

Re: [alsa-devel] Direct use of the DMA buffer?
by Pavel Hofman 20 Feb '12

20 Feb '12

Dne 20.2.2012 10:21, Jaroslav Kysela napsal(a): >> >> Clemens, thanks a lot for the information. How does it work when the >> alsa-lib chain contains plugins, such as plug, rate, etc.? I would >> assume the application circumvents these. > > Nope. The mmap commit mechanism was introduced to keep the plugin > interface functional. The direct mmap access to the DMA buffer is only > applied for the direct hw: devices. If a plugin is used inside alsa-lib, > the application talks to the plugin chain (it means that an intermediate > buffer for samples can be allocated to let things working). > Jaroslav, thanks a lot for the clarification. Pavel.

1 0

Re: [alsa-devel] Direct use of the DMA buffer?
by Jaroslav Kysela 20 Feb '12

20 Feb '12

Date 20.2.2012 09:38, Pavel Hofman wrote: > > Dne 20.2.2012 09:11, Clemens Ladisch napsal(a): >> Pavel Hofman wrote: >>> Please excuse my ignorance, but is it possible for an application to >>> directly use/output to the DMA buffer allocated by the kernel in >>> hw_params? >> >> Set one of the SND_PCM_ACCESS_MMAP_* access types and then use >> snd_pcm_mmap_begin/commit. >> > > Clemens, thanks a lot for the information. How does it work when the > alsa-lib chain contains plugins, such as plug, rate, etc.? I would > assume the application circumvents these. Nope. The mmap commit mechanism was introduced to keep the plugin interface functional. The direct mmap access to the DMA buffer is only applied for the direct hw: devices. If a plugin is used inside alsa-lib, the application talks to the plugin chain (it means that an intermediate buffer for samples can be allocated to let things working). Jaroslav -- Jaroslav Kysela <perex(a)perex.cz> Linux Kernel Sound Maintainer ALSA Project; Red Hat, Inc.

1 0

[alsa-devel] [PATCH] ASoC: io: Retrieve val_bytes from the regmap API
by Mark Brown 20 Feb '12

20 Feb '12

Allow us to build infrastructure which needs to know the size of a value without requiring regmap based drivers to supply this information to both ASoC and regmap by asking regmap for the value. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/soc-io.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/sound/soc/soc-io.c b/sound/soc/soc-io.c index 39ba507..4d8dc6a 100644 --- a/sound/soc/soc-io.c +++ b/sound/soc/soc-io.c @@ -114,6 +114,7 @@ int snd_soc_codec_set_cache_io(struct snd_soc_codec *codec, enum snd_soc_control_type control) { struct regmap_config config; + int ret; memset(&config, 0, sizeof(config)); codec->write = hw_write; @@ -141,6 +142,11 @@ int snd_soc_codec_set_cache_io(struct snd_soc_codec *codec, case SND_SOC_REGMAP: /* Device has made its own regmap arrangements */ codec->using_regmap = true; + + ret = regmap_get_val_bytes(codec->control_data); + /* Errors are legitimate for non-integer byte multiples */ + if (ret > 0) + codec->val_bytes = ret; break; default: -- 1.7.9

2 1

[alsa-devel] [PATCH 0/3] Coefficient configuration support
by Mark Brown 20 Feb '12

20 Feb '12

This series is only compile tested as yet, I'll probably get a chance to test it shortly - it should work out so hopefully the review can overlap usefully with the testing. Mark Brown (3): ASoC: core: Add SND_SOC_BYTES control for coefficient blocks ASoC: core: Add support for masking out parts of coefficient blocks ASoC: wm5100: Add DRC coefficient configuration include/sound/soc.h | 27 +++++++++++ sound/soc/codecs/wm5100.c | 2 + sound/soc/soc-core.c | 110 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 139 insertions(+), 0 deletions(-)

2 4

[alsa-devel] Direct use of the DMA buffer?
by Pavel Hofman 20 Feb '12

20 Feb '12

Hello, Please excuse my ignorance, but is it possible for an application to directly use/output to the DMA buffer allocated by the kernel in hw_params? Something like using the actual DMA buffer in the snd_pcm_writei function, without copying the data in alsa-lib/driver PCM midle layer (?), just managing the pointers. Only a theoretical question though, no plans on my side :) Thanks a lot for even a short No :-) Best regards, Pavel.

2 2