Re: [PATCH] fix typo in define: engine - memory

2009-12-02 Thread Rafał Miłecki
W dniu 4 listopada 2009 23:38 użytkownik Rafał Miłecki
zaj...@gmail.com napisał:
 Copypaste typo probably.

 On top of my [PATCH] drm/radeon/kms: add debugfs for power management
 for AtomBIOS devices.

ping

-- 
Rafał

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [PATCH] drm/radeon/kms/pm: fix typos

2009-12-02 Thread Rafał Miłecki
W dniu 6 listopada 2009 11:39 użytkownik Rafał Miłecki
zaj...@gmail.com napisał:
 Painless, just little confusing. Unit mistake reported by taiu.

ping

-- 
Rafał

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [PATCH] drm/radeon/kms: fix ring info in debugfs on r600+

2009-12-02 Thread Rafał Miłecki
W dniu 10 listopada 2009 22:34 użytkownik Rafał Miłecki
zaj...@gmail.com napisał:
 Fixes bug http://bugs.freedesktop.org/show_bug.cgi?id=24837

 Ack from glisse on IRC

ping

-- 
Rafał

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: radeon fence object allocation and free frequently

2009-12-02 Thread Thomas Hellström
Jerome Glisse wrote:
 On Thu, 2009-11-19 at 16:29 +0800, Donnie Fang wrote:
   
 Hi all,
 after reviewed the radeon fence scheme, there are lots of chances
 that it needs create a new fence object, and also there are lots of
 chances need to destroy these fence objects.
  In my opinion, is it possible to maintain a list for recording
 some freed fence object for later usage and hence save performance. Am
 i right?
 Donnie.

 

 Idea is that kernel allocator already do that for us. I would like to
 avoid having many pools in the driver, i don't think it's well behaving
 to do so. And fence are small enough to take advantage of any slab/slub
 allocator kernel has.

 However if you have benchmark that shows that fence allocation is
 slowing down, by huge margin, application than we might consider doing
 so. But i don't think fence are biggest bottleneck, i am pretty sure
 memory management is.

 Cheers,
 Jerome

   
I've also had some concerns about fence object allocation / destruction 
in the past, but it seems, just like Jerome points out,
that the slab / slub allocator does its job just fine, and I've never 
seen this end up high on benchmarks.

/Thomas



 --
 Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
 trial. Simplify your report design, integration and deployment - and focus on 
 what you do best, core application coding. Discover what's new with
 Crystal Reports now.  http://p.sf.net/sfu/bobj-july
 --
 ___
 Dri-devel mailing list
 Dri-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/dri-devel
   




--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: 945GM crash

2009-12-02 Thread Chris Wilson
On Wed, 02 Dec 2009 00:17:06 +, Svilen krustev.svi...@googlemail.com 
wrote:
 Hi guys,
 
 A bug reported initially here (Fedora 12)
 https://bugzilla.redhat.com/show_bug.cgi?id=541879
 
 You can see from the bug reports that it involves Mesa DRI Intel(R) 945GM 
 GEM 20090712 2009Q2 RC3 driver.
 
 The application uses glew library. After calling the glewInit(), the first 
 call to the openGL function which is glGenBuffers is causing the application 
 to crash.
 
 It's a cross platform application which works on other graphic 
 platforms/drivers on Linux as well as on Windows. Is there something I'm 
 missing in the initialization sequence? Or there is a problem with the driver?
 Shall I raise a bug?

This is an application bug. It is using OpenGL 2.0 features on a driver
restricted by the capabilities of its hardware to OpenGL 1.4, so
understandably tries to dereference a NULL function pointer when calling
glGenBuffers. However if the application truly wishes to be cross-device,
it can check for ARB_vertex_buffer_object and use the glGenBuffersARB
[and friends] extension points instead.

Hope this helps,
-ickle

-- 
Chris Wilson, Intel Open Source Technology Centre

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [PATCH 1/3] drm/ttm: Add range validation function

2009-12-02 Thread Thomas Hellström
Jerome,
Please see comments inline.


Jerome Glisse wrote:
 Add a function to validate buffer in a given range of
 memory. This is needed by some hw for some of their
 buffer (scanout buffer, cursor ...).

 Signed-off-by: Jerome Glisse jgli...@redhat.com
 ---
  drivers/gpu/drm/ttm/ttm_bo.c|  305 
 ++-
  include/drm/ttm/ttm_bo_api.h|5 +
  include/drm/ttm/ttm_bo_driver.h |1 +
  3 files changed, 310 insertions(+), 1 deletions(-)

 diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
 index 87c0625..6b0e7e8 100644
 --- a/drivers/gpu/drm/ttm/ttm_bo.c
 +++ b/drivers/gpu/drm/ttm/ttm_bo.c
 @@ -247,7 +247,6 @@ EXPORT_SYMBOL(ttm_bo_unreserve);
  /*
   * Call bo-mutex locked.
   */
 -
   

Whitespace.

  static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, bool zero_alloc)
  {
   struct ttm_bo_device *bdev = bo-bdev;
 @@ -418,6 +417,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object 
 *bo, bool remove_all)
   kref_put(bo-list_kref, ttm_bo_ref_bug);
   }
   if (bo-mem.mm_node) {
 + bo-mem.mm_node-private = NULL;
   drm_mm_put_block(bo-mem.mm_node);
   bo-mem.mm_node = NULL;
   }
 @@ -610,6 +610,7 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo, 
 unsigned mem_type,
  
   spin_lock(glob-lru_lock);
   if (evict_mem.mm_node) {
 + evict_mem.mm_node-private = NULL;
   drm_mm_put_block(evict_mem.mm_node);
   evict_mem.mm_node = NULL;
   }
   
 @@ -826,6 +827,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
   mem-mm_node = node;
   mem-mem_type = mem_type;
   mem-placement = cur_flags;
 + node-private = bo;
   return 0;
   }
  
   

I'd like a big warning here somewhere, because since the pointer to the 
bo is not refcounted, it may
never be dereferenced outside of the lru spinlock, because as soon as 
you release the lru spinlock, someone
else may destroy the buffer. The current usage is valid AFAICT. If you 
choose to refcount it, use bo::list_kref.


 @@ -856,6 +858,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
  
   if (ret == 0  mem-mm_node) {
   mem-placement = cur_flags;
 + mem-mm_node-private = bo;
   return 0;
   }
  
 @@ -868,6 +871,173 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
  }
  EXPORT_SYMBOL(ttm_bo_mem_space);
  
 +static unsigned long ttm_bo_free_size_if_evicted(struct ttm_buffer_object 
 *bo)
 +{
 + struct ttm_mem_type_manager *man = bo-bdev-man[bo-mem.mem_type];
 + struct drm_mm_node *node;
 + unsigned long size;
 +
 + size = bo-mem.mm_node-size;
 + if (bo-mem.mm_node-ml_entry.prev != man-manager.ml_entry) {
 + node = list_entry(bo-mem.mm_node-ml_entry.prev,
 + struct drm_mm_node, ml_entry);
 + if (node-free)
 + size += node-size;
 + }
 + if (bo-mem.mm_node-ml_entry.next != man-manager.ml_entry) {
 + node = list_entry(bo-mem.mm_node-ml_entry.next,
 + struct drm_mm_node, ml_entry);
 + if (node-free)
 + size += node-size;
 + }
 + return size;
 +}
 +
 +static void ttm_manager_evict_first(struct ttm_buffer_object *bo)
 +{
 + struct ttm_mem_type_manager *man = bo-bdev-man[bo-mem.mem_type];
 + unsigned long free_size_bo, free_size_bo_first;
 + struct ttm_buffer_object *bo_first;
 +
 + /* BO is not on lru list, don't add it */
 + if (!list_empty(bo-lru))
 + return;
 + bo_first = list_first_entry(man-lru, struct ttm_buffer_object, lru);
 + free_size_bo = ttm_bo_free_size_if_evicted(bo);
 + free_size_bo_first = ttm_bo_free_size_if_evicted(bo_first);
 + if (free_size_bo  free_size_bo_first) {
 + list_del_init(bo-lru);
 + list_add(bo-lru, man-lru);
 + }
 +}
 +
   

