search for: dev_archdata

...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 architectures we care about always use the generic DMA ops and move the pointer to struct device, or we create another inline &q...

...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 architectures we care about always use the generic DMA ops and move the pointer to struct device, or we create another inline &q...

On Tue, 3 Nov 2015 12:54:39 +0100 Christian Borntraeger <borntraeger at de.ibm.com> wrote: > As virtio-ccw now has dma ops, we can no longer default to the PCI ones. > Make use of dev_archdata to keep the dma_ops per device. The pci devices > now use that to override the default, and the default is changed to use > the noop ops for everything that is not PCI. To compile without PCI > support we also have to enable the DMA api with virtio. Not only with virtio, but generally, ri...

On Tue, 3 Nov 2015 12:54:39 +0100 Christian Borntraeger <borntraeger at de.ibm.com> wrote: > As virtio-ccw now has dma ops, we can no longer default to the PCI ones. > Make use of dev_archdata to keep the dma_ops per device. The pci devices > now use that to override the default, and the default is changed to use > the noop ops for everything that is not PCI. To compile without PCI > support we also have to enable the DMA api with virtio. Not only with virtio, but generally, ri...

As virtio-ccw now has dma ops, we can no longer default to the PCI ones. Make use of dev_archdata to keep the dma_ops per device. The pci devices now use that to override the default, and the default is changed to use the noop ops for everything that is not PCI. To compile without PCI support we also have to enable the DMA api with virtio. Signed-off-by: Christian Borntraeger <borntraeger a...

As virtio-ccw now has dma ops, we can no longer default to the PCI ones. Make use of dev_archdata to keep the dma_ops per device. The pci devices now use that to override the default, and the default is changed to use the noop ops for everything that is not PCI. To compile without PCI support we also have to enable the DMA api with virtio. Signed-off-by: Christian Borntraeger <borntraeger a...

From: Christian Borntraeger <borntraeger at de.ibm.com> As virtio-ccw will have dma ops, we can no longer default to the zPCI ones. Make use of dev_archdata to keep the dma_ops per device. The pci devices now use that to override the default, and the default is changed to use the noop ops for everything that does not specify a device specific one. To compile without PCI support we will enable HAS_DMA all the time, via the default config in lib/Kconfig....

As virtio-ccw will have dma ops, we can no longer default to the zPCI ones. Make use of dev_archdata to keep the dma_ops per device. The pci devices now use that to override the default, and the default is changed to use the noop ops for everything that does not specify a device specific one. To compile without PCI support we will enable HAS_DMA all the time, via the default config in lib/Kconfig....

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

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

Am 03.11.2015 um 13:26 schrieb Cornelia Huck: > On Tue, 3 Nov 2015 12:54:39 +0100 > Christian Borntraeger <borntraeger at de.ibm.com> wrote: > >> As virtio-ccw now has dma ops, we can no longer default to the PCI ones. >> Make use of dev_archdata to keep the dma_ops per device. The pci devices >> now use that to override the default, and the default is changed to use >> the noop ops for everything that is not PCI. To compile without PCI >> support we also have to enable the DMA api with virtio. > > Not only with vir...

...A_USE_IOMMU - bool + def_bool y select ARM_HAS_SG_CHAIN select NEED_SG_DMA_LENGTH diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h index 3234fe9bba6e..c3cf38e16866 100644 --- a/arch/arm/include/asm/device.h +++ b/arch/arm/include/asm/device.h @@ -13,9 +13,7 @@ struct dev_archdata { #ifdef CONFIG_IOMMU_API void *iommu; /* private IOMMU data */ #endif -#ifdef CONFIG_ARM_DMA_USE_IOMMU struct dma_iommu_mapping *mapping; -#endif #ifdef CONFIG_XEN const struct dma_map_ops *dev_dma_ops; #endif @@ -31,10 +29,6 @@ struct pdev_archdata { #endif }; -#ifdef CONFIG_ARM_DMA...

Currently, a lot of the virtio code assumes that bus (i.e. hypervisor) addresses are the same as physical address. This is false on Xen, so virtio is completely broken. I wouldn't be surprised if it also becomes a problem the first time that someone sticks a physical "virtio" device on a 32-bit bus on an ARM SOC with more than 4G RAM. Would you accept patches to convert

Currently, a lot of the virtio code assumes that bus (i.e. hypervisor) addresses are the same as physical address. This is false on Xen, so virtio is completely broken. I wouldn't be surprised if it also becomes a problem the first time that someone sticks a physical "virtio" device on a 32-bit bus on an ARM SOC with more than 4G RAM. Would you accept patches to convert

This switches virtio to use the DMA API on Xen and if requested by module option. This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86. To the Xen people: is this okay? If it doesn't work on other Xen variants (PVH? HVM?), can you submit follow-up patches to fix it? To everyone else: we've waffled on this for way too

This switches virtio to use the DMA API on Xen and if requested by module option. This fixes virtio on Xen, and it should break anything because it's off by default on everything except Xen PV on x86. To the Xen people: is this okay? If it doesn't work on other Xen variants (PVH? HVM?), can you submit follow-up patches to fix it? To everyone else: we've waffled on this for way too