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

[alsa-devel] [PATCH 0/2] ASoC: ak4458: fail on probe if codec is not present
by Viorel Suman 13 May '19

13 May '19

AK4458 is probed successfully even if AK4458 is not present - this is caused by probe function returning no error on i2c access failure. The patchset fixes this. Viorel Suman (2): ASoC: ak4458: rstn_control - return a non-zero on error only ASoC: ak4458: add return value for ak4458_probe sound/soc/codecs/ak4458.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) -- 2.7.4

2 4

[alsa-devel] [PATCH] ASoC : cs4265 : readable register too low
by Matt Flax 13 May '19

13 May '19

The cs4265_readable_register function stopped short of the maximum register. An example bug is taken from : https://github.com/Audio-Injector/Ultra/issues/25 Where alsactl store fails with : Cannot read control '2,0,0,C Data Buffer,0': Input/output error This patch fixes the bug by setting the cs4265 to have readable registers up to the maximum hardware register CS4265_MAX_REGISTER. Signed-off-by: Matt Flax <flatmax(a)flatmax.org> --- sound/soc/codecs/cs4265.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/cs4265.c b/sound/soc/codecs/cs4265.c index ab27d2b94d02..c0190ec59e74 100644 --- a/sound/soc/codecs/cs4265.c +++ b/sound/soc/codecs/cs4265.c @@ -60,7 +60,7 @@ static const struct reg_default cs4265_reg_defaults[] = { static bool cs4265_readable_register(struct device *dev, unsigned int reg) { switch (reg) { - case CS4265_CHIP_ID ... CS4265_SPDIF_CTL2: + case CS4265_CHIP_ID ... CS4265_MAX_REGISTER: return true; default: return false; -- 2.19.1

3 2

[alsa-devel] [PATCH v3 0/2] ASoC: Intel: Add Cometlake PCI IDs
by Evan Green 13 May '19

13 May '19

This small series adds PCI IDs for Cometlake platforms, for a dazzling audio experience. This is based on linux-next's next-20190510. Changes in v3: - Copy cnl_desc to new cml_desc, and avoid selecting cannonlake (Pierre-Louis) - Don't select CML_* in SND_SOC_INTEL_SKYLAKE (Pierre-Louis) Changes in v2: - Add CML-H ID 0x06c8 (Pierre-Louis) - Add 0x06c8 for CML-H (Pierre-Louis) Evan Green (2): ASoC: SOF: Add Comet Lake PCI IDs ASoC: Intel: Skylake: Add Cometlake PCI IDs sound/soc/intel/Kconfig | 16 +++++++++++++ sound/soc/intel/skylake/skl-messages.c | 16 +++++++++++++ sound/soc/intel/skylake/skl.c | 10 ++++++++ sound/soc/sof/intel/Kconfig | 32 ++++++++++++++++++++++++++ sound/soc/sof/sof-pci-dev.c | 28 ++++++++++++++++++++++ 5 files changed, 102 insertions(+) -- 2.20.1

3 5

[alsa-devel] [PATCH] ASoC: amd: Reporting accurate hw_ptr for acp3x dma
by Vijendar Mukunda 13 May '19

13 May '19

From: Ravulapati Vishnu vardhan rao <Vishnuvardhanrao.Ravulapati(a)amd.com> acp3x dma pointer callback has issues in reporting hw_ptr. Modified logic to use linear position registers to retrieve accurate hw_ptr. Signed-off-by: Ravulapati Vishnu vardhan rao <Vishnuvardhanrao.Ravulapati(a)amd.com> Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda(a)amd.com> --- sound/soc/amd/raven/acp3x-pcm-dma.c | 43 ++++++++++++++++++++++++++----------- 1 file changed, 31 insertions(+), 12 deletions(-) diff --git a/sound/soc/amd/raven/acp3x-pcm-dma.c b/sound/soc/amd/raven/acp3x-pcm-dma.c index 9775bda..a4ade6b 100644 --- a/sound/soc/amd/raven/acp3x-pcm-dma.c +++ b/sound/soc/amd/raven/acp3x-pcm-dma.c @@ -32,6 +32,7 @@ struct i2s_stream_instance { u16 channels; u32 xfer_resolution; struct page *pg; + u64 bytescount; void __iomem *acp3x_base; }; @@ -317,6 +318,24 @@ static int acp3x_dma_open(struct snd_pcm_substream *substream) return 0; } +static u64 acp_get_byte_count(struct i2s_stream_instance *rtd, int direction) +{ + u64 byte_count; + + if (direction == SNDRV_PCM_STREAM_PLAYBACK) { + byte_count = rv_readl(rtd->acp3x_base + + mmACP_BT_TX_LINEARPOSITIONCNTR_HIGH); + byte_count |= rv_readl(rtd->acp3x_base + + mmACP_BT_TX_LINEARPOSITIONCNTR_LOW); + } else { + byte_count = rv_readl(rtd->acp3x_base + + mmACP_BT_RX_LINEARPOSITIONCNTR_HIGH); + byte_count |= rv_readl(rtd->acp3x_base + + mmACP_BT_RX_LINEARPOSITIONCNTR_LOW); + } + return byte_count; +} + static int acp3x_dma_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params) { @@ -350,18 +369,17 @@ static int acp3x_dma_hw_params(struct snd_pcm_substream *substream, static snd_pcm_uframes_t acp3x_dma_pointer(struct snd_pcm_substream *substream) { u32 pos = 0; - struct i2s_stream_instance *rtd = substream->runtime->private_data; - - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) - pos = rv_readl(rtd->acp3x_base + - mmACP_BT_TX_LINKPOSITIONCNTR); - else - pos = rv_readl(rtd->acp3x_base + - mmACP_BT_RX_LINKPOSITIONCNTR); - - if (pos >= MAX_BUFFER) - pos = 0; - + u32 buffersize = 0; + u64 bytescount = 0; + struct i2s_stream_instance *rtd = + substream->runtime->private_data; + + buffersize = frames_to_bytes(substream->runtime, + substream->runtime->buffer_size); + bytescount = acp_get_byte_count(rtd, substream->stream); + if (bytescount > rtd->bytescount) + bytescount -= rtd->bytescount; + pos = do_div(bytescount, buffersize); return bytes_to_frames(substream->runtime, pos); } @@ -521,6 +539,7 @@ static int acp3x_dai_i2s_trigger(struct snd_pcm_substream *substream, case SNDRV_PCM_TRIGGER_START: case SNDRV_PCM_TRIGGER_RESUME: case SNDRV_PCM_TRIGGER_PAUSE_RELEASE: + rtd->bytescount = acp_get_byte_count(rtd, substream->stream); if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { rv_writel(period_bytes, rtd->acp3x_base + mmACP_BT_TX_INTR_WATERMARK_SIZE); -- 2.7.4

2 1

[alsa-devel] [PATCH V2] ASoC: soc-pcm: BE dai needs prepare when pause release after resume
by libin.yang＠intel.com 13 May '19

13 May '19

From: Libin Yang <libin.yang(a)intel.com> If playback/capture is paused and system enters S3, after system returns from suspend, BE dai needs to call prepare() callback when playback/capture is released from pause if RESUME_INFO flag is not set. Currently, the dpcm_be_dai_prepare() function will block calling prepare() if the pcm is in SND_SOC_DPCM_STATE_PAUSED state. This will cause the following test case fail if the pcm uses BE: playback -> pause -> S3 suspend -> S3 resume -> pause release The playback may exit abnormally when pause is released because the BE dai prepare() is not called. This patch allows dpcm_be_dai_prepare() to call dai prepare() callback in SND_SOC_DPCM_STATE_PAUSED state. Signed-off-by: Libin Yang <libin.yang(a)intel.com> --- sound/soc/soc-pcm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index d2aa560..0888995 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -2471,7 +2471,8 @@ int dpcm_be_dai_prepare(struct snd_soc_pcm_runtime *fe, int stream) if ((be->dpcm[stream].state != SND_SOC_DPCM_STATE_HW_PARAMS) && (be->dpcm[stream].state != SND_SOC_DPCM_STATE_STOP) && - (be->dpcm[stream].state != SND_SOC_DPCM_STATE_SUSPEND)) + (be->dpcm[stream].state != SND_SOC_DPCM_STATE_SUSPEND) && + (be->dpcm[stream].state != SND_SOC_DPCM_STATE_PAUSED)) continue; dev_dbg(be->dev, "ASoC: prepare BE %s\n", -- 2.7.4

5 13

[alsa-devel] [PATCH 0/6] ASoC: SOF: small update to align with Mark's tree
by Pierre-Louis Bossart 13 May '19

13 May '19

This small patchset removes unneeded include files, fixes a race condition seen in QEMU tests, removes unnecessary PM calls, fixes typos and updates ICL configurations. Jaska Uimonen (1): ASoC: SOF: uapi: remove unused sof header files Kai Vehmanen (1): ASoC: SOF: fix race in FW boot timeout handling Ranjani Sridharan (2): ASoC: SOF: pcm: remove runtime PM calls during pcm open/close ASoC: SOF: fix error in verbose ipc command parsing Zhu Yingjiang (2): ASoC: SOF: Intel: ICL: add Icelake SSP count ASoC: SOF: Intel: ICL add Icelake chip info struct include/uapi/sound/sof/eq.h | 172 --------------------------- include/uapi/sound/sof/manifest.h | 188 ------------------------------ include/uapi/sound/sof/tone.h | 21 ---- include/uapi/sound/sof/trace.h | 66 ----------- sound/soc/sof/intel/cnl.c | 19 +++ sound/soc/sof/intel/hda.h | 2 + sound/soc/sof/ipc.c | 2 +- sound/soc/sof/loader.c | 2 + sound/soc/sof/pcm.c | 29 +---- sound/soc/sof/sof-pci-dev.c | 2 +- 10 files changed, 27 insertions(+), 476 deletions(-) delete mode 100644 include/uapi/sound/sof/eq.h delete mode 100644 include/uapi/sound/sof/manifest.h delete mode 100644 include/uapi/sound/sof/tone.h delete mode 100644 include/uapi/sound/sof/trace.h -- 2.17.1

2 12

[alsa-devel] [PATCH v2] ASoC: max98357a: request GPIO when device get probed
by Tzung-Bi Shih 13 May '19

13 May '19

devm_gpiod_get_optional() returns EBUSY after component rebound. Request GPIO in max98357a_platform_probe() to support component rebinding. Signed-off-by: Tzung-Bi Shih <tzungbi(a)google.com> --- v1: ASoC: max98357a: manage GPIO for component rebinding => don't move from devm to non-devm (https://patchwork.kernel.org/patch/10922979/) v2: ASoC: max98357a: release GPIO when component removing => only put things that really need the card in component's probe() => don't use devm_gpiod_put() if possible (https://patchwork.kernel.org/patch/10932279/) v3: ASoC: max98357a: request GPIO when device get probed => remove empty function max98357a_component_probe() and max98357a_platform_remove() (https://patchwork.kernel.org/patch/10936239/) sound/soc/codecs/max98357a.c | 29 +++++++++-------------------- 1 file changed, 9 insertions(+), 20 deletions(-) diff --git a/sound/soc/codecs/max98357a.c b/sound/soc/codecs/max98357a.c index d037a3e4d323..80080a6415b3 100644 --- a/sound/soc/codecs/max98357a.c +++ b/sound/soc/codecs/max98357a.c @@ -59,21 +59,7 @@ static const struct snd_soc_dapm_route max98357a_dapm_routes[] = { {"Speaker", NULL, "HiFi Playback"}, }; -static int max98357a_component_probe(struct snd_soc_component *component) -{ - struct gpio_desc *sdmode; - - sdmode = devm_gpiod_get_optional(component->dev, "sdmode", GPIOD_OUT_LOW); - if (IS_ERR(sdmode)) - return PTR_ERR(sdmode); - - snd_soc_component_set_drvdata(component, sdmode); - - return 0; -} - static const struct snd_soc_component_driver max98357a_component_driver = { - .probe = max98357a_component_probe, .dapm_widgets = max98357a_dapm_widgets, .num_dapm_widgets = ARRAY_SIZE(max98357a_dapm_widgets), .dapm_routes = max98357a_dapm_routes, @@ -112,16 +98,20 @@ static struct snd_soc_dai_driver max98357a_dai_driver = { static int max98357a_platform_probe(struct platform_device *pdev) { + struct gpio_desc *sdmode; + + sdmode = devm_gpiod_get_optional(&pdev->dev, + "sdmode", GPIOD_OUT_LOW); + if (IS_ERR(sdmode)) + return PTR_ERR(sdmode); + + dev_set_drvdata(&pdev->dev, sdmode); + return devm_snd_soc_register_component(&pdev->dev, &max98357a_component_driver, &max98357a_dai_driver, 1); } -static int max98357a_platform_remove(struct platform_device *pdev) -{ - return 0; -} - #ifdef CONFIG_OF static const struct of_device_id max98357a_device_id[] = { { .compatible = "maxim,max98357a" }, @@ -145,7 +135,6 @@ static struct platform_driver max98357a_platform_driver = { .acpi_match_table = ACPI_PTR(max98357a_acpi_match), }, .probe = max98357a_platform_probe, - .remove = max98357a_platform_remove, }; module_platform_driver(max98357a_platform_driver); -- 2.21.0.1020.gf2820cf01a-goog

2 1

[alsa-devel] [PATCH] ASoC: hdmi-codec: re-introduce mutex locking
by Jerome Brunet 13 May '19

13 May '19

Replace the bit atomic operations by a mutex to ensure only one dai at a time is active on the hdmi codec. This is a follow up on change: 3fcf94ef4d41 ("ASoC: hdmi-codec: remove reference to the current substream") Suggested-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com> --- sound/soc/codecs/hdmi-codec.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/sound/soc/codecs/hdmi-codec.c b/sound/soc/codecs/hdmi-codec.c index 90a892766625..6a0cc8d7e141 100644 --- a/sound/soc/codecs/hdmi-codec.c +++ b/sound/soc/codecs/hdmi-codec.c @@ -281,7 +281,7 @@ struct hdmi_codec_priv { uint8_t eld[MAX_ELD_BYTES]; struct snd_pcm_chmap *chmap_info; unsigned int chmap_idx; - unsigned long busy; + struct mutex lock; }; static const struct snd_soc_dapm_widget hdmi_widgets[] = { @@ -395,8 +395,8 @@ static int hdmi_codec_startup(struct snd_pcm_substream *substream, struct hdmi_codec_priv *hcp = snd_soc_dai_get_drvdata(dai); int ret = 0; - ret = test_and_set_bit(0, &hcp->busy); - if (ret) { + ret = mutex_trylock(&hcp->lock); + if (!ret) { dev_err(dai->dev, "Only one simultaneous stream supported!\n"); return -EINVAL; } @@ -424,7 +424,7 @@ static int hdmi_codec_startup(struct snd_pcm_substream *substream, err: /* Release the exclusive lock on error */ - clear_bit(0, &hcp->busy); + mutex_unlock(&hcp->lock); return ret; } @@ -436,7 +436,7 @@ static void hdmi_codec_shutdown(struct snd_pcm_substream *substream, hcp->chmap_idx = HDMI_CODEC_CHMAP_IDX_UNKNOWN; hcp->hcd.ops->audio_shutdown(dai->dev->parent, hcp->hcd.data); - clear_bit(0, &hcp->busy); + mutex_unlock(&hcp->lock); } static int hdmi_codec_hw_params(struct snd_pcm_substream *substream, @@ -773,6 +773,8 @@ static int hdmi_codec_probe(struct platform_device *pdev) return -ENOMEM; hcp->hcd = *hcd; + mutex_init(&hcp->lock); + daidrv = devm_kcalloc(dev, dai_count, sizeof(*daidrv), GFP_KERNEL); if (!daidrv) return -ENOMEM; -- 2.20.1

2 1

Re: [alsa-devel] Boot procudure on HDA driver
by Takashi Iwai 13 May '19

13 May '19

On Mon, 13 May 2019 13:52:32 +0200, Kailang wrote: > > > > >Well, it's not clear to me whether you'd like to reduce the depop > >procedure above or to add it somewhere else. Could you clarify? > > This depop procedure in alc225_shutup. it doesn't need to run in system boot up. > > If system boot up, it will run alc225_init() already. alc225_init() include power up depop procedure. > So, if system boot up, it only need to run depop procedure in alc225_init(). This is the runtime suspend and resume. That is: > The current boot up procedure was below. > 1. alc225_init() ... which is called at the driver probe time, from snd_hda_codec_build_controls(). Then the codec driver initialization finishes at this point, hence it goes to runtime suspend. > 2. alc225_shutup() ==> this include power off and suspend depop procedure. some codec run this field will have pop noise at boot up. ... which is a part of the codec runtime suspend. Then, the codec gets woken up for some access, and it performs the runtime resume. > 3. alc225_init() ... which is a part of the codec runtime resume. That is, the step 2 and 3 are already out of the initialization phase, and they are normal runtime PM procedure. If the runtime depop code is superfluous for the runtime PM, you can skip it by checking the power_state, for example. But, again, it has nothing to do with the boot or not. It's just the normal runtime suspend and resume. thanks, Takashi > > > ________________________________________ > 從: Takashi Iwai [tiwai(a)suse.de] > 寄件日期: 2019年5月13日下午 07:30 > 至: Kailang > 副本: (alsa-devel(a)alsa-project.org) > 主旨: Re: Boot procudure on HDA driver > > On Mon, 13 May 2019 12:36:36 +0200, > Kailang wrote: > > > > > > Maybe I confuse and I also confuse you. Sorry!! > > > > When system suspend, it will run alc_suspend(). alc_suspend() was include alc_shutup(). > > Right. > > > When system shutdown(power off), will it run alc_shutup()? > > Yes, it's called via alc_reboot_notify(). > If spec->reboot_notify is defined, this supersedes the call, so you > may define the callback if you'd need to avoid alc_shutup() call from > there. > > > > in our patch_realtek.c. > > spec->shutup = alc225_shutup; > > Some codec didn't run the depop procudure during boot up. > > > > Maybe disable EAPD and shutup PIN will cause pop noise. > > But this procudure need to run in SUSPEND and HIBERNATE and Power off. > > It also need to run it at runtime suspend. > > > > static void alc225_shutup(struct hda_codec *codec) > > { > > struct alc_spec *spec = codec->spec; > > hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0]; > > bool hp1_pin_sense, hp2_pin_sense; > > > > *********** depop procudure ****************************************** > > if (!hp_pin) > > hp_pin = 0x21; > > > > /* 3k pull low control for Headset jack. */ > > alc_update_coef_idx(codec, 0x4a, 0, 3 << 10); > > > > hp1_pin_sense = snd_hda_jack_detect(codec, hp_pin); > > hp2_pin_sense = snd_hda_jack_detect(codec, 0x16); > > > > if (hp1_pin_sense || hp2_pin_sense) > > msleep(2); > > > > if (hp1_pin_sense) > > snd_hda_codec_write(codec, hp_pin, 0, > > AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE); > > if (hp2_pin_sense) > > snd_hda_codec_write(codec, 0x16, 0, > > AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE); > > > > if (hp1_pin_sense || hp2_pin_sense) > > msleep(85); > > > > if (hp1_pin_sense) > > snd_hda_codec_write(codec, hp_pin, 0, > > AC_VERB_SET_PIN_WIDGET_CONTROL, 0x0); > > if (hp2_pin_sense) > > snd_hda_codec_write(codec, 0x16, 0, > > AC_VERB_SET_PIN_WIDGET_CONTROL, 0x0); > > > > if (hp1_pin_sense || hp2_pin_sense) > > msleep(100); > > > > alc_auto_setup_eapd(codec, false); > > snd_hda_shutup_pins(codec); > > ************** depop procudure ************************************* > > } > > Well, it's not clear to me whether you'd like to reduce the depop > procedure above or to add it somewhere else. Could you clarify? > > > thanks, > > Takashi > > > > > > > > > > > > > > ________________________________________ > > 從: Takashi Iwai [tiwai(a)suse.de] > > 寄件日期: 2019年5月13日下午 05:42 > > 至: Kailang > > 副本: (alsa-devel(a)alsa-project.org) > > 主旨: Re: Boot procudure on HDA driver > > > > On Mon, 13 May 2019 11:30:56 +0200, > > Kailang wrote: > > > > > > > > > > > > > -----Original Message----- > > > > From: Takashi Iwai <tiwai(a)suse.de> > > > > Sent: Monday, May 13, 2019 5:11 PM > > > > To: Kailang <kailang(a)realtek.com> > > > > Cc: (alsa-devel(a)alsa-project.org) <alsa-devel(a)alsa-project.org> > > > > Subject: Re: Boot procudure on HDA driver > > > > > > > > On Mon, 13 May 2019 11:00:18 +0200, > > > > Kailang wrote: > > > > > > > > > > Hi Takashi, > > > > > > > > > > When System Boot up. > > > > > The Hda Driver running step was as below. > > > > > > > > > > alc_init(); > > > > > alc_shutup(); > > > > > alc_init(); > > > > > > > > > > The depop procedure was put in spec->init_hook and spec->shutup. > > > > > > > > > > But I find more codec which run spec->shutup at boot up. It will occur pop > > > > noise. > > > > > If it doesn't run spec->shutup, it will not occur pop noise or reduce pop noise. > > > > > > > > > > How could the spec->shutup not run at boot up? > > > > > > > > > > I ever test to put the check in spec->shutup() for PM_EVENT_SUSPEND and > > > > PM_EVENT_HIBERNATE and shutdown. > > > > > But if power_save=1, it was have issue for this. > > > > > Codec was idle already in power_save=1 state. If system go suspend, it will > > > > not run spec->shutup() again. > > > > > > > > I guess it's a runtime PM, hence it's neither PM_EVENT_SUSPEND nor > > > > PM_EVENT_HIBERNATE. > > > > > > > runtime PM and suspend and hibernate and shutdown need to run > > > spec->shutup(). > > > > Is the call really mandatory? > > > > > It's no problem. > > > But spec->shutup() doesn't need to run in boot up. > > > > The call of spec->shutup() at boot up *is* the runtime PM. > > Or any other call path I overlooked? > > > > > And it will set power_save=1 on all dell machine. > > > > > > If (codec->auto_runtime_pm || codec->bus->shutdown || > > > codec->core.dev.power.power_state.event == PM_EVENT_SUSPEND || > > > codec->core.dev.power.power_state.event == PM_EVENT_HIBERNATE) > > > > > > So, I need to put upper check code in spec->shutup(). Right? > > > Thanks. > > > > No, the auto_runtime_pm is for a completely different purpose. > > > > At the boot up, the runtime PM can be kicked in at any time. So if > > you disable the shutup during the runtime PM, it means you'd need to > > call the shutup at runtime PM completely. > > > > > > Takashi > > > > > > > > > Actually, if the shutup procedure makes the problem on a certain platform, just > > > > skip it. It's an optional behavior and would be fine without it (of course only if > > > > it's confirmed to work :) > > > > > > > > > > > > Takashi > > > > > > > > ------Please consider the environment before printing this e-mail. > > >

1 0

Re: [alsa-devel] Boot procudure on HDA driver
by Takashi Iwai 13 May '19

13 May '19

On Mon, 13 May 2019 12:36:36 +0200, Kailang wrote: > > > Maybe I confuse and I also confuse you. Sorry!! > > When system suspend, it will run alc_suspend(). alc_suspend() was include alc_shutup(). Right. > When system shutdown(power off), will it run alc_shutup()? Yes, it's called via alc_reboot_notify(). If spec->reboot_notify is defined, this supersedes the call, so you may define the callback if you'd need to avoid alc_shutup() call from there. > in our patch_realtek.c. > spec->shutup = alc225_shutup; > Some codec didn't run the depop procudure during boot up. > > Maybe disable EAPD and shutup PIN will cause pop noise. > But this procudure need to run in SUSPEND and HIBERNATE and Power off. > It also need to run it at runtime suspend. > > static void alc225_shutup(struct hda_codec *codec) > { > struct alc_spec *spec = codec->spec; > hda_nid_t hp_pin = spec->gen.autocfg.hp_pins[0]; > bool hp1_pin_sense, hp2_pin_sense; > > *********** depop procudure ****************************************** > if (!hp_pin) > hp_pin = 0x21; > > /* 3k pull low control for Headset jack. */ > alc_update_coef_idx(codec, 0x4a, 0, 3 << 10); > > hp1_pin_sense = snd_hda_jack_detect(codec, hp_pin); > hp2_pin_sense = snd_hda_jack_detect(codec, 0x16); > > if (hp1_pin_sense || hp2_pin_sense) > msleep(2); > > if (hp1_pin_sense) > snd_hda_codec_write(codec, hp_pin, 0, > AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE); > if (hp2_pin_sense) > snd_hda_codec_write(codec, 0x16, 0, > AC_VERB_SET_AMP_GAIN_MUTE, AMP_OUT_MUTE); > > if (hp1_pin_sense || hp2_pin_sense) > msleep(85); > > if (hp1_pin_sense) > snd_hda_codec_write(codec, hp_pin, 0, > AC_VERB_SET_PIN_WIDGET_CONTROL, 0x0); > if (hp2_pin_sense) > snd_hda_codec_write(codec, 0x16, 0, > AC_VERB_SET_PIN_WIDGET_CONTROL, 0x0); > > if (hp1_pin_sense || hp2_pin_sense) > msleep(100); > > alc_auto_setup_eapd(codec, false); > snd_hda_shutup_pins(codec); > ************** depop procudure ************************************* > } Well, it's not clear to me whether you'd like to reduce the depop procedure above or to add it somewhere else. Could you clarify? thanks, Takashi > > > > > > ________________________________________ > 從: Takashi Iwai [tiwai(a)suse.de] > 寄件日期: 2019年5月13日下午 05:42 > 至: Kailang > 副本: (alsa-devel(a)alsa-project.org) > 主旨: Re: Boot procudure on HDA driver > > On Mon, 13 May 2019 11:30:56 +0200, > Kailang wrote: > > > > > > > > > -----Original Message----- > > > From: Takashi Iwai <tiwai(a)suse.de> > > > Sent: Monday, May 13, 2019 5:11 PM > > > To: Kailang <kailang(a)realtek.com> > > > Cc: (alsa-devel(a)alsa-project.org) <alsa-devel(a)alsa-project.org> > > > Subject: Re: Boot procudure on HDA driver > > > > > > On Mon, 13 May 2019 11:00:18 +0200, > > > Kailang wrote: > > > > > > > > Hi Takashi, > > > > > > > > When System Boot up. > > > > The Hda Driver running step was as below. > > > > > > > > alc_init(); > > > > alc_shutup(); > > > > alc_init(); > > > > > > > > The depop procedure was put in spec->init_hook and spec->shutup. > > > > > > > > But I find more codec which run spec->shutup at boot up. It will occur pop > > > noise. > > > > If it doesn't run spec->shutup, it will not occur pop noise or reduce pop noise. > > > > > > > > How could the spec->shutup not run at boot up? > > > > > > > > I ever test to put the check in spec->shutup() for PM_EVENT_SUSPEND and > > > PM_EVENT_HIBERNATE and shutdown. > > > > But if power_save=1, it was have issue for this. > > > > Codec was idle already in power_save=1 state. If system go suspend, it will > > > not run spec->shutup() again. > > > > > > I guess it's a runtime PM, hence it's neither PM_EVENT_SUSPEND nor > > > PM_EVENT_HIBERNATE. > > > > > runtime PM and suspend and hibernate and shutdown need to run > > spec->shutup(). > > Is the call really mandatory? > > > It's no problem. > > But spec->shutup() doesn't need to run in boot up. > > The call of spec->shutup() at boot up *is* the runtime PM. > Or any other call path I overlooked? > > > And it will set power_save=1 on all dell machine. > > > > If (codec->auto_runtime_pm || codec->bus->shutdown || > > codec->core.dev.power.power_state.event == PM_EVENT_SUSPEND || > > codec->core.dev.power.power_state.event == PM_EVENT_HIBERNATE) > > > > So, I need to put upper check code in spec->shutup(). Right? > > Thanks. > > No, the auto_runtime_pm is for a completely different purpose. > > At the boot up, the runtime PM can be kicked in at any time. So if > you disable the shutup during the runtime PM, it means you'd need to > call the shutup at runtime PM completely. > > > Takashi > > > > > > Actually, if the shutup procedure makes the problem on a certain platform, just > > > skip it. It's an optional behavior and would be fine without it (of course only if > > > it's confirmed to work :) > > > > > > > > > Takashi > > > > > > ------Please consider the environment before printing this e-mail. > >

1 0