Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 19 1月, 2015 3 次提交
  3. 17 12月, 2014 1 次提交
    • M
      iommu/exynos: Fix arm64 allmodconfig build · 20911ce6
      由 Mark Brown 提交于 
      The Exynos IOMMU driver uses the ARM specific dmac_flush_range() and
outer_flush_range() functions. This breaks the build on arm64 allmodconfig
in -next since support has been merged for some Exynos ARMv8 SoCs. Add a
dependency on ARM to keep things building until either the driver has the
ARM dependencies removed or the ARMv8 architecture code implements these
ARM specific APIs.
Signed-off-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      20911ce6
  5. 04 12月, 2014 1 次提交
    • T
      memory: Add NVIDIA Tegra memory controller support · 89184651
      由 Thierry Reding 提交于 
      The memory controller on NVIDIA Tegra exposes various knobs that can be
used to tune the behaviour of the clients attached to it.

Currently this driver sets up the latency allowance registers to the HW
defaults. Eventually an API should be exported by this driver (via a
custom API or a generic subsystem) to allow clients to register latency
requirements.

This driver also registers an IOMMU (SMMU) that's implemented by the
memory controller. It is supported on Tegra30, Tegra114 and Tegra124
currently. Tegra20 has a GART instead.

The Tegra SMMU operates on memory clients and SWGROUPs. A memory client
is a unidirectional, special-purpose DMA master. A SWGROUP represents a
set of memory clients that form a logical functional unit corresponding
to a single device. Typically a device has two clients: one client for
read transactions and one client for write transactions, but there are
also devices that have only read clients, but many of them (such as the
display controllers).

Because there is no 1:1 relationship between memory clients and devices
the driver keeps a table of memory clients and the SWGROUPs that they
belong to per SoC. Note that this is an exception and due to the fact
that the SMMU is tightly integrated with the rest of the Tegra SoC. The
use of these tables is discouraged in drivers for generic IOMMU devices
such as the ARM SMMU because the same IOMMU could be used in any number
of SoCs and keeping such tables for each SoC would not scale.
Acked-by: NJoerg Roedel <jroedel@suse.de>
Signed-off-by: NThierry Reding <treding@nvidia.com>
      89184651
  7. 02 12月, 2014 1 次提交
  9. 05 11月, 2014 1 次提交
  11. 04 11月, 2014 1 次提交
    • D
      iommu/rockchip: rk3288 iommu driver · c68a2921
      由 Daniel Kurtz 提交于 
      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: NDaniel Kurtz <djkurtz@chromium.org>
Signed-off-by: NSimon Xue <xxm@rock-chips.com>
Reviewed-by: NGrant Grundler <grundler@chromium.org>
Reviewed-by: NStéphane Marchesin <marcheu@chromium.org>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      c68a2921
  13. 23 10月, 2014 1 次提交
    • S
      iommu/omap: Integrate omap-iommu-debug into omap-iommu · 61c75352
      由 Suman Anna 提交于 
      The debugfs support for OMAP IOMMU is currently implemented
as a module, warranting certain OMAP-specific IOMMU API to
be exported. The OMAP IOMMU, when enabled, can only be built-in
into the kernel, so integrate the OMAP IOMMU debug module
into the OMAP IOMMU driver. This helps in eliminating the
need to export most of the current OMAP IOMMU API.

The following are the main changes:
- The debugfs directory and entry creation logic is reversed,
  the calls are invoked by the OMAP IOMMU driver now.
- The current iffy circular logic of adding IOMMU archdata
  to the IOMMU devices itself to get a pointer to the omap_iommu
  object in the debugfs support code is replaced by directly
  using the omap_iommu structure while creating the debugfs
  entries.
- The debugfs root directory is renamed from the generic name
  "iommu" to a specific name "omap_iommu".
- Unneeded headers have also been cleaned up while at this.
- There will no longer be a omap-iommu-debug.ko module after
  this patch.
- The OMAP_IOMMU_DEBUG Kconfig option is converted to boolean
  only, the OMAP IOMMU debugfs support is built alongside the
  OMAP IOMMU driver only when this option is enabled.
