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

[alsa-devel] [PATCH] ASoC: davinci-mcasp: add support for suspend and resume
by Daniel Mack 03 Oct '13

03 Oct '13

When the system returns from suspend, it looses its configuration. Most of it is restored by running a normal audio stream startup, but the DAI format is left unset as that's configured on the audio device creation. Hence, it suffices here to care for the registers which are touched by davinci_mcasp_set_dai_fmt() and restore them when the system is resumed. Signed-off-by: Daniel Mack <zonque(a)gmail.com> --- sound/soc/davinci/davinci-mcasp.c | 39 +++++++++++++++++++++++++++++++++++++++ sound/soc/davinci/davinci-mcasp.h | 12 ++++++++++++ 2 files changed, 51 insertions(+) diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c index 591f853..5023da7 100644 --- a/sound/soc/davinci/davinci-mcasp.c +++ b/sound/soc/davinci/davinci-mcasp.c @@ -1272,12 +1272,51 @@ static int davinci_mcasp_remove(struct platform_device *pdev) return 0; } +#ifdef CONFIG_PM_SLEEP +static int davinci_mcasp_suspend(struct device *dev) +{ + struct davinci_audio_dev *a = dev_get_drvdata(dev); + void __iomem *base = a->base; + + a->context.txfmtctl = mcasp_get_reg(base + DAVINCI_MCASP_TXFMCTL_REG); + a->context.rxfmtctl = mcasp_get_reg(base + DAVINCI_MCASP_RXFMCTL_REG); + a->context.txfmt = mcasp_get_reg(base + DAVINCI_MCASP_TXFMT_REG); + a->context.rxfmt = mcasp_get_reg(base + DAVINCI_MCASP_RXFMT_REG); + a->context.aclkxctl = mcasp_get_reg(base + DAVINCI_MCASP_ACLKXCTL_REG); + a->context.aclkrctl = mcasp_get_reg(base + DAVINCI_MCASP_ACLKRCTL_REG); + a->context.pdir = mcasp_get_reg(base + DAVINCI_MCASP_PDIR_REG); + + return 0; +} + +static int davinci_mcasp_resume(struct device *dev) +{ + struct davinci_audio_dev *a = dev_get_drvdata(dev); + void __iomem *base = a->base; + + mcasp_set_reg(base + DAVINCI_MCASP_TXFMCTL_REG, a->context.txfmtctl); + mcasp_set_reg(base + DAVINCI_MCASP_RXFMCTL_REG, a->context.rxfmtctl); + mcasp_set_reg(base + DAVINCI_MCASP_TXFMT_REG, a->context.txfmt); + mcasp_set_reg(base + DAVINCI_MCASP_RXFMT_REG, a->context.rxfmt); + mcasp_set_reg(base + DAVINCI_MCASP_ACLKXCTL_REG, a->context.aclkxctl); + mcasp_set_reg(base + DAVINCI_MCASP_ACLKRCTL_REG, a->context.aclkrctl); + mcasp_set_reg(base + DAVINCI_MCASP_PDIR_REG, a->context.pdir); + + return 0; +} +#endif + +SIMPLE_DEV_PM_OPS(davinci_mcasp_pm_ops, + davinci_mcasp_suspend, + davinci_mcasp_resume); + static struct platform_driver davinci_mcasp_driver = { .probe = davinci_mcasp_probe, .remove = davinci_mcasp_remove, .driver = { .name = "davinci-mcasp", .owner = THIS_MODULE, + .pm = &davinci_mcasp_pm_ops, .of_match_table = mcasp_dt_ids, }, }; diff --git a/sound/soc/davinci/davinci-mcasp.h b/sound/soc/davinci/davinci-mcasp.h index a9ac0c1..a2e27e1 100644 --- a/sound/soc/davinci/davinci-mcasp.h +++ b/sound/soc/davinci/davinci-mcasp.h @@ -43,6 +43,18 @@ struct davinci_audio_dev { /* McASP FIFO related */ u8 txnumevt; u8 rxnumevt; + +#ifdef CONFIG_PM_SLEEP + struct { + u32 txfmtctl; + u32 rxfmtctl; + u32 txfmt; + u32 rxfmt; + u32 aclkxctl; + u32 aclkrctl; + u32 pdir; + } context; +#endif }; #endif /* DAVINCI_MCASP_H */ -- 1.8.3.1

