Re: [Intel-gfx] [PATCH] drm/i915: clear the entire sdvo infoframe buffer

2012-10-20 Thread Ben Hutchings 
On Sat, 2012-10-20 at 18:33 +0200, Daniel Vetter wrote:
> Like in the case of native hdmi, which is fixed already in
> 
> commit adf00b26d18e1b3570451296e03bcb20e4798cdd
> Author: Paulo Zanoni 
> Date:   Tue Sep 25 13:23:34 2012 -0300
> 
> drm/i915: make sure we write all the DIP data bytes
> 
> we need to clear the entire sdvo buffer to avoid upsetting the
> display.
> 
> Since infoframe buffer writing is now a bit more elaborate, extract it
> into it's own function. This will be useful if we ever get around to
> properly update the ELD for sdvo. Also #define proper names for the
> two buffer indexes with fixed usage.
> 
> v2: Cite the right commit above, spotted by Paulo Zanoni.
> 
> v3: I'm too stupid to paste the right commit.
> 
> Reported-and-tested-by: Jürg Billeter 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732
> Cc: sta...@vger.kernel.org
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_sdvo.c  |   64 
> ++--
>  drivers/gpu/drm/i915/intel_sdvo_regs.h |2 +
>  2 files changed, 46 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index d2e8c9f..4bc9c52 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -895,6 +895,47 @@ static void intel_sdvo_dump_hdmi_buf(struct intel_sdvo 
> *intel_sdvo)
>  }
>  #endif
>  
> +static bool intel_sdvo_write_infoframe(struct intel_sdvo *intel_sdvo,
> +unsigned if_index, uint8_t tx_rate,
> +uint8_t *data, unsigned length)
> +{
> + uint8_t set_buf_index[2] = { if_index, 0 };
> + uint8_t hbuf_size, tmp[8];
> + int i;
> +
> + if (!intel_sdvo_set_value(intel_sdvo,
> +   SDVO_CMD_SET_HBUF_INDEX,
> +   set_buf_index, 2))
> + return false;
> +
> + if (!intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_HBUF_INFO,
> +   &hbuf_size, 1))
> + return false;
> +
> + /* Buffer size is 0 base, hooray! */
> + hbuf_size++;

So SDVO_CMD_GET_HBUF_INFO gave us the buffer size in bytes, minus 1?

> + DRM_DEBUG_KMS("writing sdvo hbuf: %i, hbuf_size %i, hbuf_size: %i\n",
> +   if_index, length, hbuf_size);
> +
> + for (i = 0; i < hbuf_size; i += 8) {
> + memset(tmp, 0, 8);
> + memcpy(tmp, data, min_t(unsigned, 8, length));
> +
> + if (!intel_sdvo_set_value(intel_sdvo,
> +   SDVO_CMD_SET_HBUF_DATA,
> +   tmp, 8))
> + return false;
> +
> + data += 8;
> + length -= 8;
> + }
[...]

Based on the commit description, I would assume that hbuf_size may be
greater than length initialy, and you're trying to zero-pad here.  But
if hbuf_size >= length + 8 initially then length can wrap around and
this will continue to read beyond the end of the data array.

I think you could leave data and length unchanged in the loop and then
set up each data chunk like this:

memset(tmp, 0, 8);
if (i < length)
memcpy(tmp, data + i, min_t(unsigned, 8, length - i);

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment destroyed.
 - Carolyn Scheppner


signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/dp: actually nack test request

2012-10-20 Thread Daniel Vetter 
... like the comment says. No idea whether this has any effect, but
I guess it's better to not lie to the display by acking a test request
and never following through with it.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_dp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b9b9d08..8228083 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2125,7 +2125,7 @@ static void
 intel_dp_handle_test_request(struct intel_dp *intel_dp)
 {
/* NAK by default */
-   intel_dp_aux_native_write_1(intel_dp, DP_TEST_RESPONSE, DP_TEST_ACK);
+   intel_dp_aux_native_write_1(intel_dp, DP_TEST_RESPONSE, DP_TEST_NAK);
 }
 
 /*
-- 
1.7.11.4

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

[Intel-gfx] [PATCH 5/5] drm/i915: extract intel_dp_init_panel_power_sequencer

2012-10-20 Thread Daniel Vetter 
That thing has grown way too big already.

Also move around a comment to the right spot.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_dp.c | 223 +---
 1 file changed, 115 insertions(+), 108 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 971c4e4..b9b9d08 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2576,6 +2576,118 @@ intel_dp_add_properties(struct intel_dp *intel_dp, 
struct drm_connector *connect
intel_attach_broadcast_rgb_property(connector);
 }
 
+static void
+intel_dp_init_panel_power_sequencer(struct drm_device *dev,
+   struct intel_dp *intel_dp)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct edp_power_seq cur, vbt, spec, final;
+   u32 pp_on, pp_off, pp_div, pp;
+
+   /* Workaround: Need to write PP_CONTROL with the unlock key as
+* the very first thing. */
+   pp = ironlake_get_pp_control(dev_priv);
+   I915_WRITE(PCH_PP_CONTROL, pp);
+
+   pp_on = I915_READ(PCH_PP_ON_DELAYS);
+   pp_off = I915_READ(PCH_PP_OFF_DELAYS);
+   pp_div = I915_READ(PCH_PP_DIVISOR);
+
+   /* Pull timing values out of registers */
+   cur.t1_t3 = (pp_on & PANEL_POWER_UP_DELAY_MASK) >>
+   PANEL_POWER_UP_DELAY_SHIFT;
+
+   cur.t8 = (pp_on & PANEL_LIGHT_ON_DELAY_MASK) >>
+   PANEL_LIGHT_ON_DELAY_SHIFT;
+
+   cur.t9 = (pp_off & PANEL_LIGHT_OFF_DELAY_MASK) >>
+   PANEL_LIGHT_OFF_DELAY_SHIFT;
+
+   cur.t10 = (pp_off & PANEL_POWER_DOWN_DELAY_MASK) >>
+   PANEL_POWER_DOWN_DELAY_SHIFT;
+
+   cur.t11_t12 = ((pp_div & PANEL_POWER_CYCLE_DELAY_MASK) >>
+  PANEL_POWER_CYCLE_DELAY_SHIFT) * 1000;
+
+   DRM_DEBUG_KMS("cur t1_t3 %d t8 %d t9 %d t10 %d t11_t12 %d\n",
+ cur.t1_t3, cur.t8, cur.t9, cur.t10, cur.t11_t12);
+
+   vbt = dev_priv->edp.pps;
+
+   /* Upper limits from eDP 1.3 spec. Note that we the clunky units
+* of our hw here, which are all in 100usec. */
+   spec.t1_t3 = 210 * 10;
+   spec.t8 = 50 * 10; /* no limit for t8, use t7 instead */
+   spec.t9 = 50 * 10; /* no limit for t9, make it symmetric with t8 */
+   spec.t10 = 500 * 10;
+   /* This one is special and actually in units of 100ms, but zero
+* based in the hw (so we need to add 100 ms). But the sw vbt
+* table multiplies it with 1000 to make it in units of 100usec,
+* too. */
+   spec.t11_t12 = (510 + 100) * 10;
+
+   DRM_DEBUG_KMS("vbt t1_t3 %d t8 %d t9 %d t10 %d t11_t12 %d\n",
+ vbt.t1_t3, vbt.t8, vbt.t9, vbt.t10, vbt.t11_t12);
+
+   /* Use the max of the register setttings and vbt. If both are
+* unset, fall back to the spec limits. */
+#define assign_final(field)final.field = (max(cur.field, vbt.field) == 0 ? 
\
+  spec.field : \
+  max(cur.field, vbt.field))
+   assign_final(t1_t3);
+   assign_final(t8);
+   assign_final(t9);
+   assign_final(t10);
+   assign_final(t11_t12);
+#undef assign_final
+
+#define get_delay(field)   (DIV_ROUND_UP(final.field, 10))
+   intel_dp->panel_power_up_delay = get_delay(t1_t3);
+   intel_dp->backlight_on_delay = get_delay(t8);
+   intel_dp->backlight_off_delay = get_delay(t9);
+   intel_dp->panel_power_down_delay = get_delay(t10);
+   intel_dp->panel_power_cycle_delay = get_delay(t11_t12);
+#undef get_delay
+
+   /* And finally store the new values in the power sequencer. */
+   pp_on = (final.t1_t3 << PANEL_POWER_UP_DELAY_SHIFT) |
+   (final.t8 << PANEL_LIGHT_ON_DELAY_SHIFT);
+   pp_off = (final.t9 << PANEL_LIGHT_OFF_DELAY_SHIFT) |
+(final.t10 << PANEL_POWER_DOWN_DELAY_SHIFT);
+   /* Compute the divisor for the pp clock, simply match the Bspec
+* formula. */
+   pp_div = ((100 * intel_pch_rawclk(dev))/2 - 1)
+   << PP_REFERENCE_DIVIDER_SHIFT;
+   pp_div |= (DIV_ROUND_UP(final.t11_t12, 1000)
+   << PANEL_POWER_CYCLE_DELAY_SHIFT);
+
+   /* Haswell doesn't have any port selection bits for the panel
+* power sequence any more. */
+   if (HAS_PCH_IBX(dev) || HAS_PCH_CPT(dev)) {
+   if (is_cpu_edp(intel_dp))
+   pp_on |= PANEL_POWER_PORT_DP_A;
+   else
+   pp_on |= PANEL_POWER_PORT_DP_D;
+   }
+
+   I915_WRITE(PCH_PP_ON_DELAYS, pp_on);
+   I915_WRITE(PCH_PP_OFF_DELAYS, pp_off);
+   I915_WRITE(PCH_PP_DIVISOR, pp_div);
+
+
+   DRM_DEBUG_KMS("panel power up delay %d, power down delay %d, power 
cycle delay %d\n",
+ intel_dp->panel_power_up_delay, 
intel_dp->panel_power_down_delay,
+ intel_dp->panel_power_cycle_delay);
+
+

