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

[alsa-devel] [PATCH AUTOSEL 5.4 138/350] ASoC: soc-pcm: fixup dpcm_prune_paths() loop continue
by Sasha Levin 10 Dec '19

10 Dec '19

From: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> [ Upstream commit bed646dc3f7bcec91178c278deaf969cce0700a8 ] dpcm_prune_paths() is checking widget at 2 parts. (A) is for CPU, (B) is for Codec. If we focus to (A) part, continue at (a) is for (1) loop. But, if we focus to (B) part, continue at (b) is for (2) loop, not for (1). This is bug. This patch fixup this issue. static int dpcm_prune_paths(...) { ... (1) for_each_dpcm_be(fe, stream, dpcm) { ... ^ widget = dai_get_widget(...); | (A) if (widget && widget_in_list(...)) | (a) continue; v ^ (2) for_each_rtd_codec_dai(...) { | widget = dai_get_widget(...); (B) | if (widget && widget_in_list(...)) v (b) continue; } ... Fixes: 2e5894d73789 ("ASoC: pcm: Add support for DAI multicodec") Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx(a)renesas.com> Link: https://lore.kernel.org/r/87blui64mf.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/soc-pcm.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c index b600d3eaaf5cd..cdce96a3051bf 100644 --- a/sound/soc/soc-pcm.c +++ b/sound/soc/soc-pcm.c @@ -1385,6 +1385,7 @@ static int dpcm_prune_paths(struct snd_soc_pcm_runtime *fe, int stream, struct snd_soc_dapm_widget *widget; struct snd_soc_dai *dai; int prune = 0; + int do_prune; /* Destroy any old FE <--> BE connections */ for_each_dpcm_be(fe, stream, dpcm) { @@ -1398,13 +1399,16 @@ static int dpcm_prune_paths(struct snd_soc_pcm_runtime *fe, int stream, continue; /* is there a valid CODEC DAI widget for this BE */ + do_prune = 1; for_each_rtd_codec_dai(dpcm->be, i, dai) { widget = dai_get_widget(dai, stream); /* prune the BE if it's no longer in our active list */ if (widget && widget_in_list(list, widget)) - continue; + do_prune = 0; } + if (!do_prune) + continue; dev_dbg(fe->dev, "ASoC: pruning %s BE %s for %s\n", stream ? "capture" : "playback", -- 2.20.1

1 0

[alsa-devel] [PATCH AUTOSEL 5.4 088/350] ASoC: SOF: enable sync_write in hdac_bus
by Sasha Levin 10 Dec '19

10 Dec '19

From: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> [ Upstream commit f3416e7144f5d4ba0fc5dcef6ebfff891266c46a ] Align SOF HDA implementation with snd-hda-intel driver and enable sync_write flag for all supported Intel platforms in SOF. When set, a sync is issued after each verb write. Sync after write has helped to overcome intermittent delays in system resume flow on Intel Coffee Lake systems, and most recently probe errors related to the HDMI codec on Ice Lake systems. Matches the snd-hda-intel driver change done in commit 2756d9143aa5 ("ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips"). Signed-off-by: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Link: https://lore.kernel.org/r/20191008164443.1358-2-pierre-louis.bossart@linux.… Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- sound/soc/sof/intel/hda.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/sof/intel/hda.c b/sound/soc/sof/intel/hda.c index 06e84679087bc..5a5163eef2ef4 100644 --- a/sound/soc/sof/intel/hda.c +++ b/sound/soc/sof/intel/hda.c @@ -268,6 +268,7 @@ static int hda_init(struct snd_sof_dev *sdev) bus->use_posbuf = 1; bus->bdl_pos_adj = 0; + bus->sync_write = 1; mutex_init(&hbus->prepare_mutex); hbus->pci = pci; -- 2.20.1

1 0

Re: [alsa-devel] [PATCH v3 03/15] soc: tegra: Add Tegra PMC clock registrations into PMC driver
by Dmitry Osipenko 10 Dec '19

10 Dec '19

10.12.2019 22:18, Sowjanya Komatineni пишет: > > On 12/10/19 10:30 AM, Dmitry Osipenko wrote: >> 10.12.2019 20:48, Sowjanya Komatineni пишет: >>> On 12/10/19 9:41 AM, Dmitry Osipenko wrote: >>>> 09.12.2019 23:46, Sowjanya Komatineni пишет: >>>>> On 12/9/19 12:12 PM, Dmitry Osipenko wrote: >>>>>> 08.12.2019 00:36, Sowjanya Komatineni пишет: >>>>>>> On 12/7/19 11:59 AM, Sowjanya Komatineni wrote: >>>>>>>> On 12/7/19 8:00 AM, Dmitry Osipenko wrote: >>>>>>>>> 07.12.2019 18:53, Dmitry Osipenko пишет: >>>>>>>>>> 07.12.2019 18:47, Dmitry Osipenko пишет: >>>>>>>>>>> 07.12.2019 17:28, Dmitry Osipenko пишет: >>>>>>>>>>>> 06.12.2019 05:48, Sowjanya Komatineni пишет: >>>>>>>>>>>>> Tegra210 and prior Tegra PMC has clk_out_1, clk_out_2, >>>>>>>>>>>>> clk_out_3 >>>>>>>>>>>>> with >>>>>>>>>>>>> mux and gate for each of these clocks. >>>>>>>>>>>>> >>>>>>>>>>>>> Currently these PMC clocks are registered by Tegra clock >>>>>>>>>>>>> driver >>>>>>>>>>>>> using >>>>>>>>>>>>> clk_register_mux and clk_register_gate by passing PMC base >>>>>>>>>>>>> address >>>>>>>>>>>>> and register offsets and PMC programming for these clocks >>>>>>>>>>>>> happens >>>>>>>>>>>>> through direct PMC access by the clock driver. >>>>>>>>>>>>> >>>>>>>>>>>>> With this, when PMC is in secure mode any direct PMC access >>>>>>>>>>>>> from the >>>>>>>>>>>>> non-secure world does not go through and these clocks will >>>>>>>>>>>>> not be >>>>>>>>>>>>> functional. >>>>>>>>>>>>> >>>>>>>>>>>>> This patch adds these clocks registration with PMC as a clock >>>>>>>>>>>>> provider >>>>>>>>>>>>> for these clocks. clk_ops callback implementations for these >>>>>>>>>>>>> clocks >>>>>>>>>>>>> uses tegra_pmc_readl and tegra_pmc_writel which supports PMC >>>>>>>>>>>>> programming >>>>>>>>>>>>> in secure mode and non-secure mode. >>>>>>>>>>>>> >>>>>>>>>>>>> Signed-off-by: Sowjanya Komatineni <skomatineni(a)nvidia.com> >>>>>>>>>>>>> --- >>>>>>>>>>> [snip] >>>>>>>>>>> >>>>>>>>>>>>> + >>>>>>>>>>>>> +static const struct clk_ops pmc_clk_gate_ops = { >>>>>>>>>>>>> + .is_enabled = pmc_clk_is_enabled, >>>>>>>>>>>>> + .enable = pmc_clk_enable, >>>>>>>>>>>>> + .disable = pmc_clk_disable, >>>>>>>>>>>>> +}; >>>>>>>>>>>> What's the benefit of separating GATE from the MUX? >>>>>>>>>>>> >>>>>>>>>>>> I think it could be a single clock. >>>>>>>>>>> According to TRM: >>>>>>>>>>> >>>>>>>>>>> 1. GATE and MUX are separate entities. >>>>>>>>>>> >>>>>>>>>>> 2. GATE is the parent of MUX (see PMC's CLK_OUT paths diagram in >>>>>>>>>>> TRM). >>>>>>>>>>> >>>>>>>>>>> 3. PMC doesn't gate EXTPERIPH clock but could "force-enable" it, >>>>>>>>>>> correct? >>>>>>> Was following existing clk-tegra-pmc as I am not sure of reason for >>>>>>> having these clocks registered as separate mux and gate clocks. >>>>>>> >>>>>>> Yes, PMC clocks can be registered as single clock and can use >>>>>>> clk_ops >>>>>>> for set/get parent and enable/disable. >>>>>>> >>>>>>> enable/disable of PMC clocks is for force-enable to force the >>>>>>> clock to >>>>>>> run regardless of ACCEPT_REQ or INVERT_REQ. >>>>>>> >>>>>>>>>> 4. clk_m_div2/4 are internal PMC OSC dividers and thus these >>>>>>>>>> clocks >>>>>>>>>> should belong to PMC. >>>>>>>>> Also, it should be "osc" and not "clk_m". >>>>>>>> I followed the same parents as it were in existing clk-tegra-pmc >>>>>>>> driver. >>>>>>>> >>>>>>>> Yeah they are wrong and they should be from osc and not clk_m. >>>>>>>> >>>>>>>> Will fix in next version. >>>>>>>> >>>>>> Could you please describe the full EXTPERIPH clock topology and >>>>>> how the >>>>>> pinmux configuration is related to it all? >>>>>> >>>>>> What is internal to the Tegra chip and what are the external outputs? >>>>>> >>>>>> Is it possible to bypass PMC on T30+ for the EXTPERIPH clocks? >>>>> PMC CLK1/2/3 possible sources are OSC_DIV1, OSC_DIV2, OSC_DIV4, >>>>> EXTPERIPH from CAR. >>>>> >>>>> OSC_DIV1/2/4 are with internal dividers at the OSC Pads >>>>> >>>>> EXTPERIPH is from CAR and it has reset and enable controls along with >>>>> clock source selections to choose one of the PLLA_OUT0, CLK_S, >>>>> PLLP_OUT0, CLK_M, PLLE_OUT0 >>>> Are you sure that EXTPERIPH has a reset? What will it reset? Why it's >>>> not documented in TRM? >>> Yes, Extperiph1/2/3 has RST part of CAR RST_DEVICES_V bits 24/25/26 >> Are these bits not documented in a public TRMs? I checked >> T30/114/124/210 TRMs and CLK_RST_CONTROLLER_RST_DEVICES_V_0 doesn't have >> those bits in the docs. >> > Yeah these bits are missing in all Tegra TRM docs. Will request for > having EXTPERIPH reset bits to be updated in TRM... Thanks

1 0

Re: [alsa-devel] [PATCH v3 03/15] soc: tegra: Add Tegra PMC clock registrations into PMC driver
by Dmitry Osipenko 10 Dec '19

10 Dec '19

10.12.2019 20:48, Sowjanya Komatineni пишет: > > On 12/10/19 9:41 AM, Dmitry Osipenko wrote: >> 09.12.2019 23:46, Sowjanya Komatineni пишет: >>> On 12/9/19 12:12 PM, Dmitry Osipenko wrote: >>>> 08.12.2019 00:36, Sowjanya Komatineni пишет: >>>>> On 12/7/19 11:59 AM, Sowjanya Komatineni wrote: >>>>>> On 12/7/19 8:00 AM, Dmitry Osipenko wrote: >>>>>>> 07.12.2019 18:53, Dmitry Osipenko пишет: >>>>>>>> 07.12.2019 18:47, Dmitry Osipenko пишет: >>>>>>>>> 07.12.2019 17:28, Dmitry Osipenko пишет: >>>>>>>>>> 06.12.2019 05:48, Sowjanya Komatineni пишет: >>>>>>>>>>> Tegra210 and prior Tegra PMC has clk_out_1, clk_out_2, clk_out_3 >>>>>>>>>>> with >>>>>>>>>>> mux and gate for each of these clocks. >>>>>>>>>>> >>>>>>>>>>> Currently these PMC clocks are registered by Tegra clock driver >>>>>>>>>>> using >>>>>>>>>>> clk_register_mux and clk_register_gate by passing PMC base address >>>>>>>>>>> and register offsets and PMC programming for these clocks happens >>>>>>>>>>> through direct PMC access by the clock driver. >>>>>>>>>>> >>>>>>>>>>> With this, when PMC is in secure mode any direct PMC access >>>>>>>>>>> from the >>>>>>>>>>> non-secure world does not go through and these clocks will not be >>>>>>>>>>> functional. >>>>>>>>>>> >>>>>>>>>>> This patch adds these clocks registration with PMC as a clock >>>>>>>>>>> provider >>>>>>>>>>> for these clocks. clk_ops callback implementations for these >>>>>>>>>>> clocks >>>>>>>>>>> uses tegra_pmc_readl and tegra_pmc_writel which supports PMC >>>>>>>>>>> programming >>>>>>>>>>> in secure mode and non-secure mode. >>>>>>>>>>> >>>>>>>>>>> Signed-off-by: Sowjanya Komatineni <skomatineni(a)nvidia.com> >>>>>>>>>>> --- >>>>>>>>> [snip] >>>>>>>>> >>>>>>>>>>> + >>>>>>>>>>> +static const struct clk_ops pmc_clk_gate_ops = { >>>>>>>>>>> + .is_enabled = pmc_clk_is_enabled, >>>>>>>>>>> + .enable = pmc_clk_enable, >>>>>>>>>>> + .disable = pmc_clk_disable, >>>>>>>>>>> +}; >>>>>>>>>> What's the benefit of separating GATE from the MUX? >>>>>>>>>> >>>>>>>>>> I think it could be a single clock. >>>>>>>>> According to TRM: >>>>>>>>> >>>>>>>>> 1. GATE and MUX are separate entities. >>>>>>>>> >>>>>>>>> 2. GATE is the parent of MUX (see PMC's CLK_OUT paths diagram in >>>>>>>>> TRM). >>>>>>>>> >>>>>>>>> 3. PMC doesn't gate EXTPERIPH clock but could "force-enable" it, >>>>>>>>> correct? >>>>> Was following existing clk-tegra-pmc as I am not sure of reason for >>>>> having these clocks registered as separate mux and gate clocks. >>>>> >>>>> Yes, PMC clocks can be registered as single clock and can use clk_ops >>>>> for set/get parent and enable/disable. >>>>> >>>>> enable/disable of PMC clocks is for force-enable to force the clock to >>>>> run regardless of ACCEPT_REQ or INVERT_REQ. >>>>> >>>>>>>> 4. clk_m_div2/4 are internal PMC OSC dividers and thus these clocks >>>>>>>> should belong to PMC. >>>>>>> Also, it should be "osc" and not "clk_m". >>>>>> I followed the same parents as it were in existing clk-tegra-pmc >>>>>> driver. >>>>>> >>>>>> Yeah they are wrong and they should be from osc and not clk_m. >>>>>> >>>>>> Will fix in next version. >>>>>> >>>> Could you please describe the full EXTPERIPH clock topology and how the >>>> pinmux configuration is related to it all? >>>> >>>> What is internal to the Tegra chip and what are the external outputs? >>>> >>>> Is it possible to bypass PMC on T30+ for the EXTPERIPH clocks? >>> PMC CLK1/2/3 possible sources are OSC_DIV1, OSC_DIV2, OSC_DIV4, >>> EXTPERIPH from CAR. >>> >>> OSC_DIV1/2/4 are with internal dividers at the OSC Pads >>> >>> EXTPERIPH is from CAR and it has reset and enable controls along with >>> clock source selections to choose one of the PLLA_OUT0, CLK_S, >>> PLLP_OUT0, CLK_M, PLLE_OUT0 >> Are you sure that EXTPERIPH has a reset? What will it reset? Why it's >> not documented in TRM? > Yes, Extperiph1/2/3 has RST part of CAR RST_DEVICES_V bits 24/25/26 Are these bits not documented in a public TRMs? I checked T30/114/124/210 TRMs and CLK_RST_CONTROLLER_RST_DEVICES_V_0 doesn't have those bits in the docs. >>> So, PMC CLK1/2/4 possible parents are OSC_DIV1, OSC_DIV2, OSC_DIV4, EXTERN. >>> >>> >>> CLK1/2/3 also has Pinmux to route EXTPERIPH output on to these pins. >> Could you please clarify what are "these" pins? Perhaps you meant the >> EXTERN pin of PMC? > By CLK1/2/3 pins, I am referring to CLK_OUT_1/2/3 pins from Tegra I see now what you meant, thanks. [snip}