3 2

[alsa-devel] [PATCH 1/3] ASoC: tas5086: move two variables into private struct
by Daniel Mack 03 Oct '13

03 Oct '13

We need to access the charge_period and start_mid_z values from other places later, so move them to the private struct. Signed-off-by: Daniel Mack <zonque(a)gmail.com> --- sound/soc/codecs/tas5086.c | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/sound/soc/codecs/tas5086.c b/sound/soc/codecs/tas5086.c index 6d31d88..31b5868 100644 --- a/sound/soc/codecs/tas5086.c +++ b/sound/soc/codecs/tas5086.c @@ -244,6 +244,8 @@ struct tas5086_private { unsigned int mclk, sclk; unsigned int format; bool deemph; + unsigned int charge_period; + unsigned int pwm_start_mid_z; /* Current sample rate for de-emphasis control */ int rate; /* GPIO driving Reset pin, if any */ @@ -720,13 +722,15 @@ static const int tas5086_charge_period[] = { static int tas5086_probe(struct snd_soc_codec *codec) { struct tas5086_private *priv = snd_soc_codec_get_drvdata(codec); - int charge_period = 1300000; /* hardware default is 1300 ms */ - u8 pwm_start_mid_z = 0; int i, ret; + priv->pwm_start_mid_z = 0; + priv->charge_period = 1300000; /* hardware default is 1300 ms */ + if (of_match_device(of_match_ptr(tas5086_dt_ids), codec->dev)) { struct device_node *of_node = codec->dev->of_node; - of_property_read_u32(of_node, "ti,charge-period", &charge_period); + of_property_read_u32(of_node, "ti,charge-period", + &priv->charge_period); for (i = 0; i < 6; i++) { char name[25]; @@ -735,7 +739,7 @@ static int tas5086_probe(struct snd_soc_codec *codec) "ti,mid-z-channel-%d", i + 1); if (of_get_property(of_node, name, NULL) != NULL) - pwm_start_mid_z |= 1 << i; + priv->pwm_start_mid_z |= 1 << i; } } @@ -744,25 +748,25 @@ static int tas5086_probe(struct snd_soc_codec *codec) * configure 'part 1' of the PWM starts to use Mid-Z, and tell * all configured mid-z channels to start start under 'part 1'. */ - if (pwm_start_mid_z) + if (priv->pwm_start_mid_z) regmap_write(priv->regmap, TAS5086_PWM_START, TAS5086_PWM_START_MIDZ_FOR_START_1 | - pwm_start_mid_z); + priv->pwm_start_mid_z); /* lookup and set split-capacitor charge period */ - if (charge_period == 0) { + if (priv->charge_period == 0) { regmap_write(priv->regmap, TAS5086_SPLIT_CAP_CHARGE, 0); } else { i = index_in_array(tas5086_charge_period, ARRAY_SIZE(tas5086_charge_period), - charge_period); + priv->charge_period); if (i >= 0) regmap_write(priv->regmap, TAS5086_SPLIT_CAP_CHARGE, i + 0x08); else dev_warn(codec->dev, "Invalid split-cap charge period of %d ns.\n", - charge_period); + priv->charge_period); } /* enable factory trim */ -- 1.8.3.1

2 3

[alsa-devel] [PATCH] ARM: omap: edma: add suspend suspend/resume hooks
by Daniel Mack 03 Oct '13

03 Oct '13

This patch adds support for edma driver. I know the intermediate code in arch/arm/common is going to be purged eventually when the real dma-engine driver lands, so I don't know whether it's reasonable to include my patch after all. It might just server as template for the suspend/resume functions in the final driver, or maybe anyone wants to include that intermediate hack for the time being. Successfully tested on an AM335x board with davinci-mcasp enabled audio. A patch to make the latter work after suspend has been posted on alsa-devel. Thanks, Dainel Daniel Mack (1): ARM: omap: edma: add suspend suspend/resume hooks arch/arm/common/edma.c | 133 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 133 insertions(+) -- 1.8.3.1

2 2

