Re: [Intel-gfx] [PATCH 4/5] drm/i915: remove unused variables from ironlake_crtc_mode_set

2012-09-25 Thread Daniel Vetter 
On Mon, Sep 24, 2012 at 08:36:27PM -0300, Rodrigo Vivi wrote:
 Feel free to use
 Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com

Merged up to this patch to dinq, thanks for the reviewpatches.
-Daniel
 
 On Thu, Sep 20, 2012 at 6:36 PM, Paulo Zanoni przan...@gmail.com wrote:
  From: Paulo Zanoni paulo.r.zan...@intel.com
 
  The last patches moved a lot of code from ironlake_crtc_mode_set to
  sub-functions, so these variables became useless. You could get
  warnings by enabling -Wunused-but-set-variable.
 
  Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
  ---
   drivers/gpu/drm/i915/intel_display.c |   21 +++--
   1 file changed, 3 insertions(+), 18 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/intel_display.c 
  b/drivers/gpu/drm/i915/intel_display.c
  index 5fb082f..c402774 100644
  --- a/drivers/gpu/drm/i915/intel_display.c
  +++ b/drivers/gpu/drm/i915/intel_display.c
  @@ -4898,39 +4898,24 @@ static int ironlake_crtc_mode_set(struct drm_crtc 
  *crtc,
  int num_connectors = 0;
  intel_clock_t clock, reduced_clock;
  u32 dpll, fp = 0, fp2 = 0;
  -   bool ok, has_reduced_clock = false, is_sdvo = false;
  -   bool is_crt = false, is_lvds = false, is_tv = false, is_dp = false;
  +   bool ok, has_reduced_clock = false;
  +   bool is_lvds = false, is_dp = false, is_cpu_edp = false;
  struct intel_encoder *encoder;
  u32 temp;
  int ret;
  bool dither;
  -   bool is_cpu_edp = false, is_pch_edp = false;
 
  for_each_encoder_on_crtc(dev, crtc, encoder) {
  switch (encoder-type) {
  case INTEL_OUTPUT_LVDS:
  is_lvds = true;
  break;
  -   case INTEL_OUTPUT_SDVO:
  -   case INTEL_OUTPUT_HDMI:
  -   is_sdvo = true;
  -   if (encoder-needs_tv_clock)
  -   is_tv = true;
  -   break;
  -   case INTEL_OUTPUT_TVOUT:
  -   is_tv = true;
  -   break;
  -   case INTEL_OUTPUT_ANALOG:
  -   is_crt = true;
  -   break;
  case INTEL_OUTPUT_DISPLAYPORT:
  is_dp = true;
  break;
  case INTEL_OUTPUT_EDP:
  is_dp = true;
  -   if (intel_encoder_is_pch_edp(encoder-base))
  -   is_pch_edp = true;
  -   else
  +   if (!intel_encoder_is_pch_edp(encoder-base))
  is_cpu_edp = true;
  break;
  }
  --
  1.7.10.4
 
  ___
  Intel-gfx mailing list
  Intel-gfx@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/intel-gfx
 
 
 
 -- 
 Rodrigo Vivi
 Blog: http://blog.vivi.eng.br
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/9] drm/i915: add post-flush store dw workaround

2012-09-25 Thread Daniel Vetter 
On Wed, Sep 19, 2012 at 01:28:58PM -0700, Jesse Barnes wrote:
 Several platforms need this to flush the CS write buffers.

Chris spent quite some effort to dump less crap into the rings on gen6,
and your description here sounds like we only need this when flushing
write caches. Or it might only apply to CS writes (in which case this is
at the wrong spot). In any case, can you please double check where exactly
we need this and only add it there, with a neat comment explaining things
added?

I'm bitching because afair the CS stuff the windows driver emits (of which
I've seen some traces) only emits one such 8x MI_WRITE block per batch,
whereas your code here would emit 2 such 2x MI_WRITE blocks.

Thanks, Daniel
 
 References: https://bugs.freedesktop.org/show_bug.cgi?id=50241
 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 ---
  drivers/gpu/drm/i915/intel_ringbuffer.c |   15 ++-
  1 file changed, 14 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
 b/drivers/gpu/drm/i915/intel_ringbuffer.c
 index 55cdb4d..ef5101f 100644
 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
 +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
 @@ -216,7 +216,7 @@ gen6_render_ring_flush(struct intel_ring_buffer *ring,
   u32 flags = 0;
   struct pipe_control *pc = ring-private;
   u32 scratch_addr = pc-gtt_offset + 128;
 - int ret;
 + int ret, i;
  
   /* Force SNB workarounds for PIPE_CONTROL flushes */
   ret = intel_emit_post_sync_nonzero_flush(ring);
 @@ -259,6 +259,19 @@ gen6_render_ring_flush(struct intel_ring_buffer *ring,
   intel_ring_emit(ring, 0);
   intel_ring_advance(ring);
  
 + ret = intel_ring_begin(ring, 4 * 8);
 + if (ret)
 + return ret;
 +
 + for (i = 0; i  8; i++) {
 + intel_ring_emit(ring, MI_STORE_DWORD_INDEX);
 + intel_ring_emit(ring, I915_GEM_SCRATCH_INDEX  
 MI_STORE_DWORD_INDEX_SHIFT);
 + intel_ring_emit(ring, 0);
 + intel_ring_emit(ring, MI_NOOP);
 + }
 + intel_ring_advance(ring);
 +
 +
   return 0;
  }
  
 -- 
 1.7.9.5
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/9] drm/i915: add a HSW scratch location for flush commands

2012-09-25 Thread Daniel Vetter 
On Wed, Sep 19, 2012 at 01:28:57PM -0700, Jesse Barnes wrote:
 Some commands and workarounds require stores to occur to function
 correctly, so add some scratch space to the HWS page to accommodate
 them.
 
 Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
 ---
  drivers/gpu/drm/i915/intel_ringbuffer.h |1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
 b/drivers/gpu/drm/i915/intel_ringbuffer.h
 index 2ea7a31..ef85742 100644
 --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
 +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
 @@ -181,6 +181,7 @@ intel_read_status_page(struct intel_ring_buffer *ring,
   * The area from dword 0x20 to 0x3ff is available for driver usage.
   */
  #define I915_GEM_HWS_INDEX   0x20
 +#define I915_GEM_SCRATCH_INDEX   0x28 /* Some commands need a 
 scratch store */

Any specific reason for using an index divisible by 8? Afaik this is an
index, and the hw multiplies by 4 on it's own. So looks a bit puzzling
when reading (since iirc only 0x21 is used anywhere else, in some dri1
stuff).
-Daniel
  
  void intel_cleanup_ring_buffer(struct intel_ring_buffer *ring);
  
 -- 
 1.7.9.5
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] Add option -o number, which can test only one specified mode.

2012-09-25 Thread Yi Sun 
Each mode line has a number just like '[i]'. So we can only test the specified 
mode with giving the number of mode to '-o' parameter.

Signed-off-by: Yi Sun yi@intel.com

diff --git a/tests/testdisplay.c b/tests/testdisplay.c
index c52bb2f..39c4265 100644
--- a/tests/testdisplay.c
+++ b/tests/testdisplay.c
@@ -72,6 +72,7 @@ int dump_info = 0, test_all_modes =0, test_preferred_mode = 
0, force_mode = 0,
 int sleep_between_modes = 5;
 uint32_t depth = 24, stride, bpp;
 int qr_code = 0;
+int only_one_mode = 0, specified_mode_num = 0;
 
 drmModeModeInfo force_timing;
 
@@ -193,8 +194,10 @@ static void dump_connectors_fd(int drmfd)
printf(  modes:\n);
printf(  name refresh (Hz) hdisp hss hse htot vdisp 
   vss vse vtot flags type clock\n);
-   for (j = 0; j  connector-count_modes; j++)
+   for (j = 0; j  connector-count_modes; j++){
+   fprintf(stdout, [%d], j );
kmstest_dump_mode(connector-modes[j]);
+   }
 
drmModeFreeConnector(connector);
}
@@ -275,6 +278,12 @@ static void connector_find_preferred_mode(struct connector 
*c)
}
}
 
