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

[alsa-devel] [PATCH] ASoC: dmaengine: Correct Makefile when sound is built as module
by Peter Ujfalusi 10 Oct '12

10 Oct '12

soc-dmaengine-pcm library need to be part of the snd-soc-core in order to be able to compile ASoC as modules when dmaengine is enabled on the platform. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- sound/soc/Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/sound/soc/Makefile b/sound/soc/Makefile index bcbf1d0..99f32f7 100644 --- a/sound/soc/Makefile +++ b/sound/soc/Makefile @@ -1,8 +1,9 @@ snd-soc-core-objs := soc-core.o soc-dapm.o soc-jack.o soc-cache.o soc-utils.o snd-soc-core-objs += soc-pcm.o soc-compress.o soc-io.o -snd-soc-dmaengine-pcm-objs := soc-dmaengine-pcm.o -obj-$(CONFIG_SND_SOC_DMAENGINE_PCM) += snd-soc-dmaengine-pcm.o +ifneq ($(CONFIG_SND_SOC_DMAENGINE_PCM),) +snd-soc-core-objs += soc-dmaengine-pcm.o +endif obj-$(CONFIG_SND_SOC) += snd-soc-core.o obj-$(CONFIG_SND_SOC) += codecs/ -- 1.7.12

2 8

Re: [alsa-devel] [GIT PULL] Disintegrate UAPI for sound
by Takashi Iwai 09 Oct '12

09 Oct '12

At Tue, 09 Oct 2012 14:58:41 +0100, David Howells wrote: > > Takashi Iwai <tiwai(a)suse.de> wrote: > > > > Can you merge the following branch into the sound tree please. > > > > The changes look OK, but is it targeted for 3.7 or 3.8 in general? > > I assumed the latter. > > Either will do. There are no dependencies on the branch I gave you. OK, then I'm going to take it once when 3.7-rc1 is released. thanks, Takashi

1 0

[alsa-devel] Complex hw buffer with MMAP_COMPLEX?
by Adrian Knoth 09 Oct '12

09 Oct '12

Hi! I'm about to start working on the driver for the new RME MADI FX card with its 194 input and 196 output channels. I've noticed that the device has a rather uncommon hw buffer layout. Let's stick to the input side for the sake of simplicity: 2ch AES, interleaved 8ch MADI 001-008, interleaved 8ch MADI 009-015, interleaved [..] 8ch MADI 184-192, interleaved On the output side, there is another stereo pair for headphones. That is, we're dealing with 25 (or 26 for output) interleaved streams with two or eight channels each. How could we represent such a layout in ALSA, that is, how are we talking to userspace? Would one create subdevices and rejoin them via plughw? Or use MMAP_COMPLEX and then let every application deal with it on its own? It's certainly not a problem to special-case the MADI FX in jackd1 and jackd2, but OTOH, this would require other ALSA apps to do the same (I'm thinking of proprietary custom code). I wonder if we could afford to rearrange the buffers in the driver and expose a single non-interleaved buffer to userspace. WDYT? TIA

3 3

Re: [alsa-devel] [GIT PULL] Disintegrate UAPI for sound
by Takashi Iwai 09 Oct '12

09 Oct '12

