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

[alsa-devel] [PATCH 3/3 v2] ASoC: TSCS42xx: Add CCF support to get sysclk
by Steven Eckhoff 27 Mar '18

27 Mar '18

The TSCS42xx relies on set_sysclk to get a unique clock id and rate, which prevents it from being used with the simple-card. Remove set_sysclk callback Add CCF support to get clock id and rate Add clocks and clock-names to device tree binding Signed-off-by: Steven Eckhoff <steven.eckhoff.opensource(a)gmail.com> --- .../devicetree/bindings/sound/tscs42xx.txt | 6 ++ sound/soc/codecs/tscs42xx.c | 104 ++++++++++++++------- sound/soc/codecs/tscs42xx.h | 2 +- 3 files changed, 75 insertions(+), 37 deletions(-) diff --git a/Documentation/devicetree/bindings/sound/tscs42xx.txt b/Documentation/devicetree/bindings/sound/tscs42xx.txt index 2ac2f0996697..7eea32e9d078 100644 --- a/Documentation/devicetree/bindings/sound/tscs42xx.txt +++ b/Documentation/devicetree/bindings/sound/tscs42xx.txt @@ -8,9 +8,15 @@ Required Properties: - reg : <0x71> for analog mic <0x69> for digital mic + - clock-names: Must one of the following "mclk1", "xtal", "mclk2" + + - clocks: phandle of the clock that provides the codec sysclk + Example: wookie: codec@69 { compatible = "tempo,tscs42A2"; reg = <0x69>; + clock-names = "xtal"; + clocks = <&audio_xtal>; }; diff --git a/sound/soc/codecs/tscs42xx.c b/sound/soc/codecs/tscs42xx.c index d41852a37ac6..69cd4c1ed1d6 100644 --- a/sound/soc/codecs/tscs42xx.c +++ b/sound/soc/codecs/tscs42xx.c @@ -12,6 +12,7 @@ #include <linux/module.h> #include <linux/delay.h> #include <linux/mutex.h> +#include <linux/clk.h> #include <sound/tlv.h> #include <sound/pcm_params.h> #include <sound/soc.h> @@ -40,6 +41,9 @@ struct tscs42xx { struct mutex pll_lock; struct regmap *regmap; + + struct clk *sysclk; + int sysclk_src_id; }; struct coeff_ram_ctl { @@ -1251,13 +1255,46 @@ static int tscs42xx_set_dai_bclk_ratio(struct snd_soc_dai *codec_dai, return 0; } -static int tscs42xx_set_dai_sysclk(struct snd_soc_dai *codec_dai, - int clk_id, unsigned int freq, int dir) +static const struct snd_soc_dai_ops tscs42xx_dai_ops = { + .hw_params = tscs42xx_hw_params, + .mute_stream = tscs42xx_mute_stream, + .set_fmt = tscs42xx_set_dai_fmt, + .set_bclk_ratio = tscs42xx_set_dai_bclk_ratio, +}; + +static int part_is_valid(struct tscs42xx *tscs42xx) { - struct snd_soc_component *component = codec_dai->component; + int val; int ret; + unsigned int reg; + + ret = regmap_read(tscs42xx->regmap, R_DEVIDH, &reg); + if (ret < 0) + return ret; - switch (clk_id) { + val = reg << 8; + ret = regmap_read(tscs42xx->regmap, R_DEVIDL, &reg); + if (ret < 0) + return ret; + + val |= reg; + + switch (val) { + case 0x4A74: + case 0x4A73: + return true; + default: + return false; + }; +} + +static int set_sysclk(struct snd_soc_component *component) +{ + struct tscs42xx *tscs42xx = snd_soc_component_get_drvdata(component); + unsigned long freq; + int ret; + + switch (tscs42xx->sysclk_src_id) { case TSCS42XX_PLL_SRC_XTAL: case TSCS42XX_PLL_SRC_MCLK1: ret = snd_soc_component_write(component, R_PLLREFSEL, @@ -1285,6 +1322,7 @@ static int tscs42xx_set_dai_sysclk(struct snd_soc_dai *codec_dai, return -EINVAL; } + freq = clk_get_rate(tscs42xx->sysclk); ret = set_pll_ctl_from_input_freq(component, freq); if (ret < 0) { dev_err(component->dev, @@ -1295,41 +1333,13 @@ static int tscs42xx_set_dai_sysclk(struct snd_soc_dai *codec_dai, return 0; } -static const struct snd_soc_dai_ops tscs42xx_dai_ops = { - .hw_params = tscs42xx_hw_params, - .mute_stream = tscs42xx_mute_stream, - .set_fmt = tscs42xx_set_dai_fmt, - .set_bclk_ratio = tscs42xx_set_dai_bclk_ratio, - .set_sysclk = tscs42xx_set_dai_sysclk, -}; - -static int part_is_valid(struct tscs42xx *tscs42xx) +static int tscs42xx_probe(struct snd_soc_component *component) { - int val; - int ret; - unsigned int reg; - - ret = regmap_read(tscs42xx->regmap, R_DEVIDH, &reg); - if (ret < 0) - return ret; - - val = reg << 8; - ret = regmap_read(tscs42xx->regmap, R_DEVIDL, &reg); - if (ret < 0) - return ret; - - val |= reg; - - switch (val) { - case 0x4A74: - case 0x4A73: - return true; - default: - return false; - }; + return set_sysclk(component); } static const struct snd_soc_component_driver soc_codec_dev_tscs42xx = { + .probe = tscs42xx_probe, .dapm_widgets = tscs42xx_dapm_widgets, .num_dapm_widgets = ARRAY_SIZE(tscs42xx_dapm_widgets), .dapm_routes = tscs42xx_intercon, @@ -1387,11 +1397,15 @@ static const struct reg_sequence tscs42xx_patch[] = { { R_AIC2, RV_AIC2_BLRCM_DAC_BCLK_LRCLK_SHARED }, }; +static char const * const src_names[TSCS42XX_PLL_SRC_CNT] = { + "xtal", "mclk1", "mclk2"}; + static int tscs42xx_i2c_probe(struct i2c_client *i2c, const struct i2c_device_id *id) { struct tscs42xx *tscs42xx; - int ret = 0; + int src; + int ret; tscs42xx = devm_kzalloc(&i2c->dev, sizeof(*tscs42xx), GFP_KERNEL); if (!tscs42xx) { @@ -1402,6 +1416,24 @@ static int tscs42xx_i2c_probe(struct i2c_client *i2c, } i2c_set_clientdata(i2c, tscs42xx); + for (src = TSCS42XX_PLL_SRC_XTAL; src < TSCS42XX_PLL_SRC_CNT; src++) { + tscs42xx->sysclk = devm_clk_get(&i2c->dev, src_names[src]); + if (!IS_ERR(tscs42xx->sysclk)) { + break; + } else if (PTR_ERR(tscs42xx->sysclk) != -ENOENT) { + ret = PTR_ERR(tscs42xx->sysclk); + dev_err(&i2c->dev, "Failed to get sysclk (%d)\n", ret); + return ret; + } + } + if (src > TSCS42XX_PLL_SRC_CNT) { + ret = -EINVAL; + dev_err(&i2c->dev, "Failed to get a valid clock name (%d)\n", + ret); + return ret; + } + tscs42xx->sysclk_src_id = src; + tscs42xx->regmap = devm_regmap_init_i2c(i2c, &tscs42xx_regmap); if (IS_ERR(tscs42xx->regmap)) { ret = PTR_ERR(tscs42xx->regmap); diff --git a/sound/soc/codecs/tscs42xx.h b/sound/soc/codecs/tscs42xx.h index d4a30bcbf64b..814c8f3c4a68 100644 --- a/sound/soc/codecs/tscs42xx.h +++ b/sound/soc/codecs/tscs42xx.h @@ -7,10 +7,10 @@ #define __WOOKIE_H__ enum { - TSCS42XX_PLL_SRC_NONE, TSCS42XX_PLL_SRC_XTAL, TSCS42XX_PLL_SRC_MCLK1, TSCS42XX_PLL_SRC_MCLK2, + TSCS42XX_PLL_SRC_CNT, }; #define R_HPVOLL 0x0 -- 2.15.1