[alsa-devel] [PATCH] ALSA: snd-usb-usx2y: remove bogus frame check
by Daniel Mack 02 Oct '13

02 Oct '13

The frame check in i_usX2Y_urb_complete() is bogus and produces false positives as described in this LAU thread: http://linuxaudio.org/mailarchive/lau/2013/5/20/200177 This code removes the check code entirely. Cc: fzu(a)wemgehoertderstaat.de Reported-by: Dr Nicholas J Bailey <nicholas.bailey(a)glasgow.ac.uk> Suggested-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Daniel Mack <zonque(a)gmail.com> --- sound/usb/usx2y/usbusx2yaudio.c | 22 +++------------------- 1 file changed, 3 insertions(+), 19 deletions(-) diff --git a/sound/usb/usx2y/usbusx2yaudio.c b/sound/usb/usx2y/usbusx2yaudio.c index 63fb521..6234a51 100644 --- a/sound/usb/usx2y/usbusx2yaudio.c +++ b/sound/usb/usx2y/usbusx2yaudio.c @@ -299,19 +299,6 @@ static void usX2Y_error_urb_status(struct usX2Ydev *usX2Y, usX2Y_clients_stop(usX2Y); } -static void usX2Y_error_sequence(struct usX2Ydev *usX2Y, - struct snd_usX2Y_substream *subs, struct urb *urb) -{ - snd_printk(KERN_ERR -"Sequence Error!(hcd_frame=%i ep=%i%s;wait=%i,frame=%i).\n" -"Most probably some urb of usb-frame %i is still missing.\n" -"Cause could be too long delays in usb-hcd interrupt handling.\n", - usb_get_current_frame_number(usX2Y->dev), - subs->endpoint, usb_pipein(urb->pipe) ? "in" : "out", - usX2Y->wait_iso_frame, urb->start_frame, usX2Y->wait_iso_frame); - usX2Y_clients_stop(usX2Y); -} - static void i_usX2Y_urb_complete(struct urb *urb) { struct snd_usX2Y_substream *subs = urb->context; @@ -328,12 +315,9 @@ static void i_usX2Y_urb_complete(struct urb *urb) usX2Y_error_urb_status(usX2Y, subs, urb); return; } - if (likely((urb->start_frame & 0xFFFF) == (usX2Y->wait_iso_frame & 0xFFFF))) - subs->completed_urb = urb; - else { - usX2Y_error_sequence(usX2Y, subs, urb); - return; - } + + subs->completed_urb = urb; + { struct snd_usX2Y_substream *capsubs = usX2Y->subs[SNDRV_PCM_STREAM_CAPTURE], *playbacksubs = usX2Y->subs[SNDRV_PCM_STREAM_PLAYBACK]; -- 1.8.3.1

2 2

[alsa-devel] [PATCH] amixer: fix indentation when printing container TLV contents
by Anssi Hannula 02 Oct '13

02 Oct '13

