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

[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