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

Re: [alsa-devel] Enable HP machine to enable capture mute led and output mute led
by Takashi Iwai 30 Jun '14

30 Jun '14

At Fri, 20 Jun 2014 15:55:58 +0800, Kailang wrote: > > Hi Takashi, > > Maybe you don't receive. > I repost again. Don't worry, it's been applied now. I've been off for a few days. thanks, Takashi > > BR, > Kailang > > > > Attach again. > > It include below infomations. > > Thanks. > > > >> At Wed, 18 Jun 2014 17:13:57 +0800, > >> Kailang wrote: > >>> > >>> Hi Takashi, > >>> > >>> Attach was HP mute led support patch. > >>> It use Line1 vref and Mic1 vref to control mute led for ALC282. > >>> Line1 vref to control output mute led. > >>> Mic1 vref to control input mute led. > >>> > >>> It use GPIO3 and Mic1 vref to control mute led for ALC280. > >>> GPIO3 to control output mute led. > >>> Mic1 vref to control input mute led. > >> > >> Could you include this kind of information in the patch changelog? > >> The changelog text is way too short. > >> > >>> For the DMI string for output mute led application. > >>> I already request from HP to support it in next release. > >>> > >>> HP_Mute_LED_0_A => use Mic1 vref to control mute led. > >>> Is the string right? > >>> I have tested upper string for Mic1 mute led. > >> > >> Yes, this has been working for some machines, AFAIK. > >> > >> > >> thanks, > >> > >> Takashi > >> > >> ------Please consider the environment before printing this e-mail. > [2 0001-new-hp-mute-led.patch <application/octet-stream (quoted-printable)>] >

2 1

[alsa-devel] Constant delay between starting a playback and a capture stream
by Max Schmidt 30 Jun '14

30 Jun '14

Hi all, I first wrote this email to the ALSA user mailing list since I didn't know if it's appropriate to write to the ALSA dev list as I'm not directly involved in the project. I was suggested to better try it here. So, I'm sorry if this email is an inconvenience. See below my original post. Thanks and greetings! Gesendet: Montag, 23. Juni 2014 um 18:20 Uhr Von: "Max Schmidt" <schmidti444(a)web.de> An: alsa-user(a)lists.sourceforge.net Betreff: Constant delay between starting a playback and a capture stream Hey all, first a big hello to everyone since I'm new to this mailing-list. I've had a look regarding this issue here and in generell in the internet but didn't find anything relating. So, sorry if I overlooked something. I've got a BeagleBone Black (ARM Cortex A 8 µP) with an Audio-Cape (using McAsp and ALSA-Davinci-Drivers) and wrote an mmap based playback-capture application (both devices "hw:0,0"). The important thing is that the application needs a constant delay (not necessarily small) between the start of the playback and the capture stream. So when looping back the signal to the microfone the first played sample e.g. always (even after a restart of the BeagleBone or the app) has a delay in the capture stream of exactly 80 samples (when e.g. played with 48 kHz), and once measured can be seen as constant. To realize that I use the ALSA API function "snd_pcm_link(c_handle, p_handle)". When starting the playback stream (and therefore linked capture stream as welll) manually its buffer already is filled. There is no buffer underrun/overrun recovery. It already works quite fine but I still have some questions and it would be really nice if someone can help: 1) Looking at a plot of multiple measurements of looped back and captured square waves (or sines) there still is a jitter of about two to four samples (at 48 kHz; which is about 40 to 80 ms), no matter if I run it as RT-app (energy save modes etc. disabled, just important Processes have a higher Priority e.g. EDMA) or normal app. Please correct me if I'm wrong, but as far as I understand when the streams are linked, at start the processor is going through a linked list triggering all linked streams. And the trigger start is an atomic process so shouldn't get interrupted. Shouldn't it always take the same time between starting the playback and capture stream then? And if yes, where could the variable start delay come from? 2) Looking at the time stamp of both streams it tells that the difference between the start trigger normally is between 2 to 7 ms. What, I think, does not really fit to the observation written above since then there normally should be no big sample jitter at 48 kHz. Are the time stamp values not precise enough (actually how precise are the time stamps, just that they can show microseconds does not imply that the resolution really is microseconds, or am I wrong?) or are they correct and the difference in latency seen in measured plots comes from somewhere else? Delay due to Hardware should be constant so the issue must have something to do with ALSA or Linux. Would be nice if someone can help or has an idea! Tipps for an improvement are wlecome as well! Many thanks and cheers!

