[RFC] Three pipe support for IVB

[RFC] Three pipe support for IVB

[Jesse Barnes]

This set of patches lays the groundwork for supporting 3 pipes on IVB
hardware.  We've only tested it so far with 2 HDMI plus 1 VGA (a
configuration that doesn't work), and are awaiting 3 DP port hardware
(the officially supported config) to complete our testing.

So this patchset is necessary but may not be sufficient (once we have 3
DP hardware we can debug and see).  Review and comments appreciated.

Thanks,
Jesse

[PATCH 1/4] drm/i915: PLL macro cleanup and pipe assertion check

[Jesse Barnes]

Add a macro for accessing the two pipe PLLs and add a check to make sure
we don't access a non-existent one in the enable/disable functions.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
---
 drivers/gpu/drm/i915/i915_reg.h      |    6 +++---
 drivers/gpu/drm/i915/intel_display.c |    6 ++++++
 2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 542453f..7659075 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2945,15 +2945,15 @@
 
 #define _PCH_DPLL_A              0xc6014
 #define _PCH_DPLL_B              0xc6018
-#define PCH_DPLL(pipe) _PIPE(pipe, _PCH_DPLL_A, _PCH_DPLL_B)
+#define PCH_DPLL(pipe) (pipe == 0 ?  _PCH_DPLL_A : _PCH_DPLL_B)
 
 #define _PCH_FPA0                0xc6040
 #define  FP_CB_TUNE		(0x3<<22)
 #define _PCH_FPA1                0xc6044
 #define _PCH_FPB0                0xc6048
 #define _PCH_FPB1                0xc604c
-#define PCH_FP0(pipe) _PIPE(pipe, _PCH_FPA0, _PCH_FPB0)
-#define PCH_FP1(pipe) _PIPE(pipe, _PCH_FPA1, _PCH_FPB1)
+#define PCH_FP0(pipe) (pipe == 0 ? _PCH_FPA0 : _PCH_FPB0)
+#define PCH_FP1(pipe) (pipe == 0 ? _PCH_FPA1 : _PCH_FPB1)
 
 #define PCH_DPLL_TEST           0xc606c
 
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 56a8554..df9d394 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1171,6 +1171,9 @@ static void intel_enable_pch_pll(struct drm_i915_private *dev_priv,
 	int reg;
 	u32 val;
 
+	if (pipe > 1)
+		return;
+
 	/* PCH only available on ILK+ */
 	BUG_ON(dev_priv->info->gen < 5);
 
@@ -1191,6 +1194,9 @@ static void intel_disable_pch_pll(struct drm_i915_private *dev_priv,
 	int reg;
 	u32 val;
 
+	if (pipe > 1)
+		return;
+
 	/* PCH only available on ILK+ */
 	BUG_ON(dev_priv->info->gen < 5);
 
-- 
1.7.4.1

[PATCH 2/4] drm/i915: support 3 pipes on IVB+

[Jesse Barnes]

Well almost anyway.  IVB has 3 planes, pipes, transcoders, and FDI
interfaces, but only 2 pipe PLLs.  So two of the pipes must use the same
pipe timings (e.g. 2 DP plus one other, or two HDMI with the same mode
and one other, etc.).

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
---
 drivers/gpu/drm/i915/i915_dma.c      |    4 +++-
 drivers/gpu/drm/i915/i915_drv.h      |    4 ++--
 drivers/gpu/drm/i915/intel_display.c |    7 +++++++
 drivers/gpu/drm/i915/intel_dp.c      |    2 +-
 drivers/gpu/drm/i915/intel_hdmi.c    |    2 +-
 drivers/gpu/drm/i915/intel_lvds.c    |    8 +++++---
 drivers/gpu/drm/i915/intel_sdvo.c    |    2 +-
 7 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 8a3942c..7a2ee0d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -2035,7 +2035,9 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags)
 	spin_lock_init(&dev_priv->error_lock);
 	spin_lock_init(&dev_priv->rps_lock);
 
-	if (IS_MOBILE(dev) || !IS_GEN2(dev))
+	if (IS_IVYBRIDGE(dev))
+		dev_priv->num_pipe = 3;
+	else if (IS_MOBILE(dev) || !IS_GEN2(dev))
 		dev_priv->num_pipe = 2;
 	else
 		dev_priv->num_pipe = 1;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7916bd9..e865a3c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -674,8 +674,8 @@ typedef struct drm_i915_private {
 	u32 pch_pf_pos, pch_pf_size;
 	int panel_t3, panel_t12;
 
-	struct drm_crtc *plane_to_crtc_mapping[2];
-	struct drm_crtc *pipe_to_crtc_mapping[2];
+	struct drm_crtc *plane_to_crtc_mapping[3];
+	struct drm_crtc *pipe_to_crtc_mapping[3];
 	wait_queue_head_t pending_flip_queue;
 	bool flip_pending_is_done;
 
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index df9d394..0dffb52 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2083,6 +2083,7 @@ static int ironlake_update_plane(struct drm_crtc *crtc,
 	switch (plane) {
 	case 0:
 	case 1:
+	case 2:
 		break;
 	default:
 		DRM_ERROR("Can't update plane %d in SAREA\n", plane);
@@ -2182,6 +2183,10 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
 	case 0:
 	case 1:
 		break;
+	case 2:
+		if (IS_IVYBRIDGE(dev))
+			break;
+		/* fall through otherwise */
 	default:
 		DRM_ERROR("no plane for crtc\n");
 		return -EINVAL;
@@ -2878,6 +2883,8 @@ static void ironlake_pch_enable(struct drm_crtc *crtc)
 			temp |= (TRANSA_DPLL_ENABLE | TRANSA_DPLLA_SEL);
 		else if (pipe == 1 && (temp & TRANSB_DPLL_ENABLE) == 0)
 			temp |= (TRANSB_DPLL_ENABLE | TRANSB_DPLLB_SEL);
+		else if (pipe == 2 && (temp & TRANSC_DPLL_ENABLE) == 0)
+			temp |= (TRANSC_DPLL_ENABLE | TRANSC_DPLLB_SEL);
 		I915_WRITE(PCH_DPLL_SEL, temp);
 	}
 
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 44fef5e..edc369e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1996,7 +1996,7 @@ intel_dp_init(struct drm_device *dev, int output_reg)
 	if (is_edp(intel_dp))
 		intel_encoder->clone_mask = (1 << INTEL_EDP_CLONE_BIT);
 
-	intel_encoder->crtc_mask = (1 << 0) | (1 << 1);
+	intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
 	connector->interlace_allowed = true;
 	connector->doublescan_allowed = 0;
 
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
index 226ba83..11883c9 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -511,7 +511,7 @@ void intel_hdmi_init(struct drm_device *dev, int sdvox_reg)
 	connector->polled = DRM_CONNECTOR_POLL_HPD;
 	connector->interlace_allowed = 0;
 	connector->doublescan_allowed = 0;
-	intel_encoder->crtc_mask = (1 << 0) | (1 << 1);
+	intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
 
 	/* Set up the DDC bus. */
 	if (sdvox_reg == SDVOB) {
diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c
index 31da77f..42f165a 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -888,9 +888,11 @@ bool intel_lvds_init(struct drm_device *dev)
 	intel_encoder->type = INTEL_OUTPUT_LVDS;
 
 	intel_encoder->clone_mask = (1 << INTEL_LVDS_CLONE_BIT);
-	intel_encoder->crtc_mask = (1 << 1);
-	if (INTEL_INFO(dev)->gen >= 5)
-		intel_encoder->crtc_mask |= (1 << 0);
+	if (HAS_PCH_SPLIT(dev))
+		intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
+	else
+		intel_encoder->crtc_mask = (1 << 1);
+
 	drm_encoder_helper_add(encoder, &intel_lvds_helper_funcs);
 	drm_connector_helper_add(connector, &intel_lvds_connector_helper_funcs);
 	connector->display_info.subpixel_order = SubPixelHorizontalRGB;
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo.c
index 30fe554..f6853d6 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -2244,7 +2244,7 @@ intel_sdvo_output_setup(struct intel_sdvo *intel_sdvo, uint16_t flags)
 			      bytes[0], bytes[1]);
 		return false;
 	}
-	intel_sdvo->base.crtc_mask = (1 << 0) | (1 << 1);
+	intel_sdvo->base.crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
 
 	return true;
 }
-- 
1.7.4.1

[PATCH 3/4] drm/i915: split refclk code out of ironlake_crtc_mode_set

[Jesse Barnes]

Just a cleanup to make the mode_set function more manageable.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
---
 drivers/gpu/drm/i915/intel_display.c |   49 +++++++++++++++++++++++++++-------
 1 files changed, 39 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 0dffb52..058dc05 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5185,6 +5185,44 @@ static void ironlake_update_pch_refclk(struct drm_device *dev)
 	}
 }
 
