Remove a few tiny wrappers around the generic dma remap code.
Signed-off-by: Christoph Hellwig
---
arch/arm/mm/dma-mapping.c | 32 +---
1 file changed, 5 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index d07e5c865
Currently the generic dma remap allocator gets a vm_flags passed by
the caller that is a little confusing. We just introduced a generic
vmalloc-level flag to identify the dma coherent allocations, so use
that everywhere and remove the now pointless argument.
Signed-off-by: Christoph Hellwig
---
Hi all,
the common DMA remapping code uses the vmalloc/vmap code to create
page table entries for DMA mappings. This series lifts the currently
arm specific VM_* flag for that into common code, and also exposes
it to userspace in procfs to better understand the mappings.
The arm architecture had a VM_ARM_DMA_CONSISTENT flag to mark DMA
coherent remapping for a while. Lift this flag to common code so
that we can use it generically. We also check it in the only place
VM_USERMAP is directly check so that we can entirely replace that
flag as well (although I'm not ev
A helper to find the backing page array based on a virtual address.
This also ensures we do the same vm_flags check everywhere instead
of slightly different or missing ones in a few places.
Signed-off-by: Christoph Hellwig
---
arch/arm/mm/dma-mapping.c | 7 +--
drivers/iommu/dma-iommu.c
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct qcom_iommu_dev {
...
struct qcom_iommu_ctx *ctxs[0]; /* inde
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> Hi Xen maintainers and friends,
>
> please take a look at this series that cleans up the parts of swiotlb-xen
> that deal with non-coherent caches.
>
> Changes since v1:
> - rewrite dma_cache_maint to be much simpler
> - improve various comments a
On Tue, 27 Aug 2019, Christoph Hellwig wrote:
> And this was still buggy I think, it really needs some real Xen/Arm
> testing which I can't do. Hopefully better version below:
>
> --
> >From 5ad4b6e291dbb49f65480c9b769414931cbd485a Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig
> Date: Wed,
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> Now that the Xen special cases are gone nothing worth mentioning is
> left in the arm64 file, so switch to use the
> asm-generic version instead.
>
> Signed-off-by: Christoph Hellwig
> Acked-by: Will Deacon
Reviewed-by: Stefano Stabellini
> --
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> No need for a no-op wrapper.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
> ---
> drivers/xen/swiotlb-xen.c | 15 ---
> 1 file changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/xen/swiotlb-xe
Add global/context fault hooks to allow Nvidia SMMU implementation
handle faults across multiple SMMUs.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu-nvidia.c | 127
drivers/iommu/arm-smmu.c| 6 ++
drivers/iommu/arm-smmu.h| 4
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> Now that we know we always have the dma-noncoherent.h helpers available
> if we are on an architecture with support for non-coherent devices,
> we can just call them directly, and remove the calls to the dma-direct
> routines, including the fact that
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> The only thing left of page-coherent.h is two functions implemented by
> the architecture for non-coherent DMA support that are never called for
> fully coherent architectures. Just move the prototypes for those to
> swiotlb-xen.h instead.
>
> Signe
Add Memory controller DT node on T194 and enable it.
This patch is a prerequisite for SMMU enable on T194.
Signed-off-by: Krishna Reddy
---
arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 4
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 7 +++
2 files changed, 11 insertions(+)
diff
Enable SMMU translations for SDHCI and EQOS transactions.
Signed-off-by: Krishna Reddy
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index ad509bb..0496a87
Add Nvidia SMMUv2 implementation and model info.
Signed-off-by: Krishna Reddy
---
MAINTAINERS | 2 +
drivers/iommu/Makefile | 2 +-
drivers/iommu/arm-smmu-impl.c | 2 +
drivers/iommu/arm-smmu-nvidia.c | 97 +
drivers/iommu
Add binding doc for Nvidia's smmu-v2 implementation.
Signed-off-by: Krishna Reddy
---
Documentation/devicetree/bindings/iommu/arm,smmu.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
b/Documentation/devicetree/bindings/iommu/arm,smmu.
+ Boris, Juergen
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> x86 currently calls alloc_pages, but using dma-direct works as well
> there, with the added benefit of using the CMA pool if available.
> The biggest advantage is of course to remove a pointless bit of
> architecture specific code.
>
Hi All,
Nvidia Arm SMMUv2 implementation has two ARM SMMU(MMU-500) instances
that are used together for SMMU translations. The IOVA accesses from
HW devices are interleaved across these two SMMU instances and need
to be programmed identical except during tlb sync and fault handling.
This patch set
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> xen_dma_map_page uses a different and more complicated check for foreign
> pages than the other three cache maintainance helpers. Switch it to the
> simpler pfn_valid method a well, and document the scheme with a single
> improved comment in xen_dma_
tlb_sync hook allows nvidia smmu handle tlb sync
across multiple SMMUs as necessary.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu-nvidia.c | 32
drivers/iommu/arm-smmu.c| 8 +---
drivers/iommu/arm-smmu.h| 4
3 files changed,
Add DT node for T194 SMMU to enable SMMU support.
Signed-off-by: Krishna Reddy
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 75
1 file changed, 75 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
i
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> Calculate the required operation in the caller, and pass it directly
> instead of recalculating it for each page, and use simple arithmetics
> to get from the physical address to Xen page size aligned chunks.
>
> Signed-off-by: Christoph Hellwig
> -
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> Use the dma-noncoherent dev_is_dma_coherent helper instead of the home
> grown variant. Note that both are always initialized to the same
> value in arch_setup_dma_ops.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Julien Grall
Reviewed-by:
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> Reuse the arm64 code that uses the dma-direct/swiotlb helpers for DMA
> non-coherent devices.
This patch does a bunch of things not listed in the commit message, such
as moving the static inline functions to include/xen/arm/page-coherent.h
and removi
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> These routines are only used by swiotlb-xen, which cannot be modular.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Stefano Stabellini
> ---
> arch/arm/xen/mm.c | 2 --
> arch/x86/xen/mmu_pv.c | 2 --
> 2 files changed, 4 deletions(-)
>
On Mon, 26 Aug 2019, Christoph Hellwig wrote:
> arm and arm64 can just use xen_swiotlb_dma_ops directly like x86, no
> need for a pointer indirection.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Julien Grall
Reviewed-by: Stefano Stabellini
> ---
> arch/arm/mm/dma-mapping.c| 3 ++
On Thu, Aug 29, 2019 at 04:58:22PM +0300, Dmitry Osipenko wrote:
> 29.08.2019 15:40, Thierry Reding пишет:
> > On Thu, Aug 29, 2019 at 01:39:32PM +0200, Hans Verkuil wrote:
> >> On 8/26/19 3:31 PM, YueHaibing wrote:
> >>> If COMPILE_TEST is y and IOMMU_SUPPORT is n, selecting TEGRA_VDE
> >>> to m w
I've applied this to the dma-mapping for-next tree now.
If there are any issues with the parisc patch I'll happily take
incremental patches.
I've pulled this into the dma-mapping for-next tree now.
On Tue, Jul 30, 2019 at 04:50:45PM +0300, Laurent Pinchart wrote:
> I would have indented this line to match the rest. Apart from that,
I've fixed that up now that I've applied the patch.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://li
On Wed, Aug 28, 2019 at 09:01:06AM -0600, Keith Busch wrote:
> On Wed, Aug 28, 2019 at 07:14:42AM -0700, Christoph Hellwig wrote:
> > With a little tweak to the intel-iommu code we should be able to work
> > around the VMD mess for the requester IDs without having to create giant
> > amounts of boi
On Wed, Aug 28, 2019 at 04:41:45PM +, Derrick, Jonathan wrote:
> > diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
> > index 6fa846920f5f..75fe28492290 100644
> > --- a/arch/x86/include/asm/pci.h
> > +++ b/arch/x86/include/asm/pci.h
> > @@ -35,12 +35,15 @@ extern int noioap
29.08.2019 15:40, Thierry Reding пишет:
> On Thu, Aug 29, 2019 at 01:39:32PM +0200, Hans Verkuil wrote:
>> On 8/26/19 3:31 PM, YueHaibing wrote:
>>> If COMPILE_TEST is y and IOMMU_SUPPORT is n, selecting TEGRA_VDE
>>> to m will set IOMMU_IOVA to m, this fails the building of
>>> TEGRA_HOST1X and DR
On Thu, Aug 29, 2019 at 01:39:32PM +0200, Hans Verkuil wrote:
> On 8/26/19 3:31 PM, YueHaibing wrote:
> > If COMPILE_TEST is y and IOMMU_SUPPORT is n, selecting TEGRA_VDE
> > to m will set IOMMU_IOVA to m, this fails the building of
> > TEGRA_HOST1X and DRM_TEGRA which is y like this:
> >
> > driv
On Wed, Aug 28, 2019 at 9:23 PM Masahiro Yamada
wrote:
>
> On Wed, Aug 28, 2019 at 7:53 PM Masahiro Yamada
> wrote:
> >
> > Hi Christoph,
> >
> > On Tue, Aug 27, 2019 at 8:55 PM Christoph Hellwig wrote:
> > >
> > > On Tue, Aug 27, 2019 at 06:03:14PM +0900, Masahiro Yamada wrote:
> > > > Yes, thi
On 8/26/19 3:31 PM, YueHaibing wrote:
> If COMPILE_TEST is y and IOMMU_SUPPORT is n, selecting TEGRA_VDE
> to m will set IOMMU_IOVA to m, this fails the building of
> TEGRA_HOST1X and DRM_TEGRA which is y like this:
>
> drivers/gpu/host1x/cdma.o: In function `host1x_cdma_init':
> cdma.c:(.text+0x6
From: Thierry Reding
Use the new standard function instead of open-coding it.
Cc: Jean-Philippe Brucker
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Thierry Reding
---
drivers/iommu/virtio-iommu.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --gi
From: Thierry Reding
Use the new standard function instead of open-coding it.
Cc: Will Deacon
Cc: Robin Murphy
Signed-off-by: Thierry Reding
---
drivers/iommu/arm-smmu-v3.c | 11 +--
drivers/iommu/arm-smmu.c| 11 +--
2 files changed, 2 insertions(+), 20 deletions(-)
diff
From: Thierry Reding
Use the new standard function instead of open-coding it.
Signed-off-by: Thierry Reding
---
drivers/iommu/amd_iommu.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 04a9f8443344..7d
From: Thierry Reding
Implement a generic function for removing reserved regions. This can be
used by drivers that don't do anything fancy with these regions other
than allocating memory for them.
Signed-off-by: Thierry Reding
---
drivers/iommu/iommu.c | 19 +++
include/linux/io
From: Thierry Reding
Use the new standard function instead of open-coding it.
Cc: David Woodhouse
Signed-off-by: Thierry Reding
---
drivers/iommu/intel-iommu.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iom
From: Thierry Reding
Most IOMMU drivers only need to free the memory allocated for each
reserved region. Instead of open-coding the loop to do this in each
driver, extract the code into a common function that can be used by
all these drivers.
Thierry
Thierry Reding (5):
iommu: Implement iommu
From: Thierry Reding
For device tree nodes, use the standard of_iommu_get_resv_regions()
implementation to obtain the reserved memory regions associated with a
device.
Cc: Rob Herring
Cc: Frank Rowand
Cc: devicet...@vger.kernel.org
Signed-off-by: Thierry Reding
---
drivers/iommu/dma-iommu.c
From: Thierry Reding
These two patches implement support for retrieving a list of reserved
regions for a device from its device tree node. These regions are
described by the reserved-memory bindings:
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
These reserved me
From: Thierry Reding
This is an implementation that IOMMU drivers can use to obtain reserved
memory regions from a device tree node. It uses the reserved-memory DT
bindings to find the regions associated with a given device. These
regions will be used to create 1:1 mappings in the IOMMU domain th
Hi,
On 8/29/19 3:58 PM, Janusz Krzysztofik wrote:
Hi Baolu,
On Thursday, August 29, 2019 3:43:31 AM CEST Lu Baolu wrote:
Hi Janusz,
On 8/28/19 10:17 PM, Janusz Krzysztofik wrote:
We should avoid kernel panic when a intel_unmap() is called against
a non-existent domain.
Does that mean you su
Hi Baolu,
On Thursday, August 29, 2019 3:43:31 AM CEST Lu Baolu wrote:
> Hi Janusz,
>
> On 8/28/19 10:17 PM, Janusz Krzysztofik wrote:
> >> We should avoid kernel panic when a intel_unmap() is called against
> >> a non-existent domain.
> > Does that mean you suggest to replace
> > BUG_ON(!dom
48 matches
Mail list logo