[PATCH 2/2] drm/ttm: Optimize delayed buffer destruction
This commit replaces the ttm_bo_cleanup_ref function with two new functions.
One for the case where the bo is not yet on the delayed destroy list, and
one for the case where the bo was on the delayed destroy list, at least at
the time of call. This makes it possible to optimize the two cases somewhat.
It also enables the possibility to directly destroy buffers on the
delayed delete list when they are about to be evicted or swapped out.
Currently they were only evicted / swapped and destruction was left for the
delayed buffer destruction thread.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c | 171 ++
1 files changed, 107 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 7497b79..2936629 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -460,99 +460,122 @@ static void ttm_bo_cleanup_memtype_use(struct
ttm_buffer_object *bo)
wake_up_all(&bo->event_queue);
}
-
-/**
- * If bo idle, remove from delayed- and lru lists, and unref.
- * If not idle, and already on delayed list, do nothing.
- * If not idle, and not on delayed list, put on delayed list,
- * up the list_kref and schedule a delayed list check.
- */
-
-static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo, bool remove_all)
+static void ttm_bo_cleanup_refs_or_queue(struct ttm_buffer_object *bo)
{
struct ttm_bo_device *bdev = bo->bdev;
struct ttm_bo_global *glob = bo->glob;
- struct ttm_bo_driver *driver = bdev->driver;
+ struct ttm_bo_driver *driver;
+ void *sync_obj;
+ void *sync_obj_arg;
+ int put_count;
int ret;
spin_lock(&bo->lock);
-retry:
- (void) ttm_bo_wait(bo, false, false, !remove_all);
-
+ (void) ttm_bo_wait(bo, false, false, true);
if (!bo->sync_obj) {
- int put_count;
-
- spin_unlock(&bo->lock);
spin_lock(&glob->lru_lock);
- ret = ttm_bo_reserve_locked(bo, false, !remove_all, false, 0);
/**
-* Someone else has the object reserved. Bail and retry.
+* Lock inversion between bo::reserve and bo::lock here,
+* but that's OK, since we're only trylocking.
*/
- if (unlikely(ret == -EBUSY)) {
- spin_unlock(&glob->lru_lock);
- spin_lock(&bo->lock);
- goto requeue;
- }
-
- /**
-* We can re-check for sync object without taking
-* the bo::lock since setting the sync object requires
-* also bo::reserved. A busy object at this point may
-* be caused by another thread starting an accelerated
-* eviction.
-*/
+ ret = ttm_bo_reserve_locked(bo, false, true, false, 0);
- if (unlikely(bo->sync_obj)) {
- atomic_set(&bo->reserved, 0);
- wake_up_all(&bo->event_queue);
- spin_unlock(&glob->lru_lock);
- spin_lock(&bo->lock);
- if (remove_all)
- goto retry;
- else
- goto requeue;
- }
+ if (unlikely(ret == -EBUSY))
+ goto queue;
+ spin_unlock(&bo->lock);
put_count = ttm_bo_del_from_lru(bo);
- if (!list_empty(&bo->ddestroy)) {
- list_del_init(&bo->ddestroy);
- ++put_count;
- }
+ spin_unlock(&glob->lru_lock);
ttm_bo_cleanup_memtype_use(bo);
while (put_count--)
kref_put(&bo->list_kref, ttm_bo_ref_bug);
- return 0;
+ return;
+ } else {
+ spin_lock(&glob->lru_lock);
}
-requeue:
+queue:
+ sync_obj = bo->sync_obj;
+ sync_obj_arg = bo->sync_obj_arg;
+ driver = bdev->driver;
+
+ kref_get(&bo->list_kref);
+ list_add_tail(&bo->ddestroy, &bdev->ddestroy);
+ spin_unlock(&glob->lru_lock);
+ spin_unlock(&bo->lock);
+
+ if (sync_obj)
+ driver->sync_obj_flush(sync_obj, sync_obj_arg);
+ schedule_delayed_work(&bdev->wq,
+ ((HZ / 100) < 1) ? 1 : HZ / 100);
+}
+
+/**
+ * function ttm_bo_cleanup_refs
+ * If bo idle, remove from delayed- and lru lists, and unref.
+ * If not idle, do nothing.
+ *
+ * @interruptible Any sleeps should occur interruptibly.
+ * @no_wait_reserve Never wait for reserve. Return -EBUSY instead.
+ * @no_wait_gpu Never wait for gpu. Return -EBUSY instead.
+ */
+
+static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
+ bool interrup
[PATCH 1/2] drm/ttm: Avoid using the ttm_mem_type_manager::put_locked function
Release the lru spinlock early.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c | 30 +-
drivers/gpu/drm/ttm/ttm_bo_manager.c | 10 --
include/drm/ttm/ttm_bo_driver.h |2 --
3 files changed, 5 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index fd8344d..7497b79 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -439,36 +439,25 @@ out_err:
}
/**
- * Call bo::reserved and with the lru lock held.
+ * Call bo::reserved.
* Will release GPU memory type usage on destruction.
- * This is the place to put in driver specific hooks.
- * Will release the bo::reserved lock and the
- * lru lock on exit.
+ * This is the place to put in driver specific hooks to release
+ * driver private resources.
+ * Will release the bo::reserved lock.
*/
static void ttm_bo_cleanup_memtype_use(struct ttm_buffer_object *bo)
{
- struct ttm_bo_global *glob = bo->glob;
-
if (bo->ttm) {
-
- /**
-* Release the lru_lock, since we don't want to have
-* an atomic requirement on ttm_tt[unbind|destroy].
-*/
-
- spin_unlock(&glob->lru_lock);
ttm_tt_unbind(bo->ttm);
ttm_tt_destroy(bo->ttm);
bo->ttm = NULL;
- spin_lock(&glob->lru_lock);
}
- ttm_bo_mem_put_locked(bo, &bo->mem);
+ ttm_bo_mem_put(bo, &bo->mem);
atomic_set(&bo->reserved, 0);
wake_up_all(&bo->event_queue);
- spin_unlock(&glob->lru_lock);
}
@@ -788,15 +777,6 @@ void ttm_bo_mem_put(struct ttm_buffer_object *bo, struct
ttm_mem_reg *mem)
}
EXPORT_SYMBOL(ttm_bo_mem_put);
-void ttm_bo_mem_put_locked(struct ttm_buffer_object *bo, struct ttm_mem_reg
*mem)
-{
- struct ttm_mem_type_manager *man = &bo->bdev->man[mem->mem_type];
-
- if (mem->mm_node)
- (*man->func->put_node_locked)(man, mem);
-}
-EXPORT_SYMBOL(ttm_bo_mem_put_locked);
-
/**
* Repeatedly evict memory from the LRU for @mem_type until we create enough
* space, or we've evicted everything and there isn't enough space.
diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c
b/drivers/gpu/drm/ttm/ttm_bo_manager.c
index 35c97b2..7410c19 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
@@ -90,15 +90,6 @@ static void ttm_bo_man_put_node(struct ttm_mem_type_manager
*man,
}
}
-static void ttm_bo_man_put_node_locked(struct ttm_mem_type_manager *man,
- struct ttm_mem_reg *mem)
-{
- if (mem->mm_node) {
- drm_mm_put_block(mem->mm_node);
- mem->mm_node = NULL;
- }
-}
-
static int ttm_bo_man_init(struct ttm_mem_type_manager *man,
unsigned long p_size)
{
@@ -152,7 +143,6 @@ const struct ttm_mem_type_manager_func ttm_bo_manager_func
= {
ttm_bo_man_takedown,
ttm_bo_man_get_node,
ttm_bo_man_put_node,
- ttm_bo_man_put_node_locked,
ttm_bo_man_debug
};
EXPORT_SYMBOL(ttm_bo_manager_func);
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index d0ff529..d01b4dd 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -214,8 +214,6 @@ struct ttm_mem_type_manager_func {
struct ttm_mem_reg *mem);
void (*put_node)(struct ttm_mem_type_manager *man,
struct ttm_mem_reg *mem);
- void (*put_node_locked)(struct ttm_mem_type_manager *man,
- struct ttm_mem_reg *mem);
void (*debug)(struct ttm_mem_type_manager *man, const char *prefix);
};
--
1.6.2.5
[PATCH 0/0] ttm patches for drm-next
These patches attempt to optimize the delayed destroy handling. The first patch removes the need for the newly introduced mem_put_locked callback. The second patch optimizes the delayed buffer destruction somewhat, but has not yet seen extensive testing.
Re: GEM - radeon cs ioctl deadlock
On Thu, 2010-10-14 at 08:14 +1000, Dave Airlie wrote: > On Wed, 2010-10-13 at 17:57 -0400, Jerome Glisse wrote: > > So we are facing a deadlock with the radeon cs ioctl. When a buffer is given > > a name (with flink) we could endup with 2 handle pointing to the same > > object (flink object and open it from same file descriptor). Would it be ok > > if i change gem open to first look if we already have an handle for the > > object and to use that handle instead of creating a new one ? Or could > > this break intel driver ? > > I think r300g worked around this already, maybe we should just avoid > doing it from userspace if possible. We had this in nouveau at some point. In the end, I prevented the deadlock from occuring by checking that a process doesn't reserve the same buffer twice (we store file_priv in a reserved_by field in the bo as we reserve the buffers), and then just fixed userspace. Ben. > > Dave. > > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
GEM - radeon cs ioctl deadlock
So we are facing a deadlock with the radeon cs ioctl. When a buffer is given a name (with flink) we could endup with 2 handle pointing to the same object (flink object and open it from same file descriptor). Would it be ok if i change gem open to first look if we already have an handle for the object and to use that handle instead of creating a new one ? Or could this break intel driver ? Cheers, Jerome
Re: GEM - radeon cs ioctl deadlock
On Wed, 2010-10-13 at 17:57 -0400, Jerome Glisse wrote: > So we are facing a deadlock with the radeon cs ioctl. When a buffer is given > a name (with flink) we could endup with 2 handle pointing to the same > object (flink object and open it from same file descriptor). Would it be ok > if i change gem open to first look if we already have an handle for the > object and to use that handle instead of creating a new one ? Or could > this break intel driver ? I think r300g worked around this already, maybe we should just avoid doing it from userspace if possible. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
GEM - radeon cs ioctl deadlock
So we are facing a deadlock with the radeon cs ioctl. When a buffer is given a name (with flink) we could endup with 2 handle pointing to the same object (flink object and open it from same file descriptor). Would it be ok if i change gem open to first look if we already have an handle for the object and to use that handle instead of creating a new one ? Or could this break intel driver ? Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm, kdb, kms: Change mode_set_base_atomic() enter argument to be an enum
The enter argument as implemented by commit 413d45d3627 (drm, kdb, kms:
Add an enter argument to mode_set_base_atomic() API) should be more
descriptive as to what it does vs just passing 1 and 0 around.
There is no runtime behavior change as a result of this patch.
Reported-by: Jesse Barnes
Signed-off-by: Jason Wessel
CC: David Airlie
CC: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_fb_helper.c |5 ++---
drivers/gpu/drm/i915/intel_display.c|5 +++--
drivers/gpu/drm/nouveau/nv04_crtc.c |4 ++--
drivers/gpu/drm/nouveau/nv50_crtc.c |2 +-
drivers/gpu/drm/radeon/atombios_crtc.c |2 +-
drivers/gpu/drm/radeon/radeon_legacy_crtc.c |2 +-
drivers/gpu/drm/radeon/radeon_mode.h|7 +--
include/drm/drm_crtc_helper.h |7 ++-
8 files changed, 21 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 8208e19..d2849e4 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -289,8 +289,7 @@ int drm_fb_helper_debug_enter(struct fb_info *info)
mode_set->fb,
mode_set->x,
mode_set->y,
- 1);
-
+ ENTER_ATOMIC_MODE_SET);
}
}
@@ -336,7 +335,7 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
drm_fb_helper_restore_lut_atomic(mode_set->crtc);
funcs->mode_set_base_atomic(mode_set->crtc, fb, crtc->x,
- crtc->y, 0);
+ crtc->y, LEAVE_ATOMIC_MODE_SET);
}
return 0;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9109c00..96d08a9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1492,7 +1492,7 @@ err_unpin:
/* Assume fb object is pinned & idle & fenced and just update base pointers */
static int
intel_pipe_set_base_atomic(struct drm_crtc *crtc, struct drm_framebuffer *fb,
- int x, int y, int enter)
+ int x, int y, enum mode_set_atomic state)
{
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -1614,7 +1614,8 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
atomic_read(&obj_priv->pending_flip) == 0);
}
- ret = intel_pipe_set_base_atomic(crtc, crtc->fb, x, y, 0);
+ ret = intel_pipe_set_base_atomic(crtc, crtc->fb, x, y,
+LEAVE_ATOMIC_MODE_SET);
if (ret) {
i915_gem_object_unpin(to_intel_framebuffer(crtc->fb)->obj);
mutex_unlock(&dev->struct_mutex);
diff --git a/drivers/gpu/drm/nouveau/nv04_crtc.c
b/drivers/gpu/drm/nouveau/nv04_crtc.c
index 17f7cf0..c71abc2 100644
--- a/drivers/gpu/drm/nouveau/nv04_crtc.c
+++ b/drivers/gpu/drm/nouveau/nv04_crtc.c
@@ -860,12 +860,12 @@ nv04_crtc_mode_set_base(struct drm_crtc *crtc, int x, int
y,
static int
nv04_crtc_mode_set_base_atomic(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
- int x, int y, int enter)
+ int x, int y, enum mode_set_atomic state)
{
struct drm_nouveau_private *dev_priv = crtc->dev->dev_private;
struct drm_device *dev = dev_priv->dev;
- if (enter)
+ if (state == ENTER_ATOMIC_MODE_SET)
nouveau_fbcon_save_disable_accel(dev);
else
nouveau_fbcon_restore_accel(dev);
diff --git a/drivers/gpu/drm/nouveau/nv50_crtc.c
b/drivers/gpu/drm/nouveau/nv50_crtc.c
index ba91bef..16380d5 100644
--- a/drivers/gpu/drm/nouveau/nv50_crtc.c
+++ b/drivers/gpu/drm/nouveau/nv50_crtc.c
@@ -708,7 +708,7 @@ nv50_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
static int
nv50_crtc_mode_set_base_atomic(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
- int x, int y, int enter)
+ int x, int y, enum mode_set_atomic state)
{
return nv50_crtc_do_mode_set_base(crtc, fb, x, y, true, true);
}
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 037e326..348b367 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1258,7 +1258,7 @@ int atombios_crtc_set_base(struct drm_crtc *crtc, int x,
int y,
int atombios_crtc_set_base_atomic(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
- int x, int y, int enter)
+
[PATCH 2/3] kdb, kms: Save and restore the LUT on atomic KMS enter/exit
When changing VTs non-atomically the kernel works in conjunction with
the Xserver in user space and receives the LUT information from the
Xserver via a system call. When changing modes atomically for kdb,
this information must be saved and restored without disturbing user
space as if nothing ever happened.
There is a short cut used by this patch where gamma_store is used as
the save space. If this turns out to be a problem in the future a
pre-allocated chunk of memory will be required for each crtc to save
and restore the LUT information.
Signed-off-by: Jason Wessel
CC: Jesse Barnes
CC: David Airlie
CC: dri-devel at lists.freedesktop.org
---
drivers/gpu/drm/drm_fb_helper.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 625a2d5..8208e19 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -242,6 +242,30 @@ static int drm_fb_helper_parse_command_line(struct
drm_fb_helper *fb_helper)
return 0;
}
+static void drm_fb_helper_save_lut_atomic(struct drm_crtc *crtc, struct
drm_fb_helper *helper)
+{
+ uint16_t *r_base, *g_base, *b_base;
+ int i;
+
+ r_base = crtc->gamma_store;
+ g_base = r_base + crtc->gamma_size;
+ b_base = g_base + crtc->gamma_size;
+
+ for (i = 0; i < crtc->gamma_size; i++)
+ helper->funcs->gamma_get(crtc, &r_base[i], &g_base[i],
&b_base[i], i);
+}
+
+static void drm_fb_helper_restore_lut_atomic(struct drm_crtc *crtc)
+{
+ uint16_t *r_base, *g_base, *b_base;
+
+ r_base = crtc->gamma_store;
+ g_base = r_base + crtc->gamma_size;
+ b_base = g_base + crtc->gamma_size;
+
+ crtc->funcs->gamma_set(crtc, r_base, g_base, b_base, 0,
crtc->gamma_size);
+}
+
int drm_fb_helper_debug_enter(struct fb_info *info)
{
struct drm_fb_helper *helper = info->par;
@@ -260,6 +284,7 @@ int drm_fb_helper_debug_enter(struct fb_info *info)
continue;
funcs = mode_set->crtc->helper_private;
+ drm_fb_helper_save_lut_atomic(mode_set->crtc, helper);
funcs->mode_set_base_atomic(mode_set->crtc,
mode_set->fb,
mode_set->x,
@@ -309,6 +334,7 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
continue;
}
+ drm_fb_helper_restore_lut_atomic(mode_set->crtc);
funcs->mode_set_base_atomic(mode_set->crtc, fb, crtc->x,
crtc->y, 0);
}
--
1.6.3.3
[PATCH 1/3] Revert "radeon, kdb, kms: Save and restore the LUT on atomic KMS enter/exit"
This reverts commit ff773714dd30b802c336064109c535d8b2774e2f.
A generic solution is needed to save and retore the LUT information.
CC: Jesse Barnes
CC: David Airlie
CC: dri-devel at lists.freedesktop.org
Signed-off-by: Jason Wessel
---
drivers/gpu/drm/radeon/radeon_display.c | 32 ---
drivers/gpu/drm/radeon/radeon_legacy_crtc.c |5
drivers/gpu/drm/radeon/radeon_mode.h|3 --
3 files changed, 0 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 6c6846c..fd70b84 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -138,38 +138,6 @@ void radeon_crtc_load_lut(struct drm_crtc *crtc)
legacy_crtc_load_lut(crtc);
}
-void radeon_crtc_save_lut(struct drm_crtc *crtc)
-{
- struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
- int i;
-
- if (!crtc->enabled)
- return;
-
- for (i = 0; i < 256; i++) {
- radeon_crtc->lut_r_copy[i] = radeon_crtc->lut_r[i];
- radeon_crtc->lut_g_copy[i] = radeon_crtc->lut_g[i];
- radeon_crtc->lut_b_copy[i] = radeon_crtc->lut_b[i];
- }
-}
-
-void radeon_crtc_restore_lut(struct drm_crtc *crtc)
-{
- struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
- int i;
-
- if (!crtc->enabled)
- return;
-
- for (i = 0; i < 256; i++) {
- radeon_crtc->lut_r[i] = radeon_crtc->lut_r_copy[i];
- radeon_crtc->lut_g[i] = radeon_crtc->lut_g_copy[i];
- radeon_crtc->lut_b[i] = radeon_crtc->lut_b_copy[i];
- }
-
- radeon_crtc_load_lut(crtc);
-}
-
/** Sets the color ramps on behalf of fbcon */
void radeon_crtc_fb_gamma_set(struct drm_crtc *crtc, u16 red, u16 green,
u16 blue, int regno)
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index c0bf8b7..590f6a1 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -355,11 +355,6 @@ int radeon_crtc_set_base_atomic(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
int x, int y, int enter)
{
- if (enter)
- radeon_crtc_save_lut(crtc);
- else
- radeon_crtc_restore_lut(crtc);
-
return radeon_crtc_do_set_base(crtc, fb, x, y, 1);
}
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
b/drivers/gpu/drm/radeon/radeon_mode.h
index 3cda63e..94eb184 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -255,7 +255,6 @@ struct radeon_crtc {
struct drm_crtc base;
int crtc_id;
u16 lut_r[256], lut_g[256], lut_b[256];
- u16 lut_r_copy[256], lut_g_copy[256], lut_b_copy[256];
bool enabled;
bool can_tile;
uint32_t crtc_offset;
@@ -517,8 +516,6 @@ extern int atombios_get_encoder_mode(struct drm_encoder
*encoder);
extern void radeon_encoder_set_active_device(struct drm_encoder *encoder);
extern void radeon_crtc_load_lut(struct drm_crtc *crtc);
-extern void radeon_crtc_save_lut(struct drm_crtc *crtc);
-extern void radeon_crtc_restore_lut(struct drm_crtc *crtc);
extern int atombios_crtc_set_base(struct drm_crtc *crtc, int x, int y,
struct drm_framebuffer *old_fb);
extern int atombios_crtc_set_base_atomic(struct drm_crtc *crtc,
--
1.6.3.3
[PATCH 0/3] atomic kernel mode setting fixups for drm-core-next
This patch series contains fixes against the original merge of the atomic kernel mode setting for the radeon and nouveau drivers. The first change is a revert of a prior patch that was radeon specific. It turns out, as David Airlie suspected, that a generic solution is needed for saving and restoring the R G B gamma values when using atomic kernel mode setting. The final patch in the series is a fix up per prior comments from Jesse Barnes about using enums vs passing lots of true and false values in the drm API calls. Thanks, Jason. --- The following changes since commit 26bf62e47261142d528a6109fdd671a2e280b4ea: Dave Airlie (1): Merge branch 'drm-radeon-next' of ../drm-radeon-next into drm-core-next -- Jason Wessel (3): Revert "radeon, kdb, kms: Save and restore the LUT on atomic KMS enter/exit" kdb,kms: Save and restore the LUT on atomic KMS enter/exit drm,kdb,kms: Change mode_set_base_atomic() enter argument to be an enum drivers/gpu/drm/drm_fb_helper.c | 31 +++-- drivers/gpu/drm/i915/intel_display.c|5 ++- drivers/gpu/drm/nouveau/nv04_crtc.c |4 +- drivers/gpu/drm/nouveau/nv50_crtc.c |2 +- drivers/gpu/drm/radeon/atombios_crtc.c |2 +- drivers/gpu/drm/radeon/radeon_display.c | 32 --- drivers/gpu/drm/radeon/radeon_legacy_crtc.c |7 +- drivers/gpu/drm/radeon/radeon_mode.h| 10 include/drm/drm_crtc_helper.h |7 +- 9 files changed, 47 insertions(+), 53 deletions(-)
[Bug 30188] X server crashes with a SIGBUS on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=30188 --- Comment #27 from Alex Deucher 2010-10-13 13:53:07 PDT --- This patch, scheduled hopefully for 2.6.36 should also fix the issue: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=c919b371cb734f42b1130e706ecee262f8d9261d -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30188] X server crashes with a SIGBUS on Evergreen
https://bugs.freedesktop.org/show_bug.cgi?id=30188 --- Comment #27 from Alex Deucher 2010-10-13 13:53:07 PDT --- This patch, scheduled hopefully for 2.6.36 should also fix the issue: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=c919b371cb734f42b1130e706ecee262f8d9261d -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH -next] gpu/drm: fix build errors and kconfig dependency warnings
On Wed, 13 Oct 2010 15:45:22 +1100 Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20101012:
>
> The drm tree gained a conflict against the kgdb tree.
ERROR: "hwmon_device_unregister" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
ERROR: "hwmon_device_register" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
ERROR: "video_output_unregister" [drivers/acpi/video.ko] undefined!
ERROR: "video_output_register" [drivers/acpi/video.ko] undefined!
The latter 2 are simple to fix:
in drivers/gpu/drm/nouveau/Kconfig, for config DRM_NOUVEAU:
@@ -11,6 +11,7 @@ config DRM_NOUVEAU
select FRAMEBUFFER_CONSOLE if !EMBEDDED
select FB_BACKLIGHT if DRM_NOUVEAU_BACKLIGHT
select ACPI_VIDEO if ACPI
+ select VIDEO_OUTPUT_CONTROL if ACPI
help
Choose this option for open-source nVidia support.
The first 2 are a problem. I'd like to add "depends on HWMON" to DRM_NOUVEAU,
but doing so gives:
drivers/video/Kconfig:30:error: recursive dependency detected!
drivers/video/Kconfig:30: symbol FB is selected by DRM_KMS_HELPER
drivers/gpu/drm/Kconfig:22: symbol DRM_KMS_HELPER is selected by DRM_NOUVEAU
drivers/gpu/drm/nouveau/Kconfig:1: symbol DRM_NOUVEAU depends on HWMON
drivers/hwmon/Kconfig:5:symbol HWMON is selected by THINKPAD_ACPI
drivers/platform/x86/Kconfig:232: symbol THINKPAD_ACPI depends on INPUT
drivers/input/Kconfig:8:symbol INPUT is selected by VT
drivers/char/Kconfig:7: symbol VT is selected by FB_STI
drivers/video/Kconfig:636: symbol FB_STI depends on FB
so that must not be the right thing to do. Aha, that change along with
changing all "select FB" (in drivers/gpu/drm/*) to "depends on FB"
fixes the kconfig warnings. But feel free to fix it some other way.
My working patch is below.
---
From: Randy Dunlap
Fix drm and drm/nouveau kconfigs so that build succeeds and
kconfig warnings are eliminated.
Fixes these build errors:
ERROR: "hwmon_device_unregister" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
ERROR: "hwmon_device_register" [drivers/gpu/drm/nouveau/nouveau.ko] undefined!
ERROR: "video_output_unregister" [drivers/acpi/video.ko] undefined!
ERROR: "video_output_register" [drivers/acpi/video.ko] undefined!
Signed-off-by: Randy Dunlap
---
drivers/gpu/drm/Kconfig |2 +-
drivers/gpu/drm/nouveau/Kconfig |5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
--- linux-next-20101013.orig/drivers/gpu/drm/nouveau/Kconfig
+++ linux-next-20101013/drivers/gpu/drm/nouveau/Kconfig
@@ -1,16 +1,17 @@
config DRM_NOUVEAU
tristate "Nouveau (nVidia) cards"
- depends on DRM && PCI
+ depends on DRM && PCI && HWMON
+ depends on FB
select FW_LOADER
select DRM_KMS_HELPER
select DRM_TTM
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
- select FB
select FRAMEBUFFER_CONSOLE if !EMBEDDED
select FB_BACKLIGHT if DRM_NOUVEAU_BACKLIGHT
select ACPI_VIDEO if ACPI
+ select VIDEO_OUTPUT_CONTROL if ACPI
help
Choose this option for open-source nVidia support.
--- linux-next-20101013.orig/drivers/gpu/drm/Kconfig
+++ linux-next-20101013/drivers/gpu/drm/Kconfig
@@ -22,7 +22,7 @@ menuconfig DRM
config DRM_KMS_HELPER
tristate
depends on DRM
- select FB
+ depends on FB
select FRAMEBUFFER_CONSOLE if !EMBEDDED
help
FB and CRTC helpers for KMS drivers.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] gpu/drm: fix build errors and kconfig dependency warnings
On Wed, 13 Oct 2010 15:45:22 +1100 Stephen Rothwell wrote: > Hi all, > > Changes since 20101012: > > The drm tree gained a conflict against the kgdb tree. ERROR: "hwmon_device_unregister" [drivers/gpu/drm/nouveau/nouveau.ko] undefined! ERROR: "hwmon_device_register" [drivers/gpu/drm/nouveau/nouveau.ko] undefined! ERROR: "video_output_unregister" [drivers/acpi/video.ko] undefined! ERROR: "video_output_register" [drivers/acpi/video.ko] undefined! The latter 2 are simple to fix: in drivers/gpu/drm/nouveau/Kconfig, for config DRM_NOUVEAU: @@ -11,6 +11,7 @@ config DRM_NOUVEAU select FRAMEBUFFER_CONSOLE if !EMBEDDED select FB_BACKLIGHT if DRM_NOUVEAU_BACKLIGHT select ACPI_VIDEO if ACPI + select VIDEO_OUTPUT_CONTROL if ACPI help Choose this option for open-source nVidia support. The first 2 are a problem. I'd like to add "depends on HWMON" to DRM_NOUVEAU, but doing so gives: drivers/video/Kconfig:30:error: recursive dependency detected! drivers/video/Kconfig:30: symbol FB is selected by DRM_KMS_HELPER drivers/gpu/drm/Kconfig:22: symbol DRM_KMS_HELPER is selected by DRM_NOUVEAU drivers/gpu/drm/nouveau/Kconfig:1: symbol DRM_NOUVEAU depends on HWMON drivers/hwmon/Kconfig:5:symbol HWMON is selected by THINKPAD_ACPI drivers/platform/x86/Kconfig:232: symbol THINKPAD_ACPI depends on INPUT drivers/input/Kconfig:8:symbol INPUT is selected by VT drivers/char/Kconfig:7: symbol VT is selected by FB_STI drivers/video/Kconfig:636: symbol FB_STI depends on FB so that must not be the right thing to do. Aha, that change along with changing all "select FB" (in drivers/gpu/drm/*) to "depends on FB" fixes the kconfig warnings. But feel free to fix it some other way. My working patch is below. --- From: Randy Dunlap Fix drm and drm/nouveau kconfigs so that build succeeds and kconfig warnings are eliminated. Fixes these build errors: ERROR: "hwmon_device_unregister" [drivers/gpu/drm/nouveau/nouveau.ko] undefined! ERROR: "hwmon_device_register" [drivers/gpu/drm/nouveau/nouveau.ko] undefined! ERROR: "video_output_unregister" [drivers/acpi/video.ko] undefined! ERROR: "video_output_register" [drivers/acpi/video.ko] undefined! Signed-off-by: Randy Dunlap --- drivers/gpu/drm/Kconfig |2 +- drivers/gpu/drm/nouveau/Kconfig |5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) --- linux-next-20101013.orig/drivers/gpu/drm/nouveau/Kconfig +++ linux-next-20101013/drivers/gpu/drm/nouveau/Kconfig @@ -1,16 +1,17 @@ config DRM_NOUVEAU tristate "Nouveau (nVidia) cards" - depends on DRM && PCI + depends on DRM && PCI && HWMON + depends on FB select FW_LOADER select DRM_KMS_HELPER select DRM_TTM select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT - select FB select FRAMEBUFFER_CONSOLE if !EMBEDDED select FB_BACKLIGHT if DRM_NOUVEAU_BACKLIGHT select ACPI_VIDEO if ACPI + select VIDEO_OUTPUT_CONTROL if ACPI help Choose this option for open-source nVidia support. --- linux-next-20101013.orig/drivers/gpu/drm/Kconfig +++ linux-next-20101013/drivers/gpu/drm/Kconfig @@ -22,7 +22,7 @@ menuconfig DRM config DRM_KMS_HELPER tristate depends on DRM - select FB + depends on FB select FRAMEBUFFER_CONSOLE if !EMBEDDED help FB and CRTC helpers for KMS drivers.
[PATCH 3/3] drm, kdb, kms: Change mode_set_base_atomic() enter argument to be an enum
The enter argument as implemented by commit 413d45d3627 (drm, kdb, kms:
Add an enter argument to mode_set_base_atomic() API) should be more
descriptive as to what it does vs just passing 1 and 0 around.
There is no runtime behavior change as a result of this patch.
Reported-by: Jesse Barnes
Signed-off-by: Jason Wessel
CC: David Airlie
CC: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_fb_helper.c |5 ++---
drivers/gpu/drm/i915/intel_display.c|5 +++--
drivers/gpu/drm/nouveau/nv04_crtc.c |4 ++--
drivers/gpu/drm/nouveau/nv50_crtc.c |2 +-
drivers/gpu/drm/radeon/atombios_crtc.c |2 +-
drivers/gpu/drm/radeon/radeon_legacy_crtc.c |2 +-
drivers/gpu/drm/radeon/radeon_mode.h|7 +--
include/drm/drm_crtc_helper.h |7 ++-
8 files changed, 21 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 8208e19..d2849e4 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -289,8 +289,7 @@ int drm_fb_helper_debug_enter(struct fb_info *info)
mode_set->fb,
mode_set->x,
mode_set->y,
- 1);
-
+ ENTER_ATOMIC_MODE_SET);
}
}
@@ -336,7 +335,7 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
drm_fb_helper_restore_lut_atomic(mode_set->crtc);
funcs->mode_set_base_atomic(mode_set->crtc, fb, crtc->x,
- crtc->y, 0);
+ crtc->y, LEAVE_ATOMIC_MODE_SET);
}
return 0;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9109c00..96d08a9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1492,7 +1492,7 @@ err_unpin:
/* Assume fb object is pinned & idle & fenced and just update base pointers */
static int
intel_pipe_set_base_atomic(struct drm_crtc *crtc, struct drm_framebuffer *fb,
- int x, int y, int enter)
+ int x, int y, enum mode_set_atomic state)
{
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -1614,7 +1614,8 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
atomic_read(&obj_priv->pending_flip) == 0);
}
- ret = intel_pipe_set_base_atomic(crtc, crtc->fb, x, y, 0);
+ ret = intel_pipe_set_base_atomic(crtc, crtc->fb, x, y,
+LEAVE_ATOMIC_MODE_SET);
if (ret) {
i915_gem_object_unpin(to_intel_framebuffer(crtc->fb)->obj);
mutex_unlock(&dev->struct_mutex);
diff --git a/drivers/gpu/drm/nouveau/nv04_crtc.c
b/drivers/gpu/drm/nouveau/nv04_crtc.c
index 17f7cf0..c71abc2 100644
--- a/drivers/gpu/drm/nouveau/nv04_crtc.c
+++ b/drivers/gpu/drm/nouveau/nv04_crtc.c
@@ -860,12 +860,12 @@ nv04_crtc_mode_set_base(struct drm_crtc *crtc, int x, int
y,
static int
nv04_crtc_mode_set_base_atomic(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
- int x, int y, int enter)
+ int x, int y, enum mode_set_atomic state)
{
struct drm_nouveau_private *dev_priv = crtc->dev->dev_private;
struct drm_device *dev = dev_priv->dev;
- if (enter)
+ if (state == ENTER_ATOMIC_MODE_SET)
nouveau_fbcon_save_disable_accel(dev);
else
nouveau_fbcon_restore_accel(dev);
diff --git a/drivers/gpu/drm/nouveau/nv50_crtc.c
b/drivers/gpu/drm/nouveau/nv50_crtc.c
index ba91bef..16380d5 100644
--- a/drivers/gpu/drm/nouveau/nv50_crtc.c
+++ b/drivers/gpu/drm/nouveau/nv50_crtc.c
@@ -708,7 +708,7 @@ nv50_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
static int
nv50_crtc_mode_set_base_atomic(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
- int x, int y, int enter)
+ int x, int y, enum mode_set_atomic state)
{
return nv50_crtc_do_mode_set_base(crtc, fb, x, y, true, true);
}
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 037e326..348b367 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -1258,7 +1258,7 @@ int atombios_crtc_set_base(struct drm_crtc *crtc, int x,
int y,
int atombios_crtc_set_base_atomic(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
- int x, int y, int enter)
+
[PATCH 2/3] kdb, kms: Save and restore the LUT on atomic KMS enter/exit
When changing VTs non-atomically the kernel works in conjunction with
the Xserver in user space and receives the LUT information from the
Xserver via a system call. When changing modes atomically for kdb,
this information must be saved and restored without disturbing user
space as if nothing ever happened.
There is a short cut used by this patch where gamma_store is used as
the save space. If this turns out to be a problem in the future a
pre-allocated chunk of memory will be required for each crtc to save
and restore the LUT information.
Signed-off-by: Jason Wessel
CC: Jesse Barnes
CC: David Airlie
CC: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/drm_fb_helper.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 625a2d5..8208e19 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -242,6 +242,30 @@ static int drm_fb_helper_parse_command_line(struct
drm_fb_helper *fb_helper)
return 0;
}
+static void drm_fb_helper_save_lut_atomic(struct drm_crtc *crtc, struct
drm_fb_helper *helper)
+{
+ uint16_t *r_base, *g_base, *b_base;
+ int i;
+
+ r_base = crtc->gamma_store;
+ g_base = r_base + crtc->gamma_size;
+ b_base = g_base + crtc->gamma_size;
+
+ for (i = 0; i < crtc->gamma_size; i++)
+ helper->funcs->gamma_get(crtc, &r_base[i], &g_base[i],
&b_base[i], i);
+}
+
+static void drm_fb_helper_restore_lut_atomic(struct drm_crtc *crtc)
+{
+ uint16_t *r_base, *g_base, *b_base;
+
+ r_base = crtc->gamma_store;
+ g_base = r_base + crtc->gamma_size;
+ b_base = g_base + crtc->gamma_size;
+
+ crtc->funcs->gamma_set(crtc, r_base, g_base, b_base, 0,
crtc->gamma_size);
+}
+
int drm_fb_helper_debug_enter(struct fb_info *info)
{
struct drm_fb_helper *helper = info->par;
@@ -260,6 +284,7 @@ int drm_fb_helper_debug_enter(struct fb_info *info)
continue;
funcs = mode_set->crtc->helper_private;
+ drm_fb_helper_save_lut_atomic(mode_set->crtc, helper);
funcs->mode_set_base_atomic(mode_set->crtc,
mode_set->fb,
mode_set->x,
@@ -309,6 +334,7 @@ int drm_fb_helper_debug_leave(struct fb_info *info)
continue;
}
+ drm_fb_helper_restore_lut_atomic(mode_set->crtc);
funcs->mode_set_base_atomic(mode_set->crtc, fb, crtc->x,
crtc->y, 0);
}
--
1.6.3.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] atomic kernel mode setting fixups for drm-core-next
This patch series contains fixes against the original merge of the atomic kernel mode setting for the radeon and nouveau drivers. The first change is a revert of a prior patch that was radeon specific. It turns out, as David Airlie suspected, that a generic solution is needed for saving and restoring the R G B gamma values when using atomic kernel mode setting. The final patch in the series is a fix up per prior comments from Jesse Barnes about using enums vs passing lots of true and false values in the drm API calls. Thanks, Jason. --- The following changes since commit 26bf62e47261142d528a6109fdd671a2e280b4ea: Dave Airlie (1): Merge branch 'drm-radeon-next' of ../drm-radeon-next into drm-core-next -- Jason Wessel (3): Revert "radeon, kdb, kms: Save and restore the LUT on atomic KMS enter/exit" kdb,kms: Save and restore the LUT on atomic KMS enter/exit drm,kdb,kms: Change mode_set_base_atomic() enter argument to be an enum drivers/gpu/drm/drm_fb_helper.c | 31 +++-- drivers/gpu/drm/i915/intel_display.c|5 ++- drivers/gpu/drm/nouveau/nv04_crtc.c |4 +- drivers/gpu/drm/nouveau/nv50_crtc.c |2 +- drivers/gpu/drm/radeon/atombios_crtc.c |2 +- drivers/gpu/drm/radeon/radeon_display.c | 32 --- drivers/gpu/drm/radeon/radeon_legacy_crtc.c |7 +- drivers/gpu/drm/radeon/radeon_mode.h| 10 include/drm/drm_crtc_helper.h |7 +- 9 files changed, 47 insertions(+), 53 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] Revert "radeon, kdb, kms: Save and restore the LUT on atomic KMS enter/exit"
This reverts commit ff773714dd30b802c336064109c535d8b2774e2f.
A generic solution is needed to save and retore the LUT information.
CC: Jesse Barnes
CC: David Airlie
CC: dri-devel@lists.freedesktop.org
Signed-off-by: Jason Wessel
---
drivers/gpu/drm/radeon/radeon_display.c | 32 ---
drivers/gpu/drm/radeon/radeon_legacy_crtc.c |5
drivers/gpu/drm/radeon/radeon_mode.h|3 --
3 files changed, 0 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 6c6846c..fd70b84 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -138,38 +138,6 @@ void radeon_crtc_load_lut(struct drm_crtc *crtc)
legacy_crtc_load_lut(crtc);
}
-void radeon_crtc_save_lut(struct drm_crtc *crtc)
-{
- struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
- int i;
-
- if (!crtc->enabled)
- return;
-
- for (i = 0; i < 256; i++) {
- radeon_crtc->lut_r_copy[i] = radeon_crtc->lut_r[i];
- radeon_crtc->lut_g_copy[i] = radeon_crtc->lut_g[i];
- radeon_crtc->lut_b_copy[i] = radeon_crtc->lut_b[i];
- }
-}
-
-void radeon_crtc_restore_lut(struct drm_crtc *crtc)
-{
- struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
- int i;
-
- if (!crtc->enabled)
- return;
-
- for (i = 0; i < 256; i++) {
- radeon_crtc->lut_r[i] = radeon_crtc->lut_r_copy[i];
- radeon_crtc->lut_g[i] = radeon_crtc->lut_g_copy[i];
- radeon_crtc->lut_b[i] = radeon_crtc->lut_b_copy[i];
- }
-
- radeon_crtc_load_lut(crtc);
-}
-
/** Sets the color ramps on behalf of fbcon */
void radeon_crtc_fb_gamma_set(struct drm_crtc *crtc, u16 red, u16 green,
u16 blue, int regno)
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index c0bf8b7..590f6a1 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -355,11 +355,6 @@ int radeon_crtc_set_base_atomic(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
int x, int y, int enter)
{
- if (enter)
- radeon_crtc_save_lut(crtc);
- else
- radeon_crtc_restore_lut(crtc);
-
return radeon_crtc_do_set_base(crtc, fb, x, y, 1);
}
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
b/drivers/gpu/drm/radeon/radeon_mode.h
index 3cda63e..94eb184 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -255,7 +255,6 @@ struct radeon_crtc {
struct drm_crtc base;
int crtc_id;
u16 lut_r[256], lut_g[256], lut_b[256];
- u16 lut_r_copy[256], lut_g_copy[256], lut_b_copy[256];
bool enabled;
bool can_tile;
uint32_t crtc_offset;
@@ -517,8 +516,6 @@ extern int atombios_get_encoder_mode(struct drm_encoder
*encoder);
extern void radeon_encoder_set_active_device(struct drm_encoder *encoder);
extern void radeon_crtc_load_lut(struct drm_crtc *crtc);
-extern void radeon_crtc_save_lut(struct drm_crtc *crtc);
-extern void radeon_crtc_restore_lut(struct drm_crtc *crtc);
extern int atombios_crtc_set_base(struct drm_crtc *crtc, int x, int y,
struct drm_framebuffer *old_fb);
extern int atombios_crtc_set_base_atomic(struct drm_crtc *crtc,
--
1.6.3.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/ttm: Optimize delayed buffer destruction
This commit replaces the ttm_bo_cleanup_ref function with two new functions.
One for the case where the bo is not yet on the delayed destroy list, and
one for the case where the bo was on the delayed destroy list, at least at
the time of call. This makes it possible to optimize the two cases somewhat.
It also enables the possibility to directly destroy buffers on the
delayed delete list when they are about to be evicted or swapped out.
Currently they were only evicted / swapped and destruction was left for the
delayed buffer destruction thread.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c | 171 ++
1 files changed, 107 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 7497b79..2936629 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -460,99 +460,122 @@ static void ttm_bo_cleanup_memtype_use(struct
ttm_buffer_object *bo)
wake_up_all(&bo->event_queue);
}
-
-/**
- * If bo idle, remove from delayed- and lru lists, and unref.
- * If not idle, and already on delayed list, do nothing.
- * If not idle, and not on delayed list, put on delayed list,
- * up the list_kref and schedule a delayed list check.
- */
-
-static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo, bool remove_all)
+static void ttm_bo_cleanup_refs_or_queue(struct ttm_buffer_object *bo)
{
struct ttm_bo_device *bdev = bo->bdev;
struct ttm_bo_global *glob = bo->glob;
- struct ttm_bo_driver *driver = bdev->driver;
+ struct ttm_bo_driver *driver;
+ void *sync_obj;
+ void *sync_obj_arg;
+ int put_count;
int ret;
spin_lock(&bo->lock);
-retry:
- (void) ttm_bo_wait(bo, false, false, !remove_all);
-
+ (void) ttm_bo_wait(bo, false, false, true);
if (!bo->sync_obj) {
- int put_count;
-
- spin_unlock(&bo->lock);
spin_lock(&glob->lru_lock);
- ret = ttm_bo_reserve_locked(bo, false, !remove_all, false, 0);
/**
-* Someone else has the object reserved. Bail and retry.
+* Lock inversion between bo::reserve and bo::lock here,
+* but that's OK, since we're only trylocking.
*/
- if (unlikely(ret == -EBUSY)) {
- spin_unlock(&glob->lru_lock);
- spin_lock(&bo->lock);
- goto requeue;
- }
-
- /**
-* We can re-check for sync object without taking
-* the bo::lock since setting the sync object requires
-* also bo::reserved. A busy object at this point may
-* be caused by another thread starting an accelerated
-* eviction.
-*/
+ ret = ttm_bo_reserve_locked(bo, false, true, false, 0);
- if (unlikely(bo->sync_obj)) {
- atomic_set(&bo->reserved, 0);
- wake_up_all(&bo->event_queue);
- spin_unlock(&glob->lru_lock);
- spin_lock(&bo->lock);
- if (remove_all)
- goto retry;
- else
- goto requeue;
- }
+ if (unlikely(ret == -EBUSY))
+ goto queue;
+ spin_unlock(&bo->lock);
put_count = ttm_bo_del_from_lru(bo);
- if (!list_empty(&bo->ddestroy)) {
- list_del_init(&bo->ddestroy);
- ++put_count;
- }
+ spin_unlock(&glob->lru_lock);
ttm_bo_cleanup_memtype_use(bo);
while (put_count--)
kref_put(&bo->list_kref, ttm_bo_ref_bug);
- return 0;
+ return;
+ } else {
+ spin_lock(&glob->lru_lock);
}
-requeue:
+queue:
+ sync_obj = bo->sync_obj;
+ sync_obj_arg = bo->sync_obj_arg;
+ driver = bdev->driver;
+
+ kref_get(&bo->list_kref);
+ list_add_tail(&bo->ddestroy, &bdev->ddestroy);
+ spin_unlock(&glob->lru_lock);
+ spin_unlock(&bo->lock);
+
+ if (sync_obj)
+ driver->sync_obj_flush(sync_obj, sync_obj_arg);
+ schedule_delayed_work(&bdev->wq,
+ ((HZ / 100) < 1) ? 1 : HZ / 100);
+}
+
+/**
+ * function ttm_bo_cleanup_refs
+ * If bo idle, remove from delayed- and lru lists, and unref.
+ * If not idle, do nothing.
+ *
+ * @interruptible Any sleeps should occur interruptibly.
+ * @no_wait_reserve Never wait for reserve. Return -EBUSY instead.
+ * @no_wait_gpu Never wait for gpu. Return -EBUSY instead.
+ */
+
+static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
+ boo
[PATCH 1/2] drm/ttm: Avoid using the ttm_mem_type_manager::put_locked function
Release the lru spinlock early.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c | 30 +-
drivers/gpu/drm/ttm/ttm_bo_manager.c | 10 --
include/drm/ttm/ttm_bo_driver.h |2 --
3 files changed, 5 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index fd8344d..7497b79 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -439,36 +439,25 @@ out_err:
}
/**
- * Call bo::reserved and with the lru lock held.
+ * Call bo::reserved.
* Will release GPU memory type usage on destruction.
- * This is the place to put in driver specific hooks.
- * Will release the bo::reserved lock and the
- * lru lock on exit.
+ * This is the place to put in driver specific hooks to release
+ * driver private resources.
+ * Will release the bo::reserved lock.
*/
static void ttm_bo_cleanup_memtype_use(struct ttm_buffer_object *bo)
{
- struct ttm_bo_global *glob = bo->glob;
-
if (bo->ttm) {
-
- /**
-* Release the lru_lock, since we don't want to have
-* an atomic requirement on ttm_tt[unbind|destroy].
-*/
-
- spin_unlock(&glob->lru_lock);
ttm_tt_unbind(bo->ttm);
ttm_tt_destroy(bo->ttm);
bo->ttm = NULL;
- spin_lock(&glob->lru_lock);
}
- ttm_bo_mem_put_locked(bo, &bo->mem);
+ ttm_bo_mem_put(bo, &bo->mem);
atomic_set(&bo->reserved, 0);
wake_up_all(&bo->event_queue);
- spin_unlock(&glob->lru_lock);
}
@@ -788,15 +777,6 @@ void ttm_bo_mem_put(struct ttm_buffer_object *bo, struct
ttm_mem_reg *mem)
}
EXPORT_SYMBOL(ttm_bo_mem_put);
-void ttm_bo_mem_put_locked(struct ttm_buffer_object *bo, struct ttm_mem_reg
*mem)
-{
- struct ttm_mem_type_manager *man = &bo->bdev->man[mem->mem_type];
-
- if (mem->mm_node)
- (*man->func->put_node_locked)(man, mem);
-}
-EXPORT_SYMBOL(ttm_bo_mem_put_locked);
-
/**
* Repeatedly evict memory from the LRU for @mem_type until we create enough
* space, or we've evicted everything and there isn't enough space.
diff --git a/drivers/gpu/drm/ttm/ttm_bo_manager.c
b/drivers/gpu/drm/ttm/ttm_bo_manager.c
index 35c97b2..7410c19 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_manager.c
@@ -90,15 +90,6 @@ static void ttm_bo_man_put_node(struct ttm_mem_type_manager
*man,
}
}
-static void ttm_bo_man_put_node_locked(struct ttm_mem_type_manager *man,
- struct ttm_mem_reg *mem)
-{
- if (mem->mm_node) {
- drm_mm_put_block(mem->mm_node);
- mem->mm_node = NULL;
- }
-}
-
static int ttm_bo_man_init(struct ttm_mem_type_manager *man,
unsigned long p_size)
{
@@ -152,7 +143,6 @@ const struct ttm_mem_type_manager_func ttm_bo_manager_func
= {
ttm_bo_man_takedown,
ttm_bo_man_get_node,
ttm_bo_man_put_node,
- ttm_bo_man_put_node_locked,
ttm_bo_man_debug
};
EXPORT_SYMBOL(ttm_bo_manager_func);
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index d0ff529..d01b4dd 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -214,8 +214,6 @@ struct ttm_mem_type_manager_func {
struct ttm_mem_reg *mem);
void (*put_node)(struct ttm_mem_type_manager *man,
struct ttm_mem_reg *mem);
- void (*put_node_locked)(struct ttm_mem_type_manager *man,
- struct ttm_mem_reg *mem);
void (*debug)(struct ttm_mem_type_manager *man, const char *prefix);
};
--
1.6.2.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/0] ttm patches for drm-next
These patches attempt to optimize the delayed destroy handling. The first patch removes the need for the newly introduced mem_put_locked callback. The second patch optimizes the delayed buffer destruction somewhat, but has not yet seen extensive testing. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30694] wincopy will crash on r600g when going to front buffer
https://bugs.freedesktop.org/show_bug.cgi?id=30694 Kevin DeKorte changed: What|Removed |Added Component|Mesa core |Drivers/Gallium/r600 AssignedTo|mesa-...@lists.freedesktop. |dri-de...@lists.freedesktop |org |.org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30694] wincopy will crash on r600g when going to front buffer
https://bugs.freedesktop.org/show_bug.cgi?id=30694 Kevin DeKorte changed: What|Removed |Added Component|Mesa core |Drivers/Gallium/r600 AssignedTo|mesa-dev at lists.freedesktop. |dri-devel at lists.freedesktop |org |.org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30823] r300: Implementation error: Bad param 40
https://bugs.freedesktop.org/show_bug.cgi?id=30823 --- Comment #3 from Fabio Pedretti 2010-10-13 04:47:57 PDT --- I can't see any difference between 7.9 and master (there are some minor glitches on both however). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30823] r300: Implementation error: Bad param 40
https://bugs.freedesktop.org/show_bug.cgi?id=30823 --- Comment #3 from Fabio Pedretti 2010-10-13 04:47:57 PDT --- I can't see any difference between 7.9 and master (there are some minor glitches on both however). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30823] r300: Implementation error: Bad param 40
https://bugs.freedesktop.org/show_bug.cgi?id=30823 --- Comment #2 from Marek Olšák 2010-10-13 04:03:37 PDT --- Ignore that Bad param message, it's not important. The other messages are weird, Wine should not ask for float textures if the driver doesn't support them. Are there any rendering issues? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30823] r300: Implementation error: Bad param 40
https://bugs.freedesktop.org/show_bug.cgi?id=30823 --- Comment #2 from Marek Ol??k 2010-10-13 04:03:37 PDT --- Ignore that Bad param message, it's not important. The other messages are weird, Wine should not ask for float textures if the driver doesn't support them. Are there any rendering issues? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 29244] [wine][r300g] Spore Creature Creator segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=29244 --- Comment #7 from Fabio Pedretti 2010-10-13 01:43:48 PDT --- (In reply to comment #6) > I guess you guys are all running Mesa master. Could you please test the 7.9 > branch as well? It's fixed in 7.9 branch and also runs better here. With master I am indeed getting this: https://bugs.freedesktop.org/show_bug.cgi?id=30823 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29244] [wine][r300g] Spore Creature Creator segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=29244 --- Comment #7 from Fabio Pedretti 2010-10-13 01:43:48 PDT --- (In reply to comment #6) > I guess you guys are all running Mesa master. Could you please test the 7.9 > branch as well? It's fixed in 7.9 branch and also runs better here. With master I am indeed getting this: https://bugs.freedesktop.org/show_bug.cgi?id=30823 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30823] r300: Implementation error: Bad param 40
https://bugs.freedesktop.org/show_bug.cgi?id=30823 --- Comment #1 from Fabio Pedretti 2010-10-13 01:41:14 PDT --- Created an attachment (id=39410) --> (https://bugs.freedesktop.org/attachment.cgi?id=39410) wine output with mesa 7.9 branch -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30823] New: r300: Implementation error: Bad param 40
https://bugs.freedesktop.org/show_bug.cgi?id=30823 Summary: r300: Implementation error: Bad param 40 Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: fabio@libero.it Created an attachment (id=39409) --> (https://bugs.freedesktop.org/attachment.cgi?id=39409) wine output with mesa master Running the game Panzer II with wine 1.2.1 using mesa from git master I get many errors that don't show up when running with the 7.9 branch. Wine outputs with master and 7.9 are attached. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 30823] r300: Implementation error: Bad param 40
https://bugs.freedesktop.org/show_bug.cgi?id=30823 --- Comment #1 from Fabio Pedretti 2010-10-13 01:41:14 PDT --- Created an attachment (id=39410) --> (https://bugs.freedesktop.org/attachment.cgi?id=39410) wine output with mesa 7.9 branch -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 30823] New: r300: Implementation error: Bad param 40
https://bugs.freedesktop.org/show_bug.cgi?id=30823 Summary: r300: Implementation error: Bad param 40 Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: fabio.ped at libero.it Created an attachment (id=39409) --> (https://bugs.freedesktop.org/attachment.cgi?id=39409) wine output with mesa master Running the game Panzer II with wine 1.2.1 using mesa from git master I get many errors that don't show up when running with the 7.9 branch. Wine outputs with master and 7.9 are attached. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