decode_tlv() adds indentation in the beginning, with the expectation that the TLV will be printed on the line afterwards in a switch-case. However, in the case of a container TLV the switch-case simply adds another level of indentation and calls decode_tlv() for the inner TLVs. This causes the first inner TLV to be printed with too much indentation and double '|'. Fix that by printing "container" and a newline for container TLVs, so that the result is as follows: : values=0,0,0,0,0,0,0,0 | container | chmap-variable=FL,FR | chmap-variable=FL,FR,LFE | chmap-variable=FL,FR,FC Signed-off-by: Anssi Hannula <anssi.hannula(a)iki.fi> --- amixer/amixer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/amixer/amixer.c b/amixer/amixer.c index b83b0c3..cf82892 100644 --- a/amixer/amixer.c +++ b/amixer/amixer.c @@ -460,6 +460,7 @@ static void decode_tlv(unsigned int spaces, unsigned int *tlv, unsigned int tlv_ } switch (type) { case SND_CTL_TLVT_CONTAINER: + printf("container\n"); size += sizeof(unsigned int) -1; size /= sizeof(unsigned int); while (idx < size) { -- 1.8.1.5

2 1

[alsa-devel] alsa-lib 1.0.27.2 and musl
by Waldemar Brodkorb 02 Oct '13

02 Oct '13

Hi Developers, I am trying to cross-compile alsa-lib with a musl¹ libc based toolchain. Unfortunately src/compat/hsearch_r.c is failing to compile, because of some glibc specific macros (like _P) normally defined in sys/cdefs.h. After grepping through the code I can not find any consumer for any functions implemented in hsearch_r.c. When I just comment out the code, everything compiles fine. Seems that that usage of hsearch functions was removed in the code long time ago. commit 273d115de05574251bdd661747ecb68449a5cf1d Author: Jaroslav Kysela <perex(a)perex.cz> Date: Sat Jul 15 10:20:32 2000 +0000 Removed old mixer API functions. Added simple control layer (experimental). Can it just be removed? thanks for any advice or comment. best regards Waldemar ¹ http://www.musl-libc.org/

3 2

Re: [alsa-devel] [PATCH] sound: usb: add support for wireless USB devices
by Daniel Mack 02 Oct '13

02 Oct '13

On 01.10.2013 21:32, Thomas Pugliese wrote: > This patch updates snd_usb_audio_create also support devices whose > speed == USB_SPEED_WIRELESS. Interesting. What device are you testing this with? Daniel > > Signed-off-by: Thomas Pugliese <thomas.pugliese(a)gmail.com> > --- > sound/usb/card.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/sound/usb/card.c b/sound/usb/card.c > index 64952e2..ef76aa0 100644 > --- a/sound/usb/card.c > +++ b/sound/usb/card.c > @@ -349,6 +349,7 @@ static int snd_usb_audio_create(struct usb_device *dev, int idx, > case USB_SPEED_LOW: > case USB_SPEED_FULL: > case USB_SPEED_HIGH: > + case USB_SPEED_WIRELESS: > case USB_SPEED_SUPER: > break; > default: >

2 1

[alsa-devel] snd-usb-usx2y (Tascam US-122) sequence errors
by Dr Nicholas J Bailey 02 Oct '13

02 Oct '13

I'm on debian jessie, Linux arial 3.10-3-686-pae #1 SMP Debian 3.10.11-1 (2013-09-10) i686 GNU/Linux with a Tascam us-122 that has recently stopped working. When I try to capture with anything, there is a few hundred ms of audio then the capture process stalls and the following dmesg appears: [ 462.596296] Sequence Error!(hcd_frame=0 ep=8in;wait=1024,frame=0). [ 462.596296] Most probably some urb of usb-frame 1024 is still missing. [ 462.596296] Cause could be too long delays in usb-hcd interrupt handling. [ 477.959230] Sequence Error!(hcd_frame=0 ep=8in;wait=1024,frame=0). [ 477.959230] Most probably some urb of usb-frame 1024 is still missing. [ 477.959230] Cause could be too long delays in usb-hcd interrupt handling. Before this kernel, the box worked OK. The only think that leads me to believe it might be my fault is that for a very long time, I've had to plug the box in: [ 445.529271] usb 2-1.6: new full-speed USB device number 5 using ehci-pci [ 445.622076] usb 2-1.6: New USB device found, idVendor=1604, idProduct=8006 [ 445.622086] usb 2-1.6: New USB device strings: Mfr=0, Product=0, SerialNumber=0 then unplug it and plug it in again: [ 445.972743] usb 2-1.6: USB disconnect, device number 5 [ 447.621519] usb 2-1.6: new full-speed USB device number 6 using ehci-pci [ 447.714462] usb 2-1.6: New USB device found, idVendor=1604, idProduct=8007 [ 447.714471] usb 2-1.6: New USB device strings: Mfr=0, Product=0, SerialNumber=0 [ 447.834852] usbcore: registered new interface driver snd-usb-usx2y [ 455.194314] usb 2-1.6: USB disconnect, device number 6 [ 457.487433] usb 2-1.6: new full-speed USB device number 7 using ehci-pci [ 457.579960] usb 2-1.6: New USB device found, idVendor=1604, idProduct=8006 [ 457.579969] usb 2-1.6: New USB device strings: Mfr=0, Product=0, SerialNumber=0 to get the firmware to load [ 457.888884] usb 2-1.6: USB disconnect, device number 7 [ 459.379782] usb 2-1.6: new full-speed USB device number 8 using ehci-pci [ 459.472516] usb 2-1.6: New USB device found, idVendor=1604, idProduct=8007 [ 459.472526] usb 2-1.6: New USB device strings: Mfr=0, Product=0, SerialNumber=0 (green USB light comes on here). I'm not sure about how to start debugging this; there are many things that could be wrong. If it will help, I'll try and file a bug report; if not please tell me to shut up (prefereably after pointing me at the solution :) ) Nick/.

2 3

Re: [alsa-devel] Realtek ALC286 SONY Vaio Pro 13 Ubuntu 13.10
by David Henningsson 02 Oct '13

02 Oct '13

On 10/02/2013 04:13 AM, Yuval Levy wrote: > On 10/01/2013 02:28 AM, David Henningsson wrote: >> Ok. If things work without extra drivers from Sony or Realtek, then it >> should be possible to get things working in Linux too without extra >> information from these parties... > > I have added this information to the bug report > <https://bugs.launchpad.net/bugs/1228689> > where I also post my comments so that they are more persistent and > available to other users with similar issues. > > >> Ok - given that 0x21 works as expected you should only need to do this >> for pin 0x18. > > All my testing was with doing this for both pins. I only noticed now > that I do not need to do this for pin 0x18. I will try to o this only > for pin 0x21 and reboot tomorrow. Ok, cool. Notice that I wrote "do this for pin 0x18 only, not for pin 0x21", where as you replied "I'll do this for pin 0x21 only, not for pin 0x18". 0x18 is for input switching, 0x21 is for output switching. If you remove jack detection, like you did, you will need to do this switching manually, e g in pavucontrol or gnome sound settings. That is, when you plug your headphone in, you need to manually select "Headphone" too, if you don't, the result will probably be that you hear sound in both headphones and speakers. Anyway, let's guess that the high pitched sound, as well as the lack of headset microphone input, is because your headset is OMTP and that the Vaio only supports CTIA. That's my *guess*, but it could be wrong, and it would be good to have this confirmed with a CTIA headset. -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic

2 2

[alsa-devel] Problems with i.MX233 driver in 3.12rc2
by Trevor Page 01 Oct '13

01 Oct '13

Hello, First post to this list - I hope this is the appropriate place to ask for this assistance. I'm using the Olinuxino Maxi board with the i.MX233 processor. I'm using the 3.12rc2 kernel at the moment because this has recently introduced the drivers for this processor's audio. I understand that the drivers for this chip's audio are: sound/soc/codecs/mxs-builtin-codec.c sound/soc/mxs/mxs-builtin-audio.c sound/soc/mxs/mxs-builtin-dai.c sound/soc/mxs/mxs-builtin-pcm.c My application for the board is a simple C program that uses the Linphone library to make VOIP calls. The problem I am having is that audio usually works (playback and capture) perfectly fine from boot, but at some point it may suddenly go 'dead'. At this point, there is no longer any audio from the headphone socket. I have not yet pinpointed exactly what it takes to trigger the fault, but I have seen it happen once when the call was put on hold while a Linphone call was in progress. Once the audio output is dead, these are some further observations: - When a Linphone call is received, I still hear a click from the headphone output when the call ends. - I have confirmed that the DAC / HP channels are turned up and unmuted. - If I run speaker-test when the audio is working, speaker-test periodically prints time duration information (presumably on each pass of its internal loop), like "0 - Front Left", "Time per period ...". When the audio is dead, speaker-test just freezes on "0 - Front Left" forever, as if some call is either blocking or returning to say it is busy. This might hopefully therefore be a useful point to start debugging. - I have only ever managed to restore audio using a reboot. I would like to have a go at debugging this. My problem though is that although I'm experienced with C and microprocessor programming, compiling and debugging embedded Linux is new ground for me. I'd be grateful for any pointers on things I could try in order to gain an insight into what's going wrong, and tips on how I could debug the drivers. So far my plan for today is to build the kernel again with the i.MX233 audio drivers as external modules so that I can hopefully play with them a bit and compile them separately. (I assume the development and debug process for audio drivers like this is to compile them as .ko modules and modprobe them in). However without having any prior knowledge of Linux drivers or the ALSA / ASoC framework I'm not sure if I'm going to get very far. Regards, Trevor.

3 2