On Tue, 05 Apr 2022 15:27:54 +0200,
Robin Murphy wrote:
>
> iommu_get_domain_for_dev() is already perfectly happy to return NULL
> if the given device has no IOMMU. Drop the unnecessary check in favour
> of just handling that condition appropriately.
>
> Signed-off-by: Robin Murphy
> ---
>
> v2
On Tue, 05 Apr 2022 14:13:33 +0200,
Robin Murphy wrote:
>
> iommu_get_domain_for_dev() is already perfectly happy to return NULL
> if the given device has no IOMMU. Drop the unnecessary check.
>
> Signed-off-by: Robin Murphy
This will change the code behavior. The current code does nothing if
Hi,
we've got a bug report recently about the garbage playback sound from
a PCI sound device with mem_encrypt on AMD Ryzen:
https://bugzilla.kernel.org/show_bug.cgi?id=27
The debug session showed that this happens only with the mmap using
dma_mmap_coherent() and mem_encrypt. The mmap with
Acer Aspire A315-41 requires the very same workaround as the existing
quirk for Dell Latitude 5495. Add the new entry for that.
BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1137799
Signed-off-by: Takashi Iwai
---
drivers/iommu/amd_iommu_quirks.c | 13 +
1 file changed, 13
On Tue, 06 Aug 2019 07:29:49 +0200,
Christoph Hellwig wrote:
>
> On Mon, Aug 05, 2019 at 11:22:03AM +0200, Takashi Iwai wrote:
> > This won't work as expected, unfortunately. It's a bit tricky check,
> > since the driver may have its own mmap implementation via
>
On Mon, 05 Aug 2019 11:11:56 +0200,
Christoph Hellwig wrote:
>
> Replace the local hack with the dma_can_mmap helper to check if
> a given device supports mapping DMA allocations to userspace.
>
> Signed-off-by: Christoph Hellwig
> ---
> sound/core/pcm_native.c | 5 ++---
> 1 file changed, 2 in
On Sat, 03 Aug 2019 12:30:24 +0200,
Christoph Hellwig wrote:
>
> On Fri, Aug 02, 2019 at 10:24:02AM +0200, Takashi Iwai wrote:
> > I wasn't careful enough to look at that change, sorry.
> >
> > The code there tries to check whether dma_mmap_coherent() would alwa
On Fri, 02 Aug 2019 09:03:54 +0200,
Christoph Hellwig wrote:
>
> Takashi,
>
> any comments on the sounds/ side of this?
I wasn't careful enough to look at that change, sorry.
The code there tries to check whether dma_mmap_coherent() would always
fail on some platforms. Then the driver clears t
On Fri, 01 Feb 2019 17:09:57 +0100,
Christoph Hellwig wrote:
>
> On Fri, Feb 01, 2019 at 02:16:08PM +0100, Takashi Iwai wrote:
> > Actually there are a bunch of ISA sound drivers that still call
> > allocators with NULL device.
> >
> > The patch below should
On Fri, 01 Feb 2019 17:09:06 +0100,
Christoph Hellwig wrote:
>
> On Fri, Feb 01, 2019 at 02:12:45PM +0100, Takashi Iwai wrote:
> > Shall I take this one through sound git tree or all through yours?
>
> Feel free to merge the sound bits through your tree!
Alright, merged both
lso use GFP_KERNEL instead of GFP_USER as the gfp_t for the memory
> allocation, as we should treat this allocation as a normal kernel one.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Takashi Iwai
thanks,
Takashi
___
iommu mai
> Signed-off-by: Christoph Hellwig
Looks good to me:
Reviewed-by: Takashi Iwai
Shall I take this one through sound git tree or all through yours?
thanks,
Takashi
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.or
eal with separately.
Actually there are a bunch of ISA sound drivers that still call
allocators with NULL device.
The patch below should address it, although it's only compile-tested.
thanks,
Takashi
-- 8< --
From: Takashi Iwai
Subject: [PATCH] ALSA: isa: Avoid passing NULL to memory allo
On Fri, 20 Apr 2018 11:47:02 +0200,
Christoph Hellwig wrote:
>
> On Mon, Apr 16, 2018 at 05:18:19PM +0200, Takashi Iwai wrote:
> > As the recent swiotlb bug revealed, we seem to have given up the
> > direct DMA allocation too early and felt back to swiotlb allocation.
>
ned-off-by: Takashi Iwai
---
This is a resend of a test patch included in the previous thread
("swiotlb: Fix unexpected swiotlb_alloc_coherent() failures").
lib/dma-direct.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/lib/dma-direct.c b/lib/dma-direct.c
index bbfb22
dma-direct: retry allocations using GFP_DMA for small
masks")
Signed-off-by: Takashi Iwai
---
lib/dma-direct.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/dma-direct.c b/lib/dma-direct.c
index c0bba30fef0a..bbfb229aa067 100644
--- a/lib/dma-direct.c
+++ b/lib/dma-di
Hi,
this is a couple of small regression fixes I stumbled on recently.
The first one is a trivial one, and it was already posted in another
thread ("swiotlb: Fix unexpected swiotlb_alloc_coherent() failures").
thanks,
Takashi
===
Takashi Iwai (2):
dma-direct: Don't repeat al
This patch fixes the regression by extending swiotlb_dma_supported()
to check the direct DMA at first for covering the primary allocation
before swiotlb.
Fixes: 6e4bf5867783 ("x86/dma: Use generic swiotlb_ops")
Signed-off-by: Takashi Iwai
---
lib/swiotlb.c | 4
1 file changed, 4
On Thu, 12 Apr 2018 12:32:54 +0200,
Robin Murphy wrote:
>
> On 12/04/18 09:27, Takashi Iwai wrote:
> > On Thu, 12 Apr 2018 10:19:05 +0200,
> > Takashi Iwai wrote:
> >>
> >> On Thu, 12 Apr 2018 10:03:56 +0200,
> >> Takashi Iwai wrote:
> >>>
On Thu, 12 Apr 2018 10:19:05 +0200,
Takashi Iwai wrote:
>
> On Thu, 12 Apr 2018 10:03:56 +0200,
> Takashi Iwai wrote:
> >
> > On Thu, 12 Apr 2018 08:02:27 +0200,
> > Christoph Hellwig wrote:
> > >
> > > On Wed, Apr 11, 2018 at 09:28:54AM +0200, Taka
On Thu, 12 Apr 2018 10:03:56 +0200,
Takashi Iwai wrote:
>
> On Thu, 12 Apr 2018 08:02:27 +0200,
> Christoph Hellwig wrote:
> >
> > On Wed, Apr 11, 2018 at 09:28:54AM +0200, Takashi Iwai wrote:
> > > > But we should try a GFP_DMA32 allocation first, so
On Thu, 12 Apr 2018 08:02:27 +0200,
Christoph Hellwig wrote:
>
> On Wed, Apr 11, 2018 at 09:28:54AM +0200, Takashi Iwai wrote:
> > > But we should try a GFP_DMA32 allocation first, so this is a bit
> > > surprising.
> >
> > Hm, do we really
On Tue, 10 Apr 2018 20:10:20 +0200,
Christoph Hellwig wrote:
>
> On Tue, Apr 10, 2018 at 06:50:04PM +0100, Robin Murphy wrote:
> > In the first one, the machine appears to have enough RAM that most of it is
> > beyond the device's 36-bit DMA mask, thus it's fairly likely for the
> > initial dire
On Tue, 10 Apr 2018 19:06:15 +0200,
Christoph Hellwig wrote:
>
> On Tue, Apr 10, 2018 at 07:05:13PM +0200, Takashi Iwai wrote:
> > The code refactoring by commit 0176adb00406 ("swiotlb: refactor
> > coherent buffer allocation") made swiotlb_alloc_buffer() almost always
ot;)
Cc: # v4.16+
Signed-off-by: Takashi Iwai
---
lib/swiotlb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 47aeb04c1997..de7cc540450f 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -719,7 +719,7 @@ swiotlb_alloc_buffer(struct
25 matches
Mail list logo
