On Mon, Oct 15, 2018 at 12:34:02PM +1100, Alexey Kardashevskiy wrote:
>
> On 10/10/2018 00:24, Christoph Hellwig wrote:
> > This code has been unused since it was merged and is in the way of
> > cleaning up the DMA code, thus remove it.
> >
> > This effectively reverts commit 5d2aa710
Hi,
On 10/13/2018 04:25 PM, Xu Zaibo wrote:
Hi,
On 2018/10/12 13:16, Lu Baolu wrote:
Hi,
The Mediate Device is a framework for fine-grained physical device
sharing across the isolated domains. Currently the mdev framework
is designed to be independent of the platform IOMMU support. As the
On Mon, 2018-10-15 at 12:34 +1100, Alexey Kardashevskiy wrote:
> On 10/10/2018 00:24, Christoph Hellwig wrote:
> > This code has been unused since it was merged and is in the way of
> > cleaning up the DMA code, thus remove it.
> >
> > This effectively reverts commit 5d2aa710 ("powerpc/powernv:
On 10/10/2018 00:24, Christoph Hellwig wrote:
> This code has been unused since it was merged and is in the way of
> cleaning up the DMA code, thus remove it.
>
> This effectively reverts commit 5d2aa710 ("powerpc/powernv: Add support
> for Nvlink NPUs").
This code is heavily used by the
On Tue, 2018-10-09 at 15:24 +0200, Christoph Hellwig wrote:
> * Find the least restrictive zone that is entirely below the
> @@ -324,11 +305,14 @@ void __init paging_init(void)
> printk(KERN_DEBUG "Memory hole size: %ldMB\n",
>(long int)((top_of_ram - total_ram) >> 20));
The dma remap code only really makes sense for not cache coherent
architectures, and currently is only used by arm, arm64 and xtensa.
Split it out into a separate file with a separate Kconfig symbol.
[Laura: you wrote this code back then, do you have a sensible
copyright statement to add, given
dma_alloc_from_contiguous can return highmem pages depending on the
setup, which a plain non-remapping DMA allocator can't handle. Detect
this case and try the normal page allocator instead.
Signed-off-by: Christoph Hellwig
---
kernel/dma/direct.c | 12
1 file changed, 12
Please change:
Reported-by: tedheadster
Tested-by: tedheadster
to
Reported-by: Matthew Whitehead
Tested-by: Matthew Whitehead
- Matthew
___
iommu mailing list
iommu@lists.linux-foundation.org
* Thomas Gleixner wrote:
> On Sun, 14 Oct 2018, Christoph Hellwig wrote:
>
> > On Sun, Oct 14, 2018 at 10:13:31AM +0200, Thomas Gleixner wrote:
> > > On Sun, 14 Oct 2018, Christoph Hellwig wrote:
> > >
> > > > We already build the swiotlb code for 32b-t kernels with PAE support,
> > > > but
On Sun, 14 Oct 2018, Christoph Hellwig wrote:
> On Sun, Oct 14, 2018 at 10:13:31AM +0200, Thomas Gleixner wrote:
> > On Sun, 14 Oct 2018, Christoph Hellwig wrote:
> >
> > > We already build the swiotlb code for 32b-t kernels with PAE support,
> > > but the code to actually use swiotlb has only
On Sun, Oct 14, 2018 at 10:13:31AM +0200, Thomas Gleixner wrote:
> On Sun, 14 Oct 2018, Christoph Hellwig wrote:
>
> > We already build the swiotlb code for 32b-t kernels with PAE support,
> > but the code to actually use swiotlb has only been enabled for 64-bit
> > kernel for an unknown reason.
On Sun, 14 Oct 2018, Christoph Hellwig wrote:
> We already build the swiotlb code for 32b-t kernels with PAE support,
> but the code to actually use swiotlb has only been enabled for 64-bit
> kernel for an unknown reason.
>
> Before Linux 4.18 we papers over this fact because the networking
We already build the swiotlb code for 32b-t kernels with PAE support,
but the code to actually use swiotlb has only been enabled for 64-bit
kernel for an unknown reason.
Before Linux 4.18 we papers over this fact because the networking code,
the scsi layer and some random block drivers
13 matches
Mail list logo
