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

[alsa-devel] [PATCH 1/4] ASoC: DaVinci: remove requirement that dma_params is 1st in structure
by Troy Kisky 13 Jul '10

13 Jul '10

Remove requirement that dma_params is 1st in the structures davinci_audio_dev and davinci_mcbsp_dev. Signed-off-by: Troy Kisky <troy.kisky(a)boundarydevices.com> --- sound/soc/davinci/davinci-i2s.c | 6 +----- sound/soc/davinci/davinci-mcasp.c | 1 + sound/soc/davinci/davinci-mcasp.h | 5 ----- sound/soc/davinci/davinci-pcm.c | 7 ++++--- 4 files changed, 6 insertions(+), 13 deletions(-) diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c index 4ae7070..9e69a4e 100644 --- a/sound/soc/davinci/davinci-i2s.c +++ b/sound/soc/davinci/davinci-i2s.c @@ -98,11 +98,6 @@ enum { }; struct davinci_mcbsp_dev { - /* - * dma_params must be first because rtd->dai->cpu_dai->private_data - * is cast to a pointer of an array of struct davinci_pcm_dma_params in - * davinci_pcm_open. - */ struct davinci_pcm_dma_params dma_params[2]; void __iomem *base; #define MOD_DSP_A 0 @@ -547,6 +542,7 @@ static int davinci_i2s_probe(struct platform_device *pdev) dev->dma_params[SNDRV_PCM_STREAM_CAPTURE].channel = res->start; davinci_i2s_dai.private_data = dev; + davinci_i2s_dai.dma_data = dev->dma_params; ret = snd_soc_register_dai(&davinci_i2s_dai); if (ret != 0) goto err_free_mem; diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c index 5d1f98a..5023915 100644 --- a/sound/soc/davinci/davinci-mcasp.c +++ b/sound/soc/davinci/davinci-mcasp.c @@ -907,6 +907,7 @@ static int davinci_mcasp_probe(struct platform_device *pdev) dma_data->channel = res->start; davinci_mcasp_dai[pdata->op_mode].private_data = dev; + davinci_mcasp_dai[pdata->op_mode].dma_data = dev->dma_params; davinci_mcasp_dai[pdata->op_mode].dev = &pdev->dev; ret = snd_soc_register_dai(&davinci_mcasp_dai[pdata->op_mode]); diff --git a/sound/soc/davinci/davinci-mcasp.h b/sound/soc/davinci/davinci-mcasp.h index 9d179cc..582c924 100644 --- a/sound/soc/davinci/davinci-mcasp.h +++ b/sound/soc/davinci/davinci-mcasp.h @@ -39,11 +39,6 @@ enum { }; struct davinci_audio_dev { - /* - * dma_params must be first because rtd->dai->cpu_dai->private_data - * is cast to a pointer of an array of struct davinci_pcm_dma_params in - * davinci_pcm_open. - */ struct davinci_pcm_dma_params dma_params[2]; void __iomem *base; int sample_rate; diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c index c73a915..c2c2e85 100644 --- a/sound/soc/davinci/davinci-pcm.c +++ b/sound/soc/davinci/davinci-pcm.c @@ -238,10 +238,11 @@ static int davinci_pcm_open(struct snd_pcm_substream *substream) struct davinci_runtime_data *prtd; int ret = 0; struct snd_soc_pcm_runtime *rtd = substream->private_data; - struct davinci_pcm_dma_params *pa = rtd->dai->cpu_dai->private_data; - struct davinci_pcm_dma_params *params = &pa[substream->stream]; - if (!params) + struct davinci_pcm_dma_params *pa = rtd->dai->cpu_dai->dma_data; + struct davinci_pcm_dma_params *params; + if (!pa) return -ENODEV; + params = &pa[substream->stream]; snd_soc_set_runtime_hwparams(substream, &davinci_pcm_hardware); /* ensure that buffer size is a multiple of period size */ -- 1.5.6.3

3 5

[alsa-devel] Verifying mixer dB data/Invalid dB data from USB cards, especially Aureon 5.1 MkII
by Lennart Poettering 25 Jun '10

25 Jun '10

Heya, a while back I wrote a little tool "dbmeasure" which can be used to determine dB attenuation data for alsa mixer controls. I have now extended this little dB tools suite to include a tiny tool "dbverify" that can be used to verify the correctness of existing dB data exposed by the drivers. It should be relatively easy to use that tool, suitable even for non-guru folks who want to debug the dB information from alsa. http://git.0pointer.de/?p=dbmeasure.git git://git.0pointer.de/dbmeasure.git Just run "make" in a git checkout and then try: $ ./dbverify Aureon51MkII Master 30 200 That will verify the dB data of the "Master" control of the sound card that goes by the id "Aureon51MkII". It will compare the discrete volume steps 30 and 200: first it will play a full amplitude sine wave at mixer volume step 30, and then will change to mixer volume step 200, but attenuate the sine wave in software compensating for the volume change. So once you hear the sine wave attenuated by the hw, and once by the software. If the card's dB data is correct both sines should have the same volume. Now, playing around with this, I could verify what I already mentioned to Jarsolav elsewhere earlier: it seems that particularly USB cards seem to expose invalid dB data (at least all mine do). For example, for the above mentioned Aureon 5.1 it's really *way* off -- if you posess that card just run the line above, and listen to the difference. It's really bad. OTOH the dB data of the HDA cards I own is pretty accurate as it seems, at least I was unable to decide just by listening which sine wave was attenuated by sw, and which by hw. Getting back to the invalid dB data from the USB cards: the question is whether the USB descriptor data is badly parsed, and the dB mismatch hence systematic for USB cards, or if these cards are just crappy and include invalid data? In which case I wonder what we could do about that? The Aureon's dB range already looks suspicous, since both the max and the min dB value are < 0 (-47.69 to -1.97), so maybe we could add some heuristics to filter out data that already looks suspicous? Invalid dB data from the driver is a real problem for the "flat volume" logic in PA. We basically allow each app to control the full hw volume range individually, and then set the hw volume to the max of what all apps wanted and attenuate the other streams accordingly. On the Aureon this doesn't work at all, since the attenuation of the streams is miscalculated due to the invalid dB data. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4

8 93

Re: [alsa-devel] Crash 2.6.32.x, Echo 3G, Alsa, SCSI
by Clemens Ladisch 03 Jun '10

03 Jun '10

Frederick V Heitkamp wrote: > Repeatable Hard Crash. > What else do I need to provide? > > [ 5484.995249] WriteControlReg: not written, no change > [ 5485.069621] divide error: 0000 [#1] pcm_hw_params ok > [ 5485.070159] Prepare rate=44100 format=2 channels=2 > [ 5485.070161] set_audio_format[14] = 5 > [ 5485.070166] Prepare rate=44100 format=2 channels=2 > [ 5485.070167] set_audio_format[14] = 5 > [ 5485.070003] PREEMPT SMP > ... > [ 5485.070003] EIP is at pcm_pointer+0x37/0x70 [snd_echo3g] > ... > [ 5485.965788] [<c10041c0>] ? do_divide_error+0x0/0x90 > [ 5485.980619] [<f87aa037>] ? pcm_pointer+0x37/0x70 [snd_echo3g] > [ 5485.998047] [<c104764e>] ? run_timer_softirq+0x17e/0x2e0 > [ 5486.014175] [<f87ac9bf>] ? snd_echo_interrupt+0x11f/0x240 [snd_echo3g] > [ 5486.033940] [<c107a5d5>] ? handle_IRQ_event+0x45/0x190 bytes_to_frames() divides by runtime->frame_bits which is not set until after the hw_params callback has succeeded, but the corresponding chip->substream[] entry is set in that callback, by init_engine(). It should probably have been set in the prepare callback. Frederick, please try the patch below. Takashi, is there any reason why the runtime-> fields are initialized after the hw_params callback? Regards, Clemens --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -403,12 +403,6 @@ if (err < 0) goto _error; - if (substream->ops->hw_params != NULL) { - err = substream->ops->hw_params(substream, params); - if (err < 0) - goto _error; - } - runtime->access = params_access(params); runtime->format = params_format(params); runtime->subformat = params_subformat(params); @@ -446,6 +440,13 @@ runtime->boundary *= 2; snd_pcm_timer_resolution_change(substream); + + if (substream->ops->hw_params != NULL) { + err = substream->ops->hw_params(substream, params); + if (err < 0) + goto _error; + } + runtime->status->state = SNDRV_PCM_STATE_SETUP; pm_qos_remove_requirement(PM_QOS_CPU_DMA_LATENCY,

6 10

[alsa-devel] usbaudio: Support for USB audio v2.0 devices
by Daniel Mack 27 May '10

27 May '10

Hi, I've been working on support for USB devices compliant to audio class v2.0 and would like to share what I got. First problem is that they literally changed every single descriptor type by adding or removing fields or changing their width, respectively. Even worse, some enum values were dropped and reassigned so their numerical value has a different meaning now. My first step was to clean up most of the existing descriptor parsers by moving away from anonymous byte array access to real structs so we can see which fields we're actually dereferencing. In a second step, I added definitions for the replacement descriptors and use them at appropriate places. The bInterfaceProtocol field must always be set correctly of course, otherwise we'll parse garbage. Other things that have changed from v1.0 to v2.0 are: * The number of streaming interfaces is now reported by a standard interface association descriptor. The old approach using a proprietary descriptor extension is deprecated. * The number of channels per interface is now stored in the AS_GENERAL descriptor (used to be part of the FORMAT_TYPE descriptor). * The list of supported sample rates is no longer stored in a variable length appendix of the FORMAT_TYPE descriptor but is retrieved from the device using a class specific GET_RANGE command. * Supported sample formats are now reported as 32bit bitmap rather than as a fixed value. For now, this is worked around by choosing just one of them. Eventually, the code should propagate the full ability of the device. * A devices needs to have at least one CLOCK_SOURCE descriptor which denotes a clockID that is needed as argument to the class request command. If can have more than one though and the host driver is in charge to choose the right one. There are also new types for clock selectors and sample rate converters that a device might report. This is all unsupported at the moment. We only parse the first CLOCK_SOURCE and take this one. * Many descriptors (format_type, ...) have changed their layout. Handle this by casting the descriptors to the appropriate structs. With the following patches applied, a v2.0 device is recognized and reported as ALSA device. I can even hear at least some kind of music, but the sample rate setting does not yet seem to be correct. Also, the existing mixer code does not work at all for v2.0 devices. This will be quite some work to support that and I fear the whole thing must be reimplemented for v2.0 specifically. For now, I worked around that by not parsing them at all but bailing out very early. However, I would like to make sure the changes I made so far won't cause any regression for v1.0 devices, and so it would be good to see them applied as a preliminary support. I'll continue working on this and send more updates along. Let me know what you think. Thanks, Daniel

5 33

[alsa-devel] safe support for rewind in ALSA
by pl bossart 04 May '10

04 May '10

All, I'd like to reopen a thread on concerns with the current implementation of rewind in ALSA. This was already discussed on the mailing list last year without any progress. (see http://thread.gmane.org/gmane.linux.alsa.devel/65759/focus=65773 and http://article.gmane.org/gmane.linux.alsa.devel/66902) The problem is that snd_pcm_rewind() allows in theory to go back to the next sample to be rendered. This however isn't possible on any existing hardware. DMAs do prefetch samples ahead of time, and output interfaces have FIFOs on top of this. This isn't too bad in the PC world with HDAudio, since the prefetching is limited. However in the embedded space it has become a headache. To reduce power consumption, most of the recent embedded interfaces do embed some local internal memory (5kB for TI's McBSP3, a lot more for others), and we should provide a means for driver developers to set a bound on how much can be rewound safely when power-saving features are enabled. Note that there already are a set of definitions for FIFOs, but they are either obsolete or no one uses them (actually HDAudio makes use of this value internally in azx_dev but doesn't export it). My suggestion would be to add a 'fifo' parameter to the runtime structure (so that it's visible to the core), let the driver developer fill the value in the .open routine, and use this parameter in rewind to prevent rewinding too much. This parameter would include both hardware FIFOs and DMA buffers. Comments welcome. - Pierre

7 41

[alsa-devel] alsactl restore: unknown hardware: ymf724f
by Angel Tsankov 02 Apr '10

02 Apr '10

Hello, I run 'alsactl restore' on a machine with 2 sound cards -- a built-in Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02) and a non-built-in Yamaha Corporation YMF-724F [DS-1 Audio Controller] (rev 03) -- and get the following message: Unknown hardware: "YMF724F" "SigmaTel STAC9700,83,84" "AC97a:83847600" "0x1073" "0x000d" Hardware is initialized using a guess method As a consequence the volume levels of the Yamaha card do not get restored to the levels stored in /etc/asound.state. The volume levels of the built-in card however are properly restored. The asound.state file has been created by executing 'alsactl store'. The kernel has been built with support for ALSA. I've built and installed the kernel modules for both cards (not the ones in the alsa-driver package but those that come with kernel version 2.6.30.2). Any ideas why alsactl cannot find the hardware it has previously identified as "YMF724F", "SigmaTel STAC9700,83,84", and so on? Regards, Angel Tsankov

