Am 19.08.2013 12:17, schrieb Maarten Lankhorst:
[SNIP]
@@ -190,25 +225,24 @@ void radeon_fence_process(struct radeon_device *rdev, int
ring)
}
} while (atomic64_xchg(rdev-fence_drv[ring].last_seq, seq) seq);
- if (wake) {
+ if (wake)
Am 19.08.2013 21:37, schrieb Maarten Lankhorst:
Op 19-08-13 14:35, Christian König schreef:
Am 19.08.2013 12:17, schrieb Maarten Lankhorst:
[SNIP]
@@ -190,25 +225,24 @@ void radeon_fence_process(struct radeon_device *rdev, int
ring)
}
} while (atomic64_xchg(rdev-fence_drv
Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
[SNIP]
[SNIP]
+/**
+ * radeon_fence_enable_signaling - enable signalling on fence
+ * @fence: fence
+ *
+ * This function is called with fence_queue lock held, and adds a callback
+ * to fence_queue that checks if this fence is signaled, and if so
Am 20.08.2013 15:21, schrieb Maarten Lankhorst:
Op 20-08-13 11:51, Christian König schreef:
Am 20.08.2013 11:36, schrieb Maarten Lankhorst:
[SNIP]
[SNIP]
+/**
+ * radeon_fence_enable_signaling - enable signalling on fence
+ * @fence: fence
+ *
+ * This function is called with fence_queue lock
Am 17.02.2014 16:56, schrieb Maarten Lankhorst:
This type of fence can be used with hardware synchronization for simple
hardware that can block execution until the condition
(dma_buf[offset] - value) = 0 has been met.
Can't we make that just dma_buf[offset] != 0 instead? As far as I know
this
Am 17.02.2014 18:27, schrieb Rob Clark:
On Mon, Feb 17, 2014 at 11:56 AM, Christian König
deathsim...@vodafone.de wrote:
Am 17.02.2014 16:56, schrieb Maarten Lankhorst:
This type of fence can be used with hardware synchronization for simple
hardware that can block execution until
Am 17.02.2014 19:24, schrieb Rob Clark:
On Mon, Feb 17, 2014 at 12:36 PM, Christian König
deathsim...@vodafone.de wrote:
Am 17.02.2014 18:27, schrieb Rob Clark:
On Mon, Feb 17, 2014 at 11:56 AM, Christian König
deathsim...@vodafone.de wrote:
Am 17.02.2014 16:56, schrieb Maarten Lankhorst
Am 09.03.2016 um 10:03 schrieb Daniel Vetter:
On Wed, Mar 9, 2016 at 9:54 AM, Benjamin Gaignard
wrote:
In addition of the already existing operations allow exporter
to use it own custom ioctls.
Signed-off-by: Benjamin Gaignard
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
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
g
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch>
Need to strike the r-b here, since Christian König pointed out that
objects won't magically switch signalling on.
Oh, it also means that
commit fb8b7d2b9d80e1e71f379e57355936bd2b02
Am 25.11.2016 um 20:32 schrieb Jason Gunthorpe:
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 the
command queue on a NVMe drive.
Well a problem
Am 23.11.2016 um 08:49 schrieb Daniel Vetter:
On Tue, Nov 22, 2016 at 01:21:03PM -0800, Dan Williams wrote:
On Tue, Nov 22, 2016 at 1:03 PM, Daniel Vetter wrote:
On Tue, Nov 22, 2016 at 9:35 PM, Serguei Sagalovitch
wrote:
On 2016-11-22 03:10 PM,
Am 24.11.2016 um 00:25 schrieb Jason Gunthorpe:
There is certainly nothing about the hardware that cares
about ZONE_DEVICE vs System memory.
Well that is clearly not so simple. When your ZONE_DEVICE pages describe
a PCI BAR and another PCI device initiates a DMA to this address the DMA
Am 24.11.2016 um 17:42 schrieb Jason Gunthorpe:
On Wed, Nov 23, 2016 at 06:25:21PM -0700, Logan Gunthorpe wrote:
On 23/11/16 02:55 PM, Jason Gunthorpe wrote:
Only ODP hardware allows changing the DMA address on the fly, and it
works at the page table level. We do not need special handling for
Am 24.11.2016 um 18:55 schrieb Logan Gunthorpe:
Hey,
On 24/11/16 02:45 AM, Christian König wrote:
E.g. it can happen that PCI device A exports it's BAR using ZONE_DEVICE.
Not PCI device B (a SATA device) can directly read/write to it because
it is on the same bus segment, but PCI device C
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
Am 12.10.2016 um 01:50 schrieb Ruchi Kandoi:
This patchstack adds memtrack hooks into dma-buf and ion. If there's upstream
interest in memtrack, it can be extended to other memory allocators as well,
such as GEM implementations.
We have run into similar problems before. Because of this I
Patch number 6 in this series (which touches drivers I co-maintain) is
Acked-by: Christian König <christian.koe...@amd.com>.
In general looks like a very nice cleanup to me, but I'm not enlightened
enough to full judge.
Regards,
Christian.
arch/alpha/kernel/pt
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
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
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
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..
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
-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
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
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
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
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
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
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,
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
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
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
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.
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
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
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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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 +
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/
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
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
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
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
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
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
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
1 - 100 of 116 matches
Mail list logo