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

MPG X570S EDGE MAX WIFI compatibility
by GitHub issues - edited 18 Jun '22

18 Jun '22

alsa-project/alsa-ucm-conf issue #172 was edited from yhojann-cl: Please, add `0db0:151f` to `realtek-alc4080` chip compatibility in MPG X570S EDGE MAX WIFI motherboard: ``` $ lsusb | grep 0db0 Bus 001 Device 003: ID 0db0:151f Micro Star International USB Audio ``` In `ucm2/USB-Audio/USB-Audio.conf` add `151f` to regex of `0db0`: ``` Regex "USB((0b05:(1996|1a2[07]))|(0db0:(1feb|419c|a073|151f)))" ``` Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/172 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

MPG X570S EDGE MAX WIFI compatibility
by GitHub issues - opened 18 Jun '22

18 Jun '22

alsa-project/alsa-ucm-conf issue #172 was opened from yhojann-cl: Please, add `0db0:151f` to `realtek-alc4080` chip compatibility in MPG X570S EDGE MAX WIFI motherboard: In `ucm2/USB-Audio/USB-Audio.conf` add `151f` to regex of `0db0`: ``` Regex "USB((0b05:(1996|1a2[07]))|(0db0:(1feb|419c|a073|151f)))" ``` Issue URL : https://github.com/alsa-project/alsa-ucm-conf/issues/172 Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[PATCH 0/2] ASoC: SOF/soundwire: use resume_and_get on component probe
by Pierre-Louis Bossart 18 Jun '22

18 Jun '22

While testing driver bind/unbind sequences, I stumbled on a corner case where the SoundWire bus can be suspended before the ASoC card registration happens. During the registration, register accesses would then lead to timeouts. This does not happen in regular usages where the card registration happens within the 3-second time window before suspend. Adding a simple pm_runtime_resume_and_get() on component probe solves the issue, but experiments showed it was too invasive to add at the ASoC core level, with multiple regressions reported by our CI. This patchset limits the additional resume to the SOF and SoundWire codec drivers. An additional patch for the soundwire/intel component will be sent separately. Pierre-Louis Bossart (2): ASoC: SOF: pcm: use pm_resume_and_get() on component probe ASoC: codecs: soundwire: call pm_runtime_resume() in component probe sound/soc/codecs/max98373.c | 14 +++++++++++++- sound/soc/codecs/rt1308-sdw.c | 12 ++++++++++++ sound/soc/codecs/rt1316-sdw.c | 12 ++++++++++++ sound/soc/codecs/rt700.c | 5 +++++ sound/soc/codecs/rt711-sdca.c | 5 +++++ sound/soc/codecs/rt711.c | 5 +++++ sound/soc/codecs/rt715-sdca.c | 12 ++++++++++++ sound/soc/codecs/rt715.c | 12 ++++++++++++ sound/soc/sof/pcm.c | 11 +++++++++++ 9 files changed, 87 insertions(+), 1 deletion(-) -- 2.34.1

2 9

[PATCH v1] ASoC: ops: Fix integer detection for when max possible values > 1
by Stefan Binding 18 Jun '22

18 Jun '22

