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

Re: [alsa-devel] power state in power save mode
by Takashi Iwai 11 Apr '19

11 Apr '19

On Thu, 11 Apr 2019 13:39:21 +0200, Kailang wrote: > > Hi Takashi, > > I also checked the value by simply printk. > I put printk in alc256_init() and alc256_shutup(). > Without power save, i could see the expected value at suspend and resume. > > With power save, alc256_init() will run after music play, it will print out value 0x0 at this time. > alc256_shutup() already run at count down time value of power_save = ?. > So, alc256_shutup will not run again when system suspend. power state value will also not print out during suspend. > Is this the expectation behavior? Yes, the same suspend/resume path is used for the codec driver for both runtime and system suspend/resume. For the runtime PM, the callbacks are called with power_state=0. > I test add your patch. > Then test with power save option. Wait time up, codec go to power save mode(run alc256_shutup()). > Let system to suspend.(it will not run alc256_shutup() again) > Then resume it. Play a short wave file. alc256_init() will run after music play, it will value 0x10 at this time. > > I think alc256_shutup() will not update power state when it with power save option. > If I want to use alc256_shutup() to check power state then do some thing, I think it's impossible. Right? When the system was already in the runtime suspended state, it won't trigger the codec suspend again. With the recent code (after the commit b5a236c175b0), we enforce the resume even if it wasn't used at the suspend time. So for the resume, it's always woken up with the proper power_state when the system is resumed via S3/S4 (not via runtime PM). Takashi > > BR, > Kailang > > ________________________________________ > 從: Takashi Iwai [tiwai(a)suse.de] > 寄件日期: 2019年4月10日下午 11:52 > 至: Kailang > 副本: (alsa-devel(a)alsa-project.org) > 主旨: Re: power state in power save mode > > On Wed, 10 Apr 2019 05:00:31 +0200, > Kailang wrote: > > > > > -----Original Message----- > > > From: Takashi Iwai <tiwai(a)suse.de> > > > Sent: Tuesday, April 9, 2019 6:15 PM > > > To: Kailang <kailang(a)realtek.com> > > > Cc: (alsa-devel(a)alsa-project.org) <alsa-devel(a)alsa-project.org> > > > Subject: Re: power state in power save mode > > > > > > On Tue, 09 Apr 2019 11:54:27 +0200, > > > Kailang wrote: > > > > > > > > Hi Takashi, > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit > > > > /?h=for-next&id=98081ca62cbac31fb0f7efaf90b2e7384ce22257 > > > > > > > > Use upper patch to print power state in function alc256_init() and > > > alc256_shutup(). > > > > But when kernel turn on power_save = 1. (echo 1 > > > > > /sys/module/snd_hda_intel/parameters/power_save) > > > > > > > > The print power state value always be 0x0. > > > > > > That's expected, it means PM_EVENT_ON. > > > The power_state value is changed only during the suspend and resume. > > > Once after returning from resume, it's set to PM_EVENT_ON. > > > > I also test suspend and resume. It also show 0x0. > > If it turn off power save, power state value will normally. > > What exactly did you see? I checked the value by simply printk and it > behaved as expected, both with and without power save. > > > > > > > > ( If it turn off power save, power state value will normally) > > > > > > What does it mean exactly...? > > > > > > Actually one missing piece is to set PMSG_ON at the device initialization. A > > > patch like below. > > > > Add this patch, the power state value will show on suspend and resume. Right? > > I will test it later. > > This won't change anything about the suspend/resume behavior, but it's > just for some consistency in case the driver refers to the state > before entering the suspend/resume callback. > > > Takashi > > > > > > > > > > > thanks, > > > > > > Takashi > > > > > > --- a/sound/pci/hda/hda_codec.c > > > +++ b/sound/pci/hda/hda_codec.c > > > @@ -969,6 +969,7 @@ int snd_hda_codec_device_new(struct hda_bus *bus, > > > struct snd_card *card, > > > > > > /* power-up all before initialization */ > > > hda_set_power_state(codec, AC_PWRST_D0); > > > + codec->core.dev.power.power_state = PMSG_ON; > > > > > > snd_hda_codec_proc_new(codec); > > > > > > > > > ------Please consider the environment before printing this e-mail. > >

1 0

[alsa-devel] [PATCH V4] ASoC: fsl_esai: Fix missing break in switch statement
by S.j. Wang 11 Apr '19

11 Apr '19

case ESAI_HCKT_EXTAL and case ESAI_HCKR_EXTAL should be independent of each other, so replace fall-through with break. Fixes: 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver") Signed-off-by: Shengjiu Wang <shengjiu.wang(a)nxp.com> Acked-by: Nicolin Chen <nicoleotsuka(a)gmail.com> Cc: <stable(a)vger.kernel.org> --- Change in v4 - Add Acked-by and cc stable - change the subject sound/soc/fsl/fsl_esai.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c index 3623aa9a6f2e..15202a637197 100644 --- a/sound/soc/fsl/fsl_esai.c +++ b/sound/soc/fsl/fsl_esai.c @@ -251,7 +251,7 @@ static int fsl_esai_set_dai_sysclk(struct snd_soc_dai *dai, int clk_id, break; case ESAI_HCKT_EXTAL: ecr |= ESAI_ECR_ETI; - /* fall through */ + break; case ESAI_HCKR_EXTAL: ecr |= ESAI_ECR_ERI; break; -- 1.9.1

3 3

[alsa-devel] [PATCH V2] ASoC: fsl_esai: replace fall-through with break
by S.j. Wang 11 Apr '19

11 Apr '19

case ESAI_HCKT_EXTAL and case ESAI_HCKR_EXTAL should be independent of each other, so replace fall-through with break. Fixes: 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver") Signed-off-by: Shengjiu Wang <shengjiu.wang(a)nxp.com> --- Changes in v2 - fix the fixes tag. sound/soc/fsl/fsl_esai.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c index c7410bbfd2af..bad0dfed6b68 100644 --- a/sound/soc/fsl/fsl_esai.c +++ b/sound/soc/fsl/fsl_esai.c @@ -251,7 +251,7 @@ static int fsl_esai_set_dai_sysclk(struct snd_soc_dai *dai, int clk_id, break; case ESAI_HCKT_EXTAL: ecr |= ESAI_ECR_ETI; - /* fall through */ + break; case ESAI_HCKR_EXTAL: ecr |= esai_priv->synchronous ? ESAI_ECR_ETI : ESAI_ECR_ERI; break; -- 1.9.1

4 5

[alsa-devel] [PATCH V3] ASoC: fsl_esai: Fix missing break in switch statement
by S.j. Wang 11 Apr '19

11 Apr '19

case ESAI_HCKT_EXTAL and case ESAI_HCKR_EXTAL should be independent of each other, so replace fall-through with break. Fixes: 43d24e76b698 ("ASoC: fsl_esai: Add ESAI CPU DAI driver") Signed-off-by: Shengjiu Wang <shengjiu.wang(a)nxp.com> Cc: <stable(a)vger.kernel.org> --- changes in v3 - add cc stable - change the subject sound/soc/fsl/fsl_esai.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c index 3623aa9a6f2e..15202a637197 100644 --- a/sound/soc/fsl/fsl_esai.c +++ b/sound/soc/fsl/fsl_esai.c @@ -251,7 +251,7 @@ static int fsl_esai_set_dai_sysclk(struct snd_soc_dai *dai, int clk_id, break; case ESAI_HCKT_EXTAL: ecr |= ESAI_ECR_ETI; - /* fall through */ + break; case ESAI_HCKR_EXTAL: ecr |= ESAI_ECR_ERI; break; -- 1.9.1

1 1

[alsa-devel] ASoC fsl_sai? Output stuck high causes loud pop
by Cameron Kellough 10 Apr '19

10 Apr '19

Hi ASoC developers, I'm working with kernel 4.9.88 on an NXP IMX6ULL based PicoSOM from Technexion. We have developed our own integration of this CPU with an audio codec and a DSP. I'm hearing a loud pop at the end of playback for sounds and after a lot of tracing, I think there may be a problem in or near the fsl_sai driver. I suspect that the SAI transmitter is not being disabled at the end of playback as the bus appears to be driven with all ones after the end of playback. Briefly, we have the IMX6ULL configured as an I2S slave to a DSP chip. In this case, the DSP is continuously providing BCLK and LRCLK to the IMX6ULL and the connected codec. When no sound is playing and I examine the output of the Serial Data Out line from the IMX6ULL with an o-scope, the values on it encode all high bits instead of all low bits. The popping noise we hear seems to be the bus going from a relatively low value at the end of a played sound to an infinite length set of samples of maximum volume. Based on having set the pad control registers to no pullup, one would expect the I2S bus to be low when no sound is being transmitted. While the exact problem above involves a custom setup, a popping can be observed using the Technexion IMX6ULL on the PI baseboard and playing a sound with aplay. Some evidence on the NXP forum suggests the problem also exists using the IMX6. I'm sorry this isn't a lot to go on. I'm happy to provide more information if anyone is interested in this issue. --Cameron Kellough

1 0

[alsa-devel] [PATCH] ASoC: fsl_asrc: replace the process_option table with function
by S.j. Wang 10 Apr '19

10 Apr '19

The table is not flexible if supported sample rate is not in the table, so use a function to replace it. Signed-off-by: Shengjiu Wang <shengjiu.wang(a)nxp.com> --- sound/soc/fsl/fsl_asrc.c | 73 +++++++++++++++++++++++++++++++++++------------- 1 file changed, 53 insertions(+), 20 deletions(-) diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c index 0b937924d2e4..a57c6c829060 100644 --- a/sound/soc/fsl/fsl_asrc.c +++ b/sound/soc/fsl/fsl_asrc.c @@ -26,24 +26,6 @@ #define pair_dbg(fmt, ...) \ dev_dbg(&asrc_priv->pdev->dev, "Pair %c: " fmt, 'A' + index, ##__VA_ARGS__) -/* Sample rates are aligned with that defined in pcm.h file */ -static const u8 process_option[][12][2] = { - /* 8kHz 11.025kHz 16kHz 22.05kHz 32kHz 44.1kHz 48kHz 64kHz 88.2kHz 96kHz 176kHz 192kHz */ - {{0, 1}, {0, 1}, {0, 1}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0},}, /* 5512Hz */ - {{0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0},}, /* 8kHz */ - {{0, 2}, {0, 1}, {0, 1}, {0, 1}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0},}, /* 11025Hz */ - {{1, 2}, {0, 2}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0},}, /* 16kHz */ - {{1, 2}, {1, 2}, {0, 2}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 0}, {0, 0}, {0, 0}, {0, 0}, {0, 0},}, /* 22050Hz */ - {{1, 2}, {2, 1}, {2, 1}, {0, 2}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 0}, {0, 0}, {0, 0},}, /* 32kHz */ - {{2, 2}, {2, 2}, {2, 1}, {2, 1}, {0, 2}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 0}, {0, 0},}, /* 44.1kHz */ - {{2, 2}, {2, 2}, {2, 1}, {2, 1}, {0, 2}, {0, 2}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 0}, {0, 0},}, /* 48kHz */ - {{2, 2}, {2, 2}, {2, 2}, {2, 1}, {1, 2}, {0, 2}, {0, 2}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 0},}, /* 64kHz */ - {{2, 2}, {2, 2}, {2, 2}, {2, 2}, {1, 2}, {1, 2}, {1, 2}, {1, 1}, {1, 1}, {1, 1}, {1, 1}, {1, 1},}, /* 88.2kHz */ - {{2, 2}, {2, 2}, {2, 2}, {2, 2}, {1, 2}, {1, 2}, {1, 2}, {1, 1}, {1, 1}, {1, 1}, {1, 1}, {1, 1},}, /* 96kHz */ - {{2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 1}, {2, 1}, {2, 1}, {2, 1}, {2, 1},}, /* 176kHz */ - {{2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 2}, {2, 1}, {2, 1}, {2, 1}, {2, 1}, {2, 1},}, /* 192kHz */ -}; - /* Corresponding to process_option */ static int supported_input_rate[] = { 5512, 8000, 11025, 16000, 22050, 32000, 44100, 48000, 64000, 88200, @@ -79,6 +61,49 @@ static unsigned char *clk_map[2]; +static int proc_autosel(int Fsin, int Fsout, int *pre_proc, int *post_proc) +{ + bool det_out_op2_cond; + bool det_out_op0_cond; + + det_out_op2_cond = (((Fsin * 15 > Fsout * 16) & (Fsout < 56000)) | + ((Fsin > 56000) & (Fsout < 56000))); + det_out_op0_cond = (Fsin * 23 < Fsout * 8); + + /* + * Not supported case: Tsout>16.125*Tsin, and Tsout>8.125*Tsin. + */ + if (Fsin * 8 > 129 * Fsout) + *pre_proc = 5; + else if (Fsin * 8 > 65 * Fsout) + *pre_proc = 4; + else if (Fsin * 8 > 33 * Fsout) + *pre_proc = 2; + else if (Fsin * 8 > 15 * Fsout) { + if (Fsin > 152000) + *pre_proc = 2; + else + *pre_proc = 1; + } else if (Fsin < 76000) + *pre_proc = 0; + else if (Fsin > 152000) + *pre_proc = 2; + else + *pre_proc = 1; + + if (det_out_op2_cond) + *post_proc = 2; + else if (det_out_op0_cond) + *post_proc = 0; + else + *post_proc = 1; + + if (*pre_proc == 4 || *pre_proc == 5) + return -EINVAL; + + return 0; +} + /** * Request ASRC pair * @@ -239,8 +264,10 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair) u32 inrate, outrate, indiv, outdiv; u32 clk_index[2], div[2]; int in, out, channels; + int pre_proc, post_proc; struct clk *clk; bool ideal; + int ret; if (!config) { pair_err("invalid pair config\n"); @@ -377,11 +404,17 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair) ASRCTR_IDRi_MASK(index) | ASRCTR_USRi_MASK(index), ASRCTR_IDR(index) | ASRCTR_USR(index)); + ret = proc_autosel(inrate, outrate, &pre_proc, &post_proc); + if (ret) { + pair_err("No supported pre-processing options\n"); + return ret; + } + /* Apply configurations for pre- and post-processing */ regmap_update_bits(asrc_priv->regmap, REG_ASRCFG, ASRCFG_PREMODi_MASK(index) | ASRCFG_POSTMODi_MASK(index), - ASRCFG_PREMOD(index, process_option[in][out][0]) | - ASRCFG_POSTMOD(index, process_option[in][out][1])); + ASRCFG_PREMOD(index, pre_proc) | + ASRCFG_POSTMOD(index, post_proc)); return fsl_asrc_set_ideal_ratio(pair, inrate, outrate); } -- 1.9.1

2 7

[alsa-devel] [PATCH v2 0/3] ASoC: fsl: audmix: remove "model" attribute and fix ref leaks
by Viorel Suman 10 Apr '19

10 Apr '19

The latest audmix patch-set (v5) had the "model" attribute removed as requested by Nicolin Chen, but looks like (v4) version of DAI driver reached "for-next" branch - fix this by removing "model" attribute. Asside of this fix object reference leaks in machine probe reported by Julia Lawall. Viorel Suman (3): ASoC: fsl_audmix: remove "model" attribute dt-bindings: fsl,audmix: remove "model" attribute ASoC: imx-audmix: fix object reference leaks in probe Changes since V1: a) Removed "model" attribute from dt-bindings documentation b) Adressed Daniel's comments .../devicetree/bindings/sound/fsl,audmix.txt | 4 -- sound/soc/fsl/fsl_audmix.c | 43 ++++++++++++---------- sound/soc/fsl/imx-audmix.c | 4 ++ 3 files changed, 27 insertions(+), 24 deletions(-) -- 2.7.4

3 11

[alsa-devel] power state in power save mode
by Kailang 10 Apr '19

10 Apr '19

Hi Takashi, https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?h=f… Use upper patch to print power state in function alc256_init() and alc256_shutup(). But when kernel turn on power_save = 1. (echo 1 > /sys/module/snd_hda_intel/parameters/power_save) The print power state value always be 0x0. ( If it turn off power save, power state value will normally) BR, Kailang

2 3

[alsa-devel] [PATCH] ALSA: hda: Fix racy display power access
by Takashi Iwai 10 Apr '19

10 Apr '19

snd_hdac_display_power() doesn't handle the concurrent calls carefully enough, and it may lead to the doubly get_power or put_power calls, when a runtime PM and an async work get called in racy way. This patch addresses it by reusing the bus->lock mutex that has been used for protecting the link state change in ext bus code, so that it can protect against racy display state changes. The initialization of bus->lock was moved from snd_hdac_ext_bus_init() to snd_hdac_bus_init() as well accordingly. Testcase: igt/i915_pm_rpm/module-reload #glk-dsi Reported-by: Chris Wilson <chris(a)chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Imre Deak <imre.deak(a)intel.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/hda/ext/hdac_ext_bus.c | 1 - sound/hda/hdac_bus.c | 1 + sound/hda/hdac_component.c | 6 +++++- 3 files changed, 6 insertions(+), 2 deletions(-) diff --git a/sound/hda/ext/hdac_ext_bus.c b/sound/hda/ext/hdac_ext_bus.c index 9c37d9af3023..ec7715c6b0c0 100644 --- a/sound/hda/ext/hdac_ext_bus.c +++ b/sound/hda/ext/hdac_ext_bus.c @@ -107,7 +107,6 @@ int snd_hdac_ext_bus_init(struct hdac_bus *bus, struct device *dev, INIT_LIST_HEAD(&bus->hlink_list); bus->idx = idx++; - mutex_init(&bus->lock); bus->cmd_dma_state = true; return 0; diff --git a/sound/hda/hdac_bus.c b/sound/hda/hdac_bus.c index 012305177f68..ad8eee08013f 100644 --- a/sound/hda/hdac_bus.c +++ b/sound/hda/hdac_bus.c @@ -38,6 +38,7 @@ int snd_hdac_bus_init(struct hdac_bus *bus, struct device *dev, INIT_WORK(&bus->unsol_work, snd_hdac_bus_process_unsol_events); spin_lock_init(&bus->reg_lock); mutex_init(&bus->cmd_mutex); + mutex_init(&bus->lock); bus->irq = -1; return 0; } diff --git a/sound/hda/hdac_component.c b/sound/hda/hdac_component.c index a6d37b9d6413..6b5caee61c6e 100644 --- a/sound/hda/hdac_component.c +++ b/sound/hda/hdac_component.c @@ -69,13 +69,15 @@ void snd_hdac_display_power(struct hdac_bus *bus, unsigned int idx, bool enable) dev_dbg(bus->dev, "display power %s\n", enable ? "enable" : "disable"); + + mutex_lock(&bus->lock); if (enable) set_bit(idx, &bus->display_power_status); else clear_bit(idx, &bus->display_power_status); if (!acomp || !acomp->ops) - return; + goto unlock; if (bus->display_power_status) { if (!bus->display_power_active) { @@ -92,6 +94,8 @@ void snd_hdac_display_power(struct hdac_bus *bus, unsigned int idx, bool enable) bus->display_power_active = false; } } + unlock: + mutex_unlock(&bus->lock); } EXPORT_SYMBOL_GPL(snd_hdac_display_power); -- 2.16.4

1 0

[alsa-devel] [PATCH] ASoC: cAVS: add device_link to HDMI audio
by libin.yang＠intel.com 10 Apr '19

10 Apr '19

From: Libin Yang <libin.yang(a)intel.com> In resume from S3, HDAC HDMI codec driver dapm event callback may be operated before HDMI codec driver turns on the display audio power domain because of the contest between display driver and hdmi codec driver. This patch adds the device_link between cAVS generic machine device (consumer) and hdmi codec device (supplier) to make sure the sequence is always correct. Signed-off-by: Libin Yang <libin.yang(a)intel.com> --- sound/soc/intel/boards/skl_hda_dsp_common.c | 15 +++++++++++++++ sound/soc/intel/boards/skl_hda_dsp_common.h | 1 + sound/soc/intel/boards/skl_hda_dsp_generic.c | 12 ++++++++++++ 3 files changed, 28 insertions(+) diff --git a/sound/soc/intel/boards/skl_hda_dsp_common.c b/sound/soc/intel/boards/skl_hda_dsp_common.c index 9b30c0e..01c8937 100644 --- a/sound/soc/intel/boards/skl_hda_dsp_common.c +++ b/sound/soc/intel/boards/skl_hda_dsp_common.c @@ -17,6 +17,18 @@ #define NAME_SIZE 32 +static int skl_hdmi_init(struct snd_soc_pcm_runtime *rtd) +{ + struct skl_hda_private *ctx = snd_soc_card_get_drvdata(rtd->card); + struct snd_soc_dai *dai = rtd->codec_dai; + + if (!ctx->link) + ctx->link = device_link_add(rtd->card->dev, dai->dev, + DL_FLAG_RPM_ACTIVE); + + return 0; +} + int skl_hda_hdmi_add_pcm(struct snd_soc_card *card, int device) { struct skl_hda_private *ctx = snd_soc_card_get_drvdata(card); @@ -48,6 +60,7 @@ struct snd_soc_dai_link skl_hda_be_dai_links[HDA_DSP_MAX_BE_DAI_LINKS] = { .cpu_dai_name = "iDisp1 Pin", .codec_name = "ehdaudio0D2", .codec_dai_name = "intel-hdmi-hifi1", + .init = skl_hdmi_init, .dpcm_playback = 1, .no_pcm = 1, .trigger[0] = SND_SOC_DPCM_TRIGGER_POST, @@ -58,6 +71,7 @@ struct snd_soc_dai_link skl_hda_be_dai_links[HDA_DSP_MAX_BE_DAI_LINKS] = { .cpu_dai_name = "iDisp2 Pin", .codec_name = "ehdaudio0D2", .codec_dai_name = "intel-hdmi-hifi2", + .init = skl_hdmi_init, .dpcm_playback = 1, .no_pcm = 1, .trigger[0] = SND_SOC_DPCM_TRIGGER_POST, @@ -68,6 +82,7 @@ struct snd_soc_dai_link skl_hda_be_dai_links[HDA_DSP_MAX_BE_DAI_LINKS] = { .cpu_dai_name = "iDisp3 Pin", .codec_name = "ehdaudio0D2", .codec_dai_name = "intel-hdmi-hifi3", + .init = skl_hdmi_init, .dpcm_playback = 1, .no_pcm = 1, .trigger[0] = SND_SOC_DPCM_TRIGGER_POST, diff --git a/sound/soc/intel/boards/skl_hda_dsp_common.h b/sound/soc/intel/boards/skl_hda_dsp_common.h index 87c50af..df5cc6b 100644 --- a/sound/soc/intel/boards/skl_hda_dsp_common.h +++ b/sound/soc/intel/boards/skl_hda_dsp_common.h @@ -29,6 +29,7 @@ struct skl_hda_private { int pcm_count; int dai_index; const char *platform_name; + struct device_link *link; }; extern struct snd_soc_dai_link skl_hda_be_dai_links[HDA_DSP_MAX_BE_DAI_LINKS]; diff --git a/sound/soc/intel/boards/skl_hda_dsp_generic.c b/sound/soc/intel/boards/skl_hda_dsp_generic.c index b9a21e6..ceca11e 100644 --- a/sound/soc/intel/boards/skl_hda_dsp_generic.c +++ b/sound/soc/intel/boards/skl_hda_dsp_generic.c @@ -166,8 +166,20 @@ static int skl_hda_audio_probe(struct platform_device *pdev) return devm_snd_soc_register_card(&pdev->dev, &hda_soc_card); } +static int skl_hda_audio_remove(struct platform_device *pdev) +{ + struct snd_soc_card *card = platform_get_drvdata(pdev); + struct skl_hda_private *ctx = snd_soc_card_get_drvdata(card); + + if (ctx->link) + device_link_del(ctx->link); + + return 0; +} + static struct platform_driver skl_hda_audio = { .probe = skl_hda_audio_probe, + .remove = skl_hda_audio_remove, .driver = { .name = "skl_hda_dsp_generic", .pm = &snd_soc_pm_ops, -- 2.7.4

6 9