1. 04 3月, 2014 1 次提交
  2. 07 1月, 2014 1 次提交
  3. 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
  4. 01 11月, 2013 1 次提交
  5. 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
  6. 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
  7. 26 6月, 2013 1 次提交
  8. 20 6月, 2013 2 次提交
  9. 10 3月, 2013 1 次提交
  10. 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
  11. 05 2月, 2013 1 次提交
  12. 22 1月, 2013 1 次提交
  13. 28 9月, 2012 1 次提交
  14. 25 6月, 2012 2 次提交
  15. 12 5月, 2012 1 次提交
  16. 18 4月, 2012 1 次提交
  17. 26 1月, 2012 2 次提交
  18. 14 12月, 2011 1 次提交
  19. 12 12月, 2011 2 次提交
  20. 21 9月, 2011 1 次提交
  21. 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
  22. 29 8月, 2011 1 次提交
  23. 26 8月, 2011 1 次提交
  24. 21 6月, 2011 4 次提交
  25. 14 6月, 2011 1 次提交