2011-06-02 07:48:05 +08:00
|
|
|
# IOMMU_API always gets selected by whoever wants it.
|
|
|
|
|
config IOMMU_API
|
|
|
|
|
bool
|
2011-06-02 08:20:08 +08:00
|
|
|
|
2011-06-14 21:51:54 +08:00
|
|
|
menuconfig IOMMU_SUPPORT
|
|
|
|
|
bool "IOMMU Hardware Support"
|
2015-01-28 22:45:53 +08:00
|
|
|
depends on MMU
|
2011-06-14 21:51:54 +08:00
|
|
|
default y
|
|
|
|
|
---help---
|
|
|
|
|
Say Y here if you want to compile device drivers for IO Memory
|
|
|
|
|
Management Units into the kernel. These devices usually allow to
|
|
|
|
|
remap DMA requests and/or remap interrupts from other devices on the
|
|
|
|
|
system.
|
|
|
|
|
|
|
|
|
|
if IOMMU_SUPPORT
|
|
|
|
|
|
2014-11-15 01:16:49 +08:00
|
|
|
menu "Generic IOMMU Pagetable Support"
|
|
|
|
|
|
|
|
|
|
# Selected by the actual pagetable implementations
|
|
|
|
|
config IOMMU_IO_PGTABLE
|
|
|
|
|
bool
|
|
|
|
|
|
2014-11-15 01:18:23 +08:00
|
|
|
config IOMMU_IO_PGTABLE_LPAE
|
|
|
|
|
bool "ARMv7/v8 Long Descriptor Format"
|
|
|
|
|
select IOMMU_IO_PGTABLE
|
2015-07-30 02:46:04 +08:00
|
|
|
# SWIOTLB guarantees a dma_to_phys() implementation
|
|
|
|
|
depends on ARM || ARM64 || (COMPILE_TEST && SWIOTLB)
|
2014-11-15 01:18:23 +08:00
|
|
|
help
|
|
|
|
|
Enable support for the ARM long descriptor pagetable format.
|
|
|
|
|
This allocator supports 4K/2M/1G, 16K/32M and 64K/512M page
|
|
|
|
|
sizes at both stage-1 and stage-2, as well as address spaces
|
|
|
|
|
up to 48-bits in size.
|
|
|
|
|
|
2014-11-18 07:31:12 +08:00
|
|
|
config IOMMU_IO_PGTABLE_LPAE_SELFTEST
|
|
|
|
|
bool "LPAE selftests"
|
|
|
|
|
depends on IOMMU_IO_PGTABLE_LPAE
|
|
|
|
|
help
|
|
|
|
|
Enable self-tests for LPAE page table allocator. This performs
|
|
|
|
|
a series of page-table consistency checks during boot.
|
|
|
|
|
|
|
|
|
|
If unsure, say N here.
|
|
|
|
|
|
2014-11-15 01:16:49 +08:00
|
|
|
endmenu
|
|
|
|
|
|
2015-01-13 01:51:13 +08:00
|
|
|
config IOMMU_IOVA
|
2015-07-13 19:31:30 +08:00
|
|
|
tristate
|
2015-01-13 01:51:13 +08:00
|
|
|
|
2012-06-25 19:23:54 +08:00
|
|
|
config OF_IOMMU
|
|
|
|
|
def_bool y
|
2014-08-27 23:20:32 +08:00
|
|
|
depends on OF && IOMMU_API
|
2012-06-25 19:23:54 +08:00
|
|
|
|
2013-07-15 12:50:57 +08:00
|
|
|
config FSL_PAMU
|
|
|
|
|
bool "Freescale IOMMU support"
|
2015-01-20 23:13:33 +08:00
|
|
|
depends on PPC32
|
|
|
|
|
depends on PPC_E500MC || COMPILE_TEST
|
2013-07-15 12:50:57 +08:00
|
|
|
select IOMMU_API
|
|
|
|
|
select GENERIC_ALLOCATOR
|
|
|
|
|
help
|
|
|
|
|
Freescale PAMU support. PAMU is the IOMMU present on Freescale QorIQ platforms.
|
|
|
|
|
PAMU can authorize memory access, remap the memory address, and remap I/O
|
|
|
|
|
transaction types.
|
|
|
|
|
|
2011-06-02 08:20:08 +08:00
|
|
|
# MSM IOMMU support
|
|
|
|
|
config MSM_IOMMU
|
|
|
|
|
bool "MSM IOMMU Support"
|
2015-01-20 23:13:33 +08:00
|
|
|
depends on ARM
|
|
|
|
|
depends on ARCH_MSM8X60 || ARCH_MSM8960 || COMPILE_TEST
|
2015-02-06 18:44:08 +08:00
|
|
|
depends on BROKEN
|
2011-06-02 08:20:08 +08:00
|
|
|
select IOMMU_API
|
|
|
|
|
help
|
|
|
|
|
Support for the IOMMUs found on certain Qualcomm SOCs.
|
|
|
|
|
These IOMMUs allow virtualization of the address space used by most
|
|
|
|
|
cores within the multimedia subsystem.
|
|
|
|
|
|
|
|
|
|
If unsure, say N here.
|
|
|
|
|
|
|
|
|
|
config IOMMU_PGTABLES_L2
|
|
|
|
|
def_bool y
|
|
|
|
|
depends on MSM_IOMMU && MMU && SMP && CPU_DCACHE_DISABLE=n
|
2011-06-05 23:22:18 +08:00
|
|
|
|
|
|
|
|
# AMD IOMMU support
|
|
|
|
|
config AMD_IOMMU
|
|
|
|
|
bool "AMD IOMMU support"
|
|
|
|
|
select SWIOTLB
|
|
|
|
|
select PCI_MSI
|
2011-11-18 00:24:28 +08:00
|
|
|
select PCI_ATS
|
|
|
|
|
select PCI_PRI
|
|
|
|
|
select PCI_PASID
|
2011-06-05 23:22:18 +08:00
|
|
|
select IOMMU_API
|
x86, build, pci: Fix PCI_MSI build on !SMP
Commit ebd97be635 ('PCI: remove ARCH_SUPPORTS_MSI kconfig option')
removed the ARCH_SUPPORTS_MSI option which architectures could select
to indicate that they support MSI. Now, all architectures are supposed
to build fine when MSI support is enabled: instead of having the
architecture tell *when* MSI support can be used, it's up to the
architecture code to ensure that MSI support can be enabled.
On x86, commit ebd97be635 removed the following line:
select ARCH_SUPPORTS_MSI if (X86_LOCAL_APIC && X86_IO_APIC)
Which meant that MSI support was only available when the local APIC
and I/O APIC were enabled. While this is always true on SMP or x86-64,
it is not necessarily the case on i386 !SMP.
The below patch makes sure that the local APIC and I/O APIC support is
always enabled when MSI support is enabled. To do so, it:
* Ensures the X86_UP_APIC option is not visible when PCI_MSI is
enabled. This is the option that allows, on UP machines, to enable
or not the APIC support. It is already not visible on SMP systems,
or x86-64 systems, for example. We're simply also making it
invisible on i386 MSI systems.
* Ensures that the X86_LOCAL_APIC and X86_IO_APIC options are 'y'
when PCI_MSI is enabled.
Notice that this change requires a change in drivers/iommu/Kconfig to
avoid a recursive Kconfig dependencey. The AMD_IOMMU option selects
PCI_MSI, but was depending on X86_IO_APIC. This dependency is no
longer needed: as soon as PCI_MSI is selected, the presence of
X86_IO_APIC is guaranteed. Moreover, the AMD_IOMMU already depended on
X86_64, which already guaranteed that X86_IO_APIC was enabled, so this
dependency was anyway redundant.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: http://lkml.kernel.org/r/1380794354-9079-1-git-send-email-thomas.petazzoni@free-electrons.com
Reported-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-10-03 17:59:14 +08:00
|
|
|
depends on X86_64 && PCI && ACPI
|
2011-06-05 23:22:18 +08:00
|
|
|
---help---
|
|
|
|
|
With this option you can enable support for AMD IOMMU hardware in
|
|
|
|
|
your system. An IOMMU is a hardware component which provides
|
|
|
|
|
remapping of DMA memory accesses from devices. With an AMD IOMMU you
|
2012-04-17 23:01:21 +08:00
|
|
|
can isolate the DMA memory of different devices and protect the
|
2011-06-05 23:22:18 +08:00
|
|
|
system from misbehaving device drivers or hardware.
|
|
|
|
|
|
|
|
|
|
You can find out if your system has an AMD IOMMU if you look into
|
|
|
|
|
your BIOS for an option to enable it or if you have an IVRS ACPI
|
|
|
|
|
table.
|
|
|
|
|
|
|
|
|
|
config AMD_IOMMU_STATS
|
|
|
|
|
bool "Export AMD IOMMU statistics to debugfs"
|
|
|
|
|
depends on AMD_IOMMU
|
|
|
|
|
select DEBUG_FS
|
|
|
|
|
---help---
|
|
|
|
|
This option enables code in the AMD IOMMU driver to collect various
|
|
|
|
|
statistics about whats happening in the driver and exports that
|
|
|
|
|
information to userspace via debugfs.
|
|
|
|
|
If unsure, say N.
|
2011-06-11 02:42:27 +08:00
|
|
|
|
2011-11-09 19:31:15 +08:00
|
|
|
config AMD_IOMMU_V2
|
2013-01-17 10:53:39 +08:00
|
|
|
tristate "AMD IOMMU Version 2 driver"
|
2014-07-10 18:44:56 +08:00
|
|
|
depends on AMD_IOMMU
|
2011-11-24 23:21:52 +08:00
|
|
|
select MMU_NOTIFIER
|
2011-11-09 19:31:15 +08:00
|
|
|
---help---
|
|
|
|
|
This option enables support for the AMD IOMMUv2 features of the IOMMU
|
|
|
|
|
hardware. Select this option if you want to use devices that support
|
2012-04-17 23:01:21 +08:00
|
|
|
the PCI PRI and PASID interface.
|
2011-11-09 19:31:15 +08:00
|
|
|
|
2011-06-11 02:42:27 +08:00
|
|
|
# Intel IOMMU support
|
2011-08-24 08:05:25 +08:00
|
|
|
config DMAR_TABLE
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config INTEL_IOMMU
|
|
|
|
|
bool "Support for Intel IOMMU using DMA Remapping Devices"
|
2011-06-11 02:42:27 +08:00
|
|
|
depends on PCI_MSI && ACPI && (X86 || IA64_GENERIC)
|
|
|
|
|
select IOMMU_API
|
2015-01-13 01:51:13 +08:00
|
|
|
select IOMMU_IOVA
|
2011-08-24 08:05:25 +08:00
|
|
|
select DMAR_TABLE
|
2011-06-11 02:42:27 +08:00
|
|
|
help
|
|
|
|
|
DMA remapping (DMAR) devices support enables independent address
|
|
|
|
|
translations for Direct Memory Access (DMA) from devices.
|
|
|
|
|
These DMA remapping devices are reported via ACPI tables
|
|
|
|
|
and include PCI device scope covered by these DMA
|
|
|
|
|
remapping devices.
|
|
|
|
|
|
2011-08-24 08:05:25 +08:00
|
|
|
config INTEL_IOMMU_DEFAULT_ON
|
2011-06-11 02:42:27 +08:00
|
|
|
def_bool y
|
2011-08-24 08:05:25 +08:00
|
|
|
prompt "Enable Intel DMA Remapping Devices by default"
|
|
|
|
|
depends on INTEL_IOMMU
|
2011-06-11 02:42:27 +08:00
|
|
|
help
|
|
|
|
|
Selecting this option will enable a DMAR device at boot time if
|
|
|
|
|
one is found. If this option is not selected, DMAR support can
|
|
|
|
|
be enabled by passing intel_iommu=on to the kernel.
|
|
|
|
|
|
2011-08-24 08:05:25 +08:00
|
|
|
config INTEL_IOMMU_BROKEN_GFX_WA
|
2011-06-11 02:42:27 +08:00
|
|
|
bool "Workaround broken graphics drivers (going away soon)"
|
2011-08-24 08:05:25 +08:00
|
|
|
depends on INTEL_IOMMU && BROKEN && X86
|
2011-06-11 02:42:27 +08:00
|
|
|
---help---
|
|
|
|
|
Current Graphics drivers tend to use physical address
|
|
|
|
|
for DMA and avoid using DMA APIs. Setting this config
|
|
|
|
|
option permits the IOMMU driver to set a unity map for
|
|
|
|
|
all the OS-visible memory. Hence the driver can continue
|
|
|
|
|
to use physical addresses for DMA, at least until this
|
|
|
|
|
option is removed in the 2.6.32 kernel.
|
|
|
|
|
|
2011-08-24 08:05:25 +08:00
|
|
|
config INTEL_IOMMU_FLOPPY_WA
|
2011-06-11 02:42:27 +08:00
|
|
|
def_bool y
|
2011-08-24 08:05:25 +08:00
|
|
|
depends on INTEL_IOMMU && X86
|
2011-06-11 02:42:27 +08:00
|
|
|
---help---
|
|
|
|
|
Floppy disk drivers are known to bypass DMA API calls
|
|
|
|
|
thereby failing to work when IOMMU is enabled. This
|
|
|
|
|
workaround will setup a 1:1 mapping for the first
|
|
|
|
|
16MiB to make floppy (an ISA device) work.
|
|
|
|
|
|
2011-08-24 08:05:25 +08:00
|
|
|
config IRQ_REMAP
|
2013-01-17 10:53:39 +08:00
|
|
|
bool "Support for Interrupt Remapping"
|
|
|
|
|
depends on X86_64 && X86_IO_APIC && PCI_MSI && ACPI
|
2011-08-24 08:05:25 +08:00
|
|
|
select DMAR_TABLE
|
2011-06-11 02:42:27 +08:00
|
|
|
---help---
|
|
|
|
|
Supports Interrupt remapping for IO-APIC and MSI devices.
|
|
|
|
|
To use x2apic mode in the CPU's which support x2APIC enhancements or
|
|
|
|
|
to support platforms with CPU's having > 8 bit APIC ID, say Y.
|
2011-06-14 21:51:54 +08:00
|
|
|
|
2011-08-16 04:21:41 +08:00
|
|
|
# OMAP IOMMU support
|
|
|
|
|
config OMAP_IOMMU
|
|
|
|
|
bool "OMAP IOMMU Support"
|
2015-01-20 23:13:33 +08:00
|
|
|
depends on ARM && MMU
|
|
|
|
|
depends on ARCH_OMAP2PLUS || COMPILE_TEST
|
2011-08-16 04:21:41 +08:00
|
|
|
select IOMMU_API
|
2014-11-11 16:17:00 +08:00
|
|
|
---help---
|
|
|
|
|
The OMAP3 media platform drivers depend on iommu support,
|
|
|
|
|
if you need them say Y here.
|
2011-08-16 04:21:41 +08:00
|
|
|
|
|
|
|
|
config OMAP_IOMMU_DEBUG
|
2014-10-23 06:22:30 +08:00
|
|
|
bool "Export OMAP IOMMU internals in DebugFS"
|
|
|
|
|
depends on OMAP_IOMMU && DEBUG_FS
|
|
|
|
|
---help---
|
|
|
|
|
Select this to see extensive information about
|
|
|
|
|
the internal state of OMAP IOMMU in debugfs.
|
2011-08-16 04:21:41 +08:00
|
|
|
|
2014-10-23 06:22:30 +08:00
|
|
|
Say N unless you know you need this.
|
2011-08-16 04:21:41 +08:00
|
|
|
|
iommu/rockchip: rk3288 iommu driver
The rk3288 has several iommus. Each iommu belongs to a single master
device. There is one device (ISP) that has two slave iommus, but that
case is not yet supported by this driver.
At subsys init, the iommu driver registers itself as the iommu driver for
the platform bus. The master devices find their slave iommus using the
"iommus" field in their devicetree description. Since each slave iommu
belongs to exactly one master, their is no additional data needed at probe
to associate a slave with its master.
An iommu device's power domain, clock and irq are all shared with its
master device, and the master device must be careful to attach from the
iommu only after powering and clocking it (and leave it powered and
clocked before detaching). Because their is no guarantee what the status
of the iommu is at probe, and since the driver does not even know if the
device is powered, we delay requesting its irq until the master device
attaches, at which point we have a guarantee that the device is powered
and clocked and we can reset it and disable its interrupt mask.
An iommu_domain describes a virtual iova address space. Each iommu_domain
has a corresponding page table that lists the mappings from iova to
physical address.
For the rk3288 iommu, the page table has two levels:
The Level 1 "directory_table" has 1024 4-byte dte entries.
Each dte points to a level 2 "page_table".
Each level 2 page_table has 1024 4-byte pte entries.
Each pte points to a 4 KiB page of memory.
An iommu_domain is created when a dma_iommu_mapping is created via
arm_iommu_create_mapping. Master devices can then attach themselves to
this mapping (or attach the mapping to themselves?) by calling
arm_iommu_attach_device(). This in turn instructs the iommu driver to
write the page table's physical address into the slave iommu's "Directory
Table Entry" (DTE) register.
In fact multiple master devices, each with their own slave iommu device,
can all attach to the same mapping. The iommus for these devices will
share the same iommu_domain and therefore point to the same page table.
Thus, the iommu domain maintains a list of iommu devices which are
attached. This driver relies on the iommu core to ensure that all devices
have detached before destroying a domain.
v6: - add .add/remove_device() callbacks.
- parse platform_device device tree nodes for "iommus" property
- store platform device pointer as group iommudata
- Check for existence of iommu group instead of relying on a
dev_get_drvdata() to return NULL for a NULL device.
v7: - fixup some strings.
- In rk_iommu_disable_paging() # and % were reversed.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Simon Xue <xxm@rock-chips.com>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2014-11-03 10:53:27 +08:00
|
|
|
config ROCKCHIP_IOMMU
|
|
|
|
|
bool "Rockchip IOMMU Support"
|
2014-11-04 01:16:56 +08:00
|
|
|
depends on ARM
|
|
|
|
|
depends on ARCH_ROCKCHIP || COMPILE_TEST
|
iommu/rockchip: rk3288 iommu driver
The rk3288 has several iommus. Each iommu belongs to a single master
device. There is one device (ISP) that has two slave iommus, but that
case is not yet supported by this driver.
At subsys init, the iommu driver registers itself as the iommu driver for
the platform bus. The master devices find their slave iommus using the
"iommus" field in their devicetree description. Since each slave iommu
belongs to exactly one master, their is no additional data needed at probe
to associate a slave with its master.
An iommu device's power domain, clock and irq are all shared with its
master device, and the master device must be careful to attach from the
iommu only after powering and clocking it (and leave it powered and
clocked before detaching). Because their is no guarantee what the status
of the iommu is at probe, and since the driver does not even know if the
device is powered, we delay requesting its irq until the master device
attaches, at which point we have a guarantee that the device is powered
and clocked and we can reset it and disable its interrupt mask.
An iommu_domain describes a virtual iova address space. Each iommu_domain
has a corresponding page table that lists the mappings from iova to
physical address.
For the rk3288 iommu, the page table has two levels:
The Level 1 "directory_table" has 1024 4-byte dte entries.
Each dte points to a level 2 "page_table".
Each level 2 page_table has 1024 4-byte pte entries.
Each pte points to a 4 KiB page of memory.
An iommu_domain is created when a dma_iommu_mapping is created via
arm_iommu_create_mapping. Master devices can then attach themselves to
this mapping (or attach the mapping to themselves?) by calling
arm_iommu_attach_device(). This in turn instructs the iommu driver to
write the page table's physical address into the slave iommu's "Directory
Table Entry" (DTE) register.
In fact multiple master devices, each with their own slave iommu device,
can all attach to the same mapping. The iommus for these devices will
share the same iommu_domain and therefore point to the same page table.
Thus, the iommu domain maintains a list of iommu devices which are
attached. This driver relies on the iommu core to ensure that all devices
have detached before destroying a domain.
v6: - add .add/remove_device() callbacks.
- parse platform_device device tree nodes for "iommus" property
- store platform device pointer as group iommudata
- Check for existence of iommu group instead of relying on a
dev_get_drvdata() to return NULL for a NULL device.
v7: - fixup some strings.
- In rk_iommu_disable_paging() # and % were reversed.
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Signed-off-by: Simon Xue <xxm@rock-chips.com>
Reviewed-by: Grant Grundler <grundler@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2014-11-03 10:53:27 +08:00
|
|
|
select IOMMU_API
|
|
|
|
|
select ARM_DMA_USE_IOMMU
|
|
|
|
|
help
|
|
|
|
|
Support for IOMMUs found on Rockchip rk32xx SOCs.
|
|
|
|
|
These IOMMUs allow virtualization of the address space used by most
|
|
|
|
|
cores within the multimedia subsystem.
|
|
|
|
|
Say Y here if you are using a Rockchip SoC that includes an IOMMU
|
|
|
|
|
device.
|
2011-08-16 04:21:41 +08:00
|
|
|
|
2011-11-16 23:36:37 +08:00
|
|
|
config TEGRA_IOMMU_GART
|
|
|
|
|
bool "Tegra GART IOMMU Support"
|
|
|
|
|
depends on ARCH_TEGRA_2x_SOC
|
|
|
|
|
select IOMMU_API
|
|
|
|
|
help
|
|
|
|
|
Enables support for remapping discontiguous physical memory
|
|
|
|
|
shared with the operating system into contiguous I/O virtual
|
|
|
|
|
space through the GART (Graphics Address Relocation Table)
|
|
|
|
|
hardware included on Tegra SoCs.
|
|
|
|
|
|
2011-11-17 13:31:31 +08:00
|
|
|
config TEGRA_IOMMU_SMMU
|
2014-04-16 15:24:44 +08:00
|
|
|
bool "NVIDIA Tegra SMMU Support"
|
|
|
|
|
depends on ARCH_TEGRA
|
|
|
|
|
depends on TEGRA_AHB
|
|
|
|
|
depends on TEGRA_MC
|
2011-11-17 13:31:31 +08:00
|
|
|
select IOMMU_API
|
|
|
|
|
help
|
2014-04-16 15:24:44 +08:00
|
|
|
This driver supports the IOMMU hardware (SMMU) found on NVIDIA Tegra
|
2015-03-23 17:45:12 +08:00
|
|
|
SoCs (Tegra30 up to Tegra210).
|
2011-11-17 13:31:31 +08:00
|
|
|
|
2012-05-12 04:56:09 +08:00
|
|
|
config EXYNOS_IOMMU
|
|
|
|
|
bool "Exynos IOMMU Support"
|
2015-01-28 22:45:53 +08:00
|
|
|
depends on ARCH_EXYNOS && ARM && MMU
|
2012-05-12 04:56:09 +08:00
|
|
|
select IOMMU_API
|
2014-07-04 17:31:08 +08:00
|
|
|
select ARM_DMA_USE_IOMMU
|
2012-05-12 04:56:09 +08:00
|
|
|
help
|
2014-05-22 12:20:55 +08:00
|
|
|
Support for the IOMMU (System MMU) of Samsung Exynos application
|
|
|
|
|
processor family. This enables H/W multimedia accelerators to see
|
|
|
|
|
non-linear physical memory chunks as linear memory in their
|
|
|
|
|
address space.
|
2012-05-12 04:56:09 +08:00
|
|
|
|
|
|
|
|
If unsure, say N here.
|
|
|
|
|
|
|
|
|
|
config EXYNOS_IOMMU_DEBUG
|
|
|
|
|
bool "Debugging log for Exynos IOMMU"
|
|
|
|
|
depends on EXYNOS_IOMMU
|
|
|
|
|
help
|
|
|
|
|
Select this to see the detailed log message that shows what
|
2014-05-22 12:20:55 +08:00
|
|
|
happens in the IOMMU driver.
|
2012-05-12 04:56:09 +08:00
|
|
|
|
2014-05-22 12:20:55 +08:00
|
|
|
Say N unless you need kernel log message for IOMMU debugging.
|
2012-05-12 04:56:09 +08:00
|
|
|
|
2013-01-21 18:54:26 +08:00
|
|
|
config SHMOBILE_IPMMU
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config SHMOBILE_IPMMU_TLB
|
|
|
|
|
bool
|
|
|
|
|
|
|
|
|
|
config SHMOBILE_IOMMU
|
|
|
|
|
bool "IOMMU for Renesas IPMMU/IPMMUI"
|
|
|
|
|
default n
|
2015-01-28 22:45:53 +08:00
|
|
|
depends on ARM && MMU
|
2014-02-09 05:21:54 +08:00
|
|
|
depends on ARCH_SHMOBILE || COMPILE_TEST
|
2013-01-21 18:54:26 +08:00
|
|
|
select IOMMU_API
|
|
|
|
|
select ARM_DMA_USE_IOMMU
|
|
|
|
|
select SHMOBILE_IPMMU
|
|
|
|
|
select SHMOBILE_IPMMU_TLB
|
|
|
|
|
help
|
|
|
|
|
Support for Renesas IPMMU/IPMMUI. This option enables
|
|
|
|
|
remapping of DMA memory accesses from all of the IP blocks
|
|
|
|
|
on the ICB.
|
|
|
|
|
|
|
|
|
|
Warning: Drivers (including userspace drivers of UIO
|
|
|
|
|
devices) of the IP blocks on the ICB *must* use addresses
|
|
|
|
|
allocated from the IPMMU (iova) for DMA with this option
|
|
|
|
|
enabled.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
choice
|
|
|
|
|
prompt "IPMMU/IPMMUI address space size"
|
|
|
|
|
default SHMOBILE_IOMMU_ADDRSIZE_2048MB
|
|
|
|
|
depends on SHMOBILE_IOMMU
|
|
|
|
|
help
|
|
|
|
|
This option sets IPMMU/IPMMUI address space size by
|
|
|
|
|
adjusting the 1st level page table size. The page table size
|
|
|
|
|
is calculated as follows:
|
|
|
|
|
|
|
|
|
|
page table size = number of page table entries * 4 bytes
|
|
|
|
|
number of page table entries = address space size / 1 MiB
|
|
|
|
|
|
|
|
|
|
For example, when the address space size is 2048 MiB, the
|
|
|
|
|
1st level page table size is 8192 bytes.
|
|
|
|
|
|
|
|
|
|
config SHMOBILE_IOMMU_ADDRSIZE_2048MB
|
|
|
|
|
bool "2 GiB"
|
|
|
|
|
|
|
|
|
|
config SHMOBILE_IOMMU_ADDRSIZE_1024MB
|
|
|
|
|
bool "1 GiB"
|
|
|
|
|
|
|
|
|
|
config SHMOBILE_IOMMU_ADDRSIZE_512MB
|
|
|
|
|
bool "512 MiB"
|
|
|
|
|
|
|
|
|
|
config SHMOBILE_IOMMU_ADDRSIZE_256MB
|
|
|
|
|
bool "256 MiB"
|
|
|
|
|
|
|
|
|
|
config SHMOBILE_IOMMU_ADDRSIZE_128MB
|
|
|
|
|
bool "128 MiB"
|
|
|
|
|
|
|
|
|
|
config SHMOBILE_IOMMU_ADDRSIZE_64MB
|
|
|
|
|
bool "64 MiB"
|
|
|
|
|
|
|
|
|
|
config SHMOBILE_IOMMU_ADDRSIZE_32MB
|
|
|
|
|
bool "32 MiB"
|
|
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
|
|
config SHMOBILE_IOMMU_L1SIZE
|
|
|
|
|
int
|
|
|
|
|
default 8192 if SHMOBILE_IOMMU_ADDRSIZE_2048MB
|
|
|
|
|
default 4096 if SHMOBILE_IOMMU_ADDRSIZE_1024MB
|
|
|
|
|
default 2048 if SHMOBILE_IOMMU_ADDRSIZE_512MB
|
|
|
|
|
default 1024 if SHMOBILE_IOMMU_ADDRSIZE_256MB
|
|
|
|
|
default 512 if SHMOBILE_IOMMU_ADDRSIZE_128MB
|
|
|
|
|
default 256 if SHMOBILE_IOMMU_ADDRSIZE_64MB
|
|
|
|
|
default 128 if SHMOBILE_IOMMU_ADDRSIZE_32MB
|
|
|
|
|
|
2014-04-02 18:47:37 +08:00
|
|
|
config IPMMU_VMSA
|
|
|
|
|
bool "Renesas VMSA-compatible IPMMU"
|
|
|
|
|
depends on ARM_LPAE
|
|
|
|
|
depends on ARCH_SHMOBILE || COMPILE_TEST
|
|
|
|
|
select IOMMU_API
|
2015-01-21 00:30:04 +08:00
|
|
|
select IOMMU_IO_PGTABLE_LPAE
|
2014-04-02 18:47:37 +08:00
|
|
|
select ARM_DMA_USE_IOMMU
|
|
|
|
|
help
|
|
|
|
|
Support for the Renesas VMSA-compatible IPMMU Renesas found in the
|
|
|
|
|
R-Mobile APE6 and R-Car H2/M2 SoCs.
|
|
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
2013-05-21 11:33:09 +08:00
|
|
|
config SPAPR_TCE_IOMMU
|
|
|
|
|
bool "sPAPR TCE IOMMU Support"
|
2013-05-21 11:33:11 +08:00
|
|
|
depends on PPC_POWERNV || PPC_PSERIES
|
2013-05-21 11:33:09 +08:00
|
|
|
select IOMMU_API
|
|
|
|
|
help
|
|
|
|
|
Enables bits of IOMMU API required by VFIO. The iommu_ops
|
|
|
|
|
is not implemented as it is not necessary for VFIO.
|
|
|
|
|
|
2015-05-28 00:25:59 +08:00
|
|
|
# ARM IOMMU support
|
2013-06-25 01:31:25 +08:00
|
|
|
config ARM_SMMU
|
|
|
|
|
bool "ARM Ltd. System MMU (SMMU) Support"
|
2015-02-04 23:53:44 +08:00
|
|
|
depends on (ARM64 || ARM) && MMU
|
2013-06-25 01:31:25 +08:00
|
|
|
select IOMMU_API
|
2014-11-15 01:17:54 +08:00
|
|
|
select IOMMU_IO_PGTABLE_LPAE
|
2013-06-25 01:31:25 +08:00
|
|
|
select ARM_DMA_USE_IOMMU if ARM
|
|
|
|
|
help
|
|
|
|
|
Support for implementations of the ARM System MMU architecture
|
2014-11-15 01:17:54 +08:00
|
|
|
versions 1 and 2.
|
2013-06-25 01:31:25 +08:00
|
|
|
|
|
|
|
|
Say Y here if your SoC includes an IOMMU device implementing
|
|
|
|
|
the ARM SMMU architecture.
|
|
|
|
|
|
2015-05-28 00:25:59 +08:00
|
|
|
config ARM_SMMU_V3
|
|
|
|
|
bool "ARM Ltd. System MMU Version 3 (SMMUv3) Support"
|
|
|
|
|
depends on ARM64 && PCI
|
|
|
|
|
select IOMMU_API
|
|
|
|
|
select IOMMU_IO_PGTABLE_LPAE
|
|
|
|
|
help
|
|
|
|
|
Support for implementations of the ARM System MMU architecture
|
|
|
|
|
version 3 providing translation support to a PCIe root complex.
|
|
|
|
|
|
|
|
|
|
Say Y here if your system includes an IOMMU device implementing
|
|
|
|
|
the ARM SMMUv3 architecture.
|
|
|
|
|
|
2011-06-14 21:51:54 +08:00
|
|
|
endif # IOMMU_SUPPORT
|