2 2

[alsa-devel] [PATCH 1/2] ASoC: max98090: Add max98091 compatible string
by Tushar Behera 30 Jun '14

30 Jun '14

From: Wonjoon Lee <woojoo.lee(a)samsung.com> The MAX98091 CODEC is the same as MAX98090 CODEC, but with an extra microphone. Existing driver for MAX98090 CODEC already has support for MAX98091 CODEC. Adding proper compatible string so that MAX98091 CODEC can be specified from device tree. Signed-off-by: Wonjoon Lee <woojoo.lee(a)samsung.com> Signed-off-by: Doug Anderson <dianders(a)chromium.org> Signed-off-by: Tushar Behera <tushar.b(a)samsung.com> --- Picked from https://chromium-review.googlesource.com/#/c/184091/ .../devicetree/bindings/sound/max98090.txt | 2 +- sound/soc/codecs/max98090.c | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/sound/max98090.txt b/Documentation/devicetree/bindings/sound/max98090.txt index a5e63fa..c454e67 100644 --- a/Documentation/devicetree/bindings/sound/max98090.txt +++ b/Documentation/devicetree/bindings/sound/max98090.txt @@ -4,7 +4,7 @@ This device supports I2C only. Required properties: -- compatible : "maxim,max98090". +- compatible : "maxim,max98090" or "maxim,max98091". - reg : The I2C address of the device. diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c index f5fccc7..4f5534d 100644 --- a/sound/soc/codecs/max98090.c +++ b/sound/soc/codecs/max98090.c @@ -2460,12 +2460,14 @@ static const struct dev_pm_ops max98090_pm = { static const struct i2c_device_id max98090_i2c_id[] = { { "max98090", MAX98090 }, + { "max98091", MAX98091 }, { } }; MODULE_DEVICE_TABLE(i2c, max98090_i2c_id); static const struct of_device_id max98090_of_match[] = { { .compatible = "maxim,max98090", }, + { .compatible = "maxim,max98091", }, { } }; MODULE_DEVICE_TABLE(of, max98090_of_match); -- 1.7.9.5

4 6

[alsa-devel] [PATCH RFC/RFT] ASoC: rt5677: Convert to use rl6231_pll_calc
by Axel Lin 30 Jun '14

30 Jun '14

