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

[alsa-devel] [PATCH 1/2] ALSA: hda - remove quirk for Dell Vostro 1015
by David Henningsson 07 Aug '12

07 Aug '12

This computer is confirmed working with model=auto on kernel 3.2. Also, parsing fails with hda-emu with the current model. Cc: stable(a)kernel.org (3.2+) Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/patch_conexant.c | 1 - 1 file changed, 1 deletion(-) Alsa info: see hda-emu/codecs/canonical/cx20585-dell-vostro-1015-ccert-201010-6649 diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index 1436118..6f538eb 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -2972,7 +2972,6 @@ static const struct snd_pci_quirk cxt5066_cfg_tbl[] = { SND_PCI_QUIRK(0x1028, 0x02d8, "Dell Vostro", CXT5066_DELL_VOSTRO), SND_PCI_QUIRK(0x1028, 0x02f5, "Dell Vostro 320", CXT5066_IDEAPAD), SND_PCI_QUIRK(0x1028, 0x0401, "Dell Vostro 1014", CXT5066_DELL_VOSTRO), - SND_PCI_QUIRK(0x1028, 0x0402, "Dell Vostro", CXT5066_DELL_VOSTRO), SND_PCI_QUIRK(0x1028, 0x0408, "Dell Inspiron One 19T", CXT5066_IDEAPAD), SND_PCI_QUIRK(0x1028, 0x050f, "Dell Inspiron", CXT5066_IDEAPAD), SND_PCI_QUIRK(0x1028, 0x0510, "Dell Vostro", CXT5066_IDEAPAD), -- 1.7.9.5

2 3

Re: [alsa-devel] [PATCH v3 4/4] fbdev: sh_mobile_lcdc: use dma_mmap_coherent if available
by Laurent Pinchart 07 Aug '12

07 Aug '12

Hi Eiraku-san, On Monday 06 August 2012 18:55:24 Hideki EIRAKU wrote: > fb_mmap() implemented in fbmem.c uses smem_start as the physical > address of the frame buffer. In the sh_mobile_lcdc driver, the > smem_start is a dma_addr_t that is not a physical address when IOMMU is > enabled. dma_mmap_coherent() maps the address correctly. It is > available on ARM platforms. > > Signed-off-by: Hideki EIRAKU <hdk(a)igel.co.jp> Acked-by: Hideki EIRAKU <hdk(a)igel.co.jp> As this patch doesn't depend on any other patch in your series (ARCH_HAS_DMA_MMAP_COHERENT will not be defined without 1/4, so this patch will be a no-op until then), I've applied it to my tree and will push it to avoid merge conflicts, unless you would prefer to push it yourself. > --- > drivers/video/sh_mobile_lcdcfb.c | 28 ++++++++++++++++++++++++++++ > 1 files changed, 28 insertions(+), 0 deletions(-) > > diff --git a/drivers/video/sh_mobile_lcdcfb.c > b/drivers/video/sh_mobile_lcdcfb.c index 8cb653b..c8cba7a 100644 > --- a/drivers/video/sh_mobile_lcdcfb.c > +++ b/drivers/video/sh_mobile_lcdcfb.c > @@ -1614,6 +1614,17 @@ static int sh_mobile_lcdc_overlay_blank(int blank, > struct fb_info *info) return 1; > } > > +#ifdef ARCH_HAS_DMA_MMAP_COHERENT > +static int > +sh_mobile_lcdc_overlay_mmap(struct fb_info *info, struct vm_area_struct > *vma) +{ > + struct sh_mobile_lcdc_overlay *ovl = info->par; > + > + return dma_mmap_coherent(ovl->channel->lcdc->dev, vma, ovl->fb_mem, > + ovl->dma_handle, ovl->fb_size); > +} > +#endif > + > static struct fb_ops sh_mobile_lcdc_overlay_ops = { > .owner = THIS_MODULE, > .fb_read = fb_sys_read, > @@ -1626,6 +1637,9 @@ static struct fb_ops sh_mobile_lcdc_overlay_ops = { > .fb_ioctl = sh_mobile_lcdc_overlay_ioctl, > .fb_check_var = sh_mobile_lcdc_overlay_check_var, > .fb_set_par = sh_mobile_lcdc_overlay_set_par, > +#ifdef ARCH_HAS_DMA_MMAP_COHERENT > + .fb_mmap = sh_mobile_lcdc_overlay_mmap, > +#endif > }; > > static void > @@ -2093,6 +2107,17 @@ static int sh_mobile_lcdc_blank(int blank, struct > fb_info *info) return 0; > } > > +#ifdef ARCH_HAS_DMA_MMAP_COHERENT > +static int > +sh_mobile_lcdc_mmap(struct fb_info *info, struct vm_area_struct *vma) > +{ > + struct sh_mobile_lcdc_chan *ch = info->par; > + > + return dma_mmap_coherent(ch->lcdc->dev, vma, ch->fb_mem, > + ch->dma_handle, ch->fb_size); > +} > +#endif > + > static struct fb_ops sh_mobile_lcdc_ops = { > .owner = THIS_MODULE, > .fb_setcolreg = sh_mobile_lcdc_setcolreg, > @@ -2108,6 +2133,9 @@ static struct fb_ops sh_mobile_lcdc_ops = { > .fb_release = sh_mobile_lcdc_release, > .fb_check_var = sh_mobile_lcdc_check_var, > .fb_set_par = sh_mobile_lcdc_set_par, > +#ifdef ARCH_HAS_DMA_MMAP_COHERENT > + .fb_mmap = sh_mobile_lcdc_mmap, > +#endif > }; > > static void -- Regards, Laurent Pinchart

