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

Re: [alsa-devel] [Resend PATCH v3 2/4] ARM: at91: atmel-ssc: add device tree support
by Mark Brown 07 Nov '12

07 Nov '12

On Wed, Nov 07, 2012 at 03:30:46PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: > the one via ASoC for the driver with the pinctrl for now but MUST add it later > the arch/arm related via AT91 tree where the pinctrl is mandatory in the dtsi > I'm no going to spend hours to do the pinctrl to test Bo patch that he is > supposed to have deon to test this code > As basically today on DT none of the board will work if BO does no provide the > pinctrl so for me he MUST put in the dtsi > is it ok with you? Or add the pinmux bindings for other IPs over in the pinmux branch and the pinmux binding for SSC here (which will help with bisection as the DT bindings for the audio will then always exist in conjunction with the .dtsi changes for them). Either way is fine with me; I'll leave things as they are until I see some new patches. Though I have to say now that I look in -next it's a bit surprising that there are so many IPs in the file that have no pinmix configuration, based on what you're saying it seems like the entire board will be falling over with the pinmux code anyway - in the case of the sam9g20ek we'd at least need I2C pinmux settings. I may be misunderstanding.

1 0

Re: [alsa-devel] [PATCH] ASoC: wm0010: Split out the firmware file parsing from the boot.
by Mark Brown 07 Nov '12

07 Nov '12

On Wed, Nov 07, 2012 at 12:44:29PM +0000, Scott Ling wrote: > Move the firmware load and record parsing functionality out into > a separate function from the boot function. This still doesn't apply. What are you generating these against? Code for upstream should be generated against the current upstream...

1 0

[alsa-devel] commit: dpcm: Allow FE to be opened without valid BE routes
by anish kumar 07 Nov '12

07 Nov '12

Commit 3ac3f5ca91afc03587b1d2d642f126efc5be37ca ASoC: dpcm: Allow FE to be opened without valid BE routes. if (dpcm_path_get(fe, stream, &list) <= 0) { - dev_warn(fe->dev, "asoc: %s no valid %s route\n", + dev_dbg(fe->dev, "asoc: %s no valid %s route\n", fe->dai_link->name, stream ? "capture" : "playback"); - mutex_unlock(&fe->card->mutex); - return -EINVAL; } As I can see this commit has changed the log level from dev_warn to dev_dbg but this has caused a subtle problem.Right now we rely on this warning to find out issues related to "application not sending UCM commands causing mute issues".Sometimes we have seen that the device becomes mute due to application not sending UCM command properly and these issues are hard to reproduce(all we get is dump).So all we have is this log to find out if the FE(front-end) and BE(back-end) has at-lease matched or not and most of the time it doesn't and we find out that using this very log. With this gone it would be difficult to find out the problem.I don't see any harm in reverting it back to dev_warn as it will warn us that "still we have not received UCM command for turning on Back-end" and in case we receive it then this log hardly matters and just gives us information that "at that time it was not a valid route". If everyone agrees then I would be more than happy to send a patch.

3 4

Re: [alsa-devel] [Resend PATCH v3 2/4] ARM: at91: atmel-ssc: add device tree support
by Mark Brown 07 Nov '12

07 Nov '12

On Wed, Nov 07, 2012 at 11:41:21AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 10:21 Wed 07 Nov , Mark Brown wrote: > > Like I say it's not an issue right now and it seems like it should be > > trivial to fix. Is anything needed here other than adding the > > pinctrl_get_set_default() call, in which case would it not be less > > effort all round to just send the patch? If there is more involved then > > what is needed? > for the driver point of view I agreee with you for the dtsi I disagree I miss > 100 lignes of pinctrl description > so today if no pinctrl the pin are input gpio and the drivers will not work > if this code was tested this work MUST have been done otherwise we will apply > non tested work > so dor the dtsi part I do NACK it and the pinctrl code is arropund for 2 or 3 > months so no excuse even Joachim who add the rm9200 support to DT handled the > pinctrl so no exeption on at91 when switching to DT the pinctrl is mandatory > If you want to apply the part of the patch that touch only the drivers I'm > fine but for the dtsi no So what the above is saying is that we should have a followup patch to add the pinctrl setup to the DT (probably one that goes along with the pinctrl changes and adds complete pinctrl setup for the affected boards rather than just doing the audio piecemeal) and do the mindless call in the driver. That doesn't seem impossible. So long as we get those things in place prior to the merge window we should be fine. Even if we don't manage that it still seems like having the patch is better than not having it, from the sounds of it the boards are going to be totally broken if they boot with DT but without the pinctrl setup and the ASoC bindings are pretty much an orthogonal issue to that. Having the bindings for the SSC (which depend on this AFAICT) will allow other machines which are doing a better job with pinctrl to work. Does that seem reasonable?

1 0

[alsa-devel] [PATCH 0/3] ASUS G75 fixes
by tiwai＠suse.de 07 Nov '12

07 Nov '12

Hi Massimo, this is a patch series for fixing ASUS G75. Could you check whether these work for you? Once when confirmed, I'll queue these to the upstream. thanks, Takashi

2 4

[alsa-devel] Out of tree driver for hiface
by Grant Diffey 07 Nov '12

07 Nov '12

3 2

Re: [alsa-devel] [Resend PATCH v3 2/4] ARM: at91: atmel-ssc: add device tree support
by Mark Brown 07 Nov '12

07 Nov '12

On Wed, Nov 07, 2012 at 09:49:32AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: > yes the pinctrl is mainline in -next via pinctrl tree > s code does not work on the DT kernel untill it's done > NACK stand I refuse this touch the at91 dtsi untiol it's done correctly ...and here's another mail (plus a further private mail on the same subject) by the time I managed to reply to the first one, the timestamps say in about ten minutes :/ What I'm seeing here is two of the Atmel maintainers disagreeing about a patch so I've got to pick one view and right now applying the patch looks like it moves us further forwards. Like I say it's not an issue right now and it seems like it should be trivial to fix. Is anything needed here other than adding the pinctrl_get_set_default() call, in which case would it not be less effort all round to just send the patch? If there is more involved then what is needed? Thinking about it a little more I'm actually wondering why whatever pinctrl change made this mandatory didn't go through and update all the drivers.

1 0

Re: [alsa-devel] [Resend PATCH v3 2/4] ARM: at91: atmel-ssc: add device tree support
by Mark Brown 07 Nov '12

07 Nov '12

On Wed, Nov 07, 2012 at 09:47:33AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: > Mark I nack the patch series this patch series does not run on any DT kernel > as no picntrl is done > do not apply until this patfh handle the pinctrl Nicholas seemed to be disagreeing you on that one and his observation that it won't be an issue until v3.8 anyway seemed totally reasonable. In any case it doesn't seems like it'll be an issue to get it resolved before it actually gets merged down to become an issue. Of course there's also some ongoing discussion on the question of having to add mindless pinctrl_get_set_default() to all the drivers at all, the fact that we're having to do that at all seems like a failure to me at least.

1 0

Re: [alsa-devel] [Alsa-user] Ticks when playing to USB DAC at high sample rates
by Daniel Mack 07 Nov '12

07 Nov '12

On 07.11.2012 00:54, Jeffrey Barish wrote: > I guess that snd_usb_pcm_prepare is called by the core usb system to prepare > the snd driver. Anyway, snd_usb_pcm_prepare calls configure_endpoint with a > substream. Then configure_endpoint calls snd_usb_endpoint_set_params with the > data endpoint that corresponds to the substream. snd_usb_endpoint_set_params > calls data_ep_set_params with the data ep and data_ep_set_params sets nurbs to > 2 for the data endpoint. > > snd_usb_endpoint_set_params has code to call sync_ep_set_params when the > endpoint is type sync. sync_ep_set_params sets nurbs to 4 (why?). However, > snd_usb_endpoint_set_params never invokes the call to sync_ep_set_params > because ep->type is always data. Back up: snd_usb_endpoint_set_params is > called from configure_endpoint. It is called from an if block contingent on > the substream's having a sync endpoint. It does. However, the call to > snd_usb_endpoint_set_params passes subs->data_endpoint as the first argument, > so snd_usb_endpoint_set_params simply repeats the operations it performed as a > result of the previous invocation. I presume that the first argument to the > second call to snd_usb_endpoint_set_params should be subs->sync_endpoint. Eh. You clearly spotted a bug here. The rally interesting thing is that that it didn't bite us earlier, as it's in since 3.6. > I > made that change. Now freqm does change. However, I am getting tons of > ticks. Now it sounds as if the payload size is always wrong. > > Oh, 44.1 kHz works. 48 kHz works. 88.2 and 96 don't work. That's a different issue. Would you like to prepare a patch for the issue above please? Thanks, Daniel

1 1

[alsa-devel] [Resend PATCH v3 2/4] ARM: at91: atmel-ssc: add device tree support
by Bo Shen 07 Nov '12

07 Nov '12

Add atmel-ssc for device tree support Match "atmel,at91rm9200-ssc" for using pdc for data transfer Match "atmel,at91sam9g45-ssc" for using dma for data transfer Signed-off-by: Bo Shen <voice.shen(a)atmel.com> Acked-by: Nicolas Ferre <nicolas.ferre(a)atmel.com> --- Resend Fix a error find by Fengguang Yu Although there is a NACK from Jean-Christophe PLAGNIOL-VILLARD, however the pinctrl for at91 is not in mainline. So, plan to add pinctrl support after the pinctrl driver for at91 is merged. Change since v2 No change Change since v1 change the underscore to dash in atmel-ssc binding document --- .../devicetree/bindings/misc/atmel-ssc.txt | 15 ++++++ arch/arm/boot/dts/at91sam9260.dtsi | 8 ++++ arch/arm/boot/dts/at91sam9263.dtsi | 16 +++++++ arch/arm/boot/dts/at91sam9g45.dtsi | 16 +++++++ arch/arm/boot/dts/at91sam9x5.dtsi | 8 ++++ arch/arm/mach-at91/at91rm9200.c | 3 ++ arch/arm/mach-at91/at91sam9260.c | 1 + arch/arm/mach-at91/at91sam9261.c | 3 ++ arch/arm/mach-at91/at91sam9263.c | 2 + arch/arm/mach-at91/at91sam9g45.c | 2 + arch/arm/mach-at91/at91sam9rl.c | 2 + arch/arm/mach-at91/at91sam9x5.c | 1 + drivers/misc/atmel-ssc.c | 49 ++++++++++++++++++-- 13 files changed, 123 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/misc/atmel-ssc.txt diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt new file mode 100644 index 0000000..38e51ad --- /dev/null +++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt @@ -0,0 +1,15 @@ +* Atmel SSC driver. + +Required properties: +- compatible: "atmel,at91rm9200-ssc" or "atmel,at91sam9g45-ssc" + - atmel,at91rm9200-ssc: support pdc transfer + - atmel,at91sam9g45-ssc: support dma transfer +- reg: Should contain SSC registers location and length +- interrupts: Should contain SSC interrupt + +Example: +ssc0: ssc@fffbc000 { + compatible = "atmel,at91rm9200-ssc"; + reg = <0xfffbc000 0x4000>; + interrupts = <14 4 5>; +}; diff --git a/arch/arm/boot/dts/at91sam9260.dtsi b/arch/arm/boot/dts/at91sam9260.dtsi index d410581..aaa42d8 100644 --- a/arch/arm/boot/dts/at91sam9260.dtsi +++ b/arch/arm/boot/dts/at91sam9260.dtsi @@ -29,6 +29,7 @@ tcb0 = &tcb0; tcb1 = &tcb1; i2c0 = &i2c0; + ssc0 = &ssc0; }; cpus { cpu@0 { @@ -212,6 +213,13 @@ status = "disabled"; }; + ssc0: ssc@fffbc000 { + compatible = "atmel,at91rm9200-ssc"; + reg = <0xfffbc000 0x4000>; + interrupts = <14 4 5>; + status = "disable"; + }; + adc0: adc@fffe0000 { compatible = "atmel,at91sam9260-adc"; reg = <0xfffe0000 0x100>; diff --git a/arch/arm/boot/dts/at91sam9263.dtsi b/arch/arm/boot/dts/at91sam9263.dtsi index 3e6e5c1..3b721ee 100644 --- a/arch/arm/boot/dts/at91sam9263.dtsi +++ b/arch/arm/boot/dts/at91sam9263.dtsi @@ -25,6 +25,8 @@ gpio4 = &pioE; tcb0 = &tcb0; i2c0 = &i2c0; + ssc0 = &ssc0; + ssc1 = &ssc1; }; cpus { cpu@0 { @@ -173,6 +175,20 @@ status = "disabled"; }; + ssc0: ssc@fff98000 { + compatible = "atmel,at91rm9200-ssc"; + reg = <0xfff98000 0x4000>; + interrupts = <16 4 5>; + status = "disable"; + }; + + ssc1: ssc@fff9c000 { + compatible = "atmel,at91rm9200-ssc"; + reg = <0xfff9c000 0x4000>; + interrupts = <17 4 5>; + status = "disable"; + }; + macb0: ethernet@fffbc000 { compatible = "cdns,at32ap7000-macb", "cdns,macb"; reg = <0xfffbc000 0x100>; diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi b/arch/arm/boot/dts/at91sam9g45.dtsi index 3add030..acfa207 100644 --- a/arch/arm/boot/dts/at91sam9g45.dtsi +++ b/arch/arm/boot/dts/at91sam9g45.dtsi @@ -31,6 +31,8 @@ tcb1 = &tcb1; i2c0 = &i2c0; i2c1 = &i2c1; + ssc0 = &ssc0; + ssc1 = &ssc1; }; cpus { cpu@0 { @@ -226,6 +228,20 @@ status = "disabled"; }; + ssc0: ssc@fff9c000 { + compatible = "atmel,at91sam9g45-ssc"; + reg = <0xfff9c000 0x4000>; + interrupts = <16 4 5>; + status = "disable"; + }; + + ssc1: ssc@fffa0000 { + compatible = "atmel,at91sam9g45-ssc"; + reg = <0xfffa0000 0x4000>; + interrupts = <17 4 5>; + status = "disable"; + }; + adc0: adc@fffb0000 { compatible = "atmel,at91sam9260-adc"; reg = <0xfffb0000 0x100>; diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi index 03fc136..69667d0 100644 --- a/arch/arm/boot/dts/at91sam9x5.dtsi +++ b/arch/arm/boot/dts/at91sam9x5.dtsi @@ -30,6 +30,7 @@ i2c0 = &i2c0; i2c1 = &i2c1; i2c2 = &i2c2; + ssc0 = &ssc0; }; cpus { cpu@0 { @@ -87,6 +88,13 @@ interrupts = <1 4 7>; }; + ssc0: ssc@f0010000 { + compatible = "atmel,at91sam9g45-ssc"; + reg = <0xf0010000 0x4000>; + interrupts = <28 4 5>; + status = "disable"; + }; + tcb0: timer@f8008000 { compatible = "atmel,at91sam9x5-tcb"; reg = <0xf8008000 0x100>; diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c index 400d1a3..af47c75 100644 --- a/arch/arm/mach-at91/at91rm9200.c +++ b/arch/arm/mach-at91/at91rm9200.c @@ -187,6 +187,9 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.2", &ssc2_clk), + CLKDEV_CON_DEV_ID("pclk", "fffd0000.ssc", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "fffd4000.ssc", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "fffd8000.ssc", &ssc2_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91rm9200.0", &twi_clk), /* fake hclk clock */ CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &ohci_clk), diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c index d14ab6a..a41eb3d 100644 --- a/arch/arm/mach-at91/at91sam9260.c +++ b/arch/arm/mach-at91/at91sam9260.c @@ -211,6 +211,7 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.1", &tc4_clk), CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.1", &tc5_clk), CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc_clk), + CLKDEV_CON_DEV_ID("pclk", "fffbc000.ssc", &ssc_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9260.0", &twi_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20.0", &twi_clk), /* more usart lookup table for DT entries */ diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c index c7b6057..7fcbe05 100644 --- a/arch/arm/mach-at91/at91sam9261.c +++ b/arch/arm/mach-at91/at91sam9261.c @@ -177,6 +177,9 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.2", &ssc2_clk), + CLKDEV_CON_DEV_ID("pclk", "fffbc000.ssc", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "fffc0000.ssc", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "fffc4000.ssc", &ssc2_clk), CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &hck0), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9261.0", &twi_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10.0", &twi_clk), diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c index b87be18..c0f4c8c 100644 --- a/arch/arm/mach-at91/at91sam9263.c +++ b/arch/arm/mach-at91/at91sam9263.c @@ -188,6 +188,8 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_ID("hclk", &macb_clk), CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "fff98000.ssc", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "fff9c000.ssc", &ssc1_clk), CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.0", &mmc0_clk), CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.1", &mmc1_clk), CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.0", &spi0_clk), diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c index f4f96a6..a4282d3 100644 --- a/arch/arm/mach-at91/at91sam9g45.c +++ b/arch/arm/mach-at91/at91sam9g45.c @@ -241,6 +241,8 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10.1", &twi1_clk), CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.0", &ssc0_clk), CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "fff9c000.ssc", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "fffa0000.ssc", &ssc1_clk), CLKDEV_CON_DEV_ID(NULL, "atmel-trng", &trng_clk), CLKDEV_CON_DEV_ID(NULL, "atmel_sha", &aestdessha_clk), CLKDEV_CON_DEV_ID(NULL, "atmel_tdes", &aestdessha_clk), diff --git a/arch/arm/mach-at91/at91sam9rl.c b/arch/arm/mach-at91/at91sam9rl.c index 4110b54..b683fdc 100644 --- a/arch/arm/mach-at91/at91sam9rl.c +++ b/arch/arm/mach-at91/at91sam9rl.c @@ -186,6 +186,8 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.0", &tc2_clk), CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "fffc0000.ssc", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "fffc4000.ssc", &ssc1_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20.0", &twi0_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20.1", &twi1_clk), CLKDEV_CON_ID("pioA", &pioA_clk), diff --git a/arch/arm/mach-at91/at91sam9x5.c b/arch/arm/mach-at91/at91sam9x5.c index e503538..18fbbb2 100644 --- a/arch/arm/mach-at91/at91sam9x5.c +++ b/arch/arm/mach-at91/at91sam9x5.c @@ -231,6 +231,7 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t0_clk", "f800c000.timer", &tcb0_clk), CLKDEV_CON_DEV_ID("dma_clk", "ffffec00.dma-controller", &dma0_clk), CLKDEV_CON_DEV_ID("dma_clk", "ffffee00.dma-controller", &dma1_clk), + CLKDEV_CON_DEV_ID("pclk", "f0010000.ssc", &ssc_clk), CLKDEV_CON_DEV_ID(NULL, "f8010000.i2c", &twi0_clk), CLKDEV_CON_DEV_ID(NULL, "f8014000.i2c", &twi1_clk), CLKDEV_CON_DEV_ID(NULL, "f8018000.i2c", &twi2_clk), diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c index f40abd8..a769719 100644 --- a/drivers/misc/atmel-ssc.c +++ b/drivers/misc/atmel-ssc.c @@ -18,6 +18,8 @@ #include <linux/slab.h> #include <linux/module.h> +#include <linux/of.h> + /* Serialize access to ssc_list and user count */ static DEFINE_SPINLOCK(user_lock); static LIST_HEAD(ssc_list); @@ -29,7 +31,13 @@ struct ssc_device *ssc_request(unsigned int ssc_num) spin_lock(&user_lock); list_for_each_entry(ssc, &ssc_list, list) { - if (ssc->pdev->id == ssc_num) { + if (ssc->pdev->dev.of_node) { + if (of_alias_get_id(ssc->pdev->dev.of_node, "ssc") + == ssc_num) { + ssc_valid = 1; + break; + } + } else if (ssc->pdev->id == ssc_num) { ssc_valid = 1; break; } @@ -88,10 +96,41 @@ static const struct platform_device_id atmel_ssc_devtypes[] = { } }; +#ifdef CONFIG_OF +static const struct of_device_id atmel_ssc_dt_ids[] = { + { + .compatible = "atmel,at91rm9200-ssc", + .data = &at91rm9200_config, + }, { + .compatible = "atmel,at91sam9g45-ssc", + .data = &at91sam9g45_config, + }, { + /* sentinel */ + } +}; +MODULE_DEVICE_TABLE(of, atmel_ssc_dt_ids); +#endif + +static inline const struct atmel_ssc_platform_data * __init + atmel_ssc_get_driver_data(struct platform_device *pdev) +{ + if (pdev->dev.of_node) { + const struct of_device_id *match; + match = of_match_node(atmel_ssc_dt_ids, pdev->dev.of_node); + if (match == NULL) + return NULL; + return match->data; + } + + return (struct atmel_ssc_platform_data *) + platform_get_device_id(pdev)->driver_data; +} + static int ssc_probe(struct platform_device *pdev) { struct resource *regs; struct ssc_device *ssc; + const struct atmel_ssc_platform_data *plat_dat; ssc = devm_kzalloc(&pdev->dev, sizeof(struct ssc_device), GFP_KERNEL); if (!ssc) { @@ -100,8 +139,11 @@ static int ssc_probe(struct platform_device *pdev) } ssc->pdev = pdev; - ssc->pdata = (struct atmel_ssc_platform_data *) - platform_get_device_id(pdev)->driver_data; + + plat_dat = atmel_ssc_get_driver_data(pdev); + if (!plat_dat) + return -ENODEV; + ssc->pdata = (struct atmel_ssc_platform_data *)plat_dat; regs = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!regs) { @@ -160,6 +202,7 @@ static struct platform_driver ssc_driver = { .driver = { .name = "ssc", .owner = THIS_MODULE, + .of_match_table = of_match_ptr(atmel_ssc_dt_ids), }, .id_table = atmel_ssc_devtypes, .probe = ssc_probe, -- 1.7.9.5

2 1

[alsa-devel] [RFC patch v3 1/4] ARM: at91: atmel-ssc: add platform device id table
by Bo Shen 07 Nov '12

07 Nov '12

Add platform device id to check whether the SSC controller support pdc or dam for data transfer If match "at91rm9200_ssc", which support pdc for data transfer If match "at91sam9g45_ssc", which support dma for data transfer Signed-off-by: Bo Shen <voice.shen(a)atmel.com> Acked-by: Nicolas Ferre <nicolas.ferre(a)atmel.com> --- Change since v2 No change Change since v1 No change --- arch/arm/mach-at91/at91rm9200.c | 6 +++--- arch/arm/mach-at91/at91rm9200_devices.c | 6 +++--- arch/arm/mach-at91/at91sam9260.c | 2 +- arch/arm/mach-at91/at91sam9260_devices.c | 2 +- arch/arm/mach-at91/at91sam9261.c | 6 +++--- arch/arm/mach-at91/at91sam9261_devices.c | 6 +++--- arch/arm/mach-at91/at91sam9263.c | 4 ++-- arch/arm/mach-at91/at91sam9263_devices.c | 4 ++-- arch/arm/mach-at91/at91sam9g45.c | 4 ++-- arch/arm/mach-at91/at91sam9g45_devices.c | 4 ++-- arch/arm/mach-at91/at91sam9rl.c | 4 ++-- arch/arm/mach-at91/at91sam9rl_devices.c | 4 ++-- drivers/misc/atmel-ssc.c | 23 +++++++++++++++++++++++ include/linux/atmel-ssc.h | 5 +++++ 14 files changed, 54 insertions(+), 26 deletions(-) diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c index b4f0565..85d53c5 100644 --- a/arch/arm/mach-at91/at91rm9200.c +++ b/arch/arm/mach-at91/at91rm9200.c @@ -184,9 +184,9 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.1", &tc3_clk), CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.1", &tc4_clk), CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.1", &tc5_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.2", &ssc2_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.2", &ssc2_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91rm9200", &twi_clk), /* fake hclk clock */ CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &ohci_clk), diff --git a/arch/arm/mach-at91/at91rm9200_devices.c b/arch/arm/mach-at91/at91rm9200_devices.c index a563189..59ceea1 100644 --- a/arch/arm/mach-at91/at91rm9200_devices.c +++ b/arch/arm/mach-at91/at91rm9200_devices.c @@ -752,7 +752,7 @@ static struct resource ssc0_resources[] = { }; static struct platform_device at91rm9200_ssc0_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 0, .dev = { .dma_mask = &ssc0_dmamask, @@ -794,7 +794,7 @@ static struct resource ssc1_resources[] = { }; static struct platform_device at91rm9200_ssc1_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 1, .dev = { .dma_mask = &ssc1_dmamask, @@ -836,7 +836,7 @@ static struct resource ssc2_resources[] = { }; static struct platform_device at91rm9200_ssc2_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 2, .dev = { .dma_mask = &ssc2_dmamask, diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c index ad29f93..2c8aab0 100644 --- a/arch/arm/mach-at91/at91sam9260.c +++ b/arch/arm/mach-at91/at91sam9260.c @@ -210,7 +210,7 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.1", &tc3_clk), CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.1", &tc4_clk), CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.1", &tc5_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9260", &twi_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20", &twi_clk), /* more usart lookup table for DT entries */ diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c index 805ef95..9cfdc3f 100644 --- a/arch/arm/mach-at91/at91sam9260_devices.c +++ b/arch/arm/mach-at91/at91sam9260_devices.c @@ -742,7 +742,7 @@ static struct resource ssc_resources[] = { }; static struct platform_device at91sam9260_ssc_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 0, .dev = { .dma_mask = &ssc_dmamask, diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c index 8d999eb..4e8c56e 100644 --- a/arch/arm/mach-at91/at91sam9261.c +++ b/arch/arm/mach-at91/at91sam9261.c @@ -174,9 +174,9 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tc0_clk), CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.0", &tc1_clk), CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.0", &tc2_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.2", &ssc2_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.2", &ssc2_clk), CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &hck0), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9261", &twi_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10", &twi_clk), diff --git a/arch/arm/mach-at91/at91sam9261_devices.c b/arch/arm/mach-at91/at91sam9261_devices.c index 9752f17..299637f 100644 --- a/arch/arm/mach-at91/at91sam9261_devices.c +++ b/arch/arm/mach-at91/at91sam9261_devices.c @@ -706,7 +706,7 @@ static struct resource ssc0_resources[] = { }; static struct platform_device at91sam9261_ssc0_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 0, .dev = { .dma_mask = &ssc0_dmamask, @@ -748,7 +748,7 @@ static struct resource ssc1_resources[] = { }; static struct platform_device at91sam9261_ssc1_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 1, .dev = { .dma_mask = &ssc1_dmamask, @@ -790,7 +790,7 @@ static struct resource ssc2_resources[] = { }; static struct platform_device at91sam9261_ssc2_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 2, .dev = { .dma_mask = &ssc2_dmamask, diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c index 6a01d03..95a5471 100644 --- a/arch/arm/mach-at91/at91sam9263.c +++ b/arch/arm/mach-at91/at91sam9263.c @@ -186,8 +186,8 @@ static struct clk *periph_clocks[] __initdata = { static struct clk_lookup periph_clocks_lookups[] = { /* One additional fake clock for macb_hclk */ CLKDEV_CON_ID("hclk", &macb_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.0", &mmc0_clk), CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.1", &mmc1_clk), CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.0", &spi0_clk), diff --git a/arch/arm/mach-at91/at91sam9263_devices.c b/arch/arm/mach-at91/at91sam9263_devices.c index 8dde220..df89a00 100644 --- a/arch/arm/mach-at91/at91sam9263_devices.c +++ b/arch/arm/mach-at91/at91sam9263_devices.c @@ -1199,7 +1199,7 @@ static struct resource ssc0_resources[] = { }; static struct platform_device at91sam9263_ssc0_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 0, .dev = { .dma_mask = &ssc0_dmamask, @@ -1241,7 +1241,7 @@ static struct resource ssc1_resources[] = { }; static struct platform_device at91sam9263_ssc1_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 1, .dev = { .dma_mask = &ssc1_dmamask, diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c index 84af1b5..f4f96a6 100644 --- a/arch/arm/mach-at91/at91sam9g45.c +++ b/arch/arm/mach-at91/at91sam9g45.c @@ -239,8 +239,8 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.1", &tcb0_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10.0", &twi0_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10.1", &twi1_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.0", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.1", &ssc1_clk), CLKDEV_CON_DEV_ID(NULL, "atmel-trng", &trng_clk), CLKDEV_CON_DEV_ID(NULL, "atmel_sha", &aestdessha_clk), CLKDEV_CON_DEV_ID(NULL, "atmel_tdes", &aestdessha_clk), diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c index b159607..27e3bf6 100644 --- a/arch/arm/mach-at91/at91sam9g45_devices.c +++ b/arch/arm/mach-at91/at91sam9g45_devices.c @@ -1459,7 +1459,7 @@ static struct resource ssc0_resources[] = { }; static struct platform_device at91sam9g45_ssc0_device = { - .name = "ssc", + .name = "at91sam9g45_ssc", .id = 0, .dev = { .dma_mask = &ssc0_dmamask, @@ -1501,7 +1501,7 @@ static struct resource ssc1_resources[] = { }; static struct platform_device at91sam9g45_ssc1_device = { - .name = "ssc", + .name = "at91sam9g45_ssc", .id = 1, .dev = { .dma_mask = &ssc1_dmamask, diff --git a/arch/arm/mach-at91/at91sam9rl.c b/arch/arm/mach-at91/at91sam9rl.c index 72e9084..4110b54 100644 --- a/arch/arm/mach-at91/at91sam9rl.c +++ b/arch/arm/mach-at91/at91sam9rl.c @@ -184,8 +184,8 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tc0_clk), CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.0", &tc1_clk), CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.0", &tc2_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20.0", &twi0_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20.1", &twi1_clk), CLKDEV_CON_ID("pioA", &pioA_clk), diff --git a/arch/arm/mach-at91/at91sam9rl_devices.c b/arch/arm/mach-at91/at91sam9rl_devices.c index d6ca054..01220c7 100644 --- a/arch/arm/mach-at91/at91sam9rl_devices.c +++ b/arch/arm/mach-at91/at91sam9rl_devices.c @@ -832,7 +832,7 @@ static struct resource ssc0_resources[] = { }; static struct platform_device at91sam9rl_ssc0_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 0, .dev = { .dma_mask = &ssc0_dmamask, @@ -874,7 +874,7 @@ static struct resource ssc1_resources[] = { }; static struct platform_device at91sam9rl_ssc1_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 1, .dev = { .dma_mask = &ssc1_dmamask, diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c index ac00f83..f40abd8 100644 --- a/drivers/misc/atmel-ssc.c +++ b/drivers/misc/atmel-ssc.c @@ -68,6 +68,26 @@ void ssc_free(struct ssc_device *ssc) } EXPORT_SYMBOL(ssc_free); +static struct atmel_ssc_platform_data at91rm9200_config = { + .use_dma = 0, +}; + +static struct atmel_ssc_platform_data at91sam9g45_config = { + .use_dma = 1, +}; + +static const struct platform_device_id atmel_ssc_devtypes[] = { + { + .name = "at91rm9200_ssc", + .driver_data = (unsigned long) &at91rm9200_config, + }, { + .name = "at91sam9g45_ssc", + .driver_data = (unsigned long) &at91sam9g45_config, + }, { + /* sentinel */ + } +}; + static int ssc_probe(struct platform_device *pdev) { struct resource *regs; @@ -80,6 +100,8 @@ static int ssc_probe(struct platform_device *pdev) } ssc->pdev = pdev; + ssc->pdata = (struct atmel_ssc_platform_data *) + platform_get_device_id(pdev)->driver_data; regs = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!regs) { @@ -139,6 +161,7 @@ static struct platform_driver ssc_driver = { .name = "ssc", .owner = THIS_MODULE, }, + .id_table = atmel_ssc_devtypes, .probe = ssc_probe, .remove = __devexit_p(ssc_remove), }; diff --git a/include/linux/atmel-ssc.h b/include/linux/atmel-ssc.h index 4eb3175..1ca0e32 100644 --- a/include/linux/atmel-ssc.h +++ b/include/linux/atmel-ssc.h @@ -5,10 +5,15 @@ #include <linux/list.h> #include <linux/io.h> +struct atmel_ssc_platform_data { + int use_dma; +}; + struct ssc_device { struct list_head list; void __iomem *regs; struct platform_device *pdev; + struct atmel_ssc_platform_data *pdata; struct clk *clk; int user; int irq; -- 1.7.9.5

2 9

[alsa-devel] [asoc:topic/atmel 7/7] ERROR: Input tree has errors, aborting (use -f to force output)
by Fengguang Wu 07 Nov '12

07 Nov '12

Hi Bo, FYI, kernel build failed on tree: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/atmel head: e9898f35f539f3a1aecf054d01cc1631aaa67be4 commit: e9898f35f539f3a1aecf054d01cc1631aaa67be4 [7/7] ARM: at91: atmel-ssc: add device tree support config: make ARCH=arm at91_dt_defconfig All error/warnings: ERROR (duplicate_label): Duplicate label 'ssc0' on /ahb/apb/ssc@fffa0000 and /ahb/apb/ssc@fff9c000 ERROR: Input tree has errors, aborting (use -f to force output) --- 0-DAY kernel build testing backend Open Source Technology Center Fengguang Wu, Yuanhan Liu Intel Corporation

3 3

Re: [alsa-devel] [RFC patch v3 1/4] ARM: at91: atmel-ssc: add platform device id table
by Nicolas Ferre 06 Nov '12

06 Nov '12

On 11/06/2012 03:52 PM, Jean-Christophe PLAGNIOL-VILLARD : > On 13:57 Tue 06 Nov , Bo Shen wrote: >> Add platform device id to check whether the SSC controller support >> pdc or dam for data transfer >> >> If match "at91rm9200_ssc", which support pdc for data transfer >> If match "at91sam9g45_ssc", which support dma for data transfer > > you add the dt but no pinctrl NACK > > pinctrl is mandoatory for any new dt switch Well, that is a bit too demanding: We will move to pinctrl in... 3.8! So, it does not break something I am for merging this patch and then concentrating in adding the pinctrl piece just after. Best regards, >> Signed-off-by: Bo Shen <voice.shen(a)atmel.com> >> Acked-by: Nicolas Ferre <nicolas.ferre(a)atmel.com> >> --- >> Change since v2 >> No change >> Change since v1 >> No change >> --- >> arch/arm/mach-at91/at91rm9200.c | 6 +++--- >> arch/arm/mach-at91/at91rm9200_devices.c | 6 +++--- >> arch/arm/mach-at91/at91sam9260.c | 2 +- >> arch/arm/mach-at91/at91sam9260_devices.c | 2 +- >> arch/arm/mach-at91/at91sam9261.c | 6 +++--- >> arch/arm/mach-at91/at91sam9261_devices.c | 6 +++--- >> arch/arm/mach-at91/at91sam9263.c | 4 ++-- >> arch/arm/mach-at91/at91sam9263_devices.c | 4 ++-- >> arch/arm/mach-at91/at91sam9g45.c | 4 ++-- >> arch/arm/mach-at91/at91sam9g45_devices.c | 4 ++-- >> arch/arm/mach-at91/at91sam9rl.c | 4 ++-- >> arch/arm/mach-at91/at91sam9rl_devices.c | 4 ++-- >> drivers/misc/atmel-ssc.c | 23 +++++++++++++++++++++++ >> include/linux/atmel-ssc.h | 5 +++++ >> 14 files changed, 54 insertions(+), 26 deletions(-) >> >> diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c >> index b4f0565..85d53c5 100644 >> --- a/arch/arm/mach-at91/at91rm9200.c >> +++ b/arch/arm/mach-at91/at91rm9200.c >> @@ -184,9 +184,9 @@ static struct clk_lookup periph_clocks_lookups[] = { >> CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.1", &tc3_clk), >> CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.1", &tc4_clk), >> CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.1", &tc5_clk), >> - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), >> - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), >> - CLKDEV_CON_DEV_ID("pclk", "ssc.2", &ssc2_clk), >> + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), >> + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), >> + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.2", &ssc2_clk), >> CLKDEV_CON_DEV_ID(NULL, "i2c-at91rm9200", &twi_clk), >> /* fake hclk clock */ >> CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &ohci_clk), >> diff --git a/arch/arm/mach-at91/at91rm9200_devices.c b/arch/arm/mach-at91/at91rm9200_devices.c >> index a563189..59ceea1 100644 >> --- a/arch/arm/mach-at91/at91rm9200_devices.c >> +++ b/arch/arm/mach-at91/at91rm9200_devices.c >> @@ -752,7 +752,7 @@ static struct resource ssc0_resources[] = { >> }; >> >> static struct platform_device at91rm9200_ssc0_device = { >> - .name = "ssc", >> + .name = "at91rm9200_ssc", >> .id = 0, >> .dev = { >> .dma_mask = &ssc0_dmamask, >> @@ -794,7 +794,7 @@ static struct resource ssc1_resources[] = { >> }; >> >> static struct platform_device at91rm9200_ssc1_device = { >> - .name = "ssc", >> + .name = "at91rm9200_ssc", >> .id = 1, >> .dev = { >> .dma_mask = &ssc1_dmamask, >> @@ -836,7 +836,7 @@ static struct resource ssc2_resources[] = { >> }; >> >> static struct platform_device at91rm9200_ssc2_device = { >> - .name = "ssc", >> + .name = "at91rm9200_ssc", >> .id = 2, >> .dev = { >> .dma_mask = &ssc2_dmamask, >> diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c >> index ad29f93..2c8aab0 100644 >> --- a/arch/arm/mach-at91/at91sam9260.c >> +++ b/arch/arm/mach-at91/at91sam9260.c >> @@ -210,7 +210,7 @@ static struct clk_lookup periph_clocks_lookups[] = { >> CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.1", &tc3_clk), >> CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.1", &tc4_clk), >> CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.1", &tc5_clk), >> - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc_clk), >> + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc_clk), >> CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9260", &twi_clk), >> CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20", &twi_clk), >> /* more usart lookup table for DT entries */ >> diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c >> index 805ef95..9cfdc3f 100644 >> --- a/arch/arm/mach-at91/at91sam9260_devices.c >> +++ b/arch/arm/mach-at91/at91sam9260_devices.c >> @@ -742,7 +742,7 @@ static struct resource ssc_resources[] = { >> }; >> >> static struct platform_device at91sam9260_ssc_device = { >> - .name = "ssc", >> + .name = "at91rm9200_ssc", >> .id = 0, >> .dev = { >> .dma_mask = &ssc_dmamask, >> diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c >> index 8d999eb..4e8c56e 100644 >> --- a/arch/arm/mach-at91/at91sam9261.c >> +++ b/arch/arm/mach-at91/at91sam9261.c >> @@ -174,9 +174,9 @@ static struct clk_lookup periph_clocks_lookups[] = { >> CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tc0_clk), >> CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.0", &tc1_clk), >> CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.0", &tc2_clk), >> - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), >> - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), >> - CLKDEV_CON_DEV_ID("pclk", "ssc.2", &ssc2_clk), >> + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), >> + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), >> + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.2", &ssc2_clk), >> CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &hck0), >> CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9261", &twi_clk), >> CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10", &twi_clk), >> diff --git a/arch/arm/mach-at91/at91sam9261_devices.c b/arch/arm/mach-at91/at91sam9261_devices.c >> index 9752f17..299637f 100644 >> --- a/arch/arm/mach-at91/at91sam9261_devices.c >> +++ b/arch/arm/mach-at91/at91sam9261_devices.c >> @@ -706,7 +706,7 @@ static struct resource ssc0_resources[] = { >> }; >> >> static struct platform_device at91sam9261_ssc0_device = { >> - .name = "ssc", >> + .name = "at91rm9200_ssc", >> .id = 0, >> .dev = { >> .dma_mask = &ssc0_dmamask, >> @@ -748,7 +748,7 @@ static struct resource ssc1_resources[] = { >> }; >> >> static struct platform_device at91sam9261_ssc1_device = { >> - .name = "ssc", >> + .name = "at91rm9200_ssc", >> .id = 1, >> .dev = { >> .dma_mask = &ssc1_dmamask, >> @@ -790,7 +790,7 @@ static struct resource ssc2_resources[] = { >> }; >> >> static struct platform_device at91sam9261_ssc2_device = { >> - .name = "ssc", >> + .name = "at91rm9200_ssc", >> .id = 2, >> .dev = { >> .dma_mask = &ssc2_dmamask, >> diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c >> index 6a01d03..95a5471 100644 >> --- a/arch/arm/mach-at91/at91sam9263.c >> +++ b/arch/arm/mach-at91/at91sam9263.c >> @@ -186,8 +186,8 @@ static struct clk *periph_clocks[] __initdata = { >> static struct clk_lookup periph_clocks_lookups[] = { >> /* One additional fake clock for macb_hclk */ >> CLKDEV_CON_ID("hclk", &macb_clk), >> - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), >> - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), >> + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), >> + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), >> CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.0", &mmc0_clk), >> CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.1", &mmc1_clk), >> CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.0", &spi0_clk), >> diff --git a/arch/arm/mach-at91/at91sam9263_devices.c b/arch/arm/mach-at91/at91sam9263_devices.c >> index 8dde220..df89a00 100644 >> --- a/arch/arm/mach-at91/at91sam9263_devices.c >> +++ b/arch/arm/mach-at91/at91sam9263_devices.c >> @@ -1199,7 +1199,7 @@ static struct resource ssc0_resources[] = { >> }; >> >> static struct platform_device at91sam9263_ssc0_device = { >> - .name = "ssc", >> + .name = "at91rm9200_ssc", >> .id = 0, >> .dev = { >> .dma_mask = &ssc0_dmamask, >> @@ -1241,7 +1241,7 @@ static struct resource ssc1_resources[] = { >> }; >> >> static struct platform_device at91sam9263_ssc1_device = { >> - .name = "ssc", >> + .name = "at91rm9200_ssc", >> .id = 1, >> .dev = { >> .dma_mask = &ssc1_dmamask, >> diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c >> index 84af1b5..f4f96a6 100644 >> --- a/arch/arm/mach-at91/at91sam9g45.c >> +++ b/arch/arm/mach-at91/at91sam9g45.c >> @@ -239,8 +239,8 @@ static struct clk_lookup periph_clocks_lookups[] = { >> CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.1", &tcb0_clk), >> CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10.0", &twi0_clk), >> CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10.1", &twi1_clk), >> - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), >> - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), >> + CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.0", &ssc0_clk), >> + CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.1", &ssc1_clk), >> CLKDEV_CON_DEV_ID(NULL, "atmel-trng", &trng_clk), >> CLKDEV_CON_DEV_ID(NULL, "atmel_sha", &aestdessha_clk), >> CLKDEV_CON_DEV_ID(NULL, "atmel_tdes", &aestdessha_clk), >> diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c >> index b159607..27e3bf6 100644 >> --- a/arch/arm/mach-at91/at91sam9g45_devices.c >> +++ b/arch/arm/mach-at91/at91sam9g45_devices.c >> @@ -1459,7 +1459,7 @@ static struct resource ssc0_resources[] = { >> }; >> >> static struct platform_device at91sam9g45_ssc0_device = { >> - .name = "ssc", >> + .name = "at91sam9g45_ssc", >> .id = 0, >> .dev = { >> .dma_mask = &ssc0_dmamask, >> @@ -1501,7 +1501,7 @@ static struct resource ssc1_resources[] = { >> }; >> >> static struct platform_device at91sam9g45_ssc1_device = { >> - .name = "ssc", >> + .name = "at91sam9g45_ssc", >> .id = 1, >> .dev = { >> .dma_mask = &ssc1_dmamask, >> diff --git a/arch/arm/mach-at91/at91sam9rl.c b/arch/arm/mach-at91/at91sam9rl.c >> index 72e9084..4110b54 100644 >> --- a/arch/arm/mach-at91/at91sam9rl.c >> +++ b/arch/arm/mach-at91/at91sam9rl.c >> @@ -184,8 +184,8 @@ static struct clk_lookup periph_clocks_lookups[] = { >> CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tc0_clk), >> CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.0", &tc1_clk), >> CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.0", &tc2_clk), >> - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), >> - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), >> + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), >> + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), >> CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20.0", &twi0_clk), >> CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20.1", &twi1_clk), >> CLKDEV_CON_ID("pioA", &pioA_clk), >> diff --git a/arch/arm/mach-at91/at91sam9rl_devices.c b/arch/arm/mach-at91/at91sam9rl_devices.c >> index d6ca054..01220c7 100644 >> --- a/arch/arm/mach-at91/at91sam9rl_devices.c >> +++ b/arch/arm/mach-at91/at91sam9rl_devices.c >> @@ -832,7 +832,7 @@ static struct resource ssc0_resources[] = { >> }; >> >> static struct platform_device at91sam9rl_ssc0_device = { >> - .name = "ssc", >> + .name = "at91rm9200_ssc", >> .id = 0, >> .dev = { >> .dma_mask = &ssc0_dmamask, >> @@ -874,7 +874,7 @@ static struct resource ssc1_resources[] = { >> }; >> >> static struct platform_device at91sam9rl_ssc1_device = { >> - .name = "ssc", >> + .name = "at91rm9200_ssc", >> .id = 1, >> .dev = { >> .dma_mask = &ssc1_dmamask, >> diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c >> index ac00f83..f40abd8 100644 >> --- a/drivers/misc/atmel-ssc.c >> +++ b/drivers/misc/atmel-ssc.c >> @@ -68,6 +68,26 @@ void ssc_free(struct ssc_device *ssc) >> } >> EXPORT_SYMBOL(ssc_free); >> >> +static struct atmel_ssc_platform_data at91rm9200_config = { >> + .use_dma = 0, >> +}; >> + >> +static struct atmel_ssc_platform_data at91sam9g45_config = { >> + .use_dma = 1, >> +}; >> + >> +static const struct platform_device_id atmel_ssc_devtypes[] = { >> + { >> + .name = "at91rm9200_ssc", >> + .driver_data = (unsigned long) &at91rm9200_config, >> + }, { >> + .name = "at91sam9g45_ssc", >> + .driver_data = (unsigned long) &at91sam9g45_config, >> + }, { >> + /* sentinel */ >> + } >> +}; >> + >> static int ssc_probe(struct platform_device *pdev) >> { >> struct resource *regs; >> @@ -80,6 +100,8 @@ static int ssc_probe(struct platform_device *pdev) >> } >> >> ssc->pdev = pdev; >> + ssc->pdata = (struct atmel_ssc_platform_data *) >> + platform_get_device_id(pdev)->driver_data; >> >> regs = platform_get_resource(pdev, IORESOURCE_MEM, 0); >> if (!regs) { >> @@ -139,6 +161,7 @@ static struct platform_driver ssc_driver = { >> .name = "ssc", >> .owner = THIS_MODULE, >> }, >> + .id_table = atmel_ssc_devtypes, >> .probe = ssc_probe, >> .remove = __devexit_p(ssc_remove), >> }; >> diff --git a/include/linux/atmel-ssc.h b/include/linux/atmel-ssc.h >> index 4eb3175..1ca0e32 100644 >> --- a/include/linux/atmel-ssc.h >> +++ b/include/linux/atmel-ssc.h >> @@ -5,10 +5,15 @@ >> #include <linux/list.h> >> #include <linux/io.h> >> >> +struct atmel_ssc_platform_data { >> + int use_dma; >> +}; >> + >> struct ssc_device { >> struct list_head list; >> void __iomem *regs; >> struct platform_device *pdev; >> + struct atmel_ssc_platform_data *pdata; >> struct clk *clk; >> int user; >> int irq; >> -- >> 1.7.9.5 >> > -- Nicolas Ferre

1 0

[alsa-devel] [PATCH v2] ASoC: mxs-pcm: Fix fifo size
by Fabio Estevam 06 Nov '12

06 Nov '12

From: Fabio Estevam <fabio.estevam(a)freescale.com> According to MX28 Reference Manual the SAIF FIFO contains four 32-bit entries. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- Changes since v1: - Fix info about FIFO size sound/soc/mxs/mxs-pcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/mxs/mxs-pcm.c b/sound/soc/mxs/mxs-pcm.c index f82d766..6b360d0 100644 --- a/sound/soc/mxs/mxs-pcm.c +++ b/sound/soc/mxs/mxs-pcm.c @@ -60,7 +60,7 @@ static struct snd_pcm_hardware snd_mxs_hardware = { .periods_min = 1, .periods_max = 52, .buffer_bytes_max = 64 * 1024, - .fifo_size = 32, + .fifo_size = 4, }; -- 1.7.9.5

3 3

[alsa-devel] [PATCH 0/2] ASoC: fsi: add audio clock calculation
by Kuninori Morimoto 06 Nov '12

06 Nov '12

Hi Mark These patches add audio clock calculation method to FSI driver Kuninori Morimoto (2): ASoC: fsi: care fsi_hw_start/stop() return value ASoC: fsi: add master clock control functions include/sound/sh_fsi.h | 6 + sound/soc/sh/fsi.c | 318 ++++++++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 313 insertions(+), 11 deletions(-) Best regards --- Kuninori Morimoto

2 8

[alsa-devel] [Patch v2 1/4] ARM: at91: atmel-ssc: add platform device id table
by Bo Shen 06 Nov '12

06 Nov '12

Add platform device id to check whether the SSC controller support pdc or dam for data transfer If match "at91rm9200_ssc", which support pdc for data transfer If match "at91sam9g45_ssc", which support dma for data transfer Signed-off-by: Bo Shen <voice.shen(a)atmel.com> --- No change between v1 and v2 --- arch/arm/mach-at91/at91rm9200.c | 6 +++--- arch/arm/mach-at91/at91rm9200_devices.c | 6 +++--- arch/arm/mach-at91/at91sam9260.c | 2 +- arch/arm/mach-at91/at91sam9260_devices.c | 2 +- arch/arm/mach-at91/at91sam9261.c | 6 +++--- arch/arm/mach-at91/at91sam9261_devices.c | 6 +++--- arch/arm/mach-at91/at91sam9263.c | 4 ++-- arch/arm/mach-at91/at91sam9263_devices.c | 4 ++-- arch/arm/mach-at91/at91sam9g45.c | 4 ++-- arch/arm/mach-at91/at91sam9g45_devices.c | 4 ++-- arch/arm/mach-at91/at91sam9rl.c | 4 ++-- arch/arm/mach-at91/at91sam9rl_devices.c | 4 ++-- drivers/misc/atmel-ssc.c | 23 +++++++++++++++++++++++ include/linux/atmel-ssc.h | 5 +++++ 14 files changed, 54 insertions(+), 26 deletions(-) diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c index b4f0565..85d53c5 100644 --- a/arch/arm/mach-at91/at91rm9200.c +++ b/arch/arm/mach-at91/at91rm9200.c @@ -184,9 +184,9 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.1", &tc3_clk), CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.1", &tc4_clk), CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.1", &tc5_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.2", &ssc2_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.2", &ssc2_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91rm9200", &twi_clk), /* fake hclk clock */ CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &ohci_clk), diff --git a/arch/arm/mach-at91/at91rm9200_devices.c b/arch/arm/mach-at91/at91rm9200_devices.c index a563189..59ceea1 100644 --- a/arch/arm/mach-at91/at91rm9200_devices.c +++ b/arch/arm/mach-at91/at91rm9200_devices.c @@ -752,7 +752,7 @@ static struct resource ssc0_resources[] = { }; static struct platform_device at91rm9200_ssc0_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 0, .dev = { .dma_mask = &ssc0_dmamask, @@ -794,7 +794,7 @@ static struct resource ssc1_resources[] = { }; static struct platform_device at91rm9200_ssc1_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 1, .dev = { .dma_mask = &ssc1_dmamask, @@ -836,7 +836,7 @@ static struct resource ssc2_resources[] = { }; static struct platform_device at91rm9200_ssc2_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 2, .dev = { .dma_mask = &ssc2_dmamask, diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c index ad29f93..2c8aab0 100644 --- a/arch/arm/mach-at91/at91sam9260.c +++ b/arch/arm/mach-at91/at91sam9260.c @@ -210,7 +210,7 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.1", &tc3_clk), CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.1", &tc4_clk), CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.1", &tc5_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9260", &twi_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20", &twi_clk), /* more usart lookup table for DT entries */ diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c index 805ef95..9cfdc3f 100644 --- a/arch/arm/mach-at91/at91sam9260_devices.c +++ b/arch/arm/mach-at91/at91sam9260_devices.c @@ -742,7 +742,7 @@ static struct resource ssc_resources[] = { }; static struct platform_device at91sam9260_ssc_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 0, .dev = { .dma_mask = &ssc_dmamask, diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c index 8d999eb..4e8c56e 100644 --- a/arch/arm/mach-at91/at91sam9261.c +++ b/arch/arm/mach-at91/at91sam9261.c @@ -174,9 +174,9 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tc0_clk), CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.0", &tc1_clk), CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.0", &tc2_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.2", &ssc2_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.2", &ssc2_clk), CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &hck0), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9261", &twi_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10", &twi_clk), diff --git a/arch/arm/mach-at91/at91sam9261_devices.c b/arch/arm/mach-at91/at91sam9261_devices.c index 9752f17..299637f 100644 --- a/arch/arm/mach-at91/at91sam9261_devices.c +++ b/arch/arm/mach-at91/at91sam9261_devices.c @@ -706,7 +706,7 @@ static struct resource ssc0_resources[] = { }; static struct platform_device at91sam9261_ssc0_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 0, .dev = { .dma_mask = &ssc0_dmamask, @@ -748,7 +748,7 @@ static struct resource ssc1_resources[] = { }; static struct platform_device at91sam9261_ssc1_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 1, .dev = { .dma_mask = &ssc1_dmamask, @@ -790,7 +790,7 @@ static struct resource ssc2_resources[] = { }; static struct platform_device at91sam9261_ssc2_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 2, .dev = { .dma_mask = &ssc2_dmamask, diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c index 6a01d03..95a5471 100644 --- a/arch/arm/mach-at91/at91sam9263.c +++ b/arch/arm/mach-at91/at91sam9263.c @@ -186,8 +186,8 @@ static struct clk *periph_clocks[] __initdata = { static struct clk_lookup periph_clocks_lookups[] = { /* One additional fake clock for macb_hclk */ CLKDEV_CON_ID("hclk", &macb_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.0", &mmc0_clk), CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.1", &mmc1_clk), CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.0", &spi0_clk), diff --git a/arch/arm/mach-at91/at91sam9263_devices.c b/arch/arm/mach-at91/at91sam9263_devices.c index 8dde220..df89a00 100644 --- a/arch/arm/mach-at91/at91sam9263_devices.c +++ b/arch/arm/mach-at91/at91sam9263_devices.c @@ -1199,7 +1199,7 @@ static struct resource ssc0_resources[] = { }; static struct platform_device at91sam9263_ssc0_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 0, .dev = { .dma_mask = &ssc0_dmamask, @@ -1241,7 +1241,7 @@ static struct resource ssc1_resources[] = { }; static struct platform_device at91sam9263_ssc1_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 1, .dev = { .dma_mask = &ssc1_dmamask, diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c index 84af1b5..f4f96a6 100644 --- a/arch/arm/mach-at91/at91sam9g45.c +++ b/arch/arm/mach-at91/at91sam9g45.c @@ -239,8 +239,8 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.1", &tcb0_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10.0", &twi0_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10.1", &twi1_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.0", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.1", &ssc1_clk), CLKDEV_CON_DEV_ID(NULL, "atmel-trng", &trng_clk), CLKDEV_CON_DEV_ID(NULL, "atmel_sha", &aestdessha_clk), CLKDEV_CON_DEV_ID(NULL, "atmel_tdes", &aestdessha_clk), diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c index b159607..27e3bf6 100644 --- a/arch/arm/mach-at91/at91sam9g45_devices.c +++ b/arch/arm/mach-at91/at91sam9g45_devices.c @@ -1459,7 +1459,7 @@ static struct resource ssc0_resources[] = { }; static struct platform_device at91sam9g45_ssc0_device = { - .name = "ssc", + .name = "at91sam9g45_ssc", .id = 0, .dev = { .dma_mask = &ssc0_dmamask, @@ -1501,7 +1501,7 @@ static struct resource ssc1_resources[] = { }; static struct platform_device at91sam9g45_ssc1_device = { - .name = "ssc", + .name = "at91sam9g45_ssc", .id = 1, .dev = { .dma_mask = &ssc1_dmamask, diff --git a/arch/arm/mach-at91/at91sam9rl.c b/arch/arm/mach-at91/at91sam9rl.c index 72e9084..4110b54 100644 --- a/arch/arm/mach-at91/at91sam9rl.c +++ b/arch/arm/mach-at91/at91sam9rl.c @@ -184,8 +184,8 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tc0_clk), CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.0", &tc1_clk), CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.0", &tc2_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20.0", &twi0_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20.1", &twi1_clk), CLKDEV_CON_ID("pioA", &pioA_clk), diff --git a/arch/arm/mach-at91/at91sam9rl_devices.c b/arch/arm/mach-at91/at91sam9rl_devices.c index d6ca054..01220c7 100644 --- a/arch/arm/mach-at91/at91sam9rl_devices.c +++ b/arch/arm/mach-at91/at91sam9rl_devices.c @@ -832,7 +832,7 @@ static struct resource ssc0_resources[] = { }; static struct platform_device at91sam9rl_ssc0_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 0, .dev = { .dma_mask = &ssc0_dmamask, @@ -874,7 +874,7 @@ static struct resource ssc1_resources[] = { }; static struct platform_device at91sam9rl_ssc1_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 1, .dev = { .dma_mask = &ssc1_dmamask, diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c index ac00f83..f40abd8 100644 --- a/drivers/misc/atmel-ssc.c +++ b/drivers/misc/atmel-ssc.c @@ -68,6 +68,26 @@ void ssc_free(struct ssc_device *ssc) } EXPORT_SYMBOL(ssc_free); +static struct atmel_ssc_platform_data at91rm9200_config = { + .use_dma = 0, +}; + +static struct atmel_ssc_platform_data at91sam9g45_config = { + .use_dma = 1, +}; + +static const struct platform_device_id atmel_ssc_devtypes[] = { + { + .name = "at91rm9200_ssc", + .driver_data = (unsigned long) &at91rm9200_config, + }, { + .name = "at91sam9g45_ssc", + .driver_data = (unsigned long) &at91sam9g45_config, + }, { + /* sentinel */ + } +}; + static int ssc_probe(struct platform_device *pdev) { struct resource *regs; @@ -80,6 +100,8 @@ static int ssc_probe(struct platform_device *pdev) } ssc->pdev = pdev; + ssc->pdata = (struct atmel_ssc_platform_data *) + platform_get_device_id(pdev)->driver_data; regs = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!regs) { @@ -139,6 +161,7 @@ static struct platform_driver ssc_driver = { .name = "ssc", .owner = THIS_MODULE, }, + .id_table = atmel_ssc_devtypes, .probe = ssc_probe, .remove = __devexit_p(ssc_remove), }; diff --git a/include/linux/atmel-ssc.h b/include/linux/atmel-ssc.h index 4eb3175..1ca0e32 100644 --- a/include/linux/atmel-ssc.h +++ b/include/linux/atmel-ssc.h @@ -5,10 +5,15 @@ #include <linux/list.h> #include <linux/io.h> +struct atmel_ssc_platform_data { + int use_dma; +}; + struct ssc_device { struct list_head list; void __iomem *regs; struct platform_device *pdev; + struct atmel_ssc_platform_data *pdata; struct clk *clk; int user; int irq; -- 1.7.9.5

3 13

[alsa-devel] [PATCH] ASoC: codecs/wm8978: pll incorrectly configured when codec is master
by Eric Millbrandt 06 Nov '12

06 Nov '12

When MCLK is supplied externally and BCLK and LRC are configured as outputs (codec is master), the PLL values are only calculated correctly on the first transmission. On subsequent transmissions, at differenct sample rates, the wrong PLL values are used. Test for f_opclk instead of f_pllout to determine if the PLL values are needed. Signed-off-by: Eric Millbrandt <emillbrandt(a)dekaresearch.com> --- sound/soc/codecs/wm8978.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/wm8978.c b/sound/soc/codecs/wm8978.c index a706262..e329187 100644 --- a/sound/soc/codecs/wm8978.c +++ b/sound/soc/codecs/wm8978.c @@ -784,7 +784,7 @@ static int wm8978_hw_params(struct snd_pcm_substream *substream, wm8978->mclk_idx = -1; f_sel = wm8978->f_mclk; } else { - if (!wm8978->f_pllout) { + if (!wm8978->f_opclk) { /* We only enter here, if OPCLK is not used */ int ret = wm8978_configure_pll(codec); if (ret < 0) -- 1.7.2.5

2 1

Re: [alsa-devel] [PATCH 1/2] ASoC: Ux500: Fixup use of clocks
by Mark Brown 06 Nov '12

06 Nov '12

On Mon, Nov 05, 2012 at 03:27:08PM +0100, Ulf Hansson wrote: > I can not find this patch on any "next-tree" yet. Same goes for: > "[PATCH 2/2] ASoC: Ux500: Control apb clock". > Maybe I should be more patient, but thought it make sense to send a > ping on this. :-) As I've had to tell you before pings are pointless, don't do this - to repeat, if you think something has been missed resend it.

1 0

Re: [alsa-devel] [PATCH] ASoC: wm0010: Only output debug status message on status change.
by Mark Brown 06 Nov '12

06 Nov '12

On Mon, Nov 05, 2012 at 02:45:12PM +0000, Scott Ling wrote: > Rather than outputting the debug status message for every status > received from the DSP, only output a message when the status > changes. This doesn't apply against -next, please check what's going on there.

1 0

Re: [alsa-devel] [PATCH] ASoC: wm0010: Remove boot_done variable as no longer required.
by Mark Brown 06 Nov '12

06 Nov '12

On Mon, Nov 05, 2012 at 02:44:25PM +0000, Scott Ling wrote: > Remove the boot_done counter variable and check the wm0010 state > variable instead. Applied, thanks.

1 0

[alsa-devel] [FT C400,v2,RFC 0/8] M-Audio Fast Track C400
by Eldad Zack 06 Nov '12

06 Nov '12

Hi, The following patches adds support for the M-Audio Fast Track C400. I recently bought this device and I was able to get this work thanks to the discussion on the alsa-devel list.[1] Thanks everyone! This series applies against the latest mainline tree, 3.7-rc4 (HEAD 3d70f8c617a436c7146ecb81df2265b4626dfe89 ) This is v2 of the series. It adds patches #3 and #8. * First of all, everything works: mixer controls, effects control, playback and capture (with the correct sampling frequency set). Note that the device doesn't really have a master control or left/right pan. It's just "emulated" in the software. * Audio in/out seems to work good in v2, mainly because the playback is an implicit feedback endpoint, and it is now configured with the capture endpoint as its sync-buddy (patch #8). * Also needed to correct the calculation for implicit feedback, because of the different channel numbers between the two endpoints on the C400 (6 playback - implicit feedback, 4 capture) (patch #3). * The clock sources are still named "Unit 129" (0x81, internal) and "Unit 130" (0x82, SPDIF). I'll fix this later. I also plan to fix the channel names (i.e., instead of "AIn3", use "SPDIF In L"). * I've touched one FTU mixer creation function. I'd appreciate if someone can test this with the FTU to make sure I didn't break something. * Patches #6 and #7 are not ready to go in. Patch #6 employs a crude hack and misuses cmask. Patch #7 follows suit. I'd appreciate some hints on how to do this properly. (It's theoretically possible to use cmask properly, but cmasks must be a 64 bits type, because we have 10 input * 6 output = 60 paths). Grant, I mentioned just now that I get distorted playback. This was caused by me using an lower bandwidth altsetting (2), which I tried since it gives only 2 playback channels, figuring it might help latency somehow. I now reverted back to the original alsetting (1) and I seem to get a stable latency and I can't hear anything unusual (yet?). jack_delay seems to be happy as well. Cheers, Eldad Cc: Grant Diffey <gdiffey(a)gmail.com> Cc: Chris Cavey <chris-alsa(a)rauros.net> Signed-off-by: Eldad Zack <eldad(a)fogrefinery.com> Eldad Zack (8): usb-audio: skip UAC2 EFFECT_UNIT usb-audio: parameterize FTU effect unit control usb-audio: use sender stride for implicit feedback usb-audio: M-Audio Fast Track C400 quirks table usb-audio: Fast Track C400 mixer ranges usb-audio: Fast Track C400 mixer quirks usb-audio: add remaining C400 controls usb-audio: FT C400 sync playback EP to capture EP sound/usb/endpoint.c | 9 ++- sound/usb/mixer.c | 55 +++++++++++++- sound/usb/mixer_quirks.c | 196 ++++++++++++++++++++++++++++++++++++++++++++-- sound/usb/pcm.c | 13 +++ sound/usb/quirks-table.h | 71 +++++++++++++++++ 5 files changed, 332 insertions(+), 12 deletions(-) -- 1.7.8.6

1 8

Re: [alsa-devel] [Alsa-user] Ticks when playing to USB DAC at high sample rates
by Daniel Mack 06 Nov '12

06 Nov '12

On 05.11.2012 23:29, Jeffrey Barish wrote: > On Mon 05 November 2012 16:03:00 Daniel Mack wrote: >> Hi Jeff, >> >> On 05.11.2012 02:53, Jeffrey Barish wrote: >>> On Sun 04 November 2012 11:39:48 Daniel Mack wrote: >>>> [cc alsa-devel] >>>> >>>> On 04.11.2012 02:25, Jeffrey Barish wrote: >>>>> On Fri 26 October 2012 15:21:06 Jeffrey Barish wrote: >>>>>> On Fri 26 October 2012 21:47:05 Daniel Mack wrote: >>>>>>> On 26.10.2012 21:43, Jeffrey Barish wrote: >>>>>>>> On Thu 25 October 2012 19:10:45 Daniel Mack wrote: >>>>>>>>> On 25.10.2012 17:18, Jeffrey Barish wrote: >>>>>>>>>> I found something in the snd_usb_audio code (in endpoint.c) that >>>>>>>>>> could >>>>>>>>>> explain one of the problems I have observed (the ticks). I would >>>>>>>>>> normally test my theory by modifying the code. In this case, I >>>>>>>>>> would >>>>>>>>>> like to stick in a print statement to see what values are being >>>>>>>>>> assigned >>>>>>>>>> to certain variables. Unfortunately, I am too ignorant to do >>>>>>>>>> something >>>>>>>>>> even this trivial as I have never worked on kernel code. I think I >>>>>>>>>> am >>>>>>>>>> supposed to use printk, >>>>>>>>> >>>>>>>>> printk is nice for simple debugging, yes. But note that this call is >>>>>>>>> timing critical and should not be used in "fast path" code. >>>>>>>>> Introducing >>>>>>>>> a printk for each received packet for example will almost certainly >>>>>>>>> make >>>>>>>>> the driver behave quite differently. >>>>>>>>> >>>>>>>>>> but beyond that I am lost. Can someone provide >>>>>>>>>> me with some directions? I need to know how to make the driver. To >>>>>>>>>> that >>>>>>>>>> end, I probably will have to install additional packages. After >>>>>>>>>> making >>>>>>>>>> the driver, I need to know how to install it over the existing >>>>>>>>>> driver. >>>>>>>>> >>>>>>>>> Here's one way to do it: >>>>>>>>> >>>>>>>>> 1. git clone >>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git (your >>>>>>>>> patch should apply on top of this tree eventually) >>>>>>>>> 2. cd sound >>>>>>>>> 3. zcat /proc/config.gz >.config >>>>>>>>> 4. build and install the kernel image. How that is done depends on >>>>>>>>> the >>>>>>>>> distribution you're using. For Ubuntu follow the docs at [1] (start >>>>>>>>> at >>>>>>>>> point #5). For Fedora and others, something like "make && make >>>>>>>>> install" >>>>>>>>> should do >>>>>>>>> 5. reboot and check that the new kernel is running >>>>>>>>> 6. hack on sound/usb >>>>>>>>> 7. make M=sound/usb >>>>>>>>> 8. reload the module with "sudo rmmod snd_usb_audio; sudo insmod >>>>>>>>> sound/usb/snd-usb-audio.ko" (better plug out the device before so >>>>>>>>> you >>>>>>>>> always have the same defined point of start) >>>>>>>>> >>>>>>>>> >>>>>>>>> Hope that works for you. >>>>>>>>> >>>>>>>>> >>>>>>>>> Daniel >>>>>>>>> >>>>>>>>> [1] https://wiki.ubuntu.com/KernelTeam/GitKernelBuild >>>>>>>> >>>>>>>> Your directions were almost perfect, so even I was able to build the >>>>>>>> kernel. I made a discovery using the new kernel that might help >>>>>>>> someone >>>>>>>> more familiar with the code than I am to localize the problem. I am >>>>>>>> still hearing the blip when I play audio sampled at 88.2 kHz, but I >>>>>>>> just >>>>>>>> noticed that the blip is perfectly periodic, with a period of about >>>>>>>> 16.4 >>>>>>>> seconds. I am playing a sine wave synthesized using GStreamer using >>>>>>>> the >>>>>>>> following command: >>>>>>>> >>>>>>>> gst-launch audiotestsrc volume=0.01 ! audio/x-raw-float, width=64, >>>>>>>> rate=88200, channels=2, endianness=1234 ! audioconvert ! alsasink >>>>>>>> >>>>>>>> A sine wave makes it easier to hear the blip. Does this clue suggest >>>>>>>> anything? >>>>>>>> >>>>>>>> I also want to mention that when I use the new kernel, I do not get >>>>>>>> the >>>>>>>> ticks at either 88.2 or 96 kHz even when I do not use the external >>>>>>>> USB >>>>>>>> hub. I plan next to back up to the 3.6.2 kernel to see whether I >>>>>>>> still >>>>>>>> get ticks there. >>>>>>> >>>>>>> Which kernel did you use when you heard the 'blibs'? >>>>>> >>>>>> The latest news is bad. I am on 3.2.0 now. The USB DAC is working >>>>>> perfectly at this moment at both 96 kHz and 88.2 kHz without the >>>>>> external >>>>>> USB hub (imagine calling that bad news). If I set the srate to 88.2 >>>>>> kHz >>>>>> and stop and start the sine wave, sometimes I get the blip. Forget >>>>>> about >>>>>> its being periodic. It was definitely periodic before lunch; now I >>>>>> usually >>>>>> get random intervals if I get any blips at all. As I am typing this >>>>>> message, I can't get blips at all. There was some correlation between >>>>>> changing sample rates and blips, but I can't reproduce that behavior >>>>>> now. >>>>>> What is most weird is that I haven't gotten any ticks since lunch with >>>>>> any >>>>>> kernel or with either sample rate, yet they were reliable earlier today >>>>>> unless I used the external USB hub. I obviously need to experiment some >>>>>> more to see whether I can observe a pattern. >>>>> >>>>> To conclude (?) this thread, I am now convinced that the anomalies I >>>>> observed were unrelated to the device driver. I had two theories >>>>> remaining. One was that the problem was somehow related to an >>>>> overheating problem. I used a heat gun to convince myself that the >>>>> theory was wrong. The other was that the problem had something to do >>>>> with services running in the background that interfered with the device >>>>> driver. I removed or disabled all services that I could identify as >>>>> superfluous. Removed services include zeitgeist, apparmor, >>>>> modemmanager, >>>>> mdadm, and bluetooth. Disabled services include atd, dns-clean, and >>>>> pppd-dns. The system has been running perfectly with an 88.2 kHz sample >>>>> rate and no external USB hub for 2 days. However, I tried booting the >>>>> system with a copy of the OS from before I removed superfluous services. >>>>> It still ran perfectly. Thus, I cannot convince myself that removing >>>>> superfluous services actually solved the problem. I suppose it's >>>>> possible that some service was running sporadically, which could explain >>>>> why the problem seemed to come and go and also why the problem did not >>>>> occur when I booted the copy of the OS. As long as the problem remains >>>>> dormant I have no alternative but to move on and see whether the problem >>>>> eventually recurs. Only time will tell. >>>>> >>>>> Thanks for all the help. Hey, I built a kernel and got my own version >>>>> of >>>>> the device driver to run. That was exciting. >>>>> >>>>> ------------------------------------------------------------------------ >>>>> -- >>>>> ---- >>>>> >>>>> I'm back. The USB DAC continued to work for two more days after my last >>>>> message and then the blips resumed. I've been digging into the driver >>>>> code >>>>> for two days. I spent today trying to convince myself that the driver >>>>> is >>>>> actually using an asynchronous protocol. The blips are almost certainly >>>>> buffer underruns, which I could account for if the driver were not >>>>> responding to asynchronous feedback from the DAC. I expected to see a >>>>> deviation from the pattern of one frame with 89 samples followed by 4 >>>>> frames with 88 (which results in 88,200 samples per second). That >>>>> sequence would work perfectly if the clocks in the computer and in the >>>>> USB DAC were exactly the same frequency, but of course they are not. >>>>> Consequently, I would expect to see requests for one sample more or less >>>>> once in a while, depending on whether the clock in the computer is >>>>> slower >>>>> or faster than the one in the DAC. What I see is 89 + 4 * 88 almost all >>>>> the time, as expected . Once in a while there is a request for an >>>>> additional frame of 88 and then the pattern of 89 + 4 * 88 resumes. I >>>>> presume that the break in the usual pattern indicates that the device >>>>> driver is responding to a request from the DAC for fewer samples, which >>>>> confirms that the driver is using the asynchronous protocol. That's >>>>> good, if I am right. However, sticking in an extra packet of only 88 >>>>> would be the expected deviation if the host were getting a little ahead >>>>> of the DAC, yet the blip is almost certainly a buffer underrun, which >>>>> means that the host is actually falling behind. Thus, an extra packet >>>>> of >>>>> 89 would make more sense. I should also mention that there is no >>>>> correlation between the timing of the extra packet of 88 and the audible >>>>> blip. Something seems wrong here, but I'm not sure where to go next. >>>>> >>>>> On a related topic, to confirm that the blip is a buffer underrun, I >>>>> would >>>>> like to synthesize a waveform that is DC. With DC, an overrun would not >>>>> produce any audible anomalies whereas an underrun would be audible. I >>>>> am >>>>> using GStreamer to synthesize the test waveform. Does anyone know of a >>>>> way to synthesize a DC waveform using GStreamer? If not, is there any >>>>> other tool available in Linux? >>>>> >>>>> By the way, I bought another USB DAC from a different manufacturer to be >>>>> sure that the anomalies I am observing were not due to a defect in the >>>>> DAC. They both display the same problem. >>>>> >>>>> ----------------------------------------------------- >>>>> >>>>> I modified the device driver to output a constant instead of the >>>>> incoming >>>>> waveform. I get blips, as I expected, so I am now certain that the >>>>> blips >>>>> are caused by a buffer underrun. The blips occur periodically again -- >>>>> period of about 16.5 seconds. I presume that the period is related to >>>>> the difference in clock rates between the host and DAC. Roughly every >>>>> 3-4 blips, I get an extra packet of 88 samples. To prevent buffer >>>>> underrun, I ought to be getting an extra packet of 89 samples every 16.5 >>>>> seconds, but I never do. >>>> >>>> Thanks for all your investigation on this! Sending computed data instead >>>> of the payload delivered by the ALSA stack is in fact a very good way to >>>> isolate the issue. >>>> >>>> The question is: if the algorithm in the USB driver miscalculates the >>>> number of samples to send over time, what't the reason for that? Does >>>> the device report bogus values or is there this a bug in the driver? >>> >>> Well, I have two DACs, each from a different manufacturer. Both >>> experience >>> underruns (though not at the same rate). It's possible that they are both >>> reporting bogus values, but unlikely, so I'm leaning toward the bug >>> theory. >>> >>>> Did you read chapter 5.4.12.1 of the USB2.0 spec, and can you explain >>>> where you suspect the bug to be? The current implementation in the >>>> driver is quite straight forward, mapping all feedback values to Q16.16 >>>> and keeping the lower 16bits around for phase compensation between the >>>> calculation of the packet sizes. >>> >>> Do you perhaps mean chapter 5.12.4.1 (Synchronization Type)? I'm not >>> finding a 5.4.12.1 in usb_20.pdf from a zip dated 102512. >> >> Yes, sorry. >> >>> Please tell me whether I have this right: >>> >>> You start transferring the sound in snd_usb_endpoint_start using >>> usb_submit_urb to submit 2 urbs to the USB core. The urbs specify that on >>> completion, the USB core should call snd_complete_urb. snd_complete_urb >>> resubmits the urb after calling retire_playback_urb (by way of >>> retire_outbound_urb which calls retire_data_urb which is >>> retire_playback_urb), which updates its estimate of delay (what's that? >>> It seems to be 0 always) >> That's just an information that is passed to userspace for latency >> compensation matters. As you don't stream data that ALSA passes up the >> stack anymore in your tests (but static data), you can ignore this >> detail for now. >> >>> and prepare_playback_urb (by way of prepare_outbound_urb which calls >>> prepare_data_urb which is prepare_playback_urb), which fills the >>> transfer_buffer in the urb with the audio data (from a DMA buffer, I >>> guess). >>> >>> Before filling transfer_buffer, prepare_playback_urb calls >>> snd_usb_endpoint_next_packet_size to compute the number of samples to >>> send. >>> This code appears to be the crux of what I need to understand because the >>> value returned from this function is what is supposed to adjust to prevent >>> buffer underruns. >> >> That's correct. >> >>> It isn't clear to me how this function gets information >>> about the state of the buffer in the device. >> >> Via the callback of the feedback data endpoint - the momentary frequency >> is updated there and referred to again in >> snd_usb_endpoint_next_packet_size(). >> >>> The only argument to >>> snd_usb_endpoint_next_packet_size is ep, which is a pointer to the >>> snd_usb_endpoint structure. >> >> Yes, the endpoint structure hold all runtime streaming details. Once a >> sync urb is given back from the host controller, retire_inbound_urb() is >> called and snd_usb_handle_sync_urb() cares for updating the momentary >> frequency of the slave of the sync endpoint, which is the data endpoint >> that is later on used by next_packet_size(). Makes sense? >> >>> I see that ep->phase is the Q16.16 value you >>> mentioned, so the lower 16 bits are for "phase compensation between the >>> calculation of the packet sizes". I don't completely understand that >>> phrase. freqm is an unchanging value (5780275) >> >> freqm shouldn't be unchanging. Are you sure it really is? If so, is >> snd_usb_handle_sync_urb() ever called in your setup? > > Yes. freqm is always 5780275. snd_usb_handle_sync_urb is never called. Ok, we can probably stop debugging here already, because if that function is never called, something's badly wrong. No question the data endpoint will run out of bounds at some point if it doesn't get any usable feedback data. > snd_usb_handle_sync_urb is called from only one place, retire_inbound_urb, so > the latter is never called. I suppose that an inbound urb would never need to > be retired if one were never submitted. Trace whteher usb_submit_urb() is called on the sync endpoint. There must be a reason why the completion routing is never callsed, and that's most probably also the solution of your problem. [..] > Since puzzling over the apparent absence of feedback about the state of the > device, I had an epiphany this morning that such feedback is not necessary. It's always necessary, as two osciallators will drift from each other, no matter what. Without a feedback, there's no way the host can know how many data to send over the wire. > The pattern of payload sizes should not change if the payloads are sent in > response to a request from the device. The device makes this request by > calling snd_complete_urb when it finishes an urb. As the device defines time, > the host is responsible only for having the next urb ready when the device > requests it. Could it be that the missing feedback provides nonessential > information about the state of the device, such as confirmation that the > previous payload was successfully processed? > > I repeated the test with a different DAC. With that DAC it is still the case > that snd_usb_handle_sync_urb is never called. How exactly did you make sure? There's something really wrong if what you describe happens, and we need to find the cause for it. Unless you're dealing with a device that uses one data endpoint as clock source for another data endpoint (which is called an "implicit feedback" mechanism), you need to have a dedicated sync endpoint. Daniel

1 0

[alsa-devel] [FT C400,RFC 0/6] M-Audio Fast Track C400
by Eldad Zack 05 Nov '12

05 Nov '12

Hi, The following patches adds support for the M-Audio Fast Track C400. I recently bought this device and I was able to get this work thanks to the discussion on the alsa-devel list.[1] Thanks everyone! This series applies against the latest mainline tree, 3.7-rc3 (HEAD 0f89a5733a8d28174c7adeb1fdc20ac11439e766 ) * First of all, everything works: mixer controls, effects control, playback and capture (with the correct sampling frequency set). Note that the device doesn't really have a master control or left/right pan. It's just "emulated" in the software. Audio in/out works good (but not good enough yet, see below). Playback and capture at 48KHz as well as 96KHz works fine (if you don't mind an xrun every 2-5 minutes). I've captured with the C400 and played it back on my on-board device and vice versa to make sure it gets the sample rate correctly. * The clock sources are still named "Unit 129" (0x81, internal) and "Unit 130" (0x82, SPDIF). I'll fix this later. I also plan to fix the channel names (i.e., instead of "AIn3", use "SPDIF In L"). * I've touched one FTU mixer creation function. I'd appreciate if someone can test this with the FTU to make sure I didn't break something. * The last two patches are not ready to go in. Patch #5 employs a crude hack and misuses cmask. Patch #6 follows suit. I'd appreciate some hints on how to do this properly. (It's theoretically possible to use cmask properly, but cmasks must be a 64 bits type, because we have 10 input * 6 output = 60 paths). * Somewhat unrelated: I encounter latency issues. I'm not sure if it's just my particular hardware/drivers. I'm getting jack xruns even with very large buffers and low sampling frequency. Jackd is running alone, with almost no system activity (no X). With the USB 2.0 interface (ehci) I have also experienced hard lock-ups after a while (or almost immediately with 96KHz @ 64 bytes * 2 periods). Luckily I have a USB 3.0 interfaces as well (Intel xhci), which doesn't lock-up, but I still get xruns once every 2-5 minutes. (1000HZ kernel, with PREEMPT). Also, xruns are much less frequent when using only capture or only playback. Chris, do you mind testing this and see if (1) it works for you and (2) you see the same latency issues? Thanks for the USB captures, it really saved a lot of work to get this done! Cheers, Eldad Cc: Chris Cavey <chris-alsa(a)rauros.net> Signed-off-by: Eldad Zack <eldad(a)fogrefinery.com> -- Eldad Zack (6): usb-audio: skip UAC2 EFFECT_UNIT usb-audio: parameterize FTU effect unit control usb-audio: M-Audio Fast Track C400 quirks table usb-audio: Fast Track C400 mixer ranges usb-audio: Fast Track C400 mixer quirks usb-audio: add remaining C400 controls sound/usb/mixer.c | 55 +++++++++++++- sound/usb/mixer_quirks.c | 196 ++++++++++++++++++++++++++++++++++++++++++++-- sound/usb/quirks-table.h | 71 +++++++++++++++++ 3 files changed, 313 insertions(+), 9 deletions(-) -- 1.7.8.6

2 8

Re: [alsa-devel] [Alsa-user] Ticks when playing to USB DAC at high sample rates
by Daniel Mack 05 Nov '12

05 Nov '12

Hi Jeff, On 05.11.2012 02:53, Jeffrey Barish wrote: > On Sun 04 November 2012 11:39:48 Daniel Mack wrote: >> [cc alsa-devel] >> >> On 04.11.2012 02:25, Jeffrey Barish wrote: >>> On Fri 26 October 2012 15:21:06 Jeffrey Barish wrote: >>>> On Fri 26 October 2012 21:47:05 Daniel Mack wrote: >>>>> On 26.10.2012 21:43, Jeffrey Barish wrote: >>>>>> On Thu 25 October 2012 19:10:45 Daniel Mack wrote: >>>>>>> On 25.10.2012 17:18, Jeffrey Barish wrote: >>>>>>>> I found something in the snd_usb_audio code (in endpoint.c) that >>>>>>>> could >>>>>>>> explain one of the problems I have observed (the ticks). I would >>>>>>>> normally test my theory by modifying the code. In this case, I would >>>>>>>> like to stick in a print statement to see what values are being >>>>>>>> assigned >>>>>>>> to certain variables. Unfortunately, I am too ignorant to do >>>>>>>> something >>>>>>>> even this trivial as I have never worked on kernel code. I think I am >>>>>>>> supposed to use printk, >>>>>>> >>>>>>> printk is nice for simple debugging, yes. But note that this call is >>>>>>> timing critical and should not be used in "fast path" code. >>>>>>> Introducing >>>>>>> a printk for each received packet for example will almost certainly >>>>>>> make >>>>>>> the driver behave quite differently. >>>>>>> >>>>>>>> but beyond that I am lost. Can someone provide >>>>>>>> me with some directions? I need to know how to make the driver. To >>>>>>>> that >>>>>>>> end, I probably will have to install additional packages. After >>>>>>>> making >>>>>>>> the driver, I need to know how to install it over the existing >>>>>>>> driver. >>>>>>> >>>>>>> Here's one way to do it: >>>>>>> >>>>>>> 1. git clone >>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git (your >>>>>>> patch should apply on top of this tree eventually) >>>>>>> 2. cd sound >>>>>>> 3. zcat /proc/config.gz >.config >>>>>>> 4. build and install the kernel image. How that is done depends on the >>>>>>> distribution you're using. For Ubuntu follow the docs at [1] (start at >>>>>>> point #5). For Fedora and others, something like "make && make >>>>>>> install" >>>>>>> should do >>>>>>> 5. reboot and check that the new kernel is running >>>>>>> 6. hack on sound/usb >>>>>>> 7. make M=sound/usb >>>>>>> 8. reload the module with "sudo rmmod snd_usb_audio; sudo insmod >>>>>>> sound/usb/snd-usb-audio.ko" (better plug out the device before so you >>>>>>> always have the same defined point of start) >>>>>>> >>>>>>> >>>>>>> Hope that works for you. >>>>>>> >>>>>>> >>>>>>> Daniel >>>>>>> >>>>>>> [1] https://wiki.ubuntu.com/KernelTeam/GitKernelBuild >>>>>> >>>>>> Your directions were almost perfect, so even I was able to build the >>>>>> kernel. I made a discovery using the new kernel that might help someone >>>>>> more familiar with the code than I am to localize the problem. I am >>>>>> still hearing the blip when I play audio sampled at 88.2 kHz, but I >>>>>> just >>>>>> noticed that the blip is perfectly periodic, with a period of about >>>>>> 16.4 >>>>>> seconds. I am playing a sine wave synthesized using GStreamer using >>>>>> the >>>>>> following command: >>>>>> >>>>>> gst-launch audiotestsrc volume=0.01 ! audio/x-raw-float, width=64, >>>>>> rate=88200, channels=2, endianness=1234 ! audioconvert ! alsasink >>>>>> >>>>>> A sine wave makes it easier to hear the blip. Does this clue suggest >>>>>> anything? >>>>>> >>>>>> I also want to mention that when I use the new kernel, I do not get the >>>>>> ticks at either 88.2 or 96 kHz even when I do not use the external USB >>>>>> hub. I plan next to back up to the 3.6.2 kernel to see whether I still >>>>>> get ticks there. >>>>> >>>>> Which kernel did you use when you heard the 'blibs'? >>>> >>>> The latest news is bad. I am on 3.2.0 now. The USB DAC is working >>>> perfectly at this moment at both 96 kHz and 88.2 kHz without the external >>>> USB hub (imagine calling that bad news). If I set the srate to 88.2 kHz >>>> and stop and start the sine wave, sometimes I get the blip. Forget about >>>> its being periodic. It was definitely periodic before lunch; now I >>>> usually >>>> get random intervals if I get any blips at all. As I am typing this >>>> message, I can't get blips at all. There was some correlation between >>>> changing sample rates and blips, but I can't reproduce that behavior now. >>>> What is most weird is that I haven't gotten any ticks since lunch with >>>> any >>>> kernel or with either sample rate, yet they were reliable earlier today >>>> unless I used the external USB hub. I obviously need to experiment some >>>> more to see whether I can observe a pattern. >>> >>> To conclude (?) this thread, I am now convinced that the anomalies I >>> observed were unrelated to the device driver. I had two theories >>> remaining. One was that the problem was somehow related to an >>> overheating problem. I used a heat gun to convince myself that the >>> theory was wrong. The other was that the problem had something to do >>> with services running in the background that interfered with the device >>> driver. I removed or disabled all services that I could identify as >>> superfluous. Removed services include zeitgeist, apparmor, modemmanager, >>> mdadm, and bluetooth. Disabled services include atd, dns-clean, and >>> pppd-dns. The system has been running perfectly with an 88.2 kHz sample >>> rate and no external USB hub for 2 days. However, I tried booting the >>> system with a copy of the OS from before I removed superfluous services. >>> It still ran perfectly. Thus, I cannot convince myself that removing >>> superfluous services actually solved the problem. I suppose it's >>> possible that some service was running sporadically, which could explain >>> why the problem seemed to come and go and also why the problem did not >>> occur when I booted the copy of the OS. As long as the problem remains >>> dormant I have no alternative but to move on and see whether the problem >>> eventually recurs. Only time will tell. >>> >>> Thanks for all the help. Hey, I built a kernel and got my own version of >>> the device driver to run. That was exciting. >>> >>> -------------------------------------------------------------------------- >>> ---- >>> >>> I'm back. The USB DAC continued to work for two more days after my last >>> message and then the blips resumed. I've been digging into the driver >>> code >>> for two days. I spent today trying to convince myself that the driver is >>> actually using an asynchronous protocol. The blips are almost certainly >>> buffer underruns, which I could account for if the driver were not >>> responding to asynchronous feedback from the DAC. I expected to see a >>> deviation from the pattern of one frame with 89 samples followed by 4 >>> frames with 88 (which results in 88,200 samples per second). That >>> sequence would work perfectly if the clocks in the computer and in the >>> USB DAC were exactly the same frequency, but of course they are not. >>> Consequently, I would expect to see requests for one sample more or less >>> once in a while, depending on whether the clock in the computer is slower >>> or faster than the one in the DAC. What I see is 89 + 4 * 88 almost all >>> the time, as expected . Once in a while there is a request for an >>> additional frame of 88 and then the pattern of 89 + 4 * 88 resumes. I >>> presume that the break in the usual pattern indicates that the device >>> driver is responding to a request from the DAC for fewer samples, which >>> confirms that the driver is using the asynchronous protocol. That's >>> good, if I am right. However, sticking in an extra packet of only 88 >>> would be the expected deviation if the host were getting a little ahead >>> of the DAC, yet the blip is almost certainly a buffer underrun, which >>> means that the host is actually falling behind. Thus, an extra packet of >>> 89 would make more sense. I should also mention that there is no >>> correlation between the timing of the extra packet of 88 and the audible >>> blip. Something seems wrong here, but I'm not sure where to go next. >>> >>> On a related topic, to confirm that the blip is a buffer underrun, I would >>> like to synthesize a waveform that is DC. With DC, an overrun would not >>> produce any audible anomalies whereas an underrun would be audible. I am >>> using GStreamer to synthesize the test waveform. Does anyone know of a >>> way to synthesize a DC waveform using GStreamer? If not, is there any >>> other tool available in Linux? >>> >>> By the way, I bought another USB DAC from a different manufacturer to be >>> sure that the anomalies I am observing were not due to a defect in the >>> DAC. They both display the same problem. >>> >>> ----------------------------------------------------- >>> >>> I modified the device driver to output a constant instead of the incoming >>> waveform. I get blips, as I expected, so I am now certain that the blips >>> are caused by a buffer underrun. The blips occur periodically again -- >>> period of about 16.5 seconds. I presume that the period is related to >>> the difference in clock rates between the host and DAC. Roughly every >>> 3-4 blips, I get an extra packet of 88 samples. To prevent buffer >>> underrun, I ought to be getting an extra packet of 89 samples every 16.5 >>> seconds, but I never do. >> >> Thanks for all your investigation on this! Sending computed data instead >> of the payload delivered by the ALSA stack is in fact a very good way to >> isolate the issue. >> >> The question is: if the algorithm in the USB driver miscalculates the >> number of samples to send over time, what't the reason for that? Does >> the device report bogus values or is there this a bug in the driver? > > Well, I have two DACs, each from a different manufacturer. Both experience > underruns (though not at the same rate). It's possible that they are both > reporting bogus values, but unlikely, so I'm leaning toward the bug theory. > >> Did you read chapter 5.4.12.1 of the USB2.0 spec, and can you explain >> where you suspect the bug to be? The current implementation in the >> driver is quite straight forward, mapping all feedback values to Q16.16 >> and keeping the lower 16bits around for phase compensation between the >> calculation of the packet sizes. > > Do you perhaps mean chapter 5.12.4.1 (Synchronization Type)? I'm not finding a > 5.4.12.1 in usb_20.pdf from a zip dated 102512. Yes, sorry. > Please tell me whether I have this right: > > You start transferring the sound in snd_usb_endpoint_start using > usb_submit_urb to submit 2 urbs to the USB core. The urbs specify that on > completion, the USB core should call snd_complete_urb. snd_complete_urb > resubmits the urb after calling retire_playback_urb (by way of > retire_outbound_urb which calls retire_data_urb which is retire_playback_urb), > which updates its estimate of delay (what's that? It seems to be 0 always) That's just an information that is passed to userspace for latency compensation matters. As you don't stream data that ALSA passes up the stack anymore in your tests (but static data), you can ignore this detail for now. > and prepare_playback_urb (by way of prepare_outbound_urb which calls > prepare_data_urb which is prepare_playback_urb), which fills the transfer_buffer > in the urb with the audio data (from a DMA buffer, I guess). > > Before filling transfer_buffer, prepare_playback_urb calls > snd_usb_endpoint_next_packet_size to compute the number of samples to send. > This code appears to be the crux of what I need to understand because the > value returned from this function is what is supposed to adjust to prevent > buffer underruns. That's correct. > It isn't clear to me how this function gets information > about the state of the buffer in the device. Via the callback of the feedback data endpoint - the momentary frequency is updated there and referred to again in snd_usb_endpoint_next_packet_size(). > The only argument to > snd_usb_endpoint_next_packet_size is ep, which is a pointer to the > snd_usb_endpoint structure. Yes, the endpoint structure hold all runtime streaming details. Once a sync urb is given back from the host controller, retire_inbound_urb() is called and snd_usb_handle_sync_urb() cares for updating the momentary frequency of the slave of the sync endpoint, which is the data endpoint that is later on used by next_packet_size(). Makes sense? > I see that ep->phase is the Q16.16 value you > mentioned, so the lower 16 bits are for "phase compensation between the > calculation of the packet sizes". I don't completely understand that phrase. > freqm is an unchanging value (5780275) freqm shouldn't be unchanging. Are you sure it really is? If so, is snd_usb_handle_sync_urb() ever called in your setup? > and datainterval is an unchanging value > (0). phase fluctuates in a narrow range (roughly 5792282 to 5832702), but it > is fluctuating only as a consequence of this calculation: we take the bottom 16 > bits of its value and add a fixed value. If I understand this calculation > correctly, I can almost see how it could provide the sequence of packet sizes > (the 89 + 4 * 88 sequence) necessary to produce the correct number of samples > per second, but I don't see how it adjusts that number to the slightly > different concept of time at the device. However, even in that understanding I > am perplexed because I occasionally see an extra packet of 88. The device reports its buffer state by providing feedback information in a perioc manner, as letting the host know about what the device think is its correct data rate is the only way to compensate clock drifts. > Also, I think I understand why you start the transfer with 2 urbs: When the > device finishes with the first urb, the next urb has to be there already to > avoid a period when no urb is present. However, right away an alarm goes off. > When the device finishes processing the first urb, it provides feedback about > the state of the buffer. However, the host cannot respond to this feedback > until after the second urb is processed. Have we convinced ourselves that the > lag doesn't matter? I don't know because I don't understand what happens to > the urb after we send it to the USB core. What do you know about the nature > of the buffering in the device? Is there a place for the USB hardware to store > the contents of transfer_buffer independently of a buffer that feeds the actual > DAC? When does the USB hardware transfer the second urb to the device? Isochronous transfers are scheduled on the bus and sent in the configured time slot (or as soon as possible, if the ASAP flag is set). Data payload should be distributed as evenly as possible over the microframes to not blast the device's internal buffers due to bursts. > Who > tells the DAC to start playing the contents of the buffer? Ususally, once it has its buffers filled with data. > I would like to > hear that the device has a FIFO whose size is sufficient to hold the contents of > at least two transfer_buffers. The first two urbs would fill it before > activating the DAC. Every time the DAC finishes outputting the contents of one > urb, it provides feedback with the amount of space remaining in the FIFO. Not quite. It does report the momentary frequency in periodic packets (like every 16ms), not after each packet. > We > would send that many samples in the next urb. I am fantasizing this solution. > Tell me how it really works. It's described in 5.12.4.1 (Synchronization Type). The driver aims to be as close the the actual data rate that is reported by the device every couple of milliseconds. Does that answer your questions? Daniel

1 0

[alsa-devel] Idea: dynamic loading of USB quirks
by maillist＠superlative.org 05 Nov '12

05 Nov '12

Dear Alsa community, I've some minor contributions in the form of patches for USB quirks for devices in the past. It occurred to me that having these USB quirks hardcoded into the driver maybe isn't the best thing. Looking at the current quirks file, the majority of them are relatively trivial and are really just there to give the USB driver a nudge in the right direction. Having to have these hardcoded into the driver creates a number of issues: 1. It needs someone with the expertise and will, and access the specific device for testing, to build the quirk. To hardened ALSA hackers this seems trivial, but to an average end user who has a device they want to get supported, this can be pretty inpenatrable. The complexity of just getting the alsa source installed and set up for compilation is enough to put off the vast majority of users. 2. It makes the process of getting the driver "to market" lengthy as these changes have to go through all of the normal release schedules, and these are pretty opaque. 3. It makes getting changing a driver (because of a bug, or a new release of hardware) difficult as the revisions need to go through the whole process of creating a patch, getting it accepted, and then the long kernel release process, as well as the various distribution release processes. It occured to me that there might be a better way where quirks like this could be dynamically loaded into the driver after it has loaded. This would a structured text file describing the quirk to be created and pushed into the driver. Ultimately this could be wrapped into a framework where quirk files could be put into a common directory (similar to modprobe.d) with a startup script which pushed these into the driver. At the moment I don't have any specific thoughts about how to do this, but I thought it would be useful to elicit ideas from this community. The way I see it it needs: * A structured file format to describe the quirks * A basic method to push these files into the driver at runtime (sysfs?) * Some sort of dynamic data area for the driver to store the data * changes to the driver to accept, store and process these data structures At the moment I just thought I would get people thinking about this and, perhaps, making suggestions about whether it makes sense, whether it's practically achievable within the framework of the kernel and ALSA, and possible methods which might lead to a solution. If I get the time (and, at the moment, that's unlikely for the next 6 months) I'll look at trying to code something up. If anyone else is inspired and feels like having a crack at it, then feel free. All comments and discussion welcome. Cheers, Keith

3 3

[alsa-devel] [PATCH] snd-es1968: Add ESS vendor ID to pm_whitelist
by Ondrej Zary 05 Nov '12

05 Nov '12

Add generic ESS vendor ID to pm_whitelist. This should fix suspend on all Maestro-2 and Maestro-2E based PCI cards. Tested on Terratec DMX and SF64-PCE2. Signed-off-by: Ondrej Zary <linux(a)rainbow-software.org> --- a/sound/pci/es1968.c +++ b/sound/pci/es1968.c @@ -2655,6 +2655,8 @@ static struct ess_device_list pm_whitelist[] __devinitdata = { { TYPE_MAESTRO2E, 0x1179 }, { TYPE_MAESTRO2E, 0x14c0 }, /* HP omnibook 4150 */ { TYPE_MAESTRO2E, 0x1558 }, + { TYPE_MAESTRO2E, 0x125d }, /* a PCI card, e.g. Terratec DMX */ + { TYPE_MAESTRO2, 0x125d }, /* a PCI card, e.g. SF64-PCE2 */ }; static struct ess_device_list mpu_blacklist[] __devinitdata = { -- Ondrej Zary

2 1

[alsa-devel] [PATCH 1/2] HDA: Fix digital microphone on CS420x
by Daniel J Blueman 05 Nov '12

05 Nov '12

Correctly enable the digital microphones with the right bits in the right coeffecient registers on Cirrus CS4206/7 codecs. It also prevents misconfiguring ADC1/2. This fixes the digital mic on the Macbook Pro 10,1/Retina. Based-on-patch-by: Alexander Stein <alexander.stein(a)systec-electronic.com> Signed-off-by: Daniel J Blueman <daniel(a)quora.org> --- sound/pci/hda/patch_cirrus.c | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/sound/pci/hda/patch_cirrus.c b/sound/pci/hda/patch_cirrus.c index 61a7113..859a119 100644 --- a/sound/pci/hda/patch_cirrus.c +++ b/sound/pci/hda/patch_cirrus.c @@ -101,8 +101,8 @@ enum { #define CS420X_VENDOR_NID 0x11 #define CS_DIG_OUT1_PIN_NID 0x10 #define CS_DIG_OUT2_PIN_NID 0x15 -#define CS_DMIC1_PIN_NID 0x12 -#define CS_DMIC2_PIN_NID 0x0e +#define CS_DMIC1_PIN_NID 0x0e +#define CS_DMIC2_PIN_NID 0x12 /* coef indices */ #define IDX_SPDIF_STAT 0x0000 @@ -1079,14 +1079,18 @@ static void init_input(struct hda_codec *codec) cs_automic(codec, NULL); coef = 0x000a; /* ADC1/2 - Digital and Analog Soft Ramp */ + cs_vendor_coef_set(codec, IDX_ADC_CFG, coef); + + coef = cs_vendor_coef_get(codec, IDX_BEEP_CFG); if (is_active_pin(codec, CS_DMIC2_PIN_NID)) - coef |= 0x0500; /* DMIC2 2 chan on, GPIO1 off */ + coef |= 1 << 4; /* DMIC2 2 chan on, GPIO1 off */ if (is_active_pin(codec, CS_DMIC1_PIN_NID)) - coef |= 0x1800; /* DMIC1 2 chan on, GPIO0 off + coef |= 1 << 3; /* DMIC1 2 chan on, GPIO0 off * No effect if SPDIF_OUT2 is * selected in IDX_SPDIF_CTL. */ - cs_vendor_coef_set(codec, IDX_ADC_CFG, coef); + + cs_vendor_coef_set(codec, IDX_BEEP_CFG, coef); } else { if (spec->mic_detect) cs_automic(codec, NULL); -- 1.7.10.4

2 4

[alsa-devel] ad1988 spdif crackling (includes patch)
by Robin Kreis 05 Nov '12

05 Nov '12

Hi! For nearly three years, a bug has been known to cripple SPDIF output on certain hardware. It might work fine for a while, but will randomly break, showing two symptoms: PCM audio is distorted (similar to clipping) while compressed audio (AC3 or DTS) will not work at all. Muting an unmuting the master channel may temporarily fix it. This affects at least all Asus P5B and P6B mainboards. The solution is a simple one-liner, and has been known for a year: http://fjerhammer.dk/ad1988_spdif_crackling.patch (credits go to Javeed Shaikh for the patch and fjerhammer for hosting it). I can verify that it fixes all issues on my setup. Please apply it. See also: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/359361 Greetings, Robin Kreis

3 2

[alsa-devel] [PATCH v2 1/2] ASoC: tlv320aic32x4: Fix problem with first capture.
by Javier Martin 05 Nov '12

05 Nov '12

In its previous status, the first capture didn't work properly; nothing was actually recorded from the microphone. This behaviour was observed using a Visstrim M10 board. In order to solve this BUG a workaround has been added that, during the initialization process of the codec, powers on and off the ADC. The issue seems related to a HW BUG or some behavior that is not documented in the datasheet. Signed-off-by: Javier Martin <javier.martin(a)vista-silicon.com> --- Changes since v1: - Use a subject line according to the ASoC subsystem. --- sound/soc/codecs/tlv320aic32x4.c | 10 ++++++++++ sound/soc/codecs/tlv320aic32x4.h | 3 +++ 2 files changed, 13 insertions(+) diff --git a/sound/soc/codecs/tlv320aic32x4.c b/sound/soc/codecs/tlv320aic32x4.c index b0a73d3..aad92f9 100644 --- a/sound/soc/codecs/tlv320aic32x4.c +++ b/sound/soc/codecs/tlv320aic32x4.c @@ -675,6 +675,16 @@ static int aic32x4_probe(struct snd_soc_codec *codec) ARRAY_SIZE(aic32x4_snd_controls)); aic32x4_add_widgets(codec); + /* + * Workaround: for an unknown reason, the ADC needs to be powered up + * and down for the first capture to work properly. It seems related to + * a HW BUG or some kind of behavior not documented in the datasheet. + */ + tmp_reg = snd_soc_read(codec, AIC32X4_ADCSETUP); + snd_soc_write(codec, AIC32X4_ADCSETUP, tmp_reg | + AIC32X4_LADC_EN | AIC32X4_RADC_EN); + snd_soc_write(codec, AIC32X4_ADCSETUP, tmp_reg); + return 0; } diff --git a/sound/soc/codecs/tlv320aic32x4.h b/sound/soc/codecs/tlv320aic32x4.h index aae2b24..3577422 100644 --- a/sound/soc/codecs/tlv320aic32x4.h +++ b/sound/soc/codecs/tlv320aic32x4.h @@ -94,6 +94,9 @@ #define AIC32X4_WORD_LEN_24BITS 0x02 #define AIC32X4_WORD_LEN_32BITS 0x03 +#define AIC32X4_LADC_EN (1 << 7) +#define AIC32X4_RADC_EN (1 << 6) + #define AIC32X4_I2S_MODE 0x00 #define AIC32X4_DSP_MODE 0x01 #define AIC32X4_RIGHT_JUSTIFIED_MODE 0x02 -- 1.7.9.5

3 8

Re: [alsa-devel] [PATCH] ASoC: atmel_ssc_dai: make module reloadable
by Bo Shen 05 Nov '12

05 Nov '12

Hi Alexandre Belloni, On 11/1/2012 14:18, Alexandre Belloni wrote: > As the platform_devices were never unregistered, it was not possible to > unload/reload the module. > > Signed-off-by: Alexandre Belloni <alexandre.belloni(a)piout.net> > --- > sound/soc/atmel/atmel_ssc_dai.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) NACK - Thanks for your work on atmel ssc dai component. Now, I am reworking the atmel ssc dai audio framework. So, some of them will be none exist any more. Thanks again. Best regards, Bo Shen > diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c > index 354341e..07ee57b 100644 > --- a/sound/soc/atmel/atmel_ssc_dai.c > +++ b/sound/soc/atmel/atmel_ssc_dai.c > @@ -155,6 +155,8 @@ static struct atmel_ssc_info ssc_info[NUM_SSC_DEVICES] = { > #endif > }; > > +static struct platform_device *dma_pdev; > +static struct platform_device *ssc_pdevs[NUM_SSC_DEVICES]; > > /* > * SSC interrupt handler. Passes PDC interrupts to the DMA > @@ -796,6 +798,12 @@ static __devinit int asoc_ssc_probe(struct platform_device *pdev) > > static int __devexit asoc_ssc_remove(struct platform_device *pdev) > { > + int i; > + platform_device_unregister(dma_pdev); > + > + for(i = 0; i < NUM_SSC_DEVICES; i++) > + platform_device_unregister(ssc_pdevs[i]); > + > snd_soc_unregister_dai(&pdev->dev); > return 0; > } > @@ -816,7 +824,6 @@ static struct platform_driver asoc_ssc_driver = { > int atmel_ssc_set_audio(int ssc_id) > { > struct ssc_device *ssc; > - static struct platform_device *dma_pdev; > struct platform_device *ssc_pdev; > int ret; > > @@ -855,6 +862,8 @@ int atmel_ssc_set_audio(int ssc_id) > if (ret < 0) > platform_device_put(ssc_pdev); > > + ssc_pdevs[ssc_id] = ssc_pdev; > + > return ret; > } > EXPORT_SYMBOL_GPL(atmel_ssc_set_audio); >

1 0

Re: [alsa-devel] [Alsa-user] Ticks when playing to USB DAC at high sample rates
by Daniel Mack 04 Nov '12

04 Nov '12

[cc alsa-devel] On 04.11.2012 02:25, Jeffrey Barish wrote: > On Fri 26 October 2012 15:21:06 Jeffrey Barish wrote: >> On Fri 26 October 2012 21:47:05 Daniel Mack wrote: >>> On 26.10.2012 21:43, Jeffrey Barish wrote: >>>> On Thu 25 October 2012 19:10:45 Daniel Mack wrote: >>>>> On 25.10.2012 17:18, Jeffrey Barish wrote: >>>>>> I found something in the snd_usb_audio code (in endpoint.c) that could >>>>>> explain one of the problems I have observed (the ticks). I would >>>>>> normally test my theory by modifying the code. In this case, I would >>>>>> like to stick in a print statement to see what values are being >>>>>> assigned >>>>>> to certain variables. Unfortunately, I am too ignorant to do something >>>>>> even this trivial as I have never worked on kernel code. I think I am >>>>>> supposed to use printk, >>>>> >>>>> printk is nice for simple debugging, yes. But note that this call is >>>>> timing critical and should not be used in "fast path" code. Introducing >>>>> a printk for each received packet for example will almost certainly >>>>> make >>>>> the driver behave quite differently. >>>>> >>>>>> but beyond that I am lost. Can someone provide >>>>>> me with some directions? I need to know how to make the driver. To >>>>>> that >>>>>> end, I probably will have to install additional packages. After making >>>>>> the driver, I need to know how to install it over the existing driver. >>>>> >>>>> Here's one way to do it: >>>>> >>>>> 1. git clone >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git (your >>>>> patch should apply on top of this tree eventually) >>>>> 2. cd sound >>>>> 3. zcat /proc/config.gz >.config >>>>> 4. build and install the kernel image. How that is done depends on the >>>>> distribution you're using. For Ubuntu follow the docs at [1] (start at >>>>> point #5). For Fedora and others, something like "make && make install" >>>>> should do >>>>> 5. reboot and check that the new kernel is running >>>>> 6. hack on sound/usb >>>>> 7. make M=sound/usb >>>>> 8. reload the module with "sudo rmmod snd_usb_audio; sudo insmod >>>>> sound/usb/snd-usb-audio.ko" (better plug out the device before so you >>>>> always have the same defined point of start) >>>>> >>>>> >>>>> Hope that works for you. >>>>> >>>>> >>>>> Daniel >>>>> >>>>> [1] https://wiki.ubuntu.com/KernelTeam/GitKernelBuild >>>> >>>> Your directions were almost perfect, so even I was able to build the >>>> kernel. I made a discovery using the new kernel that might help someone >>>> more familiar with the code than I am to localize the problem. I am >>>> still hearing the blip when I play audio sampled at 88.2 kHz, but I just >>>> noticed that the blip is perfectly periodic, with a period of about 16.4 >>>> seconds. I am playing a sine wave synthesized using GStreamer using the >>>> following command: >>>> >>>> gst-launch audiotestsrc volume=0.01 ! audio/x-raw-float, width=64, >>>> rate=88200, channels=2, endianness=1234 ! audioconvert ! alsasink >>>> >>>> A sine wave makes it easier to hear the blip. Does this clue suggest >>>> anything? >>>> >>>> I also want to mention that when I use the new kernel, I do not get the >>>> ticks at either 88.2 or 96 kHz even when I do not use the external USB >>>> hub. I plan next to back up to the 3.6.2 kernel to see whether I still >>>> get ticks there. >>> >>> Which kernel did you use when you heard the 'blibs'? >> >> The latest news is bad. I am on 3.2.0 now. The USB DAC is working >> perfectly at this moment at both 96 kHz and 88.2 kHz without the external >> USB hub (imagine calling that bad news). If I set the srate to 88.2 kHz >> and stop and start the sine wave, sometimes I get the blip. Forget about >> its being periodic. It was definitely periodic before lunch; now I usually >> get random intervals if I get any blips at all. As I am typing this >> message, I can't get blips at all. There was some correlation between >> changing sample rates and blips, but I can't reproduce that behavior now. >> What is most weird is that I haven't gotten any ticks since lunch with any >> kernel or with either sample rate, yet they were reliable earlier today >> unless I used the external USB hub. I obviously need to experiment some >> more to see whether I can observe a pattern. > > To conclude (?) this thread, I am now convinced that the anomalies I observed > were unrelated to the device driver. I had two theories remaining. One was > that the problem was somehow related to an overheating problem. I used a heat > gun to convince myself that the theory was wrong. The other was that the > problem had something to do with services running in the background that > interfered with the device driver. I removed or disabled all services that I > could identify as superfluous. Removed services include zeitgeist, apparmor, > modemmanager, mdadm, and bluetooth. Disabled services include atd, dns-clean, > and pppd-dns. The system has been running perfectly with an 88.2 kHz sample > rate and no external USB hub for 2 days. However, I tried booting the system > with a copy of the OS from before I removed superfluous services. It still ran > perfectly. Thus, I cannot convince myself that removing superfluous services > actually solved the problem. I suppose it's possible that some service was > running sporadically, which could explain why the problem seemed to come and > go and also why the problem did not occur when I booted the copy of the OS. > As long as the problem remains dormant I have no alternative but to move on > and see whether the problem eventually recurs. Only time will tell. > > Thanks for all the help. Hey, I built a kernel and got my own version of the > device driver to run. That was exciting. > > ------------------------------------------------------------------------------ > > I'm back. The USB DAC continued to work for two more days after my last > message and then the blips resumed. I've been digging into the driver code > for two days. I spent today trying to convince myself that the driver is > actually using an asynchronous protocol. The blips are almost certainly buffer > underruns, which I could account for if the driver were not responding to > asynchronous feedback from the DAC. I expected to see a deviation from the > pattern of one frame with 89 samples followed by 4 frames with 88 (which > results in 88,200 samples per second). That sequence would work perfectly if > the clocks in the computer and in the USB DAC were exactly the same frequency, > but of course they are not. Consequently, I would expect to see requests for > one sample more or less once in a while, depending on whether the clock in the > computer is slower or faster than the one in the DAC. What I see is 89 + 4 * > 88 almost all the time, as expected . Once in a while there is a request for > an additional frame of 88 and then the pattern of 89 + 4 * 88 resumes. I > presume that the break in the usual pattern indicates that the device driver > is responding to a request from the DAC for fewer samples, which confirms that > the driver is using the asynchronous protocol. That's good, if I am right. > However, sticking in an extra packet of only 88 would be the expected > deviation if the host were getting a little ahead of the DAC, yet the blip is > almost certainly a buffer underrun, which means that the host is actually > falling behind. Thus, an extra packet of 89 would make more sense. I should > also mention that there is no correlation between the timing of the extra > packet of 88 and the audible blip. Something seems wrong here, but I'm not > sure where to go next. > > On a related topic, to confirm that the blip is a buffer underrun, I would like > to synthesize a waveform that is DC. With DC, an overrun would not produce > any audible anomalies whereas an underrun would be audible. I am using > GStreamer to synthesize the test waveform. Does anyone know of a way to > synthesize a DC waveform using GStreamer? If not, is there any other tool > available in Linux? > > By the way, I bought another USB DAC from a different manufacturer to be sure > that the anomalies I am observing were not due to a defect in the DAC. They > both display the same problem. > > ----------------------------------------------------- > > I modified the device driver to output a constant instead of the incoming > waveform. I get blips, as I expected, so I am now certain that the blips are > caused by a buffer underrun. The blips occur periodically again -- period of > about 16.5 seconds. I presume that the period is related to the difference in > clock rates between the host and DAC. Roughly every 3-4 blips, I get an extra > packet of 88 samples. To prevent buffer underrun, I ought to be getting an > extra packet of 89 samples every 16.5 seconds, but I never do. Thanks for all your investigation on this! Sending computed data instead of the payload delivered by the ALSA stack is in fact a very good way to isolate the issue. The question is: if the algorithm in the USB driver miscalculates the number of samples to send over time, what't the reason for that? Does the device report bogus values or is there this a bug in the driver? Did you read chapter 5.4.12.1 of the USB2.0 spec, and can you explain where you suspect the bug to be? The current implementation in the driver is quite straight forward, mapping all feedback values to Q16.16 and keeping the lower 16bits around for phase compensation between the calculation of the packet sizes. If you find a better solution, please share it here, preferably in the form of a patch :) Thanks, Daniel

1 0

[alsa-devel] [PATCH 5/9] ASoC: Only compile adav80x codec when a bus is defined
by Lee Jones 04 Nov '12

04 Nov '12

If !CONFIG_SPI and !CONFIG_I2C* then there is no point adding support for the adav80x codec as it relies on a bus to operate. This patch fixes the build warnings below when SPI and I2C are not specified in the configuration. sound/soc/codecs/adav80x.c:842:22: warning: ‘adav80x_bus_probe’ defined but not used [-Wunused-function] sound/soc/codecs/adav80x.c:863:22: warning: ‘adav80x_bus_remove’ defined but not used [-Wunused-function] Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Cc: alsa-devel(a)alsa-project.org Signed-off-by: Lee Jones <lee.jones(a)linaro.org> --- sound/soc/codecs/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index b92759a..0d8135a 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -19,7 +19,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_AD1980 if SND_SOC_AC97_BUS select SND_SOC_AD73311 select SND_SOC_ADAU1373 if I2C - select SND_SOC_ADAV80X + select SND_SOC_ADAV80X if (I2C || I2C_MODULE || SPI_MASTER) select SND_SOC_ADS117X select SND_SOC_AK4104 if SPI_MASTER select SND_SOC_AK4535 if I2C -- 1.7.9.5

2 2

[alsa-devel] [PATCH] snd-es1968: remove pm_whitelist
by Ondrej Zary 04 Nov '12

04 Nov '12

pm_whitelist breaks suspend on all non-whitelisted cards for unknown purpose. Remove it. This fixes suspend on Terratec DMX and SF64-PCE2 cards. Signed-off-by: Ondrej Zary <linux(a)rainbow-software.org> --- sound/pci/es1968.c | 40 ---------------------------------------- 1 files changed, 0 insertions(+), 40 deletions(-) diff --git a/sound/pci/es1968.c b/sound/pci/es1968.c index 5d0e568..a9c92a4 100644 --- a/sound/pci/es1968.c +++ b/sound/pci/es1968.c @@ -137,7 +137,6 @@ static int total_bufsize[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS - 1)] = 1024 }; static int pcm_substreams_p[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS - 1)] = 4 }; static int pcm_substreams_c[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS - 1)] = 1 }; static int clock[SNDRV_CARDS]; -static int use_pm[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS - 1)] = 2}; static int enable_mpu[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS - 1)] = 2}; #ifdef SUPPORT_JOYSTICK static bool joystick[SNDRV_CARDS]; @@ -158,8 +157,6 @@ module_param_array(pcm_substreams_c, int, NULL, 0444); MODULE_PARM_DESC(pcm_substreams_c, "PCM Capture substreams for " CARD_NAME " soundcard."); module_param_array(clock, int, NULL, 0444); MODULE_PARM_DESC(clock, "Clock on " CARD_NAME " soundcard. (0 = auto-detect)"); -module_param_array(use_pm, int, NULL, 0444); -MODULE_PARM_DESC(use_pm, "Toggle power-management. (0 = off, 1 = on, 2 = auto)"); module_param_array(enable_mpu, int, NULL, 0444); MODULE_PARM_DESC(enable_mpu, "Enable MPU401. (0 = off, 1 = on, 2 = auto)"); #ifdef SUPPORT_JOYSTICK @@ -519,7 +516,6 @@ struct es1968 { struct pci_dev *pci; struct snd_card *card; struct snd_pcm *pcm; - int do_pm; /* power-management enabled */ /* DMA memory block */ struct list_head buf_list; @@ -2387,9 +2383,6 @@ static int es1968_suspend(struct device *dev) struct snd_card *card = dev_get_drvdata(dev); struct es1968 *chip = card->private_data; - if (! chip->do_pm) - return 0; - chip->in_suspend = 1; cancel_work_sync(&chip->hwvol_work); snd_power_change_state(card, SNDRV_CTL_POWER_D3hot); @@ -2410,9 +2403,6 @@ static int es1968_resume(struct device *dev) struct es1968 *chip = card->private_data; struct esschan *es; - if (! chip->do_pm) - return 0; - /* restore all our config */ pci_set_power_state(pci, PCI_D0); pci_restore_state(pci); @@ -2648,15 +2638,6 @@ struct ess_device_list { unsigned short vendor; /* subsystem vendor id */ }; -static struct ess_device_list pm_whitelist[] __devinitdata = { - { TYPE_MAESTRO2E, 0x0e11 }, /* Compaq Armada */ - { TYPE_MAESTRO2E, 0x1028 }, - { TYPE_MAESTRO2E, 0x103c }, - { TYPE_MAESTRO2E, 0x1179 }, - { TYPE_MAESTRO2E, 0x14c0 }, /* HP omnibook 4150 */ - { TYPE_MAESTRO2E, 0x1558 }, -}; - static struct ess_device_list mpu_blacklist[] __devinitdata = { { TYPE_MAESTRO2, 0x125d }, }; @@ -2667,7 +2648,6 @@ static int __devinit snd_es1968_create(struct snd_card *card, int play_streams, int capt_streams, int chip_type, - int do_pm, int radio_nr, struct es1968 **chip_ret) { @@ -2736,25 +2716,6 @@ static int __devinit snd_es1968_create(struct snd_card *card, /* just to be sure */ pci_set_master(pci); - if (do_pm > 1) { - /* disable power-management if not on the whitelist */ - unsigned short vend; - pci_read_config_word(chip->pci, PCI_SUBSYSTEM_VENDOR_ID, &vend); - for (i = 0; i < (int)ARRAY_SIZE(pm_whitelist); i++) { - if (chip->type == pm_whitelist[i].type && - vend == pm_whitelist[i].vendor) { - do_pm = 1; - break; - } - } - if (do_pm > 1) { - /* not matched; disabling pm */ - printk(KERN_INFO "es1968: not attempting power management.\n"); - do_pm = 0; - } - } - chip->do_pm = do_pm; - snd_es1968_chip_init(chip); if ((err = snd_device_new(card, SNDRV_DEV_LOWLEVEL, chip, &ops)) < 0) { @@ -2817,7 +2778,6 @@ static int __devinit snd_es1968_probe(struct pci_dev *pci, pcm_substreams_p[dev], pcm_substreams_c[dev], pci_id->driver_data, - use_pm[dev], radio_nr[dev], &chip)) < 0) { snd_card_free(card); -- Ondrej Zary

3 3

[alsa-devel] [PATCH] ALSA: hda - support Teradici 2200 host card audio
by Lars R. Damerow 04 Nov '12

04 Nov '12

Hello, This patch adds support for Teradici's new Tera2 host card audio. The new card has the same audio chipset as the previous version, so all it's doing is recognizing the new PCI ID and treating it just like the previous one. thanks, -lars Lars R. Damerow (1): ALSA: hda - support Teradici 2200 host card audio sound/pci/hda/hda_intel.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)

2 2

[alsa-devel] [PATCH] [trivial] sound: Fix typo in drivers sound
by Masanari Iida 04 Nov '12

04 Nov '12

Correct spelling typo in debug messages within drivers/sound Signed-off-by: Masanari Iida <standby24x7(a)gmail.com> --- sound/i2c/other/ak4113.c | 2 +- sound/i2c/other/ak4114.c | 2 +- sound/i2c/other/ak4117.c | 2 +- sound/pci/rme9652/hdspm.c | 2 +- sound/soc/codecs/cs42l52.c | 2 +- sound/soc/codecs/wm8994.c | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/sound/i2c/other/ak4113.c b/sound/i2c/other/ak4113.c index ef68d71..e04e750 100644 --- a/sound/i2c/other/ak4113.c +++ b/sound/i2c/other/ak4113.c @@ -426,7 +426,7 @@ static struct snd_kcontrol_new snd_ak4113_iec958_controls[] = { }, { .iface = SNDRV_CTL_ELEM_IFACE_PCM, - .name = "IEC958 Preample Capture Default", + .name = "IEC958 Preamble Capture Default", .access = SNDRV_CTL_ELEM_ACCESS_READ | SNDRV_CTL_ELEM_ACCESS_VOLATILE, .info = snd_ak4113_spdif_pinfo, diff --git a/sound/i2c/other/ak4114.c b/sound/i2c/other/ak4114.c index 816e7d2..5bf4fca 100644 --- a/sound/i2c/other/ak4114.c +++ b/sound/i2c/other/ak4114.c @@ -401,7 +401,7 @@ static struct snd_kcontrol_new snd_ak4114_iec958_controls[] = { }, { .iface = SNDRV_CTL_ELEM_IFACE_PCM, - .name = "IEC958 Preample Capture Default", + .name = "IEC958 Preamble Capture Default", .access = SNDRV_CTL_ELEM_ACCESS_READ | SNDRV_CTL_ELEM_ACCESS_VOLATILE, .info = snd_ak4114_spdif_pinfo, .get = snd_ak4114_spdif_pget, diff --git a/sound/i2c/other/ak4117.c b/sound/i2c/other/ak4117.c index b4b2a51..40e33c9 100644 --- a/sound/i2c/other/ak4117.c +++ b/sound/i2c/other/ak4117.c @@ -380,7 +380,7 @@ static struct snd_kcontrol_new snd_ak4117_iec958_controls[] = { }, { .iface = SNDRV_CTL_ELEM_IFACE_PCM, - .name = "IEC958 Preample Capture Default", + .name = "IEC958 Preamble Capture Default", .access = SNDRV_CTL_ELEM_ACCESS_READ | SNDRV_CTL_ELEM_ACCESS_VOLATILE, .info = snd_ak4117_spdif_pinfo, .get = snd_ak4117_spdif_pget, diff --git a/sound/pci/rme9652/hdspm.c b/sound/pci/rme9652/hdspm.c index f1cd1e3..9a8d5ce 100644 --- a/sound/pci/rme9652/hdspm.c +++ b/sound/pci/rme9652/hdspm.c @@ -4899,7 +4899,7 @@ snd_hdspm_proc_read_madi(struct snd_info_entry * entry, insel = "Coaxial"; break; default: - insel = "Unkown"; + insel = "Unknown"; } snd_iprintf(buffer, diff --git a/sound/soc/codecs/cs42l52.c b/sound/soc/codecs/cs42l52.c index 6159929..4d8db36 100644 --- a/sound/soc/codecs/cs42l52.c +++ b/sound/soc/codecs/cs42l52.c @@ -763,7 +763,7 @@ static int cs42l52_set_sysclk(struct snd_soc_dai *codec_dai, if ((freq >= CS42L52_MIN_CLK) && (freq <= CS42L52_MAX_CLK)) { cs42l52->sysclk = freq; } else { - dev_err(codec->dev, "Invalid freq paramter\n"); + dev_err(codec->dev, "Invalid freq parameter\n"); return -EINVAL; } return 0; diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index 11982bf..88dbabc 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -3734,7 +3734,7 @@ static irqreturn_t wm8958_mic_irq(int irq, void *data) } while (count--); if (count == 0) - dev_warn(codec->dev, "No impedence range reported for jack\n"); + dev_warn(codec->dev, "No impedance range reported for jack\n"); #ifndef CONFIG_SND_SOC_WM8994_MODULE trace_snd_soc_jack_irq(dev_name(codec->dev)); -- 1.8.0.rc3.16.g8ead1bf

2 1

[alsa-devel] [PATCH] stop setup_dig_out_stream() causing clicks
by Laurence Darby 04 Nov '12

04 Nov '12

Starting audio or seeking in various music players causes setup_dig_out_stream() to be called, which resets the SPDIF stream, which caused one DAC (but not another) to make a clicking noise every time. This patch turns off codec->spdif_status_reset after one reset which stops further clicks. One reset is still necessary to initialise the codec properly. Signed-off-by: Laurence Darby <ldarby(a)tuffmail.com> --- 2nd attempt at this, I hope I'm not doing anything wrong this time. sound/pci/hda/hda_codec.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index 1c65cc5..7742a77 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -4731,9 +4731,11 @@ static void setup_dig_out_stream(struct hda_codec *codec, hda_nid_t nid, format); } /* turn on again (if needed) */ - if (codec->spdif_status_reset && (spdif->ctls & AC_DIG1_ENABLE)) + if (codec->spdif_status_reset && (spdif->ctls & AC_DIG1_ENABLE)) { set_dig_out_convert(codec, nid, spdif->ctls & 0xff, -1); + codec->spdif_status_reset = 0; + } } static void cleanup_dig_out_stream(struct hda_codec *codec, hda_nid_t nid) -- 1.7.12

2 5

[alsa-devel] spdif input - square resample confusion, alc886
by Rafal Powierski 03 Nov '12

03 Nov '12

Developers! SPDIF INPUT, (High Definition Audio Specification: 5.4.3 Source Synchronous Input) Writing application. hardware: ALC886 codec and AMD FUSION in my special device. How can I detect spdif stream source sample ratio? I tried not to set the ratio at init – this gives 44.1 If I set 48k it seams to work. if I set different, alsa+codec is somehow following my request and rectangular-“resampling” input to given setting. That is I am getting 2x the same value when I set 96000Hz I am afraid of repeatedly loosing samples or getting it twice (e.g. in case of jitter or the stream from alsa is not really the source synchronous ). How can I got real 1:1 sample ratio? if no solution: can I use much higher sample ratio and use software PLL based on equal consequent samples? is that behavior of repeating samples consistent? – i.e. is that planed or bug? RAW data (e.g. AC3): SND_PCM_FORMAT_IEC958_SUBFRAME_LE is not available but 32 bit format brings all 32 bits set to some non constant value. Is this maybe the raw format? Regards, Rafal

1 0

Re: [alsa-devel] Constant noise on HDA ALC275
by Takashi Iwai 03 Nov '12

03 Nov '12

At Mon, 08 Oct 2012 14:46:24 +0200, Julien Danjou wrote: > > [1 <multipart/mixed (7bit)>] > [1.1 <text/plain (quoted-printable)>] > On Mon, Oct 08 2012, Takashi Iwai wrote: > > > At best, please give alsa-info.sh outputs at both working and > > non-working cases. In that way, we can see the internal states more > > exactly than ambiguous descriptions. > > Sure! Both attached. > > The diff between background-noise and no-background-noise is: > > --- /tmp/alsa-info-background-noise.txt 2012-10-08 14:41:05.880816525 +0200 > +++ /tmp/alsa-info-no-background-noise.txt 2012-10-08 14:42:24.700814459 +0200 > @@ -3,7 +3,7 @@ > !!ALSA Information Script v 0.4.61 > !!################################ > > -!!Script ran on: Mon Oct 8 12:41:05 UTC 2012 > +!!Script ran on: Mon Oct 8 12:42:24 UTC 2012 > > > !!Linux Distribution > @@ -198,7 +198,7 @@ > Control: name="Beep Playback Switch", index=0, device=0 > ControlAmp: chs=3, dir=In, idx=4, ofs=0 > Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 > - Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] > + Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x00 0x00] > Connection: 5 > 0x18 0x19 0x1a 0x1b 0x1d It's interesting. So, _unmuting_ the input from NID 0x1d removes the noise? (0x80 means the channel is muted.) Takashi

3 21

[alsa-devel] M-Audio FastTrack C400
by Raphael Souza 02 Nov '12

02 Nov '12

Hello, first of all, i want to thank you for the attention. It's necessary good support recording with Ubuntu, and you do so well. So, i have the M-Audio Fast Track C400 and i have installed on my computer Ubuntu 12.04 LTS (Precise Pangolin). My system recognized the soundcard, run JACK with it, but i can't record or hear any sound from there. Which procedure i have to do? Thank you again. Best regards. Raphael Fonseca Sing-songwriter and Producer from Manaus, Brazil.

1 0

[alsa-devel] UCM/DAPM - saving power when idle?
by David Henningsson 02 Nov '12

02 Nov '12

I don't deal much with ASoC, so sorry if I'm missing something obvious here... When a certain use case is activated, that would then activate some DAPM widgets, causing the codec to consume more power. So, we should essentially avoid this unless we're actually playing back/recording. But, why isn't there a "disable all use cases" command, or possibly an "idle" command? (That, essentially, e g pulseaudio should set whenever playback/recording stops) Or; the option would be that the codec is actually powered down, but only activates itself when there is a stream; but this looks like it could cause problem with loopback paths (e g listening to FM radio, where there are no streams passing through CPU/main memory). -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic

3 2

[alsa-devel] [PATCH 2/3] ARM: OMAP: Remove NEED_MACH_GPIO_H
by Tony Lindgren 02 Nov '12

02 Nov '12

Omap no longer needs this option, mach/gpio.h is empty. Also remove mach/irqs.h from gpio-omap.h and include it directly from the related omap1 gpio init files. Otherwise omap2+ build fails for MULTI_PLATFORM. Cc: Peter Ujfalusi <peter.ujfalusi(a)ti.com> Cc: Jarkko Nikula <jarkko.nikula(a)bitmer.com> Cc: Liam Girdwood <lrg(a)ti.com> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Cc: alsa-devel(a)alsa-project.org Signed-off-by: Tony Lindgren <tony(a)atomide.com> --- arch/arm/Kconfig | 1 - arch/arm/mach-omap1/gpio15xx.c | 2 ++ arch/arm/mach-omap1/gpio16xx.c | 2 ++ arch/arm/mach-omap1/gpio7xx.c | 2 ++ arch/arm/mach-omap1/include/mach/gpio.h | 3 --- arch/arm/mach-omap2/include/mach/gpio.h | 3 --- include/linux/platform_data/gpio-omap.h | 1 - sound/soc/omap/am3517evm.c | 2 -- sound/soc/omap/n810.c | 1 - sound/soc/omap/osk5912.c | 1 - sound/soc/omap/sdp3430.c | 2 -- sound/soc/omap/zoom2.c | 3 --- 12 files changed, 6 insertions(+), 17 deletions(-) delete mode 100644 arch/arm/mach-omap1/include/mach/gpio.h delete mode 100644 arch/arm/mach-omap2/include/mach/gpio.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 73067ef..6207cf7 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -937,7 +937,6 @@ config ARCH_OMAP select CLKSRC_MMIO select GENERIC_CLOCKEVENTS select HAVE_CLK - select NEED_MACH_GPIO_H help Support for TI's OMAP platform (OMAP1/2/3/4). diff --git a/arch/arm/mach-omap1/gpio15xx.c b/arch/arm/mach-omap1/gpio15xx.c index 98e6f39..02b3eb2 100644 --- a/arch/arm/mach-omap1/gpio15xx.c +++ b/arch/arm/mach-omap1/gpio15xx.c @@ -19,6 +19,8 @@ #include <linux/gpio.h> #include <linux/platform_data/gpio-omap.h> +#include <mach/irqs.h> + #define OMAP1_MPUIO_VBASE OMAP1_MPUIO_BASE #define OMAP1510_GPIO_BASE 0xFFFCE000 diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c index 33f4192..b9952a2 100644 --- a/arch/arm/mach-omap1/gpio16xx.c +++ b/arch/arm/mach-omap1/gpio16xx.c @@ -19,6 +19,8 @@ #include <linux/gpio.h> #include <linux/platform_data/gpio-omap.h> +#include <mach/irqs.h> + #define OMAP1610_GPIO1_BASE 0xfffbe400 #define OMAP1610_GPIO2_BASE 0xfffbec00 #define OMAP1610_GPIO3_BASE 0xfffbb400 diff --git a/arch/arm/mach-omap1/gpio7xx.c b/arch/arm/mach-omap1/gpio7xx.c index 958ce9a..f5819b2 100644 --- a/arch/arm/mach-omap1/gpio7xx.c +++ b/arch/arm/mach-omap1/gpio7xx.c @@ -19,6 +19,8 @@ #include <linux/gpio.h> #include <linux/platform_data/gpio-omap.h> +#include <mach/irqs.h> + #define OMAP7XX_GPIO1_BASE 0xfffbc000 #define OMAP7XX_GPIO2_BASE 0xfffbc800 #define OMAP7XX_GPIO3_BASE 0xfffbd000 diff --git a/arch/arm/mach-omap1/include/mach/gpio.h b/arch/arm/mach-omap1/include/mach/gpio.h deleted file mode 100644 index ebf86c0..0000000 --- a/arch/arm/mach-omap1/include/mach/gpio.h +++ /dev/null @@ -1,3 +0,0 @@ -/* - * arch/arm/mach-omap1/include/mach/gpio.h - */ diff --git a/arch/arm/mach-omap2/include/mach/gpio.h b/arch/arm/mach-omap2/include/mach/gpio.h deleted file mode 100644 index 5621cc5..0000000 --- a/arch/arm/mach-omap2/include/mach/gpio.h +++ /dev/null @@ -1,3 +0,0 @@ -/* - * arch/arm/mach-omap2/include/mach/gpio.h - */ diff --git a/include/linux/platform_data/gpio-omap.h b/include/linux/platform_data/gpio-omap.h index e8741c2..5d50b25 100644 --- a/include/linux/platform_data/gpio-omap.h +++ b/include/linux/platform_data/gpio-omap.h @@ -26,7 +26,6 @@ #include <linux/io.h> #include <linux/platform_device.h> -#include <mach/irqs.h> #define OMAP1_MPUIO_BASE 0xfffb5000 diff --git a/sound/soc/omap/am3517evm.c b/sound/soc/omap/am3517evm.c index fad3506..c1900b2 100644 --- a/sound/soc/omap/am3517evm.c +++ b/sound/soc/omap/am3517evm.c @@ -25,8 +25,6 @@ #include <sound/soc.h> #include <asm/mach-types.h> -#include <mach/hardware.h> -#include <mach/gpio.h> #include <linux/platform_data/asoc-ti-mcbsp.h> #include "omap-mcbsp.h" diff --git a/sound/soc/omap/n810.c b/sound/soc/omap/n810.c index 521bfc3..230b8c1 100644 --- a/sound/soc/omap/n810.c +++ b/sound/soc/omap/n810.c @@ -29,7 +29,6 @@ #include <sound/soc.h> #include <asm/mach-types.h> -#include <mach/hardware.h> #include <linux/gpio.h> #include <linux/module.h> #include <linux/platform_data/asoc-ti-mcbsp.h> diff --git a/sound/soc/omap/osk5912.c b/sound/soc/omap/osk5912.c index 3960e8d..06ef8d6 100644 --- a/sound/soc/omap/osk5912.c +++ b/sound/soc/omap/osk5912.c @@ -28,7 +28,6 @@ #include <sound/soc.h> #include <asm/mach-types.h> -#include <mach/hardware.h> #include <linux/gpio.h> #include <linux/module.h> #include <linux/platform_data/asoc-ti-mcbsp.h> diff --git a/sound/soc/omap/sdp3430.c b/sound/soc/omap/sdp3430.c index 597cae7..b462a2c 100644 --- a/sound/soc/omap/sdp3430.c +++ b/sound/soc/omap/sdp3430.c @@ -31,8 +31,6 @@ #include <sound/jack.h> #include <asm/mach-types.h> -#include <mach/hardware.h> -#include <mach/gpio.h> #include <linux/platform_data/gpio-omap.h> #include <linux/platform_data/asoc-ti-mcbsp.h> diff --git a/sound/soc/omap/zoom2.c b/sound/soc/omap/zoom2.c index 677b567..27c501c 100644 --- a/sound/soc/omap/zoom2.c +++ b/sound/soc/omap/zoom2.c @@ -26,9 +26,6 @@ #include <sound/soc.h> #include <asm/mach-types.h> -#include <mach/hardware.h> -#include <mach/gpio.h> -#include <mach/board-zoom.h> #include <linux/platform_data/asoc-ti-mcbsp.h> /* Register descriptions for twl4030 codec part */

2 1

[alsa-devel] [PATCH 1/2] ASoC: bells: Add hookup of WM0010 on Bells
by Dimitris Papastamos 02 Nov '12

02 Nov '12

The Bells platform by default has a WM0010 fitted. Now that we have a public driver hook it up in the machine integration. Signed-off-by: Dimitris Papastamos <dp(a)opensource.wolfsonmicro.com> --- sound/soc/samsung/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig index e7b8317..fa166bd 100644 --- a/sound/soc/samsung/Kconfig +++ b/sound/soc/samsung/Kconfig @@ -207,6 +207,7 @@ config SND_SOC_BELLS select SND_SOC_WM5102 select SND_SOC_WM5110 select SND_SOC_WM9081 + select SND_SOC_WM0010 config SND_SOC_LOWLAND tristate "Audio support for Wolfson Lowland" -- 1.8.0

2 2

[alsa-devel] [PATCH] ASoC: bells: Up clock rate to 48kHz and 512fs
by Dimitris Papastamos 02 Nov '12

02 Nov '12

The current WM0010 firmware images expect a 48kHz * 512fs clkin. Signed-off-by: Dimitris Papastamos <dp(a)opensource.wolfsonmicro.com> --- sound/soc/samsung/bells.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/samsung/bells.c b/sound/soc/samsung/bells.c index 3d7ace7..c8ac240 100644 --- a/sound/soc/samsung/bells.c +++ b/sound/soc/samsung/bells.c @@ -27,8 +27,8 @@ */ #define MCLK_RATE 24576000 -#define SYS_AUDIO_RATE 44100 -#define SYS_MCLK_RATE (SYS_AUDIO_RATE * 256) +#define SYS_AUDIO_RATE 48000 +#define SYS_MCLK_RATE (SYS_AUDIO_RATE * 512) #define DAI_AP_DSP 0 #define DAI_DSP_CODEC 1 -- 1.8.0

2 1

[alsa-devel] [PATCH 1/2] ASoC: bells: Add hookup of WM0010 on Bells
by Dimitris Papastamos 02 Nov '12

02 Nov '12

The Bells platform by default has a WM0010 fitted. Now that we have a public driver hook it up in the machine integration. Change-Id: Ia585d5462c5d97e83bc5cc3e18abab1af8287d88 Signed-off-by: Dimitris Papastamos <dp(a)opensource.wolfsonmicro.com> --- sound/soc/samsung/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/samsung/Kconfig b/sound/soc/samsung/Kconfig index e7b8317..fa166bd 100644 --- a/sound/soc/samsung/Kconfig +++ b/sound/soc/samsung/Kconfig @@ -207,6 +207,7 @@ config SND_SOC_BELLS select SND_SOC_WM5102 select SND_SOC_WM5110 select SND_SOC_WM9081 + select SND_SOC_WM0010 config SND_SOC_LOWLAND tristate "Audio support for Wolfson Lowland" -- 1.8.0

2 2

[alsa-devel] Issue when upgrading from 1.0.22 to 1.0.25
by Nick Harezga 02 Nov '12

02 Nov '12

I initially tried to send this yesterday from my work e-mail, but I think they may be blocking the list for some reason. Apologies if this question shows up twice. I am attempting to upgrade from Ubuntu version 10.04 to version 12.04. Version 10.04 has ALSA version 1.0.22 and version 12.04 has ALSA 1.0.25. I have a simple test application that captures microphone input and then plays the audio through the speaker. When run with ALSA 1.0.22 the program works as expected. When I run the program with ALSA 1.0.25, I get a bad pipe error indicating buffer underrun when calling writes. Both systems have the same hardware (Dell Latitude E6400 laptop). I tried looking through the change logs to determine if there were any obvious changes that stood out to me, but couldn't find anything. I have attached my code. Any suggestions? Program is compiled using "g++ audio_test.cpp -o audio_test -lasound" Audio sample rate: 8000 Buffer size: 1800 Format: Signed 16bit LE, interleaved

1 0

[alsa-devel] [PATCH] ASoC: bells: Up clock rate to 48kHz and 512fs
by Dimitris Papastamos 02 Nov '12

02 Nov '12

The current WM0010 firmware images expect a 48kHz * 512fs clkin. Change-Id: I46f3f030175ebcbe9be75d01482379021510f459 Signed-off-by: Dimitris Papastamos <dp(a)opensource.wolfsonmicro.com> --- sound/soc/samsung/bells.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/samsung/bells.c b/sound/soc/samsung/bells.c index 3d7ace7..c8ac240 100644 --- a/sound/soc/samsung/bells.c +++ b/sound/soc/samsung/bells.c @@ -27,8 +27,8 @@ */ #define MCLK_RATE 24576000 -#define SYS_AUDIO_RATE 44100 -#define SYS_MCLK_RATE (SYS_AUDIO_RATE * 256) +#define SYS_AUDIO_RATE 48000 +#define SYS_MCLK_RATE (SYS_AUDIO_RATE * 512) #define DAI_AP_DSP 0 #define DAI_DSP_CODEC 1 -- 1.8.0

1 0

[alsa-devel] hda: Cirrus: fixes for CS4207 coef setup
by Alexander Stein 02 Nov '12

02 Nov '12

Hi, I'm noticing some problems using the CS4207 codec with out custom board. Output works fine so far, but I noticed that input on ADC1 (blue) is just mono and input on ADC2 (pink) is reversed stereo. Both tests were done by playing a wav on an output and directly feeding the input. After some investigations, I found out, that coef in the patch_cirrus driver don't match the CS4207 datasheet (CS4207-F4). As the driver also mentions CS4206 I'm aware that my pathces might not be suitable in general, but I couldn't find any datasheet for CS4206 so I can't compare the coef settings. Summarized here: * The beep bits were written to the wrong index (See CS4207-F4 6.15.6.5 BeepConfiguration(CIR=0004h)) * The DMIC enable signals were written to the wrong index (Same chapter as above) As the drivers sets 2 DMIC bits each, while CS4207 has only 1 for each, the coef interface might be different on both codec. Maybe someone with more detailed knowledge about the CS4206 can put his comments. Best regards, Alexander

2 3

[alsa-devel] limitations on number of alsa controls for a card
by Vinod Koul 02 Nov '12

02 Nov '12

Hi, Is there any limitation on maximum number of controls we can have. I had some platform side controls to represent DSP and adding them made some of codec controls to vanish. And looks like if I register these platform controls not all codec controls are visible in userpsace. Is there nay max limit I am hitting? -- ~Vinod

5 5

[alsa-devel] Transmitting ac3 content via spdif
by Fabio Estevam 02 Nov '12

02 Nov '12

Hi, I am trying to transmit ac3 content via spdif on a mx6 (on a yet non-mainlined driver). Tried to force non-audio mode via iecset: # iecset audio 0 control "IEC958 Playback Default" (index -1) not found root@imx6qsabrelite:~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: sgtl5000audio [sgtl5000-audio], device 0: HiFi sgtl5000-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: imxhdmisoc [imx-hdmi-soc], device 0: IMX HDMI TX mxc-hdmi-soc-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 Transmitting a wav file works fine though. Any suggestions as to how provide the "IEC958 Playback Default" control? Thanks, Fabio Estevam

1 2

[alsa-devel] [PATCH RFT] ASoC: si476x: Add missing break for SNDRV_PCM_FORMAT_S8 switch case
by Axel Lin 01 Nov '12

01 Nov '12

Signed-off-by: Axel Lin <axel.lin(a)ingics.com> --- sound/soc/codecs/si476x.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/codecs/si476x.c b/sound/soc/codecs/si476x.c index 38145ba..dadf04d 100644 --- a/sound/soc/codecs/si476x.c +++ b/sound/soc/codecs/si476x.c @@ -159,6 +159,7 @@ static int si476x_codec_hw_params(struct snd_pcm_substream *substream, switch (params_format(params)) { case SNDRV_PCM_FORMAT_S8: width = SI476X_PCM_FORMAT_S8; + break; case SNDRV_PCM_FORMAT_S16_LE: width = SI476X_PCM_FORMAT_S16_LE; break; -- 1.7.9.5

2 1

[alsa-devel] [PATCH] ASoC: mxs-saif: Fix channel swap for 24-bit format
by Fabio Estevam 01 Nov '12

01 Nov '12

From: Fabio Estevam <fabio.estevam(a)freescale.com> Playing 24-bit format file leads to channel swap on mx28 and the reason is that the current driver performs one write/read to/from the SAIF_DATA register to trigger the transfer. This approach works fine for S16_LE case because SAIF_DATA is a 32-bit register and thus is capable of storing the 16-bit left and right channels, but for the S24_LE case it can only store one channel, so in order to not lose the FIFO sync an extra read/write is needed. Reported-by: Dan Winner <DWinner(a)tc-helicon.com> Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> Tested-by: Dan Winner <DWinner(a)tc-helicon.com> --- sound/soc/mxs/mxs-saif.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/sound/soc/mxs/mxs-saif.c b/sound/soc/mxs/mxs-saif.c index aa037b2..05a875c 100644 --- a/sound/soc/mxs/mxs-saif.c +++ b/sound/soc/mxs/mxs-saif.c @@ -523,16 +523,22 @@ static int mxs_saif_trigger(struct snd_pcm_substream *substream, int cmd, if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { /* - * write a data to saif data register to trigger - * the transfer + * write data to saif data register to trigger + * the transfer. + * For 24-bit format the 32-bit FIFO register stores + * only one channel, so we need to write twice. */ __raw_writel(0, saif->base + SAIF_DATA); + __raw_writel(0, saif->base + SAIF_DATA); } else { /* - * read a data from saif data register to trigger - * the receive + * read data from saif data register to trigger + * the receive. + * For 24-bit format the 32-bit FIFO register stores + * only one channel, so we need to read twice. */ __raw_readl(saif->base + SAIF_DATA); + __raw_readl(saif->base + SAIF_DATA); } master_saif->ongoing = 1; -- 1.7.9.5

3 3

[alsa-devel] [PATCH] ASoC: atmel_ssc_dai: make module reloadable
by Alexandre Belloni 01 Nov '12

01 Nov '12

As the platform_devices were never unregistered, it was not possible to unload/reload the module. Signed-off-by: Alexandre Belloni <alexandre.belloni(a)piout.net> --- sound/soc/atmel/atmel_ssc_dai.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c index 354341e..07ee57b 100644 --- a/sound/soc/atmel/atmel_ssc_dai.c +++ b/sound/soc/atmel/atmel_ssc_dai.c @@ -155,6 +155,8 @@ static struct atmel_ssc_info ssc_info[NUM_SSC_DEVICES] = { #endif }; +static struct platform_device *dma_pdev; +static struct platform_device *ssc_pdevs[NUM_SSC_DEVICES]; /* * SSC interrupt handler. Passes PDC interrupts to the DMA @@ -796,6 +798,12 @@ static __devinit int asoc_ssc_probe(struct platform_device *pdev) static int __devexit asoc_ssc_remove(struct platform_device *pdev) { + int i; + platform_device_unregister(dma_pdev); + + for(i = 0; i < NUM_SSC_DEVICES; i++) + platform_device_unregister(ssc_pdevs[i]); + snd_soc_unregister_dai(&pdev->dev); return 0; } @@ -816,7 +824,6 @@ static struct platform_driver asoc_ssc_driver = { int atmel_ssc_set_audio(int ssc_id) { struct ssc_device *ssc; - static struct platform_device *dma_pdev; struct platform_device *ssc_pdev; int ret; @@ -855,6 +862,8 @@ int atmel_ssc_set_audio(int ssc_id) if (ret < 0) platform_device_put(ssc_pdev); + ssc_pdevs[ssc_id] = ssc_pdev; + return ret; } EXPORT_SYMBOL_GPL(atmel_ssc_set_audio); -- 1.7.9.5

1 0

[alsa-devel] Issue when upgrading from 1.0.22 to 1.0.25
by Nick Harezga 01 Nov '12

01 Nov '12

I am attempting to upgrade from Ubuntu version 10.04 to version 12.04. Version 10.04 has ALSA version 1.0.22 and version 12.04 has ALSA 1.0.25. I have a simple test application that captures microphone input and then plays the audio through the speaker. When run with ALSA 1.0.22 the program works as expected. When I run the program with ALSA 1.0.25, I get a bad pipe error indicating buffer underrun when calling writes. Both systems have the same hardware (Dell Latitude E6400 laptop). I tried looking through the change logs to determine if there were any obvious changes that stood out to me, but couldn't find anything. I have attached my code. Any suggestions? Program is compiled using "g++ audio_test.cpp -o audio_test -lasound" Audio sample rate: 8000 Buffer size: 1800 Format: Signed 16bit LE, interleaved

1 0

[alsa-devel] [PATCH v3 1/2] ASoC: mxs-saif: Remove platform data
by Fabio Estevam 01 Nov '12

01 Nov '12

From: Fabio Estevam <fabio.estevam(a)freescale.com> All MXS users have been converted to device tree and the board files have been removed. No need to keep platform data in the driver. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- Changes since v2: - Also remove 'if (np)' as dt is the only probing mechanism. Changes since v1: - Also remove mxs_saif_platform_data and sound/saif.h, which was used only to include mxs_saif_platform_data definition. include/sound/saif.h | 16 ---------------- sound/soc/mxs/mxs-saif.c | 42 +++++++++++++++--------------------------- 2 files changed, 15 insertions(+), 43 deletions(-) delete mode 100644 include/sound/saif.h diff --git a/include/sound/saif.h b/include/sound/saif.h deleted file mode 100644 index f22f3e1..0000000 diff --git a/sound/soc/mxs/mxs-saif.c b/sound/soc/mxs/mxs-saif.c index aa037b2..ab5bdec 100644 --- a/sound/soc/mxs/mxs-saif.c +++ b/sound/soc/mxs/mxs-saif.c @@ -32,7 +32,6 @@ #include <sound/pcm.h> #include <sound/pcm_params.h> #include <sound/soc.h> -#include <sound/saif.h> #include <asm/mach-types.h> #include <mach/hardware.h> #include <mach/mxs.h> @@ -652,10 +651,9 @@ static int __devinit mxs_saif_probe(struct platform_device *pdev) struct device_node *np = pdev->dev.of_node; struct resource *iores, *dmares; struct mxs_saif *saif; - struct mxs_saif_platform_data *pdata; struct pinctrl *pinctrl; int ret = 0; - + struct device_node *master; if (!np && pdev->id >= ARRAY_SIZE(mxs_saif)) return -EINVAL; @@ -664,31 +662,21 @@ static int __devinit mxs_saif_probe(struct platform_device *pdev) if (!saif) return -ENOMEM; - if (np) { - struct device_node *master; - saif->id = of_alias_get_id(np, "saif"); - if (saif->id < 0) - return saif->id; - /* - * If there is no "fsl,saif-master" phandle, it's a saif - * master. Otherwise, it's a slave and its phandle points - * to the master. - */ - master = of_parse_phandle(np, "fsl,saif-master", 0); - if (!master) { - saif->master_id = saif->id; - } else { - saif->master_id = of_alias_get_id(master, "saif"); - if (saif->master_id < 0) - return saif->master_id; - } + saif->id = of_alias_get_id(np, "saif"); + if (saif->id < 0) + return saif->id; + /* + * If there is no "fsl,saif-master" phandle, it's a saif + * master. Otherwise, it's a slave and its phandle points + * to the master. + */ + master = of_parse_phandle(np, "fsl,saif-master", 0); + if (!master) { + saif->master_id = saif->id; } else { - saif->id = pdev->id; - pdata = pdev->dev.platform_data; - if (pdata && !pdata->master_mode) - saif->master_id = pdata->master_id; - else - saif->master_id = saif->id; + saif->master_id = of_alias_get_id(master, "saif"); + if (saif->master_id < 0) + return saif->master_id; } if (saif->master_id < 0 || saif->master_id >= ARRAY_SIZE(mxs_saif)) { -- 1.7.9.5

4 4

[alsa-devel] macmini5,3 and imac27 ssid conflict
by Raymond Yau 01 Nov '12

01 Nov '12

>>> http://www.alsa-project.org/db/?f=5e7f45089ce82985c003fa2608bed82726ebbdf6 > > how many audio jacks do your macmini have ? > > > > seem only line in support jack detect, internal mic support balanced but > > ext mic does not support jack detect > > There are two audio jacks: > > 1. An analogue headset/external speakers jack. Note that in order for the external speakers to work, I need to use HDA Analyser to change the settings otherwise things remain stuck on the internal speaker. I did not try an analogue headset. https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/892697 > > 2. An analogue line-in jack. I tried this with a powered condenser microphone - I can hear a recording, but the level is too low for practical use. > > I'm not sure there is an internal microphone connected - shouting at the mac mini box does not produce an audible recording :P http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commitdiff;h=6d… Advanced information - PCI Vendor/Device/Subsystem ID's !!------------------------------------------------------- 00:1b.0 0403: 8086:1c20 (rev 05) Subsystem: 8086:7270 your macmini pci subsystem is also 8086:7270 which is same as imac27 the pin default of your macmini (init_pin_config) is replaced by the pin config of model imac27 (driver_pin_config) Codec: Cirrus Logic CS4206 Address: 0 AFG Function Id: 0x1 (unsol 0) Vendor Id: 0x10134206 Subsystem Id: 0x106b2100 is the subsystem id in codec unique ? Sysfs Files !!----------- /sys/class/sound/hwC0D0/init_pin_configs: 0x09 0x400000f0 0x0a 0x002b4040 0x0b 0x90100130 0x0c 0x018b3020 0x0d 0x90a00110 0x0e 0x400000f0 0x0f 0x01cbe030 0x10 0x014be060 0x12 0x01ab9070 0x15 0x400000f0 /sys/class/sound/hwC0D0/driver_pin_configs: 0x09 0x012b4050 0x0a 0x90100140 0x0b 0x90100142 0x0c 0x018b3020 0x0d 0x90a00110 0x0e 0x400000f0 0x0f 0x01cbe030 0x10 0x014be060 0x12 0x01ab9070 0x15 0x400000f0 /sys/class/sound/hwC0D0/user_pin_configs: /sys/class/sound/hwC0D0/init_verbs:

3 2

[alsa-devel] [PATCH] ASoC: mxs-pcm: Fix fifo size
by Fabio Estevam 31 Oct '12

31 Oct '12

From: Fabio Estevam <fabio.estevam(a)freescale.com> According to MX28 Reference Manual the SAIF FIFO contains 4-bytes. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- sound/soc/mxs/mxs-pcm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/mxs/mxs-pcm.c b/sound/soc/mxs/mxs-pcm.c index f82d766..6b360d0 100644 --- a/sound/soc/mxs/mxs-pcm.c +++ b/sound/soc/mxs/mxs-pcm.c @@ -60,7 +60,7 @@ static struct snd_pcm_hardware snd_mxs_hardware = { .periods_min = 1, .periods_max = 52, .buffer_bytes_max = 64 * 1024, - .fifo_size = 32, + .fifo_size = 4, }; -- 1.7.9.5

1 0

[alsa-devel] ALSA hda/patch_via -- Error in via_auto_fill_dac_nids
by Massimo Del Fedele 31 Oct '12

31 Oct '12

The function should scan all paths from DACs to OUTS, but like it is just takes the first available DAC. The problem arises here : if (dac) { spec->private_dac_nids[i] = dac; dac_num++; } Which correctly adds DAC to used list, but doesn't update the total number of found DACs in spec->multiout.num_dacs; following calls to is_empty_dac() will always return true for already used DACs, making parse_output_path() return always the first one. Corrected function should be like this : static int via_auto_fill_dac_nids(struct hda_codec *codec) { struct via_spec *spec = codec->spec; const struct auto_pin_cfg *cfg = &spec->autocfg; int i; hda_nid_t nid; spec->multiout.dac_nids = spec->private_dac_nids; spec->multiout.num_dacs = 0; for (i = 0; i < cfg->line_outs; i++) { hda_nid_t dac = 0; nid = cfg->line_out_pins[i]; if (!nid) continue; if (parse_output_path(codec, nid, 0, 0, &spec->out_path[i])) dac = spec->out_path[i].path[0]; if (!i && parse_output_path(codec, nid, dac, 1, &spec->out_mix_path)) dac = spec->out_mix_path.path[0]; if (dac) { spec->private_dac_nids[i] = dac; spec->multiout.num_dacs++; } } if (!spec->out_path[0].depth && spec->out_mix_path.depth) { spec->out_path[0] = spec->out_mix_path; spec->out_mix_path.depth = 0; } return 0; } This one (and a few other changes) allows the subwoofer of asus g75 work correctly. Sorry for not submitting a patch, I'm quite new to alsa; please tell me if/how I should do it. Ciao Max

1 0

[alsa-devel] [PATCH v2 1/2] ASoC: mxs-saif: Remove platform data
by Fabio Estevam 31 Oct '12

31 Oct '12

From: Fabio Estevam <fabio.estevam(a)freescale.com> All MXS users have been converted to device tree and the board files have been removed. No need to keep platform data in the driver. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- Changes since v1: - Also remove mxs_saif_platform_data and sound/saif.h, which was used only to include mxs_saif_platform_data definition. include/sound/saif.h | 16 ---------------- sound/soc/mxs/mxs-saif.c | 9 --------- 2 files changed, 25 deletions(-) delete mode 100644 include/sound/saif.h diff --git a/include/sound/saif.h b/include/sound/saif.h deleted file mode 100644 index f22f3e1..0000000 diff --git a/sound/soc/mxs/mxs-saif.c b/sound/soc/mxs/mxs-saif.c index aa037b2..76a9c4a 100644 --- a/sound/soc/mxs/mxs-saif.c +++ b/sound/soc/mxs/mxs-saif.c @@ -32,7 +32,6 @@ #include <sound/pcm.h> #include <sound/pcm_params.h> #include <sound/soc.h> -#include <sound/saif.h> #include <asm/mach-types.h> #include <mach/hardware.h> #include <mach/mxs.h> @@ -652,7 +651,6 @@ static int __devinit mxs_saif_probe(struct platform_device *pdev) struct device_node *np = pdev->dev.of_node; struct resource *iores, *dmares; struct mxs_saif *saif; - struct mxs_saif_platform_data *pdata; struct pinctrl *pinctrl; int ret = 0; @@ -682,13 +680,6 @@ static int __devinit mxs_saif_probe(struct platform_device *pdev) if (saif->master_id < 0) return saif->master_id; } - } else { - saif->id = pdev->id; - pdata = pdev->dev.platform_data; - if (pdata && !pdata->master_mode) - saif->master_id = pdata->master_id; - else - saif->master_id = saif->id; } if (saif->master_id < 0 || saif->master_id >= ARRAY_SIZE(mxs_saif)) { -- 1.7.9.5

2 1

[alsa-devel] Query about alsa ucm (use case manager) config files
by Ashish Chavan 31 Oct '12

31 Oct '12

Hi, I am just curious to know if there is any centralized repository for alsa use case manager configuration files. I tried searching and could only find alsa-ucm-conf.git repo at alsa project git server, which is actually an empty repo! How people share/reuse ucm configuration files for a specific codec? In near future, I will be developing few ucm configuration files for some codecs and wish to share them with rest of the world. I think even though ucm configs are board/machine specific, it makes sense to share them. Is there any other, more visible place to put these config files than board specific distributions?

2 1

[alsa-devel] [PATCH 1/2] ASoC: mxs-saif: Remove platform data
by Fabio Estevam 31 Oct '12

31 Oct '12

From: Fabio Estevam <fabio.estevam(a)freescale.com> All MXS users have been converted to device tree and the board files have been removed. No need to keep platform data in the driver. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- sound/soc/mxs/mxs-saif.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/sound/soc/mxs/mxs-saif.c b/sound/soc/mxs/mxs-saif.c index aa037b2..7c3154d 100644 --- a/sound/soc/mxs/mxs-saif.c +++ b/sound/soc/mxs/mxs-saif.c @@ -652,7 +652,6 @@ static int __devinit mxs_saif_probe(struct platform_device *pdev) struct device_node *np = pdev->dev.of_node; struct resource *iores, *dmares; struct mxs_saif *saif; - struct mxs_saif_platform_data *pdata; struct pinctrl *pinctrl; int ret = 0; @@ -682,13 +681,6 @@ static int __devinit mxs_saif_probe(struct platform_device *pdev) if (saif->master_id < 0) return saif->master_id; } - } else { - saif->id = pdev->id; - pdata = pdev->dev.platform_data; - if (pdata && !pdata->master_mode) - saif->master_id = pdata->master_id; - else - saif->master_id = saif->id; } if (saif->master_id < 0 || saif->master_id >= ARRAY_SIZE(mxs_saif)) { -- 1.7.9.5

4 4

Re: [alsa-devel] [PATCH 5/5] snd-ice1712: Fix resume on ice1724
by Ondrej Zary 31 Oct '12

31 Oct '12

On Wednesday 17 October 2012 08:57:39 Takashi Iwai wrote: > At Sun, 14 Oct 2012 21:09:23 +0200, > > Ondrej Zary wrote: > > set_pro_rate() is called from hw_params() but not from prepare(), > > breaking running PCM on suspend/resume. Call it from prepare() if PCM was > > suspended to fix the problem. > > > > Signed-off-by: Ondrej Zary <linux(a)rainbow-software.org> > > This should be fixed in the resume callback. Could you check the > patch below instead? I've now verified that this patch fixes a real problem. When "multi track rate locking" is disabled and some sound is played at non-default (non-48kHz) frequency during suspend, the frequency is wrong (48kHz) after resume. This patch fixes that. > thanks, > > Takashi > > --- > diff --git a/sound/pci/ice1712/ice1724.c b/sound/pci/ice1712/ice1724.c > index 161c8f6..5cc3fa5 100644 > --- a/sound/pci/ice1712/ice1724.c > +++ b/sound/pci/ice1712/ice1724.c > @@ -2867,7 +2867,12 @@ static int snd_vt1724_resume(struct device *dev) > ice->set_spdif_clock(ice, 0); > } else { > /* internal on-card clock */ > - snd_vt1724_set_pro_rate(ice, ice->pro_rate_default, 1); > + int rate; > + if (ice->cur_rate) > + rate = ice->cur_rate; > + else > + rate = ice->pro_rate_default; > + snd_vt1724_set_pro_rate(ice, rate, 1); > } > > update_spdif_bits(ice, ice->pm_saved_spdif_ctrl); > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Ondrej Zary

2 1

[alsa-devel] possibly memory leak in alsa-lib
by Ivan Sorokin 30 Oct '12

30 Oct '12

The following program shows a few leaks in valgrind (ubuntu 12.04, alsa-lib 1.0.25, eglibc 2.15): #include <alsa/asoundlib.h> int main() { snd_pcm_t* pcm = 0; snd_pcm_open(&pcm, "default", SND_PCM_STREAM_PLAYBACK, 0); snd_pcm_close(pcm); snd_config_update_free_global(); } Do I close pcm correctly? In file MEMORY-LEAK it is written that program should call snd_config_update_free_global() to free global configuration cache and I do so. I'm not sure, but probably some leaks are caused by glibc.

2 2

[alsa-devel] Store codec capabilites in alsa
by Bharath Ramachandramurthy 30 Oct '12

30 Oct '12

Hello Is there a mechanism for the codec driver to register the codec capabilities to the ALSA framework ? The BE CPU dai driver can then read the capabilities of the codec and talk to the DSP. Thanks Bharath

4 7

[alsa-devel] [PATCH 1/5] ARM: at91: atmel-ssc: add platform device id table
by Bo Shen 30 Oct '12

30 Oct '12

Using platform device id to check whether the Atmel SOC support dma for data transfer If match "at91rm9200_ssc" which does not support DMA transfer If match "at91sam9g45_ssc" which support DMA transfer Signed-off-by: Bo Shen <voice.shen(a)atmel.com> --- arch/arm/mach-at91/at91rm9200.c | 6 +++--- arch/arm/mach-at91/at91rm9200_devices.c | 6 +++--- arch/arm/mach-at91/at91sam9260.c | 2 +- arch/arm/mach-at91/at91sam9260_devices.c | 2 +- arch/arm/mach-at91/at91sam9261.c | 6 +++--- arch/arm/mach-at91/at91sam9261_devices.c | 6 +++--- arch/arm/mach-at91/at91sam9263.c | 4 ++-- arch/arm/mach-at91/at91sam9263_devices.c | 4 ++-- arch/arm/mach-at91/at91sam9g45.c | 4 ++-- arch/arm/mach-at91/at91sam9g45_devices.c | 4 ++-- arch/arm/mach-at91/at91sam9rl.c | 4 ++-- arch/arm/mach-at91/at91sam9rl_devices.c | 4 ++-- drivers/misc/atmel-ssc.c | 23 +++++++++++++++++++++++ include/linux/atmel-ssc.h | 5 +++++ 14 files changed, 54 insertions(+), 26 deletions(-) diff --git a/arch/arm/mach-at91/at91rm9200.c b/arch/arm/mach-at91/at91rm9200.c index b4f0565..85d53c5 100644 --- a/arch/arm/mach-at91/at91rm9200.c +++ b/arch/arm/mach-at91/at91rm9200.c @@ -184,9 +184,9 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.1", &tc3_clk), CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.1", &tc4_clk), CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.1", &tc5_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.2", &ssc2_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.2", &ssc2_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91rm9200", &twi_clk), /* fake hclk clock */ CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &ohci_clk), diff --git a/arch/arm/mach-at91/at91rm9200_devices.c b/arch/arm/mach-at91/at91rm9200_devices.c index a563189..59ceea1 100644 --- a/arch/arm/mach-at91/at91rm9200_devices.c +++ b/arch/arm/mach-at91/at91rm9200_devices.c @@ -752,7 +752,7 @@ static struct resource ssc0_resources[] = { }; static struct platform_device at91rm9200_ssc0_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 0, .dev = { .dma_mask = &ssc0_dmamask, @@ -794,7 +794,7 @@ static struct resource ssc1_resources[] = { }; static struct platform_device at91rm9200_ssc1_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 1, .dev = { .dma_mask = &ssc1_dmamask, @@ -836,7 +836,7 @@ static struct resource ssc2_resources[] = { }; static struct platform_device at91rm9200_ssc2_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 2, .dev = { .dma_mask = &ssc2_dmamask, diff --git a/arch/arm/mach-at91/at91sam9260.c b/arch/arm/mach-at91/at91sam9260.c index ad29f93..2c8aab0 100644 --- a/arch/arm/mach-at91/at91sam9260.c +++ b/arch/arm/mach-at91/at91sam9260.c @@ -210,7 +210,7 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.1", &tc3_clk), CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.1", &tc4_clk), CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.1", &tc5_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9260", &twi_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20", &twi_clk), /* more usart lookup table for DT entries */ diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c index 805ef95..9cfdc3f 100644 --- a/arch/arm/mach-at91/at91sam9260_devices.c +++ b/arch/arm/mach-at91/at91sam9260_devices.c @@ -742,7 +742,7 @@ static struct resource ssc_resources[] = { }; static struct platform_device at91sam9260_ssc_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 0, .dev = { .dma_mask = &ssc_dmamask, diff --git a/arch/arm/mach-at91/at91sam9261.c b/arch/arm/mach-at91/at91sam9261.c index 8d999eb..4e8c56e 100644 --- a/arch/arm/mach-at91/at91sam9261.c +++ b/arch/arm/mach-at91/at91sam9261.c @@ -174,9 +174,9 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tc0_clk), CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.0", &tc1_clk), CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.0", &tc2_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.2", &ssc2_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.2", &ssc2_clk), CLKDEV_CON_DEV_ID("hclk", "at91_ohci", &hck0), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9261", &twi_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10", &twi_clk), diff --git a/arch/arm/mach-at91/at91sam9261_devices.c b/arch/arm/mach-at91/at91sam9261_devices.c index 9752f17..299637f 100644 --- a/arch/arm/mach-at91/at91sam9261_devices.c +++ b/arch/arm/mach-at91/at91sam9261_devices.c @@ -706,7 +706,7 @@ static struct resource ssc0_resources[] = { }; static struct platform_device at91sam9261_ssc0_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 0, .dev = { .dma_mask = &ssc0_dmamask, @@ -748,7 +748,7 @@ static struct resource ssc1_resources[] = { }; static struct platform_device at91sam9261_ssc1_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 1, .dev = { .dma_mask = &ssc1_dmamask, @@ -790,7 +790,7 @@ static struct resource ssc2_resources[] = { }; static struct platform_device at91sam9261_ssc2_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 2, .dev = { .dma_mask = &ssc2_dmamask, diff --git a/arch/arm/mach-at91/at91sam9263.c b/arch/arm/mach-at91/at91sam9263.c index 6a01d03..95a5471 100644 --- a/arch/arm/mach-at91/at91sam9263.c +++ b/arch/arm/mach-at91/at91sam9263.c @@ -186,8 +186,8 @@ static struct clk *periph_clocks[] __initdata = { static struct clk_lookup periph_clocks_lookups[] = { /* One additional fake clock for macb_hclk */ CLKDEV_CON_ID("hclk", &macb_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.0", &mmc0_clk), CLKDEV_CON_DEV_ID("mci_clk", "atmel_mci.1", &mmc1_clk), CLKDEV_CON_DEV_ID("spi_clk", "atmel_spi.0", &spi0_clk), diff --git a/arch/arm/mach-at91/at91sam9263_devices.c b/arch/arm/mach-at91/at91sam9263_devices.c index 8dde220..df89a00 100644 --- a/arch/arm/mach-at91/at91sam9263_devices.c +++ b/arch/arm/mach-at91/at91sam9263_devices.c @@ -1199,7 +1199,7 @@ static struct resource ssc0_resources[] = { }; static struct platform_device at91sam9263_ssc0_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 0, .dev = { .dma_mask = &ssc0_dmamask, @@ -1241,7 +1241,7 @@ static struct resource ssc1_resources[] = { }; static struct platform_device at91sam9263_ssc1_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 1, .dev = { .dma_mask = &ssc1_dmamask, diff --git a/arch/arm/mach-at91/at91sam9g45.c b/arch/arm/mach-at91/at91sam9g45.c index 84af1b5..f4f96a6 100644 --- a/arch/arm/mach-at91/at91sam9g45.c +++ b/arch/arm/mach-at91/at91sam9g45.c @@ -239,8 +239,8 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.1", &tcb0_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10.0", &twi0_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g10.1", &twi1_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.0", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "at91sam9g45_ssc.1", &ssc1_clk), CLKDEV_CON_DEV_ID(NULL, "atmel-trng", &trng_clk), CLKDEV_CON_DEV_ID(NULL, "atmel_sha", &aestdessha_clk), CLKDEV_CON_DEV_ID(NULL, "atmel_tdes", &aestdessha_clk), diff --git a/arch/arm/mach-at91/at91sam9g45_devices.c b/arch/arm/mach-at91/at91sam9g45_devices.c index b159607..27e3bf6 100644 --- a/arch/arm/mach-at91/at91sam9g45_devices.c +++ b/arch/arm/mach-at91/at91sam9g45_devices.c @@ -1459,7 +1459,7 @@ static struct resource ssc0_resources[] = { }; static struct platform_device at91sam9g45_ssc0_device = { - .name = "ssc", + .name = "at91sam9g45_ssc", .id = 0, .dev = { .dma_mask = &ssc0_dmamask, @@ -1501,7 +1501,7 @@ static struct resource ssc1_resources[] = { }; static struct platform_device at91sam9g45_ssc1_device = { - .name = "ssc", + .name = "at91sam9g45_ssc", .id = 1, .dev = { .dma_mask = &ssc1_dmamask, diff --git a/arch/arm/mach-at91/at91sam9rl.c b/arch/arm/mach-at91/at91sam9rl.c index 72e9084..4110b54 100644 --- a/arch/arm/mach-at91/at91sam9rl.c +++ b/arch/arm/mach-at91/at91sam9rl.c @@ -184,8 +184,8 @@ static struct clk_lookup periph_clocks_lookups[] = { CLKDEV_CON_DEV_ID("t0_clk", "atmel_tcb.0", &tc0_clk), CLKDEV_CON_DEV_ID("t1_clk", "atmel_tcb.0", &tc1_clk), CLKDEV_CON_DEV_ID("t2_clk", "atmel_tcb.0", &tc2_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.0", &ssc0_clk), - CLKDEV_CON_DEV_ID("pclk", "ssc.1", &ssc1_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.0", &ssc0_clk), + CLKDEV_CON_DEV_ID("pclk", "at91rm9200_ssc.1", &ssc1_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20.0", &twi0_clk), CLKDEV_CON_DEV_ID(NULL, "i2c-at91sam9g20.1", &twi1_clk), CLKDEV_CON_ID("pioA", &pioA_clk), diff --git a/arch/arm/mach-at91/at91sam9rl_devices.c b/arch/arm/mach-at91/at91sam9rl_devices.c index d6ca054..01220c7 100644 --- a/arch/arm/mach-at91/at91sam9rl_devices.c +++ b/arch/arm/mach-at91/at91sam9rl_devices.c @@ -832,7 +832,7 @@ static struct resource ssc0_resources[] = { }; static struct platform_device at91sam9rl_ssc0_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 0, .dev = { .dma_mask = &ssc0_dmamask, @@ -874,7 +874,7 @@ static struct resource ssc1_resources[] = { }; static struct platform_device at91sam9rl_ssc1_device = { - .name = "ssc", + .name = "at91rm9200_ssc", .id = 1, .dev = { .dma_mask = &ssc1_dmamask, diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c index ac00f83..f40abd8 100644 --- a/drivers/misc/atmel-ssc.c +++ b/drivers/misc/atmel-ssc.c @@ -68,6 +68,26 @@ void ssc_free(struct ssc_device *ssc) } EXPORT_SYMBOL(ssc_free); +static struct atmel_ssc_platform_data at91rm9200_config = { + .use_dma = 0, +}; + +static struct atmel_ssc_platform_data at91sam9g45_config = { + .use_dma = 1, +}; + +static const struct platform_device_id atmel_ssc_devtypes[] = { + { + .name = "at91rm9200_ssc", + .driver_data = (unsigned long) &at91rm9200_config, + }, { + .name = "at91sam9g45_ssc", + .driver_data = (unsigned long) &at91sam9g45_config, + }, { + /* sentinel */ + } +}; + static int ssc_probe(struct platform_device *pdev) { struct resource *regs; @@ -80,6 +100,8 @@ static int ssc_probe(struct platform_device *pdev) } ssc->pdev = pdev; + ssc->pdata = (struct atmel_ssc_platform_data *) + platform_get_device_id(pdev)->driver_data; regs = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!regs) { @@ -139,6 +161,7 @@ static struct platform_driver ssc_driver = { .name = "ssc", .owner = THIS_MODULE, }, + .id_table = atmel_ssc_devtypes, .probe = ssc_probe, .remove = __devexit_p(ssc_remove), }; diff --git a/include/linux/atmel-ssc.h b/include/linux/atmel-ssc.h index 4eb3175..1ca0e32 100644 --- a/include/linux/atmel-ssc.h +++ b/include/linux/atmel-ssc.h @@ -5,10 +5,15 @@ #include <linux/list.h> #include <linux/io.h> +struct atmel_ssc_platform_data { + int use_dma; +}; + struct ssc_device { struct list_head list; void __iomem *regs; struct platform_device *pdev; + struct atmel_ssc_platform_data *pdata; struct clk *clk; int user; int irq; -- 1.7.9.5

3 11

[alsa-devel] [PATCH 1/2] sound: soc: tlv320aic32x4: Fix problem with first capture.
by Javier Martin 30 Oct '12

30 Oct '12

In its previous status, the first capture didn't work properly; nothing was actually recorded from the microphone. This behaviour was observed using a Visstrim M10 board. In order to solve this BUG a workaround has been added that, during the initialization process of the codec, powers on and off the ADC. The issue seems related to a HW BUG or some behavior that is not documented in the datasheet. Signed-off-by: Javier Martin <javier.martin(a)vista-silicon.com> --- sound/soc/codecs/tlv320aic32x4.c | 10 ++++++++++ sound/soc/codecs/tlv320aic32x4.h | 3 +++ 2 files changed, 13 insertions(+) diff --git a/sound/soc/codecs/tlv320aic32x4.c b/sound/soc/codecs/tlv320aic32x4.c index b0a73d3..aad92f9 100644 --- a/sound/soc/codecs/tlv320aic32x4.c +++ b/sound/soc/codecs/tlv320aic32x4.c @@ -675,6 +675,16 @@ static int aic32x4_probe(struct snd_soc_codec *codec) ARRAY_SIZE(aic32x4_snd_controls)); aic32x4_add_widgets(codec); + /* + * Workaround: for an unknown reason, the ADC needs to be powered up + * and down for the first capture to work properly. It seems related to + * a HW BUG or some kind of behavior not documented in the datasheet. + */ + tmp_reg = snd_soc_read(codec, AIC32X4_ADCSETUP); + snd_soc_write(codec, AIC32X4_ADCSETUP, tmp_reg | + AIC32X4_LADC_EN | AIC32X4_RADC_EN); + snd_soc_write(codec, AIC32X4_ADCSETUP, tmp_reg); + return 0; } diff --git a/sound/soc/codecs/tlv320aic32x4.h b/sound/soc/codecs/tlv320aic32x4.h index aae2b24..3577422 100644 --- a/sound/soc/codecs/tlv320aic32x4.h +++ b/sound/soc/codecs/tlv320aic32x4.h @@ -94,6 +94,9 @@ #define AIC32X4_WORD_LEN_24BITS 0x02 #define AIC32X4_WORD_LEN_32BITS 0x03 +#define AIC32X4_LADC_EN (1 << 7) +#define AIC32X4_RADC_EN (1 << 6) + #define AIC32X4_I2S_MODE 0x00 #define AIC32X4_DSP_MODE 0x01 #define AIC32X4_RIGHT_JUSTIFIED_MODE 0x02 -- 1.7.9.5

2 2

[alsa-devel] emu 1212m devel, firmware
by oeaiyu 30 Oct '12

30 Oct '12

Aloha! the thing is about emu 1212m - yep i know it's not working, but i can help to debug some and try to do something with it, i'm programming sometimes but not C, but i can debug and send you bugtrack and i can log win7 x64 if you really need it, i'm trying to not using it to spend some time to discover linux bugs - it's funny thing =)) alotofw3rkz hea i got 4 sound cards in comp i'm musician - you can listen some of my music @ symbiants.com i can send you some if you wish to. and for writing music 7 years ago or so i've bought that emu card +creative x-fi + ati r6xx hdmi + hda ati sb ad1988b not sure about r6xx. but all others are working, but emu it shows me e-mu 1010b PCI MAEM8960 but it is e-mu 1212m pci actually - the chip is similar but it's other it is like 1818m, of course the chip itself is audigy2 but the connectors are others it is very simple - i think just need to reroute some in / out also i know exactly that in latest drivers there was a firmware update (2.0.0.18 or something latest for win7) so the firmware is in the bundle that can be extracted from installer. well about in out some more - i got some front / surround /center / lfe / side sliders and more - i can send print screen if needed, but in hardware level i got adat/spdif in/out left \ right in jacks left \ right out jacks midi in \ out and special for micro-dock (this is why it is ":m") input - ethernet like that is not active also there are special pins on the card that splits card for two pieces and those ananlog in+out are with midi together and all spdif adat on the other part of card that interconnected via harddrive like ide-cable. well right now the main bug for me is that when i'm enabling this emu card, the emu-firmware is loading and it gets about 25% of CPU well this is a 1 full core, so i think that it would take the whole 100% if those cores wasn't separated or something. well as i suppose this is the firmware problem that is not suited for this hardware. -- RA OEAI

1 0

[alsa-devel] usb audio race at disconnect time
by Matthieu CASTET 30 Oct '12

30 Oct '12

Hi, while doing some monkey tests on a product we found races in usb audio code when the device in unplugged from usb (on linus master tree). This can be reproduced with usb_audio_show_race.diff and CONFIG_DEBUG_SLAB. With this patch, start a stream : # arecord -D hw:0 -r 44100 -c 2 -f S16_LE > /dev/null you will see the kernel log : "in snd_usb_hw_params sleeping" Unplug the device before "in snd_usb_hw_params sleeping exit", and you will see an oops in snd_pcm_hw_params Instead of using CONFIG_DEBUG_SLAB, usb_audio_show_use_after_free.diff can show use after free by setting usb_device pointer to NULL in snd_usb_audio_disconnect. [1] In order to protect from all the races, before using any usb_device we need to check if it is not freed. What's the best way to do that ? A trival fix would be to take a mutex in all snd_pcm_ops callback that access usb : { mutex_lock(&chip->shutdown_mutex); if (!chip->dev) { mutex_unlock(&chip->shutdown_mutex); return -ENODEV; } [...] mutex_unlock(&chip->shutdown_mutex); } But that will serialize all snd_pcm_ops callbacks. Another solution could be to use refcounting or rwlock patern : - snd_pcm_ops callbacks call rdlock_trylock/rdlock_unlock - usb_driver disconnect callback take rwlock_lock and never release it This will make "usb_driver disconnect" wait that all "snd_pcm_ops callback" are finished and abort all future call to "snd_pcm_ops callback". I believe similar problems exist in other drivers, (we saw another one in hidraw [2]), so it could be nice to find a generic pattern to help driver to manage correctly disconnection. Are there any recommended pattern ? Do you have any comment ? Thanks, Matthieu [1] [ 1366.315307] usb 1-2.1.3: new full-speed USB device number 4 using ehci-omap [ 1366.556579] input: USB Audio as /devices/platform/usbhs_omap/ehci-omap.0/usb1 /1-2/1-2.1/1-2.1.3/1-2.1.3:1.3/input/input1 [ 1366.604553] hid-generic 0003:06F8:C000.0001: input,hidraw0: USB HID v1.00 Dev ice [USB Audio] on usb-ehci-omap.0-2.1.3/input3 # # # arecord -D hw:0 -r 44100 -c 2 -f S16_LE > /dev/null Recording WAVE '[ 1368.937774] in snd_usb_hw_params sleeping stdin' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo Warning: rate is not accurate (requested = 44100Hz, got = 48000Hz) please, try the plug plugin [ 1372.385375] hid-generic 0003:06F8:C000.0001: can't reset device, ehci-omap.0- 2.1.3/input3, status -71 [ 1372.439514] usb 1-2.1.3: USB disconnect, device number 4 [ 1372.449005] hid-generic 0003:06F8:C000.0001: can't reset device, ehci-omap.0- 2.1.3/input3, status -71 [ 1378.947235] in snd_usb_hw_params sleeping exit [ 1378.952301] Unable to handle kernel NULL pointer dereference at virtual addre ss 0000029c [ 1378.961029] pgd = c31e8000 [ 1378.964019] [0000029c] *pgd=8e885831, *pte=00000000, *ppte=00000000 [ 1378.970825] Internal error: Oops: 17 [#1] SMP ARM [ 1378.975799] Modules linked in: [ 1378.979064] CPU: 0 Not tainted (3.6.0-03889-ge8dc7a6-dirty #5) [ 1378.985595] PC is at usb_ifnum_to_if+0xc/0xd4 [ 1378.990234] LR is at snd_usb_hw_params+0x1bc/0x764 [ 1378.995300] pc : [<c0275338>] lr : [<c030816c>] psr: 00000013 [ 1378.995300] sp : cf3fddf0 ip : cf3fde08 fp : cf3fde04 [ 1379.007415] r10: 0000bb80 r9 : 00000001 r8 : 00000000 [ 1379.012908] r7 : cf972f40 r6 : cf3e1f14 r5 : ce8ad000 r4 : cf3e1eb0 [ 1379.019805] r3 : 00000004 r2 : 00000005 r1 : 00000002 r0 : 00000000 [ 1379.026702] Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 1379.034240] Control: 10c5387d Table: 831e8019 DAC: 00000015 [ 1379.040313] Process arecord (pid: 636, stack limit = 0xcf3fc2f8) [ 1379.046661] Stack: (0xcf3fddf0 to 0xcf3fe000) [ 1379.051269] dde0: cf3e1eb0 ce8ad000 cf3fd e5c cf3fde08 [ 1379.059906] de00: c030816c c0275338 cf3fde3c cf3fde18 c02f5d68 c02f59e4 c05b4 c60 ce8ad000 [ 1379.068542] de20: cf3e1800 00000001 00000004 00000001 cf3fde5c cf3e1800 ce8ad 800 c05b8310 [ 1379.077178] de40: ce8ad000 c0014728 cf3fc000 00000000 cf3fde7c cf3fde60 c02f0 b8c c0307fbc [ 1379.085815] de60: cf3e1800 be91b890 be91b890 ce8ad000 cf3fdec4 cf3fde80 c02f1 778 c02f0ad4 [ 1379.094451] de80: cf3fc000 60000013 cf97b540 00000002 c0126484 00000000 cf3fd ed4 cf3e1800 [ 1379.103088] dea0: be91b890 cf3e5078 c0045877 c0014728 cf3fc000 00000000 cf3fd efc cf3fdec8 [ 1379.111755] dec0: c02f2150 c02f1228 cf3fdf3c cf3fded8 c0126634 c0068ef0 00000 001 00000000 [ 1379.120391] dee0: cf87f280 be91b890 cf3e5078 c0045877 cf3fdf0c cf3fdf00 c02f2 5dc c02f2124 [ 1379.129028] df00: cf3fdf7c cf3fdf10 c00fd6b4 c02f25ac c03d7328 cf8b49c8 00000 026 00000000 [ 1379.137664] df20: cd673738 00000002 cf3fc000 00000000 cf3fdf6c cf3fdf40 c00ec 138 c0126420 [ 1379.146301] df40: 00000000 00000000 00000006 cf8b49c0 be919140 00000000 cf87f 280 be91b890 [ 1379.154907] df60: c25c4111 00000004 c0014728 cf3fc000 cf3fdfa4 cf3fdf80 c00fd c6c c00fd638 [ 1379.163543] df80: c00183f0 00000000 00028288 b6fc68a0 00028238 00000036 00000 000 cf3fdfa8 [ 1379.172180] dfa0: c00145a0 c00fdc38 00028288 b6fc68a0 00000004 c25c4111 be91b 890 00020001 [ 1379.180816] dfc0: 00028288 b6fc68a0 00028238 00000036 be91b890 0000bb80 0000a c44 be91bb74 [ 1379.189453] dfe0: 00028288 be91b760 b6fa41c8 b6e05aec 20000010 00000004 007ff f00 00ffdf00 [ 1379.198089] Backtrace: [ 1379.200683] [<c027532c>] (usb_ifnum_to_if+0x0/0xd4) from [<c030816c>] (snd_us b_hw_params+0x1bc/0x764) [ 1379.210418] r5:ce8ad000 r4:cf3e1eb0 [ 1379.214263] [<c0307fb0>] (snd_usb_hw_params+0x0/0x764) from [<c02f0b8c>] (snd _pcm_hw_params+0xc4/0x368) [ 1379.224182] [<c02f0ac8>] (snd_pcm_hw_params+0x0/0x368) from [<c02f1778>] (snd _pcm_common_ioctl1+0x55c/0xefc) [ 1379.234558] r7:ce8ad000 r6:be91b890 r5:be91b890 r4:cf3e1800 [ 1379.240600] [<c02f121c>] (snd_pcm_common_ioctl1+0x0/0xefc) from [<c02f2150>] (snd_pcm_capture_ioctl1+0x38/0x488) [ 1379.251342] [<c02f2118>] (snd_pcm_capture_ioctl1+0x0/0x488) from [<c02f25dc>] (snd_pcm_capture_ioctl+0x3c/0x40) [ 1379.261962] r7:c0045877 r6:cf3e5078 r5:be91b890 r4:cf87f280 [ 1379.268005] [<c02f25a0>] (snd_pcm_capture_ioctl+0x0/0x40) from [<c00fd6b4>] ( do_vfs_ioctl+0x88/0x600) [ 1379.277770] [<c00fd62c>] (do_vfs_ioctl+0x0/0x600) from [<c00fdc6c>] (sys_ioct l+0x40/0x68) [ 1379.286376] r9:cf3fc000 r8:c0014728 r7:00000004 r6:c25c4111 r5:be91b890 r4:cf87f280 [ 1379.294738] [<c00fdc2c>] (sys_ioctl+0x0/0x68) from [<c00145a0>] (ret_fast_sys call+0x0/0x30) [ 1379.303558] r7:00000036 r6:00028238 r5:b6fc68a0 r4:00028288 [ 1379.309600] Code: e89da818 e1a0c00d e92dd830 e24cb004 (e590329c) [ 1379.316223] ---[ end trace 48c30133f24e0b57 ]--- [ 1379.321105] Kernel panic - not syncing: Fatal exception [2] [ 349.573974] ------------[ cut here ]------------ [ 349.578796] WARNING: at /opt/mcastet/CIA/fidji-beta28/raptor/kernel/omap/lib/list_debug.c:48 list_del+0x30/0x8c() [ 349.589477] list_del corruption. prev->next should be d95efc44, but was 6b6b6b6b [ 349.597167] Modules linked in: blackberry cdc_acm sierra option usb_wwan hso atmel_mxt_ts cp210x pl2303 usbserial 88w8688_wlan tun omap2_mcspi omap_hsmmc [ 349.611572] [<c013e608>] (unwind_backtrace+0x0/0xf0) from [<c016f7b4>] (warn_slowpath_common+0x4c/0x64) [ 349.621368] [<c016f7b4>] (warn_slowpath_common+0x4c/0x64) from [<c016f84c>] (warn_slowpath_fmt+0x2c/0x3c) [ 349.631347] [<c016f84c>] (warn_slowpath_fmt+0x2c/0x3c) from [<c0298200>] (list_del+0x30/0x8c) [ 349.640228] [<c0298200>] (list_del+0x30/0x8c) from [<c0185d50>] (remove_wait_queue+0x2c/0x6c) [ 349.649108] [<c0185d50>] (remove_wait_queue+0x2c/0x6c) from [<c01f4e64>] (free_poll_entry+0x14/0x20) [ 349.658630] [<c01f4e64>] (free_poll_entry+0x14/0x20) from [<c01f4e88>] (poll_freewait+0x18/0x6c) [ 349.667785] [<c01f4e88>] (poll_freewait+0x18/0x6c) from [<c01f5448>] (do_sys_poll+0x314/0x3a4) [ 349.676757] [<c01f5448>] (do_sys_poll+0x314/0x3a4) from [<c01f56fc>] (sys_poll+0x5c/0xbc) [ 349.685272] [<c01f56fc>] (sys_poll+0x5c/0xbc) from [<c0138f40>] (ret_fast_syscall+0x0/0x30) [ 349.693969] ---[ end trace 1b75b31a2719ed1e ]--- [ 349.698791] ------------[ cut here ]------------ [ 349.703582] WARNING: at /opt/mcastet/CIA/fidji-beta28/raptor/kernel/omap/lib/list_debug.c:51 list_del+0x58/0x8c() [ 349.714263] list_del corruption. next->prev should be d95efc44, but was 6b6b6b6b [ 349.721954] Modules linked in: blackberry cdc_acm sierra option usb_wwan hso atmel_mxt_ts cp210x pl2303 usbserial 88w8688_wlan tun omap2_mcspi omap_hsmmc [ 349.736328] [<c013e608>] (unwind_backtrace+0x0/0xf0) from [<c016f7b4>] (warn_slowpath_common+0x4c/0x64) [ 349.746124] [<c016f7b4>] (warn_slowpath_common+0x4c/0x64) from [<c016f84c>] (warn_slowpath_fmt+0x2c/0x3c) [ 349.756103] [<c016f84c>] (warn_slowpath_fmt+0x2c/0x3c) from [<c0298228>] (list_del+0x58/0x8c) [ 349.764984] [<c0298228>] (list_del+0x58/0x8c) from [<c0185d50>] (remove_wait_queue+0x2c/0x6c) [ 349.773864] [<c0185d50>] (remove_wait_queue+0x2c/0x6c) from [<c01f4e64>] (free_poll_entry+0x14/0x20) [ 349.783386] [<c01f4e64>] (free_poll_entry+0x14/0x20) from [<c01f4e88>] (poll_freewait+0x18/0x6c) [ 349.792541] [<c01f4e88>] (poll_freewait+0x18/0x6c) from [<c01f5448>] (do_sys_poll+0x314/0x3a4) [ 349.801513] [<c01f5448>] (do_sys_poll+0x314/0x3a4) from [<c01f56fc>] (sys_poll+0x5c/0xbc) [ 349.810028] [<c01f56fc>] (sys_poll+0x5c/0xbc) from [<c0138f40>] (ret_fast_syscall+0x0/0x30) [ 349.818725] ---[ end trace 1b75b31a2719ed1f ]--- [ 349.830444] hub 1-1:1.0: unable to enumerate USB device on port 2 [ 350.412475] Slab corruption: size-64 start=d7189ac0, len=64 [ 350.420166] 000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b cc 9a 18 d7 [ 350.426544] 010: cc 9a 18 d7 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b [ 350.435699] Prev obj: start=d7189a80, len=64 [ 350.441284] 000: 02 26 00 00 c5 91 18 d7 84 93 18 d7 c4 9d 18 d7 [ 350.447601] 010: 50 91 ad d3 50 9f 18 d7 50 95 ad d3 00 00 00 00 [ 350.454650] Next obj: start=d7189b00, len=64 [ 350.460083] 000: 5d 25 00 00 05 78 e5 d8 c4 9e 18 d7 44 13 6a d9 [ 350.466613] 010: 91 13 6a d9 00 00 00 00 00 00 00 00 00 00 00 00

2 14

[alsa-devel] [PATCH] ASoC: fsi: fsi_set_master_clk() was called from fsi_hw_xxx() only
by Kuninori Morimoto 29 Oct '12

29 Oct '12

Current FSI driver is using fsi_set_master_clk() if it needs system clock. But this function was called from fsi_hw_shutdown()/fsi_dai_trigger()/fsi_resume() without a sense of unity. Because of this, sound playback after suspend failed sometimes. To keep consistency, fsi_master_clk() was called from fsi_hw_start/stop() only now. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> --- sound/soc/sh/fsi.c | 23 ++++++++--------------- 1 file changed, 8 insertions(+), 15 deletions(-) diff --git a/sound/soc/sh/fsi.c b/sound/soc/sh/fsi.c index a33d483..e97501b 100644 --- a/sound/soc/sh/fsi.c +++ b/sound/soc/sh/fsi.c @@ -1364,12 +1364,17 @@ static int fsi_hw_startup(struct fsi_priv *fsi, /* fifo init */ fsi_fifo_init(fsi, io, dev); + /* start master clock */ + if (fsi_is_clk_master(fsi)) + fsi_set_master_clk(dev, fsi, fsi->rate, 1); + return 0; } static void fsi_hw_shutdown(struct fsi_priv *fsi, struct device *dev) { + /* stop master clock */ if (fsi_is_clk_master(fsi)) fsi_set_master_clk(dev, fsi, fsi->rate, 0); } @@ -1492,19 +1497,11 @@ static int fsi_dai_hw_params(struct snd_pcm_substream *substream, struct snd_soc_dai *dai) { struct fsi_priv *fsi = fsi_get_priv(substream); - long rate = params_rate(params); - int ret; - - if (!fsi_is_clk_master(fsi)) - return 0; - - ret = fsi_set_master_clk(dai->dev, fsi, rate, 1); - if (ret < 0) - return ret; - fsi->rate = rate; + if (fsi_is_clk_master(fsi)) + fsi->rate = params_rate(params); - return ret; + return 0; } static const struct snd_soc_dai_ops fsi_dai_ops = { @@ -1806,10 +1803,6 @@ static void __fsi_resume(struct fsi_priv *fsi, return; fsi_hw_startup(fsi, io, dev); - - if (fsi_is_clk_master(fsi) && fsi->rate) - fsi_set_master_clk(dev, fsi, fsi->rate, 1); - fsi_stream_start(fsi, io); } -- 1.7.9.5

2 1

[alsa-devel] snd_pcm_sw_params_set_start_threshold() functionality
by irfanks 29 Oct '12

29 Oct '12

Hello, snd_pcm_sw_params_set_start_threshold() API description explains, "PCM is automatically started when playback frames available to PCM are >= threshold" I want to know, whether above pre-buffering(threshold) mechanism is only during the start of playback ? OR Also if my playback device goes to XRUN state, Again next time when i prepare my playback device using snd_pcm_prepare(). Again the prebuffering (threshold) will occur since i have set snd_pcm_sw_params_set_start_threshold() to N periods in software params. Best Regards, Thanks in advance, Irfan...

1 1

[alsa-devel] [PATCH 4/4] ASoC: ak5702: Makefile and Kconfig for ak5702
by Paolo Doz 29 Oct '12

29 Oct '12

ASoC: ak5702: Makefile and Kconfig for ak5702 Signed-off-by: Paolo Doz <paolo.doz(a)gmail.com> --- sound/soc/codecs/Kconfig | 4 ++++ sound/soc/codecs/Makefile | 2 ++ 2 files changed, 6 insertions(+) diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 6f4f284..c029778 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -26,6 +26,7 @@ config SND_SOC_ALL_CODECS select SND_SOC_AK4641 if I2C select SND_SOC_AK4642 if I2C select SND_SOC_AK4671 if I2C + select SND_SOC_AK5702 if I2C select SND_SOC_ALC5623 if I2C select SND_SOC_ALC5632 if I2C select SND_SOC_CQ0093VC if MFD_DAVINCI_VOICECODEC @@ -194,6 +195,9 @@ config SND_SOC_AK4642 config SND_SOC_AK4671 tristate +config SND_SOC_AK5702 + tristate + config SND_SOC_ALC5623 tristate config SND_SOC_ALC5632 diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile index c55d2d7..cc201a0 100644 --- a/sound/soc/codecs/Makefile +++ b/sound/soc/codecs/Makefile @@ -14,6 +14,7 @@ snd-soc-ak4535-objs := ak4535.o snd-soc-ak4641-objs := ak4641.o snd-soc-ak4642-objs := ak4642.o snd-soc-ak4671-objs := ak4671.o +snd-soc-ak5702-objs := ak5702.o snd-soc-arizona-objs := arizona.o snd-soc-cq93vc-objs := cq93vc.o snd-soc-cs42l51-objs := cs42l51.o @@ -134,6 +135,7 @@ obj-$(CONFIG_SND_SOC_AK4535) += snd-soc-ak4535.o obj-$(CONFIG_SND_SOC_AK4641) += snd-soc-ak4641.o obj-$(CONFIG_SND_SOC_AK4642) += snd-soc-ak4642.o obj-$(CONFIG_SND_SOC_AK4671) += snd-soc-ak4671.o +obj-$(CONFIG_SND_SOC_AK5702) += snd-soc-ak5702.o obj-$(CONFIG_SND_SOC_ALC5623) += snd-soc-alc5623.o obj-$(CONFIG_SND_SOC_ALC5632) += snd-soc-alc5632.o obj-$(CONFIG_SND_SOC_ARIZONA) += snd-soc-arizona.o -- 1.7.9.5

1 0

[alsa-devel] [PATCH 3/4] ASoC: ak5702: include file for clock type
by Paolo Doz 29 Oct '12

29 Oct '12

Include file used to define clock type of ak5702. Signed-off-by: Paolo Doz <paolo.doz(a)gmail.com> --- include/sound/ak5702.h | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 include/sound/ak5702.h diff --git a/include/sound/ak5702.h b/include/sound/ak5702.h new file mode 100644 index 0000000..0ea2792 --- /dev/null +++ b/include/sound/ak5702.h @@ -0,0 +1,27 @@ +/* + * ak5702.h -- AK5702 ALSA SoC driver + * + * Author: Paolo Doz <paolo.doz(a)gmail.com> + * Copyright: (C) 2012 Soft In S.r.l. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef __AK5702_H +#define __AK5702_H + +/** + * enum ak5702_clock mode + */ + +enum ak5702_clock_mode { + PLL_master_mode, + PLL_slave_mode, + PLL_slave_mode2, + EXT_slave_mode, + EXT_master_mode +}; + +#endif /* __AK5702_H */ -- 1.7.9.5

1 0

[alsa-devel] [PATCH 2/4] ASoC: ak5702: register list of ak5702
by Paolo Doz 29 Oct '12

29 Oct '12

This header file defines the list and possible values of ak5702 registers. Signed-off-by: Paolo Doz <paolo.doz(a)gmail.com> --- sound/soc/codecs/ak5702.h | 164 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 164 insertions(+) create mode 100644 sound/soc/codecs/ak5702.h diff --git a/sound/soc/codecs/ak5702.h b/sound/soc/codecs/ak5702.h new file mode 100644 index 0000000..b214350 --- /dev/null +++ b/sound/soc/codecs/ak5702.h @@ -0,0 +1,164 @@ +/* + * ak5702.h -- AK5702 ALSA SoC driver + * + * Author: Paolo Doz <paolo.doz(a)gmail.com> + * Copyright: (C) 2012 Soft In S.r.l. + * 2009 Freescale Semiconductor, Inc. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This code comes from the original Freescale Ak5702 Audio driver + */ + +#ifndef _AK5702_H +#define _AK5702_H + +/* AK5702 register space */ + +#define AK5702_PM1 0x00 +#define AK5702_PLL1 0x01 +#define AK5702_SIG1 0x02 +#define AK5702_MICG1 0x03 +#define AK5702_FMT1 0x04 +#define AK5702_FS1 0x05 +#define AK5702_CLK1 0x06 +#define AK5702_VOLCTRL1 0x07 +#define AK5702_LVOL1 0x08 +#define AK5702_RVOL1 0x09 +#define AK5702_TIMER1 0x0A +#define AK5702_ALC11 0x0B +#define AK5702_ALC12 0x0C +#define AK5702_MODE11 0x0D +#define AK5702_MODE12 0x0E +#define AK5702_MODE13 0x0F + +#define AK5702_PM2 0x10 +#define AK5702_PLL2 0x11 +#define AK5702_SIG2 0x12 +#define AK5702_MICG2 0x13 +#define AK5702_FMT2 0x14 +#define AK5702_FS2 0x15 +#define AK5702_CLK2 0x16 +#define AK5702_VOLCTRL2 0x17 +#define AK5702_LVOL2 0x18 +#define AK5702_RVOL2 0x19 +#define AK5702_TIMER2 0x1A +#define AK5702_ALC21 0x1B +#define AK5702_ALC22 0x1C +#define AK5702_MODE21 0x1D +#define AK5702_MODE22 0x1E + +#define AK5702_CACHEREGNUM 0x1F + +#define AK5702_POWERDOWN 0x0 +#define AK5702_PM1_PMADAL 0x01 +#define AK5702_PM1_PMADAR 0x02 +#define AK5702_PM1_PMVCM 0x04 +#define AK5702_PM2_PMADBL 0x01 +#define AK5702_PM2_PMADBR 0x02 + +#define AK5702_PLL1_POWERDOWN 0x0 +#define AK5702_PLL1_POWERUP 0x01 +#define AK5702_PLL1_MASTER 0x02 +#define AK5702_PLL1_SLAVE 0x0 +#define AK5702_PLL1_MODE0 0x0 +#define AK5702_PLL1_MODE2 0x08 +#define AK5702_PLL1_MODE3 0x0C +#define AK5702_PLL1_MODE4 0x10 +#define AK5702_PLL1_MODE5 0x14 +#define AK5702_PLL1_MODE6 0x18 +#define AK5702_PLL1_MODE7 0x1C +#define AK5702_PLL1_MODE8 0x20 +#define AK5702_PLL1_MODE9 0x24 +#define AK5702_PLL1_MODE12 0x30 +#define AK5702_PLL1_MODE13 0x34 +#define AK5702_PLL1_MODE14 0x38 +#define AK5702_PLL1_MODE15 0x3C +#define AK5702_PLL1_11289600 0x10 +#define AK5702_PLL1_12000000 0x24 +#define AK5702_PLL1_12288000 0x14 +#define AK5702_PLL1_19200000 0x20 + +#define AK5702_FS1_MCKI_MODE0 0x0 +#define AK5702_FS1_MCKI_MODE1 0x01 +#define AK5702_FS1_MCKI_MODE2 0x02 +#define AK5702_FS1_MCKI_MODE3 0x03 +#define AK5702_FS1_MCKI_MODE4 0x04 +#define AK5702_FS1_MCKI_MODE5 0x05 +#define AK5702_FS1_MCKI_MODE6 0x06 +#define AK5702_FS1_MCKI_MODE7 0x07 +#define AK5702_FS1_MCKI_MODE10 0x0A +#define AK5702_FS1_MCKI_MODE11 0x0B +#define AK5702_FS1_MCKI_MODE14 0x0E +#define AK5702_FS1_MCKI_MODE15 0x0F + +#define AK5702_FS1_BCLK_MODE0 0x0 +#define AK5702_FS1_BCLK_MODE1 0x04 +#define AK5702_FS1_BCLK_MODE2 0x08 + +#define AK5702_FS1_SLAVE_1024FS 0x01 +#define AK5702_FS1_SLAVE_512FS 0x02 +#define AK5702_FS1_SLAVE_256FS 0x03 + +#define AK5702_SIG1_L_LIN1 0x0 +#define AK5702_SIG1_L_LIN2 0x01 +#define AK5702_SIG1_R_RIN1 0x0 +#define AK5702_SIG1_R_RIN2 0x02 +#define AK5702_SIG1_PMMPA 0x10 +#define AK5702_SIG1_L_LIN5 0x20 +#define AK5702_SIG1_R_RIN5 0x40 +#define AK5702_SIG2_L_LIN3 0x0 +#define AK5702_SIG2_L_LIN4 0x01 +#define AK5702_SIG2_R_RIN3 0x0 +#define AK5702_SIG2_R_RIN4 0x02 +#define AK5702_SIG2_PMMPB 0x10 + +#define AK5702_MICGAIN_0DB 0x0 + +#define AK5702_FMT1_I2S 0x23 +#define AK5702_FMT1_MSB 0x22 +#define AK5702_FMT1_TDM128 0x60 +#define AK5702_FMT1_TDM256 0xE0 +#define AK5702_FMT2_STEREO 0x20 +#define AK5702_FS1_BCKO_32FS 0x10 +#define AK5702_FS1_BCKO_64FS 0x20 +#define AK5702_CLK1_PS_256FS 0x0 +#define AK5702_CLK1_PS_128FS 0x01 +#define AK5702_CLK1_PS_64FS 0x02 +#define AK5702_CLK1_PS_32FS 0x03 +#define AK5702_VOLCTRL_INDEP 0x0 +#define AK5702_VOLCTRL_DEP 0x01 +#define AK5702_VOL_INIT 0x91 + +#define AK5702_PLL1_PM_MASK 0x01 +#define AK5702_PLL1_MODE_MASK 0x02 +#define AK5702_PLL1_PLL_MASK 0x3C +#define AK5702_FS1_BCKO_MASK 0x30 +#define AK5702_FS1_FS_MASK 0x0F +#define AK5702_CLK1_PS_MASK 0x03 +#define AK5702_FMT1_TDM_MASK 0xC0 +/* clock divider id */ +#define AK5702_BCLK_CLKDIV 0 +#define AK5702_MCLK_CLKDIV 1 + +/* bit clock div values */ +#define AK5702_BCLK_DIV_32 0 +#define AK5702_BCLK_DIV_64 1 + +/* m clock div values */ +#define AK5702_MCLK_DIV_32 0 +#define AK5702_MCLK_DIV_64 1 +#define AK5702_MCLK_DIV_128 2 +#define AK5702_MCLK_DIV_256 3 + +/* PLL master and slave modes */ +#define AK5702_PLL_POWERDOWN 0 +#define AK5702_PLL_MASTER 1 +#define AK5702_PLL_SLAVE 2 + +extern struct snd_soc_dai_driver ak5702_dai; +extern struct snd_soc_codec_driver soc_codec_dev_ak5702; + +#endif -- 1.7.9.5

1 0

[alsa-devel] [PATCH] ALSA: core: fix 64-bit SNDRV_PCM_IOCTL_STATUS ABI breakage
by Clemens Ladisch 29 Oct '12

29 Oct '12

Commit 4eeaaeaea (ALSA: core: add hooks for audio timestamps) added the new audio_tstamp field to struct snd_pcm_status. However, struct timespec requires 64-bit alignment, so the 64-bit compiler would insert 32 bits of padding before this field, which broke SNDRV_PCM_IOCTL_STATUS with error messages like this: kernel: unknown ioctl = 0x80984120 To solve this, insert the padding explicitly so that it can be taken into account when calculating the ABI structure size. Signed-off-by: Clemens Ladisch <clemens(a)ladisch.de> --- include/uapi/sound/asound.h | 3 ++- sound/core/pcm_compat.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) --- a/include/uapi/sound/asound.h +++ b/include/uapi/sound/asound.h @@ -408,8 +408,9 @@ struct snd_pcm_status { snd_pcm_uframes_t avail_max; /* max frames available on hw since last status */ snd_pcm_uframes_t overrange; /* count of ADC (capture) overrange detections from last status */ snd_pcm_state_t suspended_state; /* suspended stream state */ + __u32 reserved_alignment; /* must be filled with zero */ struct timespec audio_tstamp; /* from sample counter or wall clock */ - unsigned char reserved[60-sizeof(struct timespec)]; /* must be filled with zero */ + unsigned char reserved[56-sizeof(struct timespec)]; /* must be filled with zero */ }; struct snd_pcm_mmap_status { --- a/sound/core/pcm_compat.c +++ b/sound/core/pcm_compat.c @@ -190,8 +190,9 @@ struct snd_pcm_status32 { u32 avail_max; u32 overrange; s32 suspended_state; + u32 reserved_alignment; struct compat_timespec audio_tstamp; - unsigned char reserved[60-sizeof(struct compat_timespec)]; + unsigned char reserved[56-sizeof(struct compat_timespec)]; } __attribute__((packed));

2 3

[alsa-devel] [PATCH - ALSA: snd-virtuoso 1/1] Xonar DSX support
by sgiurgiu11＠gmail.com 29 Oct '12

29 Oct '12

From: Sergiu Giurgiu <sgiurgiu11(a)gmail.com> Signed-off-by: Sergiu Giurgiu <sgiurgiu11(a)gmail.com> diff --git a/mirror/sound/pci/oxygen/virtuoso.c b/mirror/sound/pci/oxygen/virtuoso.c index 3d71423..8104eab 100644 --- a/mirror/sound/pci/oxygen/virtuoso.c +++ b/mirror/sound/pci/oxygen/virtuoso.c @@ -52,6 +52,7 @@ static DEFINE_PCI_DEVICE_TABLE(xonar_ids) = { { OXYGEN_PCI_SUBID(0x1043, 0x835d) }, { OXYGEN_PCI_SUBID(0x1043, 0x835e) }, { OXYGEN_PCI_SUBID(0x1043, 0x838e) }, + { OXYGEN_PCI_SUBID(0x1043, 0x8522) }, { OXYGEN_PCI_SUBID_BROKEN_EEPROM }, { } }; diff --git a/mirror/sound/pci/oxygen/xonar_wm87x6.c b/mirror/sound/pci/oxygen/xonar_wm87x6.c index 63cff90..af91016 100644 --- a/mirror/sound/pci/oxygen/xonar_wm87x6.c +++ b/mirror/sound/pci/oxygen/xonar_wm87x6.c @@ -1321,6 +1321,40 @@ static const struct oxygen_model model_xonar_hdav_slim = { .adc_i2s_format = OXYGEN_I2S_FORMAT_LJUST, }; +static const struct oxygen_model model_xonar_dsx = { + .shortname = "Xonar DSX", + .longname = "Asus Virtuoso 66", + .chip = "AV200", + .init = xonar_ds_init, + .mixer_init = xonar_ds_mixer_init, + .cleanup = xonar_ds_cleanup, + .suspend = xonar_ds_suspend, + .resume = xonar_ds_resume, + .pcm_hardware_filter = wm8776_adc_hardware_filter, + .set_dac_params = set_wm87x6_dac_params, + .set_adc_params = set_wm8776_adc_params, + .update_dac_volume = update_wm87x6_volume, + .update_dac_mute = update_wm87x6_mute, + .update_center_lfe_mix = update_wm8766_center_lfe_mix, + .gpio_changed = xonar_ds_gpio_changed, + .dump_registers = dump_wm87x6_registers, + .dac_tlv = wm87x6_dac_db_scale, + .model_data_size = sizeof(struct xonar_wm87x6), + .device_config = PLAYBACK_0_TO_I2S | + PLAYBACK_1_TO_SPDIF | + CAPTURE_0_FROM_I2S_1 | + CAPTURE_1_FROM_SPDIF, + .dac_channels_pcm = 8, + .dac_channels_mixer = 8, + .dac_volume_min = 255 - 2*60, + .dac_volume_max = 255, + .function_flags = OXYGEN_FUNCTION_SPI, + .dac_mclks = OXYGEN_MCLKS(256, 256, 128), + .adc_mclks = OXYGEN_MCLKS(256, 256, 128), + .dac_i2s_format = OXYGEN_I2S_FORMAT_LJUST, + .adc_i2s_format = OXYGEN_I2S_FORMAT_LJUST, +}; + int __devinit get_xonar_wm87x6_model(struct oxygen *chip, const struct pci_device_id *id) { @@ -1331,6 +1365,9 @@ int __devinit get_xonar_wm87x6_model(struct oxygen *chip, case 0x835e: chip->model = model_xonar_hdav_slim; break; + case 0x8522: + chip->model = model_xonar_dsx; + break; default: return -EINVAL; } -- 1.7.10.4

5 4

[alsa-devel] Back-end state transition query
by Patrick Lai 29 Oct '12

29 Oct '12

Hi Liam, I am facing an issue related to how DPCM manages state of back-end substream. Here is description of problem: When front-end PCM substream is in paused state, back-end PCM substream will be put in paused state as well if given front-end PCM substream is the only client of given back-end. Based on current implementation of DPCM, when application closes front-end PCM substream, DPCM framework will not allow back-end enter HW_FREE state so back-end will never get shutdown completely as well. refer to function soc_dpcm_be_dai_hw_free(), here is the check for states if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) && (be->dpcm[stream].state != SND_SOC_DPCM_STATE_PREPARE) && (be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_FREE) && (be->dpcm[stream].state != SND_SOC_DPCM_STATE_STOP)) continue; Can't DPCM also allow back-end hardware being freed in STATE_PAUSED? Even if DPCM expects trigger stop coming to update back-end state to STATE_STOP, the following condition check will never allow back-end enter stop state anyway Refer to soc_dpcm_be_dai_trigger() case SNDRV_PCM_TRIGGER_STOP: if (be->dpcm[stream].state != SND_SOC_DPCM_STATE_START) continue; Can you please take a look and recommend the appropriate state transition or it would be okay to allow PAUSED state in soc_dpcm_be_dai_hw_free()? 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 2

Re: [alsa-devel] [PATCH 00/16] treewide: Convert dev_printk(KERN_<LEVEL> to dev_<level>(
by Joe Perches 28 Oct '12

28 Oct '12

On Sun, 2012-10-28 at 14:54 +0400, Sergei Shtylyov wrote: > Hello. Hi Sergei. > On 28-10-2012 12:05, Joe Perches wrote: > > > dev_<level> create smaller objects than dev_printk(KERN_<LEVEL>. > > Convert non-debug calls to this form. > > > Joe Perches (16): > > tile: Convert dev_printk(KERN_<LEVEL> to dev_<level>( > [...] > > tile: Convert dev_printk(KERN_<LEVEL> to dev_<level>( > [...] > > tile: Convert dev_printk(KERN_<LEVEL> to dev_<level>( > > Hm, somehow this patch is repeated thrice? Nope, I forgot to edit the 0000 file after I edited patches locally when I noticed I forgot to update the subject lines. Patches are corrected, 0000 not. I don't think it's a bit deal, I could repost just the 0000 if you want though. cheers, Joe

1 0

[alsa-devel] [PATCH 00/16] treewide: Convert dev_printk(KERN_<LEVEL> to dev_<level>(
by Joe Perches 28 Oct '12

28 Oct '12

dev_<level> create smaller objects than dev_printk(KERN_<LEVEL>. Convert non-debug calls to this form. Joe Perches (16): tile: Convert dev_printk(KERN_<LEVEL> to dev_<level>( ata: Convert dev_printk(KERN_<LEVEL> to dev_<level>( drivers: base: Convert dev_printk(KERN_<LEVEL> to dev_<level>( block: Convert dev_printk(KERN_<LEVEL> to dev_<level>( pcmcia: Convert dev_printk(KERN_<LEVEL> to dev_<level>( dma: Convert dev_printk(KERN_<LEVEL> to dev_<level>( gpu: Convert dev_printk(KERN_<LEVEL> to dev_<level>( i2c: Convert dev_printk(KERN_<LEVEL> to dev_<level>( wireless: Convert dev_printk(KERN_<LEVEL> to dev_<level>( ethernet: Convert dev_printk(KERN_<LEVEL> to dev_<level>( pci: Convert dev_printk(KERN_<LEVEL> to dev_<level>( scsi: Convert dev_printk(KERN_<LEVEL> to dev_<level>( usb: Convert dev_printk(KERN_<LEVEL> to dev_<level>( tile: Convert dev_printk(KERN_<LEVEL> to dev_<level>( watchdog: Convert dev_printk(KERN_<LEVEL> to dev_<level>( tile: Convert dev_printk(KERN_<LEVEL> to dev_<level>( arch/tile/kernel/pci_gx.c | 15 ++--- drivers/ata/pata_cmd64x.c | 6 +- drivers/base/attribute_container.c | 2 +- drivers/base/devres.c | 4 +- drivers/block/umem.c | 97 ++++++++++++-------------- drivers/char/pcmcia/cm4040_cs.c | 5 +- drivers/dma/at_hdmac_regs.h | 8 +- drivers/dma/iop-adma.c | 45 ++++++------ drivers/dma/mv_xor.c | 62 ++++++++---------- drivers/gpu/drm/gma500/cdv_intel_crt.c | 3 +- drivers/gpu/drm/gma500/cdv_intel_lvds.c | 7 +- drivers/gpu/drm/gma500/psb_intel_lvds.c | 7 +- drivers/gpu/drm/i915/intel_opregion.c | 8 +- drivers/i2c/busses/i2c-piix4.c | 5 +- drivers/net/ethernet/chelsio/cxgb3/common.h | 7 +- drivers/net/ethernet/marvell/pxa168_eth.c | 7 +- drivers/net/wireless/at76c50x-usb.c | 85 +++++++++++------------ drivers/net/wireless/iwlegacy/common.h | 5 +- drivers/net/wireless/iwlwifi/pcie/trans.c | 28 +++----- drivers/pci/irq.c | 10 ++-- drivers/pci/pci-stub.c | 2 +- drivers/pci/pcie/aspm.c | 7 +-- drivers/pcmcia/cistpl.c | 10 +-- drivers/pcmcia/cs.c | 28 +++----- drivers/pcmcia/ds.c | 38 +++++------ drivers/pcmcia/pcmcia_cis.c | 4 +- drivers/pcmcia/pcmcia_resource.c | 11 +-- drivers/pcmcia/rsrc_nonstatic.c | 24 +++---- drivers/pcmcia/ti113x.h | 80 +++++++++++------------ drivers/pcmcia/yenta_socket.c | 61 ++++++++--------- drivers/scsi/53c700.c | 2 +- drivers/scsi/aic7xxx/aic79xx_osm_pci.c | 4 +- drivers/scsi/aic7xxx/aic7xxx_osm_pci.c | 4 +- drivers/scsi/aic94xx/aic94xx_tmf.c | 4 +- drivers/scsi/bfa/bfad.c | 32 ++++----- drivers/scsi/fcoe/fcoe_sysfs.c | 3 +- drivers/scsi/lasi700.c | 2 +- drivers/scsi/libsas/sas_task.c | 9 +-- drivers/scsi/lpfc/lpfc_attr.c | 8 +- drivers/scsi/lpfc/lpfc_debugfs.h | 6 +- drivers/scsi/lpfc/lpfc_hbadisc.c | 4 +- drivers/scsi/lpfc/lpfc_init.c | 45 ++++++------- drivers/scsi/mpt2sas/mpt2sas_transport.c | 91 ++++++++++++------------- drivers/scsi/mvsas/mv_64xx.c | 2 +- drivers/scsi/mvsas/mv_chips.h | 8 +- drivers/scsi/mvsas/mv_init.c | 14 ++-- drivers/scsi/mvsas/mv_sas.c | 9 +-- drivers/scsi/pm8001/pm8001_init.c | 10 +-- drivers/scsi/pm8001/pm8001_sas.c | 4 +- drivers/scsi/raid_class.c | 8 +- drivers/scsi/scsi_scan.c | 3 +- drivers/scsi/scsi_transport_fc.c | 31 ++++----- drivers/scsi/scsi_transport_sas.c | 7 +- drivers/scsi/sni_53c710.c | 2 +- drivers/scsi/zalon.c | 4 +- drivers/usb/core/hub.c | 2 +- drivers/virtio/virtio_balloon.c | 7 +- drivers/watchdog/mpcore_wdt.c | 19 +++--- sound/pci/asihpi/hpidspcd.c | 22 +++---- sound/pci/asihpi/hpioctl.c | 17 ++--- 60 files changed, 485 insertions(+), 579 deletions(-) -- 1.7.8.112.g3fd21

2 2

[alsa-devel] ASoC updates for v3.7
by Mark Brown 28 Oct '12

28 Oct '12

The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-3.7 for you to fetch changes up to 19118eb8dc3cd6bb1b1fdf0e4ad62070c6683158: ASoC: omap-dmic: Correct functional clock name (2012-10-27 23:00:18 +0100) ---------------------------------------------------------------- ASoC: Fixes for v3.7 Clean up some fallout from the OMAP header reorganisation and a minor fix for DMIC which has no practical effect but is neater. ---------------------------------------------------------------- Peter Ujfalusi (1): ASoC: omap-dmic: Correct functional clock name Tony Lindgren (1): ASoC: zoom2: Fix compile error by including correct header files sound/soc/omap/omap-dmic.c | 4 ++-- sound/soc/omap/zoom2.c | 5 ++--- 2 files changed, 4 insertions(+), 5 deletions(-)

2 1

[alsa-devel] [asoc:topic/adsp] make[4]: *** No rule to make target `sound/soc/codecs/snd-soc-wm-adsp.c', needed by `sound/soc/codecs/snd-soc-wm-adsp.o'.
by Fengguang Wu 28 Oct '12

28 Oct '12

Hi Mark, FYI, kernel build failed on tree: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/adsp config: x86_64-allmodconfig # make ARCH=x86_64 allmodconfig All error/warnings: make[4]: *** [sound/soc/codecs/wm2200.o] Error 1 make[4]: *** No rule to make target `sound/soc/codecs/snd-soc-wm-adsp.c', needed by `sound/soc/codecs/snd-soc-wm-adsp.o'. make[4]: Target `__build' not remade because of errors. --- 0-DAY kernel build testing backend Open Source Technology Center Fengguang Wu, Yuanhan Liu Intel Corporation

1 0

[alsa-devel] [asoc:topic/adsp 33/33] sound/soc/codecs/wm2200.c:2555:10: sparse: unknown field name in initializer
by Fengguang Wu 28 Oct '12

28 Oct '12

Hi Mark, Errors in tree: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/adsp sound/soc/codecs/wm2200.c:2555:10: sparse: unknown field name in initializer sound/soc/codecs/wm2200.c:2555:2: error: unknown field 'num_ranges' specified in initializer vim +2555 sound/soc/codecs/wm2200.c d5315a23 Mark Brown 2012-01-25 2543 static const struct regmap_config wm2200_regmap = { d5315a23 Mark Brown 2012-01-25 2544 .reg_bits = 16, d5315a23 Mark Brown 2012-01-25 2545 .val_bits = 16, d5315a23 Mark Brown 2012-01-25 2546 eae2328d Mark Brown 2012-10-02 2547 .max_register = WM2200_MAX_REGISTER + (ARRAY_SIZE(wm2200_ranges) * eae2328d Mark Brown 2012-10-02 2548 WM2200_DSP_SPACING), d5315a23 Mark Brown 2012-01-25 2549 .reg_defaults = wm2200_reg_defaults, d5315a23 Mark Brown 2012-01-25 2550 .num_reg_defaults = ARRAY_SIZE(wm2200_reg_defaults), d5315a23 Mark Brown 2012-01-25 2551 .volatile_reg = wm2200_volatile_register, d5315a23 Mark Brown 2012-01-25 2552 .readable_reg = wm2200_readable_register, d5315a23 Mark Brown 2012-01-25 2553 .cache_type = REGCACHE_RBTREE, eae2328d Mark Brown 2012-10-02 2554 .ranges = wm2200_ranges, eae2328d Mark Brown 2012-10-02 @2555 .num_ranges = ARRAY_SIZE(wm2200_ranges), It seems eae2328d introduced the .num_ranges reference while struct regmap_config only defined: const struct regmap_range_cfg *ranges; unsigned int n_ranges; }; Thanks, Fengguang

1 0

[alsa-devel] [PATCH] ASoC: omap-dmic: Correct functional clock name
by Peter Ujfalusi 28 Oct '12

28 Oct '12

We should really use "fck" when asking for the functional clock and not "dmic_fck". This way we can ensure that multiple dmic modules can exist in the system. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- Hi Mark, Liam, Would it be possible to send this patch for 3.7 as a fix? The DMIC driver works withoput this patch but we ask for the functional clock using the wrong name. Thanks, Peter sound/soc/omap/omap-dmic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c index 68f2cd1..5a6aeaf 100644 --- a/sound/soc/omap/omap-dmic.c +++ b/sound/soc/omap/omap-dmic.c @@ -464,9 +464,9 @@ static __devinit int asoc_dmic_probe(struct platform_device *pdev) mutex_init(&dmic->mutex); - dmic->fclk = clk_get(dmic->dev, "dmic_fck"); + dmic->fclk = clk_get(dmic->dev, "fck"); if (IS_ERR(dmic->fclk)) { - dev_err(dmic->dev, "cant get dmic_fck\n"); + dev_err(dmic->dev, "cant get fck\n"); return -ENODEV; } -- 1.7.12.4

2 1

Re: [alsa-devel] [PATCH 3.7-rc1] omap zoom2.c: Fix compile error by including correct header files
by Peter Ujfalusi 27 Oct '12

27 Oct '12

On 10/03/2012 05:31 PM, Tim Gardner wrote: > Cc: Peter Ujfalusi <peter.ujfalusi(a)ti.com> > Cc: Jarkko Nikula <jarkko.nikula(a)bitmer.com> > Cc: Liam Girdwood <lrg(a)ti.com> > Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> > Cc: Jaroslav Kysela <perex(a)perex.cz> > Cc: Takashi Iwai <tiwai(a)suse.de> > Cc: linux-omap(a)vger.kernel.org > Cc: alsa-devel(a)alsa-project.org > Signed-off-by: Tim Gardner <tim.gardner(a)canonical.com> > --- > sound/soc/omap/zoom2.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/sound/soc/omap/zoom2.c b/sound/soc/omap/zoom2.c > index 23de2b2..d0a8c92 100644 > --- a/sound/soc/omap/zoom2.c > +++ b/sound/soc/omap/zoom2.c > @@ -27,9 +27,10 @@ > > #include <asm/mach-types.h> > #include <mach/hardware.h> > -#include <mach/gpio.h> > +#include <linux/gpio.h> > #include <mach/board-zoom.h> > #include <linux/platform_data/asoc-ti-mcbsp.h> > +#include <linux/platform_data/gpio-omap.h> > > /* Register descriptions for twl4030 codec part */ > #include <linux/mfd/twl4030-audio.h> > I have the same patch stashed away for the same issue. Was waiting for rc1 to send it. Acked-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com>

3 3

[alsa-devel] [PATCH 1/3] ASoC: jz4740-codec: Add dB information
by Lars-Peter Clausen 27 Oct '12

27 Oct '12

Add dB TLV ranges for the various volume controls. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- sound/soc/codecs/jz4740.c | 25 +++++++++++++++++++------ 1 files changed, 19 insertions(+), 6 deletions(-) diff --git a/sound/soc/codecs/jz4740.c b/sound/soc/codecs/jz4740.c index 85d9cab..51b4f99 100644 --- a/sound/soc/codecs/jz4740.c +++ b/sound/soc/codecs/jz4740.c @@ -24,6 +24,7 @@ #include <sound/pcm_params.h> #include <sound/initval.h> #include <sound/soc.h> +#include <sound/tlv.h> #define JZ4740_REG_CODEC_1 0x0 #define JZ4740_REG_CODEC_2 0x1 @@ -95,15 +96,27 @@ static int jz4740_codec_write(struct snd_soc_codec *codec, unsigned int reg, return 0; } +static const unsigned int jz4740_mic_tlv[] = { + TLV_DB_RANGE_HEAD(2), + 0, 2, TLV_DB_SCALE_ITEM(0, 600, 0), + 3, 3, TLV_DB_SCALE_ITEM(2000, 0, 0), +}; + +static const DECLARE_TLV_DB_SCALE(jz4740_out_tlv, 0, 200, 0); +static const DECLARE_TLV_DB_SCALE(jz4740_in_tlv, -3450, 150, 0); + static const struct snd_kcontrol_new jz4740_codec_controls[] = { - SOC_SINGLE("Master Playback Volume", JZ4740_REG_CODEC_2, - JZ4740_CODEC_2_HEADPHONE_VOLUME_OFFSET, 3, 0), - SOC_SINGLE("Master Capture Volume", JZ4740_REG_CODEC_2, - JZ4740_CODEC_2_INPUT_VOLUME_OFFSET, 31, 0), + SOC_SINGLE_TLV("Master Playback Volume", JZ4740_REG_CODEC_2, + JZ4740_CODEC_2_HEADPHONE_VOLUME_OFFSET, 3, 0, + jz4740_out_tlv), + SOC_SINGLE_TLV("Master Capture Volume", JZ4740_REG_CODEC_2, + JZ4740_CODEC_2_INPUT_VOLUME_OFFSET, 31, 0, + jz4740_in_tlv), SOC_SINGLE("Master Playback Switch", JZ4740_REG_CODEC_1, JZ4740_CODEC_1_HEADPHONE_DISABLE_OFFSET, 1, 1), - SOC_SINGLE("Mic Capture Volume", JZ4740_REG_CODEC_2, - JZ4740_CODEC_2_MIC_BOOST_GAIN_OFFSET, 3, 0), + SOC_SINGLE_TLV("Mic Capture Volume", JZ4740_REG_CODEC_2, + JZ4740_CODEC_2_MIC_BOOST_GAIN_OFFSET, 3, 0, + jz4740_mic_tlv), }; static const struct snd_kcontrol_new jz4740_codec_output_controls[] = { -- 1.7.2.5

2 3

[alsa-devel] [asoc:topic/wm2200 37/37] ERROR: "wm_adsp1_event" undefined!
by Fengguang Wu 26 Oct '12

26 Oct '12

Hi Mark, FYI, kernel build failed on tree: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/wm2200 head: 21ee496ffc650f79c85ae318321a9d961e240738 commit: 21ee496ffc650f79c85ae318321a9d961e240738 [37/37] ASoC: wm2200: Convert over to wm_adsp for ADSP1 support config: x86_64-allmodconfig # make ARCH=x86_64 allmodconfig All error/warnings: ERROR: "wm_adsp1_event" undefined! --- 0-DAY kernel build testing backend Open Source Technology Center Fengguang Wu, Yuanhan Liu Intel Corporation

1 0

[alsa-devel] [PATCH 1/4] ASoC: adsp: Add ADSP base support
by Mark Brown 26 Oct '12

26 Oct '12

Many current Wolfson devices feature DSPs based around an architecture known as ADSP. Since there is a lot of commonality in the system integration of these devices a common library will be used to provide support for them. This version provides equivalent support for ADSP1 to that currently included in the WM2200 driver. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/Kconfig | 5 + sound/soc/codecs/Makefile | 1 + sound/soc/codecs/wm_adsp.c | 571 ++++++++++++++++++++++++++++++++++++++++++++ sound/soc/codecs/wm_adsp.h | 54 +++++ sound/soc/codecs/wmfw.h | 29 +++ 5 files changed, 660 insertions(+) create mode 100644 sound/soc/codecs/wm_adsp.c create mode 100644 sound/soc/codecs/wm_adsp.h diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig index 6f4f284..91cbbe0 100644 --- a/sound/soc/codecs/Kconfig +++ b/sound/soc/codecs/Kconfig @@ -147,6 +147,11 @@ config SND_SOC_WM_HUBS default y if SND_SOC_WM8993=y || SND_SOC_WM8994=y default m if SND_SOC_WM8993=m || SND_SOC_WM8994=m +config SND_SOC_WM_ADSP + tristate + default y if SND_SOC_WM2200=y + default m if SND_SOC_WM2200=m + config SND_SOC_AB8500_CODEC tristate diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile index c55d2d7..ffbed85 100644 --- a/sound/soc/codecs/Makefile +++ b/sound/soc/codecs/Makefile @@ -63,6 +63,7 @@ snd-soc-twl6040-objs := twl6040.o snd-soc-uda134x-objs := uda134x.o snd-soc-uda1380-objs := uda1380.o snd-soc-wl1273-objs := wl1273.o +snd-soc-wm-adsp := wm_adsp.o snd-soc-wm0010-objs := wm0010.o snd-soc-wm1250-ev1-objs := wm1250-ev1.o snd-soc-wm2000-objs := wm2000.o diff --git a/sound/soc/codecs/wm_adsp.c b/sound/soc/codecs/wm_adsp.c new file mode 100644 index 0000000..c72d3fa --- /dev/null +++ b/sound/soc/codecs/wm_adsp.c @@ -0,0 +1,571 @@ +/* + * wm_adsp.c -- Wolfson ADSP support + * + * Copyright 2012 Wolfson Microelectronics plc + * + * Author: Mark Brown <broonie(a)opensource.wolfsonmicro.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include <linux/module.h> +#include <linux/moduleparam.h> +#include <linux/init.h> +#include <linux/delay.h> +#include <linux/firmware.h> +#include <linux/pm.h> +#include <linux/pm_runtime.h> +#include <linux/regmap.h> +#include <linux/slab.h> +#include <sound/core.h> +#include <sound/pcm.h> +#include <sound/pcm_params.h> +#include <sound/soc.h> +#include <sound/jack.h> +#include <sound/initval.h> +#include <sound/tlv.h> + +#include <linux/mfd/arizona/registers.h> + +#include "wm_adsp.h" + +#define adsp_crit(_dsp, fmt, ...) \ + dev_crit(_dsp->dev, "DSP%d: " fmt, _dsp->num, ##__VA_ARGS__) +#define adsp_err(_dsp, fmt, ...) \ + dev_err(_dsp->dev, "DSP%d: " fmt, _dsp->num, ##__VA_ARGS__) +#define adsp_warn(_dsp, fmt, ...) \ + dev_warn(_dsp->dev, "DSP%d: " fmt, _dsp->num, ##__VA_ARGS__) +#define adsp_info(_dsp, fmt, ...) \ + dev_info(_dsp->dev, "DSP%d: " fmt, _dsp->num, ##__VA_ARGS__) +#define adsp_dbg(_dsp, fmt, ...) \ + dev_dbg(_dsp->dev, "DSP%d: " fmt, _dsp->num, ##__VA_ARGS__) + +#define ADSP1_CONTROL_1 0x00 +#define ADSP1_CONTROL_2 0x02 +#define ADSP1_CONTROL_3 0x03 +#define ADSP1_CONTROL_4 0x04 +#define ADSP1_CONTROL_5 0x06 +#define ADSP1_CONTROL_6 0x07 +#define ADSP1_CONTROL_7 0x08 +#define ADSP1_CONTROL_8 0x09 +#define ADSP1_CONTROL_9 0x0A +#define ADSP1_CONTROL_10 0x0B +#define ADSP1_CONTROL_11 0x0C +#define ADSP1_CONTROL_12 0x0D +#define ADSP1_CONTROL_13 0x0F +#define ADSP1_CONTROL_14 0x10 +#define ADSP1_CONTROL_15 0x11 +#define ADSP1_CONTROL_16 0x12 +#define ADSP1_CONTROL_17 0x13 +#define ADSP1_CONTROL_18 0x14 +#define ADSP1_CONTROL_19 0x16 +#define ADSP1_CONTROL_20 0x17 +#define ADSP1_CONTROL_21 0x18 +#define ADSP1_CONTROL_22 0x1A +#define ADSP1_CONTROL_23 0x1B +#define ADSP1_CONTROL_24 0x1C +#define ADSP1_CONTROL_25 0x1E +#define ADSP1_CONTROL_26 0x20 +#define ADSP1_CONTROL_27 0x21 +#define ADSP1_CONTROL_28 0x22 +#define ADSP1_CONTROL_29 0x23 +#define ADSP1_CONTROL_30 0x24 +#define ADSP1_CONTROL_31 0x26 + +/* + * ADSP1 Control 19 + */ +#define ADSP1_WDMA_BUFFER_LENGTH_MASK 0x00FF /* DSP1_WDMA_BUFFER_LENGTH - [7:0] */ +#define ADSP1_WDMA_BUFFER_LENGTH_SHIFT 0 /* DSP1_WDMA_BUFFER_LENGTH - [7:0] */ +#define ADSP1_WDMA_BUFFER_LENGTH_WIDTH 8 /* DSP1_WDMA_BUFFER_LENGTH - [7:0] */ + + +/* + * ADSP1 Control 30 + */ +#define ADSP1_DBG_CLK_ENA 0x0008 /* DSP1_DBG_CLK_ENA */ +#define ADSP1_DBG_CLK_ENA_MASK 0x0008 /* DSP1_DBG_CLK_ENA */ +#define ADSP1_DBG_CLK_ENA_SHIFT 3 /* DSP1_DBG_CLK_ENA */ +#define ADSP1_DBG_CLK_ENA_WIDTH 1 /* DSP1_DBG_CLK_ENA */ +#define ADSP1_SYS_ENA 0x0004 /* DSP1_SYS_ENA */ +#define ADSP1_SYS_ENA_MASK 0x0004 /* DSP1_SYS_ENA */ +#define ADSP1_SYS_ENA_SHIFT 2 /* DSP1_SYS_ENA */ +#define ADSP1_SYS_ENA_WIDTH 1 /* DSP1_SYS_ENA */ +#define ADSP1_CORE_ENA 0x0002 /* DSP1_CORE_ENA */ +#define ADSP1_CORE_ENA_MASK 0x0002 /* DSP1_CORE_ENA */ +#define ADSP1_CORE_ENA_SHIFT 1 /* DSP1_CORE_ENA */ +#define ADSP1_CORE_ENA_WIDTH 1 /* DSP1_CORE_ENA */ +#define ADSP1_START 0x0001 /* DSP1_START */ +#define ADSP1_START_MASK 0x0001 /* DSP1_START */ +#define ADSP1_START_SHIFT 0 /* DSP1_START */ +#define ADSP1_START_WIDTH 1 /* DSP1_START */ + +#define ADSP2_CONTROL 0 +#define ADSP2_STATUS1 4 + +/* + * ADSP2 Control + */ + +#define ADSP2_MEM_ENA 0x0010 /* DSP1_MEM_ENA */ +#define ADSP2_MEM_ENA_MASK 0x0010 /* DSP1_MEM_ENA */ +#define ADSP2_MEM_ENA_SHIFT 4 /* DSP1_MEM_ENA */ +#define ADSP2_MEM_ENA_WIDTH 1 /* DSP1_MEM_ENA */ +#define ADSP2_SYS_ENA 0x0004 /* DSP1_SYS_ENA */ +#define ADSP2_SYS_ENA_MASK 0x0004 /* DSP1_SYS_ENA */ +#define ADSP2_SYS_ENA_SHIFT 2 /* DSP1_SYS_ENA */ +#define ADSP2_SYS_ENA_WIDTH 1 /* DSP1_SYS_ENA */ +#define ADSP2_CORE_ENA 0x0002 /* DSP1_CORE_ENA */ +#define ADSP2_CORE_ENA_MASK 0x0002 /* DSP1_CORE_ENA */ +#define ADSP2_CORE_ENA_SHIFT 1 /* DSP1_CORE_ENA */ +#define ADSP2_CORE_ENA_WIDTH 1 /* DSP1_CORE_ENA */ +#define ADSP2_START 0x0001 /* DSP1_START */ +#define ADSP2_START_MASK 0x0001 /* DSP1_START */ +#define ADSP2_START_SHIFT 0 /* DSP1_START */ +#define ADSP2_START_WIDTH 1 /* DSP1_START */ + +/* + * ADSP2 Status 1 + */ +#define ADSP2_RAM_RDY 0x0001 +#define ADSP2_RAM_RDY_MASK 0x0001 +#define ADSP2_RAM_RDY_SHIFT 0 +#define ADSP2_RAM_RDY_WIDTH 1 + + +static struct wm_adsp_region const *wm_adsp_find_region(struct wm_adsp *dsp, + int type) +{ + int i; + + for (i = 0; i < dsp->num_mems; i++) + if (dsp->mem[i].type == type) + return &dsp->mem[i]; + + return NULL; +} + +static int wm_adsp_load(struct wm_adsp *dsp) +{ + const struct firmware *firmware; + struct regmap *regmap = dsp->regmap; + unsigned int pos = 0; + const struct wmfw_header *header; + const struct wmfw_adsp1_sizes *adsp1_sizes; + const struct wmfw_adsp2_sizes *adsp2_sizes; + const struct wmfw_footer *footer; + const struct wmfw_region *region; + const struct wm_adsp_region *mem; + const char *region_name; + char *file, *text; + unsigned int reg; + int regions = 0; + int ret, offset, type, sizes; + + file = kzalloc(PAGE_SIZE, GFP_KERNEL); + if (file == NULL) + return -ENOMEM; + + snprintf(file, PAGE_SIZE, "%s-dsp%d.wmfw", dsp->part, dsp->num); + file[PAGE_SIZE - 1] = '\0'; + + ret = request_firmware(&firmware, file, dsp->dev); + if (ret != 0) { + adsp_err(dsp, "Failed to request '%s'\n", file); + goto out; + } + ret = -EINVAL; + + pos = sizeof(*header) + sizeof(*adsp1_sizes) + sizeof(*footer); + if (pos >= firmware->size) { + adsp_err(dsp, "%s: file too short, %zu bytes\n", + file, firmware->size); + goto out_fw; + } + + header = (void*)&firmware->data[0]; + + if (memcmp(&header->magic[0], "WMFW", 4) != 0) { + adsp_err(dsp, "%s: invalid magic\n", file); + goto out_fw; + } + + if (header->ver != 0) { + adsp_err(dsp, "%s: unknown file format %d\n", + file, header->ver); + goto out_fw; + } + + if (header->core != dsp->type) { + adsp_err(dsp, "%s: invalid core %d != %d\n", + file, header->core, dsp->type); + goto out_fw; + } + + switch (dsp->type) { + case WMFW_ADSP1: + pos = sizeof(*header) + sizeof(*adsp1_sizes) + sizeof(*footer); + adsp1_sizes = (void *)&(header[1]); + footer = (void *)&(adsp1_sizes[1]); + sizes = sizeof(*adsp1_sizes); + + adsp_dbg(dsp, "%s: %d DM, %d PM, %d ZM\n", + file, le32_to_cpu(adsp1_sizes->dm), + le32_to_cpu(adsp1_sizes->pm), + le32_to_cpu(adsp1_sizes->zm)); + break; + + case WMFW_ADSP2: + pos = sizeof(*header) + sizeof(*adsp2_sizes) + sizeof(*footer); + adsp2_sizes = (void *)&(header[1]); + footer = (void *)&(adsp2_sizes[1]); + sizes = sizeof(*adsp2_sizes); + + adsp_dbg(dsp, "%s: %d XM, %d YM %d PM, %d ZM\n", + file, le32_to_cpu(adsp2_sizes->xm), + le32_to_cpu(adsp2_sizes->ym), + le32_to_cpu(adsp2_sizes->pm), + le32_to_cpu(adsp2_sizes->zm)); + break; + + default: + BUG_ON(NULL == "Unknown DSP type"); + goto out_fw; + } + + if (le32_to_cpu(header->len) != sizeof(*header) + + sizes + sizeof(*footer)) { + adsp_err(dsp, "%s: unexpected header length %d\n", + file, le32_to_cpu(header->len)); + goto out_fw; + } + + adsp_dbg(dsp, "%s: timestamp %llu\n", file, + le64_to_cpu(footer->timestamp)); + + while (pos < firmware->size && + pos - firmware->size > sizeof(*region)) { + region = (void *)&(firmware->data[pos]); + region_name = "Unknown"; + reg = 0; + text = NULL; + offset = le32_to_cpu(region->offset) & 0xffffff; + type = be32_to_cpu(region->type) & 0xff; + mem = wm_adsp_find_region(dsp, type); + + switch (type) { + case WMFW_NAME_TEXT: + region_name = "Firmware name"; + text = kzalloc(le32_to_cpu(region->len) + 1, + GFP_KERNEL); + break; + case WMFW_INFO_TEXT: + region_name = "Information"; + text = kzalloc(le32_to_cpu(region->len) + 1, + GFP_KERNEL); + break; + case WMFW_ABSOLUTE: + region_name = "Absolute"; + reg = offset; + break; + case WMFW_ADSP1_PM: + BUG_ON(!mem); + region_name = "PM"; + reg = mem->base + (offset * 3); + break; + case WMFW_ADSP1_DM: + BUG_ON(!mem); + region_name = "DM"; + reg = mem->base + (offset * 2); + break; + case WMFW_ADSP2_XM: + BUG_ON(!mem); + region_name = "XM"; + reg = mem->base + (offset * 2); + break; + case WMFW_ADSP2_YM: + BUG_ON(!mem); + region_name = "YM"; + reg = mem->base + (offset * 2); + break; + case WMFW_ADSP1_ZM: + BUG_ON(!mem); + region_name = "ZM"; + reg = mem->base + (offset * 2); + break; + default: + adsp_warn(dsp, + "%s.%d: Unknown region type %x at %d(%x)\n", + file, regions, type, pos, pos); + break; + } + + adsp_dbg(dsp, "%s.%d: %d bytes at %d in %s\n", file, + regions, le32_to_cpu(region->len), offset, + region_name); + + if (text) { + memcpy(text, region->data, le32_to_cpu(region->len)); + adsp_info(dsp, "%s: %s\n", file, text); + kfree(text); + } + + if (reg) { + ret = regmap_raw_write(regmap, reg, region->data, + le32_to_cpu(region->len)); + if (ret != 0) { + adsp_err(dsp, + "%s.%d: Failed to write %d bytes at %d in %s: %d\n", + file, regions, + le32_to_cpu(region->len), offset, + region_name, ret); + goto out_fw; + } + } + + pos += le32_to_cpu(region->len) + sizeof(*region); + regions++; + } + + if (pos > firmware->size) + adsp_warn(dsp, "%s.%d: %zu bytes at end of file\n", + file, regions, pos - firmware->size); + +out_fw: + release_firmware(firmware); +out: + kfree(file); + + return ret; +} + +static int wm_adsp_load_coeff(struct wm_adsp *dsp) +{ + struct regmap *regmap = dsp->regmap; + struct wmfw_coeff_hdr *hdr; + struct wmfw_coeff_item *blk; + const struct firmware *firmware; + const char *region_name; + int ret, pos, blocks, type, offset, reg; + char *file; + + file = kzalloc(PAGE_SIZE, GFP_KERNEL); + if (file == NULL) + return -ENOMEM; + + snprintf(file, PAGE_SIZE, "%s-dsp%d.bin", dsp->part, dsp->num); + file[PAGE_SIZE - 1] = '\0'; + + ret = request_firmware(&firmware, file, dsp->dev); + if (ret != 0) { + adsp_warn(dsp, "Failed to request '%s'\n", file); + ret = 0; + goto out; + } + ret = -EINVAL; + + if (sizeof(*hdr) >= firmware->size) { + adsp_err(dsp, "%s: file too short, %zu bytes\n", + file, firmware->size); + goto out_fw; + } + + hdr = (void*)&firmware->data[0]; + if (memcmp(hdr->magic, "WMDR", 4) != 0) { + adsp_err(dsp, "%s: invalid magic\n", file); + return -EINVAL; + } + + adsp_dbg(dsp, "%s: v%d.%d.%d\n", file, + (le32_to_cpu(hdr->ver) >> 16) & 0xff, + (le32_to_cpu(hdr->ver) >> 8) & 0xff, + le32_to_cpu(hdr->ver) & 0xff); + + pos = le32_to_cpu(hdr->len); + + blocks = 0; + while (pos < firmware->size && + pos - firmware->size > sizeof(*blk)) { + blk = (void*)(&firmware->data[pos]); + + type = be32_to_cpu(blk->type) & 0xff; + offset = le32_to_cpu(blk->offset) & 0xffffff; + + adsp_dbg(dsp, "%s.%d: %x v%d.%d.%d\n", + file, blocks, le32_to_cpu(blk->id), + (le32_to_cpu(blk->ver) >> 16) & 0xff, + (le32_to_cpu(blk->ver) >> 8) & 0xff, + le32_to_cpu(blk->ver) & 0xff); + adsp_dbg(dsp, "%s.%d: %d bytes at 0x%x in %x\n", + file, blocks, le32_to_cpu(blk->len), offset, type); + + reg = 0; + region_name = "Unknown"; + switch (type) { + case WMFW_NAME_TEXT: + case WMFW_INFO_TEXT: + break; + case WMFW_ABSOLUTE: + region_name = "register"; + reg = offset; + break; + default: + adsp_err(dsp, "Unknown region type %x\n", type); + break; + } + + if (reg) { + ret = regmap_raw_write(regmap, reg, blk->data, + le32_to_cpu(blk->len)); + if (ret != 0) { + adsp_err(dsp, + "%s.%d: Failed to write to %x in %s\n", + file, blocks, reg, region_name); + } + } + + pos += le32_to_cpu(blk->len) + sizeof(*blk); + blocks++; + } + + if (pos > firmware->size) + adsp_warn(dsp, "%s.%d: %zu bytes at end of file\n", + file, blocks, pos - firmware->size); + +out_fw: + release_firmware(firmware); +out: + kfree(file); + return 0; +} + +int wm_adsp1_event(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *kcontrol, + int event) +{ + struct snd_soc_codec *codec = w->codec; + struct wm_adsp *dsps = snd_soc_codec_get_drvdata(codec); + struct wm_adsp *dsp = &dsps[w->shift]; + int ret; + + switch (event) { + case SND_SOC_DAPM_POST_PMU: + regmap_update_bits(dsp->regmap, dsp->base + ADSP1_CONTROL_30, + ADSP1_SYS_ENA, ADSP1_SYS_ENA); + + ret = wm_adsp_load(dsp); + if (ret != 0) + goto err; + + ret = wm_adsp_load_coeff(dsp); + if (ret != 0) + goto err; + + /* Start the core running */ + regmap_update_bits(dsp->regmap, dsp->base + ADSP1_CONTROL_30, + ADSP1_CORE_ENA | ADSP1_START, + ADSP1_CORE_ENA | ADSP1_START); + break; + + case SND_SOC_DAPM_PRE_PMD: + /* Halt the core */ + regmap_update_bits(dsp->regmap, dsp->base + ADSP1_CONTROL_30, + ADSP1_CORE_ENA | ADSP1_START, 0); + + regmap_update_bits(dsp->regmap, dsp->base + ADSP1_CONTROL_19, + ADSP1_WDMA_BUFFER_LENGTH_MASK, 0); + + regmap_update_bits(dsp->regmap, dsp->base + ADSP1_CONTROL_30, + ADSP1_SYS_ENA, 0); + break; + + default: + break; + } + + return 0; + +err: + regmap_update_bits(dsp->regmap, dsp->base + ADSP1_CONTROL_30, + ADSP1_SYS_ENA, 0); + return ret; +} +EXPORT_SYMBOL_GPL(wm_adsp1_event); + +static int wm_adsp2_ena(struct wm_adsp *dsp) +{ + unsigned int val; + int ret, count; + + ret = regmap_update_bits(dsp->regmap, dsp->base + ADSP2_CONTROL, + ADSP2_SYS_ENA, ADSP2_SYS_ENA); + if (ret != 0) + return ret; + + /* Wait for the RAM to start, should be near instantaneous */ + count = 0; + do { + ret = regmap_read(dsp->regmap, dsp->base + ADSP2_STATUS1, + &val); + if (ret != 0) + return ret; + } while (!(val & ADSP2_RAM_RDY) && ++count < 10); + + if (!(val & ADSP2_RAM_RDY)) { + adsp_err(dsp, "Failed to start DSP RAM\n"); + return -EBUSY; + } + + adsp_dbg(dsp, "RAM ready after %d polls\n", count); + adsp_info(dsp, "RAM ready after %d polls\n", count); + + return 0; +} + +int wm_adsp2_event(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *kcontrol, int event) +{ + struct snd_soc_codec *codec = w->codec; + struct wm_adsp *dsps = snd_soc_codec_get_drvdata(codec); + struct wm_adsp *dsp = &dsps[w->shift]; + int ret; + + switch (event) { + case SND_SOC_DAPM_POST_PMU: + ret = wm_adsp2_ena(dsp); + if (ret != 0) + return ret; + + ret = wm_adsp_load(dsp); + if (ret != 0) + goto err; + + ret = wm_adsp_load_coeff(dsp); + if (ret != 0) + goto err; + + ret = regmap_update_bits(dsp->regmap, + dsp->base + ADSP2_CONTROL, + ADSP2_SYS_ENA | ADSP2_START, 0); + if (ret != 0) + goto err; + break; + + case SND_SOC_DAPM_PRE_PMD: + regmap_update_bits(dsp->regmap, dsp->base + ADSP2_CONTROL, + ADSP2_SYS_ENA | ADSP2_START, 0); + break; + + default: + break; + } + + return 0; +err: + regmap_update_bits(dsp->regmap, dsp->base + ADSP2_CONTROL, + ADSP2_SYS_ENA | ADSP2_START, 0); + return ret; +} +EXPORT_SYMBOL_GPL(wm_adsp2_event); diff --git a/sound/soc/codecs/wm_adsp.h b/sound/soc/codecs/wm_adsp.h new file mode 100644 index 0000000..b303b1f --- /dev/null +++ b/sound/soc/codecs/wm_adsp.h @@ -0,0 +1,54 @@ +/* + * wm_adsp.h -- Wolfson ADSP support + * + * Copyright 2012 Wolfson Microelectronics plc + * + * Author: Mark Brown <broonie(a)opensource.wolfsonmicro.com> + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef __WM_ADSP_H +#define __WM_ADSP_H + +#include <sound/soc.h> +#include <sound/soc-dapm.h> + +#include "wmfw.h" + +struct wm_adsp_region { + int type; + unsigned int base; +}; + +struct wm_adsp { + const char *part; + int num; + int type; + struct device *dev; + struct regmap *regmap; + + int base; + + const struct wm_adsp_region *mem; + int num_mems; +}; + +#define WM_ADSP1(wname, num) \ + { .id = snd_soc_dapm_pga, .name = wname, .reg = SND_SOC_NOPM, \ + .shift = num, .event = wm_adsp1_event, \ + .event_flags = SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD } + +#define WM_ADSP2(wname, num) \ +{ .id = snd_soc_dapm_pga, .name = wname, .reg = SND_SOC_NOPM, \ + .shift = num, .event = wm_adsp2_event, \ + .event_flags = SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_PRE_PMD } + +int wm_adsp1_event(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *kcontrol, int event); +int wm_adsp2_event(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *kcontrol, int event); + +#endif diff --git a/sound/soc/codecs/wmfw.h b/sound/soc/codecs/wmfw.h index 5791f8e..5632ded 100644 --- a/sound/soc/codecs/wmfw.h +++ b/sound/soc/codecs/wmfw.h @@ -34,6 +34,13 @@ struct wmfw_adsp1_sizes { __le32 zm; } __packed; +struct wmfw_adsp2_sizes { + __le32 xm; + __le32 ym; + __le32 pm; + __le32 zm; +} __packed; + struct wmfw_region { union { __be32 type; @@ -57,6 +64,14 @@ struct wmfw_adsp1_id_hdr { __be32 algs; } __packed; +struct wmfw_adsp2_id_hdr { + struct wmfw_id_hdr fw; + __be32 zm; + __be32 xm; + __be32 ym; + __be32 algs; +} __packed; + struct wmfw_alg_hdr { __be32 id; __be32 ver; @@ -68,6 +83,13 @@ struct wmfw_adsp1_alg_hdr { __be32 dm; } __packed; +struct wmfw_adsp2_alg_hdr { + struct wmfw_alg_hdr alg; + __be32 zm; + __be32 xm; + __be32 ym; +} __packed; + struct wmfw_coeff_hdr { u8 magic[4]; __le32 len; @@ -86,7 +108,9 @@ struct wmfw_coeff_item { __le32 len; u8 data[]; } __packed; + #define WMFW_ADSP1 1 +#define WMFW_ADSP2 2 #define WMFW_ABSOLUTE 0xf0 #define WMFW_NAME_TEXT 0xfe @@ -96,4 +120,9 @@ struct wmfw_coeff_item { #define WMFW_ADSP1_DM 3 #define WMFW_ADSP1_ZM 4 +#define WMFW_ADSP2_PM 2 +#define WMFW_ADSP2_ZM 4 +#define WMFW_ADSP2_XM 5 +#define WMFW_ADSP2_YM 6 + #endif -- 1.7.10.4

1 3

Re: [alsa-devel] [PATCH] ALSA:hda - Fix mute-LED setup for HP dv5 laptop
by Takashi Iwai 26 Oct '12

26 Oct '12

At Fri, 26 Oct 2012 12:51:53 -0200, Gustavo Maciel Dias Vieira wrote: > > The BIOS on HP dv5 doesn't have the DMI string to guide the setup of > mute led GPIO and polarity. Associate this laptop with the hp-inv-led > model. > > Signed-off-by: Gustavo Maciel Dias Vieira <gustavo(a)sagui.org> > Tested-by: Vinícius Angiolucci <angiolucci(a)gmail.com> > --- > > The tester was using a module option to set the correct model. Let's > support it out of the box. Thanks, applied now. Takashi > > Abraços, > Gustavo > > sound/pci/hda/patch_sigmatel.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c > index 6214165..962a948 100644 > --- a/sound/pci/hda/patch_sigmatel.c > +++ b/sound/pci/hda/patch_sigmatel.c > @@ -1764,6 +1764,8 @@ static const struct snd_pci_quirk stac92hd83xxx_cfg_tbl[] = { > "HP", STAC_HP_ZEPHYR), > SND_PCI_QUIRK(PCI_VENDOR_ID_HP, 0x3660, > "HP Mini", STAC_92HD83XXX_HP_LED), > + SND_PCI_QUIRK(PCI_VENDOR_ID_HP, 0x144E, > + "HP Pavilion dv5", STAC_92HD83XXX_HP_INV_LED), > {} /* terminator */ > }; > > -- > 1.7.7.6 >

1 0

[alsa-devel] Access dummy mixer control through filesystem
by Muffinman 26 Oct '12

26 Oct '12

Hello all, I want to write an application that tracks in realtime changes in a dummy mixer control (though not sure which language yet). I think its best to try to track those changes through the filesystem. For non-dummy mixer controls I can access them through: /proc/asound/cardx/codecxxx/xxxx+regs. However, it seems that this does not work for this dummy mixer control. Is there some other location I can find this control? If this is not possible for this type of control, can someone advise me on what language to use for this project? Kind regards, Maarten ps. I've defined the dummy mixer control in /var/lib/alsa/asound.state as shown below: state.DAC { control.12345 { iface MIXER name 'Fake Playback Volume' value 100 comment { access 'read write user' type INTEGER count 1 range '0 - 100' } } }

1 0

[alsa-devel] [PATCH] ALSA: HDA - Check return value to reduce useless delay
by Wang Xingchao 26 Oct '12

26 Oct '12

For verb 705h, it's useless to read response, so use *write api would be better. If there's error after sending cmd, just try again without continue after wrong operation.Otherwise there's long time delay. Signed-off-by: Wang Xingchao <xingchao.wang(a)intel.com> --- sound/pci/hda/hda_codec.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index 960800b..0946eca 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3569,6 +3569,7 @@ static unsigned int hda_set_power_state(struct hda_codec *codec, hda_nid_t fg = codec->afg ? codec->afg : codec->mfg; int count; unsigned int state; + int err; /* this delay seems necessary to avoid click noise at power-down */ if (power_state == AC_PWRST_D3) { @@ -3582,9 +3583,11 @@ static unsigned int hda_set_power_state(struct hda_codec *codec, codec->patch_ops.set_power_state(codec, fg, power_state); else { - snd_hda_codec_read(codec, fg, 0, + err = snd_hda_codec_write(codec, fg, 0, AC_VERB_SET_POWER_STATE, power_state); + if (err < 0) + continue; snd_hda_codec_set_power_to_all(codec, fg, power_state, true); } -- 1.7.9.5

3 5

[alsa-devel] Fw: Support for M-Audio VENOM?
by Xavier Miller 26 Oct '12

26 Oct '12

Hello, I would like to have support for the M-Audio Venom synthesizer. It has a USB audio and USB MIDI interface, but the current usb audio driver fails to configure it correctly : the system hangs during a long time when the USB connection is established: for example, lsusb takes 24 seconds with the Venom attached, and alsamixer/aconnect -io end with As attachments, there is a .tar.xz with the output of lsusb, kernel messages, dbus messages and /proc/asound contents. What can I do to enable that USB interface? I could help developers to help me having a working driver (I am application developer, and I run Gentoo Linux). Kind regards, Xavier Miller.

2 2

[alsa-devel] Edirol M-16DX workaround found.
by Rick Kirk 26 Oct '12

26 Oct '12

Hi Everyone. I recently purchased an Edirol M-16DX digital Mixer and am using it with Arch Linux. Alsa version is 1.0.26. After searching the internet and in particular the alsa-devel archives I came across some discussion about this particular device dating back to 2008/09. The device has a built in USB sound card. A patch was added a long time to allow the device to function with the Alsa usb audio driver. Everything worked as expected except for a playback issue that results in a ring modulation like distortion of the audio at fixed intervals (dependant on the frequency in use). At the time those investigating the issue didn't recieve any information back from testers and were unable to resolve the issue and the patch was released with the understanding that device was not fully functional. The proposed fix at the time was to make the device capture audio during playback, even if no recording was being made, thereby using the interal capture clock to sync playback. This was never implemented for various reasons. I have found a workaround for this issue. The device has a digital SPDIF input. With the USB outputs on the device not working it made sense to use my onboard audio card via SPDIF to create a digital path from the PC to the mixer to allow use of PC sound with the mixer. I found upon connecting the SPDIF that the Edirol immediately synced to the external PC clock signal via the coax SPDIF connection. As a result the audio distortion was gone, making the device function as intended. (tested at 48khz though I expect it will work for 44.1khz and 96khz also). The downside to this is that I have lost a stereo input (input 14 is SPDIF or stereo in, not both). I now have 2 ways of using PC based audio with the machine (USB and SPDIF), or none if I stop using the SPDIF connection. This discovery proves that the playback issue is purely a lack of clock sync. I have tested this by setting the internal card to 44.1khz and the edirol to 48khz. The edirol loses external sync and shows on screen that the device switches back to "internal clock". The distortion resurfaces until I force the PC onboard audio back to 48khz, providing a useful external clock source to the edirol via the SPDIF signal. It would appear that the previously proposed fix of capturing while playing back may not be needed and my hope is that the fix might be far simpler to implement. I hope that this information is useful to those previoulsy involved. I would like to as what would be required to enable a clock sync via the USB connection between the PC and mixer? I would be happy to help with beta testing for anyone interested in taking a look at this issue. I have also read that there are other devices that suffer from this same fault so there is potential that any fix may apply to more than this one device. Alternately, if no-one has the time/interest to work directly on the problem then perhaps someone could suggest how the sync might be accomplished and where in the code to start looking? I can then attempt to patch the code myself, though it is likely well beyond my abilities. Thanks for any assistance. Regards, Rick. P.S. I have also requested technical documentation from Roland for this device in the hope they will provide it as the device in now out of production. I am yet to hear anything back.

2 1

Re: [alsa-devel] Question about move atmel audio part to DT support
by Bo Shen 26 Oct '12

26 Oct '12

Cc: linux-arm-kernel mailing list devicetree-discuss mailing list alsa-devel mailing list linux-sound mailing list On 10/19/2012 14:38, Bo Shen wrote: > Hi Mark Brown, > Now, I am trying to move atmel audio part to DT support. I meet the > following issue. > > Atmel audio part has three platform device: > -> atmel ssc: ssc library (different SOC has different number) > -> atmel ssc dai: dai for audio > -> atmel pcm: for pdc or dma transfer (now only support pdc, dma > support will add soon) > > In DT support kernel, I don't find any similar case. So, if I want to > keep ssc as library, and use dai to register pcm. Then the dts file will > like: > ---<8--- > ssc0: ssc@fffbc000 { > status = "okay"; > }; > > dai0: dai { > compatible = "atmel,atmel-ssc-dai"; > }; > > sound { > compatible = "atmel,at91sam9g20-audio"; > atmel,model = "wm8731 @ sam9g20ek"; > > atmel,audio-routing = > "Ext Spk", "LHPOUT", > "Int Mic", "MICIN"; > > atmel,audio-codec = <&wm8731>; > atmel,dai = <&dai>; > }; > --->8--- > > Would this be OK? > If not, may I add some code for ssc which dedicate for audio into > sound/soc/atmel (using audio-ssc and ssc to distiguish which dedicate > for audio, which used for ssc library)? This will broken the exist code > for audio (only sam9g20-wm8731). > Any suggestion?

2 2

[alsa-devel] ASoC updates for v3.7
by Mark Brown 25 Oct '12

25 Oct '12

The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-3.7 for you to fetch changes up to 456ba5a7802e58eccb5aa9751b3ab515ef99b9ca: Merge remote-tracking branches 'asoc/fix/ux500' and 'asoc/fix/wm8994' into for-3.7 (2012-10-25 17:36:02 +0100) ---------------------------------------------------------------- ASoC: Fixes for v3.7 A couple of driver fixes, one that improves the interoperability of WM8994 with controllers that are sensitive to extra BCLK cycles and some build break fixes for ux500. ---------------------------------------------------------------- Lee Jones (2): ASoC: Ux500: Dispose of device nodes correctly ASoC: ux500_msp_i2s: Fix devm_* and return code merge error Mark Brown (2): ASoC: wm8994: Only enable extra BCLK cycles when required Merge remote-tracking branches 'asoc/fix/ux500' and 'asoc/fix/wm8994' into for-3.7 sound/soc/codecs/wm8994.c | 18 +++++++++++++++++- sound/soc/codecs/wm8994.h | 1 + sound/soc/ux500/mop500.c | 17 +++++++++++++++++ sound/soc/ux500/ux500_msp_i2s.c | 8 +++----- 4 files changed, 38 insertions(+), 6 deletions(-)

2 1

Re: [alsa-devel] [PATCH] ASoC: supply and micbiases shoud bring "up to" STANDBY
by Mark Brown 25 Oct '12

25 Oct '12

On Wed, Oct 24, 2012 at 02:19:35PM -0700, Shaoming Feng wrote: > /* Supplies and micbiases only bring the > * context up to STANDBY as unless something > * else is active and passing audio they > * generally don't require full power. Signal > * generators are virtual pins and have no > * power impact themselves. > */ > According to the comment, the target bias level shouldn't be higher than STANDBY. > case snd_soc_dapm_clock_supply: > case snd_soc_dapm_micbias: > - if (d->target_bias_level < SND_SOC_BIAS_STANDBY) > + if (d->target_bias_level > SND_SOC_BIAS_STANDBY) > d->target_bias_level = SND_SOC_BIAS_STANDBY; This will do the wrong thing - it'll mean that if we've already found that we need a bias level over _STANDBY we'll pull back to only selecting _STANDBY. The intention here is that we should raise to _STANDBY but this shouldn't distrupt operation of other widgets.

1 0

[alsa-devel] [PATCH] ASoC: wm5102: Correct micbias DAPM supplies
by Charles Keepax 25 Oct '12

25 Oct '12

ARIZONA_MICB1_ENA_SHIFT was used for micbias 2 and 3. This change correctly uses the ARIZONA_MICBX_ENA_SHIFT for each corresponding DAPM supply. This should not have caused any problems as the micbias enables are in the same place in each register. Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm5102.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/wm5102.c b/sound/soc/codecs/wm5102.c index 1722b58..8714d62 100644 --- a/sound/soc/codecs/wm5102.c +++ b/sound/soc/codecs/wm5102.c @@ -344,9 +344,9 @@ SND_SOC_DAPM_PGA_E("IN3R PGA", ARIZONA_INPUT_ENABLES, ARIZONA_IN3R_ENA_SHIFT, SND_SOC_DAPM_SUPPLY("MICBIAS1", ARIZONA_MIC_BIAS_CTRL_1, ARIZONA_MICB1_ENA_SHIFT, 0, NULL, 0), SND_SOC_DAPM_SUPPLY("MICBIAS2", ARIZONA_MIC_BIAS_CTRL_2, - ARIZONA_MICB1_ENA_SHIFT, 0, NULL, 0), + ARIZONA_MICB2_ENA_SHIFT, 0, NULL, 0), SND_SOC_DAPM_SUPPLY("MICBIAS3", ARIZONA_MIC_BIAS_CTRL_3, - ARIZONA_MICB1_ENA_SHIFT, 0, NULL, 0), + ARIZONA_MICB3_ENA_SHIFT, 0, NULL, 0), SND_SOC_DAPM_PGA("Noise Generator", ARIZONA_COMFORT_NOISE_GENERATOR, ARIZONA_NOISE_GEN_ENA_SHIFT, 0, NULL, 0), -- 1.7.2.5

2 1

Re: [alsa-devel] sound/pci/au88x0/au88x0_core.c:2464 vortex_interrupt() warn: if();
by Raymond Yau 25 Oct '12

25 Oct '12

2012-10-23 下午10:35 於 "Takashi Iwai" <tiwai(a)suse.de> 寫道： > > At Tue, 23 Oct 2012 22:16:42 +0800, > Fengguang Wu wrote: > > > > Hi, > > > > smatch warns about a weird "if();" in sound/pci/au88x0/au88x0_core.c > > Any ideas to fix it? > > > > 2461 #ifndef CHIP_AU8810 > > 2462 for (i = 0; i < NR_WT; i++) { > > 2463 if (vortex->dma_wt[i].fifo_status == FIFO_START) { > > ==> 2464 if (vortex_wtdma_bufshift(vortex, i)) ; > > 2465 spin_unlock(&vortex->lock); > > 2466 snd_pcm_period_elapsed(vortex->dma_wt[i]. > > 2467 substream); > > 2468 spin_lock(&vortex->lock); > > 2469 } > > 2470 } > > 2471 #endif > > A quick fix is below, but I'm not 100% sure about it yet. > Let's see. using aplay with VORTEX_PCM_WT , only a very low high frequency signal is heard and after 10 seconds aplay: pcm_write:1702: write error: Input/output error refer to the patent 6167465 the wavetable DMA channels operate slightly different from the non-wavetable DMA channels it seem that the driver still cannot send the increment wavetable pointer signal and the increment count signal , thus fifo controller does not reach the trigger level to request for a dma transfer may need some code to use the sound card's timer interrupt to send increment wavetable pointer signal to provide pitching by perform sample rate conversion on the data through interpolation and looping BTW au88x0 still missing channel map /* pre-allocation of Scatter-Gather buffers */ snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV_SG, snd_dma_pci_data(chip->pci_dev), 0x10000, 0x10000); +if (VORTEX_PCM_TYPE(pcm) == VORTEX_PCM_ADB) { + err = snd_pcm_add_chmap_ctls(pcm, SNDRV_PCM_STREAM_PLAYBACK, + snd_pcm_std_chmaps, 4, 0, NULL); + if (err < 0) + return err; + } if (VORTEX_PCM_TYPE(pcm) == VORTEX_PCM_SPDIF) { http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=3fc13d6f5b08edee… how about capture stream since test/chmap can open capture stream ? case 's': if (*optarg == 'c' || *optarg == 'C') stream = SND_PCM_STREAM_CAPTURE; else stream = SND_PCM_STREAM_PLAYBACK; break; do VORTEX_PCM_A3D need a mono channel map since device 2 only support mono playback with spatalization to stereo output ? how about the mono channel map of emu10k1 and trident ? > > > thanks, > > Takashi > > --- > diff --git a/sound/pci/au88x0/au88x0_core.c b/sound/pci/au88x0/au88x0_core.c > index 525f881..3fe3dbe 100644 > --- a/sound/pci/au88x0/au88x0_core.c > +++ b/sound/pci/au88x0/au88x0_core.c > @@ -2461,7 +2461,8 @@ static irqreturn_t vortex_interrupt(int irq, void *dev_id) > #ifndef CHIP_AU8810 > for (i = 0; i < NR_WT; i++) { > if (vortex->dma_wt[i].fifo_status == FIFO_START) { > - if (vortex_wtdma_bufshift(vortex, i)) ; > + if (!vortex_wtdma_bufshift(vortex, i)) > + continue; > spin_unlock(&vortex->lock); > snd_pcm_period_elapsed(vortex->dma_wt[i]. > substream);

2 1

[alsa-devel] 191dB Master Playback Volume
by Raymond Yau 25 Oct '12

25 Oct '12

>> Something wild is merged in his system. It has a wrong "Master" >> control without suffix. Also a strange "Pre-Amp" control is found >> there, too. The string doesn't fix in kernel or alsa-lib codes at >> all. > The softvol master volume must have been from a try > with asound.rc config, but it didn't help. > Here is updated alsa-info script without asound.rc: > http://www.alsa-project.org/db/?f=ab5362501881befcdaee94e44278820d43bf92f1 > Meanwhile, in order to test sound, I have tried > severeal live distros including: Ubuntu/Lubuntu 12.10, > Mint, Crunchbang and the result is the same: no > sound or sound that is very low with a lot of noise. > Tried to update alsa to 1.0.25 following this tutorial: > http://ubuntuforums.org/showthread.php?t=1681577 > but that also failed, resulting with "no driver to compile". > Don't know what else to try, and cannot believe that > after more than 7 years with Linux now when I finally > have completely Intel based computer the sound is > making this much trouble. it is not easy to remove the softvol since it is recreated by "alsactl restore" and you still have those softvol controls and a 191dB Master playback volume there must be a bug in alsa lib when you have a stereo softvol master and a mono virtual master playback volume when both softvol without suffix "playback volume" , the capability of pre-amp is volume(global) but master is pvolume Amixer output !!------------- !!-------Mixer controls for card 0 [Intel] Card hw:0 'Intel'/'HDA Intel at 0xfeaf8000 irq 43' Mixer name: 'Realtek ALC887-VD' Components: 'HDA:10ec0887,10438445,00100302' Controls : 43 Simple ctrls : 22 Simple mixer control 'Master',0 Capabilities: pvolume pswitch pswitch-joined penum Playback channels: Front Left - Front Right Limits: Playback 0 - 255 Mono: Front Left: Playback 255 [100%] [191.00dB] [on] Front Right: Playback 255 [100%] [191.00dB] [on] Simple mixer control 'Pre-Amp',0 Capabilities: volume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 5 Front Left: 5 [100%] Front Right: 5 [100%] control.32 { comment.access 'read write' comment.type INTEGER comment.count 1 comment.range '0 - 64' comment.dbmin -6400 comment.dbmax 0 iface MIXER name 'Master Playback Volume' value 64 } control.40 { comment.access 'read write user' comment.type INTEGER comment.count 2 comment.range '0 - 255' comment.tlv '0000000100000008ffffec1400000014' comment.dbmin -5100 comment.dbmax 0 iface MIXER name 'PCM Playback Volume' value.0 255 value.1 255 } control.42 { comment.access 'read write user' comment.type INTEGER comment.count 2 comment.range '0 - 5' comment.tlv '0000000100000008fffffe0c000001f4' comment.dbmin -500 comment.dbmax 2000 iface MIXER name Pre-Amp value.0 5 value.1 5 } control.43 { comment.access 'read write user' comment.type INTEGER comment.count 2 comment.range '0 - 255' comment.tlv '0000000100000008ffffec1400000014' comment.dbmin -5100 comment.dbmax 0 iface MIXER name Master value.0 255 value.1 255

1 0

[alsa-devel] customized IOCTL in pcm platform driver.
by gsantosh＠codeaurora.org 25 Oct '12

25 Oct '12

Hi All, will ALSA framework provide any customized IOCTL functionality in PCM platform driver. in my system there is a requirement to get some information from DSP to user space and I am thinking to add IOCTL's, is there any method to accommodate or how we can address this issue? Regards, Santosh

2 8

Re: [alsa-devel] VOIP xrun problem
by Jamey Drennan 24 Oct '12

24 Oct '12

Maybe I don't quite understand your question but I use RTP (oRTP library) to manage the sending/receiving of the audio streams. On Mon, Oct 22, 2012 at 4:45 PM, Florian Faber <faber(a)faberman.de> wrote: > On 10/22/12 22:40, Jamey Drennan wrote: > > Now in the second phase, events are timed due to specification > > requirements. The same Alsa setup code is used yet xruns (mostly > > underruns) are all over the place. The underruns are periodic and can be > > reduced by increasing the period size and number of periods (this also > > increases the latency obviously and is undersirable) but never removed > > completely. > > > > My question is how to reduce/remove the xruns. > > How do you synchronize the streams? You will either have to synchronize > the media clocks or do some sort of SRC. > > > Flo > -- > Machines can do the work, so people have time to think. > public key B3B9226C x-hkp://wwwkeys.eu.pgp.net >

2 5

Re: [alsa-devel] [PATCH 2/2] ASoC: ux500_msp_i2s: Fix devm_* and return code merge error
by Mark Brown 24 Oct '12

24 Oct '12

On Wed, Oct 24, 2012 at 11:34:00AM +0200, Ulf Hansson wrote: > Acked-by: Ulf Hansson <ulf.hansson(a)linaro.org> > > I assume this shall go into 3.7, right? > > Kind regards > Ulf Hansson You may recall that only yesterday I reminded you not to top post...

1 0

[alsa-devel] [PATCH] ASoC: wm8994: Lower AIFnCLK divisor when dropping to 32kHz
by Mark Brown 24 Oct '12

24 Oct '12

When lowering SYSCLK to 50kHz for accessory detection also lower the AIFnCLK divisor to normalise the clocking configuration within the device. This will not disrupt audio as we cannot support active audio with such a low SYSCLK. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8994.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index 0932d7a..c16a9a3 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -2443,6 +2443,18 @@ static int wm8994_set_dai_sysclk(struct snd_soc_dai *dai, configure_clock(codec); + /* + * If SYSCLK will be less than 50kHz adjust AIFnCLK dividers + * for detection. + */ + if (max(wm8994->aifclk[0], wm8994->aifclk[1]) < 50000) { + dev_dbg(codec->dev, "Configuring AIFs for 128fs\n"); + snd_soc_update_bits(codec, WM8994_AIF1_RATE, + WM8994_AIF1CLK_RATE_MASK, 0x1); + snd_soc_update_bits(codec, WM8994_AIF2_RATE, + WM8994_AIF2CLK_RATE_MASK, 0x1); + } + return 0; } -- 1.7.10.4

1 0

[alsa-devel] [GIT PULL] dummy: allow disabling mixer controls
by Clemens Ladisch 24 Oct '12

24 Oct '12

The following changes since commit a0d271cbfed1dd50278c6b06bead3d00ba0a88f9: Linux 3.6 (2012-09-30 16:47:46 -0700) are available in the git repository at: git://git.alsa-project.org/alsa-kprivate.git dummy-ctl-inactive ---------------------------------------------------------------- Quite a few mixer applications do not handle deactivated controls correctly. This patch adds such controls to snd-dummy to make crash^H^H^H^H^Htesting these apps easier. ---------------------------------------------------------------- Clemens Ladisch (1): ALSA: dummy: allow disabling mixer controls sound/drivers/dummy.c | 73 +++++++++++++++++++++++++++++++++++++++++++++++- 1 files changed, 71 insertions(+), 2 deletions(-) diff --git a/sound/drivers/dummy.c b/sound/drivers/dummy.c index 54bb664..4f522cf 100644 --- a/sound/drivers/dummy.c +++ b/sound/drivers/dummy.c @@ -134,6 +134,9 @@ struct snd_dummy { spinlock_t mixer_lock; int mixer_volume[MIXER_ADDR_LAST+1][2]; int capture_source[MIXER_ADDR_LAST+1][2]; + int iobox; + struct snd_kcontrol *cd_volume_ctl; + struct snd_kcontrol *cd_switch_ctl; const struct dummy_timer_ops *timer_ops; }; @@ -817,6 +820,57 @@ static int snd_dummy_capsrc_put(struct snd_kcontrol *kcontrol, struct snd_ctl_el return change; } +static int snd_dummy_iobox_info(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_info *info) +{ + const char *const names[] = { "None", "CD Player" }; + + return snd_ctl_enum_info(info, 1, 2, names); +} + +static int snd_dummy_iobox_get(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *value) +{ + struct snd_dummy *dummy = snd_kcontrol_chip(kcontrol); + + value->value.enumerated.item[0] = dummy->iobox; + return 0; +} + +static int snd_dummy_iobox_put(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *value) +{ + struct snd_dummy *dummy = snd_kcontrol_chip(kcontrol); + int changed; + + if (value->value.enumerated.item[0] > 1) + return -EINVAL; + + changed = value->value.enumerated.item[0] != dummy->iobox; + if (changed) { + dummy->iobox = value->value.enumerated.item[0]; + + if (dummy->iobox) { + dummy->cd_volume_ctl->vd[0].access &= + ~SNDRV_CTL_ELEM_ACCESS_INACTIVE; + dummy->cd_switch_ctl->vd[0].access &= + ~SNDRV_CTL_ELEM_ACCESS_INACTIVE; + } else { + dummy->cd_volume_ctl->vd[0].access |= + SNDRV_CTL_ELEM_ACCESS_INACTIVE; + dummy->cd_switch_ctl->vd[0].access |= + SNDRV_CTL_ELEM_ACCESS_INACTIVE; + } + + snd_ctl_notify(dummy->card, SNDRV_CTL_EVENT_MASK_INFO, + &dummy->cd_volume_ctl->id); + snd_ctl_notify(dummy->card, SNDRV_CTL_EVENT_MASK_INFO, + &dummy->cd_switch_ctl->id); + } + + return changed; +} + static struct snd_kcontrol_new snd_dummy_controls[] = { DUMMY_VOLUME("Master Volume", 0, MIXER_ADDR_MASTER), DUMMY_CAPSRC("Master Capture Switch", 0, MIXER_ADDR_MASTER), @@ -827,22 +881,37 @@ DUMMY_CAPSRC("Line Capture Switch", 0, MIXER_ADDR_LINE), DUMMY_VOLUME("Mic Volume", 0, MIXER_ADDR_MIC), DUMMY_CAPSRC("Mic Capture Switch", 0, MIXER_ADDR_MIC), DUMMY_VOLUME("CD Volume", 0, MIXER_ADDR_CD), -DUMMY_CAPSRC("CD Capture Switch", 0, MIXER_ADDR_CD) +DUMMY_CAPSRC("CD Capture Switch", 0, MIXER_ADDR_CD), +{ + .iface = SNDRV_CTL_ELEM_IFACE_MIXER, + .name = "External I/O Box", + .info = snd_dummy_iobox_info, + .get = snd_dummy_iobox_get, + .put = snd_dummy_iobox_put, +}, }; static int __devinit snd_card_dummy_new_mixer(struct snd_dummy *dummy) { struct snd_card *card = dummy->card; + struct snd_kcontrol *kcontrol; unsigned int idx; int err; spin_lock_init(&dummy->mixer_lock); strcpy(card->mixername, "Dummy Mixer"); + dummy->iobox = 1; for (idx = 0; idx < ARRAY_SIZE(snd_dummy_controls); idx++) { - err = snd_ctl_add(card, snd_ctl_new1(&snd_dummy_controls[idx], dummy)); + kcontrol = snd_ctl_new1(&snd_dummy_controls[idx], dummy); + err = snd_ctl_add(card, kcontrol); if (err < 0) return err; + if (!strcmp(kcontrol->id.name, "CD Volume")) + dummy->cd_volume_ctl = kcontrol; + else if (!strcmp(kcontrol->id.name, "CD Capture Switch")) + dummy->cd_switch_ctl = kcontrol; + } return 0; }

3 6

[alsa-devel] Passing audio info from HDMI EDID beside speaker allocation
by Patrick Lai 24 Oct '12

24 Oct '12

Hi Takashi, You proposed snd_pcm_query_chmaps() to query underlying hardware speaker allocation. Please correct me if I have wrong understanding of this API. On the other hand, HDMI EDID contains audio data other than speaker allocation such as audio formats(LPCM, AC3, and etc). How are these information other than speaker allocation passed back to the user-space? Are there a standard kernel and alsa query interfaces now? 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.

3 5

[alsa-devel] [PATCH -next] sound: ice1712 build errors
by Randy Dunlap 23 Oct '12

23 Oct '12

From: Randy Dunlap <rdunlap(a)xenotime.net> Fix build errors by using correct kconfig symbol name: sound/pci/ice1712/psc724.c:417:5: error: 'struct snd_ice1712' has no member named 'pm_resume' sound/pci/ice1712/psc724.c:418:5: error: 'struct snd_ice1712' has no member named 'pm_suspend_enabled' Signed-off-by: Randy Dunlap <rdunlap(a)xenotime.net> Cc: Ondrej Zary <linux(a)rainbow-software.org> Cc: Jaroslav Kysela <perex(a)perex.cz> Cc: Takashi Iwai <tiwai(a)suse.de> Cc: alsa-devel(a)alsa-project.org --- sound/pci/ice1712/psc724.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20121023.orig/sound/pci/ice1712/psc724.c +++ linux-next-20121023/sound/pci/ice1712/psc724.c @@ -413,7 +413,7 @@ static int __devinit psc724_init(struct snd_wm8776_init(&spec->wm8776); spec->wm8766.ops.write = psc724_wm8766_write; spec->wm8766.card = ice->card; -#ifdef CONFIG_PM +#ifdef CONFIG_PM_SLEEP ice->pm_resume = psc724_resume; ice->pm_suspend_enabled = 1; #endif

3 2

[alsa-devel] [PATCH 1/3] ALSA: core: keep track of boundary wrap-around
by Pierre-Louis Bossart 23 Oct '12

23 Oct '12

Keep track of boundary crossing when hw_ptr exceeds boundary limit and wraps-around. This will help keep track of total number of frames played/received at the kernel level Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- include/sound/pcm.h | 1 + sound/core/pcm_lib.c | 25 ++++++++++++++++++++----- 2 files changed, 21 insertions(+), 5 deletions(-) diff --git a/include/sound/pcm.h b/include/sound/pcm.h index 6268a41..28fd9f9 100644 --- a/include/sound/pcm.h +++ b/include/sound/pcm.h @@ -281,6 +281,7 @@ struct snd_pcm_runtime { unsigned long hw_ptr_jiffies; /* Time when hw_ptr is updated */ unsigned long hw_ptr_buffer_jiffies; /* buffer time in jiffies */ snd_pcm_sframes_t delay; /* extra delay; typically FIFO size */ + u64 hw_ptr_wrap; /* offset for hw_ptr due to boundary wrap-around */ /* -- HW params -- */ snd_pcm_access_t access; /* access mode */ diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c index f42c10a..3dc029e 100644 --- a/sound/core/pcm_lib.c +++ b/sound/core/pcm_lib.c @@ -316,6 +316,7 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream, unsigned long jdelta; unsigned long curr_jiffies; struct timespec curr_tstamp; + int crossed_boundary = 0; old_hw_ptr = runtime->status->hw_ptr; @@ -360,8 +361,10 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream, hdelta = curr_jiffies - runtime->hw_ptr_jiffies; if (hdelta > runtime->hw_ptr_buffer_jiffies/2) { hw_base += runtime->buffer_size; - if (hw_base >= runtime->boundary) + if (hw_base >= runtime->boundary) { hw_base = 0; + crossed_boundary++; + } new_hw_ptr = hw_base + pos; goto __delta; } @@ -371,8 +374,10 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream, /* pointer crosses the end of the ring buffer */ if (new_hw_ptr < old_hw_ptr) { hw_base += runtime->buffer_size; - if (hw_base >= runtime->boundary) + if (hw_base >= runtime->boundary) { hw_base = 0; + crossed_boundary++; + } new_hw_ptr = hw_base + pos; } __delta: @@ -410,8 +415,10 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream, while (hdelta > xrun_threshold) { delta += runtime->buffer_size; hw_base += runtime->buffer_size; - if (hw_base >= runtime->boundary) + if (hw_base >= runtime->boundary) { hw_base = 0; + crossed_boundary++; + } new_hw_ptr = hw_base + pos; hdelta -= runtime->hw_ptr_buffer_jiffies; } @@ -456,8 +463,10 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream, /* the delta value is small or zero in most cases */ while (delta > 0) { new_hw_ptr += runtime->period_size; - if (new_hw_ptr >= runtime->boundary) + if (new_hw_ptr >= runtime->boundary) { new_hw_ptr -= runtime->boundary; + crossed_boundary--; + } delta--; } /* align hw_base to buffer_size */ @@ -507,6 +516,10 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream, runtime->hw_ptr_base = hw_base; runtime->status->hw_ptr = new_hw_ptr; runtime->hw_ptr_jiffies = curr_jiffies; + if (crossed_boundary) { + snd_BUG_ON(crossed_boundary != 1); + runtime->hw_ptr_wrap += runtime->boundary; + } if (runtime->tstamp_mode == SNDRV_PCM_TSTAMP_ENABLE) runtime->status->tstamp = curr_tstamp; @@ -1661,8 +1674,10 @@ static int snd_pcm_lib_ioctl_reset(struct snd_pcm_substream *substream, if (snd_pcm_running(substream) && snd_pcm_update_hw_ptr(substream) >= 0) runtime->status->hw_ptr %= runtime->buffer_size; - else + else { runtime->status->hw_ptr = 0; + runtime->hw_ptr_wrap = 0; + } snd_pcm_stream_unlock_irqrestore(substream, flags); return 0; } -- 1.7.9.5

2 3

[alsa-devel] [PATCH] ALSA: usb-audio: Add quirk for Reloop Play
by Didier Villevalois 23 Oct '12

23 Oct '12

The Reloop Audio needs a fixed endpoint quirk with S24_3LE format and UAC_EP_CS_ATTR_SAMPLE_RATE attribute. Signed-off-by: Didier Villevalois <ptitjes(a)free.fr> --- sound/usb/quirks-table.h | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h index d73ac9b..48ede8b 100644 --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -2834,6 +2834,47 @@ YAMAHA_DEVICE(0x7010, "UB99"), } }, +/* Reloop Play */ +{ + USB_DEVICE(0x200c, 0x100b), + .bInterfaceClass = USB_CLASS_PER_INTERFACE, + .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) { + .ifnum = QUIRK_ANY_INTERFACE, + .type = QUIRK_COMPOSITE, + .data = &(const struct snd_usb_audio_quirk[]) { + { + .ifnum = 0, + .type = QUIRK_AUDIO_STANDARD_MIXER, + }, + { + .ifnum = 1, + .type = QUIRK_AUDIO_FIXED_ENDPOINT, + .data = &(const struct audioformat) { + .formats = SNDRV_PCM_FMTBIT_S24_3LE, + .channels = 4, + .iface = 1, + .altsetting = 1, + .altset_idx = 1, + .attributes = UAC_EP_CS_ATTR_SAMPLE_RATE, + .endpoint = 0x01, + .ep_attr = USB_ENDPOINT_SYNC_ADAPTIVE, + .rates = SNDRV_PCM_RATE_44100 | + SNDRV_PCM_RATE_48000, + .rate_min = 44100, + .rate_max = 48000, + .nr_rates = 2, + .rate_table = (unsigned int[]) { + 44100, 48000 + } + } + }, + { + .ifnum = -1 + } + } + } +}, + { /* * Some USB MIDI devices don't have an audio control interface, -- 1.7.10.4

2 1

[alsa-devel] sound/pci/au88x0/au88x0_core.c:2464 vortex_interrupt() warn: if();
by Fengguang Wu 23 Oct '12

23 Oct '12

Hi, smatch warns about a weird "if();" in sound/pci/au88x0/au88x0_core.c Any ideas to fix it? 2461 #ifndef CHIP_AU8810 2462 for (i = 0; i < NR_WT; i++) { 2463 if (vortex->dma_wt[i].fifo_status == FIFO_START) { ==> 2464 if (vortex_wtdma_bufshift(vortex, i)) ; 2465 spin_unlock(&vortex->lock); 2466 snd_pcm_period_elapsed(vortex->dma_wt[i]. 2467 substream); 2468 spin_lock(&vortex->lock); 2469 } 2470 } 2471 #endif Thanks, Fengguang

2 1

[alsa-devel] [PATCH] [v2] ASoC: add support for the Freescale / iVeia P1022 RDK reference board
by Timur Tabi 23 Oct '12

23 Oct '12

This small reference boards has a Freescale P1022 dual-core PowerPC SOC and a Wolfson Microelectronics WM8960 codec. Signed-off-by: Timur Tabi <timur(a)freescale.com> --- sound/soc/fsl/Kconfig | 14 ++ sound/soc/fsl/Makefile | 4 + sound/soc/fsl/p1022_rdk.c | 392 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 410 insertions(+), 0 deletions(-) create mode 100644 sound/soc/fsl/p1022_rdk.c diff --git a/sound/soc/fsl/Kconfig b/sound/soc/fsl/Kconfig index 4563b28..8e48432 100644 --- a/sound/soc/fsl/Kconfig +++ b/sound/soc/fsl/Kconfig @@ -46,6 +46,20 @@ config SND_SOC_P1022_DS This will also include the Wolfson Microelectronics WM8776 codec driver. +config SND_SOC_P1022_RDK + tristate "ALSA SoC support for the Freescale / iVeia P1022 RDK board" + # I2C is necessary for the WM8960 driver + depends on P1022_RDK && I2C + select SND_SOC_FSL_SSI + select SND_SOC_FSL_UTILS + select SND_SOC_POWERPC_DMA + select SND_SOC_WM8960 + default y if P1022_RDK + help + Say Y if you want to enable audio on the Freescale / iVeia + P1022 RDK board. This will also include the Wolfson + Microelectronics WM8960 codec driver. + config SND_SOC_MPC5200_I2S tristate "Freescale MPC5200 PSC in I2S mode driver" depends on PPC_MPC52xx && PPC_BESTCOMM diff --git a/sound/soc/fsl/Makefile b/sound/soc/fsl/Makefile index 5f3cf3f..515ba66 100644 --- a/sound/soc/fsl/Makefile +++ b/sound/soc/fsl/Makefile @@ -6,6 +6,10 @@ obj-$(CONFIG_SND_SOC_MPC8610_HPCD) += snd-soc-mpc8610-hpcd.o snd-soc-p1022-ds-objs := p1022_ds.o obj-$(CONFIG_SND_SOC_P1022_DS) += snd-soc-p1022-ds.o +# P1022 RDK Machine Support +snd-soc-p1022-rdk-objs := p1022_rdk.o +obj-$(CONFIG_SND_SOC_P1022_RDK) += snd-soc-p1022-rdk.o + # Freescale PowerPC SSI/DMA Platform Support snd-soc-fsl-ssi-objs := fsl_ssi.o snd-soc-fsl-utils-objs := fsl_utils.o diff --git a/sound/soc/fsl/p1022_rdk.c b/sound/soc/fsl/p1022_rdk.c new file mode 100644 index 0000000..897e32f --- /dev/null +++ b/sound/soc/fsl/p1022_rdk.c @@ -0,0 +1,392 @@ +/** + * Freescale P1022RDK ALSA SoC Machine driver + * + * Author: Timur Tabi <timur(a)freescale.com> + * + * Copyright 2012 Freescale Semiconductor, Inc. + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed "as is" without any warranty of any + * kind, whether express or implied. + * + * Note: in order for audio to work correctly, the output controls need + * to be enabled, because they control the clock. So for playback, for + * example: + * + * amixer sset 'Left Output Mixer PCM' on + * amixer sset 'Right Output Mixer PCM' on + */ + +#include <linux/module.h> +#include <linux/interrupt.h> +#include <linux/of_device.h> +#include <linux/slab.h> +#include <sound/soc.h> +#include <asm/fsl_guts.h> + +#include "fsl_dma.h" +#include "fsl_ssi.h" +#include "fsl_utils.h" + +/* P1022-specific PMUXCR and DMUXCR bit definitions */ + +#define CCSR_GUTS_PMUXCR_UART0_I2C1_MASK 0x0001c000 +#define CCSR_GUTS_PMUXCR_UART0_I2C1_UART0_SSI 0x00010000 +#define CCSR_GUTS_PMUXCR_UART0_I2C1_SSI 0x00018000 + +#define CCSR_GUTS_PMUXCR_SSI_DMA_TDM_MASK 0x00000c00 +#define CCSR_GUTS_PMUXCR_SSI_DMA_TDM_SSI 0x00000000 + +#define CCSR_GUTS_DMUXCR_PAD 1 /* DMA controller/channel set to pad */ +#define CCSR_GUTS_DMUXCR_SSI 2 /* DMA controller/channel set to SSI */ + +/* + * Set the DMACR register in the GUTS + * + * The DMACR register determines the source of initiated transfers for each + * channel on each DMA controller. Rather than have a bunch of repetitive + * macros for the bit patterns, we just have a function that calculates + * them. + * + * guts: Pointer to GUTS structure + * co: The DMA controller (0 or 1) + * ch: The channel on the DMA controller (0, 1, 2, or 3) + * device: The device to set as the target (CCSR_GUTS_DMUXCR_xxx) + */ +static inline void guts_set_dmuxcr(struct ccsr_guts __iomem *guts, + unsigned int co, unsigned int ch, unsigned int device) +{ + unsigned int shift = 16 + (8 * (1 - co) + 2 * (3 - ch)); + + clrsetbits_be32(&guts->dmuxcr, 3 << shift, device << shift); +} + +/* There's only one global utilities register */ +static phys_addr_t guts_phys; + +/** + * machine_data: machine-specific ASoC device data + * + * This structure contains data for a single sound platform device on an + * P1022 RDK. Some of the data is taken from the device tree. + */ +struct machine_data { + struct snd_soc_dai_link dai[2]; + struct snd_soc_card card; + unsigned int dai_format; + unsigned int codec_clk_direction; + unsigned int cpu_clk_direction; + unsigned int clk_frequency; + unsigned int dma_id[2]; /* 0 = DMA1, 1 = DMA2, etc */ + unsigned int dma_channel_id[2]; /* 0 = ch 0, 1 = ch 1, etc*/ + char platform_name[2][DAI_NAME_SIZE]; /* One for each DMA channel */ +}; + +/** + * p1022_rdk_machine_probe: initialize the board + * + * This function is used to initialize the board-specific hardware. + * + * Here we program the DMACR and PMUXCR registers. + */ +static int p1022_rdk_machine_probe(struct snd_soc_card *card) +{ + struct machine_data *mdata = + container_of(card, struct machine_data, card); + struct ccsr_guts __iomem *guts; + + guts = ioremap(guts_phys, sizeof(struct ccsr_guts)); + if (!guts) { + dev_err(card->dev, "could not map global utilities\n"); + return -ENOMEM; + } + + /* Enable SSI Tx signal */ + clrsetbits_be32(&guts->pmuxcr, CCSR_GUTS_PMUXCR_UART0_I2C1_MASK, + CCSR_GUTS_PMUXCR_UART0_I2C1_UART0_SSI); + + /* Enable SSI Rx signal */ + clrsetbits_be32(&guts->pmuxcr, CCSR_GUTS_PMUXCR_SSI_DMA_TDM_MASK, + CCSR_GUTS_PMUXCR_SSI_DMA_TDM_SSI); + + /* Enable DMA Channel for SSI */ + guts_set_dmuxcr(guts, mdata->dma_id[0], mdata->dma_channel_id[0], + CCSR_GUTS_DMUXCR_SSI); + + guts_set_dmuxcr(guts, mdata->dma_id[1], mdata->dma_channel_id[1], + CCSR_GUTS_DMUXCR_SSI); + + iounmap(guts); + + return 0; +} + +/** + * p1022_rdk_startup: program the board with various hardware parameters + * + * This function takes board-specific information, like clock frequencies + * and serial data formats, and passes that information to the codec and + * transport drivers. + */ +static int p1022_rdk_startup(struct snd_pcm_substream *substream) +{ + struct snd_soc_pcm_runtime *rtd = substream->private_data; + struct machine_data *mdata = + container_of(rtd->card, struct machine_data, card); + struct device *dev = rtd->card->dev; + int ret = 0; + + /* Tell the codec driver what the serial protocol is. */ + ret = snd_soc_dai_set_fmt(rtd->codec_dai, mdata->dai_format); + if (ret < 0) { + dev_err(dev, "could not set codec driver audio format (ret=%i)\n", + ret); + return ret; + } + + ret = snd_soc_dai_set_pll(rtd->codec_dai, 0, 0, mdata->clk_frequency, + mdata->clk_frequency); + if (ret < 0) { + dev_err(dev, "could not set codec PLL frequency (ret=%i)\n", + ret); + return ret; + } + + return 0; +} + +/** + * p1022_rdk_machine_remove: Remove the sound device + * + * This function is called to remove the sound device for one SSI. We + * de-program the DMACR and PMUXCR register. + */ +static int p1022_rdk_machine_remove(struct snd_soc_card *card) +{ + struct machine_data *mdata = + container_of(card, struct machine_data, card); + struct ccsr_guts __iomem *guts; + + guts = ioremap(guts_phys, sizeof(struct ccsr_guts)); + if (!guts) { + dev_err(card->dev, "could not map global utilities\n"); + return -ENOMEM; + } + + /* Restore the signal routing */ + clrbits32(&guts->pmuxcr, CCSR_GUTS_PMUXCR_UART0_I2C1_MASK); + clrbits32(&guts->pmuxcr, CCSR_GUTS_PMUXCR_SSI_DMA_TDM_MASK); + guts_set_dmuxcr(guts, mdata->dma_id[0], mdata->dma_channel_id[0], 0); + guts_set_dmuxcr(guts, mdata->dma_id[1], mdata->dma_channel_id[1], 0); + + iounmap(guts); + + return 0; +} + +/** + * p1022_rdk_ops: ASoC machine driver operations + */ +static struct snd_soc_ops p1022_rdk_ops = { + .startup = p1022_rdk_startup, +}; + +/** + * p1022_rdk_probe: platform probe function for the machine driver + * + * Although this is a machine driver, the SSI node is the "master" node with + * respect to audio hardware connections. Therefore, we create a new ASoC + * device for each new SSI node that has a codec attached. + */ +static int p1022_rdk_probe(struct platform_device *pdev) +{ + struct device *dev = pdev->dev.parent; + /* ssi_pdev is the platform device for the SSI node that probed us */ + struct platform_device *ssi_pdev = + container_of(dev, struct platform_device, dev); + struct device_node *np = ssi_pdev->dev.of_node; + struct device_node *codec_np = NULL; + struct machine_data *mdata; + const u32 *iprop; + int ret; + + /* Find the codec node for this SSI. */ + codec_np = of_parse_phandle(np, "codec-handle", 0); + if (!codec_np) { + dev_err(dev, "could not find codec node\n"); + return -EINVAL; + } + + mdata = kzalloc(sizeof(struct machine_data), GFP_KERNEL); + if (!mdata) { + ret = -ENOMEM; + goto error_put; + } + + mdata->dai[0].cpu_dai_name = dev_name(&ssi_pdev->dev); + mdata->dai[0].ops = &p1022_rdk_ops; + + /* ASoC core can match codec with device node */ + mdata->dai[0].codec_of_node = codec_np; + + /* + * We register two DAIs per SSI, one for playback and the other for + * capture. We support codecs that have separate DAIs for both playback + * and capture. + */ + memcpy(&mdata->dai[1], &mdata->dai[0], sizeof(struct snd_soc_dai_link)); + + /* The DAI names from the codec (snd_soc_dai_driver.name) */ + mdata->dai[0].codec_dai_name = "wm8960-hifi"; + mdata->dai[1].codec_dai_name = mdata->dai[0].codec_dai_name; + + /* + * Configure the SSI for I2S slave mode. Older device trees have + * an fsl,mode property, but we ignore that since there's really + * only one way to configure the SSI. + */ + mdata->dai_format = SND_SOC_DAIFMT_NB_NF | + SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_CBM_CFM; + mdata->codec_clk_direction = SND_SOC_CLOCK_OUT; + mdata->cpu_clk_direction = SND_SOC_CLOCK_IN; + + /* + * In i2s-slave mode, the codec has its own clock source, so we + * need to get the frequency from the device tree and pass it to + * the codec driver. + */ + iprop = of_get_property(codec_np, "clock-frequency", NULL); + if (!iprop || !*iprop) { + dev_err(&pdev->dev, "codec bus-frequency property is missing or invalid\n"); + ret = -EINVAL; + goto error; + } + mdata->clk_frequency = be32_to_cpup(iprop); + + if (!mdata->clk_frequency) { + dev_err(&pdev->dev, "unknown clock frequency\n"); + ret = -EINVAL; + goto error; + } + + /* Find the playback DMA channel to use. */ + mdata->dai[0].platform_name = mdata->platform_name[0]; + ret = fsl_asoc_get_dma_channel(np, "fsl,playback-dma", &mdata->dai[0], + &mdata->dma_channel_id[0], + &mdata->dma_id[0]); + if (ret) { + dev_err(&pdev->dev, "missing/invalid playback DMA phandle (ret=%i)\n", + ret); + goto error; + } + + /* Find the capture DMA channel to use. */ + mdata->dai[1].platform_name = mdata->platform_name[1]; + ret = fsl_asoc_get_dma_channel(np, "fsl,capture-dma", &mdata->dai[1], + &mdata->dma_channel_id[1], + &mdata->dma_id[1]); + if (ret) { + dev_err(&pdev->dev, "missing/invalid capture DMA phandle (ret=%i)\n", + ret); + goto error; + } + + /* Initialize our DAI data structure. */ + mdata->dai[0].stream_name = "playback"; + mdata->dai[1].stream_name = "capture"; + mdata->dai[0].name = mdata->dai[0].stream_name; + mdata->dai[1].name = mdata->dai[1].stream_name; + + mdata->card.probe = p1022_rdk_machine_probe; + mdata->card.remove = p1022_rdk_machine_remove; + mdata->card.name = pdev->name; /* The platform driver name */ + mdata->card.owner = THIS_MODULE; + mdata->card.dev = &pdev->dev; + mdata->card.num_links = 2; + mdata->card.dai_link = mdata->dai; + + /* Register with ASoC */ + ret = snd_soc_register_card(&mdata->card); + if (ret) { + dev_err(&pdev->dev, "could not register card (ret=%i)\n", ret); + goto error; + } + + return 0; + +error: + kfree(mdata); +error_put: + of_node_put(codec_np); + return ret; +} + +/** + * p1022_rdk_remove: remove the platform device + * + * This function is called when the platform device is removed. + */ +static int __devexit p1022_rdk_remove(struct platform_device *pdev) +{ + struct snd_soc_card *card = platform_get_drvdata(pdev); + struct machine_data *mdata = + container_of(card, struct machine_data, card); + + snd_soc_unregister_card(card); + kfree(mdata); + + return 0; +} + +static struct platform_driver p1022_rdk_driver = { + .probe = p1022_rdk_probe, + .remove = __devexit_p(p1022_rdk_remove), + .driver = { + /* + * The name must match 'compatible' property in the device tree, + * in lowercase letters. + */ + .name = "snd-soc-p1022rdk", + .owner = THIS_MODULE, + }, +}; + +/** + * p1022_rdk_init: machine driver initialization. + * + * This function is called when this module is loaded. + */ +static int __init p1022_rdk_init(void) +{ + struct device_node *guts_np; + struct resource res; + + /* 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("snd-soc-p1022rdk: missing/invalid global utils node\n"); + of_node_put(guts_np); + return -EINVAL; + } + guts_phys = res.start; + of_node_put(guts_np); + + return platform_driver_register(&p1022_rdk_driver); +} + +/** + * p1022_rdk_exit: machine driver exit + * + * This function is called when this driver is unloaded. + */ +static void __exit p1022_rdk_exit(void) +{ + platform_driver_unregister(&p1022_rdk_driver); +} + +late_initcall(p1022_rdk_init); +module_exit(p1022_rdk_exit); + +MODULE_AUTHOR("Timur Tabi <timur(a)freescale.com>"); +MODULE_DESCRIPTION("Freescale / iVeia P1022 RDK ALSA SoC machine driver"); +MODULE_LICENSE("GPL v2"); -- 1.7.3.4

3 2

[alsa-devel] VOIP xrun problem
by Jamey Drennan 22 Oct '12

22 Oct '12

A quick background: I'm developing a VOIP program for an embedded system. In the first phase of the program everything was event driven. Basically ask ALSA for samples, encode them, and send them via UDP to the connected client. On the other end, receive the packet, decode, play the samples. After setting the correct value for the start_threshold function everything worked great no xruns at all. Now in the second phase, events are timed due to specification requirements. The same Alsa setup code is used yet xruns (mostly underruns) are all over the place. The underruns are periodic and can be reduced by increasing the period size and number of periods (this also increases the latency obviously and is undersirable) but never removed completely. My question is how to reduce/remove the xruns. I am not currently at a point where installing a real-time OS or patching to get these features is possible. Also, when aplay/arecord is run on the system, no xruns occur. Finally, the CPU is not being overloaded, actually in the second phase the CPU usage is much less. Any help/suggestions are greatly appreciated. Thanks in advance!

1 0

Re: [alsa-devel] A reliable kernel panic (3.6.2) and system crash when visiting a particular website
by Daniel Mack 22 Oct '12

22 Oct '12

On 22.10.2012 17:17, Alan Stern wrote: > On Sun, 21 Oct 2012, Artem S. Tashkinov wrote: > >> dmesg messages up to a crash can be seen here: https://bugzilla.kernel.org/attachment.cgi?id=84221 > > The first problem in the log is endpoint list corruption. Here's a > debugging patch which should provide a little more information. Maybe add a BUG() after each of these dev_err() so we stop at the first occurance and also see where we're coming from? > drivers/usb/core/hcd.c | 36 ++++++++++++++++++++++++++++++++++++ > 1 file changed, 36 insertions(+) > > Index: usb-3.6/drivers/usb/core/hcd.c > =================================================================== > --- usb-3.6.orig/drivers/usb/core/hcd.c > +++ usb-3.6/drivers/usb/core/hcd.c > @@ -1083,6 +1083,8 @@ EXPORT_SYMBOL_GPL(usb_calc_bus_time); > > /*-------------------------------------------------------------------------*/ > > +static bool list_error; > + > /** > * usb_hcd_link_urb_to_ep - add an URB to its endpoint queue > * @hcd: host controller to which @urb was submitted > @@ -1126,6 +1128,20 @@ int usb_hcd_link_urb_to_ep(struct usb_hc > */ > if (HCD_RH_RUNNING(hcd)) { > urb->unlinked = 0; > + > + { > + struct list_head *cur = &urb->ep->urb_list; > + struct list_head *prev = cur->prev; > + > + if (prev->next != cur && !list_error) { > + list_error = true; > + dev_err(&urb->dev->dev, > + "ep %x list add corruption: %p %p %p\n", > + urb->ep->desc.bEndpointAddress, > + cur, prev, prev->next); > + } > + } > + > list_add_tail(&urb->urb_list, &urb->ep->urb_list); > } else { > rc = -ESHUTDOWN; > @@ -1193,6 +1209,26 @@ void usb_hcd_unlink_urb_from_ep(struct u > { > /* clear all state linking urb to this dev (and hcd) */ > spin_lock(&hcd_urb_list_lock); > + { > + struct list_head *cur = &urb->urb_list; > + struct list_head *prev = cur->prev; > + struct list_head *next = cur->next; > + > + if (prev->next != cur && !list_error) { > + list_error = true; > + dev_err(&urb->dev->dev, > + "ep %x list del corruption prev: %p %p %p\n", > + urb->ep->desc.bEndpointAddress, > + cur, prev, prev->next); > + } > + if (next->prev != cur && !list_error) { > + list_error = true; > + dev_err(&urb->dev->dev, > + "ep %x list del corruption next: %p %p %p\n", > + urb->ep->desc.bEndpointAddress, > + cur, next, next->prev); > + } > + } > list_del_init(&urb->urb_list); > spin_unlock(&hcd_urb_list_lock); > } >

1 0

[alsa-devel] [PATCH repost] ASoC: fsl/pcm030 add unique dai_link names
by Eric Millbrandt 22 Oct '12

22 Oct '12

Assign each dai_link a unique name to avoid this run-time error. [ 18.978043] pcm030-audio-fabric sound.2: wm9712-hifi <-> mpc5200-psc-ac97.0 mapping ok [ 19.003179] sysfs: cannot create duplicate filename '/devices/sound.2/AC97' Signed-off-by: Eric Millbrandt <emillbrandt(a)dekaresearch.com> --- sound/soc/fsl/pcm030-audio-fabric.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/fsl/pcm030-audio-fabric.c b/sound/soc/fsl/pcm030-audio-fabric.c index 4b63ec8..4d26192 100644 --- a/sound/soc/fsl/pcm030-audio-fabric.c +++ b/sound/soc/fsl/pcm030-audio-fabric.c @@ -29,14 +29,14 @@ struct pcm030_audio_data { static struct snd_soc_dai_link pcm030_fabric_dai[] = { { - .name = "AC97", + .name = "AC97.0", .stream_name = "AC97 Analog", .codec_dai_name = "wm9712-hifi", .cpu_dai_name = "mpc5200-psc-ac97.0", .codec_name = "wm9712-codec", }, { - .name = "AC97", + .name = "AC97.1", .stream_name = "AC97 IEC958", .codec_dai_name = "wm9712-aux", .cpu_dai_name = "mpc5200-psc-ac97.1", -- 1.7.8

2 1

Re: [alsa-devel] [PATCH] check for the kzalloc return value
by Takashi Iwai 22 Oct '12

22 Oct '12

At Mon, 22 Oct 2012 17:05:53 +0400, Denis Kirjanov wrote: > > > Signed-off-by: Denis Kirjanov <kirjanov(a)gmail.com> Thanks, applied. Takashi > --- > sound/pci/als300.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/sound/pci/als300.c b/sound/pci/als300.c > index 68c4469..e1f74d4 100644 > --- a/sound/pci/als300.c > +++ b/sound/pci/als300.c > @@ -394,6 +394,8 @@ static int snd_als300_playback_open(struct snd_pcm_substream *substream) > struct snd_als300_substream_data *data = kzalloc(sizeof(*data), > GFP_KERNEL); > > + if (!data) > + return -ENOMEM; > snd_als300_dbgcallenter(); > chip->playback_substream = substream; > runtime->hw = snd_als300_playback_hw; > @@ -425,6 +427,8 @@ static int snd_als300_capture_open(struct snd_pcm_substream *substream) > struct snd_als300_substream_data *data = kzalloc(sizeof(*data), > GFP_KERNEL); > > + if (!data) > + return -ENOMEM; > snd_als300_dbgcallenter(); > chip->capture_substream = substream; > runtime->hw = snd_als300_capture_hw; > -- > 1.7.9.5 >

1 0

[alsa-devel] [PATCH resend 1/2] ASoC: davinci: replace private sram api with genalloc
by Daniel Mack 22 Oct '12

22 Oct '12

From: Matt Porter <mporter(a)ti.com> Removes the DaVinci private SRAM API and replaces it with the genalloc API. The SRAM gen_pool is passed in pdata since DaVinci is in the early stages of DT conversion. [zonque(a)gmail.com: stub out gen_pool functions for !CONFIG_GENERIC_ALLOCATOR] Signed-off-by: Matt Porter <mporter(a)ti.com> --- include/linux/platform_data/davinci_asp.h | 3 +++ sound/soc/davinci/davinci-mcasp.c | 2 ++ sound/soc/davinci/davinci-pcm.c | 37 ++++++++++++++++++++++++++----- sound/soc/davinci/davinci-pcm.h | 2 ++ 4 files changed, 38 insertions(+), 6 deletions(-) diff --git a/include/linux/platform_data/davinci_asp.h b/include/linux/platform_data/davinci_asp.h index d0c5825..f3d6e4f 100644 --- a/include/linux/platform_data/davinci_asp.h +++ b/include/linux/platform_data/davinci_asp.h @@ -16,6 +16,8 @@ #ifndef __DAVINCI_ASP_H #define __DAVINCI_ASP_H +#include <linux/genalloc.h> + struct snd_platform_data { u32 tx_dma_offset; u32 rx_dma_offset; @@ -30,6 +32,7 @@ struct snd_platform_data { unsigned enable_channel_combine:1; unsigned sram_size_playback; unsigned sram_size_capture; + struct gen_pool *sram_pool; /* * If McBSP peripheral gets the clock from an external pin, diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c index 714e51e..52194bb 100644 --- a/sound/soc/davinci/davinci-mcasp.c +++ b/sound/soc/davinci/davinci-mcasp.c @@ -1098,6 +1098,7 @@ static int davinci_mcasp_probe(struct platform_device *pdev) dma_data = &dev->dma_params[SNDRV_PCM_STREAM_PLAYBACK]; dma_data->asp_chan_q = pdata->asp_chan_q; dma_data->ram_chan_q = pdata->ram_chan_q; + dma_data->sram_pool = pdata->sram_pool; dma_data->sram_size = pdata->sram_size_playback; dma_data->dma_addr = (dma_addr_t) (pdata->tx_dma_offset + mem->start); @@ -1115,6 +1116,7 @@ static int davinci_mcasp_probe(struct platform_device *pdev) dma_data = &dev->dma_params[SNDRV_PCM_STREAM_CAPTURE]; dma_data->asp_chan_q = pdata->asp_chan_q; dma_data->ram_chan_q = pdata->ram_chan_q; + dma_data->sram_pool = pdata->sram_pool; dma_data->sram_size = pdata->sram_size_capture; dma_data->dma_addr = (dma_addr_t)(pdata->rx_dma_offset + mem->start); diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c index 93ea3bf..0ae7b6d 100644 --- a/sound/soc/davinci/davinci-pcm.c +++ b/sound/soc/davinci/davinci-pcm.c @@ -16,6 +16,7 @@ #include <linux/slab.h> #include <linux/dma-mapping.h> #include <linux/kernel.h> +#include <linux/genalloc.h> #include <sound/core.h> #include <sound/pcm.h> @@ -23,7 +24,6 @@ #include <sound/soc.h> #include <asm/dma.h> -#include <mach/sram.h> #include "davinci-pcm.h" @@ -259,7 +259,9 @@ static void davinci_pcm_dma_irq(unsigned link, u16 ch_status, void *data) } } -static int allocate_sram(struct snd_pcm_substream *substream, unsigned size, +#ifdef CONFIG_GENERIC_ALLOCATOR +static int allocate_sram(struct snd_pcm_substream *substream, + struct gen_pool *sram_pool, unsigned size, struct snd_pcm_hardware *ppcm) { struct snd_dma_buffer *buf = &substream->dma_buffer; @@ -271,9 +273,10 @@ static int allocate_sram(struct snd_pcm_substream *substream, unsigned size, return 0; ppcm->period_bytes_max = size; - iram_virt = sram_alloc(size, &iram_phys); + iram_virt = (void *)gen_pool_alloc(sram_pool, size); if (!iram_virt) goto exit1; + iram_phys = gen_pool_virt_to_phys(sram_pool, (unsigned)iram_virt); iram_dma = kzalloc(sizeof(*iram_dma), GFP_KERNEL); if (!iram_dma) goto exit2; @@ -285,11 +288,33 @@ static int allocate_sram(struct snd_pcm_substream *substream, unsigned size, return 0; exit2: if (iram_virt) - sram_free(iram_virt, size); + gen_pool_free(sram_pool, (unsigned)iram_virt, size); exit1: return -ENOMEM; } +static void davinci_free_sram(struct snd_pcm_substream *substream, + struct snd_dma_buffer *iram_dma) +{ + struct davinci_runtime_data *prtd = substream->runtime->private_data; + struct gen_pool *sram_pool = prtd->params->sram_pool; + + gen_pool_free(sram_pool, (unsigned) iram_dma->area, iram_dma->bytes); +} +#else +static int allocate_sram(struct snd_pcm_substream *substream, + struct gen_pool *sram_pool, unsigned size, + struct snd_pcm_hardware *ppcm) +{ + return 0; +} + +static void davinci_free_sram(struct snd_pcm_substream *substream, + struct snd_dma_buffer *iram_dma) +{ +} +#endif + /* * Only used with ping/pong. * This is called after runtime->dma_addr, period_bytes and data_type are valid @@ -676,7 +701,7 @@ static int davinci_pcm_open(struct snd_pcm_substream *substream) ppcm = (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) ? &pcm_hardware_playback : &pcm_hardware_capture; - allocate_sram(substream, params->sram_size, ppcm); + allocate_sram(substream, params->sram_pool, params->sram_size, ppcm); snd_soc_set_runtime_hwparams(substream, ppcm); /* ensure that buffer size is a multiple of period size */ ret = snd_pcm_hw_constraint_integer(runtime, @@ -819,7 +844,7 @@ static void davinci_pcm_free(struct snd_pcm *pcm) buf->area = NULL; iram_dma = buf->private_data; if (iram_dma) { - sram_free(iram_dma->area, iram_dma->bytes); + davinci_free_sram(substream, iram_dma); kfree(iram_dma); } } diff --git a/sound/soc/davinci/davinci-pcm.h b/sound/soc/davinci/davinci-pcm.h index fc4d01c..b6ef703 100644 --- a/sound/soc/davinci/davinci-pcm.h +++ b/sound/soc/davinci/davinci-pcm.h @@ -12,6 +12,7 @@ #ifndef _DAVINCI_PCM_H #define _DAVINCI_PCM_H +#include <linux/genalloc.h> #include <linux/platform_data/davinci_asp.h> #include <mach/edma.h> @@ -20,6 +21,7 @@ struct davinci_pcm_dma_params { unsigned short acnt; dma_addr_t dma_addr; /* device physical address for DMA */ unsigned sram_size; + struct gen_pool *sram_pool; /* SRAM gen_pool for ping pong */ enum dma_event_q asp_chan_q; /* event queue number for ASP channel */ enum dma_event_q ram_chan_q; /* event queue number for RAM channel */ unsigned char data_type; /* xfer data type */ -- 1.7.11.7

2 2

[alsa-devel] [PATCH] ASoC: jack: remove unused variable in snd_soc_jack_report()
by Wei Yongjun 22 Oct '12

22 Oct '12

From: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> The variable oldstatus is initialized but never used otherwise, so remove the unused variable. dpatch engine is used to auto generate this patch. (https://github.com/weiyj/dpatch) Signed-off-by: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> --- sound/soc/soc-jack.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/sound/soc/soc-jack.c b/sound/soc/soc-jack.c index fa0fd8d..933eb25 100644 --- a/sound/soc/soc-jack.c +++ b/sound/soc/soc-jack.c @@ -66,7 +66,6 @@ void snd_soc_jack_report(struct snd_soc_jack *jack, int status, int mask) struct snd_soc_dapm_context *dapm; struct snd_soc_jack_pin *pin; int enable; - int oldstatus; trace_snd_soc_jack_report(jack, mask, status); @@ -78,8 +77,6 @@ void snd_soc_jack_report(struct snd_soc_jack *jack, int status, int mask) mutex_lock(&jack->mutex); - oldstatus = jack->status; - jack->status &= ~mask; jack->status |= status & mask;

2 1

[alsa-devel] [PATCH -next] ASoC: fix wm2200.c printk format warnings
by Randy Dunlap 22 Oct '12

22 Oct '12

From: Randy Dunlap <rdunlap(a)xenotime.net> Fix wm2200.c printk format warnings (seen on x86_64): sound/soc/codecs/wm2200.c:1027:4: warning: format '%d' expects type 'int', but argument 4 has type 'size_t' sound/soc/codecs/wm2200.c:1139:5: warning: format '%d' expects type 'int', but argument 5 has type 'long unsigned int' sound/soc/codecs/wm2200.c:1181:2: warning: format '%d' expects type 'int', but argument 7 has type 'size_t' sound/soc/codecs/wm2200.c:1201:5: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'long unsigned int' sound/soc/codecs/wm2200.c:1264:4: warning: format '%d' expects type 'int', but argument 4 has type 'size_t' sound/soc/codecs/wm2200.c:1328:5: warning: format '%d' expects type 'int', but argument 5 has type 'long unsigned int' Signed-off-by: Randy Dunlap <rdunlap(a)xenotime.net> Cc: Liam Girdwood <lrg(a)ti.com> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Cc: alsa-devel(a)alsa-project.org (moderated for non-subscribers) --- sound/soc/codecs/wm2200.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- linux-next-20121019.orig/sound/soc/codecs/wm2200.c +++ linux-next-20121019/sound/soc/codecs/wm2200.c @@ -1023,7 +1023,7 @@ static int wm2200_dsp_load(struct snd_so pos = sizeof(*header) + sizeof(*adsp1_sizes) + sizeof(*footer); if (pos >= firmware->size) { - dev_err(codec->dev, "%s: file too short, %d bytes\n", + dev_err(codec->dev, "%s: file too short, %zu bytes\n", file, firmware->size); return -EINVAL; } @@ -1135,7 +1135,7 @@ static int wm2200_dsp_load(struct snd_so } if (pos > firmware->size) - dev_warn(codec->dev, "%s.%d: %d bytes at end of file\n", + dev_warn(codec->dev, "%s.%d: %zu bytes at end of file\n", file, regions, pos - firmware->size); out: @@ -1178,7 +1178,7 @@ static int wm2200_setup_algs(struct snd_ } algs = be32_to_cpu(id.algs); - dev_info(codec->dev, "Firmware: %x v%d.%d.%d, %d algorithms\n", + dev_info(codec->dev, "Firmware: %x v%d.%d.%d, %zu algorithms\n", be32_to_cpu(id.fw.id), (be32_to_cpu(id.fw.ver) & 0xff000) >> 16, (be32_to_cpu(id.fw.ver) & 0xff00) >> 8, @@ -1196,7 +1196,7 @@ static int wm2200_setup_algs(struct snd_ } if (be32_to_cpu(val) != 0xbedead) - dev_warn(codec->dev, "Algorithm list end %x 0x%x != 0xbeadead\n", + dev_warn(codec->dev, "Algorithm list end %zx 0x%x != 0xbeadead\n", (sizeof(id) + (algs * sizeof(*alg))) / 2, be32_to_cpu(val)); @@ -1260,7 +1260,7 @@ static int wm2200_load_coeff(struct snd_ } if (sizeof(*hdr) >= firmware->size) { - dev_err(codec->dev, "%s: file too short, %d bytes\n", + dev_err(codec->dev, "%s: file too short, %zu bytes\n", file, firmware->size); return -EINVAL; } @@ -1324,7 +1324,7 @@ static int wm2200_load_coeff(struct snd_ } if (pos > firmware->size) - dev_warn(codec->dev, "%s.%d: %d bytes at end of file\n", + dev_warn(codec->dev, "%s.%d: %zu bytes at end of file\n", file, blocks, pos - firmware->size); return 0;

2 1

Re: [alsa-devel] [PATCH 2/2] ASoC: Ux500: Control apb clock
by Mark Brown 22 Oct '12

22 Oct '12

On Mon, Oct 22, 2012 at 02:32:05PM +0200, Ulf Hansson wrote: > From: Ulf Hansson <ulf.hansson(a)linaro.org> > > When switching to common clock driver for ux500 this clock needs to > be handled as well. Before this clock was internally managed by the > clock driver itself. Applied but why isn't this a deficiency in the common clock implementation for the platform?

1 0

Re: [alsa-devel] [PATCH 1/2] ASoC: Ux500: Fixup use of clocks
by Mark Brown 22 Oct '12

22 Oct '12

On Mon, Oct 22, 2012 at 02:32:04PM +0200, Ulf Hansson wrote: > From: Ulf Hansson <ulf.hansson(a)linaro.org> > > Make sure clocks are being prepared and unprepared as well > as enabled and disabled. Applied, thanks.

1 0

Re: [alsa-devel] [PATCH 2/2] ASoC: Ux500: Control apb clock
by Linus Walleij 22 Oct '12

22 Oct '12

On Mon, Oct 22, 2012 at 2:32 PM, Ulf Hansson <ulf.hansson(a)stericsson.com> wrote: > From: Ulf Hansson <ulf.hansson(a)linaro.org> > > When switching to common clock driver for ux500 this clock needs to > be handled as well. Before this clock was internally managed by the > clock driver itself. > > Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Looks correct, Acked-by: Linus Walleij <linus.walleij(a)linaro.org> Yours, Linus Walleij

1 0

Re: [alsa-devel] [PATCH 1/2] ASoC: Ux500: Fixup use of clocks
by Linus Walleij 22 Oct '12

22 Oct '12

On Mon, Oct 22, 2012 at 2:32 PM, Ulf Hansson <ulf.hansson(a)stericsson.com> wrote: > From: Ulf Hansson <ulf.hansson(a)linaro.org> > > Make sure clocks are being prepared and unprepared as well > as enabled and disabled. > > Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Acked-by: Linus Walleij <linus.walleij(a)linaro.org> Thanks, Linus Walleij

1 0

[alsa-devel] dynamic PCM and dynamic DSP graphs
by Sebastien LEDUC 22 Oct '12

22 Oct '12

Hi Mark / Liam, We have started to use Dynamic PCM to manage our on-SoC DSP. In our case, the API exposed by the DSP is graph oriented, and allows to dynamically create and control the running graph on the DSP. What we are doing is that we use DAPM widgets and routes to manage the DSP graph dynamically: We use some dedicated widgets that have power callbacks. When a widget is powered on/off, the callback will use the DSP API to create/destroy the corresponding parts of the DSP graph. We wanted to get your feedback on this approach, so as to be sure it won't be an issue when we want to mainline our driver. We can of course share more details if needed, or even some preliminary version of the driver. Thanks in advance for your feedback Regards Sebastien

3 4

[alsa-devel] [sound-unstable:topic/hda-spdif-fix 99/124] ERROR: "snd_dmaengine_pcm_open" [sound/soc/omap/snd-soc-omap.ko] undefined!
by Fengguang Wu 22 Oct '12

22 Oct '12

Hi Peter, FYI, kernel build failed on tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable.git topic/hda-spdif-fix head: afc51e492b36bd61b46f4d70dd646678d96f5f97 commit: e7736cdea223f3a5b867c359fb35cf08250dd771 [99/124] dmaengine: Add flags parameter to dmaengine_prep_dma_cyclic() config: arm-omap2plus_defconfig # make ARCH=arm omap2plus_defconfig All error/warnings: ERROR: "snd_hwparams_to_dma_slave_config" [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: "snd_dmaengine_pcm_pointer" [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: "snd_dmaengine_pcm_open" [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: "snd_dmaengine_pcm_close" [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: "snd_dmaengine_pcm_get_chan" [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: "snd_dmaengine_pcm_trigger" [sound/soc/omap/snd-soc-omap.ko] undefined! --- 0-DAY kernel build testing backend Open Source Technology Center Fengguang Wu, Yuanhan Liu Intel Corporation

3 5

Re: [alsa-devel] [PATCH] ALSA: hda - remove unused variable in azx_position_ok()
by Takashi Iwai 22 Oct '12

22 Oct '12

At Mon, 22 Oct 2012 16:30:10 +0800, Wei Yongjun wrote: > > From: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> > > The variable stream is initialized but never used > otherwise, so remove the unused variable. > > dpatch engine is used to auto generate this patch. > (https://github.com/weiyj/dpatch) > > Signed-off-by: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> Thanks, applied. Takashi > --- > sound/pci/hda/hda_intel.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c > index 72b085a..0ceed85 100644 > --- a/sound/pci/hda/hda_intel.c > +++ b/sound/pci/hda/hda_intel.c > @@ -2193,13 +2193,11 @@ static int azx_position_ok(struct azx *chip, struct azx_dev *azx_dev) > { > u32 wallclk; > unsigned int pos; > - int stream; > > wallclk = azx_readl(chip, WALLCLK) - azx_dev->start_wallclk; > if (wallclk < (azx_dev->period_wallclk * 2) / 3) > return -1; /* bogus (too early) interrupt */ > > - stream = azx_dev->substream->stream; > pos = azx_get_position(chip, azx_dev, true); > > if (WARN_ONCE(!azx_dev->period_bytes, >

1 0

Re: [alsa-devel] [PATCH 2/2] ASoC: Ux500: Fixup compile error
by Lee Jones 22 Oct '12

22 Oct '12

On Fri, 19 Oct 2012, Ulf Hansson wrote: > From: Ulf Hansson <ulf.hansson(a)linaro.org> > > The below commit introduced a compile error for a missing include file. > ASoC: ux500_msp_i2s: better use devm functions and fix error return code Already fixed: https://patchwork.kernel.org/patch/1593881/ -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

1 0

Re: [alsa-devel] [PATCH 1/2] ASoC: Ux500: Fixup complile errors due to merge
by Lee Jones 22 Oct '12

22 Oct '12

On Fri, 19 Oct 2012, Ulf Hansson wrote: > From: Ulf Hansson <ulf.hansson(a)linaro.org> > > Likely during merge of the below commits ended up breaking compilation: > ASoC: Ux500: Enable ux500 MSP driver for Device Tree > ASoC: ux500_msp_i2s: better use devm functions and fix error return code This is already fixed: https://patchwork.kernel.org/patch/1593881/ -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog

1 0

Re: [alsa-devel] A reliable kernel panic (3.6.2) and system crash when visiting a particular website
by Daniel Mack 21 Oct '12

21 Oct '12

On 21.10.2012 22:43, Artem S. Tashkinov wrote: >> Nice. Could you do that again with the patch applied I sent yo some >> hours ago? > > That patch was of no help - the system has crashed and I couldn't spot relevant > messages. > > I've no idea what it means. The sequence of driver callbacks issued on a stream start is .open() .hw_params() .prepare() .trigger() If the ALSA part really causes this issue, the bad things happen either in any of the driver callback functions or in the core underneath. The patch I sent returns an error from the hw_params callback, and as you still see the problem, that means that the crash happens before any of the USB audio streaming really starts. Could you try and return -EINVAL from snd_usb_capture_open() please? If anyone has a better idea on how to debug this, please chime in. Daniel

1 0

Re: [alsa-devel] A reliable kernel panic (3.6.2) and system crash when visiting a particular website
by Daniel Mack 21 Oct '12

21 Oct '12

On 21.10.2012 21:49, Artem S. Tashkinov wrote: >> >> On Oct 21, 2012, Borislav Petkov <bp(a)alien8.de> wrote: >> >> On Sun, Oct 21, 2012 at 11:59:36AM +0000, Artem S. Tashkinov wrote: >>> http://imageshack.us/a/img685/9452/panicz.jpg >>> >>> list_del corruption. prev->next should be ... but was ... >> >> Btw, this is one of the debug options I told you to enable. >> >>> I cannot show you more as I have no serial console to use :( and the kernel >>> doesn't have enough time to push error messages to rsyslog and fsync >>> /var/log/messages >> >> I already told you how to catch that oops: boot with "pause_on_oops=600" >> on the kernel command line and photograph the screen when the first oops >> happens. This'll show us where the problem begins. > > This option didn't have any effect, or maybe it's because it's such a serious crash > the kernel has no time to actually print an ooops/panic message. > > dmesg messages up to a crash can be seen here: https://bugzilla.kernel.org/attachment.cgi?id=84221 Nice. Could you do that again with the patch applied I sent yo some hours ago? Thanks, Daniel

1 0

Re: [alsa-devel] was: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
by Daniel Mack 21 Oct '12

21 Oct '12

On Oct 21, 2012 5:28 PM, "Alan Stern" <stern(a)rowland.harvard.edu> wrote: > > On Sun, 21 Oct 2012, Daniel Mack wrote: > > > As the usb list is still in Cc: - Artem's lcpci dump shows that his > > machine features XHCI controllers. Can anyone think of a relation to > > this problem? > > > > And Artem, is there any way you boot your system on an older machine > > that only has EHCI ports? Thinking about it, I wonder whether the freeze > > in VBox and the crashes on native hardware have the same root cause. In > > that case, would it be possible to share that VBox image? > > Don't grasp at straws. All of the kernel logs Artem has posted show > ehci-hcd; none of them show xhci-hcd. Therefore the xHCI controller is > highly unlikely to be involved. You might be right - I'm just looking for differences between his setup and mine that would explain why nobody else sees a severe bug that is 100% reproducible for him.

1 0

Re: [alsa-devel] was: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
by Daniel Mack 21 Oct '12

21 Oct '12

On 21.10.2012 16:57, Artem S. Tashkinov wrote: >> On Oct 21, 2012, Daniel Mack wrote: >> >> [Cc: alsa-devel] >> >> On 21.10.2012 14:30, Artem S. Tashkinov wrote: >>> On Oct 21, 2012, Daniel Mack wrote: >>> >>>> A hint at least. How did you enable the audio record exactly? Can you >>>> reproduce this with arecord? >>>> >>>> What chipset are you on? Please provide both "lspci -v" and "lsusb -v" >>>> dumps. As I said, I fail to reproduce that issue on any of my machines. >>> >>> All other applications can read from the USB audio without problems, it's >>> just something in the way Adobe Flash polls my audio input which causes >>> a crash. >>> >>> Just video capture (without audio) works just fine in Adobe Flash. >> >> Ok, so that pretty much rules out the host controller. I just wonder why >> I still don't see it here, and I haven't heard of any such problem from >> anyone else. >> >> Some more questions: >> >> - Which version of Flash are you running? > > Google Chrome has its own version of Adobe Flash: > > Name: Shockwave Flash > Description: Shockwave Flash 11.4 r31 > Version: 11.4.31.110 So that's the same that I'm using. >> - Does this also happen with Firefox? > > No, Adobe Flash in Firefox is an older version (Shockwave Flash 11.1 r102), it shows > just two input devices instead of three which the newer Flash players sees. > > * HDA Intel PCH > * USB Device 0x46d:0x81d And that works, I assume? Does the second choice in the newer Flash version work maybe? >> - Does flash access the device directly or via PulseAudio? > > PA is not installed on my computer, so Flash accesses it directly via ALSA calls. Ok, Same here. >> - Could you please apply the attached patch and see what it spits out to >> dmesg once Flash opens the device? It returns -EINVAL in the hw_params >> callback to prevent the actual streaming. On my machine with Flash >> 11.4.31.110, I get values of 2/44800/1/32768/2048/0, which seems sane. >> Or does your machine still crash before anything is written to the logs? > > I will try it a bit later. Yes, we need to trace the call chain and see at which point the trouble starts. What could help is tracing the google-chrome binary with strace maybe. At least we would see the ioctl command sequence, if the log file survives the crash. As the usb list is still in Cc: - Artem's lcpci dump shows that his machine features XHCI controllers. Can anyone think of a relation to this problem? And Artem, is there any way you boot your system on an older machine that only has EHCI ports? Thinking about it, I wonder whether the freeze in VBox and the crashes on native hardware have the same root cause. In that case, would it be possible to share that VBox image? Daniel

1 0

Re: [alsa-devel] was: Re: A reliable kernel panic (3.6.2) and system crash when visiting a particular website
by Daniel Mack 21 Oct '12

21 Oct '12

[Cc: alsa-devel] On 21.10.2012 14:30, Artem S. Tashkinov wrote: > On Oct 21, 2012, Daniel Mack wrote: > >> A hint at least. How did you enable the audio record exactly? Can you >> reproduce this with arecord? >> >> What chipset are you on? Please provide both "lspci -v" and "lsusb -v" >> dumps. As I said, I fail to reproduce that issue on any of my machines. > > All other applications can read from the USB audio without problems, it's > just something in the way Adobe Flash polls my audio input which causes > a crash. > > Just video capture (without audio) works just fine in Adobe Flash. Ok, so that pretty much rules out the host controller. I just wonder why I still don't see it here, and I haven't heard of any such problem from anyone else. Some more questions: - Which version of Flash are you running? - Does this also happen with Firefox? - Does flash access the device directly or via PulseAudio? - Could you please apply the attached patch and see what it spits out to dmesg once Flash opens the device? It returns -EINVAL in the hw_params callback to prevent the actual streaming. On my machine with Flash 11.4.31.110, I get values of 2/44800/1/32768/2048/0, which seems sane. Or does your machine still crash before anything is written to the logs? > Only and only when I choose to use > > USB Device 0x46d:0x81d my system crashes in Adobe Flash. > > See the screenshot: > > https://bugzilla.kernel.org/attachment.cgi?id=84151 When exactly does the crash happen? Right after you selected that entry from the list? There's a little recording level meter in that dialog. Does that show any input from the microphone? > My hardware information can be fetched from here: > > https://bugzilla.kernel.org/show_bug.cgi?id=49181 > > On a second thought that can be even an ALSA crash or pretty much > anything else. We'll see. Thanks for your help to sort this out! Daniel

1 0

[alsa-devel] usb-audio: Reloop Play support (TI TUSB3200AC)
by Didier 'Ptitjes' Villevalois 21 Oct '12

21 Oct '12

Hello, I've bought a Reloop Play usb soundcard and I'd like to make it work with ALSA. It is a 4-channels USB soundcard. It is currently correctly recognized by ALSA as a 4-channels soundcard and I can correctly open the channels and feed them with audio. However, no audio is output by the box. It seems to contain a Texas Instrument TUSB3200AC chipset (same chipset as the Maya44 USB and Hercules DJ console). I guess the problem is a firmware problem but I don't know what to do about it. I've got a MacOS X driver that works correctly, if that of any help. (I suppose the Windows driver works too but I don't have any Windows at hand.) I'm willing to do whatever you need me to make it run with ALSA. Could you help me ? I attached my alsa-info.sh output. Didier Villevalois.

3 5

[alsa-devel] softvol master has preference over virtual master in amixer
by Raymond Yau 21 Oct '12

21 Oct '12

does softvol plugin "master" has any preference over vmaster in amixer ? http://www.alsa-project.org/db/?f=44b26f5cd37f33bfef2871ff1fd250301bdb5364 control.32 { iface MIXER name 'Master Playback Volume' value 64 comment { access 'read write' type INTEGER count 1 range '0 - 64' dbmin -6400 dbmax 0 dbvalue.0 0 } } control.42 { iface MIXER name Master value.0 255 value.1 255 comment { access 'read write user' type INTEGER count 2 range '0 - 255' tlv '0000000100000008ffffec1400000014' dbmin -5100 dbmax 0 dbvalue.0 0 dbvalue.1 0 } Card hw:0 'Intel'/'HDA Intel at 0xfeaf8000 irq 43' Mixer name: 'Realtek ALC887-VD' Components: 'HDA:10ec0887,10438445,00100302' Controls : 42 Simple ctrls : 22 Simple mixer control 'Master',0 Capabilities: pvolume pswitch pswitch-joined penum Playback channels: Front Left - Front Right Limits: Playback 0 - 255 Mono: Front Left: Playback 255 [100%] [191.00dB] [on] Front Right: Playback 255 [100%] [191.00dB] [on] Simple mixer control 'Headphone',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 64 Mono: Front Left: Playback 64 [100%] [0.00dB] [on] Front Right: Playback 64 [100%] [0.00dB] [on] Simple mixer control 'PCM',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 255 Mono: Front Left: Playback 255 [100%] [0.00dB] Front Right: Playback 255 [100%] [0.00dB] https://launchpadlibrarian.net/119782219/Symptom_PulseAudioLog.txt Oct 15 10:49:11 xaser pulseaudio[1601]: [pulseaudio] alsa-util.c: Unable to load mixer: Invalid argument Oct 15 10:49:11 xaser pulseaudio[1601]: [pulseaudio] alsa-util.c: Unable to load mixer: Invalid argument Oct 15 10:49:11 xaser pulseaudio[1601]: [pulseaudio] alsa-util.c: Unable to load mixer: Invalid argument Oct 15 10:49:11 xaser pulseaudio[1601]: [pulseaudio] alsa-util.c: Unable to load mixer: Invalid argument Oct 15 10:49:12 xaser pulseaudio[1601]: [pulseaudio] alsa-util.c: Unable to load mixer: Invalid argument Oct 15 10:49:12 xaser pulseaudio[1601]: [pulseaudio] alsa-util.c: Unable to load mixer: Invalid argument Oct 15 10:49:12 xaser pulseaudio[1601]: [pulseaudio] alsa-util.c: Unable to load mixer: Invalid argument Oct 15 10:49:12 xaser pulseaudio[1601]: [pulseaudio] alsa-util.c: Unable to load mixer: Invalid argument Oct 15 10:49:12 xaser pulseaudio[1601]: [pulseaudio] alsa-util.c: Unable to load mixer: Invalid argument Oct 15 10:49:12 xaser pulseaudio[1601]: [pulseaudio] alsa-util.c: Unable to load mixer: Invalid argument

2 4

[alsa-devel] [PATCH 1/5] sound/isa/opti9xx/miro.c: eliminate possible double free
by Julia Lawall 21 Oct '12

21 Oct '12

From: Julia Lawall <Julia.Lawall(a)lip6.fr> snd_miro_probe is a static function that is only called twice in the file that defines it. At each call site, its argument is freed using snd_card_free. Thus, there is no need for snd_miro_probe to call snd_card_free on its argument on any of its error exit paths. Because snd_card_free both reads the fields of its argument and kfrees its argments, the results of the second snd_card_free should be unpredictable. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ identifier f,free,a; parameter list[n] ps; type T; expression e; @@ f(ps,T a,...) { ... when any when != a = e if(...) { ... free(a); ... return ...; } ... when any } @@ identifier r.f,r.free; expression x,a; expression list[r.n] xs; @@ * x = f(xs,a,...); if (...) { ... free(a); ... return ...; } // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall(a)lip6.fr> --- Not tested. sound/isa/opti9xx/miro.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/isa/opti9xx/miro.c b/sound/isa/opti9xx/miro.c index 3d1afb6..4a7ff4e 100644 --- a/sound/isa/opti9xx/miro.c +++ b/sound/isa/opti9xx/miro.c @@ -1286,7 +1286,6 @@ static int __devinit snd_miro_probe(struct snd_card *card) error = snd_card_miro_aci_detect(card, miro); if (error < 0) { - snd_card_free(card); snd_printk(KERN_ERR "unable to detect aci chip\n"); return -ENODEV; }

2 1

[alsa-devel] [PATCH 1/1] Add USB audio quirk supporting Roland VG-99 advanced mode
by pete.leigh＠gmail.com 21 Oct '12

21 Oct '12

From: Pete Leigh <pete.leigh(a)gmail.com> Signed-off-by: Pete Leigh <pete.leigh(a)gmail.com> diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h index 88d8ceb..ffeabf8 100644 --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -1457,6 +1457,40 @@ YAMAHA_DEVICE(0x7010, "UB99"), } }, { + /* Advanced mode of the Roland VG-99, with MIDI and 24-bit PCM at 44.1 + * kHz. In standard mode, the device has ID 0582:00b3, and offers + * 16-bit PCM at 44.1 kHz with no MIDI. + */ + USB_DEVICE(0x0582, 0x00b2), + .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { + .vendor_name = "Roland", + .product_name = "VG-99", + .ifnum = QUIRK_ANY_INTERFACE, + .type = QUIRK_COMPOSITE, + .data = (const struct snd_usb_audio_quirk[]) { + { + .ifnum = 0, + .type = QUIRK_AUDIO_STANDARD_INTERFACE + }, + { + .ifnum = 1, + .type = QUIRK_AUDIO_STANDARD_INTERFACE + }, + { + .ifnum = 2, + .type = QUIRK_MIDI_FIXED_ENDPOINT, + .data = & (const struct snd_usb_midi_endpoint_info) { + .out_cables = 0x0003, + .in_cables = 0x0003 + } + }, + { + .ifnum = -1 + } + } + } +}, +{ /* Roland SonicCell */ USB_DEVICE(0x0582, 0x00c2), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { -- 1.7.11.7

3 3

[alsa-devel] [PATCH 1/1] USB audio quirk for Roland VG-99 advanced mode
by pete.leigh＠gmail.com 21 Oct '12

21 Oct '12

From: Pete Leigh <pete.leigh(a)gmail.com> Without this quirk the VG-99 will work in standard mode (set under USB on System menu page 2) giving 16 bits at 44.1 Khz audio in/out but no midi, and is not recognised when set to advanced mode. After applying this, I can also use the VG-99 in advanced mode: 24 24 bits audio in/out at 44.1 Khz, and midi in/out. Sysex is so far untested. In standard mode, the device appears with ID 0x00b3, so the behaviour isn't affected by this quirk. Thanks to Clemens Ladisch for simplifying and correcting my initial attempt! Signed-off-by: Pete Leigh <pete.leigh(a)gmail.com> diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h index 88d8ceb..ffeabf8 100644 --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -1457,6 +1457,40 @@ YAMAHA_DEVICE(0x7010, "UB99"), } }, { + /* Advanced mode of the Roland VG-99, with MIDI and 24-bit PCM at 44.1 + * kHz. In standard mode, the device has ID 0582:00b3, and offers + * 16-bit PCM at 44.1 kHz with no MIDI. + */ + USB_DEVICE(0x0582, 0x00b2), + .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { + .vendor_name = "Roland", + .product_name = "VG-99", + .ifnum = QUIRK_ANY_INTERFACE, + .type = QUIRK_COMPOSITE, + .data = (const struct snd_usb_audio_quirk[]) { + { + .ifnum = 0, + .type = QUIRK_AUDIO_STANDARD_INTERFACE + }, + { + .ifnum = 1, + .type = QUIRK_AUDIO_STANDARD_INTERFACE + }, + { + .ifnum = 2, + .type = QUIRK_MIDI_FIXED_ENDPOINT, + .data = & (const struct snd_usb_midi_endpoint_info) { + .out_cables = 0x0003, + .in_cables = 0x0003 + } + }, + { + .ifnum = -1 + } + } + } +}, +{ /* Roland SonicCell */ USB_DEVICE(0x0582, 0x00c2), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { -- 1.7.11.7

1 0

[alsa-devel] [PATCH - my module 1/1] USB audio quirk for Roland VG-99 advanced mode
by pete.leigh＠gmail.com 21 Oct '12

21 Oct '12

From: Pete Leigh <pete.leigh(a)gmail.com> Without this quirk the VG-99 will work in standard mode (set under USB on System menu page 2) giving 16 bits at 44.1 Khz audio in/out but no midi, and is not recognised when set to advanced mode. After applying this, I can also use the VG-99 in advanced mode: 24 24 bits audio in/out at 44.1 Khz, and midi in/out. Sysex is so far untested. In standard mode, the device appears with ID 0x00b3, so the behaviour isn't affected by this quirk. Thanks to Clemens Ladisch for simplifying and correcting my initial attempt! Signed-off-by: Pete Leigh <pete.leigh(a)gmail.com> diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h index 88d8ceb..ffeabf8 100644 --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -1457,6 +1457,40 @@ YAMAHA_DEVICE(0x7010, "UB99"), } }, { + /* Advanced mode of the Roland VG-99, with MIDI and 24-bit PCM at 44.1 + * kHz. In standard mode, the device has ID 0582:00b3, and offers + * 16-bit PCM at 44.1 kHz with no MIDI. + */ + USB_DEVICE(0x0582, 0x00b2), + .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { + .vendor_name = "Roland", + .product_name = "VG-99", + .ifnum = QUIRK_ANY_INTERFACE, + .type = QUIRK_COMPOSITE, + .data = (const struct snd_usb_audio_quirk[]) { + { + .ifnum = 0, + .type = QUIRK_AUDIO_STANDARD_INTERFACE + }, + { + .ifnum = 1, + .type = QUIRK_AUDIO_STANDARD_INTERFACE + }, + { + .ifnum = 2, + .type = QUIRK_MIDI_FIXED_ENDPOINT, + .data = & (const struct snd_usb_midi_endpoint_info) { + .out_cables = 0x0003, + .in_cables = 0x0003 + } + }, + { + .ifnum = -1 + } + } + } +}, +{ /* Roland SonicCell */ USB_DEVICE(0x0582, 0x00c2), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { -- 1.7.11.7

2 1

[alsa-devel] [PATCH] ALSA: aloop - do not reschedule timer if deleted
by Omair Mohammed Abdullah 21 Oct '12

21 Oct '12

If the timer is deleted while the timer handler is running, it may get rescheduled and an unnecessary period elapsed will be sent. Add a flag to reschedule the timer only if it has not been stopped. Signed-off-by: Omair Mohammed Abdullah <omair.m.abdullah(a)linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul(a)linux.intel.com> --- sound/drivers/aloop.c | 21 ++++++++++++++++++--- 1 files changed, 18 insertions(+), 3 deletions(-) diff --git a/sound/drivers/aloop.c b/sound/drivers/aloop.c index 0fe6d64..fec4e17 100644 --- a/sound/drivers/aloop.c +++ b/sound/drivers/aloop.c @@ -121,6 +121,7 @@ struct loopback_pcm { unsigned long last_jiffies; struct timer_list timer; spinlock_t timer_lock; + bool timer_stopped; }; static struct platform_device *devices[SNDRV_CARDS]; @@ -166,12 +167,11 @@ static inline unsigned int get_rate_shift(struct loopback_pcm *dpcm) return get_setup(dpcm)->rate_shift; } -static void loopback_timer_start(struct loopback_pcm *dpcm) +static void do_timer_start(struct loopback_pcm *dpcm) { unsigned long tick; unsigned int rate_shift = get_rate_shift(dpcm); - spin_lock(&dpcm->timer_lock); if (rate_shift != dpcm->pcm_rate_shift) { dpcm->pcm_rate_shift = rate_shift; dpcm->period_size_frac = frac_pos(dpcm, dpcm->pcm_period_size); @@ -184,6 +184,13 @@ static void loopback_timer_start(struct loopback_pcm *dpcm) tick = (tick + dpcm->pcm_bps - 1) / dpcm->pcm_bps; dpcm->timer.expires = jiffies + tick; add_timer(&dpcm->timer); +} + +static inline void loopback_timer_start(struct loopback_pcm *dpcm) +{ + spin_lock(&dpcm->timer_lock); + dpcm->timer_stopped = false; + do_timer_start(dpcm); spin_unlock(&dpcm->timer_lock); } @@ -192,6 +199,7 @@ static inline void loopback_timer_stop(struct loopback_pcm *dpcm) spin_lock(&dpcm->timer_lock); del_timer(&dpcm->timer); dpcm->timer.expires = 0; + dpcm->timer_stopped = true; spin_unlock(&dpcm->timer_lock); } @@ -540,7 +548,13 @@ static void loopback_timer_function(unsigned long data) running = loopback_pos_update(dpcm->cable); if (running & (1 << dpcm->substream->stream)) { - loopback_timer_start(dpcm); + spin_lock(&dpcm->timer_lock); + if (dpcm->timer_stopped) { + spin_unlock(&dpcm->timer_lock); + return; + } + do_timer_start(dpcm); + spin_unlock(&dpcm->timer_lock); if (dpcm->period_update_pending) { dpcm->period_update_pending = 0; snd_pcm_period_elapsed(dpcm->substream); @@ -670,6 +684,7 @@ static int loopback_open(struct snd_pcm_substream *substream) } dpcm->loopback = loopback; dpcm->substream = substream; + dpcm->timer_stopped = true; setup_timer(&dpcm->timer, loopback_timer_function, (unsigned long)dpcm); spin_lock_init(&dpcm->timer_lock); -- 1.7.4.1

2 3

[alsa-devel] [PATCH] ALSA: snd-usb: remove unused variable in init_pitch_v2()
by Wei Yongjun 21 Oct '12

21 Oct '12

From: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> The variable ep is initialized but never used otherwise, so remove the unused variable. dpatch engine is used to auto generate this patch. (https://github.com/weiyj/dpatch) Signed-off-by: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> --- sound/usb/pcm.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c index 55e19e1..f77b87a 100644 --- a/sound/usb/pcm.c +++ b/sound/usb/pcm.c @@ -171,11 +171,8 @@ static int init_pitch_v2(struct snd_usb_audio *chip, int iface, { struct usb_device *dev = chip->dev; unsigned char data[1]; - unsigned int ep; int err; - ep = get_endpoint(alts, 0)->bEndpointAddress; - data[0] = 1; if ((err = snd_usb_ctl_msg(dev, usb_sndctrlpipe(dev, 0), UAC2_CS_CUR, USB_TYPE_CLASS | USB_RECIP_ENDPOINT | USB_DIR_OUT,

2 1

[alsa-devel] calling snd_ctl_notify from mixer ctl_put
by Ondrej Zary 21 Oct '12

21 Oct '12

Hello, I want to enable/disable some mixer controls based on state of another control (switching between limiter and AGC mode). So I (re)set the SNDRV_CTL_ELEM_ACCESS_INACTIVE flag in kctl->vd[0].access and then call snd_ctl_notify(card, SNDRV_CTL_EVENT_MASK_INFO, &kctl->id); Everyting from ctl_put() mixer callback. When changing the control value in alsamixer, it crashes with: alsamixer: simple.c:948: snd_mixer_selem_get_enum_item: Assertion `(elem)->type == SND_MIXER_ELEM_SIMPLE' failed. When the snd_ctl_notify() call is commented-out, it does not crash. There is snd_ctl_activate_id() function in sound/core/control.c (not used by any driver, btw.) which does the same, protected by card->controls_rwsem. However, it locks up on that semaphore when called from the mixer callback. Oxygen/Xonar WM8776 driver is doing the same thing - I wonder if I'm doing something wrong or if that driver crashes alsamixer too? Is there any way to do this properly? -- Ondrej Zary

3 3

Re: [alsa-devel] usb-audio: Reloop Play support (TI TUSB3200AC)
by Daniel Mack 20 Oct '12

20 Oct '12

On 20.10.2012 16:24, Didier Villevalois wrote: > OK this quirk works perfectly! (hooray!!!) > > /* Reloop Play */ > { > USB_DEVICE(0x200c, 0x100b), > .bInterfaceClass = USB_CLASS_PER_INTERFACE, > .driver_info = (unsigned long) &(const struct snd_usb_audio_quirk) { > .vendor_name = "Reloop", > .product_name = "Play", > .ifnum = QUIRK_ANY_INTERFACE, > .type = QUIRK_COMPOSITE, > .data = &(const struct snd_usb_audio_quirk[]) { > { > .ifnum = 0, > .type = QUIRK_AUDIO_STANDARD_MIXER, > }, > { > .ifnum = 1, > .type = QUIRK_AUDIO_FIXED_ENDPOINT, > .data = &(const struct audioformat) { > .formats = SNDRV_PCM_FMTBIT_S24_3LE, > .channels = 4, > .iface = 1, > .altsetting = 1, > .altset_idx = 1, > .attributes = UAC_EP_CS_ATTR_SAMPLE_RATE, > .endpoint = 0x01, > .rates = SNDRV_PCM_RATE_44100 | > SNDRV_PCM_RATE_48000, > .rate_min = 44100, > .rate_max = 48000, > .nr_rates = 2, > .rate_table = (unsigned int[]) { > 44100, 48000 > } > } > }, > { > .ifnum = -1 > } > } > } > }, > > Does anyone have additional comments to do before I make a patch ? Let's ask Clemens - the quirks master - for comments :) > Also are there some special ALSA rules or straight signed-off > git-formated patches over the kernel tree are OK ? That's ok. The patch should apply on top of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git though. > Thanks again for your help! I'm really happy to have a working > device! :D Good work! I just really wonder what that updated firmware is all about ... Daniel

1 0

[alsa-devel] [PATCH 0/9] Fixes for RME MADI cards
by Adrian Knoth 20 Oct '12

20 Oct '12

Hi! I've spent another afternoon at IOSONO to fix a series of bugs in the hdspm driver. Andre Schramm and me have tested almost all patches on a box with two PCIe MADI cards and one PCI MADI card. The DDS/Varispeed patch has only been tested on my RayDAT, the sync_in detection for AES32 has not been tested at all, though the documentation is pretty clear that the previous bit position was wrong. If there are AES(32) owners with two or more cards out there, please test and report back. The typo and the coding style patches have not been tested, since they're trivial. Cheers Adrian Knoth (9): ALSA: hdspm - Allow DDS/Varispeed to be set from userspace ALSA: hdspm - Report external rate in slave mode on PCI MADI ALSA: hdspm - Fix sync check reporting on all RME HDSPM cards ALSA: hdspm - Fix reported autosync_sample_rate ALSA: hdspm - Also report autosync_sample_rate on MADI and MADIface ALSA: hdspm - Fix sync_in reporting on RME MADI cards ALSA: hdspm - Fix sync_in detection on AES/AES32 ALSA: hdspm - Fix typo in kcontrol element on RME MADI cards ALSA: hdspm - Fix coding style in CTL_ELEM macros sound/pci/rme9652/hdspm.c | 232 ++++++++++++++++++++++++++------------------- 1 file changed, 137 insertions(+), 95 deletions(-) -- 1.7.10.4

2 13

[alsa-devel] Fwd: Support for Roland VG-99 (working code, but could use help)
by Pete Leigh 20 Oct '12

20 Oct '12

Hi, I tried posting this a couple of days ago, but no response... I'm wondering if the (text) attachment stopped people from seeing it, or if there's something else I missed? It's just a request to look over the lsusb output and new quirks-table entry included, with a view to getting this added to a release. Since the initial post, I've done more testing (I'm using a kernel based on 3.4.11-1.rt19.1.fc17.ccrma.x86_64.rt) and everything seems to work fine (including midi in, which I wasn't sure of at the time of posting) apart from one apparently cosmetic issue - the device name no longer shows up in lsusb output, though it did before applying the quirk. (?) I'll include the quirk entry as text rather than an attachment this time. If I actually need to go through the process of generating a patch and sending mail via git, as per the developer page on the alsa-project site, could someone let me know, and I'll give it a go (it's something I was hoping to avoid, I admit!) Thanks, - Pete. ---------- Forwarded message ---------- The VG-99 is a guitar processor with a usb interface which offers 2x16bit 44100 pcm in and out streams in its basic usb mode, and 2x24bit 44100 in/out + midi in the advanced mode connection mode. Basic mode works fine with usb snd driver, but the device isn't recognised when set to advanced mode (this is done under USB on page 2 of the "system" config menu) I've used the lsusb -v output (below) to guess at an addition to sound/usb/quirks-table.h to try and get this working. On initial (brief) testing, audio in/out at 24bits (as shown by jackd output) and midi (out, at least) are all working. I'll attach the quirk, and would be pleased if someone could look at it, and the lsusb output, and fix up any deficiencies (it's purely voodoo here :-D) and maybe get it or something like it into the official source... please let me know if changes need to be tested. Cheers, - Pete. Here's the lsusb output: Bus 001 Device 007: ID 0582:00b2 Roland Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 8 idVendor 0x0582 Roland Corp. idProduct 0x00b2 bcdDevice 1.00 iManufacturer 1 Roland iProduct 2 VG-99 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 167 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 06 24 f1 01 00 00 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 03 18 01 44 ac 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 9 Transfer Type Isochronous Synch Type Adaptive Usage Type Data wMaxPacketSize 0x0120 1x 288 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 ** UNRECOGNIZED: 07 24 01 07 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 03 18 01 44 ac 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0120 1x 288 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 06 24 f1 02 02 02 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 1 Device Status: 0x0001 Self Powered ------------------------------------ And the quirk entry: { USB_DEVICE(0x0582, 0x00b2), .driver_info = (unsigned long) & (const struct snd_usb_audio_quirk) { .vendor_name = "Roland", .product_name = "VG-99", .ifnum = QUIRK_ANY_INTERFACE, .type = QUIRK_COMPOSITE, .data = (const struct snd_usb_audio_quirk[]) { { .ifnum = 0, .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = & (const struct audioformat) { .formats = SNDRV_PCM_FMTBIT_S24_3LE, .channels = 2, .iface = 0, .altsetting = 1, .altset_idx = 1, .attributes = 0, .endpoint = 0x01, .ep_attr = 0x09, .rates = SNDRV_PCM_RATE_CONTINUOUS, .rate_min = 44100, .rate_max = 44100, } }, { .ifnum = 1, .type = QUIRK_AUDIO_FIXED_ENDPOINT, .data = & (const struct audioformat) { .formats = SNDRV_PCM_FMTBIT_S24_3LE, .channels = 2, .iface = 1, .altsetting = 1, .altset_idx = 1, .attributes = UAC_EP_CS_ATTR_FILL_MAX, .endpoint = 0x82, .ep_attr = 0x05, .rates = SNDRV_PCM_RATE_CONTINUOUS, .rate_min = 44100, .rate_max = 44100, } }, { .ifnum = 2, .type = QUIRK_MIDI_FIXED_ENDPOINT, .data = & (const struct snd_usb_midi_endpoint_info) { .out_cables = 0x0007, .in_cables = 0x0007 } }, { .ifnum = -1 } } } },

3 18

[alsa-devel] [PATCH v3 1/3] ALSA: core: keep track of boundary wrap-around
by Pierre-Louis Bossart 19 Oct '12

19 Oct '12

Keep track of boundary crossing when hw_ptr exceeds boundary limit and wraps-around. This will help keep track of total number of frames played/received at the kernel level Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- include/sound/pcm.h | 1 + sound/core/pcm_lib.c | 25 ++++++++++++++++++++----- 2 files changed, 21 insertions(+), 5 deletions(-) diff --git a/include/sound/pcm.h b/include/sound/pcm.h index cdca2ab..ba13e0b 100644 --- a/include/sound/pcm.h +++ b/include/sound/pcm.h @@ -281,6 +281,7 @@ struct snd_pcm_runtime { unsigned long hw_ptr_jiffies; /* Time when hw_ptr is updated */ unsigned long hw_ptr_buffer_jiffies; /* buffer time in jiffies */ snd_pcm_sframes_t delay; /* extra delay; typically FIFO size */ + u64 hw_ptr_wrap; /* offset for hw_ptr due to boundary wrap-around */ /* -- HW params -- */ snd_pcm_access_t access; /* access mode */ diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c index 7ae6719..bbc6ba4 100644 --- a/sound/core/pcm_lib.c +++ b/sound/core/pcm_lib.c @@ -315,6 +315,7 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream, unsigned long jdelta; unsigned long curr_jiffies; struct timespec curr_tstamp; + int crossed_boundary = 0; old_hw_ptr = runtime->status->hw_ptr; @@ -359,8 +360,10 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream, hdelta = curr_jiffies - runtime->hw_ptr_jiffies; if (hdelta > runtime->hw_ptr_buffer_jiffies/2) { hw_base += runtime->buffer_size; - if (hw_base >= runtime->boundary) + if (hw_base >= runtime->boundary) { hw_base = 0; + crossed_boundary++; + } new_hw_ptr = hw_base + pos; goto __delta; } @@ -370,8 +373,10 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream, /* pointer crosses the end of the ring buffer */ if (new_hw_ptr < old_hw_ptr) { hw_base += runtime->buffer_size; - if (hw_base >= runtime->boundary) + if (hw_base >= runtime->boundary) { hw_base = 0; + crossed_boundary++; + } new_hw_ptr = hw_base + pos; } __delta: @@ -409,8 +414,10 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream, while (hdelta > xrun_threshold) { delta += runtime->buffer_size; hw_base += runtime->buffer_size; - if (hw_base >= runtime->boundary) + if (hw_base >= runtime->boundary) { hw_base = 0; + crossed_boundary++; + } new_hw_ptr = hw_base + pos; hdelta -= runtime->hw_ptr_buffer_jiffies; } @@ -455,8 +462,10 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream, /* the delta value is small or zero in most cases */ while (delta > 0) { new_hw_ptr += runtime->period_size; - if (new_hw_ptr >= runtime->boundary) + if (new_hw_ptr >= runtime->boundary) { new_hw_ptr -= runtime->boundary; + crossed_boundary--; + } delta--; } /* align hw_base to buffer_size */ @@ -506,6 +515,10 @@ static int snd_pcm_update_hw_ptr0(struct snd_pcm_substream *substream, runtime->hw_ptr_base = hw_base; runtime->status->hw_ptr = new_hw_ptr; runtime->hw_ptr_jiffies = curr_jiffies; + if (crossed_boundary) { + snd_BUG_ON(crossed_boundary != 1); + runtime->hw_ptr_wrap += runtime->boundary; + } if (runtime->tstamp_mode == SNDRV_PCM_TSTAMP_ENABLE) runtime->status->tstamp = curr_tstamp; @@ -1660,8 +1673,10 @@ static int snd_pcm_lib_ioctl_reset(struct snd_pcm_substream *substream, if (snd_pcm_running(substream) && snd_pcm_update_hw_ptr(substream) >= 0) runtime->status->hw_ptr %= runtime->buffer_size; - else + else { runtime->status->hw_ptr = 0; + runtime->hw_ptr_wrap = 0; + } snd_pcm_stream_unlock_irqrestore(substream, flags); return 0; } -- 1.7.9.5

2 5

[alsa-devel] [PATCH 0/2] USB-audio disconnection race fixes (v2)
by Takashi Iwai 19 Oct '12

19 Oct '12

Hi, this is a series of fixes for the disconnection races in USB-audio. A couple of new patches to improve and cover more points since the previous patch set. Takashi

1 7

Re: [alsa-devel] [PATCH v2 1/1] ALSA: hda - add quirk for Thinkpad T430
by Jonathan Nieder 19 Oct '12

19 Oct '12

joseph.salisbury(a)canonical.com wrote: > This patch adds a quirk to enable headphone jack audio on T430 Thinkpads. > > Signed-off-by: Joseph Salisbury <joseph.salisbury(a)canonical.com> > Cc: <stable(a)vger.kernel.org> Thanks --- this is a little better. One more nit: it looks like this was reported, tested, and based on a patch by Stefan Freyr. Takashi, could you amend the message to reflect that, or should the patch be resent? Something like -- >8 -- From: Stefán Freyr <stefan.freyr(a)gmail.com> Subject: ALSA: hda - add dock support for Thinkpad T430 I have a Lenovo ThinkPad T430 and an UltraBase Series 3 docking station. Without this patch, if I plug my headphones into the jack on the computer, everything works fine. The computer speakers mute and the audio is played in the headphones. However, if I plug into the docking station headphone jack the computer speakers are muted but there is no audio in the headphones. Addresses https://bugs.launchpad.net/bugs/1060372 Signed-off-by: Joseph Salisbury <joseph.salisbury(a)canonical.com> Cc: stable(a)vger.kernel.org

2 1

[alsa-devel] HDSPM - Problems with SyncIn
by Andre Schramm 19 Oct '12

19 Oct '12

Hello, I did some tests with the SyncIn-Feature of the HDSPe cards. [root@localhost ~]# lspci |grep Mult 01:00.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall DSP MADI (rev d2) 02:00.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall DSP MADI (rev d2) The SyncOut of card 2:00 was plugged to the SyncIn of 1:00 and 1:00 was put to AutoSync-mode automatically upon boot. Problem is that the amixer output seems to be inconsistent and differs from the proc output as well, so I'm not sure which one to trust. [root@localhost ~]# amixer -c0 contents numid=5,iface=MIXER,name='AutoSync Reference' ; type=ENUMERATED,access=r-------,values=1,items=5 ; Item #0 'Word Clock' ; Item #1 'MADI' ; Item #2 'TCO' ; Item #3 'Sync In' ; Item #4 'None' : values=3 numid=2,iface=MIXER,name='Internal Clock' ; type=ENUMERATED,access=rw------,values=1,items=9 ; Item #0 '32 kHz' ; Item #1 '44.1 kHz' ; Item #2 '48 kHz' ; Item #3 '64 kHz' ; Item #4 '88.2 kHz' ; Item #5 '96 kHz' ; Item #6 '128 kHz' ; Item #7 '176.4 kHz' ; Item #8 '192 kHz' : values=2 numid=4,iface=MIXER,name='Preferred Sync Reference' ; type=ENUMERATED,access=rw------,values=1,items=3 ; Item #0 'Word Clock' ; Item #1 'MADI' ; Item #2 'Sync In' : values=2 numid=10,iface=MIXER,name='SYNC IN SyncCheck' ; type=ENUMERATED,access=r-------,values=1,items=4 ; Item #0 'No Lock' ; Item #1 'Lock' ; Item #2 'Sync' ; Item #3 'N/A' : values=0 numid=3,iface=MIXER,name='System Clock Mode' ; type=ENUMERATED,access=rw------,values=1,items=2 ; Item #0 'Master' ; Item #1 'AutoSync' : values=1 numid=6,iface=MIXER,name='System Sample Rate' ; type=INTEGER,access=r-------,values=1,min=27000,max=207000,step=1 : values=47999 'Preferred Sync Reference' is SyncIn, 'SYNC IN SyncCheck' says 'No Lock', meaning no signal at all, but the 'System Sample Rate' coming from the master card is detected with 1Hz offset. When putting the master to 32000Hz, 31999Hz are shown and so on. [root@localhost ~]# cat /proc/asound/card0/hdspm RME MADI (Card #1) Rev.d2 Status2first3bits: 1 HW Serial: 0x0000019196d4 IRQ: 16 Registers bus: 0xfe9f0000 VM: 0xf8920000 --- System --- IRQ Pending: Audio=0, MIDI0=0, MIDI1=0, IRQcount=0 HW pointer: id = 0, rawptr = 0 (0->16320) estimated= 0 (bytes) MIDI FIFO: Out1=0x0, Out2=0x0, In1=0x0, In2=0x0 MIDIoverMADI FIFO: In=0x0, Out=0x0 Register: ctrl1=0x10344ca, ctrl2=0x0, status1=0xc30004, status2=0xc0020361 No TCO module detected. --- Settings --- Size (Latency): 2048 samples (2 periods of 8192 bytes) Line out: on ClearTrackMarker = off, Transmit in 64 Channel Mode, Auto Input off AutoSync Reference: AutoSync Preferred Sync Reference: TCO System Clock Frequency: 48000 --- Status: Inputs MADI=NoLock, WordClock=NoLock AutoSync: Reference= Sync In, Freq=0 (MADI = 3, Word = 3) Input: Coax, Mode=56 channels Now the proc-output reports 'No TCO module detected', which is correct, as no expansion modules where plugged to the cards. But it also says 'Preferred Sync Reference: TCO' and 'Freq=0', where amixer said SyncIn and 47999? Output of the master card is below. Regards, Andre [root@localhost ~]# amixer -c1 contents numid=5,iface=MIXER,name='AutoSync Reference' ; type=ENUMERATED,access=r-------,values=1,items=5 ; Item #0 'Word Clock' ; Item #1 'MADI' ; Item #2 'TCO' ; Item #3 'Sync In' ; Item #4 'None' : values=4 numid=15,iface=MIXER,name='Input Select' ; type=ENUMERATED,access=rw------,values=1,items=2 ; Item #0 'optical' ; Item #1 'coaxial' : values=0 numid=2,iface=MIXER,name='Internal Clock' ; type=ENUMERATED,access=rw------,values=1,items=9 ; Item #0 '32 kHz' ; Item #1 '44.1 kHz' ; Item #2 '48 kHz' ; Item #3 '64 kHz' ; Item #4 '88.2 kHz' ; Item #5 '96 kHz' ; Item #6 '128 kHz' ; Item #7 '176.4 kHz' ; Item #8 '192 kHz' : values=2 numid=4,iface=MIXER,name='Preferred Sync Reference' ; type=ENUMERATED,access=rw------,values=1,items=3 ; Item #0 'Word Clock' ; Item #1 'MADI' ; Item #2 'Sync In' : values=0 numid=10,iface=MIXER,name='SYNC IN SyncCheck' ; type=ENUMERATED,access=r-------,values=1,items=4 ; Item #0 'No Lock' ; Item #1 'Lock' ; Item #2 'Sync' ; Item #3 'N/A' : values=0 numid=3,iface=MIXER,name='System Clock Mode' ; type=ENUMERATED,access=rw------,values=1,items=2 ; Item #0 'Master' ; Item #1 'AutoSync' : values=0 numid=6,iface=MIXER,name='System Sample Rate' ; type=INTEGER,access=r-------,values=1,min=27000,max=207000,step=1 : values=48000 [root@localhost ~]# cat /proc/asound/card1/hdspm RME MADI (Card #2) Rev.d2 Status2first3bits: 1 HW Serial: 0x000001b1c606 IRQ: 17 Registers bus: 0xfeaf0000 VM: 0xf9280000 --- System --- IRQ Pending: Audio=0, MIDI0=0, MIDI1=0, IRQcount=0 HW pointer: id = 0, rawptr = 0 (0->16320) estimated= 0 (bytes) MIDI FIFO: Out1=0x0, Out2=0x0, In1=0x0, In2=0x0 MIDIoverMADI FIFO: In=0x0, Out=0x0 Register: ctrl1=0x10004da, ctrl2=0x0, status1=0x2800000, status2=0xc0020701 No TCO module detected. --- Settings --- Size (Latency): 2048 samples (2 periods of 8192 bytes) Line out: on ClearTrackMarker = off, Transmit in 64 Channel Mode, Auto Input off AutoSync Reference: Master Preferred Sync Reference: Word Clock System Clock Frequency: 48000 --- Status: Inputs MADI=NoLock, WordClock=NoLock AutoSync: Reference= Input not valid, Freq=0 (MADI = 10, Word = 0) Input: Optical, Mode=56 channels

2 2

Re: [alsa-devel] [PATCH 0/1] ALSA: hda - add quirk for Thinkpad T430
by Jonathan Nieder 19 Oct '12

19 Oct '12

Hi Joseph, joseph.salisbury(a)canonical.com wrote: > [Subject: [PATCH 0/1] ALSA: hda - add quirk for Thinkpad T430]] [...] > This patch is to enable audio on T430 Thinkpads. There is no audo > from the headphone jack without this patch. This patch adds a quirk > for the T430 model. Please don't do this cover-letter thing. A cover letter can be a good way to *summarize* a long patch series so readers are less daunted, but any information that was needed to know in order to evaluate a patch, briefly stated, should be in the commit message that actually gets committed. Thanks and hope that helps, Jonathan

1 0

[alsa-devel] Non-interleaved with plughw
by Prasant J 19 Oct '12

19 Oct '12

Hi, My hardware supports only interleaved access and I'm recording and playing using hw:0,0. Currently I provide interleaved buffers to the device. What I read is that plughw device can convert non-interleaved buffers to interleave buffers before sending to hardware. I want to reduce complexity of my application and want to use plughw. But I'm not able to get good documentation or examples of the same. Can anyone point out to me? Regards, -Prasant

1 1

Re: [alsa-devel] ASoC: mmap or read/write?
by Mike Looijmans 19 Oct '12

19 Oct '12

Clemens ------------------------------ Message: 6 Date: Thu, 18 Oct 2012 15:07:45 +0530 From: Prasant J <pj0585(a)gmail.com> To: Clemens Ladisch <clemens(a)ladisch.de> Cc: alsa-devel(a)alsa-project.org Subject: Re: [alsa-devel] ASoC: mmap or read/write? Message-ID: <CAA2DH4v4DUxf5Qh79nehTPD+22v6XddzDrEMmnBu2eM8m4JXzg(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 18, 2012 at 2:39 PM, Clemens Ladisch <clemens(a)ladisch.de> wrote: >> Prasant J wrote: >>> I'm writing an alsa application for recording & playing 16 channel audio. >>> >>> The application is intended to run on an embedded platform & the >>> resources are highly constrained. >> Then I wonder how you manage to handle 16 channels. >> What hardware is this? > I'm working with Beaglebone (ARM Cortex-A8 720 MHz). (Currently > failures are for 8 channels 32 bit / 16 bit, but our final target is > 16 channels) > >>> My application is not performing well with read/write methods. >> How much CPU usage? > The CPU usage is around 35% (as seen in top) > > I have managed to get Audio capture working fine (after certain linux > optimizations) but playback is giving under-runs (only when PLAYBACK & > CAPTURE run together) > I was wondering that changing access method to mmap (currently I'm > using read/write) may give me some more CPU time. You must be doing something wrong. I'm doing 32-bit, 16-channel input at 51.2kHz on a OMAP-L138 (an ARM9 CPU at 450 MHz) under Linux and it's using no more than 25% CPU for that. Just using"arecord" for that. Mike. (sorry for the company sig) Met vriendelijke groet / kind regards, Mike Looijmans TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) – (0)499 - 33.69.79 Telefax: (+31) - (0)499 - 33.69.70 E-mail: mike.looijmans(a)topic.nl Website: www.topic.nl Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u verzocht de afzender hierover direct te informeren en het e-mail bericht met de bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht, waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of acceptatie van dit e-mail bericht of de daarbij behorende bijlagen. The contents of this message, as well as any enclosures, are addressed personally to, and thus solely intended for the addressee. They may contain information regarding a third party. A recipient who is neither the addressee, nor empowered to receive this message on behalf of the addressee, is kindly requested to immediately inform the sender of receipt, and to destroy the message and the enclosures. Any use of the contents of this message and/or the enclosures by any other person than the addressee or person who is empowered to receive this message, is illegal towards the sender and/or the aforementioned third party. TOPIC Embedded Systems is not liable for any damage as a result of the use and/or acceptance of this message and as well as any enclosures.

3 3

[alsa-devel] Kernel panic with SB Live (snd_emu10k1) when sharing interrupts
by John Paul Adrian Glaubitz 19 Oct '12

19 Oct '12

Hello, I have a Creative SoundBlaster Live! PCI (PCI-IDs: 1102:0002 and 1102:7002) which I recently ran into trouble with. I used the SB Live! to replace my SB128 PCI which ran fine in the configuration (ASUS P8B-C/4L, see attached output from dmesg and lspci). Once I swapped the sound cards, I booted up the machine and immediately ran into a kernel panic [1] which seems to indicate that there is a problem with interrupt sharing. I there removed the Firewire card which was placed adjacent to the SB Live and the machine ran stable again. I assume that the snd_emu10k1 driver is sometimes not handling shared interrupts properly, isn't it? I wanted to report this as a bug in the ALSA bug tracker [2], but alas the tracker is currently down. I'm attaching the output of dmesg [3] as well as lspci [4]. Will provide more information if requested. Cheers, Adrian > [1] http://users.physik.fu-berlin.de/~glaubitz/emu10k1_panic.jpg > [2] https://bugtrack.alsa-project.org/alsa-bug/ > [3] http://users.physik.fu-berlin.de/~glaubitz/dmesg_emu10k1.txt > [4] http://users.physik.fu-berlin.de/~glaubitz/lspci_emu10k1.txt

2 1

[alsa-devel] [PATCH v2 0/2] ASoC: omap-mcpdm updates for 3.7
by Peter Ujfalusi 19 Oct '12

19 Oct '12

Hello Mark, Tony, Change since v1: - Fixed the second patch to keep the omap_mcpdm_open_stream() - after a coffee The mcpdm driver no longer needs to include any plat/*.h file, clearing the way for the single kernel image. Regards, Peter --- Peter Ujfalusi (1): ASoC: omap-mcpdm: Remove OMAP revision check Tony Lindgren (1): ASoC: Fix wrong include for McPDM sound/soc/omap/omap-mcpdm.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) -- 1.7.12

3 10

[alsa-devel] [PATCH 0/5] snd-ice1712: Add Philips PSC724 Ultimate Edge
by Ondrej Zary 19 Oct '12

19 Oct '12

Hello, this patch series adds full support for Philips PSC724 Ultimate Edge sound card to snd-ice1712 driver. Unlike other snd-ice1712 subdrivers, the codec code is splitted into separate files, reusable by other ice1712 subdrivers. Working: all analog outputs (front, rear, center+lfe, headphone) and inputs (front mic, rear mic, line, cd, aux), mixer, headphone jack detection, suspend/resume Untested: SPDIF -- Ondrej Zary

2 8

[alsa-devel] ESI drivers
by Neil Mcbennett 18 Oct '12

18 Oct '12

Hi, I am not a developer and probably shouldn't even be here, but I do have a question that is probably best answered from this forum. I've been looking at the ESI website and I notice that there is some ALSA support for a few of their cards... http://www.alsa-project.org/main/index.php/Matrix:Vendor-ESI The interface I'm most interested in isn't on this list (MaXiO 032e) I decided to call the technical support number in the UK and ask them what their position is regarding Linux. The guy I spoke to said that ESI are not going to provide an ALSA driver for these devices but they would be more than happy if someone from the ALSA community were to approach them. They would then assist in providing the necessary information. So, just wondering if anyone has already started on this or if there might be some interest in doing so? I was attracted to ESI by the fact that they have a number of PCIe interfaces which are still quite something of a rarity. Regards Neil

1 0

[alsa-devel] LAC 2013: the Linux Audio Conference - Call for Participation
by Robin Gareus 18 Oct '12

18 Oct '12

sorry for >< please >> << We are happy to announce the next issue of the Linux Audio Conference (LAC), May 9-12, 2013 @ IEM, the Institute of Electronic Music and Acoustics, in Graz, Austria. The Linux Audio Conference is an international conference that brings together musicians, sound artists, software developers and researchers, working with Linux as an open, stable, professional platform for audio and media research and music production. LAC includes paper sessions, workshops, and a diverse program of electronic music. *Call for Papers, Workshops, Music and Installations* We invite submissions of papers addressing all areas of audio processing and media creation based on Linux. Papers can focus on technical, artistic and scientific issues and should target developers or users. In our call for music, we are looking for works that have been produced or composed entirely/mostly using Linux. The online submission of papers, workshops, music and installations is now open at http://lac.iem.at/ The Deadline for all submissions is February 4th, 2013 (23:59 HAST) You are invited to register for participation on our conference website. There you will find up-to-date instructions, as well as important information about dates, travel, lodging, and so on. This year's conference is hosted by IEM, Graz, in cooperation with local artists and FLOSS enthusiasts. The Institute of Electronic Music and Acoustics (IEM) at the University of Music and Performing Arts Graz is considered Austria's leading institution in computer music, acoustics and audio engineering and has gained international reputation for its research on spatial audio and its artistic production and research. IEM has been embracing Linux audio as a production and research environment since the mid-1990s, and has contributed to FLOSS/Linux projects, amongst others by providing drivers for multichannel audio interfaces and hosting the Pure Data community portal and mailing lists. http://iem.at/ We look forward to seeing you in Graz in May! Sincerely, The LAC 2013 Organizing Team

1 0

[alsa-devel] [PATCH v2 0/2] Convert davinci ASoC to genalloc SRAM
by Matt Porter 18 Oct '12

18 Oct '12

Changes since v1: - Rebased against uio_pruss/genalloc series v4 patches, requiring another header to be included. This series converts davinci ASoC to use genalloc and enables that support on DA850. It applies to mainline on top of the uio_pruss/genalloc series [1] which allows DaVinci to provide a gen_pool via pdata for driver use. I've tested this on the AM180x EVM. Note that prior to this, the SRAM paths in the driver were completely unused. I've only enabled ping-pong buffering on the platform I can test as it's best to allow those with DM644x and similar platforms to set the playback/capture sram size to something that's known to work for them. [1] https://lkml.org/lkml/2012/10/5/425 Matt Porter (2): ASoC: davinci: replace private sram api with genalloc ARM: davinci: enable SRAM ping ping buffering on DA850 arch/arm/mach-davinci/board-da850-evm.c | 25 +++++++++++++++---------- include/linux/platform_data/davinci_asp.h | 3 +++ sound/soc/davinci/davinci-mcasp.c | 2 ++ sound/soc/davinci/davinci-pcm.c | 18 ++++++++++++------ sound/soc/davinci/davinci-pcm.h | 2 ++ 5 files changed, 34 insertions(+), 16 deletions(-) -- 1.7.9.5

4 9

Re: [alsa-devel] [PATCH] dma: add new DMA control commands
by Huang Shijie 18 Oct '12

18 Oct '12

On Thu, Oct 18, 2012 at 5:29 AM, Jassi Brar <jaswinder.singh(a)linaro.org> wrote: > On 18 October 2012 12:15, Huang Shijie <b32955(a)freescale.com> wrote: >> 于 2012年10月18日 14:18, Vinod Koul 写道: >> >>> Why cant you do start (prepare clock etc) when you submit the descriptor >>> to dmaengine. Can be done in tx_submit callback. >>> Similarly remove the clock when dma transaction gets completed. >> >> I ever thought this method too. >> >> But it will become low efficient in the following case: >> >> Assuming the gpmi-nand driver has to read out 1024 pages in one _SINGLE_ >> read operation. >> The gpmi-nand will submit the descriptor to dmaengine per page. So with your >> method, >> the system will repeat the enable/disable dma clock 1024 time. At every >> enable/disable dma clock, >> the system has to enable the clock chain and it's parents ... >> >> But with this patch, we only need to enable/disable dma clock one time, just >> at we select the nand chip. >> > If the clock is the dmac's property (not channels'), the toggling > seems too aggressive. > You could try using runtime_suspend/resume for clock > disabling/enabling. How about employing autosuspend with a few ms > delay? Yes, employing the autosuspend is workable method too.o But it's a little more complicated then this patch. You have to create a thread or workqueue to do the job. What's more, I think other DMA engine may also meets the same issue as the mxs-dma, such as the imx-sdma. It's somehow a common issue to disable the clocks when no one use the DMA engine. Do you also suggest employing the autosuspend? Why not use a simple way to handle this issue? When the dma device want to use a DMA engine, it just needs to issue a DMA_START command. thanks Huang Shijie Huang Shijie

1 0

Re: [alsa-devel] [PATCH v2 2/2] ARM: davinci: enable SRAM ping ping buffering on DA850
by Matt Porter 18 Oct '12

18 Oct '12

On Fri, Oct 12, 2012 at 07:11:06PM +0200, Sergei Shtylyov wrote: > Hello. > > On 11-10-2012 23:33, Matt Porter wrote: > > >Passes the DA850 shared SRAM gen_pool to the McASP driver > >and enables the ping-pong buffer DMA support. > > Here "ping-pong is correct but the subject have a typo. Thanks. Daniel: can you correct this when you squash these into your series? -Matt

1 0

[alsa-devel] [PATCH] dma: add new DMA control commands
by Huang Shijie 18 Oct '12

18 Oct '12

From: Huang Shijie <shijie8(a)gmail.com> [1] Why add these new DMA control commands? In mx6q, the gpmi-nand driver is the only user of the APBH-DMA. The dma clock is enabled when we have successfully requested a DMA channel. So even when the gpmi-nand driver does not work, the dma clock(apbh-dma) still runs in high speed (198MHz). To save some power, it is better to disable the dma clock when the dma device, such as gpmi-nand, is not working anymore. When the dma device becomes work again, enable the dma clock again. [2] add new DMA control commands: DMA_START/DMA_END DMA_START: do some preprations to start the DMA engine, such as enable the necessary clocks. DMA_END: do some works to end the DMA engine, such as disable the necessary clocks. [3] This patch does not change any logic in i2c-mxs driver and mxs-pcm driver. But for gpmi-nand driver, we will enable the the clock only when we select the nand chip, and want to do some real jobs with the nand chip. For mxs-mmc driver, disable the dma clock in the suspend; and enable the dma clock in the resume. Signed-off-by: Huang Shijie <b32955(a)freescale.com> --- drivers/dma/mxs-dma.c | 17 +++++++++++++++++ drivers/i2c/busses/i2c-mxs.c | 10 +++++++++- drivers/mmc/host/mxs-mmc.c | 19 ++++++++++++++++--- drivers/mtd/nand/gpmi-nand/gpmi-lib.c | 10 ++++++++++ drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 10 ++++++---- include/linux/dmaengine.h | 6 ++++++ sound/soc/mxs/mxs-pcm.c | 12 ++++++++++++ 7 files changed, 76 insertions(+), 8 deletions(-) diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c index 9f02e79..89286f4 100644 --- a/drivers/dma/mxs-dma.c +++ b/drivers/dma/mxs-dma.c @@ -384,6 +384,8 @@ static int mxs_dma_alloc_chan_resources(struct dma_chan *chan) /* the descriptor is ready */ async_tx_ack(&mxs_chan->desc); + clk_disable_unprepare(mxs_dma->clk); + return 0; err_clk: @@ -399,6 +401,14 @@ static void mxs_dma_free_chan_resources(struct dma_chan *chan) { struct mxs_dma_chan *mxs_chan = to_mxs_dma_chan(chan); struct mxs_dma_engine *mxs_dma = mxs_chan->mxs_dma; + int ret; + + ret = clk_prepare_enable(mxs_dma->clk); + if (ret) { + dev_err(mxs_dma->dma_device.dev, + "failed in enabling the dma clock\n"); + return; + } mxs_dma_disable_chan(mxs_chan); @@ -597,9 +607,13 @@ static int mxs_dma_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd, unsigned long arg) { struct mxs_dma_chan *mxs_chan = to_mxs_dma_chan(chan); + struct mxs_dma_engine *mxs_dma = mxs_chan->mxs_dma; int ret = 0; switch (cmd) { + case DMA_START: + ret = clk_prepare_enable(mxs_dma->clk); + break; case DMA_TERMINATE_ALL: mxs_dma_reset_chan(mxs_chan); mxs_dma_disable_chan(mxs_chan); @@ -610,6 +624,9 @@ static int mxs_dma_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd, case DMA_RESUME: mxs_dma_resume_chan(mxs_chan); break; + case DMA_END: + clk_disable_unprepare(mxs_dma->clk); + break; default: ret = -ENOSYS; } diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c index 1f58197..da1e881 100644 --- a/drivers/i2c/busses/i2c-mxs.c +++ b/drivers/i2c/busses/i2c-mxs.c @@ -643,6 +643,12 @@ static int __devinit mxs_i2c_probe(struct platform_device *pdev) dev_err(dev, "Failed to request dma\n"); return -ENODEV; } + err = dmaengine_device_control(i2c->dmach, DMA_START, 0); + if (err) { + dma_release_channel(i2c->dmach); + dev_err(dev, "Failed to start dma\n"); + return err; + } } platform_set_drvdata(pdev, i2c); @@ -680,8 +686,10 @@ static int __devexit mxs_i2c_remove(struct platform_device *pdev) if (ret) return -EBUSY; - if (i2c->dmach) + if (i2c->dmach) { + dmaengine_device_control(i2c->dmach, DMA_END, 0); dma_release_channel(i2c->dmach); + } writel(MXS_I2C_CTRL0_SFTRST, i2c->regs + MXS_I2C_CTRL0_SET); diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c index 80d1e6d..aa91830 100644 --- a/drivers/mmc/host/mxs-mmc.c +++ b/drivers/mmc/host/mxs-mmc.c @@ -676,6 +676,9 @@ static int mxs_mmc_probe(struct platform_device *pdev) "%s: failed to request dma\n", __func__); goto out_clk_put; } + ret = dmaengine_device_control(ssp->dmach, DMA_START, 0); + if (ret) + goto out_free_dma; /* set mmc core parameters */ mmc->ops = &mxs_mmc_ops; @@ -717,18 +720,20 @@ static int mxs_mmc_probe(struct platform_device *pdev) ret = devm_request_irq(&pdev->dev, irq_err, mxs_mmc_irq_handler, 0, DRIVER_NAME, host); if (ret) - goto out_free_dma; + goto out_end_free_dma; spin_lock_init(&host->lock); ret = mmc_add_host(mmc); if (ret) - goto out_free_dma; + goto out_end_free_dma; dev_info(mmc_dev(host->mmc), "initialized\n"); return 0; +out_end_free_dma: + dmaengine_device_control(ssp->dmach, DMA_END, 0); out_free_dma: if (ssp->dmach) dma_release_channel(ssp->dmach); @@ -750,8 +755,10 @@ static int mxs_mmc_remove(struct platform_device *pdev) platform_set_drvdata(pdev, NULL); - if (ssp->dmach) + if (ssp->dmach) { + dmaengine_device_control(ssp->dmach, DMA_END, 0); dma_release_channel(ssp->dmach); + } clk_disable_unprepare(ssp->clk); clk_put(ssp->clk); @@ -772,6 +779,7 @@ static int mxs_mmc_suspend(struct device *dev) ret = mmc_suspend_host(mmc); clk_disable_unprepare(ssp->clk); + dmaengine_device_control(ssp->dmach, DMA_END, 0); return ret; } @@ -784,8 +792,13 @@ static int mxs_mmc_resume(struct device *dev) int ret = 0; clk_prepare_enable(ssp->clk); + ret = dmaengine_device_control(ssp->dmach, DMA_START, 0); + if (ret) + return ret; ret = mmc_resume_host(mmc); + if (ret) + dmaengine_device_control(ssp->dmach, DMA_END, 0); return ret; } diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c index 3502acc..20ed3f3 100644 --- a/drivers/mtd/nand/gpmi-nand/gpmi-lib.c +++ b/drivers/mtd/nand/gpmi-nand/gpmi-lib.c @@ -958,6 +958,7 @@ void gpmi_begin(struct gpmi_nand_data *this) uint32_t reg; unsigned int dll_wait_time_in_us; struct gpmi_nfc_hardware_timing hw; + struct dma_chan *channel = get_dma_chan(this); int ret; /* Enable the clock. */ @@ -967,6 +968,12 @@ void gpmi_begin(struct gpmi_nand_data *this) goto err_out; } + ret = dmaengine_device_control(channel, DMA_START, 0); + if (ret) { + gpmi_disable_clk(this); + goto err_out; + } + /* Only initialize the timing once */ if (this->flags & GPMI_TIMING_INIT_OK) return; @@ -1035,7 +1042,10 @@ err_out: void gpmi_end(struct gpmi_nand_data *this) { + struct dma_chan *channel = get_dma_chan(this); + gpmi_disable_clk(this); + dmaengine_device_control(channel, DMA_END, 0); } /* Clears a BCH interrupt. */ diff --git a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c index e2c56fc..5694d03 100644 --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c @@ -815,12 +815,14 @@ static void gpmi_select_chip(struct mtd_info *mtd, int chipnr) struct nand_chip *chip = mtd->priv; struct gpmi_nand_data *this = chip->priv; - if ((this->current_chip < 0) && (chipnr >= 0)) + if ((this->current_chip < 0) && (chipnr >= 0)) { + /* set the current_chip before we call gpmi_begin(). */ + this->current_chip = chipnr; gpmi_begin(this); - else if ((this->current_chip >= 0) && (chipnr < 0)) + } else if ((this->current_chip >= 0) && (chipnr < 0)) { gpmi_end(this); - - this->current_chip = chipnr; + this->current_chip = chipnr; + } } static void gpmi_read_buf(struct mtd_info *mtd, uint8_t *buf, int len) diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h index d3201e4..79f864a 100644 --- a/include/linux/dmaengine.h +++ b/include/linux/dmaengine.h @@ -199,6 +199,8 @@ enum dma_ctrl_flags { /** * enum dma_ctrl_cmd - DMA operations that can optionally be exercised * on a running channel. + * @DMA_START: do some preprations to start the DMA engine, such as enable the + * necessary clocks. * @DMA_TERMINATE_ALL: terminate all ongoing transfers * @DMA_PAUSE: pause ongoing transfers * @DMA_RESUME: resume paused transfer @@ -209,13 +211,17 @@ enum dma_ctrl_flags { * command. * @FSLDMA_EXTERNAL_START: this command will put the Freescale DMA controller * into external start mode. + * @DMA_END: do some works to end the DMA engine, such as disable the + * necessary clocks. */ enum dma_ctrl_cmd { + DMA_START, DMA_TERMINATE_ALL, DMA_PAUSE, DMA_RESUME, DMA_SLAVE_CONFIG, FSLDMA_EXTERNAL_START, + DMA_END, }; /** diff --git a/sound/soc/mxs/mxs-pcm.c b/sound/soc/mxs/mxs-pcm.c index f82d766..cfcc30f 100644 --- a/sound/soc/mxs/mxs-pcm.c +++ b/sound/soc/mxs/mxs-pcm.c @@ -92,6 +92,7 @@ static int snd_mxs_open(struct snd_pcm_substream *substream) { struct snd_soc_pcm_runtime *rtd = substream->private_data; struct mxs_pcm_dma_data *pcm_dma_data; + struct dma_chan *chan; int ret; pcm_dma_data = kzalloc(sizeof(*pcm_dma_data), GFP_KERNEL); @@ -107,6 +108,14 @@ static int snd_mxs_open(struct snd_pcm_substream *substream) return ret; } + chan = snd_dmaengine_pcm_get_chan(substream); + ret = dmaengine_device_control(chan, DMA_START, (unsigned long)0); + if (ret) { + snd_dmaengine_pcm_close(substream); + kfree(pcm_dma_data); + return ret; + } + snd_soc_set_runtime_hwparams(substream, &snd_mxs_hardware); snd_dmaengine_pcm_set_data(substream, pcm_dma_data); @@ -117,7 +126,10 @@ static int snd_mxs_open(struct snd_pcm_substream *substream) static int snd_mxs_close(struct snd_pcm_substream *substream) { struct mxs_pcm_dma_data *pcm_dma_data = snd_dmaengine_pcm_get_data(substream); + struct dma_chan *chan; + chan = snd_dmaengine_pcm_get_chan(substream); + dmaengine_device_control(chan, DMA_END, 0); snd_dmaengine_pcm_close(substream); kfree(pcm_dma_data); -- 1.7.0.4

5 13

[alsa-devel] Non-Interleaved access method?
by Prasant J 18 Oct '12

18 Oct '12

Hi, When the application set the access method to non-interleaved, that means that the ALSA application will deliver the non-interleaved buffers to alsa subsystem & the alsa subsystem will interleave the data before sending out the data to the hardware. Am I correct? Or non-interleaved means that the data will be sent out in non-interleaved manner itself? Regards, -Prasant

2 1

[alsa-devel] ASoC: mmap or read/write?
by Prasant J 18 Oct '12

18 Oct '12

Hi, I'm writing an alsa application for recording & playing 16 channel audio. The application is intended to run on an embedded platform & the resources are highly constrained. My application is not performing well with read/write methods. I'm considering using mmap but not able to get the right documentation or start, so I want to know whether mmap really offers any advantages or not. Does the mmap method has any advantages over read/write? Is there any thumb rule to decide when to use mmap or read/write? -Prasant

2 3

[alsa-devel] Interleaved or Non-interleaved?
by Prasant J 18 Oct '12

18 Oct '12

hi, My sound hardware supports only interleaved audio. I'm writing an alsa application. Which access method will be more performing : interleaved or non-interleaved? (Or it does not make a difference?) -Prasant

2 2

[alsa-devel] [PATCH 1/2] ARM: OMAP: Trivial driver changes to remove include plat/cpu.h
by Tony Lindgren 17 Oct '12

17 Oct '12

Drivers should not use cpu_is_omap or cpu_class_is_omap macros, they should be private to the platform init code. And we'll be removing plat/cpu.h and only have a private soc.h for the arch/arm/*omap* code. This patch is intended as preparation for the core omap changes and removes the need to include plat/cpu.h from several drivers. This is needed for the ARM common zImage support. These changes are OK to do because: - omap-rng.c and hsmmc.c don't need plat/cpu.h - omap-aes.c and omap-sham.c get the proper platform_data passed to them so they don't need extra checks in the driver - omap-dma.c and omap-pcm.c can test the arch locally as omap1 and omap2 cannot be compiled together because of conflicting compiler flags Cc: Deepak Saxena <dsaxena(a)plexity.net> Cc: Matt Mackall <mpm(a)selenic.com> Cc: Herbert Xu <herbert(a)gondor.apana.org.au> Cc: David S. Miller <davem(a)davemloft.net> Cc: Venkatraman S <svenkatr(a)ti.com> Cc: Chris Ball <cjb(a)laptop.org> Cc: Vinod Koul <vinod.koul(a)intel.com> Cc: Dan Williams <djbw(a)fb.com> Cc: Peter Ujfalusi <peter.ujfalusi(a)ti.com> Cc: Jarkko Nikula <jarkko.nikula(a)bitmer.com> Cc: Liam Girdwood <lrg(a)ti.com> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Cc: linux-crypto(a)vger.kernel.org Cc: linux-mmc(a)vger.kernel.org Cc: alsa-devel(a)alsa-project.org Cc: linux-kernel(a)vger.kernel.org Signed-off-by: Tony Lindgren <tony(a)atomide.com> --- drivers/char/hw_random/omap-rng.c | 2 -- drivers/crypto/omap-aes.c | 6 ------ drivers/crypto/omap-sham.c | 8 -------- drivers/dma/omap-dma.c | 9 +++++++-- drivers/mmc/host/omap_hsmmc.c | 1 - sound/soc/omap/omap-pcm.c | 9 +++++++-- 6 files changed, 14 insertions(+), 21 deletions(-) diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c index a5effd8..45e467d 100644 --- a/drivers/char/hw_random/omap-rng.c +++ b/drivers/char/hw_random/omap-rng.c @@ -27,8 +27,6 @@ #include <asm/io.h> -#include <plat/cpu.h> - #define RNG_OUT_REG 0x00 /* Output register */ #define RNG_STAT_REG 0x04 /* Status register [0] = STAT_BUSY */ diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c index 3e61feb..649a146 100644 --- a/drivers/crypto/omap-aes.c +++ b/drivers/crypto/omap-aes.c @@ -29,7 +29,6 @@ #include <crypto/scatterwalk.h> #include <crypto/aes.h> -#include <plat/cpu.h> #include <plat-omap/dma-omap.h> /* OMAP TRM gives bitfields as start:end, where start is the higher bit @@ -941,11 +940,6 @@ static int __init omap_aes_mod_init(void) { pr_info("loading %s driver\n", "omap-aes"); - if (!cpu_class_is_omap2() || omap_type() != OMAP2_DEVICE_TYPE_SEC) { - pr_err("Unsupported cpu\n"); - return -ENODEV; - } - return platform_driver_register(&omap_aes_driver); } diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c index 6d79695..d76fe06 100644 --- a/drivers/crypto/omap-sham.c +++ b/drivers/crypto/omap-sham.c @@ -37,7 +37,6 @@ #include <crypto/hash.h> #include <crypto/internal/hash.h> -#include <plat/cpu.h> #include <plat-omap/dma-omap.h> #include <mach/irqs.h> @@ -1289,13 +1288,6 @@ static int __init omap_sham_mod_init(void) { pr_info("loading %s driver\n", "omap-sham"); - if (!cpu_class_is_omap2() || - (omap_type() != OMAP2_DEVICE_TYPE_SEC && - omap_type() != OMAP2_DEVICE_TYPE_EMU)) { - pr_err("Unsupported cpu\n"); - return -ENODEV; - } - return platform_driver_register(&omap_sham_driver); } diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c index 0b4fa50..56d9253 100644 --- a/drivers/dma/omap-dma.c +++ b/drivers/dma/omap-dma.c @@ -19,9 +19,14 @@ #include "virt-dma.h" -#include <plat/cpu.h> #include <plat-omap/dma-omap.h> +#ifdef CONFIG_ARCH_OMAP2PLUS +#define dma_omap2plus() 1 +#else +#define dma_omap2plus() 0 +#endif + struct omap_dmadev { struct dma_device ddev; spinlock_t lock; @@ -438,7 +443,7 @@ static struct dma_async_tx_descriptor *omap_dma_prep_dma_cyclic( omap_disable_dma_irq(c->dma_ch, OMAP_DMA_BLOCK_IRQ); } - if (!cpu_class_is_omap1()) { + if (dma_omap2plus()) { omap_set_dma_src_burst_mode(c->dma_ch, OMAP_DMA_DATA_BURST_16); omap_set_dma_dest_burst_mode(c->dma_ch, OMAP_DMA_DATA_BURST_16); } diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 85b164e..24df035 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -40,7 +40,6 @@ #include <linux/pm_runtime.h> #include <linux/platform_data/mmc-omap.h> #include <mach/hardware.h> -#include <plat/cpu.h> /* OMAP HSMMC Host Controller Registers */ #define OMAP_HSMMC_SYSSTATUS 0x0014 diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c index 340874e..52977aa 100644 --- a/sound/soc/omap/omap-pcm.c +++ b/sound/soc/omap/omap-pcm.c @@ -32,9 +32,14 @@ #include <sound/dmaengine_pcm.h> #include <sound/soc.h> -#include <plat/cpu.h> #include "omap-pcm.h" +#ifdef CONFIG_ARCH_OMAP1 +#define pcm_omap1510() cpu_is_omap1510() +#else +#define pcm_omap1510() 0 +#endif + static const struct snd_pcm_hardware omap_pcm_hardware = { .info = SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID | @@ -159,7 +164,7 @@ static snd_pcm_uframes_t omap_pcm_pointer(struct snd_pcm_substream *substream) { snd_pcm_uframes_t offset; - if (cpu_is_omap1510()) + if (pcm_omap1510()) offset = snd_dmaengine_pcm_pointer_no_residue(substream); else offset = snd_dmaengine_pcm_pointer(substream);

3 6

[alsa-devel] [PATCH] emu10k1: add chip details for E-mu 1010 PCIe card
by Maxim Kachur 17 Oct '12

17 Oct '12

emu10k1_main.c: Add chip details for E-mu 1010 PCIe card. It has the same chip as found in E-mu 1010b but it uses different PCI id. Signed-off-by: Maxim Kachur <mcdebugger(a)duganet.ru> --- sound/pci/emu10k1/emu10k1_main.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/sound/pci/emu10k1/emu10k1_main.c b/sound/pci/emu10k1/emu10k1_main.c index bed4485..c21adb6 100644 --- a/sound/pci/emu10k1/emu10k1_main.c +++ b/sound/pci/emu10k1/emu10k1_main.c @@ -1416,6 +1416,15 @@ static struct snd_emu_chip_details emu_chip_details[] = { .ca0108_chip = 1, .spk71 = 1, .emu_model = EMU_MODEL_EMU1010B}, /* EMU 1010 new revision */ + /* Tested by Maxim Kachur <mcdebugger(a)duganet.ru> 17th Oct 2012. */ + /* This is MAEM8986, 0202 is MAEM8980 */ + {.vendor = 0x1102, .device = 0x0008, .subsystem = 0x40071102, + .driver = "Audigy2", .name = "E-mu 1010 PCIe [MAEM8986]", + .id = "EMU1010", + .emu10k2_chip = 1, + .ca0108_chip = 1, + .spk71 = 1, + .emu_model = EMU_MODEL_EMU1010B}, /* EMU 1010 PCIe */ /* Tested by James(a)superbug.co.uk 8th July 2005. */ /* This is MAEM8810, 0202 is MAEM8820 */ {.vendor = 0x1102, .device = 0x0004, .subsystem = 0x40011102, -- 1.7.8.6

2 2

[alsa-devel] [PATCH] emu10k1: add chip details for E-mu 1010 PCIe card
by Maxim Kachur 17 Oct '12

17 Oct '12

emu10k1_main.c: Add chip details for E-mu 1010 PCIe card. It has the same chip as found in E-mu 1010b but it uses different PCI id. Signed-off-by: Maxim Kachur <mcdebugger(a)duganet.ru> --- sound/pci/emu10k1/emu10k1_main.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/sound/pci/emu10k1/emu10k1_main.c b/sound/pci/emu10k1/emu10k1_main.c index bed4485..c21adb6 100644 --- a/sound/pci/emu10k1/emu10k1_main.c +++ b/sound/pci/emu10k1/emu10k1_main.c @@ -1416,6 +1416,15 @@ static struct snd_emu_chip_details emu_chip_details[] = { .ca0108_chip = 1, .spk71 = 1, .emu_model = EMU_MODEL_EMU1010B}, /* EMU 1010 new revision */ + /* Tested by Maxim Kachur <mcdebugger(a)duganet.ru> 17th Oct 2012. */ + /* This is MAEM8986, 0202 is MAEM8980 */ + {.vendor = 0x1102, .device = 0x0008, .subsystem = 0x40071102, + .driver = "Audigy2", .name = "E-mu 1010 PCIe [MAEM8986]", + .id = "EMU1010", + .emu10k2_chip = 1, + .ca0108_chip = 1, + .spk71 = 1, + .emu_model = EMU_MODEL_EMU1010B}, /* EMU 1010 PCIe */ /* Tested by James(a)superbug.co.uk 8th July 2005. */ /* This is MAEM8810, 0202 is MAEM8820 */ {.vendor = 0x1102, .device = 0x0004, .subsystem = 0x40011102, -- 1.7.8.6

1 0

[alsa-devel] [PATCH] ASoC: codecs: da9055: DAPMise Headphone and Lineout enable controls
by Ashish Chavan 17 Oct '12

17 Oct '12

This patch DAPMises headphone and lineout output enable controls. Earlier these output enable bits were permanently turned on in probe. In da9055 codec, right outmixer is directly connected with right HP and Line out. This resulted in two side effects, (1) When you only want to use lineout, right HP (and connected charge pump) also gets enabled (2) When you only want to use stereo HP, lineout also gets enabled This patch adds three switches to select which output(s) should be enabled. Signed-off-by: Ashish Chavan <ashish.chavan(a)kpitcummins.com> Signed-off-by: David Dajun Chen <david.chen(a)diasemi.com> --- sound/soc/codecs/da9055.c | 39 ++++++++++++++++++++++++++------------- 1 files changed, 26 insertions(+), 13 deletions(-) diff --git a/sound/soc/codecs/da9055.c b/sound/soc/codecs/da9055.c index abf3e43..d3a6de2 100644 --- a/sound/soc/codecs/da9055.c +++ b/sound/soc/codecs/da9055.c @@ -753,6 +753,17 @@ static const struct snd_kcontrol_new da9055_dapm_mixoutr_controls[] = { 6, 1, 0), }; +/* Headphone Output Enable */ +static const struct snd_kcontrol_new da9055_dapm_hp_l_control = +SOC_DAPM_SINGLE("Switch", DA9055_HP_L_CTRL, 3, 1, 0); + +static const struct snd_kcontrol_new da9055_dapm_hp_r_control = +SOC_DAPM_SINGLE("Switch", DA9055_HP_R_CTRL, 3, 1, 0); + +/* Lineout Output Enable */ +static const struct snd_kcontrol_new da9055_dapm_lineout_control = +SOC_DAPM_SINGLE("Switch", DA9055_LINE_CTRL, 3, 1, 0); + /* DAPM widgets */ static const struct snd_soc_dapm_widget da9055_dapm_widgets[] = { /* Input Side */ @@ -817,6 +828,14 @@ static const struct snd_soc_dapm_widget da9055_dapm_widgets[] = { &da9055_dapm_mixoutr_controls[0], ARRAY_SIZE(da9055_dapm_mixoutr_controls)), + /* Output Enable Switches */ + SND_SOC_DAPM_SWITCH("Headphone Left Enable", SND_SOC_NOPM, 0, 0, + &da9055_dapm_hp_l_control), + SND_SOC_DAPM_SWITCH("Headphone Right Enable", SND_SOC_NOPM, 0, 0, + &da9055_dapm_hp_r_control), + SND_SOC_DAPM_SWITCH("Lineout Enable", SND_SOC_NOPM, 0, 0, + &da9055_dapm_lineout_control), + /* Output PGAs */ SND_SOC_DAPM_PGA("MIXOUT Left", DA9055_MIXOUT_L_CTRL, 7, 0, NULL, 0), SND_SOC_DAPM_PGA("MIXOUT Right", DA9055_MIXOUT_R_CTRL, 7, 0, NULL, 0), @@ -902,17 +921,20 @@ static const struct snd_soc_dapm_route da9055_audio_map[] = { {"Out Mixer Right", "DAC Right Switch", "DAC Right"}, {"MIXOUT Left", NULL, "Out Mixer Left"}, - {"Headphone Left", NULL, "MIXOUT Left"}, + {"Headphone Left Enable", "Switch", "MIXOUT Left"}, + {"Headphone Left", NULL, "Headphone Left Enable"}, {"Headphone Left", NULL, "Charge Pump"}, {"HPL", NULL, "Headphone Left"}, {"MIXOUT Right", NULL, "Out Mixer Right"}, - {"Headphone Right", NULL, "MIXOUT Right"}, + {"Headphone Right Enable", "Switch", "MIXOUT Right"}, + {"Headphone Right", NULL, "Headphone Right Enable"}, {"Headphone Right", NULL, "Charge Pump"}, {"HPR", NULL, "Headphone Right"}, {"MIXOUT Right", NULL, "Out Mixer Right"}, - {"Lineout", NULL, "MIXOUT Right"}, + {"Lineout Enable", "Switch", "MIXOUT Right"}, + {"Lineout", NULL, "Lineout Enable"}, {"LINE", NULL, "Lineout"}, }; @@ -1394,8 +1416,7 @@ static int da9055_probe(struct snd_soc_codec *codec) DA9055_GAIN_RAMPING_EN, DA9055_GAIN_RAMPING_EN); /* - * There are two separate control bits for input and output mixers as - * well as headphone and line outs. + * There are two separate control bits for input and output mixers. * One to enable corresponding amplifier and other to enable its * output. As amplifier bits are related to power control, they are * being managed by DAPM while other (non power related) bits are @@ -1411,14 +1432,6 @@ static int da9055_probe(struct snd_soc_codec *codec) snd_soc_update_bits(codec, DA9055_MIXOUT_R_CTRL, DA9055_MIXOUT_R_MIX_EN, DA9055_MIXOUT_R_MIX_EN); - snd_soc_update_bits(codec, DA9055_HP_L_CTRL, - DA9055_HP_L_AMP_OE, DA9055_HP_L_AMP_OE); - snd_soc_update_bits(codec, DA9055_HP_R_CTRL, - DA9055_HP_R_AMP_OE, DA9055_HP_R_AMP_OE); - - snd_soc_update_bits(codec, DA9055_LINE_CTRL, - DA9055_LINE_AMP_OE, DA9055_LINE_AMP_OE); - /* Set this as per your system configuration */ snd_soc_write(codec, DA9055_PLL_CTRL, DA9055_PLL_INDIV_10_20_MHZ); -- 1.7.1

2 1

[alsa-devel] [PATCH 0/3] Convert to use snd_soc_register_card()
by Bo Shen 17 Oct '12

17 Oct '12

Convert to use snd_soc_register_card(), and enable it Change the id for the gpio i2c to let it work Bo Shen (3): ASoC: sam9g20-wm8731: convert to use snd_soc_register_card() ASoC: sam9g20: using platform device for audio part i2c: change the id to let the i2c-gpio work arch/arm/mach-at91/at91sam9260_devices.c | 11 ++++++- arch/arm/mach-at91/board-sam9g20ek.c | 17 ++++++++++ sound/soc/atmel/sam9g20_wm8731.c | 51 +++++++++++++----------------- 3 files changed, 49 insertions(+), 30 deletions(-) -- 1.7.9.5

2 7

[alsa-devel] [PATCH] ALSA: hda - Don't enable unsol for jacks we're polling
by David Henningsson 17 Oct '12

17 Oct '12

This will greatly reduce the frequency for detection errors in those cases where the hardware is "flaky", i e, rapidly changing between plugged and unplugged states even without user interaction. Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/hda_jack.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/pci/hda/hda_jack.c b/sound/pci/hda/hda_jack.c index 07d5288..5bdbada 100644 --- a/sound/pci/hda/hda_jack.c +++ b/sound/pci/hda/hda_jack.c @@ -206,6 +206,8 @@ int snd_hda_jack_detect_enable_callback(struct hda_codec *codec, hda_nid_t nid, jack->action = action; if (cb) jack->callback = cb; + if (codec->jackpoll_interval > 0) + return 0; /* No unsol if we're polling instead */ return snd_hda_codec_write_cache(codec, nid, 0, AC_VERB_SET_UNSOLICITED_ENABLE, AC_USRSP_EN | jack->tag); -- 1.7.9.5

2 1

[alsa-devel] [PATCH] hda-emu: Handle snd_BUG()
by David Henningsson 17 Oct '12

17 Oct '12

Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- include/sound/core.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/sound/core.h b/include/sound/core.h index 57774ea..a749460 100644 --- a/include/sound/core.h +++ b/include/sound/core.h @@ -24,6 +24,7 @@ static inline int _snd_BUG_ON(int cond, const char *func, int line) return cond; } #define snd_BUG_ON(cond) _snd_BUG_ON(cond, __func__, __LINE__) +#define snd_BUG() snd_BUG_ON(1) #include "asound.h" #include "codec_config.h" -- 1.7.9.5

2 1

[alsa-devel] [PATCH] ALSA: hda - Always check array bounds in alc_get_line_out_pfx
by David Henningsson 17 Oct '12

17 Oct '12

Even when CONFIG_SND_DEBUG is not enabled, we don't want to return an arbitrary memory location when the channel count is larger than we expected. Cc: stable(a)kernel.org Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- Notes: This was found while debugging an OOPS on kernel 3.2. See https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1067269 for details. The badness calculation was improved in kernel 3.4; so not sure if the same could happen in later kernels, but at least apply to kernels <= 3.3 would make sense. Also adding to current trees (3.7, 3.8) would make sense IMO, just as extra safety. sound/pci/hda/patch_realtek.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 2d2bb66..651822c 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -2599,8 +2599,10 @@ static const char *alc_get_line_out_pfx(struct alc_spec *spec, int ch, return "PCM"; break; } - if (snd_BUG_ON(ch >= ARRAY_SIZE(channel_name))) + if (ch >= ARRAY_SIZE(channel_name)) { + snd_BUG(); return "PCM"; + } return channel_name[ch]; } -- 1.7.9.5

2 1

[alsa-devel] ASoC updates for 3.7
by Mark Brown 17 Oct '12

17 Oct '12

The following changes since commit 9911f7f7562a25381eff93fdc660a4a3b4c0f6e0: ASoC: codecs: Add DA9055 codec driver (2012-09-28 14:21:54 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-3.7 for you to fetch changes up to 9233ef6b559faa3db14144f41dea2e70d1ad0092: ASoC: bells: Correct typo in sub speaker DAI name for WM5110 (2012-10-17 19:01:38 +0900) ---------------------------------------------------------------- ASoC: Fixes for v3.7 Nothing too exciting except for the ams-delta change which is relatively lerge due to the fact that the driver loading had been totally broken as the driver needed a newer API to function. ---------------------------------------------------------------- Ashish Chavan (1): ASoC: codecs: da9055: Minor improvement in ALC calibration process Chris Ball (1): ARM: pxa: Fix build error caused by sram.h rename Guennadi Liakhovetski (1): ASoC: fsi: don't reschedule DMA from an atomic context Janusz Krzysztofik (1): ASoC: ams-delta: Convert to use snd_soc_register_card() Mark Brown (5): Merge branches 'asoc-twl6040' and 'asoc-omap' into for-3.7 ASoC: bells: Correct typo in sub speaker DAI name for WM5110 ASoC: wm2200: Use rev A register patches on rev B ASoC: wm2200: Fix non-inverted OUT2 mute control ASoC: bells: Correct typo in sub speaker DAI name for WM5110 Peter Meerwald (1): ASoC: fix documentation in soc-jack Peter Ujfalusi (4): ASoC: twl6040: Fix Stream DAPM mapping ASoC: omap-abe-twl6040: Fix typo of Vibrator ASoC: omap-mcpdm: Remove OMAP revision check ASoC: dmaengine: Correct Makefile when sound is built as module Tony Lindgren (1): ASoC: Fix wrong include for McPDM arch/arm/mach-omap1/board-ams-delta.c | 12 +++++++ sound/soc/Makefile | 5 +-- sound/soc/codecs/da9055.c | 22 +++++++++++- sound/soc/codecs/twl6040.c | 8 ++--- sound/soc/codecs/wm2200.c | 3 +- sound/soc/omap/ams-delta.c | 63 ++++++++++++++++----------------- sound/soc/omap/omap-abe-twl6040.c | 2 +- sound/soc/omap/omap-mcpdm.c | 9 ++--- sound/soc/pxa/mmp-pcm.c | 2 +- sound/soc/samsung/bells.c | 4 +-- sound/soc/sh/fsi.c | 15 ++++---- sound/soc/soc-jack.c | 7 ++-- 12 files changed, 90 insertions(+), 62 deletions(-)

2 1

[alsa-devel] ALSA hda_intel.c:834 spurious response ... ?
by Oleksij Rempel 17 Oct '12

17 Oct '12

Hallo all, i get with latest linus master fallowing messages after resume from suspend to ram: [ 9188.636589] ALSA hda_intel.c:834 spurious response 0x0:0x0, last cmd=0x170500 [ 9188.636592] ALSA hda_intel.c:834 spurious response 0x0:0x0, last cmd=0x170500 [ 9188.636595] ALSA hda_intel.c:834 spurious response 0x0:0x3, last cmd=0x301f0500 [ 9188.636598] ALSA hda_intel.c:834 spurious response 0x0:0x3, last cmd=0x301f0500 [ 9188.636601] ALSA hda_intel.c:834 spurious response 0x0:0x3, last cmd=0x301f0500 [ 9188.636604] ALSA hda_intel.c:834 spurious response 0x9000094:0x3, last cmd=0x301f0500 [ 9188.636606] ALSA hda_intel.c:834 spurious response 0x0:0x3, last cmd=0x301f0500 is it some thing you need to know? For more info see attached dmesg. -- Regards, Oleksij

2 3

[alsa-devel] [PATCH] hda-analyzer: Ignore unknown lines in proc file
by David Henningsson 17 Oct '12

17 Oct '12

With newer kernels, the proc file sometimes add more information. This makes hda-analyzer ignore such new additions by default, instead of the current behaviour (which is to crash with a stack trace). This way you can run an older hda-analyzer with a newer kernel. A recent example is the addition of "IEC Coding type" to all HDMI codecs. Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- hda-analyzer/hda_proc.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hda-analyzer/hda_proc.py b/hda-analyzer/hda_proc.py index a6dd3dc..7424365 100644 --- a/hda-analyzer/hda_proc.py +++ b/hda-analyzer/hda_proc.py @@ -721,7 +721,7 @@ class HDACodecProc(HDACodec, HDABaseProc): elif line.startswith(' Volume-Knob: '): node.add_volknob(line[15:]) else: - self.wrongfile(line) + print 'Unknown line, ignored: (%s)' % line idx += 1 if idx < len(lines): line = lines[idx] -- 1.7.9.5

1 0

Re: [alsa-devel] Silence playback during XRUN
by Babu, Ramesh 16 Oct '12

16 Oct '12

Hi I am trying to configure my application to use silence playback of ALSA in case XRUN. I am configuring the silence parameters as below: silence_threshold = 0 silence_size = boundary stop_threshold = bounday Using the above configuration I can see that ALSA sends silence during XRUN. But I am experiencing audio is jerky, when application starts sending the data after the XRUN. I noticed someone has met similar situation. http://mailman.alsa-project.org/pipermail/alsa-devel/2011-December/046894.h… Do I need to modify my silence settings? Anything that I need take care apart from the above mentioned parameters? Thanks Ramesh

1 1

[alsa-devel] [PATCH 1/2] ASoC: atmel-ssc: use devm_xxx() managed function
by Bo Shen 16 Oct '12

16 Oct '12

Using the devm_xxx() managed function to stripdown the error and remove code. Signed-off-by: Bo Shen <voice.shen(a)atmel.com> --- drivers/misc/atmel-ssc.c | 47 +++++++++++++++------------------------------- 1 file changed, 15 insertions(+), 32 deletions(-) diff --git a/drivers/misc/atmel-ssc.c b/drivers/misc/atmel-ssc.c index 5bb1877..23dcb76 100644 --- a/drivers/misc/atmel-ssc.c +++ b/drivers/misc/atmel-ssc.c @@ -70,37 +70,33 @@ EXPORT_SYMBOL(ssc_free); static int __init ssc_probe(struct platform_device *pdev) { - int retval = 0; struct resource *regs; struct ssc_device *ssc; - ssc = kzalloc(sizeof(struct ssc_device), GFP_KERNEL); + ssc = devm_kzalloc(&pdev->dev, sizeof(struct ssc_device), GFP_KERNEL); if (!ssc) { dev_dbg(&pdev->dev, "out of memory\n"); - retval = -ENOMEM; - goto out; + return -ENOMEM; } + ssc->pdev = pdev; + regs = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!regs) { dev_dbg(&pdev->dev, "no mmio resource defined\n"); - retval = -ENXIO; - goto out_free; + return -ENXIO; } - ssc->clk = clk_get(&pdev->dev, "pclk"); - if (IS_ERR(ssc->clk)) { - dev_dbg(&pdev->dev, "no pclk clock defined\n"); - retval = -ENXIO; - goto out_free; - } - - ssc->pdev = pdev; - ssc->regs = ioremap(regs->start, resource_size(regs)); + ssc->regs = devm_request_and_ioremap(&pdev->dev, regs); if (!ssc->regs) { dev_dbg(&pdev->dev, "ioremap failed\n"); - retval = -EINVAL; - goto out_clk; + return -EINVAL; + } + + ssc->clk = devm_clk_get(&pdev->dev, "pclk"); + if (IS_ERR(ssc->clk)) { + dev_dbg(&pdev->dev, "no pclk clock defined\n"); + return -ENXIO; } /* disable all interrupts */ @@ -112,8 +108,7 @@ static int __init ssc_probe(struct platform_device *pdev) ssc->irq = platform_get_irq(pdev, 0); if (!ssc->irq) { dev_dbg(&pdev->dev, "could not get irq\n"); - retval = -ENXIO; - goto out_unmap; + return -ENXIO; } spin_lock(&user_lock); @@ -125,16 +120,7 @@ static int __init ssc_probe(struct platform_device *pdev) dev_info(&pdev->dev, "Atmel SSC device at 0x%p (irq %d)\n", ssc->regs, ssc->irq); - goto out; - -out_unmap: - iounmap(ssc->regs); -out_clk: - clk_put(ssc->clk); -out_free: - kfree(ssc); -out: - return retval; + return 0; } static int __devexit ssc_remove(struct platform_device *pdev) @@ -142,10 +128,7 @@ static int __devexit ssc_remove(struct platform_device *pdev) struct ssc_device *ssc = platform_get_drvdata(pdev); spin_lock(&user_lock); - iounmap(ssc->regs); - clk_put(ssc->clk); list_del(&ssc->list); - kfree(ssc); spin_unlock(&user_lock); return 0; -- 1.7.9.5

6 8

[alsa-devel] [PATCH 1/2] ASoC: Ux500: Dispose of device nodes correctly
by Lee Jones 16 Oct '12

16 Oct '12

When of_parse_phandle() is used to find a device node, its reference count is incremented by the helper. Once we're finished with them, it's our responsibly to ensure they are freed in the correct manor. Cc: alsa-devel(a)alsa-project.org Cc: Liam Girdwood <lrg(a)ti.com> Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> Acked-by: Linus Walleij <linus.walleij(a)linaro.org> Signed-off-by: Lee Jones <lee.jones(a)linaro.org> --- sound/soc/ux500/mop500.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/sound/soc/ux500/mop500.c b/sound/soc/ux500/mop500.c index 6f67e6b..651a52a 100644 --- a/sound/soc/ux500/mop500.c +++ b/sound/soc/ux500/mop500.c @@ -57,6 +57,20 @@ static struct snd_soc_card mop500_card = { .num_links = ARRAY_SIZE(mop500_dai_links), }; +static void mop500_of_node_put(void) +{ + int i; + + for (i = 0; i < 2; i++) { + if (mop500_dai_links[i].cpu_of_node) + of_node_put((struct device_node *) + mop500_dai_links[i].cpu_of_node); + if (mop500_dai_links[i].codec_of_node) + of_node_put((struct device_node *) + mop500_dai_links[i].codec_of_node); + } +} + static int __devinit mop500_of_probe(struct platform_device *pdev, struct device_node *np) { @@ -69,6 +83,7 @@ static int __devinit mop500_of_probe(struct platform_device *pdev, if (!(msp_np[0] && msp_np[1] && codec_np)) { dev_err(&pdev->dev, "Phandle missing or invalid\n"); + mop500_of_node_put(); return -EINVAL; } @@ -83,6 +98,7 @@ static int __devinit mop500_of_probe(struct platform_device *pdev, return 0; } + static int __devinit mop500_probe(struct platform_device *pdev) { struct device_node *np = pdev->dev.of_node; @@ -128,6 +144,7 @@ static int __devexit mop500_remove(struct platform_device *pdev) snd_soc_unregister_card(mop500_card); mop500_ab8500_remove(mop500_card); + mop500_of_node_put(); return 0; } -- 1.7.9.5

2 2

[alsa-devel] [PATCH] ARM: tegra: remove <mach/dma.h>
by Stephen Warren 15 Oct '12

15 Oct '12

From: Stephen Warren <swarren(a)nvidia.com> Remove includes of <mach/dma.h> from sound/soc; nothing from it is used. Remove include of <mach/dma.h> from mach-tegra/apbio.c; since the DMA transfers made by this file don't need flow-control with any peripheral, there's no need to set any slave ID. Once those changes are made, there are no remaining users of <mach/dma.h> so remove it. Drivers should get this information from device tree. This removal is necessary for single zImage. Signed-off-by: Stephen Warren <swarren(a)nvidia.com> --- Mark, I'd like to take this through the Tegra tree please, unless you want me to split out the ASoC parts of the patch, and have you apply them to 3.7. arch/arm/mach-tegra/apbio.c | 3 -- arch/arm/mach-tegra/include/mach/dma.h | 54 -------------------------------- sound/soc/tegra/tegra30_ahub.c | 1 - sound/soc/tegra/tegra_pcm.h | 2 - 4 files changed, 0 insertions(+), 60 deletions(-) delete mode 100644 arch/arm/mach-tegra/include/mach/dma.h diff --git a/arch/arm/mach-tegra/apbio.c b/arch/arm/mach-tegra/apbio.c index b5015d0..bc949fb 100644 --- a/arch/arm/mach-tegra/apbio.c +++ b/arch/arm/mach-tegra/apbio.c @@ -24,8 +24,6 @@ #include <linux/sched.h> #include <linux/mutex.h> -#include <mach/dma.h> - #include "apbio.h" #if defined(CONFIG_TEGRA20_APB_DMA) @@ -71,7 +69,6 @@ bool tegra_apb_dma_init(void) dma_sconfig.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES; dma_sconfig.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES; - dma_sconfig.slave_id = TEGRA_DMA_REQ_SEL_CNTR; dma_sconfig.src_maxburst = 1; dma_sconfig.dst_maxburst = 1; diff --git a/arch/arm/mach-tegra/include/mach/dma.h b/arch/arm/mach-tegra/include/mach/dma.h deleted file mode 100644 index 3081cc6..0000000 --- a/arch/arm/mach-tegra/include/mach/dma.h +++ /dev/null @@ -1,54 +0,0 @@ -/* - * arch/arm/mach-tegra/include/mach/dma.h - * - * Copyright (c) 2008-2009, NVIDIA Corporation. - * - * 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., - * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. - */ - -#ifndef __MACH_TEGRA_DMA_H -#define __MACH_TEGRA_DMA_H - -#include <linux/list.h> - -#define TEGRA_DMA_REQ_SEL_CNTR 0 -#define TEGRA_DMA_REQ_SEL_I2S_2 1 -#define TEGRA_DMA_REQ_SEL_I2S_1 2 -#define TEGRA_DMA_REQ_SEL_SPD_I 3 -#define TEGRA_DMA_REQ_SEL_UI_I 4 -#define TEGRA_DMA_REQ_SEL_MIPI 5 -#define TEGRA_DMA_REQ_SEL_I2S2_2 6 -#define TEGRA_DMA_REQ_SEL_I2S2_1 7 -#define TEGRA_DMA_REQ_SEL_UARTA 8 -#define TEGRA_DMA_REQ_SEL_UARTB 9 -#define TEGRA_DMA_REQ_SEL_UARTC 10 -#define TEGRA_DMA_REQ_SEL_SPI 11 -#define TEGRA_DMA_REQ_SEL_AC97 12 -#define TEGRA_DMA_REQ_SEL_ACMODEM 13 -#define TEGRA_DMA_REQ_SEL_SL4B 14 -#define TEGRA_DMA_REQ_SEL_SL2B1 15 -#define TEGRA_DMA_REQ_SEL_SL2B2 16 -#define TEGRA_DMA_REQ_SEL_SL2B3 17 -#define TEGRA_DMA_REQ_SEL_SL2B4 18 -#define TEGRA_DMA_REQ_SEL_UARTD 19 -#define TEGRA_DMA_REQ_SEL_UARTE 20 -#define TEGRA_DMA_REQ_SEL_I2C 21 -#define TEGRA_DMA_REQ_SEL_I2C2 22 -#define TEGRA_DMA_REQ_SEL_I2C3 23 -#define TEGRA_DMA_REQ_SEL_DVC_I2C 24 -#define TEGRA_DMA_REQ_SEL_OWR 25 -#define TEGRA_DMA_REQ_SEL_INVALID 31 - -#endif diff --git a/sound/soc/tegra/tegra30_ahub.c b/sound/soc/tegra/tegra30_ahub.c index bf56101..64b67a3 100644 --- a/sound/soc/tegra/tegra30_ahub.c +++ b/sound/soc/tegra/tegra30_ahub.c @@ -26,7 +26,6 @@ #include <linux/regmap.h> #include <linux/slab.h> #include <mach/clk.h> -#include <mach/dma.h> #include <sound/soc.h> #include "tegra30_ahub.h" diff --git a/sound/soc/tegra/tegra_pcm.h b/sound/soc/tegra/tegra_pcm.h index b40279b..bc8b46a 100644 --- a/sound/soc/tegra/tegra_pcm.h +++ b/sound/soc/tegra/tegra_pcm.h @@ -31,8 +31,6 @@ #ifndef __TEGRA_PCM_H__ #define __TEGRA_PCM_H__ -#include <mach/dma.h> - struct tegra_pcm_dma_params { unsigned long addr; unsigned long wrap; -- 1.7.0.4

2 2

[alsa-devel] A question about speaker volume control of Creative Recon3D
by Ming Chen 15 Oct '12

15 Oct '12

Hello All, Recently I looked into the hda code for Creative sound cards, based on linux-3.6-rc3. I found that for Ca0110 (X-Fi), the patch (Patch_ca0110.c) would call add_out_volume() (and add_mono_volume()) for those DACs (refer to the ca0110_build_controls() function). While for ca0132 (Recon3D), its patch (Patch_ca0132.c) does not call add_out_volume() for any DAC (refer to the ca0132_build_controls() function). If I play a wav file under Ubuntu, it can adjust the speaker volume successfully with the Recon3D card. Can somebody kindly tell me how the speaker volume been controlled for this card? Thanks, Ming

1 0

Re: [alsa-devel] [RFC] Fix for conflict of HDMI and SPDIF IEC958 controls
by Raymond Yau 15 Oct '12

15 Oct '12

> > > > > > > > > > > > how about those hdmi jack and iec958 on ad1989b? > > > > > > > > > > On AD codecs, all digital outputs are exposed as a single cloned > > > > > device with HDA_PCM_TYPE_SPDIF. > > > > > > > > how about ad1988b with nvidia codec ? > > > > > > Nvidia codec provides devices only with HDA_PCM_TYPE_HDMI, of course. > > > > > > > from user point of view , how can they differenitate hdmi jack is > > digital > > > > ouput and hdmi output ? > > > > > > The device 1 is from AD and the device 3 is from Nvidia codec, as you > > > can see below. And this is exactly the case the conflict happens as I > > > mentioned in the original mail. > > > > will your fix change the spdif of those motherboard with ad1988b which > > have iec958 but no hdmi jack ? > > It won't change anything unless both SPDIF and HDMI *devices* are > actually created. > > > > > > Which is connected to what output, you can't know exactly unless you > > > compare the obtained ELD. The HD-audio spec isn't good enough to > > > identify the actual output. > > > > it seem that there is no presence detect on this codec > > ELD has nothing to do with the presence detect bit. > ftp://download.nvidia.com/XFree86/gpu-hdmi-audio-document/gpu-hdmi-audio.ht… 6.1.2. Chipset with 8-channel support, single stream This configuration is used in MCP77, MCP78, MCP79, MCP7A, and ION. In the case where multiple HDMI display connectors are present, the audio stream is broadcast to all HDMI connectors at once. A single ALSA device is exposed. ELD and PD information is not available on these chipsets. In these chipsets, the multiple 2-channel converters are aggregated by the ALSA driver and exposed as a single 8-channel device. Some chipsets support 2, or 8 channels (MCP77). Other chipsets support 2, 6, or 8 channels (MCP79). id = 0x10de0002, .name = "MCP77/78 HDMI", .patch = patch_nvhdmi_8ch_7x }, does it mean that this hdmi codec support 8 channels but no ELD info ? > > > Codec: Nvidia MCP77/78 HDMI > > Address: 3 > > AFG Function Id: 0x1 (unsol 0) > > Vendor Id: 0x10de0002 > > Subsystem Id: 0x10de0101 > > Revision Id: 0x100000 > > No Modem Function Group found > > Default PCM: > > rates [0x0]: > > bits [0x0]: > > formats [0x0]: > > Default Amp-In caps: N/A > > Default Amp-Out caps: N/A > > GPIO: io=0, o=0, i=0, unsolicited=0, wake=0 > > Node 0x04 [Audio Output] wcaps 0x211: Stereo Digital > > Control: name="IEC958 Playback Con Mask", index=1, device=0 > > Control: name="IEC958 Playback Pro Mask", index=1, device=0 > > Control: name="IEC958 Playback Default", index=1, device=0 > > Control: name="IEC958 Playback Switch", index=1, device=0 > > Device: name="HDMI 0", type="HDMI", device=3 > > Converter: stream=0, channel=0 > > Digital: > > Digital category: 0x0 > > PCM: > > rates [0xc0]: 48000 88200 > > bits [0xf]: 8 16 20 24 > > formats [0x1]: PCM > > Node 0x05 [Pin Complex] wcaps 0x400381: Stereo Digital > > Pincap 0x00000014: OUT Detect > > Pin Default 0x18560110: [Jack] Digital Out at Int HDMI > > Conn = Digital, Color = Unknown > > DefAssociation = 0x1, Sequence = 0x0 > > Misc = NO_PRESENCE > > Pin-ctls: 0x40: OUT > > Unsolicited: tag=00, enabled=0 > > Connection: 1 > > 0x04 > > > > > > > > > > > > https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/881826 > > > >

2 1

[alsa-devel] Invitation to connect on LinkedIn
by Hao Song via LinkedIn 15 Oct '12

15 Oct '12

LinkedIn ------------ Hao Song requested to add you as a connection on LinkedIn: ------------------------------------------ abdul, I'd like to add you to my professional network on LinkedIn. - Hao Accept invitation from Hao Song http://www.linkedin.com/e/jpxkk3-h8bk8zsc-2g/uii-rtptP1H4ViCg9YiBUOvto1r4_5… View profile of Hao Song http://www.linkedin.com/e/jpxkk3-h8bk8zsc-2g/rso/64047763/aTEQ/name/1380363… ------------------------------------------ You are receiving Invitation emails. This email was intended for abdul moiz. Learn why this is included: http://www.linkedin.com/e/jpxkk3-h8bk8zsc-2g/plh/http%3A%2F%2Fhelp%2Elinked… (c) 2012, LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

1 0

[alsa-devel] [asoc:topic/wm2200] sound/soc/codecs/wm2200.c:1033:4: warning: format '%d' expects argument of type 'int', but argument 4 has type 'size_t'
by Yuanhan Liu 15 Oct '12

15 Oct '12

Hi Mark, FYI, there are new compile warnings show up in tree: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/wm2200 head: 9874482985fb26f90c3b2d8f1a82bd796d141304 commit: 6e87badd3f38e1a095d6e1b13828246c3e8486b5 ASoC: wm2200: Provide initial coefficient loading config: x86_64-allmodconfig # make ARCH=x86_64 allmodconfig All warnings: sound/soc/codecs/wm2200.c: In function 'wm2200_dsp_load': sound/soc/codecs/wm2200.c:1033:4: warning: format '%d' expects argument of type 'int', but argument 4 has type 'size_t' [-Wformat] sound/soc/codecs/wm2200.c:1145:5: warning: format '%d' expects argument of type 'int', but argument 5 has type 'long unsigned int' [-Wformat] sound/soc/codecs/wm2200.c: In function 'wm2200_setup_algs': sound/soc/codecs/wm2200.c:1187:2: warning: format '%d' expects argument of type 'int', but argument 7 has type 'size_t' [-Wformat] sound/soc/codecs/wm2200.c:1207:5: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat] sound/soc/codecs/wm2200.c: In function 'wm2200_load_coeff': sound/soc/codecs/wm2200.c:1270:4: warning: format '%d' expects argument of type 'int', but argument 4 has type 'size_t' [-Wformat] sound/soc/codecs/wm2200.c:1334:5: warning: format '%d' expects argument of type 'int', but argument 5 has type 'long unsigned int' [-Wformat] vim +1033 sound/soc/codecs/wm2200.c e10f8711 Mark Brown 2012-10-04 1017 break; e10f8711 Mark Brown 2012-10-04 1018 default: e10f8711 Mark Brown 2012-10-04 1019 dev_err(codec->dev, "BASE %x\n", base); e10f8711 Mark Brown 2012-10-04 1020 BUG_ON(1); e10f8711 Mark Brown 2012-10-04 1021 return -EINVAL; e10f8711 Mark Brown 2012-10-04 1022 } e10f8711 Mark Brown 2012-10-04 1023 e10f8711 Mark Brown 2012-10-04 1024 ret = request_firmware(&firmware, file, codec->dev); e10f8711 Mark Brown 2012-10-04 1025 if (ret != 0) { e10f8711 Mark Brown 2012-10-04 1026 dev_err(codec->dev, "Failed to request '%s'\n", file); e10f8711 Mark Brown 2012-10-04 1027 return ret; e10f8711 Mark Brown 2012-10-04 1028 } e10f8711 Mark Brown 2012-10-04 1029 e10f8711 Mark Brown 2012-10-04 1030 pos = sizeof(*header) + sizeof(*adsp1_sizes) + sizeof(*footer); e10f8711 Mark Brown 2012-10-04 1031 if (pos >= firmware->size) { e10f8711 Mark Brown 2012-10-04 1032 dev_err(codec->dev, "%s: file too short, %d bytes\n", e10f8711 Mark Brown 2012-10-04 @1033 file, firmware->size); e10f8711 Mark Brown 2012-10-04 1034 return -EINVAL; e10f8711 Mark Brown 2012-10-04 1035 } e10f8711 Mark Brown 2012-10-04 1036 e10f8711 Mark Brown 2012-10-04 1037 header = (void*)&firmware->data[0]; e10f8711 Mark Brown 2012-10-04 1038 e10f8711 Mark Brown 2012-10-04 1039 if (memcmp(&header->magic[0], "WMFW", 4) != 0) { e10f8711 Mark Brown 2012-10-04 1040 dev_err(codec->dev, "%s: invalid magic\n", file); e10f8711 Mark Brown 2012-10-04 1041 return -EINVAL; --- 0-DAY kernel build testing backend Open Source Technology Center Fengguang Wu, Yuanhan Liu Intel Corporation

1 0

[alsa-devel] snd_ctl_elem_list
by Paul 15 Oct '12

15 Oct '12

Newbie. Trying to discover information about the audio hardware. Specifically about a USB microphone ( Audio-Technia AT2020USB ) and whether it has a volume control. Writing in Ada just to be difficult. Not having any problems with that though. After doing a malloc and a snd_ctl_elem_list I can use ctl_elem_list_count to get the number of elements. This number is non-zero ( 2 for the AT2020, 34 for the on-board Intel audio chip ). Then I can use ctl_elem_to get the number of used. That number is zero and prevents me from trying to access the element list. How can I find out information about the elements in the list? How do these elements become used? Is this even the correct path to try to discover the volume control? Thanks, Paul I

1 0

Re: [alsa-devel] sound/pci/hda/hda_codec.c:1435:46: error: 'AC_VERB_GET_CON' undeclared
by Takashi Iwai 15 Oct '12

15 Oct '12

At Sat, 13 Oct 2012 01:01:09 +0800, Fengguang Wu wrote: > > Hi Takashi, > > FYI, kernel build failed on > > commit: 645cf3b5656e47fa9a46e2fbc8d212ab572ab05b Merge branch 'topic/3.8' > config: x86_64-allyesdebian (attached as .config) > > > All error/warnings: > > sound/pci/hda/hda_codec.c: In function 'update_pcm_stream_id': > sound/pci/hda/hda_codec.c:1435:46: error: 'AC_VERB_GET_CON' undeclared (first use in this function) > sound/pci/hda/hda_codec.c:1435:46: note: each undeclared identifier is reported only once for each function it appears in Thanks, this must be already fixed. It was a temporary merge error. (One shouldn't work during updating the system....) Takashi

3 4

[alsa-devel] Support for Roland VG-99
by Pete Leigh 14 Oct '12

14 Oct '12

Hi, The VG-99 is a guitar processor with a usb interface which offers 2x16bit 44100 pcm in and out streams in its basic usb mode, and 2x24bit 44100 in/out + midi in the advanced mode connection mode. Basic mode works fine with usb snd driver, but the device isn't recognised when set to advanced mode (this is done under USB on page 2 of the "system" config menu) I've used the lsusb -v output (below) to guess at an addition to sound/usb/quirks-table.h to try and get this working. On initial (brief) testing, audio in/out at 24bits (as shown by jackd output) and midi (out, at least) are all working. I'll attach the quirk, and would be pleased if someone could look at it, and the lsusb output, and fix up any deficiencies (it's purely voodoo here :-D) and maybe get it or something like it into the official source... please let me know if changes need to be tested. Cheers, - Pete. Here's the lsusb output: Bus 001 Device 007: ID 0582:00b2 Roland Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 8 idVendor 0x0582 Roland Corp. idProduct 0x00b2 bcdDevice 1.00 iManufacturer 1 Roland iProduct 2 VG-99 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 167 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 06 24 f1 01 00 00 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 03 18 01 44 ac 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 9 Transfer Type Isochronous Synch Type Adaptive Usage Type Data wMaxPacketSize 0x0120 1x 288 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 ** UNRECOGNIZED: 07 24 01 07 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 03 18 01 44 ac 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0120 1x 288 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 06 24 f1 02 02 02 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 1 Device Status: 0x0001 Self Powered

1 0

[alsa-devel] snd-usb-audio probe problem (Teac UD-H01)
by bEN 13 Oct '12

13 Oct '12

Hi all, the new USB DAC from Teac seems detected as 'Human Interface Device' instead of 'Audio'. Despite the fact it is based on a standard USB Audio class v2 controller (Tenor 8802). Below is dmesg and lsusb outputs. Does it need to apply a patch in /sound/usb/quirks-table.h ? If yes, someone could help me to write this patch, please? Your help would be very much appreciated, Thanks in advance. bEN (from Ubuntu 11.04 with Linux 2.6.38-13-generic + Alsa driver 1.0.23) $ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.23. $ dmesg (...) [34035.000078] usb 2-4: new high speed USB device using ehci_hcd and address 3 [34035.151753] usb 2-4: config 1 has an invalid interface number: 3 but max is 2 [34035.151763] usb 2-4: config 1 has an invalid interface number: 3 but max is 2 [34035.151770] usb 2-4: config 1 has an invalid interface number: 3 but max is 2 [34035.151777] usb 2-4: config 1 has no interface number 1 [34035.155108] input: TEAC TEAC USB AUDIO DEVICE as /devices/pci0000:00/0000:00:1d.7/usb2/2-4/2-4:1.0/input/input13 [34035.155328] generic-usb 0003:0644:8038.0002: input,hidraw1: USB HID v1.00 Device [TEAC TEAC USB AUDIO DEVICE] on usb-0000:00:1d.7-4/input0 [34035.202368] Audio class v2 interfaces need an interface association [34035.202387] snd-usb-audio: probe of 2-4:1.2 failed with error -5 [34035.202426] usbcore: registered new interface driver snd-usb-audio $ lsusb -v --> see attachment.

5 6

[alsa-devel] bit depth issue for Scarlett 2i4
by Dan MacDonald 13 Oct '12

13 Oct '12

Hi ALSA devs! I recently bought a Focusrite Scarlett 2i4 which is advertised as being capable of recording at a max of 24bit/96Khz but when I run alsacap it reports it as 32bit: ./alsacap -R -d hw:1 *** Exploring configuration space of device `hw:1' for recording *** 2 channels Sampling rate 44100..96000 Hz Sample formats: S32_LE Significant bits: 32 It does seem to record OK but that output seems wrong and I'm slightly concerned about the waste of disk space when multitracking if I end up with 32bit files but only 24 of those bits per sample are actually being used. Thanks for your help! Dan

2 1

[alsa-devel] Question about rawmidi USB Tx buffer size
by Paul D. DeRocco 12 Oct '12

12 Oct '12

Simple question: how big is it? ALSA provides snd_rawmidi_status for reading the status structure from a rawmidi handle, and snd_rawmidi_status_get_avail to extract the number of bytes in the ring buffer from that structure, but what I want to know is how many bytes of space are available in the ring buffer, so that I know how many bytes I can write without blocking. Is the buffer size a fixed number for any particular driver? The only driver I'm concerned with is the USB MIDI driver, so that shouldn't be hardware dependent. -- Ciao, Paul D. DeRocco Paul mailto:pderocco@ix.netcom.com

1 0

[alsa-devel] [PATCH 0/2] dmaengine: Fix compillation issues in device_prep_dma_cyclic()
by Peter Ujfalusi 12 Oct '12

12 Oct '12

Hello, The reason for the breakage is the patch 1 got lost somewhere in the process. I also greped the whole tree for device_prep_dma_cyclic() and the second patch is the result of that. PS: I did build tested the series on ARM (OMAP), x86_32, x86_64 but not for ppc for sure. Regards, Peter --- Peter Ujfalusi (2): dmaengine: Add flags parameter to dmaengine_prep_dma_cyclic() ARM: SAMSUNG: dma-ops: Fix dmaengine_prep_dma_cyclic() parameter list arch/arm/plat-samsung/dma-ops.c | 3 ++- include/linux/dmaengine.h | 3 ++- sound/soc/soc-dmaengine-pcm.c | 6 +++++- 3 files changed, 9 insertions(+), 3 deletions(-) -- 1.7.12

5 7

Re: [alsa-devel] [3.6-rc7] switcheroo race with Intel HDA...
by Takashi Iwai 12 Oct '12

12 Oct '12

At Fri, 12 Oct 2012 23:08:14 +0800, Daniel J Blueman wrote: > > On 10 October 2012 20:34, Takashi Iwai <tiwai(a)suse.de> wrote: > > At Tue, 9 Oct 2012 22:26:40 +0800, > > Daniel J Blueman wrote: > >> On 9 October 2012 21:04, Takashi Iwai <tiwai(a)suse.de> wrote: > >> > At Tue, 9 Oct 2012 19:23:56 +0800, > >> > Daniel J Blueman wrote: > >> >> On 9 October 2012 18:07, Takashi Iwai <tiwai(a)suse.de> wrote: > >> >> > At Tue, 09 Oct 2012 12:04:08 +0200, > >> >> > Takashi Iwai wrote: > >> >> >> At Tue, 9 Oct 2012 00:34:09 +0800, > >> >> >> Daniel J Blueman wrote: > >> >> >> > On 8 October 2012 20:58, Takashi Iwai <tiwai(a)suse.de> wrote: > >> >> >> > > At Tue, 25 Sep 2012 13:20:05 +0800, > >> >> >> > > Daniel J Blueman wrote: > >> >> >> > >> On my Macbook with a discrete Nvidia GPU, there is a race between > >> >> >> > >> selecting the integrated GPU and putting the discrete GPU into D3 [1], > >> >> >> > >> reliably causing a kernel oops [2]. > >> >> >> > >> > >> >> >> > >> Introducing a delay of ~1s between the calls prevents this. When the > >> >> >> > >> second 'OFF' write path executes, it looks like struct azx at > >> >> >> > >> card->private_data hasn't yet been allocated yet [3], so there is > >> >> >> > >> likely some locking missing. > >> >> >> > > > >> >> >> > > It's rather pci_get_drvdata() returning NULL (i.e. card is NULL, thus > >> >> >> > > card->private_data causes Oops). Could you check the patch like below > >> >> >> > > and see whether you get a kernel warning (but no Oops) or the problem > >> >> >> > > gets fixed by shifting the assignment of pci drvdata? > >> >> >> > [...] > >> >> >> > > >> >> >> > Good patching. Calling pci_set_drvdata later prevents the oops in HDA, > >> >> >> > though we see unexpected 0x0 responses in the response ring buffer > >> >> >> > [1], which we don't see when there's a >~1.5s delay between IGD and > >> >> >> > OFF. > >> >> >> > >> >> >> If the previous patch fixed, it means that the switching occurred > >> >> >> during the device was being probed. Maybe a better approach to > >> >> >> register the VGA switcheroo after the proper initialization. > >> >> >> > >> >> >> The patch below is a revised one. Please give it a try. > >> >> > > >> >> > Also, it's not clear which card spews the spurious response. > >> >> > Apply the patch below in addition. > >> >> [...] > >> >> > >> >> hda-intel: 0000:01:00.1: spurious response 0x0:0x0, last cmd=0x1f0004 > >> >> $ lspci -s :1:0.1 > >> >> 01:00.1 Audio device: NVIDIA Corporation Device 0e1b (rev ff) > >> >> > >> >> It's the NVIDIA device which presumably hasn't completed it's > >> >> transition to D3 at the time the OFF is executed. > >> > > >> > OK, then could you try the patch below on the top of previous two > >> > patches? > >> > >> The first IGD switcheroo command fails to switch to the integrated GPU: > >> > >> # cat /sys/kernel/debug/vgaswitcheroo/switch > >> 0:DIS:+:Pwr:0000:01:00.0 > >> 1:IGD: :Pwr:0000:00:02.0 > >> 2:DIS-Audio: :Pwr:0000:01:00.1 > >> # echo IGD >/sys/kernel/debug/vgaswitcheroo/switch > >> vga_switcheroo: client 1 refused switch > >> > >> I also instrumented snd_hda_lock_devices, but none of the failure > >> paths are being taken, which would leave inconsistent state, as the > >> return value isn't checked. > > > > Hm, right, the return value of snd_hda_lock_devices() isn't checked, > > but I don't understand how this results like above. > > Basically switching is protected by mutex in vga_switcheroo.c, so the > > whole operation in the client side should be serialized. > > > > In anyway, try the patch below cleanly, and see the spurious message > > error coming up at which timing. > [...] > > The patch _does_ address the issue. A recent update to my Macbook > firmware misleadingly broke i915 switching, but since I can reproduce > the oops without the IGD switching completing with the stock kernel, > and consistently can't without [1], the patch is good. > > Tested-by: Daniel J Blueman <daniel(a)quora.org> OK, then I'm going to apply the patch to 3.7 tree (with Cc to stable). thanks, Takashi > > Thanks Takashi! > Daniel > > --- [1] > > snd_hda_intel 0000:00:1b.0: enabling device (0000 -> 0002) > snd_hda_intel 0000:00:1b.0: irq 54 for MSI/MSI-X > XXX 0000:00:1b.0: azx_codec_create entered > vga_switcheroo: enabled > XXX 0000:00:1b.0: azx_codec_create done > input: HDA Intel PCH Headphone as > /devices/pci0000:00/0000:00:1b.0/sound/card0/input9 > snd_hda_intel 0000:01:00.1: enabling device (0000 -> 0002) > hda_intel: Disabling MSI > hda-intel: 0000:01:00.1: Handle VGA-switcheroo audio client > XXX 0000:01:00.1: azx_codec_create entered > XXX 0000:01:00.1: azx_codec_create done > input: HDA NVidia HDMI/DP,pcm=8 as > /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input12 > input: HDA NVidia HDMI/DP,pcm=7 as > /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input13 > input: HDA NVidia HDMI/DP,pcm=3 as > /devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/input14 > vga_switcheroo: client 1 refused switch > i915: switched off > -- > Daniel J Blueman >

1 0

[alsa-devel] [PATCH 0/2] USB-audio disconnection race fixes
by Takashi Iwai 12 Oct '12

12 Oct '12

Hi, these two patches are for fixing races at disconnection of USB audio devices. The first patch tries to close the race at open/close, and the next is for other PCM and mixer ops in usb-audio driver. It seems working as far as I've tested with Matthieu's test cases. thanks, Takashi

1 2

[alsa-devel] [RFC PATCH] ALSA: hda - Implement a poll loop for jacks as a module parameter
by David Henningsson 12 Oct '12

12 Oct '12

Now that we have a generic unsol mechanism, we can implement a generic poll loop, which can be used for debugging, or if a codec's unsol mechanism is broken. Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- I'm also considering activating it by default if we go into single_cmd mode due to codec not responding. What do you think? sound/pci/hda/hda_codec.c | 32 ++++++++++++++++++++++++++++---- sound/pci/hda/hda_codec.h | 2 ++ sound/pci/hda/hda_intel.c | 5 +++++ sound/pci/hda/hda_jack.c | 22 ++++++++++++++++++++++ sound/pci/hda/hda_jack.h | 2 ++ 5 files changed, 59 insertions(+), 4 deletions(-) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index c0ab72c..626e45b 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -1135,6 +1135,19 @@ static void restore_shutup_pins(struct hda_codec *codec) } #endif +static void hda_jackpoll_work(struct work_struct *work) +{ + struct hda_codec *codec = + container_of(work, struct hda_codec, jackpoll_work.work); + if (!codec->jackpoll_interval) + return; + + snd_hda_jack_set_dirty_all(codec); + snd_hda_jack_poll_all(codec); + queue_delayed_work(codec->bus->workq, &codec->jackpoll_work, + codec->jackpoll_interval); +} + static void init_hda_cache(struct hda_cache_rec *cache, unsigned int record_size); static void free_hda_cache(struct hda_cache_rec *cache); @@ -1190,6 +1203,7 @@ static void snd_hda_codec_free(struct hda_codec *codec) { if (!codec) return; + cancel_delayed_work_sync(&codec->jackpoll_work); snd_hda_jack_tbl_clear(codec); restore_init_pincfgs(codec); #ifdef CONFIG_PM @@ -1273,6 +1287,7 @@ int /*__devinit*/ snd_hda_codec_new(struct hda_bus *bus, snd_array_init(&codec->cvt_setups, sizeof(struct hda_cvt_setup), 8); snd_array_init(&codec->conn_lists, sizeof(hda_nid_t), 64); snd_array_init(&codec->spdif_out, sizeof(struct hda_spdif_out), 16); + INIT_DELAYED_WORK(&codec->jackpoll_work, hda_jackpoll_work); #ifdef CONFIG_PM spin_lock_init(&codec->power_lock); @@ -2349,7 +2364,7 @@ int snd_hda_codec_reset(struct hda_codec *codec) return -EBUSY; /* OK, let it free */ - + cancel_delayed_work_sync(&codec->jackpoll_work); #ifdef CONFIG_PM cancel_delayed_work_sync(&codec->power_work); codec->power_on = 0; @@ -3646,7 +3661,6 @@ static void hda_call_codec_resume(struct hda_codec *codec) restore_pincfgs(codec); /* restore all current pin configs */ restore_shutup_pins(codec); hda_exec_init_verbs(codec); - snd_hda_jack_set_dirty_all(codec); if (codec->patch_ops.resume) codec->patch_ops.resume(codec); else { @@ -3655,7 +3669,13 @@ static void hda_call_codec_resume(struct hda_codec *codec) snd_hda_codec_resume_amp(codec); snd_hda_codec_resume_cache(codec); } - snd_hda_jack_report_sync(codec); + + if (codec->jackpoll_interval) + hda_jackpoll_work(&codec->jackpoll_work.work); + else { + snd_hda_jack_set_dirty_all(codec); + snd_hda_jack_report_sync(codec); + } snd_hda_power_down(codec); /* flag down before returning */ } #endif /* CONFIG_PM */ @@ -3737,7 +3757,10 @@ int snd_hda_codec_build_controls(struct hda_codec *codec) if (err < 0) return err; - snd_hda_jack_report_sync(codec); /* call at the last init point */ + if (codec->jackpoll_interval) + hda_jackpoll_work(&codec->jackpoll_work.work); + else + snd_hda_jack_report_sync(codec); /* call at the last init point */ return 0; } @@ -5128,6 +5151,7 @@ int snd_hda_suspend(struct hda_bus *bus) struct hda_codec *codec; list_for_each_entry(codec, &bus->codec_list, list) { + cancel_delayed_work_sync(&codec->jackpoll_work); if (hda_codec_is_power_on(codec)) hda_call_codec_suspend(codec, false); } diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h index 507fe8a..10a03b0 100644 --- a/sound/pci/hda/hda_codec.h +++ b/sound/pci/hda/hda_codec.h @@ -884,6 +884,8 @@ struct hda_codec { /* jack detection */ struct snd_array jacktbl; + unsigned long jackpoll_interval; /* In jiffies. Zero means no poll, rely on unsol events */ + struct delayed_work jackpoll_work; #ifdef CONFIG_SND_HDA_INPUT_JACK /* jack detection */ diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index f09ff6c..b4f1ab8 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -68,6 +68,7 @@ static int position_fix[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS-1)] = -1}; static int bdl_pos_adj[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS-1)] = -1}; static int probe_mask[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS-1)] = -1}; static int probe_only[SNDRV_CARDS]; +static int jackpoll_ms[SNDRV_CARDS]; static bool single_cmd; static int enable_msi = -1; #ifdef CONFIG_SND_HDA_PATCH_LOADER @@ -95,6 +96,8 @@ module_param_array(probe_mask, int, NULL, 0444); MODULE_PARM_DESC(probe_mask, "Bitmask to probe codecs (default = -1)."); module_param_array(probe_only, int, NULL, 0444); MODULE_PARM_DESC(probe_only, "Only probing and no codec initialization."); +module_param_array(jackpoll_ms, int, NULL, 0444); +MODULE_PARM_DESC(jackpoll_ms, "Ms between polling for jack events (default = 0, using unsol events only)"); module_param(single_cmd, bool, 0444); MODULE_PARM_DESC(single_cmd, "Use single command to communicate with codecs " "(for debugging only)."); @@ -1666,6 +1669,8 @@ static int DELAYED_INIT_MARK azx_codec_create(struct azx *chip, const char *mode err = snd_hda_codec_new(chip->bus, c, &codec); if (err < 0) continue; + codec->jackpoll_interval = + msecs_to_jiffies(jackpoll_ms[chip->dev_index]); codec->beep_mode = chip->beep_mode; codecs++; } diff --git a/sound/pci/hda/hda_jack.c b/sound/pci/hda/hda_jack.c index 5c690cb..07d5288 100644 --- a/sound/pci/hda/hda_jack.c +++ b/sound/pci/hda/hda_jack.c @@ -439,3 +439,25 @@ void snd_hda_jack_unsol_event(struct hda_codec *codec, unsigned int res) } EXPORT_SYMBOL_HDA(snd_hda_jack_unsol_event); +void snd_hda_jack_poll_all(struct hda_codec *codec) +{ + struct hda_jack_tbl *jack = codec->jacktbl.list; + int i, changes = 0; + + for (i = 0; i < codec->jacktbl.used; i++, jack++) { + unsigned int old_sense; + if (!jack->nid || !jack->jack_dirty || jack->phantom_jack) + continue; + old_sense = get_jack_plug_state(jack->pin_sense); + jack_detect_update(codec, jack); + if (old_sense == get_jack_plug_state(jack->pin_sense)) + continue; + changes = 1; + if (jack->callback) + jack->callback(codec, jack); + } + if (changes) + snd_hda_jack_report_sync(codec); +} +EXPORT_SYMBOL_HDA(snd_hda_jack_poll_all); + diff --git a/sound/pci/hda/hda_jack.h b/sound/pci/hda/hda_jack.h index af8dd47..4487785 100644 --- a/sound/pci/hda/hda_jack.h +++ b/sound/pci/hda/hda_jack.h @@ -84,4 +84,6 @@ void snd_hda_jack_report_sync(struct hda_codec *codec); void snd_hda_jack_unsol_event(struct hda_codec *codec, unsigned int res); +void snd_hda_jack_poll_all(struct hda_codec *codec); + #endif /* __SOUND_HDA_JACK_H */ -- 1.7.9.5

2 9

Re: [alsa-devel] [PATCH 2.6.32.y, 2.6.34.y] ALSA: hda - ALSA HD Audio patch for Intel Panther Point DeviceIDs
by Ben Hutchings 12 Oct '12

12 Oct '12

On Tue, 2012-10-09 at 10:56 -0400, Paul Gortmaker wrote: > On 12-10-08 09:55 PM, Ben Hutchings wrote: > > On Mon, 2012-10-08 at 18:07 -0700, Jonathan Nieder wrote: > >> From: Seth Heasley <seth.heasley(a)intel.com> > >> Date: Wed, 20 Apr 2011 10:59:57 -0700 > >> > >> commit d2edeb7c6f1dada8ca7d5c23e42d604e92ae0c76 upstream. > >> > >> This patch adds the HD Audio Controller DeviceIDs for the Intel Panther Point PCH. > >> > >> [jn: backported for 2.6.32.y by Ana Guerrero] > >> > >> Signed-off-by: Seth Heasley <seth.heasley(a)intel.com> > >> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> > >> Tested-by: Ana Guerrero <ana(a)debian.org> # EliteBook 8570w > >> Signed-off-by: Jonathan Nieder <jrnieder(a)gmail.com> > >> --- > >> Hi Willy and Paul, > >> > >> Please consider > >> > >> d2edeb7c6f1d ALSA: hda - ALSA HD Audio patch for Intel Panther Point > >> DeviceIDs > >> > >> for application to the 2.6.32.y and 2.6.34.y trees. > >> > >> It does what it says on the cover. The patch was merged in the 3.0 > >> cycle, so newer stable kernels don't need it. Backported and > >> tested[1] against Debian's 2.6.32.y-based kernel by Ana (cc-ed) -- > >> thanks! > >> > >> Thoughts of all kinds welcome, as always. > > [...] > > > > I queued up a whole series of device ID updates for Debian stable, as > > they didn't obviously depend on other changes: > > > > cea310e ALSA: hda_intel: ALSA HD Audio patch for Intel Patsburg DeviceIDs > > e35d4b1 ALSA: hda: add Vortex86MX PCI ids > > 0f0714c ALSA: hda - Add support for VMware controller > > d2edeb7 ALSA: hda - ALSA HD Audio patch for Intel Panther Point DeviceIDs > > I found that d2edeb7c6f depends (only trivially, on context) on b686453543f, > which makes a blanket class for intel IDs so that "...the driver will work > with any new control chips in future." In that respect, I guess it too > (b68645) is in the same class as the other "add more IDs" patches? Yes, it seems like this would also be worth adding. (Always assuming that any functional changes it depends on are also small enough for stable.) It's not a clean cherry-pick as the line above has changed. Ben. > Paul. > -- > > > > > (They can be cherry-picked cleanly in the above order.) But if I've > > missed some post-2.6.32 dependencies then I would like to know. > > > > Ben. > > > -- Ben Hutchings Kids! Bringing about Armageddon can be dangerous. Do not attempt it in your own home. - Terry Pratchett and Neil Gaiman, `Good Omens'

1 0

[alsa-devel] Arecord issue
by kartik natarajan 11 Oct '12

11 Oct '12

Hi, I am working on a 2.6.37 kernel and on a DM365 davinci board with a tlv320aic3254 audio codec (i2c control lines, i2s data transfer) I wanted to get the audio up on my board so got the alsa-lib and alsa-utils 1.0.25 compiled them and got the aplay to work fine. When I got to working on the arecord things haven't worked fine. I have traced all the calls and have reached so far; codec gets set properly davinci_pcm_trigger executes with success snd_pcm_sw_params() executes successfully. aplay calls begin_wave() aplay calls pcm_read() that invokes snd_pcm_readi() Finally my app seems to not go beyond the snd_pcm_start() Any assistance shall be highly appreciated! Thanks in advance, N.Kartik

2 3

[alsa-devel] [PATCH] ASoC: codecs: da9055: Minor improvement in ALC calibration process
by Ashish Chavan 11 Oct '12

11 Oct '12

This patch slightly improves ALC calibration process of da9055 codec driver by muting Mic PGAs during calibration. Signed-off-by: Ashish Chavan <ashish.chavan(a)kpitcummins.com> Signed-off-by: David Dajun Chen <david.chen(a)diasemi.com> --- sound/soc/codecs/da9055.c | 22 +++++++++++++++++++++- 1 files changed, 21 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/da9055.c b/sound/soc/codecs/da9055.c index 27c4454..abf3e43 100644 --- a/sound/soc/codecs/da9055.c +++ b/sound/soc/codecs/da9055.c @@ -179,6 +179,12 @@ #define DA9055_AIF_WORD_S24_LE (2 << 2) #define DA9055_AIF_WORD_S32_LE (3 << 2) +/* MIC_L_CTRL bit fields */ +#define DA9055_MIC_L_MUTE_EN (1 << 6) + +/* MIC_R_CTRL bit fields */ +#define DA9055_MIC_R_MUTE_EN (1 << 6) + /* MIXIN_L_CTRL bit fields */ #define DA9055_MIXIN_L_MIX_EN (1 << 3) @@ -477,7 +483,7 @@ static int da9055_put_alc_sw(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol); - u8 reg_val, adc_left, adc_right; + u8 reg_val, adc_left, adc_right, mic_left, mic_right; int avg_left_data, avg_right_data, offset_l, offset_r; if (ucontrol->value.integer.value[0]) { @@ -486,6 +492,16 @@ static int da9055_put_alc_sw(struct snd_kcontrol *kcontrol, * offsets must be done first */ + /* Save current values from Mic control registers */ + mic_left = snd_soc_read(codec, DA9055_MIC_L_CTRL); + mic_right = snd_soc_read(codec, DA9055_MIC_R_CTRL); + + /* Mute Mic PGA Left and Right */ + snd_soc_update_bits(codec, DA9055_MIC_L_CTRL, + DA9055_MIC_L_MUTE_EN, DA9055_MIC_L_MUTE_EN); + snd_soc_update_bits(codec, DA9055_MIC_R_CTRL, + DA9055_MIC_R_MUTE_EN, DA9055_MIC_R_MUTE_EN); + /* Save current values from ADC control registers */ adc_left = snd_soc_read(codec, DA9055_ADC_L_CTRL); adc_right = snd_soc_read(codec, DA9055_ADC_R_CTRL); @@ -521,6 +537,10 @@ static int da9055_put_alc_sw(struct snd_kcontrol *kcontrol, /* Restore original values of ADC control registers */ snd_soc_write(codec, DA9055_ADC_L_CTRL, adc_left); snd_soc_write(codec, DA9055_ADC_R_CTRL, adc_right); + + /* Restore original values of Mic control registers */ + snd_soc_write(codec, DA9055_MIC_L_CTRL, mic_left); + snd_soc_write(codec, DA9055_MIC_R_CTRL, mic_right); } return snd_soc_put_volsw(kcontrol, ucontrol); -- 1.7.1

2 1

[alsa-devel] [PATCH] ASoC: codecs: da9055: Add support for DSP mode of AIF
by Ashish Chavan 11 Oct '12

11 Oct '12

This patch adds AIF DSP mode support for da9055 codec driver. Signed-off-by: Ashish Chavan <ashish.chavan(a)kpitcummins.com> Signed-off-by: David Dajun Chen <david.chen(a)diasemi.com> --- sound/soc/codecs/da9055.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/sound/soc/codecs/da9055.c b/sound/soc/codecs/da9055.c index 185d8dd..27c4454 100644 --- a/sound/soc/codecs/da9055.c +++ b/sound/soc/codecs/da9055.c @@ -173,6 +173,7 @@ #define DA9055_AIF_FORMAT_I2S_MODE (0 << 0) #define DA9055_AIF_FORMAT_LEFT_J (1 << 0) #define DA9055_AIF_FORMAT_RIGHT_J (2 << 0) +#define DA9055_AIF_FORMAT_DSP (3 << 0) #define DA9055_AIF_WORD_S16_LE (0 << 2) #define DA9055_AIF_WORD_S20_3LE (1 << 2) #define DA9055_AIF_WORD_S24_LE (2 << 2) @@ -1155,6 +1156,9 @@ static int da9055_set_dai_fmt(struct snd_soc_dai *codec_dai, unsigned int fmt) case SND_SOC_DAIFMT_RIGHT_J: aif_ctrl = DA9055_AIF_FORMAT_RIGHT_J; break; + case SND_SOC_DAIFMT_DSP_A: + aif_ctrl = DA9055_AIF_FORMAT_DSP; + break; default: return -EINVAL; } -- 1.7.1

2 1

[alsa-devel] [PATCH V7 12/15] ALSA: HDA: Make hda sound card usable for Loongson
by Huacai Chen 11 Oct '12

11 Oct '12

Lemote A1004(Laptop) and A1205(All-In-One) use Conexant's hda codec, this patch modify patch_conexant.c to add Lemote specific code. Both A1004 and A1205 use the same pin configurations, but A1004 need to increase the default boost of internal mic. Signed-off-by: Jie Chen <chenj(a)lemote.com> Signed-off-by: Huacai Chen <chenhc(a)lemote.com> Signed-off-by: Hongliang Tao <taohl(a)lemote.com> Signed-off-by: Hua Yan <yanh(a)lemote.com> Cc: alsa-devel(a)alsa-project.org --- sound/pci/hda/patch_conexant.c | 44 ++++++++++++++++++++++++++++++++++++++++ 1 files changed, 44 insertions(+), 0 deletions(-) diff --git a/sound/pci/hda/patch_conexant.c b/sound/pci/hda/patch_conexant.c index 5e22a8f..3cc265e 100644 --- a/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_conexant.c @@ -4408,7 +4408,10 @@ static const struct hda_codec_ops cx_auto_patch_ops = { enum { CXT_PINCFG_LENOVO_X200, CXT_PINCFG_LENOVO_TP410, + CXT_PINCFG_LEMOTE_A1004, + CXT_PINCFG_LEMOTE_A1205, CXT_FIXUP_STEREO_DMIC, + CXT_FIXUP_INC_MIC_BOOST, }; static void cxt_fixup_stereo_dmic(struct hda_codec *codec, @@ -4418,6 +4421,19 @@ static void cxt_fixup_stereo_dmic(struct hda_codec *codec, spec->fixup_stereo_dmic = 1; } +static void cxt5066_increase_mic_boost(struct hda_codec *codec, + const struct hda_fixup *fix, int action) +{ + if (action != HDA_FIXUP_ACT_PRE_PROBE) + return; + + snd_hda_override_amp_caps(codec, 0x17, HDA_OUTPUT, + (0x3 << AC_AMPCAP_OFFSET_SHIFT) | + (0x4 << AC_AMPCAP_NUM_STEPS_SHIFT) | + (0x27 << AC_AMPCAP_STEP_SIZE_SHIFT) | + (0 << AC_AMPCAP_MUTE_SHIFT)); +} + /* ThinkPad X200 & co with cxt5051 */ static const struct hda_pintbl cxt_pincfg_lenovo_x200[] = { { 0x16, 0x042140ff }, /* HP (seq# overridden) */ @@ -4435,6 +4451,18 @@ static const struct hda_pintbl cxt_pincfg_lenovo_tp410[] = { {} }; +/* Lemote A1004/A1205 with cxt5066 */ +static const struct hda_pintbl cxt_pincfg_lemote[] = { + { 0x1a, 0x90a10020 }, /* Internal mic */ + { 0x1b, 0x03a11020 }, /* External mic */ + { 0x1d, 0x400101f0 }, /* Not used */ + { 0x1e, 0x40a701f0 }, /* Not used */ + { 0x20, 0x404501f0 }, /* Not used */ + { 0x22, 0x404401f0 }, /* Not used */ + { 0x23, 0x40a701f0 }, /* Not used */ + {} +}; + static const struct hda_fixup cxt_fixups[] = { [CXT_PINCFG_LENOVO_X200] = { .type = HDA_FIXUP_PINS, @@ -4444,10 +4472,24 @@ static const struct hda_fixup cxt_fixups[] = { .type = HDA_FIXUP_PINS, .v.pins = cxt_pincfg_lenovo_tp410, }, + [CXT_PINCFG_LEMOTE_A1004] = { + .type = HDA_FIXUP_PINS, + .chained = true, + .chain_id = CXT_FIXUP_INC_MIC_BOOST, + .v.pins = cxt_pincfg_lemote, + }, + [CXT_PINCFG_LEMOTE_A1205] = { + .type = HDA_FIXUP_PINS, + .v.pins = cxt_pincfg_lemote, + }, [CXT_FIXUP_STEREO_DMIC] = { .type = HDA_FIXUP_FUNC, .v.func = cxt_fixup_stereo_dmic, }, + [CXT_FIXUP_INC_MIC_BOOST] = { + .type = HDA_FIXUP_FUNC, + .v.func = cxt5066_increase_mic_boost, + }, }; static const struct snd_pci_quirk cxt5051_fixups[] = { @@ -4463,6 +4505,8 @@ static const struct snd_pci_quirk cxt5066_fixups[] = { SND_PCI_QUIRK(0x17aa, 0x21cf, "Lenovo T520", CXT_PINCFG_LENOVO_TP410), SND_PCI_QUIRK(0x17aa, 0x3975, "Lenovo U300s", CXT_FIXUP_STEREO_DMIC), SND_PCI_QUIRK(0x17aa, 0x397b, "Lenovo S205", CXT_FIXUP_STEREO_DMIC), + SND_PCI_QUIRK(0x1c06, 0x2011, "Lemote A1004", CXT_PINCFG_LEMOTE_A1004), + SND_PCI_QUIRK(0x1c06, 0x2012, "Lemote A1205", CXT_PINCFG_LEMOTE_A1205), {} }; -- 1.7.7.3

2 2

[alsa-devel] [PATCH] ASoC: codecs: da9055: Minor improvements
by Ashish Chavan 11 Oct '12

11 Oct '12

This patch includes two minor improvements for da9055 codec driver (1) Adding support for DSP mode of AIF (2) Muting Mic PGAs during ALC calibration process Signed-off-by: Ashish Chavan <ashish.chavan(a)kpitcummins.com> Signed-off-by: David Dajun Chen <david.chen(a)diasemi.com> --- sound/soc/codecs/da9055.c | 26 +++++++++++++++++++++++++- 1 files changed, 25 insertions(+), 1 deletions(-) diff --git a/sound/soc/codecs/da9055.c b/sound/soc/codecs/da9055.c index 185d8dd..abf3e43 100644 --- a/sound/soc/codecs/da9055.c +++ b/sound/soc/codecs/da9055.c @@ -173,11 +173,18 @@ #define DA9055_AIF_FORMAT_I2S_MODE (0 << 0) #define DA9055_AIF_FORMAT_LEFT_J (1 << 0) #define DA9055_AIF_FORMAT_RIGHT_J (2 << 0) +#define DA9055_AIF_FORMAT_DSP (3 << 0) #define DA9055_AIF_WORD_S16_LE (0 << 2) #define DA9055_AIF_WORD_S20_3LE (1 << 2) #define DA9055_AIF_WORD_S24_LE (2 << 2) #define DA9055_AIF_WORD_S32_LE (3 << 2) +/* MIC_L_CTRL bit fields */ +#define DA9055_MIC_L_MUTE_EN (1 << 6) + +/* MIC_R_CTRL bit fields */ +#define DA9055_MIC_R_MUTE_EN (1 << 6) + /* MIXIN_L_CTRL bit fields */ #define DA9055_MIXIN_L_MIX_EN (1 << 3) @@ -476,7 +483,7 @@ static int da9055_put_alc_sw(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol); - u8 reg_val, adc_left, adc_right; + u8 reg_val, adc_left, adc_right, mic_left, mic_right; int avg_left_data, avg_right_data, offset_l, offset_r; if (ucontrol->value.integer.value[0]) { @@ -485,6 +492,16 @@ static int da9055_put_alc_sw(struct snd_kcontrol *kcontrol, * offsets must be done first */ + /* Save current values from Mic control registers */ + mic_left = snd_soc_read(codec, DA9055_MIC_L_CTRL); + mic_right = snd_soc_read(codec, DA9055_MIC_R_CTRL); + + /* Mute Mic PGA Left and Right */ + snd_soc_update_bits(codec, DA9055_MIC_L_CTRL, + DA9055_MIC_L_MUTE_EN, DA9055_MIC_L_MUTE_EN); + snd_soc_update_bits(codec, DA9055_MIC_R_CTRL, + DA9055_MIC_R_MUTE_EN, DA9055_MIC_R_MUTE_EN); + /* Save current values from ADC control registers */ adc_left = snd_soc_read(codec, DA9055_ADC_L_CTRL); adc_right = snd_soc_read(codec, DA9055_ADC_R_CTRL); @@ -520,6 +537,10 @@ static int da9055_put_alc_sw(struct snd_kcontrol *kcontrol, /* Restore original values of ADC control registers */ snd_soc_write(codec, DA9055_ADC_L_CTRL, adc_left); snd_soc_write(codec, DA9055_ADC_R_CTRL, adc_right); + + /* Restore original values of Mic control registers */ + snd_soc_write(codec, DA9055_MIC_L_CTRL, mic_left); + snd_soc_write(codec, DA9055_MIC_R_CTRL, mic_right); } return snd_soc_put_volsw(kcontrol, ucontrol); @@ -1155,6 +1176,9 @@ static int da9055_set_dai_fmt(struct snd_soc_dai *codec_dai, unsigned int fmt) case SND_SOC_DAIFMT_RIGHT_J: aif_ctrl = DA9055_AIF_FORMAT_RIGHT_J; break; + case SND_SOC_DAIFMT_DSP_A: + aif_ctrl = DA9055_AIF_FORMAT_DSP; + break; default: return -EINVAL; } -- 1.7.1

2 1

[alsa-devel] Bug 48381 - [Regression][Bisected]Sound gets permanently muted a few minutes after booting
by Da Fox 10 Oct '12

10 Oct '12

Hi all, Since the official bug-tracker at https://bugtrack.alsa-project.org/alsa-bug/ seems to be down (and moreover this appears to be a kernel bug), I have filed a bug at the kernel's bug-tracker last week ( https://bugzilla.kernel.org/show_bug.cgi?id=48381 ). However, it seems to have gone unnoticed thus-far. Quick summary of the issue: After a while of inactivity the sound-card seems to go into a sort of power-saving mode (you can hear a faint 'pop' from the speakers). Before the sound would automatically turn back on again as soon as a program attempted to play sound. However now it seems that after resuming from the power-saving mode the driver thinks that there is always a headphone connected, even when it is not. I think this is what happens because toggling the 'Auto-Mute Mode' (setting it to 'Disabled') in alsamixer allows the speakers to produce sound again. This is all on a laptop (please see the linked bug report for more detailed hardware description). Would a developer please take a look at it? I have bisected the issue down to a commit made by David Henningsson and/or Takashi Iwai: ---8<--------- 80c8bfbe76869bfd6bdf3d260d316e7a32f318c3 is the first bad commit commit 80c8bfbe76869bfd6bdf3d260d316e7a32f318c3 Author: David Henningsson <david.henningsson(a)canonical.com> Date: Mon Jun 4 09:33:51 2012 +0200 ALSA: HDA: Create phantom jacks for fixed inputs and outputs PulseAudio sometimes have difficulties knowing that there is a "Speaker" or "Internal Mic", if they have no individual volume controls or selectors. As a result, only e g "Headphone" might be created for a laptop, but no "Speaker". To help out, create phantom jacks (that are always present, at least for now) for "Speaker", "Internal Mic" etc, in case we detect them. The naming convention is e g "Speaker Phantom Jack". In order not to pollute the /dev/input namespace with even more devices, these are added to the kcontrols only, not the input devices. Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> :040000 040000 7a954b731bef80cee731763521f64a424a7058a0 7d176b02ebb4553b0b0f97d200f7527cb69c122a M sound --->8--------- If any additional information is required please let me know. Best regards, Da Fox

3 6

[alsa-devel] ASoC: special SPI format for that5173 driver in daisy chain mode
by Christian Schörkhuber 10 Oct '12

10 Oct '12

Hi all, I'm working on an ASoC driver for the THAT5173 microphone preamplifier which is controlled via SPI. When operating in daisy chain mode (4 amps) the desired format is a bit odd: I need to write four 16 bit spi commands (one gain setting for each amp) in a row without raising the chipselect line between commands. That is, I need to write one 64 bit SPI command that is composed of 4 different values (and 4 register addresses which are all 0). Usually I use regmap but I don't see how I can construct such a message with regmap. How can this be done (with or without regmap)? Thanks, Chris

1 0

[alsa-devel] [PATCH] ASoC: fsl/pcm030 add unique dai_link names
by Eric Millbrandt 10 Oct '12

10 Oct '12

From: Eric Millbrandt <emillbrandt(a)dekaresearch.com Assign each dai_link a unique name to avoid this run-time error. [ 18.978043] pcm030-audio-fabric sound.2: wm9712-hifi <-> mpc5200-psc-ac97.0 mapping ok [ 19.003179] sysfs: cannot create duplicate filename '/devices/sound.2/AC97' Signed-off-by: Eric Millbrandt <emillbrandt(a)dekaresearch.com> --- sound/soc/fsl/pcm030-audio-fabric.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/fsl/pcm030-audio-fabric.c b/sound/soc/fsl/pcm030-audio-fabric.c index 4b63ec8..4d26192 100644 --- a/sound/soc/fsl/pcm030-audio-fabric.c +++ b/sound/soc/fsl/pcm030-audio-fabric.c @@ -29,14 +29,14 @@ struct pcm030_audio_data { static struct snd_soc_dai_link pcm030_fabric_dai[] = { { - .name = "AC97", + .name = "AC97.0", .stream_name = "AC97 Analog", .codec_dai_name = "wm9712-hifi", .cpu_dai_name = "mpc5200-psc-ac97.0", .codec_name = "wm9712-codec", }, { - .name = "AC97", + .name = "AC97.1", .stream_name = "AC97 IEC958", .codec_dai_name = "wm9712-aux", .cpu_dai_name = "mpc5200-psc-ac97.1", -- 1.7.8

1 1

[alsa-devel] [PATCH] ALSA: ASoC: davinci-pcm: stub out gen_pool functions for !CONFIG_GENERIC_ALLOCATOR
by Daniel Mack 10 Oct '12

10 Oct '12

On platforms without CONFIG_GENERIC_ALLOCATOR, these functions can be no-ops. The code that uses the memory buffers does the right thing if they are NULL. Signed-off-by: Daniel Mack <zonque(a)gmail.com> Cc: Hebbar, Gururaja <gururaja.hebbar(a)ti.com> Cc: Matt Porter <mporter(a)ti.com> Cc: Anil Kumar <anilkumar.v(a)ti.com> --- Alternatively, the gen_pool functions could stub out themselves for !CONFIG_GENERIC_ALLOCATOR. sound/soc/davinci/davinci-pcm.c | 29 ++++++++++++++++++++++++----- 1 file changed, 24 insertions(+), 5 deletions(-) diff --git a/sound/soc/davinci/davinci-pcm.c b/sound/soc/davinci/davinci-pcm.c index 01b3f17..afab81f 100644 --- a/sound/soc/davinci/davinci-pcm.c +++ b/sound/soc/davinci/davinci-pcm.c @@ -251,6 +251,7 @@ static void davinci_pcm_dma_irq(unsigned link, u16 ch_status, void *data) } } +#ifdef CONFIG_GENERIC_ALLOCATOR static int allocate_sram(struct snd_pcm_substream *substream, struct gen_pool *sram_pool, unsigned size, struct snd_pcm_hardware *ppcm) @@ -284,6 +285,28 @@ exit1: return -ENOMEM; } +static void davinci_free_sram(struct snd_pcm_substream *substream, + struct snd_dma_buffer *iram_dma) +{ + struct davinci_runtime_data *prtd = substream->runtime->private_data; + struct gen_pool *sram_pool = prtd->params->sram_pool; + + gen_pool_free(sram_pool, (unsigned) iram_dma->area, iram_dma->bytes); +} +#else +static int allocate_sram(struct snd_pcm_substream *substream, + struct gen_pool *sram_pool, unsigned size, + struct snd_pcm_hardware *ppcm) +{ + return 0; +} + +static void davinci_free_sram(struct snd_pcm_substream *substream, + struct snd_dma_buffer *iram_dma) +{ +} +#endif + /* * Only used with ping/pong. * This is called after runtime->dma_addr, period_bytes and data_type are valid @@ -813,11 +836,7 @@ static void davinci_pcm_free(struct snd_pcm *pcm) buf->area = NULL; iram_dma = buf->private_data; if (iram_dma) { - struct davinci_runtime_data *prtd = - substream->runtime->private_data; - struct gen_pool *sram_pool = prtd->params->sram_pool; - gen_pool_free(sram_pool, (unsigned)iram_dma->area, - iram_dma->bytes); + davinci_free_sram(substream, iram_dma); kfree(iram_dma); } } -- 1.7.11.4

1 1

[alsa-devel] [PATCH] ASoC: wm8958: Load firmwares simultaneously
by Mark Brown 10 Oct '12

10 Oct '12

As of commit 99c2aa (firmware loader: fix creation failure of fw loader device) we can have more than one firmware request outstanding at once so there is no need to daisychain our requests any more. Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8958-dsp2.c | 31 +++++++++++-------------------- 1 file changed, 11 insertions(+), 20 deletions(-) diff --git a/sound/soc/codecs/wm8958-dsp2.c b/sound/soc/codecs/wm8958-dsp2.c index 2f191a0..b0710d8 100644 --- a/sound/soc/codecs/wm8958-dsp2.c +++ b/sound/soc/codecs/wm8958-dsp2.c @@ -883,13 +883,6 @@ static void wm8958_mbc_vss_loaded(const struct firmware *fw, void *context) wm8994->mbc_vss = fw; mutex_unlock(&codec->mutex); } - - /* We can't have more than one request outstanding at once so - * we daisy chain. - */ - request_firmware_nowait(THIS_MODULE, FW_ACTION_HOTPLUG, - "wm8958_enh_eq.wfw", codec->dev, GFP_KERNEL, - codec, wm8958_enh_eq_loaded); } static void wm8958_mbc_loaded(const struct firmware *fw, void *context) @@ -897,19 +890,11 @@ static void wm8958_mbc_loaded(const struct firmware *fw, void *context) struct snd_soc_codec *codec = context; struct wm8994_priv *wm8994 = snd_soc_codec_get_drvdata(codec); - if (wm8958_dsp2_fw(codec, "MBC", fw, true) != 0) - return; - - mutex_lock(&codec->mutex); - wm8994->mbc = fw; - mutex_unlock(&codec->mutex); - - /* We can't have more than one request outstanding at once so - * we daisy chain. - */ - request_firmware_nowait(THIS_MODULE, FW_ACTION_HOTPLUG, - "wm8958_mbc_vss.wfw", codec->dev, GFP_KERNEL, - codec, wm8958_mbc_vss_loaded); + if (fw && (wm8958_dsp2_fw(codec, "MBC", fw, true) == 0)) { + mutex_lock(&codec->mutex); + wm8994->mbc = fw; + mutex_unlock(&codec->mutex); + } } void wm8958_dsp2_init(struct snd_soc_codec *codec) @@ -933,6 +918,12 @@ void wm8958_dsp2_init(struct snd_soc_codec *codec) request_firmware_nowait(THIS_MODULE, FW_ACTION_HOTPLUG, "wm8958_mbc.wfw", codec->dev, GFP_KERNEL, codec, wm8958_mbc_loaded); + request_firmware_nowait(THIS_MODULE, FW_ACTION_HOTPLUG, + "wm8958_mbc_vss.wfw", codec->dev, GFP_KERNEL, + codec, wm8958_mbc_vss_loaded); + request_firmware_nowait(THIS_MODULE, FW_ACTION_HOTPLUG, + "wm8958_enh_eq.wfw", codec->dev, GFP_KERNEL, + codec, wm8958_enh_eq_loaded); if (pdata->num_mbc_cfgs) { struct snd_kcontrol_new control[] = { -- 1.7.10.4

1 0

[alsa-devel] [PATCH] ASoC: wm8750: Convert to direct regmap API usage
by Mark Brown 10 Oct '12

10 Oct '12

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/wm8750.c | 86 ++++++++++++++++++++++++++++++++++----------- 1 file changed, 66 insertions(+), 20 deletions(-) diff --git a/sound/soc/codecs/wm8750.c b/sound/soc/codecs/wm8750.c index 89151ca..7665d68 100644 --- a/sound/soc/codecs/wm8750.c +++ b/sound/soc/codecs/wm8750.c @@ -18,6 +18,7 @@ #include <linux/delay.h> #include <linux/pm.h> #include <linux/i2c.h> +#include <linux/regmap.h> #include <linux/spi/spi.h> #include <linux/slab.h> #include <linux/of_device.h> @@ -34,24 +35,55 @@ * We can't read the WM8750 register space when we * are using 2 wire for device control, so we cache them instead. */ -static const u16 wm8750_reg[] = { - 0x0097, 0x0097, 0x0079, 0x0079, /* 0 */ - 0x0000, 0x0008, 0x0000, 0x000a, /* 4 */ - 0x0000, 0x0000, 0x00ff, 0x00ff, /* 8 */ - 0x000f, 0x000f, 0x0000, 0x0000, /* 12 */ - 0x0000, 0x007b, 0x0000, 0x0032, /* 16 */ - 0x0000, 0x00c3, 0x00c3, 0x00c0, /* 20 */ - 0x0000, 0x0000, 0x0000, 0x0000, /* 24 */ - 0x0000, 0x0000, 0x0000, 0x0000, /* 28 */ - 0x0000, 0x0000, 0x0050, 0x0050, /* 32 */ - 0x0050, 0x0050, 0x0050, 0x0050, /* 36 */ - 0x0079, 0x0079, 0x0079, /* 40 */ +static const struct reg_default wm8750_reg_defaults[] = { + { 0, 0x0097 }, + { 1, 0x0097 }, + { 2, 0x0079 }, + { 3, 0x0079 }, + { 4, 0x0000 }, + { 5, 0x0008 }, + { 6, 0x0000 }, + { 7, 0x000a }, + { 8, 0x0000 }, + { 9, 0x0000 }, + { 10, 0x00ff }, + { 11, 0x00ff }, + { 12, 0x000f }, + { 13, 0x000f }, + { 14, 0x0000 }, + { 15, 0x0000 }, + { 16, 0x0000 }, + { 17, 0x007b }, + { 18, 0x0000 }, + { 19, 0x0032 }, + { 20, 0x0000 }, + { 21, 0x00c3 }, + { 22, 0x00c3 }, + { 23, 0x00c0 }, + { 24, 0x0000 }, + { 25, 0x0000 }, + { 26, 0x0000 }, + { 27, 0x0000 }, + { 28, 0x0000 }, + { 29, 0x0000 }, + { 30, 0x0000 }, + { 31, 0x0000 }, + { 32, 0x0000 }, + { 33, 0x0000 }, + { 34, 0x0050 }, + { 35, 0x0050 }, + { 36, 0x0050 }, + { 37, 0x0050 }, + { 38, 0x0050 }, + { 39, 0x0050 }, + { 40, 0x0079 }, + { 41, 0x0079 }, + { 42, 0x0079 }, }; /* codec private data */ struct wm8750_priv { unsigned int sysclk; - enum snd_soc_control_type control_type; }; #define wm8750_reset(c) snd_soc_write(c, WM8750_RESET, 0) @@ -668,10 +700,9 @@ static int wm8750_resume(struct snd_soc_codec *codec) static int wm8750_probe(struct snd_soc_codec *codec) { - struct wm8750_priv *wm8750 = snd_soc_codec_get_drvdata(codec); int ret; - ret = snd_soc_codec_set_cache_io(codec, 7, 9, wm8750->control_type); + ret = snd_soc_codec_set_cache_io(codec, 7, 9, SND_SOC_REGMAP); if (ret < 0) { printk(KERN_ERR "wm8750: failed to set cache I/O: %d\n", ret); return ret; @@ -711,9 +742,6 @@ static struct snd_soc_codec_driver soc_codec_dev_wm8750 = { .suspend = wm8750_suspend, .resume = wm8750_resume, .set_bias_level = wm8750_set_bias_level, - .reg_cache_size = ARRAY_SIZE(wm8750_reg), - .reg_word_size = sizeof(u16), - .reg_cache_default = wm8750_reg, .controls = wm8750_snd_controls, .num_controls = ARRAY_SIZE(wm8750_snd_controls), @@ -730,10 +758,21 @@ static const struct of_device_id wm8750_of_match[] = { }; MODULE_DEVICE_TABLE(of, wm8750_of_match); +static const struct regmap_config wm8750_regmap = { + .reg_bits = 7, + .val_bits = 9, + .max_register = WM8750_MOUTV, + + .reg_defaults = wm8750_reg_defaults, + .num_reg_defaults = ARRAY_SIZE(wm8750_reg_defaults), + .cache_type = REGCACHE_RBTREE, +}; + #if defined(CONFIG_SPI_MASTER) static int __devinit wm8750_spi_probe(struct spi_device *spi) { struct wm8750_priv *wm8750; + struct regmap *regmap; int ret; wm8750 = devm_kzalloc(&spi->dev, sizeof(struct wm8750_priv), @@ -741,7 +780,10 @@ static int __devinit wm8750_spi_probe(struct spi_device *spi) if (wm8750 == NULL) return -ENOMEM; - wm8750->control_type = SND_SOC_SPI; + regmap = devm_regmap_init_spi(spi, &wm8750_regmap); + if (IS_ERR(regmap)) + return PTR_ERR(regmap); + spi_set_drvdata(spi, wm8750); ret = snd_soc_register_codec(&spi->dev, @@ -779,6 +821,7 @@ static __devinit int wm8750_i2c_probe(struct i2c_client *i2c, const struct i2c_device_id *id) { struct wm8750_priv *wm8750; + struct regmap *regmap; int ret; wm8750 = devm_kzalloc(&i2c->dev, sizeof(struct wm8750_priv), @@ -787,7 +830,10 @@ static __devinit int wm8750_i2c_probe(struct i2c_client *i2c, return -ENOMEM; i2c_set_clientdata(i2c, wm8750); - wm8750->control_type = SND_SOC_I2C; + + regmap = devm_regmap_init_i2c(i2c, &wm8750_regmap); + if (IS_ERR(regmap)) + return PTR_ERR(regmap); ret = snd_soc_register_codec(&i2c->dev, &soc_codec_dev_wm8750, &wm8750_dai, 1); -- 1.7.10.4

1 0