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
