Re: [Intel-gfx] [PATCH 5/5] drm/i915/vlv: support save/restore of display state around power well toggle

2013-10-16 Thread Daniel Vetter
On Tue, Oct 15, 2013 at 01:42:53PM -0700, Jesse Barnes wrote:
 On Tue, 15 Oct 2013 17:09:19 -0300
 Paulo Zanoni przan...@gmail.com wrote:
 
  2013/10/14 Jesse Barnes jbar...@virtuousgeek.org:
   If we disable the power well at runtime, we need to save enough display
   state so we can restore it when the power well comes back again.  Add
   support for that on VLV by reusing some of the _freeze and _thaw code.
  
   Note we need to drop the power well lock in this path around the restore,
   since we'll end up in mode set functions that take more refs on the
   power well.
  
   Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
   ---
drivers/gpu/drm/i915/intel_uncore.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
  
   diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
   b/drivers/gpu/drm/i915/intel_uncore.c
   index b126f5a..070ff00 100644
   --- a/drivers/gpu/drm/i915/intel_uncore.c
   +++ b/drivers/gpu/drm/i915/intel_uncore.c
   @@ -406,7 +406,26 @@ static void __vlv_set_power_well(struct 
   drm_i915_private *dev_priv,
static void vlv_set_display_power(struct drm_i915_private *dev_priv,
 bool enable)
{
   -   __vlv_set_power_well(dev_priv, DISP2D_PWRGT, enable);
   +   struct drm_device *dev = dev_priv-dev;
   +   struct i915_power_well *power_well = dev_priv-power_well;
   +
   +   if (enable) {
   +   /* Lost all the display state, restore it */
   +   if (vlv_display_power_enabled(dev_priv))
   +   return; /* already on, skip the fireworks */
   +   __vlv_set_power_well(dev_priv, DISP2D_PWRGT, true);
   +   spin_unlock_irq(power_well-lock);
   +   i915_restore_state(dev);
  
  At least on Haswell, i915_restore_state restores a lot more than just
  what was lost on the power well. Do you really need all this? Besides,
  I kinda fear you can break things by restoring stuff that is already
  running. While we're doing this restoring, interrputs are happening,
  everything is running, yet we call stuff like intel_i2c_reset,
  i915_gem_restore_fences and others. Another example: we have code to
  restore the backlight registers, but backlight is usually on the
  output that works even with the power well disabled. So if we disable
  the power well, then change backlight on the only output that is
  working, then reenable the power well we'll restore a bogus
  backlight state on a case where we shouldn't be touching backlight at
  all.
 
 Yeah this is definitely a WIP.  We'll probably need power well specific
 save/restore functions.  Depending on which well was toggled, the state
 that needs to be saved  restored will be different.  It may be best to
 try to push all this into modeset_setup_hw_state, since it should know
 which power wells are needed for different ops and thus restore the
 right state.  But that means ripping apart save/restore_state and
 putting bits in the right places, potentially with specific hooks like
 the uncore save/restore I added for other stuff.

setup_hw_state only deals with things which should be active (and restores
them when they're not active). But what we want here is to re-run the
-mode_set callback code when enabling a pipe again through dpms. So for
me it feels much saner to just add that callback there instead of
magically restoring register state in the get/put functions.

The reason for that is that at least long-term I expect the -mode_set
callbacks to die and that we'll move everything which is in there either
into -enable callbacks or into the compute config stage. With that we'll
have the guarantee that the hw touching code sequence is always the same,
no matter which exact upper level function caused a given state change
(modeset, dpms, resume, ...).

I don't really have an opinion about how we should handle this stuff on
the gem side of things. For that magically restoring the gem hw state in
the get/put functions sounds like the right approach. For gem we probably
also need some delayed actual put to have a bit of hysteresis. That's
kinda why I think we should have separate interfaces for display power
well management and gem/irq/aux power well management.
-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: Move some hdmi enable function name to vlv specific.

2013-10-16 Thread Chon Ming Lee
There is no functional change on this patch.  Only rename several
hdmi encoder function name which suppose to use only by valleyview from
intel_hdmi_pre_pll_enable to vlv_hdmi_pre_pll_enable, and etc.

Signed-off-by: Chon Ming Lee chon.ming@intel.com
---
 drivers/gpu/drm/i915/intel_hdmi.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 4f4d346..51a8336 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1074,7 +1074,7 @@ done:
return 0;
 }
 
-static void intel_hdmi_pre_enable(struct intel_encoder *encoder)
+static void vlv_hdmi_pre_enable(struct intel_encoder *encoder)
 {
struct intel_digital_port *dport = enc_to_dig_port(encoder-base);
struct drm_device *dev = encoder-base.dev;
@@ -1127,7 +1127,7 @@ static void intel_hdmi_pre_enable(struct intel_encoder 
*encoder)
vlv_wait_port_ready(dev_priv, port);
 }
 
-static void intel_hdmi_pre_pll_enable(struct intel_encoder *encoder)
+static void vlv_hdmi_pre_pll_enable(struct intel_encoder *encoder)
 {
struct intel_digital_port *dport = enc_to_dig_port(encoder-base);
struct drm_device *dev = encoder-base.dev;
@@ -1163,7 +1163,7 @@ static void intel_hdmi_pre_pll_enable(struct 
intel_encoder *encoder)
mutex_unlock(dev_priv-dpio_lock);
 }
 
-static void intel_hdmi_post_disable(struct intel_encoder *encoder)
+static void vlv_hdmi_post_disable(struct intel_encoder *encoder)
 {
struct intel_digital_port *dport = enc_to_dig_port(encoder-base);
struct drm_i915_private *dev_priv = encoder-base.dev-dev_private;
@@ -1313,10 +1313,10 @@ void intel_hdmi_init(struct drm_device *dev, int 
hdmi_reg, enum port port)
intel_encoder-get_hw_state = intel_hdmi_get_hw_state;
intel_encoder-get_config = intel_hdmi_get_config;
if (IS_VALLEYVIEW(dev)) {
-   intel_encoder-pre_pll_enable = intel_hdmi_pre_pll_enable;
-   intel_encoder-pre_enable = intel_hdmi_pre_enable;
+   intel_encoder-pre_pll_enable = vlv_hdmi_pre_pll_enable;
+   intel_encoder-pre_enable = vlv_hdmi_pre_enable;
intel_encoder-enable = vlv_enable_hdmi;
-   intel_encoder-post_disable = intel_hdmi_post_disable;
+   intel_encoder-post_disable = vlv_hdmi_post_disable;
} else {
intel_encoder-enable = intel_enable_hdmi;
}
-- 
1.7.7.6

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


Re: [Intel-gfx] [PATCH] drm/i915: Replace has_bsd/blt/vebox with a mask

2013-10-16 Thread Daniel Vetter
On Tue, Oct 15, 2013 at 10:02:57AM -0700, Ben Widawsky wrote:
 From: Ben Widawsky b...@bwidawsk.net
 
 I've sent this patch several times for various reasons. It essentially
 cleans up a lot of code where we need to do something per ring, and want
 to query whether or not the ring exists on that hardware.
 
 It has various uses coming up, but for now it shouldn't be too
 offensive.
 
 v2: Big conflict resolution on Damien's DEV_INFO_FOR_EACH stuff
 
 v3: Resolved vebox addition
 
 v4: Rebased after months of disuse. Also made failed ringbuffer init
 cleaner.
 
 v5: Remove the init cleaner from v4. There is a better way to do it.
 (Chris)
 
 Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
 Signed-off-by: Ben Widawsky b...@bwidawsk.net

Series merged, thanks for patchesreview.
-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 3/4] drm/i915: HSW GT3 Slices: exec flag to warn kernel that userspace is using predication

2013-10-16 Thread Chris Wilson
On Tue, Oct 15, 2013 at 05:50:49PM -0300, Rodrigo Vivi wrote:
 If Userspace isn't using MI_PREDICATE all slices must be enabled for
 backward compatibility.
 
 If I915_EXEC_USE_PREDICATE isn't set and defaul is set to half, kernel will 
 force
 all slices on.
 
 v2: fix the inverted logic for backwards compatibility
 USE_PREDICATE unset force gt_full when defaul is half
 instead of GT_FULL flag.
 
 CC: Eric Anholt e...@anholt.net
 CC: Kenneth Graunke kenn...@whitecape.org
 Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
 ---
  drivers/gpu/drm/i915/i915_drv.h|  8 
  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 67 
 ++
  drivers/gpu/drm/i915/i915_reg.h| 11 +
  drivers/gpu/drm/i915/i915_sysfs.c  | 11 -
  drivers/gpu/drm/i915/intel_display.c   |  6 +++
  drivers/gpu/drm/i915/intel_drv.h   |  1 +
  drivers/gpu/drm/i915/intel_pm.c| 39 -
  include/uapi/drm/i915_drm.h|  8 +++-
  8 files changed, 146 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index 685fb1d..bd4774e 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -1219,6 +1219,12 @@ struct i915_package_c8 {
   } regsave;
  };
  
 +struct i915_gt_slices {
 + int state_default;

Either use it as an integer (a count of slices enabled by default) or
make it an enum.

 + int forcing_full;

bool legacy_userspace_busy; ?

 + struct mutex m_lock;

Ugh. Just struct mutex lock; /* locks all access to this struct and
slice registers */ will suffice

 +};
 +
  typedef struct drm_i915_private {
   struct drm_device *dev;
   struct kmem_cache *slab;
 @@ -1418,6 +1424,8 @@ typedef struct drm_i915_private {
  
   struct i915_package_c8 pc8;
  
 + struct i915_gt_slices gt_slices;
 +
   /* Old dri1 support infrastructure, beware the dragons ya fools entering
* here! */
   struct i915_dri1_state dri1;
 diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
 b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 index 0ce0d47..eb09a51 100644
 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 @@ -923,6 +923,66 @@ i915_reset_gen7_sol_offsets(struct drm_device *dev,
  }
  
  static int
 +i915_gt_full_immediate(struct drm_device *dev, struct intel_ring_buffer 
 *ring)

That's a misnomer.

 +{
 + drm_i915_private_t *dev_priv = dev-dev_private;
 + int ret;
 +
 + if (!HAS_SLICE_SHUTDOWN(dev) || ring == dev_priv-ring[BCS])
 + return 0;
 +
 + ret = intel_ring_begin(ring, 3);
 + if (ret)
 + return ret;
 + intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
 + intel_ring_emit(ring, HSW_GT_SLICE_INFO);
 + intel_ring_emit(ring, SLICE_SEL_BOTH);
 + intel_ring_advance(ring);
 +
 + ret = intel_ring_begin(ring, 3);
 + if (ret)
 + return ret;
 + intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
 + intel_ring_emit(ring, MI_PREDICATE_RESULT_2);
 + intel_ring_emit(ring, LOWER_SLICE_ENABLED);
 + intel_ring_advance(ring);
 +
 + ret = intel_ring_begin(ring, 3);
 + if (ret)
 + return ret;
 + intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
 + intel_ring_emit(ring, HSW_SLICESHUTDOWN);
 + intel_ring_emit(ring, ~SLICE_SHUTDOWN);
 + intel_ring_advance(ring);
 +
 + ret = intel_ring_begin(ring, 3);
 + if (ret)
 + return ret;
 + intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
 + intel_ring_emit(ring, RC_IDLE_MAX_COUNT);
 + intel_ring_emit(ring, CS_IDLE_COUNT_1US);
 + intel_ring_advance(ring);
 +
 + ret = intel_ring_begin(ring, 3);
 + if (ret)
 + return ret;
 + intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
 + intel_ring_emit(ring, WAIT_FOR_RC6_EXIT);
 + intel_ring_emit(ring, WAIT_RC6_EXIT | MASK_WAIT_RC6_EXIT);
 + intel_ring_advance(ring);
 +
 + ret = intel_ring_begin(ring, 3);
 + if (ret)
 + return ret;
 + intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
 + intel_ring_emit(ring, RC_IDLE_MAX_COUNT);
 + intel_ring_emit(ring, CS_IDLE_COUNT_5US);
 + intel_ring_advance(ring);
 +
 + return 0;
 +}
 +
 +static int
  i915_gem_do_execbuffer(struct drm_device *dev, void *data,
  struct drm_file *file,
  struct drm_i915_gem_execbuffer2 *args,
 @@ -999,6 +1059,13 @@ i915_gem_do_execbuffer(struct drm_device *dev, void 
 *data,
   return -EINVAL;
   }
  
 + if ((args-flags  I915_EXEC_USE_PREDICATE) == 0 
 + dev_priv-gt_slices.state_default == 0 
 + !dev_priv-gt_slices.forcing_full) {

Always set legacy_userspace_busy here so that a change in state_default
cannot possibly break currently active users i.e. they are independent
bookkeeping.

 + dev_priv-gt_slices.forcing_full = 

[Intel-gfx] [PATCH v2 2/2] drm/i915: set HDMI pixel clock in audio configuration

2013-10-16 Thread Jani Nikula
The HDMI audio expects HDMI pixel clock to be set in the audio
configuration. We've currently just set 0, using 25.2 / 1.001 kHz
frequency, which fails with some modes.

v2: Now with a commit message.

Reference: 
http://mid.gmane.org/cagpeb3ep1lrzetpxhgrfbdqr5ts2tac8gcukwwuguf1u5ny...@mail.gmail.com
Reference: http://mid.gmane.org/20130206213533.ga16...@hardeman.nu
Reported-by: David Härdeman da...@hardeman.nu
Reported-by: Jasper Smet josb...@gmail.com
Tested-by: Jasper Smet josb...@gmail.com
Signed-off-by: Jani Nikula jani.nik...@intel.com
---
 drivers/gpu/drm/i915/i915_reg.h  |   12 -
 drivers/gpu/drm/i915/intel_display.c |   48 +++---
 2 files changed, 55 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 13153c3..3266819 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4875,7 +4875,17 @@
 #define   AUD_CONFIG_LOWER_N_SHIFT 4
 #define   AUD_CONFIG_LOWER_N_VALUE (0xfff  4)
 #define   AUD_CONFIG_PIXEL_CLOCK_HDMI_SHIFT16
-#define   AUD_CONFIG_PIXEL_CLOCK_HDMI  (0xf  16)
+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK (0xf  16)
+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_25175(0  16)
+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_25200(1  16)
+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_27000(2  16)
+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_27027(3  16)
+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_54000(4  16)
+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_54054(5  16)
+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_74176(6  16)
+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_74250(7  16)
+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_148352   (8  16)
+#define   AUD_CONFIG_PIXEL_CLOCK_HDMI_148500   (9  16)
 #define   AUD_CONFIG_DISABLE_NCTS  (1  3)
 
 /* HSW Audio */
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 55740f2..a097f84 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6722,6 +6722,44 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc,
return 0;
 }
 
+static struct {
+   int clock;
+   u32 config;
+} hdmi_audio_clock[] = {
+   { DIV_ROUND_UP(25200 * 1000, 1001), AUD_CONFIG_PIXEL_CLOCK_HDMI_25175 },
+   { 25200, AUD_CONFIG_PIXEL_CLOCK_HDMI_25200 }, /* default per bspec */
+   { 27000, AUD_CONFIG_PIXEL_CLOCK_HDMI_27000 },
+   { 27000 * 1001 / 1000, AUD_CONFIG_PIXEL_CLOCK_HDMI_27027 },
+   { 54000, AUD_CONFIG_PIXEL_CLOCK_HDMI_54000 },
+   { 54000 * 1001 / 1000, AUD_CONFIG_PIXEL_CLOCK_HDMI_54054 },
+   { DIV_ROUND_UP(74250 * 1000, 1001), AUD_CONFIG_PIXEL_CLOCK_HDMI_74176 },
+   { 74250, AUD_CONFIG_PIXEL_CLOCK_HDMI_74250 },
+   { DIV_ROUND_UP(148500 * 1000, 1001), AUD_CONFIG_PIXEL_CLOCK_HDMI_148352 
},
+   { 148500, AUD_CONFIG_PIXEL_CLOCK_HDMI_148500 },
+};
+
+/* get AUD_CONFIG_PIXEL_CLOCK_HDMI_* value for mode */
+static u32 audio_config_hdmi_pixel_clock(struct drm_display_mode *mode)
+{
+   int i;
+
+   for (i = 0; i  ARRAY_SIZE(hdmi_audio_clock); i++) {
+   if (mode-clock == hdmi_audio_clock[i].clock)
+   break;
+   }
+
+   if (i == ARRAY_SIZE(hdmi_audio_clock)) {
+   DRM_DEBUG_KMS(HDMI audio pixel clock setting for %d not found, 
falling back to defaults\n, mode-clock);
+   i = 1;
+   }
+
+   DRM_DEBUG_KMS(Configuring HDMI audio for pixel clock %d (0x%08x)\n,
+ hdmi_audio_clock[i].clock,
+ hdmi_audio_clock[i].config);
+
+   return hdmi_audio_clock[i].config;
+}
+
 static bool intel_eld_uptodate(struct drm_connector *connector,
   int reg_eldv, uint32_t bits_eldv,
   int reg_elda, uint32_t bits_elda,
@@ -6847,8 +6885,9 @@ static void haswell_write_eld(struct drm_connector 
*connector,
DRM_DEBUG_DRIVER(ELD: DisplayPort detected\n);
eld[5] |= (1  2); /* Conn_Type, 0x1 = DisplayPort */
I915_WRITE(aud_config, AUD_CONFIG_N_VALUE_INDEX); /* 0x1 = DP */
-   } else
-   I915_WRITE(aud_config, 0);
+   } else {
+   I915_WRITE(aud_config, audio_config_hdmi_pixel_clock(mode));
+   }
 
if (intel_eld_uptodate(connector,
   aud_cntrl_st2, eldv,
@@ -6926,8 +6965,9 @@ static void ironlake_write_eld(struct drm_connector 
*connector,
DRM_DEBUG_DRIVER(ELD: DisplayPort detected\n);
eld[5] |= (1  2); /* Conn_Type, 0x1 = DisplayPort */
I915_WRITE(aud_config, AUD_CONFIG_N_VALUE_INDEX); /* 0x1 = DP */
-   } else
-   I915_WRITE(aud_config, 0);
+   } else {
+   I915_WRITE(aud_config, audio_config_hdmi_pixel_clock(mode));
+   }
 
if (intel_eld_uptodate(connector,
   aud_cntrl_st2, eldv,
-- 

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: pass mode to ELD write vfuncs

2013-10-16 Thread Jani Nikula

Mengdong, I meant to CC you on these two patches. Please have a look.

I also screwed up in-reply-to, was meant to be 
http://mid.gmane.org/cover.1381765995.git.jani.nik...@intel.com

BR,
Jani.


On Wed, 16 Oct 2013, Jani Nikula jani.nik...@intel.com wrote:
 This will be needed for setting the HDMI pixel clock for audio
 config. No functional changes.

 v2: Now with a commit message.

 Signed-off-by: Jani Nikula jani.nik...@intel.com
 ---
  drivers/gpu/drm/i915/i915_drv.h  |3 ++-
  drivers/gpu/drm/i915/intel_display.c |   11 +++
  2 files changed, 9 insertions(+), 5 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index 6106d3d..caee590 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -379,7 +379,8 @@ struct drm_i915_display_funcs {
   void (*crtc_disable)(struct drm_crtc *crtc);
   void (*off)(struct drm_crtc *crtc);
   void (*write_eld)(struct drm_connector *connector,
 -   struct drm_crtc *crtc);
 +   struct drm_crtc *crtc,
 +   struct drm_display_mode *mode);
   void (*fdi_link_train)(struct drm_crtc *crtc);
   void (*init_clock_gating)(struct drm_device *dev);
   int (*queue_flip)(struct drm_device *dev, struct drm_crtc *crtc,
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 4f1b636..55740f2 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -6752,7 +6752,8 @@ static bool intel_eld_uptodate(struct drm_connector 
 *connector,
  }
  
  static void g4x_write_eld(struct drm_connector *connector,
 -   struct drm_crtc *crtc)
 +   struct drm_crtc *crtc,
 +   struct drm_display_mode *mode)
  {
   struct drm_i915_private *dev_priv = connector-dev-dev_private;
   uint8_t *eld = connector-eld;
 @@ -6792,7 +6793,8 @@ static void g4x_write_eld(struct drm_connector 
 *connector,
  }
  
  static void haswell_write_eld(struct drm_connector *connector,
 -  struct drm_crtc *crtc)
 +   struct drm_crtc *crtc,
 +   struct drm_display_mode *mode)
  {
   struct drm_i915_private *dev_priv = connector-dev-dev_private;
   uint8_t *eld = connector-eld;
 @@ -6879,7 +6881,8 @@ static void haswell_write_eld(struct drm_connector 
 *connector,
  }
  
  static void ironlake_write_eld(struct drm_connector *connector,
 -  struct drm_crtc *crtc)
 +struct drm_crtc *crtc,
 +struct drm_display_mode *mode)
  {
   struct drm_i915_private *dev_priv = connector-dev-dev_private;
   uint8_t *eld = connector-eld;
 @@ -6974,7 +6977,7 @@ void intel_write_eld(struct drm_encoder *encoder,
   connector-eld[6] = drm_av_sync_delay(connector, mode) / 2;
  
   if (dev_priv-display.write_eld)
 - dev_priv-display.write_eld(connector, crtc);
 + dev_priv-display.write_eld(connector, crtc, mode);
  }
  
  static void i845_update_cursor(struct drm_crtc *crtc, u32 base)
 -- 
 1.7.9.5


-- 
Jani Nikula, 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: Move some hdmi enable function name to vlv specific.

2013-10-16 Thread Ville Syrjälä
On Wed, Oct 16, 2013 at 05:07:41PM +0800, Chon Ming Lee wrote:
 There is no functional change on this patch.  Only rename several
 hdmi encoder function name which suppose to use only by valleyview from
 intel_hdmi_pre_pll_enable to vlv_hdmi_pre_pll_enable, and etc.
 
 Signed-off-by: Chon Ming Lee chon.ming@intel.com

Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com

As a followup you could also remove the pointless IS_VALLEYVIEW() checks
from pre_enable and pre_pll_enable.

 ---
  drivers/gpu/drm/i915/intel_hdmi.c |   12 ++--
  1 files changed, 6 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
 b/drivers/gpu/drm/i915/intel_hdmi.c
 index 4f4d346..51a8336 100644
 --- a/drivers/gpu/drm/i915/intel_hdmi.c
 +++ b/drivers/gpu/drm/i915/intel_hdmi.c
 @@ -1074,7 +1074,7 @@ done:
   return 0;
  }
  
 -static void intel_hdmi_pre_enable(struct intel_encoder *encoder)
 +static void vlv_hdmi_pre_enable(struct intel_encoder *encoder)
  {
   struct intel_digital_port *dport = enc_to_dig_port(encoder-base);
   struct drm_device *dev = encoder-base.dev;
 @@ -1127,7 +1127,7 @@ static void intel_hdmi_pre_enable(struct intel_encoder 
 *encoder)
   vlv_wait_port_ready(dev_priv, port);
  }
  
 -static void intel_hdmi_pre_pll_enable(struct intel_encoder *encoder)
 +static void vlv_hdmi_pre_pll_enable(struct intel_encoder *encoder)
  {
   struct intel_digital_port *dport = enc_to_dig_port(encoder-base);
   struct drm_device *dev = encoder-base.dev;
 @@ -1163,7 +1163,7 @@ static void intel_hdmi_pre_pll_enable(struct 
 intel_encoder *encoder)
   mutex_unlock(dev_priv-dpio_lock);
  }
  
 -static void intel_hdmi_post_disable(struct intel_encoder *encoder)
 +static void vlv_hdmi_post_disable(struct intel_encoder *encoder)
  {
   struct intel_digital_port *dport = enc_to_dig_port(encoder-base);
   struct drm_i915_private *dev_priv = encoder-base.dev-dev_private;
 @@ -1313,10 +1313,10 @@ void intel_hdmi_init(struct drm_device *dev, int 
 hdmi_reg, enum port port)
   intel_encoder-get_hw_state = intel_hdmi_get_hw_state;
   intel_encoder-get_config = intel_hdmi_get_config;
   if (IS_VALLEYVIEW(dev)) {
 - intel_encoder-pre_pll_enable = intel_hdmi_pre_pll_enable;
 - intel_encoder-pre_enable = intel_hdmi_pre_enable;
 + intel_encoder-pre_pll_enable = vlv_hdmi_pre_pll_enable;
 + intel_encoder-pre_enable = vlv_hdmi_pre_enable;
   intel_encoder-enable = vlv_enable_hdmi;
 - intel_encoder-post_disable = intel_hdmi_post_disable;
 + intel_encoder-post_disable = vlv_hdmi_post_disable;
   } else {
   intel_encoder-enable = intel_enable_hdmi;
   }
 -- 
 1.7.7.6
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 1/2] drm/i915: static inline for dummy crc functions

2013-10-16 Thread Daniel Vetter
Also use #ifdef to keep consistent with all other such cases.

Cc: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_drv.h | 4 ++--
 drivers/gpu/drm/i915/i915_irq.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9aeddc0..b39a548 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2235,10 +2235,10 @@ int i915_verify_lists(struct drm_device *dev);
 /* i915_debugfs.c */
 int i915_debugfs_init(struct drm_minor *minor);
 void i915_debugfs_cleanup(struct drm_minor *minor);
-#if defined(CONFIG_DEBUG_FS)
+#ifdef CONFIG_DEBUG_FS
 void intel_display_crc_init(struct drm_device *dev);
 #else
-void intel_display_crc_init(struct drm_device *dev) {}
+static inline void intel_display_crc_init(struct drm_device *dev) {}
 #endif
 
 /* i915_gpu_error.c */
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b2be057..8c9148c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1225,7 +1225,7 @@ static void ivb_pipe_crc_update(struct drm_device *dev, 
enum pipe pipe)
wake_up_interruptible(pipe_crc-wq);
 }
 #else
-static void ivb_pipe_crc_update(struct drm_device *dev, int pipe) {}
+static inline void ivb_pipe_crc_update(struct drm_device *dev, int pipe) {}
 #endif
 
 /* The RPS events need forcewake, so we add them to a work queue and mask their
-- 
1.8.4.rc3

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


[Intel-gfx] [PATCH 2/2] drm/i915: constify harder

2013-10-16 Thread Daniel Vetter
We not only want const strings, but a const array of them. Reported by
checkpatch.pl

Cc: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d1674b6..5fce5d8 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1909,7 +1909,7 @@ static int i915_pipe_crc_create(struct dentry *root, 
struct drm_minor *minor,
return drm_add_fake_info_node(minor, ent, info);
 }
 
-static const char *pipe_crc_sources[] = {
+static const char * const pipe_crc_sources[] = {
none,
plane1,
plane2,
@@ -2054,7 +2054,7 @@ enum intel_pipe_crc_object {
PIPE_CRC_OBJECT_PIPE,
 };
 
-static const char *pipe_crc_objects[] = {
+static const char * const pipe_crc_objects[] = {
pipe,
 };
 
-- 
1.8.4.rc3

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


Re: [Intel-gfx] Pipe CRCs v1

2013-10-16 Thread Daniel Vetter
On Tue, Oct 15, 2013 at 06:55:26PM +0100, Damien Lespiau wrote:
 This series exposes the pipe CRCs on ivybridge through debugfs. It's based on
 the initial work from Shuang He, with some improvements to have a nice user
 space API.
 
 There are several points in the display pipeline where CRCs can be computed
 on the bits flowing there. For instance, it's usually possible to compute
 the CRCs of the primary plane, the sprite plane or the CRCs of the bits
 after the panel fitter (collectively called pipe CRCs).
 
 An intel-gpu-tools series will follow with helpers to use the feature from
 tests and basic testing.
 
 Further work items:
   * make it work on other platforms
   * expose other CRCs than just the pipe CRCs (transcoders, ddi, ...)
   * implement poll() for the result files

I like this and so went ahead and merged it right away. A bit of CRC
support is much better than none and the tests should make sure that
things actually work somewhat.

Polishing that imo still needs to happen:
- Roll out on other platforms. Especially vlv since there we actually want
  to have good sprite support.

- Add an all alias or something similar which just picks a crc source
  take takes the pixels after all sprite/cursor/plane blending, csc and
  gamma ramps have been applied. For ivb that seems to be the pf source.
  To make sure it works we'd need a small testcase that moves
  cursors/sprites/planes and changes gamma to make sure we cover all these
  things. Then we could finally have automated testcases for checking all
  the restore code in our resume paths (or dpms on and all that stuff).

- atomic_t is weakly ordered, even on x86 (since it doesn't even have).
  Also, writing a correct lockless ringbuffer is Damn Hard (tm). I don't
  see any need to massive performance issues with this, so we need to
  switch to normal mutex locking (with a spinlock for the ringbuffer
  itself to allow the irq handler to fill it).

- Use it all over the place in igt tests ...

Thanks a lot for doing this.

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


Re: [Intel-gfx] [PATCH] drm/i915: Move some hdmi enable function name to vlv specific.

2013-10-16 Thread Daniel Vetter
On Wed, Oct 16, 2013 at 05:07:41PM +0800, Chon Ming Lee wrote:
 There is no functional change on this patch.  Only rename several
 hdmi encoder function name which suppose to use only by valleyview from
 intel_hdmi_pre_pll_enable to vlv_hdmi_pre_pll_enable, and etc.
 
 Signed-off-by: Chon Ming Lee chon.ming@intel.com

Queued for -next, 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 01/16] drm/i915: Expose latest 200 CRC value for pipe through debugfs

2013-10-16 Thread Ville Syrjälä
On Tue, Oct 15, 2013 at 06:55:27PM +0100, Damien Lespiau wrote:
 From: Shuang He shuang...@intel.com
 
 There are several points in the display pipeline where CRCs can be
 computed on the bits flowing there. For instance, it's usually possible
 to compute the CRCs of the primary plane, the sprite plane or the CRCs
 of the bits after the panel fitter (collectively called pipe CRCs).
 
 v2: Quite a bit of rework here and there (Damien)
 
 Signed-off-by: Shuang He shuang...@intel.com
 Signed-off-by: Damien Lespiau damien.lesp...@intel.com
 ---
  drivers/gpu/drm/i915/i915_debugfs.c | 33 +
  drivers/gpu/drm/i915/i915_drv.h | 16 
  drivers/gpu/drm/i915/i915_irq.c | 35 +++
  drivers/gpu/drm/i915/i915_reg.h | 36 +++-
  4 files changed, 119 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
 b/drivers/gpu/drm/i915/i915_debugfs.c
 index 72d0458..e1d45aa 100644
 --- a/drivers/gpu/drm/i915/i915_debugfs.c
 +++ b/drivers/gpu/drm/i915/i915_debugfs.c
 @@ -1732,6 +1732,36 @@ static int i915_pc8_status(struct seq_file *m, void 
 *unused)
   return 0;
  }
  
 +static int i915_pipe_crc(struct seq_file *m, void *data)
 +{
 + struct drm_info_node *node = (struct drm_info_node *) m-private;
 + struct drm_device *dev = node-minor-dev;
 + struct drm_i915_private *dev_priv = dev-dev_private;
 + enum pipe pipe = (enum pipe)node-info_ent-data;
 + const struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[pipe];
 + int i;
 + int start;
 +
 + if (!IS_IVYBRIDGE(dev)) {
 + seq_puts(m, unsupported\n);
 + return 0;
 + }
 +
 + start = atomic_read(pipe_crc-slot) + 1;
 + seq_puts(m,  timestamp CRC1 CRC2 CRC3 CRC4 
 CRC5\n);
 + for (i = 0; i  INTEL_PIPE_CRC_ENTRIES_NR; i++) {
 + const struct intel_pipe_crc_entry *entry =
 + pipe_crc-entries[(start + i) %
 +INTEL_PIPE_CRC_ENTRIES_NR];
 +
 + seq_printf(m, %12u %8x %8x %8x %8x %8x\n, entry-timestamp,
 +entry-crc[0], entry-crc[1], entry-crc[2],
 +entry-crc[3], entry-crc[4]);
 + }
 +
 + return 0;
 +}
 +
  static int
  i915_wedged_get(void *data, u64 *val)
  {
 @@ -2247,6 +2277,9 @@ static struct drm_info_list i915_debugfs_list[] = {
   {i915_edp_psr_status, i915_edp_psr_status, 0},
   {i915_energy_uJ, i915_energy_uJ, 0},
   {i915_pc8_status, i915_pc8_status, 0},
 + {i915_pipe_A_crc, i915_pipe_crc, 0, (void *)PIPE_A},
 + {i915_pipe_B_crc, i915_pipe_crc, 0, (void *)PIPE_B},
 + {i915_pipe_C_crc, i915_pipe_crc, 0, (void *)PIPE_C},
  };
  #define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
  
 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index 6106d3d..6855d91 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -1219,6 +1219,18 @@ struct i915_package_c8 {
   } regsave;
  };
  
 +struct intel_pipe_crc_entry {
 + uint32_t timestamp;
 + uint32_t crc[5];
 +};
 +
 +#define INTEL_PIPE_CRC_ENTRIES_NR200
 +struct intel_pipe_crc {
 + struct intel_pipe_crc_entry entries[INTEL_PIPE_CRC_ENTRIES_NR];
 + enum intel_pipe_crc_source source;
 + atomic_t slot;
 +};
 +
  typedef struct drm_i915_private {
   struct drm_device *dev;
   struct kmem_cache *slab;
 @@ -1423,6 +1435,10 @@ typedef struct drm_i915_private {
   struct i915_dri1_state dri1;
   /* Old ums support infrastructure, same warning applies. */
   struct i915_ums_state ums;
 +
 +#ifdef CONFIG_DEBUG_FS
 + struct intel_pipe_crc pipe_crc[I915_MAX_PIPES];
 +#endif

Should we keep this in intel_crtc perhaps?

  } drm_i915_private_t;
  
  static inline struct drm_i915_private *to_i915(const struct drm_device *dev)
 diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
 index 26753b6..d2074f1 100644
 --- a/drivers/gpu/drm/i915/i915_irq.c
 +++ b/drivers/gpu/drm/i915/i915_irq.c
 @@ -1188,6 +1188,32 @@ static void dp_aux_irq_handler(struct drm_device *dev)
   wake_up_all(dev_priv-gmbus_wait_queue);
  }
  
 +#if defined(CONFIG_DEBUG_FS)
 +static void ivb_pipe_crc_update(struct drm_device *dev, enum pipe pipe)
 +{
 + struct drm_i915_private *dev_priv = dev-dev_private;
 + struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[pipe];
 + struct intel_pipe_crc_entry *entry;
 + ktime_t now;
 + int ts, slot;
 +
 + now = ktime_get();
 + ts = ktime_to_us(now);
 +
 + slot = (atomic_read(pipe_crc-slot) + 1) % INTEL_PIPE_CRC_ENTRIES_NR;

Looks like using atomic_t for 'slot' doesn't really help us in any way.

 + entry = pipe_crc-entries[slot];
 + entry-timestamp = ts;
 + entry-crc[0] = I915_READ(PIPE_CRC_RES_1_IVB(pipe));
 + entry-crc[1] = 

[Intel-gfx] [PATCH] drm/i915: Disable all GEM timers and work on unload

2013-10-16 Thread Chris Wilson
We have two once very similar functions, i915_gpu_idle() and
i915_gem_idle(). The former is used as the lower level operation to
flush work on the GPU, whereas the latter is the high level interface to
flush the GEM bookkeeping in addition to flushing the GPU. As such
i915_gem_idle() also clears out the request and activity lists and
cancels the delayed work. This is what we need for unloading the driver,
unfortunately we called i915_gpu_idle() instead.

In the process, make sure that when cancelling the delayed work and
timer, which is synchronous, that we do not hold any locks to prevent a
deadlock if the work item is already waiting upon the mutex. This
requires us to push the mutex down from the caller to i915_gem_idle().

v2: s/i915_gem_idle/i915_gem_suspend/

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70334
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Tested-by: xunx.f...@intel.com
---
 drivers/gpu/drm/i915/i915_dma.c |8 +--
 drivers/gpu/drm/i915/i915_drv.c |4 +---
 drivers/gpu/drm/i915/i915_drv.h |2 +-
 drivers/gpu/drm/i915/i915_gem.c |   44 +--
 4 files changed, 22 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5e35f29..fd6c46b 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1699,15 +1699,9 @@ int i915_driver_unload(struct drm_device *dev)
if (dev_priv-mm.inactive_shrinker.scan_objects)
unregister_shrinker(dev_priv-mm.inactive_shrinker);
 
-   mutex_lock(dev-struct_mutex);
-   ret = i915_gpu_idle(dev);
+   ret = i915_gem_suspend(dev);
if (ret)
DRM_ERROR(failed to idle hardware: %d\n, ret);
-   i915_gem_retire_requests(dev);
-   mutex_unlock(dev-struct_mutex);
-
-   /* Cancel the retire work handler, which should be idle now. */
-   cancel_delayed_work_sync(dev_priv-mm.retire_work);
 
io_mapping_free(dev_priv-gtt.mappable);
arch_phys_wc_del(dev_priv-gtt.mtrr);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 59649c0..cd05cc7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -479,9 +479,7 @@ static int i915_drm_freeze(struct drm_device *dev)
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
int error;
 
-   mutex_lock(dev-struct_mutex);
-   error = i915_gem_idle(dev);
-   mutex_unlock(dev-struct_mutex);
+   error = i915_gem_suspend(dev);
if (error) {
dev_err(dev-pdev-dev,
GEM idle failed, resume might fail\n);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e0152e7..daefba4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2039,7 +2039,7 @@ int i915_gem_l3_remap(struct intel_ring_buffer *ring, int 
slice);
 void i915_gem_init_swizzling(struct drm_device *dev);
 void i915_gem_cleanup_ringbuffer(struct drm_device *dev);
 int __must_check i915_gpu_idle(struct drm_device *dev);
-int __must_check i915_gem_idle(struct drm_device *dev);
+int __must_check i915_gem_suspend(struct drm_device *dev);
 int __i915_add_request(struct intel_ring_buffer *ring,
   struct drm_file *file,
   struct drm_i915_gem_object *batch_obj,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 63dbd3c..2ff35b6 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4401,17 +4401,18 @@ void i915_gem_vma_destroy(struct i915_vma *vma)
 }
 
 int
-i915_gem_idle(struct drm_device *dev)
+i915_gem_suspend(struct drm_device *dev)
 {
drm_i915_private_t *dev_priv = dev-dev_private;
-   int ret;
+   int ret = 0;
 
+   mutex_lock(dev-struct_mutex);
if (dev_priv-ums.mm_suspended)
-   return 0;
+   goto err;
 
ret = i915_gpu_idle(dev);
if (ret)
-   return ret;
+   goto err;
 
i915_gem_retire_requests(dev);
 
@@ -4419,16 +4420,25 @@ i915_gem_idle(struct drm_device *dev)
if (!drm_core_check_feature(dev, DRIVER_MODESET))
i915_gem_evict_everything(dev);
 
-   del_timer_sync(dev_priv-gpu_error.hangcheck_timer);
-
i915_kernel_lost_context(dev);
i915_gem_cleanup_ringbuffer(dev);
 
-   /* Cancel the retire work handler, which should be idle now. */
+   /* Hack!  Don't let anybody do execbuf while we don't control the chip.
+* We need to replace this with a semaphore, or something.
+* And not confound ums.mm_suspended!
+*/
+   dev_priv-ums.mm_suspended = true;
+   mutex_unlock(dev-struct_mutex);
+
+   del_timer_sync(dev_priv-gpu_error.hangcheck_timer);
cancel_delayed_work_sync(dev_priv-mm.retire_work);
  

Re: [Intel-gfx] [PATCH 4/5] drm/i915: take power well refs when needed

2013-10-16 Thread Imre Deak
On Tue, 2013-10-15 at 13:40 -0700, Jesse Barnes wrote:
 On Tue, 15 Oct 2013 16:54:00 -0300
 Paulo Zanoni przan...@gmail.com wrote:
 [...]
 No that's taken into account here.  In __intel_set_mode we take a
 private ref on the appropriate power well so that we'll preserve state
 until we do the first crtc_enable.  From then on, the ref is tracked
 there and we drop the private one in __intel_set_mode
 
   +   if (crtc-active)
   +   intel_display_power_get(dev,
   +   
   POWER_DOMAIN_PIPE(crtc-pipe));
   +
  
  What about the panel fitter power domains? Sometimes the panel fitter
  is the thing that makes you require a power well, even though you're
  on a pipe that doesn't need it.
  
  And on Haswell you also have to take into account
  TRANSCODER_EDP+PIPE_A versus TRANSCODER_A+PIPE_A, where the first
  doesn't need the power well but the second needs it.
 
 Yeah I'm still not sure how to handle this in generic code.  Maybe the
 power well mapping function Imre added will be enough, but it
 definitely gets tricky when we look at all the different platforms we
 have to (and will have to) handle.

Isn't the power domain abstraction a neat idea exactly for the above
case? Generic code just asks for the domain it needs and doesn't care
how it maps to power wells on the given platform. So for transcoder_edp
+pipe_a it'd end up asking for POWER_DOMAIN_PIPE_A and
POWER_DOMAIN_TRANSCODER_EDP, both of which is a nop on HSW, and for the
other case POWER_DOMAIN_PIPE_A and POWER_DOMAIN_TRANSCODER_A which would
enable the power well. You also have the POWER_DOMAIN_PIPE,
POWER_DOMAIN_TRANSCODER, POWER_DOMAIN_PIPE_PANEL_FITTER helpers already.

--Imre


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH] drm/i915: Use pipe_name() instead of the pipe number

2013-10-16 Thread Damien Lespiau
Yet other direct usages of the pipe number instead of pipe_name().
We've been tracking them lately but managed to miss these last ones.

v2: Catch them all! (Ville)

Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com (v1)
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
 drivers/gpu/drm/i915/intel_display.c | 4 ++--
 drivers/gpu/drm/i915/intel_dsi.c | 2 +-
 drivers/gpu/drm/i915/intel_panel.c   | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 4f1b636..5a40b29 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10730,11 +10730,11 @@ static void intel_modeset_readout_hw_state(struct 
drm_device *dev)
}
 
encoder-connectors_active = false;
-   DRM_DEBUG_KMS([ENCODER:%d:%s] hw state readout: %s, pipe=%i\n,
+   DRM_DEBUG_KMS([ENCODER:%d:%s] hw state readout: %s, pipe %c\n,
  encoder-base.base.id,
  drm_get_encoder_name(encoder-base),
  encoder-base.crtc ? enabled : disabled,
- pipe);
+ pipe_name(pipe));
}
 
list_for_each_entry(connector, dev-mode_config.connector_list,
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 9a2fdd2..d257b09 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -350,7 +350,7 @@ static void intel_dsi_mode_set(struct intel_encoder 
*intel_encoder)
unsigned int bpp = intel_crtc-config.pipe_bpp;
u32 val, tmp;
 
-   DRM_DEBUG_KMS(pipe %d\n, pipe);
+   DRM_DEBUG_KMS(pipe %c\n, pipe_name(pipe));
 
/* Update the DSI PLL */
vlv_enable_dsi_pll(intel_encoder);
diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 1f29960..de15186 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -574,7 +574,7 @@ void intel_panel_enable_backlight(struct drm_device *dev,
intel_pipe_to_cpu_transcoder(dev_priv, pipe);
unsigned long flags;
 
-   DRM_DEBUG_KMS(pipe=%d\n, pipe);
+   DRM_DEBUG_KMS(pipe %c\n, pipe_name(pipe));
 
spin_lock_irqsave(dev_priv-backlight.lock, flags);
 
-- 
1.8.3.1

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


Re: [Intel-gfx] [PATCH] drm/i915: Disable all GEM timers and work on unload

2013-10-16 Thread Daniel Vetter
On Wed, Oct 16, 2013 at 11:50:01AM +0100, Chris Wilson wrote:
 We have two once very similar functions, i915_gpu_idle() and
 i915_gem_idle(). The former is used as the lower level operation to
 flush work on the GPU, whereas the latter is the high level interface to
 flush the GEM bookkeeping in addition to flushing the GPU. As such
 i915_gem_idle() also clears out the request and activity lists and
 cancels the delayed work. This is what we need for unloading the driver,
 unfortunately we called i915_gpu_idle() instead.
 
 In the process, make sure that when cancelling the delayed work and
 timer, which is synchronous, that we do not hold any locks to prevent a
 deadlock if the work item is already waiting upon the mutex. This
 requires us to push the mutex down from the caller to i915_gem_idle().
 
 v2: s/i915_gem_idle/i915_gem_suspend/
 
 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70334
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
 Tested-by: xunx.f...@intel.com

Queued for -next, 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 3/4] drm/i915: HSW GT3 Slices: exec flag to warn kernel that userspace is using predication

2013-10-16 Thread Rodrigo Vivi
Hi Chris,

Thank you very much for all suggestions. Will do the changes. But for
that question below I don't have the clear answer:

On Wed, Oct 16, 2013 at 6:15 AM, Chris Wilson ch...@chris-wilson.co.uk wrote:
 On Tue, Oct 15, 2013 at 05:50:49PM -0300, Rodrigo Vivi wrote:
 If Userspace isn't using MI_PREDICATE all slices must be enabled for
 backward compatibility.

 If I915_EXEC_USE_PREDICATE isn't set and defaul is set to half, kernel will 
 force
 all slices on.

 v2: fix the inverted logic for backwards compatibility
 USE_PREDICATE unset force gt_full when defaul is half
 instead of GT_FULL flag.

 CC: Eric Anholt e...@anholt.net
 CC: Kenneth Graunke kenn...@whitecape.org
 Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
 ---
  drivers/gpu/drm/i915/i915_drv.h|  8 
  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 67 
 ++
  drivers/gpu/drm/i915/i915_reg.h| 11 +
  drivers/gpu/drm/i915/i915_sysfs.c  | 11 -
  drivers/gpu/drm/i915/intel_display.c   |  6 +++
  drivers/gpu/drm/i915/intel_drv.h   |  1 +
  drivers/gpu/drm/i915/intel_pm.c| 39 -
  include/uapi/drm/i915_drm.h|  8 +++-
  8 files changed, 146 insertions(+), 5 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_drv.h 
 b/drivers/gpu/drm/i915/i915_drv.h
 index 685fb1d..bd4774e 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -1219,6 +1219,12 @@ struct i915_package_c8 {
   } regsave;
  };

 +struct i915_gt_slices {
 + int state_default;

 Either use it as an integer (a count of slices enabled by default) or
 make it an enum.

 + int forcing_full;

 bool legacy_userspace_busy; ?

 + struct mutex m_lock;

 Ugh. Just struct mutex lock; /* locks all access to this struct and
 slice registers */ will suffice

 +};
 +
  typedef struct drm_i915_private {
   struct drm_device *dev;
   struct kmem_cache *slab;
 @@ -1418,6 +1424,8 @@ typedef struct drm_i915_private {

   struct i915_package_c8 pc8;

 + struct i915_gt_slices gt_slices;
 +
   /* Old dri1 support infrastructure, beware the dragons ya fools 
 entering
* here! */
   struct i915_dri1_state dri1;
 diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
 b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 index 0ce0d47..eb09a51 100644
 --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
 @@ -923,6 +923,66 @@ i915_reset_gen7_sol_offsets(struct drm_device *dev,
  }

  static int
 +i915_gt_full_immediate(struct drm_device *dev, struct intel_ring_buffer 
 *ring)

 That's a misnomer.

 +{
 + drm_i915_private_t *dev_priv = dev-dev_private;
 + int ret;
 +
 + if (!HAS_SLICE_SHUTDOWN(dev) || ring == dev_priv-ring[BCS])
 + return 0;
 +
 + ret = intel_ring_begin(ring, 3);
 + if (ret)
 + return ret;
 + intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
 + intel_ring_emit(ring, HSW_GT_SLICE_INFO);
 + intel_ring_emit(ring, SLICE_SEL_BOTH);
 + intel_ring_advance(ring);
 +
 + ret = intel_ring_begin(ring, 3);
 + if (ret)
 + return ret;
 + intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
 + intel_ring_emit(ring, MI_PREDICATE_RESULT_2);
 + intel_ring_emit(ring, LOWER_SLICE_ENABLED);
 + intel_ring_advance(ring);
 +
 + ret = intel_ring_begin(ring, 3);
 + if (ret)
 + return ret;
 + intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
 + intel_ring_emit(ring, HSW_SLICESHUTDOWN);
 + intel_ring_emit(ring, ~SLICE_SHUTDOWN);
 + intel_ring_advance(ring);
 +
 + ret = intel_ring_begin(ring, 3);
 + if (ret)
 + return ret;
 + intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
 + intel_ring_emit(ring, RC_IDLE_MAX_COUNT);
 + intel_ring_emit(ring, CS_IDLE_COUNT_1US);
 + intel_ring_advance(ring);
 +
 + ret = intel_ring_begin(ring, 3);
 + if (ret)
 + return ret;
 + intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
 + intel_ring_emit(ring, WAIT_FOR_RC6_EXIT);
 + intel_ring_emit(ring, WAIT_RC6_EXIT | MASK_WAIT_RC6_EXIT);
 + intel_ring_advance(ring);
 +
 + ret = intel_ring_begin(ring, 3);
 + if (ret)
 + return ret;
 + intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
 + intel_ring_emit(ring, RC_IDLE_MAX_COUNT);
 + intel_ring_emit(ring, CS_IDLE_COUNT_5US);
 + intel_ring_advance(ring);
 +
 + return 0;
 +}
 +
 +static int
  i915_gem_do_execbuffer(struct drm_device *dev, void *data,
  struct drm_file *file,
  struct drm_i915_gem_execbuffer2 *args,
 @@ -999,6 +1059,13 @@ i915_gem_do_execbuffer(struct drm_device *dev, void 
 *data,
   return -EINVAL;
   }

 + if ((args-flags  I915_EXEC_USE_PREDICATE) == 0 
 + dev_priv-gt_slices.state_default == 0 
 + !dev_priv-gt_slices.forcing_full) {


Re: [Intel-gfx] [PATCH 3/4] drm/i915: HSW GT3 Slices: exec flag to warn kernel that userspace is using predication

2013-10-16 Thread Chris Wilson
On Wed, Oct 16, 2013 at 09:12:46AM -0300, Rodrigo Vivi wrote:
  + dev_priv-gt_slices.forcing_full = true;
  + i915_gt_full_immediate(dev, ring);
 
  What happens when this fails? If it only partially emits the commands,
  etc.
 
 This is a very good question. If it fails, my only concern would be
 the sync between HSW_GT_SLICE_INFO and MI_PREDICATE_RESULT_2. But I
 don't know how to do this during the exec buf without delaying the
 execution. Do you have any suggestion?

Reduce the series of if() to just one, act upon the return value, only
set legacy_userspace_busy to true after making the change. It will
eventually get cleaned up if the dispatch later fails, but we must make
sure that we accurately track hardware state.
-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 04/16] drm/i915: Sample the frame counter instead of a timestamp for CRCs

2013-10-16 Thread Ville Syrjälä
On Tue, Oct 15, 2013 at 06:55:30PM +0100, Damien Lespiau wrote:
 Signed-off-by: Damien Lespiau damien.lesp...@intel.com
 ---
  drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
  drivers/gpu/drm/i915/i915_drv.h | 2 +-
  drivers/gpu/drm/i915/i915_irq.c | 8 ++--
  3 files changed, 5 insertions(+), 9 deletions(-)
 
 diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
 b/drivers/gpu/drm/i915/i915_debugfs.c
 index 991abff..58c6fd4 100644
 --- a/drivers/gpu/drm/i915/i915_debugfs.c
 +++ b/drivers/gpu/drm/i915/i915_debugfs.c
 @@ -1748,14 +1748,14 @@ static int i915_pipe_crc(struct seq_file *m, void 
 *data)
   return 0;
   }
  
 - seq_puts(m,  timestamp CRC1 CRC2 CRC3 CRC4 
 CRC5\n);
 + seq_puts(m,   frameCRC1 CRC2 CRC3 CRC4 CRC5\n);
   head = atomic_read(pipe_crc-head);
   tail = atomic_read(pipe_crc-tail);
  
   while (CIRC_CNT(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) = 1) {
   struct intel_pipe_crc_entry *entry = pipe_crc-entries[tail];
  
 - seq_printf(m, %12u %8x %8x %8x %8x %8x\n, entry-timestamp,
 + seq_printf(m, %8u %8x %8x %8x %8x %8x\n, entry-frame,
  entry-crc[0], entry-crc[1], entry-crc[2],
  entry-crc[3], entry-crc[4]);
  
 diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
 index 7a1ed3a..cd87919 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -1228,7 +1228,7 @@ enum intel_pipe_crc_source {
  };
  
  struct intel_pipe_crc_entry {
 - uint32_t timestamp;
 + uint32_t frame;
   uint32_t crc[5];
  };
  
 diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
 index 73d76af..0b21828 100644
 --- a/drivers/gpu/drm/i915/i915_irq.c
 +++ b/drivers/gpu/drm/i915/i915_irq.c
 @@ -1195,8 +1195,7 @@ static void ivb_pipe_crc_update(struct drm_device *dev, 
 enum pipe pipe)
   struct drm_i915_private *dev_priv = dev-dev_private;
   struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[pipe];
   struct intel_pipe_crc_entry *entry;
 - ktime_t now;
 - int ts, head, tail;
 + int head, tail;
  
   head = atomic_read(pipe_crc-head);
   tail = atomic_read(pipe_crc-tail);
 @@ -1208,10 +1207,7 @@ static void ivb_pipe_crc_update(struct drm_device 
 *dev, enum pipe pipe)
  
   entry = pipe_crc-entries[head];
  
 - now = ktime_get();
 - ts = ktime_to_us(now);
 -
 - entry-timestamp = ts;
 + entry-frame = I915_READ(PIPEFRAME(pipe));

BTW that's the wrong register for ctg+. It should be PIPE_FRMCOUNT_GM45.
But it would be better if you just call
dev-driver-get_vblank_counter(). Then you get the correct answer for
everything except gen2, and for gen2 we could implement a software
frame counter if need be.

   entry-crc[0] = I915_READ(PIPE_CRC_RES_1_IVB(pipe));
   entry-crc[1] = I915_READ(PIPE_CRC_RES_2_IVB(pipe));
   entry-crc[2] = I915_READ(PIPE_CRC_RES_3_IVB(pipe));
 -- 
 1.8.3.1
 
 ___
 Intel-gfx mailing list
 Intel-gfx@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 04/16] drm/i915: Sample the frame counter instead of a timestamp for CRCs

2013-10-16 Thread Daniel Vetter
On Wed, Oct 16, 2013 at 04:29:32PM +0300, Ville Syrjälä wrote:
 On Tue, Oct 15, 2013 at 06:55:30PM +0100, Damien Lespiau wrote:
  Signed-off-by: Damien Lespiau damien.lesp...@intel.com
  ---
   drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
   drivers/gpu/drm/i915/i915_drv.h | 2 +-
   drivers/gpu/drm/i915/i915_irq.c | 8 ++--
   3 files changed, 5 insertions(+), 9 deletions(-)
  
  diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
  b/drivers/gpu/drm/i915/i915_debugfs.c
  index 991abff..58c6fd4 100644
  --- a/drivers/gpu/drm/i915/i915_debugfs.c
  +++ b/drivers/gpu/drm/i915/i915_debugfs.c
  @@ -1748,14 +1748,14 @@ static int i915_pipe_crc(struct seq_file *m, void 
  *data)
  return 0;
  }
   
  -   seq_puts(m,  timestamp CRC1 CRC2 CRC3 CRC4 
  CRC5\n);
  +   seq_puts(m,   frameCRC1 CRC2 CRC3 CRC4 CRC5\n);
  head = atomic_read(pipe_crc-head);
  tail = atomic_read(pipe_crc-tail);
   
  while (CIRC_CNT(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) = 1) {
  struct intel_pipe_crc_entry *entry = pipe_crc-entries[tail];
   
  -   seq_printf(m, %12u %8x %8x %8x %8x %8x\n, entry-timestamp,
  +   seq_printf(m, %8u %8x %8x %8x %8x %8x\n, entry-frame,
 entry-crc[0], entry-crc[1], entry-crc[2],
 entry-crc[3], entry-crc[4]);
   
  diff --git a/drivers/gpu/drm/i915/i915_drv.h 
  b/drivers/gpu/drm/i915/i915_drv.h
  index 7a1ed3a..cd87919 100644
  --- a/drivers/gpu/drm/i915/i915_drv.h
  +++ b/drivers/gpu/drm/i915/i915_drv.h
  @@ -1228,7 +1228,7 @@ enum intel_pipe_crc_source {
   };
   
   struct intel_pipe_crc_entry {
  -   uint32_t timestamp;
  +   uint32_t frame;
  uint32_t crc[5];
   };
   
  diff --git a/drivers/gpu/drm/i915/i915_irq.c 
  b/drivers/gpu/drm/i915/i915_irq.c
  index 73d76af..0b21828 100644
  --- a/drivers/gpu/drm/i915/i915_irq.c
  +++ b/drivers/gpu/drm/i915/i915_irq.c
  @@ -1195,8 +1195,7 @@ static void ivb_pipe_crc_update(struct drm_device 
  *dev, enum pipe pipe)
  struct drm_i915_private *dev_priv = dev-dev_private;
  struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[pipe];
  struct intel_pipe_crc_entry *entry;
  -   ktime_t now;
  -   int ts, head, tail;
  +   int head, tail;
   
  head = atomic_read(pipe_crc-head);
  tail = atomic_read(pipe_crc-tail);
  @@ -1208,10 +1207,7 @@ static void ivb_pipe_crc_update(struct drm_device 
  *dev, enum pipe pipe)
   
  entry = pipe_crc-entries[head];
   
  -   now = ktime_get();
  -   ts = ktime_to_us(now);
  -
  -   entry-timestamp = ts;
  +   entry-frame = I915_READ(PIPEFRAME(pipe));
 
 BTW that's the wrong register for ctg+. It should be PIPE_FRMCOUNT_GM45.
 But it would be better if you just call
 dev-driver-get_vblank_counter(). Then you get the correct answer for
 everything except gen2, and for gen2 we could implement a software
 frame counter if need be.

Hm, maybe we should even cobble it out of the drm vblank support code, to
make sure that the vblank frame numbers from the crc debugfs align with
timestamps for pageflips. But this is definitely a good idea. And afaik
gen2 doesn't have crc support (not even gen3 iirc). I'll do this in my
bikeshed series.
-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 04/16] drm/i915: Sample the frame counter instead of a timestamp for CRCs

2013-10-16 Thread Ville Syrjälä
On Wed, Oct 16, 2013 at 03:51:40PM +0200, Daniel Vetter wrote:
 On Wed, Oct 16, 2013 at 04:29:32PM +0300, Ville Syrjälä wrote:
  On Tue, Oct 15, 2013 at 06:55:30PM +0100, Damien Lespiau wrote:
   Signed-off-by: Damien Lespiau damien.lesp...@intel.com
   ---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 8 ++--
3 files changed, 5 insertions(+), 9 deletions(-)
   
   diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
   b/drivers/gpu/drm/i915/i915_debugfs.c
   index 991abff..58c6fd4 100644
   --- a/drivers/gpu/drm/i915/i915_debugfs.c
   +++ b/drivers/gpu/drm/i915/i915_debugfs.c
   @@ -1748,14 +1748,14 @@ static int i915_pipe_crc(struct seq_file *m, void 
   *data)
 return 0;
 }

   - seq_puts(m,  timestamp CRC1 CRC2 CRC3 CRC4 
   CRC5\n);
   + seq_puts(m,   frameCRC1 CRC2 CRC3 CRC4 CRC5\n);
 head = atomic_read(pipe_crc-head);
 tail = atomic_read(pipe_crc-tail);

 while (CIRC_CNT(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) = 1) {
 struct intel_pipe_crc_entry *entry = pipe_crc-entries[tail];

   - seq_printf(m, %12u %8x %8x %8x %8x %8x\n, entry-timestamp,
   + seq_printf(m, %8u %8x %8x %8x %8x %8x\n, entry-frame,
entry-crc[0], entry-crc[1], entry-crc[2],
entry-crc[3], entry-crc[4]);

   diff --git a/drivers/gpu/drm/i915/i915_drv.h 
   b/drivers/gpu/drm/i915/i915_drv.h
   index 7a1ed3a..cd87919 100644
   --- a/drivers/gpu/drm/i915/i915_drv.h
   +++ b/drivers/gpu/drm/i915/i915_drv.h
   @@ -1228,7 +1228,7 @@ enum intel_pipe_crc_source {
};

struct intel_pipe_crc_entry {
   - uint32_t timestamp;
   + uint32_t frame;
 uint32_t crc[5];
};

   diff --git a/drivers/gpu/drm/i915/i915_irq.c 
   b/drivers/gpu/drm/i915/i915_irq.c
   index 73d76af..0b21828 100644
   --- a/drivers/gpu/drm/i915/i915_irq.c
   +++ b/drivers/gpu/drm/i915/i915_irq.c
   @@ -1195,8 +1195,7 @@ static void ivb_pipe_crc_update(struct drm_device 
   *dev, enum pipe pipe)
 struct drm_i915_private *dev_priv = dev-dev_private;
 struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[pipe];
 struct intel_pipe_crc_entry *entry;
   - ktime_t now;
   - int ts, head, tail;
   + int head, tail;

 head = atomic_read(pipe_crc-head);
 tail = atomic_read(pipe_crc-tail);
   @@ -1208,10 +1207,7 @@ static void ivb_pipe_crc_update(struct drm_device 
   *dev, enum pipe pipe)

 entry = pipe_crc-entries[head];

   - now = ktime_get();
   - ts = ktime_to_us(now);
   -
   - entry-timestamp = ts;
   + entry-frame = I915_READ(PIPEFRAME(pipe));
  
  BTW that's the wrong register for ctg+. It should be PIPE_FRMCOUNT_GM45.
  But it would be better if you just call
  dev-driver-get_vblank_counter(). Then you get the correct answer for
  everything except gen2, and for gen2 we could implement a software
  frame counter if need be.
 
 Hm, maybe we should even cobble it out of the drm vblank support code, to
 make sure that the vblank frame numbers from the crc debugfs align with
 timestamps for pageflips. But this is definitely a good idea. And afaik
 gen2 doesn't have crc support (not even gen3 iirc). I'll do this in my
 bikeshed series.

I see crc registers in both gen2 and 3 bspec.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 1/2] drm/i915/dp: don't mention eDP bpp clamping if it doesn't affect bpp

2013-10-16 Thread Jani Nikula
Signed-off-by: Jani Nikula jani.nik...@intel.com

---

This is useful with the follow-up patch that frobs
dev_priv-vbt.edp_bpp, and the value no longer comes directly from VBT.
---
 drivers/gpu/drm/i915/intel_dp.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e4fdedc..f63aa8c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -822,10 +822,11 @@ intel_dp_compute_config(struct intel_encoder *encoder,
/* Walk through all bpp values. Luckily they're all nicely spaced with 2
 * bpc in between. */
bpp = pipe_config-pipe_bpp;
-   if (is_edp(intel_dp)  dev_priv-vbt.edp_bpp) {
+   if (is_edp(intel_dp)  dev_priv-vbt.edp_bpp 
+   dev_priv-vbt.edp_bpp  bpp) {
DRM_DEBUG_KMS(clamping bpp for eDP panel to BIOS-provided 
%i\n,
  dev_priv-vbt.edp_bpp);
-   bpp = min_t(int, bpp, dev_priv-vbt.edp_bpp);
+   bpp = dev_priv-vbt.edp_bpp;
}
 
for (; bpp = 6*3; bpp -= 2*3) {
-- 
1.7.9.5

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


Re: [Intel-gfx] [PATCH 04/16] drm/i915: Sample the frame counter instead of a timestamp for CRCs

2013-10-16 Thread Ville Syrjälä
On Wed, Oct 16, 2013 at 03:51:40PM +0200, Daniel Vetter wrote:
 On Wed, Oct 16, 2013 at 04:29:32PM +0300, Ville Syrjälä wrote:
  On Tue, Oct 15, 2013 at 06:55:30PM +0100, Damien Lespiau wrote:
   Signed-off-by: Damien Lespiau damien.lesp...@intel.com
   ---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 8 ++--
3 files changed, 5 insertions(+), 9 deletions(-)
   
   diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
   b/drivers/gpu/drm/i915/i915_debugfs.c
   index 991abff..58c6fd4 100644
   --- a/drivers/gpu/drm/i915/i915_debugfs.c
   +++ b/drivers/gpu/drm/i915/i915_debugfs.c
   @@ -1748,14 +1748,14 @@ static int i915_pipe_crc(struct seq_file *m, void 
   *data)
 return 0;
 }

   - seq_puts(m,  timestamp CRC1 CRC2 CRC3 CRC4 
   CRC5\n);
   + seq_puts(m,   frameCRC1 CRC2 CRC3 CRC4 CRC5\n);
 head = atomic_read(pipe_crc-head);
 tail = atomic_read(pipe_crc-tail);

 while (CIRC_CNT(head, tail, INTEL_PIPE_CRC_ENTRIES_NR) = 1) {
 struct intel_pipe_crc_entry *entry = pipe_crc-entries[tail];

   - seq_printf(m, %12u %8x %8x %8x %8x %8x\n, entry-timestamp,
   + seq_printf(m, %8u %8x %8x %8x %8x %8x\n, entry-frame,
entry-crc[0], entry-crc[1], entry-crc[2],
entry-crc[3], entry-crc[4]);

   diff --git a/drivers/gpu/drm/i915/i915_drv.h 
   b/drivers/gpu/drm/i915/i915_drv.h
   index 7a1ed3a..cd87919 100644
   --- a/drivers/gpu/drm/i915/i915_drv.h
   +++ b/drivers/gpu/drm/i915/i915_drv.h
   @@ -1228,7 +1228,7 @@ enum intel_pipe_crc_source {
};

struct intel_pipe_crc_entry {
   - uint32_t timestamp;
   + uint32_t frame;
 uint32_t crc[5];
};

   diff --git a/drivers/gpu/drm/i915/i915_irq.c 
   b/drivers/gpu/drm/i915/i915_irq.c
   index 73d76af..0b21828 100644
   --- a/drivers/gpu/drm/i915/i915_irq.c
   +++ b/drivers/gpu/drm/i915/i915_irq.c
   @@ -1195,8 +1195,7 @@ static void ivb_pipe_crc_update(struct drm_device 
   *dev, enum pipe pipe)
 struct drm_i915_private *dev_priv = dev-dev_private;
 struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[pipe];
 struct intel_pipe_crc_entry *entry;
   - ktime_t now;
   - int ts, head, tail;
   + int head, tail;

 head = atomic_read(pipe_crc-head);
 tail = atomic_read(pipe_crc-tail);
   @@ -1208,10 +1207,7 @@ static void ivb_pipe_crc_update(struct drm_device 
   *dev, enum pipe pipe)

 entry = pipe_crc-entries[head];

   - now = ktime_get();
   - ts = ktime_to_us(now);
   -
   - entry-timestamp = ts;
   + entry-frame = I915_READ(PIPEFRAME(pipe));
  
  BTW that's the wrong register for ctg+. It should be PIPE_FRMCOUNT_GM45.
  But it would be better if you just call
  dev-driver-get_vblank_counter(). Then you get the correct answer for
  everything except gen2, and for gen2 we could implement a software
  frame counter if need be.
 
 Hm, maybe we should even cobble it out of the drm vblank support code, to
 make sure that the vblank frame numbers from the crc debugfs align with
 timestamps for pageflips.

Well the frame numbers reported to userspace by vblank/page flip code
are based on a software counter maintained by the drm vblank code.
.get_vblank_counter() is the real hardware counter. I guess you mean
that we should try to report the software counter for userspace here
as well. Sounds reasonable.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH 2/2] drm/i915/dp: workaround BIOS eDP bpp clamping issue

2013-10-16 Thread Jani Nikula
This isn't a real fix to the problem, but rather a stopgap measure while
trying to find a proper solution.

There are several laptops out there that fail to light up the eDP panel
in UEFI boot mode. They seem to be mostly IVB machines, including but
apparently not limited to Dell XPS 13, Asus TX300, Asus UX31A, Asus
UX32VD, Acer Aspire S7. They seem to work in CSM or legacy boot.

The difference between UEFI and CSM is that the BIOS provides a
different VBT to the kernel. The UEFI VBT typically specifies 18 bpp and
1.62 GHz link for eDP, while CSM VBT has 24 bpp and 2.7 GHz link. We end
up clamping to 18 bpp in UEFI mode, which we can fit in the 1.62 Ghz
link, and for reasons yet unknown fail to light up the panel.

Dithering from 24 to 18 bpp itself seems to work; if we use 18 bpp with
2.7 GHz link, the eDP panel lights up. So essentially this is a link
speed issue, and *not* a bpp clamping issue.

The bug raised its head since
commit 657445fe8660100ad174600ebfa61536392b7624
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date:   Sat May 4 10:09:18 2013 +0200

Revert drm/i915: revert eDP bpp clamping code changes

which started clamping bpp *before* computing the link requirements, and
thus affecting the required bandwidth. Clamping after the computations
kept the link at 2.7 GHz.

Even though the BIOS tells us to use 18 bpp through the VBT, it happily
boots up at 24 bpp and 2.7 GHz itself! Use this information to
selectively ignore the VBT provided value.

We can't ignore the VBT eDP bpp altogether, as there are other laptops
that do require the clamping to be used due to EDID reporting higher bpp
than the panel can support.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59841
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67950
CC: sta...@vger.kernel.org
Signed-off-by: Jani Nikula jani.nik...@intel.com

---

For backporting to v3.12, you also need
commit 84a44adc16ab118cf7e0518861216cbc91cee6e4
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date:   Fri Sep 6 23:29:00 2013 +0300

drm/i915: Add support for pipe_bpp readout
---
 drivers/gpu/drm/i915/intel_dp.c |   21 +
 1 file changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f63aa8c..cb895d8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1476,6 +1476,27 @@ static void intel_dp_get_config(struct intel_encoder 
*encoder,
ironlake_check_encoder_dotclock(pipe_config, dotclock);
 
pipe_config-adjusted_mode.crtc_clock = dotclock;
+
+   if (is_edp(intel_dp)  dev_priv-vbt.edp_bpp 
+   pipe_config-pipe_bpp  dev_priv-vbt.edp_bpp) {
+   /*
+* This is a big fat ugly hack.
+*
+* Some machines in UEFI boot mode provide us a VBT that has 18
+* bpp and 1.62 GHz link bandwidth for eDP, which for reasons
+* unknown we fail to light up. Yet the same BIOS boots up with
+* 24 bpp and 2.7 GHz link. Use the same bpp as the BIOS uses as
+* max, not what it tells us to use.
+*
+* Note: This will still be broken if the eDP panel is not lit
+* up by the BIOS, and thus we can't get the mode at module
+* load.
+*/
+   DRM_DEBUG_KMS(pipe has %d bpp for eDP panel, overriding 
BIOS-provided max %d bpp\n,
+ pipe_config-pipe_bpp, dev_priv-vbt.edp_bpp);
+   dev_priv-vbt.edp_bpp = pipe_config-pipe_bpp;
+   }
+
 }
 
 static bool is_edp_psr(struct drm_device *dev)
-- 
1.7.9.5

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


[Intel-gfx] [PATCH 0/6] preparation for multiple power-wells

2013-10-16 Thread Imre Deak
This is a prepration for adding support for multiple power-wells needed
by future HW platforms. I pushed the rest of the enabling patches to [1].
I'd like to post the generic parts of those once we agreed how to do the
power-well abstraction.

Except a spinlock-mutex change these patches shouldn't cause any
functional change. I tested it on VLV/HSW VGA by doing a manual DPMS
on/off and checking that the power-well indeed toggles. Also on HSW I
checked that the audio power well release/request still works by doing a
rmmod/insmod snd_hda_intel.

[1] https://github.com/ideak/linux/commits/powerwells

Imre Deak (6):
  drm/i915: make the intel_display_power_domain enum compact
  drm/i915: factor out is_always_on_domain
  drm/i915: change power_well-lock to be mutex
  drm/i915: factor out modeset_update_power_wells
  drm/i915: enable only the needed power domains during modeset
  drm/i915: use power get/put instead of set for power on after init

 drivers/gpu/drm/i915/i915_dma.c  |   2 +-
 drivers/gpu/drm/i915/i915_drv.c  |   2 +-
 drivers/gpu/drm/i915/i915_drv.h  |  23 --
 drivers/gpu/drm/i915/intel_display.c |  69 --
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_pm.c  | 133 ++-
 6 files changed, 124 insertions(+), 107 deletions(-)

-- 
1.8.4

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


[Intel-gfx] [PATCH 1/6] drm/i915: make the intel_display_power_domain enum compact

2013-10-16 Thread Imre Deak
Upcoming patches will add tracking for a set of power domains via a
bitmask; to make things simple there remove the current gap in the
enum values.

Signed-off-by: Imre Deak imre.d...@intel.com
---
 drivers/gpu/drm/i915/i915_drv.h | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2ea66f2..9b04d05 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -98,14 +98,16 @@ enum intel_display_power_domain {
POWER_DOMAIN_TRANSCODER_A,
POWER_DOMAIN_TRANSCODER_B,
POWER_DOMAIN_TRANSCODER_C,
-   POWER_DOMAIN_TRANSCODER_EDP = POWER_DOMAIN_TRANSCODER_A + 0xF,
+   POWER_DOMAIN_TRANSCODER_EDP,
POWER_DOMAIN_VGA,
 };
 
 #define POWER_DOMAIN_PIPE(pipe) ((pipe) + POWER_DOMAIN_PIPE_A)
 #define POWER_DOMAIN_PIPE_PANEL_FITTER(pipe) \
((pipe) + POWER_DOMAIN_PIPE_A_PANEL_FITTER)
-#define POWER_DOMAIN_TRANSCODER(tran) ((tran) + POWER_DOMAIN_TRANSCODER_A)
+#define POWER_DOMAIN_TRANSCODER(tran) \
+   ((tran) == TRANSCODER_EDP ? POWER_DOMAIN_TRANSCODER_EDP : \
+(tran) + POWER_DOMAIN_TRANSCODER_A)
 
 enum hpd_pin {
HPD_NONE = 0,
-- 
1.8.4

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


[Intel-gfx] [PATCH 4/6] drm/i915: factor out modeset_update_power_wells

2013-10-16 Thread Imre Deak
We'll need the same functionality for other HW generations. The support
for these will be added by upcoming patches.

Signed-off-by: Imre Deak imre.d...@intel.com
---
 drivers/gpu/drm/i915/intel_display.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b334c50..8e734f2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6561,7 +6561,7 @@ static void hsw_package_c8_gpu_busy(struct 
drm_i915_private *dev_priv)
}
 }
 
-static void haswell_modeset_global_resources(struct drm_device *dev)
+static void modeset_update_power_wells(struct drm_device *dev)
 {
bool enable = false;
struct intel_crtc *crtc;
@@ -6576,7 +6576,11 @@ static void haswell_modeset_global_resources(struct 
drm_device *dev)
}
 
intel_set_power_well(dev, enable);
+}
 
+static void haswell_modeset_global_resources(struct drm_device *dev)
+{
+   modeset_update_power_wells(dev);
hsw_update_package_c8(dev);
 }
 
-- 
1.8.4

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


[Intel-gfx] [PATCH 5/6] drm/i915: enable only the needed power domains during modeset

2013-10-16 Thread Imre Deak
So far the modeset code enabled all power domains if it needed any. It
wasn't a problem since HW generations so far only had one always-on
power well and one dynamic power well that can be enabled/disabled. For
domains powered by always-on power wells (panel fitter on pipe A and the
eDP transcoder) we didn't do anything, for all other domains we just
enabled the single dynamic power well.

Future HW generations will change this, as they add multiple dynamic
power wells. Support for these will be added later, this patch prepares
for those by making sure we only enable the required domains.

Note that after this change on HSW we'll enable all power domains even
if it was the domain for the panel fitter on pipe A or the eDP
transcoder. This isn't a problem since the power domain framework
already checks if the domain is on an always-on power well and doesn't
do anything in this case.

Signed-off-by: Imre Deak imre.d...@intel.com
---
 drivers/gpu/drm/i915/intel_display.c | 46 
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 2 files changed, 42 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8e734f2..e2a4f3b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6561,21 +6561,57 @@ static void hsw_package_c8_gpu_busy(struct 
drm_i915_private *dev_priv)
}
 }
 
+#define for_each_power_domain(domain, mask)\
+   for ((domain) = 0; (domain)  POWER_DOMAIN_NUM; (domain)++) \
+   if ((1  (domain))  (mask))
+
+static unsigned long get_pipe_power_domains(struct drm_device *dev,
+   enum pipe pipe, bool pfit_enabled)
+{
+   unsigned long mask;
+   enum transcoder transcoder;
+
+   transcoder = intel_pipe_to_cpu_transcoder(dev-dev_private, pipe);
+
+   mask = BIT(POWER_DOMAIN_PIPE(pipe));
+   mask |= BIT(POWER_DOMAIN_TRANSCODER(transcoder));
+   if (pfit_enabled)
+   mask |= BIT(POWER_DOMAIN_PIPE_PANEL_FITTER(pipe));
+
+   return mask;
+}
+
 static void modeset_update_power_wells(struct drm_device *dev)
 {
-   bool enable = false;
+   unsigned long pipe_domains[I915_MAX_PIPES] = { 0, };
struct intel_crtc *crtc;
 
+   /*
+* First get all needed power domains, then put all unneeded, to avoid
+* any unnecessary toggling of the power wells.
+*/
list_for_each_entry(crtc, dev-mode_config.crtc_list, base.head) {
+   enum intel_display_power_domain domain;
+
if (!crtc-base.enabled)
continue;
 
-   if (crtc-pipe != PIPE_A || crtc-config.pch_pfit.enabled ||
-   crtc-config.cpu_transcoder != TRANSCODER_EDP)
-   enable = true;
+   pipe_domains[crtc-pipe] = get_pipe_power_domains(dev,
+   crtc-pipe,
+   crtc-config.pch_pfit.enabled);
+
+   for_each_power_domain(domain, pipe_domains[crtc-pipe])
+   intel_display_power_get(dev, domain);
}
 
-   intel_set_power_well(dev, enable);
+   list_for_each_entry(crtc, dev-mode_config.crtc_list, base.head) {
+   enum intel_display_power_domain domain;
+
+   for_each_power_domain(domain, crtc-enabled_power_domains)
+   intel_display_power_put(dev, domain);
+
+   crtc-enabled_power_domains = pipe_domains[crtc-pipe];
+   }
 }
 
 static void haswell_modeset_global_resources(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 189257d..63a5bfd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -320,6 +320,7 @@ struct intel_crtc {
 * some outputs connected to this crtc.
 */
bool active;
+   unsigned long enabled_power_domains;
bool eld_vld;
bool primary_enabled; /* is the primary plane (partially) visible? */
bool lowfreq_avail;
-- 
1.8.4

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


[Intel-gfx] [PATCH 2/6] drm/i915: factor out is_always_on_domain

2013-10-16 Thread Imre Deak
It is just cleaner this way and makes it easier to add support for
other HW generations with always-on power wells powering a different
set of domains.

Signed-off-by: Imre Deak imre.d...@intel.com
---
 drivers/gpu/drm/i915/i915_drv.h |  8 
 drivers/gpu/drm/i915/intel_pm.c | 84 +++--
 2 files changed, 38 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9b04d05..ca05f3a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -100,8 +100,12 @@ enum intel_display_power_domain {
POWER_DOMAIN_TRANSCODER_C,
POWER_DOMAIN_TRANSCODER_EDP,
POWER_DOMAIN_VGA,
+
+   POWER_DOMAIN_NUM,
 };
 
+#define POWER_DOMAIN_MASK (BIT(POWER_DOMAIN_NUM) - 1)
+
 #define POWER_DOMAIN_PIPE(pipe) ((pipe) + POWER_DOMAIN_PIPE_A)
 #define POWER_DOMAIN_PIPE_PANEL_FITTER(pipe) \
((pipe) + POWER_DOMAIN_PIPE_A_PANEL_FITTER)
@@ -109,6 +113,10 @@ enum intel_display_power_domain {
((tran) == TRANSCODER_EDP ? POWER_DOMAIN_TRANSCODER_EDP : \
 (tran) + POWER_DOMAIN_TRANSCODER_A)
 
+#define HSW_ALWAYS_ON_POWER_DOMAINS (  \
+   BIT(POWER_DOMAIN_PIPE_A) |  \
+   BIT(POWER_DOMAIN_TRANSCODER_EDP))
+
 enum hpd_pin {
HPD_NONE = 0,
HPD_PORT_A = HPD_NONE, /* PORT_A is internal */
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3d3658c..57d08a2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5367,6 +5367,23 @@ void intel_suspend_hw(struct drm_device *dev)
lpt_suspend_hw(dev);
 }
 
+static bool is_always_on_power_domain(struct drm_device *dev,
+ enum intel_display_power_domain domain)
+{
+   unsigned long always_on_domains;
+
+   BUG_ON(BIT(domain)  ~POWER_DOMAIN_MASK);
+
+   if (IS_HASWELL(dev)) {
+   always_on_domains = HSW_ALWAYS_ON_POWER_DOMAINS;
+   } else {
+   WARN_ON(1);
+   return true;
+   }
+
+   return BIT(domain)  always_on_domains;
+}
+
 /**
  * We should only use the power well if we explicitly asked the hardware to
  * enable it, so check if it's enabled and also check if we've requested it to
@@ -5380,24 +5397,11 @@ bool intel_display_power_enabled(struct drm_device *dev,
if (!HAS_POWER_WELL(dev))
return true;
 
-   switch (domain) {
-   case POWER_DOMAIN_PIPE_A:
-   case POWER_DOMAIN_TRANSCODER_EDP:
+   if (is_always_on_power_domain(dev, domain))
return true;
-   case POWER_DOMAIN_VGA:
-   case POWER_DOMAIN_PIPE_B:
-   case POWER_DOMAIN_PIPE_C:
-   case POWER_DOMAIN_PIPE_A_PANEL_FITTER:
-   case POWER_DOMAIN_PIPE_B_PANEL_FITTER:
-   case POWER_DOMAIN_PIPE_C_PANEL_FITTER:
-   case POWER_DOMAIN_TRANSCODER_A:
-   case POWER_DOMAIN_TRANSCODER_B:
-   case POWER_DOMAIN_TRANSCODER_C:
-   return I915_READ(HSW_PWR_WELL_DRIVER) ==
+
+   return I915_READ(HSW_PWR_WELL_DRIVER) ==
 (HSW_PWR_WELL_ENABLE_REQUEST | HSW_PWR_WELL_STATE_ENABLED);
-   default:
-   BUG();
-   }
 }
 
 static void __intel_set_power_well(struct drm_device *dev, bool enable)
@@ -5469,26 +5473,12 @@ void intel_display_power_get(struct drm_device *dev,
if (!HAS_POWER_WELL(dev))
return;
 
-   switch (domain) {
-   case POWER_DOMAIN_PIPE_A:
-   case POWER_DOMAIN_TRANSCODER_EDP:
+   if (is_always_on_power_domain(dev, domain))
return;
-   case POWER_DOMAIN_VGA:
-   case POWER_DOMAIN_PIPE_B:
-   case POWER_DOMAIN_PIPE_C:
-   case POWER_DOMAIN_PIPE_A_PANEL_FITTER:
-   case POWER_DOMAIN_PIPE_B_PANEL_FITTER:
-   case POWER_DOMAIN_PIPE_C_PANEL_FITTER:
-   case POWER_DOMAIN_TRANSCODER_A:
-   case POWER_DOMAIN_TRANSCODER_B:
-   case POWER_DOMAIN_TRANSCODER_C:
-   spin_lock_irq(power_well-lock);
-   __intel_power_well_get(power_well);
-   spin_unlock_irq(power_well-lock);
-   return;
-   default:
-   BUG();
-   }
+
+   spin_lock_irq(power_well-lock);
+   __intel_power_well_get(power_well);
+   spin_unlock_irq(power_well-lock);
 }
 
 void intel_display_power_put(struct drm_device *dev,
@@ -5500,26 +5490,12 @@ void intel_display_power_put(struct drm_device *dev,
if (!HAS_POWER_WELL(dev))
return;
 
-   switch (domain) {
-   case POWER_DOMAIN_PIPE_A:
-   case POWER_DOMAIN_TRANSCODER_EDP:
+   if (is_always_on_power_domain(dev, domain))
return;
-   case POWER_DOMAIN_VGA:
-   case POWER_DOMAIN_PIPE_B:
-   case POWER_DOMAIN_PIPE_C:
-   case POWER_DOMAIN_PIPE_A_PANEL_FITTER:
-   case POWER_DOMAIN_PIPE_B_PANEL_FITTER:
-   case POWER_DOMAIN_PIPE_C_PANEL_FITTER:
-   case 

[Intel-gfx] [PATCH 6/6] drm/i915: use power get/put instead of set for power on after init

2013-10-16 Thread Imre Deak
Currently we make sure that all power domains are enabled during driver
init and turn off unneded ones only after the first modeset. Similarly
during suspend we enable all power domains, which will remain on through
the following resume until the first modeset.

This logic is supported by intel_set_power_well() in the power domain
framework. It would be nice to simplify the API, so that we only have
get/put functions and make it more explicit on the higher level how this
power well on during init logic works. This will make it also easier
if in the future we want to shorten the time the power wells are on.

For this add a new device private flag tracking whether we have the
power wells on because of init/suspend and use only
intel_display_power_get()/put(). As nothing else uses
intel_set_power_well() we can remove it.

Signed-off-by: Imre Deak imre.d...@intel.com
---
 drivers/gpu/drm/i915/i915_dma.c  |  2 +-
 drivers/gpu/drm/i915/i915_drv.c  |  2 +-
 drivers/gpu/drm/i915/i915_drv.h  |  7 ++-
 drivers/gpu/drm/i915/intel_display.c | 17 +
 drivers/gpu/drm/i915/intel_drv.h |  1 +
 drivers/gpu/drm/i915/intel_pm.c  | 35 +--
 6 files changed, 27 insertions(+), 37 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index b8bc887..dd7f1f6 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1708,7 +1708,7 @@ int i915_driver_unload(struct drm_device *dev)
/* The i915.ko module is still not prepared to be loaded when
 * the power well is not enabled, so just enable it in case
 * we're going to unload/reload. */
-   intel_set_power_well(dev, true);
+   intel_display_set_init_power(dev, true);
i915_remove_power_well(dev);
}
 
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 59649c0..7299a96 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -469,7 +469,7 @@ static int i915_drm_freeze(struct drm_device *dev)
/* We do a lot of poking in a lot of registers, make sure they work
 * properly. */
hsw_disable_package_c8(dev_priv);
-   intel_set_power_well(dev, true);
+   intel_display_set_init_power(dev, true);
 
drm_kms_helper_poll_disable(dev);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e4354dd..0557c6b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -100,6 +100,7 @@ enum intel_display_power_domain {
POWER_DOMAIN_TRANSCODER_C,
POWER_DOMAIN_TRANSCODER_EDP,
POWER_DOMAIN_VGA,
+   POWER_DOMAIN_INIT,
 
POWER_DOMAIN_NUM,
 };
@@ -913,7 +914,6 @@ struct i915_power_well {
struct mutex lock;
/* power well enable/disable usage count */
int count;
-   int i915_request;
 };
 
 struct i915_dri1_state {
@@ -1369,6 +1369,11 @@ typedef struct drm_i915_private {
 * mchdev_lock in intel_pm.c */
struct intel_ilk_power_mgmt ips;
 
+   /*
+* Power wells needed for initialization at driver init and suspend
+* time are on. They are kept on until after the first modeset.
+*/
+   bool init_power_on;
/* Haswell power well */
struct i915_power_well power_well;
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e2a4f3b..e30db91 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6581,6 +6581,21 @@ static unsigned long get_pipe_power_domains(struct 
drm_device *dev,
return mask;
 }
 
+void intel_display_set_init_power(struct drm_device *dev, bool enable)
+{
+   struct drm_i915_private *dev_priv = dev-dev_private;
+
+   if (dev_priv-init_power_on == enable)
+   return;
+
+   if (enable)
+   intel_display_power_get(dev, POWER_DOMAIN_INIT);
+   else
+   intel_display_power_put(dev, POWER_DOMAIN_INIT);
+
+   dev_priv-init_power_on = enable;
+}
+
 static void modeset_update_power_wells(struct drm_device *dev)
 {
unsigned long pipe_domains[I915_MAX_PIPES] = { 0, };
@@ -6612,6 +6627,8 @@ static void modeset_update_power_wells(struct drm_device 
*dev)
 
crtc-enabled_power_domains = pipe_domains[crtc-pipe];
}
+
+   intel_display_set_init_power(dev, false);
 }
 
 static void haswell_modeset_global_resources(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 63a5bfd..e6306f5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -680,6 +680,7 @@ bool intel_crtc_active(struct drm_crtc *crtc);
 void i915_disable_vga_mem(struct drm_device *dev);
 void hsw_enable_ips(struct intel_crtc *crtc);
 void hsw_disable_ips(struct intel_crtc 

Re: [Intel-gfx] Patch for crashing intel server

2013-10-16 Thread Bas Wijnen
On Tue, Oct 15, 2013 at 09:25:41AM +0100, Chris Wilson wrote:
  This does indeed stop the server from crashing, but actually makes the
  problem worse: it used to play video for a few minutes and then crash
  when trying.  With my patch it would play video for a few minutes and
  then present black screens when trying.  With your patch, it presents
  black screens from the start.
 
 Start of video, or beginning of X?

Beginning of X.  After starting and logging in, I can play them for a
few minutes; afterwards it will crash.

  I must say I'm not entirely sure if the backtrace I sent you is a
  typical case; I managed to crash it sooner than usual, so perhaps it
  wasn't the bug that I triggered before.  It did stop the crashing
  however.
  
   However, that still leaveas the question as to how you ended up being
   unable to allocate bo...

I didn't check the backtrace myself, but when I wrote my shotgun-patch,
the problem was that pixmap_private was NULL; bo is in there, right?  So
at least in that case, it could never have allocated it, or at least it
couldn't store the pointer.

  While looking for it I did find and try intel-gpu-time, and noticed that
  it always reports the gpu 100% busy, even when running intel-gpu-time
  sleep 5 from a linux virtual terminal (so not even X is displayed).  Is
  that normal?
 
 Hmm, looks like it should report correctly on i915.

Due to unrelated problems (unbearable slowness) I switched from gnome to
xfce.  It does report 0% now.  It seems gnome keeps the gpu busy even if
it's not displaying anything...

Thanks,
Bas


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


Re: [Intel-gfx] [RFC] Runtime display PM for VLV/BYT

2013-10-16 Thread Imre Deak
On Wed, 2013-10-16 at 00:09 +0200, Daniel Vetter wrote:
 On Tue, Oct 15, 2013 at 8:15 PM, Imre Deak imre.d...@intel.com wrote:
  Related to this: I made intel_encoder_get_hw_state() only check if the
  power well is on and return false if it's not to indicate that the
  encoder is off. I also thought of doing the same as you and take a ref
  instead, not sure what's the right way. Maybe doing the readout only if
  the power is on, but also making sure we have a reference in this case?
  So with a new helper we'd have in intel_encoder_get_hw_state():
 
 I think the approach we've quickly discussed in today's call is
 probably simplest: We grab a temporary reference to all the display
 power wells around all the dpms/modeset functions and ignore any power
 well checks on top of that. The hw will (well, should) be in the power
 on default state, so nothing should magically turn on if we don't want
 that.

Ok, I'm fine with this too for now, later it can be improved if needed. 
I added a new POWER_DOMAIN_INIT for keeping all power wells on through
driver init-first modeset and suspend-first modeset, that could be
used for this purpose too.

--Imre


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH v3] drm: add support for additional stereo 3D modes

2013-10-16 Thread Thomas Wood
Parse the 3D_Structure_ALL and 3D_MASK fields of the HDMI Vendor
Specific Data Block to expose more stereo 3D modes.

v2: Use (1  0) for consistency. (Ville Syrjälä)
Skip adding any modes if 3D_MASK is indicated as being present but
the length only includes 3D_Structure_ALL. (Ville Syrjälä)
Check that the value of HDMI_3D_LEN is large enough to include
3D_Structure_ALL and 3D_MASK, if they are present. (Ville Syrjälä)
v3: Increment offset before the length checks. (Ville Syrjälä)

Signed-off-by: Thomas Wood thomas.w...@intel.com
---
 drivers/gpu/drm/drm_edid.c | 103 +
 1 file changed, 94 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9e81609..f1764ec 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2652,6 +2652,50 @@ static int add_hdmi_mode(struct drm_connector 
*connector, u8 vic)
return 1;
 }
 
+static int add_3d_struct_modes(struct drm_connector *connector, u16 structure,
+  const u8 *video_db, u8 video_len, u8 video_index)
+{
+   struct drm_device *dev = connector-dev;
+   struct drm_display_mode *newmode;
+   int modes = 0;
+   u8 cea_mode;
+
+   if (video_db == NULL || video_index  video_len)
+   return 0;
+
+   /* CEA modes are numbered 1..127 */
+   cea_mode = (video_db[video_index]  127) - 1;
+   if (cea_mode = ARRAY_SIZE(edid_cea_modes))
+   return 0;
+
+   if (structure  (1  0)) {
+   newmode = drm_mode_duplicate(dev, edid_cea_modes[cea_mode]);
+   if (newmode) {
+   newmode-flags |= DRM_MODE_FLAG_3D_FRAME_PACKING;
+   drm_mode_probed_add(connector, newmode);
+   modes++;
+   }
+   }
+   if (structure  (1  6)) {
+   newmode = drm_mode_duplicate(dev, edid_cea_modes[cea_mode]);
+   if (newmode) {
+   newmode-flags |= DRM_MODE_FLAG_3D_TOP_AND_BOTTOM;
+   drm_mode_probed_add(connector, newmode);
+   modes++;
+   }
+   }
+   if (structure  (1  8)) {
+   newmode = drm_mode_duplicate(dev, edid_cea_modes[cea_mode]);
+   if (newmode) {
+   newmode-flags = DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF;
+   drm_mode_probed_add(connector, newmode);
+   modes++;
+   }
+   }
+
+   return modes;
+}
+
 /*
  * do_hdmi_vsdb_modes - Parse the HDMI Vendor Specific data block
  * @connector: connector corresponding to the HDMI sink
@@ -2662,10 +2706,13 @@ static int add_hdmi_mode(struct drm_connector 
*connector, u8 vic)
  * also adds the stereo 3d modes when applicable.
  */
 static int
-do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len)
+do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len,
+  const u8 *video_db, u8 video_len)
 {
-   int modes = 0, offset = 0, i;
-   u8 vic_len;
+   int modes = 0, offset = 0, i, multi_present = 0;
+   u8 vic_len, hdmi_3d_len = 0;
+   u16 mask;
+   u16 structure_all;
 
if (len  8)
goto out;
@@ -2689,11 +2736,16 @@ do_hdmi_vsdb_modes(struct drm_connector *connector, 
const u8 *db, u8 len)
 
/* 3D_Present */
offset++;
-   if (db[8 + offset]  (1  7))
+   if (db[8 + offset]  (1  7)) {
modes += add_hdmi_mandatory_stereo_modes(connector);
 
+   /* 3D_Multi_present */
+   multi_present = (db[8 + offset]  0x60)  5;
+   }
+
offset++;
vic_len = db[8 + offset]  5;
+   hdmi_3d_len = db[8 + offset]  0x1f;
 
for (i = 0; i  vic_len  len = (9 + offset + i); i++) {
u8 vic;
@@ -2701,6 +2753,35 @@ do_hdmi_vsdb_modes(struct drm_connector *connector, 
const u8 *db, u8 len)
vic = db[9 + offset + i];
modes += add_hdmi_mode(connector, vic);
}
+   offset += 1 + vic_len;
+
+   if (!(multi_present == 1 || multi_present == 2))
+   goto out;
+
+   if ((multi_present == 1  len  (9 + offset)) ||
+   (multi_present == 2  len  (11 + offset)))
+   goto out;
+
+   if ((multi_present == 1  hdmi_3d_len  2) ||
+   (multi_present == 2  hdmi_3d_len  4))
+   goto out;
+
+   /* 3D_Structure_ALL */
+   structure_all = (db[8 + offset]  8) | db[9 + offset];
+
+   /* check if 3D_MASK is present */
+   if (multi_present == 2)
+   mask = (db[10 + offset]  8) | db[11 + offset];
+   else
+   mask = 0x;
+
+   for (i = 0; i  16; i++) {
+   if (mask  (1  i))
+   modes += add_3d_struct_modes(connector,
+structure_all,
+   

Re: [Intel-gfx] [PATCH v3] drm: add support for additional stereo 3D modes

2013-10-16 Thread Ville Syrjälä
On Wed, Oct 16, 2013 at 03:58:50PM +0100, Thomas Wood wrote:
 Parse the 3D_Structure_ALL and 3D_MASK fields of the HDMI Vendor
 Specific Data Block to expose more stereo 3D modes.
 
 v2: Use (1  0) for consistency. (Ville Syrjälä)
 Skip adding any modes if 3D_MASK is indicated as being present but
 the length only includes 3D_Structure_ALL. (Ville Syrjälä)
 Check that the value of HDMI_3D_LEN is large enough to include
 3D_Structure_ALL and 3D_MASK, if they are present. (Ville Syrjälä)
 v3: Increment offset before the length checks. (Ville Syrjälä)
 
 Signed-off-by: Thomas Wood thomas.w...@intel.com

Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com

 ---
  drivers/gpu/drm/drm_edid.c | 103 
 +
  1 file changed, 94 insertions(+), 9 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
 index 9e81609..f1764ec 100644
 --- a/drivers/gpu/drm/drm_edid.c
 +++ b/drivers/gpu/drm/drm_edid.c
 @@ -2652,6 +2652,50 @@ static int add_hdmi_mode(struct drm_connector 
 *connector, u8 vic)
   return 1;
  }
  
 +static int add_3d_struct_modes(struct drm_connector *connector, u16 
 structure,
 +const u8 *video_db, u8 video_len, u8 video_index)
 +{
 + struct drm_device *dev = connector-dev;
 + struct drm_display_mode *newmode;
 + int modes = 0;
 + u8 cea_mode;
 +
 + if (video_db == NULL || video_index  video_len)
 + return 0;
 +
 + /* CEA modes are numbered 1..127 */
 + cea_mode = (video_db[video_index]  127) - 1;
 + if (cea_mode = ARRAY_SIZE(edid_cea_modes))
 + return 0;
 +
 + if (structure  (1  0)) {
 + newmode = drm_mode_duplicate(dev, edid_cea_modes[cea_mode]);
 + if (newmode) {
 + newmode-flags |= DRM_MODE_FLAG_3D_FRAME_PACKING;
 + drm_mode_probed_add(connector, newmode);
 + modes++;
 + }
 + }
 + if (structure  (1  6)) {
 + newmode = drm_mode_duplicate(dev, edid_cea_modes[cea_mode]);
 + if (newmode) {
 + newmode-flags |= DRM_MODE_FLAG_3D_TOP_AND_BOTTOM;
 + drm_mode_probed_add(connector, newmode);
 + modes++;
 + }
 + }
 + if (structure  (1  8)) {
 + newmode = drm_mode_duplicate(dev, edid_cea_modes[cea_mode]);
 + if (newmode) {
 + newmode-flags = DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF;
 + drm_mode_probed_add(connector, newmode);
 + modes++;
 + }
 + }
 +
 + return modes;
 +}
 +
  /*
   * do_hdmi_vsdb_modes - Parse the HDMI Vendor Specific data block
   * @connector: connector corresponding to the HDMI sink
 @@ -2662,10 +2706,13 @@ static int add_hdmi_mode(struct drm_connector 
 *connector, u8 vic)
   * also adds the stereo 3d modes when applicable.
   */
  static int
 -do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len)
 +do_hdmi_vsdb_modes(struct drm_connector *connector, const u8 *db, u8 len,
 +const u8 *video_db, u8 video_len)
  {
 - int modes = 0, offset = 0, i;
 - u8 vic_len;
 + int modes = 0, offset = 0, i, multi_present = 0;
 + u8 vic_len, hdmi_3d_len = 0;
 + u16 mask;
 + u16 structure_all;
  
   if (len  8)
   goto out;
 @@ -2689,11 +2736,16 @@ do_hdmi_vsdb_modes(struct drm_connector *connector, 
 const u8 *db, u8 len)
  
   /* 3D_Present */
   offset++;
 - if (db[8 + offset]  (1  7))
 + if (db[8 + offset]  (1  7)) {
   modes += add_hdmi_mandatory_stereo_modes(connector);
  
 + /* 3D_Multi_present */
 + multi_present = (db[8 + offset]  0x60)  5;
 + }
 +
   offset++;
   vic_len = db[8 + offset]  5;
 + hdmi_3d_len = db[8 + offset]  0x1f;
  
   for (i = 0; i  vic_len  len = (9 + offset + i); i++) {
   u8 vic;
 @@ -2701,6 +2753,35 @@ do_hdmi_vsdb_modes(struct drm_connector *connector, 
 const u8 *db, u8 len)
   vic = db[9 + offset + i];
   modes += add_hdmi_mode(connector, vic);
   }
 + offset += 1 + vic_len;
 +
 + if (!(multi_present == 1 || multi_present == 2))
 + goto out;
 +
 + if ((multi_present == 1  len  (9 + offset)) ||
 + (multi_present == 2  len  (11 + offset)))
 + goto out;
 +
 + if ((multi_present == 1  hdmi_3d_len  2) ||
 + (multi_present == 2  hdmi_3d_len  4))
 + goto out;
 +
 + /* 3D_Structure_ALL */
 + structure_all = (db[8 + offset]  8) | db[9 + offset];
 +
 + /* check if 3D_MASK is present */
 + if (multi_present == 2)
 + mask = (db[10 + offset]  8) | db[11 + offset];
 + else
 + mask = 0x;
 +
 + for (i = 0; i  16; i++) {
 + if (mask  (1  i))
 + modes += 

Re: [Intel-gfx] [PATCH 4/5] drm/i915: take power well refs when needed

2013-10-16 Thread Jesse Barnes
On Wed, 16 Oct 2013 14:10:13 +0300
Imre Deak imre.d...@intel.com wrote:

 On Tue, 2013-10-15 at 13:40 -0700, Jesse Barnes wrote:
  On Tue, 15 Oct 2013 16:54:00 -0300
  Paulo Zanoni przan...@gmail.com wrote:
  [...]
  No that's taken into account here.  In __intel_set_mode we take a
  private ref on the appropriate power well so that we'll preserve state
  until we do the first crtc_enable.  From then on, the ref is tracked
  there and we drop the private one in __intel_set_mode
  
+   if (crtc-active)
+   intel_display_power_get(dev,
+   
POWER_DOMAIN_PIPE(crtc-pipe));
+
   
   What about the panel fitter power domains? Sometimes the panel fitter
   is the thing that makes you require a power well, even though you're
   on a pipe that doesn't need it.
   
   And on Haswell you also have to take into account
   TRANSCODER_EDP+PIPE_A versus TRANSCODER_A+PIPE_A, where the first
   doesn't need the power well but the second needs it.
  
  Yeah I'm still not sure how to handle this in generic code.  Maybe the
  power well mapping function Imre added will be enough, but it
  definitely gets tricky when we look at all the different platforms we
  have to (and will have to) handle.
 
 Isn't the power domain abstraction a neat idea exactly for the above
 case? Generic code just asks for the domain it needs and doesn't care
 how it maps to power wells on the given platform. So for transcoder_edp
 +pipe_a it'd end up asking for POWER_DOMAIN_PIPE_A and
 POWER_DOMAIN_TRANSCODER_EDP, both of which is a nop on HSW, and for the
 other case POWER_DOMAIN_PIPE_A and POWER_DOMAIN_TRANSCODER_A which would
 enable the power well. You also have the POWER_DOMAIN_PIPE,
 POWER_DOMAIN_TRANSCODER, POWER_DOMAIN_PIPE_PANEL_FITTER helpers already.

Yeah I think it can work.  I missed your function that takes a crtc
though as well, so we don't end up polluting the generic functions with
TRANSCODER references that don't exist on the Atom platforms for
example.  That's the main thing I'm worried about, since as we get more
and more wells I think it'll get easier to get it wrong in the generic
code, if we have to use all the required domains for all platforms
there.

-- 
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 for crashing intel server

2013-10-16 Thread Chris Wilson
On Wed, Oct 16, 2013 at 04:30:57PM +0200, Bas Wijnen wrote:
 On Tue, Oct 15, 2013 at 09:25:41AM +0100, Chris Wilson wrote:
   This does indeed stop the server from crashing, but actually makes the
   problem worse: it used to play video for a few minutes and then crash
   when trying.  With my patch it would play video for a few minutes and
   then present black screens when trying.  With your patch, it presents
   black screens from the start.
  
  Start of video, or beginning of X?
 
 Beginning of X.  After starting and logging in, I can play them for a
 few minutes; afterwards it will crash.

Still weird. Can you attach the Xorg.log from the black screen and/or crash.

   I must say I'm not entirely sure if the backtrace I sent you is a
   typical case; I managed to crash it sooner than usual, so perhaps it
   wasn't the bug that I triggered before.  It did stop the crashing
   however.
   
However, that still leaveas the question as to how you ended up being
unable to allocate bo...
 
 I didn't check the backtrace myself, but when I wrote my shotgun-patch,
 the problem was that pixmap_private was NULL; bo is in there, right?  So
 at least in that case, it could never have allocated it, or at least it
 couldn't store the pointer.

I doubt we failed to malloc the intel_pixmap, so the reason why the
intel_pixmap would be NULL is more likely due to failure to allocate the
GPU buffer object i.e. they are semantically interchangeable, an
attached intel_pixmap to a Pixmap implies we have a GPU bo. Similarly
checking for the intel_pixmap should be enough to assert that the GPU bo
exists.
-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 1/8] lib: Add a small helper to open debugfs files

2013-10-16 Thread Ben Widawsky
On Tue, Oct 15, 2013 at 07:44:27PM +0100, Damien Lespiau wrote:
 Signed-off-by: Damien Lespiau damien.lesp...@intel.com
 ---
  lib/Makefile.am   |  2 ++
  lib/igt_debugfs.c | 75 
 +++
  lib/igt_debugfs.h | 36 ++
  3 files changed, 113 insertions(+)
  create mode 100644 lib/igt_debugfs.c
  create mode 100644 lib/igt_debugfs.h
 
 diff --git a/lib/Makefile.am b/lib/Makefile.am
 index 387141b..5710802 100644
 --- a/lib/Makefile.am
 +++ b/lib/Makefile.am
 @@ -11,6 +11,8 @@ libintel_tools_la_SOURCES = \
   i830_reg.h  \
   i915_3d.h   \
   i915_reg.h  \
 + igt_debugfs.c   \
 + igt_debugfs.h   \
   instdone.c  \
   instdone.h  \
   intel_batchbuffer.c \
 diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
 new file mode 100644
 index 000..33c4fc1
 --- /dev/null
 +++ b/lib/igt_debugfs.c
 @@ -0,0 +1,75 @@
 +/*
 + * Copyright © 2013 Intel Corporation
 + *
 + * Permission is hereby granted, free of charge, to any person obtaining a
 + * copy of this software and associated documentation files (the Software),
 + * to deal in the Software without restriction, including without limitation
 + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
 + * and/or sell copies of the Software, and to permit persons to whom the
 + * Software is furnished to do so, subject to the following conditions:
 + *
 + * The above copyright notice and this permission notice (including the next
 + * paragraph) shall be included in all copies or substantial portions of the
 + * Software.
 + *
 + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
 + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
 DEALINGS
 + * IN THE SOFTWARE.
 + *
 + */
 +
 +#include sys/stat.h
 +#include sys/mount.h
 +#include errno.h
 +#include stdio.h
 +#include string.h
 +#include fcntl.h
 +
 +#include igt_debugfs.h
 +
 +int igt_debugfs_init(igt_debugfs_t *debugfs)
 +{
 + const char *path = /sys/kernel/debug;
 + struct stat st;
 + int n;
 +
 + if (stat(/debug/dri, st) == 0) {
 + path = /debug/dri;
 + goto find_minor;
 + }
 +
 + if (stat(/sys/kernel/debug/dri, st) == 0)
 + goto find_minor;
 +
 + if (stat(/sys/kernel/debug, st))
 + return errno;
 +
 + if (mount(debug, /sys/kernel/debug, debugfs, 0, 0))
 + return errno;
 +
 +find_minor:
 + strcpy(debugfs-root, path);
 + for (n = 0; n  16; n++) {
 + int len = sprintf(debugfs-dri_path, %s/dri/%d, path, n);
 + sprintf(debugfs-dri_path + len, /i915_error_state);
 + if (stat(debugfs-dri_path, st) == 0) {
 + debugfs-dri_path[len] = '\0';
 + return 0;
 + }
 + }
 +
 + debugfs-dri_path[0] = '\0';
 + return ENOENT;
 +}
 +
 +int igt_debugfs_open(igt_debugfs_t *debugfs, const char *filename)
 +{
 + char buf[1024];
 +
 + sprintf(buf, %s/%s, debugfs-dri_path, filename);
 + return open(buf, O_RDONLY);
 +}
 diff --git a/lib/igt_debugfs.h b/lib/igt_debugfs.h
 new file mode 100644
 index 000..aa9449a
 --- /dev/null
 +++ b/lib/igt_debugfs.h
 @@ -0,0 +1,36 @@
 +/*
 + * Copyright © 2013 Intel Corporation
 + *
 + * Permission is hereby granted, free of charge, to any person obtaining a
 + * copy of this software and associated documentation files (the Software),
 + * to deal in the Software without restriction, including without limitation
 + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
 + * and/or sell copies of the Software, and to permit persons to whom the
 + * Software is furnished to do so, subject to the following conditions:
 + *
 + * The above copyright notice and this permission notice (including the next
 + * paragraph) shall be included in all copies or substantial portions of the
 + * Software.
 + *
 + * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
 + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
 DEALINGS
 + * IN THE SOFTWARE.
 + *
 + */
 +
 +#ifndef __IGT_DEBUGFS_H__
 +#define __IGT_DEBUGFS_H__
 +
 +typedef struct {
 + char root[128];
 + char 

[Intel-gfx] [PATCH 2/2] drm/i915: Disable GGTT PTEs on GEN6+ suspend

2013-10-16 Thread Ben Widawsky
Once the machine gets to a certain point in the suspend process, we
expect the GPU to be idle. If it is not, we might corrupt memory.
Empirically (with an early version of this patch) we have seen this is
not the case. We cannot currently explain why the latent GPU writes
occur.

In the technical sense, this patch is a workaround in that we have an
issue we can't explain, and the patch indirectly solves the issue.
However, it's really better than a workaround because we understand why
it works, and it really should be a safe thing to do in all cases.

The noticeable effect other than the debug messages would be an increase
in the suspend time. I have not measure how expensive it actually is.

I think it would be good to spend further time to root cause why we're
seeing these latent writes, but it shouldn't preclude preventing the
fallout.

NOTE: It should be safe (and makes some sense IMO) to also keep the
VALID bit unset on resume when we clear_range(). I've opted not to do
this as properly clearing those bits at some later point would be extra
work.

Bugzilla: 
http://bugs.freedesktop.org/6549://bugs.freedesktop.org/show_bug.cgi?id=65496
Bugzilla: https://bugzilla.kernel.org/attachment.cgi?id=110401
Tested-by: Takashi Iwai ti...@suse.de
Tested-by: Paulo Zanoni paulo.r.zan...@intel.com
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
 drivers/gpu/drm/i915/i915_drv.c |  5 ++-
 drivers/gpu/drm/i915/i915_drv.h |  5 ++-
 drivers/gpu/drm/i915/i915_gem_gtt.c | 76 -
 drivers/gpu/drm/i915/i915_reg.h |  4 ++
 4 files changed, 78 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 59649c0..ea90c5f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -502,6 +502,8 @@ static int i915_drm_freeze(struct drm_device *dev)
intel_modeset_suspend_hw(dev);
}
 
+   i915_gem_suspend_gtt_mappings(dev);
+
i915_save_state(dev);
 
intel_opregion_fini(dev);
@@ -587,7 +589,8 @@ static int __i915_drm_thaw(struct drm_device *dev, bool 
restore_gtt_mappings)
mutex_lock(dev-struct_mutex);
i915_gem_restore_gtt_mappings(dev);
mutex_unlock(dev-struct_mutex);
-   }
+   } else if (drm_core_check_feature(dev, DRIVER_MODESET))
+   i915_check_and_clear_faults(dev);
 
intel_init_power_well(dev);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0cbeb0e..7ca99350 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -521,7 +521,8 @@ struct i915_address_space {
 bool valid); /* Create a valid PTE */
void (*clear_range)(struct i915_address_space *vm,
unsigned int first_entry,
-   unsigned int num_entries);
+   unsigned int num_entries,
+   bool use_scratch);
void (*insert_entries)(struct i915_address_space *vm,
   struct sg_table *st,
   unsigned int first_entry,
@@ -2143,6 +2144,8 @@ void i915_ppgtt_bind_object(struct i915_hw_ppgtt *ppgtt,
 void i915_ppgtt_unbind_object(struct i915_hw_ppgtt *ppgtt,
  struct drm_i915_gem_object *obj);
 
+void i915_check_and_clear_faults(struct drm_device *dev);
+void i915_gem_suspend_gtt_mappings(struct drm_device *dev);
 void i915_gem_restore_gtt_mappings(struct drm_device *dev);
 int __must_check i915_gem_gtt_prepare_object(struct drm_i915_gem_object *obj);
 void i915_gem_gtt_bind_object(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 81dce29..c4c42e7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -241,7 +241,8 @@ static int gen6_ppgtt_enable(struct drm_device *dev)
 /* PPGTT support for Sandybdrige/Gen6 and later */
 static void gen6_ppgtt_clear_range(struct i915_address_space *vm,
   unsigned first_entry,
-  unsigned num_entries)
+  unsigned num_entries,
+  bool use_scratch)
 {
struct i915_hw_ppgtt *ppgtt =
container_of(vm, struct i915_hw_ppgtt, base);
@@ -372,7 +373,7 @@ static int gen6_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
}
 
ppgtt-base.clear_range(ppgtt-base, 0,
-   ppgtt-num_pd_entries * I915_PPGTT_PT_ENTRIES);
+   ppgtt-num_pd_entries * I915_PPGTT_PT_ENTRIES, 
true);
 
ppgtt-pd_offset = first_pd_entry_in_global_pt * sizeof(gen6_gtt_pte_t);
 
@@ -449,7 +450,8 @@ void i915_ppgtt_unbind_object(struct i915_hw_ppgtt *ppgtt,
 {
ppgtt-base.clear_range(ppgtt-base,
   

[Intel-gfx] [PATCH 1/2] drm/i915: Make PTE valid encoding optional

2013-10-16 Thread Ben Widawsky
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
 drivers/gpu/drm/i915/i915_drv.h |  3 ++-
 drivers/gpu/drm/i915/i915_gem_gtt.c | 35 ---
 2 files changed, 22 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6106d3d..0cbeb0e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -517,7 +517,8 @@ struct i915_address_space {
 
/* FIXME: Need a more generic return type */
gen6_gtt_pte_t (*pte_encode)(dma_addr_t addr,
-enum i915_cache_level level);
+enum i915_cache_level level,
+bool valid); /* Create a valid PTE */
void (*clear_range)(struct i915_address_space *vm,
unsigned int first_entry,
unsigned int num_entries);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index e999496..81dce29 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -58,9 +58,10 @@
 #define HSW_WT_ELLC_LLC_AGE0   HSW_CACHEABILITY_CONTROL(0x6)
 
 static gen6_gtt_pte_t snb_pte_encode(dma_addr_t addr,
-enum i915_cache_level level)
+enum i915_cache_level level,
+bool valid)
 {
-   gen6_gtt_pte_t pte = GEN6_PTE_VALID;
+   gen6_gtt_pte_t pte = valid ? GEN6_PTE_VALID : 0;
pte |= GEN6_PTE_ADDR_ENCODE(addr);
 
switch (level) {
@@ -79,9 +80,10 @@ static gen6_gtt_pte_t snb_pte_encode(dma_addr_t addr,
 }
 
 static gen6_gtt_pte_t ivb_pte_encode(dma_addr_t addr,
-enum i915_cache_level level)
+enum i915_cache_level level,
+bool valid)
 {
-   gen6_gtt_pte_t pte = GEN6_PTE_VALID;
+   gen6_gtt_pte_t pte = valid ? GEN6_PTE_VALID : 0;
pte |= GEN6_PTE_ADDR_ENCODE(addr);
 
switch (level) {
@@ -105,9 +107,10 @@ static gen6_gtt_pte_t ivb_pte_encode(dma_addr_t addr,
 #define BYT_PTE_SNOOPED_BY_CPU_CACHES  (1  2)
 
 static gen6_gtt_pte_t byt_pte_encode(dma_addr_t addr,
-enum i915_cache_level level)
+enum i915_cache_level level,
+bool valid)
 {
-   gen6_gtt_pte_t pte = GEN6_PTE_VALID;
+   gen6_gtt_pte_t pte = valid ? GEN6_PTE_VALID : 0;
pte |= GEN6_PTE_ADDR_ENCODE(addr);
 
/* Mark the page as writeable.  Other platforms don't have a
@@ -122,9 +125,10 @@ static gen6_gtt_pte_t byt_pte_encode(dma_addr_t addr,
 }
 
 static gen6_gtt_pte_t hsw_pte_encode(dma_addr_t addr,
-enum i915_cache_level level)
+enum i915_cache_level level,
+bool valid)
 {
-   gen6_gtt_pte_t pte = GEN6_PTE_VALID;
+   gen6_gtt_pte_t pte = valid ? GEN6_PTE_VALID : 0;
pte |= HSW_PTE_ADDR_ENCODE(addr);
 
if (level != I915_CACHE_NONE)
@@ -134,9 +138,10 @@ static gen6_gtt_pte_t hsw_pte_encode(dma_addr_t addr,
 }
 
 static gen6_gtt_pte_t iris_pte_encode(dma_addr_t addr,
- enum i915_cache_level level)
+ enum i915_cache_level level,
+ bool valid)
 {
-   gen6_gtt_pte_t pte = GEN6_PTE_VALID;
+   gen6_gtt_pte_t pte = valid ? GEN6_PTE_VALID : 0;
pte |= HSW_PTE_ADDR_ENCODE(addr);
 
switch (level) {
@@ -245,7 +250,7 @@ static void gen6_ppgtt_clear_range(struct 
i915_address_space *vm,
unsigned first_pte = first_entry % I915_PPGTT_PT_ENTRIES;
unsigned last_pte, i;
 
-   scratch_pte = vm-pte_encode(vm-scratch.addr, I915_CACHE_LLC);
+   scratch_pte = vm-pte_encode(vm-scratch.addr, I915_CACHE_LLC, true);
 
while (num_entries) {
last_pte = first_pte + num_entries;
@@ -282,7 +287,7 @@ static void gen6_ppgtt_insert_entries(struct 
i915_address_space *vm,
dma_addr_t page_addr;
 
page_addr = sg_page_iter_dma_address(sg_iter);
-   pt_vaddr[act_pte] = vm-pte_encode(page_addr, cache_level);
+   pt_vaddr[act_pte] = vm-pte_encode(page_addr, cache_level, 
true);
if (++act_pte == I915_PPGTT_PT_ENTRIES) {
kunmap_atomic(pt_vaddr);
act_pt++;
@@ -536,7 +541,7 @@ static void gen6_ggtt_insert_entries(struct 
i915_address_space *vm,
 
for_each_sg_page(st-sgl, sg_iter, st-nents, 0) {
addr = sg_page_iter_dma_address(sg_iter);
-   iowrite32(vm-pte_encode(addr, level), gtt_entries[i]);
+   iowrite32(vm-pte_encode(addr, level, true), gtt_entries[i]);
i++;

Re: [Intel-gfx] [PATCH 3/6] drm/i915: change power_well-lock to be mutex

2013-10-16 Thread Imre Deak
On Wed, 2013-10-16 at 13:19 -0300, Paulo Zanoni wrote:
 2013/10/16 Imre Deak imre.d...@intel.com:
  There is no hard need for this to be a spin lock, as we don't take these
  locks in irq context from anywhere. An upcoming patch will add calls to
  punit read/write functions from within regions protected by this lock
  and those functions need a mutex in turn. As a solution for that convert
  the spin lock to be a mutex.
 
 Not even from snd_hda_intel? Did we check this?

Yea, at least I tried to check this at all call sites and haven't found
any place where they request the power well in atomic context. In any
case I think it's a design problem if they do ..

--Imre

 
 
  Signed-off-by: Imre Deak imre.d...@intel.com
  ---
   drivers/gpu/drm/i915/i915_drv.h |  2 +-
   drivers/gpu/drm/i915/intel_pm.c | 26 +-
   2 files changed, 14 insertions(+), 14 deletions(-)
 
  diff --git a/drivers/gpu/drm/i915/i915_drv.h 
  b/drivers/gpu/drm/i915/i915_drv.h
  index ca05f3a..e4354dd 100644
  --- a/drivers/gpu/drm/i915/i915_drv.h
  +++ b/drivers/gpu/drm/i915/i915_drv.h
  @@ -910,7 +910,7 @@ struct intel_ilk_power_mgmt {
   /* Power well structure for haswell */
   struct i915_power_well {
  struct drm_device *device;
  -   spinlock_t lock;
  +   struct mutex lock;
  /* power well enable/disable usage count */
  int count;
  int i915_request;
  diff --git a/drivers/gpu/drm/i915/intel_pm.c 
  b/drivers/gpu/drm/i915/intel_pm.c
  index 57d08a2..f7363a8 100644
  --- a/drivers/gpu/drm/i915/intel_pm.c
  +++ b/drivers/gpu/drm/i915/intel_pm.c
  @@ -5476,9 +5476,9 @@ void intel_display_power_get(struct drm_device *dev,
  if (is_always_on_power_domain(dev, domain))
  return;
 
  -   spin_lock_irq(power_well-lock);
  +   mutex_lock(power_well-lock);
  __intel_power_well_get(power_well);
  -   spin_unlock_irq(power_well-lock);
  +   mutex_unlock(power_well-lock);
   }
 
   void intel_display_power_put(struct drm_device *dev,
  @@ -5493,9 +5493,9 @@ void intel_display_power_put(struct drm_device *dev,
  if (is_always_on_power_domain(dev, domain))
  return;
 
  -   spin_lock_irq(power_well-lock);
  +   mutex_lock(power_well-lock);
  __intel_power_well_put(power_well);
  -   spin_unlock_irq(power_well-lock);
  +   mutex_unlock(power_well-lock);
   }
 
   static struct i915_power_well *hsw_pwr;
  @@ -5506,9 +5506,9 @@ void i915_request_power_well(void)
  if (WARN_ON(!hsw_pwr))
  return;
 
  -   spin_lock_irq(hsw_pwr-lock);
  +   mutex_lock(hsw_pwr-lock);
  __intel_power_well_get(hsw_pwr);
  -   spin_unlock_irq(hsw_pwr-lock);
  +   mutex_unlock(hsw_pwr-lock);
   }
   EXPORT_SYMBOL_GPL(i915_request_power_well);
 
  @@ -5518,9 +5518,9 @@ void i915_release_power_well(void)
  if (WARN_ON(!hsw_pwr))
  return;
 
  -   spin_lock_irq(hsw_pwr-lock);
  +   mutex_lock(hsw_pwr-lock);
  __intel_power_well_put(hsw_pwr);
  -   spin_unlock_irq(hsw_pwr-lock);
  +   mutex_unlock(hsw_pwr-lock);
   }
   EXPORT_SYMBOL_GPL(i915_release_power_well);
 
  @@ -5531,7 +5531,7 @@ int i915_init_power_well(struct drm_device *dev)
  hsw_pwr = dev_priv-power_well;
 
  hsw_pwr-device = dev;
  -   spin_lock_init(hsw_pwr-lock);
  +   mutex_init(hsw_pwr-lock);
  hsw_pwr-count = 0;
 
  return 0;
  @@ -5553,7 +5553,7 @@ void intel_set_power_well(struct drm_device *dev, 
  bool enable)
  if (!i915_disable_power_well  !enable)
  return;
 
  -   spin_lock_irq(power_well-lock);
  +   mutex_lock(power_well-lock);
 
  /*
   * This function will only ever contribute one
  @@ -5572,7 +5572,7 @@ void intel_set_power_well(struct drm_device *dev, 
  bool enable)
  __intel_power_well_put(power_well);
 
out:
  -   spin_unlock_irq(power_well-lock);
  +   mutex_unlock(power_well-lock);
   }
 
   static void intel_resume_power_well(struct drm_device *dev)
  @@ -5583,9 +5583,9 @@ static void intel_resume_power_well(struct drm_device 
  *dev)
  if (!HAS_POWER_WELL(dev))
  return;
 
  -   spin_lock_irq(power_well-lock);
  +   mutex_lock(power_well-lock);
  __intel_set_power_well(dev, power_well-count  0);
  -   spin_unlock_irq(power_well-lock);
  +   mutex_unlock(power_well-lock);
   }
 
   /*
  --
  1.8.4
 
  ___
  Intel-gfx mailing list
  Intel-gfx@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/intel-gfx
 
 
 



signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Disable all GEM timers and work on unload

2013-10-16 Thread Chris Wilson
On Wed, Oct 16, 2013 at 01:50:29PM +0200, Daniel Vetter wrote:
 On Wed, Oct 16, 2013 at 11:50:01AM +0100, Chris Wilson wrote:
  We have two once very similar functions, i915_gpu_idle() and
  i915_gem_idle(). The former is used as the lower level operation to
  flush work on the GPU, whereas the latter is the high level interface to
  flush the GEM bookkeeping in addition to flushing the GPU. As such
  i915_gem_idle() also clears out the request and activity lists and
  cancels the delayed work. This is what we need for unloading the driver,
  unfortunately we called i915_gpu_idle() instead.
  
  In the process, make sure that when cancelling the delayed work and
  timer, which is synchronous, that we do not hold any locks to prevent a
  deadlock if the work item is already waiting upon the mutex. This
  requires us to push the mutex down from the caller to i915_gem_idle().
  
  v2: s/i915_gem_idle/i915_gem_suspend/
  
  Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70334
  Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
  Tested-by: xunx.f...@intel.com
 
 Queued for -next, thanks for the patch.

Oops, spotted a bug in my v2.
ums.mm_suspend should only be set for !kms. Sorry that slipped my mind
when doing the s/_idle/_suspend.
-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 2/2] [v2] drm/i915: Disable GGTT PTEs on GEN6+ suspend

2013-10-16 Thread Chris Wilson
On Wed, Oct 16, 2013 at 09:21:30AM -0700, Ben Widawsky wrote:
 Once the machine gets to a certain point in the suspend process, we
 expect the GPU to be idle. If it is not, we might corrupt memory.
 Empirically (with an early version of this patch) we have seen this is
 not the case. We cannot currently explain why the latent GPU writes
 occur.
 
 In the technical sense, this patch is a workaround in that we have an
 issue we can't explain, and the patch indirectly solves the issue.
 However, it's really better than a workaround because we understand why
 it works, and it really should be a safe thing to do in all cases.
 
 The noticeable effect other than the debug messages would be an increase
 in the suspend time. I have not measure how expensive it actually is.
 
 I think it would be good to spend further time to root cause why we're
 seeing these latent writes, but it shouldn't preclude preventing the
 fallout.
 
 NOTE: It should be safe (and makes some sense IMO) to also keep the
 VALID bit unset on resume when we clear_range(). I've opted not to do
 this as properly clearing those bits at some later point would be extra
 work.
 
 v2: Fix bugzilla link

And the other one?

 Bugzilla: 
 http://bugs.freedesktop.org/6549://bugs.freedesktop.org/show_bug.cgi?id=65496
 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59321
 Tested-by: Takashi Iwai ti...@suse.de
 Tested-by: Paulo Zanoni paulo.r.zan...@intel.com
 Signed-off-by: Ben Widawsky b...@bwidawsk.net

So clearing the valid bit should result in the GPU reporting errors for
delayed accesses, but none were reported?
-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 2/2] [v2] drm/i915: Disable GGTT PTEs on GEN6+ suspend

2013-10-16 Thread Ben Widawsky
On Wed, Oct 16, 2013 at 05:58:31PM +0100, Chris Wilson wrote:
 On Wed, Oct 16, 2013 at 09:21:30AM -0700, Ben Widawsky wrote:
  Once the machine gets to a certain point in the suspend process, we
  expect the GPU to be idle. If it is not, we might corrupt memory.
  Empirically (with an early version of this patch) we have seen this is
  not the case. We cannot currently explain why the latent GPU writes
  occur.
  
  In the technical sense, this patch is a workaround in that we have an
  issue we can't explain, and the patch indirectly solves the issue.
  However, it's really better than a workaround because we understand why
  it works, and it really should be a safe thing to do in all cases.
  
  The noticeable effect other than the debug messages would be an increase
  in the suspend time. I have not measure how expensive it actually is.
  
  I think it would be good to spend further time to root cause why we're
  seeing these latent writes, but it shouldn't preclude preventing the
  fallout.
  
  NOTE: It should be safe (and makes some sense IMO) to also keep the
  VALID bit unset on resume when we clear_range(). I've opted not to do
  this as properly clearing those bits at some later point would be extra
  work.
  
  v2: Fix bugzilla link
 
 And the other one?
 

I'm really amazing. If we move ahead with this patch, Daniel, can you just erase
the extra bugs.freedesktop.org/6549://

  Bugzilla: 
  http://bugs.freedesktop.org/6549://bugs.freedesktop.org/show_bug.cgi?id=65496

Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=65496

  Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59321
  Tested-by: Takashi Iwai ti...@suse.de
  Tested-by: Paulo Zanoni paulo.r.zan...@intel.com
  Signed-off-by: Ben Widawsky b...@bwidawsk.net
 
 So clearing the valid bit should result in the GPU reporting errors for
 delayed accesses, but none were reported?
 -Chris
 

So I can't actually reproduce the problem for some reason. Paulo will
need to answer. One theory is the fault information is lost on suspend.

The original patch put faults both in suspend, and resume. After this, I
asked Paulo to wedge the GPU, and there I saw faults.

-- 
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 2/2] [v2] drm/i915: Disable GGTT PTEs on GEN6+ suspend

2013-10-16 Thread Chris Wilson
On Wed, Oct 16, 2013 at 10:06:27AM -0700, Ben Widawsky wrote:
 On Wed, Oct 16, 2013 at 05:58:31PM +0100, Chris Wilson wrote:
  So clearing the valid bit should result in the GPU reporting errors for
  delayed accesses, but none were reported?
 
 So I can't actually reproduce the problem for some reason. Paulo will
 need to answer. One theory is the fault information is lost on suspend.
 
 The original patch put faults both in suspend, and resume. After this, I
 asked Paulo to wedge the GPU, and there I saw faults.

If we can capture the error, and it should be very possible to do so, we
should be able to pinpoint the cause quite quickly. If it is just deferred
writes, it should also be a problem across module unload - which should
be easier for getting debug information out.
-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: Disable all GEM timers and work on unload

2013-10-16 Thread Daniel Vetter
On Wed, Oct 16, 2013 at 05:47:26PM +0100, Chris Wilson wrote:
 On Wed, Oct 16, 2013 at 01:50:29PM +0200, Daniel Vetter wrote:
  On Wed, Oct 16, 2013 at 11:50:01AM +0100, Chris Wilson wrote:
   We have two once very similar functions, i915_gpu_idle() and
   i915_gem_idle(). The former is used as the lower level operation to
   flush work on the GPU, whereas the latter is the high level interface to
   flush the GEM bookkeeping in addition to flushing the GPU. As such
   i915_gem_idle() also clears out the request and activity lists and
   cancels the delayed work. This is what we need for unloading the driver,
   unfortunately we called i915_gpu_idle() instead.
   
   In the process, make sure that when cancelling the delayed work and
   timer, which is synchronous, that we do not hold any locks to prevent a
   deadlock if the work item is already waiting upon the mutex. This
   requires us to push the mutex down from the caller to i915_gem_idle().
   
   v2: s/i915_gem_idle/i915_gem_suspend/
   
   Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70334
   Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
   Tested-by: xunx.f...@intel.com
  
  Queued for -next, thanks for the patch.
 
 Oops, spotted a bug in my v2.
 ums.mm_suspend should only be set for !kms. Sorry that slipped my mind
 when doing the s/_idle/_suspend.

Actually I've noticed since it was missing from the changelog, but figured
you've decided against that. I'll rectify it.
-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: preserve dispaly init order on ByT

2013-10-16 Thread Daniel Vetter
On Wed, Oct 16, 2013 at 06:10:41PM +0300, Artem Bityutskiy wrote:
 From: Artem Bityutskiy artem.bityuts...@linux.intel.com
 
 This patch changes HDMI port registration order for the BayTrail platform.
 
 The story is that in kernel version 3.11 i915 supported only one HDMI port -
 the HDMIB port. So this port ended up being HDMI-1 in user-space.
 
 But commit '6f6005a drm/i915: expose HDMI connectors on port C on BYT'
 introduced HDMIC port support. And added HDMIC  registration prior to HDMIB,
 so HDMIB became HDMI-2 and HDMIC became HDMI-1.
 
 Well, this is fine as far as the kernel is concerned. i915 does not give any
 guarantees to the numbering, and has never given them.
 
 However, this breaks wayland setup in Tizen IVI. We have only one single HDMI
 port on our hardware, and it is connected to HDMIB. Our configuration relies 
 on
 the fact that it is HDMI-1.
 
 Well, certainly this is user-space problem which was exposed with Jesse's
 patch. However, there is a reason why we have to do this assumption - we use
 touchscreen monitors and we have to associate event devices with the monitors,
 and this is not easy to do dynamically, so we just have a static setup.
 
 Anyway, while the user-space setup will have to be fixed regardless, let's
 chane the HDMI port registration order so that HDMIB stays HDMI-1, just like 
 it
 was in 3.11. Simply because there is no strong reason for changing the order 
 in
 the kernel, and it'll help setups like ours in sense that we'll have more time
 for fixing the issue properly.
 
 Also amend the commentary which looks a bit out-of-date.
 
 Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com

This makes imo sense irrespective of any userspace issues. Queued for
-next, 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 v3] drm: add support for additional stereo 3D modes

2013-10-16 Thread Daniel Vetter
On Wed, Oct 16, 2013 at 06:07:30PM +0300, Ville Syrjälä wrote:
 On Wed, Oct 16, 2013 at 03:58:50PM +0100, Thomas Wood wrote:
  Parse the 3D_Structure_ALL and 3D_MASK fields of the HDMI Vendor
  Specific Data Block to expose more stereo 3D modes.
  
  v2: Use (1  0) for consistency. (Ville Syrjälä)
  Skip adding any modes if 3D_MASK is indicated as being present but
  the length only includes 3D_Structure_ALL. (Ville Syrjälä)
  Check that the value of HDMI_3D_LEN is large enough to include
  3D_Structure_ALL and 3D_MASK, if they are present. (Ville Syrjälä)
  v3: Increment offset before the length checks. (Ville Syrjälä)
  
  Signed-off-by: Thomas Wood thomas.w...@intel.com
 
 Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com

Queued for -next, 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: vlv: fix VGA hotplug after modeset

2013-10-16 Thread Daniel Vetter
On Wed, Oct 16, 2013 at 08:39:24PM +0300, Imre Deak wrote:
 Since
 
 commit 912d812e84cea8689a2bf3dd13b11dfe191f0f1e
 Author: Daniel Vetter daniel.vet...@ffwll.ch
 Date:   Thu Oct 11 20:08:23 2012 +0200
 
 drm/i915/crt: don't set HOTPLUG bits on !PCH
 
 on VLV we don't detect any VGA unplug event after a modeset, since there we
 reset the ADPA hotplug bits. Fix it by preserving the hotplug bits on VLV as
 well.
 
 Signed-off-by: Imre Deak imre.d...@intel.com
Queued for -next (with a bikeshed to make it consistent with Chris'
equivalent fix in intel_crt_reset), thanks for the patch.
-Daniel
 ---
  drivers/gpu/drm/i915/intel_crt.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/i915/intel_crt.c 
 b/drivers/gpu/drm/i915/intel_crt.c
 index becb311..bd37685 100644
 --- a/drivers/gpu/drm/i915/intel_crt.c
 +++ b/drivers/gpu/drm/i915/intel_crt.c
 @@ -274,7 +274,7 @@ static void intel_crt_mode_set(struct intel_encoder 
 *encoder)
   struct drm_display_mode *adjusted_mode = crtc-config.adjusted_mode;
   u32 adpa;
  
 - if (HAS_PCH_SPLIT(dev))
 + if (HAS_PCH_SPLIT(dev) || IS_VALLEYVIEW(dev))
   adpa = ADPA_HOTPLUG_BITS;
   else
   adpa = 0;
 -- 
 1.8.4
 
 ___
 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 0/4] framebuffer_init checks

2013-10-16 Thread Daniel Vetter
On Thu, Oct 10, 2013 at 02:42:40PM +0300, Ville Syrjälä wrote:
 On Wed, Oct 09, 2013 at 09:23:50PM +0200, Daniel Vetter wrote:
  Hi all,
  
  That little patch turned into a bit more, and on top of it there's now also 
  a
  new testcase in igt: kms_addfb. It checks for most of the evil stuff you can
  feed to addfb.
 
 For the series:
 Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com

All merged, thanks for your review. For patch 2 I've added a note about
how exactly it'll affect shipped userspace and smashed Chris' grumpy irc
r-b on top.
-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] [v3.10][v3.11][v3.12][Regression][PATCH 1/1] Revert Revert drm/i915: revert eDP bpp clamping code changes

2013-10-16 Thread Joseph Salisbury
BugLink: http://bugs.launchpad.net/bugs/1195483

This reverts commit 657445fe8660100ad174600ebfa61536392b7624.

Signed-off-by: Joseph Salisbury joseph.salisb...@canonical.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Paulo Zanoni przan...@gmail.com
Cc: David Airlie airl...@linux.ie
Cc: sta...@vger.kernel.org


---
 drivers/gpu/drm/i915/intel_dp.c |   18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 26e162b..ce933ad 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -709,10 +709,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
 
/* Walk through all bpp values. Luckily they're all nicely spaced with 2
 * bpc in between. */
-   bpp = pipe_config-pipe_bpp;
-   if (is_edp(intel_dp)  dev_priv-vbt.edp_bpp)
-   bpp = min_t(int, bpp, dev_priv-vbt.edp_bpp);
-
+   bpp = min_t(int, 8*3, pipe_config-pipe_bpp);
for (; bpp = 6*3; bpp -= 2*3) {
mode_rate = intel_dp_link_required(adjusted_mode-clock, bpp);
 
@@ -763,6 +760,19 @@ found:
   pipe_config-dp_m_n);
 
intel_dp_set_clock(encoder, pipe_config, intel_dp-link_bw);
+   /*
+* XXX: We have a strange regression where using the vbt edp bpp value
+* for the link bw computation results in black screens, the panel only
+* works when we do the computation at the usual 24bpp (but still
+* requires us to use 18bpp). Until that's fully debugged, stay
+* bug-for-bug compatible with the old code.
+*/
+   if (is_edp(intel_dp)  dev_priv-vbt.edp_bpp) {
+   DRM_DEBUG_KMS(clamping display bpc (was %d) to eDP (%d)\n,
+ bpp, dev_priv-vbt.edp_bpp);
+   bpp = min_t(int, bpp, dev_priv-vbt.edp_bpp);
+   }
+   pipe_config-pipe_bpp = bpp;
 
return true;
 }
-- 
1.7.9.5

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


[Intel-gfx] [v3.10][v3.11][v3.12][Regression][PATCH 0/1] Revert Revert drm/i915: revert eDP bpp clamping code changes

2013-10-16 Thread Joseph Salisbury
Hi Daniel,

A bug was opened against the Ubuntu kernel[0].  It was found that reverting the 
following commit resolved this bug:

commit 657445fe8660100ad174600ebfa61536392b7624
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date:   Sat May 4 10:09:18 2013 +0200

Revert drm/i915: revert eDP bpp clamping code changes


The regression was introduced as of v3.10-rc2 and affects a large number of end 
users.

I see this code has gone back and forth a few times, so I was wondering if we 
could get some feedback.  The revert of commit 657445f was tested aginst 3.11 
stable and could not be done cleanly, so I had to make some modifications.  The 
modifications I made for 3.11 are in [PATCH 1/1].  The revert can't be done 
cleanly against 3.12 neither.  The modifications I made for 3.11 will not work 
cleanly on 3.12 due to recent changes in 3.12, such as commit 7984211.  
However, I can create a patch specific for 3.12 if you think this is the best 
way to go. 


Thanks,

Joe 

http://pad.lv/1195483


Joseph Salisbury (1):
  Revert Revert drm/i915: revert eDP bpp clamping code changes

 drivers/gpu/drm/i915/intel_dp.c |   18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

-- 
1.7.9.5

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


Re: [Intel-gfx] [PATCH] drm/i915: preserve dispaly init order on ByT

2013-10-16 Thread Chris Wilson
On Wed, Oct 16, 2013 at 07:46:27PM +0200, Daniel Vetter wrote:
 On Wed, Oct 16, 2013 at 06:10:41PM +0300, Artem Bityutskiy wrote:
  Well, certainly this is user-space problem which was exposed with Jesse's
  patch. However, there is a reason why we have to do this assumption - we use
  touchscreen monitors and we have to associate event devices with the 
  monitors,
  and this is not easy to do dynamically, so we just have a static setup.

I'm sure I heard a rumour that there was an extension block in EDID to
assiocate touch devices with monitors. Does anyone know any firm details
about that?
-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] [PATCH 01/16] drm/i915: extract display_pipe_crc_update

2013-10-16 Thread Daniel Vetter
The ringbuffer update logic should always be the same, but different
platforms have different amounts of CRC registers. Hence extract it.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_irq.c | 30 +++---
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8c9148c..df031bb 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1190,7 +1190,10 @@ static void dp_aux_irq_handler(struct drm_device *dev)
 }
 
 #if defined(CONFIG_DEBUG_FS)
-static void ivb_pipe_crc_update(struct drm_device *dev, enum pipe pipe)
+static void display_pipe_crc_update(struct drm_device *dev, enum pipe pipe,
+   uint32_t crc0, uint32_t crc1,
+   uint32_t crc2, uint32_t crc3,
+   uint32_t crc4, uint32_t frame)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[pipe];
@@ -1212,18 +1215,31 @@ static void ivb_pipe_crc_update(struct drm_device *dev, 
enum pipe pipe)
 
entry = pipe_crc-entries[head];
 
-   entry-frame = I915_READ(PIPEFRAME(pipe));
-   entry-crc[0] = I915_READ(PIPE_CRC_RES_1_IVB(pipe));
-   entry-crc[1] = I915_READ(PIPE_CRC_RES_2_IVB(pipe));
-   entry-crc[2] = I915_READ(PIPE_CRC_RES_3_IVB(pipe));
-   entry-crc[3] = I915_READ(PIPE_CRC_RES_4_IVB(pipe));
-   entry-crc[4] = I915_READ(PIPE_CRC_RES_5_IVB(pipe));
+   entry-frame = frame;
+   entry-crc[0] = crc0;
+   entry-crc[1] = crc1;
+   entry-crc[2] = crc2;
+   entry-crc[3] = crc3;
+   entry-crc[4] = crc4;
 
head = (head + 1)  (INTEL_PIPE_CRC_ENTRIES_NR - 1);
atomic_set(pipe_crc-head, head);
 
wake_up_interruptible(pipe_crc-wq);
 }
+
+static void ivb_pipe_crc_update(struct drm_device *dev, enum pipe pipe)
+{
+   struct drm_i915_private *dev_priv = dev-dev_private;
+
+   display_pipe_crc_update(dev, pipe,
+   I915_READ(PIPE_CRC_RES_1_IVB(pipe)),
+   I915_READ(PIPE_CRC_RES_2_IVB(pipe)),
+   I915_READ(PIPE_CRC_RES_3_IVB(pipe)),
+   I915_READ(PIPE_CRC_RES_4_IVB(pipe)),
+   I915_READ(PIPE_CRC_RES_5_IVB(pipe)),
+   I915_READ(PIPEFRAME(pipe)));
+}
 #else
 static inline void ivb_pipe_crc_update(struct drm_device *dev, int pipe) {}
 #endif
-- 
1.8.4.rc3

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


[Intel-gfx] [PATCH 00/16] CRC support for non-ivb

2013-10-16 Thread Daniel Vetter
Hi all,

I've stitched together basic CRC support for non-ivb platforms. Still need to do
a bit more testing on this, but ignoring bugs this should be it. We also need to
pimp the igt testcase a bit so that it falls back to the new PIPE source if the
PLANE1 source isn't available.

Review and comments highly welcome.

Cheers, Daniel

Daniel Vetter (16):
  drm/i915: extract display_pipe_crc_update
  drm/i915: add CRC #defines for ilk/snb
  drm/i915: wire up CRC interrupt for ilk/snb
  drm/i915: use -get_vblank_counter for the crc frame counter
  drm/i915: wait one vblank when disabling CRCs
  drm/i915: fix CRC debugfs setup
  drm/i915: crc support for hsw
  drm/i915: Adjust CRC capture for pre-gen5/vlv
  drm/i915: CRC source selection #defines for gmch/vlv chips
  drm/i915: Wire up CRC interrupts for pre-gen5/vlv
  drm/i915: Enable CRC interrupts on pre-gen5/vlv
  drm/i915: Fix PIPE_CRC_CTL for vlv
  drm/i915: Add new CRC sources
  drm/i915: Wire up CRC support for gen3/4
  drm/i915: Wire up gen2 CRC support
  drm/i915: Wire up CRC for vlv

 drivers/gpu/drm/i915/i915_debugfs.c | 164 +++-
 drivers/gpu/drm/i915/i915_drv.h |   6 ++
 drivers/gpu/drm/i915/i915_irq.c | 151 +
 drivers/gpu/drm/i915/i915_reg.h |  74 +---
 4 files changed, 328 insertions(+), 67 deletions(-)

-- 
1.8.4.rc3

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


[Intel-gfx] [PATCH 03/16] drm/i915: wire up CRC interrupt for ilk/snb

2013-10-16 Thread Daniel Vetter
We enable the interrupt unconditionally and only control it
through the enable bit in the CRC control register.

v2: Extract per-platform helpers to compute the register values.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_debugfs.c | 74 -
 drivers/gpu/drm/i915/i915_drv.h |  1 +
 drivers/gpu/drm/i915/i915_irq.c | 26 -
 drivers/gpu/drm/i915/i915_reg.h |  2 +
 4 files changed, 84 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5fce5d8..323f58e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1914,6 +1914,7 @@ static const char * const pipe_crc_sources[] = {
plane1,
plane2,
pf,
+   pipe,
 };
 
 static const char *pipe_crc_source_name(enum intel_pipe_crc_source source)
@@ -1942,14 +1943,61 @@ static int display_crc_ctl_open(struct inode *inode, 
struct file *file)
return single_open(file, display_crc_ctl_show, dev);
 }
 
+static int ilk_pipe_crc_ctl_reg(enum intel_pipe_crc_source source,
+   uint32_t *val)
+{
+   switch (source) {
+   case INTEL_PIPE_CRC_SOURCE_PLANE1:
+   *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PRIMARY_ILK;
+   break;
+   case INTEL_PIPE_CRC_SOURCE_PLANE2:
+   *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_SPRITE_ILK;
+   break;
+   case INTEL_PIPE_CRC_SOURCE_PF:
+   return -EINVAL;
+   case INTEL_PIPE_CRC_SOURCE_PIPE:
+   *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PIPE_ILK;
+   break;
+   default:
+   *val = 0;
+   break;
+   }
+
+   return 0;
+}
+
+static int ivb_pipe_crc_ctl_reg(enum intel_pipe_crc_source source,
+   uint32_t *val)
+{
+   switch (source) {
+   case INTEL_PIPE_CRC_SOURCE_PLANE1:
+   *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PRIMARY_IVB;
+   break;
+   case INTEL_PIPE_CRC_SOURCE_PLANE2:
+   *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_SPRITE_IVB;
+   break;
+   case INTEL_PIPE_CRC_SOURCE_PF:
+   *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PF_IVB;
+   break;
+   case INTEL_PIPE_CRC_SOURCE_PIPE:
+   return -EINVAL;
+   default:
+   *val = 0;
+   break;
+   }
+
+   return 0;
+}
+
 static int pipe_crc_set_source(struct drm_device *dev, enum pipe pipe,
   enum intel_pipe_crc_source source)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[pipe];
u32 val;
+   int ret;
 
-   if (!IS_IVYBRIDGE(dev))
+   if (!(IS_IVYBRIDGE(dev) || IS_GEN5(dev) || IS_GEN6(dev)))
return -ENODEV;
 
if (pipe_crc-source == source)
@@ -1959,6 +2007,14 @@ static int pipe_crc_set_source(struct drm_device *dev, 
enum pipe pipe,
if (pipe_crc-source  source)
return -EINVAL;
 
+   if (IS_GEN5(dev) || IS_GEN6(dev))
+   ret = ilk_pipe_crc_ctl_reg(source, val);
+   else
+   ret = ivb_pipe_crc_ctl_reg(source, val);
+
+   if (ret != 0)
+   return ret;
+
/* none - real source transition */
if (source) {
DRM_DEBUG_DRIVER(collecting CRCs for pipe %c, %s\n,
@@ -1976,22 +2032,6 @@ static int pipe_crc_set_source(struct drm_device *dev, 
enum pipe pipe,
 
pipe_crc-source = source;
 
-   switch (source) {
-   case INTEL_PIPE_CRC_SOURCE_PLANE1:
-   val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PRIMARY_IVB;
-   break;
-   case INTEL_PIPE_CRC_SOURCE_PLANE2:
-   val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_SPRITE_IVB;
-   break;
-   case INTEL_PIPE_CRC_SOURCE_PF:
-   val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PF_IVB;
-   break;
-   case INTEL_PIPE_CRC_SOURCE_NONE:
-   default:
-   val = 0;
-   break;
-   }
-
I915_WRITE(PIPE_CRC_CTL(pipe), val);
POSTING_READ(PIPE_CRC_CTL(pipe));
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e2bf930..09857f8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1222,6 +1222,7 @@ enum intel_pipe_crc_source {
INTEL_PIPE_CRC_SOURCE_PLANE1,
INTEL_PIPE_CRC_SOURCE_PLANE2,
INTEL_PIPE_CRC_SOURCE_PF,
+   INTEL_PIPE_CRC_SOURCE_PIPE,
INTEL_PIPE_CRC_SOURCE_MAX,
 };
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index df031bb..36465ef 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1240,8 +1240,22 @@ static void ivb_pipe_crc_update(struct drm_device *dev, 
enum pipe pipe)
 

[Intel-gfx] [PATCH 02/16] drm/i915: add CRC #defines for ilk/snb

2013-10-16 Thread Daniel Vetter
Also add a new _PIPE_INC macro which takes an base plus increment.
Much less likely to botch the job by missing an s/A/B/ somewhere.

v2: They've moved the bitfield. Argh!

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_reg.h | 46 +++--
 1 file changed, 35 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4d01eaf..984bf9e1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -26,6 +26,7 @@
 #define _I915_REG_H_
 
 #define _PIPE(pipe, a, b) ((a) + (pipe)*((b)-(a)))
+#define _PIPE_INC(pipe, base, inc) ((base) + (pipe)*(inc))
 #define _TRANSCODER(tran, a, b) ((a) + (tran)*((b)-(a)))
 
 #define _PORT(port, a, b) ((a) + (port)*((b)-(a)))
@@ -1844,19 +1845,31 @@
 #define   PIPE_CRC_SOURCE_PRIMARY_IVB  (0  29)
 #define   PIPE_CRC_SOURCE_SPRITE_IVB   (1  29)
 #define   PIPE_CRC_SOURCE_PF_IVB   (2  29)
-#define _PIPE_CRC_RES_1_A_IVB  (dev_priv-info-display_mmio_offset + 0x60064)
-#define _PIPE_CRC_RES_2_A_IVB  (dev_priv-info-display_mmio_offset + 0x60068)
-#define _PIPE_CRC_RES_3_A_IVB  (dev_priv-info-display_mmio_offset + 0x6006c)
-#define _PIPE_CRC_RES_4_A_IVB  (dev_priv-info-display_mmio_offset + 0x60070)
-#define _PIPE_CRC_RES_5_A_IVB  (dev_priv-info-display_mmio_offset + 0x60074)
+#define   PIPE_CRC_SOURCE_PRIMARY_ILK  (0  28)
+#define   PIPE_CRC_SOURCE_SPRITE_ILK   (1  28)
+#define   PIPE_CRC_SOURCE_PIPE_ILK (2  28)
+/* embedded DP port on the north display block, reserved on ivb */
+#define   PIPE_CRC_SOURCE_PORT_A_ILK   (4  28)
+#define   PIPE_CRC_SOURCE_FDI_ILK  (5  28) /* reserved on ivb */
+#define _PIPE_CRC_RES_1_A_IVB  0x60064
+#define _PIPE_CRC_RES_2_A_IVB  0x60068
+#define _PIPE_CRC_RES_3_A_IVB  0x6006c
+#define _PIPE_CRC_RES_4_A_IVB  0x60070
+#define _PIPE_CRC_RES_5_A_IVB  0x60074
+
+#define _PIPE_CRC_RES_RED_A_ILK0x60060
+#define _PIPE_CRC_RES_GREEN_A_ILK  0x60064
+#define _PIPE_CRC_RES_BLUE_A_ILK   0x60068
+#define _PIPE_CRC_RES_RES1_A_ILK   0x6006c
+#define _PIPE_CRC_RES_RES2_A_ILK   0x60080
 
 /* Pipe B CRC regs */
-#define _PIPE_CRC_CTL_B(dev_priv-info-display_mmio_offset + 
0x61050)
-#define _PIPE_CRC_RES_1_B_IVB  (dev_priv-info-display_mmio_offset + 0x61064)
-#define _PIPE_CRC_RES_2_B_IVB  (dev_priv-info-display_mmio_offset + 0x61068)
-#define _PIPE_CRC_RES_3_B_IVB  (dev_priv-info-display_mmio_offset + 0x6106c)
-#define _PIPE_CRC_RES_4_B_IVB  (dev_priv-info-display_mmio_offset + 0x61070)
-#define _PIPE_CRC_RES_5_B_IVB  (dev_priv-info-display_mmio_offset + 0x61074)
+#define _PIPE_CRC_CTL_B0x61050
+#define _PIPE_CRC_RES_1_B_IVB  0x61064
+#define _PIPE_CRC_RES_2_B_IVB  0x61068
+#define _PIPE_CRC_RES_3_B_IVB  0x6106c
+#define _PIPE_CRC_RES_4_B_IVB  0x61070
+#define _PIPE_CRC_RES_5_B_IVB  0x61074
 
 #define PIPE_CRC_CTL(pipe) _PIPE(pipe, _PIPE_CRC_CTL_A, _PIPE_CRC_CTL_B)
 #define PIPE_CRC_RES_1_IVB(pipe)   \
@@ -1870,6 +1883,17 @@
 #define PIPE_CRC_RES_5_IVB(pipe)   \
_PIPE(pipe, _PIPE_CRC_RES_5_A_IVB, _PIPE_CRC_RES_5_B_IVB)
 
+#define PIPE_CRC_RES_RED_ILK(pipe) \
+   _PIPE_INC(pipe, _PIPE_CRC_RES_RED_A_ILK, 0x01000)
+#define PIPE_CRC_RES_GREEN_ILK(pipe) \
+   _PIPE_INC(pipe, _PIPE_CRC_RES_GREEN_A_ILK, 0x01000)
+#define PIPE_CRC_RES_BLUE_ILK(pipe) \
+   _PIPE_INC(pipe, _PIPE_CRC_RES_BLUE_A_ILK, 0x01000)
+#define PIPE_CRC_RES_RES1_ILK(pipe) \
+   _PIPE_INC(pipe, _PIPE_CRC_RES_RES1_A_ILK, 0x01000)
+#define PIPE_CRC_RES_RES2_ILK(pipe) \
+   _PIPE_INC(pipe, _PIPE_CRC_RES_RES2_A_ILK, 0x01000)
+
 /* Pipe A timing regs */
 #define _HTOTAL_A  (dev_priv-info-display_mmio_offset + 0x6)
 #define _HBLANK_A  (dev_priv-info-display_mmio_offset + 0x60004)
-- 
1.8.4.rc3

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


[Intel-gfx] [PATCH 05/16] drm/i915: wait one vblank when disabling CRCs

2013-10-16 Thread Daniel Vetter
This avoids a spurious spurious interrupt warning.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 323f58e..349f149 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2040,6 +2040,8 @@ static int pipe_crc_set_source(struct drm_device *dev, 
enum pipe pipe,
DRM_DEBUG_DRIVER(stopping CRCs for pipe %c\n,
 pipe_name(pipe));
 
+   intel_wait_for_vblank(dev, pipe);
+
kfree(pipe_crc-entries);
pipe_crc-entries = NULL;
}
-- 
1.8.4.rc3

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


[Intel-gfx] [PATCH 04/16] drm/i915: use -get_vblank_counter for the crc frame counter

2013-10-16 Thread Daniel Vetter
Suggested by Ville.

Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_irq.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 36465ef..eaf1268 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1193,7 +1193,7 @@ static void dp_aux_irq_handler(struct drm_device *dev)
 static void display_pipe_crc_update(struct drm_device *dev, enum pipe pipe,
uint32_t crc0, uint32_t crc1,
uint32_t crc2, uint32_t crc3,
-   uint32_t crc4, uint32_t frame)
+   uint32_t crc4)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[pipe];
@@ -1215,7 +1215,7 @@ static void display_pipe_crc_update(struct drm_device 
*dev, enum pipe pipe,
 
entry = pipe_crc-entries[head];
 
-   entry-frame = frame;
+   entry-frame = dev-driver-get_vblank_counter(dev, pipe);
entry-crc[0] = crc0;
entry-crc[1] = crc1;
entry-crc[2] = crc2;
@@ -1237,8 +1237,7 @@ static void ivb_pipe_crc_update(struct drm_device *dev, 
enum pipe pipe)
I915_READ(PIPE_CRC_RES_2_IVB(pipe)),
I915_READ(PIPE_CRC_RES_3_IVB(pipe)),
I915_READ(PIPE_CRC_RES_4_IVB(pipe)),
-   I915_READ(PIPE_CRC_RES_5_IVB(pipe)),
-   I915_READ(PIPEFRAME(pipe)));
+   I915_READ(PIPE_CRC_RES_5_IVB(pipe)));
 }
 
 static void ilk_pipe_crc_update(struct drm_device *dev, enum pipe pipe)
@@ -1250,8 +1249,7 @@ static void ilk_pipe_crc_update(struct drm_device *dev, 
enum pipe pipe)
I915_READ(PIPE_CRC_RES_GREEN_ILK(pipe)),
I915_READ(PIPE_CRC_RES_BLUE_ILK(pipe)),
I915_READ(PIPE_CRC_RES_RES1_ILK(pipe)),
-   I915_READ(PIPE_CRC_RES_RES2_ILK(pipe)),
-   I915_READ(PIPEFRAME(pipe)));
+   I915_READ(PIPE_CRC_RES_RES2_ILK(pipe)));
 }
 #else
 static inline void ivb_pipe_crc_update(struct drm_device *dev, int pipe) {}
-- 
1.8.4.rc3

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


[Intel-gfx] [PATCH 06/16] drm/i915: fix CRC debugfs setup

2013-10-16 Thread Daniel Vetter
We've set up all files, but removed only those for which we have a
pipe. Which leaves the one for pipe C on machines with less than 2
pipes, breaking module reload.

v2: We can't get at the drm device this early (wtf), so just register
all the files and also remove them all again.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_debugfs.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 349f149..bb55046 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2772,7 +2772,6 @@ int i915_debugfs_init(struct drm_minor *minor)
 
 void i915_debugfs_cleanup(struct drm_minor *minor)
 {
-   struct drm_device *dev = minor-dev;
int i;
 
drm_debugfs_remove_files(i915_debugfs_list,
@@ -2781,7 +2780,7 @@ void i915_debugfs_cleanup(struct drm_minor *minor)
drm_debugfs_remove_files((struct drm_info_list *) i915_forcewake_fops,
 1, minor);
 
-   for (i = 0; i  INTEL_INFO(dev)-num_pipes; i++) {
+   for (i = 0; i  ARRAY_SIZE(i915_pipe_crc_data); i++) {
struct drm_info_list *info_list =
(struct drm_info_list *)i915_pipe_crc_data[i];
 
-- 
1.8.4.rc3

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


[Intel-gfx] [PATCH 08/16] drm/i915: Adjust CRC capture for pre-gen5/vlv

2013-10-16 Thread Daniel Vetter
Should work down to gen2. The #defines for the interrupt sources are
already there in PIPESTAT and are the same on all gmch platforms for
gen2 up to vlv.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_irq.c | 28 +++-
 drivers/gpu/drm/i915/i915_reg.h | 30 +++---
 2 files changed, 34 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 156a1a4..98f5ac3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1249,21 +1249,31 @@ static void ivb_pipe_crc_update(struct drm_device *dev, 
enum pipe pipe)
I915_READ(PIPE_CRC_RES_5_IVB(pipe)));
 }
 
-static void ilk_pipe_crc_update(struct drm_device *dev, enum pipe pipe)
+static void i9xx_pipe_crc_update(struct drm_device *dev, enum pipe pipe)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
+   uint32_t res1, res2;
+
+   if (INTEL_INFO(dev)-gen = 3)
+   res1 = I915_READ(PIPE_CRC_RES_RES1_I915(pipe));
+   else
+   res1 = 0;
+
+   if (INTEL_INFO(dev)-gen = 5 || IS_G4X(dev))
+   res2 = I915_READ(PIPE_CRC_RES_RES2_G4X(pipe));
+   else
+   res2 = 0;
 
display_pipe_crc_update(dev, pipe,
-   I915_READ(PIPE_CRC_RES_RED_ILK(pipe)),
-   I915_READ(PIPE_CRC_RES_GREEN_ILK(pipe)),
-   I915_READ(PIPE_CRC_RES_BLUE_ILK(pipe)),
-   I915_READ(PIPE_CRC_RES_RES1_ILK(pipe)),
-   I915_READ(PIPE_CRC_RES_RES2_ILK(pipe)));
+   I915_READ(PIPE_CRC_RES_RED(pipe)),
+   I915_READ(PIPE_CRC_RES_GREEN(pipe)),
+   I915_READ(PIPE_CRC_RES_BLUE(pipe)),
+   res1, res2);
 }
 #else
 static inline void hsw_pipe_crc_update(struct drm_device *dev, int pipe) {}
 static inline void ivb_pipe_crc_update(struct drm_device *dev, int pipe) {}
-static inline void ilk_pipe_crc_update(struct drm_device *dev, int pipe) {}
+static inline void i9xx_pipe_crc_update(struct drm_device *dev, int pipe) {}
 #endif
 
 /* The RPS events need forcewake, so we add them to a work queue and mask their
@@ -1543,10 +1553,10 @@ static void ilk_display_irq_handler(struct drm_device 
*dev, u32 de_iir)
DRM_DEBUG_DRIVER(Pipe B FIFO underrun\n);
 
if (de_iir  DE_PIPEA_CRC_DONE)
-   ilk_pipe_crc_update(dev, PIPE_A);
+   i9xx_pipe_crc_update(dev, PIPE_A);
 
if (de_iir  DE_PIPEB_CRC_DONE)
-   ilk_pipe_crc_update(dev, PIPE_B);
+   i9xx_pipe_crc_update(dev, PIPE_B);
 
if (de_iir  DE_PLANEA_FLIP_DONE) {
intel_prepare_page_flip(dev, 0);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cf277ac..7379bbd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1858,11 +1858,11 @@
 #define _PIPE_CRC_RES_4_A_IVB  0x60070
 #define _PIPE_CRC_RES_5_A_IVB  0x60074
 
-#define _PIPE_CRC_RES_RED_A_ILK0x60060
-#define _PIPE_CRC_RES_GREEN_A_ILK  0x60064
-#define _PIPE_CRC_RES_BLUE_A_ILK   0x60068
-#define _PIPE_CRC_RES_RES1_A_ILK   0x6006c
-#define _PIPE_CRC_RES_RES2_A_ILK   0x60080
+#define _PIPE_CRC_RES_RED_A(dev_priv-info-display_mmio_offset + 
0x60060)
+#define _PIPE_CRC_RES_GREEN_A  (dev_priv-info-display_mmio_offset + 
0x60064)
+#define _PIPE_CRC_RES_BLUE_A   (dev_priv-info-display_mmio_offset + 
0x60068)
+#define _PIPE_CRC_RES_RES1_A_I915  (dev_priv-info-display_mmio_offset + 
0x6006c)
+#define _PIPE_CRC_RES_RES2_A_G4X   (dev_priv-info-display_mmio_offset + 
0x60080)
 
 /* Pipe B CRC regs */
 #define _PIPE_CRC_CTL_B0x61050
@@ -1884,16 +1884,16 @@
 #define PIPE_CRC_RES_5_IVB(pipe)   \
_PIPE(pipe, _PIPE_CRC_RES_5_A_IVB, _PIPE_CRC_RES_5_B_IVB)
 
-#define PIPE_CRC_RES_RED_ILK(pipe) \
-   _PIPE_INC(pipe, _PIPE_CRC_RES_RED_A_ILK, 0x01000)
-#define PIPE_CRC_RES_GREEN_ILK(pipe) \
-   _PIPE_INC(pipe, _PIPE_CRC_RES_GREEN_A_ILK, 0x01000)
-#define PIPE_CRC_RES_BLUE_ILK(pipe) \
-   _PIPE_INC(pipe, _PIPE_CRC_RES_BLUE_A_ILK, 0x01000)
-#define PIPE_CRC_RES_RES1_ILK(pipe) \
-   _PIPE_INC(pipe, _PIPE_CRC_RES_RES1_A_ILK, 0x01000)
-#define PIPE_CRC_RES_RES2_ILK(pipe) \
-   _PIPE_INC(pipe, _PIPE_CRC_RES_RES2_A_ILK, 0x01000)
+#define PIPE_CRC_RES_RED(pipe) \
+   _PIPE_INC(pipe, _PIPE_CRC_RES_RED_A, 0x01000)
+#define PIPE_CRC_RES_GREEN(pipe) \
+   _PIPE_INC(pipe, _PIPE_CRC_RES_GREEN_A, 0x01000)
+#define PIPE_CRC_RES_BLUE(pipe) \
+   _PIPE_INC(pipe, _PIPE_CRC_RES_BLUE_A, 0x01000)
+#define PIPE_CRC_RES_RES1_I915(pipe) \
+   _PIPE_INC(pipe, _PIPE_CRC_RES_RES1_A_I915, 0x01000)
+#define 

[Intel-gfx] [PATCH 09/16] drm/i915: CRC source selection #defines for gmch/vlv chips

2013-10-16 Thread Daniel Vetter
A bit a mess, since with DP/TV outputs we can't use the pipe CRC.
Also, no plane CRCs, so we need to update the basic testcases.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_reg.h | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7379bbd..ad8fe21 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1843,15 +1843,37 @@
 /* Pipe A CRC regs */
 #define _PIPE_CRC_CTL_A(dev_priv-info-display_mmio_offset + 
0x60050)
 #define   PIPE_CRC_ENABLE  (1  31)
+/* ivb+ source selection */
 #define   PIPE_CRC_SOURCE_PRIMARY_IVB  (0  29)
 #define   PIPE_CRC_SOURCE_SPRITE_IVB   (1  29)
 #define   PIPE_CRC_SOURCE_PF_IVB   (2  29)
+/* ilk+ source selection */
 #define   PIPE_CRC_SOURCE_PRIMARY_ILK  (0  28)
 #define   PIPE_CRC_SOURCE_SPRITE_ILK   (1  28)
 #define   PIPE_CRC_SOURCE_PIPE_ILK (2  28)
 /* embedded DP port on the north display block, reserved on ivb */
 #define   PIPE_CRC_SOURCE_PORT_A_ILK   (4  28)
 #define   PIPE_CRC_SOURCE_FDI_ILK  (5  28) /* reserved on ivb */
+/* vlv source selection */
+#define   PIPE_CRC_SOURCE_PIPE_VLV (0  27)
+#define   PIPE_CRC_SOURCE_HDMIB_VLV(1  27)
+#define   PIPE_CRC_SOURCE_HDMIC_VLV(2  27)
+/* with DP port the pipe source is invalid */
+#define   PIPE_CRC_SOURCE_DP_D_VLV (3  27)
+#define   PIPE_CRC_SOURCE_DP_B_VLV (6  27)
+#define   PIPE_CRC_SOURCE_DP_C_VLV (7  27)
+/* gen3+ source selection */
+#define   PIPE_CRC_SOURCE_PIPE_I9XX(0  28)
+#define   PIPE_CRC_SOURCE_SDVOB_I9XX   (1  28)
+#define   PIPE_CRC_SOURCE_SDVOC_I9XX   (2  28)
+/* with DP/TV port the pipe source is invalid */
+#define   PIPE_CRC_SOURCE_DP_D_G4X (3  28)
+#define   PIPE_CRC_SOURCE_TV_PRE   (4  28)
+#define   PIPE_CRC_SOURCE_TV_POST  (5  28)
+#define   PIPE_CRC_SOURCE_DP_B_G4X (6  28)
+#define   PIPE_CRC_SOURCE_DP_C_G4X (7  28)
+/* gen2 doesn't have source selection bits */
+
 #define _PIPE_CRC_RES_1_A_IVB  0x60064
 #define _PIPE_CRC_RES_2_A_IVB  0x60068
 #define _PIPE_CRC_RES_3_A_IVB  0x6006c
-- 
1.8.4.rc3

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


[Intel-gfx] [PATCH 10/16] drm/i915: Wire up CRC interrupts for pre-gen5/vlv

2013-10-16 Thread Daniel Vetter
And throw in a tiny for_each_pipe refactoring for gen2.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_irq.c | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 98f5ac3..b31e7ca 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1350,6 +1350,9 @@ static irqreturn_t valleyview_irq_handler(int irq, void 
*arg)
intel_prepare_page_flip(dev, pipe);
intel_finish_page_flip(dev, pipe);
}
+
+   if (pipe_stats[pipe]  PIPE_CRC_DONE_INTERRUPT_STATUS)
+   i9xx_pipe_crc_update(dev, pipe);
}
 
/* Consume port.  Then clear IIR or we'll miss events */
@@ -2800,13 +2803,14 @@ static irqreturn_t i8xx_irq_handler(int irq, void *arg)
if (iir  I915_USER_INTERRUPT)
notify_ring(dev, dev_priv-ring[RCS]);
 
-   if (pipe_stats[0]  PIPE_VBLANK_INTERRUPT_STATUS 
-   i8xx_handle_vblank(dev, 0, iir))
-   flip_mask = ~DISPLAY_PLANE_FLIP_PENDING(0);
+   for_each_pipe(pipe) {
+   if (pipe_stats[pipe]  PIPE_VBLANK_INTERRUPT_STATUS 
+   i8xx_handle_vblank(dev, pipe, iir))
+   flip_mask = ~DISPLAY_PLANE_FLIP_PENDING(pipe);
 
-   if (pipe_stats[1]  PIPE_VBLANK_INTERRUPT_STATUS 
-   i8xx_handle_vblank(dev, 1, iir))
-   flip_mask = ~DISPLAY_PLANE_FLIP_PENDING(1);
+   if (pipe_stats[pipe]  PIPE_CRC_DONE_INTERRUPT_STATUS)
+   i9xx_pipe_crc_update(dev, pipe);
+   }
 
iir = new_iir;
}
@@ -2999,6 +3003,9 @@ static irqreturn_t i915_irq_handler(int irq, void *arg)
 
if (pipe_stats[pipe]  PIPE_LEGACY_BLC_EVENT_STATUS)
blc_event = true;
+
+   if (pipe_stats[pipe]  PIPE_CRC_DONE_INTERRUPT_STATUS)
+   i9xx_pipe_crc_update(dev, pipe);
}
 
