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

[alsa-devel] [PATCH 0/4] twl4030 codec as MFD device
by Peter Ujfalusi 22 Oct '09

22 Oct '09

Hello, The following series adds new MFD device on top of the twl4030 MFD device for the codec part of the chip, and also converts the soc audio driver to use the correct probing (device model). Reason for the twl4030_codec MFD: the vibra control is actually in the codec part of the twl4030. If both the vibra and the audio functionality is needed from the twl4030 at the same time, than they need to control the codec power and APLL at the same time without breaking the other driver. Also these two has to be able to work without the need for the other driver. The proposed solution: Register twl4030_codec as a child for the twl4030 mfd. twl4030_codec is also and mfd and at the moment it has two child: twl4030_codec_audio: for audio codec twl4030_codec_vibra: for vibra driver The twl4030_codec mfd registers the devices for audio and vibra (if the platform data is not NULL for them), and has - at the moment - functions to enable/disable resources, each of these resources has ref-counts, so the twl4030_codec knows, when the resource is need to be turned on or off. The interface is quite simple: int twl4030_codec_enable_resource(enum twl4030_codec_res id); int twl4030_codec_disable_resource(enum twl4030_codec_res id); These functions are returning the content of the given register after the modification (or negative value, if error - the error handling need to be revisited in a near future), so that the caller can update it's local cache if it need to do (the audio driver needs it). There are two resource defined: TWL4030_CODEC_RES_POWER: Controlling the power of the codec TWL4030_CODEC_RES_APLL: For APLL The vibra driver is not part of this series. I have also included a patch, which changes the board files for those, which in my knowledge uses the twl4030 codec as audio device. I might missed some boards... To-Do list: - revisit the error handling in twl4030-codec driver - add the actual vibra driver ;) - coexistence related fixes for the audio and vibra driver - move all audio related configuration from soc machine drivers to the board files (if any) --- Peter Ujfalusi (4): MFD: twl4030: add twl4030_codec MFD as a new child to the core OMAP: Platform support for twl4030_codec MFD ASoC: TWL4030: Only update the needed bits in *set_dai_sysclk ASoC: TWL4030: Driver registration via twl4030_codec MFD arch/arm/mach-omap2/board-3430sdp.c | 9 + arch/arm/mach-omap2/board-omap3beagle.c | 9 + arch/arm/mach-omap2/board-omap3evm.c | 9 + arch/arm/mach-omap2/board-omap3pandora.c | 9 + arch/arm/mach-omap2/board-overo.c | 9 + arch/arm/mach-omap2/board-zoom2.c | 9 + drivers/mfd/Kconfig | 13 ++ drivers/mfd/Makefile | 1 + drivers/mfd/twl4030-codec.c | 245 ++++++++++++++++++++++++++++ drivers/mfd/twl4030-core.c | 14 ++ include/linux/i2c/twl4030.h | 18 ++ include/linux/mfd/twl4030-codec.h | 261 ++++++++++++++++++++++++++++++ sound/soc/codecs/Kconfig | 2 +- sound/soc/codecs/twl4030.c | 225 ++++++++++++++++---------- sound/soc/codecs/twl4030.h | 242 +--------------------------- 15 files changed, 751 insertions(+), 324 deletions(-) create mode 100644 drivers/mfd/twl4030-codec.c create mode 100644 include/linux/mfd/twl4030-codec.h

4 19

[alsa-devel] work in progress: USB driver for Behringer BCD 2000
by AJ Slye 22 Oct '09

22 Oct '09

I would Like to test this, and help where I can.. If midi works that would be great, but if we can get audio as well, wonderfull....

1 0

[alsa-devel] [PATCH alsa-lib 1/3] Open device nodes with close-on-exec flag
by Rémi Denis-Courmont 21 Oct '09

21 Oct '09

