[PATCH v3 12/12] intel-ipu3: imgu top level pci device

This patch adds support for the Intel IPU v3 as found on Skylake and Kaby Lake SoCs. The driver has a dependency on the firmware binary to function properly. Signed-off-by: Yong Zhi Signed-off-by: Tomasz Figa --- drivers/media/pci/intel/ipu3/Kconfig |

[PATCH v3 02/12] intel-ipu3: mmu: implement driver

From: Tomasz Figa This driver translates Intel IPU3 internal virtual address to physical address. Signed-off-by: Tomasz Figa Signed-off-by: Yong Zhi --- drivers/media/pci/intel/ipu3/Kconfig| 9 +

[PATCH v3 03/12] intel-ipu3: Add DMA API implementation

From: Tomasz Figa This patch adds support for the IPU3 DMA mapping API. Signed-off-by: Tomasz Figa Signed-off-by: Yong Zhi --- drivers/media/pci/intel/ipu3/Kconfig | 8 + drivers/media/pci/intel/ipu3/Makefile | 2 +-

[PATCH v3 00/12] Intel IPU3 ImgU patchset

This patchset adds support for the Intel IPU3 (Image Processing Unit) ImgU, which is essentially a modern memory-to-memory ISP. It implements raw Bayer to YUV image format conversion as well as a large number of other pixel processing algorithms for improving the image quality. Meta data formats

Re: [PATCH 1/2] iommu/arm-smmu: Track context bank state

Hi Robin, On 7/18/2017 6:14 PM, Robin Murphy wrote: > Echoing what we do for Stream Map Entries, maintain a software shadow > state for context bank configuration. With this in place, we are mere > moments away from blissfully easy suspend/resume support. > > Signed-off-by: Robin Murphy

[PATCH] iommu: Convert to using %pOF instead of full_name

Now that we have a custom printf format specifier, convert users of full_name to use %pOF instead. This is preparation to remove storing of the full path string for each node. Signed-off-by: Rob Herring Cc: Joerg Roedel Cc: Heiko Stuebner Cc:

[PATCH 2/4] iommu/iova: Optimise the padding calculation

From: Zhen Lei The mask for calculating the padding size doesn't change, so there's no need to recalculate it every loop iteration. Furthermore, Once we've done that, it becomes clear that we don't actually need to calculate a padding size at all - by flipping the

[PATCH 3/4] iommu/iova: Extend rbtree node caching

The cached node mechanism provides a significant performance benefit for allocations using a 32-bit DMA mask, but in the case of non-PCI devices or where the 32-bit space is full, the loss of this benefit can be significant - on large systems there can be many thousands of entries in the tree,

[PATCH 4/4] iommu/iova: Make dma_32bit_pfn implicit

From: Zhen Lei Now that the cached node optimisation can apply to all allocations, the couple of users which were playing tricks with dma_32bit_pfn in order to benefit from it can stop doing so. Conversely, there is also no need for all the other users to explicitly

[PATCH 1/4] iommu/iova: Optimise rbtree searching

From: Zhen Lei Checking the IOVA bounds separately before deciding which direction to continue the search (if necessary) results in redundantly comparing both pfns twice each. GCC can already determine that the final comparison op is redundant and optimise it down to

[PATCH 0/4] Optimise 64-bit IOVA allocations

Hi all, In the wake of the ARM SMMU optimisation efforts, it seems that certain workloads (e.g. storage I/O with large scatterlists) probably remain quite heavily influenced by IOVA allocation performance. Separately, Ard also reported massive performance drops for a graphical desktop on AMD

Re: [Qemu-devel] [RFC PATCH 7/8] VFIO: Add new IOCTL for IOMMU TLB invalidate propagation

On 18/07/17 15:29, Alex Williamson wrote: > On Tue, 18 Jul 2017 10:38:40 +0100 > Jean-Philippe Brucker wrote: > >> On 17/07/17 23:45, Alex Williamson wrote: >> [..] > > How does a user learn which model(s) are supported by the interface? > How do they

Re: [Qemu-devel] [RFC PATCH 7/8] VFIO: Add new IOCTL for IOMMU TLB invalidate propagation

