On Wed, Nov 12, 2014 at 04:02:34PM +0100, Joerg Roedel wrote:
> On Wed, Nov 12, 2014 at 03:47:16PM +0100, Thierry Reding wrote:
> > The SMMU is part of a larger IP block that's also a memory controller.
> > Having it in drivers/iommu would mean that we need to provid
From: Thierry Reding
Rather than duplicate the ARM_AMBA Kconfig symbol in both 32-bit and
64-bit ARM architectures, move the common definition to drivers/amba
where dependent drivers will be located.
Signed-off-by: Thierry Reding
---
Hi Russell, Will, Catalin,
As explained in the cover-letter
From: Thierry Reding
The memory controller on NVIDIA Tegra exposes various knobs that can be
used to tune the behaviour of the clients attached to it.
In addition, the memory controller implements an SMMU (IOMMU) which can
translate I/O virtual addresses to physical addresses for clients. This
From: Thierry Reding
The memory controller clock runs either at half or the same frequency as
the EMC clock.
Reviewed-By: Tomeu Vizoso
Signed-off-by: Thierry Reding
---
Mike, as I said in the cover letter there are tight dependencies between the
patches in this series, so I'd like to get
From: Thierry Reding
This is the sixth installment in the Tegra IOMMU and memory controller
support series. This version addresses the final outstanding comments from
Olof about using proper Kconfig symbols to track the dependencies. It also
splits up the driver into one part that implements the
From: Thierry Reding
This will allow the Kconfig option to be shared among 32-bit and 64-bit
ARM.
Signed-off-by: Thierry Reding
---
Hi Russell,
As explained in the cover-letter there are tight dependencies between the
patches in this series, so for simplicity I'd like to take this
From: Thierry Reding
Collapses the old memory-controller and IOMMU device tree nodes into a
single node to more accurately describe the hardware.
While this is an incompatible change there are no users of the IOMMU on
Tegra, even though a driver has existed for some time.
Signed-off-by
From: Thierry Reding
The memory controller on NVIDIA Tegra exposes various knobs that can be
used to tune the behaviour of the clients attached to it.
Currently this driver sets up the latency allowance registers to the HW
defaults. Eventually an API should be exported by this driver (via a
From: Thierry Reding
Add iommus properties to the device tree nodes for the two display
controllers found on Tegra114. 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.
Signed-off-by
From: Thierry Reding
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.
Signed-off-by
From: Thierry Reding
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
---
arch/arm/boot/dts/tegra124
From: Thierry Reding
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.
Signed-off-by
From: Thierry Reding
Add the device tree node for the memory controller found on Tegra114
SoCs. The memory controller integrates an IOMMU (called SMMU) as well as
various knobs to tweak memory accesses by the various clients.
The old IOMMU device tree node is collapsed into the memory
From: Thierry Reding
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
---
Changes in v7:
- update help text
drivers/iommu/Kc
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
> >
> > This is the sixth installment in the Tegra IOMMU and memory controller
> > support series. This version addr
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
> >
> > The memory controller clock runs either at half or the same frequency as
> > the EMC clock.
> >
> > Revie
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
On Thu, Dec 04, 2014 at 01:43:32PM +, Robin Murphy wrote:
> Hi Grant, thanks for the advice - silly micro-optimisations removed, and
> I'll make a note to do so from my in-development code, too ;)
>
> I didn't much like the casting either, so rather than push it elsewhere or
> out to the calle
On Fri, Dec 05, 2014 at 01:06:52PM +, Grant Likely wrote:
> On Fri, Dec 5, 2014 at 12:35 PM, Robin Murphy 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
On Fri, Dec 05, 2014 at 01:21:31PM +, Grant Likely wrote:
> On Fri, Dec 5, 2014 at 1:18 PM, Thierry Reding
> wrote:
> > On Fri, Dec 05, 2014 at 01:06:52PM +, Grant Likely wrote:
> >> On Fri, Dec 5, 2014 at 12:35 PM, Robin Murphy wrote:
> >> > Hi Will
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 pro
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]
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
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
>
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
> ---
> Hi Alex/Olof/Thierry/Hiroshi,
>
> This patch is created on top of Thierry Reding's patch set:
> "[PATCH v7 00/12] NVIDIA Tegra memory contro
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 you want to use the IOMMU API in your driver, and have an iommu
> > property in your device's DT node. If by chance your IOMMU is registered
> > early
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
t; > >> On 01/16/2015 08:18 AM, 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:10A
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 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
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 sign
On Mon, Jan 19, 2015 at 12:50:52PM +, Will Deacon wrote:
> On Mon, Jan 19, 2015 at 12:43:06PM +0000, 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:
> > &g
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 T
From: Thierry Reding
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 o
From: Thierry Reding
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: Do not reg
From: Thierry Reding
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 this proper
On Tue, Jan 27, 2015 at 01:08:57AM +0100, Joerg Roedel wrote:
> From: Joerg Roedel
>
> 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 devices the iom
From: Thierry Reding
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 be able to register
From: Thierry Reding
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 of the problems is that it
From: Thierry Reding
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-platform ke
From: Thierry Reding
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 will no longer be able to
From: Thierry Reding
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 will no longer be able to
From: Thierry Reding
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 will no longer be able to
From: Thierry Reding
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-platform ke
From: Thierry Reding
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 be able to register
From: Thierry Reding
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 of the problems is that it
From: Thierry Reding
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 will no longer be able to
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
> >
> > The OMAP IOMMU driver unconditionally execute
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:
> >>
patch moves the field from iommu_ops into the iommu_domain and
> updates all users accordingly.
>
> Signed-off-by: Will Deacon
> ---
[...]
> drivers/iommu/tegra-gart.c | 2 +-
> drivers/iommu/tegra-smmu.c | 3 +--
Acked-by: Thierry Reding
drivers/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
pgp6r5DU0lSOG.pgp
Description: PGP signature
_
From: Thierry Reding
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.
In order to cope with
From: Thierry Reding
Each address space in the Tegra SMMU provides 4 GiB worth of addresses.
Cc: Hiroshi Doyu
Signed-off-by: Thierry Reding
---
drivers/iommu/tegra-smmu.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index
From: Thierry Reding
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
Signed-off-by: Thierry Reding
---
drivers/iommu/tegra-smmu.c | 109
From: Thierry Reding
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
Signed-off-by: Thierry Reding
---
drivers/iommu/tegra-gart.c | 25 ++---
1 file changed, 14
On Fri, Mar 27, 2015 at 11:07:24AM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> 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
On Fri, Mar 27, 2015 at 11:07:25AM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Each address space in the Tegra SMMU provides 4 GiB worth of addresses.
>
> Cc: Hiroshi Doyu
> Signed-off-by: Thierry Reding
> ---
> drivers/iommu/tegra-smmu.c | 5 +
> 1
/iommu/tegra-smmu.c | 41 +++--
> 1 file changed, 23 insertions(+), 18 deletions(-)
Acked-by: Thierry Reding
pgpUypubyWb7L.pgp
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
/iommu/tegra-gart.c | 67
> +++---
> 1 file changed, 46 insertions(+), 21 deletions(-)
Acked-by: Thierry Reding
pgpykpODTRoTm.pgp
Description: PGP signature
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
rivers/iommu/shmobile-iommu.c | 40 +++
> drivers/iommu/tegra-gart.c | 67 +--
> drivers/iommu/tegra-smmu.c | 41 ++-
> include/linux/iommu.h | 17 ++--
> 16 files changed, 407 insertions(+), 317 del
disabled.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 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.
Rev
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.
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
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
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
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
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/
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
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
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
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 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,
On Thu, Aug 29, 2019 at 03:47:03PM -0700, Krishna Reddy wrote:
> 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
On Thu, Aug 29, 2019 at 03:47:04PM -0700, Krishna Reddy wrote:
> 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
>
>
On Thu, Aug 29, 2019 at 03:47:05PM -0700, Krishna Reddy wrote:
> 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/nv
On Fri, Aug 30, 2019 at 06:12:08PM +, Krishna Reddy wrote:
> >> +"nidia,smmu-v2"
> >> "qcom,smmu-v2"
>
> >I agree with Mikko that the compatible must be at least SoC-specific, but
> >potentially even instance-specific (e.g. "nvidia,tegra194-gp
On Mon, Sep 02, 2019 at 03:22:35PM +0100, Robin Murphy wrote:
> On 29/08/2019 12:14, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > For device tree nodes, use the standard of_iommu_get_resv_regions()
> > implementation to obtain the reserved memory regions a
On Mon, Sep 02, 2019 at 02:54:23PM +0100, Robin Murphy wrote:
> On 29/08/2019 12:14, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > This is an implementation that IOMMU drivers can use to obtain reserved
> > memory regions from a device tree node. It
From: Thierry Reding
Hi,
this series proposes the introduction of a mini-framework for memory
controllers. The primary use-case for this right now is to allow for
drivers that depend on the memory controller to defer probe until the
memory controller has been successfully registered.
One
From: Thierry Reding
This new framework is currently nothing more than a registry of memory
controllers, with the goal being to order device probing. One use-case
where this is useful, for example, is a memory controller device which
needs to program some registers before the system MMU can be
From: Thierry Reding
Use the memory controller framework to obtain a reference to the memory
controller to which the SMMU will make memory requests. This allows the
two drivers to properly order their probes so that the memory controller
can be programmed first.
An example where this is
From: Thierry Reding
Registering as memory controller allows other drivers to obtain a
reference to it. This is mostly useful as a way of ordering probe
between devices depending on one another.
Signed-off-by: Thierry Reding
---
drivers/memory/tegra/tegra186.c | 8 +++-
1 file changed, 7
From: Navneet Kumar
Enable clients' translation only after setting up the swgroups.
Signed-off-by: Navneet Kumar
Signed-off-by: Thierry Reding
---
drivers/iommu/tegra-smmu.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/iommu/
From: Thierry Reding
Page tables that reside in physical memory beyond the 4 GiB boundary are
currently not working properly. The reason is that when the physical
address for page directory entries is read, it gets truncated at 32 bits
and can cause crashes when passing that address to the DMA
mitry Osipenko
Tested-by: Dmitry Osipenko
Signed-off-by: Thierry Reding
---
drivers/iommu/tegra-smmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 99f85fb5a704..03e667480ec6 100644
--- a/drivers/iommu/tegra-s
On Wed, Sep 18, 2019 at 04:37:38PM +0100, Will Deacon wrote:
> On Thu, Aug 29, 2019 at 01:17:48PM +0200, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > Implement a generic function for removing reserved regions. This can be
> > used by drivers that don
On Thu, Oct 31, 2019 at 06:11:33PM +0300, Dmitry Osipenko wrote:
> 15.10.2019 19:29, Thierry Reding пишет:
> > From: Thierry Reding
> >
> > This new framework is currently nothing more than a registry of memory
> > controllers, with the goal being to order device prob
On Tue, Sep 17, 2019 at 06:59:50PM +0100, Will Deacon wrote:
> On Mon, Sep 02, 2019 at 04:52:45PM +0200, Thierry Reding wrote:
> > On Mon, Sep 02, 2019 at 03:22:35PM +0100, Robin Murphy wrote:
> > > On 29/08/2019 12:14, Thierry Reding wrote:
> > > > From: Thierr
On Wed, Nov 27, 2019 at 01:16:54PM +0100, Thierry Reding wrote:
> On Tue, Sep 17, 2019 at 06:59:50PM +0100, Will Deacon wrote:
> > On Mon, Sep 02, 2019 at 04:52:45PM +0200, Thierry Reding wrote:
> > > On Mon, Sep 02, 2019 at 03:22:35PM +0100, Robin Murphy wrote:
> >
On Wed, Nov 27, 2019 at 05:09:41PM +, Robin Murphy wrote:
> On 27/11/2019 2:16 pm, Thierry Reding wrote:
> [...]
> > Nevermind that, I figured out that I was missingthe initialization of
> > some of the S2CR variables. I've got something that I think is working
> >
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
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
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
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
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 bd25674ee4db
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
---
Changes in v2:
- change subject prefix to 'iommu: virt:' to 'iommu: virtio:'
drivers/
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/
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.
Changes in v2:
- change subject prefix to "
From: Thierry Reding
On some platforms, the firmware will setup hardware to read from a given
region of memory. One such example is a display controller that is
scanning out a splash screen from physical memory.
During Linux' boot process, the ARM SMMU will configure all contexts to
fau
301 - 400 of 716 matches
Mail list logo
