1. 03 11月, 2018 1 次提交
  2. 31 10月, 2018 1 次提交
  3. 19 10月, 2018 3 次提交
  4. 26 9月, 2018 1 次提交
  5. 25 9月, 2018 1 次提交
    • R
      arm64/dma-mapping: Mildly optimise non-coherent IOMMU ops · 7adb562c
      Robin Murphy 提交于
      Whilst the symmetry of deferring to the existing sync callback in
      __iommu_map_page() is nice, taking a round-trip through
      iommu_iova_to_phys() is a pretty heavyweight way to get an address we
      can trivially compute from the page we already have. Tweaking it to just
      perform the cache maintenance directly when appropriate doesn't really
      make the code any more complicated, and the runtime efficiency gain can
      only be a benefit.
      
      Furthermore, the sync operations themselves know they can only be
      invoked on a managed DMA ops domain, so can use the fast specific domain
      lookup to avoid excessive manipulation of the group refcount
      (particularly in the scatterlist cases).
      Acked-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
      Tested-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      7adb562c
  6. 08 9月, 2018 1 次提交
  7. 18 8月, 2018 1 次提交
  8. 19 6月, 2018 1 次提交
  9. 15 5月, 2018 1 次提交
    • C
      arm64: Increase ARCH_DMA_MINALIGN to 128 · ebc7e21e
      Catalin Marinas 提交于
      This patch increases the ARCH_DMA_MINALIGN to 128 so that it covers the
      currently known Cache Writeback Granule (CTR_EL0.CWG) on arm64 and moves
      the fallback in cache_line_size() from L1_CACHE_BYTES to this constant.
      In addition, it warns (and taints) if the CWG is larger than
      ARCH_DMA_MINALIGN as this is not safe with non-coherent DMA.
      
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Robin Murphy <robin.murphy@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      ebc7e21e
  10. 08 5月, 2018 1 次提交
  11. 27 3月, 2018 1 次提交
  12. 07 3月, 2018 1 次提交
    • C
      arm64: Revert L1_CACHE_SHIFT back to 6 (64-byte cache line size) · 1f85b42a
      Catalin Marinas 提交于
      Commit 97303480 ("arm64: Increase the max granular size") increased
      the cache line size to 128 to match Cavium ThunderX, apparently for some
      performance benefit which could not be confirmed. This change, however,
      has an impact on the network packets allocation in certain
      circumstances, requiring slightly over a 4K page with a significant
      performance degradation.
      
      This patch reverts L1_CACHE_SHIFT back to 6 (64-byte cache line) while
      keeping ARCH_DMA_MINALIGN at 128. The cache_line_size() function was
      changed to default to ARCH_DMA_MINALIGN in the absence of a meaningful
      CTR_EL0.CWG bit field.
      
      In addition, if a system with ARCH_DMA_MINALIGN < CTR_EL0.CWG is
      detected, the kernel will force swiotlb bounce buffering for all
      non-coherent devices since DMA cache maintenance on sub-CWG ranges is
      not safe, leading to data corruption.
      
      Cc: Tirumalesh Chalamarla <tchalamarla@cavium.com>
      Cc: Timur Tabi <timur@codeaurora.org>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Acked-by: NRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      1f85b42a
  13. 15 1月, 2018 3 次提交
  14. 10 1月, 2018 1 次提交
    • C
      dma-mapping: move swiotlb arch helpers to a new header · ea8c64ac
      Christoph Hellwig 提交于
      phys_to_dma, dma_to_phys and dma_capable are helpers published by
      architecture code for use of swiotlb and xen-swiotlb only.  Drivers are
      not supposed to use these directly, but use the DMA API instead.
      
      Move these to a new asm/dma-direct.h helper, included by a
      linux/dma-direct.h wrapper that provides the default linear mapping
      unless the architecture wants to override it.
      
      In the MIPS case the existing dma-coherent.h is reused for now as
      untangling it will take a bit of work.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: NRobin Murphy <robin.murphy@arm.com>
      ea8c64ac
  15. 04 10月, 2017 1 次提交
  16. 02 10月, 2017 1 次提交
  17. 21 8月, 2017 2 次提交
  18. 20 7月, 2017 1 次提交
  19. 20 6月, 2017 1 次提交
  20. 15 6月, 2017 1 次提交
  21. 05 5月, 2017 1 次提交
  22. 02 5月, 2017 1 次提交
    • S
      xen/arm,arm64: fix xen_dma_ops after 815dd187 "Consolidate get_dma_ops..." · e0586326
      Stefano Stabellini 提交于
      The following commit:
      
        commit 815dd187
        Author: Bart Van Assche <bart.vanassche@sandisk.com>
        Date:   Fri Jan 20 13:04:04 2017 -0800
      
            treewide: Consolidate get_dma_ops() implementations
      
      rearranges get_dma_ops in a way that xen_dma_ops are not returned when
      running on Xen anymore, dev->dma_ops is returned instead (see
      arch/arm/include/asm/dma-mapping.h:get_arch_dma_ops and
      include/linux/dma-mapping.h:get_dma_ops).
      
      Fix the problem by storing dev->dma_ops in dev_archdata, and setting
      dev->dma_ops to xen_dma_ops. This way, xen_dma_ops is returned naturally
      by get_dma_ops. The Xen code can retrieve the original dev->dma_ops from
      dev_archdata when needed. It also allows us to remove __generic_dma_ops
      from common headers.
      Signed-off-by: NStefano Stabellini <sstabellini@kernel.org>
      Tested-by: NJulien Grall <julien.grall@arm.com>
      Suggested-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Cc: <stable@vger.kernel.org>        [4.11+]
      CC: linux@armlinux.org.uk
      CC: catalin.marinas@arm.com
      CC: will.deacon@arm.com
      CC: boris.ostrovsky@oracle.com
      CC: jgross@suse.com
      CC: Julien Grall <julien.grall@arm.com>
      e0586326
  23. 29 4月, 2017 1 次提交
  24. 20 4月, 2017 1 次提交
  25. 23 3月, 2017 1 次提交
  26. 25 2月, 2017 1 次提交
  27. 06 2月, 2017 1 次提交
    • R
      iommu/dma: Remove bogus dma_supported() implementation · a1831bb9
      Robin Murphy 提交于
      Back when this was first written, dma_supported() was somewhat of a
      murky mess, with subtly different interpretations being relied upon in
      various places. The "does device X support DMA to address range Y?"
      uses assuming Y to be physical addresses, which motivated the current
      iommu_dma_supported() implementation and are alluded to in the comment
      therein, have since been cleaned up, leaving only the far less ambiguous
      "can device X drive address bits Y" usage internal to DMA API mask
      setting. As such, there is no reason to keep a slightly misleading
      callback which does nothing but duplicate the current default behaviour;
      we already constrain IOVA allocations to the iommu_domain aperture where
      necessary, so let's leave DMA mask business to architecture-specific
      code where it belongs.
      Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      a1831bb9
  28. 26 1月, 2017 1 次提交
  29. 25 1月, 2017 2 次提交
    • B
      treewide: Move dma_ops from struct dev_archdata into struct device · 5657933d
      Bart Van Assche 提交于
      Some but not all architectures provide set_dma_ops(). Move dma_ops
      from struct dev_archdata into struct device such that it becomes
      possible on all architectures to configure dma_ops per device.
      Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: x86@kernel.org
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      5657933d
    • B
      treewide: Constify most dma_map_ops structures · 5299709d
      Bart Van Assche 提交于
      Most dma_map_ops structures are never modified. Constify these
      structures such that these can be write-protected. This patch
      has been generated as follows:
      
      git grep -l 'struct dma_map_ops' |
        xargs -d\\n sed -i \
          -e 's/struct dma_map_ops/const struct dma_map_ops/g' \
          -e 's/const struct dma_map_ops {/struct dma_map_ops {/g' \
          -e 's/^const struct dma_map_ops;$/struct dma_map_ops;/' \
          -e 's/const const struct dma_map_ops /const struct dma_map_ops /g';
      sed -i -e 's/const \(struct dma_map_ops intel_dma_ops\)/\1/' \
        $(git grep -l 'struct dma_map_ops intel_dma_ops');
      sed -i -e 's/const \(struct dma_map_ops dma_iommu_ops\)/\1/' \
        $(git grep -l 'struct dma_map_ops' | grep ^arch/powerpc);
      sed -i -e '/^struct vmd_dev {$/,/^};$/ s/const \(struct dma_map_ops[[:blank:]]dma_ops;\)/\1/' \
             -e '/^static void vmd_setup_dma_ops/,/^}$/ s/const \(struct dma_map_ops \*dest\)/\1/' \
             -e 's/const \(struct dma_map_ops \*dest = \&vmd->dma_ops\)/\1/' \
          drivers/pci/host/*.c
      sed -i -e '/^void __init pci_iommu_alloc(void)$/,/^}$/ s/dma_ops->/intel_dma_ops./' arch/ia64/kernel/pci-dma.c
      sed -i -e 's/static const struct dma_map_ops sn_dma_ops/static struct dma_map_ops sn_dma_ops/' arch/ia64/sn/pci/pci_dma.c
      sed -i -e 's/(const struct dma_map_ops \*)//' drivers/misc/mic/bus/vop_bus.c
      Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: x86@kernel.org
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      5299709d
  30. 23 1月, 2017 1 次提交
  31. 19 1月, 2017 1 次提交
  32. 12 1月, 2017 1 次提交
  33. 19 12月, 2016 1 次提交
  34. 14 11月, 2016 1 次提交