+   if ( only_one_mode ){
+   c-mode = connector-modes[specified_mode_num];
+   if (c-mode.type  DRM_MODE_TYPE_PREFERRED)
+   c-mode_valid = 1;
+   }
+
if (!c-mode_valid) {
if (connector-count_modes  0) {
/* use the first mode as test mode */
@@ -318,7 +327,7 @@ static void connector_find_preferred_mode(struct connector 
*c)
c-crtc = resources-crtcs[i];
c-pipe = i;
 
-   if(test_preferred_mode || force_mode)
+   if(test_preferred_mode || force_mode || only_one_mode)
resources-crtcs[i] = 0;
 
c-connector = connector;
@@ -525,7 +534,7 @@ set_mode(struct connector *c)
 
gem_close(drm_fd, fb_info.gem_handle);
 
-   fprintf(stdout, CRTS(%u):,c-crtc);
+   fprintf(stdout, CRTS(%u):[%d],c-crtc, j);
kmstest_dump_mode(c-mode);
if (drmModeSetCrtc(drm_fd, c-crtc, fb_id, 0, 0,
   c-id, 1, c-mode)) {
@@ -585,7 +594,7 @@ int update_display(void)
dump_crtcs_fd(drm_fd);
}
 
-   if (test_preferred_mode || test_all_modes || force_mode) {
+   if (test_preferred_mode || test_all_modes || force_mode || 
only_one_mode) {
/* Find any connected displays */
for (c = 0; c  resources-count_connectors; c++) {
connectors[c].id = resources-connectors[c];
@@ -596,7 +605,7 @@ int update_display(void)
return 1;
 }
 
-static char optstr[] = hiaf:s:d:p:mrt;
+static char optstr[] = hiaf:s:d:p:mrto:;
 
 static void __attribute__((noreturn)) usage(char *name)
 {
@@ -609,6 +618,7 @@ static void __attribute__((noreturn)) usage(char *name)
fprintf(stderr, \t-m\ttest the preferred mode\n);
fprintf(stderr, \t-t\tuse a tiled framebuffer\n);
fprintf(stderr, \t-r\tprint a QR code on the screen whose content is 
\pass\ for the automatic test\n);
+   fprintf(stderr, \t-o\tnumber of the mode\tonly test specified 
mode\n);
fprintf(stderr, \t-f\tclock 
MHz,hdisp,hsync-start,hsync-end,htotal,\n);
fprintf(stderr, \t\tvdisp,vsync-start,vsync-end,vtotal\n);
fprintf(stderr, \t\ttest force mode\n);
@@ -701,6 +711,10 @@ int main(int argc, char **argv)
case 'r':
qr_code = 1;
break;
+   case 'o':
+   only_one_mode = 1;
+   specified_mode_num = atoi(optarg);
+   break;
default:
fprintf(stderr, unknown option %c\n, c);
/* fall through */
@@ -710,7 +724,7 @@ int main(int argc, char **argv)
}
}
if (!test_all_modes  !force_mode  !dump_info 
-   !test_preferred_mode)
+   !test_preferred_mode  !only_one_mode)
test_all_modes = 1;
 
drm_fd = drm_open_any();
-- 
1.7.6.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Wrap external callers to IPS state with appropriate locks

2012-09-25 Thread Chris Wilson 
Finishes commit 02d719562ef40483648b2cc46899d4a2ff5953bb
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date:   Thu Aug 9 16:44:54 2012 +0200

drm/i915: properly guard ilk ips state

The core functions were annotated with their locking requirements, but
we overlooked that they were exported, without any control over the
locking, to debugfs. So in order to enable debugfs to read the registers
without triggering sanity checks, we change the exported entry points to
properly take the required locks before calling the core routines.

Reported-by: yangguang guang.a.y...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55304
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/intel_pm.c |   40 +++
 1 file changed, 36 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4e16cc1..f459e30 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2735,7 +2735,7 @@ static const struct cparams {
{ 0, 800, 231, 23784 },
 };
 
-unsigned long i915_chipset_val(struct drm_i915_private *dev_priv)
+static unsigned long __i915_chipset_val(struct drm_i915_private *dev_priv)
 {
u64 total_count, diff, ret;
u32 count1, count2, count3, m = 0, c = 0;
@@ -2789,6 +2789,22 @@ unsigned long i915_chipset_val(struct drm_i915_private 
*dev_priv)
return ret;
 }
 
+unsigned long i915_chipset_val(struct drm_i915_private *dev_priv)
+{
+   unsigned long val;
+
+   if (dev_priv-info-gen != 5)
+   return 0;
+
+   spin_lock_irq(mchdev_lock);
+
+   val = __i915_chipset_val(dev_priv);
+
+   spin_unlock_irq(mchdev_lock);
+
+   return val;
+}
+
 unsigned long i915_mch_val(struct drm_i915_private *dev_priv)
 {
unsigned long m, x, b;
@@ -2992,7 +3008,7 @@ void i915_update_gfx_val(struct drm_i915_private 
*dev_priv)
spin_unlock_irq(mchdev_lock);
 }
 
-unsigned long i915_gfx_val(struct drm_i915_private *dev_priv)
+static unsigned long __i915_gfx_val(struct drm_i915_private *dev_priv)
 {
unsigned long t, corr, state1, corr2, state2;
u32 pxvid, ext_v;
@@ -3029,6 +3045,22 @@ unsigned long i915_gfx_val(struct drm_i915_private 
*dev_priv)
return dev_priv-ips.gfx_power + state2;
 }
 
+unsigned long i915_gfx_val(struct drm_i915_private *dev_priv)
+{
+   unsigned long val;
+
+   if (dev_priv-info-gen != 5)
+   return 0;
+
+   spin_lock_irq(mchdev_lock);
+
+   val = __i915_gfx_val(dev_priv);
+
+   spin_unlock_irq(mchdev_lock);
+
+   return val;
+}
+
 /**
  * i915_read_mch_val - return value for IPS use
  *
@@ -3045,8 +3077,8 @@ unsigned long i915_read_mch_val(void)
goto out_unlock;
dev_priv = i915_mch_dev;
 
-   chipset_val = i915_chipset_val(dev_priv);
-   graphics_val = i915_gfx_val(dev_priv);
+   chipset_val = __i915_chipset_val(dev_priv);
+   graphics_val = __i915_gfx_val(dev_priv);
 
ret = chipset_val + graphics_val;
 
-- 
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Pratique : les cocottes Fontignac passent au lave-vaisselle

2012-09-25 Thread Guide achats malins 
Title: Pratique : les cocottes Fontignac passent au
lave-vaisselle
			
			
			
			
			Problme daffichage ? Consultez
cette page dans votre navigateur.
			  

  


  
	  
		
		
		
		
	  
	


  
	  
		
		
		Cocotte Fontignac, en fonte, pour mijoter ou saisir, elle sait tout
faire et sur tout type de feux.
		
	  
	


  
	  
		
		
		
			
			  
			  
			  
			  
Valable jusquau
25-09-12 23h59
			  
			  
			
			
			  
			  -69 %
			  
			
			
			  
			
		  
	  
	  
		
		
			
			  
			
			
			  
			  
			  159.00 
			  
			  
			
			
			  
			  49.00 
			  
			
		  
	  
	  
		
		
	  
	


  
	  
		
		

	La marque
Fontignac, cest la rfrence des cocottes en fonte !
Cest la grande marque Franaise, qui existe depuis 1926. Vous
pourrez saisir ou mijoter de bons petits plats, les garder au chaud et ce,
sur...
		
	  
	


  


  
	  
		
		
			
			  
			  Robinet LED			  
			
			
			  
			  
  
	
	
		
		  
		  
			-21 %
		  
		  
		
	  
	
  
  
	
	
	29,90 
	
	
  
  
	
	
		13,65 
	
	
  
  
	
  

			
		  
		
		
			
			  
			  Ple Pomme			  
			
			
			  
			  
  
	
	
		
		  
		  
			-41 %
		  
		  
		
	  
	
  
  
	
	
	22,90 
	
	
  
  
	
	
		13,55 
	
	
  
  
	
  

			
		  
		
	  
	  
		
		
			
			  
			  Tapis Souris USB			  
			
			
			  
			  
  
	
	
		
		  
		  
			-33 %
		  
		  
		
	  
	
  
  
	
	
	13,90 
	
	
  
  
	
	
		9,40 
	
	
  
  
	
  

			
		  
		
		
			
			  
			  Savon inusable			  
			
			
			  
			  
  
	
	
		
		  
		  
			-63 %
		  
		  
		
	  
	
  
  
	
	
	12,50 
	
	
  
  
	
	
		4,73 
	
	
  
  
	
  

			
		  
		
	  
	


  
	  
		
		
		
	  
	


  Conformment aux dispositions lgales, vous
pouvez vous opposer  recevoir dautres messages de notre
part. Pour exercer votre droit dopposition,suivez
ce lien: le dsabonnement seffectue en un
clic..

			  
			
			
			


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: s/cacheing/caching/

2012-09-25 Thread Chris Wilson 
On Tue, 25 Sep 2012 10:32:17 +0200, Daniel Vetter dan...@ffwll.ch wrote:
 On Sat, Sep 22, 2012 at 2:01 AM, Ben Widawsky b...@bwidawsk.net wrote:
  From: Ben Widawsky benjamin.widaw...@intel.com
 
  Signed-off-by: Ben Widawsky b...@bwidawsk.net
 
 IIrc we're already including this header in shipping libdrm, and we
 have already users for it ... Have you checked whether this doesn't
 break anything once copied over to libdrm? Maybe we just need a few
 #defines for the old names ...

It doesn't affect the ddx since it is still using its own prototype, and
there has yet to be a patch for Mesa to use this knowledge.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/9] drm/i915: add post-flush store dw workaround

2012-09-25 Thread Jesse Barnes 
On Tue, 25 Sep 2012 10:49:28 +0200
Daniel Vetter dan...@ffwll.ch wrote:

 On Wed, Sep 19, 2012 at 01:28:58PM -0700, Jesse Barnes wrote:
  Several platforms need this to flush the CS write buffers.
 
 Chris spent quite some effort to dump less crap into the rings on gen6,
 and your description here sounds like we only need this when flushing
 write caches. Or it might only apply to CS writes (in which case this is
 at the wrong spot). In any case, can you please double check where exactly
 we need this and only add it there, with a neat comment explaining things
 added?

write caches as in any time we do a store dw and want to read the
result coherently is my understanding.

 I'm bitching because afair the CS stuff the windows driver emits (of which
 I've seen some traces) only emits one such 8x MI_WRITE block per batch,
 whereas your code here would emit 2 such 2x MI_WRITE blocks.

Doing it once should be sufficient, I guess I need to split this out
(probably a good idea anyway for comment  naming purposes).

-- 
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/9] drm/i915: add a HSW scratch location for flush commands

2012-09-25 Thread Jesse Barnes 
On Tue, 25 Sep 2012 10:54:00 +0200
Daniel Vetter dan...@ffwll.ch wrote:

 On Wed, Sep 19, 2012 at 01:28:57PM -0700, Jesse Barnes wrote:
  Some commands and workarounds require stores to occur to function
  correctly, so add some scratch space to the HWS page to accommodate
  them.
  
  Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
  ---
   drivers/gpu/drm/i915/intel_ringbuffer.h |1 +
   1 file changed, 1 insertion(+)
  
  diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
  b/drivers/gpu/drm/i915/intel_ringbuffer.h
  index 2ea7a31..ef85742 100644
  --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
  +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
  @@ -181,6 +181,7 @@ intel_read_status_page(struct intel_ring_buffer *ring,
* The area from dword 0x20 to 0x3ff is available for driver usage.
*/
   #define I915_GEM_HWS_INDEX 0x20
  +#define I915_GEM_SCRATCH_INDEX 0x28 /* Some commands need a 
  scratch store */
 
 Any specific reason for using an index divisible by 8? Afaik this is an
 index, and the hw multiplies by 4 on it's own. So looks a bit puzzling
 when reading (since iirc only 0x21 is used anywhere else, in some dri1
 stuff).

I got scared when I saw something about qword alignment in the docs.

-- 
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/9] drm/i915: add a HSW scratch location for flush commands

2012-09-25 Thread Daniel Vetter 
On Tue, Sep 25, 2012 at 1:08 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
 On Tue, 25 Sep 2012 10:54:00 +0200
 Daniel Vetter dan...@ffwll.ch wrote:

 On Wed, Sep 19, 2012 at 01:28:57PM -0700, Jesse Barnes wrote:
  Some commands and workarounds require stores to occur to function
  correctly, so add some scratch space to the HWS page to accommodate
  them.
 
  Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
  ---
   drivers/gpu/drm/i915/intel_ringbuffer.h |1 +
   1 file changed, 1 insertion(+)
 
  diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
  b/drivers/gpu/drm/i915/intel_ringbuffer.h
  index 2ea7a31..ef85742 100644
  --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
  +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
  @@ -181,6 +181,7 @@ intel_read_status_page(struct intel_ring_buffer *ring,
* The area from dword 0x20 to 0x3ff is available for driver usage.
*/
   #define I915_GEM_HWS_INDEX 0x20
  +#define I915_GEM_SCRATCH_INDEX 0x28 /* Some commands need a 
  scratch store */

 Any specific reason for using an index divisible by 8? Afaik this is an
 index, and the hw multiplies by 4 on it's own. So looks a bit puzzling
 when reading (since iirc only 0x21 is used anywhere else, in some dri1
 stuff).

 I got scared when I saw something about qword alignment in the docs.

Afaik you need the qword alignment only when doing a qword write. And
iirc that only works with writes to gtt address (not status page
offsets). And for 64bit store_dw writes I remember some further
restrictions (at least on some pipes).

One thing I wonder is whether these workarounds still work when using
a status page store dw and not a direct write to a gtt address though
...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Wrap external callers to IPS state with appropriate locks

2012-09-25 Thread Chris Wilson 
Finishes commit 02d719562ef40483648b2cc46899d4a2ff5953bb
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date:   Thu Aug 9 16:44:54 2012 +0200

drm/i915: properly guard ilk ips state

The core functions were annotated with their locking requirements, but
we overlooked that they were exported, without any control over the
locking, to debugfs. So in order to enable debugfs to read the registers
without triggering sanity checks, we change the exported entry points to
properly take the required locks before calling the core routines.

Reported-by: yangguang guang.a.y...@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55304
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/intel_pm.c |   40 +++
 1 file changed, 36 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 4e16cc1..f459e30 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2735,7 +2735,7 @@ static const struct cparams {
{ 0, 800, 231, 23784 },
 };
 
-unsigned long i915_chipset_val(struct drm_i915_private *dev_priv)
+static unsigned long __i915_chipset_val(struct drm_i915_private *dev_priv)
 {
u64 total_count, diff, ret;
u32 count1, count2, count3, m = 0, c = 0;
@@ -2789,6 +2789,22 @@ unsigned long i915_chipset_val(struct drm_i915_private 
*dev_priv)
return ret;
 }
 
+unsigned long i915_chipset_val(struct drm_i915_private *dev_priv)
+{
+   unsigned long val;
+
+   if (dev_priv-info-gen != 5)
+   return 0;
+
+   spin_lock_irq(mchdev_lock);
+
+   val = __i915_chipset_val(dev_priv);
+
+   spin_unlock_irq(mchdev_lock);
+
+   return val;
+}
+
 unsigned long i915_mch_val(struct drm_i915_private *dev_priv)
 {
unsigned long m, x, b;
@@ -2992,7 +3008,7 @@ void i915_update_gfx_val(struct drm_i915_private 
*dev_priv)
spin_unlock_irq(mchdev_lock);
 }
 
-unsigned long i915_gfx_val(struct drm_i915_private *dev_priv)
+static unsigned long __i915_gfx_val(struct drm_i915_private *dev_priv)
 {
unsigned long t, corr, state1, corr2, state2;
u32 pxvid, ext_v;
@@ -3029,6 +3045,22 @@ unsigned long i915_gfx_val(struct drm_i915_private 
*dev_priv)
return dev_priv-ips.gfx_power + state2;
 }
 
+unsigned long i915_gfx_val(struct drm_i915_private *dev_priv)
+{
+   unsigned long val;
+
+   if (dev_priv-info-gen != 5)
+   return 0;
+
+   spin_lock_irq(mchdev_lock);
+
+   val = __i915_gfx_val(dev_priv);
+
+   spin_unlock_irq(mchdev_lock);
+
+   return val;
+}
+
 /**
  * i915_read_mch_val - return value for IPS use
  *
@@ -3045,8 +3077,8 @@ unsigned long i915_read_mch_val(void)
goto out_unlock;
dev_priv = i915_mch_dev;
 
-   chipset_val = i915_chipset_val(dev_priv);
-   graphics_val = i915_gfx_val(dev_priv);
+   chipset_val = __i915_chipset_val(dev_priv);
+   graphics_val = __i915_gfx_val(dev_priv);
 
ret = chipset_val + graphics_val;
 
-- 
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Mark hardware context support optional

2012-09-25 Thread Chris Wilson 
As using the contexts (with mesa) causes an instant hard hang on my
i5-2500 SandyBridge GT1 desktop, they are not ready for universal
enabling.

Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/i915_drv.c |5 +
 drivers/gpu/drm/i915/i915_drv.h |1 +
 drivers/gpu/drm/i915/i915_gem_context.c |   10 +-
 3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 705b2e1..6a87b21 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -64,6 +64,11 @@ module_param_named(semaphores, i915_semaphores, int, 0600);
 MODULE_PARM_DESC(semaphores,
Use semaphores for inter-ring sync (default: -1 (use per-chip 
defaults)));
 
+int i915_hw_contexts __read_mostly = 0;
+module_param_named(hw_contexts, i915_hw_contexts, int, 0400);
+MODULE_PARM_DESC(hw_contexts,
+   Enable hardware context support for userspace (default: 
disabled)));
+
 int i915_enable_rc6 __read_mostly = -1;
 module_param_named(i915_enable_rc6, i915_enable_rc6, int, 0400);
 MODULE_PARM_DESC(i915_enable_rc6,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dddc3dc..04b2134 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1245,6 +1245,7 @@ extern unsigned int i915_fbpercrtc __always_unused;
 extern int i915_panel_ignore_lid __read_mostly;
 extern unsigned int i915_powersave __read_mostly;
 extern int i915_semaphores __read_mostly;
+extern int i915_hw_contexts __read_mostly;
 extern unsigned int i915_lvds_downclock __read_mostly;
 extern int i915_lvds_channel_mode __read_mostly;
 extern int i915_panel_use_ssc __read_mostly;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3d3fc10..b26b592 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -247,12 +247,20 @@ err_destroy:
return ret;
 }
 
+static bool intel_has_hw_contexts(struct drm_device *dev)
+{
+   if (!i915_hw_contexts)
+   return false;
+
+   return HAS_HW_CONTEXTS(dev);
+}
+
 void i915_gem_context_init(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
uint32_t ctx_size;
 
-   if (!HAS_HW_CONTEXTS(dev))
+   if (!intel_has_hw_contexts(dev))
dev_priv-hw_contexts_disabled = true;
 
if (dev_priv-hw_contexts_disabled)
-- 
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Chart looks absolutely amazing!

2012-09-25 Thread Matty Russo 

Stock Symbol: FU EG
Recommendation: Accummulate/Long

Closed at: 0.284
Long Term Target Price: 2.67

Traders, this is a Champ! Trading activity during the past 3 weeks all time 
level!


HUGE NEWS

BIG NEWS COMING

NEWS:

Ruling of Federal Judge Weinstein That Poker is More a Game of Skill Than 
Chance


FaceUp Entertainment Group (OTC BB: FU EG), while our revenue model is 
member established and is now legal in at least 37 states in the US, the 
result of legal online poker could be massive for our shareholders and for 
others in this industry. Our high-tech AV program is effortlessly adaptable 
and we plan to be viablewhen the day arrives based on a nationwide 
legislative ruling.


Face Up Gaming`s unique platform is actually used in generating a vast 
multi-player gaming web consisting of games from each parts of the world, 
providing local normalized as well as cross linguistic localization!!!


We don`t need to say more! Trading starts Tue, Sep 25th first thing!

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: make sure we write all the DIP data bytes

2012-09-25 Thread Paulo Zanoni 
From: Paulo Zanoni paulo.r.zan...@intel.com

... even if the actual infoframe is smaller than the maximum possible
size.

If we don't write all the 32 DIP data bytes the InfoFrame ECC may not
be correctly calculated in some cases (e.g., when changing the port),
and this will lead to black screens on HDMI monitors. The ECC value is
generated by the hardware.

I don't see how this should break anything since we're writing 0 and
that should be the correct value, so this patch should be safe.

Notice that on IVB and older we actually have 64 bytes available for
VIDEO_DIP_DATA, but only bytes 0-31 actually store infoframe data: the
others are either read-only ECC values or marked as reserved. On HSW
we only have 32 bytes, and the ECC value is stored on its own separate
read-only register. See BSpec.

This patch fixes bug #46761, which is marked as a regression
introduced by commit 4e89ee174bb2da341bf90a84321c7008a3c9210d:
drm/i915: set the DIP port on ibx_write_infoframe

Before commit 4e89 we were just failing to send AVI infoframes when we
needed to change the port, which can lead to black screens in some
cases. After commit 4e89 we started sending infoframes, but with a
possibly wrong ECC value. After this patch I hope we start sending
correct infoframes.

Version 2:
  - Improve commit message
  - Try to make the code more clear

Cc: sta...@vger.kernel.org
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46761
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
 drivers/gpu/drm/i915/i915_reg.h   |4 
 drivers/gpu/drm/i915/intel_hdmi.c |   15 +++
 2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a828e90..7637824 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1794,6 +1794,10 @@
 
 /* Video Data Island Packet control */
 #define VIDEO_DIP_DATA 0x61178
+/* Read the description of VIDEO_DIP_DATA (before Haswel) or VIDEO_DIP_ECC
+ * (Haswell and newer) to see which VIDEO_DIP_DATA byte corresponds to each 
byte
+ * of the infoframe structure specified by CEA-861. */
+#define   VIDEO_DIP_DATA_SIZE  32
 #define VIDEO_DIP_CTL  0x61170
 /* Pre HSW: */
 #define   VIDEO_DIP_ENABLE (1  31)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index f9fb47c..08f2b63 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -151,6 +151,9 @@ static void g4x_write_infoframe(struct drm_encoder *encoder,
I915_WRITE(VIDEO_DIP_DATA, *data);
data++;
}
+   /* Write every possible data byte to force correct ECC calculation. */
+   for (; i  VIDEO_DIP_DATA_SIZE; i += 4)
+   I915_WRITE(VIDEO_DIP_DATA, 0);
mmiowb();
 
val |= g4x_infoframe_enable(frame);
@@ -186,6 +189,9 @@ static void ibx_write_infoframe(struct drm_encoder *encoder,
I915_WRITE(TVIDEO_DIP_DATA(intel_crtc-pipe), *data);
data++;
}
+   /* Write every possible data byte to force correct ECC calculation. */
+   for (; i  VIDEO_DIP_DATA_SIZE; i += 4)
+   I915_WRITE(TVIDEO_DIP_DATA(intel_crtc-pipe), 0);
mmiowb();
 
val |= g4x_infoframe_enable(frame);
@@ -224,6 +230,9 @@ static void cpt_write_infoframe(struct drm_encoder *encoder,
I915_WRITE(TVIDEO_DIP_DATA(intel_crtc-pipe), *data);
data++;
}
+   /* Write every possible data byte to force correct ECC calculation. */
+   for (; i  VIDEO_DIP_DATA_SIZE; i += 4)
+   I915_WRITE(TVIDEO_DIP_DATA(intel_crtc-pipe), 0);
mmiowb();
 
val |= g4x_infoframe_enable(frame);
@@ -259,6 +268,9 @@ static void vlv_write_infoframe(struct drm_encoder *encoder,
I915_WRITE(VLV_TVIDEO_DIP_DATA(intel_crtc-pipe), *data);
data++;
}
+   /* Write every possible data byte to force correct ECC calculation. */
+   for (; i  VIDEO_DIP_DATA_SIZE; i += 4)
+   I915_WRITE(VLV_TVIDEO_DIP_DATA(intel_crtc-pipe), 0);
mmiowb();
 
val |= g4x_infoframe_enable(frame);
@@ -292,6 +304,9 @@ static void hsw_write_infoframe(struct drm_encoder *encoder,
I915_WRITE(data_reg + i, *data);
data++;
}
+   /* Write every possible data byte to force correct ECC calculation. */
+   for (; i  VIDEO_DIP_DATA_SIZE; i += 4)
+   I915_WRITE(data_reg + i, 0);
mmiowb();
 
val |= hsw_infoframe_enable(frame);
-- 
1.7.10.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: s/cacheing/caching/

2012-09-25 Thread Ben Widawsky 
On Tue, 25 Sep 2012 10:43:55 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:

 On Tue, 25 Sep 2012 10:32:17 +0200, Daniel Vetter dan...@ffwll.ch wrote:
  On Sat, Sep 22, 2012 at 2:01 AM, Ben Widawsky b...@bwidawsk.net wrote:
   From: Ben Widawsky benjamin.widaw...@intel.com
  
   Signed-off-by: Ben Widawsky b...@bwidawsk.net
  
  IIrc we're already including this header in shipping libdrm, and we
  have already users for it ... Have you checked whether this doesn't
  break anything once copied over to libdrm? Maybe we just need a few
  #defines for the old names ...
 
 It doesn't affect the ddx since it is still using its own prototype, and
 there has yet to be a patch for Mesa to use this knowledge.
 -Chris
 

Quickly!

-- 
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: make sure we write all the DIP data bytes

2012-09-25 Thread Rodrigo Vivi 
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com

On Tue, Sep 25, 2012 at 1:23 PM, Paulo Zanoni przan...@gmail.com wrote:
 From: Paulo Zanoni paulo.r.zan...@intel.com

 ... even if the actual infoframe is smaller than the maximum possible
 size.

 If we don't write all the 32 DIP data bytes the InfoFrame ECC may not
 be correctly calculated in some cases (e.g., when changing the port),
 and this will lead to black screens on HDMI monitors. The ECC value is
 generated by the hardware.

 I don't see how this should break anything since we're writing 0 and
 that should be the correct value, so this patch should be safe.

 Notice that on IVB and older we actually have 64 bytes available for
 VIDEO_DIP_DATA, but only bytes 0-31 actually store infoframe data: the
 others are either read-only ECC values or marked as reserved. On HSW
 we only have 32 bytes, and the ECC value is stored on its own separate
 read-only register. See BSpec.

 This patch fixes bug #46761, which is marked as a regression
 introduced by commit 4e89ee174bb2da341bf90a84321c7008a3c9210d:
 drm/i915: set the DIP port on ibx_write_infoframe

 Before commit 4e89 we were just failing to send AVI infoframes when we
 needed to change the port, which can lead to black screens in some
 cases. After commit 4e89 we started sending infoframes, but with a
 possibly wrong ECC value. After this patch I hope we start sending
 correct infoframes.

 Version 2:
   - Improve commit message
   - Try to make the code more clear

 Cc: sta...@vger.kernel.org
 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46761
 Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
 ---
  drivers/gpu/drm/i915/i915_reg.h   |4 
  drivers/gpu/drm/i915/intel_hdmi.c |   15 +++
  2 files changed, 19 insertions(+)

 diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
 index a828e90..7637824 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -1794,6 +1794,10 @@

  /* Video Data Island Packet control */
  #define VIDEO_DIP_DATA 0x61178
 +/* Read the description of VIDEO_DIP_DATA (before Haswel) or VIDEO_DIP_ECC
 + * (Haswell and newer) to see which VIDEO_DIP_DATA byte corresponds to each 
 byte
 + * of the infoframe structure specified by CEA-861. */
 +#define   VIDEO_DIP_DATA_SIZE  32
  #define VIDEO_DIP_CTL  0x61170
  /* Pre HSW: */
  #define   VIDEO_DIP_ENABLE (1  31)
 diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
 b/drivers/gpu/drm/i915/intel_hdmi.c
 index f9fb47c..08f2b63 100644
 --- a/drivers/gpu/drm/i915/intel_hdmi.c
 +++ b/drivers/gpu/drm/i915/intel_hdmi.c
 @@ -151,6 +151,9 @@ static void g4x_write_infoframe(struct drm_encoder 
 *encoder,
 I915_WRITE(VIDEO_DIP_DATA, *data);
 data++;
 }
 +   /* Write every possible data byte to force correct ECC calculation. */
 +   for (; i  VIDEO_DIP_DATA_SIZE; i += 4)
 +   I915_WRITE(VIDEO_DIP_DATA, 0);
 mmiowb();

 val |= g4x_infoframe_enable(frame);
 @@ -186,6 +189,9 @@ static void ibx_write_infoframe(struct drm_encoder 
 *encoder,
 I915_WRITE(TVIDEO_DIP_DATA(intel_crtc-pipe), *data);
 data++;
 }
 +   /* Write every possible data byte to force correct ECC calculation. */
 +   for (; i  VIDEO_DIP_DATA_SIZE; i += 4)
 +   I915_WRITE(TVIDEO_DIP_DATA(intel_crtc-pipe), 0);
 mmiowb();

 val |= g4x_infoframe_enable(frame);
 @@ -224,6 +230,9 @@ static void cpt_write_infoframe(struct drm_encoder 
 *encoder,
 I915_WRITE(TVIDEO_DIP_DATA(intel_crtc-pipe), *data);
 data++;
 }
 +   /* Write every possible data byte to force correct ECC calculation. */
 +   for (; i  VIDEO_DIP_DATA_SIZE; i += 4)
 +   I915_WRITE(TVIDEO_DIP_DATA(intel_crtc-pipe), 0);
 mmiowb();

 val |= g4x_infoframe_enable(frame);
 @@ -259,6 +268,9 @@ static void vlv_write_infoframe(struct drm_encoder 
 *encoder,
 I915_WRITE(VLV_TVIDEO_DIP_DATA(intel_crtc-pipe), *data);
 data++;
 }
 +   /* Write every possible data byte to force correct ECC calculation. */
 +   for (; i  VIDEO_DIP_DATA_SIZE; i += 4)
 +   I915_WRITE(VLV_TVIDEO_DIP_DATA(intel_crtc-pipe), 0);
 mmiowb();

 val |= g4x_infoframe_enable(frame);
 @@ -292,6 +304,9 @@ static void hsw_write_infoframe(struct drm_encoder 
 *encoder,
 I915_WRITE(data_reg + i, *data);
 data++;
 }
 +   /* Write every possible data byte to force correct ECC calculation. */
 +   for (; i  VIDEO_DIP_DATA_SIZE; i += 4)
 +   I915_WRITE(data_reg + i, 0);
 mmiowb();

 val |= hsw_infoframe_enable(frame);
 --
 1.7.10.4

 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH] drm/i915: Mark hardware context support optional

2012-09-25 Thread Ben Widawsky 
On Tue, 25 Sep 2012 14:53:37 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:

 Enable hardware context support for userspace (default: disabled)));

You've found one platform this doesn't work on, and a bunch of features
rely on this, and yet we default to disabled? That seems a bit harsh to
me.

-- 
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Mark hardware context support optional

2012-09-25 Thread Chris Wilson 
On Tue, 25 Sep 2012 12:04:14 -0700, Ben Widawsky b...@bwidawsk.net wrote:
 On Tue, 25 Sep 2012 14:53:37 +0100
 Chris Wilson ch...@chris-wilson.co.uk wrote:
 
  Enable hardware context support for userspace (default: disabled)));
 
 You've found one platform this doesn't work on, and a bunch of features
 rely on this, and yet we default to disabled? That seems a bit harsh to
 me.

Exactly, it's meant to be harsh. In the limited testing that hw contexts
have been exposed to, we have a number of hangs for which they are
implicated. Therefore they are not safe to enable yet... Unless you can
prove otherwise. :-p
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Mark hardware context support optional

2012-09-25 Thread Ben Widawsky 
On Tue, 25 Sep 2012 20:41:45 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:

 On Tue, 25 Sep 2012 12:04:14 -0700, Ben Widawsky b...@bwidawsk.net
 wrote:
  On Tue, 25 Sep 2012 14:53:37 +0100
  Chris Wilson ch...@chris-wilson.co.uk wrote:
  
   Enable hardware context support for userspace (default:
   disabled)));
  
  You've found one platform this doesn't work on, and a bunch of
  features rely on this, and yet we default to disabled? That seems a
  bit harsh to me.
 
 Exactly, it's meant to be harsh. In the limited testing that hw
 contexts have been exposed to, we have a number of hangs for which
 they are implicated. Therefore they are not safe to enable yet...
 Unless you can prove otherwise. :-p
 -Chris
 

