1. 20 Aug, 2020 1 commit
  2. 30 Jun, 2020 1 commit
  3. 11 Sep, 2019 1 commit
  4. 05 Jun, 2019 1 commit
  5. 30 May, 2017 1 commit
    • Laurent Pinchart's avatar
      ARM: dma-mapping: Don't tear down third-party mappings · a93a121a
      Laurent Pinchart authored
      arch_setup_dma_ops() is used in device probe code paths to create an
      IOMMU mapping and attach it to the device. The function assumes that the
      device is attached to a device-specific IOMMU instance (or at least a
      device-specific TLB in a shared IOMMU instance) and thus creates a
      separate mapping for every device.
      
      On several systems (Renesas R-Car Gen2 being one of them), that
      assumption is not true, and IOMMU mappings must be shared between
      multiple devices. In those cases the IOMMU driver knows better than the
      generic ARM dma-mapping layer and attaches mapping to devices manually
      with arm_iommu_attach_device(), which sets the DMA ops for the device.
      
      The arch_setup_dma_ops() function takes this into account and bails out
      immediately if the device already has DMA ops assigned. However, the
      corresponding arch_teardown_dma_ops() function, called from driver
      unbind code paths (including probe deferral), will tear the mapping down
      regardless of who created it. When the device is reprobed
      arch_setup_dma_ops() will be called again but won't perform any
      operation as the DMA ops will still be set.
      
      We need to reset the DMA ops in arch_teardown_dma_ops() to fix this.
      However, we can't do so unconditionally, as then a new mapping would be
      created by arch_setup_dma_ops() when the device is reprobed, regardless
      of whether the device needs to share a mapping or not. We must thus keep
      track of whether arch_setup_dma_ops() created the mapping, and only in
      that case tear it down in arch_teardown_dma_ops().
      
      Keep track of that information in the dev_archdata structure. As the
      structure is embedded in all instances of struct device let's not grow
      it, but turn the existing dma_coherent bool field into a bitfield that
      can be used for other purposes.
      
      Fixes: 09515ef5
      
       ("of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices")
      Reviewed-by: Robin Murphy's avatarRobin Murphy <robin.murphy@arm.com>
      Signed-off-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      a93a121a
  6. 02 May, 2017 1 commit
    • Stefano Stabellini's avatar
      xen/arm,arm64: fix xen_dma_ops after 815dd187 "Consolidate get_dma_ops..." · e0586326
      Stefano Stabellini authored
      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: default avatarStefano Stabellini <sstabellini@kernel.org>
      Tested-by: default avatarJulien Grall <julien.grall@arm.com>
      Suggested-by: Catalin Marinas's avatarCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: Catalin Marinas's avatarCatalin 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
  7. 24 Jan, 2017 2 commits
    • Bart Van Assche's avatar
      treewide: Move dma_ops from struct dev_archdata into struct device · 5657933d
      Bart Van Assche authored
      
      
      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: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Acked-by: default avatarGreg 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: default avatarDoug Ledford <dledford@redhat.com>
      5657933d
    • Bart Van Assche's avatar
      treewide: Constify most dma_map_ops structures · 5299709d
      Bart Van Assche authored
      
      
      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: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Reviewed-by: default avatarChristoph 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: default avatarDoug Ledford <dledford@redhat.com>
      5299709d
  8. 04 Dec, 2014 1 commit
  9. 25 Feb, 2013 1 commit
  10. 21 May, 2012 2 commits
    • Marek Szyprowski's avatar
      ARM: dma-mapping: add support for IOMMU mapper · 4ce63fcd
      Marek Szyprowski authored
      
      
      This patch add a complete implementation of DMA-mapping API for
      devices which have IOMMU support.
      
      This implementation tries to optimize dma address space usage by remapping
      all possible physical memory chunks into a single dma address space chunk.
      
      DMA address space is managed on top of the bitmap stored in the
      dma_iommu_mapping structure stored in device->archdata. Platform setup
      code has to initialize parameters of the dma address space (base address,
      size, allocation precision order) with arm_iommu_create_mapping() function.
      To reduce the size of the bitmap, all allocations are aligned to the
      specified order of base 4 KiB pages.
      
      dma_alloc_* functions allocate physical memory in chunks, each with
      alloc_pages() function to avoid failing if the physical memory gets
      fragmented. In worst case the allocated buffer is composed of 4 KiB page
      chunks.
      
      dma_map_sg() function minimizes the total number of dma address space
      chunks by merging of physical memory chunks into one larger dma address
      space chunk. If requested chunk (scatter list entry) boundaries
      match physical page boundaries, most calls to dma_map_sg() requests will
      result in creating only one chunk in dma address space.
      
      dma_map_page() simply creates a mapping for the given page(s) in the dma
      address space.
      
      All dma functions also perform required cache operation like their
      counterparts from the arm linear physical memory mapping version.
      
      This patch contains code and fixes kindly provided by:
      - Krishna Reddy <vdumpa@nvidia.com>,
      - Andrzej Pietrasiewicz <andrzej.p@samsung.com>,
      - Hiroshi DOYU <hdoyu@nvidia.com>
      
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Acked-by: default avatarKyungmin Park <kyungmin.park@samsung.com>
      Reviewed-by: default avatarKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Tested-By: default avatarSubash Patel <subash.ramaswamy@linaro.org>
      4ce63fcd
    • Marek Szyprowski's avatar
      ARM: dma-mapping: use asm-generic/dma-mapping-common.h · 2dc6a016
      Marek Szyprowski authored
      
      
      This patch modifies dma-mapping implementation on ARM architecture to
      use common dma_map_ops structure and asm-generic/dma-mapping-common.h
      helpers.
      
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Acked-by: default avatarKyungmin Park <kyungmin.park@samsung.com>
      Tested-By: default avatarSubash Patel <subash.ramaswamy@linaro.org>
      2dc6a016
  11. 17 Oct, 2011 1 commit
    • Ohad Ben-Cohen's avatar
      ARM: 7130/1: dev_archdata: add private iommu extension · cfb470b3
      Ohad Ben-Cohen authored
      
      
      Add a private iommu pointer to the ARM-specific arch data in the
      device struct, which will be used to attach iommu-specific data
      to devices which require iommu support.
      
      Different iommu implementations (on different platforms) will attach
      different types of data to this pointer, so 'void *' is currently used
      (the downside is reduced typesafety).
      
      Note: ia64, x86 and sparc have this exact iommu extension as well, and
      if others are likely to adopt it too, we might want to consider
      adding this to the device struct itself directly.
      
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Grant Likely <grant.likely@secretlab.ca>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      cfb470b3
  12. 21 Sep, 2011 1 commit
  13. 21 Jul, 2009 1 commit
    • Magnus Damm's avatar
      Driver Core: Add platform device arch data V3 · d7aacadd
      Magnus Damm authored
      
      
      Allow architecture specific data in struct platform_device V3.
      
      With this patch struct pdev_archdata is added to struct
      platform_device, similar to struct dev_archdata in found in
      struct device. Useful for architecture code that needs to
      keep extra data associated with each platform device.
      
      Struct pdev_archdata is different from dev.platform_data, the
      convention is that dev.platform_data points to driver-specific
      data. It may or may not be required by the driver. The format
      of this depends on driver but is the same across architectures.
      
      The structure pdev_archdata is a place for architecture specific
      data. This data is handled by architecture specific code (for
      example runtime PM), and since it is architecture specific it
      should _never_ be touched by device driver code. Exactly like
      struct dev_archdata but for platform devices.
      
      [rjw: This change is for power management mostly and that's why it
       goes through the suspend tree.]
      
      Signed-off-by: default avatarMagnus Damm <damm@igel.co.jp>
      Acked-by: default avatarKevin Hilman <khilman@deeprootsystems.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      d7aacadd
  14. 02 Aug, 2008 1 commit
  15. 12 Feb, 2007 1 commit
  16. 01 Dec, 2006 1 commit