search for: dma_map_ops

...in the driver. - DMA_ATTR_NO_KERNEL_MAPPING -------------------------- diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c index 6f7de4f4e191e7..447e0fd0ed3895 100644 --- a/arch/alpha/kernel/pci_iommu.c +++ b/arch/alpha/kernel/pci_iommu.c @@ -952,5 +952,7 @@ const struct dma_map_ops alpha_pci_ops = { .dma_supported = alpha_pci_supported, .mmap = dma_common_mmap, .get_sgtable = dma_common_get_sgtable, + .alloc_pages = dma_common_alloc_pages, + .free_pages = dma_common_free_pages, }; EXPORT_SYMBOL(alpha_pci_ops); diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/...

On arm64 the dma_map_ops implementation is based on the swiotlb. swiotlb-xen, used by default in dom0 on Xen, is also based on the swiotlb. Avoid calling into the default arm64 dma_map_ops functions from xen_dma_map_page, xen_dma_unmap_page, xen_dma_sync_single_for_cpu, and xen_dma_sync_single_for_device otherwise we end...

...in the driver. - DMA_ATTR_NO_KERNEL_MAPPING -------------------------- diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c index 81037907268d5c..291121e3b5a583 100644 --- a/arch/alpha/kernel/pci_iommu.c +++ b/arch/alpha/kernel/pci_iommu.c @@ -957,5 +957,7 @@ const struct dma_map_ops alpha_pci_ops = { .dma_supported = alpha_pci_supported, .mmap = dma_common_mmap, .get_sgtable = dma_common_get_sgtable, + .alloc_pages = dma_common_alloc_pages, + .free_pages = dma_common_free_pages, }; EXPORT_SYMBOL(alpha_pci_ops); diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/...

...390/include/asm/device.h b/arch/s390/include/asm/device.h index d8f9872..4a9f35e 100644 --- a/arch/s390/include/asm/device.h +++ b/arch/s390/include/asm/device.h @@ -3,5 +3,9 @@ * * This file is released under the GPLv2 */ -#include <asm-generic/device.h> +struct dev_archdata { + struct dma_map_ops *dma_ops; +}; +struct pdev_archdata { +}; diff --git a/arch/s390/include/asm/dma-mapping.h b/arch/s390/include/asm/dma-mapping.h index b3fd54d..cb05f5c 100644 --- a/arch/s390/include/asm/dma-mapping.h +++ b/arch/s390/include/asm/dma-mapping.h @@ -11,11 +11,13 @@ #define DMA_ERROR_CODE (~(dma_...

...390/include/asm/device.h b/arch/s390/include/asm/device.h index d8f9872..4a9f35e 100644 --- a/arch/s390/include/asm/device.h +++ b/arch/s390/include/asm/device.h @@ -3,5 +3,9 @@ * * This file is released under the GPLv2 */ -#include <asm-generic/device.h> +struct dev_archdata { + struct dma_map_ops *dma_ops; +}; +struct pdev_archdata { +}; diff --git a/arch/s390/include/asm/dma-mapping.h b/arch/s390/include/asm/dma-mapping.h index b3fd54d..cb05f5c 100644 --- a/arch/s390/include/asm/dma-mapping.h +++ b/arch/s390/include/asm/dma-mapping.h @@ -11,11 +11,13 @@ #define DMA_ERROR_CODE (~(dma_...

...e/asm/device.h b/arch/s390/include/asm/device.h index d8f9872b0e2d..4a9f35e0973f 100644 --- a/arch/s390/include/asm/device.h +++ b/arch/s390/include/asm/device.h @@ -3,5 +3,9 @@ * * This file is released under the GPLv2 */ -#include <asm-generic/device.h> +struct dev_archdata { + struct dma_map_ops *dma_ops; +}; +struct pdev_archdata { +}; diff --git a/arch/s390/include/asm/dma-mapping.h b/arch/s390/include/asm/dma-mapping.h index e64bfcb9702f..3249b7464889 100644 --- a/arch/s390/include/asm/dma-mapping.h +++ b/arch/s390/include/asm/dma-mapping.h @@ -11,11 +11,13 @@ #define DMA_ERROR_COD...

...390/include/asm/device.h b/arch/s390/include/asm/device.h index d8f9872..4a9f35e 100644 --- a/arch/s390/include/asm/device.h +++ b/arch/s390/include/asm/device.h @@ -3,5 +3,9 @@ * * This file is released under the GPLv2 */ -#include <asm-generic/device.h> +struct dev_archdata { + struct dma_map_ops *dma_ops; +}; +struct pdev_archdata { +}; diff --git a/arch/s390/include/asm/dma-mapping.h b/arch/s390/include/asm/dma-mapping.h index b3fd54d..cb05f5c 100644 --- a/arch/s390/include/asm/dma-mapping.h +++ b/arch/s390/include/asm/dma-mapping.h @@ -11,11 +11,13 @@ #define DMA_ERROR_CODE (~(dma_...

Andy, to make it obvious which version is the latest, here is a branch The following changes since commit 6a13feb9c82803e2b815eca72fa7a9f5561d7861: Linux 4.3 (2015-11-01 16:05:25 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux.git dma for you to fetch changes up to fc7f9754db6ce0c12281da4055281f731d36bdee: s390/dma: Allow

Andy, to make it obvious which version is the latest, here is a branch The following changes since commit 6a13feb9c82803e2b815eca72fa7a9f5561d7861: Linux 4.3 (2015-11-01 16:05:25 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/borntraeger/linux.git dma for you to fetch changes up to fc7f9754db6ce0c12281da4055281f731d36bdee: s390/dma: Allow

Andy, this is the next and hopefully last version. Seems to work fine when replacing the previous patches in your tree. I have some reviews/acks for patch 2 and 3. patch 1 still needs one ack. Can you replace the patches in your tree and carry them along with your changes? old introduction: ----- There are some attempts to unify the dma ops (Christoph) as well as some attempts to make virtio use

Andy, this is the next and hopefully last version. Seems to work fine when replacing the previous patches in your tree. I have some reviews/acks for patch 2 and 3. patch 1 still needs one ack. Can you replace the patches in your tree and carry them along with your changes? old introduction: ----- There are some attempts to unify the dma ops (Christoph) as well as some attempts to make virtio use

...se the dma_map_* APIs and just switch the dma_ops in the struct device based on the hypervisor requirements. IE. For KVM we could attach a set of ops that basically just return the physical address, real PCI transport would use the normal callbacks etc... The only problem at the moment is that the dma_map_ops, while defined generically, aren't plumbed into the generic struct device but instead on some architectures dev_archdata. This includes powerpc, ARM and x86 (under a CONFIG option for the latter which is only enabled on x86_64 and some oddball i386 variant). So either we switch to have all arc...

...se the dma_map_* APIs and just switch the dma_ops in the struct device based on the hypervisor requirements. IE. For KVM we could attach a set of ops that basically just return the physical address, real PCI transport would use the normal callbacks etc... The only problem at the moment is that the dma_map_ops, while defined generically, aren't plumbed into the generic struct device but instead on some architectures dev_archdata. This includes powerpc, ARM and x86 (under a CONFIG option for the latter which is only enabled on x86_64 and some oddball i386 variant). So either we switch to have all arc...

here is the 2nd version of providing an DMA API for s390. There are some attempts to unify the dma ops (Christoph) as well as some attempts to make virtio use the dma API (Andy). At kernel summit we concluded that we want to use the same code on all platforms, whereever possible, so having a dummy dma_op might be the easiest solution to keep virtio-ccw as similar as possible to

here is the 2nd version of providing an DMA API for s390. There are some attempts to unify the dma ops (Christoph) as well as some attempts to make virtio use the dma API (Andy). At kernel summit we concluded that we want to use the same code on all platforms, whereever possible, so having a dummy dma_op might be the easiest solution to keep virtio-ccw as similar as possible to

...lt; 6) +#define DMA_ATTR_FORCE_CONTIGUOUS (1UL << 7) +#define DMA_ATTR_ALLOC_SINGLE_PAGES (1UL << 8) + /* * A dma_addr_t can hold any valid DMA or bus address for the platform. * It can be given to a device to use as a DMA source or target. A CPU cannot @@ -21,34 +33,35 @@ struct dma_map_ops { void* (*alloc)(struct device *dev, size_t size, dma_addr_t *dma_handle, gfp_t gfp, - struct dma_attrs *attrs); + unsigned long attrs); void (*free)(struct device *dev, size_t size, void *vaddr, dma_addr_t dma_handle, - struct dma_attrs *attrs); + unsigned...

...nsigned long attrs) All these functions should probably be marked static. > +void virtio_direct_unmap_page(struct device *hwdev, dma_addr_t dev_addr, > + size_t size, enum dma_data_direction dir, > + unsigned long attrs) > +{ > +} No need to implement no-op callbacks in struct dma_map_ops. > + > +int virtio_direct_mapping_error(struct device *hwdev, dma_addr_t dma_addr) > +{ > + return 0; > +} Including this one. > +void *virtio_direct_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle, > + gfp_t gfp, unsigned long attrs) > +{ > + void *queu...

...-mapping.c > index af27f1c22d93..87a0037574e4 100644 > --- a/arch/arm/mm/dma-mapping.c > +++ b/arch/arm/mm/dma-mapping.c > @@ -1151,6 +1151,11 @@ int arm_dma_supported(struct device *dev, u64 mask) > return __dma_supported(dev, mask, false); > } > > +static const struct dma_map_ops *arm_get_dma_map_ops(bool coherent) > +{ > + return coherent ? &arm_coherent_dma_ops : &arm_dma_ops; > +} > + > #ifdef CONFIG_ARM_DMA_USE_IOMMU > > static int __dma_info_to_prot(enum dma_data_direction dir, unsigned long attrs) > @@ -2296,7 +2301,7 @@ void arm_io...

Hi all, this patch series enables xen-swiotlb on arm and arm64. It has been heavily reworked compared to the previous versions in order to achieve better performances and to address review comments. We are not using dma_mark_clean to ensure coherency anymore. We call the platform implementation of map_page and unmap_page. We assume that dom0 has been mapped 1:1 (physical address == machine

...ivers/virtio/virtio.c > index 7907ad3..6b13987 100644 > --- a/drivers/virtio/virtio.c > +++ b/drivers/virtio/virtio.c > @@ -166,6 +166,8 @@ void virtio_add_status(struct virtio_device *dev, unsigned int status) > } > EXPORT_SYMBOL_GPL(virtio_add_status); > > +const struct dma_map_ops virtio_direct_dma_ops; > + > int virtio_finalize_features(struct virtio_device *dev) > { > int ret = dev->config->finalize_features(dev); > @@ -174,6 +176,9 @@ int virtio_finalize_features(struct virtio_device *dev) > if (ret) > return ret; The previous patch r...