The reason I've always resisted a module parameter is that rc6 and
contexts are tied so very closely together. We've had a number of
issues around rc6 already, I do not want contexts to be conflated with
those issues. It's interesting if rc6=0 and failures still occur. I've
yet to hear of such an issue, but I'd like to know if that's the case
here.

As a side note, I'll mention yet again that we're missing a workaround
which Daniel (and I believe you as well) have previously
preemptively shot down involving sending a 3d primitive down the pipe
at certain times. IIRC those are only required with rc6 enabled.

Also, AFAIK many HW problems are fixed in IVB, and even more fixed in
HSW, so disabling for all platforms seems like not the right decision
to me. At least, as long as we only have evidence of one failing
platform.

As mesa will depend on this feature more and more, and with no error
state or other info to go on, again I think we should defer globally
disabling until we get more info, or else we risk not getting more info.

-- 
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] assertion on intel_disable_transcoder

2012-09-25 Thread Ben Guthro 
I am seeing this same trace (and no video) on multiple Haswell SDP's, with
3.6-rc7 (and earlier kernels)

Was there ever a resolution on this?



On Wed, Aug 15, 2012 at 3:24 AM, Wang, Xingchao xingchao.w...@intel.comwrote:

 Hi,

 Some update related to this warning.
 Ironlake_crtc_dpms() will enable/disable crtc which pipe was
 enabled/disabled there.
 Ironlake_crtc_dpms(DRM_MODE_DPMS_OFF) was called before the warning and
 crtc was disabled, that causes intel_wait_for_vblank() timeout and some
 assertions.

 I think it's a bug but I have no clue where/when to enable crtc again.

 Here's part of dmesg before the warning and the message showing dpms off.

 [   19.332220] [drm:intel_lvds_init], LVDS is not present in VBT
 [   19.332261] [drm:intel_crt_init], pch crt adpa set to 0x80f4
 [   19.332295] [drm:intel_dp_i2c_init], i2c_init DPDDC-B
 [   19.334807] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003f
 [   19.334809] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110
 [   19.337318] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5145003f
 [   19.337319] [drm:intel_dp_i2c_aux_ch], aux_ch failed -110
 [   19.337432] [drm:ironlake_crtc_dpms], crtc 0/0 dpms off
 [   19.337436] [drm:i915_get_vblank_timestamp], crtc 0 is disabled
 [   19.351826] [ cut here ]
 [   19.351848] WARNING: at drivers/gpu/drm/i915/intel_display.c:1118
 assert_fdi_tx+0x87/0x90 [i915]()
 [   19.351849] Hardware name: Shark Bay Client platform
 [   19.351850] FDI TX state assertion failure (expected off, current on)
 [   19.351867] Modules linked in: i915(+) kvm snd_hda_codec_realtek
 snd_hda_codec_hdmi drm_kms_helper
  drm snd_hda_intel snd_hda_codec snd_hwdep snd_pcm ghash_clmulni_intel
 snd_seq_midi snd_rawmidi snd_s
 eq_midi_event snd_seq aesni_intel snd_timer i2c_algo_bit cryptd mcs7830
 psmouse snd_seq_device usbnet
  snd joydev aes_x86_64 hid_generic soundcore serio_raw snd_page_alloc
 lpc_ich microcode mac_hid video
  lp parport e1000e usbhid hid
 [   19.351869] Pid: 535, comm: modprobe Not tainted 3.5.0-rc46patches+ #29
 [   19.351870] Call Trace:
 [   19.351876]  [8105278f] warn_slowpath_common+0x7f/0xc0

 thanks
 --xingchao


  -Original Message-
  From: Wang, Xingchao
  Sent: Tuesday, August 07, 2012 3:26 PM
  To: Daniel Vetter; Zanoni, Paulo R
  Cc: intel-gfx@lists.freedesktop.org; Fu, Michael; Wu, Fengguang; 'Zhenyu
  Wang (zhen...@linux.intel.com)'; Zhao, Yakui
  Subject: assertion on intel_disable_transcoder
 
  Hi Daniel/Paulo,
 
  It's easy to see such WARNING in dmesg, the DDI port is not disabled
 prior to
  disable transcoder.
  I am not sure it will impact the Pipe/transcoder/DDI-port configurations,
  anyway after some times WARNING, I could not make HDMI audio work
  anymore.
  With intel_audio_dump I could see the related configurations was totally
  disabled.
 
  DDI_BUF_CTL_A 0x0080  DDI Buffer Controler A
  DDI_BUF_CTL_B 0x  DDI Buffer Controler B
  DDI_BUF_CTL_C 0x0080  DDI Buffer Controler C
  DDI_BUF_CTL_D 0x  DDI Buffer Controler D
  DDI_BUF_CTL_E 0x8002  DDI Buffer Controler E
  PIPE_CONF_A   0x  PIPE Configuration A
  PIPE_CONF_B   0x  PIPE Configuration B
  PIPE_CONF_C   0x  PIPE Configuration C
  PIPE_CONF_EDP 0x  PIPE Configuration EDP
  PIPE_DDI_FUNC_CTL_A   0xc4034002  PIPE DDI Function Control A
  PIPE_DDI_FUNC_CTL_B   0xa0035000  PIPE DDI Function Control B
  PIPE_DDI_FUNC_CTL_C   0x0003  PIPE DDI Function Control C
  PIPE_DDI_FUNC_CTL_EDP 0x0003  PIPE DDI Function Control EDP
  TRANS_CONF0x  Transcoder Configuration
 
  Thanks
  --xingchao
 
  [   16.835658] [ cut here ]
  [   16.835690] WARNING: at drivers/gpu/drm/i915/intel_display.c:1118
  assert_fdi_tx+0x87/0x90 [i915]()
  [   16.835691] Hardware name: Shark Bay Client platform
  [   16.835692] FDI TX state assertion failure (expected off, current on)
  [   16.835706] Modules linked in: snd_seq_midi_event i915(+) snd_seq
  snd_timer drm_kms_helper snd_seq
  _device ghash_clmulni_intel drm aesni_intel snd cryptd mcs7830 usbnet
 joydev
  aes_x86_64 soundcore psm ouse snd_page_alloc hid_generic i2c_algo_bit
  serio_raw video mac_hid microcode lpc_ich lp parport e10 00e usbhid hid
  [   16.835708] Pid: 470, comm: modprobe Not tainted 3.5.0-rc46patches+
 #12
  [   16.835709] Call Trace:
  [   16.835715]  [8105278f] warn_slowpath_common+0x7f/0xc0
  [   16.835718]  [81052886] warn_slowpath_fmt+0x46/0x50
  [   16.835728]  [a01cc847] assert_fdi_tx+0x87/0x90 [i915]
  [   16.835739]  [a01d5cf5] ironlake_crtc_disable+0x185/0x820
 [i915]
  [   16.835748]  [a01d641e] ironlake_crtc_dpms+0x8e/0xa0 [i915]
  [   16.835756]  [a01cdbd8] intel_crtc_dpms+0x48/0x140 [i915]
  [   16.835768]  [a01d49d5] intel_crtc_disable+0x35/0xb0 [i915]
  [   16.835772]  [a012d6a5]

Re: [Intel-gfx] [PATCH] drm/i915: Mark hardware context support optional

2012-09-25 Thread Chris Wilson 
On Tue, 25 Sep 2012 13:35:31 -0700, Ben Widawsky b...@bwidawsk.net wrote:
 On Tue, 25 Sep 2012 20:41:45 +0100
 Chris Wilson ch...@chris-wilson.co.uk wrote:
 
  On Tue, 25 Sep 2012 12:04:14 -0700, Ben Widawsky b...@bwidawsk.net
  wrote:
   On Tue, 25 Sep 2012 14:53:37 +0100
   Chris Wilson ch...@chris-wilson.co.uk wrote:
   
Enable hardware context support for userspace (default:
disabled)));
   
   You've found one platform this doesn't work on, and a bunch of
   features rely on this, and yet we default to disabled? That seems a
   bit harsh to me.
  
  Exactly, it's meant to be harsh. In the limited testing that hw
  contexts have been exposed to, we have a number of hangs for which
  they are implicated. Therefore they are not safe to enable yet...
  Unless you can prove otherwise. :-p
  -Chris
  
 
 The reason I've always resisted a module parameter is that rc6 and
 contexts are tied so very closely together. We've had a number of
 issues around rc6 already, I do not want contexts to be conflated with
 those issues. It's interesting if rc6=0 and failures still occur. I've
 yet to hear of such an issue, but I'd like to know if that's the case
 here.