if (blc_event || (iir  I915_ASLE_INTERRUPT))
@@ -3243,6 +3250,9 @@ static irqreturn_t i965_irq_handler(int irq, void *arg)
 
if (pipe_stats[pipe]  PIPE_LEGACY_BLC_EVENT_STATUS)
blc_event = true;
+
+   if (pipe_stats[pipe]  PIPE_CRC_DONE_INTERRUPT_STATUS)
+   i9xx_pipe_crc_update(dev, pipe);
}
 
 
-- 
1.8.4.rc3

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


[Intel-gfx] [PATCH 12/16] drm/i915: Fix PIPE_CRC_CTL for vlv

2013-10-16 Thread Daniel Vetter
The PIPE_B #define was missing the display mmio offset. Use the
_PIPE_INC macro instead, it's simpler.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_reg.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ad8fe21..4e0f0b7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1887,14 +1887,13 @@
 #define _PIPE_CRC_RES_RES2_A_G4X   (dev_priv-info-display_mmio_offset + 
0x60080)
 
 /* Pipe B CRC regs */
-#define _PIPE_CRC_CTL_B0x61050
 #define _PIPE_CRC_RES_1_B_IVB  0x61064
 #define _PIPE_CRC_RES_2_B_IVB  0x61068
 #define _PIPE_CRC_RES_3_B_IVB  0x6106c
 #define _PIPE_CRC_RES_4_B_IVB  0x61070
 #define _PIPE_CRC_RES_5_B_IVB  0x61074
 