The standard snd_soc_info_volsw() allows a two value control to be defined as an integer control only if the control name ends in "Volume". It achieves this by creating a substring if it contains " Volume", and ensuring this exists at the end of the name. The volume substring is then used to decide whether the type is a SNDRV_CTL_ELEM_TYPE_INTEGER or SNDRV_CTL_ELEM_TYPE_BOOLEAN. However this volume substring is only computed for a two value control. This means for controls where there are more than two possible values, the substring is never created, so in this case the substring remains NULL, and the condition yields SNDRV_CTL_ELEM_TYPE_BOOLEAN, even though there are more than 2 possible values. If there are more than 2 possible values for the control, then it should always be an integer control. Fixes: aa2a4b897132 ("ASoC: ops: Fix boolean/integer detection for simple controls") Signed-off-by: Stefan Binding <sbinding(a)opensource.cirrus.com> --- sound/soc/soc-ops.c | 15 +++++++-------- 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/sound/soc/soc-ops.c b/sound/soc/soc-ops.c index 0267e39de2a8..1970bda074d8 100644 --- a/sound/soc/soc-ops.c +++ b/sound/soc/soc-ops.c @@ -183,17 +183,16 @@ int snd_soc_info_volsw(struct snd_kcontrol *kcontrol, if (mc->platform_max && mc->platform_max < max) max = mc->platform_max; - /* Even two value controls ending in Volume should always be integer */ if (max == 1) { + /* Even two value controls ending in Volume should always be integer */ vol_string = strstr(kcontrol->id.name, " Volume"); - if (vol_string && strcmp(vol_string, " Volume")) - vol_string = NULL; - } - - if (!vol_string) - uinfo->type = SNDRV_CTL_ELEM_TYPE_BOOLEAN; - else + if (vol_string && !strcmp(vol_string, " Volume")) + uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER; + else + uinfo->type = SNDRV_CTL_ELEM_TYPE_BOOLEAN; + } else { uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER; + } uinfo->count = snd_soc_volsw_is_stereo(mc) ? 2 : 1; uinfo->value.integer.min = 0; -- 2.25.1

3 2

[PATCH v2] ASoC: mediatek: mt8186: Fix mutex double unlock in GPIO request
by Fei Shao 18 Jun '22

18 Jun '22

The lockdep mechanism revealed an unbalanced unlocking on MT8186: [ 2.993966] WARNING: bad unlock balance detected! [ 2.993978] ------------------------------------- [ 2.993983] kworker/u16:1/10 is trying to release lock (gpio_request_mutex) at: [ 2.993994] [<ffffffdcd9adebf8>] mt8186_afe_gpio_request+0xf8/0x210 [ 2.994012] but there are no more locks to release! The cause is that the mutex will be double unlocked if dai is unknown during GPIO selection, and this patch fixes it. Fixes: cfa9a966f12a ("ASoC: mediatek: mt8186: support gpio control in platform driver") Signed-off-by: Fei Shao <fshao(a)chromium.org> --- Changes in v2: - Trimmed the commit message sound/soc/mediatek/mt8186/mt8186-afe-gpio.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c b/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c index 255ffba637d3..274c0c8ec2f2 100644 --- a/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c +++ b/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c @@ -230,7 +230,6 @@ int mt8186_afe_gpio_request(struct device *dev, bool enable, sel = enable ? MT8186_AFE_GPIO_PCM_ON : MT8186_AFE_GPIO_PCM_OFF; break; default: - mutex_unlock(&gpio_request_mutex); dev_err(dev, "%s(), invalid dai %d\n", __func__, dai); goto unlock; } -- 2.36.1.476.g0c4daa206d-goog

2 1

[PATCH] ASoC: mediatek: mt8186: Fix mutex double unlock in GPIO request
by Fei Shao 18 Jun '22

18 Jun '22