Hmm, Can you explain why we'd ever *not* want to put bo first on the lru 
list?
I mean , bo_first might not even be in the correct range? That would 
also save the size computations.


 +static int ttm_manager_space_range(struct ttm_buffer_object *bo,
 + uint32_t mem_type,
 + struct ttm_mem_reg *mem,
 + unsigned long start, unsigned long end,
 + bool interruptible, bool no_wait)
 +{
 + struct ttm_bo_global *glob = bo-glob;
 + struct drm_mm_node *entry;
 + struct ttm_mem_type_manager *man = bo-bdev-man[mem_type];
 + struct drm_mm *mm = man-manager;
 + unsigned size = end - start;
 + struct ttm_buffer_object *tbo;
 + unsigned wasted;
 + int ret;
 +
 + mem-mm_node = NULL;
 + ret = 

Re: PROBLEM: radeon, kernel = 2.6.32-rc6-git5, any mode switch on MacBookPro2, 2 is delayed by 130 seconds of black screen

2009-12-02 Thread Viktor Malyarchuk
Hi Alex,

I bisected drm-next branch from Dave's git tree
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git .

The result is:

ebbe1cb936dfc96d809ccf4d64a9755f8ba0c0ff is the first bad commit
commit ebbe1cb936dfc96d809ccf4d64a9755f8ba0c0ff
Author: Alex Deucher alexdeuc...@gmail.com
Date:   Fri Oct 16 11:15:25 2009 -0400

drm/radeon/kms/atom: add support for spread spectrum (v2)

Spread spectrum is a periodic disturbance added
to the feedback divider to change the pixel clock
periodically to reduce interference.

Only enabled on LVDS.

v2: add support for r4xx and fix DCE 3

Signed-off-by: Alex Deucher alexdeuc...@gmail.com
Signed-off-by: Dave Airlie airl...@redhat.com

:04 04 4cd7bdabeac245accf789e26e944aeb678fe1f16 
077d0d318aed2f25464f9eeaffa39f33fa652909 M  drivers

Best,
Viktor

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: PROBLEM: radeon, kernel = 2.6.32-rc6-git5, any mode switch on MacBookPro2, 2 is delayed by 130 seconds of black screen

2009-12-02 Thread Viktor Malyarchuk
Revert failed:

git revert ebbe1cb936dfc96d809ccf4d64a9755f8ba0c0ff
warning: too many files (created: 1954 deleted: 653), skipping inexact rename 
detection
Automatic revert failed.  After resolving the conflicts,
mark the corrected paths with 'git add paths' or 'git rm paths' and commit 
the result.

Best,
Viktor

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 25394] New: [Display port] : Massive corruption observed on changing the resolution on Display port

2009-12-02 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=25394

   Summary: [Display port] : Massive corruption observed on changing
the resolution on Display port
   Product: Mesa
   Version: git
  Platform: x86 (IA32)
OS/Version: other
Status: NEW
  Severity: major
  Priority: high
 Component: Drivers/DRI/R600
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: hysv...@gmail.com


Created an attachment (id=31657)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=31657)
screenshot

Details of the X-stack:
--

kernel :git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
drm-radeon-dp branch

mesa - 7.8   

xorg/xserver- 1.6.0   

xf86-video-ati - git://git.freedesktop.org/git/xorg/driver/xf86-video-ati
displayport branch

ASIC-RV730 Pro 


Steps to Reproduce:
==

1) Below is the output of xrandr -q

Screen 0: minimum 320 x 200, current 1920 x 1200, maximum 1920 x 1920
HDMI-0 disconnected (normal left inverted right x axis y axis)
DisplayPort-0 connected 1920x1200+0+0 (normal left inverted right x axis y
axis) 519mm x 320mm
   1920x1200  60.0*+
   1600x1200  60.0  
   1280x1024  75.0 60.0  
   1152x864   75.0  
   1024x768   75.0 60.0  
   800x60075.0 60.3  
   640x48075.0 59.9  
   720x40070.1  
DVI-0 disconnected (normal left inverted right x axis y axis)


2) Now change the resolution to 800x600 with

xrandr -output DisplayPort-0 --mode 800x600

Observed Behaviour :
=

Massive Desktop corruption observed.(Screenshot attached)


Display Port : Manufacturer: Dell Model:a02b


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 25394] [Display port] : Massive corruption observed on changing the resolution on Display port

2009-12-02 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=25394





--- Comment #1 from samit vats hysv...@gmail.com  2009-12-02 06:20:37 PST ---
Created an attachment (id=31658)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=31658)
xorg.conf


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 25394] [Display port] : Massive corruption observed on changing the resolution on Display port

2009-12-02 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=25394





--- Comment #2 from samit vats hysv...@gmail.com  2009-12-02 06:21:10 PST ---
Created an attachment (id=31659)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=31659)
Xorg.log


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 25394] [Display port] : Massive corruption observed on changing the resolution on Display port

2009-12-02 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=25394





--- Comment #3 from samit vats hysv...@gmail.com  2009-12-02 06:21:45 PST ---
Created an attachment (id=31660)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=31660)
lspci


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 25394] [Display port] : Massive corruption observed on changing the resolution on Display port

2009-12-02 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=25394





--- Comment #4 from samit vats hysv...@gmail.com  2009-12-02 06:22:05 PST ---
Created an attachment (id=31661)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=31661)
glxinfo


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 25383] DRM: R600 packet issues and IRQs disabled?

2009-12-02 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=25383





--- Comment #2 from Darksurf piroisl...@yahoo.com  2009-12-02 07:50:28 PST ---
I've already got mesa 7.6 .  So do I need 7.7 ?


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 25394] [Display port] : Massive corruption observed on changing the resolution on Display port

2009-12-02 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=25394


Alex Deucher ag...@yahoo.com changed:

   What|Removed |Added

  Attachment #31659|application/octet-stream|text/plain
  mime type||
  Attachment #31659|0   |1
   is patch||




-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH] drm: Add compatibility #ifdefs for *BSD

2009-12-02 Thread Kristian Høgsberg
This let's use use the linux drm headers as the canonical source for
libdrm on all platforms.

Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---

This is the patch to sync the linux kernel headers with what's in
libdrm now.  With this patch upstream, we can copy headers from the
kernel into the libdrm repo unchanged.

 include/drm/drm.h|   29 +++--
 include/drm/drm_mode.h   |3 ---
 include/drm/i915_drm.h   |4 ++--
 include/drm/mga_drm.h|2 +-
 include/drm/radeon_drm.h |2 +-
 include/drm/via_drm.h|2 +-
 6 files changed, 24 insertions(+), 18 deletions(-)

