Re: [Intel-gfx] [PATCH 3/3] drm/i915: add basic pipe config dump support

2013-05-28 Thread Daniel Vetter
On Mon, May 27, 2013 at 06:30:17PM -0300, Paulo Zanoni wrote:
> 2013/5/21 Daniel Vetter :
> Besides this, I also booted a kernel with this patch, and on the first
> time we print these things, almost everything is zero, even stuff like
> pipe_bpp, even for enabled pipes. Is this expected?

Lack of hw state readout support for those. One of the goals of this is
that it's easier to see what pipe config the kernel is actually dealing
with, and knowing that we have no clue about the pipe bpp is useuful.

I'll respin the patch with your other comments fixed up.
-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] [PULL] drm-intel-fixes

2013-05-28 Thread Daniel Vetter
On Thu, May 23, 2013 at 02:03:09PM +0200, Daniel Vetter wrote:
> Hi Dave,
> 
> A few fixes, nothing shocking:
> - More Haswell pci ids. Includes a pile of marketing spare ids (which
>   despite the spare moniker show up all over the place).
> - Fix a regression in handling modeset failures, resulting in black
>   screens on 3 pipe setups when we've run out of pch plls (Chris).
> - Fix up the setcrtc semantics to unconditionally enable the outputs.
>   Juding from git digging that has (kinda) always been the case and neatly
>   fixes a few long-standing (i.e. forever) bug reports (Imre).
> - jiffies_timeout + 1 patches from Imre. They partially fix spurious
>   wait_event failures in the interrupt-driven dp aux/i2c code. The other
>   part is a core patch for the wait_event macros going in through -mm. A
>   few patches more than strictly required since Imre is pushing for a
>   general solution in 3.11.
> 
> Cheers, Daniel

Update pull request (same sha1 but with a tag) so that I can pile new
patches on top (there's one I want to give some testing for a few days
first ...).

Cheers, Daniel


The following changes since commit c7788792a5e7b0d5d7f96d0766b4cb6112d47d75:

  Linux 3.10-rc2 (2013-05-20 14:37:38 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-05-28

for you to fetch changes up to 3598706b52cb45ba0a9e8aa99ce5ac59140f2b8b:

  drm/i915: avoid premature DP AUX timeouts (2013-05-22 13:51:26 +0200)


Chris Wilson (1):
  drm/i915: Propagate errors back from fb set-base

Imre Deak (5):
  drm/i915: force full modeset if the connector is in DPMS OFF mode
  drm/i915: add msecs_to_jiffies_timeout to guarantee minimum duration
  drm/i915: use msecs_to_jiffies_timeout instead of open coding the same
  drm/i915: avoid premature timeouts in __wait_seqno()
  drm/i915: avoid premature DP AUX timeouts

Rodrigo Vivi (1):
  drm/i915: Adding more reserved PCI IDs for Haswell.

 drivers/gpu/drm/i915/i915_drv.c  |   46 +++
 drivers/gpu/drm/i915/i915_drv.h  |   15 +++
 drivers/gpu/drm/i915/i915_gem.c  |2 +-
 drivers/gpu/drm/i915/intel_display.c |   49 ++
 drivers/gpu/drm/i915/intel_dp.c  |2 +-
 drivers/gpu/drm/i915/intel_i2c.c |5 ++--
 6 files changed, 87 insertions(+), 32 deletions(-)
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: Fix spurious -EIO/SIGBUS on wedged gpus

2013-05-28 Thread Daniel Vetter
On Fri, May 24, 2013 at 10:03:14PM +0100, Chris Wilson wrote:
> On Fri, May 24, 2013 at 09:29:32PM +0200, Daniel Vetter wrote:
> > Chris Wilson noticed that since
> > 
> > commit 1f83fee08d625f8d0130f9fe5ef7b17c2e022f3c [v3.9]
> > Author: Daniel Vetter 
> > Date:   Thu Nov 15 17:17:22 2012 +0100
> > 
> > drm/i915: clear up wedged transitions
> > 
> > X can again get -EIO when it does not expect it. And even worse score
> > a SIGBUS when accessing gtt mmaps. The established ABI is that we
> > _only_ return an -EIO from execbuf - all other ioctls should just
> > work. And since the reset code moves all bos out of gpu domains and
> > clears out all the last_seqno/ring tracking there really shouldn't be
> > any reason for non-execbuf code to ever touch the hw and see an -EIO.
> > 
> > After some extensive discussions we've noticed that these spurios -EIO
> > are caused by i915_gem_wait_for_error:
> > 
> > http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg20540.html
> > 
> > That is easy to fix by returning 0 instead of -EIO, since grabbing the
> > dev->struct_mutex does not yet mean that we actually want to touch the
> > hw. And so there is no reason at all to fail with -EIO.
> > 
> > But that's not the entire since, since often (at least it's easily
> > googleable) dmesg indicates that the reset fails and we declare the
> > gpu wedged. Then, quite a bit later X wakes up with the "Timed out
> > waiting for the gpu reset to complete" DRM_ERROR message in
> > wait_for_errror and brings down the desktop with an -EIO/SIGBUS.
> > 
> > So clearly we're missing a wakeup somewhere, since the gpu reset just
> > doesn't take 10 seconds to complete. And indeed we're do handle the
> > terminally wedged state wrong.
> > 
> > Fix this all up.
> > 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=63921
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=64073
> > Cc: Chris Wilson 
> > Cc: Daniel Vetter 
> > Cc: Damien Lespiau 
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Daniel Vetter 
> 
> Definite woosh. I feel silly for missing that.
> Reviewed-by: Chris Wilson 

Merged to -fixes, thanks for the review.

> I still think there is a risk for the non-blocking wait to return an
> EIO and papering it over is the simplest approach. The chance that
> anyone will ever hit is minimal, and fortunately an EIO should never
> actually cause an application with adequate error handling to crash, so
> something that we can discuss at leisure.

Yeah, now that we have a less hand-wavey explanation for those -EIO we can
forget about the reset timeout until the next user screams about X dying
untimely ;-)
-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] [i-g-t PATCH] tests/gem_wait_render_timeout: make sure the GPU is idle before exiting

2013-05-28 Thread Daniel Vetter
On Mon, May 27, 2013 at 06:42:42PM +0300, Imre Deak wrote:
> Leaving the GPU running after we exit can mess up timing dependent tests
> we run afterwards.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64270
> 
> Signed-off-by: Imre Deak 

I've flailed around in this area since forever, see gem_quiescent_gpu in
drmtest.c. I wonder whether we shouldn't just install an atexit handler
with this and maybe for full paranoia run it in drm_open_any, too?

One ugly bug with that function is that it doesn't quiescent all rings on
gen6+ though. So I guess that needs fixing.
-Daniel

> ---
>  tests/gem_wait_render_timeout.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/tests/gem_wait_render_timeout.c b/tests/gem_wait_render_timeout.c
> index 14482e3..9ec4e49 100644
> --- a/tests/gem_wait_render_timeout.c
> +++ b/tests/gem_wait_render_timeout.c
> @@ -216,6 +216,11 @@ int main(int argc, char **argv)
>   assert(gem_bo_wait_timeout(fd, dst2->handle, &timeout) == -ETIME);
>   assert(timeout == 0);
>  
> + /* Make sure we exit only after the GPU is idle. Apply some fuzz
> +  * to the timeout since the calibrated iteration count can be
> +  * twice the amount the GPU can execute in a second. */
> + timeout = 5 * ENOUGH_WORK_IN_SECONDS * NSEC_PER_SEC;
> + assert(gem_bo_wait_timeout(fd, dst2->handle, &timeout) == 0);
>  
>   if (do_signals)
>   drmtest_stop_signal_helper();
> -- 
> 1.8.1.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


[Intel-gfx] [PATCH] drm/i915: document why dvo/sdvo/crt need a special dpms function

2013-05-28 Thread Jani Nikula
In the cloned case, changing just one output but keeping the other, the
pipe state won't change and intel_crtc_update_dpms will be a nop, but we
still need to update the dpms state of the output being changed.

Only dvo, sdvo and crt are cloneable, so only those three have special
dpms functions.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_crt.c  |4 +++-
 drivers/gpu/drm/i915/intel_dvo.c  |3 +++
 drivers/gpu/drm/i915/intel_sdvo.c |3 +++
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 5e9f93e..3acec8c 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -149,7 +149,7 @@ static void intel_enable_crt(struct intel_encoder *encoder)
intel_crt_set_dpms(encoder, crt->connector->base.dpms);
 }
 
-
+/* Special dpms function to support cloning between dvo/sdvo/crt. */
 static void intel_crt_dpms(struct drm_connector *connector, int mode)
 {
struct drm_device *dev = connector->dev;
@@ -180,6 +180,8 @@ static void intel_crt_dpms(struct drm_connector *connector, 
int mode)
else
encoder->connectors_active = true;
 
+   /* We call connector dpms manually below in case pipe dpms doesn't
+* change due to cloning. */
if (mode < old_dpms) {
/* From off to on, enable the pipe first. */
intel_crtc_update_dpms(crtc);
diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index 9e80d48..eb2020e 100644
--- a/drivers/gpu/drm/i915/intel_dvo.c
+++ b/drivers/gpu/drm/i915/intel_dvo.c
@@ -180,6 +180,7 @@ static void intel_enable_dvo(struct intel_encoder *encoder)
intel_dvo->dev.dev_ops->dpms(&intel_dvo->dev, true);
 }
 
+/* Special dpms function to support cloning between dvo/sdvo/crt. */
 static void intel_dvo_dpms(struct drm_connector *connector, int mode)
 {
struct intel_dvo *intel_dvo = intel_attached_dvo(connector);
@@ -201,6 +202,8 @@ static void intel_dvo_dpms(struct drm_connector *connector, 
int mode)
return;
}
 
+   /* We call connector dpms manually below in case pipe dpms doesn't
+* change due to cloning. */
if (mode == DRM_MODE_DPMS_ON) {
intel_dvo->base.connectors_active = true;
 
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
b/drivers/gpu/drm/i915/intel_sdvo.c
index 4d4a3f0..7068195 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -1416,6 +1416,7 @@ static void intel_enable_sdvo(struct intel_encoder 
*encoder)
intel_sdvo_set_active_outputs(intel_sdvo, intel_sdvo->attached_output);
 }
 
+/* Special dpms function to support cloning between dvo/sdvo/crt. */
 static void intel_sdvo_dpms(struct drm_connector *connector, int mode)
 {
struct drm_crtc *crtc;
@@ -1437,6 +1438,8 @@ static void intel_sdvo_dpms(struct drm_connector 
*connector, int mode)
return;
}
 
+   /* We set active outputs manually below in case pipe dpms doesn't change
+* due to cloning. */
if (mode != DRM_MODE_DPMS_ON) {
intel_sdvo_set_active_outputs(intel_sdvo, 0);
if (0)
-- 
1.7.9.5

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


Re: [Intel-gfx] [PATCH 0/4] drm/i915: remove is_cpu_edp()

2013-05-28 Thread Daniel Vetter
On Mon, May 27, 2013 at 02:54:33PM -0300, Rodrigo Vivi wrote:
> Yeap, makes sense let them explicit then...
> Thanks for explanation and fell free to go ahead ;)

Thanks for your review, all patches merged to dinq.
-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: Avoid promoting a simulated hang to 'wedged'

2013-05-28 Thread Chris Wilson
It appears that a beneficial side-effect of Mika's more accurate hangman
work is to speed up hang detection and execution. This exposes a bug in
the reset code that then treats repeated simulated hangs as an
indication that the machine is wedged. Jiggle the code around so that we
only do the simulation processing from the hangcheck and avoid confusing
it with a real hang.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65060
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.c |   55 ---
 1 file changed, 23 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a1a936f..af22450 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -839,37 +839,14 @@ static int gen6_do_reset(struct drm_device *dev)
 
 int intel_gpu_reset(struct drm_device *dev)
 {
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   int ret = -ENODEV;
-
switch (INTEL_INFO(dev)->gen) {
case 7:
-   case 6:
-   ret = gen6_do_reset(dev);
-   break;
-   case 5:
-   ret = ironlake_do_reset(dev);
-   break;
-   case 4:
-   ret = i965_do_reset(dev);
-   break;
-   case 2:
-   ret = i8xx_do_reset(dev);
-   break;
-   }
-
-   /* Also reset the gpu hangman. */
-   if (dev_priv->gpu_error.stop_rings) {
-   DRM_INFO("Simulated gpu hang, resetting stop_rings\n");
-   dev_priv->gpu_error.stop_rings = 0;
-   if (ret == -ENODEV) {
-   DRM_ERROR("Reset not implemented, but ignoring "
- "error for simulated gpu hangs\n");
-   ret = 0;
-   }
+   case 6: return gen6_do_reset(dev);
+   case 5: return ironlake_do_reset(dev);
+   case 4: return i965_do_reset(dev);
+   case 2: return i8xx_do_reset(dev);
+   default: return -ENODEV;
}
-
-   return ret;
 }
 
 /**
@@ -890,6 +867,7 @@ int intel_gpu_reset(struct drm_device *dev)
 int i915_reset(struct drm_device *dev)
 {
drm_i915_private_t *dev_priv = dev->dev_private;
+   bool simulated;
int ret;
 
if (!i915_try_reset)
@@ -899,13 +877,26 @@ int i915_reset(struct drm_device *dev)
 
i915_gem_reset(dev);
 
-   ret = -ENODEV;
-   if (get_seconds() - dev_priv->gpu_error.last_reset < 5)
+   simulated = dev_priv->gpu_error.stop_rings != 0;
+
+   if (!simulated && get_seconds() - dev_priv->gpu_error.last_reset < 5) {
DRM_ERROR("GPU hanging too fast, declaring wedged!\n");
-   else
+   ret = -ENODEV;
+   } else {
ret = intel_gpu_reset(dev);
 
-   dev_priv->gpu_error.last_reset = get_seconds();
+   /* Also reset the gpu hangman. */
+   if (simulated) {
+   DRM_INFO("Simulated gpu hang, resetting stop_rings\n");
+   dev_priv->gpu_error.stop_rings = 0;
+   if (ret == -ENODEV) {
+   DRM_ERROR("Reset not implemented, but ignoring "
+ "error for simulated gpu hangs\n");
+   ret = 0;
+   }
+   } else
+   dev_priv->gpu_error.last_reset = get_seconds();
+   }
if (ret) {
DRM_ERROR("Failed to reset chip.\n");
mutex_unlock(&dev->struct_mutex);
-- 
1.7.10.4

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


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

2013-05-28 Thread Daniel Vetter
On Mon, May 27, 2013 at 05:45:53PM -0300, Paulo Zanoni wrote:
> 2013/5/21 Daniel Vetter :
> > +   pipe_config->cpu_transcoder = crtc->pipe;
> > +   tmp = I915_READ(TRANS_DDI_FUNC_CTL(TRANSCODER_EDP));
> > +   if (tmp & TRANS_DDI_FUNC_ENABLE) {
> > +   enum pipe trans_edp_pipe;
> > +   switch (tmp & TRANS_DDI_EDP_INPUT_MASK) {
> > +   default:
> > +   WARN(1, "unknown pipe linked to edp transcoder\n");
> 
> Since there's no "break" we'll assign PIPE_A and then we'll probably
> break pipe A on this case. OTOH this case should never really happen,
> so I'm not sure if we care. So this is an optional bikeshedding.

Generally I prefer to have as little fallback code as possible for such
impossible cases. Avoiding the break makes sure we have at elast a valid
pipe value and so hopefully increase our chances that the following code
survives. No matter what we're pretty much guaranteed to end up with a
black screen.

> Reviewed-by: Paulo Zanoni 

Thanks for the review, first 2 patches are merged to dinq now.
-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: store adjusted dotclock in adjustede_mode->clock

2013-05-28 Thread Daniel Vetter
... not the port clock. This allows us to kill the funny semantics
around pixel_target_clock.

Since the dpll code still needs the real port clock, add a new
port_clock field to the pipe configuration. Handling the default case
for that one is a bit tricky, since encoders might not consistently
overwrite it when retrying the crtc/encoder bw arbitrage step in the
compute config stage. Hence we need to always clear port_clock and
update it again if the encoder hasn't put in something more specific.
This can't be done in one step since the encoder might want to adjust
the mode first.

I was a bit on the fence whether I should subsume the pixel multiplier
handling into the port_clock, too. But then I decided against this
since it's on an abstract level still the dotclock of the adjusted
mode, and only our hw makes it a bit special due to the separate pixel
mulitplier setting (which requires that the dpll runs at the
non-multiplied dotclock).

So after this patch the adjusted_mode accurately describes the mode we
feed into the port, after the panel fitter and pixel multiplier (or
line doubling, if we ever bother with that) have done their job.
Since the fdi link is between the pfit and the pixel multiplier steps
we need to be careful with calculating the fdi link config.

The ironlake cpu edp port is the only encoder interested in the
portclock (outside of compute_config), refactor the flow a bit to
avoid duplicated code. I've broken this part in an early version of
the patch, hence why I've changed the code a bit more than strictly
required.

v2: Fix up ilk cpu pll handling.

v3: Introduce an fdi_dotclock variable in ironlake_fdi_compute_config
to make it clearer that we transmit the adjusted_mode without the
pixel multiplier taken into account. The old code multiplied the the
available link bw with the pixel multiplier, which results in the same
fdi configuration, but is much more confusing.

v3: Rebase on top of Imre's is_cpu_edp removal.

Reviewed-by: Jesse Barnes 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_ddi.c |  3 ++-
 drivers/gpu/drm/i915/intel_display.c | 37 ++
 drivers/gpu/drm/i915/intel_dp.c  | 50 +---
 drivers/gpu/drm/i915/intel_drv.h | 13 +-
 drivers/gpu/drm/i915/intel_hdmi.c|  4 +--
 5 files changed, 48 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 9649df8..486c46b 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -624,7 +624,7 @@ intel_ddi_calculate_wrpll(int clock /* in Hz */,
  clock, *p_out, *n2_out, *r2_out);
 }
 
-bool intel_ddi_pll_mode_set(struct drm_crtc *crtc, int clock)
+bool intel_ddi_pll_mode_set(struct drm_crtc *crtc)
 {
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
struct intel_encoder *intel_encoder = intel_ddi_get_crtc_encoder(crtc);
@@ -634,6 +634,7 @@ bool intel_ddi_pll_mode_set(struct drm_crtc *crtc, int 
clock)
int type = intel_encoder->type;
enum pipe pipe = intel_crtc->pipe;
uint32_t reg, val;
+   int clock = intel_crtc->config.port_clock;
 
/* TODO: reuse PLLs when possible (compare values) */
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 88369db..ab190cb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3945,7 +3945,7 @@ static int ironlake_fdi_compute_config(struct intel_crtc 
*intel_crtc,
 {
struct drm_device *dev = intel_crtc->base.dev;
struct drm_display_mode *adjusted_mode = &pipe_config->adjusted_mode;
-   int target_clock, lane, link_bw;
+   int lane, link_bw, fdi_dotclock;
bool setup_ok, needs_recompute = false;
 
 retry:
@@ -3958,19 +3958,15 @@ retry:
 */
link_bw = intel_fdi_link_freq(dev) * MHz(100)/KHz(1)/10;
 
-   if (pipe_config->pixel_target_clock)
-   target_clock = pipe_config->pixel_target_clock;
-   else
-   target_clock = adjusted_mode->clock;
-
-   lane = ironlake_get_lanes_required(target_clock, link_bw,
+   lane = ironlake_get_lanes_required(adjusted_mode->clock, link_bw,
   pipe_config->pipe_bpp);
 
pipe_config->fdi_lanes = lane;
 
+   fdi_dotclock = adjusted_mode->clock;
if (pipe_config->pixel_multiplier > 1)
-   link_bw *= pipe_config->pixel_multiplier;
-   intel_link_compute_m_n(pipe_config->pipe_bpp, lane, target_clock,
+   fdi_dotclock /= pipe_config->pixel_multiplier;
+   intel_link_compute_m_n(pipe_config->pipe_bpp, lane, fdi_dotclock,
   link_bw, &pipe_config->fdi_m_n);
 
setup_ok = ironlake_check_fdi_lanes(intel_crtc->base.dev,
@@ -4299,8 +4295,6 @@ static void vlv_update_pll(struct intel_crtc *crtc)
 {
struct drm_device *dev = crtc->base.d

Re: [Intel-gfx] [PATCH] drm/i915: document why dvo/sdvo/crt need a special dpms function

2013-05-28 Thread Daniel Vetter
On Tue, May 28, 2013 at 12:35:02PM +0300, Jani Nikula wrote:
> In the cloned case, changing just one output but keeping the other, the
> pipe state won't change and intel_crtc_update_dpms will be a nop, but we
> still need to update the dpms state of the output being changed.
> 
> Only dvo, sdvo and crt are cloneable, so only those three have special
> dpms functions.
> 
> Signed-off-by: Jani Nikula 

Queued for -next since it took me a few minutes of digging myself to
figure this out again (git blame helped though), thanks for the patch.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_crt.c  |4 +++-
>  drivers/gpu/drm/i915/intel_dvo.c  |3 +++
>  drivers/gpu/drm/i915/intel_sdvo.c |3 +++
>  3 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_crt.c 
> b/drivers/gpu/drm/i915/intel_crt.c
> index 5e9f93e..3acec8c 100644
> --- a/drivers/gpu/drm/i915/intel_crt.c
> +++ b/drivers/gpu/drm/i915/intel_crt.c
> @@ -149,7 +149,7 @@ static void intel_enable_crt(struct intel_encoder 
> *encoder)
>   intel_crt_set_dpms(encoder, crt->connector->base.dpms);
>  }
>  
> -
> +/* Special dpms function to support cloning between dvo/sdvo/crt. */
>  static void intel_crt_dpms(struct drm_connector *connector, int mode)
>  {
>   struct drm_device *dev = connector->dev;
> @@ -180,6 +180,8 @@ static void intel_crt_dpms(struct drm_connector 
> *connector, int mode)
>   else
>   encoder->connectors_active = true;
>  
> + /* We call connector dpms manually below in case pipe dpms doesn't
> +  * change due to cloning. */
>   if (mode < old_dpms) {
>   /* From off to on, enable the pipe first. */
>   intel_crtc_update_dpms(crtc);
> diff --git a/drivers/gpu/drm/i915/intel_dvo.c 
> b/drivers/gpu/drm/i915/intel_dvo.c
> index 9e80d48..eb2020e 100644
> --- a/drivers/gpu/drm/i915/intel_dvo.c
> +++ b/drivers/gpu/drm/i915/intel_dvo.c
> @@ -180,6 +180,7 @@ static void intel_enable_dvo(struct intel_encoder 
> *encoder)
>   intel_dvo->dev.dev_ops->dpms(&intel_dvo->dev, true);
>  }
>  
> +/* Special dpms function to support cloning between dvo/sdvo/crt. */
>  static void intel_dvo_dpms(struct drm_connector *connector, int mode)
>  {
>   struct intel_dvo *intel_dvo = intel_attached_dvo(connector);
> @@ -201,6 +202,8 @@ static void intel_dvo_dpms(struct drm_connector 
> *connector, int mode)
>   return;
>   }
>  
> + /* We call connector dpms manually below in case pipe dpms doesn't
> +  * change due to cloning. */
>   if (mode == DRM_MODE_DPMS_ON) {
>   intel_dvo->base.connectors_active = true;
>  
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index 4d4a3f0..7068195 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -1416,6 +1416,7 @@ static void intel_enable_sdvo(struct intel_encoder 
> *encoder)
>   intel_sdvo_set_active_outputs(intel_sdvo, intel_sdvo->attached_output);
>  }
>  
> +/* Special dpms function to support cloning between dvo/sdvo/crt. */
>  static void intel_sdvo_dpms(struct drm_connector *connector, int mode)
>  {
>   struct drm_crtc *crtc;
> @@ -1437,6 +1438,8 @@ static void intel_sdvo_dpms(struct drm_connector 
> *connector, int mode)
>   return;
>   }
>  
> + /* We set active outputs manually below in case pipe dpms doesn't change
> +  * due to cloning. */
>   if (mode != DRM_MODE_DPMS_ON) {
>   intel_sdvo_set_active_outputs(intel_sdvo, 0);
>   if (0)
> -- 
> 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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH -next] drm/i915: fix error return code in init_pipe_control()

2013-05-28 Thread Daniel Vetter
On Tue, May 28, 2013 at 05:51:44PM +0800, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> Fix to return -ENOMEM in the kmap() error handling case
> instead of 0, as done elsewhere in this function.
> 
> Signed-off-by: Wei Yongjun 
Queued for -next, thanks for the patch.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH -next] drm/i915: fix error return code in init_pipe_control()

2013-05-28 Thread Chris Wilson
On Tue, May 28, 2013 at 05:51:44PM +0800, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> Fix to return -ENOMEM in the kmap() error handling case
> instead of 0, as done elsewhere in this function.

kmap() can fail?

It is either translated to page_address() or kmap_high() (on x86),
neither of which may return NULL. However, only kmap_atomic() is
documented as being guaranteed to return a valid value. If we could
have a similar definitive statement for kmap(), we can then cleanup
quite a bit of redundant error handling.
-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


[Intel-gfx] [PATCH] drm/i915: add basic pipe config dump support

2013-05-28 Thread Daniel Vetter
All this pipe config abstraction adds another layer of complexity, so
it's good to have better visibility into what's going on exactly.
Doesn't dump out everything yet, and some bits are a bit duplicated
but this should be a good start.

Note that at boot-up a lot of the fields are 0 even for enabled pipes,
this is simply because our hw state readout code doesn't support
everything.

v2: Remove a few more now redudant debug output lines.

v3: Review from Paulo
- use transcoder_name
- fix up format specifiers
- add missing ':' in debug output

Cc: Paulo Zanoni 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 74 +---
 1 file changed, 44 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 57fd85e..87d8bc9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3528,18 +3528,12 @@ static void i9xx_pfit_enable(struct intel_crtc *crtc)
if (!crtc->config.gmch_pfit.control)
return;
 
-   WARN_ON(I915_READ(PFIT_CONTROL) & PFIT_ENABLE);
-   assert_pipe_disabled(dev_priv, crtc->pipe);
-
/*
-* Enable automatic panel scaling so that non-native modes
-* fill the screen.  The panel fitter should only be
-* adjusted whilst the pipe is disabled, according to
-* register description and PRM.
+* The panel fitter should only be adjusted whilst the pipe is disabled,
+* according to register description and PRM.
 */
-   DRM_DEBUG_KMS("applying panel-fitter: %x, %x\n",
- pipe_config->gmch_pfit.control,
- pipe_config->gmch_pfit.pgm_ratios);
+   WARN_ON(I915_READ(PFIT_CONTROL) & PFIT_ENABLE);
+   assert_pipe_disabled(dev_priv, crtc->pipe);
 
I915_WRITE(PFIT_PGM_RATIOS, pipe_config->gmch_pfit.pgm_ratios);
I915_WRITE(PFIT_CONTROL, pipe_config->gmch_pfit.control);
@@ -4862,9 +4856,6 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
dspcntr |= DISPPLANE_SEL_PIPE_B;
}
 
-   DRM_DEBUG_KMS("Mode for pipe %c:\n", pipe_name(pipe));
-   drm_mode_debug_printmodeline(mode);
-
intel_set_pipe_timings(intel_crtc, mode, adjusted_mode);
 
/* pipesrc and dspsize control the size that is scaled from,
@@ -5666,9 +5657,6 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
/* Ensure that the cursor is valid for the new mode before changing... 
*/
intel_crtc_update_cursor(crtc, true);
 
-   DRM_DEBUG_KMS("Mode for pipe %c:\n", pipe_name(pipe));
-   drm_mode_debug_printmodeline(mode);
-
/* CPU eDP is the only output that doesn't need a PCH PLL of its own. */
if (intel_crtc->config.has_pch_encoder) {
struct intel_pch_pll *pll;
@@ -5879,9 +5867,6 @@ static int haswell_crtc_mode_set(struct drm_crtc *crtc,
/* Ensure that the cursor is valid for the new mode before changing... 
*/
intel_crtc_update_cursor(crtc, true);
 
-   DRM_DEBUG_KMS("Mode for pipe %c:\n", pipe_name(pipe));
-   drm_mode_debug_printmodeline(mode);
-
if (intel_crtc->config.has_dp_encoder)
intel_dp_set_m_n(intel_crtc);
 
@@ -7690,6 +7675,35 @@ pipe_config_set_bpp(struct drm_crtc *crtc,
return bpp;
 }
 
+static void intel_dump_pipe_config(struct intel_crtc *crtc,
+  struct intel_crtc_config *pipe_config,
+  const char *context)
+{
+   DRM_DEBUG_KMS("[CRTC:%d]%s config for pipe %c\n", crtc->base.base.id,
+ context, pipe_name(crtc->pipe));
+
+   DRM_DEBUG_KMS("cpu_transcoder: %c\n", 
transcoder_name(pipe_config->cpu_transcoder));
+   DRM_DEBUG_KMS("pipe bpp: %i, dithering: %i\n",
+ pipe_config->pipe_bpp, pipe_config->dither);
+   DRM_DEBUG_KMS("fdi/pch: %i, lanes: %i, gmch_m: %u, gmch_n: %u, link_m: 
%u, link_n: %u, tu: %u\n",
+ pipe_config->has_pch_encoder,
+ pipe_config->fdi_lanes,
+ pipe_config->fdi_m_n.gmch_m, pipe_config->fdi_m_n.gmch_n,
+ pipe_config->fdi_m_n.link_m, pipe_config->fdi_m_n.link_n,
+ pipe_config->fdi_m_n.tu);
+   DRM_DEBUG_KMS("requested mode:\n");
+   drm_mode_debug_printmodeline(&pipe_config->requested_mode);
+   DRM_DEBUG_KMS("adjusted mode:\n");
+   drm_mode_debug_printmodeline(&pipe_config->adjusted_mode);
+   DRM_DEBUG_KMS("gmch pfit: control: 0x%08x, ratios: 0x%08x, lvds border: 
0x%08x\n",
+ pipe_config->gmch_pfit.control,
+ pipe_config->gmch_pfit.pgm_ratios,
+ pipe_config->gmch_pfit.lvds_border_bits);
+   DRM_DEBUG_KMS("pch pfit: pos: 0x%08x, size: 0x%08x\n",
+ pipe_config->pch_pfit.pos,
+ pipe_config->pch_pfit.size);

Re: [Intel-gfx] [PATCH 08/18] drm/i915: Create a more generic pm handler for hsw+

2013-05-28 Thread Damien Lespiau
On Sat, Apr 27, 2013 at 05:59:19PM -0700, Ben Widawsky wrote:
> HSW has some special requirements for the VEBOX. Splitting out the
> interrupt handler will make the code a bit nicer and less error prone
> when we begin to handle those.
> 
> The slight functional change in this patch (queueing work while holding
> the spinlock) is intentional as it makes a subsequent patch a bit nicer.
> The change should also only effect HSW platforms.
> 
> Based on patches from:
> CC: Haihao Xiang 
> Signed-off-by: Ben Widawsky 

Reviewed-by: Damien Lespiau 

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


Re: [Intel-gfx] [PATCH 09/18] drm/i915: make PM interrupt writes non-destructive

2013-05-28 Thread Damien Lespiau
On Sat, Apr 27, 2013 at 05:59:20PM -0700, Ben Widawsky wrote:
> @@ -2720,12 +2720,12 @@ static void gen6_enable_rps(struct drm_device *dev)
>   gen6_set_rps(dev_priv->dev, (gt_perf_status & 0xff00) >> 8);
>  
>   /* requires MSI enabled */
> - I915_WRITE(GEN6_PMIER, GEN6_PM_DEFERRED_EVENTS);
> + I915_WRITE(GEN6_PMIER, I915_READ(GEN6_PMIER) | GEN6_PM_RPS_EVENTS);
>   spin_lock_irq(&dev_priv->rps.lock);
>   WARN_ON(dev_priv->rps.pm_iir != 0);
> - I915_WRITE(GEN6_PMIMR, 0);
> + I915_WRITE(GEN6_PMIIR, GEN6_PM_RPS_EVENTS);

You're not unmasking the RPS interrupts in PMIMR here now. I'm missing
how they are enabled now.

>   spin_unlock_irq(&dev_priv->rps.lock);
> - /* enable all PM interrupts */
> + /* unmask all PM interrupts */
>   I915_WRITE(GEN6_PMINTRMSK, 0);
>
>   rc6vids = 0;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 10/18] drm/i915: Create an ivybridge_irq_preinstall

2013-05-28 Thread Damien Lespiau
On Sat, Apr 27, 2013 at 05:59:21PM -0700, Ben Widawsky wrote:
> Signed-off-by: Ben Widawsky 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 27 ++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 13ea6c2..21b09cd 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2502,6 +2502,31 @@ static void ironlake_irq_preinstall(struct drm_device 
> *dev)
>   POSTING_READ(SDEIER);
>  }
>  
> +static void ivybridge_irq_preinstall(struct drm_device *dev)
> +{
> + drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev->dev_private;
> +
> + atomic_set(&dev_priv->irq_received, 0);
> +
> + I915_WRITE(HWSTAM, 0xeffe);
> +
> + /* XXX hotplug from PCH */
> +
> + I915_WRITE(DEIMR, 0x);
> + I915_WRITE(DEIER, 0x0);
> + POSTING_READ(DEIER);
> +
> + /* and GT */
> + I915_WRITE(GTIMR, 0x);
> + I915_WRITE(GTIER, 0x0);
> + POSTING_READ(GTIER);

you're missing a:

if (HAS_PCH_NOP(dev))
return;

that you've added in the ironlake path since that patch.

> +
> + /* south display irq */
> + I915_WRITE(SDEIMR, 0x);
> + I915_WRITE(SDEIER, 0x0);
> + POSTING_READ(SDEIER);
> +}

SDEIER is set to 0x now with a big comment explaining why.

>  static void valleyview_irq_preinstall(struct drm_device *dev)
>  {
>   drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev->dev_private;
> @@ -3500,7 +3525,7 @@ void intel_irq_init(struct drm_device *dev)
>   } else if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev)) {
>   /* Share pre & uninstall handlers with ILK/SNB */
>   dev->driver->irq_handler = ivybridge_irq_handler;
> - dev->driver->irq_preinstall = ironlake_irq_preinstall;
> + dev->driver->irq_preinstall = ivybridge_irq_preinstall;
>   dev->driver->irq_postinstall = ivybridge_irq_postinstall;
>   dev->driver->irq_uninstall = ironlake_irq_uninstall;
>   dev->driver->enable_vblank = ivybridge_enable_vblank;
> -- 
> 1.8.2.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 11/18] drm/i915: Add PM regs to pre install

2013-05-28 Thread Damien Lespiau
On Sat, Apr 27, 2013 at 05:59:22PM -0700, Ben Widawsky wrote:
> Signed-off-by: Ben Widawsky 
> ---
>  drivers/gpu/drm/i915/i915_irq.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 21b09cd..4a1b7f5 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2525,6 +2525,11 @@ static void ivybridge_irq_preinstall(struct drm_device 
> *dev)
>   I915_WRITE(SDEIMR, 0x);
>   I915_WRITE(SDEIER, 0x0);
>   POSTING_READ(SDEIER);
> +
> + /* Power management */
> + I915_WRITE(GEN6_PMIMR, 0x);
> + I915_WRITE(GEN6_PMIER, 0x0);
> + POSTING_READ(GEN6_PMIER);
>  }

With the comments on the previous patch, I guess this shoulde be put
before the if (HAS_PCH_NOP) return; block and thus before the DE
init.

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


Re: [Intel-gfx] [PATCH 12/18] drm/i915: Convert irq_refounct to struct

2013-05-28 Thread Damien Lespiau
On Sat, Apr 27, 2013 at 05:59:23PM -0700, Ben Widawsky wrote:
> It's overkill on older gens, but it's useful for newer gens.
> 
> Signed-off-by: Ben Widawsky 

Reviewed-by: Damien Lespiau 

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


[Intel-gfx] [PATCH 1/2] drm/i915: consolidate and tighten encoder cloning checks

2013-05-28 Thread Daniel Vetter
Only lvds/tv did actually check for cloning or not, but many more
places should.

Notices because my ivb tried to enable both cpu edp and vga on the
first crtc - the resulting confusion between has_pch_encoder,
has_dp_encoder but not actually being a pch dp encoder resulting in
hilarity (hitting a BUG).

We _really_ need an igt to random-walk our modeset space more
exhaustively.

I haven't figured out yet why exactly we see this configuration
request from the setcrtc ioctl, but I can reliably reproduce it by
unplugging a bunch of connectors and restarting X.

Strangely restarting X again fixes things ...

Cc: Chris Wilson 
Cc: sta...@vger.kernel.org
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 41 +---
 drivers/gpu/drm/i915/intel_drv.h |  1 -
 drivers/gpu/drm/i915/intel_lvds.c|  3 ---
 drivers/gpu/drm/i915/intel_tv.c  |  3 ---
 4 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 30ffe7f..e9aa2a5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5859,29 +5859,12 @@ static int haswell_crtc_mode_set(struct drm_crtc *crtc,
struct drm_display_mode *mode = &intel_crtc->config.requested_mode;
int pipe = intel_crtc->pipe;
int plane = intel_crtc->plane;
-   int num_connectors = 0;
-   bool is_cpu_edp = false;
-   struct intel_encoder *encoder;
int ret;
 
-   for_each_encoder_on_crtc(dev, crtc, encoder) {
-   switch (encoder->type) {
-   case INTEL_OUTPUT_EDP:
-   if (enc_to_dig_port(&encoder->base)->port == PORT_A)
-   is_cpu_edp = true;
-   break;
-   }
-
-   num_connectors++;
-   }
-
/* We are not sure yet this won't happen. */
WARN(!HAS_PCH_LPT(dev), "Unexpected PCH type %d\n",
 INTEL_PCH_TYPE(dev));
 
-   WARN(num_connectors != 1, "%d connectors attached to pipe %c\n",
-num_connectors, pipe_name(pipe));
-
WARN_ON(I915_READ(PIPECONF(intel_crtc->config.cpu_transcoder)) &
(PIPECONF_ENABLE | I965_PIPECONF_ACTIVE));
 
@@ -7708,6 +7691,25 @@ pipe_config_set_bpp(struct drm_crtc *crtc,
return bpp;
 }
 
+static bool check_encoder_cloning(struct drm_crtc *crtc)
+{
+   int num_encoders = 0;
+   bool uncloneable_encoders = false;
+   struct intel_encoder *encoder;
+
+   list_for_each_entry(encoder, &crtc->dev->mode_config.encoder_list,
+   base.head) {
+   if (&encoder->new_crtc->base != crtc)
+   continue;
+
+   num_encoders++;
+   if (!encoder->cloneable)
+   uncloneable_encoders = true;
+   }
+
+   return !(num_encoders > 1 && uncloneable_encoders);
+}
+
 static struct intel_crtc_config *
 intel_modeset_pipe_config(struct drm_crtc *crtc,
  struct drm_framebuffer *fb,
@@ -7720,6 +7722,11 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
int plane_bpp, ret = -EINVAL;
bool retry = true;
 
+   if (!check_encoder_cloning(crtc)) {
+   DRM_DEBUG_KMS("rejecting invalid cloning configuration\n");
+   return ERR_PTR(-EINVAL);
+   }
+
pipe_config = kzalloc(sizeof(*pipe_config), GFP_KERNEL);
if (!pipe_config)
return ERR_PTR(-ENOMEM);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3db4b14..a844a05 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -627,7 +627,6 @@ extern void intel_crtc_load_lut(struct drm_crtc *crtc);
 extern void intel_crtc_update_dpms(struct drm_crtc *crtc);
 extern void intel_encoder_destroy(struct drm_encoder *encoder);
 extern void intel_encoder_dpms(struct intel_encoder *encoder, int mode);
-extern bool intel_encoder_check_is_cloned(struct intel_encoder *encoder);
 extern void intel_connector_dpms(struct drm_connector *, int mode);
 extern bool intel_connector_get_hw_state(struct intel_connector *connector);
 extern void intel_modeset_check_state(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 6554860..10c3d56 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -264,9 +264,6 @@ static bool intel_lvds_compute_config(struct intel_encoder 
*intel_encoder,
return false;
}
 
-   if (intel_encoder_check_is_cloned(&lvds_encoder->base))
-   return false;
-
if ((I915_READ(lvds_encoder->reg) & LVDS_A3_POWER_MASK) ==
LVDS_A3_POWER_UP)
lvds_bpp = 8*3;
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 7d11a5a..39debd8 100644
--- a/drivers/gpu/drm/i915/intel_t

[Intel-gfx] [PATCH 2/2] drm/i915: drop a few really redundant WARNs in hsw mode_set

2013-05-28 Thread Daniel Vetter
- Correct cpu->pch display matching is already check when we detect
  the PCH type at driver load.
- Plane/pipe state is already checked both when a) enabling, b)
  disabling and in c) the modeset state checker. No need to go
  overboard and also check it in in between a) and b).

Cc: Paulo Zanoni 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e9aa2a5..1216fdf 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5861,15 +5861,6 @@ static int haswell_crtc_mode_set(struct drm_crtc *crtc,
int plane = intel_crtc->plane;
int ret;
 
-   /* We are not sure yet this won't happen. */
-   WARN(!HAS_PCH_LPT(dev), "Unexpected PCH type %d\n",
-INTEL_PCH_TYPE(dev));
-
-   WARN_ON(I915_READ(PIPECONF(intel_crtc->config.cpu_transcoder)) &
-   (PIPECONF_ENABLE | I965_PIPECONF_ACTIVE));
-
-   WARN_ON(I915_READ(DSPCNTR(plane)) & DISPLAY_PLANE_ENABLE);
-
if (!intel_ddi_pll_mode_set(crtc))
return -EINVAL;
 
-- 
1.7.11.7

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


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

2013-05-28 Thread Damien Lespiau
On Sat, Apr 27, 2013 at 05:59:24PM -0700, Ben Widawsky wrote:
> The motivation here is we're going to add some new interrupt definitions
> and handling outside of the GT interrupts which is all we've managed so
> far (with some RPS exceptions). By consolidating the names in the future
> we can make thing a bit cleaner as we don't need to define register
> names twice, and we can leverage pretty decent overlap in HW registers
> since ILK.
> 
> To explain briefly what is in the comments: there are two sets of
> interrupt masking/enabling registers. At least so far, the definitions
> of the two sets overlap. The old code setup distinct names for
> interrupts in each set, ie. one for global, and one for ring. This made
> things confusing when using the wrong defines in the wrong places.
> 
> rebase: Modified VLV bits
> 
> Signed-off-by: Ben Widawsky 


With or without the naming biskeshed below:

Reviewed-by: Damien Lespiau 

-- 
Damien

> ---
>  drivers/gpu/drm/i915/i915_irq.c |  58 +-
>  drivers/gpu/drm/i915/i915_reg.h | 101 
> ++--
>  drivers/gpu/drm/i915/intel_ringbuffer.c |  17 +++---
>  3 files changed, 79 insertions(+), 97 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 4a1b7f5..06e254a 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -781,7 +781,7 @@ static void ivybridge_parity_work(struct work_struct 
> *work)
>   I915_WRITE(GEN7_MISCCPCTL, misccpctl);
>  
>   spin_lock_irqsave(&dev_priv->irq_lock, flags);
> - dev_priv->gt_irq_mask &= ~GT_GEN7_L3_PARITY_ERROR_INTERRUPT;
> + dev_priv->gt_irq_mask &= ~GT_RENDER_L3_PARITY_ERROR_INTERRUPT;
>   I915_WRITE(GTIMR, dev_priv->gt_irq_mask);
>   spin_unlock_irqrestore(&dev_priv->irq_lock, flags);
>  
> @@ -813,7 +813,7 @@ static void ivybridge_handle_parity_error(struct 
> drm_device *dev)
>   return;
>  
>   spin_lock_irqsave(&dev_priv->irq_lock, flags);
> - dev_priv->gt_irq_mask |= GT_GEN7_L3_PARITY_ERROR_INTERRUPT;
> + dev_priv->gt_irq_mask |= GT_RENDER_L3_PARITY_ERROR_INTERRUPT;
>   I915_WRITE(GTIMR, dev_priv->gt_irq_mask);
>   spin_unlock_irqrestore(&dev_priv->irq_lock, flags);
>  
> @@ -825,22 +825,21 @@ static void snb_gt_irq_handler(struct drm_device *dev,
>  u32 gt_iir)
>  {
>  
> - if (gt_iir & (GEN6_RENDER_USER_INTERRUPT |
> -   GEN6_RENDER_PIPE_CONTROL_NOTIFY_INTERRUPT))
> + if (gt_iir & (GT_RENDER_USER_INTERRUPT | 
> GT_RENDER_PIPECTL_NOTIFY_INTERRUPT))
>   notify_ring(dev, &dev_priv->ring[RCS]);
> - if (gt_iir & GEN6_BSD_USER_INTERRUPT)
> + if (gt_iir & GT_BSD_USER_INTERRUPT)
>   notify_ring(dev, &dev_priv->ring[VCS]);
> - if (gt_iir & GEN6_BLITTER_USER_INTERRUPT)
> + if (gt_iir & GT_BLT_USER_INTERRUPT)
>   notify_ring(dev, &dev_priv->ring[BCS]);
>  
> - if (gt_iir & (GT_GEN6_BLT_CS_ERROR_INTERRUPT |
> -   GT_GEN6_BSD_CS_ERROR_INTERRUPT |
> -   GT_RENDER_CS_ERROR_INTERRUPT)) {
> + if (gt_iir & (GT_BLT_CS_ERROR_INTERRUPT |
> +   GT_BSD_CS_ERROR_INTERRUPT |
> +   GT_RENDER_MASTER_ERROR_INTERRUPT)) {

If we ware in the naming domain here, not sure why the CS master error
for render would have a different name than the others,
GT_RENDER_CS_ERROR_INTERRUPT looked good to me.

>   DRM_ERROR("GT error interrupt 0x%08x\n", gt_iir);
>   i915_handle_error(dev, false);
>   }
>  
> - if (gt_iir & GT_GEN7_L3_PARITY_ERROR_INTERRUPT)
> + if (gt_iir & GT_RENDER_L3_PARITY_ERROR_INTERRUPT)
>   ivybridge_handle_parity_error(dev);
>  }
>  
> @@ -1284,9 +1283,9 @@ static void ilk_gt_irq_handler(struct drm_device *dev,
>  struct drm_i915_private *dev_priv,
>  u32 gt_iir)
>  {
> - if (gt_iir & (GT_USER_INTERRUPT | GT_PIPE_NOTIFY))
> + if (gt_iir & (GT_RENDER_USER_INTERRUPT | 
> GT_RENDER_PIPECTL_NOTIFY_INTERRUPT))
>   notify_ring(dev, &dev_priv->ring[RCS]);
> - if (gt_iir & GT_BSD_USER_INTERRUPT)
> + if (gt_iir & ILK_BSD_USER_INTERRUPT)
>   notify_ring(dev, &dev_priv->ring[VCS]);
>  }
>  
> @@ -2629,7 +2628,7 @@ static int ironlake_irq_postinstall(struct drm_device 
> *dev)
>  DE_PLANEA_FLIP_DONE | DE_PLANEB_FLIP_DONE |
>  DE_AUX_CHANNEL_A | DE_PIPEB_FIFO_UNDERRUN |
>  DE_PIPEA_FIFO_UNDERRUN | DE_POISON;
> - u32 render_irqs;
> + u32 gt_irqs;
>  
>   dev_priv->irq_mask = ~display_mask;
>  
> @@ -2644,17 +2643,14 @@ static int ironlake_irq_postinstall(struct drm_device 
> *dev)
>   I915_WRITE(GTIIR, I915_READ(GTIIR));
>   I915_WRITE(GTIMR, dev_priv->gt_irq_mask);
>  
> + gt_irqs = GT_RENDER_USER_INTERRUPT;
> +
>   if (IS_GEN6(dev))
> - 

Re: [Intel-gfx] [PATCH] drm/i915: add basic pipe config dump support

2013-05-28 Thread Paulo Zanoni
2013/5/28 Daniel Vetter :
> All this pipe config abstraction adds another layer of complexity, so
> it's good to have better visibility into what's going on exactly.
> Doesn't dump out everything yet, and some bits are a bit duplicated
> but this should be a good start.
>
> Note that at boot-up a lot of the fields are 0 even for enabled pipes,
> this is simply because our hw state readout code doesn't support
> everything.
>
> v2: Remove a few more now redudant debug output lines.
>
> v3: Review from Paulo
> - use transcoder_name
> - fix up format specifiers
> - add missing ':' in debug output
>
> Cc: Paulo Zanoni 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Paulo Zanoni 

> ---
>  drivers/gpu/drm/i915/intel_display.c | 74 
> +---
>  1 file changed, 44 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 57fd85e..87d8bc9 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3528,18 +3528,12 @@ static void i9xx_pfit_enable(struct intel_crtc *crtc)
> if (!crtc->config.gmch_pfit.control)
> return;
>
> -   WARN_ON(I915_READ(PFIT_CONTROL) & PFIT_ENABLE);
> -   assert_pipe_disabled(dev_priv, crtc->pipe);
> -
> /*
> -* Enable automatic panel scaling so that non-native modes
> -* fill the screen.  The panel fitter should only be
> -* adjusted whilst the pipe is disabled, according to
> -* register description and PRM.
> +* The panel fitter should only be adjusted whilst the pipe is 
> disabled,
> +* according to register description and PRM.
>  */
> -   DRM_DEBUG_KMS("applying panel-fitter: %x, %x\n",
> - pipe_config->gmch_pfit.control,
> - pipe_config->gmch_pfit.pgm_ratios);
> +   WARN_ON(I915_READ(PFIT_CONTROL) & PFIT_ENABLE);
> +   assert_pipe_disabled(dev_priv, crtc->pipe);
>
> I915_WRITE(PFIT_PGM_RATIOS, pipe_config->gmch_pfit.pgm_ratios);
> I915_WRITE(PFIT_CONTROL, pipe_config->gmch_pfit.control);
> @@ -4862,9 +4856,6 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
> dspcntr |= DISPPLANE_SEL_PIPE_B;
> }
>
> -   DRM_DEBUG_KMS("Mode for pipe %c:\n", pipe_name(pipe));
> -   drm_mode_debug_printmodeline(mode);
> -
> intel_set_pipe_timings(intel_crtc, mode, adjusted_mode);
>
> /* pipesrc and dspsize control the size that is scaled from,
> @@ -5666,9 +5657,6 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
> /* Ensure that the cursor is valid for the new mode before 
> changing... */
> intel_crtc_update_cursor(crtc, true);
>
> -   DRM_DEBUG_KMS("Mode for pipe %c:\n", pipe_name(pipe));
> -   drm_mode_debug_printmodeline(mode);
> -
> /* CPU eDP is the only output that doesn't need a PCH PLL of its own. 
> */
> if (intel_crtc->config.has_pch_encoder) {
> struct intel_pch_pll *pll;
> @@ -5879,9 +5867,6 @@ static int haswell_crtc_mode_set(struct drm_crtc *crtc,
> /* Ensure that the cursor is valid for the new mode before 
> changing... */
> intel_crtc_update_cursor(crtc, true);
>
> -   DRM_DEBUG_KMS("Mode for pipe %c:\n", pipe_name(pipe));
> -   drm_mode_debug_printmodeline(mode);
> -
> if (intel_crtc->config.has_dp_encoder)
> intel_dp_set_m_n(intel_crtc);
>
> @@ -7690,6 +7675,35 @@ pipe_config_set_bpp(struct drm_crtc *crtc,
> return bpp;
>  }
>
> +static void intel_dump_pipe_config(struct intel_crtc *crtc,
> +  struct intel_crtc_config *pipe_config,
> +  const char *context)
> +{
> +   DRM_DEBUG_KMS("[CRTC:%d]%s config for pipe %c\n", crtc->base.base.id,
> + context, pipe_name(crtc->pipe));
> +
> +   DRM_DEBUG_KMS("cpu_transcoder: %c\n", 
> transcoder_name(pipe_config->cpu_transcoder));
> +   DRM_DEBUG_KMS("pipe bpp: %i, dithering: %i\n",
> + pipe_config->pipe_bpp, pipe_config->dither);
> +   DRM_DEBUG_KMS("fdi/pch: %i, lanes: %i, gmch_m: %u, gmch_n: %u, 
> link_m: %u, link_n: %u, tu: %u\n",
> + pipe_config->has_pch_encoder,
> + pipe_config->fdi_lanes,
> + pipe_config->fdi_m_n.gmch_m, 
> pipe_config->fdi_m_n.gmch_n,
> + pipe_config->fdi_m_n.link_m, 
> pipe_config->fdi_m_n.link_n,
> + pipe_config->fdi_m_n.tu);
> +   DRM_DEBUG_KMS("requested mode:\n");
> +   drm_mode_debug_printmodeline(&pipe_config->requested_mode);
> +   DRM_DEBUG_KMS("adjusted mode:\n");
> +   drm_mode_debug_printmodeline(&pipe_config->adjusted_mode);
> +   DRM_DEBUG_KMS("gmch pfit: control: 0x%08x, ratios: 0x%08x, lvds 
> border: 0x%08x\n",
> + pipe_config->gmch_pfit.control,
> + 

[Intel-gfx] [i-g-t PATCH v2 1/2] lib: make sure all rings are idle in gpu_quiescent_gpu()

2013-05-28 Thread Imre Deak
Signed-off-by: Imre Deak 
---
 lib/drmtest.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/lib/drmtest.c b/lib/drmtest.c
index 16f5be1..2d37fb6 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -109,6 +109,7 @@ int gem_available_fences(int fd)
 }
 
 
+#define LOCAL_I915_EXEC_VEBOX  (4 << 0)
 /* Ensure the gpu is idle by launching a nop execbuf and stalling for it. */
 void gem_quiescent_gpu(int fd)
 {
@@ -143,6 +144,21 @@ void gem_quiescent_gpu(int fd)
 
do_ioctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2, &execbuf);
 
+   if (gem_has_blt(fd)) {
+   execbuf.flags = I915_EXEC_BLT;
+   do_ioctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2, &execbuf);
+   }
+
+   if (gem_has_bsd(fd)) {
+   execbuf.flags = I915_EXEC_BSD;
+   do_ioctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2, &execbuf);
+   }
+
+   if (gem_has_vebox(fd)) {
+   execbuf.flags = LOCAL_I915_EXEC_VEBOX;
+   do_ioctl(fd, DRM_IOCTL_I915_GEM_EXECBUFFER2, &execbuf);
+   }
+
gem_sync(fd, handle);
 }
 
-- 
1.8.1.2

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


[Intel-gfx] [i-g-t PATCH v2 2/2] tests/lib: make sure the GPU is idle at test start and exit

2013-05-28 Thread Imre Deak
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64270

v2:
- Make sure also that the GPU is idle at start and error exit of any
  test using drm_open_any(). (Daniel)

Signed-off-by: Imre Deak 
---
 lib/drmtest.c | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/lib/drmtest.c b/lib/drmtest.c
index 2d37fb6..198104d 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -228,7 +228,7 @@ int drm_get_card(int master)
 }
 
 /** Open the first DRM device we can find, searching up to 16 device nodes */
-int drm_open_any(void)
+static int __drm_open_any(void)
 {
char *name;
int ret, fd;
@@ -248,6 +248,29 @@ int drm_open_any(void)
return fd;
 }
 
+static void quiescent_gpu_at_exit(int sig)
+{
+   int fd;
+
+   fd = __drm_open_any();
+   if (fd >= 0)
+   close(fd);
+}
+
+int drm_open_any(void)
+{
+   static int open_count;
+   int fd = __drm_open_any();
+
+   if (fd < 0 || __sync_fetch_and_add(&open_count, 1))
+   return fd;
+
+   gem_quiescent_gpu(fd);
+   drmtest_install_exit_handler(quiescent_gpu_at_exit);
+
+   return fd;
+}
+
 /**
  * Open the first DRM device we can find where we end up being the master.
  */
-- 
1.8.1.2

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


[Intel-gfx] [PATCH] drm/i915: drop a few really redundant WARNs in hsw mode_set

2013-05-28 Thread Daniel Vetter
- Correct cpu->pch display matching is already check when we detect
  the PCH type at driver load.
- Plane/pipe state is already checked both when a) enabling, b)
  disabling and in c) the modeset state checker. No need to go
  overboard and also check it in in between a) and b).

