Re: [Intel-gfx] [PATCH 10/12] drm/i915: Compute display surface offset in the plane check hook for SKL+

[Sivakumar Thulasimani]

Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasim...@intel.com>

On Tuesday 03 May 2016 09:09 PM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä <ville.syrj...@linux.intel.com>

SKL has nasty limitations with the display surface offsets:
* source x offset + width must be less than the stride for X tiled
   surfaces or the display engine falls over
* the surface offset requires lots of alignment (256K or 1M)

These facts mean that we can't just pick any suitably aligned tile
boundary as the offset and expect the resulting x offset to be useable.
The solution is to start with the closest boundary as before, but then
keep searhing backwards until we find one that works, or don't. This
means we must be prepared to fail, hence the whole surface offset
calculation needs to be moved to the .check_plane() hook from the
.update_plane() hook.

While at it we can check that the source width/height don't exceed
maximum plane size limits.

We'll store the results of the computation in the plane state to make
it easy for the .update_plane() hook to do its thing.

Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
---
  drivers/gpu/drm/i915/intel_display.c | 164 +--
  drivers/gpu/drm/i915/intel_drv.h |   5 ++
  drivers/gpu/drm/i915/intel_sprite.c  |  33 +++
  3 files changed, 151 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ad7c48757ba6..b3d7d312e57c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2873,6 +2873,120 @@ valid_fb:
obj->frontbuffer_bits |= to_intel_plane(primary)->frontbuffer_bit;
  }
  