The implementation of rt5677_pll_calc() has the same logic of rl6231_pll_calc(). The only difference is the lower boundary checking for freq_in. This patch calls rl6231_pll_calc() instead of open-coded. The k_bp of struct rt5677_pll_code is always false, thus also remove the code to check pll_code.k_bp. Signed-off-by: Axel Lin <axel.lin(a)ingics.com> --- Hi Oder, This patch removes the usage of k_bp from struct rt5677_pll_code because it is always false. I think if k_bp is necessay in the further development, maybe it's better to add it to rl6231_pll_code. How do you think? Regards, Axel sound/soc/codecs/rt5677.c | 69 ++++++----------------------------------------- sound/soc/codecs/rt5677.h | 8 ------ 2 files changed, 8 insertions(+), 69 deletions(-) diff --git a/sound/soc/codecs/rt5677.c b/sound/soc/codecs/rt5677.c index 45f99a8..e7c401f 100644 --- a/sound/soc/codecs/rt5677.c +++ b/sound/soc/codecs/rt5677.c @@ -2988,62 +2988,12 @@ static int rt5677_set_dai_sysclk(struct snd_soc_dai *dai, * Returns 0 for success or negative error code. */ static int rt5677_pll_calc(const unsigned int freq_in, - const unsigned int freq_out, struct rt5677_pll_code *pll_code) + const unsigned int freq_out, struct rl6231_pll_code *pll_code) { - int max_n = RT5677_PLL_N_MAX, max_m = RT5677_PLL_M_MAX; - int k, red, n_t, pll_out, in_t; - int n = 0, m = 0, m_t = 0; - int out_t, red_t = abs(freq_out - freq_in); - bool m_bp = false, k_bp = false; - - if (RT5677_PLL_INP_MAX < freq_in || RT5677_PLL_INP_MIN > freq_in) + if (RT5677_PLL_INP_MIN > freq_in) return -EINVAL; - k = 100000000 / freq_out - 2; - if (k > RT5677_PLL_K_MAX) - k = RT5677_PLL_K_MAX; - for (n_t = 0; n_t <= max_n; n_t++) { - in_t = freq_in / (k + 2); - pll_out = freq_out / (n_t + 2); - if (in_t < 0) - continue; - if (in_t == pll_out) { - m_bp = true; - n = n_t; - goto code_find; - } - red = abs(in_t - pll_out); - if (red < red_t) { - m_bp = true; - n = n_t; - m = m_t; - if (red == 0) - goto code_find; - red_t = red; - } - for (m_t = 0; m_t <= max_m; m_t++) { - out_t = in_t / (m_t + 2); - red = abs(out_t - pll_out); - if (red < red_t) { - m_bp = false; - n = n_t; - m = m_t; - if (red == 0) - goto code_find; - red_t = red; - } - } - } - pr_debug("Only get approximation about PLL\n"); - -code_find: - - pll_code->m_bp = m_bp; - pll_code->k_bp = k_bp; - pll_code->m_code = m; - pll_code->n_code = n; - pll_code->k_code = k; - return 0; + return rl6231_pll_calc(freq_in, freq_out, pll_code); } static int rt5677_set_dai_pll(struct snd_soc_dai *dai, int pll_id, int source, @@ -3051,7 +3001,7 @@ static int rt5677_set_dai_pll(struct snd_soc_dai *dai, int pll_id, int source, { struct snd_soc_codec *codec = dai->codec; struct rt5677_priv *rt5677 = snd_soc_codec_get_drvdata(codec); - struct rt5677_pll_code pll_code; + struct rl6231_pll_code pll_code; int ret; if (source == rt5677->pll_src && freq_in == rt5677->pll_in && @@ -3109,15 +3059,12 @@ static int rt5677_set_dai_pll(struct snd_soc_dai *dai, int pll_id, int source, return ret; } - dev_dbg(codec->dev, "m_bypass=%d k_bypass=%d m=%d n=%d k=%d\n", - pll_code.m_bp, pll_code.k_bp, - (pll_code.m_bp ? 0 : pll_code.m_code), pll_code.n_code, - (pll_code.k_bp ? 0 : pll_code.k_code)); + dev_dbg(codec->dev, "m_bypass=%d m=%d n=%d k=%d\n", + pll_code.m_bp, (pll_code.m_bp ? 0 : pll_code.m_code), + pll_code.n_code, pll_code.k_code); regmap_write(rt5677->regmap, RT5677_PLL1_CTRL1, - pll_code.n_code << RT5677_PLL_N_SFT | - pll_code.k_bp << RT5677_PLL_K_BP_SFT | - (pll_code.k_bp ? 0 : pll_code.k_code)); + pll_code.n_code << RT5677_PLL_N_SFT | pll_code.k_code); regmap_write(rt5677->regmap, RT5677_PLL1_CTRL2, (pll_code.m_bp ? 0 : pll_code.m_code) << RT5677_PLL_M_SFT | pll_code.m_bp << RT5677_PLL_M_BP_SFT); diff --git a/sound/soc/codecs/rt5677.h b/sound/soc/codecs/rt5677.h index af4e9c7..08252e7 100644 --- a/sound/soc/codecs/rt5677.h +++ b/sound/soc/codecs/rt5677.h @@ -1425,14 +1425,6 @@ enum { RT5677_AIFS, }; -struct rt5677_pll_code { - bool m_bp; /* Indicates bypass m code or not. */ - bool k_bp; /* Indicates bypass k code or not. */ - int m_code; - int n_code; - int k_code; -}; - struct rt5677_priv { struct snd_soc_codec *codec; struct rt5677_platform_data pdata; -- 1.8.3.2

3 2

[alsa-devel] [PATCH] ASoC: davinci-mcasp: Fix S24_LE and U24_LE support
by Peter Ujfalusi 30 Jun '14