Disabling rc6 but keeping hw contexts works but regresses performance in
old school games.

rc6=0 hw_contexts=0 - works
rc6=0 hw_contexts=1 - works
rc6=1 hw_contexts=0 - works (current default up to 3.6)
rc6=1 hw_contexts=1 - hard hang with gl (new default in 3.6)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Two GMA 950 issues

2012-09-25 Thread Alan W. Irwin 

I have recently upgraded my Asus Eee b202 box (with 945GM chipset and
GMA 950 graphics core) from Debian stable to Debian testing.

Before I was just using this rather underpowered box as a thin client
(using the X -query method to access a remote box xdm to help log in
to that remote box to actually do my work or play low-end 3D games
such as foobillard).  However, as a test I tried installing KDE on
this box. This new KDE version is much faster than the Debian stable
version so that experiment turned out to be a huge success.  So on the
whole I am completely satisfied with the KDE graphics experience I have
directly on this box.

However, I have noticed two issues with this box that probably indicate
that the software in the Intel graphics driver needs some
additional testing/maintenance for GMA950 graphics cores.

(1) The first issue (full bug report at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688812) is fiddling
with desktop effects (specifically turning the Outline effect off
than on again) brings the GPU to a near halt (it took about a minute
to respond to even hovering the mouse over part of the desktop and
another minute to respond to clicking on the mouse).  I ascribe the
slowdown to the GPU because top showed the cpu was idle and there
was tonnes of free memory available as well. That huge slowdown is
permanent in the sense that logging off and/or (warm) rebooting does
not solve the issue.  The only way out of this trap that I found was
to mv the .kde directory aside and reconfigure everything from
scratch.