4 26

[alsa-devel] snd-hda-intel: no data when recording from mic, "IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj" logged in kern.log
by Aleksander Adamowski 17 Mar '10

17 Mar '10

Hi! I think I have some interesting problems to analyse for Takashi. Maybe my sound card model is a non typical one, but I have a continuous stream of capture-related problems with it. It's an integrated sound card on my Gigabyte GA-MA74GM-S2H Rev. 1.1 motherboard. "grep ^Codec /proc/asound/card0/codec#0" shows: Codec: Realtek ALC888 I'm attaching the full contents of /proc/asound/card0/codec#0 for identification. But first, some background. With this particular card, I've been continuously hit by the "azx_get_response timeout, switching to single_cmd mode" problem, described here: http://www.kernel.org/pub/linux/kernel/people/tiwai/docs/HD-Audio.html#_cod… However, in my case setting probe_mask=1 (experimentally determined) didn't make the problem go away, although it seemed to reduce its frequency (might be just a coincidence). Whenever the dreaded "azx_get_response timeout, switching to single_cmd mode" message appeared in the kernel log, recording stopped working. The card got into the bad state where it would not record sound, and arecord would be giving a stream of "overrun" error messages: arecord -f cd output.wav Recording WAVE 'a.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo overrun!!! (at least 27.876 ms long) overrun!!! (at least 26.965 ms long) overrun!!! (at least 16.169 ms long) overrun!!! (at least 11.749 ms long) overrun!!! (at least 11.298 ms long) overrun!!! (at least 11.814 ms long) overrun!!! (at least 11.190 ms long) overrun!!! (at least 11.190 ms long) overrun!!! (at least 11.747 ms long) overrun!!! (at least 11.819 ms long) overrun!!! (at least 11.149 ms long) overrun!!! (at least 11.257 ms long) overrun!!! (at least 11.315 ms long) overrun!!! (at least 11.651 ms long) overrun!!! (at least 11.745 ms long) overrun!!! (at least 11.235 ms long) overrun!!! (at least 11.169 ms long) overrun!!! (at least 11.776 ms long) overrun!!! (at least 11.391 ms long) overrun!!! (at least 11.669 ms long) overrun!!! (at least 11.714 ms long) overrun!!! (at least 11.671 ms long) overrun!!! (at least 11.190 ms long) What's notable, sound playback would continue to work OK. After being fed up with interrupted Skype conversations (where I weren't immediately aware that the other side stopped hearing me, since I was hearing them), I've decided to upgrade do kernel 2.6.29 (citing the http://www.kernel.org/pub/linux/kernel/people/tiwai/docs/HD-Audio.html#_cod… document: "Since 2.6.29 kernel, the driver has a more robust probing method, so this error might happen rarely, though"). After upgrading to 2.6.29 I've removed any extra snd-hda-intel options from modprobe config files. Now the azx_get_response timeout seems to be gone, but I'm experiencing another problem: after some powered up time, recording starts giving empty streams - there's no error, but audio data has zero lengh. e.g. when I arecord, I get a .wav file that is only 44 bytes long (which seems to be the length of the WAV header). When I make a Skype test call to echo123, and it starts playing back my message, it's zero length too - the playback end signal can be heard immediately after the playback start signal. This problem seems to concide with the following error message in the kernel log: hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj. Do you have any idea what could be the cause and how to debug this issue further? -- Best Regards, Aleksander Adamowski http://olo.org.pl

