[PATCH v7 09/12] ARM: tegra: Enable IOMMU for display controllers on Tegra30

From: Thierry Reding tred...@nvidia.com Add iommus properties to the device tree nodes for the two display controllers found on Tegra30. This will allow the display controllers to map physically non-contiguous buffers to I/O virtual contiguous address spaces so that they can be used for scan-out

[PATCH v7 08/12] ARM: tegra: Add memory controller support for Tegra124

From: Thierry Reding tred...@nvidia.com Add the memory controller and wire up the interrupt that is used to report errors. Provide a reference to the memory controller clock and mark the device as being an IOMMU by adding an #iommu-cells property. Signed-off-by: Thierry Reding tred...@nvidia.com

[PATCH v7 11/12] ARM: tegra: Enable IOMMU for display controllers on Tegra124

From: Thierry Reding tred...@nvidia.com Add iommus properties to the device tree nodes for the two display controllers found on Tegra124. This will allow the display controllers to map physically non-contiguous buffers to I/O virtual contiguous address spaces so that they can be used for scan-out

[PATCH v7 12/12] memory: tegra: Add Tegra132 support

From: Thierry Reding tred...@nvidia.com The memory controller on Tegra132 is very similar to the one found on Tegra124. But the Denver CPUs don't have an outer cache, so dcache maintenance is done slightly differently. Signed-off-by: Thierry Reding tred...@nvidia.com --- Changes in v7: - update

Re: [PATCH v7 00/12] NVIDIA Tegra memory controller and IOMMU support

On Thu, Nov 13, 2014 at 11:12:20AM +0100, Arnd Bergmann wrote: On Thursday 13 November 2014 10:32:25 Thierry Reding wrote: From: Thierry Reding tred...@nvidia.com This is the sixth installment in the Tegra IOMMU and memory controller support series. This version addresses the final

Re: [PATCH v7 01/12] clk: tegra: Implement memory-controller clock

On Thu, Nov 13, 2014 at 05:53:56PM -0800, Mike Turquette wrote: Quoting Thierry Reding (2014-11-13 01:32:26) From: Thierry Reding tred...@nvidia.com The memory controller clock runs either at half or the same frequency as the EMC clock. Reviewed-By: Tomeu Vizoso tomeu.viz

Re: [PATCH v6 1/8] iommu: provide early initialisation hook for IOMMU drivers

