date:20121016

[Intel-gfx] why two vertex buffers ?

2012-10-16 Thread baisheng_wang

 Dear All,

In intel 3D driver, It seems there are two vertex buffers： one is struct 
intel_buffer_object (VBO), which catches all vertex
building and drawing commands, such as glVertex3f; Another is struct prim in 
struct intel_context, into which functions like intel_draw_triangle 
accumulate vertex. So why exist two vertex buffers? What's the difference ?

Thanks,
Jacky

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

Re: [Intel-gfx] [PATCH 3/4] drm/i915: ILK also needs that last fix

2012-10-16 Thread Daniel Vetter

On Mon, Oct 15, 2012 at 08:21:41PM -0700, Ben Widawsky wrote:
On Mon, 15 Oct 2012 20:59:22 +0200
Daniel Vetter dan...@ffwll.ch wrote:

On Wed, Oct 03, 2012 at 07:34:23PM -0700, Ben Widawsky wrote:
That fix was the disable render deptch cache pipeline flush

Signed-off-by: Ben Widawsky b...@bwidawsk.net

I've stumbled over the same one, but my docs here suggest i965g/gm45
need it, too:

http://cgit.freedesktop.org/~danvet/drm/commit/?h=ilk-wa-pileid=37c4c82b8cdbcf5adccad97f0b45747ba37ed659

Have you checked whether we don't need this on ivb/vlv/hsw, too?

I did check whether the windows driver does it for those platforms, and
the answer is no. So the answer to your question is maybe because who
knows what exists in some other doc somewhere in the metaverse. I think
this is a good enough start though since it seems SNB was definitely a
bit buggier than IVB.

Yeah, I've noticed while checking w/as that they're not consistently named
on older platforms. E.g. the above definitely exists on eaglelake, too,
but named slightly different. So the w/a db doesn't pick up all uses.
Hoooray!

Also, for w/a patches based on the vpg w/a database, please include
the vpg w/a name tag both in the commit message and in a code comment
somewhere.

Good idea. If you're okay with longer commit message subjects, I'd even
suggest putting it there to make it even a bit easier to search for.

Yeah, I'm fine with putting it into the commit head, I've put it there
myself. If the w/a only affects one platform we could try to squeeze the
platform name into the headline, too. But having to read the commit
message for that doesn't really hurt, either.
-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: Don't delete DPLL Multiplier during DAC init.

2012-10-16 Thread Daniel Vetter

On Sun, Oct 14, 2012 at 04:33:11PM +0200, Egbert Eich wrote:
 The DPLL multipiler is set up in intel_display.c:i9xx_update_pll()
 called from i9xx_crtc_mode_set().
 There the DPLL multiplier is adjusted so that the SDVO gets a sufficient
 bus clock.
 When cloning a CRTC between an SDVO driven encoder and the standard
 DAC the DAC setup code reseted the multiplier value to 1 thus undoing
 the correct setup. There is no need to touch the multiplier in the DAC
 setup code: the correct value (i.e. 1 in case no SDVO encoder is used)
 is set by i9xx_update_pll() already.
 A comment at the code suggested that this code is a left over from the
 days when there was no setup for clone modes.
 
 Signed-off-by: Egbert Eich e...@suse.de
Picked up for -fixes, thanks for the patch.
-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: Add QUIRK_INVERT_BRIGHTNESS for NCR machines.

2012-10-16 Thread Daniel Vetter

On Sun, Oct 14, 2012 at 03:46:38PM +0200, Egbert Eich wrote:
 NCR machines with LVDS panels using Intel chipsets need to have the
 QUIRK_INVERT_BRIGHTNESS bit set.
 Unfortunately NCR doesn't set a meaningful subvendor/subdevice ID,
 therefore we add a DMI dependent quirk list.
 
 Signed-off-by: Egbert Eich e...@suse.de

Meh, I've hoped that this invert-brightness quirk would just disappear.
Looks like it's here to stay. Thanks for the patch, applied to -fixes.
-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: Don't clone SDVO LVDS with analog.

2012-10-16 Thread Daniel Vetter

On Sat, Oct 13, 2012 at 02:30:15PM +0200, Egbert Eich wrote:
 SDVO LVDS are not clonable as the input mode gets adjusted by
 the LVDS encoder.
 
 Signed-off-by: Egbert Eich e...@suse.de

Imo cloning should simply die outright. Patch applied, thanks.
-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: Restore sdvo_flags after dtd-mode-dtd Roundrtrip.

2012-10-16 Thread Daniel Vetter

On Sat, Oct 13, 2012 at 02:29:31PM +0200, Egbert Eich wrote:
 For TV and LVDS encoders intel_sdvo_set_input_timings_for_mode()
 is called to pass a mode to the sdvo chip and retrieve a dtd
 containing information needed to calculate the adjusted_mode which
 is done by intel_sdvo_get_dtd_from_mode().
 To set this adjusted_mode as input mode for the sdvo chip, a dtd is
 recalculated using intel_sdvo_get_mode_from_dtd(). During this round
 trip the sdvo_flags contained in the dtd obtained from the hardware
 are lost.
 Since these flags cannot be ignored in all cases this patch preserves
 and restores them.
 
 This regression has been introduced in
 
 commit 6651819b4b4fc3caa6964c5d825eb4bb996f3905
 Author: Daniel Vetter daniel.vet...@ffwll.ch
 Date:   Sun Apr 1 19:16:18 2012 +0200
 
 drm/i915: handle input/output sdvo timings separately in mode_set
 
 Signed-off-by: Egbert Eich e...@suse.de

Long term we need to decently improve our adjusted_mode handling and stop
shoveling random state into random structures. Short-term this looks good
enough. Thanks for the patch, applied.
-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] IVB-eDP regression with on latest git

2012-10-16 Thread Daniel Vetter

On Mon, Oct 15, 2012 at 09:07:33PM +0200, Oleksij Rempel wrote:
 I'll repost it, looks like last message got lost.
 
 Am 14.10.2012 14:49, schrieb Oleksij Rempel:
 Am 14.10.2012 10:55, schrieb Daniel Vetter:
 On Sun, Oct 14, 2012 at 9:18 AM, Oleksij Rempel
 bug-tr...@fisher-privat.net wrote:
 With latest kernel (vanilla/master, or intel.drm-next) i do not have
 image
 on build in screen (eDP). Hardware Asus Zenbook UX32A. Vendor: 0x8086,
 Device: 0x0166, Revision: 0x09 (??)
 Is it know issue?
 
 Nope, this is a new one. Can you grab the dmesg with drm.debug=0xe of
 the broken kernel please? Also, a bisect usually helps a lot, too.
 
 Thanks, Daniel
 
 
 
 I can't access this laptop with broken kernel.
 
 The patch caused this regression is:
 commit 2477367083b3eaa97f87993ab26627a02f350551
 Author: Chris Wilson ch...@chris-wilson.co.uk
 Date:   Wed Sep 26 16:48:30 2012 +0100
 
  drm/i915: Try harder to complete DP training pattern 1
 
  In commit cdb0e95bf571dccc1f75fef9bdad21b167ef0b37
  Author: Keith Packard kei...@keithp.com
  Date:   Tue Nov 1 20:00:06 2011 -0700
 
  drm/i915: Try harder during dp pattern 1 link training
 
  extra passes were made to retry the same voltage and then retry a full
  clock reset. However, as coverity pointed out, we never tried the full
  clock reset as we broke out of the loop early.
 
  Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
  Reviewed-by: Damien Lespiau damien.lesp...@intel.com
 
 
 Reverting it makes laptop work again.

Ok, I've reverted this in -fixes, we need to think a bit more about our dp
link training for -next. Thanks a lot for reporting and bisecting this
regression.

Yours, 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 02/14] drm/i915: add intel_ddi_set_pipe_settings

2012-10-16 Thread Jani Nikula

On Mon, 15 Oct 2012, Paulo Zanoni przan...@gmail.com wrote:
 From: Paulo Zanoni paulo.r.zan...@intel.com

 In theory, all the DDI pipe settings should be set here, including
 timing and M/N registers. For now, let's just set the DP MSA
 attributes.

 Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
 ---
  drivers/gpu/drm/i915/i915_reg.h  | 10 ++
  drivers/gpu/drm/i915/intel_ddi.c | 34 ++
  drivers/gpu/drm/i915/intel_display.c |  4 +++-
  drivers/gpu/drm/i915/intel_drv.h |  1 +
  4 files changed, 48 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
 index 8200c31..7ca8b7d 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -4533,6 +4533,16 @@
  #define  PIPE_CLK_SEL_DISABLED   (0x029)
  #define  PIPE_CLK_SEL_PORT(x)((x+1)29)
  
 +#define _PIPEA_MSA_MISC  0x60410
 +#define _PIPEB_MSA_MISC  0x61410
 +#define PIPE_MSA_MISC(pipe) _PIPE(pipe, _PIPEA_MSA_MISC, _PIPEB_MSA_MISC)
 +#define  PIPE_MSA_SYNC_CLK   (10)
 +#define  PIPE_MSA_6_BPC  (05)
 +#define  PIPE_MSA_8_BPC  (15)
 +#define  PIPE_MSA_10_BPC (25)
 +#define  PIPE_MSA_12_BPC (35)
 +#define  PIPE_MSA_16_BPC (35)

This should be (45) per DP 1.2a. Not that it matters now, unused as it
is.

BR,
Jani.

 +
  /* LCPLL Control */
  #define LCPLL_CTL0x130040
  #define  LCPLL_PLL_DISABLE   (131)
 diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
 b/drivers/gpu/drm/i915/intel_ddi.c
 index 9659c227..e58df71 100644
 --- a/drivers/gpu/drm/i915/intel_ddi.c
 +++ b/drivers/gpu/drm/i915/intel_ddi.c
 @@ -827,6 +827,40 @@ bool intel_ddi_pll_mode_set(struct drm_crtc *crtc, int 
 clock)
   return true;
  }
  
 +void intel_ddi_set_pipe_settings(struct drm_crtc *crtc)
 +{
 + struct drm_i915_private *dev_priv = crtc-dev-dev_private;
 + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 + struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
 + enum pipe pipe = intel_crtc-pipe;
 + int type = intel_encoder-type;
 + uint32_t temp;
 +
 + if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
 +
 + temp = PIPE_MSA_SYNC_CLK;
 + switch (intel_crtc-bpp) {
 + case 18:
 + temp |= PIPE_MSA_6_BPC;
 + break;
 + case 24:
 + temp |= PIPE_MSA_8_BPC;
 + break;
 + case 30:
 + temp |= PIPE_MSA_10_BPC;
 + break;
 + case 36:
 + temp |= PIPE_MSA_12_BPC;
 + break;
 + default:
 + temp |= PIPE_MSA_8_BPC;
 + WARN(1, %d bpp unsupported by pipe DDI function\n,
 +  intel_crtc-bpp);
 + }
 + I915_WRITE(PIPE_MSA_MISC(pipe), temp);
 + }
 +}
 +
  void intel_ddi_enable_pipe_func(struct drm_crtc *crtc)
  {
   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 705ed80..f48986b9 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -3218,8 +3218,10 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
*/
   intel_crtc_load_lut(crtc);
  
 - if (IS_HASWELL(dev))
 + if (IS_HASWELL(dev)) {
 + intel_ddi_set_pipe_settings(crtc);
   intel_ddi_enable_pipe_func(crtc);
 + }
  
   intel_enable_pipe(dev_priv, pipe, is_pch_port);
   intel_enable_plane(dev_priv, plane, pipe);
 diff --git a/drivers/gpu/drm/i915/intel_drv.h 
 b/drivers/gpu/drm/i915/intel_drv.h
 index 7e1e670..ed75a36 100644
 --- a/drivers/gpu/drm/i915/intel_drv.h
 +++ b/drivers/gpu/drm/i915/intel_drv.h
 @@ -597,5 +597,6 @@ extern bool intel_ddi_pll_mode_set(struct drm_crtc *crtc, 
 int clock);
  extern void intel_ddi_pre_enable(struct intel_encoder *intel_encoder);
  extern void intel_ddi_post_disable(struct intel_encoder *intel_encoder);
  extern void intel_ddi_put_crtc_pll(struct drm_crtc *crtc);
 +extern void intel_ddi_set_pipe_settings(struct drm_crtc *crtc);
  
  #endif /* __INTEL_DRV_H__ */
 -- 
 1.7.11.4

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

[Intel-gfx] [PATCH] drm/i915: Set DERRMR around batches required vblank events

2012-10-16 Thread Chris Wilson

In order for the Display Engine to send messages to the Render Engine,
that event must be unmasked in the Display Engine Render Response Mask
Register (DERRMR). By default all events are masked to prevent unwanted
messages to conserve power, and it is strongly recommended that only
single events be unmasked at any time. So in order to pipeline the
register writes around individual batchbuffers, userspace must notify
the kernel when it requires a vblank event, this patch implements an
interface to do so with an single (pipe, event) request through the
execbuffer flags.

Note that another workaround is required for IVB, in that we must also
prevent RC6 sleeps whilst waiting upon an event. To do that we also
pipeline a forcewake into the second MT slot.

There are a few unpleasant issues addressed by the patch. The first is
to only allow a single ring to process vsync requests at any time. This
is really a non-issue as the current hardware can only process those
requests on a single ring, but by serialising between rings we should
prevent our future selves from shooting their feet. The second ugly
issue is to handle unwind failures by disabling signals whilst queueing
a vsync request, perhaps a pleasant side-effect. The last issue is the
trick to enable vblank irqs which relies on the deferred vblank put.

References: https://bugs.freedesktop.org/show_bug.cgi?id=50244
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---

I am still not convinced this fixes anything as at the moment I am
simply unable to detect any tearing on my ivb setup if I apply any form of
vblank throttling.

The other issue is that I think if I had a SECURE
(DRM_MASTER|DRM_ROOT_ONLY) batch buffer I could probably do all of this
in userspace.
-Chris

---
 drivers/gpu/drm/i915/i915_dma.c|3 ++
 drivers/gpu/drm/i915/i915_drv.h|3 ++
 drivers/gpu/drm/i915/i915_gem.c|2 +
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   76 
 drivers/gpu/drm/i915/i915_reg.h|1 +
 include/drm/i915_drm.h |   17 +++
 6 files changed, 102 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5779e8f..759a5e6 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1015,6 +1015,9 @@ static int i915_getparam(struct drm_device *dev, void 
*data,
case I915_PARAM_HAS_PRIME_VMAP_FLUSH:
value = 1;
break;
+   case I915_PARAM_HAS_EXEC_VSYNC:
+   value = 1;
+   break;
default:
DRM_DEBUG_DRIVER(Unknown parameter %d\n,
 param-param);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index dda10c1..db2ca9f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -434,6 +434,9 @@ typedef struct drm_i915_private {
struct intel_ring_buffer ring[I915_NUM_RINGS];
uint32_t next_seqno;
 
+   struct intel_ring_buffer *vsync_ring;
+   uint32_t vsync_seqno;
+
drm_dma_handle_t *status_page_dmah;
uint32_t counter;
struct drm_i915_gem_object *pwrctx;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f740535..7a5ab2c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2643,6 +2643,8 @@ int i915_gpu_idle(struct drm_device *dev)
return ret;
}
 
+   dev_priv-vsync_ring = NULL;
+   dev_priv-vsync_seqno = 0;
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index bcd5aa2..021b967 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -807,6 +807,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
   struct drm_i915_gem_exec_object2 *exec)
 {
drm_i915_private_t *dev_priv = dev-dev_private;
+   bool was_interruptible = dev_priv-mm.interruptible;
struct list_head objects;
struct eb_objects *eb;
struct drm_i915_gem_object *batch_obj;
@@ -1044,6 +1045,62 @@ i915_gem_do_execbuffer(struct drm_device *dev, void 
*data,
goto err;
}
 
+   if (args-flags  I915_EXEC_VSYNC_ENABLE  INTEL_INFO(dev)-gen = 6) {
+   u32 pipe, event;
+
+   if (dev_priv-vsync_seqno  dev_priv-vsync_ring != ring) {
+   ret = i915_wait_seqno(dev_priv-vsync_ring,
+ dev_priv-vsync_seqno);
+   if (ret)
+   goto err;
+
+   dev_priv-vsync_ring = NULL;
+   dev_priv-vsync_seqno = 0;
+   }
+
+   pipe = I915_EXEC_VSYNC_GET_PIPE(args-flags);
+   event =

Re: [Intel-gfx] [PATCH 01/14] drm/i915: add DP support to intel_ddi_enable_pipe_func

2012-10-16 Thread Jani Nikula

On Mon, 15 Oct 2012, Paulo Zanoni przan...@gmail.com wrote:
 From: Paulo Zanoni paulo.r.zan...@intel.com

Reviewed-by: Jani Nikula jani.nik...@intel.com


 Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
 ---
  drivers/gpu/drm/i915/intel_ddi.c | 34 ++
  drivers/gpu/drm/i915/intel_dp.c  |  5 -
  drivers/gpu/drm/i915/intel_drv.h |  5 +
  3 files changed, 35 insertions(+), 9 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
 b/drivers/gpu/drm/i915/intel_ddi.c
 index a78860a..9659c227 100644
 --- a/drivers/gpu/drm/i915/intel_ddi.c
 +++ b/drivers/gpu/drm/i915/intel_ddi.c
 @@ -831,8 +831,10 @@ void intel_ddi_enable_pipe_func(struct drm_crtc *crtc)
  {
   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
   struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
 + struct drm_encoder *encoder = intel_encoder-base;
   struct drm_i915_private *dev_priv = crtc-dev-dev_private;
   enum pipe pipe = intel_crtc-pipe;
 + int type = intel_encoder-type;
   uint32_t temp;
  
   /* Enable PIPE_DDI_FUNC_CTL for the pipe to work in HDMI mode */
 @@ -861,9 +863,8 @@ void intel_ddi_enable_pipe_func(struct drm_crtc *crtc)
   if (crtc-mode.flags  DRM_MODE_FLAG_PHSYNC)
   temp |= PIPE_DDI_PHSYNC;
  
 - if (intel_encoder-type == INTEL_OUTPUT_HDMI) {
 - struct intel_hdmi *intel_hdmi =
 - enc_to_intel_hdmi(intel_encoder-base);
 + if (type == INTEL_OUTPUT_HDMI) {
 + struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
  
   if (intel_hdmi-has_hdmi_sink)
   temp |= PIPE_DDI_MODE_SELECT_HDMI;
 @@ -871,9 +872,34 @@ void intel_ddi_enable_pipe_func(struct drm_crtc *crtc)
   temp |= PIPE_DDI_MODE_SELECT_DVI;
  
   temp |= PIPE_DDI_SELECT_PORT(intel_hdmi-ddi_port);
 - } else if (intel_encoder-type == INTEL_OUTPUT_ANALOG) {
 +
 + } else if (type == INTEL_OUTPUT_ANALOG) {
   temp |= PIPE_DDI_MODE_SELECT_FDI;
   temp |= PIPE_DDI_SELECT_PORT(PORT_E);
 +
 + } else if (type == INTEL_OUTPUT_DISPLAYPORT ||
 +type == INTEL_OUTPUT_EDP) {
 + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
 +
 + temp |= PIPE_DDI_MODE_SELECT_DP_SST;
 + temp |= PIPE_DDI_SELECT_PORT(intel_dp-port);
 +
 + switch (intel_dp-lane_count) {
 + case 1:
 + temp |= PIPE_DDI_PORT_WIDTH_X1;
 + break;
 + case 2:
 + temp |= PIPE_DDI_PORT_WIDTH_X2;
 + break;
 + case 4:
 + temp |= PIPE_DDI_PORT_WIDTH_X4;
 + break;
 + default:
 + temp |= PIPE_DDI_PORT_WIDTH_X4;
 + WARN(1, Unsupported lane count %d\n,
 +  intel_dp-lane_count);
 + }
 +
   } else {
   WARN(1, Invalid encoder type %d for pipe %d\n,
intel_encoder-type, pipe);
 diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
 index fcce392..871bc17 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -77,11 +77,6 @@ static bool is_cpu_edp(struct intel_dp *intel_dp)
   return is_edp(intel_dp)  !is_pch_edp(intel_dp);
  }
  
 -static struct intel_dp *enc_to_intel_dp(struct drm_encoder *encoder)
 -{
 - return container_of(encoder, struct intel_dp, base.base);
 -}
 -
  static struct intel_dp *intel_attached_dp(struct drm_connector *connector)
  {
   return container_of(intel_attached_encoder(connector),
 diff --git a/drivers/gpu/drm/i915/intel_drv.h 
 b/drivers/gpu/drm/i915/intel_drv.h
 index 245319a..7e1e670 100644
 --- a/drivers/gpu/drm/i915/intel_drv.h
 +++ b/drivers/gpu/drm/i915/intel_drv.h
 @@ -474,6 +474,11 @@ static inline struct intel_encoder 
 *intel_attached_encoder(struct drm_connector
   return to_intel_connector(connector)-encoder;
  }
  
 +static inline struct intel_dp *enc_to_intel_dp(struct drm_encoder *encoder)
 +{
 + return container_of(encoder, struct intel_dp, base.base);
 +}
 +
  extern void intel_connector_attach_encoder(struct intel_connector *connector,
  struct intel_encoder *encoder);
  extern struct drm_encoder *intel_best_encoder(struct drm_connector 
 *connector);
 -- 
 1.7.11.4

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

Re: [Intel-gfx] [PATCH 04/14] drm/i915: add DP support to intel_ddi_disable_port

2012-10-16 Thread Jani Nikula

On Mon, 15 Oct 2012, Paulo Zanoni przan...@gmail.com wrote:
 From: Paulo Zanoni paulo.r.zan...@intel.com

 Just a missing register. There is no problem to run this code when the
 output is HDMI.

Reviewed-by: Jani Nikula jani.nik...@intel.com


 Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
 ---
  drivers/gpu/drm/i915/intel_ddi.c | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

 diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
 b/drivers/gpu/drm/i915/intel_ddi.c
 index 5071370..4f03b1b 100644
 --- a/drivers/gpu/drm/i915/intel_ddi.c
 +++ b/drivers/gpu/drm/i915/intel_ddi.c
 @@ -1105,14 +1105,23 @@ void intel_ddi_post_disable(struct intel_encoder 
 *intel_encoder)
   struct drm_i915_private *dev_priv = encoder-dev-dev_private;
   enum port port = intel_ddi_get_encoder_port(intel_encoder);
   uint32_t val;
 + bool wait = false;
  
   val = I915_READ(DDI_BUF_CTL(port));
   if (val  DDI_BUF_CTL_ENABLE) {
   val = ~DDI_BUF_CTL_ENABLE;
   I915_WRITE(DDI_BUF_CTL(port), val);
 - intel_wait_ddi_buf_idle(dev_priv, port);
 + wait = true;
   }
  
 + val = I915_READ(DP_TP_CTL(port));
 + val = ~(DP_TP_CTL_ENABLE | DP_TP_CTL_LINK_TRAIN_MASK);
 + val |= DP_TP_CTL_LINK_TRAIN_PAT1;
 + I915_WRITE(DP_TP_CTL(port), val);
 +
 + if (wait)
 + intel_wait_ddi_buf_idle(dev_priv, port);
 +
   I915_WRITE(PORT_CLK_SEL(port), PORT_CLK_SEL_NONE);
  }
  
 -- 
 1.7.11.4

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

Re: [Intel-gfx] [PATCH 06/14] drm/i915: add basic Haswell DP link train bits

2012-10-16 Thread Jani Nikula

On Mon, 15 Oct 2012, Paulo Zanoni przan...@gmail.com wrote:
 From: Paulo Zanoni paulo.r.zan...@intel.com

 Previously, the DP register was used for everything. On Haswell, it
 was split into DDI_BUF_CTL (which is the new intel_dp-DP register)
 and DP_TP_CTL.

 The logic behind this patch is based on a patch written by Shobhit
 Kumar, but the way the code was written is very different.

 Credits-to: Shobhit Kumar shobhit.ku...@intel.com
 Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
 ---
  drivers/gpu/drm/i915/i915_reg.h |   4 ++
  drivers/gpu/drm/i915/intel_dp.c | 104 
 +---
  2 files changed, 102 insertions(+), 6 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
 index 7ca8b7d..68ce163 100644
 --- a/drivers/gpu/drm/i915/i915_reg.h
 +++ b/drivers/gpu/drm/i915/i915_reg.h
 @@ -4426,12 +4426,16 @@
  #define  DP_TP_CTL_LINK_TRAIN_MASK   (78)
  #define  DP_TP_CTL_LINK_TRAIN_PAT1   (08)
  #define  DP_TP_CTL_LINK_TRAIN_PAT2   (18)
 +#define  DP_TP_CTL_LINK_TRAIN_PAT3   (48)
 +#define  DP_TP_CTL_LINK_TRAIN_IDLE   (28)
  #define  DP_TP_CTL_LINK_TRAIN_NORMAL (38)
 +#define  DP_TP_CTL_SCRAMBLE_DISABLE  (17)
  
  /* DisplayPort Transport Status */
  #define DP_TP_STATUS_A   0x64044
  #define DP_TP_STATUS_B   0x64144
  #define DP_TP_STATUS(port) _PORT(port, DP_TP_STATUS_A, DP_TP_STATUS_B)
 +#define  DP_TP_STATUS_IDLE_DONE  (125)
  #define  DP_TP_STATUS_AUTOTRAIN_DONE (112)
  
  /* DDI Buffer Control */
 diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
 index 3fa71cd..b10f35b 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -1476,7 +1476,19 @@ intel_dp_pre_emphasis_max(struct intel_dp *intel_dp, 
 uint8_t voltage_swing)
  {
   struct drm_device *dev = intel_dp-base.base.dev;
  
 - if (IS_GEN7(dev)  is_cpu_edp(intel_dp)  !IS_VALLEYVIEW(dev)) {
 + if (IS_HASWELL(dev)) {
 + switch (voltage_swing  DP_TRAIN_VOLTAGE_SWING_MASK) {
 + case DP_TRAIN_VOLTAGE_SWING_400:
 + return DP_TRAIN_PRE_EMPHASIS_9_5;
 + case DP_TRAIN_VOLTAGE_SWING_600:
 + return DP_TRAIN_PRE_EMPHASIS_6;
 + case DP_TRAIN_VOLTAGE_SWING_800:
 + return DP_TRAIN_PRE_EMPHASIS_3_5;
 + case DP_TRAIN_VOLTAGE_SWING_1200:
 + default:
 + return DP_TRAIN_PRE_EMPHASIS_0;
 + }
 + } else if (IS_GEN7(dev)  is_cpu_edp(intel_dp)  !IS_VALLEYVIEW(dev)) 
 {
   switch (voltage_swing  DP_TRAIN_VOLTAGE_SWING_MASK) {
   case DP_TRAIN_VOLTAGE_SWING_400:
   return DP_TRAIN_PRE_EMPHASIS_6;
 @@ -1630,6 +1642,40 @@ intel_gen7_edp_signal_levels(uint8_t train_set)
   }
  }
  
 +/* Gen7.5's (HSW) DP voltage swing and pre-emphasis control */
 +static uint32_t
 +intel_dp_signal_levels_hsw(uint8_t train_set)
 +{
 + int signal_levels = train_set  (DP_TRAIN_VOLTAGE_SWING_MASK |
 +  DP_TRAIN_PRE_EMPHASIS_MASK);
 + switch (signal_levels) {
 + case DP_TRAIN_VOLTAGE_SWING_400 | DP_TRAIN_PRE_EMPHASIS_0:
 + return DDI_BUF_EMP_400MV_0DB_HSW;
 + case DP_TRAIN_VOLTAGE_SWING_400 | DP_TRAIN_PRE_EMPHASIS_3_5:
 + return DDI_BUF_EMP_400MV_3_5DB_HSW;
 + case DP_TRAIN_VOLTAGE_SWING_400 | DP_TRAIN_PRE_EMPHASIS_6:
 + return DDI_BUF_EMP_400MV_6DB_HSW;
 + case DP_TRAIN_VOLTAGE_SWING_400 | DP_TRAIN_PRE_EMPHASIS_9_5:
 + return DDI_BUF_EMP_400MV_9_5DB_HSW;
 +
 + case DP_TRAIN_VOLTAGE_SWING_600 | DP_TRAIN_PRE_EMPHASIS_0:
 + return DDI_BUF_EMP_600MV_0DB_HSW;
 + case DP_TRAIN_VOLTAGE_SWING_600 | DP_TRAIN_PRE_EMPHASIS_3_5:
 + return DDI_BUF_EMP_600MV_3_5DB_HSW;
 + case DP_TRAIN_VOLTAGE_SWING_600 | DP_TRAIN_PRE_EMPHASIS_6:
 + return DDI_BUF_EMP_600MV_6DB_HSW;
 +
 + case DP_TRAIN_VOLTAGE_SWING_800 | DP_TRAIN_PRE_EMPHASIS_0:
 + return DDI_BUF_EMP_800MV_0DB_HSW;
 + case DP_TRAIN_VOLTAGE_SWING_800 | DP_TRAIN_PRE_EMPHASIS_3_5:
 + return DDI_BUF_EMP_800MV_3_5DB_HSW;
 + default:
 + DRM_DEBUG_KMS(Unsupported voltage swing/pre-emphasis level:
 +   0x%x\n, signal_levels);
 + return DDI_BUF_EMP_400MV_0DB_HSW;
 + }
 +}
 +
  static uint8_t
  intel_get_lane_status(uint8_t link_status[DP_LINK_STATUS_SIZE],
 int lane)
 @@ -1686,8 +1732,44 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
   struct drm_device *dev = intel_dp-base.base.dev;
   struct drm_i915_private *dev_priv = dev-dev_private;
   int ret;
 + uint32_t temp;
  
 - if (HAS_PCH_CPT(dev)  (IS_GEN7(dev) || !is_cpu_edp(intel_dp))) {
 + if (IS_HASWELL(dev)) {
 + temp =

Re: [Intel-gfx] [PATCH 07/14] drm/i915: use TU_SIZE macro at intel_dp_set_m_n

2012-10-16 Thread Jani Nikula

On Mon, 15 Oct 2012, Paulo Zanoni przan...@gmail.com wrote:
 From: Paulo Zanoni paulo.r.zan...@intel.com

 Much simpler and looks more like the M/N code inside intel_display.c.

Reviewed-by: Jani Nikula jani.nik...@intel.com


 Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
 ---
  drivers/gpu/drm/i915/intel_dp.c | 7 ++-
  1 file changed, 2 insertions(+), 5 deletions(-)

 diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
 index b10f35b..52b5453 100644
 --- a/drivers/gpu/drm/i915/intel_dp.c
 +++ b/drivers/gpu/drm/i915/intel_dp.c
 @@ -794,9 +794,7 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct 
 drm_display_mode *mode,
mode-clock, adjusted_mode-clock, m_n);
  
   if (HAS_PCH_SPLIT(dev)) {
 - I915_WRITE(TRANSDATA_M1(pipe),
 -((m_n.tu - 1)  PIPE_GMCH_DATA_M_TU_SIZE_SHIFT) |
 -m_n.gmch_m);
 + I915_WRITE(TRANSDATA_M1(pipe), TU_SIZE(m_n.tu) | m_n.gmch_m);
   I915_WRITE(TRANSDATA_N1(pipe), m_n.gmch_n);
   I915_WRITE(TRANSDPLINK_M1(pipe), m_n.link_m);
   I915_WRITE(TRANSDPLINK_N1(pipe), m_n.link_n);
 @@ -807,8 +805,7 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct 
 drm_display_mode *mode,
   I915_WRITE(PIPE_LINK_N1(pipe), m_n.link_n);
   } else {
   I915_WRITE(PIPE_GMCH_DATA_M(pipe),
 -((m_n.tu - 1)  PIPE_GMCH_DATA_M_TU_SIZE_SHIFT) |
 -m_n.gmch_m);
 +TU_SIZE(m_n.tu) | m_n.gmch_m);
   I915_WRITE(PIPE_GMCH_DATA_N(pipe), m_n.gmch_n);
   I915_WRITE(PIPE_DP_LINK_M(pipe), m_n.link_m);
   I915_WRITE(PIPE_DP_LINK_N(pipe), m_n.link_n);
 -- 
 1.7.11.4

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

[Intel-gfx] [BUG] i915 RC6 lockup

2012-10-16 Thread Jonas Jelten

Hi list!

I think i've got a problem with the intel driver:

Sometimes, I think especially after running graphics intense
applications, RC6 is disabled completely and heats up my Thinkpad X220t
to 90 degree celsius, while idling.

At first I thought that this is a CPU frequency scaling issue, as the
cpufreq_powersave claims to be running at 800 MHz, but i7z
(http://code.google.com/p/i7z/) shows all multipliers to be 25 - 2.5
GHz CPU clock.

Powertop 2.1 reveals that the GPU is 100% active, 0% RC6, 0% RC6p and 0%
RC6pp, and the CPU is 99,9% in C7-deep-sleep, at maximum frequency.
/sys/kernel/debug/dri/0/i915_ring_freq_table also pointed the issue to
being caused by the GPU.

intel_gpu_top shows a total idle.

I'm on ArchLinux, Kernel 3.6.2, xf86-video-intel-git
b42d81b63f5b6a571faffaadd42c74adce40128a, this is 2.20.10.
Problem first occured with Kernel 3.6.0.
Core i5-2520M HD 3000

cat /proc/cmdline
cryptdevice=/dev/sda2:cryptroot root=/dev/mapper/cryptroot ro vga=791
i915.i915_enable_rc6=7 i915.modeset=1 i915.lvds_downclock=1
i915.semaphores=1 drm.vblankoffdelay=1 init=/bin/systemd
initrd=../initramfs-linux.img BOOT_IMAGE=../vmlinuz-linux

Sometimes it can be fixed by going to pm-suspend and waking up. A reboot
always fixes it, until it randomly locks up the GPU again.

Please help me how i can do further investigation to catch the bug.

As this makes my Laptop consume ~40W, it would be really nice if this
gets fixed.


Cheers,

Jonas



signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] hsw rps values regress RPS on Macbook Air

2012-10-16 Thread Jesse Barnes

On Fri, 12 Oct 2012 11:34:08 -0700
Eric Anholt e...@anholt.net wrote:

 Jesse Barnes jbar...@virtuousgeek.org writes:
 
  On Tue, 09 Oct 2012 13:05:54 -0700
  Eric Anholt e...@anholt.net wrote:
 
  On my new MBA with danvet's drm-intel-next-queued, I'm not getting
  working RPS.  vblank_mode=0 glxgears never ups the frequency, and
  vblank_mode=0 openarena only makes it up to 500mhz.  Reverting
  1ee9ae3244c4789f3184c5123f3b2d7e405b3f4c gets the machine to responsive
  RPS: fully on while the GPU is busy, fully lowered when it's not.
  
  Since we're always just looking for all-on or all-off and never see
  workloads that actually want to be somewhere in between, could we please
  just move to race to idle for RPS?
 
  Ramping to the max freq is fine for benchmarking.  But for normal
  vblank throttled activity, using the lowest freq (assuming it's
  above our nominal freq) that can hit the refresh is the right answer
  from a power perspective.
 
 Have you seen any workloads where a middle frequency value is actually
 chosen by the current RPS system?

I can't tell if this is a snarky response or not. :)  But either way it
misses my point: I think the current RPS system isn't ideal for many of
our workloads and the way our GL stack runs things.  I've thought we
could do better for awhile now but couldn't think of a way that would
let userspace request lower frequencies if it didn't need the extra
processing power, but if we collect a little data in Mesa maybe we can
do it.

I propose a new ioctl, I915_FREQ_REQUEST, with 3 different parameters,
I915_MAX_FREQ, I915_MORE_FREQ, and I915_LESS_FREQ.  The first would
tell the kernel the app would like to run at the maximum possible
speed, regardless of power or throttling considerations.  MORE
would simply tell the kernel the app needs a higher frequency to meet
its frame rate target, and LESS would tell the kernel it could run
slower and still hit its target.

In Mesa, we'd need to track the FPS target for the app, the current FPS
(e.g. over the last second, or using a decaying average with some
weight toward recent activity), and the time between swapbuffers calls
(as an approximation of how long it takes us to draw each frame).

Periodically (maybe every second when we update our current FPS), Mesa
would either request more frequency if it wasn't hitting its FPS
target, or less frequency if its frame draw time was less than 90% of
the maximum alloted frame time (the period for the frequency we're
trying to hit).  The FPS target would be based on the swap interval for
the app.

In a benchmarking mode (i.e. vblank_mode=0 or swapinterval set to 0),
we could just make a I915_MAX_FREQ request and be done with it.

Within the kernel, we'd evaluate every app's requests and choose the
max frequency requested, re-setting things on every ioctl call and when
apps close.

Any thoughts?  Would collecting the above info in Mesa be pretty easy?
I think we already collect FPS info if certain debug flags are set, and
frame time seems like a pretty trivial calculation based on some
timestamping in a couple of places...

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

Re: [Intel-gfx] [PATCH] drm/i915: Set DERRMR around batches required vblank events

2012-10-16 Thread Daniel Vetter

On Tue, Oct 16, 2012 at 11:47 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:

 I am still not convinced this fixes anything as at the moment I am
 simply unable to detect any tearing on my ivb setup if I apply any form of
 vblank throttling.

 The other issue is that I think if I had a SECURE
 (DRM_MASTER|DRM_ROOT_ONLY) batch buffer I could probably do all of this
 in userspace.

Yeah, I'm a bit torn between this approach and just allowing SECURE
batches. The big upside of secure batches is that it allows more
flexibility (if the LRI really work from secure batches and not just
from the ring). The only downside I can see is that we won't be able
to arbitrage the derrmr bits (since only one is allowed to be set at
any given time) between different userspace processes. But I don't see
mutliple concurrent display servers (with cooperative owenership of
the hw) happening anytime soon, so I won't worry about this before it
happens. Syncing against modeset should still work with our MI_WAIT
related waits on fbs before we disable the pipe.

The other issue (only on gen7) is that this will keep the gpu out of
rc6 (and hence the entire package) for long times, especially on
mostly-idle video playback. I don't think that massively increased
power consumption is what users will appreciated.

Now with the Tearfree option and you saying that vblank render
throttling mostly fixes this, do we have any unhappy bug reporters
left? In that case I'd prefer to just can this entirely (and suggest
to ppl to use a real compositor - the wasted bw issue on X also seems
to be on track to be solved).

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

50 matches

Mail list logo