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

[alsa-devel] [PATCHv2 0/4] Add ESAI & SPDIF Vybrid and LS1+ support.
by Xiubo Li 14 Apr '14

14 Apr '14

Changes in V2: - Revise some issue from Nicolin Chen and Fabio Estevam. Xiubo Li (4): ASoC: esai: use the precise definition of 'ret'. ASoC: spdif: Sort the header files alphabetically. ASoC: esai: Add VF610+ compatibles support. ASoC: spdif: Add VF610+ compatibles support. sound/soc/fsl/fsl_esai.c | 9 ++++++--- sound/soc/fsl/fsl_spdif.c | 9 +++++---- 2 files changed, 11 insertions(+), 7 deletions(-) -- 1.8.4

3 6

[alsa-devel] [PATCH] ASoC: dapm: don't skip evaluate the power of widget with force set
by Xiang Xiao 14 Apr '14

14 Apr '14

Signed-off-by: Xiang Xiao <xiaoxiang(a)xiaomi.com> --- sound/soc/soc-dapm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index c8a780d..14af77e 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -1673,7 +1673,7 @@ static void dapm_widget_set_peer_power(struct snd_soc_dapm_widget *peer, /* If the peer is already in the state we're moving to then we * won't have an impact on it. */ - if (power != peer->power) + if (peer->force || power != peer->power) dapm_mark_dirty(peer, "peer state change"); } @@ -1683,7 +1683,7 @@ static void dapm_widget_set_power(struct snd_soc_dapm_widget *w, bool power, { struct snd_soc_dapm_path *path; - if (w->power == power) + if (!w->force && w->power == power) return; trace_snd_soc_dapm_widget_power(w, power); -- 1.8.1.2

2 1

[alsa-devel] [RFT v2 0/6] ASoC: core: Add support for DAI multicodec
by Benoit Cousson 14 Apr '14

14 Apr '14

Hi Mark and Liam, Here is the second version of the multicodec series. I mostly rebased the code to asoc-next, added smaller patches to introduce helpers before the main patch and thus reduce the overal size of that patch and modified the TDM slot fixup. Please note that I have a very simple setup based on BBB to check if the series is working, so it will be good to test the series on various setup to ensure this is not generating any regression. Hence the RFT for this version. The series is based on asoc-v3.15-2-245-g876dea8. Test and comments are welcome. Thanks, Benoit v1: http://comments.gmane.org/gmane.linux.alsa.devel/120532 v2: - Split the first version in several patches. - Remove the TDM fixup --- Misael Lopez Cruz (6): ASoC: core: Add helpers for codec and codec_dai search ASoC: core: Add helpers for codec DAI probe & remove ASoC: core: Add helper for DAI widgets linking ASoC: core: Add function for ac97 codec registration ASoC: core: Add helpers for dai link and aux dev init ASoC: core: Add support for DAI multicodec include/sound/soc-dai.h | 5 + include/sound/soc.h | 16 ++ sound/soc/soc-core.c | 578 ++++++++++++++++++++++++++++++++++-------------- sound/soc/soc-dapm.c | 39 +++- sound/soc/soc-pcm.c | 438 +++++++++++++++++++++++++----------- 5 files changed, 761 insertions(+), 315 deletions(-) -- 1.8.3.2

3 11

[alsa-devel] [PATCH] ASoC: jack: export gpio detect
by cfreeman＠nvidia.com 14 Apr '14

14 Apr '14

From: Christopher Freeman <cfreeman(a)nvidia.com> Export the gpio detect function so machine drivers may call it. Interrupts for the jack may be disabled during sleep, so this allows a machine driver to have the jack status updated during resume. Signed-off-by: Christopher Freeman <cfreeman(a)nvidia.com> --- include/sound/soc.h | 1 + sound/soc/soc-jack.c | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index a6a059c..36383cb 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -442,6 +442,7 @@ int snd_soc_jack_add_gpios(struct snd_soc_jack *jack, int count, struct snd_soc_jack_gpio *gpios); void snd_soc_jack_free_gpios(struct snd_soc_jack *jack, int count, struct snd_soc_jack_gpio *gpios); +void snd_soc_jack_gpio_detect(struct snd_soc_jack_gpio *gpio); #endif /* codec register bit access */ diff --git a/sound/soc/soc-jack.c b/sound/soc/soc-jack.c index 0bb5ccc..fd97cc5 100644 --- a/sound/soc/soc-jack.c +++ b/sound/soc/soc-jack.c @@ -231,7 +231,7 @@ EXPORT_SYMBOL_GPL(snd_soc_jack_notifier_unregister); #ifdef CONFIG_GPIOLIB /* gpio detect */ -static void snd_soc_jack_gpio_detect(struct snd_soc_jack_gpio *gpio) +void snd_soc_jack_gpio_detect(struct snd_soc_jack_gpio *gpio) { struct snd_soc_jack *jack = gpio->jack; int enable; @@ -251,6 +251,7 @@ static void snd_soc_jack_gpio_detect(struct snd_soc_jack_gpio *gpio) snd_soc_jack_report(jack, report, gpio->report); } +EXPORT_SYMBOL_GPL(snd_soc_jack_gpio_detect); /* irq handler for gpio pin */ static irqreturn_t gpio_handler(int irq, void *data) -- 1.8.3.2 ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

3 5

[alsa-devel] [PATCH] ASoC: davinci-mcasp: Do not touch 0x04 register above McASP_VERSION_2
by Peter Ujfalusi 14 Apr '14

14 Apr '14

This register is not defined in TI81xx and on AM335x/AM437x it is the SYSCONFIG register which should not be touched by drivers since it is related to PM and handled by the generic PM code. This register write was there since the first time the davinci-mcasp driver was appeared in the kernel. The reason why it did not caused any issues on AM335x/AM437x is that it sets bit 1 in SYSCONFIG register which in turn will enable the smart-idle mode. This is the default mode and this is the mode McASP should be in also when in use. On TI81xx the register is not defined. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- sound/soc/davinci/davinci-mcasp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c index ce0e55a4304c..50a824d9dbb7 100644 --- a/sound/soc/davinci/davinci-mcasp.c +++ b/sound/soc/davinci/davinci-mcasp.c @@ -495,7 +495,7 @@ static int mcasp_common_hw_param(struct davinci_mcasp *mcasp, int stream, int active_serializers, numevt, n; u32 reg; /* Default configuration */ - if (mcasp->version != MCASP_VERSION_4) + if (mcasp->version < MCASP_VERSION_3) mcasp_set_bits(mcasp, DAVINCI_MCASP_PWREMUMGT_REG, MCASP_SOFT); /* All PINS as McASP */ -- 1.9.1

2 1

[alsa-devel] [PATCH 00/17] Removed deprecated ENUM/MUX macros
by Lars-Peter Clausen 14 Apr '14

14 Apr '14

Hi, This is a follow-up to the enum consolidation series. It updates all users of the now redundant and deprecated macros and once that is done removes the macros. - Lars Lars-Peter Clausen (17): ASoC: adau1373: Replace usage deprecated MUX/ENUM macros ASoC: adav80x: Replace usage deprecated MUX/ENUM macros ASoC: arizona: Replace usage deprecated MUX/ENUM macros ASoC: max98090: Replace usage deprecated MUX/ENUM macros ASoC: mc13783: Replace usage deprecated MUX/ENUM macros ASoC: pcm512x: Replace usage deprecated SOC_VALUE_ENUM macro ASoC: rt5640: Replace usage deprecated MUX/ENUM macros ASoC: wm2200: Replace usage deprecated MUX/ENUM macros ASoC: wm5100: Replace usage deprecated MUX/ENUM macros ASoC: wm5102: Replace usage deprecated MUX/ENUM macros ASoC: wm5110: Replace usage deprecated MUX/ENUM macros ASoC: wm8988: Replace usage deprecated MUX/ENUM macros ASoC: wm5102: Replace usage deprecated SOC_VALUE_ENUM macro ASoC: wm8994: Replace usage deprecated MUX/ENUM macros ASoC: wm8995: Replace usage deprecated MUX/ENUM macros ASoC: wm8997: Replace usage deprecated MUX/ENUM macros ASoC: Remove deprecated ENUM/MUX macros include/sound/soc-dapm.h | 12 ------------ include/sound/soc.h | 2 -- sound/soc/codecs/adau1373.c | 7 +++---- sound/soc/codecs/adav80x.c | 8 ++++---- sound/soc/codecs/arizona.h | 4 ++-- sound/soc/codecs/max98090.c | 5 ++--- sound/soc/codecs/mc13783.c | 8 ++++---- sound/soc/codecs/pcm512x.c | 2 +- sound/soc/codecs/rt5640.c | 4 ++-- sound/soc/codecs/wm2200.c | 4 ++-- sound/soc/codecs/wm5100.c | 4 ++-- sound/soc/codecs/wm5102.c | 14 +++++++------- sound/soc/codecs/wm5110.c | 18 +++++++++--------- sound/soc/codecs/wm8988.c | 8 ++++---- sound/soc/codecs/wm8994.c | 12 ++++++------ sound/soc/codecs/wm8995.c | 10 ++++------ sound/soc/codecs/wm8997.c | 12 ++++++------ 17 files changed, 58 insertions(+), 76 deletions(-) -- 1.8.0

2 18

[alsa-devel] [PATCH 1/6] ASoC: pcm512x: Use CONFIG_PM_RUNTIME macro
by Sachin Kamat 14 Apr '14

14 Apr '14

Fixes the following compilation warnings: sound/soc/codecs/pcm512x.c:520:12: warning: ‘pcm512x_suspend’ defined but not used [-Wunused-function] sound/soc/codecs/pcm512x.c:545:12: warning: ‘pcm512x_resume’ defined but not used [-Wunused-function] Signed-off-by: Sachin Kamat <sachin.kamat(a)linaro.org> --- sound/soc/codecs/pcm512x.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/soc/codecs/pcm512x.c b/sound/soc/codecs/pcm512x.c index 4b4c0c7..5112420 100644 --- a/sound/soc/codecs/pcm512x.c +++ b/sound/soc/codecs/pcm512x.c @@ -517,6 +517,7 @@ void pcm512x_remove(struct device *dev) } EXPORT_SYMBOL_GPL(pcm512x_remove); +#ifdef CONFIG_PM_RUNTIME static int pcm512x_suspend(struct device *dev) { struct pcm512x_priv *pcm512x = dev_get_drvdata(dev); @@ -578,6 +579,7 @@ static int pcm512x_resume(struct device *dev) return 0; } +#endif const struct dev_pm_ops pcm512x_pm_ops = { SET_RUNTIME_PM_OPS(pcm512x_suspend, pcm512x_resume, NULL) -- 1.7.9.5

2 11

[alsa-devel] [PATCH 0/7] ASoC:davinci-mcasp: bc polarity fix and proper format support
by Peter Ujfalusi 14 Apr '14

14 Apr '14

Hi, The bit clock polarity has been configured incorrectly in the McASP driver for a long time. IB_NF, NB_IF and IB_IF was not correct on the receive side since they were selecting the same edge as we used for the tx. The driver only had support for DSP_B mode (and probably AC97, but I can not test that). All other formats were broken (DSP_A, I2S, LEFT_J, etc). With this series the following formats will be supported by the McASP driver: - DSP_B - AC97 - DSP_A (new) - I2S (new) - LEFT_J (new) Non supported modes will return error from now on. Regards, Peter --- Peter Ujfalusi (7): ASoC: davinci-mcasp: Fix bit clock polarity settings ASoC: davinci-mcasp: Format data delay configuration enhancement ASoC: davinci-mcasp: Support for DSP_A format ASoC: davinci-mcasp: Move the FS polarity change out from the switch case ASoC: davinci-mcasp: Add support for I2S format ASoC: davinci-mcasp: Support for LEFT_J format ASoC: davinci-mcasp: Remove excess empty lines from davinci_mcasp_set_dai_fmt() sound/soc/davinci/davinci-mcasp.c | 76 +++++++++++++++++++++++++-------------- 1 file changed, 50 insertions(+), 26 deletions(-) -- 1.9.1

3 13

[alsa-devel] iMX233 audio capture: glitches on task switch?
by Gilles Grégoire 14 Apr '14

14 Apr '14

Dear alsa developers, I need help debugging a driver for the builtin codec of Freescale's iMX233 SoC. I am facing an issue when capturing audio: garbage data (glitches) appears periodically in the recorded audio data. Audio playback looks fine, as far as I can tell. I am using kernel 3.13.6. A driver by Freescale exists for a 2.6.35 kernel but it was never submitted to mainline. Therefore, the driver I use is a port of Freescale's driver to kernel 3.13.6 by Michal Ulianko. You can find it in the attached patch+dts. Please note that this is still a work in progress. The driver is actually quite simple: it simply sets up the codec/cpu DAI and uses the generic dma engine through snd_dmaengine_pcm_register() to make the audio run. I am using arecord to capture the audio from the default input (the mic), which is _not_ connected in my setup. The command line I am using is the following: $ arecord --disable-format --disable-resample --fatal-errors --disable-channels --buffer-size=32768 --period-size=4096 -r 22050 -f S16_LE -c 2 -d 1 /tmp/test.wav What happens: the recorded audio data contains glitches at periodic intervals which contain garbage data. No underrun/overrun occurs during capture. I suspect that the problem is not in the driver's code itself, but could be the symptom of a bug somewhere else (possibly in mxs dma code), because of the following observations I did: * there are 2 kind of glitches: short (~3 samples) and long (~25 samples) depending on the kernel configuration. Both kinds may exists on the same capture. * short glitches exist only with CONFIG_HZ_PERIODIC=y. The period of those glitches is _exactly_ 4ms, which corresponds to the HZ value in my kernel config (250Hz). * long glitches are always there. The period of those glitches is directly related to the --period-bytes parameter of arecord: halving the --period-bytes parameter halves the period of the glitches. You can find attached a screenshot showing the glitches for the "dynticks" case (where only long glitches exist) and for the "periodic timer" case (where both kinds are visible). These observations lead me to believe that the glitches are related to task switching. Here is my best guess: * the short glitches come from the HZ tick invoking the scheduler. * the long glitches come from the kernel code waking up the arecord process when enough audio data was received. I spent a long time trying to narrow down the problem with no success. My main problem is that I have no idea what kind of bug could cause these symptoms. This is where I need help: I would welcome any advice on what to look for. Best regards, -- Gilles

2 2

[alsa-devel] snd-usb-audio issues??
by Richard Storer 14 Apr '14

14 Apr '14

Hi, this is my first time post on the ML so apologies if my message is not to the required standard. I am currently using a Raspberry Pi ARM computer it's running a customised version of Debian called Raspbian: Linux raspberrypi 3.10.36+ #665 PREEMPT Wed Apr 9 15:01:53 BST 2014 armv6l GNU/Linux For audio playback and capture I am using a Creative Sound Blaster Live 24bit external: ID 041e:3040 Creative Technology, Ltd SoundBlaster Live! 24-bit External SB0490 I am currently experiencing 2 problems with this device which I believe are related to the snd-usb-audio driver. My first issue is for some reason booting Linux with my device already attached to the USB port produces no audio output, however capture is functioning. I've tried mute, unmute via alsamixer but it seems like the amplifier circuit inside hasn't turned itself on properly. The cure for this (and 100% reproducible) would be to unplug / replug the USB cable or simply connect to USB after Linux has fully loaded. I don't understand why this should be the case surely it doesn't matter at what stage the device is connected?? My next issue I feel is a little bit more serious and from what I understand affects all versions of Linux even the x86 distros. I use my Sound Blaster to capture stereo audio via Line-In which I then stream in realtime via Darkice. While Line-In capture does function on this device the signal levels are extremely low. Unfortunately there is no Line-In mixer control for my device the only capture control I have is Mic and that doesn't control Line-In. I have search for many months for a solution to the lack of Line-In control but I have come to the conclusion that something is broken in the driver or it got missed out. Is anyone aware of these issues or could at least offer a solution to increase the Line-In mixer levels maybe communicate with the USB device directly without ALSA's assistance?? Richard S.

3 8