At Tue, 09 Oct 2012 14:30:42 +0100, David Howells wrote: > > Can you merge the following branch into the sound tree please. The changes look OK, but is it targeted for 3.7 or 3.8 in general? I assumed the latter. thanks, Takashi > > This is to complete part of the Userspace API (UAPI) disintegration for which > the preparatory patches were pulled recently. After these patches, userspace > headers will be segregated into: > > include/uapi/linux/.../foo.h > > for the userspace interface stuff, and: > > include/linux/.../foo.h > > for the strictly kernel internal stuff. > > --- > The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8: > > Merge branch 'akpm' (Andrew's patch-bomb) (2012-10-09 16:23:15 +0900) > > are available in the git repository at: > > > git://git.infradead.org/users/dhowells/linux-headers.git tags/disintegrate-sound-20121009 > > for you to fetch changes up to 674e95ca446369e9ca40e4e92b214a616a52bcd6: > > UAPI: (Scripted) Disintegrate include/sound (2012-10-09 09:49:13 +0100) > > ---------------------------------------------------------------- > UAPI Disintegration 2012-10-09 > > ---------------------------------------------------------------- > David Howells (1): > UAPI: (Scripted) Disintegrate include/sound > > include/sound/Kbuild | 10 - > include/sound/asequencer.h | 594 +---------------- > include/sound/asound.h | 935 +-------------------------- > include/sound/emu10k1.h | 355 +---------- > include/sound/sb16_csp.h | 104 +-- > include/uapi/sound/Kbuild | 10 + > include/uapi/sound/asequencer.h | 614 ++++++++++++++++++ > include/uapi/sound/asound.h | 957 ++++++++++++++++++++++++++++ > include/{ => uapi}/sound/asound_fm.h | 0 > include/{ => uapi}/sound/compress_offload.h | 0 > include/{ => uapi}/sound/compress_params.h | 0 > include/uapi/sound/emu10k1.h | 373 +++++++++++ > include/{ => uapi}/sound/hdsp.h | 0 > include/{ => uapi}/sound/hdspm.h | 0 > include/uapi/sound/sb16_csp.h | 122 ++++ > include/{ => uapi}/sound/sfnt_info.h | 0 > 16 files changed, 2084 insertions(+), 1990 deletions(-) > create mode 100644 include/uapi/sound/asequencer.h > create mode 100644 include/uapi/sound/asound.h > rename include/{ => uapi}/sound/asound_fm.h (100%) > rename include/{ => uapi}/sound/compress_offload.h (100%) > rename include/{ => uapi}/sound/compress_params.h (100%) > create mode 100644 include/uapi/sound/emu10k1.h > rename include/{ => uapi}/sound/hdsp.h (100%) > rename include/{ => uapi}/sound/hdspm.h (100%) > create mode 100644 include/uapi/sound/sb16_csp.h > rename include/{ => uapi}/sound/sfnt_info.h (100%) > . >

1 0

[alsa-devel] [PATCH v2] ALSA: ASoC: McASP: add support for 24 bit samples
by Mike Looijmans 09 Oct '12

09 Oct '12

Sorry for the lack of quoting, but I onle get the digest. These are wrong: + case SNDRV_PCM_FORMAT_U24_LE: + case SNDRV_PCM_FORMAT_S24_LE: These pack a 24-bit sample value in a 32-bit word. The codec will send 32 bits to the McASP, and you should transfer 32 bits to the user, not just 24. Hence, SNDRV_PCM_FORMAT_S24_LE must be treated just like SNDRV_PCM_FORMAT_S32_LE. I've tested that on a DA850-alike board with several TLV320AIC3256 codecs, treating them as 3-byte samples will reasult in invalid data. Met vriendelijke groet / kind regards, Mike Looijmans TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) - (0)499 - 33.69.79 Telefax: (+31) - (0)499 - 33.69.70 E-mail: mike.looijmans(a)topic.nl Website: www.topic.nl Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u verzocht de afzender hierover direct te informeren en het e-mail bericht met de bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht, waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of acceptatie van dit e-mail bericht of de daarbij behorende bijlagen. The contents of this message, as well as any enclosures, are addressed personally to, and thus solely intended for the addressee. They may contain information regarding a third party. A recipient who is neither the addressee, nor empowered to receive this message on behalf of the addressee, is kindly requested to immediately inform the sender of receipt, and to destroy the message and the enclosures. Any use of the contents of this message and/or the enclosures by any other person than the addressee or person who is empowered to receive this message, is illegal towards the sender and/or the aforementioned third party. TOPIC Embedded Systems is not liable for any damage as a result of the use and/or acceptance of this message and as well as any enclosures.

4 7

Re: [alsa-devel] [3.6-rc7] switcheroo race with Intel HDA...
by Takashi Iwai 09 Oct '12

09 Oct '12

At Tue, 9 Oct 2012 19:23:56 +0800, Daniel J Blueman wrote: > > On 9 October 2012 18:07, Takashi Iwai <tiwai(a)suse.de> wrote: > > At Tue, 09 Oct 2012 12:04:08 +0200, > > Takashi Iwai wrote: > >> > >> At Tue, 9 Oct 2012 00:34:09 +0800, > >> Daniel J Blueman wrote: > >> > > >> > On 8 October 2012 20:58, Takashi Iwai <tiwai(a)suse.de> wrote: > >> > > At Tue, 25 Sep 2012 13:20:05 +0800, > >> > > Daniel J Blueman wrote: > >> > >> On my Macbook with a discrete Nvidia GPU, there is a race between > >> > >> selecting the integrated GPU and putting the discrete GPU into D3 [1], > >> > >> reliably causing a kernel oops [2]. > >> > >> > >> > >> Introducing a delay of ~1s between the calls prevents this. When the > >> > >> second 'OFF' write path executes, it looks like struct azx at > >> > >> card->private_data hasn't yet been allocated yet [3], so there is > >> > >> likely some locking missing. > >> > > > >> > > It's rather pci_get_drvdata() returning NULL (i.e. card is NULL, thus > >> > > card->private_data causes Oops). Could you check the patch like below > >> > > and see whether you get a kernel warning (but no Oops) or the problem > >> > > gets fixed by shifting the assignment of pci drvdata? > >> > [...] > >> > > >> > Good patching. Calling pci_set_drvdata later prevents the oops in HDA, > >> > though we see unexpected 0x0 responses in the response ring buffer > >> > [1], which we don't see when there's a >~1.5s delay between IGD and > >> > OFF. > >> > >> If the previous patch fixed, it means that the switching occurred > >> during the device was being probed. Maybe a better approach to > >> register the VGA switcheroo after the proper initialization. > >> > >> The patch below is a revised one. Please give it a try. > > > > Also, it's not clear which card spews the spurious response. > > Apply the patch below in addition. > [...] > > hda-intel: 0000:01:00.1: spurious response 0x0:0x0, last cmd=0x1f0004 > $ lspci -s :1:0.1 > 01:00.1 Audio device: NVIDIA Corporation Device 0e1b (rev ff) > > It's the NVIDIA device which presumably hasn't completed it's > transition to D3 at the time the OFF is executed. OK, then could you try the patch below on the top of previous two patches? Takashi --- diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index f09ff6c..676c64d 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2639,13 +2640,13 @@ static void azx_vs_set_state(struct pci_dev *pci, disabled ? "Disabling" : "Enabling", pci_name(chip->pci)); if (disabled) { + snd_hda_lock_devices(chip->bus); azx_suspend(&pci->dev); chip->disabled = true; - snd_hda_lock_devices(chip->bus); } else { - snd_hda_unlock_devices(chip->bus); chip->disabled = false; azx_resume(&pci->dev); + snd_hda_unlock_devices(chip->bus); } } }