+static int skl_max_plane_width(const struct drm_framebuffer *fb, int plane,

+  unsigned int rotation)
+{
+   int cpp = drm_format_plane_cpp(fb->pixel_format, plane);
+
+   switch (fb->modifier[plane]) {
+   case DRM_FORMAT_MOD_NONE:
+   case I915_FORMAT_MOD_X_TILED:
+   switch (cpp) {
+   case 8:
+   return 4096;
+   case 4:
+   case 2:
+   case 1:
+   return 8192;
+   default:
+   MISSING_CASE(cpp);
+   break;
+   }
+   break;
+   case I915_FORMAT_MOD_Y_TILED:
+   case I915_FORMAT_MOD_Yf_TILED:
+   switch (cpp) {
+   case 8:
+   return 2048;
+   case 4:
+   return 4096;
+   case 2:
+   case 1:
+   return 8192;
+   default:
+   MISSING_CASE(cpp);
+   break;
+   }
+   break;
+   default:
+   MISSING_CASE(fb->modifier[plane]);
+   }
+
+   return 2048;
+}
+
+static int skl_check_main_surface(struct intel_plane_state *plane_state)
+{
+   const struct drm_i915_private *dev_priv = 
to_i915(plane_state->base.plane->dev);
+   const struct drm_framebuffer *fb = plane_state->base.fb;
+   unsigned int rotation = plane_state->base.rotation;
+   int x = plane_state->src.x1 >> 16;
+   int y = plane_state->src.y1 >> 16;
+   int w = drm_rect_width(_state->src) >> 16;
+   int h = drm_rect_height(_state->src) >> 16;
+   int max_width = skl_max_plane_width(fb, 0, rotation);
+   int max_height = 4096;
+   u32 alignment, offset;
+
+   if (w > max_width || h > max_height) {
+   DRM_DEBUG_KMS("requested Y/RGB source size %dx%d too big (limit 
%dx%d)\n",
+ w, h, max_width, max_height);
+   return -EINVAL;
+   }
+
+   intel_add_fb_offsets(, , plane_state, 0);
+   offset = intel_compute_tile_offset(, , plane_state, 0);
+
+   alignment = intel_surf_alignment(dev_priv, fb->modifier[0]);
+
+   /*
+* When using an X-tiled surface, the plane blows up
+* if the x offset + width exceed the stride.
+*
+* TODO: linear and Y-tiled seem fine, Yf untested,
+*/
+   if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED) {
+   int cpp = drm_format_plane_cpp(fb->pixel_format, 0);
+
+   for (;;) {
+   if ((x + w) * cpp <= fb->pitches[0])
+   break;
+
+   if (offset == 0) {
+   DRM_DEBUG_KMS("Unable to find suitable display 
surface offset\n");
+   return -EINVAL;
+   }
+
+   offset = intel_adjust_tile_offset(, , plane_state, 
0,
+ offset, offset - 
alignment);
+   }
+   }
+
+   plane_st

Re: [Intel-gfx] [PATCH 09/12] drm/i915: Make intel_adjust_tile_offset() work for linear buffers

[Sivakumar Thulasimani]

Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasim...@intel.com>

On Tuesday 03 May 2016 09:09 PM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä <ville.syrj...@linux.intel.com>

To make life less surprising we can make intel_adjust_tile_offset()
deal with linear buffers as well. Currently it doesn't seem like there's
a real need for this since only X tiling and NV12 (which would always
be tiled currently) should need it. But I've used it for some debug
hacks already so seems like a reasonable thing to have.

Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
---
  drivers/gpu/drm/i915/intel_display.c | 73 
  1 file changed, 57 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 17f9f014e808..ad7c48757ba6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2347,19 +2347,16 @@ void intel_add_fb_offsets(int *x, int *y,
  }
  
  /*

- * Adjust the tile offset by moving the difference into
- * the x/y offsets.
- *
   * Input tile dimensions and pitch must already be
   * rotated to match x and y, and in pixel units.
   */
-static u32 intel_adjust_tile_offset(int *x, int *y,
-   unsigned int tile_width,
-   unsigned int tile_height,
-   unsigned int tile_size,
-   unsigned int pitch_tiles,
-   u32 old_offset,
-   u32 new_offset)
+static u32 _intel_adjust_tile_offset(int *x, int *y,
+unsigned int tile_width,
+unsigned int tile_height,
+unsigned int tile_size,
+unsigned int pitch_tiles,
+u32 old_offset,
+u32 new_offset)
  {
unsigned int pitch_pixels = pitch_tiles * tile_width;
unsigned int tiles;
@@ -2381,6 +2378,50 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
  }
  
  /*

+ * Adjust the tile offset by moving the difference into
+ * the x/y offsets.
+ */
+static u32 intel_adjust_tile_offset(int *x, int *y,
+   const struct intel_plane_state *state, int 
plane,
+   u32 old_offset, u32 new_offset)
+{
+   const struct drm_i915_private *dev_priv = 
to_i915(state->base.plane->dev);
+   const struct drm_framebuffer *fb = state->base.fb;
+   unsigned int cpp = drm_format_plane_cpp(fb->pixel_format, plane);
+   unsigned int rotation = state->base.rotation;
+   unsigned int pitch = intel_fb_pitch(fb, plane, rotation);
+
+   WARN_ON(new_offset > old_offset);
+
+   if (fb->modifier[plane] != DRM_FORMAT_MOD_NONE) {
+   unsigned int tile_size, tile_width, tile_height;
+   unsigned int pitch_tiles;
+
+   tile_size = intel_tile_size(dev_priv);
+   intel_tile_dims(dev_priv, _width, _height,
+   fb->modifier[plane], cpp);
+
+   if (intel_rotation_90_or_270(rotation)) {
+   pitch_tiles = pitch / tile_height;
+   swap(tile_width, tile_height);
+   } else {
+   pitch_tiles = pitch / (tile_width * cpp);
+   }
+
+   _intel_adjust_tile_offset(x, y, tile_width, tile_height,
+ tile_size, pitch_tiles,
+ old_offset, new_offset);
+   } else {
+   old_offset += *y * pitch + *x * cpp;
+
+   *y = (old_offset - new_offset) / pitch;
+   *x = ((old_offset - new_offset) - *y * pitch) / cpp;
+   }
+
+   return new_offset;
+}
+
+/*
   * Computes the linear offset to the base tile and adjusts
   * x, y. bytes per pixel is assumed to be a power-of-two.
   *
@@ -2432,9 +2473,9 @@ static u32 _intel_compute_tile_offset(const struct 
drm_i915_private *dev_priv,
offset = (tile_rows * pitch_tiles + tiles) * tile_size;
offset_aligned = offset & ~alignment;
  
-		intel_adjust_tile_offset(x, y, tile_width, tile_height,

-tile_size, pitch_tiles,
-offset, offset_aligned);
+   _intel_adjust_tile_offset(x, y, tile_width, tile_height,
+ tile_size, pitch_tiles,
+ offset, offset_aligned);
} else {
offset = *y * pitch + *x * cpp;
offset_aligned = offset & ~alignment;
@@ -2581,9 +2622,9 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
  

Re: [Intel-gfx] [PATCH 07/12] drm/i915: Limit fb x offset due to fences

[Sivakumar Thulasimani]

Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasim...@intel.com>

On Tuesday 03 May 2016 09:09 PM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä <ville.syrj...@linux.intel.com>

If there's a fence on the object it will be aligned to the start
of the object, and hence CPU rendering to any fb that straddles
the fence edge will come out wrong due to lines wrapping at the
wrong place.

We have no API to manage fences on a sub-object level, so we can't
really fix this in any way. Additonally gen2/3 fences are rather
coarse grained so adjusting the offset migth not even be possible.

Avoid these problems by requiring the fb layout to agree with the
fence layout (if present).

Signed-off-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
---
  drivers/gpu/drm/i915/intel_display.c | 16 
  1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 68612a5fac3d..438f3bd86e48 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2504,6 +2504,22 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
intel_fb_offset_to_xy(, , fb, i);
  
  		/*

+* The fence (if used) is aligned to the start of the object
+* so having the framebuffer wrap around across the edge of the
+* fenced region doesn't really work. We have no API to 
configure
+* the fence start offset within the object (nor could we 
probably
+* on gen2/3). So it's just easier if we just require that the
+* fb layout agrees with the fence layout. We already check 
that the
+* fb stride matches the fence stride elsewhere.
+*/
+   if (intel_fb->obj->tiling_mode != I915_TILING_NONE &&
+   (x + width) * cpp > fb->pitches[i]) {
+   DRM_DEBUG("bad fb plane %d offset: 0x%x\n",
+ i, fb->offsets[i]);
+   return -EINVAL;
+   }
+
+   /*
 * First pixel of the framebuffer from
 * the start of the normal gtt mapping.
 */


--
regards,
Sivakumar Thulasimani

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/bxt: Set oscaledcompmethod to enable scale value

[Sivakumar Thulasimani]

On 9/22/2015 6:32 PM, Imre Deak wrote:

On ma, 2015-09-21 at 23:00 +0530, Sivakumar Thulasimani wrote:

Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasim...@intel.com>

On 9/18/2015 2:11 PM, Sonika Jindal wrote:

Bspec update tells that we have to enable oscaledcompmethod instead of
ouniqetrangenmethod for enabling scale value during swing programming.
Also, scale value is 'don't care' for other levels except the last entry
translation table. So, make it 0 instead of 0x9A.

Signed-off-by: Sonika Jindal <sonika.jin...@intel.com>
---
   drivers/gpu/drm/i915/i915_reg.h  |2 +-
   drivers/gpu/drm/i915/intel_ddi.c |   22 +++---
   2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 812b7b2..cec6546 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1395,7 +1395,7 @@ enum skl_disp_power_wells {
   #define BXT_PORT_TX_DW3_LN0(port)_PORT3(port, _PORT_TX_DW3_LN0_A,  \
 _PORT_TX_DW3_LN0_B,  \
 _PORT_TX_DW3_LN0_C)
-#define   UNIQE_TRANGE_EN_METHOD   (1 << 27)
+#define   SCALE_DCOMP_METHOD   (1 << 26)
   
   #define _PORT_TX_DW4_LN0_A		0x162510

   #define _PORT_TX_DW4_LN0_B   0x6C510
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index fec51df..0d9b304 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -261,15 +261,15 @@ struct bxt_ddi_buf_trans {
*/
   static const struct bxt_ddi_buf_trans bxt_ddi_translations_dp[] = {
/* Idx  NT mV diff  db  */
-   { 52,  0x9A, 0, 128, true  },   /* 0:   400 0   */
-   { 78,  0x9A, 0, 85,  false },   /* 1:   400 3.5 */
-   { 104, 0x9A, 0, 64,  false },   /* 2:   400 6   */
-   { 154, 0x9A, 0, 43,  false },   /* 3:   400 9.5 */
-   { 77,  0x9A, 0, 128, false },   /* 4:   600 0   */
-   { 116, 0x9A, 0, 85,  false },   /* 5:   600 3.5 */
-   { 154, 0x9A, 0, 64,  false },   /* 6:   600 6   */
-   { 102, 0x9A, 0, 128, false },   /* 7:   800 0   */
-   { 154, 0x9A, 0, 85,  false },   /* 8:   800 3.5 */
+   { 52,  0, 0, 128, true  },  /* 0:   400 0   */
+   { 78,  0, 0, 85,  false },  /* 1:   400 3.5 */
+   { 104, 0, 0, 64,  false },  /* 2:   400 6   */
+   { 154, 0, 0, 43,  false },  /* 3:   400 9.5 */
+   { 77,  0, 0, 128, false },  /* 4:   600 0   */
+   { 116, 0, 0, 85,  false },  /* 5:   600 3.5 */
+   { 154, 0, 0, 64,  false },  /* 6:   600 6   */
+   { 102, 0, 0, 128, false },  /* 7:   800 0   */
+   { 154, 0, 0, 85,  false },  /* 8:   800 3.5 */

There is no point in changing the above values as they are don't-care in
any case. In fact the reset value is 0x98 so I'd program that for these
cases if we ever wanted to change them. For now I'd leave this as-is to
keep in sync with the bxt_ddi_translations_hdmi table and also what CHV
does.


{ 154, 0x9A, 1, 128, false },   /* 9:   12000   */
   };


   
@@ -2151,9 +2151,9 @@ static void bxt_ddi_vswing_sequence(struct drm_device *dev, u32 level,

I915_WRITE(BXT_PORT_TX_DW2_GRP(port), val);
   
   	val = I915_READ(BXT_PORT_TX_DW3_LN0(port));

-   val &= ~UNIQE_TRANGE_EN_METHOD;
+   val &= ~SCALE_DCOMP_METHOD;
if (ddi_translations[level].enable)
-   val |= UNIQE_TRANGE_EN_METHOD;
+   val |= SCALE_DCOMP_METHOD;

Please still leave behind a DRM_ERROR in case UNIQE_TRANGE_EN_METHOD was
set in the register and we are disabling scaling. The scaling value does
seem to depend on this bit too, so seeing if it was set can help
tracking down problems.

This was the only place UNIQE_TRANGE_EN_METHOD was set before, with that 
removed
only possibility for it to be set is by GOP/VBIOS. (who are also 
expected to make this change
if not done already.) in such a scenario wont an error message be 
useless here ?

I915_WRITE(BXT_PORT_TX_DW3_GRP(port), val);
   
   	val = I915_READ(BXT_PORT_TX_DW4_LN0(port));







--
regards,
Sivakumar


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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/bxt: eDP low vswing support

[Sivakumar Thulasimani]

Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasim...@intel.com>

On 9/18/2015 2:11 PM, Sonika Jindal wrote:

Adding voltage swing table for edp to support low vswings.

Signed-off-by: Sonika Jindal <sonika.jin...@intel.com>
---
  drivers/gpu/drm/i915/intel_ddi.c |   23 +++
  1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0d9b304..17281bc 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -256,9 +256,6 @@ struct bxt_ddi_buf_trans {
bool default_index; /* true if the entry represents default value */
  };
  
-/* BSpec does not define separate vswing/pre-emphasis values for eDP.

- * Using DP values for eDP as well.
- */
  static const struct bxt_ddi_buf_trans bxt_ddi_translations_dp[] = {
/* Idx  NT mV diff  db  */
{ 52,  0, 0, 128, true  },  /* 0:   400 0   */
@@ -273,6 +270,20 @@ static const struct bxt_ddi_buf_trans 
bxt_ddi_translations_dp[] = {
{ 154, 0x9A, 1, 128, false },   /* 9:   12000   */
  };
  
+static const struct bxt_ddi_buf_trans bxt_ddi_translations_edp[] = {

+   /* Idx  NT mV diff  db  */
+   { 26, 0, 0, 128, false },   /* 0:   200 0   */
+   { 38, 0, 0, 112, false },   /* 1:   200 1.5 */
+   { 48, 0, 0, 96,  false },   /* 2:   200 4   */
+   { 54, 0, 0, 69,  false },   /* 3:   200 6   */
+   { 32, 0, 0, 128, false },   /* 4:   250 0   */
+   { 48, 0, 0, 104, false },   /* 5:   250 1.5 */
+   { 54, 0, 0, 85,  false },   /* 6:   250 4   */
+   { 43, 0, 0, 128, false },   /* 7:   300 0   */
+   { 54, 0, 0, 101, false },   /* 8:   300 1.5 */
+   { 48, 0, 0, 128, false },   /* 9:   300 0   */
+};
+
  /* BSpec has 2 recommended values - entries 0 and 8.
   * Using the entry with higher vswing.
   */
@@ -2113,7 +2124,11 @@ static void bxt_ddi_vswing_sequence(struct drm_device 
*dev, u32 level,
u32 n_entries, i;
uint32_t val;
  
-	if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {

+   if (type == INTEL_OUTPUT_EDP && dev_priv->edp_low_vswing) {
+   n_entries = ARRAY_SIZE(bxt_ddi_translations_edp);
+   ddi_translations = bxt_ddi_translations_edp;
+   } else if (type == INTEL_OUTPUT_DISPLAYPORT
+   || type == INTEL_OUTPUT_EDP) {
n_entries = ARRAY_SIZE(bxt_ddi_translations_dp);
ddi_translations = bxt_ddi_translations_dp;
} else if (type == INTEL_OUTPUT_HDMI) {


--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915/bxt: Set oscaledcompmethod to enable scale value

[Sivakumar Thulasimani]

Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasim...@intel.com>

On 9/18/2015 2:11 PM, Sonika Jindal wrote:

Bspec update tells that we have to enable oscaledcompmethod instead of
ouniqetrangenmethod for enabling scale value during swing programming.
Also, scale value is 'don't care' for other levels except the last entry
translation table. So, make it 0 instead of 0x9A.

Signed-off-by: Sonika Jindal <sonika.jin...@intel.com>
---
  drivers/gpu/drm/i915/i915_reg.h  |2 +-
  drivers/gpu/drm/i915/intel_ddi.c |   22 +++---
  2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 812b7b2..cec6546 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1395,7 +1395,7 @@ enum skl_disp_power_wells {
  #define BXT_PORT_TX_DW3_LN0(port) _PORT3(port, _PORT_TX_DW3_LN0_A,  \
 _PORT_TX_DW3_LN0_B,  \
 _PORT_TX_DW3_LN0_C)
-#define   UNIQE_TRANGE_EN_METHOD   (1 << 27)
+#define   SCALE_DCOMP_METHOD   (1 << 26)
  
  #define _PORT_TX_DW4_LN0_A		0x162510

  #define _PORT_TX_DW4_LN0_B0x6C510
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index fec51df..0d9b304 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -261,15 +261,15 @@ struct bxt_ddi_buf_trans {
   */
  static const struct bxt_ddi_buf_trans bxt_ddi_translations_dp[] = {
/* Idx  NT mV diff  db  */
-   { 52,  0x9A, 0, 128, true  },   /* 0:   400 0   */
-   { 78,  0x9A, 0, 85,  false },   /* 1:   400 3.5 */
-   { 104, 0x9A, 0, 64,  false },   /* 2:   400 6   */
-   { 154, 0x9A, 0, 43,  false },   /* 3:   400 9.5 */
-   { 77,  0x9A, 0, 128, false },   /* 4:   600 0   */
-   { 116, 0x9A, 0, 85,  false },   /* 5:   600 3.5 */
-   { 154, 0x9A, 0, 64,  false },   /* 6:   600 6   */
-   { 102, 0x9A, 0, 128, false },   /* 7:   800 0   */
-   { 154, 0x9A, 0, 85,  false },   /* 8:   800 3.5 */
+   { 52,  0, 0, 128, true  },  /* 0:   400 0   */
+   { 78,  0, 0, 85,  false },  /* 1:   400 3.5 */
+   { 104, 0, 0, 64,  false },  /* 2:   400 6   */
+   { 154, 0, 0, 43,  false },  /* 3:   400 9.5 */
+   { 77,  0, 0, 128, false },  /* 4:   600 0   */
+   { 116, 0, 0, 85,  false },  /* 5:   600 3.5 */
+   { 154, 0, 0, 64,  false },  /* 6:   600 6   */
+   { 102, 0, 0, 128, false },  /* 7:   800 0   */
+   { 154, 0, 0, 85,  false },  /* 8:   800 3.5 */
{ 154, 0x9A, 1, 128, false },   /* 9:   12000   */
  };
  
@@ -2151,9 +2151,9 @@ static void bxt_ddi_vswing_sequence(struct drm_device *dev, u32 level,

I915_WRITE(BXT_PORT_TX_DW2_GRP(port), val);
  
  	val = I915_READ(BXT_PORT_TX_DW3_LN0(port));

-   val &= ~UNIQE_TRANGE_EN_METHOD;
+   val &= ~SCALE_DCOMP_METHOD;
if (ddi_translations[level].enable)
-   val |= UNIQE_TRANGE_EN_METHOD;
+   val |= SCALE_DCOMP_METHOD;
I915_WRITE(BXT_PORT_TX_DW3_GRP(port), val);
  
  	val = I915_READ(BXT_PORT_TX_DW4_LN0(port));


--
regards,
Sivakumar

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

[Intel-gfx] [PATCH] Revert "drm/i915: Add eDP intermediate frequencies for CHV"

[Sivakumar Thulasimani]

From: "Thulasimani,Sivakumar" <sivakumar.thulasim...@intel.com>

This reverts
commit: fe51bfb95c996733150c44d21e1c9f4b6322a326.
Author: Ville Syrjälä <ville.syrj...@linux.intel.com>
Date:   Thu Mar 12 17:10:38 2015 +0200

CHV does not support intermediate frequencies so reverting the
patch that added it in the first place

Cc: sta...@vger.kernel.org
Reviewed-by: Ville Syrjälä <ville.syrj...@linux.intel.com>
Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasim...@intel.com>
Signed-off-by: Jani Nikula <jani.nik...@intel.com>
---
 drivers/gpu/drm/i915/intel_dp.c |6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b1fe32b..3e277c4 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -87,9 +87,6 @@ static const struct dp_link_dpll chv_dpll[] = {
 /* Skylake supports following rates */
 static const int gen9_rates[] = { 162000, 216000, 27,
  324000, 432000, 54 };
-static const int chv_rates[] = { 162000, 202500, 21, 216000,
-243000, 27, 324000, 405000,
-42, 432000, 54 };
 static const int default_rates[] = { 162000, 27, 54 };
 
 /**
@@ -1169,9 +1166,6 @@ intel_dp_source_rates(struct drm_device *dev, const int 
**source_rates)
if (INTEL_INFO(dev)->gen >= 9) {
*source_rates = gen9_rates;
return ARRAY_SIZE(gen9_rates);
-   } else if (IS_CHERRYVIEW(dev)) {
-   *source_rates = chv_rates;
-   return ARRAY_SIZE(chv_rates);
}
 
*source_rates = default_rates;
-- 
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 4/4] drm/i915: force full detect on sink count change

[Sivakumar Thulasimani]

On 9/2/2015 2:43 PM, Daniel Vetter wrote:

On Thu, Aug 27, 2015 at 02:18:32PM +0530, Sivakumar Thulasimani wrote:

From: "Thulasimani,Sivakumar" <sivakumar.thulasim...@intel.com>

This patch checks for changes in sink count between short pulse
hpds and forces full detect when there is a change.

This will allow both detection of hotplug and unplug of panels
through dongles that give only short pulse for such events.

v2: changed variable type from u8 to bool (Jani)
 return immediately if perform_full_detect is set(Siva)

Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasim...@intel.com>

That's still incomplete since in the hotplug work function we check
whether ->detect status has changed. If that doesn't happen (e.g. sink
count changes from 1->2 or whatever) then we'll fail to generate the
required uevent.

I suspect the only clean way to fix this is to merge all the dp hpd
handling together into one place and stop using ->detect for some parts of
it. Then we would have one place only that decides whether anything
changed, and whether we need to send anything to userspace or not.
-Daniel

i doubt sink count change from 1->2 is valid.
1)  we support only edp and SST displays in intel_dp_detect.
we should handle all mst related code in intel_dp_hpd_pulse.
2) check_link_status is called from withing !mst check so i dont see it 
change from 1 to 2.
3) even if it changes from 1 to 2, for the given port without mst there 
is no way to

switch between first sink to second one outside mst logic.

correct me if i am wrong, the only reason to call intel_dp_detect is to 
see if
"one display is connected or disconnected" which i feel is fine with 
current code.


But i do agree that we need to clean up intel_dp_hpd_pulse since it does 
a lot of things
then repeats those same operations in intel_dp_detect. for example we 
read dpcd 0-14,
link status and probe oui only to repeat the same steps in the 
intel_dp_detect. considering

that our dpcd read has 1ms delay this can add up pretty quick.

if the intention of intel_dp_hpd_pulse is to handle mst displays, that 
should be checked first
and continue only if display is mst otherwise we should just jump to 
intel_dp_detect.

---
  drivers/gpu/drm/i915/intel_dp.c |   27 ++-
  1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 834f513..279e52c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4370,26 +4370,39 @@ go_again:
   *  4. Check link status on receipt of hot-plug interrupt
   */
  static void
-intel_dp_check_link_status(struct intel_dp *intel_dp)
+intel_dp_check_link_status(struct intel_dp *intel_dp, bool 
*perform_full_detect)
  {
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
struct intel_crtc *crtc =
to_intel_crtc(dp_to_dig_port(intel_dp)->base.base.crtc);
u8 sink_irq_vector;
+   u8 old_sink_count = intel_dp->sink_count;
+   bool ret;
u8 link_status[DP_LINK_STATUS_SIZE];
  
  	WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
  
+	*perform_full_detect = false;

+
/* Try to read receiver status if the link appears to be up */
if (!intel_dp_get_link_status(intel_dp, link_status)) {
return;
}
  
-	/* Now read the DPCD to see if it's actually running */

-   if (!intel_dp_get_dpcd(intel_dp)) {
+   /* Now read the DPCD to see if it's actually running
+* Don't return immediately if dpcd read failed,
+* if sink count was 1 and dpcd read failed we need
+* to do full detection
+*/
+   ret = intel_dp_get_dpcd(intel_dp);
+
+   if (old_sink_count != intel_dp->sink_count)
+   *perform_full_detect = true;
+
+   /* No need to proceed if we are going to do full detect */
+   if (!ret || *perform_full_detect)
return;
-   }
  
  	if (!intel_encoder->base.crtc)

return;
@@ -5031,13 +5044,17 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
}
  
  		if (!intel_dp->is_mst) {

+   bool full_detect;
/*
 * we'll check the link status via the normal hot plug 
path later -
 * but for short hpds we should check it now
 */
drm_modeset_lock(>mode_config.connection_mutex, 
NULL);
-   intel_dp_check_link_status(intel_dp);
+   intel_dp_check_link_status(intel_dp, _detect);
drm_modeset_unlock(>mode_config.connection_mutex);
+
+   if (full_detect)
+  

Re: [Intel-gfx] [PATCH] drm/i915: Check DP link status on long hpd too

[Sivakumar Thulasimani]

On 8/20/2015 10:07 PM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä 

We are no longer checkling the DP link status on long hpd. We used to do
that from the .hot_plug() handler, but it was removed when MST got
introduced.

If there's no userspace we now fail to retrain the link if the sink
power is toggled (or cable yanked and replugged), meaning the user is
left staring at a blank screen. With the retraining put back that should
be fixed.

Also remove the leftover comment that referred to the old retraining
from .hot_plug().

Fixes a regression introduced in:
commit 0e32b39ceed665bfa4a77a4bc307b6652b991632
Author: Dave Airlie 
Date:   Fri May 2 14:02:48 2014 +1000

 drm/i915: add DP 1.2 MST support (v0.7)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89453
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91407
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89461
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89594
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85641
Cc: Dave Airlie 
Cc: sta...@vger.kernel.org
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/i915/intel_dp.c | 11 +--
  1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d32ce48..b014158 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5024,9 +5024,12 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
  
  		intel_dp_probe_oui(intel_dp);
  
-		if (!intel_dp_probe_mst(intel_dp))

+   if (!intel_dp_probe_mst(intel_dp)) {
+   drm_modeset_lock(>mode_config.connection_mutex, 
NULL);
+   intel_dp_check_link_status(intel_dp);
+   drm_modeset_unlock(>mode_config.connection_mutex);

couple of queries for my understanding.
> why should we check for link status for long pulse, which is supposed 
to be for plug in or plug out ?
> goto mst_fail will indicate we are falling back to intel_dp_detect, 
isnt this better suited there ?


Also the following bug indicates failure in mst panel, but the changes 
here are in non-mst path
 https://bugs.freedesktop.org/show_bug.cgi?id=89453, how is this 
patch helping this bug ?

goto mst_fail;
-
+   }
} else {
if (intel_dp->is_mst) {
if (intel_dp_check_mst_status(intel_dp) == -EINVAL)
@@ -5034,10 +5037,6 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
}
  
  		if (!intel_dp->is_mst) {

-   /*
-* we'll check the link status via the normal hot plug 
path later -
-* but for short hpds we should check it now
-*/
drm_modeset_lock(>mode_config.connection_mutex, 
NULL);
intel_dp_check_link_status(intel_dp);
drm_modeset_unlock(>mode_config.connection_mutex);


--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH 4/4] drm/i915: force full detect on sink count change

[Sivakumar Thulasimani]

On 9/1/2015 4:12 PM, Jani Nikula wrote:

On Thu, 27 Aug 2015, Sivakumar Thulasimani <sivakumar.thulasim...@intel.com> 
wrote:

From: "Thulasimani,Sivakumar" <sivakumar.thulasim...@intel.com>

This patch checks for changes in sink count between short pulse
hpds and forces full detect when there is a change.

This will allow both detection of hotplug and unplug of panels
through dongles that give only short pulse for such events.

v2: changed variable type from u8 to bool (Jani)
 return immediately if perform_full_detect is set(Siva)

The general idea LGTM, however see below.


Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasim...@intel.com>
---
  drivers/gpu/drm/i915/intel_dp.c |   27 ++-
  1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 834f513..279e52c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4370,26 +4370,39 @@ go_again:
   *  4. Check link status on receipt of hot-plug interrupt
   */
  static void
-intel_dp_check_link_status(struct intel_dp *intel_dp)
+intel_dp_check_link_status(struct intel_dp *intel_dp, bool 
*perform_full_detect)
  {
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
struct intel_crtc *crtc =
to_intel_crtc(dp_to_dig_port(intel_dp)->base.base.crtc);
u8 sink_irq_vector;
+   u8 old_sink_count = intel_dp->sink_count;
+   bool ret;
u8 link_status[DP_LINK_STATUS_SIZE];
  
  	WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
  
+	*perform_full_detect = false;

+
/* Try to read receiver status if the link appears to be up */
if (!intel_dp_get_link_status(intel_dp, link_status)) {
return;
}
  
-	/* Now read the DPCD to see if it's actually running */

-   if (!intel_dp_get_dpcd(intel_dp)) {
+   /* Now read the DPCD to see if it's actually running
+* Don't return immediately if dpcd read failed,
+* if sink count was 1 and dpcd read failed we need
+* to do full detection
+*/
+   ret = intel_dp_get_dpcd(intel_dp);
+
+   if (old_sink_count != intel_dp->sink_count)
+   *perform_full_detect = true;

The point I was trying to make earlier is that how can you trust
intel_dp->sink_count if intel_dp_get_dpcd failed? You don't know where
it failed, and ->sink_count may or may not have changed. Maybe it has
changed for real but you didn't have a chance to read it just yet.


+
+   /* No need to proceed if we are going to do full detect */
+   if (!ret || *perform_full_detect)
return;
-   }

So if you're returning because of !ret, *perform_full_detect may be true
or false, you don't know. I'd like the code to be explicit about what
you want the caller to do when intel_dp_get_dpcd returns false, full
detect or not.

BR,
Jani.
the idea i had in mind was if intel_dp_get_dpcd failed we should do a 
full detect.


my assumption here was that sink_count would be zero so it would take care
of this, but now that it seems to be a wrong assumption how about the 
following code ?

this makes it explicit that if dpcd read failed we will do full detect.

+   if ((old_sink_count != intel_dp->sink_count) || !ret)
+   *perform_full_detect = true;

+
+   /* No need to proceed if we are going to do full detect */
+   if (*perform_full_detect)
return;



  
  	if (!intel_encoder->base.crtc)

return;
@@ -5031,13 +5044,17 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
}
  
  		if (!intel_dp->is_mst) {

+   bool full_detect;
/*
 * we'll check the link status via the normal hot plug 
path later -
 * but for short hpds we should check it now
 */
drm_modeset_lock(>mode_config.connection_mutex, 
NULL);
-   intel_dp_check_link_status(intel_dp);
+   intel_dp_check_link_status(intel_dp, _detect);
drm_modeset_unlock(>mode_config.connection_mutex);
+
+   if (full_detect)
+   goto put_power;
}
}
  
--

1.7.9.5



--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: read sink_count dpcd always

[Sivakumar Thulasimani]

On 9/1/2015 3:59 PM, Jani Nikula wrote:

On Thu, 27 Aug 2015, Sivakumar Thulasimani <sivakumar.thulasim...@intel.com> 
wrote:

From: "Thulasimani,Sivakumar" <sivakumar.thulasim...@intel.com>

This patch reads sink_count dpcd always and removes its
read operation based on values in downstream port dpcd.

SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd.
SINK_COUNT denotes if a display is attached, while
DOWNSTREAM_PORT_PRESET indicates how many ports are available
in the dongle where display can be attached. so it is possible
for sink count to change irrespective of value in downstream
port dpcd.

This makes sense.

I'm scared this may break something, if there are displays/adapters out
there that don't set sink count properly. I guess only one way to find
out... And this might actually fix something else.


Here is a table of possible values and scenarios

sink_count  downstream_port
 present
0   0   no display is attached
0   1   dongle is connected without display
1   0   display connected directly
1   1   display connected through dongle

Do you think you handle this last case properly now? Previously we'd
return with "connected" at the sink count check, but now we'll go for
the "pke ddc gently" phase.

See below.


v2: moved out crtc enabled checks to prior patch(Jani)

Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasim...@intel.com>
---
  drivers/gpu/drm/i915/intel_dp.c |   21 -
  1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 76561e0..9e4e27d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3898,6 +3898,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
uint8_t rev;
+   uint8_t reg;
  
  	if (intel_dp_dpcd_read_wake(_dp->aux, 0x000, intel_dp->dpcd,

sizeof(intel_dp->dpcd)) < 0)
@@ -3908,6 +3909,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
if (intel_dp->dpcd[DP_DPCD_REV] == 0)
return false; /* DPCD not present */
  
+	if (intel_dp_dpcd_read_wake(_dp->aux, DP_SINK_COUNT,

+   , 1) < 0)
+   return false;
+
+   if (!DP_GET_SINK_COUNT(reg))
+   return false;
+
/* Check if the panel supports PSR */
memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
if (is_edp(intel_dp)) {
@@ -4427,19 +4435,6 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
return connector_status_connected;
  
-	/* If we're HPD-aware, SINK_COUNT changes dynamically */

-   if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
-   intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
-   uint8_t reg;
-
-   if (intel_dp_dpcd_read_wake(_dp->aux, DP_SINK_COUNT,
-   , 1) < 0)
-   return connector_status_unknown;
-
-   return DP_GET_SINK_COUNT(reg) ? connector_status_connected
- : connector_status_disconnected;
-   }
-

Why do we proceed here if we know that we have sink count > 0 and we
have a downstream port present? Admittedly I'm not sure I understand (or
remember) why we had this logic in the first place...

BR,
Jani.
based on what little i can dig up, we proceed in case of dongles to 
check if the

display is CRT or not.
if edid read succeeded, it is DP or any display with proper edid to work 
with.

If edid read failed, then it could be CRT, without edid

we can make it work with a fake edid, but it seems current code just
sets it as connector_status_unknown and ignores the display


/* If no HPD, poke DDC gently */
if (drm_probe_ddc(_dp->aux.ddc))
return connector_status_connected;
--
1.7.9.5



--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH 2/4] drm/i915: read sink_count dpcd always

[Sivakumar Thulasimani]

On 9/1/2015 6:45 PM, Jani Nikula wrote:

On Tue, 01 Sep 2015, Sivakumar Thulasimani <sivakumar.thulasim...@intel.com> 
wrote:

On 9/1/2015 3:59 PM, Jani Nikula wrote:

On Thu, 27 Aug 2015, Sivakumar Thulasimani <sivakumar.thulasim...@intel.com> 
wrote:

From: "Thulasimani,Sivakumar" <sivakumar.thulasim...@intel.com>

This patch reads sink_count dpcd always and removes its
read operation based on values in downstream port dpcd.

SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd.
SINK_COUNT denotes if a display is attached, while
DOWNSTREAM_PORT_PRESET indicates how many ports are available
in the dongle where display can be attached. so it is possible
for sink count to change irrespective of value in downstream
port dpcd.

This makes sense.

I'm scared this may break something, if there are displays/adapters out
there that don't set sink count properly. I guess only one way to find
out... And this might actually fix something else.


Here is a table of possible values and scenarios

sink_count  downstream_port
  present
0   0   no display is attached
0   1   dongle is connected without display
1   0   display connected directly
1   1   display connected through dongle

Do you think you handle this last case properly now? Previously we'd
return with "connected" at the sink count check, but now we'll go for
the "pke ddc gently" phase.

See below.


v2: moved out crtc enabled checks to prior patch(Jani)

Signed-off-by: Sivakumar Thulasimani <sivakumar.thulasim...@intel.com>
---
   drivers/gpu/drm/i915/intel_dp.c |   21 -
   1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 76561e0..9e4e27d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3898,6 +3898,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct drm_device *dev = dig_port->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
uint8_t rev;
+   uint8_t reg;
   
   	if (intel_dp_dpcd_read_wake(_dp->aux, 0x000, intel_dp->dpcd,

sizeof(intel_dp->dpcd)) < 0)
@@ -3908,6 +3909,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
if (intel_dp->dpcd[DP_DPCD_REV] == 0)
return false; /* DPCD not present */
   
+	if (intel_dp_dpcd_read_wake(_dp->aux, DP_SINK_COUNT,

+   , 1) < 0)
+   return false;
+
+   if (!DP_GET_SINK_COUNT(reg))
+   return false;
+
/* Check if the panel supports PSR */
memset(intel_dp->psr_dpcd, 0, sizeof(intel_dp->psr_dpcd));
if (is_edp(intel_dp)) {
@@ -4427,19 +4435,6 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DWN_STRM_PORT_PRESENT))
return connector_status_connected;
   
-	/* If we're HPD-aware, SINK_COUNT changes dynamically */

-   if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11 &&
-   intel_dp->downstream_ports[0] & DP_DS_PORT_HPD) {
-   uint8_t reg;
-
-   if (intel_dp_dpcd_read_wake(_dp->aux, DP_SINK_COUNT,
-   , 1) < 0)
-   return connector_status_unknown;
-
-   return DP_GET_SINK_COUNT(reg) ? connector_status_connected
- : connector_status_disconnected;
-   }
-

Why do we proceed here if we know that we have sink count > 0 and we
have a downstream port present? Admittedly I'm not sure I understand (or
remember) why we had this logic in the first place...

BR,
Jani.

based on what little i can dig up, we proceed in case of dongles to
check if the
display is CRT or not.
if edid read succeeded, it is DP or any display with proper edid to work
with.
If edid read failed, then it could be CRT, without edid

My point is, with the current code, if we have downstream port present
and sink count > 0 and the first downsteam port supports hpd, we'll
directly say status is connected. The hpd check may be bogus, but we
still won't go probing ddc on them.

With your patch, we'd always do the ddc probe if there is a downstream
port present and the sink count > 0.

BR,
Jani.
understood, will check once by adding the old check if hpd supported 
downstream

is present and share new patch.




we can make it work with a fake edid, but it seems current code just
sets it as connector_status_unknown and ignores the display


/* If no HPD, poke DDC gently */
if (drm_probe_ddc(_dp->aux.ddc))
return connector_status_connected;
--
1.7.9.5


--
regards,
Sivakumar



--
regards,
Sivakumar

Re: [Intel-gfx] [PATCH v2 4/7] drm/i915: add common intel_digital_port_connected function

[Sivakumar Thulasimani]

On 8/27/2015 12:30 PM, Jani Nikula wrote:

On Wed, 26 Aug 2015, Sivakumar Thulasimani sivakumar.thulasim...@intel.com 
wrote:

On 8/20/2015 1:17 PM, Jani Nikula wrote:

Add a common intel_digital_port_connected() that splits out to functions
for different platforms. No functional changes.

v2: make the function return a boolean

Signed-off-by: Jani Nikula jani.nik...@intel.com
---
   drivers/gpu/drm/i915/intel_dp.c | 41 
++---
   1 file changed, 22 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f08859471841..f947951a01d4 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4473,13 +4473,6 @@ edp_detect(struct intel_dp *intel_dp)
return status;
   }
   
-/*

- * ibx_digital_port_connected - is the specified port connected?
- * @dev_priv: i915 private structure
- * @port: the port to test
- *
- * Returns true if @port is connected, false otherwise.
- */
   static bool ibx_digital_port_connected(struct drm_i915_private *dev_priv,
   struct intel_digital_port *port)
   {
@@ -4524,13 +4517,12 @@ static bool ibx_digital_port_connected(struct 
drm_i915_private *dev_priv,
return I915_READ(SDEISR)  bit;
   }
   
-static bool g4x_digital_port_connected(struct drm_device *dev,

+static bool g4x_digital_port_connected(struct drm_i915_private *dev_priv,
   struct intel_digital_port *port)
   {
-   struct drm_i915_private *dev_priv = dev-dev_private;
uint32_t bit;
   
-	if (IS_VALLEYVIEW(dev)) {

+   if (IS_VALLEYVIEW(dev_priv)) {

this might not work :(.  just noted this as part of another review.
please fix this since
it is merged.

Sorry, what might not work?

Jani.


-   if (IS_VALLEYVIEW(dev)) {
+   if (IS_VALLEYVIEW(dev_priv)) { - dev_priv is used instead of dev
should be IS_VALLEYVIEW(dev_priv-dev)




switch (port-port) {
case PORT_B:
bit = PORTB_HOTPLUG_LIVE_STATUS_VLV;
@@ -4565,6 +4557,22 @@ static bool g4x_digital_port_connected(struct drm_device 
*dev,
return I915_READ(PORT_HOTPLUG_STAT)  bit;
   }
   
+/*

+ * intel_digital_port_connected - is the specified port connected?
+ * @dev_priv: i915 private structure
+ * @port: the port to test
+ *
+ * Return %true if @port is connected, %false otherwise.
+ */
+static bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
+struct intel_digital_port *port)
+{
+   if (HAS_PCH_SPLIT(dev_priv))
+   return ibx_digital_port_connected(dev_priv, port);
+   else
+   return g4x_digital_port_connected(dev_priv, port);
+}
+
   static enum drm_connector_status
   ironlake_dp_detect(struct intel_dp *intel_dp)
   {
@@ -4572,7 +4580,7 @@ ironlake_dp_detect(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
   
-	if (!ibx_digital_port_connected(dev_priv, intel_dig_port))

+   if (!intel_digital_port_connected(dev_priv, intel_dig_port))
return connector_status_disconnected;
   
   	return intel_dp_detect_dpcd(intel_dp);

@@ -4594,7 +4602,7 @@ g4x_dp_detect(struct intel_dp *intel_dp)
return status;
}
   
-	if (!g4x_digital_port_connected(dev, intel_dig_port))

+   if (!intel_digital_port_connected(dev-dev_private, intel_dig_port))
return connector_status_disconnected;
   
   	return intel_dp_detect_dpcd(intel_dp);

@@ -5057,13 +5065,8 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
/* indicate that we need to restart link training */
intel_dp-train_set_valid = false;
   
-		if (HAS_PCH_SPLIT(dev)) {

-   if (!ibx_digital_port_connected(dev_priv, 
intel_dig_port))
-   goto mst_fail;
-   } else {
-   if (!g4x_digital_port_connected(dev, intel_dig_port))
-   goto mst_fail;
-   }
+   if (!intel_digital_port_connected(dev_priv, intel_dig_port))
+   goto mst_fail;
   
   		if (!intel_dp_get_dpcd(intel_dp)) {

goto mst_fail;

--
regards,
Sivakumar



--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH v2 4/7] drm/i915: add common intel_digital_port_connected function

[Sivakumar Thulasimani]

On 8/27/2015 1:38 PM, Jani Nikula wrote:

On Thu, 27 Aug 2015, Sivakumar Thulasimani sivakumar.thulasim...@intel.com 
wrote:

On 8/27/2015 12:30 PM, Jani Nikula wrote:

On Wed, 26 Aug 2015, Sivakumar Thulasimani sivakumar.thulasim...@intel.com 
wrote:

On 8/20/2015 1:17 PM, Jani Nikula wrote:

Add a common intel_digital_port_connected() that splits out to functions
for different platforms. No functional changes.

v2: make the function return a boolean

Signed-off-by: Jani Nikula jani.nik...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 41 
++---
1 file changed, 22 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f08859471841..f947951a01d4 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4473,13 +4473,6 @@ edp_detect(struct intel_dp *intel_dp)
return status;
}

-/*

- * ibx_digital_port_connected - is the specified port connected?
- * @dev_priv: i915 private structure
- * @port: the port to test
- *
- * Returns true if @port is connected, false otherwise.
- */
static bool ibx_digital_port_connected(struct drm_i915_private *dev_priv,
   struct intel_digital_port *port)
{
@@ -4524,13 +4517,12 @@ static bool ibx_digital_port_connected(struct 
drm_i915_private *dev_priv,
return I915_READ(SDEISR)  bit;
}

-static bool g4x_digital_port_connected(struct drm_device *dev,

+static bool g4x_digital_port_connected(struct drm_i915_private *dev_priv,
   struct intel_digital_port *port)
{
-   struct drm_i915_private *dev_priv = dev-dev_private;
uint32_t bit;

-	if (IS_VALLEYVIEW(dev)) {

+   if (IS_VALLEYVIEW(dev_priv)) {

this might not work :(.  just noted this as part of another review.
please fix this since
it is merged.

Sorry, what might not work?

Jani.

-   if (IS_VALLEYVIEW(dev)) {
+   if (IS_VALLEYVIEW(dev_priv)) { - dev_priv is used instead of dev
should be IS_VALLEYVIEW(dev_priv-dev)

Ah, that may be confusing. We're transitioning towards preferring
dev_priv, and instead of switching everything at once (which would not
work) Chris put together some magic to have these macros accept either
drm_i915_private or drm_device pointer. See __I915__ in i915_drv.h.

BR,
Jani.

sorry, missed that part :(.



switch (port-port) {
case PORT_B:
bit = PORTB_HOTPLUG_LIVE_STATUS_VLV;
@@ -4565,6 +4557,22 @@ static bool g4x_digital_port_connected(struct drm_device 
*dev,
return I915_READ(PORT_HOTPLUG_STAT)  bit;
}

+/*

+ * intel_digital_port_connected - is the specified port connected?
+ * @dev_priv: i915 private structure
+ * @port: the port to test
+ *
+ * Return %true if @port is connected, %false otherwise.
+ */
+static bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
+struct intel_digital_port *port)
+{
+   if (HAS_PCH_SPLIT(dev_priv))
+   return ibx_digital_port_connected(dev_priv, port);
+   else
+   return g4x_digital_port_connected(dev_priv, port);
+}
+
static enum drm_connector_status
ironlake_dp_detect(struct intel_dp *intel_dp)
{
@@ -4572,7 +4580,7 @@ ironlake_dp_detect(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);

-	if (!ibx_digital_port_connected(dev_priv, intel_dig_port))

+   if (!intel_digital_port_connected(dev_priv, intel_dig_port))
return connector_status_disconnected;

	return intel_dp_detect_dpcd(intel_dp);

@@ -4594,7 +4602,7 @@ g4x_dp_detect(struct intel_dp *intel_dp)
return status;
}

-	if (!g4x_digital_port_connected(dev, intel_dig_port))

+   if (!intel_digital_port_connected(dev-dev_private, intel_dig_port))
return connector_status_disconnected;

	return intel_dp_detect_dpcd(intel_dp);

@@ -5057,13 +5065,8 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
/* indicate that we need to restart link training */
intel_dp-train_set_valid = false;

-		if (HAS_PCH_SPLIT(dev)) {

-   if (!ibx_digital_port_connected(dev_priv, 
intel_dig_port))
-   goto mst_fail;
-   } else {
-   if (!g4x_digital_port_connected(dev, intel_dig_port))
-   goto mst_fail;
-   }
+   if (!intel_digital_port_connected(dev_priv, intel_dig_port))
+   goto mst_fail;

		if (!intel_dp_get_dpcd(intel_dp)) {

goto mst_fail;

--
regards,
Sivakumar


--
regards,
Sivakumar



--
regards,
Sivakumar

[Intel-gfx] [PATCH 2/4] drm/i915: read sink_count dpcd always

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch reads sink_count dpcd always and removes its
read operation based on values in downstream port dpcd.

SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd.
SINK_COUNT denotes if a display is attached, while
DOWNSTREAM_PORT_PRESET indicates how many ports are available
in the dongle where display can be attached. so it is possible
for sink count to change irrespective of value in downstream
port dpcd.

Here is a table of possible values and scenarios

sink_count  downstream_port
present
0   0   no display is attached
0   1   dongle is connected without display
1   0   display connected directly
1   1   display connected through dongle

v2: moved out crtc enabled checks to prior patch(Jani)

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |   21 -
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 76561e0..9e4e27d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3898,6 +3898,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct drm_device *dev = dig_port-base.base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
uint8_t rev;
+   uint8_t reg;
 
if (intel_dp_dpcd_read_wake(intel_dp-aux, 0x000, intel_dp-dpcd,
sizeof(intel_dp-dpcd))  0)
@@ -3908,6 +3909,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
if (intel_dp-dpcd[DP_DPCD_REV] == 0)
return false; /* DPCD not present */
 
+   if (intel_dp_dpcd_read_wake(intel_dp-aux, DP_SINK_COUNT,
+   reg, 1)  0)
+   return false;
+
+   if (!DP_GET_SINK_COUNT(reg))
+   return false;
+
/* Check if the panel supports PSR */
memset(intel_dp-psr_dpcd, 0, sizeof(intel_dp-psr_dpcd));
if (is_edp(intel_dp)) {
@@ -4427,19 +4435,6 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT]  DP_DWN_STRM_PORT_PRESENT))
return connector_status_connected;
 
-   /* If we're HPD-aware, SINK_COUNT changes dynamically */
-   if (intel_dp-dpcd[DP_DPCD_REV] = 0x11 
-   intel_dp-downstream_ports[0]  DP_DS_PORT_HPD) {
-   uint8_t reg;
-
-   if (intel_dp_dpcd_read_wake(intel_dp-aux, DP_SINK_COUNT,
-   reg, 1)  0)
-   return connector_status_unknown;
-
-   return DP_GET_SINK_COUNT(reg) ? connector_status_connected
- : connector_status_disconnected;
-   }
-
/* If no HPD, poke DDC gently */
if (drm_probe_ddc(intel_dp-aux.ddc))
return connector_status_connected;
-- 
1.7.9.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: Save sink_count for tracking changes to it

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

sink count can change between short pulse hpd hence this patch
adds a member variable to intel_dp so we can track any changes
between short pulse interrupts.

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c  |5 ++---
 drivers/gpu/drm/i915/intel_drv.h |1 +
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9e4e27d..834f513 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3898,7 +3898,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct drm_device *dev = dig_port-base.base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
uint8_t rev;
-   uint8_t reg;
 
if (intel_dp_dpcd_read_wake(intel_dp-aux, 0x000, intel_dp-dpcd,
sizeof(intel_dp-dpcd))  0)
@@ -3910,10 +3909,10 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
return false; /* DPCD not present */
 
if (intel_dp_dpcd_read_wake(intel_dp-aux, DP_SINK_COUNT,
-   reg, 1)  0)
+   intel_dp-sink_count, 1)  0)
return false;
 
-   if (!DP_GET_SINK_COUNT(reg))
+   if (!DP_GET_SINK_COUNT(intel_dp-sink_count))
return false;
 
/* Check if the panel supports PSR */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 81b7d77..8aca5bb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -712,6 +712,7 @@ struct intel_dp {
enum hdmi_force_audio force_audio;
bool limited_color_range;
bool color_range_auto;
+   uint8_t sink_count;
uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
uint8_t psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
-- 
1.7.9.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: read dpcd 0 - 12 link_status always

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

Compliance requires the driver to read dpcd register 0 to 12 and
registers 0x200 to 0x205 to be read always.
Current code performs dpcd read for short pulse interrupts only
if the sink is enabled. This patch forces read for link status
and registers 0 to 12.

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8a66a44..76561e0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4374,12 +4374,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
 
WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex));
 
-   if (!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;
@@ -4390,6 +4384,12 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
return;
}
 
+   if (!intel_encoder-base.crtc)
+   return;
+
+   if (!to_intel_crtc(intel_encoder-base.crtc)-active)
+   return;
+
/* Try to read the source of the interrupt */
if (intel_dp-dpcd[DP_DPCD_REV] = 0x11 
intel_dp_get_sink_irq(intel_dp, sink_irq_vector)) {
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 4/4] drm/i915: force full detect on sink count change

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch checks for changes in sink count between short pulse
hpds and forces full detect when there is a change.

This will allow both detection of hotplug and unplug of panels
through dongles that give only short pulse for such events.

v2: changed variable type from u8 to bool (Jani)
return immediately if perform_full_detect is set(Siva)

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |   27 ++-
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 834f513..279e52c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4370,26 +4370,39 @@ go_again:
  *  4. Check link status on receipt of hot-plug interrupt
  */
 static void
-intel_dp_check_link_status(struct intel_dp *intel_dp)
+intel_dp_check_link_status(struct intel_dp *intel_dp, bool 
*perform_full_detect)
 {
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_encoder *intel_encoder = dp_to_dig_port(intel_dp)-base;
struct intel_crtc *crtc =
to_intel_crtc(dp_to_dig_port(intel_dp)-base.base.crtc);
u8 sink_irq_vector;
+   u8 old_sink_count = intel_dp-sink_count;
+   bool ret;
u8 link_status[DP_LINK_STATUS_SIZE];
 
WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex));
 
+   *perform_full_detect = false;
+
/* Try to read receiver status if the link appears to be up */
if (!intel_dp_get_link_status(intel_dp, link_status)) {
return;
}
 
-   /* Now read the DPCD to see if it's actually running */
-   if (!intel_dp_get_dpcd(intel_dp)) {
+   /* Now read the DPCD to see if it's actually running
+* Don't return immediately if dpcd read failed,
+* if sink count was 1 and dpcd read failed we need
+* to do full detection
+*/
+   ret = intel_dp_get_dpcd(intel_dp);
+
+   if (old_sink_count != intel_dp-sink_count)
+   *perform_full_detect = true;
+
+   /* No need to proceed if we are going to do full detect */
+   if (!ret || *perform_full_detect)
return;
-   }
 
if (!intel_encoder-base.crtc)
return;
@@ -5031,13 +5044,17 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
}
 
if (!intel_dp-is_mst) {
+   bool full_detect;
/*
 * we'll check the link status via the normal hot plug 
path later -
 * but for short hpds we should check it now
 */
drm_modeset_lock(dev-mode_config.connection_mutex, 
NULL);
-   intel_dp_check_link_status(intel_dp);
+   intel_dp_check_link_status(intel_dp, full_detect);
drm_modeset_unlock(dev-mode_config.connection_mutex);
+
+   if (full_detect)
+   goto put_power;
}
}
 
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 0/4] Detect DP displays based on sink count change

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

These patches together help detect DP displays on short pulse HPD 
and pass the respective compliance test case (4.2.2.8)

v2: modifed first patch so we will read sink_count independent of
downstream ports availablility.
v3: split first patch so crtc enabled check is done in one patch
and rest of sink_count changes in second patch.

Thulasimani,Sivakumar (4):
  drm/i915: read dpcd 0 - 12  link_status always
  drm/i915: read sink_count dpcd always
  drm/i915: Save sink_count for tracking changes to it
  drm/i915: force full detect on sink count change

 drivers/gpu/drm/i915/intel_dp.c  |   57 +++---
 drivers/gpu/drm/i915/intel_drv.h |1 +
 2 files changed, 35 insertions(+), 23 deletions(-)

-- 
1.7.9.5

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: read sink_count dpcd always

[Sivakumar Thulasimani]

On 8/26/2015 3:17 PM, Jani Nikula wrote:

On Tue, 25 Aug 2015, Sivakumar Thulasimani sivakumar.thulasim...@intel.com 
wrote:

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch reads sink_count dpcd always and removes its
read operation based on values in downstream port dpcd. Also
we should read it irrespective of current status of sink.

Having to write also in a commit message is a good hint to stop and
think about whether that should be a separate patch. Maybe it should be,
here too?

BR,
Jani.

:) i thought about it since that part of the message was added last, since
without those changes this patch will not be read sink_count always.

will split it into two patches and rename them accordingly.

SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd.
SINK_COUNT denotes if a display is attached, while
DOWNSTREAM_PORT_PRESET indicates how many ports are available
in the dongle where display can be attached. so it is possible
for sink count to change irrespective of value in downstream
port dpcd.

Here is a table of possible values and scenarios

sink_count  downstream_port
present
0   0   no display is attached
0   1   dongle is connected without display
1   0   display connected directly
1   1   display connected through dongle

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c |   33 ++---
  1 file changed, 14 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8a66a44..9e4e27d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3898,6 +3898,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct drm_device *dev = dig_port-base.base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
uint8_t rev;
+   uint8_t reg;
  
  	if (intel_dp_dpcd_read_wake(intel_dp-aux, 0x000, intel_dp-dpcd,

sizeof(intel_dp-dpcd))  0)
@@ -3908,6 +3909,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
if (intel_dp-dpcd[DP_DPCD_REV] == 0)
return false; /* DPCD not present */
  
+	if (intel_dp_dpcd_read_wake(intel_dp-aux, DP_SINK_COUNT,

+   reg, 1)  0)
+   return false;
+
+   if (!DP_GET_SINK_COUNT(reg))
+   return false;
+
/* Check if the panel supports PSR */
memset(intel_dp-psr_dpcd, 0, sizeof(intel_dp-psr_dpcd));
if (is_edp(intel_dp)) {
@@ -4374,12 +4382,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
  
  	WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex));
  
-	if (!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;
@@ -4390,6 +4392,12 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
return;
}
  
+	if (!intel_encoder-base.crtc)

+   return;
+
+   if (!to_intel_crtc(intel_encoder-base.crtc)-active)
+   return;
+
/* Try to read the source of the interrupt */
if (intel_dp-dpcd[DP_DPCD_REV] = 0x11 
intel_dp_get_sink_irq(intel_dp, sink_irq_vector)) {
@@ -4427,19 +4435,6 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT]  DP_DWN_STRM_PORT_PRESENT))
return connector_status_connected;
  
-	/* If we're HPD-aware, SINK_COUNT changes dynamically */

-   if (intel_dp-dpcd[DP_DPCD_REV] = 0x11 
-   intel_dp-downstream_ports[0]  DP_DS_PORT_HPD) {
-   uint8_t reg;
-
-   if (intel_dp_dpcd_read_wake(intel_dp-aux, DP_SINK_COUNT,
-   reg, 1)  0)
-   return connector_status_unknown;
-
-   return DP_GET_SINK_COUNT(reg) ? connector_status_connected
- : connector_status_disconnected;
-   }
-
/* If no HPD, poke DDC gently */
if (drm_probe_ddc(intel_dp-aux.ddc))
return connector_status_connected;
--
1.7.9.5



--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: force full detect on sink count change

[Sivakumar Thulasimani]

On 8/26/2015 3:32 PM, Jani Nikula wrote:

On Tue, 25 Aug 2015, Sivakumar Thulasimani sivakumar.thulasim...@intel.com 
wrote:

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch checks for changes in sink count between short pulse
hpds and forces full detect when there is a change. This will
result in compliance test case 4.2.2.8 passing since it tests
for this behavior.

This will allow both detection of hotplug and unplug of panels
through dongles that give only short pulse for such events.

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c |   20 
  1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 834f513..eb3ab41 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4370,26 +4370,34 @@ go_again:
   *  4. Check link status on receipt of hot-plug interrupt
   */
  static void
-intel_dp_check_link_status(struct intel_dp *intel_dp)
+intel_dp_check_link_status(struct intel_dp *intel_dp, bool 
*perform_full_detect)

You could turn perform_full_detect into a boolean return value which
this function doesn't have.

sure will do.



  {
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_encoder *intel_encoder = dp_to_dig_port(intel_dp)-base;
struct intel_crtc *crtc =
to_intel_crtc(dp_to_dig_port(intel_dp)-base.base.crtc);
u8 sink_irq_vector;
+   u8 old_sink_count = intel_dp-sink_count;
+   u8 ret;

Isn't this a bool, really?


u8 link_status[DP_LINK_STATUS_SIZE];
  
  	WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex));
  
+	*perform_full_detect = false;

+
/* Try to read receiver status if the link appears to be up */
if (!intel_dp_get_link_status(intel_dp, link_status)) {
return;
}
  
  	/* Now read the DPCD to see if it's actually running */

-   if (!intel_dp_get_dpcd(intel_dp)) {
+   ret = intel_dp_get_dpcd(intel_dp);
+
+   if (old_sink_count != intel_dp-sink_count)
+   *perform_full_detect = true;

Can't trust intel_dp-sink_count without checking the return value. So I
guess you can call intel_dp_get_dpcd the way it's done now, and move the
sink count check below it.

BR,
Jani.


sure will fix this.



+
+   if (!ret)
return;
-   }
  
  	if (!intel_encoder-base.crtc)

return;
@@ -5031,13 +5039,17 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
}
  
  		if (!intel_dp-is_mst) {

+   bool full_detect;
/*
 * we'll check the link status via the normal hot plug 
path later -
 * but for short hpds we should check it now
 */
drm_modeset_lock(dev-mode_config.connection_mutex, 
NULL);
-   intel_dp_check_link_status(intel_dp);
+   intel_dp_check_link_status(intel_dp, full_detect);
drm_modeset_unlock(dev-mode_config.connection_mutex);
+
+   if (full_detect)
+   goto put_power;
}
}
  
--

1.7.9.5



--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: read sink_count dpcd always

[Sivakumar Thulasimani]

On 8/26/2015 5:21 PM, Ville Syrjälä wrote:

On Tue, Aug 25, 2015 at 05:20:36PM +0530, Sivakumar Thulasimani wrote:

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch reads sink_count dpcd always and removes its
read operation based on values in downstream port dpcd. Also
we should read it irrespective of current status of sink.

SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd.
SINK_COUNT denotes if a display is attached, while
DOWNSTREAM_PORT_PRESET indicates how many ports are available
in the dongle where display can be attached. so it is possible
for sink count to change irrespective of value in downstream
port dpcd.

Here is a table of possible values and scenarios

sink_count  downstream_port
present
0   0   no display is attached
0   1   dongle is connected without display
1   0   display connected directly
1   1   display connected through dongle

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c |   33 ++---
  1 file changed, 14 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8a66a44..9e4e27d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3898,6 +3898,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct drm_device *dev = dig_port-base.base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
uint8_t rev;
+   uint8_t reg;
  
  	if (intel_dp_dpcd_read_wake(intel_dp-aux, 0x000, intel_dp-dpcd,

sizeof(intel_dp-dpcd))  0)
@@ -3908,6 +3909,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
if (intel_dp-dpcd[DP_DPCD_REV] == 0)
return false; /* DPCD not present */
  
+	if (intel_dp_dpcd_read_wake(intel_dp-aux, DP_SINK_COUNT,

+   reg, 1)  0)
+   return false;
+
+   if (!DP_GET_SINK_COUNT(reg))
+   return false;
+
/* Check if the panel supports PSR */
memset(intel_dp-psr_dpcd, 0, sizeof(intel_dp-psr_dpcd));
if (is_edp(intel_dp)) {
@@ -4374,12 +4382,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
  
  	WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex));
  
-	if (!intel_encoder-base.crtc)

-   return;
-
-   if (!to_intel_crtc(intel_encoder-base.crtc)-active)
-   return;
-

I don't like trying to overload intel_dp_check_link_status() to do other
stuff besides link retraining. The sink irq stuff already snuck in
somehow, but I think we should pull it out and try to make the function
names match what they do.

The entire DP hpd locking also needs more though. We now grab the
connection_mutex for the retraining to prevent racing against modeset,
but it doesn't prevent racing against -detect(). And for MST we take
no locks whatsoever, even for the retraining (I have a patch for that
that I'll send out soon).
Agree, i am still thinking on how to extract the Automated test request 
part so

we can avoid having same code twice in intel_dp_detect() and in
intel_dp_check_link_status. if your patch also cleans up this function i can
rebase on top of it.

/* Try to read receiver status if the link appears to be up */
if (!intel_dp_get_link_status(intel_dp, link_status)) {
return;
@@ -4390,6 +4392,12 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
return;
}
  
+	if (!intel_encoder-base.crtc)

+   return;
+
+   if (!to_intel_crtc(intel_encoder-base.crtc)-active)
+   return;
+
/* Try to read the source of the interrupt */
if (intel_dp-dpcd[DP_DPCD_REV] = 0x11 
intel_dp_get_sink_irq(intel_dp, sink_irq_vector)) {
@@ -4427,19 +4435,6 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT]  DP_DWN_STRM_PORT_PRESENT))
return connector_status_connected;
  
-	/* If we're HPD-aware, SINK_COUNT changes dynamically */

-   if (intel_dp-dpcd[DP_DPCD_REV] = 0x11 
-   intel_dp-downstream_ports[0]  DP_DS_PORT_HPD) {
-   uint8_t reg;
-
-   if (intel_dp_dpcd_read_wake(intel_dp-aux, DP_SINK_COUNT,
-   reg, 1)  0)
-   return connector_status_unknown;
-
-   return DP_GET_SINK_COUNT(reg) ? connector_status_connected
- : connector_status_disconnected;
-   }
-
/* If no HPD, poke DDC gently */
if (drm_probe_ddc(intel_dp-aux.ddc))
return connector_status_connected;
--
1.7.9.5


--
regards,
Sivakumar

___
Intel-gfx mailing list
Intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for DP

[Sivakumar Thulasimani]

On 8/18/2015 1:36 AM, Benjamin Tissoires wrote:

On Aug 14 2015 or thereabouts, Stéphane Marchesin wrote:

On Wed, Aug 5, 2015 at 12:34 PM, Benjamin Tissoires
benjamin.tissoi...@redhat.com wrote:

On Jul 30 2015 or thereabouts, Sivakumar Thulasimani wrote:


On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:

On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:

why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you can
identify both lane count and reversal state without touching anything in the
link training code. i am yet to upstream my changes for CHT that i can share
if required that does the same in intel_dp_detect without touching any line
in link training path.

With my current limited knowledge of the dp hotplug (and i915 driver) I
am not sure we could detect the reversed state without trying to train 1
lane only. I'd be glad to look at your changes and test them on my
system if you think that could help having a cleaner solution.

Cheers,
Benjamin

No, what i recommended was to do link training but in intel_dp_detect. Since
USB Type C cable
also has its own lane count restriction (it can have different lane count
than the one supported
by panel) you might have to figure that out as well. so both reversal and
lane count detection
can be done outside the modeset path and keep the code free of type C
changes outside
detection path.

Please find below the code to do the same. Do not waste time trying to apply
this directly on
nightly since this is based on a local tree and because this is pre- atomic
changes code, so you
might have to modify chv_upfront_link_train to work on top of the latest
nightly code. we
are supposed to upstream this and is in my todo list.


[original patch snipped...]

Hi Sivakumar,

So I managed to manually re-apply your patch on top of
drm-intel-nightly, and tried to port it to make Broadwell working too.
It works OK if the system is already boot without any external DP used.
In this case, the detection works and I can see my external monitor
working properly.

However, if the monitor is cold plugged, the cpu/GPU hangs and I can not
understand why. I think I enabled all that is mentioned in the PRM to be
able to train the DP link, but I am obviously missing something else.
Can you have a look?


Hi Benjamin,

I would recommend against this approach. Some adapters will claim that
they recovered a clock even when it isn't on the lanes you enabled,
which means that the reversal detection doesn't always work. The only
reliable way to do this is to go talk to the Chrome OS EC (you can
find these patches later in the Chrome OS tree). It's not as generic,
but we might be able to abstract that logic, maybe.


Hi Stéphane,

This is a very good news. I was afraid we would not have access to the
hardware controller because the Intel controller hub spec was not
public.

I will try to have a look at it, but the latest chromeos branch (3.18)
seems to differ quite a lot from the upstream one. Anyway, fingers
crossed.

Cheers,
Benjamin

Hi Benjamin/Stéphan,
All Intel platforms (at-least those i inquired about) handle lane 
reversal in HW.
your statement that link training will pass even on reversed lane seems 
to point

to the same fact. in such a scenario why should the encoder/connector care
if the lane is reversed or not ?

--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: force full detect on sink count change

[Sivakumar Thulasimani]

On 8/26/2015 3:32 PM, Jani Nikula wrote:

On Tue, 25 Aug 2015, Sivakumar Thulasimani sivakumar.thulasim...@intel.com 
wrote:

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch checks for changes in sink count between short pulse
hpds and forces full detect when there is a change. This will
result in compliance test case 4.2.2.8 passing since it tests
for this behavior.

This will allow both detection of hotplug and unplug of panels
through dongles that give only short pulse for such events.

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c |   20 
  1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 834f513..eb3ab41 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4370,26 +4370,34 @@ go_again:
   *  4. Check link status on receipt of hot-plug interrupt
   */
  static void
-intel_dp_check_link_status(struct intel_dp *intel_dp)
+intel_dp_check_link_status(struct intel_dp *intel_dp, bool 
*perform_full_detect)

You could turn perform_full_detect into a boolean return value which
this function doesn't have.

ok thinking a few mins brings back the reason for this change :).

we return from this function for the following reasons,
 dpcd read failed
 sink count change
 crtc is not active
 ATR was requested and it was handled/ignored
 link status was good or if bad we retrained it.
and it might have passed or failed.

lets say i return true or false. what does that mean ?

i'll need full detection only if display was already present and is not 
anymore

which can be due to
 dpcd read failure while the display was enabled ? (basically sink 
count change from 1 to 0)

or sink count changed from 0 to 1.

so it is better to have an explicit parameter rather than




  {
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_encoder *intel_encoder = dp_to_dig_port(intel_dp)-base;
struct intel_crtc *crtc =
to_intel_crtc(dp_to_dig_port(intel_dp)-base.base.crtc);
u8 sink_irq_vector;
+   u8 old_sink_count = intel_dp-sink_count;
+   u8 ret;

Isn't this a bool, really?


u8 link_status[DP_LINK_STATUS_SIZE];
  
  	WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex));
  
+	*perform_full_detect = false;

+
/* Try to read receiver status if the link appears to be up */
if (!intel_dp_get_link_status(intel_dp, link_status)) {
return;
}
  
  	/* Now read the DPCD to see if it's actually running */

-   if (!intel_dp_get_dpcd(intel_dp)) {
+   ret = intel_dp_get_dpcd(intel_dp);
+
+   if (old_sink_count != intel_dp-sink_count)
+   *perform_full_detect = true;

Can't trust intel_dp-sink_count without checking the return value. So I
guess you can call intel_dp_get_dpcd the way it's done now, and move the
sink count check below it.

BR,
Jani.


+
+   if (!ret)
return;
-   }
  
  	if (!intel_encoder-base.crtc)

return;
@@ -5031,13 +5039,17 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
}
  
  		if (!intel_dp-is_mst) {

+   bool full_detect;
/*
 * we'll check the link status via the normal hot plug 
path later -
 * but for short hpds we should check it now
 */
drm_modeset_lock(dev-mode_config.connection_mutex, 
NULL);
-   intel_dp_check_link_status(intel_dp);
+   intel_dp_check_link_status(intel_dp, full_detect);
drm_modeset_unlock(dev-mode_config.connection_mutex);
+
+   if (full_detect)
+   goto put_power;
}
}
  