diff --git a/include/drm/drm.h b/include/drm/drm.h
index 7cb50bd..838bce9 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -36,17 +36,27 @@
 #ifndef _DRM_H_
 #define _DRM_H_
 
+#if defined(__linux__)
+
 #include linux/types.h
-#include asm/ioctl.h /* For _IO* macros */
-#define DRM_IOCTL_NR(n)_IOC_NR(n)
-#define DRM_IOC_VOID   _IOC_NONE
-#define DRM_IOC_READ   _IOC_READ
-#define DRM_IOC_WRITE  _IOC_WRITE
-#define DRM_IOC_READWRITE  _IOC_READ|_IOC_WRITE
-#define DRM_IOC(dir, group, nr, size) _IOC(dir, group, nr, size)
+#include asm/ioctl.h
+typedef unsigned int drm_handle_t;
+
+#else /* One of the BSDs */
 
-#define DRM_MAJOR   226
-#define DRM_MAX_MINOR   15
+#include sys/ioccom.h
+#include sys/types.h
+typedef int8_t   __s8;
+typedef uint8_t  __u8;
+typedef int16_t  __s16;
+typedef uint16_t __u16;
+typedef int32_t  __s32;
+typedef uint32_t __u32;
+typedef int64_t  __s64;
+typedef uint64_t __u64;
+typedef unsigned long drm_handle_t;
+
+#endif
 
 #define DRM_NAME   drm /** Name in kernel, /dev, and /proc */
 #define DRM_MIN_ORDER  5 /** At least 2^5 bytes = 32 bytes */
@@ -59,7 +69,6 @@
 #define _DRM_LOCK_IS_CONT(lock)   ((lock)  _DRM_LOCK_CONT)
 #define _DRM_LOCKING_CONTEXT(lock) ((lock)  ~(_DRM_LOCK_HELD|_DRM_LOCK_CONT))
 
-typedef unsigned int drm_handle_t;
 typedef unsigned int drm_context_t;
 typedef unsigned int drm_drawable_t;
 typedef unsigned int drm_magic_t;
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 1f90841..852505e 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -27,9 +27,6 @@
 #ifndef _DRM_MODE_H
 #define _DRM_MODE_H
 
-#include linux/kernel.h
-#include linux/types.h
-
 #define DRM_DISPLAY_INFO_LEN   32
 #define DRM_CONNECTOR_NAME_LEN 32
 #define DRM_DISPLAY_MODE_LEN   32
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 7e0cb1d..a04c3ab 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -27,11 +27,11 @@
 #ifndef _I915_DRM_H_
 #define _I915_DRM_H_
 
+#include drm.h
+
 /* Please note that modifications to all structs defined here are
  * subject to backwards-compatibility constraints.
  */
-#include linux/types.h
-#include drm.h
 
 /* Each region is a minimum of 16k, and there are at most 255 of them.
  */
diff --git a/include/drm/mga_drm.h b/include/drm/mga_drm.h
index 325fd6f..3ffbc47 100644
--- a/include/drm/mga_drm.h
+++ b/include/drm/mga_drm.h
@@ -35,7 +35,7 @@
 #ifndef __MGA_DRM_H__
 #define __MGA_DRM_H__
 
-#include linux/types.h
+#include drm.h
 
 /* WARNING: If you change any of these defines, make sure to change the
  * defines in the Xserver file (mga_sarea.h)
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 3b9932a..39537f3 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -33,7 +33,7 @@
 #ifndef __RADEON_DRM_H__
 #define __RADEON_DRM_H__
 
-#include linux/types.h
+#include drm.h
 
 /* WARNING: If you change any of these defines, make sure to change the
  * defines in the X server file (radeon_sarea.h)
diff --git a/include/drm/via_drm.h b/include/drm/via_drm.h
index 170786e..fd11a5b 100644
--- a/include/drm/via_drm.h
+++ b/include/drm/via_drm.h
@@ -24,7 +24,7 @@
 #ifndef _VIA_DRM_H_
 #define _VIA_DRM_H_
 
-#include linux/types.h
+#include drm.h
 
 /* WARNING: These defines must be the same as what the Xserver uses.
  * if you change them, you must change the defines in the Xserver.
-- 
1.6.5.rc2


--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [PATCH] drm: Add compatibility #ifdefs for *BSD

2009-12-02 Thread Robert Noland
On Wed, 2009-12-02 at 11:36 -0500, Kristian Høgsberg wrote:
 This let's use use the linux drm headers as the canonical source for
 libdrm on all platforms.
 
 Signed-off-by: Kristian Høgsberg k...@bitplanet.net
 ---
 
 This is the patch to sync the linux kernel headers with what's in
 libdrm now.  With this patch upstream, we can copy headers from the
 kernel into the libdrm repo unchanged.
 
  include/drm/drm.h|   29 +++--
  include/drm/drm_mode.h   |3 ---
  include/drm/i915_drm.h   |4 ++--
  include/drm/mga_drm.h|2 +-
  include/drm/radeon_drm.h |2 +-
  include/drm/via_drm.h|2 +-
  6 files changed, 24 insertions(+), 18 deletions(-)
 
 diff --git a/include/drm/drm.h b/include/drm/drm.h
 index 7cb50bd..838bce9 100644
 --- a/include/drm/drm.h
 +++ b/include/drm/drm.h
 @@ -36,17 +36,27 @@
  #ifndef _DRM_H_
  #define _DRM_H_
  
 +#if defined(__linux__)
 +
  #include linux/types.h
 -#include asm/ioctl.h   /* For _IO* macros */
 -#define DRM_IOCTL_NR(n)  _IOC_NR(n)
 -#define DRM_IOC_VOID _IOC_NONE
 -#define DRM_IOC_READ _IOC_READ
 -#define DRM_IOC_WRITE_IOC_WRITE
 -#define DRM_IOC_READWRITE_IOC_READ|_IOC_WRITE
 -#define DRM_IOC(dir, group, nr, size) _IOC(dir, group, nr, size)
 +#include asm/ioctl.h
 +typedef unsigned int drm_handle_t;
 +
 +#else /* One of the BSDs */
  
 -#define DRM_MAJOR   226
 -#define DRM_MAX_MINOR   15

This does not look like the latest version with the DRM_MAX_MINOR
shuffle.  Are you planning to handle that with a separate patch?