+static int ironlake_get_refclk(struct drm_crtc *crtc)
+{
+	struct drm_device *dev = crtc->dev;
+	struct drm_i915_private *dev_priv = dev->dev_private;
+	struct intel_encoder *encoder;
+	struct drm_mode_config *mode_config = &dev->mode_config;
+	struct intel_encoder *edp_encoder = NULL;
+	int num_connectors = 0;
+	bool is_lvds = false;
+
+	list_for_each_entry(encoder, &mode_config->encoder_list, base.head) {
+		if (encoder->base.crtc != crtc)
+			continue;
+
+		switch (encoder->type) {
+		case INTEL_OUTPUT_LVDS:
+			is_lvds = true;
+			break;
+		case INTEL_OUTPUT_EDP:
+			edp_encoder = encoder;
+			break;
+		}
+		num_connectors++;
+	}
+
+	if (is_lvds && intel_panel_use_ssc(dev_priv) && num_connectors < 2) {
+		DRM_DEBUG_KMS("using SSC reference clock of %d MHz\n",
+			      dev_priv->lvds_ssc_freq);
+		return dev_priv->lvds_ssc_freq * 1000;
+	}
+
+	/* PCH ports use a 120 MHz refclk */
+	if (!edp_encoder || intel_encoder_is_pch_edp(&edp_encoder->base))
+		return 120000;
+	else
+		return 96000;
+}
+
 static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
 				  struct drm_display_mode *mode,
 				  struct drm_display_mode *adjusted_mode,
@@ -5244,16 +5282,7 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
 		num_connectors++;
 	}
 
-	if (is_lvds && intel_panel_use_ssc(dev_priv) && num_connectors < 2) {
-		refclk = dev_priv->lvds_ssc_freq * 1000;
-		DRM_DEBUG_KMS("using SSC reference clock of %d MHz\n",
-			      refclk / 1000);
-	} else {
-		refclk = 96000;
-		if (!has_edp_encoder ||
-		    intel_encoder_is_pch_edp(&has_edp_encoder->base))
-			refclk = 120000; /* 120Mhz refclk */
-	}
+	refclk = ironlake_get_refclk(crtc);
 
 	/*
 	 * Returns a set of divisors for the desired target clock with the given
-- 
1.7.4.1

[PATCH 4/4] drm/i915: more 3 pipe support

[Jesse Barnes]

Handle PLL allocation and transcoder select bits on CPT+.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
---
 drivers/gpu/drm/i915/intel_crt.c     |   13 ++---
 drivers/gpu/drm/i915/intel_display.c |   93 +++++++++++++++++++++------------
 drivers/gpu/drm/i915/intel_drv.h     |    3 +
 drivers/gpu/drm/i915/intel_hdmi.c    |   10 ++--
 4 files changed, 70 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 0979d88..da769e6 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -152,17 +152,12 @@ static void intel_crt_mode_set(struct drm_encoder *encoder,
 	if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC)
 		adpa |= ADPA_VSYNC_ACTIVE_HIGH;
 
-	if (intel_crtc->pipe == 0) {
-		if (HAS_PCH_CPT(dev))
-			adpa |= PORT_TRANS_A_SEL_CPT;
-		else
+	if (HAS_PCH_CPT(dev))
+		adpa |= PORT_TRANS_SEL_CPT(intel_crtc->pipe);
+	else if (intel_crtc->pipe == 0)
 			adpa |= ADPA_PIPE_A_SELECT;
-	} else {
-		if (HAS_PCH_CPT(dev))
-			adpa |= PORT_TRANS_B_SEL_CPT;
-		else
+	else
 			adpa |= ADPA_PIPE_B_SELECT;
-	}
 
 	if (!HAS_PCH_SPLIT(dev))
 		I915_WRITE(BCLRPAT(intel_crtc->pipe), 0);
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 058dc05..4d8f4f2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -802,6 +802,9 @@ static void assert_pch_pll(struct drm_i915_private *dev_priv,
 	u32 val;
 	bool cur_state;
 
+	if (pipe > 1)
+		return;
+
 	reg = PCH_DPLL(pipe);
 	val = I915_READ(reg);
 	cur_state = !!(val & DPLL_VCO_ENABLE);
@@ -2704,6 +2707,8 @@ static void ironlake_fdi_pll_enable(struct drm_crtc *crtc)
 	temp &= ~((0x7 << 19) | (0x7 << 16));
 	temp |= (intel_crtc->fdi_lanes - 1) << 19;
 	temp |= (I915_READ(PIPECONF(pipe)) & PIPE_BPC_MASK) << 11;
+	if (HAS_PCH_CPT(dev))
+		temp |= 1<<11;
 	I915_WRITE(reg, temp | FDI_RX_PLL_ENABLE);
 
 	POSTING_READ(reg);
@@ -2869,7 +2874,7 @@ static void ironlake_pch_enable(struct drm_crtc *crtc)
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 	int pipe = intel_crtc->pipe;
-	u32 reg, temp;
+	u32 reg, temp, transc_sel;
 
 	/* For PCH output, training FDI link */
 	dev_priv->display.fdi_link_train(crtc);
@@ -2877,6 +2882,9 @@ static void ironlake_pch_enable(struct drm_crtc *crtc)
 	intel_enable_pch_pll(dev_priv, pipe);
 
 	if (HAS_PCH_CPT(dev)) {
+		transc_sel = intel_crtc->use_pll_a ? TRANSC_DPLLA_SEL :
+			TRANSC_DPLLB_SEL;
+
 		/* Be sure PCH DPLL SEL is set */
 		temp = I915_READ(PCH_DPLL_SEL);
 		if (pipe == 0 && (temp & TRANSA_DPLL_ENABLE) == 0)
@@ -2884,7 +2892,7 @@ static void ironlake_pch_enable(struct drm_crtc *crtc)
 		else if (pipe == 1 && (temp & TRANSB_DPLL_ENABLE) == 0)
 			temp |= (TRANSB_DPLL_ENABLE | TRANSB_DPLLB_SEL);
 		else if (pipe == 2 && (temp & TRANSC_DPLL_ENABLE) == 0)
-			temp |= (TRANSC_DPLL_ENABLE | TRANSC_DPLLB_SEL);
+			temp |= (TRANSC_DPLL_ENABLE | transc_sel);
 		I915_WRITE(PCH_DPLL_SEL, temp);
 	}
 
@@ -3056,8 +3064,8 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
 			temp &= ~(TRANSB_DPLL_ENABLE | TRANSB_DPLLB_SEL);
 			break;
 		case 2:
-			/* FIXME: manage transcoder PLLs? */
-			temp &= ~(TRANSC_DPLL_ENABLE | TRANSC_DPLLB_SEL);
+			/* C shares PLL A or B */
+			temp &= ~(TRANSC_DPLL_ENABLE | TRANSB_DPLLB_SEL);
 			break;
 		default:
 			BUG(); /* wtf */
@@ -3066,7 +3074,8 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
 	}
 
 	/* disable PCH DPLL */
-	intel_disable_pch_pll(dev_priv, pipe);
+	if (!intel_crtc->no_pll)
+		intel_disable_pch_pll(dev_priv, pipe);
 
 	/* Switch from PCDclk to Rawclk */
 	reg = FDI_RX_CTL(pipe);
@@ -5486,16 +5495,32 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
 	drm_mode_debug_printmodeline(mode);
 
 	/* PCH eDP needs FDI, but CPU eDP does not */
-	if (!has_edp_encoder || intel_encoder_is_pch_edp(&has_edp_encoder->base)) {
+	if (!intel_crtc->no_pll &&
+	    (!has_edp_encoder ||
+	     intel_encoder_is_pch_edp(&has_edp_encoder->base))) {
 		I915_WRITE(PCH_FP0(pipe), fp);
 		I915_WRITE(PCH_DPLL(pipe), dpll & ~DPLL_VCO_ENABLE);
 
 		POSTING_READ(PCH_DPLL(pipe));
 		udelay(150);
+	} else {
+		if (dpll == (I915_READ(PCH_DPLL(0)) & 0x7fffffff) &&
+		    fp == I915_READ(PCH_FP0(0))) {
+			intel_crtc->use_pll_a = true;
+			DRM_DEBUG_KMS("using pipe a dpll\n");
+		} else if (dpll == (I915_READ(PCH_DPLL(1)) & 0x7fffffff) &&
+			   fp == I915_READ(PCH_FP0(1))) {
+			intel_crtc->use_pll_a = false;
+			DRM_DEBUG_KMS("using pipe b dpll\n");
+		} else
+			DRM_DEBUG_KMS("no matching PLL configuration for pipe 2\n");
 	}
 
 	/* enable transcoder DPLL */
+#if 1
 	if (HAS_PCH_CPT(dev)) {
+		u32 transc_sel = intel_crtc->use_pll_a ? TRANSC_DPLLA_SEL :
+			TRANSC_DPLLB_SEL;
 		temp = I915_READ(PCH_DPLL_SEL);
 		switch (pipe) {
 		case 0:
@@ -5505,8 +5530,7 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
 			temp |=	TRANSB_DPLL_ENABLE | TRANSB_DPLLB_SEL;
 			break;
 		case 2:
-			/* FIXME: manage transcoder PLLs? */
-			temp |= TRANSC_DPLL_ENABLE | TRANSC_DPLLB_SEL;
+			temp |= TRANSC_DPLL_ENABLE | transc_sel;
 			break;
 		default:
 			BUG();
@@ -5516,7 +5540,7 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
 		POSTING_READ(PCH_DPLL_SEL);
 		udelay(150);
 	}
-
+#endif
 	/* The LVDS pin pair needs to be on before the DPLLs are enabled.
 	 * This is an exception to the general rule that mode_set doesn't turn
 	 * things on.
@@ -5524,17 +5548,13 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
 	if (is_lvds) {
 		temp = I915_READ(PCH_LVDS);
 		temp |= LVDS_PORT_EN | LVDS_A0A2_CLKA_POWER_UP;
-		if (pipe == 1) {
-			if (HAS_PCH_CPT(dev))
-				temp |= PORT_TRANS_B_SEL_CPT;
-			else
-				temp |= LVDS_PIPEB_SELECT;
-		} else {
-			if (HAS_PCH_CPT(dev))
-				temp &= ~PORT_TRANS_SEL_MASK;
-			else
-				temp &= ~LVDS_PIPEB_SELECT;
-		}
+		if (HAS_PCH_CPT(dev))
+		    temp |= PORT_TRANS_SEL_CPT(pipe);
+		else if (pipe == 1)
+			temp |= LVDS_PIPEB_SELECT;
+		else
+			temp &= ~LVDS_PIPEB_SELECT;
+
 		/* set the corresponsding LVDS_BORDER bit */
 		temp |= dev_priv->lvds_border_bits;
 		/* Set the B0-B3 data pairs corresponding to whether we're going to
@@ -5584,8 +5604,9 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
 		I915_WRITE(TRANSDPLINK_N1(pipe), 0);
 	}
 
-	if (!has_edp_encoder ||
-	    intel_encoder_is_pch_edp(&has_edp_encoder->base)) {
+	if (!intel_crtc->no_pll &&
+	    (!has_edp_encoder ||
+	     intel_encoder_is_pch_edp(&has_edp_encoder->base))) {
 		I915_WRITE(PCH_DPLL(pipe), dpll);
 
 		/* Wait for the clocks to stabilize. */
@@ -5601,18 +5622,20 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
 	}
 
 	intel_crtc->lowfreq_avail = false;
-	if (is_lvds && has_reduced_clock && i915_powersave) {
-		I915_WRITE(PCH_FP1(pipe), fp2);
-		intel_crtc->lowfreq_avail = true;
-		if (HAS_PIPE_CXSR(dev)) {
-			DRM_DEBUG_KMS("enabling CxSR downclocking\n");
-			pipeconf |= PIPECONF_CXSR_DOWNCLOCK;
-		}
-	} else {
-		I915_WRITE(PCH_FP1(pipe), fp);
-		if (HAS_PIPE_CXSR(dev)) {
-			DRM_DEBUG_KMS("disabling CxSR downclocking\n");
-			pipeconf &= ~PIPECONF_CXSR_DOWNCLOCK;
+	if (!intel_crtc->no_pll) {
+		if (is_lvds && has_reduced_clock && i915_powersave) {
+			I915_WRITE(PCH_FP1(pipe), fp2);
+			intel_crtc->lowfreq_avail = true;
+			if (HAS_PIPE_CXSR(dev)) {
+				DRM_DEBUG_KMS("enabling CxSR downclocking\n");
+				pipeconf |= PIPECONF_CXSR_DOWNCLOCK;
+			}
+		} else {
+			I915_WRITE(PCH_FP1(pipe), fp);
+			if (HAS_PIPE_CXSR(dev)) {
+				DRM_DEBUG_KMS("disabling CxSR downclocking\n");
+				pipeconf &= ~PIPECONF_CXSR_DOWNCLOCK;
+			}
 		}
 	}
 
@@ -7103,6 +7126,8 @@ static void intel_crtc_init(struct drm_device *dev, int pipe)
 	intel_crtc->bpp = 24; /* default for pre-Ironlake */
 
 	if (HAS_PCH_SPLIT(dev)) {
+		if (pipe == 2 && IS_IVYBRIDGE(dev))
+			intel_crtc->no_pll = true;
 		intel_helper_funcs.prepare = ironlake_crtc_prepare;
 		intel_helper_funcs.commit = ironlake_crtc_commit;
 	} else {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0b2ee9d..4b5f543 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -171,6 +171,9 @@ struct intel_crtc {
 	int16_t cursor_width, cursor_height;
 	bool cursor_visible;
 	unsigned int bpp;
+
+	bool no_pll; /* tertiary pipe for IVB */
+	bool use_pll_a;
 };
 
 #define to_intel_crtc(x) container_of(x, struct intel_crtc, base)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
index 11883c9..ac621dd 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -249,12 +249,10 @@ static void intel_hdmi_mode_set(struct drm_encoder *encoder,
 		sdvox |= SDVO_NULL_PACKETS_DURING_VSYNC;
 	}
 
-	if (intel_crtc->pipe == 1) {
-		if (HAS_PCH_CPT(dev))
-			sdvox |= PORT_TRANS_B_SEL_CPT;
-		else
-			sdvox |= SDVO_PIPE_B_SELECT;
-	}
+	if (HAS_PCH_CPT(dev))
+		sdvox |= PORT_TRANS_SEL_CPT(intel_crtc->pipe);
+	else if (intel_crtc->pipe == 1)
+		sdvox |= SDVO_PIPE_B_SELECT;
 
 	I915_WRITE(intel_hdmi->sdvox_reg, sdvox);
 	POSTING_READ(intel_hdmi->sdvox_reg);
-- 
1.7.4.1

Re: [PATCH 1/4] drm/i915: PLL macro cleanup and pipe assertion check

[Jesse Barnes]

[-- Attachment #1.1: Type: text/plain, Size: 547 bytes --]

On Wed,  5 Oct 2011 10:25:18 -0700
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> Add a macro for accessing the two pipe PLLs and add a check to make sure
> we don't access a non-existent one in the enable/disable functions.

This reminds me that the IVB 3 pipe support has a big limitation: two
of the pipes need to share pipe PLLs.  That means they have to be the
same output port type and share timings, thus the two DP or identical
HDMI config implied in my earlier mail.

-- 
Jesse Barnes, Intel Open Source Technology Center

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

Re: [PATCH 1/4] drm/i915: PLL macro cleanup and pipe assertion check

[Keith Packard]

[-- Attachment #1.1: Type: text/plain, Size: 441 bytes --]

On Wed,  5 Oct 2011 10:25:18 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> Add a macro for accessing the two pipe PLLs and add a check to make sure
> we don't access a non-existent one in the enable/disable functions.

So, I haven't read through the specs, but are the PLLs tied to specific
pipes? Or are we really talking about a different object here, and just
mis-naming it as a 'pipe'?

-- 
keith.packard@intel.com

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

Re: [PATCH 3/4] drm/i915: split refclk code out of ironlake_crtc_mode_set

[Keith Packard]

[-- Attachment #1.1: Type: text/plain, Size: 381 bytes --]

On Wed,  5 Oct 2011 10:25:20 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> +	/* PCH ports use a 120 MHz refclk */
> +	if (!edp_encoder || intel_encoder_is_pch_edp(&edp_encoder->base))
> +		return 120000;
> +	else
> +		return 96000;
> +}

I can't find any documentation that says that there is any 96MHz refclk
on PCH hardware.

-- 
keith.packard@intel.com

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

Re: [PATCH 1/4] drm/i915: PLL macro cleanup and pipe assertion check

[Jesse Barnes]

[-- Attachment #1.1: Type: text/plain, Size: 954 bytes --]

On Wed, 05 Oct 2011 11:07:53 -0700
Keith Packard <keithp@keithp.com> wrote:

> On Wed,  5 Oct 2011 10:25:18 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> 
> > Add a macro for accessing the two pipe PLLs and add a check to make sure
> > we don't access a non-existent one in the enable/disable functions.
> 
> So, I haven't read through the specs, but are the PLLs tied to specific
> pipes? Or are we really talking about a different object here, and just
> mis-naming it as a 'pipe'?

They're not hardwired; we can use the DPLL_SEL reg to control which PLL
drives which transcoder.  Unfortunately our old pipe terminology is a
bit outdated with the PCH split.  It used to be the pipe was fairly
self-contained: a PLL with pipe and plane controls.  Now it's split
across the CPU and PCH with FDI in between (sometimes) and transcoder
configuration (sometimes with DP).

-- 
Jesse Barnes, Intel Open Source Technology Center

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

Re: [PATCH 3/4] drm/i915: split refclk code out of ironlake_crtc_mode_set

[Jesse Barnes]

[-- Attachment #1.1: Type: text/plain, Size: 685 bytes --]

On Wed, 05 Oct 2011 11:09:57 -0700
Keith Packard <keithp@keithp.com> wrote:

> On Wed,  5 Oct 2011 10:25:20 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> 
> > +	/* PCH ports use a 120 MHz refclk */
> > +	if (!edp_encoder || intel_encoder_is_pch_edp(&edp_encoder->base))
> > +		return 120000;
> > +	else
> > +		return 96000;
> > +}
> 
> I can't find any documentation that says that there is any 96MHz refclk
> on PCH hardware.

Was just preserving the old code; I think you've fixed this issue
already in another patch (looks like it's another one that's been there
since we first brought up ILK?).

-- 
Jesse Barnes, Intel Open Source Technology Center

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

Re: [PATCH 1/4] drm/i915: PLL macro cleanup and pipe assertion check

[Chris Wilson]

On Wed,  5 Oct 2011 10:25:18 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> Add a macro for accessing the two pipe PLLs and add a check to make sure
> we don't access a non-existent one in the enable/disable functions.
> 
> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> ---
>  drivers/gpu/drm/i915/i915_reg.h      |    6 +++---
>  drivers/gpu/drm/i915/intel_display.c |    6 ++++++
>  2 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 542453f..7659075 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2945,15 +2945,15 @@
>  
>  #define _PCH_DPLL_A              0xc6014
>  #define _PCH_DPLL_B              0xc6018
> -#define PCH_DPLL(pipe) _PIPE(pipe, _PCH_DPLL_A, _PCH_DPLL_B)
> +#define PCH_DPLL(pipe) (pipe == 0 ?  _PCH_DPLL_A : _PCH_DPLL_B)

If you check that pipe != 2 elsewhere why change these macros? What
might be a good addition is to use a compile-time assert in case we do
feed these an invalid enum pipe.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH 1/4] drm/i915: PLL macro cleanup and pipe assertion check

[Jesse Barnes]

[-- Attachment #1.1: Type: text/plain, Size: 1547 bytes --]

On Wed, 05 Oct 2011 19:43:53 +0100
Chris Wilson <chris@chris-wilson.co.uk> wrote:

> On Wed,  5 Oct 2011 10:25:18 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > Add a macro for accessing the two pipe PLLs and add a check to make sure
> > we don't access a non-existent one in the enable/disable functions.
> > 
> > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h      |    6 +++---
> >  drivers/gpu/drm/i915/intel_display.c |    6 ++++++
> >  2 files changed, 9 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> > index 542453f..7659075 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -2945,15 +2945,15 @@
> >  
> >  #define _PCH_DPLL_A              0xc6014
> >  #define _PCH_DPLL_B              0xc6018
> > -#define PCH_DPLL(pipe) _PIPE(pipe, _PCH_DPLL_A, _PCH_DPLL_B)
> > +#define PCH_DPLL(pipe) (pipe == 0 ?  _PCH_DPLL_A : _PCH_DPLL_B)
> 
> If you check that pipe != 2 elsewhere why change these macros? What
> might be a good addition is to use a compile-time assert in case we do
> feed these an invalid enum pipe.

Belt & suspenders; I added the checks and fixes at different times
too.  But a compile time check would be good for this one.  In future
PCH parts we'll have more PLLs to drive pipes, but they'll be at a
different offset so we'll need new macro anyway.

-- 
Jesse Barnes, Intel Open Source Technology Center

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

Re: [PATCH 3/4] drm/i915: split refclk code out of ironlake_crtc_mode_set

[Keith Packard]

[-- Attachment #1.1: Type: text/plain, Size: 490 bytes --]

On Wed, 5 Oct 2011 11:26:26 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> Was just preserving the old code; I think you've fixed this issue
> already in another patch (looks like it's another one that's been there
> since we first brought up ILK?).

I think the only case where we select the '96MHz' clock is the same case
where we hard-code the actually clock for DP.

I was just wondering if you had special info that I couldn't find.

-- 
keith.packard@intel.com

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

Re: [PATCH 4/4] drm/i915: more 3 pipe support

[Jesse Barnes]

[-- Attachment #1.1: Type: text/plain, Size: 11479 bytes --]

On Wed,  5 Oct 2011 10:25:21 -0700
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> Handle PLL allocation and transcoder select bits on CPT+.

Updated patch that fixes the bug with VGA plus two HDMI.  Was missing
the composite sync bits in the FDI TX side (setting them everywhere
here just to be safe).

-- 
Jesse Barnes, Intel Open Source Technology Center

From 3efb84701437f2d1eae3fb68c1259c2bb5a0c518 Mon Sep 17 00:00:00 2001
From: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri, 2 Sep 2011 15:28:39 -0700
Subject: [PATCH] drm/i915: more 3 pipe support

Handle PLL allocation and transcoder select bits on CPT+.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
---
 drivers/gpu/drm/i915/i915_reg.h      |    1 +
 drivers/gpu/drm/i915/intel_crt.c     |   13 +---
 drivers/gpu/drm/i915/intel_display.c |  101 +++++++++++++++++++++-------------
 drivers/gpu/drm/i915/intel_drv.h     |    3 +
 drivers/gpu/drm/i915/intel_hdmi.c    |   10 +--
 5 files changed, 74 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7659075..b31f253 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3167,6 +3167,7 @@
 #define  FDI_LINK_TRAIN_NONE_IVB            (3<<8)
 
 /* both Tx and Rx */
+#define  FDI_COMPOSITE_SYNC		(1<<11)
 #define  FDI_LINK_TRAIN_AUTO		(1<<10)
 #define  FDI_SCRAMBLING_ENABLE          (0<<7)
 #define  FDI_SCRAMBLING_DISABLE         (1<<7)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 0979d88..da769e6 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -152,17 +152,12 @@ static void intel_crt_mode_set(struct drm_encoder *encoder,
 	if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC)
 		adpa |= ADPA_VSYNC_ACTIVE_HIGH;
 
-	if (intel_crtc->pipe == 0) {
-		if (HAS_PCH_CPT(dev))
-			adpa |= PORT_TRANS_A_SEL_CPT;
-		else
+	if (HAS_PCH_CPT(dev))
+		adpa |= PORT_TRANS_SEL_CPT(intel_crtc->pipe);
+	else if (intel_crtc->pipe == 0)
 			adpa |= ADPA_PIPE_A_SELECT;
-	} else {
-		if (HAS_PCH_CPT(dev))
-			adpa |= PORT_TRANS_B_SEL_CPT;
-		else
+	else
 			adpa |= ADPA_PIPE_B_SELECT;
-	}
 
 	if (!HAS_PCH_SPLIT(dev))
 		I915_WRITE(BCLRPAT(intel_crtc->pipe), 0);
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 058dc05..e63a187 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -802,6 +802,9 @@ static void assert_pch_pll(struct drm_i915_private *dev_priv,
 	u32 val;
 	bool cur_state;
 
+	if (pipe > 1)
+		return;
+
 	reg = PCH_DPLL(pipe);
 	val = I915_READ(reg);
 	cur_state = !!(val & DPLL_VCO_ENABLE);
@@ -2366,6 +2369,7 @@ static void ironlake_fdi_link_train(struct drm_crtc *crtc)
 	temp = I915_READ(reg);
 	temp &= ~FDI_RX_SYMBOL_LOCK;
 	temp &= ~FDI_RX_BIT_LOCK;
+	temp |= FDI_COMPOSITE_SYNC;
 	I915_WRITE(reg, temp);
 	I915_READ(reg);
 	udelay(150);
@@ -2377,6 +2381,7 @@ static void ironlake_fdi_link_train(struct drm_crtc *crtc)
 	temp |= (intel_crtc->fdi_lanes - 1) << 19;
 	temp &= ~FDI_LINK_TRAIN_NONE;
 	temp |= FDI_LINK_TRAIN_PATTERN_1;
+	temp |= FDI_COMPOSITE_SYNC;
 	I915_WRITE(reg, temp | FDI_TX_ENABLE);
 
 	reg = FDI_RX_CTL(pipe);
@@ -2704,6 +2709,8 @@ static void ironlake_fdi_pll_enable(struct drm_crtc *crtc)
 	temp &= ~((0x7 << 19) | (0x7 << 16));
 	temp |= (intel_crtc->fdi_lanes - 1) << 19;
 	temp |= (I915_READ(PIPECONF(pipe)) & PIPE_BPC_MASK) << 11;
+	if (HAS_PCH_CPT(dev))
+		temp |= 1<<11;
 	I915_WRITE(reg, temp | FDI_RX_PLL_ENABLE);
 
 	POSTING_READ(reg);
@@ -2869,7 +2876,7 @@ static void ironlake_pch_enable(struct drm_crtc *crtc)
 	struct drm_i915_private *dev_priv = dev->dev_private;
 	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 	int pipe = intel_crtc->pipe;
-	u32 reg, temp;
+	u32 reg, temp, transc_sel;
 
 	/* For PCH output, training FDI link */
 	dev_priv->display.fdi_link_train(crtc);
@@ -2877,6 +2884,9 @@ static void ironlake_pch_enable(struct drm_crtc *crtc)
 	intel_enable_pch_pll(dev_priv, pipe);
 
 	if (HAS_PCH_CPT(dev)) {
+		transc_sel = intel_crtc->use_pll_a ? TRANSC_DPLLA_SEL :
+			TRANSC_DPLLB_SEL;
+
 		/* Be sure PCH DPLL SEL is set */
 		temp = I915_READ(PCH_DPLL_SEL);
 		if (pipe == 0 && (temp & TRANSA_DPLL_ENABLE) == 0)
@@ -2884,7 +2894,7 @@ static void ironlake_pch_enable(struct drm_crtc *crtc)
 		else if (pipe == 1 && (temp & TRANSB_DPLL_ENABLE) == 0)
 			temp |= (TRANSB_DPLL_ENABLE | TRANSB_DPLLB_SEL);
 		else if (pipe == 2 && (temp & TRANSC_DPLL_ENABLE) == 0)
-			temp |= (TRANSC_DPLL_ENABLE | TRANSC_DPLLB_SEL);
+			temp |= (TRANSC_DPLL_ENABLE | transc_sel);
 		I915_WRITE(PCH_DPLL_SEL, temp);
 	}
 
@@ -3056,8 +3066,8 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
 			temp &= ~(TRANSB_DPLL_ENABLE | TRANSB_DPLLB_SEL);
 			break;
 		case 2:
-			/* FIXME: manage transcoder PLLs? */
-			temp &= ~(TRANSC_DPLL_ENABLE | TRANSC_DPLLB_SEL);
+			/* C shares PLL A or B */
+			temp &= ~(TRANSC_DPLL_ENABLE | TRANSB_DPLLB_SEL);
 			break;
 		default:
 			BUG(); /* wtf */
@@ -3066,7 +3076,8 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
 	}
 
 	/* disable PCH DPLL */
-	intel_disable_pch_pll(dev_priv, pipe);
+	if (!intel_crtc->no_pll)
+		intel_disable_pch_pll(dev_priv, pipe);
 
 	/* Switch from PCDclk to Rawclk */
 	reg = FDI_RX_CTL(pipe);
@@ -5216,11 +5227,7 @@ static int ironlake_get_refclk(struct drm_crtc *crtc)
 		return dev_priv->lvds_ssc_freq * 1000;
 	}
 
-	/* PCH ports use a 120 MHz refclk */
-	if (!edp_encoder || intel_encoder_is_pch_edp(&edp_encoder->base))
-		return 120000;
-	else
-		return 96000;
+	return 120000;
 }
 
 static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
@@ -5486,16 +5493,32 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
 	drm_mode_debug_printmodeline(mode);
 
 	/* PCH eDP needs FDI, but CPU eDP does not */
-	if (!has_edp_encoder || intel_encoder_is_pch_edp(&has_edp_encoder->base)) {
+	if (!intel_crtc->no_pll &&
+	    (!has_edp_encoder ||
+	     intel_encoder_is_pch_edp(&has_edp_encoder->base))) {
 		I915_WRITE(PCH_FP0(pipe), fp);
 		I915_WRITE(PCH_DPLL(pipe), dpll & ~DPLL_VCO_ENABLE);
 
 		POSTING_READ(PCH_DPLL(pipe));
 		udelay(150);
+	} else {
+		if (dpll == (I915_READ(PCH_DPLL(0)) & 0x7fffffff) &&
+		    fp == I915_READ(PCH_FP0(0))) {
+			intel_crtc->use_pll_a = true;
+			DRM_DEBUG_KMS("using pipe a dpll\n");
+		} else if (dpll == (I915_READ(PCH_DPLL(1)) & 0x7fffffff) &&
+			   fp == I915_READ(PCH_FP0(1))) {
+			intel_crtc->use_pll_a = false;
+			DRM_DEBUG_KMS("using pipe b dpll\n");
+		} else
+			DRM_DEBUG_KMS("no matching PLL configuration for pipe 2\n");
 	}
 
 	/* enable transcoder DPLL */
+#if 1
 	if (HAS_PCH_CPT(dev)) {
+		u32 transc_sel = intel_crtc->use_pll_a ? TRANSC_DPLLA_SEL :
+			TRANSC_DPLLB_SEL;
 		temp = I915_READ(PCH_DPLL_SEL);
 		switch (pipe) {
 		case 0:
@@ -5505,8 +5528,7 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
 			temp |=	TRANSB_DPLL_ENABLE | TRANSB_DPLLB_SEL;
 			break;
 		case 2:
-			/* FIXME: manage transcoder PLLs? */
-			temp |= TRANSC_DPLL_ENABLE | TRANSC_DPLLB_SEL;
+			temp |= TRANSC_DPLL_ENABLE | transc_sel;
 			break;
 		default:
 			BUG();
@@ -5516,7 +5538,7 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
 		POSTING_READ(PCH_DPLL_SEL);
 		udelay(150);
 	}
-
+#endif
 	/* The LVDS pin pair needs to be on before the DPLLs are enabled.
 	 * This is an exception to the general rule that mode_set doesn't turn
 	 * things on.
@@ -5524,17 +5546,13 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
 	if (is_lvds) {
 		temp = I915_READ(PCH_LVDS);
 		temp |= LVDS_PORT_EN | LVDS_A0A2_CLKA_POWER_UP;
-		if (pipe == 1) {
-			if (HAS_PCH_CPT(dev))
-				temp |= PORT_TRANS_B_SEL_CPT;
-			else
-				temp |= LVDS_PIPEB_SELECT;
-		} else {
-			if (HAS_PCH_CPT(dev))
-				temp &= ~PORT_TRANS_SEL_MASK;
-			else
-				temp &= ~LVDS_PIPEB_SELECT;
-		}
+		if (HAS_PCH_CPT(dev))
+		    temp |= PORT_TRANS_SEL_CPT(pipe);
+		else if (pipe == 1)
+			temp |= LVDS_PIPEB_SELECT;
+		else
+			temp &= ~LVDS_PIPEB_SELECT;
+
 		/* set the corresponsding LVDS_BORDER bit */
 		temp |= dev_priv->lvds_border_bits;
 		/* Set the B0-B3 data pairs corresponding to whether we're going to
@@ -5584,8 +5602,9 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
 		I915_WRITE(TRANSDPLINK_N1(pipe), 0);
 	}
 
-	if (!has_edp_encoder ||
-	    intel_encoder_is_pch_edp(&has_edp_encoder->base)) {
+	if (!intel_crtc->no_pll &&
+	    (!has_edp_encoder ||
+	     intel_encoder_is_pch_edp(&has_edp_encoder->base))) {
 		I915_WRITE(PCH_DPLL(pipe), dpll);
 
 		/* Wait for the clocks to stabilize. */
@@ -5601,18 +5620,20 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
 	}
 
 	intel_crtc->lowfreq_avail = false;
-	if (is_lvds && has_reduced_clock && i915_powersave) {
-		I915_WRITE(PCH_FP1(pipe), fp2);
-		intel_crtc->lowfreq_avail = true;
-		if (HAS_PIPE_CXSR(dev)) {
-			DRM_DEBUG_KMS("enabling CxSR downclocking\n");
-			pipeconf |= PIPECONF_CXSR_DOWNCLOCK;
-		}
-	} else {
-		I915_WRITE(PCH_FP1(pipe), fp);
-		if (HAS_PIPE_CXSR(dev)) {
-			DRM_DEBUG_KMS("disabling CxSR downclocking\n");
-			pipeconf &= ~PIPECONF_CXSR_DOWNCLOCK;
+	if (!intel_crtc->no_pll) {
+		if (is_lvds && has_reduced_clock && i915_powersave) {
+			I915_WRITE(PCH_FP1(pipe), fp2);
+			intel_crtc->lowfreq_avail = true;
+			if (HAS_PIPE_CXSR(dev)) {
+				DRM_DEBUG_KMS("enabling CxSR downclocking\n");
+				pipeconf |= PIPECONF_CXSR_DOWNCLOCK;
+			}
+		} else {
+			I915_WRITE(PCH_FP1(pipe), fp);
+			if (HAS_PIPE_CXSR(dev)) {
+				DRM_DEBUG_KMS("disabling CxSR downclocking\n");
+				pipeconf &= ~PIPECONF_CXSR_DOWNCLOCK;
+			}
 		}
 	}
 
@@ -7103,6 +7124,8 @@ static void intel_crtc_init(struct drm_device *dev, int pipe)
 	intel_crtc->bpp = 24; /* default for pre-Ironlake */
 
 	if (HAS_PCH_SPLIT(dev)) {
+		if (pipe == 2 && IS_IVYBRIDGE(dev))
+			intel_crtc->no_pll = true;
 		intel_helper_funcs.prepare = ironlake_crtc_prepare;
 		intel_helper_funcs.commit = ironlake_crtc_commit;
 	} else {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0b2ee9d..4b5f543 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -171,6 +171,9 @@ struct intel_crtc {
 	int16_t cursor_width, cursor_height;
 	bool cursor_visible;
 	unsigned int bpp;
+
+	bool no_pll; /* tertiary pipe for IVB */
+	bool use_pll_a;
 };
 
 #define to_intel_crtc(x) container_of(x, struct intel_crtc, base)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
index 11883c9..ac621dd 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -249,12 +249,10 @@ static void intel_hdmi_mode_set(struct drm_encoder *encoder,
 		sdvox |= SDVO_NULL_PACKETS_DURING_VSYNC;
 	}
 
-	if (intel_crtc->pipe == 1) {
-		if (HAS_PCH_CPT(dev))
-			sdvox |= PORT_TRANS_B_SEL_CPT;
-		else
-			sdvox |= SDVO_PIPE_B_SELECT;
-	}
+	if (HAS_PCH_CPT(dev))
+		sdvox |= PORT_TRANS_SEL_CPT(intel_crtc->pipe);
+	else if (intel_crtc->pipe == 1)
+		sdvox |= SDVO_PIPE_B_SELECT;
 
 	I915_WRITE(intel_hdmi->sdvox_reg, sdvox);
 	POSTING_READ(intel_hdmi->sdvox_reg);
-- 
1.7.4.1


[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

Re: [RFC] Three pipe support for IVB

[Jesse Barnes]

[-- Attachment #1.1: Type: text/plain, Size: 1415 bytes --]

On Wed,  5 Oct 2011 10:25:17 -0700
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> This set of patches lays the groundwork for supporting 3 pipes on IVB
> hardware.  We've only tested it so far with 2 HDMI plus 1 VGA (a
> configuration that doesn't work), and are awaiting 3 DP port hardware
> (the officially supported config) to complete our testing.
> 
> So this patchset is necessary but may not be sufficient (once we have 3
> DP hardware we can debug and see).  Review and comments appreciated.

Gordon, I think this set (with the updated 4/4 patch) is ready for
testing.  You'll need a configuration that uses the same monitor on two
identical ports to get all the pipes running.  I'm also interested in
the failure cases though.  There are some limitations:
  1) two heads need to use the same timings and ports
  2) FDI B and C share lanes, so are limited to a max of two lanes each

For (1), I'm currently using a VGA attached monitor, an HDMI attached
monitor, and another HDMI monitor attached to a DP->HDMI dongle on my
SDV (that allows me to drive the port with the HDMI encoder rather than
the DP encoder).

Unfortunately, (2) complicates our mode list output.  If you query for
available modes, you'll definitely see some that you can't drive with 3
pipes enabled.  I'm not sure if the best way to handle that...

-- 
Jesse Barnes, Intel Open Source Technology Center

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

Re: [RFC] Three pipe support for IVB

[Keith Packard]

[-- Attachment #1.1: Type: text/plain, Size: 728 bytes --]

On Wed, 5 Oct 2011 12:56:47 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> Unfortunately, (2) complicates our mode list output.  If you query for
> available modes, you'll definitely see some that you can't drive with 3
> pipes enabled.  I'm not sure if the best way to handle that...

All we can do is say 'no' when someone tries to select that
configuration. We've never figured out a better way to list valid
settings.

The proposed RandR 1.4 protocol has a 'set everything all at once' API
which allows you to say 'no' before even starting the mode setting
process, which is kinda nice. We just need to make sure sure this can be
mirrored through KMS to the hardware.

-- 
keith.packard@intel.com

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

Re: [RFC] Three pipe support for IVB

[Eugeni Dodonov]

[-- Attachment #1.1: Type: text/plain, Size: 1787 bytes --]

On Wed, Oct 5, 2011 at 16:56, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> On Wed,  5 Oct 2011 10:25:17 -0700
> Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>
> > This set of patches lays the groundwork for supporting 3 pipes on IVB
> > hardware.  We've only tested it so far with 2 HDMI plus 1 VGA (a
> > configuration that doesn't work), and are awaiting 3 DP port hardware
> > (the officially supported config) to complete our testing.
> >
> > So this patchset is necessary but may not be sufficient (once we have 3
> > DP hardware we can debug and see).  Review and comments appreciated.
>
> Gordon, I think this set (with the updated 4/4 patch) is ready for
> testing.  You'll need a configuration that uses the same monitor on two
> identical ports to get all the pipes running.  I'm also interested in
> the failure cases though.  There are some limitations:
>  1) two heads need to use the same timings and ports
>  2) FDI B and C share lanes, so are limited to a max of two lanes each
>
> For (1), I'm currently using a VGA attached monitor, an HDMI attached
> monitor, and another HDMI monitor attached to a DP->HDMI dongle on my
> SDV (that allows me to drive the port with the HDMI encoder rather than
> the DP encoder).
>
> Unfortunately, (2) complicates our mode list output.  If you query for
> available modes, you'll definitely see some that you can't drive with 3
> pipes enabled.  I'm not sure if the best way to handle that...
>

It works - with a small change to the FDI_COMPOSITE_SYNC which we discussed
on irc with Jesse - I'll send it on the corresponding patch.

With that change, for the series:

Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Tested-By: Eugeni Dodonov <eugeni.dodonov@intel.com>

-- 
Eugeni Dodonov
<http://eugeni.dodonov.net/>

[-- Attachment #1.2: Type: text/html, Size: 2476 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

Re: [PATCH 4/4] drm/i915: more 3 pipe support

[Eugeni Dodonov]

[-- Attachment #1.1: Type: text/plain, Size: 1817 bytes --]

On Wed, Oct 5, 2011 at 16:48, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

> On Wed,  5 Oct 2011 10:25:21 -0700
> Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>
> > Handle PLL allocation and transcoder select bits on CPT+.
>
> Updated patch that fixes the bug with VGA plus two HDMI.  Was missing
> the composite sync bits in the FDI TX side (setting them everywhere
> here just to be safe).
>
> --
> Jesse Barnes, Intel Open Source Technology Center
>


The following chunk which we discussed on IRC earlier today made it work
correctly on IVB:

>From 8a5e2eb86f62ab14ca0c12b16628e009d1fcbe98 Mon Sep 17 00:00:00 2001
From: Eugeni Dodonov <eugeni.dodonov@intel.com>
Date: Wed, 5 Oct 2011 18:34:09 -0300
Subject: [PATCH] Enable composite sync bit on IVB

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
---
 drivers/gpu/drm/i915/intel_display.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e63a187..26cadff 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2608,6 +2608,7 @@ static void ivb_manual_fdi_link_train(struct drm_crtc
*crtc)
     temp |= FDI_LINK_TRAIN_PATTERN_1_IVB;
     temp &= ~FDI_LINK_TRAIN_VOL_EMP_MASK;
     temp |= FDI_LINK_TRAIN_400MV_0DB_SNB_B;
+    temp |= FDI_COMPOSITE_SYNC;
     I915_WRITE(reg, temp | FDI_TX_ENABLE);

     reg = FDI_RX_CTL(pipe);
@@ -2615,6 +2616,7 @@ static void ivb_manual_fdi_link_train(struct drm_crtc
*crtc)
     temp &= ~FDI_LINK_TRAIN_AUTO;
     temp &= ~FDI_LINK_TRAIN_PATTERN_MASK_CPT;
     temp |= FDI_LINK_TRAIN_PATTERN_1_CPT;
+    temp |= FDI_COMPOSITE_SYNC;
     I915_WRITE(reg, temp | FDI_RX_ENABLE);

     POSTING_READ(reg);
-- 
1.7.6.4

-- 
Eugeni Dodonov
<http://eugeni.dodonov.net/>

[-- Attachment #1.2: Type: text/html, Size: 2475 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

Re: [RFC] Three pipe support for IVB

[Dave Airlie]

On Wed, Oct 5, 2011 at 9:18 PM, Keith Packard <keithp@keithp.com> wrote:
> On Wed, 5 Oct 2011 12:56:47 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>
>> Unfortunately, (2) complicates our mode list output.  If you query for
>> available modes, you'll definitely see some that you can't drive with 3
>> pipes enabled.  I'm not sure if the best way to handle that...
>
> All we can do is say 'no' when someone tries to select that
> configuration. We've never figured out a better way to list valid
> settings.
>
> The proposed RandR 1.4 protocol has a 'set everything all at once' API
> which allows you to say 'no' before even starting the mode setting
> process, which is kinda nice. We just need to make sure sure this can be
> mirrored through KMS to the hardware.

Fine for dynamic stuff, how do you pick a correct initial mode?

You can't say no there, you need to make a decision from the
information provided.

Dave.

Re: [RFC] Three pipe support for IVB

[Jesse Barnes]

[-- Attachment #1.1: Type: text/plain, Size: 1894 bytes --]

On Thu, 6 Oct 2011 07:31:44 +0100
Dave Airlie <airlied@gmail.com> wrote:

> On Wed, Oct 5, 2011 at 9:18 PM, Keith Packard <keithp@keithp.com> wrote:
> > On Wed, 5 Oct 2011 12:56:47 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> >
> >> Unfortunately, (2) complicates our mode list output.  If you query for
> >> available modes, you'll definitely see some that you can't drive with 3
> >> pipes enabled.  I'm not sure if the best way to handle that...
> >
> > All we can do is say 'no' when someone tries to select that
> > configuration. We've never figured out a better way to list valid
> > settings.
> >
> > The proposed RandR 1.4 protocol has a 'set everything all at once' API
> > which allows you to say 'no' before even starting the mode setting
> > process, which is kinda nice. We just need to make sure sure this can be
> > mirrored through KMS to the hardware.
> 
> Fine for dynamic stuff, how do you pick a correct initial mode?
> 
> You can't say no there, you need to make a decision from the
> information provided.

Yeah that's a good point.  There's something weird going on in general
with X's default config on my system at least.  All 3 heads come up at
1280x1024, but the two identical HDMI heads come up with different
refresh rates for some reason (one uses the preferred mode and the
other tries to get 75Hz).

Of course I'd prefer an extended config as the default, which might
make it easier to choose all the preferred modes, but that doesn't
solve the problem of having say two 1920x1200 monitors attached along
with a 2560x1600, which won't work on IVB...

Should we add a new mode flag to indicate which modes are conditional
on config and which modes can always be supported?  That way X and
other tools could get all the heads lit up by default at least...

-- 
Jesse Barnes, Intel Open Source Technology Center

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

Re: [RFC] Three pipe support for IVB

[Keith Packard]

[-- Attachment #1.1: Type: text/plain, Size: 343 bytes --]

On Thu, 6 Oct 2011 07:31:44 +0100, Dave Airlie <airlied@gmail.com> wrote:

> You can't say no there, you need to make a decision from the
> information provided.

Yeah, you'd end up having to use two modes with the same clock. Let's
hope DisplayPort ends up a lot more popular than it has gotten so far?

-- 
keith.packard@intel.com

[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

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

Re: [RFC] Three pipe support for IVB

[Daniel Vetter]

On Thu, Oct 06, 2011 at 08:18:30AM -0700, Jesse Barnes wrote:
> On Thu, 6 Oct 2011 07:31:44 +0100
> Dave Airlie <airlied@gmail.com> wrote:
> > On Wed, Oct 5, 2011 at 9:18 PM, Keith Packard <keithp@keithp.com> wrote:
> > > On Wed, 5 Oct 2011 12:56:47 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> > >
> > >> Unfortunately, (2) complicates our mode list output.  If you query for
> > >> available modes, you'll definitely see some that you can't drive with 3
> > >> pipes enabled.  I'm not sure if the best way to handle that...
> > >
> > > All we can do is say 'no' when someone tries to select that
> > > configuration. We've never figured out a better way to list valid
> > > settings.
> > >
> > > The proposed RandR 1.4 protocol has a 'set everything all at once' API
> > > which allows you to say 'no' before even starting the mode setting
> > > process, which is kinda nice. We just need to make sure sure this can be
> > > mirrored through KMS to the hardware.
> > 
> > Fine for dynamic stuff, how do you pick a correct initial mode?
> > 
> > You can't say no there, you need to make a decision from the
> > information provided.
> 
> Yeah that's a good point.  There's something weird going on in general
> with X's default config on my system at least.  All 3 heads come up at
> 1280x1024, but the two identical HDMI heads come up with different
> refresh rates for some reason (one uses the preferred mode and the
> other tries to get 75Hz).
> 
> Of course I'd prefer an extended config as the default, which might
> make it easier to choose all the preferred modes, but that doesn't
> solve the problem of having say two 1920x1200 monitors attached along
> with a 2560x1600, which won't work on IVB...
> 
> Should we add a new mode flag to indicate which modes are conditional
> on config and which modes can always be supported?  That way X and
> other tools could get all the heads lit up by default at least...

For the kernel console we have the identical "light up as much as possible
in the hope the user can see something" problem. So I think the only thing
to do is to expose the kernel console mode somewhere (in case a running X
session has totally mangled the modeset config). This way we need to solve
the problem only once and the kernel has all the information to make the
best out of it.

For everything else userspace just has to remember the users preferred
modeset layout and restore it on boot-up. I should be safe to assume that
a given mode that once worked should continue to do so, and if it fails
userspace can fall back to the kernel console configuration.

-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48