--

1.7.9.5



--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH v2 4/7] drm/i915: add common intel_digital_port_connected function

[Sivakumar Thulasimani]

On 8/20/2015 1:17 PM, Jani Nikula wrote:

Add a common intel_digital_port_connected() that splits out to functions
for different platforms. No functional changes.

v2: make the function return a boolean

Signed-off-by: Jani Nikula jani.nik...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c | 41 ++---
  1 file changed, 22 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f08859471841..f947951a01d4 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4473,13 +4473,6 @@ edp_detect(struct intel_dp *intel_dp)
return status;
  }
  
-/*

- * ibx_digital_port_connected - is the specified port connected?
- * @dev_priv: i915 private structure
- * @port: the port to test
- *
- * Returns true if @port is connected, false otherwise.
- */
  static bool ibx_digital_port_connected(struct drm_i915_private *dev_priv,
   struct intel_digital_port *port)
  {
@@ -4524,13 +4517,12 @@ static bool ibx_digital_port_connected(struct 
drm_i915_private *dev_priv,
return I915_READ(SDEISR)  bit;
  }
  
-static bool g4x_digital_port_connected(struct drm_device *dev,

+static bool g4x_digital_port_connected(struct drm_i915_private *dev_priv,
   struct intel_digital_port *port)
  {
-   struct drm_i915_private *dev_priv = dev-dev_private;
uint32_t bit;
  
-	if (IS_VALLEYVIEW(dev)) {

+   if (IS_VALLEYVIEW(dev_priv)) {
this might not work :(.  just noted this as part of another review. 
please fix this since

it is merged.

switch (port-port) {
case PORT_B:
bit = PORTB_HOTPLUG_LIVE_STATUS_VLV;
@@ -4565,6 +4557,22 @@ static bool g4x_digital_port_connected(struct drm_device 
*dev,
return I915_READ(PORT_HOTPLUG_STAT)  bit;
  }
  
+/*

+ * intel_digital_port_connected - is the specified port connected?
+ * @dev_priv: i915 private structure
+ * @port: the port to test
+ *
+ * Return %true if @port is connected, %false otherwise.
+ */
+static bool intel_digital_port_connected(struct drm_i915_private *dev_priv,
+struct intel_digital_port *port)
+{
+   if (HAS_PCH_SPLIT(dev_priv))
+   return ibx_digital_port_connected(dev_priv, port);
+   else
+   return g4x_digital_port_connected(dev_priv, port);
+}
+
  static enum drm_connector_status
  ironlake_dp_detect(struct intel_dp *intel_dp)
  {
@@ -4572,7 +4580,7 @@ ironlake_dp_detect(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
  
-	if (!ibx_digital_port_connected(dev_priv, intel_dig_port))

+   if (!intel_digital_port_connected(dev_priv, intel_dig_port))
return connector_status_disconnected;
  
  	return intel_dp_detect_dpcd(intel_dp);

@@ -4594,7 +4602,7 @@ g4x_dp_detect(struct intel_dp *intel_dp)
return status;
}
  
-	if (!g4x_digital_port_connected(dev, intel_dig_port))

+   if (!intel_digital_port_connected(dev-dev_private, intel_dig_port))
return connector_status_disconnected;
  
  	return intel_dp_detect_dpcd(intel_dp);

@@ -5057,13 +5065,8 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
/* indicate that we need to restart link training */
intel_dp-train_set_valid = false;
  
-		if (HAS_PCH_SPLIT(dev)) {

-   if (!ibx_digital_port_connected(dev_priv, 
intel_dig_port))
-   goto mst_fail;
-   } else {
-   if (!g4x_digital_port_connected(dev, intel_dig_port))
-   goto mst_fail;
-   }
+   if (!intel_digital_port_connected(dev_priv, intel_dig_port))
+   goto mst_fail;
  
  		if (!intel_dp_get_dpcd(intel_dp)) {

goto mst_fail;


--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for DP

[Sivakumar Thulasimani]

On 8/26/2015 7:59 PM, Benjamin Tissoires wrote:

On Aug 26 2015 or thereabouts, Sivakumar Thulasimani wrote:


On 8/18/2015 1:36 AM, Benjamin Tissoires wrote:

On Aug 14 2015 or thereabouts, Stéphane Marchesin wrote:

On Wed, Aug 5, 2015 at 12:34 PM, Benjamin Tissoires
benjamin.tissoi...@redhat.com wrote:

On Jul 30 2015 or thereabouts, Sivakumar Thulasimani wrote:

On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:

On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:

why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you can
identify both lane count and reversal state without touching anything in the
link training code. i am yet to upstream my changes for CHT that i can share
if required that does the same in intel_dp_detect without touching any line
in link training path.

With my current limited knowledge of the dp hotplug (and i915 driver) I
am not sure we could detect the reversed state without trying to train 1
lane only. I'd be glad to look at your changes and test them on my
system if you think that could help having a cleaner solution.

Cheers,
Benjamin

No, what i recommended was to do link training but in intel_dp_detect. Since
USB Type C cable
also has its own lane count restriction (it can have different lane count
than the one supported
by panel) you might have to figure that out as well. so both reversal and
lane count detection
can be done outside the modeset path and keep the code free of type C
changes outside
detection path.

Please find below the code to do the same. Do not waste time trying to apply
this directly on
nightly since this is based on a local tree and because this is pre- atomic
changes code, so you
might have to modify chv_upfront_link_train to work on top of the latest
nightly code. we
are supposed to upstream this and is in my todo list.


[original patch snipped...]

Hi Sivakumar,

So I managed to manually re-apply your patch on top of
drm-intel-nightly, and tried to port it to make Broadwell working too.
It works OK if the system is already boot without any external DP used.
In this case, the detection works and I can see my external monitor
working properly.

However, if the monitor is cold plugged, the cpu/GPU hangs and I can not
understand why. I think I enabled all that is mentioned in the PRM to be
able to train the DP link, but I am obviously missing something else.
Can you have a look?


Hi Benjamin,

I would recommend against this approach. Some adapters will claim that
they recovered a clock even when it isn't on the lanes you enabled,
which means that the reversal detection doesn't always work. The only
reliable way to do this is to go talk to the Chrome OS EC (you can
find these patches later in the Chrome OS tree). It's not as generic,
but we might be able to abstract that logic, maybe.


Hi Stéphane,

This is a very good news. I was afraid we would not have access to the
hardware controller because the Intel controller hub spec was not
public.

I will try to have a look at it, but the latest chromeos branch (3.18)
seems to differ quite a lot from the upstream one. Anyway, fingers
crossed.

Cheers,
Benjamin

Hi Benjamin/Stéphan,

Hi Sivakumar,


 All Intel platforms (at-least those i inquired about) handle lane
reversal in HW.

That is the theory and what is written in the USB Type C spec IIRC.
Problem is, the Chromebook Pixel 2 external display does not work when a
USB Type-C adapter is in the reversed position (or believe me, I would
definitively not have submitted a patch for the beauty of it).
Everything else works (link training when 4 lanes are activated, or
other communication channels). Only the order of the 4 data lanes
matters in this situation and the USB controller does not reverse them
for us on this laptop.

your statement that link training will pass even on reversed lane seems to
point
to the same fact. in such a scenario why should the encoder/connector care
if the lane is reversed or not ?

Problem is that Stephane said some adapters are lying regarding the
clock recovery. They claim everything is fine while in the end, the
display doesn't show anything because the lanes are reversed. If this is
just a chromebook Pixel 2 issue, that's better then. I won't have to try
to put some generic interface to notify that the display port lanes have
to be reversed.

Cheers,
Benjamin
Thanks for the info :). There is no way in code to confirm if after link 
training display

is working properly (other than short pulse for link related issues)
so this has to be on a case by case basis. i would recommend
if you plan to upstream it to restrict the changes for chromebook Pixel 
2 alone.

--
regards,
Sivakumar



--
regards,
Sivakumar

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

[Intel-gfx] [PATCH 0/3] Detect DP displays based on sink count change

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

These patches together help detect DP displays on short pulse HPD 
and pass the respective compliance test case (4.2.2.8)

v2: modifed first patch so we will read sink_count independent of
downstream ports availablility.

Thulasimani,Sivakumar (3):
  drm/i915: read sink_count dpcd always
  drm/i915: Save sink_count for tracking changes to it
  drm/i915: force full detect on sink count change

 drivers/gpu/drm/i915/intel_dp.c  |   50 +-
 drivers/gpu/drm/i915/intel_drv.h |1 +
 2 files changed, 29 insertions(+), 22 deletions(-)

-- 
1.7.9.5

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

[Intel-gfx] [PATCH 1/3] drm/i915: read sink_count dpcd always

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch reads sink_count dpcd always and removes its
read operation based on values in downstream port dpcd. Also
we should read it irrespective of current status of sink.

SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd.
SINK_COUNT denotes if a display is attached, while
DOWNSTREAM_PORT_PRESET indicates how many ports are available
in the dongle where display can be attached. so it is possible
for sink count to change irrespective of value in downstream
port dpcd.

Here is a table of possible values and scenarios

sink_count  downstream_port
present
0   0   no display is attached
0   1   dongle is connected without display
1   0   display connected directly
1   1   display connected through dongle

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |   33 ++---
 1 file changed, 14 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8a66a44..9e4e27d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3898,6 +3898,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct drm_device *dev = dig_port-base.base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
uint8_t rev;
+   uint8_t reg;
 
if (intel_dp_dpcd_read_wake(intel_dp-aux, 0x000, intel_dp-dpcd,
sizeof(intel_dp-dpcd))  0)
@@ -3908,6 +3909,13 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
if (intel_dp-dpcd[DP_DPCD_REV] == 0)
return false; /* DPCD not present */
 
+   if (intel_dp_dpcd_read_wake(intel_dp-aux, DP_SINK_COUNT,
+   reg, 1)  0)
+   return false;
+
+   if (!DP_GET_SINK_COUNT(reg))
+   return false;
+
/* Check if the panel supports PSR */
memset(intel_dp-psr_dpcd, 0, sizeof(intel_dp-psr_dpcd));
if (is_edp(intel_dp)) {
@@ -4374,12 +4382,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
 
WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex));
 
-   if (!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;
@@ -4390,6 +4392,12 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
return;
}
 
+   if (!intel_encoder-base.crtc)
+   return;
+
+   if (!to_intel_crtc(intel_encoder-base.crtc)-active)
+   return;
+
/* Try to read the source of the interrupt */
if (intel_dp-dpcd[DP_DPCD_REV] = 0x11 
intel_dp_get_sink_irq(intel_dp, sink_irq_vector)) {
@@ -4427,19 +4435,6 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT]  DP_DWN_STRM_PORT_PRESENT))
return connector_status_connected;
 
-   /* If we're HPD-aware, SINK_COUNT changes dynamically */
-   if (intel_dp-dpcd[DP_DPCD_REV] = 0x11 
-   intel_dp-downstream_ports[0]  DP_DS_PORT_HPD) {
-   uint8_t reg;
-
-   if (intel_dp_dpcd_read_wake(intel_dp-aux, DP_SINK_COUNT,
-   reg, 1)  0)
-   return connector_status_unknown;
-
-   return DP_GET_SINK_COUNT(reg) ? connector_status_connected
- : connector_status_disconnected;
-   }
-
/* If no HPD, poke DDC gently */
if (drm_probe_ddc(intel_dp-aux.ddc))
return connector_status_connected;
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 2/3] drm/i915: Save sink_count for tracking changes to it

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

Sink count can change between short pulse hpd hence this patch
adds a member variable to intel_dp so we can track any changes
between short pulse interrupts.

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c  |5 ++---
 drivers/gpu/drm/i915/intel_drv.h |1 +
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9e4e27d..834f513 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3898,7 +3898,6 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
struct drm_device *dev = dig_port-base.base.dev;
struct drm_i915_private *dev_priv = dev-dev_private;
uint8_t rev;
-   uint8_t reg;
 
if (intel_dp_dpcd_read_wake(intel_dp-aux, 0x000, intel_dp-dpcd,
sizeof(intel_dp-dpcd))  0)
@@ -3910,10 +3909,10 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
return false; /* DPCD not present */
 
if (intel_dp_dpcd_read_wake(intel_dp-aux, DP_SINK_COUNT,
-   reg, 1)  0)
+   intel_dp-sink_count, 1)  0)
return false;
 
-   if (!DP_GET_SINK_COUNT(reg))
+   if (!DP_GET_SINK_COUNT(intel_dp-sink_count))
return false;
 
/* Check if the panel supports PSR */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 81b7d77..8aca5bb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -712,6 +712,7 @@ struct intel_dp {
enum hdmi_force_audio force_audio;
bool limited_color_range;
bool color_range_auto;
+   uint8_t sink_count;
uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
uint8_t psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 3/3] drm/i915: force full detect on sink count change

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch checks for changes in sink count between short pulse
hpds and forces full detect when there is a change. This will
result in compliance test case 4.2.2.8 passing since it tests
for this behavior.

This will allow both detection of hotplug and unplug of panels
through dongles that give only short pulse for such events.

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |   20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 834f513..eb3ab41 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4370,26 +4370,34 @@ go_again:
  *  4. Check link status on receipt of hot-plug interrupt
  */
 static void
-intel_dp_check_link_status(struct intel_dp *intel_dp)
+intel_dp_check_link_status(struct intel_dp *intel_dp, bool 
*perform_full_detect)
 {
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_encoder *intel_encoder = dp_to_dig_port(intel_dp)-base;
struct intel_crtc *crtc =
to_intel_crtc(dp_to_dig_port(intel_dp)-base.base.crtc);
u8 sink_irq_vector;
+   u8 old_sink_count = intel_dp-sink_count;
+   u8 ret;
u8 link_status[DP_LINK_STATUS_SIZE];
 
WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex));
 
+   *perform_full_detect = false;
+
/* Try to read receiver status if the link appears to be up */
if (!intel_dp_get_link_status(intel_dp, link_status)) {
return;
}
 
/* Now read the DPCD to see if it's actually running */
-   if (!intel_dp_get_dpcd(intel_dp)) {
+   ret = intel_dp_get_dpcd(intel_dp);
+
+   if (old_sink_count != intel_dp-sink_count)
+   *perform_full_detect = true;
+
+   if (!ret)
return;
-   }
 
if (!intel_encoder-base.crtc)
return;
@@ -5031,13 +5039,17 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
}
 
if (!intel_dp-is_mst) {
+   bool full_detect;
/*
 * we'll check the link status via the normal hot plug 
path later -
 * but for short hpds we should check it now
 */
drm_modeset_lock(dev-mode_config.connection_mutex, 
NULL);
-   intel_dp_check_link_status(intel_dp);
+   intel_dp_check_link_status(intel_dp, full_detect);
drm_modeset_unlock(dev-mode_config.connection_mutex);
+
+   if (full_detect)
+   goto put_power;
}
}
 
-- 
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 1/2] drm/i915: Read sink_count dpcd always for short hpd

[Sivakumar Thulasimani]

dropping this patch as i understood more about
SINK_COUNT dpcd and DOWNSTREAM_PORT_PRESENT dpcd.
will upload a new series with proper fix.

On 8/17/2015 6:21 PM, Sivakumar Thulasimani wrote:

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

Compliance test 4.2.2.8 requires driver to read the sink_count for
short pulse interrupt even when the panel is not enabled.
This patch performs the following
a) reading sink_count by reusing intel_dp_detect_dpcd
instead of using intel_dp_get_dpcd
b) moving crtc enabled checks post sink_count read call

v2: avoid code movement with functionality changes (Ville)

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c |   20 
  1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b905c19..0b73e98 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -132,6 +132,8 @@ static void edp_panel_vdd_off(struct intel_dp *intel_dp, 
bool sync);
  static void vlv_init_panel_power_sequencer(struct intel_dp *intel_dp);
  static void vlv_steal_power_sequencer(struct drm_device *dev,
  enum pipe pipe);
+static enum drm_connector_status
+intel_dp_detect_dpcd(struct intel_dp *intel_dp);
  
  static int

  intel_dp_max_link_bw(struct intel_dp  *intel_dp)
@@ -4362,21 +4364,23 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
  
  	WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex));
  
-	if (!intel_encoder-base.crtc)

+   /* 4.2.2.8 requires source to read link_status, 0 - 12 DPCD 
+* sink_count even for short pulse irrespective of the sink is
+* in use or not
+*/
+   if (!intel_dp_get_link_status(intel_dp, link_status)) {
return;
+   }
  
-	if (!to_intel_crtc(intel_encoder-base.crtc)-active)

+   /* reuse to read both 0 - 12 DPCD  sink_count */
+   if (intel_dp_detect_dpcd(intel_dp) != connector_status_connected)
return;
  
-	/* Try to read receiver status if the link appears to be up */

-   if (!intel_dp_get_link_status(intel_dp, link_status)) {
+   if (!intel_encoder-base.crtc)
return;
-   }
  
-	/* Now read the DPCD to see if it's actually running */

-   if (!intel_dp_get_dpcd(intel_dp)) {
+   if (!to_intel_crtc(intel_encoder-base.crtc)-active)
return;
-   }
  
  	/* Try to read the source of the interrupt */

if (intel_dp-dpcd[DP_DPCD_REV] = 0x11 


--
regards,
Sivakumar

___
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: Avoid TP3 on CHV

[Sivakumar Thulasimani]

On 8/18/2015 12:14 PM, Jani Nikula wrote:

On Tue, 18 Aug 2015, Sivakumar Thulasimani sivakumar.thulasim...@intel.com 
wrote:

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch removes TP3 support on CHV since there is no support
for HBR2 on this platform.

v2: rename the function to indicate it checks source rates (Jani)

Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c |   24 +---
  1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 475d8cb..8bc6361 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1207,6 +1207,20 @@ intel_dp_sink_rates(struct intel_dp *intel_dp, const int 
**sink_rates)
return (intel_dp_max_link_bw(intel_dp)  3) + 1;
  }
  
+static bool intel_dp_source_supports_hbr2(struct drm_device *dev)

+{
+   /* WaDisableHBR2:skl */
+   if (IS_SKYLAKE(dev)  INTEL_REVID(dev) = SKL_REVID_B0)
+   return false;
+
+   if ((IS_HASWELL(dev)  !IS_HSW_ULX(dev)) || IS_BROADWELL(dev) ||
+   (INTEL_INFO(dev)-gen = 9))
+   return true;
+   else
+   return false;
+}
+
+
  static int
  intel_dp_source_rates(struct drm_device *dev, const int **source_rates)
  {
@@ -1220,12 +1234,8 @@ intel_dp_source_rates(struct drm_device *dev, const int 
**source_rates)
  
  	*source_rates = default_rates;
  
-	/* WaDisableHBR2:skl */

-   if (IS_SKYLAKE(dev)  INTEL_REVID(dev) = SKL_REVID_B0)
-   return (DP_LINK_BW_2_7  3) + 1;
-
-   if ((IS_HASWELL(dev)  !IS_HSW_ULX(dev)) || IS_BROADWELL(dev) ||
-   (INTEL_INFO(dev)-gen = 9))
+   /* This depends on the fact that 5.4 is last value in the array */
+   if (intel_dp_source_supports_hbr2(dev))
return (DP_LINK_BW_5_4  3) + 1;
else
return (DP_LINK_BW_2_7  3) + 1;
@@ -3926,7 +3936,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
/* Training Pattern 3 support, both source and sink */
if (intel_dp-dpcd[DP_DPCD_REV] = 0x12 
intel_dp-dpcd[DP_MAX_LANE_COUNT]  DP_TPS3_SUPPORTED 
-   (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)-gen = 8)) {
+   intel_dp_source_supports_hbr2(dev)) {

hbr2 is not the same as tps3, is it? It's possible to use tps3 without
using hbr2, right?

BR,
Jani.

Yes, TP3 can be supported on panels that does not support HBR2 as well, but
the check here is for hardware capability. Intel platforms that does not 
support

HBR2 cannot support TP3 as well, so we should treat them both the same.
(the only exception here seems to be SKL B0 where WA is in place)




intel_dp-use_tps3 = true;
DRM_DEBUG_KMS(Displayport TPS3 supported\n);
} else
--
1.7.9.5



--
regards,
Sivakumar

___
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: Avoid TP3 on CHV

[Sivakumar Thulasimani]

On 8/18/2015 12:42 PM, Jani Nikula wrote:

On Tue, 18 Aug 2015, Sivakumar Thulasimani sivakumar.thulasim...@intel.com 
wrote:

On 8/18/2015 12:14 PM, Jani Nikula wrote:

On Tue, 18 Aug 2015, Sivakumar Thulasimani sivakumar.thulasim...@intel.com 
wrote:

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch removes TP3 support on CHV since there is no support
for HBR2 on this platform.

v2: rename the function to indicate it checks source rates (Jani)

Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
   drivers/gpu/drm/i915/intel_dp.c |   24 +---
   1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 475d8cb..8bc6361 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1207,6 +1207,20 @@ intel_dp_sink_rates(struct intel_dp *intel_dp, const int 
**sink_rates)
return (intel_dp_max_link_bw(intel_dp)  3) + 1;
   }
   
+static bool intel_dp_source_supports_hbr2(struct drm_device *dev)

+{
+   /* WaDisableHBR2:skl */
+   if (IS_SKYLAKE(dev)  INTEL_REVID(dev) = SKL_REVID_B0)
+   return false;
+
+   if ((IS_HASWELL(dev)  !IS_HSW_ULX(dev)) || IS_BROADWELL(dev) ||
+   (INTEL_INFO(dev)-gen = 9))
+   return true;
+   else
+   return false;
+}
+
+
   static int
   intel_dp_source_rates(struct drm_device *dev, const int **source_rates)
   {
@@ -1220,12 +1234,8 @@ intel_dp_source_rates(struct drm_device *dev, const int 
**source_rates)
   
   	*source_rates = default_rates;
   
-	/* WaDisableHBR2:skl */

-   if (IS_SKYLAKE(dev)  INTEL_REVID(dev) = SKL_REVID_B0)
-   return (DP_LINK_BW_2_7  3) + 1;
-
-   if ((IS_HASWELL(dev)  !IS_HSW_ULX(dev)) || IS_BROADWELL(dev) ||
-   (INTEL_INFO(dev)-gen = 9))
+   /* This depends on the fact that 5.4 is last value in the array */
+   if (intel_dp_source_supports_hbr2(dev))
return (DP_LINK_BW_5_4  3) + 1;
else
return (DP_LINK_BW_2_7  3) + 1;
@@ -3926,7 +3936,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
/* Training Pattern 3 support, both source and sink */
if (intel_dp-dpcd[DP_DPCD_REV] = 0x12 
intel_dp-dpcd[DP_MAX_LANE_COUNT]  DP_TPS3_SUPPORTED 
-   (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)-gen = 8)) {
+   intel_dp_source_supports_hbr2(dev)) {

hbr2 is not the same as tps3, is it? It's possible to use tps3 without
using hbr2, right?

BR,
Jani.

Yes, TP3 can be supported on panels that does not support HBR2 as well, but
the check here is for hardware capability. Intel platforms that does not
support
HBR2 cannot support TP3 as well, so we should treat them both the same.
(the only exception here seems to be SKL B0 where WA is in place)

Okay, please at least add a comment to that effect.

Alternatively you add a separate intel_dp_source_supports_tps3, and
modify intel_dp_source_supports_hbr2 to be
(intel_dp_source_supports_tps3  !WaDisableHBR2:skl). *shrug*.

BR,
Jani.


updated the patch with comments and shared again.



intel_dp-use_tps3 = true;
DRM_DEBUG_KMS(Displayport TPS3 supported\n);
} else
--
1.7.9.5


--
regards,
Sivakumar



--
regards,
Sivakumar

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

[Intel-gfx] [PATCH] drm/i915: Avoid TP3 on CHV

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch removes TP3 support on CHV since there is no support
for HBR2 on this platform.

v2: rename the function to indicate it checks source rates (Jani)
v3: update comment to indicate TP3 dependancy on HBR2 supported
hardware (Jani)

Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |   31 +++
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 475d8cb..051614a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1207,6 +1207,20 @@ intel_dp_sink_rates(struct intel_dp *intel_dp, const int 
**sink_rates)
return (intel_dp_max_link_bw(intel_dp)  3) + 1;
 }
 
+static bool intel_dp_source_supports_hbr2(struct drm_device *dev)
+{
+   /* WaDisableHBR2:skl */
+   if (IS_SKYLAKE(dev)  INTEL_REVID(dev) = SKL_REVID_B0)
+   return false;
+
+   if ((IS_HASWELL(dev)  !IS_HSW_ULX(dev)) || IS_BROADWELL(dev) ||
+   (INTEL_INFO(dev)-gen = 9))
+   return true;
+   else
+   return false;
+}
+
+
 static int
 intel_dp_source_rates(struct drm_device *dev, const int **source_rates)
 {
@@ -1220,12 +1234,8 @@ intel_dp_source_rates(struct drm_device *dev, const int 
**source_rates)
 
*source_rates = default_rates;
 
-   /* WaDisableHBR2:skl */
-   if (IS_SKYLAKE(dev)  INTEL_REVID(dev) = SKL_REVID_B0)
-   return (DP_LINK_BW_2_7  3) + 1;
-
-   if ((IS_HASWELL(dev)  !IS_HSW_ULX(dev)) || IS_BROADWELL(dev) ||
-   (INTEL_INFO(dev)-gen = 9))
+   /* This depends on the fact that 5.4 is last value in the array */
+   if (intel_dp_source_supports_hbr2(dev))
return (DP_LINK_BW_5_4  3) + 1;
else
return (DP_LINK_BW_2_7  3) + 1;
@@ -3923,10 +3933,15 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
}
}
 
-   /* Training Pattern 3 support, both source and sink */
+   /* Training Pattern 3 support, Intel platforms that support HBR2 alone
+* have support for TP3 hence that check is used along with dpcd check
+* to ensure TP3 can be enabled.
+* SKL  B0: due it's WaDisableHBR2 is the only exception where TP3 is
+* supported but still not enabled.
+*/
if (intel_dp-dpcd[DP_DPCD_REV] = 0x12 
intel_dp-dpcd[DP_MAX_LANE_COUNT]  DP_TPS3_SUPPORTED 
-   (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)-gen = 8)) {
+   intel_dp_source_supports_hbr2(dev)) {
intel_dp-use_tps3 = true;
DRM_DEBUG_KMS(Displayport TPS3 supported\n);
} else
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 1/4] Revert drm/i915: Add eDP intermediate frequencies for CHV

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This reverts
commit fe51bfb95c996733150c44d21e1c9f4b6322a326.
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date:   Thu Mar 12 17:10:38 2015 +0200

CHV does not support intermediate frequencies so reverting the
patch that added it in the first place

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b905c19..bfe0567 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -95,9 +95,6 @@ static const int bxt_rates[] = { 162000, 216000, 243000, 
27,
  324000, 432000, 54 };
 static const int skl_rates[] = { 162000, 216000, 27,
  324000, 432000, 54 };
