1st step shows we should NOT disable the iommu when it is already
enabled. But current code does disable-enable. So there is still works
to do.
The original kernel does a disable and re-enable , Bill's patchset
removed the disable operation.
I think step 2 is necessary, because when the
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
The ARM SMMU driver is compatible with the notion of a type-1 IOMMU in
VFIO.
This patch allows VFIO_IOMMU_TYPE1 to be selected if ARM_SMMU=y.
Signed-off-by: Will Deacon will.dea...@arm.com
---
Alex: I'm wondering if we can't just drop the dependency clause here
altogether. What breaks if we
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.
Signed-off-by: Will Deacon will.dea...@arm.com
---
arch/arm/kernel/setup.c | 2 ++
1
Hello everybody,
Here is the fourth iteration of the RFC I've previously posted here:
RFCv1:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/283023.html
RFCv2:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/283752.html
RFCv3:
This patch adds a new function to the iommu_ops structure to allow an
OF device to be added to a specific IOMMU instance using the recently
merged generic devicetree binding for IOMMUs. The callback (of_xlate)
takes a struct device representing the master and an of_phandle_args
representing the
IOMMU drivers must be initialised before any of their upstream devices,
otherwise the relevant iommu_ops won't be configured for the bus in
question. To solve this, a number of IOMMU drivers use initcalls to
initialise the driver before anything has a chance to be probed.
Whilst this solves the
set_arch_dma_coherent_ops is called from of_dma_configure in order to
swizzle the architectural dma-mapping functions over to a cache-coherent
implementation. This is currently implemented only for ARM.
In anticipation of re-using this mechanism for IOMMU-backed dma-mapping
ops too, this patch
The generic IOMMU device-tree bindings can be used to add arbitrary OF
masters to an IOMMU with a compliant binding.
This patch introduces of_iommu_configure, which does exactly that.
Signed-off-by: Will Deacon will.dea...@arm.com
---
drivers/iommu/Kconfig| 2 +-
drivers/iommu/of_iommu.c |
of_dma_configure determines the size of the DMA range for a device by
either parsing the dma-ranges property or inspecting the coherent DMA
mask. This same information can be used to initialise the max segment
size and boundary_mask to a default value.
Signed-off-by: Will Deacon
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 ops.
Signed-off-by: Will Deacon will.dea...@arm.com
---
arch/arm/include/asm/dma-mapping.h | 4 +++-
drivers/of/platform.c | 21 ++---
On Friday 14 November 2014 18:56:29 Will Deacon wrote:
Here is the fourth iteration of the RFC I've previously posted here:
RFCv1:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/283023.html
RFCv2:
Hi Arnd,
Thanks for having a look.
On Fri, Nov 14, 2014 at 07:11:23PM +, Arnd Bergmann wrote:
On Friday 14 November 2014 18:56:29 Will Deacon wrote:
Here is the fourth iteration of the RFC I've previously posted here:
RFCv1:
On Friday 14 November 2014 19:27:54 Will Deacon wrote:
At the moment, iommu_ops is a structure that can get used for any
number of iommus of the same type, but by putting per-device private
data into the same structure you have to duplicate it per instance.
I'm not sure I agree -- the
On Thu, Nov 13 2014 at 01:48:26 AM, Will Deacon will.dea...@arm.com wrote:
Ha, damn, then I don't have a user of the shiny new quirks field I added!
I don't think I'll go as far as removing it altogether though...
I'm sure we'll be making liberal use of that field soon enough ;)
-Mitch
--
Let's try this again as plain text...
For a PCIe device with SR-IOV support enabled (e.g. the PF device ID is 0xf001
at :07:00.0 and the 16 VFs have device ID 0xf002 at :07:01.0 through
:07:02.7), if the hardware attempts a DMA read/write of memory that was
mapped by the PF devfn
For a PCIe device with SR-IOV support enabled (e.g. the PF device ID is 0xf001
at :07:00.0 and the 16 VFs have device ID 0xf002 at :07:01.0 through
:07:02.7), if the hardware attempts a DMA read/write of memory that was
mapped by the PF devfn but instead uses a requester id of one
[+cc Alex, add a subject]
On Fri, Nov 14, 2014 at 6:49 PM, Allan, Bruce W bruce.w.al...@intel.com wrote:
Let's try this again as plain text...
For a PCIe device with SR-IOV support enabled (e.g. the PF device ID is
0xf001 at :07:00.0 and the 16 VFs have device ID 0xf002 at :07:01.0
18 matches
Mail list logo