1 0

[alsa-devel] No audio on Lenovo Miix 320
by Freaky 27 Mar '18

27 Mar '18

Hi there, we're having some issues getting the audio working on a Lenovo Miix 320. On some forums they say it should work after blacklisting snd_hdmi_lpe_audio. Have blacklisted this, and there's one audio card less now, but still no go unfortunately. Currently running with 4.15.10 from Fedora 27. It logs a lot of: "Audio Port: ASoC: no backend DAIs enabled for Audio Port" lines. Any ideas on how to troubleshoot this? Saw similar problems in https://bugzilla.kernel.org/show_bug.cgi?id=96691 but this seems to be for another codec/DAI. Also, their system seems to be a Baytrail Atom, this is a Cherrytrail. Not sure if any of the patches are applicable. dmesg is attached. I can patch, build and test kernels. Coding is another story however :). Any help is appreciated. Kind regards,

2 1

[alsa-devel] [PATCH] ALSA: usb-audio: fix memory leak on cval
by Colin King 27 Mar '18

27 Mar '18

From: Colin Ian King <colin.king(a)canonical.com> With the current exit return path of the ctl_info allocation failure cval is not being freed resulting in a memory leak. Fix this by kfree'ing it on the return. Detected by CoverityScan, CID#1466878 ("Resource Leak") Fixes: 21e9b3e931f7 ("ALSA: usb-audio: fix uac control query argument") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- sound/usb/mixer.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c index 04dab6f65535..301ad61ed426 100644 --- a/sound/usb/mixer.c +++ b/sound/usb/mixer.c @@ -1365,8 +1365,10 @@ static void build_feature_ctl(struct mixer_build *state, void *raw_desc, cval->cmask = ctl_mask; ctl_info = get_feature_control_info(control); - if (!ctl_info) + if (!ctl_info) { + kfree(cval); return; + } if (state->mixer->protocol == UAC_VERSION_1) cval->val_type = ctl_info->type; else /* UAC_VERSION_2 */ -- 2.15.1

2 1

Re: [alsa-devel] [PATCH] [sound] hdac-codec runtime suspended at PM:Suspend.
by Subhransu S. Prusty 27 Mar '18

27 Mar '18

On Thu, Mar 15, 2018 at 09:02:30PM +0530, Anshuman Gupta wrote: > On Thu, Mar 15, 2018 at 04:12:44PM +0530, Subhransu S. Prusty wrote: > > On Wed, Mar 14, 2018 at 09:07:14PM +0530, Anshuman Gupta wrote: > > > On Wed, Mar 14, 2018 at 11:53:58AM +0100, Rafael J. Wysocki wrote: > > > > On Wed, Mar 14, 2018 at 11:38 AM, Anshuman Gupta > > > > <anshuman.gupta(a)intel.com> wrote: > > > > > On Mon, Mar 12, 2018 at 12:26:53PM +0100, Rafael J. Wysocki wrote: > > > > >> On Mon, Mar 12, 2018 at 12:17 PM, Anshuman Gupta > > > > >> <anshuman.gupta(a)intel.com> wrote: > > > > >> > > > > > >> > + if (pm_runtime_status_suspended(dev)) > > > > >> > + return; > > > > >> > > > > >> That, again, is somewhat fragile from the concurrency perspective. > > > > >> > > > > > > > > And here you want to avoid the below if the device is still suspended. > > > Yes, if we do not avoid the code below, complete callback takes about > > > 3 seconds due to snd_hdac_codec_read timed out because hdac controller > > > would be in runtime suspend state. > > > > > > > > Why is the below code located in the ->complete callback anyway? > > > > Shouldn't it be there in the ->resume one? > > > > > > > Yes even i am also having same doubt, why these power down and power up > > > sequences are part of prepare and complete callback. > > > Adding driver author "Subhransu S. Prusty" to provide more inputs on this. > > > > This driver needs a late resume as it receives a jack notification from the > > i915 driver and the skl controller driver resume may not have happened and > > in turn hda controller may not ready. This ensures a synchronization for > > jack event during resume from S3. > Let me give you insight of the issue, this driver blocks the direct complete > of hda controller PCI 00:1f.3, sometimes it takes 280ms to resume hda controller > from S3 and s2idle. So it does not make sense to suspend/resume hda controller > when it is already in runtime suspend. I get it now. I think this patch needs rework to address both the issues. > > > > I think this patch defeats the purpose. > Here in this case PCI driver may kick the direct complete for hda controller > https://elixir.bootlin.com/linux/latest/source/drivers/pci/pci-driver.c#L691 > But hdac hdmi codec driver is blocking it. > So i think it will be ok to keep this codec and hda controller in runtime > suspend while entering S3 or s2idle, both can resume by runtime PM as well, > will it brake any audio functionality? There was some PM and jack detection issues (I don't recollect now) because of which this was added. This was due to the gfx display power and hda controller synchronization. The rework may be required in both hdac_hdmi and skylake drivers. Regards, Subhransu > > > > Regards, > > Subhransu > > > > > > >> > /* Power up afg */ > > > > >> > snd_hdac_codec_read(hdac, hdac->afg, 0, AC_VERB_SET_POWER_STATE, > > > > >> > AC_PWRST_D0); > > > > >> > -- > > > > >> > 2.7.4 > > > > > > -- > > > Thanks, > > > Anshuman > > > > -- > > -- > Thanks, > Anshuman --

