Re: [Intel-gfx] OpenGL sampler objects on sandybridge with Ubuntu Linux 12.04

2012-05-21 Thread Mark Newiger 
Hi Daniel,

I already filed it:
https://bugs.freedesktop.org/show_bug.cgi?id=49996

Thanks and best regards
Mark

-Ursprüngliche Nachricht-
Von: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] Im Auftrag von Daniel Vetter
Gesendet: Samstag, 19. Mai 2012 22:43
An: Mark Newiger
Cc: intel-gfx@lists.freedesktop.org
Betreff: Re: [Intel-gfx] OpenGL sampler objects on sandybridge with Ubuntu 
Linux 12.04

Hi,

Please file a bug report with the below details on bugs.freedesktop.org against 
"Mesa" -> "DRI/Intel(i965)".

Thanks, Daniel

On Wed, May 16, 2012 at 09:58:45AM +, Mark Newiger wrote:
> Hello,
> 
> We are using an MiniPC with the following configuration:
> 
> -  Intel SandyBridge PC Mainboard DH61AG and integrated Intel HD 
> Graphics 3000
> 
> -  Dual OS: Windows 7 32bit and Ubuntu 12.04 32bit
> 
> When using OpenGL sampler objects for configuring textures, on Ubuntu I have 
> to create a mipmap chain by calling "glGenerateMipmap()". Otherwise the 
> texture sampling will not work (e.g. returns black).
> Take the following example:
> // Init
> int texture;
> glGenTextures(1, &texture);
> glBindTexture(GL_TEXTURE_2D, texture); glTexImage2D(...);
> 
> int sampler;
> glGenSamplers(1, &sampler);
> glSamplerParameteri(sampler, GL_TEXTURE_MIN_FILTER, GL_LINEAR); 
> glSamplerParameteri(sampler, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
> 
> // Render loop
> glActiveTexture(GL_TEXTURE0);
> glBindTexture(GL_TEXTURE_2D, texture); glBindSampler(0, sampler); ...
> 
> This works perfectly on Windows but not on Ubuntu. For Ubuntu Linux I have to 
> add the following:
> //Init
> ...
> glTexImage2D(...);
> glGenerateMipmap(GL_TEXTURE_2D);
> 
> Without the mipmap the texture sampling does not work, although I am not 
> using any mipmaps.
> When using the traditional texture filter configuration, this problem does 
> not occur and the code behaves the same on Windows and Linux:
> // Render loop
> glActiveTexture(GL_TEXTURE0);
> glBindTexture(GL_TEXTURE_2D, texture); glTexParameteri(GL_TEXTURE_2D, 
> GL_TEXTURE_MIN_FILTER, GL_LINEAR); glTexParameteri(GL_TEXTURE_2D, 
> GL_TEXTURE_MAG_FILTER, GL_LINEAR);
> 
> Seems to be a driver bug for me. Or did I oversee something ?
> 
> Thanks and best regards
> Mark
> 
> 
> Best regards,
> Mark Newiger | Senior Software Engineer SeeFront GmbH Esplanade 41 | 
> D-20354 Hamburg, Germany
> Office: +49 40 416 22 64-83
> mark.newi...@seefront.com | 
> www.seefront.com
> 
> Managing Director: Christoph Grossmann Registered seat of the company: 
> Hamburg Register Court: Amtsgericht Hamburg HRB 98205 VAT-ID-No. 
> DE248406189
> 

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


--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4] drm/i915: clarify semaphore-ring interaction

2012-05-21 Thread Chris Wilson 
On Sun, 20 May 2012 08:45:38 -0700, Ben Widawsky  wrote:
> After Daniel split out this code, I think this makes more sense, and
> looks nicer. Also added some comments to help the situation.
> 
> v2: Make signal_mbox be all rings for symmetric-ness.
> v3: submitted the wrong version of the patch before.
>   v2 had an issue with odd number of rings. The fix is to always emit an
>   even number of instructions to the ring with mbox updates.
> v4: I suck. The code should send out mbox updates for NUM_RINGS-1 *
>   number of commands. Instead of NUM_RINGS * number of commands-1.
> -ret = intel_ring_begin(ring, round_up((I915_NUM_RINGS) * 3, 2) + 4);
> +ret = intel_ring_begin(ring, round_up((I915_NUM_RINGS-1) * 4, 2) + 4);

I'm honestly less enthralled about v4. I'd rather see that as a separate
preparatory patch so that it is put into context.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: consolidate interrupt naming scheme

2012-05-21 Thread Chris Wilson 
On Fri, 18 May 2012 09:02:09 -0700, Ben Widawsky  wrote:
> here are some opportunities to do things a bit better with the naming of
> things now that our hindsight is better.

The major problem with this is that it breaks the expectations of the
INTEL_ namespace, masquerading per-gen values as fixed constants for all
chipsets.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: IBX has a fixed pch pll to pch pipe mapping

2012-05-21 Thread Jesse Barnes 
On Sun, 20 May 2012 20:51:19 +0200
Daniel Vetter  wrote:

> On Sun, May 20, 2012 at 08:00:25PM +0200, Daniel Vetter wrote:
> > This should fix breakage introduced in
> > 
> > commit ee7b9f93fd96a72e5d09e2b44024c11880873c6b
> > Author: Jesse Barnes 
> > Date:   Fri Apr 20 17:11:53 2012 +0100
> > 
> > drm/i915: manage PCH PLLs separately from pipes
> > 
> > v2: Add a DRM_DEBUG_KMS message to explain why a given pll was
> > selected, suggested by Chris Wilson.
> > 
> > v3: Actually run git add.
> > 
> > Cc: Jesse Barnes 
> > Cc: Chris Wilson 
> > Reviewed-by: Chris Wilson 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49712
> > Signed-Off-by: Daniel Vetter 
> 
> Ok, I've merged this one to dinq. I could reproduce a failure on my ilk
> by forcing the crtc which looked very much like what QA is hitting, and
> this patch does indeed fix that.

Great, thanks Daniel.

-- 
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: [GEN7] Use HW scheduler for fixed function shaders

2012-05-21 Thread Jesse Barnes 
On Sun, 20 May 2012 21:24:15 +0200
Daniel Vetter  wrote:

> On Wed, Apr 18, 2012 at 5:33 PM, Daniel Vetter  wrote:
> > Jesse, can you also please check whether we need the same thing on vlv?
> > atm the the clock gating functions are almost identical safe for this wrt
> > touching registers in the gt core.
> 
> Prod.
> 
> Now that you have a vlv, no more excuses ;-)

I've got one more: I'm waiting on a dediprog so I can upgrade the
BIOS.  The machine is stable unless I try to use gfx at the moment
because a BIOS change prevented the GPU from coming out of reset.

I was able to do some work on the VGA console side of things (adding a
couple of needed workarounds); hopefully I'll be able to refresh this
patchset this week or next and do the sprite stuff too.

Bernard's team may have one for testing by now too though; so they can
provide an answer on this thread.

-- 
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: enable vdd when switching off the eDP panel

2012-05-21 Thread Daniel Vetter 
Hi Keith&Chris,

This is the patch for you to try on the macbook airs 

Thanks, Daniel

On Sun, May 20, 2012 at 05:14:50PM +0200, Daniel Vetter wrote:
> We have one bug report from a validation team that we get the eDP
> panel sequencing still somewhat wrong: We need to enable VDD while
> switching off the panel and backlight. Unfortunately that reporter
> seems to have fallen off the earth :(
> 
> For another reporter this actually fixes a black panel issue because
> without this the backlight/panel gets confused and doesn't light up
> again.
> 
> v2: I've forgotten to remove the vdd_off call in panel_off which is
> now bogus. This essentially reverts
> 
> commit 17038de5f16569a25343cf68668f3b657eafb00e
> Author: Chris Wilson 
> Date:   Mon Apr 16 22:43:42 2012 +0100
> 
> drm/i915/dp: Flush any outstanding work to turn the VDD off
> 
> v3: the current panel_off code forces off the vdd power, too. Which is
> bogus and resulted in some funny warnings later on when we've tried to
> do aux channel communications with just the vdd forced on. Fix this,
> too.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46312
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43163
> Tested-by: Vincent Frentzel 
> Cc: sta...@kernel.org
> Signed-Off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_dp.c |   18 --
>  1 file changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index a1a5ce7..3bbd754 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1154,11 +1154,10 @@ static void ironlake_edp_panel_off(struct intel_dp 
> *intel_dp)
>  
>   DRM_DEBUG_KMS("Turn eDP power off\n");
>  
> - WARN(intel_dp->want_panel_vdd, "Cannot turn power off while VDD is 
> on\n");
> - ironlake_panel_vdd_off_sync(intel_dp); /* finish any pending work */
> + WARN(!intel_dp->want_panel_vdd, "Need VDD to turn off panel\n");
>  
>   pp = ironlake_get_pp_control(dev_priv);
> - pp &= ~(POWER_TARGET_ON | EDP_FORCE_VDD | PANEL_POWER_RESET | 
> EDP_BLC_ENABLE);
> + pp &= ~(POWER_TARGET_ON | PANEL_POWER_RESET | EDP_BLC_ENABLE);
>   I915_WRITE(PCH_PP_CONTROL, pp);
>   POSTING_READ(PCH_PP_CONTROL);
>  
> @@ -1266,18 +1265,16 @@ static void intel_dp_prepare(struct drm_encoder 
> *encoder)
>  {
>   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
>  
> +
> + /* Make sure the panel is off before trying to change the mode. But also
> +  * ensure that we have vdd while we switch off the panel. */
> + ironlake_edp_panel_vdd_on(intel_dp);
>   ironlake_edp_backlight_off(intel_dp);
>   ironlake_edp_panel_off(intel_dp);
>  
> - /* Wake up the sink first */
> - ironlake_edp_panel_vdd_on(intel_dp);
>   intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
>   intel_dp_link_down(intel_dp);
>   ironlake_edp_panel_vdd_off(intel_dp, false);
> -
> - /* Make sure the panel is off before trying to
> -  * change the mode
> -  */
>  }
>  
>  static void intel_dp_commit(struct drm_encoder *encoder)
> @@ -1309,10 +1306,11 @@ intel_dp_dpms(struct drm_encoder *encoder, int mode)
>   uint32_t dp_reg = I915_READ(intel_dp->output_reg);
>  
>   if (mode != DRM_MODE_DPMS_ON) {
> + /* Switching the panel off requires vdd. */
> + ironlake_edp_panel_vdd_on(intel_dp);
>   ironlake_edp_backlight_off(intel_dp);
>   ironlake_edp_panel_off(intel_dp);
>  
> - ironlake_edp_panel_vdd_on(intel_dp);
>   intel_dp_sink_dpms(intel_dp, mode);
>   intel_dp_link_down(intel_dp);
>   ironlake_edp_panel_vdd_off(intel_dp, false);
> -- 
> 1.7.10
> 

-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/5] drm/i915/dp: For consistency use the DP hotplug synonyms

2012-05-21 Thread Daniel Vetter 
On Fri, May 11, 2012 at 06:01:35PM +0100, Chris Wilson wrote:
> Signed-off-by: Chris Wilson 

Ok, I've slurped in the entire series. Let's see what happens 
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_dp.c |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 5341a57..aa9262c 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2480,19 +2480,19 @@ intel_dp_init(struct drm_device *dev, int output_reg)
>   case DP_B:
>   case PCH_DP_B:
>   dev_priv->hotplug_supported_mask |=
> - HDMIB_HOTPLUG_INT_STATUS;
> + DPB_HOTPLUG_INT_STATUS;
>   name = "DPDDC-B";
>   break;
>   case DP_C:
>   case PCH_DP_C:
>   dev_priv->hotplug_supported_mask |=
> - HDMIC_HOTPLUG_INT_STATUS;
> + DPC_HOTPLUG_INT_STATUS;
>   name = "DPDDC-C";
>   break;
>   case DP_D:
>   case PCH_DP_D:
>   dev_priv->hotplug_supported_mask |=
> - HDMID_HOTPLUG_INT_STATUS;
> + DPD_HOTPLUG_INT_STATUS;
>   name = "DPDDC-D";
>   break;
>   }
> -- 
> 1.7.10
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: be more careful when returning -ENXIO in gmbus transfer

2012-05-21 Thread Daniel Vetter 
... flaky ddc hardware can cause a spurious NAK, resulting in the i2c
core and drm edid functions not trying to retry the edid transfer.

Luckily the gmbus quiescenting also times out for these cases, so we
can get out of this mess by returning -ETIMEDOUT for this specific
case. This way we keep the fast-fail of returning -ENXIO if there is
no device present, speeding up the boot process.

This regression has been introduced in

commit e646d5773572bf52017983d758bdf05777dc5600
Author: Daniel Kurtz 
Date:   Fri Mar 30 19:46:38 2012 +0800

drm/i915/intel_i2c: always wait for IDLE before clearing NAK

v2: Return -ETIMEDOUT for this case and keep the -ENXIO for real NAKs,
suggested by Daniel Kurtz.

Cc: Daniel Kurtz 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49518
Reported-and-Tested-by: Julian Simioni 
Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_i2c.c |   21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index e04255e..892477b 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -396,11 +396,22 @@ clear_err:
 * Wait for bus to IDLE before clearing NAK.
 * If we clear the NAK while bus is still active, then it will stay
 * active and the next transaction may fail.
+*
+* If no ACK is received during the address phase of a transaction, the
+* adapter must report -ENXIO. It is not clear what to return if no ACK
+* is received at other times. But we have to be careful to not return
+* spurious -ENXIO because that will prevent i2c and drm edid functions
+* from retrying. So return -ENXIO only when gmbus properly quiescents -
+* timing out seems to happen when there _is_ a ddc chip present, but
+* it's slow responding and only answers on the 2nd retry.
 */
+   ret = -ENXIO;
if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0,
-10))
+10)) {
DRM_DEBUG_KMS("GMBUS [%s] timed out after NAK\n",
  adapter->name);
+   ret = -ETIMEDOUT;
+   }
 
/* Toggle the Software Clear Interrupt bit. This has the effect
 * of resetting the GMBUS controller and so clearing the
@@ -414,14 +425,6 @@ clear_err:
 adapter->name, msgs[i].addr,
 (msgs[i].flags & I2C_M_RD) ? 'r' : 'w', msgs[i].len);
 
-   /*
-* If no ACK is received during the address phase of a transaction,
-* the adapter must report -ENXIO.
-* It is not clear what to return if no ACK is received at other times.
-* So, we always return -ENXIO in all NAK cases, to ensure we send
-* it at least during the one case that is specified.
-*/
-   ret = -ENXIO;
goto out;
 
 timeout:
-- 
1.7.10

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

Re: [Intel-gfx] [PATCH] drm/i915: don't return -ENXIO from gmbus xfer

2012-05-21 Thread Daniel Vetter 
On Sun, May 20, 2012 at 08:16:46PM +0200, Daniel Vetter wrote:
> On Sun, May 20, 2012 at 11:07:46AM -0700, Daniel Kurtz wrote:
> > Since this reported issue is happening in this double error path, I'd
> > rather a patch that fixes it without disabling the more generic NAK
> > path.  Maybe something like this:
> 
> Hm, good suggestion. This way, if we get a NAK but no issues later on,
> we'll still fail faster if gmbus detected that no device is responding.
> Which should speed up boot a bit. I'll run this past the bug reporter.

We're lucky, and the modified patch tested ok by the bug reporter. I'll
follow up with v2, please smash your r-b onto it if you're satisfied.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: be more careful when returning -ENXIO in gmbus transfer

2012-05-21 Thread Chris Wilson 
On Mon, 21 May 2012 20:19:48 +0200, Daniel Vetter  
wrote:
> ... flaky ddc hardware can cause a spurious NAK, resulting in the i2c
> core and drm edid functions not trying to retry the edid transfer.
> 
> Luckily the gmbus quiescenting also times out for these cases, so we
> can get out of this mess by returning -ETIMEDOUT for this specific
> case. This way we keep the fast-fail of returning -ENXIO if there is
> no device present, speeding up the boot process.
> 
> This regression has been introduced in
> 
> commit e646d5773572bf52017983d758bdf05777dc5600
> Author: Daniel Kurtz 
> Date:   Fri Mar 30 19:46:38 2012 +0800
> 
> drm/i915/intel_i2c: always wait for IDLE before clearing NAK
> 
> v2: Return -ETIMEDOUT for this case and keep the -ENXIO for real NAKs,
> suggested by Daniel Kurtz.
> 
> Cc: Daniel Kurtz 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49518
> Reported-and-Tested-by: Julian Simioni 
> Signed-Off-by: Daniel Vetter 

Acked-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: properly handle interlaced bit for sdvo dtd conversion

2012-05-21 Thread Paulo Zanoni 
2012/5/12 Daniel Vetter :
> We've simply ignored this, which isn't too great. With this, interlaced
> 1080i works on my HDMI screen connected through sdvo. For no apparent
> reason anything else still doesn't work as it should.
>
> While at it, give these magic numbers in the dtd proper names and
> add a comment that they match with EDID detailed timings.
>
> v2: Actually use the right bit for interlaced.
>
> Signed-Off-by: Daniel Vetter 

This looks like 2 different patches merged into one :)

In theory, bits 2 and 1 could have a different meaning too, but I'm
not sure how applicable this is to sDVO. But yeah, I had to read this
code in the past and 0x2 and 0x4 were not exactly nice to read, so at
least now those bits have a name :)

Not tested, just reviewed against the sdvo and edid specs...
Reviewed-by: Paulo Zanoni 

> ---
>  drivers/gpu/drm/i915/intel_sdvo.c      |   12 
>  drivers/gpu/drm/i915/intel_sdvo_regs.h |    5 +
>  2 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index 125228e..a658207 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -783,10 +783,12 @@ static void intel_sdvo_get_dtd_from_mode(struct 
> intel_sdvo_dtd *dtd,
>                ((v_sync_len & 0x30) >> 4);
>
>        dtd->part2.dtd_flags = 0x18;
> +       if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> +               dtd->part2.dtd_flags |= DTD_FLAG_INTERLACE;
>        if (mode->flags & DRM_MODE_FLAG_PHSYNC)
> -               dtd->part2.dtd_flags |= 0x2;
> +               dtd->part2.dtd_flags |= DTD_FLAG_HSYNC_POSITIVE;
>        if (mode->flags & DRM_MODE_FLAG_PVSYNC)
> -               dtd->part2.dtd_flags |= 0x4;
> +               dtd->part2.dtd_flags |= DTD_FLAG_VSYNC_POSITIVE;
>
>        dtd->part2.sdvo_flags = 0;
>        dtd->part2.v_sync_off_high = v_sync_offset & 0xc0;
> @@ -820,9 +822,11 @@ static void intel_sdvo_get_mode_from_dtd(struct 
> drm_display_mode * mode,
>        mode->clock = dtd->part1.clock * 10;
>
>        mode->flags &= ~(DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC);
> -       if (dtd->part2.dtd_flags & 0x2)
> +       if (dtd->part2.dtd_flags & DTD_FLAG_INTERLACE)
> +               mode->flags |= DRM_MODE_FLAG_INTERLACE;
> +       if (dtd->part2.dtd_flags & DTD_FLAG_HSYNC_POSITIVE)
>                mode->flags |= DRM_MODE_FLAG_PHSYNC;
> -       if (dtd->part2.dtd_flags & 0x4)
> +       if (dtd->part2.dtd_flags & DTD_FLAG_VSYNC_POSITIVE)
>                mode->flags |= DRM_MODE_FLAG_PVSYNC;
>  }
>
> diff --git a/drivers/gpu/drm/i915/intel_sdvo_regs.h 
> b/drivers/gpu/drm/i915/intel_sdvo_regs.h
> index 6b7b22f..9d03014 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo_regs.h
> +++ b/drivers/gpu/drm/i915/intel_sdvo_regs.h
> @@ -61,6 +61,11 @@ struct intel_sdvo_caps {
>        u16 output_flags;
>  } __attribute__((packed));
>
> +/* Note: SDVO detailed timing flags match EDID misc flags. */
> +#define DTD_FLAG_HSYNC_POSITIVE (1 << 1)
> +#define DTD_FLAG_VSYNC_POSITIVE (1 << 2)
> +#define DTD_FLAG_INTERLACE     (1 << 7)
> +
>  /** This matches the EDID DTD structure, more or less */
>  struct intel_sdvo_dtd {
>        struct {
> --
> 1.7.8.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



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

[Intel-gfx] [PATCH] drm/i915: fix module unload since error_state rework

2012-05-21 Thread Daniel Vetter 
We need to remove the debugfs file. Regression introduce in

commit d54423037f141518950f324af88a551a82449496
Author: Daniel Vetter 
Date:   Fri Apr 27 15:17:40 2012 +0200

drm/i915: allow the existing error_state to be destroyed

Reported-and-Tested-by: Jesse Barnes 
Signed-Off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_debugfs.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index eb2b3c2..5363e9c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2032,6 +2032,8 @@ void i915_debugfs_cleanup(struct drm_minor *minor)
 1, minor);
drm_debugfs_remove_files((struct drm_info_list *) &i915_ring_stop_fops,
 1, minor);
+   drm_debugfs_remove_files((struct drm_info_list *) 
&i915_error_state_fops,
+1, minor);
 }
 
 #endif /* CONFIG_DEBUG_FS */
-- 
1.7.7.6

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

Re: [Intel-gfx] [PATCH] drm/i915: be more careful when returning -ENXIO in gmbus transfer

2012-05-21 Thread Daniel Vetter 
On Mon, May 21, 2012 at 11:31:20AM -0700, Daniel Kurtz wrote:
> On Mon, May 21, 2012 at 11:24 AM, Chris Wilson  
> wrote:
> > On Mon, 21 May 2012 20:19:48 +0200, Daniel Vetter  
> > wrote:
> >> ... flaky ddc hardware can cause a spurious NAK, resulting in the i2c
> >> core and drm edid functions not trying to retry the edid transfer.
> >>
> >> Luckily the gmbus quiescenting also times out for these cases, so we
> >> can get out of this mess by returning -ETIMEDOUT for this specific
> >> case. This way we keep the fast-fail of returning -ENXIO if there is
> >> no device present, speeding up the boot process.
> >>
> >> This regression has been introduced in
> >>
> >> commit e646d5773572bf52017983d758bdf05777dc5600
> >> Author: Daniel Kurtz 
> >> Date:   Fri Mar 30 19:46:38 2012 +0800
> >>
> >>     drm/i915/intel_i2c: always wait for IDLE before clearing NAK
> >>
> >> v2: Return -ETIMEDOUT for this case and keep the -ENXIO for real NAKs,
> >> suggested by Daniel Kurtz.
> >>
> >> Cc: Daniel Kurtz 
> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49518
> >> Reported-and-Tested-by: Julian Simioni 
> >> Signed-Off-by: Daniel Vetter 
> >
> > Acked-by: Chris Wilson 
> > -Chris
> >
> > --
> > Chris Wilson, Intel Open Source Technology Centre
> 
> Reviewed-by: Daniel Kurtz 
Picked up for -fixes, thanks for the review.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: enable vdd when switching off the eDP panel

2012-05-21 Thread Chris Wilson 
On Mon, 21 May 2012 18:40:30 +0200, Daniel Vetter  wrote:
> Hi Keith&Chris,
> 
> This is the patch for you to try on the macbook airs 

Cursory testing of switching on and off the internal panel seems ok.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: consolidate interrupt naming scheme

2012-05-21 Thread Ben Widawsky 
On Mon, 21 May 2012 09:46:00 +0100
Chris Wilson  wrote:

> On Fri, 18 May 2012 09:02:09 -0700, Ben Widawsky  wrote:
> > here are some opportunities to do things a bit better with the naming of
> > things now that our hindsight is better.
> 
> The major problem with this is that it breaks the expectations of the
> INTEL_ namespace, masquerading per-gen values as fixed constants for all
> chipsets.
> -Chris
> 

With only a couple of exceptions (BSD user interrupt) there is no need
for per-gen values. I think we shouldn't have much trouble maintaining
this as is. The existing naming scheme wrongly calls things GEN6 when
they were introduced earlier (I'm also not sure GT_ is valid for every
interrupt). So the goal was to have I915_* for old stuff, INTEL_* for
everything, and DEVICENAME_ for special cases.


-- 
Ben Widawsky, 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 v4] drm/i915: clarify semaphore-ring interaction

2012-05-21 Thread Ben Widawsky 
On Mon, 21 May 2012 09:44:02 +0100
Chris Wilson  wrote:

> On Sun, 20 May 2012 08:45:38 -0700, Ben Widawsky  wrote:
> > After Daniel split out this code, I think this makes more sense, and
> > looks nicer. Also added some comments to help the situation.
> > 
> > v2: Make signal_mbox be all rings for symmetric-ness.
> > v3: submitted the wrong version of the patch before.
> >   v2 had an issue with odd number of rings. The fix is to always emit an
> >   even number of instructions to the ring with mbox updates.
> > v4: I suck. The code should send out mbox updates for NUM_RINGS-1 *
> >   number of commands. Instead of NUM_RINGS * number of commands-1.
> > -ret = intel_ring_begin(ring, round_up((I915_NUM_RINGS) * 3, 2) + 4);
> > +ret = intel_ring_begin(ring, round_up((I915_NUM_RINGS-1) * 4, 2) + 4);
> 
> I'm honestly less enthralled about v4. I'd rather see that as a separate
> preparatory patch so that it is put into context.
> -Chris
> 

I can do that. Are you okay with the idea otherwise? This is really all
prep work for some HSW patches anyway.

-- 
Ben Widawsky, 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 v4] drm/i915: clarify semaphore-ring interaction

2012-05-21 Thread Chris Wilson 
On Mon, 21 May 2012 14:03:05 -0700, Ben Widawsky  wrote:
> I can do that. Are you okay with the idea otherwise? This is really all
> prep work for some HSW patches anyway.

Yes, I can see where you are going, I just need that little bit of
convincing that it will all work out in the end ;-)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: consolidate interrupt naming scheme

2012-05-21 Thread Chris Wilson 
On Mon, 21 May 2012 14:01:52 -0700, Ben Widawsky  wrote:
> On Mon, 21 May 2012 09:46:00 +0100
> Chris Wilson  wrote:
> 
> > On Fri, 18 May 2012 09:02:09 -0700, Ben Widawsky  wrote:
> > > here are some opportunities to do things a bit better with the naming of
> > > things now that our hindsight is better.
> > 
> > The major problem with this is that it breaks the expectations of the
> > INTEL_ namespace, masquerading per-gen values as fixed constants for all
> > chipsets.
> > -Chris
> > 
> 
> With only a couple of exceptions (BSD user interrupt) there is no need
> for per-gen values. I think we shouldn't have much trouble maintaining
> this as is. The existing naming scheme wrongly calls things GEN6 when
> they were introduced earlier (I'm also not sure GT_ is valid for every
> interrupt). So the goal was to have I915_* for old stuff, INTEL_* for
> everything, and DEVICENAME_ for special cases.

I concur that the current names are rather ad-hoc and not well thought
out. I'm just not buying that this replacement is any better. INTEL_BSD
is a complete turn off.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: enable vdd when switching off the eDP panel

2012-05-21 Thread Keith Packard 
Daniel Vetter  writes:

>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -1154,11 +1154,10 @@ static void ironlake_edp_panel_off(struct intel_dp 
>> *intel_dp)
>>  
>>  DRM_DEBUG_KMS("Turn eDP power off\n");
>>  
>> -WARN(intel_dp->want_panel_vdd, "Cannot turn power off while VDD is 
>> on\n");
>> -ironlake_panel_vdd_off_sync(intel_dp); /* finish any pending work */
>> +WARN(!intel_dp->want_panel_vdd, "Need VDD to turn off panel\n");
>>  
>>  pp = ironlake_get_pp_control(dev_priv);
>> -pp &= ~(POWER_TARGET_ON | EDP_FORCE_VDD | PANEL_POWER_RESET | 
>> EDP_BLC_ENABLE);
>> +pp &= ~(POWER_TARGET_ON | PANEL_POWER_RESET | EDP_BLC_ENABLE);

Can you explain where the panel is getting turned off here?

-- 
keith.pack...@intel.com


pgpys5TelbnPm.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: enable vdd when switching off the eDP panel

2012-05-21 Thread Daniel Vetter 
On Mon, May 21, 2012 at 06:49:18PM -0700, Keith Packard wrote:
> Daniel Vetter  writes:
> 
> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> @@ -1154,11 +1154,10 @@ static void ironlake_edp_panel_off(struct intel_dp 
> >> *intel_dp)
> >>  
> >>DRM_DEBUG_KMS("Turn eDP power off\n");
> >>  
> >> -  WARN(intel_dp->want_panel_vdd, "Cannot turn power off while VDD is 
> >> on\n");
> >> -  ironlake_panel_vdd_off_sync(intel_dp); /* finish any pending work */
> >> +  WARN(!intel_dp->want_panel_vdd, "Need VDD to turn off panel\n");
> >>  
> >>pp = ironlake_get_pp_control(dev_priv);
> >> -  pp &= ~(POWER_TARGET_ON | EDP_FORCE_VDD | PANEL_POWER_RESET | 
> >> EDP_BLC_ENABLE);
> >> +  pp &= ~(POWER_TARGET_ON | PANEL_POWER_RESET | EDP_BLC_ENABLE);
> 
> Can you explain where the panel is getting turned off here?

Well, before this change the edp power off sequence was:
- switch vdd off (or more precise: ensure it's off)
- switch backlight off
- switch panel power off (i.e. the above function)

Now the new sequence is (always with the right amounts of delays,
obviously):
- switch vdd on
- switch backlight off
- switch panel off
- switch vdd off

That's why I've had to remove the EDP_FORCE_VDD bit from the above
bitfrobbing, because we now want vdd to stay on while we do the power
sequence above.

The reason is that we have a callchain (in intel_dp_prepare) where we do
some aux channel communication after having switched off the panel. And
that needs vdd, but because edp_panel_off killed that, things got
confused.
-Daniel
-- 
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx