think because I used
a newer version.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
Cc: sta...@vger.kernel.org
---
diff --git a/drivers/gpu/drm/nouveau/nva3_copy.fuc
b/drivers/gpu/drm/nouveau/nva3_copy.fuc
index abc3662..219850d 100644
--- a/drivers/gpu/drm/nouveau
Hey,
For intel/nouveau hybrid graphics I'm interested in this since it
would allow me to synchronize between intel and nvidia cards
without waiting for rendering to complete.
I'm worried about the api though, nouveau and intel already
have existing infrastructure to deal with fencing so exposing
Hey Erik,
Op 07-06-12 19:35, Erik Gilling schreef:
On Thu, Jun 7, 2012 at 1:55 AM, Maarten Lankhorst
m.b.lankho...@gmail.com wrote:
I haven't looked at intel and amd, but from a quick glance
it seems like they already implement fencing too, so just
some way to synch up the fences on shared
white is set to src if used, but src can be used in the maskFormat too.
Fixes crash when logging in on a sandybridge laptop.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
diff --git a/uxa/uxa-glyphs.c b/uxa/uxa-glyphs.c
index e83464e..4b81756 100644
--- a/uxa/uxa-glyphs.c
Hey,
Due to inertia, I thought I would take a shot at implicit synchronization as
well.
I have just barely enough to make it work for nouveau to synchronize with itself
now using the cpu. Hopefully the general idea is correct but I feel the
implementation wrong.
There are 2 ways to get
Well,
V2 time! I was hinted to look at ttm_execbuf_util, and it does indeed contain
some nice code.
My goal was to extend dma-buf in a generic way now, some elements from v1 are
remaining,
most notably a dma-buf used for syncing. However it is expected now that
dma-buf syncing will
work in a
This patch implements my attempt at dmabuf synchronization.
The core idea is that a lot of devices will have their own
methods of synchronization, but more complicated devices
allow some way of fencing, so why not export those as
dma-buf?
This patchset implements dmabufmgr, which is based on
From: Maarten Lankhorst maarten.lankho...@canonical.com
Core code based on ttm_bo and ttm_execbuf_util
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/base/Makefile |2 +-
drivers/base/dma-buf-mgr-eu.c | 263
From: Maarten Lankhorst maarten.lankho...@canonical.com
Export the hardware status page so others can read seqno.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 29 --
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 87
From: Maarten Lankhorst maarten.lankho...@canonical.com
The prime code no longer requires the bo to be backed by a gem object,
and cpu access calls have been implemented. This will be needed for
exporting fence bo's.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers
From: Maarten Lankhorst maarten.lankho...@canonical.com
This is needed to allow creation of read-only vm mappings
in fence objects.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c |6 +++---
drivers/gpu/drm/nouveau/nouveau_drv.h
From: Maarten Lankhorst maarten.lankho...@canonical.com
This can be used by nv84 and nvc0 to implement hardware fencing,
earlier systems will require more thought but can fall back to
software for now.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/nouveau
From: Maarten Lankhorst maarten.lankho...@canonical.com
Create a dma object for the prime semaphore and every imported sync bo.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/nouveau/nv84_fence.c | 121 --
1 file changed
From: Maarten Lankhorst maarten.lankho...@canonical.com
Create a read-only mapping for every imported bo, and create a prime
bo in in system memory.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/nouveau/nvc0_fence.c | 104
From: Maarten Lankhorst maarten.lankho...@canonical.com
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 121 +++--
1 file changed, 116 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau
borrowed from Maarten Lankhorst.
NOTE: the memory location fence is not implemented yet, the above is
just for explaining how it would work.
On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
NOTIFY_INTR, but that might have been
removed on fermi, so instead I'm using invalid command
0x0058 now as a way to signal completion.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/nouveau/nouveau_drv.h |2 +
drivers/gpu/drm/nouveau/nouveau_fence.c | 49
Hey,
Op 14-07-12 00:56, Maarten Maathuis schreef:
On Fri, Jul 13, 2012 at 11:35 PM, Maarten Lankhorst
m.b.lankho...@gmail.com wrote:
A way to trigger an irq will be needed for optimus support since
cpu-waiting isn't always viable there. This could also be nice for
power saving on since cpu
Hey,
Op 13-07-12 20:52, Rob Clark schreef:
On Fri, Jul 13, 2012 at 12:35 PM, Tom Cooksey tom.cook...@arm.com wrote:
My other thought is around atomicity. Could this be extended to
(safely) allow for hardware devices which might want to access
multiple buffers simultaneously? I think it
Hey,
Op 14-07-12 23:42, Baurzhan Ismagulov schreef:
Hello David,
Samsung 2443BW is 1920x1200 but reports 1920x1080 in the EDID. Attached
is a proof-of-concept implementation of a quirk. It works on my i686 PC.
The patch is against the latest linux-2.6. An attempt to clone
Op 16-07-12 11:49, Baurzhan Ismagulov schreef:
On Mon, Jul 16, 2012 at 11:13:09AM +0200, Maarten Lankhorst wrote:
Samsung 2443BW is 1920x1200 but reports 1920x1080 in the EDID. Attached
is a proof-of-concept implementation of a quirk. It works on my i686 PC.
The patch is against the latest
Op 16-07-12 13:00, Baurzhan Ismagulov schreef:
On Mon, Jul 16, 2012 at 12:13:14PM +0200, Maarten Lankhorst wrote:
Samsung 2443BW is 1920x1200 but reports 1920x1080 in the EDID. Attached
is a proof-of-concept implementation of a quirk. It works on my i686 PC.
The patch is against the latest
Hey Rob,
Op 13-07-12 17:38, Rob Clark schreef:
...
+/**
+ * dma_buf_attach_fence - Attach a fence to a dma-buf.
+ *
+ * @buf: the dma-buf to attach to
+ * @fence: the fence to attach
+ *
+ * A fence can only be attached to a single dma-buf. The dma-buf takes
+ * ownership of the fence,
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
dma-buf-mgr handles the case of reserving single or multiple dma-bufs
while trying to prevent deadlocks from buffers being reserved
simultaneously. For this to happen extra functions have been introduced:
+ dma_buf_reserve
this mechanism. It is useful to expose
this for graphics cards that have an op to support this.
Some cards like i915 can export those, but don't have an option to wait,
so they need the software fallback.
I extended the original patch by Rob Clark.
Signed-off-by: Maarten Lankhorst maarten.lankho
decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
---
drivers/base/Makefile |2
drivers/base/dma-fence.c | 317
)); in
nouveau_vblank_enable and/or return -EINVAL in that case?
If you add the modification to nouveau_vblank_enable:
Reviewed-by: Maarten Lankhorst maarten.lankho...@canonical.com
~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http
Hey Sumit,
Op 06-08-12 08:41, Sumit Semwal schreef:
Hi Maarten,
On 27 July 2012 19:09, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
A dma-fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
-in w/ dma-buf.. after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten
this mechanism. It is useful to expose
this for graphics cards that have an op to support this.
Some cards like i915 can export those, but don't have an option to wait,
so they need the software fallback.
I extended the original patch by Rob Clark.
Signed-off-by: Maarten Lankhorst maarten.lankho
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
dma-buf-mgr handles the case of reserving single or multiple dma-bufs
while trying to prevent deadlocks from buffers being reserved
simultaneously. For this to happen extra functions have been introduced:
+ dma_buf_reserve
Op 07-08-12 19:53, Maarten Lankhorst schreef:
A dma-fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device. For example, userspace can call page_flip ioctl to display the
next frame of graphics after
Hey Sumit,
Op 08-08-12 08:35, Sumit Semwal schreef:
Hi Maarten,
On 8 August 2012 00:17, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
Op 07-08-12 19:53, Maarten Lankhorst schreef:
A dma-fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace
Documentation says that code requiring dma-buf should add it to
select, so inline fallbacks are not going to be used. A link error
will make it obvious what went wrong, instead of silently doing
nothing at runtime.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
include
-in w/ dma-buf.. after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten
-fence.c since
not much was left of the file. Lots of documentation added.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/base/dma-fence.c | 21 +++
include/linux/dma-fence.h | 61 +
2 files changed, 82
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
dma-buf-mgr handles the case of reserving single or multiple dma-bufs
while trying to prevent deadlocks from buffers being reserved
simultaneously. For this to happen extra functions have been introduced:
+ dma_buf_reserve
Hey,
Op 11-08-12 17:14, Rob Clark schreef:
On Fri, Aug 10, 2012 at 3:29 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Fri, Aug 10, 2012 at 04:57:52PM +0200, Maarten Lankhorst wrote:
A dma-fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass
Hey,
Op 11-08-12 21:39, Daniel Vetter schreef:
+
+ if (!ret) {
+ cb-base.flags = 0;
+ cb-base.func = __dma_fence_wake_func;
+ cb-base.private = priv;
+ cb-fence = fence;
+ cb-func = func;
+
Nobody uses it, so might as well simplify the code some.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 36f4b28..ddfe393 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm
How is this different from just calling with no_wait == false?
As far as I can tell, both paths end up with the same result..
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/cirrus/cirrus_drv.h |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h
b/drivers/gpu/drm/cirrus/cirrus_drv.h
index 64ea597..5d04564 100644
--- a/drivers/gpu/drm/cirrus
The removed member is unneeded, an extra pass is done after all
buffers have been reserved. The behavior stays the same even without
the removed member, but this makes the code slightly more readable.
Depends on previous 2 execbuf-util patches.
Signed-off-by: Maarten Lankhorst maarten.lankho
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/ast/ast_drv.h |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index d4af9ed..20a437f 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/mgag200/mgag200_drv.h |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h
b/drivers/gpu/drm/mgag200/mgag200_drv.h
index 6f13b35..d22cbbf 100644
--- a/drivers/gpu/drm
Hey,
Op 20-08-12 17:15, Jerome Glisse schreef:
On Mon, Aug 20, 2012 at 9:42 AM, Maarten Lankhorst
maarten.lankho...@canonical.com wrote:
How is this different from just calling with no_wait == false?
As far as I can tell, both paths end up with the same result..
Signed-off-by: Maarten
Hey Dan,
Op 16-08-12 01:12, Daniel Vetter schreef:
Hi Maarten,
Ok, here comes the promised review (finally!), but it's rather a
high-level thingy. I've mostly thought about how we could create a neat
api with the following points. For a bit of clarity, I've grouped the
different
Hey,
Op 22-08-12 14:52, Thomas Hellstrom schreef:
Hi, Maarten,
please see some comments inline.
On 08/22/2012 01:50 PM, Maarten Lankhorst wrote:
Hey Dan,
Op 16-08-12 01:12, Daniel Vetter schreef:
Hi Maarten,
Ok, here comes the promised review (finally!), but it's rather a
high-level
Hey Thomas,
I'm playing around with moving reservations from ttm to global, but how ttm
ttm is handling reservations is getting in the way. The code wants to move
the bo from the lru lock at the same time a reservation is made, but that
seems to be slightly too strict. It would really help me if
Op 12-09-12 15:28, Thomas Hellstrom schreef:
On 09/12/2012 02:48 PM, Maarten Lankhorst wrote:
Hey Thomas,
I'm playing around with moving reservations from ttm to global, but how ttm
ttm is handling reservations is getting in the way. The code wants to move
the bo from the lru lock
Op 14-09-12 12:50, Thomas Hellström schreef:
Hi Maarten!
Broadening the audience a bit..
On 9/14/12 9:12 AM, Maarten Lankhorst wrote:
Op 13-09-12 23:00, Thomas Hellstrom schreef:
On 09/13/2012 07:13 PM, Maarten Lankhorst wrote:
Hey
Op 13-09-12 18:41, Thomas Hellstrom schreef:
On 09/13
|| !attach-dmabuf || !sg_table))
return;
Looks good to me!
Reviewed-by: Maarten Lankhorst maarten.lankho...@canonical.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Documentation says that code requiring dma-buf should add it to
select, so inline fallbacks are not going to be used. A link error
will make it obvious what went wrong, instead of silently doing
nothing at runtime.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
include
to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
about checking
-fence.c since
not much was left of the file. Lots of documentation added.
v3: Use fence_ops instead of custom callbacks. Moved to own file
to avoid circular dependency between dma-buf.h and fence.h
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
Documentation/DocBook/device
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
The self-tests will fail if the commit lockdep: Check if nested
lock is actually held from linux tip core/locking is not applied.
---
drivers/base/reservation.c | 46 +-
include/linux/reservation.h | 29 +++-
lib
Hey,
Op 28-09-12 14:41, Maarten Lankhorst schreef:
Documentation says that code requiring dma-buf should add it to
select, so inline fallbacks are not going to be used. A link error
will make it obvious what went wrong, instead of silently doing
nothing at runtime.
The whole patch
Op 28-09-12 17:29, Thomas Hellström schreef:
On 9/28/12 2:43 PM, Maarten Lankhorst wrote:
This adds support for a generic reservations framework that can be
hooked up to ttm and dma-buf and allows easy sharing of reservations
across devices.
The idea is that a dma-buf and ttm object both
Op 28-09-12 22:10, Thomas Hellstrom schreef:
On 09/28/2012 09:42 PM, Thomas Hellstrom wrote:
On 09/28/2012 04:14 PM, Maarten Lankhorst wrote:
Hey,
Op 28-09-12 14:41, Maarten Lankhorst schreef:
Documentation says that code requiring dma-buf should add it to
select, so inline fallbacks
Op 28-09-12 21:42, Thomas Hellstrom schreef:
On 09/28/2012 04:14 PM, Maarten Lankhorst wrote:
Hey,
Op 28-09-12 14:41, Maarten Lankhorst schreef:
Documentation says that code requiring dma-buf should add it to
select, so inline fallbacks are not going to be used. A link error
will make
Hey,
Bit late reply, hopefully not too late.
Op 30-08-12 16:00, Tom Cooksey schreef:
Hi All,
Over the last few months I've been working on off with a few people from
Linaro on a new EGL extension. The extension allows constructing an EGLImage
from a (set of) dma_buf file descriptors,
Hey,
Op 03-10-12 09:45, Thomas Hellstrom schreef:
On 10/02/2012 10:03 AM, Daniel Vetter wrote:
On Tue, Oct 02, 2012 at 08:46:32AM +0200, Thomas Hellstrom wrote:
On 10/01/2012 11:47 AM, Maarten Lankhorst wrote:
I was doing a evil hack where I 'released' lru_lock to lockdep before
doing
Op 03-10-12 12:53, Thomas Hellstrom schreef:
On 10/03/2012 10:53 AM, Daniel Vetter wrote:
On Wed, Oct 3, 2012 at 10:37 AM, Thomas Hellstrom thellst...@vmware.com
wrote:
So if I understand you correctly, the reservation changes in TTM are
motivated by the
fact that otherwise, in the generic
Op 28-09-12 14:42, Maarten Lankhorst schreef:
A fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device. For example, userspace can call page_flip ioctl to display the
next frame of graphics after
Op 11-10-12 09:51, Hans Verkuil schreef:
my understaning is
that the drivers/media/ authors should also ack with this licensing
(possible) change. I am one of the main contributors there. Alan also has
copyrights there, and at other parts of the Linux Kernel, including the
driver's
core,
I was trying to clean ttm up a little so my changes would be less invasive, and
simplify
the code for debuggability. During testing I noticed the following weirdnesses:
- ttm_mem_evict_first ignores no_wait_gpu if the buffer is on the ddestroy list.
If you follow the code, it will effectively
Op 11-10-12 21:26, Thomas Hellstrom schreef:
On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:
Anyway, if you plan to remove the fence lock and protect it with reserve,
you must
make sure that a waiting reserve is never done in a destruction path. I
think this
mostly concerns the nvidia
Op 12-10-12 07:57, Thomas Hellstrom schreef:
On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
Op 11-10-12 21:26, Thomas Hellstrom schreef:
On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:
Anyway, if you plan to remove the fence lock and protect it with reserve,
you must
make sure
Op 12-10-12 07:57, Thomas Hellstrom schreef:
On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
Op 11-10-12 21:26, Thomas Hellstrom schreef:
On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:
Anyway, if you plan to remove the fence lock and protect it with reserve,
you must
make sure
Nobody uses it, so might as well simplify the code some.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
Reviewed-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/ttm/ttm_bo.c | 41
drivers/gpu/drm/ttm/ttm_bo_util.c
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/ttm/ttm_bo.c | 12 ++--
include/drm/ttm/ttm_bo_api.h | 14 ++
2 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/radeon/radeon_gart.c |2 +-
drivers/gpu/drm/radeon/radeon_object.c |6 +++---
drivers/gpu/drm/radeon/radeon_object.h |2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c
index 3ce68a2..bd78257 100644
It's always hardcoded to the same value.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |7 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 15 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |4
3 files
vmwgfx was its only user and always sets it to the same..
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/ttm/ttm_bo.c | 13 -
drivers/gpu/drm/ttm/ttm_bo_util.c |1 -
drivers/gpu/drm/ttm/ttm_execbuf_util.c |1 -
include
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c |2 +-
drivers/gpu/drm/radeon/radeon_ttm.c |2 +-
drivers/gpu/drm/ttm/ttm_bo_util.c|1 -
include/drm/ttm/ttm_bo_driver.h |3 ---
4 files changed, 2 insertions(+), 6
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c |6 +++---
drivers/gpu/drm/radeon/radeon_ttm.c|7 +++
drivers/gpu/drm/ttm/ttm_bo.c |6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |7 +++
include
Apart from some code inside ttm itself and nouveau_bo_vma_del,
this is the only place where ttm_bo_wait is used without a reservation.
Fix this so we can remove the fence_lock later on.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/nouveau/nouveau_gem.c
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 16
drivers/gpu/drm/nouveau/nouveau_bo.h |1 +
drivers/gpu/drm/nouveau/nouveau_gem.c |2 +-
3 files changed, 18 insertions(+), 1 deletion(-)
diff --git
This will otherwise cause a lockdep splat, so warn when nouveau
forgets to unpin a buffer, and fix up the ones I've hit.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/nouveau/nouveau_abi16.c |1 +
drivers/gpu/drm/nouveau/nouveau_fbcon.c |1
This will otherwise cause a lockdep splat, so warn when nouveau
forgets to unpin a buffer, and fix up the ones I've hit.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/nouveau/nouveau_abi16.c |1 +
drivers/gpu/drm/nouveau/nouveau_fbcon.c |1
Just use the return error from ttm_mem_evict_first instead.
Since ttm_mem_evict_first does the same check, the error message
from that function can be used.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/ttm/ttm_bo.c | 27 ---
1
Op 15-10-12 14:27, Thomas Hellstrom schreef:
On 10/12/2012 12:09 PM, Maarten Lankhorst wrote:
Op 12-10-12 07:57, Thomas Hellstrom schreef:
On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
Op 11-10-12 21:26, Thomas Hellstrom schreef:
On 10/11/2012 08:42 PM, Maarten Lankhorst wrote:
Anyway
Op 15-10-12 17:37, Maarten Lankhorst schreef:
To make multi-object reservation work, the fix is to add a ticket lock of
which all the
reservation objects are a nested lock of. Since in this case the ticket
lock would prevent
deadlocks, this is acceptable. Having 2 ticket 'locks
Op 15-10-12 20:40, Thomas Hellstrom schreef:
On 10/15/2012 05:37 PM, Maarten Lankhorst wrote:
Op 15-10-12 14:27, Thomas Hellstrom schreef:
On 10/12/2012 12:09 PM, Maarten Lankhorst wrote:
Op 12-10-12 07:57, Thomas Hellstrom schreef:
On 10/11/2012 10:55 PM, Maarten Lankhorst wrote:
Op 11-10
Hey,
Op 18-10-12 09:59, Thomas Hellstrom schreef:
On 10/18/2012 09:28 AM, Thomas Hellstrom wrote:
Hi, Maarten,
As you know I have been having my doubts about this change.
To me it seems insane to be forced to read the fence pointer under a
reserved lock, simply because when you take the
Op 18-10-12 13:02, Thomas Hellstrom schreef:
On 10/18/2012 10:37 AM, Maarten Lankhorst wrote:
Hey,
Op 18-10-12 09:59, Thomas Hellstrom schreef:
On 10/18/2012 09:28 AM, Thomas Hellstrom wrote:
Hi, Maarten,
As you know I have been having my doubts about this change.
To me it seems insane
Op 18-10-12 13:55, Thomas Hellstrom schreef:
On 10/18/2012 01:38 PM, Maarten Lankhorst wrote:
Op 18-10-12 13:02, Thomas Hellstrom schreef:
On 10/18/2012 10:37 AM, Maarten Lankhorst wrote:
Hey,
Op 18-10-12 09:59, Thomas Hellstrom schreef:
On 10/18/2012 09:28 AM, Thomas Hellstrom wrote:
Hi
Hey,
Op 05-11-12 14:31, Thomas Hellstrom schreef:
Reservation locking currently always takes place under the LRU spinlock.
Hence, strictly there is no need for an atomic_cmpxchg call; we can use
atomic_read followed by atomic_write since nobody else will ever reserve
without the lru spinlock
This is similar to other platforms that don't allow command submission
to buffers locked on the cpu.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bf6e4b5..2b3f69b 100644
--- a/drivers/gpu
Op 25-10-12 09:42, Thomas Hellstrom schreef:
On 10/12/2012 04:58 PM, Maarten Lankhorst wrote:
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/ttm/ttm_bo.c | 12 ++--
include/drm/ttm/ttm_bo_api.h | 14 ++
2 files changed, 20
Op 06-11-12 15:48, Kelly Doran schreef:
The vblank on nvc0 was not working correctly and would freeze X, I managed
to track it down and fix it with some help from m.b.lankhorst, see
https://bugs.freedesktop.org/show_bug.cgi?id=56692 for details.
Reviewed-by: Maarten Lankhorst maarten.lankho
Op 08-11-12 21:53, Paul Menzel schreef:
Dear Maarten,
thanks for the patch.
Am Donnerstag, den 08.11.2012, 17:19 +0100 schrieb Maarten Lankhorst:
Commit c0077061e7ea
Please paste the commit summary for people not having a Git tree at
hand.
The summary will go in the commit log, at which
Op 11-11-12 19:35, Marcin Slusarz schreef:
On Sun, Nov 11, 2012 at 07:26:17PM +0100, Marcin Slusarz wrote:
On Tue, Nov 06, 2012 at 07:30:00PM +0100, Maarten Lankhorst wrote:
Op 06-11-12 15:48, Kelly Doran schreef:
The vblank on nvc0 was not working correctly and would freeze X, I managed
The few places that care should have those checks instead.
This allow destruction of bo backed memory without a reservation.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/radeon/radeon_gart.c | 1 -
drivers/gpu/drm/radeon/radeon_object.c | 2 +-
2 files
move to release_list instead
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/ttm/ttm_bo.c | 47 +---
1 file changed, 14 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm
Just use the return error from ttm_mem_evict_first instead.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/ttm/ttm_bo.c | 27 ---
1 file changed, 8 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers
and ttm_bo_cleanup_refs_or_queue.
A reservation is taken first, then fence lock is taken and a wait is attempted.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
v2:
- fix conflict with upstream race fix, simplifies ttm_bo_cleanup_refs
v3:
- change removal of fence_lock to making
:
- add WARN_ON(!atomic_read(bo-kref.refcount)) in reserve to ensure
that nobody accidentally reserves a dead buffer.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/ttm/ttm_bo.c | 123 -
drivers/gpu/drm/ttm
-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/ast/ast_ttm.c| 10 +++---
drivers/gpu/drm/cirrus/cirrus_ttm.c | 10 +++---
drivers/gpu/drm/mgag200/mgag200_ttm.c| 10 +++---
drivers/gpu/drm/nouveau/nouveau_bo.c | 55
1 - 100 of 2608 matches
Mail list logo
