Convert to use vm_insert_range() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Matthew Wilcox
---
drivers/iommu/dma-iommu.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating a new function and use it across
the drivers.
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating a new function and use it across
the drivers.
The Kconfig currently controlling compilation of this code is:
drivers/iommu/Kconfig:config ARM_SMMU
drivers/iommu/Kconfig: bool "ARM Ltd. System MMU (SMMU) Support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially
The Kconfig currently controlling compilation of this code is:
drivers/iommu/Kconfig:config ARM_SMMU_V3
drivers/iommu/Kconfig: bool "ARM Ltd. System MMU Version 3 (SMMUv3) Support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is
The Kconfig currently controlling compilation of this code is:
drivers/iommu/Kconfig:config MTK_IOMMU_V1
drivers/iommu/Kconfig: bool "MTK IOMMU Version 1 (M4U gen1) Support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially
The Kconfig currently controlling compilation of this code is:
drivers/iommu/Kconfig:config TEGRA_IOMMU_GART
drivers/iommu/Kconfig: bool "Tegra GART IOMMU Support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned,
The Kconfig currently controlling compilation of this code is:
drivers/iommu/Kconfig:config IPMMU_VMSA
drivers/iommu/Kconfig:bool "Renesas VMSA-compatible IPMMU"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially
The Kconfig currently controlling compilation of this code is:
drivers/iommu/Kconfig:config MSM_IOMMU
drivers/iommu/Kconfig: bool "MSM IOMMU Support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially orphaned, so that
when
The Kconfig currently controlling compilation of this code is:
drivers/iommu/Kconfig:config ROCKCHIP_IOMMU
drivers/iommu/Kconfig: bool "Rockchip IOMMU Support"
...meaning that it currently is not being built as a module by anyone.
The bind/unbind/remove was already explicitly disabled in
The Kconfig currently controlling compilation of this code is:
drivers/iommu/Kconfig:config MTK_IOMMU_V1
drivers/iommu/Kconfig: bool "MTK IOMMU Version 1 (M4U gen1) Support"
...meaning that it currently is not being built as a module by anyone.
Lets remove the modular code that is essentially
The work here represents a scan over the iommu dir, looking for files/drivers
that have nothing to do with a modular use case, but are using modular
infrastructure regardless.
We are trying to make driver code consistent with the Makefiles/Kconfigs that
control them. This means not using modular
Historically a lot of these existed because we did not have
a distinction between what was modular code and what was providing
support to modules via EXPORT_SYMBOL and friends. That changed
when we forked out support for the latter into the export.h file.
This means we should be able to reduce
On Fri, Nov 30, 2018 at 07:05:40PM +, Robin Murphy wrote:
> On 05/11/2018 12:19, Christoph Hellwig wrote:
>> Do not waste vmalloc space on allocations that do not require a mapping
>> into the kernel address space.
>>
>> Signed-off-by: Christoph Hellwig
>> ---
>> kernel/dma/remap.c | 11
On Fri, Nov 30, 2018 at 07:05:23PM +, Robin Murphy wrote:
> It's a bit yuck that we now end up with arch_* hooks being a mix of arch
> code and not-actually-arch-code, but I guess there's some hope of coming
> back and streamlining things in future once all the big moves are done.
Yes, I
On Fri, Nov 30, 2018 at 07:05:06PM +, Robin Murphy wrote:
> On 05/11/2018 12:19, Christoph Hellwig wrote:
>> The dma remap code only really makes sense for not cache coherent
>> architectures,
>
> And coherent ones with highmem, presumably? That can at least be the case
> on 32-bit Arm, where
On Fri, Nov 30, 2018 at 07:04:51PM +, Robin Murphy wrote:
> On 05/11/2018 12:19, Christoph Hellwig wrote:
>> 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
On Fri, Nov 30, 2018 at 07:04:41PM +, Robin Murphy wrote:
> On 05/11/2018 12:19, Christoph Hellwig wrote:
>> Some architectures support remapping highmem into DMA coherent
>> allocations. To use the common code for them we need variants of
>> dma_direct_{alloc,free}_pages that do not use
This solves a problem we see with drm/msm, caused by getting
iommu_dma_ops while we attach our own domain and manage it directly at
the iommu API level:
[0038] user address but active_mm is swapper
Internal error: Oops: 9605 [#1] PREEMPT SMP
Modules linked in:
CPU: 7 PID:
19 matches
Mail list logo