-static const int chv_rates[] = { 162000, 202500, 21, 216000,
-243000, 27, 324000, 405000,
-42, 432000, 54 };
 static const int default_rates[] = { 162000, 27, 54 };
 
 /**
@@ -1219,9 +1216,6 @@ intel_dp_source_rates(struct drm_device *dev, const int 
**source_rates)
} else if (IS_SKYLAKE(dev)) {
*source_rates = skl_rates;
return ARRAY_SIZE(skl_rates);
-   } else if (IS_CHERRYVIEW(dev)) {
-   *source_rates = chv_rates;
-   return ARRAY_SIZE(chv_rates);
}
 
*source_rates = default_rates;
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 2/4] drm/i915: remove HBR2 from chv supported list

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch removes 5.4Gbps from supported link rate for CHV since
it is not supported in it.

v2: change the ordering for better readability (Ville)

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bfe0567..475d8cb 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1220,11 +1220,12 @@ intel_dp_source_rates(struct drm_device *dev, const int 
**source_rates)
 
*source_rates = default_rates;
 
+   /* WaDisableHBR2:skl */
if (IS_SKYLAKE(dev)  INTEL_REVID(dev) = SKL_REVID_B0)
-   /* WaDisableHBR2:skl */
return (DP_LINK_BW_2_7  3) + 1;
-   else if (INTEL_INFO(dev)-gen = 8 ||
-   (IS_HASWELL(dev)  !IS_HSW_ULX(dev)))
+
+   if ((IS_HASWELL(dev)  !IS_HSW_ULX(dev)) || IS_BROADWELL(dev) ||
+   (INTEL_INFO(dev)-gen = 9))
return (DP_LINK_BW_5_4  3) + 1;
else
return (DP_LINK_BW_2_7  3) + 1;
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 0/4] HBR2 cleanup for CHV/SKL

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch series cleans up the code to remove HBR2 support
for CHV since it is not supported on CHV. Also fixes a bug
for SKL platforms where HBR2 is not supported.

Thulasimani,Sivakumar (4):
  Revert drm/i915: Add eDP intermediate frequencies for CHV
  drm/i915: remove HBR2 from chv supported list
  drm/i915: Avoid TP3 on CHV
  drm/i915: fix link rates reported for SKL

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

-- 
1.7.9.5

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

[Intel-gfx] [PATCH 4/4] drm/i915: fix link rates reported for SKL

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch fixes the bug that SKL SKUs before B0 might return
HBR2 as supported even though it is not supposed to be enabled
on such platforms.

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |   14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 03523b3..963fdae 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1224,21 +1224,23 @@ static bool intel_dp_is_hbr2_supported(struct 
drm_device *dev)
 static int
 intel_dp_source_rates(struct drm_device *dev, const int **source_rates)
 {
+   int size = 0;
if (IS_BROXTON(dev)) {
*source_rates = bxt_rates;
-   return ARRAY_SIZE(bxt_rates);
+   size = ARRAY_SIZE(bxt_rates);
} else if (IS_SKYLAKE(dev)) {
*source_rates = skl_rates;
-   return ARRAY_SIZE(skl_rates);
+   size = ARRAY_SIZE(skl_rates);
+   } else {
+   *source_rates = default_rates;
+   size = ARRAY_SIZE(default_rates);
}
 
-   *source_rates = default_rates;
-
/* This depends on the fact that 5.4 is last value in the array */
if (intel_dp_is_hbr2_supported(dev))
-   return (DP_LINK_BW_5_4  3) + 1;
+   return size;
else
-   return (DP_LINK_BW_2_7  3) + 1;
+   return size - 1;
 }
 
 static void
-- 
1.7.9.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: Avoid TP3 on CHV

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch removes TP3 support on CHV since there is no support
for HBR2 on this platform.

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |   24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 475d8cb..03523b3 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1207,6 +1207,20 @@ intel_dp_sink_rates(struct intel_dp *intel_dp, const int 
**sink_rates)
return (intel_dp_max_link_bw(intel_dp)  3) + 1;
 }
 
+static bool intel_dp_is_hbr2_supported(struct drm_device *dev)
+{
+   /* WaDisableHBR2:skl */
+   if (IS_SKYLAKE(dev)  INTEL_REVID(dev) = SKL_REVID_B0)
+   return false;
+
+   if ((IS_HASWELL(dev)  !IS_HSW_ULX(dev)) || IS_BROADWELL(dev) ||
+   (INTEL_INFO(dev)-gen = 9))
+   return true;
+   else
+   return false;
+}
+
+
 static int
 intel_dp_source_rates(struct drm_device *dev, const int **source_rates)
 {
@@ -1220,12 +1234,8 @@ intel_dp_source_rates(struct drm_device *dev, const int 
**source_rates)
 
*source_rates = default_rates;
 
-   /* WaDisableHBR2:skl */
-   if (IS_SKYLAKE(dev)  INTEL_REVID(dev) = SKL_REVID_B0)
-   return (DP_LINK_BW_2_7  3) + 1;
-
-   if ((IS_HASWELL(dev)  !IS_HSW_ULX(dev)) || IS_BROADWELL(dev) ||
-   (INTEL_INFO(dev)-gen = 9))
+   /* This depends on the fact that 5.4 is last value in the array */
+   if (intel_dp_is_hbr2_supported(dev))
return (DP_LINK_BW_5_4  3) + 1;
else
return (DP_LINK_BW_2_7  3) + 1;
@@ -3926,7 +3936,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
/* Training Pattern 3 support, both source and sink */
if (intel_dp-dpcd[DP_DPCD_REV] = 0x12 
intel_dp-dpcd[DP_MAX_LANE_COUNT]  DP_TPS3_SUPPORTED 
-   (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)-gen = 8)) {
+   intel_dp_is_hbr2_supported(dev)) {
intel_dp-use_tps3 = true;
DRM_DEBUG_KMS(Displayport TPS3 supported\n);
} else
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 1/2] drm/i915: Read sink_count dpcd always for short hpd

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

Compliance test 4.2.2.8 requires driver to read the sink_count for
short pulse interrupt even when the panel is not enabled.
This patch performs the following
a) reading sink_count by reusing intel_dp_detect_dpcd
instead of using intel_dp_get_dpcd
b) moving crtc enabled checks post sink_count read call

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |  117 ---
 1 file changed, 59 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b905c19..e4de8e5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4342,6 +4342,56 @@ go_again:
return -EINVAL;
 }
 
+/* XXX this is probably wrong for multiple downstream ports */
+static enum drm_connector_status
+intel_dp_detect_dpcd(struct intel_dp *intel_dp)
+{
+   uint8_t *dpcd = intel_dp-dpcd;
+   uint8_t type;
+
+   if (!intel_dp_get_dpcd(intel_dp))
+   return connector_status_disconnected;
+
+   /* if there's no downstream port, we're done */
+   if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT]  DP_DWN_STRM_PORT_PRESENT))
+   return connector_status_connected;
+
+   /* If we're HPD-aware, SINK_COUNT changes dynamically */
+   if (intel_dp-dpcd[DP_DPCD_REV] = 0x11 
+   intel_dp-downstream_ports[0]  DP_DS_PORT_HPD) {
+   uint8_t reg;
+
+   if (intel_dp_dpcd_read_wake(intel_dp-aux, DP_SINK_COUNT,
+   reg, 1)  0)
+   return connector_status_unknown;
+
+   return DP_GET_SINK_COUNT(reg) ? connector_status_connected
+ : connector_status_disconnected;
+   }
+
+   /* If no HPD, poke DDC gently */
+   if (drm_probe_ddc(intel_dp-aux.ddc))
+   return connector_status_connected;
+
+   /* Well we tried, say unknown for unreliable port types */
+   if (intel_dp-dpcd[DP_DPCD_REV] = 0x11) {
+   type = intel_dp-downstream_ports[0]  DP_DS_PORT_TYPE_MASK;
+   if (type == DP_DS_PORT_TYPE_VGA ||
+   type == DP_DS_PORT_TYPE_NON_EDID)
+   return connector_status_unknown;
+   } else {
+   type = intel_dp-dpcd[DP_DOWNSTREAMPORT_PRESENT] 
+   DP_DWN_STRM_PORT_TYPE_MASK;
+   if (type == DP_DWN_STRM_PORT_TYPE_ANALOG ||
+   type == DP_DWN_STRM_PORT_TYPE_OTHER)
+   return connector_status_unknown;
+   }
+
+   /* Anything else is out of spec, warn and ignore */
+   DRM_DEBUG_KMS(Broken DP branch device, ignoring\n);
+   return connector_status_disconnected;
+}
+
 /*
  * According to DP spec
  * 5.1.2:
@@ -4362,21 +4412,22 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
 
WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex));
 
-   if (!intel_encoder-base.crtc)
+   /* 4.2.2.8 requires source to read link_status, 0 - 12 DPCD 
+* sink_count even for short pulse irrespective of the sink is
+* in use or not
+*/
+   if (!intel_dp_get_link_status(intel_dp, link_status))
return;
 
-   if (!to_intel_crtc(intel_encoder-base.crtc)-active)
+   /* reuse to read both 0 - 12 DPCD  sink_count */
+   if (intel_dp_detect_dpcd(intel_dp) != connector_status_connected)
return;
 
-   /* Try to read receiver status if the link appears to be up */
-   if (!intel_dp_get_link_status(intel_dp, link_status)) {
+   if (!intel_encoder-base.crtc)
return;
-   }
 
-   /* Now read the DPCD to see if it's actually running */
-   if (!intel_dp_get_dpcd(intel_dp)) {
+   if (!to_intel_crtc(intel_encoder-base.crtc)-active)
return;
-   }
 
/* Try to read the source of the interrupt */
if (intel_dp-dpcd[DP_DPCD_REV] = 0x11 
@@ -4401,56 +4452,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
}
 }
 
-/* XXX this is probably wrong for multiple downstream ports */
-static enum drm_connector_status
-intel_dp_detect_dpcd(struct intel_dp *intel_dp)
-{
-   uint8_t *dpcd = intel_dp-dpcd;
-   uint8_t type;
-
-   if (!intel_dp_get_dpcd(intel_dp))
-   return connector_status_disconnected;
-
-   /* if there's no downstream port, we're done */
-   if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT]  DP_DWN_STRM_PORT_PRESENT))
-   return connector_status_connected;
-
-   /* If we're HPD-aware, SINK_COUNT changes dynamically */
-   if (intel_dp-dpcd[DP_DPCD_REV] = 0x11 
-   intel_dp-downstream_ports[0]  DP_DS_PORT_HPD) {
-   uint8_t reg;
-
-   if (intel_dp_dpcd_read_wake(intel_dp-aux, DP_SINK_COUNT,
-   reg, 1

[Intel-gfx] [PATCH 0/2] Detect DP displays based on sink count change

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

These two patches together help detect DP displays on short pulse HPD
and pass the respective compliance test case (4.2.2.8)

Thulasimani,Sivakumar (2):
  drm/i915: Read sink_count dpcd always for short hpd
  drm/i915: Perform full detect on sink_count change

 drivers/gpu/drm/i915/intel_dp.c  |  131 +-
 drivers/gpu/drm/i915/intel_drv.h |1 +
 2 files changed, 73 insertions(+), 59 deletions(-)

-- 
1.7.9.5

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

[Intel-gfx] [PATCH 2/2] drm/i915: Perform full detect on sink_count change

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch checks for changes in sink_count during short pulse hpd
in check_link_status and forces full detect when sink_count
changes. Compliance test 4.2.2.8 expects this behavior in
compliant driver.

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c  |   24 ++--
 drivers/gpu/drm/i915/intel_drv.h |1 +
 2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e4de8e5..04a9ade 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4359,14 +4359,13 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
/* If we're HPD-aware, SINK_COUNT changes dynamically */
if (intel_dp-dpcd[DP_DPCD_REV] = 0x11 
intel_dp-downstream_ports[0]  DP_DS_PORT_HPD) {
-   uint8_t reg;
 
if (intel_dp_dpcd_read_wake(intel_dp-aux, DP_SINK_COUNT,
-   reg, 1)  0)
+   intel_dp-sink_count, 1)  0)
return connector_status_unknown;
 
-   return DP_GET_SINK_COUNT(reg) ? connector_status_connected
- : connector_status_disconnected;
+   return DP_GET_SINK_COUNT(intel_dp-sink_count) ?
+   connector_status_connected : connector_status_disconnected;
}
 
/* If no HPD, poke DDC gently */
@@ -4401,17 +4400,20 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
  *  4. Check link status on receipt of hot-plug interrupt
  */
 static void
-intel_dp_check_link_status(struct intel_dp *intel_dp)
+intel_dp_check_link_status(struct intel_dp *intel_dp, bool *need_full_detect)
 {
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_encoder *intel_encoder = dp_to_dig_port(intel_dp)-base;
struct intel_crtc *crtc =
to_intel_crtc(dp_to_dig_port(intel_dp)-base.base.crtc);
u8 sink_irq_vector;
+   u8 old_sink_count = intel_dp-sink_count;
u8 link_status[DP_LINK_STATUS_SIZE];
 
WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex));
 
+   *need_full_detect = false;
+
/* 4.2.2.8 requires source to read link_status, 0 - 12 DPCD 
 * sink_count even for short pulse irrespective of the sink is
 * in use or not
@@ -4423,6 +4425,12 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
if (intel_dp_detect_dpcd(intel_dp) != connector_status_connected)
return;
 
+   if (old_sink_count != intel_dp-sink_count) {
+   DRM_ERROR(forcing full detect\n);
+   *need_full_detect = true;
+   return;
+   }
+
if (!intel_encoder-base.crtc)
return;
 
@@ -5026,13 +5034,17 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
}
 
if (!intel_dp-is_mst) {
+   bool full_detect = false;
/*
 * we'll check the link status via the normal hot plug 
path later -
 * but for short hpds we should check it now
 */
drm_modeset_lock(dev-mode_config.connection_mutex, 
NULL);
-   intel_dp_check_link_status(intel_dp);
+   intel_dp_check_link_status(intel_dp, full_detect);
drm_modeset_unlock(dev-mode_config.connection_mutex);
+
+   if (full_detect)
+   goto put_power;
}
}
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 81b7d77..8aca5bb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -712,6 +712,7 @@ struct intel_dp {
enum hdmi_force_audio force_audio;
bool limited_color_range;
bool color_range_auto;
+   uint8_t sink_count;
uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
uint8_t psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 2/2] drm/i915: Perform full detect on sink_count change

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch checks for changes in sink_count during short pulse hpd
in check_link_status and forces full detect when sink_count
changes. Compliance test 4.2.2.8 expects this behavior in
compliant driver.

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c  |   25 +++--
 drivers/gpu/drm/i915/intel_drv.h |1 +
 2 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0b73e98..067f9ee 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4353,17 +4353,20 @@ go_again:
  *  4. Check link status on receipt of hot-plug interrupt
  */
 static void
-intel_dp_check_link_status(struct intel_dp *intel_dp)
+intel_dp_check_link_status(struct intel_dp *intel_dp, bool *need_full_detect)
 {
struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_encoder *intel_encoder = dp_to_dig_port(intel_dp)-base;
struct intel_crtc *crtc =
to_intel_crtc(dp_to_dig_port(intel_dp)-base.base.crtc);
u8 sink_irq_vector;
+   u8 old_sink_count = intel_dp-sink_count;
u8 link_status[DP_LINK_STATUS_SIZE];
 
WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex));
 
+   *need_full_detect = false;
+
/* 4.2.2.8 requires source to read link_status, 0 - 12 DPCD 
 * sink_count even for short pulse irrespective of the sink is
 * in use or not
@@ -4376,6 +4379,12 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
if (intel_dp_detect_dpcd(intel_dp) != connector_status_connected)
return;
 
+   if (old_sink_count != intel_dp-sink_count) {
+   DRM_ERROR(forcing full detect\n);
+   *need_full_detect = true;
+   return;
+   }
+
if (!intel_encoder-base.crtc)
return;
 
@@ -4422,14 +4431,13 @@ intel_dp_detect_dpcd(struct intel_dp *intel_dp)
/* If we're HPD-aware, SINK_COUNT changes dynamically */
if (intel_dp-dpcd[DP_DPCD_REV] = 0x11 
intel_dp-downstream_ports[0]  DP_DS_PORT_HPD) {
-   uint8_t reg;
 
if (intel_dp_dpcd_read_wake(intel_dp-aux, DP_SINK_COUNT,
-   reg, 1)  0)
+   intel_dp-sink_count, 1)  0)
return connector_status_unknown;
 
-   return DP_GET_SINK_COUNT(reg) ? connector_status_connected
- : connector_status_disconnected;
+   return DP_GET_SINK_COUNT(intel_dp-sink_count) ?
+   connector_status_connected : connector_status_disconnected;
}
 
/* If no HPD, poke DDC gently */
@@ -5029,13 +5037,18 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
}
 
if (!intel_dp-is_mst) {
+   bool full_detect = false;
+
/*
 * we'll check the link status via the normal hot plug 
path later -
 * but for short hpds we should check it now
 */
drm_modeset_lock(dev-mode_config.connection_mutex, 
NULL);
-   intel_dp_check_link_status(intel_dp);
+   intel_dp_check_link_status(intel_dp, full_detect);
drm_modeset_unlock(dev-mode_config.connection_mutex);
+
+   if (full_detect)
+   goto put_power;
}
}
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 81b7d77..8aca5bb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -712,6 +712,7 @@ struct intel_dp {
enum hdmi_force_audio force_audio;
bool limited_color_range;
bool color_range_auto;
+   uint8_t sink_count;
uint8_t dpcd[DP_RECEIVER_CAP_SIZE];
uint8_t psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE];
uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS];
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 0/2] Detect DP displays based on sink count change

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

These two patches together help detect DP displays on short pulse HPD
and pass the respective compliance test case (4.2.2.8)

Thulasimani,Sivakumar (2):
  drm/i915: Read sink_count dpcd always for short hpd
  drm/i915: Perform full detect on sink_count change

 drivers/gpu/drm/i915/intel_dp.c  |   43 ++
 drivers/gpu/drm/i915/intel_drv.h |1 +
 2 files changed, 31 insertions(+), 13 deletions(-)

-- 
1.7.9.5

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

[Intel-gfx] [PATCH 1/2] drm/i915: Read sink_count dpcd always for short hpd

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

Compliance test 4.2.2.8 requires driver to read the sink_count for
short pulse interrupt even when the panel is not enabled.
This patch performs the following
a) reading sink_count by reusing intel_dp_detect_dpcd
instead of using intel_dp_get_dpcd
b) moving crtc enabled checks post sink_count read call

v2: avoid code movement with functionality changes (Ville)

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |   20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b905c19..0b73e98 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -132,6 +132,8 @@ static void edp_panel_vdd_off(struct intel_dp *intel_dp, 
bool sync);
 static void vlv_init_panel_power_sequencer(struct intel_dp *intel_dp);
 static void vlv_steal_power_sequencer(struct drm_device *dev,
  enum pipe pipe);
+static enum drm_connector_status
+intel_dp_detect_dpcd(struct intel_dp *intel_dp);
 
 static int
 intel_dp_max_link_bw(struct intel_dp  *intel_dp)
@@ -4362,21 +4364,23 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
 
WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex));
 
-   if (!intel_encoder-base.crtc)
+   /* 4.2.2.8 requires source to read link_status, 0 - 12 DPCD 
+* sink_count even for short pulse irrespective of the sink is
+* in use or not
+*/
+   if (!intel_dp_get_link_status(intel_dp, link_status)) {
return;
+   }
 
-   if (!to_intel_crtc(intel_encoder-base.crtc)-active)
+   /* reuse to read both 0 - 12 DPCD  sink_count */
+   if (intel_dp_detect_dpcd(intel_dp) != connector_status_connected)
return;
 
-   /* Try to read receiver status if the link appears to be up */
-   if (!intel_dp_get_link_status(intel_dp, link_status)) {
+   if (!intel_encoder-base.crtc)
return;
-   }
 
-   /* Now read the DPCD to see if it's actually running */
-   if (!intel_dp_get_dpcd(intel_dp)) {
+   if (!to_intel_crtc(intel_encoder-base.crtc)-active)
return;
-   }
 
/* Try to read the source of the interrupt */
if (intel_dp-dpcd[DP_DPCD_REV] = 0x11 
-- 
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 4/4] drm/i915: fix link rates reported for SKL

[Sivakumar Thulasimani]

On 8/17/2015 5:59 PM, Jani Nikula wrote:

On Mon, 17 Aug 2015, Sivakumar Thulasimani sivakumar.thulasim...@intel.com 
wrote:

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch fixes the bug that SKL SKUs before B0 might return
HBR2 as supported even though it is not supposed to be enabled
on such platforms.

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c |   14 --
  1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 03523b3..963fdae 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1224,21 +1224,23 @@ static bool intel_dp_is_hbr2_supported(struct 
drm_device *dev)
  static int
  intel_dp_source_rates(struct drm_device *dev, const int **source_rates)
  {
+   int size = 0;

No need to initialize.


if (IS_BROXTON(dev)) {
*source_rates = bxt_rates;
-   return ARRAY_SIZE(bxt_rates);
+   size = ARRAY_SIZE(bxt_rates);
} else if (IS_SKYLAKE(dev)) {
*source_rates = skl_rates;
-   return ARRAY_SIZE(skl_rates);
+   size = ARRAY_SIZE(skl_rates);
+   } else {
+   *source_rates = default_rates;
+   size = ARRAY_SIZE(default_rates);
}
  
-	*source_rates = default_rates;

-
/* This depends on the fact that 5.4 is last value in the array */
if (intel_dp_is_hbr2_supported(dev))
-   return (DP_LINK_BW_5_4  3) + 1;
+   return size;
else
-   return (DP_LINK_BW_2_7  3) + 1;
+   return size - 1;

/* This depends on the fact that 5.4 is last value in the array */
if (!intel_dp_source_supports_hbr2(dev))
size--;

return size;

uploaded v2 of patches 3  4.
thanks for the review :)


  }
  
  static void

--
1.7.9.5



--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH 4/4] drm/i915: fix link rates reported for SKL

[Sivakumar Thulasimani]

On 8/17/2015 6:11 PM, Ville Syrjälä wrote:

On Mon, Aug 17, 2015 at 05:45:11PM +0530, Sivakumar Thulasimani wrote:

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch fixes the bug that SKL SKUs before B0 might return
HBR2 as supported even though it is not supposed to be enabled
on such platforms.

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c |   14 --
  1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 03523b3..963fdae 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1224,21 +1224,23 @@ static bool intel_dp_is_hbr2_supported(struct 
drm_device *dev)
  static int
  intel_dp_source_rates(struct drm_device *dev, const int **source_rates)
  {
+   int size = 0;
if (IS_BROXTON(dev)) {
*source_rates = bxt_rates;
-   return ARRAY_SIZE(bxt_rates);
+   size = ARRAY_SIZE(bxt_rates);
} else if (IS_SKYLAKE(dev)) {
*source_rates = skl_rates;
-   return ARRAY_SIZE(skl_rates);
+   size = ARRAY_SIZE(skl_rates);
+   } else {
+   *source_rates = default_rates;
+   size = ARRAY_SIZE(default_rates);
}
  
-	*source_rates = default_rates;

-
/* This depends on the fact that 5.4 is last value in the array */
if (intel_dp_is_hbr2_supported(dev))
-   return (DP_LINK_BW_5_4  3) + 1;
+   return size;
else
-   return (DP_LINK_BW_2_7  3) + 1;
+   return size - 1;

Maybe we should use rate_to_index() here? Should be a bit more
future proof for when we get HBR3. So, perhaps something like this?

{
...
*source_rates = bxt_rates;
size_rates = ARRAY_SIZE(bxt_rates);
...

if (intel_dp_is_hbr2_supported)
max_rate = 54;
else
max_rate = 27;

size = rate_to_index(max_rate, *source_rates) + 1;
if (WARN_ON(size  size_rates))
size = size_rates;

return size;
}

But that could be a followup patch.

Otherwise the series looks good so:
Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com

thanks for the review :)

  }
  
  static void

--
1.7.9.5


--
regards,
Sivakumar

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

[Intel-gfx] [PATCH 4/4] drm/i915: fix link rates reported for SKL

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch fixes the bug that SKL SKUs before B0 might return
HBR2 as supported even though it is not supposed to be enabled
on such platforms.

v2: optimize if else condition (Jani)

Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |   19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8bc6361..32bf961 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1224,21 +1224,24 @@ static bool intel_dp_source_supports_hbr2(struct 
drm_device *dev)
 static int
 intel_dp_source_rates(struct drm_device *dev, const int **source_rates)
 {
+   int size;
+
if (IS_BROXTON(dev)) {
*source_rates = bxt_rates;
-   return ARRAY_SIZE(bxt_rates);
+   size =  ARRAY_SIZE(bxt_rates);
} else if (IS_SKYLAKE(dev)) {
*source_rates = skl_rates;
-   return ARRAY_SIZE(skl_rates);
+   size = ARRAY_SIZE(skl_rates);
+   } else {
+   *source_rates = default_rates;
+   size = ARRAY_SIZE(default_rates);
}
 
-   *source_rates = default_rates;
-
/* This depends on the fact that 5.4 is last value in the array */
-   if (intel_dp_source_supports_hbr2(dev))
-   return (DP_LINK_BW_5_4  3) + 1;
-   else
-   return (DP_LINK_BW_2_7  3) + 1;
+   if (!intel_dp_source_supports_hbr2(dev))
+   size--;
+
+   return size;
 }
 
 static void
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 2/4] drm/i915: remove HBR2 from chv supported list

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch removes 5.4Gbps from supported link rate for CHV since
it is not supported in it.

v2: change the ordering for better readability (Ville)

Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bfe0567..475d8cb 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1220,11 +1220,12 @@ intel_dp_source_rates(struct drm_device *dev, const int 
**source_rates)
 
*source_rates = default_rates;
 
+   /* WaDisableHBR2:skl */
if (IS_SKYLAKE(dev)  INTEL_REVID(dev) = SKL_REVID_B0)
-   /* WaDisableHBR2:skl */
return (DP_LINK_BW_2_7  3) + 1;
-   else if (INTEL_INFO(dev)-gen = 8 ||
-   (IS_HASWELL(dev)  !IS_HSW_ULX(dev)))
+
+   if ((IS_HASWELL(dev)  !IS_HSW_ULX(dev)) || IS_BROADWELL(dev) ||
+   (INTEL_INFO(dev)-gen = 9))
return (DP_LINK_BW_5_4  3) + 1;
else
return (DP_LINK_BW_2_7  3) + 1;
-- 
1.7.9.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: Avoid TP3 on CHV

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch removes TP3 support on CHV since there is no support
for HBR2 on this platform.

v2: rename the function to indicate it checks source rates (Jani)

Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |   24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 475d8cb..8bc6361 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1207,6 +1207,20 @@ intel_dp_sink_rates(struct intel_dp *intel_dp, const int 
**sink_rates)
return (intel_dp_max_link_bw(intel_dp)  3) + 1;
 }
 
+static bool intel_dp_source_supports_hbr2(struct drm_device *dev)
+{
+   /* WaDisableHBR2:skl */
+   if (IS_SKYLAKE(dev)  INTEL_REVID(dev) = SKL_REVID_B0)
+   return false;
+
+   if ((IS_HASWELL(dev)  !IS_HSW_ULX(dev)) || IS_BROADWELL(dev) ||
+   (INTEL_INFO(dev)-gen = 9))
+   return true;
+   else
+   return false;
+}
+
+
 static int
 intel_dp_source_rates(struct drm_device *dev, const int **source_rates)
 {
@@ -1220,12 +1234,8 @@ intel_dp_source_rates(struct drm_device *dev, const int 
**source_rates)
 
*source_rates = default_rates;
 
-   /* WaDisableHBR2:skl */
-   if (IS_SKYLAKE(dev)  INTEL_REVID(dev) = SKL_REVID_B0)
-   return (DP_LINK_BW_2_7  3) + 1;
-
-   if ((IS_HASWELL(dev)  !IS_HSW_ULX(dev)) || IS_BROADWELL(dev) ||
-   (INTEL_INFO(dev)-gen = 9))
+   /* This depends on the fact that 5.4 is last value in the array */
+   if (intel_dp_source_supports_hbr2(dev))
return (DP_LINK_BW_5_4  3) + 1;
else
return (DP_LINK_BW_2_7  3) + 1;
@@ -3926,7 +3936,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp)
/* Training Pattern 3 support, both source and sink */
if (intel_dp-dpcd[DP_DPCD_REV] = 0x12 
intel_dp-dpcd[DP_MAX_LANE_COUNT]  DP_TPS3_SUPPORTED 
-   (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)-gen = 8)) {
+   intel_dp_source_supports_hbr2(dev)) {
intel_dp-use_tps3 = true;
DRM_DEBUG_KMS(Displayport TPS3 supported\n);
} else
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 0/4] HBR2 cleanup for CHV/SKL V2

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch series cleans up the code to remove HBR2 support
for CHV since it is not supported on CHV. Also fixes a bug
for SKL platforms where HBR2 is not supported.

V2:
  Added RB from Ville Syrjälä
  patches 3  4 updated with comments from Jani.

Thulasimani,Sivakumar (4):
  Revert drm/i915: Add eDP intermediate frequencies for CHV
  drm/i915: remove HBR2 from chv supported list
  drm/i915: Avoid TP3 on CHV
  drm/i915: fix link rates reported for SKL

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

-- 
1.7.9.5

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

[Intel-gfx] [PATCH 1/4] Revert drm/i915: Add eDP intermediate frequencies for CHV

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This reverts
commit fe51bfb95c996733150c44d21e1c9f4b6322a326.
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date:   Thu Mar 12 17:10:38 2015 +0200

CHV does not support intermediate frequencies so reverting the
patch that added it in the first place

Reviewed-by: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b905c19..bfe0567 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -95,9 +95,6 @@ static const int bxt_rates[] = { 162000, 216000, 243000, 
27,
  324000, 432000, 54 };
 static const int skl_rates[] = { 162000, 216000, 27,
  324000, 432000, 54 };
-static const int chv_rates[] = { 162000, 202500, 21, 216000,
-243000, 27, 324000, 405000,
-42, 432000, 54 };
 static const int default_rates[] = { 162000, 27, 54 };
 
 /**
@@ -1219,9 +1216,6 @@ intel_dp_source_rates(struct drm_device *dev, const int 
**source_rates)
} else if (IS_SKYLAKE(dev)) {
*source_rates = skl_rates;
return ARRAY_SIZE(skl_rates);
-   } else if (IS_CHERRYVIEW(dev)) {
-   *source_rates = chv_rates;
-   return ARRAY_SIZE(chv_rates);
}
 
*source_rates = default_rates;
-- 
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 1/2] drm/i915: Read sink_count dpcd always for short hpd

[Sivakumar Thulasimani]

On 8/17/2015 5:39 PM, Jani Nikula wrote:

On Mon, 17 Aug 2015, Sivakumar Thulasimani sivakumar.thulasim...@intel.com 
wrote:

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

Compliance test 4.2.2.8 requires driver to read the sink_count for
short pulse interrupt even when the panel is not enabled.
This patch performs the following
a) reading sink_count by reusing intel_dp_detect_dpcd
instead of using intel_dp_get_dpcd
b) moving crtc enabled checks post sink_count read call

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c |  117 ---
  1 file changed, 59 insertions(+), 58 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b905c19..e4de8e5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4342,6 +4342,56 @@ go_again:
return -EINVAL;
  }
  
+/* XXX this is probably wrong for multiple downstream ports */

+static enum drm_connector_status
+intel_dp_detect_dpcd(struct intel_dp *intel_dp)
+{
+   uint8_t *dpcd = intel_dp-dpcd;
+   uint8_t type;
+
+   if (!intel_dp_get_dpcd(intel_dp))
+   return connector_status_disconnected;
+
+   /* if there's no downstream port, we're done */
+   if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT]  DP_DWN_STRM_PORT_PRESENT))
+   return connector_status_connected;
+
+   /* If we're HPD-aware, SINK_COUNT changes dynamically */
+   if (intel_dp-dpcd[DP_DPCD_REV] = 0x11 
+   intel_dp-downstream_ports[0]  DP_DS_PORT_HPD) {
+   uint8_t reg;
+
+   if (intel_dp_dpcd_read_wake(intel_dp-aux, DP_SINK_COUNT,
+   reg, 1)  0)
+   return connector_status_unknown;
+
+   return DP_GET_SINK_COUNT(reg) ? connector_status_connected
+ : connector_status_disconnected;
+   }
+
+   /* If no HPD, poke DDC gently */
+   if (drm_probe_ddc(intel_dp-aux.ddc))
+   return connector_status_connected;
+
+   /* Well we tried, say unknown for unreliable port types */
+   if (intel_dp-dpcd[DP_DPCD_REV] = 0x11) {
+   type = intel_dp-downstream_ports[0]  DP_DS_PORT_TYPE_MASK;
+   if (type == DP_DS_PORT_TYPE_VGA ||
+   type == DP_DS_PORT_TYPE_NON_EDID)
+   return connector_status_unknown;
+   } else {
+   type = intel_dp-dpcd[DP_DOWNSTREAMPORT_PRESENT] 
+   DP_DWN_STRM_PORT_TYPE_MASK;
+   if (type == DP_DWN_STRM_PORT_TYPE_ANALOG ||
+   type == DP_DWN_STRM_PORT_TYPE_OTHER)
+   return connector_status_unknown;
+   }
+
+   /* Anything else is out of spec, warn and ignore */
+   DRM_DEBUG_KMS(Broken DP branch device, ignoring\n);
+   return connector_status_disconnected;
+}

Please either a) just add a forward declaration for
intel_dp_detect_dpcd, or b) add a separate non-functional prep patch
that moves the function around. Please don't combine code movement with
functional changes.

BR,
Jani.

uploaded V2 of the patch with forward declaration.



+
  /*
   * According to DP spec
   * 5.1.2:
@@ -4362,21 +4412,22 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
  
  	WARN_ON(!drm_modeset_is_locked(dev-mode_config.connection_mutex));
  
-	if (!intel_encoder-base.crtc)

+   /* 4.2.2.8 requires source to read link_status, 0 - 12 DPCD 
+* sink_count even for short pulse irrespective of the sink is
+* in use or not
+*/
+   if (!intel_dp_get_link_status(intel_dp, link_status))
return;
  