1 1

[alsa-devel] Connecting a codec to McASP in Linux 2.6.37
by Mike Looijmans 07 Aug '12

07 Aug '12

We are using the (Arago) linux kernel 2.6.37 (also labelled v2.6.37_DAVINCIPSP_03.21.00.04). There are several TLV320AIC3256 codec connected to an OMAP-L138 SoM board via I2C and McASP. The board is based on the DA850 EVM. To support the codec, I've backported the tlv320aic32x4 driver from the 2.6.39 linux kernel. The I2C part is configured correctly, and I can get and set mixer components and other settings via I2C to the codec. However, setting up the McASP data path is a complete riddle, and I need help to get this to work. In the board files, the following structs "glue" the codec to the audio data transfer unit: static struct snd_soc_dai_link da8xx_evm_dai[] = { { .name = "TLV320AIC3X-1", .stream_name = "AIC3X-1", .cpu_dai_name= "davinci-mcasp.0", .codec_dai_name = "tlv320aic32x4-hifi", .codec_name = "tlv320aic32x4.11-0018", .platform_name = "davinci-pcm-audio", .init = evm_aic3x_init_analog, .ops = &evm_ops, }, { .name = "TLV320AIC3X-2", .stream_name = "AIC3X-2", .cpu_dai_name= "davinci-mcasp.0", .codec_dai_name = "tlv320aic32x4-hifi", .codec_name = "tlv320aic32x4.12-0018", .platform_name = "davinci-pcm-audio", .init = evm_aic3x_init_analog, .ops = &evm_ops, }, I cannot determine what "stream_name" is supposed to do. Documentation in "dapm.txt" claims that "the stream name must match the corresponding stream name in your codec snd_soc_codec_dai", but that appears to be untrue, because in the existing SoC drivers, they never match. Also, "snd_soc_codec_dai" seems to be a typo in the documentation, because it only appears in the alsa soc documentation and nowhere else in the kernel. The string "davinci-mcasp.0" refers to the struct in sound/soc/davinci/davinci-mcasp.c: static struct snd_soc_dai_driver davinci_mcasp_dai[] = { { .name = "davinci-mcasp.0", .playback = { .channels_min = 2, .channels_max = 2, .rates = DAVINCI_MCASP_RATES, .formats = SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE, }, .capture = { .channels_min = 2, .channels_max = 2, .rates = DAVINCI_MCASP_RATES, .formats = SNDRV_PCM_FMTBIT_S8 | SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S32_LE, }, .ops = &davinci_mcasp_dai_ops, }, And in the board config files, there is also a struct that configures the McASP ports: static u8 da850_iis_serializer_direction[] = { INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, RX_MODE, TX_MODE, INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, INACTIVE_MODE, }; static struct snd_platform_data da850_evm_snd_data = { .tx_dma_offset = 0x2000, .rx_dma_offset = 0x2000, .op_mode = DAVINCI_MCASP_IIS_MODE, .num_serializer = ARRAY_SIZE(da850_iis_serializer_direction), .tdm_slots = 2, .serial_dir = da850_iis_serializer_direction, .asp_chan_q = EVENTQ_1, .version = MCASP_VERSION_2, .txnumevt = 1, .rxnumevt = 1, }; ... da8xx_register_mcasp(0, &da850_evm_snd_data); Now this part is a complete mystery. To have multiple CODECs, do i need to register multiple instances of the McASP driver and fill in the serializer structs for each? And if not, how does it know which input is for which codec? And what are all the fields? There's no documentation whatsoever, so the above was my best guess to get at least one codec functioning. It sort of seems to do something, but all samples are zero and I get lots of overrun errors when using arecord to capture data from it. If there's more you need to know in order to help, don't hesitate to ask, I'll be happy to supply whatever information you need on this. Mike. 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.

