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

[alsa-devel] [PATCH] ASoC: codecs/wm8978: Remove remuxing of GPIO1 pin
by Eric Millbrandt 16 Nov '12

16 Nov '12

Remove remuxing GPIO1. Leave control of this up to the platform device. Signed-off-by: Eric Millbrandt <emillbrandt(a)dekaresearch.com> --- sound/soc/codecs/wm8978.c | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-) diff --git a/sound/soc/codecs/wm8978.c b/sound/soc/codecs/wm8978.c index e329187..2fcc6da 100644 --- a/sound/soc/codecs/wm8978.c +++ b/sound/soc/codecs/wm8978.c @@ -529,9 +529,6 @@ static int wm8978_configure_pll(struct snd_soc_codec *codec) return idx; wm8978->mclk_idx = idx; - - /* GPIO1 into default mode as input - before configuring PLL */ - snd_soc_update_bits(codec, WM8978_GPIO_CONTROL, 7, 0); } else { return -EINVAL; } -- 1.7.2.5

2 1

[alsa-devel] [PATCH v2] ASoC: bells: Up to 512fs
by Dimitris Papastamos 16 Nov '12

16 Nov '12

Optimize performance by providing a 512fs based clkin. Signed-off-by: Dimitris Papastamos <dp(a)opensource.wolfsonmicro.com> --- sound/soc/samsung/bells.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/samsung/bells.c b/sound/soc/samsung/bells.c index 3d7ace7..b5065ee 100644 --- a/sound/soc/samsung/bells.c +++ b/sound/soc/samsung/bells.c @@ -28,7 +28,7 @@ #define MCLK_RATE 24576000 #define SYS_AUDIO_RATE 44100 -#define SYS_MCLK_RATE (SYS_AUDIO_RATE * 256) +#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] ASoC: arizona: Fix typo - Swap value in 48k_rates[] and 44k1_rates[]
by Dimitris Papastamos 16 Nov '12

16 Nov '12

