On 05/08/2015 04:21 PM, Konrad Rzeszutek Wilk wrote:
On Fri, May 01, 2015 at 01:32:12PM -0500, wda...@nvidia.com wrote:
From: Will Davis
Hi,
This patch series adds DMA APIs to map and unmap a struct resource to and from
a PCI device's IOVA domain, and implements the AMD, Intel, and nommu vers
On Fri, May 01, 2015 at 01:32:12PM -0500, wda...@nvidia.com wrote:
> From: Will Davis
>
> Hi,
>
> This patch series adds DMA APIs to map and unmap a struct resource to and from
> a PCI device's IOVA domain, and implements the AMD, Intel, and nommu versions
> of these interfaces.
>
> This solves
On Fri, May 8, 2015 at 10:49 AM, Will Deacon wrote:
> Hi Stuart,
>
> On Thu, May 07, 2015 at 06:49:32PM +0100, Stuart Yoder wrote:
>> On Tue, Mar 24, 2015 at 10:50 AM, Mark Rutland wrote:
>> > Hi all,
>> >
>> > For some devices, identification of particular masters is critical to
>> > their opera
Version three of the ARM SMMU architecture introduces significant
changes and improvements over previous versions of the specification,
necessitating a new driver in the Linux kernel.
The main change to the programming interface is that the majority of the
configuration data has been moved from MM
The ARM SMMUv3 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_V3=y.
Signed-off-by: Will Deacon
---
drivers/vfio/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vfio/Kconfig b/drive
This patch adds device-tree bindings for ARM SMMUv3 IOMMU devices.
Cc: Mark Rutland
Signed-off-by: Will Deacon
---
.../devicetree/bindings/iommu/arm,smmu-v3.txt | 37 ++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/arm,smm
Hi all,
SMMUv3 is a significant departure from previous ARM SMMU designs in that
the majority of the configuration data has been moved from MMIO registers
to in-memory data structures, with communication between the CPU and the
SMMU being mediated via in-memory circular queues. It also has native
Stage 1 translation is controlled by two sets of page tables (TTBR0 and
TTBR1) which grow up and down from zero respectively in the ARMv8
translation regime. For the SMMU, we only care about TTBR0 and, in the
case of a 48-bit virtual space, we expect to map virtual addresses 0x0
through to 0x_f
Hi Stuart,
On Thu, May 07, 2015 at 06:49:32PM +0100, Stuart Yoder wrote:
> On Tue, Mar 24, 2015 at 10:50 AM, Mark Rutland wrote:
> > Hi all,
> >
> > For some devices, identification of particular masters is critical to
> > their operation (e.g. IOMMUs, MSI controllers). The identity of masters
>
On Thu, Apr 23, 2015 at 6:09 PM, Daniel Kurtz wrote:
> On Mon, Apr 20, 2015 at 7:43 PM, Tomasz Figa wrote:
>> To flush created mappings, current mapping code relies on the fact that
>> during unmap the driver zaps every IOVA being unmapped and that it is
>> enough to zap a single IOVA of page tab
10 matches
Mail list logo