From: Takashi Iwai <tiwai@suse.de>
To: Andrzej Hajda <a.hajda@samsung.com>,
Neil Armstrong <narmstrong@baylibre.com>
Cc: Jernej Skrabec <jernej.skrabec@siol.net>,
alsa-devel@alsa-project.org,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
dri-devel@lists.freedesktop.org, Jonas Karlman <jonas@kwiboo.se>
Subject: [alsa-devel] Incorrect buffer handling in dw-hdmi bridge audio
Date: Tue, 05 Nov 2019 08:55:21 +0100 [thread overview]
Message-ID: <s5heeymbvva.wl-tiwai@suse.de> (raw)
Hi,
while recently working on the ALSA memory allocator API cleanup, I
noticed that dw-hdmi bridge driver seems doing weird about the buffer
management. It pre-allocates the usual device buffers fully at the
probe time, while each stream allocates the buffer via the vmalloc
helpers and replaces with it at each open.
I guess it's no expected behavior? It's basically a full waste of
resources, and the vmalloc buffer isn't guaranteed to work well for
mmap on every architecture.
Below is the patch to address it. Can anyone check whether this still
works?
Since I have a cleanup series and this is involved, I'd like to take
the fix through my tree once after it's confirmed (and get ACK if
possible).
Thanks!
Takashi
-- 8< --
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] drm/bridge: dw-hdmi: Fix the incorrect buffer allocations
The driver sets up the buffer preallocation with SNDRV_DMA_TYPE_DEV,
while it re-allocates and releases vmalloc pages. This is not only a
lot of waste resources but also causes the mmap malfunction.
Change / drop the vmalloc-related code and use the standard buffer
allocation / release code instead.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
index 2b7539701b42..8fe7a6e8ff94 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
@@ -384,15 +384,14 @@ static int dw_hdmi_close(struct snd_pcm_substream *substream)
static int dw_hdmi_hw_free(struct snd_pcm_substream *substream)
{
- return snd_pcm_lib_free_vmalloc_buffer(substream);
+ return snd_pcm_lib_free_pages(substream);
}
static int dw_hdmi_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
{
/* Allocate the PCM runtime buffer, which is exposed to userspace. */
- return snd_pcm_lib_alloc_vmalloc_buffer(substream,
- params_buffer_bytes(params));
+ return snd_pcm_lib_malloc_pages(substream, params_buffer_bytes(params));
}
static int dw_hdmi_prepare(struct snd_pcm_substream *substream)
@@ -511,7 +510,6 @@ static const struct snd_pcm_ops snd_dw_hdmi_ops = {
.prepare = dw_hdmi_prepare,
.trigger = dw_hdmi_trigger,
.pointer = dw_hdmi_pointer,
- .page = snd_pcm_lib_get_vmalloc_page,
};
static int snd_dw_hdmi_probe(struct platform_device *pdev)
--
2.16.4
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
WARNING: multiple messages have this Message-ID (diff)
From: Takashi Iwai <tiwai@suse.de>
To: Andrzej Hajda <a.hajda@samsung.com>,
Neil Armstrong <narmstrong@baylibre.com>
Cc: Jernej Skrabec <jernej.skrabec@siol.net>,
alsa-devel@alsa-project.org,
Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
dri-devel@lists.freedesktop.org, Jonas Karlman <jonas@kwiboo.se>
Subject: Incorrect buffer handling in dw-hdmi bridge audio
Date: Tue, 05 Nov 2019 08:55:21 +0100 [thread overview]
Message-ID: <s5heeymbvva.wl-tiwai@suse.de> (raw)
Hi,
while recently working on the ALSA memory allocator API cleanup, I
noticed that dw-hdmi bridge driver seems doing weird about the buffer
management. It pre-allocates the usual device buffers fully at the
probe time, while each stream allocates the buffer via the vmalloc
helpers and replaces with it at each open.
I guess it's no expected behavior? It's basically a full waste of
resources, and the vmalloc buffer isn't guaranteed to work well for
mmap on every architecture.
Below is the patch to address it. Can anyone check whether this still
works?
Since I have a cleanup series and this is involved, I'd like to take
the fix through my tree once after it's confirmed (and get ACK if
possible).
Thanks!
Takashi
-- 8< --
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] drm/bridge: dw-hdmi: Fix the incorrect buffer allocations
The driver sets up the buffer preallocation with SNDRV_DMA_TYPE_DEV,
while it re-allocates and releases vmalloc pages. This is not only a
lot of waste resources but also causes the mmap malfunction.
Change / drop the vmalloc-related code and use the standard buffer
allocation / release code instead.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
index 2b7539701b42..8fe7a6e8ff94 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-ahb-audio.c
@@ -384,15 +384,14 @@ static int dw_hdmi_close(struct snd_pcm_substream *substream)
static int dw_hdmi_hw_free(struct snd_pcm_substream *substream)
{
- return snd_pcm_lib_free_vmalloc_buffer(substream);
+ return snd_pcm_lib_free_pages(substream);
}
static int dw_hdmi_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params)
{
/* Allocate the PCM runtime buffer, which is exposed to userspace. */
- return snd_pcm_lib_alloc_vmalloc_buffer(substream,
- params_buffer_bytes(params));
+ return snd_pcm_lib_malloc_pages(substream, params_buffer_bytes(params));
}
static int dw_hdmi_prepare(struct snd_pcm_substream *substream)
@@ -511,7 +510,6 @@ static const struct snd_pcm_ops snd_dw_hdmi_ops = {
.prepare = dw_hdmi_prepare,
.trigger = dw_hdmi_trigger,
.pointer = dw_hdmi_pointer,
- .page = snd_pcm_lib_get_vmalloc_page,
};
static int snd_dw_hdmi_probe(struct platform_device *pdev)
--
2.16.4
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next reply other threads:[~2019-11-05 7:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-05 7:55 Takashi Iwai [this message]
2019-11-05 7:55 ` Incorrect buffer handling in dw-hdmi bridge audio Takashi Iwai
2019-11-05 8:07 ` [alsa-devel] " Neil Armstrong
2019-11-05 8:07 ` Neil Armstrong
2019-11-05 16:02 ` [alsa-devel] " Russell King - ARM Linux admin
2019-11-05 16:02 ` Russell King - ARM Linux admin
2019-11-05 16:33 ` [alsa-devel] " Takashi Iwai
2019-11-05 16:33 ` Takashi Iwai
2019-11-05 16:44 ` [alsa-devel] " Takashi Iwai
2019-11-05 16:44 ` Takashi Iwai
2019-11-05 17:02 ` [alsa-devel] " Russell King - ARM Linux admin
2019-11-05 17:02 ` Russell King - ARM Linux admin
2019-11-05 17:09 ` [alsa-devel] " Takashi Iwai
2019-11-05 17:09 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=s5heeymbvva.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=Laurent.pinchart@ideasonboard.com \
--cc=a.hajda@samsung.com \
--cc=alsa-devel@alsa-project.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jernej.skrabec@siol.net \
--cc=jonas@kwiboo.se \
--cc=narmstrong@baylibre.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.