30 Jun '14

In case of S24_LE/U24_LE modes we expect 24bits on the bus while the samples are stored and transferred in memory on 32bits (lower 3 bytes of the 4 bytes). Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- sound/soc/davinci/davinci-mcasp.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/sound/soc/davinci/davinci-mcasp.c b/sound/soc/davinci/davinci-mcasp.c index 9afb14629a17..6d5de26eae2f 100644 --- a/sound/soc/davinci/davinci-mcasp.c +++ b/sound/soc/davinci/davinci-mcasp.c @@ -720,6 +720,10 @@ static int davinci_mcasp_hw_params(struct snd_pcm_substream *substream, case SNDRV_PCM_FORMAT_U24_LE: case SNDRV_PCM_FORMAT_S24_LE: + dma_params->data_type = 4; + word_length = 24; + break; + case SNDRV_PCM_FORMAT_U32_LE: case SNDRV_PCM_FORMAT_S32_LE: dma_params->data_type = 4; -- 2.0.0

3 2

[alsa-devel] [PATCH 1/2] ASoC: tlv320aic3x: Correct S24_3LE support
by Peter Ujfalusi 30 Jun '14

30 Jun '14

Correct the hw_params callback to configure the codec correctly in case of S24_3LE format since in case of S24_3LE the codec has been configured to 16bit format mode. S24_LE is not defined as supported format for the codec. Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)ti.com> --- sound/soc/codecs/tlv320aic3x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c index e12fafbb1e09..5360772bc1ad 100644 --- a/sound/soc/codecs/tlv320aic3x.c +++ b/sound/soc/codecs/tlv320aic3x.c @@ -879,7 +879,7 @@ static int aic3x_hw_params(struct snd_pcm_substream *substream, case SNDRV_PCM_FORMAT_S20_3LE: data |= (0x01 << 4); break; - case SNDRV_PCM_FORMAT_S24_LE: + case SNDRV_PCM_FORMAT_S24_3LE: data |= (0x02 << 4); break; case SNDRV_PCM_FORMAT_S32_LE: -- 2.0.0

2 2

[alsa-devel] [PATCH] ASoC: rt5640: add ASRC support
by bardliao＠realtek.com 30 Jun '14

30 Jun '14

From: Bard Liao <bardliao(a)realtek.com> This patch add ASRC support for rt5640 series codecs. Signed-off-by: Bard Liao <bardliao(a)realtek.com> --- sound/soc/codecs/rt5640.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++- sound/soc/codecs/rt5640.h | 2 ++ 2 files changed, 80 insertions(+), 1 deletion(-) diff --git a/sound/soc/codecs/rt5640.c b/sound/soc/codecs/rt5640.c index 6bc6efd..3245ec4 100644 --- a/sound/soc/codecs/rt5640.c +++ b/sound/soc/codecs/rt5640.c @@ -341,6 +341,43 @@ static bool rt5640_readable_register(struct device *dev, unsigned int reg) } } +static const char * const rt5640_asrc_mode[] = { + "disable", "enable" +}; + +static const SOC_ENUM_SINGLE_DECL(rt5640_asrc_enum, SND_SOC_NOPM, + 0, rt5640_asrc_mode); + +static int rt5640_asrc_put(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol); + struct rt5640_priv *rt5640 = snd_soc_codec_get_drvdata(codec); + + rt5640->asrc_en = ucontrol->value.integer.value[0]; + + if (rt5640->asrc_en) { + snd_soc_update_bits(codec, RT5640_DUMMY1, 0x70, 0x70); + snd_soc_update_bits(codec, RT5640_JD_CTRL, 0x3, 0x3); + } else { + snd_soc_update_bits(codec, RT5640_DUMMY1, 0x70, 0x0); + snd_soc_update_bits(codec, RT5640_JD_CTRL, 0x3, 0x0); + } + + return 0; +} + +static int rt5640_asrc_get(struct snd_kcontrol *kcontrol, + struct snd_ctl_elem_value *ucontrol) +{ + struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol); + struct rt5640_priv *rt5640 = snd_soc_codec_get_drvdata(codec); + + ucontrol->value.enumerated.item[0] = rt5640->asrc_en; + + return 0; +} + static const DECLARE_TLV_DB_SCALE(out_vol_tlv, -4650, 150, 0); static const DECLARE_TLV_DB_SCALE(dac_vol_tlv, -65625, 375, 0); static const DECLARE_TLV_DB_SCALE(in_vol_tlv, -3450, 150, 0); @@ -436,6 +473,10 @@ static const struct snd_kcontrol_new rt5640_snd_controls[] = { SOC_ENUM("DAC IF1 Data Switch", rt5640_if1_dac_enum), SOC_ENUM("ADC IF2 Data Switch", rt5640_if2_adc_enum), SOC_ENUM("DAC IF2 Data Switch", rt5640_if2_dac_enum), + + /* ASRC */ + SOC_ENUM_EXT("ASRC Switch", rt5640_asrc_enum, + rt5640_asrc_get, rt5640_asrc_put), }; static const struct snd_kcontrol_new rt5640_specific_snd_controls[] = { @@ -1020,9 +1061,37 @@ static int rt5640_hp_post_event(struct snd_soc_dapm_widget *w, return 0; } +static int rt5640_asrc_event(struct snd_soc_dapm_widget *w, + struct snd_kcontrol *kcontrol, int event) +{ + struct rt5640_priv *rt5640 = snd_soc_codec_get_drvdata(w->codec); + + if (!rt5640->asrc_en) + return 0; + + switch (event) { + case SND_SOC_DAPM_PRE_PMU: + snd_soc_write(w->codec, RT5640_ASRC_1, 0x9b00); + snd_soc_write(w->codec, RT5640_ASRC_2, 0xf800); + break; + case SND_SOC_DAPM_POST_PMD: + snd_soc_write(w->codec, RT5640_ASRC_1, 0x0); + snd_soc_write(w->codec, RT5640_ASRC_2, 0x0); + break; + default: + return 0; + } + + return 0; +} + static const struct snd_soc_dapm_widget rt5640_dapm_widgets[] = { SND_SOC_DAPM_SUPPLY("PLL1", RT5640_PWR_ANLG2, RT5640_PWR_PLL_BIT, 0, NULL, 0), + + SND_SOC_DAPM_SUPPLY_S("ASRC Function", 1, SND_SOC_NOPM, + 0, 0, rt5640_asrc_event, + SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMD), /* Input Side */ /* micbias */ SND_SOC_DAPM_SUPPLY("LDO2", RT5640_PWR_ANLG1, @@ -1276,6 +1345,9 @@ static const struct snd_soc_dapm_widget rt5639_specific_dapm_widgets[] = { }; static const struct snd_soc_dapm_route rt5640_dapm_routes[] = { + {"I2S1", NULL, "ASRC Function"}, + {"I2S2", NULL, "ASRC Function"}, + {"IN1P", NULL, "LDO2"}, {"IN2P", NULL, "LDO2"}, @@ -1635,7 +1707,12 @@ static int rt5640_hw_params(struct snd_pcm_substream *substream, int dai_sel, pre_div, bclk_ms, frame_size; rt5640->lrck[dai->id] = params_rate(params); - pre_div = rl6231_get_clk_info(rt5640->sysclk, rt5640->lrck[dai->id]); + if (rt5640->asrc_en) + pre_div = 0; + else + pre_div = rl6231_get_clk_info(rt5640->sysclk, + rt5640->lrck[dai->id]); + if (pre_div < 0) { dev_err(codec->dev, "Unsupported clock setting %d for DAI %d\n", rt5640->lrck[dai->id], dai->id); diff --git a/sound/soc/codecs/rt5640.h b/sound/soc/codecs/rt5640.h index 58ebe96..0b39178 100644 --- a/sound/soc/codecs/rt5640.h +++ b/sound/soc/codecs/rt5640.h @@ -2095,6 +2095,8 @@ struct rt5640_priv { int pll_out; bool hp_mute; + + int asrc_en; }; #endif -- 1.8.1.1.439.g50a6b54

4 4

[alsa-devel] [PATCH] ASoC: sgtl5000: fix devres handling
by Russell King 30 Jun '14

30 Jun '14

The sgtl5000 uses a two-stage initialisation process. The first stage is when the platform driver is probed, where some resources are found and initialised. The second stage is via the codec driver's probe function, where regulators are found and initialised using the managed resource support. The problem here is that this works fine until the codec driver is unbound. When this occurs, sgtl5000_remove() is called which is a no-op as far as the managed resource code is concerned. The regulators remain allocated, and their pointers in sgtl5000_priv remain valid. If the codec is now re-probed, it will again try and find the regulators, which will now be busy. This will fail. That's not the only problem - if using the LDO regulator, the regulator is unregistered from the regulator core code, but it still has a user. When the user is cleaned up (eg, by removing the module) it hits the free'd regulator, and this can oops the kernel. This bug was originally introduced by 63e54cd9caa3ce ("ASoC: sgtl5000: Use devm_regulator_bulk_get()"). Signed-off-by: Russell King <rmk+kernel(a)arm.linux.org.uk> --- You may wish to give some consideration to whether ASoC core code should be doing this instead, this is probably a very common source of brokenness where two-stage driver initialisation exists. These kinds of issues are why I consider (as a general rule) that two-stage driver initialisation is really bad. sound/soc/codecs/sgtl5000.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c index 96ce061c1f10..3bbd89065313 100644 --- a/sound/soc/codecs/sgtl5000.c +++ b/sound/soc/codecs/sgtl5000.c @@ -1305,6 +1305,9 @@ static int sgtl5000_probe(struct snd_soc_codec *codec) int ret; struct sgtl5000_priv *sgtl5000 = snd_soc_codec_get_drvdata(codec); + if (!devres_open_group(codec->dev, NULL, GFP_KERNEL)) + return -ENOMEM; + ret = sgtl5000_enable_regulators(codec); if (ret) return ret; @@ -1362,6 +1365,9 @@ static int sgtl5000_probe(struct snd_soc_codec *codec) err: regulator_bulk_disable(ARRAY_SIZE(sgtl5000->supplies), sgtl5000->supplies); + + devres_release_group(codec->dev, NULL); + ldo_regulator_remove(codec); return ret; @@ -1375,6 +1381,9 @@ static int sgtl5000_remove(struct snd_soc_codec *codec) regulator_bulk_disable(ARRAY_SIZE(sgtl5000->supplies), sgtl5000->supplies); + + devres_release_group(codec->dev, NULL); + ldo_regulator_remove(codec); return 0; -- 1.8.3.1

3 2

[alsa-devel] [PATCH 0/7] HD-audio cleanup patches for 3.17
by Takashi Iwai 30 Jun '14

30 Jun '14

Hi, below is a series of cleanup patches for HD-audio. Most of changes are to move the PCI-controller specific code from the common code to hda_intel.c. A slight intesive change is the introduction of get_position and get_delay callbacks that replace the existing position_fix[] quirks although there should be no functional changes. Takashi

1 7

[alsa-devel] [PATCH] ALSA: hda - Fix invalid function call in snd_hda_add_vmaster()
by Takashi Iwai 30 Jun '14

30 Jun '14

The recent commit [6194b99d: ALSA: hda - Kill the rest of snd_print*() usages] changed the callback map_slaves(), but one call was forgotten to be replaced due to the cast, which leads to kernel Oops due to invalid function. This patch replaces it with a proper function. Fixes: 6194b99de9f5 ('ALSA: hda - Kill the rest of snd_print*() usages') Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/pci/hda/hda_codec.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index d91cb7f5961a..47a617786fca 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -2831,6 +2831,12 @@ static int init_slave_unmute(struct hda_codec *codec, return put_kctl_with_value(slave, 1); } +static int add_slave(struct hda_codec *codec, + void *data, struct snd_kcontrol *slave) +{ + return snd_ctl_add_slave(data, slave); +} + /** * snd_hda_add_vmaster - create a virtual master control and add slaves * @codec: HD-audio codec @@ -2873,8 +2879,7 @@ int __snd_hda_add_vmaster(struct hda_codec *codec, char *name, if (err < 0) return err; - err = map_slaves(codec, slaves, suffix, - (map_slave_func_t)snd_ctl_add_slave, kctl); + err = map_slaves(codec, slaves, suffix, add_slave, kctl); if (err < 0) return err; -- 2.0.0

1 0