Cc: Paulo Zanoni 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 5baf14c..a40c186 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5861,15 +5861,6 @@ static int haswell_crtc_mode_set(struct drm_crtc *crtc,
int plane = intel_crtc->plane;
int ret;
 
-   /* We are not sure yet this won't happen. */
-   WARN(!HAS_PCH_LPT(dev), "Unexpected PCH type %d\n",
-INTEL_PCH_TYPE(dev));
-
-   WARN_ON(I915_READ(PIPECONF(intel_crtc->config.cpu_transcoder)) &
-   (PIPECONF_ENABLE | I965_PIPECONF_ACTIVE));
-
-   WARN_ON(I915_READ(DSPCNTR(plane)) & DISPLAY_PLANE_ENABLE);
-
if (!intel_ddi_pll_mode_set(crtc))
return -EINVAL;
 
-- 
1.7.11.7

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


Re: [Intel-gfx] [PATCH] drm/i915: add basic pipe config dump support

2013-05-28 Thread Daniel Vetter
On Tue, May 28, 2013 at 11:17:34AM -0300, Paulo Zanoni wrote:
> 2013/5/28 Daniel Vetter :
> > All this pipe config abstraction adds another layer of complexity, so
> > it's good to have better visibility into what's going on exactly.
> > Doesn't dump out everything yet, and some bits are a bit duplicated
> > but this should be a good start.
> >
> > Note that at boot-up a lot of the fields are 0 even for enabled pipes,
> > this is simply because our hw state readout code doesn't support
> > everything.
> >
> > v2: Remove a few more now redudant debug output lines.
> >
> > v3: Review from Paulo
> > - use transcoder_name
> > - fix up format specifiers
> > - add missing ':' in debug output
> >
> > Cc: Paulo Zanoni 
> > Signed-off-by: Daniel Vetter 
> 
> Reviewed-by: Paulo Zanoni 

Queued for -next, thanks for the review.
-Daniel
> 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 74 
> > +---
> >  1 file changed, 44 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 57fd85e..87d8bc9 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -3528,18 +3528,12 @@ static void i9xx_pfit_enable(struct intel_crtc 
> > *crtc)
> > if (!crtc->config.gmch_pfit.control)
> > return;
> >
> > -   WARN_ON(I915_READ(PFIT_CONTROL) & PFIT_ENABLE);
> > -   assert_pipe_disabled(dev_priv, crtc->pipe);
> > -
> > /*
> > -* Enable automatic panel scaling so that non-native modes
> > -* fill the screen.  The panel fitter should only be
> > -* adjusted whilst the pipe is disabled, according to
> > -* register description and PRM.
> > +* The panel fitter should only be adjusted whilst the pipe is 
> > disabled,
> > +* according to register description and PRM.
> >  */
> > -   DRM_DEBUG_KMS("applying panel-fitter: %x, %x\n",
> > - pipe_config->gmch_pfit.control,
> > - pipe_config->gmch_pfit.pgm_ratios);
> > +   WARN_ON(I915_READ(PFIT_CONTROL) & PFIT_ENABLE);
> > +   assert_pipe_disabled(dev_priv, crtc->pipe);
> >
> > I915_WRITE(PFIT_PGM_RATIOS, pipe_config->gmch_pfit.pgm_ratios);
> > I915_WRITE(PFIT_CONTROL, pipe_config->gmch_pfit.control);
> > @@ -4862,9 +4856,6 @@ static int i9xx_crtc_mode_set(struct drm_crtc *crtc,
> > dspcntr |= DISPPLANE_SEL_PIPE_B;
> > }
> >
> > -   DRM_DEBUG_KMS("Mode for pipe %c:\n", pipe_name(pipe));
> > -   drm_mode_debug_printmodeline(mode);
> > -
> > intel_set_pipe_timings(intel_crtc, mode, adjusted_mode);
> >
> > /* pipesrc and dspsize control the size that is scaled from,
> > @@ -5666,9 +5657,6 @@ static int ironlake_crtc_mode_set(struct drm_crtc 
> > *crtc,
> > /* Ensure that the cursor is valid for the new mode before 
> > changing... */
> > intel_crtc_update_cursor(crtc, true);
> >
> > -   DRM_DEBUG_KMS("Mode for pipe %c:\n", pipe_name(pipe));
> > -   drm_mode_debug_printmodeline(mode);
> > -
> > /* CPU eDP is the only output that doesn't need a PCH PLL of its 
> > own. */
> > if (intel_crtc->config.has_pch_encoder) {
> > struct intel_pch_pll *pll;
> > @@ -5879,9 +5867,6 @@ static int haswell_crtc_mode_set(struct drm_crtc 
> > *crtc,
> > /* Ensure that the cursor is valid for the new mode before 
> > changing... */
> > intel_crtc_update_cursor(crtc, true);
> >
> > -   DRM_DEBUG_KMS("Mode for pipe %c:\n", pipe_name(pipe));
> > -   drm_mode_debug_printmodeline(mode);
> > -
> > if (intel_crtc->config.has_dp_encoder)
> > intel_dp_set_m_n(intel_crtc);
> >
> > @@ -7690,6 +7675,35 @@ pipe_config_set_bpp(struct drm_crtc *crtc,
> > return bpp;
> >  }
> >
> > +static void intel_dump_pipe_config(struct intel_crtc *crtc,
> > +  struct intel_crtc_config *pipe_config,
> > +  const char *context)
> > +{
> > +   DRM_DEBUG_KMS("[CRTC:%d]%s config for pipe %c\n", 
> > crtc->base.base.id,
> > + context, pipe_name(crtc->pipe));
> > +
> > +   DRM_DEBUG_KMS("cpu_transcoder: %c\n", 
> > transcoder_name(pipe_config->cpu_transcoder));
> > +   DRM_DEBUG_KMS("pipe bpp: %i, dithering: %i\n",
> > + pipe_config->pipe_bpp, pipe_config->dither);
> > +   DRM_DEBUG_KMS("fdi/pch: %i, lanes: %i, gmch_m: %u, gmch_n: %u, 
> > link_m: %u, link_n: %u, tu: %u\n",
> > + pipe_config->has_pch_encoder,
> > + pipe_config->fdi_lanes,
> > + pipe_config->fdi_m_n.gmch_m, 
> > pipe_config->fdi_m_n.gmch_n,
> > + pipe_config->fdi_m_n.link_m, 
> > pipe_config->fdi_m_n.link_n,
> > + pipe_config->fdi_m_n.tu);
> > +   DRM_DEBUG_KMS("requested

Re: [Intel-gfx] [PATCH] drm/i915: drop a few really redundant WARNs in hsw mode_set

2013-05-28 Thread Paulo Zanoni
2013/5/28 Daniel Vetter :
> - Correct cpu->pch display matching is already check when we detect
>   the PCH type at driver load.
> - Plane/pipe state is already checked both when a) enabling, b)
>   disabling and in c) the modeset state checker. No need to go
>   overboard and also check it in in between a) and b).

Reviewed-by: Paulo Zanoni 


>
> Cc: Paulo Zanoni 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 9 -
>  1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 5baf14c..a40c186 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5861,15 +5861,6 @@ static int haswell_crtc_mode_set(struct drm_crtc *crtc,
> int plane = intel_crtc->plane;
> int ret;
>
> -   /* We are not sure yet this won't happen. */
> -   WARN(!HAS_PCH_LPT(dev), "Unexpected PCH type %d\n",
> -INTEL_PCH_TYPE(dev));
> -
> -   WARN_ON(I915_READ(PIPECONF(intel_crtc->config.cpu_transcoder)) &
> -   (PIPECONF_ENABLE | I965_PIPECONF_ACTIVE));
> -
> -   WARN_ON(I915_READ(DSPCNTR(plane)) & DISPLAY_PLANE_ENABLE);
> -
> if (!intel_ddi_pll_mode_set(crtc))
> return -EINVAL;
>
> --
> 1.7.11.7
>



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


[Intel-gfx] [i-g-t PATCH v3 2/2] tests/lib: make sure the GPU is idle at test start and exit

2013-05-28 Thread Imre Deak
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64270

v2:
- Make sure also that the GPU is idle at start and error exit of any
  test using drm_open_any(). (Daniel)
v3:
- actually call gem_quiescent_gpu() at exit

Signed-off-by: Imre Deak 
---
 lib/drmtest.c | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/lib/drmtest.c b/lib/drmtest.c
index 2d37fb6..d17dbb0 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -228,7 +228,7 @@ int drm_get_card(int master)
 }
 
 /** Open the first DRM device we can find, searching up to 16 device nodes */
-int drm_open_any(void)
+static int __drm_open_any(void)
 {
char *name;
int ret, fd;
@@ -248,6 +248,31 @@ int drm_open_any(void)
return fd;
 }
 
+static void quiescent_gpu_at_exit(int sig)
+{
+   int fd;
+
+   fd = __drm_open_any();
+   if (fd >= 0) {
+   gem_quiescent_gpu(fd);
+   close(fd);
+   }
+}
+
+int drm_open_any(void)
+{
+   static int open_count;
+   int fd = __drm_open_any();
+
+   if (fd < 0 || __sync_fetch_and_add(&open_count, 1))
+   return fd;
+
+   gem_quiescent_gpu(fd);
+   drmtest_install_exit_handler(quiescent_gpu_at_exit);
+
+   return fd;
+}
+
 /**
  * Open the first DRM device we can find where we end up being the master.
  */
-- 
1.8.1.2

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


Re: [Intel-gfx] [PATCH 14/18] drm/i915: vebox interrupt get/put

2013-05-28 Thread Damien Lespiau
On Sat, Apr 27, 2013 at 05:59:25PM -0700, Ben Widawsky wrote:
> v2: Use the correct lock to protect PM interrupt regs, this was
> accidentally lost from earlier (Haihao)
> Fix return types (Ben)
> 
> CC: Xiang, Haihao 
> Signed-off-by: Ben Widawsky 
> ---

Reviewed-by: Damien Lespiau 

-- 
Damien

>  drivers/gpu/drm/i915/intel_ringbuffer.c | 46 
> +++--
>  drivers/gpu/drm/i915/intel_ringbuffer.h |  5 ++--
>  2 files changed, 47 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index ccfa1f9..93a3128 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -1005,6 +1005,48 @@ gen6_ring_put_irq(struct intel_ring_buffer *ring)
>   gen6_gt_force_wake_put(dev_priv);
>  }
>  
> +static bool
> +hsw_vebox_get_irq(struct intel_ring_buffer *ring)
> +{
> + struct drm_device *dev = ring->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + unsigned long flags;
> +
> + if (!dev->irq_enabled)
> + return false;
> +
> + spin_lock_irqsave(&dev_priv->rps.lock, flags);
> + if (ring->irq_refcount.pm++ == 0) {
> + u32 pm_imr = I915_READ(GEN6_PMIMR);
> + I915_WRITE_IMR(ring, ~ring->irq_enable_mask);
> + I915_WRITE(GEN6_PMIMR, pm_imr & ~ring->irq_enable_mask);
> + POSTING_READ(GEN6_PMIMR);
> + }
> + spin_unlock_irqrestore(&dev_priv->rps.lock, flags);
> +
> + return true;
> +}
> +
> +static void
> +hsw_vebox_put_irq(struct intel_ring_buffer *ring)
> +{
> + struct drm_device *dev = ring->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + unsigned long flags;
> +
> + if (!dev->irq_enabled)
> + return;
> +
> + spin_lock_irqsave(&dev_priv->rps.lock, flags);
> + if (--ring->irq_refcount.pm == 0) {
> + u32 pm_imr = I915_READ(GEN6_PMIMR);
> + I915_WRITE_IMR(ring, ~0);
> + I915_WRITE(GEN6_PMIMR, pm_imr | ring->irq_enable_mask);
> + POSTING_READ(GEN6_PMIMR);
> + }
> + spin_unlock_irqrestore(&dev_priv->rps.lock, flags);
> +}
> +
>  static int
>  i965_dispatch_execbuffer(struct intel_ring_buffer *ring,
>u32 offset, u32 length,
> @@ -1913,8 +1955,8 @@ int intel_init_vebox_ring_buffer(struct drm_device *dev)
>   ring->get_seqno = gen6_ring_get_seqno;
>   ring->set_seqno = ring_set_seqno;
>   ring->irq_enable_mask = 0;
> - ring->irq_get = NULL;
> - ring->irq_put = NULL;
> + ring->irq_get = hsw_vebox_get_irq;
> + ring->irq_put = hsw_vebox_put_irq;
>   ring->dispatch_execbuffer = gen6_ring_dispatch_execbuffer;
>   ring->sync_to = gen6_ring_sync;
>   ring->semaphore_register[RCS] = MI_SEMAPHORE_SYNC_VER;
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> b/drivers/gpu/drm/i915/intel_ringbuffer.h
> index 24b4413..d040dae 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> @@ -69,8 +69,9 @@ struct  intel_ring_buffer {
>   u32 last_retired_head;
>  
>   struct {
> - u32 gt;
> - } irq_refcount; /* protected by dev_priv->irq_lock */
> + u32 gt; /*  protected by dev_priv->irq_lock */
> + u32 pm; /*  protected by dev_priv->rps.lock (sucks) */
> + } irq_refcount;
>   u32 irq_enable_mask;/* bitmask to enable ring 
> interrupt */
>   u32 trace_irq_seqno;
>   u32 sync_seqno[I915_NUM_RINGS-1];
> -- 
> 1.8.2.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 15/18] drm/i915: Enable vebox interrupts

