On 02/06/2015 10:12 AM, Catalin Marinas wrote:
On Fri, Feb 06, 2015 at 02:54:23PM +, Murali Karicheri wrote:
On 02/06/2015 09:38 AM, Catalin Marinas wrote:
On Thu, Feb 05, 2015 at 09:52:55PM +, Murali Karicheri wrote:
Fix the dma-range size when the DT attribute is missing. i.e set
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 be
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 will no
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
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 of the
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 will no
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
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
On Thu, Feb 05, 2015 at 09:52:55PM +, Murali Karicheri wrote:
Fix the dma-range size when the DT attribute is missing. i.e set size to
dev-coherent_dma_mask + 1 instead of dev-coherent_dma_mask. Also add
code to check invalid values of size configured in DT and log error.
Cc: Joerg
Hello Hann,
On Fri, Feb 06, 2015 at 11:45:55AM +0800, Hann Huang wrote:
Hi all,
I did some experiment which needs two-stage address translation (GVA-GPA-
SPA).
After setting the mode bit in DTE to 100b, I got lots of IO_PAGE_FAULT event
but no any PPR request.
Did you also install a valid
Taking some inspiration from the arch/arm code, implement the
arch-specific side of the DMA mapping ops using the new IOMMU-DMA layer.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
arch/arm64/include/asm/device.h | 3 +
arch/arm64/include/asm/dma-mapping.h | 17 ++
On 02/06/2015 09:38 AM, Catalin Marinas wrote:
On Thu, Feb 05, 2015 at 09:52:55PM +, Murali Karicheri wrote:
Fix the dma-range size when the DT attribute is missing. i.e set size to
dev-coherent_dma_mask + 1 instead of dev-coherent_dma_mask. Also add
code to check invalid values of size
Taking inspiration from the existing arch/arm code, break out some
generic functions to interface the DMA-API to the IOMMU-API. This will
do the bulk of the heavy lifting for IOMMU-backed dma-mapping.
Whilst this RFC series is aimed at enabling arm64, once any remaining
obvious issues in the
Hi all,
This is an updated RFC to address some of the initial comments[1].
The first two patches of the original posting, along with the IOVA
series, are now in -next so aren't included here.
If this is starting to look tidy enough, then I'll get to work on
porting arch/arm as well so I can
With iommu_dma_ops in place, hook them up to the configuration code, so
IOMMU-fronted devices will get them automatically.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/dma-mapping.h | 11 ++-
On 02/06/2015 10:15 AM, Catalin Marinas wrote:
On Thu, Feb 05, 2015 at 09:52:52PM +, Murali Karicheri wrote:
This patch add an important capability to PCI driver on Keystone. I hope to
have this merged to the upstream branch so that it is available for v3.20.
It's very late for 3.20 and
On Thu, Feb 05, 2015 at 09:52:52PM +, Murali Karicheri wrote:
This patch add an important capability to PCI driver on Keystone. I hope to
have this merged to the upstream branch so that it is available for v3.20.
It's very late for 3.20 and the code hasn't been in linux-next at all
(but
This patch was produced using Coccinelle. A simplified version of the
semantic patch is:
@r exists@
identifier f;
local idexpression u8 x;
identifier xname;
@@
f(...) {
...when any
(
x@xname = 1;
|
x@xname = 0;
)
...when any
}
@bad exists@
identifier r.f;
local idexpression u8 r.x
Hi Thierry,
On 02/06/2015 04:44 AM, Thierry Reding wrote:
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
Hi Laura,
As a heads up, I'm still vainly hoping to move the ARM SMMU driver
entirely over to the generic framework - there's an iommu/dev branch on
top of the iommu/dma branch I pushed earlier[1] which you might want to
take a peek at to check if we're likely to end up pulling in different
On 02/06/2015 12:53 PM, Bjorn Helgaas wrote:
On Fri, Feb 6, 2015 at 9:28 AM, Murali Karicherim-kariche...@ti.com wrote:
On 02/06/2015 10:15 AM, Catalin Marinas wrote:
On Thu, Feb 05, 2015 at 09:52:52PM +, Murali Karicheri wrote:
This patch add an important capability to PCI driver on
21 matches
Mail list logo
