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

[alsa-devel] [PATCH V2 0/6] Add support for the WM8280 and WM8281 codecs
by Richard Fitzgerald 26 Nov '14

26 Nov '14

This set of patches adds support for the WM8280 and WM8281 codecs to the Wolfson Arizona drivers. Only change since V1 series is update to device tree binding documentation in patch 2 Richard Fitzgerald (6): mfd: arizona: add support for WM8280/WM8281 Documentation: devicetree: arizona: Add bindings for WM8280 regulator: arizona-micsupp: Add support for WM8280/WM8281 gpio: arizona: Add support for WM8280/WM8281 extcon: arizona: Add support for WM8280/WM8281 ASoC: arizona: Add support for WM8280/WM8281 Documentation/devicetree/bindings/mfd/arizona.txt | 15 +++++++++++---- drivers/extcon/extcon-arizona.c | 1 + drivers/gpio/gpio-arizona.c | 1 + drivers/mfd/Kconfig | 5 +++-- drivers/mfd/arizona-core.c | 14 ++++++++++++-- drivers/mfd/arizona-i2c.c | 2 ++ drivers/mfd/arizona-irq.c | 1 + drivers/mfd/arizona-spi.c | 2 ++ drivers/regulator/arizona-micsupp.c | 1 + include/linux/mfd/arizona/core.h | 1 + sound/soc/codecs/arizona.c | 2 ++ 11 files changed, 37 insertions(+), 8 deletions(-) -- 1.7.2.5

2 7

[alsa-devel] Where to find Alsa experienced programmer?
by Andrej Falout 25 Nov '14

25 Nov '14

Hello, I have a client that would like to hire services of an skilled programmer with Alsa related experience, for a particular project contract task. They advertised locally, but came up with nothing, which is probably not a big surprise. They have accepted remote/online working as an option. Could anyone suggest the appropriate method/place to seek such a person? Any suggestions gratefully received. Kind regards, Andrej Falout

2 1

Re: [alsa-devel] [PATCH 26/29] ALSA: oxfw: Add support AMDTP in-stream
by Clemens Ladisch 25 Nov '14

25 Nov '14