3 2

[alsa-devel] [bug report] ALSA: pcm: Return -EBUSY for OSS ioctls changing busy streams
by Dan Carpenter 27 Mar '18

27 Mar '18

Hello Takashi Iwai, The patch 40cab6e88cb0: "ALSA: pcm: Return -EBUSY for OSS ioctls changing busy streams" from Mar 23, 2018, leads to the following static checker warning: sound/core/oss/pcm_oss.c:1741 snd_pcm_oss_set_rate() warn: inconsistent returns 'mutex:&runtime->oss.params_lock'. Locked on: line 1734 Unlocked on: line 1732 line 1741 sound/core/oss/pcm_oss.c 1717 static int snd_pcm_oss_set_rate(struct snd_pcm_oss_file *pcm_oss_file, int rate) 1718 { 1719 int idx; 1720 1721 for (idx = 1; idx >= 0; --idx) { 1722 struct snd_pcm_substream *substream = pcm_oss_file->streams[idx]; 1723 struct snd_pcm_runtime *runtime; 1724 if (substream == NULL) 1725 continue; 1726 runtime = substream->runtime; 1727 if (rate < 1000) 1728 rate = 1000; 1729 else if (rate > 192000) 1730 rate = 192000; 1731 if (mutex_lock_interruptible(&runtime->oss.params_lock)) 1732 return -ERESTARTSYS; 1733 if (atomic_read(&runtime->oss.rw_ref)) 1734 return -EBUSY; ^^^^^^^^^^^^^ Unlock before returning? 1735 if (runtime->oss.rate != rate) { 1736 runtime->oss.params = 1; 1737 runtime->oss.rate = rate; 1738 } 1739 mutex_unlock(&runtime->oss.params_lock); 1740 } 1741 return snd_pcm_oss_get_rate(pcm_oss_file); 1742 } regards, dan carpenter

2 2

[alsa-devel] [PATCH] ALSA: pcm: potential uninitialized return values
by Dan Carpenter 27 Mar '18

27 Mar '18

Smatch complains that "tmp" can be uninitialized if we do a zero size write. Fixes: 02a5d6925cd3 ("ALSA: pcm: Avoid potential races between OSS ioctls and read/write") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> diff --git a/sound/core/oss/pcm_oss.c b/sound/core/oss/pcm_oss.c index a9082f219561..40852c595453 100644 --- a/sound/core/oss/pcm_oss.c +++ b/sound/core/oss/pcm_oss.c @@ -1364,7 +1364,7 @@ static ssize_t snd_pcm_oss_write2(struct snd_pcm_substream *substream, const cha static ssize_t snd_pcm_oss_write1(struct snd_pcm_substream *substream, const char __user *buf, size_t bytes) { size_t xfer = 0; - ssize_t tmp; + ssize_t tmp = 0; struct snd_pcm_runtime *runtime = substream->runtime; if (atomic_read(&substream->mmap_count)) @@ -1474,7 +1474,7 @@ static ssize_t snd_pcm_oss_read2(struct snd_pcm_substream *substream, char *buf, static ssize_t snd_pcm_oss_read1(struct snd_pcm_substream *substream, char __user *buf, size_t bytes) { size_t xfer = 0; - ssize_t tmp; + ssize_t tmp = 0; struct snd_pcm_runtime *runtime = substream->runtime; if (atomic_read(&substream->mmap_count))

2 1

[alsa-devel] Disable DAPM for click avoidance ?
by Ricard Wanderlof 27 Mar '18

27 Mar '18

I'm having an issue with a codec where the normal DAPM procedure of disabling most of the codec when there is no stream ongoing results in large clicks when a playback stream starts and stops, because the output jumps from 0V when the output is disabled to over a volt when the output is enabled. There appears to be a 'slow stop/start' feature in the codec, however, it takes about one second to ramp up and down the output voltage, and that is too long a delay when starting a stream. In our usecase the power consumtion of the codec is negligable compared to the rest of the electronics, so leaving the codec running at all times is perfectly feasible. Is there any way from a machine driver to disable the DAPM switching, i.e. leave parts of the codec running at all times? In this specific case, there are two internal PM controls which enable the output. One of them is controlled by an output mixer element (SND_SOC_DAPM_MIXER_E), and the other one from set_bias_level(). I've had a look in the core code, but it seems that the whole business of changing the bias level when a stream is started is always performed and that there is no way to say "Set the bias level to ON and leave it there". An alternative would be to augment the codec driver with an 'always on' feature, which effectively always enables PM for certain parts of the chip. But it seems like the wrong place to do this type of thing. Another use for this feature is that we have had a lot of problems over the years with buggy I2S interfaces misbehaving when streams are started and stopped, and there would be an advantage to letting the AIF run the whole time after startup. /Ricard -- Ricard Wolf Wanderlöf ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30

2 11

[alsa-devel] [PATCH v2 0/3] ASoC: Add Multi CPU DAI support
by Shreyas NC 27 Mar '18

27 Mar '18

As discussed in [1], ASoC core supports multi codec DAIs on a DAI link. However it does not do so for CPU DAIs. So, add support for multi CPU DAIs on a DAI Link by adding multi CPU DAI in Card instantiation, suspend and resume functions, PCM ops, stream handling functions and DAPM. [1]: https://www.spinics.net/lists/alsa-devel/msg71369.html Changes in v2: - Addressed review comments by Charles - Rebased on latest for-next branch Shreyas NC (3): ASoC: Add initial support for multiple CPU DAIs ASoC: Add Multi CPU DAI support for PCM ops ASoC: Add Multi CPU DAI support in DAPM include/sound/soc.h | 5 + sound/soc/soc-core.c | 283 ++++++++++++++++++++---------- sound/soc/soc-dapm.c | 71 +++++--- sound/soc/soc-pcm.c | 483 +++++++++++++++++++++++++++++++++------------------ 4 files changed, 564 insertions(+), 278 deletions(-) -- 2.7.4

1 3

[alsa-devel] [PATCH] ALSA: aloop: Mark paused device as inactive
by Robert Rosengren 27 Mar '18

27 Mar '18

Show paused ALSA aloop device as inactive, i.e. the control "PCM Slave Active" set as false. Notification sent upon state change. This makes it possible for client capturing from aloop device to know if data is expected. Without it the client expects data even if playback is paused. Signed-off-by: Robert Rosengren <robertr(a)axis.com> --- sound/drivers/aloop.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/sound/drivers/aloop.c b/sound/drivers/aloop.c index 0333143a1fa7..5404ab11132d 100644 --- a/sound/drivers/aloop.c +++ b/sound/drivers/aloop.c @@ -291,6 +291,8 @@ static int loopback_trigger(struct snd_pcm_substream *substream, int cmd) cable->pause |= stream; loopback_timer_stop(dpcm); spin_unlock(&cable->lock); + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + loopback_active_notify(dpcm); break; case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: case SNDRV_PCM_TRIGGER_RESUME: @@ -299,6 +301,8 @@ static int loopback_trigger(struct snd_pcm_substream *substream, int cmd) cable->pause &= ~stream; loopback_timer_start(dpcm); spin_unlock(&cable->lock); + if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) + loopback_active_notify(dpcm); break; default: return -EINVAL; @@ -879,9 +883,11 @@ static int loopback_active_get(struct snd_kcontrol *kcontrol, [kcontrol->id.subdevice][kcontrol->id.device ^ 1]; unsigned int val = 0; - if (cable != NULL) - val = (cable->running & (1 << SNDRV_PCM_STREAM_PLAYBACK)) ? - 1 : 0; + if (cable != NULL) { + unsigned int running = cable->running ^ cable->pause; + + val = (running & (1 << SNDRV_PCM_STREAM_PLAYBACK)) ? 1 : 0; + } ucontrol->value.integer.value[0] = val; return 0; } -- 2.11.0

2 3

[alsa-devel] Question about cpu_dai/codec_dai unbalance
by Kuninori Morimoto 27 Mar '18

27 Mar '18

Hi Mark, ALSA ML Now, I'm investigating cpu_dai/codec_dai, and I noticed there are many unbalance. For example, snd_soc_suspend(), it calls .digital_mute() only for codec_dai, not for cpc_dai, and, calls .suspend() only for cpu_dai, not for codec_dai. It seems there are many unbalance like this on ALSA SoC. I know it is case-by-case, but I think we can have more balance. For example above snd_soc_suspend() case, .digital_mute() is very common for both cpu/codec I think, and, codec can have .suspend() ? But what do you think ? I think it doesn't breaks current system, because each cpu_dai doesn't have .digital_mute(), and codec_dai doesn't have .suspend() for now. Thus, nothing happen if I added it. The reason why I'm asking is that now, I'm thinking to merge cpu_dai/codec_dai into one dai list somehow. This means, we can have non-categorized DAI, this is same as previous codec/platform replacement into component. Then, this kind of DAI unbalance might be problem. Best regards --- Kuninori Morimoto

1 0