On Tue, Dec 02, 2014 at 10:36:59AM +0100, Arnd Bergmann wrote: On Tuesday 02 December 2014 10:23:00 Marek Szyprowski wrote: +static inline void of_iommu_set_ops(struct device_node *np, + const struct iommu_ops *ops) +{ + np-data = (struct

Re: [PATCH v6 1/8] iommu: provide early initialisation hook for IOMMU drivers

On Fri, Dec 05, 2014 at 01:06:52PM +, Grant Likely wrote: On Fri, Dec 5, 2014 at 12:35 PM, Robin Murphy robin.mur...@arm.com wrote: Hi Will, On 05/12/14 12:10, Will Deacon wrote: [...] Do you expect drivers to modify that *priv pointer after the ops structure is registered? I'd

Re: [PATCH v6 1/8] iommu: provide early initialisation hook for IOMMU drivers

On Fri, Dec 05, 2014 at 01:21:31PM +, Grant Likely wrote: On Fri, Dec 5, 2014 at 1:18 PM, Thierry Reding thierry.red...@gmail.com wrote: On Fri, Dec 05, 2014 at 01:06:52PM +, Grant Likely wrote: On Fri, Dec 5, 2014 at 12:35 PM, Robin Murphy robin.mur...@arm.com wrote: Hi

Re: [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall

On Sun, Dec 14, 2014 at 02:45:36PM +0200, Laurent Pinchart wrote: Hi Marek, Thank you for the patch. On Wednesday 19 November 2014 12:15:47 Marek Szyprowski wrote: This patch introduces IOMMU_OF_DECLARE-based initialization to the driver, which replaces subsys_initcall-based procedure.

Re: [PATCH 0/2] Change order of linkage in kernel makefiles for amdkfd

On Mon, Dec 22, 2014 at 01:07:13PM +0200, Oded Gabbay wrote: This small patch-set, was created to solve the bug described at https://bugzilla.kernel.org/show_bug.cgi?id=89661 (Kernel panic when trying use amdkfd driver on Kaveri). It replaces the previous patch-set called [PATCH 0/3] Use

[PATCH 3/4] iommu/rockchip: Play nice in multi-platform builds

From: Thierry Reding tred...@nvidia.com The Rockchip IOMMU driver unconditionally executes code and registers a struct iommu_ops with the platform bus irrespective of whether it runs on a Rockchip SoC or not. This causes problems in multi-platform kernels where drivers for other SoCs

[PATCH 4/4] iommu/msm: Mark driver BROKEN

From: Thierry Reding tred...@nvidia.com The MSM IOMMU driver unconditionally calls bus_set_iommu(), which is a very stupid thing to do on multi-platform kernels. While marking the driver BROKEN may seem a little extreme, there is no other way to make the driver skip initialization. One

[PATCH 0/4] iommu: A couple of urgent fixes

From: Thierry Reding tred...@nvidia.com Hi Joerg, Here are a couple of urgent fixes for a regression on old Tegra devices related to IOMMU support. The issue is that many drivers think it's a good idea to register IOMMU support unconditionally, which is not the smart thing to do at all on multi

[PATCH 2/4] iommu/omap: Play nice in multi-platform builds

From: Thierry Reding tred...@nvidia.com The OMAP IOMMU driver unconditionally executes code and registers a struct iommu_ops with the platform bus irrespective of whether it runs on an OMAP SoC or not. This causes problems in multi-platform kernels where drivers for other SoCs will no longer

Re: [PATCH 3/5] iommu: Limit iommu_attach/detach_device to devices with their own group

On Tue, Jan 27, 2015 at 01:08:57AM +0100, Joerg Roedel wrote: From: Joerg Roedel jroe...@suse.de This patch changes the behavior of the iommu_attach_device and iommu_detach_device functions. With this change these functions only work on devices that have their own group. For all other

[PATCH v2 2/4] iommu/omap: Play nice in multi-platform builds

From: Thierry Reding tred...@nvidia.com The OMAP IOMMU driver unconditionally executes code and registers a struct iommu_ops with the platform bus irrespective of whether it runs on an OMAP SoC or not. This causes problems in multi-platform kernels where drivers for other SoCs will no longer

[PATCH v2 1/4] iommu/exynos: Play nice in multi-platform builds

From: Thierry Reding tred...@nvidia.com The Exynos System MMU driver unconditionally executes code and registers a struct iommu_ops with the platform bus irrespective of whether it runs on an Exynos SoC or not. This causes problems in multi-platform kernels where drivers for other SoCs

[PATCH v2 0/4] iommu: A couple of urgent fixes

From: Thierry Reding tred...@nvidia.com Hi Joerg, Here are a couple of urgent fixes for a regression on old Tegra devices related to IOMMU support. The issue is that many drivers think it's a good idea to register IOMMU support unconditionally, which is not the smart thing to do at all on multi

[PATCH v2 4/4] iommu/msm: Mark driver BROKEN

From: Thierry Reding tred...@nvidia.com The MSM IOMMU driver unconditionally calls bus_set_iommu(), which is a very stupid thing to do on multi-platform kernels. While marking the driver BROKEN may seem a little extreme, there is no other way to make the driver skip initialization. One

[PATCH v2 3/4] iommu/rockchip: Play nice in multi-platform builds

From: Thierry Reding tred...@nvidia.com The Rockchip IOMMU driver unconditionally executes code and registers a struct iommu_ops with the platform bus irrespective of whether it runs on a Rockchip SoC or not. This causes problems in multi-platform kernels where drivers for other SoCs

Re: [PATCH 2/4] iommu/omap: Play nice in multi-platform builds

On Wed, Feb 04, 2015 at 04:31:55PM +0200, Laurent Pinchart wrote: Hi Thierry, Thank you for the patch. On Wednesday 04 February 2015 08:58:08 Thierry Reding wrote: From: Thierry Reding tred...@nvidia.com The OMAP IOMMU driver unconditionally executes code and registers a struct

Re: [PATCH 2/4] iommu/omap: Play nice in multi-platform builds

On Wed, Feb 04, 2015 at 11:37:52AM -0600, Suman Anna wrote: Hi Thierry, On 02/04/2015 08:31 AM, Laurent Pinchart wrote: Hi Thierry, Thank you for the patch. On Wednesday 04 February 2015 08:58:08 Thierry Reding wrote: From: Thierry Reding tred...@nvidia.com The OMAP IOMMU

Re: [PATCH v6 8/8] arm: dma-mapping: plumb our iommu mapping ops into arch_setup_dma_ops

On Sun, Jan 18, 2015 at 01:18:51PM +0200, Laurent Pinchart wrote: Hi Alexandre, On Sunday 18 January 2015 15:54:34 Alexandre Courbot wrote: On 01/16/2015 08:18 AM, Laurent Pinchart wrote: [...] The second way is to implement a mechanism to let drivers signal that they want to handle

Re: [PATCH v6 8/8] arm: dma-mapping: plumb our iommu mapping ops into arch_setup_dma_ops

On Fri, Jan 16, 2015 at 01:18:21AM +0200, Laurent Pinchart wrote: [...] The second way is to implement a mechanism to let drivers signal that they want to handle DMA mappings themselves. As the mappings need in the general case to be created before the probe function is called we can't signal

Re: [PATCH v6 8/8] arm: dma-mapping: plumb our iommu mapping ops into arch_setup_dma_ops

On Mon, Jan 19, 2015 at 12:50:52PM +, Will Deacon wrote: On Mon, Jan 19, 2015 at 12:43:06PM +, Thierry Reding wrote: On Sun, Jan 18, 2015 at 01:18:51PM +0200, Laurent Pinchart wrote: On Sunday 18 January 2015 15:54:34 Alexandre Courbot wrote: On 01/16/2015 08:18 AM, Laurent

Re: [PATCH v6 8/8] arm: dma-mapping: plumb our iommu mapping ops into arch_setup_dma_ops

On Mon, Jan 19, 2015 at 04:52:41PM +0100, Arnd Bergmann wrote: On Monday 19 January 2015 13:36:24 Thierry Reding wrote: On Fri, Jan 16, 2015 at 01:18:21AM +0200, Laurent Pinchart wrote: On Thursday 15 January 2015 11:12:17 Will Deacon wrote: On Thu, Jan 15, 2015 at 08:28:44AM +

Re: [PATCH v6 8/8] arm: dma-mapping: plumb our iommu mapping ops into arch_setup_dma_ops

Pinchart wrote: On Thursday 15 January 2015 11:12:17 Will Deacon wrote: On Thu, Jan 15, 2015 at 08:28:44AM +, Thierry Reding wrote: On Wed, Jan 14, 2015 at 10:46:10AM +, Will Deacon wrote: On Wed, Jan 14, 2015 at 09:00:24AM +, Alexandre Courbot wrote: [...] 2) Say

Re: [PATCH v6 8/8] arm: dma-mapping: plumb our iommu mapping ops into arch_setup_dma_ops

On Fri, Jan 16, 2015 at 01:18:21AM +0200, Laurent Pinchart wrote: On Thursday 15 January 2015 11:12:17 Will Deacon wrote: On Thu, Jan 15, 2015 at 08:28:44AM +, Thierry Reding wrote: On Wed, Jan 14, 2015 at 10:46:10AM +, Will Deacon wrote: On Wed, Jan 14, 2015 at 09:00:24AM +

Re: [PATCH v6 8/8] arm: dma-mapping: plumb our iommu mapping ops into arch_setup_dma_ops

On Wed, Jan 14, 2015 at 07:17:50PM +, Will Deacon wrote: On Wed, Jan 14, 2015 at 01:51:36PM +, Heiko Stübner wrote: Am Mittwoch, 14. Januar 2015, 10:46:10 schrieb Will Deacon: On Wed, Jan 14, 2015 at 09:00:24AM +, Alexandre Courbot wrote: On 12/02/2014 01:57 AM, Will Deacon

Re: [PATCH 0/2] Change order of linkage in kernel makefiles for amdkfd

On Thu, Jan 08, 2015 at 04:15:42PM +0200, Oded Gabbay wrote: Hi Thierry, Generally I agree with the issues you describe in the current design. One task in our 2015 workplan is to change the whole method amdkfd is loaded, so it can independently load at any time, regardless of the order of

Re: [PATCH v2] memory: Add NVIDIA SMMU suspend/resume support

On Wed, Dec 24, 2014 at 09:10:41AM +0800, Mark Zhang wrote: This patch adds suspend/resume support for NVIDIA SMMU. Signed-off-by: Mark Zhang ma...@nvidia.com --- Hi Alex/Olof/Thierry/Hiroshi, This patch is created on top of Thierry Reding's patch set: [PATCH v7 00/12] NVIDIA Tegra

Re: [PATCH 0/2] Change order of linkage in kernel makefiles for amdkfd

On Mon, Dec 29, 2014 at 10:34:32AM +0100, Christian König wrote: Am 29.12.2014 um 09:16 schrieb Laurent Pinchart: Hi Oded, On Sunday 28 December 2014 13:36:50 Oded Gabbay wrote: On 12/26/2014 11:19 AM, Laurent Pinchart wrote: On Thursday 25 December 2014 14:20:59 Thierry Reding wrote

Re: [PATCH 2/2] iommu: of: enforce const-ness of struct iommu_ops

/of/platform.c| 2 +- include/linux/dma-mapping.h | 2 +- include/linux/of_iommu.h | 8 7 files changed, 18 insertions(+), 17 deletions(-) Acked-by: Thierry Reding tred...@nvidia.com pgp6r5DU0lSOG.pgp Description: PGP signature

Re: [PATCH 1/4] iommu/tegra-smmu: Add debugfs support

On Fri, Mar 27, 2015 at 11:07:24AM +0100, Thierry Reding wrote: From: Thierry Reding tred...@nvidia.com Provide clients and swgroups files in debugfs. These files show for which clients IOMMU translation is enabled and which ASID is associated with each SWGROUP. Cc: Hiroshi Doyu hd

[PATCH 1/4] iommu/tegra-smmu: Add debugfs support

From: Thierry Reding tred...@nvidia.com Provide clients and swgroups files in debugfs. These files show for which clients IOMMU translation is enabled and which ASID is associated with each SWGROUP. Cc: Hiroshi Doyu hd...@nvidia.com Signed-off-by: Thierry Reding tred...@nvidia.com --- drivers

[PATCH 4/4] iommu/tegra: smmu: Compute PFN mask at runtime

From: Thierry Reding tred...@nvidia.com The SMMU on Tegra30 and Tegra114 supports addressing up to 4 GiB of physical memory. On Tegra124 the addressable physical memory was extended to 16 GiB. The page frame number stored in PTEs therefore requires 20 or 22 bits, depending on SoC generation

[PATCH 3/4] iommu/tegra: gart: Set aperture at domain initialization time

From: Thierry Reding tred...@nvidia.com The aperture of the domain should always be available, otherwise drivers need to attach first before they can use the aperture geometry. Cc: Hiroshi Doyu hd...@nvidia.com Signed-off-by: Thierry Reding tred...@nvidia.com --- drivers/iommu/tegra-gart.c | 25

[PATCH 2/2] iommu/tegra: gart: Provide default -map_sg() callback

From: Thierry Reding tred...@nvidia.com Commit 315786ebbf4a (iommu: Add iommu_map_sg() function) adds a new -map_sg() callback and provides a default implementation that drivers can use until they implement a hardware-specific variant. Unfortunately the Tegra GART driver was not updated as part

[PATCH 0/2] iommu/tegra-gart: Fixes for v3.19

From: Thierry Reding tred...@nvidia.com Hi Joerg, Here are two last-minute fixes that I'd still like to get into v3.19 if at all possible. They fix regressions on Tegra20 systems introduced by enabling IOMMU support for Tegra30 and later. Thanks, Thierry Thierry Reding (2): iommu/tegra: gart

[PATCH 1/2] iommu/tegra: gart: Do not register with bus

From: Thierry Reding tred...@nvidia.com The driver currently doesn't work as expected and causes existing setups with Tegra20 to break after commit df06b759f2cf (drm/tegra: Add IOMMU support). To restore these setups, do not register the operations with the platform bus for now. Fixing

Re: [PATCH 1/4] iommu/tegra-smmu: Add debugfs support

On Tue, Mar 31, 2015 at 05:02:14PM +0200, Joerg Roedel wrote: Hi Thierry, On Fri, Mar 27, 2015 at 11:15:41AM +0100, Thierry Reding wrote: Another possibility would be for you to ack this patch so that I can take it into the same branch as the dependency. The remainder of this series

Re: [PATCH] iommu: rockchip: fix build without CONFIG_OF

: 425061b0f5074 (iommu/rockchip: Play nice in multi-platform builds) How can this even happen? Rockchip depends on multiplatform, and multiplatform pulls in OF. Ah... COMPILE_TEST... oh well. Reviewed-by: Thierry Reding tred...@nvidia.com pgpZZOI4Hrr9X.pgp Description: PGP signature

[PATCH] iommu/tegra-smmu: Parameterize number of TLB lines

From: Thierry Reding tred...@nvidia.com The number of TLB lines was increased from 16 on Tegra30 to 32 on Tegra114 and later. Parameterize the value so that the initial default can be set accordingly. On Tegra30, initializing the value to 32 would effectively disable the TLB and hence cause

[GIT PULL 6/9] iommu/tegra-smmu: Changes for v4.3-rc1

manipulation iommu/tegra-smmu: Use __GFP_ZERO to allocate zeroed pages iommu/tegra-smmu: Extract tegra_smmu_pte_get_use() iommu/tegra-smmu: Factor out tegra_smmu_set_pde() Thierry Reding (1): iommu/tegra-smmu: Parameterize number of TLB lines drivers/iommu/tegra-smmu.c

[GIT PULL 0/9] ARM: tegra: Changes for v4.3-rc1

Hi ARM SoC maintainers, Mike, Stephen, Linus, Joerg, Here's a set of pull requests with changes for v4.3-rc1. This is coming in rather late, but most of this is pretty trivial, so I hope it can still be merged for the v4.3 window. Thanks, Thierry ___

Re: [PATCH 16/18] iommu: tegra-smmu: get_use

On Mon, Jul 27, 2015 at 01:30:07PM +0100, Russell King wrote: Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/iommu/tegra-smmu.c | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) Joerg may want to have a proper commit message here. If you're too

Re: [PATCH 18/18] iommu: tegra-smmu: remove cacheflush.h

On Mon, Jul 27, 2015 at 01:30:17PM +0100, Russell King wrote: Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/iommu/tegra-smmu.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c index e5d6bc45c58f..4a8b66f05d8f

Re: [PATCH 17/18] iommu: tegra-smmu: more cleanups

On Mon, Jul 27, 2015 at 01:30:12PM +0100, Russell King wrote: Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- drivers/iommu/tegra-smmu.c | 49 ++ 1 file changed, 28 insertions(+), 21 deletions(-) Same here. Thierry signature.asc

Re: [PATCH 00/18] Clean up exposure of arch-internal code

On Mon, Jul 27, 2015 at 03:16:54PM +0100, Russell King - ARM Linux wrote: On Mon, Jul 27, 2015 at 04:09:06PM +0200, Thierry Reding wrote: On Mon, Jul 27, 2015 at 01:28:24PM +0100, Russell King - ARM Linux wrote: This series of patches attempts to clean up the use of architecture internal

Re: [RFC PATCH 0/3] iommu: Add range flush operation

On Tue, Sep 29, 2015 at 02:25:23PM +0900, Tomasz Figa wrote: > Currently the IOMMU subsystem provides 3 basic operations: iommu_map(), > iommu_map_sg() and iommu_unmap(). iommu_map() can be used to map memory > page by page, however it involves flushing the caches (CPU and IOMMU) for > every

Re: [RFC PATCH 2/3] memory: tegra: add TLB cache line size

On Tue, Sep 29, 2015 at 02:25:25PM +0900, Tomasz Figa wrote: > From: Vince Hsu > > This patch adds SMMU line size to Tegra SoC data struct to enable SMMU > driver to use this knowledge in code added by further patch. I think the line size should either be added in the same

Re: [RFC PATCH 1/3] iommu: Add support for out of band flushing

On Tue, Sep 29, 2015 at 02:25:24PM +0900, Tomasz Figa wrote: > This patch adds a new "flush" callback to iommu_ops, which is supposed > to perform any necessary flushes within given IOMMU domain to make any > changes to mappings of given area [iova; iova + size) be reflected to > IOMMU clients. >

[PATCH] iommu/msm: Use platform_register/unregister_drivers()

From: Thierry Reding <tred...@nvidia.com> These new helpers simplify implementing multi-driver modules and properly handle failure to register one driver by unregistering all previously registered drivers. Signed-off-by: Thierry Reding <tred...@nvidia.com> --- drivers/iommu/msm_iomm

Re: [PATCH 2/2] iommu: Add dummy implementations for !IOMMU_IOVA

On Wed, Mar 22, 2017 at 03:55:30PM +0100, Joerg Roedel wrote: > Hi Thierry > > On Mon, Mar 20, 2017 at 08:14:31PM +0100, Thierry Reding wrote: > > I've got a series of patches that I'd like to merge for v4.12 that have > > a build-time dependency on this patch. It wou

Re: [iommu:core 3/3] drivers/iommu/iova.c:36: error: redefinition of 'init_iova_domain'

On Thu, Mar 23, 2017 at 02:28:27AM +0800, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git core > head: 21aff52ab2c831c2f07d48e2fa8d4bab26a66992 > commit: 21aff52ab2c831c2f07d48e2fa8d4bab26a66992 [3/3] iommu: Add dummy > implementations for

[PATCH 1/2] MAINTAINERS: Add related headers to IOMMU section

From: Thierry Reding <tred...@nvidia.com> The linux/iommu.h and linux/iova.h headers belong to the IOMMU subsystem but scripts/get_maintainers.pl currently fails to assign them because they aren't listed in MAINTAINERS. Signed-off-by: Thierry Reding <tred...@nvidia.com> --- MAI

[PATCH 2/2] iommu: Add dummy implementations for !IOMMU_IOVA

From: Thierry Reding <tred...@nvidia.com> Currently, building code which uses the API guarded by the IOMMU_IOVA will fail to link if IOMMU_IOVA is not enabled. Often this code will be using the API provided by the IOMMU_API Kconfig symbol, but support for this can be optional, with code f

Re: [PATCH 2/2] iommu: Add dummy implementations for !IOMMU_IOVA

On Mon, Mar 20, 2017 at 08:11:28PM +0100, Thierry Reding wrote: > From: Thierry Reding <tred...@nvidia.com> > > Currently, building code which uses the API guarded by the IOMMU_IOVA > will fail to link if IOMMU_IOVA is not enabled. Often this code will be > using the API prov

Re: [PATCH 0/2] iommu/tegra*: Add support for struct iommu_device

> iommu/tegra-gart: Add support for struct iommu_device > > drivers/iommu/tegra-gart.c | 26 ++ > drivers/iommu/tegra-smmu.c | 25 +++++ > 2 files changed, 51 insertions(+) The series: Acked-by: Thierr

Re: [PATCH 2/2] iommu/tegra-gart: Add support for struct iommu_device

On Thu, Aug 17, 2017 at 01:21:52AM +0300, Dmitry Osipenko wrote: > Hello Joerg, > > On 10.08.2017 01:29, Joerg Roedel wrote: > > From: Joerg Roedel > > > > Add a struct iommu_device to each tegra-gart and register it > > with the iommu-core. Also link devices added to the

Re: [PATCH 10/13] drm/tegra: Use sychronized interface of the IOMMU-API

convert this code to use the synchronized > functions so that it will behave as before. > > Cc: Thierry Reding <thierry.red...@gmail.com> > Cc: David Airlie <airl...@linux.ie> > Cc: Jonathan Hunter <jonath...@nvidia.com> > Cc: dri-de...@lists.freedesktop.org &g

Re: [PATCH 2/2] iommu/tegra-gart: Add support for struct iommu_device

> Signed-off-by: Joerg Roedel <jroe...@suse.de> > --- > drivers/iommu/tegra-gart.c | 26 ++ > 1 file changed, 26 insertions(+) Acked-by: Thierry Reding <tred...@nvidia.com> signature.asc Description: PGP signature

Re: [PATCH 1/2] iommu/tegra: Add support for struct iommu_device

> Signed-off-by: Joerg Roedel <jroe...@suse.de> > --- > drivers/iommu/tegra-smmu.c | 25 + > 1 file changed, 25 insertions(+) Acked-by: Thierry Reding <tred...@nvidia.com> signature.asc Description: PGP signature

Re: [PATCH 01/44] firmware/ivc: use dma_mapping_error

On Thu, Jun 08, 2017 at 03:25:26PM +0200, Christoph Hellwig wrote: > DMA_ERROR_CODE is not supposed to be used by drivers. > > Signed-off-by: Christoph Hellwig <h...@lst.de> > --- > drivers/firmware/tegra/ivc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-)