Takashi Sakamoto wrote: > On Nov 24 2014 22:54, Clemens Ladisch wrote: >> In theory, it would be possible to use atomic_t to synchronize multiple >> streams, but this requires that >> 1. two CPUs that start a stream at the same time do not both think they >> are the first, ... and >> 2. when one CPU is still starting a stream, code on all other CPUs must >> be able to work correctly, without synchronization. [...] > > If I rewrite your pseudo code, like this: > >> void start_some_substream(...) >> { >> if (atomic_inc_and_test(substreams)) { >> mutex_lock(); >> // lots of stuff to start DMA ... > > if (wait_for_first_packet() == ETIMEDOUT) { > stop_dma(); > release_streams(); > mutex_unlock(); > return ETIMEDOUT; > } >> mutex_unlock(); >> } >> ... >> } This is an even better example of why atomic_t is incorrect: when the startup fails, the second call to start_some_substream() at the same time, which just sees that substreams>0, cannot notice the error, and thinks its own substream has been started successfully. Regards, Clemens

2 1

Re: [alsa-devel] [PATCH v3] ASoC: Remove 'const' from the device_node pointers
by Mark Brown 25 Nov '14

25 Nov '14

On Tue, Nov 25, 2014 at 12:14:48PM +0100, Jean-Francois Moine wrote: > As Russell King's explained it, there should not be pointers to > struct device_node: OK, found a user that needs this so applying now. Please do try to make your changelogs clearer about why things are being done, it's often hard to figure things out which slows everything down.

1 0

[alsa-devel] Remove my address from alsa-devel@alsa-project,org
by John Houston 25 Nov '14

25 Nov '14

jbhdbr(a)gmail.com Sent from my iPhone

1 0

[alsa-devel] [PATCH] ASoC: Disable regmap helpers if regmap is disabled
by Lars-Peter Clausen 25 Nov '14

25 Nov '14

If regmap is disabled there will be no users of the ASoC regmap helpers. Furthermore regmap_exit() will no be defined causing the following compile error: sound/soc/soc-core.c: In function 'snd_soc_component_exit_regmap': sound/soc/soc-core.c:2645:2: error: implicit declaration of function 'regmap_exit' [-Werror=implicit-function-declaration] So disable the helpers if regmap is disabled. Reported-by: kbuild test robot <fengguang.wu(a)intel.com> Fixes: 20feb881988c ASoC: Add helper functions for deferred regmap setup") Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- include/sound/soc.h | 4 ++++ sound/soc/soc-core.c | 4 ++++ 2 files changed, 8 insertions(+) diff --git a/include/sound/soc.h b/include/sound/soc.h index 879e2b3..4cef90cc 100644 --- a/include/sound/soc.h +++ b/include/sound/soc.h @@ -1283,6 +1283,8 @@ void snd_soc_component_async_complete(struct snd_soc_component *component); int snd_soc_component_test_bits(struct snd_soc_component *component, unsigned int reg, unsigned int mask, unsigned int value); +#ifdef CONFIG_REGMAP + void snd_soc_component_init_regmap(struct snd_soc_component *component, struct regmap *regmap); void snd_soc_component_exit_regmap(struct snd_soc_component *component); @@ -1318,6 +1320,8 @@ static inline void snd_soc_codec_exit_regmap(struct snd_soc_codec *codec) snd_soc_component_exit_regmap(&codec->component); } +#endif + /* device driver data */ static inline void snd_soc_card_set_drvdata(struct snd_soc_card *card, diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index cc52ea1..7904eda 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -2612,6 +2612,8 @@ static void snd_soc_component_setup_regmap(struct snd_soc_component *component) component->val_bytes = val_bytes; } +#ifdef CONFIG_REGMAP + /** * snd_soc_component_init_regmap() - Initialize regmap instance for the component * @component: The component for which to initialize the regmap instance @@ -2647,6 +2649,8 @@ void snd_soc_component_exit_regmap(struct snd_soc_component *component) } EXPORT_SYMBOL_GPL(snd_soc_component_exit_regmap); +#endif + static void snd_soc_component_add_unlocked(struct snd_soc_component *component) { if (!component->write && !component->read) { -- 1.8.0

2 1

[alsa-devel] [PATCH] ASoC: qi_lb60: Pass flags to gpiod_get()
by Lars-Peter Clausen 25 Nov '14

25 Nov '14

Pass flags to gpiod_get() to automatically configure the GPIOs. This is shorter and not passing any flags to gpiod_get() will eventually no longer be supported. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- sound/soc/jz4740/qi_lb60.c | 11 ++--------- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/sound/soc/jz4740/qi_lb60.c b/sound/soc/jz4740/qi_lb60.c index 5cb91f9..0fb7d2a 100644 --- a/sound/soc/jz4740/qi_lb60.c +++ b/sound/soc/jz4740/qi_lb60.c @@ -77,25 +77,18 @@ static int qi_lb60_probe(struct platform_device *pdev) { struct qi_lb60 *qi_lb60; struct snd_soc_card *card = &qi_lb60_card; - int ret; qi_lb60 = devm_kzalloc(&pdev->dev, sizeof(*qi_lb60), GFP_KERNEL); if (!qi_lb60) return -ENOMEM; - qi_lb60->snd_gpio = devm_gpiod_get(&pdev->dev, "snd"); + qi_lb60->snd_gpio = devm_gpiod_get(&pdev->dev, "snd", GPIOD_OUT_LOW); if (IS_ERR(qi_lb60->snd_gpio)) return PTR_ERR(qi_lb60->snd_gpio); - ret = gpiod_direction_output(qi_lb60->snd_gpio, 0); - if (ret) - return ret; - qi_lb60->amp_gpio = devm_gpiod_get(&pdev->dev, "amp"); + qi_lb60->amp_gpio = devm_gpiod_get(&pdev->dev, "amp", GPIOD_OUT_LOW); if (IS_ERR(qi_lb60->amp_gpio)) return PTR_ERR(qi_lb60->amp_gpio); - ret = gpiod_direction_output(qi_lb60->amp_gpio, 0); - if (ret) - return ret; card->dev = &pdev->dev; -- 1.7.10.4

2 1

[alsa-devel] [PATCH] alsa-lib: Fix assorted tstamp_type bugs/omissions.
by Tim Cussins 25 Nov '14

25 Nov '14

Just a couple of quick fixes related to tstamp_type. - snd_pcm_sw_params(): copy tstamp_type field - snd_pcm_tstamp_type_name(): fix argument type - snd_pcm_dump_sw_setup(): fix dumping of tstamp_type field --- src/pcm/pcm.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c index 3904256..baa47c7 100644 --- a/src/pcm/pcm.c +++ b/src/pcm/pcm.c @@ -897,6 +897,7 @@ int snd_pcm_sw_params(snd_pcm_t *pcm, snd_pcm_sw_params_t *params) if (err < 0) return err; pcm->tstamp_mode = params->tstamp_mode; + pcm->tstamp_type = params->tstamp_type; pcm->period_step = params->period_step; pcm->avail_min = params->avail_min; pcm->period_event = sw_get_period_event(params); @@ -1843,7 +1844,7 @@ const char *snd_pcm_tstamp_mode_name(snd_pcm_tstamp_t mode) * \param mode PCM tstamp type * \return ascii name of PCM tstamp type setting */ -const char *snd_pcm_tstamp_type_name(snd_pcm_tstamp_t type) +const char *snd_pcm_tstamp_type_name(snd_pcm_tstamp_type_t type) { if (type > SND_PCM_TSTAMP_TYPE_LAST) return NULL; @@ -1924,7 +1925,7 @@ int snd_pcm_dump_sw_setup(snd_pcm_t *pcm, snd_output_t *out) return -EIO; } snd_output_printf(out, " tstamp_mode : %s\n", snd_pcm_tstamp_mode_name(pcm->tstamp_mode)); - snd_output_printf(out, " tstamp_type : %s\n", snd_pcm_tstamp_type_name(pcm->tstamp_mode)); + snd_output_printf(out, " tstamp_type : %s\n", snd_pcm_tstamp_type_name(pcm->tstamp_type)); snd_output_printf(out, " period_step : %d\n", pcm->period_step); snd_output_printf(out, " avail_min : %ld\n", pcm->avail_min); snd_output_printf(out, " period_event : %i\n", pcm->period_event); -- 1.7.10.4

2 1

[alsa-devel] Cache issue on BayTrail (ValleyView2) HD-audio
by Takashi Iwai 25 Nov '14

25 Nov '14

Hi Mengdong, right now I'm playing onboard HD-audio on a Baytrail (ValleyView2) machine, not DP/HDMI output, and I noticed that the snooping doesn't seem working with this. The playback sometimes stutters / gets noises. This is a typical behavior with caching mismatch and indeed it works when I disable snooping via snoop=0 option. Could you check whether this can be seen generically? Also, can anyone check whether snoop=0 for Baytrail HD-audio causes any issues? In general, snoop=0 isn't too bad (IIRC, Windows does it as default), so we can turn it off at least for Baytrail as default. thanks, Takashi

1 1

Re: [alsa-devel] [PATCH v3] ASoC: Remove 'const' from the device_node pointers
by Mark Brown 25 Nov '14

25 Nov '14

On Tue, Nov 25, 2014 at 12:14:48PM +0100, Jean-Francois Moine wrote: > As Russell King's explained it, there should not be pointers to > struct device_node: > > "struct device_node is a ref-counted structure. That means if you > store a reference to it, you should "get" it, and you should "put" > it once you've done. The act of "put"ing the pointed-to structure > involves writing to that structure, so it is totally unappropriate > to store a device_node structure as a const pointer. It forces you > to have to cast it back to a non-const pointer at various points > in time to use various OF function calls." So, we're not holding references here (we're just doing comparisons, the references need to be owned before we get into the core) and I'm not seeing anything here removing casts?

2 2