(2) The second issue (full bug report at 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688822)

is a regression (when compared to Debian stable) in playing
remote games with LIBGL_ALWAYS_INDIRECT=1 using the X -query method to gain 
access
to a remote box.  Interestingly, I can run those remote games just fine
if I use the ssh method rather than X -query to gain access to
the remote box.

The Eee box was first introduced only 4 years ago so it is fairly
modern equipment.  Also, it might experience a bit of a renaissance
now that it appears sophisticated Linux desktop environments like KDE
appear to run on it with no speed issues at all.  So it would be a
shame if the above bugs were not addressed in some way by the Intel
developers here.

My own feeling is perhaps the best way to deal with such bugs is not
to worry too much about the high-level specifics that triggered them,
but instead do full-blown tests on equipment with GMA 950 graphics
core similar to the tests Intel runs on their latest hardware.  In the
long run, such tests are the only way to make sure the latest Intel
graphics stack works properly on somwhat older equipment like this.

I would be happy to run such comprehensive tests, but this is a
production box (i.e., I am trying to use this box to help develop my
own free software).  I don't mind pausing my own development work to
run the tests, but if setting up such tests is too time-consuming or
would take too much of my time learning about how to build the Intel
graphics stack from scratch, I would prefer someone else to run the
tests instead.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Mark hardware context support optional

2012-09-25 Thread Daniel Vetter 
On Tue, Sep 25, 2012 at 10:46 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 rc6=0 hw_contexts=0 - works
 rc6=0 hw_contexts=1 - works
 rc6=1 hw_contexts=0 - works (current default up to 3.6)
 rc6=1 hw_contexts=1 - hard hang with gl (new default in 3.6)

I think we need that workaround ... Ben, can you hack up what should
be required? Since as soon as we get the first external regression
report I'll pretty much have to disable it by default, which isn't
really great. Dumping an entire 3d setup batch into the kernel looks
like the lesser evil.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: make sure we write all the DIP data bytes

