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

[alsa-devel] [PATCH] ASoC: Convert WM8994 MICBIASes to supply widgets
by Mark Brown 02 Dec '11

02 Dec '11

There are some in tree systems using the driver but none use the MICBIAS widgets. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm_hubs.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/wm_hubs.c b/sound/soc/codecs/wm_hubs.c index d1debfb..2a61094 100644 --- a/sound/soc/codecs/wm_hubs.c +++ b/sound/soc/codecs/wm_hubs.c @@ -610,8 +610,8 @@ SND_SOC_DAPM_INPUT("IN1RP"), SND_SOC_DAPM_INPUT("IN2RN"), SND_SOC_DAPM_INPUT("IN2RP:VXRP"), -SND_SOC_DAPM_MICBIAS("MICBIAS2", WM8993_POWER_MANAGEMENT_1, 5, 0), -SND_SOC_DAPM_MICBIAS("MICBIAS1", WM8993_POWER_MANAGEMENT_1, 4, 0), +SND_SOC_DAPM_SUPPLY("MICBIAS2", WM8993_POWER_MANAGEMENT_1, 5, 0, NULL, 0), +SND_SOC_DAPM_SUPPLY("MICBIAS1", WM8993_POWER_MANAGEMENT_1, 4, 0, NULL, 0), SND_SOC_DAPM_MIXER("IN1L PGA", WM8993_POWER_MANAGEMENT_2, 6, 0, in1l_pga, ARRAY_SIZE(in1l_pga)), -- 1.7.7.3

1 0

[alsa-devel] [PATCH] ASoC: Add WM8958 based headset detection on Littlemill
by Mark Brown 02 Dec '11

02 Dec '11

The board supports CODECs that won't work with this but the CODEC driver will check to see if it's running on the right chip for us. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/samsung/littlemill.c | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/sound/soc/samsung/littlemill.c b/sound/soc/samsung/littlemill.c index d2a44ab..5d7680f 100644 --- a/sound/soc/samsung/littlemill.c +++ b/sound/soc/samsung/littlemill.c @@ -154,8 +154,11 @@ static struct snd_soc_dapm_route audio_paths[] = { { "Headphone", NULL, "HPOUT1R" }, }; +static struct snd_soc_jack littlemill_headset; + static int littlemill_late_probe(struct snd_soc_card *card) { + struct snd_soc_codec *codec = card->rtd[0].codec; struct snd_soc_dai *codec_dai = card->rtd[0].codec_dai; int ret; @@ -164,6 +167,18 @@ static int littlemill_late_probe(struct snd_soc_card *card) if (ret < 0) return ret; + ret = snd_soc_jack_new(codec, "Headset", + SND_JACK_HEADSET | SND_JACK_MECHANICAL | + SND_JACK_BTN_0 | SND_JACK_BTN_1 | + SND_JACK_BTN_2 | SND_JACK_BTN_3 | + SND_JACK_BTN_4 | SND_JACK_BTN_5, + &littlemill_headset); + if (ret) + return ret; + + /* This will check device compatibility itself */ + wm8958_mic_detect(codec, &littlemill_headset, NULL, NULL); + return 0; } -- 1.7.7.3

1 0

Re: [alsa-devel] [PATCH 1/5] ASoC: omap-dmic: Add device tree bindings
by Mark Brown 02 Dec '11

02 Dec '11

On Fri, Dec 02, 2011 at 03:59:01PM +0100, Cousson, Benoit wrote: > On 12/2/2011 3:00 PM, Mark Brown wrote: > >At least the DMA bindings seem fairly well sorted - we just merged the > >Tegra audio bindings which define a Tegra property for the DMA request > >signal. There's a reasonable amount of variation in how these things > >get plumbed together. > Mmm, I missed that series, but I'm not sure it is doing the right thing. > - First the name is missing :-( > - Secondly a dma-channel is not a dma-request... So I'm not sure > what that series is supposed to add... The idea is that the thing going into the block is the request line, this is sufficient to identify to the DMA controller code which hardware is being talked about. > >This is also OK for clocks since they'll go through the clock API so > >nothing needs doing there either. > Yep, my point was about the DT churn that this will generate. Adding new things isn't churn in quite the same way - extending bindings is a more natural process than dropping old bits of binding. > At the end, the effort should be only at OMAP core level, so the > driver should not be affected if we decide to move hwmod stuff into > DT or not. Well, the binding will at least need to be updated. Though of course if we manage to ship the DTS for the OMAP with the kernel then it won't really matter if we churn the binding and we may as well not document it at all, treating it as an internal part of the kernel that happens to go through device tree.

1 0

Re: [alsa-devel] [PATCH 1/5] ASoC: omap-dmic: Add device tree bindings
by Mark Brown 02 Dec '11

02 Dec '11

On Fri, Dec 02, 2011 at 02:31:13PM +0100, Cousson, Benoit wrote: > Even if the reg-names and interrupts-names are accepted, which is > still not obvious due to a little bit of resistance, we still do not Yeah, it seems like there's very little traction on any of the problems with legacy bindings that device tree has. > have dma request bindings, nor clock bindings, nor pin mux. > All these information are provided today by hwmod, so it will still > be there for a couple of more merge windows. At least the DMA bindings seem fairly well sorted - we just merged the Tegra audio bindings which define a Tegra property for the DMA request signal. There's a reasonable amount of variation in how these things get plumbed together. > The important point for me, it to avoid having to change the driver > whenever these bindings will be there. This will be OK today for reg > and interrupts since they both go through Linux resources. This is also OK for clocks since they'll go through the clock API so nothing needs doing there either. > >Could we define and implement the "real" version now (it should be reasonable to > >code blind except possibly for the DMA channel as it's such a direct > >mapping) with hwmod left in there as something that's legacy for old > >kernels? > I think DT churn is unavoidable due to the ongoing effort to add > clock, regulator, dma, pin mux into DT core. > I don't think we should wait to have all that ready to start > migrating to DT. Well, it does make the whole process a bit silly. If we're planning to discard hwmod it seems like we shouldn't be transitioning it into device tree in the first place and instead just add the new properties to the bindings as we go. If hwmod must go into the device tree somehow is it not possible to keep the hwmod data in its own binding (referencing the nodes it affects rather than being in their bindings).