Re: [PATCH v1 2/4] iommu/tegra: gart: Check whether page is already mapped

On Tue, Sep 26, 2017 at 04:49:52PM +0300, Dmitry Osipenko wrote: > On 26.09.2017 14:06, Thierry Reding wrote: > > On Wed, Jul 05, 2017 at 07:29:46PM +0300, Dmitry Osipenko wrote: > >> Due to a bug, multiple devices may try to map the same IOVA region. We can > >>

Re: [PATCH v1 2/4] iommu/tegra: gart: Check whether page is already mapped

On Wed, Jul 05, 2017 at 07:29:46PM +0300, Dmitry Osipenko wrote: > Due to a bug, multiple devices may try to map the same IOVA region. We can > catch that case by checking that 'VALID' bit of the GART's page entry is > unset prior to mapping of the page. Due to what bug? Sounds to me like access

Re: [PATCH v1 3/4] iommu/tegra: gart: Move PFN validation out of spinlock

gra-gart.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Acked-by: Thierry Reding <tred...@nvidia.com> signature.asc Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v1 4/4] iommu/tegra: gart: Correct number of unmapped bytes

ry mapping an IOVA that wasn't properly unmapped before. Anyway, this looks like the right thing to do: Acked-by: Thierry Reding <tred...@nvidia.com> signature.asc Description: PGP signature ___ iommu mailing list iommu@lists.linux-foundation.o

Re: [PATCH v1 1/4] iommu/tegra: gart: Don't unnecessarily allocate registers context

On Wed, Jul 05, 2017 at 07:29:45PM +0300, Dmitry Osipenko wrote: > GART looses it's state only in case of a deepest suspend level. Let's not > waste memory if machine doesn't support that suspend level. > > Signed-off-by: Dmitry Osipenko > --- > drivers/iommu/tegra-gart.c | 36

[PATCH 1/2] iommu/tegra: Allow devices to be grouped

From: Thierry Reding <tred...@nvidia.com> Implement the ->device_group() and ->of_xlate() callbacks which are used in order to group devices. Each group can then share a single domain. This is implemented primarily in order to achieve the same semantics on Tegra210 and earlier as

[PATCH 2/2] memory: tegra: Create SMMU display groups

From: Thierry Reding <tred...@nvidia.com> Create SMMU display groups for Tegra30, Tegra114, Tegra124 and Tegra210. This allows the display controllers on these devices to share the same IOMMU domain using the standard IOMMU group mechanism. Signed-off-by: Thierry Reding <tred...@n

Re: [PATCH 0/2] iommu/tegra: Add IOMMU group support

On Mon, Nov 27, 2017 at 10:50:53AM +0100, Thierry Reding wrote: > From: Thierry Reding <tred...@nvidia.com> > > Hi Joerg, > > Both patches in this series are built-time dependent and therefore it > would be easiest if they went in via the same tree (either the IOMMU &

[PATCH 0/2] iommu/tegra: Add IOMMU group support

From: Thierry Reding <tred...@nvidia.com> Hi Joerg, Both patches in this series are built-time dependent and therefore it would be easiest if they went in via the same tree (either the IOMMU tree, or the Tegra tree with your Acked-by on patch 1). Alternatively, I could put pat

Re: [PATCH -next] iommu/tegra-smmu: Fix return value check in tegra_smmu_group_get()

On Wed, Dec 20, 2017 at 09:44:00AM -0700, Alex Williamson wrote: > On Wed, 20 Dec 2017 03:06:09 + > Wei Yongjun wrote: > > > In case of error, the function iommu_group_alloc() returns ERR_PTR() and > > never returns NULL. The NULL test in the return value check should

Re: [PATCH v1 3/4] iommu/tegra: gart: Constify number of GART pages

On Mon, Apr 09, 2018 at 11:07:21PM +0300, Dmitry Osipenko wrote: > GART has a fixed aperture size, hence the number of pages is constant. > > Signed-off-by: Dmitry Osipenko > --- > drivers/iommu/tegra-gart.c | 14 -- > 1 file changed, 8 insertions(+), 6

Re: [PATCH v1 2/4] iommu/tegra: gart: Fix gart_iommu_unmap()

ivers/iommu/tegra-gart.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Thierry Reding <tred...@nvidia.com> Acked-by: Thierry Reding <tred...@nvidia.com> signature.asc Description: PGP signature ___ iommu mailing list

Re: [PATCH v1 4/4] iommu/tegra: gart: Optimize map/unmap

On Mon, Apr 09, 2018 at 11:07:22PM +0300, Dmitry Osipenko wrote: > Currently GART writes one page entry at a time. More optimal would be to > aggregate the writes and flush BUS buffer in the end, this gives map/unmap > 10-40% (depending on size of mapping) performance boost compared to a >

Re: [PATCH v1 1/4] iommu/tegra: gart: Add debugging facility

ouldn't be needed unless the IOVA allocator or GART driver are buggy. That said, I think this has some usefulness to find such bugs, so: Acked-by: Thierry Reding <tred...@nvidia.com> signature.asc Description: PGP signature ___ iommu mailing list

[PATCH v3 0/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

From: Thierry Reding An unfortunate interaction between the 32-bit ARM DMA/IOMMU mapping code and Tegra SMMU driver changes to support IOMMU groups introduced a boot- time regression on Tegra124. This was caught very late because none of the standard configurations that are tested on Tegra

[PATCH v3 1/2] ARM: dma-mapping: Implement arm_dma_iommu_detach_device()

From: Thierry Reding Implement this function to enable drivers from detaching from any IOMMU domains that architecture code might have attached them to so that they can take exclusive control of the IOMMU via the IOMMU API. Signed-off-by: Thierry Reding --- Changes in v3: - make API 32-bit ARM

[PATCH v3 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

From: Thierry Reding Depending on the kernel configuration, early ARM architecture setup code may have attached the GPU to a DMA/IOMMU mapping that transparently uses the IOMMU to back the DMA API. Tegra requires special handling for IOMMU backed buffers (a special bit in the GPU's MMU page

Re: [PATCH v3 1/2] ARM: dma-mapping: Implement arm_dma_iommu_detach_device()

On Wed, May 30, 2018 at 10:59:30AM +0100, Robin Murphy wrote: > On 30/05/18 09:03, Thierry Reding wrote: > > From: Thierry Reding > > > > Implement this function to enable drivers from detaching from any IOMMU > > domains that architecture code might have attached t

Re: [PATCH v3 1/2] ARM: dma-mapping: Implement arm_dma_iommu_detach_device()

On Wed, May 30, 2018 at 02:54:46PM +0200, Thierry Reding wrote: > On Wed, May 30, 2018 at 10:59:30AM +0100, Robin Murphy wrote: > > On 30/05/18 09:03, Thierry Reding wrote: > > > From: Thierry Reding > > > > > > Implement this function to enable d

Re: [PATCH v3 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

On Wed, May 30, 2018 at 02:30:51PM +0100, Robin Murphy wrote: > On 30/05/18 14:00, Thierry Reding wrote: > > On Wed, May 30, 2018 at 11:30:25AM +0100, Robin Murphy wrote: > > > On 30/05/18 09:03, Thierry Reding wrote: > > > > From: Thierry Reding > >

Re: [PATCH v3 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

On Wed, May 30, 2018 at 11:30:25AM +0100, Robin Murphy wrote: > On 30/05/18 09:03, Thierry Reding wrote: > > From: Thierry Reding > > > > Depending on the kernel configuration, early ARM architecture setup code > > may have attached the GPU to a DMA/IOMMU mapp

[PATCH v4 0/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

From: Thierry Reding An unfortunate interaction between the 32-bit ARM DMA/IOMMU mapping code and Tegra SMMU driver changes to support IOMMU groups introduced a boot- time regression on Tegra124. This was caught very late because none of the standard configurations that are tested on Tegra

[PATCH v4 2/2] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

From: Thierry Reding Depending on the kernel configuration, early ARM architecture setup code may have attached the GPU to a DMA/IOMMU mapping that transparently uses the IOMMU to back the DMA API. Tegra requires special handling for IOMMU backed buffers (a special bit in the GPU's MMU page

[PATCH v4 1/2] ARM: dma-mapping: Set proper DMA ops in arm_iommu_detach_device()

From: Thierry Reding Instead of setting the DMA ops pointer to NULL, set the correct, non-IOMMU ops depending on the device's coherency setting. Signed-off-by: Thierry Reding --- Changes in v4: - new patch to fix existing arm_iommu_detach_device() to do what we need arch/arm/mm/dma-mapping.c

Re: [PATCH v3 1/2] ARM: dma-mapping: Implement arm_dma_iommu_detach_device()

On Wed, May 30, 2018 at 02:42:50PM +0100, Robin Murphy wrote: > On 30/05/18 14:12, Thierry Reding wrote: > > On Wed, May 30, 2018 at 02:54:46PM +0200, Thierry Reding wrote: > > > On Wed, May 30, 2018 at 10:59:30AM +0100, Robin Murphy wrote: > > > > On 30/05/

Re: [PATCH v4 1/2] ARM: dma-mapping: Set proper DMA ops in arm_iommu_detach_device()

On Wed, May 30, 2018 at 04:06:24PM +0200, Thierry Reding wrote: > From: Thierry Reding > > Instead of setting the DMA ops pointer to NULL, set the correct, > non-IOMMU ops depending on the device's coherency setting. > > Signed-off-by: Thierry Reding > --- > Changes in

Re: [PATCH v2 2/5] dma-mapping: Introduce dma_iommu_detach_device() API

On Mon, Apr 30, 2018 at 12:41:52PM +0100, Robin Murphy wrote: > On 30/04/18 12:02, Thierry Reding wrote: > > On Thu, Apr 26, 2018 at 02:11:36PM +0200, Thierry Reding wrote: > > > On Wed, Apr 25, 2018 at 08:19:34AM -0700, Christoph Hellwig wrote: > > > > On Wed, Ap

Re: [PATCH v2 2/5] dma-mapping: Introduce dma_iommu_detach_device() API

On Thu, Apr 26, 2018 at 02:11:36PM +0200, Thierry Reding wrote: > On Wed, Apr 25, 2018 at 08:19:34AM -0700, Christoph Hellwig wrote: > > On Wed, Apr 25, 2018 at 12:10:48PM +0200, Thierry Reding wrote: > > > From: Thierry Reding <tred...@nvidia.com> > > > > &

Re: [PATCH v4 1/2] dma-mapping: move dma configuration to bus infrastructure

The conditional here is somewhat pointless since the of_node should always be set. If it weren't it should be considered a bug and this function welcome to crash to make that very obvious. Either way: Acked-by: Thierry Reding <tred...@nvidia.com> signature.asc Description: PGP signature

Re: [PATCH v2 1/8] memory: tegra: Provide facility for integration with the GART driver

On Sat, Aug 04, 2018 at 05:29:56PM +0300, Dmitry Osipenko wrote: > In order to report clients name and access direction on GART's page fault, > MC driver need to access GART registers. Add facility that provides access > to the GART. > > Signed-off-by: Dmitry Osipenko > --- >

Re: [PATCH v2 2/8] iommu/tegra: gart: Provide access to Memory Controller driver

On Sat, Aug 04, 2018 at 05:29:57PM +0300, Dmitry Osipenko wrote: > GART contain registers needed by the Memory Controller driver, provide > access to the MC driver by utilizing its GART-integration facility. > > Signed-off-by: Dmitry Osipenko > --- > drivers/iommu/tegra-gart.c | 23

Re: [PATCH v2 2/8] iommu/tegra: gart: Provide access to Memory Controller driver

On Thu, Aug 09, 2018 at 02:39:03PM +0300, Dmitry Osipenko wrote: > On Thursday, 9 August 2018 14:17:46 MSK Thierry Reding wrote: > > On Sat, Aug 04, 2018 at 05:29:57PM +0300, Dmitry Osipenko wrote: > > > GART contain registers needed by the Memory Controller driver, provide >

Re: [PATCH v2 2/8] iommu/tegra: gart: Provide access to Memory Controller driver

On Thu, Aug 09, 2018 at 05:22:59PM +0300, Dmitry Osipenko wrote: > On Thursday, 9 August 2018 16:59:24 MSK Thierry Reding wrote: > > On Thu, Aug 09, 2018 at 02:39:03PM +0300, Dmitry Osipenko wrote: > > > On Thursday, 9 August 2018 14:17:46 MSK Thierry Reding wrote: > >

Re: [PATCH v3 06/19] dt-bindings: memory: tegra: Squash tegra20-gart into tegra20-mc

On Mon, Aug 20, 2018 at 10:35:54PM +0300, Dmitry Osipenko wrote: > On 20.08.2018 22:27, Dmitry Osipenko wrote: > > On 20.08.2018 22:12, Rob Herring wrote: > >> On Sat, Aug 18, 2018 at 06:54:17PM +0300, Dmitry Osipenko wrote: > >>> Splitting GART and Memory Controller wasn't a good decision that

[PATCH v2 1/5] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

From: Thierry Reding <tred...@nvidia.com> Depending on the kernel configuration, early ARM architecture setup code may have attached the GPU to a DMA/IOMMU mapping that transparently uses the IOMMU to back the DMA API. Tegra requires special handling for IOMMU backed buffers (a speci

<    1   2   3   4   5   6   7   >