Signed-off-by: Dimitris Papastamos <dp(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/arizona.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c index c03b65a..054967d 100644 --- a/sound/soc/codecs/arizona.c +++ b/sound/soc/codecs/arizona.c @@ -268,7 +268,7 @@ EXPORT_SYMBOL_GPL(arizona_out_ev); static unsigned int arizona_sysclk_48k_rates[] = { 6144000, 12288000, - 22579200, + 24576000, 49152000, 73728000, 98304000, @@ -278,7 +278,7 @@ static unsigned int arizona_sysclk_48k_rates[] = { static unsigned int arizona_sysclk_44k1_rates[] = { 5644800, 11289600, - 24576000, + 22579200, 45158400, 67737600, 90316800, -- 1.8.0

2 1

[alsa-devel] [PATCH] ASoC: bells: Fix up git patch application failure
by Mark Brown 16 Nov '12

16 Nov '12

It seems git has been getting confused by the very similar contexts for the speaker DAIs and has been applying patches to the wrong places causing all sorts of confusion. Fix this up by hand. Reported-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> Signed-off-by: Mark Brown <broonie(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 b56b9a3..a2ca156 100644 --- a/sound/soc/samsung/bells.c +++ b/sound/soc/samsung/bells.c @@ -212,7 +212,7 @@ static struct snd_soc_dai_link bells_dai_wm5102[] = { { .name = "Sub", .stream_name = "Sub", - .cpu_dai_name = "wm5110-aif3", + .cpu_dai_name = "wm5102-aif3", .codec_dai_name = "wm9081-hifi", .codec_name = "wm9081.1-006c", .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF @@ -247,7 +247,7 @@ static struct snd_soc_dai_link bells_dai_wm5110[] = { { .name = "Sub", .stream_name = "Sub", - .cpu_dai_name = "wm5102-aif3", + .cpu_dai_name = "wm5110-aif3", .codec_dai_name = "wm9081-hifi", .codec_name = "wm9081.1-006c", .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF -- 1.7.10.4

1 0

[alsa-devel] [PATCH] ASoC: codecs/wm8978: Only reconfigure GPIO1 when used for PLL output
by Eric Millbrandt 15 Nov '12

15 Nov '12

When GPIO1 is used for other purposes than PLL output (GPIO, Amute, etc) the driver incorrectly reconfigures the pin to input when the PLL is recalculated. Only reconfigure the pin for input when reconfiguring the PLL and GPIO1 is used for PLL output. Signed-off-by: Eric Millbrandt <emillbrandt(a)dekaresearch.com> --- sound/soc/codecs/wm8978.c | 17 +++++++++++------ 1 files changed, 11 insertions(+), 6 deletions(-) diff --git a/sound/soc/codecs/wm8978.c b/sound/soc/codecs/wm8978.c index a706262..0659b41 100644 --- a/sound/soc/codecs/wm8978.c +++ b/sound/soc/codecs/wm8978.c @@ -509,7 +509,11 @@ static int wm8978_configure_pll(struct snd_soc_codec *codec) dev_dbg(codec->dev, "%s: OPCLKDIV=%d\n", __func__, opclk_div); - snd_soc_update_bits(codec, WM8978_GPIO_CONTROL, 0x30, + /* + * GPIO1 is used for OPCLK, reconfigure into default + * mode as input - before configuring OPCLKDIV and PLL + */ + snd_soc_update_bits(codec, WM8978_GPIO_CONTROL, 0x37, (opclk_div - 1) << 4); wm8978->f_pllout = f_opclk * opclk_div; @@ -529,9 +533,6 @@ static int wm8978_configure_pll(struct snd_soc_codec *codec) return idx; wm8978->mclk_idx = idx; - - /* GPIO1 into default mode as input - before configuring PLL */ - snd_soc_update_bits(codec, WM8978_GPIO_CONTROL, 7, 0); } else { return -EINVAL; } @@ -638,8 +639,12 @@ static int wm8978_set_dai_sysclk(struct snd_soc_dai *codec_dai, int clk_id, /* Clock CODEC directly from MCLK */ snd_soc_update_bits(codec, WM8978_CLOCKING, 0x100, 0); - /* GPIO1 into default mode as input - before configuring PLL */ - snd_soc_update_bits(codec, WM8978_GPIO_CONTROL, 7, 0); + /* + * If GPIO1 is used for OPCLK, reconfigure GPIO1 into default + * mode as input - before configuring PLL + */ + if (f_opclk) + snd_soc_update_bits(codec, WM8978_GPIO_CONTROL, 7, 0); /* Turn off PLL */ snd_soc_update_bits(codec, WM8978_POWER_MANAGEMENT_1, 0x20, 0); -- 1.7.2.5

2 4

[alsa-devel] Can't connect to MIDI output of Edirol UA-1000
by Colin Fletcher 15 Nov '12

15 Nov '12

Hello all, I hope this is the right place to report this and ask for help: if not, I'd be glad of a pointers to any more appropriate forum. I've just recently noticed that connections to the MIDI output of my Edirol UA-1000 fail when using the snd_ua101 driver in recent kernels. Although the port is listed, connections to it fail from all the software I've tried: qjackctl, a2jmidid and aconnect all fail to connect. aconnect simply reports "Connection failed (Input/output error)"; a2jmidid -e says "ERROR: a2j_port_create: snd_seq_connect_to() for 20:0 failed with error -5"; and qjackctl reports no error but refuses to make the connection. I've observed the problem in stable kernels 3.0.39 and 3.4.11; it works as expected when booted into a 2.6.32 kernel, where the snd_usb_audio driver is used for the UA-1000. Other USB MIDI devices appear to work fine with the newer kernels. Incidentally, I also noticed that the 'Control' MIDI in & out of the UA-1000 no longer appear when using snd_ua101, but I don't think this is related, since changing the values of midi_ep.out_cables and midi_ep.in_cables to 3 in the ua101_probe() function in sound/usb/misc/ua101.c brings the control in & out back, but I'm still unable to connect the outputs. Any help, suggestions, patches or requests for more details gratefully received! Thank you, Colin Fletcher.

3 7

[alsa-devel] Request regarding driver development
by Ralf Mardorf 15 Nov '12

15 Nov '12

Hi :), I correspond with RME, because I've got issues with my RME HDSPe AIO. They're very friendly and asked me to check the status of the driver development. Is somebody working on that driver? If so, is information missing to write the driver? More about the issues: http://www.rme-audio.de/forum/viewtopic.php?id=16092 http://sourceforge.net/mailarchive/forum.php?thread_name=20121108143549.689… I'll keep subscribed to this list for the next weeks, otherwise I'm subscribed to ALSA users and I won't unsubscribe there. Regards, Ralf

1 0

[alsa-devel] [PATCH] ASoC: bells: Up to 512fs
by Dimitris Papastamos 15 Nov '12

15 Nov '12

Optimize performance by providing a 512fs based clkin. Change-Id: Ied1f59ebaa4469aac41c97ae3000a4af9c653518 Signed-off-by: Dimitris Papastamos <dp(a)opensource.wolfsonmicro.com> --- sound/soc/samsung/bells.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/samsung/bells.c b/sound/soc/samsung/bells.c index 3d7ace7..b5065ee 100644 --- a/sound/soc/samsung/bells.c +++ b/sound/soc/samsung/bells.c @@ -28,7 +28,7 @@ #define MCLK_RATE 24576000 #define SYS_AUDIO_RATE 44100 -#define SYS_MCLK_RATE (SYS_AUDIO_RATE * 256) +#define SYS_MCLK_RATE (SYS_AUDIO_RATE * 512) #define DAI_AP_DSP 0 #define DAI_DSP_CODEC 1 -- 1.8.0

1 0

Re: [alsa-devel] Races in alsa-lib with threads
by Takashi Iwai 15 Nov '12

15 Nov '12

At Tue, 13 Nov 2012 13:39:24 +0000, Krakora Robert-B42341 wrote: > > [1 <text/plain; us-ascii (quoted-printable)>] > > From: Takashi Iwai [tiwai(a)suse.de] > > Sent: Tuesday, November 13, 2012 2:30 AM > > To: Trent Piepho > > Cc: Krakora Robert-B42341; alsa-devel(a)alsa-project.org > > Subject: Re: [alsa-devel] Races in alsa-lib with threads > > > > At Tue, 13 Nov 2012 02:14:08 -0500, > > Trent Piepho wrote: > > > > > > On Tue, Nov 13, 2012 at 1:32 AM, Takashi Iwai <tiwai(a)suse.de> wrote: > > > > At Mon, 12 Nov 2012 19:40:42 +0000 (UTC), > > > > Rob Krakora wrote: > > > >> Would you be able to point me the the ALSA documentation that indicates the > > > >> stipulations on handle usage using multiple threads? I cannot find it. > > > > > > > > Think other way round: > > > > The fact that it isn't documented means it's not safe to use in that > > > > way :) > > > > > > > > > The introduction on the alsa-project home page says, "SMP and > > > thread-safe design. " Some people might misunderstand what > > > thread-safe means. Maybe some clarification could be added. > > > "Different streams are SMP and thread-safe (calls for the same stream > > > must be serialized)." > > > > Yeah this should be corrected. SMP things are just about the kernel > > side at that time. > > > > It's a Wiki, feel free to correct / improve the text. > > > > > > Takashi > > Hi Takashi, > > The way that the GStreamer ALSA Sink Plugin is using ALSA Lib assumes that it is thread safe. The fix crafted by one of Trent's colleagues (attached) seems to be the way to go. However, I don't know how it would impact other functionality within ALSA Lib. No, sorry, we don't want to introduce pthread_lock in alsa-lib PCM stuff. We already have a few places, yes, but they are exceptional (mostly for funky rarely used plugins that we can drop or mixer codes that are no hot path). Takashi

7 23

Re: [alsa-devel] [PATCH 1/1] media: Entities with sink pads must have at least one enabled link
by Laurent Pinchart 15 Nov '12

15 Nov '12

Hi Sakari, On Wednesday 14 November 2012 23:13:45 Sakari Ailus wrote: > On Wed, Nov 14, 2012 at 10:23:19AM +0100, Sylwester Nawrocki wrote: > > On 11/13/2012 03:24 PM, Sakari Ailus wrote: > > > Hi all, > > > > > > Comments would be appreciated, either positive or negative. The omap3isp > > > driver does the same check itself currently, but I think this is more > > > generic than that. > > > > > > Thanks. > > > > > > On Fri, Oct 26, 2012 at 10:46:17PM +0300, Sakari Ailus wrote: > > >> If an entity has sink pads, at least one of them must be connected to > > >> another pad with an enabled link. If a driver with multiple sink pads > > >> has more strict requirements the check should be done in the driver > > >> itself. > > >> > > >> Just requiring one sink pad is connected with an enabled link is enough > > >> API-wise: entities with sink pads with only disabled links should not > > >> be allowed to stream in the first place, but also in a different > > >> operation mode a device might require only one of its pads connected > > >> with an active link. > > >> > > >> If an entity has an ability to function as a source entity another > > >> logical entity connected to the aforementioned one should be used for > > >> the purpose. > > > > Why not leave it to individual drivers ? I'm not sure if it is a good idea > > not to allow an entity with sink pads to be used as a source only. It > > might be appropriate for most of the cases but likely not all. I'm > > inclined not to add this requirement in the API. Just my opinion though. > > I'm just wondering what would be the use case for that. > > What comes closest is generating a test pattern, but even that should be a > separate subdev: the test pattern can be enabled by enabling the link from > the test pattern generator subdev. That would force creating a separate subdev just to support test pattern generation, I'm not sure if I want to push for that. There might also be other use cases not related to V4L (thus the cross-posting). > As it seems not everyone is outright happy about the idea of making this > mandatory, then how about making it optional? > > I'd hate having a link validate function for each subdev e.g. in the OMAP 3 > ISP driver that just checks that its sink pad is actually connected with an > enabled link. That'd be lots of mostly useless code. Agreed. > If this is done in the framework, the drivers will be spared from copying > this code in a number of places. Which was why I originally wrote this > patch. The alternative is to re-parse the whole graph in the driver which > I'd also like to avoid. I'd also prefer to avoid that *if*possible*, as we already walk the graph during link validation. > One opion I can think of is to call link_validate op of struct > media_entity_operations also for disabled links on entities that are > connected through active links (on V4L2 to a video node right before > streaming, for example). > > That'd make it easy to perform the check in the drivers. > > What do you think? I think that would be a bit too complex. Drivers (or the V4L core) would need to gather data from multiple links in some state object to find out if the complete pipeline is valid or not. Another option would be to set a flag somewhere to indicate whether the check should be performed by the media core or left to drivers. As different types of drivers might need different types of checks, I think I would prefer for now to walk the graph one more time in the OMAP3 ISP driver, as currently done, and revisit this issue when we will have a couple of drivers implementing pipeline validity checks. I'm just a bit uncomfortable adding core code for a feature that has a single user at the moment without a clear view regarding how it would scale. -- Regards, Laurent Pinchart

1 0

[alsa-devel] snd_device_name_hint: Inconsistent output
by Peter Grasch 15 Nov '12

15 Nov '12

Hi! Today, I noticed that some devices (specifically, the "pulse" device, but there might be others as well) do not show up in a call to snd_device_name_hint when it is called for the first time within an application. I've managed to reproduce the problem on three different systems: Get the source of a current version of aplay, compile it, run aplay -L and store the output. Then add another call to snd_device_name_hint in pcm_list to make it look like this (leaking memory, but it doesn't matter for this demonstration): 315 static void pcm_list(void) 316 { 317 void **hints, **n; 318 char *name, *descr, *descr1, *io; 319 const char *filter; 320 321 snd_device_name_hint(-1, "pcm", &hints); 322 if (snd_device_name_hint(-1, "pcm", &hints) < 0) 323 return; Compile and run this version of aplay and again store the output of "aplay -L". For me, the two outputs differ. Please net me know how I can help to resolve this issue. Thanks. Best regards, Peter

1 0

[alsa-devel] [patch] ALSA: es1968: precedence bug in snd_es1968_tea575x_get_pins()
by Dan Carpenter 14 Nov '12

14 Nov '12

I don't think this works as intended. '|' higher precedence than ?: so the bitwize OR "0 | (val & STR_MOST)" is a no-op. I have re-written it to be more clear. Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> --- I don't have a way to test this. diff --git a/sound/pci/es1968.c b/sound/pci/es1968.c index 50169bc..7266020 100644 --- a/sound/pci/es1968.c +++ b/sound/pci/es1968.c @@ -2581,9 +2581,14 @@ static u8 snd_es1968_tea575x_get_pins(struct snd_tea575x *tea) struct es1968 *chip = tea->private_data; unsigned long io = chip->io_port + GPIO_DATA; u16 val = inw(io); - - return (val & STR_DATA) ? TEA575X_DATA : 0 | - (val & STR_MOST) ? TEA575X_MOST : 0; + u8 ret; + + ret = 0; + if (val & STR_DATA) + ret |= TEA575X_DATA; + if (val & STR_MOST) + ret |= TEA575X_MOST; + return ret; } static void snd_es1968_tea575x_set_direction(struct snd_tea575x *tea, bool output)

4 4

[alsa-devel] [PATCH] ALSA: ASoC: ak4104: add reset line property to DT bindings
by Daniel Mack 14 Nov '12

14 Nov '12

This device doesn't have a pdata definition for legacy boards, and unless anyone need to control the reset GPIO, it's not worth adding one. So this feature is only available to DT users for now. Signed-off-by: Daniel Mack <zonque(a)gmail.com> --- Documentation/devicetree/bindings/sound/ak4104.txt | 5 +++++ sound/soc/codecs/ak4104.c | 17 +++++++++++++++++ 2 files changed, 22 insertions(+) diff --git a/Documentation/devicetree/bindings/sound/ak4104.txt b/Documentation/devicetree/bindings/sound/ak4104.txt index 1f8e506..b902ee3 100644 --- a/Documentation/devicetree/bindings/sound/ak4104.txt +++ b/Documentation/devicetree/bindings/sound/ak4104.txt @@ -8,6 +8,11 @@ Required properties: - reg : The chip select number on the SPI bus +Optional properties: + + - reset-gpio : a GPIO spec for the reset pin. If specified, it will be + deasserted before communication to the device starts. + Example: spdif: ak4104@0 { diff --git a/sound/soc/codecs/ak4104.c b/sound/soc/codecs/ak4104.c index d4d4858..eec086b 100644 --- a/sound/soc/codecs/ak4104.c +++ b/sound/soc/codecs/ak4104.c @@ -15,6 +15,8 @@ #include <sound/soc.h> #include <sound/initval.h> #include <linux/spi/spi.h> +#include <linux/of_device.h> +#include <linux/of_gpio.h> #include <sound/asoundef.h> /* AK4104 registers addresses */ @@ -204,6 +206,7 @@ static const struct regmap_config ak4104_regmap = { static int ak4104_spi_probe(struct spi_device *spi) { + struct device_node *np = spi->dev.of_node; struct ak4104_private *ak4104; unsigned int val; int ret; @@ -225,6 +228,20 @@ static int ak4104_spi_probe(struct spi_device *spi) return ret; } + if (np) { + enum of_gpio_flags flags; + int gpio = of_get_named_gpio_flags(np, "reset-gpio", 0, &flags); + + if (gpio_is_valid(gpio)) { + ret = devm_gpio_request_one(&spi->dev, gpio, + flags & OF_GPIO_ACTIVE_LOW ? + GPIOF_OUT_INIT_LOW : GPIOF_OUT_INIT_HIGH, + "ak4104 reset"); + if (ret < 0) + return ret; + } + } + /* read the 'reserved' register - according to the datasheet, it * should contain 0x5b. Not a good way to verify the presence of * the device, but there is no hardware ID register. */ -- 1.7.11.7

2 4

Re: [alsa-devel] [PATCH 1/1] media: Entities with sink pads must have at least one enabled link
by Laurent Pinchart 14 Nov '12

14 Nov '12

Hi Sylwester, On Wednesday 14 November 2012 10:23:19 Sylwester Nawrocki wrote: > On 11/13/2012 03:24 PM, Sakari Ailus wrote: > > Hi all, > > > > Comments would be appreciated, either positive or negative. The omap3isp > > driver does the same check itself currently, but I think this is more > > generic than that. > > > > Thanks. > > > > On Fri, Oct 26, 2012 at 10:46:17PM +0300, Sakari Ailus wrote: > >> If an entity has sink pads, at least one of them must be connected to > >> another pad with an enabled link. If a driver with multiple sink pads has > >> more strict requirements the check should be done in the driver itself. > >> > >> Just requiring one sink pad is connected with an enabled link is enough > >> API-wise: entities with sink pads with only disabled links should not be > >> allowed to stream in the first place, but also in a different operation > >> mode a device might require only one of its pads connected with an > >> active link. > >> > >> If an entity has an ability to function as a source entity another > >> logical entity connected to the aforementioned one should be used for the > >> purpose. > > Why not leave it to individual drivers ? I'm not sure if it is a good idea > not to allow an entity with sink pads to be used as a source only. It might > be appropriate for most of the cases but likely not all. I'm inclined not to > add this requirement in the API. Just my opinion though. I have mixed feelings about this patch too, which is why I've asked Sakari to cross-post it. It's pretty easy to add this check to the core now, but pushing it back to drivers late if we realize it's too restrictive would be difficult. I think my preference would go for a helper function that drivers can use, possibly first waiting until a second driver requires this kind of checks before implementing it. -- Regards, Laurent Pinchart

1 0

[alsa-devel] CM6206, S/PDIF + JACK
by Dan MacDonald 14 Nov '12

14 Nov '12

Hi ALSA devs! I've got a Startech USB device based on the CM6206 chipset. It does work with JACK although I can only access the two mic inputs as JACK capture ports even though under alsamixer I can also see line in and SPDIF In. I bought it in the hope of using its SPDIF input under JACK. SPDIF is enabled under alsamixer and even when I start JACK with a signal coming in to SPDIF, I still get no SPDIF capture port.I have posted various ALSA logs and more details here: http://www.linuxmusicians.com/viewtopic.php?f=27&t=8898 I've already spoke to las about this but he couldn't help me, no knowing anything about these devices. Might I be able to get this working under JACK? Maybe I need a special ALSA config to enable SPDIF? Thanks! Dan

2 6

[alsa-devel] ALSA with dmix, help needed
by Sandulescu Bogdan 14 Nov '12

14 Nov '12

Hello, I am struggling for some time now with dmix plugin from ALSA. Could anyone please answer to these questions: 1. Is ALSA library with DMIX plugin suitable for real-time embedded systems: where it's needed small api latencies, fast output to dma/serial bus and no audible defects? 2. Is it reliable to use ALSA commands from different threads? (e.g. open() in one master thread, writei() from child threads)? 3. Is it normal that two consecutive writei() calls to generate underrun - this happens only just after opening the dmix device. e.g.: if( snd_pcm_writei(pPcmPlayHandle, (pu8WavDataBuf), 2048) < 0) fprintf(stderr, "Underrun encountered: application didn't sent enough data to the ALSA buffer \n"); if( snd_pcm_writei(pPcmPlayHandle, (pu8WavDataBuf+4096),2048) < 0) fprintf(stderr, "Underrun encountered: application didn't sent enough data to the ALSA buffer \n"); The second writei() generates this underrun error (-32), even though there is no delay between these two calls. The get_buff_size is 4096, get_buf_period = 1024. 4. The pcm_drain() help states: "for playback, wait for all pending frames to be played and then stop the PCM" But, how come the execution duration of this drain() takes longer than the actual sound duration? e.g. pcm_drain() takes 300-400 miliseconds, but the wav size sent to writei() is less than 100ms? I'm using ASLA lib 1.0.25, on a ARM controller with 440MHz, and no other high prio threads.

1 0

[alsa-devel] [PATCH 1/2] ALSA: core: fix NULL checking in snd_pcm_plug_client_size()
by Xi Wang 14 Nov '12

14 Nov '12

The dereference snd_pcm_plug_stream(plug) should come after the NULL check snd_BUG_ON(!plug). Signed-off-by: Xi Wang <xi.wang(a)gmail.com> --- sound/core/oss/pcm_plugin.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/core/oss/pcm_plugin.c b/sound/core/oss/pcm_plugin.c index 71cc3dd..f0d7b15 100644 --- a/sound/core/oss/pcm_plugin.c +++ b/sound/core/oss/pcm_plugin.c @@ -199,12 +199,13 @@ int snd_pcm_plugin_free(struct snd_pcm_plugin *plugin) snd_pcm_sframes_t snd_pcm_plug_client_size(struct snd_pcm_substream *plug, snd_pcm_uframes_t drv_frames) { struct snd_pcm_plugin *plugin, *plugin_prev, *plugin_next; - int stream = snd_pcm_plug_stream(plug); + int stream; if (snd_BUG_ON(!plug)) return -ENXIO; if (drv_frames == 0) return 0; + stream = snd_pcm_plug_stream(plug); if (stream == SNDRV_PCM_STREAM_PLAYBACK) { plugin = snd_pcm_plug_last(plug); while (plugin && drv_frames > 0) { -- 1.7.10.4

2 2

[alsa-devel] [patch] ALSA: fm801: precedence bug in snd_fm801_tea575x_get_pins()
by Dan Carpenter 14 Nov '12

14 Nov '12

There is a precedence bug because | has higher precedence than ?:. This code was cut and pasted and I fixed a similar bug a few days ago. Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> diff --git a/sound/pci/fm801.c b/sound/pci/fm801.c index cc2e91d..c5806f8 100644 --- a/sound/pci/fm801.c +++ b/sound/pci/fm801.c @@ -767,9 +767,14 @@ static u8 snd_fm801_tea575x_get_pins(struct snd_tea575x *tea) struct fm801 *chip = tea->private_data; unsigned short reg = inw(FM801_REG(chip, GPIO_CTRL)); struct snd_fm801_tea575x_gpio gpio = *get_tea575x_gpio(chip); - - return (reg & FM801_GPIO_GP(gpio.data)) ? TEA575X_DATA : 0 | - (reg & FM801_GPIO_GP(gpio.most)) ? TEA575X_MOST : 0; + u8 ret; + + ret = 0; + if (reg & FM801_GPIO_GP(gpio.data)) + ret |= TEA575X_DATA; + if (reg & FM801_GPIO_GP(gpio.most)) + ret |= TEA575X_MOST; + return ret; } static void snd_fm801_tea575x_set_direction(struct snd_tea575x *tea, bool output)

2 1

[alsa-devel] [PATCH] ASoC: ab8500: Staticise non-exported ab85000_codec_dai
by Mark Brown 14 Nov '12

14 Nov '12

Signed-off-by: Mark Brown <broonie(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/ab8500-codec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/ab8500-codec.c b/sound/soc/codecs/ab8500-codec.c index af54749..4d96090 100644 --- a/sound/soc/codecs/ab8500-codec.c +++ b/sound/soc/codecs/ab8500-codec.c @@ -2356,7 +2356,7 @@ static int ab8500_codec_set_dai_tdm_slot(struct snd_soc_dai *dai, return 0; } -struct snd_soc_dai_driver ab8500_codec_dai[] = { +static struct snd_soc_dai_driver ab8500_codec_dai[] = { { .name = "ab8500-codec-dai.0", .id = 0, -- 1.7.10.4

1 0

[alsa-devel] [PATCH v5 0/3] Add pinctrl support and enable audio
by Bo Shen 14 Nov '12

14 Nov '12

This patch set is based on linux next master branch The detail information as following: Git: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git Branch: master Commit ID: 75e0ebabd87048b91e4189b90d4af8ef565115db Detail information about implement as following: - atmel ssc: add pinctrl support - atmel ssc dai: register dai and pcm directly - at91sam9g20ek wm8731: convert to dt support Bo Shen (3): ARM: at91: atmel-ssc: add pinctrl support ASoC: atmel-ssc-dai: register dai and pcm directly ASoC: at91sam9g20ek-wm8731: convert to dt support .../sound/atmel-at91sam9g20ek-wm8731-audio.txt | 26 +++ arch/arm/boot/dts/at91sam9260.dtsi | 18 ++ arch/arm/boot/dts/at91sam9263.dtsi | 36 ++++ arch/arm/boot/dts/at91sam9g20ek_common.dtsi | 34 ++- arch/arm/boot/dts/at91sam9g45.dtsi | 36 ++++ arch/arm/boot/dts/at91sam9n12.dtsi | 26 +++ arch/arm/boot/dts/at91sam9x5.dtsi | 32 ++- arch/arm/mach-at91/at91sam9260_devices.c | 9 - arch/arm/mach-at91/board-sam9g20ek.c | 8 +- drivers/misc/atmel-ssc.c | 8 + sound/soc/atmel/Kconfig | 3 +- sound/soc/atmel/atmel-pcm.c | 23 +- sound/soc/atmel/atmel-pcm.h | 3 + sound/soc/atmel/atmel_ssc_dai.c | 228 +++++--------------- sound/soc/atmel/atmel_ssc_dai.h | 1 + sound/soc/atmel/sam9g20_wm8731.c | 89 +++++++- 16 files changed, 357 insertions(+), 223 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/atmel-at91sam9g20ek-wm8731-audio.txt -- 1.7.9.5

2 11

[alsa-devel] [PATCH 1/3] ASoC: arizona: Add support for multiplexer with no associated mixer
by Charles Keepax 14 Nov '12

14 Nov '12

The Asynchronous Sample Rate Converters on the wm5102/wm5110 have no mixer attached to their input, but they do allow the input to be selected from a number of sources via a multiplexer. Currently the platform assumes the presence of 4 multiplexers and a mixer for each block. This patch adds support multiplexed single input blocks into the Arizona platform. Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- sound/soc/codecs/arizona.h | 40 ++++++++++++++++++++-------------------- 1 files changed, 20 insertions(+), 20 deletions(-) diff --git a/sound/soc/codecs/arizona.h b/sound/soc/codecs/arizona.h index 5a09127..f1c0ec9 100644 --- a/sound/soc/codecs/arizona.h +++ b/sound/soc/codecs/arizona.h @@ -94,33 +94,30 @@ extern int arizona_mixer_values[ARIZONA_NUM_MIXER_INPUTS]; const struct snd_kcontrol_new name##_mux = \ SOC_DAPM_VALUE_ENUM("Route", name##_enum) +#define ARIZONA_MUX_ENUMS(name, base_reg) \ + static ARIZONA_MUX_ENUM_DECL(name##_enum, base_reg); \ + static ARIZONA_MUX_CTL_DECL(name) + #define ARIZONA_MIXER_ENUMS(name, base_reg) \ - static ARIZONA_MUX_ENUM_DECL(name##_in1_enum, base_reg); \ - static ARIZONA_MUX_ENUM_DECL(name##_in2_enum, base_reg + 2); \ - static ARIZONA_MUX_ENUM_DECL(name##_in3_enum, base_reg + 4); \ - static ARIZONA_MUX_ENUM_DECL(name##_in4_enum, base_reg + 6); \ - static ARIZONA_MUX_CTL_DECL(name##_in1); \ - static ARIZONA_MUX_CTL_DECL(name##_in2); \ - static ARIZONA_MUX_CTL_DECL(name##_in3); \ - static ARIZONA_MUX_CTL_DECL(name##_in4) + ARIZONA_MUX_ENUMS(name##_in1, base_reg); \ + ARIZONA_MUX_ENUMS(name##_in2, base_reg + 2); \ + ARIZONA_MUX_ENUMS(name##_in3, base_reg + 4); \ + ARIZONA_MUX_ENUMS(name##_in4, base_reg + 6) #define ARIZONA_DSP_AUX_ENUMS(name, base_reg) \ - static ARIZONA_MUX_ENUM_DECL(name##_aux1_enum, base_reg); \ - static ARIZONA_MUX_ENUM_DECL(name##_aux2_enum, base_reg + 8); \ - static ARIZONA_MUX_ENUM_DECL(name##_aux3_enum, base_reg + 16); \ - static ARIZONA_MUX_ENUM_DECL(name##_aux4_enum, base_reg + 24); \ - static ARIZONA_MUX_ENUM_DECL(name##_aux5_enum, base_reg + 32); \ - static ARIZONA_MUX_ENUM_DECL(name##_aux6_enum, base_reg + 40); \ - static ARIZONA_MUX_CTL_DECL(name##_aux1); \ - static ARIZONA_MUX_CTL_DECL(name##_aux2); \ - static ARIZONA_MUX_CTL_DECL(name##_aux3); \ - static ARIZONA_MUX_CTL_DECL(name##_aux4); \ - static ARIZONA_MUX_CTL_DECL(name##_aux5); \ - static ARIZONA_MUX_CTL_DECL(name##_aux6) + ARIZONA_MUX_ENUMS(name##_aux1, base_reg); \ + ARIZONA_MUX_ENUMS(name##_aux2, base_reg + 8); \ + ARIZONA_MUX_ENUMS(name##_aux3, base_reg + 16); \ + ARIZONA_MUX_ENUMS(name##_aux4, base_reg + 24); \ + ARIZONA_MUX_ENUMS(name##_aux5, base_reg + 32); \ + ARIZONA_MUX_ENUMS(name##_aux6, base_reg + 40) #define ARIZONA_MUX(name, ctrl) \ SND_SOC_DAPM_VALUE_MUX(name, SND_SOC_NOPM, 0, 0, ctrl) +#define ARIZONA_MUX_WIDGETS(name, name_str) \ + ARIZONA_MUX(name_str " Input", &name##_mux) + #define ARIZONA_MIXER_WIDGETS(name, name_str) \ ARIZONA_MUX(name_str " Input 1", &name##_in1_mux), \ ARIZONA_MUX(name_str " Input 2", &name##_in2_mux), \ @@ -138,6 +135,9 @@ extern int arizona_mixer_values[ARIZONA_NUM_MIXER_INPUTS]; ARIZONA_MUX(name_str " Aux 5", &name##_aux5_mux), \ ARIZONA_MUX(name_str " Aux 6", &name##_aux6_mux) +#define ARIZONA_MUX_ROUTES(name) \ + ARIZONA_MIXER_INPUT_ROUTES(name " Input") + #define ARIZONA_MIXER_ROUTES(widget, name) \ { widget, NULL, name " Mixer" }, \ { name " Mixer", NULL, name " Input 1" }, \ -- 1.7.2.5

2 3

[alsa-devel] [PATCH v2 1/2] ASoC: mxs-saif: Fix channel swap for 24-bit format
by Fabio Estevam 14 Nov '12

14 Nov '12

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> --- Changes since v1: - Clarify that the extra read/write is also safe for non 24-bit formats. sound/soc/mxs/mxs-saif.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/sound/soc/mxs/mxs-saif.c b/sound/soc/mxs/mxs-saif.c index aa037b2..0eb2883 100644 --- a/sound/soc/mxs/mxs-saif.c +++ b/sound/soc/mxs/mxs-saif.c @@ -523,16 +523,24 @@ 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. + * This is also safe for the other non 24-bit formats. */ __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. + * This is also safe for the other non 24-bit formats. */ __raw_readl(saif->base + SAIF_DATA); + __raw_readl(saif->base + SAIF_DATA); } master_saif->ongoing = 1; -- 1.7.9.5

4 6

[alsa-devel] [PATCH v3 1/2] aplay: Show usage if no parameter is passed
by Fabio Estevam 13 Nov '12

13 Nov '12

When aplay/arecord are called without any argument the application hangs forever. Instead of hanging, print the usage and exit. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- Changes since v2: - return 1 instead of 0 - Use stdout for the arecord case Changes since v1: - Also check for isatty, so that 'aplay < file.wav' can still work aplay/aplay.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/aplay/aplay.c b/aplay/aplay.c index 741979a..66cc78f 100644 --- a/aplay/aplay.c +++ b/aplay/aplay.c @@ -493,6 +493,7 @@ int main(int argc, char *argv[]) int tmp, err, c; int do_device_list = 0, do_pcm_list = 0; snd_pcm_info_t *info; + FILE *direction; #ifdef ENABLE_NLS setlocale(LC_ALL, ""); @@ -511,14 +512,21 @@ int main(int argc, char *argv[]) file_type = FORMAT_WAVE; command = "arecord"; start_delay = 1; + direction = stdout; } else if (strstr(argv[0], "aplay")) { stream = SND_PCM_STREAM_PLAYBACK; command = "aplay"; + direction = stdin; } else { error(_("command should be named either arecord or aplay")); return 1; } + if (isatty(fileno(direction)) && (argc == 1)) { + usage(command); + return 1; + } + chunk_size = -1; rhwparams.format = DEFAULT_FORMAT; rhwparams.rate = DEFAULT_SPEED; -- 1.7.9.5

3 3

Re: [alsa-devel] Races in alsa-lib with threads
by Krakora Robert-B42341 13 Nov '12

13 Nov '12

> From: Takashi Iwai [tiwai(a)suse.de] > Sent: Tuesday, November 13, 2012 2:30 AM > To: Trent Piepho > Cc: Krakora Robert-B42341; alsa-devel(a)alsa-project.org > Subject: Re: [alsa-devel] Races in alsa-lib with threads > > At Tue, 13 Nov 2012 02:14:08 -0500, > Trent Piepho wrote: > > > > On Tue, Nov 13, 2012 at 1:32 AM, Takashi Iwai <tiwai(a)suse.de> wrote: > > > At Mon, 12 Nov 2012 19:40:42 +0000 (UTC), > > > Rob Krakora wrote: > > >> Would you be able to point me the the ALSA documentation that indicates the > > >> stipulations on handle usage using multiple threads? I cannot find it. > > > > > > Think other way round: > > > The fact that it isn't documented means it's not safe to use in that > > > way :) > > > > > > The introduction on the alsa-project home page says, "SMP and > > thread-safe design. " Some people might misunderstand what > > thread-safe means. Maybe some clarification could be added. > > "Different streams are SMP and thread-safe (calls for the same stream > > must be serialized)." > > Yeah this should be corrected. SMP things are just about the kernel > side at that time. > > It's a Wiki, feel free to correct / improve the text. > > > Takashi Hi Takashi, The way that the GStreamer ALSA Sink Plugin is using ALSA Lib assumes that it is thread safe. The fix crafted by one of Trent's colleagues (attached) seems to be the way to go. However, I don't know how it would impact other functionality within ALSA Lib. Best Regards, Rob Krakora

1 0

[alsa-devel] [PATCH v4 2/2] ac3dec: Show usage if no parameter is passed
by Fabio Estevam 13 Nov '12

13 Nov '12

When ac3dec is called without any argument the application hangs forever. Instead of hanging, print the usage and exit. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- Changes since v3: - Fix return value Changes since v2: - No changes Changes since v1: - Also check for isatty, so that 'ac3dec < file.wav' can still work ac3dec/ac3dec.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/ac3dec/ac3dec.c b/ac3dec/ac3dec.c index 00c4f1a..ce6c507 100644 --- a/ac3dec/ac3dec.c +++ b/ac3dec/ac3dec.c @@ -130,6 +130,11 @@ int main(int argc,char *argv[]) out_config.spdif = SPDIF_NONE; out_config.hdmi = 0; + if (isatty(fileno(stdin)) && (argc == 1)) { + help(); + return 1; + } + morehelp = 0; while (1) { int c; -- 1.7.9.5

2 1

[alsa-devel] [PATCH v2 1/2] aplay: Show usage if no parameter is passed
by Fabio Estevam 13 Nov '12

13 Nov '12

When aplay/arecord are called without any argument the application hangs forever. Instead of hanging, print the usage and exit. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- Changes since v1: - Also check for isatty, so that 'aplay < file.wav' can still work aplay/aplay.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/aplay/aplay.c b/aplay/aplay.c index 741979a..38459e6 100644 --- a/aplay/aplay.c +++ b/aplay/aplay.c @@ -519,6 +519,11 @@ int main(int argc, char *argv[]) return 1; } + if (isatty(fileno(stdin)) && (argc == 1)) { + usage(command); + return 0; + } + chunk_size = -1; rhwparams.format = DEFAULT_FORMAT; rhwparams.rate = DEFAULT_SPEED; -- 1.7.9.5

3 3

Re: [alsa-devel] Sound+USB: deadlock problem
by Takashi Iwai 13 Nov '12

13 Nov '12

At Tue, 13 Nov 2012 10:39:14 +0100, Jiri Slaby wrote: > > On 11/13/2012 09:45 AM, Takashi Iwai wrote: > > At Tue, 13 Nov 2012 09:30:10 +0100, > > Jiri Slaby wrote: > >> > >> On 11/13/2012 09:28 AM, Takashi Iwai wrote: > >>> At Tue, 13 Nov 2012 09:26:17 +0100, > >>> Jiri Slaby wrote: > >>>> > >>>> Hello, > >>>> > >>>> I've just plugged+unplugged+plugged my USB audio card and the audio > >>>> subsystem got stuck: > >>> > >>> Which kernel? If it's older than 3.7-rc5, could you try 3.7-rc5? > >> > >> Oh, forgot to mention: > >> 3.7.0-rc5-next-20121112_64+ > > > > Through a quick glance, one of mutex locks seems stuck. > > Just a blind short -- does the patch below cure the problem? > > Yes, this helps. > > Adding a LOCKDEP splash _before_ applying the patch: Thanks, this helps much for understanding the cause. It's a new rwsem in the usb-audio driver that deadlocks. Although the previous patch fixes the deadlock it opens the race again. Could you try the patch below instead? The rwsem above doesn't have to be taken for the whole operation, but just needs to protect for turning on the flag. The patch below should suffice for protecting races but avoids the deadlock. Takashi --- diff --git a/sound/usb/card.c b/sound/usb/card.c index 282f0fc..dbf7999 100644 --- a/sound/usb/card.c +++ b/sound/usb/card.c @@ -559,9 +559,11 @@ static void snd_usb_audio_disconnect(struct usb_device *dev, return; card = chip->card; - mutex_lock(&register_mutex); down_write(&chip->shutdown_rwsem); chip->shutdown = 1; + up_write(&chip->shutdown_rwsem); + + mutex_lock(&register_mutex); chip->num_interfaces--; if (chip->num_interfaces <= 0) { snd_card_disconnect(card); @@ -582,11 +584,9 @@ static void snd_usb_audio_disconnect(struct usb_device *dev, snd_usb_mixer_disconnect(p); } usb_chip[chip->index] = NULL; - up_write(&chip->shutdown_rwsem); mutex_unlock(&register_mutex); snd_card_free_when_closed(card); } else { - up_write(&chip->shutdown_rwsem); mutex_unlock(&register_mutex); } }

1 0

Re: [alsa-devel] Sound+USB: deadlock problem
by Takashi Iwai 13 Nov '12

13 Nov '12

At Tue, 13 Nov 2012 09:30:10 +0100, Jiri Slaby wrote: > > On 11/13/2012 09:28 AM, Takashi Iwai wrote: > > At Tue, 13 Nov 2012 09:26:17 +0100, > > Jiri Slaby wrote: > >> > >> Hello, > >> > >> I've just plugged+unplugged+plugged my USB audio card and the audio > >> subsystem got stuck: > > > > Which kernel? If it's older than 3.7-rc5, could you try 3.7-rc5? > > Oh, forgot to mention: > 3.7.0-rc5-next-20121112_64+ Through a quick glance, one of mutex locks seems stuck. Just a blind short -- does the patch below cure the problem? thanks, Takashi --- diff --git a/sound/core/pcm.c b/sound/core/pcm.c index 030102c..a66a7ca 100644 --- a/sound/core/pcm.c +++ b/sound/core/pcm.c @@ -1086,7 +1086,7 @@ static int snd_pcm_dev_disconnect(struct snd_device *device) if (list_empty(&pcm->list)) goto unlock; - mutex_lock(&pcm->open_mutex); + /* mutex_lock(&pcm->open_mutex); */ wake_up(&pcm->open_wait); list_del_init(&pcm->list); for (cidx = 0; cidx < 2; cidx++) @@ -1118,7 +1118,7 @@ static int snd_pcm_dev_disconnect(struct snd_device *device) pcm->streams[cidx].chmap_kctl = NULL; } } - mutex_unlock(&pcm->open_mutex); + /* mutex_unlock(&pcm->open_mutex); */ unlock: mutex_unlock(&register_mutex); return 0;

1 0

Re: [alsa-devel] Sound+USB: deadlock problem
by Takashi Iwai 13 Nov '12

13 Nov '12

At Tue, 13 Nov 2012 09:26:17 +0100, Jiri Slaby wrote: > > Hello, > > I've just plugged+unplugged+plugged my USB audio card and the audio > subsystem got stuck: Which kernel? If it's older than 3.7-rc5, could you try 3.7-rc5? Takashi > > INFO: task khubd:440 blocked for more than 120 seconds. > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > khubd D ffff8801cbc92400 0 440 2 0x00000000 > ffff8801c4ae3a38 0000000000000046 ffff8801c49be270 ffff8801c4ae3fd8 > ffff8801c4ae3fd8 ffff8801c4ae3fd8 ffff8801c4284830 ffff8801c49be270 > ffff8801c4ae3a28 ffff8801a7198758 ffff8801a719875c ffff8801c49be270 > Call Trace: > [<ffffffff816ae109>] schedule+0x29/0x70 > [<ffffffff816ae38e>] schedule_preempt_disabled+0xe/0x10 > [<ffffffff816ad02a>] __mutex_lock_slowpath+0xca/0x140 > [<ffffffff816acb5a>] mutex_lock+0x2a/0x50 > [<ffffffff8157c8e6>] snd_pcm_dev_disconnect+0x46/0x1f0 > [<ffffffff81576512>] snd_device_disconnect+0x62/0xa0 > [<ffffffff815765f4>] snd_device_disconnect_all+0x44/0x70 > [<ffffffff81570d83>] snd_card_disconnect+0x153/0x1d0 > [<ffffffff816ad3a8>] ? down_write+0x38/0x40 > [<ffffffff815bf038>] usb_audio_disconnect+0x88/0x1c0 > [<ffffffff814df460>] usb_unbind_interface+0x60/0x1a0 > [<ffffffff81436e4c>] __device_release_driver+0x7c/0xe0 > [<ffffffff814370bc>] device_release_driver+0x2c/0x40 > [<ffffffff8143681e>] bus_remove_device+0xee/0x160 > [<ffffffff81433c2a>] device_del+0x11a/0x1b0 > [<ffffffff814dce40>] usb_disable_device+0xb0/0x270 > [<ffffffff814d38ed>] usb_disconnect+0xad/0x160 > [<ffffffff814d613e>] hub_thread+0x6fe/0x1700 > [<ffffffff810b643e>] ? dequeue_task_fair+0xee/0x100 > [<ffffffff810a2c70>] ? finish_wait+0x80/0x80 > [<ffffffff814d5a40>] ? usb_remote_wakeup+0x70/0x70 > [<ffffffff810a2620>] kthread+0xc0/0xd0 > [<ffffffff810a2560>] ? kthread_create_on_node+0x130/0x130 > [<ffffffff816afb5c>] ret_from_fork+0x7c/0xb0 > [<ffffffff810a2560>] ? kthread_create_on_node+0x130/0x130 > INFO: task pulseaudio:4642 blocked for more than 120 seconds. > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > pulseaudio D ffff8801cbc12400 0 4642 1 0x00000000 > ffff8801c1c39cf0 0000000000000082 ffff8801c0d7d550 ffff8801c1c39fd8 > ffff8801c1c39fd8 ffff8801c1c39fd8 ffff8801a7203480 ffff8801c0d7d550 > ffff8801aa37b530 ffff8801c0d7d550 ffff8800ab118a48 fffffffeffffffff > Call Trace: > [<ffffffff816ae109>] schedule+0x29/0x70 > [<ffffffff816aeafd>] rwsem_down_failed_common+0xbd/0x150 > [<ffffffff816aebc5>] rwsem_down_read_failed+0x15/0x17 > [<ffffffff81302c04>] call_rwsem_down_read_failed+0x14/0x30 > [<ffffffff816ad3d4>] ? down_read+0x24/0x2b > [<ffffffff815c84b2>] snd_usb_hw_free+0x42/0x90 > [<ffffffff815809ab>] snd_pcm_release_substream+0x5b/0xc0 > [<ffffffff81580a58>] snd_pcm_release+0x48/0xb0 > [<ffffffff815707d7>] snd_disconnect_release+0x97/0xe0 > [<ffffffff8116ed8c>] __fput+0xec/0x230 > [<ffffffff8116eede>] ____fput+0xe/0x10 > [<ffffffff8109ef37>] task_work_run+0xa7/0xe0 > [<ffffffff81045959>] do_notify_resume+0x59/0x80 > [<ffffffff816afe08>] int_signal+0x12/0x17 > INFO: task khubd:440 blocked for more than 120 seconds. > "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. > khubd D ffff8801cbc92400 0 440 2 0x00000000 > ffff8801c4ae3a38 0000000000000046 ffff8801c49be270 ffff8801c4ae3fd8 > ffff8801c4ae3fd8 ffff8801c4ae3fd8 ffff8801c4284830 ffff8801c49be270 > ffff8801c4ae3a28 ffff8801a7198758 ffff8801a719875c ffff8801c49be270 > Call Trace: > [<ffffffff816ae109>] schedule+0x29/0x70 > [<ffffffff816ae38e>] schedule_preempt_disabled+0xe/0x10 > [<ffffffff816ad02a>] __mutex_lock_slowpath+0xca/0x140 > [<ffffffff816acb5a>] mutex_lock+0x2a/0x50 > [<ffffffff8157c8e6>] snd_pcm_dev_disconnect+0x46/0x1f0 > [<ffffffff81576512>] snd_device_disconnect+0x62/0xa0 > [<ffffffff815765f4>] snd_device_disconnect_all+0x44/0x70 > [<ffffffff81570d83>] snd_card_disconnect+0x153/0x1d0 > [<ffffffff816ad3a8>] ? down_write+0x38/0x40 > [<ffffffff815bf038>] usb_audio_disconnect+0x88/0x1c0 > [<ffffffff814df460>] usb_unbind_interface+0x60/0x1a0 > [<ffffffff81436e4c>] __device_release_driver+0x7c/0xe0 > [<ffffffff814370bc>] device_release_driver+0x2c/0x40 > [<ffffffff8143681e>] bus_remove_device+0xee/0x160 > [<ffffffff81433c2a>] device_del+0x11a/0x1b0 > [<ffffffff814dce40>] usb_disable_device+0xb0/0x270 > [<ffffffff814d38ed>] usb_disconnect+0xad/0x160 > [<ffffffff814d613e>] hub_thread+0x6fe/0x1700 > [<ffffffff810b643e>] ? dequeue_task_fair+0xee/0x100 > [<ffffffff810a2c70>] ? finish_wait+0x80/0x80 > [<ffffffff814d5a40>] ? usb_remote_wakeup+0x70/0x70 > [<ffffffff810a2620>] kthread+0xc0/0xd0 > [<ffffffff810a2560>] ? kthread_create_on_node+0x130/0x130 > [<ffffffff816afb5c>] ret_from_fork+0x7c/0xb0 > [<ffffffff810a2560>] ? kthread_create_on_node+0x130/0x130 > sadc D ffff8801cbc92400 0 7883 7870 0x00000004 > ffff8801b9ab5d98 0000000000000082 ffff8801087b0d20 ffff8801b9ab5fd8 > ffff8801b9ab5fd8 ffff8801b9ab5fd8 ffff8801c487c830 ffff8801087b0d20 > ffff8801c0ca5380 ffff8801b99b08e8 ffff8801b99b08ec ffff8801087b0d20 > Call Trace: > [<ffffffff816ae109>] schedule+0x29/0x70 > [<ffffffff816ae38e>] schedule_preempt_disabled+0xe/0x10 > [<ffffffff816ad02a>] __mutex_lock_slowpath+0xca/0x140 > [<ffffffff816acb5a>] mutex_lock+0x2a/0x50 > [<ffffffff814e312b>] show_manufacturer+0x2b/0x60 > [<ffffffff81433910>] dev_attr_show+0x20/0x60 > [<ffffffff81129707>] ? __get_free_pages+0x17/0x50 > [<ffffffff811d6fc5>] sysfs_read_file+0xa5/0x1c0 > [<ffffffff8116dcb9>] vfs_read+0xa9/0x180 > [<ffffffff8116dde2>] sys_read+0x52/0xa0 > [<ffffffff816afc02>] system_call_fastpath+0x16/0x1b > > > thanks, > -- > js > suse labs >

1 0

Re: [alsa-devel] [RFC PATCH v4 2/2] ASoC: sam9g20-wm8731: convert to dt support
by Mark Brown 13 Nov '12

13 Nov '12

On Thu, Nov 08, 2012 at 04:24:31PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 15:57 Thu 08 Nov , Bo Shen wrote: > > Signed-off-by: Bo Shen <voice.shen(a)atmel.com> > > --- > > Change since v3 RFC: > > Remove dai node, remap ssc in place > > without pinctrl added, so don't modify the dtsi file, will be added > > soon > until I see the pinctrl to test this no > This code is untested I see a version adding the DT pinmux stuff has now been posted but this does seem a bit unfair, the code should be fine on a current ASoC branch - it's only going to break after merging with the pinctrl support.

1 0

[alsa-devel] Races in alsa-lib with threads
by Trent Piepho 13 Nov '12

13 Nov '12

We've found a race with alsa-lib functions are called from multiple threads. I was under the impression that alsa-lib was supposed to be thread safe. Is this not the case and all alsa calls should be done one from thread or protected by a mutex? The race we found was in sync_ptr1() in pcm_hw.c. This issues the ioctl() to get the current hw ptr from the kernel and send the app ptr to the kernel. The communication is done by passing a pointer to hw->sync_ptr, a field in the snd_pcm_hw_t structure for the pcm. Any thread calling sync_ptr1 will pass the same structure to the kernel. This should be a red flag for a race, having two threads write to the same data structure at the same time. This function gets called by snd_pcm_writei(), as part of that function getting the current hw pointer so it can calculate the avail value. And again when it actually writes data to commit the new app pointer to the kernel. It also gets called by snd_pcm_delay() if a rate plugin is used. snd_pcm_rate_delay() will end up calling snd_pcm_hw_hwsync() and that does a sync_ptr1() call. So imaging two threads, one writing data and calling snd_pcm_writei() and another calling snd_pcm_delay() as part of trying to sync audio playback. gstreamer does this! The ioctl is handled by snd_pcm_sync_ptr() in pcm_native.c. It gets the stream lock while it reads/writes the various fields a sync struct on the stack, then releases the lock and calls copy_to_user to write the sync struct from its stack to userspace. Here's how the race works. Thread 1 calls snd_pcm_delay(). sync_ptr1 is called snd_pcm_sync_ptr gets the lock, fills a struct with the current data, releases the lock. Does not call copy_to_user yet! Thread 2 runs! It calls snd_pcm_writei(), actually writes data too It calls sync_ptr1() to update the app pointer with the new data and returns The snd_pcm_writei() call returns Thread 1 runs again, calls copy_to_user The copy_to_user writes the OLD struct that was prepared back on the 3rd line into userspace The hw and app pointer values, as far as the userspace copy in alsa-lib is concerned, have regressed to what they were before the call to snd_pcm_writei()! You get an audio stutter as the data written is overwritten by the next write. The race turns out to not be that unlikely. The stream lock is held and then released before calling copy_to_user. When it's released irqs are enabled. If a period has elapsed while the lock was held, the irq handle runs now, the elapsing period will wake anything blocked in poll() waiting for space, which then probably gets to run immediately since the schedule likes tasks that have been sleeping and just woke, and the new task was probably blocked waiting to write data so that's what it does as soon as it runs.

4 6

[alsa-devel] ASoC updates for 3.7
by Mark Brown 13 Nov '12

13 Nov '12

The following changes since commit 77b67063bb6bce6d475e910d3b886a606d0d91f7: Linux 3.7-rc5 (2012-11-11 13:44:33 +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 ba027da8eb309252cb611f23808da51487f68e12: Merge branches 'fix/arizona', 'fix/core', 'fix/cs42l52', 'fix/mxs', 'fix/samsung' and 'fix/wm8978' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into tmp (2012-11-13 15:13:29 +0900) ---------------------------------------------------------------- ASoC: Fixes for v3.7 A few small fixes plus a large but simple change for WM5102 which writes out a bunch of register updates to the device when we enable the clock as recommended following chip evaluation. ---------------------------------------------------------------- Charles Keepax (1): ASoC: bells: Correct type in sub speaker DAI name for WM5102 Dimitris Papastamos (2): ASoC: bells: Add missing select of WM0010 ASoC: bells: Select WM1250-EV1 Springbank audio I/O module Eric Millbrandt (1): ASoC: wm8978: pll incorrectly configured when codec is master Fabio Estevam (2): ASoC: mxs-saif: Add MODULE_ALIAS ASoC: mxs-saif: Fix channel swap for 24-bit format Mark Brown (2): ASoC: wm5102: Write register value corrections after SYSCLK is enabled Merge branches 'fix/arizona', 'fix/core', 'fix/cs42l52', 'fix/mxs', 'fix/samsung' and 'fix/wm8978' of git://git.kernel.org/.../broonie/sound into tmp Misael Lopez Cruz (1): ASoC: dapm: Use card_list during DAPM shutdown Mukund Navada (1): ASoC: core: Double control update err for snd_soc_put_volsw_sx Wei Yongjun (1): ASoC: cs42l52: fix the return value of cs42l52_set_fmt() sound/soc/codecs/cs42l52.c | 3 +- sound/soc/codecs/wm5102.c | 552 +++++++++++++++++++++++++++++++++++++++++++- sound/soc/codecs/wm8978.c | 2 +- sound/soc/mxs/mxs-saif.c | 17 +- sound/soc/samsung/Kconfig | 2 + sound/soc/samsung/bells.c | 2 +- sound/soc/soc-core.c | 5 +- sound/soc/soc-dapm.c | 2 +- 8 files changed, 573 insertions(+), 12 deletions(-)

2 1

[alsa-devel] [PATCH] ALSA: ASoC: cs4271: free allocated GPIO
by Daniel Mack 13 Nov '12

13 Nov '12

In case of probe deferral, the allocated GPIO line is not freed, which prevents it from being claimed and properly asserted in later attempts. Fix this by using devm_gpio_request(). Signed-off-by: Daniel Mack <zonque(a)gmail.com> Reported-by: Michael Hirsch <hirsch(a)teufel.de> Cc: Alexander Sverdlin <subaparts(a)yandex.ru> --- sound/soc/codecs/cs4271.c | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/sound/soc/codecs/cs4271.c b/sound/soc/codecs/cs4271.c index f994af3..e3f0a7f 100644 --- a/sound/soc/codecs/cs4271.c +++ b/sound/soc/codecs/cs4271.c @@ -485,7 +485,7 @@ static int cs4271_probe(struct snd_soc_codec *codec) gpio_nreset = cs4271plat->gpio_nreset; if (gpio_nreset >= 0) - if (gpio_request(gpio_nreset, "CS4271 Reset")) + if (devm_gpio_request(codec->dev, gpio_nreset, "CS4271 Reset")) gpio_nreset = -EINVAL; if (gpio_nreset >= 0) { /* Reset codec */ @@ -535,15 +535,10 @@ static int cs4271_probe(struct snd_soc_codec *codec) static int cs4271_remove(struct snd_soc_codec *codec) { struct cs4271_private *cs4271 = snd_soc_codec_get_drvdata(codec); - int gpio_nreset; - gpio_nreset = cs4271->gpio_nreset; - - if (gpio_is_valid(gpio_nreset)) { + if (gpio_is_valid(cs4271->gpio_nreset)) /* Set codec to the reset state */ - gpio_set_value(gpio_nreset, 0); - gpio_free(gpio_nreset); - } + gpio_set_value(cs4271->gpio_nreset, 0); return 0; }; -- 1.7.11.7

2 1

[alsa-devel] a52: update to new libavcodec API
by Anton Khirnov 13 Nov '12

13 Nov '12

Hi, this patchset updates the a52 plugin to work with the upcoming Libav 9 release. In doing that, it drops support for pre-0.8 libavcodec versions. I think it is not unreasonable to demand at least a year old libavcodec to compile latest git of alsa-plugins and keeping compatibility with the old audio encoding API would result in ugly #ifdefery mess. The plugin compiles and appears to work, but as I have no SPDIF receiver, I cannot properly test it. I would very much appreciate it if someone else could do that. Please comment. -- Anton Khirnov

2 5

[alsa-devel] [PATCH 1/2] aplay: Show usage if no parameter is passed
by Fabio Estevam 13 Nov '12

13 Nov '12

From: Fabio Estevam <fabio.estevam(a)freescale.com> When aplay/arecord are called without any argument the application hangs forever. Instead of hanging, print the usage and exit. Signed-off-by: Fabio Estevam <fabio.estevam(a)freescale.com> --- aplay/aplay.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/aplay/aplay.c b/aplay/aplay.c index 741979a..9cc5063 100644 --- a/aplay/aplay.c +++ b/aplay/aplay.c @@ -519,6 +519,11 @@ int main(int argc, char *argv[]) return 1; } + if (argc == 1) { + usage(command); + return 0; + } + chunk_size = -1; rhwparams.format = DEFAULT_FORMAT; rhwparams.rate = DEFAULT_SPEED; -- 1.7.9.5

2 2

Re: [alsa-devel] Help requested: new HSS1394 MIDI back-end
by Clemens Ladisch 12 Nov '12

12 Nov '12

Sean M. Pappalardo - D.J. Pegasus wrote: > On 05/30/2012 06:51 AM, Clemens Ladisch wrote: >> Sean M. Pappalardo - D.J. Pegasus wrote: >>> four-byte platter messages that start with >>> 0xF9 and the remaining three can range from 0x00 to 0xFF. >> >> This is not MIDI. Into what MIDI messages should >> the driver convert this? > > It shouldn't convert it at all. Just deliver it as-is in a single > four-byte message, if possible. The problem is the communication between the driver and userspace; _that_ must be valid MIDI. > 0xF9 is a valid, if undefined, MIDI status. Undefined means invalid. Furthermore, data bytes must not have the eighth bit set. > I will also need the ability to use the HSS1394 SendUserControl > function to set the device's timers, and that is definitely not MIDI > at all. > I wonder if it would be a good idea to define a special SYSEX message > that the SCS1x driver would interpret and convert to a call to that > function? As it happens, the actual SysEx commands use the wrong manufacturer ID ("00 01 02" is Crystal Semiconductor); I could just use the real ID (Stanton is "00 01 60") to escape non-MIDI HSS1394 messages. Let's add "HSS" to identify this, and to allow the full byte range, each HSS1394 byte is split into two nibbles. So: 00 F9 xx yy zz -> F0 00 01 60 48 53 53 00 00 0F 09 0x 0x 0y 0y 0z 0z F7 13 xx yy zz <- F0 00 01 60 48 53 53 01 03 0x 0x 0y 0y 0z 0z F7 14 xx yy zz <- F0 00 01 60 48 53 53 01 04 0x 0x 0y 0y 0z 0z F7 (0x13 = 0x10 + 3 = kUserTagBase + uUserTag) Regards, Clemens

3 21

Re: [alsa-devel] [sound:for-next 42/42] sound/pci/ice1712/ice1724.c:2366:5: error: 'struct snd_ice1712' has no member named 'pm_suspend_enabled'
by Takashi Iwai 12 Nov '12

12 Nov '12

At Mon, 12 Nov 2012 18:22:00 +0800, kbuild test robot wrote: > > tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-next > head: ef8784453d1cd5beedce9d288d56221a898c7ecb > commit: ef8784453d1cd5beedce9d288d56221a898c7ecb [42/42] ALSA: ice1724: enable suspend on unknown ICE1724 cards > config: i386-randconfig-b666 (attached as .config) > > All error/warnings: > > sound/pci/ice1712/ice1724.c: In function 'snd_vt1724_read_eeprom': > sound/pci/ice1712/ice1724.c:2366:5: error: 'struct snd_ice1712' has no member named 'pm_suspend_enabled' Fixed now like below. Thanks! Takashi --- From 063f603c8c1039f576405bb98c1b6c94262e5806 Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Mon, 12 Nov 2012 11:38:10 +0100 Subject: [PATCH] ALSA: ice1724: Fix build error without CONFIG_PM_SLEEP Bah, forgot this again... Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/ice1712/ice1724.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/pci/ice1712/ice1724.c b/sound/pci/ice1712/ice1724.c index 4c52a31..ea99e56 100644 --- a/sound/pci/ice1712/ice1724.c +++ b/sound/pci/ice1712/ice1724.c @@ -2362,8 +2362,10 @@ static int __devinit snd_vt1724_read_eeprom(struct snd_ice1712 *ice, } printk(KERN_WARNING "ice1724: No matching model found for ID 0x%x\n", ice->eeprom.subvendor); +#ifdef CONFIG_PM_SLEEP /* assume AC97-only card which can suspend without additional code */ ice->pm_suspend_enabled = 1; +#endif found: ice->eeprom.size = snd_vt1724_read_i2c(ice, dev, 0x04); -- 1.8.0

1 0

[alsa-devel] [PATCH] snd-ice1712: enable suspend on unknown ICE1724 cards
by Ondrej Zary 12 Nov '12

12 Nov '12

Assume that unknown ICE1724-based cards are AC97-only that can suspend without any additional card-specific code. This fixes suspend on Gainward Hollywood@Home 7.1. Signed-off-by: Ondrej Zary <linux(a)rainbow-software.org> --- sound/pci/ice1712/ice1724.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/sound/pci/ice1712/ice1724.c b/sound/pci/ice1712/ice1724.c index 5cc3fa5..aebd584 100644 --- a/sound/pci/ice1712/ice1724.c +++ b/sound/pci/ice1712/ice1724.c @@ -2363,6 +2363,8 @@ static int __devinit snd_vt1724_read_eeprom(struct snd_ice1712 *ice, } printk(KERN_WARNING "ice1724: No matching model found for ID 0x%x\n", ice->eeprom.subvendor); + /* assume AC97-only card which can suspend without additional code */ + ice->pm_suspend_enabled = 1; found: ice->eeprom.size = snd_vt1724_read_i2c(ice, dev, 0x04); -- Ondrej Zary

2 1

[alsa-devel] ALSA with dmix performance issue...
by Sandulescu Bogdan 12 Nov '12

12 Nov '12

Hello all, While implementing a multiple sounds playback using 'dmix' plugin, I've encountered several performance issues. Here they are: 1. The snd_pcm_open(&pPcmPlayHandle, "plug:'dmix:RATE=8000'" , SND_PCM_STREAM_PLAYBACK, 0) - used to playback multiple sounds with dmix pluging, it is taking around 70ms to complete. This is a very long period, considering there are some sounds to be played which have 50ms lenght! Is it possible to decrease this value? 2. Same issue with the "setting Parameters" sequence. It is also taking around 80ms to complete; Is it possible to decrease this value? 3. The architecture of my module is done as follows: - MainThread() -> receives sound play requests and creates new thread/threads based on such requests * PlayThreads() -> created whenever a sound playback is needed; it opens() the dmix, setting parameters; output data; close dmix; exit thread at playback completion; multiple PlayThreads() could be active at the same time! I have tried to move all 'common' sound settings and the pcm_open() - in order to optimize runtime - into the MainThread (operation done only once), and the PlayThreads are responsible just of outputing data. However, this resulted in incorrect ALSA functionality: when more than two playbacks are active at the same time, all Play threads , except the first activated one, cannnot access the PCM handle correctly: returned code -77 (EBADFD), in some other cases returned -5 (EIO)... Are there any other methods I can optimize the runtime performance? Thank you in advance for any answers, Bogdan

1 0

[alsa-devel] Non-blocking snd_pcm_drain?
by Daniel Sanz 11 Nov '12

11 Nov '12

Hello, I'm new to the ALSA API and I have a question: I've developed a small program that plays audio from a buffer using snd_pcm_writei and snd_pcm_drain but I noticed that the snd_pcm_drain call blocks until the buffer is completely drained. Is there any way to drain the buffer without a block? I've tried calling snd_pcm_nonblock(handle, 1) before the call to snd_pcm_drain but it does not work. The context is that this is an application that plays a particular WAV sound repeatedly, so I don't want to wait until the sound is played completely before it is played again. What would be the best way to achieve this? Thanks,

2 3

Re: [alsa-devel] Possible problem with cmipci driver
by Takashi Iwai 11 Nov '12

11 Nov '12

At Sat, 10 Nov 2012 11:20:06 -0700, Jake Edge wrote: > > > Hi Takashi, Jaroslav, and other sound developers, > > Maybe I am way off base, but I think there may be a bug relatively > recently introduced into the cmipci driver. I note that Takashi has > made some changes in July (commit: > 68cb2b559278858ef9f3a7722f95df88797c7840 ) that might (?) be relevant. If the above commit is the culprit, does the patch below help? Takashi --- diff --git a/sound/pci/cmipci.c b/sound/pci/cmipci.c index 22122ff..ae41982 100644 --- a/sound/pci/cmipci.c +++ b/sound/pci/cmipci.c @@ -3368,7 +3368,7 @@ static int snd_cmipci_suspend(struct device *dev) pci_disable_device(pci); pci_save_state(pci); - pci_set_power_state(pci, PCI_D3hot); + pci_set_power_state(pci, pci_choose_state(pci, PMSG_SUSPEND)); return 0; }

1 0

[alsa-devel] [PATCH] ALSA: ASoC: cs4271: free allocated GPIO
by Daniel Mack 10 Nov '12

10 Nov '12

In case of probe deferral, the allocated GPIO line is not freed, which prevents it from being claimed and properly asserted in later attempts. Fix this by freeing the GPIO in case of errors. Signed-off-by: Daniel Mack <zonque(a)gmail.com> Reported-by: Michael Hirsch <hirsch(a)teufel.de> Cc: Alexander Sverdlin <subaparts(a)yandex.ru> --- sound/soc/codecs/cs4271.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/sound/soc/codecs/cs4271.c b/sound/soc/codecs/cs4271.c index e5a7ea4..ea57014 100644 --- a/sound/soc/codecs/cs4271.c +++ b/sound/soc/codecs/cs4271.c @@ -505,7 +505,7 @@ static int cs4271_probe(struct snd_soc_codec *codec) ret = regulator_enable(cs4271->vd_supply); if (ret < 0) { dev_err(codec->dev, "unable to enable regulator\n"); - return ret; + goto err; } } @@ -548,22 +548,31 @@ static int cs4271_probe(struct snd_soc_codec *codec) cs4271->bus_type); if (ret) { dev_err(codec->dev, "Failed to set cache I/O: %d\n", ret); - return ret; + goto err_free_gpio; } ret = snd_soc_update_bits(codec, CS4271_MODE2, CS4271_MODE2_PDN | CS4271_MODE2_CPEN, CS4271_MODE2_PDN | CS4271_MODE2_CPEN); if (ret < 0) - return ret; + goto err_free_gpio; ret = snd_soc_update_bits(codec, CS4271_MODE2, CS4271_MODE2_PDN, 0); if (ret < 0) - return ret; + goto err_free_gpio; /* Power-up sequence requires 85 uS */ udelay(85); return snd_soc_add_codec_controls(codec, cs4271_snd_controls, ARRAY_SIZE(cs4271_snd_controls)); + +err_free_gpio: + if (gpio_is_valid(cs4271->gpio_nreset)) + gpio_free(cs4271->gpio_nreset); + + cs4271->gpio_nreset = -EINVAL; + +err: + return ret; } static int cs4271_remove(struct snd_soc_codec *codec) -- 1.7.11.7

2 2

[alsa-devel] snd_pcm_wait function
by Enno Fennema 10 Nov '12

10 Nov '12

The documentation says this functions waits for the pcm to become ready for I/O. I am not sure what ready means in this context. I assume entering the PREPARED state. Is that correct? Is there a function to wait for entering the SETUP state. In particular I would like to wait for pcm_snd_drain to finish. Appreciate any help. Enno Fennema

2 1

[alsa-devel] Bug in alsa-lib causes high CPU with rate plugin
by Trent Piepho 10 Nov '12

10 Nov '12

There is a bug in the way alsa-lib sleeps when using a plugin that can cause very high CPU usage for PCM playback with using rate conversion. I've attached a simple test program. It simply uses blocking mode and calls snd_pcm_writei() with a buffer of zeros one thousand times and then exits. One would think the CPU usage would be very low. And indeed when the write sized passed to snd_pcm_writei is equal to the period size it is quite low (i5 with HDA): lucid@Dashboard:~$ /usr/bin/time ./a.out > /dev/null period size 352, write size 352 done, wrote 1000 buffers of 352 frames 0.10user 0.15system 0:09.01elapsed 2%CPU (0avgtext+0avgdata 9360maxresident)k But, with one small change to have snd_pcm_writei() write buffers one frame larger than the period size, one gets this: period size 352, write size 353 done, wrote 1000 buffers of 353 frames 1.92user 2.00system 0:09.04elapsed 43%CPU (0avgtext+0avgdata 9360maxresident)k Simply increasing the write size by one caused the CPU usage to jump to 43% from 2%! Because more software writes in chunks equal to the period size it doesn't see this problem. That's why it wasn't found and fixed long ago. I've figured out why this is happening. The problem is caused by how alsa-lib decides to sleep when waiting for available buffer space and the way the rate plugin can only process complete periods at a time. Suppose we have the rate plugin with hw as its slave. Both have a ring buffer that is 3+ periods in size. Allowing for the rate conversion, the buffers and periods are the same size for both. avail_min is set to the normal value of one period for both. Suppose there are two empty periods in the buffer and we call snd_pcm_writei() to write 1.5 periods. That fits in the empty space in the rate plugin's buffer and so gets written immediately. The rate plugin's buffer now has 0.5 empty periods of space. The rate plugin will resample just one period of the newly written data, because it can only process complete periods at a time, and write that to the hw buffer. So the hw buffer now has one free period. This means the rate plugin has less free space in its buffer than the hw has, because the rate plugin has half a period of data it can't yet resample and pass to the slave. Now we write another one period of data with another snd_pcm_writei() call. This gets to snd_pcm_write_areas() in pcm.c and triggers this code (edited for brevity): if ((state == SND_PCM_STATE_RUNNING && (snd_pcm_uframes_t)avail < pcm->avail_min && size > (snd_pcm_uframes_t)avail)) { err = snd_pcm_wait(pcm, -1); goto _again; } avail is the available space in the rate plugin's buffer, which is half a period. pcm->avail_min is also for the rate plugin. size is the amount remaining in the writei() call, which is one period in this example. As we can see, the conditions of the if() statement are true. avail of 0.5 periods is less than avail_min of 1 period and the size of the write (1 period) is greater than avail. So we call snd_pcm_wait() and then go back to the top when it returns. avail will get updated to the current value and this code runs again. Eventually snd_pcm_wait() will call poll() and try to sleep in the kernel while waiting for more room to be available. But remember the hw buffer had one full period free! That's more than tghe half period that's free in the rate buffer and, and this is the key here, it is *more than avail_min*. So poll() will not sleep at all! That's where the 43% CPU comes from. alsa-lib is in a tight loop inside snd_pcm_write_areas() calling snd_pcm_wait() over and over again. snd_pcm_wait() doesn't sleep, because it's based on the status of the hw buffer and that buffer does have free space. snd_pcm_write_areas() would write to the hw buffer and not try to sleep. But it's not looking at the hw buffer when it decides to sleep or write, it's looking at the rate buffer. And the rate buffer's fill level says to sleep, not write. And if snd_pcm_wait() was looking at the rate buffer, it would sleep. We have the rate buffer that's current fill level says, "sleep first, then write" and the HW buffer that says the opposite, "write first, then sleep". The code that writes looks at the former and decides to sleep but the code that sleeps looks at the latter and decides it's not time sleep. A trivial patch that stops this behavior is below, which simply forces the rate plugin's avail_min to 1. diff --git a/src/pcm/pcm_rate.c b/src/pcm/pcm_rate.c index 41089d7..86f57c4 100644 --- a/src/pcm/pcm_rate.c +++ b/src/pcm/pcm_rate.c @@ -1142,6 +1142,7 @@ static int snd_pcm_rate_start(snd_pcm_t *pcm) return 0; } rate->start_pending = 0; + pcm->avail_min = 1; return snd_pcm_start(rate->gen.slave); } I think it would be better to have the rate plugin decrease avail_min by how much unresampled data it has yet to pass to the slave. This preserves the idea of avail_min if it were set to more than one period. This also fixes the problem. I've attached a real patch to do that. For the test program to show the problem YOU MUST USE THE RATE CONVERT PLUGIN! It seems obvious but people keep missing this. I found the easiest way to do that was to create a custom device in ~/.asoundrc that forced rate converting to 48kHz. Like this: pcm.foo { type plug; slave { pcm "hw:0,0"; rate 48000; } }

2 3

[alsa-devel] [PATCH] ASoC: samsung - Don't setup i2s if already active.
by Dylan Reid 09 Nov '12

09 Nov '12

If the dai is already running when setup is called, skip setup. Setting up again caused set_sysclk to set rclk_srcrate to other->rclk_srcrate, other would often be set to the default of 44.1. Playing a 48k stream then adding a 48k capture stream would lead to both streams set to 44.1 (The value of other->rclk_srcrate). Similarly in shutdown, if either playback or capture is still active, return instead of turning off the clocks. Signed-off-by: Dylan Reid <dgreid(a)chromium.org> --- sound/soc/samsung/i2s.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c index 40b00a1..b9935dd 100644 --- a/sound/soc/samsung/i2s.c +++ b/sound/soc/samsung/i2s.c @@ -637,6 +637,10 @@ static int i2s_startup(struct snd_pcm_substream *substream, struct i2s_dai *other = i2s->pri_dai ? : i2s->sec_dai; unsigned long flags; + /* Check not already running. */ + if (dai->playback_active || dai->capture_active) + return 0; + spin_lock_irqsave(&lock, flags); i2s->mode |= DAI_OPENED; @@ -661,6 +665,10 @@ static void i2s_shutdown(struct snd_pcm_substream *substream, struct i2s_dai *other = i2s->pri_dai ? : i2s->sec_dai; unsigned long flags; + /* Check not still running. */ + if (dai->playback_active || dai->capture_active) + return; + spin_lock_irqsave(&lock, flags); i2s->mode &= ~DAI_OPENED; -- 1.7.12.146.g16d26b1

2 2

Re: [alsa-devel] [PATCH 1/6] spi: imx: specify spi base for device tree probe
by Mark Brown 09 Nov '12

09 Nov '12

On Fri, Nov 09, 2012 at 03:00:20PM +0100, Steffen Trumtrar wrote: > * This breaks compatibility with user space applications between non-DT and DT. > * On platforms that are in between DT and non-DT, it breaks registration of > devices via spi_board_info. > Use the same method as 7e6086d9e54a159a6257c02bb7fc5805c614aad2 does for gpios: > Use alias to identify the spi port, and then specify the base via the port id. > If alias is not defined in DT, allocate the base dynamically. This sounds like a fix userspace and/or complete your DT conversion problem...

1 0

[alsa-devel] [PATCH] ASoC: dapm: Use card_list during DAPM shutdown
by Misael Lopez Cruz 09 Nov '12

09 Nov '12

DAPM shutdown incorrectly uses "list" field of codec struct while iterating over probed components (codec_dev_list). "list" field refers to codecs registered in the system, "card_list" field is used for probed components. Signed-off-by: Misael Lopez Cruz <misael.lopez(a)ti.com> Signed-off-by: Liam Girdwood <lrg(a)ti.com> --- sound/soc/soc-dapm.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c index d0a4be3..6e35bca 100644 --- a/sound/soc/soc-dapm.c +++ b/sound/soc/soc-dapm.c @@ -3745,7 +3745,7 @@ void snd_soc_dapm_shutdown(struct snd_soc_card *card) { struct snd_soc_codec *codec; - list_for_each_entry(codec, &card->codec_dev_list, list) { + list_for_each_entry(codec, &card->codec_dev_list, card_list) { soc_dapm_shutdown_codec(&codec->dapm); if (codec->dapm.bias_level == SND_SOC_BIAS_STANDBY) snd_soc_dapm_set_bias_level(&codec->dapm, -- 1.7.4.1

3 3

Re: [alsa-devel] [PATCH 1/1] ASOC: core: Double control update err for snd_soc_put_volsw_sx
by Mark Brown 09 Nov '12

09 Nov '12

On Fri, Nov 09, 2012 at 11:53:40AM +0530, y(a)dbdp33.itg.ti.com wrote: > From: Mukund Navada <navada(a)ti.com> > > snd_soc_put_volsw_sx function fails to update second control > if first control is updated by snd_soc_update_bits_locked. Applied, thanks.

1 0

Re: [alsa-devel] [PATCH 6/6] ASoC: fsl: add imx-wm8974 machine driver
by Mark Brown 09 Nov '12

09 Nov '12

On Fri, Nov 09, 2012 at 03:00:25PM +0100, Steffen Trumtrar wrote: > +static int imx_wm8974_dai_init(struct snd_soc_pcm_runtime *rtd) > +{ > + struct imx_wm8974_data *data = container_of(rtd->card, > + struct imx_wm8974_data, card); > + struct device *dev = rtd->card->dev; > + int ret; > + > + /* the pll stability peaks at N=8 and around 90MHz. > + * This values are best reached with a 12.288MHz or > + * 11.289MHz clock. As the first is closer to N=8 in > + * more situations, chose 12.288MHz as the target clock > + * (ref: datasheet section "Master Clock and Phase Locked Loop")*/ > + ret = snd_soc_dai_set_pll(rtd->codec_dai, 0, 0, data->clk_frequency, > + 12288000); This seems far from ideal - it's starting the PLL at system boot and just leaving it running. This will be power inefficient when the system is not playing audio as the PLL will be consuming power but not used for anything. You could also do the same thing with the MCLK. Note also that a 12.288MHz clock is only suitable for 8kHz based sample rates, for CD audio 44.1kHz based rates like most media files 11.2896MHz should be chosen. The driver may want to switch dynamically at runtime to support the widest possible range of rates. > + data->codec_clk = clk_get(&codec_pdev->dev, NULL); > + if (IS_ERR(data->codec_clk)) { devm_clk_get() - this'd free the clock that's leaked on removal.

1 0

Re: [alsa-devel] [PATCH 4/6] ASoC: wm8974: add SPI as a possible bus master
by Mark Brown 09 Nov '12

09 Nov '12

On Fri, Nov 09, 2012 at 03:55:04PM +0100, Steffen Trumtrar wrote: > On Fri, Nov 09, 2012 at 02:38:42PM +0000, Mark Brown wrote: > > We should be converting things to regmap if we're going to do this - > > we're trying to phase out the ASoC-specific I/O and this makes the code > > simpler anyway as the core will just be able to get the regmap from the > > struct device without bouncing information around through the private > > data and so on. > I wasn't aware of that driver. That sounds way better than the private data stuff. If you look in mainline there's a bunch of conversions been done recently, it's fairly mechanical so hopefully they'll show you what needs doing.

1 0

Re: [alsa-devel] [PATCH 5/6] ARM i.MX: rename ssi1 clock for imx27
by Mark Brown 09 Nov '12

09 Nov '12

On Fri, Nov 09, 2012 at 03:00:24PM +0100, Steffen Trumtrar wrote: > Signed-off-by: Steffen Trumtrar <s.trumtrar(a)pengutronix.de> You don't say anything about why you're renaming here... > - clk_register_clkdev(clk[ssi1_ipg_gate], NULL, "imx-ssi.0"); > + clk_register_clkdev(clk[ssi1_ipg_gate], NULL, "10010000.ssi"); > clk_register_clkdev(clk[ssi2_ipg_gate], NULL, "imx-ssi.1"); I'm guessing this is for DT... why are we only renaming one of the clocks here and will this not break non-DT users?

1 0

Re: [alsa-devel] [PATCH 3/6] ASoC: wm8974: include MCLKDIV in pll_factors
by Mark Brown 09 Nov '12

09 Nov '12

On Fri, Nov 09, 2012 at 03:00:22PM +0100, Steffen Trumtrar wrote: > To calculate the integer part of the frequency ratio, the whole output > path has to be considered (post and pre are optional): > Ndiv = (pre * target * 4 * post) / source > In the current implementation only the fixed- and pre-divider is > considered, but the post-divider is omitted. > To calculate Ndiv, this post divider has to be applied before any > calculation happens. Otherwise Ndiv is considered to be to low in the > later stages. This leads to a wrong value in the PLLN register, which > in turn produces a wrong playback speed of the audio signal. This changelog doesn't mention where you're using MCLKDIV here but it does rather sound like the PLL configuration is not being done correctly here. The expectation is that when the PLL is configured the raw output frequency from the PLL is specified. The PLL is then specified as the system clock with that rate and then any division required to make that usable happens afterwards. > + case WM8974_MCLKDIV_1: > + reg = 1; > + break; Please do follow the Linux coding style for kernel code.

1 0

Re: [alsa-devel] [PATCH 4/6] ASoC: wm8974: add SPI as a possible bus master
by Mark Brown 09 Nov '12

09 Nov '12

On Fri, Nov 09, 2012 at 03:00:23PM +0100, Steffen Trumtrar wrote: > The wm8974 can be controlled via i2c or spi. The current driver only supports > i2c. Add SPI as possible bus. > > As the driver has to distinguish the bus type, pass this info via the wm8974_priv. > This reverts c2562a8e3b5f871ad0b73caf98bb7541e8724efc, because the driver now > needs it back. Don't just quote raw commit IDs, *especially* not full ones, as they're completely illegible to humans. Someone reading the changelog needs to be able to understand what this commit is and why the driver needs it back. > - ret = snd_soc_codec_set_cache_io(codec, 7, 9, SND_SOC_I2C); > + ret = snd_soc_codec_set_cache_io(codec, 7, 9, wm8974->control_type); We should be converting things to regmap if we're going to do this - we're trying to phase out the ASoC-specific I/O and this makes the code simpler anyway as the core will just be able to get the regmap from the struct device without bouncing information around through the private data and so on.

1 0

[alsa-devel] Using sync dapm_sync in stream_event call back
by Babu, Ramesh 09 Nov '12

09 Nov '12

Hi In my machine driver, I need to disable a widget in stream_event call back. I realized that I cannot invoke dapm_sync() inside the stream_event, because it causes recursive lock. How can I disable a pin (widget) inside stream_event call back? Thanks Ramesh

2 3

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

09 Nov '12

On Wed, Nov 07, 2012 at 04:42:41PM +0100, 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. Both of these patches are already applied...

1 0

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

09 Nov '12

On Wed, Nov 07, 2012 at 04:53:17PM +0000, Scott Ling wrote: > Move the firmware load and record parsing functionality out into > a separate function from the boot function. Applied both, thanks.

1 0

[alsa-devel] Linux Kernel-3.5 crashed as dapm is not supported by codec
by Rajeev kumar 09 Nov '12

09 Nov '12

Hello Peter I am working on Linux Kernel-3.5. I have not provided the dapm support in codec. When the system goes in hibernation state it gets crashed. command for putting the system in hibernation: echo disk > /sys/power/state Please find below the crash log Unable to handle kernel NULL pointer dereference at virtual address 00000008 pgd = bd470000 [00000008] *pgd=3d43b831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] SMP ARM Modules linked in: CPU: 1 Not tainted (3.5.0-lsp-3.3.0-rc1 #5) PC is at snd_soc_dapm_shutdown+0x48/0x11c LR is at snd_soc_poweroff+0x68/0x70 pc : [<80372438>] lr : [<8036ccf4>] psr: 00000013 sp : bd5bbd98 ip : bd5bbdc8 fp : bd5bbdc4 r10: 806a6048 r9 : 8044e200 r8 : bd5bbd98 r7 : 807260c4 r6 : bebceec8 r5 : ffffffec r4 : bebcee08 r3 : 00000000 r2 : bebcec10 r1 : 00000000 r0 : 807260c4 Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c53c7d Table: 3d47004a DAC: 00000015 Process disk.sh (pid: 1932, stack limit = 0xbd5ba2f0) Stack: (0xbd5bbd98 to 0xbd5bc000) bd80: bd5bbd98 bd5bbd98 bda0: bd5bbdc4 807260c4 000016b0 00000004 00000000 8024397c bd5bbde4 bd5bbdc8 bdc0: 8036ccf4 803723fc 8036cc8c be9b2808 be9b2808 00000000 bd5bbdf4 bd5bbde8 bde0: 802439bc 8036cc98 bd5bbe2c bd5bbdf8 80247a28 80243988 80435b80 8008fc18 be00: 00000000 00000000 bd5bbe2c be9b2808 00000004 be9b283c 8072359c 00000004 be20: bd5bbe54 bd5bbe30 80248564 802479f8 806a5c98 009b2880 be9b2880 00000000 be40: 806a6008 be9b2808 bd5bbe8c bd5bbe58 80248dac 80248450 3a87fb94 00000023 be60: 3a87fb94 00000023 00000004 806f6e58 00000004 00000005 be863e00 bd4a2918 be80: bd5bbea4 bd5bbe90 80249144 80248cfc 00000001 00000000 bd5bbebc bd5bbea8 bea0: 800590a8 802490e4 00000000 806953ac bd5bbed4 bd5bbec0 800592dc 8005906c bec0: bde8b000 be863f00 bd5bbefc bd5bbed8 80057444 80059194 00000005 be863f00 bee0: bd4a2900 bd5bbf70 be863e00 bd4a2918 bd5bbf0c bd5bbf00 801e5e18 80057394 bf00: bd5bbf3c bd5bbf10 80124f18 801e5e08 bd5bbf70 00000005 bdcd9300 76fc6000 bf20: bd5bbf70 00000000 00000000 00000000 bd5bbf6c bd5bbf40 800cf8b0 80124e0c bf40: 00000000 bde7b500 00000003 bdcd9300 76fc6000 00000005 00000004 00000000 bf60: bd5bbfa4 bd5bbf70 800cfb2c 800cf7f8 00000000 00000000 00000005 00000000 bf80: 00000004 76f87628 00000005 76fc6000 8000e088 bd5ba000 00000000 bd5bbfa8 bfa0: 8000dde0 800cfaec 76f87628 00000005 00000001 76fc6000 00000005 00000000 bfc0: 76f87628 00000005 76fc6000 00000004 00000005 76fc74c0 000b0094 0005dae8 bfe0: 00000005 7e8df7c8 76ed713c 76f1fafc 60000010 00000001 3fffe821 3fffec21 [<80372438>] (snd_soc_dapm_shutdown+0x48/0x11c) from [<8036ccf4>] (snd_soc_poweroff+0x68/0x70) [<8036ccf4>] (snd_soc_poweroff+0x68/0x70) from [<802439bc>] (platform_pm_poweroff+0x40/0x58) [<802439bc>] (platform_pm_poweroff+0x40/0x58) from [<80247a28>] (dpm_run_callback.isra.12+0x3c/0x74) [<80247a28>] (dpm_run_callback.isra.12+0x3c/0x74) from [<80248564>] (__device_suspend+0x120/0x194) [<80248564>] (__device_suspend+0x120/0x194) from [<80248dac>] (dpm_suspend+0xbc/0x224) [<80248dac>] (dpm_suspend+0xbc/0x224) from [<80249144>] (dpm_suspend_start+0x6c/0x74) [<80249144>] (dpm_suspend_start+0x6c/0x74) from [<800590a8>] (hibernation_platform_enter+0x48/0x128) [<800590a8>] (hibernation_platform_enter+0x48/0x128) from [<800592dc>] (hibernate+0x154/0x21c) [<800592dc>] (hibernate+0x154/0x21c) from [<80057444>] (state_store+0xbc/0xd0) [<80057444>] (state_store+0xbc/0xd0) from [<801e5e18>] (kobj_attr_store+0x1c/0x28) [<801e5e18>] (kobj_attr_store+0x1c/0x28) from [<80124f18>] (sysfs_write_file+0x118/0x14c) [<80124f18>] (sysfs_write_file+0x118/0x14c) from [<800cf8b0>] (vfs_write+0xc4/0x140) [<800cf8b0>] (vfs_write+0xc4/0x140) from [<800cfb2c>] (sys_write+0x4c/0x78) [<800cfb2c>] (sys_write+0x4c/0x78) from [<8000dde0>] (ret_fast_syscall+0x0/0x48) Code: e59350f8 e3a03000 e2455014 ea00000f (e595201c) Best Regards Rajeev

4 12

Re: [alsa-devel] [PATCH V6 12/15] ALSA: HDA: Make hda sound card usable for Loongson
by Takashi Iwai 09 Nov '12

09 Nov '12

At Fri, 09 Nov 2012 09:36:34 +0100, John Crispin wrote: > > On 17/08/12 11:09, Takashi Iwai wrote: > > At Fri, 17 Aug 2012 16:43:32 +0800, > > Huacai Chen wrote: > >> > > >> > 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@alsa-project.org > > Looks good. > > Reviewed-by: Takashi Iwai<tiwai(a)suse.de> > > > > Should I apply it to sound git tree or all patches will go through > > mips tree? > > > > > > thanks, > > > > Takashi > > > > > Hi Takashi, > > did you take this patch ? I will queue several of the other patches from > the series for 3.8 and let them go upstream via the mips tree. We have > this patch open in the linux-mips patchwork. I would set it to "Other > Subsystem" if you took it already. Yes, this was already merged in sound git tree for 3.8. thanks, Takashi

1 0

[alsa-devel] [PATCH] ALSA: hda - Removed unused non-standard name "C/LFE"
by David Henningsson 09 Nov '12

09 Nov '12

A closer look shows that the name is not even used and can be removed. Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- sound/pci/hda/patch_via.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/pci/hda/patch_via.c b/sound/pci/hda/patch_via.c index 9ae8cfc..7ae5f85 100644 --- a/sound/pci/hda/patch_via.c +++ b/sound/pci/hda/patch_via.c @@ -1938,7 +1938,7 @@ static int via_auto_create_multi_out_ctls(struct hda_codec *codec) struct auto_pin_cfg *cfg = &spec->autocfg; struct nid_path *path; static const char * const chname[4] = { - "Front", "Surround", "C/LFE", "Side" + "Front", "Surround", NULL /* "CLFE" */, "Side" }; int i, idx, err; int old_line_outs; -- 1.7.9.5

2 1

[alsa-devel] Status of Zoom R16
by Evan Ta 08 Nov '12

08 Nov '12

Hi, as subj says: can you tell me how the Zoom R16 is doing? The hardware looks nice, but the latest info I can find is a seemingly unresolved failure to work with Alsa as of feb 2010. Thanks, Evan

4 6

Re: [alsa-devel] [PATCH 2/2] ARM: davinci: enable SRAM ping ping buffering on DA850
by Arnd Bergmann 08 Nov '12

08 Nov '12

On Thursday 04 October 2012, Matt Porter wrote: > Passes the DA850 shared SRAM gen_pool to the McASP driver > and enables the ping-pong buffer DMA support. > > Signed-off-by: Matt Porter <mporter(a)ti.com> > --- It seems this is in linux-next now, but the patch it depends on (ARM: davinci: add platform hook to fetch the SRAM pool) is not. Arnd

1 0

[alsa-devel] spdif input, source synchronous?
by Rafal Powierski 08 Nov '12

08 Nov '12

Hi Developers, Does anyone know how the SPDIF input is working on HDA? Is it using a source-synchronous data transfer over HDA? In my arrangement (ALC886) I can set up any rate and I am receiving a rectangular “resampling”. – is this a bug? will this stay? so I can use higher ratio and some kind of software PLL to recover input rate? How can I read presence and rate of the signal? Verb – Get Digital Converter Control 1,2 is good thing to have, but I need “carrier-detect” and maybe rate to feed back to Alsa on setup. I hope someone knows this – even if maybe spdif input is not very popular. Regards, Rafal

1 0

[alsa-devel] [RFC PATCH v4 1/2] ASoC: atmel-ssc-dai: register dai and pcm directly
by Bo Shen 08 Nov '12

08 Nov '12

change the method for register dai and pcm - let the atmel-ssc-dai no longer as a standalone platform device - remap ssc and then register dai directly - register pcm from dai directly Modify the code which related with this change Signed-off-by: Bo Shen <voice.shen(a)atmel.com> --- Change since v3 RFC - remap ssc and then register dai and pcm directly Change since v2 - Register dai and pcm directly according to Mark Brown's suggestion - using name to distinguish ssc register for audio or library if for audio, the name with dai subfix if for library, the name without dai subfix - fix the issue for sam9g20-wm8731 - when register dai and pcm cause the sam9g20-wm8731 doesn't work, so fix it - Add device tree support - Detail information reference atmel-ssc-dai.txt binding document Change since v1 No change --- arch/arm/mach-at91/at91sam9260_devices.c | 9 -- arch/arm/mach-at91/board-sam9g20ek.c | 8 +- sound/soc/atmel/atmel-pcm.c | 23 +-- sound/soc/atmel/atmel-pcm.h | 3 + sound/soc/atmel/atmel_ssc_dai.c | 228 +++++++----------------------- sound/soc/atmel/atmel_ssc_dai.h | 1 + sound/soc/atmel/sam9g20_wm8731.c | 13 +- 7 files changed, 76 insertions(+), 209 deletions(-) diff --git a/arch/arm/mach-at91/at91sam9260_devices.c b/arch/arm/mach-at91/at91sam9260_devices.c index df7bebf..6959fd2 100644 --- a/arch/arm/mach-at91/at91sam9260_devices.c +++ b/arch/arm/mach-at91/at91sam9260_devices.c @@ -768,14 +768,6 @@ static inline void configure_ssc_pins(unsigned pins) at91_set_A_periph(AT91_PIN_PB21, 1); } -static struct platform_device at91sam9260_ssc_dai_device = { - .name = "atmel-ssc-dai", - .id = 0, - .dev = { - .parent = &(at91sam9260_ssc_device.dev), - }, -}; - /* * SSC controllers are accessed through library code, instead of any * kind of all-singing/all-dancing driver. For example one could be @@ -800,7 +792,6 @@ void __init at91_add_device_ssc(unsigned id, unsigned pins) } platform_device_register(pdev); - platform_device_register(&at91sam9260_ssc_dai_device); } #else diff --git a/arch/arm/mach-at91/board-sam9g20ek.c b/arch/arm/mach-at91/board-sam9g20ek.c index 5b6a6f9..f3faf54 100644 --- a/arch/arm/mach-at91/board-sam9g20ek.c +++ b/arch/arm/mach-at91/board-sam9g20ek.c @@ -353,19 +353,13 @@ static struct i2c_board_info __initdata ek_i2c_devices[] = { }, }; -static struct platform_device sam9g20ek_pcm_device = { - .name = "atmel-pcm-audio", - .id = -1, -}; - static struct platform_device sam9g20ek_audio_device = { .name = "at91sam9g20ek-audio", - .id = -1, + .id = 0, }; static void __init ek_add_device_audio(void) { - platform_device_register(&sam9g20ek_pcm_device); platform_device_register(&sam9g20ek_audio_device); } diff --git a/sound/soc/atmel/atmel-pcm.c b/sound/soc/atmel/atmel-pcm.c index 9b84f98..40e17d1 100644 --- a/sound/soc/atmel/atmel-pcm.c +++ b/sound/soc/atmel/atmel-pcm.c @@ -473,28 +473,17 @@ static struct snd_soc_platform_driver atmel_soc_platform = { .resume = atmel_pcm_resume, }; -static int __devinit atmel_soc_platform_probe(struct platform_device *pdev) +int atmel_pcm_platform_register(struct device *dev) { - return snd_soc_register_platform(&pdev->dev, &atmel_soc_platform); + return snd_soc_register_platform(dev, &atmel_soc_platform); } +EXPORT_SYMBOL(atmel_pcm_platform_register); -static int __devexit atmel_soc_platform_remove(struct platform_device *pdev) +void atmel_pcm_platform_unregister(struct device *dev) { - snd_soc_unregister_platform(&pdev->dev); - return 0; + snd_soc_unregister_platform(dev); } - -static struct platform_driver atmel_pcm_driver = { - .driver = { - .name = "atmel-pcm-audio", - .owner = THIS_MODULE, - }, - - .probe = atmel_soc_platform_probe, - .remove = __devexit_p(atmel_soc_platform_remove), -}; - -module_platform_driver(atmel_pcm_driver); +EXPORT_SYMBOL(atmel_pcm_platform_unregister); MODULE_AUTHOR("Sedji Gaouaou <sedji.gaouaou(a)atmel.com>"); MODULE_DESCRIPTION("Atmel PCM module"); diff --git a/sound/soc/atmel/atmel-pcm.h b/sound/soc/atmel/atmel-pcm.h index 5e0a95e..e6d67b3 100644 --- a/sound/soc/atmel/atmel-pcm.h +++ b/sound/soc/atmel/atmel-pcm.h @@ -80,4 +80,7 @@ struct atmel_pcm_dma_params { #define ssc_readx(base, reg) (__raw_readl((base) + (reg))) #define ssc_writex(base, reg, value) __raw_writel((value), (base) + (reg)) +int atmel_pcm_platform_register(struct device *dev); +void atmel_pcm_platform_unregister(struct device *dev); + #endif /* _ATMEL_PCM_H */ diff --git a/sound/soc/atmel/atmel_ssc_dai.c b/sound/soc/atmel/atmel_ssc_dai.c index 354341e..4435e19 100644 --- a/sound/soc/atmel/atmel_ssc_dai.c +++ b/sound/soc/atmel/atmel_ssc_dai.c @@ -47,13 +47,6 @@ #include "atmel-pcm.h" #include "atmel_ssc_dai.h" - -#if defined(CONFIG_ARCH_AT91SAM9260) || defined(CONFIG_ARCH_AT91SAM9G20) -#define NUM_SSC_DEVICES 1 -#else -#define NUM_SSC_DEVICES 3 -#endif - /* * SSC PDC registers required by the PCM DMA engine. */ @@ -96,63 +89,24 @@ static struct atmel_ssc_mask ssc_rx_mask = { /* * DMA parameters. */ -static struct atmel_pcm_dma_params ssc_dma_params[NUM_SSC_DEVICES][2] = { - {{ - .name = "SSC0 PCM out", - .pdc = &pdc_tx_reg, - .mask = &ssc_tx_mask, - }, +static struct atmel_pcm_dma_params ssc_dma_params[2] = { { - .name = "SSC0 PCM in", - .pdc = &pdc_rx_reg, - .mask = &ssc_rx_mask, - } }, -#if NUM_SSC_DEVICES == 3 - {{ - .name = "SSC1 PCM out", + .name = "SSC PCM out", .pdc = &pdc_tx_reg, .mask = &ssc_tx_mask, }, { - .name = "SSC1 PCM in", + .name = "SSC PCM in", .pdc = &pdc_rx_reg, .mask = &ssc_rx_mask, - } }, - {{ - .name = "SSC2 PCM out", - .pdc = &pdc_tx_reg, - .mask = &ssc_tx_mask, }, - { - .name = "SSC2 PCM in", - .pdc = &pdc_rx_reg, - .mask = &ssc_rx_mask, - } }, -#endif }; - -static struct atmel_ssc_info ssc_info[NUM_SSC_DEVICES] = { - { - .name = "ssc0", - .lock = __SPIN_LOCK_UNLOCKED(ssc_info[0].lock), - .dir_mask = SSC_DIR_MASK_UNUSED, - .initialized = 0, - }, -#if NUM_SSC_DEVICES == 3 - { - .name = "ssc1", - .lock = __SPIN_LOCK_UNLOCKED(ssc_info[1].lock), +static struct atmel_ssc_info ssc_info = { + .name = "ssc", + .lock = __SPIN_LOCK_UNLOCKED(ssc_info.lock), .dir_mask = SSC_DIR_MASK_UNUSED, .initialized = 0, - }, - { - .name = "ssc2", - .lock = __SPIN_LOCK_UNLOCKED(ssc_info[2].lock), - .dir_mask = SSC_DIR_MASK_UNUSED, - .initialized = 0, - }, -#endif }; @@ -205,7 +159,7 @@ static irqreturn_t atmel_ssc_interrupt(int irq, void *dev_id) static int atmel_ssc_startup(struct snd_pcm_substream *substream, struct snd_soc_dai *dai) { - struct atmel_ssc_info *ssc_p = &ssc_info[dai->id]; + struct atmel_ssc_info *ssc_p = &ssc_info; int dir_mask; pr_debug("atmel_ssc_startup: SSC_SR=0x%u\n", @@ -234,7 +188,7 @@ static int atmel_ssc_startup(struct snd_pcm_substream *substream, static void atmel_ssc_shutdown(struct snd_pcm_substream *substream, struct snd_soc_dai *dai) { - struct atmel_ssc_info *ssc_p = &ssc_info[dai->id]; + struct atmel_ssc_info *ssc_p = &ssc_info; struct atmel_pcm_dma_params *dma_params; int dir, dir_mask; @@ -285,7 +239,7 @@ static void atmel_ssc_shutdown(struct snd_pcm_substream *substream, static int atmel_ssc_set_dai_fmt(struct snd_soc_dai *cpu_dai, unsigned int fmt) { - struct atmel_ssc_info *ssc_p = &ssc_info[cpu_dai->id]; + struct atmel_ssc_info *ssc_p = &ssc_info; ssc_p->daifmt = fmt; return 0; @@ -297,7 +251,7 @@ static int atmel_ssc_set_dai_fmt(struct snd_soc_dai *cpu_dai, static int atmel_ssc_set_dai_clkdiv(struct snd_soc_dai *cpu_dai, int div_id, int div) { - struct atmel_ssc_info *ssc_p = &ssc_info[cpu_dai->id]; + struct atmel_ssc_info *ssc_p = &ssc_info; switch (div_id) { case ATMEL_SSC_CMR_DIV: @@ -336,8 +290,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream, struct snd_soc_dai *dai) { struct snd_soc_pcm_runtime *rtd = snd_pcm_substream_chip(substream); - int id = dai->id; - struct atmel_ssc_info *ssc_p = &ssc_info[id]; + struct atmel_ssc_info *ssc_p = &ssc_info; struct atmel_pcm_dma_params *dma_params; int dir, channels, bits; u32 tfmr, rfmr, tcmr, rcmr; @@ -354,7 +307,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream, else dir = 1; - dma_params = &ssc_dma_params[id][dir]; + dma_params = &ssc_dma_params[dir]; dma_params->ssc = ssc_p->ssc; dma_params->substream = substream; @@ -603,7 +556,7 @@ static int atmel_ssc_hw_params(struct snd_pcm_substream *substream, static int atmel_ssc_prepare(struct snd_pcm_substream *substream, struct snd_soc_dai *dai) { - struct atmel_ssc_info *ssc_p = &ssc_info[dai->id]; + struct atmel_ssc_info *ssc_p = &ssc_info; struct atmel_pcm_dma_params *dma_params; int dir; @@ -631,7 +584,7 @@ static int atmel_ssc_suspend(struct snd_soc_dai *cpu_dai) if (!cpu_dai->active) return 0; - ssc_p = &ssc_info[cpu_dai->id]; + ssc_p = &ssc_info; /* Save the status register before disabling transmit and receive */ ssc_p->ssc_state.ssc_sr = ssc_readl(ssc_p->ssc->regs, SR); @@ -660,7 +613,7 @@ static int atmel_ssc_resume(struct snd_soc_dai *cpu_dai) if (!cpu_dai->active) return 0; - ssc_p = &ssc_info[cpu_dai->id]; + ssc_p = &ssc_info; /* restore SSC register settings */ ssc_writel(ssc_p->ssc->regs, TFMR, ssc_p->ssc_state.ssc_tfmr); @@ -689,28 +642,10 @@ static int atmel_ssc_resume(struct snd_soc_dai *cpu_dai) static int atmel_ssc_probe(struct snd_soc_dai *dai) { - struct atmel_ssc_info *ssc_p = &ssc_info[dai->id]; - int ret = 0; + struct atmel_ssc_info *ssc_p = &ssc_info; snd_soc_dai_set_drvdata(dai, ssc_p); - /* - * Request SSC device - */ - ssc_p->ssc = ssc_request(dai->id); - if (IS_ERR(ssc_p->ssc)) { - printk(KERN_ERR "ASoC: Failed to request SSC %d\n", dai->id); - ret = PTR_ERR(ssc_p->ssc); - } - - return ret; -} - -static int atmel_ssc_remove(struct snd_soc_dai *dai) -{ - struct atmel_ssc_info *ssc_p = snd_soc_dai_get_drvdata(dai); - - ssc_free(ssc_p->ssc); return 0; } @@ -728,11 +663,8 @@ static const struct snd_soc_dai_ops atmel_ssc_dai_ops = { .set_clkdiv = atmel_ssc_set_dai_clkdiv, }; -static struct snd_soc_dai_driver atmel_ssc_dai[NUM_SSC_DEVICES] = { - { - .name = "atmel-ssc-dai.0", +static struct snd_soc_dai_driver atmel_ssc_dai = { .probe = atmel_ssc_probe, - .remove = atmel_ssc_remove, .suspend = atmel_ssc_suspend, .resume = atmel_ssc_resume, .playback = { @@ -746,69 +678,37 @@ static struct snd_soc_dai_driver atmel_ssc_dai[NUM_SSC_DEVICES] = { .rates = ATMEL_SSC_RATES, .formats = ATMEL_SSC_FORMATS,}, .ops = &atmel_ssc_dai_ops, - }, -#if NUM_SSC_DEVICES == 3 - { - .name = "atmel-ssc-dai.1", - .probe = atmel_ssc_probe, - .remove = atmel_ssc_remove, - .suspend = atmel_ssc_suspend, - .resume = atmel_ssc_resume, - .playback = { - .channels_min = 1, - .channels_max = 2, - .rates = ATMEL_SSC_RATES, - .formats = ATMEL_SSC_FORMATS,}, - .capture = { - .channels_min = 1, - .channels_max = 2, - .rates = ATMEL_SSC_RATES, - .formats = ATMEL_SSC_FORMATS,}, - .ops = &atmel_ssc_dai_ops, - }, - { - .name = "atmel-ssc-dai.2", - .probe = atmel_ssc_probe, - .remove = atmel_ssc_remove, - .suspend = atmel_ssc_suspend, - .resume = atmel_ssc_resume, - .playback = { - .channels_min = 1, - .channels_max = 2, - .rates = ATMEL_SSC_RATES, - .formats = ATMEL_SSC_FORMATS,}, - .capture = { - .channels_min = 1, - .channels_max = 2, - .rates = ATMEL_SSC_RATES, - .formats = ATMEL_SSC_FORMATS,}, - .ops = &atmel_ssc_dai_ops, - }, -#endif }; -static __devinit int asoc_ssc_probe(struct platform_device *pdev) +static int asoc_ssc_init(struct device *dev) { - BUG_ON(pdev->id < 0); - BUG_ON(pdev->id >= ARRAY_SIZE(atmel_ssc_dai)); - return snd_soc_register_dai(&pdev->dev, &atmel_ssc_dai[pdev->id]); -} + int ret; + + ret = snd_soc_register_dai(dev, &atmel_ssc_dai); + if (ret) { + dev_err(dev, "Could not register DAI: %d\n", ret); + goto err; + } + + ret = atmel_pcm_platform_register(dev); + if (ret) { + dev_err(dev, "Could not register PCM: %d\n", ret); + goto err_unregister_dai; + }; -static int __devexit asoc_ssc_remove(struct platform_device *pdev) -{ - snd_soc_unregister_dai(&pdev->dev); return 0; -} -static struct platform_driver asoc_ssc_driver = { - .driver = { - .name = "atmel-ssc-dai", - .owner = THIS_MODULE, - }, +err_unregister_dai: + snd_soc_unregister_dai(dev); +err: + return ret; +} - .probe = asoc_ssc_probe, - .remove = __devexit_p(asoc_ssc_remove), -}; +static void asoc_ssc_exit(struct device *dev) +{ + atmel_pcm_platform_unregister(dev); + snd_soc_unregister_dai(dev); +} /** * atmel_ssc_set_audio - Allocate the specified SSC for audio use. @@ -816,50 +716,32 @@ 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; - if (ssc_id < 0 || ssc_id >= ARRAY_SIZE(atmel_ssc_dai)) - return -EINVAL; - - /* Allocate a dummy device for DMA if we don't have one already */ - if (!dma_pdev) { - dma_pdev = platform_device_alloc("atmel-pcm-audio", -1); - if (!dma_pdev) - return -ENOMEM; - - ret = platform_device_add(dma_pdev); - if (ret < 0) { - platform_device_put(dma_pdev); - dma_pdev = NULL; - return ret; - } - } - - ssc_pdev = platform_device_alloc("atmel-ssc-dai", ssc_id); - if (!ssc_pdev) - return -ENOMEM; - /* If we can grab the SSC briefly to parent the DAI device off it */ ssc = ssc_request(ssc_id); - if (IS_ERR(ssc)) - pr_warn("Unable to parent ASoC SSC DAI on SSC: %ld\n", + if (IS_ERR(ssc)) { + pr_err("Unable to parent ASoC SSC DAI on SSC: %ld\n", PTR_ERR(ssc)); - else { - ssc_pdev->dev.parent = &(ssc->pdev->dev); - ssc_free(ssc); + return PTR_ERR(ssc); + } else { + ssc_info.ssc = ssc; } - ret = platform_device_add(ssc_pdev); - if (ret < 0) - platform_device_put(ssc_pdev); + ret = asoc_ssc_init(&ssc->pdev->dev); return ret; } EXPORT_SYMBOL_GPL(atmel_ssc_set_audio); -module_platform_driver(asoc_ssc_driver); +void atmel_ssc_put_audio(void) +{ + struct ssc_device *ssc = ssc_info.ssc; + + ssc_free(ssc); + asoc_ssc_exit(&ssc->pdev->dev); +} +EXPORT_SYMBOL_GPL(atmel_ssc_put_audio); /* Module information */ MODULE_AUTHOR("Sedji Gaouaou, sedji.gaouaou(a)atmel.com, www.atmel.com"); diff --git a/sound/soc/atmel/atmel_ssc_dai.h b/sound/soc/atmel/atmel_ssc_dai.h index 5d4f0f9..70c66dd 100644 --- a/sound/soc/atmel/atmel_ssc_dai.h +++ b/sound/soc/atmel/atmel_ssc_dai.h @@ -118,5 +118,6 @@ struct atmel_ssc_info { }; int atmel_ssc_set_audio(int ssc); +void atmel_ssc_put_audio(void); #endif /* _AT91_SSC_DAI_H */ diff --git a/sound/soc/atmel/sam9g20_wm8731.c b/sound/soc/atmel/sam9g20_wm8731.c index 228ca6a..eef6eed 100644 --- a/sound/soc/atmel/sam9g20_wm8731.c +++ b/sound/soc/atmel/sam9g20_wm8731.c @@ -179,10 +179,10 @@ static int at91sam9g20ek_wm8731_init(struct snd_soc_pcm_runtime *rtd) static struct snd_soc_dai_link at91sam9g20ek_dai = { .name = "WM8731", .stream_name = "WM8731 PCM", - .cpu_dai_name = "atmel-ssc-dai.0", + .cpu_dai_name = "at91rm9200_ssc.0", .codec_dai_name = "wm8731-hifi", .init = at91sam9g20ek_wm8731_init, - .platform_name = "atmel-pcm-audio", + .platform_name = "at91rm9200_ssc.0", .codec_name = "wm8731.0-001b", .ops = &at91sam9g20ek_ops, }; @@ -204,6 +204,10 @@ static int __devinit at91sam9g20ek_audio_probe(struct platform_device *pdev) if (!(machine_is_at91sam9g20ek() || machine_is_at91sam9g20ek_2mmc())) return -ENODEV; + ret = atmel_ssc_set_audio(pdev->id); + if (ret) + goto err; + /* * Codec MCLK is supplied by PCK0 - set it up. */ @@ -211,7 +215,7 @@ static int __devinit at91sam9g20ek_audio_probe(struct platform_device *pdev) if (IS_ERR(mclk)) { printk(KERN_ERR "ASoC: Failed to get MCLK\n"); ret = PTR_ERR(mclk); - goto err; + goto err_ssc_put_audio; } pllb = clk_get(NULL, "pllb"); @@ -240,6 +244,8 @@ static int __devinit at91sam9g20ek_audio_probe(struct platform_device *pdev) err_mclk: clk_put(mclk); mclk = NULL; +err_ssc_put_audio: + atmel_ssc_put_audio(); err: return ret; } @@ -248,6 +254,7 @@ static int __devexit at91sam9g20ek_audio_remove(struct platform_device *pdev) { struct snd_soc_card *card = platform_get_drvdata(pdev); + atmel_ssc_put_audio(); snd_soc_unregister_card(card); clk_put(mclk); mclk = NULL; -- 1.7.9.5

1 1

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

08 Nov '12

Hi J, On 11/7/2012 23:16, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 15:44 Wed 07 Nov , Mark Brown wrote: >> 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. > for where it's merge honestly I do not care much but the pinctrl must be > handled correctly I will send patches to add pinctrl support. For atmel ssc driver, it is simple, however for dtsi, which point should I based on? which git and which branch? Because, I am not sure which branch on git://github.com/at91linux/linux-at91.git is the right point. Thanks. Best Regards, Bo Shen > Best Regards, > J. > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel(a)lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel >

1 0

[alsa-devel] [PATCH 0/1] HDSPM RME RayDAT sync reporting
by Adrian Knoth 07 Nov '12

07 Nov '12

Hi! This patch is supposed to be applied on top of my recent series of patches (60e952bdb537c72dea4484711c9cc00383f78393). Cheers Adrian Knoth (1): ALSA: hdspm - Fix sync check reporting on RME RayDAT sound/pci/rme9652/hdspm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 1.7.10.4

2 4

[alsa-devel] Fix for Asus G75 notebook subwoofer
by Massimo Del Fedele 07 Nov '12

07 Nov '12

This code fixes surround path of asus G75; i'll drop here as a function to be called before codec initialization (I did it in static int patch_vt2002P() ) because I don't know how to detect the notebook and apply it only when needed (I'm new to alsa code). /* Fixes for Asus G75 subwoofer pin 24 is marked as speaker by bios -- should mark as line pin 33 has a wrong connection to out-of-range nid #3e */ static int fix_asus_g75_subwoofer(struct hda_codec *codec) { /* right connection to pin widget #33 */ hda_nid_t conn[8] = {0x1c}; unsigned int conf; /* Fix connection of pin widget #33 on VT1802p * reported connection (33-1e) refers to non-existent widget #1e which in turn * reports a connection to #1c; we skip nonexistent 1e widget landing directly * on 1c one */ snd_hda_override_conn_list(codec, 0x33, 1, conn); // pin 24 should be marked as line out pin (not speaker as in bios) // and as AC_JACK_PORT_COMPLEX connection to avoid to be taken by autoparser as a speaker conf = snd_hda_codec_get_pincfg(codec, 0x24); conf = conf & ~AC_DEFCFG_DEVICE; conf = (conf & ~AC_DEFCFG_PORT_CONN) | (AC_JACK_PORT_COMPLEX << AC_DEFCFG_PORT_CONN_SHIFT); snd_hda_codec_set_pincfg(codec, 0x24, conf); // pin 33 should be marked as line out pin (not speaker as in bios) // and as AC_JACK_PORT_COMPLEX, not AC_JACK_PORT_NONE as in bios conf = snd_hda_codec_get_pincfg(codec, 0x33); conf = conf & ~AC_DEFCFG_DEVICE; conf = (conf & ~AC_DEFCFG_PORT_CONN) | (AC_JACK_PORT_COMPLEX << AC_DEFCFG_PORT_CONN_SHIFT); snd_hda_codec_set_pincfg(codec, 0x33, conf); return 0; } I guess that the fix on NID #33 should be applied anyways on VT1802p, because by now it connects to a non-existing widget (well, it does exist but is not documented and out of NID range; it should be a stereo-to-mono mixer). BTW, also NID #34, which has 2 connections, has one of them to non-existing nid above; in my case it does no harm : Widget #24 -- ANALOG STEREO PIN COMPLEX Input from widgets : 14 3e <-- widget 3e is out of range, but connects to 1c widget Connection type : JACK Device : LINE OUT Does NOT support unsolicited response Out amp present In amp NOT present Ciao Max

3 23

Re: [alsa-devel] [PATCH -next] ASoC: cs42l52: fix the return value of cs42l52_set_fmt()
by Mark Brown 07 Nov '12

07 Nov '12

On Wed, Nov 07, 2012 at 08:38:35PM +0800, Wei Yongjun wrote: > From: Wei Yongjun <yongjun_wei(a)trendmicro.com.cn> > > Fix the return value of cs42l52_set_fmt() when clock inversion is > not allowed and also remove the useless variable ret. Applied, but you need to work on your changelogs: What is wrong with the return value? > u8 iface = 0; > > switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) { > @@ -822,7 +821,7 @@ static int cs42l52_set_fmt(struct snd_soc_dai *codec_dai, unsigned int fmt) > case SND_SOC_DAIFMT_NB_IF: > break; > default: > - ret = -EINVAL; > + return -EINVAL; > } > cs42l52->config.format = iface; > snd_soc_write(codec, CS42L52_IFACE_CTL1, cs42l52->config.format); > This doesn't look like it changes the return value... the actual issue here is that we don't pay attention to ret later on, we just always return 0.

1 0

[alsa-devel] [PATCH] ASoC: bells: Correct type in sub speaker DAI name for WM5102
by Charles Keepax 07 Nov '12

07 Nov '12

Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> --- sound/soc/samsung/bells.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/sound/soc/samsung/bells.c b/sound/soc/samsung/bells.c index 3d7ace7..b135de0 100644 --- a/sound/soc/samsung/bells.c +++ b/sound/soc/samsung/bells.c @@ -287,7 +287,7 @@ static struct snd_soc_dai_link bells_dai_wm5102[] = { { .name = "Sub", .stream_name = "Sub", - .cpu_dai_name = "wm5110-aif3", + .cpu_dai_name = "wm5102-aif3", .codec_dai_name = "wm9081-hifi", .codec_name = "wm9081.1-006c", .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF -- 1.7.2.5

2 1

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 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-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 28 Oct '12

28 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 22 Oct '12

22 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