[Intel-gfx] [PATCH 4/5] drm/i915/dp: compute the pch dp aux divider from the rawclk

2012-10-20 Thread Daniel Vetter 
Otherwise dp aux won't work on some hsw platforms, since they use a
different rawclk than the 125MHz clock used thus far.

To absolutely not change anything, round up: That way we get the old
63 divider for the default 125MHz clock.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_dp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b35d5bd..971c4e4 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -372,7 +372,7 @@ intel_dp_aux_ch(struct intel_dp *intel_dp,
else
aux_clock_divider = 225; /* eDP input clock at 450Mhz */
} else if (HAS_PCH_SPLIT(dev))
-   aux_clock_divider = 63; /* IRL input clock fixed at 125Mhz */
+   aux_clock_divider = DIV_ROUND_UP(intel_pch_rawclk(dev), 2);
else
aux_clock_divider = intel_hrawclk(dev) / 2;
 
-- 
1.7.11.4

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

[Intel-gfx] [PATCH 3/5] drm/i915/eDP: compute the panel power clock divisor from the pch rawclock

2012-10-20 Thread Daniel Vetter 
We need this when the bios forgets even to set that bit up. Most seem
to do that, even when they don't set up anything else in the panel
power sequencer.

Note that on IBX the rawclk is variable according to Bspec, but
everyone is using 125MHz. The rawclk is fixed to 125MHz on CPT, but
luckily we still have the same register available. On hsw, different
variants have different clocks, hence we need to check the register.

