History log of /linux-6.15/sound/core/memalloc.c (Results 1 – 25 of 103)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4
# fa030813 19-Dec-2024 Fedor Pchelkin <[email protected]>

ALSA: memalloc: prefer dma_mapping_error() over explicit address checking

With CONFIG_DMA_API_DEBUG enabled, the following warning is observed:

DMA-API: snd_hda_intel 0000:03:00.1: device driver fa

ALSA: memalloc: prefer dma_mapping_error() over explicit address checking

With CONFIG_DMA_API_DEBUG enabled, the following warning is observed:

DMA-API: snd_hda_intel 0000:03:00.1: device driver failed to check map error[device address=0x00000000ffff0000] [size=20480 bytes] [mapped as single]
WARNING: CPU: 28 PID: 2255 at kernel/dma/debug.c:1036 check_unmap+0x1408/0x2430
CPU: 28 UID: 42 PID: 2255 Comm: wireplumber Tainted: G W L 6.12.0-10-133577cad6bf48e5a7848c4338124081393bfe8a+ #759
debug_dma_unmap_page+0xe9/0xf0
snd_dma_wc_free+0x85/0x130 [snd_pcm]
snd_pcm_lib_free_pages+0x1e3/0x440 [snd_pcm]
snd_pcm_common_ioctl+0x1c9a/0x2960 [snd_pcm]
snd_pcm_ioctl+0x6a/0xc0 [snd_pcm]
...

Check for returned DMA addresses using specialized dma_mapping_error()
helper which is generally recommended for this purpose by
Documentation/core-api/dma-api.rst.

Fixes: c880a5146642 ("ALSA: memalloc: Use proper DMA mapping API for x86 WC buffer allocations")
Reported-by: Mikhail Gavrilov <[email protected]>
Closes: https://lore.kernel.org/r/CABXGCsNB3RsMGvCucOy3byTEOxoc-Ys+zB_HQ=Opb_GhX1ioDA@mail.gmail.com/
Tested-by: Mikhail Gavrilov <[email protected]>
Signed-off-by: Fedor Pchelkin <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


Revision tags: v6.13-rc3, v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11
# 0b9f2bd0 12-Sep-2024 Takashi Iwai <[email protected]>

ALSA: memalloc: Use proper DMA mapping API for x86 S/G buffer allocations

The fallback S/G buffer allocation for x86 used the addresses deduced
from the page allocations blindly. It broke the alloc

ALSA: memalloc: Use proper DMA mapping API for x86 S/G buffer allocations

The fallback S/G buffer allocation for x86 used the addresses deduced
from the page allocations blindly. It broke the allocations on IOMMU
and made us to work around with a hackish DMA ops check.

For cleaning up those messes, this patch switches to the proper DMA
mapping API usages with the standard sg-table instead.

By introducing the sg-table, the address table isn't needed, but for
keeping the original allocation sizes for freeing, replace it with the
array keeping the number of pages.

The get_addr callback is changed to use the existing one for
non-contiguous buffers. (Also it's the reason sg_table is put at the
beginning of struct snd_dma_sg_fallback.)

And finally, the hackish workaround that checks the DMA ops is
dropped now.

Link: https://patch.msgid.link/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


# c880a514 12-Sep-2024 Takashi Iwai <[email protected]>

ALSA: memalloc: Use proper DMA mapping API for x86 WC buffer allocations

The x86 WC page allocation assumes incorrectly the DMA address
directly taken from the page. Also it checks the DMA ops
inap

ALSA: memalloc: Use proper DMA mapping API for x86 WC buffer allocations

The x86 WC page allocation assumes incorrectly the DMA address
directly taken from the page. Also it checks the DMA ops
inappropriately for switching to the own method.

This patch rewrites the stuff to use the proper DMA mapping API
instead.

Link: https://patch.msgid.link/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


# 9408ace4 10-Sep-2024 Takashi Iwai <[email protected]>

ALSA: memalloc: Drop Xen PV workaround again

Since recently in the commit e469e2045f1b ("ALSA: memalloc: Let IOMMU
handle S/G primarily"), the SG buffer allocation code was modified to
use the stand

ALSA: memalloc: Drop Xen PV workaround again

Since recently in the commit e469e2045f1b ("ALSA: memalloc: Let IOMMU
handle S/G primarily"), the SG buffer allocation code was modified to
use the standard DMA code primarily and the fallback is applied only
limitedly. This made the Xen PV specific workarounds we took in the
commit 53466ebdec61 ("ALSA: memalloc: Workaround for Xen PV") rather
superfluous.

It was a hackish workaround for the regression at that time, and it
seems that it's causing another issues (reportedly memory
corruptions). So it's better to clean it up, after all.

Link: https://lore.kernel.org/[email protected]
Cc: Ariadne Conill <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


# 5ced8b91 10-Sep-2024 Takashi Iwai <[email protected]>

ALSA: memalloc: Move snd_malloc_ops definition into memalloc.c again

The definition of struct snd_malloc_ops was moved out to
memalloc_local.h since there was another code for S/G buffer
allocation

ALSA: memalloc: Move snd_malloc_ops definition into memalloc.c again

The definition of struct snd_malloc_ops was moved out to
memalloc_local.h since there was another code for S/G buffer
allocation referring to the struct. But since the code change to use
non-contiguous allocators, it's solely referred in memalloc.c, hence
it makes little sense to have a separate header file.

Let's move it back to memalloc.c.

Link: https://patch.msgid.link/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


Revision tags: v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2
# e469e204 01-Aug-2024 Takashi Iwai <[email protected]>

ALSA: memalloc: Let IOMMU handle S/G primarily

The recent changes in IOMMU made the non-contiguous page allocations
as default, hence we can simply use the standard DMA allocation for
the S/G pages

ALSA: memalloc: Let IOMMU handle S/G primarily

The recent changes in IOMMU made the non-contiguous page allocations
as default, hence we can simply use the standard DMA allocation for
the S/G pages as well. In this patch, we simplify the code by trying
the standard DMA allocation at first, instead of
dma_alloc_noncontiguous().

For the case without IOMMU, we still need to manage the S/G pages
manually, so we keep the same fallback routines like before.

The fallback types (SNDRV_DMA_TYPE_DEV_SG_FALLBACK & co) are dropped /
folded into SNDRV_DMA_TYPE_DEV_SG and co now. The allocation via the
standard DMA call overrides the type accordingly, hence we don't have
to have extra fallback types any longer. OTOH, SNDRV_DMA_TYPE_DEV_SG
is no longer an alias but became its own type back again.

Note that this patch requires another prerequisite fix for memmalloc
helper to use the DMA API for WC pages on x86.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=219087
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


# 9c273013 01-Aug-2024 Takashi Iwai <[email protected]>

ALSA: memalloc: Use DMA API for x86 WC page allocations, too

The memalloc helper used a house-made code for allocation of WC pages
on x86, since the standard DMA API doesn't cover it well. Meanwhil

ALSA: memalloc: Use DMA API for x86 WC page allocations, too

The memalloc helper used a house-made code for allocation of WC pages
on x86, since the standard DMA API doesn't cover it well. Meanwhile,
the manually allocated pages won't work together with IOMMU, resulting
in faults, so we should switch to the DMA API in that case, instead.

This patch tries to switch back to DMA API for WC pages on x86, but
with some additional tweaks that are missing.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=219087
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


Revision tags: v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5, v6.8-rc4, v6.8-rc3, v6.8-rc2, v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7, v6.7-rc6, v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7, v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3, v6.6-rc2, v6.6-rc1, v6.5, v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7, v6.4-rc6, v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3, v6.3-rc7, v6.3-rc6, v6.3-rc5, v6.3-rc4, v6.3-rc3, v6.3-rc2, v6.3-rc1, v6.2, v6.2-rc8, v6.2-rc7, v6.2-rc6
# 53466ebd 25-Jan-2023 Takashi Iwai <[email protected]>

ALSA: memalloc: Workaround for Xen PV

We change recently the memalloc helper to use
dma_alloc_noncontiguous() and the fallback to get_pages(). Although
lots of issues with IOMMU (or non-IOMMU) have

ALSA: memalloc: Workaround for Xen PV

We change recently the memalloc helper to use
dma_alloc_noncontiguous() and the fallback to get_pages(). Although
lots of issues with IOMMU (or non-IOMMU) have been addressed, but
there seems still a regression on Xen PV. Interestingly, the only
proper way to work is use dma_alloc_coherent(). The use of
dma_alloc_coherent() for SG buffer was dropped as it's problematic on
IOMMU systems. OTOH, Xen PV has a different way, and it's fine to use
the dma_alloc_coherent().

This patch is a workaround for Xen PV. It consists of the following
changes:
- For Xen PV, use only the fallback allocation without
dma_alloc_noncontiguous()
- In the fallback allocation, use dma_alloc_coherent();
the DMA address from dma_alloc_coherent() is returned in get_addr
ops
- The DMA addresses are stored in an array; the first entry stores the
number of allocated pages in lower bits, which are referred at
releasing pages again

Reported-by: Marek Marczykowski-Górecki <[email protected]>
Tested-by: Marek Marczykowski-Górecki <[email protected]>
Fixes: a8d302a0b770 ("ALSA: memalloc: Revive x86-specific WC page allocations again")
Fixes: 9736a325137b ("ALSA: memalloc: Don't fall back for SG-buffer with IOMMU")
Link: https://lore.kernel.org/r/[email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


Revision tags: v6.2-rc5, v6.2-rc4, v6.2-rc3, v6.2-rc2, v6.2-rc1
# db918321 20-Dec-2022 Christoph Hellwig <[email protected]>

ALSA: memalloc: don't use GFP_COMP for non-coherent dma allocations

While not quite as bogus as for the dma-coherent allocations that were
fixed earlier, GFP_COMP for these allocations has no benefi

ALSA: memalloc: don't use GFP_COMP for non-coherent dma allocations

While not quite as bogus as for the dma-coherent allocations that were
fixed earlier, GFP_COMP for these allocations has no benefits for
the dma-direct case, and can't be supported at all by dma dma-iommu
backend which splits up allocations into smaller orders. Due to an
oversight in ffcb75458460 that flag stopped being cleared for all
dma allocations, but only got rejected for coherent ones.

Start fixing this by not requesting __GFP_COMP in the sound code, which
is the only place that did this.

Fixes: ffcb75458460 ("dma-mapping: reject __GFP_COMP in dma_alloc_attrs")
Reported-by: Mikhail Gavrilov <[email protected]>
Reported-by: Kai Vehmanen <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
Acked-by: Takashi Iwai <[email protected]>
Tested-by: Mikhail Gavrilov <[email protected]>
Tested-by: Kai Vehmanen <[email protected]>

show more ...


Revision tags: v6.1, v6.1-rc8, v6.1-rc7, v6.1-rc6, v6.1-rc5
# 3306877a 09-Nov-2022 Christoph Hellwig <[email protected]>

ALSA: memalloc: don't pass bogus GFP_ flags to dma_alloc_*

dma_alloc_coherent/dma_alloc_wc is an opaque allocator that only uses
the GFP_ flags for allocation context control. Don't pass __GFP_COMP

ALSA: memalloc: don't pass bogus GFP_ flags to dma_alloc_*

dma_alloc_coherent/dma_alloc_wc is an opaque allocator that only uses
the GFP_ flags for allocation context control. Don't pass __GFP_COMP
which makes no sense for an allocation that can't in any way be
converted to a page pointer.

Note that for dma_alloc_noncoherent and dma_alloc_noncontigous in
combination with the DMA mmap helpers __GFP_COMP looks sketchy as well,
so I would suggest to drop that as well after a careful audit.

Signed-off-by: Christoph Hellwig <[email protected]>

show more ...


# cc265163 14-Nov-2022 Takashi Iwai <[email protected]>

ALSA: memalloc: Allocate more contiguous pages for fallback case

Currently the fallback SG allocation tries to allocate each single
page, and this tends to result in the reverse order of memory
addr

ALSA: memalloc: Allocate more contiguous pages for fallback case

Currently the fallback SG allocation tries to allocate each single
page, and this tends to result in the reverse order of memory
addresses when large space is available at boot, as the kernel takes a
free page from the top to the bottom in the zone. The end result
looks as if non-contiguous (although it actually is). What's worse is
that it leads to an overflow of BDL entries for HD-audio.

For avoiding such a problem, this patch modifies the allocation code
slightly; now it tries to allocate the larger contiguous chunks as
much as possible, then reduces to the smaller chunks only if the
allocation failed -- a similar strategy as the existing
snd_dma_alloc_pages_fallback() function.

Along with the trick, drop the unused address array from
snd_dma_sg_fallback object. It was needed in the past when
dma_alloc_coherent() was used, but with the standard page allocator,
it became superfluous and never referred.

Fixes: a8d302a0b770 ("ALSA: memalloc: Revive x86-specific WC page allocations again")
Reviewed-by: Kai Vehmanen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


# 9d8e536d 12-Nov-2022 Takashi Iwai <[email protected]>

ALSA: memalloc: Try dma_alloc_noncontiguous() at first

The latest fix for the non-contiguous memalloc helper changed the
allocation method for a non-IOMMU system to use only the fallback
allocator.

ALSA: memalloc: Try dma_alloc_noncontiguous() at first

The latest fix for the non-contiguous memalloc helper changed the
allocation method for a non-IOMMU system to use only the fallback
allocator. This should have worked, but it caused a problem sometimes
when too many non-contiguous pages are allocated that can't be treated
by HD-audio controller.

As a quirk workaround, go back to the original strategy: use
dma_alloc_noncontiguous() at first, and apply the fallback only when
it fails, but only for non-IOMMU case.

We'll need a better fix in the fallback code as well, but this
workaround should paper over most cases.

Fixes: 9736a325137b ("ALSA: memalloc: Don't fall back for SG-buffer with IOMMU")
Reported-by: Linus Torvalds <[email protected]>
Link: https://lore.kernel.org/r/CAHk-=wgSH5ubdvt76gNwa004ooZAEJL_1Q-Fyw5M2FDdqL==dg@mail.gmail.com
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


# 9736a325 10-Nov-2022 Takashi Iwai <[email protected]>

ALSA: memalloc: Don't fall back for SG-buffer with IOMMU

When the non-contiguous page allocation for SG buffer allocation
fails, the memalloc helper tries to fall back to the old page
allocation met

ALSA: memalloc: Don't fall back for SG-buffer with IOMMU

When the non-contiguous page allocation for SG buffer allocation
fails, the memalloc helper tries to fall back to the old page
allocation methods. This would, however, result in the bogus page
addresses when IOMMU is enabled. Usually in such a case, the fallback
allocation should fail as well, but occasionally it succeeds and
hitting a bad access.

The fallback was thought for non-IOMMU case, and as the error from
dma_alloc_noncontiguous() with IOMMU essentially implies a fatal
memory allocation error, we should return the error straightforwardly
without fallback. This avoids the corner case like the above.

The patch also renames the local variable "dma_ops" with snd_ prefix
for avoiding the name conflict.

Fixes: a8d302a0b770 ("ALSA: memalloc: Revive x86-specific WC page allocations again")
Reported-by: Kai Vehmanen <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Link: https://lore.kernel.org/r/alpine.DEB.2.22.394.2211041541090.3532114@eliteleevi.tm.intel.com
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


Revision tags: v6.1-rc4, v6.1-rc3, v6.1-rc2, v6.1-rc1, v6.0, v6.0-rc7
# a61c7d88 23-Sep-2022 Kai Vehmanen <[email protected]>

ALSA: memalloc: use __GFP_RETRY_MAYFAIL for DMA mem allocs

Use __GFP_RETRY_MAYFAIL instead of __GFP__NORETRY in
snd_dma_dev_alloc(), snd_dma_wc_alloc() and friends, to allocate pages
for device memo

ALSA: memalloc: use __GFP_RETRY_MAYFAIL for DMA mem allocs

Use __GFP_RETRY_MAYFAIL instead of __GFP__NORETRY in
snd_dma_dev_alloc(), snd_dma_wc_alloc() and friends, to allocate pages
for device memory. The MAYFAIL flag retains the semantics of not
triggering the OOM killer, but lowers the risk of alloc failure.

MAYFAIL flag was added in commit dcda9b04713c3 ("mm, tree wide: replace
__GFP_REPEAT by __GFP_RETRY_MAYFAIL with more useful semantic").

This change addresses recurring failures with SOF audio driver in test
cases where a system suspend-resume stress test is run, combined with an
active high memory-load use-case. The failure typically shows up as:

[ 379.480229] sof-audio-pci-intel-tgl 0000:00:1f.3: booting DSP firmware
[ 379.484803] sof-audio-pci-intel-tgl 0000:00:1f.3: error: memory alloc failed: -12
[ 379.484810] sof-audio-pci-intel-tgl 0000:00:1f.3: error: dma prepare for ICCMAX stream failed

Multiple fixes to reduce the memory usage of DSP boot have been
identified in SOF driver, but even with those fixes, debug on affected
systems has shown that even a single page alloc may fail with
__GFP_NORETRY. When this occurs, system is under significant load on
physical memory, but a lot of reclaimable pages are available, so the
system has not run out of memory. With __GFP_RETRY_MAYFAIL, the errors
are not hit in these stress tests.

The alloc failure is severe as audio capability is completely lost if
alloc failure is hit at system resume.

An alternative solution was considered where the resources for DSP boot
would be kept allocated until driver is unbound. This would avoid the
allocation failure, but consume memory that is only needed temporarily
at probe and resume time. It seems better to not hang on to the memory,
but rather work a bit harder for allocating the pages at resume.

BugLink: https://github.com/thesofproject/linux/issues/3844
Signed-off-by: Kai Vehmanen <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


Revision tags: v6.0-rc6, v6.0-rc5
# 37137ec2 06-Sep-2022 Takashi Iwai <[email protected]>

ALSA: hda: Once again fix regression of page allocations with IOMMU

The last fix for trying to recover the regression on AMD platforms,
unfortunately, leaded to yet another regression: it turned out

ALSA: hda: Once again fix regression of page allocations with IOMMU

The last fix for trying to recover the regression on AMD platforms,
unfortunately, leaded to yet another regression: it turned out that
IOMMUs don't like the usage of raw page allocations.

This is yet another attempt for addressing the log saga; at this time,
we re-use the existing buffer allocation mechanism with SG-pages
although we require only single pages. The SG buffer allocation
itself was confirmed to work for stream buffers, so it's relatively
easy to adapt for other places.

The only problem is: although the HD-audio code is accessing the
address directly via dmab->address field, SG-pages don't set up it.
For the ease of adaption, we now set up the dmab->addr field from the
address of the first page as default, so that it can run with the
HD-audio driver code as-is without the excessive call of
snd_sgbuf_get_addr() multiple times; that's the only change in the
memalloc helper side. The rest is nothing but a flip of the dma_type
field in the HD-audio side.

Fixes: a8d302a0b770 ("ALSA: memalloc: Revive x86-specific WC page allocations again")
Reported-by: Mikhail Gavrilov <[email protected]>
Tested-by: Mikhail Gavrilov <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/CABXGCsO+kB2t5QyHY-rUe76npr1m0-5JOtt8g8SiHUo34ur7Ww@mail.gmail.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216112
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216363
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


Revision tags: v6.0-rc4, v6.0-rc3
# dd164fbf 23-Aug-2022 Takashi Iwai <[email protected]>

ALSA: memalloc: Drop special handling of GFP for CONTINUOUS allocation

Now that all users of snd_dma_continuous_data() is gone, let's drop
this ugly (and dangerous) way.

After this commit, SNDRV_DM

ALSA: memalloc: Drop special handling of GFP for CONTINUOUS allocation

Now that all users of snd_dma_continuous_data() is gone, let's drop
this ugly (and dangerous) way.

After this commit, SNDRV_DMA_TYPE_CONTINUOUS may take the standard
device pointer instead of the hacked pointer by the macro above, and
the memalloc core refers to the coherent_dma_mask of the given
device like other SNDRV_DMA_TYPE. It's still allowed to pass NULL
there, and in that case, the allocation is performed always in the
normal zone.

For SNDRV_DMA_TYPE_VMALLOC, the device pointer is simply ignored.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


Revision tags: v6.0-rc2
# a8d302a0 21-Aug-2022 Takashi Iwai <[email protected]>

ALSA: memalloc: Revive x86-specific WC page allocations again

We dropped the x86-specific hack for WC-page allocations with a hope
that the standard dma_alloc_wc() works nowadays. Alas, it doesn't,

ALSA: memalloc: Revive x86-specific WC page allocations again

We dropped the x86-specific hack for WC-page allocations with a hope
that the standard dma_alloc_wc() works nowadays. Alas, it doesn't,
and we need to take back some workaround again, but in a different
form, as the previous one was broken for some platforms.

This patch re-introduces the x86-specific WC-page allocations, but it
uses rather the manual page allocations instead of
dma_alloc_coherent(). The use of dma_alloc_coherent() was also a
potential problem in the recent addition of the fallback allocation
for noncontig pages, and this patch eliminates both at once.

Fixes: 9882d63bea14 ("ALSA: memalloc: Drop x86-specific hack for WC allocations")
Cc: <[email protected]>
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216363
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


Revision tags: v6.0-rc1, v5.19, v5.19-rc8, v5.19-rc7
# 6eba99d4 13-Jul-2022 Takashi Iwai <[email protected]>

ALSA: memalloc: Fix missing return value comments for kernel docs

Each kernel doc comment expects the definition of the return value in
a proper format. This patch adds or fixes the missing entries

ALSA: memalloc: Fix missing return value comments for kernel docs

Each kernel doc comment expects the definition of the return value in
a proper format. This patch adds or fixes the missing entries for
memory allocation helpers.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


Revision tags: v5.19-rc6, v5.19-rc5, v5.19-rc4
# 9882d63b 20-Jun-2022 Takashi Iwai <[email protected]>

ALSA: memalloc: Drop x86-specific hack for WC allocations

The recent report for a crash on Haswell machines implied that the
x86-specific (rather hackish) implementation for write-cache memory
buffe

ALSA: memalloc: Drop x86-specific hack for WC allocations

The recent report for a crash on Haswell machines implied that the
x86-specific (rather hackish) implementation for write-cache memory
buffer allocation in ALSA core is buggy with the recent kernel in some
corner cases. This patch drops the x86-specific implementation and
uses the standard dma_alloc_wc() & co generically for avoiding the bug
and also for simplification.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216112
Cc: <[email protected]> # v5.18+
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


Revision tags: v5.19-rc3, v5.19-rc2, v5.19-rc1, v5.18, v5.18-rc7, v5.18-rc6, v5.18-rc5, v5.18-rc4, v5.18-rc3
# 925ca893 13-Apr-2022 Takashi Iwai <[email protected]>

ALSA: memalloc: Add fallback SG-buffer allocations for x86

The recent change for memory allocator replaced the SG-buffer handling
helper for x86 with the standard non-contiguous page handler. This

ALSA: memalloc: Add fallback SG-buffer allocations for x86

The recent change for memory allocator replaced the SG-buffer handling
helper for x86 with the standard non-contiguous page handler. This
works for most cases, but there is a corner case I obviously
overlooked, namely, the fallback of non-contiguous handler without
IOMMU. When the system runs without IOMMU, the core handler tries to
use the continuous pages with a single SGL entry. It works nicely for
most cases, but when the system memory gets fragmented, the large
allocation may fail frequently.

Ideally the non-contig handler could deal with the proper SG pages,
it's cumbersome to extend for now. As a workaround, here we add new
types for (minimalistic) SG allocations, instead, so that the
allocator falls back to those types automatically when the allocation
with the standard API failed.

BTW, one better (but pretty minor) improvement from the previous
SG-buffer code is that this provides the proper mmap support without
the PCM's page fault handling.

Fixes: 2c95b92ecd92 ("ALSA: memalloc: Unify x86 SG-buffer handling (take#3)")
BugLink: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2272
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1198248
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


Revision tags: v5.18-rc2, v5.18-rc1, v5.17, v5.17-rc8, v5.17-rc7, v5.17-rc6, v5.17-rc5, v5.17-rc4
# 3e16dc50 10-Feb-2022 Takashi Iwai <[email protected]>

ALSA: memalloc: invalidate SG pages before sync

It seems that calling invalidate_kernel_vmap_range() is more correct
to be called before dma_sync_*(), judging from the other thread:
https://lore.k

ALSA: memalloc: invalidate SG pages before sync

It seems that calling invalidate_kernel_vmap_range() is more correct
to be called before dma_sync_*(), judging from the other thread:
https://lore.kernel.org/all/[email protected]/
Although this won't matter much in practice, let's fix the call order
for consistency.

Fixes: a25684a95646 ("ALSA: memalloc: Support for non-contiguous page allocation")
Reported-by: Ezequiel Garcia <[email protected]>
Cc: <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


# 8e1741c6 10-Feb-2022 Takashi Iwai <[email protected]>

ALSA: memalloc: Fix dma_need_sync() checks

dma_need_sync() checks each DMA address. Fix the incorrect usages
for non-contiguous and non-coherent page allocations.
Fortunately, there are no actual c

ALSA: memalloc: Fix dma_need_sync() checks

dma_need_sync() checks each DMA address. Fix the incorrect usages
for non-contiguous and non-coherent page allocations.
Fortunately, there are no actual call sites that need manual syncs
yet.

Fixes: a25684a95646 ("ALSA: memalloc: Support for non-contiguous page allocation")
Fixes: 73325f60e2ed ("ALSA: memalloc: Support for non-coherent page allocation")
Cc: <[email protected]>
Reported-by: Ezequiel Garcia <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


Revision tags: v5.17-rc3, v5.17-rc2, v5.17-rc1, v5.16, v5.16-rc8, v5.16-rc7, v5.16-rc6, v5.16-rc5, v5.16-rc4, v5.16-rc3, v5.16-rc2
# 2c95b92e 16-Nov-2021 Takashi Iwai <[email protected]>

ALSA: memalloc: Unify x86 SG-buffer handling (take#3)

This is a second attempt to unify the x86-specific SG-buffer handling
code with the new standard non-contiguous page handler.

The first try (in

ALSA: memalloc: Unify x86 SG-buffer handling (take#3)

This is a second attempt to unify the x86-specific SG-buffer handling
code with the new standard non-contiguous page handler.

The first try (in commit 2d9ea39917a4) failed due to the wrong page
and address calculations, hence reverted. (And the second try failed
due to a copy&paste error.) Now it's corrected with the previous fix
for noncontig pages, and the proper sg page iteration by this patch.

After the migration, SNDRV_DMA_TYPE_DMA_SG becomes identical with
SNDRV_DMA_TYPE_NONCONTIG on x86, while others still fall back to
SNDRV_DMA_TYPE_DEV.

Tested-by: Alex Xu (Hello71) <[email protected]>
Tested-by: Harald Arnesen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Link: https://lore.kernel.org/r/[email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


Revision tags: v5.16-rc1
# 4ddac460 10-Nov-2021 Takashi Iwai <[email protected]>

ALSA: memalloc: Remove a stale comment

The comment about the reused vmalloc helpers is no longer valid after
the recent change for the noncontig allocator. Drop the stale
comment.

Fixes: ad4f93ca4

ALSA: memalloc: Remove a stale comment

The comment about the reused vmalloc helpers is no longer valid after
the recent change for the noncontig allocator. Drop the stale
comment.

Fixes: ad4f93ca4138 ("ALSA: memalloc: Use proper SG helpers for noncontig allocations")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


# ad4f93ca 08-Nov-2021 Takashi Iwai <[email protected]>

ALSA: memalloc: Use proper SG helpers for noncontig allocations

The recently introduced non-contiguous page allocation support helpers
are using the simplified code to calculate the page and DMA add

ALSA: memalloc: Use proper SG helpers for noncontig allocations

The recently introduced non-contiguous page allocation support helpers
are using the simplified code to calculate the page and DMA address
based on the vmalloc helpers, but this isn't quite right as the vmap
is valid only for the direct DMA.

This patch corrects those accessors to use the proper SG helpers
instead.

Fixes: a25684a95646 ("ALSA: memalloc: Support for non-contiguous page allocation")
Tested-by: Alex Xu (Hello71) <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Takashi Iwai <[email protected]>

show more ...


12345