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

Re: [alsa-devel] ASoC MPC5xxx PSC AC97 audio driver
by jonsmirl＠gmail.com 08 Sep '11

08 Sep '11

On Thu, Sep 8, 2011 at 6:16 AM, David Jander <david.jander(a)protonic.nl> wrote: > > Dear Jon, Here's the device tree... http://git.digispeaker.com/?p=digispeaker-kernel.git;a=blob;f=arch/powerpc/… Grant can comment on the current bindings. We switched onto ARM based hardware a couple of years ago. We're looking the the iMX502 for a current design. > > I am busy writing an AC97 ASoC driver for the MPC5121e processor from > Freescale, and was using your MPC5200 driver as a starting point. I would > really like to make the driver as unified as possible, but I was encountering > some problems that make me think that maybe your driver as included in current > mainline linux (3.1-rc2 for me atm) is not working anymore. Do you know if it > is still working? > Unfortunately I have little experience with ALSA drivers, so I might not > be doing things entirely in the correct way. Nevertheless I was unable to get > the driver/device binding working the way you did, and I don't have a MPC5200 > platform with AC97 codec to try out your code :-( > > Here's what I don't quite get: > > mpc5200_dma.c seems to be the proper PCM driver, which has an OF compatible > string of "fsl,mpc5200-pcm", but I can't find any DTS which declares such a > node. Apparently the driver is somehow bound by ALSA via the platform name > "mpc5200-pcm-audio" via the specific fabric drivers, but that seems to happen > in the opposite order than it is supposed to: In my case, first the AC97 driver > is probed (i.e. mpc5200_psc_ac97.c), which expects the driver data to be > already initialized by the dma part, which it isn't, so the kernel oopses in > line 288 of mpc5200_psc_ac97.c: > > static int __devinit psc_ac97_of_probe(struct platform_device *op) > { > ... > 287 psc_dma = dev_get_drvdata(&op->dev); > 288 regs = psc_dma->psc_regs; > 289 ac97.private_data = psc_dma; > ... > > Am I doing something wrong or has this indeed changed in recent versions of > the kernel? > > I do have the driver working now, but I had to turn things around and kzalloc() > the drvdata struct "psc_dma" in the AC97 part of the driver. Of course this > makes unifying the driver quite an ugly job. > > Also, currently, my driver is not using DMA, but a work-queue to keep the FIFO > filled ;-) > > To get DMA working, I still need to extend the existing DMA driver which can > only do memory->memory transfers right now. Unfortunately this part is totally > different from the MPC5200B, which uses a bestcomm DMA controller, so I would > like to end up creating a new file "mpc5121_dma.c" and extending > "mpc5200_psc_ac97.c" so it does the mpc5121e-specific cold-reset. The rest is > basically the same.... except for the fact that I get the oops mentioned above > unless I do the PSC register setup and drvdata allocation in > psc_ac97_of_probe()! Is this also broken for the MPC5200B and do I need to fix > it for both? > > Also, I'd like to work towards generic fabric code for all the cases of > "generic AC97 codec connected to a PSC". Maybe this can be OF-ified somehow? > > Thanks a lot for any hint. > > Best regards, > > -- > David Jander > Protonic Holland. > -- Jon Smirl jonsmirl(a)gmail.com

1 0

Re: [alsa-devel] Player Thread is not woken after period elapsed
by Nallasellan, Singaravelan 08 Sep '11

08 Sep '11

> > > Further investigation of this issue shows that the thread is in running state > and it is not scheduled. I am not sure how I will go about debugging this issue. > Any pointer would help. > > > > Could you confirm if [commit f26f9af Sched: fix skip_clock_update > > optimization] residents in your kernel? I applied this patch manually. I still see the issue. > > And commit da7a735e51f9622eb3e1672594d4a41da01d7e4f > http://marc.info/?l=linux-kernel&m=129527509622696&w=2 This is already applied.

1 0

[alsa-devel] alsa driver playback using aplay fails
by Appalayagari Sreedhar 08 Sep '11

08 Sep '11

