date:20130510

Re: [Intel-gfx] [PATCH] list-workarounds: Convert to python3

2013-05-10 Thread Kenneth Graunke


On 05/10/2013 03:28 PM, Ben Widawsky wrote:

The rest of the tool suite that uses python already uses python3.
The tool configure requires python >= 3 (which is confusing because of
the no backward compat problem).

The world is slowly moving to python3.

Converted with 2to3.

CC: Damien Lespiau 
CC: Kenneth Graunke 
Signed-off-by: Ben Widawsky 


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

[Intel-gfx] [PATCH] list-workarounds: Convert to python3

2013-05-10 Thread Ben Widawsky

The rest of the tool suite that uses python already uses python3.
The tool configure requires python >= 3 (which is confusing because of
the no backward compat problem).

The world is slowly moving to python3.

Converted with 2to3.

CC: Damien Lespiau 
CC: Kenneth Graunke 
Signed-off-by: Ben Widawsky 
---
 scripts/list-workarounds | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/scripts/list-workarounds b/scripts/list-workarounds
index 6c8c636..b874fd8 100755
--- a/scripts/list-workarounds
+++ b/scripts/list-workarounds
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
 
 import os,sys
 import optparse
@@ -29,7 +29,7 @@ wa_re = 
re.compile('(?PWa[A-Z0-9][a-zA-Z0-9_]+):(?P[a-z,]+)')
 waname_re = re.compile('(?PWa[A-Z0-9][a-zA-Z0-9_]+)')
 def parse(me):
for line in me.splitlines():
-   match = wa_re.search(line)
+   match = wa_re.search(str(line))
if not match:
if not verbose:
continue
@@ -103,8 +103,8 @@ if __name__ == '__main__':
sys.exit(1)
 