-#define PIPE_CRC_CTL(pipe) _PIPE(pipe, _PIPE_CRC_CTL_A, _PIPE_CRC_CTL_B)
+#define PIPE_CRC_CTL(pipe) _PIPE_INC(pipe, _PIPE_CRC_CTL_A, 0x01000)
 #define PIPE_CRC_RES_1_IVB(pipe)   \
_PIPE(pipe, _PIPE_CRC_RES_1_A_IVB, _PIPE_CRC_RES_1_B_IVB)
 #define PIPE_CRC_RES_2_IVB(pipe)   \
-- 
1.8.4.rc3

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


[Intel-gfx] [PATCH 13/16] drm/i915: Add new CRC sources

2013-10-16 Thread Daniel Vetter
On pre-gen5 and vlv we can't use the pipe source when TV-out or a DP
port is connected to the pipe. Hence we need to expose new CRC
sources.

Also simplify the existing pipe source platform code a bit by
rejecting all unhandled sources by default.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_debugfs.c | 16 ++--
 drivers/gpu/drm/i915/i915_drv.h |  5 +
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 59c7653..c504c27 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1915,6 +1915,10 @@ static const char * const pipe_crc_sources[] = {
plane2,
pf,
pipe,
+   TV,
+   DP-B,
+   DP-C,
+   DP-D,
 };
 
 static const char *pipe_crc_source_name(enum intel_pipe_crc_source source)
