|
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 ...
|