--- /dev/null
+From 4d9e9153f1c64d91a125c6967bc0bfb0bb653ea0 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Mon, 9 Aug 2021 09:18:29 +0200
+Subject: ALSA: pci: cs46xx: Fix set up buffer type properly
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 4d9e9153f1c64d91a125c6967bc0bfb0bb653ea0 upstream.
+
+CS46xx driver switches the buffer depending on the number of periods,
+and in some cases it switches to the own buffer without updating the
+buffer type properly. This may cause a problem with the mmap on
+exotic architectures that require the own mmap call for the coherent
+DMA buffer.
+
+This patch addresses the potential breakage by replacing the buffer
+setup with the proper macro. It also simplifies the source code,
+too.
+
+Link: https://lore.kernel.org/r/20210809071829.22238-4-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/cs46xx/cs46xx_lib.c | 30 ++++++++----------------------
+ 1 file changed, 8 insertions(+), 22 deletions(-)
+
+--- a/sound/pci/cs46xx/cs46xx_lib.c
++++ b/sound/pci/cs46xx/cs46xx_lib.c
+@@ -1121,9 +1121,7 @@ static int snd_cs46xx_playback_hw_params
+ if (params_periods(hw_params) == CS46XX_FRAGS) {
+ if (runtime->dma_area != cpcm->hw_buf.area)
+ snd_pcm_lib_free_pages(substream);
+- runtime->dma_area = cpcm->hw_buf.area;
+- runtime->dma_addr = cpcm->hw_buf.addr;
+- runtime->dma_bytes = cpcm->hw_buf.bytes;
++ snd_pcm_set_runtime_buffer(substream, &cpcm->hw_buf);
+
+
+ #ifdef CONFIG_SND_CS46XX_NEW_DSP
+@@ -1143,11 +1141,8 @@ static int snd_cs46xx_playback_hw_params
+ #endif
+
+ } else {
+- if (runtime->dma_area == cpcm->hw_buf.area) {
+- runtime->dma_area = NULL;
+- runtime->dma_addr = 0;
+- runtime->dma_bytes = 0;
+- }
++ if (runtime->dma_area == cpcm->hw_buf.area)
++ snd_pcm_set_runtime_buffer(substream, NULL);
+ err = snd_pcm_lib_malloc_pages(substream, params_buffer_bytes(hw_params));
+ if (err < 0) {
+ #ifdef CONFIG_SND_CS46XX_NEW_DSP
+@@ -1196,9 +1191,7 @@ static int snd_cs46xx_playback_hw_free(s
+ if (runtime->dma_area != cpcm->hw_buf.area)
+ snd_pcm_lib_free_pages(substream);
+
+- runtime->dma_area = NULL;
+- runtime->dma_addr = 0;
+- runtime->dma_bytes = 0;
++ snd_pcm_set_runtime_buffer(substream, NULL);
+
+ return 0;
+ }
+@@ -1287,16 +1280,11 @@ static int snd_cs46xx_capture_hw_params(
+ if (runtime->periods == CS46XX_FRAGS) {
+ if (runtime->dma_area != chip->capt.hw_buf.area)
+ snd_pcm_lib_free_pages(substream);
+- runtime->dma_area = chip->capt.hw_buf.area;
+- runtime->dma_addr = chip->capt.hw_buf.addr;
+- runtime->dma_bytes = chip->capt.hw_buf.bytes;
++ snd_pcm_set_runtime_buffer(substream, &chip->capt.hw_buf);
+ substream->ops = &snd_cs46xx_capture_ops;
+ } else {
+- if (runtime->dma_area == chip->capt.hw_buf.area) {
+- runtime->dma_area = NULL;
+- runtime->dma_addr = 0;
+- runtime->dma_bytes = 0;
+- }
++ if (runtime->dma_area == chip->capt.hw_buf.area)
++ snd_pcm_set_runtime_buffer(substream, NULL);
+ err = snd_pcm_lib_malloc_pages(substream, params_buffer_bytes(hw_params));
+ if (err < 0)
+ return err;
+@@ -1313,9 +1301,7 @@ static int snd_cs46xx_capture_hw_free(st
+
+ if (runtime->dma_area != chip->capt.hw_buf.area)
+ snd_pcm_lib_free_pages(substream);
+- runtime->dma_area = NULL;
+- runtime->dma_addr = 0;
+- runtime->dma_bytes = 0;
++ snd_pcm_set_runtime_buffer(substream, NULL);
+
+ return 0;
+ }
--- /dev/null
+From 0899a7a23047f106c06888769d6cd6ff43d7395f Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Mon, 9 Aug 2021 09:18:28 +0200
+Subject: ALSA: pci: rme: Set up buffer type properly
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 0899a7a23047f106c06888769d6cd6ff43d7395f upstream.
+
+Although the regression of the mmap was fixed in the recent commit
+dc0dc8a73e8e ("ALSA: pcm: Fix mmap breakage without explicit buffer
+setup"), RME9652 and HDSP drivers have still potential issues with
+their mmap handling. Namely, they use the default mmap handler
+without the standard buffer preallocation, and PCM core wouldn't use
+the coherent DMA mapping. It's practically OK on x86, but on some
+exotic architectures, it wouldn't work.
+
+This patch addresses the potential breakage by replacing the buffer
+setup with the proper macro. It also simplifies the source code,
+too.
+
+Link: https://lore.kernel.org/r/20210809071829.22238-3-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/rme9652/hdsp.c | 6 ++----
+ sound/pci/rme9652/rme9652.c | 6 ++----
+ 2 files changed, 4 insertions(+), 8 deletions(-)
+
+--- a/sound/pci/rme9652/hdsp.c
++++ b/sound/pci/rme9652/hdsp.c
+@@ -4518,8 +4518,7 @@ static int snd_hdsp_playback_open(struct
+ snd_pcm_set_sync(substream);
+
+ runtime->hw = snd_hdsp_playback_subinfo;
+- runtime->dma_area = hdsp->playback_buffer;
+- runtime->dma_bytes = HDSP_DMA_AREA_BYTES;
++ snd_pcm_set_runtime_buffer(substream, hdsp->playback_dma_buf);
+
+ hdsp->playback_pid = current->pid;
+ hdsp->playback_substream = substream;
+@@ -4595,8 +4594,7 @@ static int snd_hdsp_capture_open(struct
+ snd_pcm_set_sync(substream);
+
+ runtime->hw = snd_hdsp_capture_subinfo;
+- runtime->dma_area = hdsp->capture_buffer;
+- runtime->dma_bytes = HDSP_DMA_AREA_BYTES;
++ snd_pcm_set_runtime_buffer(substream, hdsp->capture_dma_buf);
+
+ hdsp->capture_pid = current->pid;
+ hdsp->capture_substream = substream;
+--- a/sound/pci/rme9652/rme9652.c
++++ b/sound/pci/rme9652/rme9652.c
+@@ -2279,8 +2279,7 @@ static int snd_rme9652_playback_open(str
+ snd_pcm_set_sync(substream);
+
+ runtime->hw = snd_rme9652_playback_subinfo;
+- runtime->dma_area = rme9652->playback_buffer;
+- runtime->dma_bytes = RME9652_DMA_AREA_BYTES;
++ snd_pcm_set_runtime_buffer(substream, rme9652->playback_dma_buf);
+
+ if (rme9652->capture_substream == NULL) {
+ rme9652_stop(rme9652);
+@@ -2339,8 +2338,7 @@ static int snd_rme9652_capture_open(stru
+ snd_pcm_set_sync(substream);
+
+ runtime->hw = snd_rme9652_capture_subinfo;
+- runtime->dma_area = rme9652->capture_buffer;
+- runtime->dma_bytes = RME9652_DMA_AREA_BYTES;
++ snd_pcm_set_runtime_buffer(substream, rme9652->capture_dma_buf);
+
+ if (rme9652->playback_substream == NULL) {
+ rme9652_stop(rme9652);
--- /dev/null
+From cbea6e5a7772b7a5b80baa8f98fd77853487fd2a Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Mon, 9 Aug 2021 09:18:27 +0200
+Subject: ALSA: pcm: Check mmap capability of runtime dma buffer at first
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit cbea6e5a7772b7a5b80baa8f98fd77853487fd2a upstream.
+
+Currently we check only the substream->dma_buffer as the preset of the
+buffer configuration for verifying the availability of mmap. But a
+few drivers rather set up the buffer in the own way without the
+standard buffer preallocation using substream->dma_buffer, and they
+miss the proper checks. (Now it's working more or less fine as most
+of them are running only on x86).
+
+Actually, they may set up the runtime dma_buffer (referred via
+snd_pcm_get_dma_buf()) at the open callback, though. That is, this
+could have been used as the primary source.
+
+This patch changes the hw_support_mmap() function to check the runtime
+dma buffer at first. It's usually NULL with the standard buffer
+preallocation, and in that case, we continue checking
+substream->dma_buffer as fallback.
+
+Link: https://lore.kernel.org/r/20210809071829.22238-2-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/core/pcm_native.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+--- a/sound/core/pcm_native.c
++++ b/sound/core/pcm_native.c
+@@ -243,13 +243,18 @@ int snd_pcm_info_user(struct snd_pcm_sub
+
+ static bool hw_support_mmap(struct snd_pcm_substream *substream)
+ {
++ struct snd_dma_buffer *dmabuf;
++
+ if (!(substream->runtime->hw.info & SNDRV_PCM_INFO_MMAP))
+ return false;
+
+ if (substream->ops->mmap || substream->ops->page)
+ return true;
+
+- switch (substream->dma_buffer.dev.type) {
++ dmabuf = snd_pcm_get_dma_buf(substream);
++ if (!dmabuf)
++ dmabuf = &substream->dma_buffer;
++ switch (dmabuf->dev.type) {
+ case SNDRV_DMA_TYPE_UNKNOWN:
+ /* we can't know the device, so just assume that the driver does
+ * everything right
+@@ -259,7 +264,7 @@ static bool hw_support_mmap(struct snd_p
+ case SNDRV_DMA_TYPE_VMALLOC:
+ return true;
+ default:
+- return dma_can_mmap(substream->dma_buffer.dev.dev);
++ return dma_can_mmap(dmabuf->dev.dev);
+ }
+ }
+
--- /dev/null
+alsa-pcm-check-mmap-capability-of-runtime-dma-buffer-at-first.patch
+alsa-pci-rme-set-up-buffer-type-properly.patch
+alsa-pci-cs46xx-fix-set-up-buffer-type-properly.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