Since other pieces are driven by the rawclock, too, keep the little
helper in a central place.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 10 ++
 drivers/gpu/drm/i915/intel_dp.c  |  8 ++--
 drivers/gpu/drm/i915/intel_drv.h |  2 ++
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9c17a0a7..7fb032f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -80,6 +80,16 @@ struct intel_limit {
 /* FDI */
 #define IRONLAKE_FDI_FREQ  270 /* in kHz for mode->clock */
 
+int
+intel_pch_rawclk(struct drm_device *dev)
+{
+   struct drm_i915_private *dev_priv = dev->dev_private;
+
+   WARN_ON(!HAS_PCH_SPLIT(dev));
+
+   return I915_READ(PCH_RAWCLK_FREQ) & RAWCLK_FREQ_MASK;
+}
+
 static bool
 intel_find_best_PLL(const intel_limit_t *limit, struct drm_crtc *crtc,
int target, int refclk, intel_clock_t *match_clock,
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 49846c0..b35d5bd 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2749,8 +2749,12 @@ intel_dp_init(struct drm_device *dev, int output_reg, 
enum port port)
(final.t8 << PANEL_LIGHT_ON_DELAY_SHIFT);
pp_off = (final.t9 << PANEL_LIGHT_OFF_DELAY_SHIFT) |
 (final.t10 << PANEL_POWER_DOWN_DELAY_SHIFT);
-   pp_div = (pp_div & PP_REFERENCE_DIVIDER_MASK) |
-(DIV_ROUND_UP(final.t11_t12, 1000) << 
PANEL_POWER_CYCLE_DELAY_SHIFT);
+   /* Compute the divisor for the pp clock, simply match the Bspec
+* formula. */
+   pp_div = ((100 * intel_pch_rawclk(dev))/2 - 1)
+   << PP_REFERENCE_DIVIDER_SHIFT;
+   pp_div |= (DIV_ROUND_UP(final.t11_t12, 1000)
+   << PANEL_POWER_CYCLE_DELAY_SHIFT);
 
/* Haswell doesn't have any port selection bits for the panel
 * power sequence any more. */
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index ed75a36..39bddd7 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -396,6 +396,8 @@ struct intel_fbc_work {
int interval;
 };
 
+int intel_pch_rawclk(struct drm_device *dev);
+
 int intel_connector_update_modes(struct drm_connector *connector,
struct edid *edid);
 int intel_ddc_get_modes(struct drm_connector *c, struct i2c_adapter *adapter);
-- 
1.7.11.4

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

[Intel-gfx] [PATCH 2/5] drm/i915: enable/disable backlight for eDP

2012-10-20 Thread Daniel Vetter 
Like we already do for the LVDS panels. This seems to help greatly
in setting up the backlight, since the BIOS might refuse to cooperate.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_dp.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 265cec1..49846c0 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1128,6 +1128,8 @@ static void ironlake_edp_panel_off(struct intel_dp 
*intel_dp)
 
DRM_DEBUG_KMS("Turn eDP power off\n");
 
+   intel_panel_disable_backlight(dev);
+
WARN(!intel_dp->want_panel_vdd, "Need VDD to turn off panel\n");
 
pp = ironlake_get_pp_control(dev_priv);
@@ -1146,6 +1148,7 @@ static void ironlake_edp_backlight_on(struct intel_dp 
*intel_dp)
 {
struct drm_device *dev = intel_dp->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
+   int pipe = to_intel_crtc(intel_dp->base.base.crtc)->pipe;
u32 pp;
 
if (!is_edp(intel_dp))
@@ -1163,6 +1166,8 @@ static void ironlake_edp_backlight_on(struct intel_dp 
*intel_dp)
pp |= EDP_BLC_ENABLE;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
+
+   intel_panel_enable_backlight(dev, pipe);
 }
 
 static void ironlake_edp_backlight_off(struct intel_dp *intel_dp)
-- 
1.7.11.4

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

[Intel-gfx] [PATCH 1/5] drm/i915: make edp panel power sequence setup more robust

2012-10-20 Thread Daniel Vetter 
3 changes:
- If a given value is unset, use the maximal limits from the eDP spec.
- Write back the new values, since otherwise the panel power sequencing
  hw will not dtrt.
- Revert the early bail-out in case the register values are unset.

The last change reverts

commit bfa3384a9a8459443bbd776c142e7dba4b0f
Author: Jesse Barnes 
Date:   Tue Apr 10 11:58:04 2012 -0700

drm/i915: check PPS regs for sanity when using eDP

v2:
- Unlock the PP regs as the very first thing. This is a required w/a
  for cpu eDP on port A, and generally a good idea.
- Fixup the panel power control port selection bits.

v3: Paulo Zanoni noticed that I've fumbled the computation of the spec
limit values. Fix them up. We've also noticed that the t8/t9 values in
the vbt/bios-programmed pp are much larger than any limits. My guess
is that this is to conceal any backlight enable/disable delays. So by
using the much shorter limits from the spec, which only concerns the
sink, we risk that we might display before the backlight is fully on,
or disable the output while the backlight still has afterglow. I've
figured I don't care too much, since this will only happen when both
the pp regs are not programmed, and the vbt tables don't contain
anything useful.

v4: Don't set the port selection bits on hsw/LPT, they don't exist any
more.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_reg.h |  5 +++
 drivers/gpu/drm/i915/intel_dp.c | 71 ++---
 2 files changed, 65 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b428fbb..3ecd8c3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4018,6 +4018,11 @@
 #define  PANEL_LIGHT_ON_DELAY_SHIFT0
 
 #define PCH_PP_OFF_DELAYS  0xc720c
+#define  PANEL_POWER_PORT_SELECT_MASK  (0x3 << 30)
+#define  PANEL_POWER_PORT_LVDS (0 << 30)
+#define  PANEL_POWER_PORT_DP_A (1 << 30)
+#define  PANEL_POWER_PORT_DP_C (2 << 30)
+#define  PANEL_POWER_PORT_DP_D (3 << 30)
 #define  PANEL_POWER_DOWN_DELAY_MASK   (0x1fff)
 #define  PANEL_POWER_DOWN_DELAY_SHIFT  16
 #define  PANEL_LIGHT_OFF_DELAY_MASK(0x1fff)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f2c9ea6..265cec1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2671,20 +2671,18 @@ intel_dp_init(struct drm_device *dev, int output_reg, 
enum port port)
 
/* Cache some DPCD data in the eDP case */
if (is_edp(intel_dp)) {
-   struct edp_power_seqcur, vbt;
-   u32 pp_on, pp_off, pp_div;
+   struct edp_power_seqcur, vbt, spec, final;
+   u32 pp_on, pp_off, pp_div, pp;
+
+   /* Workaround: Need to write PP_CONTROL with the unlock key as
+* the very first thing. */
+   pp = ironlake_get_pp_control(dev_priv);
+   I915_WRITE(PCH_PP_CONTROL, pp);
 
pp_on = I915_READ(PCH_PP_ON_DELAYS);
pp_off = I915_READ(PCH_PP_OFF_DELAYS);
pp_div = I915_READ(PCH_PP_DIVISOR);
 
-   if (!pp_on || !pp_off || !pp_div) {
-   DRM_INFO("bad panel power sequencing delays, disabling 
panel\n");
-   intel_dp_encoder_destroy(&intel_dp->base.base);
-   intel_dp_destroy(&intel_connector->base);
-   return;
-   }
-
/* Pull timing values out of registers */
cur.t1_t3 = (pp_on & PANEL_POWER_UP_DELAY_MASK) >>
PANEL_POWER_UP_DELAY_SHIFT;
@@ -2706,16 +2704,62 @@ intel_dp_init(struct drm_device *dev, int output_reg, 
enum port port)
 
vbt = dev_priv->edp.pps;
 
+   /* Upper limits from eDP 1.3 spec. Note that we the clunky units
+* of our hw here, which are all in 100usec. */
+   spec.t1_t3 = 210 * 10;
+   spec.t8 = 50 * 10; /* no limit for t8, use t7 instead */
+   spec.t9 = 50 * 10; /* no limit for t9, make it symmetric with 
t8 */
+   spec.t10 = 500 * 10;
+   /* This one is special and actually in units of 100ms, but zero
+* based in the hw (so we need to add 100 ms). But the sw vbt
+* table multiplies it with 1000 to make it in units of 100usec,
+* too. */
+   spec.t11_t12 = (510 + 100) * 10;
+
DRM_DEBUG_KMS("vbt t1_t3 %d t8 %d t9 %d t10 %d t11_t12 %d\n",
  vbt.t1_t3, vbt.t8, vbt.t9, vbt.t10, vbt.t11_t12);
 
-#define get_delay(field)   ((max(cur.field, vbt.field) + 9) / 10)
-
+   /* Use the max of the register setttings and vbt. If both are
+* unset, fall back to the spec limits. */
+#define assign_final(field)final.field = (max(cur.field, vbt.field) == 0 ? 
\
+

[Intel-gfx] [PATCH 0/5] eDP improvements

2012-10-20 Thread Daniel Vetter 
Hi all,

This is useful fallout of my futile attempts at getting the eDP panel on my ivb
working without the BIOS' help. I now at least get a backlit black screen though
;-)

Paulo said that this is good enough for his hsw eDP machine already, and it
definitely improves the code a bit and (hopefully) makes it a tad more robust.

Comments, flames and test results highly welcome.

Cheers, Daniel

Daniel Vetter (5):
  drm/i915: make edp panel power sequence setup more robust
  drm/i915: enable/disable backlight for eDP
  drm/i915/eDP: compute the panel power clock divisor from the pch
rawclock
  drm/i915/dp: compute the pch dp aux divider from the rawclk
  drm/i915: extract intel_dp_init_panel_power_sequencer

 drivers/gpu/drm/i915/i915_reg.h  |   5 +
 drivers/gpu/drm/i915/intel_display.c |  10 ++
 drivers/gpu/drm/i915/intel_dp.c  | 177 ---
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 4 files changed, 138 insertions(+), 56 deletions(-)

-- 
1.7.11.4

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

Re: [Intel-gfx] Screen unusable for console until X starts (945GM)

2012-10-20 Thread Daniel Vetter 
On Sat, Oct 20, 2012 at 08:18:31PM +0200, Rolf Eike Beer wrote:
> Daniel Vetter wrote:
> > On Sat, Oct 20, 2012 at 2:20 PM, Rolf Eike Beer  
> wrote:
> > > I can switch the screen brightness during startup, but that only makes the
> > > black screen a dark grey screen, I still see no text.
> > 
> > Could be that we botch something with the enable sequence then. Can
> > you try 3.7-rc1 please (or the latest drm-intel-fixes tree from
> > http://cgit.freedesktop.org/~danvet/drm-intel)? The reworked modeset
> > code is reportedly better at not frying lvds panels ...
> 
> Same behavior as before, dmesg attached.
> 
> $ rpm -qi kernel-vanilla-3.7.rc1.next.20121019-1.1.i686 | tail -n 7
> The standard kernel - without any SUSE patches
> 
> 
> Source Timestamp: 2012-10-19 18:37:40 +0200
> GIT Revision: 375041b9f8fcf7c3f5890dea352c9f61f7695f0a
>   
>  
> GIT Branch: linux-next
>   
>  
> Distribution: Kernel:linux-next 
> 
> Greetings,

I've misread your dmesg, there's actually nothing wrong with the backlight
settings that the i915 driver does. One thing to figure out is which
backlight controller actually controls your backlight. Can you check out
all the exposed controls in /sys/class/backlight and experiment around
which ones have an effect?

I'm pretty sure that it's the backlight and not a modeset gone wrong,
since We don't do another modeset when X starts (it takes over the current
setup).
-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: clear the entire sdvo infoframe buffer

2012-10-20 Thread Daniel Vetter 
Like in the case of native hdmi, which is fixed already in

commit adf00b26d18e1b3570451296e03bcb20e4798cdd
Author: Paulo Zanoni 
Date:   Tue Sep 25 13:23:34 2012 -0300

drm/i915: make sure we write all the DIP data bytes

we need to clear the entire sdvo buffer to avoid upsetting the
display.

Since infoframe buffer writing is now a bit more elaborate, extract it
into it's own function. This will be useful if we ever get around to
properly update the ELD for sdvo. Also #define proper names for the
two buffer indexes with fixed usage.

v2: Cite the right commit above, spotted by Paulo Zanoni.

v3: I'm too stupid to paste the right commit.

Reported-and-tested-by: Jürg Billeter 
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_sdvo.c  |   64 ++--
 drivers/gpu/drm/i915/intel_sdvo_regs.h |2 +
 2 files changed, 46 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
b/drivers/gpu/drm/i915/intel_sdvo.c
index d2e8c9f..4bc9c52 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -895,6 +895,47 @@ static void intel_sdvo_dump_hdmi_buf(struct intel_sdvo 
*intel_sdvo)
 }
 #endif
 
+static bool intel_sdvo_write_infoframe(struct intel_sdvo *intel_sdvo,
+  unsigned if_index, uint8_t tx_rate,
+  uint8_t *data, unsigned length)
+{
+   uint8_t set_buf_index[2] = { if_index, 0 };
+   uint8_t hbuf_size, tmp[8];
+   int i;
+
+   if (!intel_sdvo_set_value(intel_sdvo,
+ SDVO_CMD_SET_HBUF_INDEX,
+ set_buf_index, 2))
+   return false;
+
+   if (!intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_HBUF_INFO,
+ &hbuf_size, 1))
+   return false;
+
+   /* Buffer size is 0 base, hooray! */
+   hbuf_size++;
+
+   DRM_DEBUG_KMS("writing sdvo hbuf: %i, hbuf_size %i, hbuf_size: %i\n",
+ if_index, length, hbuf_size);
+
+   for (i = 0; i < hbuf_size; i += 8) {
+   memset(tmp, 0, 8);
+   memcpy(tmp, data, min_t(unsigned, 8, length));
+
+   if (!intel_sdvo_set_value(intel_sdvo,
+ SDVO_CMD_SET_HBUF_DATA,
+ tmp, 8))
+   return false;
+
+   data += 8;
+   length -= 8;
+   }
+
+   return intel_sdvo_set_value(intel_sdvo,
+   SDVO_CMD_SET_HBUF_TXRATE,
+   &tx_rate, 1);
+}
+
 static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo *intel_sdvo)
 {
struct dip_infoframe avi_if = {
@@ -902,11 +943,7 @@ static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo 
*intel_sdvo)
.ver = DIP_VERSION_AVI,
.len = DIP_LEN_AVI,
};
-   uint8_t tx_rate = SDVO_HBUF_TX_VSYNC;
-   uint8_t set_buf_index[2] = { 1, 0 };
uint8_t sdvo_data[4 + sizeof(avi_if.body.avi)];
-   uint64_t *data = (uint64_t *)sdvo_data;
-   unsigned i;
 
intel_dip_infoframe_csum(&avi_if);
 