On Tue, 18 Jul 2017 10:38:40 +0100 Jean-Philippe Brucker wrote: > On 17/07/17 23:45, Alex Williamson wrote: > [..] > >>> > >>> How does a user learn which model(s) are supported by the interface? > >>> How do they learn which ops are supported? Perhaps a good use

Re: [PATCH v10 00/38] x86: Secure Memory Encryption (AMD)

On 7/18/2017 7:03 AM, Thomas Gleixner wrote: On Mon, 17 Jul 2017, Tom Lendacky wrote: This patch series provides support for AMD's new Secure Memory Encryption (SME) feature. SME can be used to mark individual pages of memory as encrypted through the page tables. A page of memory that is

[PATCH 1/2] iommu/arm-smmu: Track context bank state

Echoing what we do for Stream Map Entries, maintain a software shadow state for context bank configuration. With this in place, we are mere moments away from blissfully easy suspend/resume support. Signed-off-by: Robin Murphy --- Since the runtime PM discussion has come

[PATCH 2/2] iommu/arm-smmu: Add system PM support

With all our hardware state tracked in such a way that we can naturally restore it as part of the necessary reset, resuming is trivial, and there's nothing to do on suspend at all. Signed-off-by: Robin Murphy --- drivers/iommu/arm-smmu.c | 12 1 file changed,

Re: [PATCH v10 00/38] x86: Secure Memory Encryption (AMD)

On Mon, 17 Jul 2017, Tom Lendacky wrote: > This patch series provides support for AMD's new Secure Memory Encryption > (SME) > feature. > > SME can be used to mark individual pages of memory as encrypted through the > page tables. A page of memory that is marked encrypted will be automatically >

[tip:x86/mm] iommu/amd: Allow the AMD IOMMU to work with memory encryption

Commit-ID: 2543a786aa25258451f3418b87a038c7ddaa2e85 Gitweb: http://git.kernel.org/tip/2543a786aa25258451f3418b87a038c7ddaa2e85 Author: Tom Lendacky AuthorDate: Mon, 17 Jul 2017 16:10:24 -0500 Committer: Ingo Molnar CommitDate: Tue, 18 Jul 2017

[PATCH 4/4] ARM64: dts: rockchip: rk3399 add iommu nodes

From: Simon Add VPU/VDEC/IEP/VOPL/VOPB/ISP0/ISP1 iommu nodes Signed-off-by: Simon --- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 63 1 file changed, 63 insertions(+) diff --git

[PATCH 3/4] ARM64: dts: rockchip: rk3368 add iommu nodes

From: Simon Add IEP/ISP/VOP/HEVC/VPU iommu nodes Signed-off-by: Simon --- arch/arm64/boot/dts/rockchip/rk3368.dtsi | 48 1 file changed, 48 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi

[PATCH 1/4] ARM64: dts: rockchip: rk3328 add iommu nodes

From: Simon Add H265e/VEPU/VPU/VDEC/VOP iommu nodes Signed-off-by: Simon --- arch/arm64/boot/dts/rockchip/rk3328.dtsi | 45 1 file changed, 45 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi

[PATCH 2/4] ARM: dts: rockchip: rk322x add iommu nodes

From: Simon Add VPU/VDEC/VOP/IEP iommu nodes Signed-off-by: Simon --- arch/arm/boot/dts/rk322x.dtsi | 36 1 file changed, 36 insertions(+) diff --git a/arch/arm/boot/dts/rk322x.dtsi b/arch/arm/boot/dts/rk322x.dtsi

Re: [Qemu-devel] [RFC PATCH 7/8] VFIO: Add new IOCTL for IOMMU TLB invalidate propagation

On 17/07/17 23:45, Alex Williamson wrote: [..] >>> >>> How does a user learn which model(s) are supported by the interface? >>> How do they learn which ops are supported? Perhaps a good use for one of >>> those >>> flag bits in the outer data structure is "probe". >> >> My initial plan to user

Re: [PATCH 1/5] iommu/arm-smmu-v3: put off the execution of TLBI* to reduce lock confliction

On Mon, 17 Jul 2017 13:28:47 -0400 Nate Watterson wrote: > Hi Jonathan, > > On 7/17/2017 10:23 AM, Jonathan Cameron wrote: > > On Mon, 17 Jul 2017 14:06:42 +0100 > > John Garry wrote: > > > >> + > >> > >> On 29/06/2017 03:08, Leizhen