This is the last remaining function that doesn't use the reservation
lock completely to fence off access to a buffer.
---
drivers/gpu/drm/ttm/ttm_bo.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 48 +---
drivers/gpu/drm/nouveau/nouveau_fence.c | 24 +---
drivers/gpu/drm/nouveau/nouveau_fence.h |2
drivers/gpu/drm/nouveau/nouveau_gem.c| 16 ++-
drivers/gpu/drm/qxl/qxl_debugfs.c|6 +
Final driver! \o/
This is not a proper dma_fence because the hardware may never signal
anything, so don't use dma-buf with qxl, ever.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/qxl/Makefile |2
drivers/gpu/drm/qxl/qxl_cmd.c |5 -
This series applies on top of the driver-core-next branch of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
Before converting ttm to the new fence interface I had to fix some
drivers to require a reservation before poking with fence_obj.
After flipping the switch RCU becomes
It seems some drivers really want this as a parameter,
like vmwgfx.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/qxl/qxl_release.c|2 +-
drivers/gpu/drm/radeon/radeon_object.c |2 +-
drivers/gpu/drm/radeon/radeon_uvd.c |2 +-
No users are left, kill it off! :D
Conversion to the reservation api is next on the list, after
that the functionality can be restored with rcu.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 25 +++---
From: Maarten Lankhorst maarten.lankho...@ubuntu.com
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/nouveau/core/core/event.c |4
drivers/gpu/drm/nouveau/nouveau_bo.c |6
drivers/gpu/drm/nouveau/nouveau_display.c |4
This reorders the list to keep track of what buffers are reserved,
so previous members are always unreserved.
This gets rid of some bookkeeping that's no longer needed,
while simplifying the code some.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
This makes it possible to wait for a specific amount of time,
rather than wait until infinity.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
Reviewed-by: Christian König deathsim...@vodafone.de
---
drivers/gpu/drm/radeon/radeon_fence.c | 60 ++---
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |2
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c| 299 ++
drivers/gpu/drm/vmwgfx/vmwgfx_fence.h| 29 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |
With the conversion to the reservation api this should be safe.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
diff --git
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.
After the switch to rcu the reservation lock will be
removed again.
Signed-off-by: Maarten Lankhorst
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/radeon/radeon.h| 15 +-
drivers/gpu/drm/radeon/radeon_device.c | 60 -
drivers/gpu/drm/radeon/radeon_fence.c | 223 ++--
3 files changed, 248 insertions(+), 50
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/radeon/radeon_gem.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index
This will ensure we always hold the required lock when calling those functions.
---
drivers/gpu/drm/nouveau/nouveau_bo.c |2 ++
drivers/gpu/drm/nouveau/nouveau_display.c | 17 +
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/ttm/ttm_bo.c | 76 +++---
1 file changed, 13 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index
Only one type was ever used. This is needed to simplify the fence
support in the next commit.
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |5 +--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |1 -
op 09-07-14 15:09, Mike Lothian schreef:
Hi Maarten
Will this stop the stuttering I've been seeing with DRI3 and PRIME? Or will
other patches / plumbing be required
No, that testing was with the whole series including the parts where you
synchronized intel with radeon (iirc).
Although it
op 09-07-14 14:57, Deucher, Alexander schreef:
snip
+static const char *radeon_fence_get_timeline_name(struct fence *f)
+{
+struct radeon_fence *fence = to_radeon_fence(f);
+switch (fence-ring) {
+case RADEON_RING_TYPE_GFX_INDEX: return radeon.gfx;
+case
https://bugs.freedesktop.org/show_bug.cgi?id=80901
--- Comment #14 from Gianni Vialetto gia...@rootcube.net ---
The problem I see with trip-points is that those allow to set a fixed PWM value
when the sensors detect a certain temperature. The nouveau driver instead
raises the fan speed
https://bugs.freedesktop.org/show_bug.cgi?id=80901
--- Comment #15 from Martin Peres martin.pe...@ensi-bourges.fr ---
(In reply to comment #14)
The problem I see with trip-points is that those allow to set a fixed PWM
value when the sensors detect a certain temperature. The nouveau driver
https://bugs.freedesktop.org/show_bug.cgi?id=81136
Priority: medium
Bug ID: 81136
Assignee: nouveau@lists.freedesktop.org
Summary: [NV92] Regression in Linux 3.15: GPU lockup after
suspend
QA Contact: xorg-t...@lists.x.org
https://bugs.freedesktop.org/show_bug.cgi?id=81136
--- Comment #1 from Agustín Dall'Alba agus...@dallalba.com.ar ---
Created attachment 102509
-- https://bugs.freedesktop.org/attachment.cgi?id=102509action=edit
Logs for git kernel with noaccel=1 nofbaccel=1
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=81136
--- Comment #2 from Agustín Dall'Alba agus...@dallalba.com.ar ---
Created attachment 102510
-- https://bugs.freedesktop.org/attachment.cgi?id=102510action=edit
Logs for Linux 3.15.4 with commit ecf24de reverted
--
You are receiving this mail
-Original Message-
From: Maarten Lankhorst [mailto:maarten.lankho...@canonical.com]
Sent: Wednesday, July 09, 2014 8:30 AM
To: airl...@linux.ie
Cc: thellst...@vmware.com; nouveau@lists.freedesktop.org; linux-
ker...@vger.kernel.org; dri-de...@lists.freedesktop.org;
Hi Maarten
Will this stop the stuttering I've been seeing with DRI3 and PRIME? Or will
other patches / plumbing be required
Cheers
Mike
On 9 Jul 2014 13:29, Maarten Lankhorst maarten.lankho...@canonical.com
wrote:
This series applies on top of the driver-core-next branch of
https://bugs.freedesktop.org/show_bug.cgi?id=80675
--- Comment #4 from Jeff jrs...@gmail.com ---
I believe I am having the same issue, except it is entirely black after KMS is
activated on boot. Even in X11.
I use Debian Testing on a Dell XPS m1730 with SLI Geforce 8700m.
lspci -v |grep 84
https://bugs.freedesktop.org/show_bug.cgi?id=80675
--- Comment #5 from Ilia Mirkin imir...@alum.mit.edu ---
(In reply to comment #4)
I believe I am having the same issue, except
In other words... not the same issue. File a fresh bug with the relevant info.
If it's deemed the same, we can mark
nouveau_fence_update does real work unconditionally. Avoid doing that if
the fence we're checking on has already been signalled.
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu
---
src/gallium/drivers/nouveau/nouveau_fence.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
From: Christoph Bumiller e0425...@student.tuwien.ac.at
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
---
docs/GL3.txt | 5 +-
docs/relnotes/10.3.html| 1 +
src/gallium/drivers/nouveau/nouveau_screen.c | 6 +-
From: Christoph Bumiller e0425...@student.tuwien.ac.at
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
---
.../drivers/nouveau/nvc0/nvc0_vbo_translate.c | 41 +++---
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git
The main patches are from Christoph. Unfortunately they're a little beyond my
understanding of all the vertex-related details, but they generally seemed
fine. I'm just going to push these unless someone steps up to review them.
Christoph Bumiller (2):
nvc0: add support for indirect drawing
32 matches
Mail list logo