@@ -916,22 +953,9 @@ static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo 
*intel_sdvo)
sdvo_data[3] = avi_if.checksum;
memcpy(&sdvo_data[4], &avi_if.body, sizeof(avi_if.body.avi));
 
-   if (!intel_sdvo_set_value(intel_sdvo,
- SDVO_CMD_SET_HBUF_INDEX,
- set_buf_index, 2))
-   return false;
-
-   for (i = 0; i < sizeof(sdvo_data); i += 8) {
-   if (!intel_sdvo_set_value(intel_sdvo,
- SDVO_CMD_SET_HBUF_DATA,
- data, 8))
-   return false;
-   data++;
-   }
-
-   return intel_sdvo_set_value(intel_sdvo,
-   SDVO_CMD_SET_HBUF_TXRATE,
-   &tx_rate, 1);
+   return intel_sdvo_write_infoframe(intel_sdvo, SDVO_HBUF_INDEX_AVI_IF,
+ SDVO_HBUF_TX_VSYNC,
+ sdvo_data, sizeof(sdvo_data));
 }
 
 static bool intel_sdvo_set_tv_format(struct intel_sdvo *intel_sdvo)
diff --git a/drivers/gpu/drm/i915/intel_sdvo_regs.h 
b/drivers/gpu/drm/i915/intel_sdvo_regs.h
index 9d03014..770bdd6 100644
--- a/drivers/gpu/drm/i915/intel_sdvo_regs.h
+++ b/drivers/gpu/drm/i915/intel_sdvo_regs.h
@@ -708,6 +708,8 @@ struct intel_sdvo_enhancements_arg {
 #define SDVO_CMD_SET_AUDIO_STAT0x91
 #define SDVO_CMD_GET_AUDIO_STAT0x92
 #define SDVO_CMD_SET_HBUF_INDEX0x93
+  #define SDVO_HBUF_INDEX_ELD  0
+  #define SDVO_HBUF_INDEX_AVI_IF   1
 #define SDVO_CMD_GET_HBUF_INDEX

Re: [Intel-gfx] [PATCH] drm/i915: clear the entire sdvo infoframe buffer

2012-10-20 Thread Paulo Zanoni 
Hi

2012/10/20 Daniel Vetter :
> Like in the case of native hdmi, which is fixed already in
>
> commit 29de6ce574870a0d3fd157afdbf51c0282e2bf63
> Author: Damien Lespiau 
> Date:   Fri Oct 19 17:55:43 2012 +0100
>
> drm/i915: Don't program DSPCLK_GATE_D twice on IVB and VLV
>
> we need to clear the entire sdvo buffer to avoid upsetting the
> display.

This is not exactly the commit I mentioned... As far as I know,
Damien's commit does not fix any known HDMI bug.

>
> Since infoframe buffer writing is now a bit more elaborate, extract it
> into it's own function. This will be useful if we ever get around to
> properly update the ELD for sdvo. Also #define proper names for the
> two buffer indexes with fixed usage.
>
> v2: Cite the right commit above, spotted by Paulo Zanoni.
>
> Reported-and-tested-by: Jürg Billeter 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732
> Cc: sta...@vger.kernel.org
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_sdvo.c  |   64 
> ++--
>  drivers/gpu/drm/i915/intel_sdvo_regs.h |2 +
>  2 files changed, 46 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index d2e8c9f..4bc9c52 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -895,6 +895,47 @@ static void intel_sdvo_dump_hdmi_buf(struct intel_sdvo 
> *intel_sdvo)
>  }
>  #endif
>
> +static bool intel_sdvo_write_infoframe(struct intel_sdvo *intel_sdvo,
> +  unsigned if_index, uint8_t tx_rate,
> +  uint8_t *data, unsigned length)
> +{
> +   uint8_t set_buf_index[2] = { if_index, 0 };
> +   uint8_t hbuf_size, tmp[8];
> +   int i;
> +
> +   if (!intel_sdvo_set_value(intel_sdvo,
> + SDVO_CMD_SET_HBUF_INDEX,
> + set_buf_index, 2))
> +   return false;
> +
> +   if (!intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_HBUF_INFO,
> + &hbuf_size, 1))
> +   return false;
> +
> +   /* Buffer size is 0 base, hooray! */
> +   hbuf_size++;
> +
> +   DRM_DEBUG_KMS("writing sdvo hbuf: %i, hbuf_size %i, hbuf_size: %i\n",
> + if_index, length, hbuf_size);
> +
> +   for (i = 0; i < hbuf_size; i += 8) {
> +   memset(tmp, 0, 8);
> +   memcpy(tmp, data, min_t(unsigned, 8, length));
> +
> +   if (!intel_sdvo_set_value(intel_sdvo,
> + SDVO_CMD_SET_HBUF_DATA,
> + tmp, 8))
> +   return false;
> +
> +   data += 8;
> +   length -= 8;
> +   }
> +
> +   return intel_sdvo_set_value(intel_sdvo,
> +   SDVO_CMD_SET_HBUF_TXRATE,
> +   &tx_rate, 1);
> +}
> +
>  static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo *intel_sdvo)
>  {
> struct dip_infoframe avi_if = {
> @@ -902,11 +943,7 @@ static bool intel_sdvo_set_avi_infoframe(struct 
> intel_sdvo *intel_sdvo)
> .ver = DIP_VERSION_AVI,
> .len = DIP_LEN_AVI,
> };
> -   uint8_t tx_rate = SDVO_HBUF_TX_VSYNC;
> -   uint8_t set_buf_index[2] = { 1, 0 };
> uint8_t sdvo_data[4 + sizeof(avi_if.body.avi)];
> -   uint64_t *data = (uint64_t *)sdvo_data;
> -   unsigned i;
>
> intel_dip_infoframe_csum(&avi_if);
>
> @@ -916,22 +953,9 @@ static bool intel_sdvo_set_avi_infoframe(struct 
> intel_sdvo *intel_sdvo)
> sdvo_data[3] = avi_if.checksum;
> memcpy(&sdvo_data[4], &avi_if.body, sizeof(avi_if.body.avi));
>
> -   if (!intel_sdvo_set_value(intel_sdvo,
> - SDVO_CMD_SET_HBUF_INDEX,
> - set_buf_index, 2))
> -   return false;
> -
> -   for (i = 0; i < sizeof(sdvo_data); i += 8) {
> -   if (!intel_sdvo_set_value(intel_sdvo,
> - SDVO_CMD_SET_HBUF_DATA,
> - data, 8))
> -   return false;
> -   data++;
> -   }
> -
> -   return intel_sdvo_set_value(intel_sdvo,
> -   SDVO_CMD_SET_HBUF_TXRATE,
> -   &tx_rate, 1);
> +   return intel_sdvo_write_infoframe(intel_sdvo, SDVO_HBUF_INDEX_AVI_IF,
> + SDVO_HBUF_TX_VSYNC,
> + sdvo_data, sizeof(sdvo_data));
>  }
>
>  static bool intel_sdvo_set_tv_format(struct intel_sdvo *intel_sdvo)
> diff --git a/drivers/gpu/drm/i915/intel_sdvo_regs.h 
> b/drivers/gpu/drm/i915/intel_sdvo_regs.h
> index 9d03014..770bdd6 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo_regs.h
> +++ b/drivers/gpu/drm/i915/intel_sdvo

[Intel-gfx] [PATCH] drm/i915: clear the entire sdvo infoframe buffer

2012-10-20 Thread Daniel Vetter 
Like in the case of native hdmi, which is fixed already in

commit 29de6ce574870a0d3fd157afdbf51c0282e2bf63
Author: Damien Lespiau 
Date:   Fri Oct 19 17:55:43 2012 +0100

drm/i915: Don't program DSPCLK_GATE_D twice on IVB and VLV

we need to clear the entire sdvo buffer to avoid upsetting the
display.

Since infoframe buffer writing is now a bit more elaborate, extract it
into it's own function. This will be useful if we ever get around to
properly update the ELD for sdvo. Also #define proper names for the
two buffer indexes with fixed usage.

v2: Cite the right commit above, spotted by Paulo Zanoni.

Reported-and-tested-by: Jürg Billeter 
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_sdvo.c  |   64 ++--
 drivers/gpu/drm/i915/intel_sdvo_regs.h |2 +
 2 files changed, 46 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
b/drivers/gpu/drm/i915/intel_sdvo.c
index d2e8c9f..4bc9c52 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -895,6 +895,47 @@ static void intel_sdvo_dump_hdmi_buf(struct intel_sdvo 
*intel_sdvo)
 }
 #endif
 
+static bool intel_sdvo_write_infoframe(struct intel_sdvo *intel_sdvo,
+  unsigned if_index, uint8_t tx_rate,
+  uint8_t *data, unsigned length)
+{
+   uint8_t set_buf_index[2] = { if_index, 0 };
+   uint8_t hbuf_size, tmp[8];
+   int i;
+
+   if (!intel_sdvo_set_value(intel_sdvo,
+ SDVO_CMD_SET_HBUF_INDEX,
+ set_buf_index, 2))
+   return false;
+
+   if (!intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_HBUF_INFO,
+ &hbuf_size, 1))
+   return false;
+
+   /* Buffer size is 0 base, hooray! */
+   hbuf_size++;
+
+   DRM_DEBUG_KMS("writing sdvo hbuf: %i, hbuf_size %i, hbuf_size: %i\n",
+ if_index, length, hbuf_size);
+
+   for (i = 0; i < hbuf_size; i += 8) {
+   memset(tmp, 0, 8);
+   memcpy(tmp, data, min_t(unsigned, 8, length));
+
+   if (!intel_sdvo_set_value(intel_sdvo,
+ SDVO_CMD_SET_HBUF_DATA,
+ tmp, 8))
+   return false;
+
+   data += 8;
+   length -= 8;
+   }
+
+   return intel_sdvo_set_value(intel_sdvo,
+   SDVO_CMD_SET_HBUF_TXRATE,
+   &tx_rate, 1);
+}
+
 static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo *intel_sdvo)
 {
struct dip_infoframe avi_if = {
@@ -902,11 +943,7 @@ static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo 
*intel_sdvo)
.ver = DIP_VERSION_AVI,
.len = DIP_LEN_AVI,
};
-   uint8_t tx_rate = SDVO_HBUF_TX_VSYNC;
-   uint8_t set_buf_index[2] = { 1, 0 };
uint8_t sdvo_data[4 + sizeof(avi_if.body.avi)];
-   uint64_t *data = (uint64_t *)sdvo_data;
-   unsigned i;
 
intel_dip_infoframe_csum(&avi_if);
 
@@ -916,22 +953,9 @@ static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo 
*intel_sdvo)
sdvo_data[3] = avi_if.checksum;
memcpy(&sdvo_data[4], &avi_if.body, sizeof(avi_if.body.avi));
 
-   if (!intel_sdvo_set_value(intel_sdvo,
- SDVO_CMD_SET_HBUF_INDEX,
- set_buf_index, 2))
-   return false;
-
-   for (i = 0; i < sizeof(sdvo_data); i += 8) {
-   if (!intel_sdvo_set_value(intel_sdvo,
- SDVO_CMD_SET_HBUF_DATA,
- data, 8))
-   return false;
-   data++;
-   }
-
-   return intel_sdvo_set_value(intel_sdvo,
-   SDVO_CMD_SET_HBUF_TXRATE,
-   &tx_rate, 1);
+   return intel_sdvo_write_infoframe(intel_sdvo, SDVO_HBUF_INDEX_AVI_IF,
+ SDVO_HBUF_TX_VSYNC,
+ sdvo_data, sizeof(sdvo_data));
 }
 
 static bool intel_sdvo_set_tv_format(struct intel_sdvo *intel_sdvo)
diff --git a/drivers/gpu/drm/i915/intel_sdvo_regs.h 
b/drivers/gpu/drm/i915/intel_sdvo_regs.h
index 9d03014..770bdd6 100644
--- a/drivers/gpu/drm/i915/intel_sdvo_regs.h
+++ b/drivers/gpu/drm/i915/intel_sdvo_regs.h
@@ -708,6 +708,8 @@ struct intel_sdvo_enhancements_arg {
 #define SDVO_CMD_SET_AUDIO_STAT0x91
 #define SDVO_CMD_GET_AUDIO_STAT0x92
 #define SDVO_CMD_SET_HBUF_INDEX0x93
+  #define SDVO_HBUF_INDEX_ELD  0
+  #define SDVO_HBUF_INDEX_AVI_IF   1
 #define SDVO_CMD_GET_HBUF_INDEX0x94
 #define SDVO_CMD_GET_H

[Intel-gfx] [ANNOUNCE] xf86-video-intel 2.20.12

2012-10-20 Thread Chris Wilson 
More bug reports, more bug fixes! Perhaps the headline feature is
that with secure batches, coming to a 3.8 kernel near you, we may
finally have the ability to perform updates to the scanout synchronized
to the refresh rate on later SandyBridge and IvyBridge chipsets. It comes
at quite a power cost as we need to keep the GPU out of its power saving
modes, but it should allow legacy vsync to function at last. But this
should allow us to address a longstanding issue with tearing on
SandyBridge+.

 * Fix component-alpha rendering on IvyBridge, for example subpixel
   antialiased glyphs.
   https://bugs.freedesktop.org/show_bug.cgi?id=56037

 * Flush before some "pipelined" state changes on gen4. The evidence is
   that the same flushes as required on gen5+ are also required for gen4.
   https://bugs.freedesktop.org/show_bug.cgi?id=55627

 * Prevent a potential crash when forcing a stall on a busy CPU bo
   https://bugs.freedesktop.org/show_bug.cgi?id=56180
-Chris

[Release 2.20.11 contained a typo causing UXA to fail immediately.]

Chris Wilson (14):
  sna: Drop fake tiled CPU mapping
  sna/gen7: Filter BLEND flags for CA glyphs
  sna/dri: Defensively check for GTT mmap failure during fallback
  sna: Enable support for SECURE batch buffers
  sna: Use the secure batches to program scanline waits on gen6+
  sna/overlay: Move bo out of GTT domain after binding to overlay plane
  sna: secure batches accepted upstream, so simply use runtime detection
  sna/gen4: Presume we need a flush upon state change similar to gen5+
  sna: Reorder final checks for using the BO and setting the damage pointer
  sna: Clear the damage along with the BO when forcing the stall for 
inplace BLT
  uxa: Disable bo reuse after binding to a scanout
  2.20.11 release
  uxa: Fixup drm_intel_bo_disable_reuse() typo
  2.20.12 release

git tag: 2.20.12

http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.20.12.tar.bz2
MD5:  6d9565de03c167d8f621315476c20c73  xf86-video-intel-2.20.12.tar.bz2
SHA1: 472e7b1a9bf299089bb7fbfbb3d37d1ee6b20db6  xf86-video-intel-2.20.12.tar.bz2
SHA256: 39e02b7f90a2665efe5483075f93b1c87d24f48070d5de783dd41e20d9eb0c7c  
xf86-video-intel-2.20.12.tar.bz2

http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.20.12.tar.gz
MD5:  fd4e13711d8098d8dcf41b07eeb16572  xf86-video-intel-2.20.12.tar.gz
SHA1: aa4580712775041224ed3ecd191ae5283230371a  xf86-video-intel-2.20.12.tar.gz
SHA256: b4eb1b6d4aecc0d6306ad21530c57d3e6e19e8220efa351e16a8985f2afdb28a  
xf86-video-intel-2.20.12.tar.gz

-- 
Chris Wilson, Intel Open Source Technology Centre


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

Re: [Intel-gfx] [PATCH] drm/i915: clear the entire sdvo infoframe buffer

2012-10-20 Thread Paulo Zanoni 
Hi

2012/10/20 Daniel Vetter :
> Like in the case of native hdmi, which is fixed already in
>
> commit 6441ab5f8ffdf7e99eefe0fb747858e0c12b567e
> Author: Paulo Zanoni 
> Date:   Fri Oct 5 12:05:58 2012 -0300
>
> drm/i915: completely rewrite the Haswell PLL handling code

Did you really mean this commit? Maybe you wanted to say commit
adf00b26d18e1b3570451296e03bcb20e4798cdd:

drm/i915: make sure we write all the DIP data bytes

?

>
> we need to clear the entire sdvo buffer to avoid upsetting the
> display.
>
> Since infoframe buffer writing is now a bit more elaborate, extract it
> into it's own function. This will be useful if we ever get around to
> properly update the ELD for sdvo. Also #define proper names for the
> two buffer indexes with fixed usage.
>
> Reported-and-tested-by: Jürg Billeter 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732
> Cc: sta...@vger.kernel.org
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_sdvo.c  |   64 
> ++--
>  drivers/gpu/drm/i915/intel_sdvo_regs.h |2 +
>  2 files changed, 46 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index d2e8c9f..4bc9c52 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -895,6 +895,47 @@ static void intel_sdvo_dump_hdmi_buf(struct intel_sdvo 
> *intel_sdvo)
>  }
>  #endif
>
> +static bool intel_sdvo_write_infoframe(struct intel_sdvo *intel_sdvo,
> +  unsigned if_index, uint8_t tx_rate,
> +  uint8_t *data, unsigned length)
> +{
> +   uint8_t set_buf_index[2] = { if_index, 0 };
> +   uint8_t hbuf_size, tmp[8];
> +   int i;
> +
> +   if (!intel_sdvo_set_value(intel_sdvo,
> + SDVO_CMD_SET_HBUF_INDEX,
> + set_buf_index, 2))
> +   return false;
> +
> +   if (!intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_HBUF_INFO,
> + &hbuf_size, 1))
> +   return false;
> +
> +   /* Buffer size is 0 base, hooray! */
> +   hbuf_size++;
> +
> +   DRM_DEBUG_KMS("writing sdvo hbuf: %i, hbuf_size %i, hbuf_size: %i\n",
> + if_index, length, hbuf_size);
> +
> +   for (i = 0; i < hbuf_size; i += 8) {
> +   memset(tmp, 0, 8);
> +   memcpy(tmp, data, min_t(unsigned, 8, length));
> +
> +   if (!intel_sdvo_set_value(intel_sdvo,
> + SDVO_CMD_SET_HBUF_DATA,
> + tmp, 8))
> +   return false;
> +
> +   data += 8;
> +   length -= 8;
> +   }
> +
> +   return intel_sdvo_set_value(intel_sdvo,
> +   SDVO_CMD_SET_HBUF_TXRATE,
> +   &tx_rate, 1);
> +}
> +
>  static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo *intel_sdvo)
>  {
> struct dip_infoframe avi_if = {
> @@ -902,11 +943,7 @@ static bool intel_sdvo_set_avi_infoframe(struct 
> intel_sdvo *intel_sdvo)
> .ver = DIP_VERSION_AVI,
> .len = DIP_LEN_AVI,
> };
> -   uint8_t tx_rate = SDVO_HBUF_TX_VSYNC;
> -   uint8_t set_buf_index[2] = { 1, 0 };
> uint8_t sdvo_data[4 + sizeof(avi_if.body.avi)];
> -   uint64_t *data = (uint64_t *)sdvo_data;
> -   unsigned i;
>
> intel_dip_infoframe_csum(&avi_if);
>
> @@ -916,22 +953,9 @@ static bool intel_sdvo_set_avi_infoframe(struct 
> intel_sdvo *intel_sdvo)
> sdvo_data[3] = avi_if.checksum;
> memcpy(&sdvo_data[4], &avi_if.body, sizeof(avi_if.body.avi));
>
> -   if (!intel_sdvo_set_value(intel_sdvo,
> - SDVO_CMD_SET_HBUF_INDEX,
> - set_buf_index, 2))
> -   return false;
> -
> -   for (i = 0; i < sizeof(sdvo_data); i += 8) {
> -   if (!intel_sdvo_set_value(intel_sdvo,
> - SDVO_CMD_SET_HBUF_DATA,
> - data, 8))
> -   return false;
> -   data++;
> -   }
> -
> -   return intel_sdvo_set_value(intel_sdvo,
> -   SDVO_CMD_SET_HBUF_TXRATE,
> -   &tx_rate, 1);
> +   return intel_sdvo_write_infoframe(intel_sdvo, SDVO_HBUF_INDEX_AVI_IF,
> + SDVO_HBUF_TX_VSYNC,
> + sdvo_data, sizeof(sdvo_data));
>  }
>
>  static bool intel_sdvo_set_tv_format(struct intel_sdvo *intel_sdvo)
> diff --git a/drivers/gpu/drm/i915/intel_sdvo_regs.h 
> b/drivers/gpu/drm/i915/intel_sdvo_regs.h
> index 9d03014..770bdd6 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo_regs.h
> +++ b/drivers/gpu/drm/i915/intel_sdvo_regs.h

Re: [Intel-gfx] GPU RC6 breaks PCIe to PCI bridge connected to CPU PCIe slot on SandyBridge systems

2012-10-20 Thread Andy Walls 
On Fri, 2012-10-19 at 18:06 +0100, Simon Farnsworth wrote:
> On Friday 19 October 2012 17:10:17 Simon Farnsworth wrote:
> > Mauro, Linux-Media
> > 
> > I have an issue where an SAA7134-based TV capture card connected via a PCIe 
> > to
> > PCI bridge chip works when the GPU is kept out of RC6 state, but sometimes
> > "skips" updating lines of the capture when the GPU is in RC6. We've 
> > confirmed
> > that a CX23418 based chip doesn't have the problem, so the question is 
> > whether
> > the SAA7134 and the saa7134 driver are at fault, or whether it's the PCIe 
> > bus.

My money's on the saa7134 driver's irq_handler or the driver's locking
scheme to protect data accessed by both irq handler and userspace file
operations (aka videobuf's locking) in the driver.

It could also be a system level problem with another driver's irq
handler being stupid.

> > This manifests as a regression, as I had no problems with kernel 3.3 (which
> > never enabled RC6 on the Intel GPU), but I do have problems with 3.5 and 
> > with
> > current Linus git master. I'm happy to try anything, 

Profile the saa7134 driver in operation:

http://www.spinics.net/lists/linux-media/msg15762.html

That will give you and driver writers a clue as to where any big delays
are hapeening in the saa7134 driver.

Odds are the processor slowing down to a lower power/lower speed state
is exposing inefficiencies in the irq handling of the saa7134 driver.


 
> > I've attached lspci -vvx output (suitable for feeding to lspci -F) for
> > when the corruption is present (lspci.faulty) and when it's not
> > (lspci.working). 

Doing a diff between the two files and checking what devices have
changed registers I noted that only 3 devices' PCI config space
registers changed: 00:01.0 and 00:1c.1 (both PCIe ports/bridges) and
00:1a.0. 

$ lspci -F lspci.working -tv
-[:00]-+-00.0  Intel Corporation 2nd Generation Core Processor Family DRAM 
Controller
   +-01.0-[01-02]00.0-[02]08.0  Philips Semiconductors 
SAA7131/SAA7133/SAA7135 Video Broadcast Decoder
   +-02.0  Intel Corporation 2nd Generation Core Processor Family 
Integrated Graphics Controller
   +-16.0  Intel Corporation 6 Series/C200 Series Chipset Family MEI 
Controller #1
   +-19.0  Intel Corporation 82579V Gigabit Network Connection
   +-1a.0  Intel Corporation 6 Series/C200 Series Chipset Family USB 
Enhanced Host Controller #2
   +-1b.0  Intel Corporation 6 Series/C200 Series Chipset Family High 
Definition Audio Controller
   +-1c.0-[03]--
   +-1c.1-[04]00.0  NEC Corporation uPD720200 USB 3.0 Host 
Controller
   +-1d.0  Intel Corporation 6 Series/C200 Series Chipset Family USB 
Enhanced Host Controller #1
   +-1f.0  Intel Corporation H67 Express Chipset Family LPC Controller
   +-1f.2  Intel Corporation 6 Series/C200 Series Chipset Family 6 port 
SATA AHCI Controller
   \-1f.3  Intel Corporation 6 Series/C200 Series Chipset Family SMBus 
Controller

Obviously the changes to the bridge at 00:01.0 might matter, but I would
need to dig up the data sheet for the "00:01.0 PCI bridge [0604]: Intel
Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI
Express Root Port [8086:0101] (rev 09) (prog-if 00 [Normal decode])" to
see if it really mattered.


> The speculation is that the SAA7134 is somehow more
> > sensitive to the changes in timings that RC6 introduces than the CX23418, 
> > and
> > that someone who understands the saa7134 driver might be able to make it 
> > less
> > sensitive.

I heavily optimized the cx18 driver for the high throughput use case
(mutliple cards running multiple data streams), which meant squeezing
every little bit of useless junk out of the irq handler and adding
highly granular buffer queue locking between the irq handling and the
userspace file operations calls.  Also the CX23418 firmware has a "best
effort" buffer notification handshake and the cx18 driver does some
extra recovery processing to handle when it is late on handling buffer
notifications.  All that optimzation and robustness coding took me a few
months to get right.

I don't see that sort of optimization of the saa7134 driver coming
anytime soon.

Regards,
Andy

> And timings are definitely the problem; I have a userspace provided pm_qos
> request asking for 0 exit latency, but I can see CPU cores entering C6. I'll
> take this problem to an appropriate list.
> 
> There is still be a bug in the SAA7134 driver, as the card clearly wants a
> pm_qos request when streaming to stop the DMA latency becoming too high; this
> doesn't directly affect me, as my userspace always requests minimal DMA
> latency anyway, so consider this message as just closing down the thread for
> now, and as a marker for the future (if people see such corruption, the
> saa7134 driver needs a pm_qos request when streaming that isn't currently
> present).


___
Intel-gfx

Re: [Intel-gfx] Screen unusable for console until X starts (945GM)

2012-10-20 Thread Rolf Eike Beer 
Am Samstag 20 Oktober 2012, 14:18:10 schrieb Daniel Vetter:
> On Sat, Oct 20, 2012 at 2:14 PM, Rolf Eike Beer  
wrote:
> > Am Samstag 20 Oktober 2012, 13:57:37 schrieb Daniel Vetter:
> >> On Sat, Oct 20, 2012 at 8:30 AM, Rolf Eike Beer 
> > 
> > wrote:
> >> > I have an older Laptop with this card in it:
> >> > 
> >> > [0.813208] agpgart-intel :00:00.0: Intel 945GM Chipset
> >> > [0.813284] agpgart-intel :00:00.0: detected gtt size: 262144K
> >> > total, 262144K mappable
> >> > [0.814188] agpgart-intel :00:00.0: detected 8192K stolen memory
> >> > [0.814377] agpgart-intel :00:00.0: AGP aperture is 256M @
> >> > 0xc000
> >> > 
> >> > I observe the following strange behavior: if I start up the system
> >> > (grub2,
> >> > openSUSE 12.1) I see the splash screen appearing shortly. In most cases
> >> > it
> >> > will then disappear and the screen will become just black. This is not
> >> > the
> >> > delay "X is loading but has not put anything on the screen", but it is
> >> > much
> >> > earlier. I'm asked for a crypt password during bootup, which in most
> >> > cases
> >> > now happens totally in the dark, i.e. no console messages at all, no
> >> > prompt. Booting just to runlevel 3 leaves me with a black screen but a
> >> > functional system.
> >> > 
> >> > The strange thing is: sometimes (like 10%) things are just working,
> >> > i.e. I
> >> > have console output. I've tested with 3.1.10 as well as 3.6.2 and both
> >> > have
> >> > the problem. I've run a number of 2.6 kernels before on this system,
> >> > but I
> >> > do not recall when the problem occured or which is one that definitely
> >> > worked.
> >> > 
> >> > Starting X will always get the screen back into working state, i.e. the
> >> > system is normally usable after startup, but it is just annoying to see
> >> > nothing during startup.
> >> > 
> >> > Any hints, patches, whatever?
> >> 
> >> Please attach drm.debug=0xe to your kernel cmdline, boot 3.6 and
> >> attach complete dmesg (up to the point where X makes something appear
> >> on the screen).
> > 
> > Attached. Since I did not mention it earlier: from the moment on X is
> > started consoles also work fine.
> 
> Another case where something sets the backlight brightness to zero
> when we take over, and the X restores it to something sane again. If
> the backlight keys on your machine work, you should be able to
> brighten things up even before X starts.
> 
> Adding Jani since he's recently looked at an eerily similar bug.

I can switch the screen brightness during startup, but that only makes the 
black screen a dark grey screen, I still see no text.

Eike

signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Initialize obj->pages before use by i915_gem_object_do_bit17_swizzle()

2012-10-20 Thread Krzysztof Kolasa 

On 19.10.2012 16:51, Chris Wilson wrote:

If we leave obj->pages set to NULL before attempting to deswizzle them,
then an OOPS is well deserved.

Fixes regression introduced in commit 9da3da660d8c19a54f6e93361d147509be3fff84
Author: Chris Wilson 
Date:   Fri Jun 1 15:20:22 2012 +0100

 drm/i915: Replace the array of pages with a scatterlist

Reported-by: Krzysztof Kolasa
Signed-off-by: Chris Wilson 
Cc: sta...@vger.kernel.org
---
  drivers/gpu/drm/i915/i915_gem.c |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ad2ed75..6ab7c68 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1953,10 +1953,11 @@ i915_gem_object_get_pages_gtt(struct 
drm_i915_gem_object *obj)
sg_set_page(sg, page, PAGE_SIZE, 0);
}
  
+	obj->pages = st;

+
if (i915_gem_object_needs_bit17_swizzle(obj))
i915_gem_object_do_bit_17_swizzle(obj);
  
-	obj->pages = st;

return 0;
  
  err_pages:

Patch solves the problem.

Thanks.

Krzysztof



smime.p7s
Description: S/MIME Cryptographic Signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Screen unusable for console until X starts (945GM)

2012-10-20 Thread Rolf Eike Beer 
I have an older Laptop with this card in it:

[0.813208] agpgart-intel :00:00.0: Intel 945GM Chipset
[0.813284] agpgart-intel :00:00.0: detected gtt size: 262144K total, 
262144K mappable
[0.814188] agpgart-intel :00:00.0: detected 8192K stolen memory
[0.814377] agpgart-intel :00:00.0: AGP aperture is 256M @ 0xc000

I observe the following strange behavior: if I start up the system (grub2, 
openSUSE 12.1) I see the splash screen appearing shortly. In most cases it 
will then disappear and the screen will become just black. This is not the 
delay "X is loading but has not put anything on the screen", but it is much 
earlier. I'm asked for a crypt password during bootup, which in most cases now 
happens totally in the dark, i.e. no console messages at all, no prompt. 
Booting just to runlevel 3 leaves me with a black screen but a functional 
system.

The strange thing is: sometimes (like 10%) things are just working, i.e. I 
have console output. I've tested with 3.1.10 as well as 3.6.2 and both have 
the problem. I've run a number of 2.6 kernels before on this system, but I do 
not recall when the problem occured or which is one that definitely worked.

Starting X will always get the screen back into working state, i.e. the system 
is normally usable after startup, but it is just annoying to see nothing 
during startup.

Any hints, patches, whatever?

Greetings,

Eike

P.S.: please keep me on CC, I'm not on the list.

signature.asc
Description: This is a digitally signed message part.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: clear the entire sdvo infoframe buffer

2012-10-20 Thread Daniel Vetter 
Like in the case of native hdmi, which is fixed already in

commit 6441ab5f8ffdf7e99eefe0fb747858e0c12b567e
Author: Paulo Zanoni 
Date:   Fri Oct 5 12:05:58 2012 -0300

drm/i915: completely rewrite the Haswell PLL handling code

we need to clear the entire sdvo buffer to avoid upsetting the
display.

Since infoframe buffer writing is now a bit more elaborate, extract it
into it's own function. This will be useful if we ever get around to
properly update the ELD for sdvo. Also #define proper names for the
two buffer indexes with fixed usage.

Reported-and-tested-by: Jürg Billeter 
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=25732
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_sdvo.c  |   64 ++--
 drivers/gpu/drm/i915/intel_sdvo_regs.h |2 +
 2 files changed, 46 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
b/drivers/gpu/drm/i915/intel_sdvo.c
index d2e8c9f..4bc9c52 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -895,6 +895,47 @@ static void intel_sdvo_dump_hdmi_buf(struct intel_sdvo 
*intel_sdvo)
 }
 #endif
 
+static bool intel_sdvo_write_infoframe(struct intel_sdvo *intel_sdvo,
+  unsigned if_index, uint8_t tx_rate,
+  uint8_t *data, unsigned length)
+{
+   uint8_t set_buf_index[2] = { if_index, 0 };
+   uint8_t hbuf_size, tmp[8];
+   int i;
+
+   if (!intel_sdvo_set_value(intel_sdvo,
+ SDVO_CMD_SET_HBUF_INDEX,
+ set_buf_index, 2))
+   return false;
+
+   if (!intel_sdvo_get_value(intel_sdvo, SDVO_CMD_GET_HBUF_INFO,
+ &hbuf_size, 1))
+   return false;
+
+   /* Buffer size is 0 base, hooray! */
+   hbuf_size++;
+
+   DRM_DEBUG_KMS("writing sdvo hbuf: %i, hbuf_size %i, hbuf_size: %i\n",
+ if_index, length, hbuf_size);
+
+   for (i = 0; i < hbuf_size; i += 8) {
+   memset(tmp, 0, 8);
+   memcpy(tmp, data, min_t(unsigned, 8, length));
+
+   if (!intel_sdvo_set_value(intel_sdvo,
+ SDVO_CMD_SET_HBUF_DATA,
+ tmp, 8))
+   return false;
+
+   data += 8;
+   length -= 8;
+   }
+
+   return intel_sdvo_set_value(intel_sdvo,
+   SDVO_CMD_SET_HBUF_TXRATE,
+   &tx_rate, 1);
+}
+
 static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo *intel_sdvo)
 {
struct dip_infoframe avi_if = {
@@ -902,11 +943,7 @@ static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo 
*intel_sdvo)
.ver = DIP_VERSION_AVI,
.len = DIP_LEN_AVI,
};
-   uint8_t tx_rate = SDVO_HBUF_TX_VSYNC;
-   uint8_t set_buf_index[2] = { 1, 0 };
uint8_t sdvo_data[4 + sizeof(avi_if.body.avi)];
-   uint64_t *data = (uint64_t *)sdvo_data;
-   unsigned i;
 
intel_dip_infoframe_csum(&avi_if);
 
@@ -916,22 +953,9 @@ static bool intel_sdvo_set_avi_infoframe(struct intel_sdvo 
*intel_sdvo)
sdvo_data[3] = avi_if.checksum;
memcpy(&sdvo_data[4], &avi_if.body, sizeof(avi_if.body.avi));
 
-   if (!intel_sdvo_set_value(intel_sdvo,
- SDVO_CMD_SET_HBUF_INDEX,
- set_buf_index, 2))
-   return false;
-
-   for (i = 0; i < sizeof(sdvo_data); i += 8) {
-   if (!intel_sdvo_set_value(intel_sdvo,
- SDVO_CMD_SET_HBUF_DATA,
- data, 8))
-   return false;
-   data++;
-   }
-
-   return intel_sdvo_set_value(intel_sdvo,
-   SDVO_CMD_SET_HBUF_TXRATE,
-   &tx_rate, 1);
+   return intel_sdvo_write_infoframe(intel_sdvo, SDVO_HBUF_INDEX_AVI_IF,
+ SDVO_HBUF_TX_VSYNC,
+ sdvo_data, sizeof(sdvo_data));
 }
 
 static bool intel_sdvo_set_tv_format(struct intel_sdvo *intel_sdvo)
diff --git a/drivers/gpu/drm/i915/intel_sdvo_regs.h 
b/drivers/gpu/drm/i915/intel_sdvo_regs.h
index 9d03014..770bdd6 100644
--- a/drivers/gpu/drm/i915/intel_sdvo_regs.h
+++ b/drivers/gpu/drm/i915/intel_sdvo_regs.h
@@ -708,6 +708,8 @@ struct intel_sdvo_enhancements_arg {
 #define SDVO_CMD_SET_AUDIO_STAT0x91
 #define SDVO_CMD_GET_AUDIO_STAT0x92
 #define SDVO_CMD_SET_HBUF_INDEX0x93
+  #define SDVO_HBUF_INDEX_ELD  0
+  #define SDVO_HBUF_INDEX_AVI_IF   1
 #define SDVO_CMD_GET_HBUF_INDEX0x94
 #define SDVO_CMD_GET_HBUF_INFO 0x95
 #define SDVO_CMD_SET_HBUF_AV_SPLIT

Re: [Intel-gfx] Screen unusable for console until X starts (945GM)

2012-10-20 Thread Daniel Vetter 
On Sat, Oct 20, 2012 at 2:20 PM, Rolf Eike Beer  wrote:
> I can switch the screen brightness during startup, but that only makes the
> black screen a dark grey screen, I still see no text.

Could be that we botch something with the enable sequence then. Can
you try 3.7-rc1 please (or the latest drm-intel-fixes tree from
http://cgit.freedesktop.org/~danvet/drm-intel)? The reworked modeset
code is reportedly better at not frying lvds panels ...

Yours, 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] Screen unusable for console until X starts (945GM)

2012-10-20 Thread Daniel Vetter 
On Sat, Oct 20, 2012 at 2:14 PM, Rolf Eike Beer  wrote:
> Am Samstag 20 Oktober 2012, 13:57:37 schrieb Daniel Vetter:
>> On Sat, Oct 20, 2012 at 8:30 AM, Rolf Eike Beer 
> wrote:
>> > I have an older Laptop with this card in it:
>> >
>> > [0.813208] agpgart-intel :00:00.0: Intel 945GM Chipset
>> > [0.813284] agpgart-intel :00:00.0: detected gtt size: 262144K
>> > total, 262144K mappable
>> > [0.814188] agpgart-intel :00:00.0: detected 8192K stolen memory
>> > [0.814377] agpgart-intel :00:00.0: AGP aperture is 256M @
>> > 0xc000
>> >
>> > I observe the following strange behavior: if I start up the system (grub2,
>> > openSUSE 12.1) I see the splash screen appearing shortly. In most cases it
>> > will then disappear and the screen will become just black. This is not the
>> > delay "X is loading but has not put anything on the screen", but it is
>> > much
>> > earlier. I'm asked for a crypt password during bootup, which in most cases
>> > now happens totally in the dark, i.e. no console messages at all, no
>> > prompt. Booting just to runlevel 3 leaves me with a black screen but a
>> > functional system.
>> >
>> > The strange thing is: sometimes (like 10%) things are just working, i.e. I
>> > have console output. I've tested with 3.1.10 as well as 3.6.2 and both
>> > have
>> > the problem. I've run a number of 2.6 kernels before on this system, but I
>> > do not recall when the problem occured or which is one that definitely
>> > worked.
>> >
>> > Starting X will always get the screen back into working state, i.e. the
>> > system is normally usable after startup, but it is just annoying to see
>> > nothing during startup.
>> >
>> > Any hints, patches, whatever?
>>
>> Please attach drm.debug=0xe to your kernel cmdline, boot 3.6 and
>> attach complete dmesg (up to the point where X makes something appear
>> on the screen).
>
> Attached. Since I did not mention it earlier: from the moment on X is started
> consoles also work fine.

Another case where something sets the backlight brightness to zero
when we take over, and the X restores it to something sane again. If
the backlight keys on your machine work, you should be able to
brighten things up even before X starts.

Adding Jani since he's recently looked at an eerily similar bug.

Cheers, 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 0/8] Haswell eDP enablement patches 1-8 v2

2012-10-20 Thread Daniel Vetter 
On Sat, Oct 20, 2012 at 12:00 AM, Daniel Vetter  wrote:
> On Fri, Oct 19, 2012 at 11:19 PM, Paulo Zanoni  wrote:
>>   - Daniel suggested to not convert some of the code that touches FDI and
>> the PCH transcoder but I did not remove these chunks since we're
>> currently running this code on Haswell even when not using VGA, so 
>> if we
>> don't convert the code to cpu_transcoder we might start poking the 
>> wrong
>> pipes and messing a lot of things. I really don't think we should 
>> delay
>> Haswell enablement even more based on cleanups we did not even write
>> yet.  I've been maintaining these Haswell patches for a long time, 
>> I'd
>> love to get rid of them. When we do the VGA cleanups we will be able 
>> to
>> fix what we need to fix.
>
> Hm, where are we calling into fdi/pch code if the connector is not
> VGA? I've thought we've taken care of all these things by now ...

Ok, on irc Paulo clarified that in ironlake_crtc_disable we still call
some of the fdi and (pch) transcoder functions. Now for most cases I'd
simply call this a bug - we need to teach the code some smarts to
check whether any of the encoders are on the pch and only disable
things if that's the case.

But even without that consideration I don't think it makes sense to to
the s/pipe/cpu_transcoder transformation on these functions:
- At most we should talk about a separate pch transcoder  (to make the
vga encoder work on cpu_pipe != PIPE_A). The current code works
somewhat since there's only one pch transcoder on LPT, and by fixing
VGA to pipe A we make sure we don't try to use a non-existing pch
transcoder.
- We don't have an eDP transcoder on any pch device. So mapping to the
transcoder enum makes even less sense.

My proposal:
- ditch the s/pipe/cpu_transcoder/ that touch the fdi/pch transcoder
stuff from this patch series.
- when fixing up hsw vga support, first rename the current transcoder
functions to pch_transcoder, to make clear what they're dealing with
- add a intel_crtc->pch_transcoder, which for all platforms but hsw
would be the same as intel_crtc->pipe, switch all pch code over to use
that
- add an encoder->is_pch_encoder field, and wrap up all the fdi/pch
stuff with checks for this to avoid calling code that we should call.
We probably should keep around all the asserts that check whether
things are properly disabled.
- fix the pch_transcoder field on hsw to PIPE_A, since that's what
we'll ever use.

Depending upon what the code looks like, we could also create haswell
specific crtc_enable/disable functions and maybe even move all the
fdi/pch_transcoder stuff into the a hsw specific crt encoder (since
it's the only odd thing out).

Comments?

Cheers, 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] Screen unusable for console until X starts (945GM)

2012-10-20 Thread Daniel Vetter 
On Sat, Oct 20, 2012 at 8:30 AM, Rolf Eike Beer  wrote:
> I have an older Laptop with this card in it:
>
> [0.813208] agpgart-intel :00:00.0: Intel 945GM Chipset
> [0.813284] agpgart-intel :00:00.0: detected gtt size: 262144K total,
> 262144K mappable
> [0.814188] agpgart-intel :00:00.0: detected 8192K stolen memory
> [0.814377] agpgart-intel :00:00.0: AGP aperture is 256M @ 0xc000
>
> I observe the following strange behavior: if I start up the system (grub2,
> openSUSE 12.1) I see the splash screen appearing shortly. In most cases it
> will then disappear and the screen will become just black. This is not the
> delay "X is loading but has not put anything on the screen", but it is much
> earlier. I'm asked for a crypt password during bootup, which in most cases now
> happens totally in the dark, i.e. no console messages at all, no prompt.
> Booting just to runlevel 3 leaves me with a black screen but a functional
> system.
>
> The strange thing is: sometimes (like 10%) things are just working, i.e. I
> have console output. I've tested with 3.1.10 as well as 3.6.2 and both have
> the problem. I've run a number of 2.6 kernels before on this system, but I do
> not recall when the problem occured or which is one that definitely worked.
>
> Starting X will always get the screen back into working state, i.e. the system
> is normally usable after startup, but it is just annoying to see nothing
> during startup.
>
> Any hints, patches, whatever?

Please attach drm.debug=0xe to your kernel cmdline, boot 3.6 and
attach complete dmesg (up to the point where X makes something appear
on the screen).
-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