[PATCH 00/29] Haswell round 3

[PATCH 00/29] Haswell round 3

[Eugeni Dodonov]

Hi forks,

Just in time for everyone's weekend, here comes the 3rd round of patches on
Haswell.

As major highlights, it also adds support for HDMI/DVI outputs and multi-head
modes (I tried with VGA and HDMI).

Other than that, it is the same patches with comments from the past round
addressed (SBI locking support, proper WM calculation, better PCH items
detection, and so on).

Daniel, I think that the bits definitions, power wells, clocks programming, and
modesetting for both FDI and HDMI modes should be good to go unless someone
spots additional issues with them - so please, all of you who have something to
say about them, say it now and bikeshed as you please :).

Note that the DP and eDP modesetting support is not there yet - it will still
require a considerable amount of patches.

Also, there is one patch which fixes null pointer exceptions in gmbus code I
was having with some of the drm-intel-next-queued iterations, but I don't think
it is necessary at the moment now that gmbus stuff was disabled again (patch
5). I am not even sure if we'll hit those code paths with invalid values in
real life, so I simple added some checks for cases when we don't have a valid
adapter as it was looking too error-prone otherwise. Perhaps we could add a
WARN into them as well.

Eugeni Dodonov (29):
  drm/i915: add definition of LPT FDI port width registers
  drm/i915: add WRPLL divider programming bits
  drm/i915: add Haswell DIP controls registers
  drm/i915: support infoframes on Haswell
  drm/i915: prevent NULL pointer exception when using gmbus
  drm/i915: add support for SBI ops
  drm/i915: calculate same watermarks on Haswell as on Ivy Bridge
  drm/i915: share forcewaking code between IVB and HSW
  drm/i915: haswell has 3 pipes as well
  drm/i915: reuse Ivybridge interrupts code for Haswell
  drm/i915: share pipe count handling with Ivybridge
  drm/i915: share IVB cursor routine with Haswell
  drm/i915: show unknown sdvox registers on hdmi init
  drm/i915: do not use fdi_normal_train on haswell
  drm/i915: do not enable PCH PLL on pre-haswell
  drm/i915: detect PCH encoders on Haswell
  drm/i915: enable power wells on haswell init
  drm/i915: disable rc6 on haswell for now
  drm/i915: program WM_LINETIME on Haswell
  drm/i915: do not use old code paths on Haswell
  drm/i915: initialize DDI buffer translations
  drm/i915: perform Haswell DDI link training in FDI mode
  drm/i915: disable pipe DDI function when disabling pipe
  drm/i915: program iCLKIP on Lynx Point
  drm/i915: detect digital outputs on Haswell
  drm/i915: add support for DDI-controlled digital outputs
  drm/i915: add WR PLL programming table
  drm/i915: prepare HDMI link for Haswell
  drm/i915: hook Haswell devices in place

 drivers/char/agp/intel-agp.c         |    4 +
 drivers/gpu/drm/i915/i915_dma.c      |    2 +-
 drivers/gpu/drm/i915/i915_drv.c      |    7 +
 drivers/gpu/drm/i915/i915_irq.c      |    6 +-
 drivers/gpu/drm/i915/i915_reg.h      |   23 +
 drivers/gpu/drm/i915/intel_display.c |  763 ++++++++++++++++++++++++++++++++--
 drivers/gpu/drm/i915/intel_drv.h     |    1 +
 drivers/gpu/drm/i915/intel_hdmi.c    |  602 ++++++++++++++++++++++++++-
 8 files changed, 1357 insertions(+), 51 deletions(-)

-- 
1.7.10

[PATCH 01/29] drm/i915: add definition of LPT FDI port width registers

[Eugeni Dodonov]

v2: change bits names to align better with other bits style

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
---
 drivers/gpu/drm/i915/i915_reg.h |    3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 972321f..98579f5 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3648,6 +3648,9 @@
 #define  FDI_LINK_TRAIN_PATTERN_IDLE_CPT	(2<<8)
 #define  FDI_LINK_TRAIN_NORMAL_CPT		(3<<8)
 #define  FDI_LINK_TRAIN_PATTERN_MASK_CPT	(3<<8)
+/* LPT */
+#define  FDI_PORT_WIDTH_2X_LPT			(1<<19)
+#define  FDI_PORT_WIDTH_1X_LPT			(0<<19)
 
 #define _FDI_RXA_MISC            0xf0010
 #define _FDI_RXB_MISC            0xf1010
-- 
1.7.10

[PATCH 02/29] drm/i915: add WRPLL divider programming bits

[Eugeni Dodonov]

Those are used to program the WRPLL dividers correctly for each gives
frequency.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
---
 drivers/gpu/drm/i915/i915_reg.h |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 98579f5..05d98f2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4178,6 +4178,10 @@
 #define  WRPLL_PLL_SELECT_SSC			(0x01<<28)
 #define  WRPLL_PLL_SELECT_NON_SCC		(0x02<<28)
 #define  WRPLL_PLL_SELECT_LCPLL_2700	(0x03<<28)
+/* WRPLL divider programming */
+#define  WRPLL_DIVIDER_REFERENCE(x)		((x)<<0)
+#define  WRPLL_DIVIDER_POST(x)			((x)<<8)
+#define  WRPLL_DIVIDER_FEEDBACK(x)		((x)<<16)
 
 /* Port clock selection */
 #define PORT_CLK_SEL_A			0x46100
-- 
1.7.10

[PATCH 03/29] drm/i915: add Haswell DIP controls registers

[Eugeni Dodonov]

Haswell has different DIP control registers and offsets.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
---
 drivers/gpu/drm/i915/i915_reg.h |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 05d98f2..8cc53fb 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3488,6 +3488,22 @@
 #define VLV_TVIDEO_DIP_GCP(pipe) \
 	_PIPE(pipe, VLV_VIDEO_DIP_GDCP_PAYLOAD_A, VLV_VIDEO_DIP_GDCP_PAYLOAD_B)
 
+/* Haswell DIP controls */
+#define HSW_VIDEO_DIP_CTL_A			0x60200
+#define HSW_VIDEO_DIP_AVI_DATA_A	0x60220
+#define HSW_VIDEO_DIP_GCP_A			0x60210
+
+#define HSW_VIDEO_DIP_CTL_B			0x61200
+#define HSW_VIDEO_DIP_AVI_DATA_B	0x61220
+#define HSW_VIDEO_DIP_GCP_B			0x61210
+
+#define HSW_TVIDEO_DIP_CTL(pipe) \
+	 _PIPE(pipe, HSW_VIDEO_DIP_CTL_A, HSW_VIDEO_DIP_CTL_B)
+#define HSW_TVIDEO_DIP_AVI_DATA(pipe) \
+	 _PIPE(pipe, HSW_VIDEO_DIP_AVI_DATA_A, HSW_VIDEO_DIP_AVI_DATA_B)
+#define HSW_TVIDEO_DIP_GCP(pipe) \
+	_PIPE(pipe, HSW_VIDEO_DIP_GCP_A, HSW_VIDEO_DIP_GCP_B)
+
 #define _TRANS_HTOTAL_B          0xe1000
 #define _TRANS_HBLANK_B          0xe1004
 #define _TRANS_HSYNC_B           0xe1008
-- 
1.7.10

Re: [PATCH 03/29] drm/i915: add Haswell DIP controls registers

[Daniel Vetter]

On Fri, Apr 13, 2012 at 05:08:39PM -0300, Eugeni Dodonov wrote:
> Haswell has different DIP control registers and offsets.
> 
> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>

I've read a bit through Bspec wrt dip writing and it looks like hsw is
rather differen from previous chips:
- with have a data reg for every type of dip
- the bits in the ctl reg moved around completely

... so I guess this patch and the follow-on one are pretty bogus. One
thing I've noticed is that intel_infoframe_index and intel_infoframe_flags
have way too generic names, they're only useful to frob the dip ctl reg on
pre-hsw afaics. I think we should rename them to i9xx_infoframe_ctl_inde
and _flags or something similar.

-Daniel
> ---
>  drivers/gpu/drm/i915/i915_reg.h |   16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 05d98f2..8cc53fb 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3488,6 +3488,22 @@
>  #define VLV_TVIDEO_DIP_GCP(pipe) \
>  	_PIPE(pipe, VLV_VIDEO_DIP_GDCP_PAYLOAD_A, VLV_VIDEO_DIP_GDCP_PAYLOAD_B)
>  
> +/* Haswell DIP controls */
> +#define HSW_VIDEO_DIP_CTL_A			0x60200
> +#define HSW_VIDEO_DIP_AVI_DATA_A	0x60220
> +#define HSW_VIDEO_DIP_GCP_A			0x60210
> +
> +#define HSW_VIDEO_DIP_CTL_B			0x61200
> +#define HSW_VIDEO_DIP_AVI_DATA_B	0x61220
> +#define HSW_VIDEO_DIP_GCP_B			0x61210
> +
> +#define HSW_TVIDEO_DIP_CTL(pipe) \
> +	 _PIPE(pipe, HSW_VIDEO_DIP_CTL_A, HSW_VIDEO_DIP_CTL_B)
> +#define HSW_TVIDEO_DIP_AVI_DATA(pipe) \
> +	 _PIPE(pipe, HSW_VIDEO_DIP_AVI_DATA_A, HSW_VIDEO_DIP_AVI_DATA_B)
> +#define HSW_TVIDEO_DIP_GCP(pipe) \
> +	_PIPE(pipe, HSW_VIDEO_DIP_GCP_A, HSW_VIDEO_DIP_GCP_B)
> +
>  #define _TRANS_HTOTAL_B          0xe1000
>  #define _TRANS_HBLANK_B          0xe1004
>  #define _TRANS_HSYNC_B           0xe1008
> -- 
> 1.7.10
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [PATCH 03/29] drm/i915: add Haswell DIP controls registers

[Eugeni Dodonov]

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

On Tue, Apr 17, 2012 at 07:12, Daniel Vetter <daniel@ffwll.ch> wrote:

> On Fri, Apr 13, 2012 at 05:08:39PM -0300, Eugeni Dodonov wrote:
> > Haswell has different DIP control registers and offsets.
> >
> > Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
>
> I've read a bit through Bspec wrt dip writing and it looks like hsw is
> rather differen from previous chips:
> - with have a data reg for every type of dip
> - the bits in the ctl reg moved around completely
>
> ... so I guess this patch and the follow-on one are pretty bogus. One
> thing I've noticed is that intel_infoframe_index and intel_infoframe_flags
> have way too generic names, they're only useful to frob the dip ctl reg on
> pre-hsw afaics. I think we should rename them to i9xx_infoframe_ctl_inde
> and _flags or something similar.
>

Yep, I only did the minimally-required stuff to have HDMI output, so the
ones willing to use Haswell could have anything on their screen besides 'No
Signal' :).

But yes, those patches should receive more care for full hdmi and DIP
support going forward.

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

