[PATCH 1/3] drm/i915: remove comment about IVB link training from intel_pm.c

[PATCH 1/3] drm/i915: remove comment about IVB link training from intel_pm.c

[Paulo Zanoni]

From: Paulo Zanoni <paulo.r.zanoni@intel.com>

We have the exact same comment inside intel_init_display. This is
a leftover from when we moved a lot of code from intel_display.c to
intel_pm.c.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
---
 drivers/gpu/drm/i915/intel_pm.c |    1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index baea4fc..a175984 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4191,7 +4191,6 @@ void intel_init_pm(struct drm_device *dev)
 			}
 			dev_priv->display.init_clock_gating = gen6_init_clock_gating;
 		} else if (IS_IVYBRIDGE(dev)) {
-			/* FIXME: detect B0+ stepping and use auto training */
 			if (SNB_READ_WM0_LATENCY()) {
 				dev_priv->display.update_wm = ivybridge_update_wm;
 				dev_priv->display.update_sprite_wm = sandybridge_update_sprite_wm;
-- 
1.7.10.4

[PATCH 2/3] drm/i915: don't intel_crt_init on any ULT machines

[Paulo Zanoni]

From: Paulo Zanoni <paulo.r.zanoni@intel.com>

We may have DDI_BUF_CTL(PORT_A) configured with 2 lanes and still not
have CRT, so just check for !IS_ULT. This problem happened on a real
machine and resulted in a very ugly dmesg.

Cc: stable@vger.kernel.org
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@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 574d68d..64b4407 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8488,7 +8488,7 @@ static void intel_setup_outputs(struct drm_device *dev)
 		I915_WRITE(PFIT_CONTROL, 0);
 	}
 
-	if (!(HAS_DDI(dev) && (I915_READ(DDI_BUF_CTL(PORT_A)) & DDI_A_4_LANES)))
+	if (!IS_ULT(dev))
 		intel_crt_init(dev);
 
 	if (HAS_DDI(dev)) {
-- 
1.7.10.4

[PATCH 3/3] drm/i915: WARN when LPT-LP is not paired with ULT CPU

[Paulo Zanoni]

From: Paulo Zanoni <paulo.r.zanoni@intel.com>

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
---
 drivers/gpu/drm/i915/i915_drv.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index bddb9a5..3d3803a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -457,11 +457,13 @@ void intel_detect_pch(struct drm_device *dev)
 				dev_priv->num_pch_pll = 0;
 				DRM_DEBUG_KMS("Found LynxPoint PCH\n");
 				WARN_ON(!IS_HASWELL(dev));
+				WARN_ON(IS_ULT(dev));
 			} else if (id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
 				dev_priv->pch_type = PCH_LPT;
 				dev_priv->num_pch_pll = 0;
 				DRM_DEBUG_KMS("Found LynxPoint LP PCH\n");
 				WARN_ON(!IS_HASWELL(dev));
+				WARN_ON(!IS_ULT(dev));
 			}
 			BUG_ON(dev_priv->num_pch_pll > I915_NUM_PLLS);
 		}
-- 
1.7.10.4

Re: [Intel-gfx] [PATCH 2/3] drm/i915: don't intel_crt_init on any ULT machines

[Chris Wilson]

On Fri, Apr 12, 2013 at 06:16:53PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni <paulo.r.zanoni@intel.com>
> 
> We may have DDI_BUF_CTL(PORT_A) configured with 2 lanes and still not
> have CRT, so just check for !IS_ULT. This problem happened on a real
> machine and resulted in a very ugly dmesg.
> 
> Cc: stable@vger.kernel.org
> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>

This doesn't apply to dinq. The approach I'd favour is to have a
intel_info.has_crt similar to the other feature flags.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] [PATCH 2/3] drm/i915: don't intel_crt_init on any ULT machines

[Daniel Vetter]

On Mon, Apr 15, 2013 at 09:45:00PM +0100, Chris Wilson wrote:
> On Fri, Apr 12, 2013 at 06:16:53PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > 
> > We may have DDI_BUF_CTL(PORT_A) configured with 2 lanes and still not
> > have CRT, so just check for !IS_ULT. This problem happened on a real
> > machine and resulted in a very ugly dmesg.
> > 
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> 
> This doesn't apply to dinq. The approach I'd favour is to have a
> intel_info.has_crt similar to the other feature flags.

I'm ok with piling checks on top here for now, I guess we should
reconsider once the next hw platforms shows up around the corner ...

All patches merged to dinq, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [Intel-gfx] [PATCH 2/3] drm/i915: don't intel_crt_init on any ULT machines

[Paulo Zanoni]

Hi

2013/4/16 Daniel Vetter <daniel@ffwll.ch>:
> On Mon, Apr 15, 2013 at 09:45:00PM +0100, Chris Wilson wrote:
>> On Fri, Apr 12, 2013 at 06:16:53PM -0300, Paulo Zanoni wrote:
>> > From: Paulo Zanoni <paulo.r.zanoni@intel.com>
>> >
>> > We may have DDI_BUF_CTL(PORT_A) configured with 2 lanes and still not
>> > have CRT, so just check for !IS_ULT. This problem happened on a real
>> > machine and resulted in a very ugly dmesg.
>> >
>> > Cc: stable@vger.kernel.org
>> > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
>>
>> This doesn't apply to dinq. The approach I'd favour is to have a
>> intel_info.has_crt similar to the other feature flags.
>
> I'm ok with piling checks on top here for now, I guess we should
> reconsider once the next hw platforms shows up around the corner ...

We can always apply Chris's suggestion as a follow-up patch.

>
> All patches merged to dinq, thanks.

I thought patch 2 would go to -fixes. We need it even for older Kernels.

Thanks for the reviews,
Paulo

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch



--
Paulo Zanoni

Re: [Intel-gfx] [PATCH 2/3] drm/i915: don't intel_crt_init on any ULT machines

[Daniel Vetter]

On Tue, Apr 16, 2013 at 3:41 PM, Paulo Zanoni <przanoni@gmail.com> wrote:
>> All patches merged to dinq, thanks.
>
> I thought patch 2 would go to -fixes. We need it even for older Kernels.
>

This late in the release cycle -fixes is for severe regressions and
black-screen level non-regression issues only. Hence merged through
-next with cc: stable.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch