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

[alsa-devel] ucm: hardware resource arbitration
by Patrick Lai 16 Sep '12

16 Sep '12

Hi, I have two use cases which can acquire same CODEC path but they cannot run concurrently through mixing. When such scenario does arise, arbitration is required based on priority of use cases. On the other hand, same use cases on different platform may use different CODEC paths so arbitration is not required. In order to decide whether arbitration is required, I think the best place to do so is in UCM. I looked at existing UCM APIs but I do not believe existing APIs have concept of arbitration built in. If I am wrong, how can I handle arbitration with existing UCM APIs. If I am correct, is there anyone looking to expand UCM APIs for similar scenario? Thanks Patrick -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

2 3

[alsa-devel] ASoC updates for 3.6
by Mark Brown 15 Sep '12

15 Sep '12

The following changes since commit d9875690d9b89a866022ff49e3fcea892345ad92: Linux 3.6-rc2 (2012-08-16 14:51:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-3.6 for you to fetch changes up to 985b11fa8064d55d0d5a84e68667434598911bb2: ASoC: wm8904: correct the index (2012-09-14 18:02:38 +0100) ---------------------------------------------------------------- ASoC: Updates for 3.6 A bigger set of updates than I'm entirely comfortable with - things backed up a bit due to travel. As ever the majority of these are small, focused updates for specific drivers though there are a couple of core changes. There's been good exposure in -next. The AT91 patch fixes a build break. ---------------------------------------------------------------- Bo Shen (1): ASoC: wm8904: correct the index Dylan Reid (1): ASoC: samsung dma - Don't indicate support for pause/resume. Fabio Estevam (1): ASoC: mc13783: Remove mono support Heather Lomond (1): ASoC: arizona: Fix typo in 44.1kHz rates Joachim Eastwood (1): ASoC: atmel-ssc: include linux/io.h for raw io Julia Lawall (3): ASoC: imx-sgtl5000: fix error return code ASoC: ux500_msp_i2s: better use devm functions and fix error return code ASoC: am3517evm: fix error return code Mark Brown (2): ASoC: dapm: Make sure we update the bias level for CODECs with no op ASoC: dapm: Don't force card bias level to be updated Prasad Joshi (1): ASoC: spear: correct the check for NULL dma_buffer pointer Stephen Warren (2): sound: tegra_alc5632: remove HP detect GPIO inversion ASoC: tegra: fix maxburst settings in dmaengine code include/linux/atmel-ssc.h | 1 + sound/soc/codecs/arizona.c | 2 +- sound/soc/codecs/mc13783.c | 8 ++++---- sound/soc/codecs/wm8904.c | 2 +- sound/soc/fsl/imx-sgtl5000.c | 2 +- sound/soc/omap/am3517evm.c | 2 +- sound/soc/samsung/dma.c | 8 +------- sound/soc/soc-dapm.c | 5 ++++- sound/soc/spear/spear_pcm.c | 2 +- sound/soc/tegra/tegra_alc5632.c | 1 - sound/soc/tegra/tegra_pcm.c | 4 ++-- sound/soc/ux500/ux500_msp_i2s.c | 25 +++++-------------------- 12 files changed, 22 insertions(+), 40 deletions(-)

2 1

[alsa-devel] [PATCH] ASoC: wm8904: correct the index
by Bo Shen 14 Sep '12

14 Sep '12

Signed-off-by: Bo Shen <voice.shen(a)atmel.com> --- sound/soc/codecs/wm8904.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/wm8904.c b/sound/soc/codecs/wm8904.c index 65d525d..13e8222 100644 --- a/sound/soc/codecs/wm8904.c +++ b/sound/soc/codecs/wm8904.c @@ -100,7 +100,7 @@ static const struct reg_default wm8904_reg_defaults[] = { { 14, 0x0000 }, /* R14 - Power Management 2 */ { 15, 0x0000 }, /* R15 - Power Management 3 */ { 18, 0x0000 }, /* R18 - Power Management 6 */ - { 19, 0x945E }, /* R20 - Clock Rates 0 */ + { 20, 0x945E }, /* R20 - Clock Rates 0 */ { 21, 0x0C05 }, /* R21 - Clock Rates 1 */ { 22, 0x0006 }, /* R22 - Clock Rates 2 */ { 24, 0x0050 }, /* R24 - Audio Interface 0 */ -- 1.7.9.5

2 1

Re: [alsa-devel] [PATCH 5/5] ASoC: tegra: remove support of legacy DMA driver based access
by Stephen Warren 14 Sep '12

14 Sep '12

On 08/16/2012 08:13 AM, Laxman Dewangan wrote: > Remove the support code which uses the legacy APB DMA driver > for accessing the I2S FIFO. > The driver will use the dmaengine based APB DMA driver for > accessing reqding/writing to I2S FIFO. > > Signed-off-by: Laxman Dewangan <ldewangan(a)nvidia.com> Please note that I've applied this to Tegra's for-3.7/dmaengine branch, even though it hasn't been ack'd by an ASoC maintainer.

2 3

Re: [alsa-devel] [PATCH 5/5] ASoC: tegra: remove support of legacy DMA driver based access
by Stephen Warren 14 Sep '12

14 Sep '12

On 08/16/2012 08:13 AM, Laxman Dewangan wrote: > Remove the support code which uses the legacy APB DMA driver > for accessing the I2S FIFO. > The driver will use the dmaengine based APB DMA driver for > accessing reqding/writing to I2S FIFO. > > Signed-off-by: Laxman Dewangan <ldewangan(a)nvidia.com> Mark, Liam, I'd like to take this patch through the Tegra tree, since it relies on the previous Tegra patches to convert to dmaengine. Could I please get an ack if that's OK? Thanks.

2 2

Re: [alsa-devel] [PATCH 4/7] mfd: ab8500-core: Apply the AB8500 CODEC's compatible string to its MFD cell
by Mark Brown 14 Sep '12

14 Sep '12

On Fri, Jul 27, 2012 at 03:36:33PM +0200, Samuel Ortiz wrote: > On Fri, Jul 27, 2012 at 01:38:51PM +0100, Lee Jones wrote: > > Provide a compatible string for the AB8500 CODEC to aid in > > configuration property look-up from its associated Device Tree > > node. > Applied as well. I remain *deeply* unconvinced that this is tasteful design for the device tree bindings, and it's certainly not needed urgently for v3.6 as there's no DT bindings on the CODEC side.

3 2

Re: [alsa-devel] [PATCH 4/5] spi: tegra: remove support of legacy DMA driver based access
by Stephen Warren 14 Sep '12

14 Sep '12

On 08/16/2012 08:13 AM, Laxman Dewangan wrote: > Remove the support code which uses the legacy APB DMA driver > for accessing the SPI FIFO. > The driver will use the dmaengine based APB DMA driver for > accessing reqding/writing to SPI FIFO. > > Signed-off-by: Laxman Dewangan <ldewangan(a)nvidia.com> Grant, Mark, I'd like to take this patch through the Tegra tree, since it relies on the previous Tegra patches to convert to dmaengine. Could I please get an ack if that's OK? Thanks.

2 3

[alsa-devel] [PATCH] ASoC: wm8960: Support shared LRCLK
by Mark Brown 14 Sep '12

14 Sep '12

If the LRCLK is shared and the WM8960 is clock master then we should enable the LRCM bit to tell the device that it should drive LRCLK when either ADC or DAC is enabled rather than separately driving the two LRCLKs. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- include/sound/wm8960.h | 2 ++ sound/soc/codecs/wm8960.c | 11 +++++++++++ 2 files changed, 13 insertions(+) diff --git a/include/sound/wm8960.h b/include/sound/wm8960.h index 74e9a95..b5a1ab9e 100644 --- a/include/sound/wm8960.h +++ b/include/sound/wm8960.h @@ -19,6 +19,8 @@ struct wm8960_data { bool capless; /* Headphone outputs configured in capless mode */ int dres; /* Discharge resistance for headphone outputs */ + + bool shared_lrclk; /* DAC and ADC LRCLKs are wired together */ }; #endif diff --git a/sound/soc/codecs/wm8960.c b/sound/soc/codecs/wm8960.c index 7cb0d07c..8740423 100644 --- a/sound/soc/codecs/wm8960.c +++ b/sound/soc/codecs/wm8960.c @@ -1029,6 +1029,7 @@ static const struct regmap_config wm8960_regmap = { static __devinit int wm8960_i2c_probe(struct i2c_client *i2c, const struct i2c_device_id *id) { + struct wm8960_data *pdata = dev_get_platdata(&i2c->dev); struct wm8960_priv *wm8960; int ret; @@ -1041,6 +1042,16 @@ static __devinit int wm8960_i2c_probe(struct i2c_client *i2c, if (IS_ERR(wm8960->regmap)) return PTR_ERR(wm8960->regmap); + if (pdata && pdata->shared_lrclk) { + ret = regmap_update_bits(wm8960->regmap, WM8960_ADDCTL2, + 0x4, 0x4); + if (ret != 0) { + dev_err(&i2c->dev, "Failed to enable LRCM: %d\n", + ret); + return ret; + } + } + i2c_set_clientdata(i2c, wm8960); ret = snd_soc_register_codec(&i2c->dev, -- 1.7.10.4

2 3

Re: [alsa-devel] [PATCH 1/7] powerpc/52xx: define FSL_SOC
by Eric Millbrandt 14 Sep '12

14 Sep '12

On 2012-09-14 agust(a)denx.de wrote: > Eric Millbrandt <emillbrandt(a)dekaresearch.com> wrote: > ... > > Better use: > > diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig index > d701330..4563b28 100644 > --- a/sound/soc/fsl/Kconfig > +++ b/sound/soc/fsl/Kconfig > @@ -6,7 +6,7 @@ config SND_SOC_FSL_UTILS > > menuconfig SND_POWERPC_SOC > tristate "SoC Audio for Freescale PowerPC CPUs" > - depends on FSL_SOC > + depends on FSL_SOC || PPC_MPC52xx > help > Say Y or M if you want to add support for codecs attached to > the PowerPC CPUs. > Thanks, > > Anatolij > Looks good to me, I will do this instead. Thanks. Eric -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message. Thank you. Please consider the environment before printing this email.

1 0

Re: [alsa-devel] FW: [PATCH 07/22] ASoC: Ux500: Initialise PCM from MSP probe rather than as a device
by Ola Lilja 14 Sep '12

14 Sep '12

On 08/23/2012 09:29 PM, Ola Lilja wrote: > > >> -----Original Message----- >> From: Lee Jones [mailto:lee.jones@linaro.org] >> Sent: den 23 augusti 2012 16:59 >> To: Mark Brown >> Cc: Ola Lilja; 'Linus Walleij'; roger.xr.nilsson(a)stericsson.com; linux- >> arm-kernel(a)lists.infradead.org; alsa-devel(a)alsa-project.org >> Subject: Re: [PATCH 07/22] ASoC: Ux500: Initialise PCM from MSP probe >> rather than as a device >> >> On Thu, Aug 23, 2012 at 03:37:57PM +0100, Mark Brown wrote: >> > On Thu, Aug 23, 2012 at 02:26:19PM +0100, Lee Jones wrote: >> > >> > > > I think Ola is suggesting probing the DMA driver from the machine >> > > > which will also work though I'm not 100% sure if I'm parsing the >> > > > above correctly. The issue in DT terms is that if the DMA >> > > > controller is shared with a bunch of other IPs then it should >> have >> > > > one node shared between them all and not a bunch of shim nodes >> > > > inserted in the middle which only exists due to the way Linux >> instantiates stuff. I haven't followed everything in this discussion, but what I meant in an earlier mail was that using the device for platform-DAI (MSP_I2S) also as platform int the DAI-link struct is not anything I can see fit (as in the patch Lee first submitted). I can see a few acceptable solutions: 1) Use it as it is! (A virtual device for PCM is created in arch/arm and the probe is invoked from the machine-driver). 2) Since the actual platform is the DMA-block, maybe there is some way of making the device "non-virtual" by having some sub-device in the DMA-driver that is instead triggered in the same way as in 1). 3) Move it to DT, but it seems that it is not possible when it is now a virtual device. Any of these three would be fine with me. >> > >> > > When you say 'machine', do you mean from arch/<arch>/mach-*? If so, >> > > I'm keen for that not to happen. >> > >> > No, sound/soc/ux500/snowball.c or whatever. At least that's my >> guess. >> >> Ah, I see. Maybe the mop500.c file then. >> >> > > > They instantiate the PCM driver dynamically from the DAI when >> it's >> > > > probed which is pretty much what you're patch is doing. >> > >> > > So they do it in the same why I have with this patch? Do you know >> > > why Ola might think this is a bad idea? >> > >> > I'm not 100% sure, I'm guessing it might be down to the fact that you >> > end up with multiple PCM drivers. We could avoid that with >> > refcounting but nobody's really worried about it. >> >> I think I'll wait for Ola to get back, as he's the expert on this >> stuff. >> >> I'll attempt to re-jig the patch-set, as this is a blocker atm. >> >> -- >> Lee Jones >> Linaro ST-Ericsson Landing Team Lead >> Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook >> | Twitter | Blog >

3 2