2013-05-28 Thread Damien Lespiau
On Sat, Apr 27, 2013 at 05:59:26PM -0700, Ben Widawsky wrote:
> Similar to a patch originally written by:
> 
> v2: Reversed the meanings of masked and enabled (Haihao)
> Made non-destructive writes in case enable/disabler rps runs first
> (Haihao)
> 
> CC: Xiang, Haihao 
> Signed-off-by: Ben Widawsky 

With or without the bikeshed below:

Reviewed-by: Damien Lespiau 

-- 
Damien

> ---
>  drivers/gpu/drm/i915/i915_irq.c | 26 --
>  drivers/gpu/drm/i915/i915_reg.h |  3 +++
>  drivers/gpu/drm/i915/intel_ringbuffer.c |  2 +-
>  3 files changed, 28 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 06e254a..ae2ee9d 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -944,8 +944,15 @@ static void hsw_pm_irq_handler(struct drm_i915_private 
> *dev_priv,
>   }
>   spin_unlock_irqrestore(&dev_priv->rps.lock, flags);
>  
> - if (pm_iir & ~GEN6_PM_RPS_EVENTS)
> - DRM_ERROR("Unexpected PM interrupted\n");
> + if (pm_iir & ~GEN6_PM_RPS_EVENTS) {
> + if (pm_iir & PM_VEBOX_USER_INTERRUPT)
> + notify_ring(dev_priv->dev, &dev_priv->ring[VECS]);
> +
> + if (pm_iir & PM_VEBOX_CS_ERROR_INTERRUPT) {
> + DRM_ERROR("PM error interrupt 0x%08x\n", pm_iir);

Maybe we could even be a bit more explicit here, saying it's a command
stream/parser error.

> + i915_handle_error(dev_priv->dev, false);
> + }
> + }
>  }
>  
>  static irqreturn_t valleyview_irq_handler(int irq, void *arg)
> @@ -2701,6 +2708,21 @@ static int ivybridge_irq_postinstall(struct drm_device 
> *dev)
>   I915_WRITE(GTIER, gt_irqs);
>   POSTING_READ(GTIER);
>  
> + I915_WRITE(GEN6_PMIIR, I915_READ(GEN6_PMIIR));
> + if (HAS_VEBOX(dev)) {
> + u32 pm_irqs, pmier, pmimr;
> + pm_irqs = PM_VEBOX_USER_INTERRUPT | PM_VEBOX_CS_ERROR_INTERRUPT;
> +
> + /* Our enable/disable rps functions may touch these registers so
> +  * make sure to set a known state for only the non-RPS bits. */
> + pmier = (I915_READ(GEN6_PMIER) & GEN6_PM_RPS_EVENTS) | pm_irqs;
> + pmimr = (I915_READ(GEN6_PMIMR) | ~GEN6_PM_RPS_EVENTS) & 
> ~pm_irqs;
> + I915_WRITE(GEN6_PMIMR, pmimr);
> + I915_WRITE(GEN6_PMIER, pmier);
> + }
> +
> + POSTING_READ(GEN6_PMIER);
> +
>   ibx_irq_postinstall(dev);
>  
>   return 0;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 399d041..9e8b8b4 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -860,6 +860,9 @@
>  #define GT_RENDER_DEBUG_INTERRUPT(1 <<  1)
>  #define GT_RENDER_USER_INTERRUPT (1 <<  0)
>  
> +#define PM_VEBOX_CS_ERROR_INTERRUPT  (1 << 12) /* hsw+ */
> +#define PM_VEBOX_USER_INTERRUPT  (1 << 10) /* hsw+ */
> +
>  /* These are all the "old" interrupts */
>  #define ILK_BSD_USER_INTERRUPT   (1<<5)
>  #define I915_PIPE_CONTROL_NOTIFY_INTERRUPT   (1<<18)
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 93a3128..30f22e1 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -1954,7 +1954,7 @@ int intel_init_vebox_ring_buffer(struct drm_device *dev)
>   ring->add_request = gen6_add_request;
>   ring->get_seqno = gen6_ring_get_seqno;
>   ring->set_seqno = ring_set_seqno;
> - ring->irq_enable_mask = 0;
> + ring->irq_enable_mask = PM_VEBOX_USER_INTERRUPT | 
> PM_VEBOX_CS_ERROR_INTERRUPT;
>   ring->irq_get = hsw_vebox_get_irq;
>   ring->irq_put = hsw_vebox_put_irq;
>   ring->dispatch_execbuffer = gen6_ring_dispatch_execbuffer;
> -- 
> 1.8.2.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 16/18] drm/i915: add VEBOX into debugfs

2013-05-28 Thread Damien Lespiau
On Sat, Apr 27, 2013 at 05:59:27PM -0700, Ben Widawsky wrote:
> From: "Xiang, Haihao" 
> 
> v2 (Ben): s/hsw/hws
> 
> Signed-off-by: Xiang, Haihao 
> [Order changed, and modified by]
> Signed-off-by: Ben Widawsky 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 13 +
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index a55630a..71fb7aa 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -379,6 +379,17 @@ static int i915_gem_request_info(struct seq_file *m, 
> void *data)
>   }
>   count++;
>   }
> + if (!list_empty(&dev_priv->ring[VECS].request_list)) {
> + seq_printf(m, "VEBOX requests:\n");
> + list_for_each_entry(gem_request,
> + &dev_priv->ring[VECS].request_list,
> + list) {
> + seq_printf(m, "%d @ %d\n",
> +gem_request->seqno,
> +(int) (jiffies - 
> gem_request->emitted_jiffies));
> + }
> + count++;
> + }
>   mutex_unlock(&dev->struct_mutex);

That block doesn't seem necessary as the code above this chuck cycles
over all the rings?

>  
>   if (count == 0)
> @@ -570,6 +581,7 @@ static const char *ring_str(int ring)
>   case RCS: return "render";
>   case VCS: return "bsd";
>   case BCS: return "blt";
> + case VECS: return "vebox";
>   default: return "";
>   }
>  }
> @@ -2099,6 +2111,7 @@ static struct drm_info_list i915_debugfs_list[] = {
>   {"i915_gem_hws", i915_hws_info, 0, (void *)RCS},
>   {"i915_gem_hws_blt", i915_hws_info, 0, (void *)BCS},
>   {"i915_gem_hws_bsd", i915_hws_info, 0, (void *)VCS},
> + {"i915_gem_hws_vebox", i915_hws_info, 0, (void *)VECS},
>   {"i915_rstdby_delays", i915_rstdby_delays, 0},
>   {"i915_cur_delayinfo", i915_cur_delayinfo, 0},
>   {"i915_delayfreq_table", i915_delayfreq_table, 0},
> -- 
> 1.8.2.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 17/18] drm/i915: add I915_EXEC_VEBOX to i915_gem_do_execbuffer()

2013-05-28 Thread Damien Lespiau
On Sat, Apr 27, 2013 at 05:59:28PM -0700, Ben Widawsky wrote:
> From: "Xiang, Haihao" 
> 
> A user can run batchbuffer via VEBOX ring.
> 
> Signed-off-by: Xiang, Haihao 
> [Order changed by]
> Signed-off-by: Ben Widawsky 

Reviewed-by: Damien Lespiau 

-- 
Damien

> ---
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 9 +
>  include/uapi/drm/i915_drm.h| 1 +
>  2 files changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 117ce38..a8bb62c 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -885,6 +885,15 @@ i915_gem_do_execbuffer(struct drm_device *dev, void 
> *data,
>   return -EPERM;
>   }
>   break;
> + case I915_EXEC_VEBOX:
> + ring = &dev_priv->ring[VECS];
> + if (ctx_id != 0) {
> + DRM_DEBUG("Ring %s doesn't support contexts\n",
> +   ring->name);
> + return -EPERM;
> + }
> + break;
> +
>   default:
>   DRM_DEBUG("execbuf with unknown ring: %d\n",
> (int)(args->flags & I915_EXEC_RING_MASK));
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 07d5941..81b9981 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -660,6 +660,7 @@ struct drm_i915_gem_execbuffer2 {
>  #define I915_EXEC_RENDER (1<<0)
>  #define I915_EXEC_BSD(2<<0)
>  #define I915_EXEC_BLT(3<<0)
> +#define I915_EXEC_VEBOX  (4<<0)
>  
>  /* Used for switching the constants addressing mode on gen4+ RENDER ring.
>   * Gen6+ only supports relative addressing to dynamic state (default) and
> -- 
> 1.8.2.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 18/18] drm/i915: add I915_PARAM_HAS_VEBOX to i915_getparam

2013-05-28 Thread Damien Lespiau
On Sat, Apr 27, 2013 at 05:59:29PM -0700, Ben Widawsky wrote:
> From: "Xiang, Haihao" 
> 
> This will let userland only try to use the new ring
> when the appropriate kernel is present
> 
> Signed-off-by: Xiang, Haihao 
> [Order changed, and merge conflict resolved by]
> Signed-off-by: Ben Widawsky 

Reviewed-by: Damien Lespiau 

-- 
Damien

> ---
>  drivers/gpu/drm/i915/i915_dma.c | 3 +++
>  include/uapi/drm/i915_drm.h | 2 +-
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index a1648eb..66a1e39 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -956,6 +956,9 @@ static int i915_getparam(struct drm_device *dev, void 
> *data,
>   case I915_PARAM_HAS_BLT:
>   value = intel_ring_initialized(&dev_priv->ring[BCS]);
>   break;
> + case I915_PARAM_HAS_VEBOX:
> + value = intel_ring_initialized(&dev_priv->ring[VECS]);
> + break;
>   case I915_PARAM_HAS_RELAXED_FENCING:
>   value = 1;
>   break;
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index 81b9981..923ed7f 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -305,7 +305,7 @@ typedef struct drm_i915_irq_wait {
>  #define I915_PARAM_HAS_WAIT_TIMEOUT   19
>  #define I915_PARAM_HAS_SEMAPHORES 20
>  #define I915_PARAM_HAS_PRIME_VMAP_FLUSH   21
> -#define I915_PARAM_RSVD_FOR_FUTURE_USE22
> +#define I915_PARAM_HAS_VEBOX  22
>  #define I915_PARAM_HAS_SECURE_BATCHES 23
>  #define I915_PARAM_HAS_PINNED_BATCHES 24
>  #define I915_PARAM_HAS_EXEC_NO_RELOC  25
> -- 
> 1.8.2.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx


[Intel-gfx] [PATCH -next] drm/i915: fix error return code in init_pipe_control()

2013-05-28 Thread Wei Yongjun
From: Wei Yongjun 

Fix to return -ENOMEM in the kmap() error handling case
instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 5698fae..9b97cf6 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -464,9 +464,11 @@ init_pipe_control(struct intel_ring_buffer *ring)
goto err_unref;
 
pc->gtt_offset = obj->gtt_offset;
-   pc->cpu_page =  kmap(sg_page(obj->pages->sgl));
-   if (pc->cpu_page == NULL)
+   pc->cpu_page = kmap(sg_page(obj->pages->sgl));
+   if (pc->cpu_page == NULL) {
+   ret = -ENOMEM;
goto err_unpin;
+   }
 
DRM_DEBUG_DRIVER("%s pipe control offset: 0x%08x\n",
 ring->name, pc->gtt_offset);

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


Re: [Intel-gfx] [i-g-t PATCH v3 2/2] tests/lib: make sure the GPU is idle at test start and exit

2013-05-28 Thread Daniel Vetter
On Tue, May 28, 2013 at 05:35:32PM +0300, Imre Deak wrote:
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64270
> 
> v2:
> - Make sure also that the GPU is idle at start and error exit of any
>   test using drm_open_any(). (Daniel)
> v3:
> - actually call gem_quiescent_gpu() at exit
> 
> Signed-off-by: Imre Deak 

Both merged to igt, thanks.
-Daniel

> ---
>  lib/drmtest.c | 27 ++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/drmtest.c b/lib/drmtest.c
> index 2d37fb6..d17dbb0 100644
> --- a/lib/drmtest.c
> +++ b/lib/drmtest.c
> @@ -228,7 +228,7 @@ int drm_get_card(int master)
>  }
>  
>  /** Open the first DRM device we can find, searching up to 16 device nodes */
> -int drm_open_any(void)
> +static int __drm_open_any(void)
>  {
>   char *name;
>   int ret, fd;
> @@ -248,6 +248,31 @@ int drm_open_any(void)
>   return fd;
>  }
>  
> +static void quiescent_gpu_at_exit(int sig)
> +{
> + int fd;
> +
> + fd = __drm_open_any();
> + if (fd >= 0) {
> + gem_quiescent_gpu(fd);
> + close(fd);
> + }
> +}
> +
> +int drm_open_any(void)
> +{
> + static int open_count;
> + int fd = __drm_open_any();
> +
> + if (fd < 0 || __sync_fetch_and_add(&open_count, 1))
> + return fd;
> +
> + gem_quiescent_gpu(fd);
> + drmtest_install_exit_handler(quiescent_gpu_at_exit);
> +
> + return fd;
> +}
> +
>  /**
>   * Open the first DRM device we can find where we end up being the master.
>   */
> -- 
> 1.8.1.2
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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


Re: [Intel-gfx] [PATCH 09/18] drm/i915: make PM interrupt writes non-destructive

2013-05-28 Thread Ben Widawsky
On Tue, May 28, 2013 at 02:30:56PM +0100, Damien Lespiau wrote:
> On Sat, Apr 27, 2013 at 05:59:20PM -0700, Ben Widawsky wrote:
> > @@ -2720,12 +2720,12 @@ static void gen6_enable_rps(struct drm_device *dev)
> > gen6_set_rps(dev_priv->dev, (gt_perf_status & 0xff00) >> 8);
> >  
> > /* requires MSI enabled */
> > -   I915_WRITE(GEN6_PMIER, GEN6_PM_DEFERRED_EVENTS);
> > +   I915_WRITE(GEN6_PMIER, I915_READ(GEN6_PMIER) | GEN6_PM_RPS_EVENTS);
> > spin_lock_irq(&dev_priv->rps.lock);
> > WARN_ON(dev_priv->rps.pm_iir != 0);
> > -   I915_WRITE(GEN6_PMIMR, 0);
> > +   I915_WRITE(GEN6_PMIIR, GEN6_PM_RPS_EVENTS);
> 
> You're not unmasking the RPS interrupts in PMIMR here now. I'm missing
> how they are enabled now.

You are right. It's fixed in a later patch IFF we have VEBOX, but would
regress on IVB and HSW. Both this patch, and that are easily fixed. BRB.

> 
> > spin_unlock_irq(&dev_priv->rps.lock); - /* enable all PM
> > interrupts */ + /* unmask all PM interrupts */
> > I915_WRITE(GEN6_PMINTRMSK, 0);
> >
> > rc6vids = 0;

-- 
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 16/18] drm/i915: add VEBOX into debugfs

2013-05-28 Thread Ben Widawsky
On Tue, May 28, 2013 at 04:06:07PM +0100, Damien Lespiau wrote:
> On Sat, Apr 27, 2013 at 05:59:27PM -0700, Ben Widawsky wrote:
> > From: "Xiang, Haihao" 
> > 
> > v2 (Ben): s/hsw/hws
> > 
> > Signed-off-by: Xiang, Haihao 
> > [Order changed, and modified by]
> > Signed-off-by: Ben Widawsky 
> > ---
> >  drivers/gpu/drm/i915/i915_debugfs.c | 13 +
> >  1 file changed, 13 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index a55630a..71fb7aa 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -379,6 +379,17 @@ static int i915_gem_request_info(struct seq_file *m, 
> > void *data)
> > }
> > count++;
> > }
> > +   if (!list_empty(&dev_priv->ring[VECS].request_list)) {
> > +   seq_printf(m, "VEBOX requests:\n");
> > +   list_for_each_entry(gem_request,
> > +   &dev_priv->ring[VECS].request_list,
> > +   list) {
> > +   seq_printf(m, "%d @ %d\n",
> > +  gem_request->seqno,
> > +  (int) (jiffies - 
> > gem_request->emitted_jiffies));
> > +   }
> > +   count++;
> > +   }
> > mutex_unlock(&dev->struct_mutex);
> 
> That block doesn't seem necessary as the code above this chuck cycles
> over all the rings?

Indeed. This is a rebase relic. This hunk is removed.
> 
> >  
> > if (count == 0)
> > @@ -570,6 +581,7 @@ static const char *ring_str(int ring)
> > case RCS: return "render";
> > case VCS: return "bsd";
> > case BCS: return "blt";
> > +   case VECS: return "vebox";
> > default: return "";
> > }
> >  }
> > @@ -2099,6 +2111,7 @@ static struct drm_info_list i915_debugfs_list[] = {
> > {"i915_gem_hws", i915_hws_info, 0, (void *)RCS},
> > {"i915_gem_hws_blt", i915_hws_info, 0, (void *)BCS},
> > {"i915_gem_hws_bsd", i915_hws_info, 0, (void *)VCS},
> > +   {"i915_gem_hws_vebox", i915_hws_info, 0, (void *)VECS},
> > {"i915_rstdby_delays", i915_rstdby_delays, 0},
> > {"i915_cur_delayinfo", i915_cur_delayinfo, 0},
> > {"i915_delayfreq_table", i915_delayfreq_table, 0},
> > -- 
> > 1.8.2.1
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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 13/18] drm/i915: consolidate interrupt naming scheme