parse(work_arounds)
-   for wa in sorted(workarounds.iterkeys()):
+   for wa in sorted(workarounds.keys()):
if not options.platform:
-   print("%s: %s" % (wa, ', '.join(workarounds[wa])))
+   print(("%s: %s" % (wa, ', '.join(workarounds[wa]
elif options.platform in workarounds[wa]:
print(wa)
-- 
1.8.2.2

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

Re: [Intel-gfx] [PATCH] drm/i915: add encoder get_config function v4

2013-05-10 Thread Daniel Vetter

On Fri, May 10, 2013 at 9:21 AM, Daniel Vetter  wrote:
> On Thu, May 09, 2013 at 01:28:12AM +0300, Ville Syrjälä wrote:
>> On Wed, May 08, 2013 at 02:01:02PM -0700, Jesse Barnes wrote:
>> > We can use this for fetching encoder specific pipe_config state, like
>> > mode flags, adjusted clock, etc.
>> >
>> > Just used for mode flags atm, so we can check the pipe config state at
>> > mode set time.
>> >
>> > v2: get_config when checking hw state too
>> > v3: fix DVO and LVDS mode flags (Ville)
>> > get SDVO DTD for flag fetch (Ville)
>> > v4: use input timings (Ville)
>> > correct command used (Ville)
>> > remove gen4 check (Ville)
>> >
>> > Signed-off-by: Jesse Barnes 
>>
>> I believe all my complaints have been addressed.
>>
>> Reviewed-by: Ville Syrjälä 
>
> Queued for -next, thanks for the patch.

Dumped again since the ddi_encoder->get_config was missing.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: add DDI get_config function too

2013-05-10 Thread Jesse Barnes

Missed out when doing the rest of the outputs.

Signed-off-by: Jesse Barnes 
---
 drivers/gpu/drm/i915/intel_ddi.c |   23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index cddcf4a..27a74a9 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1254,6 +1254,28 @@ static void intel_ddi_hot_plug(struct intel_encoder 
*intel_encoder)
intel_dp_check_link_status(intel_dp);
 }
 
+static void intel_ddi_get_config(struct intel_encoder *encoder,
+struct intel_crtc_config *pipe_config)
+{
+   struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
+   struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
+   enum transcoder cpu_transcoder = intel_crtc->config.cpu_transcoder;
+   u32 temp, flags = 0;
+
+   temp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
+   if (temp & TRANS_DDI_PHSYNC)
+   flags |= DRM_MODE_FLAG_PHSYNC;
+   else
+   flags |= DRM_MODE_FLAG_NHSYNC;
+   if (temp & TRANS_DDI_PVSYNC)
+   flags |= DRM_MODE_FLAG_PVSYNC;
+   else
+   flags |= DRM_MODE_FLAG_NVSYNC;
+
+   pipe_config->adjusted_mode.flags |= flags;
+   pipe_config->pixel_multiplier = 1;
+}
+
 static void intel_ddi_destroy(struct drm_encoder *encoder)
 {
/* HDMI has nothing special to destroy, so we can go with this. */
@@ -1313,6 +1335,7 @@ void intel_ddi_init(struct drm_device *dev, enum port 
port)
intel_encoder->disable = intel_disable_ddi;
intel_encoder->post_disable = intel_ddi_post_disable;
intel_encoder->get_hw_state = intel_ddi_get_hw_state;
+   intel_encoder->get_config = intel_ddi_get_config;
 
intel_dig_port->port = port;
intel_dig_port->port_reversal = I915_READ(DDI_BUF_CTL(port)) &
-- 
1.7.9.5

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

[Intel-gfx] [PATCH] drm/i915: fetch PCH PLL state at init time v2

2013-05-10 Thread Jesse Barnes

We need to properly track PCH PLL sharing configs, and generally set up
PCH PLL state at init time as part of the state readout process.

v2: update to new code, use intel_crtc instead (Jesse)

I-told-you-so-by: Daniel Vetter 
Signed-off-by: Jesse Barnes 
---
 drivers/gpu/drm/i915/intel_display.c |   48 +-
 1 file changed, 47 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index dda4501..2e7a5bb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6974,6 +6974,49 @@ static void i9xx_crtc_clock_get(struct intel_crtc *crtc,
pipe_config->adjusted_mode.clock = clock.dot;
 }
 
+static void ironlake_crtc_pll_get(struct intel_crtc *crtc)
+{
+   struct drm_device *dev = crtc->base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   u32 dpll_sel;
+
+   if (HAS_PCH_IBX(dev_priv->dev))
+   crtc->pch_pll = &dev_priv->pch_plls[crtc->pipe];
+
+   if (HAS_PCH_CPT(dev_priv->dev)) {
+   dpll_sel = I915_READ(PCH_DPLL_SEL);
+
+   switch (crtc->pipe) {
+   case PIPE_A:
+   if ((dpll_sel & TRANSA_DPLL_ENABLE) &&
+   (dpll_sel & TRANSA_DPLLB_SEL))
+   crtc->pch_pll = &dev_priv->pch_plls[1];
+   else if (dpll_sel & TRANSA_DPLL_ENABLE)
+   crtc->pch_pll = &dev_priv->pch_plls[0];
+   break;
+   case PIPE_B:
+   if ((dpll_sel & TRANSB_DPLL_ENABLE) &&
+   (dpll_sel & TRANSB_DPLLB_SEL))
+   crtc->pch_pll = &dev_priv->pch_plls[1];
+   else if (dpll_sel & TRANSB_DPLL_ENABLE)
+   crtc->pch_pll = &dev_priv->pch_plls[0];
+   break;
+   case PIPE_C:
+   if ((dpll_sel & TRANSC_DPLL_ENABLE) &&
+   (dpll_sel & TRANSC_DPLLB_SEL))
+   crtc->pch_pll = &dev_priv->pch_plls[1];
+   else if (dpll_sel & TRANSC_DPLL_ENABLE)
+   crtc->pch_pll = &dev_priv->pch_plls[0];
+   break;
+   default:
+   BUG();
+   }
+   }
+
+   crtc->pch_pll->refcount++;
+   crtc->pch_pll->active = 1;
+}
+
 static void ironlake_crtc_clock_get(struct intel_crtc *crtc,
struct intel_crtc_config *pipe_config)
 {
@@ -7021,6 +7064,8 @@ static void ironlake_crtc_clock_get(struct intel_crtc 
*crtc,
do_div(clock, link_n);
 
pipe_config->adjusted_mode.clock = clock;
+
+   ironlake_crtc_pll_get(crtc);
 }
 
 /** Returns the currently programmed mode of the given pipe. */
@@ -9611,7 +9656,8 @@ setup_pipes:
if (crtc->active) {
intel_pipe_config_to_crtc(crtc, &crtc->config);
 
-   DRM_DEBUG_KMS("[CRTC:%d] found active mode: ");
+   DRM_DEBUG_KMS("[CRTC:%d] found active mode: ",
+ crtc->base.base.id);
drm_mode_debug_printmodeline(&crtc->base.mode);
}
 
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 4/4] HACK: drm/i915: flip on a no fb -> fb transition

2013-05-10 Thread Jesse Barnes

This needs better checking since the display could be off in this case.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 591ac2d..dda4501 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8422,8 +8422,8 @@ intel_set_config_compute_mode_changes(struct drm_mode_set 
*set,
if (set->crtc->fb != set->fb) {
/* If we have no fb then treat it as a full mode set */
if (set->crtc->fb == NULL) {
-   DRM_DEBUG_KMS("crtc has no fb, full mode set\n");
-   config->mode_changed = true;
+   DRM_DEBUG_KMS("crtc has no fb, will flip\n");
+   config->fb_changed = true;
} else if (set->fb == NULL) {
config->mode_changed = true;
} else if (set->fb->pixel_format !=
-- 
1.7.9.5

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

Re: [Intel-gfx] [PATCH 3/4] drm/i915: VLV support is no longer preliminary

2013-05-10 Thread Jesse Barnes

On Fri, 10 May 2013 20:58:17 +0200
Daniel Vetter  wrote:

> On Fri, May 10, 2013 at 09:10:27AM -0700, Jesse Barnes wrote:
> > On Fri, 10 May 2013 09:29:28 +0200
> > Daniel Vetter  wrote:
> > 
> > > On Wed, May 08, 2013 at 10:45:15AM -0700, Jesse Barnes wrote:
> > > > Works pretty well actually.
> > > > 
> > > > Signed-off-by: Jesse Barnes 
> > > 
> > > Patches 1-3 merged to dinq, thanks. I'm a bit unhappy that we don't have
> > > mipi yet, otoh mipi needs sink drivers so meh.
> > 
> > Yeah, MIPI DSI is a bit messy regardless, so I think it's ok to call it
> > "ready" even if we don't have some specific DSI panels supported.
> 
> Another thing which looked _really_ fishy was non-eDP DP support on vlv.
> Atm we often only take the new vlv dp paths due to is_cpu_edp being true
> on vlv edp, too. Imo that should be remedied and we should move all the
> vlv paths out of the is_cpu_edp checks (and maybe inline the port ==
> PORT_A check for ilk-ivb in all relevant places). Imre has ideas already,
> too.

Ok just be careful, because regular DP works fine here in testing. :)

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

[Intel-gfx] [PATCH 2/4] drm/i915: copy fetched mode state into crtc at setup_hw time

2013-05-10 Thread Jesse Barnes

We already fetch and track other state into the main CRTC and encoder
structs, and for fastboot we need to do the same with the mode and clock
data we read out.

Signed-off-by: Jesse Barnes 
---
 drivers/gpu/drm/i915/intel_display.c |   29 +
 1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3d95a0e..53ad51c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4788,6 +4788,24 @@ static void intel_get_pipe_timings(struct intel_crtc 
*crtc,
pipe_config->requested_mode.hdisplay = ((tmp >> 16) & 0x) + 1;
 }
 
+static void intel_pipe_config_to_crtc(struct intel_crtc *intel_crtc,
+ struct intel_crtc_config *pipe_config)
+{
+   struct drm_crtc *crtc = &intel_crtc->base;
+
+   crtc->mode.hdisplay = pipe_config->adjusted_mode.crtc_hdisplay;
+   crtc->mode.htotal = pipe_config->adjusted_mode.crtc_htotal;
+   crtc->mode.hsync_start = pipe_config->adjusted_mode.crtc_hsync_start;
+   crtc->mode.hsync_end = pipe_config->adjusted_mode.crtc_hsync_end;
+
+   crtc->mode.vdisplay = pipe_config->adjusted_mode.crtc_vdisplay;
+   crtc->mode.vtotal = pipe_config->adjusted_mode.crtc_vtotal;
+   crtc->mode.vsync_start = pipe_config->adjusted_mode.crtc_vsync_start;
+   crtc->mode.vsync_end = pipe_config->adjusted_mode.crtc_vsync_end;
+
+   crtc->mode.flags = pipe_config->adjusted_mode.flags;
+}
+
 static void i9xx_set_pipeconf(struct intel_crtc *intel_crtc)
 {
struct drm_device *dev = intel_crtc->base.dev;
@@ -9578,6 +9596,13 @@ setup_pipes:
 
crtc->base.enabled = crtc->active;
 
+   if (crtc->active) {
+   intel_pipe_config_to_crtc(crtc, &crtc->config);
+
+   DRM_DEBUG_KMS("[CRTC:%d] found active mode: ");
+   drm_mode_debug_printmodeline(&crtc->base.mode);
+   }
+
DRM_DEBUG_KMS("[CRTC:%d] hw state readout: %s\n",
  crtc->base.base.id,
  crtc->active ? "enabled" : "disabled");
@@ -9596,6 +9621,10 @@ setup_pipes:
encoder->get_config(encoder, &crtc->config);
dev_priv->display.get_clock(crtc,
&crtc->config);
+   crtc->base.mode.clock =
+   crtc->config.adjusted_mode.clock;
+   crtc->base.mode.flags |=
+   crtc->config.adjusted_mode.flags;
}
encoder->base.crtc = &crtc->base;
} else {
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 3/4] HACK: drm/i915: turn off panel fitting at flip time if needed

2013-05-10 Thread Jesse Barnes

Need better pfit tracking to do this right.

Signed-off-by: Jesse Barnes 
---
 drivers/gpu/drm/i915/intel_display.c |   12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 53ad51c..591ac2d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2301,6 +2301,18 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
return ret;
}
 
+   /* Update pipe size and adjust fitter if needed */
+   I915_WRITE(PIPESRC(intel_crtc->pipe),
+  ((crtc->mode.hdisplay - 1) << 16) |
+  (crtc->mode.vdisplay - 1));
+   if (!intel_crtc->config.pch_pfit.size &&
+   (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS) ||
+intel_pipe_has_type(crtc, INTEL_OUTPUT_EDP))) {
+   I915_WRITE(PF_CTL(intel_crtc->pipe), 0);
+   I915_WRITE(PF_WIN_POS(intel_crtc->pipe), 0);
+   I915_WRITE(PF_WIN_SZ(intel_crtc->pipe), 0);
+   }
+
ret = dev_priv->display.update_plane(crtc, fb, x, y);
if (ret) {
intel_unpin_fb_obj(to_intel_framebuffer(fb)->obj);
-- 
1.7.9.5

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

[Intel-gfx] [PATCH 1/4] drm/i915: get mode clock when reading the pipe config v4

2013-05-10 Thread Jesse Barnes

We need this for comparing modes between configuration changes.

v2: try harder to calulate non-simple pixel clocks (Daniel)
call get_clock after getting the encoder config, needed for pixel multiply
(Jesse)
v3: drop get_clock now that the pixel_multiply has been moved into
get_pipe_config
v4: re-add get_clock; we need to get the pixel multiplier in the
encoder, so need to calculate the clock value after the encoder's
get_config is called

Signed-off-by: Jesse Barnes 
---
 drivers/gpu/drm/i915/i915_drv.h  |1 +
 drivers/gpu/drm/i915/intel_crt.c |1 +
 drivers/gpu/drm/i915/intel_display.c |   80 +++---
 drivers/gpu/drm/i915/intel_dp.c  |8 
 drivers/gpu/drm/i915/intel_drv.h |3 ++
 drivers/gpu/drm/i915/intel_dvo.c |1 +
 drivers/gpu/drm/i915/intel_hdmi.c|1 +
 drivers/gpu/drm/i915/intel_lvds.c|1 +
 drivers/gpu/drm/i915/intel_sdvo.c|   24 ++
 9 files changed, 113 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 14817de..2e284bb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -323,6 +323,7 @@ struct drm_i915_display_funcs {
 * fills out the pipe-config with the hw state. */
bool (*get_pipe_config)(struct intel_crtc *,
struct intel_crtc_config *);
+   void (*get_clock)(struct intel_crtc *, struct intel_crtc_config *);
int (*crtc_mode_set)(struct drm_crtc *crtc,
 int x, int y,
 struct drm_framebuffer *old_fb);
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 789c4ef..bd91e72 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -101,6 +101,7 @@ static void intel_crt_get_config(struct intel_encoder 
*encoder,
flags |= DRM_MODE_FLAG_NVSYNC;
 
pipe_config->adjusted_mode.flags |= flags;
+   pipe_config->pixel_multiplier = 1;
 }
 
 static void intel_disable_crt(struct intel_encoder *encoder)
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index cba0992..3d95a0e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -45,6 +45,11 @@ bool intel_pipe_has_type(struct drm_crtc *crtc, int type);
 static void intel_increase_pllclock(struct drm_crtc *crtc);
 static void intel_crtc_update_cursor(struct drm_crtc *crtc, bool on);
 
+static void i9xx_crtc_clock_get(struct intel_crtc *crtc,
+   struct intel_crtc_config *pipe_config);
+static void ironlake_crtc_clock_get(struct intel_crtc *crtc,
+   struct intel_crtc_config *pipe_config);
+
 typedef struct {
int min, max;
 } intel_range_t;
@@ -6852,11 +6857,12 @@ void intel_release_load_detect_pipe(struct 
drm_connector *connector,
 }
 
 /* Returns the clock of the currently programmed mode of the given pipe. */
-static int intel_crtc_clock_get(struct drm_device *dev, struct drm_crtc *crtc)
+static void i9xx_crtc_clock_get(struct intel_crtc *crtc,
+   struct intel_crtc_config *pipe_config)
 {
+   struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   int pipe = intel_crtc->pipe;
+   int pipe = pipe_config->cpu_transcoder;
u32 dpll = I915_READ(DPLL(pipe));
u32 fp;
intel_clock_t clock;
@@ -6895,7 +6901,8 @@ static int intel_crtc_clock_get(struct drm_device *dev, 
struct drm_crtc *crtc)
default:
DRM_DEBUG_KMS("Unknown DPLL mode %08x in programmed "
  "mode\n", (int)(dpll & DPLL_MODE_MASK));
-   return 0;
+   pipe_config->adjusted_mode.clock = 0;
+   return;
}
 
/* XXX: Handle the 100Mhz refclk */
@@ -6934,8 +6941,56 @@ static int intel_crtc_clock_get(struct drm_device *dev, 
struct drm_crtc *crtc)
 * i830PllIsValid() because it relies on the xf86_config connector
 * configuration being accurate, which it isn't necessarily.
 */
+   pipe_config->adjusted_mode.clock = clock.dot;
+}
+
+static void ironlake_crtc_clock_get(struct intel_crtc *crtc,
+   struct intel_crtc_config *pipe_config)
+{
+   struct drm_device *dev = crtc->base.dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
+   int link_freq, repeat;
+   u64 clock;
+   u32 link_m, link_n;
+
+   /* FIXME: Haswell bits */
+
+   repeat = pipe_config->pixel_multiplier;
+
+   /*
+* The calculation for the data clock is:
+* pixel_clock =

Re: [Intel-gfx] [PATCH] drm: check user mode flags for validity

2013-05-10 Thread Ville Syrjälä

On Fri, May 10, 2013 at 09:08:08AM -0700, Jesse Barnes wrote:
> On Thu, 9 May 2013 01:25:59 +0300
> Ville Syrjälä  wrote:
> 
> > On Wed, May 08, 2013 at 02:01:25PM -0700, Jesse Barnes wrote:
> > > Requested-by: Ville Syrjälä 
> > > Signed-off-by: Jesse Barnes 
> > > ---
> > >  drivers/gpu/drm/drm_crtc.c |   12 
> > >  1 file changed, 12 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > > index 792c3e3..72ae33a 100644
> > > --- a/drivers/gpu/drm/drm_crtc.c
> > > +++ b/drivers/gpu/drm/drm_crtc.c
> > > @@ -1318,6 +1318,18 @@ static int drm_crtc_convert_umode(struct 
> > > drm_display_mode *out,
> > >   if (in->clock > INT_MAX || in->vrefresh > INT_MAX)
> > >   return -ERANGE;
> > >  
> > > + /* Reject modes with invalid h/vsync */
> > > + if (!(in->flags & (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NHSYNC)))
> > > + return -EINVAL;
> > > + if ((in->flags & DRM_MODE_FLAG_PHSYNC) &&
> > > + (in->flags & DRM_MODE_FLAG_NHSYNC))
> > > + return -EINVAL;
> > > + if (!(in->flags & (DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC)))
> > > + return -EINVAL;
> > > + if ((in->flags & DRM_MODE_FLAG_PVSYNC) &&
> > > + (in->flags & DRM_MODE_FLAG_NVSYNC))
> > > + return -EINVAL;
> > 
> > That might be a bit too drastic. Well I suppose making sure that both
> > flags are not enabled at the same time could be OK. But having neither
> > flag set could be perfectly legal (the user could be asking for composite
> > sync instead for example).
> > 
> > 
> > So my less drastic suggestion would be doing something like this in i915
> > specific code:
> > 
> >  adjusted_mode->flags = 0;
> >  if (requested_mode->flags & NHSYNC)
> > adjusted_mode->flags |= NHSYNC;
> >  else
> > adjusted_mode->flags |= PHSYNC;
> > 
> > It would gurantee that we end up picking exactly one of the flags in
> > every case. If both are set, we pick -, of neither is set we pick +.
> 
> Ah yeah I knew I was forgetting something... I'll drop the checks for
> no flags.
> 
> You really think it would be better to do this in i915?  I guess it's
> probably safe, but it seems nicer to filter this out where it might
> occur (the EDID quirks should already deal with bogus flags for kernel
> generated mode lists).

I was thinking that we're generally quite relaxed about modesetting. The
user may specify something, but we might not really honor it due to
various mode fixups. Heck, if we have an LVDS or some other fixed mode
display, we ignore everything but the hdisp/vdisp from the user mode.

The same goes with the sync flags. For example if we're doing composite
or component output, it's always going to be composite sync, no matter
what the user asked for. And if we're cloning it at the same time, we
may be outputting both composite sync and separate h/v syncs at the same
time. Also the actual sync polarities may be limited by the hardware, so
not all cloned outputs might be using the same polarities.

We have no spec for how these flags should work, and we've been very
relaxed about them thus far. I'm mostly worried that if we add strict
checks, we may break some setup that works. So my idea would be to treat
that stuff as just hints.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: implement WADPOClockGatingDisable for LPT

2013-05-10 Thread Daniel Vetter

On Wed, May 08, 2013 at 01:54:17PM +0100, Damien Lespiau wrote:
> On Tue, May 07, 2013 at 03:40:21PM +0100, Damien Lespiau wrote:
> > On Tue, May 07, 2013 at 10:46:01AM -0300, Paulo Zanoni wrote:
> > > 2013/5/7 Damien Lespiau :
> > > > On Tue, May 07, 2013 at 02:10:05PM +0100, Damien Lespiau wrote:
> > > >> On Wed, Apr 17, 2013 at 06:15:49PM -0300, Paulo Zanoni wrote:
> > > >> > From: Paulo Zanoni 
> > > >> >
> > > >> > This should prevent mode set failures on LPT.
> > > >> >
> > > >> > Signed-off-by: Paulo Zanoni 
> > > >> > ---
> > > >> >  drivers/gpu/drm/i915/intel_pm.c |5 +
> > > >> >  1 file changed, 5 insertions(+)
> > > >> >
> > > >> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > > >> > b/drivers/gpu/drm/i915/intel_pm.c
> > > >> > index 413877d..15ff0ac 100644
> > > >> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > >> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > >> > @@ -3758,6 +3758,11 @@ static void lpt_init_clock_gating(struct 
> > > >> > drm_device *dev)
> > > >> > I915_WRITE(SOUTH_DSPCLK_GATE_D,
> > > >> >I915_READ(SOUTH_DSPCLK_GATE_D) |
> > > >> >PCH_LP_PARTITION_LEVEL_DISABLE);
> > > >> > +
> > > >> > +   /* WADPOClockGatingDisable */
> > > >> > +   I915_WRITE(_TRANSA_CHICKEN1,
> > > >> > +  I915_READ(_TRANSA_CHICKEN1) |
> > > >> > +  TRANS_CHICKEN1_DP0UNIT_GC_DISABLE);
> 
> 
> Of course, It'd be good to add the :hsw at the end of
> WADPOClockGatingDisable (ammending the patch when applying?) now that
> the workaround documentation has been pushed.

Done and queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] drm/i915: VLV support is no longer preliminary

2013-05-10 Thread Daniel Vetter

On Fri, May 10, 2013 at 09:10:27AM -0700, Jesse Barnes wrote:
> On Fri, 10 May 2013 09:29:28 +0200
> Daniel Vetter  wrote:
> 
> > On Wed, May 08, 2013 at 10:45:15AM -0700, Jesse Barnes wrote:
> > > Works pretty well actually.
> > > 
> > > Signed-off-by: Jesse Barnes 
> > 
> > Patches 1-3 merged to dinq, thanks. I'm a bit unhappy that we don't have
> > mipi yet, otoh mipi needs sink drivers so meh.
> 
> Yeah, MIPI DSI is a bit messy regardless, so I think it's ok to call it
> "ready" even if we don't have some specific DSI panels supported.

Another thing which looked _really_ fishy was non-eDP DP support on vlv.
Atm we often only take the new vlv dp paths due to is_cpu_edp being true
on vlv edp, too. Imo that should be remedied and we should move all the
vlv paths out of the is_cpu_edp checks (and maybe inline the port ==
PORT_A check for ilk-ivb in all relevant places). Imre has ideas already,
too.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] Revert "drm/i915: disable interrupts earlier in the driver unload code"

2013-05-10 Thread Jesse Barnes

On Fri, 10 May 2013 09:27:09 +0200
Daniel Vetter  wrote:

> On Wed, May 08, 2013 at 10:45:16AM -0700, Jesse Barnes wrote:
> > This reverts commit fd0c06420d39958032655a04cfd194d5a7b38f83.
> 
> A bit thin on details about what exactly blows up ... can you please dig a
> bit more?

Oh and this wasn't an official submission :)  Just something to get you
thinking about it...

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

Re: [Intel-gfx] [PATCH 3/4] drm/i915: VLV support is no longer preliminary

2013-05-10 Thread Jesse Barnes

On Fri, 10 May 2013 09:29:28 +0200
Daniel Vetter  wrote:

> On Wed, May 08, 2013 at 10:45:15AM -0700, Jesse Barnes wrote:
> > Works pretty well actually.
> > 
> > Signed-off-by: Jesse Barnes 
> 
> Patches 1-3 merged to dinq, thanks. I'm a bit unhappy that we don't have
> mipi yet, otoh mipi needs sink drivers so meh.

Yeah, MIPI DSI is a bit messy regardless, so I think it's ok to call it
"ready" even if we don't have some specific DSI panels supported.

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

Re: [Intel-gfx] [PATCH 4/4] Revert "drm/i915: disable interrupts earlier in the driver unload code"

2013-05-10 Thread Jesse Barnes

On Fri, 10 May 2013 09:27:09 +0200
Daniel Vetter  wrote:

> On Wed, May 08, 2013 at 10:45:16AM -0700, Jesse Barnes wrote:
> > This reverts commit fd0c06420d39958032655a04cfd194d5a7b38f83.
> 
> A bit thin on details about what exactly blows up ... can you please dig a
> bit more?

On unload, we crash trying to queue the VLV work from the
gen6_pm_rps_work function and things fall over pretty hard.  At least
that's what the backtrace looked like; it was hard to tell since the
machine was hard hung and I couldn't scroll back.

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

Re: [Intel-gfx] [PATCH] drm: check user mode flags for validity

2013-05-10 Thread Jesse Barnes

On Thu, 9 May 2013 01:25:59 +0300
Ville Syrjälä  wrote:

> On Wed, May 08, 2013 at 02:01:25PM -0700, Jesse Barnes wrote:
> > Requested-by: Ville Syrjälä 
> > Signed-off-by: Jesse Barnes 
> > ---
> >  drivers/gpu/drm/drm_crtc.c |   12 
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 792c3e3..72ae33a 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -1318,6 +1318,18 @@ static int drm_crtc_convert_umode(struct 
> > drm_display_mode *out,
> > if (in->clock > INT_MAX || in->vrefresh > INT_MAX)
> > return -ERANGE;
> >  
> > +   /* Reject modes with invalid h/vsync */
> > +   if (!(in->flags & (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NHSYNC)))
> > +   return -EINVAL;
> > +   if ((in->flags & DRM_MODE_FLAG_PHSYNC) &&
> > +   (in->flags & DRM_MODE_FLAG_NHSYNC))
> > +   return -EINVAL;
> > +   if (!(in->flags & (DRM_MODE_FLAG_PVSYNC | DRM_MODE_FLAG_NVSYNC)))
> > +   return -EINVAL;
> > +   if ((in->flags & DRM_MODE_FLAG_PVSYNC) &&
> > +   (in->flags & DRM_MODE_FLAG_NVSYNC))
> > +   return -EINVAL;
> 
> That might be a bit too drastic. Well I suppose making sure that both
> flags are not enabled at the same time could be OK. But having neither
> flag set could be perfectly legal (the user could be asking for composite
> sync instead for example).
> 
> 
> So my less drastic suggestion would be doing something like this in i915
> specific code:
> 
>  adjusted_mode->flags = 0;
>  if (requested_mode->flags & NHSYNC)
>   adjusted_mode->flags |= NHSYNC;
>  else
>   adjusted_mode->flags |= PHSYNC;
> 
> It would gurantee that we end up picking exactly one of the flags in
> every case. If both are set, we pick -, of neither is set we pick +.

Ah yeah I knew I was forgetting something... I'll drop the checks for
no flags.

You really think it would be better to do this in i915?  I guess it's
probably safe, but it seems nicer to filter this out where it might
occur (the EDID quirks should already deal with bogus flags for kernel
generated mode lists).

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

Re: [Intel-gfx] [PATCH] drm/i915: s/valleyview/baytrail

2013-05-10 Thread Chad Versace


On 05/08/2013 09:53 PM, Ben Widawsky wrote:

Bay Trail is the marketing name for the new Silvermont based SOCs we've
been calling Valleyview. All recent Intel disclosed documents use the
term "Bay Trail." AFAICT, only leaked docs (and our code) use the term
Valleyview. I've also verified with internal sources that references to,
"Valleyview" should be dropped.

Why?
We've always strived to make the already confusing generation
information as clear as possible in our driver. With the introduction
of the below, we made two names referring to the exact same silicon.

commit 93c34e70ebf464a9ee142d93b681c5df094ec654
Author: Kenneth Graunke 
Date:   Mon Apr 22 00:53:50 2013 -0700

 drm/i915: Fix page table entries for Bay Trail.

While it's tempting to simply do the renames in Ken's patch, it's simply
not correct. As an added bonus, Mesa also uses the byt/baytrail names.

Yes. I know this is painful. Doing it now is the least painful way to do
this right (short of going back in time.)

disclaimer: only compile tested.
disclaimer2: I didn't fix pre-existing checkpatch issues.

CC: Kenneth Graunke 
CC: Jesse Barnes 
Signed-off-by: Ben Widawsky 


Acked-by: Chad Versace 

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

Re: [Intel-gfx] [PATCH] drm/i915: Advance seqno upon reseting the GPU following a hang

2013-05-10 Thread Daniel Vetter

On Wed, May 8, 2013 at 4:06 PM, Chris Wilson  wrote:
> On Wed, May 08, 2013 at 04:02:00PM +0200, Daniel Vetter wrote:
>> On Wed, May 08, 2013 at 02:29:30PM +0100, Chris Wilson wrote:
>> > There is an unlikely corner case whereby a lockless wait may not notice
>> > a GPU hang and reset, and so continue to wait for the device to advance
>> > beyond the chosen seqno. This of course may never happen as the waiter
>> > may be the only user. Instead, we can explicitly advance the device
>> > seqno to match the requests that are forcibly retired following the
>> > hang.
>> >
>> > Signed-off-by: Chris Wilson 
>>
>> This race is why the reset counter must always increase and can't just
>> flip-flop between the reset-in-progress and everything-works states.
>>
>> Now if we want to unwedge on resume we need to reconsider this, but imo it
>> would be easier to simply remember the reset counter before we wedge the
>> gpu and restore that one (incremented as if the gpu reset worked). We
>> already assume that wedged will never collide with a real reset counter,
>> so this should work.
>
> Agree that this a unwedge-upon-resume issue, but my argument here is
> that this leaves the hardware state consistent with what we forcibly
> reset it to. From that perspective your suggestion is papering over this
> here bug and this is the neat solution.

Yeah, for the reset case I agree that just continuing in the sequence
would be more resilient. I'm still a bit unsure though what to do
across suspend/resume (where we currently force-reset the sequence
numbers, too). Maybe we need the poke-y stick there, too (in the form
of kicking waiters and incrementing the reset counter).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH intel-gpu-tools] assembler: Add support for the SENDC instruction.

2013-05-10 Thread Damien Lespiau

On Thu, May 09, 2013 at 10:44:48AM -0700, Matt Turner wrote:
> ---
>  assembler/gram.y | 20 
>  assembler/lex.l  |  1 +
>  2 files changed, 13 insertions(+), 8 deletions(-)

Looks good to me.

Reviewed-by: Damien Lespiau 

-- 
Damien

> 
> diff --git a/assembler/gram.y b/assembler/gram.y
> index 50d71d1..09f21f1 100644
> --- a/assembler/gram.y
> +++ b/assembler/gram.y
> @@ -440,7 +440,7 @@ static void resolve_subnr(struct brw_reg *reg)
>  %token  MUL MAC MACH LINE SAD2 SADA2 DP4 DPH DP3 DP2
>  %token  AVG ADD SEL AND OR XOR SHR SHL ASR CMP CMPN PLN
>  %token  ADDC BFI1 BFREV CBIT F16TO32 F32TO16 FBH FBL
> -%token  SEND NOP JMPI IF IFF WHILE ELSE BREAK CONT HALT MSAVE
> +%token  SEND SENDC NOP JMPI IF IFF WHILE ELSE BREAK CONT HALT MSAVE
>  %token  PUSH MREST POP WAIT DO ENDIF ILLEGAL
>  %token  MATH_INST
>  %token  MAD LRP BFE BFI2 SUBB
> @@ -494,6 +494,7 @@ static void resolve_subnr(struct brw_reg *reg)
>  %type  instoption
>  %type  unaryop binaryop binaryaccop breakop
>  %type  trinaryop
> +%type  sendop
>  %type  conditionalmodifier 
>  %type  predicate
>  %type  instoptions instoption_list
> @@ -1099,7 +1100,10 @@ trinaryinstruction:
>  }
>  ;
>  
> -sendinstruction: predicate SEND execsize exp post_dst payload msgtarget
> +sendop:  SEND | SENDC
> +;
> +
> +sendinstruction: predicate sendop execsize exp post_dst payload msgtarget
>   MSGLEN exp RETURNLEN exp instoptions
>   {
> /* Send instructions are messy.  The first argument is the
> @@ -1163,7 +1167,7 @@ sendinstruction: predicate SEND execsize exp post_dst 
> payload msgtarget
>GEN(&$$)->bits3.generic.end_of_thread = 
> $12.end_of_thread;
> }
>   }
> - | predicate SEND execsize dst sendleadreg payload 
> directsrcoperand instoptions
> + | predicate sendop execsize dst sendleadreg payload 
> directsrcoperand instoptions
>   {
> memset(&$$, 0, sizeof($$));
> set_instruction_opcode(&$$, $2);
> @@ -1181,7 +1185,7 @@ sendinstruction: predicate SEND execsize exp post_dst 
> payload msgtarget
>   YYERROR;
>  
> }
> - | predicate SEND execsize dst sendleadreg payload imm32reg 
> instoptions
> + | predicate sendop execsize dst sendleadreg payload imm32reg 
> instoptions
>  {
> if ($7.reg.type != BRW_REGISTER_TYPE_UD &&
> $7.reg.type != BRW_REGISTER_TYPE_D &&
> @@ -1202,7 +1206,7 @@ sendinstruction: predicate SEND execsize exp post_dst 
> payload msgtarget
> if (set_instruction_src1(&$$, &$7, &@7) != 0)
>   YYERROR;
>  }
> - | predicate SEND execsize dst sendleadreg sndopr imm32reg 
> instoptions
> + | predicate sendop execsize dst sendleadreg sndopr imm32reg 
> instoptions
>   {
> struct src_operand src0;
>  
> @@ -1243,7 +1247,7 @@ sendinstruction: predicate SEND execsize exp post_dst 
> payload msgtarget
>  
>GEN(&$$)->bits3.generic_gen5.end_of_thread = !!($6 & 
> EX_DESC_EOT_MASK);
>   }
> - | predicate SEND execsize dst sendleadreg sndopr 
> directsrcoperand instoptions
> + | predicate sendop execsize dst sendleadreg sndopr 
> directsrcoperand instoptions
>   {
> struct src_operand src0;
>  
> @@ -1284,7 +1288,7 @@ sendinstruction: predicate SEND execsize exp post_dst 
> payload msgtarget
>set_instruction_src1(&$$, &$7, &@7);
>GEN(&$$)->bits3.generic_gen5.end_of_thread = !!($6 & 
> EX_DESC_EOT_MASK);
>   }
> - | predicate SEND execsize dst sendleadreg payload sndopr 
> imm32reg instoptions
> + | predicate sendop execsize dst sendleadreg payload sndopr 
> imm32reg instoptions
>   {
> if ($8.reg.type != BRW_REGISTER_TYPE_UD &&
> $8.reg.type != BRW_REGISTER_TYPE_D &&
> @@ -1310,7 +1314,7 @@ sendinstruction: predicate SEND execsize exp post_dst 
> payload msgtarget
> GEN(&$$)->bits3.generic_gen5.end_of_thread = !!($7 & 
> EX_DESC_EOT_MASK);
> }
>   }
> - | predicate SEND execsize dst sendleadreg payload exp 
> directsrcoperand instoptions
> + | predicate sendop execsize dst sendleadreg payload exp 
> directsrcoperand instoptions
>   {
> memset(&$$, 0, sizeof($$));
> set_instruction_opcode(&$$, $2);
> diff --git a/assembler/lex.l b/assembler/lex.l
> index 769d98b..4f1f961 100644
> --- a/assembler/lex.l
> +++ b/assembler/lex.l
> @@ -129,6 +129,7 @@ yylval.integer = BRW_CHANNEL_W;
>  "subb" { yylval.integer = BRW_OPCODE_SUBB; return SUBB; }
>  
>  "send" { yylval.integer = BRW_OPCODE_SEND; return SEND; }
> +"sendc" { yylval.integer = BRW_OPCODE_SE

Re: [Intel-gfx] [PATCH] drm/i915: Add missing platform tags to FBC workaround comments

2013-05-10 Thread Daniel Vetter

On Fri, May 10, 2013 at 02:33:17PM +0100, Damien Lespiau wrote:
> There was a race between Rodrigo writing those patches and me
> formalizing the addition of platform tags. This patches fixes it.
> 
> Signed-off-by: Damien Lespiau 

Queued for -next, thanks for the patch.
-Daniel
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index d806448..28cec57 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -243,13 +243,13 @@ static void ironlake_disable_fbc(struct drm_device *dev)
>   I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl);
>  
>   if (IS_IVYBRIDGE(dev))
> - /* WaFbcDisableDpfcClockGating */
> + /* WaFbcDisableDpfcClockGating:ivb */
>   I915_WRITE(ILK_DSPCLK_GATE_D,
>  I915_READ(ILK_DSPCLK_GATE_D) &
>  ~ILK_DPFCUNIT_CLOCK_GATE_DISABLE);
>  
>   if (IS_HASWELL(dev))
> - /* WaFbcDisableDpfcClockGating */
> + /* WaFbcDisableDpfcClockGating:hsw */
>   I915_WRITE(HSW_CLKGATE_DISABLE_PART_1,
>  I915_READ(HSW_CLKGATE_DISABLE_PART_1) &
>  ~HSW_DPFC_GATING_DISABLE);
> @@ -281,17 +281,17 @@ static void gen7_enable_fbc(struct drm_crtc *crtc, 
> unsigned long interval)
>  intel_crtc->plane << IVB_DPFC_CTL_PLANE_SHIFT);
>  
>   if (IS_IVYBRIDGE(dev)) {
> - /* WaFbcAsynchFlipDisableFbcQueue */
> + /* WaFbcAsynchFlipDisableFbcQueue:ivb */
>   I915_WRITE(ILK_DISPLAY_CHICKEN1, ILK_FBCQ_DIS);
> - /* WaFbcDisableDpfcClockGating */
> + /* WaFbcDisableDpfcClockGating:ivb */
>   I915_WRITE(ILK_DSPCLK_GATE_D,
>  I915_READ(ILK_DSPCLK_GATE_D) |
>  ILK_DPFCUNIT_CLOCK_GATE_DISABLE);
>   } else {
> - /* WaFbcAsynchFlipDisableFbcQueue */
> + /* WaFbcAsynchFlipDisableFbcQueue:hsw */
>   I915_WRITE(HSW_PIPE_SLICE_CHICKEN_1(intel_crtc->pipe),
>  HSW_BYPASS_FBC_QUEUE);
> - /* WaFbcDisableDpfcClockGating */
> + /* WaFbcDisableDpfcClockGating:hsw */
>   I915_WRITE(HSW_CLKGATE_DISABLE_PART_1,
>  I915_READ(HSW_CLKGATE_DISABLE_PART_1) |
>  HSW_DPFC_GATING_DISABLE);
> -- 
> 1.8.1.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use pipe config state to control gmch pfit enable/disable

2013-05-10 Thread Mika Kuoppala

Daniel Vetter  writes:

> Allows us to rip out a few fragile checks (which are duplicated in the
> hw state readout now, too). Also prepares us a bit for more than one
> panel/pfit.
>
> Signed-off-by: Daniel Vetter 

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

Re: [Intel-gfx] [PATCH 7/7] drm/i915: rip out an unused lvds_reg variable

2013-05-10 Thread Daniel Vetter

On Fri, May 10, 2013 at 02:42:03PM +0300, Jani Nikula wrote:
> On Tue, 30 Apr 2013, Daniel Vetter  wrote:
> > Somehow this has been forgotten in
> >
> > commit 1974cad0ee4ce84e5cb792e49c4f0d9421e0312c
> > Author: Daniel Vetter 
> > Date:   Mon Nov 26 17:22:09 2012 +0100
> >
> > drm/i915: move is_dual_link_lvds to intel_lvds.c
> >
> 
> Reviewed-by: Jani Nikula 

Oops, missed one. Queued for -next, thanks for the review.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] list-workarounds: Don't add an already present platform

2013-05-10 Thread Damien Lespiau

Currently if we come across several sites that say that a specific
workaround is implemented for a platform, we just add the platform
several times to the list. eg.

WaFbcDisableDpfcClockGating: ivb, hsw, ivb, hsw

This patch prevent that by only adding the plaform if it's not already
there.

Signed-off-by: Damien Lespiau 
---
 scripts/list-workarounds | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/scripts/list-workarounds b/scripts/list-workarounds
index 7bfd82d..6c8c636 100755
--- a/scripts/list-workarounds
+++ b/scripts/list-workarounds
@@ -47,7 +47,10 @@ def parse(me):
platforms = match.group('platforms')
 
if wa_name in workarounds:
-   workarounds[wa_name] += parse_platforms(platforms)
+   platforms = parse_platforms(platforms)
+   for p in platforms:
+   if not p in workarounds[wa_name]:
+   workarounds[wa_name].append(p)
else:
workarounds[wa_name] = parse_platforms(platforms)
 
-- 
1.8.1.4

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

[Intel-gfx] [PATCH] drm/i915: Add missing platform tags to FBC workaround comments

2013-05-10 Thread Damien Lespiau

There was a race between Rodrigo writing those patches and me
formalizing the addition of platform tags. This patches fixes it.

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

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d806448..28cec57 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -243,13 +243,13 @@ static void ironlake_disable_fbc(struct drm_device *dev)
I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl);
 
if (IS_IVYBRIDGE(dev))
-   /* WaFbcDisableDpfcClockGating */
+   /* WaFbcDisableDpfcClockGating:ivb */
I915_WRITE(ILK_DSPCLK_GATE_D,
   I915_READ(ILK_DSPCLK_GATE_D) &
   ~ILK_DPFCUNIT_CLOCK_GATE_DISABLE);
 
if (IS_HASWELL(dev))
-   /* WaFbcDisableDpfcClockGating */
+   /* WaFbcDisableDpfcClockGating:hsw */
I915_WRITE(HSW_CLKGATE_DISABLE_PART_1,
   I915_READ(HSW_CLKGATE_DISABLE_PART_1) &
   ~HSW_DPFC_GATING_DISABLE);
@@ -281,17 +281,17 @@ static void gen7_enable_fbc(struct drm_crtc *crtc, 
unsigned long interval)
   intel_crtc->plane << IVB_DPFC_CTL_PLANE_SHIFT);
 