This avoid leaking device descriptors through exec. Thus ALSA applications can safely spawn other processes in their background. Signed-off-by: Rémi Denis-Courmont <remi(a)remlab.net> --- include/local.h | 23 +++++++++++++++++------ 1 files changed, 17 insertions(+), 6 deletions(-) diff --git a/include/local.h b/include/local.h index b5a1c45..5b54def 100644 --- a/include/local.h +++ b/include/local.h @@ -230,22 +230,33 @@ extern snd_lib_error_handler_t snd_err_msg; # define link_warning(symbol, msg) #endif -/* open with resmgr */ -#ifdef SUPPORT_RESMGR static inline int snd_open_device(const char *filename, int fmode) { - int fd = open(filename, fmode); + int fd; + +#ifdef O_CLOEXEC + fd = open(filename, fmode|O_CLOEXEC); if (fd >= 0) return fd; + if (errno == EINVAL) +#endif + { + fd = open(filename, fmode); + if (fd >= 0) { + fcntl(fd, F_SETFD, FD_CLOEXEC); + return fd; + } + } + +/* open with resmgr */ +#ifdef SUPPORT_RESMGR if (errno == EAGAIN || errno == EBUSY) return fd; if (! access(filename, F_OK)) return rsm_open_device(filename, fmode); +#endif return -1; } -#else -#define snd_open_device(filename, fmode) open(filename, fmode); -#endif /* make local functions really local */ #define snd_dlobj_cache_lookup \ -- 1.6.5

1 2

[alsa-devel] [PATCH] Re: Calling omap_pcm_prepare() results in BUG() on OMAP1
by Janusz Krzysztofik 21 Oct '09

21 Oct '09

I'm resending, this time CCing Mark as I should. Janusz ----------------------- Wednesday 21 October 2009 09:16:37 Jarkko Nikula napisał(a): > Hi > > On Wed, 21 Oct 2009 05:11:06 +0200 > > Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> wrote: > > Hi, > > After DMA burst mode has been introduced in sound/soc/omap/omap-pcm.c, > > omap_pcm_prepare() unconditionally calls: > > > > omap_set_dma_src_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); > > omap_set_dma_dest_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); > > > > AFAICS, current implementation of those two functions found in > > arch/arm/plat-ompa/dma.c doesn't support OMAP_DMA_DATA_BURST_16 on OMAP1 > > at all, so they both end with BUG() on that machine. That seems to result > > in ASoC being completely unusable, at least on my OMAP5910 based Amstrad > > Delta. > > Thanks for reporting the issue. Nobody didn't realize when those calls > were added that indeed they will end up to BUG() in > arch/arm/plat-omap/dma.c on OMAP1. > > > Is calling BUG() for OMAP1 from those functions intentional? > > > > If not intentional, can those be corrected by simply putting break; > > before defalut:? > > I'd let it on as it is as it will point out immediately invalid > argument for OMAP1 and those functions do not have return value. > > > If intentional, can those function calls be conditionally omited, at > > least for OMAP1510, in sound/soc/omap/omap-pcm.c? > > Yep, just put cpu_class_is_omap1() test in sound/soc/omap/omap-pcm.c > since we should not try to set unsupported burst size for OMAP1. Here you are. Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- --- linux-2.6.32-rc5/sound/soc/omap/omap-pcm.c.orig 2009-10-16 02:41:50.000000000 +0200 +++ linux-2.6.32-rc5/sound/soc/omap/omap-pcm.c 2009-10-21 12:33:45.000000000 +0200 @@ -195,6 +195,9 @@ static int omap_pcm_prepare(struct snd_p else omap_enable_dma_irq(prtd->dma_ch, OMAP_DMA_FRAME_IRQ); + if (cpu_class_is_omap1()) + return 0; + omap_set_dma_src_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); omap_set_dma_dest_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16);

2 1

[alsa-devel] [PATCH] ASoC: tlv320dac33: typo fix in the header
by Peter Ujfalusi 21 Oct '09

21 Oct '09

Fix the definition of DAC33_LTM field, the LTM bits in FIFO_IRQ_MODE_B register are starting at bit 6. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)nokia.com> --- sound/soc/codecs/tlv320dac33.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/tlv320dac33.h b/sound/soc/codecs/tlv320dac33.h index 0fedd70..eb8ae07 100644 --- a/sound/soc/codecs/tlv320dac33.h +++ b/sound/soc/codecs/tlv320dac33.h @@ -186,7 +186,7 @@ #define DAC33_NSM(x) (x << 0) #define DAC33_PSM(x) (x << 2) #define DAC33_ATM(x) (x << 4) -#define DAC33_LTM(x) (x << 4) +#define DAC33_LTM(x) (x << 6) /* DAC33_DAC_CTRL_A (0x2C) */ #define DAC33_DACRATE(x) (x << 0) -- 1.6.5.1

2 1

[alsa-devel] [PATCH] ASoC: Amstrad Delta minor cleanups
by Janusz Krzysztofik 21 Oct '09

21 Oct '09

Hi Mark, Here is a patch that corrects small omissions I have found in my code. Signed-off-by: Janusz Krzysztofik <jkrzyszt(a)tis.icnet.pl> --- --- linux-2.6.32-rc5/sound/soc/omap/ams-delta.c.orig 2009-10-16 02:41:50.000000000 +0200 +++ linux-2.6.32-rc5/sound/soc/omap/ams-delta.c 2009-10-21 03:33:17.000000000 +0200 @@ -40,7 +40,7 @@ /* Board specific DAPM widgets */ - const struct snd_soc_dapm_widget ams_delta_dapm_widgets[] = { +static const struct snd_soc_dapm_widget ams_delta_dapm_widgets[] = { /* Handset */ SND_SOC_DAPM_MIC("Mouthpiece", NULL), SND_SOC_DAPM_HP("Earpiece", NULL), @@ -81,7 +81,7 @@ static const char *ams_delta_audio_mode[ (1 << AMS_DELTA_SPEAKER)) #define AMS_DELTA_SPEAKERPHONE (AMS_DELTA_HANDSFREE | (1 << AMS_DELTA_AGC)) -unsigned short ams_delta_audio_mode_pins[] = { +static const unsigned short ams_delta_audio_mode_pins[] = { AMS_DELTA_MIXED, AMS_DELTA_HANDSET, AMS_DELTA_HANDSFREE,

2 1

[alsa-devel] question on snd_jack_report
by Harsha, Priya 21 Oct '09

21 Oct '09

When I call snd_jack_report with the status of the jack, from the user user space which parameter should I check in the sys/class/input/input2 to know if the jack is present or not? Thanks, Harsha.

2 1

[alsa-devel] Calling omap_pcm_prepare() results in BUG() on OMAP1
by Janusz Krzysztofik 21 Oct '09

21 Oct '09

Hi, After DMA burst mode has been introduced in sound/soc/omap/omap-pcm.c, omap_pcm_prepare() unconditionally calls: omap_set_dma_src_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); omap_set_dma_dest_burst_mode(prtd->dma_ch, OMAP_DMA_DATA_BURST_16); AFAICS, current implementation of those two functions found in arch/arm/plat-ompa/dma.c doesn't support OMAP_DMA_DATA_BURST_16 on OMAP1 at all, so they both end with BUG() on that machine. That seems to result in ASoC being completely unusable, at least on my OMAP5910 based Amstrad Delta. Is calling BUG() for OMAP1 from those functions intentional? If not intentional, can those be corrected by simply putting break; before defalut:? If intentional, can those function calls be conditionally omited, at least for OMAP1510, in sound/soc/omap/omap-pcm.c? Thanks, Janusz

2 2

[alsa-devel] snd-hda-intel , changing the model option
by Colin Kincaid Williams 21 Oct '09

21 Oct '09

Hello, I'm trying to get my sound working and was wondering: Is there is a way to change the model option without restarting my computer? I tried editing the /etc/modprobe.d/alsa-base.conf file, and then restarting alsa with /etc/init.d/alsa-utils restart 0 , however I do not think the change is taking place. I used the alsa-info.sh script to determine if the change took place however it appears that the card has the same model name as when the machine booted. Best, Colin Williams

1 0

[alsa-devel] ASoC update for 2.6.33
by Mark Brown 20 Oct '09

20 Oct '09

The following changes since commit 3da8e6885ec2dea67321c904d721be90e00cd748: Mark Brown (1): Merge branch 'for-2.6.32' into for-2.6.33 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.33 Barry Song (1): ASoC: Fix possible codec_dai->ops NULL pointer problems Julia Lawall (1): ASoC: Move dereference after NULL test Manuel Lauss (2): ASoC: au1x: psc-ac97: verify correct codec register was read ASoC: au1x: psc-ac97: reorganize timeouts Mark Brown (1): Merge branch 'for-2.6.32' into for-2.6.33 Peter Ujfalusi (1): ASoC: TWL4030: Only update the needed bits in *set_dai_sysclk sound/soc/au1x/psc-ac97.c | 49 +++++++++++++++++++++++++++++-------------- sound/soc/codecs/twl4030.c | 22 ++++++++++--------- sound/soc/soc-core.c | 11 +++++++-- sound/soc/soc-jack.c | 3 +- 4 files changed, 55 insertions(+), 30 deletions(-)

1 0