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 the
annotation
for a blocking acquire, and left trylock
On 10/03/2012 09:57 AM, Maarten Lankhorst wrote:
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
On 10/03/2012 09:54 AM, Daniel Vetter wrote:
On Wed, Oct 3, 2012 at 9:45 AM, Thomas Hellstrom thellst...@vmware.com wrote:
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
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 reservation code, lockdep can only be
annotated
I took a quick look on the fencing and added some thoughts on
shared fences:
On 09/28/2012 02: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
On 10/03/2012 02:46 PM, Maarten Lankhorst wrote:
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
TTM base objects will be the first consumer.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
drivers/gpu/drm/drm_hashtab.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index
cycle on successful
reserve.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
drivers/gpu/drm/ttm/ttm_bo.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bf6e4b5..46008ea 100644
--- a/drivers
-off-by: Thomas Hellstrom thellst...@vmware.com
---
drivers/gpu/drm/ttm/ttm_object.c | 30 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |8
include/drm/ttm/ttm_object.h |4
include/linux/kref.h |2 +-
4
trivial.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
include/linux/kref.h | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/include/linux/kref.h b/include/linux/kref.h
index 65af688..fd16042 100644
--- a/include/linux/kref.h
+++ b/include
A patch series for next that removes a substantial number of read-modify-write
operations from TTM command submission, in particular if TTM objects are used
to export objects to user-space. The only per-object atomic r-m-w operations
left during a typical execbuf call should be refcount up and
On 11/05/2012 02:31 PM, Thomas Hellstrom wrote:
The mostly used lookup+get put+potential_destroy path of TTM objects
is converted to use RCU locks. This will substantially decrease the amount
of locked bus cycles during normal operation.
Since we use kfree_rcu to free the objects, no rcu
and down.
v2: Formatting fixes.
In-Reply-To:
From Thomas Hellstrom thellst...@vmware.com # This line is ignored.
From: Thomas Hellstrom thellst...@vmware.com
Subject:
In-Reply-To:
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord
TTM base objects will be the first consumer.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
drivers/gpu/drm/drm_hashtab.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index
trivial.
v2: Formatting fixes.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
include/linux/kref.h | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/include/linux/kref.h b/include/linux/kref.h
index 65af688..bae91d0 100644
--- a/include/linux
cycle on successful
reserve.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
drivers/gpu/drm/ttm/ttm_bo.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bf6e4b5..46008ea 100644
--- a/drivers
: Don't touch include/linux/kref.h
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
drivers/gpu/drm/ttm/ttm_object.c | 30 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |8
include/drm/ttm/ttm_object.h |4
3 files changed
On 11/05/2012 03:01 PM, Maarten Lankhorst wrote:
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
A patch series for next that removes a substantial number of read-modify-write
operations from TTM command submission, in particular if TTM objects are used
to export objects to user-space. The only per-object atomic r-m-w operations
left during a typical execbuf call should be refcount up and
TTM base objects will be the first consumer.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
drivers/gpu/drm/drm_hashtab.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index
trivial.
v2: Formatting fixes.
v3: Invert the return value.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
include/linux/kref.h | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/include/linux/kref.h b/include/linux/kref.h
index 65af688..4972e6e
: Don't touch include/linux/kref.h
v3: Adapt to kref_get_unless_zero return value change
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
drivers/gpu/drm/ttm/ttm_object.c | 30 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |8
include/drm/ttm
cycle on successful
reserve.
Note that thit commit may be obsoleted by the cross-device reservation work.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
drivers/gpu/drm/ttm/ttm_bo.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
);
- preempt_enable();
set_page_dirty(to_page);
mark_page_accessed(to_page);
page_cache_release(to_page);
Reviewed-by: Thomas Hellstrom thellst...@vmware.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+/*
+ * Authors: Thomas Hellstrom thellstrom-at-vmware-dot-com
+ */
+
+#include linux/dma-fence.h
+#include linux/dma
On 08/22/2012 03:32 PM, Maarten Lankhorst wrote:
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
On 11/20/2012 07:19 AM, Dave Airlie wrote:
On Tue, Nov 6, 2012 at 9:31 PM, Thomas Hellstrom thellst...@vmware.com wrote:
The mostly used lookup+get put+potential_destroy path of TTM objects
is converted to use RCU locks. This will substantially decrease the amount
of locked bus cycles during
On 11/28/2012 02:33 PM, Lucas Stach wrote:
Am Mittwoch, den 28.11.2012, 15:17 +0200 schrieb Terje Bergström:
On 28.11.2012 01:00, Dave Airlie wrote:
We generally aim for the first, to stop the gpu from reading/writing
any memory it hasn't been granted access to,
the second is nice to have
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 it obvious what went wrong, instead of silently doing
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 are not going to be used. A link error
will make
On 09/29/2012 05:16 PM, Maarten Lankhorst wrote:
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
On 10/01/2012 11:47 AM, Maarten Lankhorst wrote:
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
On 09/12/2013 05:58 PM, Daniel Vetter wrote:
On Thu, Sep 12, 2013 at 5:43 PM, Peter Zijlstra pet...@infradead.org wrote:
The one in ttm is just bonghits to shut up lockdep: ttm can recurse
into it's own pagefault handler and then deadlock, the trylock just
keeps lockdep quiet.
Could you
On 09/12/2013 05:45 PM, Maarten Lankhorst wrote:
Op 12-09-13 17:36, Daniel Vetter schreef:
On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra pet...@infradead.org wrote:
So I'm poking around the preemption code and stumbled upon:
drivers/gpu/drm/i915/i915_gem.c:
On 09/12/2013 10:39 PM, Thomas Gleixner wrote:
On Thu, 12 Sep 2013, Daniel Vetter wrote:
On Thu, Sep 12, 2013 at 10:20 PM, Thomas Gleixner t...@linutronix.de wrote:
I think for ttm drivers it's just execbuf being exploitable. But on
drm/i915 we've
had the same issue with the pwrite/pread
On 09/12/2013 11:50 PM, Maarten Lankhorst wrote:
Op 12-09-13 18:44, Thomas Hellstrom schreef:
On 09/12/2013 05:45 PM, Maarten Lankhorst wrote:
Op 12-09-13 17:36, Daniel Vetter schreef:
On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra pet...@infradead.org wrote:
So I'm poking around
On 09/12/2013 11:50 PM, Maarten Lankhorst wrote:
Op 12-09-13 18:44, Thomas Hellstrom schreef:
On 09/12/2013 05:45 PM, Maarten Lankhorst wrote:
Op 12-09-13 17:36, Daniel Vetter schreef:
On Thu, Sep 12, 2013 at 5:06 PM, Peter Zijlstra pet...@infradead.org wrote:
So I'm poking around
On 09/13/2013 09:16 AM, Maarten Lankhorst wrote:
Op 13-09-13 08:44, Thomas Hellstrom schreef:
On 09/12/2013 11:50 PM, Maarten Lankhorst wrote:
Op 12-09-13 18:44, Thomas Hellstrom schreef:
On 09/12/2013 05:45 PM, Maarten Lankhorst wrote:
Op 12-09-13 17:36, Daniel Vetter schreef:
On Thu, Sep
On 09/13/2013 09:51 AM, Maarten Lankhorst wrote:
Op 13-09-13 09:46, Thomas Hellstrom schreef:
On 09/13/2013 09:16 AM, Maarten Lankhorst wrote:
Op 13-09-13 08:44, Thomas Hellstrom schreef:
On 09/12/2013 11:50 PM, Maarten Lankhorst wrote:
Op 12-09-13 18:44, Thomas Hellstrom schreef:
On 09/12
On 09/13/2013 10:32 AM, Daniel Vetter wrote:
On Fri, Sep 13, 2013 at 10:23 AM, Thomas Hellstrom
thellst...@vmware.com wrote:
As previously mentioned, copy_from_user should return -EFAULT, since the
VMAs are marked with VM_IO. It should not recurse into fault(), so evil
user-space looses.
I
On 09/13/2013 10:58 AM, Maarten Lankhorst wrote:
Op 13-09-13 10:23, Thomas Hellstrom schreef:
On 09/13/2013 09:51 AM, Maarten Lankhorst wrote:
Op 13-09-13 09:46, Thomas Hellstrom schreef:
On 09/13/2013 09:16 AM, Maarten Lankhorst wrote:
Op 13-09-13 08:44, Thomas Hellstrom schreef:
On 09/12
Anyone else but me that feels such a function could be useful?
My main use-case is that it would resolve the mutual refcounting problem:
1) drm buffer object caches a dma_buf pointer which it refcounts
2) The dma-buf holds a refcount to the buffer.
This is resolved today by having the
the attached file for refcounting,
get_dma_buf_unless_doomed maps directly to a get_file_unless_doomed.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
include/linux/dma-buf.h | 16
include/linux/fs.h | 15 +++
2 files changed, 31 insertions(+)
diff --git
On 11/08/2013 09:06 AM, Daniel Vetter wrote:
On Thu, Nov 07, 2013 at 11:18:54PM -0800, Thomas Hellstrom wrote:
In this context, a doomed object is an object whose refcount has reached
zero, but that has not yet been freed.
To avoid mutual refcounting vmwgfx need to have a non-refcounted
On 11/22/2013 05:18 PM, Daniel Vetter wrote:
On Fri, Nov 22, 2013 at 4:54 PM, Thomas Meyer tho...@m3y3r.de wrote:
Am 22.11.2013 um 11:55 schrieb Daniel Vetter dan...@ffwll.ch:
On Fri, Nov 22, 2013 at 11:36 AM, Dave Airlie airl...@linux.ie wrote:
Hi,
cc'ing mailing list,
Daniel any ideas?
kobject_get_unless_zero() and its commit message.
Since dma-bufs are using the attached file for refcounting,
get_dma_buf_unless_doomed maps directly to a get_file_unless_doomed.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
include/linux/dma-buf.h | 16
include/linux
On 11/11/2013 04:17 PM, Al Viro wrote:
On Mon, Nov 11, 2013 at 12:57:47AM -0800, Thomas Hellstrom wrote:
Resending since it appears this RFC never got to the dri-devel lkml lists.
In this context, a doomed object is an object whose refcount has reached
zero, but that has not yet been freed
On 11/08/2013 06:28 PM, Daniel Vetter wrote:
On Fri, Nov 8, 2013 at 9:50 AM, Thomas Hellstrom thellst...@vmware.com wrote:
This, however comes with two implications
1) Once a DMA-buf is added, it stays alive at least until someone removes
the gem name of the exporting object, regardless whether
A callback similar to page_mkwrite except it will be called before making
ptes that don't point to normal pages writable.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
include/linux/mm.h |9 +
mm/memory.c| 52
and it will not work with nonlinear VMAs.
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
include/linux/mm.h |3 ++
mm/memory.c| 108
2 files changed, 111 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index
Hi!
Before going any further with this I'd like to check whether this is an
acceptable way to go.
Background:
GPU buffer objects in general and vmware svga GPU buffers in
particular are mapped by user-space using MIXEDMAP or PFNMAP. Sometimes the
address space is backed by a set of pages,
code with apply_to_page_range().
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
mm/memory.c | 73 +++
1 file changed, 48 insertions(+), 25 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 8ae9a6e..79178c2 100644
On 11/19/2013 11:51 PM, Andy Lutomirski wrote:
On 11/19/2013 12:06 PM, Thomas Hellstrom wrote:
Hi!
Before going any further with this I'd like to check whether this is an
acceptable way to go.
Background:
GPU buffer objects in general and vmware svga GPU buffers in
particular are mapped
On 11/20/2013 05:50 PM, Andy Lutomirski wrote:
On Wed, Nov 20, 2013 at 12:12 AM, Thomas Hellstrom
thellst...@vmware.com wrote:
On 11/19/2013 11:51 PM, Andy Lutomirski wrote:
On 11/19/2013 12:06 PM, Thomas Hellstrom wrote:
Hi!
Before going any further with this I'd like to check whether
On 02/28/2014 10:20 PM, Alexey Khoroshilov wrote:
vmw_takedown_otable_base() and vmw_mob_unbind() check for
potential vmw_fifo_reserve() failure and print error message,
but then immediately dereference NULL pointer.
Found by Linux Driver Verification project (linuxtesting.org).
On 02/12/2014 02:46 PM, Masanari Iida wrote:
This patch fix a memory leak found by cppcheck.
[drivers/gpu/drm/ttm/ttm_agp_backend.c:129]:
(error) Memory leak: agp_be
Signed-off-by: Masanari Iida standby2...@gmail.com
---
drivers/gpu/drm/ttm/ttm_agp_backend.c | 1 +
1 file changed, 1
On 02/17/2014 04:57 PM, Maarten Lankhorst wrote:
Android syncpoints can be mapped to a timeline. This removes the need
to maintain a separate api for synchronization. I've left the android
trace events in place, but the core fence events should already be
sufficient for debugging.
v2:
-
...@samsung.com
#drivers/media/v4l2-core/
For the TTM part:
Acked-by: Thomas Hellstrom thellst...@vmware.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
On 10/08/2013 04:55 PM, Jerome Glisse wrote:
On Tue, Oct 08, 2013 at 04:45:18PM +0200, Christian König wrote:
Am 08.10.2013 16:33, schrieb Jerome Glisse:
On Tue, Oct 08, 2013 at 04:14:40PM +0200, Maarten Lankhorst wrote:
Allocate and copy all kernel memory before doing reservations. This
On 10/08/2013 06:47 PM, Jerome Glisse wrote:
On Tue, Oct 08, 2013 at 06:29:35PM +0200, Thomas Hellstrom wrote:
On 10/08/2013 04:55 PM, Jerome Glisse wrote:
On Tue, Oct 08, 2013 at 04:45:18PM +0200, Christian König wrote:
Am 08.10.2013 16:33, schrieb Jerome Glisse:
On Tue, Oct 08, 2013 at 04
On 09/23/2013 05:33 PM, Maarten Lankhorst wrote:
Hey,
Op 13-09-13 11:00, Peter Zijlstra schreef:
On Fri, Sep 13, 2013 at 10:41:54AM +0200, Daniel Vetter wrote:
On Fri, Sep 13, 2013 at 10:29 AM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, Sep 13, 2013 at 09:46:03AM +0200, Thomas
On 09/24/2013 09:34 AM, Maarten Lankhorst wrote:
Op 24-09-13 09:22, Thomas Hellstrom schreef:
On 09/23/2013 05:33 PM, Maarten Lankhorst wrote:
Hey,
Op 13-09-13 11:00, Peter Zijlstra schreef:
On Fri, Sep 13, 2013 at 10:41:54AM +0200, Daniel Vetter wrote:
On Fri, Sep 13, 2013 at 10:29 AM
On 09/24/2013 12:11 PM, Maarten Lankhorst wrote:
Op 24-09-13 11:36, Daniel Vetter schreef:
On Tue, Sep 24, 2013 at 11:03:37AM +0200, Thomas Hellstrom wrote:
On 09/24/2013 09:34 AM, Maarten Lankhorst wrote:
Op 24-09-13 09:22, Thomas Hellstrom schreef:
On 09/23/2013 05:33 PM, Maarten Lankhorst
On 09/24/2013 01:32 PM, Maarten Lankhorst wrote:
Op 24-09-13 12:33, Thomas Hellstrom schreef:
On 09/24/2013 12:11 PM, Maarten Lankhorst wrote:
It seems userspace only updates offset and domain in nouveau. If it fails to
update
it would result in the same affect as when the buffer gets moved
On 09/24/2013 11:43 AM, Maarten Lankhorst wrote:
Op 24-09-13 11:03, Thomas Hellstrom schreef:
On 09/24/2013 09:34 AM, Maarten Lankhorst wrote:
Op 24-09-13 09:22, Thomas Hellstrom schreef:
Actually, it's not the locking order bo:reserve - mmap_sem that triggers the
lockdep warning, right
On 05/19/2014 03:13 PM, Maarten Lankhorst wrote:
op 19-05-14 15:42, Thomas Hellstrom schreef:
Hi, Maarten!
Some nitpicks, and that krealloc within rcu lock still worries me.
Otherwise looks good.
/Thomas
On 04/23/2014 12:15 PM, Maarten Lankhorst wrote:
@@ -55,8 +60,8 @@ int
Hi, Maarten!
Some nitpicks, and that krealloc within rcu lock still worries me.
Otherwise looks good.
/Thomas
On 04/23/2014 12:15 PM, Maarten Lankhorst wrote:
This adds 4 more functions to deal with rcu.
reservation_object_get_fences_rcu() will obtain the list of shared
and exclusive
On 05/19/2014 03:13 PM, Maarten Lankhorst wrote:
op 19-05-14 15:42, Thomas Hellstrom schreef:
Hi, Maarten!
Some nitpicks, and that krealloc within rcu lock still worries me.
Otherwise looks good.
/Thomas
On 04/23/2014 12:15 PM, Maarten Lankhorst wrote:
@@ -55,8 +60,8 @@ int
On 01/31/2014 04:25 PM, Vlastimil Babka wrote:
On 01/31/2014 03:58 PM, Thomas Hellstrom wrote:
On 01/31/2014 03:40 PM, Vlastimil Babka wrote:
On 01/15/2014 05:06 PM, Daniel Borkmann wrote:
[keeping netdev in loop as well]
On 01/15/2014 03:27 PM, Vlastimil Babka wrote:
On 01/13/2014 12:39 PM
On 01/31/2014 03:27 AM, Dave Jones wrote:
One of the error paths in vmw_setup_otable_base causes us to return with
'ret' having never been set to anything causing us to return whatever was
on the stack.
Found with Coverity
Signed-off-by: Dave Jones da...@fedoraproject.org
diff --git
Patch 78-80/85
Reviewed-by: Thomas Hellstrom thellst...@vmware.com
Queued for ttm-next.
Thanks.
Thomas
On 01/06/2014 05:42 PM, Rashika Kheria wrote:
Mark function as static because it is not used outside file
drm/ttm/ttm_bo.c.
This eliminates the following warning in drm/ttm/ttm_bo.c
On 01/07/2014 11:51 AM, Josh Triplett wrote:
On Tue, Jan 07, 2014 at 11:21:12AM +0100, Jakob Bornecrantz wrote:
On Mon, Jan 6, 2014 at 5:48 PM, Rashika Kheria rashika.khe...@gmail.com
wrote:
Mark functions as static because they are not used outside the file
drm/vmwgfx/vmwgfx_kms.c.
This
On 01/31/2014 03:40 PM, Vlastimil Babka wrote:
On 01/15/2014 05:06 PM, Daniel Borkmann wrote:
[keeping netdev in loop as well]
On 01/15/2014 03:27 PM, Vlastimil Babka wrote:
On 01/13/2014 12:39 PM, Daniel Borkmann wrote:
On 01/13/2014 11:16 AM, Vlastimil Babka wrote:
On 01/11/2014 02:32 PM,
On 12/12/2013 03:36 PM, Thierry Reding wrote:
This is a simple test module that can be used to allocate, export and
delete DMA-BUF objects. It can be used to test DMA-BUF sharing in
systems that lack a real second driver.
Looks nice. I wonder whether this could be extended to create a
On 12/14/2013 01:37 PM, Thierry Reding wrote:
On Thu, Dec 12, 2013 at 11:30:23PM +0100, Daniel Vetter wrote:
On Thu, Dec 12, 2013 at 8:34 PM, Thomas Hellstrom thellst...@vmware.com wrote:
On 12/12/2013 03:36 PM, Thierry Reding wrote:
This is a simple test module that can be used to allocate
On 12/14/2013 02:02 PM, Rob Clark wrote:
On Sat, Dec 14, 2013 at 7:47 AM, Thomas Hellstrom tho...@shipmail.org wrote:
On 12/14/2013 01:37 PM, Thierry Reding wrote:
On Thu, Dec 12, 2013 at 11:30:23PM +0100, Daniel Vetter wrote:
On Thu, Dec 12, 2013 at 8:34 PM, Thomas Hellstrom thellst
', and 'extra' should be in 'id' group and the
rest of attributes should be attached directly to the device.
Thanks for doing this. Makes vmmouse work again.
Reported-by: Thomas Hellstrom thellst...@vmware.com
Signed-off-by: Dmitry Torokhov dmitry.torok...@gmail.com
Tested-by: Thomas Hellstrom
On 04/29/2014 04:32 PM, Maarten Lankhorst wrote:
op 23-04-14 13:15, Maarten Lankhorst schreef:
This adds 4 more functions to deal with rcu.
reservation_object_get_fences_rcu() will obtain the list of shared
and exclusive fences without obtaining the ww_mutex.
Hi!
Ugh. This became more complicated than I thought, but I'm OK with moving
TTM over to fence while we sort out
how / if we're going to use this.
While reviewing, it struck me that this is kind of error-prone, and hard
to follow since we're operating on a structure that may be
continually
On 04/10/2014 12:07 PM, Maarten Lankhorst wrote:
Hey,
op 10-04-14 10:46, Thomas Hellstrom schreef:
Hi!
Ugh. This became more complicated than I thought, but I'm OK with moving
TTM over to fence while we sort out
how / if we're going to use this.
While reviewing, it struck me
On 04/10/2014 01:08 PM, Thomas Hellstrom wrote:
On 04/10/2014 12:07 PM, Maarten Lankhorst wrote:
Hey,
op 10-04-14 10:46, Thomas Hellstrom schreef:
Hi!
Ugh. This became more complicated than I thought, but I'm OK with moving
TTM over to fence while we sort out
how / if we're going to use
in the
reservation_object_get_fences_rcu() function below:
On 04/10/2014 05:00 PM, Maarten Lankhorst wrote:
op 10-04-14 13:08, Thomas Hellstrom schreef:
On 04/10/2014 12:07 PM, Maarten Lankhorst wrote:
Hey,
op 10-04-14 10:46, Thomas Hellstrom schreef:
Hi!
Ugh. This became more complicated than I thought, but I'm
On 04/11/2014 11:24 AM, Maarten Lankhorst wrote:
op 11-04-14 10:38, Thomas Hellstrom schreef:
Hi, Maarten.
Here I believe we encounter a lot of locking inconsistencies.
First, it seems you're use a number of pointers as RCU pointers without
annotating them as such and use the correct rcu
Hi,
as was discussed a while ago, there are some serious security flaws with
the current drm master model, that allows a
user that had previous access or current access to an X server terminal
to access the GPU memory of the active X server, without being
authenticated to the X server and thereby
Hi!
On 04/11/2014 08:09 PM, Maarten Lankhorst wrote:
op 11-04-14 12:11, Thomas Hellstrom schreef:
On 04/11/2014 11:24 AM, Maarten Lankhorst wrote:
op 11-04-14 10:38, Thomas Hellstrom schreef:
Hi, Maarten.
Here I believe we encounter a lot of locking inconsistencies.
First, it seems you're
On 04/11/2014 08:09 PM, Maarten Lankhorst wrote:
op 11-04-14 12:11, Thomas Hellstrom schreef:
On 04/11/2014 11:24 AM, Maarten Lankhorst wrote:
op 11-04-14 10:38, Thomas Hellstrom schreef:
Hi, Maarten.
Here I believe we encounter a lot of locking inconsistencies.
First, it seems you're use
On 04/11/2014 10:31 PM, David Herrmann wrote:
Hi
On Fri, Apr 11, 2014 at 2:42 PM, Thomas Hellstrom thellst...@vmware.com
wrote:
as was discussed a while ago, there are some serious security flaws with
the current drm master model, that allows a
user that had previous access or current
On 04/14/2014 09:42 AM, Maarten Lankhorst wrote:
op 11-04-14 21:35, Thomas Hellstrom schreef:
On 04/11/2014 08:09 PM, Maarten Lankhorst wrote:
op 11-04-14 12:11, Thomas Hellstrom schreef:
On 04/11/2014 11:24 AM, Maarten Lankhorst wrote:
op 11-04-14 10:38, Thomas Hellstrom schreef:
Hi
On 04/14/2014 02:41 PM, One Thousand Gnomes wrote:
throw out all GPU memory on master drop and block ioctls requiring
authentication until master becomes active again.
If you have a per driver method then the driver can implement whatever is
optimal (possibly including throwing it all out).
. The patch
corrects that behaviour.
See https://bugs.gentoo.org/show_bug.cgi?id=494794 for examples.
Just adding cc's of maintainer list.
Looks correct to me.
Reviewed-by: Thomas Hellstrom thellst...@vmware.com
Will add it to vmgfx-next and cc stable.
Thanks,
Thomas
Signed-off-by: Christopher
On 06/30/2014 12:19 PM, Christopher Friedt wrote:
On Apr 1, 2014 6:00 AM, Thomas Hellstrom thellst...@vmware.com
mailto:thellst...@vmware.com wrote:
On 03/28/2014 02:45 AM, Dave Airlie wrote:
On Fri, Mar 28, 2014 at 10:45 AM, Christopher Friedt
chrisfri...@gmail.com mailto:chrisfri
On 06/30/2014 02:25 PM, Christopher Friedt wrote:
On Mon, Jun 30, 2014 at 7:48 AM, Thomas Hellstrom thellst...@vmware.com
wrote:
I don't think we can blame video-vmware for this. A kernel driver change
that breaks existing user-space is by definition a kernel driver bug,
regardless whether
On 06/30/2014 02:49 PM, Christopher Friedt wrote:
On Mon, Jun 30, 2014 at 8:39 AM, Thomas Hellstrom thellst...@vmware.com
wrote:
xf86-video-vmware in kms mode uses the kernel driver to set these registers.
FWIW, the modesetting part of the kernel driver uses SVGA_REG_PITCHLOCK
instead
On 06/30/2014 03:18 PM, Christopher Friedt wrote:
On Mon, Jun 30, 2014 at 8:49 AM, Christopher Friedt
chrisfri...@gmail.com wrote:
That sounds a bit more accurate. Should kms and fbdev be setting both
registers then?
I wonder if fbdev can use PITCHLOCK as well, rather than
BYTES_PER_LINE. I
carefully. The reason the parameter is passed
might be some historical one or clarity of which drm_open_hash
we remove an item from.
Reasons for this are probably lost. On the patch:
Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch
Acked-by: Thomas Hellstrom thellst...@vmware.com
Aside: Imo we
On 07/02/2014 05:01 AM, Christopher Friedt wrote:
I have been unable to reproduce this issue in a plethora of test
cases, although granted, I do not have access to a Win7 machine. For
that, I have asked an Ubuntu tester to run through some tests for me.
Hi.
IIRC I don't think the TTM DMA pool allocates coherent pages more than
one page at a time, and _if that's true_ it's pretty unnecessary for the
dma subsystem to route those allocations to CMA. Maybe Konrad could shed
some light over this?
/Thomas
On 08/08/2014 07:42 PM, Mario Kleiner
On 08/09/2014 03:33 PM, Konrad Rzeszutek Wilk wrote:
On August 9, 2014 1:39:39 AM EDT, Thomas Hellstrom thellst...@vmware.com
wrote:
Hi.
Hey Thomas!
IIRC I don't think the TTM DMA pool allocates coherent pages more than
one page at a time, and _if that's true_ it's pretty unnecessary
On 08/10/2014 05:11 AM, Mario Kleiner wrote:
Resent this time without HTML formatting which lkml doesn't like. Sorry.
On 08/09/2014 03:58 PM, Thomas Hellstrom wrote:
On 08/09/2014 03:33 PM, Konrad Rzeszutek Wilk wrote:
On August 9, 2014 1:39:39 AM EDT, Thomas
Hellstromthellst...@vmware.com
On 08/10/2014 08:02 PM, Mario Kleiner wrote:
On 08/10/2014 01:03 PM, Thomas Hellstrom wrote:
On 08/10/2014 05:11 AM, Mario Kleiner wrote:
Resent this time without HTML formatting which lkml doesn't like.
Sorry.
On 08/09/2014 03:58 PM, Thomas Hellstrom wrote:
On 08/09/2014 03:33 PM, Konrad
1 - 100 of 372 matches
Mail list logo