-	if (!to_intel_crtc(intel_encoder-base.crtc)-active)

+   /* reuse to read both 0 - 12 DPCD  sink_count */
+   if (intel_dp_detect_dpcd(intel_dp) != connector_status_connected)
return;
  
-	/* Try to read receiver status if the link appears to be up */

-   if (!intel_dp_get_link_status(intel_dp, link_status)) {
+   if (!intel_encoder-base.crtc)
return;
-   }
  
-	/* Now read the DPCD to see if it's actually running */

-   if (!intel_dp_get_dpcd(intel_dp)) {
+   if (!to_intel_crtc(intel_encoder-base.crtc)-active)
return;
-   }
  
  	/* Try to read the source of the interrupt */

if (intel_dp-dpcd[DP_DPCD_REV] = 0x11 
@@ -4401,56 +4452,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
}
  }
  
-/* XXX this is probably wrong for multiple downstream ports */

-static enum drm_connector_status
-intel_dp_detect_dpcd(struct intel_dp *intel_dp)
-{
-   uint8_t *dpcd = intel_dp-dpcd;
-   uint8_t type;
-
-   if (!intel_dp_get_dpcd(intel_dp))
-   return connector_status_disconnected;
-
-   /* if there's no downstream port, we're done */
-   if (!(dpcd[DP_DOWNSTREAMPORT_PRESENT

Re: [Intel-gfx] [PATCH 1/2] Revert drm/i915: Add eDP intermediate frequencies for CHV

[Sivakumar Thulasimani]

On 8/14/2015 12:29 PM, Jani Nikula wrote:

On Wed, 12 Aug 2015, Daniel Vetter dan...@ffwll.ch wrote:

On Wed, Aug 12, 2015 at 04:02:17PM +0300, Ville Syrjälä wrote:

On Wed, Aug 12, 2015 at 05:31:55PM +0530, Sivakumar Thulasimani wrote:


On 8/12/2015 5:02 PM, Ville Syrjälä wrote:

On Fri, Jul 31, 2015 at 11:32:52AM +0530, Sivakumar Thulasimani wrote:

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This reverts
commit fe51bfb95c996733150c44d21e1c9f4b6322a326.
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date:   Thu Mar 12 17:10:38 2015 +0200

CHV does not support intermediate frequencies so reverting the
patch that added it in the first place

My docs still say it does. Is there some undocumented problem with the
PLL or is this just a marketing decision?

I don't think so, i too have just one document that shows the phy values
for each of
the link rates but have not found any where else to say it is supported .

Display cluster HAS says they're supported. And since the spreadsheet
has them all in green I assume someone actually figured that they ought
to work.


Also this is not tested by anyone including us from product team so i
highly doubt
   it will even work.

Well if no one has tested them I guess we shouldn't try to use them. Not
a big loss in any case I suppose.

So based on that reasoning I can give an ack for this patch:
Acked-by: Ville Syrjälä ville.syrj...@linux.intel.com


regarding HBR2, it was supposed to land on a future stepping that never
happened
so it is not supported at all.

Hmm. Display Cluster HAS listed it as a stretch goal for early steppings. Apart
from that there isn't much else to go by. Excepth the training pattern 3
support, but now that I look again the new bit for that has disappeared
from the DP register in the spec. Or maybe I was looking at the k0 spec
when I added it. It's still in the k0 spec but as you say that's been
nuked.

In light of this, I think dropping HBR2 is reasonable. HBR is anyway
enough for 4k@30 with 4 lanes, so it's not like we really need HBR2.

And could you also cook up a patch to kill the training pattern 3
support for CHV? Should be mostly a revert of my original patch that
added it, but you probably need to adjust the use_tps3 condition a bit
too.

Can we please grill the people responsible for this docs mess some more?

Patch itself is for Jani.

There was some suggestions from Ville [1] to patch 1/2 that I haven't
seen a reply to.

BR,
Jani.

[1] http://mid.gmane.org/20150812131205.gw5...@intel.com


yes, i can make that change. i was assuming that since Daniel's reply 
had message
patch itself is for Jani that you would pick it up :), will check once 
before waiting

next time.

-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH v2 5/7] drm/i915: Move intel_dp-lane_count into pipe_config

[Sivakumar Thulasimani]

Reviewed-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com

On Monday 06 July 2015 07:09 PM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä ville.syrj...@linux.intel.com

Currently we clobber intel_dp-lane_count in compute config, which means
after a rejected modeset we may no longer be able to retrain the current
link. Move lane_count into pipe_config to avoid that.

v2: Add missing ':' to the pipe config debug dump

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
  drivers/gpu/drm/i915/i915_reg.h  |  3 ++
  drivers/gpu/drm/i915/intel_ddi.c | 10 +++---
  drivers/gpu/drm/i915/intel_display.c |  7 +++--
  drivers/gpu/drm/i915/intel_dp.c  | 60 
  drivers/gpu/drm/i915/intel_dp_mst.c  |  6 +++-
  drivers/gpu/drm/i915/intel_drv.h |  3 +-
  6 files changed, 61 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d5c794a..f5dc75c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4096,6 +4096,7 @@ enum skl_disp_power_wells {
  /* How many wires to use. I guess 3 was too hard */
  #define   DP_PORT_WIDTH(width)(((width) - 1)  19)
  #define   DP_PORT_WIDTH_MASK  (7  19)
+#define   DP_PORT_WIDTH_SHIFT  19
  
  /* Mystic DPCD version 1.1 special mode */

  #define   DP_ENHANCED_FRAMING (1  18)
@@ -7128,6 +7129,8 @@ enum skl_disp_power_wells {
  #define  DDI_BUF_IS_IDLE  (17)
  #define  DDI_A_4_LANES(14)
  #define  DDI_PORT_WIDTH(width)(((width) - 1)  1)
+#define  DDI_PORT_WIDTH_MASK   (7  1)
+#define  DDI_PORT_WIDTH_SHIFT  1
  #define  DDI_INIT_DISPLAY_DETECTED(10)
  
  /* DDI Buffer Translations */

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 96fb472..8df596d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -723,11 +723,11 @@ void intel_ddi_init_dp_buf_reg(struct intel_encoder 
*encoder)
struct intel_dp *intel_dp = enc_to_intel_dp(encoder-base);
struct intel_digital_port *intel_dig_port =
enc_to_dig_port(encoder-base);
+   struct intel_crtc *crtc = to_intel_crtc(encoder-base.crtc);
  
  	intel_dp-DP = intel_dig_port-saved_port_bits |

DDI_BUF_CTL_ENABLE | DDI_BUF_TRANS_SELECT(0);
-   intel_dp-DP |= DDI_PORT_WIDTH(intel_dp-lane_count);
-
+   intel_dp-DP |= DDI_PORT_WIDTH(crtc-config-lane_count);
  }
  
  static struct intel_encoder *

@@ -1913,7 +1913,7 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc 
*crtc)
} else
temp |= TRANS_DDI_MODE_SELECT_DP_SST;
  
-		temp |= DDI_PORT_WIDTH(intel_dp-lane_count);

+   temp |= DDI_PORT_WIDTH(intel_crtc-config-lane_count);
} else if (type == INTEL_OUTPUT_DP_MST) {
struct intel_dp *intel_dp = enc_to_mst(encoder)-primary-dp;
  
@@ -1922,7 +1922,7 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc *crtc)

} else
temp |= TRANS_DDI_MODE_SELECT_DP_SST;
  
-		temp |= DDI_PORT_WIDTH(intel_dp-lane_count);

+   temp |= DDI_PORT_WIDTH(intel_crtc-config-lane_count);
} else {
WARN(1, Invalid encoder type %d for pipe %c\n,
 intel_encoder-type, pipe_name(pipe));
@@ -3072,6 +3072,8 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
case TRANS_DDI_MODE_SELECT_DP_SST:
case TRANS_DDI_MODE_SELECT_DP_MST:
pipe_config-has_dp_encoder = true;
+   pipe_config-lane_count =
+   ((temp  DDI_PORT_WIDTH_MASK)  DDI_PORT_WIDTH_SHIFT) 
+ 1;
intel_dp_get_m_n(intel_crtc, pipe_config);
break;
default:
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 136b533..d56973f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11981,14 +11981,16 @@ static void intel_dump_pipe_config(struct intel_crtc 
*crtc,
  pipe_config-fdi_m_n.gmch_m, pipe_config-fdi_m_n.gmch_n,
  pipe_config-fdi_m_n.link_m, pipe_config-fdi_m_n.link_n,
  pipe_config-fdi_m_n.tu);
-   DRM_DEBUG_KMS(dp: %i, gmch_m: %u, gmch_n: %u, link_m: %u, link_n: %u, tu: 
%u\n,
+   DRM_DEBUG_KMS(dp: %i, lanes: %i, gmch_m: %u, gmch_n: %u, link_m: %u, 
link_n: %u, tu: %u\n,
  pipe_config-has_dp_encoder,
+ pipe_config-lane_count,
  pipe_config-dp_m_n.gmch_m, pipe_config-dp_m_n.gmch_n,
  pipe_config-dp_m_n.link_m, pipe_config-dp_m_n.link_n,
  pipe_config-dp_m_n.tu);
  
-	DRM_DEBUG_KMS(dp: %i, gmch_m2: %u, gmch_n2: %u, link_m2: %u, link_n2: %u

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Clean up DP/HDMI limited color range handling

[Sivakumar Thulasimani]

sdvo is still using color_range name in it's functions. would be good to
rename that as well along with dp  hdmi done here.

otherwise changes are fine
Reviewed-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com

On Monday 06 July 2015 05:40 PM, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä ville.syrj...@linux.intel.com

Currently we treat intel_{dp,hdmi}-color_range as partly user
controller value (via the property) but we also change it during
.compute_config() when using the Automatic mode. That is a bit
confusing, so let's just change things so that we store the user
property values in intel_dp, and only change what's stored in
pipe_config during .compute_config().

There should be no functional change.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
  drivers/gpu/drm/i915/intel_dp.c   | 25 -
  drivers/gpu/drm/i915/intel_drv.h  |  4 ++--
  drivers/gpu/drm/i915/intel_hdmi.c | 26 --
  3 files changed, 26 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fcc64e5..decefa1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1455,15 +1455,13 @@ found:
 * CEA-861-E - 5.1 Default Encoding Parameters
 * VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
 */
-   if (bpp != 18  drm_match_cea_mode(adjusted_mode)  1)
-   intel_dp-color_range = DP_COLOR_RANGE_16_235;
-   else
-   intel_dp-color_range = 0;
+   pipe_config-limited_color_range =
+   bpp != 18  drm_match_cea_mode(adjusted_mode)  1;
+   } else {
+   pipe_config-limited_color_range =
+   intel_dp-limited_color_range;
}
  
-	if (intel_dp-color_range)

-   pipe_config-limited_color_range = true;
-
intel_dp-lane_count = lane_count;
  
  	if (intel_dp-num_sink_rates) {

@@ -1605,8 +1603,9 @@ static void intel_dp_prepare(struct intel_encoder 
*encoder)
trans_dp = ~TRANS_DP_ENH_FRAMING;
I915_WRITE(TRANS_DP_CTL(crtc-pipe), trans_dp);
} else {
-   if (!HAS_PCH_SPLIT(dev)  !IS_VALLEYVIEW(dev))
-   intel_dp-DP |= intel_dp-color_range;
+   if (!HAS_PCH_SPLIT(dev)  !IS_VALLEYVIEW(dev) 
+   crtc-config-limited_color_range)
+   intel_dp-DP |= DP_COLOR_RANGE_16_235;
  
  		if (adjusted_mode-flags  DRM_MODE_FLAG_PHSYNC)

intel_dp-DP |= DP_SYNC_HS_HIGH;
@@ -4663,7 +4662,7 @@ intel_dp_set_property(struct drm_connector *connector,
  
  	if (property == dev_priv-broadcast_rgb_property) {

bool old_auto = intel_dp-color_range_auto;
-   uint32_t old_range = intel_dp-color_range;
+   bool old_range = intel_dp-limited_color_range;
  
  		switch (val) {

case INTEL_BROADCAST_RGB_AUTO:
@@ -4671,18 +4670,18 @@ intel_dp_set_property(struct drm_connector *connector,
break;
case INTEL_BROADCAST_RGB_FULL:
intel_dp-color_range_auto = false;
-   intel_dp-color_range = 0;
+   intel_dp-limited_color_range = false;
break;
case INTEL_BROADCAST_RGB_LIMITED:
intel_dp-color_range_auto = false;
-   intel_dp-color_range = DP_COLOR_RANGE_16_235;
+   intel_dp-limited_color_range = true;
break;
default:
return -EINVAL;
}
  
  		if (old_auto == intel_dp-color_range_auto 

-   old_range == intel_dp-color_range)
+   old_range == intel_dp-limited_color_range)
return 0;
  
  		goto done;

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3f0a890..983a7a7 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -669,7 +669,7 @@ struct cxsr_latency {
  struct intel_hdmi {
u32 hdmi_reg;
int ddc_bus;
-   uint32_t color_range;
+   bool limited_color_range;
bool color_range_auto;
bool has_hdmi_sink;
bool has_audio;
@@ -714,7 +714,7 @@ struct intel_dp {
uint32_t DP;
bool has_audio;
enum hdmi_force_audio force_audio;
-   uint32_t color_range;
+   bool limited_color_range;
bool color_range_auto;
uint8_t link_bw;
uint8_t rate_select;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index c7e912b..ba845f7 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -848,8 +848,8 @@ static void intel_hdmi_prepare(struct intel_encoder 
*encoder

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Dont enable hpd for eDP

[Sivakumar Thulasimani]

On 8/12/2015 6:26 PM, Daniel Vetter wrote:

On Mon, Aug 10, 2015 at 05:51:48PM +0530, Sivakumar Thulasimani wrote:


On 8/10/2015 5:44 PM, Jani Nikula wrote:

On Mon, 10 Aug 2015, Sivakumar Thulasimani sivakumar.thulasim...@intel.com 
wrote:

On 8/10/2015 5:07 PM, Jani Nikula wrote:

On Mon, 10 Aug 2015, Sivakumar Thulasimani sivakumar.thulasim...@intel.com 
wrote:

Reviewed-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com

On 8/10/2015 10:35 AM, Sonika Jindal wrote:

With HPD support added for all ports including PORT_A, setting hpd_pin will
result in enabling of hpd to edp as well. There is no need to enable HPD on
PORT_A hence this patch removes hpd_pin update for PORT_A, where edp will
be connected. it can be added back when required

What? You can't just go ahead and remove HPD from eDP sinks.

BR,
Jani.

Nope, we are not removing HPD for edp sinks, it was never there in the
first place. It was
enabled for CHV (even there by mistake since PORT B/C was both DP and
eDP) but it was
never there for any other plaforms nor is it used for any purpose (PSR
must use it, but i
dont see code for it as well).

Are you saying there's no HPD enabled in our *hardware* for eDP? Or
driver?

My point is, is this patch making it harder to enable eDP hpd handling
(e.g. for PSR or DP link re-training) in the future? We currently take
it into account in a few places, and if we start removing that, it will
be a loss of effort to first remove and then add it back.

BR,
Jani.

i was referring to our driver only.

Our VLV/CHV code already receives hpd for every pps on and off which is
later ignored. if we dont disable HPD on eDPs this behavior will be extended
for all platforms which i feel is too costly to keep enabled when there is
no
purpose for it right now.

don't optimize code because you feel it's costly, only do it when you
have hard numbers. One interrupt per pps on or off transition won't be
measurable at all.
-Daniel

let me rephrase my concern then :)
a) HPD was never enabled before this patch for edp
b) this patch series will enable hpd for edp
so why should we allow hpd for edp when no one is using it and will 
cause problems

unless ignored explicitly ?

--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH] drm/i915: fix checksum write for automated test reply

[Sivakumar Thulasimani]

Hi Daniel,
any comments for the patch below ?

regards,
Sivakumar

On Friday 07 August 2015 03:14 PM, Sivakumar Thulasimani wrote:

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

DP spec requires the checksum of the last block read to be written
when replying to TEST_EDID_READ. This patch fixes the current code
to do the same.

v2: removed loop for jumping blocks and performed direct addition
as recommended by Daniel

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c |9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f1b9f93..fa6e202 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4090,9 +4090,16 @@ static uint8_t intel_dp_autotest_edid(struct intel_dp 
*intel_dp)
  intel_dp-aux.i2c_defer_count);
intel_dp-compliance_test_data = INTEL_DP_RESOLUTION_FAILSAFE;
} else {
+   struct edid *block = intel_connector-detect_edid;
+
+   /* We have to write the checksum
+* of the last block read
+*/
+   block += intel_connector-detect_edid-extensions;
+
if (!drm_dp_dpcd_write(intel_dp-aux,
DP_TEST_EDID_CHECKSUM,
-   intel_connector-detect_edid-checksum,
+   block-checksum,
1))
DRM_DEBUG_KMS(Failed to write EDID checksum\n);
  


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

Re: [Intel-gfx] [PATCH 1/2] Revert drm/i915: Add eDP intermediate frequencies for CHV

[Sivakumar Thulasimani]

hi Ville,
  can you review these patches ?

regards,
Sivakumar

On Friday 31 July 2015 11:32 AM, Sivakumar Thulasimani wrote:

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This reverts
commit fe51bfb95c996733150c44d21e1c9f4b6322a326.
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date:   Thu Mar 12 17:10:38 2015 +0200

CHV does not support intermediate frequencies so reverting the
patch that added it in the first place

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c |6 --
  1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44f8a32..d9fb7a8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -95,9 +95,6 @@ static const int bxt_rates[] = { 162000, 216000, 243000, 
27,
  324000, 432000, 54 };
  static const int skl_rates[] = { 162000, 216000, 27,
  324000, 432000, 54 };
-static const int chv_rates[] = { 162000, 202500, 21, 216000,
-243000, 27, 324000, 405000,
-42, 432000, 54 };
  static const int default_rates[] = { 162000, 27, 54 };
  
  /**

@@ -1185,9 +1182,6 @@ intel_dp_source_rates(struct drm_device *dev, const int 
**source_rates)
} else if (IS_SKYLAKE(dev)) {
*source_rates = skl_rates;
return ARRAY_SIZE(skl_rates);
-   } else if (IS_CHERRYVIEW(dev)) {
-   *source_rates = chv_rates;
-   return ARRAY_SIZE(chv_rates);
}
  
  	*source_rates = default_rates;


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

Re: [Intel-gfx] [PATCH 1/2] Revert drm/i915: Add eDP intermediate frequencies for CHV

[Sivakumar Thulasimani]

On 8/12/2015 5:02 PM, Ville Syrjälä wrote:

On Fri, Jul 31, 2015 at 11:32:52AM +0530, Sivakumar Thulasimani wrote:

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This reverts
commit fe51bfb95c996733150c44d21e1c9f4b6322a326.
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date:   Thu Mar 12 17:10:38 2015 +0200

CHV does not support intermediate frequencies so reverting the
patch that added it in the first place

My docs still say it does. Is there some undocumented problem with the
PLL or is this just a marketing decision?
I don't think so, i too have just one document that shows the phy values 
for each of

the link rates but have not found any where else to say it is supported .
Also this is not tested by anyone including us from product team so i 
highly doubt

 it will even work.

regarding HBR2, it was supposed to land on a future stepping that never 
happened

so it is not supported at all.

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c |6 --
  1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44f8a32..d9fb7a8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -95,9 +95,6 @@ static const int bxt_rates[] = { 162000, 216000, 243000, 
27,
  324000, 432000, 54 };
  static const int skl_rates[] = { 162000, 216000, 27,
  324000, 432000, 54 };
-static const int chv_rates[] = { 162000, 202500, 21, 216000,
-243000, 27, 324000, 405000,
-42, 432000, 54 };
  static const int default_rates[] = { 162000, 27, 54 };
  
  /**

@@ -1185,9 +1182,6 @@ intel_dp_source_rates(struct drm_device *dev, const int 
**source_rates)
} else if (IS_SKYLAKE(dev)) {
*source_rates = skl_rates;
return ARRAY_SIZE(skl_rates);
-   } else if (IS_CHERRYVIEW(dev)) {
-   *source_rates = chv_rates;
-   return ARRAY_SIZE(chv_rates);
}
  
  	*source_rates = default_rates;

--
1.7.9.5


--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH] drm/i915: Retry port as HDMI if dp_is_edp turns out to be false

[Sivakumar Thulasimani]

hi Mengdong,
is there any reason why you cannot modify VBT ? unless it is 
shipped version you

can just flash the modified VBT along with BIOS.

Chris,
i would be even more surprised if VBIOS/GOP can enable some display 
when it is
configured incorrectly in VBT. Give me a day to check with someone if 
this is even

possible in that level.

On 8/10/2015 8:00 AM, Lin, Mengdong wrote:

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Lukas Wunner
Hi,

On Sun, Aug 09, 2015 at 01:12:53PM +0100, Chris Wilson wrote:

We follow the VBT as to whether a DDI port is used for eDP and if so,
do not attach a HDMI encoder to it. However there are machines for
which the VBT eDP flag is a lie (shocking!) and we fail to detect a eDP link.
Furthermore, on those machines the HDMI is connected to that DDI port
but we ignore it.

If we reorder our port initialisation to try the eDP setup first and
if that fails we can treat it as a normal DP port along with a HDMI
output. To accomplish this, we have to delay registering the DP
connector/encoder until after we establish its final type.

Sorry to jump in. Could this help another use case as below ?

We have some Bytrail machine (Bayley Bay), we applied HW rework to disable eDP 
connectivity to DDI1 and enable DP on DDI 1.
But we found the i915 driver still take this DDI as eDP, not DP. we suspect 
it's because VBT still takes it as DP and so i915 driver just follows.

If we don't want to revise VBT in BIOS after every rework, is there any other 
way to let i915 detect this is a DP link?

Thanks
Mengdong


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

The existing code seems very carefully crafted, taking into account the
differences betweem various GPU generations etc, shuffling that around
might risk breakage. FWIW, I'm wondering if just adding a quirk for this single
Dell workstation might be justified?

Best regards,

Lukas



Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
---
  drivers/gpu/drm/i915/intel_display.c |  27 
  drivers/gpu/drm/i915/intel_dp.c  | 127

+--

  drivers/gpu/drm/i915/intel_drv.h |   6 +-
  3 files changed, 79 insertions(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0bcd1b1aba4f..aab8dfd1f8a5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13941,7 +13941,6 @@ static void intel_setup_outputs(struct
drm_device *dev)  {
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_encoder *encoder;
-   bool dpd_is_edp = false;

intel_lvds_init(dev);

@@ -13983,31 +13982,33 @@ static void intel_setup_outputs(struct

drm_device *dev)

intel_ddi_init(dev, PORT_D);
} else if (HAS_PCH_SPLIT(dev)) {
int found;
-   dpd_is_edp = intel_dp_is_edp(dev, PORT_D);

if (has_edp_a(dev))
intel_dp_init(dev, DP_A, PORT_A);

+   found = 0;
+   /* PCH SDVOB multiplex with HDMIB */
if (I915_READ(PCH_HDMIB)  SDVO_DETECTED) {
-   /* PCH SDVOB multiplex with HDMIB */
found = intel_sdvo_init(dev, PCH_SDVOB, true);
if (!found)
intel_hdmi_init(dev, PCH_HDMIB, PORT_B);
-   if (!found  (I915_READ(PCH_DP_B)  DP_DETECTED))
-   intel_dp_init(dev, PCH_DP_B, PORT_B);
}
+   if (!found  I915_READ(PCH_DP_B)  DP_DETECTED)
+   intel_dp_init(dev, PCH_DP_B, PORT_B);

-   if (I915_READ(PCH_HDMIC)  SDVO_DETECTED)
-   intel_hdmi_init(dev, PCH_HDMIC, PORT_C);
-
-   if (!dpd_is_edp  I915_READ(PCH_HDMID)  SDVO_DETECTED)
-   intel_hdmi_init(dev, PCH_HDMID, PORT_D);
-
+   found = 0;
if (I915_READ(PCH_DP_C)  DP_DETECTED)
-   intel_dp_init(dev, PCH_DP_C, PORT_C);
+   found = intel_dp_init(dev, PCH_DP_C, PORT_C);
+   if (found != DRM_MODE_CONNECTOR_eDP 
+   I915_READ(PCH_HDMIC)  SDVO_DETECTED)
+   intel_hdmi_init(dev, PCH_HDMIC, PORT_C);

+   found = 0;
if (I915_READ(PCH_DP_D)  DP_DETECTED)
-   intel_dp_init(dev, PCH_DP_D, PORT_D);
+   found = intel_dp_init(dev, PCH_DP_D, PORT_D);
+   if (found != DRM_MODE_CONNECTOR_eDP 
+   I915_READ(PCH_HDMID)  SDVO_DETECTED)
+   intel_hdmi_init(dev, PCH_HDMID, PORT_D);
} else if (IS_VALLEYVIEW(dev)) {
/*
 * The DP_DETECTED bit is the latched state of the DDC diff 
--git

Re: [Intel-gfx] [PATCH] drm/i915: Retry port as HDMI if dp_is_edp turns out to be false

[Sivakumar Thulasimani]

Chris,
After asking few people found that the simplest explanation and 
plausible root cause
being that PORT D is set for both eDP and HDMI :). in which case the 
proper fix is  to
check in intel_dp_is_edp, if PORT D is again set for any other display 
and return false

if that is the case
or
have a quirk for this config since this seems to be reported atleast for 
now as suggested

by Lukas

i would recommend the first method, if we confirm the root cause is as 
explained above.


On 8/10/2015 11:35 AM, Sivakumar Thulasimani wrote:

hi Mengdong,
is there any reason why you cannot modify VBT ? unless it is 
shipped version you

can just flash the modified VBT along with BIOS.

Chris,
i would be even more surprised if VBIOS/GOP can enable some 
display when it is
configured incorrectly in VBT. Give me a day to check with someone if 
this is even

possible in that level.

On 8/10/2015 8:00 AM, Lin, Mengdong wrote:

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On 
Behalf Of

Lukas Wunner
Hi,

On Sun, Aug 09, 2015 at 01:12:53PM +0100, Chris Wilson wrote:

We follow the VBT as to whether a DDI port is used for eDP and if so,
do not attach a HDMI encoder to it. However there are machines for
which the VBT eDP flag is a lie (shocking!) and we fail to detect a 
eDP link.

Furthermore, on those machines the HDMI is connected to that DDI port
but we ignore it.

If we reorder our port initialisation to try the eDP setup first and
if that fails we can treat it as a normal DP port along with a HDMI
output. To accomplish this, we have to delay registering the DP
connector/encoder until after we establish its final type.

Sorry to jump in. Could this help another use case as below ?

We have some Bytrail machine (Bayley Bay), we applied HW rework to 
disable eDP connectivity to DDI1 and enable DP on DDI 1.
But we found the i915 driver still take this DDI as eDP, not DP. we 
suspect it's because VBT still takes it as DP and so i915 driver just 
follows.


If we don't want to revise VBT in BIOS after every rework, is there 
any other way to let i915 detect this is a DP link?


Thanks
Mengdong


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

The existing code seems very carefully crafted, taking into account the
differences betweem various GPU generations etc, shuffling that around
might risk breakage. FWIW, I'm wondering if just adding a quirk for 
this single

Dell workstation might be justified?

Best regards,

Lukas



Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Jesse Barnes jbar...@virtuousgeek.org
---
  drivers/gpu/drm/i915/intel_display.c |  27 
  drivers/gpu/drm/i915/intel_dp.c  | 127

+--

  drivers/gpu/drm/i915/intel_drv.h |   6 +-
  3 files changed, 79 insertions(+), 81 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0bcd1b1aba4f..aab8dfd1f8a5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13941,7 +13941,6 @@ static void intel_setup_outputs(struct
drm_device *dev)  {
  struct drm_i915_private *dev_priv = dev-dev_private;
  struct intel_encoder *encoder;
-bool dpd_is_edp = false;

  intel_lvds_init(dev);

@@ -13983,31 +13982,33 @@ static void intel_setup_outputs(struct

drm_device *dev)

  intel_ddi_init(dev, PORT_D);
  } else if (HAS_PCH_SPLIT(dev)) {
  int found;
-dpd_is_edp = intel_dp_is_edp(dev, PORT_D);

  if (has_edp_a(dev))
  intel_dp_init(dev, DP_A, PORT_A);

+found = 0;
+/* PCH SDVOB multiplex with HDMIB */
  if (I915_READ(PCH_HDMIB)  SDVO_DETECTED) {
-/* PCH SDVOB multiplex with HDMIB */
  found = intel_sdvo_init(dev, PCH_SDVOB, true);
  if (!found)
  intel_hdmi_init(dev, PCH_HDMIB, PORT_B);
-if (!found  (I915_READ(PCH_DP_B)  DP_DETECTED))
-intel_dp_init(dev, PCH_DP_B, PORT_B);
  }
+if (!found  I915_READ(PCH_DP_B)  DP_DETECTED)
+intel_dp_init(dev, PCH_DP_B, PORT_B);

-if (I915_READ(PCH_HDMIC)  SDVO_DETECTED)
-intel_hdmi_init(dev, PCH_HDMIC, PORT_C);
-
-if (!dpd_is_edp  I915_READ(PCH_HDMID)  SDVO_DETECTED)
-intel_hdmi_init(dev, PCH_HDMID, PORT_D);
-
+found = 0;
  if (I915_READ(PCH_DP_C)  DP_DETECTED)
-intel_dp_init(dev, PCH_DP_C, PORT_C);
+found = intel_dp_init(dev, PCH_DP_C, PORT_C);
+if (found != DRM_MODE_CONNECTOR_eDP 
+I915_READ(PCH_HDMIC)  SDVO_DETECTED)
+intel_hdmi_init(dev, PCH_HDMIC, PORT_C);

+found = 0;
  if (I915_READ(PCH_DP_D)  DP_DETECTED)
-intel_dp_init(dev, PCH_DP_D, PORT_D);
+found = intel_dp_init(dev, PCH_DP_D, PORT_D);
+if (found != DRM_MODE_CONNECTOR_eDP 
+I915_READ(PCH_HDMID

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Dont enable hpd for eDP

[Sivakumar Thulasimani]

On 8/10/2015 5:07 PM, Jani Nikula wrote:

On Mon, 10 Aug 2015, Sivakumar Thulasimani sivakumar.thulasim...@intel.com 
wrote:

Reviewed-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com

On 8/10/2015 10:35 AM, Sonika Jindal wrote:

With HPD support added for all ports including PORT_A, setting hpd_pin will
result in enabling of hpd to edp as well. There is no need to enable HPD on
PORT_A hence this patch removes hpd_pin update for PORT_A, where edp will
be connected. it can be added back when required

What? You can't just go ahead and remove HPD from eDP sinks.

BR,
Jani.
Nope, we are not removing HPD for edp sinks, it was never there in the 
first place. It was
enabled for CHV (even there by mistake since PORT B/C was both DP and 
eDP) but it was
never there for any other plaforms nor is it used for any purpose (PSR 
must use it, but i

dont see code for it as well).



Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
   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 fcc64e5..5a614c9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5784,7 +5784,7 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
/* Set up the hotplug pin. */
switch (port) {
case PORT_A:
-   intel_encoder-hpd_pin = HPD_PORT_A;
+   /* Not enabling edp interrupts */
break;
case PORT_B:
intel_encoder-hpd_pin = HPD_PORT_B;

--
regards,
Sivakumar

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


--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Dont enable hpd for eDP

[Sivakumar Thulasimani]

On 8/10/2015 5:44 PM, Jani Nikula wrote:

On Mon, 10 Aug 2015, Sivakumar Thulasimani sivakumar.thulasim...@intel.com 
wrote:

On 8/10/2015 5:07 PM, Jani Nikula wrote:

On Mon, 10 Aug 2015, Sivakumar Thulasimani sivakumar.thulasim...@intel.com 
wrote:

Reviewed-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com

On 8/10/2015 10:35 AM, Sonika Jindal wrote:

With HPD support added for all ports including PORT_A, setting hpd_pin will
result in enabling of hpd to edp as well. There is no need to enable HPD on
PORT_A hence this patch removes hpd_pin update for PORT_A, where edp will
be connected. it can be added back when required

What? You can't just go ahead and remove HPD from eDP sinks.

BR,
Jani.

Nope, we are not removing HPD for edp sinks, it was never there in the
first place. It was
enabled for CHV (even there by mistake since PORT B/C was both DP and
eDP) but it was
never there for any other plaforms nor is it used for any purpose (PSR
must use it, but i
dont see code for it as well).

Are you saying there's no HPD enabled in our *hardware* for eDP? Or
driver?

My point is, is this patch making it harder to enable eDP hpd handling
(e.g. for PSR or DP link re-training) in the future? We currently take
it into account in a few places, and if we start removing that, it will
be a loss of effort to first remove and then add it back.

BR,
Jani.

i was referring to our driver only.

Our VLV/CHV code already receives hpd for every pps on and off which is
later ignored. if we dont disable HPD on eDPs this behavior will be extended
for all platforms which i feel is too costly to keep enabled when there 
is no

purpose for it right now.

if anyone later requires HPD , they might need it for PSR panels only and
since that code is not available as of now, this can be added along with 
those

changes so i feel this is the better tradeoff :)




Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
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 fcc64e5..5a614c9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5784,7 +5784,7 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
/* Set up the hotplug pin. */
switch (port) {
case PORT_A:
-   intel_encoder-hpd_pin = HPD_PORT_A;
+   /* Not enabling edp interrupts */
break;
case PORT_B:
intel_encoder-hpd_pin = HPD_PORT_B;

--
regards,
Sivakumar

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

--
regards,
Sivakumar



--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915/bxt: WA for swapped HPD pins in A stepping

[Sivakumar Thulasimani]

Reviewed-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com

On 8/10/2015 10:35 AM, Sonika Jindal wrote:

WA for BXT A0/A1, where DDIB's HPD pin is swapped to DDIA, so enabling
DDIA HPD pin in place of DDIB.

v2: For DP, irq_port is used to determine the encoder instead of
hpd_pin and removing the edp HPD logic because port A HPD is not
present(Imre)
v3: Rebased on top of Imre's patchset for enabling HPD on PORT A.
Added hpd_pin swapping for intel_dp_init_connector, setting encoder
for PORT_A as per the WA in irq_port (Imre)
v4: Dont enable interrupt for edp, also reframe the description (Siva)
v5: Don’t check for PORT_A in intel_ddi_init to update dig_port,
instead avoid setting hpd_pin itself (Imre)

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  drivers/gpu/drm/i915/intel_ddi.c  |   10 +-
  drivers/gpu/drm/i915/intel_dp.c   |2 ++
  drivers/gpu/drm/i915/intel_hdmi.c |9 -
  3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index e2c6f73..777e3a3 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3225,7 +3225,15 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
goto err;
  
  		intel_dig_port-hpd_pulse = intel_dp_hpd_pulse;

-   dev_priv-hotplug.irq_port[port] = intel_dig_port;
+   /*
+* On BXT A0/A1, sw needs to activate DDIA HPD logic and
+* interrupts to check the external panel connection.
+*/
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0)
+ port == PORT_B)
+   dev_priv-hotplug.irq_port[PORT_A] = intel_dig_port;
+   else
+   dev_priv-hotplug.irq_port[port] = intel_dig_port;
}
  
  	/* In theory we don't need the encoder-type check, but leave it just in

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 5a614c9..7fab3e5 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5788,6 +5788,8 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
break;
case PORT_B:
intel_encoder-hpd_pin = HPD_PORT_B;
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+   intel_encoder-hpd_pin = HPD_PORT_A;
break;
case PORT_C:
intel_encoder-hpd_pin = HPD_PORT_C;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 70bad5b..94fa716 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1973,7 +1973,14 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
intel_hdmi-ddc_bus = GMBUS_PIN_1_BXT;
else
intel_hdmi-ddc_bus = GMBUS_PIN_DPB;
-   intel_encoder-hpd_pin = HPD_PORT_B;
+   /*
+* On BXT A0/A1, sw needs to activate DDIA HPD logic and
+* interrupts to check the external panel connection.
+*/
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+   intel_encoder-hpd_pin = HPD_PORT_A;
+   else
+   intel_encoder-hpd_pin = HPD_PORT_B;
break;
case PORT_C:
if (IS_BROXTON(dev_priv))


--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Dont enable hpd for eDP

[Sivakumar Thulasimani]

Reviewed-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com

On 8/10/2015 10:35 AM, Sonika Jindal wrote:

With HPD support added for all ports including PORT_A, setting hpd_pin will
result in enabling of hpd to edp as well. There is no need to enable HPD on
PORT_A hence this patch removes hpd_pin update for PORT_A, where edp will
be connected. it can be added back when required

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  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 fcc64e5..5a614c9 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5784,7 +5784,7 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
/* Set up the hotplug pin. */
switch (port) {
case PORT_A:
-   intel_encoder-hpd_pin = HPD_PORT_A;
+   /* Not enabling edp interrupts */
break;
case PORT_B:
intel_encoder-hpd_pin = HPD_PORT_B;


--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915/bxt: Add HPD support for DDIA

[Sivakumar Thulasimani]

Reviewed-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com

On 8/10/2015 10:35 AM, Sonika Jindal wrote:

Also remove redundant comments.

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  drivers/gpu/drm/i915/i915_irq.c |   10 +++---
  1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 02b9e73..9b9533a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -90,6 +90,7 @@ static const u32 hpd_status_i915[HPD_NUM_PINS] = {
  
  /* BXT hpd list */

  static const u32 hpd_bxt[HPD_NUM_PINS] = {
+   [HPD_PORT_A] = BXT_DE_PORT_HP_DDIA,
[HPD_PORT_B] = BXT_DE_PORT_HP_DDIB,
[HPD_PORT_C] = BXT_DE_PORT_HP_DDIC
  };
@@ -3018,30 +3019,25 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
u32 hotplug_port = 0;
u32 hotplug_ctrl;
  
-	/* Now, enable HPD */

for_each_intel_encoder(dev, intel_encoder) {
if (dev_priv-hotplug.stats[intel_encoder-hpd_pin].state
== HPD_ENABLED)
hotplug_port |= hpd_bxt[intel_encoder-hpd_pin];
}
  
-	/* Mask all HPD control bits */

hotplug_ctrl = I915_READ(BXT_HOTPLUG_CTL)  ~BXT_HOTPLUG_CTL_MASK;
  
-	/* Enable requested port in hotplug control */

-   /* TODO: implement (short) HPD support on port A */
-   WARN_ON_ONCE(hotplug_port  BXT_DE_PORT_HP_DDIA);
+   if (hotplug_port  BXT_DE_PORT_HP_DDIA)
+   hotplug_ctrl |= BXT_DDIA_HPD_ENABLE;
if (hotplug_port  BXT_DE_PORT_HP_DDIB)
hotplug_ctrl |= BXT_DDIB_HPD_ENABLE;
if (hotplug_port  BXT_DE_PORT_HP_DDIC)
hotplug_ctrl |= BXT_DDIC_HPD_ENABLE;
I915_WRITE(BXT_HOTPLUG_CTL, hotplug_ctrl);
  
-	/* Unmask DDI hotplug in IMR */

hotplug_ctrl = I915_READ(GEN8_DE_PORT_IMR)  ~hotplug_port;
I915_WRITE(GEN8_DE_PORT_IMR, hotplug_ctrl);
  
-	/* Enable DDI hotplug in IER */

hotplug_ctrl = I915_READ(GEN8_DE_PORT_IER) | hotplug_port;
I915_WRITE(GEN8_DE_PORT_IER, hotplug_ctrl);
POSTING_READ(GEN8_DE_PORT_IER);


--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Check live status before reading edid

[Sivakumar Thulasimani]

On 7/14/2015 5:21 PM, Sonika Jindal wrote:

Adding this for SKL onwards.

v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c   |4 ++--
  drivers/gpu/drm/i915/intel_drv.h  |2 ++
  drivers/gpu/drm/i915/intel_hdmi.c |   43 +
  3 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4ebfc3a..7b54b9d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4443,8 +4443,8 @@ ironlake_dp_detect(struct intel_dp *intel_dp)
return intel_dp_detect_dpcd(intel_dp);
  }
  
-static int g4x_digital_port_connected(struct drm_device *dev,

-  struct intel_digital_port 
*intel_dig_port)
+int g4x_digital_port_connected(struct drm_device *dev,
+  struct intel_digital_port *intel_dig_port)
  {
struct drm_i915_private *dev_priv = dev-dev_private;
uint32_t bit;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a47fbc3..30c8dd6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1187,6 +1187,8 @@ void intel_edp_drrs_disable(struct intel_dp *intel_dp);
  void intel_edp_drrs_invalidate(struct drm_device *dev,
unsigned frontbuffer_bits);
  void intel_edp_drrs_flush(struct drm_device *dev, unsigned frontbuffer_bits);
+int g4x_digital_port_connected(struct drm_device *dev,
+  struct intel_digital_port *intel_dig_port);
  
  /* intel_dp_mst.c */

  int intel_dp_mst_encoder_init(struct intel_digital_port *intel_dig_port, int 
conn_id);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index c4b82ce..402be54 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1300,6 +1300,40 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
to_intel_connector(connector)-detect_edid = NULL;
  }
  
+static bool bxt_port_connected(struct drm_i915_private *dev_priv,

+  struct intel_digital_port *port)
+{
+   u32 temp = I915_READ(GEN8_DE_PORT_ISR);
+
+   /* TODO: Add bxt A0/A1 wa related to hpd pin swap */
+   switch (port-port) {
why not pass the encoder and use its hpd_pin ? that will avoid the need 
to do

A0/A1 related checks ?

+   case PORT_B:
+   return temp  BXT_DE_PORT_HP_DDIB;
+
+   case PORT_C:
+   return temp  BXT_DE_PORT_HP_DDIC;
+
+   default:
+   return false;
+
+   }
+}
+
+static bool intel_hdmi_live_status(struct intel_digital_port *intel_dig_port)
+{
+   struct drm_device *dev = intel_dig_port-base.base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   if (IS_VALLEYVIEW(dev))
+   return g4x_digital_port_connected(dev, intel_dig_port);
+   else if (IS_SKYLAKE(dev))
+   return ibx_digital_port_connected(dev_priv, intel_dig_port);
+   else if (IS_BROXTON(dev))
+   return bxt_port_connected(dev_priv, intel_dig_port);
+
+   return true;
+}
+
  static bool
  intel_hdmi_set_edid(struct drm_connector *connector)
  {
@@ -1308,15 +1342,16 @@ intel_hdmi_set_edid(struct drm_connector *connector)
struct intel_encoder *intel_encoder =
hdmi_to_dig_port(intel_hdmi)-base;
enum intel_display_power_domain power_domain;
-   struct edid *edid;
+   struct edid *edid = NULL;
bool connected = false;
  
  	power_domain = intel_display_port_power_domain(intel_encoder);

intel_display_power_get(dev_priv, power_domain);
  
-	edid = drm_get_edid(connector,

-   intel_gmbus_get_adapter(dev_priv,
-   intel_hdmi-ddc_bus));
+   if (intel_hdmi_live_status(hdmi_to_dig_port(intel_hdmi)))
+   edid = drm_get_edid(connector,
+   intel_gmbus_get_adapter(dev_priv,
+   intel_hdmi-ddc_bus));
  
  	intel_display_power_put(dev_priv, power_domain);
  


--
regards,
Sivakumar

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

[Intel-gfx] [PATCH] drm/i915: fix checksum write for automated test reply

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

DP spec requires the checksum of the last block read to be written
when replying to TEST_EDID_READ. This patch fixes the current code
to do the same.

v2: removed loop for jumping blocks and performed direct addition
as recommended by Daniel

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f1b9f93..fa6e202 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4090,9 +4090,16 @@ static uint8_t intel_dp_autotest_edid(struct intel_dp 
*intel_dp)
  intel_dp-aux.i2c_defer_count);
intel_dp-compliance_test_data = INTEL_DP_RESOLUTION_FAILSAFE;
} else {
+   struct edid *block = intel_connector-detect_edid;
+
+   /* We have to write the checksum
+* of the last block read
+*/
+   block += intel_connector-detect_edid-extensions;
+
if (!drm_dp_dpcd_write(intel_dp-aux,
DP_TEST_EDID_CHECKSUM,
-   intel_connector-detect_edid-checksum,
+   block-checksum,
1))
DRM_DEBUG_KMS(Failed to write EDID checksum\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 3/3] drm/i915: Support DDI lane reversal for DP

[Sivakumar Thulasimani]

On 8/6/2015 1:04 AM, Benjamin Tissoires wrote:

On Jul 30 2015 or thereabouts, Sivakumar Thulasimani wrote:


On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:

On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:

why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you can
identify both lane count and reversal state without touching anything in the
link training code. i am yet to upstream my changes for CHT that i can share
if required that does the same in intel_dp_detect without touching any line
in link training path.

With my current limited knowledge of the dp hotplug (and i915 driver) I
am not sure we could detect the reversed state without trying to train 1
lane only. I'd be glad to look at your changes and test them on my
system if you think that could help having a cleaner solution.

Cheers,
Benjamin

No, what i recommended was to do link training but in intel_dp_detect. Since
USB Type C cable
also has its own lane count restriction (it can have different lane count
than the one supported
by panel) you might have to figure that out as well. so both reversal and
lane count detection
can be done outside the modeset path and keep the code free of type C
changes outside
detection path.

Please find below the code to do the same. Do not waste time trying to apply
this directly on
nightly since this is based on a local tree and because this is pre- atomic
changes code, so you
might have to modify chv_upfront_link_train to work on top of the latest
nightly code. we
are supposed to upstream this and is in my todo list.


[original patch snipped...]

Hi Sivakumar,

So I managed to manually re-apply your patch on top of
drm-intel-nightly, and tried to port it to make Broadwell working too.
It works OK if the system is already boot without any external DP used.
In this case, the detection works and I can see my external monitor
working properly.

However, if the monitor is cold plugged, the cpu/GPU hangs and I can not
understand why. I think I enabled all that is mentioned in the PRM to be
able to train the DP link, but I am obviously missing something else.
Can you have a look?

My patch is now:

/snipping some more


@@ -4495,7 +4499,9 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)
struct intel_dp *intel_dp = intel_attached_dp(connector);
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct intel_encoder *intel_encoder = intel_dig_port-base;
+   struct drm_crtc *crtc = intel_dig_port-base.base.crtc;
struct drm_device *dev = connector-dev;
+   struct intel_crtc *intel_crtc;
enum drm_connector_status status;
enum intel_display_power_domain power_domain;
bool ret;
@@ -4540,6 +4546,18 @@ intel_dp_detect(struct drm_connector *connector, bool 
force)
  
  	if (intel_encoder-type != INTEL_OUTPUT_EDP)

intel_encoder-type = INTEL_OUTPUT_DISPLAYPORT;
+
+   if (intel_encoder-type == INTEL_OUTPUT_DISPLAYPORT 
+   (IS_BROADWELL(dev) || IS_CHERRYVIEW(dev))) {
+   /* Do not handle connected boot scenario where panel is enabled
+* by GOP/VBIOS.
+*/
+   if ((connector-status != connector_status_connected) 
+   !(intel_encoder-connectors_active 
+ crtc  crtc-enabled))
+   intel_upfront_link_train(dev, intel_dp, NULL);
+   }
+
here you are calling intel_upfront_link_train only if display is plugged 
in and there is no crtc associated with it.
hence your code is working on hotplug. modify the above to consider 
scenario when crtc is set and enabled
which happens when you plug in dp and boot the system. a good pointer is 
the original code :)

+if (intel_encoder-connectors_active 
+crtc  crtc-enabled) {
+intel_crtc = to_intel_crtc(crtc);
+DRM_DEBUG_KMS(Disabling crtc %c for upfront link training\n,
+pipe_name(intel_crtc-pipe));
+intel_crtc_control(crtc, false);
+}

But again, all these are experimental :), any point you touch crtc it is 
not in line with the new atomic
thinking and will not be allowed upstream till it is fixed as per the 
new way :).




status = connector_status_connected;
  
  	/* Try to read the source of the interrupt */

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 320c9e6..fcc95d5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1163,6 +1163,13 @@ bool intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
  void intel_dp_start_link_train(struct intel_dp *intel_dp);
  void intel_dp_complete_link_train(struct intel_dp *intel_dp);
  void intel_dp_stop_link_train(struct intel_dp *intel_dp);
+bool intel_upfront_link_train(struct drm_device *dev,
+ struct intel_dp *intel_dp,
+ struct

Re: [Intel-gfx] [PATCH v3.1 2/3] drm/i915: Update atomic state when removing mst connector, v3.

[Sivakumar Thulasimani]

thanks for the change :)


Reviewed-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com


On 8/6/2015 5:17 PM, Maarten Lankhorst wrote:

Fully remove the MST connector from the atomic state, and remove the
early returns in check_*_state for MST connectors.

With atomic the state can be made consistent all the time.

Thanks to Sivakumar Thulasimani for the idea of using
drm_atomic_helper_set_config.

Changes since v1:
- Remove the MST check in intel_connector_check_state too.
Changes since v2:
- Use drm_atomic_helper_set_config.

Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
Cc: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
  drivers/gpu/drm/i915/intel_display.c | 11 ---
  drivers/gpu/drm/i915/intel_dp_mst.c  | 13 -
  2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5e40b7e7013a..77b4da7e698c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6370,10 +6370,6 @@ static void intel_connector_check_state(struct 
intel_connector *connector)
  connector-base.base.id,
  connector-base.name);
  