1 0

[alsa-devel] hda-jack-retask - a GUI for easy retasking of your HDA Intel codecs!
by David Henningsson 02 Dec '11

02 Dec '11

Something fun for friday afternoon? :-) Over the past few weeks I’ve been working (from time to time) with HDA-Jack-Retask, a small application that makes the kernel interface for jack retasking really easy to use. Although primarily meant for power users, it focuses on simplicity: Just select your codec, then select which pins you want to override and what you want them to override to: Headphones, Line Out, Mic, Line In, and so on. There are buttons for trying it out right away, and for making your override the boot-time default. And of course, a button for removing all overrides in case things did not go as planned. Consider it beta quality for now, and it’s one of those "won’t work for everyone" programs, but that’s mostly due to hardware and driver limitations. If you're running Ubuntu 11.10: You can install it by adding ppa:diwic/hda [1] and then installing the hda-jack-retask package. Start it by running “hda-jack-retask” in a terminal. Or from the command line: sudo add-ppa-repository ppa:diwic/hda sudo apt-get update sudo apt-get install hda-jack-retask hda-jack-retask & If you're running something else: 1) download the source tarball [2] 2) Ensure you have a build environment (gcc, make, sed, etc), gtk3 (and glib) development headers, and the "gksu" application all are installed. On debian platforms, these packages are known as "build-essential", "libgtk-3-dev" and "gksu". 3) make 4) ./hda-jack-retask & Enjoy! End user blog post is here [3]. -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic [1] https://launchpad.net/~diwic/+archive/hda [2] https://launchpad.net/~diwic/+archive/hda/+files/hda-jack-retask_0.20111129… [3] http://voices.canonical.com/david.henningsson/2011/11/29/turn-your-mic-jack…

1 0

Re: [alsa-devel] [PATCH 2/3] sound/soc/lapis: add machine driver
by Mark Brown 02 Dec '11

02 Dec '11

On Fri, Dec 02, 2011 at 09:09:34PM +0900, Tomoya MORINAGA wrote: > 2011/12/2 Mark Brown <broonie(a)opensource.wolfsonmicro.com>: > > The CPU side audio drivers are not there - there seemed to be some quite > > serious review issues with those. > Let me clarify your saying. > Does the above "audio drivers" mean i2s (of south bridge) driver or HD > audio (of north bridge) or another? I2S and audio DMA.

2 2

[alsa-devel] [PATCH 1/2] ASoC: p1022ds: add support for fsl, P1022 and fsl, P1022DS model names
by Timur Tabi 02 Dec '11

02 Dec '11