robert.

 +#include sys/ioccom.h
 +#include sys/types.h
 +typedef int8_t   __s8;
 +typedef uint8_t  __u8;
 +typedef int16_t  __s16;
 +typedef uint16_t __u16;
 +typedef int32_t  __s32;
 +typedef uint32_t __u32;
 +typedef int64_t  __s64;
 +typedef uint64_t __u64;
 +typedef unsigned long drm_handle_t;
 +
 +#endif
  
  #define DRM_NAME drm /** Name in kernel, /dev, and /proc */
  #define DRM_MIN_ORDER5 /** At least 2^5 bytes = 32 bytes */
 @@ -59,7 +69,6 @@
  #define _DRM_LOCK_IS_CONT(lock) ((lock)  _DRM_LOCK_CONT)
  #define _DRM_LOCKING_CONTEXT(lock) ((lock)  
 ~(_DRM_LOCK_HELD|_DRM_LOCK_CONT))
  
 -typedef unsigned int drm_handle_t;
  typedef unsigned int drm_context_t;
  typedef unsigned int drm_drawable_t;
  typedef unsigned int drm_magic_t;
 diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
 index 1f90841..852505e 100644
 --- a/include/drm/drm_mode.h
 +++ b/include/drm/drm_mode.h
 @@ -27,9 +27,6 @@
  #ifndef _DRM_MODE_H
  #define _DRM_MODE_H
  
 -#include linux/kernel.h
 -#include linux/types.h
 -
  #define DRM_DISPLAY_INFO_LEN 32
  #define DRM_CONNECTOR_NAME_LEN   32
  #define DRM_DISPLAY_MODE_LEN 32
 diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
 index 7e0cb1d..a04c3ab 100644
 --- a/include/drm/i915_drm.h
 +++ b/include/drm/i915_drm.h
 @@ -27,11 +27,11 @@
  #ifndef _I915_DRM_H_
  #define _I915_DRM_H_
  
 +#include drm.h
 +
  /* Please note that modifications to all structs defined here are
   * subject to backwards-compatibility constraints.
   */
 -#include linux/types.h
 -#include drm.h
  
  /* Each region is a minimum of 16k, and there are at most 255 of them.
   */
 diff --git a/include/drm/mga_drm.h b/include/drm/mga_drm.h
 index 325fd6f..3ffbc47 100644
 --- a/include/drm/mga_drm.h
 +++ b/include/drm/mga_drm.h
 @@ -35,7 +35,7 @@
  #ifndef __MGA_DRM_H__
  #define __MGA_DRM_H__
  
 -#include linux/types.h
 +#include drm.h
  
  /* WARNING: If you change any of these defines, make sure to change the
   * defines in the Xserver file (mga_sarea.h)
 diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
 index 3b9932a..39537f3 100644
 --- a/include/drm/radeon_drm.h
 +++ b/include/drm/radeon_drm.h
 @@ -33,7 +33,7 @@
  #ifndef __RADEON_DRM_H__
  #define __RADEON_DRM_H__
  
 -#include linux/types.h
 +#include drm.h
  
  /* WARNING: If you change any of these defines, make sure to change the
   * defines in the X server file (radeon_sarea.h)
 diff --git a/include/drm/via_drm.h b/include/drm/via_drm.h
 index 170786e..fd11a5b 100644
 --- a/include/drm/via_drm.h
 +++ b/include/drm/via_drm.h
 @@ -24,7 +24,7 @@
  #ifndef _VIA_DRM_H_
  #define _VIA_DRM_H_
  
 -#include linux/types.h
 +#include drm.h
  
  /* WARNING: These defines must be the same as what the Xserver uses.
   * if you change them, you must change the defines in the Xserver.
 -- 
 1.6.5.rc2
 
 
 --
 Join us December 9, 2009 for the Red Hat Virtual Experience,
 a free event focused on virtualization and cloud computing. 
 Attend in-depth sessions from your desk. Your couch. Anywhere.
 http://p.sf.net/sfu/redhat-sfdev2dev
 --
 ___
 Dri-devel mailing list
 Dri-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/dri-devel
-- 
Robert Noland rnol...@2hip.net
2Hip Networks



[PATCH] drm/radeon/kms: handle vblanks properly with dpms on avivo chips

2009-12-02 Thread Alex Deucher
From 954230c97fac8fbfc2212024ff9f6c057bf48714 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Wed, 2 Dec 2009 11:46:52 -0500
Subject: [PATCH] drm/radeon/kms: handle vblanks properly with dpms on
avivo chips

Copied from pre-avivo code.

Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
 drivers/gpu/drm/radeon/atombios_crtc.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index 7c489d1..89ac438 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -241,6 +241,7 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode)
 {
struct drm_device *dev = crtc-dev;
struct radeon_device *rdev = dev-dev_private;
+   struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);

switch (mode) {
case DRM_MODE_DPMS_ON:
@@ -248,20 +249,19 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode)
if (ASIC_IS_DCE3(rdev))
atombios_enable_crtc_memreq(crtc, 1);
atombios_blank_crtc(crtc, 0);
+   drm_vblank_post_modeset(dev, radeon_crtc-crtc_id);
+   radeon_crtc_load_lut(crtc);
break;
case DRM_MODE_DPMS_STANDBY:
case DRM_MODE_DPMS_SUSPEND:
case DRM_MODE_DPMS_OFF:
+   drm_vblank_pre_modeset(dev, radeon_crtc-crtc_id);
atombios_blank_crtc(crtc, 1);
if (ASIC_IS_DCE3(rdev))
atombios_enable_crtc_memreq(crtc, 0);
atombios_enable_crtc(crtc, 0);
break;
}
-
-   if (mode != DRM_MODE_DPMS_OFF) {
-   radeon_crtc_load_lut(crtc);
-   }
 }

 static void
-- 
1.5.6.3
From 954230c97fac8fbfc2212024ff9f6c057bf48714 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Wed, 2 Dec 2009 11:46:52 -0500
Subject: [PATCH] drm/radeon/kms: handle vblanks properly with dpms on avivo chips

Copied from pre-avivo code.

Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
 drivers/gpu/drm/radeon/atombios_crtc.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
index 7c489d1..89ac438 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -241,6 +241,7 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode)
 {
 	struct drm_device *dev = crtc-dev;
 	struct radeon_device *rdev = dev-dev_private;
+	struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
 
 	switch (mode) {
 	case DRM_MODE_DPMS_ON:
@@ -248,20 +249,19 @@ void atombios_crtc_dpms(struct drm_crtc *crtc, int mode)
 		if (ASIC_IS_DCE3(rdev))
 			atombios_enable_crtc_memreq(crtc, 1);
 		atombios_blank_crtc(crtc, 0);
+		drm_vblank_post_modeset(dev, radeon_crtc-crtc_id);
+		radeon_crtc_load_lut(crtc);
 		break;
 	case DRM_MODE_DPMS_STANDBY:
 	case DRM_MODE_DPMS_SUSPEND:
 	case DRM_MODE_DPMS_OFF:
+		drm_vblank_pre_modeset(dev, radeon_crtc-crtc_id);
 		atombios_blank_crtc(crtc, 1);
 		if (ASIC_IS_DCE3(rdev))
 			atombios_enable_crtc_memreq(crtc, 0);
 		atombios_enable_crtc(crtc, 0);
 		break;
 	}
-
-	if (mode != DRM_MODE_DPMS_OFF) {
-		radeon_crtc_load_lut(crtc);
-	}
 }
 
 static void
-- 
1.5.6.3

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [PATCH] drm: Add compatibility #ifdefs for *BSD

2009-12-02 Thread Kristian Høgsberg
2009/12/2 Robert Noland rnol...@2hip.net:
 On Wed, 2009-12-02 at 11:36 -0500, Kristian Høgsberg wrote:
 This let's use use the linux drm headers as the canonical source for
 libdrm on all platforms.

 Signed-off-by: Kristian Høgsberg k...@bitplanet.net
 ---

 This is the patch to sync the linux kernel headers with what's in
 libdrm now.  With this patch upstream, we can copy headers from the
 kernel into the libdrm repo unchanged.
...
 This does not look like the latest version with the DRM_MAX_MINOR
 shuffle.  Are you planning to handle that with a separate patch?

DRM_MAX_MINOR is only used in userspace, but this patch does break
linux kernel compile. I need to move a couple of #defines deteled from
drm.h to drmP.h.  New patch on the way.

thanks,
Kristian

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH] drm: Add compatibility #ifdefs for *BSD

2009-12-02 Thread Kristian Høgsberg
This let's use use the linux drm headers as the canonical source for
libdrm on all platforms.

Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---

Second try, now with the #defines added to drmP.h that was missing in
the first patch.

 include/drm/drm.h|   29 +++--
 include/drm/drmP.h   |3 +++
 include/drm/drm_mode.h   |3 ---
 include/drm/i915_drm.h   |4 ++--
 include/drm/mga_drm.h|2 +-
 include/drm/radeon_drm.h |2 +-
 include/drm/via_drm.h|2 +-
 7 files changed, 27 insertions(+), 18 deletions(-)

diff --git a/include/drm/drm.h b/include/drm/drm.h
index 7cb50bd..838bce9 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -36,17 +36,27 @@
 #ifndef _DRM_H_
 #define _DRM_H_
 
+#if defined(__linux__)
+
 #include linux/types.h
-#include asm/ioctl.h /* For _IO* macros */
-#define DRM_IOCTL_NR(n)_IOC_NR(n)
-#define DRM_IOC_VOID   _IOC_NONE
-#define DRM_IOC_READ   _IOC_READ
-#define DRM_IOC_WRITE  _IOC_WRITE
-#define DRM_IOC_READWRITE  _IOC_READ|_IOC_WRITE
-#define DRM_IOC(dir, group, nr, size) _IOC(dir, group, nr, size)
+#include asm/ioctl.h
+typedef unsigned int drm_handle_t;
+
+#else /* One of the BSDs */
 
