they contain two new IOMMU drivers for the ARM Tegra 2 and 3 platforms.
Besides that there are also a few patches for the AMD IOMMU which
prepare the driver for adding intr-remapping support and a couple of
fixes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPa3RMAAoJECvwRC2XARrjgwUQAKYXxRmbiIT2FxWxoIx75Q6N
vO+Z3kaERBpY1dx2VD5shenIs6P6hr5DxnxbcMhD4wBNXVSRToj2BskLhBz79syi
ecBCCPPELKypJvNpK55YM9gLnSwT8tbnPrCCMUqLQJQ1sptYMAfbwdRvNAOHF4Kp
eU9JoJjq37WreX0hgHNqDcEBsBo18NwI+1jkayleTxeWf2gJiCWTs7VwKsa3Xcni
OkFvNHy1krjqFlcT21p/eEf5dCTHXsxzU4+ilr4S8pg99KMsZuHFc6tFUkby3OC6
jqbgNqxve2y5KvqAvyqxWkcUbejbN3B6AukiYj70Duy/6OPZ39F6O+vPAoYsxbR1
0kT3evwbTBRYH/xcV4oJjPgdH7+hzAoe4ZNm3ROditXxdFU7vb8rlArTyVup8zrF
LiVbLHll9v6vaxk8Ff8ZY9nJSOiNXWBGwsusj33PTE3RkVucpOlPQIX5yAcBYBDO
JI6Qf7gm7GXdOKA23HxXwQKr8kw+EsDAEqslAMFTd9o0dFejikMXoDk2GYVO5qOK
b0kGcGwDCcd1QaFDT+GimT2IueoM+YNUtwLpbXLm3syWfKNuqC8uJ32V0gHt4k9X
1FU0qKSifKiJlDYT+JjHuRdRlZhfreIK7rHLVDyulKOHp1O5DAGeFHigRpEq8i9O
xQvz5vq1vyO5nO8P6gDl
=lCBm
-----END PGP SIGNATURE-----
Merge tag 'iommu-updates-v3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu
Pull IOMMU updates from Joerg Roedel:
"The IOMMU updates for this round are not very large patch-wise. But
they contain two new IOMMU drivers for the ARM Tegra 2 and 3
platforms. Besides that there are also a few patches for the AMD
IOMMU which prepare the driver for adding intr-remapping support and a
couple of fixes."
* tag 'iommu-updates-v3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
iommu/amd: Fix section mismatch
iommu/amd: Move interrupt setup code into seperate function
iommu/amd: Make sure IOMMU interrupts are re-enabled on resume
iommu/amd: Fix section warning for prealloc_protection_domains
iommu/amd: Don't initialize IOMMUv2 resources when not required
iommu/amd: Update git-tree in MAINTAINERS
iommu/tegra-gart: fix spin_unlock in map failure path
iommu/amd: Fix double free of mem-region in error-path
iommu/amd: Split amd_iommu_init function
ARM: IOMMU: Tegra30: Add iommu_ops for SMMU driver
ARM: IOMMU: Tegra20: Add iommu_ops for GART driver
Pull trivial tree from Jiri Kosina:
"It's indeed trivial -- mostly documentation updates and a bunch of
typo fixes from Masanari.
There are also several linux/version.h include removals from Jesper."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: (101 commits)
kcore: fix spelling in read_kcore() comment
constify struct pci_dev * in obvious cases
Revert "char: Fix typo in viotape.c"
init: fix wording error in mm_init comment
usb: gadget: Kconfig: fix typo for 'different'
Revert "power, max8998: Include linux/module.h just once in drivers/power/max8998_charger.c"
writeback: fix fn name in writeback_inodes_sb_nr_if_idle() comment header
writeback: fix typo in the writeback_control comment
Documentation: Fix multiple typo in Documentation
tpm_tis: fix tis_lock with respect to RCU
Revert "media: Fix typo in mixer_drv.c and hdmi_drv.c"
Doc: Update numastat.txt
qla4xxx: Add missing spaces to error messages
compiler.h: Fix typo
security: struct security_operations kerneldoc fix
Documentation: broken URL in libata.tmpl
Documentation: broken URL in filesystems.tmpl
mtd: simplify return logic in do_map_probe()
mm: fix comment typo of truncate_inode_pages_range
power: bq27x00: Fix typos in comment
...
Pull core/iommu changes for v3.4 from Ingo Molnar
* 'core-iommu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/iommu/intel: Increase the number of iommus supported to MAX_IO_APICS
x86/iommu/intel: Fix identity mapping for sandy bridge
Fix the following section warnings :
WARNING: vmlinux.o(.text+0x49dbc): Section mismatch in reference
from the function acpi_map_cpu2node() to the variable
.cpuinit.data:__apicid_to_node The function acpi_map_cpu2node()
references the variable __cpuinitdata __apicid_to_node. This is
often because acpi_map_cpu2node lacks a __cpuinitdata
annotation or the annotation of __apicid_to_node is wrong.
WARNING: vmlinux.o(.text+0x49dc1): Section mismatch in reference
from the function acpi_map_cpu2node() to the function
.cpuinit.text:numa_set_node() The function acpi_map_cpu2node()
references the function __cpuinit numa_set_node(). This is often
because acpi_map_cpu2node lacks a __cpuinit annotation or the
annotation of numa_set_node is wrong.
WARNING: vmlinux.o(.text+0x526e77): Section mismatch in
reference from the function prealloc_protection_domains() to the
function .init.text:alloc_passthrough_domain() The function
prealloc_protection_domains() references the function __init
alloc_passthrough_domain(). This is often because
prealloc_protection_domains lacks a __init annotation or the annotation of alloc_passthrough_domain is wrong.
Signed-off-by: Steffen Persvold <sp@numascale.com>
Link: http://lkml.kernel.org/r/1331810188-24785-1-git-send-email-sp@numascale.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
For interrupt remapping the enablement of the IOMMU MSI
interrupt needs to be deferred because the IOMMU itself will
be initialized before the io-apics are up and running. So
the code to setup the MSI is moved seperated from the
hardware-setup routine now.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Unfortunatly the interrupts for the event log and the
peripheral page-faults are only enabled at boot but not
re-enabled at resume. Fix that.
Cc: stable@vger.kernel.org
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Fix the following section warning in drivers/iommu/amd_iommu.c :
WARNING: vmlinux.o(.text+0x526e77): Section mismatch in reference from the function prealloc_protection_domains() to the function .init.text:alloc_passthrough_domain()
The function prealloc_protection_domains() references
the function __init alloc_passthrough_domain().
This is often because prealloc_protection_domains lacks a __init
annotation or the annotation of alloc_passthrough_domain is wrong.
Cc: stable@vger.kernel.org
Signed-off-by: Steffen Persvold <sp@numascale.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Add a check to the init-path of the AMD IOMMUv2 driver if
the hardware is available in the system. Only allocate all
the resources if it is really available.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
This must have been messed up while merging, the intention was
clearly to unlock there.
Signed-off-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
When ioremap_nocache fails in iommu initialization the code
calls release_mem_region immediatly. But the function is
called again when the propagates into the upper init
functions leading to a double-free. Fix that.
Reported-by: Don Dutile <ddutile@redhat.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
This function is called from enable_iommus(), which in turn is used
from amd_iommu_resume().
Cc: stable@vger.kernel.org
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
The number of IOMMUs supported should be the same as the number
of IO APICS. This limit comes into play when the IOMMUs are
identity mapped, thus the number of possible IOMMUs in the
"static identity" (si) domain should be this same number.
Signed-off-by: Mike Travis <travis@sgi.com>
Signed-off-by: Jack Steiner <steiner@sgi.com>
Cc: Jack Steiner <steiner@sgi.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Chris Wright <chrisw@sous-sol.org>
Cc: Daniel Rahn <drahn@suse.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Joerg Roedel <joerg.roedel@amd.com>
[ Fixed printk format string, cleaned up the code ]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/n/tip-ixcmp0hfp0a3b2lfv3uo0p0x@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
With SandyBridge, Intel has changed these Socket PCI devices to
have a class type of "System Peripheral" & "Performance
counter", rather than "HostBridge".
So instead of using a "special" case to detect which devices will
not be doing DMA, use the fact that a device that is not associated
with an IOMMU, will not need an identity map.
Signed-off-by: Mike Travis <travis@sgi.com>
Signed-off-by: Mike Habeck <habeck@sgi.com>
Cc: Jack Steiner <steiner@sgi.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Chris Wright <chrisw@sous-sol.org>
Cc: Daniel Rahn <drahn@suse.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Link: http://lkml.kernel.org/n/tip-018fywmjs3lmzfyzjlktg8dx@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@elte.hu>
The hardware-initializtion part of the AMD IOMMU driver is
split out into a seperate function. This function can now be
called either from amd_iommu_init() itself or any other
place if the hardware needs to be ready earlier. This will
be used to implement interrupt remapping for AMD.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
omap3isp depends on omap's iommu and will fail to probe if
initialized before it (which always happen if they are builtin).
Make omap's iommu subsys_initcall as an interim solution until
the probe deferral mechanism is merged.
Reported-by: James <angweiyang@gmail.com>
Debugged-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: stable <stable@vger.kernel.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Hiroshi Doyu <hdoyu@nvidia.com>
Cc: Joerg Roedel <Joerg.Roedel@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Adapt omap-iommu-debug to the latest omap-iommu API changes, which
were introduced by commit fabdbca "iommu/omap: eliminate the public
omap_find_iommu_device() method".
In a nutshell, iommu users are not expected to provide the omap_iommu
handle anymore - instead, iommus are attached using their user's device
handle.
omap-iommu-debug is a hybrid beast though: it invokes both public and
private omap iommu API, so fix it as necessary (otherwise a crash
is imminent).
Note: omap-iommu-debug is a bit disturbing, as it fiddles with internal
omap iommu data and requires exposing API which is otherwise not needed.
It should better be more tightly coupled with omap-iommu, to prevent
further bit rot and avoid exposing redundant API. Naturally that's out
of scope for the -rc cycle, so for now just fix the obvious.
Reported-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Hiroshi Doyu <hdoyu@nvidia.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Joerg Roedel <Joerg.Roedel@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Error handling in msm_iommu_unmap() is broken. On some error
conditions retval is set to a non-zero value which causes
the function to return 'len' at the end. This hides the
error from the user. Zero should be returned in those error
cases.
Cc: David Brown <davidb@codeaurora.org>
Cc: Stepan Moskovchenko <stepanm@codeaurora.org>
Cc: stable@vger.kernel.org # >= 3.1
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Acked-by: David Brown <davidb@codeaurora.org>
Tegra 20 IOMMU H/W, GART (Graphics Address Relocation Table). This
patch implements struct iommu_ops for GART for the upper IOMMU API.
This H/W module supports only single virtual address space(domain),
and manages a single level 1-to-1 mapping H/W translation page table.
[With small fixes by Joerg Roedel]
Signed-off-by: Hiroshi DOYU <hdoyu@nvidia.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
On some systems the IVRS table does not contain all PCI
devices present in the system. In case a device not present
in the IVRS table is translated by the IOMMU no DMA is
possible from that device by default.
This patch fixes this by removing the DTE entry for every
PCI device present in the system and not covered by IVRS.
Cc: stable@vger.kernel.org # >= 3.0
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
* 'core-memblock-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (52 commits)
memblock: Reimplement memblock allocation using reverse free area iterator
memblock: Kill early_node_map[]
score: Use HAVE_MEMBLOCK_NODE_MAP
s390: Use HAVE_MEMBLOCK_NODE_MAP
mips: Use HAVE_MEMBLOCK_NODE_MAP
ia64: Use HAVE_MEMBLOCK_NODE_MAP
SuperH: Use HAVE_MEMBLOCK_NODE_MAP
sparc: Use HAVE_MEMBLOCK_NODE_MAP
powerpc: Use HAVE_MEMBLOCK_NODE_MAP
memblock: Implement memblock_add_node()
memblock: s/memblock_analyze()/memblock_allow_resize()/ and update users
memblock: Track total size of regions automatically
powerpc: Cleanup memblock usage
memblock: Reimplement memblock_enforce_memory_limit() using __memblock_remove()
memblock: Make memblock functions handle overflowing range @size
memblock: Reimplement __memblock_remove() using memblock_isolate_range()
memblock: Separate out memblock_isolate_range() from memblock_set_node()
memblock: Kill memblock_init()
memblock: Kill sentinel entries at the end of static region arrays
memblock: Add __memblock_dump_all()
...
To protect the command buffer from hanging when a device
does not respond to an IOTLB invalidation, set a timeout of
1s for outstanding IOTLB invalidations.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
The IOMMUv2 driver added a few statistic counter which are
interesting in the iommu=pt mode too. So initialize the
statistic counter for that mode too.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
* 'drm-intel-fixes' of git://people.freedesktop.org/~keithp/linux:
drm/i915/dp: Dither down to 6bpc if it makes the mode fit
drm/i915: enable semaphores on per-device defaults
drm/i915: don't set unpin_work if vblank_get fails
drm/i915: By default, enable RC6 on IVB and SNB when reasonable
iommu: Export intel_iommu_enabled to signal when iommu is in use
drm/i915/sdvo: Include LVDS panels for the IS_DIGITAL check
drm/i915: prevent division by zero when asking for chipset power
drm/i915: add PCH info to i915_capabilities
drm/i915: set the right SDVO transcoder for CPT
drm/i915: no-lvds quirk for ASUS AT5NM10T-I
drm/i915: Treat pre-gen4 backlight duty cycle value consistently
drm/i915: Hook up Ivybridge eDP
drm/i915: add multi-threaded forcewake support
In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar
is enabled. The new 'intel_iommu_enabled' variable signals when the
iommu code is in operation.
Cc: Ted Phelps <phelps@gnusto.com>
Cc: Peter <pab1612@gmail.com>
Cc: Lukas Hejtmanek <xhejtman@fi.muni.cz>
Cc: Andrew Lutomirski <luto@mit.edu>
CC: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Since it is not guaranteed that an iommu driver initializes in its
domain_init() function, it must be initialized with NULL to prevent
calling a function in an arbitrary location when iommu fault occurred.
Signed-off-by: KyongHo Cho <pullip.cho@samsung.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
This call-back is invoked when the task that is bound to a
pasid is about to exit. The driver can use it to shutdown
all context related to that context in a safe way.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
This function can be used to find out which features
necessary for IOMMUv2 usage are available on a given device.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
The symbolic register names for PCI and PASID changed in
PCI code. This patch adapts the AMD IOMMU driver to these
changes.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Since pages are not pinned anymore we need notifications
when the VMM changes the page-tables. Use mmu_notifiers for
that.
Also use the task_exit notifier from the profiling subsystem
to shutdown all contexts related to this task.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
This patch adds the amd_iommu_init_device() and
amd_iommu_free_device() functions which make a device and
the IOMMU ready for IOMMUv2 usage.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Add a Kconfig option for the optional driver. Since it is
optional it can be compiled as a module and will only be
loaded when required by another driver.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
The AMD IOMMUv2 driver needs to get the IOMMUv2 domain
associated with a particular device. This patch adds a
function to get this information.
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>