[PATCH 1/2] drm/i915/dp: don't mention eDP bpp clamping if it doesn't affect bpp

[PATCH 1/2] drm/i915/dp: don't mention eDP bpp clamping if it doesn't affect bpp

[Jani Nikula]

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

---

This is useful with the follow-up patch that frobs
dev_priv->vbt.edp_bpp, and the value no longer comes directly from VBT.
---
 drivers/gpu/drm/i915/intel_dp.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e4fdedc..f63aa8c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -822,10 +822,11 @@ intel_dp_compute_config(struct intel_encoder *encoder,
 	/* Walk through all bpp values. Luckily they're all nicely spaced with 2
 	 * bpc in between. */
 	bpp = pipe_config->pipe_bpp;
-	if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp) {
+	if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp &&
+	    dev_priv->vbt.edp_bpp < bpp) {
 		DRM_DEBUG_KMS("clamping bpp for eDP panel to BIOS-provided %i\n",
 			      dev_priv->vbt.edp_bpp);
-		bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp);
+		bpp = dev_priv->vbt.edp_bpp;
 	}
 
 	for (; bpp >= 6*3; bpp -= 2*3) {
-- 
1.7.9.5

[PATCH 2/2] drm/i915/dp: workaround BIOS eDP bpp clamping issue

[Jani Nikula]

This isn't a real fix to the problem, but rather a stopgap measure while
trying to find a proper solution.

There are several laptops out there that fail to light up the eDP panel
in UEFI boot mode. They seem to be mostly IVB machines, including but
apparently not limited to Dell XPS 13, Asus TX300, Asus UX31A, Asus
UX32VD, Acer Aspire S7. They seem to work in CSM or legacy boot.

The difference between UEFI and CSM is that the BIOS provides a
different VBT to the kernel. The UEFI VBT typically specifies 18 bpp and
1.62 GHz link for eDP, while CSM VBT has 24 bpp and 2.7 GHz link. We end
up clamping to 18 bpp in UEFI mode, which we can fit in the 1.62 Ghz
link, and for reasons yet unknown fail to light up the panel.

Dithering from 24 to 18 bpp itself seems to work; if we use 18 bpp with
2.7 GHz link, the eDP panel lights up. So essentially this is a link
speed issue, and *not* a bpp clamping issue.

The bug raised its head since
commit 657445fe8660100ad174600ebfa61536392b7624
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat May 4 10:09:18 2013 +0200

    Revert "drm/i915: revert eDP bpp clamping code changes"

which started clamping bpp *before* computing the link requirements, and
thus affecting the required bandwidth. Clamping after the computations
kept the link at 2.7 GHz.

Even though the BIOS tells us to use 18 bpp through the VBT, it happily
boots up at 24 bpp and 2.7 GHz itself! Use this information to
selectively ignore the VBT provided value.

We can't ignore the VBT eDP bpp altogether, as there are other laptops
that do require the clamping to be used due to EDID reporting higher bpp
than the panel can support.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59841
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67950
CC: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

---

For backporting to v3.12, you also need
commit 84a44adc16ab118cf7e0518861216cbc91cee6e4
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Sep 6 23:29:00 2013 +0300

    drm/i915: Add support for pipe_bpp readout
---
 drivers/gpu/drm/i915/intel_dp.c |   21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f63aa8c..cb895d8 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1476,6 +1476,27 @@ static void intel_dp_get_config(struct intel_encoder *encoder,
 		ironlake_check_encoder_dotclock(pipe_config, dotclock);
 
 	pipe_config->adjusted_mode.crtc_clock = dotclock;
+
+	if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp &&
+	    pipe_config->pipe_bpp > dev_priv->vbt.edp_bpp) {
+		/*
+		 * This is a big fat ugly hack.
+		 *
+		 * Some machines in UEFI boot mode provide us a VBT that has 18
+		 * bpp and 1.62 GHz link bandwidth for eDP, which for reasons
+		 * unknown we fail to light up. Yet the same BIOS boots up with
+		 * 24 bpp and 2.7 GHz link. Use the same bpp as the BIOS uses as
+		 * max, not what it tells us to use.
+		 *
+		 * Note: This will still be broken if the eDP panel is not lit
+		 * up by the BIOS, and thus we can't get the mode at module
+		 * load.
+		 */
+		DRM_DEBUG_KMS("pipe has %d bpp for eDP panel, overriding BIOS-provided max %d bpp\n",
+			      pipe_config->pipe_bpp, dev_priv->vbt.edp_bpp);
+		dev_priv->vbt.edp_bpp = pipe_config->pipe_bpp;
+	}
+
 }
 
 static bool is_edp_psr(struct drm_device *dev)
-- 
1.7.9.5

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

Re: [PATCH 2/2] drm/i915/dp: workaround BIOS eDP bpp clamping issue

[Jani Nikula]

On Wed, 16 Oct 2013, Jani Nikula <jani.nikula@intel.com> wrote:
> This isn't a real fix to the problem, but rather a stopgap measure while
> trying to find a proper solution.
>
> There are several laptops out there that fail to light up the eDP panel
> in UEFI boot mode. They seem to be mostly IVB machines, including but
> apparently not limited to Dell XPS 13, Asus TX300, Asus UX31A, Asus
> UX32VD, Acer Aspire S7. They seem to work in CSM or legacy boot.
>
> The difference between UEFI and CSM is that the BIOS provides a
> different VBT to the kernel. The UEFI VBT typically specifies 18 bpp and
> 1.62 GHz link for eDP, while CSM VBT has 24 bpp and 2.7 GHz link. We end
> up clamping to 18 bpp in UEFI mode, which we can fit in the 1.62 Ghz
> link, and for reasons yet unknown fail to light up the panel.
>
> Dithering from 24 to 18 bpp itself seems to work; if we use 18 bpp with
> 2.7 GHz link, the eDP panel lights up. So essentially this is a link
> speed issue, and *not* a bpp clamping issue.
>
> The bug raised its head since
> commit 657445fe8660100ad174600ebfa61536392b7624
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Sat May 4 10:09:18 2013 +0200
>
>     Revert "drm/i915: revert eDP bpp clamping code changes"
>
> which started clamping bpp *before* computing the link requirements, and
> thus affecting the required bandwidth. Clamping after the computations
> kept the link at 2.7 GHz.
>
> Even though the BIOS tells us to use 18 bpp through the VBT, it happily
> boots up at 24 bpp and 2.7 GHz itself! Use this information to
> selectively ignore the VBT provided value.
>
> We can't ignore the VBT eDP bpp altogether, as there are other laptops
> that do require the clamping to be used due to EDID reporting higher bpp
> than the panel can support.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59841
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67950
> CC: stable@vger.kernel.org
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Tested-by: Ulf Winkelvos <ulf@winkelvos.de>
Tested-by: jkp <jkp@iki.fi>

and I also have another machine on loan this fixes.

Jani.


>
> ---
>
> For backporting to v3.12, you also need
> commit 84a44adc16ab118cf7e0518861216cbc91cee6e4
> Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Date:   Fri Sep 6 23:29:00 2013 +0300
>
>     drm/i915: Add support for pipe_bpp readout
> ---
>  drivers/gpu/drm/i915/intel_dp.c |   21 +++++++++++++++++++++
>  1 file changed, 21 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index f63aa8c..cb895d8 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1476,6 +1476,27 @@ static void intel_dp_get_config(struct intel_encoder *encoder,
>  		ironlake_check_encoder_dotclock(pipe_config, dotclock);
>  
>  	pipe_config->adjusted_mode.crtc_clock = dotclock;
> +
> +	if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp &&
> +	    pipe_config->pipe_bpp > dev_priv->vbt.edp_bpp) {
> +		/*
> +		 * This is a big fat ugly hack.
> +		 *
> +		 * Some machines in UEFI boot mode provide us a VBT that has 18
> +		 * bpp and 1.62 GHz link bandwidth for eDP, which for reasons
> +		 * unknown we fail to light up. Yet the same BIOS boots up with
> +		 * 24 bpp and 2.7 GHz link. Use the same bpp as the BIOS uses as
> +		 * max, not what it tells us to use.
> +		 *
> +		 * Note: This will still be broken if the eDP panel is not lit
> +		 * up by the BIOS, and thus we can't get the mode at module
> +		 * load.
> +		 */
> +		DRM_DEBUG_KMS("pipe has %d bpp for eDP panel, overriding BIOS-provided max %d bpp\n",
> +			      pipe_config->pipe_bpp, dev_priv->vbt.edp_bpp);
> +		dev_priv->vbt.edp_bpp = pipe_config->pipe_bpp;
> +	}
> +
>  }
>  
>  static bool is_edp_psr(struct drm_device *dev)
> -- 
> 1.7.9.5
>

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH for 3.12/-fixes 1/2] drm/i915: Add support for pipe_bpp readout

[Jani Nikula]

From: Ville Syrjälä <ville.syrjala@linux.intel.com>

On CTG+ read out the pipe bpp setting from hardware and fill it into
pipe config. Also check it appropriately.

v2: Don't do the pipe_bpp extraction inside the PCH only code block on
    ILK+.
    Avoid the PIPECONF read as we already have read it for the
    PIPECONF_EANBLE check.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

---

This is already in drm-intel-next-queued as
commit 42571aefafb1d330ef84eb29418832f72e7dfb4c
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Sep 6 23:29:00 2013 +0300

    drm/i915: Add support for pipe_bpp readout

but is needed for patch 2/2.
---
 drivers/gpu/drm/i915/intel_ddi.c     |   17 ++++++++++++++++
 drivers/gpu/drm/i915/intel_display.c |   36 ++++++++++++++++++++++++++++++++++
 2 files changed, 53 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 63de270..beb7f65 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1268,6 +1268,23 @@ static void intel_ddi_get_config(struct intel_encoder *encoder,
 		flags |= DRM_MODE_FLAG_NVSYNC;
 
 	pipe_config->adjusted_mode.flags |= flags;
+
+	switch (temp & TRANS_DDI_BPC_MASK) {
+	case TRANS_DDI_BPC_6:
+		pipe_config->pipe_bpp = 18;
+		break;
+	case TRANS_DDI_BPC_8:
+		pipe_config->pipe_bpp = 24;
+		break;
+	case TRANS_DDI_BPC_10:
+		pipe_config->pipe_bpp = 30;
+		break;
+	case TRANS_DDI_BPC_12:
+		pipe_config->pipe_bpp = 36;
+		break;
+	default:
+		break;
+	}
 }
 
 static void intel_ddi_destroy(struct drm_encoder *encoder)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 581fb4b..725f0be 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4983,6 +4983,22 @@ static bool i9xx_get_pipe_config(struct intel_crtc *crtc,
 	if (!(tmp & PIPECONF_ENABLE))
 		return false;
 
+	if (IS_G4X(dev) || IS_VALLEYVIEW(dev)) {
+		switch (tmp & PIPECONF_BPC_MASK) {
+		case PIPECONF_6BPC:
+			pipe_config->pipe_bpp = 18;
+			break;
+		case PIPECONF_8BPC:
+			pipe_config->pipe_bpp = 24;
+			break;
+		case PIPECONF_10BPC:
+			pipe_config->pipe_bpp = 30;
+			break;
+		default:
+			break;
+		}
+	}
+
 	intel_get_pipe_timings(crtc, pipe_config);
 
 	i9xx_get_pfit_config(crtc, pipe_config);
@@ -5881,6 +5897,23 @@ static bool ironlake_get_pipe_config(struct intel_crtc *crtc,
 	if (!(tmp & PIPECONF_ENABLE))
 		return false;
 
+	switch (tmp & PIPECONF_BPC_MASK) {
+	case PIPECONF_6BPC:
+		pipe_config->pipe_bpp = 18;
+		break;
+	case PIPECONF_8BPC:
+		pipe_config->pipe_bpp = 24;
+		break;
+	case PIPECONF_10BPC:
+		pipe_config->pipe_bpp = 30;
+		break;
+	case PIPECONF_12BPC:
+		pipe_config->pipe_bpp = 36;
+		break;
+	default:
+		break;
+	}
+
 	if (I915_READ(PCH_TRANSCONF(crtc->pipe)) & TRANS_ENABLE) {
 		struct intel_shared_dpll *pll;
 
@@ -8612,6 +8645,9 @@ intel_pipe_config_compare(struct drm_device *dev,
 	PIPE_CONF_CHECK_X(dpll_hw_state.fp0);
 	PIPE_CONF_CHECK_X(dpll_hw_state.fp1);
 
+	if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5)
+		PIPE_CONF_CHECK_I(pipe_bpp);
+
 #undef PIPE_CONF_CHECK_X
 #undef PIPE_CONF_CHECK_I
 #undef PIPE_CONF_CHECK_FLAGS
-- 
1.7.9.5

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

[PATCH for 3.12/-fixes 2/2] drm/i915/dp: workaround BIOS eDP bpp clamping issue

[Jani Nikula]

This isn't a real fix to the problem, but rather a stopgap measure while
trying to find a proper solution.

There are several laptops out there that fail to light up the eDP panel
in UEFI boot mode. They seem to be mostly IVB machines, including but
apparently not limited to Dell XPS 13, Asus TX300, Asus UX31A, Asus
UX32VD, Acer Aspire S7. They seem to work in CSM or legacy boot.

The difference between UEFI and CSM is that the BIOS provides a
different VBT to the kernel. The UEFI VBT typically specifies 18 bpp and
1.62 GHz link for eDP, while CSM VBT has 24 bpp and 2.7 GHz link. We end
up clamping to 18 bpp in UEFI mode, which we can fit in the 1.62 Ghz
link, and for reasons yet unknown fail to light up the panel.

Dithering from 24 to 18 bpp itself seems to work; if we use 18 bpp with
2.7 GHz link, the eDP panel lights up. So essentially this is a link
speed issue, and *not* a bpp clamping issue.

The bug raised its head since
commit 657445fe8660100ad174600ebfa61536392b7624
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sat May 4 10:09:18 2013 +0200

    Revert "drm/i915: revert eDP bpp clamping code changes"

which started clamping bpp *before* computing the link requirements, and
thus affecting the required bandwidth. Clamping after the computations
kept the link at 2.7 GHz.

Even though the BIOS tells us to use 18 bpp through the VBT, it happily
boots up at 24 bpp and 2.7 GHz itself! Use this information to
selectively ignore the VBT provided value.

We can't ignore the VBT eDP bpp altogether, as there are other laptops
that do require the clamping to be used due to EDID reporting higher bpp
than the panel can support.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59841
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67950
Tested-by: Ulf Winkelvos <ulf@winkelvos.de>
Tested-by: jkp <jkp@iki.fi>
CC: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
---
 drivers/gpu/drm/i915/intel_dp.c |   20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2c555f9..1a43137 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1401,6 +1401,26 @@ static void intel_dp_get_config(struct intel_encoder *encoder,
 		else
 			pipe_config->port_clock = 270000;
 	}
+
+	if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp &&
+	    pipe_config->pipe_bpp > dev_priv->vbt.edp_bpp) {
+		/*
+		 * This is a big fat ugly hack.
+		 *
+		 * Some machines in UEFI boot mode provide us a VBT that has 18
+		 * bpp and 1.62 GHz link bandwidth for eDP, which for reasons
+		 * unknown we fail to light up. Yet the same BIOS boots up with
+		 * 24 bpp and 2.7 GHz link. Use the same bpp as the BIOS uses as
+		 * max, not what it tells us to use.
+		 *
+		 * Note: This will still be broken if the eDP panel is not lit
+		 * up by the BIOS, and thus we can't get the mode at module
+		 * load.
+		 */
+		DRM_DEBUG_KMS("pipe has %d bpp for eDP panel, overriding BIOS-provided max %d bpp\n",
+			      pipe_config->pipe_bpp, dev_priv->vbt.edp_bpp);
+		dev_priv->vbt.edp_bpp = pipe_config->pipe_bpp;
+	}
 }
 
 static bool is_edp_psr(struct intel_dp *intel_dp)
-- 
1.7.9.5

Re: [PATCH for 3.12/-fixes 2/2] drm/i915/dp: workaround BIOS eDP bpp clamping issue

[Daniel Vetter]

On Mon, Oct 21, 2013 at 10:52:07AM +0300, Jani Nikula wrote:
> This isn't a real fix to the problem, but rather a stopgap measure while
> trying to find a proper solution.
> 
> There are several laptops out there that fail to light up the eDP panel
> in UEFI boot mode. They seem to be mostly IVB machines, including but
> apparently not limited to Dell XPS 13, Asus TX300, Asus UX31A, Asus
> UX32VD, Acer Aspire S7. They seem to work in CSM or legacy boot.
> 
> The difference between UEFI and CSM is that the BIOS provides a
> different VBT to the kernel. The UEFI VBT typically specifies 18 bpp and
> 1.62 GHz link for eDP, while CSM VBT has 24 bpp and 2.7 GHz link. We end
> up clamping to 18 bpp in UEFI mode, which we can fit in the 1.62 Ghz
> link, and for reasons yet unknown fail to light up the panel.
> 
> Dithering from 24 to 18 bpp itself seems to work; if we use 18 bpp with
> 2.7 GHz link, the eDP panel lights up. So essentially this is a link
> speed issue, and *not* a bpp clamping issue.
> 
> The bug raised its head since
> commit 657445fe8660100ad174600ebfa61536392b7624
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Sat May 4 10:09:18 2013 +0200
> 
>     Revert "drm/i915: revert eDP bpp clamping code changes"
> 
> which started clamping bpp *before* computing the link requirements, and
> thus affecting the required bandwidth. Clamping after the computations
> kept the link at 2.7 GHz.
> 
> Even though the BIOS tells us to use 18 bpp through the VBT, it happily
> boots up at 24 bpp and 2.7 GHz itself! Use this information to
> selectively ignore the VBT provided value.
> 
> We can't ignore the VBT eDP bpp altogether, as there are other laptops
> that do require the clamping to be used due to EDID reporting higher bpp
> than the panel can support.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=59841
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67950
> Tested-by: Ulf Winkelvos <ulf@winkelvos.de>
> Tested-by: jkp <jkp@iki.fi>
> CC: stable@vger.kernel.org
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Both merged to -fixes, thanks for the quick backport. I've added the note
about we need the first patch to the commit message and also added the cc:
stable tag.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: [PATCH 1/2] drm/i915/dp: don't mention eDP bpp clamping if it doesn't affect bpp

[Daniel Vetter]

On Wed, Oct 16, 2013 at 05:06:17PM +0300, Jani Nikula wrote:
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> 
> ---
> 
> This is useful with the follow-up patch that frobs
> dev_priv->vbt.edp_bpp, and the value no longer comes directly from VBT.

Same as for Ben's patch: Such prep-patch justifications should imo be part
of the commit message. I've moved it.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_dp.c |    5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index e4fdedc..f63aa8c 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -822,10 +822,11 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>  	/* Walk through all bpp values. Luckily they're all nicely spaced with 2
>  	 * bpc in between. */
>  	bpp = pipe_config->pipe_bpp;
> -	if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp) {
> +	if (is_edp(intel_dp) && dev_priv->vbt.edp_bpp &&
> +	    dev_priv->vbt.edp_bpp < bpp) {
>  		DRM_DEBUG_KMS("clamping bpp for eDP panel to BIOS-provided %i\n",
>  			      dev_priv->vbt.edp_bpp);
> -		bpp = min_t(int, bpp, dev_priv->vbt.edp_bpp);
> +		bpp = dev_priv->vbt.edp_bpp;
>  	}
>  
>  	for (; bpp >= 6*3; bpp -= 2*3) {
> -- 
> 1.7.9.5
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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