The lockdep mechanism reveals an unbalanced unlocking on MT8186: [ 2.993966] WARNING: bad unlock balance detected! [ 2.993971] 5.15.46-421fef3b44d7-lockdep #16 Not tainted [ 2.993978] ------------------------------------- [ 2.993983] kworker/u16:1/10 is trying to release lock (gpio_request_mutex) at: [ 2.993994] [<ffffffdcd9adebf8>] mt8186_afe_gpio_request+0xf8/0x210 [ 2.994012] but there are no more locks to release! [ 2.994017] [ 2.994017] other info that might help us debug this: [ 2.994022] 3 locks held by kworker/u16:1/10: [ 2.994028] #0: ffffff80c004a148 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x1a8/0x364 [ 2.994054] #1: ffffffc0080d3d58 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work+0x1d0/0x364 [ 2.994074] #2: ffffff80c12ab9a0 (&dev->mutex){....}-{3:3}, at: __device_attach+0x44/0x150 [ 2.994096] [ 2.994096] stack backtrace: [ 2.994102] CPU: 6 PID: 10 Comm: kworker/u16:1 Not tainted 5.15.46-421fef3b44d7-lockdep #16 a2af0e2c6b3eeab6799b5aa8091c1d05d3a7bbb1 [ 2.994113] Hardware name: Google Kingler board (DT) [ 2.994120] Workqueue: events_unbound deferred_probe_work_func [ 2.994130] Call trace: [ 2.994135] dump_backtrace+0x0/0x1d4 [ 2.994144] show_stack+0x20/0x2c [ 2.994152] dump_stack_lvl+0x78/0x9c [ 2.994163] dump_stack+0x18/0x44 [ 2.994172] print_unlock_imbalance_bug+0xf0/0xf4 [ 2.994184] lock_release+0x150/0x388 [ 2.994193] __mutex_unlock_slowpath+0x4c/0x1bc [ 2.994202] mutex_unlock+0x44/0x50 [ 2.994210] mt8186_afe_gpio_request+0xf8/0x210 [ 2.994220] mt8186_afe_gpio_init+0xcc/0x134 [ 2.994230] mt8186_mt6366_rt1019_rt5682s_dev_probe+0x14c/0x220 [ 2.994238] platform_probe+0xb0/0xd0 [ 2.994247] really_probe+0xcc/0x2c8 [ 2.994253] __driver_probe_device+0xbc/0xe8 [ 2.994264] driver_probe_device+0x48/0xf0 [ 2.994271] __device_attach_driver+0xa0/0xc8 [ 2.994278] bus_for_each_drv+0x8c/0xd8 [ 2.994288] __device_attach+0xc4/0x150 [ 2.994298] device_initial_probe+0x1c/0x28 [ 2.994308] bus_probe_device+0x3c/0xa0 [ 2.994318] deferred_probe_work_func+0xa0/0xe0 [ 2.994325] process_one_work+0x208/0x364 [ 2.994334] worker_thread+0x288/0x3fc [ 2.994343] kthread+0x140/0x160 [ 2.994351] ret_from_fork+0x10/0x20 The cause is that the mutex will be double unlocked if dai is unknown during GPIO selection, and this patch fixes it. Fixes: cfa9a966f12a ("ASoC: mediatek: mt8186: support gpio control in platform driver") Signed-off-by: Fei Shao <fshao(a)chromium.org> --- sound/soc/mediatek/mt8186/mt8186-afe-gpio.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c b/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c index 255ffba637d3..274c0c8ec2f2 100644 --- a/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c +++ b/sound/soc/mediatek/mt8186/mt8186-afe-gpio.c @@ -230,7 +230,6 @@ int mt8186_afe_gpio_request(struct device *dev, bool enable, sel = enable ? MT8186_AFE_GPIO_PCM_ON : MT8186_AFE_GPIO_PCM_OFF; break; default: - mutex_unlock(&gpio_request_mutex); dev_err(dev, "%s(), invalid dai %d\n", __func__, dai); goto unlock; } -- 2.36.1.476.g0c4daa206d-goog

2 3

[PATCH 0/3] ASoC: SOF: Intel: fix resume from hibernate
by Pierre-Louis Bossart 18 Jun '22

18 Jun '22

The enablement of IMR-based DSP boot helped reduce resume latency, but unfortunately the context is not saved in S4 and S5 which leads to multiple reports of boot failures. This patchset forces a full firmware reload/reboot when resuming from S4/S5 and restores functionality. Pierre-Louis Bossart (3): ASoC: SOF: pm: add explicit behavior for ACPI S1 and S2 ASoC: SOF: pm: add definitions for S4 and S5 states ASoC: SOF: Intel: disable IMR boot when resuming from ACPI S4 and S5 states sound/soc/sof/intel/hda-loader.c | 3 ++- sound/soc/sof/pm.c | 21 ++++++++++++++++++++- sound/soc/sof/sof-priv.h | 2 ++ 3 files changed, 24 insertions(+), 2 deletions(-) -- 2.34.1

2 4

[PATCH] ASoC: ops: Fix multiple value control type
by Sameer Pujar 18 Jun '22

18 Jun '22

The commit aa2a4b897132("ASoC: ops: Fix boolean/integer detection for simple controls") fixes false positives with controls not ending in " Volume" string. But it now forces boolean type for the multi value controls. Fix this by adding a max check before assigning types. Fixes: aa2a4b897132("ASoC: ops: Fix boolean/integer detection for simple controls") Signed-off-by: Sameer Pujar <spujar(a)nvidia.com> --- sound/soc/soc-ops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/soc-ops.c b/sound/soc/soc-ops.c index 0267e39..21be8e8 100644 --- a/sound/soc/soc-ops.c +++ b/sound/soc/soc-ops.c @@ -190,7 +190,7 @@ int snd_soc_info_volsw(struct snd_kcontrol *kcontrol, vol_string = NULL; } - if (!vol_string) + if (!vol_string && max == 1) uinfo->type = SNDRV_CTL_ELEM_TYPE_BOOLEAN; else uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER; -- 2.7.4

3 2

[PATCH v2 0/3] ASoC: rockchip: i2s: switch BCLK to GPIO
by Judy Hsiao 17 Jun '22

17 Jun '22

The patches series is to fix the unexpected large DC output voltage of Max98357a to burn the speakers on rockchip platform when BCLK and SD_MODE are ON but LRCLK is OFF. Changes Since V2: -- Add documents of i2s pinctrl-names. -- Fix dtsi syntax error. -- Include the dtsi change and the driver change in the same series. -- Ensure that driver gets both bclk_on and bclk_off states before using them. Judy Hsiao (3): ASoC: rockchip: i2s: switch BCLK to GPIO arm64: dts: rk3399: i2s: switch BCLK to GPIO ASoC: dt-bindings: rockchip: Document pinctrl-names for i2s .../bindings/sound/rockchip-i2s.yaml | 7 + .../boot/dts/rockchip/rk3399-gru-scarlet.dtsi | 10 ++ arch/arm64/boot/dts/rockchip/rk3399.dtsi | 25 +++- sound/soc/rockchip/rockchip_i2s.c | 134 ++++++++++++++---- 4 files changed, 149 insertions(+), 27 deletions(-) -- 2.36.1.476.g0c4daa206d-goog

4 14

[PATCH] ASoC: SOF: Intel: hda: Fix compressed stream position tracking
by Pierre-Louis Bossart 17 Jun '22

17 Jun '22

From: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Commit 288fad2f71fa ("ASoC: SOF: Intel: hda: add quirks for HDAudio DMA position information") modified the PCM path only, but left the compressed data patch using an obsolete option. Move the functionality in a helper that can be called for both PCM and compressed data. Reviewed-by: Ranjani Sridharan <ranjani.sridharan(a)linux.intel.com> Fixes: 288fad2f71fa ("ASoC: SOF: Intel: hda: add quirks for HDAudio DMA position information") Signed-off-by: Peter Ujfalusi <peter.ujfalusi(a)linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> --- sound/soc/sof/intel/hda-pcm.c | 74 +------------------------ sound/soc/sof/intel/hda-stream.c | 94 ++++++++++++++++++++++++++++++-- sound/soc/sof/intel/hda.h | 3 + 3 files changed, 94 insertions(+), 77 deletions(-) diff --git a/sound/soc/sof/intel/hda-pcm.c b/sound/soc/sof/intel/hda-pcm.c index dc1f743730c0d..6888e0a4665d2 100644 --- a/sound/soc/sof/intel/hda-pcm.c +++ b/sound/soc/sof/intel/hda-pcm.c @@ -192,79 +192,7 @@ snd_pcm_uframes_t hda_dsp_pcm_pointer(struct snd_sof_dev *sdev, goto found; } - switch (sof_hda_position_quirk) { - case SOF_HDA_POSITION_QUIRK_USE_SKYLAKE_LEGACY: - /* - * This legacy code, inherited from the Skylake driver, - * mixes DPIB registers and DPIB DDR updates and - * does not seem to follow any known hardware recommendations. - * It's not clear e.g. why there is a different flow - * for capture and playback, the only information that matters is - * what traffic class is used, and on all SOF-enabled platforms - * only VC0 is supported so the work-around was likely not necessary - * and quite possibly wrong. - */ - - /* DPIB/posbuf position mode: - * For Playback, Use DPIB register from HDA space which - * reflects the actual data transferred. - * For Capture, Use the position buffer for pointer, as DPIB - * is not accurate enough, its update may be completed - * earlier than the data written to DDR. - */ - if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) { - pos = snd_sof_dsp_read(sdev, HDA_DSP_HDA_BAR, - AZX_REG_VS_SDXDPIB_XBASE + - (AZX_REG_VS_SDXDPIB_XINTERVAL * - hstream->index)); - } else { - /* - * For capture stream, we need more workaround to fix the - * position incorrect issue: - * - * 1. Wait at least 20us before reading position buffer after - * the interrupt generated(IOC), to make sure position update - * happens on frame boundary i.e. 20.833uSec for 48KHz. - * 2. Perform a dummy Read to DPIB register to flush DMA - * position value. - * 3. Read the DMA Position from posbuf. Now the readback - * value should be >= period boundary. - */ - usleep_range(20, 21); - snd_sof_dsp_read(sdev, HDA_DSP_HDA_BAR, - AZX_REG_VS_SDXDPIB_XBASE + - (AZX_REG_VS_SDXDPIB_XINTERVAL * - hstream->index)); - pos = snd_hdac_stream_get_pos_posbuf(hstream); - } - break; - case SOF_HDA_POSITION_QUIRK_USE_DPIB_REGISTERS: - /* - * In case VC1 traffic is disabled this is the recommended option - */ - pos = snd_sof_dsp_read(sdev, HDA_DSP_HDA_BAR, - AZX_REG_VS_SDXDPIB_XBASE + - (AZX_REG_VS_SDXDPIB_XINTERVAL * - hstream->index)); - break; - case SOF_HDA_POSITION_QUIRK_USE_DPIB_DDR_UPDATE: - /* - * This is the recommended option when VC1 is enabled. - * While this isn't needed for SOF platforms it's added for - * consistency and debug. - */ - pos = snd_hdac_stream_get_pos_posbuf(hstream); - break; - default: - dev_err_once(sdev->dev, "hda_position_quirk value %d not supported\n", - sof_hda_position_quirk); - pos = 0; - break; - } - - if (pos >= hstream->bufsize) - pos = 0; - + pos = hda_dsp_stream_get_position(hstream, substream->stream, true); found: pos = bytes_to_frames(substream->runtime, pos); diff --git a/sound/soc/sof/intel/hda-stream.c b/sound/soc/sof/intel/hda-stream.c index daeb64c495e40..d95ae17e81cc4 100644 --- a/sound/soc/sof/intel/hda-stream.c +++ b/sound/soc/sof/intel/hda-stream.c @@ -707,12 +707,13 @@ bool hda_dsp_check_stream_irq(struct snd_sof_dev *sdev) } static void -hda_dsp_set_bytes_transferred(struct hdac_stream *hstream, u64 buffer_size) +hda_dsp_compr_bytes_transferred(struct hdac_stream *hstream, int direction) { + u64 buffer_size = hstream->bufsize; u64 prev_pos, pos, num_bytes; div64_u64_rem(hstream->curr_pos, buffer_size, &prev_pos); - pos = snd_hdac_stream_get_pos_posbuf(hstream); + pos = hda_dsp_stream_get_position(hstream, direction, false); if (pos < prev_pos) num_bytes = (buffer_size - prev_pos) + pos; @@ -748,8 +749,7 @@ static bool hda_dsp_stream_check(struct hdac_bus *bus, u32 status) if (s->substream && sof_hda->no_ipc_position) { snd_sof_pcm_period_elapsed(s->substream); } else if (s->cstream) { - hda_dsp_set_bytes_transferred(s, - s->cstream->runtime->buffer_size); + hda_dsp_compr_bytes_transferred(s, s->cstream->direction); snd_compr_fragment_elapsed(s->cstream); } } @@ -1009,3 +1009,89 @@ void hda_dsp_stream_free(struct snd_sof_dev *sdev) devm_kfree(sdev->dev, hda_stream); } } + +snd_pcm_uframes_t hda_dsp_stream_get_position(struct hdac_stream *hstream, + int direction, bool can_sleep) +{ + struct hdac_ext_stream *hext_stream = stream_to_hdac_ext_stream(hstream); + struct sof_intel_hda_stream *hda_stream = hstream_to_sof_hda_stream(hext_stream); + struct snd_sof_dev *sdev = hda_stream->sdev; + snd_pcm_uframes_t pos; + + switch (sof_hda_position_quirk) { + case SOF_HDA_POSITION_QUIRK_USE_SKYLAKE_LEGACY: + /* + * This legacy code, inherited from the Skylake driver, + * mixes DPIB registers and DPIB DDR updates and + * does not seem to follow any known hardware recommendations. + * It's not clear e.g. why there is a different flow + * for capture and playback, the only information that matters is + * what traffic class is used, and on all SOF-enabled platforms + * only VC0 is supported so the work-around was likely not necessary + * and quite possibly wrong. + */ + + /* DPIB/posbuf position mode: + * For Playback, Use DPIB register from HDA space which + * reflects the actual data transferred. + * For Capture, Use the position buffer for pointer, as DPIB + * is not accurate enough, its update may be completed + * earlier than the data written to DDR. + */ + if (direction == SNDRV_PCM_STREAM_PLAYBACK) { + pos = snd_sof_dsp_read(sdev, HDA_DSP_HDA_BAR, + AZX_REG_VS_SDXDPIB_XBASE + + (AZX_REG_VS_SDXDPIB_XINTERVAL * + hstream->index)); + } else { + /* + * For capture stream, we need more workaround to fix the + * position incorrect issue: + * + * 1. Wait at least 20us before reading position buffer after + * the interrupt generated(IOC), to make sure position update + * happens on frame boundary i.e. 20.833uSec for 48KHz. + * 2. Perform a dummy Read to DPIB register to flush DMA + * position value. + * 3. Read the DMA Position from posbuf. Now the readback + * value should be >= period boundary. + */ + if (can_sleep) + usleep_range(20, 21); + + snd_sof_dsp_read(sdev, HDA_DSP_HDA_BAR, + AZX_REG_VS_SDXDPIB_XBASE + + (AZX_REG_VS_SDXDPIB_XINTERVAL * + hstream->index)); + pos = snd_hdac_stream_get_pos_posbuf(hstream); + } + break; + case SOF_HDA_POSITION_QUIRK_USE_DPIB_REGISTERS: + /* + * In case VC1 traffic is disabled this is the recommended option + */ + pos = snd_sof_dsp_read(sdev, HDA_DSP_HDA_BAR, + AZX_REG_VS_SDXDPIB_XBASE + + (AZX_REG_VS_SDXDPIB_XINTERVAL * + hstream->index)); + break; + case SOF_HDA_POSITION_QUIRK_USE_DPIB_DDR_UPDATE: + /* + * This is the recommended option when VC1 is enabled. + * While this isn't needed for SOF platforms it's added for + * consistency and debug. + */ + pos = snd_hdac_stream_get_pos_posbuf(hstream); + break; + default: + dev_err_once(sdev->dev, "hda_position_quirk value %d not supported\n", + sof_hda_position_quirk); + pos = 0; + break; + } + + if (pos >= hstream->bufsize) + pos = 0; + + return pos; +} diff --git a/sound/soc/sof/intel/hda.h b/sound/soc/sof/intel/hda.h index a3118499e34fc..dc713c20ba1d9 100644 --- a/sound/soc/sof/intel/hda.h +++ b/sound/soc/sof/intel/hda.h @@ -565,6 +565,9 @@ int hda_dsp_stream_setup_bdl(struct snd_sof_dev *sdev, bool hda_dsp_check_ipc_irq(struct snd_sof_dev *sdev); bool hda_dsp_check_stream_irq(struct snd_sof_dev *sdev); +snd_pcm_uframes_t hda_dsp_stream_get_position(struct hdac_stream *hstream, + int direction, bool can_sleep); + struct hdac_ext_stream * hda_dsp_stream_get(struct snd_sof_dev *sdev, int direction, u32 flags); int hda_dsp_stream_put(struct snd_sof_dev *sdev, int direction, int stream_tag); -- 2.34.1

2 1