Re: [PATCH 2/4] dma-buf: lock the reservation object during (un)map_dma_buf v2

Am 03.07.2018 um 14:52 schrieb Daniel Vetter: On Tue, Jul 03, 2018 at 01:46:44PM +0200, Christian König wrote: Am 25.06.2018 um 11:12 schrieb Daniel Vetter: On Mon, Jun 25, 2018 at 10:22:31AM +0200, Daniel Vetter wrote: On Fri, Jun 22, 2018 at 04:11:01PM +0200, Christian König wrote: First

Re: [PATCH 04/15] dma-fence: Make ->wait callback optional

Am 04.05.2018 um 11:25 schrieb Daniel Vetter: On Fri, May 4, 2018 at 11:16 AM, Chris Wilson wrote: Quoting Daniel Vetter (2018-05-04 09:57:59) On Fri, May 04, 2018 at 09:31:33AM +0100, Chris Wilson wrote: Quoting Daniel Vetter (2018-05-04 09:23:01) On Fri, May 04,

Re: [PATCH 04/17] dma-fence: Allow wait_any_timeout for all fences

Am 27.04.2018 um 08:17 schrieb Daniel Vetter: When this was introduced in commit a519435a96597d8cd96123246fea4ae5a6c90b02 Author: Christian König <christian.koe...@amd.com> Date: Tue Oct 20 16:34:16 2015 +0200 dma-buf/fence: add fence_wait_any_timeout funct

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

Am 20.04.2018 um 12:17 schrieb Christoph Hellwig: 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 th

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

Am 20.04.2018 um 09:13 schrieb Daniel Vetter: On Thu, Apr 19, 2018 at 01:16:57AM -0700, Christoph Hellwig wrote: 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

[PATCH 5/5] drm/amdgpu: add independent DMA-buf import v3

interface Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 72 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 32 +++--- 2 files changed, 89 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/d

[PATCH 1/5] dma-buf: use parameter structure for dma_buf_attach

Move the parameters into a structure to make it simpler to extend it in follow up patches. This also adds the importer private as parameter so that we can directly work with a completely filled in attachment structure. Signed-off-by: Christian König <christian.koe...@amd.com> --- drive

[PATCH 3/5] drm/ttm: remove the backing store if no placement is given

Pipeline removal of the BOs backing store when the placement is given during validation. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/ttm/ttm_bo.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/d

[PATCH 4/5] drm/amdgpu: add independent DMA-buf export v2

Instead of relying on the DRM functions just implement our own export functions. This adds support for taking care of unpinned DMA-buf. v2: fix unintended recursion, remove debugging leftovers Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/amd/amdgpu/am

[PATCH 2/5] dma-buf: add optional invalidate_mappings callback v3

to set the callback v3: move flag for invalidation support into the DMA-buf, use new attach_info structure to set the callback v4: use importer_priv field instead of mangling exporter priv. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/dma-buf/dma-buf.

Re: [PATCH v2] Add udmabuf misc device

Am 06.04.2018 um 11:33 schrieb Gerd Hoffmann: Hi, The pages backing a DMA-buf are not allowed to move (at least not without a patch set I'm currently working on), but for certain MM operations to work correctly you must be able to modify the page tables entries and move the pages backing

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

Am 29.03.2018 um 18:25 schrieb Logan Gunthorpe: On 29/03/18 10:10 AM, Christian König wrote: Why not? I mean the dma_map_resource() function is for P2P while other dma_map_* functions are only for system memory. Oh, hmm, I wasn't aware dma_map_resource was exclusively for mapping P2P. Though

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

Am 29.03.2018 um 17:45 schrieb Logan Gunthorpe: On 29/03/18 05:44 AM, Christian König wrote: Am 28.03.2018 um 21:53 schrieb Logan Gunthorpe: On 28/03/18 01:44 PM, Christian König wrote: Well, isn't that exactly what dma_map_resource() is good for? As far as I can see it makes sure IOMMU

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

Am 28.03.2018 um 21:53 schrieb Logan Gunthorpe: On 28/03/18 01:44 PM, Christian König wrote: Well, isn't that exactly what dma_map_resource() is good for? As far as I can see it makes sure IOMMU is aware of the access route and translates a CPU address into a PCI Bus address. I'm using

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

Am 29.03.2018 um 08:57 schrieb Daniel Vetter: On Sun, Mar 25, 2018 at 12:59:56PM +0200, Christian König wrote: Add a peer2peer flag noting that the importer can deal with device resources which are not backed by pages. Signed-off-by: Christian König <christian.koe...@amd.com> Um st

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

Am 28.03.2018 um 20:57 schrieb Logan Gunthorpe: On 28/03/18 12:28 PM, Christian König wrote: I'm just using amdgpu as blueprint because I'm the co-maintainer of it and know it mostly inside out. Ah, I see. The resource addresses are translated using dma_map_resource(). As far as I know

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

Am 28.03.2018 um 18:25 schrieb Logan Gunthorpe: On 28/03/18 10:02 AM, Christian König wrote: Yeah, that looks very similar to what I picked up from the older patches, going to read up on that after my vacation. Yeah, I was just reading through your patchset and there are a lot of similarities

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

Am 28.03.2018 um 17:47 schrieb Logan Gunthorpe: On 28/03/18 09:07 AM, Christian König wrote: Am 28.03.2018 um 14:38 schrieb Christoph Hellwig: On Sun, Mar 25, 2018 at 12:59:54PM +0200, Christian König wrote: From: "wda...@nvidia.com" <wda...@nvidia.com> Add an interface t

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

Am 28.03.2018 um 14:38 schrieb Christoph Hellwig: On Sun, Mar 25, 2018 at 12:59:54PM +0200, Christian König wrote: From: "wda...@nvidia.com" <wda...@nvidia.com> Add an interface to find the first device which is upstream of both devices. Please work with Logan and

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Am 27.03.2018 um 09:53 schrieb Daniel Vetter: [SNIP] [SNIP] A slightly better solution is using atomic counter: driver_range_start() { atomic_inc(>notifier_count); ... Yeah, that is exactly what amdgpu is doing now. Sorry if my description didn't made that clear. I would like to

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Am 26.03.2018 um 17:42 schrieb Jerome Glisse: On Mon, Mar 26, 2018 at 10:01:21AM +0200, Daniel Vetter wrote: On Thu, Mar 22, 2018 at 10:58:55AM +0100, Christian König wrote: Am 22.03.2018 um 08:18 schrieb Daniel Vetter: [SNIP] Key take away from that was that you can't take any locks from

Re: [PATCH] dma-buf: use parameter structure for dma_buf_attach

Am 26.03.2018 um 10:36 schrieb Daniel Vetter: On Sun, Mar 25, 2018 at 01:34:51PM +0200, Christian König wrote: [SNIP] - attach->dev = dev; + attach->dev = info->dev; attach->dmabuf = dmabuf; + attach->priv = info->priv; The ->priv fiel

Re: [PATCH] dma-buf: use parameter structure for dma_buf_attach

Am 26.03.2018 um 10:36 schrieb Daniel Vetter: On Sun, Mar 25, 2018 at 01:34:51PM +0200, Christian König wrote: [SNIP] - attach->dev = dev; + attach->dev = info->dev; attach->dmabuf = dmabuf; + attach->priv = info->priv; The ->priv fiel

[PATCH] dma-buf: use parameter structure for dma_buf_attach

Move the parameters into a structure to make it simpler to extend it in follow up patches. This also adds the importer private as parameter so that we can directly work with a completely filled in attachment structure. Signed-off-by: Christian König <christian.koe...@amd.com> --- drive

[PATCH 8/8] drm/amdgpu: add support for exporting VRAM using DMA-buf

We should be able to do this now after checking all the prerequisites. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c| 44 +++--- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 9 +++ drivers/gpu/drm/amd/

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

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. Signed-off-by: Christian König <christian.koe...@amd.com> --- include/linux/scatterlist.

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

From: "wda...@nvidia.com" <wda...@nvidia.com> Add an interface to find the first device which is upstream of both devices. Signed-off-by: Will Davis <wda...@nvidia.com> Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/pci/search.c | 24 +

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

Add a peer2peer flag noting that the importer can deal with device resources which are not backed by pages. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/dma-buf/dma-buf.c | 1 + include/linux/dma-buf.h | 4 2 files changed, 5 insertions(+) diff --git a/d

[PATCH 3/8] PCI: Add pci_peer_traffic_supported()

From: "wda...@nvidia.com" <wda...@nvidia.com> Add checks for topology and ACS configuration to determine whether or not peer traffic should be supported between two PCI devices. Signed-off-by: Will Davis <wda...@nvidia.com> Signed-off-by: Christian König <christian.koe

[PATCH 7/8] drm/amdgpu: add amdgpu_gem_attach

Check if we can do peer2peer on the PCIe bus. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 24 1 file changed, 24 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c b/drivers/gpu/d

[PATCH 6/8] drm/amdgpu: note that we can handle peer2peer DMA-buf

Importing should work out of the box. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c

[PATCH 5/8] drm/amdgpu: print DMA-buf status in debugfs

Just note if a BO was imported/exported. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c

[PATCH 4/5] drm/amdgpu: add independent DMA-buf export v2

Instead of relying on the DRM functions just implement our own export functions. This adds support for taking care of unpinned DMA-buf. v2: fix unintended recursion, remove debugging leftovers Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/amd/amdgpu/am

[PATCH 2/5] drm/ttm: keep a reference to transfer pipelined BOs

Make sure the transfered BO is never destroy before the transfer BO. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/ttm/ttm_bo_util.c | 50 +++ 1 file changed, 30 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/d

[PATCH 5/5] drm/amdgpu: add independent DMA-buf import v3

interface Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 72 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 32 +++--- 2 files changed, 89 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/d

[PATCH 1/5] dma-buf: add optional invalidate_mappings callback v3

to set the callback v3: move flag for invalidation support into the DMA-buf, use new attach_info structure to set the callback Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/dma-buf/dma-buf.c | 43 +++ include/linux/dma-buf.h

[PATCH 3/5] drm/ttm: remove the backing store if no placement is given

Pipeline removal of the BOs backing store when the placement is given during validation. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/ttm/ttm_bo.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/d

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Am 22.03.2018 um 08:18 schrieb Daniel Vetter: On Wed, Mar 21, 2018 at 12:54:20PM +0100, Christian König wrote: Am 21.03.2018 um 09:28 schrieb Daniel Vetter: On Tue, Mar 20, 2018 at 06:47:57PM +0100, Christian König wrote: Am 20.03.2018 um 15:08 schrieb Daniel Vetter: [SNIP] For the in-driver

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Am 22.03.2018 um 08:14 schrieb Daniel Vetter: On Wed, Mar 21, 2018 at 10:34:05AM +0100, Christian König wrote: Am 21.03.2018 um 09:18 schrieb Daniel Vetter: [SNIP] For correct operation you always need to implement invalidate_range_end as well and add some lock/completion work Otherwise

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Am 21.03.2018 um 09:28 schrieb Daniel Vetter: On Tue, Mar 20, 2018 at 06:47:57PM +0100, Christian König wrote: Am 20.03.2018 um 15:08 schrieb Daniel Vetter: [SNIP] For the in-driver reservation path (CS) having a slow-path that grabs a temporary reference, drops the vram lock and then locks

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Am 21.03.2018 um 09:18 schrieb Daniel Vetter: [SNIP] They're both in i915_gem_userptr.c, somewhat interleaved. Would be interesting if you could show what you think is going wrong in there compared to amdgpu_mn.c. i915 implements only one callback: static const struct mmu_notifier_ops

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Am 20.03.2018 um 15:08 schrieb Daniel Vetter: [SNIP] For the in-driver reservation path (CS) having a slow-path that grabs a temporary reference, drops the vram lock and then locks the reservation normally (using the acquire context used already for the entire CS) is a bit tricky, but totally

Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Am 20.03.2018 um 08:44 schrieb Daniel Vetter: On Mon, Mar 19, 2018 at 5:23 PM, Christian König <ckoenig.leichtzumer...@gmail.com> wrote: Am 19.03.2018 um 16:53 schrieb Chris Wilson: Quoting Christian König (2018-03-16 14:22:32) [snip, probably lost too must context] This allows for full

Re: [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Am 19.03.2018 um 16:53 schrieb Chris Wilson: Quoting Christian König (2018-03-16 14:22:32) [snip, probably lost too must context] This allows for full grown pipelining, e.g. the exporter can say I need to move the buffer for some operation. Then let the move operation wait for all existing

Re: [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

Am 16.03.2018 um 14:51 schrieb Chris Wilson: Quoting Christian König (2018-03-16 13:20:45) @@ -326,6 +338,29 @@ struct dma_buf_attachment { struct device *dev; struct list_head node; void *priv; + + /** +* @invalidate_mappings

[PATCH 4/5] drm/amdgpu: add independent DMA-buf export v2

Instead of relying on the DRM functions just implement our own export functions. This adds support for taking care of unpinned DMA-buf. v2: fix unintended recursion, remove debugging leftovers Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/amd/amdgpu/am

[PATCH 3/5] drm/ttm: remove the backing store if no placement is given

Pipeline removal of the BOs backing store when the placement is given during validation. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/ttm/ttm_bo.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/d

[PATCH 5/5] drm/amdgpu: add independent DMA-buf import v2

Instead of relying on the DRM functions just implement our own import functions. This adds support for taking care of unpinned DMA-buf. v2: enable for all exporters, not just amdgpu, fix invalidation handling, lock reservation object while setting callback Signed-off-by: Christian König

[PATCH 2/5] drm/ttm: keep a reference to transfer pipelined BOs

Make sure the transfered BO is never destroy before the transfer BO. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/ttm/ttm_bo_util.c | 50 +++ 1 file changed, 30 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/d

[PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2

to set the callback Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/dma-buf/dma-buf.c | 60 +++ include/linux/dma-buf.h | 38 ++ 2 files changed, 98 insertions(+) diff --git a/drivers/dma-buf/dma-b

RFC: unpinned DMA-buf exporting v2

Hi everybody, since I've got positive feedback from Daniel I continued working on this approach. A few issues are still open: 1. Daniel suggested that I make the invalidate_mappings callback a parameter of dma_buf_attach(). This approach unfortunately won't work because when the attachment is

Re: [PATCH v2] Add udmabuf misc device

Am 16.03.2018 um 08:46 schrieb Gerd Hoffmann: A driver to let userspace turn iovecs into dma-bufs. Use case: Allows qemu create dmabufs for the vga framebuffer or virtio-gpu ressources. Then they can be passed around to display those guest things on the host. To spice client for classic full

Re: [PATCH 1/4] dma-buf: add optional invalidate_mappings callback

Am 15.03.2018 um 10:20 schrieb Daniel Vetter: On Tue, Mar 13, 2018 at 06:20:07PM +0100, Christian König wrote: [SNIP] Take a look at the DOT graphs for atomic I've done a while ago. I think we could make a formidable competition for who's doing the worst diagrams :-) Thanks, going to give

Re: [PATCH 1/4] dma-buf: add optional invalidate_mappings callback

Am 13.03.2018 um 17:00 schrieb Daniel Vetter: On Tue, Mar 13, 2018 at 04:52:02PM +0100, Christian König wrote: Am 13.03.2018 um 16:17 schrieb Daniel Vetter: [SNIP] Ok, so plan is to support fully pipeline moves and everything, with the old sg tables lazily cleaned up. I was thinking more about

Re: [PATCH 1/4] dma-buf: add optional invalidate_mappings callback

Am 13.03.2018 um 16:17 schrieb Daniel Vetter: [SNIP] I think a helper which both unmaps _and_ waits for all the fences to clear would be best, with some guarantees that it'll either fail or all the mappings _will_ be gone. The locking for that one will be hilarious, since we need to figure out

Re: RFC: unpinned DMA-buf exporting

Am 12.03.2018 um 18:24 schrieb Daniel Vetter: On Fri, Mar 09, 2018 at 08:11:40PM +0100, Christian K??nig wrote: This set of patches adds an option invalidate_mappings callback to each DMA-buf attachment which can be filled in by the importer. This callback allows the exporter to provided the

Re: [PATCH 1/4] dma-buf: add optional invalidate_mappings callback

Am 12.03.2018 um 18:07 schrieb Daniel Vetter: On Fri, Mar 09, 2018 at 08:11:41PM +0100, Christian K??nig wrote: [SNIP] +/** + * dma_buf_invalidate_mappings - invalidate all mappings of this dma_buf + * + * @dmabuf:[in]buffer which mappings should be invalidated + * + * Informs all

[PATCH 1/4] dma-buf: add optional invalidate_mappings callback

Each importer can now provide an invalidate_mappings callback. This allows the exporter to provide the mappings without the need to pin the backing store. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/dma-buf/dma-buf.c | 25 + include/lin

[PATCH 3/4] drm/amdgpu: add independent DMA-buf export

Instead of relying on the DRM functions just implement our own export functions. This adds support for taking care of unpinned DMA-buf. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 - drivers/gpu/drm/amd/amdgpu/amdgpu

[PATCH 4/4] drm/amdgpu: add independent DMA-buf import

Instead of relying on the DRM functions just implement our own import functions. This adds support for taking care of unpinned DMA-buf. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 64 +-- drivers/g

RFC: unpinned DMA-buf exporting

This set of patches adds an option invalidate_mappings callback to each DMA-buf attachment which can be filled in by the importer. This callback allows the exporter to provided the DMA-buf content without pinning it. The reservation objects lock acts as synchronization point for buffer moves

[PATCH 2/4] drm/ttm: keep a reference to transfer pipelined BOs

Make sure the transfered BO is never destroy before the transfer BO. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/ttm/ttm_bo_util.c | 50 +++ 1 file changed, 30 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/d

[PATCH 1/4] dma-buf: add optional invalidate_mappings callback

Each importer can now provide an invalidate_mappings callback. This allows the exporter to provide the mappings without the need to pin the backing store. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/dma-buf/dma-buf.c | 25 + include/lin

Re: [PATCH 1/3] dma-buf: make returning the exclusive fence optional

Ping? Daniel you requested the patch with its user. Would be nice when I can commit this cause we need it for debugging and cleaning up a bunch of other things as well. Regards, Christian. Am 12.01.2018 um 10:47 schrieb Christian König: Change reservation_object_get_fences_rcu to make

[PATCH 2/3] drm/amdgpu: add amdgpu_pasid_free_delayed v2

Free up a pasid after all fences signaled. v2: also handle the case when we can't allocate a fence array. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c | 82 + drivers/gpu/drm/amd/amdgpu/amdgpu_ids.

[PATCH 1/3] dma-buf: make returning the exclusive fence optional

Change reservation_object_get_fences_rcu to make the exclusive fence pointer optional. If not specified the exclusive fence is put into the fence array as well. This is helpful for a couple of cases where we need all fences in a single array. Signed-off-by: Christian König <christian.

[PATCH 3/3] drm/amdgpu: always allocate a PASIDs for each VM v2

Start to always allocate a pasid for each VM. v2: use dev_warn when we run out of PASIDs Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 43 ++--- 1 file changed, 29 insertions(+), 14 deletions(-) diff

Re: [Linaro-mm-sig] [PATCH] dma-buf: add some lockdep asserts to the reservation object implementation

Yeah, somehow missed that one. The patch looks mostly good, except for reservation_object_get_excl(). For that one an RCU protection is usually sufficient, so annotating it with reservation_object_assert_held() sounds incorrect to me. Regards, Christian. Am 11.01.2018 um 11:43 schrieb Lucas

Re: [Linaro-mm-sig] [PATCH] dma-buf: make returning the exclusive fence optional

Am 10.01.2018 um 14:21 schrieb Daniel Vetter: On Wed, Jan 10, 2018 at 01:53:41PM +0100, Christian König wrote: Change reservation_object_get_fences_rcu to make the exclusive fence pointer optional. If not specified the exclusive fence is put into the fence array as well. This is helpful

[PATCH] dma-buf: make returning the exclusive fence optional

Change reservation_object_get_fences_rcu to make the exclusive fence pointer optional. If not specified the exclusive fence is put into the fence array as well. This is helpful for a couple of cases where we need all fences in a single array. Signed-off-by: Christian König <christian.

Re: [PATCH 0/4] Backported amdgpu ttm deadlock fixes for 4.14

-by: Christian König <christian.koe...@amd.com> Thanks for taking care of this, Christian. Additionally, some more race conditions exist that I've managed to trigger with piglit and lockdep enabled after applying these patches: = WARNING: suspicious RCU

Re: [PATCH] reservation: don't wait when timeout=0

Am 21.11.2017 um 16:58 schrieb Chris Wilson: Quoting Christian König (2017-11-21 15:49:55) Am 21.11.2017 um 15:59 schrieb Rob Clark: On Tue, Nov 21, 2017 at 9:38 AM, Chris Wilson <ch...@chris-wilson.co.uk> wrote: Quoting Rob Clark (2017-11-21 14:08:46) If we are testing if a reser

Re: [PATCH] reservation: don't wait when timeout=0

Am 21.11.2017 um 15:59 schrieb Rob Clark: On Tue, Nov 21, 2017 at 9:38 AM, Chris Wilson wrote: Quoting Rob Clark (2017-11-21 14:08:46) If we are testing if a reservation object's fences have been signaled with timeout=0 (non-blocking), we need to pass 0 for timeout

Re: [PATCH] reservation: don't wait when timeout=0

viewed-by: Christian König <christian.koe...@amd.com> --- drivers/dma-buf/reservation.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c index dec3a815455d..71f51140a9ad 100644 --- a/dri

Re: [PATCH 0/4] dma-buf: Silence dma_fence __rcu sparse warnings

Patch #4 is Reviewed-by: Christian König <christian.koe...@amd.com>. The rest is Acked-by: Christian König <christian.koe...@amd.com>. Regards, Christian. Am 02.11.2017 um 21:03 schrieb Ville Syrjala: From: Ville Syrjälä <ville.syrj...@linux.intel.com> When building drm+i91

Re: [PATCH] dma-buf: Cleanup comments on dma_buf_map_attachment()

Am 01.11.2017 um 15:06 schrieb Liviu Dudau: Mappings need to be unmapped by calling dma_buf_unmap_attachment() and not by calling again dma_buf_map_attachment(). Also fix some spelling mistakes. Signed-off-by: Liviu Dudau <liviu.du...@arm.com> Reviewed-by: Christian König <chri

Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

Am 20.09.2017 um 20:20 schrieb Daniel Vetter: On Mon, Sep 11, 2017 at 01:06:32PM +0200, Christian König wrote: Am 11.09.2017 um 12:01 schrieb Chris Wilson: [SNIP] Yeah, but that is illegal with a fence objects. When anybody allocates fences this way it breaks at least

[PATCH] dma-fence: fix dma_fence_get_rcu_safe v2

From: Christian König <christian.koe...@amd.com> When dma_fence_get_rcu() fails to acquire a reference it doesn't necessary mean that there is no fence at all. It usually mean that the fence was replaced by a new one and in this situation we certainly want to have the new one as

Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

Am 11.09.2017 um 12:01 schrieb Chris Wilson: [SNIP] Yeah, but that is illegal with a fence objects. When anybody allocates fences this way it breaks at least reservation_object_get_fences_rcu(), reservation_object_wait_timeout_rcu() and reservation_object_test_signaled_single(). Many, many

Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

Am 11.09.2017 um 11:23 schrieb Chris Wilson: Quoting Christian König (2017-09-11 10:06:50) Am 11.09.2017 um 10:59 schrieb Chris Wilson: Quoting Christian König (2017-09-11 09:50:40) Sorry for the delayed response, but your mail somehow ended up in the Spam folder. Am 04.09.2017 um 15:40

Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

Am 11.09.2017 um 10:59 schrieb Chris Wilson: Quoting Christian König (2017-09-11 09:50:40) Sorry for the delayed response, but your mail somehow ended up in the Spam folder. Am 04.09.2017 um 15:40 schrieb Chris Wilson: Quoting Christian König (2017-09-04 14:27:33) From: Christian König

Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

Sorry for the delayed response, but your mail somehow ended up in the Spam folder. Am 04.09.2017 um 15:40 schrieb Chris Wilson: Quoting Christian König (2017-09-04 14:27:33) From: Christian König <christian.koe...@amd.com> The logic is buggy and unnecessary complex. When dma_fence_g

Re: [PATCH] dma-fence: fix dma_fence_get_rcu_safe

I really wonder what's wrong with my mail client, but it looks like this patch never made it at least to dri-devel. Forwarding manually now, Christian. Am 04.09.2017 um 15:16 schrieb Christian König: From: Christian König <christian.koe...@amd.com> The logic is buggy and unnecessary c

[PATCH] dma-fence: fix dma_fence_get_rcu_safe

From: Christian König <christian.koe...@amd.com> The logic is buggy and unnecessary complex. When dma_fence_get_rcu() fails to acquire a reference it doesn't necessary mean that there is no fence at all. It usually mean that the fence was replaced by a new one and in this situation we cer

[PATCH] dma-fence: fix dma_fence_get_rcu_safe

From: Christian König <christian.koe...@amd.com> The logic is buggy and unnecessary complex. When dma_fence_get_rcu() fails to acquire a reference it doesn't necessary mean that there is no fence at all. It usually mean that the fence was replaced by a new one and in this situation we cer

Re: [PATCH] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly v2

Ping, what do you guys think of that? Am 25.07.2017 um 15:35 schrieb Christian König: From: Christian König <christian.koe...@amd.com> With hardware resets in mind it is possible that all shared fences are signaled, but the exlusive isn't. Fix waiting for everything in this situatio

[PATCH] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly v2

From: Christian König <christian.koe...@amd.com> With hardware resets in mind it is possible that all shared fences are signaled, but the exlusive isn't. Fix waiting for everything in this situation. v2: make sure we always wait for the exclusive fence Signed-off-by: Christian

Re: [PATCH] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly

Am 24.07.2017 um 13:57 schrieb Daniel Vetter: On Mon, Jul 24, 2017 at 11:51 AM, Christian König <deathsim...@vodafone.de> wrote: Am 24.07.2017 um 10:33 schrieb Daniel Vetter: On Fri, Jul 21, 2017 at 06:20:01PM +0200, Christian König wrote: From: Christian König <christian.koe..

Re: [PATCH] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly

Am 24.07.2017 um 10:34 schrieb zhoucm1: On 2017年07月22日 00:20, Christian König wrote: From: Christian König <christian.koe...@amd.com> With hardware resets in mind it is possible that all shared fences are signaled, but the exlusive isn't. Fix waiting for everything in this sit

Re: [PATCH] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly

Am 24.07.2017 um 10:33 schrieb Daniel Vetter: On Fri, Jul 21, 2017 at 06:20:01PM +0200, Christian König wrote: From: Christian König <christian.koe...@amd.com> With hardware resets in mind it is possible that all shared fences are signaled, but the exlusive isn't. Fix waiting for ever

[PATCH] dma-buf: fix reservation_object_wait_timeout_rcu to wait correctly

From: Christian König <christian.koe...@amd.com> With hardware resets in mind it is possible that all shared fences are signaled, but the exlusive isn't. Fix waiting for everything in this situation. Signed-off-by: Christian König <christian.koe...@amd.com> --- drivers/dma-buf/reser

Re: [PATCH] dma-buf: avoid scheduling on fence status query v2

overhead to a fence status query. Avoid this overhead by returning early if a zero timeout is specified. v2: move early return after enable_signaling Signed-off-by: Andres Rodriguez <andre...@gmail.com> Reviewed-by: Christian König <christian.koe...@amd.com> --- If I'm understandi

Re: [PATCH] dma-buf: avoid scheduling on fence status query

Am 26.04.2017 um 11:59 schrieb Dave Airlie: On 26 April 2017 at 17:20, Christian König <deathsim...@vodafone.de> wrote: NAK, I'm wondering how often I have to reject that change. We should probably add a comment here. Even with a zero timeout we still need to enable signaling, otherwis

Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

lt;log...@deltatee.com> --- Good to know that somebody is working on this. Those problems troubled us as well. Patch is Acked-by: Christian König <christian.koe...@amd.com>. Regards, Christian. include/linux/scatterlist.h | 85 + 1 file changed

Re: [PATCH] dma-buf: avoid scheduling on fence status query

NAK, I'm wondering how often I have to reject that change. We should probably add a comment here. Even with a zero timeout we still need to enable signaling, otherwise some fence will never signal if userspace just polls on them. If a caller is only interested in the fence status without

Re: [PATCH] dma-buf: fence debugging

Exclusive fence: etnaviv 134000.gpu signalled Attached Devices: gpu-subsystem Total 1 devices attached Total 1 objects, 8294400 bytes Signed-off-by: Russell King <rmk+ker...@arm.linux.org.uk> Reviewed-by: Christian König <christian.koe...@amd.com> --- drivers/dma-b

Re: [PATCH] dma-buf: add support for compat ioctl

Am 21.02.2017 um 15:55 schrieb Marek Szyprowski: Dear All, On 2017-02-21 15:37, Marek Szyprowski wrote: Hi Christian, On 2017-02-21 14:59, Christian König wrote: Am 21.02.2017 um 14:21 schrieb Marek Szyprowski: Add compat ioctl support to dma-buf. This lets one to use DMA_BUF_IOCTL_SYNC

Re: [PATCH] dma-buf: add support for compat ioctl

Am 21.02.2017 um 14:21 schrieb Marek Szyprowski: Add compat ioctl support to dma-buf. This lets one to use DMA_BUF_IOCTL_SYNC ioctl from 32bit application on 64bit kernel. Data structures for both 32 and 64bit modes are same, so there is no need for additional translation layer. Well I might

Re: Enabling peer to peer device transactions for PCIe devices

Am 12.01.2017 um 16:11 schrieb Jerome Glisse: On Wed, Jan 11, 2017 at 10:54:39PM -0600, Stephen Bates wrote: On Fri, January 6, 2017 4:10 pm, Logan Gunthorpe wrote: On 06/01/17 11:26 AM, Jason Gunthorpe wrote: Make a generic API for all of this and you'd have my vote.. IMHO, you must

Re: Enabling peer to peer device transactions for PCIe devices

Am 27.11.2016 um 15:02 schrieb Haggai Eran: On 11/25/2016 9:32 PM, Jason Gunthorpe wrote: On Fri, Nov 25, 2016 at 02:22:17PM +0100, Christian König wrote: Like you say below we have to handle short lived in the usual way, and that covers basically every device except IB MRs, including

  1   2   >