Signed-off-by: NSuman Anna <s-anna@ti.com>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      61c75352
  15. 29 7月, 2014 2 次提交
  17. 10 7月, 2014 1 次提交
  19. 26 5月, 2014 3 次提交
  21. 04 3月, 2014 1 次提交
  23. 07 1月, 2014 1 次提交
  25. 16 11月, 2013 1 次提交
    • L
      Don't try to compile shmobile-iommu outside of ARM · f63c4824
      由 Linus Torvalds 提交于 
      Commit 7d02c4d6 ("iommu/shmobile: Enable the driver on all ARM
platforms") completely brokenly enabled the shmobile-iommu driver under
COMPILE_TEST.

It's bogus, because it won't compile anywhere else than ARM, since it
tries to include <asm/dma-iommu.h>, which is very much ARM-only.

So remove the bogus COMPILE_TEST dependency, which just causes
allmodconfig to fail on non-ARM platforms.

Cc: Joerg Roedel <joro@8bytes.org>
Cc: iommu@lists.linux-foundation.org
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Simon Horman <horms@verge.net.au>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f63c4824
  27. 01 11月, 2013 1 次提交
  29. 05 10月, 2013 1 次提交
    • T
      x86, build, pci: Fix PCI_MSI build on !SMP · 0dbc6078
      由 Thomas Petazzoni 提交于 
      Commit ebd97be6 ('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 ebd97be6 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: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: http://lkml.kernel.org/r/1380794354-9079-1-git-send-email-thomas.petazzoni@free-electrons.comReported-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      0dbc6078
  31. 14 8月, 2013 1 次提交
    • V
      iommu/fsl: Freescale PAMU driver and iommu implementation. · 695093e3
      由 Varun Sethi 提交于 
      Following is a brief description of the PAMU hardware:
PAMU determines what action to take and whether to authorize the action on
the basis of the memory address, a Logical IO Device Number (LIODN), and
PAACT table (logically) indexed by LIODN and address. Hardware devices which
need to access memory must provide an LIODN in addition to the memory address.

Peripheral Access Authorization and Control Tables (PAACTs) are the primary
data structures used by PAMU. A PAACT is a table of peripheral access
authorization and control entries (PAACE).Each PAACE defines the range of
I/O bus address space that is accessible by the LIOD and the associated access
capabilities.

There are two types of PAACTs: primary PAACT (PPAACT) and secondary PAACT
(SPAACT).A given physical I/O device may be able to act as one or more
independent logical I/O devices (LIODs). Each such logical I/O device is
assigned an identifier called logical I/O device number (LIODN). A LIODN is
allocated a contiguous portion of the I/O bus address space called the DSA window
for performing DSA operations. The DSA window may optionally be divided into
multiple sub-windows, each of which may be used to map to a region in system
storage space. The first sub-window is referred to as the primary sub-window
and the remaining are called secondary sub-windows.

This patch provides the PAMU driver (fsl_pamu.c) and the corresponding IOMMU
API implementation (fsl_pamu_domain.c). The PAMU hardware driver (fsl_pamu.c)
has been derived from the work done by Ashish Kalra and Timur Tabi.

[For iommu group support]
Acked-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NTimur Tabi <timur@tabi.org>
Signed-off-by: NVarun Sethi <Varun.Sethi@freescale.com>
Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      695093e3
  33. 26 6月, 2013 1 次提交
  35. 20 6月, 2013 2 次提交
  37. 10 3月, 2013 1 次提交
  39. 06 2月, 2013 1 次提交
    • H
      iommu/shmobile: Add iommu driver for Renesas IPMMU modules · c2c460f7
      由 Hideki EIRAKU 提交于 
      This is the Renesas IPMMU driver and IOMMU API implementation.

The IPMMU module supports the MMU function and the PMB function.  The
MMU function provides address translation by pagetable compatible with
ARMv6.  The PMB function provides address translation including
tile-linear translation.  This patch implements the MMU function.

The iommu driver does not register a platform driver directly because:
- the register space of the MMU function and the PMB function
  have a common register (used for settings flush), so they should ideally
  have a way to appropriately share this register.
- the MMU function uses the IOMMU API while the PMB function does not.
- the two functions may be used independently.
Signed-off-by: NHideki EIRAKU <hdk@igel.co.jp>
Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      c2c460f7
  41. 05 2月, 2013 1 次提交
  43. 22 1月, 2013 1 次提交
  45. 28 9月, 2012 1 次提交
  47. 25 6月, 2012 2 次提交
  49. 12 5月, 2012 1 次提交
  51. 18 4月, 2012 1 次提交
  53. 26 1月, 2012 2 次提交
  55. 14 12月, 2011 1 次提交
  57. 12 12月, 2011 2 次提交
  59. 21 9月, 2011 1 次提交
  61. 14 9月, 2011 1 次提交
    • J
      iommu/omap: Fix build error with !IOMMU_SUPPORT · 7b6d45f1
      由 Joerg Roedel 提交于 
      Without this patch it is possible to select the VIDEO_OMAP3
driver which then selects OMAP_IOVMM. But the omap iommu
driver is not compiled without IOMMU_SUPPORT enabled. Fix
that by forcing OMAP_IOMMU and OMAP_IOVMM are enabled before
VIDEO_OMAP3 can be selected.

Cc: Ohad Ben-Cohen <ohad@wizery.com>
Cc: iommu@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com>
      7b6d45f1