Re: [PATCH] DRM: fix headers_check warnings

2010-03-01 Thread Randy Dunlap
On Sat, 27 Feb 2010 14:57:36 +0530 Jaswinder Singh Rajput wrote:

> 
> Fixed following headers_check warnings:
>   CHECK   include/drm (14 files)
>  include/drm/drm_mode.h:84: found __[us]{8,16,32,64} type without #include 
> 
>  include/drm/i915_drm.h:119: found __[us]{8,16,32,64} type without #include 
> 
>  include/drm/mga_drm.h:260: found __[us]{8,16,32,64} type without #include 
> 
>  include/drm/radeon_drm.h:758: found __[us]{8,16,32,64} type without #include 
> 
>  include/drm/via_drm.h:117: found __[us]{8,16,32,64} type without #include 
> 
> 
> Signed-off-by: Jaswinder Singh Rajput 
> Cc: Kristian Høgsberg 
> Cc: Arnd Bergmann 
> Cc: Dave Airlie 

Acked-by: Randy Dunlap 

Thanks much.

> ---
>  include/drm/drm_mode.h   |2 ++
>  include/drm/i915_drm.h   |1 +
>  include/drm/mga_drm.h|1 +
>  include/drm/radeon_drm.h |1 +
>  include/drm/via_drm.h|1 +
>  5 files changed, 6 insertions(+), 0 deletions(-)
> 
> diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
> index c5ba163..c5aa66d 100644
> --- a/include/drm/drm_mode.h
> +++ b/include/drm/drm_mode.h
> @@ -27,6 +27,8 @@
>  #ifndef _DRM_MODE_H
>  #define _DRM_MODE_H
>  
> +#include 
> +
>  #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 b64a8d7..5cf7f5b 100644
> --- a/include/drm/i915_drm.h
> +++ b/include/drm/i915_drm.h
> @@ -27,6 +27,7 @@
>  #ifndef _I915_DRM_H_
>  #define _I915_DRM_H_
>  
> +#include 
>  #include "drm.h"
>  
>  /* Please note that modifications to all structs defined here are
> diff --git a/include/drm/mga_drm.h b/include/drm/mga_drm.h
> index 3ffbc47..ae23df9 100644
> --- a/include/drm/mga_drm.h
> +++ b/include/drm/mga_drm.h
> @@ -35,6 +35,7 @@
>  #ifndef __MGA_DRM_H__
>  #define __MGA_DRM_H__
>  
> +#include 
>  #include "drm.h"
>  
>  /* WARNING: If you change any of these defines, make sure to change the
> diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
> index 39537f3..459ff45 100644
> --- a/include/drm/radeon_drm.h
> +++ b/include/drm/radeon_drm.h
> @@ -33,6 +33,7 @@
>  #ifndef __RADEON_DRM_H__
>  #define __RADEON_DRM_H__
>  
> +#include 
>  #include "drm.h"
>  
>  /* WARNING: If you change any of these defines, make sure to change the
> diff --git a/include/drm/via_drm.h b/include/drm/via_drm.h
> index fd11a5b..23880b0 100644
> --- a/include/drm/via_drm.h
> +++ b/include/drm/via_drm.h
> @@ -24,6 +24,7 @@
>  #ifndef _VIA_DRM_H_
>  #define _VIA_DRM_H_
>  
> +#include 
>  #include "drm.h"
>  
>  /* WARNING: These defines must be the same as what the Xserver uses.
> -- 


---
~Randy

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [PATCH] agpgart: Reprobe VGA devices when a new GART device is added

2010-03-01 Thread Ben Hutchings
On Mon, Mar 01, 2010 at 08:19:02AM -0800, Eric Anholt wrote:
> On Mon, 1 Mar 2010 18:33:14 +1000, Dave Airlie  wrote:
> > On Sun, Feb 28, 2010 at 1:30 PM, Ben Hutchings  wrote:
> > > This addresses .
> > >
> > > DRM drivers may fail to probe their devices when the associated AGP
> > > GART does not yet have a driver, so we reprobe unbound VGA devices
> > > when a GART device is added.
> > >
> > > Signed-off-by: Ben Hutchings 
> > > ---
> > > This is intended to address the dependency problem highlighted in the
> > > above bug report.  That specific bug can be fixed by adding a module
> > > dependency from i915 to intel_agp, but in general there is no fixed
> > > relationship betweem DRM and GART drivers.
> > >
> > > There is a narrow race between the check for a current driver binding
> > > and the call to device_reprobe().  This could be closed by adding a
> > > variant on device_attach() and device_reprobe() that is a no-op for
> > > bound devices.
> > >
> > 
> > This isn't useful, generally there is no AGP binding, and most drivers
> > if they can't find an AGP backend will still run fine without it. i.e. 
> > radeon,
> > mga etc.

I see, only the Intel GPU drivers set DRIVER_REQUIRE_AGP.

> > Intel is a special case and I think we've already merged an explicit
> > depend.
> > 
> > Just build agp drivers into the kernel, I'm tempted to make them all
> > non-modular.
> 
> That seems easier.

Easier, yes, but it's a fair amount of bloat for i386 kernels (less so for
x86-64) since there are many different GART drivers.  I was hoping to avoid
that.

Ben.

-- 
Ben Hutchings
Life is like a sewer:
what you get out of it depends on what you put into it.

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 26419] Selection in blender does not work with r600

2010-03-01 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=26419


Dave Airlie  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Comment #1 from Dave Airlie   2010-03-01 20:15:00 
PST ---
fixed pushed on master and mesa_7_7_branches.


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

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH] libdrm_radeon: Optimize reloc writing to do less looping.

2010-03-01 Thread Pauli Nieminen
Bit has table will be first checked from BO if we can quarentee this BO is not
in this cs already. When bo is emited the reference to cs is removed with bit
operations.

To quarentee that all cs ids are unique number of ids is limited to 32. If
application uses more than 32 cs objects extra cs don't get benefits from
bit hash function.

This optimization decreases cs_write_reloc share of torcs profiling from 4.3%
to 2.6%.

V2: 
 * Fix data type for referenced_in_cs to be uint32_t
 * Use gcc builtin_ctz to find the first zero bit.

---
 radeon/radeon_bo_gem.c |1 +
 radeon/radeon_cs_gem.c |  118 +++-
 2 files changed, 88 insertions(+), 31 deletions(-)

diff --git a/radeon/radeon_bo_gem.c b/radeon/radeon_bo_gem.c
index bc8058d..1b33bdb 100644
--- a/radeon/radeon_bo_gem.c
+++ b/radeon/radeon_bo_gem.c
@@ -80,6 +80,7 @@ static struct radeon_bo *bo_open(struct radeon_bo_manager 
*bom,
 bo->base.domains = domains;
 bo->base.flags = flags;
 bo->base.ptr = NULL;
+bo->base.referenced_in_cs = 0;
 bo->map_count = 0;
 if (handle) {
 struct drm_gem_open open_arg;
diff --git a/radeon/radeon_cs_gem.c b/radeon/radeon_cs_gem.c
index 45a219c..3836c33 100644
--- a/radeon/radeon_cs_gem.c
+++ b/radeon/radeon_cs_gem.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "radeon_cs.h"
@@ -63,11 +64,56 @@ struct cs_gem {
 struct radeon_cs_intbase;
 struct drm_radeon_cscs;
 struct drm_radeon_cs_chunk  chunks[2];
+uint32_tid;
 unsignednrelocs;
 uint32_t*relocs;
 struct radeon_bo_int**relocs_bo;
 };
 
+static pthread_mutex_t id_mutex = PTHREAD_MUTEX_INITIALIZER;
+static uint32_t cs_id_source = 0;
+
+/**
+ * result is undefined if called with ~0
+ */
+static uint32_t get_first_zero(const uint32_t n)
+{
+/* __builtin_ctz returns number of trailing zeros. */
+return 1 << __builtin_ctz(~n);
+}
+
+/**
+ * Returns a free id for cs.
+ * If there is no free id we return zero
+ **/
+static uint32_t generate_id(void)
+{
+uint32_t r = 0;
+pthread_mutex_lock( &id_mutex );
+/* check for free ids */
+if (cs_id_source != ~r) {
+/* find first zero bit */
+r = get_first_zero(cs_id_source);
+
+/* set id as reserved */
+cs_id_source |= r;
+}
+pthread_mutex_unlock( &id_mutex );
+return r;
+}
+
+/**
+ * Free the id for later reuse
+ **/
+static void free_id(uint32_t id)
+{
+pthread_mutex_lock( &id_mutex );
+
+cs_id_source &= ~id;
+
+pthread_mutex_unlock( &id_mutex );
+}
+
 static struct radeon_cs_int *cs_gem_create(struct radeon_cs_manager *csm,
uint32_t ndw)
 {
@@ -90,6 +136,7 @@ static struct radeon_cs_int *cs_gem_create(struct 
radeon_cs_manager *csm,
 }
 csg->base.relocs_total_size = 0;
 csg->base.crelocs = 0;
+csg->id = generate_id();
 csg->nrelocs = 4096 / (4 * 4) ;
 csg->relocs_bo = (struct radeon_bo_int**)calloc(1,
 csg->nrelocs*sizeof(void*));
@@ -141,38 +188,43 @@ static int cs_gem_write_reloc(struct radeon_cs_int *cs,
 if (write_domain == RADEON_GEM_DOMAIN_CPU) {
 return -EINVAL;
 }
-/* check if bo is already referenced */
-for(i = 0; i < cs->crelocs; i++) {
-idx = i * RELOC_SIZE;
-reloc = (struct cs_reloc_gem*)&csg->relocs[idx];
-if (reloc->handle == bo->handle) {
-/* Check domains must be in read or write. As we check already
- * checked that in argument one of the read or write domain was
- * set we only need to check that if previous reloc as the read
- * domain set then the read_domain should also be set for this
- * new relocation.
- */
-/* the DDX expects to read and write from same pixmap */
-if (write_domain && (reloc->read_domain & write_domain)) {
-reloc->read_domain = 0;
-reloc->write_domain = write_domain;
-} else if (read_domain & reloc->write_domain) {
-reloc->read_domain = 0;
-} else {
-if (write_domain != reloc->write_domain)
-return -EINVAL;
-if (read_domain != reloc->read_domain)
-return -EINVAL;
+/* use bit field hash functionto determine
+   if this bo is for sure not in this cs.*/
+if ((boi->referenced_in_cs & csg->id)) {
+/* check if bo is already referenced */
+for(i = cs->crelocs; i != 0;) {
+--i;
+idx = i * RELOC_SIZE;
+reloc = (struct cs_reloc_gem*)&csg->relocs[idx];
+if (reloc->handle == bo->handle) {
+/* Check domains must be in read or write. As we check already
+ * checked that in argument one of the read

[git pull] drm request 2

2010-03-01 Thread Dave Airlie

Same tree as yesterday with a warning + PPC build fix + fix for build on 
x86 after PPC (I think I just validated Ingo).

The following changes since commit 60b341b778cc2929df16c0a504c91621b3c6a4ad:
  Linus Torvalds (1):
Linux 2.6.33

are available in the git repository at:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus

Alex Deucher (34):
  drm/radeon/kms: add radeon i2c algo
  drm/radeon/kms: add support for hw i2c on r1xx-r5xx
  drm/radeon/kms: add workaround for rn50/rv100 servers
  drm/radeon/kms: add support for hardcoded edids in rom (v2)
  drm/radeon/kms: clean up some low-hanging magic numbers
  drm/radeon/kms: rework pll algo selection
  drm/radeon/kms: add pll quirk for toshiba laptop panel
  drm/radeon/kms/atom: clean up spread spectrum code
  drm/radeon/kms/atom: add a helper function to get the radeon connector 
priv
  drm/radeon/kms/r600: reduce gpu cache flushing
  drm/radeon/kms: consolidate crtc count in rdev
  drm/radeon/kms: add functions to get current pcie lanes
  drm/radeon/kms: pull power mode info from bios tables (v3)
  drm/radeon/kms: add a power state type based on power state flags
  drm/radeon/kms: add code to select power state
  drm/radeon/kms: use power states for dynamic reclocking
  drm/radeon/kms: dynclks fixes
  drm/radeon/kms: take the pm mutex when using hw i2c
  drm/radeon/kms: update atombios.h to latest upstream.
  drm/radeon/kms: add initial Evergreen support (Radeon HD 5xxx)
  drm/radeon/kms: fix prescale calculations
  drm/radeon/kms/atom: replace 0/1 in crtc code with 
ATOM_DISABLE/ATOM_ENABLE
  drm/radeon/kms/evergreen: fix multi-head
  drm/radeon/kms/evergreen: adapt to i2c changes
  drm/radeon/r600: fix warnings in CS checker
  drm/radeon/kms: add LVDS pll quirk for Dell Studio 15
  drm/radeon/kms: remove HDP flushes from fence emit (v2)
  drm/radeon/kms: remove unused r600_gart_clear_page
  drm/radeon/rv740: fix backend setup
  drm/radeon: fixes for r6xx/r7xx gfx init
  drm/radeon/kms/evergreen: fix typo in cursor code
  drm/radeon/kms: update new pll algo
  drm/radeon/kms/atom: fix shr/shl ops
  drm/radeon: fix typo in Makefile

Andy Shevchenko (1):
  drivers/gpu/drm/drm_fb_helper.c: don't use private implementation of 
atoi()

Ben Skeggs (17):
  drm/nv50: switch to indirect push buffer controls
  drm/nouveau: remove PUSHBUF_CAL macro
  drm/nv50: make pushbuf dma object cover entire vm
  drm/nouveau: new gem pushbuf interface, bump to 0.0.16
  drm/nouveau: allow retrieval of vbios image from debugfs
  drm/nouveau: rename parsed_dcb_gpio to dcb_gpio_table
  drm/nouveau: merge parsed_dcb and bios_parsed_dcb into dcb_table
  drm/nouveau: merge nvbios and nouveau_bios_info
  drm/nouveau: reorganise bios header, add dcb connector type enums
  drm/nouveau: parse dcb gpio/connector tables after encoders
  drm/nouveau: check for known dcb connector types
  drm/nouveau: construct a connector table for cards that lack a real one
  drm/nouveau: use dcb connector table for creating drm connectors
  drm/nv50: enable hpd on any connector we know the gpio line for
  drm/nouveau: use dcb connector types throughout the driver
  drm/nouveau: support version 0x20 displayport tables
  drm/nouveau: report unknown connector state if lid closed

Chris Wilson (2):
  drm/i915: Replace open-coded eviction in i915_gem_idle()
  drm/i915: Record batch buffer following GPU error

Daniel Vetter (11):
  drm/i915: overlay: nuke readback to flush wc caches
  drm/i915: overlay: drop superflous gpu flushes
  drm/i915: move a gtt flush to the correct place
  drm/i915: blow away userspace mappings before fence change
  drm/i915: reuse i915_gem_object_put_fence_reg for fence stealing code
  drm/i915: fixup active list locking in object_unbind
  drm/i915: extract fence stealing code
  drm/i915: ensure lru ordering of fence_list
  drm/i915: reuse i915_gpu_idle helper
  drm/i915: clean-up i915_gem_flush_gpu_write_domain
  drm/i915: check for multiple write domains in pin_and_relocate

Dave Airlie (21):
  drm/radeon/kms: switch all KMS driver ioctls to unlocked.
  drm/radeon/kms: use udelay for short delays
  drm: switch all GEM/KMS ioctls to unlocked ioctl status.
  drm/kms: fix fb_changed = true else statement
  drm/radeon/kms: check for valid PCI bios and not OF rom
  drm/radeon/kms: set gart pages to invalid on unbind and point to dummy 
page
  drm/radeon/kms: flush HDP cache on GART table updates.
  [rfc] drm/radeon/kms: pm debugging check for vbl.
  Merge remote branch 'korg/drm-core-next' into drm-next-stage
  Merge remote branch 'anholt/drm-intel-next' into drm-next-stage
  fb: for framebuffer handover don't exit the loop early.
  Merge remote b

Re: [PATCH 2/2] drm/ttm: don't write to bo->reserved without holding glob->lru_lock

2010-03-01 Thread Thomas Hellstrom
Maarten Maathuis wrote:
> - The headerfile says you can't write to it without holding the lock.
>   
NAK.

The header-file is incorrect. It should say that the lru_lock needs to 
be held only when we transition from 0 to 1.

That guarantees that if the lru lock is held, and we read 0, we can 
safely assume that we're the only ones trying to lock.

/Thomas










> Signed-off-by: Maarten Maathuis 
> ---
>  drivers/gpu/drm/ttm/ttm_bo.c |8 +++-
>  1 files changed, 7 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index f5333d9..2104885 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -476,9 +476,9 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object 
> *bo, bool remove_all)
>   drm_mm_put_block(bo->mem.mm_node);
>   bo->mem.mm_node = NULL;
>   }
> - spin_unlock(&glob->lru_lock);
>  
>   atomic_set(&bo->reserved, 0);
> + spin_unlock(&glob->lru_lock);
>  
>   while (put_count--)
>   kref_put(&bo->list_kref, ttm_bo_ref_bug);
> @@ -1707,8 +1707,12 @@ EXPORT_SYMBOL(ttm_bo_wait);
>  
>  void ttm_bo_unblock_reservation(struct ttm_buffer_object *bo)
>  {
> + struct ttm_bo_global *glob = bo->glob;
> +
> + spin_lock(&glob->lru_lock);
>   atomic_set(&bo->reserved, 0);
>   wake_up_all(&bo->event_queue);
> + spin_unlock(&glob->lru_lock);
>  }
>  
>  int ttm_bo_block_reservation(struct ttm_buffer_object *bo, bool 
> interruptible,
> @@ -1849,8 +1853,10 @@ out:
>* already swapped buffer.
>*/
>  
> + spin_lock(&glob->lru_lock);
>   atomic_set(&bo->reserved, 0);
>   wake_up_all(&bo->event_queue);
> + spin_unlock(&glob->lru_lock);
>   kref_put(&bo->list_kref, ttm_bo_release_list);
>   return ret;
>  }
>   


--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH] libdrm_radeon: Optimize reloc writing to do less looping.

2010-03-01 Thread Pauli Nieminen
Bit has table will be first checked from BO if we can quarentee this BO is not
in this cs already. When bo is emited the reference to cs is removed with bit
operations.

To quarentee that there is no other cs with same id number of CS that can have
id is limited to number of bits in unsigned long.

This optimization decreases cs_write_reloc share of torcs profiling from 4.3%
to 2.6%.
---
 radeon/radeon_bo_gem.c |1 +
 radeon/radeon_bo_int.h |2 +-
 radeon/radeon_cs_gem.c |  111 ++-
 3 files changed, 82 insertions(+), 32 deletions(-)

diff --git a/radeon/radeon_bo_gem.c b/radeon/radeon_bo_gem.c
index bc8058d..1b33bdb 100644
--- a/radeon/radeon_bo_gem.c
+++ b/radeon/radeon_bo_gem.c
@@ -80,6 +80,7 @@ static struct radeon_bo *bo_open(struct radeon_bo_manager 
*bom,
 bo->base.domains = domains;
 bo->base.flags = flags;
 bo->base.ptr = NULL;
+bo->base.referenced_in_cs = 0;
 bo->map_count = 0;
 if (handle) {
 struct drm_gem_open open_arg;
diff --git a/radeon/radeon_bo_int.h b/radeon/radeon_bo_int.h
index 9589ead..d1df829 100644
--- a/radeon/radeon_bo_int.h
+++ b/radeon/radeon_bo_int.h
@@ -17,7 +17,7 @@ struct radeon_bo_int {
 unsignedcref;
 struct radeon_bo_manager*bom;
 uint32_tspace_accounted;
-uint32_treferenced_in_cs;
+unsigned long   referenced_in_cs;
 };
 
 /* bo functions */
diff --git a/radeon/radeon_cs_gem.c b/radeon/radeon_cs_gem.c
index 45a219c..d23aa35 100644
--- a/radeon/radeon_cs_gem.c
+++ b/radeon/radeon_cs_gem.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "radeon_cs.h"
@@ -63,11 +64,49 @@ struct cs_gem {
 struct radeon_cs_intbase;
 struct drm_radeon_cscs;
 struct drm_radeon_cs_chunk  chunks[2];
+unsigned long   id;
 unsignednrelocs;
 uint32_t*relocs;
 struct radeon_bo_int**relocs_bo;
 };
 
+static pthread_mutex_t id_mutex = PTHREAD_MUTEX_INITIALIZER;
+static unsigned long cs_id_source = 0;
+
+/**
+ * Returns a free id for cs.
+ * If there is no free id we return zero
+ **/
+static unsigned long generate_id(void)
+{
+unsigned long r = 0,x;
+pthread_mutex_lock( &id_mutex );
+/* check for free ids */
+if (cs_id_source != ~r) {
+/* find first zero bit */
+x = cs_id_source + 1; /* 10111 -> 1100 */
+r = ~cs_id_source;/* 10111 -> 0100 */
+r = x & r;/* x & r -> 0100 */
+
+/* set id as reserved */
+cs_id_source |= r;
+}
+pthread_mutex_unlock( &id_mutex );
+return r;
+}
+
+/**
+ * Free the id for later reuse
+ **/
+static void free_id(unsigned long id)
+{
+pthread_mutex_lock( &id_mutex );
+
+cs_id_source &= ~id;
+
+pthread_mutex_unlock( &id_mutex );
+}
+
 static struct radeon_cs_int *cs_gem_create(struct radeon_cs_manager *csm,
uint32_t ndw)
 {
@@ -90,6 +129,7 @@ static struct radeon_cs_int *cs_gem_create(struct 
radeon_cs_manager *csm,
 }
 csg->base.relocs_total_size = 0;
 csg->base.crelocs = 0;
+csg->id = generate_id();
 csg->nrelocs = 4096 / (4 * 4) ;
 csg->relocs_bo = (struct radeon_bo_int**)calloc(1,
 csg->nrelocs*sizeof(void*));
@@ -141,38 +181,43 @@ static int cs_gem_write_reloc(struct radeon_cs_int *cs,
 if (write_domain == RADEON_GEM_DOMAIN_CPU) {
 return -EINVAL;
 }
-/* check if bo is already referenced */
-for(i = 0; i < cs->crelocs; i++) {
-idx = i * RELOC_SIZE;
-reloc = (struct cs_reloc_gem*)&csg->relocs[idx];
-if (reloc->handle == bo->handle) {
-/* Check domains must be in read or write. As we check already
- * checked that in argument one of the read or write domain was
- * set we only need to check that if previous reloc as the read
- * domain set then the read_domain should also be set for this
- * new relocation.
- */
-/* the DDX expects to read and write from same pixmap */
-if (write_domain && (reloc->read_domain & write_domain)) {
-reloc->read_domain = 0;
-reloc->write_domain = write_domain;
-} else if (read_domain & reloc->write_domain) {
-reloc->read_domain = 0;
-} else {
-if (write_domain != reloc->write_domain)
-return -EINVAL;
-if (read_domain != reloc->read_domain)
-return -EINVAL;
+/* use bit field hash functionto determine
+   if this bo is for sure not in this cs.*/
+if ((boi->referenced_in_cs & csg->id)) {
+/* check if bo is already referenced */
+for(i = cs->crelocs; i != 0;) {
+--i;
+idx = i * RELOC_

Re: [PATCH 1/2] drm/ttm: remove some bo->mutex remains

2010-03-01 Thread Jerome Glisse
On Mon, Mar 01, 2010 at 07:34:39PM +0100, Maarten Maathuis wrote:
> - A few comments existed here and there that referred to a bo->mutex.
> 
> Signed-off-by: Maarten Maathuis 

Reviewed-by: Jerome Glisse 

> ---
>  drivers/gpu/drm/ttm/ttm_bo.c|6 +-
>  drivers/gpu/drm/ttm/ttm_bo_vm.c |2 +-
>  include/drm/ttm/ttm_bo_api.h|3 +--
>  include/drm/ttm/ttm_bo_driver.h |1 +
>  4 files changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 2920f9a..f5333d9 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -46,7 +46,6 @@
>  #include 
>  #include 
>  
> -#define TTM_ASSERT_LOCKED(param)
>  #define TTM_DEBUG(fmt, arg...)
>  #define TTM_BO_HASH_ORDER 13
>  
> @@ -306,9 +305,6 @@ void ttm_bo_unreserve(struct ttm_buffer_object *bo)
>  }
>  EXPORT_SYMBOL(ttm_bo_unreserve);
>  
> -/*
> - * Call bo->mutex locked.
> - */
>  static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, bool zero_alloc)
>  {
>   struct ttm_bo_device *bdev = bo->bdev;
> @@ -316,7 +312,7 @@ static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, 
> bool zero_alloc)
>   int ret = 0;
>   uint32_t page_flags = 0;
>  
> - TTM_ASSERT_LOCKED(&bo->mutex);
> + BUG_ON(!atomic_read(&bo->reserved));
>   bo->ttm = NULL;
>  
>   if (bdev->need_dma32)
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 668dbe8..41b0c1e 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -146,7 +146,7 @@ static int ttm_bo_vm_fault(struct vm_area_struct *vma, 
> struct vm_fault *vmf)
>* since the mmap_sem is only held in read mode. However, we
>* modify only the caching bits of vma->vm_page_prot and
>* consider those bits protected by
> -  * the bo->mutex, as we should be the only writers.
> +  * bo->reserved, as we should be the only writers.
>* There shouldn't really be any readers of these bits except
>* within vm_insert_mixed()? fork?
>*
> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> index 81eb9f4..c1093ae 100644
> --- a/include/drm/ttm/ttm_bo_api.h
> +++ b/include/drm/ttm/ttm_bo_api.h
> @@ -35,7 +35,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -298,7 +297,7 @@ ttm_bo_reference(struct ttm_buffer_object *bo)
>   * @interruptible:  Use interruptible wait.
>   * @no_wait:  Return immediately if buffer is busy.
>   *
> - * This function must be called with the bo::mutex held, and makes
> + * This function must be called with bo->reserved held, and makes
>   * sure any previous rendering to the buffer is completed.
>   * Note: It might be necessary to block validations before the
>   * wait by reserving the buffer.
> diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
> index ff7664e..d3fc5f8 100644
> --- a/include/drm/ttm/ttm_bo_driver.h
> +++ b/include/drm/ttm/ttm_bo_driver.h
> @@ -37,6 +37,7 @@
>  #include "linux/workqueue.h"
>  #include "linux/fs.h"
>  #include "linux/spinlock.h"
> +#include 
>  
>  struct ttm_backend;
>  
> -- 
> 1.7.0
> 
> 
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> --
> ___
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
> 

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [PATCH 2/2] drm/ttm: don't write to bo->reserved without holding glob->lru_lock

2010-03-01 Thread Jerome Glisse
On Mon, Mar 01, 2010 at 07:34:40PM +0100, Maarten Maathuis wrote:
> - The headerfile says you can't write to it without holding the lock.
> 
> Signed-off-by: Maarten Maathuis 

NAK, from my POV as we always use atomic_* on reserved it's useless
to protect it with spinlock.

Cheers,
Jerome

> ---
>  drivers/gpu/drm/ttm/ttm_bo.c |8 +++-
>  1 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index f5333d9..2104885 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -476,9 +476,9 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object 
> *bo, bool remove_all)
>   drm_mm_put_block(bo->mem.mm_node);
>   bo->mem.mm_node = NULL;
>   }
> - spin_unlock(&glob->lru_lock);
>  
>   atomic_set(&bo->reserved, 0);
> + spin_unlock(&glob->lru_lock);
>  
>   while (put_count--)
>   kref_put(&bo->list_kref, ttm_bo_ref_bug);
> @@ -1707,8 +1707,12 @@ EXPORT_SYMBOL(ttm_bo_wait);
>  
>  void ttm_bo_unblock_reservation(struct ttm_buffer_object *bo)
>  {
> + struct ttm_bo_global *glob = bo->glob;
> +
> + spin_lock(&glob->lru_lock);
>   atomic_set(&bo->reserved, 0);
>   wake_up_all(&bo->event_queue);
> + spin_unlock(&glob->lru_lock);
>  }
>  
>  int ttm_bo_block_reservation(struct ttm_buffer_object *bo, bool 
> interruptible,
> @@ -1849,8 +1853,10 @@ out:
>* already swapped buffer.
>*/
>  
> + spin_lock(&glob->lru_lock);
>   atomic_set(&bo->reserved, 0);
>   wake_up_all(&bo->event_queue);
> + spin_unlock(&glob->lru_lock);
>   kref_put(&bo->list_kref, ttm_bo_release_list);
>   return ret;
>  }
> -- 
> 1.7.0
> 
> 
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> --
> ___
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
> 

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH] drm/radeon: fix typo in Makefile

2010-03-01 Thread Alex Deucher
>From ceb6fdc76834259bd4d4d47562ad166362bdcd4c Mon Sep 17 00:00:00 2001
From: Alex Deucher 
Date: Mon, 1 Mar 2010 14:23:31 -0500
Subject: [PATCH] drm/radeon: fix typo in Makefile

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/Makefile |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 0adf49e..ed38262 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -63,6 +63,6 @@ radeon-y += radeon_device.o radeon_kms.o \
evergreen.o

 radeon-$(CONFIG_COMPAT) += radeon_ioc32.o
-radeon-$(CONFIG_VGA_SWITCHEROO) += radone_atpx_handler.o
+radeon-$(CONFIG_VGA_SWITCHEROO) += radeon_atpx_handler.o

 obj-$(CONFIG_DRM_RADEON)+= radeon.o
-- 
1.5.6.3


0001-drm-radeon-fix-typo-in-Makefile.patch
Description: application/mbox
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH 2/2] drm/ttm: don't write to bo->reserved without holding glob->lru_lock

2010-03-01 Thread Maarten Maathuis
- The headerfile says you can't write to it without holding the lock.

Signed-off-by: Maarten Maathuis 
---
 drivers/gpu/drm/ttm/ttm_bo.c |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index f5333d9..2104885 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -476,9 +476,9 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object 
*bo, bool remove_all)
drm_mm_put_block(bo->mem.mm_node);
bo->mem.mm_node = NULL;
}
-   spin_unlock(&glob->lru_lock);
 
atomic_set(&bo->reserved, 0);
+   spin_unlock(&glob->lru_lock);
 
while (put_count--)
kref_put(&bo->list_kref, ttm_bo_ref_bug);
@@ -1707,8 +1707,12 @@ EXPORT_SYMBOL(ttm_bo_wait);
 
 void ttm_bo_unblock_reservation(struct ttm_buffer_object *bo)
 {
+   struct ttm_bo_global *glob = bo->glob;
+
+   spin_lock(&glob->lru_lock);
atomic_set(&bo->reserved, 0);
wake_up_all(&bo->event_queue);
+   spin_unlock(&glob->lru_lock);
 }
 
 int ttm_bo_block_reservation(struct ttm_buffer_object *bo, bool interruptible,
@@ -1849,8 +1853,10 @@ out:
 * already swapped buffer.
 */
 
+   spin_lock(&glob->lru_lock);
atomic_set(&bo->reserved, 0);
wake_up_all(&bo->event_queue);
+   spin_unlock(&glob->lru_lock);
kref_put(&bo->list_kref, ttm_bo_release_list);
return ret;
 }
-- 
1.7.0


--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH 1/2] drm/ttm: remove some bo->mutex remains

2010-03-01 Thread Maarten Maathuis
- A few comments existed here and there that referred to a bo->mutex.

Signed-off-by: Maarten Maathuis 
---
 drivers/gpu/drm/ttm/ttm_bo.c|6 +-
 drivers/gpu/drm/ttm/ttm_bo_vm.c |2 +-
 include/drm/ttm/ttm_bo_api.h|3 +--
 include/drm/ttm/ttm_bo_driver.h |1 +
 4 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2920f9a..f5333d9 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -46,7 +46,6 @@
 #include 
 #include 
 
-#define TTM_ASSERT_LOCKED(param)
 #define TTM_DEBUG(fmt, arg...)
 #define TTM_BO_HASH_ORDER 13
 
@@ -306,9 +305,6 @@ void ttm_bo_unreserve(struct ttm_buffer_object *bo)
 }
 EXPORT_SYMBOL(ttm_bo_unreserve);
 
-/*
- * Call bo->mutex locked.
- */
 static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, bool zero_alloc)
 {
struct ttm_bo_device *bdev = bo->bdev;
@@ -316,7 +312,7 @@ static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, 
bool zero_alloc)
int ret = 0;
uint32_t page_flags = 0;
 
-   TTM_ASSERT_LOCKED(&bo->mutex);
+   BUG_ON(!atomic_read(&bo->reserved));
bo->ttm = NULL;
 
if (bdev->need_dma32)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 668dbe8..41b0c1e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -146,7 +146,7 @@ static int ttm_bo_vm_fault(struct vm_area_struct *vma, 
struct vm_fault *vmf)
 * since the mmap_sem is only held in read mode. However, we
 * modify only the caching bits of vma->vm_page_prot and
 * consider those bits protected by
-* the bo->mutex, as we should be the only writers.
+* bo->reserved, as we should be the only writers.
 * There shouldn't really be any readers of these bits except
 * within vm_insert_mixed()? fork?
 *
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 81eb9f4..c1093ae 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -35,7 +35,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -298,7 +297,7 @@ ttm_bo_reference(struct ttm_buffer_object *bo)
  * @interruptible:  Use interruptible wait.
  * @no_wait:  Return immediately if buffer is busy.
  *
- * This function must be called with the bo::mutex held, and makes
+ * This function must be called with bo->reserved held, and makes
  * sure any previous rendering to the buffer is completed.
  * Note: It might be necessary to block validations before the
  * wait by reserving the buffer.
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index ff7664e..d3fc5f8 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -37,6 +37,7 @@
 #include "linux/workqueue.h"
 #include "linux/fs.h"
 #include "linux/spinlock.h"
+#include 
 
 struct ttm_backend;
 
-- 
1.7.0


--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 26816] AGP KMS x11 video perf problem.

2010-03-01 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=26816





--- Comment #2 from Andy Furniss   2010-03-01 
09:32:01 PST ---
(In reply to comment #1)
> Created an attachment (id=33664)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=33664) [details]
> pool allocator to improve AGP performance.
> 
> Does this kernel patch help your performance problems? It is made against
> vanila git sources.

Yes, that does fix it, KMS with UTS enabled is now the same as UMS.

KMS + ExaNoUploadToScreen is unchanged.

> To profile kernel you will need 1.1.5 version of sysprofile and kernel debug
> symbols.

Ahh, I was hoping to get away with the stable as I can't compile the newer one
- it doesn't like my old gtk AFAICT.


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

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 16950] git checkout of mesa crashes when using wine on r500 card

2010-03-01 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=16950


kowalski marcin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Comment #5 from kowalski marcin   2010-03-01 09:23:25 
PST ---
let's close this, i haven't had issues in a while.


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

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [PATCH] vga_switcheroo: fix build on platforms with no ACPI

2010-03-01 Thread Alex Deucher
On Mon, Mar 1, 2010 at 5:52 AM, Dave Airlie  wrote:
> From: Dave Airlie 
>
> radeon was always including the atpx code unnecessarily, also core
> switcheroo was including acpi headers.
>
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/radeon/Makefile              |    3 ++-
>  drivers/gpu/drm/radeon/radeon_atpx_handler.c |    1 -
>  drivers/gpu/drm/radeon/radeon_drv.h          |    6 ++
>  drivers/gpu/vga/vga_switcheroo.c             |    3 ---
>  include/linux/vga_switcheroo.h               |    1 -
>  5 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
> index 0a4d526..0adf49e 100644
> --- a/drivers/gpu/drm/radeon/Makefile
> +++ b/drivers/gpu/drm/radeon/Makefile
> @@ -60,8 +60,9 @@ radeon-y += radeon_device.o radeon_kms.o \
>        rs400.o rs600.o rs690.o rv515.o r520.o r600.o rv770.o radeon_test.o \
>        r200.o radeon_legacy_tv.o r600_cs.o r600_blit.o r600_blit_shaders.o \
>        r600_blit_kms.o radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o \
> -       evergreen.o radeon_atpx_handler.o
> +       evergreen.o
>
>  radeon-$(CONFIG_COMPAT) += radeon_ioc32.o
> +radeon-$(CONFIG_VGA_SWITCHEROO) += radone_atpx_handler.o

typo.  should be radeon_atpx_handler.o

Alex

>
>  obj-$(CONFIG_DRM_RADEON)+= radeon.o
> diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c 
> b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> index 0ae52f1..3f557c4 100644
> --- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> +++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> @@ -6,7 +6,6 @@
>  *
>  * ATPX support for both Intel/ATI
>  */
> -
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.h 
> b/drivers/gpu/drm/radeon/radeon_drv.h
> index 4fe1646..ec55f2b 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.h
> +++ b/drivers/gpu/drm/radeon/radeon_drv.h
> @@ -463,8 +463,14 @@ extern void r600_blit_swap(struct drm_device *dev,
>                           int w, int h, int src_pitch, int dst_pitch, int 
> cpp);
>
>  /* atpx handler */
> +#if defined(CONFIG_VGA_SWITCHEROO)
>  void radeon_register_atpx_handler(void);
>  void radeon_unregister_atpx_handler(void);
> +#else
> +static inline void radeon_register_atpx_handler(void) {}
> +static inline void radeon_unregister_atpx_handler(void) {}
> +#endif
> +
>  /* Flags for stats.boxes
>  */
>  #define RADEON_BOX_DMA_IDLE      0x1
> diff --git a/drivers/gpu/vga/vga_switcheroo.c 
> b/drivers/gpu/vga/vga_switcheroo.c
> index a3f587a..d6d1149 100644
> --- a/drivers/gpu/vga/vga_switcheroo.c
> +++ b/drivers/gpu/vga/vga_switcheroo.c
> @@ -25,9 +25,6 @@
>  #include 
>  #include 
>
> -#include 
> -#include 
> -
>  #include 
>  #include 
>
> diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
> index 4b58ab1..ae9ab13 100644
> --- a/include/linux/vga_switcheroo.h
> +++ b/include/linux/vga_switcheroo.h
> @@ -7,7 +7,6 @@
>  * vga_switcheroo.h - Support for laptop with dual GPU using one set of 
> outputs
>  */
>
> -#include 
>  #include 
>
>  enum vga_switcheroo_state {
> --
> 1.6.5.2
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> --
> ___
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/dri-devel
>

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: SwapContext hook back

2010-03-01 Thread Ian Romanick
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Westermann Fu wrote:

> I found that for DRI callback 'SwapContext' hook handler, seems no
> driver interested with it, except for old glint video driver do real
> work in it. Does it mean context switch concept outdated for current
> graphics hardware, but I found that intel hardware has logical context
> save/store command for these stuff? As I guess, context switch design
> strategy was taken out behind background of old-style DMA graphics
> device such as GLINT. But how the performance boost by using context
> switching rather than by reg-by-reg emiting at that old time?   Thanks
> very much.

My recollection is that this was to allow for the X server to handle
graphics context switching.  That method is certainly undesirable.  If a
driver were to implement some sort of optimized switching, the kernel is
the right place to do it.  What we've found in the past with most
hardware is that the cost of tracking dirty state tends to outweigh the
benefit of not emitting redundant state.  Different applications don't
generally have any of the expensive state in common.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuL8NAACgkQX1gOwKyEAw9OEQCgkZRX9T5zmOBeCNvDXx4u/OZW
8XcAnArdE7Jqnw1ihDX6vZpyq4Gr5e9n
=I2NG
-END PGP SIGNATURE-

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [PATCH][RFC] time: add wait_interruptible_timeout macro to sleep (w. timeout) until wake_up

2010-03-01 Thread Michel Dänzer
On Sat, 2010-02-27 at 10:33 +0100, Rafał Miłecki wrote: 
> W dniu 26 lutego 2010 20:01 użytkownik Ville Syrjälä  napisał:
> > Disabling the condition check doesn't make sense.
> >
> > You could use a completion.
> >
> > init_completion(vbl_irq);
> > enable_vbl_irq();
> > wait_for_completion(vbl_irq);
> > disable_vbl_irq();
> > and call complete(vbl_irq) in the interrupt handler.
> >
> > The same would of course work with just some flag or counter
> > and a wait queue.
> 
> Ouch, I can see it gone bad already.
> 
> Firstly I simply just wanted to avoid condition in wait_event_*. It
> looked unnecessary as I got interrupts (signals).

So this code runs in user process context? If so, it should return to
userspace ASAP on signal receipt, otherwise e.g. smoothness of X mouse
movement may suffer.

If that's a problem, then maybe the code should run in a different
context, e.g. a tasklet or some kind of worker kernel thread.


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

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


drm: Allow platform devices to register as DRM devices

2010-03-01 Thread Jordan Crouse
Following is a patch to allow platform devices on platforms without PCI 
to register and operate as fully fledged DRM devices.  I have been using 
this code for some time now and I'm convinced that the model works, but 
I'm posting this to get some constructive criticism on ways to improve 
the patch and get it ready for upstream.

Thanks,
Jordan


--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [PATCH] agpgart: Reprobe VGA devices when a new GART device is added

2010-03-01 Thread Eric Anholt
On Mon, 1 Mar 2010 18:33:14 +1000, Dave Airlie  wrote:
> On Sun, Feb 28, 2010 at 1:30 PM, Ben Hutchings  wrote:
> > This addresses .
> >
> > DRM drivers may fail to probe their devices when the associated AGP
> > GART does not yet have a driver, so we reprobe unbound VGA devices
> > when a GART device is added.
> >
> > Signed-off-by: Ben Hutchings 
> > ---
> > This is intended to address the dependency problem highlighted in the
> > above bug report.  That specific bug can be fixed by adding a module
> > dependency from i915 to intel_agp, but in general there is no fixed
> > relationship betweem DRM and GART drivers.
> >
> > There is a narrow race between the check for a current driver binding
> > and the call to device_reprobe().  This could be closed by adding a
> > variant on device_attach() and device_reprobe() that is a no-op for
> > bound devices.
> >
> 
> This isn't useful, generally there is no AGP binding, and most drivers
> if they can't find an AGP backend will still run fine without it. i.e. radeon,
> mga etc.
> 
> Intel is a special case and I think we've already merged an explicit
> depend.
> 
> Just build agp drivers into the kernel, I'm tempted to make them all
> non-modular.

That seems easier.


pgptHyNIRQvRo.pgp
Description: PGP signature
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH] drm: Allow platform devices to register as DRM devices

2010-03-01 Thread Jordan Crouse

Allow platform devices without PCI resources to be DRM devices.

Signed-off-by: Jordan Crouse 
---

  drivers/gpu/drm/Kconfig |4 -
  drivers/gpu/drm/Makefile|2
  drivers/gpu/drm/drm_bufs.c  |   27 ++-
  drivers/gpu/drm/drm_drv.c   |   38 +
  drivers/gpu/drm/drm_edid.c  |3 +
  drivers/gpu/drm/drm_info.c  |   23 --
  drivers/gpu/drm/drm_ioctl.c |   70 -
  drivers/gpu/drm/drm_irq.c   |   16 ++--
  drivers/gpu/drm/drm_pci.c   |  142 
+++
  drivers/gpu/drm/drm_platform.c  |  121 ++
  drivers/gpu/drm/drm_stub.c  |   90 +-
  drivers/gpu/drm/drm_sysfs.c |7 +-
  drivers/gpu/drm/drm_vm.c|   14 +++
  drivers/gpu/drm/i915/i915_drv.c |2
  drivers/gpu/drm/radeon/radeon_drv.c |2
  include/drm/drmP.h  |   52 +++--
  16 files changed, 444 insertions(+), 169 deletions(-)
  create mode 100644 drivers/gpu/drm/drm_platform.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 305c590..c2f43cc 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -6,7 +6,7 @@
  #
  menuconfig DRM
tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI 
support)"
-   depends on (AGP || AGP=n) && PCI && !EMULATED_CMPXCHG && MMU
+   depends on !EMULATED_CMPXCHG && MMU
select I2C
select I2C_ALGOBIT
help
@@ -16,7 +16,7 @@ menuconfig DRM
  These modules provide support for synchronization, security, and
  DMA transfers. Please see  for more
  details.  You should also select and configure AGP
- (/dev/agpgart) support.
+ (/dev/agpgart) support if it is available for your platform.

  config DRM_KMS_HELPER
tristate
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 39c5aa7..a3ea7c6 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -9,7 +9,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
drm_drv.o drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
drm_lock.o drm_memory.o drm_proc.o drm_stub.o drm_vm.o \
drm_agpsupport.o drm_scatter.o ati_pcigart.o drm_pci.o \
-   drm_sysfs.o drm_hashtab.o drm_sman.o drm_mm.o \
+   drm_platform.o drm_sysfs.o drm_hashtab.o drm_sman.o drm_mm.o \
drm_crtc.o drm_modes.o drm_edid.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o

diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 8417cc4..4177f60 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -11,6 +11,7 @@
   *
   * Copyright 1999, 2000 Precision Insight, Inc., Cedar Park, Texas.
   * Copyright 2000 VA Linux Systems, Inc., Sunnyvale, California.
+ * Copyright (c) 2009, Code Aurora Forum.
   * All Rights Reserved.
   *
   * Permission is hereby granted, free of charge, to any person obtaining a
@@ -40,13 +41,37 @@

  resource_size_t drm_get_resource_start(struct drm_device *dev, 
unsigned int resource)
  {
+   if (drm_core_check_feature(dev, DRIVER_USE_PLATFORM_DEVICE)) {
+   struct resource *r;
+   r = platform_get_resource(dev->platformdev, IORESOURCE_MEM,
+resource);
+
+   return r ? r->start : 0;
+   }
+
+#ifdef CONFIG_PCI
return pci_resource_start(dev->pdev, resource);
+#endif
+
+   return 0;
  }
  EXPORT_SYMBOL(drm_get_resource_start);

  resource_size_t drm_get_resource_len(struct drm_device *dev, unsigned 
int resource)
  {
+   if (drm_core_check_feature(dev, DRIVER_USE_PLATFORM_DEVICE)) {
+   struct resource *r;
+   r = platform_get_resource(dev->platformdev, IORESOURCE_MEM,
+   resource);
+
+   return r ? (r->end - r->start) : 0;
+   }
+
+#ifdef CONFIG_PCI
return pci_resource_len(dev->pdev, resource);
+#endif
+
+   return 0;
  }

  EXPORT_SYMBOL(drm_get_resource_len);
@@ -188,7 +213,7 @@ static int drm_addmap_core(struct drm_device * dev, 
resource_size_t offset,
switch (map->type) {
case _DRM_REGISTERS:
case _DRM_FRAME_BUFFER:
-#if !defined(__sparc__) && !defined(__alpha__) && !defined(__ia64__) && 
!defined(__powerpc64__) && !defined(__x86_64__)
+#if !defined(__sparc__) && !defined(__alpha__) && !defined(__ia64__) && 
!defined(__powerpc64__) && !defined(__x86_64__) && !defined(__arm__)
if (map->offset + (map->size-1) < map->offset ||
map->offset < virt_to_phys(high_memory)) {
kfree(map);
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 766c468..b5171ed 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -24,6 +24,7 @@
   *
   * Copyright 1

[Bug 26816] AGP KMS x11 video perf problem.

2010-03-01 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=26816





--- Comment #1 from Pauli   2010-03-01 07:10:03 PST ---
Created an attachment (id=33664)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=33664)
pool allocator to improve AGP performance.

Does this kernel patch help your performance problems? It is made against
vanila git sources.

To profile kernel you will need 1.1.5 version of sysprofile and kernel debug
symbols.


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

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 26817] New: Machine crashes on large screen updates.

2010-03-01 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=26817

   Summary: Machine crashes on large screen updates.
   Product: DRI
   Version: XOrg CVS
  Platform: x86-64 (AMD64)
   URL: http://pastebin.ca/1817089
OS/Version: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: mads_randst...@yahoo.dk


Created an attachment (id=33663)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=33663)
lspci, dmesg, Xorg.0.log from machine, delimited by --- NAME ---

My machine crashes on occasionally (more than once pr. day) when one of the
following happens.

Moving window from back to front in stack. (with large windows)
Changing tabs in paned windows (xchat, bluefish editor, firefox, netbeans,
chromium, and others)
Scrolling "fast" over multiple pages of text/data in the applications mentioned
above.

Also, firefox + flashplayer seems to bring it on almost all the time. Though it
may be unrelated (flashplayer have been known to crash before)

When I attach a gdb to the X process through an SSH session from another
machine, the SSH session stops to respond when the crash happens. It is the
entire machine not just X that does this. Also there is no signal caught by gdb
before the session freezes, so it is quite instant for the entire machine.

The machine is a Lenovo ThinkPad T400.
I have attached output of lspci, xorg.log (for the crashed session), and


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

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 26816] New: AGP KMS x11 video perf problem.

2010-03-01 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=26816

   Summary: AGP KMS x11 video perf problem.
   Product: DRI
   Version: XOrg CVS
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: li...@andyfurniss.entadsl.com


RV670 AGP running git ddx, xserver, libdrm and drt + nopat/AGP ttm caching fix
patch. Problem is not new.

I think there is a caching problem with KMS that does not happen with UMS which
makes video that doesn't use xv like flash or mplayer -vo x11 eat too much Cpu.

A partial work around can be achieved by disabling accel UTS, but it's still
not as good as UMS.

Some top figures - this is with mplayer -vo x11 704x...@25fps Cpu is single
core 2.1GHz.

UMS

Cpu(s): 18.7%us,  2.3%sy,  0.0%ni, 79.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
2504 andy  40   0 39008  13m 7748 S 13.3  1.5   0:01.10 mplayer
2472 root  40   0  591m 8508 5872 S  7.3  0.9   0:02.51 Xorg

KMS + ExaNoUploadToScreen

Cpu(s): 36.3%us,  0.3%sy,  0.0%ni, 63.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
4955 root  40   0 21140 9052 5760 S 22.9  1.0   0:04.76 Xorg
5006 andy  40   0 37980  13m 7836 S 13.6  1.5   0:00.71 mplayer

KMS