2 10

[alsa-devel] [PATCH] hda-intel: Add position_fix quirk for ASUS M2V-MX SE.
by Paul Menzel 10 Mar '10

10 Mar '10

With PulseAudio and an application accessing an input device like `gnome-volume-manager` both have high CPU load as reported in [1]. Loading `snd-hda-intel` with `position_fix=1` fixes this issue. Therefore add a quirk for ASUS M2V-MX SE. The only downside is, when now exiting for example MPlayer when it is playing an audio file a high pitched sound is outputted by the speaker. $ lspci -vvnn | grep -A10 Audio 20:01.0 Audio device [0403]: VIA Technologies, Inc. VT1708/A [Azalia HDAC] (VIA High Definition Audio Controller) [1106:3288] (rev 10) Subsystem: ASUSTeK Computer Inc. Device [1043:8290] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 17 Region 0: Memory at fbffc000 (64-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: HDA Intel [1] http://sourceforge.net/mailarchive/forum.php?thread_name=1265550675.4642.24… Signed-off-by: Paul Menzel <paulepanter(a)users.sourceforge.net> --- sound/pci/hda/hda_intel.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 051cf51..22dcdc2 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2264,6 +2264,7 @@ static struct snd_pci_quirk position_fix_list[] __devinitdata = { SND_PCI_QUIRK(0x1028, 0x01cc, "Dell D820", POS_FIX_LPIB), SND_PCI_QUIRK(0x1028, 0x01de, "Dell Precision 390", POS_FIX_LPIB), SND_PCI_QUIRK(0x103c, 0x306d, "HP dv3", POS_FIX_LPIB), + SND_PCI_QUIRK(0x1106, 0x3288, "ASUS M2V-MX SE", POS_FIX_LPIB), SND_PCI_QUIRK(0x1043, 0x813d, "ASUS P5AD2", POS_FIX_LPIB), SND_PCI_QUIRK(0x1462, 0x1002, "MSI Wind U115", POS_FIX_LPIB), {} -- 1.6.6.1

2 2

[alsa-devel] [PATCH 3/5] ASoC: DaVinci: CQ93VC Voice Codec
by miguel.aguilar＠ridgerun.com 08 Mar '10

08 Mar '10

From: Miguel Aguilar <miguel.aguilar(a)ridgerun.com> Currently the DM365 is the only SoC that includes this Voice Codec. Signed-off-by: Miguel Aguilar <miguel.aguilar(a)ridgerun.com> --- sound/soc/codecs/Kconfig | 4 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/cq93vc.c | 288 +++++++++++++++++++++++++++++++++++++++++++++ sound/soc/codecs/cq93vc.h | 29 +++++ 4 files changed, 323 insertions(+), 0 deletions(-) create mode 100644 sound/soc/codecs/cq93vc.c create mode 100644 sound/soc/codecs/cq93vc.h diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 52b005f..0daca22 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -21,6 +21,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_AK4535 if I2C select SND_SOC_AK4642 if I2C select SND_SOC_AK4671 if I2C + select SND_SOC_CQ0093VC if MFD_DAVINCI_VOICECODEC select SND_SOC_CS4270 if I2C select SND_SOC_MAX9877 if I2C select SND_SOC_PCM3008 @@ -108,6 +109,9 @@ config SND_SOC_AK4642 config SND_SOC_AK4671 tristate +config SND_SOC_CQ0093VC + tristate + # Cirrus Logic CS4270 Codec config SND_SOC_CS4270 tristate diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile index dbaecb1..dff91fb 100644 --- a/sound/soc/codecs/Makefile +++ b/sound/soc/codecs/Makefile @@ -8,6 +8,7 @@ snd-soc-ak4104-objs := ak4104.o snd-soc-ak4535-objs := ak4535.o snd-soc-ak4642-objs := ak4642.o snd-soc-ak4671-objs := ak4671.o +snd-soc-cq93vc-objs := cq93vc.o snd-soc-cs4270-objs := cs4270.o snd-soc-cx20442-objs := cx20442.o snd-soc-l3-objs := l3.o @@ -64,6 +65,7 @@ obj-$(CONFIG_SND_SOC_AK4104) += snd-soc-ak4104.o obj-$(CONFIG_SND_SOC_AK4535) += snd-soc-ak4535.o obj-$(CONFIG_SND_SOC_AK4642) += snd-soc-ak4642.o obj-$(CONFIG_SND_SOC_AK4671) += snd-soc-ak4671.o +obj-$(CONFIG_SND_SOC_CQ0093VC) += snd-soc-cq93vc.o obj-$(CONFIG_SND_SOC_CS4270) += snd-soc-cs4270.o obj-$(CONFIG_SND_SOC_CX20442) += snd-soc-cx20442.o obj-$(CONFIG_SND_SOC_L3) += snd-soc-l3.o diff --git a/sound/soc/codecs/cq93vc.c b/sound/soc/codecs/cq93vc.c new file mode 100644 index 0000000..37f6ba7 --- /dev/null +++ b/sound/soc/codecs/cq93vc.c @@ -0,0 +1,288 @@ +/* + * ALSA SoC CQ0093 Voice Codec Driver for DaVinci platforms + * + * Copyright (C) 2010 Texas Instruments, Inc + * + * Author: Miguel Aguilar <miguel.aguilar(a)ridgerun.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ +#include <linux/module.h> +#include <linux/moduleparam.h> +#include <linux/init.h> +#include <linux/io.h> +#include <linux/delay.h> +#include <linux/pm.h> +#include <linux/platform_device.h> +#include <linux/device.h> +#include <linux/clk.h> +#include <linux/mfd/davinci_voicecodec.h> + +#include <sound/core.h> +#include <sound/pcm.h> +#include <sound/pcm_params.h> +#include <sound/soc.h> +#include <sound/soc-dai.h> +#include <sound/soc-dapm.h> +#include <sound/initval.h> + +#include <mach/dm365.h> + +#include "cq93vc.h" + +static inline unsigned int cq93vc_read(struct snd_soc_codec *codec, + unsigned int reg) +{ + struct davinci_vc *davinci_vc = codec->control_data; + + return readl(davinci_vc->base + reg); +} + +static inline int cq93vc_write(struct snd_soc_codec *codec, unsigned int reg, + unsigned int value) +{ + struct davinci_vc *davinci_vc = codec->control_data; + + writel(value, davinci_vc->base + reg); + + return 0; +} + +static const struct snd_kcontrol_new cq93vc_snd_controls[] = { + SOC_SINGLE("PGA Capture Volume", DAVINCI_VC_REG05, 0, 0x03, 0), + SOC_SINGLE("Mono DAC Playback Volume", DAVINCI_VC_REG09, 0, 0x3f, 0), +}; + +static int cq93vc_mute(struct snd_soc_dai *dai, int mute) +{ + struct snd_soc_codec *codec = dai->codec; + u8 reg = cq93vc_read(codec, DAVINCI_VC_REG09) & ~DAVINCI_VC_REG09_MUTE; + + if (mute) + cq93vc_write(codec, DAVINCI_VC_REG09, + reg | DAVINCI_VC_REG09_MUTE); + else + cq93vc_write(codec, DAVINCI_VC_REG09, reg); + + return 0; +} + +static int cq93vc_set_dai_sysclk(struct snd_soc_dai *codec_dai, + int clk_id, unsigned int freq, int dir) +{ + struct snd_soc_codec *codec = codec_dai->codec; + struct davinci_vc *davinci_vc = codec->control_data; + + switch (freq) { + case 22579200: + case 27000000: + case 33868800: + davinci_vc->cq93vc.sysclk = freq; + return 0; + } + + return -EINVAL; +} + +static int cq93vc_set_bias_level(struct snd_soc_codec *codec, + enum snd_soc_bias_level level) +{ + switch (level) { + case SND_SOC_BIAS_ON: + cq93vc_write(codec, DAVINCI_VC_REG12, + DAVINCI_VC_REG12_POWER_ALL_ON); + break; + case SND_SOC_BIAS_PREPARE: + break; + case SND_SOC_BIAS_STANDBY: + cq93vc_write(codec, DAVINCI_VC_REG12, + DAVINCI_VC_REG12_POWER_ALL_OFF); + break; + case SND_SOC_BIAS_OFF: + /* force all power off */ + cq93vc_write(codec, DAVINCI_VC_REG12, + DAVINCI_VC_REG12_POWER_ALL_OFF); + break; + } + codec->bias_level = level; + + return 0; +} + +#define CQ93VC_RATES (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_16000) +#define CQ93VC_FORMATS (SNDRV_PCM_FMTBIT_U8 | SNDRV_PCM_FMTBIT_S16_LE) + +static struct snd_soc_dai_ops cq93vc_dai_ops = { + .digital_mute = cq93vc_mute, + .set_sysclk = cq93vc_set_dai_sysclk, +}; + +struct snd_soc_dai cq93vc_dai = { + .name = "CQ93VC", + .playback = { + .stream_name = "Playback", + .channels_min = 1, + .channels_max = 2, + .rates = CQ93VC_RATES, + .formats = CQ93VC_FORMATS,}, + .capture = { + .stream_name = "Capture", + .channels_min = 1, + .channels_max = 2, + .rates = CQ93VC_RATES, + .formats = CQ93VC_FORMATS,}, + .ops = &cq93vc_dai_ops, +}; +EXPORT_SYMBOL_GPL(cq93vc_dai); + +static int cq93vc_resume(struct platform_device *pdev) +{ + struct snd_soc_device *socdev = platform_get_drvdata(pdev); + struct snd_soc_codec *codec = socdev->card->codec; + + cq93vc_set_bias_level(codec, codec->suspend_bias_level); + + return 0; +} + +static struct snd_soc_codec *cq93vc_codec; + +static int cq93vc_probe(struct platform_device *pdev) +{ + struct snd_soc_device *socdev = platform_get_drvdata(pdev); + struct device *dev = &pdev->dev; + struct snd_soc_codec *codec; + int ret; + + socdev->card->codec = cq93vc_codec; + codec = socdev->card->codec; + + /* Register pcms */ + ret = snd_soc_new_pcms(socdev, SNDRV_DEFAULT_IDX1, SNDRV_DEFAULT_STR1); + if (ret < 0) { + dev_err(dev, "%s: failed to create pcms\n", pdev->name); + return ret; + } + + /* Set controls */ + snd_soc_add_controls(codec, cq93vc_snd_controls, + ARRAY_SIZE(cq93vc_snd_controls)); + + /* Off, with power on */ + cq93vc_set_bias_level(codec, SND_SOC_BIAS_STANDBY); + + return 0; +} + +static int cq93vc_remove(struct platform_device *pdev) +{ + struct snd_soc_device *socdev = platform_get_drvdata(pdev); + + snd_soc_free_pcms(socdev); + snd_soc_dapm_free(socdev); + + return 0; +} + +struct snd_soc_codec_device soc_codec_dev_cq93vc = { + .probe = cq93vc_probe, + .remove = cq93vc_remove, + .resume = cq93vc_resume, +}; +EXPORT_SYMBOL_GPL(soc_codec_dev_cq93vc); + +static __init int cq93vc_codec_probe(struct platform_device *pdev) +{ + struct davinci_vc *davinci_vc = platform_get_drvdata(pdev); + struct snd_soc_codec *codec; + int ret; + + codec = kzalloc(sizeof(struct snd_soc_codec), GFP_KERNEL); + if (codec == NULL) { + dev_dbg(davinci_vc->dev, + "could not allocate memory for codec data\n"); + return -ENOMEM; + } + + davinci_vc->cq93vc.codec = codec; + + cq93vc_dai.dev = &pdev->dev; + + mutex_init(&codec->mutex); + INIT_LIST_HEAD(&codec->dapm_widgets); + INIT_LIST_HEAD(&codec->dapm_paths); + codec->dev = &pdev->dev; + codec->name = "CQ93VC"; + codec->owner = THIS_MODULE; + codec->read = cq93vc_read; + codec->write = cq93vc_write; + codec->set_bias_level = cq93vc_set_bias_level; + codec->dai = &cq93vc_dai; + codec->num_dai = 1; + codec->control_data = davinci_vc; + + cq93vc_codec = codec; + + ret = snd_soc_register_dai(&cq93vc_dai); + if (ret != 0) { + dev_err(davinci_vc->dev, "could register dai\n"); + goto fail1; + } + return 0; + +fail1: + kfree(codec); + cq93vc_codec = NULL; + + return ret; +} + +static int __devexit cq93vc_codec_remove(struct platform_device *pdev) +{ + struct snd_soc_device *socdev = platform_get_drvdata(pdev); + struct snd_soc_codec *codec = socdev->card->codec; + + snd_soc_unregister_dai(&cq93vc_dai); + + kfree(codec); + cq93vc_codec = NULL; + + return 0; +} + +static struct platform_driver cq93vc_codec_driver = { + .driver = { + .name = "cq93vc", + .owner = THIS_MODULE, + }, + .probe = cq93vc_codec_probe, + .remove = __devexit_p(cq93vc_codec_remove), +}; + +static __init int cq93vc_init(void) +{ + return platform_driver_probe(&cq93vc_codec_driver, cq93vc_codec_probe); +} +module_init(cq93vc_init); + +static __exit void cq93vc_exit(void) +{ + platform_driver_unregister(&cq93vc_codec_driver); +} +module_exit(cq93vc_exit); + +MODULE_DESCRIPTION("Texas Instruments DaVinci ASoC CQ0093 Voice Codec Driver"); +MODULE_AUTHOR("Miguel Aguilar"); +MODULE_LICENSE("GPL"); diff --git a/sound/soc/codecs/cq93vc.h b/sound/soc/codecs/cq93vc.h new file mode 100644 index 0000000..845b196 --- /dev/null +++ b/sound/soc/codecs/cq93vc.h @@ -0,0 +1,29 @@ +/* + * ALSA SoC CQ0093 Voice Codec Driver for DaVinci platforms + * + * Copyright (C) 2010 Texas Instruments, Inc + * + * Author: Miguel Aguilar <miguel.aguilar(a)ridgerun.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#ifndef _CQ93VC_H +#define _CQ93VC_H + +extern struct snd_soc_dai cq93vc_dai; +extern struct snd_soc_codec_device soc_codec_dev_cq93vc; + +#endif -- 1.6.0.4

3 3

[alsa-devel] 2.6.30-rc8 skipping regression also affects cmipci
by Frédéric Brière 07 Mar '10

07 Mar '10

Hi everybody, I was only recently able to upgrade from 2.6.26 to 2.6.32 (long story). In so doing, I noticed infrequent occurrences of audio skipping, which I managed to bisect down to c87d973. It would appear that this commit also affects cmipci (CMI8738), albeit not as badly as it did for intel8x0. (I guess I'm the only person left on Earth still using a stand-alone PCI sound card, which is why this was never reported. <g>) Here's a sample log output after turning xrun debugging on: [ 171.555860] PCM: hw_ptr skipping! (pos=6341, delta=16383, period=1024, jdelta=0/85) [ 181.114680] PCM: hw_ptr skipping! (pos=12529, delta=16370, period=1024, jdelta=0/85) [ 181.114770] PCM: hw_ptr skipping! (pos=12534, delta=16375, period=1024, jdelta=0/85) [ 1713.774316] PCM: hw_ptr skipping! (pos=9456, delta=16369, period=1024, jdelta=0/85) [ 1713.774346] PCM: hw_ptr skipping! (pos=9458, delta=16371, period=1024, jdelta=0/85) [ 1713.774409] PCM: hw_ptr skipping! (pos=9461, delta=16374, period=1024, jdelta=0/85) [ 1713.774613] PCM: hw_ptr skipping! (pos=9470, delta=16383, period=1024, jdelta=0/85) [ 1831.092000] PCM: hw_ptr skipping! (pos=1712, delta=16373, period=1024, jdelta=0/85) [ 1953.347453] PCM: hw_ptr skipping! (pos=3723, delta=16316, period=1024, jdelta=0/84) [ 1953.347465] PCM: hw_ptr skipping! (pos=3724, delta=16317, period=1024, jdelta=0/84) [ 1953.347485] PCM: hw_ptr skipping! (pos=3725, delta=16318, period=1024, jdelta=0/84) You'll notice that this occurs much less frequently than it did for intel8x0. However, I left MPlayer on pause for the night, and at some point the kernel started spewing several syslog messages every couple of seconds: [25332.211286] PCM: hw_ptr skipping! [Q] (pos=4, delta=-1073740800, period=1024, jdelta=5/44744/0) [25332.232637] PCM: hw_ptr skipping! [Q] (pos=1029, delta=-1073739771, period=1024, jdelta=6/44749/0) [25332.253957] PCM: hw_ptr skipping! [Q] (pos=2053, delta=-1073738747, period=1024, jdelta=5/44755/0) [25332.275292] PCM: hw_ptr skipping! [Q] (pos=3077, delta=-1073737723, period=1024, jdelta=5/44760/0) [25332.296616] PCM: hw_ptr skipping! [Q] (pos=4101, delta=-1073736699, period=1024, jdelta=6/44765/0) [25332.317932] PCM: hw_ptr skipping! [Q] (pos=5125, delta=-1073735675, period=1024, jdelta=5/44771/0) [25332.339269] PCM: hw_ptr skipping! [Q] (pos=6149, delta=-1073734651, period=1024, jdelta=5/44776/0) [25332.360600] PCM: hw_ptr skipping! [Q] (pos=7173, delta=-1073733627, period=1024, jdelta=6/44781/0) [25332.381942] PCM: hw_ptr skipping! [Q] (pos=8197, delta=-1073732603, period=1024, jdelta=5/44787/0) [25332.403261] PCM: hw_ptr skipping! [Q] (pos=9221, delta=-1073731579, period=1024, jdelta=5/44792/0) [25337.244901] PCM: hw_ptr skipping! [Q] (pos=12293, delta=-1073728507, period=1024, jdelta=6/44808/0) [25337.266223] PCM: hw_ptr skipping! [Q] (pos=13317, delta=-1073727483, period=1024, jdelta=5/44813/0) This kept going on until I quit MPlayer (which, as I said, was not actually playing anything all this time). Not that skipped silence is much of an issue, but I thought this might add useful information. Let me know if I can be of any help in resolving this. -- If you want to travel around the world and be invited to speak at a lot of different places, just write a Unix operating system. -- Linus Torvalds

2 3