Commit ab827d97 ("powerpc/85xx: Rework P1022DS device tree") renamed the the /model property of the P1022DS device tree from "fsl,P1022" to "fsl,P1022DS". To support both old and new device trees, the ASoC machine driver for the P1022DS needs to query the /model property and update the platform driver object dynamically. Signed-off-by: Timur Tabi <timur(a)freescale.com> --- sound/soc/fsl/p1022_ds.c | 36 ++++++++++++++++++++++++++++-------- 1 files changed, 28 insertions(+), 8 deletions(-) diff --git a/sound/soc/fsl/p1022_ds.c b/sound/soc/fsl/p1022_ds.c index 2c064a9..3091626 100644 --- a/sound/soc/fsl/p1022_ds.c +++ b/sound/soc/fsl/p1022_ds.c @@ -540,12 +540,6 @@ static struct platform_driver p1022_ds_driver = { .probe = p1022_ds_probe, .remove = __devexit_p(p1022_ds_remove), .driver = { - /* The name must match the 'model' property in the device tree, - * in lowercase letters, but only the part after that last - * comma. This is because some model properties have a "fsl," - * prefix. - */ - .name = "snd-soc-p1022", .owner = THIS_MODULE, }, }; @@ -559,13 +553,39 @@ static int __init p1022_ds_init(void) { struct device_node *guts_np; struct resource res; + const char *sprop; + + /* + * Check if we're actually running on a P1022DS. Older device trees + * have a model of "fsl,P1022" and newer ones use "fsl,P1022DS", so we + * need to support both. The SSI driver uses that property to link to + * the machine driver, so have to match it. + */ + sprop = of_get_property(of_find_node_by_path("/"), "model", NULL); + if (!sprop) { + pr_err("snd-soc-p1022ds: missing /model node"); + return -ENODEV; + } + + pr_debug("snd-soc-p1022ds: board model name is %s\n", sprop); - pr_info("Freescale P1022 DS ALSA SoC machine driver\n"); + /* + * The name of this board, taken from the device tree. Normally, this is a* + * fixed string, but some P1022DS device trees have a /model property of + * "fsl,P1022", and others have "fsl,P1022DS". + */ + if (strcasecmp(sprop, "fsl,p1022ds") == 0) + p1022_ds_driver.driver.name = "snd-soc-p1022ds"; + else if (strcasecmp(sprop, "fsl,p1022") == 0) + p1022_ds_driver.driver.name = "snd-soc-p1022"; + else + return -ENODEV; /* Get the physical address of the global utilities registers */ guts_np = of_find_compatible_node(NULL, NULL, "fsl,p1022-guts"); if (of_address_to_resource(guts_np, 0, &res)) { - pr_err("p1022-ds: missing/invalid global utilities node\n"); + pr_err("snd-soc-p1022ds: missing/invalid global utils node\n"); + of_node_put(guts_np); return -EINVAL; } guts_phys = res.start; -- 1.7.4.4

3 4

Re: [alsa-devel] [PATCH 5/6] compress: add the core file
by Nallasellan, Singaravelan 02 Dec '11

02 Dec '11

> > > A general note: it's not necessarily to split playback and capture > > devices. For example, rawmidi has a single device for full-duplex. > > In the case of PCM, we had to split them because of mmap. The mmap > > for the capture was supposed not to be read-only, some apps may want > > to add mark on the buffer. > > Beats me why an app would want to write anything into the capture ring buffer. > Do you have an example of this use case? Maybe there's a similar need for > compressed data. Thanks! > -Pierre > There was a requirement to add the timestamp at the beginning of each block or frame if the encoded data is in RAW format. If the encoder does add the timestamp or marker, then we don't need the write option.

2 3

[alsa-devel] data write in alsa
by Vinod Koul 02 Dec '11

02 Dec '11

Hi Takashi, For alsa pcm we have two ways to write data, either we use write() system call or use ioctl SNDRV_PCM_IOCTL_WRITEI_FRAMES. Is there any specific reason why we have two methods and which one is preferred and why? This question is basically for compress API, should we add similar write method thru ioctls, if so why? -- ~Vinod

3 3

Re: [alsa-devel] [PATCH 2/3] sound/soc/lapis: add machine driver
by Mark Brown 02 Dec '11

02 Dec '11

On Mon, Nov 21, 2011 at 01:08:51PM +0900, Tomoya MORINAGA wrote: > Add machine driver for LAPIS Semiconductor ML7213 IOH. This needs to come after you add the base platform support in the series - clearly this won't work without the CPU side drivers it depends on. As with the CODEC driver you really should be looking at the standards for modern drivers and following them. > @@ -60,6 +60,7 @@ source "sound/soc/s6000/Kconfig" > source "sound/soc/sh/Kconfig" > source "sound/soc/tegra/Kconfig" > source "sound/soc/txx9/Kconfig" > +source "sound/soc/lapis/Kconfig" Keep the Makefile and Kconfig entries sorted. > +static struct snd_soc_dai_link ioh_i2s_dai = { > + .name = "I2S", > + .stream_name = "I2S HiFi", > + .cpu_dai_name = "ml7213ioh-i2s", > + .codec_dai_name = "ml7213ioh-hifi", I'm very surprised this works... If nothing else I'd expec the CODEC DAI to have a different name to the CPU. > +static int __init ioh_i2s_probe(struct platform_device *pdev) > +{ > + int ret; > + > + soc_pdev = platform_device_alloc("soc-audio", -1); > + if (!soc_pdev) > + return -ENOMEM; You should register the card as a standard platform device for new drivers and use snd_soc_register_card(). > +static struct platform_driver ioh_i2s_driver = { > + .remove = ioh_i2s_remove, > + .driver = { > + .name = "ml7213ioh-machine", > + .owner = THIS_MODULE, > + }, > +}; You're already doing the platform device bit so it should be be a case of changing the body of probe() and remove(). > +static int __init ioh_i2s_init(void) > +{ > + return platform_driver_probe(&ioh_i2s_driver, > + ioh_i2s_probe); > +} Just make this a standard platform_driver_register().

3 5