1 0

Re: [alsa-devel] [PATCH v3 03/15] soc: tegra: Add Tegra PMC clock registrations into PMC driver
by Dmitry Osipenko 10 Dec '19

10 Dec '19

09.12.2019 23:46, Sowjanya Komatineni пишет: > > On 12/9/19 12:12 PM, Dmitry Osipenko wrote: >> 08.12.2019 00:36, Sowjanya Komatineni пишет: >>> On 12/7/19 11:59 AM, Sowjanya Komatineni wrote: >>>> On 12/7/19 8:00 AM, Dmitry Osipenko wrote: >>>>> 07.12.2019 18:53, Dmitry Osipenko пишет: >>>>>> 07.12.2019 18:47, Dmitry Osipenko пишет: >>>>>>> 07.12.2019 17:28, Dmitry Osipenko пишет: >>>>>>>> 06.12.2019 05:48, Sowjanya Komatineni пишет: >>>>>>>>> Tegra210 and prior Tegra PMC has clk_out_1, clk_out_2, clk_out_3 >>>>>>>>> with >>>>>>>>> mux and gate for each of these clocks. >>>>>>>>> >>>>>>>>> Currently these PMC clocks are registered by Tegra clock driver >>>>>>>>> using >>>>>>>>> clk_register_mux and clk_register_gate by passing PMC base address >>>>>>>>> and register offsets and PMC programming for these clocks happens >>>>>>>>> through direct PMC access by the clock driver. >>>>>>>>> >>>>>>>>> With this, when PMC is in secure mode any direct PMC access >>>>>>>>> from the >>>>>>>>> non-secure world does not go through and these clocks will not be >>>>>>>>> functional. >>>>>>>>> >>>>>>>>> This patch adds these clocks registration with PMC as a clock >>>>>>>>> provider >>>>>>>>> for these clocks. clk_ops callback implementations for these >>>>>>>>> clocks >>>>>>>>> uses tegra_pmc_readl and tegra_pmc_writel which supports PMC >>>>>>>>> programming >>>>>>>>> in secure mode and non-secure mode. >>>>>>>>> >>>>>>>>> Signed-off-by: Sowjanya Komatineni <skomatineni(a)nvidia.com> >>>>>>>>> --- >>>>>>> [snip] >>>>>>> >>>>>>>>> + >>>>>>>>> +static const struct clk_ops pmc_clk_gate_ops = { >>>>>>>>> + .is_enabled = pmc_clk_is_enabled, >>>>>>>>> + .enable = pmc_clk_enable, >>>>>>>>> + .disable = pmc_clk_disable, >>>>>>>>> +}; >>>>>>>> What's the benefit of separating GATE from the MUX? >>>>>>>> >>>>>>>> I think it could be a single clock. >>>>>>> According to TRM: >>>>>>> >>>>>>> 1. GATE and MUX are separate entities. >>>>>>> >>>>>>> 2. GATE is the parent of MUX (see PMC's CLK_OUT paths diagram in >>>>>>> TRM). >>>>>>> >>>>>>> 3. PMC doesn't gate EXTPERIPH clock but could "force-enable" it, >>>>>>> correct? >>> Was following existing clk-tegra-pmc as I am not sure of reason for >>> having these clocks registered as separate mux and gate clocks. >>> >>> Yes, PMC clocks can be registered as single clock and can use clk_ops >>> for set/get parent and enable/disable. >>> >>> enable/disable of PMC clocks is for force-enable to force the clock to >>> run regardless of ACCEPT_REQ or INVERT_REQ. >>> >>>>>> 4. clk_m_div2/4 are internal PMC OSC dividers and thus these clocks >>>>>> should belong to PMC. >>>>> Also, it should be "osc" and not "clk_m". >>>> I followed the same parents as it were in existing clk-tegra-pmc >>>> driver. >>>> >>>> Yeah they are wrong and they should be from osc and not clk_m. >>>> >>>> Will fix in next version. >>>> >> Could you please describe the full EXTPERIPH clock topology and how the >> pinmux configuration is related to it all? >> >> What is internal to the Tegra chip and what are the external outputs? >> >> Is it possible to bypass PMC on T30+ for the EXTPERIPH clocks? > > PMC CLK1/2/3 possible sources are OSC_DIV1, OSC_DIV2, OSC_DIV4, > EXTPERIPH from CAR. > > OSC_DIV1/2/4 are with internal dividers at the OSC Pads > > EXTPERIPH is from CAR and it has reset and enable controls along with > clock source selections to choose one of the PLLA_OUT0, CLK_S, > PLLP_OUT0, CLK_M, PLLE_OUT0 Are you sure that EXTPERIPH has a reset? What will it reset? Why it's not documented in TRM? > So, PMC CLK1/2/4 possible parents are OSC_DIV1, OSC_DIV2, OSC_DIV4, EXTERN. > > > CLK1/2/3 also has Pinmux to route EXTPERIPH output on to these pins. Could you please clarify what are "these" pins? Perhaps you meant the EXTERN pin of PMC? > When EXTERN output clock is selected for these PMC clocks thru > CLKx_SRC_SEL, output clock is from driver by EXTPERIPH from CAR via > Pinmux logic or driven as per CLKx_SRC_SEL bypassing pinmux based on > CLKx_ACCEPT_REQ bit. > > > PMC Clock control register has bit CLKx_ACCEPT_REQ > When CLKx_ACCEPT_REQ = 0, output clock driver is from by EXTPERIPH > through the pinmux > When CLKx_ACCEPT_REQ = 1, output clock is based on CLKx_SRC_SEL bits > (OSC_DIV1/2/4 and EXTPERIPH clock bypassing the pinmux) > > FORCE_EN bit in PMC CLock control register forces the clock to run > regardless of this. Okay.