[-- Attachment #1.2: Type: text/html, Size: 1595 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

[PATCH 04/29] drm/i915: support infoframes on Haswell

[Eugeni Dodonov]

Haswell has different DIP registers which we need to use for infoframes,
so add proper infrastructure to address that.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
---
 drivers/gpu/drm/i915/intel_hdmi.c |   34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
index 7de2d3b..f6a9b83 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -208,6 +208,36 @@ static void vlv_write_infoframe(struct drm_encoder *encoder,
 	I915_WRITE(reg, VIDEO_DIP_ENABLE | val | flags);
 }
 
+static void hsw_write_infoframe(struct drm_encoder *encoder,
+				     struct dip_infoframe *frame)
+{
+	uint32_t *data = (uint32_t *)frame;
+	struct drm_device *dev = encoder->dev;
+	struct drm_i915_private *dev_priv = dev->dev_private;
+	struct drm_crtc *crtc = encoder->crtc;
+	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+	int reg = HSW_TVIDEO_DIP_CTL(intel_crtc->pipe);
+	unsigned i, len = DIP_HEADER_SIZE + frame->len;
+	u32 flags, val = I915_READ(reg);
+
+	intel_wait_for_vblank(dev, intel_crtc->pipe);
+
+	flags = intel_infoframe_index(frame);
+
+	val &= ~(VIDEO_DIP_SELECT_MASK | 0xf); /* clear DIP data offset */
+
+	I915_WRITE(reg, VIDEO_DIP_ENABLE | val | flags);
+
+	for (i = 0; i < len; i += 4) {
+		I915_WRITE(HSW_TVIDEO_DIP_AVI_DATA(intel_crtc->pipe), *data);
+		data++;
+	}
+
+	flags |= intel_infoframe_flags(frame);
+
+	I915_WRITE(reg, VIDEO_DIP_ENABLE | val | flags);
+}
+
 static void intel_set_infoframe(struct drm_encoder *encoder,
 				struct dip_infoframe *frame)
 {
@@ -587,6 +617,10 @@ void intel_hdmi_init(struct drm_device *dev, int sdvox_reg)
 		intel_hdmi->write_infoframe = vlv_write_infoframe;
 		for_each_pipe(i)
 			I915_WRITE(VLV_TVIDEO_DIP_CTL(i), 0);
+	} else if (IS_HASWELL(dev)) {
+		intel_hdmi->write_infoframe = hsw_write_infoframe;
+		for_each_pipe(i)
+			I915_WRITE(HSW_TVIDEO_DIP_CTL(i), 0);
 	}  else {
 		intel_hdmi->write_infoframe = ironlake_write_infoframe;
 		for_each_pipe(i)
-- 
1.7.10

[PATCH 05/29] drm/i915: prevent NULL pointer exception when using gmbus

[Eugeni Dodonov]

Prevent a NULL pointer exception when we are trying to retrieve EDID data
from non-existent adapter.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
---
 drivers/gpu/drm/i915/intel_hdmi.c |   30 +++++++++++++++++++-----------
 1 file changed, 19 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
index f6a9b83..700bd0b 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -389,14 +389,16 @@ intel_hdmi_detect(struct drm_connector *connector, bool force)
 {
 	struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
 	struct drm_i915_private *dev_priv = connector->dev->dev_private;
-	struct edid *edid;
+	struct edid *edid = NULL;
 	enum drm_connector_status status = connector_status_disconnected;
+	struct i2c_adapter *adapter;
 
 	intel_hdmi->has_hdmi_sink = false;
 	intel_hdmi->has_audio = false;
-	edid = drm_get_edid(connector,
-			    intel_gmbus_get_adapter(dev_priv,
-						    intel_hdmi->ddc_bus));
+
+	adapter = intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
+	if (adapter)
+		edid = drm_get_edid(connector, adapter);
 
 	if (edid) {
 		if (edid->input & DRM_EDID_INPUT_DIGITAL) {
@@ -423,14 +425,17 @@ static int intel_hdmi_get_modes(struct drm_connector *connector)
 {
 	struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
 	struct drm_i915_private *dev_priv = connector->dev->dev_private;
+	struct i2c_adapter *adapter;
 
 	/* We should parse the EDID data and find out if it's an HDMI sink so
 	 * we can send audio to it.
 	 */
 
-	return intel_ddc_get_modes(connector,
-				   intel_gmbus_get_adapter(dev_priv,
-							   intel_hdmi->ddc_bus));
+	adapter = intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
+	if (!adapter)
+		return 0;
+
+	return intel_ddc_get_modes(connector, adapter);
 }
 
 static bool
@@ -438,12 +443,15 @@ intel_hdmi_detect_audio(struct drm_connector *connector)
 {
 	struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
 	struct drm_i915_private *dev_priv = connector->dev->dev_private;
-	struct edid *edid;
+	struct edid *edid = NULL;
 	bool has_audio = false;
+	struct i2c_adapter *adapter;
+
+	adapter = intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
+
+	if (adapter)
+		edid = drm_get_edid(connector, adapter);
 
-	edid = drm_get_edid(connector,
-			    intel_gmbus_get_adapter(dev_priv,
-						    intel_hdmi->ddc_bus));
 	if (edid) {
 		if (edid->input & DRM_EDID_INPUT_DIGITAL)
 			has_audio = drm_detect_monitor_audio(edid);
-- 
1.7.10

Re: [PATCH 05/29] drm/i915: prevent NULL pointer exception when using gmbus

[Chris Wilson]

On Fri, 13 Apr 2012 17:08:41 -0300, Eugeni Dodonov <eugeni.dodonov@intel.com> wrote:
> Prevent a NULL pointer exception when we are trying to retrieve EDID data
> from non-existent adapter.

This just means that a HDMI with a garbage ddc_bus is never detected.
Since we control ddc_bus entirely, it means that the initialisation is
completely bogus. Please fix the root cause and not paper over
programming bugs.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH 05/29] drm/i915: prevent NULL pointer exception when using gmbus

[Eugeni Dodonov]

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

On Fri, Apr 13, 2012 at 17:18, Chris Wilson <chris@chris-wilson.co.uk>wrote:

> On Fri, 13 Apr 2012 17:08:41 -0300, Eugeni Dodonov <
> eugeni.dodonov@intel.com> wrote:
> > Prevent a NULL pointer exception when we are trying to retrieve EDID data
> > from non-existent adapter.
>
> This just means that a HDMI with a garbage ddc_bus is never detected.
> Since we control ddc_bus entirely, it means that the initialisation is
> completely bogus. Please fix the root cause and not paper over
> programming bugs.
>

Sorry, I think I wasn't clear in my cover letter about this one.. I am not
hitting any issue with this current branch I sent; but the nature of the
code we have after the gmbus refactoring made me a bit paranoid about
accessing properties of something that could potential be NULL.

As far as I can see, we should not hit this with any combination of outputs
on any hardware that is already covered by the wikipedia :). So I am fine
with dropping this patch if you also think that it does not adds anything
relevant to us. Or perhaps I should refactor it into adding some WARN's
instead?

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

[-- Attachment #1.2: Type: text/html, Size: 1604 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 05/29] drm/i915: prevent NULL pointer exception when using gmbus

[Daniel Vetter]

On Fri, Apr 13, 2012 at 09:26:14PM -0300, Eugeni Dodonov wrote:
> On Fri, Apr 13, 2012 at 17:18, Chris Wilson <chris@chris-wilson.co.uk>wrote:
> 
> > On Fri, 13 Apr 2012 17:08:41 -0300, Eugeni Dodonov <
> > eugeni.dodonov@intel.com> wrote:
> > > Prevent a NULL pointer exception when we are trying to retrieve EDID data
> > > from non-existent adapter.
> >
> > This just means that a HDMI with a garbage ddc_bus is never detected.
> > Since we control ddc_bus entirely, it means that the initialisation is
> > completely bogus. Please fix the root cause and not paper over
> > programming bugs.
> >
> 
> Sorry, I think I wasn't clear in my cover letter about this one.. I am not
> hitting any issue with this current branch I sent; but the nature of the
> code we have after the gmbus refactoring made me a bit paranoid about
> accessing properties of something that could potential be NULL.
> 
> As far as I can see, we should not hit this with any combination of outputs
> on any hardware that is already covered by the wikipedia :). So I am fine
> with dropping this patch if you also think that it does not adds anything
> relevant to us. Or perhaps I should refactor it into adding some WARN's
> instead?

If you're uneasy about a NULL deref add a BUG_ON (because the NULL-deref
will lead to an oops anyway) or add a WARN_ON and try to bail out. But if
the condition is truely (or at least should be) impossible, a BUG_ON to
document it is imo better (if we can't bail out in a sensible way).
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: [PATCH 05/29] drm/i915: prevent NULL pointer exception when using gmbus

[Chris Wilson]

On Sat, 14 Apr 2012 17:58:52 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Fri, Apr 13, 2012 at 09:26:14PM -0300, Eugeni Dodonov wrote:
> > On Fri, Apr 13, 2012 at 17:18, Chris Wilson <chris@chris-wilson.co.uk>wrote:
> > 
> > > On Fri, 13 Apr 2012 17:08:41 -0300, Eugeni Dodonov <
> > > eugeni.dodonov@intel.com> wrote:
> > > > Prevent a NULL pointer exception when we are trying to retrieve EDID data
> > > > from non-existent adapter.
> > >
> > > This just means that a HDMI with a garbage ddc_bus is never detected.
> > > Since we control ddc_bus entirely, it means that the initialisation is
> > > completely bogus. Please fix the root cause and not paper over
> > > programming bugs.
> > >
> > 
> > Sorry, I think I wasn't clear in my cover letter about this one.. I am not
> > hitting any issue with this current branch I sent; but the nature of the
> > code we have after the gmbus refactoring made me a bit paranoid about
> > accessing properties of something that could potential be NULL.
> > 
> > As far as I can see, we should not hit this with any combination of outputs
> > on any hardware that is already covered by the wikipedia :). So I am fine
> > with dropping this patch if you also think that it does not adds anything
> > relevant to us. Or perhaps I should refactor it into adding some WARN's
> > instead?
> 
> If you're uneasy about a NULL deref add a BUG_ON (because the NULL-deref
> will lead to an oops anyway) or add a WARN_ON and try to bail out. But if
> the condition is truely (or at least should be) impossible, a BUG_ON to
> document it is imo better (if we can't bail out in a sensible way).

In this case, the paranoid would add the check during init (and fail to
create the HDMI encoder with a loud DRM_ERROR).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 06/29] drm/i915: add support for SBI ops

[Eugeni Dodonov]

With Lynx Point, we need to use SBI to communicate with the display clock
control. This commit adds helper functions to access the registers via
SBI.

v2: de-inline the function and address changes in bits names

v3: protect operations with dpio_lock, increase timeout to 100 for
paranoia sake.

v1 Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>

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

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 33aaad3..36f6b8e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1300,6 +1300,69 @@ static void intel_disable_pll(struct drm_i915_private *dev_priv, enum pipe pipe)
 	POSTING_READ(reg);
 }
 
+/* SBI access */
+static void
+intel_sbi_write(struct drm_i915_private *dev_priv, u16 reg, u32 value)
+{
+	unsigned long flags;
+
+	spin_lock_irqsave(&dev_priv->dpio_lock, flags);
+	if (wait_for_atomic_us((I915_READ(SBI_CTL_STAT) & SBI_READY) == 0,
+				100)) {
+		DRM_ERROR("timeout waiting for SBI to become ready\n");
+		goto out_unlock;
+	}
+
+	I915_WRITE(SBI_ADDR,
+			(reg << 16));
+	I915_WRITE(SBI_DATA,
+			value);
+	I915_WRITE(SBI_CTL_STAT,
+			SBI_BUSY |
+			SBI_CTL_OP_CRWR);
+
+	if (wait_for_atomic_us((I915_READ(SBI_CTL_STAT) & (SBI_READY | SBI_RESPONSE_SUCCESS)) == 0,
+				100)) {
+		DRM_ERROR("timeout waiting for SBI to complete write transaction\n");
+		goto out_unlock;
+	}
+
+out_unlock:
+	spin_unlock_irqrestore(&dev_priv->dpio_lock, flags);
+}
+
+static u32
+intel_sbi_read(struct drm_i915_private *dev_priv, u16 reg)
+{
+	unsigned long flags;
+	u32 value;
+
+	spin_lock_irqsave(&dev_priv->dpio_lock, flags);
+	if (wait_for_atomic_us((I915_READ(SBI_CTL_STAT) & SBI_READY) == 0,
+				100)) {
+		DRM_ERROR("timeout waiting for SBI to become ready\n");
+		goto out_unlock;
+	}
+
+	I915_WRITE(SBI_ADDR,
+			(reg << 16));
+	I915_WRITE(SBI_CTL_STAT,
+			SBI_BUSY |
+			SBI_CTL_OP_CRRD);
+
+	if (wait_for_atomic_us((I915_READ(SBI_CTL_STAT) & (SBI_READY | SBI_RESPONSE_SUCCESS)) == 0,
+				100)) {
+		DRM_ERROR("timeout waiting for SBI to complete read transaction\n");
+		goto out_unlock;
+	}
+
+	value = I915_READ(SBI_DATA);
+
+out_unlock:
+	spin_unlock_irqrestore(&dev_priv->dpio_lock, flags);
+	return value;
+}
+
 /**
  * intel_enable_pch_pll - enable PCH PLL
  * @dev_priv: i915 private structure
-- 
1.7.10

Re: [PATCH 06/29] drm/i915: add support for SBI ops

[Chris Wilson]

On Fri, 13 Apr 2012 17:08:42 -0300, Eugeni Dodonov <eugeni.dodonov@intel.com> wrote:
> With Lynx Point, we need to use SBI to communicate with the display clock
> control. This commit adds helper functions to access the registers via
> SBI.
> 
> v2: de-inline the function and address changes in bits names
> 
> v3: protect operations with dpio_lock, increase timeout to 100 for
> paranoia sake.
> 
> v1 Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>

Hmm, busy-waits upon a register change. Does it have to be atomic? Can
it really be called in IRQ context? Can I have a sleepy version that
won't cause audible stutters for the normal case? (Admittedly
single-core processors are history...)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH 06/29] drm/i915: add support for SBI ops

[Eugeni Dodonov]

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

On Fri, Apr 13, 2012 at 17:26, Chris Wilson <chris@chris-wilson.co.uk>wrote:

> On Fri, 13 Apr 2012 17:08:42 -0300, Eugeni Dodonov <
> eugeni.dodonov@intel.com> wrote:
> > With Lynx Point, we need to use SBI to communicate with the display clock
> > control. This commit adds helper functions to access the registers via
> > SBI.
> >
> > v2: de-inline the function and address changes in bits names
> >
> > v3: protect operations with dpio_lock, increase timeout to 100 for
> > paranoia sake.
> >
> > v1 Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
>
> Hmm, busy-waits upon a register change. Does it have to be atomic? Can
> it really be called in IRQ context? Can I have a sleepy version that
> won't cause audible stutters for the normal case? (Admittedly
> single-core processors are history...)
>

The original version wasn't atomic and wasn't called in IRQ context, but
Daniel suggested that I should be more paranoid about this so I followed
his idea :).

Anyway, both versions (this one and previous one) work; would both you and
Daniel be happy if I do another version of this keeping the dpio_lock
handling but dropping atomic bits?

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

[-- Attachment #1.2: Type: text/html, Size: 1744 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

[PATCH 07/29] drm/i915: calculate same watermarks on Haswell as on Ivy Bridge

[Eugeni Dodonov]

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

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 36f6b8e..60b1540 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4921,7 +4921,7 @@ void sandybridge_update_wm(struct drm_device *dev)
 	}
 
 	/* IVB has 3 pipes */
-	if (IS_IVYBRIDGE(dev) &&
+	if ((IS_IVYBRIDGE(dev) || IS_HASWELL(dev)) &&
 	    g4x_compute_wm0(dev, 2,
 			    &sandybridge_display_wm_info, latency,
 			    &sandybridge_cursor_wm_info, latency,
-- 
1.7.10

Re: [PATCH 07/29] drm/i915: calculate same watermarks on Haswell as on Ivy Bridge

[Chris Wilson]

On Fri, 13 Apr 2012 17:08:43 -0300, Eugeni Dodonov <eugeni.dodonov@intel.com> wrote:
> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_display.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 36f6b8e..60b1540 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4921,7 +4921,7 @@ void sandybridge_update_wm(struct drm_device *dev)
>  	}
>  
>  	/* IVB has 3 pipes */
> -	if (IS_IVYBRIDGE(dev) &&
> +	if ((IS_IVYBRIDGE(dev) || IS_HASWELL(dev)) &&

Would checking the number of pipes here bere more informative? Otherwise
the comment is stale.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 08/29] drm/i915: share forcewaking code between IVB and HSW

[Eugeni Dodonov]

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
---
 drivers/gpu/drm/i915/intel_display.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 60b1540..3d78686 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9336,7 +9336,7 @@ static void intel_init_display(struct drm_device *dev)
 		dev_priv->display.force_wake_put = __gen6_gt_force_wake_put;
 
 		/* IVB configs may use multi-threaded forcewake */
-		if (IS_IVYBRIDGE(dev)) {
+		if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev)) {
 			u32	ecobus;
 
 			/* A small trick here - if the bios hasn't configured MT forcewake,
-- 
1.7.10

[PATCH 09/29] drm/i915: haswell has 3 pipes as well

[Eugeni Dodonov]

They work differently, but the count is the same.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
---
 drivers/gpu/drm/i915/i915_dma.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 333b746..a813f65 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -2115,7 +2115,7 @@ 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_IVYBRIDGE(dev))
+	if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev))
 		dev_priv->num_pipe = 3;
 	else if (IS_MOBILE(dev) || !IS_GEN2(dev))
 		dev_priv->num_pipe = 2;
-- 
1.7.10

[PATCH 10/29] drm/i915: reuse Ivybridge interrupts code for Haswell

[Eugeni Dodonov]

v2: prevent possible conflicts with VLV.

v1 Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
---
 drivers/gpu/drm/i915/i915_irq.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index febddc2..1ed18db 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1969,7 +1969,7 @@ static void ironlake_irq_preinstall(struct drm_device *dev)
 
 	INIT_WORK(&dev_priv->hotplug_work, i915_hotplug_work_func);
 	INIT_WORK(&dev_priv->error_work, i915_error_work_func);
-	if (IS_GEN6(dev) || IS_IVYBRIDGE(dev))
+	if (IS_GEN6(dev) || IS_IVYBRIDGE(dev) || IS_HASWELL(dev))
 		INIT_WORK(&dev_priv->rps_work, gen6_pm_rps_work);
 
 	I915_WRITE(HWSTAM, 0xeffe);
@@ -2445,7 +2445,7 @@ void intel_irq_init(struct drm_device *dev)
 	dev->driver->get_vblank_counter = i915_get_vblank_counter;
 	dev->max_vblank_count = 0xffffff; /* only 24 bits of frame count */
 	if (IS_G4X(dev) || IS_GEN5(dev) || IS_GEN6(dev) || IS_IVYBRIDGE(dev) ||
-	    IS_VALLEYVIEW(dev)) {
+	    IS_VALLEYVIEW(dev) || IS_HASWELL(dev)) {
 		dev->max_vblank_count = 0xffffffff; /* full 32 bit counter */
 		dev->driver->get_vblank_counter = gm45_get_vblank_counter;
 	}
@@ -2463,7 +2463,7 @@ void intel_irq_init(struct drm_device *dev)
 		dev->driver->irq_uninstall = valleyview_irq_uninstall;
 		dev->driver->enable_vblank = valleyview_enable_vblank;
 		dev->driver->disable_vblank = valleyview_disable_vblank;
-	} else if (IS_IVYBRIDGE(dev)) {
+	} else if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev)) {
 		/* Share pre & uninstall handlers with ILK/SNB */
 		dev->driver->irq_handler = ivybridge_irq_handler;
 		dev->driver->irq_preinstall = ironlake_irq_preinstall;
-- 
1.7.10

Re: [PATCH 10/29] drm/i915: reuse Ivybridge interrupts code for Haswell

[Daniel Vetter]

On Fri, Apr 13, 2012 at 05:08:46PM -0300, Eugeni Dodonov wrote:
> v2: prevent possible conflicts with VLV.
> 
> v1 Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_irq.c |    6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index febddc2..1ed18db 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -1969,7 +1969,7 @@ static void ironlake_irq_preinstall(struct drm_device *dev)
>  
>  	INIT_WORK(&dev_priv->hotplug_work, i915_hotplug_work_func);
>  	INIT_WORK(&dev_priv->error_work, i915_error_work_func);
> -	if (IS_GEN6(dev) || IS_IVYBRIDGE(dev))
> +	if (IS_GEN6(dev) || IS_IVYBRIDGE(dev) || IS_HASWELL(dev))
>  		INIT_WORK(&dev_priv->rps_work, gen6_pm_rps_work);
>  
>  	I915_WRITE(HWSTAM, 0xeffe);
> @@ -2445,7 +2445,7 @@ void intel_irq_init(struct drm_device *dev)
>  	dev->driver->get_vblank_counter = i915_get_vblank_counter;
>  	dev->max_vblank_count = 0xffffff; /* only 24 bits of frame count */
>  	if (IS_G4X(dev) || IS_GEN5(dev) || IS_GEN6(dev) || IS_IVYBRIDGE(dev) ||
> -	    IS_VALLEYVIEW(dev)) {
> +	    IS_VALLEYVIEW(dev) || IS_HASWELL(dev)) {

This one here is growing out of hands. Can you replace it with is_g4x ||
gen >= 5 please? We can throw in stupid exceptions when they actually
arrise.
-Daniel

>  		dev->max_vblank_count = 0xffffffff; /* full 32 bit counter */
>  		dev->driver->get_vblank_counter = gm45_get_vblank_counter;
>  	}
> @@ -2463,7 +2463,7 @@ void intel_irq_init(struct drm_device *dev)
>  		dev->driver->irq_uninstall = valleyview_irq_uninstall;
>  		dev->driver->enable_vblank = valleyview_enable_vblank;
>  		dev->driver->disable_vblank = valleyview_disable_vblank;
> -	} else if (IS_IVYBRIDGE(dev)) {
> +	} else if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev)) {
>  		/* Share pre & uninstall handlers with ILK/SNB */
>  		dev->driver->irq_handler = ivybridge_irq_handler;
>  		dev->driver->irq_preinstall = ironlake_irq_preinstall;
> -- 
> 1.7.10
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[PATCH 11/29] drm/i915: share pipe count handling with Ivybridge

[Eugeni Dodonov]

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
---
 drivers/gpu/drm/i915/intel_display.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 3d78686..5ee652d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2427,7 +2427,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
 	case 1:
 		break;
 	case 2:
-		if (IS_IVYBRIDGE(dev))
+		if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev))
 			break;
 		/* fall through otherwise */
 	default:
-- 
1.7.10

Re: [PATCH 11/29] drm/i915: share pipe count handling with Ivybridge

[Daniel Vetter]

On Fri, Apr 13, 2012 at 05:08:47PM -0300, Eugeni Dodonov wrote:
> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_display.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 3d78686..5ee652d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2427,7 +2427,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
>  	case 1:
>  		break;
>  	case 2:
> -		if (IS_IVYBRIDGE(dev))
> +		if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev))
>  			break;
>  		/* fall through otherwise */
>  	default:

Imo this code is a rather funky way to check for 3 plane support ... I
think we should just replace this entire switch statement with a
if(WARN_ON(intel_crtc->plane > dev_priv->num_pipes)) return -EINVAL;

Or has there been another reason for this? Chris, git blame says you've
originally added this in 5c3b82e2, any comments?
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: [PATCH 11/29] drm/i915: share pipe count handling with Ivybridge

[Chris Wilson]

On Tue, 17 Apr 2012 12:19:16 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Fri, Apr 13, 2012 at 05:08:47PM -0300, Eugeni Dodonov wrote:
> > Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
> > Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_display.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index 3d78686..5ee652d 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2427,7 +2427,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
> >  	case 1:
> >  		break;
> >  	case 2:
> > -		if (IS_IVYBRIDGE(dev))
> > +		if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev))
> >  			break;
> >  		/* fall through otherwise */
> >  	default:
> 
> Imo this code is a rather funky way to check for 3 plane support ... I
> think we should just replace this entire switch statement with a
> if(WARN_ON(intel_crtc->plane > dev_priv->num_pipes)) return -EINVAL;
> 
> Or has there been another reason for this? Chris, git blame says you've
> originally added this in 5c3b82e2, any comments?

Yup, it's just a userspace (and internal consistency) validation check, so
if (pipe >= dev_priv->num_pipes) return -EINVAL; would have sufficed.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH 11/29] drm/i915: share pipe count handling with Ivybridge

[Daniel Vetter]

On Tue, Apr 17, 2012 at 11:36:33AM +0100, Chris Wilson wrote:
> On Tue, 17 Apr 2012 12:19:16 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Fri, Apr 13, 2012 at 05:08:47PM -0300, Eugeni Dodonov wrote:
> > > Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
> > > Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c |    2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > > index 3d78686..5ee652d 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -2427,7 +2427,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
> > >  	case 1:
> > >  		break;
> > >  	case 2:
> > > -		if (IS_IVYBRIDGE(dev))
> > > +		if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev))
> > >  			break;
> > >  		/* fall through otherwise */
> > >  	default:
> > 
> > Imo this code is a rather funky way to check for 3 plane support ... I
> > think we should just replace this entire switch statement with a
> > if(WARN_ON(intel_crtc->plane > dev_priv->num_pipes)) return -EINVAL;
> > 
> > Or has there been another reason for this? Chris, git blame says you've
> > originally added this in 5c3b82e2, any comments?
> 
> Yup, it's just a userspace (and internal consistency) validation check, so
> if (pipe >= dev_priv->num_pipes) return -EINVAL; would have sufficed.

Hm, how can userspace trigger this? It can only pass in crtc ids, which
the drm core validates. intel_crtc->plane is completely in our control,
hence why I think this can only be a driver bug. Or do I miss something?
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

Re: [PATCH 11/29] drm/i915: share pipe count handling with Ivybridge

[Chris Wilson]

On Tue, 17 Apr 2012 13:26:19 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Apr 17, 2012 at 11:36:33AM +0100, Chris Wilson wrote:
> > On Tue, 17 Apr 2012 12:19:16 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> > > On Fri, Apr 13, 2012 at 05:08:47PM -0300, Eugeni Dodonov wrote:
> > > > Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
> > > > Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_display.c |    2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > > > index 3d78686..5ee652d 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -2427,7 +2427,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
> > > >  	case 1:
> > > >  		break;
> > > >  	case 2:
> > > > -		if (IS_IVYBRIDGE(dev))
> > > > +		if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev))
> > > >  			break;
> > > >  		/* fall through otherwise */
> > > >  	default:
> > > 
> > > Imo this code is a rather funky way to check for 3 plane support ... I
> > > think we should just replace this entire switch statement with a
> > > if(WARN_ON(intel_crtc->plane > dev_priv->num_pipes)) return -EINVAL;
> > > 
> > > Or has there been another reason for this? Chris, git blame says you've
> > > originally added this in 5c3b82e2, any comments?
> > 
> > Yup, it's just a userspace (and internal consistency) validation check, so
> > if (pipe >= dev_priv->num_pipes) return -EINVAL; would have sufficed.
> 
> Hm, how can userspace trigger this? It can only pass in crtc ids, which
> the drm core validates. intel_crtc->plane is completely in our control,
> hence why I think this can only be a driver bug. Or do I miss something?

Shooting the messanger here. :-p

Right, userspace cannot assign pipes, that is purely an internal detail.
So this can be promoted to a if (WARN(pipe >= num_pipes)) return -EINVAL;
or killed outright.

All I did in that commit was perform the existing consistency check
upfront, and return -EINVAL alongside the DRM_ERROR.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[PATCH 12/29] drm/i915: share IVB cursor routine with Haswell

[Eugeni Dodonov]

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
---
 drivers/gpu/drm/i915/intel_display.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 5ee652d..33ff60e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6807,7 +6807,7 @@ static void intel_crtc_update_cursor(struct drm_crtc *crtc,
 	if (!visible && !intel_crtc->cursor_visible)
 		return;
 
-	if (IS_IVYBRIDGE(dev)) {
+	if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev)) {
 		I915_WRITE(CURPOS_IVB(pipe), pos);
 		ivb_update_cursor(crtc, base);
 	} else {
-- 
1.7.10

[PATCH 13/29] drm/i915: show unknown sdvox registers on hdmi init

[Eugeni Dodonov]

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

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
index 700bd0b..0978fb7 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -614,6 +614,8 @@ void intel_hdmi_init(struct drm_device *dev, int sdvox_reg)
 		intel_encoder->clone_mask = (1 << INTEL_HDMIF_CLONE_BIT);
 		intel_hdmi->ddc_bus = GMBUS_PORT_DPD;
 		dev_priv->hotplug_supported_mask |= HDMID_HOTPLUG_INT_STATUS;
+	} else {
+		DRM_DEBUG_DRIVER("Unknown sdvox register %x\n", sdvox_reg);
 	}
 
 	intel_hdmi->sdvox_reg = sdvox_reg;
-- 
1.7.10

Re: [PATCH 13/29] drm/i915: show unknown sdvox registers on hdmi init

[Daniel Vetter]

On Fri, Apr 13, 2012 at 05:08:49PM -0300, Eugeni Dodonov wrote:
> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>

This is pretty much a implementation bug, and with the new DDI split I'm
not too sure we'll need this. I'm ingoring this for now ;-)
-Daniel
> ---
>  drivers/gpu/drm/i915/intel_hdmi.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
> index 700bd0b..0978fb7 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -614,6 +614,8 @@ void intel_hdmi_init(struct drm_device *dev, int sdvox_reg)
>  		intel_encoder->clone_mask = (1 << INTEL_HDMIF_CLONE_BIT);
>  		intel_hdmi->ddc_bus = GMBUS_PORT_DPD;
>  		dev_priv->hotplug_supported_mask |= HDMID_HOTPLUG_INT_STATUS;
> +	} else {
> +		DRM_DEBUG_DRIVER("Unknown sdvox register %x\n", sdvox_reg);
>  	}
>  
>  	intel_hdmi->sdvox_reg = sdvox_reg;
> -- 
> 1.7.10
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[PATCH 14/29] drm/i915: do not use fdi_normal_train on haswell

[Eugeni Dodonov]

This should be already configured when FDI auto-negotiation is done.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
---
 drivers/gpu/drm/i915/intel_display.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 33ff60e..0768f48 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3159,7 +3159,8 @@ static void ironlake_pch_enable(struct drm_crtc *crtc)
 	I915_WRITE(TRANS_VSYNC(pipe),  I915_READ(VSYNC(pipe)));
 	I915_WRITE(TRANS_VSYNCSHIFT(pipe),  I915_READ(VSYNCSHIFT(pipe)));
 
-	intel_fdi_normal_train(crtc);
+	if (!IS_HASWELL(dev))
+		intel_fdi_normal_train(crtc);
 
 	/* For PCH DP, enable TRANS_DP_CTL */
 	if (HAS_PCH_CPT(dev) &&
-- 
1.7.10

[PATCH 15/29] drm/i915: do not enable PCH PLL on pre-haswell

[Eugeni Dodonov]

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

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 0768f48..e4ebd39 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1437,8 +1437,9 @@ static void intel_enable_transcoder(struct drm_i915_private *dev_priv,
 	/* PCH only available on ILK+ */
 	BUG_ON(dev_priv->info->gen < 5);
 
-	/* Make sure PCH DPLL is enabled */
-	assert_pch_pll_enabled(dev_priv, pipe);
+	/* Make sure PCH DPLL is enabled on Pre-Haswell platforms */
+	if (!IS_HASWELL(dev_priv->dev))
+		assert_pch_pll_enabled(dev_priv, pipe);
 
 	/* FDI must be feeding us bits for PCH ports */
 	assert_fdi_tx_enabled(dev_priv, pipe);
-- 
1.7.10

Re: [PATCH 15/29] drm/i915: do not enable PCH PLL on pre-haswell

[Chris Wilson]

The PLL split needs to be reconsidered in light of Jesse's decoupling
PLLs from the pipes.

I think we want to start annotating those so that we can keep track of
CPU vs PCH DP/FDI links and plls.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH 15/29] drm/i915: do not enable PCH PLL on pre-haswell

[Eugeni Dodonov]

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

On Fri, Apr 13, 2012 at 17:55, Chris Wilson <chris@chris-wilson.co.uk>wrote:

> The PLL split needs to be reconsidered in light of Jesse's decoupling
> PLLs from the pipes.
>
> I think we want to start annotating those so that we can keep track of
> CPU vs PCH DP/FDI links and plls.
>

Yes, I'll wait for the PLL patches to land and will refactor this
accordingly. I just didn't wanted to have it blocking my entire series here.

With HSW, on PCH, we only have 1 PLL (iCLKIP), the other ones are on the
CPU.

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

[-- Attachment #1.2: Type: text/html, Size: 916 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 15/29] drm/i915: do not enable PCH PLL on pre-haswell

[Daniel Vetter]

On Fri, Apr 13, 2012 at 05:08:51PM -0300, Eugeni Dodonov wrote:
> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_display.c |    5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 0768f48..e4ebd39 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1437,8 +1437,9 @@ static void intel_enable_transcoder(struct drm_i915_private *dev_priv,
>  	/* PCH only available on ILK+ */
>  	BUG_ON(dev_priv->info->gen < 5);
>  
> -	/* Make sure PCH DPLL is enabled */
> -	assert_pch_pll_enabled(dev_priv, pipe);
> +	/* Make sure PCH DPLL is enabled on Pre-Haswell platforms */
> +	if (!IS_HASWELL(dev_priv->dev))
> +		assert_pch_pll_enabled(dev_priv, pipe);

If I read the code correctly, you can drop this one with the follow-up
patch to correctly detect which ports are driven through the pch in
intel_crtc_driving_pch. I'm having a feeling there are other places where
we should exploit this and could drop an IS_HSW check, but I'm too tired
to check right now ;-)
-Daniel

>  
>  	/* FDI must be feeding us bits for PCH ports */
>  	assert_fdi_tx_enabled(dev_priv, pipe);
> -- 
> 1.7.10
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[PATCH 16/29] drm/i915: detect PCH encoders on Haswell

[Eugeni Dodonov]

On Haswell, the only PCH-connected output is the one driven by DDI E in
FDI mode, used for VGA connection. All the others are handled by the CPU.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index e4ebd39..b01afb0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3098,6 +3098,13 @@ static bool intel_crtc_driving_pch(struct drm_crtc *crtc)
 		if (encoder->base.crtc != crtc)
 			continue;
 
+		/* On Haswell, only DDI E can connect to PCH through FDI to drive VGA */
+		if (IS_HASWELL(dev) && (encoder->type != DRM_MODE_ENCODER_DAC)) {
+			DRM_DEBUG_KMS("Non-PCH encoder detected on Haswell. Allowed: %d, detected: %d\n",
+					DRM_MODE_ENCODER_DAC, encoder->type);
+			return false;
+		}
+
 		switch (encoder->type) {
 		case INTEL_OUTPUT_EDP:
 			if (!intel_encoder_is_pch_edp(&encoder->base))
-- 
1.7.10

Re: [PATCH 16/29] drm/i915: detect PCH encoders on Haswell

[Daniel Vetter]

On Fri, Apr 13, 2012 at 05:08:52PM -0300, Eugeni Dodonov wrote:
> On Haswell, the only PCH-connected output is the one driven by DDI E in
> FDI mode, used for VGA connection. All the others are handled by the CPU.
> 
> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
> ---
>  drivers/gpu/drm/i915/intel_display.c |    7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index e4ebd39..b01afb0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3098,6 +3098,13 @@ static bool intel_crtc_driving_pch(struct drm_crtc *crtc)
>  		if (encoder->base.crtc != crtc)
>  			continue;
>  
> +		/* On Haswell, only DDI E can connect to PCH through FDI to drive VGA */
> +		if (IS_HASWELL(dev) && (encoder->type != DRM_MODE_ENCODER_DAC)) {
> +			DRM_DEBUG_KMS("Non-PCH encoder detected on Haswell. Allowed: %d, detected: %d\n",
> +					DRM_MODE_ENCODER_DAC, encoder->type);
> +			return false;
> +		}

Shouldn't we use a PCH_LTP check here, given that it looks like hsd can
be combined with ppt? Or is it really only DDI E that can be used for
fdi and hsw+ppt would only be able to drive 1 pch output?
-Daniel

> +
>  		switch (encoder->type) {
>  		case INTEL_OUTPUT_EDP:
>  			if (!intel_encoder_is_pch_edp(&encoder->base))
> -- 
> 1.7.10
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[PATCH 17/29] drm/i915: enable power wells on haswell init

[Eugeni Dodonov]

This attempts to enable all the available power wells during the
initialization.

Those power wells can be enabled in parallel or on-demand, and disabled
when no longer needed, but this is out of scope of this initial
enablement. Proper tracking of who uses which power well will require
a considerable rework of our display handling, so we just leave them all
enabled when the driver is loaded for now.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index b01afb0..cc2be0b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9635,6 +9635,34 @@ void intel_modeset_init_hw(struct drm_device *dev)
 		ivb_pch_pwm_override(dev);
 }
 
+/* Starting with Haswell, we have different power wells for
+ * different parts of the GPU. This attempts to enable them all.
+ */
+static void intel_init_power_wells(struct drm_device *dev)
+{
+	struct drm_i915_private *dev_priv = dev->dev_private;
+	unsigned long power_wells[] = {
+		HSW_PWR_WELL_CTL1,
+		HSW_PWR_WELL_CTL2,
+		HSW_PWR_WELL_CTL4
+	};
+	int i;
+
+	mutex_lock(&dev->struct_mutex);
+
+	for (i = 0; i < ARRAY_SIZE(power_wells); i++) {
+		int well = I915_READ(power_wells[i]);
+
+		if ((well & HSW_PWR_WELL_STATE) == 0) {
+			I915_WRITE(power_wells[i], well & HSW_PWR_WELL_ENABLE);
+			if (wait_for(I915_READ(power_wells[i] & HSW_PWR_WELL_STATE), 20))
+				DRM_ERROR("Error enabling power well %lx\n", power_wells[i]);
+		}
+	}
+
+	mutex_unlock(&dev->struct_mutex);
+}
+
 void intel_modeset_init(struct drm_device *dev)
 {
 	struct drm_i915_private *dev_priv = dev->dev_private;
@@ -9652,6 +9680,9 @@ void intel_modeset_init(struct drm_device *dev)
 
 	intel_init_quirks(dev);
 
+	if (IS_HASWELL(dev))
+		intel_init_power_wells(dev);
+
 	intel_init_display(dev);
 
 	if (IS_GEN2(dev)) {
-- 
1.7.10

Re: [PATCH 17/29] drm/i915: enable power wells on haswell init

[Chris Wilson]

On Fri, 13 Apr 2012 17:08:53 -0300, Eugeni Dodonov <eugeni.dodonov@intel.com> wrote:
>  void intel_modeset_init(struct drm_device *dev)
>  {
>  	struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -9652,6 +9680,9 @@ void intel_modeset_init(struct drm_device *dev)
>  
>  	intel_init_quirks(dev);
>  
> +	if (IS_HASWELL(dev))
> +		intel_init_power_wells(dev);
> +

Perform the gen checks in intel_init_power_wells() so that we keep the
initialisation sequence readable.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH 17/29] drm/i915: enable power wells on haswell init

[Eugeni Dodonov]

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

On Fri, Apr 13, 2012 at 18:03, Chris Wilson <chris@chris-wilson.co.uk>wrote:

> On Fri, 13 Apr 2012 17:08:53 -0300, Eugeni Dodonov <
> eugeni.dodonov@intel.com> wrote:
> >  void intel_modeset_init(struct drm_device *dev)
> >  {
> >       struct drm_i915_private *dev_priv = dev->dev_private;
> > @@ -9652,6 +9680,9 @@ void intel_modeset_init(struct drm_device *dev)
> >
> >       intel_init_quirks(dev);
> >
> > +     if (IS_HASWELL(dev))
> > +             intel_init_power_wells(dev);
> > +
>
> Perform the gen checks in intel_init_power_wells() so that we keep the
> initialisation sequence readable.
>

Yes, makes total sense, I'll do this.

Thanks!

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

[-- Attachment #1.2: Type: text/html, Size: 1183 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

[PATCH 18/29] drm/i915: disable rc6 on haswell for now

[Eugeni Dodonov]

This needs proper enablement to avoid machine hangs, so let's just avoid
it for now.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
---
 drivers/gpu/drm/i915/intel_display.c |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index cc2be0b..448f8d7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8631,6 +8631,10 @@ int intel_enable_rc6(const struct drm_device *dev)
 	if (INTEL_INFO(dev)->gen == 5)
 		return 0;
 
+	/* Sorry Haswell, no RC6 for you for now. */
+	if (IS_HASWELL(dev))
+		return 0;
+
 	/*
 	 * Disable rc6 on Sandybridge
 	 */
-- 
1.7.10

[PATCH 19/29] drm/i915: program WM_LINETIME on Haswell

[Eugeni Dodonov]

The line time can be programmed according to the number of horizontal
pixels vs effective pixel rate ratio.

v2: improve comment as per Chris Wilson suggestion

v3: incorporate latest changes in specs.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 448f8d7..712bbaa 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6436,6 +6436,19 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
 		   (adjusted_mode->crtc_vsync_start - 1) |
 		   ((adjusted_mode->crtc_vsync_end - 1) << 16));
 
+	if (IS_HASWELL(dev)) {
+		temp = I915_READ(PIPE_WM_LINETIME(pipe));
+		temp &= ~PIPE_WM_LINETIME_MASK;
+
+		/* The WM are computed with base on how long it takes to fill a single
+		 * row at the given clock rate, multiplied by 8.
+		 * */
+		temp |= PIPE_WM_LINETIME_TIME(
+			((adjusted_mode->crtc_hdisplay * 1000) / adjusted_mode->clock) * 8);
+
+		I915_WRITE(PIPE_WM_LINETIME(pipe), temp);
+	}
+
 	/* pipesrc controls the size that is scaled from, which should
 	 * always be the user's requested size.
 	 */
-- 
1.7.10

[PATCH 20/29] drm/i915: do not use old code paths on Haswell

[Eugeni Dodonov]

Haswell has a different way of accessing pipes and PCH-specific registers,
so avoid using legacy registers on it.

This patch will probably be reworked into a series of smaller patches once
the required plumbing lands and we won't hit those assertions anymore.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 712bbaa..a1598a5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -949,9 +949,16 @@ static void assert_fdi_tx(struct drm_i915_private *dev_priv,
 	u32 val;
 	bool cur_state;
 
-	reg = FDI_TX_CTL(pipe);
-	val = I915_READ(reg);
-	cur_state = !!(val & FDI_TX_ENABLE);
+	if (IS_HASWELL(dev_priv->dev)) {
+		DRM_ERROR("Attempting to check FDI_TX_CTL on Haswell, using DDI instead\n");
+		reg = DDI_FUNC_CTL(pipe);
+		val = I915_READ(reg);
+		cur_state = !!(val & PIPE_DDI_FUNC_ENABLE);
+	} else {
+		reg = FDI_TX_CTL(pipe);
+		val = I915_READ(reg);
+		cur_state = !!(val & FDI_TX_ENABLE);
+	}
 	WARN(cur_state != state,
 	     "FDI TX state assertion failure (expected %s, current %s)\n",
 	     state_string(state), state_string(cur_state));
@@ -966,9 +973,14 @@ static void assert_fdi_rx(struct drm_i915_private *dev_priv,
 	u32 val;
 	bool cur_state;
 
-	reg = FDI_RX_CTL(pipe);
-	val = I915_READ(reg);
-	cur_state = !!(val & FDI_RX_ENABLE);
+	if (IS_HASWELL(dev_priv->dev) && pipe > 0) {
+			DRM_ERROR("Attempting to enable FDI_RX on Haswell pipe > 0\n");
+			return;
+	} else {
+		reg = FDI_RX_CTL(pipe);
+		val = I915_READ(reg);
+		cur_state = !!(val & FDI_RX_ENABLE);
+	}
 	WARN(cur_state != state,
 	     "FDI RX state assertion failure (expected %s, current %s)\n",
 	     state_string(state), state_string(cur_state));
@@ -986,6 +998,11 @@ static void assert_fdi_tx_pll_enabled(struct drm_i915_private *dev_priv,
 	if (dev_priv->info->gen == 5)
 		return;
 
+	if (IS_HASWELL(dev_priv->dev)) {
+		DRM_ERROR("Attempting to check FDI_TX_PLL on Haswell, aborting\n");
+		return;
+	}
+
 	reg = FDI_TX_CTL(pipe);
 	val = I915_READ(reg);
 	WARN(!(val & FDI_TX_PLL_ENABLE), "FDI TX PLL assertion failure, should be active but is disabled\n");
@@ -997,6 +1014,10 @@ static void assert_fdi_rx_pll_enabled(struct drm_i915_private *dev_priv,
 	int reg;
 	u32 val;
 
+	if (IS_HASWELL(dev_priv->dev) && pipe > 0) {
+		DRM_ERROR("Attempting to enable FDI on Haswell with pipe > 0\n");
+		return;
+	}
 	reg = FDI_RX_CTL(pipe);
 	val = I915_READ(reg);
 	WARN(!(val & FDI_RX_PLL_ENABLE), "FDI RX PLL assertion failure, should be active but is disabled\n");
@@ -1102,6 +1123,11 @@ static void assert_pch_refclk_enabled(struct drm_i915_private *dev_priv)
 	u32 val;
 	bool enabled;
 
+	if (HAS_PCH_LPT(dev_priv->dev)) {
+		DRM_ERROR("LPT does not has PCH refclk, skipping check\n");
+		return;
+	}
+
 	val = I915_READ(PCH_DREF_CONTROL);
 	enabled = !!(val & (DREF_SSC_SOURCE_MASK | DREF_NONSPREAD_SOURCE_MASK |
 			    DREF_SUPERSPREAD_SOURCE_MASK));
@@ -1445,6 +1471,10 @@ static void intel_enable_transcoder(struct drm_i915_private *dev_priv,
 	assert_fdi_tx_enabled(dev_priv, pipe);
 	assert_fdi_rx_enabled(dev_priv, pipe);
 
+	if (IS_HASWELL(dev_priv->dev) && pipe > 0) {
+		DRM_ERROR("Attempting to enable transcoder on Haswell with pipe > 0\n");
+		return;
+	}
 	reg = TRANSCONF(pipe);
 	val = I915_READ(reg);
 	pipeconf_val = I915_READ(PIPECONF(pipe));
@@ -2971,13 +3001,18 @@ static void ironlake_fdi_pll_enable(struct drm_crtc *crtc)
 	udelay(200);
 
 	/* Enable CPU FDI TX PLL, always on for Ironlake */
-	reg = FDI_TX_CTL(pipe);
-	temp = I915_READ(reg);
-	if ((temp & FDI_TX_PLL_ENABLE) == 0) {
-		I915_WRITE(reg, temp | FDI_TX_PLL_ENABLE);
+	if (IS_HASWELL(dev)) {
+		DRM_ERROR("Skipping enablement of FDI_TX_PLL on Haswell\n");
+		return;
+	} else {
+		reg = FDI_TX_CTL(pipe);
+		temp = I915_READ(reg);
+		if ((temp & FDI_TX_PLL_ENABLE) == 0) {
+			I915_WRITE(reg, temp | FDI_TX_PLL_ENABLE);
 
-		POSTING_READ(reg);
-		udelay(100);
+			POSTING_READ(reg);
+			udelay(100);
+		}
 	}
 }
 
-- 
1.7.10

[PATCH 21/29] drm/i915: initialize DDI buffer translations

[Eugeni Dodonov]

Buffer translations for DDI links must be initialized prior to enablement.
For FDI and DP, first 9 pairs of values are used to select the connection
parameters. HDMI uses the last pair of values and ignores the first 9
pairs. So we program HDMI values in both cases, which allows HDMI to work
over both FDI and DP-friendly buffers.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index a1598a5..e7a2a81 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2856,6 +2856,86 @@ static void gen6_fdi_link_train(struct drm_crtc *crtc)
 	DRM_DEBUG_KMS("FDI train done.\n");
 }
 
+/* HDMI/DVI modes ignore everything but the last 2 items. So we share
+ * them for both DP and FDI transports, allowing those ports to
+ * automatically adapt to HDMI connections as well
+ */
+static const long hsw_ddi_translations_dp[] = {
+	0x00FFFFFF, 0x0006000E,
+	0x00D75FFF, 0x0005000A,
+	0x00C30FFF, 0x00040006,
+	0x80AAAFFF, 0x000B0000,
+	0x00FFFFFF, 0x0005000A,
+	0x00D75FFF, 0x000C0004,
+	0x80C30FFF, 0x000B0000,
+	0x00FFFFFF, 0x00040006,
+	0x80D75FFF, 0x000B0000,
+	0x00FFFFFF, 0x00040006
+};
+
+static const long hsw_ddi_translations_fdi[] = {
+	0x00FFFFFF, 0x0007000E,
+	0x00D75FFF, 0x000F000A,
+	0x00C30FFF, 0x00060006,
+	0x00AAAFFF, 0x001E0000,
+	0x00FFFFFF, 0x000F000A,
+	0x00D75FFF, 0x00160004,
+	0x00C30FFF, 0x001E0000,
+	0x00FFFFFF, 0x00060006,
+	0x00D75FFF, 0x001E0000,
+	0x00FFFFFF, 0x00040006
+};
+
+/* On Haswell, DDI port buffers must be programmed with correct values
+ * in advance. The buffer values are different for FDI and DP modes,
+ * but the HDMI/DVI fields are shared among those. So we program the DDI
+ * in either FDI or DP modes only, as HDMI connections will work with both
+ * of those
+ */
+void hsw_prepare_ddi_buffers(struct drm_device *dev, enum port port, bool use_fdi_mode)
+{
+	struct drm_i915_private *dev_priv = dev->dev_private;
+	u32 reg;
+	int i, j;
+
+	DRM_DEBUG_DRIVER("Initializing DDI buffers for port %c in %s mode\n",
+			port_name(port),
+			use_fdi_mode ? "FDI" : "DP");
+
+	WARN((use_fdi_mode && (port != PORT_E)),
+		"Programming port %c in FDI mode, this probably will not work.\n",
+		port_name(port));
+
+	/* Those registers seem to be double-buffered, so write them twice */
+	for (j=0; j < 2; j++) {
+		for (i=0, reg=DDI_BUF_TRANS(port); i < ARRAY_SIZE(hsw_ddi_translations_fdi); i++) {
+			I915_WRITE(reg,
+					(use_fdi_mode) ?
+						hsw_ddi_translations_fdi[i] :
+						hsw_ddi_translations_dp[i]);
+			reg += 4;
+		}
+		udelay(20);
+	}
+}
+
+/* Program DDI buffers translations for DP. By default, program ports A-D in DP
+ * mode and port E for FDI.
+ */
+static void intel_hsw_prepare_ddi_buffers(struct drm_device *dev)
+{
+	int port;
+
+	for (port = PORT_A; port < PORT_E; port++)
+		hsw_prepare_ddi_buffers(dev, port, false);
+
+	/* DDI E is the suggested one to work in FDI mode, so program is as such by
+	 * default. It will have to be re-programmed in case a digital DP output
+	 * will be detected on it
+	 */
+	hsw_prepare_ddi_buffers(dev, PORT_E, true);
+}
+
 /* Manual link training for Ivy Bridge A0 parts */
 static void ivb_manual_fdi_link_train(struct drm_crtc *crtc)
 {
@@ -9732,8 +9812,10 @@ void intel_modeset_init(struct drm_device *dev)
 
 	intel_init_quirks(dev);
 
-	if (IS_HASWELL(dev))
+	if (IS_HASWELL(dev)) {
 		intel_init_power_wells(dev);
+		intel_hsw_prepare_ddi_buffers(dev);
+	}
 
 	intel_init_display(dev);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 79cabf5..6862ed3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -420,6 +420,7 @@ extern void intel_init_clock_gating(struct drm_device *dev);
 extern void intel_write_eld(struct drm_encoder *encoder,
 			    struct drm_display_mode *mode);
 extern void intel_cpt_verify_modeset(struct drm_device *dev, int pipe);
+extern void hsw_prepare_ddi_buffers(struct drm_device *dev, enum port port, bool use_fdi_mode);
 
 /* For use by IVB LP watermark workaround in intel_sprite.c */
 extern void sandybridge_update_wm(struct drm_device *dev);
-- 
1.7.10

Re: [PATCH 21/29] drm/i915: initialize DDI buffer translations

[Chris Wilson]

On Fri, 13 Apr 2012 17:08:57 -0300, Eugeni Dodonov <eugeni.dodonov@intel.com> wrote:
> +	/* Those registers seem to be double-buffered, so write them twice */
> +	for (j=0; j < 2; j++) {
> +		for (i=0, reg=DDI_BUF_TRANS(port); i < ARRAY_SIZE(hsw_ddi_translations_fdi); i++) {
> +			I915_WRITE(reg,
> +					(use_fdi_mode) ?
> +						hsw_ddi_translations_fdi[i] :
> +						hsw_ddi_translations_dp[i]);

If you use a temporary variable for the translation table ptr (and moved
it out of the loop), these writes would fit into 80 columns and be much
more readable.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH 21/29] drm/i915: initialize DDI buffer translations

[Chris Wilson]

On Fri, 13 Apr 2012 17:08:57 -0300, Eugeni Dodonov <eugeni.dodonov@intel.com> wrote:
> -	if (IS_HASWELL(dev))
> +	if (IS_HASWELL(dev)) {
>  		intel_init_power_wells(dev);
> +		intel_hsw_prepare_ddi_buffers(dev);
Give this a much more generic, more grandiose name and move the
generation specific routines down a level:
  intel_init_ddi() [but make it more verbose and self-documenting!]

When you do that you'll might consider it to actually a part of the
display initialisation and so move it down below intel_init_display().
Remember it is vital for our sanity that we be able to concisely describe
the sequence of steps required to initialise the GPU.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH 21/29] drm/i915: initialize DDI buffer translations

[Eugeni Dodonov]

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

On Fri, Apr 13, 2012 at 18:11, Chris Wilson <chris@chris-wilson.co.uk>wrote:

> On Fri, 13 Apr 2012 17:08:57 -0300, Eugeni Dodonov <
> eugeni.dodonov@intel.com> wrote:
> > -     if (IS_HASWELL(dev))
> > +     if (IS_HASWELL(dev)) {
> >               intel_init_power_wells(dev);
> > +             intel_hsw_prepare_ddi_buffers(dev);
> Give this a much more generic, more grandiose name and move the
> generation specific routines down a level:
>  intel_init_ddi() [but make it more verbose and self-documenting!]
>

Will do.


> When you do that you'll might consider it to actually a part of the
> display initialisation and so move it down below intel_init_display().
> Remember it is vital for our sanity that we be able to concisely describe
> the sequence of steps required to initialise the GPU.
>

My initial idea here was to re-use the IS_HASWELL check to do all the
platform-specific stuff in one place, but with the suggestion above it
makes it much easier to move the intel_ddi_init into more logical position.

The specs ask to make sure that the DDI buffers translations are configured
correctly before attempting to enable them, so I thought on doing them
early in the process, so the further step assume that everything is up and
ready to use already. But yes, I believe that it could be done from within
intel_init_display as well, and it will be more logical indeed.

In both cases, I agree that it will make the driver code much more
self-explainable and easier to maintain. Huge thanks! I'll send a new
version with those comments addressed later.

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

[-- Attachment #1.2: Type: text/html, Size: 2277 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

[PATCH 22/29] drm/i915: perform Haswell DDI link training in FDI mode

[Eugeni Dodonov]

This patch attempts at following the modeset sequence closely, retrying
with different voltages if the DP_TP_STATUS reports a failed training.

For training, we add a table of recommended settings for FDI, HDMI and DP
connections. For FDI and DP modes, we also add the HDMI buffer
translation as the last item. Those are ignored in such modes, so there is
no harm in having them set.

Initially, we use DDI E for FDI connectivity.  This is the suggested
configuration, and this seems to be what should work the best with FDI.

Note that we leave the DDI Function for corresponding pipe active when we
are done with the training. This ensures that we only need to enable pipe
afterwards to get a working modesetting, in a similar fashion as on
pre-HSW hardware. The modeset disabling sequence mentions a correct order
of disabling things, but this is out of scope of this patch and is being
done separately, for clearer distinction of what happens when.

v2: improve comments a bit, use PORT enums instead of hardcoded PORT_E
registers, split DDI buffers programming into a separate patch.

v1 Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
---
 drivers/gpu/drm/i915/intel_display.c |  118 ++++++++++++++++++++++++++++++++++
 1 file changed, 118 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index e7a2a81..dcfe143 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2936,6 +2936,113 @@ static void intel_hsw_prepare_ddi_buffers(struct drm_device *dev)
 	hsw_prepare_ddi_buffers(dev, PORT_E, true);
 }
 
+static const long hsw_ddi_buf_ctl_values[] = {
+	DDI_BUF_EMP_400MV_0DB_HSW,
+	DDI_BUF_EMP_400MV_3_5DB_HSW,
+	DDI_BUF_EMP_400MV_6DB_HSW,
+	DDI_BUF_EMP_400MV_9_5DB_HSW,
+	DDI_BUF_EMP_600MV_0DB_HSW,
+	DDI_BUF_EMP_600MV_3_5DB_HSW,
+	DDI_BUF_EMP_600MV_6DB_HSW,
+	DDI_BUF_EMP_800MV_0DB_HSW,
+	DDI_BUF_EMP_800MV_3_5DB_HSW
+};
+
+
+/* Link training for HSW parts */
+static void hsw_fdi_link_train(struct drm_crtc *crtc)
+{
+	struct drm_device *dev = crtc->dev;
+	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, i;
+
+	/* Configure CPU PLL, wait for warmup */
+	I915_WRITE(SPLL_CTL,
+			SPLL_PLL_ENABLE |
+			SPLL_PLL_FREQ_1350MHz |
+			SPLL_PLL_SCC);
+
+	/* Use SPLL to drive the output when in FDI mode */
+	I915_WRITE(PORT_CLK_SEL(PORT_E),
+			PORT_CLK_SEL_SPLL);
+	I915_WRITE(PIPE_CLK_SEL(pipe),
+			PIPE_CLK_SEL_PORT(PORT_E));
+
+	udelay(20);
+
+	/* Start the training iterating through available voltages and emphasis */
+	for (i=0; i < ARRAY_SIZE(hsw_ddi_buf_ctl_values); i++) {
+		/* Configure DP_TP_CTL with auto-training */
+		I915_WRITE(DP_TP_CTL(PORT_E),
+					DP_TP_CTL_FDI_AUTOTRAIN |
+					DP_TP_CTL_ENHANCED_FRAME_ENABLE |
+					DP_TP_CTL_LINK_TRAIN_PAT1 |
+					DP_TP_CTL_ENABLE);
+
+		/* Configure and enable DDI_BUF_CTL for DDI E with next voltage */
+		temp = I915_READ(DDI_BUF_CTL(PORT_E));
+		temp = (temp & ~DDI_BUF_EMP_MASK);
+		I915_WRITE(DDI_BUF_CTL(PORT_E),
+				temp |
+				DDI_BUF_CTL_ENABLE |
+				DDI_PORT_WIDTH_X2 |
+				hsw_ddi_buf_ctl_values[i]);
+
+		udelay(600);
+
+		/* Enable CPU FDI Receiver with auto-training */
+		reg = FDI_RX_CTL(pipe);
+		I915_WRITE(reg,
+				I915_READ(reg) |
+					FDI_LINK_TRAIN_AUTO |
+					FDI_RX_ENABLE |
+					FDI_LINK_TRAIN_PATTERN_1_CPT |
+					FDI_RX_ENHANCE_FRAME_ENABLE |
+					FDI_PORT_WIDTH_2X_LPT |
+					FDI_RX_PLL_ENABLE);
+		POSTING_READ(reg);
+		udelay(100);
+
+		temp = I915_READ(DP_TP_STATUS(PORT_E));
+		if (temp & DP_TP_STATUS_AUTOTRAIN_DONE) {
+			DRM_INFO("BUF_CTL training done on %d step\n", i);
+
+			/* Enable normal pixel sending for FDI */
+			I915_WRITE(DP_TP_CTL(PORT_E),
+						DP_TP_CTL_FDI_AUTOTRAIN |
+						DP_TP_CTL_LINK_TRAIN_NORMAL |
+						DP_TP_CTL_ENHANCED_FRAME_ENABLE |
+						DP_TP_CTL_ENABLE);
+
+			/* Enable PIPE_DDI_FUNC_CTL for the pipe to work in FDI mode */
+			temp = I915_READ(DDI_FUNC_CTL(pipe));
+			temp &= ~PIPE_DDI_PORT_MASK;
+			temp |= PIPE_DDI_SELECT_PORT(PORT_E) |
+					PIPE_DDI_MODE_SELECT_FDI |
+					PIPE_DDI_FUNC_ENABLE |
+					PIPE_DDI_PORT_WIDTH_X2;
+			I915_WRITE(DDI_FUNC_CTL(pipe),
+					temp);
+			break;
+		} else {
+			DRM_ERROR("Error training BUF_CTL %d\n", i);
+
+			/* Disable DP_TP_CTL and FDI_RX_CTL) and retry */
+			I915_WRITE(DP_TP_CTL(PORT_E),
+					I915_READ(DP_TP_CTL(PORT_E)) &
+						~DP_TP_CTL_ENABLE);
+			I915_WRITE(FDI_RX_CTL(pipe),
+					I915_READ(FDI_RX_CTL(pipe)) &
+						~FDI_RX_PLL_ENABLE);
+			continue;
+		}
+	}
+
+	DRM_DEBUG_KMS("FDI train done.\n");
+}
+
 /* Manual link training for Ivy Bridge A0 parts */
 static void ivb_manual_fdi_link_train(struct drm_crtc *crtc)
 {
@@ -9542,6 +9649,17 @@ static void intel_init_display(struct drm_device *dev)
 			}
 			dev_priv->display.init_clock_gating = ivybridge_init_clock_gating;
 			dev_priv->display.write_eld = ironlake_write_eld;
+		} else if (IS_HASWELL(dev)) {
+			dev_priv->display.fdi_link_train = hsw_fdi_link_train;
+			if (SNB_READ_WM0_LATENCY()) {
+				dev_priv->display.update_wm = sandybridge_update_wm;
+			} else {
+				DRM_DEBUG_KMS("Failed to read display plane latency. "
+					      "Disable CxSR\n");
+				dev_priv->display.update_wm = NULL;
+			}
+			dev_priv->display.init_clock_gating = ivybridge_init_clock_gating;
+			dev_priv->display.write_eld = ironlake_write_eld;
 		} else
 			dev_priv->display.update_wm = NULL;
 	} else if (IS_VALLEYVIEW(dev)) {
-- 
1.7.10

[PATCH 23/29] drm/i915: disable pipe DDI function when disabling pipe

[Eugeni Dodonov]

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

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index dcfe143..ac34457 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1605,6 +1605,16 @@ static void intel_disable_pipe(struct drm_i915_private *dev_priv,
 
 	I915_WRITE(reg, val & ~PIPECONF_ENABLE);
 	intel_wait_for_pipe_off(dev_priv->dev, pipe);
+
+	/* On HSW, disable pipe DDI function the pipe */
+	if (IS_HASWELL(dev_priv->dev)) {
+		val = I915_READ(DDI_FUNC_CTL(pipe));
+		val &= ~PIPE_DDI_PORT_MASK;
+		val &= ~PIPE_DDI_FUNC_ENABLE;
+		I915_WRITE(DDI_FUNC_CTL(pipe),
+				val);
+	}
+
 }
 
 /*
-- 
1.7.10

[PATCH 24/29] drm/i915: program iCLKIP on Lynx Point

[Eugeni Dodonov]

The iCLKIP clock is used to drive the VGA pixel clock on the PCH. In order
to do so, it must be programmed to properly do the clock ticks according
to the divisor, phase direction, phase increments and a special auxiliary
divisor for 20MHz clock.

Those values can be programmed individually, by doing some math; or we
could use a pre-defined table of values for each modeset. For speed and
simplification, the idea was to just adopt the table of valid pixel clocks
and select the matching iCLKIP values from there.

As a possible idea for the future, it would be possible to add a fallback
and calculate those values manually in case no match is found. But I don't
think we'll encounter a mode not covered by those table, and VGA is pretty
much going away in the future anyway.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index ac34457..bdc22f5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2958,6 +2958,312 @@ static const long hsw_ddi_buf_ctl_values[] = {
 	DDI_BUF_EMP_800MV_3_5DB_HSW
 };
 
+/* Available pixel clock values */
+struct iclk_vga_clock {
+	u32 clock;
+	u16 auxdiv;
+	u16 divsel;
+	u16 phasedir;
+	u16 phaseinc;
+};
+
+static const struct iclk_vga_clock iclk_vga_clock_table[] = {
+	{20000,	1,	0x41,	0,	0x20},	/* 20000 ppm=0 */
+	{21000,	0,	0x7E,	0,	0x25},	/* 20999 ppm=-53 */
+	{21912,	0,	0x79,	0,	0x0E},	/* 21912 ppm=12 */
+	{22000,	0,	0x78,	0,	0x2F},	/* 21999 ppm=-58 */
+	{23000,	0,	0x73,	0,	0x19},	/* 23000 ppm=6 */
+	{24000,	0,	0x6E,	0,	0x20},	/* 24000 ppm=0 */
+	{25000,	0,	0x6A,	0,	0x00},	/* 25000 ppm=0 */
+	{25175,	0,	0x69,	0,	0x10},	/* 25175 ppm=-7 */
+	{25200,	0,	0x69,	0,	0x09},	/* 25201 ppm=21 */
+	{26000,	0,	0x66,	1,	0x0A},	/* 26001 ppm=24 */
+	{27000,	0,	0x62,	0,	0x00},	/* 27000 ppm=0 */
+	{27027,	0,	0x62,	1,	0x06},	/* 27025 ppm=-62 */
+	{27500,	0,	0x60,	0,	0x0C},	/* 27498 ppm=-58 */
+	{28000,	0,	0x5E,	0,	0x1B},	/* 28002 ppm=70 */
+	{28320,	0,	0x5D,	0,	0x16},	/* 28319 ppm=-50 */
+	{28322,	0,	0x5D,	0,	0x15},	/* 28323 ppm=44 */
+	{29000,	0,	0x5B,	0,	0x07},	/* 28998 ppm=-64 */
+	{30000,	0,	0x58,	0,	0x00},	/* 30000 ppm=0 */
+	{31000,	0,	0x55,	0,	0x06},	/* 31001 ppm=35 */
+	{31500,	0,	0x54,	1,	0x12},	/* 31498 ppm=-53 */
+	{32000,	0,	0x52,	0,	0x18},	/* 32000 ppm=0 */
+	{32500,	0,	0x51,	0,	0x05},	/* 32500 ppm=-15 */
+	{33000,	0,	0x50,	1,	0x0C},	/* 33002 ppm=70 */
+	{34000,	0,	0x4D,	0,	0x1A},	/* 34002 ppm=70 */
+	{35000,	0,	0x4B,	0,	0x09},	/* 35001 ppm=29 */
+	{35500,	0,	0x4A,	0,	0x04},	/* 35497 ppm=-82 */
+	{36000,	0,	0x49,	0,	0x00},	/* 36000 ppm=0 */
+	{37000,	0,	0x47,	1,	0x02},	/* 37002 ppm=58 */
+	{38000,	0,	0x45,	0,	0x03},	/* 38003 ppm=82 */
+	{39000,	0,	0x43,	0,	0x0F},	/* 38998 ppm=-53 */
+	{40000,	0,	0x41,	0,	0x20},	/* 40000 ppm=0 */
+	{40500,	0,	0x41,	1,	0x15},	/* 40497 ppm=-79 */
+	{40541,	0,	0x41,	1,	0x1A},	/* 40544 ppm=95 */
+	{41000,	0,	0x40,	1,	0x09},	/* 40996 ppm=-87 */
+	{41540,	0,	0x3F,	0,	0x00},	/* 41538 ppm=-38 */
+	{42000,	0,	0x3E,	0,	0x12},	/* 42003 ppm=70 */
+	{43000,	0,	0x3D,	1,	0x0D},	/* 42996 ppm=-99 */
+	{43163,	0,	0x3D,	1,	0x1D},	/* 43168 ppm=108 */
+	{44000,	0,	0x3B,	0,	0x17},	/* 44003 ppm=70 */
+	{44900,	0,	0x3A,	0,	0x09},	/* 44895 ppm=-117 */
+	{45000,	0,	0x3A,	0,	0x00},	/* 45000 ppm=0 */
+	{46000,	0,	0x39,	1,	0x13},	/* 45994 ppm=-128 */
+	{47000,	0,	0x37,	0,	0x1D},	/* 46995 ppm=-110 */
+	{48000,	0,	0x36,	0,	0x10},	/* 48000 ppm=0 */
+	{49000,	0,	0x35,	0,	0x07},	/* 48993 ppm=-134 */
+	{49500,	0,	0x35,	1,	0x1D},	/* 49499 ppm=-27 */
+	{50000,	0,	0x34,	0,	0x00},	/* 50000 ppm=0 */
+	{51000,	0,	0x33,	1,	0x04},	/* 51004 ppm=70 */
+	{52000,	0,	0x32,	1,	0x05},	/* 52001 ppm=24 */
+	{52406,	0,	0x32,	1,	0x1F},	/* 52411 ppm=101 */
+	{53000,	0,	0x31,	1,	0x04},	/* 53006 ppm=116 */
+	{54000,	0,	0x30,	0,	0x00},	/* 54000 ppm=0 */
+	{54054,	0,	0x30,	1,	0x03},	/* 54051 ppm=-62 */
+	{55000,	0,	0x2F,	0,	0x06},	/* 54997 ppm=-58 */
+	{56000,	0,	0x2E,	0,	0x0E},	/* 55995 ppm=-93 */
+	{56250,	0,	0x2E,	0,	0x00},	/* 56250 ppm=0 */
+	{57000,	0,	0x2D,	0,	0x18},	/* 56992 ppm=-139 */
+	{58000,	0,	0x2D,	1,	0x1D},	/* 58006 ppm=105 */
+	{59000,	0,	0x2C,	1,	0x0F},	/* 58996 ppm=-64 */
+	{60000,	0,	0x2B,	0,	0x00},	/* 60000 ppm=0 */
+	{61000,	0,	0x2A,	0,	0x11},	/* 60995 ppm=-76 */
+	{62000,	0,	0x2A,	1,	0x1D},	/* 62002 ppm=35 */
+	{63000,	0,	0x29,	1,	0x09},	/* 62997 ppm=-53 */
+	{64000,	0,	0x28,	0,	0x0C},	/* 64000 ppm=0 */
+	{65000,	0,	0x28,	1,	0x1E},	/* 65011 ppm=174 */
+	{66000,	0,	0x27,	1,	0x06},	/* 66005 ppm=70 */
+	{66667,	0,	0x26,	0,	0x20},	/* 66667 ppm=-5 */
+	{67000,	0,	0x26,	0,	0x13},	/* 67003 ppm=41 */
+	{68000,	0,	0x26,	1,	0x13},	/* 68005 ppm=70 */
+	{68179,	0,	0x26,	1,	0x19},	/* 68166 ppm=-196 */
+	{69000,	0,	0x25,	0,	0x08},	/* 69010 ppm=139 */
+	{70000,	0,	0x25,	1,	0x1B},	/* 69988 ppm=-174 */
+	{71000,	0,	0x24,	0,	0x02},	/* 70994 ppm=-82 */
+	{72000,	0,	0x23,	0,	0x20},	/* 72000 ppm=0 */
+	{73000,	0,	0x23,	1,	0x01},	/* 73004 ppm=53 */
+	{74000,	0,	0x22,	0,	0x1F},	/* 74004 ppm=58 */
+	{74175,	0,	0x22,	0,	0x1A},	/* 74163 ppm=-161 */
+	{74250,	0,	0x22,	0,	0x17},	/* 74259 ppm=118 */
+	{74481,	0,	0x22,	0,	0x10},	/* 74483 ppm=24 */
+	{75000,	0,	0x22,	0,	0x00},	/* 75000 ppm=0 */
+	{76000,	0,	0x22,	1,	0x1E},	/* 75989 ppm=-139 */
+	{77000,	0,	0x21,	0,	0x04},	/* 77005 ppm=70 */
+	{78000,	0,	0x21,	1,	0x19},	/* 78014 ppm=174 */
+	{78750,	0,	0x20,	0,	0x12},	/* 78760 ppm=131 */
+	{79000,	0,	0x20,	0,	0x0B},	/* 79012 ppm=157 */
+	{80000,	0,	0x20,	1,	0x10},	/* 80000 ppm=0 */
+	{81000,	0,	0x1F,	0,	0x15},	/* 81013 ppm=157 */
+	{81081,	0,	0x1F,	0,	0x13},	/* 81089 ppm=95 */
+	{81624,	0,	0x1F,	0,	0x05},	/* 81625 ppm=12 */
+	{82000,	0,	0x1F,	1,	0x05},	/* 82012 ppm=151 */
+	{83000,	0,	0x1F,	1,	0x1E},	/* 82997 ppm=-35 */
+	{83950,	0,	0x1E,	0,	0x0A},	/* 83965 ppm=179 */
+	{84000,	0,	0x1E,	0,	0x09},	/* 84006 ppm=70 */
+	{85000,	0,	0x1E,	1,	0x0F},	/* 84998 ppm=-29 */
+	{86000,	0,	0x1D,	0,	0x19},	/* 86013 ppm=151 */
+	{87000,	0,	0x1D,	0,	0x02},	/* 87009 ppm=105 */
+	{88000,	0,	0x1D,	1,	0x14},	/* 87984 ppm=-186 */
+	{89000,	0,	0x1C,	0,	0x16},	/* 88980 ppm=-220 */
+	{90000,	0,	0x1C,	0,	0x00},	/* 90000 ppm=0 */
+	{91000,	0,	0x1C,	1,	0x15},	/* 90995 ppm=-53 */
+	{92000,	0,	0x1B,	0,	0x16},	/* 92013 ppm=139 */
+	{93000,	0,	0x1B,	0,	0x02},	/* 93003 ppm=35 */
+	{94000,	0,	0x1B,	1,	0x12},	/* 94015 ppm=163 */
+	{94500,	0,	0x1B,	1,	0x1B},	/* 94478 ppm=-235 */
+	{95000,	0,	0x1A,	0,	0x1B},	/* 94997 ppm=-29 */
+	{95654,	0,	0x1A,	0,	0x0F},	/* 95628 ppm=-271 */
+	{96000,	0,	0x1A,	0,	0x08},	/* 96000 ppm=0 */
+	{97000,	0,	0x1A,	1,	0x0B},	/* 97024 ppm=249 */
+	{98000,	0,	0x1A,	1,	0x1D},	/* 98015 ppm=151 */
+	{99000,	0,	0x19,	0,	0x11},	/* 99026 ppm=261 */
+	{100000,	0,	0x19,	0,	0x00},	/* 100000 ppm=0 */
+	{101000,	0,	0x19,	1,	0x11},	/* 100994 ppm=-64 */
+	{102000,	0,	0x18,	0,	0x1E},	/* 102007 ppm=70 */
+	{103000,	0,	0x18,	0,	0x0E},	/* 102980 ppm=-197 */
+	{104000,	0,	0x18,	1,	0x02},	/* 103971 ppm=-278 */
+	{105000,	0,	0x18,	1,	0x12},	/* 104982 ppm=-174 */
+	{106000,	0,	0x17,	0,	0x1E},	/* 106012 ppm=116 */
+	{107000,	0,	0x17,	0,	0x0F},	/* 106997 ppm=-29 */
+	{107214,	0,	0x17,	0,	0x0C},	/* 107196 ppm=-168 */
+	{108000,	0,	0x17,	0,	0x00},	/* 108000 ppm=0 */
+	{109000,	0,	0x17,	1,	0x0F},	/* 109022 ppm=203 */
+	{110000,	0,	0x17,	1,	0x1D},	/* 109994 ppm=-58 */
+	{110013,	0,	0x17,	1,	0x1D},	/* 109994 ppm=-177 */
+	{111000,	0,	0x16,	0,	0x15},	/* 110983 ppm=-157 */
+	{111263,	0,	0x16,	0,	0x11},	/* 111269 ppm=55 */
+	{111375,	0,	0x16,	0,	0x10},	/* 111340 ppm=-313 */
+	{112000,	0,	0x16,	0,	0x07},	/* 111990 ppm=-93 */
+	{113000,	0,	0x16,	1,	0x07},	/* 113015 ppm=134 */
+	{113309,	0,	0x16,	1,	0x0B},	/* 113311 ppm=22 */
+	{113100,	0,	0x16,	1,	0x08},	/* 113089 ppm=-98 */
+	{114000,	0,	0x16,	1,	0x14},	/* 113984 ppm=-139 */
+	{115000,	0,	0x15,	0,	0x1F},	/* 114970 ppm=-261 */
+	{116000,	0,	0x15,	0,	0x12},	/* 115973 ppm=-232 */
+	{117000,	0,	0x15,	0,	0x05},	/* 116994 ppm=-53 */
+	{118000,	0,	0x15,	1,	0x08},	/* 118033 ppm=278 */
+	{119000,	0,	0x15,	1,	0x14},	/* 119008 ppm=70 */
+	{119651,	0,	0x15,	1,	0x1C},	/* 119668 ppm=139 */
+	{120000,	0,	0x14,	0,	0x20},	/* 120000 ppm=0 */
+	{121000,	0,	0x14,	0,	0x14},	/* 121008 ppm=70 */
+	{122000,	0,	0x14,	0,	0x08},	/* 122034 ppm=278 */
+	{122614,	0,	0x14,	0,	0x01},	/* 122640 ppm=214 */
+	{123000,	0,	0x14,	1,	0x03},	/* 122989 ppm=-87 */
+	{123379,	0,	0x14,	1,	0x07},	/* 123340 ppm=-313 */
+	{124000,	0,	0x14,	1,	0x0E},	/* 123960 ppm=-324 */
+	{125000,	0,	0x14,	1,	0x1A},	/* 125036 ppm=290 */
+	{126000,	0,	0x13,	0,	0x1B},	/* 126039 ppm=313 */
+	{127000,	0,	0x13,	0,	0x11},	/* 126965 ppm=-272 */
+	{128000,	0,	0x13,	0,	0x06},	/* 128000 ppm=0 */
+	{129000,	0,	0x13,	1,	0x04},	/* 128955 ppm=-348 */
+	{129859,	0,	0x13,	1,	0x0D},	/* 129827 ppm=-245 */
+	{130000,	0,	0x13,	1,	0x0F},	/* 130023 ppm=174 */
+	{131000,	0,	0x13,	1,	0x19},	/* 131008 ppm=64 */
+	{131850,	0,	0x12,	0,	0x1F},	/* 131808 ppm=-321 */
+	{132000,	0,	0x12,	0,	0x1D},	/* 132009 ppm=70 */
+	{133000,	0,	0x12,	0,	0x13},	/* 133025 ppm=192 */
+	{133330,	0,	0x12,	0,	0x10},	/* 133333 ppm=26 */
+	{134000,	0,	0x12,	0,	0x0A},	/* 133953 ppm=-348 */
+	{135000,	0,	0x12,	0,	0x00},	/* 135000 ppm=0 */
+	{136000,	0,	0x12,	1,	0x09},	/* 135956 ppm=-324 */
+	{137000,	0,	0x12,	1,	0x13},	/* 137034 ppm=249 */
+	{138000,	0,	0x12,	1,	0x1C},	/* 138019 ppm=139 */
+	{139000,	0,	0x11,	0,	0x1B},	/* 139019 ppm=134 */
+	{139050,	0,	0x11,	0,	0x1B},	/* 139019 ppm=-227 */
+	{139054,	0,	0x11,	0,	0x1B},	/* 139019 ppm=-256 */
+	{140000,	0,	0x11,	0,	0x12},	/* 140032 ppm=232 */
+	{141000,	0,	0x11,	0,	0x0A},	/* 140946 ppm=-382 */
+	{142000,	0,	0x11,	0,	0x01},	/* 141988 ppm=-82 */
+	{143000,	0,	0x11,	1,	0x08},	/* 143046 ppm=325 */
+	{143472,	0,	0x11,	1,	0x0C},	/* 143522 ppm=346 */
+	{144000,	0,	0x11,	1,	0x10},	/* 144000 ppm=0 */
+	{145000,	0,	0x11,	1,	0x18},	/* 144966 ppm=-232 */
+	{146000,	0,	0x10,	0,	0x20},	/* 145946 ppm=-371 */
+	{147000,	0,	0x10,	0,	0x18},	/* 146939 ppm=-417 */
+	{147891,	0,	0x10,	0,	0x10},	/* 147945 ppm=367 */
+	{148000,	0,	0x10,	0,	0x10},	/* 147945 ppm=-371 */
+	{148350,	0,	0x10,	0,	0x0D},	/* 148326 ppm=-161 */
+	{148500,	0,	0x10,	0,	0x0C},	/* 148454 ppm=-313 */
+	{149000,	0,	0x10,	0,	0x08},	/* 148966 ppm=-232 */
+	{150000,	0,	0x10,	0,	0x00},	/* 150000 ppm=0 */
+	{151000,	0,	0x10,	1,	0x08},	/* 151049 ppm=325 */
+	{152000,	0,	0x10,	1,	0x0F},	/* 151979 ppm=-139 */
+	{152280,	0,	0x10,	1,	0x11},	/* 152247 ppm=-219 */
+	{153000,	0,	0x10,	1,	0x17},	/* 153056 ppm=365 */
+	{154000,	0,	0x10,	1,	0x1E},	/* 154011 ppm=70 */
+	{155000,	0,	0x0F,	0,	0x1B},	/* 154978 ppm=-145 */
+	{156000,	0,	0x0F,	0,	0x14},	/* 155957 ppm=-278 */
+	{157000,	0,	0x0F,	0,	0x0D},	/* 156948 ppm=-330 */
+	{157500,	0,	0x0F,	0,	0x09},	/* 157521 ppm=131 */
+	{158000,	0,	0x0F,	0,	0x06},	/* 157952 ppm=-301 */
+	{159000,	0,	0x0F,	1,	0x01},	/* 158970 ppm=-191 */
+	{160000,	0,	0x0F,	1,	0x08},	/* 160000 ppm=0 */
+	{161000,	0,	0x0F,	1,	0x0F},	/* 161044 ppm=273 */
+	{162000,	0,	0x0F,	1,	0x15},	/* 161949 ppm=-313 */
+	{163000,	0,	0x0F,	1,	0x1C},	/* 163019 ppm=116 */
+	{164000,	0,	0x0E,	0,	0x1E},	/* 163947 ppm=-324 */
+	{165000,	0,	0x0E,	0,	0x17},	/* 165043 ppm=261 */
+	{166000,	0,	0x0E,	0,	0x11},	/* 165994 ppm=-35 */
+	{167000,	0,	0x0E,	0,	0x0B},	/* 166957 ppm=-261 */
+	{168000,	0,	0x0E,	0,	0x05},	/* 167930 ppm=-417 */
+	{169000,	0,	0x0E,	1,	0x02},	/* 169080 ppm=475 */
+	{169128,	0,	0x0E,	1,	0x02},	/* 169080 ppm=-283 */
+	{170000,	0,	0x0E,	1,	0x08},	/* 170079 ppm=464 */
+	{171000,	0,	0x0E,	1,	0x0D},	/* 170920 ppm=-469 */
+	{172000,	0,	0x0E,	1,	0x13},	/* 171940 ppm=-348 */
+	{172800,	0,	0x0E,	1,	0x18},	/* 172800 ppm=0 */
+	{173000,	0,	0x0E,	1,	0x19},	/* 172973 ppm=-157 */
+	{174000,	0,	0x0E,	1,	0x1F},	/* 174018 ppm=105 */
+	{174787,	0,	0x0D,	0,	0x1D},	/* 174722 ppm=-373 */
+	{175000,	0,	0x0D,	0,	0x1B},	/* 175076 ppm=435 */
+	{175500,	0,	0x0D,	0,	0x19},	/* 175431 ppm=-391 */
+	{176000,	0,	0x0D,	0,	0x16},	/* 175967 ppm=-186 */
+	{177000,	0,	0x0D,	0,	0x10},	/* 177049 ppm=278 */
+	{178000,	0,	0x0D,	0,	0x0B},	/* 177961 ppm=-220 */
+	{179000,	0,	0x0D,	0,	0x05},	/* 179067 ppm=377 */
+	{180000,	0,	0x0D,	0,	0x00},	/* 180000 ppm=0 */
+};
+
+/* Program iCLKIP clock to the desired frequency */
+static void lpt_program_iclkip(struct drm_crtc *crtc)
+{
+	struct drm_device *dev = crtc->dev;
+	struct drm_i915_private *dev_priv = dev->dev_private;
+	u32 auxdiv=0, divsel=0, phasedir=0, phaseinc=0, valid=0;
+	u32 temp, i;
+
+	/* Ungate pixel clock */
+	I915_WRITE(PIXCLK_GATE, PIXCLK_GATE_GATE);
+
+	/* Disable SSCCTL */
+	intel_sbi_write(dev_priv, SBI_SSCCTL6,
+				intel_sbi_read(dev_priv, SBI_SSCCTL6) |
+					SBI_SSCCTL_DISABLE);
+
+	/* Calculating clock values for iCLKIP */
+	for (i=0; i < ARRAY_SIZE(iclk_vga_clock_table); i++) {
+		if (crtc->mode.clock == iclk_vga_clock_table[i].clock) {
+			DRM_INFO("Found clock settings for %dKHz refresh rate\n",
+					crtc->mode.clock);
+
+			auxdiv = iclk_vga_clock_table[i].auxdiv;
+			divsel = iclk_vga_clock_table[i].divsel;
+			phasedir = iclk_vga_clock_table[i].phasedir;
+			phaseinc = iclk_vga_clock_table[i].phaseinc;
+
+			valid = 1;
+
+			break;
+		}
+	}
+
+	if (!valid) {
+		DRM_ERROR("Unable to find iCLKIP clock settings for %dKHz refresh rate\n",
+				crtc->mode.clock);
+		return;
+	}
+
+	/* Program SSCDIVINTPHASE6 with values which HW team uses */
+	DRM_DEBUG("Programming SSCDIVINTPHASE for %dKHz: auxdiv=%x, divsel=%x, phasedir=%x, phaseinc=%x\n",
+			crtc->mode.clock,
+			auxdiv,
+			divsel,
+			phasedir,
+			phaseinc);
+
+	/* Program SSCDIVINTPHASE6 */
+	temp = intel_sbi_read(dev_priv, SBI_SSCDIVINTPHASE6);
+	temp &= ~SBI_SSCDIVINTPHASE_DIVSEL_MASK;
+	temp |= SBI_SSCDIVINTPHASE_DIVSEL(divsel);
+	temp &= ~SBI_SSCDIVINTPHASE_INCVAL_MASK;
+	temp |= SBI_SSCDIVINTPHASE_INCVAL(phaseinc);
+	temp |= SBI_SSCDIVINTPHASE_DIR(phasedir);
+	temp |= SBI_SSCDIVINTPHASE_PROPAGATE;
+
+	intel_sbi_write(dev_priv,
+			SBI_SSCDIVINTPHASE6,
+			temp);
+
+	/* Program SSCAUXDIV */
+	intel_sbi_write(dev_priv,
+			SBI_SSCAUXDIV6,
+				intel_sbi_read(dev_priv, SBI_SSCAUXDIV6) |
+					SBI_SSCAUXDIV_FINALDIV2SEL(auxdiv));
+
+
+	/* Enable modulator and associated divider */
+	intel_sbi_write(dev_priv, SBI_SSCCTL6,
+				intel_sbi_read(dev_priv, SBI_SSCCTL6) &
+					~SBI_SSCCTL_DISABLE);
+
+	/* Wait for initialization time */
+	udelay(50);
+
+	/* Gate pixel clock */
+	I915_WRITE(PIXCLK_GATE, PIXCLK_GATE_UNGATE);
+}
+
 
 /* Link training for HSW parts */
 static void hsw_fdi_link_train(struct drm_crtc *crtc)
@@ -3386,6 +3692,9 @@ static void ironlake_pch_enable(struct drm_crtc *crtc)
 			temp |= (TRANSC_DPLL_ENABLE | transc_sel);
 		}
 		I915_WRITE(PCH_DPLL_SEL, temp);
+	} else if (HAS_PCH_LPT(dev)) {
+		/* Program iCLKIP */
+		lpt_program_iclkip(crtc);
 	}
 
 	/* set transcoder timing, panel must allow it */
-- 
1.7.10

Re: [PATCH 24/29] drm/i915: program iCLKIP on Lynx Point

[Daniel Vetter]

On Fri, Apr 13, 2012 at 05:09:00PM -0300, Eugeni Dodonov wrote:
> The iCLKIP clock is used to drive the VGA pixel clock on the PCH. In order
> to do so, it must be programmed to properly do the clock ticks according
> to the divisor, phase direction, phase increments and a special auxiliary
> divisor for 20MHz clock.
> 
> Those values can be programmed individually, by doing some math; or we
> could use a pre-defined table of values for each modeset. For speed and
> simplification, the idea was to just adopt the table of valid pixel clocks
> and select the matching iCLKIP values from there.
> 
> As a possible idea for the future, it would be possible to add a fallback
> and calculate those values manually in case no match is found. But I don't
> think we'll encounter a mode not covered by those table, and VGA is pretty
> much going away in the future anyway.
> 
> Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>

I'm honestly not too happy with this table, because somewhere in there
we'll have an annoying type, and there's almost zero chance we'll ever
find that. So I prefer if we can replicate the pixel clock computation
from some stupid excel sheet ...
-Daniel
> ---
>  drivers/gpu/drm/i915/intel_display.c |  309 ++++++++++++++++++++++++++++++++++
>  1 file changed, 309 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index ac34457..bdc22f5 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2958,6 +2958,312 @@ static const long hsw_ddi_buf_ctl_values[] = {
>  	DDI_BUF_EMP_800MV_3_5DB_HSW
>  };
>  
> +/* Available pixel clock values */
> +struct iclk_vga_clock {
> +	u32 clock;
> +	u16 auxdiv;
> +	u16 divsel;
> +	u16 phasedir;
> +	u16 phaseinc;
> +};
> +
> +static const struct iclk_vga_clock iclk_vga_clock_table[] = {
> +	{20000,	1,	0x41,	0,	0x20},	/* 20000 ppm=0 */
> +	{21000,	0,	0x7E,	0,	0x25},	/* 20999 ppm=-53 */
> +	{21912,	0,	0x79,	0,	0x0E},	/* 21912 ppm=12 */
> +	{22000,	0,	0x78,	0,	0x2F},	/* 21999 ppm=-58 */
> +	{23000,	0,	0x73,	0,	0x19},	/* 23000 ppm=6 */
> +	{24000,	0,	0x6E,	0,	0x20},	/* 24000 ppm=0 */
> +	{25000,	0,	0x6A,	0,	0x00},	/* 25000 ppm=0 */
> +	{25175,	0,	0x69,	0,	0x10},	/* 25175 ppm=-7 */
> +	{25200,	0,	0x69,	0,	0x09},	/* 25201 ppm=21 */
> +	{26000,	0,	0x66,	1,	0x0A},	/* 26001 ppm=24 */
> +	{27000,	0,	0x62,	0,	0x00},	/* 27000 ppm=0 */
> +	{27027,	0,	0x62,	1,	0x06},	/* 27025 ppm=-62 */
> +	{27500,	0,	0x60,	0,	0x0C},	/* 27498 ppm=-58 */
> +	{28000,	0,	0x5E,	0,	0x1B},	/* 28002 ppm=70 */
> +	{28320,	0,	0x5D,	0,	0x16},	/* 28319 ppm=-50 */
> +	{28322,	0,	0x5D,	0,	0x15},	/* 28323 ppm=44 */
> +	{29000,	0,	0x5B,	0,	0x07},	/* 28998 ppm=-64 */
> +	{30000,	0,	0x58,	0,	0x00},	/* 30000 ppm=0 */
> +	{31000,	0,	0x55,	0,	0x06},	/* 31001 ppm=35 */
> +	{31500,	0,	0x54,	1,	0x12},	/* 31498 ppm=-53 */
> +	{32000,	0,	0x52,	0,	0x18},	/* 32000 ppm=0 */
> +	{32500,	0,	0x51,	0,	0x05},	/* 32500 ppm=-15 */
> +	{33000,	0,	0x50,	1,	0x0C},	/* 33002 ppm=70 */
> +	{34000,	0,	0x4D,	0,	0x1A},	/* 34002 ppm=70 */
> +	{35000,	0,	0x4B,	0,	0x09},	/* 35001 ppm=29 */
> +	{35500,	0,	0x4A,	0,	0x04},	/* 35497 ppm=-82 */
> +	{36000,	0,	0x49,	0,	0x00},	/* 36000 ppm=0 */
> +	{37000,	0,	0x47,	1,	0x02},	/* 37002 ppm=58 */
> +	{38000,	0,	0x45,	0,	0x03},	/* 38003 ppm=82 */
> +	{39000,	0,	0x43,	0,	0x0F},	/* 38998 ppm=-53 */
> +	{40000,	0,	0x41,	0,	0x20},	/* 40000 ppm=0 */
> +	{40500,	0,	0x41,	1,	0x15},	/* 40497 ppm=-79 */
> +	{40541,	0,	0x41,	1,	0x1A},	/* 40544 ppm=95 */
> +	{41000,	0,	0x40,	1,	0x09},	/* 40996 ppm=-87 */
> +	{41540,	0,	0x3F,	0,	0x00},	/* 41538 ppm=-38 */
> +	{42000,	0,	0x3E,	0,	0x12},	/* 42003 ppm=70 */
> +	{43000,	0,	0x3D,	1,	0x0D},	/* 42996 ppm=-99 */
> +	{43163,	0,	0x3D,	1,	0x1D},	/* 43168 ppm=108 */
> +	{44000,	0,	0x3B,	0,	0x17},	/* 44003 ppm=70 */
> +	{44900,	0,	0x3A,	0,	0x09},	/* 44895 ppm=-117 */
> +	{45000,	0,	0x3A,	0,	0x00},	/* 45000 ppm=0 */
> +	{46000,	0,	0x39,	1,	0x13},	/* 45994 ppm=-128 */
> +	{47000,	0,	0x37,	0,	0x1D},	/* 46995 ppm=-110 */
> +	{48000,	0,	0x36,	0,	0x10},	/* 48000 ppm=0 */
> +	{49000,	0,	0x35,	0,	0x07},	/* 48993 ppm=-134 */
> +	{49500,	0,	0x35,	1,	0x1D},	/* 49499 ppm=-27 */
> +	{50000,	0,	0x34,	0,	0x00},	/* 50000 ppm=0 */
> +	{51000,	0,	0x33,	1,	0x04},	/* 51004 ppm=70 */
> +	{52000,	0,	0x32,	1,	0x05},	/* 52001 ppm=24 */
> +	{52406,	0,	0x32,	1,	0x1F},	/* 52411 ppm=101 */
> +	{53000,	0,	0x31,	1,	0x04},	/* 53006 ppm=116 */
> +	{54000,	0,	0x30,	0,	0x00},	/* 54000 ppm=0 */
> +	{54054,	0,	0x30,	1,	0x03},	/* 54051 ppm=-62 */
> +	{55000,	0,	0x2F,	0,	0x06},	/* 54997 ppm=-58 */
> +	{56000,	0,	0x2E,	0,	0x0E},	/* 55995 ppm=-93 */
> +	{56250,	0,	0x2E,	0,	0x00},	/* 56250 ppm=0 */
> +	{57000,	0,	0x2D,	0,	0x18},	/* 56992 ppm=-139 */
> +	{58000,	0,	0x2D,	1,	0x1D},	/* 58006 ppm=105 */
> +	{59000,	0,	0x2C,	1,	0x0F},	/* 58996 ppm=-64 */
> +	{60000,	0,	0x2B,	0,	0x00},	/* 60000 ppm=0 */
> +	{61000,	0,	0x2A,	0,	0x11},	/* 60995 ppm=-76 */
> +	{62000,	0,	0x2A,	1,	0x1D},	/* 62002 ppm=35 */
> +	{63000,	0,	0x29,	1,	0x09},	/* 62997 ppm=-53 */
> +	{64000,	0,	0x28,	0,	0x0C},	/* 64000 ppm=0 */
> +	{65000,	0,	0x28,	1,	0x1E},	/* 65011 ppm=174 */
> +	{66000,	0,	0x27,	1,	0x06},	/* 66005 ppm=70 */
> +	{66667,	0,	0x26,	0,	0x20},	/* 66667 ppm=-5 */
> +	{67000,	0,	0x26,	0,	0x13},	/* 67003 ppm=41 */
> +	{68000,	0,	0x26,	1,	0x13},	/* 68005 ppm=70 */
> +	{68179,	0,	0x26,	1,	0x19},	/* 68166 ppm=-196 */
> +	{69000,	0,	0x25,	0,	0x08},	/* 69010 ppm=139 */
> +	{70000,	0,	0x25,	1,	0x1B},	/* 69988 ppm=-174 */
> +	{71000,	0,	0x24,	0,	0x02},	/* 70994 ppm=-82 */
> +	{72000,	0,	0x23,	0,	0x20},	/* 72000 ppm=0 */
> +	{73000,	0,	0x23,	1,	0x01},	/* 73004 ppm=53 */
> +	{74000,	0,	0x22,	0,	0x1F},	/* 74004 ppm=58 */
> +	{74175,	0,	0x22,	0,	0x1A},	/* 74163 ppm=-161 */
> +	{74250,	0,	0x22,	0,	0x17},	/* 74259 ppm=118 */
> +	{74481,	0,	0x22,	0,	0x10},	/* 74483 ppm=24 */
> +	{75000,	0,	0x22,	0,	0x00},	/* 75000 ppm=0 */
> +	{76000,	0,	0x22,	1,	0x1E},	/* 75989 ppm=-139 */
> +	{77000,	0,	0x21,	0,	0x04},	/* 77005 ppm=70 */
> +	{78000,	0,	0x21,	1,	0x19},	/* 78014 ppm=174 */
> +	{78750,	0,	0x20,	0,	0x12},	/* 78760 ppm=131 */
> +	{79000,	0,	0x20,	0,	0x0B},	/* 79012 ppm=157 */
> +	{80000,	0,	0x20,	1,	0x10},	/* 80000 ppm=0 */
> +	{81000,	0,	0x1F,	0,	0x15},	/* 81013 ppm=157 */
> +	{81081,	0,	0x1F,	0,	0x13},	/* 81089 ppm=95 */
> +	{81624,	0,	0x1F,	0,	0x05},	/* 81625 ppm=12 */
> +	{82000,	0,	0x1F,	1,	0x05},	/* 82012 ppm=151 */
> +	{83000,	0,	0x1F,	1,	0x1E},	/* 82997 ppm=-35 */
> +	{83950,	0,	0x1E,	0,	0x0A},	/* 83965 ppm=179 */
> +	{84000,	0,	0x1E,	0,	0x09},	/* 84006 ppm=70 */
> +	{85000,	0,	0x1E,	1,	0x0F},	/* 84998 ppm=-29 */
> +	{86000,	0,	0x1D,	0,	0x19},	/* 86013 ppm=151 */
> +	{87000,	0,	0x1D,	0,	0x02},	/* 87009 ppm=105 */
> +	{88000,	0,	0x1D,	1,	0x14},	/* 87984 ppm=-186 */
> +	{89000,	0,	0x1C,	0,	0x16},	/* 88980 ppm=-220 */
> +	{90000,	0,	0x1C,	0,	0x00},	/* 90000 ppm=0 */
> +	{91000,	0,	0x1C,	1,	0x15},	/* 90995 ppm=-53 */
> +	{92000,	0,	0x1B,	0,	0x16},	/* 92013 ppm=139 */
> +	{93000,	0,	0x1B,	0,	0x02},	/* 93003 ppm=35 */
> +	{94000,	0,	0x1B,	1,	0x12},	/* 94015 ppm=163 */
> +	{94500,	0,	0x1B,	1,	0x1B},	/* 94478 ppm=-235 */
> +	{95000,	0,	0x1A,	0,	0x1B},	/* 94997 ppm=-29 */
> +	{95654,	0,	0x1A,	0,	0x0F},	/* 95628 ppm=-271 */
> +	{96000,	0,	0x1A,	0,	0x08},	/* 96000 ppm=0 */
> +	{97000,	0,	0x1A,	1,	0x0B},	/* 97024 ppm=249 */
> +	{98000,	0,	0x1A,	1,	0x1D},	/* 98015 ppm=151 */
> +	{99000,	0,	0x19,	0,	0x11},	/* 99026 ppm=261 */
> +	{100000,	0,	0x19,	0,	0x00},	/* 100000 ppm=0 */
> +	{101000,	0,	0x19,	1,	0x11},	/* 100994 ppm=-64 */
> +	{102000,	0,	0x18,	0,	0x1E},	/* 102007 ppm=70 */
> +	{103000,	0,	0x18,	0,	0x0E},	/* 102980 ppm=-197 */
> +	{104000,	0,	0x18,	1,	0x02},	/* 103971 ppm=-278 */
> +	{105000,	0,	0x18,	1,	0x12},	/* 104982 ppm=-174 */
> +	{106000,	0,	0x17,	0,	0x1E},	/* 106012 ppm=116 */
> +	{107000,	0,	0x17,	0,	0x0F},	/* 106997 ppm=-29 */
> +	{107214,	0,	0x17,	0,	0x0C},	/* 107196 ppm=-168 */
> +	{108000,	0,	0x17,	0,	0x00},	/* 108000 ppm=0 */
> +	{109000,	0,	0x17,	1,	0x0F},	/* 109022 ppm=203 */
> +	{110000,	0,	0x17,	1,	0x1D},	/* 109994 ppm=-58 */
> +	{110013,	0,	0x17,	1,	0x1D},	/* 109994 ppm=-177 */
> +	{111000,	0,	0x16,	0,	0x15},	/* 110983 ppm=-157 */
> +	{111263,	0,	0x16,	0,	0x11},	/* 111269 ppm=55 */
> +	{111375,	0,	0x16,	0,	0x10},	/* 111340 ppm=-313 */
> +	{112000,	0,	0x16,	0,	0x07},	/* 111990 ppm=-93 */
> +	{113000,	0,	0x16,	1,	0x07},	/* 113015 ppm=134 */
> +	{113309,	0,	0x16,	1,	0x0B},	/* 113311 ppm=22 */
> +	{113100,	0,	0x16,	1,	0x08},	/* 113089 ppm=-98 */
> +	{114000,	0,	0x16,	1,	0x14},	/* 113984 ppm=-139 */
> +	{115000,	0,	0x15,	0,	0x1F},	/* 114970 ppm=-261 */
> +	{116000,	0,	0x15,	0,	0x12},	/* 115973 ppm=-232 */
> +	{117000,	0,	0x15,	0,	0x05},	/* 116994 ppm=-53 */
> +	{118000,	0,	0x15,	1,	0x08},	/* 118033 ppm=278 */
> +	{119000,	0,	0x15,	1,	0x14},	/* 119008 ppm=70 */
> +	{119651,	0,	0x15,	1,	0x1C},	/* 119668 ppm=139 */
> +	{120000,	0,	0x14,	0,	0x20},	/* 120000 ppm=0 */
> +	{121000,	0,	0x14,	0,	0x14},	/* 121008 ppm=70 */
> +	{122000,	0,	0x14,	0,	0x08},	/* 122034 ppm=278 */
> +	{122614,	0,	0x14,	0,	0x01},	/* 122640 ppm=214 */
> +	{123000,	0,	0x14,	1,	0x03},	/* 122989 ppm=-87 */
> +	{123379,	0,	0x14,	1,	0x07},	/* 123340 ppm=-313 */
> +	{124000,	0,	0x14,	1,	0x0E},	/* 123960 ppm=-324 */
> +	{125000,	0,	0x14,	1,	0x1A},	/* 125036 ppm=290 */
> +	{126000,	0,	0x13,	0,	0x1B},	/* 126039 ppm=313 */
> +	{127000,	0,	0x13,	0,	0x11},	/* 126965 ppm=-272 */
> +	{128000,	0,	0x13,	0,	0x06},	/* 128000 ppm=0 */
> +	{129000,	0,	0x13,	1,	0x04},	/* 128955 ppm=-348 */
> +	{129859,	0,	0x13,	1,	0x0D},	/* 129827 ppm=-245 */
> +	{130000,	0,	0x13,	1,	0x0F},	/* 130023 ppm=174 */
> +	{131000,	0,	0x13,	1,	0x19},	/* 131008 ppm=64 */
> +	{131850,	0,	0x12,	0,	0x1F},	/* 131808 ppm=-321 */
> +	{132000,	0,	0x12,	0,	0x1D},	/* 132009 ppm=70 */
> +	{133000,	0,	0x12,	0,	0x13},	/* 133025 ppm=192 */
> +	{133330,	0,	0x12,	0,	0x10},	/* 133333 ppm=26 */
> +	{134000,	0,	0x12,	0,	0x0A},	/* 133953 ppm=-348 */
> +	{135000,	0,	0x12,	0,	0x00},	/* 135000 ppm=0 */
> +	{136000,	0,	0x12,	1,	0x09},	/* 135956 ppm=-324 */
> +	{137000,	0,	0x12,	1,	0x13},	/* 137034 ppm=249 */
> +	{138000,	0,	0x12,	1,	0x1C},	/* 138019 ppm=139 */
> +	{139000,	0,	0x11,	0,	0x1B},	/* 139019 ppm=134 */
> +	{139050,	0,	0x11,	0,	0x1B},	/* 139019 ppm=-227 */
> +	{139054,	0,	0x11,	0,	0x1B},	/* 139019 ppm=-256 */
> +	{140000,	0,	0x11,	0,	0x12},	/* 140032 ppm=232 */
> +	{141000,	0,	0x11,	0,	0x0A},	/* 140946 ppm=-382 */
> +	{142000,	0,	0x11,	0,	0x01},	/* 141988 ppm=-82 */
> +	{143000,	0,	0x11,	1,	0x08},	/* 143046 ppm=325 */
> +	{143472,	0,	0x11,	1,	0x0C},	/* 143522 ppm=346 */
> +	{144000,	0,	0x11,	1,	0x10},	/* 144000 ppm=0 */
> +	{145000,	0,	0x11,	1,	0x18},	/* 144966 ppm=-232 */
> +	{146000,	0,	0x10,	0,	0x20},	/* 145946 ppm=-371 */
> +	{147000,	0,	0x10,	0,	0x18},	/* 146939 ppm=-417 */
> +	{147891,	0,	0x10,	0,	0x10},	/* 147945 ppm=367 */
> +	{148000,	0,	0x10,	0,	0x10},	/* 147945 ppm=-371 */
> +	{148350,	0,	0x10,	0,	0x0D},	/* 148326 ppm=-161 */
> +	{148500,	0,	0x10,	0,	0x0C},	/* 148454 ppm=-313 */
> +	{149000,	0,	0x10,	0,	0x08},	/* 148966 ppm=-232 */
> +	{150000,	0,	0x10,	0,	0x00},	/* 150000 ppm=0 */
> +	{151000,	0,	0x10,	1,	0x08},	/* 151049 ppm=325 */
> +	{152000,	0,	0x10,	1,	0x0F},	/* 151979 ppm=-139 */
> +	{152280,	0,	0x10,	1,	0x11},	/* 152247 ppm=-219 */
> +	{153000,	0,	0x10,	1,	0x17},	/* 153056 ppm=365 */
> +	{154000,	0,	0x10,	1,	0x1E},	/* 154011 ppm=70 */
> +	{155000,	0,	0x0F,	0,	0x1B},	/* 154978 ppm=-145 */
> +	{156000,	0,	0x0F,	0,	0x14},	/* 155957 ppm=-278 */
> +	{157000,	0,	0x0F,	0,	0x0D},	/* 156948 ppm=-330 */
> +	{157500,	0,	0x0F,	0,	0x09},	/* 157521 ppm=131 */
> +	{158000,	0,	0x0F,	0,	0x06},	/* 157952 ppm=-301 */
> +	{159000,	0,	0x0F,	1,	0x01},	/* 158970 ppm=-191 */
> +	{160000,	0,	0x0F,	1,	0x08},	/* 160000 ppm=0 */
> +	{161000,	0,	0x0F,	1,	0x0F},	/* 161044 ppm=273 */
> +	{162000,	0,	0x0F,	1,	0x15},	/* 161949 ppm=-313 */
> +	{163000,	0,	0x0F,	1,	0x1C},	/* 163019 ppm=116 */
> +	{164000,	0,	0x0E,	0,	0x1E},	/* 163947 ppm=-324 */
> +	{165000,	0,	0x0E,	0,	0x17},	/* 165043 ppm=261 */
> +	{166000,	0,	0x0E,	0,	0x11},	/* 165994 ppm=-35 */
> +	{167000,	0,	0x0E,	0,	0x0B},	/* 166957 ppm=-261 */
> +	{168000,	0,	0x0E,	0,	0x05},	/* 167930 ppm=-417 */
> +	{169000,	0,	0x0E,	1,	0x02},	/* 169080 ppm=475 */
> +	{169128,	0,	0x0E,	1,	0x02},	/* 169080 ppm=-283 */
> +	{170000,	0,	0x0E,	1,	0x08},	/* 170079 ppm=464 */
> +	{171000,	0,	0x0E,	1,	0x0D},	/* 170920 ppm=-469 */
> +	{172000,	0,	0x0E,	1,	0x13},	/* 171940 ppm=-348 */
> +	{172800,	0,	0x0E,	1,	0x18},	/* 172800 ppm=0 */
> +	{173000,	0,	0x0E,	1,	0x19},	/* 172973 ppm=-157 */
> +	{174000,	0,	0x0E,	1,	0x1F},	/* 174018 ppm=105 */
> +	{174787,	0,	0x0D,	0,	0x1D},	/* 174722 ppm=-373 */
> +	{175000,	0,	0x0D,	0,	0x1B},	/* 175076 ppm=435 */
> +	{175500,	0,	0x0D,	0,	0x19},	/* 175431 ppm=-391 */
> +	{176000,	0,	0x0D,	0,	0x16},	/* 175967 ppm=-186 */
> +	{177000,	0,	0x0D,	0,	0x10},	/* 177049 ppm=278 */
> +	{178000,	0,	0x0D,	0,	0x0B},	/* 177961 ppm=-220 */
> +	{179000,	0,	0x0D,	0,	0x05},	/* 179067 ppm=377 */
> +	{180000,	0,	0x0D,	0,	0x00},	/* 180000 ppm=0 */
> +};
> +
> +/* Program iCLKIP clock to the desired frequency */
> +static void lpt_program_iclkip(struct drm_crtc *crtc)
> +{
> +	struct drm_device *dev = crtc->dev;
> +	struct drm_i915_private *dev_priv = dev->dev_private;
> +	u32 auxdiv=0, divsel=0, phasedir=0, phaseinc=0, valid=0;
> +	u32 temp, i;
> +
> +	/* Ungate pixel clock */
> +	I915_WRITE(PIXCLK_GATE, PIXCLK_GATE_GATE);
> +
> +	/* Disable SSCCTL */
> +	intel_sbi_write(dev_priv, SBI_SSCCTL6,
> +				intel_sbi_read(dev_priv, SBI_SSCCTL6) |
> +					SBI_SSCCTL_DISABLE);
> +
> +	/* Calculating clock values for iCLKIP */
> +	for (i=0; i < ARRAY_SIZE(iclk_vga_clock_table); i++) {
> +		if (crtc->mode.clock == iclk_vga_clock_table[i].clock) {
> +			DRM_INFO("Found clock settings for %dKHz refresh rate\n",
> +					crtc->mode.clock);
> +
> +			auxdiv = iclk_vga_clock_table[i].auxdiv;
> +			divsel = iclk_vga_clock_table[i].divsel;
> +			phasedir = iclk_vga_clock_table[i].phasedir;
> +			phaseinc = iclk_vga_clock_table[i].phaseinc;
> +
> +			valid = 1;
> +
> +			break;
> +		}
> +	}
> +
> +	if (!valid) {
> +		DRM_ERROR("Unable to find iCLKIP clock settings for %dKHz refresh rate\n",
> +				crtc->mode.clock);
> +		return;
> +	}
> +
> +	/* Program SSCDIVINTPHASE6 with values which HW team uses */
> +	DRM_DEBUG("Programming SSCDIVINTPHASE for %dKHz: auxdiv=%x, divsel=%x, phasedir=%x, phaseinc=%x\n",
> +			crtc->mode.clock,
> +			auxdiv,
> +			divsel,
> +			phasedir,
> +			phaseinc);
> +
> +	/* Program SSCDIVINTPHASE6 */
> +	temp = intel_sbi_read(dev_priv, SBI_SSCDIVINTPHASE6);
> +	temp &= ~SBI_SSCDIVINTPHASE_DIVSEL_MASK;
> +	temp |= SBI_SSCDIVINTPHASE_DIVSEL(divsel);
> +	temp &= ~SBI_SSCDIVINTPHASE_INCVAL_MASK;
> +	temp |= SBI_SSCDIVINTPHASE_INCVAL(phaseinc);
> +	temp |= SBI_SSCDIVINTPHASE_DIR(phasedir);
> +	temp |= SBI_SSCDIVINTPHASE_PROPAGATE;
> +
> +	intel_sbi_write(dev_priv,
> +			SBI_SSCDIVINTPHASE6,
> +			temp);
> +
> +	/* Program SSCAUXDIV */
> +	intel_sbi_write(dev_priv,
> +			SBI_SSCAUXDIV6,
> +				intel_sbi_read(dev_priv, SBI_SSCAUXDIV6) |
> +					SBI_SSCAUXDIV_FINALDIV2SEL(auxdiv));
> +
> +
> +	/* Enable modulator and associated divider */
> +	intel_sbi_write(dev_priv, SBI_SSCCTL6,
> +				intel_sbi_read(dev_priv, SBI_SSCCTL6) &
> +					~SBI_SSCCTL_DISABLE);
> +
> +	/* Wait for initialization time */
> +	udelay(50);
> +
> +	/* Gate pixel clock */
> +	I915_WRITE(PIXCLK_GATE, PIXCLK_GATE_UNGATE);
> +}
> +
>  
>  /* Link training for HSW parts */
>  static void hsw_fdi_link_train(struct drm_crtc *crtc)
> @@ -3386,6 +3692,9 @@ static void ironlake_pch_enable(struct drm_crtc *crtc)
>  			temp |= (TRANSC_DPLL_ENABLE | transc_sel);
>  		}
>  		I915_WRITE(PCH_DPLL_SEL, temp);
> +	} else if (HAS_PCH_LPT(dev)) {
> +		/* Program iCLKIP */
> +		lpt_program_iclkip(crtc);
>  	}
>  
>  	/* set transcoder timing, panel must allow it */
> -- 
> 1.7.10
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [PATCH 24/29] drm/i915: program iCLKIP on Lynx Point

[Eugeni Dodonov]

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

On Sun, Apr 15, 2012 at 20:49, Daniel Vetter <daniel@ffwll.ch> wrote:
>
> I'm honestly not too happy with this table, because somewhere in there
> we'll have an annoying type, and there's almost zero chance we'll ever
> find that. So I prefer if we can replicate the pixel clock computation
> from some stupid excel sheet ...
>

The latest specs say that the table is the recommended way for configuring
known clocks settings, for both iCLKIP and WR PLL, and the
algorithm/formula should be used as fallback only.

But I'll add them as well. One never knows when a new and previously
unthinkable mode pops up :).

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

[-- Attachment #1.2: Type: text/html, Size: 1035 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 24/29] drm/i915: program iCLKIP on Lynx Point

[Chris Wilson]

On Sun, 15 Apr 2012 21:44:15 -0300, Eugeni Dodonov <eugeni@dodonov.net> wrote:
> On Sun, Apr 15, 2012 at 20:49, Daniel Vetter <daniel@ffwll.ch> wrote:
> >
> > I'm honestly not too happy with this table, because somewhere in there
> > we'll have an annoying type, and there's almost zero chance we'll ever
> > find that. So I prefer if we can replicate the pixel clock computation
> > from some stupid excel sheet ...
> >
> 
> The latest specs say that the table is the recommended way for configuring
> known clocks settings, for both iCLKIP and WR PLL, and the
> algorithm/formula should be used as fallback only.

Which implies that they do not match the values generated by the
algorithm. If you are going to keep the table, at least trim it so that
we aren't wasting bytes in unused precised. And split into the distinct
auxdivider, etc.
 
> But I'll add them as well. One never knows when a new and previously
> unthinkable mode pops up :).

Indeed. I'd throw it back at the hardware people, what are they doing in
kilobytes of data that can't be down in a few bytes of algorithm?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH 24/29] drm/i915: program iCLKIP on Lynx Point

[Daniel Vetter]

On Mon, Apr 16, 2012 at 09:26:40AM +0100, Chris Wilson wrote:
> On Sun, 15 Apr 2012 21:44:15 -0300, Eugeni Dodonov <eugeni@dodonov.net> wrote:
> > On Sun, Apr 15, 2012 at 20:49, Daniel Vetter <daniel@ffwll.ch> wrote:
> > >
> > > I'm honestly not too happy with this table, because somewhere in there
> > > we'll have an annoying type, and there's almost zero chance we'll ever
> > > find that. So I prefer if we can replicate the pixel clock computation
> > > from some stupid excel sheet ...
> > >
> > 
> > The latest specs say that the table is the recommended way for configuring
> > known clocks settings, for both iCLKIP and WR PLL, and the
> > algorithm/formula should be used as fallback only.
> 
> Which implies that they do not match the values generated by the
> algorithm. If you are going to keep the table, at least trim it so that
> we aren't wasting bytes in unused precised. And split into the distinct
> auxdivider, etc.

Well, if the algo and the table do not match, I want to know where.
Because even worse than a table is a table+algo - practically guarantees a
bug in the algo because it's only ever used as a fallback.

> > But I'll add them as well. One never knows when a new and previously
> > unthinkable mode pops up :).
> 
> Indeed. I'd throw it back at the hardware people, what are they doing in
> kilobytes of data that can't be down in a few bytes of algorithm?

Safe for a good reason I'd really prefer the algo over kilobytes of tables
...
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH 25/29] drm/i915: detect digital outputs on Haswell

[Eugeni Dodonov]

Digital port detection on Haswell is indicated by the presence of a bit in
DDI_BUF_CTL for port A, and by a different register for ports B, C and D.
So we check for those bits during the initialization time and let the hdmi
function know about those.

Note that this bit does not indicates whether the output is DP or HDMI.
However, the DDI buffers can be programmed in a way that is shared between
DP/HDMI and FDI/HDMI except for PORT E.

So for now, we detect those digital outputs as being HDMI, but proper DP
support is still pending.

Note that DDI A can only drive eDP, so we do not handle it here for hdmi
initialization.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index bdc22f5..1524966 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8743,26 +8743,45 @@ static void intel_setup_outputs(struct drm_device *dev)
 	if (HAS_PCH_SPLIT(dev)) {
 		int found;
 
-		if (I915_READ(HDMIB) & PORT_DETECTED) {
-			/* PCH SDVOB multiplex with HDMIB */
-			found = intel_sdvo_init(dev, PCH_SDVOB, true);
-			if (!found)
-				intel_hdmi_init(dev, HDMIB);
-			if (!found && (I915_READ(PCH_DP_B) & DP_DETECTED))
-				intel_dp_init(dev, PCH_DP_B);
-		}
+		if (IS_HASWELL(dev)) {
+			/* Haswell uses DDI functions to detect digital outputs */
+			found = I915_READ(DDI_BUF_CTL_A) & DDI_INIT_DISPLAY_DETECTED;
+			/* DDI A only supports eDP */
+			if (found)
+				DRM_INFO("Found digital output on DDI port A\n");
+
+			/* DDI B, C and D detection is indicated by the SFUSE_STRAP
+			 * register */
+			found = I915_READ(SFUSE_STRAP);
+
+			if (found & SFUSE_STRAP_DDIB_DETECTED)
+				intel_hdmi_init(dev, DDI_BUF_CTL(PORT_B));
+			if (found & SFUSE_STRAP_DDIC_DETECTED)
+				intel_hdmi_init(dev, DDI_BUF_CTL(PORT_C));
+			if (found & SFUSE_STRAP_DDID_DETECTED)
+				intel_hdmi_init(dev, DDI_BUF_CTL(PORT_D));
+		} else {
+			if (I915_READ(HDMIB) & PORT_DETECTED) {
+				/* PCH SDVOB multiplex with HDMIB */
+				found = intel_sdvo_init(dev, PCH_SDVOB, true);
+				if (!found)
+					intel_hdmi_init(dev, HDMIB);
+				if (!found && (I915_READ(PCH_DP_B) & DP_DETECTED))
+					intel_dp_init(dev, PCH_DP_B);
+			}
 
-		if (I915_READ(HDMIC) & PORT_DETECTED)
-			intel_hdmi_init(dev, HDMIC);
+			if (I915_READ(HDMIC) & PORT_DETECTED)
+				intel_hdmi_init(dev, HDMIC);
 
-		if (I915_READ(HDMID) & PORT_DETECTED)
-			intel_hdmi_init(dev, HDMID);
+			if (I915_READ(HDMID) & PORT_DETECTED)
+				intel_hdmi_init(dev, HDMID);
 
-		if (I915_READ(PCH_DP_C) & DP_DETECTED)
-			intel_dp_init(dev, PCH_DP_C);
+			if (I915_READ(PCH_DP_C) & DP_DETECTED)
+				intel_dp_init(dev, PCH_DP_C);
 
-		if (!dpd_is_edp && (I915_READ(PCH_DP_D) & DP_DETECTED))
-			intel_dp_init(dev, PCH_DP_D);
+			if (!dpd_is_edp && (I915_READ(PCH_DP_D) & DP_DETECTED))
+				intel_dp_init(dev, PCH_DP_D);
+		}
 
 	} else if (SUPPORTS_DIGITAL_OUTPUTS(dev)) {
 		bool found = false;
-- 
1.7.10

Re: [PATCH 25/29] drm/i915: detect digital outputs on Haswell

[Chris Wilson]

On Fri, 13 Apr 2012 17:09:01 -0300, Eugeni Dodonov <eugeni.dodonov@intel.com> wrote:
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index bdc22f5..1524966 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8743,26 +8743,45 @@ static void intel_setup_outputs(struct drm_device *dev)
>  	if (HAS_PCH_SPLIT(dev)) {
>  		int found;
>  
> -		if (I915_READ(HDMIB) & PORT_DETECTED) {
> -			/* PCH SDVOB multiplex with HDMIB */
> -			found = intel_sdvo_init(dev, PCH_SDVOB, true);
> -			if (!found)
> -				intel_hdmi_init(dev, HDMIB);
> -			if (!found && (I915_READ(PCH_DP_B) & DP_DETECTED))
> -				intel_dp_init(dev, PCH_DP_B);
> -		}
> +		if (IS_HASWELL(dev)) {

We're starting to get to ridiculous levels of indention. Break the PCH
detection of SDVO/HDMI outputs into its own routine, and perhaps further
down in architectures?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH 25/29] drm/i915: detect digital outputs on Haswell

[Eugeni Dodonov]

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

On Fri, Apr 13, 2012 at 18:17, Chris Wilson <chris@chris-wilson.co.uk>wrote:

> We're starting to get to ridiculous levels of indention. Break the PCH
> detection of SDVO/HDMI outputs into its own routine, and perhaps further
> down in architectures?
>

Yes, both intel_display and intel_hdmi get too overcomplex with those
patches :(.

I haven't done the split in those series because I thought that the plan
was to land those VLV/HSW patches before doing the big display refactoring
we discussed some weeks ago. But I could certainly start doing it.

Daniel, what do you think would best from your dinq maintainership point of
view - refactor those bits here and in other big patches of this series
(fdi and hdmi ones) and then resend all the patches; or have them as is and
do the big refactoring for everything after that?

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

[-- Attachment #1.2: Type: text/html, Size: 1269 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 25/29] drm/i915: detect digital outputs on Haswell

[Daniel Vetter]

On Fri, Apr 13, 2012 at 09:37:44PM -0300, Eugeni Dodonov wrote:
> On Fri, Apr 13, 2012 at 18:17, Chris Wilson <chris@chris-wilson.co.uk>wrote:
> 
> > We're starting to get to ridiculous levels of indention. Break the PCH
> > detection of SDVO/HDMI outputs into its own routine, and perhaps further
> > down in architectures?
> >
> 
> Yes, both intel_display and intel_hdmi get too overcomplex with those
> patches :(.
> 
> I haven't done the split in those series because I thought that the plan
> was to land those VLV/HSW patches before doing the big display refactoring
> we discussed some weeks ago. But I could certainly start doing it.
> 
> Daniel, what do you think would best from your dinq maintainership point of
> view - refactor those bits here and in other big patches of this series
> (fdi and hdmi ones) and then resend all the patches; or have them as is and
> do the big refactoring for everything after that?

I this specific case I think we simply need to add an IS_HASWELL check
before the HAS_PCH_SPLIT check - hsw shares zero output detection code in
this block with previous pch_split chips, so the indentation seems to be
pointless.
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

[PATCH 26/29] drm/i915: add support for DDI-controlled digital outputs

[Eugeni Dodonov]

Those are driven by DDIs on Haswell architecture, so we need to keep track
of which DDI is being used on each output.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
---
 drivers/gpu/drm/i915/intel_hdmi.c |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
index 0978fb7..09dab76 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -41,6 +41,7 @@ struct intel_hdmi {
 	struct intel_encoder base;
 	u32 sdvox_reg;
 	int ddc_bus;
+	int ddi_port;
 	uint32_t color_range;
 	bool has_hdmi_sink;
 	bool has_audio;
@@ -614,6 +615,24 @@ void intel_hdmi_init(struct drm_device *dev, int sdvox_reg)
 		intel_encoder->clone_mask = (1 << INTEL_HDMIF_CLONE_BIT);
 		intel_hdmi->ddc_bus = GMBUS_PORT_DPD;
 		dev_priv->hotplug_supported_mask |= HDMID_HOTPLUG_INT_STATUS;
+	} else if (sdvox_reg == DDI_BUF_CTL(PORT_B)) {
+		DRM_DEBUG_DRIVER("LPT: detected output on DDI B\n");
+		intel_encoder->clone_mask = (1 << INTEL_HDMIB_CLONE_BIT);
+		intel_hdmi->ddc_bus = GMBUS_PORT_DPB;
+		intel_hdmi->ddi_port = PORT_B;
+		dev_priv->hotplug_supported_mask |= HDMIB_HOTPLUG_INT_STATUS;
+	} else if (sdvox_reg == DDI_BUF_CTL(PORT_C)) {
+		DRM_DEBUG_DRIVER("LPT: detected output on DDI C\n");
+		intel_encoder->clone_mask = (1 << INTEL_HDMIC_CLONE_BIT);
+		intel_hdmi->ddc_bus = GMBUS_PORT_DPC;
+		intel_hdmi->ddi_port = PORT_C;
+		dev_priv->hotplug_supported_mask |= HDMIC_HOTPLUG_INT_STATUS;
+	} else if (sdvox_reg == DDI_BUF_CTL(PORT_D)) {
+		DRM_DEBUG_DRIVER("LPT: detected output on DDI D\n");
+		intel_encoder->clone_mask = (1 << INTEL_HDMID_CLONE_BIT);
+		intel_hdmi->ddc_bus = GMBUS_PORT_DPD;
+		intel_hdmi->ddi_port = PORT_D;
+		dev_priv->hotplug_supported_mask |= HDMID_HOTPLUG_INT_STATUS;
 	} else {
 		DRM_DEBUG_DRIVER("Unknown sdvox register %x\n", sdvox_reg);
 	}
-- 
1.7.10

[PATCH 27/29] drm/i915: add WR PLL programming table

[Eugeni Dodonov]

This table is used for programming WR PLL clocks, used by HDMI and DVI outputs.
I split it into a separate patch to simplify the HDMI enabling patch which was
getting huge.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
---
 drivers/gpu/drm/i915/intel_hdmi.c |  388 +++++++++++++++++++++++++++++++++++++
 1 file changed, 388 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
index 09dab76..d2f278f 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -277,6 +277,394 @@ static void intel_hdmi_set_spd_infoframe(struct drm_encoder *encoder)
 	intel_set_infoframe(encoder, &spd_if);
 }
 
+/* WRPLL clock dividers */
+struct wrpll_tmds_clock {
+	u32 clock;
+	u16 p;		/* Post divider */
+	u16 n2;		/* Feedback divider */
+	u16 r2;		/* Reference divider */
+};
+
+/* Table of matching values for WRPLL clocks programming for each frequency */
+static const struct wrpll_tmds_clock wrpll_tmds_clock_table[] = {
+	{19750,	38,	25,	18},
+	{20000,	48,	32,	18},
+	{21000,	36,	21,	15},
+	{21912,	42,	29,	17},
+	{22000,	36,	22,	15},
+	{23000,	36,	23,	15},
+	{23500,	40,	40,	23},
+	{23750,	26,	16,	14},
+	{23750,	26,	16,	14},
+	{24000,	36,	24,	15},
+	{25000,	36,	25,	15},
+	{25175,	26,	40,	33},
+	{25200,	30,	21,	15},
+	{26000,	36,	26,	15},
+	{27000,	30,	21,	14},
+	{27027,	18,	100,	111},
+	{27500,	30,	29,	19},
+	{28000,	34,	30,	17},
+	{28320,	26,	30,	22},
+	{28322,	32,	42,	25},
+	{28750,	24,	23,	18},
+	{29000,	30,	29,	18},
+	{29750,	32,	30,	17},
+	{30000,	30,	25,	15},
+	{30750,	30,	41,	24},
+	{31000,	30,	31,	18},
+	{31500,	30,	28,	16},
+	{32000,	30,	32,	18},
+	{32500,	28,	32,	19},
+	{33000,	24,	22,	15},
+	{34000,	28,	30,	17},
+	{35000,	26,	32,	19},
+	{35500,	24,	30,	19},
+	{36000,	26,	26,	15},
+	{36750,	26,	46,	26},
+	{37000,	24,	23,	14},
+	{37762,	22,	40,	26},
+	{37800,	20,	21,	15},
+	{38000,	24,	27,	16},
+	{38250,	24,	34,	20},
+	{39000,	24,	26,	15},
+	{40000,	24,	32,	18},
+	{40500,	20,	21,	14},
+	{40541,	22,	147,	89},
+	{40750,	18,	19,	14},
+	{41000,	16,	17,	14},
+	{41500,	22,	44,	26},
+	{41540,	22,	44,	26},
+	{42000,	18,	21,	15},
+	{42500,	22,	45,	26},
+	{43000,	20,	43,	27},
+	{43163,	20,	24,	15},
+	{44000,	18,	22,	15},
+	{44900,	20,	108,	65},
+	{45000,	20,	25,	15},
+	{45250,	20,	52,	31},
+	{46000,	18,	23,	15},
+	{46750,	20,	45,	26},
+	{47000,	20,	40,	23},
+	{48000,	18,	24,	15},
+	{49000,	18,	49,	30},
+	{49500,	16,	22,	15},
+	{50000,	18,	25,	15},
+	{50500,	18,	32,	19},
+	{51000,	18,	34,	20},
+	{52000,	18,	26,	15},
+	{52406,	14,	34,	25},
+	{53000,	16,	22,	14},
+	{54000,	16,	24,	15},
+	{54054,	16,	173,	108},
+	{54500,	14,	24,	17},
+	{55000,	12,	22,	18},
+	{56000,	14,	45,	31},
+	{56250,	16,	25,	15},
+	{56750,	14,	25,	17},
+	{57000,	16,	27,	16},
+	{58000,	16,	43,	25},
+	{58250,	16,	38,	22},
+	{58750,	16,	40,	23},
+	{59000,	14,	26,	17},
+	{59341,	14,	40,	26},
+	{59400,	16,	44,	25},
+	{60000,	16,	32,	18},
+	{60500,	12,	39,	29},
+	{61000,	14,	49,	31},
+	{62000,	14,	37,	23},
+	{62250,	14,	42,	26},
+	{63000,	12,	21,	15},
+	{63500,	14,	28,	17},
+	{64000,	12,	27,	19},
+	{65000,	14,	32,	19},
+	{65250,	12,	29,	20},
+	{65500,	12,	32,	22},
+	{66000,	12,	22,	15},
+	{66667,	14,	38,	22},
+	{66750,	10,	21,	17},
+	{67000,	14,	33,	19},
+	{67750,	14,	58,	33},
+	{68000,	14,	30,	17},
+	{68179,	14,	46,	26},
+	{68250,	14,	46,	26},
+	{69000,	12,	23,	15},
+	{70000,	12,	28,	18},
+	{71000,	12,	30,	19},
+	{72000,	12,	24,	15},
+	{73000,	10,	23,	17},
+	{74000,	12,	23,	14},
+	{74176,	8,	100,	91},
+	{74250,	10,	22,	16},
+	{74481,	12,	43,	26},
+	{74500,	10,	29,	21},
+	{75000,	12,	25,	15},
+	{75250,	10,	39,	28},
+	{76000,	12,	27,	16},
+	{77000,	12,	53,	31},
+	{78000,	12,	26,	15},
+	{78750,	12,	28,	16},
+	{79000,	10,	38,	26},
+	{79500,	10,	28,	19},
+	{80000,	12,	32,	18},
+	{81000,	10,	21,	14},
+	{81081,	6,	100,	111},
+	{81624,	8,	29,	24},
+	{82000,	8,	17,	14},
+	{83000,	10,	40,	26},
+	{83950,	10,	28,	18},
+	{84000,	10,	28,	18},
+	{84750,	6,	16,	17},
+	{85000,	6,	17,	18},
+	{85250,	10,	30,	19},
+	{85750,	10,	27,	17},
+	{86000,	10,	43,	27},
+	{87000,	10,	29,	18},
+	{88000,	10,	44,	27},
+	{88500,	10,	41,	25},
+	{89000,	10,	28,	17},
+	{89012,	6,	90,	91},
+	{89100,	10,	33,	20},
+	{90000,	10,	25,	15},
+	{91000,	10,	32,	19},
+	{92000,	10,	46,	27},
+	{93000,	10,	31,	18},
+	{94000,	10,	40,	23},
+	{94500,	10,	28,	16},
+	{95000,	10,	44,	25},
+	{95654,	10,	39,	22},
+	{95750,	10,	39,	22},
+	{96000,	10,	32,	18},
+	{97000,	8,	23,	16},
+	{97750,	8,	42,	29},
+	{98000,	8,	45,	31},
+	{99000,	8,	22,	15},
+	{99750,	8,	34,	23},
+	{100000,	6,	20,	18},
+	{100500,	6,	19,	17},
+	{101000,	6,	37,	33},
+	{101250,	8,	21,	14},
+	{102000,	6,	17,	15},
+	{102250,	6,	25,	22},
+	{103000,	8,	29,	19},
+	{104000,	8,	37,	24},
+	{105000,	8,	28,	18},
+	{106000,	8,	22,	14},
+	{107000,	8,	46,	29},
+	{107214,	8,	27,	17},
+	{108000,	8,	24,	15},
+	{108108,	8,	173,	108},
+	{109000,	6,	23,	19},
+	{109000,	6,	23,	19},
+	{110000,	6,	22,	18},
+	{110013,	6,	22,	18},
+	{110250,	8,	49,	30},
+	{110500,	8,	36,	22},
+	{111000,	8,	23,	14},
+	{111264,	8,	150,	91},
+	{111375,	8,	33,	20},
+	{112000,	8,	63,	38},
+	{112500,	8,	25,	15},
+	{113100,	8,	57,	34},
+	{113309,	8,	42,	25},
+	{114000,	8,	27,	16},
+	{115000,	6,	23,	18},
+	{116000,	8,	43,	25},
+	{117000,	8,	26,	15},
+	{117500,	8,	40,	23},
+	{118000,	6,	38,	29},
+	{119000,	8,	30,	17},
+	{119500,	8,	46,	26},
+	{119651,	8,	39,	22},
+	{120000,	8,	32,	18},
+	{121000,	6,	39,	29},
+	{121250,	6,	31,	23},
+	{121750,	6,	23,	17},
+	{122000,	6,	42,	31},
+	{122614,	6,	30,	22},
+	{123000,	6,	41,	30},
+	{123379,	6,	37,	27},
+	{124000,	6,	51,	37},
+	{125000,	6,	25,	18},
+	{125250,	4,	13,	14},
+	{125750,	4,	27,	29},
+	{126000,	6,	21,	15},
+	{127000,	6,	24,	17},
+	{127250,	6,	41,	29},
+	{128000,	6,	27,	19},
+	{129000,	6,	43,	30},
+	{129859,	4,	25,	26},
+	{130000,	6,	26,	18},
+	{130250,	6,	42,	29},
+	{131000,	6,	32,	22},
+	{131500,	6,	38,	26},
+	{131850,	6,	41,	28},
+	{132000,	6,	22,	15},
+	{132750,	6,	28,	19},
+	{133000,	6,	34,	23},
+	{133330,	6,	37,	25},
+	{134000,	6,	61,	41},
+	{135000,	6,	21,	14},
+	{135250,	6,	167,	111},
+	{136000,	6,	62,	41},
+	{137000,	6,	35,	23},
+	{138000,	6,	23,	15},
+	{138500,	6,	40,	26},
+	{138750,	6,	37,	24},
+	{139000,	6,	34,	22},
+	{139050,	6,	34,	22},
+	{139054,	6,	34,	22},
+	{140000,	6,	28,	18},
+	{141000,	6,	36,	23},
+	{141500,	6,	22,	14},
+	{142000,	6,	30,	19},
+	{143000,	6,	27,	17},
+	{143472,	4,	17,	16},
+	{144000,	6,	24,	15},
+	{145000,	6,	29,	18},
+	{146000,	6,	47,	29},
+	{146250,	6,	26,	16},
+	{147000,	6,	49,	30},
+	{147891,	6,	23,	14},
+	{148000,	6,	23,	14},
+	{148250,	6,	28,	17},
+	{148352,	4,	100,	91},
+	{148500,	6,	33,	20},
+	{149000,	6,	48,	29},
+	{150000,	6,	25,	15},
+	{151000,	4,	19,	17},
+	{152000,	6,	27,	16},
+	{152280,	6,	44,	26},
+	{153000,	6,	34,	20},
+	{154000,	6,	53,	31},
+	{155000,	6,	31,	18},
+	{155250,	6,	50,	29},
+	{155750,	6,	45,	26},
+	{156000,	6,	26,	15},
+	{157000,	6,	61,	35},
+	{157500,	6,	28,	16},
+	{158000,	6,	65,	37},
+	{158250,	6,	44,	25},
+	{159000,	6,	53,	30},
+	{159500,	6,	39,	22},
+	{160000,	6,	32,	18},
+	{161000,	4,	31,	26},
+	{162000,	4,	18,	15},
+	{162162,	4,	131,	109},
+	{162500,	4,	53,	44},
+	{163000,	4,	29,	24},
+	{164000,	4,	17,	14},
+	{165000,	4,	22,	18},
+	{166000,	4,	32,	26},
+	{167000,	4,	26,	21},
+	{168000,	4,	46,	37},
+	{169000,	4,	104,	83},
+	{169128,	4,	64,	51},
+	{169500,	4,	39,	31},
+	{170000,	4,	34,	27},
+	{171000,	4,	19,	15},
+	{172000,	4,	51,	40},
+	{172750,	4,	32,	25},
+	{172800,	4,	32,	25},
+	{173000,	4,	41,	32},
+	{174000,	4,	49,	38},
+	{174787,	4,	22,	17},
+	{175000,	4,	35,	27},
+	{176000,	4,	30,	23},
+	{177000,	4,	38,	29},
+	{178000,	4,	29,	22},
+	{178500,	4,	37,	28},
+	{179000,	4,	53,	40},
+	{179500,	4,	73,	55},
+	{180000,	4,	20,	15},
+	{181000,	4,	55,	41},
+	{182000,	4,	31,	23},
+	{183000,	4,	42,	31},
+	{184000,	4,	30,	22},
+	{184750,	4,	26,	19},
+	{185000,	4,	37,	27},
+	{186000,	4,	51,	37},
+	{187000,	4,	36,	26},
+	{188000,	4,	32,	23},
+	{189000,	4,	21,	15},
+	{190000,	4,	38,	27},
+	{190960,	4,	41,	29},
+	{191000,	4,	41,	29},
+	{192000,	4,	27,	19},
+	{192250,	4,	37,	26},
+	{193000,	4,	20,	14},
+	{193250,	4,	53,	37},
+	{194000,	4,	23,	16},
+	{194208,	4,	23,	16},
+	{195000,	4,	26,	18},
+	{196000,	4,	45,	31},
+	{197000,	4,	35,	24},
+	{197750,	4,	41,	28},
+	{198000,	4,	22,	15},
+	{198500,	4,	25,	17},
+	{199000,	4,	28,	19},
+	{200000,	4,	37,	25},
+	{201000,	4,	61,	41},
+	{202000,	4,	112,	75},
+	{202500,	4,	21,	14},
+	{203000,	4,	146,	97},
+	{204000,	4,	62,	41},
+	{204750,	4,	44,	29},
+	{205000,	4,	38,	25},
+	{206000,	4,	29,	19},
+	{207000,	4,	23,	15},
+	{207500,	4,	40,	26},
+	{208000,	4,	37,	24},
+	{208900,	4,	48,	31},
+	{209000,	4,	48,	31},
+	{209250,	4,	31,	20},
+	{210000,	4,	28,	18},
+	{211000,	4,	25,	16},
+	{212000,	4,	22,	14},
+	{213000,	4,	30,	19},
+	{213750,	4,	38,	24},
+	{214000,	4,	46,	29},
+	{214750,	4,	35,	22},
+	{215000,	4,	43,	27},
+	{216000,	4,	24,	15},
+	{217000,	4,	37,	23},
+	{218000,	4,	42,	26},
+	{218250,	4,	42,	26},
+	{218750,	4,	34,	21},
+	{219000,	4,	47,	29},
+	{219000,	4,	47,	29},
+	{220000,	4,	44,	27},
+	{220640,	4,	49,	30},
+	{220750,	4,	36,	22},
+	{221000,	4,	36,	22},
+	{222000,	4,	23,	14},
+	{222525,	4,	28,	17},
+	{222750,	4,	33,	20},
+	{227000,	4,	37,	22},
+	{230250,	4,	29,	17},
+	{233500,	4,	38,	22},
+	{235000,	4,	40,	23},
+	{238000,	4,	30,	17},
+	{241500,	2,	17,	19},
+	{245250,	2,	20,	22},
+	{247750,	2,	22,	24},
+	{253250,	2,	15,	16},
+	{256250,	2,	18,	19},
+	{262500,	2,	31,	32},
+	{267250,	2,	66,	67},
+	{268500,	2,	94,	95},
+	{270000,	2,	14,	14},
+	{272500,	2,	77,	76},
+	{273750,	2,	57,	56},
+	{280750,	2,	24,	23},
+	{281250,	2,	23,	22},
+	{286000,	2,	17,	16},
+	{291750,	2,	26,	24},
+	{296703,	2,	56,	51},
+	{297000,	2,	22,	20},
+	{298000,	2,	21,	19},
+};
+
 static void intel_hdmi_mode_set(struct drm_encoder *encoder,
 				struct drm_display_mode *mode,
 				struct drm_display_mode *adjusted_mode)
-- 
1.7.10

[PATCH 28/29] drm/i915: prepare HDMI link for Haswell

[Eugeni Dodonov]

On Haswell, we need to properly train the DDI buffers prior to enabling
HDMI, and enable the required clocks with correct dividers for the desired
frequency.

Also, we cannot simple reuse HDMI routines from previous generations of
GPU, as most of HDMI-specific stuff is being done via the DDI port
programming instead of HDMI-specific registers.

This commit take advantage of the WR PLL clock table which is in a
separate (previous) commit to select the right divisors for each mode.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
---
 drivers/gpu/drm/i915/intel_hdmi.c |  129 ++++++++++++++++++++++++++++++++++++-
 1 file changed, 128 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
index d2f278f..e2b8847 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -665,6 +665,98 @@ static const struct wrpll_tmds_clock wrpll_tmds_clock_table[] = {
 	{298000,	2,	21,	19},
 };
 
+static void intel_hdmi_mode_set_hsw(struct drm_encoder *encoder,
+				struct drm_display_mode *mode,
+				struct drm_display_mode *adjusted_mode)
+{
+	struct drm_device *dev = encoder->dev;
+	struct drm_i915_private *dev_priv = dev->dev_private;
+	struct drm_crtc *crtc = encoder->crtc;
+	struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+	struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
+	int port = intel_hdmi->ddi_port;
+	int pipe = intel_crtc->pipe;
+	int p, n2, r2, valid=0;
+	u32 temp, i;
+
+	/* On Haswell, we need to enable the clocks and prepare DDI function to
+	 * work in HDMI mode for this pipe.
+	 */
+	DRM_DEBUG_KMS("Preparing HDMI DDI mode for Haswell on port %c, pipe %c\n", port_name(port), pipe_name(pipe));
+
+	for (i=0; i < ARRAY_SIZE(wrpll_tmds_clock_table); i++) {
+		if (crtc->mode.clock == wrpll_tmds_clock_table[i].clock) {
+			p = wrpll_tmds_clock_table[i].p;
+			n2 = wrpll_tmds_clock_table[i].n2;
+			r2 = wrpll_tmds_clock_table[i].r2;
+
+			DRM_INFO("Found clock settings for %dKHz refresh rate: p=%d, n2=%d, r2=%d\n",
+					crtc->mode.clock,
+					p, n2, r2);
+
+			valid = 1;
+			break;
+		}
+	}
+
+	if (!valid) {
+		DRM_ERROR("Unable to find WRPLL clock settings for %dKHz refresh rate\n",
+				crtc->mode.clock);
+		return;
+	}
+
+	/* Enable LCPLL if disabled */
+	temp = I915_READ(LCPLL_CTL);
+	if (temp & LCPLL_PLL_DISABLE)
+		I915_WRITE(LCPLL_CTL,
+				temp & ~LCPLL_PLL_DISABLE);
+
+	/* Configure WR PLL 1, program the correct divider values for
+	 * the desired frequency and wait for warmup */
+	I915_WRITE(WRPLL_CTL1,
+			WRPLL_PLL_ENABLE |
+			WRPLL_PLL_SELECT_LCPLL_2700 |
+			WRPLL_DIVIDER_REFERENCE(r2) |
+			WRPLL_DIVIDER_FEEDBACK(n2) |
+			WRPLL_DIVIDER_POST(p));
+
+	udelay(20);
+
+	/* Use WRPLL1 clock to drive the output to the port, and tell the pipe to use
+	 * this port for connection.
+	 */
+	I915_WRITE(PORT_CLK_SEL(port),
+			PORT_CLK_SEL_WRPLL1);
+	I915_WRITE(PIPE_CLK_SEL(pipe),
+			PIPE_CLK_SEL_PORT(port));
+
+	udelay(20);
+
+	if (intel_hdmi->has_audio) {
+		/* Proper support for digital audio needs a new logic and a new set
+		 * of registers, so we leave it for future patch bombing.
+		 */
+		DRM_DEBUG_DRIVER("HDMI audio on pipe %c not yet supported on DDI\n",
+				 pipe_name(intel_crtc->pipe));
+	}
+
+	/* Enable PIPE_DDI_FUNC_CTL for the pipe to work in HDMI mode */
+	temp = I915_READ(DDI_FUNC_CTL(pipe));
+	temp &= ~PIPE_DDI_PORT_MASK;
+	temp &= ~PIPE_DDI_BPC_12;
+	temp |= PIPE_DDI_SELECT_PORT(port) |
+			PIPE_DDI_MODE_SELECT_HDMI |
+			((intel_crtc->bpp > 24) ?
+				PIPE_DDI_BPC_12 :
+				PIPE_DDI_BPC_8) |
+			PIPE_DDI_FUNC_ENABLE;
+
+	I915_WRITE(DDI_FUNC_CTL(pipe), temp);
+
+	intel_hdmi_set_avi_infoframe(encoder);
+	intel_hdmi_set_spd_infoframe(encoder);
+}
+
 static void intel_hdmi_mode_set(struct drm_encoder *encoder,
 				struct drm_display_mode *mode,
 				struct drm_display_mode *adjusted_mode)
@@ -713,6 +805,30 @@ static void intel_hdmi_mode_set(struct drm_encoder *encoder,
 	intel_hdmi_set_spd_infoframe(encoder);
 }
 
+static void intel_hdmi_dpms_hsw(struct drm_encoder *encoder, int mode)
+{
+	struct drm_device *dev = encoder->dev;
+	struct drm_i915_private *dev_priv = dev->dev_private;
+	struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
+	int port = intel_hdmi->ddi_port;
+	u32 temp;
+
+	temp = I915_READ(DDI_BUF_CTL(port));
+
+	if (mode != DRM_MODE_DPMS_ON) {
+		temp &= ~DDI_BUF_CTL_ENABLE;
+	} else {
+		temp |= DDI_BUF_CTL_ENABLE;
+	}
+
+	/* Enable DDI_BUF_CTL. In HDMI/DVI mode, the port width,
+	 * and swing/emphasis values are ignored so nothing special needs
+	 * to be done besides enabling the port.
+	 */
+	I915_WRITE(DDI_BUF_CTL(port),
+			temp);
+}
+
 static void intel_hdmi_dpms(struct drm_encoder *encoder, int mode)
 {
 	struct drm_device *dev = encoder->dev;
@@ -914,6 +1030,14 @@ static void intel_hdmi_destroy(struct drm_connector *connector)
 	kfree(connector);
 }
 
+static const struct drm_encoder_helper_funcs intel_hdmi_helper_funcs_hsw = {
+	.dpms = intel_hdmi_dpms_hsw,
+	.mode_fixup = intel_hdmi_mode_fixup,
+	.prepare = intel_encoder_prepare,
+	.mode_set = intel_hdmi_mode_set_hsw,
+	.commit = intel_encoder_commit,
+};
+
 static const struct drm_encoder_helper_funcs intel_hdmi_helper_funcs = {
 	.dpms = intel_hdmi_dpms,
 	.mode_fixup = intel_hdmi_mode_fixup,
@@ -1044,7 +1168,10 @@ void intel_hdmi_init(struct drm_device *dev, int sdvox_reg)
 			I915_WRITE(TVIDEO_DIP_CTL(i), 0);
 	}
 
-	drm_encoder_helper_add(&intel_encoder->base, &intel_hdmi_helper_funcs);
+	if (IS_HASWELL(dev))
+		drm_encoder_helper_add(&intel_encoder->base, &intel_hdmi_helper_funcs_hsw);
+	else
+		drm_encoder_helper_add(&intel_encoder->base, &intel_hdmi_helper_funcs);
 
 	intel_hdmi_add_properties(intel_hdmi, connector);
 
-- 
1.7.10

[PATCH 29/29] drm/i915: hook Haswell devices in place

[Eugeni Dodonov]

This patch enables i915 driver to handle Haswell devices. It should go in
last, when things are working stable enough.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
---
 drivers/char/agp/intel-agp.c    |    4 ++++
 drivers/gpu/drm/i915/i915_drv.c |    7 +++++++
 2 files changed, 11 insertions(+)

diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index 74c2d92..764f70c 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -908,6 +908,10 @@ static struct pci_device_id agp_intel_pci_table[] = {
 	ID(PCI_DEVICE_ID_INTEL_IVYBRIDGE_M_HB),
 	ID(PCI_DEVICE_ID_INTEL_IVYBRIDGE_S_HB),
 	ID(PCI_DEVICE_ID_INTEL_VALLEYVIEW_HB),
+	ID(PCI_DEVICE_ID_INTEL_HASWELL_HB),
+	ID(PCI_DEVICE_ID_INTEL_HASWELL_M_HB),
+	ID(PCI_DEVICE_ID_INTEL_HASWELL_S_HB),
+	ID(PCI_DEVICE_ID_INTEL_HASWELL_E_HB),
 	{ }
 };
 
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ccfdc81..9282bd0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -345,6 +345,13 @@ static const struct pci_device_id pciidlist[] = {		/* aka */
 	INTEL_VGA_DEVICE(0x0162, &intel_ivybridge_d_info), /* GT2 desktop */
 	INTEL_VGA_DEVICE(0x015a, &intel_ivybridge_d_info), /* GT1 server */
 	INTEL_VGA_DEVICE(0x016a, &intel_ivybridge_d_info), /* GT2 server */
+	INTEL_VGA_DEVICE(0x0402, &intel_haswell_d_info), /* GT1 desktop */
+	INTEL_VGA_DEVICE(0x0412, &intel_haswell_d_info), /* GT2 desktop */
+	INTEL_VGA_DEVICE(0x040a, &intel_haswell_d_info), /* GT1 server */
+	INTEL_VGA_DEVICE(0x041a, &intel_haswell_d_info), /* GT2 server */
+	INTEL_VGA_DEVICE(0x0406, &intel_haswell_m_info), /* GT1 mobile */
+	INTEL_VGA_DEVICE(0x0416, &intel_haswell_m_info), /* GT2 mobile */
+	INTEL_VGA_DEVICE(0x0c16, &intel_haswell_d_info), /* SDV */
 	{0, 0, 0}
 };
 
-- 
1.7.10

Re: [PATCH 00/29] Haswell round 3

[Daniel Vetter]

On Fri, Apr 13, 2012 at 05:08:36PM -0300, Eugeni Dodonov wrote:
> Hi forks,
> 
> Just in time for everyone's weekend, here comes the 3rd round of patches on
> Haswell.
> 
> As major highlights, it also adds support for HDMI/DVI outputs and multi-head
> modes (I tried with VGA and HDMI).
> 
> Other than that, it is the same patches with comments from the past round
> addressed (SBI locking support, proper WM calculation, better PCH items
> detection, and so on).
> 
> Daniel, I think that the bits definitions, power wells, clocks programming, and
> modesetting for both FDI and HDMI modes should be good to go unless someone
> spots additional issues with them - so please, all of you who have something to
> say about them, say it now and bikeshed as you please :).

I've picked up a few more patches I couldn't find anything to bikeshed
about, the others grew some comments. I haven't looked too hard at the
actual modeset stuff given that you're already really busy reworking
things and moving stuff to intel_ddi.c

For the modeset stuff 2 general comments so you know from where the
bikeshed will hit you in the next review round:
- if possible, I'd like to hide most of the 'disable pch stuff on hsw'
  stuff behind crtc_driving_pch checks.
- I think we need to be careful about IS_HASWELL vs PCH_LPT checks,
  otherwise hsw+ppt will not work so great.

For the dip/infoframe stuff, maybe you can volunteer Paulo to help you
out, he's looking into this atm anyway. 

Cheers, Daniel

> 
> Note that the DP and eDP modesetting support is not there yet - it will still
> require a considerable amount of patches.
> 
> Also, there is one patch which fixes null pointer exceptions in gmbus code I
> was having with some of the drm-intel-next-queued iterations, but I don't think
> it is necessary at the moment now that gmbus stuff was disabled again (patch
> 5). I am not even sure if we'll hit those code paths with invalid values in
> real life, so I simple added some checks for cases when we don't have a valid
> adapter as it was looking too error-prone otherwise. Perhaps we could add a
> WARN into them as well.

> 
> Eugeni Dodonov (29):
>   drm/i915: add definition of LPT FDI port width registers
>   drm/i915: add WRPLL divider programming bits
>   drm/i915: add Haswell DIP controls registers
>   drm/i915: support infoframes on Haswell
>   drm/i915: prevent NULL pointer exception when using gmbus
>   drm/i915: add support for SBI ops
>   drm/i915: calculate same watermarks on Haswell as on Ivy Bridge
>   drm/i915: share forcewaking code between IVB and HSW
>   drm/i915: haswell has 3 pipes as well
>   drm/i915: reuse Ivybridge interrupts code for Haswell
>   drm/i915: share pipe count handling with Ivybridge
>   drm/i915: share IVB cursor routine with Haswell
>   drm/i915: show unknown sdvox registers on hdmi init
>   drm/i915: do not use fdi_normal_train on haswell
>   drm/i915: do not enable PCH PLL on pre-haswell
>   drm/i915: detect PCH encoders on Haswell
>   drm/i915: enable power wells on haswell init
>   drm/i915: disable rc6 on haswell for now
>   drm/i915: program WM_LINETIME on Haswell
>   drm/i915: do not use old code paths on Haswell
>   drm/i915: initialize DDI buffer translations
>   drm/i915: perform Haswell DDI link training in FDI mode
>   drm/i915: disable pipe DDI function when disabling pipe
>   drm/i915: program iCLKIP on Lynx Point
>   drm/i915: detect digital outputs on Haswell
>   drm/i915: add support for DDI-controlled digital outputs
>   drm/i915: add WR PLL programming table
>   drm/i915: prepare HDMI link for Haswell
>   drm/i915: hook Haswell devices in place
> 
>  drivers/char/agp/intel-agp.c         |    4 +
>  drivers/gpu/drm/i915/i915_dma.c      |    2 +-
>  drivers/gpu/drm/i915/i915_drv.c      |    7 +
>  drivers/gpu/drm/i915/i915_irq.c      |    6 +-
>  drivers/gpu/drm/i915/i915_reg.h      |   23 +
>  drivers/gpu/drm/i915/intel_display.c |  763 ++++++++++++++++++++++++++++++++--
>  drivers/gpu/drm/i915/intel_drv.h     |    1 +
>  drivers/gpu/drm/i915/intel_hdmi.c    |  602 ++++++++++++++++++++++++++-
>  8 files changed, 1357 insertions(+), 51 deletions(-)
> 
> -- 
> 1.7.10
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [PATCH 00/29] Haswell round 3

[Eugeni Dodonov]

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

On Tue, Apr 17, 2012 at 07:49, Daniel Vetter <daniel@ffwll.ch> wrote:

> On Fri, Apr 13, 2012 at 05:08:36PM -0300, Eugeni Dodonov wrote:
> > Hi forks,
> >
> > Just in time for everyone's weekend, here comes the 3rd round of patches
> on
> > Haswell.
> >
> > As major highlights, it also adds support for HDMI/DVI outputs and
> multi-head
> > modes (I tried with VGA and HDMI).
> >
> > Other than that, it is the same patches with comments from the past round
> > addressed (SBI locking support, proper WM calculation, better PCH items
> > detection, and so on).
> >
> > Daniel, I think that the bits definitions, power wells, clocks
> programming, and
> > modesetting for both FDI and HDMI modes should be good to go unless
> someone
> > spots additional issues with them - so please, all of you who have
> something to
> > say about them, say it now and bikeshed as you please :).
>
> I've picked up a few more patches I couldn't find anything to bikeshed
> about, the others grew some comments. I haven't looked too hard at the
> actual modeset stuff given that you're already really busy reworking
> things and moving stuff to intel_ddi.c
>

...and into intel_pm.c as well when those patches land :).

At least the power wells-related part is much more welcome there.

So I'll address the bikeshedding^w comments on the remaining patches and
will resend them when intel_pm.c stuff lands.

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

[-- Attachment #1.2: Type: text/html, Size: 1939 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