-		/* there is no real hw state for MST connectors */

-   if (connector-mst_port)
-   return;
-
I915_STATE_WARN(connector-base.dpms == DRM_MODE_DPMS_OFF,
 wrong connector dpms state\n);
I915_STATE_WARN(connector-base.encoder != encoder-base,
@@ -12749,13 +12745,6 @@ check_encoder_state(struct drm_device *dev)
encoder-base.crtc,
 connector's crtc doesn't match encoder crtc\n);
}
-   /*
-* for MST connectors if we unplug the connector is gone
-* away but the encoder is still connected to a crtc
-* until a modeset happens in response to the hotplug.
-*/
-   if (!enabled  encoder-base.encoder_type == 
DRM_MODE_ENCODER_DPMST)
-   continue;
  
  		I915_STATE_WARN(!!encoder-base.crtc != enabled,

 encoder's enabled state mismatch 
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index ff01569158ea..91ad17110c2f 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -467,9 +467,20 @@ static void intel_dp_destroy_mst_connector(struct 
drm_dp_mst_topology_mgr *mgr,
  {
struct intel_connector *intel_connector = to_intel_connector(connector);
struct drm_device *dev = connector-dev;
+
/* need to nuke the connector */
drm_modeset_lock_all(dev);
-   intel_connector_dpms(connector, DRM_MODE_DPMS_OFF);
+   if (connector-state-crtc) {
+   struct drm_mode_set set;
+   int ret;
+
+   memset(set, 0, sizeof(set));
+   set.crtc = connector-state-crtc,
+
+   ret = drm_atomic_helper_set_config(set);
+
+   WARN(ret, Disabling mst crtc failed with %i\n, ret);
+   }
drm_modeset_unlock_all(dev);
  
  	intel_connector-unregister(intel_connector);


--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH v2 02/12] drm/i915: Update atomic state when removing mst connector.

[Sivakumar Thulasimani]

On 7/27/2015 6:05 PM, Maarten Lankhorst wrote:

Signed-off-by: Maarten Lankhorst maarten.lankho...@linux.intel.com
---
  drivers/gpu/drm/i915/intel_display.c |  7 --
  drivers/gpu/drm/i915/intel_dp_mst.c  | 45 +++-
  2 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7747520bf9f6..3ab0a8a8e702 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12751,13 +12751,6 @@ check_encoder_state(struct drm_device *dev)
encoder-base.crtc,
 connector's crtc doesn't match encoder crtc\n);
}
-   /*
-* for MST connectors if we unplug the connector is gone
-* away but the encoder is still connected to a crtc
-* until a modeset happens in response to the hotplug.
-*/
-   if (!enabled  encoder-base.encoder_type == 
DRM_MODE_ENCODER_DPMST)
-   continue;
  
  		I915_STATE_WARN(!!encoder-base.crtc != enabled,

 encoder's enabled state mismatch 
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 585f0a45b3f1..35f2eb59818a 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -448,6 +448,49 @@ static struct drm_connector 
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
return connector;
  }
  
+static void

+intel_dp_unbind_mst_connector(struct drm_device *dev,
+ struct drm_connector *connector)
+{
+   struct drm_atomic_state *state;
+   struct drm_connector_state *conn_state;
+   struct drm_crtc *crtc = connector-state-crtc;
+   int ret;
+
+   if (!crtc)
+   return;
+
why cant we call drm_atomic_helper_set_config with just crtc copied into 
struct drm_mode_set ?

+   state = drm_atomic_state_alloc(dev);
+   if (!state)
+   return;
+
+   state-acquire_ctx = dev-mode_config.acquire_ctx;
+
+   conn_state = drm_atomic_get_connector_state(state, connector);
+   ret = PTR_ERR_OR_ZERO(conn_state);
+   if (!ret)
+   ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
+
+   if (!ret)
+   ret = drm_atomic_add_affected_connectors(state, crtc);
+
+   if (!ret  !drm_atomic_connectors_for_crtc(state, crtc)) {
+   struct drm_crtc_state *crtc_state =
+   drm_atomic_get_existing_crtc_state(state, crtc);
+
+   crtc_state-active = false;
+   ret = drm_atomic_set_mode_for_crtc(crtc_state, NULL);
+   }
+
+   if (!ret)
+   ret = drm_atomic_commit(state);
+
+   if (ret)
+   drm_atomic_state_free(state);
+
+   I915_STATE_WARN_ON(ret);
+}
+
  static void intel_dp_destroy_mst_connector(struct drm_dp_mst_topology_mgr 
*mgr,
   struct drm_connector *connector)
  {
@@ -455,7 +498,7 @@ static void intel_dp_destroy_mst_connector(struct 
drm_dp_mst_topology_mgr *mgr,
struct drm_device *dev = connector-dev;
/* need to nuke the connector */
drm_modeset_lock_all(dev);
-   intel_connector_dpms(connector, DRM_MODE_DPMS_OFF);
+   intel_dp_unbind_mst_connector(dev, connector);
drm_modeset_unlock_all(dev);
  
  	intel_connector-unregister(intel_connector);


--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH] drm/i915/bxt: WA for swapped HPD pins in A stepping

[Sivakumar Thulasimani]

On 8/5/2015 3:23 PM, Imre Deak wrote:

On Mon, 2015-07-27 at 11:02 +0530, Sonika Jindal wrote:

WA for BXT A0/A1, where DDIB's HPD pin is swapped to DDIA, so enabling
DDIA HPD pin in place of DDIB.

v2: For DP, irq_port is used to determine the encoder instead of
hpd_pin and removing the edp HPD logic because port A HPD is not
present(Imre)
v3: Rebased on top of Imre's patchset for enabling HPD on PORT A.
Added hpd_pin swapping for intel_dp_init_connector, setting encoder
for PORT_A as per the WA in irq_port (Imre)
v4: Dont enable interrupt for edp, also reframe the description (Siva)

Signed-off-by: Sonika Jindal sonika.jin...@intel.com

This patch is a new version of 2/2 of your patchset at
http://lists.freedesktop.org/archives/intel-gfx/2015-July/071580.html

so this should've been sent either as a reply to the individual v1 patch
there, or just by resending the whole patchset. For now you could just
resend the whole patchset. Also please add the version info to the
subject with git format-patch --subject-prefix.



---
  drivers/gpu/drm/i915/intel_ddi.c  |   11 ++-
  drivers/gpu/drm/i915/intel_dp.c   |4 
  drivers/gpu/drm/i915/intel_hdmi.c |9 -
  3 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index e2c6f73..8d7ffe0 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3225,7 +3225,16 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
goto err;
  
  		intel_dig_port-hpd_pulse = intel_dp_hpd_pulse;

-   dev_priv-hotplug.irq_port[port] = intel_dig_port;
+   /*
+* On BXT A0/A1, sw needs to activate DDIA HPD logic and
+* interrupts to check the external panel connection.
+*/
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0)
+ port == PORT_B)
+   dev_priv-hotplug.irq_port[PORT_A] = intel_dig_port;
+   /* Dont enable interrupts for edp*/
+   else if (port != PORT_A)
+   dev_priv-hotplug.irq_port[port] = intel_dig_port;

Not enabling HPD on eDP is not a BXT specific change (even though it's
disabled now everywhere), so that part should be a separate patch and
ordered before patch 1/2. Also this isn't the proper place to disable
HPD handling; as long as the corresponding intel_encoder-hpd_pin is set
the relevant interrupt will get unmasked and hotplug_work will be
called. See bxt_hpd_irq_setup() and intel_hpd_irq_handler().

hmm , ok Sonika, please remove HPD_PORT_A being set for PORT_A. here 
else if can

be modified to simple else

}
  
  	/* In theory we don't need the encoder-type check, but leave it just in

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fcc64e5..71679ef 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5785,9 +5785,13 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
switch (port) {
case PORT_A:
intel_encoder-hpd_pin = HPD_PORT_A;
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+   intel_encoder-hpd_pin = HPD_PORT_C;
break;
case PORT_B:
intel_encoder-hpd_pin = HPD_PORT_B;
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+   intel_encoder-hpd_pin = HPD_PORT_A;
break;
case PORT_C:
intel_encoder-hpd_pin = HPD_PORT_C;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 70bad5b..94fa716 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1973,7 +1973,14 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
intel_hdmi-ddc_bus = GMBUS_PIN_1_BXT;
else
intel_hdmi-ddc_bus = GMBUS_PIN_DPB;
-   intel_encoder-hpd_pin = HPD_PORT_B;
+   /*
+* On BXT A0/A1, sw needs to activate DDIA HPD logic and
+* interrupts to check the external panel connection.
+*/
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+   intel_encoder-hpd_pin = HPD_PORT_A;
+   else
+   intel_encoder-hpd_pin = HPD_PORT_B;
break;
case PORT_C:
if (IS_BROXTON(dev_priv))







--
regards,
Sivakumar


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

Re: [Intel-gfx] [PATCH] drm/i915: remove intermediate link rate entries for CHV

[Sivakumar Thulasimani]

On 7/30/2015 10:48 PM, Hindman, Gavin wrote:

This applies to all CHV derivatives, including BSW?

Gavin Hindman

yes, this will apply to all CHV derivatives.

-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of 
Sivakumar Thulasimani
Sent: Thursday, July 30, 2015 1:45 AM
To: ville.syrj...@linux.intel.com; intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH] drm/i915: remove intermediate link rate entries 
for CHV

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

CHV does not support intermediate link rates nor does it support HBR2. This 
patch removes those entries and returns HBR as the max link rate supported on 
CHV platform.

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c |   11 +++
  1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c 
index 898dc74..5c68b17 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -95,9 +95,6 @@ static const int bxt_rates[] = { 162000, 216000, 243000, 
27,
  324000, 432000, 54 };
  static const int skl_rates[] = { 162000, 216000, 27,
  324000, 432000, 54 };
-static const int chv_rates[] = { 162000, 202500, 21, 216000,
-243000, 27, 324000, 405000,
-42, 432000, 54 };
  static const int default_rates[] = { 162000, 27, 54 };
  
  /**

@@ -1186,15 +1183,13 @@ intel_dp_source_rates(struct drm_device *dev, const int 
**source_rates)
} else if (IS_SKYLAKE(dev)) {
*source_rates = skl_rates;
return ARRAY_SIZE(skl_rates);
-   } else if (IS_CHERRYVIEW(dev)) {
-   *source_rates = chv_rates;
-   return ARRAY_SIZE(chv_rates);
}
  
  	*source_rates = default_rates;
  
-	if (IS_SKYLAKE(dev)  INTEL_REVID(dev) = SKL_REVID_B0)

-   /* WaDisableHBR2:skl */
+   /* WaDisableHBR2:skl */
+   if ((IS_SKYLAKE(dev)  INTEL_REVID(dev) = SKL_REVID_B0) ||
+   IS_CHERRYVIEW(dev))
return (DP_LINK_BW_2_7  3) + 1;
else if (INTEL_INFO(dev)-gen = 8 ||
(IS_HASWELL(dev)  !IS_HSW_ULX(dev)))
--
1.7.9.5

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


--
regards,
Sivakumar

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

[Intel-gfx] [PATCH 1/2] Revert drm/i915: Add eDP intermediate frequencies for CHV

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This reverts
commit fe51bfb95c996733150c44d21e1c9f4b6322a326.
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date:   Thu Mar 12 17:10:38 2015 +0200

CHV does not support intermediate frequencies so reverting the
patch that added it in the first place

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44f8a32..d9fb7a8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -95,9 +95,6 @@ static const int bxt_rates[] = { 162000, 216000, 243000, 
27,
  324000, 432000, 54 };
 static const int skl_rates[] = { 162000, 216000, 27,
  324000, 432000, 54 };
-static const int chv_rates[] = { 162000, 202500, 21, 216000,
-243000, 27, 324000, 405000,
-42, 432000, 54 };
 static const int default_rates[] = { 162000, 27, 54 };
 
 /**
@@ -1185,9 +1182,6 @@ intel_dp_source_rates(struct drm_device *dev, const int 
**source_rates)
} else if (IS_SKYLAKE(dev)) {
*source_rates = skl_rates;
return ARRAY_SIZE(skl_rates);
-   } else if (IS_CHERRYVIEW(dev)) {
-   *source_rates = chv_rates;
-   return ARRAY_SIZE(chv_rates);
}
 
*source_rates = default_rates;
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 2/2] drm/i915: remove HBR2 from chv supported list

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

This patch removes 5.4Gbps from supported link rate for CHV since
it is not supported in it.

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index d9fb7a8..4e53433 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1186,8 +1186,9 @@ intel_dp_source_rates(struct drm_device *dev, const int 
**source_rates)
 
*source_rates = default_rates;
 
-   if (IS_SKYLAKE(dev)  INTEL_REVID(dev) = SKL_REVID_B0)
-   /* WaDisableHBR2:skl */
+   /* WaDisableHBR2:skl */
+   if ((IS_SKYLAKE(dev)  INTEL_REVID(dev) = SKL_REVID_B0) ||
+   IS_CHERRYVIEW(dev))
return (DP_LINK_BW_2_7  3) + 1;
else if (INTEL_INFO(dev)-gen = 8 ||
(IS_HASWELL(dev)  !IS_HSW_ULX(dev)))
-- 
1.7.9.5

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

[Intel-gfx] [PATCH] drm/i915: read bpp from vbt only for older panels

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

BPP bits defined in VBT should be used only on panels whose
edid version is 1.3 or older. EDID version 1.4 introduced offsets
where bpp is defined and read into display_info, hence bpp from
VBT will be used only when bpc in display_info is zero.

