The patch sent in the below thread fixed the problem in kernel v5.2 on
my system.
A sincere Thank You to everyone who jumped in to help, using their
valuable time on this obscure issue.
Best Regards,
Alfred Farleigh
----
Re: [PATCH dma 1/1] dma-direct: correct the physical addr in
dma_direct_sync_sg_for_cpu/device
Fixes: 55897af63091("dma-direct: merge swiotlb_dma_ops into the
dma_direct code")
Signed-off-by: Fugang Duan <[email protected]>
---
kernel/dma/direct.c | 18 +++++++++++-------
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index b90e1ae..0e87f86 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -242,12 +242,14 @@ void dma_direct_sync_sg_for_device(struct device *dev,
int i;
for_each_sg(sgl, sg, nents, i) {
- if (unlikely(is_swiotlb_buffer(sg_phys(sg))))
- swiotlb_tbl_sync_single(dev, sg_phys(sg), sg->length,
+ phys_addr_t paddr = dma_to_phys(dev, sg_dma_address(sg));
+
+ if (unlikely(is_swiotlb_buffer(paddr)))
+ swiotlb_tbl_sync_single(dev, paddr, sg->length,
dir, SYNC_FOR_DEVICE);
if (!dev_is_dma_coherent(dev))
- arch_sync_dma_for_device(dev, sg_phys(sg), sg->length,
+ arch_sync_dma_for_device(dev, paddr, sg->length,
dir);
}
}
@@ -279,11 +281,13 @@ void dma_direct_sync_sg_for_cpu(struct device *dev,
int i;
for_each_sg(sgl, sg, nents, i) {
+ phys_addr_t paddr = dma_to_phys(dev, sg_dma_address(sg));
+
if (!dev_is_dma_coherent(dev))
- arch_sync_dma_for_cpu(dev, sg_phys(sg), sg->length, dir);
-
- if (unlikely(is_swiotlb_buffer(sg_phys(sg))))
- swiotlb_tbl_sync_single(dev, sg_phys(sg), sg->length, dir,
+ arch_sync_dma_for_cpu(dev, paddr, sg->length, dir);
+
+ if (unlikely(is_swiotlb_buffer(paddr)))
+ swiotlb_tbl_sync_single(dev, paddr, sg->length, dir,
SYNC_FOR_CPU);
}
On 7/16/19 10:43 PM, Al Farleigh wrote:
re: the dma-direct code commit below
I have bisected the kernel to isolate a PCI board problem on my AMD
x86-64 ASROCK system. The board worked at (Fedora kernel) 4.18.16 but
stopped when moving to (Fedora kernel) 5.0. I then used
(git/torvalds/linux) 4.20-rc4 or so to locate the fault via bisect.
I now have two kernels, good/bad, that straddle the commit.
I was asked to try v5.2 just in case it was fixed; I compiled it and the
fault appears to still be present.
Simply, mpeg video does not stream from board; no errors, but no video.
My work is documented at
https://bugs.kde.org/show_bug.cgi?id=408004
including dmesgs, lspcis, and (second) git bisect log.
Could I please ask if and where I should submit a bug? and am willing to
assist if I can.
Thank You!
-----
commit 55897af63091ebc2c3f239c6a6666f748113ac50
Author: Christoph Hellwig <[email protected]>
Date: Mon Dec 3 11:43:54 2018 +0100
dma-direct: merge swiotlb_dma_ops into the dma_direct code
While the dma-direct code is (relatively) clean and simple we
actually have to use the swiotlb ops for the mapping on many
architectures due to devices with addressing limits. Instead
of keeping two implementations around this commit allows the
dma-direct implementation to call the swiotlb bounce buffering
functions and thus share the guts of the mapping implementation.
This also simplified the dma-mapping setup on a few architectures
where we don't have to differenciate which implementation to use.
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
