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

[alsa-devel] ASoC: Configuring codec PCM port question
by Babu, Ramesh 28 Jan '11

28 Jan '11

Hi My codec has 2 ports, PCM1 and PCM2 ports. PCM2 port is used for playback and capture operations and PCM1 is connected to Modem. The ASoC driver has to configure, enable and disable PCM1 port during voice call activity. I am thinking of following two options to configure PCM1 port: 1. AlSA Mixer control: Create mixer control and provide options like VOICE_HS, VOICE_IHF, VOICE_EP and VOICE_DISABLE. Application will use one of the option to Configure the PCM1 port. 2. IOCTL : Application invokes IOCTL in hardware specific driver code and then it enables PCM1 port (cross-path DAPM ?) Which is the best way to implement it? Are there any other existing way to implement it? Thanks Ramesh

2 1

[alsa-devel] ALSA mixer query
by Irfan Shaikh 28 Jan '11

28 Jan '11

Hello all, I am rendering audio to a PCM playback device (hw:0,0). I also need to render the same audio data to second PCM playback device (hw:0,1). 1) Can i use ALSA mixer APIs so that i give PCM audio data to 1 playback device or some common interface, but the PCM audio data is rendered to both devices (hw:0,0 and hw:0,1) Regards Irfan SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited ("Sasken") unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html

2 1

[alsa-devel] [PATCH 0/2] ASoC: Refcount fixes
by Jarkko Nikula 28 Jan '11

28 Jan '11

Hi Nothing new, just yesterday's refcount fix for-2.6.38 and another minor for-2.6.39 rebased on top of for-2.6.39 and sent together. -- Jarkko

3 5

[alsa-devel] Strange control interactions on Tegra Harmony
by Stephen Warren 28 Jan '11

28 Jan '11

Mark, I performed some testing on the patch to enable Harmony's internal speaker that I recently posted, and found a few strange interactions between the mixer controls. The relevant controls that appear are in alsamixer are: Headphone (mute + volume) [default: unmuted, high volume] Speaker (mute + volume) [default: unmuted, high volume] Left/Right Speaker Mixer DACL/DACR/Left Bypass/Right Bypass (switch, default muted/off) Now, if I start playing something, and go enable Right Speaker Mixer DACR, I hear the sound on the speaker. Muting this control turns off the speaker. However, unmuting again doesn't turn the speaker back on. This exact same behavior is seen for Right Speaker Mixer DACL/Left Bypass. For Left Bypass at least, that's odd, since the ADC path shouldn't be active to Capture anything and bypass it back, and there's no mic attached. The Right Speaker Right Bypass control works the first and all subsequent times. Perhaps that's something to do with it being the last entry in wm8903.c's right_speaker_mixer[] array? Finally, the muting either the Headphone and Speaker controls actually affects both the headphone and speaker outputs in all cases, rather than just the output the control is named for. I briefly started to debug this, and notice that the SND_SOC_DAPM_SPK event function isn't being called at all in the cases where muting doesn't toggle as expected. I didn't manage to trace the code through the entire ASoc code-base yet, but initial indications were that some register writes for the speaker mixer routing setup weren't sticking - i.e. I'd toggle a control to unmuted, exit alsamixer, restart alsamixer, and the control wouldn't be in the state I'd placed it. Can you comment on this? I can certainly continue to debug it, but I figured it might be immediately obvious to you what the problem was e.g. if the same thing had happened on other platforms/codecs. Thanks. -- nvpublic

2 4

[alsa-devel] [PATCH] ASoC: Use card as parameter to exported PM functions
by Stephen Warren 28 Jan '11

28 Jan '11

If a machine driver is going to use the exported snd_soc_suspend/resume, at present, the platform device's drvdata must be the snd_soc_card. This prevents the machine driver from placing its own custom drvdata into the platform device. This patch reworks the exported PM functions to take the card instead of the dev, thus allowing machine drivers to use a custom drvdata type. The disadvantage is that every machine driver that does this must then implement something similar to the soc_suspend/resume_dev functions in this patch. An alternative might be to add a drvdata field to struct snd_soc_card, accompanied by snd_soc_set/get_drvdata functions. Another alternative would be to wrap the snd_soc_card stored in the drvdata within another type, and use container_of whenever the machine driver needed the data in the wrapper type. This patch is hence more of a question of "do we want to do it this way", rather than a concrete proposed patch. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- include/sound/soc.h | 6 +++--- sound/soc/soc-core.c | 46 ++++++++++++++++++++++++++++++++-------------- 2 files changed, 35 insertions(+), 17 deletions(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index 7ecdaef..96ae31d 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -260,9 +260,9 @@ enum snd_soc_compress_type { int snd_soc_register_card(struct snd_soc_card *card); int snd_soc_unregister_card(struct snd_soc_card *card); -int snd_soc_suspend(struct device *dev); -int snd_soc_resume(struct device *dev); -int snd_soc_poweroff(struct device *dev); +int snd_soc_suspend(struct snd_soc_card *card); +int snd_soc_resume(struct snd_soc_card *card); +int snd_soc_poweroff(struct snd_soc_card *card); int snd_soc_register_platform(struct device *dev, struct snd_soc_platform_driver *platform_drv); void snd_soc_unregister_platform(struct device *dev); diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index e9f81c5..b72110c 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -972,9 +972,8 @@ static struct snd_pcm_ops soc_pcm_ops = { #ifdef CONFIG_PM_SLEEP /* powers down audio subsystem for suspend */ -int snd_soc_suspend(struct device *dev) +int snd_soc_suspend(struct snd_soc_card *card) { - struct snd_soc_card *card = dev_get_drvdata(dev); struct snd_soc_codec *codec; int i; @@ -1088,6 +1087,13 @@ int snd_soc_suspend(struct device *dev) } EXPORT_SYMBOL_GPL(snd_soc_suspend); +static int soc_suspend_dev(struct device *dev) +{ + struct snd_soc_card *card = dev_get_drvdata(dev); + + return snd_soc_suspend(card); +} + /* deferred resume work, so resume can complete before we finished * setting our codec back up, which can be very slow on I2C */ @@ -1192,9 +1198,8 @@ static void soc_resume_deferred(struct work_struct *work) } /* powers up audio subsystem after a suspend */ -int snd_soc_resume(struct device *dev) +int snd_soc_resume(struct snd_soc_card *card) { - struct snd_soc_card *card = dev_get_drvdata(dev); int i; /* AC97 devices might have other drivers hanging off them so @@ -1205,21 +1210,28 @@ int snd_soc_resume(struct device *dev) for (i = 0; i < card->num_rtd; i++) { struct snd_soc_dai *cpu_dai = card->rtd[i].cpu_dai; if (cpu_dai->driver->ac97_control) { - dev_dbg(dev, "Resuming AC97 immediately\n"); + dev_dbg(card->dev, "Resuming AC97 immediately\n"); soc_resume_deferred(&card->deferred_resume_work); } else { - dev_dbg(dev, "Scheduling resume work\n"); + dev_dbg(card->dev, "Scheduling resume work\n"); if (!schedule_work(&card->deferred_resume_work)) - dev_err(dev, "resume work item may be lost\n"); + dev_err(card->dev, "resume work item may be lost\n"); } } return 0; } EXPORT_SYMBOL_GPL(snd_soc_resume); + +static int soc_resume_dev(struct device *dev) +{ + struct snd_soc_card *card = dev_get_drvdata(dev); + + return snd_soc_resume(card); +} #else -#define snd_soc_suspend NULL -#define snd_soc_resume NULL +#define soc_suspend_dev NULL +#define soc_resume_dev NULL #endif static struct snd_soc_dai_ops null_dai_ops = { @@ -1926,9 +1938,8 @@ static int soc_remove(struct platform_device *pdev) return 0; } -int snd_soc_poweroff(struct device *dev) +int snd_soc_poweroff(struct snd_soc_card *card) { - struct snd_soc_card *card = dev_get_drvdata(dev); int i; if (!card->instantiated) @@ -1947,10 +1958,17 @@ int snd_soc_poweroff(struct device *dev) } EXPORT_SYMBOL_GPL(snd_soc_poweroff); +static int soc_poweroff_dev(struct device *dev) +{ + struct snd_soc_card *card = dev_get_drvdata(dev); + + return snd_soc_poweroff(card); +} + const struct dev_pm_ops snd_soc_pm_ops = { - .suspend = snd_soc_suspend, - .resume = snd_soc_resume, - .poweroff = snd_soc_poweroff, + .suspend = soc_suspend_dev, + .resume = soc_resume_dev, + .poweroff = soc_poweroff_dev, }; /* ASoC platform driver */ -- 1.7.1

