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
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
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
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
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
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
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
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 +
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
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 +
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
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 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
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
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
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.
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
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
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
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
From: Thierry Reding tred...@nvidia.com
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 tred...@nvidia.com
---
Hi Russell
From: Thierry Reding tred...@nvidia.com
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
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...@collabora.com
Signed-off-by: Thierry Reding tred...@nvidia.com
---
Mike, as I said in the cover letter there are tight
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 outstanding comments from
Olof about using proper Kconfig symbols to track the dependencies. It also
splits up the driver into one part
From: Thierry Reding tred...@nvidia.com
This will allow the Kconfig option to be shared among 32-bit and 64-bit
ARM.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
Hi Russell,
As explained in the cover-letter there are tight dependencies between the
patches in this series, so
From: Thierry Reding tred...@nvidia.com
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
From: Thierry Reding tred...@nvidia.com
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
From: Thierry Reding tred...@nvidia.com
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
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
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
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
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
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
On Wed, Nov 12, 2014 at 03:21:50PM +0100, Joerg Roedel wrote:
On Fri, Nov 07, 2014 at 05:00:56PM +0100, Thierry Reding wrote:
drivers/iommu/tegra-smmu.c | 1295
--
drivers/memory/tegra/smmu.c | 716 +
This new
On Mon, Nov 10, 2014 at 05:25:39PM +, Will Deacon wrote:
On Fri, Nov 07, 2014 at 03:26:18PM +, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
Currently the driver registers IOMMU bus operations for all busses even
if no ARM SMMU is present on a system. Depending
From: Thierry Reding tred...@nvidia.com
Currently the driver registers IOMMU bus operations for all busses even
if no ARM SMMU is present on a system. Depending on the driver probing
order this prevents the driver for the real IOMMU to register itself as
the bus-wide IOMMU.
Signed-off
From: Thierry Reding tred...@nvidia.com
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 tred...@nvidia.com
---
Hi Russell
From: Thierry Reding tred...@nvidia.com
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
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
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...@collabora.com
Signed-off-by: Thierry Reding tred...@nvidia.com
---
Mike, as I said in the cover letter there are tight
From: Thierry Reding tred...@nvidia.com
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
From: Thierry Reding tred...@nvidia.com
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
From: Thierry Reding tred...@nvidia.com
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
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 outstanding comments from
Olof about using proper Kconfig symbols to track the dependencies. It also
splits up the driver into one part
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
---
drivers/memory/tegra
From: Thierry Reding tred...@nvidia.com
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
On Wed, Oct 01, 2014 at 11:54:11AM -0400, Sean Paul wrote:
On Tue, Sep 30, 2014 at 2:48 PM, Sean Paul seanp...@google.com wrote:
On Thu, Jun 26, 2014 at 4:49 PM, Thierry Reding thierry.red...@gmail.com
wrote:
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
On Tue, Sep 30, 2014 at 02:48:35PM -0400, Sean Paul wrote:
On Thu, Jun 26, 2014 at 4:49 PM, Thierry Reding
thierry.red...@gmail.com wrote:
From: Thierry Reding tred...@nvidia.com
When an IOMMU device is available on the platform bus, allocate an IOMMU
domain and attach the display
On Sat, Nov 01, 2014 at 02:38:26PM +0900, Alexandre Courbot wrote:
On Fri, Oct 31, 2014 at 10:27 PM, Thierry Reding
thierry.red...@gmail.com wrote:
On Thu, Oct 30, 2014 at 04:08:41PM +0100, Thierry Reding wrote:
On Wed, Oct 15, 2014 at 03:09:30PM -0700, Olof Johansson wrote:
Hi,
Oh
On Thu, Oct 30, 2014 at 04:08:41PM +0100, Thierry Reding wrote:
On Wed, Oct 15, 2014 at 03:09:30PM -0700, Olof Johansson wrote:
Hi,
Oh, a few more comments:
On Mon, Oct 13, 2014 at 3:33 AM, Thierry Reding
thierry.red...@gmail.com wrote:
diff --git a/drivers/memory/Makefile b
On Fri, Oct 17, 2014 at 10:43:56AM -0700, David Riley wrote:
Hi Thierry,
On Mon, Oct 13, 2014 at 3:33 AM, Thierry Reding
thierry.red...@gmail.com wrote:
From: Thierry Reding tred...@nvidia.com
Collapses the old memory-controller and IOMMU device tree nodes into a
single node to more
On Mon, Oct 20, 2014 at 01:02:45PM +0200, Tomeu Vizoso wrote:
On 13 October 2014 12:33, Thierry Reding thierry.red...@gmail.com wrote:
[...]
+struct clk *tegra_clk_register_mc(const char *name, const char
*parent_name,
+ void __iomem *reg, spinlock_t *lock
On Wed, Oct 15, 2014 at 03:09:30PM -0700, Olof Johansson wrote:
Hi,
Oh, a few more comments:
On Mon, Oct 13, 2014 at 3:33 AM, Thierry Reding
thierry.red...@gmail.com wrote:
diff --git a/drivers/memory/Makefile b/drivers/memory/Makefile
index c32d31981be3..1c932e7e7b8d 100644
On Wed, Oct 15, 2014 at 03:05:36PM -0700, Olof Johansson wrote:
Hi,
On Mon, Oct 13, 2014 at 3:33 AM, Thierry Reding
thierry.red...@gmail.com wrote:
[...]
diff --git a/drivers/memory/tegra/tegra-mc.c
b/drivers/memory/tegra/tegra-mc.c
new file mode 100644
index
On Mon, Aug 18, 2014 at 06:57:50PM +0200, Joerg Roedel wrote:
On Fri, Aug 01, 2014 at 02:45:13PM +0200, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
This allows IOMMU drivers to compile even if IOMMU_API is not selected
and helps improve compile coverage.
IOMMU
On Mon, Oct 06, 2014 at 12:02:47PM -0700, Olav Haugan wrote:
On 9/25/2014 10:01 AM, Joerg Roedel wrote:
On Mon, Aug 11, 2014 at 03:45:50PM -0700, Olav Haugan wrote:
+static inline int iommu_map_sg(struct iommu_domain *domain, unsigned long
iova,
+ struct scatterlist
On Tue, Oct 14, 2014 at 03:20:46PM +0200, Arnd Bergmann wrote:
On Tuesday 14 October 2014 16:07:38 Laurent Pinchart wrote:
On Tuesday 23 September 2014 09:44:25 Arnd Bergmann wrote:
On Tuesday 23 September 2014 09:02:39 Thierry Reding wrote:
I see two problems with using deferred
On Tue, Oct 14, 2014 at 06:01:58PM +0300, Laurent Pinchart wrote:
Hi Thierry,
On Tuesday 14 October 2014 15:37:59 Thierry Reding wrote:
On Tue, Oct 14, 2014 at 03:20:46PM +0200, Arnd Bergmann wrote:
On Tuesday 14 October 2014 16:07:38 Laurent Pinchart wrote:
On Tuesday 23 September
From: Thierry Reding tred...@nvidia.com
The memory controller clock runs either at half or the same frequency as
the EMC clock.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
Changes in v3:
- split registration into a separate function that can be reused for all
SoC generations, but pass
From: Thierry Reding tred...@nvidia.com
This will allow the Kconfig option to be shared among 32-bit and 64-bit
ARM.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
Changes in v4:
- add precursory patch introducing drivers/amba/Kconfig, rebase on top
Changes in v3:
- select ARM_AMBA from
From: Thierry Reding tred...@nvidia.com
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
From: Thierry Reding tred...@nvidia.com
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 tred...@nvidia.com
---
arch/arm/Kconfig
From: Thierry Reding tred...@nvidia.com
Collapses the old memory-controller and IOMMU device tree nodes into a
single node to more accurately describe the hardware.
Note that this is an incompatible change, but while a GART driver has
existed for a few years it has never been used to do any
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
From: Thierry Reding tred...@nvidia.com
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
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
From: Thierry Reding tred...@nvidia.com
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
From: Thierry Reding tred...@nvidia.com
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
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
On Fri, Oct 03, 2014 at 04:08:50PM +0100, Will Deacon wrote:
Hi Thierry,
On Wed, Oct 01, 2014 at 09:46:10AM +0100, Thierry Reding wrote:
On Tue, Sep 30, 2014 at 05:00:35PM +0100, Will Deacon wrote:
On Thu, Sep 25, 2014 at 07:40:23AM +0100, Thierry Reding wrote:
[...]
So I think what
On Mon, Oct 06, 2014 at 01:50:40PM +0300, Laurent Pinchart wrote:
Hi Thierry and Will,
On Monday 06 October 2014 11:52:50 Thierry Reding wrote:
On Fri, Oct 03, 2014 at 04:08:50PM +0100, Will Deacon wrote:
On Wed, Oct 01, 2014 at 09:46:10AM +0100, Thierry Reding wrote:
On Tue, Sep 30
On Wed, Oct 01, 2014 at 11:54:11AM -0400, Sean Paul wrote:
On Tue, Sep 30, 2014 at 2:48 PM, Sean Paul seanp...@google.com wrote:
On Thu, Jun 26, 2014 at 4:49 PM, Thierry Reding
thierry.red...@gmail.com wrote:
From: Thierry Reding tred...@nvidia.com
When an IOMMU device is available
On Mon, Sep 29, 2014 at 09:47:34AM -0700, Mitchel Humpherys wrote:
On Mon, Sep 29 2014 at 01:31:37 AM, Thierry Reding thierry.red...@gmail.com
wrote:
On Sat, Sep 27, 2014 at 08:27:28PM -0700, Mitchel Humpherys wrote:
From: Matt Wagantall ma...@codeaurora.org
It is sometimes necessary
versions are provided with and
without timeouts.
Cc: Thierry Reding thierry.red...@gmail.com
Cc: Will Deacon will.dea...@arm.com
Signed-off-by: Matt Wagantall ma...@codeaurora.org
Signed-off-by: Mitchel Humpherys mitch...@codeaurora.org
---
include/linux/iopoll.h | 77
()
is useless.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
drivers/pci/msi.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
Reviewed-by: Thierry Reding tred...@nvidia.com
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 51d7e62..50f67a3 100644
--- a/drivers/pci
On Fri, Sep 26, 2014 at 02:20:35PM +0800, Yijing Wang wrote:
The PCI core can already deal with that. An MSI chip can be set per bus
and the weak pcibios_add_bus() can be used to set that. Often it might
not even be necessary to do it via pcibios_add_bus() if you create the
root bus
On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
[...]
At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
directly (patch attached).
Really attached this time.
Thierry
From 2cedfcf38cdfe21688d1363659f28e271ce43358 Mon Sep 17 00:00:00 2001
From: Thierry
On Wed, Sep 24, 2014 at 05:33:38PM +0100, Will Deacon wrote:
On Tue, Sep 23, 2014 at 08:14:01AM +0100, Thierry Reding wrote:
On Mon, Sep 22, 2014 at 06:43:37PM +0100, Will Deacon wrote:
Yup. In this case, the iommu_dma_mapping passed to arch_setup_dma_ops
contains a domain
On Thu, Sep 25, 2014 at 11:14:12AM +0800, Yijing Wang wrote:
Currently, PCI drivers will initialize bus-msi in
pcibios_add_bus(). pcibios_add_bus() will be called
in every pci bus initialization. So the bus-msi
assignment in pci_alloc_child_bus() is useless.
I think this should be the other
On Thu, Sep 25, 2014 at 11:14:11AM +0800, Yijing Wang wrote:
Msi_chip functions setup_irq/teardown_irq rarely use msi_chip
argument.
That's not true. Out of the four drivers that you modify two use the
parameter. And the two that don't probably should be using it too.
50% is not rarely. =)
On Thu, Sep 25, 2014 at 11:14:13AM +0800, Yijing Wang wrote:
Currently, pcie-designware, pcie-rcar, pci-tegra drivers
use irq chip_data to save the msi_chip pointer. They
already call irq_set_chip_data() in their own MSI irq map
functions. So irq_set_chip_data() in arch_setup_msi_irq()
is
On Thu, Sep 25, 2014 at 11:14:16AM +0800, Yijing Wang wrote:
Introduce weak arch_find_msi_chip() to find the match msi_chip.
Currently, MSI chip associates pci bus to msi_chip. Because in
ARM platform, there may be more than one MSI controller in system.
Associate pci bus to msi_chip help pci
On Thu, Sep 25, 2014 at 11:14:22AM +0800, Yijing Wang wrote:
[...]
diff --git a/arch/mips/pci/msi-octeon.c b/arch/mips/pci/msi-octeon.c
[...]
@@ -132,12 +132,12 @@ msi_irq_allocated:
/* Make sure the search for available interrupts didn't fail */
if (irq = 64) {
if
On Thu, Sep 25, 2014 at 11:14:24AM +0800, Yijing Wang wrote:
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Nit: s/irq/IRQ/ in the above.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
On Thu, Sep 25, 2014 at 11:14:25AM +0800, Yijing Wang wrote:
[...]
diff --git a/arch/mips/pci/pci-xlr.c b/arch/mips/pci/pci-xlr.c
[...]
@@ -214,11 +214,11 @@ static int get_irq_vector(const struct pci_dev *dev)
}
#ifdef CONFIG_PCI_MSI
-void arch_teardown_msi_irq(unsigned int irq)
+void
On Thu, Sep 25, 2014 at 11:14:27AM +0800, Yijing Wang wrote:
[...]
diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c
[...]
@@ -358,7 +358,7 @@ static void zpci_irq_handler(struct airq_struct *airq)
}
}
-int arch_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type)
+int
On Thu, Sep 25, 2014 at 03:48:55PM +0100, Liviu Dudau wrote:
On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote:
On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote:
This series is based Bjorn's pci/msi branch
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas
On Tue, Sep 23, 2014 at 09:44:25AM +0200, Arnd Bergmann wrote:
On Tuesday 23 September 2014 09:02:39 Thierry Reding wrote:
I see two problems with using deferred probing here:
- we don't actually need to defer the probing but the binding to the
driver
when no dma ops are set
On Fri, Sep 12, 2014 at 05:34:55PM +0100, Will Deacon wrote:
[...]
+static bool arm_setup_iommu_dma_ops(struct device *dev, u64 dma_base, u64
size)
+{
+ struct dma_iommu_mapping *mapping;
+
+ mapping = arm_iommu_create_mapping(dev-bus, dma_base, size);
If I understand correctly
On Tue, Sep 16, 2014 at 06:04:48PM +, Varun Sethi wrote:
Hi Arnd,
-Original Message-
From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
boun...@lists.linux-foundation.org] On Behalf Of Arnd Bergmann
Sent: Monday, September 15, 2014 10:27 PM
To: Sethi
On Thu, Sep 18, 2014 at 02:17:33PM +0300, Laurent Pinchart wrote:
Hi Will,
Thank you for the patch.
On Friday 12 September 2014 17:34:53 Will Deacon wrote:
This patch extends of_dma_configure so that it sets up the IOMMU for a
device, as well as the coherent/non-coherent DMA mapping
On Fri, Sep 12, 2014 at 05:34:54PM +0100, Will Deacon wrote:
We need to ensure that the IOMMUs in the system have a chance to perform
some basic initialisation before we start adding masters to them.
This patch adds a call to of_iommu_init before of_platform_populate.
Why can't you call it
On Mon, Sep 22, 2014 at 01:08:27PM +0200, Arnd Bergmann wrote:
On Monday 22 September 2014 11:36:15 Thierry Reding wrote:
On Fri, Sep 12, 2014 at 05:34:54PM +0100, Will Deacon wrote:
We need to ensure that the IOMMUs in the system have a chance to perform
some basic initialisation before
On Mon, Sep 01, 2014 at 07:22:32AM +0200, Marek Szyprowski wrote:
Hi Greg,
On 2014-08-05 12:47, Marek Szyprowski wrote:
This patch adds a new flags for device drivers. This flag instructs
kernel that the device driver does it own management of IOMMU assisted
IO address space
On Tue, Aug 19, 2014 at 10:52:46PM +0200, Laurent Pinchart wrote:
On Tuesday 19 August 2014 11:40:24 Olav Haugan wrote:
On 8/19/2014 9:11 AM, Laurent Pinchart wrote:
On Tuesday 19 August 2014 13:59:54 Joerg Roedel wrote:
On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote:
If
On Wed, Aug 06, 2014 at 04:28:45PM -0700, Olav Haugan wrote:
On 8/6/2014 1:17 PM, Joerg Roedel wrote:
On Wed, Aug 06, 2014 at 10:08:55AM -0700, Olav Haugan wrote:
so you are suggesting that I check in bus_set_iommu() whether the
driver has set the map_sg/unmap_sg function pointers or not
From: Thierry Reding tred...@nvidia.com
This allows IOMMU drivers to compile even if IOMMU_API is not selected
and helps improve compile coverage.
Signed-off-by: Thierry Reding tred...@nvidia.com
---
include/linux/iommu.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux
From: Thierry Reding tred...@nvidia.com
With this structure always defined, drivers can be always compiled,
irrespective of whether or not IOMMU_API is enabled. This helps to
increase compile coverage without having to build with two separate
configurations.
Unused code can still be discarded
On Wed, Jul 30, 2014 at 04:26:47PM +0100, Mark Rutland wrote:
Hi Thierry,
This looks sane to me.
I just have a few questions below which are hopefully simple/stupid.
On Fri, Jul 04, 2014 at 04:29:17PM +0100, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
This commit
+0100, Thierry Reding wrote:
From: Thierry Reding tred...@nvidia.com
This commit introduces a generic device tree binding for IOMMU devices.
Only a very minimal subset is described here, but it is enough to cover
the requirements of both the Exynos System MMU and Tegra SMMU as
discussed
401 - 500 of 625 matches
Mail list logo