1 0

[alsa-devel] [PATCH] ALSA: hda - Set channels count for HBR format
by Wang Xingchao 07 Aug '12

07 Aug '12

If it's HBR format, the channels count should be 8. Signed-off-by: Wang Xingchao <xingchao.wang(a)intel.com> --- sound/pci/hda/patch_hdmi.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index ad319d4..ae4e67e 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -1153,8 +1153,11 @@ static int generic_hdmi_playback_pcm_prepare(struct hda_pcm_stream *hinfo, struct hdmi_spec *spec = codec->spec; int pin_idx = hinfo_to_pin_index(spec, hinfo); hda_nid_t pin_nid = spec->pins[pin_idx].pin_nid; - - hdmi_set_channel_count(codec, cvt_nid, substream->runtime->channels); + + if (is_hbr_format(format)) + hdmi_set_channel_count(codec, cvt_nid, 8); + else + hdmi_set_channel_count(codec, cvt_nid, substream->runtime->channels); hdmi_setup_audio_infoframe(codec, pin_idx, substream); -- 1.7.9.5

3 4

Re: [alsa-devel] [PATCH] ALSA: hda - add dock support for Thinkpad X230
by Takashi Iwai 07 Aug '12

07 Aug '12

At Mon, 6 Aug 2012 23:02:01 +0200, Felix Kaechele wrote: n> > As with the ThinkPad Models X230 Tablet and T530 the X230 needs a qurik to > correctly set up the pins for the dock port. > > Signed-off-by: Felix Kaechele <felix(a)fetzig.org> Applied now (with Cc to stable like others). Thanks. Takashi > --- > sound/pci/hda/patch_realtek.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c > index b9a5c45..6163826 100644 > --- a/sound/pci/hda/patch_realtek.c > +++ b/sound/pci/hda/patch_realtek.c > @@ -6207,6 +6207,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { > SND_PCI_QUIRK(0x17aa, 0x21ca, "Thinkpad L412", ALC269_FIXUP_SKU_IGNORE), > SND_PCI_QUIRK(0x17aa, 0x21e9, "Thinkpad Edge 15", ALC269_FIXUP_SKU_IGNORE), > SND_PCI_QUIRK(0x17aa, 0x21f6, "Thinkpad T530", ALC269_FIXUP_LENOVO_DOCK), > + SND_PCI_QUIRK(0x17aa, 0x21fa, "Thinkpad X230", ALC269_FIXUP_LENOVO_DOCK), > SND_PCI_QUIRK(0x17aa, 0x2203, "Thinkpad X230 Tablet", ALC269_FIXUP_LENOVO_DOCK), > SND_PCI_QUIRK(0x17aa, 0x3bf8, "Quanta FL1", ALC269_FIXUP_QUANTA_MUTE), > SND_PCI_QUIRK(0x17aa, 0x3bf8, "Lenovo Ideapd", ALC269_FIXUP_PCM_44K), > -- > 1.7.11.2 >

1 0

Re: [alsa-devel] [PATCH 1/1] mx27_3ds: Add sound support
by Fabio Estevam 06 Aug '12

06 Aug '12

Gaëtan, On Mon, Aug 6, 2012 at 11:24 AM, Gaëtan Carlier <gcembed(a)gmail.com> wrote: > Hi Fabio, > Sorry, I have missed your patch in my email archive. I didn't search the > right keywords. > I applied your [patch 1/2] (2/2 is already merged) but I have same effect. I > use aplay with file k3b_error1.wav (Unsigned 8 bit, Rate 8000 Hz, Mono) and > alsa/Front_Left.wav (Signed 16 bit Little Endian, Rate 48000 Hz, Mono). Two > sounds are played too fast. > It is maybe a bad configuration of Alsa (but this is working with kernel > 2.6.22 from Freescale). I have just sent the following patch to the alsa-list which fixes this mono playback issue. Regards, Fabio Estevam >From bc46087110bd48a41f1f7dcb826853349662c766 Mon Sep 17 00:00:00 2001 From: Fabio Estevam <fabio.estevam(a)freescale.com> Date: Mon, 6 Aug 2012 16:30:51 -0300 Subject: [PATCH] ASoC: imx-ssi: Fix mono playback Currently mono playback is played on a faster rate. Adjust channels_min to 2 channels in order to play it back correctly. Reported-by: Gaëtan Carlier <gcembed(a)gmail.com> Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- sound/soc/fsl/imx-ssi.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/fsl/imx-ssi.c b/sound/soc/fsl/imx-ssi.c index 28dd76c..c42df31 100644 --- a/sound/soc/fsl/imx-ssi.c +++ b/sound/soc/fsl/imx-ssi.c @@ -380,7 +380,7 @@ static int imx_ssi_dai_probe(struct snd_soc_dai *dai) static struct snd_soc_dai_driver imx_ssi_dai = { .probe = imx_ssi_dai_probe, .playback = { - .channels_min = 1, + .channels_min = 2, .channels_max = 2, .rates = SNDRV_PCM_RATE_8000_96000, .formats = SNDRV_PCM_FMTBIT_S16_LE, -- 1.7.1

1 0

[alsa-devel] [RFC PATCH 0/2] ASoC: add compress stream support
by Vinod Koul 06 Aug '12

06 Aug '12

Here is the much delayed support for compress audio streams in ASoC. This patch series is in RFC form, once we have agreed on this I will send the patches supporting Intel driver as well. Mainly we indicate if the dai is of compressed nature and based on that register a new compressed device. Also the platform driver adds the compress stream operations. Since the codecs handles PCM only, the assumption is that they will not have anything to do here and machine needs to set codec appropriately for compressed streams. In future if codec with such support are available then we can simply add compressed operations into codec as well Comments, criticism welcome... -- Namarta Kohli (1): ASoC: add compress stream support Vinod Koul (1): ASoC: add definations for compressed operations include/sound/compress_driver.h | 1 + include/sound/soc-dai.h | 2 + include/sound/soc.h | 17 ++- sound/soc/Makefile | 2 +- sound/soc/soc-compress.c | 297 +++++++++++++++++++++++++++++++++++++++ sound/soc/soc-core.c | 10 ++- 6 files changed, 326 insertions(+), 3 deletions(-) create mode 100644 sound/soc/soc-compress.c

3 11

[alsa-devel] adding an external dsp under soc-dsp framework
by ziv haziz 06 Aug '12

06 Aug '12

i plan on adding an external dsp which has slimbus interface under soc-dsp framwork. currently i would like to make the following type of connection: CPU->DSP->Codec and as the dsp is an external one (physically seperated from both the CPU and the Codec) i have a difficulty defining how to represent it: do i need to make two entities of the dsp: - one for the BE connection and one for the FE connection and add some internal routing using mixer controls? this will create two devices in the user space which the user application should open? - or is there a way to make one device which is composed of all three blocks? last small question: as slimbus ports id should be passed how do you suggest a device should share his slimbus port id?

2 1

Re: [alsa-devel] [PATCH 1/1] mx27_3ds: Add sound support
by Fabio Estevam 06 Aug '12

06 Aug '12

On Mon, Aug 6, 2012 at 11:24 AM, Gaëtan Carlier <gcembed(a)gmail.com> wrote: > Hi Fabio, > Sorry, I have missed your patch in my email archive. I didn't search the > right keywords. > I applied your [patch 1/2] (2/2 is already merged) but I have same effect. I > use aplay with file k3b_error1.wav (Unsigned 8 bit, Rate 8000 Hz, Mono) and > alsa/Front_Left.wav (Signed 16 bit Little Endian, Rate 48000 Hz, Mono). Two > sounds are played too fast. > It is maybe a bad configuration of Alsa (but this is working with kernel > 2.6.22 from Freescale). Ok, we will need to debug this problem then. Can you please send me offline these two files? Regards, Fabio Estevam

1 0

Re: [alsa-devel] [PATCH 00/27] ASoC: Use module_i2c_driver
by Mark Brown 06 Aug '12

06 Aug '12

On Mon, Aug 06, 2012 at 05:25:33PM +0530, Sachin Kamat wrote: > module_i2c_driver() is helper macro for I2C drivers which do not do anything > special in module init/exit. This eliminates a lot of boilerplate > and calling it replaces module_init() and module_exit(). Applied all, thanks.

1 0