2 1

[alsa-devel] [PATCH] ASoC: DaVinci: fix kernel panic due to uninitialized platform_data
by Manjunathappa, Prakash 28 Jan '11

28 Jan '11

This patch fixes the Kernel panic issue on accessing davinci_vc in cq93vc_probe function. struct davinci_vc is part of platform device's private driver data(codec->dev->p->driver_data) and this is populated by DaVinci Voice Codec MFD driver. Signed-off-by: Manjunathappa, Prakash <prakash.pm(a)ti.com> --- This patch applies to Linus's tree at [1]. [1] http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git --- sound/soc/codecs/cq93vc.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/cq93vc.c b/sound/soc/codecs/cq93vc.c index 46dbfd0..347a567 100644 --- a/sound/soc/codecs/cq93vc.c +++ b/sound/soc/codecs/cq93vc.c @@ -153,7 +153,7 @@ static int cq93vc_resume(struct snd_soc_codec *codec) static int cq93vc_probe(struct snd_soc_codec *codec) { - struct davinci_vc *davinci_vc = codec->dev->platform_data; + struct davinci_vc *davinci_vc = snd_soc_codec_get_drvdata(codec); davinci_vc->cq93vc.codec = codec; codec->control_data = davinci_vc; -- 1.7.1

3 2

[alsa-devel] configure sampling rate using alsa-utils
by subashchandra.bose＠wipro.com 28 Jan '11

28 Jan '11

Hi All, we are planning to write a driver for GenADC device in ALSA framework. The hardware device is capable of working in different sampling rate for voice channel, High Speed Channel and low Speed Channel. I went into ALSA home page, using alsa-utils aplay can be used to configure the sampling rate(eg: aplay -r SNDRV_PCM_RATE_8000) Can anybody config if this can be used to configure the GenADC device for voice/HighSpeed/Low Speed channels? Thanks & Regards, -Subash Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

1 0

Re: [alsa-devel] [PATCH - [hdspm] RayDAT/AIO 1/2] ALSA: Add support for RME RayDAT and AIO
by Takashi Iwai 27 Jan '11

27 Jan '11

At Wed, 26 Jan 2011 19:32:14 +0100, Adrian Knoth wrote: > > diff --git a/include/sound/hdspm.h b/include/sound/hdspm.h > index 81990b2..c3f1819 100644 > --- a/include/sound/hdspm.h > +++ b/include/sound/hdspm.h > @@ -131,4 +225,175 @@ typedef struct hdspm_version hdspm_version_t; > typedef struct hdspm_channelfader snd_hdspm_channelfader_t; > typedef struct hdspm_mixer hdspm_mixer_t; > > -#endif /* __SOUND_HDSPM_H */ > +/* These tables map the ALSA channels 1..N to the channels that we > + need to use in order to find the relevant channel buffer. RME > + refers to this kind of mapping as between "the ADAT channel and > + the DMA channel." We index it using the logical audio channel, > + and the value is the DMA channel (i.e. channel buffer number) > + where the data for that channel can be read/written from/to. > +*/ > + > +char channel_map_unity_ss[HDSPM_MAX_CHANNELS] = { Err, no, array definitions should be never in a header file. It doesn't matter whether it's static or not. The definition should be in *.c file where it's used. So, simply move these array definitions to hdspm.c. thanks, Takashi

4 8

[alsa-devel] [PATCH] ASoC: Add subsequence information to seq_notify callbacks
by Mark Brown 27 Jan '11

27 Jan '11

Allows drivers to distinguish which subsequence is being notified when they get called back. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- include/sound/soc-dapm.h | 2 +- include/sound/soc.h | 2 +- sound/soc/soc-dapm.c | 5 +++-- 3 files changed, 5 insertions(+), 4 deletions(-) diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h index 6a25e69..979ed84 100644 --- a/include/sound/soc-dapm.h +++ b/include/sound/soc-dapm.h @@ -501,7 +501,7 @@ struct snd_soc_dapm_context { struct snd_soc_dapm_update *update; void (*seq_notifier)(struct snd_soc_dapm_context *, - enum snd_soc_dapm_type); + enum snd_soc_dapm_type, int); struct device *dev; /* from parent - for debug */ struct snd_soc_codec *codec; /* parent codec */ diff --git a/include/sound/soc.h b/include/sound/soc.h index 49a14da..ab0d5cd 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -554,7 +554,7 @@ struct snd_soc_codec_driver { enum snd_soc_bias_level level); void (*seq_notifier)(struct snd_soc_dapm_context *, - enum snd_soc_dapm_type); + enum snd_soc_dapm_type, int); }; /* SoC platform interface */ diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index 37b376f..0f94fd0 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -899,7 +899,8 @@ static void dapm_seq_run(struct snd_soc_dapm_context *dapm, for (i = 0; i < ARRAY_SIZE(dapm_up_seq); i++) if (sort[i] == cur_sort) cur_dapm->seq_notifier(cur_dapm, - i); + i, + cur_subseq); } INIT_LIST_HEAD(&pending); @@ -968,7 +969,7 @@ static void dapm_seq_run(struct snd_soc_dapm_context *dapm, for (i = 0; i < ARRAY_SIZE(dapm_up_seq); i++) if (sort[i] == cur_sort) cur_dapm->seq_notifier(cur_dapm, - i); + i, cur_subseq); } } -- 1.7.2.3

2 1

[alsa-devel] [PATCH] ASoC: Make cache status available via debugfs
by Mark Brown 27 Jan '11

27 Jan '11

Could just as well live in sysfs but sysfs doesn't have the simple value export helpers debugfs does. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- include/sound/soc.h | 4 ++-- sound/soc/soc-core.c | 5 +++++ 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/include/sound/soc.h b/include/sound/soc.h index 4fd79e0..49a14da 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -494,14 +494,14 @@ struct snd_soc_codec { struct snd_ac97 *ac97; /* for ad-hoc ac97 devices */ unsigned int active; unsigned int cache_bypass:1; /* Suppress access to the cache */ - unsigned int cache_only:1; /* Suppress writes to hardware */ - unsigned int cache_sync:1; /* Cache needs to be synced to hardware */ unsigned int suspended:1; /* Codec is in suspend PM state */ unsigned int probed:1; /* Codec has been probed */ unsigned int ac97_registered:1; /* Codec has been AC97 registered */ unsigned int ac97_created:1; /* Codec has been created by SoC */ unsigned int sysfs_registered:1; /* codec has been sysfs registered */ unsigned int cache_init:1; /* codec cache has been initialized */ + u32 cache_only; /* Suppress writes to hardware */ + u32 cache_sync; /* Cache needs to be synced to hardware */ /* codec IO */ void *control_data; /* codec control (i2c/3wire) data */ diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 5dffc7a4..8af47f7 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -235,6 +235,11 @@ static void soc_init_codec_debugfs(struct snd_soc_codec *codec) return; } + debugfs_create_bool("cache_sync", 0444, codec->debugfs_codec_root, + &codec->cache_sync); + debugfs_create_bool("cache_only", 0444, codec->debugfs_codec_root, + &codec->cache_only); + codec->debugfs_reg = debugfs_create_file("codec_reg", 0644, codec->debugfs_codec_root, codec, &codec_reg_fops); -- 1.7.2.3

2 1