similar to: [PATCH 3/5] Move dma_ops from archdata into struct device

On Fri, 2016-12-09 at 19:22 +0100, Christoph Hellwig wrote: > We'll need a bit of a wieder audience for this I think.. > > On Wed, Dec 07, 2016 at 05:11:28PM -0800, Bart Van Assche wrote: > > Additionally, introduce set_dma_ops(). A later patch will introduce a > > call to that function in the RDMA drivers that will be modified to use > > dma_noop_ops. > >

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, 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

From: Thierry Reding <treding at nvidia.com> Depending on the kernel configuration, early ARM architecture setup code may have attached the GPU to a DMA/IOMMU mapping that transparently uses the IOMMU to back the DMA API. Tegra requires special handling for IOMMU backed buffers (a special bit in the GPU's MMU page tables indicates the memory path to take: via the SMMU or directly to the

> +void arch_iommu_detach_device(struct device *dev) > +{ > +#ifdef CONFIG_ARM_DMA_USE_IOMMU > + struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev); > + const struct dma_map_ops *dma_ops; > + > + if (!mapping) > + return; > + > + arm_iommu_release_mapping(mapping); > + arm_iommu_detach_device(dev); > + > + dma_ops =

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

From: Thierry Reding <treding at nvidia.com> Depending on the kernel configuration, early ARM architecture setup code may have attached the GPU to a DMA/IOMMU mapping that transparently uses the IOMMU to back the DMA API. Tegra requires special handling for IOMMU backed buffers (a special bit in the GPU's MMU page tables indicates the memory path to take: via the SMMU or directly to the

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 at

On Fri, Jul 20, 2018 at 09:29:41AM +0530, Anshuman Khandual wrote: >Subject: Re: [RFC 4/4] virtio: Add platform specific DMA API translation for > virito devices s/virito/virtio/ > This adds a hook which a platform can define in order to allow it to > override virtio device's DMA OPS irrespective of whether it has the > flag VIRTIO_F_IOMMU_PLATFORM set or not. We want to use

On Fri, Jul 20, 2018 at 09:29:41AM +0530, Anshuman Khandual wrote: >Subject: Re: [RFC 4/4] virtio: Add platform specific DMA API translation for > virito devices s/virito/virtio/ > This adds a hook which a platform can define in order to allow it to > override virtio device's DMA OPS irrespective of whether it has the > flag VIRTIO_F_IOMMU_PLATFORM set or not. We want to use

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 at

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

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.

Hallo, ich schreibe einfach mal deutsch, und hoffe dass Du das auch verstehst (if not write me back in English). OS X 10.3.9 Ich habe R 2.1.0 installiert, und das Programm hat auch funktioniert. Will wenig sp??ter wieder mit R arbeiten, es l??sst sich aber nicht mehr starten. "Das Programm R wurde unerwartet beendet", w??hrend ich versuche es durch Doppelklicken auf das R.app-symbol

On 07/20/2018 09:29 AM, Anshuman Khandual wrote: > Now that virtio core always needs all virtio devices to have DMA OPS, we > need to make sure that the structure it points is the right one. In the > absence of VIRTIO_F_IOMMU_PLATFORM flag QEMU expects GPA from guest kernel. > In such case, virtio device must use default virtio_direct_dma_ops DMA OPS > structure which transforms

On 07/20/2018 09:29 AM, Anshuman Khandual wrote: > Now that virtio core always needs all virtio devices to have DMA OPS, we > need to make sure that the structure it points is the right one. In the > absence of VIRTIO_F_IOMMU_PLATFORM flag QEMU expects GPA from guest kernel. > In such case, virtio device must use default virtio_direct_dma_ops DMA OPS > structure which transforms

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