Hi, I have integrated the cx2070x codec driver which is in ALSA model. I am trying to test the codec driver using the aplay command. in my code CPU is the master and codec is the slave. The Audio format which i used is : #define AUDIO_FORMAT (SND_SOC_DAIFMT_I2S | \ SND_SOC_DAIFMT_CBS_CFS | SND_SOC_DAIFMT_IB_NF) when i run the aplay command. aplay Front_Center.wav the codec driver is opening and shutting down. please find the log. the CPU is TI processsor. davinci_i2s_startup davinci_i2s_startup snd_soc_set_runtime_hwparams asoc: cx2070x <-> davinci-mcbsp info: asoc: rate mask 0x6fe asoc: min ch 2 max ch 2 asoc: min rate 8000 max rate 96000 Playing WAVE 'Front_Center.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono soc_pcm_hw_params davinci_i2s_set_dai_fmt davinci_i2s_set_dai_fmt cx2070x_hw_params 4294941454: cx2070x_hw_params() called format:2 speed:48000 davinci_i2s_hw_params soc_pcm_prepare davinci_i2s_prepare davinci_mcbsp_stop davinci_mcbsp_stop davinci_i2s_prepare soc_pcm_trigger davinci_i2s_trigger davinci_i2s_trigger soc_pcm_trigger davinci_i2s_trigger davinci_mcbsp_stop davinci_mcbsp_stop davinci_i2s_trigger soc_pcm_hw_free soc_pcm_hw_free soc_codec_close davinci_i2s_shutdown davinci_mcbsp_stop davinci_mcbsp_stop davinci_i2s_shutdown # pop wq checking: Playback status: inactive waiting: yes Could you please tell me where i am doing wrong? Thank you, Sreedhar.

2 2

[alsa-devel] ASoC: auto-loading board-specific modules
by Mans Rullgard 08 Sep '11

08 Sep '11

Currently in ASoC, there is for each supported board a module describing the board-specific DAI links by creating a "soc-audio" platform device with an associated struct snd_soc_card. The problem with this is that these modules are not automatically loaded by udev (or other device-scanning mechanisms) so some intervention is required before sound will work. I can think of a few different ways to make everything happen automatically: 1. Build the board-specific bits into the platform modules which are already loaded as platform drivers. 2. Create another platform device whose only function is to cause the board modules to be loaded. 3. Something entirely different. Someone had a recollection of the current scheme being introduced as a "temporary" solution a couple of years ago, in which case it is about time it got fixed. I'd appreciate some input on which direction to pursue this before spending time on a potentially inappropriate solution. -- Mans Rullgard Multimedia mans.rullgard(a)linaro.org

2 3

Re: [alsa-devel] [PATCH v2] ASoC: omap: add MODULE_ALIAS to mcbsp and pcm drivers
by Mark Brown 08 Sep '11

08 Sep '11

On Wed, Sep 07, 2011 at 12:07:21PM +0100, Mans Rullgard wrote: > This adds MODULE_ALIAS directives to the omap-mcbsp-dai and > omap-pcm-audio drivers so they can be auto-loaded when platform > devices are scanned. Acked-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com>

2 1

Re: [alsa-devel] [PATCH 60/62] sound: irq: Remove IRQF_DISABLED
by Mark Brown 07 Sep '11

07 Sep '11

On Wed, Sep 07, 2011 at 04:10:57PM +0800, Yong Zhang wrote: > This flag is a NOOP and can be removed now. > > Signed-off-by: Yong Zhang <yong.zhang0(a)gmail.com> Acked-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com>

1 0

Re: [alsa-devel] [PATCH 60/62] sound: irq: Remove IRQF_DISABLED
by Péter Ujfalusi 07 Sep '11

07 Sep '11

On Wednesday 07 September 2011 16:10:57 Yong Zhang wrote: > This flag is a NOOP and can be removed now. > > Signed-off-by: Yong Zhang <yong.zhang0(a)gmail.com> ... > sound/soc/codecs/tlv320dac33.c | 2 +- .. > diff --git a/sound/soc/codecs/tlv320dac33.c b/sound/soc/codecs/tlv320dac33.c > index faa5e9f..243d177 100644 > --- a/sound/soc/codecs/tlv320dac33.c > +++ b/sound/soc/codecs/tlv320dac33.c > @@ -1431,7 +1431,7 @@ static int dac33_soc_probe(struct snd_soc_codec > *codec) /* Check if the IRQ number is valid and request it */ > if (dac33->irq >= 0) { > ret = request_irq(dac33->irq, dac33_interrupt_handler, > - IRQF_TRIGGER_RISING | IRQF_DISABLED, > + IRQF_TRIGGER_RISING, > codec->name, codec); > if (ret < 0) { > dev_err(codec->dev, "Could not request IRQ%d (%d)\n", Acked-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com>

1 0

[alsa-devel] Alsa for OSX
by Peter Lapisu 07 Sep '11

07 Sep '11

hello iam using a Lion 10.7.2 hackintosh with the ASUS Maximus IV Gene Z my adudio is SupremeFX X-Fi 2 is there any version of Alsa for OSX ? as the Voodoo drivers causes a kernel panic and the AppleHDA drivers causes problems too i read that under linux, to use my audio (SupremeFX X-Fi 2), i need ALSA... i know OSX isnt linux, but is there an OSX support? thanks

3 2

[alsa-devel] [PATCH] [PATCH]ASoC:blackfin:add ad73311 card driver name
by Scott Jiang 07 Sep '11

07 Sep '11

ASoC doesn't copy codec name to card driver now. ALSA lib need this info to find the proper card config. So add card name in snd_soc_card, asoc will copy this name to snd_card. Signed-off-by: Scott Jiang <scott.jiang.linux(a)gmail.com> --- sound/soc/blackfin/bf5xx-ad73311.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sound/soc/blackfin/bf5xx-ad73311.c b/sound/soc/blackfin/bf5xx-ad73311.c index 732a247..975c6e8 100644 --- a/sound/soc/blackfin/bf5xx-ad73311.c +++ b/sound/soc/blackfin/bf5xx-ad73311.c @@ -192,6 +192,7 @@ static struct snd_soc_dai_link bf5xx_ad73311_dai[] = { static struct snd_soc_card bf5xx_ad73311 = { .name = "bfin-ad73311", + .driver_name = "AD73311", .probe = bf5xx_probe, .dai_link = &bf5xx_ad73311_dai[CONFIG_SND_BF5XX_SPORT_NUM], .num_links = 1, -- 1.7.0.4

2 2

Re: [alsa-devel] [PATCH] ASoC: Add driver for rt5631
by Mark Brown 06 Sep '11

06 Sep '11

On Tue, Sep 06, 2011 at 06:32:42PM +0800, johnnyhsu(a)realtek.com wrote: > switch (reg) { > - case RT5631_VENDOR_ID: > - case RT5631_VENDOR_ID1: > - case RT5631_VENDOR_ID2: > - return 0; > - default: > + case RT5631_RESET: > + case RT5631_INT_ST_IRQ_CTRL_2: > + case RT5631_INDEX_ADD: > + case RT5631_INDEX_DATA: > + case RT5631_EQ_CTRL: > return 1; > + default: > + return 0; This is an incremental patch against your previous driver, not a full patch. You should always send a patches which can be applied against current kernels. > - pr_info("enter %s, syclk=%d\n", __func__, freq); > + dev_info(codec->dev, "enter %s, syclk=%d\n", __func__, freq); This should be a debug level print at most, otherwise you just spam the console. > if (!freq_in || !freq_out) { > dev_dbg(codec->dev, "PLL disabled\n"); > - return -EINVAL; > + return 0; I'd expect to see some sort of register write when the PLL is disabled? > /** > - * rt5631_index_reg_show - sysfs file for dumping index registers of 2nd layer > + * rt5631_index_reg_show: Show private register of rt5631 codec. > + * @dev: device to query. > + * @attr: device attribute. > + * @buf: buffer to display. > + * > + * To show private registers which are not changed often by user. > + * You have to access them through register 0x6a and 0x6c. > */ > static ssize_t rt5631_index_reg_show(struct device *dev, > struct device_attribute *attr, char *buf) As I've told you repeatedly you should be using the standard facilities for debug access to registers - you should not open coding this in your driver. Once again, ignoring review comments isn't helpful.

1 0