v2: use display_info.bpc for deciding when to use vbt_bpp (Jani)

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44f8a32..ae00e86 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1409,7 +1409,10 @@ intel_dp_compute_config(struct intel_encoder *encoder,
 * bpc in between. */
bpp = pipe_config-pipe_bpp;
if (is_edp(intel_dp)) {
-   if (dev_priv-vbt.edp_bpp  dev_priv-vbt.edp_bpp  bpp) {
+
+   /* Get bpp from vbt only for panels that dont have bpp in edid 
*/
+   if (intel_connector-base.display_info.bpc == 0 
+   (dev_priv-vbt.edp_bpp  dev_priv-vbt.edp_bpp  bpp)) 
{
DRM_DEBUG_KMS(clamping bpp for eDP panel to 
BIOS-provided %i\n,
  dev_priv-vbt.edp_bpp);
bpp = dev_priv-vbt.edp_bpp;
-- 
1.7.9.5

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

[Intel-gfx] [PATCH] drm/i915: read bpp from vbt only for older panels

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

BPP bits defined in VBT should be used only on panels whose
edid version is 1.3 or older. EDID version 1.4 introduced offsets
where bpp is defined and hence should be preferred over any value
programmed in VBT.

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |   11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44f8a32..898dc74 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -132,6 +132,7 @@ static void edp_panel_vdd_off(struct intel_dp *intel_dp, 
bool sync);
 static void vlv_init_panel_power_sequencer(struct intel_dp *intel_dp);
 static void vlv_steal_power_sequencer(struct drm_device *dev,
  enum pipe pipe);
+static struct edid * intel_dp_get_edid(struct intel_dp *intel_dp);
 
 static int
 intel_dp_max_link_bw(struct intel_dp  *intel_dp)
@@ -1353,6 +1354,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
enum port port = dp_to_dig_port(intel_dp)-port;
struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config-base.crtc);
struct intel_connector *intel_connector = intel_dp-attached_connector;
+   struct edid *edid = NULL;
int lane_count, clock;
int min_lane_count = 1;
int max_lane_count = intel_dp_max_lane_count(intel_dp);
@@ -1409,12 +1411,19 @@ intel_dp_compute_config(struct intel_encoder *encoder,
 * bpc in between. */
bpp = pipe_config-pipe_bpp;
if (is_edp(intel_dp)) {
-   if (dev_priv-vbt.edp_bpp  dev_priv-vbt.edp_bpp  bpp) {
+   edid = intel_dp_get_edid(intel_dp);
+
+   /* Get bpp from vbt only for panels with edid 1.3 or older */
+   if (edid  edid-version == 1  edid-revision = 3  
+   (dev_priv-vbt.edp_bpp  dev_priv-vbt.edp_bpp  bpp)) 
{
DRM_DEBUG_KMS(clamping bpp for eDP panel to 
BIOS-provided %i\n,
  dev_priv-vbt.edp_bpp);
bpp = dev_priv-vbt.edp_bpp;
}
 
+   if (edid)
+   kfree(edid);
+
/*
 * Use the maximum clock and number of lanes the eDP panel
 * advertizes being capable of. The panels are generally
-- 
1.7.9.5

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

[Intel-gfx] [PATCH] drm/i915: remove intermediate link rate entries for CHV

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

CHV does not support intermediate link rates nor does it support
HBR2. This patch removes those entries and returns HBR as the max
link rate supported on CHV platform.

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |   11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 898dc74..5c68b17 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -95,9 +95,6 @@ static const int bxt_rates[] = { 162000, 216000, 243000, 
27,
  324000, 432000, 54 };
 static const int skl_rates[] = { 162000, 216000, 27,
  324000, 432000, 54 };
-static const int chv_rates[] = { 162000, 202500, 21, 216000,
-243000, 27, 324000, 405000,
-42, 432000, 54 };
 static const int default_rates[] = { 162000, 27, 54 };
 
 /**
@@ -1186,15 +1183,13 @@ intel_dp_source_rates(struct drm_device *dev, const int 
**source_rates)
} else if (IS_SKYLAKE(dev)) {
*source_rates = skl_rates;
return ARRAY_SIZE(skl_rates);
-   } else if (IS_CHERRYVIEW(dev)) {
-   *source_rates = chv_rates;
-   return ARRAY_SIZE(chv_rates);
}
 
*source_rates = default_rates;
 
-   if (IS_SKYLAKE(dev)  INTEL_REVID(dev) = SKL_REVID_B0)
-   /* WaDisableHBR2:skl */
+   /* WaDisableHBR2:skl */
+   if ((IS_SKYLAKE(dev)  INTEL_REVID(dev) = SKL_REVID_B0) ||
+   IS_CHERRYVIEW(dev))
return (DP_LINK_BW_2_7  3) + 1;
else if (INTEL_INFO(dev)-gen = 8 ||
(IS_HASWELL(dev)  !IS_HSW_ULX(dev)))
-- 
1.7.9.5

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

Re: [Intel-gfx] [PATCH] drm/i915: read bpp from vbt only for older panels

[Sivakumar Thulasimani]

On 7/30/2015 3:27 PM, Jani Nikula wrote:

On Thu, 30 Jul 2015, Sivakumar Thulasimani sivakumar.thulasim...@intel.com 
wrote:

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

BPP bits defined in VBT should be used only on panels whose
edid version is 1.3 or older. EDID version 1.4 introduced offsets
where bpp is defined and hence should be preferred over any value
programmed in VBT.

Should we actually look at the EDID bpp somewhere?

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c |   11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44f8a32..898dc74 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -132,6 +132,7 @@ static void edp_panel_vdd_off(struct intel_dp *intel_dp, 
bool sync);
  static void vlv_init_panel_power_sequencer(struct intel_dp *intel_dp);
  static void vlv_steal_power_sequencer(struct drm_device *dev,
  enum pipe pipe);
+static struct edid * intel_dp_get_edid(struct intel_dp *intel_dp);
  
  static int

  intel_dp_max_link_bw(struct intel_dp  *intel_dp)
@@ -1353,6 +1354,7 @@ intel_dp_compute_config(struct intel_encoder *encoder,
enum port port = dp_to_dig_port(intel_dp)-port;
struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config-base.crtc);
struct intel_connector *intel_connector = intel_dp-attached_connector;
+   struct edid *edid = NULL;
int lane_count, clock;
int min_lane_count = 1;
int max_lane_count = intel_dp_max_lane_count(intel_dp);
@@ -1409,12 +1411,19 @@ intel_dp_compute_config(struct intel_encoder *encoder,
 * bpc in between. */
bpp = pipe_config-pipe_bpp;
if (is_edp(intel_dp)) {
-   if (dev_priv-vbt.edp_bpp  dev_priv-vbt.edp_bpp  bpp) {
+   edid = intel_dp_get_edid(intel_dp);
+
+   /* Get bpp from vbt only for panels with edid 1.3 or older */
+   if (edid  edid-version == 1  edid-revision = 3  
+   (dev_priv-vbt.edp_bpp  dev_priv-vbt.edp_bpp  bpp)) 
{

Now you require the panel to have an EDID in order to use the bpp in
VBT.

BR,
Jani.

will update with a new patch that will remove this expectation.

DRM_DEBUG_KMS(clamping bpp for eDP panel to BIOS-provided 
%i\n,
  dev_priv-vbt.edp_bpp);
bpp = dev_priv-vbt.edp_bpp;
}
  
+		if (edid)

+   kfree(edid);
+
/*
 * Use the maximum clock and number of lanes the eDP panel
 * advertizes being capable of. The panels are generally
--
1.7.9.5

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


--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH] drm/i915: remove intermediate link rate entries for CHV

[Sivakumar Thulasimani]

On 7/30/2015 3:31 PM, Jani Nikula wrote:

On Thu, 30 Jul 2015, Sivakumar Thulasimani sivakumar.thulasim...@intel.com 
wrote:

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

CHV does not support intermediate link rates nor does it support
HBR2. This patch removes those entries and returns HBR as the max
link rate supported on CHV platform.

These are two separate changes, and should be two separate
patches. Moreover, the intermediate link rate change should be a revert
of

commit fe51bfb95c996733150c44d21e1c9f4b6322a326
Author: Ville Syrjälä ville.syrj...@linux.intel.com
Date:   Thu Mar 12 17:10:38 2015 +0200

 drm/i915: Add eDP intermediate frequencies for CHV

with Cc: Ville and Sonika to record this back and forth here.

BR,
Jani.
Sure, will share new patch that will revert the above one and create a 
new patch

for restricting CHV to HBR.



Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c |   11 +++
  1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 898dc74..5c68b17 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -95,9 +95,6 @@ static const int bxt_rates[] = { 162000, 216000, 243000, 
27,
  324000, 432000, 54 };
  static const int skl_rates[] = { 162000, 216000, 27,
  324000, 432000, 54 };
-static const int chv_rates[] = { 162000, 202500, 21, 216000,
-243000, 27, 324000, 405000,
-42, 432000, 54 };
  static const int default_rates[] = { 162000, 27, 54 };
  
  /**

@@ -1186,15 +1183,13 @@ intel_dp_source_rates(struct drm_device *dev, const int 
**source_rates)
} else if (IS_SKYLAKE(dev)) {
*source_rates = skl_rates;
return ARRAY_SIZE(skl_rates);
-   } else if (IS_CHERRYVIEW(dev)) {
-   *source_rates = chv_rates;
-   return ARRAY_SIZE(chv_rates);
}
  
  	*source_rates = default_rates;
  
-	if (IS_SKYLAKE(dev)  INTEL_REVID(dev) = SKL_REVID_B0)

-   /* WaDisableHBR2:skl */
+   /* WaDisableHBR2:skl */
+   if ((IS_SKYLAKE(dev)  INTEL_REVID(dev) = SKL_REVID_B0) ||
+   IS_CHERRYVIEW(dev))
return (DP_LINK_BW_2_7  3) + 1;
else if (INTEL_INFO(dev)-gen = 8 ||
(IS_HASWELL(dev)  !IS_HSW_ULX(dev)))
--
1.7.9.5

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


--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for DP

[Sivakumar Thulasimani]

On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:

On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:

why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you can
identify both lane count and reversal state without touching anything in the
link training code. i am yet to upstream my changes for CHT that i can share
if required that does the same in intel_dp_detect without touching any line
in link training path.

With my current limited knowledge of the dp hotplug (and i915 driver) I
am not sure we could detect the reversed state without trying to train 1
lane only. I'd be glad to look at your changes and test them on my
system if you think that could help having a cleaner solution.

Cheers,
Benjamin
No, what i recommended was to do link training but in intel_dp_detect. 
Since USB Type C cable
also has its own lane count restriction (it can have different lane 
count than the one supported
by panel) you might have to figure that out as well. so both reversal 
and lane count detection
can be done outside the modeset path and keep the code free of type C 
changes outside

detection path.

Please find below the code to do the same. Do not waste time trying to 
apply this directly on
nightly since this is based on a local tree and because this is pre- 
atomic changes code, so you
might have to modify chv_upfront_link_train to work on top of the latest 
nightly code. we

are supposed to upstream this and is in my todo list.

---

Author: Durgadoss R durgados...@intel.com
Date:   Fri May 22 14:30:07 2015 +0530

   drm/i915: Enable Upfront link training for type-C DP support

To support USB type C alternate DP mode, the display driver needs 
to know the
number of lanes required by DP panel as well as number of lanes 
that can be
supported by the type-C cable. Sometimes, the type-C cable may 
limit the
bandwidth even if Panel can support more lanes. To address these 
scenarios,
the display driver will start link training with max lanes, and if 
the link

training fails, the driver then falls back to x2 lanes.

* Since link training is done before modeset, planes are not 
enabled. Only

  encoder and the its associated PLLs are enabled.
* Once link training is done, the encoder and its PLLs are 
disabled; so that

  the subsequent modeset is not aware of these changes.
* As of now, this is tested only on CHV.

Signed-off-by: Durgadoss R durgados...@intel.com

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c

index 0c8ae2a..c72dcaa 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14793,3 +14793,121 @@ intel_display_print_error_state(struct 
drm_i915_error_state_buf *m,

 err_printf(m,   VSYNC: %08x\n, error-transcoder[i].vsync);
 }
 }
+
+bool chv_upfront_link_train(struct drm_device *dev,
+struct intel_dp *intel_dp, struct intel_crtc *crtc)
+{
+struct drm_i915_private *dev_priv = dev-dev_private;
+struct intel_connector *connector = intel_dp-attached_connector;
+struct intel_encoder *encoder = connector-encoder;
+bool found = false;
+bool valid_crtc = false;
+
+if (!connector || !encoder) {
+DRM_DEBUG_KMS(dp connector/encoder is NULL\n);
+return false;
+}
+
+/* If we already have a crtc, start link training directly */
+if (crtc) {
+valid_crtc = true;
+goto start_link_train;
+}
+
+/* Find an unused crtc and use it for link training */
+for_each_intel_crtc(dev, crtc) {
+if (intel_crtc_active(crtc-base))
+continue;
+
+connector-new_encoder = encoder;
+encoder-new_crtc = crtc;
+encoder-base.crtc = crtc-base;
+
+/* Make sure the new crtc will work with the encoder */
+if (drm_encoder_crtc_ok(encoder-base,
+ crtc-base)) {
+found = true;
+break;
+}
+}
+
+if (!found) {
+DRM_ERROR(Could not find crtc for upfront link training\n);
+return false;
+}
+
+start_link_train:
+
+DRM_DEBUG_KMS(upfront link training on pipe:%c\n,
+pipe_name(crtc-pipe));
+found = false;
+
+/* Initialize with Max Link rate  lane count supported by panel */
+intel_dp-link_bw =  intel_dp-dpcd[DP_MAX_LINK_RATE];
+intel_dp-lane_count = intel_dp-dpcd[DP_MAX_LANE_COUNT] 
+DP_MAX_LANE_COUNT_MASK;
+
+do {
+/* Find port clock from link_bw */
+crtc-config.port_clock =
+drm_dp_bw_code_to_link_rate(intel_dp-link_bw);
+
+/* Enable PLL followed by port */
+intel_dp_set_clock(encoder, crtc-config, intel_dp-link_bw);
+chv_update_pll(crtc);
+encoder-pre_pll_enable(encoder);
+chv_enable_pll(crtc);
+encoder

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Support DDI lane reversal for DP

[Sivakumar Thulasimani]

why not detect reverse in intel_dp_detect/intel_hpd_pulse ? that way you 
can identify both lane count and reversal state without touching 
anything in the link training code. i am yet to upstream my changes for 
CHT that i can share if required that does the same in intel_dp_detect 
without touching any line in link training path.


On 7/28/2015 9:33 PM, Benjamin Tissoires wrote:

The DP outputs connected through a USB Type-C port can have inverted
lanes. To detect that case, we implement autodetection by training only
the first lane if it doesn't work, we assume that we need to invert
the lanes.

Tested on a Chromebook Pixel 2015 (samus) with a USB Type-C to HDMI
adapter and a Dell 4K and some various regular monitors.

Based on 2 patches from the ChromeOS tree by:
Stéphane Marchesin marc...@chromium.org
Todd Broch tbr...@chromium.org

Signed-off-by: Benjamin Tissoires benjamin.tissoi...@redhat.com
---
  drivers/gpu/drm/i915/intel_ddi.c | 13 +
  drivers/gpu/drm/i915/intel_dp.c  | 36 
  drivers/gpu/drm/i915/intel_drv.h |  1 +
  3 files changed, 50 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 9a40bfb..0b0c1ec 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2249,6 +2249,7 @@ static void intel_ddi_pre_enable(struct intel_encoder 
*intel_encoder)
enum port port = intel_ddi_get_encoder_port(intel_encoder);
int type = intel_encoder-type;
int hdmi_level;
+   bool reversed = false;
  
  	if (type == INTEL_OUTPUT_EDP) {

struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
@@ -2295,8 +2296,20 @@ static void intel_ddi_pre_enable(struct intel_encoder 
*intel_encoder)
if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) {
struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
  
+		if (IS_BROADWELL(dev)  type == INTEL_OUTPUT_DISPLAYPORT) {

+   intel_ddi_init_dp_buf_reg(intel_encoder);
+   reversed = intel_dp_is_reversed(intel_dp);
+   }
+
intel_ddi_init_dp_buf_reg(intel_encoder);
  
+		if (IS_BROADWELL(dev)) {

+   if (reversed)
+   intel_dp-DP |= DDI_BUF_PORT_REVERSAL;
+   else
+   intel_dp-DP = ~DDI_BUF_PORT_REVERSAL;
+   }
+
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
intel_dp_start_link_train(intel_dp);
intel_dp_complete_link_train(intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b740987..18280cc 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3820,6 +3820,42 @@ intel_dp_complete_link_train(struct intel_dp *intel_dp)
intel_dp-DP = DP;
  }
  
+bool intel_dp_is_reversed(struct intel_dp *intel_dp)

+{
+   struct drm_encoder *encoder = dp_to_dig_port(intel_dp)-base.base;
+   struct drm_device *dev = encoder-dev;
+   struct drm_i915_private *dev_priv = dev-dev_private;
+   uint32_t DP = intel_dp-DP;
+
+   /*
+* Train with 1 lane. There is no guarantee that the monitor supports
+* 2 or 4 lanes, and we wouldn't see any asymetricity with 4 lanes.
+*/
+   const uint8_t lane_count = 1;
+   bool reversed;
+
+   if (!HAS_DDI(dev))
+   return false;
+
+   DP = ~(DDI_BUF_PORT_REVERSAL | DDI_PORT_WIDTH(4));
+   DP |= DDI_PORT_WIDTH(lane_count);
+
+   I915_WRITE(intel_dp-output_reg, DP);
+   POSTING_READ(intel_dp-output_reg);
+   udelay(600);
+
+   if (!_intel_dp_start_link_train(intel_dp, lane_count, DP, true))
+   return true;
+
+   reversed = !_intel_dp_complete_link_train(intel_dp, lane_count, DP, 
true);
+
+   /* clear training, we had only one lane */
+   intel_dp-train_set_valid = false;
+
+   return reversed;
+
+}
+
  void intel_dp_stop_link_train(struct intel_dp *intel_dp)
  {
intel_dp_set_link_train(intel_dp, intel_dp-DP,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 320c9e6..cba00c6 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1169,6 +1169,7 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc);
  bool intel_dp_compute_config(struct intel_encoder *encoder,
 struct intel_crtc_state *pipe_config);
  bool intel_dp_is_edp(struct drm_device *dev, enum port port);
+bool intel_dp_is_reversed(struct intel_dp *intel_dp);
  enum irqreturn intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port,
  bool long_hpd);
  void intel_edp_backlight_on(struct intel_dp *intel_dp);


--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH] drm/i915/bxt: WA for swapped HPD pins in A stepping

[Sivakumar Thulasimani]

Reviewed-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com


On 7/27/2015 11:02 AM, Sonika Jindal wrote:

WA for BXT A0/A1, where DDIB's HPD pin is swapped to DDIA, so enabling
DDIA HPD pin in place of DDIB.

v2: For DP, irq_port is used to determine the encoder instead of
hpd_pin and removing the edp HPD logic because port A HPD is not
present(Imre)
v3: Rebased on top of Imre's patchset for enabling HPD on PORT A.
Added hpd_pin swapping for intel_dp_init_connector, setting encoder
for PORT_A as per the WA in irq_port (Imre)
v4: Dont enable interrupt for edp, also reframe the description (Siva)

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  drivers/gpu/drm/i915/intel_ddi.c  |   11 ++-
  drivers/gpu/drm/i915/intel_dp.c   |4 
  drivers/gpu/drm/i915/intel_hdmi.c |9 -
  3 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index e2c6f73..8d7ffe0 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3225,7 +3225,16 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
goto err;
  
  		intel_dig_port-hpd_pulse = intel_dp_hpd_pulse;

-   dev_priv-hotplug.irq_port[port] = intel_dig_port;
+   /*
+* On BXT A0/A1, sw needs to activate DDIA HPD logic and
+* interrupts to check the external panel connection.
+*/
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0)
+ port == PORT_B)
+   dev_priv-hotplug.irq_port[PORT_A] = intel_dig_port;
+   /* Dont enable interrupts for edp*/
+   else if (port != PORT_A)
+   dev_priv-hotplug.irq_port[port] = intel_dig_port;
}
  
  	/* In theory we don't need the encoder-type check, but leave it just in

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fcc64e5..71679ef 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5785,9 +5785,13 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
switch (port) {
case PORT_A:
intel_encoder-hpd_pin = HPD_PORT_A;
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+   intel_encoder-hpd_pin = HPD_PORT_C;
break;
case PORT_B:
intel_encoder-hpd_pin = HPD_PORT_B;
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+   intel_encoder-hpd_pin = HPD_PORT_A;
break;
case PORT_C:
intel_encoder-hpd_pin = HPD_PORT_C;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 70bad5b..94fa716 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1973,7 +1973,14 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
intel_hdmi-ddc_bus = GMBUS_PIN_1_BXT;
else
intel_hdmi-ddc_bus = GMBUS_PIN_DPB;
-   intel_encoder-hpd_pin = HPD_PORT_B;
+   /*
+* On BXT A0/A1, sw needs to activate DDIA HPD logic and
+* interrupts to check the external panel connection.
+*/
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+   intel_encoder-hpd_pin = HPD_PORT_A;
+   else
+   intel_encoder-hpd_pin = HPD_PORT_B;
break;
case PORT_C:
if (IS_BROXTON(dev_priv))


--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH] drm/i915: fix checksum write for automated test reply

[Sivakumar Thulasimani]

Any comments for this change ?

On 7/22/2015 6:31 PM, Sivakumar Thulasimani wrote:

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

DP spec requires the checksum of the last block read to be written
when replying to TEST_EDID_READ. This patch fixes the current code
to do the same.

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c |9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f1b9f93..fa6e202 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4090,9 +4090,16 @@ static uint8_t intel_dp_autotest_edid(struct intel_dp 
*intel_dp)
  intel_dp-aux.i2c_defer_count);
intel_dp-compliance_test_data = INTEL_DP_RESOLUTION_FAILSAFE;
} else {
+   struct edid *block = intel_connector-detect_edid;
+
+   /* We have to write the checksum
+* of the last block read
+*/
+   block += intel_connector-detect_edid-extensions;
+
if (!drm_dp_dpcd_write(intel_dp-aux,
DP_TEST_EDID_CHECKSUM,
-   intel_connector-detect_edid-checksum,
+   block-checksum,
1))
DRM_DEBUG_KMS(Failed to write EDID checksum\n);
  


--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH] drm/i915: Parsing LFP brightness control from VBT

[Sivakumar Thulasimani]

On 7/6/2015 4:35 PM, Vandana Kannan wrote:

From: Deepak M m.dee...@intel.com

LFP brighness control from the VBT block 43 indicates which
controller is used for brightness.
LFP1 brightness control method:
Bit 7-4 = This field controller number of the brightnes controller.
0 = Controller 0
1 = Controller 1
2 = Controller 2
3 = Controller 3
Others = Reserved

Bits 3-0 are for Control pin
0 = PMIC pin is used for brightness control
1 = LPSS PWM is used for brightness control
2 = Display DDI is used for brightness control
3 = CABC method to control brightness
Others = Reserved

History:
This patch was submitted earlier including a check for control pin.
http://lists.freedesktop.org/archives/intel-gfx/2014-December/057530.html
Since it caused the issue, https://bugs.freedesktop.org/show_bug.cgi?id=87671,
it was reverted in
http://lists.freedesktop.org/archives/intel-gfx/2015-January/058110.html

The current patch reads controller and control pin from VBT (version = 191)

 From VBT version = 197, default value of control pin is set to DDI, so the
corresponding check during backlight setup will be made in a future patch

Signed-off-by: Deepak M m.dee...@intel.com
Signed-off-by: Vandana Kannan vandana.kan...@intel.com
Cc: Jani Nikula jani.nik...@intel.com
---
  drivers/gpu/drm/i915/i915_drv.h   |  2 ++
  drivers/gpu/drm/i915/intel_bios.c |  9 +
  drivers/gpu/drm/i915/intel_bios.h | 11 +++
  3 files changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 950a981..a89e9a9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1461,6 +1461,8 @@ struct intel_vbt_data {
bool present;
bool active_low_pwm;
u8 min_brightness;  /* min_brightness/255 of max */
+   u8 controller;  /* brightness controller number */
+   u8 control_pin; /* brightness control pin */
} backlight;
  
  	/* MIPI DSI */

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 2ff9eb0..32c1ef2 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -256,6 +256,7 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv,
  {
const struct bdb_lfp_backlight_data *backlight_data;
const struct bdb_lfp_backlight_data_entry *entry;
+   const struct bdb_lfp_backlight_control_data *bl_ctrl_data;
  
  	backlight_data = find_section(bdb, BDB_LVDS_BACKLIGHT);

if (!backlight_data)
@@ -268,6 +269,7 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv,
}
  
  	entry = backlight_data-data[panel_type];

+   bl_ctrl_data = backlight_data-blc_ctl[panel_type];
  
  	dev_priv-vbt.backlight.present = entry-type == BDB_BACKLIGHT_TYPE_PWM;

if (!dev_priv-vbt.backlight.present) {
@@ -279,12 +281,19 @@ parse_lfp_backlight(struct drm_i915_private *dev_priv,
dev_priv-vbt.backlight.pwm_freq_hz = entry-pwm_freq_hz;
dev_priv-vbt.backlight.active_low_pwm = entry-active_low_pwm;
dev_priv-vbt.backlight.min_brightness = entry-min_brightness;
+   dev_priv-vbt.backlight.controller = bl_ctrl_data-controller;
+   dev_priv-vbt.backlight.control_pin = bl_ctrl_data-pin;
+
DRM_DEBUG_KMS(VBT backlight PWM modulation frequency %u Hz, 
  active %s, min brightness %u, level %u\n,
  dev_priv-vbt.backlight.pwm_freq_hz,
  dev_priv-vbt.backlight.active_low_pwm ? low : high,
  dev_priv-vbt.backlight.min_brightness,
  backlight_data-level[panel_type]);
+
+   DRM_DEBUG_KMS(VBT BL controller %u, BL control pin %u\n,
+   dev_priv-vbt.backlight.controller,
+   dev_priv-vbt.backlight.control_pin);
  }
  
  /* Try to find sdvo panel data */

diff --git a/drivers/gpu/drm/i915/intel_bios.h 
b/drivers/gpu/drm/i915/intel_bios.h
index af0b476..e97c1c0 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -402,10 +402,21 @@ struct bdb_lfp_backlight_data_entry {
u8 obsolete3;
  } __packed;
  
+#define BLC_CONTROL_PIN_PMIC   0

+#define BLC_CONTROL_PIN_LPSS_PWM   1
+#define BLC_CONTROL_PIN_DDI2
+#define BLC_CONTROL_PIN_CABC   3
+
+struct bdb_lfp_backlight_control_data {
+   u8 controller:4;
+   u8 pin:4;

the pin should be first half of this struct.
pin - 0:3
controller - 4:7

+} __packed;
+
  struct bdb_lfp_backlight_data {
u8 entry_size;
struct bdb_lfp_backlight_data_entry data[16];
u8 level[16];
+   struct bdb_lfp_backlight_control_data blc_ctl[16];
  } __packed;
  
  struct aimdb_header {


--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH 1/7] drm: Fix DP_TEST_COUNT_MASK

[Sivakumar Thulasimani]

Reviewed-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com

On 7/24/2015 5:04 AM, Rodrigo Vivi wrote:

By Vesa's DP 1.2 Spec this counter has 4 bits [3:0].

This mask is wrong since when the counter was introduced by myself
on commit ad9dc91b6e21266bfc6f466db4b95e10211f31ee
Author: Rodrigo Vivi rodrigo.v...@gmail.com
Date:   Tue Sep 16 19:18:12 2014 -0400

 drm/i915: Fix Sink CRC

Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
  include/drm/drm_dp_helper.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 2e86f64..94898f6 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -420,7 +420,7 @@
  
  #define DP_TEST_SINK_MISC		0x246

  # define DP_TEST_CRC_SUPPORTED(1  5)
-# define DP_TEST_COUNT_MASK0x7
+# define DP_TEST_COUNT_MASK0xf
  
  #define DP_TEST_RESPONSE		0x260

  # define DP_TEST_ACK  (1  0)


--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: combine i9xx_get_hpd_pins and pch_get_hpd_pins

[Sivakumar Thulasimani]

,
+  dig_hotplug_reg, hpd_cpt,
+  pch_port_hotplug_long_detect);
intel_hpd_irq_handler(dev, pin_mask, long_mask);
}
  
@@ -1981,7 +1961,8 @@ static void bxt_hpd_handler(struct drm_device *dev, uint32_t iir_status)

/* Clear sticky bits in hpd status */
I915_WRITE(BXT_HOTPLUG_CTL, hp_control);
  
-	pch_get_hpd_pins(pin_mask, long_mask, hp_trigger, hp_control, hpd_bxt);

+   intel_get_hpd_pins(pin_mask, long_mask, hp_trigger, hp_control,
+  hpd_bxt, pch_port_hotplug_long_detect);
intel_hpd_irq_handler(dev, pin_mask, long_mask);
  }
  


Reviewed-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com

--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: don't use HPD_PORT_A as an alias for HPD_NONE

[Sivakumar Thulasimani]

On 7/22/2015 4:02 AM, Imre Deak wrote:

Curren tly HPD_PORT_A is used as an alias for HPD_NONE to mean that the
given port doesn't support long/short HPD pulse detection. SDVO and CRT
ports are like this and for these ports we only want to know whether an
hot plug event was detected on the corresponding pin. Since at least on
BXT we need long/short pulse detection on PORT A as well (added by the
next patch) remove this aliasing of HPD_PORT_A/HPD_NONE and let the
return value of intel_hpd_pin_to_port() show whether long/short pulse
detection is supported on the passed in
pin.

No functional change.

v2:
- rebase on top of -nightly (Daniel)
- make the check for intel_hpd_pin_to_port() return value more readable
   (Sivakumar)

Signed-off-by: Imre Deak imre.d...@intel.com
Reviewed-by: Sonika Jindal sonika.jin...@intel.com
Reviewed-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
  drivers/gpu/drm/i915/i915_drv.h  |  4 ++--
  drivers/gpu/drm/i915/i915_irq.c  |  4 +++-
  drivers/gpu/drm/i915/intel_hotplug.c | 20 +---
  3 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b876e78..b94ada9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -206,11 +206,11 @@ enum intel_display_power_domain {
  
  enum hpd_pin {

HPD_NONE = 0,
-   HPD_PORT_A = HPD_NONE, /* PORT_A is internal */
HPD_TV = HPD_NONE, /* TV is known to be unreliable */
HPD_CRT,
HPD_SDVO_B,
HPD_SDVO_C,
+   HPD_PORT_A,
HPD_PORT_B,
HPD_PORT_C,
HPD_PORT_D,
@@ -2648,7 +2648,7 @@ void intel_hpd_irq_handler(struct drm_device *dev, u32 
pin_mask, u32 long_mask);
  void intel_hpd_init(struct drm_i915_private *dev_priv);
  void intel_hpd_init_work(struct drm_i915_private *dev_priv);
  void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
-enum port intel_hpd_pin_to_port(enum hpd_pin pin);
+bool intel_hpd_pin_to_port(enum hpd_pin pin, enum port *port);
  
  /* i915_irq.c */

  void i915_queue_hangcheck(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 9410aab..f08ec9c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1273,7 +1273,9 @@ static void intel_get_hpd_pins(u32 *pin_mask, u32 
*long_mask,
  
  		*pin_mask |= BIT(i);
  
-		port = intel_hpd_pin_to_port(i);

+   if (!intel_hpd_pin_to_port(i, port))
+   continue;
+
if (long_pulse_detect(port, dig_hotplug_reg))
*long_mask |= BIT(i);
}
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c 
b/drivers/gpu/drm/i915/intel_hotplug.c
index 3c9171f..032a0bf 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -76,17 +76,23 @@
   * it will use i915_hotplug_work_func where this logic is handled.
   */
  
-enum port intel_hpd_pin_to_port(enum hpd_pin pin)

+bool intel_hpd_pin_to_port(enum hpd_pin pin, enum port *port)
  {
switch (pin) {
+   case HPD_PORT_A:
+   *port = PORT_A;
+   return true;
case HPD_PORT_B:
-   return PORT_B;
+   *port = PORT_B;
+   return true;
case HPD_PORT_C:
-   return PORT_C;
+   *port = PORT_C;
+   return true;
case HPD_PORT_D:
-   return PORT_D;
+   *port = PORT_D;
+   return true;
default:
-   return PORT_A; /* no hpd */
+   return false;   /* no hpd */
}
  }
  
@@ -369,8 +375,8 @@ void intel_hpd_irq_handler(struct drm_device *dev,

if (!(BIT(i)  pin_mask))
continue;
  
-		port = intel_hpd_pin_to_port(i);

-   is_dig_port = port  dev_priv-hotplug.irq_port[port];
+   is_dig_port = intel_hpd_pin_to_port(i, port) 
+ dev_priv-hotplug.irq_port[port];
  
  		if (is_dig_port) {

bool long_hpd = long_mask  BIT(i);


Reviewed-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com

--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: combine i9xx_get_hpd_pins and pch_get_hpd_pins

[Sivakumar Thulasimani]

On 7/21/2015 11:28 PM, Imre Deak wrote:

On Tue, 2015-07-21 at 13:50 +0530, Sivakumar Thulasimani wrote:

On 7/21/2015 3:13 AM, Imre Deak wrote:

These functions are quite similar, so combine them with the use of a new
argument for a function that detects long pulses. This will be also
needed by an upcoming patch adding support for BXT long pulse detection.

No functional change.

Signed-off-by: Imre Deak imre.d...@intel.com
---
   drivers/gpu/drm/i915/i915_irq.c | 54 
++---
   1 file changed, 18 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a6fbe64..306de78 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1256,9 +1256,10 @@ static bool i9xx_port_hotplug_long_detect(enum port 
port, u32 val)
   }
   
   /* Get a bit mask of pins that have triggered, and which ones may be long. */

-static void pch_get_hpd_pins(u32 *pin_mask, u32 *long_mask,
+static void intel_get_hpd_pins(u32 *pin_mask, u32 *long_mask,
 u32 hotplug_trigger, u32 dig_hotplug_reg,
-const u32 hpd[HPD_NUM_PINS])
+const u32 hpd[HPD_NUM_PINS],
+bool long_pulse_detect(enum port port, u32 val))
   {
enum port port;
int i;
@@ -1276,7 +1277,7 @@ static void pch_get_hpd_pins(u32 *pin_mask, u32 
*long_mask,
*pin_mask |= BIT(i);
   
   		port = intel_hpd_pin_to_port(i);

-   if (pch_port_hotplug_long_detect(port, dig_hotplug_reg))
+   if (long_pulse_detect(port, dig_hotplug_reg))
*long_mask |= BIT(i);
}
   
@@ -1285,34 +1286,6 @@ static void pch_get_hpd_pins(u32 *pin_mask, u32 *long_mask,
   
   }
   
-/* Get a bit mask of pins that have triggered, and which ones may be long. */

-static void i9xx_get_hpd_pins(u32 *pin_mask, u32 *long_mask,
- u32 hotplug_trigger, const u32 hpd[HPD_NUM_PINS])
-{
-   enum port port;
-   int i;
-
-   *pin_mask = 0;
-   *long_mask = 0;
-
-   if (!hotplug_trigger)
-   return;
-
-   for_each_hpd_pin(i) {
-   if ((hpd[i]  hotplug_trigger) == 0)
-   continue;
-
-   *pin_mask |= BIT(i);
-
-   port = intel_hpd_pin_to_port(i);
-   if (i9xx_port_hotplug_long_detect(port, hotplug_trigger))
-   *long_mask |= BIT(i);
-   }
-
-   DRM_DEBUG_DRIVER(hotplug event received, stat 0x%08x, pins 0x%08x\n,
-hotplug_trigger, *pin_mask);
-}
-
   static void gmbus_irq_handler(struct drm_device *dev)
   {
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -1550,7 +1523,9 @@ static void i9xx_hpd_irq_handler(struct drm_device *dev)
if (IS_G4X(dev) || IS_VALLEYVIEW(dev)) {
u32 hotplug_trigger = hotplug_status  HOTPLUG_INT_STATUS_G4X;
   
-		i9xx_get_hpd_pins(pin_mask, long_mask, hotplug_trigger, hpd_status_g4x);

+   intel_get_hpd_pins(pin_mask, long_mask, hotplug_trigger,
+  hotplug_trigger, hpd_status_g4x,
+  i9xx_port_hotplug_long_detect);
intel_hpd_irq_handler(dev, pin_mask, long_mask);
   
   		if (hotplug_status  DP_AUX_CHANNEL_MASK_INT_STATUS_G4X)

@@ -1558,7 +1533,9 @@ static void i9xx_hpd_irq_handler(struct drm_device *dev)
} else {
u32 hotplug_trigger = hotplug_status  HOTPLUG_INT_STATUS_I915;
   
-		i9xx_get_hpd_pins(pin_mask, long_mask, hotplug_trigger, hpd_status_i915);

+   intel_get_hpd_pins(pin_mask, long_mask, hotplug_trigger,
+  hotplug_trigger, hpd_status_g4x,
+  i9xx_port_hotplug_long_detect);
intel_hpd_irq_handler(dev, pin_mask, long_mask);
}
   }
@@ -1664,7 +1641,9 @@ static void ibx_irq_handler(struct drm_device *dev, u32 
pch_iir)
dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
   
-	pch_get_hpd_pins(pin_mask, long_mask, hotplug_trigger, dig_hotplug_reg, hpd_ibx);

+   intel_get_hpd_pins(pin_mask, long_mask, hotplug_trigger,
+  dig_hotplug_reg, hpd_ibx,
+  pch_port_hotplug_long_detect);
intel_hpd_irq_handler(dev, pin_mask, long_mask);
   
   	if (pch_iir  SDE_AUDIO_POWER_MASK) {

@@ -1763,7 +1742,9 @@ static void cpt_irq_handler(struct drm_device *dev, u32 
pch_iir)
dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
   
-	pch_get_hpd_pins(pin_mask, long_mask, hotplug_trigger, dig_hotplug_reg, hpd_cpt);

+   intel_get_hpd_pins(pin_mask, long_mask, hotplug_trigger,
+  dig_hotplug_reg, hpd_cpt,
+  pch_port_hotplug_long_detect

Re: [Intel-gfx] [PATCH 3/3] drm/i915/bxt: add support for HPD long/short pulse detection on HPD_PORT_A pin

[Sivakumar Thulasimani]

On 7/21/2015 3:13 AM, Imre Deak wrote:

This is a requirement for enabling display port HPD support on the port
A HPD pin. This support is to be added by follow-up patches.

Signed-off-by: Imre Deak imre.d...@intel.com
---
  drivers/gpu/drm/i915/i915_irq.c | 18 +-
  drivers/gpu/drm/i915/i915_reg.h |  5 +
  2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4ad7a31..02b9e73 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1227,6 +1227,22 @@ static irqreturn_t gen8_gt_irq_handler(struct 
drm_i915_private *dev_priv,
return ret;
  }
  
+static bool bxt_port_hotplug_long_detect(enum port port, u32 val)

+{
+   switch (port) {
+   case PORT_A:
+   return val  BXT_PORTA_HOTPLUG_LONG_DETECT;
+   case PORT_B:
+   return val  PORTB_HOTPLUG_LONG_DETECT;
+   case PORT_C:
+   return val  PORTC_HOTPLUG_LONG_DETECT;
+   case PORT_D:
+   return val  PORTD_HOTPLUG_LONG_DETECT;
+   default:
+   return false;
+   }
+}
+
  static bool pch_port_hotplug_long_detect(enum port port, u32 val)
  {
switch (port) {
@@ -1961,7 +1977,7 @@ static void bxt_hpd_handler(struct drm_device *dev, 
uint32_t iir_status)
I915_WRITE(BXT_HOTPLUG_CTL, hp_control);
  
  	intel_get_hpd_pins(pin_mask, long_mask, hp_trigger, hp_control,

-  hpd_bxt, pch_port_hotplug_long_detect);
+  hpd_bxt, bxt_port_hotplug_long_detect);
intel_hpd_irq_handler(dev, pin_mask, long_mask);
  }
  
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h

index fc70035..be166b3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5942,6 +5942,11 @@ enum skl_disp_power_wells {
  
  /* digital port hotplug */

  #define PCH_PORT_HOTPLUG0xc4030   /* SHOTPLUG_CTL */
+#define BXT_PORTA_HOTPLUG_ENABLE   (1  28)
+#define BXT_PORTA_HOTPLUG_STATUS_MASK  (0x3  24)
+#define  BXT_PORTA_HOTPLUG_NO_DETECT   (0  24)
+#define  BXT_PORTA_HOTPLUG_SHORT_DETECT(1  24)
+#define  BXT_PORTA_HOTPLUG_LONG_DETECT (2  24)
  #define PORTD_HOTPLUG_ENABLE(1  20)
  #define PORTD_PULSE_DURATION_2ms(0)
  #define PORTD_PULSE_DURATION_4_5ms  (1  18)


Reviewed-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com

--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH] drm/i915/bxt: WA for swapped HPD pins in A stepping

[Sivakumar Thulasimani]

On 7/22/2015 4:39 PM, Jindal, Sonika wrote:



On 7/22/2015 4:03 PM, Sivakumar Thulasimani wrote:



On 7/22/2015 3:37 PM, Sonika Jindal wrote:

As per bspec, on BXT A0/A1, sw needs to activate DDIA HPD logic
and interrupts to check the external panel connection and DDIC HPD
logic for edp panel.

v2: For DP, irq_port is used to determine the encoder instead of
hpd_pin and removing the edp HPD logic because port A HPD is not
present(Imre)
v3: Rebased on top of Imre's patchset for enabling HPD on PORT A.
Added hpd_pin swapping for intel_dp_init_connector, setting encoder
for PORT_A as per the WA in irq_port (Imre)

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  drivers/gpu/drm/i915/intel_ddi.c  |   12 +++-
  drivers/gpu/drm/i915/intel_dp.c   |4 
  drivers/gpu/drm/i915/intel_hdmi.c |9 -
  3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index e2c6f73..d5745e2 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3225,7 +3225,17 @@ void intel_ddi_init(struct drm_device *dev,
enum port port)
  goto err;
  intel_dig_port-hpd_pulse = intel_dp_hpd_pulse;
-dev_priv-hotplug.irq_port[port] = intel_dig_port;
+/*
+ * On BXT A0/A1, sw needs to activate DDIA HPD logic and
+ * interrupts to check the external panel connection.
+ */
+if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  
BXT_REVID_B0)) {

+if (port == PORT_B)
+dev_priv-hotplug.irq_port[PORT_A] = intel_dig_port;
+else if (port == PORT_A)
+dev_priv-hotplug.irq_port[PORT_C] = intel_dig_port;
+} else
+dev_priv-hotplug.irq_port[port] = intel_dig_port;
  }
  /* In theory we don't need the encoder-type check, but leave it
just in
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index fcc64e5..71679ef 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5785,9 +5785,13 @@ intel_dp_init_connector(struct
intel_digital_port *intel_dig_port,
  switch (port) {
  case PORT_A:
  intel_encoder-hpd_pin = HPD_PORT_A;
+if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+intel_encoder-hpd_pin = HPD_PORT_C;
  break;
  case PORT_B:
  intel_encoder-hpd_pin = HPD_PORT_B;
+if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+intel_encoder-hpd_pin = HPD_PORT_A;
  break;
  case PORT_C:
  intel_encoder-hpd_pin = HPD_PORT_C;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 70bad5b..94fa716 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1973,7 +1973,14 @@ void intel_hdmi_init_connector(struct
intel_digital_port *intel_dig_port,
  intel_hdmi-ddc_bus = GMBUS_PIN_1_BXT;
  else
  intel_hdmi-ddc_bus = GMBUS_PIN_DPB;
-intel_encoder-hpd_pin = HPD_PORT_B;
+/*
+ * On BXT A0/A1, sw needs to activate DDIA HPD logic and
+ * interrupts to check the external panel connection.
+ */
+if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+intel_encoder-hpd_pin = HPD_PORT_A;
+else
+intel_encoder-hpd_pin = HPD_PORT_B;
  break;
  case PORT_C:
  if (IS_BROXTON(dev_priv))

bxt_hpd_irq_setup is not touched here without this being updated i dont
think HPD can be enabled.
Now, we swap the hpd_pin, which is being used to enable HPD in 
bxt_hpd_irq_setup.


yes, but the hpd_pin which is updated to HPD_PORT_A when enters 
bxt_hpd_setup_irq we are enabling
only HPD B  C. so it will not enable HPDA. unless i am missing some 
patch i am not seeing code to

enable HPD A with latest nightly code.


Regards,
Sonika




--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH] drm/i915/bxt: WA for swapped HPD pins in A stepping

[Sivakumar Thulasimani]

On 7/22/2015 3:37 PM, Sonika Jindal wrote:

As per bspec, on BXT A0/A1, sw needs to activate DDIA HPD logic
and interrupts to check the external panel connection and DDIC HPD
logic for edp panel.

v2: For DP, irq_port is used to determine the encoder instead of
hpd_pin and removing the edp HPD logic because port A HPD is not
present(Imre)
v3: Rebased on top of Imre's patchset for enabling HPD on PORT A.
Added hpd_pin swapping for intel_dp_init_connector, setting encoder
for PORT_A as per the WA in irq_port (Imre)

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  drivers/gpu/drm/i915/intel_ddi.c  |   12 +++-
  drivers/gpu/drm/i915/intel_dp.c   |4 
  drivers/gpu/drm/i915/intel_hdmi.c |9 -
  3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index e2c6f73..d5745e2 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3225,7 +3225,17 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
goto err;
  
  		intel_dig_port-hpd_pulse = intel_dp_hpd_pulse;

-   dev_priv-hotplug.irq_port[port] = intel_dig_port;
+   /*
+* On BXT A0/A1, sw needs to activate DDIA HPD logic and
+* interrupts to check the external panel connection.
+*/
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0)) {
+   if (port == PORT_B)
+   dev_priv-hotplug.irq_port[PORT_A] = 
intel_dig_port;
+   else if (port == PORT_A)
+   dev_priv-hotplug.irq_port[PORT_C] = 
intel_dig_port;
+   } else
+   dev_priv-hotplug.irq_port[port] = intel_dig_port;
}
  
  	/* In theory we don't need the encoder-type check, but leave it just in

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fcc64e5..71679ef 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5785,9 +5785,13 @@ intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
switch (port) {
case PORT_A:
intel_encoder-hpd_pin = HPD_PORT_A;
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+   intel_encoder-hpd_pin = HPD_PORT_C;
break;
case PORT_B:
intel_encoder-hpd_pin = HPD_PORT_B;
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+   intel_encoder-hpd_pin = HPD_PORT_A;
break;
case PORT_C:
intel_encoder-hpd_pin = HPD_PORT_C;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 70bad5b..94fa716 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1973,7 +1973,14 @@ void intel_hdmi_init_connector(struct intel_digital_port 
*intel_dig_port,
intel_hdmi-ddc_bus = GMBUS_PIN_1_BXT;
else
intel_hdmi-ddc_bus = GMBUS_PIN_DPB;
-   intel_encoder-hpd_pin = HPD_PORT_B;
+   /*
+* On BXT A0/A1, sw needs to activate DDIA HPD logic and
+* interrupts to check the external panel connection.
+*/
+   if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  BXT_REVID_B0))
+   intel_encoder-hpd_pin = HPD_PORT_A;
+   else
+   intel_encoder-hpd_pin = HPD_PORT_B;
break;
case PORT_C:
if (IS_BROXTON(dev_priv))
bxt_hpd_irq_setup is not touched here without this being updated i dont 
think HPD can be enabled.


--
regards,
Sivakumar

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

[Intel-gfx] [PATCH] drm/i915: fix checksum write for automated test reply

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

DP spec requires the checksum of the last block read to be written
when replying to TEST_EDID_READ. This patch fixes the current code
to do the same.

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |   11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f1b9f93..9617d04 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4090,9 +4090,18 @@ static uint8_t intel_dp_autotest_edid(struct intel_dp 
*intel_dp)
  intel_dp-aux.i2c_defer_count);
intel_dp-compliance_test_data = INTEL_DP_RESOLUTION_FAILSAFE;
} else {
+   struct edid *block = intel_connector-detect_edid;
+   uint8_t temp = intel_connector-detect_edid-extensions;
+
+   /* We have to write the checksum
+* of the last block read
+*/
+   while (temp--)
+   block++;
+
if (!drm_dp_dpcd_write(intel_dp-aux,
DP_TEST_EDID_CHECKSUM,
-   intel_connector-detect_edid-checksum,
+   block-checksum,
1))
DRM_DEBUG_KMS(Failed to write EDID checksum\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] drm/i915/bxt: WA for swapped HPD pins in A stepping

[Sivakumar Thulasimani]

On 7/22/2015 5:32 PM, Jindal, Sonika wrote:



On 7/22/2015 5:01 PM, Sivakumar Thulasimani wrote:



On 7/22/2015 4:39 PM, Jindal, Sonika wrote:



On 7/22/2015 4:03 PM, Sivakumar Thulasimani wrote:



On 7/22/2015 3:37 PM, Sonika Jindal wrote:

As per bspec, on BXT A0/A1, sw needs to activate DDIA HPD logic
and interrupts to check the external panel connection and DDIC HPD
logic for edp panel.

v2: For DP, irq_port is used to determine the encoder instead of
hpd_pin and removing the edp HPD logic because port A HPD is not
present(Imre)
v3: Rebased on top of Imre's patchset for enabling HPD on PORT A.
Added hpd_pin swapping for intel_dp_init_connector, setting encoder
for PORT_A as per the WA in irq_port (Imre)

Signed-off-by: Sonika Jindal sonika.jin...@intel.com
---
  drivers/gpu/drm/i915/intel_ddi.c  |   12 +++-
  drivers/gpu/drm/i915/intel_dp.c   |4 
  drivers/gpu/drm/i915/intel_hdmi.c |9 -
  3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index e2c6f73..d5745e2 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -3225,7 +3225,17 @@ void intel_ddi_init(struct drm_device *dev,
enum port port)
  goto err;
  intel_dig_port-hpd_pulse = intel_dp_hpd_pulse;
-dev_priv-hotplug.irq_port[port] = intel_dig_port;
+/*
+ * On BXT A0/A1, sw needs to activate DDIA HPD logic and
+ * interrupts to check the external panel connection.
+ */
+if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev) 
BXT_REVID_B0)) {
+if (port == PORT_B)
+dev_priv-hotplug.irq_port[PORT_A] = intel_dig_port;
+else if (port == PORT_A)
+dev_priv-hotplug.irq_port[PORT_C] = intel_dig_port;
Please don't enable interrupt for PORT_A :) otherwise we might have to 
handle HPD

for each pps on/off like in CHV.

+} else
+dev_priv-hotplug.irq_port[port] = intel_dig_port;
  }
  /* In theory we don't need the encoder-type check, but 
leave it

just in
diff --git a/drivers/gpu/drm/i915/intel_dp.c
b/drivers/gpu/drm/i915/intel_dp.c
index fcc64e5..71679ef 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5785,9 +5785,13 @@ intel_dp_init_connector(struct
intel_digital_port *intel_dig_port,
  switch (port) {
  case PORT_A:
  intel_encoder-hpd_pin = HPD_PORT_A;
+if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  
BXT_REVID_B0))

+intel_encoder-hpd_pin = HPD_PORT_C;
  break;
  case PORT_B:
  intel_encoder-hpd_pin = HPD_PORT_B;
+if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  
BXT_REVID_B0))

+intel_encoder-hpd_pin = HPD_PORT_A;
  break;
  case PORT_C:
  intel_encoder-hpd_pin = HPD_PORT_C;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 70bad5b..94fa716 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1973,7 +1973,14 @@ void intel_hdmi_init_connector(struct
intel_digital_port *intel_dig_port,
  intel_hdmi-ddc_bus = GMBUS_PIN_1_BXT;
  else
  intel_hdmi-ddc_bus = GMBUS_PIN_DPB;
-intel_encoder-hpd_pin = HPD_PORT_B;
+/*
+ * On BXT A0/A1, sw needs to activate DDIA HPD logic and
+ * interrupts to check the external panel connection.
+ */
+if (IS_BROXTON(dev_priv)  (INTEL_REVID(dev)  
BXT_REVID_B0))

+intel_encoder-hpd_pin = HPD_PORT_A;
+else
+intel_encoder-hpd_pin = HPD_PORT_B;
  break;
  case PORT_C:
  if (IS_BROXTON(dev_priv))
bxt_hpd_irq_setup is not touched here without this being updated i 
dont

think HPD can be enabled.

Now, we swap the hpd_pin, which is being used to enable HPD in
bxt_hpd_irq_setup.


yes, but the hpd_pin which is updated to HPD_PORT_A when enters
bxt_hpd_setup_irq we are enabling
only HPD B  C. so it will not enable HPDA. unless i am missing some
patch i am not seeing code to
enable HPD A with latest nightly code.


Yes, you are missing the patch 1 of this series :)
[PATCH 1/2] drm/i915/bxt: Add HPD support for DDIA


Regards,
Sonika





ok missed that in the thread list :).

--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH] drm/i915: fix checksum write for automated test reply

[Sivakumar Thulasimani]

On 7/22/2015 5:30 PM, Daniel Vetter wrote:

On Wed, Jul 22, 2015 at 03:36:48PM +0530, Sivakumar Thulasimani wrote:

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

DP spec requires the checksum of the last block read to be written
when replying to TEST_EDID_READ. This patch fixes the current code
to do the same.

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
  drivers/gpu/drm/i915/intel_dp.c |   11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f1b9f93..9617d04 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4090,9 +4090,18 @@ static uint8_t intel_dp_autotest_edid(struct intel_dp 
*intel_dp)
  intel_dp-aux.i2c_defer_count);
intel_dp-compliance_test_data = INTEL_DP_RESOLUTION_FAILSAFE;
} else {
+   struct edid *block = intel_connector-detect_edid;
+   uint8_t temp = intel_connector-detect_edid-extensions;
+
+   /* We have to write the checksum
+* of the last block read
+*/
+   while (temp--)
+   block++;

block += block-extensions;

instead of implementing addition by adding lots of 1? Also if you want to
simplify computation by extracting local variables, give them a better
name than temp. That's somewhat ok for a reused u32 tmp for register
read-modify-writes over lots of registers, but not really for anything
else.
-Daniel


Done. uploaded v2 with this change.

+
if (!drm_dp_dpcd_write(intel_dp-aux,
DP_TEST_EDID_CHECKSUM,
-   intel_connector-detect_edid-checksum,
+   block-checksum,
1))
DRM_DEBUG_KMS(Failed to write EDID checksum\n);
  
--

1.7.9.5

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






--
regards,
Sivakumar


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

[Intel-gfx] [PATCH] drm/i915: fix checksum write for automated test reply

[Sivakumar Thulasimani]

From: Thulasimani,Sivakumar sivakumar.thulasim...@intel.com

DP spec requires the checksum of the last block read to be written
when replying to TEST_EDID_READ. This patch fixes the current code
to do the same.

Signed-off-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com
---
 drivers/gpu/drm/i915/intel_dp.c |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f1b9f93..fa6e202 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4090,9 +4090,16 @@ static uint8_t intel_dp_autotest_edid(struct intel_dp 
*intel_dp)
  intel_dp-aux.i2c_defer_count);
intel_dp-compliance_test_data = INTEL_DP_RESOLUTION_FAILSAFE;
} else {
+   struct edid *block = intel_connector-detect_edid;
+
+   /* We have to write the checksum
+* of the last block read
+*/
+   block += intel_connector-detect_edid-extensions;
+
if (!drm_dp_dpcd_write(intel_dp-aux,
DP_TEST_EDID_CHECKSUM,
-   intel_connector-detect_edid-checksum,
+   block-checksum,
1))
DRM_DEBUG_KMS(Failed to write EDID checksum\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 2/3] drm/i915: don't use HPD_PORT_A as an alias for HPD_NONE

[Sivakumar Thulasimani]

On 7/21/2015 3:13 AM, Imre Deak wrote:

Currently HPD_PORT_A is used as an alias for HPD_NONE to mean that the
given port doesn't support long/short HPD pulse detection. SDVO and CRT
ports are like this and for these ports we only want to know whether an
hot plug event was detected on the corresponding pin. Since at least on
BXT we need long/short pulse detection on PORT A as well (added by the
next patch) remove this aliasing of HPD_PORT_A/HPD_NONE and let the
return value of intel_hpd_pin_to_port() show whether long/short pulse
detection is supported on the passed in pin.

No functional change.

Signed-off-by: Imre Deak imre.d...@intel.com
---
  drivers/gpu/drm/i915/i915_drv.h  |  4 ++--
  drivers/gpu/drm/i915/i915_irq.c  |  4 ++--
  drivers/gpu/drm/i915/intel_hotplug.c | 20 +---
  3 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 78d6c7a..ebfd5a5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -206,11 +206,11 @@ enum intel_display_power_domain {
  
  enum hpd_pin {

HPD_NONE = 0,
-   HPD_PORT_A = HPD_NONE, /* PORT_A is internal */
HPD_TV = HPD_NONE, /* TV is known to be unreliable */
HPD_CRT,
HPD_SDVO_B,
HPD_SDVO_C,
+   HPD_PORT_A,
HPD_PORT_B,
HPD_PORT_C,
HPD_PORT_D,
@@ -2627,7 +2627,7 @@ void intel_hpd_irq_handler(struct drm_device *dev, u32 
pin_mask, u32 long_mask);
  void intel_hpd_init(struct drm_i915_private *dev_priv);
  void intel_hpd_init_work(struct drm_i915_private *dev_priv);
  void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
-enum port intel_hpd_pin_to_port(enum hpd_pin pin);
+bool intel_hpd_pin_to_port(enum hpd_pin pin, enum port *port);
  
  /* i915_irq.c */

  void i915_queue_hangcheck(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 306de78..4ad7a31 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1276,8 +1276,8 @@ static void intel_get_hpd_pins(u32 *pin_mask, u32 
*long_mask,
  
  		*pin_mask |= BIT(i);
  
-		port = intel_hpd_pin_to_port(i);

-   if (long_pulse_detect(port, dig_hotplug_reg))
+   if (intel_hpd_pin_to_port(i, port) 
+   long_pulse_detect(port, dig_hotplug_reg))
*long_mask |= BIT(i);
}

feel that this could be more readable when split it to two conditions ?
if (intel_hpd_pin_to_port(i, port) == false)
continue;
if (long_pulse_detect(port, dig_hotplug_reg)
*long_mask |= BIT(i);

other than this, this change looks good.

Reviewed-by: Sivakumar Thulasimani sivakumar.thulasim...@intel.com


  
diff --git a/drivers/gpu/drm/i915/intel_hotplug.c b/drivers/gpu/drm/i915/intel_hotplug.c

index 3c53aac..8cda7b9 100644
--- a/drivers/gpu/drm/i915/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/intel_hotplug.c
@@ -29,17 +29,23 @@
  #include i915_drv.h
  #include intel_drv.h
  
-enum port intel_hpd_pin_to_port(enum hpd_pin pin)

+bool intel_hpd_pin_to_port(enum hpd_pin pin, enum port *port)
  {
switch (pin) {
+   case HPD_PORT_A:
+   *port = PORT_A;
+   return true;
case HPD_PORT_B:
-   return PORT_B;
+   *port = PORT_B;
+   return true;
case HPD_PORT_C:
-   return PORT_C;
+   *port = PORT_C;
+   return true;
case HPD_PORT_D:
-   return PORT_D;
+   *port = PORT_D;
+   return true;
default:
-   return PORT_A; /* no hpd */
+   return false;   /* no hpd */
}
  }
  
@@ -322,8 +328,8 @@ void intel_hpd_irq_handler(struct drm_device *dev,

if (!(BIT(i)  pin_mask))
continue;
  
-		port = intel_hpd_pin_to_port(i);

-   is_dig_port = port  dev_priv-hotplug.irq_port[port];
+   is_dig_port = intel_hpd_pin_to_port(i, port) 
+ dev_priv-hotplug.irq_port[port];
  
  		if (is_dig_port) {

bool long_hpd = long_mask  BIT(i);


--
regards,
Sivakumar

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: combine i9xx_get_hpd_pins and pch_get_hpd_pins

[Sivakumar Thulasimani]

On 7/21/2015 3:13 AM, Imre Deak wrote:

These functions are quite similar, so combine them with the use of a new
argument for a function that detects long pulses. This will be also
needed by an upcoming patch adding support for BXT long pulse detection.

No functional change.

Signed-off-by: Imre Deak imre.d...@intel.com
---
  drivers/gpu/drm/i915/i915_irq.c | 54 ++---
  1 file changed, 18 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a6fbe64..306de78 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1256,9 +1256,10 @@ static bool i9xx_port_hotplug_long_detect(enum port 
port, u32 val)
  }
  
  /* Get a bit mask of pins that have triggered, and which ones may be long. */

-static void pch_get_hpd_pins(u32 *pin_mask, u32 *long_mask,
+static void intel_get_hpd_pins(u32 *pin_mask, u32 *long_mask,
 u32 hotplug_trigger, u32 dig_hotplug_reg,
-const u32 hpd[HPD_NUM_PINS])
+const u32 hpd[HPD_NUM_PINS],
+bool long_pulse_detect(enum port port, u32 val))
  {
enum port port;
int i;
@@ -1276,7 +1277,7 @@ static void pch_get_hpd_pins(u32 *pin_mask, u32 
*long_mask,
*pin_mask |= BIT(i);
  
  		port = intel_hpd_pin_to_port(i);

-   if (pch_port_hotplug_long_detect(port, dig_hotplug_reg))
+   if (long_pulse_detect(port, dig_hotplug_reg))
*long_mask |= BIT(i);
}
  
@@ -1285,34 +1286,6 @@ static void pch_get_hpd_pins(u32 *pin_mask, u32 *long_mask,
  
  }
  
-/* Get a bit mask of pins that have triggered, and which ones may be long. */

-static void i9xx_get_hpd_pins(u32 *pin_mask, u32 *long_mask,
- u32 hotplug_trigger, const u32 hpd[HPD_NUM_PINS])
-{
-   enum port port;
-   int i;
-
-   *pin_mask = 0;
-   *long_mask = 0;
-
-   if (!hotplug_trigger)
-   return;
-
-   for_each_hpd_pin(i) {
-   if ((hpd[i]  hotplug_trigger) == 0)
-   continue;
-
-   *pin_mask |= BIT(i);
-
-   port = intel_hpd_pin_to_port(i);
-   if (i9xx_port_hotplug_long_detect(port, hotplug_trigger))
-   *long_mask |= BIT(i);
-   }
-
-   DRM_DEBUG_DRIVER(hotplug event received, stat 0x%08x, pins 0x%08x\n,
-hotplug_trigger, *pin_mask);
-}
-
  static void gmbus_irq_handler(struct drm_device *dev)
  {
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -1550,7 +1523,9 @@ static void i9xx_hpd_irq_handler(struct drm_device *dev)
if (IS_G4X(dev) || IS_VALLEYVIEW(dev)) {
u32 hotplug_trigger = hotplug_status  HOTPLUG_INT_STATUS_G4X;
  
-		i9xx_get_hpd_pins(pin_mask, long_mask, hotplug_trigger, hpd_status_g4x);

+   intel_get_hpd_pins(pin_mask, long_mask, hotplug_trigger,
+  hotplug_trigger, hpd_status_g4x,
+  i9xx_port_hotplug_long_detect);
intel_hpd_irq_handler(dev, pin_mask, long_mask);
  
  		if (hotplug_status  DP_AUX_CHANNEL_MASK_INT_STATUS_G4X)

@@ -1558,7 +1533,9 @@ static void i9xx_hpd_irq_handler(struct drm_device *dev)
} else {
u32 hotplug_trigger = hotplug_status  HOTPLUG_INT_STATUS_I915;
  
-		i9xx_get_hpd_pins(pin_mask, long_mask, hotplug_trigger, hpd_status_i915);

+   intel_get_hpd_pins(pin_mask, long_mask, hotplug_trigger,
+  hotplug_trigger, hpd_status_g4x,
+  i9xx_port_hotplug_long_detect);
intel_hpd_irq_handler(dev, pin_mask, long_mask);
}
  }
@@ -1664,7 +1641,9 @@ static void ibx_irq_handler(struct drm_device *dev, u32 
pch_iir)
dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
  
-	pch_get_hpd_pins(pin_mask, long_mask, hotplug_trigger, dig_hotplug_reg, hpd_ibx);

+   intel_get_hpd_pins(pin_mask, long_mask, hotplug_trigger,
+  dig_hotplug_reg, hpd_ibx,
+  pch_port_hotplug_long_detect);
intel_hpd_irq_handler(dev, pin_mask, long_mask);
  
  	if (pch_iir  SDE_AUDIO_POWER_MASK) {

@@ -1763,7 +1742,9 @@ static void cpt_irq_handler(struct drm_device *dev, u32 
pch_iir)
dig_hotplug_reg = I915_READ(PCH_PORT_HOTPLUG);
I915_WRITE(PCH_PORT_HOTPLUG, dig_hotplug_reg);
  
-	pch_get_hpd_pins(pin_mask, long_mask, hotplug_trigger, dig_hotplug_reg, hpd_cpt);

+   intel_get_hpd_pins(pin_mask, long_mask, hotplug_trigger,
+  dig_hotplug_reg, hpd_cpt,
+  pch_port_hotplug_long_detect);
intel_hpd_irq_handler(dev, pin_mask, long_mask);
  
  	if (pch_iir  SDE_AUDIO_POWER_MASK_CPT) {

@@ -1979,7 +1960,8 @@ static 

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Clear out DPLL state from pipe config in DSI get config

[Sivakumar Thulasimani]

On 7/13/2015 2:21 PM, Daniel Vetter wrote:

On Fri, Jul 10, 2015 at 05:37:07PM +0530, Sivakumar Thulasimani wrote:


On 7/1/2015 6:12 PM, Daniel Vetter wrote:

On Tue, Jun 30, 2015 at 02:50:33PM +0300, Ville Syrjälä wrote:

On Tue, Jun 30, 2015 at 12:13:37PM +0200, Daniel Vetter wrote:

On Mon, Jun 29, 2015 at 08:08:27PM +0300, Ville Syrjälä wrote:

On Mon, Jun 29, 2015 at 07:56:05PM +0300, Ville Syrjälä wrote:

On Mon, Jun 29, 2015 at 06:42:11PM +0200, Daniel Vetter wrote:

On Mon, Jun 29, 2015 at 03:25:52PM +0300, ville.syrj...@linux.intel.com wrote:

From: Ville Syrjälä ville.syrj...@linux.intel.com

VLV/CHV don't use the DPLL with DSI, so just clear out the DPLL state

from the pipe_config in intel_dsi_get_config(). This avoids spurious

state checker warnings. We already did it this way for DPLL_MD, but do
it for DPLL too.

Toss in a WARN to intel_dsi_pre_enable() to make sure the ref clocks
are enabled however. Supposedly they have some meaning to DSI too.
We now keep the ref clocks always enabled while the disp2d well is
enabled.

Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
  drivers/gpu/drm/i915/intel_dsi.c | 15 +--
  1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 36e2148..92bb252 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -421,18 +421,12 @@ static void intel_dsi_pre_enable(struct intel_encoder 
*encoder)
/* Disable DPOunit clock gating, can stall pipe
 * and we need DPLL REFA always enabled */
-   tmp = I915_READ(DPLL(pipe));
-   tmp |= DPLL_REF_CLK_ENABLE_VLV;
-   I915_WRITE(DPLL(pipe), tmp);
-
-   /* update the hw state for DPLL */
-   intel_crtc-config-dpll_hw_state.dpll = DPLL_INTEGRATED_REF_CLK_VLV |
-   DPLL_REF_CLK_ENABLE_VLV | DPLL_VGA_MODE_DIS;
-
tmp = I915_READ(DSPCLK_GATE_D);
tmp |= DPOUNIT_CLOCK_GATE_DISABLE;
I915_WRITE(DSPCLK_GATE_D, tmp);
+   WARN_ON((I915_READ(DPLL(pipe))  DPLL_REF_CLK_ENABLE_VLV) == 0);
+
/* put device in ready state */
intel_dsi_device_ready(encoder);
@@ -635,9 +629,10 @@ static void intel_dsi_get_config(struct intel_encoder 
*encoder,
DRM_DEBUG_KMS(\n);
/*
-* DPLL_MD is not used in case of DSI, reading will get some default 
value
-* set dpll_md = 0
+* DPLL is not used in case of DSI, reading will getsome default value.
+* Clear the state to keep the state checker happy.
 */
+   pipe_config-dpll_hw_state.dpll = 0;
pipe_config-dpll_hw_state.dpll_md = 0;

State configs are supposed to be kzallocated. Needing this indicates a
pretty serious bug - I'd vote to instead also ditch the dpll_md line and
fix the offender.

There is no offender really. We read out the DPLL state before we know
which ports are active and hence can't tell at that point if the
information is really relevant.

So the bios leaves the DPLL enabled even when using a DSI port? Or do we
miss to check some routing bits in get_clock?

Not necessarily enabled, but there are other bits in there that could be
left in any state basically. The DSI port simply doesn't care.

If the enable bit is what's gating things here then we should just forgo
reading out any dpll register state if that's not set. Looking at the
vlv/chv state readout code that seems to be the trouble - there's nothing
guarding the register reads into the pipe_config at all. Didn't matter
pre-vlv without dsi since enable pipe should imply enabled dpll, but
obviously won't work correctly with dsi. Can you please spin such a patch
and remove the hacks here from dsi_get_config?
-Daniel

Not sure i understand the point of contention here, just noticed this after
i gave my RB :)
so my justification on why this is proper is that DSI is not supposed to
touch DPLL register
any place we access dpll_hw_state.dpll is under !is_dsi check so that
ensures that we dont
program DPLL register for dsi panel. it was wrong to have originally modfied
DPLL register
inside intel_dsi_pre_enable so removal is fine. setting it to zero in
intel_dsi_get_config
is of no impact since any place we write back the contents of dpll_hw_state
is past the
!is_dsi check is never consumed by anyone as long as the CRTC uses DSI.

Ok, let's try a patch. Does the below work y/n? I've merged the patches up
to this one to dinq meanwhile, but I'd really like to close this first. If
it works I can rebase this patch here myself. Diff below is based on
-nightly with the above patch, so if you want to test on top of it you
also have to remove the dpll = 0; line too ofc.

Thanks, Daniel

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a7482ab140e1..c770655f5612 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8079,6 +8079,10 @@ static bool i9xx_get_pipe_config(struct