@@ -1953,14 +1957,14 @@ static int ilk_pipe_crc_ctl_reg(enum 
intel_pipe_crc_source source,
case INTEL_PIPE_CRC_SOURCE_PLANE2:
*val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_SPRITE_ILK;
break;
-   case INTEL_PIPE_CRC_SOURCE_PF:
-   return -EINVAL;
case INTEL_PIPE_CRC_SOURCE_PIPE:
*val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PIPE_ILK;
break;
-   default:
+   case INTEL_PIPE_CRC_SOURCE_NONE:
*val = 0;
break;
+   default:
+   return -EINVAL;
}
 
return 0;
@@ -1979,11 +1983,11 @@ static int ivb_pipe_crc_ctl_reg(enum 
intel_pipe_crc_source source,
case INTEL_PIPE_CRC_SOURCE_PF:
*val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PF_IVB;
break;
-   case INTEL_PIPE_CRC_SOURCE_PIPE:
-   return -EINVAL;
-   default:
+   case INTEL_PIPE_CRC_SOURCE_NONE:
*val = 0;
break;
+   default:
+   return -EINVAL;
}
 
return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 09857f8..4ba0a79 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1223,6 +1223,11 @@ enum intel_pipe_crc_source {
INTEL_PIPE_CRC_SOURCE_PLANE2,
INTEL_PIPE_CRC_SOURCE_PF,
INTEL_PIPE_CRC_SOURCE_PIPE,
+   /* TV/DP on pre-gen5/vlv can't use the pipe source. */
+   INTEL_PIPE_CRC_SOURCE_TV,
+   INTEL_PIPE_CRC_SOURCE_DP_B,
+   INTEL_PIPE_CRC_SOURCE_DP_C,
+   INTEL_PIPE_CRC_SOURCE_DP_D,
INTEL_PIPE_CRC_SOURCE_MAX,
 };
 
-- 
1.8.4.rc3

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


[Intel-gfx] [PATCH 14/16] drm/i915: Wire up CRC support for gen3/4

2013-10-16 Thread Daniel Vetter
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_debugfs.c | 44 +++--
 1 file changed, 42 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index c504c27..6de9e7e 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1947,6 +1947,44 @@ static int display_crc_ctl_open(struct inode *inode, 
struct file *file)
return single_open(file, display_crc_ctl_show, dev);
 }
 
+static int i9xx_pipe_crc_ctl_reg(struct drm_device *dev,
+enum intel_pipe_crc_source source,
+uint32_t *val)
+{
+   switch (source) {
+   case INTEL_PIPE_CRC_SOURCE_PIPE:
+   *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PIPE_I9XX;
+   break;
+   case INTEL_PIPE_CRC_SOURCE_TV:
+   if (!SUPPORTS_TV(dev))
+   return -EINVAL;
+   *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_TV_PRE;
+   break;
+   case INTEL_PIPE_CRC_SOURCE_DP_B:
+   if (!IS_G4X(dev))
+   return -EINVAL;
+   *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_B_G4X;
+   break;
+   case INTEL_PIPE_CRC_SOURCE_DP_C:
+   if (!IS_G4X(dev))
+   return -EINVAL;
+   *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_C_G4X;
+   break;
+   case INTEL_PIPE_CRC_SOURCE_DP_D:
+   if (!IS_G4X(dev))
+   return -EINVAL;
+   *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_D_G4X;
+   break;
+   case INTEL_PIPE_CRC_SOURCE_NONE:
+   *val = 0;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 static int ilk_pipe_crc_ctl_reg(enum intel_pipe_crc_source source,
uint32_t *val)
 {
@@ -2001,7 +2039,7 @@ static int pipe_crc_set_source(struct drm_device *dev, 
enum pipe pipe,
u32 val;
int ret;
 
-   if (!(INTEL_INFO(dev)-gen = 5  !IS_VALLEYVIEW(dev)))
+   if (!(INTEL_INFO(dev)-gen = 3  !IS_VALLEYVIEW(dev)))
return -ENODEV;
 
if (pipe_crc-source == source)
@@ -2011,7 +2049,9 @@ static int pipe_crc_set_source(struct drm_device *dev, 
enum pipe pipe,
if (pipe_crc-source  source)
return -EINVAL;
 
-   if (IS_GEN5(dev) || IS_GEN6(dev))
+   if (INTEL_INFO(dev)-gen  5)
+   ret = i9xx_pipe_crc_ctl_reg(dev, source, val);
+   else if (IS_GEN5(dev) || IS_GEN6(dev))
ret = ilk_pipe_crc_ctl_reg(source, val);
else
ret = ivb_pipe_crc_ctl_reg(source, val);
-- 
1.8.4.rc3

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


[Intel-gfx] [PATCH] tests/debugfs_pipe_crc: fall back to PIPE source

2013-10-16 Thread Daniel Vetter
With PLANE1 and PIPE CRC sources the test will work on all currently
shipping (and planed fwiw) platforms.

Also add all the other new sources for non-ivb/hsw chips.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 lib/igt_debugfs.c| 12 +++-
 lib/igt_debugfs.h|  7 ++-
 tests/debugfs_pipe_crc.c |  8 +++-
 3 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index 371f583..f903454 100644
--- a/lib/igt_debugfs.c
+++ b/lib/igt_debugfs.c
@@ -207,6 +207,11 @@ static const char *pipe_crc_sources[] = {
 plane1,
 plane2,
 pf,
+   pipe,
+   TV,
+   DP-B,
+   DP-C,
+   DP-D
 };
 
 static const char *pipe_crc_source_name(enum intel_pipe_crc_source source)
@@ -214,7 +219,7 @@ static const char *pipe_crc_source_name(enum 
intel_pipe_crc_source source)
 return pipe_crc_sources[source];
 }
 
-void igt_pipe_crc_start(igt_pipe_crc_t *pipe_crc)
+bool igt_pipe_crc_start(igt_pipe_crc_t *pipe_crc)
 {
char buf[64];
igt_crc_t *crcs = NULL;
@@ -223,7 +228,10 @@ void igt_pipe_crc_start(igt_pipe_crc_t *pipe_crc)
 
sprintf(buf, pipe %c %s, pipe_name(pipe_crc-pipe),
pipe_crc_source_name(pipe_crc-source));
+   errno = 0;
write(pipe_crc-ctl_fd, buf, strlen(buf));
+   if (errno != 0)
+   return false;
 
/*
 * For some no yet identified reason, the first CRC is bonkers. So
@@ -231,6 +239,8 @@ void igt_pipe_crc_start(igt_pipe_crc_t *pipe_crc)
 */
igt_pipe_crc_get_crcs(pipe_crc, 1, crcs);
free(crcs);
+
+   return true;
 }
 
 void igt_pipe_crc_stop(igt_pipe_crc_t *pipe_crc)
diff --git a/lib/igt_debugfs.h b/lib/igt_debugfs.h
index 7c280e7..f2873e0 100644
--- a/lib/igt_debugfs.h
+++ b/lib/igt_debugfs.h
@@ -50,6 +50,11 @@ enum intel_pipe_crc_source {
 INTEL_PIPE_CRC_SOURCE_PLANE1,
 INTEL_PIPE_CRC_SOURCE_PLANE2,
 INTEL_PIPE_CRC_SOURCE_PF,
+INTEL_PIPE_CRC_SOURCE_PIPE,
+INTEL_PIPE_CRC_SOURCE_TV,
+INTEL_PIPE_CRC_SOURCE_DP_B,
+INTEL_PIPE_CRC_SOURCE_DP_C,
+INTEL_PIPE_CRC_SOURCE_DP_D,
 INTEL_PIPE_CRC_SOURCE_MAX,
 };
 
@@ -69,7 +74,7 @@ igt_pipe_crc_new(igt_debugfs_t *debugfs, int drm_fd, enum 
pipe pipe,
 enum intel_pipe_crc_source source);
 void igt_pipe_crc_reset(void);
 void igt_pipe_crc_free(igt_pipe_crc_t *pipe_crc);
-void igt_pipe_crc_start(igt_pipe_crc_t *pipe_crc);
+bool igt_pipe_crc_start(igt_pipe_crc_t *pipe_crc);
 void igt_pipe_crc_stop(igt_pipe_crc_t *pipe_crc);
 void igt_pipe_crc_get_crcs(igt_pipe_crc_t *pipe_crc, int n_crcs,
   igt_crc_t **out_crcs);
diff --git a/tests/debugfs_pipe_crc.c b/tests/debugfs_pipe_crc.c
index 9884fd7..f9ebac9 100644
--- a/tests/debugfs_pipe_crc.c
+++ b/tests/debugfs_pipe_crc.c
@@ -172,7 +172,13 @@ static void test_read_crc(data_t *data)
 
connector_set_mode(data, connector, connector-config.default_mode);
 
-   igt_pipe_crc_start(pipe_crc);
+   if (!igt_pipe_crc_start(pipe_crc)) {
+   igt_pipe_crc_free(pipe_crc);
+   pipe_crc = igt_pipe_crc_new(data-debugfs, data-drm_fd,
+   connector-config.pipe,
+   INTEL_PIPE_CRC_SOURCE_PIPE);
+   igt_assert(igt_pipe_crc_start(pipe_crc));
+   }
 
/* wait for 3 vblanks and the corresponding 3 CRCs */
igt_pipe_crc_get_crcs(pipe_crc, 3, crcs);
-- 
1.8.4.rc3

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


[Intel-gfx] [PATCH 16/16] drm/i915: Wire up CRC for vlv

2013-10-16 Thread Daniel Vetter
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_debugfs.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index ff6970b..5841b6f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1961,6 +1961,29 @@ static int i8xx_pipe_crc_ctl_reg(enum 
intel_pipe_crc_source source,
return 0;
 }
 
+static int vlv_pipe_crc_ctl_reg(enum intel_pipe_crc_source source,
+   uint32_t *val)
+{
+   switch (source) {
+   case INTEL_PIPE_CRC_SOURCE_PIPE:
+   *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_PIPE_VLV;
+   break;
+   case INTEL_PIPE_CRC_SOURCE_DP_B:
+   *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_B_VLV;
+   break;
+   case INTEL_PIPE_CRC_SOURCE_DP_C:
+   *val = PIPE_CRC_ENABLE | PIPE_CRC_SOURCE_DP_C_VLV;
+   break;
+   case INTEL_PIPE_CRC_SOURCE_NONE:
+   *val = 0;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 static int i9xx_pipe_crc_ctl_reg(struct drm_device *dev,
 enum intel_pipe_crc_source source,
 uint32_t *val)
@@ -2067,6 +2090,8 @@ static int pipe_crc_set_source(struct drm_device *dev, 
enum pipe pipe,
ret = i8xx_pipe_crc_ctl_reg(source, val);
else if (INTEL_INFO(dev)-gen  5)
ret = i9xx_pipe_crc_ctl_reg(dev, source, val);
+   else if (IS_VALLEYVIEW(dev))
+   ret = vlv_pipe_crc_ctl_reg(source, val);
else if (IS_GEN5(dev) || IS_GEN6(dev))
ret = ilk_pipe_crc_ctl_reg(source, val);
else
-- 
1.8.4.rc3

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


[Intel-gfx] [PATCH 15/16] drm/i915: Wire up gen2 CRC support

2013-10-16 Thread Daniel Vetter
Really simple, and we don't even have working frame numbers.

Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
 drivers/gpu/drm/i915/i915_debugfs.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6de9e7e..ff6970b 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1947,6 +1947,20 @@ static int display_crc_ctl_open(struct inode *inode, 
struct file *file)
return single_open(file, display_crc_ctl_show, dev);
 }
 
+static int i8xx_pipe_crc_ctl_reg(enum intel_pipe_crc_source source,
+uint32_t *val)
+{
+   switch (source) {
+   case INTEL_PIPE_CRC_SOURCE_PIPE:
+   *val = PIPE_CRC_ENABLE;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
 static int i9xx_pipe_crc_ctl_reg(struct drm_device *dev,
 enum intel_pipe_crc_source source,
 uint32_t *val)
@@ -2049,7 +2063,9 @@ static int pipe_crc_set_source(struct drm_device *dev, 
enum pipe pipe,
if (pipe_crc-source  source)
return -EINVAL;
 
-   if (INTEL_INFO(dev)-gen  5)
+   if (IS_GEN2(dev))
+   ret = i8xx_pipe_crc_ctl_reg(source, val);
+   else if (INTEL_INFO(dev)-gen  5)
ret = i9xx_pipe_crc_ctl_reg(dev, source, val);
else if (IS_GEN5(dev) || IS_GEN6(dev))
ret = ilk_pipe_crc_ctl_reg(source, val);
-- 
1.8.4.rc3

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


Re: [Intel-gfx] [v3.10][v3.11][v3.12][Regression][PATCH 1/1] Revert Revert drm/i915: revert eDP bpp clamping code changes

2013-10-16 Thread Daniel Vetter
On Wed, Oct 16, 2013 at 04:34:57PM -0400, Joseph Salisbury wrote:
 BugLink: http://bugs.launchpad.net/bugs/1195483
 
 This reverts commit 657445fe8660100ad174600ebfa61536392b7624.
 
 Signed-off-by: Joseph Salisbury joseph.salisb...@canonical.com
 Cc: Daniel Vetter daniel.vet...@ffwll.ch
 Cc: Paulo Zanoni przan...@gmail.com
 Cc: David Airlie airl...@linux.ie
 Cc: sta...@vger.kernel.org

It's by far not that simple. Jani is working on both the underlying bug
and a better w/a. See

https://bugzilla.kernel.org/show_bug.cgi?id=59841

for the full story in its entire glory.

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


Re: [Intel-gfx] [PATCH] cpufreq: Add dummy cpufreq_cpu_get/put for CONFIG_CPU_FREQ=n

2013-10-16 Thread Rafael J. Wysocki
On Tuesday, October 08, 2013 10:56:11 AM Daniel Vetter wrote:
 The drm/i915 driver wants to adjust it's own power policies using the
 cpu policies as a guideline (we can implicitly boost the cpus through
 the gpus on some platforms). To avoid a dreaded select (since a
 depends will leave users wondering where where their driver has gone
 too) add dummy functions.
 
 Reported-by: kbuild test robot fengguang...@intel.com
 Cc: kbuild test robot fengguang...@intel.com
 Cc: Rafael J. Wysocki r...@sisk.pl
 Cc: Viresh Kumar viresh.ku...@linaro.org
 Cc: cpuf...@vger.kernel.org
 Cc: linux...@vger.kernel.org
 Cc: linux-ker...@vger.kernel.org
 Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
 ---
 A quick ack for merging this this through the drm-intel tree is
 probably the simplest way forward.

Well, ACK, or please let me know if you want me to take this.

Thanks!

 ---
  include/linux/cpufreq.h | 8 
  1 file changed, 8 insertions(+)
 
 diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
 index fcabc42..5ad9a4e 100644
 --- a/include/linux/cpufreq.h
 +++ b/include/linux/cpufreq.h
 @@ -93,8 +93,16 @@ struct cpufreq_policy {
  #define CPUFREQ_SHARED_TYPE_ALL   (2) /* All dependent CPUs should set 
 freq */
  #define CPUFREQ_SHARED_TYPE_ANY   (3) /* Freq can be set from any 
 dependent CPU*/
  
 +#ifdef CONFIG_CPU_FREQ
  struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu);
  void cpufreq_cpu_put(struct cpufreq_policy *policy);
 +#else
 +static inline struct cpufreq_policy *cpufreq_cpu_get(unsigned int cpu)
 +{
 + return NULL;
 +}
 +static inline void cpufreq_cpu_put(struct cpufreq_policy *policy) { }
 +#endif
  
  static inline bool policy_is_shared(struct cpufreq_policy *policy)
  {
 
-- 
I speak only for myself.
Rafael J. Wysocki, 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] [IGT PATCH] README: list some of the dependencies

2013-10-16 Thread Ben Widawsky
On Tue, Oct 08, 2013 at 09:19:06PM +0300, Jani Nikula wrote:
 Signed-off-by: Jani Nikula jani.nik...@intel.com
 ---
  README |   12 
  1 file changed, 12 insertions(+)
 
 diff --git a/README b/README
 index 653bfcd..a04c987 100644
 --- a/README
 +++ b/README
 @@ -96,3 +96,15 @@ debugger/
   initiating connections with debug clients..
  
   The debugger must be run as root: sudo debugger/eudb
 +
 +DEPENDENCIES
 + This is a non-exchaustive list of package dependencies required for
 + building everything:
 +
 + libpciaccess-dev
 + libdrm-dev
 + xutils-dev
 + libcairo2-dev
 + swig2.0
 + libpython3.3-dev
 + x11proto-dri2-dev

I've pushed this. Some documentation is better than no documentation.

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