1 0

[alsa-devel] [PATCH] ALSA: hda - remove "Mic Jack Mode" for headset jacks (Latitude Exx30)
by David Henningsson 09 Oct '12

09 Oct '12

Dell Latitude 5x30 and 6x30 series of machines all have a single 4-pin headset jack. Enabling line in mode for such jack is very confusing (you would only get mono input, and would have to use non-standard adapters), so remove the option by default. Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/patch_sigmatel.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index bb6c50e..f60b353 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -104,6 +104,7 @@ enum { STAC_92HD83XXX_HP_LED, STAC_92HD83XXX_HP_INV_LED, STAC_92HD83XXX_HP_MIC_LED, + STAC_92HD83XXX_HEADSET_JACK, STAC_92HD83XXX_MODELS }; @@ -204,6 +205,7 @@ struct sigmatel_spec { unsigned int check_volume_offset:1; unsigned int auto_mic:1; unsigned int linear_tone_beep:1; + unsigned int headset_jack:1; /* 4-pin headset jack (hp + mono mic) */ /* gpio lines */ unsigned int eapd_mask; @@ -1684,6 +1686,7 @@ static const char * const stac92hd83xxx_models[STAC_92HD83XXX_MODELS] = { [STAC_92HD83XXX_HP_LED] = "hp-led", [STAC_92HD83XXX_HP_INV_LED] = "hp-inv-led", [STAC_92HD83XXX_HP_MIC_LED] = "hp-mic-led", + [STAC_92HD83XXX_HEADSET_JACK] = "headset-jack", }; static const struct snd_pci_quirk stac92hd83xxx_cfg_tbl[] = { @@ -1694,6 +1697,24 @@ static const struct snd_pci_quirk stac92hd83xxx_cfg_tbl[] = { "DFI LanParty", STAC_92HD83XXX_REF), SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x02ba, "unknown Dell", STAC_DELL_S14), + SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x0532, + "Dell Latitude E6230", STAC_92HD83XXX_HEADSET_JACK), + SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x0533, + "Dell Latitude E6330", STAC_92HD83XXX_HEADSET_JACK), + SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x0534, + "Dell Latitude E6430", STAC_92HD83XXX_HEADSET_JACK), + SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x0535, + "Dell Latitude E6530", STAC_92HD83XXX_HEADSET_JACK), + SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x053c, + "Dell Latitude E5430", STAC_92HD83XXX_HEADSET_JACK), + SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x053d, + "Dell Latitude E5530", STAC_92HD83XXX_HEADSET_JACK), + SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x0549, + "Dell Latitude E5430", STAC_92HD83XXX_HEADSET_JACK), + SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x057d, + "Dell Latitude E6430s", STAC_92HD83XXX_HEADSET_JACK), + SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x0584, + "Dell Latitude E6430U", STAC_92HD83XXX_HEADSET_JACK), SND_PCI_QUIRK(PCI_VENDOR_ID_DELL, 0x1028, "Dell Vostro 3500", STAC_DELL_VOSTRO_3500), SND_PCI_QUIRK(PCI_VENDOR_ID_HP, 0x1656, @@ -2855,6 +2876,9 @@ static inline int stac92xx_add_jack_mode_control(struct hda_codec *codec, char name[22]; if (snd_hda_get_input_pin_attr(def_conf) != INPUT_PIN_ATTR_INT) { + if (spec->headset_jack && snd_hda_get_input_pin_attr(def_conf) + != INPUT_PIN_ATTR_DOCK) + return 0; if (snd_hda_get_default_vref(codec, nid) == AC_PINCTL_VREF_GRD && nid == spec->line_switch) control = STAC_CTL_WIDGET_IO_SWITCH; @@ -5636,6 +5660,9 @@ again: case STAC_92HD83XXX_HP_MIC_LED: spec->mic_mute_led_gpio = 0x08; /* GPIO3 */ break; + case STAC_92HD83XXX_HEADSET_JACK: + spec->headset_jack = 1; + break; } if (find_mute_led_cfg(codec, default_polarity)) -- 1.7.9.5

2 1

Re: [alsa-devel] [3.6-rc7] switcheroo race with Intel HDA...
by Takashi Iwai 09 Oct '12

09 Oct '12

At Tue, 9 Oct 2012 00:34:09 +0800, Daniel J Blueman wrote: > > On 8 October 2012 20:58, Takashi Iwai <tiwai(a)suse.de> wrote: > > At Tue, 25 Sep 2012 13:20:05 +0800, > > Daniel J Blueman wrote: > >> On my Macbook with a discrete Nvidia GPU, there is a race between > >> selecting the integrated GPU and putting the discrete GPU into D3 [1], > >> reliably causing a kernel oops [2]. > >> > >> Introducing a delay of ~1s between the calls prevents this. When the > >> second 'OFF' write path executes, it looks like struct azx at > >> card->private_data hasn't yet been allocated yet [3], so there is > >> likely some locking missing. > > > > It's rather pci_get_drvdata() returning NULL (i.e. card is NULL, thus > > card->private_data causes Oops). Could you check the patch like below > > and see whether you get a kernel warning (but no Oops) or the problem > > gets fixed by shifting the assignment of pci drvdata? > [...] > > Good patching. Calling pci_set_drvdata later prevents the oops in HDA, > though we see unexpected 0x0 responses in the response ring buffer > [1], which we don't see when there's a >~1.5s delay between IGD and > OFF. If the previous patch fixed, it means that the switching occurred during the device was being probed. Maybe a better approach to register the VGA switcheroo after the proper initialization. The patch below is a revised one. Please give it a try. Takashi --- diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index f09ff6c..dcbfd29 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -501,6 +501,7 @@ struct azx { /* VGA-switcheroo setup */ unsigned int use_vga_switcheroo:1; + unsigned int vga_switcheroo_registered:1; unsigned int init_failed:1; /* delayed init failed */ unsigned int disabled:1; /* disabled by VGA-switcher */ @@ -2684,14 +2685,20 @@ static const struct vga_switcheroo_client_ops azx_vs_ops = { static int __devinit register_vga_switcheroo(struct azx *chip) { + int err; + if (!chip->use_vga_switcheroo) return 0; /* FIXME: currently only handling DIS controller * is there any machine with two switchable HDMI audio controllers? */ - return vga_switcheroo_register_audio_client(chip->pci, &azx_vs_ops, + err = vga_switcheroo_register_audio_client(chip->pci, &azx_vs_ops, VGA_SWITCHEROO_DIS, chip->bus != NULL); + if (err < 0) + return err; + chip->vga_switcheroo_registered = 1; + return 0; } #else #define init_vga_switcheroo(chip) /* NOP */ @@ -2713,7 +2720,8 @@ static int azx_free(struct azx *chip) if (use_vga_switcheroo(chip)) { if (chip->disabled && chip->bus) snd_hda_unlock_devices(chip->bus); - vga_switcheroo_unregister_client(chip->pci); + if (chip->vga_switcheroo_registered) + vga_switcheroo_unregister_client(chip->pci); } if (chip->initialized) { @@ -3067,14 +3075,6 @@ static int __devinit azx_create(struct snd_card *card, struct pci_dev *pci, } ok: - err = register_vga_switcheroo(chip); - if (err < 0) { - snd_printk(KERN_ERR SFX - "Error registering VGA-switcheroo client\n"); - azx_free(chip); - return err; - } - err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, &ops); if (err < 0) { snd_printk(KERN_ERR SFX "Error creating device [card]!\n"); @@ -3345,6 +3345,13 @@ static int __devinit azx_probe(struct pci_dev *pci, if (pci_dev_run_wake(pci)) pm_runtime_put_noidle(&pci->dev); + err = register_vga_switcheroo(chip); + if (err < 0) { + snd_printk(KERN_ERR SFX + "Error registering VGA-switcheroo client\n"); + goto out_free; + } + dev++; return 0;

1 1

[alsa-devel] [PATCH v2] ALSA: ASoC: McASP: add support for 24 bit samples
by Daniel Mack 09 Oct '12

09 Oct '12

Signed-off-by: Daniel Mack <zonque(a)gmail.com> Cc: Hebbar, Gururaja <gururaja.hebbar(a)ti.com> Cc: Matt Porter <mporter(a)ti.com> --- v2: also enable 24bit in the DAI sound/soc/davinci/davinci-mcasp.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c index 1252bad..76728be 100644 --- a/sound/soc/davinci/davinci-mcasp.c +++ b/sound/soc/davinci/davinci-mcasp.c @@ -839,6 +839,14 @@ static int davinci_mcasp_hw_params(struct snd_pcm_substream *substream, word_length = DAVINCI_AUDIO_WORD_16; break; + case SNDRV_PCM_FORMAT_U24_3LE: + case SNDRV_PCM_FORMAT_S24_3LE: + case SNDRV_PCM_FORMAT_U24_LE: + case SNDRV_PCM_FORMAT_S24_LE: + dma_params->data_type = 3; + word_length = DAVINCI_AUDIO_WORD_24; + break; + case SNDRV_PCM_FORMAT_U32_LE: case SNDRV_PCM_FORMAT_S32_LE: dma_params->data_type = 4; @@ -917,6 +925,10 @@ static const struct snd_soc_dai_ops davinci_mcasp_dai_ops = { SNDRV_PCM_FMTBIT_U8 | \ SNDRV_PCM_FMTBIT_S16_LE | \ SNDRV_PCM_FMTBIT_U16_LE | \ + SNDRV_PCM_FMTBIT_S24_LE | \ + SNDRV_PCM_FMTBIT_U24_LE | \ + SNDRV_PCM_FMTBIT_S24_3LE | \ + SNDRV_PCM_FMTBIT_U24_3LE | \ SNDRV_PCM_FMTBIT_S32_LE | \ SNDRV_PCM_FMTBIT_U32_LE) -- 1.7.11.4

2 1

[alsa-devel] [PATCH 0/5] McASP changes for more flexibility
by Daniel Mack 09 Oct '12

09 Oct '12

Hi, I've been working on the McASP driver lately to support a board on which an AM33xx SoC is connected to a CS4271 via I2S. The CPU is clock master for both LRCLK and BITCLK, but receives its master clock externally. Some changes were necessary in order to get this playing, as the driver seems to have been used with DSP_B formats only. I couldn't the pateches on any Davinci platform, so I rely on other people to test and see if they break anything. Thanks, Daniel Daniel Mack (5): ALSA: ASoC: enable 192KHz support for McASP ALSA: ASoC: McASP: add support for clock dividers ALSA: ASoC: McASP: add support for 24 bit samples ALSA: ASoC: McASP: make AHCLK direction configurable ALSA: ASoC: McASP: set format parameters in dependence of the DAI format sound/soc/davinci/davinci-evm.c | 5 +++ sound/soc/davinci/davinci-mcasp.c | 87 ++++++++++++++++++++++++++++++++++----- sound/soc/davinci/davinci-mcasp.h | 2 +- sound/soc/davinci/davinci-pcm.c | 16 ++----- 4 files changed, 86 insertions(+), 24 deletions(-) -- 1.7.11.4

2 10