if (IS_IVYBRIDGE(dev)) {
-   /* WaFbcAsynchFlipDisableFbcQueue */
+   /* WaFbcAsynchFlipDisableFbcQueue:ivb */
I915_WRITE(ILK_DISPLAY_CHICKEN1, ILK_FBCQ_DIS);
-   /* WaFbcDisableDpfcClockGating */
+   /* WaFbcDisableDpfcClockGating:ivb */
I915_WRITE(ILK_DSPCLK_GATE_D,
   I915_READ(ILK_DSPCLK_GATE_D) |
   ILK_DPFCUNIT_CLOCK_GATE_DISABLE);
} else {
-   /* WaFbcAsynchFlipDisableFbcQueue */
+   /* WaFbcAsynchFlipDisableFbcQueue:hsw */
I915_WRITE(HSW_PIPE_SLICE_CHICKEN_1(intel_crtc->pipe),
   HSW_BYPASS_FBC_QUEUE);
-   /* WaFbcDisableDpfcClockGating */
+   /* WaFbcDisableDpfcClockGating:hsw */
I915_WRITE(HSW_CLKGATE_DISABLE_PART_1,
   I915_READ(HSW_CLKGATE_DISABLE_PART_1) |
   HSW_DPFC_GATING_DISABLE);
-- 
1.8.1.4

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

Re: [Intel-gfx] [PATCH] drm/i915: Compute WR PLL dividers dynamically

2013-05-10 Thread Daniel Vetter

On Fri, May 10, 2013 at 02:01:51PM +0100, Damien Lespiau wrote:
> Up to now, we were using a static table to match the clock frequency
> with a (r2,n2,p) triplet. Despite this table being big, it's by no mean
> comprehensive and we had to fall back to the closest frequency when the
> requested TMDS clock wasn't in the table.
> 
> This patch computes (r2,n2,p) dynamically and get rid of The Big Table.
> 
> v2: Replace the floating point constant 1e6 by 100
> 
> Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=58497
> Signed-off-by: Damien Lespiau 

Let's try again ;-)

Queued for -next (with a s/spaces/tab bikeshed applied), thanks for the patch.
-Daniel
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 617 
> ++-
>  1 file changed, 214 insertions(+), 403 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 1468932..5c35386 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -281,392 +281,6 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
>   DRM_ERROR("FDI link training failed!\n");
>  }
>  
> -/* 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.
> - * The code assumes this table is sorted. */
> -static const struct wrpll_tmds_clock wrpll_tmds_clock_table[] = {
> - {19750, 38, 25, 18},
> - {2, 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},
> - {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},
> - {3, 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},
> - {4, 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},
> - {5, 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},
> - {6, 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,

Re: [Intel-gfx] [PATCH] drm/i915: panel fitter hw state readout&check support

2013-05-10 Thread Daniel Vetter

On Fri, May 10, 2013 at 3:07 PM, Mika Kuoppala
 wrote:
> As discussed in irc, we might come across a case where panel fitter
> is not aligned to the same pipe in ilk+. Perhaps warn if we
> encounter such a weird setup?

Yeah, our current code doesn't support different pfit->pipe
associations. They're used since not all pipes have a high-quality 7x5
or 5x5 upscale mode. I think a WARN here for ivb/hsw is justified,
even when the old code wouldn't have supported this. I'll update the
patch
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: HSW FBC WaFbcDisableDpfcClockGating

2013-05-10 Thread Daniel Vetter

On Thu, May 09, 2013 at 02:20:50PM -0300, Rodrigo Vivi wrote:
> Display register 46500h bit 23 must be set to 1b for the entire time that
> Frame Buffer Compression is enabled.
> 
> v2: Ville suggested to enable it back when disabling fbc to avoid wasting
> power.
> 
> v3: RMW to preserve other bits (by Ville)
> v4: Fix from Ville: sed &/| at RMW
> v5: Too far on sed.
> 
> Cc: Ville Syrjälä 
> Reviewed-by: Ville Syrjälä 
> Signed-off-by: Rodrigo Vivi 

I've slurped in the entire series into dinq (which a whitespace fix added
for this patch here), thanks for the patches and review.

I'll drop my reservations here about enabling fbc by default on haswell,
expect a "told you so" if it blows up ;-)

Cheers, Daniel

> ---
>  drivers/gpu/drm/i915/i915_reg.h |  3 +++
>  drivers/gpu/drm/i915/intel_pm.c | 10 ++
>  2 files changed, 13 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index a17480e..40a59e5 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -986,6 +986,9 @@
>_HSW_PIPE_SLICE_CHICKEN_1_A, + \
>_HSW_PIPE_SLICE_CHICKEN_1_B)
>  
> +#define HSW_CLKGATE_DISABLE_PART_1   0x46500
> +#define   HSW_DPFC_GATING_DISABLE(1<<23)
> +
>  /*
>   * GPIO regs
>   */
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 3f4bf58..aedf5da 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -248,6 +248,12 @@ static void ironlake_disable_fbc(struct drm_device *dev)
>  I915_READ(ILK_DSPCLK_GATE_D) &
>  ~ILK_DPFCUNIT_CLOCK_GATE_DISABLE);
>  
> + if(IS_HASWELL(dev))
> + /* WaFbcDisableDpfcClockGating */
> + I915_WRITE(HSW_CLKGATE_DISABLE_PART_1,
> +I915_READ(HSW_CLKGATE_DISABLE_PART_1) &
> +~HSW_DPFC_GATING_DISABLE);
> +
>   DRM_DEBUG_KMS("disabled FBC\n");
>   }
>  }
> @@ -285,6 +291,10 @@ static void gen7_enable_fbc(struct drm_crtc *crtc, 
> unsigned long interval)
>   /* WaFbcAsynchFlipDisableFbcQueue */
>   I915_WRITE(HSW_PIPE_SLICE_CHICKEN_1(intel_crtc->pipe),
>  HSW_BYPASS_FBC_QUEUE);
> + /* WaFbcDisableDpfcClockGating */
> + I915_WRITE(HSW_CLKGATE_DISABLE_PART_1,
> +I915_READ(HSW_CLKGATE_DISABLE_PART_1) |
> +HSW_DPFC_GATING_DISABLE);
>   }
>  
>   I915_WRITE(SNB_DPFC_CTL_SA,
> -- 
> 1.7.11.7
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Use pipe_config state to disable ilk+ pfit

2013-05-10 Thread Mika Kuoppala

Daniel Vetter  writes:

> No more need to guard the write with a power well check on Haswell now
> that we have proper pfit state readout: We can simply only clear the
> pfit if it's actually on.
>
> This removes some duplication of knowledge between the haswell pfit
> disable and pfit state readout code about.
>
> While at it extract a little helper for this.
>
> Signed-off-by: Daniel Vetter 

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

Re: [Intel-gfx] [PATCH] drm/i915: panel fitter hw state readout&check support

2013-05-10 Thread Mika Kuoppala

Daniel Vetter  writes:

> On Fri, May 10, 2013 at 02:37:59PM +0300, Mika Kuoppala wrote:
>> 
>> Hi Daniel,
>> 
>> Daniel Vetter  writes:
>> 
>> > Pfit state readout is a bit ugly on gen2/3 due to the intermingling
>> > with the lvds state, but alas.
>> >
>> > Also note that since state is always cleared to zero we can
>> > unconditonally compare all the state and completely neglect the actual
>> > platform we're running on.
>> >
>> > v2: Properly check for the pfit power domain on haswell.
>> >
>> > v3: Don't check pgm_ratios on gen4+, they're auto-computed by the hw.
>> >
>> > v4: Properly clear the lvds border bits, upset the state checker a
>> > bit.
>> >
>> > v5: Unconditionally read out panel dither settings on gen2/3.
>> >
>> > Signed-off-by: Daniel Vetter 
>> > ---
>> >  drivers/gpu/drm/i915/intel_display.c | 67 
>> > ++--
>> >  drivers/gpu/drm/i915/intel_lvds.c|  1 +
>> >  2 files changed, 66 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> > b/drivers/gpu/drm/i915/intel_display.c
>> > index bfbb484..58395e3 100644
>> > --- a/drivers/gpu/drm/i915/intel_display.c
>> > +++ b/drivers/gpu/drm/i915/intel_display.c
>> > @@ -4967,6 +4967,36 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
>> >return ret;
>> >  }
>> >  
>> > +static void i9xx_get_pfit_config(struct intel_crtc *crtc,
>> > +   struct intel_crtc_config *pipe_config)
>> > +{
>> > +  struct drm_device *dev = crtc->base.dev;
>> > +  struct drm_i915_private *dev_priv = dev->dev_private;
>> > +  uint32_t tmp;
>> > +
>> > +  tmp = I915_READ(PFIT_CONTROL);
>> 
>> You could do
>> const uint32_t ctl = I915_READ(PFIT_CONTROL);
>> and...
>> 
>> > +  if (INTEL_INFO(dev)->gen < 4) {
>> > +  if (crtc->pipe != PIPE_B)
>> > +  return;
>> > +
>> > +  /* gen2/3 store dither state in pfit control, needs to match */
>> > +  pipe_config->gmch_pfit.control = tmp & PANEL_8TO6_DITHER_ENABLE;
>> > +  } else {
>> > +  if ((tmp & PFIT_PIPE_MASK) != (crtc->pipe << PFIT_PIPE_SHIFT))
>> > +  return;
>> > +  }
>> > +
>> > +  if (!(tmp & PFIT_ENABLE))
>> > +  return;
>> > +
>> > +  pipe_config->gmch_pfit.control = I915_READ(PFIT_CONTROL);
>> 
>> and use ctl in here to avoid extra read.
>
> Originally I've had that, but then thought it'd look more symmetric if I
> read out all the registers anew once we're sure that we're looking at the
> right panel fitter. I can do the cse again if you want.

Matter of taste bikeshedding it was. No need to change.

>> > +  pipe_config->gmch_pfit.pgm_ratios = I915_READ(PFIT_PGM_RATIOS);
>> > +  if (INTEL_INFO(dev)->gen < 5)
>> > +  pipe_config->gmch_pfit.lvds_border_bits =
>> > +  I915_READ(LVDS) & LVDS_BORDER_ENABLE;
>> > +}
>> > +
>> >  static bool i9xx_get_pipe_config(struct intel_crtc *crtc,
>> > struct intel_crtc_config *pipe_config)
>> >  {
>> > @@ -4980,6 +5010,8 @@ static bool i9xx_get_pipe_config(struct intel_crtc 
>> > *crtc,
>> >  
>> >intel_get_pipe_timings(crtc, pipe_config);
>> >  
>> > +  i9xx_get_pfit_config(crtc, pipe_config);
>> > +
>> >return true;
>> >  }
>> >  
>> > @@ -5815,6 +5847,21 @@ static void ironlake_get_fdi_m_n_config(struct 
>> > intel_crtc *crtc,
>> >   & TU_SIZE_MASK) >> TU_SIZE_SHIFT) + 1;
>> >  }
>> >  
>> > +static void ironlake_get_pfit_config(struct intel_crtc *crtc,
>> > +   struct intel_crtc_config *pipe_config)
>> > +{
>> > +  struct drm_device *dev = crtc->base.dev;
>> > +  struct drm_i915_private *dev_priv = dev->dev_private;
>> > +  uint32_t tmp;
>> > +
>> > +  tmp = I915_READ(PF_CTL(crtc->pipe));
>> > +
>> > +  if (tmp & PF_ENABLE) {
>> > +  pipe_config->pch_pfit.pos = I915_READ(PF_WIN_POS(crtc->pipe));
>> > +  pipe_config->pch_pfit.size = I915_READ(PF_WIN_SZ(crtc->pipe));
>> > +  }
>> > +}
>> > +
>> >  static bool ironlake_get_pipe_config(struct intel_crtc *crtc,
>> > struct intel_crtc_config *pipe_config)
>> >  {
>> > @@ -5838,6 +5885,8 @@ static bool ironlake_get_pipe_config(struct 
>> > intel_crtc *crtc,
>> >  
>> >intel_get_pipe_timings(crtc, pipe_config);
>> >  
>> > +  ironlake_get_pfit_config(crtc, pipe_config);
>> > +
>> >return true;
>> >  }
>> >  
>> > @@ -5957,6 +6006,7 @@ static bool haswell_get_pipe_config(struct 
>> > intel_crtc *crtc,
>> >struct drm_device *dev = crtc->base.dev;
>> >struct drm_i915_private *dev_priv = dev->dev_private;
>> >enum transcoder cpu_transcoder = crtc->config.cpu_transcoder;
>> > +  enum intel_display_power_domain pfit_domain;
>> >uint32_t tmp;
>> >  
>> >if (!intel_display_power_enabled(dev,
>> > @@ -5986,6 +6036,10 @@ static bool haswell_get_pipe_config(struct 
>> > intel_crtc *crtc,
>> >  
>> >intel_get_pipe_timings(crtc, pipe_config);
>> >  
>> > +  pfit_domain = POWER_DOMA

[Intel-gfx] [PATCH] drm/i915: Compute WR PLL dividers dynamically

2013-05-10 Thread Damien Lespiau

Up to now, we were using a static table to match the clock frequency
with a (r2,n2,p) triplet. Despite this table being big, it's by no mean
comprehensive and we had to fall back to the closest frequency when the
requested TMDS clock wasn't in the table.

This patch computes (r2,n2,p) dynamically and get rid of The Big Table.

v2: Replace the floating point constant 1e6 by 100

Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=58497
Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/i915/intel_ddi.c | 617 ++-
 1 file changed, 214 insertions(+), 403 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 1468932..5c35386 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -281,392 +281,6 @@ void hsw_fdi_link_train(struct drm_crtc *crtc)
DRM_ERROR("FDI link training failed!\n");
 }
 
-/* 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.
- * The code assumes this table is sorted. */
-static const struct wrpll_tmds_clock wrpll_tmds_clock_table[] = {
-   {19750, 38, 25, 18},
-   {2, 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},
-   {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},
-   {3, 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},
-   {4, 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},
-   {5, 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},
-   {6, 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},
-   {7, 14, 38, 22},
-   {66750, 10, 21, 17},
-   {67000, 14, 33, 19},
-   {67750, 14, 58, 33},
-   {68000, 14, 30, 17},
-   {68179, 14, 46, 26}

Re: [Intel-gfx] [PATCH] drm/i915: Compute WR PLL dividers dynamically

2013-05-10 Thread Damien Lespiau

On Wed, May 08, 2013 at 09:37:14PM +0200, Daniel Vetter wrote:
> Oops, blows up on 32bit machines. I guess the igt will be useful once more
> to check that the 32bit version is solid, too. Dropped from dinq for now.
> -Daniel

Oops indeed.

Turns out the mistake was an easy one to spot. I used 1e6 as a contant, which
is a double constant (!) and promoted the expression to a floating point
multiplication before casting it back to a 64 bits integer. The diff between
the problematic patch and the resent one (which will follow this mail) is quite
straightforward then:

$ git diff
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 9ee25e7..5c35386 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -530,8 +530,8 @@ static void wrpll_update_rnp(uint64_t freq2k, unsigned 
budget,
diff = ABS_DIFF((freq2k * p * r2), (LC_FREQ_2K * n2));
diff_best = ABS_DIFF((freq2k * best->p * best->r2),
 (LC_FREQ_2K * best->n2));
-   c = 1e6 * diff;
-   d = 1e6 * diff_best;
+   c = 100 * diff;
+   d = 100 * diff_best;

if (a < c && b < d) {
/* If both are above the budget, pick the closer */

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

Re: [Intel-gfx] [PATCH] drm/i915: Organize VBT stuff inside drm_i915_private

2013-05-10 Thread Daniel Vetter

On Thu, May 09, 2013 at 08:03:18PM -0300, Rodrigo Vivi wrote:
> drm_i915_private is getting bigger and bigger when adding new vbt stuff.
> So, the better way of getting drm_i915_private organized is to create
> a special structure for vbt stuff.
> 
> v2: Basically conflicts fixes
> 
> Reviewed-by: Jani Nikula 
> Signed-off-by: Rodrigo Vivi 

Queued for -next, thanks for the patch.
-Daniel
> ---
>  drivers/gpu/drm/i915/i915_dma.c  |   8 +--
>  drivers/gpu/drm/i915/i915_drv.h  |  57 +++-
>  drivers/gpu/drm/i915/intel_bios.c| 100 
> +--
>  drivers/gpu/drm/i915/intel_crt.c |   4 +-
>  drivers/gpu/drm/i915/intel_display.c |  12 ++---
>  drivers/gpu/drm/i915/intel_dp.c  |  18 +++
>  drivers/gpu/drm/i915/intel_lvds.c|  16 +++---
>  drivers/gpu/drm/i915/intel_pm.c  |   2 +-
>  drivers/gpu/drm/i915/intel_sdvo.c|   6 +--
>  drivers/gpu/drm/i915/intel_tv.c  |   8 +--
>  10 files changed, 119 insertions(+), 112 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index a1648eb..f5addac 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -1742,10 +1742,10 @@ int i915_driver_unload(struct drm_device *dev)
>* free the memory space allocated for the child device
>* config parsed from VBT
>*/
> - if (dev_priv->child_dev && dev_priv->child_dev_num) {
> - kfree(dev_priv->child_dev);
> - dev_priv->child_dev = NULL;
> - dev_priv->child_dev_num = 0;
> + if (dev_priv->vbt.child_dev && dev_priv->vbt.child_dev_num) {
> + kfree(dev_priv->vbt.child_dev);
> + dev_priv->vbt.child_dev = NULL;
> + dev_priv->vbt.child_dev_num = 0;
>   }
>  
>   vga_switcheroo_unregister_client(dev->pdev);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ab172c2..10d0fc4 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -889,6 +889,37 @@ enum modeset_restore {
>   MODESET_SUSPENDED,
>  };
>  
> +struct intel_vbt_data {
> + struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */
> + struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */
> +
> + /* Feature bits */
> + unsigned int int_tv_support:1;
> + unsigned int lvds_dither:1;
> + unsigned int lvds_vbt:1;
> + unsigned int int_crt_support:1;
> + unsigned int lvds_use_ssc:1;
> + unsigned int display_clock_mode:1;
> + unsigned int fdi_rx_polarity_inverted:1;
> + int lvds_ssc_freq;
> + unsigned int bios_lvds_val; /* initial [PCH_]LVDS reg val in VBIOS */
> +
> + /* eDP */
> + int edp_rate;
> + int edp_lanes;
> + int edp_preemphasis;
> + int edp_vswing;
> + bool edp_initialized;
> + bool edp_support;
> + int edp_bpp;
> + struct edp_power_seq edp_pps;
> +
> + int crt_ddc_pin;
> +
> + int child_dev_num;
> + struct child_device_config *child_dev;
> +};
> +
>  typedef struct drm_i915_private {
>   struct drm_device *dev;
>   struct kmem_cache *slab;
> @@ -968,6 +999,7 @@ typedef struct drm_i915_private {
>   struct intel_fbc_work *fbc_work;
>  
>   struct intel_opregion opregion;
> + struct intel_vbt_data vbt;
>  
>   /* overlay */
>   struct intel_overlay *overlay;
> @@ -984,31 +1016,8 @@ typedef struct drm_i915_private {
>   /* LVDS info */
>   struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */
>   struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */
> -
> - /* Feature bits from the VBIOS */
> - unsigned int int_tv_support:1;
> - unsigned int lvds_dither:1;
> - unsigned int lvds_vbt:1;
> - unsigned int int_crt_support:1;
> - unsigned int lvds_use_ssc:1;
> - unsigned int display_clock_mode:1;
> - unsigned int fdi_rx_polarity_inverted:1;
> - int lvds_ssc_freq;
> - unsigned int bios_lvds_val; /* initial [PCH_]LVDS reg val in VBIOS */
> - struct {
> - int rate;
> - int lanes;
> - int preemphasis;
> - int vswing;
> -
> - bool initialized;
> - bool support;
> - int bpp;
> - struct edp_power_seq pps;
> - } edp;
>   bool no_aux_handshake;
>  
> - int crt_ddc_pin;
>   struct drm_i915_fence_reg fence_regs[I915_MAX_NUM_FENCES]; /* assume 
> 965 */
>   int fence_reg_start; /* 4 if userland hasn't ioctl'd us yet */
>   int num_fence_regs; /* 8 on pre-965, 16 otherwise */
> @@ -1050,8 +1059,6 @@ typedef struct drm_i915_private {
>   /* indicates the reduced downclock for LVDS*/
>   int lvds_downclock;
>   u16 orig_clock;
> - int child_dev_num;
> - struct child_device_config *child_dev;
>  
>   bool mchbar_need_disable;
>  
>

[Intel-gfx] [PATCH 4/4] drm: Only print a debug message when the polled connector has changed

2013-05-10 Thread Damien Lespiau

Suggested-by: Chris Wilson 
Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/drm_crtc_helper.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 9085db6..ed1334e 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -1007,13 +1007,20 @@ static void output_poll_execute(struct work_struct 
*work)
continue;
 
connector->status = connector->funcs->detect(connector, false);
-   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to 
%s\n",
- connector->base.id,
- drm_get_connector_name(connector),
- drm_get_connector_status_name(old_status),
- drm_get_connector_status_name(connector->status));
-   if (old_status != connector->status)
+   if (old_status != connector->status) {
+   const char *old, *new;
+
+   old = drm_get_connector_status_name(old_status);
+   new = drm_get_connector_status_name(connector->status);
+
+   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] "
+ "status updated from %s to %s\n",
+ connector->base.id,
+ drm_get_connector_name(connector),
+ old, new);
+
changed = true;
+   }
}
 
mutex_unlock(&dev->mode_config.mutex);
-- 
1.8.1.4

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

[Intel-gfx] [PATCH 3/4] drm: Don't prune modes loudly when a connector is disconnected

2013-05-10 Thread Damien Lespiau

drm_helper_probe_single_connector_modes() is responsible for pruning the
previously detected modes on a disconnected connector. We don't really
need to log, again, the full list of modes that used to be valid when
connected.

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/drm_crtc_helper.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index e447396..9085db6 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -121,6 +121,7 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
connector->helper_private;
int count = 0;
int mode_flags = 0;
+   bool verbose_prune = true;
 
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
drm_get_connector_name(connector));
@@ -149,6 +150,7 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
connector->base.id, drm_get_connector_name(connector));
drm_mode_connector_update_edid_property(connector, NULL);
+   verbose_prune = false;
goto prune;
}
 
@@ -182,7 +184,7 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
}
 
 prune:
-   drm_mode_prune_invalid(dev, &connector->modes, true);
+   drm_mode_prune_invalid(dev, &connector->modes, verbose_prune);
 
if (list_empty(&connector->modes))
return 0;
-- 
1.8.1.4

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

[Intel-gfx] [PATCH 2/4] drm: Make the HPD status updates debug logs more readable

2013-05-10 Thread Damien Lespiau

Instead of just printing "status updated from 1 to 2", make those enum
numbers immediately readable.

v2: Also patch output_poll_execute() (Daniel Vetter)
v3: Use drm_get_connector_status_name (Ville Syrjälä)

Signed-off-by: Damien Lespiau 
Reviewed-by: Jesse Barnes  (for v1)
---
 drivers/gpu/drm/drm_crtc.c|  1 +
 drivers/gpu/drm/drm_crtc_helper.c | 10 ++
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 3a8f7e6d..6b1e4b5 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -246,6 +246,7 @@ char *drm_get_connector_status_name(enum 
drm_connector_status status)
else
return "unknown";
 }
+EXPORT_SYMBOL(drm_get_connector_status_name);
 
 /**
  * drm_mode_object_get - allocate a new modeset identifier
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index e974f93..e447396 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -1005,10 +1005,11 @@ static void output_poll_execute(struct work_struct 
*work)
continue;
 
connector->status = connector->funcs->detect(connector, false);
-   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to 
%d\n",
+   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to 
%s\n",
  connector->base.id,
  drm_get_connector_name(connector),
- old_status, connector->status);
+ drm_get_connector_status_name(old_status),
+ drm_get_connector_status_name(connector->status));
if (old_status != connector->status)
changed = true;
}
@@ -1083,10 +1084,11 @@ void drm_helper_hpd_irq_event(struct drm_device *dev)
old_status = connector->status;
 
connector->status = connector->funcs->detect(connector, false);
-   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d to 
%d\n",
+   DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to 
%s\n",
  connector->base.id,
  drm_get_connector_name(connector),
- old_status, connector->status);
+ drm_get_connector_status_name(old_status),
+ drm_get_connector_status_name(connector->status));
if (old_status != connector->status)
changed = true;
}
-- 
1.8.1.4

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

[Intel-gfx] [PATCH 1/4] drm: Add missing break in the command line mode parsing code

2013-05-10 Thread Damien Lespiau

As we parse the string given on the command line one char at a time, it
seems that we do want a break at every case.

Signed-off-by: Damien Lespiau 
Reviewed-by: Rodrigo Vivi 
---
 drivers/gpu/drm/drm_modes.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index f264d08..7a83836 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1143,6 +1143,7 @@ bool drm_mode_parse_command_line_for_connector(const char 
*mode_option,
was_digit = false;
} else
goto done;
+   break;
case '0' ... '9':
was_digit = true;
break;
-- 
1.8.1.4

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

[Intel-gfx] Some lost drm patches v2

2013-05-10 Thread Damien Lespiau

Updated series with:

- Reviews applied,
- Drop a patch that would conflict with Ville's latest changes,
- Drop Chris (Cummins)'s patch as he rebased it on top of drm-next and sent it
  back himself,
- Add a suggestion from Chris (Wilson) to not repeat the message in the poll
  handler. I did not do that for the irq helper as it might be useful to detect
  spurious interrupts.
 
-- 
Damien

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

[Intel-gfx] [PATCH 03/11] drm/i915: take msecs_to_jiffies_min into use

2013-05-10 Thread Imre Deak

Use msecs_to_jiffies_min instead of open-coding the same.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_dp.c  |2 +-
 drivers/gpu/drm/i915/intel_drv.h |2 +-
 drivers/gpu/drm/i915/intel_i2c.c |2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 92d1334..8be304d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -276,7 +276,7 @@ intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool 
has_aux_irq)
 #define C (((status = I915_READ_NOTRACE(ch_ctl)) & DP_AUX_CH_CTL_SEND_BUSY) == 
0)
if (has_aux_irq)
done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
- msecs_to_jiffies(10) + 1);
+ msecs_to_jiffies_min(10));
else
done = wait_for_atomic(C, 10) == 0;
if (!done && !(C))
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 388a394..f2e3409 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -42,7 +42,7 @@
  * we've never had a chance to check the condition before the timeout.
  */
 #define _wait_for(COND, MS, W) ({ \
-   unsigned long timeout__ = jiffies + msecs_to_jiffies(MS) + 1;   \
+   unsigned long timeout__ = jiffies + msecs_to_jiffies_min(MS);   \
int ret__ = 0;  \
while (!(COND)) {   \
if (time_after(jiffies, timeout__)) {   \
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 5d24503..447b4b0 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -228,7 +228,7 @@ gmbus_wait_hw_status(struct drm_i915_private *dev_priv,
 * need to wake up periodically and check that ourselves. */
I915_WRITE(GMBUS4 + reg_offset, gmbus4_irq_en);
 
-   for (i = 0; i < msecs_to_jiffies(50) + 1; i++) {
+   for (i = 0; i < msecs_to_jiffies_min(50); i++) {
prepare_to_wait(&dev_priv->gmbus_wait_queue, &wait,
TASK_UNINTERRUPTIBLE);
 
-- 
1.7.10.4

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

Re: [Intel-gfx] [PATCH] drm/i915: panel fitter hw state readout&check support

2013-05-10 Thread Daniel Vetter

On Fri, May 10, 2013 at 02:37:59PM +0300, Mika Kuoppala wrote:
> 
> Hi Daniel,
> 
> Daniel Vetter  writes:
> 
> > Pfit state readout is a bit ugly on gen2/3 due to the intermingling
> > with the lvds state, but alas.
> >
> > Also note that since state is always cleared to zero we can
> > unconditonally compare all the state and completely neglect the actual
> > platform we're running on.
> >
> > v2: Properly check for the pfit power domain on haswell.
> >
> > v3: Don't check pgm_ratios on gen4+, they're auto-computed by the hw.
> >
> > v4: Properly clear the lvds border bits, upset the state checker a
> > bit.
> >
> > v5: Unconditionally read out panel dither settings on gen2/3.
> >
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 67 
> > ++--
> >  drivers/gpu/drm/i915/intel_lvds.c|  1 +
> >  2 files changed, 66 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index bfbb484..58395e3 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -4967,6 +4967,36 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
> > return ret;
> >  }
> >  
> > +static void i9xx_get_pfit_config(struct intel_crtc *crtc,
> > +struct intel_crtc_config *pipe_config)
> > +{
> > +   struct drm_device *dev = crtc->base.dev;
> > +   struct drm_i915_private *dev_priv = dev->dev_private;
> > +   uint32_t tmp;
> > +
> > +   tmp = I915_READ(PFIT_CONTROL);
> 
> You could do
> const uint32_t ctl = I915_READ(PFIT_CONTROL);
> and...
> 
> > +   if (INTEL_INFO(dev)->gen < 4) {
> > +   if (crtc->pipe != PIPE_B)
> > +   return;
> > +
> > +   /* gen2/3 store dither state in pfit control, needs to match */
> > +   pipe_config->gmch_pfit.control = tmp & PANEL_8TO6_DITHER_ENABLE;
> > +   } else {
> > +   if ((tmp & PFIT_PIPE_MASK) != (crtc->pipe << PFIT_PIPE_SHIFT))
> > +   return;
> > +   }
> > +
> > +   if (!(tmp & PFIT_ENABLE))
> > +   return;
> > +
> > +   pipe_config->gmch_pfit.control = I915_READ(PFIT_CONTROL);
> 
> and use ctl in here to avoid extra read.

Originally I've had that, but then thought it'd look more symmetric if I
read out all the registers anew once we're sure that we're looking at the
right panel fitter. I can do the cse again if you want.

> > +   pipe_config->gmch_pfit.pgm_ratios = I915_READ(PFIT_PGM_RATIOS);
> > +   if (INTEL_INFO(dev)->gen < 5)
> > +   pipe_config->gmch_pfit.lvds_border_bits =
> > +   I915_READ(LVDS) & LVDS_BORDER_ENABLE;
> > +}
> > +
> >  static bool i9xx_get_pipe_config(struct intel_crtc *crtc,
> >  struct intel_crtc_config *pipe_config)
> >  {
> > @@ -4980,6 +5010,8 @@ static bool i9xx_get_pipe_config(struct intel_crtc 
> > *crtc,
> >  
> > intel_get_pipe_timings(crtc, pipe_config);
> >  
> > +   i9xx_get_pfit_config(crtc, pipe_config);
> > +
> > return true;
> >  }
> >  
> > @@ -5815,6 +5847,21 @@ static void ironlake_get_fdi_m_n_config(struct 
> > intel_crtc *crtc,
> >& TU_SIZE_MASK) >> TU_SIZE_SHIFT) + 1;
> >  }
> >  
> > +static void ironlake_get_pfit_config(struct intel_crtc *crtc,
> > +struct intel_crtc_config *pipe_config)
> > +{
> > +   struct drm_device *dev = crtc->base.dev;
> > +   struct drm_i915_private *dev_priv = dev->dev_private;
> > +   uint32_t tmp;
> > +
> > +   tmp = I915_READ(PF_CTL(crtc->pipe));
> > +
> > +   if (tmp & PF_ENABLE) {
> > +   pipe_config->pch_pfit.pos = I915_READ(PF_WIN_POS(crtc->pipe));
> > +   pipe_config->pch_pfit.size = I915_READ(PF_WIN_SZ(crtc->pipe));
> > +   }
> > +}
> > +
> >  static bool ironlake_get_pipe_config(struct intel_crtc *crtc,
> >  struct intel_crtc_config *pipe_config)
> >  {
> > @@ -5838,6 +5885,8 @@ static bool ironlake_get_pipe_config(struct 
> > intel_crtc *crtc,
> >  
> > intel_get_pipe_timings(crtc, pipe_config);
> >  
> > +   ironlake_get_pfit_config(crtc, pipe_config);
> > +
> > return true;
> >  }
> >  
> > @@ -5957,6 +6006,7 @@ static bool haswell_get_pipe_config(struct intel_crtc 
> > *crtc,
> > struct drm_device *dev = crtc->base.dev;
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > enum transcoder cpu_transcoder = crtc->config.cpu_transcoder;
> > +   enum intel_display_power_domain pfit_domain;
> > uint32_t tmp;
> >  
> > if (!intel_display_power_enabled(dev,
> > @@ -5986,6 +6036,10 @@ static bool haswell_get_pipe_config(struct 
> > intel_crtc *crtc,
> >  
> > intel_get_pipe_timings(crtc, pipe_config);
> >  
> > +   pfit_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe);
> > +   if (intel_display_power_enabled(dev, pfit_domain))
> > +   ironlake_get_pfit_config(crtc, pipe_config);
> > +
> > return t

Re: [Intel-gfx] [PATCH 6/7] drm/i915: make SDVO TV-out work for multifunction devices

2013-05-10 Thread Jani Nikula

On Tue, 30 Apr 2013, Daniel Vetter  wrote:
> We need to track this correctly. While at it shovel the boolean
> to track whether the sdvo is in tv mode or not into pipe_config.

Reviewed-by: Jani Nikula 

> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36997
> Tested-by: Pierre Assal 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36997
> Tested-by: cancan,feng 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 8 +++-
>  drivers/gpu/drm/i915/intel_drv.h | 5 -
>  drivers/gpu/drm/i915/intel_sdvo.c| 8 ++--
>  3 files changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 44bcfae..ef0d27b 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4546,7 +4546,7 @@ static void i9xx_update_pll(struct intel_crtc *crtc,
>   if (INTEL_INFO(dev)->gen >= 4)
>   dpll |= (6 << PLL_LOAD_PULSE_PHASE_SHIFT);
>  
> - if (is_sdvo && intel_pipe_has_type(&crtc->base, INTEL_OUTPUT_TVOUT))
> + if (crtc->config.sdvo_tv_clock)
>   dpll |= PLL_REF_INPUT_TVCLKINBC;
>   else if (intel_pipe_has_type(&crtc->base, INTEL_OUTPUT_LVDS) &&
>intel_panel_use_ssc(dev_priv) && num_connectors < 2)
> @@ -5590,7 +5590,7 @@ static uint32_t ironlake_compute_dpll(struct intel_crtc 
> *intel_crtc,
>   struct intel_encoder *intel_encoder;
>   uint32_t dpll;
>   int factor, num_connectors = 0;
> - bool is_lvds = false, is_sdvo = false, is_tv = false;
> + bool is_lvds = false, is_sdvo = false;
>  
>   for_each_encoder_on_crtc(dev, crtc, intel_encoder) {
>   switch (intel_encoder->type) {
> @@ -5600,8 +5600,6 @@ static uint32_t ironlake_compute_dpll(struct intel_crtc 
> *intel_crtc,
>   case INTEL_OUTPUT_SDVO:
>   case INTEL_OUTPUT_HDMI:
>   is_sdvo = true;
> - if (intel_encoder->needs_tv_clock)
> - is_tv = true;
>   break;
>   }
>  
> @@ -5615,7 +5613,7 @@ static uint32_t ironlake_compute_dpll(struct intel_crtc 
> *intel_crtc,
>dev_priv->lvds_ssc_freq == 100) ||
>   (HAS_PCH_IBX(dev) && intel_is_dual_link_lvds(dev)))
>   factor = 25;
> - } else if (is_sdvo && is_tv)
> + } else if (intel_crtc->config.sdvo_tv_clock)
>   factor = 20;
>  
>   if (ironlake_needs_fb_cb_tune(&intel_crtc->config.dpll, factor))
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 766afcf..be196ff 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -120,7 +120,6 @@ struct intel_encoder {
>   struct intel_crtc *new_crtc;
>  
>   int type;
> - bool needs_tv_clock;
>   /*
>* Intel hw has only one MUX where encoders could be clone, hence a
>* simple flag is enough to compute the possible_clones mask.
> @@ -223,6 +222,10 @@ struct intel_crtc_config {
>   /* Controls for the clock computation, to override various stages. */
>   bool clock_set;
>  
> + /* SDVO TV has a bunch of special case. To make multifunction encoders
> +  * work correctly, we need to track this at runtime.*/
> + bool sdvo_tv_clock;
> +
>   /*
>* crtc bandwidth limit, don't increase pipe bpp or clock if not really
>* required. This is set in the 2nd loop of calling encoder's
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index f6bf9fc..3a1d710 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -1092,6 +1092,7 @@ static bool intel_sdvo_compute_config(struct 
> intel_encoder *encoder,
>   (void) intel_sdvo_get_preferred_input_mode(intel_sdvo,
>  mode,
>  adjusted_mode);
> + pipe_config->sdvo_tv_clock = true;
>   } else if (intel_sdvo->is_lvds) {
>   if (!intel_sdvo_set_output_timings_from_mode(intel_sdvo,
>
> intel_sdvo->sdvo_lvds_fixed_mode))
> @@ -1655,12 +1656,9 @@ intel_sdvo_detect(struct drm_connector *connector, 
> bool force)
>   if (ret == connector_status_connected) {
>   intel_sdvo->is_tv = false;
>   intel_sdvo->is_lvds = false;
> - intel_sdvo->base.needs_tv_clock = false;
>  
> - if (response & SDVO_TV_MASK) {
> + if (response & SDVO_TV_MASK)
>   intel_sdvo->is_tv = true;
> - intel_sdvo->base.needs_tv_clock = true;
> - }
>   if (response & SDVO_LVDS_MASK)
>   intel_sdvo->is_lvds = intel_sdvo->sdvo_lvds_fixed_mode 
> != NULL;

Re: [Intel-gfx] [PATCH 7/7] drm/i915: rip out an unused lvds_reg variable

2013-05-10 Thread Jani Nikula

On Tue, 30 Apr 2013, Daniel Vetter  wrote:
> Somehow this has been forgotten in
>
> commit 1974cad0ee4ce84e5cb792e49c4f0d9421e0312c
> Author: Daniel Vetter 
> Date:   Mon Nov 26 17:22:09 2012 +0100
>
> drm/i915: move is_dual_link_lvds to intel_lvds.c
>

Reviewed-by: Jani Nikula 

> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 6 --
>  1 file changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index ef0d27b..30f452e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -651,12 +651,6 @@ intel_g4x_find_best_PLL(const intel_limit_t *limit, 
> struct drm_crtc *crtc,
>   found = false;
>  
>   if (intel_pipe_has_type(crtc, INTEL_OUTPUT_LVDS)) {
> - int lvds_reg;
> -
> - if (HAS_PCH_SPLIT(dev))
> - lvds_reg = PCH_LVDS;
> - else
> - lvds_reg = LVDS;
>   if (intel_is_dual_link_lvds(dev))
>   clock.p2 = limit->p2.p2_fast;
>   else
> -- 
> 1.7.11.7
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/7] drm/i915: rip out now unused is_foo tracking from crtc code

2013-05-10 Thread Jani Nikula

On Tue, 30 Apr 2013, Daniel Vetter  wrote:
> More ugly stuff gone for good! The big special case left now is
> lvds (which is indeed really special).

Reviewed-by: Jani Nikula 

A follow-up patch could switch the switches to ifs for the OCD folks. ;)

> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 28 +++-
>  1 file changed, 3 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index e68d26a..44bcfae 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4833,8 +4833,8 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
>   int refclk, num_connectors = 0;
>   intel_clock_t clock, reduced_clock;
>   u32 dspcntr;
> - bool ok, has_reduced_clock = false, is_sdvo = false;
> - bool is_lvds = false, is_tv = false;
> + bool ok, has_reduced_clock = false;
> + bool is_lvds = false;
>   struct intel_encoder *encoder;
>   const intel_limit_t *limit;
>   int ret;
> @@ -4844,15 +4844,6 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
>   case INTEL_OUTPUT_LVDS:
>   is_lvds = true;
>   break;
> - case INTEL_OUTPUT_SDVO:
> - case INTEL_OUTPUT_HDMI:
> - is_sdvo = true;
> - if (encoder->needs_tv_clock)
> - is_tv = true;
> - break;
> - case INTEL_OUTPUT_TVOUT:
> - is_tv = true;
> - break;
>   }
>  
>   num_connectors++;
> @@ -5291,7 +5282,6 @@ static int ironlake_get_refclk(struct drm_crtc *crtc)
>   struct drm_device *dev = crtc->dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   struct intel_encoder *encoder;
> - struct intel_encoder *edp_encoder = NULL;
>   int num_connectors = 0;
>   bool is_lvds = false;
>  
> @@ -5300,9 +5290,6 @@ static int ironlake_get_refclk(struct drm_crtc *crtc)
>   case INTEL_OUTPUT_LVDS:
>   is_lvds = true;
>   break;
> - case INTEL_OUTPUT_EDP:
> - edp_encoder = encoder;
> - break;
>   }
>   num_connectors++;
>   }
> @@ -5461,22 +5448,13 @@ static bool ironlake_compute_clocks(struct drm_crtc 
> *crtc,
>   struct intel_encoder *intel_encoder;
>   int refclk;
>   const intel_limit_t *limit;
> - bool ret, is_sdvo = false, is_tv = false, is_lvds = false;
> + bool ret, is_lvds = false;
>  
>   for_each_encoder_on_crtc(dev, crtc, intel_encoder) {
>   switch (intel_encoder->type) {
>   case INTEL_OUTPUT_LVDS:
>   is_lvds = true;
>   break;
> - case INTEL_OUTPUT_SDVO:
> - case INTEL_OUTPUT_HDMI:
> - is_sdvo = true;
> - if (intel_encoder->needs_tv_clock)
> - is_tv = true;
> - break;
> - case INTEL_OUTPUT_TVOUT:
> - is_tv = true;
> - break;
>   }
>   }
>  
> -- 
> 1.7.11.7
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: panel fitter hw state readout&check support

2013-05-10 Thread Mika Kuoppala


Hi Daniel,

Daniel Vetter  writes:

> Pfit state readout is a bit ugly on gen2/3 due to the intermingling
> with the lvds state, but alas.
>
> Also note that since state is always cleared to zero we can
> unconditonally compare all the state and completely neglect the actual
> platform we're running on.
>
> v2: Properly check for the pfit power domain on haswell.
>
> v3: Don't check pgm_ratios on gen4+, they're auto-computed by the hw.
>
> v4: Properly clear the lvds border bits, upset the state checker a
> bit.
>
> v5: Unconditionally read out panel dither settings on gen2/3.
>
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 67 
> ++--
>  drivers/gpu/drm/i915/intel_lvds.c|  1 +
>  2 files changed, 66 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index bfbb484..58395e3 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4967,6 +4967,36 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
>   return ret;
>  }
>  
> +static void i9xx_get_pfit_config(struct intel_crtc *crtc,
> +  struct intel_crtc_config *pipe_config)
> +{
> + struct drm_device *dev = crtc->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + uint32_t tmp;
> +
> + tmp = I915_READ(PFIT_CONTROL);

You could do
const uint32_t ctl = I915_READ(PFIT_CONTROL);
and...

> + if (INTEL_INFO(dev)->gen < 4) {
> + if (crtc->pipe != PIPE_B)
> + return;
> +
> + /* gen2/3 store dither state in pfit control, needs to match */
> + pipe_config->gmch_pfit.control = tmp & PANEL_8TO6_DITHER_ENABLE;
> + } else {
> + if ((tmp & PFIT_PIPE_MASK) != (crtc->pipe << PFIT_PIPE_SHIFT))
> + return;
> + }
> +
> + if (!(tmp & PFIT_ENABLE))
> + return;
> +
> + pipe_config->gmch_pfit.control = I915_READ(PFIT_CONTROL);

and use ctl in here to avoid extra read.

> + pipe_config->gmch_pfit.pgm_ratios = I915_READ(PFIT_PGM_RATIOS);
> + if (INTEL_INFO(dev)->gen < 5)
> + pipe_config->gmch_pfit.lvds_border_bits =
> + I915_READ(LVDS) & LVDS_BORDER_ENABLE;
> +}
> +
>  static bool i9xx_get_pipe_config(struct intel_crtc *crtc,
>struct intel_crtc_config *pipe_config)
>  {
> @@ -4980,6 +5010,8 @@ static bool i9xx_get_pipe_config(struct intel_crtc 
> *crtc,
>  
>   intel_get_pipe_timings(crtc, pipe_config);
>  
> + i9xx_get_pfit_config(crtc, pipe_config);
> +
>   return true;
>  }
>  
> @@ -5815,6 +5847,21 @@ static void ironlake_get_fdi_m_n_config(struct 
> intel_crtc *crtc,
>  & TU_SIZE_MASK) >> TU_SIZE_SHIFT) + 1;
>  }
>  
> +static void ironlake_get_pfit_config(struct intel_crtc *crtc,
> +  struct intel_crtc_config *pipe_config)
> +{
> + struct drm_device *dev = crtc->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + uint32_t tmp;
> +
> + tmp = I915_READ(PF_CTL(crtc->pipe));
> +
> + if (tmp & PF_ENABLE) {
> + pipe_config->pch_pfit.pos = I915_READ(PF_WIN_POS(crtc->pipe));
> + pipe_config->pch_pfit.size = I915_READ(PF_WIN_SZ(crtc->pipe));
> + }
> +}
> +
>  static bool ironlake_get_pipe_config(struct intel_crtc *crtc,
>struct intel_crtc_config *pipe_config)
>  {
> @@ -5838,6 +5885,8 @@ static bool ironlake_get_pipe_config(struct intel_crtc 
> *crtc,
>  
>   intel_get_pipe_timings(crtc, pipe_config);
>  
> + ironlake_get_pfit_config(crtc, pipe_config);
> +
>   return true;
>  }
>  
> @@ -5957,6 +6006,7 @@ static bool haswell_get_pipe_config(struct intel_crtc 
> *crtc,
>   struct drm_device *dev = crtc->base.dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   enum transcoder cpu_transcoder = crtc->config.cpu_transcoder;
> + enum intel_display_power_domain pfit_domain;
>   uint32_t tmp;
>  
>   if (!intel_display_power_enabled(dev,
> @@ -5986,6 +6036,10 @@ static bool haswell_get_pipe_config(struct intel_crtc 
> *crtc,
>  
>   intel_get_pipe_timings(crtc, pipe_config);
>  
> + pfit_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe);
> + if (intel_display_power_enabled(dev, pfit_domain))
> + ironlake_get_pfit_config(crtc, pipe_config);
> +
>   return true;
>  }
>  
> @@ -7961,7 +8015,8 @@ intel_modeset_update_state(struct drm_device *dev, 
> unsigned prepare_pipes)
>   if (mask & (1 <<(intel_crtc)->pipe))
>  
>  static bool
> -intel_pipe_config_compare(struct intel_crtc_config *current_config,
> +intel_pipe_config_compare(struct drm_device *dev,
> +   struct intel_crtc_config *current_config,
> struct intel_crtc_config *pipe_conf

Re: [Intel-gfx] [PATCH 4/7] drm/i915: rip out TV-out lore ...

2013-05-10 Thread Jani Nikula

On Tue, 30 Apr 2013, Daniel Vetter  wrote:
> This seems to be an impressive piece of copy&pasta lore. I've
> checked all docs and on most platforms these bits are all MBZ, with
> the exception of the SDVO pixel multiplier on gen3. On gen4 that
> moved to a special DPLL_MD registers.
>
> No indication whatsoever that we actually need this for native
> TV-out support. I suspect this started as a hack when we didn't
> yet have proper pixel multiplier support in place for SDVO TV, but
> then got stuck in a life of its own.
>
> Just rip it out.
>
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 317e055..e68d26a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4548,10 +4548,6 @@ static void i9xx_update_pll(struct intel_crtc *crtc,
>  
>   if (is_sdvo && intel_pipe_has_type(&crtc->base, INTEL_OUTPUT_TVOUT))
>   dpll |= PLL_REF_INPUT_TVCLKINBC;
> - else if (intel_pipe_has_type(&crtc->base, INTEL_OUTPUT_TVOUT))
> - /* XXX: just matching BIOS for now */
> - /*  dpll |= PLL_REF_INPUT_TVCLKINBC; */
> - dpll |= 3;

I found a g45 spec saying this about bits 7:0 on CTG:

"FPB1 P1 Post Divisor: Writes to this byte cause the staging register
 contents to be written into the active register when in the VGA mode of
 operation. This will also occur when the VGA MSR register is written."

Additionally 3 is an illegal value...

Reviewed-by: Jani Nikula 


>   else if (intel_pipe_has_type(&crtc->base, INTEL_OUTPUT_LVDS) &&
>intel_panel_use_ssc(dev_priv) && num_connectors < 2)
>   dpll |= PLLB_REF_INPUT_SPREADSPECTRUMIN;
> -- 
> 1.7.11.7
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] fbcon issues oh hd4000

2013-05-10 Thread Daniel Vetter

On Fri, May 10, 2013 at 1:26 PM, Fabio Coatti  wrote:
> Hi Daniel,
> I'm contacting you as you are listed as i915 maintainer for linux
> kernel and I'm not sure if it is ok to write in mailing lists for this
> small issue.

_Always_ cc a mailing list, since your maintainer tends to be busy.
_Especially_ for small stuff.

> I'm having an issue that should be easy to fix, but it turned out to be not :)
>
> Basically, the issue is the "classical" blank console during boot (it
> becomes blank after some messages, when i915 driver kicks in, I guess)
> and the screen is resumed when X starts.
> (happens with 3.9.1 but also with 3.8.X).
> The machine is a i7 3770 / Q77 chipset (HD4000 afaik)
> As I said it should be easy to fix, according to all similar solved
> issues tha I got googling, but I tried all combinations of kernel
> boot parameters that I can think of (i915.modeset=1, video=HDMI-2:D,
> fbcon=map:X, and so on); I used i915 as module and compiled in, with
> initrd, but no joy so far.
> Weird thing, on a different hardware but same family (i5,HD3000) all
> works just fine with same kernel options and this command line:

That's not the same family, but a different product generation ;-)

> console=tty1  fbcon=map:0 i915.modeset=1
>
> Of course I'm not asking you to help debugging my installation, But
> can you point me to some link, hint or whatever useful in order to
> look better at this issue?

Sounds like the fbcon mode selection gets something wrong which X gets
right. Please retest on the latest upstream kernel and if that still
fails please boot with drm.debug=0xe (and no other parameter added)
and file a bug report  on bugs.freedesktop.org against dri -> drm
(intel) with the complete dmesg attached.

Thanks, Daniel

> Many thanks for any suggestion.
>
>
> --
> Fabio



--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/7] drm/i915: drop TVclock special casing on ilk+

2013-05-10 Thread Jani Nikula

On Tue, 30 Apr 2013, Daniel Vetter  wrote:
> TV-out uses the same reference clock as everyone else. The only
> difference seems to be in the slightly different CB tuning limit.
>
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 11 +--
>  1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index f10f094..317e055 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5629,9 +5629,6 @@ static uint32_t ironlake_compute_dpll(struct intel_crtc 
> *intel_crtc,
>   if (intel_encoder->needs_tv_clock)
>   is_tv = true;
>   break;
> - case INTEL_OUTPUT_TVOUT:
> - is_tv = true;
> - break;

An observation, this code path is actually dead code for ilk+, as is the
else if (is_tv) branch below. Good riddance.

>   }
>  
>   num_connectors++;
> @@ -5690,13 +5687,7 @@ static uint32_t ironlake_compute_dpll(struct 
> intel_crtc *intel_crtc,
>   break;
>   }
>  
> - if (is_sdvo && is_tv)
> - dpll |= PLL_REF_INPUT_TVCLKINBC;

The commit message could reflect that this is actually a reserved value
in the register spec. With that bikeshed,

Reviewed-by: Jani Nikula 

> - else if (is_tv)
> - /* XXX: just matching BIOS for now */
> - /*  dpll |= PLL_REF_INPUT_TVCLKINBC; */
> - dpll |= 3;
> - else if (is_lvds && intel_panel_use_ssc(dev_priv) && num_connectors < 2)
> + if (is_lvds && intel_panel_use_ssc(dev_priv) && num_connectors < 2)
>   dpll |= PLLB_REF_INPUT_SPREADSPECTRUMIN;
>   else
>   dpll |= PLL_REF_INPUT_DREFCLK;
> -- 
> 1.7.11.7
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/7] drm/i915: move sdvo TV clock computation to intel_sdvo.c

2013-05-10 Thread Jani Nikula

On Tue, 30 Apr 2013, Daniel Vetter  wrote:
> We have a very nice infrastructure for this now!
>
> Note that the multifunction sdvo support is pretty neatly broken: We
> completely ignore userspace's request for which connector to wire up
> with the encoder and just use whatever the last detect callback has
> seen.
>
> Not something I'll fix in this patch, but unfortunately something
> which is also broken in the DDI code ...
>
> v2: Don't call sdvo_tv_clock twice.
>
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 30 --
>  drivers/gpu/drm/i915/intel_sdvo.c| 30 ++
>  2 files changed, 30 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 1128f83..f10f094 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4286,30 +4286,6 @@ static int i9xx_get_refclk(struct drm_crtc *crtc, int 
> num_connectors)
>   return refclk;
>  }
>  
> -static void i9xx_adjust_sdvo_tv_clock(struct intel_crtc *crtc)
> -{
> - unsigned dotclock = crtc->config.adjusted_mode.clock;
> - struct dpll *clock = &crtc->config.dpll;
> -
> - /* SDVO TV has fixed PLL values depend on its clock range,
> -this mirrors vbios setting. */
> - if (dotclock >= 10 && dotclock < 140500) {
> - clock->p1 = 2;
> - clock->p2 = 10;
> - clock->n = 3;
> - clock->m1 = 16;
> - clock->m2 = 8;
> - } else if (dotclock >= 140500 && dotclock <= 20) {
> - clock->p1 = 1;
> - clock->p2 = 10;
> - clock->n = 6;
> - clock->m1 = 12;
> - clock->m2 = 8;
> - }
> -
> - crtc->config.clock_set = true;
> -}
> -
>  static uint32_t pnv_dpll_compute_fp(struct dpll *dpll)
>  {
>   return (1 << dpll->n) << 16 | dpll->m1 << 8 | dpll->m2;
> @@ -4926,9 +4902,6 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
>   intel_crtc->config.dpll.p2 = clock.p2;
>   }
>  
> - if (is_sdvo && is_tv)
> - i9xx_adjust_sdvo_tv_clock(intel_crtc);
> -
>   if (IS_GEN2(dev))
>   i8xx_update_pll(intel_crtc, adjusted_mode,
>   has_reduced_clock ? &reduced_clock : NULL,
> @@ -5538,9 +5511,6 @@ static bool ironlake_compute_clocks(struct drm_crtc 
> *crtc,
>reduced_clock);
>   }
>  
> - if (is_sdvo && is_tv)
> - i9xx_adjust_sdvo_tv_clock(to_intel_crtc(crtc));
> -

With this change, is_sdvo and is_tv are no longer used, and could be
dropped from the function. All the same,

Reviewed-by: Jani Nikula 

>   return true;
>  }
>  
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index d154284..f6bf9fc 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -1041,6 +1041,32 @@ intel_sdvo_get_preferred_input_mode(struct intel_sdvo 
> *intel_sdvo,
>   return true;
>  }
>  
> +static void i9xx_adjust_sdvo_tv_clock(struct intel_crtc_config *pipe_config)
> +{
> + unsigned dotclock = pipe_config->adjusted_mode.clock;
> + struct dpll *clock = &pipe_config->dpll;
> +
> + /* SDVO TV has fixed PLL values depend on its clock range,
> +this mirrors vbios setting. */
> + if (dotclock >= 10 && dotclock < 140500) {
> + clock->p1 = 2;
> + clock->p2 = 10;
> + clock->n = 3;
> + clock->m1 = 16;
> + clock->m2 = 8;
> + } else if (dotclock >= 140500 && dotclock <= 20) {
> + clock->p1 = 1;
> + clock->p2 = 10;
> + clock->n = 6;
> + clock->m1 = 12;
> + clock->m2 = 8;
> + } else {
> + WARN(1, "SDVO TV clock out of range: %i\n", dotclock);
> + }
> +
> + pipe_config->clock_set = true;
> +}
> +
>  static bool intel_sdvo_compute_config(struct intel_encoder *encoder,
> struct intel_crtc_config *pipe_config)
>  {
> @@ -1097,6 +1123,10 @@ static bool intel_sdvo_compute_config(struct 
> intel_encoder *encoder,
>   if (intel_sdvo->color_range)
>   pipe_config->limited_color_range = true;
>  
> + /* Clock computation needs to happen after pixel multiplier. */
> + if (intel_sdvo->is_tv)
> + i9xx_adjust_sdvo_tv_clock(pipe_config);
> +
>   return true;
>  }
>  
> -- 
> 1.7.11.7
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 5/7] drm/i915: stop using is_pch_edp() in is_cpu_edp()

2013-05-10 Thread Imre Deak

On Fri, 2013-05-10 at 10:49 +0200, Daniel Vetter wrote:
> On Wed, May 08, 2013 at 01:14:06PM +0300, Imre Deak wrote:
> > is_pch_edp() will be removed by the next patch, so replace it by a check
> > for the port and device type.
> > 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c |   17 +++--
> >  1 file changed, 11 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 42c11dd..38b9cd2 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -65,6 +65,13 @@ static bool is_pch_edp(struct intel_dp *intel_dp)
> > return intel_dp->is_pch_edp;
> >  }
> >  
> > +static struct drm_device *intel_dp_to_dev(struct intel_dp *intel_dp)
> > +{
> > +   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > +
> > +   return intel_dig_port->base.base.dev;
> > +}
> > +
> >  /**
> >   * is_cpu_edp - is the port on the CPU and attached to an eDP panel?
> >   * @intel_dp: DP struct
> > @@ -73,14 +80,12 @@ static bool is_pch_edp(struct intel_dp *intel_dp)
> >   */
> >  static bool is_cpu_edp(struct intel_dp *intel_dp)
> >  {
> > -   return is_edp(intel_dp) && !is_pch_edp(intel_dp);
> > -}
> > -
> > -static struct drm_device *intel_dp_to_dev(struct intel_dp *intel_dp)
> > -{
> > +   struct drm_device *dev = intel_dp_to_dev(intel_dp);
> > struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> > +   enum port port = intel_dig_port->port;
> >  
> > -   return intel_dig_port->base.base.dev;
> > +   return is_edp(intel_dp) &&
> > +   (port == PORT_A || (port == PORT_C && IS_VALLEYVIEW(dev)));
> 
> Valleyview is a giant mess here, I guess we should split the vlv case
> from the pch_split cpu edp case. Maybe just check for port A in relevant
> cases and factor out vlv cases completely.
> 
> My bet is that this massive confusion is the reason that vlv dp (i.e.
> non-edp) is totally broken atm.

Could we do that as a follow-up to this? That work would have also the
benefit of removing is_cpu_edp() as you hoped earlier, so it could stand
on its own..

--Imre

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

Re: [Intel-gfx] [PATCH v2 5/7] drm/i915: stop using is_pch_edp() in is_cpu_edp()

2013-05-10 Thread Daniel Vetter

On Wed, May 08, 2013 at 01:14:06PM +0300, Imre Deak wrote:
> is_pch_edp() will be removed by the next patch, so replace it by a check
> for the port and device type.
> 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/intel_dp.c |   17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 42c11dd..38b9cd2 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -65,6 +65,13 @@ static bool is_pch_edp(struct intel_dp *intel_dp)
>   return intel_dp->is_pch_edp;
>  }
>  
> +static struct drm_device *intel_dp_to_dev(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> +
> + return intel_dig_port->base.base.dev;
> +}
> +
>  /**
>   * is_cpu_edp - is the port on the CPU and attached to an eDP panel?
>   * @intel_dp: DP struct
> @@ -73,14 +80,12 @@ static bool is_pch_edp(struct intel_dp *intel_dp)
>   */
>  static bool is_cpu_edp(struct intel_dp *intel_dp)
>  {
> - return is_edp(intel_dp) && !is_pch_edp(intel_dp);
> -}
> -
> -static struct drm_device *intel_dp_to_dev(struct intel_dp *intel_dp)
> -{
> + struct drm_device *dev = intel_dp_to_dev(intel_dp);
>   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + enum port port = intel_dig_port->port;
>  
> - return intel_dig_port->base.base.dev;
> + return is_edp(intel_dp) &&
> + (port == PORT_A || (port == PORT_C && IS_VALLEYVIEW(dev)));

Valleyview is a giant mess here, I guess we should split the vlv case
from the pch_split cpu edp case. Maybe just check for port A in relevant
cases and factor out vlv cases completely.

My bet is that this massive confusion is the reason that vlv dp (i.e.
non-edp) is totally broken atm.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: hw state readout&check support for cpu_transcoder

2013-05-10 Thread Daniel Vetter

This allows us to drop a bunch of ugly hacks and finally implement
what

commit cc464b2a17c59adedbdc02cc54341d630354edc3
Author: Paulo Zanoni 
Date:   Fri Jan 25 16:59:16 2013 -0200

drm/i915: set TRANSCODER_EDP even earlier

tried to achieve, but that was reverted again in

commit bba2181c49f1dddf8b592804a1b53cc1a3cf408a
Author: Daniel Vetter 
Date:   Fri Mar 22 10:53:40 2013 +0100

Revert "drm/i915: set TRANSCODER_EDP even earlier"

Now we should always have a consistent cpu_transcoder in the
pipe_config.

v2: Fix up the code as spotted by Paulo:
- read the register for real
- assign the right pipes
- break out if the hw state doesn't make sense

Cc: Paulo Zanoni 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_ddi.c |  4 ++
 drivers/gpu/drm/i915/intel_display.c | 91 ++--
 2 files changed, 38 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 8c4f2aa..baaf670 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1458,9 +1458,13 @@ static bool intel_ddi_compute_config(struct 
intel_encoder *encoder,
 struct intel_crtc_config *pipe_config)
 {
int type = encoder->type;
+   int port = intel_ddi_get_encoder_port(encoder);
 
WARN(type == INTEL_OUTPUT_UNKNOWN, "compute_config() on unknown 
output!\n");
 
+   if (port == PORT_A)
+   pipe_config->cpu_transcoder = TRANSCODER_EDP;
+
if (type == INTEL_OUTPUT_HDMI)
return intel_hdmi_compute_config(encoder, pipe_config);
else
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 219094f..6dcb3a6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3566,12 +3566,6 @@ static void ironlake_crtc_off(struct drm_crtc *crtc)
 
 static void haswell_crtc_off(struct drm_crtc *crtc)
 {
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-
-   /* Stop saying we're using TRANSCODER_EDP because some other CRTC might
-* start using it. */
-   intel_crtc->config.cpu_transcoder = (enum transcoder) intel_crtc->pipe;
-
intel_ddi_put_crtc_pll(crtc);
 }
 
@@ -5038,6 +5032,8 @@ static bool i9xx_get_pipe_config(struct intel_crtc *crtc,
struct drm_i915_private *dev_priv = dev->dev_private;
uint32_t tmp;
 
+   pipe_config->cpu_transcoder = crtc->pipe;
+
tmp = I915_READ(PIPECONF(crtc->pipe));
if (!(tmp & PIPECONF_ENABLE))
return false;
@@ -5789,8 +5785,6 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
WARN(!(HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev)),
 "Unexpected PCH type %d\n", INTEL_PCH_TYPE(dev));
 
-   intel_crtc->config.cpu_transcoder = pipe;
-
ok = ironlake_compute_clocks(crtc, adjusted_mode, &clock,
 &has_reduced_clock, &reduced_clock);
if (!ok) {
@@ -5913,6 +5907,8 @@ static bool ironlake_get_pipe_config(struct intel_crtc 
*crtc,
struct drm_i915_private *dev_priv = dev->dev_private;
uint32_t tmp;
 
+   pipe_config->cpu_transcoder = crtc->pipe;
+
tmp = I915_READ(PIPECONF(crtc->pipe));
if (!(tmp & PIPECONF_ENABLE))
return false;
@@ -5987,11 +5983,6 @@ static int haswell_crtc_mode_set(struct drm_crtc *crtc,
num_connectors++;
}
 
-   if (is_cpu_edp)
-   intel_crtc->config.cpu_transcoder = TRANSCODER_EDP;
-   else
-   intel_crtc->config.cpu_transcoder = pipe;
-
/* We are not sure yet this won't happen. */
WARN(!HAS_PCH_LPT(dev), "Unexpected PCH type %d\n",
 INTEL_PCH_TYPE(dev));
@@ -6047,14 +6038,37 @@ static bool haswell_get_pipe_config(struct intel_crtc 
*crtc,
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   enum transcoder cpu_transcoder = crtc->config.cpu_transcoder;
uint32_t tmp;
 
+   pipe_config->cpu_transcoder = crtc->pipe;
+   tmp = I915_READ(TRANS_DDI_FUNC_CTL(TRANSCODER_EDP));
+   if (tmp & TRANS_DDI_FUNC_ENABLE) {
+   enum pipe trans_edp_pipe;
+   switch (tmp & TRANS_DDI_EDP_INPUT_MASK) {
+   default:
+   WARN(1, "unknown pipe linked to edp transcoder\n");
+   break;
+   case TRANS_DDI_EDP_INPUT_A_ONOFF:
+   case TRANS_DDI_EDP_INPUT_A_ON:
+   trans_edp_pipe = PIPE_A;
+   break;
+   case TRANS_DDI_EDP_INPUT_B_ONOFF:
+   trans_edp_pipe = PIPE_B;
+   break;
+   case TRANS_DDI_EDP_INPUT_C_ONOFF:
+   trans_edp_pipe = PIPE_C;
+   break;
+   }
+
+   if (trans_edp_pipe == crtc->pipe)
+

[Intel-gfx] [QA] Testing report for `drm-intel-testing` (was: Updated -next) on ww19

2013-05-10 Thread Shui, YangweiX

Summary
We finished a new round of kernel testing. Generally, in this circle, 4 new 
bugs are filed, 20 bugs are still opened,4 Duplicated bugs, 7 bugs are closed.



Test Environment

Kernel: f59736c314fc8835b5294cb955f3f16a75cd72d2

Merge: 2b87f3b a9b054e

Author: Daniel Vetter 

Date:   Fri May 3 21:03:17 2013 +0200



Merge remote-tracking branch 'danvet/drm-intel-fixes' into drm-intel-testing



Conflicts:

drivers/gpu/drm/i915/i915_reg.h



Hardware

We covered the platform: Haswell mobile, HSW desktop, HSW ULT, 
IvyBridge(MacBook), SandyBridge, IronLake



Finding



New Bugs:

Bug 64379 - [HSW desktop 
bisected] ddi pll tracking botch-up due to vt-switchless resume

Bug 64270 - 
[SNB/IVB/HSW]I-G-T gem_wait_render_timeout Aborted

Bug 64415 - [ILK] Some 
modes unable to light up on DP display

Bug 63981 - MacBook Pro 
retina 13 inch early 2013 jittery display





Opened Bugs:

Bug 63586 - [HSW desktop] 
Resume from s4 causes call trace and system hang, with cool boot

Bug 63454 - Call Trace when 
resume from S3

Bug 62791 - [ILK 
regression] Change from X-window to text terminal causes Call Trace

Bug 55121 - Limited color 
range on screen that is connected via HDMI [SandyBridge] 
(https://bugzilla.kernel.org/show_bug.cgi?id=55121)

Bug 61041 - 
[Pineview]I-G-T/testdisplay && VGA 1600x1200 65Hz messing the screen

Bug 61158 - [ILK] System 
hang while running testdisplay to mode 1280x800

Bug 60002 - 
[PNV]I-G-T/kms_flip subtest：'blocking-absolute-wf_vblank' fail

Bug 6 - [IVB]kms_flip 
error: inter-vblank ts jitter

Bug 5 - 
[ILK,IVB]kms_flip error: inter-flip ts jitter

Bug 59834 - 
[ILK]I-G-T/kms_flip subtest: 'wf_vblank-vs-modeset' fail

Bug 59836 - 
[PNV]igt/kms_flip/absolute-wf_vblank fail

Bug 59339 - [ILK] 
I-G-T/kms_flip subtest: 'flip-vs-panning' fail

Bug 36997 - [G45 SDVO] TV 
can't display

Bug 42194 - [IVB/SNB] 
coldplug new monitors for fbcon on lastclose()

Bug 51975 - [IVB]can't find 
the HDMI audio device

Bug 57441 - 
[HSW]I-G-T/sysfs_l3_parity fail

Bug 58497 - [IVB HSW] 
I-G-T/testdisplay, there's error in dmesg

Bug 58701 - [SNB 
DP]I-G-T/testdisplay && 1920x1080i showing not full

Bug 54687 - [ilk] pipe off 
timeout

Bug 45729 - [bisected 
regression] Incorrect Mode Timing on DP Display, with 3.3-rc (due to interlaced 
CEA modes) (blocked by bug #61158)


Duplicated bugs:

Bug 62141 - [SNB] hang on 
gnome-shell start with Fedora 19/rawhide + rc6(bug #56416)
Bug 52424 - [Bisected SNB 
Regression] glxgears causes GPU hung(bug #62141)

Bug 63912 - [ILK] Kill X 
cause call trace with DP pipe(bug #54687)

Bug 63453 - [ILK] 
testdisplay cause Call Trace with DP pipe(bug #54687)





Closed Bugs:

Bug 63945 - [HSW] When VGA 
plugged, system booting up with call trace in dmesg

Bug 63941 - [HSW]I-G-T 
gem_storedw_loop_vebox aborted

Bug 63863 - 
igt/prime_self_import/with_two_bos aborted

Bug 59229 - I-G-T/ 
prime_self_import fail

Bug 54111 - [IVB]I-G-T 
prime test/module_reload fail with *ERROR* “Memory manager not clean. Delaying 
takedown”

Bug 58695 - I-G-T/prime_udl 
fail

Bug 62275 - [HSW 3.8.2 
regression] After running testdisplay with only eDP, screen turn to black an

Re: [Intel-gfx] [PATCH 3/4] drm/i915: VLV support is no longer preliminary

2013-05-10 Thread Daniel Vetter

On Wed, May 08, 2013 at 10:45:15AM -0700, Jesse Barnes wrote:
> Works pretty well actually.
> 
> Signed-off-by: Jesse Barnes 

Patches 1-3 merged to dinq, thanks. I'm a bit unhappy that we don't have
mipi yet, otoh mipi needs sink drivers so meh.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] Revert "drm/i915: disable interrupts earlier in the driver unload code"

2013-05-10 Thread Daniel Vetter

On Wed, May 08, 2013 at 10:45:16AM -0700, Jesse Barnes wrote:
> This reverts commit fd0c06420d39958032655a04cfd194d5a7b38f83.

A bit thin on details about what exactly blows up ... can you please dig a
bit more?
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_display.c |   19 +++
>  drivers/gpu/drm/i915/intel_pm.c  |3 ---
>  2 files changed, 7 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index d0c5ecf..e22e752 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9674,23 +9674,12 @@ void intel_modeset_cleanup(struct drm_device *dev)
>   struct drm_crtc *crtc;
>   struct intel_crtc *intel_crtc;
>  
> - /*
> -  * Interrupts and polling as the first thing to avoid creating havoc.
> -  * Too much stuff here (turning of rps, connectors, ...) would
> -  * experience fancy races otherwise.
> -  */
> - drm_irq_uninstall(dev);
> - cancel_work_sync(&dev_priv->hotplug_work);
> - /*
> -  * Due to the hpd irq storm handling the hotplug work can re-arm the
> -  * poll handlers. Hence disable polling after hpd handling is shut down.
> -  */
>   drm_kms_helper_poll_fini(dev);
> -
>   mutex_lock(&dev->struct_mutex);
>  
>   intel_unregister_dsm_handler();
>  
> +
>   list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
>   /* Skip inactive CRTCs */
>   if (!crtc->fb)
> @@ -9708,6 +9697,12 @@ void intel_modeset_cleanup(struct drm_device *dev)
>  
>   mutex_unlock(&dev->struct_mutex);
>  
> + /* Disable the irq before mode object teardown, for the irq might
> +  * enqueue unpin/hotplug work. */
> + drm_irq_uninstall(dev);
> + cancel_work_sync(&dev_priv->hotplug_work);
> + cancel_work_sync(&dev_priv->rps.work);
> +
>   /* flush any delayed tasks or pending work */
>   flush_scheduled_work();
>  
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 081194d..992ff0d 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3729,9 +3729,6 @@ void intel_disable_gt_powersave(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = dev->dev_private;
>  
> - /* Interrupts should be disabled already to avoid re-arming. */
> - WARN_ON(dev->irq_enabled);
> -
>   if (IS_IRONLAKE_M(dev)) {
>   ironlake_disable_drps(dev);
>   ironlake_disable_rc6(dev);
> -- 
> 1.7.10.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: add encoder get_config function v4

2013-05-10 Thread Daniel Vetter

On Thu, May 09, 2013 at 01:28:12AM +0300, Ville Syrjälä wrote:
> On Wed, May 08, 2013 at 02:01:02PM -0700, Jesse Barnes wrote:
> > We can use this for fetching encoder specific pipe_config state, like
> > mode flags, adjusted clock, etc.
> > 
> > Just used for mode flags atm, so we can check the pipe config state at
> > mode set time.
> > 
> > v2: get_config when checking hw state too
> > v3: fix DVO and LVDS mode flags (Ville)
> > get SDVO DTD for flag fetch (Ville)
> > v4: use input timings (Ville)
> > correct command used (Ville)
> > remove gen4 check (Ville)
> > 
> > Signed-off-by: Jesse Barnes 
> 
> I believe all my complaints have been addressed.
> 
> Reviewed-by: Ville Syrjälä 

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC][PATCH 1/1] drm/i915: Rewrite ILK+ watermark handling

2013-05-10 Thread Ville Syrjälä

On Thu, May 09, 2013 at 12:09:30PM -0700, Jesse Barnes wrote:
> On Mon,  6 May 2013 16:45:52 +0300
> ville.syrj...@linux.intel.com wrote:
> 
> > From: Ville Syrjälä 
> > 
> > Rewrite the ILK+ watermark code to allow:
> > - updating the watermarks safely (to avoid underruns)
> > - pre-computing watermarks (will help with atomic modest and pageflip)
> > - enabling LP1+ watermarks for HSW multi-pipe scenarios
> 
> This looks like the right way to go long term.  But Paulo's patches for
> HSW are fairly small and make things better immediately, so we should
> probably get them in first.

Agreed. I'll try to review them properly soon, so far I just glanced at
them.

> This one needs to be split up somehow so we can review it better like
> you mention in the TODO.
> 
> Another thing that I used when doing the WM code way back when was to
> port it to userspace and run through various configs to make sure the
> values were all sane.  Might be nice if we could do that easily
> somehow, maybe with an #ifdef or putting all the wm stuff into a
> separate file.

Actually I had this stuff running in user space first :)

It's not that hard to implement the required stubs to get some drm
file to compile in userland. I did it already for drm_edid.c (stuff
that I've neglected to publish anywhere). I've not tried it for i915
code, and I suppose it may be a bit more work. Splitting the watermark
stuff into a separate file could help a bit though.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Re-enable FBC WM if the watermark is good on gen6+

2013-05-10 Thread Daniel Vetter

On Thu, May 09, 2013 at 05:51:13PM -0300, Paulo Zanoni wrote:
> 2013/4/24  :
> > From: Ville Syrjälä 
> >
> > If the calculated FBC watermark is no good, we simply disable FBC
> > watermarks. But we fail to re-enable them later if the calculated
> > watermark becomes good again. Fix that, but remember to leave FBC
> > watermarks disabled on ILK since that's required by some workarounds.
> >
> > v2: Fix checkpatch complaint
> >
> > Signed-off-by: Ville Syrjälä 
> 
> Looks correct...
> Reviewed-by: Paulo Zanoni 

Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

57 matches

Mail list logo