On 11/04/2013 05:40 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 04, 2013 at 05:57:39AM -0800, Thomas Hellstrom wrote:
>> The code handles three different cases:
>> 1) physical page addresses. The ttm page array is used.
>> 2) DMA subsystem addresses. A scatter-gath
On 11/04/2013 05:34 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 04, 2013 at 05:57:38AM -0800, Thomas Hellstrom wrote:
>> Used by the vmwgfx driver
> That looks OK to me. And baremetal should not be
> affected as the Intel VT-d driver turns of the SWIOTLB
> driver - so it
On 11/04/2013 05:30 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Nov 04, 2013 at 05:57:37AM -0800, Thomas Hellstrom wrote:
>> These patches makes the vmwgfx driver use the DMA API to obtain valid
>> device addresses rather than blindly using physical addresses.
>>
>> T
On 11/04/2013 05:27 PM, Daniel Vetter wrote:
> On Mon, Nov 04, 2013 at 05:57:39AM -0800, Thomas Hellstrom wrote:
>> The code handles three different cases:
>> 1) physical page addresses. The ttm page array is used.
>> 2) DMA subsystem addresses. A scatter-gather list is used.
Used by the vmwgfx driver
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob Bornecrantz
---
drivers/gpu/drm/ttm/Makefile |6 +-
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |3 +++
include/drm/ttm/ttm_page_alloc.h | 11 ++-
3 files changed, 14 insertions
These patches makes the vmwgfx driver use the DMA API to obtain valid
device addresses rather than blindly using physical addresses.
The main motivation is to be able to use a virtual IOMMU in the future.
Other TTM drivers typically map pages one by one rather than using a
scatter-gather list, bu
The code handles three different cases:
1) physical page addresses. The ttm page array is used.
2) DMA subsystem addresses. A scatter-gather list is used.
3) Coherent pages. The ttm dma pool is used, together with the dma_ttm
array os dma_addr_t
Signed-off-by: Thomas Hellstrom
Reviewed-by: Jakob
A couple of vmwgfx fixes on top of drm-next / drm-core-next.
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulen
From: Jakob Bornecrantz
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |4 +---
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |5 ++---
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
From: Jakob Bornecrantz
This fixes kernel panics when running the vbltest from the drm repo. We
can't just skip initializing the vblank system since it sets up certain
state for us, see: "vmwgfx: Enable use of the vblank system."
Signed-off-by: Jakob Bornecrantz
Signed-off-by: T
From: Jakob Bornecrantz
Make sure we null the display private, make sure we catch and
handle vblank failing to init and don't call vblank_cleanup if
we haven't initialized the display system.
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/
Konrad, Dave
Given our previous discussion on the list, I believe these patches
shouldn't introduce any regressions in the non-Xen case, however we
should probably be prepared to back them out quickly if that turns out
to be the case...
Thanks,
Thomas
On 01/07/2011 06:11 PM, Konrad Rzeszute
Fix a number of typos misspellings and checkpatch.pl warnings.
Replace "[ttm] " with TTM_PFX
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 62 +++--
1 files changed, 36 insertions(+), 26 deletions(-)
diff --git a/drivers/g
This patch fixes a regression introduced with the pool page allocator
in the event that there are no highmem pages (for example x86_64),
in which case cached page allocation would fail.
Tested with the vmwgfx driver on a 64-bit vm.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm
a...@linux-foundation.org wrote:
> From: Dan Carpenter
>
> "fx->lock" is used as the index in "dev_priv->decoder_queue[fx->lock]"
> which is an array of "VIA_NR_XVMC_LOCKS" elements.
>
> Signed-off-by: Dan Carpenter
> Cc: David Ai
Dave Airlie wrote:
> On Wed, Apr 7, 2010 at 8:21 PM, Jerome Glisse wrote:
>
>> On fault the driver is given the opportunity to perform any operation
>> it sees fit in order to place the buffer into a CPU visible area of
>> memory. This patch doesn't break TTM users, nouveau, vmwgfx and radeon
>
Jerome Glisse wrote:
> This patch update radeon to the new no_wait splitted argument
> TTM functionality.
>
> Compile tested only (but thing should run as there is no
> operating change from driver point of view)
>
> Signed-off-by: Jerome Glisse
>
Revie
in first patch of the patchset
> V3 update after io_mem_reserve/io_mem_free callback balancing
> V4 adjust to minor cleanup
>
> Signed-off-by: Jerome Glisse
>
Jerome, see comment below, apart from that, this is
Acked-by: Thomas Hellstrom
> ---
> d
sted.
>
> V2 don't derefence bo->mem.mm_node as it's not NULL only for
>VRAM or GTT
> V3 update after io_mem_reserve/io_mem_free callback balancing
>
> Signed-off-by: Jerome Glisse
>
Reviewed-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx
Jerome Glisse wrote:
> So in these patchset i use bool instead of atomic remove empty line
> removal, and i hope addressed standing issues. Again only compile
> tested for nouveau & vmwgfx. Tested this time only tested on RV710
> with special patch to force unmappable vram use.
> http://people.free
Jerome Glisse wrote:
> This isn't needed anymore with the new TTM fault callback
>
> Signed-off-by: Jerome Glisse
>
Reviewed-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |6 --
> 1 files changed, 0 insertions(+), 6 deletions(-)
&g
m any necessary task for mapping to succeed
> V4 minor cleanup, atomic_t -> bool as member is protected by reserve
>mecanism from concurent access
>
> Signed-off-by: Jerome Glisse
>
Reviewed-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/ttm/ttm_bo.c
>
> This patch break the API to other modules, update to others
> driver are following in separate patches.
>
> Signed-off-by: Jerome Glisse
>
Acked-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 57
>
Jerome Glisse wrote:
> On Wed, Mar 24, 2010 at 07:27:57PM +0100, Thomas Hellstrom wrote:
>
>> Jerome Glisse wrote:
>>
>>> On fault the driver is given the opportunity to perform any operation
>>> it sees fit in order to place the buffer into a CPU vi
Jerome Glisse wrote:
> On fault the driver is given the opportunity to perform any operation
> it sees fit in order to place the buffer into a CPU visible area of
> memory. This patch doesn't break TTM users, nouveau, vmwgfx and radeon
> should keep working properly. Future patch will take advantag
Jerome Glisse wrote:
> On Mon, Mar 01, 2010 at 01:03:38PM +0100, Thomas Hellstrom wrote:
>
>> Dave Airlie wrote:
>>
>>> On Fri, Feb 26, 2010 at 3:01 AM, Jerome Glisse wrote:
>>>
>>>
>>>> Updated patchset, to apply cleanly
Jerome Glisse wrote:
> On fault the driver is given the opportunity to perform any operation
> it sees fit in order to place the buffer into a CPU visible area of
> memory. This patch doesn't break TTM users, nouveau, vmwgfx and radeon
> should keep working properly. Future patch will take advantag
>
> This patch break the API to other modules, update to others
> driver are following in separate patches.
>
> Signed-off-by: Jerome Glisse
>
Acked-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 57
>
Arvind R wrote:
> On Thu, Mar 11, 2010 at 4:32 PM, Pekka Paalanen wrote:
>
>> I'm adding dri-devel@ to CC, since this suggested patch touches
>> TTM code, and none of the Nouveau code. TTM patches go via
>> dri-de...@.
>>
>> Thanks.
>>
>>
>>
This is a NAK in its current form.
First, At m
Dave Airlie wrote:
> Now that the drm core can do this, lets just use it, split the code out
> so TTM doesn't have to drag all of drmP.h in.
>
>
Acked-by: Thomas Hellstrom
It's funny, though. The original code used code similar to
"is_vmalloc_addr()" now in l
Luca Barbieri wrote:
>> ^^^ Luca, I've never seen this show up high on a profile (yet). Do you see
>> that with Nouveau? I used to have an rb-tree implementation of drm_mm_xxx
>> lying around, but I didn't use it because I didn't have a case where it
>> showed up?
>>
>
> Yes, before I did user
Luca Barbieri wrote:
> While this is almost surely a good idea, note that userspace caching
> and suballocation substantially improves Mesa performance even on PCIe
> systems.
> This is mostly due to the unavoidable overhead of kernel calls and
> pagetable modifications,
> as well as the avoidab
Maarten Maathuis wrote:
> - The headerfile says you can't write to it without holding the lock.
>
NAK.
The header-file is incorrect. It should say that the lru_lock needs to
be held only when we transition from 0 to 1.
That guarantees that if the lru lock is held, and we read 0, we can
safel
Dave Airlie wrote:
> On Fri, Feb 26, 2010 at 3:01 AM, Jerome Glisse wrote:
>
>> Updated patchset, to apply cleanly on top of TTM split no_wait argument.
>> Compile tested for nouveau+vmwgfx, test in progress for radeon.
>>
>> So with the new change radeon won't wait for bo reserving other bo
>>
Jerome Glisse wrote:
> On Wed, Feb 24, 2010 at 01:37:42PM +0100, Thomas Hellstrom wrote:
>
>> Jerome Glisse wrote:
>>
>>> On Tue, Feb 23, 2010 at 02:05:50PM +0100, Thomas Hellstrom wrote:
>>>
>>>> Jerome Glisse wrote:
>>>
Jerome Glisse wrote:
> On Tue, Feb 23, 2010 at 02:05:50PM +0100, Thomas Hellstrom wrote:
>
>> Jerome Glisse wrote:
>>
>>> On Mon, Feb 22, 2010 at 08:58:28PM +0100, Thomas Hellstrom wrote:
>>>
>>>> Jerome Glisse wrote:
>>>
RR(to_page);
>>>goto out_err;
>>> -
>>> + }
>>>
>> If that is true and the rest is just nice cleanups then I'm okay with it,.
>>
>> Reviewed-by: Dave Airlie
>>
>> I'll need
Jerome Glisse wrote:
> On Mon, Feb 22, 2010 at 08:58:28PM +0100, Thomas Hellstrom wrote:
>
>> Jerome Glisse wrote:
>>
>>> On Mon, Feb 22, 2010 at 06:30:24PM +0100, Thomas Hellstrom wrote:
>>>
>>>> Jerome Glisse wrote:
>>>>
Jerome Glisse wrote:
> On Mon, Feb 22, 2010 at 06:30:24PM +0100, Thomas Hellstrom wrote:
>
>> Jerome Glisse wrote:
>>
>>> Thomas i think i addressed your concern here, the ttm_bo_validate
>>> didn't needed a new argument or i did not understand
Jerome Glisse wrote:
> Thomas i think i addressed your concern here, the ttm_bo_validate
> didn't needed a new argument or i did not understand what was
> necessary beside no_wait. In this patchset we check the value
> of callback in case of EBUSY (call set_need_resched) or ERESTARTSYS
> we return
Rafał Miłecki wrote:
> Signed-off-by: Rafał Miłecki
> ---
> We try to implement some PM in radeon KMS and we need to sync with VLBANK for
> reclocking engine/memory. The easiest and cleanest way seems to be sleeping in
> timer handler just before reclocking. Then our IRQ handler calls wake_up and
Intercept query commands and apply relocations to their guest pointers.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 108 ++-
1 files changed, 92 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b
Jerome,
I think this could and should be accomplished in the following way (like
the old ttm did).
1: For kernel maps:
a) reserve the bo.
b) validate the bo into a mappable segment of vram, perhaps using range
validation.
c) idle any accelerated move.
d) call ttm_bo_kmap.
2: For fault:
a) in b
Dave Airlie wrote:
> On Mon, Feb 15, 2010 at 8:04 PM, Thomas Hellstrom wrote:
>
>> Hi, Dave!
>>
>> Could you point me to what's needed in drm fb setup to utilize the
>> vesafb handover mechanism?
>>
>
> In intel_fb.c
>
>
When the vmwgfx module is loaded on top of vesafb, it would operate in
stealth mode in parallel with vesafb, evicting VRAM on dropmaster.
Change that to use the vesafb handover mechanism, like other drmfb drivers.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 49
Hi, Dave!
Could you point me to what's needed in drm fb setup to utilize the
vesafb handover mechanism?
Thanks,
Thomas
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healin
Michel Dänzer wrote:
> On Fri, 2010-02-12 at 00:17 +0100, Thomas Hellstrom wrote:
>
>> Signed-off-by: Thomas Hellstrom
>>
>
> Please make a proper short description of the change on the first line
> of the commit message.
>
>
>
Done. That short de
When searching for free space in a range, the function could return a node
extending outside of the given range.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/drm_mm.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/drm_mm.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index cdec329..2ac074c 100644
--- a/drivers/gpu/drm/drm_mm.c
+++ b/drivers/gpu/drm/drm_mm.c
@@ -405,7 +405,8
If the buffer object was already in the requested memory type, but
outside of the requested range it was never moved into the requested range.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers
This patch series contains two pretty important bugfixes to the new
validate-in-range functionality. The first bug could case a buffer object to
be validated outside of the requested range, the other one could cause a
buffer object to remain at its current offset even though that offset was
outsid
From: Jakob Bornecrantz
Even if this bumps the version to 1 it does not mean the driver is
out of staging. From what we know this is the last backwards
incompatible change to the driver.
Signed-off-by: Jakob Bornecrantz
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
Jakob Bornecrantz wrote:
> Even if this bumps the version to 1 it does not mean the driver is
> out of staging. From what we know this is the last backwards
> incompatible change to the driver.
>
> Signed-off-by: Jakob Bornecrantz
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |6 +++---
>
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |3 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 17 +
drivers/gpu/drm/vmwgfx/vmwgfx_irq.c | 13 +++--
3 files changed, 14 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx
Resending with correct email time-stamp.
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and manag
When time-based throttling is implemented, we need to bump minor.
When the old way of detecting scanout is removed, we need to bump major.
In the meantime, this change should not break existing user-space.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |6
Robert Högberg wrote:
> Hello.
>
> I'm trying to debug an issue I'm having with my Via CN400 board. The problem
> I see is that every time I watch a specific DVD using XvMC the display
> freezes completely after a short time.
>
> The freeze seems to be caused by a failing via_cmdbuf_wait. I don't
When time-based throttling is implemented, we need to bump minor.
When the old way of detecting scanout is removed, we need to bump major.
In the meantime, this change should not break existing user-space.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |6
Jerome Glisse wrote:
> On Mon, Feb 01, 2010 at 11:35:21AM +1000, Dave Airlie wrote:
>
>> On Thu, Jan 28, 2010 at 7:26 PM, Luca Barbieri
>> wrote:
>>
>>> Currently TTM tries to preserve the previous caching even for moves
>>> between unrelated memory spaces.
>>>
>>> This results for instan
tm_object.c
> @@ -109,8 +109,8 @@ struct ttm_ref_object {
> struct drm_hash_item hash;
> struct list_head head;
> struct kref kref;
> - struct ttm_base_object *obj;
> enum ttm_ref_type ref_type;
> + struct ttm_base_object *obj;
>
blem that the core kernel
complains if you try to move directly from wc to uc? In that case it
looks OK to me:
Acked-by: Thomas Hellstrom
>
>> Fixes errors like:
>>
>>> reserve_ram_pages_type failed 0x15b7a000-0x15b7b000, track 0x8, req 0x10
>>>
>
Jerome Glisse wrote:
> On Thu, Jan 21, 2010 at 01:59:26PM +0100, Thomas Hellstrom wrote:
>
>> Jerome Glisse wrote:
>>
>>> On Thu, Jan 21, 2010 at 04:49:39AM +0100, Luca Barbieri wrote:
>>>
>>>>> We had to do a similar thing in the
&
Yuan, Shengquan wrote:
> On Wed, Jan 20, 2010 at 6:48 PM, Thomas Hellstrom wrote:
>
>> Yuan,
>> This looks like an old leftover from a previous cleanup.
>>
>> Although, when I look at the code, it seems save_flags should be removed
>> completely.
>>
Luca Barbieri wrote:
>> At a first glance:
>>
>> 1) We probably *will* need a delayed destroyed workqueue to avoid wasting
>> memory that otherwise should be freed to the system. At the very least, the
>> delayed delete process should optionally be run by a system shrinker.
>>
> You are right.
Luca Barbieri wrote:
>> We had to do a similar thing in the
>> Poulsbo driver and it turned out that we could save a significant amount of
>> CPU by using a delayed workqueue, collecting objects and destroying them
>> periodically.
>>
> Yes, indeed, we don't really care about a fence expiring
Jerome Glisse wrote:
> On Thu, Jan 21, 2010 at 04:49:39AM +0100, Luca Barbieri wrote:
>
>>> We had to do a similar thing in the
>>> Poulsbo driver and it turned out that we could save a significant amount of
>>> CPU by using a delayed workqueue, collecting objects and destroying them
>>> periodi
Luca Barbieri wrote:
> When designing this, we should also keep in mind that some drivers
> (e.g. nouveau) have multiple FIFO channels, and thus we would like a
> buffer to be referenced for reading by multiple channels at once (and
> be destroyed only when all fences are expired, obviously).
> Als
Luca Barbieri wrote:
>> Also note that the delayed delete list is not in fence order but in
>> deletion-time order, which perhaps gives room for more optimizations.
>>
> You are right.
> I think then that ttm_bo_delayed_delete may still need to be changed,
> because it stops when ttm_bo_cleanu
Luca Barbieri wrote:
> Yes it's fine. I sent your patch to Dave with an expanded commit
> comment for merging.
>
> Here is a possible redesign of the mechanism inspired by this issue.
> It seems that what we are racing against is buffer eviction, due to
> delayed deletion buffers being still kept o
Thomas Hellstrom wrote:
Yes, it looks correct. Although it seems a little unintuitive to enter
the loop with the spinlock held, and exit it with the spinlock not held.
I've attached yet another patch to have that fixed. Could you take a
look at whether it seems OK with you and, in that
Thomas Hellstrom wrote:
Thomas Hellstrom wrote:
Yes, it looks correct. Although it seems a little unintuitive to enter
the loop with the spinlock held, and exit it with the spinlock not held.
I've attached yet another patch to have that fixed. Could you take a
look at whether it see
Luca Barbieri wrote:
>> Would nentry=list_first_entry(&entry->ddestroy, ) work?
>>
> Yes, it seems a bit less intuitive, but if that's the accepted
> practice, let's do that instead.
>
>
>> Here nentry may have been removed from the list by another process, which
>> would trigger the u
Yuan,
This looks like an old leftover from a previous cleanup.
Although, when I look at the code, it seems save_flags should be removed
completely.
Can you take a look at that and respin the patch?
Thanks,
Thomas
Yuan, Shengquan wrote:
> commit d60326ac977a5e99047b44f9b313ff79cd3a14b4
> Autho
Luca,
Good catch.
Some comments inline:
Luca Barbieri wrote:
> + entry = list_first_entry(&bdev->ddestroy,
> + struct ttm_buffer_object, ddestroy);
> + kref_get(&entry->list_kref);
>
> - if (next != &bdev->ddestroy) {
> - nentry = list_entry
This is needed to fix a vmwgfx memory usage bug.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index da37021..c7733c3 100644
--- a
Use VRAM whenever there is free space for DMA buffers,
but use system GMR memory if using VRAM would cause an eviction.
This significantly reduces the guest system memory usage for
VMs with a large amount of VRAM allocated.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx
This is a convention that the vmwgfx driver has come to rely on.
Signed-off-by: Thomas Hellstrom
---
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 7a64f07..da37021 100644
callbacks.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 62 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |2 +
2 files changed, 63 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vm
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c |1 +
drivers/gpu/drm/ttm/ttm_lock.c |2 ++
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index e10a04e..7a64f07 100644
--- a/drivers/gpu/drm
Unbind GMR bindings on the buffer about to be swapped out.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
driver must then release any
private GPU bindings on those buffers.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c|3 +++
include/drm/ttm/ttm_bo_driver.h |5 +
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu
An error happening before the snooper.image member had been set up
would cause a kfree of an arbitrary pointer. Set up the snooper.image
member early.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 39 -
1 files changed, 21
A vt switch in stealth mode would take down the FIFO, and re-
initialize fence sequence numbers. This patch
saves the current state of the fence sequence when the FIFO is
disabled.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |1 +
drivers/gpu/drm/vmwgfx
That's unnecessary since partial screen updates from GMRs are fast.
Also fix cliprect pointer dereferencing
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 12 +---
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/v
This patch series contains a number of bug fixes for the vmwgfx driver.
Some fixes has required minimal changes to TTM, most notably a swap_notify
callback, since the vmwgfx driver has driver-private GPU bindings.
--
This
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_lock.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_lock.c b/drivers/gpu/drm/ttm/ttm_lock.c
index 3d172ef..de41e55 100644
--- a/drivers/gpu/drm/ttm/ttm_lock.c
+++ b/drivers/gpu/drm
This was previously done explicitly for overlay- and fb buffers.
Now it's done for any buffer leaving the SYSTEM memory region.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 10 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |1 +
drivers/gp
I've seen something similar with openchrome,
but I think I traced that down to the DMA engines causing memory corruption.
Note that IIRC kmap_atomic may return page_address(page) for a lowmem page.
Any idea what may cause kmap_atomic to behave in this way?
/Thomas
Maarten Maathuis wrote:
> I've
Improve the command verifier to catch all occurences of surface handles,
and translate to SIDs.
This way DMA buffers and 3D surfaces share a common handle space,
which makes it possible for the kms code to differentiate.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
Improve the command verifier to catch all occurences of surface handles,
and translate to SIDs.
This way DMA buffers and 3D surfaces share a common handle space,
which makes it possible for the kms code to differentiate.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
Dave Airlie wrote:
> From: Dave Airlie
>
> For some reason these ioctls have no DRM flags, which just seems wrong,
> so I guess that needs reviewing also before staging exit.
>
> Signed-off-by: Dave Airlie
>
Dave, is the DRM_UNLOCKED stuff going in for 2.6.33? Otherwise, I'll
provide a patch
Jerome Glisse wrote:
> On Mon, Dec 21, 2009 at 01:53:37PM +1000, Dave Airlie wrote:
>
>> From: Bob Gleitsmann
>>
>> This is from bug 25728.
>>
>> [airlied: I'm just forwarding the patch for review, Thomas, ickle?]
>>
>
> Looks good t
Ben Skeggs wrote:
> On Wed, 2009-12-16 at 12:11 +0100, Thomas Hellstrom wrote:
>
>> Jerome Glisse wrote:
>>
>>> On Wed, 2009-12-16 at 11:56 +0100, Thomas Hellstrom wrote:
>>>
>>>
>>>> Hi guys,
>>>>
>&
Jerome Glisse wrote:
> On Wed, 2009-12-16 at 11:56 +0100, Thomas Hellstrom wrote:
>
>> Hi guys,
>>
>> There is another TTM race bug that I'm going to fix but which doesn't
>> yet affect any upstream code AFAICT.
>>
>> The effect is tha
Hi guys,
There is another TTM race bug that I'm going to fix but which doesn't
yet affect any upstream code AFAICT.
The effect is that it may cause a deadlock in extremely rare cases if
there are two processes validating at the same time, and one process
needs to evict a buffer on which ttm_bo
1) Remove from lru before reserving so we avoid competing with
evicting processes.
2) Avoid calling kref_put() on bo::list_kref while spinlocked.
3) Additional refcounting bug-checking.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c |7 ---
1 files changed, 4
lru lock.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c | 36 +++-
1 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 488f255..0d6646d 100644
--- a/drivers/gpu/drm
Jerome Glisse wrote:
> Hi Thomas,
>
> Dave find out the root of a strange oops we did encouter.
> I spend sometimes today trying to hack ttm around but
> in the end my solution is wrong.
>
> So when we move an object a ttm ghost object is created.
> If GPU takes time to evict the bo the ghost objec
Jerome Glisse wrote:
> This patch series add printing of all informations necessary to
> understand why getting memory space fails. I have mixed feeling
> on letting this enabled by default or only enabling it with debug
> compile flags.
>
> Cheers,
> Jerome
>
>
Jerome,
This is Acked-By me, alth
Jakob Bornecrantz wrote:
> This patch series add the vmwgfx driver to the kernel tree inside
> the staging tree. I split the patch in two parts as the svga
> headers fail checkpatch quite hard. The svga* headers are shared
> between a lot of different components but I can understand if they
> get r
1 - 100 of 196 matches
Mail list logo
