Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 11:54:43PM +0100, Russell King - ARM Linux wrote: > > if the memory was previously dirty (iow, CPU has written), you need to > flush the dirty cache lines _before_ the GPU writes happen, but you > don't know whether the CPU has speculatively prefetched, so you need > to

[PATCH 2/3] media/ttusb-dev: remove pci_zalloc_coherent abuse

Switch to a plain kzalloc instea of pci_zalloc_coherent to allocate memory for the USB DMA. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/media/usb/ttusb-dec/ttusb_dec.c | 13 +++-- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/drivers/media/usb/ttu

[PATCH 1/3] media/ttusb-budget: remove pci_zalloc_coherent abuse

Switch to a plain kzalloc instea of pci_zalloc_coherent to allocate memory for the USB DMA. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c | 13 +++-- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/drivers/med

[PATCH 3/3] pci-dma-compat: remove handling of NULL pdev arguments

Historically some ISA drivers used the old pci DMA API with a NULL pdev argument, but these days this isn't used and not too useful due to the per-device DMA ops, so remove it. Signed-off-by: Christoph Hellwig <h...@lst.de> --- include/linux/pci-dma-compat.h | 27 +---

remove pci_dma_* abuses and workarounds

Back before the dawn of time pci_dma_* with a NULL pci_dev argument was used for all kinds of things, e.g. dma mapping for non-PCI devices. All this has been long removed, but it turns out we still care for a NULL pci_dev in the wrappers, and we still have two odd USB drivers that use

[PATCH 1/4] media/ttusb-budget: remove pci_zalloc_coherent abuse

Switch to a plain kzalloc instead of pci_zalloc_coherent to allocate memory for the USB DMA. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c | 18 -- 1 file changed, 4 insertions(+), 14 deletions(-) diff --git a/drivers

remove pci_dma_* abuses and workarounds V2

Back before the dawn of time pci_dma_* with a NULL pci_dev argument was used for all kinds of things, e.g. dma mapping for non-PCI devices. All this has been long removed, but it turns out we still care for a NULL pci_dev in the wrappers, and we still have two odd USB drivers that use

[PATCH 2/4] media/ttusb-dev: remove pci_zalloc_coherent abuse

Switch to a plain kzalloc instead of pci_zalloc_coherent to allocate memory for the USB DMA. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/media/usb/ttusb-dec/ttusb_dec.c | 18 -- 1 file changed, 4 insertions(+), 14 deletions(-) diff --git a/drivers/media/usb

[PATCH 3/4] tsi108_eth: use dma API properly

with the driver. Signed-off-by: Christoph Hellwig <h...@lst.de> --- drivers/net/ethernet/tundra/tsi108_eth.c | 36 ++-- 1 file changed, 20 insertions(+), 16 deletions(-) diff --git a/drivers/net/ethernet/tundra/tsi108_eth.c b/drivers/net/ethernet/tundra/tsi108_eth.c

[PATCH 4/4] PCI: Remove NULL device handling from PCI DMA API

Historically some ISA drivers used the old PCI DMA API with a NULL pdev argument, but these days this isn't used and not too useful due to the per-device DMA ops, so remove it. Signed-off-by: Christoph Hellwig <h...@lst.de> --- include/linux/pci-dma-compat.h | 27 +---

Re: [PATCH 3/4] tsi108_eth: use dma API properly

On Wed, Jan 10, 2018 at 10:09:20PM +0200, Andy Shevchenko wrote: > > + struct platform_device *pdev; > > Do you really need platform_defice reference? > > Perhaps > > struct device *hdev; // hardware device > > > data->hdev = >dev; > > Another idea > > dev->dev.parent = >dev; > > No

Re: [PATCH 1/3] media/ttusb-budget: remove pci_zalloc_coherent abuse

On Tue, Jan 09, 2018 at 12:49:26PM -0800, Joe Perches wrote: > This message doesn't make sense anymore and it might as well > be deleted. > > And it might be better to use kcalloc > > ttusb->iso_buffer = kcalloc(FRAMES_PER_ISO_BUF * ISO_BUF_COUNT, >

Re: [PATCH 3/3] pci-dma-compat: remove handling of NULL pdev arguments

ng that with PCI is pretty horrible. I'll add a conversion of that driver to the next resend. > > Signed-off-by: Christoph Hellwig <h...@lst.de> > > With Mauro's ack on the media/ttusb-dev patches, I could merge the > whole series via the PCI tree? Fine with me.

Re: [PATCH 4/8] dma-buf: add peer2peer flag

On Mon, Apr 16, 2018 at 03:38:56PM +0200, Daniel Vetter wrote: > We've broken that assumption in i915 years ago. Not struct page backed > gpu memory is very real. > > Of course we'll never feed such a strange sg table to a driver which > doesn't understand it, but allowing sg_page == NULL works

Re: [PATCH 4/8] dma-buf: add peer2peer flag

On Tue, Apr 03, 2018 at 08:08:32PM +0200, Daniel Vetter wrote: > I did not mean you should dma_map_sg/page. I just meant that using > dma_map_resource to fill only the dma address part of the sg table seems > perfectly sufficient. But that is not how the interface work, especially facing

Re: [PATCH 4/8] dma-buf: add peer2peer flag

On Fri, Apr 20, 2018 at 10:58:50AM +0200, Christian König wrote: > > Yes there's a bit a layering violation insofar that drivers really > > shouldn't each have their own copy of "how do I convert a piece of dma > > memory into dma-buf", but that doesn't render the interface a bad idea. > >

Re: [PATCH 4/8] dma-buf: add peer2peer flag

On Fri, Apr 20, 2018 at 12:44:01PM +0200, Christian König wrote: > > > What we need is an sg_alloc_table_from_resources(dev, resources, > > > num_resources) which does the handling common to all drivers. > > A structure that contains > > > > {page,offset,len} + {dma_addr+dma_len} > > > > is not

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Fri, Apr 20, 2018 at 05:21:11PM +0200, Daniel Vetter wrote: > > At the very lowest level they will need to be handled differently for > > many architectures, the questions is at what point we'll do the > > branching out. > > Having at least struct page also in that list with (dma_addr_t,

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Wed, Apr 25, 2018 at 08:23:15AM +0200, Daniel Vetter wrote: > For more fun: > > https://www.spinics.net/lists/dri-devel/msg173630.html > > Yeah, sometimes we want to disable the iommu because the on-gpu > pagetables are faster ... I am not on this list, but remote NAK from here. This needs

Re: [PATCH] media: zoran: move to dma-mapping interface

On Tue, Apr 24, 2018 at 10:40:45PM +0200, Arnd Bergmann wrote: > No drivers should use virt_to_bus() any more. This converts > one of the few remaining ones to the DMA mapping interface. > > Signed-off-by: Arnd Bergmann > --- > drivers/media/pci/zoran/Kconfig| 2 +- >

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Tue, Apr 24, 2018 at 09:32:20PM +0200, Daniel Vetter wrote: > Out of curiosity, how much virtual flushing stuff is there still out > there? At least in drm we've pretty much ignore this, and seem to be > getting away without a huge uproar (at least from driver developers > and users, core folks

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Wed, Apr 25, 2018 at 09:02:17AM +0200, Daniel Vetter wrote: > Can we please not nack everything right away? Doesn't really motivate > me to show you all the various things we're doing in gpu to make the > dma layer work for us. That kind of noodling around in lower levels to > get them to do

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Wed, Apr 25, 2018 at 02:24:36AM -0400, Alex Deucher wrote: > > It has a non-coherent transaction mode (which the chipset can opt to > > not implement and still flush), to make sure the AGP horror show > > doesn't happen again and GPU folks are happy with PCIe. That's at > > least my

Re: [PATCH] media: zoran: move to dma-mapping interface

On Wed, Apr 25, 2018 at 09:08:13AM +0200, Arnd Bergmann wrote: > > That probably also means it can use dma_mmap_coherent instead of the > > handcrafted remap_pfn_range loop and the PageReserved abuse. > > I'd rather not touch that code. How about adding a comment about > the fact that it should

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Wed, Apr 25, 2018 at 09:56:43AM +0200, Thierry Reding wrote: > And to add to the confusion, none of this seems to be an issue on 64-bit > ARM where the generic DMA/IOMMU code from drivers/iommu/dma-iommu.c is > used. In the long term I want everyone to use that code. Help welcome!

noveau vs arm dma ops

[discussion about this patch, which should have been cced to the iommu and linux-arm-kernel lists, but wasn't: https://www.spinics.net/lists/dri-devel/msg173630.html] On Wed, Apr 25, 2018 at 09:41:51AM +0200, Thierry Reding wrote: > > API from the iommu/dma-mapping code. Drivers have no

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote: > > Coordinating the backport of a trivial helper in the arm tree is not > > the end of the world. Really, this cowboy attitude is a good reason > > why graphics folks have such a bad rep. You keep poking into random > > kernel

Re: [PATCH] media: zoran: move to dma-mapping interface

On Wed, Apr 25, 2018 at 01:15:18PM +0200, Arnd Bergmann wrote: > That thought had occurred to me as well. I removed the oldest ISDN > drivers already some years ago, and the OSS sound drivers > got removed as well, and comedi got converted to the dma-mapping > interfaces, so there isn't much left

Re: [PATCH 1/8] lib/scatterlist: add sg_set_dma_addr() helper

On Sun, Mar 25, 2018 at 12:59:53PM +0200, Christian König wrote: > Use this function to set an sg entry to point to device resources mapped > using dma_map_resource(). The page pointer is set to NULL and only the DMA > address, length and offset values are valid. NAK. Please provide a higher

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On Sun, Mar 25, 2018 at 12:59:54PM +0200, Christian König wrote: > From: "wda...@nvidia.com" > > Add an interface to find the first device which is upstream of both > devices. Please work with Logan and base this on top of the outstanding peer to peer patchset.

Re: [PATCH 2/8] PCI: Add pci_find_common_upstream_dev()

On Thu, Mar 29, 2018 at 09:58:54PM -0400, Jerome Glisse wrote: > dma_map_resource() is the right API (thought its current implementation > is fill with x86 assumptions). So i would argue that arch can decide to > implement it or simply return dma error address which trigger fallback > path into

<    1   2