-#define DRM_MAJOR   226
-#define DRM_MAX_MINOR   15
+#include sys/ioccom.h
+#include sys/types.h
+typedef int8_t   __s8;
+typedef uint8_t  __u8;
+typedef int16_t  __s16;
+typedef uint16_t __u16;
+typedef int32_t  __s32;
+typedef uint32_t __u32;
+typedef int64_t  __s64;
+typedef uint64_t __u64;
+typedef unsigned long drm_handle_t;
+
+#endif
 
 #define DRM_NAME   drm /** Name in kernel, /dev, and /proc */
 #define DRM_MIN_ORDER  5 /** At least 2^5 bytes = 32 bytes */
@@ -59,7 +69,6 @@
 #define _DRM_LOCK_IS_CONT(lock)   ((lock)  _DRM_LOCK_CONT)
 #define _DRM_LOCKING_CONTEXT(lock) ((lock)  ~(_DRM_LOCK_HELD|_DRM_LOCK_CONT))
 
-typedef unsigned int drm_handle_t;
 typedef unsigned int drm_context_t;
 typedef unsigned int drm_drawable_t;
 typedef unsigned int drm_magic_t;
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c8e64bb..5a9582b 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -322,6 +322,9 @@ typedef int drm_ioctl_t(struct drm_device *dev, void *data,
 typedef int drm_ioctl_compat_t(struct file *filp, unsigned int cmd,
   unsigned long arg);
 
+#define DRM_IOCTL_NR(n)_IOC_NR(n)
+#define DRM_MAJOR   226
+
 #define DRM_AUTH   0x1
 #defineDRM_MASTER  0x2
 #define DRM_ROOT_ONLY  0x4
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 1f90841..852505e 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -27,9 +27,6 @@
 #ifndef _DRM_MODE_H
 #define _DRM_MODE_H
 
-#include linux/kernel.h
-#include linux/types.h
-
 #define DRM_DISPLAY_INFO_LEN   32
 #define DRM_CONNECTOR_NAME_LEN 32
 #define DRM_DISPLAY_MODE_LEN   32
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 7e0cb1d..a04c3ab 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -27,11 +27,11 @@
 #ifndef _I915_DRM_H_
 #define _I915_DRM_H_
 
+#include drm.h
+
 /* Please note that modifications to all structs defined here are
  * subject to backwards-compatibility constraints.
  */
-#include linux/types.h
-#include drm.h
 
 /* Each region is a minimum of 16k, and there are at most 255 of them.
  */
diff --git a/include/drm/mga_drm.h b/include/drm/mga_drm.h
index 325fd6f..3ffbc47 100644
--- a/include/drm/mga_drm.h
+++ b/include/drm/mga_drm.h
@@ -35,7 +35,7 @@
 #ifndef __MGA_DRM_H__
 #define __MGA_DRM_H__
 
-#include linux/types.h
+#include drm.h
 
 /* WARNING: If you change any of these defines, make sure to change the
  * defines in the Xserver file (mga_sarea.h)
diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 3b9932a..39537f3 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -33,7 +33,7 @@
 #ifndef __RADEON_DRM_H__
 #define __RADEON_DRM_H__
 
-#include linux/types.h
+#include drm.h
 
 /* WARNING: If you change any of these defines, make sure to change the
  * defines in the X server file (radeon_sarea.h)
diff --git a/include/drm/via_drm.h b/include/drm/via_drm.h
index 170786e..fd11a5b 100644
--- a/include/drm/via_drm.h
+++ b/include/drm/via_drm.h
@@ -24,7 +24,7 @@
 #ifndef _VIA_DRM_H_
 #define _VIA_DRM_H_
 
-#include linux/types.h
+#include drm.h
 
 /* WARNING: These defines must be the same as what the Xserver uses.
  * if you change them, you must change the defines in the Xserver.
-- 
1.6.5.rc2


--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net

[Bug 25398] New: DRI not working with HD3870

2009-12-02 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=25398

   Summary: DRI not working with HD3870
   Product: DRI
   Version: unspecified
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: freedesk...@shakaweb.org


I've got a Radeon HD3870 which I'm not able to use with DRI on my Debian
system. First I didn't get anything but a black screen when starting X, until I
changed Driver to radeonhd.

With Debian's radeonhd without DIR I get a working X but that's the only
configuration that works.

Not working configurations include:

- Explicitly enabling DRI/EXA in xorg.conf

- Using Debian's radeon driver (since it has DRI enabled by default)

- Using current git version of xf86-video-ati

- Using current git version or official version 1.3.0 release of radeonhd
driver which also brings default DRI


With all those setups I only get a black screen - sometimes with some fragments
of what should show up - and a very juddering mouse cursor. I can't do nothing
but reset the computer to get out of there. Using ssh I was able to figure out
that Xorg uses 100% of the CPU.

As you can see in the log file attached, radeonhd gives continuous (WW)
RADEONHD(0): DRMCPIdle: DRM CP IDLE returned BUSY! messages.

Any ideas how to debug?


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 25398] DRI not working with HD3870

2009-12-02 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=25398





--- Comment #1 from Christopher Schramm freedesk...@shakaweb.org  2009-12-02 
09:54:48 PST ---
Created an attachment (id=31666)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=31666)
Xorg log with radeonhd from current git


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH 0/2] Core drm changes for vmwgfx driver

2009-12-02 Thread Jakob Bornecrantz
Hi everybody

Here is a small patch series that adds functionality needed by the 
vmwgfx driver to core drm. The first patch gives the driver
hooks for the drm_[set|drop]_master ioctls. The second adds the
framebuffer dirty ioctl.

Checkpatch gives 1 error and 2 warnings for the second patch but
in those places I have done exactly what the code is doing around it.

Cheers Jakob.

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH 1/2] drm: Add support for drm master_[set|drop] callbacks.

2009-12-02 Thread Jakob Bornecrantz
From: Thomas Hellstrom thellst...@vmware.com

Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
 drivers/gpu/drm/drm_fops.c |   14 ++
 drivers/gpu/drm/drm_stub.c |   11 +++
 include/drm/drmP.h |9 +
 3 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 251bc0e..d632f3c 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -297,6 +297,18 @@ static int drm_open_helper(struct inode *inode, struct 
file *filp,
goto out_free;
}
}
+   mutex_lock(dev-struct_mutex);
+   if (dev-driver-master_set) {
+   ret = dev-driver-master_set(dev, priv, true);
+   if (ret) {
+   /* drop both references if this fails */
+   drm_master_put(priv-minor-master);
+   drm_master_put(priv-master);
+   mutex_unlock(dev-struct_mutex);
+   goto out_free;
+   }
+   }
+   mutex_unlock(dev-struct_mutex);
} else {
/* get a reference to the master */
priv-master = drm_master_get(priv-minor-master);
@@ -504,6 +516,8 @@ int drm_release(struct inode *inode, struct file *filp)
 
if (file_priv-minor-master == file_priv-master) {
/* drop the reference held my the minor */
+   if (dev-driver-master_drop)
+   dev-driver-master_drop(dev, file_priv, true);
drm_master_put(file_priv-minor-master);
}
}
diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
index 55bb8a8..066b0aa 100644
--- a/drivers/gpu/drm/drm_stub.c
+++ b/drivers/gpu/drm/drm_stub.c
@@ -174,6 +174,8 @@ void drm_master_put(struct drm_master **master)
 int drm_setmaster_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
 {
+   int ret = 0;
+
if (file_priv-is_master)
return 0;
 
@@ -188,6 +190,13 @@ int drm_setmaster_ioctl(struct drm_device *dev, void *data,
mutex_lock(dev-struct_mutex);
file_priv-minor-master = drm_master_get(file_priv-master);
file_priv-is_master = 1;
+   if (dev-driver-master_set) {
+   ret = dev-driver-master_set(dev, file_priv, false);
+   if (unlikely(ret != 0)) {
+   file_priv-is_master = 0;
+   drm_master_put(file_priv-minor-master);
+   }
+   }
mutex_unlock(dev-struct_mutex);
}
 
@@ -204,6 +213,8 @@ int drm_dropmaster_ioctl(struct drm_device *dev, void *data,
return -EINVAL;
 
mutex_lock(dev-struct_mutex);
+   if (dev-driver-master_drop)
+   dev-driver-master_drop(dev, file_priv, false);
drm_master_put(file_priv-minor-master);
file_priv-is_master = 0;
mutex_unlock(dev-struct_mutex);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c8e64bb..bf7df3f 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -795,6 +795,15 @@ struct drm_driver {
/* Master routines */
int (*master_create)(struct drm_device *dev, struct drm_master *master);
void (*master_destroy)(struct drm_device *dev, struct drm_master 
*master);
+   /**
+* master_set is called whenever the minor master is set.
+* master_drop is called whenever the minor master is dropped.
+*/
+
+   int (*master_set)(struct drm_device *dev, struct drm_file *file_priv,
+ bool from_open);
+   void (*master_drop)(struct drm_device *dev, struct drm_file *file_priv,
+   bool from_release);
 
int (*proc_init)(struct drm_minor *minor);
void (*proc_cleanup)(struct drm_minor *minor);
-- 
1.6.0.4


--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH 2/2] drm: Add dirty ioctl and property

2009-12-02 Thread Jakob Bornecrantz
This commit adds a ioctl and property to allow userspace
to notify the kernel that a framebuffer has changed. Instead
of snooping the command stream this allows finer grained
tracking of which areas have changed.

The primary user for this functionality is virtual hardware
like the vmware svga device, but also Xen hardware likes to
be notify. There is also real hardware like DisplayLink and
DisplayPort that might take advantage of this ioctl.

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
---
 drivers/gpu/drm/drm_crtc.c |  105 
 drivers/gpu/drm/drm_drv.c  |1 +
 include/drm/drm.h  |1 +
 include/drm/drm_crtc.h |   19 
 include/drm/drm_mode.h |   44 ++
 5 files changed, 170 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5cae0b3..4beb439 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -125,6 +125,16 @@ static struct drm_prop_enum_list 
drm_tv_subconnector_enum_list[] =
 DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
 drm_tv_subconnector_enum_list)
 
+static struct drm_prop_enum_list drm_dirty_info_enum_list[] =
+{
+   { DRM_MODE_DIRTY_OFF,  Off  },
+   { DRM_MODE_DIRTY_ON,   On   },
+   { DRM_MODE_DIRTY_ANNOTATE, Annotate },
+};
+
+DRM_ENUM_NAME_FN(drm_get_dirty_info_name,
+drm_dirty_info_enum_list)
+
 struct drm_conn_prop_enum_list {
int type;
char *name;
@@ -802,6 +812,36 @@ int drm_mode_create_dithering_property(struct drm_device 
*dev)
 EXPORT_SYMBOL(drm_mode_create_dithering_property);
 
 /**
+ * drm_mode_create_dirty_property - create dirty property
+ * @dev: DRM device
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * connectors.
+ */
+int drm_mode_create_dirty_info_property(struct drm_device *dev)
+{
+   struct drm_property *dirty_info;
+   int i;
+
+   if (dev-mode_config.dirty_info_property)
+   return 0;
+
+   dirty_info =
+   drm_property_create(dev, DRM_MODE_PROP_ENUM |
+   DRM_MODE_PROP_IMMUTABLE,
+   dirty,
+   ARRAY_SIZE(drm_dirty_info_enum_list));
+   for (i = 0; i  ARRAY_SIZE(drm_dirty_info_enum_list); i++)
+   drm_property_add_enum(dirty_info, i,
+ drm_dirty_info_enum_list[i].type,
+ drm_dirty_info_enum_list[i].name);
+   dev-mode_config.dirty_info_property = dirty_info;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_dirty_info_property);
+
+/**
  * drm_mode_config_init - initialize DRM mode_configuration structure
  * @dev: DRM device
  *
@@ -1753,6 +1793,71 @@ out:
return ret;
 }
 
+int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
+  void *data, struct drm_file *file_priv)
+{
+   struct drm_clip_rect __user *clips_ptr;
+   struct drm_clip_rect *clips = NULL;
+   struct drm_mode_fb_dirty_cmd *r = data;
+   struct drm_mode_object *obj;
+   struct drm_framebuffer *fb;
+   unsigned flags;
+   int num_clips;
+   int ret = 0;
+
+   mutex_lock(dev-mode_config.mutex);
+   obj = drm_mode_object_find(dev, r-fb_id, DRM_MODE_OBJECT_FB);
+   if (!obj) {
+   DRM_ERROR(invalid framebuffer id\n);
+   ret = -EINVAL;
+   goto out_err1;
+   }
+   fb = obj_to_fb(obj);
+
+   num_clips = r-num_clips;
+   clips_ptr = (struct drm_clip_rect *)(unsigned long)r-clips_ptr;
+
+   if (!num_clips != !clips_ptr) {
+   ret = -EINVAL;
+   goto out_err1;
+   }
+
+   flags = DRM_MODE_FB_DIRTY_FLAGS  r-flags;
+
+   /* If userspace annotates copy, clips must come in pairs */
+   if (flags  DRM_MODE_FB_DIRTY_ANNOTATE_COPY  (num_clips % 2)) {
+   ret = -EINVAL;
+   goto out_err1;
+   }
+
+   if (num_clips  clips_ptr) {
+   clips = kzalloc(num_clips * sizeof(*clips), GFP_KERNEL);
+   if (!clips) {
+   ret = -ENOMEM;
+   goto out_err1;
+   }
+
+   ret = copy_from_user(clips, clips_ptr,
+num_clips * sizeof(*clips));
+   if (ret)
+   goto out_err2;
+   }
+
+   if (fb-funcs-dirty) {
+   ret = fb-funcs-dirty(fb, flags, r-color, clips, num_clips);
+   } else {
+   ret = -ENOSYS;
+   goto out_err2;
+   }
+
+out_err2:
+   kfree(clips);
+out_err1:
+   mutex_unlock(dev-mode_config.mutex);
+   return ret;
+}
+
+
 /**
  * drm_fb_release - remove and free the FBs on this file
  * @filp: file * from the ioctl
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index a75ca63..18fdc21 100644

Re: [PATCH 1/2] drm: Add support for drm master_[set|drop] callbacks.

2009-12-02 Thread Thomas Hellström
Jakob Bornecrantz wrote:
 From: Thomas Hellstrom thellst...@vmware.com

 Signed-off-by: Thomas Hellstrom thellst...@vmware.com
 Signed-off-by: Jakob Bornecrantz ja...@vmware.com
 ---
  drivers/gpu/drm/drm_fops.c |   14 ++
  drivers/gpu/drm/drm_stub.c |   11 +++
  include/drm/drmP.h |9 +
  3 files changed, 34 insertions(+), 0 deletions(-)
   
It might be worthwhile to comment on what these hooks are used for:

The vmwgfx driver has a per master rw lock around TTM, to guarantee 
mutual exclusion when needed.
This is typically when all evictable buffers are evicted due to

1) vt switch
2) master switch
3) suspend / resume.

In the multi-master case, on master switch the new master takes the 
previously active master lock in write mode, and then evicts all 
buffers. Any clients to previous masters will then block on that lock 
when trying to validate a buffer. fbdev also acts as a virtual master w 
r t this.

/Thomas





--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 25193] kwin corruption with 286bf89e5a1fc931dbf523ded861b809859485e2

2009-12-02 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=25193


Aidan Marks ai...@cisco.com changed:

   What|Removed |Added

   Severity|normal  |major




--- Comment #18 from Aidan Marks ai...@cisco.com  2009-12-02 12:26:00 PST ---
(In reply to comment #17)
 
 Its probably a good idea to fix this before 7.7-rc2 is released... 
 

Agreed.  this is a 7.7 release showstopper.  Suggest reverting now, unless
Maciej is close to a fix.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 25193] kwin corruption with 286bf89e5a1fc931dbf523ded861b809859485e2

2009-12-02 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=25193





--- Comment #19 from Aidan Marks ai...@cisco.com  2009-12-02 12:56:28 PST ---
Reverted via e84e9b6eb7727760814ae211c95218bb28a3.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 25193] kwin corruption with 286bf89e5a1fc931dbf523ded861b809859485e2

2009-12-02 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=25193


Rafał Miłecki zaj...@gmail.com changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED




--- Comment #20 from Rafał Miłecki zaj...@gmail.com  2009-12-02 12:57:27 PST 
---
Reverted:
http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_7_branchid=e84e9b6eb7727760814ae211c95218bb28a3


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 25355] sauerbraten segfaults after 63c00c53a3019b801c5eee8a12f7862422f79f10

2009-12-02 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=25355





--- Comment #1 from Maciej Cencora m.cenc...@gmail.com  2009-12-02 14:10:27 
PST ---
Created an attachment (id=31685)
 -- (http://bugs.freedesktop.org/attachment.cgi?id=31685)
proposed patch

Attached patch should fix the problem.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 24150] tv out issues with radeon kms drm-next

2009-12-02 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=24150





--- Comment #11 from Andy Furniss li...@andyfurniss.entadsl.com  2009-12-02 
14:48:43 PST ---
(In reply to comment #9)
 You can use xrandr to
  select the tv standard (NTSC or PAL) however.  e.g.,
  xrandr --output DIN --set tv standard pal
  You may have to double check the property names with kms (xrandr --verbose).
  
 
 xrandr --verbose with kms doesn't list the tv_standard, it does with ums.

This is working now after the recent commit to drm-testing.

I now get pal by default and can switch between pal and ntsc OK.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH] vgaarb: use MIT license

2009-12-02 Thread Tiago Vignatti
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
---
Hi. I'd please ask that other copyright holders put yours s-o-b tag there.
Thanks.

 drivers/gpu/vga/vgaarb.c |   26 +++---
 include/linux/vgaarb.h   |   21 +
 2 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
index 1ac0c93..7553cc3 100644
--- a/drivers/gpu/vga/vgaarb.c
+++ b/drivers/gpu/vga/vgaarb.c
@@ -1,12 +1,32 @@
 /*
- * vgaarb.c
+ * vgaarb.c: Implements the VGA arbitration. For details refer to
+ * Documentation/vgaarbiter.txt
+ *
  *
  * (C) Copyright 2005 Benjamin Herrenschmidt b...@kernel.crashing.org
  * (C) Copyright 2007 Paulo R. Zanoni przan...@gmail.com
  * (C) Copyright 2007, 2009 Tiago Vignatti vigna...@freedesktop.org
  *
- * Implements the VGA arbitration. For details refer to
- * Documentation/vgaarbiter.txt
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS
+ * IN THE SOFTWARE.
+ *
  */
 
 #include linux/module.h
diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h
index 2dfaa29..c9a9759 100644
--- a/include/linux/vgaarb.h
+++ b/include/linux/vgaarb.h
@@ -5,6 +5,27 @@
  * (C) Copyright 2005 Benjamin Herrenschmidt b...@kernel.crashing.org
  * (C) Copyright 2007 Paulo R. Zanoni przan...@gmail.com
  * (C) Copyright 2007, 2009 Tiago Vignatti vigna...@freedesktop.org
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS
+ * IN THE SOFTWARE.
+ *
  */
 
 #ifndef LINUX_VGA_H
-- 
1.6.0.4


--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH] drm/radeon/kms: tighten the pll range when selecting dividers

2009-12-02 Thread Alex Deucher
The attached kms patch is for testing.  Please let me know if it fixes
any flickering or blinking problems or causes any.  The patch uses the
stricter pll_out_min in the bios rather than the less strict limited
currently used.  This limits the available divider selections except
in cases known to need a wider range (some duallink monitors).

Alex
From 9a08f099ae01de8e6e6511dbda556b1584d0fd0e Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Wed, 2 Dec 2009 19:03:52 -0500
Subject: [PATCH] drm/radeon/kms: tighten the pll range when selecting dividers

We use the pll in/out min/max values in the bios to limit our
pll divider selection.  In most cases the values in the bios
for pll_out_min are higher than the default value we were using
(64800) which gives us a more limited range of dividers.  However,
using the bios pll_out_min limit caused a problem on at least one
2560x1600 monitor.  So, use the bios pll_out_min for everything
except modes with clocks over 200 Mhz.  This should provide the
best of both worlds.

Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
 drivers/gpu/drm/radeon/atombios_crtc.c   |6 ++
 drivers/gpu/drm/radeon/radeon_atombios.c |   10 --
 drivers/gpu/drm/radeon/radeon_display.c  |   13 +++--
 drivers/gpu/drm/radeon/radeon_mode.h |1 +
 4 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
index 7a8cd93..c128e13 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -441,6 +441,12 @@ void atombios_crtc_set_pll(struct drm_crtc *crtc, struct drm_display_mode *mode)
 			pll_flags |= RADEON_PLL_PREFER_HIGH_FB_DIV;
 		else
 			pll_flags |= RADEON_PLL_PREFER_LOW_REF_DIV;
+
+		/* some duallink monitors seem to prefer dividers calculated with a wider
+		 * pll range
+		 */
+		if (mode-clock  20)
+			pll_flags |= RADEON_PLL_USE_DEFAULT_OUT_MIN;
 	} else {
 		pll_flags |= RADEON_PLL_LEGACY;
 
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c b/drivers/gpu/drm/radeon/radeon_atombios.c
index 76825ad..a45b251 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -851,16 +851,6 @@ bool radeon_atom_get_clock_info(struct drm_device *dev)
 p1pll-pll_out_min = 64800;
 			else
 p1pll-pll_out_min = 2;
-		} else if (p1pll-pll_out_min  64800) {
-			/* Limiting the pll output range is a good thing generally as
-			 * it limits the number of possible pll combinations for a given
-			 * frequency presumably to the ones that work best on each card.
-			 * However, certain duallink DVI monitors seem to like
-			 * pll combinations that would be limited by this at least on
-			 * pre-DCE 3.0 r6xx hardware.  This might need to be adjusted per
-			 * family.
-			 */
-			p1pll-pll_out_min = 64800;
 		}
 
 		p1pll-pll_in_min =
diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c
index d4f4fb1..89f99c9 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -409,6 +409,8 @@ void radeon_compute_pll(struct radeon_pll *pll,
 {
 	uint32_t min_ref_div = pll-min_ref_div;
 	uint32_t max_ref_div = pll-max_ref_div;
+	uint32_t pll_out_min = pll-pll_out_min;
+	uint32_t pll_out_max = pll-pll_out_max;
 	uint32_t min_fractional_feed_div = 0;
 	uint32_t max_fractional_feed_div = 0;
 	uint32_t best_vco = pll-best_vco;
@@ -444,6 +446,13 @@ void radeon_compute_pll(struct radeon_pll *pll,
 		max_fractional_feed_div = pll-max_frac_feedback_div;
 	}
 
+	if (flags  RADEON_PLL_USE_DEFAULT_OUT_MIN) {
+		if (flags  RADEON_PLL_LEGACY)
+			pll_out_min = 2;
+		else
+			pll_out_min = 64800;
+	}
+
 	for (post_div = pll-min_post_div; post_div = pll-max_post_div; ++post_div) {
 		uint32_t ref_div;
 
@@ -484,10 +493,10 @@ void radeon_compute_pll(struct radeon_pll *pll,
 tmp = (uint64_t)pll-reference_freq * feedback_div;
 vco = radeon_div(tmp, ref_div);
 
-if (vco  pll-pll_out_min) {
+if (vco  pll_out_min) {
 	min_feed_div = feedback_div + 1;
 	continue;
-} else if (vco  pll-pll_out_max) {
+} else if (vco  pll_out_max) {
 	max_feed_div = feedback_div;
 	continue;
 }
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h b/drivers/gpu/drm/radeon/radeon_mode.h
index 174e4a4..24c2016 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -150,6 +150,7 @@ struct radeon_tmds_pll {
 #define RADEON_PLL_PREFER_HIGH_POST_DIV (1  9)
 #define RADEON_PLL_USE_FRAC_FB_DIV  (1  10)
 #define RADEON_PLL_PREFER_CLOSEST_LOWER (1  11)
+#define RADEON_PLL_USE_DEFAULT_OUT_MIN  (1  12)
 
 struct radeon_pll {
 	uint16_t reference_freq;
-- 
1.5.6.3

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 

[PATCH] drm/radeon/kms: pll fixes

2009-12-02 Thread Alex Deucher
This is an alternate patch for testing.  Please let me know if this
patch fixes or causes any blinking or blanking problems.  It limits
the pll_out_min limit to the limit in the bios and enables fractional
feedback dividers on all hardware that supports it.

Alex
From 09e41073d46cc9f3e69444b1ee12e4c5dee3f779 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Wed, 2 Dec 2009 19:26:48 -0500
Subject: [PATCH] drm/radeon/kms: pll fixes

Should help fix flickering modes on some systems.
Use the tighter pll_out_min from the bios in addition
to fractional feedback dividers on all cards that support
it.

Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
 drivers/gpu/drm/radeon/atombios_crtc.c   |4 ++--
 drivers/gpu/drm/radeon/radeon_atombios.c |   10 --
 2 files changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c
index 7a8cd93..afc6df7 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -431,11 +431,11 @@ void atombios_crtc_set_pll(struct drm_crtc *crtc, struct drm_display_mode *mode)
 	memset(args, 0, sizeof(args));
 
 	if (ASIC_IS_AVIVO(rdev)) {
+		pll_flags |= RADEON_PLL_USE_FRAC_FB_DIV;
 		if ((rdev-family == CHIP_RS600) ||
 		(rdev-family == CHIP_RS690) ||
 		(rdev-family == CHIP_RS740))
-			pll_flags |= (RADEON_PLL_USE_FRAC_FB_DIV |
-  RADEON_PLL_PREFER_CLOSEST_LOWER);
+			pll_flags |= RADEON_PLL_PREFER_CLOSEST_LOWER;
 
 		if (ASIC_IS_DCE32(rdev)  mode-clock  20)	/* range limits??? */
 			pll_flags |= RADEON_PLL_PREFER_HIGH_FB_DIV;
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c b/drivers/gpu/drm/radeon/radeon_atombios.c
index 76825ad..a45b251 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -851,16 +851,6 @@ bool radeon_atom_get_clock_info(struct drm_device *dev)
 p1pll-pll_out_min = 64800;
 			else
 p1pll-pll_out_min = 2;
-		} else if (p1pll-pll_out_min  64800) {
-			/* Limiting the pll output range is a good thing generally as
-			 * it limits the number of possible pll combinations for a given
-			 * frequency presumably to the ones that work best on each card.
-			 * However, certain duallink DVI monitors seem to like
-			 * pll combinations that would be limited by this at least on
-			 * pre-DCE 3.0 r6xx hardware.  This might need to be adjusted per
-			 * family.
-			 */
-			p1pll-pll_out_min = 64800;
 		}
 
 		p1pll-pll_in_min =
-- 
1.5.6.3

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


drm/*/kms: how to prepare driver for modesetting

2009-12-02 Thread Rafał Miłecki
I need to prepare radeon driver for setting mode and detect disabling
display. I have to disable PM and eventually enable it again after
mode setting is done (only for single head configuration). My problem
is I do not know when modesetting starts and as result can not disable
PM reliably.

I tried to analyze:
int drm_crtc_helper_set_config(struct drm_mode_set *set);

It's quite simple if we consider mode-switching only. First prepare is
called (for encoder and crtc), then after setting mode, commit is
called (for encoder and crtc). That would just mean introducing my PM
stuff in prepare and commit.

But then I've to consider disabling display (xrandr X --off). This
operation calls DRM_MODE_DPMS_OFF for crtc. So in result in radeon's
case atombios_crtc_dpms is called from:
1) drm on disabling display
2) drm on lack of activity
3) radeon on crtc's prepare

That makes my detection (almost?) impossible.

Do you see any way of doing that?

-- 
Rafał

--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel