[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #24 from Alexandre Demers  ---
I'll retest it with the latest two patches, but I think setting gfxpayload=text
prevents the bug. I know for sure that with the index patch, suspend/resume
cycle is fixed. Also, if I remove gfxpayload=keep completely, my monitor works
fine.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/c795c2c8/attachment.html>


[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #23 from Alex Deucher  ---
(In reply to comment #19)
> Should I try to combine patch 69113
> and patch 69370 with the others?

Worth a shot.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/1f5529fe/attachment.html>


[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #22 from Alexandre Demers  ---
(In reply to comment #21)
> (In reply to comment #19)
> > If I followed you correctly, setting bit 24 to "1" disables memory but keeps
> > the CRTC state as it is (hopefully in sync with the monitor). However, what
> > I see when grub2 kicks in with the "gfxpayload=keep" is an unsynced monitor.
> > Sometimes the display will be black, other times it will only appear in the
> > first couple of vertical lines, in others it will be vertically synced but
> > shifted to the right at half or at two third of the screen. In other words,
> > this really seems to be a sync problem. Should I try to combine patch 69113
> > and patch 69370 with the others?
> 
> Are you saying the monitor gets messed up when grub kicks in?  I.e., before
> the OS loads?  If so, that sounds like a grub issue.

I'll take some pictures or record a small video of what's going on. That will
be easier to understand. But yes, I'm beginning to think Grub2 is playing a bad
trick somewhere in there and is not playing nicely when handling the
framebuffer.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/eb4d8f75/attachment.html>


[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #21 from Alex Deucher  ---
(In reply to comment #19)
> If I followed you correctly, setting bit 24 to "1" disables memory but keeps
> the CRTC state as it is (hopefully in sync with the monitor). However, what
> I see when grub2 kicks in with the "gfxpayload=keep" is an unsynced monitor.
> Sometimes the display will be black, other times it will only appear in the
> first couple of vertical lines, in others it will be vertically synced but
> shifted to the right at half or at two third of the screen. In other words,
> this really seems to be a sync problem. Should I try to combine patch 69113
> and patch 69370 with the others?

Are you saying the monitor gets messed up when grub kicks in?  I.e., before the
OS loads?  If so, that sounds like a grub issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/f1dd5436/attachment.html>


[PATCH 4/4] drm/ttm: remove ttm_mem_global->queue

2012-11-06 Thread Marcin Slusarz
It's unused.

Signed-off-by: Marcin Slusarz 
Cc: Thomas Hellstrom 
---
 drivers/gpu/drm/ttm/ttm_memory.c | 1 -
 include/drm/ttm/ttm_memory.h | 2 --
 2 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 479c6b0..dbc2def 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -367,7 +367,6 @@ int ttm_mem_global_init(struct ttm_mem_global *glob)
spin_lock_init(>lock);
glob->swap_queue = create_singlethread_workqueue("ttm_swap");
INIT_WORK(>work, ttm_shrink_work);
-   init_waitqueue_head(>queue);
ret = kobject_init_and_add(
>kobj, _mem_glob_kobj_type, ttm_get_kobj(), 
"memory_accounting");
if (unlikely(ret != 0)) {
diff --git a/include/drm/ttm/ttm_memory.h b/include/drm/ttm/ttm_memory.h
index d6d1da4..72dcbe8 100644
--- a/include/drm/ttm/ttm_memory.h
+++ b/include/drm/ttm/ttm_memory.h
@@ -60,7 +60,6 @@ struct ttm_mem_shrink {
  * for the GPU, and this will otherwise block other workqueue tasks(?)
  * At this point we use only a single-threaded workqueue.
  * @work: The workqueue callback for the shrink queue.
- * @queue: Wait queue for processes suspended waiting for memory.
  * @lock: Lock to protect the @shrink - and the memory accounting members,
  * that is, essentially the whole structure with some exceptions.
  * @zones: Array of pointers to accounting zones.
@@ -80,7 +79,6 @@ struct ttm_mem_global {
struct ttm_mem_shrink *shrink;
struct workqueue_struct *swap_queue;
struct work_struct work;
-   wait_queue_head_t queue;
spinlock_t lock;
struct ttm_mem_zone *zones[TTM_MEM_MAX_ZONES];
unsigned int num_zones;
-- 
1.7.12



[PATCH 3/4] drm/ttm: remove ttm_bo_device->nice_mode

2012-11-06 Thread Marcin Slusarz
It's unused.

Signed-off-by: Marcin Slusarz 
Cc: Thomas Hellstrom 
---
 drivers/gpu/drm/ttm/ttm_bo.c| 1 -
 include/drm/ttm/ttm_bo_driver.h | 3 ---
 2 files changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 412486c..da7a985 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1570,7 +1570,6 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
goto out_no_addr_mm;

INIT_DELAYED_WORK(>wq, ttm_bo_delayed_workqueue);
-   bdev->nice_mode = true;
INIT_LIST_HEAD(>ddestroy);
bdev->dev_mapping = NULL;
bdev->glob = glob;
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index d803b92..95628e7 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -521,8 +521,6 @@ struct ttm_bo_global {
  * lru_lock: Spinlock that protects the buffer+device lru lists and
  * ddestroy lists.
  * @val_seq: Current validation sequence.
- * @nice_mode: Try nicely to wait for buffer idle when cleaning a manager.
- * If a GPU lockup has been detected, this is forced to 0.
  * @dev_mapping: A pointer to the struct address_space representing the
  * device address space.
  * @wq: Work queue structure for the delayed delete workqueue.
@@ -556,7 +554,6 @@ struct ttm_bo_device {
 * Protected by load / firstopen / lastclose /unload sync.
 */

-   bool nice_mode;
struct address_space *dev_mapping;

/*
-- 
1.7.12



[PATCH 2/4] drm/ttm: remove persistent_swap_storage argument from ttm_bo_init/ttm_bo_create

2012-11-06 Thread Marcin Slusarz
All drivers pass NULL here. ttm_buffer_object's field can still be set after
init, just like nouveau does.

Signed-off-by: Marcin Slusarz 
Cc: Thomas Hellstrom 
---
 drivers/gpu/drm/ast/ast_ttm.c|  7 +++
 drivers/gpu/drm/cirrus/cirrus_ttm.c  |  2 +-
 drivers/gpu/drm/mgag200/mgag200_ttm.c|  2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c |  7 +++
 drivers/gpu/drm/radeon/radeon_object.c   |  6 +++---
 drivers/gpu/drm/ttm/ttm_bo.c |  7 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |  3 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |  8 +++-
 include/drm/ttm/ttm_bo_api.h | 16 +++-
 9 files changed, 20 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 0a54f65..c6dcc84 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -354,10 +354,9 @@ int ast_bo_create(struct drm_device *dev, int size, int 
align,
acc_size = ttm_bo_dma_acc_size(>ttm.bdev, size,
   sizeof(struct ast_bo));

-   ret = ttm_bo_init(>ttm.bdev, >bo, size,
- ttm_bo_type_device, >placement,
- align >> PAGE_SHIFT, false, NULL, acc_size,
- NULL, ast_bo_ttm_destroy);
+   ret = ttm_bo_init(>ttm.bdev, >bo, size, ttm_bo_type_device,
+ >placement, align >> PAGE_SHIFT, false,
+ acc_size, NULL, ast_bo_ttm_destroy);
if (ret)
return ret;

diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index 90d7701..65e665f 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -361,7 +361,7 @@ int cirrus_bo_create(struct drm_device *dev, int size, int 
align,

ret = ttm_bo_init(>ttm.bdev, >bo, size,
  ttm_bo_type_device, >placement,
- align >> PAGE_SHIFT, false, NULL, acc_size,
+ align >> PAGE_SHIFT, false, acc_size,
  NULL, cirrus_bo_ttm_destroy);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c 
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index 49d60a6..be121d1 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -355,7 +355,7 @@ int mgag200_bo_create(struct drm_device *dev, int size, int 
align,

ret = ttm_bo_init(>ttm.bdev, >bo, size,
  ttm_bo_type_device, >placement,
- align >> PAGE_SHIFT, false, NULL, acc_size,
+ align >> PAGE_SHIFT, false, acc_size,
  NULL, mgag200_bo_ttm_destroy);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 3cbf1a8..82f0f3c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -223,10 +223,9 @@ nouveau_bo_new(struct drm_device *dev, int size, int align,
acc_size = ttm_bo_dma_acc_size(>ttm.bdev, size,
   sizeof(struct nouveau_bo));

-   ret = ttm_bo_init(>ttm.bdev, >bo, size,
- type, >placement,
- align >> PAGE_SHIFT, false, NULL, acc_size, sg,
- nouveau_bo_del_ttm);
+   ret = ttm_bo_init(>ttm.bdev, >bo, size, type,
+ >placement, align >> PAGE_SHIFT, false,
+ acc_size, sg, nouveau_bo_del_ttm);
if (ret) {
/* ttm will call nouveau_bo_del_ttm if it fails.. */
return ret;
diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 0665845..834b291 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -139,9 +139,9 @@ int radeon_bo_create(struct radeon_device *rdev,
radeon_ttm_placement_from_domain(bo, domain);
/* Kernel allocation are uninterruptible */
down_read(>pm.mclk_lock);
-   r = ttm_bo_init(>mman.bdev, >tbo, size, type,
-   >placement, page_align, !kernel, NULL,
-   acc_size, sg, _ttm_bo_destroy);
+   r = ttm_bo_init(>mman.bdev, >tbo, size, type, >placement,
+   page_align, !kernel, acc_size, sg,
+   _ttm_bo_destroy);
up_read(>pm.mclk_lock);
if (unlikely(r != 0)) {
return r;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 27a2d3f..412486c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1180,7 +1180,6 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
struct ttm_placement *placement,
uint32_t page_alignment,
bool interruptible,
-   struct 

[PATCH 1/4] drm/ttm: remove ttm_buffer_object->buffer_start

2012-11-06 Thread Marcin Slusarz
All drivers set it to 0 and nothing uses it.

Signed-off-by: Marcin Slusarz 
Cc: Thomas Hellstrom 
---
 drivers/gpu/drm/ast/ast_ttm.c| 2 +-
 drivers/gpu/drm/cirrus/cirrus_ttm.c  | 2 +-
 drivers/gpu/drm/mgag200/mgag200_ttm.c| 2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
 drivers/gpu/drm/radeon/radeon_object.c   | 2 +-
 drivers/gpu/drm/ttm/ttm_bo.c | 8 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 4 ++--
 include/drm/ttm/ttm_bo_api.h | 9 -
 9 files changed, 10 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 1a026ac..0a54f65 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -356,7 +356,7 @@ int ast_bo_create(struct drm_device *dev, int size, int 
align,

ret = ttm_bo_init(>ttm.bdev, >bo, size,
  ttm_bo_type_device, >placement,
- align >> PAGE_SHIFT, 0, false, NULL, acc_size,
+ align >> PAGE_SHIFT, false, NULL, acc_size,
  NULL, ast_bo_ttm_destroy);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index bc83f83..90d7701 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -361,7 +361,7 @@ int cirrus_bo_create(struct drm_device *dev, int size, int 
align,

ret = ttm_bo_init(>ttm.bdev, >bo, size,
  ttm_bo_type_device, >placement,
- align >> PAGE_SHIFT, 0, false, NULL, acc_size,
+ align >> PAGE_SHIFT, false, NULL, acc_size,
  NULL, cirrus_bo_ttm_destroy);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c 
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index 1504699..49d60a6 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -355,7 +355,7 @@ int mgag200_bo_create(struct drm_device *dev, int size, int 
align,

ret = ttm_bo_init(>ttm.bdev, >bo, size,
  ttm_bo_type_device, >placement,
- align >> PAGE_SHIFT, 0, false, NULL, acc_size,
+ align >> PAGE_SHIFT, false, NULL, acc_size,
  NULL, mgag200_bo_ttm_destroy);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 35ac57f..3cbf1a8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -225,7 +225,7 @@ nouveau_bo_new(struct drm_device *dev, int size, int align,

ret = ttm_bo_init(>ttm.bdev, >bo, size,
  type, >placement,
- align >> PAGE_SHIFT, 0, false, NULL, acc_size, sg,
+ align >> PAGE_SHIFT, false, NULL, acc_size, sg,
  nouveau_bo_del_ttm);
if (ret) {
/* ttm will call nouveau_bo_del_ttm if it fails.. */
diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index b91118c..0665845 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -140,7 +140,7 @@ int radeon_bo_create(struct radeon_device *rdev,
/* Kernel allocation are uninterruptible */
down_read(>pm.mclk_lock);
r = ttm_bo_init(>mman.bdev, >tbo, size, type,
-   >placement, page_align, 0, !kernel, NULL,
+   >placement, page_align, !kernel, NULL,
acc_size, sg, _ttm_bo_destroy);
up_read(>pm.mclk_lock);
if (unlikely(r != 0)) {
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bf6e4b5..27a2d3f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1179,7 +1179,6 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
enum ttm_bo_type type,
struct ttm_placement *placement,
uint32_t page_alignment,
-   unsigned long buffer_start,
bool interruptible,
struct file *persistent_swap_storage,
size_t acc_size,
@@ -1200,7 +1199,6 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
return -ENOMEM;
}

-   size += buffer_start & ~PAGE_MASK;
num_pages = (size + PAGE_SIZE - 1) >> PAGE_SHIFT;
if (num_pages == 0) {
pr_err("Illegal buffer object size\n");
@@ -1233,7 +1231,6 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
bo->mem.page_alignment = page_alignment;
bo->mem.bus.io_reserved_vm = false;
bo->mem.bus.io_reserved_count = 0;
-   bo->buffer_start = buffer_start & PAGE_MASK;
bo->priv_flags = 0;
bo->mem.placement = 

[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #20 from Alexandre Demers  ---
Should I have a look at how grub2 handles and talks to the kernel when using
gfxpayload=keep? A quick search shows this issue has been lurking for some time
(2010) with various radeon card
(https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/605614,
http://frugalware.org/pipermail/frugalware-devel/2012-February/011500.html,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567245,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567393).

Could something be wrong when handling the framebuffer?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/2594c33b/attachment.html>


[PATCH] nouveau: Fix crash after D3

2012-11-06 Thread Daniel J Blueman
In 3.7-rc4, when starting X with the integrated GPU and suspending the discrete 
GPU,
after one or more 32-bit applications are used (eg Skype) and X is stopped,
we hit a panic.

Prevent this by testing if the fini function is valid.

Full panic bootlog is at: http://quora.org/2012/nouveau/dmesg-crash.txt
Xorg.log is at: http://quora.org/2012/nouveau/Xorg.0.log-crash.txt
Kernel log after fix is at: http://quora.org/2012/nouveau/dmesg-fix.txt

Signed-off-by: Daniel J Blueman 
---
 drivers/gpu/drm/nouveau/core/core/object.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/object.c 
b/drivers/gpu/drm/nouveau/core/core/object.c
index 0daab62..3da3525 100644
--- a/drivers/gpu/drm/nouveau/core/core/object.c
+++ b/drivers/gpu/drm/nouveau/core/core/object.c
@@ -354,12 +354,16 @@ static int
 nouveau_object_decf(struct nouveau_object *object)
 {
int ret;
+   struct nouveau_ofuncs *pfuncs;

nv_trace(object, "stopping...\n");

-   ret = nv_ofuncs(object)->fini(object, false);
-   if (ret)
-   nv_warn(object, "failed fini, %d\n", ret);
+   pfuncs = nv_ofuncs(object);
+   if (pfuncs->fini) {
+   ret = nv_ofuncs(object)->fini(object, false);
+   if (ret)
+   nv_warn(object, "failed fini, %d\n", ret);
+   }

if (object->engine) {
mutex_lock(_subdev(object->engine)->mutex);
-- 
1.7.10.4



[Bug 56405] Distorted graphics on Radeon HD 6620G

2012-11-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=56405

--- Comment #13 from Michael Dressel  ---
Created attachment 69640
  --> https://bugs.freedesktop.org/attachment.cgi?id=69640=edit
compilation errors

These are the compile errors I get with the above mentioned commit.
The compile errors are fixed in the commit also mentioned above.

When I choose the start end endpoints for the bisecting
I looked at the date of the commit.
And the commit I related to the 8.0 tag by the date
does not compile either. So this was not a good starting point
in the first place.
I guess it would be better to bisect between the mesa-8.0.4 and mesa-9.0 tags.
If I try this git asks me to check a merge base first.
This merge base dates back to January and it seams to have
a very different configure/build structure.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/e1a41338/attachment.html>


Fix for vblank on nvc0

2012-11-06 Thread Maarten Lankhorst


Op 06-11-12 15:48, Kelly Doran schreef:
> The vblank on nvc0 was not working correctly and would freeze X, I managed
> to track it down and fix it with some help from m.b.lankhorst, see
> https://bugs.freedesktop.org/show_bug.cgi?id=56692 for details.
>
Reviewed-by: Maarten Lankhorst 

I recommended the bar flush since nvd0 does as well, and there might be a small 
race
otherwise.

Can this still get in before final 3.7 release?

~Maarten


[Bug 50208] X does not start on Linux kernel 3.2.0-24, works on 3.0.0-19

2012-11-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=50208

--- Comment #3 from Nicola Larosa  ---
It's still not working with 3.5.0-18.29 . :-( I don't know how to bisect.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/338ff400/attachment.html>


[Suggestion] drivers/gpu/drm/ttm: let constant string match the output format in ttm_dma_page_alloc_debugfs

2012-11-06 Thread Chen Gang
Hello David Airlie:

   for the h[4] is "available" (which length is 9), at line 1107.
   but for seq_printf at line 1114, its format is %8s.

   I suggest to make them match with each other (although it is not a bug).

   thanks.


1103 int ttm_dma_page_alloc_debugfs(struct seq_file *m, void *data)
1104 {
1105 struct device_pools *p;
1106 struct dma_pool *pool = NULL;
1107 char *h[] = {"pool", "refills", "pages freed", "inuse", 
"available",
1108  "name", "virt", "busaddr"};
1109 
1110 if (!_manager) {
 seq_printf(m, "No pool allocator running.\n");
1112 return 0;
1113 }
1114 seq_printf(m, "%13s %12s %13s %8s %8s %8s\n",
1115h[0], h[1], h[2], h[3], h[4], h[5]);
1116 mutex_lock(&_manager->lock);
1117 list_for_each_entry(p, &_manager->pools, pools) {
1118 struct device *dev = p->dev;
1119 if (!dev)
1120 continue;
1121 pool = p->pool;
1122 seq_printf(m, "%13s %12ld %13ld %8d %8d %8s\n",
1123 pool->name, pool->nrefills,
1124 pool->nfrees, pool->npages_in_use,
1125 pool->npages_free,
1126 pool->dev_name);
1127 }
1128 mutex_unlock(&_manager->lock);
1129 return 0;
1130 }
1131 EXPORT_SYMBOL_GPL(ttm_dma_page_alloc_debugfs);



-- 
Chen Gang

Asianux Corporation


[PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available

2012-11-06 Thread Tomi Valkeinen
On 2012-11-05 16:21, Rob Clark wrote:
> On 11/05/2012 02:55 AM, Tomi Valkeinen wrote:
 But even then, choosing the manager is not easy, as whoever chooses the
 >>manager needs to observe all the possible displays used at the same
 >>time...
>>> >
>>> >Right. I was wondering if omapfb/omapdrm could understand the 'all
>>> >possible displays information' better compared to a panel's probe.
>>> >
>>> >Even omapdrm/omafb can't be perfect because we could insert a panel
>>> >driver module at any time, and omapfb/omapdrm may miss that out.
>> True, omapdrm/fb may have a better idea. It's still unclear though.
>> Currently we have quite strict order in the sequence the modules need to
>> be loaded, which is quite bad and causes issues. We should make things
>> more dynamic, so that the initialization of the drivers could happen
>> more freely.
>>
>> But that creates more problems: when booting up, omapfb starts. But
>> omapfb can't know if all the panel drivers have already been loaded.
>> omapfb may see that DVI is the default display, but what should it do if
>> DVI doesn't have a driver yet? It could wait, but perhaps the driver for
>> DVI will never even be loaded.
> 
> The encoder which is connected to the crtc (manager) is picked by
> combination of encoder->possible_crtcs bitmask and
> connector->best_encoder().  We could keep things limited so that the
> association of crtc to encoder (manager to output, roughly) never
> changes, but this isn't really the right thing to do.  It is better that
> the dssdev not rely on knowing the manager it is attached to at probe
> time, but instead grab resources more dynamically.
> 
> Also, at the moment we don't really have any notification to userspace
> about new encoders/connectors showing up (or conversely, being
> removed).  Only about existing connectors being plugged/unplugged.  The
> closest analogy is perhaps the USB display devices, but even there it is
> only the entire drm device that is plugged/unplugged.  And TBH I don't
> really see the point in supporting panel drivers being dynamically
> loaded.  It isn't like someone is dynamically soldering on a new display
> connector to some board that is running.  I think omapfb or omapdrm
> probe should trigger registering the compiled-in panel drivers, so that
> it can be sure that the dssdev's pop up before it goes and creates drm
> connector objects.  Currently we have to hack around this in omapdrm
> with late_initcall() to ensure the panel drivers are probed first, but
> that is an ugly hack that I'd like to get rid of.

We have panel devices and panel drivers, each of which can appear at any
time. Both are needed for the panel probe to happen. If we don't support
device hotplugging (dynamic creation of devices), we need to use
late_initcall for omapfb/drm. At least I don't see any other option.

You say that omapdrm should trigger registering of the drivers. How
would that work? Do you mean that the panel drivers would register
themselves to some common list, and omapdrm would go through this list
when drm is loaded, calling probe for the items in the list? I guess
that's doable, but... It's not how kernel drivers are supposed to work,
and so doesn't sound very clean approach to me.

I think we should support proper hotplugging of the panels. This would
fix the problem about init order, but it would also give us device
hotplug support. Obviously nobody is going to solder panel to a running
board, but I don't see any reason why panels, or, more likely, panels on
an add-on boards (like the capes being discussed in omap ml) would not
be hotpluggable using whatever connector is used on the particular use case.

And even if we don't support removing of the devices, things like the
add-on capes could cause the panel on the cape to be identified at some
late time (the panel is not described in the board file or DT data, but
found at runtime depending on the ID of the cape). This would add
another step to the init sequence that should be just right, if we don't
support hotplug.

Yes, I know it's not simple =). And I'm fine with simpler approach for
the time being, but I'd like full hotplug to be the future goal. At
least the common panel framework should not create restrictions about
this, even if drm wouldn't allow device hotplug.

 Tomi



[PATCH 1/3] drm/ttm: add ttm_bo_is_reserved

2012-11-06 Thread Maarten Lankhorst
Op 25-10-12 09:42, Thomas Hellstrom schreef:
> On 10/12/2012 04:58 PM, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>   drivers/gpu/drm/ttm/ttm_bo.c |   12 ++--
>>   include/drm/ttm/ttm_bo_api.h |   14 ++
>>   2 files changed, 20 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
>> index be1148e..d9d8541 100644
>> --- a/drivers/gpu/drm/ttm/ttm_bo.c
>> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
>> @@ -161,9 +161,9 @@ int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo, 
>> bool interruptible)
>>   {
>>   if (interruptible) {
>>   return wait_event_interruptible(bo->event_queue,
>> -   atomic_read(>reserved) == 0);
>> +   !ttm_bo_is_reserved(bo));
>>   } else {
>> -wait_event(bo->event_queue, atomic_read(>reserved) == 0);
>> +wait_event(bo->event_queue, !ttm_bo_is_reserved(bo));
>>   return 0;
>>   }
>>   }
>> @@ -174,7 +174,7 @@ void ttm_bo_add_to_lru(struct ttm_buffer_object *bo)
>>   struct ttm_bo_device *bdev = bo->bdev;
>>   struct ttm_mem_type_manager *man;
>>   -BUG_ON(!atomic_read(>reserved));
>> +BUG_ON(!ttm_bo_is_reserved(bo));
>> if (!(bo->mem.placement & TTM_PL_FLAG_NO_EVICT)) {
>>   @@ -748,7 +748,7 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, 
>> bool interruptible,
>>   goto out;
>>   }
>>   -BUG_ON(!atomic_read(>reserved));
>> +BUG_ON(!ttm_bo_is_reserved(bo));
>> evict_mem = bo->mem;
>>   evict_mem.mm_node = NULL;
>> @@ -1058,7 +1058,7 @@ int ttm_bo_move_buffer(struct ttm_buffer_object *bo,
>>   struct ttm_mem_reg mem;
>>   struct ttm_bo_device *bdev = bo->bdev;
>>   -BUG_ON(!atomic_read(>reserved));
>> +BUG_ON(!ttm_bo_is_reserved(bo));
>> /*
>>* FIXME: It's possible to pipeline buffer moves.
>> @@ -1115,7 +1115,7 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
>>   {
>>   int ret;
>>   -BUG_ON(!atomic_read(>reserved));
>> +BUG_ON(!ttm_bo_is_reserved(bo));
>>   /* Check that range is valid */
>>   if (placement->lpfn || placement->fpfn)
>>   if (placement->fpfn > placement->lpfn ||
>> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
>> index 9654451..1d71f6b 100644
>> --- a/include/drm/ttm/ttm_bo_api.h
>> +++ b/include/drm/ttm/ttm_bo_api.h
>> @@ -705,4 +705,18 @@ extern ssize_t ttm_bo_io(struct ttm_bo_device *bdev, 
>> struct file *filp,
>> extern void ttm_bo_swapout_all(struct ttm_bo_device *bdev);
>>   +/**
>> + * ttm_bo_is_reserved - return an indication if a ttm buffer object is 
>> reserved
>> + *
>> + * @bo: The buffer object to check.
>> + *
>> + * This function returns an indication if a bo is reserved or not, and 
>> should
>> + * only be used to print an error when it is not from incorrect api usage, 
>> since
>> + * there's no guarantee that it is the caller that is holding the 
>> reservation.
>> + */
>> +static inline bool ttm_bo_is_reserved(struct ttm_buffer_object *bo)
>> +{
>> +return atomic_read(>reserved);
>> +}
>> +
>>   #endif
> This looks good, although for clarity we should add in the comments that
> if the caller is holding the reservation, the function is guaranteed to 
> return true.
>
> Otherwise
> Reviewed-by: Thomas Hellstrom 

Unless you use lockdep, you can't say with 100% certainty if the CALLER is 
holding it or not. :-)
But lockdep can actually check if that's the case with 
lockdep_is_held(>reservation_lock);
which iterates over all locks held by the current task.

~Maarten

Updated version with a comment about return value in ttm_bo_is_reserved:

drm/ttm: Add ttm_bo_is_reserved function

Signed-off-by: Maarten Lankhorst 
Reviewed-by: Thomas Hellstrom 

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2b3f69b..82e2633 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -162,9 +162,9 @@ int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo, 
bool interruptible)
 {
if (interruptible) {
return wait_event_interruptible(bo->event_queue,
-  atomic_read(>reserved) == 0);
+  !ttm_bo_is_reserved(bo));
} else {
-   wait_event(bo->event_queue, atomic_read(>reserved) == 0);
+   wait_event(bo->event_queue, !ttm_bo_is_reserved(bo));
return 0;
}
 }
@@ -175,7 +175,7 @@ void ttm_bo_add_to_lru(struct ttm_buffer_object *bo)
struct ttm_bo_device *bdev = bo->bdev;
struct ttm_mem_type_manager *man;

-   BUG_ON(!atomic_read(>reserved));
+   BUG_ON(!ttm_bo_is_reserved(bo));

if (!(bo->mem.placement & TTM_PL_FLAG_NO_EVICT)) {

@@ -756,7 +756,7 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, bool 
interruptible,
goto out;
}

-   

[PATCH] drm/ttm: alter cpu_writers to return -EBUSY in ttm_execbuf_util reservations

2012-11-06 Thread Maarten Lankhorst
This is similar to other platforms that don't allow command submission
to buffers locked on the cpu.

Signed-off-by: Maarten Lankhorst 

---

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bf6e4b5..2b3f69b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1054,16 +1054,6 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
 }
 EXPORT_SYMBOL(ttm_bo_mem_space);

-int ttm_bo_wait_cpu(struct ttm_buffer_object *bo, bool no_wait)
-{
-   if ((atomic_read(>cpu_writers) > 0) && no_wait)
-   return -EBUSY;
-
-   return wait_event_interruptible(bo->event_queue,
-   atomic_read(>cpu_writers) == 0);
-}
-EXPORT_SYMBOL(ttm_bo_wait_cpu);
-
 int ttm_bo_move_buffer(struct ttm_buffer_object *bo,
struct ttm_placement *placement,
bool interruptible, bool no_wait_reserve,
@@ -1797,8 +1787,7 @@ EXPORT_SYMBOL(ttm_bo_synccpu_write_grab);

 void ttm_bo_synccpu_write_release(struct ttm_buffer_object *bo)
 {
-   if (atomic_dec_and_test(>cpu_writers))
-   wake_up_all(>event_queue);
+   atomic_dec(>cpu_writers);
 }
 EXPORT_SYMBOL(ttm_bo_synccpu_write_release);

diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c 
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index 1937069..7aa5073 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -185,10 +185,7 @@ retry_this_bo:
ttm_eu_backoff_reservation_locked(list);
spin_unlock(>lru_lock);
ttm_eu_list_ref_sub(list);
-   ret = ttm_bo_wait_cpu(bo, false);
-   if (ret)
-   return ret;
-   goto retry;
+   return -EBUSY;
}
}

diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index e8028ad..850424f 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -429,8 +429,9 @@ extern void ttm_bo_unlock_delayed_workqueue(struct 
ttm_bo_device *bdev,
  * @no_wait: Return immediately if buffer is busy.
  *
  * Synchronizes a buffer object for CPU RW access. This means
- * blocking command submission that affects the buffer and
- * waiting for buffer idle. This lock is recursive.
+ * command submission that affects the buffer will return -EBUSY
+ * until ttm_bo_synccpu_write_release is called.
+ *
  * Returns
  * -EBUSY if the buffer is busy and no_wait is true.
  * -ERESTARTSYS if interrupted by a signal.
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index d803b92..3e193f5 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -729,20 +729,6 @@ extern void ttm_bo_mem_put(struct ttm_buffer_object *bo,
 extern void ttm_bo_mem_put_locked(struct ttm_buffer_object *bo,
  struct ttm_mem_reg *mem);

-/**
- * ttm_bo_wait_for_cpu
- *
- * @bo: Pointer to a struct ttm_buffer_object.
- * @no_wait: Don't sleep while waiting.
- *
- * Wait until a buffer object is no longer sync'ed for CPU access.
- * Returns:
- * -EBUSY: Buffer object was sync'ed for CPU access. (only if no_wait == 1).
- * -ERESTARTSYS: An interruptible sleep was interrupted by a signal.
- */
-
-extern int ttm_bo_wait_cpu(struct ttm_buffer_object *bo, bool no_wait);
-
 extern void ttm_bo_global_release(struct drm_global_reference *ref);
 extern int ttm_bo_global_init(struct drm_global_reference *ref);




[PATCH RESEND] gma600: Enable HDMI support

2012-11-06 Thread Alan Cox
From: Alan Cox 

There are still some mysteries left, in particular how (and in
fact if) the EDID is supposed to work on the HDMI port. However
the basic stuff now works and I can plug my Q550 into an HDMI
display and get the expected results.

[v2: cleans up space/tab and other formatting as per Dave's
 request]

Signed-off-by: Alan Cox 
---

 drivers/gpu/drm/gma500/oaktrail.h|6 
 drivers/gpu/drm/gma500/oaktrail_crtc.c   |8 +
 drivers/gpu/drm/gma500/oaktrail_device.c |2 
 drivers/gpu/drm/gma500/oaktrail_hdmi.c   |  365 +-
 4 files changed, 365 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/gma500/oaktrail.h 
b/drivers/gpu/drm/gma500/oaktrail.h
index f2f9f38..30adbbe 100644
--- a/drivers/gpu/drm/gma500/oaktrail.h
+++ b/drivers/gpu/drm/gma500/oaktrail.h
@@ -249,3 +249,9 @@ extern void oaktrail_hdmi_i2c_exit(struct pci_dev *dev);
 extern void oaktrail_hdmi_save(struct drm_device *dev);
 extern void oaktrail_hdmi_restore(struct drm_device *dev);
 extern void oaktrail_hdmi_init(struct drm_device *dev, struct 
psb_intel_mode_device *mode_dev);
+extern int oaktrail_crtc_hdmi_mode_set(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
+   struct drm_display_mode 
*adjusted_mode, int x, int y,
+   struct drm_framebuffer *old_fb);
+extern void oaktrail_crtc_hdmi_dpms(struct drm_crtc *crtc, int mode);
+
+
diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c 
b/drivers/gpu/drm/gma500/oaktrail_crtc.c
index cdafd2a..4ec2962 100644
--- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
+++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
@@ -168,6 +168,11 @@ static void oaktrail_crtc_dpms(struct drm_crtc *crtc, int 
mode)
const struct psb_offset *map = _priv->regmap[pipe];
u32 temp;

+   if (pipe == 1) {
+   oaktrail_crtc_hdmi_dpms(crtc, mode);
+   return;
+   }
+
if (!gma_power_begin(dev, true))
return;

@@ -302,6 +307,9 @@ static int oaktrail_crtc_mode_set(struct drm_crtc *crtc,
uint64_t scalingType = DRM_MODE_SCALE_FULLSCREEN;
struct drm_connector *connector;

+   if (pipe == 1)
+   return oaktrail_crtc_hdmi_mode_set(crtc, mode, adjusted_mode, 
x, y, old_fb);
+
if (!gma_power_begin(dev, true))
return 0;

diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c 
b/drivers/gpu/drm/gma500/oaktrail_device.c
index 010b8207..08747fd 100644
--- a/drivers/gpu/drm/gma500/oaktrail_device.c
+++ b/drivers/gpu/drm/gma500/oaktrail_device.c
@@ -544,7 +544,7 @@ const struct psb_ops oaktrail_chip_ops = {
.accel_2d = 1,
.pipes = 2,
.crtcs = 2,
-   .hdmi_mask = (1 << 0),
+   .hdmi_mask = (1 << 1),
.lvds_mask = (1 << 0),
.cursor_needs_phys = 0,
.sgx_offset = MRST_SGX_OFFSET,
diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c 
b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
index 69e51e9..f036f1f 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
@@ -155,6 +155,345 @@ static void oaktrail_hdmi_audio_disable(struct drm_device 
*dev)
HDMI_READ(HDMI_HCR);
 }

+static void wait_for_vblank(struct drm_device *dev)
+{
+   /* Wait for 20ms, i.e. one cycle at 50hz. */
+   mdelay(20);
+}
+
+static unsigned int htotal_calculate(struct drm_display_mode *mode)
+{
+   u32 htotal, new_crtc_htotal;
+
+   htotal = (mode->crtc_hdisplay - 1) | ((mode->crtc_htotal - 1) << 16);
+
+   /*
+* 1024 x 768  new_crtc_htotal = 0x1024;
+* 1280 x 1024 new_crtc_htotal = 0x0c34;
+*/
+   new_crtc_htotal = (mode->crtc_htotal - 1) * 200 * 1000 / mode->clock;
+
+   DRM_DEBUG_KMS("new crtc htotal 0x%4x\n", new_crtc_htotal);
+   return (mode->crtc_hdisplay - 1) | (new_crtc_htotal << 16);
+}
+
+static void oaktrail_hdmi_find_dpll(struct drm_crtc *crtc, int target,
+   int refclk, struct oaktrail_hdmi_clock 
*best_clock)
+{
+   int np_min, np_max, nr_min, nr_max;
+   int np, nr, nf;
+
+   np_min = DIV_ROUND_UP(oaktrail_hdmi_limit.vco.min, target * 10);
+   np_max = oaktrail_hdmi_limit.vco.max / (target * 10);
+   if (np_min < oaktrail_hdmi_limit.np.min)
+   np_min = oaktrail_hdmi_limit.np.min;
+   if (np_max > oaktrail_hdmi_limit.np.max)
+   np_max = oaktrail_hdmi_limit.np.max;
+
+   nr_min = DIV_ROUND_UP((refclk * 1000), (target * 10 * np_max));
+   nr_max = DIV_ROUND_UP((refclk * 1000), (target * 10 * np_min));
+   if (nr_min < oaktrail_hdmi_limit.nr.min)
+   nr_min = oaktrail_hdmi_limit.nr.min;
+   if (nr_max > oaktrail_hdmi_limit.nr.max)
+   nr_max = oaktrail_hdmi_limit.nr.max;
+
+   np = DIV_ROUND_UP((refclk * 1000), (target * 10 * nr_max));
+   nr = DIV_ROUND_UP((refclk * 1000), (target * 10 * np));
+   nf = 

[Bug 50091] GeForce 6150SE: system hangs on X-server start with garbled screen

2012-11-06 Thread bugzilla-dae...@bugzilla.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=50091


Alan  changed:

   What|Removed |Added

 CC||alan at lxorguk.ukuu.org.uk
  Component|Video(Other)|Video(DRI - non Intel)
 AssignedTo|drivers_video-other at kernel- |drivers_video-dri at 
kernel-bu
   |bugs.osdl.org   |gs.osdl.org




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.


[PATCH 4/4] drm/ttm: Optimize reservation slightly

2012-11-06 Thread Thomas Hellstrom
Reservation locking currently always takes place under the LRU spinlock.
Hence, strictly there is no need for an atomic_cmpxchg call; we can use
atomic_read followed by atomic_write since nobody else will ever reserve
without the lru spinlock held.
At least on Intel this should remove a locked bus cycle on successful
reserve.

Note that thit commit may be obsoleted by the cross-device reservation work.

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 bf6e4b5..46008ea 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -220,7 +220,7 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
struct ttm_bo_global *glob = bo->glob;
int ret;

-   while (unlikely(atomic_cmpxchg(>reserved, 0, 1) != 0)) {
+   while (unlikely(atomic_read(>reserved) != 0)) {
/**
 * Deadlock avoidance for multi-bo reserving.
 */
@@ -249,6 +249,7 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
return ret;
}

+   atomic_set(>reserved, 1);
if (use_sequence) {
/**
 * Wake up waiters that may need to recheck for deadlock,
-- 
1.7.4.4



[PATCH 3/4] drm/ttm, drm/vmwgfx: Use RCU locking for object lookups v3

2012-11-06 Thread Thomas Hellstrom
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 synchronization is needed
at module unload time.

v2: Don't touch include/linux/kref.h
v3: Adapt to kref_get_unless_zero return value change

Signed-off-by: Thomas Hellstrom 
---
 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, 19 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_object.c b/drivers/gpu/drm/ttm/ttm_object.c
index c785787..f18eeb4 100644
--- a/drivers/gpu/drm/ttm/ttm_object.c
+++ b/drivers/gpu/drm/ttm/ttm_object.c
@@ -80,7 +80,7 @@ struct ttm_object_file {
  */

 struct ttm_object_device {
-   rwlock_t object_lock;
+   spinlock_t object_lock;
struct drm_open_hash object_hash;
atomic_t object_count;
struct ttm_mem_global *mem_glob;
@@ -157,12 +157,12 @@ int ttm_base_object_init(struct ttm_object_file *tfile,
base->refcount_release = refcount_release;
base->ref_obj_release = ref_obj_release;
base->object_type = object_type;
-   write_lock(>object_lock);
+   spin_lock(>object_lock);
kref_init(>refcount);
ret = drm_ht_just_insert_please(>object_hash,
>hash,
(unsigned long)base, 31, 0, 0);
-   write_unlock(>object_lock);
+   spin_unlock(>object_lock);
if (unlikely(ret != 0))
goto out_err0;

@@ -186,30 +186,22 @@ static void ttm_release_base(struct kref *kref)
container_of(kref, struct ttm_base_object, refcount);
struct ttm_object_device *tdev = base->tfile->tdev;

+   spin_lock(>object_lock);
(void)drm_ht_remove_item(>object_hash, >hash);
-   write_unlock(>object_lock);
+   spin_unlock(>object_lock);
if (base->refcount_release) {
ttm_object_file_unref(>tfile);
base->refcount_release();
}
-   write_lock(>object_lock);
 }

 void ttm_base_object_unref(struct ttm_base_object **p_base)
 {
struct ttm_base_object *base = *p_base;
-   struct ttm_object_device *tdev = base->tfile->tdev;

*p_base = NULL;

-   /*
-* Need to take the lock here to avoid racing with
-* users trying to look up the object.
-*/
-
-   write_lock(>object_lock);
kref_put(>refcount, ttm_release_base);
-   write_unlock(>object_lock);
 }
 EXPORT_SYMBOL(ttm_base_object_unref);

@@ -221,14 +213,14 @@ struct ttm_base_object *ttm_base_object_lookup(struct 
ttm_object_file *tfile,
struct drm_hash_item *hash;
int ret;

-   read_lock(>object_lock);
+   rcu_read_lock();
ret = drm_ht_find_item(>object_hash, key, );

if (likely(ret == 0)) {
base = drm_hash_entry(hash, struct ttm_base_object, hash);
-   kref_get(>refcount);
+   ret = kref_get_unless_zero(>refcount) ? 0 : -EINVAL;
}
-   read_unlock(>object_lock);
+   rcu_read_unlock();

if (unlikely(ret != 0))
return NULL;
@@ -426,7 +418,7 @@ struct ttm_object_device *ttm_object_device_init(struct 
ttm_mem_global
return NULL;

tdev->mem_glob = mem_glob;
-   rwlock_init(>object_lock);
+   spin_lock_init(>object_lock);
atomic_set(>object_count, 0);
ret = drm_ht_create(>object_hash, hash_order);

@@ -444,9 +436,9 @@ void ttm_object_device_release(struct ttm_object_device 
**p_tdev)

*p_tdev = NULL;

-   write_lock(>object_lock);
+   spin_lock(>object_lock);
drm_ht_remove(>object_hash);
-   write_unlock(>object_lock);
+   spin_unlock(>object_lock);

kfree(tdev);
 }
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index da3c6b5..ae675c6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -351,7 +351,7 @@ static void vmw_user_context_free(struct vmw_resource *res)
container_of(res, struct vmw_user_context, res);
struct vmw_private *dev_priv = res->dev_priv;

-   kfree(ctx);
+   ttm_base_object_kfree(ctx, base);
ttm_mem_global_free(vmw_mem_glob(dev_priv),
vmw_user_context_size);
 }
@@ -1147,7 +1147,7 @@ static void vmw_user_surface_free(struct vmw_resource 
*res)
kfree(srf->offsets);
kfree(srf->sizes);
kfree(srf->snooper.image);
-   kfree(user_srf);
+   ttm_base_object_kfree(user_srf, base);
ttm_mem_global_free(vmw_mem_glob(dev_priv), size);
 }

@@ -1575,7 +1575,7 @@ static void vmw_user_dmabuf_destroy(struct 
ttm_buffer_object *bo)
 {

[PATCH 2/4] kref: Implement kref_get_unless_zero v3

2012-11-06 Thread Thomas Hellstrom
This function is intended to simplify locking around refcounting for
objects that can be looked up from a lookup structure, and which are
removed from that lookup structure in the object destructor.
Operations on such objects require at least a read lock around
lookup + kref_get, and a write lock around kref_put + remove from lookup
structure. Furthermore, RCU implementations become extremely tricky.
With a lookup followed by a kref_get_unless_zero *with return value check*
locking in the kref_put path can be deferred to the actual removal from
the lookup structure and RCU lookups become trivial.

v2: Formatting fixes.
v3: Invert the return value.

Signed-off-by: Thomas Hellstrom 
---
 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 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -111,4 +111,25 @@ static inline int kref_put_mutex(struct kref *kref,
}
return 0;
 }
+
+/**
+ * kref_get_unless_zero - Increment refcount for object unless it is zero.
+ * @kref: object.
+ *
+ * Return non-zero if the increment succeeded. Otherwise return 0.
+ *
+ * This function is intended to simplify locking around refcounting for
+ * objects that can be looked up from a lookup structure, and which are
+ * removed from that lookup structure in the object destructor.
+ * Operations on such objects require at least a read lock around
+ * lookup + kref_get, and a write lock around kref_put + remove from lookup
+ * structure. Furthermore, RCU implementations become extremely tricky.
+ * With a lookup followed by a kref_get_unless_zero *with return value check*
+ * locking in the kref_put path can be deferred to the actual removal from
+ * the lookup structure and RCU lookups become trivial.
+ */
+static inline int __must_check kref_get_unless_zero(struct kref *kref)
+{
+   return atomic_add_unless(>refcount, 1, 0);
+}
 #endif /* _KREF_H_ */
-- 
1.7.4.4



[PATCH 1/4] drm: Make hashtab rcu-safe

2012-11-06 Thread Thomas Hellstrom
TTM base objects will be the first consumer.

Signed-off-by: Thomas Hellstrom 
---
 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 c3745c4..5729e39 100644
--- a/drivers/gpu/drm/drm_hashtab.c
+++ b/drivers/gpu/drm/drm_hashtab.c
@@ -67,10 +67,8 @@ void drm_ht_verbose_list(struct drm_open_hash *ht, unsigned 
long key)
hashed_key = hash_long(key, ht->order);
DRM_DEBUG("Key is 0x%08lx, Hashed key is 0x%08x\n", key, hashed_key);
h_list = >table[hashed_key];
-   hlist_for_each(list, h_list) {
-   entry = hlist_entry(list, struct drm_hash_item, head);
+   hlist_for_each_entry_rcu(entry, list, h_list, head)
DRM_DEBUG("count %d, key: 0x%08lx\n", count++, entry->key);
-   }
 }

 static struct hlist_node *drm_ht_find_key(struct drm_open_hash *ht,
@@ -83,8 +81,7 @@ static struct hlist_node *drm_ht_find_key(struct 
drm_open_hash *ht,

hashed_key = hash_long(key, ht->order);
h_list = >table[hashed_key];
-   hlist_for_each(list, h_list) {
-   entry = hlist_entry(list, struct drm_hash_item, head);
+   hlist_for_each_entry_rcu(entry, list, h_list, head) {
if (entry->key == key)
return list;
if (entry->key > key)
@@ -105,8 +102,7 @@ int drm_ht_insert_item(struct drm_open_hash *ht, struct 
drm_hash_item *item)
hashed_key = hash_long(key, ht->order);
h_list = >table[hashed_key];
parent = NULL;
-   hlist_for_each(list, h_list) {
-   entry = hlist_entry(list, struct drm_hash_item, head);
+   hlist_for_each_entry_rcu(entry, list, h_list, head) {
if (entry->key == key)
return -EINVAL;
if (entry->key > key)
@@ -114,9 +110,9 @@ int drm_ht_insert_item(struct drm_open_hash *ht, struct 
drm_hash_item *item)
parent = list;
}
if (parent) {
-   hlist_add_after(parent, >head);
+   hlist_add_after_rcu(parent, >head);
} else {
-   hlist_add_head(>head, h_list);
+   hlist_add_head_rcu(>head, h_list);
}
return 0;
 }
@@ -171,7 +167,7 @@ int drm_ht_remove_key(struct drm_open_hash *ht, unsigned 
long key)

list = drm_ht_find_key(ht, key);
if (list) {
-   hlist_del_init(list);
+   hlist_del_init_rcu(list);
return 0;
}
return -EINVAL;
@@ -179,7 +175,7 @@ int drm_ht_remove_key(struct drm_open_hash *ht, unsigned 
long key)

 int drm_ht_remove_item(struct drm_open_hash *ht, struct drm_hash_item *item)
 {
-   hlist_del_init(>head);
+   hlist_del_init_rcu(>head);
return 0;
 }
 EXPORT_SYMBOL(drm_ht_remove_item);
-- 
1.7.4.4



[PATCH 0/4] drm/ttm: Get rid of a number of atomic read-modify-write ops v3

2012-11-06 Thread Thomas Hellstrom
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 down.

v2: Formatting fixes.
v3: Invert the return value of kref_get_unless_zero.
Add a comment in the commit message to patch 4 that it may be obsoleted.



[PATCH] drm: exynos: fix for mapping of dma buffers

2012-11-06 Thread Inki Dae
Applied.

Thanks,
Inki Dae


2012/11/6 Rahul Sharma 

> This patch fixes the problem of mapping contigous and non contigous dma
> buffers.
>
> Currently page struct is calculated from the buf->dma_addr which is not the
> physical address. It is replaced by buf->pages which points to the page
> struct
> of the first page of contigous memory chunk. This gives the correct page
> frame
> number for mapping.
>
> Non-contigous dma buffers are described using SG table and SG lists. Each
> valid SG List is pointing to a single page or group of pages which are
> physically contigous. Current implementation just maps the first page of
> each
> SG List and leave the other pages unmapped, leading to a crash. Given
> solution
> finds the page struct for the faulting page through parsing SG table and
> map it.
>
> Signed-off-by: Rahul Sharma 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c |   28
> +---
>  1 files changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 8cb6824..50d73f1 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -95,15 +95,37 @@ static int exynos_drm_gem_map_buf(struct
> drm_gem_object *obj,
>  {
> struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_gem_obj(obj);
> struct exynos_drm_gem_buf *buf = exynos_gem_obj->buffer;
> +   struct scatterlist *sgl;
> unsigned long pfn;
> +   int i;
>
> if (exynos_gem_obj->flags & EXYNOS_BO_NONCONTIG) {
> +   if (!buf->sgt)
> +   return -EINTR;
> +
> +   sgl = buf->sgt->sgl;
> +   for_each_sg(buf->sgt->sgl, sgl, buf->sgt->nents, i) {
> +   if (!sgl) {
> +   DRM_ERROR("invalid SG table\n");
> +   return -EINTR;
> +   }
> +   if (page_offset < (sgl->length >> PAGE_SHIFT))
> +   break;
> +   page_offset -=  (sgl->length >> PAGE_SHIFT);
> +   }
> +
> +   if (i >= buf->sgt->nents) {
> +   DRM_ERROR("invalid page offset\n");
> +   return -EINVAL;
> +   }
> +
> +   pfn = __phys_to_pfn(sg_phys(sgl)) + page_offset;
> +   } else {
> if (!buf->pages)
> return -EINTR;
>
> -   pfn = page_to_pfn(buf->pages[page_offset++]);
> -   } else
> -   pfn = (buf->dma_addr >> PAGE_SHIFT) + page_offset;
> +   pfn = page_to_pfn(buf->pages[0]) + page_offset;
> +   }
>
> return vm_insert_mixed(vma, f_vaddr, pfn);
>  }
> --
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/b160442e/attachment-0001.html>


[drm-intel:drm-intel-next-queued 255/259] drivers/gpu/drm/i915/i915_gem_gtt.c:366:36: sparse: dereference of noderef expression

2012-11-06 Thread Fengguang Wu

Hi Ben,

FYI, there are new sparse warnings show up in

tree:   git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-next-queued
head:   afef67fbc09aec8508c88aac1931661a36e91958
commit: a1e0e54668f41badfaf5e49cae9fc10b79635b25 [255/259] drm/i915: Stop using 
AGP layer for GEN6+

+ drivers/gpu/drm/i915/i915_gem_gtt.c:366:36: sparse: dereference of noderef 
expression

vim +366 drivers/gpu/drm/i915/i915_gem_gtt.c

a1e0e546 Ben Widawsky 2012-11-04  350  {
a1e0e546 Ben Widawsky 2012-11-04  351   struct drm_device *dev = obj->base.dev;
a1e0e546 Ben Widawsky 2012-11-04  352   struct drm_i915_private *dev_priv = 
dev->dev_private;
a1e0e546 Ben Widawsky 2012-11-04  353   struct sg_table *st = obj->pages;
a1e0e546 Ben Widawsky 2012-11-04  354   struct scatterlist *sg = st->sgl;
a1e0e546 Ben Widawsky 2012-11-04  355   const int first_entry = 
obj->gtt_space->start >> PAGE_SHIFT;
a1e0e546 Ben Widawsky 2012-11-04  356   const int max_entries = 
dev_priv->mm.gtt->gtt_total_entries - first_entry;
a1e0e546 Ben Widawsky 2012-11-04  357   gtt_pte_t __iomem *gtt_entries = 
dev_priv->mm.gtt->gtt + first_entry;
a1e0e546 Ben Widawsky 2012-11-04  358   int unused, i = 0;
a1e0e546 Ben Widawsky 2012-11-04  359   unsigned int len, m = 0;
a1e0e546 Ben Widawsky 2012-11-04  360   dma_addr_t addr;
a1e0e546 Ben Widawsky 2012-11-04  361  
a1e0e546 Ben Widawsky 2012-11-04  362   for_each_sg(st->sgl, sg, st->nents, 
unused) {
a1e0e546 Ben Widawsky 2012-11-04  363   len = sg_dma_len(sg) >> 
PAGE_SHIFT;
a1e0e546 Ben Widawsky 2012-11-04  364   for (m = 0; m < len; m++) {
a1e0e546 Ben Widawsky 2012-11-04  365   addr = 
sg_dma_address(sg) + (m << PAGE_SHIFT);
a1e0e546 Ben Widawsky 2012-11-04 @366   gtt_entries[i] = 
pte_encode(dev, addr, level);
a1e0e546 Ben Widawsky 2012-11-04  367   i++;
a1e0e546 Ben Widawsky 2012-11-04  368   }
a1e0e546 Ben Widawsky 2012-11-04  369   }
a1e0e546 Ben Widawsky 2012-11-04  370  
a1e0e546 Ben Widawsky 2012-11-04  371   BUG_ON(i > max_entries);
a1e0e546 Ben Widawsky 2012-11-04  372   BUG_ON(i != obj->base.size / PAGE_SIZE);
a1e0e546 Ben Widawsky 2012-11-04  373  
a1e0e546 Ben Widawsky 2012-11-04  374   /* XXX: This serves as a posting read 
to make sure that the PTE has

---
0-DAY kernel build testing backend Open Source Technology Center
Fengguang Wu, Yuanhan Liu  Intel Corporation


[Bug 12882] [855GM missing DVO driver] s-video not detected

2012-11-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=12882

Daniel Vetter  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #31 from Daniel Vetter  ---
Mass-closing missing dvo driver bugs. We won't ever do that, so this needs a RE
effort from someone else.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/2e17b5e9/attachment.html>


[Bug 30845] [855 missing dvo driver] DVI output unsupported

2012-11-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=30845

Daniel Vetter  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #7 from Daniel Vetter  ---
Mass-closing missing dvo driver bugs. We won't ever do that, so this needs a RE
effort from someone else.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/bf8f428e/attachment.html>


[Bug 26735] r600: rendering artifacts

2012-11-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=26735

T?r?k Edwin <edwin+mesa at etorok.net> changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #13 from T?r?k Edwin <edwin+mesa at etorok.net> ---
(In reply to comment #12)
> Note: classic r600 driver has been abandoned.
> Please use r600g (gallium driver) instead.
> 
> Is this still an issue with a newer driver/kernel?

Rendering looks correct now, tested with r600g version '3.0 Mesa 9.1-devel
(git-e87a578)' (R600_LLVM=0).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/1e204e20/attachment.html>


[Bug 56405] Distorted graphics on Radeon HD 6620G

2012-11-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=56405

--- Comment #12 from Michel D?nzer  ---
What are the compile errors?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/47c3b59e/attachment-0001.html>


Fix for vblank on nvc0

2012-11-06 Thread Kelly Doran
The vblank on nvc0 was not working correctly and would freeze X, I managed
to track it down and fix it with some help from m.b.lankhorst, see
https://bugs.freedesktop.org/show_bug.cgi?id=56692 for details.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/27ceb48e/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: nvc0_vblank_fix.patch
Type: application/octet-stream
Size: 1647 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/27ceb48e/attachment.obj>


[PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available

2012-11-06 Thread Rob Clark
On Tue, Nov 6, 2012 at 7:41 AM, Tomi Valkeinen  wrote:
> On 2012-11-05 16:21, Rob Clark wrote:
>> On 11/05/2012 02:55 AM, Tomi Valkeinen wrote:
> But even then, choosing the manager is not easy, as whoever chooses the
> >>manager needs to observe all the possible displays used at the same
> >>time...
 >
 >Right. I was wondering if omapfb/omapdrm could understand the 'all
 >possible displays information' better compared to a panel's probe.
 >
 >Even omapdrm/omafb can't be perfect because we could insert a panel
 >driver module at any time, and omapfb/omapdrm may miss that out.
>>> True, omapdrm/fb may have a better idea. It's still unclear though.
>>> Currently we have quite strict order in the sequence the modules need to
>>> be loaded, which is quite bad and causes issues. We should make things
>>> more dynamic, so that the initialization of the drivers could happen
>>> more freely.
>>>
>>> But that creates more problems: when booting up, omapfb starts. But
>>> omapfb can't know if all the panel drivers have already been loaded.
>>> omapfb may see that DVI is the default display, but what should it do if
>>> DVI doesn't have a driver yet? It could wait, but perhaps the driver for
>>> DVI will never even be loaded.
>>
>> The encoder which is connected to the crtc (manager) is picked by
>> combination of encoder->possible_crtcs bitmask and
>> connector->best_encoder().  We could keep things limited so that the
>> association of crtc to encoder (manager to output, roughly) never
>> changes, but this isn't really the right thing to do.  It is better that
>> the dssdev not rely on knowing the manager it is attached to at probe
>> time, but instead grab resources more dynamically.
>>
>> Also, at the moment we don't really have any notification to userspace
>> about new encoders/connectors showing up (or conversely, being
>> removed).  Only about existing connectors being plugged/unplugged.  The
>> closest analogy is perhaps the USB display devices, but even there it is
>> only the entire drm device that is plugged/unplugged.  And TBH I don't
>> really see the point in supporting panel drivers being dynamically
>> loaded.  It isn't like someone is dynamically soldering on a new display
>> connector to some board that is running.  I think omapfb or omapdrm
>> probe should trigger registering the compiled-in panel drivers, so that
>> it can be sure that the dssdev's pop up before it goes and creates drm
>> connector objects.  Currently we have to hack around this in omapdrm
>> with late_initcall() to ensure the panel drivers are probed first, but
>> that is an ugly hack that I'd like to get rid of.
>
> We have panel devices and panel drivers, each of which can appear at any
> time. Both are needed for the panel probe to happen. If we don't support
> device hotplugging (dynamic creation of devices), we need to use
> late_initcall for omapfb/drm. At least I don't see any other option.
>
> You say that omapdrm should trigger registering of the drivers. How
> would that work? Do you mean that the panel drivers would register
> themselves to some common list, and omapdrm would go through this list
> when drm is loaded, calling probe for the items in the list? I guess
> that's doable, but... It's not how kernel drivers are supposed to work,
> and so doesn't sound very clean approach to me.

I mean, similar to how we handle the subdev for dmm..  the
omap_drm_init() does the platform_driver_register() for the dmm device
before the platform_driver_register() for omapdrm itself, so we know
if there is a dmm device, the driver gets probed first before omapdrm.

It could be a matter of iterating through a list, or something like
this.. that is basically an implementation detail.  But the end result
is that the order the drivers are registered is controlled so the
probe sequence works out properly (not to mention suspend/resume
sequence).

> I think we should support proper hotplugging of the panels. This would
> fix the problem about init order, but it would also give us device
> hotplug support. Obviously nobody is going to solder panel to a running
> board, but I don't see any reason why panels, or, more likely, panels on
> an add-on boards (like the capes being discussed in omap ml) would not
> be hotpluggable using whatever connector is used on the particular use case.
>
> And even if we don't support removing of the devices, things like the
> add-on capes could cause the panel on the cape to be identified at some
> late time (the panel is not described in the board file or DT data, but
> found at runtime depending on the ID of the cape). This would add
> another step to the init sequence that should be just right, if we don't
> support hotplug.

If capes are really hot-pluggable, then maybe it is worth thinking
about how to make this more dynamic.  Although it is a bigger problem,
which involves userspace being aware that connectors can dynamically
appear/disappear.  And the dynamic 

[PATCH] drm/radeon: fix typo in evergreen_mc_resume()

2012-11-06 Thread Michel Dänzer
On Mon, 2012-11-05 at 11:34 -0500, alexdeucher at gmail.com wrote: 
> From: Alex Deucher 
> 
> Add missing index that may have led us to enabling
> more crtcs than necessary.
> 
> May also fix:
> https://bugs.freedesktop.org/show_bug.cgi?id=56139
> 
> Signed-off-by: Alex Deucher 

Reviewed-by: Michel D?nzer 


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer


[ANNOUNCE] libdrm 2.4.40

2012-11-06 Thread Marek Olšák
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

libdrm 2.4.40 has been released.

The reason is we need to use the radeon stencil mipmap allocator for combined
depth-stencil buffers in Mesa.


Alex Deucher (1):
  radeon: add some new SI pci ids

Andreas Boll (1):
  radeon: fix unused-function warning

Chris Wilson (3):
  intel: Fix "properly test for HAS_LLC"
  intel: Correct the word decoding for gen2 3DSTATE_LOAD_STATE_IMMEDIATE_1
  intel: Silence a trivial compiler warning

Daniel Stone (1):
  configure.ac: Allow forcible disabling of Cairo support

Daniel Vetter (1):
  intel: properly test for HAS_LLC

Dave Airlie (1):
  fix make distcheck

Jakob Bornecrantz (1):
  vmwgfx: No longer experimental

Jesse Barnes (2):
  intel: add support for ValleyView
  libdrm: man page infrastructure and a few sample man pages

Kristian H?gsberg (1):
  intel: Mark bo's exported to prime as not reusable

Marcin Slusarz (1):
  libkms: link against libdrm

Marek Ol??k (5):
  radeon: don't take the stencil-specific codepath for buffers without
stencil
  radeon: don't force stencil tile split to 0
  radeon: fix stencil miptree allocation of combined ZS buffers on EG and
SI
  radeon: fix tile_split of 128-bit surface formats with 8x MSAA
  configure.ac: bump version to 2.4.40 for release

Michel D?nzer (3):
  radeon: Fix layout of linear aligned mipmaps on SI.
  radeon: Memory footprint of SI mipmap base level is padded to powers of
two.
  radeon: Sampling pitch for non-mipmaps seems padded to slice alignment
on SI.

Rob Clark (2):
  update gitignore
  initialize width/height fields in drmModeCrtc

Vincent Penquerc'h (1):
  omap: release lock also on error paths

git tag: libdrm-2.4.40

http://dri.freedesktop.org/libdrm/libdrm-2.4.40.tar.bz2
MD5:  626a3dc44a40ef37565b61732b688567  libdrm-2.4.40.tar.bz2
SHA1: 0f77aa49922e17102caa75de86c8e79bbf23b4a1  libdrm-2.4.40.tar.bz2
SHA256: 48c14e4600ea0fde522292893eb4055d2f6d86a69d093d379c827deaccffaa1f
 libdrm-2.4.40.tar.bz2

http://dri.freedesktop.org/libdrm/libdrm-2.4.40.tar.gz
MD5:  d6c7eae620f0c0252377f0bf6a02ce54  libdrm-2.4.40.tar.gz
SHA1: fa16e9704514e3368a5b207ba250a7d7626b627b  libdrm-2.4.40.tar.gz
SHA256: 9f2ea4c1e5656c28e9237e9a67c58282b86b8e964aac5734774a2cd30ee17381
 libdrm-2.4.40.tar.gz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBAgAGBQJQmGD3AAoJEP3RXVrO8PKxg4cH/RDZUrVYqm4nDfnuVUFHLcju
SgPv3HEScFMvYeyrwNIGJKFca6ZkUQdS19YtS9x88WeRjsC811BNjQoNyvZd1D+V
6mKZwATR0IZ4bRmTTU58zgqFqboIdzrzXi/Cv0U3Qx7pbDdCUrHUAvcyjvLG5/Y6
SU9VmrQe1p/tlr3beQbJALhSFJpXJMS57BXz0M/58MlmeKplXjoPLVd/teOZGXB2
s4kxj1r4WBKcdnD9vnjoRrcrRV5ghdliqnmZf+xM2edBRIoreGQ/ZPzc9tXT8ywF
3BsBvyDxRwZFtUlDTocUrdTAeCpGQPhDe2pbxcMUKnA98ZUfmk+mHR7WL2HpE84=
=eban
-END PGP SIGNATURE-


[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-dae...@freedesktop.org
 kicks in with the "gfxpayload=keep" is an unsynced monitor.
Sometimes the display will be black, other times it will only appear in the
first couple of vertical lines, in others it will be vertically synced but
shifted to the right at half or at two third of the screen. In other words,
this really seems to be a sync problem. Should I try to combine patch 69113 and
patch 69370 with the others?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/136a79da/attachment.html>


[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-dae...@freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #18 from Alexandre Demers  ---
(In reply to comment #16)
> Created attachment 69573 [details] [review]
> possible fix
> 
> Actually, I think I found the problem.  Missing index in mc_resume().

This seems to fix my resume problem I was experiencing where the display would
come up, but then it would crash. However, it doesn't solve the boot/grub2 bug.

So, this patch should be kept (but not for the current bug).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/314a8974/attachment.html>


[Bug 56405] Distorted graphics on Radeon HD 6620G

2012-11-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=56405

--- Comment #12 from Michel Dänzer mic...@daenzer.net ---
What are the compile errors?

-- 
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 26735] r600: rendering artifacts

2012-11-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=26735

Török Edwin edwin+m...@etorok.net changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #13 from Török Edwin edwin+m...@etorok.net ---
(In reply to comment #12)
 Note: classic r600 driver has been abandoned.
 Please use r600g (gallium driver) instead.
 
 Is this still an issue with a newer driver/kernel?

Rendering looks correct now, tested with r600g version '3.0 Mesa 9.1-devel
(git-e87a578)' (R600_LLVM=0).

-- 
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 30845] [855 missing dvo driver] DVI output unsupported

2012-11-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=30845

Daniel Vetter dan...@ffwll.ch changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #7 from Daniel Vetter dan...@ffwll.ch ---
Mass-closing missing dvo driver bugs. We won't ever do that, so this needs a RE
effort from someone else.

-- 
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


[PATCH 2/4] kref: Implement kref_get_unless_zero v3

2012-11-06 Thread Thomas Hellstrom
This function is intended to simplify locking around refcounting for
objects that can be looked up from a lookup structure, and which are
removed from that lookup structure in the object destructor.
Operations on such objects require at least a read lock around
lookup + kref_get, and a write lock around kref_put + remove from lookup
structure. Furthermore, RCU implementations become extremely tricky.
With a lookup followed by a kref_get_unless_zero *with return value check*
locking in the kref_put path can be deferred to the actual removal from
the lookup structure and RCU lookups become 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 100644
--- a/include/linux/kref.h
+++ b/include/linux/kref.h
@@ -111,4 +111,25 @@ static inline int kref_put_mutex(struct kref *kref,
}
return 0;
 }
+
+/**
+ * kref_get_unless_zero - Increment refcount for object unless it is zero.
+ * @kref: object.
+ *
+ * Return non-zero if the increment succeeded. Otherwise return 0.
+ *
+ * This function is intended to simplify locking around refcounting for
+ * objects that can be looked up from a lookup structure, and which are
+ * removed from that lookup structure in the object destructor.
+ * Operations on such objects require at least a read lock around
+ * lookup + kref_get, and a write lock around kref_put + remove from lookup
+ * structure. Furthermore, RCU implementations become extremely tricky.
+ * With a lookup followed by a kref_get_unless_zero *with return value check*
+ * locking in the kref_put path can be deferred to the actual removal from
+ * the lookup structure and RCU lookups become trivial.
+ */
+static inline int __must_check kref_get_unless_zero(struct kref *kref)
+{
+   return atomic_add_unless(kref-refcount, 1, 0);
+}
 #endif /* _KREF_H_ */
-- 
1.7.4.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 3/4] drm/ttm, drm/vmwgfx: Use RCU locking for object lookups v3

2012-11-06 Thread Thomas Hellstrom
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 synchronization is needed
at module unload time.

v2: 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/ttm_object.h |4 
 3 files changed, 19 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_object.c b/drivers/gpu/drm/ttm/ttm_object.c
index c785787..f18eeb4 100644
--- a/drivers/gpu/drm/ttm/ttm_object.c
+++ b/drivers/gpu/drm/ttm/ttm_object.c
@@ -80,7 +80,7 @@ struct ttm_object_file {
  */
 
 struct ttm_object_device {
-   rwlock_t object_lock;
+   spinlock_t object_lock;
struct drm_open_hash object_hash;
atomic_t object_count;
struct ttm_mem_global *mem_glob;
@@ -157,12 +157,12 @@ int ttm_base_object_init(struct ttm_object_file *tfile,
base-refcount_release = refcount_release;
base-ref_obj_release = ref_obj_release;
base-object_type = object_type;
-   write_lock(tdev-object_lock);
+   spin_lock(tdev-object_lock);
kref_init(base-refcount);
ret = drm_ht_just_insert_please(tdev-object_hash,
base-hash,
(unsigned long)base, 31, 0, 0);
-   write_unlock(tdev-object_lock);
+   spin_unlock(tdev-object_lock);
if (unlikely(ret != 0))
goto out_err0;
 
@@ -186,30 +186,22 @@ static void ttm_release_base(struct kref *kref)
container_of(kref, struct ttm_base_object, refcount);
struct ttm_object_device *tdev = base-tfile-tdev;
 
+   spin_lock(tdev-object_lock);
(void)drm_ht_remove_item(tdev-object_hash, base-hash);
-   write_unlock(tdev-object_lock);
+   spin_unlock(tdev-object_lock);
if (base-refcount_release) {
ttm_object_file_unref(base-tfile);
base-refcount_release(base);
}
-   write_lock(tdev-object_lock);
 }
 
 void ttm_base_object_unref(struct ttm_base_object **p_base)
 {
struct ttm_base_object *base = *p_base;
-   struct ttm_object_device *tdev = base-tfile-tdev;
 
*p_base = NULL;
 
-   /*
-* Need to take the lock here to avoid racing with
-* users trying to look up the object.
-*/
-
-   write_lock(tdev-object_lock);
kref_put(base-refcount, ttm_release_base);
-   write_unlock(tdev-object_lock);
 }
 EXPORT_SYMBOL(ttm_base_object_unref);
 
@@ -221,14 +213,14 @@ struct ttm_base_object *ttm_base_object_lookup(struct 
ttm_object_file *tfile,
struct drm_hash_item *hash;
int ret;
 
-   read_lock(tdev-object_lock);
+   rcu_read_lock();
ret = drm_ht_find_item(tdev-object_hash, key, hash);
 
if (likely(ret == 0)) {
base = drm_hash_entry(hash, struct ttm_base_object, hash);
-   kref_get(base-refcount);
+   ret = kref_get_unless_zero(base-refcount) ? 0 : -EINVAL;
}
-   read_unlock(tdev-object_lock);
+   rcu_read_unlock();
 
if (unlikely(ret != 0))
return NULL;
@@ -426,7 +418,7 @@ struct ttm_object_device *ttm_object_device_init(struct 
ttm_mem_global
return NULL;
 
tdev-mem_glob = mem_glob;
-   rwlock_init(tdev-object_lock);
+   spin_lock_init(tdev-object_lock);
atomic_set(tdev-object_count, 0);
ret = drm_ht_create(tdev-object_hash, hash_order);
 
@@ -444,9 +436,9 @@ void ttm_object_device_release(struct ttm_object_device 
**p_tdev)
 
*p_tdev = NULL;
 
-   write_lock(tdev-object_lock);
+   spin_lock(tdev-object_lock);
drm_ht_remove(tdev-object_hash);
-   write_unlock(tdev-object_lock);
+   spin_unlock(tdev-object_lock);
 
kfree(tdev);
 }
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index da3c6b5..ae675c6 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -351,7 +351,7 @@ static void vmw_user_context_free(struct vmw_resource *res)
container_of(res, struct vmw_user_context, res);
struct vmw_private *dev_priv = res-dev_priv;
 
-   kfree(ctx);
+   ttm_base_object_kfree(ctx, base);
ttm_mem_global_free(vmw_mem_glob(dev_priv),
vmw_user_context_size);
 }
@@ -1147,7 +1147,7 @@ static void vmw_user_surface_free(struct vmw_resource 
*res)
kfree(srf-offsets);
kfree(srf-sizes);
kfree(srf-snooper.image);
-   kfree(user_srf);
+   ttm_base_object_kfree(user_srf, base);

[PATCH 4/4] drm/ttm: Optimize reservation slightly

2012-11-06 Thread Thomas Hellstrom
Reservation locking currently always takes place under the LRU spinlock.
Hence, strictly there is no need for an atomic_cmpxchg call; we can use
atomic_read followed by atomic_write since nobody else will ever reserve
without the lru spinlock held.
At least on Intel this should remove a locked bus 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 b/drivers/gpu/drm/ttm/ttm_bo.c
index bf6e4b5..46008ea 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -220,7 +220,7 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
struct ttm_bo_global *glob = bo-glob;
int ret;
 
-   while (unlikely(atomic_cmpxchg(bo-reserved, 0, 1) != 0)) {
+   while (unlikely(atomic_read(bo-reserved) != 0)) {
/**
 * Deadlock avoidance for multi-bo reserving.
 */
@@ -249,6 +249,7 @@ int ttm_bo_reserve_locked(struct ttm_buffer_object *bo,
return ret;
}
 
+   atomic_set(bo-reserved, 1);
if (use_sequence) {
/**
 * Wake up waiters that may need to recheck for deadlock,
-- 
1.7.4.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 50091] GeForce 6150SE: system hangs on X-server start with garbled screen

2012-11-06 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=50091


Alan a...@lxorguk.ukuu.org.uk changed:

   What|Removed |Added

 CC||a...@lxorguk.ukuu.org.uk
  Component|Video(Other)|Video(DRI - non Intel)
 AssignedTo|drivers_video-other@kernel- |drivers_video-dri@kernel-bu
   |bugs.osdl.org   |gs.osdl.org




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] drm/ttm: alter cpu_writers to return -EBUSY in ttm_execbuf_util reservations

2012-11-06 Thread Maarten Lankhorst
This is similar to other platforms that don't allow command submission
to buffers locked on the cpu.

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com

---

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bf6e4b5..2b3f69b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1054,16 +1054,6 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
 }
 EXPORT_SYMBOL(ttm_bo_mem_space);
 
-int ttm_bo_wait_cpu(struct ttm_buffer_object *bo, bool no_wait)
-{
-   if ((atomic_read(bo-cpu_writers)  0)  no_wait)
-   return -EBUSY;
-
-   return wait_event_interruptible(bo-event_queue,
-   atomic_read(bo-cpu_writers) == 0);
-}
-EXPORT_SYMBOL(ttm_bo_wait_cpu);
-
 int ttm_bo_move_buffer(struct ttm_buffer_object *bo,
struct ttm_placement *placement,
bool interruptible, bool no_wait_reserve,
@@ -1797,8 +1787,7 @@ EXPORT_SYMBOL(ttm_bo_synccpu_write_grab);
 
 void ttm_bo_synccpu_write_release(struct ttm_buffer_object *bo)
 {
-   if (atomic_dec_and_test(bo-cpu_writers))
-   wake_up_all(bo-event_queue);
+   atomic_dec(bo-cpu_writers);
 }
 EXPORT_SYMBOL(ttm_bo_synccpu_write_release);
 
diff --git a/drivers/gpu/drm/ttm/ttm_execbuf_util.c 
b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
index 1937069..7aa5073 100644
--- a/drivers/gpu/drm/ttm/ttm_execbuf_util.c
+++ b/drivers/gpu/drm/ttm/ttm_execbuf_util.c
@@ -185,10 +185,7 @@ retry_this_bo:
ttm_eu_backoff_reservation_locked(list);
spin_unlock(glob-lru_lock);
ttm_eu_list_ref_sub(list);
-   ret = ttm_bo_wait_cpu(bo, false);
-   if (ret)
-   return ret;
-   goto retry;
+   return -EBUSY;
}
}
 
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index e8028ad..850424f 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -429,8 +429,9 @@ extern void ttm_bo_unlock_delayed_workqueue(struct 
ttm_bo_device *bdev,
  * @no_wait: Return immediately if buffer is busy.
  *
  * Synchronizes a buffer object for CPU RW access. This means
- * blocking command submission that affects the buffer and
- * waiting for buffer idle. This lock is recursive.
+ * command submission that affects the buffer will return -EBUSY
+ * until ttm_bo_synccpu_write_release is called.
+ *
  * Returns
  * -EBUSY if the buffer is busy and no_wait is true.
  * -ERESTARTSYS if interrupted by a signal.
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index d803b92..3e193f5 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -729,20 +729,6 @@ extern void ttm_bo_mem_put(struct ttm_buffer_object *bo,
 extern void ttm_bo_mem_put_locked(struct ttm_buffer_object *bo,
  struct ttm_mem_reg *mem);
 
-/**
- * ttm_bo_wait_for_cpu
- *
- * @bo: Pointer to a struct ttm_buffer_object.
- * @no_wait: Don't sleep while waiting.
- *
- * Wait until a buffer object is no longer sync'ed for CPU access.
- * Returns:
- * -EBUSY: Buffer object was sync'ed for CPU access. (only if no_wait == 1).
- * -ERESTARTSYS: An interruptible sleep was interrupted by a signal.
- */
-
-extern int ttm_bo_wait_cpu(struct ttm_buffer_object *bo, bool no_wait);
-
 extern void ttm_bo_global_release(struct drm_global_reference *ref);
 extern int ttm_bo_global_init(struct drm_global_reference *ref);
 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available

2012-11-06 Thread Tomi Valkeinen
On 2012-11-05 16:21, Rob Clark wrote:
 On 11/05/2012 02:55 AM, Tomi Valkeinen wrote:
 But even then, choosing the manager is not easy, as whoever chooses the
 manager needs to observe all the possible displays used at the same
 time...
 
 Right. I was wondering if omapfb/omapdrm could understand the 'all
 possible displays information' better compared to a panel's probe.
 
 Even omapdrm/omafb can't be perfect because we could insert a panel
 driver module at any time, and omapfb/omapdrm may miss that out.
 True, omapdrm/fb may have a better idea. It's still unclear though.
 Currently we have quite strict order in the sequence the modules need to
 be loaded, which is quite bad and causes issues. We should make things
 more dynamic, so that the initialization of the drivers could happen
 more freely.

 But that creates more problems: when booting up, omapfb starts. But
 omapfb can't know if all the panel drivers have already been loaded.
 omapfb may see that DVI is the default display, but what should it do if
 DVI doesn't have a driver yet? It could wait, but perhaps the driver for
 DVI will never even be loaded.
 
 The encoder which is connected to the crtc (manager) is picked by
 combination of encoder-possible_crtcs bitmask and
 connector-best_encoder().  We could keep things limited so that the
 association of crtc to encoder (manager to output, roughly) never
 changes, but this isn't really the right thing to do.  It is better that
 the dssdev not rely on knowing the manager it is attached to at probe
 time, but instead grab resources more dynamically.
 
 Also, at the moment we don't really have any notification to userspace
 about new encoders/connectors showing up (or conversely, being
 removed).  Only about existing connectors being plugged/unplugged.  The
 closest analogy is perhaps the USB display devices, but even there it is
 only the entire drm device that is plugged/unplugged.  And TBH I don't
 really see the point in supporting panel drivers being dynamically
 loaded.  It isn't like someone is dynamically soldering on a new display
 connector to some board that is running.  I think omapfb or omapdrm
 probe should trigger registering the compiled-in panel drivers, so that
 it can be sure that the dssdev's pop up before it goes and creates drm
 connector objects.  Currently we have to hack around this in omapdrm
 with late_initcall() to ensure the panel drivers are probed first, but
 that is an ugly hack that I'd like to get rid of.

We have panel devices and panel drivers, each of which can appear at any
time. Both are needed for the panel probe to happen. If we don't support
device hotplugging (dynamic creation of devices), we need to use
late_initcall for omapfb/drm. At least I don't see any other option.

You say that omapdrm should trigger registering of the drivers. How
would that work? Do you mean that the panel drivers would register
themselves to some common list, and omapdrm would go through this list
when drm is loaded, calling probe for the items in the list? I guess
that's doable, but... It's not how kernel drivers are supposed to work,
and so doesn't sound very clean approach to me.

I think we should support proper hotplugging of the panels. This would
fix the problem about init order, but it would also give us device
hotplug support. Obviously nobody is going to solder panel to a running
board, but I don't see any reason why panels, or, more likely, panels on
an add-on boards (like the capes being discussed in omap ml) would not
be hotpluggable using whatever connector is used on the particular use case.

And even if we don't support removing of the devices, things like the
add-on capes could cause the panel on the cape to be identified at some
late time (the panel is not described in the board file or DT data, but
found at runtime depending on the ID of the cape). This would add
another step to the init sequence that should be just right, if we don't
support hotplug.

Yes, I know it's not simple =). And I'm fine with simpler approach for
the time being, but I'd like full hotplug to be the future goal. At
least the common panel framework should not create restrictions about
this, even if drm wouldn't allow device hotplug.

 Tomi

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH 1/3] drm/ttm: add ttm_bo_is_reserved

2012-11-06 Thread Maarten Lankhorst
Op 25-10-12 09:42, Thomas Hellstrom schreef:
 On 10/12/2012 04:58 PM, Maarten Lankhorst wrote:
 Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
 ---
   drivers/gpu/drm/ttm/ttm_bo.c |   12 ++--
   include/drm/ttm/ttm_bo_api.h |   14 ++
   2 files changed, 20 insertions(+), 6 deletions(-)

 diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
 index be1148e..d9d8541 100644
 --- a/drivers/gpu/drm/ttm/ttm_bo.c
 +++ b/drivers/gpu/drm/ttm/ttm_bo.c
 @@ -161,9 +161,9 @@ int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo, 
 bool interruptible)
   {
   if (interruptible) {
   return wait_event_interruptible(bo-event_queue,
 -   atomic_read(bo-reserved) == 0);
 +   !ttm_bo_is_reserved(bo));
   } else {
 -wait_event(bo-event_queue, atomic_read(bo-reserved) == 0);
 +wait_event(bo-event_queue, !ttm_bo_is_reserved(bo));
   return 0;
   }
   }
 @@ -174,7 +174,7 @@ void ttm_bo_add_to_lru(struct ttm_buffer_object *bo)
   struct ttm_bo_device *bdev = bo-bdev;
   struct ttm_mem_type_manager *man;
   -BUG_ON(!atomic_read(bo-reserved));
 +BUG_ON(!ttm_bo_is_reserved(bo));
 if (!(bo-mem.placement  TTM_PL_FLAG_NO_EVICT)) {
   @@ -748,7 +748,7 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, 
 bool interruptible,
   goto out;
   }
   -BUG_ON(!atomic_read(bo-reserved));
 +BUG_ON(!ttm_bo_is_reserved(bo));
 evict_mem = bo-mem;
   evict_mem.mm_node = NULL;
 @@ -1058,7 +1058,7 @@ int ttm_bo_move_buffer(struct ttm_buffer_object *bo,
   struct ttm_mem_reg mem;
   struct ttm_bo_device *bdev = bo-bdev;
   -BUG_ON(!atomic_read(bo-reserved));
 +BUG_ON(!ttm_bo_is_reserved(bo));
 /*
* FIXME: It's possible to pipeline buffer moves.
 @@ -1115,7 +1115,7 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
   {
   int ret;
   -BUG_ON(!atomic_read(bo-reserved));
 +BUG_ON(!ttm_bo_is_reserved(bo));
   /* Check that range is valid */
   if (placement-lpfn || placement-fpfn)
   if (placement-fpfn  placement-lpfn ||
 diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
 index 9654451..1d71f6b 100644
 --- a/include/drm/ttm/ttm_bo_api.h
 +++ b/include/drm/ttm/ttm_bo_api.h
 @@ -705,4 +705,18 @@ extern ssize_t ttm_bo_io(struct ttm_bo_device *bdev, 
 struct file *filp,
 extern void ttm_bo_swapout_all(struct ttm_bo_device *bdev);
   +/**
 + * ttm_bo_is_reserved - return an indication if a ttm buffer object is 
 reserved
 + *
 + * @bo: The buffer object to check.
 + *
 + * This function returns an indication if a bo is reserved or not, and 
 should
 + * only be used to print an error when it is not from incorrect api usage, 
 since
 + * there's no guarantee that it is the caller that is holding the 
 reservation.
 + */
 +static inline bool ttm_bo_is_reserved(struct ttm_buffer_object *bo)
 +{
 +return atomic_read(bo-reserved);
 +}
 +
   #endif
 This looks good, although for clarity we should add in the comments that
 if the caller is holding the reservation, the function is guaranteed to 
 return true.

 Otherwise
 Reviewed-by: Thomas Hellstrom thellst...@vmware.com

Unless you use lockdep, you can't say with 100% certainty if the CALLER is 
holding it or not. :-)
But lockdep can actually check if that's the case with 
lockdep_is_held(ttm-reservation_lock);
which iterates over all locks held by the current task.

~Maarten

Updated version with a comment about return value in ttm_bo_is_reserved:

drm/ttm: Add ttm_bo_is_reserved function

Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
Reviewed-by: Thomas Hellstrom thellst...@vmware.com

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2b3f69b..82e2633 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -162,9 +162,9 @@ int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo, 
bool interruptible)
 {
if (interruptible) {
return wait_event_interruptible(bo-event_queue,
-  atomic_read(bo-reserved) == 0);
+  !ttm_bo_is_reserved(bo));
} else {
-   wait_event(bo-event_queue, atomic_read(bo-reserved) == 0);
+   wait_event(bo-event_queue, !ttm_bo_is_reserved(bo));
return 0;
}
 }
@@ -175,7 +175,7 @@ void ttm_bo_add_to_lru(struct ttm_buffer_object *bo)
struct ttm_bo_device *bdev = bo-bdev;
struct ttm_mem_type_manager *man;
 
-   BUG_ON(!atomic_read(bo-reserved));
+   BUG_ON(!ttm_bo_is_reserved(bo));
 
if (!(bo-mem.placement  TTM_PL_FLAG_NO_EVICT)) {
 
@@ -756,7 +756,7 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, bool 
interruptible,
goto out;
}
 
-   BUG_ON(!atomic_read(bo-reserved));
+   

[PATCH RESEND] gma600: Enable HDMI support

2012-11-06 Thread Alan Cox
From: Alan Cox a...@linux.intel.com

There are still some mysteries left, in particular how (and in
fact if) the EDID is supposed to work on the HDMI port. However
the basic stuff now works and I can plug my Q550 into an HDMI
display and get the expected results.

[v2: cleans up space/tab and other formatting as per Dave's
 request]

Signed-off-by: Alan Cox a...@linux.intel.com
---

 drivers/gpu/drm/gma500/oaktrail.h|6 
 drivers/gpu/drm/gma500/oaktrail_crtc.c   |8 +
 drivers/gpu/drm/gma500/oaktrail_device.c |2 
 drivers/gpu/drm/gma500/oaktrail_hdmi.c   |  365 +-
 4 files changed, 365 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/gma500/oaktrail.h 
b/drivers/gpu/drm/gma500/oaktrail.h
index f2f9f38..30adbbe 100644
--- a/drivers/gpu/drm/gma500/oaktrail.h
+++ b/drivers/gpu/drm/gma500/oaktrail.h
@@ -249,3 +249,9 @@ extern void oaktrail_hdmi_i2c_exit(struct pci_dev *dev);
 extern void oaktrail_hdmi_save(struct drm_device *dev);
 extern void oaktrail_hdmi_restore(struct drm_device *dev);
 extern void oaktrail_hdmi_init(struct drm_device *dev, struct 
psb_intel_mode_device *mode_dev);
+extern int oaktrail_crtc_hdmi_mode_set(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
+   struct drm_display_mode 
*adjusted_mode, int x, int y,
+   struct drm_framebuffer *old_fb);
+extern void oaktrail_crtc_hdmi_dpms(struct drm_crtc *crtc, int mode);
+
+
diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c 
b/drivers/gpu/drm/gma500/oaktrail_crtc.c
index cdafd2a..4ec2962 100644
--- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
+++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
@@ -168,6 +168,11 @@ static void oaktrail_crtc_dpms(struct drm_crtc *crtc, int 
mode)
const struct psb_offset *map = dev_priv-regmap[pipe];
u32 temp;
 
+   if (pipe == 1) {
+   oaktrail_crtc_hdmi_dpms(crtc, mode);
+   return;
+   }
+
if (!gma_power_begin(dev, true))
return;
 
@@ -302,6 +307,9 @@ static int oaktrail_crtc_mode_set(struct drm_crtc *crtc,
uint64_t scalingType = DRM_MODE_SCALE_FULLSCREEN;
struct drm_connector *connector;
 
+   if (pipe == 1)
+   return oaktrail_crtc_hdmi_mode_set(crtc, mode, adjusted_mode, 
x, y, old_fb);
+
if (!gma_power_begin(dev, true))
return 0;
 
diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c 
b/drivers/gpu/drm/gma500/oaktrail_device.c
index 010b8207..08747fd 100644
--- a/drivers/gpu/drm/gma500/oaktrail_device.c
+++ b/drivers/gpu/drm/gma500/oaktrail_device.c
@@ -544,7 +544,7 @@ const struct psb_ops oaktrail_chip_ops = {
.accel_2d = 1,
.pipes = 2,
.crtcs = 2,
-   .hdmi_mask = (1  0),
+   .hdmi_mask = (1  1),
.lvds_mask = (1  0),
.cursor_needs_phys = 0,
.sgx_offset = MRST_SGX_OFFSET,
diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c 
b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
index 69e51e9..f036f1f 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
@@ -155,6 +155,345 @@ static void oaktrail_hdmi_audio_disable(struct drm_device 
*dev)
HDMI_READ(HDMI_HCR);
 }
 
+static void wait_for_vblank(struct drm_device *dev)
+{
+   /* Wait for 20ms, i.e. one cycle at 50hz. */
+   mdelay(20);
+}
+
+static unsigned int htotal_calculate(struct drm_display_mode *mode)
+{
+   u32 htotal, new_crtc_htotal;
+
+   htotal = (mode-crtc_hdisplay - 1) | ((mode-crtc_htotal - 1)  16);
+
+   /*
+* 1024 x 768  new_crtc_htotal = 0x1024;
+* 1280 x 1024 new_crtc_htotal = 0x0c34;
+*/
+   new_crtc_htotal = (mode-crtc_htotal - 1) * 200 * 1000 / mode-clock;
+
+   DRM_DEBUG_KMS(new crtc htotal 0x%4x\n, new_crtc_htotal);
+   return (mode-crtc_hdisplay - 1) | (new_crtc_htotal  16);
+}
+
+static void oaktrail_hdmi_find_dpll(struct drm_crtc *crtc, int target,
+   int refclk, struct oaktrail_hdmi_clock 
*best_clock)
+{
+   int np_min, np_max, nr_min, nr_max;
+   int np, nr, nf;
+
+   np_min = DIV_ROUND_UP(oaktrail_hdmi_limit.vco.min, target * 10);
+   np_max = oaktrail_hdmi_limit.vco.max / (target * 10);
+   if (np_min  oaktrail_hdmi_limit.np.min)
+   np_min = oaktrail_hdmi_limit.np.min;
+   if (np_max  oaktrail_hdmi_limit.np.max)
+   np_max = oaktrail_hdmi_limit.np.max;
+
+   nr_min = DIV_ROUND_UP((refclk * 1000), (target * 10 * np_max));
+   nr_max = DIV_ROUND_UP((refclk * 1000), (target * 10 * np_min));
+   if (nr_min  oaktrail_hdmi_limit.nr.min)
+   nr_min = oaktrail_hdmi_limit.nr.min;
+   if (nr_max  oaktrail_hdmi_limit.nr.max)
+   nr_max = oaktrail_hdmi_limit.nr.max;
+
+   np = DIV_ROUND_UP((refclk * 1000), (target * 10 * nr_max));
+   nr = DIV_ROUND_UP((refclk * 1000), (target * 10 * np));
+   nf = 

Re: [PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available

2012-11-06 Thread Rob Clark
On Tue, Nov 6, 2012 at 7:41 AM, Tomi Valkeinen to...@iki.fi wrote:
 On 2012-11-05 16:21, Rob Clark wrote:
 On 11/05/2012 02:55 AM, Tomi Valkeinen wrote:
 But even then, choosing the manager is not easy, as whoever chooses the
 manager needs to observe all the possible displays used at the same
 time...
 
 Right. I was wondering if omapfb/omapdrm could understand the 'all
 possible displays information' better compared to a panel's probe.
 
 Even omapdrm/omafb can't be perfect because we could insert a panel
 driver module at any time, and omapfb/omapdrm may miss that out.
 True, omapdrm/fb may have a better idea. It's still unclear though.
 Currently we have quite strict order in the sequence the modules need to
 be loaded, which is quite bad and causes issues. We should make things
 more dynamic, so that the initialization of the drivers could happen
 more freely.

 But that creates more problems: when booting up, omapfb starts. But
 omapfb can't know if all the panel drivers have already been loaded.
 omapfb may see that DVI is the default display, but what should it do if
 DVI doesn't have a driver yet? It could wait, but perhaps the driver for
 DVI will never even be loaded.

 The encoder which is connected to the crtc (manager) is picked by
 combination of encoder-possible_crtcs bitmask and
 connector-best_encoder().  We could keep things limited so that the
 association of crtc to encoder (manager to output, roughly) never
 changes, but this isn't really the right thing to do.  It is better that
 the dssdev not rely on knowing the manager it is attached to at probe
 time, but instead grab resources more dynamically.

 Also, at the moment we don't really have any notification to userspace
 about new encoders/connectors showing up (or conversely, being
 removed).  Only about existing connectors being plugged/unplugged.  The
 closest analogy is perhaps the USB display devices, but even there it is
 only the entire drm device that is plugged/unplugged.  And TBH I don't
 really see the point in supporting panel drivers being dynamically
 loaded.  It isn't like someone is dynamically soldering on a new display
 connector to some board that is running.  I think omapfb or omapdrm
 probe should trigger registering the compiled-in panel drivers, so that
 it can be sure that the dssdev's pop up before it goes and creates drm
 connector objects.  Currently we have to hack around this in omapdrm
 with late_initcall() to ensure the panel drivers are probed first, but
 that is an ugly hack that I'd like to get rid of.

 We have panel devices and panel drivers, each of which can appear at any
 time. Both are needed for the panel probe to happen. If we don't support
 device hotplugging (dynamic creation of devices), we need to use
 late_initcall for omapfb/drm. At least I don't see any other option.

 You say that omapdrm should trigger registering of the drivers. How
 would that work? Do you mean that the panel drivers would register
 themselves to some common list, and omapdrm would go through this list
 when drm is loaded, calling probe for the items in the list? I guess
 that's doable, but... It's not how kernel drivers are supposed to work,
 and so doesn't sound very clean approach to me.

I mean, similar to how we handle the subdev for dmm..  the
omap_drm_init() does the platform_driver_register() for the dmm device
before the platform_driver_register() for omapdrm itself, so we know
if there is a dmm device, the driver gets probed first before omapdrm.

It could be a matter of iterating through a list, or something like
this.. that is basically an implementation detail.  But the end result
is that the order the drivers are registered is controlled so the
probe sequence works out properly (not to mention suspend/resume
sequence).

 I think we should support proper hotplugging of the panels. This would
 fix the problem about init order, but it would also give us device
 hotplug support. Obviously nobody is going to solder panel to a running
 board, but I don't see any reason why panels, or, more likely, panels on
 an add-on boards (like the capes being discussed in omap ml) would not
 be hotpluggable using whatever connector is used on the particular use case.

 And even if we don't support removing of the devices, things like the
 add-on capes could cause the panel on the cape to be identified at some
 late time (the panel is not described in the board file or DT data, but
 found at runtime depending on the ID of the cape). This would add
 another step to the init sequence that should be just right, if we don't
 support hotplug.

If capes are really hot-pluggable, then maybe it is worth thinking
about how to make this more dynamic.  Although it is a bigger problem,
which involves userspace being aware that connectors can dynamically
appear/disappear.  And the dynamic disappearing is something I worry
about more.. it adds the possibility of all sorts of interesting race
conditions, such as connectors 

[Suggestion] drivers/gpu/drm/ttm: let constant string match the output format in ttm_dma_page_alloc_debugfs

2012-11-06 Thread Chen Gang
Hello David Airlie:

   for the h[4] is available (which length is 9), at line 1107.
   but for seq_printf at line 1114, its format is %8s.

   I suggest to make them match with each other (although it is not a bug).

   thanks.


1103 int ttm_dma_page_alloc_debugfs(struct seq_file *m, void *data)
1104 {
1105 struct device_pools *p;
1106 struct dma_pool *pool = NULL;
1107 char *h[] = {pool, refills, pages freed, inuse, 
available,
1108  name, virt, busaddr};
1109 
1110 if (!_manager) {
 seq_printf(m, No pool allocator running.\n);
1112 return 0;
1113 }
1114 seq_printf(m, %13s %12s %13s %8s %8s %8s\n,
1115h[0], h[1], h[2], h[3], h[4], h[5]);
1116 mutex_lock(_manager-lock);
1117 list_for_each_entry(p, _manager-pools, pools) {
1118 struct device *dev = p-dev;
1119 if (!dev)
1120 continue;
1121 pool = p-pool;
1122 seq_printf(m, %13s %12ld %13ld %8d %8d %8s\n,
1123 pool-name, pool-nrefills,
1124 pool-nfrees, pool-npages_in_use,
1125 pool-npages_free,
1126 pool-dev_name);
1127 }
1128 mutex_unlock(_manager-lock);
1129 return 0;
1130 }
1131 EXPORT_SYMBOL_GPL(ttm_dma_page_alloc_debugfs);



-- 
Chen Gang

Asianux Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH] nouveau: Fix crash after D3

2012-11-06 Thread Daniel J Blueman
In 3.7-rc4, when starting X with the integrated GPU and suspending the discrete 
GPU,
after one or more 32-bit applications are used (eg Skype) and X is stopped,
we hit a panic.

Prevent this by testing if the fini function is valid.

Full panic bootlog is at: http://quora.org/2012/nouveau/dmesg-crash.txt
Xorg.log is at: http://quora.org/2012/nouveau/Xorg.0.log-crash.txt
Kernel log after fix is at: http://quora.org/2012/nouveau/dmesg-fix.txt

Signed-off-by: Daniel J Blueman dan...@quora.org
---
 drivers/gpu/drm/nouveau/core/core/object.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/core/core/object.c 
b/drivers/gpu/drm/nouveau/core/core/object.c
index 0daab62..3da3525 100644
--- a/drivers/gpu/drm/nouveau/core/core/object.c
+++ b/drivers/gpu/drm/nouveau/core/core/object.c
@@ -354,12 +354,16 @@ static int
 nouveau_object_decf(struct nouveau_object *object)
 {
int ret;
+   struct nouveau_ofuncs *pfuncs;
 
nv_trace(object, stopping...\n);
 
-   ret = nv_ofuncs(object)-fini(object, false);
-   if (ret)
-   nv_warn(object, failed fini, %d\n, ret);
+   pfuncs = nv_ofuncs(object);
+   if (pfuncs-fini) {
+   ret = nv_ofuncs(object)-fini(object, false);
+   if (ret)
+   nv_warn(object, failed fini, %d\n, ret);
+   }
 
if (object-engine) {
mutex_lock(nv_subdev(object-engine)-mutex);
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Fix for vblank on nvc0

2012-11-06 Thread Kelly Doran
The vblank on nvc0 was not working correctly and would freeze X, I managed
to track it down and fix it with some help from m.b.lankhorst, see
https://bugs.freedesktop.org/show_bug.cgi?id=56692 for details.


nvc0_vblank_fix.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 50208] X does not start on Linux kernel 3.2.0-24, works on 3.0.0-19

2012-11-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=50208

--- Comment #3 from Nicola Larosa freedesktop.b...@teknico.net ---
It's still not working with 3.5.0-18.29 . :-( I don't know how to bisect.

-- 
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


Re: Fix for vblank on nvc0

2012-11-06 Thread Maarten Lankhorst


Op 06-11-12 15:48, Kelly Doran schreef:
 The vblank on nvc0 was not working correctly and would freeze X, I managed
 to track it down and fix it with some help from m.b.lankhorst, see
 https://bugs.freedesktop.org/show_bug.cgi?id=56692 for details.

Reviewed-by: Maarten Lankhorst maarten.lankho...@canonical.com

I recommended the bar flush since nvd0 does as well, and there might be a small 
race
otherwise.

Can this still get in before final 3.7 release?

~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 56405] Distorted graphics on Radeon HD 6620G

2012-11-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=56405

--- Comment #13 from Michael Dressel mdrs...@t-online.de ---
Created attachment 69640
  -- https://bugs.freedesktop.org/attachment.cgi?id=69640action=edit
compilation errors

These are the compile errors I get with the above mentioned commit.
The compile errors are fixed in the commit also mentioned above.

When I choose the start end endpoints for the bisecting
I looked at the date of the commit.
And the commit I related to the 8.0 tag by the date
does not compile either. So this was not a good starting point
in the first place.
I guess it would be better to bisect between the mesa-8.0.4 and mesa-9.0 tags.
If I try this git asks me to check a merge base first.
This merge base dates back to January and it seams to have
a very different configure/build structure.

-- 
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


[PATCH 1/4] drm/ttm: remove ttm_buffer_object-buffer_start

2012-11-06 Thread Marcin Slusarz
All drivers set it to 0 and nothing uses it.

Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
Cc: Thomas Hellstrom thellst...@vmware.com
---
 drivers/gpu/drm/ast/ast_ttm.c| 2 +-
 drivers/gpu/drm/cirrus/cirrus_ttm.c  | 2 +-
 drivers/gpu/drm/mgag200/mgag200_ttm.c| 2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
 drivers/gpu/drm/radeon/radeon_object.c   | 2 +-
 drivers/gpu/drm/ttm/ttm_bo.c | 8 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 4 ++--
 include/drm/ttm/ttm_bo_api.h | 9 -
 9 files changed, 10 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 1a026ac..0a54f65 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -356,7 +356,7 @@ int ast_bo_create(struct drm_device *dev, int size, int 
align,
 
ret = ttm_bo_init(ast-ttm.bdev, astbo-bo, size,
  ttm_bo_type_device, astbo-placement,
- align  PAGE_SHIFT, 0, false, NULL, acc_size,
+ align  PAGE_SHIFT, false, NULL, acc_size,
  NULL, ast_bo_ttm_destroy);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index bc83f83..90d7701 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -361,7 +361,7 @@ int cirrus_bo_create(struct drm_device *dev, int size, int 
align,
 
ret = ttm_bo_init(cirrus-ttm.bdev, cirrusbo-bo, size,
  ttm_bo_type_device, cirrusbo-placement,
- align  PAGE_SHIFT, 0, false, NULL, acc_size,
+ align  PAGE_SHIFT, false, NULL, acc_size,
  NULL, cirrus_bo_ttm_destroy);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c 
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index 1504699..49d60a6 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -355,7 +355,7 @@ int mgag200_bo_create(struct drm_device *dev, int size, int 
align,
 
ret = ttm_bo_init(mdev-ttm.bdev, mgabo-bo, size,
  ttm_bo_type_device, mgabo-placement,
- align  PAGE_SHIFT, 0, false, NULL, acc_size,
+ align  PAGE_SHIFT, false, NULL, acc_size,
  NULL, mgag200_bo_ttm_destroy);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 35ac57f..3cbf1a8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -225,7 +225,7 @@ nouveau_bo_new(struct drm_device *dev, int size, int align,
 
ret = ttm_bo_init(drm-ttm.bdev, nvbo-bo, size,
  type, nvbo-placement,
- align  PAGE_SHIFT, 0, false, NULL, acc_size, sg,
+ align  PAGE_SHIFT, false, NULL, acc_size, sg,
  nouveau_bo_del_ttm);
if (ret) {
/* ttm will call nouveau_bo_del_ttm if it fails.. */
diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index b91118c..0665845 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -140,7 +140,7 @@ int radeon_bo_create(struct radeon_device *rdev,
/* Kernel allocation are uninterruptible */
down_read(rdev-pm.mclk_lock);
r = ttm_bo_init(rdev-mman.bdev, bo-tbo, size, type,
-   bo-placement, page_align, 0, !kernel, NULL,
+   bo-placement, page_align, !kernel, NULL,
acc_size, sg, radeon_ttm_bo_destroy);
up_read(rdev-pm.mclk_lock);
if (unlikely(r != 0)) {
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bf6e4b5..27a2d3f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1179,7 +1179,6 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
enum ttm_bo_type type,
struct ttm_placement *placement,
uint32_t page_alignment,
-   unsigned long buffer_start,
bool interruptible,
struct file *persistent_swap_storage,
size_t acc_size,
@@ -1200,7 +1199,6 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
return -ENOMEM;
}
 
-   size += buffer_start  ~PAGE_MASK;
num_pages = (size + PAGE_SIZE - 1)  PAGE_SHIFT;
if (num_pages == 0) {
pr_err(Illegal buffer object size\n);
@@ -1233,7 +1231,6 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
bo-mem.page_alignment = page_alignment;
bo-mem.bus.io_reserved_vm = false;
bo-mem.bus.io_reserved_count = 0;
-   

[PATCH 2/4] drm/ttm: remove persistent_swap_storage argument from ttm_bo_init/ttm_bo_create

2012-11-06 Thread Marcin Slusarz
All drivers pass NULL here. ttm_buffer_object's field can still be set after
init, just like nouveau does.

Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
Cc: Thomas Hellstrom thellst...@vmware.com
---
 drivers/gpu/drm/ast/ast_ttm.c|  7 +++
 drivers/gpu/drm/cirrus/cirrus_ttm.c  |  2 +-
 drivers/gpu/drm/mgag200/mgag200_ttm.c|  2 +-
 drivers/gpu/drm/nouveau/nouveau_bo.c |  7 +++
 drivers/gpu/drm/radeon/radeon_object.c   |  6 +++---
 drivers/gpu/drm/ttm/ttm_bo.c |  7 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |  3 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |  8 +++-
 include/drm/ttm/ttm_bo_api.h | 16 +++-
 9 files changed, 20 insertions(+), 38 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 0a54f65..c6dcc84 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -354,10 +354,9 @@ int ast_bo_create(struct drm_device *dev, int size, int 
align,
acc_size = ttm_bo_dma_acc_size(ast-ttm.bdev, size,
   sizeof(struct ast_bo));
 
-   ret = ttm_bo_init(ast-ttm.bdev, astbo-bo, size,
- ttm_bo_type_device, astbo-placement,
- align  PAGE_SHIFT, false, NULL, acc_size,
- NULL, ast_bo_ttm_destroy);
+   ret = ttm_bo_init(ast-ttm.bdev, astbo-bo, size, ttm_bo_type_device,
+ astbo-placement, align  PAGE_SHIFT, false,
+ acc_size, NULL, ast_bo_ttm_destroy);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index 90d7701..65e665f 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -361,7 +361,7 @@ int cirrus_bo_create(struct drm_device *dev, int size, int 
align,
 
ret = ttm_bo_init(cirrus-ttm.bdev, cirrusbo-bo, size,
  ttm_bo_type_device, cirrusbo-placement,
- align  PAGE_SHIFT, false, NULL, acc_size,
+ align  PAGE_SHIFT, false, acc_size,
  NULL, cirrus_bo_ttm_destroy);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c 
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index 49d60a6..be121d1 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -355,7 +355,7 @@ int mgag200_bo_create(struct drm_device *dev, int size, int 
align,
 
ret = ttm_bo_init(mdev-ttm.bdev, mgabo-bo, size,
  ttm_bo_type_device, mgabo-placement,
- align  PAGE_SHIFT, false, NULL, acc_size,
+ align  PAGE_SHIFT, false, acc_size,
  NULL, mgag200_bo_ttm_destroy);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 3cbf1a8..82f0f3c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -223,10 +223,9 @@ nouveau_bo_new(struct drm_device *dev, int size, int align,
acc_size = ttm_bo_dma_acc_size(drm-ttm.bdev, size,
   sizeof(struct nouveau_bo));
 
-   ret = ttm_bo_init(drm-ttm.bdev, nvbo-bo, size,
- type, nvbo-placement,
- align  PAGE_SHIFT, false, NULL, acc_size, sg,
- nouveau_bo_del_ttm);
+   ret = ttm_bo_init(drm-ttm.bdev, nvbo-bo, size, type,
+ nvbo-placement, align  PAGE_SHIFT, false,
+ acc_size, sg, nouveau_bo_del_ttm);
if (ret) {
/* ttm will call nouveau_bo_del_ttm if it fails.. */
return ret;
diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index 0665845..834b291 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -139,9 +139,9 @@ int radeon_bo_create(struct radeon_device *rdev,
radeon_ttm_placement_from_domain(bo, domain);
/* Kernel allocation are uninterruptible */
down_read(rdev-pm.mclk_lock);
-   r = ttm_bo_init(rdev-mman.bdev, bo-tbo, size, type,
-   bo-placement, page_align, !kernel, NULL,
-   acc_size, sg, radeon_ttm_bo_destroy);
+   r = ttm_bo_init(rdev-mman.bdev, bo-tbo, size, type, bo-placement,
+   page_align, !kernel, acc_size, sg,
+   radeon_ttm_bo_destroy);
up_read(rdev-pm.mclk_lock);
if (unlikely(r != 0)) {
return r;
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 27a2d3f..412486c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1180,7 +1180,6 @@ int ttm_bo_init(struct 

[PATCH 3/4] drm/ttm: remove ttm_bo_device-nice_mode

2012-11-06 Thread Marcin Slusarz
It's unused.

Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
Cc: Thomas Hellstrom thellst...@vmware.com
---
 drivers/gpu/drm/ttm/ttm_bo.c| 1 -
 include/drm/ttm/ttm_bo_driver.h | 3 ---
 2 files changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 412486c..da7a985 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1570,7 +1570,6 @@ int ttm_bo_device_init(struct ttm_bo_device *bdev,
goto out_no_addr_mm;
 
INIT_DELAYED_WORK(bdev-wq, ttm_bo_delayed_workqueue);
-   bdev-nice_mode = true;
INIT_LIST_HEAD(bdev-ddestroy);
bdev-dev_mapping = NULL;
bdev-glob = glob;
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index d803b92..95628e7 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -521,8 +521,6 @@ struct ttm_bo_global {
  * lru_lock: Spinlock that protects the buffer+device lru lists and
  * ddestroy lists.
  * @val_seq: Current validation sequence.
- * @nice_mode: Try nicely to wait for buffer idle when cleaning a manager.
- * If a GPU lockup has been detected, this is forced to 0.
  * @dev_mapping: A pointer to the struct address_space representing the
  * device address space.
  * @wq: Work queue structure for the delayed delete workqueue.
@@ -556,7 +554,6 @@ struct ttm_bo_device {
 * Protected by load / firstopen / lastclose /unload sync.
 */
 
-   bool nice_mode;
struct address_space *dev_mapping;
 
/*
-- 
1.7.12

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[PATCH 4/4] drm/ttm: remove ttm_mem_global-queue

2012-11-06 Thread Marcin Slusarz
It's unused.

Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
Cc: Thomas Hellstrom thellst...@vmware.com
---
 drivers/gpu/drm/ttm/ttm_memory.c | 1 -
 include/drm/ttm/ttm_memory.h | 2 --
 2 files changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 479c6b0..dbc2def 100644
--- a/drivers/gpu/drm/ttm/ttm_memory.c
+++ b/drivers/gpu/drm/ttm/ttm_memory.c
@@ -367,7 +367,6 @@ int ttm_mem_global_init(struct ttm_mem_global *glob)
spin_lock_init(glob-lock);
glob-swap_queue = create_singlethread_workqueue(ttm_swap);
INIT_WORK(glob-work, ttm_shrink_work);
-   init_waitqueue_head(glob-queue);
ret = kobject_init_and_add(
glob-kobj, ttm_mem_glob_kobj_type, ttm_get_kobj(), 
memory_accounting);
if (unlikely(ret != 0)) {
diff --git a/include/drm/ttm/ttm_memory.h b/include/drm/ttm/ttm_memory.h
index d6d1da4..72dcbe8 100644
--- a/include/drm/ttm/ttm_memory.h
+++ b/include/drm/ttm/ttm_memory.h
@@ -60,7 +60,6 @@ struct ttm_mem_shrink {
  * for the GPU, and this will otherwise block other workqueue tasks(?)
  * At this point we use only a single-threaded workqueue.
  * @work: The workqueue callback for the shrink queue.
- * @queue: Wait queue for processes suspended waiting for memory.
  * @lock: Lock to protect the @shrink - and the memory accounting members,
  * that is, essentially the whole structure with some exceptions.
  * @zones: Array of pointers to accounting zones.
@@ -80,7 +79,6 @@ struct ttm_mem_global {
struct ttm_mem_shrink *shrink;
struct workqueue_struct *swap_queue;
struct work_struct work;
-   wait_queue_head_t queue;
spinlock_t lock;
struct ttm_mem_zone *zones[TTM_MEM_MAX_ZONES];
unsigned int num_zones;
-- 
1.7.12

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #20 from Alexandre Demers alexandre.f.dem...@gmail.com ---
Should I have a look at how grub2 handles and talks to the kernel when using
gfxpayload=keep? A quick search shows this issue has been lurking for some time
(2010) with various radeon card
(https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/605614,
http://frugalware.org/pipermail/frugalware-devel/2012-February/011500.html,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567245,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567393).

Could something be wrong when handling the framebuffer?

-- 
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 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #21 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #19)
 If I followed you correctly, setting bit 24 to 1 disables memory but keeps
 the CRTC state as it is (hopefully in sync with the monitor). However, what
 I see when grub2 kicks in with the gfxpayload=keep is an unsynced monitor.
 Sometimes the display will be black, other times it will only appear in the
 first couple of vertical lines, in others it will be vertically synced but
 shifted to the right at half or at two third of the screen. In other words,
 this really seems to be a sync problem. Should I try to combine patch 69113
 and patch 69370 with the others?

Are you saying the monitor gets messed up when grub kicks in?  I.e., before the
OS loads?  If so, that sounds like a grub issue.

-- 
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 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #22 from Alexandre Demers alexandre.f.dem...@gmail.com ---
(In reply to comment #21)
 (In reply to comment #19)
  If I followed you correctly, setting bit 24 to 1 disables memory but keeps
  the CRTC state as it is (hopefully in sync with the monitor). However, what
  I see when grub2 kicks in with the gfxpayload=keep is an unsynced monitor.
  Sometimes the display will be black, other times it will only appear in the
  first couple of vertical lines, in others it will be vertically synced but
  shifted to the right at half or at two third of the screen. In other words,
  this really seems to be a sync problem. Should I try to combine patch 69113
  and patch 69370 with the others?
 
 Are you saying the monitor gets messed up when grub kicks in?  I.e., before
 the OS loads?  If so, that sounds like a grub issue.

I'll take some pictures or record a small video of what's going on. That will
be easier to understand. But yes, I'm beginning to think Grub2 is playing a bad
trick somewhere in there and is not playing nicely when handling the
framebuffer.

-- 
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 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #23 from Alex Deucher ag...@yahoo.com ---
(In reply to comment #19)
 Should I try to combine patch 69113
 and patch 69370 with the others?

Worth a shot.

-- 
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 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

2012-11-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #24 from Alexandre Demers alexandre.f.dem...@gmail.com ---
I'll retest it with the latest two patches, but I think setting gfxpayload=text
prevents the bug. I know for sure that with the index patch, suspend/resume
cycle is fixed. Also, if I remove gfxpayload=keep completely, my monitor works
fine.

-- 
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 56828] New: Driver for Radeon has broken acceleration functionality with HD 5450

2012-11-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=56828

  Priority: medium
Bug ID: 56828
  Assignee: dri-devel@lists.freedesktop.org
   Summary: Driver for Radeon has broken acceleration
functionality with HD 5450
  Severity: normal
Classification: Unclassified
OS: Linux (All)
  Reporter: z...@jabster.pl
  Hardware: x86-64 (AMD64)
Status: NEW
   Version: unspecified
 Component: Drivers/DRI/R600
   Product: Mesa

Created attachment 69649
  -- https://bugs.freedesktop.org/attachment.cgi?id=69649action=edit
Xorg.0.log

Tested today released xf86-video-ati 7.0 and, unfortunately, it doesn't support
properly Radeon HD 5450.
The problems turned up while trying to run some more graphically demanding
application, say: game, for instance. For example: running FooBillard noticed,
that most of the time the game window was OK, but attempt to move it results in
garbage within the game window. While trying to run CG Madness the situation
was much worse: the entire screen started to blink strange way, there was no
other option, than to leave graphics with Control-Alt-Backspace. On the text
console there were messages:

radeon: The kernel rejected CS, see dmesg for more information.
radeon: The kernel rejected CS, see dmesg for more information.
radeon: The kernel rejected CS, see dmesg for more information.
radeon: The kernel rejected CS, see dmesg for more information.
radeon: The kernel rejected CS, see dmesg for more information.
radeon: The kernel rejected CS, see dmesg for more information.
radeon: The kernel rejected CS, see dmesg for more information.
radeon: The kernel rejected CS, see dmesg for more information.

dmesg reported:

radeon :02:00.0: evergreen_surface_check_2d:285 cb height 608 invalid must
be aligned with 64
radeon :02:00.0: evergreen_cs_track_validate_cb:427 cb[0] invalid
(0x0063 0x1daf 0x00090880 0x01088468)
radeon :02:00.0: evergreen_packet3_check:2105 invalid cmd stream 588
[drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
radeon :02:00.0: evergreen_surface_check_2d:285 cb height 608 invalid must
be aligned with 64
radeon :02:00.0: evergreen_cs_track_validate_cb:427 cb[0] invalid
(0x0063 0x1daf 0x00090880 0x01088468)
radeon :02:00.0: evergreen_packet3_check:2105 invalid cmd stream 574
[drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
radeon :02:00.0: evergreen_surface_check_2d:285 cb height 608 invalid must
be aligned with 64
radeon :02:00.0: evergreen_cs_track_validate_cb:427 cb[0] invalid
(0x0063 0x1daf 0x00090880 0x01088468)
radeon :02:00.0: evergreen_packet3_check:2105 invalid cmd stream 588
[drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
radeon :02:00.0: evergreen_surface_check_2d:285 cb height 608 invalid must
be aligned with 64
radeon :02:00.0: evergreen_cs_track_validate_cb:427 cb[0] invalid
(0x0063 0x1daf 0x00090880 0x01088468)
radeon :02:00.0: evergreen_packet3_check:2105 invalid cmd stream 588
[drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !

I was testing the driver using newest Slackware 14.0, with libdrm 2.4.39,
kernel 3.6.0. The system was 32-bit(!), although actually ran on 64-bit
hardware.

Very similar installation using this newest driver, ran on much older hardware
with K7 processor (early Sempron 1.8 GHz) - and with old Radeon 9600 - works
with no problems whatsoever (tested with both mentioned games, CG Madness
reached 36 FPS).

My /etc/xorg.conf

# Transparency on
Section Extensions
Option Composite Enable
Option RENDER Enable
EndSection

Section ServerLayout
Identifier X.org Configured
Screen  0  Screen0 0 0
#   Screen  1  Screen1 RightOf Screen0
#   Screen  2  Screen2 RightOf Screen1
InputDeviceMouse0 CorePointer
InputDeviceKeyboard0 CoreKeyboard
EndSection

Section Files
ModulePath   /usr/lib/xorg/modules
FontPath /usr/share/fonts/Speedo
FontPath /usr/share/fonts/TTF
FontPath /usr/share/fonts/OTF
FontPath /usr/share/fonts/Type1
FontPath /usr/share/fonts/misc
FontPath /usr/share/fonts/kanjistrokeorders
FontPath /usr/share/fonts/75dpi/:unscaled
FontPath /usr/share/fonts/100dpi/:unscaled
FontPath /usr/share/fonts/75dpi
FontPath /usr/share/fonts/100dpi
FontPath /usr/share/fonts/cyrillic
EndSection

Section Module
Load  extmod
Load  record
Load  dri2
Load  dri
Load  glx
Load  dbe
EndSection

Section InputDevice
Identifier  Keyboard0
Driver  kbd  
Option XkbRules xorg
Option XkbModel pc104
Option XkbLayout pl 
#   Option AutoRepeat 250 40
EndSection

Section InputDevice
Identifier  Mouse0
Driver  mouse

[git pull] drm radeon + core fixes

2012-11-06 Thread Dave Airlie

Hi Linus,

a single radeon typo fix for a regressions
and two fixes for a regression in the open helper addres space stuff.

Dave.

The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89:

  Linux 3.7-rc4 (2012-11-04 11:07:39 -0800)

are available in the git repository at:
  git://people.freedesktop.org/~airlied/linux drm-fixes

Alex Deucher (1):
  drm/radeon: fix typo in evergreen_mc_resume()

Ilija Hadzic (2):
  drm: restore open_count if drm_setup fails
  drm: set dev_mapping before calling drm_open_helper

 drivers/gpu/drm/drm_fops.c |   44 ---
 drivers/gpu/drm/radeon/evergreen.c |2 +-
 2 files changed, 31 insertions(+), 15 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm: exynos: add iommu support in hdmi driver with dt enabled

2012-11-06 Thread Leela Krishna Amudala
Hello Rahul,

On Mon, Nov 5, 2012 at 2:32 PM, Rahul Sharma rahul.sha...@samsung.com wrote:
 This patch adds iommu support for hdmi driver with device tree based
 search. It searches for sysmmu property in hdmi dt node to get tv
 iommu device pointer which will be used to configure iommu hw interface.

 This patch is based on exynos-drm-next-iommu branch at
 http://git.kernel.org/?p=linux/kernel/git/daeinki/drm-exynos.git

 This patch is having dependency on  linux-samsung-soc patchset named
 add dt based support for iommu for hdmi

 Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
 Signed-off-by: Prathyush K prathyus...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_hdmi.c |   35 
 ++
  1 files changed, 35 insertions(+), 0 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
 b/drivers/gpu/drm/exynos/exynos_hdmi.c
 index d1a1d71..ee110c9 100644
 --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
 +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
 @@ -34,7 +34,9 @@
  #include linux/regulator/consumer.h
  #include linux/io.h
  #include linux/of_gpio.h
 +#include linux/of_platform.h
  #include plat/gpio-cfg.h
 +#include mach/sysmmu.h

  #include drm/exynos_drm.h

 @@ -2275,6 +2277,34 @@ void hdmi_attach_hdmiphy_client(struct i2c_client 
 *hdmiphy)
  }

  #ifdef CONFIG_OF
 +
 +static int drm_hdmi_dt_init_iommu(struct device *dev)
 +{
 +   struct platform_device *pds;
 +   struct device_node *dn, *dns;
 +   const __be32 *parp;
 +
 +   dn = dev-of_node;
 +   parp = of_get_property(dn, sysmmu, NULL);
 +   if (parp == NULL) {
 +   dev_err(dev, failed to find sysmmu property\n);
 +   return -EINVAL;
 +   }
 +   dns = of_find_node_by_phandle(be32_to_cpup(parp));
 +   if (dns == NULL) {
 +   dev_err(dev, failed to find sysmmu node\n);
 +   return -EINVAL;
 +   }
 +   pds = of_find_device_by_node(dns);
 +   if (pds == NULL) {
 +   dev_err(dev, failed to find sysmmu platform device\n);
 +   return -EINVAL;
 +   }
 +
 +   platform_set_sysmmu(pds-dev, dev);
 +   return 0;
 +}
 +

As a part of adding iommu support to FIMD driver, we have to implement
the same function in FIMD driver also, which makes code replication.
So, it would be better to move this function out of this file and put
it in a common drm file so that FIMD also can use it.

Best Wishes,
Leela Krishna Amudala.

  static struct s5p_hdmi_platform_data *drm_hdmi_dt_parse_pdata
 (struct device *dev)
  {
 @@ -2294,6 +2324,11 @@ static struct s5p_hdmi_platform_data 
 *drm_hdmi_dt_parse_pdata
 goto err_data;
 }

 +   if (drm_hdmi_dt_init_iommu(dev)){
 +   DRM_ERROR(no sysmmu property found\n);
 +   goto err_data;
 +   }
 +
 pd-hpd_gpio = of_get_named_gpio_flags(np, hpd-gpio, 0, flags);

 return pd;
 --
 1.7.0.4

 ___
 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


[PATCH] drm/pci: add missing variable initialization

2012-11-06 Thread Jingoo Han
Fixed build warning as below:

arch/arm/mm/cache-l2x0.c:37:12: warning: 'l2_wt_override' defined but not used 
[-Wunused-variable]

Signed-off-by: Jingoo Han jg1@samsung.com
---
 drivers/gpu/drm/drm_pci.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
index ba33144..754bc96 100644
--- a/drivers/gpu/drm/drm_pci.c
+++ b/drivers/gpu/drm/drm_pci.c
@@ -470,7 +470,7 @@ int drm_pcie_get_speed_cap_mask(struct drm_device *dev, u32 
*mask)
 {
struct pci_dev *root;
int pos;
-   u32 lnkcap, lnkcap2;
+   u32 lnkcap = 0, lnkcap2 = 0;
 
*mask = 0;
if (!dev-pdev)
-- 
1.7.1


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [PATCH] drm/pci: add missing variable initialization

2012-11-06 Thread Jingoo Han
On Wednesday, November 07, 2012 2:37 PM Jingoo Han wrote
 
 Fixed build warning as below:
 
 arch/arm/mm/cache-l2x0.c:37:12: warning: 'l2_wt_override' defined but not 
 used [-Wunused-variable]

Sorry, this error message is wrong.
I made a mistake.

I will fix the error message and send v2 patch.

Best regards,
Jingoo Han

 
 Signed-off-by: Jingoo Han jg1@samsung.com
 ---
  drivers/gpu/drm/drm_pci.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_pci.c b/drivers/gpu/drm/drm_pci.c
 index ba33144..754bc96 100644
 --- a/drivers/gpu/drm/drm_pci.c
 +++ b/drivers/gpu/drm/drm_pci.c
 @@ -470,7 +470,7 @@ int drm_pcie_get_speed_cap_mask(struct drm_device *dev, 
 u32 *mask)
  {
   struct pci_dev *root;
   int pos;
 - u32 lnkcap, lnkcap2;
 + u32 lnkcap = 0, lnkcap2 = 0;
 
   *mask = 0;
   if (!dev-pdev)
 --
 1.7.1


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 56828] Driver for Radeon has broken acceleration functionality with HD 5450

2012-11-06 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=56828

Andreas Boll andreas.boll@gmail.com changed:

   What|Removed |Added

  Component|Drivers/DRI/R600|Drivers/Gallium/r600

--- Comment #1 from Andreas Boll andreas.boll@gmail.com ---
What's your mesa version. Could you attach the output from glxinfo?
You need at least mesa 9.0 .
2D tiling has been activated by default in xf86-video-ati 7.0
which only affects r6xx+ asics.
If you don't want to upgrade mesa you can disable that feature with setting

Option ColorTiling2D False

in your Xorg.conf

-- 
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