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.
While turn off the GPA-to-SPA translation, PPR request comes and no
IO_PAGE_FAULT event.
My question is :
I
From: Mitchel Humpherys
On some platforms with tight power constraints it is polite to only
leave your clocks on for as long as you absolutely need them. Currently
we assume that all clocks necessary for SMMU register access are always
on.
Add some optional device tree properties to specify any
With the addition of clocks in the SMMU driver, the driver
now may need to be deferred if the clocks are not ready. Apart from
just the probe function though, we may need to defer attachment as
well. Support both of these.
Signed-off-by: Laura Abbott
---
I went with the simplest approach ('start
of_dma_configure is currently a void function. IOMMU configuration may
need to defer probing so return appropriate values.
Signed-off-by: Laura Abbott
---
drivers/iommu/of_iommu.c | 14 +++---
drivers/of/device.c | 9 +++--
include/linux/of_device.h | 4 ++--
3 files changed
Setting up the DMA operations may trigger a probe deferral.
Return a proper error code to let probe deferral do its thing.
Signed-off-by: Laura Abbott
---
arch/arm/include/asm/dma-mapping.h | 2 +-
arch/arm/mm/dma-mapping.c| 4 +++-
arch/arm64/include/asm/dma-mapping.h | 2 +-
a
Hi,
On the heels of Exynos integrating SMMU in to the DT for probing,
this series attempts to add support to make SMMU drivers work with
deferred probing. This has been referenced before[1] but this is
some actual code to use as a starting point for discussion.
The requirement for this is based o
Murali,
On Thu, Feb 05, 2015 at 09:42:27PM +, Murali Karicheri wrote:
> On 02/02/2015 07:18 AM, Catalin Marinas wrote:
> > On Fri, Jan 30, 2015 at 06:06:27PM +, Murali Karicheri wrote:
> >> On 01/28/2015 12:30 PM, Catalin Marinas wrote:
> >>> I think we can remove this check altogether (we
Hi Arnd & Bjorn,
I believe this is ready to be merged so that it becomes available in
v3.20. Not sure which subsystem will pick this up. Could you respond?
I am working on another patch to address the size based dma mask
calculation as suggested in this thread and don't want to delay merge of
Function of_iommu_configure() is called from of_dma_configure() to
setup iommu ops using DT property. This API is currently used for
platform devices for which DMA configuration (including iommu ops)
may come from device's parent. To extend this functionality for PCI
devices, this API need to take
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.
Also would like thank everyone for the contribution.
PCI devices on Keystone doesn't have correct dma_pfn_offset set. This patch
add capability to
Move of_dma_configure() to device.c so that same function can be re-used
for PCI devices to obtain DMA configuration from DT. Also add a second
argument so that for PCI, DT node of root bus host bridge can be used to
obtain the DMA configuration for the slave PCI device.
Cc: Joerg Roedel
Cc: Gran
If there is a DT node available for the root bridge's parent device,
use the dma configuration from that device node. For example, keystone
PCI devices would require dma_pfn_offset to be set correctly in the
device structure of the pci device in order to have the correct dma mask.
The DT node will
Add a helper function to get/put the root bus's host bridge device.
Cc: Joerg Roedel
Cc: Grant Likely
Cc: Rob Herring
Cc: Will Deacon
Cc: Russell King
Cc: Arnd Bergmann
Cc: Suravee Suthikulpanit
Acked-by: Bjorn Helgaas
Signed-off-by: Murali Karicheri
---
drivers/pci/host-bridge.c | 14
arm_iommu_create_mapping() has size parameter of size_t and
arm_setup_iommu_dma_ops() can take a value higher than that
when this is called from the of code. So limit the size to
SIZE_MAX.
Cc: Joerg Roedel
Cc: Grant Likely
Cc: Rob Herring
Cc: Bjorn Helgaas
Cc: Will Deacon
Cc: Russell King
Cc
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 Roedel
Cc: Grant Likely
Cc: Rob Herring
Cc: Bjorn Helgaas
Cc: Will Dea
Add of_pci_dma_configure() to allow updating the dma configuration
of the pci device using the configuration from DT of the parent of
the root bridge device. Use the newly added APIs
pci_get/put_host_bridge_device() for implementing this.
Cc: Joerg Roedel
Cc: Grant Likely
Cc: Will Deacon
Cc: Ru
On 02/02/2015 07:18 AM, Catalin Marinas wrote:
On Fri, Jan 30, 2015 at 06:06:27PM +, Murali Karicheri wrote:
On 01/28/2015 12:30 PM, Catalin Marinas wrote:
I think we can remove this check altogether (we leaved without it for a
while) but we need to add 1 when calculating the mask:
From: Markus Elfring
Date: Thu, 5 Feb 2015 17:54:16 +0100
The vfree() function performs also input parameter validation.
Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/iommu/tegra-gart.c | 3 +--
On 02/05/2015 01:40 PM, Joerg Roedel wrote:
So this should be the correct version then.
From 2a52250e542d8964c8285a37b71fe838a44c05c4 Mon Sep 17 00:00:00 2001
From: Joerg Roedel
Date: Wed, 4 Feb 2015 15:50:38 +0100
Subject: [PATCH 1/2] iommu/amd: Use wait_event in put_pasid_state_wait
Now th
On Wed, Feb 04, 2015 at 05:34:50PM +0100, Peter Zijlstra wrote:
> You just lost your atomic_dec.
So this should be the correct version then.
>From 2a52250e542d8964c8285a37b71fe838a44c05c4 Mon Sep 17 00:00:00 2001
From: Joerg Roedel
Date: Wed, 4 Feb 2015 15:50:38 +0100
Subject: [PATCH 1/2] iommu/
On Wed, 2015-02-04 at 16:17 +0100, Joerg Roedel wrote:
> The AMD address is dead for a long time already, replace it
> with a working one.
Maybe add a .mailmap entry too.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfounda
Hi Thierry,
Am Mittwoch, 4. Februar 2015, 08:58:09 schrieb Thierry Reding:
> 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
22 matches
Mail list logo
