On Wed, Feb 06, 2019 at 11:55:49AM +, Robin Murphy wrote:
> On 14/01/2019 09:41, Christoph Hellwig wrote:
>> For entirely dma coherent architectures there is no good reason to ever
>> remap dma coherent allocation.
>
> Yes there is, namely assembling large buffers without the need for massive
+CC Eugeniy
As resident ARC DMA expert can you please this a quick spin.
-Vineet
On 2/4/19 12:14 AM, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
> ---
> arch/arc/Kconfig | 1 +
> arch/arc/include/asm/Kbuild | 1 +
>
On Fri, Feb 08, 2019 at 11:49:55PM -0500, Sinan Kaya wrote:
> On 2/8/2019 8:02 PM, sathyanarayanan kuppuswamy wrote:
> >>This means that you should probably have some kind of version check
> >>here.
> >
> >There is no version field in ATS v1.0 spec. Also, If I follow the history
> >log in PCI
On 2/11/19 11:15 AM, Raj, Ashok wrote:
On Fri, Feb 08, 2019 at 11:49:55PM -0500, Sinan Kaya wrote:
On 2/8/2019 8:02 PM, sathyanarayanan kuppuswamy wrote:
This means that you should probably have some kind of version check
here.
There is no version field in ATS v1.0 spec. Also, If I follow
I'm looking at commit 562831747f6299abd481b5b00bd4fa19d5c8a259
which fails to adequately explain why we can't use PASID 0. Commit
af39507305fb83a5d3c475c2851f4d59545d8a18 also doesn't explain why PASID
0 is no longer usable for the intel-svm driver.
There are a load of simplifications that
On Fri, Feb 8, 2019 at 10:52 AM Souptick Joarder wrote:
>
> On Thu, Feb 7, 2019 at 10:17 PM Matthew Wilcox wrote:
> >
> > On Thu, Feb 07, 2019 at 09:19:47PM +0530, Souptick Joarder wrote:
> > > Just thought to take opinion for documentation before placing it in v3.
> > > Does it looks fine ?
> >
From: Kuppuswamy Sathyanarayanan
Intel IOMMU responds automatically when receiving page-requests from
a PCIe endpoint and the page-request queue is full and it cannot accept
any more page-requests. When it auto-responds to page-requests with a
success to the endpoint, it automatically responds
From: Kuppuswamy Sathyanarayanan
Return the PRG Response PASID Required bit in the Page Request
Status Register.
As per PCIe spec r4.0, sec 10.5.2.3, if this bit is Set then the device
expects a PASID TLP Prefix on PRG Response Messages when the
corresponding Page Requests had a PASID TLP
From: Kuppuswamy Sathyanarayanan
In Intel IOMMU, if the Page Request Queue (PRQ) is full, it will
automatically respond to the device with a success message as a keep
alive. And when sending the success message, IOMMU will include PASID in
the Response Message when the Page Request has a PASID
On 2/11/19 1:43 PM, sathyanarayanan.kuppusw...@linux.intel.com wrote:
From: Kuppuswamy Sathyanarayanan
As per Intel vt-d specification, Rev 3.0 (section 7.5.1.1, title "Page Request
Descriptor"), Intel IOMMU Page Request Descriptor only provides bits[63:12] of the
page address. Hence its
From: Kuppuswamy Sathyanarayanan
As per Intel vt-d specification, Rev 3.0 (section 7.5.1.1, title "Page Request
Descriptor"), Intel IOMMU Page Request Descriptor only provides bits[63:12] of
the page address. Hence its required to enforce that the device will only send
page request with
On 2/11/2019 2:15 PM, Raj, Ashok wrote:
It seems rather odd we have to check for ATS version.
I always assumed unspecified bits (Reserved) must be 0. We only check
this if ATS is enabled, and this particular bit wasn't given away for another
feature.
Is it really required to check for ATS
From: Kuppuswamy Sathyanarayanan
As per Intel vt-d specification, Rev 3.0 (section 7.5.1.1, title "Page
Request Descriptor"), Intel IOMMU page request descriptor only uses
bits[63:12] of the page address. Hence Intel IOMMU driver would only
permit devices that advertise they would only send page
From: Kuppuswamy Sathyanarayanan
As per Intel vt-d specification, Rev 3.0 (section 7.5.1.1, title
"Page Request Descriptor"), Intel IOMMU page request descriptor
only uses bits[63:12] of the Page Address. Hence its required to
enforce that the device will only send page request with
page-aligned
From: Kuppuswamy Sathyanarayanan
Return the Page Aligned Request bit in the ATS Capability Register.
As per PCIe spec r4.0, sec 10.5.1.2, If Page Aligned Request bit is
set, then it indicates the Untranslated Addresses generated by the
device are alwayis always aligned to a 4096 byte boundary.
On 2/12/19 11:02 AM, Peter Xu wrote:
On Tue, Feb 12, 2019 at 10:44:23AM +0800, Lu Baolu wrote:
Hi,
On 2/12/19 3:28 AM, Matthew Wilcox wrote:
I'm looking at commit 562831747f6299abd481b5b00bd4fa19d5c8a259
which fails to adequately explain why we can't use PASID 0. Commit
Hi Christoph,
On Mon, Feb 04, 2019 at 09:14:19AM +0100, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
> ---
> arch/arc/Kconfig | 1 +
> arch/arc/include/asm/Kbuild | 1 +
> arch/arc/include/asm/dma-mapping.h | 13 -
> arch/arm/Kconfig
Hi,
On 2/12/19 3:28 AM, Matthew Wilcox wrote:
I'm looking at commit 562831747f6299abd481b5b00bd4fa19d5c8a259
which fails to adequately explain why we can't use PASID 0. Commit
af39507305fb83a5d3c475c2851f4d59545d8a18 also doesn't explain why PASID
0 is no longer usable for the intel-svm
On Tue, Feb 12, 2019 at 10:44:23AM +0800, Lu Baolu wrote:
> Hi,
>
> On 2/12/19 3:28 AM, Matthew Wilcox wrote:
> >
> > I'm looking at commit 562831747f6299abd481b5b00bd4fa19d5c8a259
> > which fails to adequately explain why we can't use PASID 0. Commit
> >
Hi Christoph,
On Mon, Feb 11, 2019 at 02:35:48PM +0100, Christoph Hellwig wrote:
> This API is primarily used through DT entries, but two architectures
> and two drivers call it directly. So instead of selecting the config
> symbol for random architectures pull it in implicitly for the actual
>
Use the proper sg_next() helper to move to the next scatterlist element
to support chained scatterlists.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/omap.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/mmc/host/omap.c
These days the DMA mapping code must bounce buffer for any not supported
address, and if they driver needs to optimize for natively supported
ranged it should use dma_get_required_mask.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/dma-mapping.h | 7 ---
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do an atomic kmap for the page
while doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/sh_mmcif.c | 59 +++--
1
All MMC and SD host drivers are highmem safe now, and bounce buffering
for addressing limitations is handled in the DMA layer now.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/core/queue.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/mmc/core/queue.c
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do an atomic kmap for the page
while doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/s3cmci.c | 107 +++---
On Thu, Feb 07, 2019 at 11:29:14PM +, Paul Burton wrote:
> Would you like this to go through the MIPS tree or elsewhere? If the
> latter:
>
> Acked-by: Paul Burton
Please pick it up through the mips tree!
___
iommu mailing list
On Mon, Feb 11, 2019 at 02:35:51PM +0100, Christoph Hellwig wrote:
> All users of dma_declare_coherent want their allocations to be
> exclusive, so default to exclusive allocations.
>
> Signed-off-by: Christoph Hellwig
> ---
> Documentation/DMA-API.txt | 9 +--
>
On Mon, Feb 11, 2019 at 02:35:49PM +0100, Christoph Hellwig wrote:
> This is where all the related code already lives.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/base/Kconfig | 77
> kernel/dma/Kconfig | 77
If we want to get rid of the block layer bounce buffering for highmem we
need to ensure no segment spans multiple pages so that we can kmap it.
Add a flag to struct mmc_host so that we can handle the block and DMA
layer interactions in common code.
Signed-off-by: Christoph Hellwig
---
Hi everyone,
this series converts the remaining MMC host drivers to properly kmap the
scatterlist entries it does PIO operations on, and then goes on to
remove the usage of block layer bounce buffering (which I plan to remove
eventually) from the MMC layer.
As a bonus I've converted various
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do an atomic kmap for the page
while doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/davinci_mmc.c | 22 +-
1 file
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do an atomic kmap for the page
while doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/omap.c | 15 ++-
1 file changed, 10
This avoids bug prone open coding of the sg offset handling and
also helps to document the limitations of mapping scatterlist
entries.
Signed-off-by: Christoph Hellwig
---
include/linux/scatterlist.h | 26 ++
1 file changed, 26 insertions(+)
diff --git
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do an atomic kmap for the page
while doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/mvsdio.c | 33 +
1 file
Use the proper sg_next() helper to move to the next scatterlist element
to support chained scatterlists.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/sh_mmcif.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sh_mmcif.c
Use the proper sg_next() helper to move to the next scatterlist element
to support chained scatterlists.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/s3cmci.c | 19 +--
drivers/mmc/host/s3cmci.h | 2 +-
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git
Instead of setting up a kernel pointer to track the current PIO address,
track the offset in the current page, and do a kmap for the page while
doing the actual PIO operations.
Signed-off-by: Christoph Hellwig
---
drivers/mmc/host/moxart-mmc.c | 20
1 file changed, 12
Signed-off-by: Christoph Hellwig
---
include/linux/mmc/host.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 4d35ff36ceff..4eadf01b4a93 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -397,7 +397,6 @@ struct
On Mon, Feb 11, 2019 at 02:35:44PM +0100, Christoph Hellwig wrote:
> No need to carry an unused field around.
>
> Signed-off-by: Christoph Hellwig
> ---
> include/linux/device.h | 2 ++
> 1 file changed, 2 insertions(+)
Reviewed-by: Greg Kroah-Hartman
Hi Alex:
Thanks for your review.
On Fri, Feb 8, 2019 at 2:15 AM Alex Williamson
wrote:
>
> On Thu, 7 Feb 2019 23:33:48 +0800
> lantianyu1...@gmail.com wrote:
>
> > From: Lan Tianyu
> >
> > On the bare metal, enabling X2APIC mode requires interrupt remapping
> > function which helps
Hi Olaf:
Thanks for your review.
On Fri, Feb 8, 2019 at 10:52 PM Olaf Hering wrote:
>
> On Thu, Feb 07, lantianyu1...@gmail.com wrote:
>
> > +++ b/drivers/iommu/Kconfig
> > +config HYPERV_IOMMU
> > + bool "Hyper-V x2APIC IRQ Handling"
> > + depends on HYPERV
> > + select
On Fri, Feb 8, 2019 at 1:15 AM Vitaly Kuznetsov wrote:
>
> lantianyu1...@gmail.com writes:
>
> > From: Lan Tianyu
> >
> > On the bare metal, enabling X2APIC mode requires interrupt remapping
> > function which helps to deliver irq to cpu with 32-bit APIC ID.
> > Hyper-V doesn't provide interrupt
On Tue, Feb 05, 2019 at 11:20:30AM -0600, Rob Herring wrote:
> On Tue, Feb 5, 2019 at 10:55 AM Christoph Hellwig wrote:
> >
> > On Tue, Feb 05, 2019 at 10:37:31AM -0600, Rob Herring wrote:
> > > Move io-pgtable.h to include/linux/ and export alloc_io_pgtable_ops
> > > and free_io_pgtable_ops.
On Mon, Feb 11, 2019 at 02:21:56PM +0100, Christoph Hellwig wrote:
> Any chance to get a quick review on this small series?
For arm64:
Acked-by: Catalin Marinas
___
iommu mailing list
iommu@lists.linux-foundation.org
From: Lan Tianyu
On the bare metal, enabling X2APIC mode requires interrupt remapping
function which helps to deliver irq to cpu with 32-bit APIC ID.
Hyper-V doesn't provide interrupt remapping function so far and Hyper-V
MSI protocol already supports to deliver interrupt to the CPU whose
From: Lan Tianyu
Hyper-V doesn't provide irq remapping for IO-APIC. To enable x2apic,
set x2apic destination mode to physcial mode when x2apic is available
and Hyper-V IOMMU driver makes sure cpus assigned with IO-APIC irqs have
8-bit APIC id.
Reviewed-by: Thomas Gleixner
Signed-off-by: Lan
From: Lan Tianyu
On the bare metal, enabling X2APIC mode requires interrupt remapping
function which helps to deliver irq to cpu with 32-bit APIC ID.
Hyper-V doesn't provide interrupt remapping function so far and Hyper-V
MSI protocol already supports to deliver interrupt to the CPU whose
On Fri, Feb 01, 2019 at 05:10:26PM +0100, Christoph Hellwig wrote:
> On Fri, Feb 01, 2019 at 03:19:41PM +0200, Felipe Balbi wrote:
> > Christoph Hellwig writes:
> >
> > > dma_map_single already transfers ownership to the device.
> > >
> > > Signed-off-by: Christoph Hellwig
> >
> > Do you want
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
Acked-by: Nicolas Ferre
---
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/amd/au1000_eth.c | 6 +++---
1 file
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Note that this driver seems to entirely lack dma_map_single error
handling, but that is left
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use GFP_KERNEL instead of GFP_ATOMIC as the gfp_t for the memory
allocation, as we aren't
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/moxa/moxart_ether.c | 11
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Note that smc911x apparently is a PIO chip with an external DMA
handshake, and we probably use
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Note this driver seems to lack dma_unmap_* calls entirely, but fixing
that is left for another
We still have a few drivers which pass a NULL struct device pointer
to DMA API functions, which generally is a bad idea as the API
implementations rely on the device not only for ops selection, but
also the dma mask and various other attributes.
This series contains all easy conversions to pass a
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use the proper Kconfig symbol to check for DMA API availability.
Signed-off-by: Christoph
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/video/fbdev/da8xx-fb.c | 13 +++--
1
We still have a few drivers which pass a NULL struct device pointer
to DMA API functions, which generally is a bad idea as the API
implementations rely on the device not only for ops selection, but
also the dma mask and various other attributes.
This series contains all easy conversions to pass a
All users of per-device coherent memory are exclusive, that is if we can't
allocate from the per-device pool we can't use the system memory either.
Unfold the current dma_{alloc,free}_from_dev_coherent implementation and
always use the per-device pool if it exists.
Signed-off-by: Christoph
The only useful bit in this function was the already assigned check.
Once that is moved to dma_init_coherent_memory thee rest can easily
be handled in the two callers.
Signed-off-by: Christoph Hellwig
---
kernel/dma/coherent.c | 47 +--
1 file changed, 14
All users of dma_declare_coherent want their allocations to be
exclusive, so default to exclusive allocations.
Signed-off-by: Christoph Hellwig
---
Documentation/DMA-API.txt | 9 +--
arch/arm/mach-imx/mach-imx27_visstrim_m10.c | 12 +++--
The OF_RESERVED_MEM can be used if we have either CMA or the generic
declare coherent code built and we support the early flattened DT.
So don't bother making it a user visible options that is selected
by most configs that fit the above category, but just select it when
the requirements are met.
This API is not used anywhere, so remove it.
Signed-off-by: Christoph Hellwig
---
Documentation/DMA-API.txt | 17 -
include/linux/dma-mapping.h | 9 -
kernel/dma/coherent.c | 23 ---
3 files changed, 49 deletions(-)
diff --git
This API is primarily used through DT entries, but two architectures
and two drivers call it directly. So instead of selecting the config
symbol for random architectures pull it in implicitly for the actual
users. Also rename the Kconfig option to describe the feature better.
Signed-off-by:
This function is only used in of_reserved_mem.c, and never overridden
despite the __weak marker.
Signed-off-by: Christoph Hellwig
---
drivers/of/of_reserved_mem.c| 2 +-
include/linux/of_reserved_mem.h | 7 ---
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git
memmap return a regular void pointer, not and __iomem one.
Signed-off-by: Christoph Hellwig
---
kernel/dma/coherent.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/dma/coherent.c b/kernel/dma/coherent.c
index 66f0fb7e9a3a..4b76aba574c2 100644
---
We handle allocation and freeing in common code, so we should handle
mmap the same way. Also all users of per-device coherent memory are
exclusive, that is if we can't allocate from the per-device pool we
can't use the system memory either. Unfold the current
dma_mmap_from_dev_coherent
Any chance to get a quick review on this small series?
On Mon, Feb 04, 2019 at 09:14:18AM +0100, Christoph Hellwig wrote:
> Hi all,
>
> this series adds kconfig symbols to indicate that the architecture
> provides the arch_setup_dma_ops and arch_teardown_dma_ops hooks.
>
> This avoids polluting
Just like we do for all other DMA operations.
Signed-off-by: Christoph Hellwig
---
drivers/video/fbdev/pxa3xx-gcu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/pxa3xx-gcu.c b/drivers/video/fbdev/pxa3xx-gcu.c
index 69cfb337c857..047a2fa4b87e 100644
gbefb uses managed resources, so it should do the same for DMA
allocations.
Signed-off-by: Christoph Hellwig
---
drivers/video/fbdev/gbefb.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
Hi,
Christoph Hellwig writes:
> On Fri, Feb 01, 2019 at 05:10:26PM +0100, Christoph Hellwig wrote:
>> On Fri, Feb 01, 2019 at 03:19:41PM +0200, Felipe Balbi wrote:
>> > Christoph Hellwig writes:
>> >
>> > > dma_map_single already transfers ownership to the device.
>> > >
>> > > Signed-off-by:
Currently the sm501 mfd driver can be compiled without any dependencies,
but through the use of dma_declare_coherent it really depends on
having DMA and iomem support. Normally we don't explicitly require DMA
support as we have stubs for it if on UML, but in this case the driver
selects support
This is where all the related code already lives.
Signed-off-by: Christoph Hellwig
---
drivers/base/Kconfig | 77
kernel/dma/Kconfig | 77
2 files changed, 77 insertions(+), 77 deletions(-)
diff --git
Hi all,
this series removes various bits of dead code and refactors the
remaining functionality around dma_declare_coherent to be a somewhat
more coherent code base.
___
iommu mailing list
iommu@lists.linux-foundation.org
No need to carry an unused field around.
Signed-off-by: Christoph Hellwig
---
include/linux/device.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index 6cb4640b6160..be544400acdd 100644
--- a/include/linux/device.h
+++
On 08/02/2019 18:55, Geert Uytterhoeven wrote:
Hi Robin,
On Fri, Feb 8, 2019 at 6:55 PM Robin Murphy wrote:
On 08/02/2019 16:40, Joerg Roedel wrote:
On Thu, Feb 07, 2019 at 08:36:53PM +0100, Geert Uytterhoeven wrote:
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index
Adding a few more people to Cc.
On Sun, Feb 03, 2019 at 10:27:09AM +, wen yang wrote:
> Make sure to drop the reference to the device taken by
> of_find_device_by_node() on driver unbind.
>
> Signed-off-by: Wen Yang
> Cc: Joerg Roedel
> Cc: iommu@lists.linux-foundation.org
> Cc:
On Fri, Feb 08, 2019 at 02:20:44PM +, Tom Murphy wrote:
> ---
> include/linux/iommu.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
The patch has no Signed-off-by, please add it and a proper
commit-message and re-send.
___
iommu mailing
On Fri, Feb 08, 2019 at 04:05:33PM -0600, Bjorn Helgaas wrote:
> I've had these minor iommu cleanups lying around for a while, but the ugly
> dmesg logs from [1] prompted me to finally post them. Take what you like,
> ignore the rest, and tell me so I can clear out my queue of old stuff.
>
>
Fix typo, flush_tlb_all should be flush_iotlb_all
Signed-off-by: Tom Murphy
---
include/linux/iommu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index a1d28f42cb77..bb4bf1269e5d 100644
--- a/include/linux/iommu.h
+++
This is a follow up to the commit cf65a0f6f6ff
("dma-mapping: move all DMA mapping code to kernel/dma")
which moved source code of DMA API to kernel/dma folder. Since there is
no file left in the lib that require DMA API debugging options move the
latter to kernel/dma as well.
Cc: Christoph
On Mon, Feb 11, 2019 at 05:54:09PM +0200, Andy Shevchenko wrote:
> This is a follow up to the commit cf65a0f6f6ff
>
> ("dma-mapping: move all DMA mapping code to kernel/dma")
>
> which moved source code of DMA API to kernel/dma folder. Since there is
> no file left in the lib that require DMA
On Wed, Feb 06, 2019 at 03:08:26PM +, Robin Murphy wrote:
> Other than dma-iommu.c itself, none of them *require* it - only arch/arm64
> selects it (the one from MTK_IOMMU is just bogus), and a lot of the drivers
> also build for at least one other architecture (and/or arm64 with
>
On Wed, Feb 06, 2019 at 03:28:28PM +, Robin Murphy wrote:
> Because if iommu_map() only gets called at PAGE_SIZE granularity, then the
> IOMMU PTEs will be created at PAGE_SIZE (or smaller) granularity, so any
> effort to get higher-order allocations matching larger IOMMU block sizes is
>
On Tue, Feb 05, 2019 at 03:02:23PM +, Robin Murphy wrote:
> On 14/01/2019 09:41, Christoph Hellwig wrote:
>> The current iommu_dma_mmap code does not properly handle memory from the
>> page allocator that hasn't been remapped, which can happen in the rare
>> case of allocations for a coherent
On Mon, Feb 11, 2019 at 04:54:50PM +0100, Christoph Hellwig wrote:
> On Mon, Feb 11, 2019 at 05:54:09PM +0200, Andy Shevchenko wrote:
> > This is a follow up to the commit cf65a0f6f6ff
> >
> > ("dma-mapping: move all DMA mapping code to kernel/dma")
> >
> > which moved source code of DMA API
This is a follow up to the commit cf65a0f6f6ff
("dma-mapping: move all DMA mapping code to kernel/dma")
which moved source code of DMA API to kernel/dma folder. Since there is
no file left in the lib that require DMA API debugging options move the
latter to kernel/dma as well.
Cc: Christoph
88 matches
Mail list logo