Cpu(s): 17.9%us, 60.8%sy,  0.0%ni, 21.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
4897 root  40   0 19628 8684 6040 R 65.8  1.0   0:29.11 Xorg
4925 andy  40   0 37980  13m 7836 S 13.0  1.5   0:00.91 mplayer

Will try and get a useful sysprof current effort just says in kernel for the
last case.


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

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 26631] R600 AGP KMS + dynpm,dynclks = stalls

2010-03-01 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=26631





--- Comment #11 from Andy Furniss   2010-03-01 
04:34:38 PST ---
(In reply to comment #10)

> I also notice that even just running gears the clock changes up/down
> accompanied by visual disturbance every couple of seconds, which seems a bit
> pointless, as do a lot of the in game changes.

Another thing I've noticed is that if I have two screens cloned then pm doesn't
do this. In fact the only time it seems to change clock is to reduce going into
DPMS and increase to full on coming back out, so I don't get pm during use
unless I turn off one of the screens with xrandr.


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

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Unmappable VRAM patchset V4

2010-03-01 Thread Thomas Hellstrom
Dave Airlie wrote:
> On Fri, Feb 26, 2010 at 3:01 AM, Jerome Glisse  wrote:
>   
>> Updated patchset, to apply cleanly on top of TTM split no_wait argument.
>> Compile tested for nouveau+vmwgfx, test in progress for radeon.
>>
>> So with the new change radeon won't wait for bo reserving other bo
>> in fault path but will wait the GPU (hoping it doesn't lockup ;))
>> This should address concern about the wait/locking issue.
>> 
>
> Thomas any time for this yet? I'd like to pull this in obviously, but
> it would be nice to know if Jerome has addressed all concerns.
>
> Dave.
>   
Hi Dave!
My schedule is currently a bit tight. I think the immediate deadlock 
concerns are met, but I'd to take a deeper look at some things that look 
a bit suspicious, but I think the overall approach is ok.
I'll hopefully be able to do a review on wednesday.

/Thomas


--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Convert DRM_INFO/DRM_ERROR to dev_info/dev_err

2010-03-01 Thread Jerome Glisse
On Mon, Mar 01, 2010 at 03:47:35PM +1000, Dave Airlie wrote:
> On Fri, Feb 26, 2010 at 4:56 AM, Jerome Glisse  wrote:
> > Attached is conversion from DRM_INFO/DRM_ERROR to dev_info/dev_err
> > to apply it copy all doconv* file into the radeon subfolder of the
> > kernel run ./doconv.sh and then apply the 0001 patch which fix
> > compilation after conversion (place where struct radeon_device is
> > missing) then thing should compile
> >
> > I think it's worthwhile cleanup especialy on multi GPU configuration.
> 
> Does this not remove the drm log levels?
> 
> so we end up with everything in dmesg the whole time?
> 
> that seems wrong, I'd rather pass a dev to DRM_ERROR/DRM_INFO
> or maybe defined DRM_DEV_ERROR, DRM_DEV_INFO.
> 
> Dave.
>

This doesn't touch DRM_DEBUG so log level is unaffected.
But if you prefer havimg DRM_DEV* i could convert radeon
to that.

Cheers,
Jerome

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [git pull] drm merge

2010-03-01 Thread Dave Airlie

It wouldn't be the drm unless it didn't build somewhere,

two fixes on top of that tree:
8edb381d6705811b278527907a5ae2a9c4db8074 vga_switcheroo: fix build on 
platforms with no ACPI
55a5cb5d594c18b3147a2288b00ea359c1a38cf8 drm/radeon: Fix printf type 
warning in 64bit system.

Dave..

On Mon, 1 Mar 2010, Dave Airlie wrote:

> 
> Hi Linus,
> 
> The following changes since commit 60b341b778cc2929df16c0a504c91621b3c6a4ad:
>   Linus Torvalds (1):
> Linux 2.6.33
> 
> are available in the git repository at:
> 
>   ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 
> drm-linus
> 
> This contains a few patches outside the DRM/AGP trees,
> (a) Initial hybrid graphics support in drivers/gpu/vga/ - called the 
> vga_switcheroo
> this is for dual-gpu laptops with a multiplexer on the outputs to swap 
> LVDS/VGA 
> between the two GPUs and the ability to powerdown the discrete GPU. This 
> implements
> the ATI variant and starts the groundwork for the nvidia variant. It touches
> fb code also to add a call to move all consoles to the other fb device.
> (b) minor fb patch to fix an offb handover issue.
> 
> Major drm highlights:
> core: switch to unlocked ioctls for KMS ioctls
> radeon-non-kms: fix ability to trash memory on r100/r200
>   fix problem trying to dynamically allocate 64k buffers at 
> runtime
> radeon: AMD evergreen (R5xxx) modesetting support - no accel yet,
>   unlocked KMS ioctls
>   hw i2c engine support
>   initial dynamic power management support
>   r600 command stream checker + fixes.
> intel: Sandybridge GPU support
>   unlocked KMS ioctls
> nouveau: new API - breaks userspace compatiblity - must upgrade libdrm_nouveau
>nv50 context program generator - gets rid of reliance on nvidia 
> firmware
> 
> *NOTE* in case you missed it: this will *break* your nvidia machine, its 
> purely
> intentional. Rawhide should have the libdrm and driver updates necessary.
> 
> Dave.
> 
> Alex Deucher (33):
>   drm/radeon/kms: add radeon i2c algo
>   drm/radeon/kms: add support for hw i2c on r1xx-r5xx
>   drm/radeon/kms: add workaround for rn50/rv100 servers
>   drm/radeon/kms: add support for hardcoded edids in rom (v2)
>   drm/radeon/kms: clean up some low-hanging magic numbers
>   drm/radeon/kms: rework pll algo selection
>   drm/radeon/kms: add pll quirk for toshiba laptop panel
>   drm/radeon/kms/atom: clean up spread spectrum code
>   drm/radeon/kms/atom: add a helper function to get the radeon connector 
> priv
>   drm/radeon/kms/r600: reduce gpu cache flushing
>   drm/radeon/kms: consolidate crtc count in rdev
>   drm/radeon/kms: add functions to get current pcie lanes
>   drm/radeon/kms: pull power mode info from bios tables (v3)
>   drm/radeon/kms: add a power state type based on power state flags
>   drm/radeon/kms: add code to select power state
>   drm/radeon/kms: use power states for dynamic reclocking
>   drm/radeon/kms: dynclks fixes
>   drm/radeon/kms: take the pm mutex when using hw i2c
>   drm/radeon/kms: update atombios.h to latest upstream.
>   drm/radeon/kms: add initial Evergreen support (Radeon HD 5xxx)
>   drm/radeon/kms: fix prescale calculations
>   drm/radeon/kms/atom: replace 0/1 in crtc code with 
> ATOM_DISABLE/ATOM_ENABLE
>   drm/radeon/kms/evergreen: fix multi-head
>   drm/radeon/kms/evergreen: adapt to i2c changes
>   drm/radeon/r600: fix warnings in CS checker
>   drm/radeon/kms: add LVDS pll quirk for Dell Studio 15
>   drm/radeon/kms: remove HDP flushes from fence emit (v2)
>   drm/radeon/kms: remove unused r600_gart_clear_page
>   drm/radeon/rv740: fix backend setup
>   drm/radeon: fixes for r6xx/r7xx gfx init
>   drm/radeon/kms/evergreen: fix typo in cursor code
>   drm/radeon/kms: update new pll algo
>   drm/radeon/kms/atom: fix shr/shl ops
> 
> Andy Shevchenko (1):
>   drivers/gpu/drm/drm_fb_helper.c: don't use private implementation of 
> atoi()
> 
> Ben Skeggs (17):
>   drm/nv50: switch to indirect push buffer controls
>   drm/nouveau: remove PUSHBUF_CAL macro
>   drm/nv50: make pushbuf dma object cover entire vm
>   drm/nouveau: new gem pushbuf interface, bump to 0.0.16
>   drm/nouveau: allow retrieval of vbios image from debugfs
>   drm/nouveau: rename parsed_dcb_gpio to dcb_gpio_table
>   drm/nouveau: merge parsed_dcb and bios_parsed_dcb into dcb_table
>   drm/nouveau: merge nvbios and nouveau_bios_info
>   drm/nouveau: reorganise bios header, add dcb connector type enums
>   drm/nouveau: parse dcb gpio/connector tables after encoders
>   drm/nouveau: check for known dcb connector types
>   drm/nouveau: construct a connector table for cards that lack a real one
>   drm/nouveau: use dcb connector table for creating drm connectors
>   drm/nv50: enable hpd on any connector we know the gpio line for
>   drm/nouvea

[PATCH] vga_switcheroo: fix build on platforms with no ACPI

2010-03-01 Thread Dave Airlie
From: Dave Airlie 

radeon was always including the atpx code unnecessarily, also core
switcheroo was including acpi headers.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/radeon/Makefile  |3 ++-
 drivers/gpu/drm/radeon/radeon_atpx_handler.c |1 -
 drivers/gpu/drm/radeon/radeon_drv.h  |6 ++
 drivers/gpu/vga/vga_switcheroo.c |3 ---
 include/linux/vga_switcheroo.h   |1 -
 5 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 0a4d526..0adf49e 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -60,8 +60,9 @@ radeon-y += radeon_device.o radeon_kms.o \
rs400.o rs600.o rs690.o rv515.o r520.o r600.o rv770.o radeon_test.o \
r200.o radeon_legacy_tv.o r600_cs.o r600_blit.o r600_blit_shaders.o \
r600_blit_kms.o radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o \
-   evergreen.o radeon_atpx_handler.o
+   evergreen.o
 
 radeon-$(CONFIG_COMPAT) += radeon_ioc32.o
+radeon-$(CONFIG_VGA_SWITCHEROO) += radone_atpx_handler.o
 
 obj-$(CONFIG_DRM_RADEON)+= radeon.o
diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c 
b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
index 0ae52f1..3f557c4 100644
--- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
+++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
@@ -6,7 +6,6 @@
  *
  * ATPX support for both Intel/ATI
  */
-
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/radeon/radeon_drv.h 
b/drivers/gpu/drm/radeon/radeon_drv.h
index 4fe1646..ec55f2b 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.h
+++ b/drivers/gpu/drm/radeon/radeon_drv.h
@@ -463,8 +463,14 @@ extern void r600_blit_swap(struct drm_device *dev,
   int w, int h, int src_pitch, int dst_pitch, int cpp);
 
 /* atpx handler */
+#if defined(CONFIG_VGA_SWITCHEROO)
 void radeon_register_atpx_handler(void);
 void radeon_unregister_atpx_handler(void);
+#else
+static inline void radeon_register_atpx_handler(void) {}
+static inline void radeon_unregister_atpx_handler(void) {}
+#endif
+
 /* Flags for stats.boxes
  */
 #define RADEON_BOX_DMA_IDLE  0x1
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index a3f587a..d6d1149 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -25,9 +25,6 @@
 #include 
 #include 
 
-#include 
-#include 
-
 #include 
 #include 
 
diff --git a/include/linux/vga_switcheroo.h b/include/linux/vga_switcheroo.h
index 4b58ab1..ae9ab13 100644
--- a/include/linux/vga_switcheroo.h
+++ b/include/linux/vga_switcheroo.h
@@ -7,7 +7,6 @@
  * vga_switcheroo.h - Support for laptop with dual GPU using one set of outputs
  */
 
-#include 
 #include 
 
 enum vga_switcheroo_state {
-- 
1.6.5.2


--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [PATCH] drm/radeon/kms: fence cleanup + more reliable GPU lockup detection

2010-03-01 Thread Jerome Glisse
On Mon, Mar 01, 2010 at 04:00:02PM +1000, Dave Airlie wrote:
> On Mon, Mar 1, 2010 at 2:47 AM, Jerome Glisse  wrote:
> > On Sun, Feb 28, 2010 at 12:22:52PM +, Alan Swanson wrote:
> >> On Fri, 2010-02-26 at 15:49 +0100, Jerome Glisse wrote:
> >> > This patch cleanup the fence code, it drops the timeout field of
> >> > fence as the time to complete each IB is unpredictable and shouldn't
> >> > be bound.
> >> >
> >> > The fence cleanup lead to GPU lockup detection improvement, this
> >> > patch introduce a callback, allowing to do asic specific test for
> >> > lockup detection. In this patch the CP is use as a first indicator
> >> > of GPU lockup. If CP doesn't make progress during 1second we assume
> >> > we are facing a GPU lockup.
> >> >
> >> > To avoid overhead of testing GPU lockup frequently due to fence
> >> > taking time to be signaled we query the lockup callback every
> >> > 100msec. There is plenty code comment explaining the design & choise
> >> > inside the code.
> >>
> >> Every 100msec? Is this running all the time? If so, that's not very good
> >> for CPU power saving to lower C-states in an idle system. We could at
> >> least use one of the round_jiffies.
> >>
> >
> > This run only when userspace call bo wait thus it only happen when userspace
> > is waiting for something.
> 
> Why not just test when the old timeout code used to test? every second or so?
> 
> I'm not sure why with the old code instead of assuming a fence timeout implied
> a lockup you didn't just change it to test if it was a real lockup and
> continue waiting
> if the GPU was making progress. This seems simpler, though maybe the cleanups
> are worth it.
> 
> Dave.
> 

The old code was misleading we didn't test every second or so but
it was depending on fence timeout and it was quite small amount
of time don't remember of hand. Here on the fast r7xx with 2 quake3
bunch of gears and compiz the average time for fence is 20ms.
But i think i will switch back to half a second timeout some irq
will likely wake up us.

Note that if you remove the comment lines in my patch i am pretty
sure my patch is removing code rather than adding some :) I will
do a V3 today.

Cheers,
Jerome

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH] drm/radeon: Fix printf type warning in 64bit system.

2010-03-01 Thread Pauli Nieminen
Type of iterator was promoted to unsigned long in 64bit systems.

*header is small structure so it is alwas safe to cast return value
of sizeof operator to int.

Signed-off-by: Pauli Nieminen 
---
 drivers/gpu/drm/radeon/r300_cmdbuf.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/radeon/r300_cmdbuf.c 
b/drivers/gpu/drm/radeon/r300_cmdbuf.c
index 18d3ff8..27930fc 100644
--- a/drivers/gpu/drm/radeon/r300_cmdbuf.c
+++ b/drivers/gpu/drm/radeon/r300_cmdbuf.c
@@ -1148,7 +1148,7 @@ int r300_do_cp_cmdbuf(struct drm_device *dev,
default:
DRM_ERROR("bad cmd_type %i at byte %d\n",
  header->header.cmd_type,
- cmdbuf->buffer->iterator - sizeof(*header));
+ cmdbuf->buffer->iterator - 
(int)sizeof(*header));
ret = -EINVAL;
goto cleanup;
}
-- 
1.6.3.3


