Re: [Intel-gfx] [PATCH 01/14] drm/i915: Parametrize PANEL_PORT_SELECT_VLV

[Jani Nikula]

On Mon, 18 Aug 2014, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
>
> Passing the port as a parameter to PANEL_PORT_SELECT_VLV results in
> neater code. Sadly the PCH port select bits aren't suitable for the
> same treatment and the resulting macro would be much uglier, so
> leave those defines as is.

Reviewed-by: Jani Nikula 

>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_reg.h |  3 +--
>  drivers/gpu/drm/i915/intel_dp.c | 12 
>  2 files changed, 5 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index daac02b..9503d96 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5383,8 +5383,7 @@ enum punit_power_well {
>  #define PIPEA_PP_STATUS (VLV_DISPLAY_BASE + 0x61200)
>  #define PIPEA_PP_CONTROL(VLV_DISPLAY_BASE + 0x61204)
>  #define PIPEA_PP_ON_DELAYS  (VLV_DISPLAY_BASE + 0x61208)
> -#define  PANEL_PORT_SELECT_DPB_VLV   (1 << 30)
> -#define  PANEL_PORT_SELECT_DPC_VLV   (2 << 30)
> +#define  PANEL_PORT_SELECT_VLV(port) ((port) << 30)
>  #define PIPEA_PP_OFF_DELAYS (VLV_DISPLAY_BASE + 0x6120c)
>  #define PIPEA_PP_DIVISOR(VLV_DISPLAY_BASE + 0x61210)
>  
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 4f69648..43dd226 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -308,9 +308,7 @@ vlv_power_sequencer_pipe(struct intel_dp *intel_dp)
>   for (pipe = PIPE_A; pipe <= PIPE_B; pipe++) {
>   u32 port_sel = I915_READ(VLV_PIPE_PP_ON_DELAYS(pipe)) &
>   PANEL_PORT_SELECT_MASK;
> - if (port_sel == PANEL_PORT_SELECT_DPB_VLV && port == PORT_B)
> - return pipe;
> - if (port_sel == PANEL_PORT_SELECT_DPC_VLV && port == PORT_C)
> + if (port_sel == PANEL_PORT_SELECT_VLV(port))
>   return pipe;
>   }
>  
> @@ -4294,6 +4292,7 @@ intel_dp_init_panel_power_sequencer_registers(struct 
> drm_device *dev,
>   u32 pp_on, pp_off, pp_div, port_sel = 0;
>   int div = HAS_PCH_SPLIT(dev) ? intel_pch_rawclk(dev) : 
> intel_hrawclk(dev);
>   int pp_on_reg, pp_off_reg, pp_div_reg;
> + enum port port = dp_to_dig_port(intel_dp)->port;
>  
>   if (HAS_PCH_SPLIT(dev)) {
>   pp_on_reg = PCH_PP_ON_DELAYS;
> @@ -4328,12 +4327,9 @@ intel_dp_init_panel_power_sequencer_registers(struct 
> drm_device *dev,
>   /* Haswell doesn't have any port selection bits for the panel
>* power sequencer any more. */
>   if (IS_VALLEYVIEW(dev)) {
> - if (dp_to_dig_port(intel_dp)->port == PORT_B)
> - port_sel = PANEL_PORT_SELECT_DPB_VLV;
> - else
> - port_sel = PANEL_PORT_SELECT_DPC_VLV;
> + port_sel = PANEL_PORT_SELECT_VLV(port);
>   } else if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev)) {
> - if (dp_to_dig_port(intel_dp)->port == PORT_A)
> + if (port == PORT_A)
>   port_sel = PANEL_PORT_SELECT_DPA;
>   else
>   port_sel = PANEL_PORT_SELECT_DPD;
> -- 
> 1.8.5.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] [PATCH i-g-t] kms_rotation_crc: Calling commit2 instead of legacy commit

[sonika . jindal]

From: Sonika Jindal 

Since planes are universal now, using commit2 so that drmModeSetPlane can be
called for primary plane as well instead of drmModeSetCrtc. drmModeSetPlane will
update the x,y,w,h for the plane.

Cc: Damien Lespiau 

Signed-off-by: Sonika Jindal 
---
 tests/kms_rotation_crc.c |4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
index 5041f90..9daa4f6 100644
--- a/tests/kms_rotation_crc.c
+++ b/tests/kms_rotation_crc.c
@@ -72,7 +72,6 @@ static bool prepare_crtc(data_t *data, igt_output_t *output, 
enum pipe pipe,
 
igt_output_set_pipe(output, pipe);
 
-
/* create the pipe_crc object for this pipe */
igt_pipe_crc_free(data->pipe_crc);
data->pipe_crc = igt_pipe_crc_new(pipe, INTEL_PIPE_CRC_SOURCE_AUTO);
@@ -119,8 +118,6 @@ static bool prepare_crtc(data_t *data, igt_output_t 
*output, enum pipe pipe,
paint_squares(data, &data->fb, mode, IGT_ROTATION_0);
 
igt_plane_set_fb(plane, &data->fb);
-   igt_display_commit(display);
-
return true;
 }
 
@@ -172,6 +169,7 @@ static void test_plane_rotation(data_t *data, enum 
igt_plane plane_type)
 
if (!prepare_crtc(data, output, pipe, plane))
continue;
+   igt_display_commit2(display, commit);
 
igt_plane_set_rotation(plane, IGT_ROTATION_180);
igt_display_commit2(display, commit);
-- 
1.7.10.4

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

[Intel-gfx] [PATCH 2/2] drm/i915: Add 180 degree primary plane rotation support

[sonika . jindal]

From: Sonika Jindal 

Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.

v2: Calculating linear/tiled offsets based on pipe source width and
height. Added 180 degree rotation support in ironlake_update_plane.

v3: Checking if CRTC is active before issueing update_plane. Added
wait for vblank to make sure we dont overtake page flips. Disabling
FBC since it does not work with rotated planes.

v4: Updated rotation checks for pending flips, fbc disable. Creating
rotation property only for Gen4 onwards. Property resetting as part
of lastclose.

v5: Resetting property in i915_driver_lastclose properly for planes
and crtcs. Fixed linear offset calculation that was off by 1 w.r.t
width in i9xx_update_plane and ironlake_update_plane. Removed tab
based indentation and unnecessary braces in intel_crtc_set_property
and intel_update_fbc. FBC and flip related checks should be done only
for valid crtcs.

v6: Minor nits in FBC disable checks for comments in intel_crtc_set_property
and positioning the disable code in intel_update_fbc.

v7: In case rotation property on inactive crtc is updated, we return
successfully printing debug log as crtc is inactive and only property change
is preserved.

v8: update_plane is changed to update_primary_plane, crtc->fb is changed to
crtc->primary->fb  and return value of update_primary_plane is ignored.

v9: added rotation property to primary plane instead of crtc. Removing reset
of rotation property from lastclose. rotation_property is moved to
drm_mode_config, so drm layer will take care of resetting. Adding updation of
fbc when rotation is set to 0. Allowing rotation only if value is
different than old one.

v10: Calling intel_primary_plane_setplane instead of update_primary_plane in
set_property(Daniel).

Testcase: igt/kms_rotation_crc

Signed-off-by: Uma Shankar 
Signed-off-by: Sagar Kamble 
Signed-off-by: Sonika Jindal 
---
 drivers/gpu/drm/i915/i915_reg.h  |1 +
 drivers/gpu/drm/i915/intel_display.c |  116 --
 drivers/gpu/drm/i915/intel_pm.c  |6 ++
 3 files changed, 119 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7a6cc69..f8aaf0b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4209,6 +4209,7 @@ enum punit_power_well {
 #define   DISPPLANE_NO_LINE_DOUBLE 0
 #define   DISPPLANE_STEREO_POLARITY_FIRST  0
 #define   DISPPLANE_STEREO_POLARITY_SECOND (1<<18)
+#define   DISPPLANE_ROTATE_180 (1<<15)
 #define   DISPPLANE_TRICKLE_FEED_DISABLE   (1<<14) /* Ironlake */
 #define   DISPPLANE_TILED  (1<<10)
 #define _DSPAADDR  0x70184
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 1b0e403..cc2999b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2332,6 +2332,9 @@ static void i9xx_update_primary_plane(struct drm_crtc 
*crtc,
unsigned long linear_offset;
u32 dspcntr;
u32 reg = DSPCNTR(plane);
+   int pixel_size;
+
+   pixel_size = drm_format_plane_cpp(fb->pixel_format, 0);
 
if (!intel_crtc->primary_enabled) {
I915_WRITE(reg, 0);
@@ -2359,6 +2362,7 @@ static void i9xx_update_primary_plane(struct drm_crtc 
*crtc,
   (intel_crtc->config.pipe_src_w - 1));
I915_WRITE(DSPPOS(plane), 0);
}
+   dspcntr &= ~DISPPLANE_ROTATE_180;
 
switch (fb->pixel_format) {
case DRM_FORMAT_C8:
@@ -2398,8 +2402,6 @@ static void i9xx_update_primary_plane(struct drm_crtc 
*crtc,
if (IS_G4X(dev))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
 
-   I915_WRITE(reg, dspcntr);
-
linear_offset = y * fb->pitches[0] + x * (fb->bits_per_pixel / 8);
 
if (INTEL_INFO(dev)->gen >= 4) {
@@ -2412,6 +2414,21 @@ static void i9xx_update_primary_plane(struct drm_crtc 
*crtc,
intel_crtc->dspaddr_offset = linear_offset;
}
 
+   if (to_intel_plane(crtc->primary)->rotation == BIT(DRM_ROTATE_180)) {
+   dspcntr |= DISPPLANE_ROTATE_180;
+
+   x += (intel_crtc->config.pipe_src_w - 1);
+   y += (intel_crtc->config.pipe_src_h - 1);
+
+   /* Finding the last pixel of the last line of the display
+   data and adding to linear_offset*/
+   linear_offset += (intel_crtc->config.pipe_src_h - 1) *
+   fb->pitches[0] +
+   (intel_crtc->config.pipe_src_w - 1) * pixel_size;
+   }
+
+   I915_WRITE(reg, dspcntr);
+
DRM_DEBUG_KMS("Writing base %08lX %08lX %d %d %d\n",
  i915_gem_obj_ggtt_offset(obj), linear_offset, x, y,
  fb->pitches[0]);
@@ -2438,6 +2455,9 @@ static void ironlake_update_primary_plane(struct drm_crtc 
*crtc,
unsi

[Intel-gfx] [PATCH 1/2] drm/i915: Updating plane parameters for primary plane in setplane

[sonika . jindal]

From: Sonika Jindal 

Signed-off-by: Sonika Jindal 
---
 drivers/gpu/drm/i915/intel_display.c |   24 
 1 file changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e9b578e..1b0e403 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11528,6 +11528,21 @@ intel_primary_plane_setplane(struct drm_plane *plane, 
struct drm_crtc *crtc,
.x2 = intel_crtc->active ? intel_crtc->config.pipe_src_w : 0,
.y2 = intel_crtc->active ? intel_crtc->config.pipe_src_h : 0,
};
+   const struct {
+   int crtc_x, crtc_y;
+   unsigned int crtc_w, crtc_h;
+   uint32_t src_x, src_y, src_w, src_h;
+   } orig = {
+   .crtc_x = crtc_x,
+   .crtc_y = crtc_y,
+   .crtc_w = crtc_w,
+   .crtc_h = crtc_h,
+   .src_x = src_x,
+   .src_y = src_y,
+   .src_w = src_w,
+   .src_h = src_h,
+   };
+   struct intel_plane *intel_plane = to_intel_plane(plane);
bool visible;
int ret;
 
@@ -11604,6 +11619,15 @@ intel_primary_plane_setplane(struct drm_plane *plane, 
struct drm_crtc *crtc,
 
return 0;
}
+   intel_plane->crtc_x = orig.crtc_x;
+   intel_plane->crtc_y = orig.crtc_y;
+   intel_plane->crtc_w = orig.crtc_w;
+   intel_plane->crtc_h = orig.crtc_h;
+   intel_plane->src_x = orig.src_x;
+   intel_plane->src_y = orig.src_y;
+   intel_plane->src_w = orig.src_w;
+   intel_plane->src_h = orig.src_h;
+   intel_plane->obj = obj;
 
ret = intel_pipe_set_base(crtc, src.x1, src.y1, fb);
if (ret)
-- 
1.7.10.4

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

[Intel-gfx] [PATCH 0/2] 180 Primary plane rotation: calling setplane in set_property

[sonika . jindal]

From: Sonika Jindal 

As suggested by Daniel, now calling intel_primary_plane_setplane in
set_property.

Inside setplane, the intel_plane's member variables were not updated in the
structure. The first patch does that updation.

>From kms_rotation_crc igt, drmModeSetCrtc was called to set up crtc for primary
plane. So, intel_plane's members like x, y, w, h will not get updated and when
setplane is called from set_property, the values will be invalid in intel_plane
structure. So, updated the kms_plane_crc igt also to call igt_display_commit2
with COMMIT_UNIVERSAL.
For legacy planes, I am still not sure how will this setplane approach work.
Open for suggestions..

Dropping the r-b tag from the second patch.

Sonika Jindal (2):
  drm/i915: Updating intel_plane members for primary plane in setplane
  drm/i915: Add 180 degree primary plane rotation support

 drivers/gpu/drm/i915/i915_reg.h  |1 +
 drivers/gpu/drm/i915/intel_display.c |  140 +-
 drivers/gpu/drm/i915/intel_pm.c  |6 ++
 3 files changed, 143 insertions(+), 4 deletions(-)

-- 
1.7.10.4

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

Re: [Intel-gfx] [PATCH 3/4] drm/i915/dp: make backlight bl_power control power sequencer backlight

[Jani Nikula]

On Mon, 18 Aug 2014, Clint Taylor  wrote:
> On 08/12/2014 07:11 AM, Jani Nikula wrote:
>> This lets the userspace switch off the backlight using the backlight
>> class sysfs bl_power file. The switch is done using the power sequencer;
>> the backlight PWM, and everything else, remains enabled. The display
>> backlight won't draw power, but for maximum power savings the encoder
>> needs to be switched off.
>>
>> Signed-off-by: Jani Nikula 
>> ---
>>   drivers/gpu/drm/i915/intel_dp.c | 22 ++
>>   1 file changed, 22 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c 
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index d8baf60ff3fd..f6e3e9a906b0 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -1453,6 +1453,27 @@ void intel_edp_backlight_off(struct intel_dp 
>> *intel_dp)
>>  intel_panel_disable_backlight(intel_dp->attached_connector);
>>   }
>>
>> +/*
>> + * Hook for controlling the panel power control backlight through the 
>> bl_power
>> + * sysfs attribute. Take care to handle multiple calls.
>> + */
>> +static void intel_edp_backlight_power(struct intel_connector *connector,
>> +  bool enable)
>> +{
>> +struct intel_dp *intel_dp = intel_attached_dp(&connector->base);
>> +bool is_enabled = ironlake_get_pp_control(intel_dp) & EDP_BLC_ENABLE;
>> +
>> +if (is_enabled == enable)
>> +return;
>> +
>> +DRM_DEBUG_KMS("\n");
>> +
>> +if (enable)
>> +_intel_edp_backlight_on(intel_dp);
>> +else
>> +_intel_edp_backlight_off(intel_dp);
>
> Is there a good reason why we leave the PWM enabled? There is a small 
> power requirement to leave the PWM enabled.

Implementation simplicity. If you want to go for max power savings, you
are supposed to switch everything off using KMS, not just backlight.

BR,
Jani.


>
>> +}
>> +
>>   static void ironlake_edp_pll_on(struct intel_dp *intel_dp)
>>   {
>>  struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>> @@ -4579,6 +4600,7 @@ static bool intel_edp_init_connector(struct intel_dp 
>> *intel_dp,
>>  }
>>
>>  intel_panel_init(&intel_connector->panel, fixed_mode, downclock_mode);
>> +intel_connector->panel.backlight_power = intel_edp_backlight_power;
>>  intel_panel_setup_backlight(connector);
>>
>>  return true;
>>
>

-- 
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: fix suspend/resume for GENs w/o runtime PM support

[Sagar Arun Kamble]

Oh. I also missed this side effect of paths converging.

Reviewed-by: Sagar Kamble 

On Mon, 2014-08-18 at 13:20 +0300, Imre Deak wrote:
> Before sharing common parts between the system and runtime s/r
> handlers we WARNed if the runtime s/r handlers were called on GENs that
> didn't support RPM. But this WARN is not correct if the same handler is
> called from the system s/r path, since that can happen on any platform.
> This also broke system s/r on old platforms.
> 
> The issue was introduced in
> 
> commit 016970beb05da6285c2f3ed2bee1c676cb75972e
> Author: Sagar Kamble 
> Date:   Wed Aug 13 23:07:06 2014 +0530
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82751
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 117f5c1..f646f34 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -499,7 +499,8 @@ bool i915_semaphore_is_enabled(struct drm_device *dev)
>  }
>  
> 
> -static int intel_suspend_complete(struct drm_i915_private *dev_priv);
> +static int intel_suspend_complete(struct drm_i915_private *dev_priv,
> +   bool rpm_suspend);
>  static int intel_resume_prepare(struct drm_i915_private *dev_priv,
>   bool rpm_resume);
>  
> @@ -909,7 +910,7 @@ static int i915_pm_suspend_late(struct device *dev)
>   if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
>   return 0;
>  
> - ret = intel_suspend_complete(dev_priv);
> + ret = intel_suspend_complete(dev_priv, false);
>  
>   if (ret)
>   DRM_ERROR("Suspend complete failed: %d\n", ret);
> @@ -1410,7 +1411,7 @@ static int intel_runtime_suspend(struct device *device)
>   cancel_work_sync(&dev_priv->rps.work);
>   intel_runtime_pm_disable_interrupts(dev);
>  
> - ret = intel_suspend_complete(dev_priv);
> + ret = intel_suspend_complete(dev_priv, true);
>   if (ret) {
>   DRM_ERROR("Runtime suspend failed, disabling it (%d)\n", ret);
>   intel_runtime_pm_restore_interrupts(dev);
> @@ -1471,10 +1472,11 @@ static int intel_runtime_resume(struct device *device)
>   * This function implements common functionality of runtime and system
>   * suspend sequence.
>   */
> -static int intel_suspend_complete(struct drm_i915_private *dev_priv)
> +static int intel_suspend_complete(struct drm_i915_private *dev_priv,
> +   bool rpm_suspend)
>  {
>   struct drm_device *dev = dev_priv->dev;
> - int ret;
> + int ret = 0;
>  
>   if (IS_GEN6(dev)) {
>   ret = 0;
> @@ -1482,7 +1484,7 @@ static int intel_suspend_complete(struct 
> drm_i915_private *dev_priv)
>   ret = hsw_suspend_complete(dev_priv);
>   } else if (IS_VALLEYVIEW(dev)) {
>   ret = vlv_suspend_complete(dev_priv);
> - } else {
> + } else if (rpm_suspend) {
>   ret = -ENODEV;
>   WARN_ON(1);
>   }
> @@ -1499,7 +1501,7 @@ static int intel_resume_prepare(struct drm_i915_private 
> *dev_priv,
>   bool rpm_resume)
>  {
>   struct drm_device *dev = dev_priv->dev;
> - int ret;
> + int ret = 0;
>  
>   if (IS_GEN6(dev)) {
>   ret = snb_resume_prepare(dev_priv, rpm_resume);
> @@ -1507,7 +1509,7 @@ static int intel_resume_prepare(struct drm_i915_private 
> *dev_priv,
>   ret = hsw_resume_prepare(dev_priv, rpm_resume);
>   } else if (IS_VALLEYVIEW(dev)) {
>   ret = vlv_resume_prepare(dev_priv, rpm_resume);
> - } else {
> + } else if (rpm_resume) {
>   WARN_ON(1);
>   ret = -ENODEV;
>   }


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

[Intel-gfx] [PATCH] drm/i915: don't warn if backlight unexpectedly enabled

[Scot Doyle]

BIOS or firmware can modify hardware state during suspend/resume,
for example on the Toshiba CB35 or Lenovo T400, so log a debug message
instead of a warning if the backlight is unexpectedly enabled.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80930
Cc: Jani Nikula 
Signed-off-by: Scot Doyle 
---
 drivers/gpu/drm/i915/intel_panel.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index 59b028f..8e37444 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -801,7 +801,7 @@ static void pch_enable_backlight(struct intel_connector 
*connector)

cpu_ctl2 = I915_READ(BLC_PWM_CPU_CTL2);
if (cpu_ctl2 & BLM_PWM_ENABLE) {
-   WARN(1, "cpu backlight already enabled\n");
+   DRM_DEBUG_KMS("cpu backlight already enabled\n");
cpu_ctl2 &= ~BLM_PWM_ENABLE;
I915_WRITE(BLC_PWM_CPU_CTL2, cpu_ctl2);
}
@@ -845,7 +845,7 @@ static void i9xx_enable_backlight(struct intel_connector 
*connector)

ctl = I915_READ(BLC_PWM_CTL);
if (ctl & BACKLIGHT_DUTY_CYCLE_MASK_PNV) {
-   WARN(1, "backlight already enabled\n");
+   DRM_DEBUG_KMS("backlight already enabled\n");
I915_WRITE(BLC_PWM_CTL, 0);
}

@@ -876,7 +876,7 @@ static void i965_enable_backlight(struct intel_connector 
*connector)

ctl2 = I915_READ(BLC_PWM_CTL2);
if (ctl2 & BLM_PWM_ENABLE) {
-   WARN(1, "backlight already enabled\n");
+   DRM_DEBUG_KMS("backlight already enabled\n");
ctl2 &= ~BLM_PWM_ENABLE;
I915_WRITE(BLC_PWM_CTL2, ctl2);
}
@@ -910,7 +910,7 @@ static void vlv_enable_backlight(struct intel_connector 
*connector)

ctl2 = I915_READ(VLV_BLC_PWM_CTL2(pipe));
if (ctl2 & BLM_PWM_ENABLE) {
-   WARN(1, "backlight already enabled\n");
+   DRM_DEBUG_KMS("backlight already enabled\n");
ctl2 &= ~BLM_PWM_ENABLE;
I915_WRITE(VLV_BLC_PWM_CTL2(pipe), ctl2);
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] How to create PCH to support those existing driver

[Chen, Tiejun]

On 2014/8/18 17:58, Michael S. Tsirkin wrote:

On Mon, Aug 18, 2014 at 05:01:25PM +0800, Chen, Tiejun wrote:

On 2014/8/18 16:21, Michael S. Tsirkin wrote:

On Mon, Aug 18, 2014 at 11:06:29AM +0800, Chen, Tiejun wrote:

On 2014/8/17 18:32, Michael S. Tsirkin wrote:

On Fri, Aug 15, 2014 at 09:58:40AM +0800, Chen, Tiejun wrote:

Michael and Paolo,


Please re-post discussion on list. These off list ones are just
wasting time since they invariably have to be repeated on list again.


Okay, now just reissue this discussion to all related guys. And do you think
we need to discuss in public, qemu and xen mail list?


Absolutely.


Now -CC qemu, xen and intel-gfx.

If I'm missing someone important please tell me as well.






After I created that new machine specific to IGD passthrough, xenigd, now I
will step next to register the PCH.

IIRC, our complete solution should be as follows:

#1 create a new machine based on piix, xenigd

This is done with Michael help.

#2 register ISA bridge

1> Its still fixed at 1f.0.
2> ISA bridge's vendor_id/device_id should be emulated but then

subsystem_vendor_id = PCI_VENDOR_ID_XEN;
subsystem_device_id = ISA Bridge's real device id

This mean we need to change driver to walk with this way.
For example, in
case of Linux native driver,

intel_detect_pch()
{
...
if (pch->subsystem_vendor == PCI_VENDOR_ID_XEN)
id = pch->subsystem_device & INTEL_PCH_DEVICE_ID_MASK;

Then driver can get that real device id by 'subsystem_device', right?

This is fine now but how to support those existing drivers which are just


Here correct one point, we don't need to care about supporting the legacy
driver since the legacy driver still should work qemu-traditional. So we
just make sure the existing driver with this subsystem_id way can support
those existing and legacy platform.

Now this is clear to me.


dependent on checking real vendor_id/device_id directly,

if (pch->vendor == PCI_VENDOR_ID_INTEL) {
unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK

Maybe I'm missing something, please hint me.

Thanks
Tiejun


The subsystem id was just one idea.


But from that email thread, "RH / Intel Virtualization Engineering Meeting -
Minutes 7/10", I didn't see other idea we should prefer currently.


What was finally agreed for future drivers is that guests will get all
information they need from the video card, this ID hack was needed only
for very old legacy devices.
http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/42258
So this is for newer guests, they will work without need
for hacks, like any other device.



Actually we had a meeting to discuss our future solution, but seems you were
on vacation at that moment :)

In that meeting we had an agreement between us and some upstream guys.

We will have such a PCI capability structure in this PCI device to represent
all information in the future. This make sens to Intel as well.

Maybe Allen or Paolo known more details.

But obviously this a long-term solution, so currently we will work with this
subsystem_id way temporarily. And this way is accepted by those guys in the
meeting.



I don't see the point really. If you are modifying the driver,


Yes, we need to modify something in the driver.


why not modify it to its final form.


What's your final form?


Avoid poking at other devices besides the passed through card.
Get everything from BAR and other registers of the card.


Allen,

Could you reply this?




As I track that email thread, seems the follows is just a way you guys
achieve a better agreement.

"

why not set the subsys vid to the RH/Quamranet/Virtio VID, so it's
obvious for the use-match?


That's exactly the suggestion.  Though upstream they might be using the
XenSource id since the patches were for Xen.

Paolo
"
Or I'm missing something?

Thanks
Tiejun



I thought the point of this work is to make existing
linux/windows drivers work. Is it or isn't it?


Yes. We need change driver as I said previously like this,

>> 2> ISA bridge's vendor_id/device_id should be emulated but then
>>
>>subsystem_vendor_id = PCI_VENDOR_ID_XEN;
>>subsystem_device_id = ISA Bridge's real device id
>>
>> This mean we need to change driver to walk with this way.
>> For example, in
>> case of Linux native driver,
>>
>> intel_detect_pch()
>> {
>>...
>>if (pch->subsystem_vendor == PCI_VENDOR_ID_XEN)
>>id = pch->subsystem_device & INTEL_PCH_DEVICE_ID_MASK;

This is a minimal change to driver as we discussed.



Wrt changing drivers, change them to behave sanely, like all other
drivers, and avoid poking at the chipset.
http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/42258
Seems to suggest one way to do this.
Can what is suggested there work for existing devices?



Again, Allen,

Are you sure if this suggestion can work?

[Intel-gfx] [PATCH 4/4] drm/i915/bdw: Map unused PDPs to a scratch page

[Rodrigo Vivi]

From: Bob Beckett 

Create a scratch page for the two unused PDPs and set all the PTEs
for them to point to it.

This patch addresses a page fault, and subsequent hang in pipe
control flush. In these cases, the Main Graphic Arbiter Error
register [0x40A0] showed a TLB Page Fault error, and a high memory
address (higher than the size of our PPGTT) was reported in the
Fault TLB RD Data0 register (0x4B10).

PDP2 & PDP3 were not set because, in theory, they aren't required
for our PPGTT size, but they should be mapped to a scratch page
anyway.

v2: Rebase on latest nightly.

Signed-off-by: Michel Thierry  (v1)
Signed-off-by: Dave Gordon  (v2)
Signed-off-by: Oscar Mateo 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 79 +
 drivers/gpu/drm/i915/i915_gem_gtt.h |  2 +
 2 files changed, 65 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index b4b7cfd..7cb18e7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -361,6 +361,11 @@ static void gen8_ppgtt_free(const struct i915_hw_ppgtt 
*ppgtt)
kfree(ppgtt->gen8_pt_dma_addr[i]);
}
 
+   /* Unused PDPs are always assigned to scratch page */
+   for (i = ppgtt->num_pd_pages; i < GEN8_LEGACY_PDPS; i++)
+   kfree(ppgtt->gen8_pt_dma_addr[i]);
+   __free_page(ppgtt->scratch_page);
+
__free_pages(ppgtt->pd_pages, get_order(ppgtt->num_pd_pages << 
PAGE_SHIFT));
 }
 
@@ -385,6 +390,13 @@ static void gen8_ppgtt_unmap_pages(struct i915_hw_ppgtt 
*ppgtt)
   PCI_DMA_BIDIRECTIONAL);
}
}
+
+   /* Unused PDPs are always assigned to scratch page */
+   for (i = ppgtt->num_pd_pages; i < GEN8_LEGACY_PDPS; i++) {
+   if (ppgtt->pd_dma_addr[i])
+   pci_unmap_page(hwdev, ppgtt->pd_dma_addr[i],
+   PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
+   }
 }
 
 static void gen8_ppgtt_cleanup(struct i915_address_space *vm)
@@ -471,10 +483,21 @@ static int gen8_ppgtt_allocate_dma(struct i915_hw_ppgtt 
*ppgtt)
 static int gen8_ppgtt_allocate_page_directories(struct i915_hw_ppgtt *ppgtt,
const int max_pdp)
 {
-   ppgtt->pd_pages = alloc_pages(GFP_KERNEL, get_order(max_pdp << 
PAGE_SHIFT));
-   if (!ppgtt->pd_pages)
+   /* Scratch page for unmapped PDP's */
+   ppgtt->scratch_page = alloc_page(GFP_KERNEL);
+   if (!ppgtt->scratch_page)
return -ENOMEM;
 
+   /* Must allocate space for all 4 PDPs. HW has implemented cache which
+* pre-fetches entries; that pre-fetch can attempt access for entries
+* even if no resources are located in that range.
+*/
+   ppgtt->pd_pages = alloc_pages(GFP_KERNEL, GEN8_LEGACY_PDPS);
+   if (!ppgtt->pd_pages) {
+   __free_page(ppgtt->scratch_page);
+   return -ENOMEM;
+   }
+
ppgtt->num_pd_pages = 1 << get_order(max_pdp << PAGE_SHIFT);
BUG_ON(ppgtt->num_pd_pages > GEN8_LEGACY_PDPS);
 
@@ -492,6 +515,7 @@ static int gen8_ppgtt_alloc(struct i915_hw_ppgtt *ppgtt,
 
ret = gen8_ppgtt_allocate_page_tables(ppgtt, max_pdp);
if (ret) {
+   __free_page(ppgtt->scratch_page);
__free_pages(ppgtt->pd_pages, get_order(max_pdp << PAGE_SHIFT));
return ret;
}
@@ -526,18 +550,25 @@ static int gen8_ppgtt_setup_page_directories(struct 
i915_hw_ppgtt *ppgtt,
 
 static int gen8_ppgtt_setup_page_tables(struct i915_hw_ppgtt *ppgtt,
const int pd,
-   const int pt)
+   const int pt,
+   const int max_pdp)
 {
dma_addr_t pt_addr;
struct page *p;
int ret;
 
-   p = ppgtt->gen8_pt_pages[pd][pt];
-   pt_addr = pci_map_page(ppgtt->base.dev->pdev,
-  p, 0, PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
-   ret = pci_dma_mapping_error(ppgtt->base.dev->pdev, pt_addr);
-   if (ret)
-   return ret;
+   /* Unused PDPs need to have their ptes pointing to the
+* existing scratch page.
+*/
+   if (pd < max_pdp) {
+   p = ppgtt->gen8_pt_pages[pd][pt];
+   pt_addr = pci_map_page(ppgtt->base.dev->pdev,
+   p, 0, PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
+   ret = pci_dma_mapping_error(ppgtt->base.dev->pdev, pt_addr);
+   if (ret)
+   return ret;
+   } else
+   pt_addr = ppgtt->scratch_dma_addr;
 
ppgtt->gen8_pt_dma_addr[pd][pt] = pt_addr;
 
@@ -559,6 +590,7 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt, 
uint64_t size)
const int max_pdp = DIV_ROUND_UP(size, 1 << 3

[Intel-gfx] [PATCH 0/4] drm-intel-collector - update

[Rodrigo Vivi]

This is another drm-intel-collector updated notice:
http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector

Here goes the update list in order for better reviewers assignment:

Patch drm/i915: Bring UP Power Wells before disabling RC6. - Reviewer:
Patch drm/i915: Don't save/restore RS when not used - Reviewer:
Patch drm/i915: honour forced connector modes - Reviewer:
Patch drm/i915/bdw: Map unused PDPs to a scratch page - Reviewer:


Ben Widawsky (1):
  drm/i915: Don't save/restore RS when not used

Bob Beckett (1):
  drm/i915/bdw: Map unused PDPs to a scratch page

Chris Wilson (1):
  drm/i915: honour forced connector modes

Deepak S (1):
  drm/i915: Bring UP Power Wells before disabling RC6.

 drivers/gpu/drm/i915/i915_gem_context.c | 10 +++--
 drivers/gpu/drm/i915/i915_gem_gtt.c | 79 ++---
 drivers/gpu/drm/i915/i915_gem_gtt.h |  2 +
 drivers/gpu/drm/i915/intel_fbdev.c  | 33 +-
 drivers/gpu/drm/i915/intel_pm.c |  6 +++
 5 files changed, 89 insertions(+), 41 deletions(-)

-- 
1.9.3

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

[Intel-gfx] [PATCH 1/4] drm/i915: Bring UP Power Wells before disabling RC6.

[Rodrigo Vivi]

From: Deepak S 

We need do forcewake before Disabling RC6, This is what the BIOS
expects while going into suspend.

v2: updated commit message. (Daniel)

Reviewer: Paulo Zanoni 
Cc: Paulo Zanoni 
Signed-off-by: Deepak S 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_pm.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 41de760..9f96baa 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3527,8 +3527,14 @@ static void valleyview_disable_rps(struct drm_device 
*dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
 
+   /* we're doing forcewake before Disabling RC6,
+* This what the BIOS expects when going into suspend */
+   gen6_gt_force_wake_get(dev_priv, FORCEWAKE_ALL);
+
I915_WRITE(GEN6_RC_CONTROL, 0);
 
+   gen6_gt_force_wake_put(dev_priv, FORCEWAKE_ALL);
+
gen6_disable_rps_interrupts(dev);
 }
 
-- 
1.9.3

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

[Intel-gfx] [PATCH 3/4] drm/i915: honour forced connector modes

[Rodrigo Vivi]

From: Chris Wilson 

In the move over to use BIOS connector configs, we lost the ability to
force a specific set of connectors on or off.  Try to remedy that by
dropping back to the old behavior if we detect a hard coded connector
config that tries to enable a connector (disabling is easy!).

Based on earlier patches by Jesse Barnes.

v2: Remove Jesse's patch

Reported-by: Ville Syrjälä 
Signed-off-by: Chris Wilson 
Cc: Jesse Barnes 
Cc: Ville Syrjälä 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_fbdev.c | 33 -
 1 file changed, 12 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index f475414..5d879d18 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -331,24 +331,6 @@ static bool intel_fb_initial_config(struct drm_fb_helper 
*fb_helper,
int num_connectors_enabled = 0;
int num_connectors_detected = 0;
 
-   /*
-* If the user specified any force options, just bail here
-* and use that config.
-*/
-   for (i = 0; i < fb_helper->connector_count; i++) {
-   struct drm_fb_helper_connector *fb_conn;
-   struct drm_connector *connector;
-
-   fb_conn = fb_helper->connector_info[i];
-   connector = fb_conn->connector;
-
-   if (!enabled[i])
-   continue;
-
-   if (connector->force != DRM_FORCE_UNSPECIFIED)
-   return false;
-   }
-
save_enabled = kcalloc(dev->mode_config.num_connector, sizeof(bool),
   GFP_KERNEL);
if (!save_enabled)
@@ -374,8 +356,18 @@ static bool intel_fb_initial_config(struct drm_fb_helper 
*fb_helper,
continue;
}
 
+   if (connector->force == DRM_FORCE_OFF) {
+   DRM_DEBUG_KMS("connector %s is disabled by user, 
skipping\n",
+ connector->name);
+   enabled[i] = false;
+   continue;
+   }
+
encoder = connector->encoder;
if (!encoder || WARN_ON(!encoder->crtc)) {
+   if (connector->force > DRM_FORCE_OFF)
+   goto bail;
+
DRM_DEBUG_KMS("connector %s has no encoder or crtc, 
skipping\n",
  connector->name);
enabled[i] = false;
@@ -394,8 +386,7 @@ static bool intel_fb_initial_config(struct drm_fb_helper 
*fb_helper,
for (j = 0; j < fb_helper->connector_count; j++) {
if (crtcs[j] == new_crtc) {
DRM_DEBUG_KMS("fallback: cloned 
configuration\n");
-   fallback = true;
-   goto out;
+   goto bail;
}
}
 
@@ -466,8 +457,8 @@ static bool intel_fb_initial_config(struct drm_fb_helper 
*fb_helper,
fallback = true;
}
 
-out:
if (fallback) {
+bail:
DRM_DEBUG_KMS("Not using firmware configuration\n");
memcpy(enabled, save_enabled, dev->mode_config.num_connector);
kfree(save_enabled);
-- 
1.9.3

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

[Intel-gfx] [PATCH 2/4] drm/i915: Don't save/restore RS when not used

[Rodrigo Vivi]

From: Ben Widawsky 

v2: fix conflict on rebase.

Cc: Kenneth Graunke 
Signed-off-by: Ben Widawsky 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_gem_context.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 3b99390..15ec7e4 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -563,6 +563,7 @@ mi_set_context(struct intel_engine_cs *ring,
   struct intel_context *new_context,
   u32 hw_flags)
 {
+   u32 flags = hw_flags | MI_MM_SPACE_GTT;
int ret;
 
/* w/a: If Flush TLB Invalidation Mode is enabled, driver must do a TLB
@@ -576,6 +577,10 @@ mi_set_context(struct intel_engine_cs *ring,
return ret;
}
 
+   /* These flags are for resource streamer on HSW+ */
+   if (!IS_HASWELL(ring->dev) && INTEL_INFO(ring->dev)->gen < 8)
+   flags |= (MI_SAVE_EXT_STATE_EN | MI_RESTORE_EXT_STATE_EN);
+
ret = intel_ring_begin(ring, 6);
if (ret)
return ret;
@@ -589,10 +594,7 @@ mi_set_context(struct intel_engine_cs *ring,
intel_ring_emit(ring, MI_NOOP);
intel_ring_emit(ring, MI_SET_CONTEXT);
intel_ring_emit(ring, 
i915_gem_obj_ggtt_offset(new_context->legacy_hw_ctx.rcs_state) |
-   MI_MM_SPACE_GTT |
-   MI_SAVE_EXT_STATE_EN |
-   MI_RESTORE_EXT_STATE_EN |
-   hw_flags);
+   flags);
/*
 * w/a: MI_SET_CONTEXT must always be followed by MI_NOOP
 * WaMiSetContext_Hang:snb,ivb,vlv
-- 
1.9.3

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

Re: [Intel-gfx] [PATCH 02/14] drm/i915: Reorganize vlv eDP reboot notifier

[Clint Taylor]

On 08/18/2014 12:15 PM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

Move the vlv_power_sequencer_pipe() after the IS_VALLEYVIEW() check
and flatten the rest of the function.

Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/intel_dp.c | 24 
  1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 43dd226..a9ed2a6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -347,22 +347,22 @@ static int edp_notify_handler(struct notifier_block 
*this, unsigned long code,
struct drm_i915_private *dev_priv = dev->dev_private;
u32 pp_div;
u32 pp_ctrl_reg, pp_div_reg;
-   enum pipe pipe = vlv_power_sequencer_pipe(intel_dp);
+   enum pipe pipe;

-   if (!is_edp(intel_dp) || code != SYS_RESTART)
+   if (!IS_VALLEYVIEW(dev) || !is_edp(intel_dp) || code != SYS_RESTART)
return 0;

-   if (IS_VALLEYVIEW(dev)) {
-   pp_ctrl_reg = VLV_PIPE_PP_CONTROL(pipe);
-   pp_div_reg  = VLV_PIPE_PP_DIVISOR(pipe);
-   pp_div = I915_READ(pp_div_reg);
-   pp_div &= PP_REFERENCE_DIVIDER_MASK;
+   pipe = vlv_power_sequencer_pipe(intel_dp);

-   /* 0x1F write to PP_DIV_REG sets max cycle delay */
-   I915_WRITE(pp_div_reg, pp_div | 0x1F);
-   I915_WRITE(pp_ctrl_reg, PANEL_UNLOCK_REGS | PANEL_POWER_OFF);
-   msleep(intel_dp->panel_power_cycle_delay);
-   }
+   pp_ctrl_reg = VLV_PIPE_PP_CONTROL(pipe);
+   pp_div_reg  = VLV_PIPE_PP_DIVISOR(pipe);
+   pp_div = I915_READ(pp_div_reg);
+   pp_div &= PP_REFERENCE_DIVIDER_MASK;
+
+   /* 0x1F write to PP_DIV_REG sets max cycle delay */
+   I915_WRITE(pp_div_reg, pp_div | 0x1F);
+   I915_WRITE(pp_ctrl_reg, PANEL_UNLOCK_REGS | PANEL_POWER_OFF);
+   msleep(intel_dp->panel_power_cycle_delay);


Looks better..



return 0;
  }



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

[Intel-gfx] [PATCH] drm/edid: Reduce horizontal timings for pixel replicated modes

[clinton . a . taylor]

From: Clint Taylor 

Pixel replicated modes should be 720 horizontal pixel and pixel
replicated by the HW across the HDMI cable at 2X pixel clock. Current
horizontal resolution of 1440 does not allow pixel duplication to
occur and scaling artifacts occur on the TV. HDMI certification
7-26 currently fails for all pixel replicated modes. This change fizes
the HDMI certification issues with 480i/576i.

V2: Removed interlace flag from VICs 44 and 45. Will be submitted in
another patch. Various other formatting fixes.

Signed-off-by: Clint Taylor 
---
 drivers/gpu/drm/drm_edid.c|   96 ++---
 drivers/gpu/drm/i915/intel_hdmi.c |   10 +++-
 2 files changed, 57 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f905c63..412c525 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -632,27 +632,27 @@ static const struct drm_display_mode edid_cea_modes[] = {
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_INTERLACE),
  .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
-   /* 6 - 1440x480i@60Hz */
-   { DRM_MODE("1440x480i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
-  1602, 1716, 0, 480, 488, 494, 525, 0,
+   /* 6 - 720(1440)x480i@60Hz */
+   { DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+  801, 858, 0, 480, 488, 494, 525, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
  .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
-   /* 7 - 1440x480i@60Hz */
-   { DRM_MODE("1440x480i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
-  1602, 1716, 0, 480, 488, 494, 525, 0,
+   /* 7 - 720(1440)x480i@60Hz */
+   { DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+  801, 858, 0, 480, 488, 494, 525, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
  .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
-   /* 8 - 1440x240@60Hz */
-   { DRM_MODE("1440x240", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
-  1602, 1716, 0, 240, 244, 247, 262, 0,
+   /* 8 - 720(1440)x240@60Hz */
+   { DRM_MODE("720x240", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+  801, 858, 0, 240, 244, 247, 262, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_DBLCLK),
  .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
-   /* 9 - 1440x240@60Hz */
-   { DRM_MODE("1440x240", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
-  1602, 1716, 0, 240, 244, 247, 262, 0,
+   /* 9 - 720(1440)x240@60Hz */
+   { DRM_MODE("720x240", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+  801, 858, 0, 240, 244, 247, 262, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_DBLCLK),
  .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
@@ -714,27 +714,27 @@ static const struct drm_display_mode edid_cea_modes[] = {
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_INTERLACE),
  .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
-   /* 21 - 1440x576i@50Hz */
-   { DRM_MODE("1440x576i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
-  1590, 1728, 0, 576, 580, 586, 625, 0,
+   /* 21 - 720(1440)x576i@50Hz */
+   { DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500, 720, 732,
+  795, 864, 0, 576, 580, 586, 625, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
  .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
-   /* 22 - 1440x576i@50Hz */
-   { DRM_MODE("1440x576i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
-  1590, 1728, 0, 576, 580, 586, 625, 0,
+   /* 22 - 720(1440)x576i@50Hz */
+   { DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500, 720, 732,
+  795, 864, 0, 576, 580, 586, 625, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
  .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
-   /* 23 - 1440x288@50Hz */
-   { DRM_MODE("1440x288", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
-  1590, 1728, 0, 288, 290, 293, 312, 0,
+   /* 23 - 720(1440)x288@50Hz */
+   { DRM_MODE("720x288", DRM_MODE_TYPE_DRIVER, 13500, 720, 732,
+  795, 864, 0, 288, 290, 293, 312, 0,
   DRM_MODE_FL

[Intel-gfx] [PATCH] drm/i915/dp: Backlight PWM enable before BL Enable assert

[clinton . a . taylor]

From: Clint Taylor 

Backlight on delay uses PWM enable time to seperate PWM to
backlight enable assert. Previous time difference used timing
from VDD enable which occur several seconds before resulting
in PWM starting 5ms after backlight enable. Changes to backlight
 duty cycle take affect at the end of the current PWM cycle.
Measured time for the PWM cycle is 5ms. 5 additional ms must be
added to the backlight_on_delay to get correct VBT timing of
PWM to backlight enable assert.

V2: Rebase to Jani Nikula backlight power patch 1/4

Change-Id: I2982f9785d92e8d64c04ca25c8bd4c5d1dc8067c
Signed-off-by: Clint Taylor 
---
 drivers/gpu/drm/i915/intel_dp.c  | 6 --
 drivers/gpu/drm/i915/intel_drv.h | 1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d8baf60..aed923b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1141,7 +1141,7 @@ static void wait_panel_power_cycle(struct intel_dp 
*intel_dp)
 
 static void wait_backlight_on(struct intel_dp *intel_dp)
 {
-   wait_remaining_ms_from_jiffies(intel_dp->last_power_on,
+   wait_remaining_ms_from_jiffies(intel_dp->last_backlight_on,
   intel_dp->backlight_on_delay);
 }
 
@@ -1418,6 +1418,7 @@ void intel_edp_backlight_on(struct intel_dp *intel_dp)
DRM_DEBUG_KMS("\n");
 
intel_panel_enable_backlight(intel_dp->attached_connector);
+   intel_dp->last_backlight_on = jiffies;
_intel_edp_backlight_on(intel_dp);
 }
 
@@ -4256,9 +4257,10 @@ intel_dp_init_panel_power_sequencer(struct drm_device 
*dev,
assign_final(t11_t12);
 #undef assign_final
 
+#define PWM_CYCLE_DELAY 5
 #define get_delay(field)   (DIV_ROUND_UP(final.field, 10))
intel_dp->panel_power_up_delay = get_delay(t1_t3);
-   intel_dp->backlight_on_delay = get_delay(t8);
+   intel_dp->backlight_on_delay = get_delay(t8) + PWM_CYCLE_DELAY;
intel_dp->backlight_off_delay = get_delay(t9);
intel_dp->panel_power_down_delay = get_delay(t10);
intel_dp->panel_power_cycle_delay = get_delay(t11_t12);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3abc915..ad6fcc1 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -556,6 +556,7 @@ struct intel_dp {
bool want_panel_vdd;
unsigned long last_power_cycle;
unsigned long last_power_on;
+   unsigned long last_backlight_on;
unsigned long last_backlight_off;
 
struct notifier_block edp_notifier;
-- 
1.8.3.2

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

[Intel-gfx] [PATCH 10/14] drm/i915: Track which port is using which pipe's power sequencer

[ville . syrjala]

From: Ville Syrjälä 

VLV/CHV have a per-pipe panel power sequencer which locks onto the
port once used. We need to keep track wich power sequencers are
locked to which ports.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c  | 185 ++-
 drivers/gpu/drm/i915/intel_drv.h |   6 ++
 2 files changed, 168 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 556e4de..4614e6e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -294,28 +294,99 @@ static enum pipe
 vlv_power_sequencer_pipe(struct intel_dp *intel_dp)
 {
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
-   struct drm_crtc *crtc = intel_dig_port->base.base.crtc;
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   enum port port = intel_dig_port->port;
-   enum pipe pipe;
+   struct intel_encoder *encoder;
+   unsigned int pipes = (1 << PIPE_A) | (1 << PIPE_B);
+   struct edp_power_seq power_seq;
 
lockdep_assert_held(&dev_priv->pps_mutex);
 
-   /* modeset should have pipe */
-   if (crtc)
-   return to_intel_crtc(crtc)->pipe;
+   if (intel_dp->pps_pipe != INVALID_PIPE)
+   return intel_dp->pps_pipe;
+
+   /*
+* We don't have power sequencer currently.
+* Pick one that's not used by other ports.
+*/
+   list_for_each_entry(encoder, &dev->mode_config.encoder_list, base.head) 
{
+   struct intel_dp *tmp;
+
+   if (encoder->type != INTEL_OUTPUT_EDP)
+   continue;
+
+   tmp = enc_to_intel_dp(&encoder->base);
+
+   if (tmp->pps_pipe != INVALID_PIPE)
+   pipes &= ~(1 << tmp->pps_pipe);
+   }
+
+   /*
+* Didn't find one. This should not happen since there
+* are two power sequencers and up to two eDP ports.
+*/
+   if (WARN_ON(pipes == 0))
+   return PIPE_A;
+
+   intel_dp->pps_pipe = ffs(pipes) - 1;
+
+   DRM_DEBUG_KMS("picked pipe %c power sequencer for port %c\n",
+ pipe_name(intel_dp->pps_pipe), 
port_name(intel_dig_port->port));
+
+   /* init power sequencer on this pipe and port */
+   intel_dp_init_panel_power_sequencer(dev, intel_dp, &power_seq);
+   intel_dp_init_panel_power_sequencer_registers(dev, intel_dp,
+ &power_seq);
+
+   return intel_dp->pps_pipe;
+}
+
+static enum pipe
+vlv_initial_power_sequencer_pipe(struct drm_i915_private *dev_priv,
+enum port port)
+{
+   enum pipe pipe;
 
-   /* init time, try to find a pipe with this port selected */
for (pipe = PIPE_A; pipe <= PIPE_B; pipe++) {
u32 port_sel = I915_READ(VLV_PIPE_PP_ON_DELAYS(pipe)) &
PANEL_PORT_SELECT_MASK;
-   if (port_sel == PANEL_PORT_SELECT_VLV(port))
-   return pipe;
+
+   if (port_sel != PANEL_PORT_SELECT_VLV(port))
+   continue;
+
+   return pipe;
+   }
+
+   return INVALID_PIPE;
+}
+
+static void
+vlv_initial_power_sequencer_setup(struct intel_dp *intel_dp)
+{
+   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+   struct drm_device *dev = intel_dig_port->base.base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct edp_power_seq power_seq;
+   enum port port = intel_dig_port->port;
+
+   lockdep_assert_held(&dev_priv->pps_mutex);
+
+   /* try to find a pipe with this port selected */
+   intel_dp->pps_pipe = vlv_initial_power_sequencer_pipe(dev_priv, port);
+
+   /* didn't find one? just let vlv_power_sequencer_pipe() pick one when 
needed */
+   if (intel_dp->pps_pipe == INVALID_PIPE) {
+   DRM_DEBUG_KMS("no initial power sequencer for port %c\n",
+ port_name(port));
+   return;
}
 
-   /* shrug */
-   return PIPE_A;
+   DRM_DEBUG_KMS("initial power sequencer for port %c: pipe %c\n",
+ port_name(port), pipe_name(intel_dp->pps_pipe));
+
+   intel_dp_init_panel_power_sequencer(dev, intel_dp, &power_seq);
+   intel_dp_init_panel_power_sequencer_registers(dev, intel_dp,
+ &power_seq);
 }
 
 static u32 _pp_ctrl_reg(struct intel_dp *intel_dp)
@@ -2209,6 +2280,76 @@ static void g4x_pre_enable_dp(struct intel_encoder 
*encoder)
}
 }
 
+static void vlv_steal_power_sequencer(struct drm_device *dev,
+ enum pipe pipe)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_encoder *encoder;
+
+   lockdep_assert_held(&dev_priv->p

[Intel-gfx] [PATCH 14/14] drm/i915: Move DP port disable to post_disable for pch platforms

[ville . syrjala]

From: Ville Syrjälä 

We need to turn the DP port off after the pipe, otherwise the pipe won't
turn off properly on certain pch platforms at least (happens on my ILK for
example).  This also matches the BSpec modeset sequence better. We still
don't match the spec exactly though (eg. audio disable should happen
much earlier), but at last this eliminates the nasty
wait_for_pipe_off() timeouts.

We already did the port disable after the pipe for VLV/CHV and for CPU
eDP.

For g4x leave the port disable where it is since that matches the
modeset sequence in the documentation and I don't have a suitable
machine to test if the other order would work.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 12925be..915d4ec 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2194,7 +2194,6 @@ void intel_edp_psr_init(struct drm_device *dev)
 static void intel_disable_dp(struct intel_encoder *encoder)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
-   enum port port = dp_to_dig_port(intel_dp)->port;
struct drm_device *dev = encoder->base.dev;
 
/* Make sure the panel is off before trying to change the mode. But also
@@ -2204,21 +2203,19 @@ static void intel_disable_dp(struct intel_encoder 
*encoder)
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
intel_edp_panel_off(intel_dp);
 
-   /* cpu edp my only be disable _after_ the cpu pipe/plane is disabled. */
-   if (!(port == PORT_A || IS_VALLEYVIEW(dev)))
+   /* disable the port before the pipe on g4x */
+   if (INTEL_INFO(dev)->gen < 5)
intel_dp_link_down(intel_dp);
 }
 
-static void g4x_post_disable_dp(struct intel_encoder *encoder)
+static void ilk_post_disable_dp(struct intel_encoder *encoder)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
enum port port = dp_to_dig_port(intel_dp)->port;
 
-   if (port != PORT_A)
-   return;
-
intel_dp_link_down(intel_dp);
-   ironlake_edp_pll_off(intel_dp);
+   if (port == PORT_A)
+   ironlake_edp_pll_off(intel_dp);
 }
 
 static void vlv_post_disable_dp(struct intel_encoder *encoder)
@@ -5044,7 +5041,8 @@ intel_dp_init(struct drm_device *dev, int output_reg, 
enum port port)
} else {
intel_encoder->pre_enable = g4x_pre_enable_dp;
intel_encoder->enable = g4x_enable_dp;
-   intel_encoder->post_disable = g4x_post_disable_dp;
+   if (INTEL_INFO(dev)->gen >= 5)
+   intel_encoder->post_disable = ilk_post_disable_dp;
}
 
intel_dig_port->port = port;
-- 
1.8.5.5

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

[Intel-gfx] [PATCH 09/14] drm/i915: Fix edp vdd locking

[ville . syrjala]

From: Ville Syrjälä 

Introduce a new mutex (pps_mutex) to protect the power sequencer
state. For now this state includes want_panel_vdd as well as the
power sequencer registers.

We need a single mutex (as opposed to per port) because later on we
will need to deal with VLV/CHV which have multiple power sequencer
which can be reassigned to different ports.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h  |  3 ++
 drivers/gpu/drm/i915/intel_display.c |  2 +
 drivers/gpu/drm/i915/intel_dp.c  | 97 +++-
 3 files changed, 90 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4754328..8684898 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1501,6 +1501,9 @@ struct drm_i915_private {
/* LVDS info */
bool no_aux_handshake;
 
+   /* protects panel power sequencer state */
+   struct mutex pps_mutex;
+
struct drm_i915_fence_reg fence_regs[I915_MAX_NUM_FENCES]; /* assume 
965 */
int fence_reg_start; /* 4 if userland hasn't ioctl'd us yet */
int num_fence_regs; /* 8 on pre-965, 16 otherwise */
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3f8e037..04c0e5d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12437,6 +12437,8 @@ static void intel_init_display(struct drm_device *dev)
}
 
intel_panel_init_backlight_funcs(dev);
+
+   mutex_init(&dev_priv->pps_mutex);
 }
 
 /*
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7ae9a9a..556e4de 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -300,6 +300,8 @@ vlv_power_sequencer_pipe(struct intel_dp *intel_dp)
enum port port = intel_dig_port->port;
enum pipe pipe;
 
+   lockdep_assert_held(&dev_priv->pps_mutex);
+
/* modeset should have pipe */
if (crtc)
return to_intel_crtc(crtc)->pipe;
@@ -352,6 +354,8 @@ static int edp_notify_handler(struct notifier_block *this, 
unsigned long code,
if (!IS_VALLEYVIEW(dev) || !is_edp(intel_dp) || code != SYS_RESTART)
return 0;
 
+   mutex_lock(&dev_priv->pps_mutex);
+
pipe = vlv_power_sequencer_pipe(intel_dp);
 
pp_ctrl_reg = VLV_PIPE_PP_CONTROL(pipe);
@@ -364,6 +368,8 @@ static int edp_notify_handler(struct notifier_block *this, 
unsigned long code,
I915_WRITE(pp_ctrl_reg, PANEL_UNLOCK_REGS | PANEL_POWER_OFF);
msleep(intel_dp->panel_power_cycle_delay);
 
+   mutex_unlock(&dev_priv->pps_mutex);
+
return 0;
 }
 
@@ -372,6 +378,8 @@ static bool edp_have_panel_power(struct intel_dp *intel_dp)
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct drm_i915_private *dev_priv = dev->dev_private;
 
+   lockdep_assert_held(&dev_priv->pps_mutex);
+
return (I915_READ(_pp_stat_reg(intel_dp)) & PP_ON) != 0;
 }
 
@@ -383,6 +391,8 @@ static bool edp_have_panel_vdd(struct intel_dp *intel_dp)
struct intel_encoder *intel_encoder = &intel_dig_port->base;
enum intel_display_power_domain power_domain;
 
+   lockdep_assert_held(&dev_priv->pps_mutex);
+
power_domain = intel_display_port_power_domain(intel_encoder);
return intel_display_power_enabled(dev_priv, power_domain) &&
   (I915_READ(_pp_ctrl_reg(intel_dp)) & EDP_FORCE_VDD) != 0;
@@ -533,6 +543,8 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
bool has_aux_irq = HAS_AUX_IRQ(dev);
bool vdd;
 
+   mutex_lock(&dev_priv->pps_mutex);
+
/*
 * We will be called with VDD already enabled for dpcd/edid/oui reads.
 * In such cases we want to leave VDD enabled and it's up to upper 
layers
@@ -648,6 +660,8 @@ out:
if (vdd)
edp_panel_vdd_off(intel_dp, false);
 
+   mutex_unlock(&dev_priv->pps_mutex);
+
return ret;
 }
 
@@ -1102,6 +1116,8 @@ static void wait_panel_status(struct intel_dp *intel_dp,
struct drm_i915_private *dev_priv = dev->dev_private;
u32 pp_stat_reg, pp_ctrl_reg;
 
+   lockdep_assert_held(&dev_priv->pps_mutex);
+
pp_stat_reg = _pp_stat_reg(intel_dp);
pp_ctrl_reg = _pp_ctrl_reg(intel_dp);
 
@@ -1165,6 +1181,8 @@ static  u32 ironlake_get_pp_control(struct intel_dp 
*intel_dp)
struct drm_i915_private *dev_priv = dev->dev_private;
u32 control;
 
+   lockdep_assert_held(&dev_priv->pps_mutex);
+
control = I915_READ(_pp_ctrl_reg(intel_dp));
control &= ~PANEL_UNLOCK_MASK;
control |= PANEL_UNLOCK_REGS;
@@ -1182,6 +1200,8 @@ static bool edp_panel_vdd_on(struct intel_dp *intel_dp)
u32 pp_stat_reg, pp_ctrl_reg;
bool need_to_disable = !intel_dp->want_panel_vdd;
 
+   lockdep_assert_held(&dev_priv->pps_mutex);
+
if (!is_edp(intel_dp))

[Intel-gfx] [PATCH 03/14] drm/i915: Use intel_edp_panel_vdd_on() in intel_dp_probe_mst()

[ville . syrjala]

From: Ville Syrjälä 

We want to use the higher level vdd on func here. Not a big deal
yet (we'd just get the warn when things go awry) but when the
locking gets fixed this becomes more important.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a9ed2a6..28d0183 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3419,7 +3419,7 @@ intel_dp_probe_mst(struct intel_dp *intel_dp)
if (intel_dp->dpcd[DP_DPCD_REV] < 0x12)
return false;
 
-   _edp_panel_vdd_on(intel_dp);
+   intel_edp_panel_vdd_on(intel_dp);
if (intel_dp_dpcd_read_wake(&intel_dp->aux, DP_MSTM_CAP, buf, 1)) {
if (buf[0] & DP_MST_CAP) {
DRM_DEBUG_KMS("Sink is MST capable\n");
-- 
1.8.5.5

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

[Intel-gfx] [PATCH 12/14] drm/i915: Turn on panel power before doing aux transfers

[ville . syrjala]

From: Ville Syrjälä 

On VLV/CHV the panel power sequencer may need to be "kicked" a bit to
lock onto the new port, and that needs to happen before any aux
transfers are attempted if we want the aux transfers to actaully
succeed. So turn on panel power (part of the "kick") before aux
transfers (DPMS_ON + link training).

This also matches the documented modeset sequence better for pch
platforms. The documentation doesn't explicitly state anything about the
DPMS or link training DPCD writes, but the panel power on step is
always listed before link training is mentioned.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4952783..28bc652 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2275,10 +2275,10 @@ static void intel_enable_dp(struct intel_encoder 
*encoder)
return;
 
intel_edp_panel_vdd_on(intel_dp);
-   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
-   intel_dp_start_link_train(intel_dp);
intel_edp_panel_on(intel_dp);
intel_edp_panel_vdd_off(intel_dp, true);
+   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
+   intel_dp_start_link_train(intel_dp);
intel_dp_complete_link_train(intel_dp);
intel_dp_stop_link_train(intel_dp);
 }
-- 
1.8.5.5

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

[Intel-gfx] [PATCH 13/14] drm/i915: Enable DP port earlier

[ville . syrjala]

From: Ville Syrjälä 

Bspec says we should enable the DP port before enabling panel power,
and that the port must be enabled with training pattern 1. Do so.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 172 +++-
 1 file changed, 100 insertions(+), 72 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 28bc652..12925be 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2264,6 +2264,104 @@ static void chv_post_disable_dp(struct intel_encoder 
*encoder)
mutex_unlock(&dev_priv->dpio_lock);
 }
 
+static void
+_intel_dp_set_link_train(struct intel_dp *intel_dp,
+uint32_t *DP,
+uint8_t dp_train_pat)
+{
+   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+   struct drm_device *dev = intel_dig_port->base.base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   enum port port = intel_dig_port->port;
+
+   if (HAS_DDI(dev)) {
+   uint32_t temp = I915_READ(DP_TP_CTL(port));
+
+   if (dp_train_pat & DP_LINK_SCRAMBLING_DISABLE)
+   temp |= DP_TP_CTL_SCRAMBLE_DISABLE;
+   else
+   temp &= ~DP_TP_CTL_SCRAMBLE_DISABLE;
+
+   temp &= ~DP_TP_CTL_LINK_TRAIN_MASK;
+   switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) {
+   case DP_TRAINING_PATTERN_DISABLE:
+   temp |= DP_TP_CTL_LINK_TRAIN_NORMAL;
+
+   break;
+   case DP_TRAINING_PATTERN_1:
+   temp |= DP_TP_CTL_LINK_TRAIN_PAT1;
+   break;
+   case DP_TRAINING_PATTERN_2:
+   temp |= DP_TP_CTL_LINK_TRAIN_PAT2;
+   break;
+   case DP_TRAINING_PATTERN_3:
+   temp |= DP_TP_CTL_LINK_TRAIN_PAT3;
+   break;
+   }
+   I915_WRITE(DP_TP_CTL(port), temp);
+
+   } else if (HAS_PCH_CPT(dev) && (IS_GEN7(dev) || port != PORT_A)) {
+   *DP &= ~DP_LINK_TRAIN_MASK_CPT;
+
+   switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) {
+   case DP_TRAINING_PATTERN_DISABLE:
+   *DP |= DP_LINK_TRAIN_OFF_CPT;
+   break;
+   case DP_TRAINING_PATTERN_1:
+   *DP |= DP_LINK_TRAIN_PAT_1_CPT;
+   break;
+   case DP_TRAINING_PATTERN_2:
+   *DP |= DP_LINK_TRAIN_PAT_2_CPT;
+   break;
+   case DP_TRAINING_PATTERN_3:
+   DRM_ERROR("DP training pattern 3 not supported\n");
+   *DP |= DP_LINK_TRAIN_PAT_2_CPT;
+   break;
+   }
+
+   } else {
+   if (IS_CHERRYVIEW(dev))
+   *DP &= ~DP_LINK_TRAIN_MASK_CHV;
+   else
+   *DP &= ~DP_LINK_TRAIN_MASK;
+
+   switch (dp_train_pat & DP_TRAINING_PATTERN_MASK) {
+   case DP_TRAINING_PATTERN_DISABLE:
+   *DP |= DP_LINK_TRAIN_OFF;
+   break;
+   case DP_TRAINING_PATTERN_1:
+   *DP |= DP_LINK_TRAIN_PAT_1;
+   break;
+   case DP_TRAINING_PATTERN_2:
+   *DP |= DP_LINK_TRAIN_PAT_2;
+   break;
+   case DP_TRAINING_PATTERN_3:
+   if (IS_CHERRYVIEW(dev)) {
+   *DP |= DP_LINK_TRAIN_PAT_3_CHV;
+   } else {
+   DRM_ERROR("DP training pattern 3 not 
supported\n");
+   *DP |= DP_LINK_TRAIN_PAT_2;
+   }
+   break;
+   }
+   }
+}
+
+static void intel_dp_enable_port(struct intel_dp *intel_dp)
+{
+   struct drm_device *dev = intel_dp_to_dev(intel_dp);
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   intel_dp->DP |= DP_PORT_EN;
+
+   /* enable with pattern 1 (as per spec) */
+   _intel_dp_set_link_train(intel_dp, &intel_dp->DP,
+DP_TRAINING_PATTERN_1);
+
+   I915_WRITE(intel_dp->output_reg, intel_dp->DP);
+   POSTING_READ(intel_dp->output_reg);
+}
+
 static void intel_enable_dp(struct intel_encoder *encoder)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
@@ -2274,6 +2372,7 @@ static void intel_enable_dp(struct intel_encoder *encoder)
if (WARN_ON(dp_reg & DP_PORT_EN))
return;
 
+   intel_dp_enable_port(intel_dp);
intel_edp_panel_vdd_on(intel_dp);
intel_edp_panel_on(intel_dp);
intel_edp_panel_vdd_off(intel_dp, true);
@@ -3174,81 +3273,10 @@ intel_dp_set_link_train(struct intel_dp *intel_dp,
  

[Intel-gfx] [PATCH 11/14] drm/i915: Be more careful when picking the initial power sequencer pipe

[ville . syrjala]

From: Ville Syrjälä 

Try to make sure we find the power sequencer that the BIOS used
by first looking for one which has the panel power enabled, then
fall back to one with VDD force bit enabled, and finally look at
just the port select bits. This should make us pick the correct
power sequencer when the BIOS has already enabled the panel.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 36 ++--
 1 file changed, 34 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4614e6e..4952783 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -341,9 +341,31 @@ vlv_power_sequencer_pipe(struct intel_dp *intel_dp)
return intel_dp->pps_pipe;
 }
 
+typedef bool (*vlv_pipe_check)(struct drm_i915_private *dev_priv,
+  enum pipe pipe);
+
+static bool vlv_pipe_has_pp_on(struct drm_i915_private *dev_priv,
+  enum pipe pipe)
+{
+   return I915_READ(VLV_PIPE_PP_STATUS(pipe)) & PP_ON;
+}
+
+static bool vlv_pipe_has_vdd_on(struct drm_i915_private *dev_priv,
+   enum pipe pipe)
+{
+   return I915_READ(VLV_PIPE_PP_CONTROL(pipe)) & EDP_FORCE_VDD;
+}
+
+static bool vlv_pipe_any(struct drm_i915_private *dev_priv,
+enum pipe pipe)
+{
+   return true;
+}
+
 static enum pipe
 vlv_initial_power_sequencer_pipe(struct drm_i915_private *dev_priv,
-enum port port)
+enum port port,
+vlv_pipe_check pipe_check)
 {
enum pipe pipe;
 
@@ -354,6 +376,9 @@ vlv_initial_power_sequencer_pipe(struct drm_i915_private 
*dev_priv,
if (port_sel != PANEL_PORT_SELECT_VLV(port))
continue;
 
+   if (!pipe_check(dev_priv, pipe))
+   continue;
+
return pipe;
}
 
@@ -372,7 +397,14 @@ vlv_initial_power_sequencer_setup(struct intel_dp 
*intel_dp)
lockdep_assert_held(&dev_priv->pps_mutex);
 
/* try to find a pipe with this port selected */
-   intel_dp->pps_pipe = vlv_initial_power_sequencer_pipe(dev_priv, port);
+   /* first pick one where the panel is on */
+   intel_dp->pps_pipe = vlv_initial_power_sequencer_pipe(dev_priv, port, 
vlv_pipe_has_pp_on);
+   /* didn't find one? pick one where vdd is on */
+   if (intel_dp->pps_pipe == INVALID_PIPE)
+   intel_dp->pps_pipe = vlv_initial_power_sequencer_pipe(dev_priv, 
port, vlv_pipe_has_vdd_on);
+   /* didn't find one? pick one with just the correct port */
+   if (intel_dp->pps_pipe == INVALID_PIPE)
+   intel_dp->pps_pipe = vlv_initial_power_sequencer_pipe(dev_priv, 
port, vlv_pipe_any);
 
/* didn't find one? just let vlv_power_sequencer_pipe() pick one when 
needed */
if (intel_dp->pps_pipe == INVALID_PIPE) {
-- 
1.8.5.5

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

[Intel-gfx] [PATCH 06/14] drm/i915: Replace big nested if block with early return

[ville . syrjala]

From: Ville Syrjälä 

Looks nicer.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 19a818f..e6b4d4d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1232,38 +1232,38 @@ static void edp_panel_vdd_off_sync(struct intel_dp 
*intel_dp)
 {
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_digital_port *intel_dig_port =
+   dp_to_dig_port(intel_dp);
+   struct intel_encoder *intel_encoder = &intel_dig_port->base;
+   enum intel_display_power_domain power_domain;
u32 pp;
u32 pp_stat_reg, pp_ctrl_reg;
 
WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
 
-   if (!intel_dp->want_panel_vdd && edp_have_panel_vdd(intel_dp)) {
-   struct intel_digital_port *intel_dig_port =
-   dp_to_dig_port(intel_dp);
-   struct intel_encoder *intel_encoder = &intel_dig_port->base;
-   enum intel_display_power_domain power_domain;
+   if (intel_dp->want_panel_vdd || !edp_have_panel_vdd(intel_dp))
+   return;
 
-   DRM_DEBUG_KMS("Turning eDP VDD off\n");
+   DRM_DEBUG_KMS("Turning eDP VDD off\n");
 
-   pp = ironlake_get_pp_control(intel_dp);
-   pp &= ~EDP_FORCE_VDD;
+   pp = ironlake_get_pp_control(intel_dp);
+   pp &= ~EDP_FORCE_VDD;
 
-   pp_ctrl_reg = _pp_ctrl_reg(intel_dp);
-   pp_stat_reg = _pp_stat_reg(intel_dp);
+   pp_ctrl_reg = _pp_ctrl_reg(intel_dp);
+   pp_stat_reg = _pp_stat_reg(intel_dp);
 
-   I915_WRITE(pp_ctrl_reg, pp);
-   POSTING_READ(pp_ctrl_reg);
+   I915_WRITE(pp_ctrl_reg, pp);
+   POSTING_READ(pp_ctrl_reg);
 
-   /* Make sure sequencer is idle before allowing subsequent 
activity */
-   DRM_DEBUG_KMS("PP_STATUS: 0x%08x PP_CONTROL: 0x%08x\n",
-   I915_READ(pp_stat_reg), I915_READ(pp_ctrl_reg));
+   /* Make sure sequencer is idle before allowing subsequent activity */
+   DRM_DEBUG_KMS("PP_STATUS: 0x%08x PP_CONTROL: 0x%08x\n",
+   I915_READ(pp_stat_reg), I915_READ(pp_ctrl_reg));
 
-   if ((pp & POWER_TARGET_ON) == 0)
-   intel_dp->last_power_cycle = jiffies;
+   if ((pp & POWER_TARGET_ON) == 0)
+   intel_dp->last_power_cycle = jiffies;
 
-   power_domain = intel_display_port_power_domain(intel_encoder);
-   intel_display_power_put(dev_priv, power_domain);
-   }
+   power_domain = intel_display_port_power_domain(intel_encoder);
+   intel_display_power_put(dev_priv, power_domain);
 }
 
 static void edp_panel_vdd_work(struct work_struct *__work)
-- 
1.8.5.5

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

[Intel-gfx] [PATCH 08/14] drm/i915: Flatten intel_edp_panel_vdd_on()

[ville . syrjala]

From: Ville Syrjälä 

Less pointless indentation is always nice. There will be a bit more
code in this function once the power sequencer locking is fixed.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0fb510c..7ae9a9a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1221,11 +1221,14 @@ static bool edp_panel_vdd_on(struct intel_dp *intel_dp)
 
 void intel_edp_panel_vdd_on(struct intel_dp *intel_dp)
 {
-   if (is_edp(intel_dp)) {
-   bool vdd = edp_panel_vdd_on(intel_dp);
+   bool vdd;
 
-   WARN(!vdd, "eDP VDD already requested on\n");
-   }
+   if (!is_edp(intel_dp))
+   return;
+
+   vdd = edp_panel_vdd_on(intel_dp);
+
+   WARN(!vdd, "eDP VDD already requested on\n");
 }
 
 static void edp_panel_vdd_off_sync(struct intel_dp *intel_dp)
-- 
1.8.5.5

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

[Intel-gfx] [PATCH 07/14] drm/i915: Warn about want_panel_vdd in edp_panel_vdd_off_sync()

[ville . syrjala]

From: Ville Syrjälä 

If we force vdd off warn if someone is still using it. With this
change the delayed vdd off work needs to check want_panel_vdd
itself to make sure it doesn't try to turn vdd off when someone
is using it.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e6b4d4d..0fb510c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1241,7 +1241,9 @@ static void edp_panel_vdd_off_sync(struct intel_dp 
*intel_dp)
 
WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
 
-   if (intel_dp->want_panel_vdd || !edp_have_panel_vdd(intel_dp))
+   WARN_ON(intel_dp->want_panel_vdd);
+
+   if (!edp_have_panel_vdd(intel_dp))
return;
 
DRM_DEBUG_KMS("Turning eDP VDD off\n");
@@ -1273,7 +1275,8 @@ static void edp_panel_vdd_work(struct work_struct *__work)
struct drm_device *dev = intel_dp_to_dev(intel_dp);
 
drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
-   edp_panel_vdd_off_sync(intel_dp);
+   if (!intel_dp->want_panel_vdd)
+   edp_panel_vdd_off_sync(intel_dp);
drm_modeset_unlock(&dev->mode_config.connection_mutex);
 }
 
-- 
1.8.5.5

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

[Intel-gfx] [PATCH 05/14] drm/i915: Add a note explaining vdd on/off handling in intel_dp_aux_ch()

[ville . syrjala]

From: Ville Syrjälä 

Add a comment to explain why we care about the current want_panel_vdd
state in intel_dp_aux_ch().

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 30943a5..19a818f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -533,6 +533,12 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
bool has_aux_irq = HAS_AUX_IRQ(dev);
bool vdd;
 
+   /*
+* We will be called with VDD already enabled for dpcd/edid/oui reads.
+* In such cases we want to leave VDD enabled and it's up to upper 
layers
+* to turn it off. But for eg. i2c-dev access we need to turn it on/off
+* ourselves.
+*/
vdd = edp_panel_vdd_on(intel_dp);
 
/* dp aux is extremely sensitive to irq latency, hence request the
-- 
1.8.5.5

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

[Intel-gfx] [PATCH 04/14] drm/i915: Rename edp vdd funcs for consistency

[ville . syrjala]

From: Ville Syrjälä 

edp_* are now the lower level functions and intel_edp_* the higher level
ones. One should use them in pairs.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 28d0183..30943a5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -111,7 +111,7 @@ static struct intel_dp *intel_attached_dp(struct 
drm_connector *connector)
 }
 
 static void intel_dp_link_down(struct intel_dp *intel_dp);
-static bool _edp_panel_vdd_on(struct intel_dp *intel_dp);
+static bool edp_panel_vdd_on(struct intel_dp *intel_dp);
 static void edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync);
 
 int
@@ -533,7 +533,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
bool has_aux_irq = HAS_AUX_IRQ(dev);
bool vdd;
 
-   vdd = _edp_panel_vdd_on(intel_dp);
+   vdd = edp_panel_vdd_on(intel_dp);
 
/* dp aux is extremely sensitive to irq latency, hence request the
 * lowest possible wakeup latency and so prevent the cpu from going into
@@ -1165,7 +1165,7 @@ static  u32 ironlake_get_pp_control(struct intel_dp 
*intel_dp)
return control;
 }
 
-static bool _edp_panel_vdd_on(struct intel_dp *intel_dp)
+static bool edp_panel_vdd_on(struct intel_dp *intel_dp)
 {
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
@@ -1216,7 +1216,7 @@ static bool _edp_panel_vdd_on(struct intel_dp *intel_dp)
 void intel_edp_panel_vdd_on(struct intel_dp *intel_dp)
 {
if (is_edp(intel_dp)) {
-   bool vdd = _edp_panel_vdd_on(intel_dp);
+   bool vdd = edp_panel_vdd_on(intel_dp);
 
WARN(!vdd, "eDP VDD already requested on\n");
}
@@ -1299,6 +1299,11 @@ static void edp_panel_vdd_off(struct intel_dp *intel_dp, 
bool sync)
edp_panel_vdd_schedule_off(intel_dp);
 }
 
+static void intel_edp_panel_vdd_off(struct intel_dp *intel_dp, bool sync)
+{
+   return edp_panel_vdd_off(intel_dp, sync);
+}
+
 void intel_edp_panel_on(struct intel_dp *intel_dp)
 {
struct drm_device *dev = intel_dp_to_dev(intel_dp);
@@ -2102,7 +2107,7 @@ static void intel_enable_dp(struct intel_encoder *encoder)
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_start_link_train(intel_dp);
intel_edp_panel_on(intel_dp);
-   edp_panel_vdd_off(intel_dp, true);
+   intel_edp_panel_vdd_off(intel_dp, true);
intel_dp_complete_link_train(intel_dp);
intel_dp_stop_link_train(intel_dp);
 }
@@ -3405,7 +3410,7 @@ intel_dp_probe_oui(struct intel_dp *intel_dp)
DRM_DEBUG_KMS("Branch OUI: %02hx%02hx%02hx\n",
  buf[0], buf[1], buf[2]);
 
-   edp_panel_vdd_off(intel_dp, false);
+   intel_edp_panel_vdd_off(intel_dp, false);
 }
 
 static bool
@@ -3429,7 +3434,7 @@ intel_dp_probe_mst(struct intel_dp *intel_dp)
intel_dp->is_mst = false;
}
}
-   edp_panel_vdd_off(intel_dp, false);
+   intel_edp_panel_vdd_off(intel_dp, false);
 
drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr, intel_dp->is_mst);
return intel_dp->is_mst;
@@ -4527,7 +4532,7 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
/* Cache DPCD and EDID for edp. */
intel_edp_panel_vdd_on(intel_dp);
has_dpcd = intel_dp_get_dpcd(intel_dp);
-   edp_panel_vdd_off(intel_dp, false);
+   intel_edp_panel_vdd_off(intel_dp, false);
 
if (has_dpcd) {
if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11)
-- 
1.8.5.5

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

[Intel-gfx] [PATCH 02/14] drm/i915: Reorganize vlv eDP reboot notifier

[ville . syrjala]

From: Ville Syrjälä 

Move the vlv_power_sequencer_pipe() after the IS_VALLEYVIEW() check
and flatten the rest of the function.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 43dd226..a9ed2a6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -347,22 +347,22 @@ static int edp_notify_handler(struct notifier_block 
*this, unsigned long code,
struct drm_i915_private *dev_priv = dev->dev_private;
u32 pp_div;
u32 pp_ctrl_reg, pp_div_reg;
-   enum pipe pipe = vlv_power_sequencer_pipe(intel_dp);
+   enum pipe pipe;
 
-   if (!is_edp(intel_dp) || code != SYS_RESTART)
+   if (!IS_VALLEYVIEW(dev) || !is_edp(intel_dp) || code != SYS_RESTART)
return 0;
 
-   if (IS_VALLEYVIEW(dev)) {
-   pp_ctrl_reg = VLV_PIPE_PP_CONTROL(pipe);
-   pp_div_reg  = VLV_PIPE_PP_DIVISOR(pipe);
-   pp_div = I915_READ(pp_div_reg);
-   pp_div &= PP_REFERENCE_DIVIDER_MASK;
+   pipe = vlv_power_sequencer_pipe(intel_dp);
 
-   /* 0x1F write to PP_DIV_REG sets max cycle delay */
-   I915_WRITE(pp_div_reg, pp_div | 0x1F);
-   I915_WRITE(pp_ctrl_reg, PANEL_UNLOCK_REGS | PANEL_POWER_OFF);
-   msleep(intel_dp->panel_power_cycle_delay);
-   }
+   pp_ctrl_reg = VLV_PIPE_PP_CONTROL(pipe);
+   pp_div_reg  = VLV_PIPE_PP_DIVISOR(pipe);
+   pp_div = I915_READ(pp_div_reg);
+   pp_div &= PP_REFERENCE_DIVIDER_MASK;
+
+   /* 0x1F write to PP_DIV_REG sets max cycle delay */
+   I915_WRITE(pp_div_reg, pp_div | 0x1F);
+   I915_WRITE(pp_ctrl_reg, PANEL_UNLOCK_REGS | PANEL_POWER_OFF);
+   msleep(intel_dp->panel_power_cycle_delay);
 
return 0;
 }
-- 
1.8.5.5

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

[Intel-gfx] [PATCH 00/14] drm/i915: edp vdd locking and prep for power sequencer kick

[ville . syrjala]

From: Ville Syrjälä 

While wrestling with the VLV/CHV panel power sequencer I noticed the locking
in our edp vdd code was rather broken. This series aims to fix that by
introducing a power seqeuencer mutex. I was already thinking about using the
aux.hw_mutex for this since it's already locked around the aux ->transfer()
function, but the VLV/CHV multiple power sequencer issue requires a single
lock instead of per-port.

At the end of the series there's a bit of reordering of the DP port
enable/disable sequences to make subsequent power sequencer kick patches
easier. The last patch fixes the wait_pipe_off() timeouts on my ILK.
Strictly speaking it shouldn't be part of this series, but I couldn't
really test this on my ILK without suffering tons of warnings so I
included it here anyway.

Ville Syrjälä (14):
  drm/i915: Parametrize PANEL_PORT_SELECT_VLV
  drm/i915: Reorganize vlv eDP reboot notifier
  drm/i915: Use intel_edp_panel_vdd_on() in intel_dp_probe_mst()
  drm/i915: Rename edp vdd funcs for consistency
  drm/i915: Add a note explaining vdd on/off handling in
intel_dp_aux_ch()
  drm/i915: Replace big nested if block with early return
  drm/i915: Warn about want_panel_vdd in edp_panel_vdd_off_sync()
  drm/i915: Flatten intel_edp_panel_vdd_on()
  drm/i915: Fix edp vdd locking
  drm/i915: Track which port is using which pipe's power sequencer
  drm/i915: Be more careful when picking the initial power sequencer
pipe
  drm/i915: Turn on panel power before doing aux transfers
  drm/i915: Enable DP port earlier
  drm/i915: Move DP port disable to post_disable for pch platforms

 drivers/gpu/drm/i915/i915_drv.h  |   3 +
 drivers/gpu/drm/i915/i915_reg.h  |   3 +-
 drivers/gpu/drm/i915/intel_display.c |   2 +
 drivers/gpu/drm/i915/intel_dp.c  | 619 +--
 drivers/gpu/drm/i915/intel_drv.h |   6 +
 5 files changed, 463 insertions(+), 170 deletions(-)

-- 
1.8.5.5

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

[Intel-gfx] [PATCH 01/14] drm/i915: Parametrize PANEL_PORT_SELECT_VLV

[ville . syrjala]

From: Ville Syrjälä 

Passing the port as a parameter to PANEL_PORT_SELECT_VLV results in
neater code. Sadly the PCH port select bits aren't suitable for the
same treatment and the resulting macro would be much uglier, so
leave those defines as is.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h |  3 +--
 drivers/gpu/drm/i915/intel_dp.c | 12 
 2 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index daac02b..9503d96 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5383,8 +5383,7 @@ enum punit_power_well {
 #define PIPEA_PP_STATUS (VLV_DISPLAY_BASE + 0x61200)
 #define PIPEA_PP_CONTROL(VLV_DISPLAY_BASE + 0x61204)
 #define PIPEA_PP_ON_DELAYS  (VLV_DISPLAY_BASE + 0x61208)
-#define  PANEL_PORT_SELECT_DPB_VLV (1 << 30)
-#define  PANEL_PORT_SELECT_DPC_VLV (2 << 30)
+#define  PANEL_PORT_SELECT_VLV(port)   ((port) << 30)
 #define PIPEA_PP_OFF_DELAYS (VLV_DISPLAY_BASE + 0x6120c)
 #define PIPEA_PP_DIVISOR(VLV_DISPLAY_BASE + 0x61210)
 
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4f69648..43dd226 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -308,9 +308,7 @@ vlv_power_sequencer_pipe(struct intel_dp *intel_dp)
for (pipe = PIPE_A; pipe <= PIPE_B; pipe++) {
u32 port_sel = I915_READ(VLV_PIPE_PP_ON_DELAYS(pipe)) &
PANEL_PORT_SELECT_MASK;
-   if (port_sel == PANEL_PORT_SELECT_DPB_VLV && port == PORT_B)
-   return pipe;
-   if (port_sel == PANEL_PORT_SELECT_DPC_VLV && port == PORT_C)
+   if (port_sel == PANEL_PORT_SELECT_VLV(port))
return pipe;
}
 
@@ -4294,6 +4292,7 @@ intel_dp_init_panel_power_sequencer_registers(struct 
drm_device *dev,
u32 pp_on, pp_off, pp_div, port_sel = 0;
int div = HAS_PCH_SPLIT(dev) ? intel_pch_rawclk(dev) : 
intel_hrawclk(dev);
int pp_on_reg, pp_off_reg, pp_div_reg;
+   enum port port = dp_to_dig_port(intel_dp)->port;
 
if (HAS_PCH_SPLIT(dev)) {
pp_on_reg = PCH_PP_ON_DELAYS;
@@ -4328,12 +4327,9 @@ intel_dp_init_panel_power_sequencer_registers(struct 
drm_device *dev,
/* Haswell doesn't have any port selection bits for the panel
 * power sequencer any more. */
if (IS_VALLEYVIEW(dev)) {
-   if (dp_to_dig_port(intel_dp)->port == PORT_B)
-   port_sel = PANEL_PORT_SELECT_DPB_VLV;
-   else
-   port_sel = PANEL_PORT_SELECT_DPC_VLV;
+   port_sel = PANEL_PORT_SELECT_VLV(port);
} else if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev)) {
-   if (dp_to_dig_port(intel_dp)->port == PORT_A)
+   if (port == PORT_A)
port_sel = PANEL_PORT_SELECT_DPA;
else
port_sel = PANEL_PORT_SELECT_DPD;
-- 
1.8.5.5

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

[Intel-gfx] [PATCH] drm/i915: Move intel_ddi_set_vc_payload_alloc(false) to haswell_crtc_disable()

[ville . syrjala]

From: Ville Syrjälä 

Somehow the intel_ddi_set_vc_payload_alloc(false) call has ended up
in ironlake_crtc_disable() rather than haswell_crtc_disable(). Move it
to the correct place.

intel_ddi_disable_transcoder_func() already disables the vc payload
allocation so this doesn't actually do anything more. The spec
says we should wait for some kind of ack after frobbing the bit. We
don't appear to do that currently, but if and when someone decides
that we should do it, intel_ddi_set_vc_payload_alloc() would appear
to be be the right place for it. So having the function call in
haswell_crtc_disable() seems like the right thing for the future
even if it does nothing currently.

Cc: Dave Airlie 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 09c7298..121024e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4169,10 +4169,6 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
intel_set_pch_fifo_underrun_reporting(dev, pipe, false);
 
intel_disable_pipe(dev_priv, pipe);
-
-   if (intel_crtc->config.dp_encoder_is_mst)
-   intel_ddi_set_vc_payload_alloc(crtc, false);
-
ironlake_pfit_disable(intel_crtc);
 
for_each_encoder_on_crtc(dev, crtc, encoder)
@@ -4240,6 +4236,9 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
intel_set_pch_fifo_underrun_reporting(dev, TRANSCODER_A, false);
intel_disable_pipe(dev_priv, pipe);
 
+   if (intel_crtc->config.dp_encoder_is_mst)
+   intel_ddi_set_vc_payload_alloc(crtc, false);
+
intel_ddi_disable_transcoder_func(dev_priv, cpu_transcoder);
 
ironlake_pfit_disable(intel_crtc);
-- 
1.8.5.5

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

Re: [Intel-gfx] [PATCH] drm/i915: fix i915_frequency_info on BDW

[Rodrigo Vivi]

On Fri, Aug 15, 2014 at 10:12 AM, Paulo Zanoni  wrote:

> 2014-08-15 13:50 GMT-03:00 Rodrigo Vivi :
> >
> >
> >
> > On Fri, Aug 1, 2014 at 2:14 PM, Paulo Zanoni  wrote:
> >>
> >> From: Paulo Zanoni 
> >>
> >> The GEN6_PM* registers don't exist on BDW anymore, so when we read
> >> this file we trigger unclaimed register errors. The equivalent BDW
> >> register for PMs is GEN8_GT_I*R(2), so use it.
> >>
> >> Testcase: igt/pm_rpm/debugfs-read
> >> Signed-off-by: Paulo Zanoni 
> >> ---
> >>  drivers/gpu/drm/i915/i915_debugfs.c | 20 +++-
> >>  1 file changed, 15 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> >> b/drivers/gpu/drm/i915/i915_debugfs.c
> >> index 9e737b7..17bd20ff 100644
> >> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> >> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> >> @@ -1024,6 +1024,7 @@ static int i915_frequency_info(struct seq_file *m,
> >> void *unused)
> >> u32 rpstat, cagf, reqf;
> >> u32 rpupei, rpcurup, rpprevup;
> >> u32 rpdownei, rpcurdown, rpprevdown;
> >> +   u32 pm_ier, pm_imr, pm_isr, pm_iir, pm_mask;
> >> int max_freq;
> >>
> >> /* RPSTAT1 is in the GT power well */
> >> @@ -1061,12 +1062,21 @@ static int i915_frequency_info(struct seq_file
> *m,
> >> void *unused)
> >> gen6_gt_force_wake_put(dev_priv, FORCEWAKE_ALL);
> >> mutex_unlock(&dev->struct_mutex);
> >>
> >> +   if (IS_GEN6(dev) || IS_GEN7(dev)) {
> >> +   pm_ier = I915_READ(GEN6_PMIER);
> >> +   pm_imr = I915_READ(GEN6_PMIMR);
> >> +   pm_isr = I915_READ(GEN6_PMISR);
> >> +   pm_iir = I915_READ(GEN6_PMIIR);
> >> +   pm_mask = I915_READ(GEN6_PMINTRMSK);
> >> +   } else {
> >> +   pm_ier = I915_READ(GEN8_GT_IER(2));
> >> +   pm_imr = I915_READ(GEN8_GT_IMR(2));
> >> +   pm_isr = I915_READ(GEN8_GT_ISR(2));
> >> +   pm_iir = I915_READ(GEN8_GT_IIR(2));
> >
> >
> > Why do we care only about GT(2) interrupt reg?
> > What about other 0, 1 and 3 regs?
>
> Because, as far as I could see, the GEN8_GT(2) register is the one
> that seems to be equivalent to the old GEN6_PM register in terms of
> the functionality debugged by this function: it is the one that
> contains all the RPS stuff. Another thing that influenced me to take
> this decision was that, for example, snb_update_pm_irq() touches
> GEN6_PM, while bdw_update_pm_irq() touches only GEN8_GT(2). But I'm
> not a great user of this code, so maybe we do want more interrupts.
> OTOH, if we want all, there's always i915_interrupt_info.
>

Yeah, makes sense.

Reviewed-by: Rodrigo Vivi 


>
> >
> > Could this explain GT3 failures?
>
> Which GT3 failures? I don't understand why you ask this.
>

forget about the gt3 on this, and thanks for the ideas!


>
> >
> >>
> >> +   pm_mask = I915_READ(GEN6_PMINTRMSK);
> >> +   }
> >> seq_printf(m, "PM IER=0x%08x IMR=0x%08x ISR=0x%08x
> >> IIR=0x%08x, MASK=0x%08x\n",
> >> -  I915_READ(GEN6_PMIER),
> >> -  I915_READ(GEN6_PMIMR),
> >> -  I915_READ(GEN6_PMISR),
> >> -  I915_READ(GEN6_PMIIR),
> >> -  I915_READ(GEN6_PMINTRMSK));
> >> +  pm_ier, pm_imr, pm_isr, pm_iir, pm_mask);
> >> seq_printf(m, "GT_PERF_STATUS: 0x%08x\n",
> gt_perf_status);
> >> seq_printf(m, "Render p-state ratio: %d\n",
> >>(gt_perf_status & 0xff00) >> 8);
> >> --
> >> 2.0.1
> >>
> >> ___
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> >
> >
> >
> > --
> > Rodrigo Vivi
> > Blog: http://blog.vivi.eng.br
> >
>
>
>
> --
> Paulo Zanoni
>



-- 
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] drm/i915/dp: make backlight bl_power control power sequencer backlight

[Clint Taylor]

On 08/12/2014 07:11 AM, Jani Nikula wrote:

This lets the userspace switch off the backlight using the backlight
class sysfs bl_power file. The switch is done using the power sequencer;
the backlight PWM, and everything else, remains enabled. The display
backlight won't draw power, but for maximum power savings the encoder
needs to be switched off.

Signed-off-by: Jani Nikula 
---
  drivers/gpu/drm/i915/intel_dp.c | 22 ++
  1 file changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d8baf60ff3fd..f6e3e9a906b0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1453,6 +1453,27 @@ void intel_edp_backlight_off(struct intel_dp *intel_dp)
intel_panel_disable_backlight(intel_dp->attached_connector);
  }

+/*
+ * Hook for controlling the panel power control backlight through the bl_power
+ * sysfs attribute. Take care to handle multiple calls.
+ */
+static void intel_edp_backlight_power(struct intel_connector *connector,
+ bool enable)
+{
+   struct intel_dp *intel_dp = intel_attached_dp(&connector->base);
+   bool is_enabled = ironlake_get_pp_control(intel_dp) & EDP_BLC_ENABLE;
+
+   if (is_enabled == enable)
+   return;
+
+   DRM_DEBUG_KMS("\n");
+
+   if (enable)
+   _intel_edp_backlight_on(intel_dp);
+   else
+   _intel_edp_backlight_off(intel_dp);


Is there a good reason why we leave the PWM enabled? There is a small 
power requirement to leave the PWM enabled.



+}
+
  static void ironlake_edp_pll_on(struct intel_dp *intel_dp)
  {
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
@@ -4579,6 +4600,7 @@ static bool intel_edp_init_connector(struct intel_dp 
*intel_dp,
}

intel_panel_init(&intel_connector->panel, fixed_mode, downclock_mode);
+   intel_connector->panel.backlight_power = intel_edp_backlight_power;
intel_panel_setup_backlight(connector);

return true;



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

[Intel-gfx] [PATCH v2 i-g-t 1/1] tests: Fix seg fault when gem_mmap is run without specifying a subtest

[Mike Mason]

gem_mmap seg faults when all tests are run together. This occurs because
the new-object subtest closes the gem object, but short-mmap assumes
it still exists. Thus gem_mmap__cpu() returns nil for addr and memset()
seg faults. This patch makes new-object and short-mmap create and
close their own gem objects.

Signed-off-by: Mike Mason 
---
 tests/gem_mmap.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/gem_mmap.c b/tests/gem_mmap.c
index 334bd76..33ffe45 100644
--- a/tests/gem_mmap.c
+++ b/tests/gem_mmap.c
@@ -62,10 +62,8 @@ igt_main
igt_assert(ret == -1 && errno == ENOENT);
}
 
-   igt_fixture
-   handle = gem_create(fd, OBJECT_SIZE);
-
igt_subtest("new-object") {
+   handle = gem_create(fd, OBJECT_SIZE);
arg.handle = handle;
arg.offset = 0;
arg.size = OBJECT_SIZE;
@@ -94,9 +92,11 @@ igt_main
 
igt_subtest("short-mmap") {
igt_assert(OBJECT_SIZE > 4096);
+   handle = gem_create(fd, OBJECT_SIZE);
addr = gem_mmap__cpu(fd, handle, 4096, PROT_WRITE);
memset(addr, 0, 4096);
munmap(addr, 4096);
+   gem_close(fd, handle);
}
 
igt_fixture
-- 
1.9.1

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

[Intel-gfx] [PATCH v2 i-g-t 1/1] scripts: Allow multiple -t and -x regular expressions for run-tests.sh

[Mike Mason]

Piglit allows multiple -t and -x regular expressions to be
given on the command line. This patch enables run-tests.sh to
support that as well.

Signed-off-by: Mike Mason 
---
 scripts/run-tests.sh | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/scripts/run-tests.sh b/scripts/run-tests.sh
index cf77473..d0e0c67 100755
--- a/scripts/run-tests.sh
+++ b/scripts/run-tests.sh
@@ -55,8 +55,10 @@ function print_help {
echo "  (default: $RESULTS)"
echo "  -s  create html summary"
echo "  -t   only include tests that match the regular 
expression"
+   echo "  (can be used more than once)"
echo "  -v  enable verbose mode"
echo "  -x   exclude tests that match the regular expression"
+   echo "  (can be used more than once)"
echo ""
echo "Useful patterns for test filtering are described in 
tests/NAMING-CONVENTION"
 }
@@ -78,9 +80,9 @@ while getopts ":dhlr:st:vx:" opt; do
l) list_tests; exit ;;
r) RESULTS="$OPTARG" ;;
s) SUMMARY="html" ;;
-   t) FILTER="-t $OPTARG" ;;
+   t) FILTER="$FILTER -t $OPTARG" ;;
v) VERBOSE="-v" ;;
-   x) EXCLUDE="-x $OPTARG" ;;
+   x) EXCLUDE="$EXCLUDE -x $OPTARG" ;;
:)
echo "Option -$OPTARG requires an argument."
exit 1
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH] drm/edid: Reduce horizontal timings for pixel replicated modes

[Clint Taylor]

On 08/14/2014 11:48 AM, Ville Syrjälä wrote:

On Thu, Aug 14, 2014 at 11:09:25AM -0700, clinton.a.tay...@intel.com wrote:

From: Clint Taylor 

Pixel replicated modes should be 720 horizontal pixel and pixel
replicated by the HW across the HDMI cable at 2X pixel clock. Current
horizontal resolution of 1440 does not allow pixel duplication to
occur and scaling artifacts occur on the TV. HDMI certification
7-26 currently fails for all pixel replicated modes. This change fizes
the HDMI certification issues with 480i/576i.

Signed-off-by: Clint Taylor 
---
  drivers/gpu/drm/drm_edid.c|  100 ++---
  drivers/gpu/drm/i915/intel_hdmi.c |   14 +-
  2 files changed, 63 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f905c63..c7a26a7 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -632,27 +632,27 @@ static const struct drm_display_mode edid_cea_modes[] = {
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_INTERLACE),
  .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
-   /* 6 - 1440x480i@60Hz */
-   { DRM_MODE("1440x480i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
-  1602, 1716, 0, 480, 488, 494, 525, 0,
+   /* 6 - 720(1440)x480i@60Hz */
+   { DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+  801, 858, 0, 480, 488, 494, 525, 0,


As stated before I think I would have preferred explicit /2 here, but
if you prefer to have it this way I can live with it.


Sorry, I missed the other patches comments. The CEA-861-E specification 
actually has the pixel doubled values in (Table 3) the detailed sync 
information data, so it does make sense to have the doubled values in 
the table with /2. I prefer the actual values myself, but I am willing 
to use either method.





   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
  .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
-   /* 7 - 1440x480i@60Hz */
-   { DRM_MODE("1440x480i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
-  1602, 1716, 0, 480, 488, 494, 525, 0,
+   /* 7 - 720(1440)x480i@60Hz */
+   { DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+  801, 858, 0, 480, 488, 494, 525, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
  .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
-   /* 8 - 1440x240@60Hz */
-   { DRM_MODE("1440x240", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
-  1602, 1716, 0, 240, 244, 247, 262, 0,
+   /* 8 - 720(1440)x240@60Hz */
+   { DRM_MODE("720x240", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+  801, 858, 0, 240, 244, 247, 262, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_DBLCLK),
  .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
-   /* 9 - 1440x240@60Hz */
-   { DRM_MODE("1440x240", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
-  1602, 1716, 0, 240, 244, 247, 262, 0,
+   /* 9 - 720(1440)x240@60Hz */
+   { DRM_MODE("720x240", DRM_MODE_TYPE_DRIVER, 13500, 720, 739,
+  801, 858, 0, 240, 244, 247, 262, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_DBLCLK),
  .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
@@ -714,27 +714,27 @@ static const struct drm_display_mode edid_cea_modes[] = {
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_INTERLACE),
  .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
-   /* 21 - 1440x576i@50Hz */
-   { DRM_MODE("1440x576i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
-  1590, 1728, 0, 576, 580, 586, 625, 0,
+   /* 21 - 720(1440)x576i@50Hz */
+   { DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500, 720, 732,
+  795, 864, 0, 576, 580, 586, 625, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM_MODE_FLAG_DBLCLK),
  .vrefresh = 50, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_4_3, },
-   /* 22 - 1440x576i@50Hz */
-   { DRM_MODE("1440x576i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1464,
-  1590, 1728, 0, 576, 580, 586, 625, 0,
+   /* 22 - 720(1440)x576i@50Hz */
+   { DRM_MODE("720x576i", DRM_MODE_TYPE_DRIVER, 13500, 720, 732,
+  795, 864, 0, 576, 580, 586, 625, 0,
   DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC |
DRM_MODE_FLAG_INTERLACE | DRM

Re: [Intel-gfx] [PATCH] drm: HDMI pixel replication modes now hactive of 720 for pixel replication

[Clint Taylor]

On 08/12/2014 04:07 AM, Ville Syrjälä wrote:

On Tue, Jul 29, 2014 at 02:58:23PM -0700, clinton.a.tay...@intel.com wrote:

From: Clint Taylor 

CEA SD interlaced modes use a horizontal 720 pixels that are pixel replicated 
to 1440. The current driver reports 1440 pixel to the OS and does not set pixel 
replicated modes.

Signed-off-by: Clint Taylor 
---
  drivers/gpu/drm/drm_edid.c|   68 ++---
  drivers/gpu/drm/i915/intel_hdmi.c |   13 +++
  2 files changed, 47 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index dfa9769..5233f4c 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -632,26 +632,26 @@ static const struct drm_display_mode edid_cea_modes[] = {
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_INTERLACE),
  .vrefresh = 60, .picture_aspect_ratio = HDMI_PICTURE_ASPECT_16_9, },
-   /* 6 - 1440x480i@60Hz */
-   { DRM_MODE("1440x480i", DRM_MODE_TYPE_DRIVER, 27000, 1440, 1478,
+   /* 6 - 720(1440)x480i@60Hz */
+   { DRM_MODE("720x480i", DRM_MODE_TYPE_DRIVER, 27000, 720, 1478,


I think the best thing here might be to halve all the horizontal
timings (and the clock), and maybe do it with an explicit /2 to
remind people that this is a bit special, and also the spec lists
the doubled timings, so it's maybe a bit easier to compare with the
spec that way.

So perhaps something like this:
DRM_MODE(..., 27000/2, 1440/2, 1478/2, ...



diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 2422413..f8cdf7f 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -918,6 +918,19 @@ bool intel_hdmi_compute_config(struct intel_encoder 
*encoder,
intel_hdmi->color_range = 0;
}

+   /* Adjust pipe timings for pixel doubled modes */
+   if ((adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)) {
+   adjusted_mode->hsync_start /= 2;
+   adjusted_mode->hsync_end /= 2;
+   adjusted_mode->htotal /= 2;
+
+   drm_mode_set_crtcinfo(adjusted_mode, 0);
+
+   /* Set 2x pixel double on pipe */
+   pipe_config->pixel_multiplier = 2;
+   pipe_config->port_clock = adjusted_mode->crtc_clock;
+   }


If you halve the timings already in drm_edid.c all of this would be
reduced to just:

if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
pipe_config->pixel_multiplier = 2;



+
if (intel_hdmi->color_range)
pipe_config->limited_color_range = true;

--
1.7.9.5

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




Sorry, I missed this comment completely before I submitted the second 
patch to dri-devel. I will be making changes to the second patch only 
based on the feedback so far.


Thanks,
Clint


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

Re: [Intel-gfx] [PATCH 1/4] drm/i915/dp: split up panel power control from backlight pwm control

[Clint Taylor]

On 08/12/2014 07:11 AM, Jani Nikula wrote:

Make it possible to change panel power control backlight state without
touching the PWM. No functional changes.

Signed-off-by: Jani Nikula 
---
  drivers/gpu/drm/i915/intel_dp.c | 39 ++-
  1 file changed, 26 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e5ada4fbe945..d8baf60ff3fd 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1384,7 +1384,8 @@ void intel_edp_panel_off(struct intel_dp *intel_dp)
intel_display_power_put(dev_priv, power_domain);
  }

-void intel_edp_backlight_on(struct intel_dp *intel_dp)
+/* Enable backlight in the panel power control. */
+static void _intel_edp_backlight_on(struct intel_dp *intel_dp)
  {
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
@@ -1392,13 +1393,6 @@ void intel_edp_backlight_on(struct intel_dp *intel_dp)
u32 pp;
u32 pp_ctrl_reg;

-   if (!is_edp(intel_dp))
-   return;
-
-   DRM_DEBUG_KMS("\n");
-
-   intel_panel_enable_backlight(intel_dp->attached_connector);
-
/*
 * If we enable the backlight right away following a panel power
 * on, we may see slight flicker as the panel syncs with the eDP
@@ -1415,17 +1409,26 @@ void intel_edp_backlight_on(struct intel_dp *intel_dp)
POSTING_READ(pp_ctrl_reg);
  }

-void intel_edp_backlight_off(struct intel_dp *intel_dp)
+/* Enable backlight PWM and backlight PP control. */
+void intel_edp_backlight_on(struct intel_dp *intel_dp)
+{
+   if (!is_edp(intel_dp))
+   return;
+
+   DRM_DEBUG_KMS("\n");
+
+   intel_panel_enable_backlight(intel_dp->attached_connector);
+   _intel_edp_backlight_on(intel_dp);
+}
+
+/* Disable backlight in the panel power control. */
+static void _intel_edp_backlight_off(struct intel_dp *intel_dp)
  {
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct drm_i915_private *dev_priv = dev->dev_private;
u32 pp;
u32 pp_ctrl_reg;

-   if (!is_edp(intel_dp))
-   return;
-
-   DRM_DEBUG_KMS("\n");
pp = ironlake_get_pp_control(intel_dp);
pp &= ~EDP_BLC_ENABLE;

@@ -1436,7 +1439,17 @@ void intel_edp_backlight_off(struct intel_dp *intel_dp)
intel_dp->last_backlight_off = jiffies;

edp_wait_backlight_off(intel_dp);
+}
+
+/* Disable backlight PP control and backlight PWM. */
+void intel_edp_backlight_off(struct intel_dp *intel_dp)
+{
+   if (!is_edp(intel_dp))
+   return;
+
+   DRM_DEBUG_KMS("\n");

+   _intel_edp_backlight_off(intel_dp);
intel_panel_disable_backlight(intel_dp->attached_connector);
  }




Patch works as expected.

Some day we need to rename intel_panel_disable_backlight() to 
intel_panel_disable_backlight_pwm() to make this code more readable as 
all intel_panel_backlight_ methods only affect the PWM.


Clint





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

Re: [Intel-gfx] [PATCH i-g-t 1/1] Add kms_flip_event_leak to .gitignore

[Thomas Wood]

On 15 August 2014 20:14, Mason, Michael W  wrote:
> This patch just adds kms_flip_event_leak to tests/.gitignore.

Patch merged, thanks.

>
> Signed-off-by: Mike Mason 
> ---
>  tests/.gitignore | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/tests/.gitignore b/tests/.gitignore index d14d87b..3da061e 100644
> --- a/tests/.gitignore
> +++ b/tests/.gitignore
> @@ -121,6 +121,7 @@ kms_cursor_crc
>  kms_fbc_crc
>  kms_fence_pin_leak
>  kms_flip
> +kms_flip_event_leak
>  kms_flip_tiling
>  kms_force_connector
>  kms_mmio_vs_cs_flip
> --
> 1.9.1
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] intel-gpu-tools: skip kms_flip_event_leak unless we have cairo

[Thomas Wood]

On 18 August 2014 14:56,   wrote:
> From: Tim Gore 
>
> kms_flip_event_leak depends on cairo, so add it to the
> list of tests to skip (in Android.mk) if ANDROID_HAS_CAIRO
> is not set to 1.

Patch merged, thanks.

>
> Signed-off-by: Tim Gore 
> ---
>  tests/Android.mk | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tests/Android.mk b/tests/Android.mk
> index 00e6f1b..3644aa1 100644
> --- a/tests/Android.mk
> +++ b/tests/Android.mk
> @@ -72,7 +72,8 @@ else
>  kms_render \
>  kms_universal_plane \
>  kms_rotation_crc \
> -kms_force_connector
> +kms_force_connector \
> +kms_flip_event_leak
>  IGT_LOCAL_CFLAGS += -DANDROID_HAS_CAIRO=0
>  endif
>
> --
> 2.0.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/bdw: Populate lrc with aliasing ppgtt if required

[Damien Lespiau]

On Mon, Aug 18, 2014 at 03:54:02PM +0100, Thomas Daniel wrote:
> A previous commit broke aliasing PPGTT for lrc, resulting in a kernel oops
> on boot. Add a check so that is full PPGTT is not in use the context is
> populated with the aliasing PPGTT.
> 
> Issue: VIZ-4278
> Signed-off-by: Thomas Daniel 
> ---
>  drivers/gpu/drm/i915/intel_lrc.c |7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c 
> b/drivers/gpu/drm/i915/intel_lrc.c
> index c096b9b..79a6b91 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1452,12 +1452,19 @@ static int
>  populate_lr_context(struct intel_context *ctx, struct drm_i915_gem_object 
> *ctx_obj,
>   struct intel_engine_cs *ring, struct intel_ringbuffer 
> *ringbuf)
>  {
> + struct drm_device *dev = ring->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
>   struct drm_i915_gem_object *ring_obj = ringbuf->obj;
>   struct i915_hw_ppgtt *ppgtt = ctx->ppgtt;

It's a bit weird to leave ppgtt initialized here when you're going to
always override it below.

>   struct page *page;
>   uint32_t *reg_state;
>   int ret;
>  
> + if (USES_FULL_PPGTT(dev))
> + ppgtt = ctx->ppgtt;
> + else
> + ppgtt = dev_priv->mm.aliasing_ppgtt;
> +

The patch drom daniel you mention removes the usage of USES_FULL_PPGTT()
to directly test ctx->ppgtt. You may want to reproduce that here ie.

ppgtt = ctx->ppgtt;
if (!ppgtt)
ppgtt = dev_priv->mm.aliasing_ppgtt;

doesn't really matter either way I guess, but can we at least not set
then always override ppgtt?

Thanks,

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

Re: [Intel-gfx] [PATCH] drm/i915/bdw: Disable execlists by default

[Paulo Zanoni]

2014-08-18 5:29 GMT-03:00 Jani Nikula :
> On Fri, 15 Aug 2014, Damien Lespiau  wrote:
>> We still have a few missing bits and pieces to have execlists enabled by
>> default eg. the error capture or the render state initialization and so
>> it wouldn't be wise to enable it by default on BDW just yet.
>
> Also,
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82740

Yes, please! I can't boot BDW anymore without this.

Reviewed-by: Paulo Zanoni 
Tested-by: Paulo Zanoni 

>
>> Cc: Daniel Vetter 
>> Cc: Thomas Daniel 
>> Signed-off-by: Damien Lespiau 
>> ---
>>  drivers/gpu/drm/i915/i915_params.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_params.c 
>> b/drivers/gpu/drm/i915/i915_params.c
>> index 0886aca..139f490 100644
>> --- a/drivers/gpu/drm/i915/i915_params.c
>> +++ b/drivers/gpu/drm/i915/i915_params.c
>> @@ -35,7 +35,7 @@ struct i915_params i915 __read_mostly = {
>>   .vbt_sdvo_panel_type = -1,
>>   .enable_rc6 = -1,
>>   .enable_fbc = -1,
>> - .enable_execlists = -1,
>> + .enable_execlists = 0,
>>   .enable_hangcheck = true,
>>   .enable_ppgtt = -1,
>>   .enable_psr = 0,
>> @@ -122,7 +122,7 @@ MODULE_PARM_DESC(enable_ppgtt,
>>  module_param_named(enable_execlists, i915.enable_execlists, int, 0400);
>>  MODULE_PARM_DESC(enable_execlists,
>>   "Override execlists usage. "
>> - "(-1=auto [default], 0=disabled, 1=enabled)");
>> + "(-1=auto, 0=disabled [default], 1=enabled)");
>>
>>  module_param_named(enable_psr, i915.enable_psr, int, 0600);
>>  MODULE_PARM_DESC(enable_psr, "Enable PSR (default: false)");
>> --
>> 1.8.3.1
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



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

[Intel-gfx] [PATCH] drm/i915/bdw: Populate lrc with aliasing ppgtt if required

[Thomas Daniel]

A previous commit broke aliasing PPGTT for lrc, resulting in a kernel oops
on boot. Add a check so that is full PPGTT is not in use the context is
populated with the aliasing PPGTT.

Issue: VIZ-4278
Signed-off-by: Thomas Daniel 
---
 drivers/gpu/drm/i915/intel_lrc.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index c096b9b..79a6b91 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1452,12 +1452,19 @@ static int
 populate_lr_context(struct intel_context *ctx, struct drm_i915_gem_object 
*ctx_obj,
struct intel_engine_cs *ring, struct intel_ringbuffer 
*ringbuf)
 {
+   struct drm_device *dev = ring->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_i915_gem_object *ring_obj = ringbuf->obj;
struct i915_hw_ppgtt *ppgtt = ctx->ppgtt;
struct page *page;
uint32_t *reg_state;
int ret;
 
+   if (USES_FULL_PPGTT(dev))
+   ppgtt = ctx->ppgtt;
+   else
+   ppgtt = dev_priv->mm.aliasing_ppgtt;
+
ret = i915_gem_object_set_to_cpu_domain(ctx_obj, true);
if (ret) {
DRM_DEBUG_DRIVER("Could not set to CPU domain\n");
-- 
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 41/43] drm/i915/bdw: Enable Logical Ring Contexts (hence, Execlists)

[Daniel, Thomas]

> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Monday, August 18, 2014 9:33 AM
> To: Daniel, Thomas; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 41/43] drm/i915/bdw: Enable Logical Ring
> Contexts (hence, Execlists)
> 
> On Thu, 24 Jul 2014, Thomas Daniel  wrote:
> > From: Oscar Mateo 
> >
> > The time has come, the Walrus said, to talk of many things.
> 
> FYI this causes https://bugs.freedesktop.org/show_bug.cgi?id=82740
Hmm, this seems to be an interaction between execlists and PPGTT
patches, specifically:
http://patchwork.freedesktop.org/patch/31150/
which breaks aliasing PPGTT when execlists are enabled, resulting
in this oops on boot.

I will post a patch which avoids this but I don't know if the intention
is to drop aliasing PPGTT support when execlists are enabled.

Thomas.

> > Signed-off-by: Oscar Mateo 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index b7cf0ec..1ce51d6 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2061,7 +2061,7 @@ struct drm_i915_cmd_table {
> >  #define I915_NEED_GFX_HWS(dev) (INTEL_INFO(dev)->need_gfx_hws)
> >
> >  #define HAS_HW_CONTEXTS(dev)   (INTEL_INFO(dev)->gen >= 6)
> > -#define HAS_LOGICAL_RING_CONTEXTS(dev) 0
> > +#define HAS_LOGICAL_RING_CONTEXTS(dev) (INTEL_INFO(dev)-
> >gen >= 8)
> >  #define HAS_ALIASING_PPGTT(dev)(INTEL_INFO(dev)->gen >= 6)
> >  #define HAS_PPGTT(dev) (INTEL_INFO(dev)->gen >= 7 &&
> !IS_GEN8(dev))
> >  #define USES_PPGTT(dev)intel_enable_ppgtt(dev, false)
> > --
> > 1.7.9.5
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> --
> 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: fix plane/cursor handling when runtime suspended

[Ville Syrjälä]

On Fri, Aug 15, 2014 at 03:59:32PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni 
> 
> If we're runtime suspended and try to use the plane interfaces, we
> will get a lot of WARNs saying we did the wrong thing.
> 
> We need to get runtime PM references to pin the objects, and to
> change the fences. The pin functions are the ideal places for
> this, but intel_crtc_cursor_set_obj() doesn't call them, so we also
> have to add get/put calls inside it. There is no problem if we runtime
> suspend right after these functions are finished, because the
> registers written are forwarded to system memory.
> 
> Note: for a complete fix of the cursor-dpms test case, we also need
> the patch named "drm/i915: Don't try to enable cursor from setplane
> when crtc is disabled".
> 
> v2: - Narrow the put/get calls on intel_crtc_cursor_set_obj() (Daniel)
> v3: - Make get/put also surround the fence and unpin calls (Daniel and
>   Ville).
> - Merge all the plane changes into a single patch since they're
>   the same fix.
> - Add the comment requested by Daniel.
> v4: - Remove spurious whitespace (Ville).
> v5: - Remove intel_crtc_update_cursor() chunk since Ville did an
>   equivalent fix in another patch (Ville).
> v6: - Remove unpin chunk: it will be on a separate patch (Ville,
>   Chris, Daniel).
> v7: - Same thing, new color.
> 
> Testcase: igt/pm_rpm/cursor
> Testcase: igt/pm_rpm/cursor-dpms
> Testcase: igt/pm_rpm/legacy-planes
> Testcase: igt/pm_rpm/legacy-planes-dpms
> Testcase: igt/pm_rpm/universal-planes
> Testcase: igt/pm_rpm/universal-planes-dpms
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81645
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82603
> Cc: sta...@vger.kernel.org
> Signed-off-by: Paulo Zanoni 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 3f8e037..15fe3eb 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2201,6 +2201,15 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
>   if (need_vtd_wa(dev) && alignment < 256 * 1024)
>   alignment = 256 * 1024;
>  
> + /*
> +  * Global gtt pte registers are special registers which actually forward
> +  * writes to a chunk of system memory. Which means that there is no risk
> +  * that the register values disappear as soon as we call
> +  * intel_runtime_pm_put(), so it is correct to wrap only the
> +  * pin/unpin/fence and not more.
> +  */
> + intel_runtime_pm_get(dev_priv);
> +
>   dev_priv->mm.interruptible = false;
>   ret = i915_gem_object_pin_to_display_plane(obj, alignment, pipelined);
>   if (ret)
> @@ -2218,12 +2227,14 @@ intel_pin_and_fence_fb_obj(struct drm_device *dev,
>   i915_gem_object_pin_fence(obj);
>  
>   dev_priv->mm.interruptible = true;
> + intel_runtime_pm_put(dev_priv);
>   return 0;
>  
>  err_unpin:
>   i915_gem_object_unpin_from_display_plane(obj);
>  err_interruptible:
>   dev_priv->mm.interruptible = true;
> + intel_runtime_pm_put(dev_priv);
>   return ret;
>  }
>  
> @@ -8253,6 +8264,7 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc 
> *crtc,
>uint32_t width, uint32_t height)
>  {
>   struct drm_device *dev = crtc->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>   enum pipe pipe = intel_crtc->pipe;
>   unsigned old_width, stride;
> @@ -8292,6 +8304,15 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc 
> *crtc,
>   goto fail_locked;
>   }
>  
> + /*
> +  * Global gtt pte registers are special registers which actually
> +  * forward writes to a chunk of system memory. Which means that
> +  * there is no risk that the register values disappear as soon
> +  * as we call intel_runtime_pm_put(), so it is correct to wrap
> +  * only the pin/unpin/fence and not more.
> +  */
> + intel_runtime_pm_get(dev_priv);
> +
>   /* Note that the w/a also requires 2 PTE of padding following
>* the bo. We currently fill all unused PTE with the shadow
>* page and so we should always have valid PTE following the
> @@ -8304,16 +8325,20 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc 
> *crtc,
>   ret = i915_gem_object_pin_to_display_plane(obj, alignment, 
> NULL);
>   if (ret) {
>   DRM_DEBUG_KMS("failed to move cursor bo into the 
> GTT\n");
> + intel_runtime_pm_put(dev_priv);
>   goto fail_locked;
>   }
>  
>   ret = i915_gem_object_put_fence

[Intel-gfx] [PATCH] intel-gpu-tools: skip kms_flip_event_leak unless we have cairo

[tim . gore]

From: Tim Gore 

kms_flip_event_leak depends on cairo, so add it to the
list of tests to skip (in Android.mk) if ANDROID_HAS_CAIRO
is not set to 1.

Signed-off-by: Tim Gore 
---
 tests/Android.mk | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/Android.mk b/tests/Android.mk
index 00e6f1b..3644aa1 100644
--- a/tests/Android.mk
+++ b/tests/Android.mk
@@ -72,7 +72,8 @@ else
 kms_render \
 kms_universal_plane \
 kms_rotation_crc \
-kms_force_connector
+kms_force_connector \
+kms_flip_event_leak
 IGT_LOCAL_CFLAGS += -DANDROID_HAS_CAIRO=0
 endif
 
-- 
2.0.3

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

Re: [Intel-gfx] [PATCH v3 1/5] drm/i915: take display port power domain in DP HPD handler

[Jani Nikula]

Series pushed to -fixes, thanks for the patches and review.

BR,
Jani.


On Mon, 18 Aug 2014, Imre Deak  wrote:
> Ville noticed that we can call ibx_digital_port_connected() which accesses
> the HW without holding any power well/runtime pm reference. Fix this by
> holding a display port power domain reference around the whole hpd_pulse
> handler.
>
> Signed-off-by: Imre Deak 
> Reviewed-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 19 ++-
>  1 file changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index ee3942f..a520188 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4037,15 +4037,21 @@ bool
>  intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
>  {
>   struct intel_dp *intel_dp = &intel_dig_port->dp;
> + struct intel_encoder *intel_encoder = &intel_dig_port->base;
>   struct drm_device *dev = intel_dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
> - int ret;
> + enum intel_display_power_domain power_domain;
> + bool ret = true;
> +
>   if (intel_dig_port->base.type != INTEL_OUTPUT_EDP)
>   intel_dig_port->base.type = INTEL_OUTPUT_DISPLAYPORT;
>  
>   DRM_DEBUG_KMS("got hpd irq on port %d - %s\n", intel_dig_port->port,
> long_hpd ? "long" : "short");
>  
> + power_domain = intel_display_port_power_domain(intel_encoder);
> + intel_display_power_get(dev_priv, power_domain);
> +
>   if (long_hpd) {
>   if (!ibx_digital_port_connected(dev_priv, intel_dig_port))
>   goto mst_fail;
> @@ -4061,8 +4067,7 @@ intel_dp_hpd_pulse(struct intel_digital_port 
> *intel_dig_port, bool long_hpd)
>  
>   } else {
>   if (intel_dp->is_mst) {
> - ret = intel_dp_check_mst_status(intel_dp);
> - if (ret == -EINVAL)
> + if (intel_dp_check_mst_status(intel_dp) == -EINVAL)
>   goto mst_fail;
>   }
>  
> @@ -4076,7 +4081,8 @@ intel_dp_hpd_pulse(struct intel_digital_port 
> *intel_dig_port, bool long_hpd)
>   drm_modeset_unlock(&dev->mode_config.connection_mutex);
>   }
>   }
> - return false;
> + ret = false;
> + goto put_power;
>  mst_fail:
>   /* if we were in MST mode, and device is not there get out of MST mode 
> */
>   if (intel_dp->is_mst) {
> @@ -4084,7 +4090,10 @@ mst_fail:
>   intel_dp->is_mst = false;
>   drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr, 
> intel_dp->is_mst);
>   }
> - return true;
> +put_power:
> + intel_display_power_put(dev_priv, power_domain);
> +
> + return ret;
>  }
>  
>  /* Return which DP Port should be selected for Transcoder DP control */
> -- 
> 1.8.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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: Use dev_priv as first argument of for_each_pipe()

[Chris Wilson]

On Mon, Aug 18, 2014 at 02:07:40PM +0100, Damien Lespiau wrote:
> On Mon, Aug 18, 2014 at 01:58:06PM +0100, Chris Wilson wrote:
> > On Mon, Aug 18, 2014 at 01:49:10PM +0100, Damien Lespiau wrote:
> > > Chris has decided that enough is enough. It's time to fixup dev Vs
> > > dev_priv. This is a modest contribution to the crusade.
> > > 
> > > v2: Still use INTEL_INFO(), for the (mythical!) case we want to hardcode
> > > the info struct with defines (Chris)
> > > Rename the macro argument from 'dev' to 'dev_priv' (Jani)
> > > 
> > > v3: Use names unlikely to be used as macro arguments (Chris)
> > 
> > I can be annoying! These macros typically take the iter as the first
> > argument...
> 
> How typical is your typical?

list_for_each and everything derived from them that paid attention...
 
> #define for_each_pipe(__dev_priv, __p)
> #define for_each_crtc(dev, crtc)
> #define for_each_intel_crtc(dev, intel_crtc)
> #define for_each_intel_encoder(dev, intel_encoder) 
> #define for_each_encoder_on_crtc(dev, __crtc, intel_encoder)
> #define for_each_connector_on_encoder(dev, __encoder, intel_connector)
> 
> Sounds like a lot of churn for no good reason this time.

Or that I forgot to tell you about this detail last time.
-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: Use dev_priv as first argument of for_each_pipe()

[Damien Lespiau]

On Mon, Aug 18, 2014 at 01:58:06PM +0100, Chris Wilson wrote:
> On Mon, Aug 18, 2014 at 01:49:10PM +0100, Damien Lespiau wrote:
> > Chris has decided that enough is enough. It's time to fixup dev Vs
> > dev_priv. This is a modest contribution to the crusade.
> > 
> > v2: Still use INTEL_INFO(), for the (mythical!) case we want to hardcode
> > the info struct with defines (Chris)
> > Rename the macro argument from 'dev' to 'dev_priv' (Jani)
> > 
> > v3: Use names unlikely to be used as macro arguments (Chris)
> 
> I can be annoying! These macros typically take the iter as the first
> argument...

How typical is your typical?

#define for_each_pipe(__dev_priv, __p)
#define for_each_crtc(dev, crtc)
#define for_each_intel_crtc(dev, intel_crtc)
#define for_each_intel_encoder(dev, intel_encoder) 
#define for_each_encoder_on_crtc(dev, __crtc, intel_encoder)
#define for_each_connector_on_encoder(dev, __encoder, intel_connector)

Sounds like a lot of churn for no good reason this time.

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

Re: [Intel-gfx] [PATCH] drm/i915: Use dev_priv as first argument of for_each_pipe()

[Chris Wilson]

On Mon, Aug 18, 2014 at 01:49:10PM +0100, Damien Lespiau wrote:
> Chris has decided that enough is enough. It's time to fixup dev Vs
> dev_priv. This is a modest contribution to the crusade.
> 
> v2: Still use INTEL_INFO(), for the (mythical!) case we want to hardcode
> the info struct with defines (Chris)
> Rename the macro argument from 'dev' to 'dev_priv' (Jani)
> 
> v3: Use names unlikely to be used as macro arguments (Chris)

I can be annoying! These macros typically take the iter as the first
argument...
-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] drm/i915: Print the pipe on which the vblank wait times out

[Damien Lespiau]

Pimp up the debug message that tells us we've been waiting for a vblank
that never arrived. Printing the pipe could lead a "doh!" moment where
we've been waiting for a vblank on a pipe that was off for instance.

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/i915/intel_display.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f602924..71d3487 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -900,7 +900,8 @@ static void g4x_wait_for_vblank(struct drm_device *dev, int 
pipe)
frame = I915_READ(frame_reg);
 
if (wait_for(I915_READ_NOTRACE(frame_reg) != frame, 50))
-   WARN(1, "vblank wait timed out\n");
+   WARN(1, "vblank wait on pipe %c timed out\n",
+pipe_name(pipe));
 }
 
 /**
@@ -941,7 +942,8 @@ void intel_wait_for_vblank(struct drm_device *dev, int pipe)
if (wait_for(I915_READ(pipestat_reg) &
 PIPE_VBLANK_INTERRUPT_STATUS,
 50))
-   DRM_DEBUG_KMS("vblank wait timed out\n");
+   DRM_DEBUG_KMS("vblank wait on pipe %c timed out\n",
+ pipe_name(pipe));
 }
 
 static bool pipe_dsl_stopped(struct drm_device *dev, enum pipe pipe)
-- 
1.8.3.1

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

[Intel-gfx] [PATCH] drm/i915: Use dev_priv as first argument of for_each_pipe()

[Damien Lespiau]

Chris has decided that enough is enough. It's time to fixup dev Vs
dev_priv. This is a modest contribution to the crusade.

v2: Still use INTEL_INFO(), for the (mythical!) case we want to hardcode
the info struct with defines (Chris)
Rename the macro argument from 'dev' to 'dev_priv' (Jani)

v3: Use names unlikely to be used as macro arguments (Chris)

Suggested-by: Chris Wilson 
Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 10 +++---
 drivers/gpu/drm/i915/i915_dma.c  |  4 +--
 drivers/gpu/drm/i915/i915_drv.h  |  3 +-
 drivers/gpu/drm/i915/i915_irq.c  | 65 ++--
 drivers/gpu/drm/i915/intel_display.c | 16 +
 drivers/gpu/drm/i915/intel_dp.c  |  2 +-
 drivers/gpu/drm/i915/intel_panel.c   |  2 +-
 drivers/gpu/drm/i915/intel_pm.c  | 17 +-
 8 files changed, 60 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6c82bda..637143c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -662,7 +662,7 @@ static int i915_interrupt_info(struct seq_file *m, void 
*data)
   I915_READ(VLV_IIR_RW));
seq_printf(m, "Display IMR:\t%08x\n",
   I915_READ(VLV_IMR));
-   for_each_pipe(pipe)
+   for_each_pipe(dev_priv, pipe)
seq_printf(m, "Pipe %c stat:\t%08x\n",
   pipe_name(pipe),
   I915_READ(PIPESTAT(pipe)));
@@ -702,7 +702,7 @@ static int i915_interrupt_info(struct seq_file *m, void 
*data)
   i, I915_READ(GEN8_GT_IER(i)));
}
 
-   for_each_pipe(pipe) {
+   for_each_pipe(dev_priv, pipe) {
if (!intel_display_power_enabled(dev_priv,
POWER_DOMAIN_PIPE(pipe))) {
seq_printf(m, "Pipe %c power disabled\n",
@@ -749,7 +749,7 @@ static int i915_interrupt_info(struct seq_file *m, void 
*data)
   I915_READ(VLV_IIR_RW));
seq_printf(m, "Display IMR:\t%08x\n",
   I915_READ(VLV_IMR));
-   for_each_pipe(pipe)
+   for_each_pipe(dev_priv, pipe)
seq_printf(m, "Pipe %c stat:\t%08x\n",
   pipe_name(pipe),
   I915_READ(PIPESTAT(pipe)));
@@ -785,7 +785,7 @@ static int i915_interrupt_info(struct seq_file *m, void 
*data)
   I915_READ(IIR));
seq_printf(m, "Interrupt mask:  %08x\n",
   I915_READ(IMR));
-   for_each_pipe(pipe)
+   for_each_pipe(dev_priv, pipe)
seq_printf(m, "Pipe %c stat: %08x\n",
   pipe_name(pipe),
   I915_READ(PIPESTAT(pipe)));
@@ -4178,7 +4178,7 @@ void intel_display_crc_init(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
enum pipe pipe;
 
-   for_each_pipe(pipe) {
+   for_each_pipe(dev_priv, pipe) {
struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[pipe];
 
pipe_crc->opened = false;
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 3f676f9..f19dbff 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1528,10 +1528,10 @@ static void intel_device_info_runtime_init(struct 
drm_device *dev)
info = (struct intel_device_info *)&dev_priv->info;
 
if (IS_VALLEYVIEW(dev))
-   for_each_pipe(pipe)
+   for_each_pipe(dev_priv, pipe)
info->num_sprites[pipe] = 2;
else
-   for_each_pipe(pipe)
+   for_each_pipe(dev_priv, pipe)
info->num_sprites[pipe] = 1;
 
if (i915.disable_display) {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4754328..dcfc63c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -163,7 +163,8 @@ enum hpd_pin {
 I915_GEM_DOMAIN_INSTRUCTION | \
 I915_GEM_DOMAIN_VERTEX)
 
-#define for_each_pipe(p) for ((p) = 0; (p) < INTEL_INFO(dev)->num_pipes; (p)++)
+#define for_each_pipe(__dev_priv, __p) \
+   for ((__p) = 0; (__p) < INTEL_INFO(__dev_priv)->num_pipes; (__p)++)
 #define for_each_sprite(p, s) for ((s) = 0; (s) < 
INTEL_INFO(dev)->num_sprites[(p)]; (s)++)
 
 #define for_each_crtc(dev, crtc) \
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6b6fff1..06bb8cd 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -238,7 +238,7 @@ static bool ivb_can_enable_err_int(struct drm_device

[Intel-gfx] [PATCH v4 2/5] drm/i915: fix HPD IRQ reenable work cancelation

[Imre Deak]

Atm, the HPD IRQ reenable timer can get rearmed right after it's
canceled. Also to access the HPD IRQ mask registers we need to wake up
the HW.

Solve both issues by converting the reenable timer to a delayed work and
grabbing a runtime PM reference in the work. By this we can also forgo
canceling the timer during runtime suspend, since the only important
thing there is that the HW is awake when we write the registers and
that's ensured by the RPM ref. So do the cancelation only during driver
unload time; this is also a requirement for an upcoming patch where we
want to cancel all HPD related works only during system suspend and
driver unload time, but not during runtime suspend.

Note that there is still a race between the HPD IRQ reenable work and
drm_irq_uninstall() during driver unload, where the work can reenable
the HPD IRQs disabled by drm_irq_uninstall(). This isn't a problem since
the HPD IRQs will still be effectively masked by the first level
interrupt mask.

v2-3:
- unchanged
v4:
- use proper API for changing the expiration time for an already pending
  delayed work (Jani)

Signed-off-by: Imre Deak 
Reviewed-by: Ville Syrjälä  (v2)
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 drivers/gpu/drm/i915/i915_irq.c  | 33 -
 drivers/gpu/drm/i915/intel_display.c |  1 +
 3 files changed, 14 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4412f6a..1263aac 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1458,7 +1458,7 @@ struct drm_i915_private {
} hpd_mark;
} hpd_stats[HPD_NUM_PINS];
u32 hpd_event_bits;
-   struct timer_list hotplug_reenable_timer;
+   struct delayed_work hotplug_reenable_work;
 
struct i915_fbc fbc;
struct i915_drrs drrs;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 390ccc2..718aa5e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1189,8 +1189,8 @@ static void i915_hotplug_work_func(struct work_struct 
*work)
  * some connectors */
if (hpd_disabled) {
drm_kms_helper_poll_enable(dev);
-   mod_timer(&dev_priv->hotplug_reenable_timer,
- jiffies + 
msecs_to_jiffies(I915_REENABLE_HOTPLUG_DELAY));
+   mod_delayed_work(system_wq, &dev_priv->hotplug_reenable_work,
+ msecs_to_jiffies(I915_REENABLE_HOTPLUG_DELAY));
}
 
spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
@@ -1213,11 +1213,6 @@ static void i915_hotplug_work_func(struct work_struct 
*work)
drm_kms_helper_hotplug_event(dev);
 }
 
-static void intel_hpd_irq_uninstall(struct drm_i915_private *dev_priv)
-{
-   del_timer_sync(&dev_priv->hotplug_reenable_timer);
-}
-
 static void ironlake_rps_change_irq_handler(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -3892,8 +3887,6 @@ static void gen8_irq_uninstall(struct drm_device *dev)
if (!dev_priv)
return;
 
-   intel_hpd_irq_uninstall(dev_priv);
-
gen8_irq_reset(dev);
 }
 
@@ -3908,8 +3901,6 @@ static void valleyview_irq_uninstall(struct drm_device 
*dev)
 
I915_WRITE(VLV_MASTER_IER, 0);
 
-   intel_hpd_irq_uninstall(dev_priv);
-
for_each_pipe(pipe)
I915_WRITE(PIPESTAT(pipe), 0x);
 
@@ -3988,8 +3979,6 @@ static void ironlake_irq_uninstall(struct drm_device *dev)
if (!dev_priv)
return;
 
-   intel_hpd_irq_uninstall(dev_priv);
-
ironlake_irq_reset(dev);
 }
 
@@ -4360,8 +4349,6 @@ static void i915_irq_uninstall(struct drm_device * dev)
struct drm_i915_private *dev_priv = dev->dev_private;
int pipe;
 
-   intel_hpd_irq_uninstall(dev_priv);
-
if (I915_HAS_HOTPLUG(dev)) {
I915_WRITE(PORT_HOTPLUG_EN, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
@@ -4598,8 +4585,6 @@ static void i965_irq_uninstall(struct drm_device * dev)
if (!dev_priv)
return;
 
-   intel_hpd_irq_uninstall(dev_priv);
-
I915_WRITE(PORT_HOTPLUG_EN, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
 
@@ -4615,14 +4600,18 @@ static void i965_irq_uninstall(struct drm_device * dev)
I915_WRITE(IIR, I915_READ(IIR));
 }
 
-static void intel_hpd_irq_reenable(unsigned long data)
+static void intel_hpd_irq_reenable(struct work_struct *work)
 {
-   struct drm_i915_private *dev_priv = (struct drm_i915_private *)data;
+   struct drm_i915_private *dev_priv =
+   container_of(work, typeof(*dev_priv),
+hotplug_reenable_work.work);
struct drm_device *dev = dev_priv->dev;
struct drm_mode_config *mode_config = &dev->mode_config;
unsigned long irqflags;
int i;

Re: [Intel-gfx] [PATCH v3 2/5] drm/i915: fix HPD IRQ reenable work cancelation

[Jani Nikula]

On Mon, 18 Aug 2014, Imre Deak  wrote:
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 390ccc2..8a5a03f 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1189,8 +1189,8 @@ static void i915_hotplug_work_func(struct work_struct 
> *work)
> * some connectors */
>   if (hpd_disabled) {
>   drm_kms_helper_poll_enable(dev);
> - mod_timer(&dev_priv->hotplug_reenable_timer,
> -   jiffies + 
> msecs_to_jiffies(I915_REENABLE_HOTPLUG_DELAY));
> + schedule_delayed_work(&dev_priv->hotplug_reenable_work,
> +   msecs_to_jiffies(I915_REENABLE_HOTPLUG_DELAY));
>   }

As we discussed face to face, there's a semantic change here, and a
lesson worth repeating on the list. If the timer is pending, mod_timer()
will update the expiry time. However, if the delayed work is pending,
schedule_delayed_work() will *not* update the expiry time.

I guess you need to be bitten by this to remember... been there done
that. ;) Happily there's no need to work around this anymore since

commit 8376fe22c7e79c7e90857d39f82aeae6cad6c4b8
Author: Tejun Heo 
Date:   Fri Aug 3 10:30:47 2012 -0700

workqueue: implement mod_delayed_work[_on]()

and you can use mod_delayed_work().


BR,
Jani.


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

[Intel-gfx] [PATCH v3 4/5] drm/i915: make sure VDD is turned off during system suspend

[Imre Deak]

Atm we may leave eDP VDD enabled during system suspend after the CRTCs
are disabled through an HPD->DPCD read event. So disable VDD during
suspend at a point when no HPDs can occur.

Note that runtime suspend doesn't have the same problem, since there the
RPM ref held by VDD provides already the needed serialization.

v2:
- add note to commit message about the runtime suspend path (Ville)
- use edp_panel_vdd_off_sync(), so we can keep the WARN in
  edp_panel_vdd_off() (Ville)
v3:
- rebased on -fixes (for_each_intel_encoder()->list_for_each_entry())
  (Imre)

Signed-off-by: Imre Deak 
Reviewed-by: Ville Syrjälä  (v2)
[rebased on -fixes (Imre)] (v3)
---
 drivers/gpu/drm/i915/i915_drv.c  | 17 +
 drivers/gpu/drm/i915/intel_dp.c  | 11 +++
 drivers/gpu/drm/i915/intel_drv.h |  6 ++
 3 files changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3f9c8f6..e27cdbe 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -509,6 +509,21 @@ void intel_hpd_cancel_work(struct drm_i915_private 
*dev_priv)
cancel_delayed_work_sync(&dev_priv->hotplug_reenable_work);
 }
 
+static void intel_suspend_encoders(struct drm_i915_private *dev_priv)
+{
+   struct drm_device *dev = dev_priv->dev;
+   struct drm_encoder *encoder;
+
+   drm_modeset_lock_all(dev);
+   list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
+   struct intel_encoder *intel_encoder = to_intel_encoder(encoder);
+
+   if (intel_encoder->suspend)
+   intel_encoder->suspend(intel_encoder);
+   }
+   drm_modeset_unlock_all(dev);
+}
+
 static int i915_drm_freeze(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -555,6 +570,8 @@ static int i915_drm_freeze(struct drm_device *dev)
intel_runtime_pm_disable_interrupts(dev);
intel_hpd_cancel_work(dev_priv);
 
+   intel_suspend_encoders(dev_priv);
+
intel_suspend_gt_powersave(dev);
 
intel_modeset_suspend_hw(dev);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a520188..e31ac9e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4003,6 +4003,16 @@ void intel_dp_encoder_destroy(struct drm_encoder 
*encoder)
kfree(intel_dig_port);
 }
 
+void intel_dp_encoder_suspend(struct intel_encoder *intel_encoder)
+{
+   struct intel_dp *intel_dp = enc_to_intel_dp(&intel_encoder->base);
+
+   if (!is_edp(intel_dp))
+   return;
+
+   edp_panel_vdd_off_sync(intel_dp);
+}
+
 static void intel_dp_encoder_reset(struct drm_encoder *encoder)
 {
intel_edp_panel_vdd_sanitize(to_intel_encoder(encoder));
@@ -4731,6 +4741,7 @@ intel_dp_init(struct drm_device *dev, int output_reg, 
enum port port)
intel_encoder->disable = intel_disable_dp;
intel_encoder->get_hw_state = intel_dp_get_hw_state;
intel_encoder->get_config = intel_dp_get_config;
+   intel_encoder->suspend = intel_dp_encoder_suspend;
if (IS_CHERRYVIEW(dev)) {
intel_encoder->pre_pll_enable = chv_dp_pre_pll_enable;
intel_encoder->pre_enable = chv_pre_enable_dp;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index fe3431f..b8c8bbd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -153,6 +153,12 @@ struct intel_encoder {
 * be set correctly before calling this function. */
void (*get_config)(struct intel_encoder *,
   struct intel_crtc_config *pipe_config);
+   /*
+* Called during system suspend after all pending requests for the
+* encoder are flushed (for example for DP AUX transactions) and
+* device interrupts are disabled.
+*/
+   void (*suspend)(struct intel_encoder *);
int crtc_mask;
enum hpd_pin hpd_pin;
 };
-- 
1.8.4

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

[Intel-gfx] [PATCH v3 5/5] drm/i915: don't try to retrain a DP link on an inactive CRTC

[Imre Deak]

Atm we may retrain the DP link even if the CRTC is inactive through
HPD work->intel_dp_check_link_status(). This in turn can lock up the PHY
(at least on BYT), since the DP port is disabled.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81948
Signed-off-by: Imre Deak 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e31ac9e..99064f9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3553,6 +3553,9 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
if (WARN_ON(!intel_encoder->base.crtc))
return;
 
+   if (!to_intel_crtc(intel_encoder->base.crtc)->active)
+   return;
+
/* Try to read receiver status if the link appears to be up */
if (!intel_dp_get_link_status(intel_dp, link_status)) {
return;
-- 
1.8.4

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

[Intel-gfx] [PATCH v3 2/5] drm/i915: fix HPD IRQ reenable work cancelation

[Imre Deak]

Atm, the HPD IRQ reenable timer can get rearmed right after it's
canceled. Also to access the HPD IRQ mask registers we need to wake up
the HW.

Solve both issues by converting the reenable timer to a delayed work and
grabbing a runtime PM reference in the work. By this we can also forgo
canceling the timer during runtime suspend, since the only important
thing there is that the HW is awake when we write the registers and
that's ensured by the RPM ref. So do the cancelation only during driver
unload time; this is also a requirement for an upcoming patch where we
want to cancel all HPD related works only during system suspend and
driver unload time, but not during runtime suspend.

Note that there is still a race between the HPD IRQ reenable work and
drm_irq_uninstall() during driver unload, where the work can reenable
the HPD IRQs disabled by drm_irq_uninstall(). This isn't a problem since
the HPD IRQs will still be effectively masked by the first level
interrupt mask.

Signed-off-by: Imre Deak 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 drivers/gpu/drm/i915/i915_irq.c  | 33 -
 drivers/gpu/drm/i915/intel_display.c |  1 +
 3 files changed, 14 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4412f6a..1263aac 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1458,7 +1458,7 @@ struct drm_i915_private {
} hpd_mark;
} hpd_stats[HPD_NUM_PINS];
u32 hpd_event_bits;
-   struct timer_list hotplug_reenable_timer;
+   struct delayed_work hotplug_reenable_work;
 
struct i915_fbc fbc;
struct i915_drrs drrs;
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 390ccc2..8a5a03f 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1189,8 +1189,8 @@ static void i915_hotplug_work_func(struct work_struct 
*work)
  * some connectors */
if (hpd_disabled) {
drm_kms_helper_poll_enable(dev);
-   mod_timer(&dev_priv->hotplug_reenable_timer,
- jiffies + 
msecs_to_jiffies(I915_REENABLE_HOTPLUG_DELAY));
+   schedule_delayed_work(&dev_priv->hotplug_reenable_work,
+ msecs_to_jiffies(I915_REENABLE_HOTPLUG_DELAY));
}
 
spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
@@ -1213,11 +1213,6 @@ static void i915_hotplug_work_func(struct work_struct 
*work)
drm_kms_helper_hotplug_event(dev);
 }
 
-static void intel_hpd_irq_uninstall(struct drm_i915_private *dev_priv)
-{
-   del_timer_sync(&dev_priv->hotplug_reenable_timer);
-}
-
 static void ironlake_rps_change_irq_handler(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -3892,8 +3887,6 @@ static void gen8_irq_uninstall(struct drm_device *dev)
if (!dev_priv)
return;
 
-   intel_hpd_irq_uninstall(dev_priv);
-
gen8_irq_reset(dev);
 }
 
@@ -3908,8 +3901,6 @@ static void valleyview_irq_uninstall(struct drm_device 
*dev)
 
I915_WRITE(VLV_MASTER_IER, 0);
 
-   intel_hpd_irq_uninstall(dev_priv);
-
for_each_pipe(pipe)
I915_WRITE(PIPESTAT(pipe), 0x);
 
@@ -3988,8 +3979,6 @@ static void ironlake_irq_uninstall(struct drm_device *dev)
if (!dev_priv)
return;
 
-   intel_hpd_irq_uninstall(dev_priv);
-
ironlake_irq_reset(dev);
 }
 
@@ -4360,8 +4349,6 @@ static void i915_irq_uninstall(struct drm_device * dev)
struct drm_i915_private *dev_priv = dev->dev_private;
int pipe;
 
-   intel_hpd_irq_uninstall(dev_priv);
-
if (I915_HAS_HOTPLUG(dev)) {
I915_WRITE(PORT_HOTPLUG_EN, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
@@ -4598,8 +4585,6 @@ static void i965_irq_uninstall(struct drm_device * dev)
if (!dev_priv)
return;
 
-   intel_hpd_irq_uninstall(dev_priv);
-
I915_WRITE(PORT_HOTPLUG_EN, 0);
I915_WRITE(PORT_HOTPLUG_STAT, I915_READ(PORT_HOTPLUG_STAT));
 
@@ -4615,14 +4600,18 @@ static void i965_irq_uninstall(struct drm_device * dev)
I915_WRITE(IIR, I915_READ(IIR));
 }
 
-static void intel_hpd_irq_reenable(unsigned long data)
+static void intel_hpd_irq_reenable(struct work_struct *work)
 {
-   struct drm_i915_private *dev_priv = (struct drm_i915_private *)data;
+   struct drm_i915_private *dev_priv =
+   container_of(work, typeof(*dev_priv),
+hotplug_reenable_work.work);
struct drm_device *dev = dev_priv->dev;
struct drm_mode_config *mode_config = &dev->mode_config;
unsigned long irqflags;
int i;
 
+   intel_runtime_pm_get(dev_priv);
+
spin_lock_irqsave(&dev_priv->irq_lock, irqflags);
for (i = (HPD_NONE

[Intel-gfx] [PATCH v3 3/5] drm/i915: cancel hotplug and dig_port work during suspend and unload

[Imre Deak]

Make sure these work handlers don't run after we system suspend or
unload the driver. Note that we don't cancel the handlers during runtime
suspend. That could lead to a lockup, since we take a runtime PM ref
from the handlers themselves. Fortunaltely canceling there is not needed
since the RPM ref itself provides for the needed serialization.

v2:
- fix the order of canceling dig_port_work wrt. hotplug_work (Ville)
- zero out {long,short}_hpd_port_mask and hpd_event_bits for speed
  (Ville)

Signed-off-by: Imre Deak 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.c  | 16 
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/intel_display.c |  3 +--
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ec96f9a..3f9c8f6 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -494,6 +494,21 @@ bool i915_semaphore_is_enabled(struct drm_device *dev)
return true;
 }
 
+void intel_hpd_cancel_work(struct drm_i915_private *dev_priv)
+{
+   spin_lock_irq(&dev_priv->irq_lock);
+
+   dev_priv->long_hpd_port_mask = 0;
+   dev_priv->short_hpd_port_mask = 0;
+   dev_priv->hpd_event_bits = 0;
+
+   spin_unlock_irq(&dev_priv->irq_lock);
+
+   cancel_work_sync(&dev_priv->dig_port_work);
+   cancel_work_sync(&dev_priv->hotplug_work);
+   cancel_delayed_work_sync(&dev_priv->hotplug_reenable_work);
+}
+
 static int i915_drm_freeze(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -538,6 +553,7 @@ static int i915_drm_freeze(struct drm_device *dev)
flush_delayed_work(&dev_priv->rps.delayed_resume_work);
 
intel_runtime_pm_disable_interrupts(dev);
+   intel_hpd_cancel_work(dev_priv);
 
intel_suspend_gt_powersave(dev);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1263aac..7a830ea 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2178,6 +2178,7 @@ extern unsigned long i915_mch_val(struct drm_i915_private 
*dev_priv);
 extern unsigned long i915_gfx_val(struct drm_i915_private *dev_priv);
 extern void i915_update_gfx_val(struct drm_i915_private *dev_priv);
 int vlv_force_gfx_clock(struct drm_i915_private *dev_priv, bool on);
+void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
 
 extern void intel_console_resume(struct work_struct *work);
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bcf8d18..d074d70 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13103,8 +13103,7 @@ void intel_modeset_cleanup(struct drm_device *dev)
 * experience fancy races otherwise.
 */
drm_irq_uninstall(dev);
-   cancel_work_sync(&dev_priv->hotplug_work);
-   cancel_delayed_work_sync(&dev_priv->hotplug_reenable_work);
+   intel_hpd_cancel_work(dev_priv);
dev_priv->pm._irqs_disabled = true;
 
/*
-- 
1.8.4

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

[Intel-gfx] [PATCH v3 1/5] drm/i915: take display port power domain in DP HPD handler

[Imre Deak]

Ville noticed that we can call ibx_digital_port_connected() which accesses
the HW without holding any power well/runtime pm reference. Fix this by
holding a display port power domain reference around the whole hpd_pulse
handler.

Signed-off-by: Imre Deak 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_dp.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index ee3942f..a520188 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4037,15 +4037,21 @@ bool
 intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
 {
struct intel_dp *intel_dp = &intel_dig_port->dp;
+   struct intel_encoder *intel_encoder = &intel_dig_port->base;
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   int ret;
+   enum intel_display_power_domain power_domain;
+   bool ret = true;
+
if (intel_dig_port->base.type != INTEL_OUTPUT_EDP)
intel_dig_port->base.type = INTEL_OUTPUT_DISPLAYPORT;
 
DRM_DEBUG_KMS("got hpd irq on port %d - %s\n", intel_dig_port->port,
  long_hpd ? "long" : "short");
 
+   power_domain = intel_display_port_power_domain(intel_encoder);
+   intel_display_power_get(dev_priv, power_domain);
+
if (long_hpd) {
if (!ibx_digital_port_connected(dev_priv, intel_dig_port))
goto mst_fail;
@@ -4061,8 +4067,7 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
 
} else {
if (intel_dp->is_mst) {
-   ret = intel_dp_check_mst_status(intel_dp);
-   if (ret == -EINVAL)
+   if (intel_dp_check_mst_status(intel_dp) == -EINVAL)
goto mst_fail;
}
 
@@ -4076,7 +4081,8 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
drm_modeset_unlock(&dev->mode_config.connection_mutex);
}
}
-   return false;
+   ret = false;
+   goto put_power;
 mst_fail:
/* if we were in MST mode, and device is not there get out of MST mode 
*/
if (intel_dp->is_mst) {
@@ -4084,7 +4090,10 @@ mst_fail:
intel_dp->is_mst = false;
drm_dp_mst_topology_mgr_set_mst(&intel_dp->mst_mgr, 
intel_dp->is_mst);
}
-   return true;
+put_power:
+   intel_display_power_put(dev_priv, power_domain);
+
+   return ret;
 }
 
 /* Return which DP Port should be selected for Transcoder DP control */
-- 
1.8.4

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

[Intel-gfx] [PATCH v2 4/4] drm/i915: Clear TX FIFO reset master override bits on chv

[ville . syrjala]

From: Ville Syrjälä 

Clear the override bits to make sure the hardware maanages
the TX FIFO reset master on its own.

v2: Squash with the earlier attempt at forcing the override bits

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h   | 12 
 drivers/gpu/drm/i915/intel_dp.c   |  9 +
 drivers/gpu/drm/i915/intel_hdmi.c |  9 +
 3 files changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b8e8d33..daac02b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -784,6 +784,8 @@ enum punit_power_well {
 #define _VLV_PCS_DW0_CH1   0x8400
 #define   DPIO_PCS_TX_LANE2_RESET  (1<<16)
 #define   DPIO_PCS_TX_LANE1_RESET  (1<<7)
+#define   DPIO_LEFT_TXFIFO_RST_MASTER2 (1<<4)
+#define   DPIO_RIGHT_TXFIFO_RST_MASTER2(1<<3)
 #define VLV_PCS_DW0(ch) _PORT(ch, _VLV_PCS_DW0_CH0, _VLV_PCS_DW0_CH1)
 
 #define _VLV_PCS01_DW0_CH0 0x200
@@ -860,8 +862,18 @@ enum punit_power_well {
 
 #define _VLV_PCS_DW11_CH0  0x822c
 #define _VLV_PCS_DW11_CH1  0x842c
+#define   DPIO_LANEDESKEW_STRAP_OVRD   (1<<3)
+#define   DPIO_LEFT_TXFIFO_RST_MASTER  (1<<1)
+#define   DPIO_RIGHT_TXFIFO_RST_MASTER (1<<0)
 #define VLV_PCS_DW11(ch) _PORT(ch, _VLV_PCS_DW11_CH0, _VLV_PCS_DW11_CH1)
 
+#define _VLV_PCS01_DW11_CH00x022c
+#define _VLV_PCS23_DW11_CH00x042c
+#define _VLV_PCS01_DW11_CH10x262c
+#define _VLV_PCS23_DW11_CH10x282c
+#define VLV_PCS01_DW11(ch) _PORT(ch, _VLV_PCS01_DW0_CH0, _VLV_PCS01_DW0_CH1)
+#define VLV_PCS23_DW11(ch) _PORT(ch, _VLV_PCS23_DW0_CH0, _VLV_PCS23_DW0_CH1)
+
 #define _VLV_PCS_DW12_CH0  0x8230
 #define _VLV_PCS_DW12_CH1  0x8430
 #define VLV_PCS_DW12(ch) _PORT(ch, _VLV_PCS_DW12_CH0, _VLV_PCS_DW12_CH1)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f8e4578..4f69648 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2223,6 +2223,15 @@ static void chv_pre_enable_dp(struct intel_encoder 
*encoder)
 
mutex_lock(&dev_priv->dpio_lock);
 
+   /* allow hardware to manage TX FIFO reset source */
+   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW11(ch));
+   val &= ~DPIO_LANEDESKEW_STRAP_OVRD;
+   vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW11(ch), val);
+
+   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW11(ch));
+   val &= ~DPIO_LANEDESKEW_STRAP_OVRD;
+   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW11(ch), val);
+
/* Deassert soft data lane reset*/
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(ch));
val |= CHV_PCS_REQ_SOFTRESET_EN;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index f3bf0c7..f0cff45 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1378,6 +1378,15 @@ static void chv_hdmi_pre_enable(struct intel_encoder 
*encoder)
 
mutex_lock(&dev_priv->dpio_lock);
 
+   /* allow hardware to manage TX FIFO reset source */
+   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW11(ch));
+   val &= ~DPIO_LANEDESKEW_STRAP_OVRD;
+   vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW11(ch), val);
+
+   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW11(ch));
+   val &= ~DPIO_LANEDESKEW_STRAP_OVRD;
+   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW11(ch), val);
+
/* Deassert soft data lane reset*/
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(ch));
val |= CHV_PCS_REQ_SOFTRESET_EN;
-- 
1.8.5.5

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

[Intel-gfx] [PATCH 1/4] drm/i915: Warn about odd rps values on CHV

[ville . syrjala]

From: Ville Syrjälä 

CHV wants even rps opcodes so print a warning of the
min/max/rpe/rp1 values are odd, and warn if an odd value
slips through to valleyview_set_rps() and truncate it to
an even value.

Also add a comment to chv_freq_opcode() to make sure no one
changes the code without considering this requirement.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_pm.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c8f744c..c84ad93 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3453,6 +3453,10 @@ void valleyview_set_rps(struct drm_device *dev, u8 val)
 dev_priv->rps.cur_freq,
 vlv_gpu_freq(dev_priv, val), val);
 
+   if (WARN_ONCE(IS_CHERRYVIEW(dev) && (val & 1),
+ "Odd GPU freq value\n"))
+   val &= ~1;
+
if (val != dev_priv->rps.cur_freq)
vlv_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ, val);
 
@@ -4149,6 +4153,12 @@ static void cherryview_init_gt_powersave(struct 
drm_device *dev)
 vlv_gpu_freq(dev_priv, dev_priv->rps.min_freq),
 dev_priv->rps.min_freq);
 
+   WARN_ONCE((dev_priv->rps.max_freq |
+  dev_priv->rps.efficient_freq |
+  dev_priv->rps.rp1_freq |
+  dev_priv->rps.min_freq) & 1,
+ "Odd GPU freq values\n");
+
/* Preserve min/max settings in case of re-init */
if (dev_priv->rps.max_freq_softlimit == 0)
dev_priv->rps.max_freq_softlimit = dev_priv->rps.max_freq;
@@ -7443,6 +7453,7 @@ static int chv_freq_opcode(struct drm_i915_private 
*dev_priv, int val)
return -1;
}
 
+   /* CHV needs even values */
opcode = (DIV_ROUND_CLOSEST((val * 2 * mul), dev_priv->rps.cz_freq) * 
2);
 
return opcode;
-- 
1.8.5.5

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

[Intel-gfx] [PATCH 0/4] drm/i915: A few CHV stragglers

[ville . syrjala]

From: Ville Syrjälä 

Here are a few remaining CHV patches from the big series [1].
I reworked some of these a bit.

The remaining patches from the big series are all power sequencer related,
and I'm currently reworking those too. Will post them separately once I have
something decent.

[1] http://lists.freedesktop.org/archives/intel-gfx/2014-June/048132.html

Ville Syrjälä (4):
  drm/i915: Warn about odd rps values on CHV
  drm/i915: Populate mem_freq in init_gt_powerwave()
  drm/i915: Make sure hardware uses the correct swing margin/deemph bits
on chv
  drm/i915: Clear TX FIFO reset master override bits on chv

 drivers/gpu/drm/i915/i915_reg.h   |  37 +++---
 drivers/gpu/drm/i915/intel_dp.c   |  23 +
 drivers/gpu/drm/i915/intel_hdmi.c |  23 +
 drivers/gpu/drm/i915/intel_pm.c   | 101 --
 4 files changed, 131 insertions(+), 53 deletions(-)

-- 
1.8.5.5

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

[Intel-gfx] [PATCH 3/4] drm/i915: Make sure hardware uses the correct swing margin/deemph bits on chv

[ville . syrjala]

From: Ville Syrjälä 

The register can house two different swing marging/deemph settings at
once. However only one gets used based on some other bits. Make sure we
set those bits correctly to make the hardware use the settings we
provided.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h   | 19 +++
 drivers/gpu/drm/i915/intel_dp.c   | 14 ++
 drivers/gpu/drm/i915/intel_hdmi.c | 14 ++
 3 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2df946d..b8e8d33 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -824,12 +824,31 @@ enum punit_power_well {
 
 #define _VLV_PCS_DW9_CH0   0x8224
 #define _VLV_PCS_DW9_CH1   0x8424
+#define   DPIO_PCS_TX2MARGIN_MASK  (0x7<<13)
+#define   DPIO_PCS_TX2MARGIN_000   (0<<13)
+#define   DPIO_PCS_TX2MARGIN_101   (1<<13)
+#define   DPIO_PCS_TX1MARGIN_MASK  (0x7<<10)
+#define   DPIO_PCS_TX1MARGIN_000   (0<<10)
+#define   DPIO_PCS_TX1MARGIN_101   (1<<10)
 #defineVLV_PCS_DW9(ch) _PORT(ch, _VLV_PCS_DW9_CH0, _VLV_PCS_DW9_CH1)
 
+#define _VLV_PCS01_DW9_CH0 0x224
+#define _VLV_PCS23_DW9_CH0 0x424
+#define _VLV_PCS01_DW9_CH1 0x2624
+#define _VLV_PCS23_DW9_CH1 0x2824
+#define VLV_PCS01_DW9(ch) _PORT(ch, _VLV_PCS01_DW9_CH0, _VLV_PCS01_DW9_CH1)
+#define VLV_PCS23_DW9(ch) _PORT(ch, _VLV_PCS23_DW9_CH0, _VLV_PCS23_DW9_CH1)
+
 #define _CHV_PCS_DW10_CH0  0x8228
 #define _CHV_PCS_DW10_CH1  0x8428
 #define   DPIO_PCS_SWING_CALC_TX0_TX2  (1<<30)
 #define   DPIO_PCS_SWING_CALC_TX1_TX3  (1<<31)
+#define   DPIO_PCS_TX2DEEMP_MASK   (0xf<<24)
+#define   DPIO_PCS_TX2DEEMP_9P5(0<<24)
+#define   DPIO_PCS_TX2DEEMP_6P0(2<<24)
+#define   DPIO_PCS_TX1DEEMP_MASK   (0xf<<16)
+#define   DPIO_PCS_TX1DEEMP_9P5(0<<16)
+#define   DPIO_PCS_TX1DEEMP_6P0(2<<16)
 #define CHV_PCS_DW10(ch) _PORT(ch, _CHV_PCS_DW10_CH0, _CHV_PCS_DW10_CH1)
 
 #define _VLV_PCS01_DW10_CH00x0228
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e5ada4f..f8e4578 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2632,12 +2632,26 @@ static uint32_t intel_chv_signal_levels(struct intel_dp 
*intel_dp)
/* Clear calc init */
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW10(ch));
val &= ~(DPIO_PCS_SWING_CALC_TX0_TX2 | DPIO_PCS_SWING_CALC_TX1_TX3);
+   val &= ~(DPIO_PCS_TX1DEEMP_MASK | DPIO_PCS_TX2DEEMP_MASK);
+   val |= DPIO_PCS_TX1DEEMP_9P5 | DPIO_PCS_TX2DEEMP_9P5;
vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW10(ch), val);
 
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW10(ch));
val &= ~(DPIO_PCS_SWING_CALC_TX0_TX2 | DPIO_PCS_SWING_CALC_TX1_TX3);
+   val &= ~(DPIO_PCS_TX1DEEMP_MASK | DPIO_PCS_TX2DEEMP_MASK);
+   val |= DPIO_PCS_TX1DEEMP_9P5 | DPIO_PCS_TX2DEEMP_9P5;
vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW10(ch), val);
 
+   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW9(ch));
+   val &= ~(DPIO_PCS_TX1MARGIN_MASK | DPIO_PCS_TX2MARGIN_MASK);
+   val |= DPIO_PCS_TX1MARGIN_000 | DPIO_PCS_TX2MARGIN_000;
+   vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW9(ch), val);
+
+   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW9(ch));
+   val &= ~(DPIO_PCS_TX1MARGIN_MASK | DPIO_PCS_TX2MARGIN_MASK);
+   val |= DPIO_PCS_TX1MARGIN_000 | DPIO_PCS_TX2MARGIN_000;
+   vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW9(ch), val);
+
/* Program swing deemph */
for (i = 0; i < 4; i++) {
val = vlv_dpio_read(dev_priv, pipe, CHV_TX_DW4(ch, i));
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 9169786..f3bf0c7 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1414,12 +1414,26 @@ static void chv_hdmi_pre_enable(struct intel_encoder 
*encoder)
/* Clear calc init */
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW10(ch));
val &= ~(DPIO_PCS_SWING_CALC_TX0_TX2 | DPIO_PCS_SWING_CALC_TX1_TX3);
+   val &= ~(DPIO_PCS_TX1DEEMP_MASK | DPIO_PCS_TX2DEEMP_MASK);
+   val |= DPIO_PCS_TX1DEEMP_9P5 | DPIO_PCS_TX2DEEMP_9P5;
vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW10(ch), val);
 
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW10(ch));
val &= ~(DPIO_PCS_SWING_CALC_TX0_TX2 | DPIO_PCS_SWING_CALC_TX1_TX3);
+   val &= ~(DPIO_PCS_TX1DEEMP_MASK | DPIO_PCS_TX2DEEMP_MASK);
+   val |= DPIO_PCS_TX1DEEMP_9P5 | DPIO_PCS_TX2DEEMP_9P5;
vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW10(ch), val);
 
+   val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW9(ch));
+   val &= ~(DPIO_PCS_TX1MARGIN_MASK | DPIO_PCS_TX2MARGIN_MASK);
+   val |= DPIO_PCS_TX1MARGIN_000 | DPIO_PCS_TX2MARGIN_000;
+

[Intel-gfx] [PATCH v2 2/4] drm/i915: Populate mem_freq in init_gt_powerwave()

[ville . syrjala]

From: Ville Syrjälä 

init_clock_gating() is too late to read out the mem_freq. We already
want to print out the GPU MHz numbers before it's called. Move the
mem_freq setup to init_gt_powersave().

v2: Also kill the CHV_CZ_CLOCK_FREQ_MODE_* defines

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h |  6 ---
 drivers/gpu/drm/i915/intel_pm.c | 90 -
 2 files changed, 43 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 203062e..2df946d 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5650,12 +5650,6 @@ enum punit_power_well {
 GEN6_PM_RP_DOWN_THRESHOLD | \
 GEN6_PM_RP_DOWN_TIMEOUT)
 
-#define CHV_CZ_CLOCK_FREQ_MODE_200 200
-#define CHV_CZ_CLOCK_FREQ_MODE_267 267
-#define CHV_CZ_CLOCK_FREQ_MODE_320 320
-#define CHV_CZ_CLOCK_FREQ_MODE_333 333
-#define CHV_CZ_CLOCK_FREQ_MODE_400 400
-
 #define GEN7_GT_SCRATCH_BASE   0x4F100
 #define GEN7_GT_SCRATCH_REG_NUM8
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c84ad93..39dd066 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4088,11 +4088,27 @@ static void valleyview_cleanup_pctx(struct drm_device 
*dev)
 static void valleyview_init_gt_powersave(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
+   u32 val;
 
valleyview_setup_pctx(dev);
 
mutex_lock(&dev_priv->rps.hw_lock);
 
+   val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
+   switch ((val >> 6) & 3) {
+   case 0:
+   case 1:
+   dev_priv->mem_freq = 800;
+   break;
+   case 2:
+   dev_priv->mem_freq = 1066;
+   break;
+   case 3:
+   dev_priv->mem_freq = 1333;
+   break;
+   }
+   DRM_DEBUG_DRIVER("DDR speed: %d MHz", dev_priv->mem_freq);
+
dev_priv->rps.max_freq = valleyview_rps_max_freq(dev_priv);
dev_priv->rps.rp0_freq = dev_priv->rps.max_freq;
DRM_DEBUG_DRIVER("max GPU freq: %d MHz (%u)\n",
@@ -4127,11 +4143,38 @@ static void valleyview_init_gt_powersave(struct 
drm_device *dev)
 static void cherryview_init_gt_powersave(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
+   u32 val;
 
cherryview_setup_pctx(dev);
 
mutex_lock(&dev_priv->rps.hw_lock);
 
+   val = vlv_punit_read(dev_priv, CCK_FUSE_REG);
+   switch ((val >> 2) & 0x7) {
+   case 0:
+   case 1:
+   dev_priv->rps.cz_freq = 200;
+   dev_priv->mem_freq = 1600;
+   break;
+   case 2:
+   dev_priv->rps.cz_freq = 267;
+   dev_priv->mem_freq = 1600;
+   break;
+   case 3:
+   dev_priv->rps.cz_freq = 333;
+   dev_priv->mem_freq = 2000;
+   break;
+   case 4:
+   dev_priv->rps.cz_freq = 320;
+   dev_priv->mem_freq = 1600;
+   break;
+   case 5:
+   dev_priv->rps.cz_freq = 400;
+   dev_priv->mem_freq = 1600;
+   break;
+   }
+   DRM_DEBUG_DRIVER("DDR speed: %d MHz", dev_priv->mem_freq);
+
dev_priv->rps.max_freq = cherryview_rps_max_freq(dev_priv);
dev_priv->rps.rp0_freq = dev_priv->rps.max_freq;
DRM_DEBUG_DRIVER("max GPU freq: %d MHz (%u)\n",
@@ -5760,24 +5803,6 @@ static void ivybridge_init_clock_gating(struct 
drm_device *dev)
 static void valleyview_init_clock_gating(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
-   u32 val;
-
-   mutex_lock(&dev_priv->rps.hw_lock);
-   val = vlv_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS);
-   mutex_unlock(&dev_priv->rps.hw_lock);
-   switch ((val >> 6) & 3) {
-   case 0:
-   case 1:
-   dev_priv->mem_freq = 800;
-   break;
-   case 2:
-   dev_priv->mem_freq = 1066;
-   break;
-   case 3:
-   dev_priv->mem_freq = 1333;
-   break;
-   }
-   DRM_DEBUG_DRIVER("DDR speed: %d MHz", dev_priv->mem_freq);
 
I915_WRITE(DSPCLK_GATE_D, VRHUNIT_CLOCK_GATE_DISABLE);
 
@@ -5853,35 +5878,6 @@ static void valleyview_init_clock_gating(struct 
drm_device *dev)
 static void cherryview_init_clock_gating(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = dev->dev_private;
-   u32 val;
-
-   mutex_lock(&dev_priv->rps.hw_lock);
-   val = vlv_punit_read(dev_priv, CCK_FUSE_REG);
-   mutex_unlock(&dev_priv->rps.hw_lock);
-   switch ((val >> 2) & 0x7) {
-   case 0:
-   case 1:
-

Re: [Intel-gfx] Usage of _PAGE_PCD et al in i915 driver

[Juergen Gross]

On 08/18/2014 12:21 PM, Ville Syrjälä wrote:

On Mon, Aug 18, 2014 at 07:31:58AM +0200, Juergen Gross wrote:

On 08/15/2014 12:21 PM, Ville Syrjälä wrote:

On Thu, Aug 14, 2014 at 05:55:11AM +0200, Juergen Gross wrote:

On 08/13/2014 05:07 PM, Jesse Barnes wrote:

On Fri, 8 Aug 2014 15:14:15 +0200
Daniel Vetter  wrote:


Adding relevant mailing lists.

On Fri, Aug 8, 2014 at 1:23 PM, Juergen Gross  wrote:

I'm just about to create a patch for full PAT support in the Linux
kernel, including Xen. For this purpose I introduce a translation
between cache modes and pte bits.

Scanning the kernel sources for usage of the cache mode bits in the
pte I discovered  drivers/gpu/drm/i915/i915_gem_gtt.h is using
_PAGE_PCD, _PAGE_PWT and _PAGE_PAT. I think those defines are used
to create ptes not for usage by the main processor, but for the
graphics processor. Is this true? In this case I'd suggest to define
i915-specific macros instead of using the x86 ones.


Yeah, those are gpu specific PAT tables, but the hw engineers
specifically designed this to match, and we've tried to follow the cpu
side to match it. Especially in the future that will be somewhat
important, since we want to fully share the entire address space
between cpu and gpu on the next platform. Jesse is working on that.


Right, we have an x86 compatible MMU in the GPU itself, so re-using the
defines makes sense.  I suppose with your work you'll move them and
make them a bit more opaque?  If so, we'll still want a way to get at
them directly, or access your mapping functions for generating PTE bits
for the GPU MMU.


Using the mapping functions I'm introducing should work, if the MMU has
an x86 compatible MSR_IA32_CR_PAT which is configured the same way as
on the x86 processor (be aware that Xen is using another MSR_IA32_CR_PAT
setting as the Linux kernel).


We have a PAT that is structured the same way as the x86 PAT. But the
contents of the PAT entries are obviously specific to the GPU so it's
not identical. But the pcd/pwt/pat bits index the PAT in exactly the
same way as on x86.

See bdw_setup_private_ppat() and chv_setup_private_ppat() for how we
set up the PAT.



So you are using the PAT bit in the ptes, but the semantic for the GPU
will be different as for the x86 processor, because the GPU PAT is set
up differently from the x86 one.

In case you are sharing ptes between GPU and x86 processor in future,
this might lead to problems when the x86 processor will use ptes with
the PAT bit set.


I'm not sure why you single out the PAT bit. It's just another index bit
like PCD and PWT.


I single out the PAT bit because all entries of CPU PAT-register and
GPU PAT-register differ with PAT==1. With PAT==0 they are configured
to have the same semantics.


Currently we play around with the GPU caching mode rather freely because
the hardware is already fully coherent wrt. CPU caches (well, apart from
display scanout which knows nothing about any caches). What we do
currently is leave all the CPU mappings as WB and just change the GPU
caching mode depending on the need.


The Xen hypervisor is already using a different PAT configuration than
then Linux Kernel.

So your approach could break Xen when sharing the page tables between
CPU and GPU.


However once we share the page tables I'm not sure what's the plan wrt.
changing the caching mode for GPU buffers since that would involve
changing the CPU cachine mode as well, and we may still want finer
granularity control over the various GPU caches. Maybe we need to
reserve some PAT entries for GPU specific purposes so that the CPU
might have no difference between two PAT entries but the GPU would.
But I'm not sure there are any extra PAT entries left which could be
reserved for such things.


There should be 2 entries left in the PAT-register which could be used
by the GPU, I think: there are only 6 different cache modes defined for
x86 and we have 8 PAT register entries, so at least 2 entries must be
duplicates.


We do have ways to override the GPU caching mode using inline information
in the GPU command buffers though, so in theory at least, it doesn't
matter all that much to the GPU how the page table caching bits are
configured. However not all commands may have such inline caching
information, and we still have the display scanout to worry about which
still relies on the page tables to avoid expensive manual clflushes.




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

Re: [Intel-gfx] [PATCH 1/4] drm/i915: fix HPD IRQ reenable work cancelation

[Jani Nikula]

On Fri, 15 Aug 2014, Imre Deak  wrote:
> On Fri, 2014-08-15 at 12:48 +0300, Jani Nikula wrote:
>> On Fri, 15 Aug 2014, Imre Deak  wrote:
>> > On Wed, 2014-08-13 at 19:33 +0300, Ville Syrjälä wrote:
>> >> The series seems fine to me.
>> >> 
>> >> Reviewed-by: Ville Syrjälä 
>> >> for the rest as well.
>> >
>> > Thanks, I assume it's for v2. I'd say this is for -fixes. The problem
>> > existed even in 3.16, but only the MST support made it apparent with the
>> > extra HPD signaling and DP AUX activity during suspend.
>> 
>> The series no longer applies on any branch. Would you mind respinning on
>> -fixes please?
>
> Ok. I just noticed that it depends on the following two patches that are
> only in -nightly not in -fixes:
>
> "drm/i915: Introduce a for_each_intel_encoder() macro"
> "drm/i915: lock around link status and link training."
>
> Are you going to apply these? The second one is definitely needed in
> -fixes imo.

I've rebased -fixes on top of 3.17-rc1, so the second patch is there
now. However patch 3 still doesn't apply. Also, if we're going to queue
these for stable to fix 3.16, it's easier if we don't depend on
for_each_intel_encoder. Could you rebase this on -fixes now please?

Thanks,
Jani.



-- 
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 i-g-t 1/1] tests: Fix seg fault when gem_mmap is run without specifying a subtest

[Thomas Wood]

On 15 August 2014 22:08, Mason, Michael W  wrote:
> From: Mike Mason 
>

This patch and the previous one (scripts: Allow multiple -t and -x
regular expressions for run-tests.sh) look fine, but they don't apply
because tabs have been converted to spaces. Can you check and re-send
with this fixed?


> gem_mmap seg faults when all tests are run together. This occurs because
> the new-object subtest closes the gem object, but short-mmap assumes
> it still exists. Thus gem_mmap__cpu() returns nil for addr and memset()
> seg faults. This patch makes new-object and short-mmap create and
> close their own gem objects.
>
> Signed-off-by: Mike Mason 
> ---
>  tests/gem_mmap.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tests/gem_mmap.c b/tests/gem_mmap.c
> index 334bd76..33ffe45 100644
> --- a/tests/gem_mmap.c
> +++ b/tests/gem_mmap.c
> @@ -62,10 +62,8 @@ igt_main
> igt_assert(ret == -1 && errno == ENOENT);
> }
>
> -   igt_fixture
> -   handle = gem_create(fd, OBJECT_SIZE);
> -
> igt_subtest("new-object") {
> +   handle = gem_create(fd, OBJECT_SIZE);
> arg.handle = handle;
> arg.offset = 0;
> arg.size = OBJECT_SIZE;
> @@ -94,9 +92,11 @@ igt_main
>
> igt_subtest("short-mmap") {
> igt_assert(OBJECT_SIZE > 4096);
> +   handle = gem_create(fd, OBJECT_SIZE);
> addr = gem_mmap__cpu(fd, handle, 4096, PROT_WRITE);
> memset(addr, 0, 4096);
> munmap(addr, 4096);
> +   gem_close(fd, handle);
> }
>
> igt_fixture
> --
> 1.9.1
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Usage of _PAGE_PCD et al in i915 driver

[Ville Syrjälä]

On Mon, Aug 18, 2014 at 07:31:58AM +0200, Juergen Gross wrote:
> On 08/15/2014 12:21 PM, Ville Syrjälä wrote:
> > On Thu, Aug 14, 2014 at 05:55:11AM +0200, Juergen Gross wrote:
> >> On 08/13/2014 05:07 PM, Jesse Barnes wrote:
> >>> On Fri, 8 Aug 2014 15:14:15 +0200
> >>> Daniel Vetter  wrote:
> >>>
>  Adding relevant mailing lists.
> 
>  On Fri, Aug 8, 2014 at 1:23 PM, Juergen Gross  wrote:
> > I'm just about to create a patch for full PAT support in the Linux
> > kernel, including Xen. For this purpose I introduce a translation
> > between cache modes and pte bits.
> >
> > Scanning the kernel sources for usage of the cache mode bits in the
> > pte I discovered  drivers/gpu/drm/i915/i915_gem_gtt.h is using
> > _PAGE_PCD, _PAGE_PWT and _PAGE_PAT. I think those defines are used
> > to create ptes not for usage by the main processor, but for the
> > graphics processor. Is this true? In this case I'd suggest to define
> > i915-specific macros instead of using the x86 ones.
> 
>  Yeah, those are gpu specific PAT tables, but the hw engineers
>  specifically designed this to match, and we've tried to follow the cpu
>  side to match it. Especially in the future that will be somewhat
>  important, since we want to fully share the entire address space
>  between cpu and gpu on the next platform. Jesse is working on that.
> >>>
> >>> Right, we have an x86 compatible MMU in the GPU itself, so re-using the
> >>> defines makes sense.  I suppose with your work you'll move them and
> >>> make them a bit more opaque?  If so, we'll still want a way to get at
> >>> them directly, or access your mapping functions for generating PTE bits
> >>> for the GPU MMU.
> >>
> >> Using the mapping functions I'm introducing should work, if the MMU has
> >> an x86 compatible MSR_IA32_CR_PAT which is configured the same way as
> >> on the x86 processor (be aware that Xen is using another MSR_IA32_CR_PAT
> >> setting as the Linux kernel).
> >
> > We have a PAT that is structured the same way as the x86 PAT. But the
> > contents of the PAT entries are obviously specific to the GPU so it's
> > not identical. But the pcd/pwt/pat bits index the PAT in exactly the
> > same way as on x86.
> >
> > See bdw_setup_private_ppat() and chv_setup_private_ppat() for how we
> > set up the PAT.
> >
> 
> So you are using the PAT bit in the ptes, but the semantic for the GPU
> will be different as for the x86 processor, because the GPU PAT is set
> up differently from the x86 one.
> 
> In case you are sharing ptes between GPU and x86 processor in future,
> this might lead to problems when the x86 processor will use ptes with
> the PAT bit set.

I'm not sure why you single out the PAT bit. It's just another index bit
like PCD and PWT.

Currently we play around with the GPU caching mode rather freely because
the hardware is already fully coherent wrt. CPU caches (well, apart from
display scanout which knows nothing about any caches). What we do
currently is leave all the CPU mappings as WB and just change the GPU
caching mode depending on the need.

However once we share the page tables I'm not sure what's the plan wrt.
changing the caching mode for GPU buffers since that would involve
changing the CPU cachine mode as well, and we may still want finer
granularity control over the various GPU caches. Maybe we need to
reserve some PAT entries for GPU specific purposes so that the CPU
might have no difference between two PAT entries but the GPU would.
But I'm not sure there are any extra PAT entries left which could be
reserved for such things.

We do have ways to override the GPU caching mode using inline information
in the GPU command buffers though, so in theory at least, it doesn't
matter all that much to the GPU how the page table caching bits are
configured. However not all commands may have such inline caching
information, and we still have the display scanout to worry about which
still relies on the page tables to avoid expensive manual clflushes.

-- 
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] drm/i915: fix suspend/resume for GENs w/o runtime PM support

[Imre Deak]

Before sharing common parts between the system and runtime s/r
handlers we WARNed if the runtime s/r handlers were called on GENs that
didn't support RPM. But this WARN is not correct if the same handler is
called from the system s/r path, since that can happen on any platform.
This also broke system s/r on old platforms.

The issue was introduced in

commit 016970beb05da6285c2f3ed2bee1c676cb75972e
Author: Sagar Kamble 
Date:   Wed Aug 13 23:07:06 2014 +0530

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82751
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_drv.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 117f5c1..f646f34 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -499,7 +499,8 @@ bool i915_semaphore_is_enabled(struct drm_device *dev)
 }
 
 
-static int intel_suspend_complete(struct drm_i915_private *dev_priv);
+static int intel_suspend_complete(struct drm_i915_private *dev_priv,
+ bool rpm_suspend);
 static int intel_resume_prepare(struct drm_i915_private *dev_priv,
bool rpm_resume);
 
@@ -909,7 +910,7 @@ static int i915_pm_suspend_late(struct device *dev)
if (drm_dev->switch_power_state == DRM_SWITCH_POWER_OFF)
return 0;
 
-   ret = intel_suspend_complete(dev_priv);
+   ret = intel_suspend_complete(dev_priv, false);
 
if (ret)
DRM_ERROR("Suspend complete failed: %d\n", ret);
@@ -1410,7 +1411,7 @@ static int intel_runtime_suspend(struct device *device)
cancel_work_sync(&dev_priv->rps.work);
intel_runtime_pm_disable_interrupts(dev);
 
-   ret = intel_suspend_complete(dev_priv);
+   ret = intel_suspend_complete(dev_priv, true);
if (ret) {
DRM_ERROR("Runtime suspend failed, disabling it (%d)\n", ret);
intel_runtime_pm_restore_interrupts(dev);
@@ -1471,10 +1472,11 @@ static int intel_runtime_resume(struct device *device)
  * This function implements common functionality of runtime and system
  * suspend sequence.
  */
-static int intel_suspend_complete(struct drm_i915_private *dev_priv)
+static int intel_suspend_complete(struct drm_i915_private *dev_priv,
+ bool rpm_suspend)
 {
struct drm_device *dev = dev_priv->dev;
-   int ret;
+   int ret = 0;
 
if (IS_GEN6(dev)) {
ret = 0;
@@ -1482,7 +1484,7 @@ static int intel_suspend_complete(struct drm_i915_private 
*dev_priv)
ret = hsw_suspend_complete(dev_priv);
} else if (IS_VALLEYVIEW(dev)) {
ret = vlv_suspend_complete(dev_priv);
-   } else {
+   } else if (rpm_suspend) {
ret = -ENODEV;
WARN_ON(1);
}
@@ -1499,7 +1501,7 @@ static int intel_resume_prepare(struct drm_i915_private 
*dev_priv,
bool rpm_resume)
 {
struct drm_device *dev = dev_priv->dev;
-   int ret;
+   int ret = 0;
 
if (IS_GEN6(dev)) {
ret = snb_resume_prepare(dev_priv, rpm_resume);
@@ -1507,7 +1509,7 @@ static int intel_resume_prepare(struct drm_i915_private 
*dev_priv,
ret = hsw_resume_prepare(dev_priv, rpm_resume);
} else if (IS_VALLEYVIEW(dev)) {
ret = vlv_resume_prepare(dev_priv, rpm_resume);
-   } else {
+   } else if (rpm_resume) {
WARN_ON(1);
ret = -ENODEV;
}
-- 
1.8.4

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

Re: [Intel-gfx] [PATCH] drm/i915: Use dev_priv as first argument of for_each_pipe()

[Chris Wilson]

On Mon, Aug 18, 2014 at 11:00:42AM +0100, Damien Lespiau wrote:
> Chris has decided that enough is enough. It's time to fixup dev Vs
> dev_priv. This is a modest contribution to the crusade.
> 
> v2: Still use INTEL_INFO(), for the (mythical!) case we want to hardcode
> the info struct with defines (Chris)
> Rename the macro argument from 'dev' to 'dev_priv' (Jani)

If you want to be pedantic, don't use a macro name that is often a
variable name.
-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] drm/i915: Use dev_priv as first argument of for_each_pipe()

[Damien Lespiau]

Chris has decided that enough is enough. It's time to fixup dev Vs
dev_priv. This is a modest contribution to the crusade.

v2: Still use INTEL_INFO(), for the (mythical!) case we want to hardcode
the info struct with defines (Chris)
Rename the macro argument from 'dev' to 'dev_priv' (Jani)

Suggested-by: Chris Wilson 
Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 10 +++---
 drivers/gpu/drm/i915/i915_dma.c  |  4 +--
 drivers/gpu/drm/i915/i915_drv.h  |  3 +-
 drivers/gpu/drm/i915/i915_irq.c  | 65 ++--
 drivers/gpu/drm/i915/intel_display.c | 16 +
 drivers/gpu/drm/i915/intel_dp.c  |  2 +-
 drivers/gpu/drm/i915/intel_panel.c   |  2 +-
 drivers/gpu/drm/i915/intel_pm.c  | 17 +-
 8 files changed, 60 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 6c82bda..637143c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -662,7 +662,7 @@ static int i915_interrupt_info(struct seq_file *m, void 
*data)
   I915_READ(VLV_IIR_RW));
seq_printf(m, "Display IMR:\t%08x\n",
   I915_READ(VLV_IMR));
-   for_each_pipe(pipe)
+   for_each_pipe(dev_priv, pipe)
seq_printf(m, "Pipe %c stat:\t%08x\n",
   pipe_name(pipe),
   I915_READ(PIPESTAT(pipe)));
@@ -702,7 +702,7 @@ static int i915_interrupt_info(struct seq_file *m, void 
*data)
   i, I915_READ(GEN8_GT_IER(i)));
}
 
-   for_each_pipe(pipe) {
+   for_each_pipe(dev_priv, pipe) {
if (!intel_display_power_enabled(dev_priv,
POWER_DOMAIN_PIPE(pipe))) {
seq_printf(m, "Pipe %c power disabled\n",
@@ -749,7 +749,7 @@ static int i915_interrupt_info(struct seq_file *m, void 
*data)
   I915_READ(VLV_IIR_RW));
seq_printf(m, "Display IMR:\t%08x\n",
   I915_READ(VLV_IMR));
-   for_each_pipe(pipe)
+   for_each_pipe(dev_priv, pipe)
seq_printf(m, "Pipe %c stat:\t%08x\n",
   pipe_name(pipe),
   I915_READ(PIPESTAT(pipe)));
@@ -785,7 +785,7 @@ static int i915_interrupt_info(struct seq_file *m, void 
*data)
   I915_READ(IIR));
seq_printf(m, "Interrupt mask:  %08x\n",
   I915_READ(IMR));
-   for_each_pipe(pipe)
+   for_each_pipe(dev_priv, pipe)
seq_printf(m, "Pipe %c stat: %08x\n",
   pipe_name(pipe),
   I915_READ(PIPESTAT(pipe)));
@@ -4178,7 +4178,7 @@ void intel_display_crc_init(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
enum pipe pipe;
 
-   for_each_pipe(pipe) {
+   for_each_pipe(dev_priv, pipe) {
struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[pipe];
 
pipe_crc->opened = false;
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 3f676f9..f19dbff 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1528,10 +1528,10 @@ static void intel_device_info_runtime_init(struct 
drm_device *dev)
info = (struct intel_device_info *)&dev_priv->info;
 
if (IS_VALLEYVIEW(dev))
-   for_each_pipe(pipe)
+   for_each_pipe(dev_priv, pipe)
info->num_sprites[pipe] = 2;
else
-   for_each_pipe(pipe)
+   for_each_pipe(dev_priv, pipe)
info->num_sprites[pipe] = 1;
 
if (i915.disable_display) {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4754328..719c7c7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -163,7 +163,8 @@ enum hpd_pin {
 I915_GEM_DOMAIN_INSTRUCTION | \
 I915_GEM_DOMAIN_VERTEX)
 
-#define for_each_pipe(p) for ((p) = 0; (p) < INTEL_INFO(dev)->num_pipes; (p)++)
+#define for_each_pipe(dev_priv, p) \
+   for ((p) = 0; (p) < INTEL_INFO(dev_priv)->num_pipes; (p)++)
 #define for_each_sprite(p, s) for ((s) = 0; (s) < 
INTEL_INFO(dev)->num_sprites[(p)]; (s)++)
 
 #define for_each_crtc(dev, crtc) \
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 6b6fff1..06bb8cd 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -238,7 +238,7 @@ static bool ivb_can_enable_err_int(struct drm_device *dev)
 
assert_spin_locked(&dev_priv->irq_lock);
 
-   for_ea

Re: [Intel-gfx] How to create PCH to support those existing driver

[Michael S. Tsirkin]

On Mon, Aug 18, 2014 at 05:01:25PM +0800, Chen, Tiejun wrote:
> On 2014/8/18 16:21, Michael S. Tsirkin wrote:
> >On Mon, Aug 18, 2014 at 11:06:29AM +0800, Chen, Tiejun wrote:
> >>On 2014/8/17 18:32, Michael S. Tsirkin wrote:
> >>>On Fri, Aug 15, 2014 at 09:58:40AM +0800, Chen, Tiejun wrote:
> Michael and Paolo,
> >>>
> >>>Please re-post discussion on list. These off list ones are just
> >>>wasting time since they invariably have to be repeated on list again.
> >>
> >>Okay, now just reissue this discussion to all related guys. And do you think
> >>we need to discuss in public, qemu and xen mail list?
> >
> >Absolutely.
> 
> Now -CC qemu, xen and intel-gfx.
> 
> If I'm missing someone important please tell me as well.
> 
> >
> >>>
> After I created that new machine specific to IGD passthrough, xenigd, now 
> I
> will step next to register the PCH.
> 
> IIRC, our complete solution should be as follows:
> 
> #1 create a new machine based on piix, xenigd
> 
> This is done with Michael help.
> 
> #2 register ISA bridge
> 
> 1> Its still fixed at 1f.0.
> 2> ISA bridge's vendor_id/device_id should be emulated but then
>   
>   subsystem_vendor_id = PCI_VENDOR_ID_XEN;
>   subsystem_device_id = ISA Bridge's real device id
> 
> This mean we need to change driver to walk with this way.
> For example, in
> case of Linux native driver,
> 
> intel_detect_pch()
> {
>   ...
>   if (pch->subsystem_vendor == PCI_VENDOR_ID_XEN)
>   id = pch->subsystem_device & INTEL_PCH_DEVICE_ID_MASK;
> 
> Then driver can get that real device id by 'subsystem_device', right?
> 
> This is fine now but how to support those existing drivers which are just
> >>
> >>Here correct one point, we don't need to care about supporting the legacy
> >>driver since the legacy driver still should work qemu-traditional. So we
> >>just make sure the existing driver with this subsystem_id way can support
> >>those existing and legacy platform.
> >>
> >>Now this is clear to me.
> >>
> dependent on checking real vendor_id/device_id directly,
> 
>   if (pch->vendor == PCI_VENDOR_ID_INTEL) {
>   unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK
> 
> Maybe I'm missing something, please hint me.
> 
> Thanks
> Tiejun
> >>>
> >>>The subsystem id was just one idea.
> >>
> >>But from that email thread, "RH / Intel Virtualization Engineering Meeting -
> >>Minutes 7/10", I didn't see other idea we should prefer currently.
> >>
> >>>What was finally agreed for future drivers is that guests will get all
> >>>information they need from the video card, this ID hack was needed only
> >>>for very old legacy devices.
> >>>http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/42258
> >>>So this is for newer guests, they will work without need
> >>>for hacks, like any other device.
> >>>
> >>
> >>Actually we had a meeting to discuss our future solution, but seems you were
> >>on vacation at that moment :)
> >>
> >>In that meeting we had an agreement between us and some upstream guys.
> >>
> >>We will have such a PCI capability structure in this PCI device to represent
> >>all information in the future. This make sens to Intel as well.
> >>
> >>Maybe Allen or Paolo known more details.
> >>
> >>But obviously this a long-term solution, so currently we will work with this
> >>subsystem_id way temporarily. And this way is accepted by those guys in the
> >>meeting.
> >
> >
> >I don't see the point really. If you are modifying the driver,
> 
> Yes, we need to modify something in the driver.
> 
> >why not modify it to its final form.
> 
> What's your final form?

Avoid poking at other devices besides the passed through card.
Get everything from BAR and other registers of the card.

> As I track that email thread, seems the follows is just a way you guys
> achieve a better agreement.
> 
> "
> > why not set the subsys vid to the RH/Quamranet/Virtio VID, so it's
> > obvious for the use-match?
> 
> That's exactly the suggestion.  Though upstream they might be using the
> XenSource id since the patches were for Xen.
> 
> Paolo
> "
> Or I'm missing something?
> 
> Thanks
> Tiejun


I thought the point of this work is to make existing
linux/windows drivers work. Is it or isn't it?

Wrt changing drivers, change them to behave sanely, like all other
drivers, and avoid poking at the chipset.
http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/42258
Seems to suggest one way to do this.
Can what is suggested there work for existing devices?


> >
> >>>
> >>>For existing drivers: Vendor ID is intel anyway.
> >>
> >>Yes.
> >>
> >>>For device ID, override it through a property
> >>>or something. But I think poking at the real host from
> >>>qemu is a mistake though, host is not
> >>>protected by iommu.
> >>>Two possible suggestions were to reverse-detect
> >>>id of the device from the card 

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Program PFI credits for VLV

[Vandana Kannan]

Hi Ville,

Apologize for the delay in reply.
For your inputs on the programming side (modeset global resources
handling and self documenting code parts), I agree with you and will
make the changes.
For opens related to info on the feature, internal discussions are
ongoing. I will get back to you on them next week..

Thanks,
Vandana

On Aug-08-2014 6:33 PM, Ville Syrjälä wrote:
> On Thu, Aug 07, 2014 at 06:40:03PM +0530, Vandana Kannan wrote:
>> From: Vidya Srinivas 
>>
>> PFI credit programming is required when CD clock (related to data flow from
>> display pipeline to end display) is greater than CZ clock (related to data
>> flow from memory to display plane). This programming should be done when all
>> planes are OFF to avoid intermittent hangs while accessing memory even from
>> different Gfx units (not just display).
>>
>> If cdclk/czclk >=1, PFI credits could be set as any number. To get better
>> performance, larger PFI credit can be assigned to PND. Otherwise if
>> cdclk/czclk<1, the default PFI credit of 8 should be set.
> 
> Do we have any docs for this? I see the register in the docs but nothing
> about the correct programming. Some kind of refrence to the used
> documentation would be nice.
> 
>>
>> v2:
>> - Change log to lower log level instead of DRM_ERROR
>> - Change function name to valleyview_program_pfi_credits
>> - Move program PFI credits to modeset_init instead of intel_set_mode
>> - Change magic numbers to logical constants
>>
>> Signed-off-by: Vidya Srinivas 
>> Signed-off-by: Gajanan Bhat 
>> Signed-off-by: Vandana Kannan 
>> ---
>>  drivers/gpu/drm/i915/i915_drv.c  |  6 ++
>>  drivers/gpu/drm/i915/i915_drv.h  |  2 ++
>>  drivers/gpu/drm/i915/i915_reg.h  |  5 +
>>  drivers/gpu/drm/i915/intel_display.c |  4 +++-
>>  drivers/gpu/drm/i915/intel_pm.c  | 22 ++
>>  5 files changed, 38 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c 
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index 6c4b25c..00e0b4a 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -558,6 +558,9 @@ static int i915_drm_freeze(struct drm_device *dev)
>>  intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED);
>>  console_unlock();
>>  
>> +if (IS_VALLEYVIEW(dev))
>> +valleyview_program_pfi_credits(dev_priv, false);
> 
> If we want to do this for system suspend I think we should stick it
> into i915_drm_freeze() (just after turning off the pipes). Not sure if
> we should also force cdclk to minimum there...
> 
> Hmm. Is the GCI_CONTROL register is part of the disp2d power well? If it
> is we probably need to enable the power well around the register write.
> 
>> +
>>  dev_priv->suspend_count++;
>>  
>>  intel_display_set_init_power(dev_priv, false);
>> @@ -693,6 +696,9 @@ static int __i915_drm_thaw(struct drm_device *dev, bool 
>> restore_gtt_mappings)
>>  dev_priv->modeset_restore = MODESET_DONE;
>>  mutex_unlock(&dev_priv->modeset_restore_lock);
>>  
>> +if (IS_VALLEYVIEW(dev))
>> +valleyview_program_pfi_credits(dev_priv, true);
> 
> I think this thing can be dropped. We need to do the reprogramming as
> part of the modeset global resources handling.
> 
>> +
>>  intel_opregion_notify_adapter(dev, PCI_D0);
>>  
>>  return 0;
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 881e0a6..88fd4c7 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -2172,6 +2172,8 @@ extern struct i915_params i915 __read_mostly;
>>  
>>  /* i915_dma.c */
>>  void i915_update_dri1_breadcrumb(struct drm_device *dev);
>> +extern void valleyview_program_pfi_credits(struct drm_i915_private 
>> *dev_priv,
>> +   bool flag);
>>  extern void i915_kernel_lost_context(struct drm_device * dev);
>>  extern int i915_driver_load(struct drm_device *, unsigned long flags);
>>  extern int i915_driver_unload(struct drm_device *);
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h 
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index fb111cd..7f4c2f5 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -1937,6 +1937,11 @@ enum punit_power_well {
>>  #define   CZCLK_FREQ_MASK   0xf
>>  #define GMBUSFREQ_VLV   (VLV_DISPLAY_BASE + 0x6510)
>>  
>> +#define GCI_CONTROL (VLV_DISPLAY_BASE + 0x650C)
>> +#define   PFI_CREDIT(7 << 28)
> 
> Maybe something like this for a bit more self documenting code.
> 
> #define PFI_CREDIT(x) (((x)-8) << 28) /* 8-15 */
> 
>> +#define   PFI_CREDIT_RESEND (1 << 27)
>> +#define   VGA_FAST_MODE_DISABLE (1 << 14)
>> +
>>  /*
>>   * Palette regs
>>   */
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 2089319..2af2e60 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/driver

Re: [Intel-gfx] How to create PCH to support those existing driver

[Chen, Tiejun]

On 2014/8/18 16:21, Michael S. Tsirkin wrote:

On Mon, Aug 18, 2014 at 11:06:29AM +0800, Chen, Tiejun wrote:

On 2014/8/17 18:32, Michael S. Tsirkin wrote:

On Fri, Aug 15, 2014 at 09:58:40AM +0800, Chen, Tiejun wrote:

Michael and Paolo,


Please re-post discussion on list. These off list ones are just
wasting time since they invariably have to be repeated on list again.


Okay, now just reissue this discussion to all related guys. And do you think
we need to discuss in public, qemu and xen mail list?


Absolutely.


Now -CC qemu, xen and intel-gfx.

If I'm missing someone important please tell me as well.






After I created that new machine specific to IGD passthrough, xenigd, now I
will step next to register the PCH.

IIRC, our complete solution should be as follows:

#1 create a new machine based on piix, xenigd

This is done with Michael help.

#2 register ISA bridge

1> Its still fixed at 1f.0.
2> ISA bridge's vendor_id/device_id should be emulated but then

subsystem_vendor_id = PCI_VENDOR_ID_XEN;
subsystem_device_id = ISA Bridge's real device id

This mean we need to change driver to walk with this way.
For example, in
case of Linux native driver,

intel_detect_pch()
{
...
if (pch->subsystem_vendor == PCI_VENDOR_ID_XEN)
id = pch->subsystem_device & INTEL_PCH_DEVICE_ID_MASK;

Then driver can get that real device id by 'subsystem_device', right?

This is fine now but how to support those existing drivers which are just


Here correct one point, we don't need to care about supporting the legacy
driver since the legacy driver still should work qemu-traditional. So we
just make sure the existing driver with this subsystem_id way can support
those existing and legacy platform.

Now this is clear to me.


dependent on checking real vendor_id/device_id directly,

if (pch->vendor == PCI_VENDOR_ID_INTEL) {
unsigned short id = pch->device & INTEL_PCH_DEVICE_ID_MASK

Maybe I'm missing something, please hint me.

Thanks
Tiejun


The subsystem id was just one idea.


But from that email thread, "RH / Intel Virtualization Engineering Meeting -
Minutes 7/10", I didn't see other idea we should prefer currently.


What was finally agreed for future drivers is that guests will get all
information they need from the video card, this ID hack was needed only
for very old legacy devices.
http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/42258
So this is for newer guests, they will work without need
for hacks, like any other device.



Actually we had a meeting to discuss our future solution, but seems you were
on vacation at that moment :)

In that meeting we had an agreement between us and some upstream guys.

We will have such a PCI capability structure in this PCI device to represent
all information in the future. This make sens to Intel as well.

Maybe Allen or Paolo known more details.

But obviously this a long-term solution, so currently we will work with this
subsystem_id way temporarily. And this way is accepted by those guys in the
meeting.



I don't see the point really. If you are modifying the driver,


Yes, we need to modify something in the driver.


why not modify it to its final form.


What's your final form?

As I track that email thread, seems the follows is just a way you guys 
achieve a better agreement.


"
> why not set the subsys vid to the RH/Quamranet/Virtio VID, so it's
> obvious for the use-match?

That's exactly the suggestion.  Though upstream they might be using the 
XenSource id since the patches were for Xen.


Paolo
"
Or I'm missing something?

Thanks
Tiejun





For existing drivers: Vendor ID is intel anyway.


Yes.


For device ID, override it through a property
or something. But I think poking at the real host from
qemu is a mistake though, host is not
protected by iommu.
Two possible suggestions were to reverse-detect
id of the device from the card that is assigned,


I guess you're saying pci_get_device(vendor/devices_ids), right?


or just make it a user property, and move the smarts
to management.


Sorry could you elaborate this way in detail?

Thanks
Tiejun



Will do but let's do it on the mailing list.


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

Re: [Intel-gfx] [PATCH 41/43] drm/i915/bdw: Enable Logical Ring Contexts (hence, Execlists)

[Jani Nikula]

On Thu, 24 Jul 2014, Thomas Daniel  wrote:
> From: Oscar Mateo 
>
> The time has come, the Walrus said, to talk of many things.

FYI this causes https://bugs.freedesktop.org/show_bug.cgi?id=82740

> Signed-off-by: Oscar Mateo 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index b7cf0ec..1ce51d6 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2061,7 +2061,7 @@ struct drm_i915_cmd_table {
>  #define I915_NEED_GFX_HWS(dev)   (INTEL_INFO(dev)->need_gfx_hws)
>  
>  #define HAS_HW_CONTEXTS(dev) (INTEL_INFO(dev)->gen >= 6)
> -#define HAS_LOGICAL_RING_CONTEXTS(dev)   0
> +#define HAS_LOGICAL_RING_CONTEXTS(dev)   (INTEL_INFO(dev)->gen >= 8)
>  #define HAS_ALIASING_PPGTT(dev)  (INTEL_INFO(dev)->gen >= 6)
>  #define HAS_PPGTT(dev)   (INTEL_INFO(dev)->gen >= 7 && 
> !IS_GEN8(dev))
>  #define USES_PPGTT(dev)  intel_enable_ppgtt(dev, false)
> -- 
> 1.7.9.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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/bdw: Disable execlists by default

[Jani Nikula]

On Fri, 15 Aug 2014, Damien Lespiau  wrote:
> We still have a few missing bits and pieces to have execlists enabled by
> default eg. the error capture or the render state initialization and so
> it wouldn't be wise to enable it by default on BDW just yet.

Also,

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82740

> Cc: Daniel Vetter 
> Cc: Thomas Daniel 
> Signed-off-by: Damien Lespiau 
> ---
>  drivers/gpu/drm/i915/i915_params.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_params.c 
> b/drivers/gpu/drm/i915/i915_params.c
> index 0886aca..139f490 100644
> --- a/drivers/gpu/drm/i915/i915_params.c
> +++ b/drivers/gpu/drm/i915/i915_params.c
> @@ -35,7 +35,7 @@ struct i915_params i915 __read_mostly = {
>   .vbt_sdvo_panel_type = -1,
>   .enable_rc6 = -1,
>   .enable_fbc = -1,
> - .enable_execlists = -1,
> + .enable_execlists = 0,
>   .enable_hangcheck = true,
>   .enable_ppgtt = -1,
>   .enable_psr = 0,
> @@ -122,7 +122,7 @@ MODULE_PARM_DESC(enable_ppgtt,
>  module_param_named(enable_execlists, i915.enable_execlists, int, 0400);
>  MODULE_PARM_DESC(enable_execlists,
>   "Override execlists usage. "
> - "(-1=auto [default], 0=disabled, 1=enabled)");
> + "(-1=auto, 0=disabled [default], 1=enabled)");
>  
>  module_param_named(enable_psr, i915.enable_psr, int, 0600);
>  MODULE_PARM_DESC(enable_psr, "Enable PSR (default: false)");
> -- 
> 1.8.3.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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: Use dev_priv as first argument of for_each_pipe()

[Jani Nikula]

On Fri, 15 Aug 2014, Damien Lespiau  wrote:
> Chris has decided that enough is enough. It's time to fixup dev Vs
> dev_priv and the, oh so awful, INTEL_INFO(). This is a modest
> contribution to the crusade.


> -#define for_each_pipe(p) for ((p) = 0; (p) < INTEL_INFO(dev)->num_pipes; 
> (p)++)
> +#define for_each_pipe(dev, p) for ((p) = 0; (p) < (dev)->info.num_pipes; 
> (p)++)

Naming the first argument "dev" disagrees with the subject.

BR,
Jani.


-- 
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] [REGRESSION BISECTED] backlight control stops workin with 3.14 and later

[Jani Nikula]

On Sun, 17 Aug 2014, Bertrik Sikken  wrote:
> On 15-8-2014 3:43, Jani Nikula wrote:
>> On Thu, 14 Aug 2014, Bertrik Sikken  wrote:
>
>>> Attached is dmesg output from booting kernel 3.14-2 (debian unstable)
>>> with drm.debug=0xe and the samsung_laptop module enabled, from my
>>> Samsung N150plus netbook.
>> 
>> Have you tried 3.15?
>
> I've built the v3.15 kernel (using the .config file from debian
> unstable and doing make oldconfig).
>
> The backlight is at maximum brightness after boot and I can't control
> it using the backlight buttons, nor by writing to
> /sys/class/backlight/samsung/brightness
> (say half the value or 1/10th of max_brightness)
>
> Backlight does work when writing
> /sys/class/backlight/intel_backlight/brightness

How about disabling samsung backlight module with 3.15?

BR,
Jani.


>
> Kind regards,
> Bertrik Sikken

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