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

[alsa-devel] [PATCH v3 6/6] ARM: DaVinci: ASoC: Add machine driver support for DM646x
by Chaithrika U S 28 May '09

28 May '09

This patch does the following: (1) Add support for the DM646x machine (2)Modifications required to introduce the platform driver model to get platform data for all the machines including dm355 and dm644x. Signed-off-by: Steve Chen <schen(a)mvista.com> Signed-off-by: Pavel Kiryukhin <pkiryukhin(a)ru.mvista.com> Signed-off-by: Naresh Medisetty <naresh(a)ti.com> Signed-off-by: Chaithrika U S <chaithrika(a)ti.com> --- This patch applies against ALSA mainline - the topic/asoc branch of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git sound/soc/davinci/davinci-evm.c | 103 ++++++++++++++++++-------------------- 1 files changed, 49 insertions(+), 54 deletions(-) diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c index 58fd1cb..d66fbd3 100644 --- a/sound/soc/davinci/davinci-evm.c +++ b/sound/soc/davinci/davinci-evm.c @@ -25,11 +25,13 @@ #include <mach/asp.h> #include <mach/edma.h> #include <mach/mux.h> +#include <mach/cpu.h> #include "../codecs/tlv320aic3x.h" +#include "../codecs/spdif_transciever.h" #include "davinci-pcm.h" #include "davinci-i2s.h" - +#include "davinci-i2s-mcasp.h" #define AUDIO_FORMAT (SND_SOC_DAIFMT_DSP_B | \ SND_SOC_DAIFMT_CBM_CFM | SND_SOC_DAIFMT_IB_NF) @@ -43,7 +45,7 @@ static int evm_hw_params(struct snd_pcm_substream *substream, unsigned sysclk; /* ASP1 on DM355 EVM is clocked by an external oscillator */ - if (machine_is_davinci_dm355_evm()) + if (machine_is_davinci_dm355_evm() || machine_is_davinci_dm6467_evm()) sysclk = 27000000; /* ASP0 in DM6446 EVM is clocked by U55, as configured by @@ -144,6 +146,24 @@ static struct snd_soc_dai_link evm_dai = { .ops = &evm_ops, }; +static struct snd_soc_dai_link dm6467_evm_dai[] = { + { + .name = "TLV320AIC3X", + .stream_name = "AIC3X", + .cpu_dai = &davinci_iis_mcasp_dai[DAVINCI_MCASP_I2S_DAI], + .codec_dai = &aic3x_dai, + .init = evm_aic3x_init, + .ops = &evm_ops, + }, + { + .name = "McASP", + .stream_name = "spdif", + .cpu_dai = &davinci_iis_mcasp_dai[DAVINCI_MCASP_DIT_DAI], + .codec_dai = &dit_stub_dai, + .ops = &evm_ops, + }, +}; + /* davinci-evm audio machine driver */ static struct snd_soc_card snd_soc_card_evm = { .name = "DaVinci EVM", @@ -152,12 +172,26 @@ static struct snd_soc_card snd_soc_card_evm = { .num_links = 1, }; +/* davinci dm6467 evm audio machine driver */ +static struct snd_soc_card dm6467_snd_soc_card_evm = { + .name = "DaVinci DM6467 EVM", + .platform = &davinci_soc_platform, + .dai_link = dm6467_evm_dai, + .num_links = ARRAY_SIZE(dm6467_evm_dai), +}; + /* evm audio private data */ static struct aic3x_setup_data evm_aic3x_setup = { .i2c_bus = 1, .i2c_address = 0x1b, }; +/* dm6467 evm audio private data */ +static struct aic3x_setup_data dm6467_evm_aic3x_setup = { + .i2c_bus = 1, + .i2c_address = 0x18, +}; + /* evm audio subsystem */ static struct snd_soc_device evm_snd_devdata = { .card = &snd_soc_card_evm, @@ -165,60 +199,30 @@ static struct snd_soc_device evm_snd_devdata = { .codec_data = &evm_aic3x_setup, }; -/* DM6446 EVM uses ASP0; line-out is a pair of RCA jacks */ -static struct resource evm_snd_resources[] = { - { - .start = DAVINCI_ASP0_BASE, - .end = DAVINCI_ASP0_BASE + SZ_8K - 1, - .flags = IORESOURCE_MEM, - }, -}; - -static struct evm_snd_platform_data evm_snd_data = { - .tx_dma_ch = DAVINCI_DMA_ASP0_TX, - .rx_dma_ch = DAVINCI_DMA_ASP0_RX, -}; - -/* DM335 EVM uses ASP1; line-out is a stereo mini-jack */ -static struct resource dm335evm_snd_resources[] = { - { - .start = DAVINCI_ASP1_BASE, - .end = DAVINCI_ASP1_BASE + SZ_8K - 1, - .flags = IORESOURCE_MEM, - }, -}; - -static struct evm_snd_platform_data dm335evm_snd_data = { - .tx_dma_ch = DAVINCI_DMA_ASP1_TX, - .rx_dma_ch = DAVINCI_DMA_ASP1_RX, +/* evm audio subsystem */ +static struct snd_soc_device dm6467_evm_snd_devdata = { + .card = &dm6467_snd_soc_card_evm, + .codec_dev = &soc_codec_dev_aic3x, + .codec_data = &dm6467_evm_aic3x_setup, }; static struct platform_device *evm_snd_device; static int __init evm_init(void) { - struct resource *resources; - unsigned num_resources; - struct evm_snd_platform_data *data; + struct snd_soc_device *evm_snd_dev_data; int index; int ret; if (machine_is_davinci_evm()) { - davinci_cfg_reg(DM644X_MCBSP); - - resources = evm_snd_resources; - num_resources = ARRAY_SIZE(evm_snd_resources); - data = &evm_snd_data; + evm_snd_dev_data = &evm_snd_devdata; index = 0; } else if (machine_is_davinci_dm355_evm()) { - /* we don't use ASP1 IRQs, or we'd need to mux them ... */ - davinci_cfg_reg(DM355_EVT8_ASP1_TX); - davinci_cfg_reg(DM355_EVT9_ASP1_RX); - - resources = dm335evm_snd_resources; - num_resources = ARRAY_SIZE(dm335evm_snd_resources); - data = &dm335evm_snd_data; + evm_snd_dev_data = &evm_snd_devdata; index = 1; + } else if (machine_is_davinci_dm6467_evm()) { + evm_snd_dev_data = &dm6467_evm_snd_devdata; + index = 0; } else return -EINVAL; @@ -226,17 +230,8 @@ static int __init evm_init(void) if (!evm_snd_device) return -ENOMEM; - platform_set_drvdata(evm_snd_device, &evm_snd_devdata); - evm_snd_devdata.dev = &evm_snd_device->dev; - platform_device_add_data(evm_snd_device, data, sizeof(*data)); - - ret = platform_device_add_resources(evm_snd_device, resources, - num_resources); - if (ret) { - platform_device_put(evm_snd_device); - return ret; - } - + platform_set_drvdata(evm_snd_device, evm_snd_dev_data); + evm_snd_dev_data->dev = &evm_snd_device->dev; ret = platform_device_add(evm_snd_device); if (ret) platform_device_put(evm_snd_device); -- 1.5.6

1 0

[alsa-devel] [PATCH v3 3/6] ARM: DaVinci: ASoC: Introduce platform driver model for dm644x, dm355
by Chaithrika U S 28 May '09

28 May '09

Introduce the platform driver model to get platform data for dm355 and dm644x. Register platform driver and acquire the resources in the probe function Since the platform specific code had been moved from machine driver to dm<soc>.c Signed-off-by: Naresh Medisetty <naresh(a)ti.com> Signed-off-by: Chaithrika U S <chaithrika(a)ti.com> --- This patch applies against ALSA mainline - that's the topic/asoc branch of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git sound/soc/davinci/davinci-i2s.c | 115 ++++++++++++++++++++++----------------- 1 files changed, 66 insertions(+), 49 deletions(-) diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c index b1ea52f..dec7611 100644 --- a/sound/soc/davinci/davinci-i2s.c +++ b/sound/soc/davinci/davinci-i2s.c @@ -436,15 +436,39 @@ static int davinci_i2s_trigger(struct snd_pcm_substream *substream, int cmd, return ret; } -static int davinci_i2s_probe(struct platform_device *pdev, - struct snd_soc_dai *dai) +#define DAVINCI_I2S_RATES SNDRV_PCM_RATE_8000_96000 + +static struct snd_soc_dai_ops davinci_i2s_dai_ops = { + .startup = davinci_i2s_startup, + .trigger = davinci_i2s_trigger, + .hw_params = davinci_i2s_hw_params, + .set_fmt = davinci_i2s_set_dai_fmt, + +}; + +struct snd_soc_dai davinci_i2s_dai = { + .name = "davinci-i2s", + .id = 0, + .playback = { + .channels_min = 2, + .channels_max = 2, + .rates = DAVINCI_I2S_RATES, + .formats = SNDRV_PCM_FMTBIT_S16_LE,}, + .capture = { + .channels_min = 2, + .channels_max = 2, + .rates = DAVINCI_I2S_RATES, + .formats = SNDRV_PCM_FMTBIT_S16_LE,}, + .ops = &davinci_i2s_dai_ops, + +}; +EXPORT_SYMBOL_GPL(davinci_i2s_dai); + +static int davinci_i2s_probe(struct platform_device *pdev) { - struct snd_soc_device *socdev = platform_get_drvdata(pdev); - struct snd_soc_card *card = socdev->card; - struct snd_soc_dai *cpu_dai = card->dai_link->cpu_dai; + struct evm_snd_platform_data *pdata = pdev->dev.platform_data;; struct davinci_mcbsp_dev *dev; - struct resource *mem, *ioarea; - struct evm_snd_platform_data *pdata; + struct resource *mem, *ioarea, *res; int ret; mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); @@ -466,9 +490,7 @@ static int davinci_i2s_probe(struct platform_device *pdev, goto err_release_region; } - cpu_dai->private_data = dev; - - dev->clk = clk_get(&pdev->dev, NULL); + dev->clk = clk_get(&pdev->dev, pdata->clk_name); if (IS_ERR(dev->clk)) { ret = -ENODEV; goto err_free_mem; @@ -476,18 +498,35 @@ static int davinci_i2s_probe(struct platform_device *pdev, clk_enable(dev->clk); dev->base = (void __iomem *)IO_ADDRESS(mem->start); - pdata = pdev->dev.platform_data; dev->dma_params[SNDRV_PCM_STREAM_PLAYBACK] = &davinci_i2s_pcm_out; - dev->dma_params[SNDRV_PCM_STREAM_PLAYBACK]->channel = pdata->tx_dma_ch; dev->dma_params[SNDRV_PCM_STREAM_PLAYBACK]->dma_addr = (dma_addr_t)(io_v2p(dev->base) + DAVINCI_MCBSP_DXR_REG); dev->dma_params[SNDRV_PCM_STREAM_CAPTURE] = &davinci_i2s_pcm_in; - dev->dma_params[SNDRV_PCM_STREAM_CAPTURE]->channel = pdata->rx_dma_ch; dev->dma_params[SNDRV_PCM_STREAM_CAPTURE]->dma_addr = (dma_addr_t)(io_v2p(dev->base) + DAVINCI_MCBSP_DRR_REG); + /* first TX, then RX */ + res = platform_get_resource(pdev, IORESOURCE_DMA, 0); + if (!res) { + dev_err(&pdev->dev, "no DMA resource\n"); + goto err_free_mem; + } + dev->dma_params[SNDRV_PCM_STREAM_PLAYBACK]->channel = res->start; + + res = platform_get_resource(pdev, IORESOURCE_DMA, 1); + if (!res) { + dev_err(&pdev->dev, "no DMA resource\n"); + goto err_free_mem; + } + dev->dma_params[SNDRV_PCM_STREAM_CAPTURE]->channel = res->start; + + davinci_i2s_dai.private_data = dev; + ret = snd_soc_register_dai(&davinci_i2s_dai); + if (ret != 0) + goto err_free_mem; + return 0; err_free_mem: @@ -498,62 +537,40 @@ err_release_region: return ret; } -static void davinci_i2s_remove(struct platform_device *pdev, - struct snd_soc_dai *dai) +static int davinci_i2s_remove(struct platform_device *pdev) { - struct snd_soc_device *socdev = platform_get_drvdata(pdev); - struct snd_soc_card *card = socdev->card; - struct snd_soc_dai *cpu_dai = card->dai_link->cpu_dai; - struct davinci_mcbsp_dev *dev = cpu_dai->private_data; + struct davinci_mcbsp_dev *dev = davinci_i2s_dai.private_data; struct resource *mem; + snd_soc_unregister_dai(&davinci_i2s_dai); clk_disable(dev->clk); clk_put(dev->clk); dev->clk = NULL; - kfree(dev); - mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); release_mem_region(mem->start, (mem->end - mem->start) + 1); -} -#define DAVINCI_I2S_RATES SNDRV_PCM_RATE_8000_96000 + return 0; +} -static struct snd_soc_dai_ops davinci_i2s_dai_ops = { - .startup = davinci_i2s_startup, - .trigger = davinci_i2s_trigger, - .hw_params = davinci_i2s_hw_params, - .set_fmt = davinci_i2s_set_dai_fmt, +static struct platform_driver davinci_mcbsp_driver = { + .probe = davinci_i2s_probe, + .remove = davinci_i2s_remove, + .driver = { + .name = "davinci-asp", + .owner = THIS_MODULE, + }, }; -struct snd_soc_dai davinci_i2s_dai = { - .name = "davinci-i2s", - .id = 0, - .probe = davinci_i2s_probe, - .remove = davinci_i2s_remove, - .playback = { - .channels_min = 2, - .channels_max = 2, - .rates = DAVINCI_I2S_RATES, - .formats = SNDRV_PCM_FMTBIT_S16_LE,}, - .capture = { - .channels_min = 2, - .channels_max = 2, - .rates = DAVINCI_I2S_RATES, - .formats = SNDRV_PCM_FMTBIT_S16_LE,}, - .ops = &davinci_i2s_dai_ops, -}; -EXPORT_SYMBOL_GPL(davinci_i2s_dai); - static int __init davinci_i2s_init(void) { - return snd_soc_register_dai(&davinci_i2s_dai); + return platform_driver_register(&davinci_mcbsp_driver); } module_init(davinci_i2s_init); static void __exit davinci_i2s_exit(void) { - snd_soc_unregister_dai(&davinci_i2s_dai); + platform_driver_unregister(&davinci_mcbsp_driver); } module_exit(davinci_i2s_exit); -- 1.5.6

1 0

[alsa-devel] [PATCH v3 0/6] ARM: DaVinci: Audio support for DM646x
by Chaithrika U S 28 May '09

28 May '09

From: Chaithrika U S <chaithrika(a)ti.com> Add audio support for DM646x Signed-off-by: Naresh Medisetty <naresh(a)ti.com> Signed-off-by: Chaithrika U S <chaithrika(a)ti.com> --- This patch set adds audio support for DM646x This updated version has included most of the review comments received for the previous version of the patch set. This series is dependent on the following patches submitted to the DaVinci mailing list: [PATCH v2 1/2] ARM: DaVinci: EDMA: Move queue related mappings to dm<soc>.c [PATCH v2 2/2] ARM: DaVinci: EDMA: Enable EDMA support for dm646x Patch 1: Adds McASP clock support for the two instances of mcasp(mcasp0,mcasp1) This patch applies to the DaVinci git tree available at http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git Patch 2: Registers the platform devices for ASP on dm355, dm644x and dm646x This patch applies to the DaVinci git tree available at http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git Patch 3: Introduces platform driver model for dm644x and dm355 Applies against ALSA mainline - that's the topic/asoc branch of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git Patch 4: Add dummy codec support Applies against ALSA mainline - that's the topic/asoc branch of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git Patch 5: Adds driver support for the two instances of McASP on TI's DM646x Applies against ALSA mainline - that's the topic/asoc branch of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git Patch 6: Add machine driver support for DM646x Applies against ALSA mainline - that's the topic/asoc branch of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git These patches are based on the work done by Steve Chen <schen(a)mvista.com> and Pavel Kiryukhin <pkiryukhin(a)ru.mvista.com> on Monstavista 2.6.18 kernel.

1 0

[alsa-devel] [PATCH] Compaq Presario CQ60 patching for Conexant
by Tony Vroon 28 May '09

28 May '09

A docking mic control is shown by default. The Compaq Presario CQ60 laptop has no docking connector, so designate it as a CXT5051_HP model. This makes the phantom mixer slider disappear. Signed-off-by: Tony Vroon <tony(a)linx.net> diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index 56ce19e..4fcbe21 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -1848,6 +1848,7 @@ static const char *cxt5051_models[CXT5051_MODELS] = { static struct snd_pci_quirk cxt5051_cfg_tbl[] = { SND_PCI_QUIRK(0x103c, 0x30cf, "HP DV6736", CXT5051_HP_DV6736), + SND_PCI_QUIRK(0x103c, 0x360b, "Compaq Presario CQ60", CXT5051_HP), SND_PCI_QUIRK(0x14f1, 0x0101, "Conexant Reference board", CXT5051_LAPTOP), SND_PCI_QUIRK(0x14f1, 0x5051, "HP Spartan 1.1", CXT5051_HP),

2 1

[alsa-devel] Testers wanted: New SB X-Fi driver
by jimi o'beirne 28 May '09

28 May '09

Takashi Thanks so much for making this driver! Unfortunately, I'm a bit of a newbie, how would I actually install the driver? I am using Ubuntu Jaunty with a SB X-Fi card. Thanks for your help, Jim

1 0

Re: [alsa-devel] [Pkg-alsa-devel] Bug#529940: lib32asound2: symbol versioning changed in an incompatible way
by Elimar Riesebieter 28 May '09

28 May '09

tags 529940 pending forwarded 529940 alsa-devel(a)alsa-project.org thanks * Adeodato Simó [090527 13:53 +0200] > severity 529940 serious > retitle 529940 lib32asound2: symbol versioning changed in an incompatible way (ALSA_0.9.0rc4/8 dropped) > thanks > > Hello, > > it seems that between 1.0.19-1 and 1.0.20-1 the list of symbols in > lib32asound2 changed. More precisely, the list of symbols remained but > their associated versioning changed: all symbols associated with > ALSA_0.9.0rc4 and ALSA_0.9.0rc8 were changed to live under ALSA_0.9 > instead, making applications compiled against <= 1.0.19 fail to start > due to missing symbols. > > Note that this problem affects the 32-bit library in amd64, but not the > native libraries nor in i386 nor amd64. Don't we have to verify it at ppc64 as well? CC'd to debian-ppc. > > Also note that we've started having applications like WINE 1.1.19 in > experimental rebuilt against 1.0.20, and which don't work against > alsa-lib 1.0.19 either. And we'll have no easy way to detect these, > since shlibs are not bumped. > > Will you be able to upload fixed packages in a timely manner? According to [0] I created svn version 2249 on alioth [1]. I've tested it on amd64, were rc4 symbols appeared by checking via readelf. But maybe alsa-devel rechecks the buildsystem of alsa-libs to avoid that dirty hacks? --with-versioned appended to ./configure opts didn't help. [0] http://mailman.alsa-project.org/pipermail/alsa-devel/2009-April/016083.html [1] http://svn.debian.org/wsvn/pkg-alsa/?op=comp&compare[]=%2F@2248&compare[]=%… Jordi, please recheck and upload. Index: debian/rules =================================================================== --- debian/rules (Revision 2248) +++ debian/rules (Arbeitskopie) @@ -39,7 +39,7 @@ endif endif -CFLAGS = -g -Wall +CFLAGS = -g -Wall -DUSE_VERSIONED_SYMBOLS ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) CFLAGS += -O0 -- "Talking much about oneself can also be a means to conceal oneself." -Friedrich Nietzsche

2 1

[alsa-devel] skype and old alsa RC4 symbols
by Jon Smirl 27 May '09

27 May '09

I would like to run pulseaudio 9.15 contained in this ubuntu repository since it fixes my problems with S/PDIF https://launchpad.net/~themuso/+archive/ppa However, the 32b compatibility library in this build don't work with skype since it is missing some RC4 obsolete symbols. jonsmirl@terra:/home/apps/alsa-lib-1.0.19/debian/lib32asound2/usr/lib32$ readelf -W -s libasound.so.2.0.0 | grep snd_pcm_hw_params_get_channels_min 174: 0004a970 58 FUNC WEAK DEFAULT 12 snd_pcm_hw_params_get_channels_min@@ALSA_0.9 454: 0004a970 58 FUNC GLOBAL DEFAULT 12 __snd_pcm_hw_params_get_channels_min@@ALSA_0.9 The 64b library has the missing RC4 symbols. jonsmirl@terra:/home/apps/alsa-lib-1.0.19/debian/libasound2/usr/lib$ readelf -W -s libasound.so.2.0.0 | grep snd_pcm_hw_params_get_channels_min 173: 000000000004ff10 15 FUNC GLOBAL DEFAULT 12 snd_pcm_hw_params_get_channels_min@@ALSA_0.9.0rc4 177: 000000000004ff20 31 FUNC GLOBAL DEFAULT 12 snd_pcm_hw_params_get_channels_min(a)ALSA_0.9 462: 000000000004ff10 15 FUNC GLOBAL DEFAULT 12 __snd_pcm_hw_params_get_channels_min@@ALSA_0.9 jonsmirl@terra:/home/apps/alsa-lib-1.0.19/debian/libasound2/usr/lib$ How do I get the RC4 symbols into the 32 library? I can pull down the source for this and build without problem. I just can't identify what needs to be changed to make the symbols appear in the 32b compat lib. -- Jon Smirl jonsmirl(a)gmail.com

2 2

Re: [alsa-devel] spdif/iec958 outputs at VT1708S not recognized
by Takashi Iwai 27 May '09

27 May '09

At Wed, 27 May 2009 12:35:49 -0400, Sentinel wrote: > > Yeah it didn't work. > > I am lost and generally I can find the answers quickly. I cant use the > "kernel" alsa due to the spdif out and for some reason those undefined > messages just wont go away. I looked into the kernel source and they both > do exist in sound core. I can't imagine what could be wrong. If it's really an ALSA module (not soundcore), it's often because you didn't unload some old modules before loading a new one. Also, if the old modules are also update modules located in /lib/modules/$VERSION/update or so, then the old modules will still win over the newly installed one in /lib/modules/$VERSION/kernel/sound/*. IIRC, Ubuntu or some others install the update modules there. In such a case, you'll need to specify the installation path explicitly via configure option, too. If it's the sound core, you need to make sure that this is really built in, either into the kernel or as a module. And, the kernel tree really points to the version you are running. There are symbols to be referred, so it's not only the source you need to build external modules. At best, you should consult on user forum (or such) for your own distro, since this topic is really distro-specific. Takashi > > -----Original Message----- > From: Takashi Iwai [mailto:tiwai@suse.de] > Sent: Wednesday, May 27, 2009 1:35 AM > To: Sentinel > Cc: alsa-devel(a)alsa-project.org > Subject: Re: [alsa-devel] spdif/iec958 outputs at VT1708S not recognized > > At Tue, 26 May 2009 22:57:31 -0400, > Sentinel wrote: > > > > Okay I figured out my own problem. > > > > > > > > This is specific to those who run 64bit OS. > > > > > > > > for anyone who is getting register_sound_special_device error when > > attempting to compile ALSA, on a 64 bit OS make sure your running your > > configure properly. Most likely your distro has ALSA libraries located in > > the /usr/lib64 path not in /usr/lib and most likely the ld.so.conf is set > to > > look in /usr/lib64 before it searches /usr/lib which is the default for > the > > configure script. As a warning I'd not try to change that order > especially > > if you have built any 32bit compatibility drivers into /usr/lib > > I guess you are looking at a wrong place. > The fix must be coincident :) > > Basically alsa-driver (and kernel) compilation doesn't use any > user-space library, so libpath is irrelevant. The only important > location is the kernel source tree and its build stub. If these > aren't set up properly, such an error (version mismatch or so) may > happen. > > Note that sound_register_special() and co aren't defined in the ALSA > driver, but it's defined in sound_core.c in the kernel. > > > Takashi > >

1 0

[alsa-devel] ASoC updates for 2.6.31
by Mark Brown 27 May '09

27 May '09

The following changes since commit 0f89bdcac61536c5cb2a095a514657019573afb4: Peter Ujfalusi (1): ASoC: TWL4030: HandsfreeL/R mute DAPM switch are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git for-2.6.31 Jon Smirl (4): ASoC: Main rewite of the mpc5200 audio DMA code ASoC: AC97 driver for mpc5200 ASoC: Support for AC97 on Phytec pmc030 base board. ASoC: Fabric bindings for STAC9766 on the Efika Mark Brown (2): ASoC: Mark MPC5200 AC97 as BROKEN until PowerPC merge issues are resolved ASoC: Switch FSL SSI DAI over to symmetric_rates sound/soc/fsl/Kconfig | 28 +++- sound/soc/fsl/Makefile | 5 + sound/soc/fsl/efika-audio-fabric.c | 90 +++++++ sound/soc/fsl/fsl_ssi.c | 9 +- sound/soc/fsl/mpc5200_dma.c | 442 ++++++++++++++++++++++------------- sound/soc/fsl/mpc5200_dma.h | 33 ++-- sound/soc/fsl/mpc5200_psc_ac97.c | 331 ++++++++++++++++++++++++++ sound/soc/fsl/mpc5200_psc_ac97.h | 15 ++ sound/soc/fsl/mpc5200_psc_i2s.c | 247 ++++---------------- sound/soc/fsl/mpc5200_psc_i2s.h | 12 + sound/soc/fsl/pcm030-audio-fabric.c | 90 +++++++ 11 files changed, 905 insertions(+), 397 deletions(-) create mode 100644 sound/soc/fsl/efika-audio-fabric.c create mode 100644 sound/soc/fsl/mpc5200_psc_ac97.c create mode 100644 sound/soc/fsl/mpc5200_psc_ac97.h create mode 100644 sound/soc/fsl/mpc5200_psc_i2s.h create mode 100644 sound/soc/fsl/pcm030-audio-fabric.c

2 1

Re: [alsa-devel] 2.6.30: xruns caused by "ALSA: pcm - Safer boundary checks"
by Takashi Iwai 27 May '09

27 May '09

At Tue, 26 May 2009 13:16:49 -0400, Robert Krakora wrote: > > On Tue, May 26, 2009 at 11:41 AM, Takashi Iwai <tiwai(a)suse.de> wrote: > > At Tue, 26 May 2009 10:28:26 -0400, > > Robert Krakora wrote: > >> > >> On Tue, May 26, 2009 at 4:03 AM, Takashi Iwai <tiwai(a)suse.de> wrote: > >> > At Sun, 24 May 2009 23:56:40 -0700, > >> > Nathan Grennan wrote: > >> >> > >> >> Takashi Iwai wrote: > >> >> > Testing the patch would be helpful :) > >> >> > > >> >> > >> >> Will do > >> > > >> > Did you get any positive / negative result? > >> > > >> > We are in the late rc stage, so a fix should be merged ASAP... > >> > > >> > > >> > thanks, > >> > > >> > Takashi > >> > _______________________________________________ > >> > Alsa-devel mailing list > >> > Alsa-devel(a)alsa-project.org > >> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > >> > > >> > > >> > >> Takashi: > >> > >> I cannot speak for the other person experiencing this problem. > >> However, neither your snapshot or Jarloslav's patch corrected the > >> problem which I am experiencing. > > > > So, did you get the same kernel messages when xrun_debug is set? > > > >> I have not looked at the code much > >> in pcm_lib.c or pcm_native.c but it seems as though you are trying to > >> manage FIFO overflow and underflow scenarios. Is my assumption > >> correct? ;-) > > > > No. The problem appears like an invalid check of jiffies in > > snd_pcm_hw_ptr_update*(). After the pause, jiffies isn't recorded > > properly, thus it gets screwed up. > > > > To be sure, could you try the patch below? This will disable the > > jiffies check completely. If the problem still happens, then it's > > somewhere else where we need to check. > > > > > > thanks, > > > > Takashi > > > > --- > > diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c > > index a2a792c..47837a6 100644 > > --- a/sound/core/pcm_lib.c > > +++ b/sound/core/pcm_lib.c > > @@ -249,6 +249,7 @@ static int snd_pcm_update_hw_ptr_interrupt(struct snd_pcm_substream *substream) > > new_hw_ptr = hw_base + pos; > > } > > } > > +#if 0 /* no jiffies check */ > > /* Skip the jiffies check for hardwares with BATCH flag. > > * Such hardware usually just increases the position at each IRQ, > > * thus it can't give any strange position. > > @@ -279,6 +280,7 @@ static int snd_pcm_update_hw_ptr_interrupt(struct snd_pcm_substream *substream) > > delta = 0; > > } > > no_jiffies_check: > > +#endif /* no jiffies check */ > > if (delta > runtime->period_size + runtime->period_size / 2) { > > hw_ptr_error(substream, > > "Lost interrupts? " > > @@ -336,6 +338,7 @@ int snd_pcm_update_hw_ptr(struct snd_pcm_substream *substream) > > hw_base = 0; > > new_hw_ptr = hw_base + pos; > > } > > +#if 0 /* no jiffies check */ > > if (((delta * HZ) / runtime->rate) > jdelta + HZ/100) { > > hw_ptr_error(substream, > > "hw_ptr skipping! " > > @@ -345,6 +348,7 @@ int snd_pcm_update_hw_ptr(struct snd_pcm_substream *substream) > > ((delta * HZ) / runtime->rate)); > > return 0; > > } > > +#endif /* no jiffies check */ > > if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK && > > runtime->silence_size > 0) > > snd_pcm_playback_silence(substream, new_hw_ptr); > > > > > > Takashi: > > Your patch worked. jiffies seems to be the cause. xrun_debug is on > and I do not see any of the error messages. [Re-added some dropped addresses to Cc] Thanks for testing! I have an impression that the jiffies check can behave pretty buggy in cases the hardware doesn't give a smooth pointer update. It's supposed to filter out spontaneous invalid pointer values. That'll work indeed (although I don't think the check in snd_pcm_period_elapsed() is worth). But what if a hardware returns the pointer value that is not always updated smoothly? Assume a hardware returning only spontaneously updated values, 0 at t=0, 1000 at t=100, 2000 at t=200, and so on. If snd_pcm_update_hw_ptr() is called at t=99, it gets still position 0. Then when it's called at t=100, it suddenly increases to position 1000 while jiffies delta is only 1. The current code would filter out this update because it appears as if too much. The problem continues, if snd_pcm_update_hw_ptr() is constantly called at each t=100, 101, ... At each call, jiffies delta is 1, but the position delta is still 1000 because it wasn't updated. That is, as long as the app keeps calling snd_pcm_update_hw_ptr(), the position won't be updated. This is pretty possible especially with an app like pulseaudio. I have a feeling that we should disable the jiffies check in that part, at least for 2.6.30, until a better solution is found. The jiffies check is already done and works pretty well in the driver side (hda-intel and intel8x0). But this check in the PCM core can be (not always, though) buggy, and actually gives problems sometimes. Takashi

3 3