--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode

2010-03-01 Thread Michal Suchanek
On 21 November 2009 05:27, Dave Airlie  wrote:

> At the moment the problem with fbset is what to do with it in the
> dual head case. Currently we create an fb console that is lowest
> common size of the two heads and set native modes on both,

Does that mean that fbset is supposed to work (set resolution) on drmfb?

>
> Now if a user runs fbset, I'm not sure what the right answer is,
> a) pick a head in advance via sysfs maybe and set it on that.
> b) try and set the mode on both heads cloned (what to do if
> there is no common mode is another issue).
>

I would say it's time to support multihead with fbset properly.

That is people would need new fbset which sees both (all) heads, and
fbset can then choose the head itself (and people can make it do
something different when they don't like the default). It should also
support setting up rotation on each head.

For old fbset setting something visible is probably good enough.

Schemes which would make a multihead setup look like a single screen
get complicated quite easily. Perhaps an option to turn off some
outputs so that the native resolution of one output is used (instead
of clone) would work.

Thanks

Michal

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


SwapContext hook back

2010-03-01 Thread Westermann Fu
Hi,

I found that for DRI callback 'SwapContext' hook handler, seems no driver
interested with it, except for old glint video driver do real work in it.
Does it mean context switch concept outdated for current graphics hardware,
but I found that intel hardware has logical context save/store command for
these stuff? As I guess, context switch design strategy was taken out behind
background of old-style DMA graphics device such as GLINT. But how the
performance boost by using context switching rather than by reg-by-reg
emiting at that old time?   Thanks very much.

Regards
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [PATCH] agpgart: Reprobe VGA devices when a new GART device is added

2010-03-01 Thread Dave Airlie
On Sun, Feb 28, 2010 at 1:30 PM, Ben Hutchings  wrote:
> This addresses .
>
> DRM drivers may fail to probe their devices when the associated AGP
> GART does not yet have a driver, so we reprobe unbound VGA devices
> when a GART device is added.
>
> Signed-off-by: Ben Hutchings 
> ---
> This is intended to address the dependency problem highlighted in the
> above bug report.  That specific bug can be fixed by adding a module
> dependency from i915 to intel_agp, but in general there is no fixed
> relationship betweem DRM and GART drivers.
>
> There is a narrow race between the check for a current driver binding
> and the call to device_reprobe().  This could be closed by adding a
> variant on device_attach() and device_reprobe() that is a no-op for
> bound devices.
>

This isn't useful, generally there is no AGP binding, and most drivers
if they can't find an AGP backend will still run fine without it. i.e. radeon,
mga etc.

Intel is a special case and I think we've already merged an explicit
depend.

Just build agp drivers into the kernel, I'm tempted to make them all
non-modular.

Dave.

--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [PATCH] agpgart: Reprobe VGA devices when a new GART device is added

2010-03-01 Thread Ben Hutchings
On Sun, 2010-02-28 at 03:30 +, Ben Hutchings wrote:
> +static void agp_probe_video(struct work_struct *work)
> +{
> + struct pci_dev *pdev = NULL;
> +
> + while ((pdev = pci_get_class(0x03, pdev)) != NULL) {

Only without the opening brace here...

Ben.

> + if (!pdev->dev.driver && device_reprobe(&pdev->dev))
> + pr_err(PFX "failed to reprobe %s\n", pci_name(pdev));
> +}

-- 
Ben Hutchings
Horngren's Observation:
   Among economists, the real world is often a special case.


signature.asc
Description: This is a digitally signed message part
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH] agpgart: Reprobe VGA devices when a new GART device is added

2010-03-01 Thread Ben Hutchings
This addresses .

DRM drivers may fail to probe their devices when the associated AGP
GART does not yet have a driver, so we reprobe unbound VGA devices
when a GART device is added.

Signed-off-by: Ben Hutchings 
---
This is intended to address the dependency problem highlighted in the
above bug report.  That specific bug can be fixed by adding a module
dependency from i915 to intel_agp, but in general there is no fixed
relationship betweem DRM and GART drivers.

There is a narrow race between the check for a current driver binding
and the call to device_reprobe().  This could be closed by adding a
variant on device_attach() and device_reprobe() that is a no-op for
bound devices.

Ben.

 drivers/char/agp/backend.c |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/drivers/char/agp/backend.c b/drivers/char/agp/backend.c
index c3ab46d..f9680bf 100644
--- a/drivers/char/agp/backend.c
+++ b/drivers/char/agp/backend.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include "agp.h"
 
@@ -281,6 +282,24 @@ void agp_put_bridge(struct agp_bridge_data *bridge)
 EXPORT_SYMBOL(agp_put_bridge);
 

+/*
+ * DRM drivers may fail to probe their devices when the associated AGP
+ * GART does not yet have a driver, so we reprobe unbound VGA devices
+ * when a GART device is added.  This problem applies not only to true
+ * AGP devices which would be children of the affected bridge, but
+ * also to PCI Express devices that may be siblings of the GART
+ * device.  Therefore iterate over all PCI VGA devices.
+ */
+static void agp_probe_video(struct work_struct *work)
+{
+   struct pci_dev *pdev = NULL;
+
+   while ((pdev = pci_get_class(0x03, pdev)) != NULL) {
+   if (!pdev->dev.driver && device_reprobe(&pdev->dev))
+   pr_err(PFX "failed to reprobe %s\n", pci_name(pdev));
+}
+static DECLARE_WORK(agp_probe_video_work, agp_probe_video);
+
 int agp_add_bridge(struct agp_bridge_data *bridge)
 {
int error;
@@ -324,6 +343,7 @@ int agp_add_bridge(struct agp_bridge_data *bridge)
}
 
list_add(&bridge->list, &agp_bridges);
+   schedule_work(&agp_probe_video_work);
return 0;
 
 frontend_err:
-- 
1.6.6.2



--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel