[+cc Alex, add a subject]
On Fri, Nov 14, 2014 at 6:49 PM, Allan, Bruce W 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
> through :07:02
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 of
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 bu
On Thu, Nov 13 2014 at 01:48:26 AM, Will Deacon 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
--
Qualcomm Innovatio
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
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:
> > http://lists.infradead.org/pipermail/linu
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:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-Se
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
---
arch/arm/include/asm/dma-mapping.h | 4 +++-
drivers/of/platform.c | 21 ++---
include/linux/dma-mappi
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
---
drivers/iommu/Kconfig| 2 +-
drivers/iommu/of_iommu.c | 33
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
---
drivers/of/p
This patch plumbs the existing ARM IOMMU DMA infrastructure (which isn't
actually called outside of a few drivers) into arch_setup_dma_ops, so
that we can use IOMMUs for DMA transfers in a more generic fashion.
Since this significantly complicates the arch_setup_dma_ops function,
it is moved out o
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 im
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 rep
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:
http://lists.infradead
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 IOM
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
---
arch/arm/kernel/setup.c | 2 ++
1 file changed, 2 insert
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
---
Alex: I'm wondering if we can't just drop the dependency clause here
altogether. What breaks if we allow VFIO_IOMMU_TYPE1
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.
> >
> > Reviewed-By: Tomeu Vizoso
> > Signed-off-by: Thierr
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 d
19 matches
Mail list logo