2013-05-28 Thread Ben Widawsky
On Tue, May 28, 2013 at 03:01:54PM +0100, Damien Lespiau wrote:
> On Sat, Apr 27, 2013 at 05:59:24PM -0700, Ben Widawsky wrote:
> > The motivation here is we're going to add some new interrupt definitions
> > and handling outside of the GT interrupts which is all we've managed so
> > far (with some RPS exceptions). By consolidating the names in the future
> > we can make thing a bit cleaner as we don't need to define register
> > names twice, and we can leverage pretty decent overlap in HW registers
> > since ILK.
> > 
> > To explain briefly what is in the comments: there are two sets of
> > interrupt masking/enabling registers. At least so far, the definitions
> > of the two sets overlap. The old code setup distinct names for
> > interrupts in each set, ie. one for global, and one for ring. This made
> > things confusing when using the wrong defines in the wrong places.
> > 
> > rebase: Modified VLV bits
> > 
> > Signed-off-by: Ben Widawsky 
> 
> 
> With or without the naming biskeshed below:
> 
> Reviewed-by: Damien Lespiau 
> 
> -- 
> Damien
> 
> > ---
> >  drivers/gpu/drm/i915/i915_irq.c |  58 +-
> >  drivers/gpu/drm/i915/i915_reg.h | 101 
> > ++--
> >  drivers/gpu/drm/i915/intel_ringbuffer.c |  17 +++---
> >  3 files changed, 79 insertions(+), 97 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index 4a1b7f5..06e254a 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -781,7 +781,7 @@ static void ivybridge_parity_work(struct work_struct 
> > *work)
> > I915_WRITE(GEN7_MISCCPCTL, misccpctl);
> >  
> > spin_lock_irqsave(&dev_priv->irq_lock, flags);
> > -   dev_priv->gt_irq_mask &= ~GT_GEN7_L3_PARITY_ERROR_INTERRUPT;
> > +   dev_priv->gt_irq_mask &= ~GT_RENDER_L3_PARITY_ERROR_INTERRUPT;
> > I915_WRITE(GTIMR, dev_priv->gt_irq_mask);
> > spin_unlock_irqrestore(&dev_priv->irq_lock, flags);
> >  
> > @@ -813,7 +813,7 @@ static void ivybridge_handle_parity_error(struct 
> > drm_device *dev)
> > return;
> >  
> > spin_lock_irqsave(&dev_priv->irq_lock, flags);
> > -   dev_priv->gt_irq_mask |= GT_GEN7_L3_PARITY_ERROR_INTERRUPT;
> > +   dev_priv->gt_irq_mask |= GT_RENDER_L3_PARITY_ERROR_INTERRUPT;
> > I915_WRITE(GTIMR, dev_priv->gt_irq_mask);
> > spin_unlock_irqrestore(&dev_priv->irq_lock, flags);
> >  
> > @@ -825,22 +825,21 @@ static void snb_gt_irq_handler(struct drm_device *dev,
> >u32 gt_iir)
> >  {
> >  
> > -   if (gt_iir & (GEN6_RENDER_USER_INTERRUPT |
> > - GEN6_RENDER_PIPE_CONTROL_NOTIFY_INTERRUPT))
> > +   if (gt_iir & (GT_RENDER_USER_INTERRUPT | 
> > GT_RENDER_PIPECTL_NOTIFY_INTERRUPT))
> > notify_ring(dev, &dev_priv->ring[RCS]);
> > -   if (gt_iir & GEN6_BSD_USER_INTERRUPT)
> > +   if (gt_iir & GT_BSD_USER_INTERRUPT)
> > notify_ring(dev, &dev_priv->ring[VCS]);
> > -   if (gt_iir & GEN6_BLITTER_USER_INTERRUPT)
> > +   if (gt_iir & GT_BLT_USER_INTERRUPT)
> > notify_ring(dev, &dev_priv->ring[BCS]);
> >  
> > -   if (gt_iir & (GT_GEN6_BLT_CS_ERROR_INTERRUPT |
> > - GT_GEN6_BSD_CS_ERROR_INTERRUPT |
> > - GT_RENDER_CS_ERROR_INTERRUPT)) {
> > +   if (gt_iir & (GT_BLT_CS_ERROR_INTERRUPT |
> > + GT_BSD_CS_ERROR_INTERRUPT |
> > + GT_RENDER_MASTER_ERROR_INTERRUPT)) {
> 
> If we ware in the naming domain here, not sure why the CS master error
> for render would have a different name than the others,
> GT_RENDER_CS_ERROR_INTERRUPT looked good to me.

I was just copying the docs. I presume on earlier gens, maybe it meant
something else? It seems I accidently dropped the "CS" part though. I've
added that back, and left the MASTER.

"Render Command Parser Master Error"


> 
> > DRM_ERROR("GT error interrupt 0x%08x\n", gt_iir);
> > i915_handle_error(dev, false);
> > }
> >  
> > -   if (gt_iir & GT_GEN7_L3_PARITY_ERROR_INTERRUPT)
> > +   if (gt_iir & GT_RENDER_L3_PARITY_ERROR_INTERRUPT)
> > ivybridge_handle_parity_error(dev);
> >  }
> >  
> > @@ -1284,9 +1283,9 @@ static void ilk_gt_irq_handler(struct drm_device *dev,
> >struct drm_i915_private *dev_priv,
> >u32 gt_iir)
> >  {
> > -   if (gt_iir & (GT_USER_INTERRUPT | GT_PIPE_NOTIFY))
> > +   if (gt_iir & (GT_RENDER_USER_INTERRUPT | 
> > GT_RENDER_PIPECTL_NOTIFY_INTERRUPT))
> > notify_ring(dev, &dev_priv->ring[RCS]);
> > -   if (gt_iir & GT_BSD_USER_INTERRUPT)
> > +   if (gt_iir & ILK_BSD_USER_INTERRUPT)
> > notify_ring(dev, &dev_priv->ring[VCS]);
> >  }
> >  
> > @@ -2629,7 +2628,7 @@ static int ironlake_irq_postinstall(struct drm_device 
> > *dev)
> >DE_PLANEA_FLIP_DONE | DE_PLANEB_FLIP_DONE |
> >DE_AUX_CHANNEL_A | DE_PIPEB_FIFO_UNDERRUN |
> >  

Re: [Intel-gfx] debugging Haswell eDP black screen after S3

2013-05-28 Thread Ben Guthro
On Tue, May 21, 2013 at 1:28 PM, Ben Guthro  wrote:
> On Tue, May 21, 2013 at 10:02 AM, Daniel Vetter  wrote:
>> On Tue, May 21, 2013 at 3:44 PM, Ben Guthro  wrote:
 This will break kms since now you have the vbios and the linux kms driver
 fighting over the same piece of hw. Does

 xset dpms force off
 xset dpms force on

 cause similar issues?
>>>
>>> No, these work as expected (on 3.8)
>>> I didn't realize that these broke with KMS. I'll stick with the S3 
>>> reproduction.
>>
>> Ok, so things are at least not terribly broken.
>>
 If not please make sure that vbetool isn't badly interfering with the
 kernel modeset driver on suspend/resume. At least looking at your dmesg
 and reg dumps vbe wreaking havoc with the kms driver seems like a rather
 likely scenario. Also, can you please test latest 3.10-rc kernels?
>>>
>>> 3.10-rc2 doesn't seem to work at all - it boots to a black screen every 
>>> time.
>>
>> That otoh is ugly. Could be that though that this is the same (or a
>> similar bug) to your resume issue - in the last few kernel releases
>> we've tried very hard to unify the code between initial driver load at
>> boot-up and resume.
>
> Perhaps I should qualify "at all"
>
> It seems that it fails somewhat late in the boot process. If I remove
> the "boot splash" cli params, I can see it transition into the high
> res mode, and seemingly get into init.
> However, even if I boot to single user mode, the screen goes black.
>
> Unfortunately, both times I tried to test this, and then reboot, I
> ended up at a "grub rescue" prompt, with an unusable system.
>
>>
>> So can you please try to bisect where the boot-up regression has been
>> introduced between 3.8 and 3.10-rc2?
>
> I'm not sure I'll be able to do this.
> With the failure condition I describe above, I am unable to even ssh
> into this machine to debug, nevermind install a new kernel.
> This means I need to generate a new kernel, and install kit with that
> kernel for every bisection test.
>
> This may be more time than I am able to dedicate to this problem - but I'll 
> try.
>
> Ben

It appears I did not CC the list on my last 2 replies.
My apologies - I'll re-paste them below.


I tried to bisect this, but was unsuccessful, in that I didn't seem to
have a reproducible test case to get back into this failure condition.
It seemed that it always would succeed for me...which of course makes
bisecting near impossible.

I tried updating to 3.10-RC3...well, actually to this changeset at the
tip of Linus' tree:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=58f8bbd2e39c3732c55698494338ee19a92c53a0

I can get X to come up now on this machine - albeit very slowly.
Once it comes up, it seems to hang, and respawn

I get a lot of these in the log now, as well:

[  392.195734] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer
elapsed... GPU hung

Things in the log that look suspicious to me are:
[   34.293452] [drm:intel_pipe_set_base] *ERROR* pin & fence failed
[   34.293486] [drm:intel_crtc_set_config] *ERROR* failed to set mode
on [CRTC:3], err = -28


I get the following errors in the X log, that prevent it from coming up:
[76.142] (EE) intel(0): failed to set mode: No space left on device
[76.142]
Fatal server error:
[76.142] AddScreen/ScreenInit failed for driver 0
[76.142]
[76.142] (EE)



Xorg also crashes in the following manner:


[   218.876] (EE) Backtrace:
[   218.880] (EE) 0: X (xorg_backtrace+0x34) [0x7fe44fff9754]
[   218.880] (EE) 1: X (0x7fe44fe44000+0x1b96a9) [0x7fe44fffd6a9]
[   218.880] (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0
(0x7fe44f16a000+0xfcb0) [0x7fe44f179cb0]
[   218.880] (EE) 3: /lib/x86_64-linux-gnu/libc.so.6
(0x7fe44ddcf000+0x148c6b) [0x7fe44df17c6b]
[   218.880] (EE) 4: /usr/lib/xorg/modules/drivers/intel_drv.so
(0x7fe44cb5a000+0x17c36) [0x7fe44cb71c36]
[   218.880] (EE) 5: /usr/lib/xorg/modules/drivers/intel_drv.so
(0x7fe44cb5a000+0x19857) [0x7fe44cb73857]
[   218.880] (EE) 6: /usr/lib/xorg/modules/drivers/intel_drv.so
(0x7fe44cb5a000+0xed429) [0x7fe44cc47429]
[   218.880] (EE) 7: X (0x7fe44fe44000+0x13e8ac) [0x7fe44ff828ac]
[   218.880] (EE) 8: X (0x7fe44fe44000+0x5239e) [0x7fe44fe9639e]
[   218.880] (EE) 9: X (0x7fe44fe44000+0x557a1) [0x7fe44fe997a1]
[   218.880] (EE) 10: X (0x7fe44fe44000+0x4415a) [0x7fe44fe8815a]
[   218.880] (EE) 11: /lib/x86_64-linux-gnu/libc.so.6
(__libc_start_main+0xed) [0x7fe44ddf076d]
[   218.880] (EE) 12: X (0x7fe44fe44000+0x444b1) [0x7fe44fe884b1]
[   218.880] (EE)
[   218.880] (EE) Bus error at address 0x7fe44a6c9080
[   218.880]
Fatal server error:
[   218.881] Caught signal 7 (Bus error). Server aborting
[   218.881]
[   218.881] (EE)


I recognize that this isn't terribly helpful without the symbol
resolution. I tried installing debug symbols, but they didn't seem to
help.

Ben
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freed

[Intel-gfx] [PULL] drm-intel-next for 3.11

2013-05-28 Thread Daniel Vetter
Hi Dave,

So I've figured it's time to upon up drm-next with a nice pile of intel
patches. And there seems to be some other stuff pending on dri-devel
already, too ;-)

Highlights (copy-pasted from my testing cycle mails):
- fbc support for Haswell (Rodrigo)
- streamlined workaround comments, including an igt tool to grep for
  them (Damien)
- sdvo and TV out cleanups, including a fixup for sdvo multifunction devices
- refactor our eDP mess a bit (Imre)
- don't register the hdmi connector on haswell when desktop eDP is present
- vlv support is no longer preliminary!
- more vlv fixes from Jesse for stolen and dpll handling
- more flexible power well checking infrastructure from Paulo
- a few gtt patches from Ben
- a bit of OCD cleanups for transcoder #defines and an assorted pile
  of smaller things.
- fixes for the gmch modeset sequence
- a bit of OCD around plane/pipe usage (Ville)
- vlv turbo support (Jesse)
- tons of vlv modeset fixes (Jesse et al.)
- vlv pte write fixes (Kenneth Graunke)
- hpd filtering to avoid costly probes on unaffected outputs (Egbert Eich)
- intel dev_info cleanups and refactorings (Damien)
- vlv rc6 support (Jesse)
- random pile of fixes around non-24bpp modes handling
- asle/opregion cleanups and locking fixes (Jani)
- dp dpll refactoring
- improvements for reduced_clock computation on g4x/ilk+
- pfit state refactored to use pipe_config (Jesse)
- lots more computed modeset state moved to pipe_config, including readout
  and cross-check support
- fdi auto-dithering for ivb B/C links, using the neat pipe_config
  improvements
- drm_rect helpers plus sprite clipping fixes (Ville)
- hw context refcounting (Mika + Ben)

Note that the merge with Linus' tree was a bit messy so I've also pushed
out a 2nd tag drm-intel-next-2013-05-20-merged which has the backmerge
which is already in my queue. Pull request for the merged tree below. Just
drop the -merged suffix if you want to have some fun ;-)

Cheers, Daniel


The following changes since commit c7788792a5e7b0d5d7f96d0766b4cb6112d47d75:

  Linux 3.10-rc2 (2013-05-20 14:37:38 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~danvet/drm-intel 
tags/drm-intel-next-2013-05-20-merged

for you to fetch changes up to e1b73cba13a0cc68dd4f746eced15bd6bb24cda4:

  Merge tag 'v3.10-rc2' into drm-intel-next-queued (2013-05-21 09:52:16 +0200)



Ben Widawsky (3):
  drm/i915: Assert mutex_is_locked on context lookup
  drm/i915: BUG_ON bad PPGTT offset
  drm/i915: Extract PDE writes

Chris Wilson (2):
  drm/i915: Only print the info message about incresing stolen size for FBC 
once
  drm/i915: put context upon switching

Damien Lespiau (12):
  drm/i915: Remove mention of Haswell in DDI code
  drm/i915: Turn DEV_INFO_FLAGS into a foreach style macro
  drm/i915: Replace the line of %s by a DEV_INFO_FOR_EACH_FLAG() invocation
  drm/i915: Use DEV_INFO_FOR_EACH_FLAG() to declare flags as well
  drm/i915: Turn HAS_DDI() into a device_info flag
  drm/i915: Introduce HAS_FPGA_DBG_UNCLAIMED()
  drm/i915: Turn HAS_FPGA_DBG_UNCLAIMED into a device_info flag
  drm/i915: Ivybridge is the odd one when it comes to pipe scalers
  drm/i915: Add platform information to implemented workarounds
  drm/i915: Add references to some workaround we implement
  drm/i915: Compute WR PLL dividers dynamically
  drm/i915: Add missing platform tags to FBC workaround comments

Daniel Vetter (56):
  drm/i915: don't enable the plane too early in i9xx_crtc_mode_set
  drm/i915: drop redundant vblank waits
  drm/i915: add pipe asserts for the crtc enable sequence
  drm/i915: add i9xx pfit pipe asserts
  drm/i915: move debug output back to the right place
  drm/i915: fix VLV limits
  drm/i915: magic VLV PLL registers in the dpio sideband
  drm/i915: disable interrupts earlier in the driver unload code
  drm/i915: Disable high-bpc on pre-1.4 EDID screens
  drm/i915: Fixup non-24bpp support for VGA screens on Haswell
  drm/i915: consolidate pch pll computations a bit
  drm/i915: shovel compute clock into crtc->config.dpll on ilk
  drm/i915: move dp clock computations to encoder->compute_config
  drm/i915: use pipe_config for lvds dithering
  drm/i915: don't force matching p1 for g4x/ilk+ reduced pll settings
  drm/i915: remove redundant has_pch_encoder check
  drm/i915: simplify config->pixel_multiplier handling
  drm/i915: put the right cpu_transcoder into pipe_config for hw state 
readout
  drm/i915: force bpp for eDP panels
  drm/i915: drop adjusted_mode from *_set_pipeconf functions
  drm/i915: implement high-bpc + pipeconf-dither support for g4x/vlv
  drm/i915: allow high-bpc modes on DP
  drm/i915: move intel_crtc->fdi_lanes to pipe_config
  drm/i915: hw state readout support for pipe_config->fdi_lanes
  drm/i915: split up fdi_

[Intel-gfx] [PATCH] drm/i915: WA: FBC Render Nuke.

2013-05-28 Thread Rodrigo Vivi
WaFbcNukeOn3DBlt for IVB, HSW and VLV.

According BSPec: "Workaround: Do not enable Render Command Streamer tracking 
for FBC.
Instead insert a LRI to address 0x50380 with data 0x0004 after the 
PIPE_CONTROL that
follows each render submission."

v2: Chris noticed that flush_domains check was missing here and also suggested 
to do
LRI only when fbc is enabled. To avoid do a I915_READ on every flush lets 
use the
module parameter check.

v3: Adding Wa name as Damien suggested.

Cc: Chris Wilson 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_reg.h |  2 ++
 drivers/gpu/drm/i915/intel_pm.c |  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c | 32 
 3 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cc4c223..81ac584 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -977,6 +977,8 @@
 /* Framebuffer compression for Ivybridge */
 #define IVB_FBC_RT_BASE0x7020
 
+#define MSG_FBC_REND_STATE 0x50380
+#define   FBC_REND_NUKE(1<<2)
 
 #define _HSW_PIPE_SLICE_CHICKEN_1_A0x420B0
 #define _HSW_PIPE_SLICE_CHICKEN_1_B0x420B4
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 1879188..e830a9b 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -274,7 +274,7 @@ static void gen7_enable_fbc(struct drm_crtc *crtc, unsigned 
long interval)
struct drm_i915_gem_object *obj = intel_fb->obj;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 
-   I915_WRITE(IVB_FBC_RT_BASE, obj->gtt_offset | ILK_FBC_RT_VALID);
+   I915_WRITE(IVB_FBC_RT_BASE, obj->gtt_offset);
 
if (!intel_edp_is_psr_enabled(dev))
I915_WRITE(ILK_DPFC_CONTROL, DPFC_CTL_EN | DPFC_CTL_LIMIT_1X |
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 3d2c236..69491db 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -280,6 +280,30 @@ gen7_render_ring_cs_stall_wa(struct intel_ring_buffer 
*ring)
return 0;
 }
 
+static int gen7_ring_fbc_flush(struct intel_ring_buffer *ring)
+{
+   struct drm_device *dev = ring->dev;
+   int ret;
+
+   if (i915_enable_fbc == 0)
+   return 0;
+
+   if (i915_enable_fbc < 0 && !IS_HASWELL(dev))
+   return 0;
+
+   ret = intel_ring_begin(ring, 4);
+   if (ret)
+   return ret;
+   intel_ring_emit(ring, MI_NOOP);
+   /* WaFbcNukeOn3DBlt:ivb/hsw/vlv */
+   intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
+   intel_ring_emit(ring, MSG_FBC_REND_STATE);
+   intel_ring_emit(ring, FBC_REND_NUKE);
+   intel_ring_advance(ring);
+
+   return 0;
+}
+
 static int
 gen7_render_ring_flush(struct intel_ring_buffer *ring,
   u32 invalidate_domains, u32 flush_domains)
@@ -336,6 +360,9 @@ gen7_render_ring_flush(struct intel_ring_buffer *ring,
intel_ring_emit(ring, 0);
intel_ring_advance(ring);
 
+   if (flush_domains)
+   return gen7_ring_fbc_flush(ring);
+
return 0;
 }
 
@@ -1623,6 +1650,7 @@ gen6_ring_dispatch_execbuffer(struct intel_ring_buffer 
*ring,
 static int blt_ring_flush(struct intel_ring_buffer *ring,
  u32 invalidate, u32 flush)
 {
+   struct drm_device *dev = ring->dev;
uint32_t cmd;
int ret;
 
@@ -1645,6 +1673,10 @@ static int blt_ring_flush(struct intel_ring_buffer *ring,
intel_ring_emit(ring, 0);
intel_ring_emit(ring, MI_NOOP);
intel_ring_advance(ring);
+
+   if (IS_GEN7(dev))
+   return gen7_ring_fbc_flush(ring);
+
return 0;
 }
 
-- 
1.8.1.4

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


Re: [Intel-gfx] [PATCH] drm/i915: WA: FBC Render Nuke.

2013-05-28 Thread Rodrigo Vivi
Ops, sorry about miss "in-reply-to".. I was here fighting with my git
send-email for a long time doing many attempts...

Anyways, going to the point.
Ville, I decide to let it without SRM described in PM guide because it
doesn't not work properly. I' ve made many attempts here but it doesn'
t work rpopertly.
>From the MI_SOTRE_REGISTER_MEM in BSpec: "This command temporarily
halts command execution."
Besides that we don't have a reliable way to detect directly front
buffer rendering...

I understand the synchronization concerns, but this patch follows the
BSPec workaround and it is working properly here on my both machines
(IVB and HSW) for more than on week now without a single corruption or
slowness.

So, this is the best we have now and I kindly ask you guys to accept
it. It fixed many corruption and slowness that Timothy faced.
In parallel I'm going to contact PM guide writers asking about this
SRM and also asking them new updated versions.

Thanks in advance,
Rodrigo




On Tue, May 28, 2013 at 9:25 PM, Rodrigo Vivi  wrote:
> WaFbcNukeOn3DBlt for IVB, HSW and VLV.
>
> According BSPec: "Workaround: Do not enable Render Command Streamer tracking 
> for FBC.
> Instead insert a LRI to address 0x50380 with data 0x0004 after the 
> PIPE_CONTROL that
> follows each render submission."
>
> v2: Chris noticed that flush_domains check was missing here and also 
> suggested to do
> LRI only when fbc is enabled. To avoid do a I915_READ on every flush lets 
> use the
> module parameter check.
>
> v3: Adding Wa name as Damien suggested.
>
> Cc: Chris Wilson 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_reg.h |  2 ++
>  drivers/gpu/drm/i915/intel_pm.c |  2 +-
>  drivers/gpu/drm/i915/intel_ringbuffer.c | 32 
>  3 files changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index cc4c223..81ac584 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -977,6 +977,8 @@
>  /* Framebuffer compression for Ivybridge */
>  #define IVB_FBC_RT_BASE0x7020
>
> +#define MSG_FBC_REND_STATE 0x50380
> +#define   FBC_REND_NUKE(1<<2)
>
>  #define _HSW_PIPE_SLICE_CHICKEN_1_A0x420B0
>  #define _HSW_PIPE_SLICE_CHICKEN_1_B0x420B4
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 1879188..e830a9b 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -274,7 +274,7 @@ static void gen7_enable_fbc(struct drm_crtc *crtc, 
> unsigned long interval)
> struct drm_i915_gem_object *obj = intel_fb->obj;
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>
> -   I915_WRITE(IVB_FBC_RT_BASE, obj->gtt_offset | ILK_FBC_RT_VALID);
> +   I915_WRITE(IVB_FBC_RT_BASE, obj->gtt_offset);
>
> if (!intel_edp_is_psr_enabled(dev))
> I915_WRITE(ILK_DPFC_CONTROL, DPFC_CTL_EN | DPFC_CTL_LIMIT_1X |
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 3d2c236..69491db 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -280,6 +280,30 @@ gen7_render_ring_cs_stall_wa(struct intel_ring_buffer 
> *ring)
> return 0;
>  }
>
> +static int gen7_ring_fbc_flush(struct intel_ring_buffer *ring)
> +{
> +   struct drm_device *dev = ring->dev;
> +   int ret;
> +
> +   if (i915_enable_fbc == 0)
> +   return 0;
> +
> +   if (i915_enable_fbc < 0 && !IS_HASWELL(dev))
> +   return 0;
> +
> +   ret = intel_ring_begin(ring, 4);
> +   if (ret)
> +   return ret;
> +   intel_ring_emit(ring, MI_NOOP);
> +   /* WaFbcNukeOn3DBlt:ivb/hsw/vlv */
> +   intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
> +   intel_ring_emit(ring, MSG_FBC_REND_STATE);
> +   intel_ring_emit(ring, FBC_REND_NUKE);
> +   intel_ring_advance(ring);
> +
> +   return 0;
> +}
> +
>  static int
>  gen7_render_ring_flush(struct intel_ring_buffer *ring,
>u32 invalidate_domains, u32 flush_domains)
> @@ -336,6 +360,9 @@ gen7_render_ring_flush(struct intel_ring_buffer *ring,
> intel_ring_emit(ring, 0);
> intel_ring_advance(ring);
>
> +   if (flush_domains)
> +   return gen7_ring_fbc_flush(ring);
> +
> return 0;
>  }
>
> @@ -1623,6 +1650,7 @@ gen6_ring_dispatch_execbuffer(struct intel_ring_buffer 
> *ring,
>  static int blt_ring_flush(struct intel_ring_buffer *ring,
>   u32 invalidate, u32 flush)
>  {
> +   struct drm_device *dev = ring->dev;
> uint32_t cmd;
> int ret;
>
> @@ -1645,6 +1673,10 @@ static int blt_ring_flush(struct intel_ring_buffer 
> *ring,
> intel_ring_emit(ring, 0);
> intel_ring_emit(ring, MI_NOOP);
> intel_ring_advance(ring);

[Intel-gfx] [PATCH 00/18] Introduce the Haswell VECS v2

2013-05-28 Thread Ben Widawsky
The primary change in this series is I introduce the
ivybridge_preinstall and "Add PM regs to pre/post install"
before make "PM interrupt writes non-destructive". This helps address
the issue Damien caught where the PMIMR is never cleared midway through
the series. On that note, I fixed a bug introduced on the previous
rebase where the PMIMR wasn't getting cleared without VEBOX. That fix is
addressed in v2 of "vebox interrupt get/put"

I've also rebased this series on the latest -nightly, and tried to fix
all comments Damien made in the series.

Thanks again to Damien for the review this far.

v1 with more background:
http://lists.freedesktop.org/archives/intel-gfx/2013-April/027308.html

Ben Widawsky (14):
  drm/i915: Comments for semaphore clarification
  drm/i915: Semaphore MBOX update generalization
  drm/i915: Introduce VECS: the 4th ring
  drm/i915: Add VECS semaphore bits
  drm/i915: Rename ring flush functions
  drm/i915: Vebox ringbuffer init
  drm/i915: Create a more generic pm handler for hsw+
  drm/i915: Create an ivybridge_irq_preinstall
  drm/i915: Add PM regs to pre/post install
  drm/i915: make PM interrupt writes non-destructive
  drm/i915: Convert irq_refounct to struct
  drm/i915: consolidate interrupt naming scheme
  drm/i915: vebox interrupt get/put
  drm/i915: Enable vebox interrupts

Xiang, Haihao (4):
  drm/i915: add HAS_VEBOX
  drm/i915: add VEBOX into debugfs
  drm/i915: add I915_EXEC_VEBOX to i915_gem_do_execbuffer()
  drm/i915: add I915_PARAM_HAS_VEBOX to i915_getparam

 drivers/gpu/drm/i915/i915_debugfs.c|   2 +
 drivers/gpu/drm/i915/i915_dma.c|   3 +
 drivers/gpu/drm/i915/i915_drv.c|   2 +
 drivers/gpu/drm/i915/i915_drv.h|   2 +
 drivers/gpu/drm/i915/i915_gem.c|  11 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   9 ++
 drivers/gpu/drm/i915/i915_irq.c| 162 ++--
 drivers/gpu/drm/i915/i915_reg.h| 148 +++---
 drivers/gpu/drm/i915/intel_pm.c|  15 +--
 drivers/gpu/drm/i915/intel_ringbuffer.c| 194 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.h|  16 ++-
 include/uapi/drm/i915_drm.h|   3 +-
 12 files changed, 399 insertions(+), 168 deletions(-)

-- 
1.8.3

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


[Intel-gfx] [PATCH 01/18] [v2] drm/i915: Comments for semaphore clarification

2013-05-28 Thread Ben Widawsky
Semaphores are tied very closely to the rings in the GPU. Trivial patch
adds comments to the existing code so that when we add new rings we can
include comments there as well. It also helps distinguish the ring to
semaphore mailbox interactions by using the ringname in the semaphore
data structures.

This patch should have no functional impact.

v2: The English parts (as opposed to register names) of the comments
were reversed. (Damien)

Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/i915_reg.h | 12 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.c | 18 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h |  4 ++--
 3 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index dbd9de5..6579d0c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -265,12 +265,12 @@
 #define  MI_SEMAPHORE_UPDATE   (1<<21)
 #define  MI_SEMAPHORE_COMPARE  (1<<20)
 #define  MI_SEMAPHORE_REGISTER (1<<18)
-#define  MI_SEMAPHORE_SYNC_RV  (2<<16)
-#define  MI_SEMAPHORE_SYNC_RB  (0<<16)
-#define  MI_SEMAPHORE_SYNC_VR  (0<<16)
-#define  MI_SEMAPHORE_SYNC_VB  (2<<16)
-#define  MI_SEMAPHORE_SYNC_BR  (2<<16)
-#define  MI_SEMAPHORE_SYNC_BV  (0<<16)
+#define  MI_SEMAPHORE_SYNC_RB  (0<<16) /* BCS wait for RCS  (BRSYNC) */
+#define  MI_SEMAPHORE_SYNC_RV  (2<<16) /* VCS wait for RCS  (VRSYNC) */
+#define  MI_SEMAPHORE_SYNC_VR  (0<<16) /* RCS wait for VCS  (RVSYNC) */
+#define  MI_SEMAPHORE_SYNC_VB  (2<<16) /* BCS wait for VCS  (BVSYNC) */
+#define  MI_SEMAPHORE_SYNC_BV  (0<<16) /* VCS wait for BCS  (VBSYNC) */
+#define  MI_SEMAPHORE_SYNC_BR  (2<<16) /* RCS wait for BCS  (RBSYNC) */
 #define  MI_SEMAPHORE_SYNC_INVALID  (1<<0)
 /*
  * 3D instructions used by the kernel
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 9b97cf6..2d2a362 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1671,9 +1671,9 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
ring->get_seqno = gen6_ring_get_seqno;
ring->set_seqno = ring_set_seqno;
ring->sync_to = gen6_ring_sync;
-   ring->semaphore_register[0] = MI_SEMAPHORE_SYNC_INVALID;
-   ring->semaphore_register[1] = MI_SEMAPHORE_SYNC_RV;
-   ring->semaphore_register[2] = MI_SEMAPHORE_SYNC_RB;
+   ring->semaphore_register[RCS] = MI_SEMAPHORE_SYNC_INVALID;
+   ring->semaphore_register[VCS] = MI_SEMAPHORE_SYNC_RV;
+   ring->semaphore_register[BCS] = MI_SEMAPHORE_SYNC_RB;
ring->signal_mbox[0] = GEN6_VRSYNC;
ring->signal_mbox[1] = GEN6_BRSYNC;
} else if (IS_GEN5(dev)) {
@@ -1830,9 +1830,9 @@ int intel_init_bsd_ring_buffer(struct drm_device *dev)
ring->irq_put = gen6_ring_put_irq;
ring->dispatch_execbuffer = gen6_ring_dispatch_execbuffer;
ring->sync_to = gen6_ring_sync;
-   ring->semaphore_register[0] = MI_SEMAPHORE_SYNC_VR;
-   ring->semaphore_register[1] = MI_SEMAPHORE_SYNC_INVALID;
-   ring->semaphore_register[2] = MI_SEMAPHORE_SYNC_VB;
+   ring->semaphore_register[RCS] = MI_SEMAPHORE_SYNC_VR;
+   ring->semaphore_register[VCS] = MI_SEMAPHORE_SYNC_INVALID;
+   ring->semaphore_register[BCS] = MI_SEMAPHORE_SYNC_VB;
ring->signal_mbox[0] = GEN6_RVSYNC;
ring->signal_mbox[1] = GEN6_BVSYNC;
} else {
@@ -1876,9 +1876,9 @@ int intel_init_blt_ring_buffer(struct drm_device *dev)
ring->irq_put = gen6_ring_put_irq;
ring->dispatch_execbuffer = gen6_ring_dispatch_execbuffer;
ring->sync_to = gen6_ring_sync;
-   ring->semaphore_register[0] = MI_SEMAPHORE_SYNC_BR;
-   ring->semaphore_register[1] = MI_SEMAPHORE_SYNC_BV;
-   ring->semaphore_register[2] = MI_SEMAPHORE_SYNC_INVALID;
+   ring->semaphore_register[RCS] = MI_SEMAPHORE_SYNC_BR;
+   ring->semaphore_register[VCS] = MI_SEMAPHORE_SYNC_BV;
+   ring->semaphore_register[BCS] = MI_SEMAPHORE_SYNC_INVALID;
ring->signal_mbox[0] = GEN6_RBSYNC;
ring->signal_mbox[1] = GEN6_VBSYNC;
ring->init = init_ring_common;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index ef374a8..24268fb 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -105,8 +105,8 @@ struct  intel_ring_buffer {
int (*sync_to)(struct intel_ring_buffer *ring,
   struct intel_ring_buffer *to,
   u32 seqno);
-
-   u32 semaphore_register[3]; /*our mbox written by others */
+   /* our mbox written by others */
+   u32 semaphore_reg

[Intel-gfx] [PATCH 02/18] drm/i915: Semaphore MBOX update generalization

2013-05-28 Thread Ben Widawsky
This replaces the existing MBOX update code with a more generalized
calculation for emitting mbox updates. We also create a sentinel for
doing the updates so we can more abstractly deal with the rings.

When doing MBOX updates the code must be aware of the /other/ rings.
Until now the platforms which supported semaphores had a fixed number of
rings and so it made sense for the code to be very specialized
(hardcoded).

The patch does contain a functional change, but should have no
behavioral changes.

Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/i915_reg.h |  1 +
 drivers/gpu/drm/i915/intel_ringbuffer.c | 43 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.h |  5 +++-
 3 files changed, 34 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6579d0c..19f8e51 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -593,6 +593,7 @@
 #define GEN6_VRSYNC (RING_SYNC_1(GEN6_BSD_RING_BASE))
 #define GEN6_VBSYNC (RING_SYNC_0(GEN6_BSD_RING_BASE))
 #define GEN6_BRSYNC (RING_SYNC_0(BLT_RING_BASE))
+#define GEN6_NOSYNC 0
 #define GEN6_BVSYNC (RING_SYNC_1(BLT_RING_BASE))
 #define RING_MAX_IDLE(base)((base)+0x54)
 #define RING_HWS_PGA(base) ((base)+0x80)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2d2a362..5df1791 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -582,9 +582,16 @@ static void
 update_mboxes(struct intel_ring_buffer *ring,
  u32 mmio_offset)
 {
+/* NB: In order to be able to do semaphore MBOX updates for varying number
+ * of rings, it's easiest if we round up each individual update to a
+ * multiple of 2 (since ring updates must always be a multiple of 2)
+ * even though the actual update only requires 3 dwords.
+ */
+#define MBOX_UPDATE_DWORDS 4
intel_ring_emit(ring, MI_LOAD_REGISTER_IMM(1));
intel_ring_emit(ring, mmio_offset);
intel_ring_emit(ring, ring->outstanding_lazy_request);
+   intel_ring_emit(ring, MI_NOOP);
 }
 
 /**
@@ -599,19 +606,24 @@ update_mboxes(struct intel_ring_buffer *ring,
 static int
 gen6_add_request(struct intel_ring_buffer *ring)
 {
-   u32 mbox1_reg;
-   u32 mbox2_reg;
-   int ret;
+   struct drm_device *dev = ring->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_ring_buffer *useless;
+   int i, ret;
 
-   ret = intel_ring_begin(ring, 10);
+   ret = intel_ring_begin(ring, ((I915_NUM_RINGS-1) *
+ MBOX_UPDATE_DWORDS) +
+ 4);
if (ret)
return ret;
+#undef MBOX_UPDATE_DWORDS
 
-   mbox1_reg = ring->signal_mbox[0];
-   mbox2_reg = ring->signal_mbox[1];
+   for_each_ring(useless, dev_priv, i) {
+   u32 mbox_reg = ring->signal_mbox[i];
+   if (mbox_reg != GEN6_NOSYNC)
+   update_mboxes(ring, mbox_reg);
+   }
 
-   update_mboxes(ring, mbox1_reg);
-   update_mboxes(ring, mbox2_reg);
intel_ring_emit(ring, MI_STORE_DWORD_INDEX);
intel_ring_emit(ring, I915_GEM_HWS_INDEX << MI_STORE_DWORD_INDEX_SHIFT);
intel_ring_emit(ring, ring->outstanding_lazy_request);
@@ -1674,8 +1686,9 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
ring->semaphore_register[RCS] = MI_SEMAPHORE_SYNC_INVALID;
ring->semaphore_register[VCS] = MI_SEMAPHORE_SYNC_RV;
ring->semaphore_register[BCS] = MI_SEMAPHORE_SYNC_RB;
-   ring->signal_mbox[0] = GEN6_VRSYNC;
-   ring->signal_mbox[1] = GEN6_BRSYNC;
+   ring->signal_mbox[RCS] = GEN6_NOSYNC;
+   ring->signal_mbox[VCS] = GEN6_VRSYNC;
+   ring->signal_mbox[BCS] = GEN6_BRSYNC;
} else if (IS_GEN5(dev)) {
ring->add_request = pc_render_add_request;
ring->flush = gen4_render_ring_flush;
@@ -1833,8 +1846,9 @@ int intel_init_bsd_ring_buffer(struct drm_device *dev)
ring->semaphore_register[RCS] = MI_SEMAPHORE_SYNC_VR;
ring->semaphore_register[VCS] = MI_SEMAPHORE_SYNC_INVALID;
ring->semaphore_register[BCS] = MI_SEMAPHORE_SYNC_VB;
-   ring->signal_mbox[0] = GEN6_RVSYNC;
-   ring->signal_mbox[1] = GEN6_BVSYNC;
+   ring->signal_mbox[RCS] = GEN6_RVSYNC;
+   ring->signal_mbox[VCS] = GEN6_NOSYNC;
+   ring->signal_mbox[BCS] = GEN6_BVSYNC;
} else {
ring->mmio_base = BSD_RING_BASE;
ring->flush = bsd_ring_flush;
@@ -1879,8 +1893,9 @@ int intel_init_blt_ring_buffer(struct drm_device *dev)
ring->semaphore_register[RCS] = MI_SEMAPHORE_SYNC_BR;
ring->semaphore_register[VCS] = MI_SEMAPHORE_SYNC_BV;
ring->semaphore_register[BCS] = MI_SEMAP

[Intel-gfx] [PATCH 03/18] drm/i915: Introduce VECS: the 4th ring

2013-05-28 Thread Ben Widawsky
The video enhancement command streamer is a new ring on HSW which does
what it sounds like it does. This patch provides the most minimal
inception of the ring.

In order to support a new ring, we need to bump the number. The patch
may look trivial to the untrained eye, but bumping the number of rings
is a bit scary. As such the patch is not terribly useful by itself, but
a pretty nice place to find issues during a bisection.

Reviewed-by: Damien Lespiau 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 2 ++
 drivers/gpu/drm/i915/intel_ringbuffer.h | 3 ++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 5df1791..ead979a 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -915,6 +915,8 @@ void intel_ring_setup_status_page(struct intel_ring_buffer 
*ring)
case VCS:
mmio = BSD_HWS_PGA_GEN7;
break;
+   case VECS:
+   BUG();
}
} else if (IS_GEN6(ring->dev)) {
mmio = RING_HWS_PGA_GEN6(ring->mmio_base);
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index f55d92e..73619cb 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -47,8 +47,9 @@ struct  intel_ring_buffer {
RCS = 0x0,
VCS,
BCS,
+   VECS,
} id;
-#define I915_NUM_RINGS 3
+#define I915_NUM_RINGS 4
u32 mmio_base;
void__iomem *virtual_start;
struct  drm_device *dev;
-- 
1.8.3

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


[Intel-gfx] [PATCH 04/18] [v2] drm/i915: Add VECS semaphore bits

2013-05-28 Thread Ben Widawsky
Like the other rings, the VECS supports semaphores. The semaphore stuff
is a bit wonky so this patch on it's own should be nice for review.

This patch should have no functional impact.

v2: Fix the English parts of clarification (again, register names were
right, text was reversed) (Damien)
Restore the still valid invariant. (Damien)
The bsd semaphore register should be MI_SEMAPHORE_SYNC_VVE (Damien)

Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/i915_reg.h | 40 ++---
 drivers/gpu/drm/i915/intel_ringbuffer.c |  6 +
 2 files changed, 33 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 19f8e51..41c5d45 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -265,13 +265,19 @@
 #define  MI_SEMAPHORE_UPDATE   (1<<21)
 #define  MI_SEMAPHORE_COMPARE  (1<<20)
 #define  MI_SEMAPHORE_REGISTER (1<<18)
-#define  MI_SEMAPHORE_SYNC_RB  (0<<16) /* BCS wait for RCS  (BRSYNC) */
-#define  MI_SEMAPHORE_SYNC_RV  (2<<16) /* VCS wait for RCS  (VRSYNC) */
-#define  MI_SEMAPHORE_SYNC_VR  (0<<16) /* RCS wait for VCS  (RVSYNC) */
-#define  MI_SEMAPHORE_SYNC_VB  (2<<16) /* BCS wait for VCS  (BVSYNC) */
-#define  MI_SEMAPHORE_SYNC_BV  (0<<16) /* VCS wait for BCS  (VBSYNC) */
-#define  MI_SEMAPHORE_SYNC_BR  (2<<16) /* RCS wait for BCS  (RBSYNC) */
-#define  MI_SEMAPHORE_SYNC_INVALID  (1<<0)
+#define  MI_SEMAPHORE_SYNC_VR  (0<<16) /* RCS  wait for VCS  (RVSYNC) */
+#define  MI_SEMAPHORE_SYNC_VER (1<<16) /* RCS  wait for VECS (RVESYNC) */
+#define  MI_SEMAPHORE_SYNC_BR  (2<<16) /* RCS  wait for BCS  (RBSYNC) */
+#define  MI_SEMAPHORE_SYNC_BV  (0<<16) /* VCS  wait for BCS  (VBSYNC) */
+#define  MI_SEMAPHORE_SYNC_VEV (1<<16) /* VCS  wait for VECS (VVESYNC) */
+#define  MI_SEMAPHORE_SYNC_RV  (2<<16) /* VCS  wait for RCS  (VRSYNC) */
+#define  MI_SEMAPHORE_SYNC_RB  (0<<16) /* BCS  wait for RCS  (BRSYNC) */
+#define  MI_SEMAPHORE_SYNC_VEB (1<<16) /* BCS  wait for VECS (BVESYNC) */
+#define  MI_SEMAPHORE_SYNC_VB  (2<<16) /* BCS  wait for VCS  (BVSYNC) */
+#define  MI_SEMAPHORE_SYNC_BVE (0<<16) /* VECS wait for BCS  (VEBSYNC) */
+#define  MI_SEMAPHORE_SYNC_VVE (1<<16) /* VECS wait for VCS  (VEVSYNC) */
+#define  MI_SEMAPHORE_SYNC_RVE (2<<16) /* VECS wait for RCS  (VERSYNC) */
+#define  MI_SEMAPHORE_SYNC_INVALID  (3<<16)
 /*
  * 3D instructions used by the kernel
  */
@@ -581,6 +587,7 @@
 #define RENDER_RING_BASE   0x02000
 #define BSD_RING_BASE  0x04000
 #define GEN6_BSD_RING_BASE 0x12000
+#define VEBOX_RING_BASE0x1a000
 #define BLT_RING_BASE  0x22000
 #define RING_TAIL(base)((base)+0x30)
 #define RING_HEAD(base)((base)+0x34)
@@ -588,13 +595,20 @@
 #define RING_CTL(base) ((base)+0x3c)
 #define RING_SYNC_0(base)  ((base)+0x40)
 #define RING_SYNC_1(base)  ((base)+0x44)
-#define GEN6_RVSYNC (RING_SYNC_0(RENDER_RING_BASE))
-#define GEN6_RBSYNC (RING_SYNC_1(RENDER_RING_BASE))
-#define GEN6_VRSYNC (RING_SYNC_1(GEN6_BSD_RING_BASE))
-#define GEN6_VBSYNC (RING_SYNC_0(GEN6_BSD_RING_BASE))
-#define GEN6_BRSYNC (RING_SYNC_0(BLT_RING_BASE))
+#define RING_SYNC_2(base)  ((base)+0x48)
+#define GEN6_RVSYNC(RING_SYNC_0(RENDER_RING_BASE))
+#define GEN6_RBSYNC(RING_SYNC_1(RENDER_RING_BASE))
+#define GEN6_RVESYNC   (RING_SYNC_2(RENDER_RING_BASE))
+#define GEN6_VBSYNC(RING_SYNC_0(GEN6_BSD_RING_BASE))
+#define GEN6_VRSYNC(RING_SYNC_1(GEN6_BSD_RING_BASE))
+#define GEN6_VVESYNC   (RING_SYNC_2(GEN6_BSD_RING_BASE))
+#define GEN6_BRSYNC(RING_SYNC_0(BLT_RING_BASE))
+#define GEN6_BVSYNC(RING_SYNC_1(BLT_RING_BASE))
+#define GEN6_BVESYNC   (RING_SYNC_2(BLT_RING_BASE))
+#define GEN6_VEBSYNC   (RING_SYNC_0(VEBOX_RING_BASE))
+#define GEN6_VERSYNC   (RING_SYNC_1(VEBOX_RING_BASE))
+#define GEN6_VEVSYNC   (RING_SYNC_2(VEBOX_RING_BASE))
 #define GEN6_NOSYNC 0
-#define GEN6_BVSYNC (RING_SYNC_1(BLT_RING_BASE))
 #define RING_MAX_IDLE(base)((base)+0x54)
 #define RING_HWS_PGA(base) ((base)+0x80)
 #define RING_HWS_PGA_GEN6(base)((base)+0x2080)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index ead979a..93ccd1e 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1688,9 +1688,11 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
ring->semaphore_register[RCS] = MI_SEMAPHORE_SYNC_INVALID;
ring->semaphore_register[VCS] = MI_SEMAPHORE_SYNC_RV;
ring->semaphore_register[BCS] = MI_SEMAPHORE_SYNC_RB;
+   ring->semaphore_register[VECS] = MI_SEMAPHORE_SYNC_RVE;
ring->signal_mbox[RCS] = GEN6_NOSYNC;
ring->signal_mbox[VCS] = GEN6_VRSYNC;
ring->signal_mbox[BCS] = GEN6_BRSYNC;
+   ring->signal_mbox[VECS] = GEN6_VERSY

[Intel-gfx] [PATCH 14/18] [v2] drm/i915: vebox interrupt get/put

2013-05-28 Thread Ben Widawsky
v2: Use the correct lock to protect PM interrupt regs, this was
accidentally lost from earlier (Haihao)
Fix return types (Ben)

Reviewed-by: Damien Lespiau 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 46 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h |  5 ++--
 2 files changed, 47 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 5ab8cc2..8a6a0ee 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1019,6 +1019,48 @@ gen6_ring_put_irq(struct intel_ring_buffer *ring)
gen6_gt_force_wake_put(dev_priv);
 }
 
+static bool
+hsw_vebox_get_irq(struct intel_ring_buffer *ring)
+{
+   struct drm_device *dev = ring->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   unsigned long flags;
+
+   if (!dev->irq_enabled)
+   return false;
+
+   spin_lock_irqsave(&dev_priv->rps.lock, flags);
+   if (ring->irq_refcount.pm++ == 0) {
+   u32 pm_imr = I915_READ(GEN6_PMIMR);
+   I915_WRITE_IMR(ring, ~ring->irq_enable_mask);
+   I915_WRITE(GEN6_PMIMR, pm_imr & ~ring->irq_enable_mask);
+   POSTING_READ(GEN6_PMIMR);
+   }
+   spin_unlock_irqrestore(&dev_priv->rps.lock, flags);
+
+   return true;
+}
+
+static void
+hsw_vebox_put_irq(struct intel_ring_buffer *ring)
+{
+   struct drm_device *dev = ring->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   unsigned long flags;
+
+   if (!dev->irq_enabled)
+   return;
+
+   spin_lock_irqsave(&dev_priv->rps.lock, flags);
+   if (--ring->irq_refcount.pm == 0) {
+   u32 pm_imr = I915_READ(GEN6_PMIMR);
+   I915_WRITE_IMR(ring, ~0);
+   I915_WRITE(GEN6_PMIMR, pm_imr | ring->irq_enable_mask);
+   POSTING_READ(GEN6_PMIMR);
+   }
+   spin_unlock_irqrestore(&dev_priv->rps.lock, flags);
+}
+
 static int
 i965_dispatch_execbuffer(struct intel_ring_buffer *ring,
 u32 offset, u32 length,
@@ -1928,8 +1970,8 @@ int intel_init_vebox_ring_buffer(struct drm_device *dev)
ring->get_seqno = gen6_ring_get_seqno;
ring->set_seqno = ring_set_seqno;
ring->irq_enable_mask = 0;
-   ring->irq_get = NULL;
-   ring->irq_put = NULL;
+   ring->irq_get = hsw_vebox_get_irq;
+   ring->irq_put = hsw_vebox_put_irq;
ring->dispatch_execbuffer = gen6_ring_dispatch_execbuffer;
ring->sync_to = gen6_ring_sync;
ring->semaphore_register[RCS] = MI_SEMAPHORE_SYNC_VER;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 153b87f..022d07e 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -73,8 +73,9 @@ struct  intel_ring_buffer {
u32 last_retired_head;
 
struct {
-   u32 gt;
-   } irq_refcount; /* protected by dev_priv->irq_lock */
+   u32 gt; /*  protected by dev_priv->irq_lock */
+   u32 pm; /*  protected by dev_priv->rps.lock (sucks) */
+   } irq_refcount;
u32 irq_enable_mask;/* bitmask to enable ring 
interrupt */
u32 trace_irq_seqno;
u32 sync_seqno[I915_NUM_RINGS-1];
-- 
1.8.3

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


[Intel-gfx] [PATCH 08/18] drm/i915: Create a more generic pm handler for hsw+

2013-05-28 Thread Ben Widawsky
HSW has some special requirements for the VEBOX. Splitting out the
interrupt handler will make the code a bit nicer and less error prone
when we begin to handle those.

The slight functional change in this patch (queueing work while holding
the spinlock) is intentional as it makes a subsequent patch a bit nicer.
The change should also only effect HSW platforms.

Reviewed-by: Damien Lespiau 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/i915_irq.c | 30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 557acd3..c7b51c2 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -842,6 +842,7 @@ static void snb_gt_irq_handler(struct drm_device *dev,
ivybridge_handle_parity_error(dev);
 }
 
+/* Legacy way of handling PM interrupts */
 static void gen6_queue_rps_work(struct drm_i915_private *dev_priv,
u32 pm_iir)
 {
@@ -921,6 +922,31 @@ static void dp_aux_irq_handler(struct drm_device *dev)
wake_up_all(&dev_priv->gmbus_wait_queue);
 }
 
+/* Unlike gen6_queue_rps_work() from which this function is originally derived,
+ * we must be able to deal with other PM interrupts. This is complicated 
because
+ * of the way in which we use the masks to defer the RPS work (which for
+ * posterity is necessary because of forcewake).
+ */
+static void hsw_pm_irq_handler(struct drm_i915_private *dev_priv,
+  u32 pm_iir)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(&dev_priv->rps.lock, flags);
+   dev_priv->rps.pm_iir |= pm_iir & GEN6_PM_DEFERRED_EVENTS;
+   if (dev_priv->rps.pm_iir) {
+   I915_WRITE(GEN6_PMIMR, dev_priv->rps.pm_iir);
+   /* never want to mask useful interrupts. (also posting read) */
+   WARN_ON(I915_READ_NOTRACE(GEN6_PMIMR) & 
~GEN6_PM_DEFERRED_EVENTS);
+   /* TODO: if queue_work is slow, move it out of the spinlock */
+   queue_work(dev_priv->wq, &dev_priv->rps.work);
+   }
+   spin_unlock_irqrestore(&dev_priv->rps.lock, flags);
+
+   if (pm_iir & ~GEN6_PM_DEFERRED_EVENTS)
+   DRM_ERROR("Unexpected PM interrupted\n");
+}
+
 static irqreturn_t valleyview_irq_handler(int irq, void *arg)
 {
struct drm_device *dev = (struct drm_device *) arg;
@@ -1231,7 +1257,9 @@ static irqreturn_t ivybridge_irq_handler(int irq, void 
*arg)
 
pm_iir = I915_READ(GEN6_PMIIR);
if (pm_iir) {
-   if (pm_iir & GEN6_PM_DEFERRED_EVENTS)
+   if (IS_HASWELL(dev))
+   hsw_pm_irq_handler(dev_priv, pm_iir);
+   else if (pm_iir & GEN6_PM_DEFERRED_EVENTS)
gen6_queue_rps_work(dev_priv, pm_iir);
I915_WRITE(GEN6_PMIIR, pm_iir);
ret = IRQ_HANDLED;
-- 
1.8.3

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


[Intel-gfx] [PATCH 09/18] [v2] drm/i915: Create an ivybridge_irq_preinstall

2013-05-28 Thread Ben Widawsky
v2: Add new PCH_NOP check (Damien)
Add SDEIMR comment (Damien)

Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/i915_irq.c | 33 -
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c7b51c2..9143452 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2491,6 +2491,37 @@ static void ironlake_irq_preinstall(struct drm_device 
*dev)
I915_WRITE(GTIER, 0x0);
POSTING_READ(GTIER);
 
+   /* south display irq */
+   I915_WRITE(SDEIMR, 0x);
+   /*
+* SDEIER is also touched by the interrupt handler to work around missed
+* PCH interrupts. Hence we can't update it after the interrupt handler
+* is enabled - instead we unconditionally enable all PCH interrupt
+* sources here, but then only unmask them as needed with SDEIMR.
+*/
+   I915_WRITE(SDEIER, 0x);
+   POSTING_READ(SDEIER);
+}
+
+static void ivybridge_irq_preinstall(struct drm_device *dev)
+{
+   drm_i915_private_t *dev_priv = (drm_i915_private_t *) dev->dev_private;
+
+   atomic_set(&dev_priv->irq_received, 0);
+
+   I915_WRITE(HWSTAM, 0xeffe);
+
+   /* XXX hotplug from PCH */
+
+   I915_WRITE(DEIMR, 0x);
+   I915_WRITE(DEIER, 0x0);
+   POSTING_READ(DEIER);
+
+   /* and GT */
+   I915_WRITE(GTIMR, 0x);
+   I915_WRITE(GTIER, 0x0);
+   POSTING_READ(GTIER);
+
if (HAS_PCH_NOP(dev))
return;
 
@@ -3496,7 +3527,7 @@ void intel_irq_init(struct drm_device *dev)
} else if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev)) {
/* Share pre & uninstall handlers with ILK/SNB */
dev->driver->irq_handler = ivybridge_irq_handler;
-   dev->driver->irq_preinstall = ironlake_irq_preinstall;
+   dev->driver->irq_preinstall = ivybridge_irq_preinstall;
dev->driver->irq_postinstall = ivybridge_irq_postinstall;
dev->driver->irq_uninstall = ironlake_irq_uninstall;
dev->driver->enable_vblank = ivybridge_enable_vblank;
-- 
1.8.3

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


[Intel-gfx] [PATCH 06/18] drm/i915: add HAS_VEBOX

2013-05-28 Thread Ben Widawsky
From: "Xiang, Haihao" 

The flag will be useful to help share code between IVB, and HSW as the
programming is similar in many places with this as one of the major
differences.

Signed-off-by: Xiang, Haihao 
[Commit message + small fix by]
Reviewed-by: Damien Lespiau 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/i915_drv.c | 2 ++
 drivers/gpu/drm/i915/i915_drv.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b7c3b98..078d284 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -311,6 +311,7 @@ static const struct intel_device_info intel_haswell_d_info 
= {
.is_haswell = 1,
.has_ddi = 1,
.has_fpga_dbg = 1,
+   .has_vebox_ring = 1,
 };
 
 static const struct intel_device_info intel_haswell_m_info = {
@@ -320,6 +321,7 @@ static const struct intel_device_info intel_haswell_m_info 
= {
.has_ddi = 1,
.has_fpga_dbg = 1,
.has_fbc = 1,
+   .has_vebox_ring = 1,
 };
 
 static const struct pci_device_id pciidlist[] = {  /* aka */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c0bbe9a..b6f2968 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -374,6 +374,7 @@ struct drm_i915_gt_funcs {
func(supports_tv) sep \
func(has_bsd_ring) sep \
func(has_blt_ring) sep \
+   func(has_vebox_ring) sep \
func(has_llc) sep \
func(has_ddi) sep \
func(has_fpga_dbg)
@@ -1373,6 +1374,7 @@ struct drm_i915_file_private {
 
 #define HAS_BSD(dev)(INTEL_INFO(dev)->has_bsd_ring)
 #define HAS_BLT(dev)(INTEL_INFO(dev)->has_blt_ring)
+#define HAS_VEBOX(dev)  (INTEL_INFO(dev)->has_vebox_ring)
 #define HAS_LLC(dev)(INTEL_INFO(dev)->has_llc)
 #define I915_NEED_GFX_HWS(dev) (INTEL_INFO(dev)->need_gfx_hws)
 
-- 
1.8.3

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


[Intel-gfx] [PATCH 10/18] [v2] drm/i915: Add PM regs to pre/post install

2013-05-28 Thread Ben Widawsky
At the moment, these values are wiped out anyway by the rps
enable/disable. That will be changed in the next patch though.

v2: Add post install setup to address issue found by Damien in the next
patch.
replaced
WARN_ON(dev_priv->rps.pm_iir != 0);
with rps.pm_iir = 0;

With the v2 of this patch and the deferred pm enabling (which changed
since the original patches) we're now able to get PM interrupts before
we've brought up enabled rps. At this point in boot, we don't want to do
anything about it, so we simply ignore it. Since writing the original
assertion, the code has changed quite a bit, and I believe removing this
assertion is perfectly safe.

Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/i915_irq.c | 10 ++
 drivers/gpu/drm/i915/intel_pm.c |  2 +-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 9143452..9c66fcf 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2522,6 +2522,11 @@ static void ivybridge_irq_preinstall(struct drm_device 
*dev)
I915_WRITE(GTIER, 0x0);
POSTING_READ(GTIER);
 
+   /* Power management */
+   I915_WRITE(GEN6_PMIMR, 0x);
+   I915_WRITE(GEN6_PMIER, 0x0);
+   POSTING_READ(GEN6_PMIER);
+
if (HAS_PCH_NOP(dev))
return;
 
@@ -2710,6 +2715,11 @@ static int ivybridge_irq_postinstall(struct drm_device 
*dev)
I915_WRITE(GTIER, render_irqs);
POSTING_READ(GTIER);
 
+   /* Power management */
+   I915_WRITE(GEN6_PMIMR, ~GEN6_PM_DEFERRED_EVENTS);
+   I915_WRITE(GEN6_PMIER, GEN6_PM_DEFERRED_EVENTS);
+   POSTING_READ(GEN6_PMIMR);
+
ibx_irq_postinstall(dev);
 
return 0;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9328ed9..66750fe 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2818,7 +2818,7 @@ static void gen6_enable_rps(struct drm_device *dev)
/* requires MSI enabled */
I915_WRITE(GEN6_PMIER, GEN6_PM_DEFERRED_EVENTS);
spin_lock_irq(&dev_priv->rps.lock);
-   WARN_ON(dev_priv->rps.pm_iir != 0);
+   dev_priv->rps.pm_iir = 0;
I915_WRITE(GEN6_PMIMR, 0);
spin_unlock_irq(&dev_priv->rps.lock);
/* enable all PM interrupts */
-- 
1.8.3

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


[Intel-gfx] [PATCH 05/18] drm/i915: Rename ring flush functions

2013-05-28 Thread Ben Widawsky
Historically we considered the render ring to have special flush
semantics and everything else to fall under a more general umbrella.
Probably by coincidence more than anything we decided to make the bsd
ring have the default *other* flush. As the new vebox ring exposes, the
bsd ring is actually the weird one. Doing this allows us to call
gen6_ring_flush for the vebox because calling blt_ring_flush would be
weird...

This patch should have no functional change.

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

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 93ccd1e..3022e15 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1565,8 +1565,8 @@ static void gen6_bsd_ring_write_tail(struct 
intel_ring_buffer *ring,
   _MASKED_BIT_DISABLE(GEN6_BSD_SLEEP_MSG_DISABLE));
 }
 
-static int gen6_ring_flush(struct intel_ring_buffer *ring,
-  u32 invalidate, u32 flush)
+static int gen6_bsd_ring_flush(struct intel_ring_buffer *ring,
+  u32 invalidate, u32 flush)
 {
uint32_t cmd;
int ret;
@@ -1637,8 +1637,8 @@ gen6_ring_dispatch_execbuffer(struct intel_ring_buffer 
*ring,
 
 /* Blitter support (SandyBridge+) */
 
-static int blt_ring_flush(struct intel_ring_buffer *ring,
- u32 invalidate, u32 flush)
+static int gen6_ring_flush(struct intel_ring_buffer *ring,
+  u32 invalidate, u32 flush)
 {
uint32_t cmd;
int ret;
@@ -1838,7 +1838,7 @@ int intel_init_bsd_ring_buffer(struct drm_device *dev)
/* gen6 bsd needs a special wa for tail updates */
if (IS_GEN6(dev))
ring->write_tail = gen6_bsd_ring_write_tail;
-   ring->flush = gen6_ring_flush;
+   ring->flush = gen6_bsd_ring_flush;
ring->add_request = gen6_add_request;
ring->get_seqno = gen6_ring_get_seqno;
ring->set_seqno = ring_set_seqno;
@@ -1887,7 +1887,7 @@ int intel_init_blt_ring_buffer(struct drm_device *dev)
 
ring->mmio_base = BLT_RING_BASE;
ring->write_tail = ring_write_tail;
-   ring->flush = blt_ring_flush;
+   ring->flush = gen6_ring_flush;
ring->add_request = gen6_add_request;
ring->get_seqno = gen6_ring_get_seqno;
ring->set_seqno = ring_set_seqno;
-- 
1.8.3

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


[Intel-gfx] [PATCH 11/18] [v5] drm/i915: make PM interrupt writes non-destructive

2013-05-28 Thread Ben Widawsky
PM interrupts have an expanded role on HSW. It helps route the EBOX
interrupts. This patch is necessary to make the existing code which
touches the mask, and enable registers more friendly to other code paths
that also will need these registers.

To be more explicit:
At preinstall all interrupts are masked and disabled. This implies that
preinstall should always happen before any enabling/disabling of RPS or
other interrupts.

The PMIMR is touched by the workqueue, so enable/disable touch IER and
IIR. Similarly, the code currently expects IMR has no use outside of the
RPS related interrupts so they unconditionally set 0, or ~0. We could
use IER in the workqueue, and IMR elsewhere, but since the workqueue
use-case is more transient the existing usage makes sense.

Disable RPS events:
IER := IER & ~GEN6_PM_RPS_EVENTS // Disable RPS related interrupts
IIR := GEN6_PM_RPS_EVENTS // Disable any outstanding interrupts

Enable RPS events:
IER := IER | GEN6_PM_RPS_EVENTS // Enable the RPS related interrupts
IIR := GEN6_PM_RPS_EVENTS // Make sure there were no leftover events
(really shouldn't happen)

v2: Shouldn't destroy PMIIR or PMIMR VEBOX interrupt state in
enable/disable rps functions (Haihao)

v3: Bug found by Chris where we were clearing the wrong bits at rps
disable.
expanded commit message

v4: v3 was based off the wrong branch

v5: Added the setting of PMIMR because of previous patch update

CC: Chris Wilson 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/i915_irq.c | 21 +++--
 drivers/gpu/drm/i915/i915_reg.h |  2 +-
 drivers/gpu/drm/i915/intel_pm.c | 13 +++--
 3 files changed, 19 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 9c66fcf..8da936d 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -700,10 +700,11 @@ static void gen6_pm_rps_work(struct work_struct *work)
pm_iir = dev_priv->rps.pm_iir;
dev_priv->rps.pm_iir = 0;
pm_imr = I915_READ(GEN6_PMIMR);
-   I915_WRITE(GEN6_PMIMR, 0);
+   /* Make sure not to corrupt PMIMR state used by ringbuffer code */
+   I915_WRITE(GEN6_PMIMR, pm_imr & ~GEN6_PM_RPS_EVENTS);
spin_unlock_irq(&dev_priv->rps.lock);
 
-   if ((pm_iir & GEN6_PM_DEFERRED_EVENTS) == 0)
+   if ((pm_iir & GEN6_PM_RPS_EVENTS) == 0)
return;
 
mutex_lock(&dev_priv->rps.hw_lock);
@@ -933,17 +934,17 @@ static void hsw_pm_irq_handler(struct drm_i915_private 
*dev_priv,
unsigned long flags;
 
spin_lock_irqsave(&dev_priv->rps.lock, flags);
-   dev_priv->rps.pm_iir |= pm_iir & GEN6_PM_DEFERRED_EVENTS;
+   dev_priv->rps.pm_iir |= pm_iir & GEN6_PM_RPS_EVENTS;
if (dev_priv->rps.pm_iir) {
I915_WRITE(GEN6_PMIMR, dev_priv->rps.pm_iir);
/* never want to mask useful interrupts. (also posting read) */
-   WARN_ON(I915_READ_NOTRACE(GEN6_PMIMR) & 
~GEN6_PM_DEFERRED_EVENTS);
+   WARN_ON(I915_READ_NOTRACE(GEN6_PMIMR) & ~GEN6_PM_RPS_EVENTS);
/* TODO: if queue_work is slow, move it out of the spinlock */
queue_work(dev_priv->wq, &dev_priv->rps.work);
}
spin_unlock_irqrestore(&dev_priv->rps.lock, flags);
 
-   if (pm_iir & ~GEN6_PM_DEFERRED_EVENTS)
+   if (pm_iir & ~GEN6_PM_RPS_EVENTS)
DRM_ERROR("Unexpected PM interrupted\n");
 }
 
@@ -1018,7 +1019,7 @@ static irqreturn_t valleyview_irq_handler(int irq, void 
*arg)
if (pipe_stats[0] & PIPE_GMBUS_INTERRUPT_STATUS)
gmbus_irq_handler(dev);
 
-   if (pm_iir & GEN6_PM_DEFERRED_EVENTS)
+   if (pm_iir & GEN6_PM_RPS_EVENTS)
gen6_queue_rps_work(dev_priv, pm_iir);
 
I915_WRITE(GTIIR, gt_iir);
@@ -1259,7 +1260,7 @@ static irqreturn_t ivybridge_irq_handler(int irq, void 
*arg)
if (pm_iir) {
if (IS_HASWELL(dev))
hsw_pm_irq_handler(dev_priv, pm_iir);
-   else if (pm_iir & GEN6_PM_DEFERRED_EVENTS)
+   else if (pm_iir & GEN6_PM_RPS_EVENTS)
gen6_queue_rps_work(dev_priv, pm_iir);
I915_WRITE(GEN6_PMIIR, pm_iir);
ret = IRQ_HANDLED;
@@ -1374,7 +1375,7 @@ static irqreturn_t ironlake_irq_handler(int irq, void 
*arg)
if (IS_GEN5(dev) &&  de_iir & DE_PCU_EVENT)
ironlake_handle_rps_change(dev);
 
-   if (IS_GEN6(dev) && pm_iir & GEN6_PM_DEFERRED_EVENTS)
+   if (IS_GEN6(dev) && pm_iir & GEN6_PM_RPS_EVENTS)
gen6_queue_rps_work(dev_priv, pm_iir);
 
I915_WRITE(GTIIR, gt_iir);
@@ -2716,8 +2717,8 @@ static int ivybridge_irq_postinstall(struct drm_device 
*dev)
POSTING_READ(GTIER);
 
/* Power management */
-   I915_WRITE(GEN6_PMIMR, ~GEN6_PM_DEFERRED_EVENTS);
-   I915_WRITE(GEN6_PMIER, GEN6_PM_DEFERRED_EVENTS);
+   I915_W

[Intel-gfx] [PATCH 12/18] drm/i915: Convert irq_refounct to struct

2013-05-28 Thread Ben Widawsky
It's overkill on older gens, but it's useful for newer gens.

Reviewed-by: Damien Lespiau 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/intel_ringbuffer.c | 16 
 drivers/gpu/drm/i915/intel_ringbuffer.h |  4 +++-
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 89dfc63..c7a89bb 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -795,7 +795,7 @@ gen5_ring_get_irq(struct intel_ring_buffer *ring)
return false;
 
spin_lock_irqsave(&dev_priv->irq_lock, flags);
-   if (ring->irq_refcount++ == 0) {
+   if (ring->irq_refcount.gt++ == 0) {
dev_priv->gt_irq_mask &= ~ring->irq_enable_mask;
I915_WRITE(GTIMR, dev_priv->gt_irq_mask);
POSTING_READ(GTIMR);
@@ -813,7 +813,7 @@ gen5_ring_put_irq(struct intel_ring_buffer *ring)
unsigned long flags;
 
spin_lock_irqsave(&dev_priv->irq_lock, flags);
-   if (--ring->irq_refcount == 0) {
+   if (--ring->irq_refcount.gt == 0) {
dev_priv->gt_irq_mask |= ring->irq_enable_mask;
I915_WRITE(GTIMR, dev_priv->gt_irq_mask);
POSTING_READ(GTIMR);
@@ -832,7 +832,7 @@ i9xx_ring_get_irq(struct intel_ring_buffer *ring)
return false;
 
spin_lock_irqsave(&dev_priv->irq_lock, flags);
-   if (ring->irq_refcount++ == 0) {
+   if (ring->irq_refcount.gt++ == 0) {
dev_priv->irq_mask &= ~ring->irq_enable_mask;
I915_WRITE(IMR, dev_priv->irq_mask);
POSTING_READ(IMR);
@@ -850,7 +850,7 @@ i9xx_ring_put_irq(struct intel_ring_buffer *ring)
unsigned long flags;
 
spin_lock_irqsave(&dev_priv->irq_lock, flags);
-   if (--ring->irq_refcount == 0) {
+   if (--ring->irq_refcount.gt == 0) {
dev_priv->irq_mask |= ring->irq_enable_mask;
I915_WRITE(IMR, dev_priv->irq_mask);
POSTING_READ(IMR);
@@ -869,7 +869,7 @@ i8xx_ring_get_irq(struct intel_ring_buffer *ring)
return false;
 
spin_lock_irqsave(&dev_priv->irq_lock, flags);
-   if (ring->irq_refcount++ == 0) {
+   if (ring->irq_refcount.gt++ == 0) {
dev_priv->irq_mask &= ~ring->irq_enable_mask;
I915_WRITE16(IMR, dev_priv->irq_mask);
POSTING_READ16(IMR);
@@ -887,7 +887,7 @@ i8xx_ring_put_irq(struct intel_ring_buffer *ring)
unsigned long flags;
 
spin_lock_irqsave(&dev_priv->irq_lock, flags);
-   if (--ring->irq_refcount == 0) {
+   if (--ring->irq_refcount.gt == 0) {
dev_priv->irq_mask |= ring->irq_enable_mask;
I915_WRITE16(IMR, dev_priv->irq_mask);
POSTING_READ16(IMR);
@@ -980,7 +980,7 @@ gen6_ring_get_irq(struct intel_ring_buffer *ring)
gen6_gt_force_wake_get(dev_priv);
 
spin_lock_irqsave(&dev_priv->irq_lock, flags);
-   if (ring->irq_refcount++ == 0) {
+   if (ring->irq_refcount.gt++ == 0) {
if (HAS_L3_GPU_CACHE(dev) && ring->id == RCS)
I915_WRITE_IMR(ring, ~(ring->irq_enable_mask |
GEN6_RENDER_L3_PARITY_ERROR));
@@ -1003,7 +1003,7 @@ gen6_ring_put_irq(struct intel_ring_buffer *ring)
unsigned long flags;
 
spin_lock_irqsave(&dev_priv->irq_lock, flags);
-   if (--ring->irq_refcount == 0) {
+   if (--ring->irq_refcount.gt == 0) {
if (HAS_L3_GPU_CACHE(dev) && ring->id == RCS)
I915_WRITE_IMR(ring, ~GEN6_RENDER_L3_PARITY_ERROR);
else
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 1c79520..153b87f 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -72,7 +72,9 @@ struct  intel_ring_buffer {
 */
u32 last_retired_head;
 
-   u32 irq_refcount;   /* protected by 
dev_priv->irq_lock */
+   struct {
+   u32 gt;
+   } irq_refcount; /* protected by dev_priv->irq_lock */
u32 irq_enable_mask;/* bitmask to enable ring 
interrupt */
u32 trace_irq_seqno;
u32 sync_seqno[I915_NUM_RINGS-1];
-- 
1.8.3

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


[Intel-gfx] [PATCH 07/18] [v2] drm/i915: Vebox ringbuffer init

2013-05-28 Thread Ben Widawsky
v2: Add set_seqno which didn't exist before rebase (Haihao)

Signed-off-by: Ben Widawsky 
Reviewed-by: Damien Lespiau 
Signed-off-by: Xiang, Haihao 
---
 drivers/gpu/drm/i915/i915_gem.c | 11 ++-
 drivers/gpu/drm/i915/i915_reg.h |  1 +
 drivers/gpu/drm/i915/intel_ringbuffer.c | 35 -
 drivers/gpu/drm/i915/intel_ringbuffer.h |  1 +
 4 files changed, 46 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index adb1c18..e5b6a92 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4010,12 +4010,21 @@ static int i915_gem_init_rings(struct drm_device *dev)
goto cleanup_bsd_ring;
}
 
+   if (HAS_VEBOX(dev)) {
+   ret = intel_init_vebox_ring_buffer(dev);
+   if (ret)
+   goto cleanup_blt_ring;
+   }
+
+
ret = i915_gem_set_seqno(dev, ((u32)~0 - 0x1000));
if (ret)
-   goto cleanup_blt_ring;
+   goto cleanup_vebox_ring;
 
return 0;
 
+cleanup_vebox_ring:
+   intel_cleanup_ring_buffer(&dev_priv->ring[VECS]);
 cleanup_blt_ring:
intel_cleanup_ring_buffer(&dev_priv->ring[BCS]);
 cleanup_bsd_ring:
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 41c5d45..a5717f1 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -620,6 +620,7 @@
 #define DONE_REG   0x40b0
 #define BSD_HWS_PGA_GEN7   (0x04180)
 #define BLT_HWS_PGA_GEN7   (0x04280)
+#define VEBOX_HWS_PGA_GEN7 (0x04380)
 #define RING_ACTHD(base)   ((base)+0x74)
 #define RING_NOPID(base)   ((base)+0x94)
 #define RING_IMR(base) ((base)+0xa8)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 3022e15..89dfc63 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -916,7 +916,8 @@ void intel_ring_setup_status_page(struct intel_ring_buffer 
*ring)
mmio = BSD_HWS_PGA_GEN7;
break;
case VECS:
-   BUG();
+   mmio = VEBOX_HWS_PGA_GEN7;
+   break;
}
} else if (IS_GEN6(ring->dev)) {
mmio = RING_HWS_PGA_GEN6(ring->mmio_base);
@@ -1909,6 +1910,38 @@ int intel_init_blt_ring_buffer(struct drm_device *dev)
return intel_init_ring_buffer(dev, ring);
 }
 
+int intel_init_vebox_ring_buffer(struct drm_device *dev)
+{
+   drm_i915_private_t *dev_priv = dev->dev_private;
+   struct intel_ring_buffer *ring = &dev_priv->ring[VECS];
+
+   ring->name = "video enhancement ring";
+   ring->id = VECS;
+
+   ring->mmio_base = VEBOX_RING_BASE;
+   ring->write_tail = ring_write_tail;
+   ring->flush = gen6_ring_flush;
+   ring->add_request = gen6_add_request;
+   ring->get_seqno = gen6_ring_get_seqno;
+   ring->set_seqno = ring_set_seqno;
+   ring->irq_enable_mask = 0;
+   ring->irq_get = NULL;
+   ring->irq_put = NULL;
+   ring->dispatch_execbuffer = gen6_ring_dispatch_execbuffer;
+   ring->sync_to = gen6_ring_sync;
+   ring->semaphore_register[RCS] = MI_SEMAPHORE_SYNC_VER;
+   ring->semaphore_register[VCS] = MI_SEMAPHORE_SYNC_VEV;
+   ring->semaphore_register[BCS] = MI_SEMAPHORE_SYNC_VEB;
+   ring->semaphore_register[VECS] = MI_SEMAPHORE_SYNC_INVALID;
+   ring->signal_mbox[RCS] = GEN6_RVESYNC;
+   ring->signal_mbox[VCS] = GEN6_VVESYNC;
+   ring->signal_mbox[BCS] = GEN6_BVESYNC;
+   ring->signal_mbox[VECS] = GEN6_NOSYNC;
+   ring->init = init_ring_common;
+
+   return intel_init_ring_buffer(dev, ring);
+}
+
 int
 intel_ring_flush_all_caches(struct intel_ring_buffer *ring)
 {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 73619cb..1c79520 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -234,6 +234,7 @@ int intel_ring_invalidate_all_caches(struct 
intel_ring_buffer *ring);
 int intel_init_render_ring_buffer(struct drm_device *dev);
 int intel_init_bsd_ring_buffer(struct drm_device *dev);
 int intel_init_blt_ring_buffer(struct drm_device *dev);
+int intel_init_vebox_ring_buffer(struct drm_device *dev);
 
 u32 intel_ring_get_active_head(struct intel_ring_buffer *ring);
 void intel_ring_setup_status_page(struct intel_ring_buffer *ring);
-- 
1.8.3

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


[Intel-gfx] [PATCH 13/18] [v2] drm/i915: consolidate interrupt naming scheme

2013-05-28 Thread Ben Widawsky
The motivation here is we're going to add some new interrupt definitions
and handling outside of the GT interrupts which is all we've managed so
far (with some RPS exceptions). By consolidating the names in the future
we can make thing a bit cleaner as we don't need to define register
names twice, and we can leverage pretty decent overlap in HW registers
since ILK.

To explain briefly what is in the comments: there are two sets of
interrupt masking/enabling registers. At least so far, the definitions
of the two sets overlap. The old code setup distinct names for
interrupts in each set, ie. one for global, and one for ring. This made
things confusing when using the wrong defines in the wrong places.

rebase: Modified VLV bits

v2: Renamed GT_RENDER_MASTER to GT_RENDER_CS_MASTER (Damien)

Reviewed-by: Damien Lespiau 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/i915_irq.c |  61 ++-
 drivers/gpu/drm/i915/i915_reg.h | 101 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.c |  21 ---
 3 files changed, 85 insertions(+), 98 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 8da936d..4f7a12f 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -780,7 +780,7 @@ static void ivybridge_parity_work(struct work_struct *work)
I915_WRITE(GEN7_MISCCPCTL, misccpctl);
 
spin_lock_irqsave(&dev_priv->irq_lock, flags);
-   dev_priv->gt_irq_mask &= ~GT_GEN7_L3_PARITY_ERROR_INTERRUPT;
+   dev_priv->gt_irq_mask &= ~GT_RENDER_L3_PARITY_ERROR_INTERRUPT;
I915_WRITE(GTIMR, dev_priv->gt_irq_mask);
spin_unlock_irqrestore(&dev_priv->irq_lock, flags);
 
@@ -812,7 +812,7 @@ static void ivybridge_handle_parity_error(struct drm_device 
*dev)
return;
 
spin_lock_irqsave(&dev_priv->irq_lock, flags);
-   dev_priv->gt_irq_mask |= GT_GEN7_L3_PARITY_ERROR_INTERRUPT;
+   dev_priv->gt_irq_mask |= GT_RENDER_L3_PARITY_ERROR_INTERRUPT;
I915_WRITE(GTIMR, dev_priv->gt_irq_mask);
spin_unlock_irqrestore(&dev_priv->irq_lock, flags);
 
@@ -824,22 +824,22 @@ static void snb_gt_irq_handler(struct drm_device *dev,
   u32 gt_iir)
 {
 
-   if (gt_iir & (GEN6_RENDER_USER_INTERRUPT |
- GEN6_RENDER_PIPE_CONTROL_NOTIFY_INTERRUPT))
+   if (gt_iir &
+   (GT_RENDER_USER_INTERRUPT | GT_RENDER_PIPECTL_NOTIFY_INTERRUPT))
notify_ring(dev, &dev_priv->ring[RCS]);
-   if (gt_iir & GEN6_BSD_USER_INTERRUPT)
+   if (gt_iir & GT_BSD_USER_INTERRUPT)
notify_ring(dev, &dev_priv->ring[VCS]);
-   if (gt_iir & GEN6_BLITTER_USER_INTERRUPT)
+   if (gt_iir & GT_BLT_USER_INTERRUPT)
notify_ring(dev, &dev_priv->ring[BCS]);
 
-   if (gt_iir & (GT_GEN6_BLT_CS_ERROR_INTERRUPT |
- GT_GEN6_BSD_CS_ERROR_INTERRUPT |
- GT_RENDER_CS_ERROR_INTERRUPT)) {
+   if (gt_iir & (GT_BLT_CS_ERROR_INTERRUPT |
+ GT_BSD_CS_ERROR_INTERRUPT |
+ GT_RENDER_CS_MASTER_ERROR_INTERRUPT)) {
DRM_ERROR("GT error interrupt 0x%08x\n", gt_iir);
i915_handle_error(dev, false);
}
 
-   if (gt_iir & GT_GEN7_L3_PARITY_ERROR_INTERRUPT)
+   if (gt_iir & GT_RENDER_L3_PARITY_ERROR_INTERRUPT)
ivybridge_handle_parity_error(dev);
 }
 
@@ -1283,9 +1283,10 @@ static void ilk_gt_irq_handler(struct drm_device *dev,
   struct drm_i915_private *dev_priv,
   u32 gt_iir)
 {
-   if (gt_iir & (GT_USER_INTERRUPT | GT_PIPE_NOTIFY))
+   if (gt_iir &
+   (GT_RENDER_USER_INTERRUPT | GT_RENDER_PIPECTL_NOTIFY_INTERRUPT))
notify_ring(dev, &dev_priv->ring[RCS]);
-   if (gt_iir & GT_BSD_USER_INTERRUPT)
+   if (gt_iir & ILK_BSD_USER_INTERRUPT)
notify_ring(dev, &dev_priv->ring[VCS]);
 }
 
@@ -2640,7 +2641,7 @@ static int ironlake_irq_postinstall(struct drm_device 
*dev)
   DE_PLANEA_FLIP_DONE | DE_PLANEB_FLIP_DONE |
   DE_AUX_CHANNEL_A | DE_PIPEB_FIFO_UNDERRUN |
   DE_PIPEA_FIFO_UNDERRUN | DE_POISON;
-   u32 render_irqs;
+   u32 gt_irqs;
 
dev_priv->irq_mask = ~display_mask;
 
@@ -2655,17 +2656,15 @@ static int ironlake_irq_postinstall(struct drm_device 
*dev)
I915_WRITE(GTIIR, I915_READ(GTIIR));
I915_WRITE(GTIMR, dev_priv->gt_irq_mask);
 
+   gt_irqs = GT_RENDER_USER_INTERRUPT;
+
if (IS_GEN6(dev))
-   render_irqs =
-   GT_USER_INTERRUPT |
-   GEN6_BSD_USER_INTERRUPT |
-   GEN6_BLITTER_USER_INTERRUPT;
+   gt_irqs |= GT_BLT_USER_INTERRUPT | GT_BSD_USER_INTERRUPT;
else
-   render_irqs =
-   GT_USER_INTERRUPT |
-

[Intel-gfx] [PATCH 17/18] drm/i915: add I915_EXEC_VEBOX to i915_gem_do_execbuffer()

2013-05-28 Thread Ben Widawsky
From: "Xiang, Haihao" 

A user can run batchbuffer via VEBOX ring.

Signed-off-by: Xiang, Haihao 
Reviewed-by: Damien Lespiau 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 9 +
 include/uapi/drm/i915_drm.h| 1 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c 
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 117ce38..a8bb62c 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -885,6 +885,15 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
return -EPERM;
}
break;
+   case I915_EXEC_VEBOX:
+   ring = &dev_priv->ring[VECS];
+   if (ctx_id != 0) {
+   DRM_DEBUG("Ring %s doesn't support contexts\n",
+ ring->name);
+   return -EPERM;
+   }
+   break;
+
default:
DRM_DEBUG("execbuf with unknown ring: %d\n",
  (int)(args->flags & I915_EXEC_RING_MASK));
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 07d5941..81b9981 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -660,6 +660,7 @@ struct drm_i915_gem_execbuffer2 {
 #define I915_EXEC_RENDER (1<<0)
 #define I915_EXEC_BSD(2<<0)
 #define I915_EXEC_BLT(3<<0)
+#define I915_EXEC_VEBOX  (4<<0)
 
 /* Used for switching the constants addressing mode on gen4+ RENDER ring.
  * Gen6+ only supports relative addressing to dynamic state (default) and
-- 
1.8.3

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


[Intel-gfx] [PATCH 16/18] [v2] drm/i915: add VEBOX into debugfs

2013-05-28 Thread Ben Widawsky
From: "Xiang, Haihao" 

v2: Removed rebase relic VECS ring from i915_gem_request_info (Damien)

Signed-off-by: Xiang, Haihao 
[Order changed, and modified by]
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2eb572a..5bbfc10 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -570,6 +570,7 @@ static const char *ring_str(int ring)
case RCS: return "render";
case VCS: return "bsd";
case BCS: return "blt";
+   case VECS: return "vebox";
default: return "";
}
 }
@@ -,6 +2223,7 @@ static struct drm_info_list i915_debugfs_list[] = {
{"i915_gem_hws", i915_hws_info, 0, (void *)RCS},
{"i915_gem_hws_blt", i915_hws_info, 0, (void *)BCS},
{"i915_gem_hws_bsd", i915_hws_info, 0, (void *)VCS},
+   {"i915_gem_hsw_vebox", i915_hws_info, 0, (void *)VECS},
{"i915_rstdby_delays", i915_rstdby_delays, 0},
{"i915_cur_delayinfo", i915_cur_delayinfo, 0},
{"i915_delayfreq_table", i915_delayfreq_table, 0},
-- 
1.8.3

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


[Intel-gfx] [PATCH 18/18] drm/i915: add I915_PARAM_HAS_VEBOX to i915_getparam

2013-05-28 Thread Ben Widawsky
From: "Xiang, Haihao" 

This will let userland only try to use the new ring
when the appropriate kernel is present

Signed-off-by: Xiang, Haihao 
Reviewed-by: Damien Lespiau 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/i915_dma.c | 3 +++
 include/uapi/drm/i915_drm.h | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 3cd2b60..03ee193 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -956,6 +956,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
case I915_PARAM_HAS_BLT:
value = intel_ring_initialized(&dev_priv->ring[BCS]);
break;
+   case I915_PARAM_HAS_VEBOX:
+   value = intel_ring_initialized(&dev_priv->ring[VECS]);
+   break;
case I915_PARAM_HAS_RELAXED_FENCING:
value = 1;
break;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 81b9981..923ed7f 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -305,7 +305,7 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_HAS_WAIT_TIMEOUT 19
 #define I915_PARAM_HAS_SEMAPHORES   20
 #define I915_PARAM_HAS_PRIME_VMAP_FLUSH 21
-#define I915_PARAM_RSVD_FOR_FUTURE_USE  22
+#define I915_PARAM_HAS_VEBOX22
 #define I915_PARAM_HAS_SECURE_BATCHES   23
 #define I915_PARAM_HAS_PINNED_BATCHES   24
 #define I915_PARAM_HAS_EXEC_NO_RELOC25
-- 
1.8.3

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


[Intel-gfx] [PATCH 15/18] [v3] drm/i915: Enable vebox interrupts

2013-05-28 Thread Ben Widawsky
Similar to a patch originally written by:

v2: Reversed the meanings of masked and enabled (Haihao)
Made non-destructive writes in case enable/disabler rps runs first
(Haihao)

v3: Reword error message (Damien)
Modify postinstall to do the right thing based on previous fixup. (Ben)

CC: Xiang, Haihao 
Reviewed-by: Damien Lespiau 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/i915_irq.c | 31 +--
 drivers/gpu/drm/i915/i915_reg.h |  3 +++
 drivers/gpu/drm/i915/intel_ringbuffer.c |  3 ++-
 3 files changed, 30 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 4f7a12f..560465d 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -944,8 +944,15 @@ static void hsw_pm_irq_handler(struct drm_i915_private 
*dev_priv,
}
spin_unlock_irqrestore(&dev_priv->rps.lock, flags);
 
-   if (pm_iir & ~GEN6_PM_RPS_EVENTS)
-   DRM_ERROR("Unexpected PM interrupted\n");
+   if (pm_iir & ~GEN6_PM_RPS_EVENTS) {
+   if (pm_iir & PM_VEBOX_USER_INTERRUPT)
+   notify_ring(dev_priv->dev, &dev_priv->ring[VECS]);
+
+   if (pm_iir & PM_VEBOX_CS_ERROR_INTERRUPT) {
+   DRM_ERROR("VEBOX CS error interrupt 0x%08x\n", pm_iir);
+   i915_handle_error(dev_priv->dev, false);
+   }
+   }
 }
 
 static irqreturn_t valleyview_irq_handler(int irq, void *arg)
@@ -2690,6 +2697,7 @@ static int ivybridge_irq_postinstall(struct drm_device 
*dev)
DE_PLANEA_FLIP_DONE_IVB |
DE_AUX_CHANNEL_A_IVB |
DE_ERR_INT_IVB;
+   u32 pm_irqs = GEN6_PM_RPS_EVENTS;
u32 gt_irqs;
 
dev_priv->irq_mask = ~display_mask;
@@ -2715,10 +2723,21 @@ static int ivybridge_irq_postinstall(struct drm_device 
*dev)
I915_WRITE(GTIER, gt_irqs);
POSTING_READ(GTIER);
 
-   /* Power management */
-   I915_WRITE(GEN6_PMIMR, ~GEN6_PM_RPS_EVENTS);
-   I915_WRITE(GEN6_PMIER, GEN6_PM_RPS_EVENTS);
-   POSTING_READ(GEN6_PMIMR);
+   I915_WRITE(GEN6_PMIIR, I915_READ(GEN6_PMIIR));
+   if (HAS_VEBOX(dev))
+   pm_irqs |= PM_VEBOX_USER_INTERRUPT |
+   PM_VEBOX_CS_ERROR_INTERRUPT;
+
+   /* Our enable/disable rps functions may touch these registers so
+* make sure to set a known state for only the non-RPS bits.
+* The RMW is extra paranoia since this should be called after being set
+* to a known state in preinstall.
+* */
+   I915_WRITE(GEN6_PMIMR,
+  (I915_READ(GEN6_PMIMR) | ~GEN6_PM_RPS_EVENTS) & ~pm_irqs);
+   I915_WRITE(GEN6_PMIER,
+  (I915_READ(GEN6_PMIER) & GEN6_PM_RPS_EVENTS) | pm_irqs);
+   POSTING_READ(GEN6_PMIER);
 
ibx_irq_postinstall(dev);
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b740f0d..73348ba 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -886,6 +886,9 @@
 #define GT_RENDER_DEBUG_INTERRUPT  (1 <<  1)
 #define GT_RENDER_USER_INTERRUPT   (1 <<  0)
 
+#define PM_VEBOX_CS_ERROR_INTERRUPT(1 << 12) /* hsw+ */
+#define PM_VEBOX_USER_INTERRUPT(1 << 10) /* hsw+ */
+
 /* These are all the "old" interrupts */
 #define ILK_BSD_USER_INTERRUPT (1<<5)
 #define I915_PIPE_CONTROL_NOTIFY_INTERRUPT (1<<18)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 8a6a0ee..0e72da6 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1969,7 +1969,8 @@ int intel_init_vebox_ring_buffer(struct drm_device *dev)
ring->add_request = gen6_add_request;
ring->get_seqno = gen6_ring_get_seqno;
ring->set_seqno = ring_set_seqno;
-   ring->irq_enable_mask = 0;
+   ring->irq_enable_mask = PM_VEBOX_USER_INTERRUPT |
+   PM_VEBOX_CS_ERROR_INTERRUPT;
ring->irq_get = hsw_vebox_get_irq;
ring->irq_put = hsw_vebox_put_irq;
ring->dispatch_execbuffer = gen6_ring_dispatch_execbuffer;
-- 
1.8.3

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


[Intel-gfx] [PATCH 14.5/34] drm/i915: Unify PPGTT codepaths on gen6+

2013-05-28 Thread Ben Widawsky
This will allow us to use the same code paths whether or not we have
PPGTT actually turned on. It will do all but actually enable the bits
that tell the HW to use PPGTT.

This patch also will help tie together contexts and PPGTT in the next
patch. That patch wants to disable contexts if there is no PPGTT, and we
disable PPGTT on gen6 with VT-D. Since Mesa depends on gen6+ having HW
contexts, this is a requirement.

Just compiled tested for now, I'll do more testing on it if the relevant
parties find it swallowable.

Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/i915_dma.c | 3 ++-
 drivers/gpu/drm/i915/i915_gem.c | 6 +-
 drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++-
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 3ae8298..ad7f3ce 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -975,7 +975,8 @@ static int i915_getparam(struct drm_device *dev, void *data,
value = HAS_LLC(dev);
break;
case I915_PARAM_HAS_ALIASING_PPGTT:
-   value = dev_priv->mm.aliasing_ppgtt ? 1 : 0;
+   if (intel_enable_ppgtt(dev) && dev_priv->mm.aliasing_ppgtt)
+   value = 1;
break;
case I915_PARAM_HAS_WAIT_TIMEOUT:
value = 1;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fc35447..42beb50 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4072,7 +4072,11 @@ int i915_gem_init(struct drm_device *dev)
DRM_DEBUG_DRIVER("allow wake ack timed out\n");
}
 
-   if (intel_enable_ppgtt(dev) && HAS_ALIASING_PPGTT(dev)) {
+   /* NB: In order to keep the code paths for all platforms with PPGTT the
+* same, we run through this next section regardless, but don't actually
+* enable the PPGTT via GFX_MODE.
+*/
+   if (HAS_ALIASING_PPGTT(dev)) {
struct i915_hw_ppgtt *ppgtt;
 
i915_gem_setup_global_gtt(dev, 0, dev_priv->gtt.mappable_end,
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index a126955..d1a41f7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -154,7 +154,8 @@ static int gen6_ppgtt_enable(struct drm_device *dev)
ecochk = I915_READ(GAM_ECOCHK);
I915_WRITE(GAM_ECOCHK, ecochk | ECOCHK_SNB_BIT |
   ECOCHK_PPGTT_CACHE64B);
-   I915_WRITE(GFX_MODE, _MASKED_BIT_ENABLE(GFX_PPGTT_ENABLE));
+   if (intel_enable_ppgtt(dev))
+   I915_WRITE(GFX_MODE, 
_MASKED_BIT_ENABLE(GFX_PPGTT_ENABLE));
} else if (INTEL_INFO(dev)->gen >= 7) {
uint32_t ecochk, ecobits;
 
-- 
1.8.3

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