2012-09-25 Thread Daniel Vetter 
On Tue, Sep 25, 2012 at 02:06:30PM -0300, Rodrigo Vivi wrote:
 Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
 
 On Tue, Sep 25, 2012 at 1:23 PM, Paulo Zanoni przan...@gmail.com wrote:
  From: Paulo Zanoni paulo.r.zan...@intel.com
 
  ... even if the actual infoframe is smaller than the maximum possible
  size.
 
  If we don't write all the 32 DIP data bytes the InfoFrame ECC may not
  be correctly calculated in some cases (e.g., when changing the port),
  and this will lead to black screens on HDMI monitors. The ECC value is
  generated by the hardware.
 
  I don't see how this should break anything since we're writing 0 and
  that should be the correct value, so this patch should be safe.
 
  Notice that on IVB and older we actually have 64 bytes available for
  VIDEO_DIP_DATA, but only bytes 0-31 actually store infoframe data: the
  others are either read-only ECC values or marked as reserved. On HSW
  we only have 32 bytes, and the ECC value is stored on its own separate
  read-only register. See BSpec.
 
  This patch fixes bug #46761, which is marked as a regression
  introduced by commit 4e89ee174bb2da341bf90a84321c7008a3c9210d:
  drm/i915: set the DIP port on ibx_write_infoframe
 
  Before commit 4e89 we were just failing to send AVI infoframes when we
  needed to change the port, which can lead to black screens in some
  cases. After commit 4e89 we started sending infoframes, but with a
  possibly wrong ECC value. After this patch I hope we start sending
  correct infoframes.
 
  Version 2:
- Improve commit message
- Try to make the code more clear
 
  Cc: sta...@vger.kernel.org
  Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46761
  Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com

Applied to -fixes, although I guess I'll push this through 3.7 -
infoframes blow up too often.
-Daniel
  ---
   drivers/gpu/drm/i915/i915_reg.h   |4 
   drivers/gpu/drm/i915/intel_hdmi.c |   15 +++
   2 files changed, 19 insertions(+)
 
  diff --git a/drivers/gpu/drm/i915/i915_reg.h 
  b/drivers/gpu/drm/i915/i915_reg.h
  index a828e90..7637824 100644
  --- a/drivers/gpu/drm/i915/i915_reg.h
  +++ b/drivers/gpu/drm/i915/i915_reg.h
  @@ -1794,6 +1794,10 @@
 
   /* Video Data Island Packet control */
   #define VIDEO_DIP_DATA 0x61178
  +/* Read the description of VIDEO_DIP_DATA (before Haswel) or VIDEO_DIP_ECC
  + * (Haswell and newer) to see which VIDEO_DIP_DATA byte corresponds to 
  each byte
  + * of the infoframe structure specified by CEA-861. */
  +#define   VIDEO_DIP_DATA_SIZE  32
   #define VIDEO_DIP_CTL  0x61170
   /* Pre HSW: */
   #define   VIDEO_DIP_ENABLE (1  31)
  diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
  b/drivers/gpu/drm/i915/intel_hdmi.c
  index f9fb47c..08f2b63 100644
  --- a/drivers/gpu/drm/i915/intel_hdmi.c
  +++ b/drivers/gpu/drm/i915/intel_hdmi.c
  @@ -151,6 +151,9 @@ static void g4x_write_infoframe(struct drm_encoder 
  *encoder,
  I915_WRITE(VIDEO_DIP_DATA, *data);
  data++;
  }
  +   /* Write every possible data byte to force correct ECC calculation. 
  */
  +   for (; i  VIDEO_DIP_DATA_SIZE; i += 4)
  +   I915_WRITE(VIDEO_DIP_DATA, 0);
  mmiowb();
 
  val |= g4x_infoframe_enable(frame);
  @@ -186,6 +189,9 @@ static void ibx_write_infoframe(struct drm_encoder 
  *encoder,
  I915_WRITE(TVIDEO_DIP_DATA(intel_crtc-pipe), *data);
  data++;
  }
  +   /* Write every possible data byte to force correct ECC calculation. 
  */
  +   for (; i  VIDEO_DIP_DATA_SIZE; i += 4)
  +   I915_WRITE(TVIDEO_DIP_DATA(intel_crtc-pipe), 0);
  mmiowb();
 
  val |= g4x_infoframe_enable(frame);
  @@ -224,6 +230,9 @@ static void cpt_write_infoframe(struct drm_encoder 
  *encoder,
  I915_WRITE(TVIDEO_DIP_DATA(intel_crtc-pipe), *data);
  data++;
  }
  +   /* Write every possible data byte to force correct ECC calculation. 
  */
  +   for (; i  VIDEO_DIP_DATA_SIZE; i += 4)
  +   I915_WRITE(TVIDEO_DIP_DATA(intel_crtc-pipe), 0);
  mmiowb();
 
  val |= g4x_infoframe_enable(frame);
  @@ -259,6 +268,9 @@ static void vlv_write_infoframe(struct drm_encoder 
  *encoder,
  I915_WRITE(VLV_TVIDEO_DIP_DATA(intel_crtc-pipe), *data);
  data++;
  }
  +   /* Write every possible data byte to force correct ECC calculation. 
  */
  +   for (; i  VIDEO_DIP_DATA_SIZE; i += 4)
  +   I915_WRITE(VLV_TVIDEO_DIP_DATA(intel_crtc-pipe), 0);
  mmiowb();
 
  val |= g4x_infoframe_enable(frame);
  @@ -292,6 +304,9 @@ static void hsw_write_infoframe(struct drm_encoder 
  *encoder,
  I915_WRITE(data_reg + i, *data);
  data++;
  }
  +   /* Write every possible data byte to force correct ECC calculation. 
  */
  +   for (; i

[Intel-gfx] [QA 09/26] Testing report for `drm-intel-testing` (was: Updated -testing)

2012-09-25 Thread Sun, Yi 
Summary

We finished a new round of kernel testing. Generally, in this circle, 5 bugs 
are closed, 17 bugs are still open. Especially, 4 new filed bugs, and 2 
re-opened bugs.



Test Environment

Kernel: (drm-intel-testing)7ce7b92e4aec3af4fbc56ff6e87a8b55d2362ec1

Some additional commit info:

Merge: 853c70e b98b601

Author: Daniel Vetter daniel.vet...@ffwll.ch

Date:   Thu Sep 20 15:20:38 2012 +0200



Hardware

We covered the platform of IvyBridge, SandyBridge, IronLake,G45 and Pineview



Findings

Reopened bugs:

Bug 50569 - [ILK] System reboot after S4

Bug 54764 - [ILK regression] DP display some mode not able to light up



New bugs:

Bug 55268 - [SNB] eDP can't light up after reboot with micro HDMI

Bug 55271 - [ILK regression] DP fail to light up after S4 with X and glxgears

Bug 55276 - [SNB regression]some dp display modes can't light up

Bug 55304 - [Regression ILK]I-G-T/debugfs_reader fail with Call Trace



Closed bugs:

Bug 50823 - [IVB]EDP can't show all modes correctly

Bug 51055 - [IVB]I-G-T/gem_tiled_blits fails while running two or more times

Bug 51493 - [ILK] Prefer mode(2560x1600) can't light up for the second time 
with DP external display connected

Bug 54410 - [IVB regression]I-G-T/gem_tiled_pread_pwrite failed

Bug 55040 - [IVB]I-G-T/module_reload fails with NVDIA video card enabled



Old open bugs

Bug 36997 - [G45] TV can't display after loading drm driver

Bug 41976 - [IVB] screen turn to be black while switching between console and 
x-window with 3-pipe active

Bug 42194 - [IVB/SNB] coldplug new monitors for fbcon on lastclose()

Bug 45729 - [bisected regression] Incorrect Mode Timing on DP Display, with 
3.3-rc (due to interlaced CEA modes)

Bug 47034 - [G45] mode set failure with testdisplay, low resolution modes fail 
and display doesn't come back

Bug 50069 - [IVB]I-G-T/flip_test never finish

Bug 51677 - [IVB] Running module_reload after calling function drm_open_any() 
will cause GPU hang

Bug 51975 - [IVB]can't find the HDMI audio device

Bug 52424 - [Bisected SNB Regression] glxgears causes GPU hung

Bug 54111 - [IVB]I-G-T/module_reload fail with *ERROR* Memory manager not 
clean. Delaying takedown

Bug 54253 - [SNB]eDP can't work while booting with miniVGA



Thanks

 --Sun, Yi

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx