Re: [Intel-gfx] [PATCH] drm/i915/pmu: Fix sysfs exported counter config

2018-01-23 Thread Chris Wilson 
Quoting Tvrtko Ursulin (2018-01-23 13:45:58)
> From: Tvrtko Ursulin 
> 
> We need to generate the event config value using the uAPI class and not
> the driver internal one.
> 
> Signed-off-by: Tvrtko Ursulin 
> Fixes: 109ec558370f ("drm/i915/pmu: Only enumerate available counters in 
> sysfs")
> Cc: Tvrtko Ursulin 
> Cc: Chris Wilson 
> Cc: Jani Nikula 
> Cc: Joonas Lahtinen 
> Cc: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/i915_pmu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
> index 86d9b9fb6aef..f380d8896a63 100644
> --- a/drivers/gpu/drm/i915/i915_pmu.c
> +++ b/drivers/gpu/drm/i915/i915_pmu.c
> @@ -906,7 +906,7 @@ create_event_attributes(struct drm_i915_private *i915)
> *attr_iter++ = _iter->attr.attr;
> i915_iter =
> add_i915_attr(i915_iter, str,
> - __I915_PMU_ENGINE(engine->class,
> + 
> __I915_PMU_ENGINE(engine->uabi_class,

Indeed. __I915_PMU_ENGINE() is uapi/i915_drm.h so uabi-centric.
Reviewed-by: Chris Wilson 
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/pmu: Fix sysfs exported counter config

2018-01-23 Thread Tvrtko Ursulin 
From: Tvrtko Ursulin 

We need to generate the event config value using the uAPI class and not
the driver internal one.

Signed-off-by: Tvrtko Ursulin 
Fixes: 109ec558370f ("drm/i915/pmu: Only enumerate available counters in sysfs")
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_pmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 86d9b9fb6aef..f380d8896a63 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -906,7 +906,7 @@ create_event_attributes(struct drm_i915_private *i915)
*attr_iter++ = _iter->attr.attr;
i915_iter =
add_i915_attr(i915_iter, str,
- __I915_PMU_ENGINE(engine->class,
+ 
__I915_PMU_ENGINE(engine->uabi_class,

engine->instance,

engine_events[i].sample));
 
-- 
2.14.1

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

Re: [Intel-gfx] [PATCH 03/16] drm/i915/skl+: add NV12 in skl_format_to_fourcc

2018-01-23 Thread Mika Kahola 
On Mon, 2018-01-22 at 17:33 +0530, Vidya Srinivas wrote:
> From: Mahesh Kumar 
> 
> Add support of recognizing DRM_FORMAT_NV12 from plane_format
> register value.
> 

Reviewed-by: Mika Kahola 

> Signed-off-by: Mahesh Kumar 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 91f3c0a..a1e4a5e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2612,6 +2612,8 @@ static int skl_format_to_fourcc(int format,
> bool rgb_order, bool alpha)
>   switch (format) {
>   case PLANE_CTL_FORMAT_RGB_565:
>   return DRM_FORMAT_RGB565;
> + case PLANE_CTL_FORMAT_NV12:
> + return DRM_FORMAT_NV12;
>   default:
>   case PLANE_CTL_FORMAT_XRGB_:
>   if (rgb_order) {
-- 
Mika Kahola - Intel OTC

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

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v2] drm/i915: Increase render/media power gating hysteresis for gen9+ (rev3)

2018-01-23 Thread Chris Wilson 
Quoting Patchwork (2018-01-22 21:26:48)
> == Series Details ==
> 
> Series: series starting with [v2] drm/i915: Increase render/media power 
> gating hysteresis for gen9+ (rev3)
> URL   : https://patchwork.freedesktop.org/series/36842/
> State : success
> 
> == Summary ==
> 
> Warning: bzip CI_DRM_3667/shard-glkb6/results7.json.bz2 wasn't in correct 
> JSON format
> Test kms_cursor_legacy:
> Subgroup cursor-vs-flip-atomic:
> fail   -> PASS   (shard-apl) fdo#103355
> Subgroup flip-vs-cursor-legacy:
> pass   -> FAIL   (shard-apl) fdo#102670
> Test perf:
> Subgroup buffer-fill:
> fail   -> PASS   (shard-apl) fdo#103755
> Subgroup oa-exponents:
> fail   -> PASS   (shard-apl) fdo#102254
> Test kms_frontbuffer_tracking:
> Subgroup fbc-1p-offscren-pri-shrfb-draw-blt:
> fail   -> PASS   (shard-snb) fdo#101623 +1
> 
> fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355
> fdo#102670 https://bugs.freedesktop.org/show_bug.cgi?id=102670
> fdo#103755 https://bugs.freedesktop.org/show_bug.cgi?id=103755
> fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254
> fdo#101623 https://bugs.freedesktop.org/show_bug.cgi?id=101623
> 
> shard-apltotal:2780 pass:1716 dwarn:1   dfail:0   fail:23  skip:1040 
> time:14666s
> shard-hswtotal:2780 pass:1724 dwarn:1   dfail:0   fail:12  skip:1042 
> time:15570s
> shard-snbtotal:2780 pass:1317 dwarn:1   dfail:0   fail:13  skip:1449 
> time:8120s
> Blacklisted hosts:
> shard-kbltotal:2780 pass:1835 dwarn:3   dfail:0   fail:26  skip:916 
> time:11041s
> 
> == Logs ==
> 
> For more details see: 
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7738/shards.html

Reran on trybot to confirm the kbl errors were just flukes,
https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_1695/shards.html
and pushed. Given that this is destined for 4.17, that gives us 3 months
to soak it before it gets exposed upstream. Fingers crossed!

Thanks,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP

2018-01-23 Thread Imre Deak 
On Tue, Jan 23, 2018 at 11:48:22AM +0200, Jani Nikula wrote:
> On Mon, 22 Jan 2018, Imre Deak  wrote:
> > On Fri, Jan 19, 2018 at 05:45:16PM +0200, Imre Deak wrote:
> >> On Thu, Oct 12, 2017 at 12:13:38PM -0700, Manasi Navare wrote:
> >> > In case of eDP because the panel has a fixed mode, the link rate
> >> > and lane count at which it is trained corresponds to the link BW
> >> > required to support the native resolution of the panel. In case of
> >> > panles with lower resolutions where fewer lanes are hooked up internally,
> >> > that number is reflected in the MAX_LANE_COUNT DPCD register of the 
> >> > panel.
> >> > So it is pointless to fallback to lower link rate/lane count in case
> >> > of link training failure on eDP connector since the lower link BW
> >> > will not support the native resolution of the panel and we cannot
> >> > prune the preferred mode on the eDP connector.
> >> > 
> >> > In case of Link training failure on the eDP panel, something is wrong
> >> > in the HW internally and hence driver errors out with a loud
> >> > and clear DRM_ERROR message.
> >> > 
> >> > v2:
> >> > * Fix the DEBUG_ERROR and add {} in else (Ville Syrjala)
> >> > 
> >> > Cc: Clinton Taylor 
> >> > Cc: Jim Bride 
> >> > Cc: Jani Nikula 
> >> > Cc: Ville Syrjala 
> >> > Cc: Dave Airlie 
> >> > Cc: Daniel Vetter 
> >> > Signed-off-by: Manasi Navare 
> >> > Reviewed-by: Ville Syrjala 
> >> 
> >> This fell through the cracks, looks like it partially fixes
> >> https://bugs.freedesktop.org/show_bug.cgi?id=103369
> >> 
> >> Why link training fails there is not clear.
> >
> > Ok, the link training fail turned out to be a race between a modeset
> > link training and a link retraining called from
> > runtime_resume->intel_hpd_init->dp_detect. As Ville pointed out that
> > one was fixed meanwhile by
> >
> > commit 42e5e65765265485ecf2a480c244d76c2c624449
> > Author: Daniel Vetter 
> > AuthorDate: Mon Nov 13 17:01:40 2017 +0100
> > Commit: Daniel Vetter 
> > CommitDate: Thu Nov 23 14:59:07 2017 +0100
> >
> > drm/i915: sync dp link status checks against atomic commmits
> >
> > I merged now this fix to address the other issue, adding the above bug
> > as reference. Thanks for the patch and the review.
> 
> Thanks for the follow-up... but should we have added a Fixes: or cc:
> stable tag here?

Fixes: 9301397a63b3 ("drm/i915: Implement Link Rate fallback on Link
training failure")

I wasn't sure about stable, since for me the link training failure
happened only due to the bug fixed by 42e5e65765265. In any case I can't
see how it could cause problems, so yes let's Cc: stable too.

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

Re: [Intel-gfx] [PATCH 1/4] drm/i915/guc: Fix lockdep due to log relay channel handling under struct_mutex

2018-01-23 Thread Sagar Arun Kamble 



On 1/22/2018 8:57 PM, Sagar Arun Kamble wrote:



On 1/22/2018 4:17 PM, Chris Wilson wrote:

Quoting Sagar Arun Kamble (2018-01-22 10:38:10)


On 1/22/2018 3:46 PM, Chris Wilson wrote:

Quoting Sagar Arun Kamble (2018-01-22 08:26:01)

+int intel_guc_log_relay_create(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   struct rchan *guc_log_relay_chan;
+   size_t n_subbufs, subbuf_size;
+   int ret;
+
+   if (!i915_modparams.guc_log_level)
+   return 0;
+
+   GEM_BUG_ON(guc_log_has_relay(guc));
+
   /* Keep the size of sub buffers same as shared log 
buffer */

-   subbuf_size = guc->log.vma->obj->base.size;
+   subbuf_size = GUC_LOG_SIZE;
     /* Store up to 8 snapshots, which is large enough to 
buffer sufficient
   * boot time logs and provides enough leeway to User, in 
terms of
@@ -407,33 +442,31 @@ static int guc_log_runtime_create(struct 
intel_guc *guc)
  DRM_ERROR("Couldn't create relay chan for GuC 
logging\n");

     ret = -ENOMEM;
-   goto err_vaddr;
+   goto err;
  }
     GEM_BUG_ON(guc_log_relay_chan->subbuf_size < 
subbuf_size);

  guc->log.runtime.relay_chan = guc_log_relay_chan;
   -   INIT_WORK(>log.runtime.flush_work, 
capture_logs_work);

  return 0;
   -err_vaddr:
- i915_gem_object_unpin_map(guc->log.vma->obj);
-   guc->log.runtime.buf_addr = NULL;
+err:
+   /* logging will be off */
+   i915_modparams.guc_log_level = 0;
  return ret;
   }
   -static void guc_log_runtime_destroy(struct intel_guc *guc)
+void intel_guc_log_relay_destroy(struct intel_guc *guc)
   {

Now exposed to multiple users, we need to document what the locking
requirements are here. Or add some local locking.

Do you mean locking between relay_create and relay_destroy?

We need a lock around guc->log.runtime.relay_chan as the destroy path is
not ostensibly serialised between multiple potential callers. Ordinarily
I would have said that serialisation for create/destroy/access of
relay_chan was guaranteed by init/fini ordering,
I was also initially thinking that init/fini ordering should take care 
of synchronization.
Checked further and I see that relay_open and relay_destroy are 
synchronized by relay_channels_mutex
and internally if needed through debugfs inode synchronization. So I 
feel we need not add new lock.
Sorry. after some more thinking, I am now convinced that lock will be 
needed as guc_log_has_relay was accessing

it without any locking. Will share new rev. Thanks for the review.

  but that's no longer
clear (based on a 5min read of the patch).

The most important question is "can relay_destroy be called while some
user still has access to the relay_chan?"


   Looks like at the
moment, _create is using struct_mutex,
relay_create and relay_destroy are now to be done outside of 
struct_mutex.

I will add this documentation to the functions.

(lockdep_assert_held :)
-Chris




--
Thanks,
Sagar

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

Re: [Intel-gfx] [PATCH] drm/i915: Replace open-coded wait-for loop

2018-01-23 Thread Mika Kuoppala 
Chris Wilson  writes:

> Now that we can pass arbitrary commands into the base __wait_for()
> macro, we can reimplement the open-coded wait-for inside
> i915_gem_idle_work_handler() using the macro. This means that instead of
> using ktime, we now use jiffies, and benefit from the exponential sleep
> backoff that allows a fast response if the HW settles quickly.
>
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> Cc: Tvrtko Ursulin 
> Cc: Joonas Lahtinen 
>
> ---
> Note this depends on __wait_for() from the hdcp topic branch.
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 15 ---
>  1 file changed, 4 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 7f0684ccc724..cb4df1be0909 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3347,7 +3347,6 @@ i915_gem_idle_work_handler(struct work_struct *work)
>   struct drm_i915_private *dev_priv =
>   container_of(work, typeof(*dev_priv), gt.idle_work.work);
>   bool rearm_hangcheck;
> - ktime_t end;
>  
>   if (!READ_ONCE(dev_priv->gt.awake))
>   return;
> @@ -3356,16 +3355,10 @@ i915_gem_idle_work_handler(struct work_struct *work)
>* Wait for last execlists context complete, but bail out in case a
>* new request is submitted.
>*/
> - end = ktime_add_ms(ktime_get(), I915_IDLE_ENGINES_TIMEOUT);
> - do {
> - if (new_requests_since_last_retire(dev_priv))
> - return;
> -
> - if (intel_engines_are_idle(dev_priv))
> - break;
> -
> - usleep_range(100, 500);
> - } while (ktime_before(ktime_get(), end));
> + __wait_for(if (new_requests_since_last_retire(dev_priv)) return,
> +intel_engines_are_idle(dev_priv),
> +I915_IDLE_ENGINES_TIMEOUT * 1000,
> +10,  1000);

Not perhaps the prettiest construct but it does what
the commit message promises.

Reviewed-by: Mika Kuoppala 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915/edp: Do not do link training fallback or prune modes on EDP

2018-01-23 Thread Jani Nikula 
On Mon, 22 Jan 2018, Imre Deak  wrote:
> On Fri, Jan 19, 2018 at 05:45:16PM +0200, Imre Deak wrote:
>> On Thu, Oct 12, 2017 at 12:13:38PM -0700, Manasi Navare wrote:
>> > In case of eDP because the panel has a fixed mode, the link rate
>> > and lane count at which it is trained corresponds to the link BW
>> > required to support the native resolution of the panel. In case of
>> > panles with lower resolutions where fewer lanes are hooked up internally,
>> > that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
>> > So it is pointless to fallback to lower link rate/lane count in case
>> > of link training failure on eDP connector since the lower link BW
>> > will not support the native resolution of the panel and we cannot
>> > prune the preferred mode on the eDP connector.
>> > 
>> > In case of Link training failure on the eDP panel, something is wrong
>> > in the HW internally and hence driver errors out with a loud
>> > and clear DRM_ERROR message.
>> > 
>> > v2:
>> > * Fix the DEBUG_ERROR and add {} in else (Ville Syrjala)
>> > 
>> > Cc: Clinton Taylor 
>> > Cc: Jim Bride 
>> > Cc: Jani Nikula 
>> > Cc: Ville Syrjala 
>> > Cc: Dave Airlie 
>> > Cc: Daniel Vetter 
>> > Signed-off-by: Manasi Navare 
>> > Reviewed-by: Ville Syrjala 
>> 
>> This fell through the cracks, looks like it partially fixes
>> https://bugs.freedesktop.org/show_bug.cgi?id=103369
>> 
>> Why link training fails there is not clear.
>
> Ok, the link training fail turned out to be a race between a modeset
> link training and a link retraining called from
> runtime_resume->intel_hpd_init->dp_detect. As Ville pointed out that
> one was fixed meanwhile by
>
> commit 42e5e65765265485ecf2a480c244d76c2c624449
> Author: Daniel Vetter 
> AuthorDate: Mon Nov 13 17:01:40 2017 +0100
> Commit: Daniel Vetter 
> CommitDate: Thu Nov 23 14:59:07 2017 +0100
>
> drm/i915: sync dp link status checks against atomic commmits
>
> I merged now this fix to address the other issue, adding the above bug
> as reference. Thanks for the patch and the review.

Thanks for the follow-up... but should we have added a Fixes: or cc:
stable tag here?

BR,
Jani.


>
> --Imre
>
>> 
>> > ---
>> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 26 
>> > +-
>> >  1 file changed, 17 insertions(+), 9 deletions(-)
>> > 
>> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c 
>> > b/drivers/gpu/drm/i915/intel_dp_link_training.c
>> > index 05907fa..cf8fef8 100644
>> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
>> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
>> > @@ -328,14 +328,22 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
>> >return;
>> >  
>> >   failure_handling:
>> > -  DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = 
>> > %d, lane count = %d",
>> > -intel_connector->base.base.id,
>> > -intel_connector->base.name,
>> > -intel_dp->link_rate, intel_dp->lane_count);
>> > -  if (!intel_dp_get_link_train_fallback_values(intel_dp,
>> > -   intel_dp->link_rate,
>> > -   intel_dp->lane_count))
>> > -  /* Schedule a Hotplug Uevent to userspace to start modeset */
>> > -  schedule_work(_connector->modeset_retry_work);
>> > +  /* Dont fallback and prune modes if its eDP */
>> > +  if (!intel_dp_is_edp(intel_dp)) {
>> > +  DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link 
>> > rate = %d, lane count = %d",
>> > +intel_connector->base.base.id,
>> > +intel_connector->base.name,
>> > +intel_dp->link_rate, intel_dp->lane_count);
>> > +  if (!intel_dp_get_link_train_fallback_values(intel_dp,
>> > +   
>> > intel_dp->link_rate,
>> > +   
>> > intel_dp->lane_count))
>> > +  /* Schedule a Hotplug Uevent to userspace to start 
>> > modeset */
>> > +  schedule_work(_connector->modeset_retry_work);
>> > +  } else {
>> > +  DRM_ERROR("[CONNECTOR:%d:%s] Link Training failed at link rate 
>> > = %d, lane count = %d",
>> > +intel_connector->base.base.id,
>> > +intel_connector->base.name,
>> > +intel_dp->link_rate, intel_dp->lane_count);
>> > +  }
>> >return;
>> >  }
>> > -- 
>> > 2.1.4
>> > 
>> > ___
>> > Intel-gfx mailing list
>> > Intel-gfx@lists.freedesktop.org
>> >

Re: [Intel-gfx] [PATCH v2] drm/i915: Move LRC register offsets to a header file

2018-01-23 Thread Chris Wilson 
Quoting Michel Thierry (2018-01-23 00:41:07)
> On 1/22/2018 4:31 PM, Lucas De Marchi wrote:
> > So for this file what I understand is that it should be:
> > 
> >   // SPDX-License-Identifier: MIT
> >   // Copyright (C) 2014-2018 Intel Corporation
> 
> So be it.

Oh no, we don't do C++ comments.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt] igt/kms_frontbuffer_tracking: Show FBC status during the wait

2018-01-23 Thread Chris Wilson 
Currently, we have a sporadic failure in the multidraw tests where it
sometimes fails to start FBC in a timely fashion (and at other times
works fine). Try to get a little more information as wait it is waiting
for by showing the fbc status at each stage.

Signed-off-by: Chris Wilson 
Reviewed-by: Daniel Vetter 
---
 tests/kms_frontbuffer_tracking.c | 17 +
 1 file changed, 5 insertions(+), 12 deletions(-)

diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index 1601cab45..79e4f5862 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -792,22 +792,15 @@ static void __debugfs_read(const char *param, char *buf, 
int len)
 
 #define debugfs_read(p, arr) __debugfs_read(p, arr, sizeof(arr))
 
-static bool fbc_is_enabled(void)
+static bool fbc_is_enabled(int lvl)
 {
char buf[128];
 
debugfs_read("i915_fbc_status", buf);
+   igt_log(IGT_LOG_DOMAIN, lvl, "fbc_is_enabled()?\n%s", buf);
return strstr(buf, "FBC enabled\n");
 }
 
-static void fbc_print_status(void)
-{
-   char buf[128];
-
-   debugfs_read("i915_fbc_status", buf);
-   igt_info("FBC status:\n%s\n", buf);
-}
-
 static bool psr_is_enabled(void)
 {
char buf[256];
@@ -927,7 +920,7 @@ static bool fbc_stride_not_supported(void)
 
 static bool fbc_wait_until_enabled(void)
 {
-   return igt_wait(fbc_is_enabled(), 2000, 1);
+   return igt_wait(fbc_is_enabled(IGT_LOG_DEBUG), 2000, 1);
 }
 
 static bool psr_wait_until_enabled(void)
@@ -1710,8 +1703,8 @@ static void do_status_assertions(int flags)
igt_require(!fbc_not_enough_stolen());
igt_require(!fbc_stride_not_supported());
if (!fbc_wait_until_enabled()) {
-   fbc_print_status();
-   igt_assert_f(fbc_is_enabled(), "FBC disabled\n");
+   igt_assert_f(fbc_is_enabled(IGT_LOG_WARN),
+"FBC disabled\n");
}
 
if (opt.fbc_check_compression)
-- 
2.15.1

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

<    1   2