* [PATCH 1/5] drm/i915: Move double wide mode handling into pipe_config
2013-09-02 18:24 [PATCH 0/5] drm/i915: Double wide pipe config ville.syrjala
@ 2013-09-02 18:24 ` ville.syrjala
2013-09-02 18:24 ` [PATCH 2/5] drm/i915: Add double_wide readout and checking ville.syrjala
` (4 subsequent siblings)
5 siblings, 0 replies; 12+ messages in thread
From: ville.syrjala @ 2013-09-02 18:24 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Determine the need for double wide mode already in compute_config
stage as we need that information to figure out if horizontal
coordinates need to be adjusted.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/intel_display.c | 31 ++++++++++++++++++++-----------
drivers/gpu/drm/i915/intel_drv.h | 2 ++
2 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 42e65ce..563c0bc 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4140,6 +4140,23 @@ static int intel_crtc_compute_config(struct intel_crtc *crtc,
return -EINVAL;
}
+ if (INTEL_INFO(dev)->gen < 4) {
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ int clock_limit =
+ dev_priv->display.get_display_clock_speed(dev);
+
+ /*
+ * Enable pixel doubling when the dot clock
+ * is > 90% of the (display) core speed.
+ *
+ * XXX: No double-wide on 915GM pipe B. Is that
+ * the only reason for the pipe == PIPE_A check?
+ */
+ if (crtc->pipe == PIPE_A &&
+ adjusted_mode->clock > clock_limit * 9 / 10)
+ pipe_config->double_wide = true;
+ }
+
/* Cantiga+ cannot handle modes with a hsync front porch of 0.
* WaPruneModeWithIncorrectHsyncOffset:ctg,elk,ilk,snb,ivb,vlv,hsw.
*/
@@ -4819,17 +4836,8 @@ static void i9xx_set_pipeconf(struct intel_crtc *intel_crtc)
pipeconf = 0;
- if (intel_crtc->pipe == 0 && INTEL_INFO(dev)->gen < 4) {
- /* Enable pixel doubling when the dot clock is > 90% of the (display)
- * core speed.
- *
- * XXX: No double-wide on 915GM pipe B. Is that the only reason for the
- * pipe == 0 check?
- */
- if (intel_crtc->config.adjusted_mode.clock >
- dev_priv->display.get_display_clock_speed(dev) * 9 / 10)
- pipeconf |= PIPECONF_DOUBLE_WIDE;
- }
+ if (intel_crtc->config.double_wide)
+ pipeconf |= PIPECONF_DOUBLE_WIDE;
/* only g4x and later have fancy bpc/dither controls */
if (IS_G4X(dev) || IS_VALLEYVIEW(dev)) {
@@ -8267,6 +8275,7 @@ static void intel_dump_pipe_config(struct intel_crtc *crtc,
pipe_config->pch_pfit.pos,
pipe_config->pch_pfit.size);
DRM_DEBUG_KMS("ips: %i\n", pipe_config->ips_enabled);
+ DRM_DEBUG_KMS("double wide: %i\n", pipe_config->double_wide);
}
static bool check_encoder_cloning(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a71b47c..512dccd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -294,6 +294,8 @@ struct intel_crtc_config {
struct intel_link_m_n fdi_m_n;
bool ips_enabled;
+
+ bool double_wide;
};
struct intel_crtc {
--
1.8.1.5
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH 2/5] drm/i915: Add double_wide readout and checking
2013-09-02 18:24 [PATCH 0/5] drm/i915: Double wide pipe config ville.syrjala
2013-09-02 18:24 ` [PATCH 1/5] drm/i915: Move double wide mode handling into pipe_config ville.syrjala
@ 2013-09-02 18:24 ` ville.syrjala
2013-09-02 18:24 ` [PATCH 3/5] drm/i915: Check pixel clock limits on pre-gen4 ville.syrjala
` (3 subsequent siblings)
5 siblings, 0 replies; 12+ messages in thread
From: ville.syrjala @ 2013-09-02 18:24 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Read the double wide pipe information from hardware in
i9xx_get_pipe_config(), and check it in intel_pipe_config_compare()
For gen4+ double_wide is always false so the comparison can be done
on all platforms.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/intel_display.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 563c0bc..ea33468 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5045,6 +5045,9 @@ static bool i9xx_get_pipe_config(struct intel_crtc *crtc,
if (!(tmp & PIPECONF_ENABLE))
return false;
+ if (INTEL_INFO(dev)->gen < 4)
+ pipe_config->double_wide = tmp & PIPECONF_DOUBLE_WIDE;
+
intel_get_pipe_timings(crtc, pipe_config);
i9xx_get_pfit_config(crtc, pipe_config);
@@ -8679,6 +8682,8 @@ intel_pipe_config_compare(struct drm_device *dev,
PIPE_CONF_CHECK_I(ips_enabled);
+ PIPE_CONF_CHECK_I(double_wide);
+
PIPE_CONF_CHECK_I(shared_dpll);
PIPE_CONF_CHECK_X(dpll_hw_state.dpll);
PIPE_CONF_CHECK_X(dpll_hw_state.dpll_md);
--
1.8.1.5
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH 3/5] drm/i915: Check pixel clock limits on pre-gen4
2013-09-02 18:24 [PATCH 0/5] drm/i915: Double wide pipe config ville.syrjala
2013-09-02 18:24 ` [PATCH 1/5] drm/i915: Move double wide mode handling into pipe_config ville.syrjala
2013-09-02 18:24 ` [PATCH 2/5] drm/i915: Add double_wide readout and checking ville.syrjala
@ 2013-09-02 18:24 ` ville.syrjala
2013-09-02 18:51 ` Daniel Vetter
2013-09-02 18:24 ` [PATCH 4/5] drm/i915: pipe_src_w must be even in LVDS dual channel, DVO ganged, and double wide mode ville.syrjala
` (2 subsequent siblings)
5 siblings, 1 reply; 12+ messages in thread
From: ville.syrjala @ 2013-09-02 18:24 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
We don't want to try to push the hardware beyond it's capabilities,
so check the pixel clock against the display core clock limit. Do
it for pre-gen4 for now since that's where we alread have the double
wide pixel clock limit check.
Let's assume that when double wide mode is enabled the max
pixel clock limit is also doubled.
FIXME: panel fitter downscaling probably affects the limit on
non-pch platforms too, so we'd need another version of
ilk_pipe_pixel_rate() to figure that out.
FIXME: should check the limits on all platforms. Also sprites
affect the max allowed pixel rate on some platforms, so we need
to eventually tie all the planes and pipes into one check in
the future. But we need plane state pre-compute before that can
happen.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/intel_display.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index ea33468..040e0ef 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4140,6 +4140,7 @@ static int intel_crtc_compute_config(struct intel_crtc *crtc,
return -EINVAL;
}
+ /* FIXME should check pixel clock limits on all platforms */
if (INTEL_INFO(dev)->gen < 4) {
struct drm_i915_private *dev_priv = dev->dev_private;
int clock_limit =
@@ -4153,8 +4154,13 @@ static int intel_crtc_compute_config(struct intel_crtc *crtc,
* the only reason for the pipe == PIPE_A check?
*/
if (crtc->pipe == PIPE_A &&
- adjusted_mode->clock > clock_limit * 9 / 10)
+ adjusted_mode->clock > clock_limit * 9 / 10) {
+ clock_limit *= 2;
pipe_config->double_wide = true;
+ }
+
+ if (adjusted_mode->clock > clock_limit * 9 / 10)
+ return -EINVAL;
}
/* Cantiga+ cannot handle modes with a hsync front porch of 0.
--
1.8.1.5
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [PATCH 3/5] drm/i915: Check pixel clock limits on pre-gen4
2013-09-02 18:24 ` [PATCH 3/5] drm/i915: Check pixel clock limits on pre-gen4 ville.syrjala
@ 2013-09-02 18:51 ` Daniel Vetter
2013-09-02 19:24 ` Ville Syrjälä
0 siblings, 1 reply; 12+ messages in thread
From: Daniel Vetter @ 2013-09-02 18:51 UTC (permalink / raw)
To: ville.syrjala; +Cc: intel-gfx
On Mon, Sep 02, 2013 at 09:24:26PM +0300, ville.syrjala@linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> We don't want to try to push the hardware beyond it's capabilities,
> so check the pixel clock against the display core clock limit. Do
> it for pre-gen4 for now since that's where we alread have the double
> wide pixel clock limit check.
>
> Let's assume that when double wide mode is enabled the max
> pixel clock limit is also doubled.
>
> FIXME: panel fitter downscaling probably affects the limit on
> non-pch platforms too, so we'd need another version of
> ilk_pipe_pixel_rate() to figure that out.
>
> FIXME: should check the limits on all platforms. Also sprites
> affect the max allowed pixel rate on some platforms, so we need
> to eventually tie all the planes and pipes into one check in
> the future. But we need plane state pre-compute before that can
> happen.
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/i915/intel_display.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index ea33468..040e0ef 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -4140,6 +4140,7 @@ static int intel_crtc_compute_config(struct intel_crtc *crtc,
> return -EINVAL;
> }
>
> + /* FIXME should check pixel clock limits on all platforms */
We do by failing to find the pll. The fun is to move all that code into
the pipe computation stage. The second part of the fun is that on newer
platforms dotclock limits are all encoder specific, so we need to shovel
them into encoder callbacks anyway.
I don't know whether there are any additional pixel clock limits on top of
what the plls can handle, but at least I haven't spotted them yet ...
-Daniel
> if (INTEL_INFO(dev)->gen < 4) {
> struct drm_i915_private *dev_priv = dev->dev_private;
> int clock_limit =
> @@ -4153,8 +4154,13 @@ static int intel_crtc_compute_config(struct intel_crtc *crtc,
> * the only reason for the pipe == PIPE_A check?
> */
> if (crtc->pipe == PIPE_A &&
> - adjusted_mode->clock > clock_limit * 9 / 10)
> + adjusted_mode->clock > clock_limit * 9 / 10) {
> + clock_limit *= 2;
> pipe_config->double_wide = true;
> + }
> +
> + if (adjusted_mode->clock > clock_limit * 9 / 10)
> + return -EINVAL;
> }
>
> /* Cantiga+ cannot handle modes with a hsync front porch of 0.
> --
> 1.8.1.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
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH 3/5] drm/i915: Check pixel clock limits on pre-gen4
2013-09-02 18:51 ` Daniel Vetter
@ 2013-09-02 19:24 ` Ville Syrjälä
2013-09-03 7:55 ` Daniel Vetter
0 siblings, 1 reply; 12+ messages in thread
From: Ville Syrjälä @ 2013-09-02 19:24 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
On Mon, Sep 02, 2013 at 08:51:41PM +0200, Daniel Vetter wrote:
> On Mon, Sep 02, 2013 at 09:24:26PM +0300, ville.syrjala@linux.intel.com wrote:
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > We don't want to try to push the hardware beyond it's capabilities,
> > so check the pixel clock against the display core clock limit. Do
> > it for pre-gen4 for now since that's where we alread have the double
> > wide pixel clock limit check.
> >
> > Let's assume that when double wide mode is enabled the max
> > pixel clock limit is also doubled.
> >
> > FIXME: panel fitter downscaling probably affects the limit on
> > non-pch platforms too, so we'd need another version of
> > ilk_pipe_pixel_rate() to figure that out.
> >
> > FIXME: should check the limits on all platforms. Also sprites
> > affect the max allowed pixel rate on some platforms, so we need
> > to eventually tie all the planes and pipes into one check in
> > the future. But we need plane state pre-compute before that can
> > happen.
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 8 +++++++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index ea33468..040e0ef 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -4140,6 +4140,7 @@ static int intel_crtc_compute_config(struct intel_crtc *crtc,
> > return -EINVAL;
> > }
> >
> > + /* FIXME should check pixel clock limits on all platforms */
>
> We do by failing to find the pll. The fun is to move all that code into
> the pipe computation stage.
Are you 100% sure the PLL algorithm can never give you a clock that
exceeds the display core clock? Looking at the functions to calculate
the core clock, there is an awful lot of variation there already, and we
don't even have those functions filled out for modern platforms.
> The second part of the fun is that on newer
> platforms dotclock limits are all encoder specific, so we need to shovel
> them into encoder callbacks anyway.
>
> I don't know whether there are any additional pixel clock limits on top of
> what the plls can handle, but at least I haven't spotted them yet ...
The display core clock is the big one. We have to check it for other
platforms too eventually since the limit depends on a bunch of factors.
For example on ILK/SNB we need to check whether there's one or two sprites
enabled, are they using RGB or YUV, are they scaled, and if so by how
much? Obviouly we can't do all that until we can pre-compute the state
of all planes.
So actually we may need some more steps in the process. Something like
this:
1) adjust timings
2) calculate PLL settings to get the real clock
3) check double wide etc. that depends on the clock
4) compute plane config
5) check core clock and other plane related global limits
But I don't mind dropping this one now, and revisiting the issue with a
bigger hammer in the future.
--
Ville Syrjälä
Intel OTC
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 3/5] drm/i915: Check pixel clock limits on pre-gen4
2013-09-02 19:24 ` Ville Syrjälä
@ 2013-09-03 7:55 ` Daniel Vetter
0 siblings, 0 replies; 12+ messages in thread
From: Daniel Vetter @ 2013-09-03 7:55 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
On Mon, Sep 02, 2013 at 10:24:18PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 02, 2013 at 08:51:41PM +0200, Daniel Vetter wrote:
> > On Mon, Sep 02, 2013 at 09:24:26PM +0300, ville.syrjala@linux.intel.com wrote:
> > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > >
> > > We don't want to try to push the hardware beyond it's capabilities,
> > > so check the pixel clock against the display core clock limit. Do
> > > it for pre-gen4 for now since that's where we alread have the double
> > > wide pixel clock limit check.
> > >
> > > Let's assume that when double wide mode is enabled the max
> > > pixel clock limit is also doubled.
> > >
> > > FIXME: panel fitter downscaling probably affects the limit on
> > > non-pch platforms too, so we'd need another version of
> > > ilk_pipe_pixel_rate() to figure that out.
> > >
> > > FIXME: should check the limits on all platforms. Also sprites
> > > affect the max allowed pixel rate on some platforms, so we need
> > > to eventually tie all the planes and pipes into one check in
> > > the future. But we need plane state pre-compute before that can
> > > happen.
> > >
> > > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > ---
> > > drivers/gpu/drm/i915/intel_display.c | 8 +++++++-
> > > 1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > > index ea33468..040e0ef 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -4140,6 +4140,7 @@ static int intel_crtc_compute_config(struct intel_crtc *crtc,
> > > return -EINVAL;
> > > }
> > >
> > > + /* FIXME should check pixel clock limits on all platforms */
> >
> > We do by failing to find the pll. The fun is to move all that code into
> > the pipe computation stage.
>
> Are you 100% sure the PLL algorithm can never give you a clock that
> exceeds the display core clock? Looking at the functions to calculate
> the core clock, there is an awful lot of variation there already, and we
> don't even have those functions filled out for modern platforms.
>
> > The second part of the fun is that on newer
> > platforms dotclock limits are all encoder specific, so we need to shovel
> > them into encoder callbacks anyway.
> >
> > I don't know whether there are any additional pixel clock limits on top of
> > what the plls can handle, but at least I haven't spotted them yet ...
>
> The display core clock is the big one. We have to check it for other
> platforms too eventually since the limit depends on a bunch of factors.
> For example on ILK/SNB we need to check whether there's one or two sprites
> enabled, are they using RGB or YUV, are they scaled, and if so by how
> much? Obviouly we can't do all that until we can pre-compute the state
> of all planes.
>
> So actually we may need some more steps in the process. Something like
> this:
> 1) adjust timings
> 2) calculate PLL settings to get the real clock
> 3) check double wide etc. that depends on the clock
> 4) compute plane config
> 5) check core clock and other plane related global limits
>
> But I don't mind dropping this one now, and revisiting the issue with a
> bigger hammer in the future.
I think this one here is good, I've only taking issues with the FIXME
comment since I've thought most of this is encoder specific. But it sounds
like there's an entire set of constraints on the pixel value construction
side of things that we're currently completely missing. So I guess this is
ok.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH 4/5] drm/i915: pipe_src_w must be even in LVDS dual channel, DVO ganged, and double wide mode
2013-09-02 18:24 [PATCH 0/5] drm/i915: Double wide pipe config ville.syrjala
` (2 preceding siblings ...)
2013-09-02 18:24 ` [PATCH 3/5] drm/i915: Check pixel clock limits on pre-gen4 ville.syrjala
@ 2013-09-02 18:24 ` ville.syrjala
2013-09-02 18:24 ` [PATCH 5/5] drm/i915: Fix up pipe vs. double wide confusion ville.syrjala
2013-09-02 18:53 ` [PATCH 0/5] drm/i915: Double wide pipe config Daniel Vetter
5 siblings, 0 replies; 12+ messages in thread
From: ville.syrjala @ 2013-09-02 18:24 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Pipe horizontal source size must be even when either LVDS dual channel
mode, DVO ganged mode, or pipe double wide mode is used.
We must round it down since we can never increase the user specified
viewport size.
The actual error from an odd pipe source width looks like a diagonal
shift, like you might get from a bad stride.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/intel_display.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 040e0ef..ee777a7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4163,6 +4163,16 @@ static int intel_crtc_compute_config(struct intel_crtc *crtc,
return -EINVAL;
}
+ /*
+ * Pipe horizontal size must be even in:
+ * - DVO ganaged mode
+ * - LVDS dual channel mode
+ * - Double wide pipe
+ */
+ if ((intel_pipe_has_type(&crtc->base, INTEL_OUTPUT_LVDS) &&
+ intel_is_dual_link_lvds(dev)) || pipe_config->double_wide)
+ pipe_config->pipe_src_w &= ~1;
+
/* Cantiga+ cannot handle modes with a hsync front porch of 0.
* WaPruneModeWithIncorrectHsyncOffset:ctg,elk,ilk,snb,ivb,vlv,hsw.
*/
--
1.8.1.5
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH 5/5] drm/i915: Fix up pipe vs. double wide confusion
2013-09-02 18:24 [PATCH 0/5] drm/i915: Double wide pipe config ville.syrjala
` (3 preceding siblings ...)
2013-09-02 18:24 ` [PATCH 4/5] drm/i915: pipe_src_w must be even in LVDS dual channel, DVO ganged, and double wide mode ville.syrjala
@ 2013-09-02 18:24 ` ville.syrjala
2013-09-02 18:53 ` [PATCH 0/5] drm/i915: Double wide pipe config Daniel Vetter
5 siblings, 0 replies; 12+ messages in thread
From: ville.syrjala @ 2013-09-02 18:24 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Double wide mode is only available on pipe A, except on GDG where
pipe B is also double wide capable.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index ee777a7..70f9fc2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4150,10 +4150,10 @@ static int intel_crtc_compute_config(struct intel_crtc *crtc,
* Enable pixel doubling when the dot clock
* is > 90% of the (display) core speed.
*
- * XXX: No double-wide on 915GM pipe B. Is that
- * the only reason for the pipe == PIPE_A check?
+ * GDG double wide on either pipe,
+ * otherwise pipe A only.
*/
- if (crtc->pipe == PIPE_A &&
+ if ((crtc->pipe == PIPE_A || IS_I915G(dev)) &&
adjusted_mode->clock > clock_limit * 9 / 10) {
clock_limit *= 2;
pipe_config->double_wide = true;
--
1.8.1.5
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [PATCH 0/5] drm/i915: Double wide pipe config
2013-09-02 18:24 [PATCH 0/5] drm/i915: Double wide pipe config ville.syrjala
` (4 preceding siblings ...)
2013-09-02 18:24 ` [PATCH 5/5] drm/i915: Fix up pipe vs. double wide confusion ville.syrjala
@ 2013-09-02 18:53 ` Daniel Vetter
2013-09-02 19:26 ` Ville Syrjälä
2013-09-02 19:31 ` [PATCH] drm/i915: Convert overlay double wide check over to " ville.syrjala
5 siblings, 2 replies; 12+ messages in thread
From: Daniel Vetter @ 2013-09-02 18:53 UTC (permalink / raw)
To: ville.syrjala; +Cc: intel-gfx
On Mon, Sep 02, 2013 at 09:24:23PM +0300, ville.syrjala@linux.intel.com wrote:
> I was suspecting double wide to be the cause of a bug report, and so
> started digging a bit. Sadly it looks like that bug is caused by something
> else, but I did end up fixing a double wide related bug anyway.
>
> The resulting series is here. It needs to be applied after the pipe config
> fixes seried I just posted since I'm using the new pipe_src_w in this
> series.
There's also the DOUBLE_WIDE check in intel_overlay I've hoped you'd
convert ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH 0/5] drm/i915: Double wide pipe config
2013-09-02 18:53 ` [PATCH 0/5] drm/i915: Double wide pipe config Daniel Vetter
@ 2013-09-02 19:26 ` Ville Syrjälä
2013-09-02 19:31 ` [PATCH] drm/i915: Convert overlay double wide check over to " ville.syrjala
1 sibling, 0 replies; 12+ messages in thread
From: Ville Syrjälä @ 2013-09-02 19:26 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
On Mon, Sep 02, 2013 at 08:53:01PM +0200, Daniel Vetter wrote:
> On Mon, Sep 02, 2013 at 09:24:23PM +0300, ville.syrjala@linux.intel.com wrote:
> > I was suspecting double wide to be the cause of a bug report, and so
> > started digging a bit. Sadly it looks like that bug is caused by something
> > else, but I did end up fixing a double wide related bug anyway.
> >
> > The resulting series is here. It needs to be applied after the pipe config
> > fixes seried I just posted since I'm using the new pipe_src_w in this
> > series.
>
> There's also the DOUBLE_WIDE check in intel_overlay I've hoped you'd
> convert ;-)
Now how did I miss that. I'm going to blame cscope :)
--
Ville Syrjälä
Intel OTC
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH] drm/i915: Convert overlay double wide check over to pipe config
2013-09-02 18:53 ` [PATCH 0/5] drm/i915: Double wide pipe config Daniel Vetter
2013-09-02 19:26 ` Ville Syrjälä
@ 2013-09-02 19:31 ` ville.syrjala
1 sibling, 0 replies; 12+ messages in thread
From: ville.syrjala @ 2013-09-02 19:31 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/intel_overlay.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay.c b/drivers/gpu/drm/i915/intel_overlay.c
index ddfd0ae..8d6d0a1 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -821,14 +821,11 @@ int intel_overlay_switch_off(struct intel_overlay *overlay)
static int check_overlay_possible_on_crtc(struct intel_overlay *overlay,
struct intel_crtc *crtc)
{
- drm_i915_private_t *dev_priv = overlay->dev->dev_private;
-
if (!crtc->active)
return -EINVAL;
/* can't use the overlay with double wide pipe */
- if (INTEL_INFO(overlay->dev)->gen < 4 &&
- (I915_READ(PIPECONF(crtc->pipe)) & (PIPECONF_DOUBLE_WIDE | PIPECONF_ENABLE)) != PIPECONF_ENABLE)
+ if (crtc->config.double_wide)
return -EINVAL;
return 0;
--
1.8.1.5
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 12+ messages in thread