1 0

[alsa-devel] [PATCH] ALSA: pcm: Fill silence on buffers at hw_params
by Takashi Iwai 10 Dec '19

10 Dec '19

The current PCM code doesn't initialize explicitly the buffers allocated for PCM streams, hence it might leak some uninitialized kernel data by mmapping or reading the buffer before actually reading or writing. Since this is a common problem, let's initialize the data on the buffers each hw_params properly. For that, an existing helper function is exposed as snd_pcm_fill_silence_frames() and call it from snd_pcm_hw_params(). Reported-and-tested-by: Lionel Koenig <lionel.koenig(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- sound/core/pcm_lib.c | 13 ++++--------- sound/core/pcm_local.h | 2 ++ sound/core/pcm_native.c | 3 +++ 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/sound/core/pcm_lib.c b/sound/core/pcm_lib.c index 2236b5e0c1f2..3c63324b8bb7 100644 --- a/sound/core/pcm_lib.c +++ b/sound/core/pcm_lib.c @@ -30,9 +30,6 @@ #define trace_applptr(substream, prev, curr) #endif -static int fill_silence_frames(struct snd_pcm_substream *substream, - snd_pcm_uframes_t off, snd_pcm_uframes_t frames); - /* * fill ring buffer with silence * runtime->silence_start: starting pointer to silence area @@ -100,7 +97,7 @@ void snd_pcm_playback_silence(struct snd_pcm_substream *substream, snd_pcm_ufram ofs = runtime->silence_start % runtime->buffer_size; while (frames > 0) { transfer = ofs + frames > runtime->buffer_size ? runtime->buffer_size - ofs : frames; - err = fill_silence_frames(substream, ofs, transfer); + err = snd_pcm_fill_silence_frames(substream, ofs, transfer); snd_BUG_ON(err < 0); runtime->silence_filled += transfer; frames -= transfer; @@ -1945,8 +1942,6 @@ static int fill_silence(struct snd_pcm_substream *substream, int channel, { struct snd_pcm_runtime *runtime = substream->runtime; - if (substream->stream != SNDRV_PCM_STREAM_PLAYBACK) - return 0; if (substream->ops->fill_silence) return substream->ops->fill_silence(substream, channel, hwoff, bytes); @@ -2030,10 +2025,10 @@ static int noninterleaved_copy(struct snd_pcm_substream *substream, } /* fill silence on the given buffer position; - * called from snd_pcm_playback_silence() + * called from snd_pcm_playback_silence() and snd_pcm_hw_params() */ -static int fill_silence_frames(struct snd_pcm_substream *substream, - snd_pcm_uframes_t off, snd_pcm_uframes_t frames) +int snd_pcm_fill_silence_frames(struct snd_pcm_substream *substream, + snd_pcm_uframes_t off, snd_pcm_uframes_t frames) { if (substream->runtime->access == SNDRV_PCM_ACCESS_RW_INTERLEAVED || substream->runtime->access == SNDRV_PCM_ACCESS_MMAP_INTERLEAVED) diff --git a/sound/core/pcm_local.h b/sound/core/pcm_local.h index 384efd002984..ac4f455b1fff 100644 --- a/sound/core/pcm_local.h +++ b/sound/core/pcm_local.h @@ -34,6 +34,8 @@ int snd_pcm_update_hw_ptr(struct snd_pcm_substream *substream); void snd_pcm_playback_silence(struct snd_pcm_substream *substream, snd_pcm_uframes_t new_hw_ptr); +int snd_pcm_fill_silence_frames(struct snd_pcm_substream *substream, + snd_pcm_uframes_t off, snd_pcm_uframes_t frames); static inline snd_pcm_uframes_t snd_pcm_avail(struct snd_pcm_substream *substream) diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index 1fe581167b7b..d6f270c639b4 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -739,6 +739,9 @@ static int snd_pcm_hw_params(struct snd_pcm_substream *substream, while (runtime->boundary * 2 <= LONG_MAX - runtime->buffer_size) runtime->boundary *= 2; + /* clear the buffer once for avoiding information leaks */ + snd_pcm_fill_silence_frames(substream, 0, runtime->period_size); + snd_pcm_timer_resolution_change(substream); snd_pcm_set_state(substream, SNDRV_PCM_STATE_SETUP); -- 2.16.4

1 1

[alsa-devel] [PATCH] ALSA: hda/hdmi - Fix duplicate unref of pci_dev
by Lukas Wunner 10 Dec '19

10 Dec '19

Nicholas Johnson reports a null pointer deref as well as a refcount underflow upon hot-removal of a Thunderbolt-attached AMD eGPU. He's bisected the issue down to commit 586bc4aab878 ("ALSA: hda/hdmi - fix vgaswitcheroo detection for AMD"). The commit iterates over PCI devices using pci_get_class() and unreferences each device found, even though pci_get_class() subsequently unreferences the device as well. Fix it. Fixes: 586bc4aab878 ("ALSA: hda/hdmi - fix vgaswitcheroo detection for AMD") Link: https://lore.kernel.org/r/PSXP216MB0438BFEAA0617283A834E11580580@PSXP216MB0… Reported-and-tested-by: Nicholas Johnson <nicholas.johnson-opensource(a)outlook.com.au> Signed-off-by: Lukas Wunner <lukas(a)wunner.de> Cc: Mika Westerberg <mika.westerberg(a)linux.intel.com> Cc: Alexander Deucher <alexander.deucher(a)amd.com> Cc: Bjorn Helgaas <helgaas(a)kernel.org> --- sound/pci/hda/hda_intel.c | 1 - 1 file changed, 1 deletion(-) diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 35b4526f0d28..b856b89378ac 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1419,7 +1419,6 @@ static bool atpx_present(void) return true; } } - pci_dev_put(pdev); } return false; } -- 2.24.0

4 9

[alsa-devel] [PATCH 5.6 00/71] ALSA: Use managed buffer allocation
by Takashi Iwai 10 Dec '19

10 Dec '19

Hi, we already got a PCM core extension in 5.5-rc1 for allocating / releasing the PCM buffers implicitly, so called managed buffer allocation mode. This patch set is to apply this new mode for the actual (non-ASoC) drivers. The patches for ASoC and the other subsystems will follow in later patch sets. Also, other PCM API changes will follow later, too. This won't change anything from the functional POV, but merely cleanups. Takashi === Takashi Iwai (71): ALSA: aoa: Use managed buffer allocation ALSA: aaci: Use managed buffer allocation ALSA: atmel: Use managed buffer allocation ALSA: aloop: Use managed buffer allocation ALSA: dummy: Use managed buffer allocation ALSA: ml403: Use managed buffer allocation ALSA: pcsp: Use managed buffer allocation ALSA: vx: Use managed buffer allocation ALSA: firewire: Use managed buffer allocation ALSA: ad1816a: Use managed buffer allocation ALSA: cmi8330: Use managed buffer allocation ALSA: es1688: Use managed buffer allocation ALSA: es18xx: Use managed buffer allocation ALSA: sb: Use managed buffer allocation ALSA: gus: Use managed buffer allocation ALSA: wss: Use managed buffer allocation ALSA: mips: Use managed buffer allocation ALSA: parisc: Use managed buffer allocation ALSA: ad1889: Use managed buffer allocation ALSA: ali5451: Use managed buffer allocation ALSA: als300: Use managed buffer allocation ALSA: als4000: Use managed buffer allocation ALSA: asihpi: Use managed buffer allocation ALSA: atiixp: Use managed buffer allocation ALSA: au88x0: Use managed buffer allocation ALSA: aw2: Use managed buffer allocation ALSA: azt3328: Use managed buffer allocation ALSA: bt87x: Use managed buffer allocation ALSA: ca0106: Use managed buffer allocation ALSA: cmipci: Use managed buffer allocation ALSA: cs4281: Use managed buffer allocation ALSA: cs5535: Use managed buffer allocation ALSA: ctxfi: Use managed buffer allocation ALSA: echoaudio: Use managed buffer allocation ALSA: emu10k1x: Use managed buffer allocation ALSA: emu10k1: Use managed buffer allocation ALSA: ens137x: Use managed buffer allocation ALSA: es1938: Use managed buffer allocation ALSA: fm801: Use managed buffer allocation ALSA: hda: Use managed buffer allocation ALSA: ice1712: Use managed buffer allocation ALSA: ice1724: Use managed buffer allocation ALSA: intel8x0: Use managed buffer allocation ALSA: lola: Use managed buffer allocation ALSA: lx6464es: Use managed buffer allocation ALSA: maestro3: Use managed buffer allocation ALSA: mixart: Use managed buffer allocation ALSA: oxygen: Use managed buffer allocation ALSA: pcxhr: Use managed buffer allocation ALSA: riptide: Use managed buffer allocation ALSA: rme32: Use managed buffer allocation ALSA: sis7019: Use managed buffer allocation ALSA: sonicvibes: Use managed buffer allocation ALSA: trident: Use managed buffer allocation ALSA: via82xx: Use managed buffer allocation ALSA: ymfpci: Use managed buffer allocation ALSA: pdaudiocf: Use managed buffer allocation ALSA: pmac: Use managed buffer allocation ALSA: ps3: Use managed buffer allocation ALSA: aica: Use managed buffer allocation ALSA: sh: Use managed buffer allocation ALSA: sparc: Use managed buffer allocation ALSA: spi: Use managed buffer allocation ALSA: 6fire: Use managed buffer allocation ALSA: caiaq: Use managed buffer allocation ALSA: hiface: Use managed buffer allocation ALSA: line6: Use managed buffer allocation ALSA: ua101: Use managed buffer allocation ALSA: usx2y: Use managed buffer allocation ALSA: usb-audio: Use managed buffer allocation ALSA: hdml-lpe-audio: Use managed buffer allocation sound/aoa/soundbus/i2sbus/pcm.c | 11 +------ sound/arm/aaci.c | 40 +++++++++-------------- sound/atmel/ac97c.c | 20 ++---------- sound/drivers/aloop.c | 12 ++----- sound/drivers/dummy.c | 14 ++------ sound/drivers/ml403-ac97cr.c | 29 +++-------------- sound/drivers/pcsp/pcsp_lib.c | 17 ++++------ sound/drivers/vx/vx_pcm.c | 27 ++------------- sound/firewire/bebob/bebob_pcm.c | 11 ++----- sound/firewire/dice/dice-pcm.c | 13 +++----- sound/firewire/digi00x/digi00x-pcm.c | 11 ++----- sound/firewire/fireface/ff-pcm.c | 9 ++--- sound/firewire/fireworks/fireworks_pcm.c | 11 ++----- sound/firewire/isight.c | 10 ++---- sound/firewire/motu/motu-pcm.c | 11 ++----- sound/firewire/oxfw/oxfw-pcm.c | 17 +++------- sound/firewire/tascam/tascam-pcm.c | 11 ++----- sound/isa/ad1816a/ad1816a_lib.c | 20 ++---------- sound/isa/cmi8330.c | 5 ++- sound/isa/es1688/es1688_lib.c | 20 ++---------- sound/isa/es18xx.c | 24 +++----------- sound/isa/gus/gus_pcm.c | 28 +++++----------- sound/isa/sb/sb16_main.c | 21 ++---------- sound/isa/sb/sb8_main.c | 21 ++---------- sound/isa/wss/wss_lib.c | 23 ++----------- sound/mips/hal2.c | 25 ++------------ sound/mips/sgio2audio.c | 20 ++---------- sound/parisc/harmony.c | 18 +++------- sound/pci/ad1889.c | 24 ++------------ sound/pci/ali5451/ali5451.c | 30 ++--------------- sound/pci/als300.c | 23 ++----------- sound/pci/als4000.c | 23 ++----------- sound/pci/asihpi/asihpi.c | 10 ++---- sound/pci/atiixp.c | 14 +++----- sound/pci/atiixp_modem.c | 9 ++--- sound/pci/au88x0/au88x0_pcm.c | 15 ++------- sound/pci/aw2/aw2-alsa.c | 45 +++++++------------------ sound/pci/azt3328.c | 30 +++-------------- sound/pci/bt87x.c | 14 +++----- sound/pci/ca0106/ca0106_main.c | 56 ++++---------------------------- sound/pci/cmipci.c | 36 ++++++-------------- sound/pci/cs4281.c | 20 ++---------- sound/pci/cs5535audio/cs5535audio_pcm.c | 12 +++---- sound/pci/ctxfi/ctpcm.c | 15 +++------ sound/pci/echoaudio/echoaudio.c | 19 +++-------- sound/pci/emu10k1/emu10k1x.c | 15 ++++----- sound/pci/emu10k1/emupcm.c | 41 ++++------------------- sound/pci/emu10k1/p16v.c | 48 ++++----------------------- sound/pci/ens1370.c | 27 +++------------ sound/pci/es1938.c | 28 ++-------------- sound/pci/fm801.c | 20 ++---------- sound/pci/hda/hda_controller.c | 13 +++----- sound/pci/ice1712/ice1712.c | 42 +++++------------------- sound/pci/ice1712/ice1724.c | 25 +++++--------- sound/pci/intel8x0.c | 11 +++---- sound/pci/intel8x0m.c | 23 +++---------- sound/pci/lola/lola_pcm.c | 11 +++---- sound/pci/lx6464es/lx6464es.c | 14 ++------ sound/pci/maestro3.c | 9 ++--- sound/pci/mixart/mixart.c | 14 +++----- sound/pci/oxygen/oxygen_pcm.c | 52 +++++++++++++---------------- sound/pci/pcxhr/pcxhr.c | 31 ++++-------------- sound/pci/riptide/riptide.c | 10 +++--- sound/pci/rme32.c | 35 ++++---------------- sound/pci/sis7019.c | 25 ++------------ sound/pci/sonicvibes.c | 20 ++---------- sound/pci/trident/trident_main.c | 49 +++++++++++----------------- sound/pci/via82xx.c | 45 ++++++++++--------------- sound/pci/via82xx_modem.c | 9 ++--- sound/pci/ymfpci/ymfpci_main.c | 33 +++++-------------- sound/pcmcia/pdaudiocf/pdaudiocf_pcm.c | 25 ++------------ sound/ppc/pmac.c | 28 ++-------------- sound/ppc/snd_ps3.c | 28 +++------------- sound/sh/aica.c | 29 +++-------------- sound/sh/sh_dac_audio.c | 20 ++---------- sound/sparc/amd7930.c | 20 ++---------- sound/sparc/cs4231.c | 17 ++-------- sound/sparc/dbri.c | 13 ++------ sound/spi/at73c213.c | 11 ++----- sound/usb/6fire/pcm.c | 17 +--------- sound/usb/caiaq/audio.c | 13 ++------ sound/usb/hiface/pcm.c | 18 ++-------- sound/usb/line6/pcm.c | 13 ++------ sound/usb/misc/ua101.c | 23 +++---------- sound/usb/pcm.c | 15 +++------ sound/usb/usx2y/usbusx2yaudio.c | 26 +++++---------- sound/usb/usx2y/usx2yhwdeppcm.c | 18 +++++----- sound/x86/intel_hdmi_audio.c | 16 ++++----- 88 files changed, 402 insertions(+), 1492 deletions(-) -- 2.16.4

2 76

[alsa-devel] [PATCH for-5.6 0/2] usb:gadget: ALSA PCM API updates
by Takashi Iwai 10 Dec '19

10 Dec '19

Hi, this is a patch set to adapt the latest ALSA PCM API to staging drivers. Basically these are merely cleanups, as shown in diffstat, and there should be no functional changes. As the corresponding ALSA PCM API change is found in 5.5-rc1, please apply these on 5.5-rc1 or later. Or if you prefer, I can merge them through sound tree, too. Let me know. thanks, Takashi === Takashi Iwai (2): usb: gadget: u_audio: Use managed buffer allocation usb: gadget: u_audio: Drop superfluous ioctl PCM ops drivers/usb/gadget/function/u_audio.c | 19 ++----------------- 1 file changed, 2 insertions(+), 17 deletions(-) -- 2.16.4

1 2

[alsa-devel] [PATCH 0/2] ASoC: topology: fix error handling
by Pierre-Louis Bossart 10 Dec '19

10 Dec '19

Two additional patches from Dragos to deal with errors with bad topologies, reviewed on GitHub last week. https://github.com/thesofproject/linux/pull/1598 Thanks Dragos! Dragos Tarcatu (2): ASoC: topology: Check return value for snd_soc_add_dai_link() ASoC: topology: Check return value for soc_tplg_pcm_create() sound/soc/soc-topology.c | 27 ++++++++++++++++++++------- 1 file changed, 20 insertions(+), 7 deletions(-) -- 2.20.1

2 4