Re: [Intel-gfx] [PATCH i-g-t v5 4/7] Introduce common frame dumping configuration and helpers
On Wed, Jul 19, 2017 at 04:46:07PM +0300, Paul Kocialkowski wrote:
> This introduces a common FrameDumpPath configuration field, as well as
> helper functions in dedicated igt_frame for writing cairo surfaces
> to png files.
>
> Signed-off-by: Paul Kocialkowski
> ---
> lib/Makefile.sources | 2 +
> lib/igt.h| 1 +
> lib/igt_core.c | 12 +
> lib/igt_core.h | 2 +-
> lib/igt_frame.c | 137
> +++
> lib/igt_frame.h | 43
Please make sure you pull the new docs into the docs build too. And while
doing that, please review for other stuff added in the past year and
include that too. And please build the docs and check the result.
Thanks, Daniel
> 6 files changed, 196 insertions(+), 1 deletion(-)
> create mode 100644 lib/igt_frame.c
> create mode 100644 lib/igt_frame.h
>
> diff --git a/lib/Makefile.sources b/lib/Makefile.sources
> index 53fdb54c..c2e58809 100644
> --- a/lib/Makefile.sources
> +++ b/lib/Makefile.sources
> @@ -83,6 +83,8 @@ lib_source_list = \
> uwildmat/uwildmat.c \
> igt_kmod.c \
> igt_kmod.h \
> + igt_frame.c \
> + igt_frame.h \
> $(NULL)
>
> .PHONY: version.h.tmp
> diff --git a/lib/igt.h b/lib/igt.h
> index a069deb3..d16a4991 100644
> --- a/lib/igt.h
> +++ b/lib/igt.h
> @@ -34,6 +34,7 @@
> #include "igt_draw.h"
> #include "igt_dummyload.h"
> #include "igt_fb.h"
> +#include "igt_frame.h"
> #include "igt_gt.h"
> #include "igt_kms.h"
> #include "igt_pm.h"
> diff --git a/lib/igt_core.c b/lib/igt_core.c
> index 1ba79361..5a3b00e8 100644
> --- a/lib/igt_core.c
> +++ b/lib/igt_core.c
> @@ -235,6 +235,10 @@
> * An example configuration follows:
> *
> * |[
> + * # The common configuration secton follows.
> + * [Common]
> + * FrameDumpPath=/tmp # The path to dump frames that fail comparison checks
> + *
> * # The following section is used for configuring the Device Under Test.
> * # It is not mandatory and allows overriding default values.
> * [DUT]
> @@ -290,6 +294,7 @@ static struct {
> static pthread_mutex_t log_buffer_mutex = PTHREAD_MUTEX_INITIALIZER;
>
> GKeyFile *igt_key_file;
> +char *frame_dump_path;
>
> const char *igt_test_name(void)
> {
> @@ -621,6 +626,13 @@ static int config_parse(void)
> if (!igt_key_file)
> return 0;
>
> + frame_dump_path = getenv("IGT_FRAME_DUMP_PATH");
> +
> + if (!frame_dump_path)
> + frame_dump_path = g_key_file_get_string(igt_key_file, "Common",
> + "FrameDumpPath",
> + &error);
> +
> rc = g_key_file_get_integer(igt_key_file, "DUT", "SuspendResumeDelay",
> &error);
> if (error && error->code == G_KEY_FILE_ERROR_INVALID_VALUE)
> diff --git a/lib/igt_core.h b/lib/igt_core.h
> index 0739ca83..1619a9d6 100644
> --- a/lib/igt_core.h
> +++ b/lib/igt_core.h
> @@ -50,7 +50,7 @@
> extern const char* __igt_test_description __attribute__((weak));
> extern bool __igt_plain_output;
> extern GKeyFile *igt_key_file;
> -
> +extern char *frame_dump_path;
>
> /**
> * IGT_TEST_DESCRIPTION:
> diff --git a/lib/igt_frame.c b/lib/igt_frame.c
> new file mode 100644
> index ..dfafe53d
> --- /dev/null
> +++ b/lib/igt_frame.c
> @@ -0,0 +1,137 @@
> +/*
> + * Copyright © 2017 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + * Paul Kocialkowski
> + */
> +
> +#include "config.h"
> +
> +#include
> +#include
> +#include
> +
> +#include "igt.h"
> +
> +/**
> + * SECTION:igt_frame
> + * @short_description: Library for frame-related tests
> + * @title: Frame
> + * @include: igt_frame.h
> + *
> + * This
Re: [Intel-gfx] [PATCH] edp-DRRS test
On Thu, Jul 20, 2017 at 8:27 AM, Ramalingam C wrote: > Agreed Paulo. As per daniel's suggestion we tried to reuse the > infrastructure > provided by frontbuffer tracking igt. But we couldn't as the test case > requirements > were not matching. DRRS _is_ using the frontbuffer tracking stuff. Maybe you need additional tests on top (which can be separate), but you definitely want to test the stuff frontbuffer tracking is testing. Why exactly does it not match? Thanks, 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 https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] lib/igt_core: Handle glib errors correctly to avoid stderr spew
This adds the required error clean/free calls after calling
configuration parsing functions. In addition to properly handling memory,
this avoids glib spewing out error messages on stderr, which breaks the
whole CI.
Signed-off-by: Paul Kocialkowski
---
lib/igt_core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 028ef6bd..03d9a5bf 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -637,10 +637,16 @@ static int config_parse(void)
"FrameDumpPath",
&error);
+ g_clear_error(&error);
+
rc = g_key_file_get_integer(igt_key_file, "DUT", "SuspendResumeDelay",
&error);
- if (error && error->code == G_KEY_FILE_ERROR_INVALID_VALUE)
+ if (error && error->code == G_KEY_FILE_ERROR_INVALID_VALUE) {
+ g_error_free(error);
return -2;
+ }
+
+ g_clear_error(&error);
if (rc != 0)
igt_set_autoresume_delay(rc);
@@ -809,6 +815,7 @@ static int common_init(int *argc, char **argv,
ret = g_key_file_load_from_file(igt_key_file, key_file_loc,
G_KEY_FILE_NONE, &error);
if (error && error->code == G_KEY_FILE_ERROR) {
+ g_error_free(error);
g_key_file_free(igt_key_file);
igt_key_file = NULL;
ret = -2;
@@ -816,6 +823,8 @@ static int common_init(int *argc, char **argv,
goto out;
}
+ g_clear_error(&error);
+
ret = config_parse();
#endif
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib/igt_core: Handle glib errors correctly to avoid stderr spew
On Thu, 2017-07-20 at 10:45 +0300, Paul Kocialkowski wrote:
> This adds the required error clean/free calls after calling
> configuration parsing functions. In addition to properly handling
> memory,
> this avoids glib spewing out error messages on stderr, which breaks
> the
> whole CI.
Fixes: ee31e0b5 ("Introduce common frame dumping configuration...")
> Signed-off-by: Paul Kocialkowski
> ---
> lib/igt_core.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/lib/igt_core.c b/lib/igt_core.c
> index 028ef6bd..03d9a5bf 100644
> --- a/lib/igt_core.c
> +++ b/lib/igt_core.c
> @@ -637,10 +637,16 @@ static int config_parse(void)
> "FrameDumpPat
> h",
> &error);
>
> + g_clear_error(&error);
> +
> rc = g_key_file_get_integer(igt_key_file, "DUT",
> "SuspendResumeDelay",
> &error);
> - if (error && error->code == G_KEY_FILE_ERROR_INVALID_VALUE)
> + if (error && error->code == G_KEY_FILE_ERROR_INVALID_VALUE) {
> + g_error_free(error);
> return -2;
> + }
> +
> + g_clear_error(&error);
>
> if (rc != 0)
> igt_set_autoresume_delay(rc);
> @@ -809,6 +815,7 @@ static int common_init(int *argc, char **argv,
> ret = g_key_file_load_from_file(igt_key_file, key_file_loc,
> G_KEY_FILE_NONE, &error);
> if (error && error->code == G_KEY_FILE_ERROR) {
> + g_error_free(error);
> g_key_file_free(igt_key_file);
> igt_key_file = NULL;
> ret = -2;
> @@ -816,6 +823,8 @@ static int common_init(int *argc, char **argv,
> goto out;
> }
>
> + g_clear_error(&error);
> +
> ret = config_parse();
> #endif
>
--
Paul Kocialkowski
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo, Finland
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2] lib/igt_core: Handle glib errors correctly to avoid stderr spew
This adds the required error clean/free calls after calling
configuration parsing functions. In addition to properly handling memory,
this avoids glib spewing out error messages on stderr, which breaks the
whole CI with this message:
GLib-WARNING **: GError set over the top of a previous GError or
uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL
before it's set.
The overwriting error message was: Key file does not have group ?DUT?
Fixes: ee31e0b5 ("Introduce common frame dumping configuration...")
Cc: Paul Kocialkowski
Cc: Lyude
Cc: Martin Peres
Signed-off-by: Paul Kocialkowski
---
lib/igt_core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 028ef6bd..03d9a5bf 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -637,10 +637,16 @@ static int config_parse(void)
"FrameDumpPath",
&error);
+ g_clear_error(&error);
+
rc = g_key_file_get_integer(igt_key_file, "DUT", "SuspendResumeDelay",
&error);
- if (error && error->code == G_KEY_FILE_ERROR_INVALID_VALUE)
+ if (error && error->code == G_KEY_FILE_ERROR_INVALID_VALUE) {
+ g_error_free(error);
return -2;
+ }
+
+ g_clear_error(&error);
if (rc != 0)
igt_set_autoresume_delay(rc);
@@ -809,6 +815,7 @@ static int common_init(int *argc, char **argv,
ret = g_key_file_load_from_file(igt_key_file, key_file_loc,
G_KEY_FILE_NONE, &error);
if (error && error->code == G_KEY_FILE_ERROR) {
+ g_error_free(error);
g_key_file_free(igt_key_file);
igt_key_file = NULL;
ret = -2;
@@ -816,6 +823,8 @@ static int common_init(int *argc, char **argv,
goto out;
}
+ g_clear_error(&error);
+
ret = config_parse();
#endif
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2] lib/igt_core: Handle glib errors correctly to avoid stderr spew
On Thu, Jul 20, 2017 at 11:07:42AM +0300, Paul Kocialkowski wrote:
> This adds the required error clean/free calls after calling
> configuration parsing functions. In addition to properly handling memory,
> this avoids glib spewing out error messages on stderr, which breaks the
> whole CI with this message:
>
> GLib-WARNING **: GError set over the top of a previous GError or
> uninitialized memory.
> This indicates a bug in someone's code. You must ensure an error is NULL
> before it's set.
> The overwriting error message was: Key file does not have group ?DUT?
>
> Fixes: ee31e0b5 ("Introduce common frame dumping configuration...")
>
> Cc: Paul Kocialkowski
> Cc: Lyude
> Cc: Martin Peres
> Signed-off-by: Paul Kocialkowski
Acked-by: Arkadiusz Hiler
and pushed.
--
Cheers,
Arek
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Pass enum pipe to intel_set_pch_fifo_underrun_reporting()
On Wed, Jul 19, 2017 at 10:39:28AM -0700, Matthias Kaehlcke wrote:
> Commit a21960339c8c ("drm/i915: Consistently use enum pipe for PCH
> transcoders") misses some pieces, due to a problem with the patch
> format, this patch adds the remaining bits.
>
> Fixes: a21960339c8c ("drm/i915: Consistently use enum pipe for PCH
> transcoders")
>
> Signed-off-by: Matthias Kaehlcke
Applied, and this time successfully it seems!
Thanks a lot, and sorry for the slight ordeal, I still have no clear idea
what happened with your v2 patch.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a89d0fd1c2e1..5c7054c3be0e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5347,8 +5347,7 @@ static void haswell_crtc_enable(struct intel_crtc_state
> *pipe_config,
> return;
>
> if (intel_crtc->config->has_pch_encoder)
> - intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
> - false);
> + intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false);
>
> intel_encoders_pre_pll_enable(crtc, pipe_config, old_state);
>
> @@ -5433,8 +5432,7 @@ static void haswell_crtc_enable(struct intel_crtc_state
> *pipe_config,
> intel_wait_for_vblank(dev_priv, pipe);
> intel_wait_for_vblank(dev_priv, pipe);
> intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, true);
> - intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
> - true);
> + intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, true);
> }
>
> /* If we change the relative order between pipe/planes enabling, we need
> @@ -5531,8 +5529,7 @@ static void haswell_crtc_disable(struct
> intel_crtc_state *old_crtc_state,
> enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
>
> if (intel_crtc->config->has_pch_encoder)
> - intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
> - false);
> + intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false);
>
> intel_encoders_disable(crtc, old_crtc_state, old_state);
>
> @@ -5560,8 +5557,7 @@ static void haswell_crtc_disable(struct
> intel_crtc_state *old_crtc_state,
> intel_encoders_post_disable(crtc, old_crtc_state, old_state);
>
> if (old_crtc_state->has_pch_encoder)
> - intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
> - true);
> + intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, true);
> }
>
> static void i9xx_pfit_enable(struct intel_crtc *crtc)
> --
> 2.14.0.rc0.284.gd933b75aa4-goog
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Keep a small stash of preallocated WC pages
We use WC pages for coherent writes into the ppGTT on !llc
architectuures. However, to create a WC page requires a stop_machine(),
i.e. is very slow. To compensate we currently keep a per-vm cache of
recently freed pages, but we still see the slow startup of new contexts.
We can amoritize that cost slightly by allocating WC pages in small
batches (PAGEVEC_SIZE == 14) and since creating a WC page implies a
stop_machine() there is no penalty for keeping that stash global.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++
drivers/gpu/drm/i915/i915_gem_gtt.c | 82 ++---
2 files changed, 71 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d26bc10f488e..e0db2d620170 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1446,6 +1446,9 @@ struct i915_gem_mm {
struct llist_head free_list;
struct work_struct free_work;
+ /** Small stash of WC pages */
+ struct pagevec wc_stash;
+
/** Usable portion of the GTT for GEM */
dma_addr_t stolen_base; /* limited to low memory (32-bit) */
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 10aa7762d9a6..76ca22164a34 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -351,31 +351,77 @@ static gen6_pte_t iris_pte_encode(dma_addr_t addr,
static struct page *vm_alloc_page(struct i915_address_space *vm, gfp_t gfp)
{
- struct page *page;
+ struct pagevec *pvec = &vm->free_pages;
if (I915_SELFTEST_ONLY(should_fail(&vm->fault_attr, 1)))
i915_gem_shrink_all(vm->i915);
- if (vm->free_pages.nr)
- return vm->free_pages.pages[--vm->free_pages.nr];
+ if (likely(pvec->nr))
+ return pvec->pages[--pvec->nr];
- page = alloc_page(gfp);
- if (!page)
+ if (!vm->pt_kmap_wc)
+ return alloc_page(gfp);
+
+ lockdep_assert_held(&vm->i915->drm.struct_mutex);
+
+ /* Look in our global stash of WC pages... */
+ pvec = &vm->i915->mm.wc_stash;
+ if (likely(pvec->nr))
+ return pvec->pages[--pvec->nr];
+
+ /* Otherwise batch allocate pages to amoritize cost of set_pages_wc. */
+ do {
+ struct page *page;
+
+ page = alloc_page(gfp);
+ if (unlikely(!page))
+ break;
+
+ pvec->pages[pvec->nr++] = page;
+ } while (pvec->nr < ARRAY_SIZE(pvec->pages));
+
+ if (unlikely(!pvec->nr))
return NULL;
- if (vm->pt_kmap_wc)
- set_pages_array_wc(&page, 1);
+ set_pages_array_wc(pvec->pages, pvec->nr);
- return page;
+ return pvec->pages[--pvec->nr];
}
-static void vm_free_pages_release(struct i915_address_space *vm)
+static void vm_free_pages_release(struct i915_address_space *vm,
+ bool immediate)
{
GEM_BUG_ON(!pagevec_count(&vm->free_pages));
- if (vm->pt_kmap_wc)
- set_pages_array_wb(vm->free_pages.pages,
- pagevec_count(&vm->free_pages));
+ if (vm->pt_kmap_wc) {
+ struct pagevec *global, *local;
+
+ /* When we use WC, first fill up the global stash and then
+* only if full immediately free the overflow.
+*/
+
+ lockdep_assert_held(&vm->i915->drm.struct_mutex);
+ global = &vm->i915->mm.wc_stash;
+ local = &vm->free_pages;
+ if (global->nr < ARRAY_SIZE(global->pages)) {
+ do {
+ global->pages[global->nr++] =
+ local->pages[--local->nr];
+ if (!local->nr)
+ return;
+ } while (global->nr < ARRAY_SIZE(global->pages));
+
+ /* As we have made some room in the VM's free_pages,
+* we can wait for it to fill again. Unless we are
+* inside i915_address_space_fini() and must
+* immediately release the pages!
+*/
+ if (!immediate)
+ return;
+ }
+
+ set_pages_array_wb(local->pages, local->nr);
+ }
__pagevec_release(&vm->free_pages);
}
@@ -383,7 +429,7 @@ static void vm_free_pages_release(struct i915_address_space
*vm)
static void vm_free_page(struct i915_address_space *vm, struct page *page)
{
if (!pagevec_add(&vm->free_pages, page))
- vm_free_pages_release(vm);
+ vm_free_pages_release(vm, false);
}
static int __setup_page_dma(struct i915_address_space *vm,
@@ -1867,7 +1913,7 @@ static voi
Re: [Intel-gfx] [PATCH 9/9] drm/i915: Drop unpin stall in atomic_prepare_commit
On Wed, Jul 19, 2017 at 04:01:03PM +0200, Maarten Lankhorst wrote:
> Op 19-07-17 om 14:55 schreef Daniel Vetter:
> > The core already does this in setup_commit(). With this we can also
> > remove the unpin_work_count since it's the last user.
> >
> > Cc: Maarten Lankhorst
> > Cc: Ville Syrjälä
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 13 +
> > drivers/gpu/drm/i915/intel_drv.h | 2 --
> > 2 files changed, 1 insertion(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index e52a2adbaaa5..351208b7b1ad 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -11825,18 +11825,7 @@ static int intel_atomic_check(struct drm_device
> > *dev,
> > static int intel_atomic_prepare_commit(struct drm_device *dev,
> >struct drm_atomic_state *state)
> > {
> > - struct drm_i915_private *dev_priv = to_i915(dev);
> > - struct drm_crtc_state *crtc_state;
> > - struct drm_crtc *crtc;
> > - int i, ret;
> > -
> > - for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> > - if (state->legacy_cursor_update)
> > - continue;
> > -
> > - if (atomic_read(&to_intel_crtc(crtc)->unpin_work_count) >= 2)
> > - flush_workqueue(dev_priv->wq);
> > - }
> > + int ret;
> >
> > ret = mutex_lock_interruptible(&dev->struct_mutex);
> > if (ret)
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 9cb7e781e863..96402c06e295 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -798,8 +798,6 @@ struct intel_crtc {
> > unsigned long long enabled_power_domains;
> > struct intel_overlay *overlay;
> >
> > - atomic_t unpin_work_count;
> > -
> > /* Display surface base address adjustement for pageflips. Note that on
> > * gen4+ this only adjusts up to a tile, offsets within a tile are
> > * handled in the hw itself (with the TILEOFF register). */
>
> I like red diffs..
>
> For patch 1, 4 (with updated commit message), 6-9:
> Reviewed-by: Maarten Lankhorst
Ok I merged patches 1&2, that take care of this for a lot of
users/systems, and the remaining stuff needs a notch more polish, and a
lot more testing anyway.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] CONTRIBUTING: formalize review rules
On Wed, Jul 19, 2017 at 11:03:46AM +0300, Arkadiusz Hiler wrote: > On Tue, Jul 18, 2017 at 06:00:20PM +0200, Daniel Vetter wrote: > > There's a bunch of reasons why I think we should formalize and enforce > > our review rules for igt patches: > > > > - We have a lot of new engineers joining and review helps enormously > > with mentoring and learning. But right now only patches from > > contributors without commit rights are consistently subjected to > > review, which makes this imbalanced and removes senior contributors > > from the review pool. > > > > - We have a much bigger team and we need to make sure we're aligned on > > where igt as a tool and testsuite needs to head towards. Getting > > that alignment happens through reviewing each other's submission. > > Pushing a contentious patch and then dealing with a heated irc > > discussion is much less effective. > > > > - Finally igt becomes ever more important for our testing, making sure > > the code quality is high is important. Review helps with that. > > > > v2: Improve wording a bit (Imre). > > > > Acked-by: Daniel Stone > > Acked-by: Jani Nikula > > Acked-by: Joonas Lahtinen > > Acked-by: Maarten Lankhorst > > Acked-by: Petri Latvala > > Acked-by: Imre Deak > > Acked-by: Robert Foss > > Acked-by: Ben Widawsky > > Acked-by: Tvrtko Ursulin > > Acked-by: Mika Kuoppala > > Signed-off-by: Daniel Vetter > Acked-by: Arkadiusz Hiler > > With the recent growth in contributions it's a good thing :-) And pushed, thx everyone for their acks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 01/14] RFC drm/i915: Expose a PMU interface for perf queries
On 19/07/2017 10:53, Kamble, Sagar A wrote:
Can we reuse calc_residency defined in i915_sysfs.c
Looks like it, that is intel_pm.c/intel_rc6_residency_us.
I will incorporate the change in the series or the patch. Thanks for
spotting this!
Regards,
Tvrtko
On 7/18/2017 8:06 PM, Tvrtko Ursulin wrote:
From: Chris Wilson
The first goal is to be able to measure GPU (and invidual ring) busyness
without having to poll registers from userspace. (Which not only incurs
holding the forcewake lock indefinitely, perturbing the system, but also
runs the risk of hanging the machine.) As an alternative we can use the
perf event counter interface to sample the ring registers periodically
and send those results to userspace.
To be able to do so, we need to export the two symbols from
kernel/events/core.c to register and unregister a PMU device.
v2: Use a common timer for the ring sampling.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.c | 2 +
drivers/gpu/drm/i915/i915_drv.h | 23 ++
drivers/gpu/drm/i915/i915_pmu.c | 452
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 +
include/uapi/drm/i915_drm.h | 41 +++
kernel/events/core.c| 1 +
7 files changed, 522 insertions(+)
create mode 100644 drivers/gpu/drm/i915/i915_pmu.c
diff --git a/drivers/gpu/drm/i915/Makefile
b/drivers/gpu/drm/i915/Makefile
index f8227318dcaf..1c720013dc42 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -26,6 +26,7 @@ i915-y := i915_drv.o \
i915-$(CONFIG_COMPAT) += i915_ioc32.o
i915-$(CONFIG_DEBUG_FS) += i915_debugfs.o intel_pipe_crc.o
+i915-$(CONFIG_PERF_EVENTS) += i915_pmu.o
# GEM code
i915-y += i915_cmd_parser.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index d310d8245dca..f18ce519f6a2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1194,6 +1194,7 @@ static void i915_driver_register(struct
drm_i915_private *dev_priv)
struct drm_device *dev = &dev_priv->drm;
i915_gem_shrinker_init(dev_priv);
+i915_pmu_register(dev_priv);
/*
* Notify a valid surface after modesetting,
@@ -1247,6 +1248,7 @@ static void i915_driver_unregister(struct
drm_i915_private *dev_priv)
intel_opregion_unregister(dev_priv);
i915_perf_unregister(dev_priv);
+i915_pmu_unregister(dev_priv);
i915_teardown_sysfs(dev_priv);
i915_guc_log_unregister(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 7c6fab08a2e6..de518503e033 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2093,6 +2094,12 @@ struct intel_cdclk_state {
unsigned int cdclk, vco, ref;
};
+enum {
+__I915_SAMPLE_FREQ_ACT = 0,
+__I915_SAMPLE_FREQ_REQ,
+__I915_NUM_PMU_SAMPLERS
+};
+
struct drm_i915_private {
struct drm_device drm;
@@ -2591,6 +2598,13 @@ struct drm_i915_private {
intirq;
} lpe_audio;
+struct {
+struct pmu base;
+struct hrtimer timer;
+u64 enable;
+u64 sample[__I915_NUM_PMU_SAMPLERS];
+} pmu;
+
/*
* NOTE: This is the dri1/ums dungeon, don't add stuff here.
Your patch
* will be rejected. Instead look for a better place.
@@ -3760,6 +3774,15 @@ extern void i915_perf_fini(struct
drm_i915_private *dev_priv);
extern void i915_perf_register(struct drm_i915_private *dev_priv);
extern void i915_perf_unregister(struct drm_i915_private *dev_priv);
+/* i915_pmu.c */
+#ifdef CONFIG_PERF_EVENTS
+extern void i915_pmu_register(struct drm_i915_private *i915);
+extern void i915_pmu_unregister(struct drm_i915_private *i915);
+#else
+static inline void i915_pmu_register(struct drm_i915_private *i915) {}
+static inline void i915_pmu_unregister(struct drm_i915_private *i915) {}
+#endif
+
/* i915_suspend.c */
extern int i915_save_state(struct drm_i915_private *dev_priv);
extern int i915_restore_state(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_pmu.c
b/drivers/gpu/drm/i915/i915_pmu.c
new file mode 100644
index ..f03ddad44da6
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -0,0 +1,452 @@
+#include
+#include
+
+#include "i915_drv.h"
+#include "intel_ringbuffer.h"
+
+#define FREQUENCY 200
+#define PERIOD max_t(u64, 1, NSEC_PER_SEC / FREQUENCY)
+
+#define RING_MASK 0x
+#define RING_MAX 32
+
+static void engines_sample(struct drm_i915_private *dev_priv)
+{
+struct intel_engine_cs *engine;
+enum intel_engine_id id;
+bool fw = false;
+
+if ((dev_priv->pmu.enable & RING_MASK) == 0)
+return;
+
+if (!dev_priv->gt.awake)
+return;
+
+if (!intel_runtime_pm_get_if_in_use(dev_priv
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix scaler init during CRTC HW state readout
On Thu, 20 Jul 2017, Imre Deak wrote:
> The scaler allocation code depends on a non-zero default value for the
> crtc scaler_id, so make sure we initialize the scaler state accordingly
> even if the crtc is off. This fixes at least an initial YUV420 modeset
> (added in a follow-up patchset by Shashank) when booting with the screen
> off: after the initial HW readout and modeset which enables the scaler a
> subsequent modeset will disable the scaler which isn't properly
> allocated. This results in a funky HW state where the pipe scaler HW
> registers can't be modified and the normally black screen is grey and
> shifted to the right or jitters.
>
> The problem was revealed by Shashank's YUV420 patchset and first
> reported by Ville.
>
> Cc: Shashank Sharma
> Cc: Ville Syrjälä
> Cc: Chandra Konduru
> Cc: Matt Roper
> Cc: # 4.11.x
> Reported-by: Ville Syrjälä
> Fixes: a1b2278e4dfc ("drm/i915: skylake panel fitting using shared scalers")
> Signed-off-by: Imre Deak
>
> ---
>
> [ Older stable versions need backporting, so that's for a follow-up ]
I thought we'd annotate cc: stable with all the kernels that need the
fix, not according to where the fix applies as-is. In this case, it
would be v4.2+, right?
BR,
Jani.
> ---
> drivers/gpu/drm/i915/intel_display.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 7774f3465fbc..8a38e64b1931 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9132,6 +9132,13 @@ static bool haswell_get_pipe_config(struct intel_crtc
> *crtc,
> u64 power_domain_mask;
> bool active;
>
> + if (INTEL_GEN(dev_priv) >= 9) {
> + intel_crtc_init_scalers(crtc, pipe_config);
> +
> + pipe_config->scaler_state.scaler_id = -1;
> + pipe_config->scaler_state.scaler_users &= ~(1 <<
> SKL_CRTC_INDEX);
> + }
> +
> power_domain = POWER_DOMAIN_PIPE(crtc->pipe);
> if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
> return false;
> @@ -9160,13 +9167,6 @@ static bool haswell_get_pipe_config(struct intel_crtc
> *crtc,
> pipe_config->gamma_mode =
> I915_READ(GAMMA_MODE(crtc->pipe)) & GAMMA_MODE_MODE_MASK;
>
> - if (INTEL_GEN(dev_priv) >= 9) {
> - intel_crtc_init_scalers(crtc, pipe_config);
> -
> - pipe_config->scaler_state.scaler_id = -1;
> - pipe_config->scaler_state.scaler_users &= ~(1 <<
> SKL_CRTC_INDEX);
> - }
> -
> power_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe);
> if (intel_display_power_get_if_enabled(dev_priv, power_domain)) {
> power_domain_mask |= BIT_ULL(power_domain);
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 00/14] i915 PMU and engine busy stats
On 19/07/2017 13:05, Chris Wilson wrote: Quoting Tvrtko Ursulin (2017-07-18 15:36:04) From: Tvrtko Ursulin Rough sketch of the idea I mentioned a few times to various people - merging the engine busyness tracking with Chris i915 PMU RFC. First patch is the actual PMU RFC by Chris. It is followed by some cleanup patches, then come a few improvements, cheap execlists engine busyness tracking, debugfs view for the same, and finally the i915 PMU is extended to use this instead of timer based mmio sampling. This makes it cheaper and also more accurate since engine busyness is not derived via sampling. But I haven't figure out the perf API yet. For example is it possible to access our events in an usable fashion via perf top/stat or something? Do we want to make the events discoverable as I did (patch 8). In my dreams I have gpu activity in the same perf timechart as gpu activity. But that can be mostly by the request tracepoints, but still overlaying cpu/gpu activity is desirable and more importantly we want to coordinate with nouveau/amdgpu so that such interfaces are as agnostic as possible. There are definitely a bunch of global features in common for all (engine enumeration & activity, mempool enumeration, size & activty, power usage?). But the key question is how do we build for the future? Split the event id range into common/driver? I don't know if going for common events would be workable. A few metrics sounds like it could be generic, but I am not sure there would be more than a couple where that would be future proof. Also is the coordination effort (no one else seems to implement a perf interface at the moment) worth it at the current time? I am not sure. I could not find much (any?) kernel API level documentation for perf. There isn't much indeed. Given that we now have a second pair of eyes go over the sampling and improve its interaction with i915, we should start getting PeterZ involved to check the interaction with perf. Okay, I guess another cleanup pass and then I can do that. In the meantime do you have any good understanding of what kind of events are we exposing here? They look weird if I record them and look with "perf script", and "perf stat" always reports zeroes for them. But they still work from the overlay tool. So it is a bit of a mystery to me what they really are. Btw patch series actually works since intel-gpu-overlay can use these events when they are available. Chris Wilson (1): RFC drm/i915: Expose a PMU interface for perf queries One thing I would like is for any future interface (including this engine/class/event id) to use the engine class/instance mapping. I was thinking about that myself. I can do it in the next cleanup pass. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 12/14] drm/i915: Interface for controling engine stats collection
On 19/07/2017 12:04, Chris Wilson wrote: [snip] Long term though having a global static key is going to be a nasty wart. Joonas will definitely ask the question how much will it cost us to use an engine->bool and what we can do to minimise that cost. Why you think it is nasty? Sounds pretty cool to me. If we enable sampling on one device (engine even!), it affects another. But the device is the more compelling argument against. Since you mention engines, I can do it on engine granularity with normal branches. It makes sense for the pmu interface to have it per engine. Then as I said before, I can put in a late patch in the series which adds a static key (master enable/disable on or-ed per-engine enables) just in case we find it attractive. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] Revert "drm/i915: Add heuristic to determine better way to adjust brightness"
This reverts commit 560a758d39c616f83ac25ff6e0816a49ebe6401c.
The DPCD backlight commits regress a Thinkpad X1 Carbon 4th Gen and a
BXT-P (in CI). Enabling dynamic backlight boots to a black screen, and
enabling DPCD backlight leads to a black screen after suspend/resume.
References: http://mid.mail-archive.com/20170706135349.6tu3lz7uehazlnnn@boom
References: http://mid.mail-archive.com/20170627132326.f2q3yn4bh5flji4q@boom
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101619
Reported-by: David Weinehall
Fixes: 560a758d39c6 ("drm/i915: Add heuristic to determine better way to adjust
brightness")
Cc: Jenny TC
Cc: David Weinehall
Cc: Puthikorn Voravootivat
Cc: Dhinakaran Pandiyan
Cc: Daniel Vetter
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_params.c| 7 ++-
drivers/gpu/drm/i915/i915_params.h| 2 +-
drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 61 ++-
3 files changed, 7 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 5b5ab15d191f..14e2c2e57f96 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -63,7 +63,7 @@ struct i915_params i915 __read_mostly = {
.huc_firmware_path = NULL,
.enable_dp_mst = true,
.inject_load_failure = 0,
- .enable_dpcd_backlight = -1,
+ .enable_dpcd_backlight = false,
.enable_gvt = false,
};
@@ -246,10 +246,9 @@ MODULE_PARM_DESC(enable_dp_mst,
module_param_named_unsafe(inject_load_failure, i915.inject_load_failure, uint,
0400);
MODULE_PARM_DESC(inject_load_failure,
"Force an error after a number of failure check points (0:disabled
(default), N:force failure at the Nth failure check point)");
-module_param_named_unsafe(enable_dpcd_backlight, i915.enable_dpcd_backlight,
int, 0600);
+module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool,
0600);
MODULE_PARM_DESC(enable_dpcd_backlight,
- "Enable support for DPCD backlight control "
- "(-1:auto (default), 0:force disable, 1:force enabled if supported");
+ "Enable support for DPCD backlight control (default:false)");
module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
MODULE_PARM_DESC(enable_gvt,
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 0d6cf9138dc4..febbfdbd30bd 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -53,7 +53,6 @@
func(int, edp_vswing); \
func(int, reset); \
func(unsigned int, inject_load_failure); \
- func(int, enable_dpcd_backlight); \
/* leave bools at the end to not create holes */ \
func(bool, alpha_support); \
func(bool, enable_cmd_parser); \
@@ -67,6 +66,7 @@
func(bool, verbose_state_checks); \
func(bool, nuclear_pageflip); \
func(bool, enable_dp_mst); \
+ func(bool, enable_dpcd_backlight); \
func(bool, enable_gvt)
#define MEMBER(T, member) T member
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index fea161727c6e..d2830ba3162e 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -251,66 +251,15 @@ intel_dp_aux_display_control_capable(struct
intel_connector *connector)
/* Check the eDP Display control capabilities registers to determine if
* the panel can support backlight control over the aux channel
*/
- if ((intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP) &&
- (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
+ if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
+ (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
+ !(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
{
DRM_DEBUG_KMS("AUX Backlight Control Supported!\n");
return true;
}
return false;
}
-/*
- * Heuristic function whether we should use AUX for backlight adjustment or
not.
- *
- * We should use AUX for backlight brightness adjustment if panel doesn't this
- * via PWM pin or using AUX is better than using PWM pin.
- *
- * The heuristic to determine that using AUX pin is better than using PWM pin
is
- * that the panel support any of the feature list here.
- * - Regional backlight brightness adjustment
- * - Backlight PWM frequency set
- * - More than 8 bits resolution of brightness level
- * - Backlight enablement via AUX and not by BL_ENABLE pin
- *
- * If all above are not true, assume that using PWM pin is better.
- */
-static bool
-intel_dp_aux_display_control_heuristic(struct intel_connector *connector)
-{
- struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
- uint8_t reg_va
[Intel-gfx] [PATCH 0/2] drm/i915: revert DPCD backlight and DBC enabling by default
The two commits being reverted regress machines, a production ThinkPad, and BXT-P in CI, and there hasn't been adequate response to follow-up or fix the issues. The regressions were reported 3½ weeks ago. The reverts are long overdue already. Back to the drawing board. BR, Jani. Cc: Jenny TC Cc: David Weinehall Cc: Puthikorn Voravootivat Cc: Dhinakaran Pandiyan Cc: Daniel Vetter Jani Nikula (2): Revert "drm/i915: Add option to support dynamic backlight via DPCD" Revert "drm/i915: Add heuristic to determine better way to adjust brightness" drivers/gpu/drm/i915/i915_params.c| 12 +--- drivers/gpu/drm/i915/i915_params.h| 5 +- drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 87 +-- 3 files changed, 8 insertions(+), 96 deletions(-) -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] Revert "drm/i915: Add option to support dynamic backlight via DPCD"
This reverts commit ae25eceab616d16a07bcaa434b84463d58a3bdc3.
The DPCD backlight commits regress a Thinkpad X1 Carbon 4th Gen and a
BXT-P (in CI). Enabling dynamic backlight boots to a black screen, and
enabling DPCD backlight leads to a black screen after suspend/resume.
References: http://mid.mail-archive.com/20170706135349.6tu3lz7uehazlnnn@boom
References: http://mid.mail-archive.com/20170627132326.f2q3yn4bh5flji4q@boom
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101619
Reported-by: David Weinehall
Fixes: ae25eceab616 ("drm/i915: Add option to support dynamic backlight via
DPCD")
Cc: Jenny TC
Cc: David Weinehall
Cc: Puthikorn Voravootivat
Cc: Dhinakaran Pandiyan
Cc: Daniel Vetter
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_params.c| 5 -
drivers/gpu/drm/i915/i915_params.h| 3 +--
drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 26 --
3 files changed, 1 insertion(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 88b9d3e6713a..5b5ab15d191f 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -65,7 +65,6 @@ struct i915_params i915 __read_mostly = {
.inject_load_failure = 0,
.enable_dpcd_backlight = -1,
.enable_gvt = false,
- .enable_dbc = true,
};
module_param_named(modeset, i915.modeset, int, 0400);
@@ -255,7 +254,3 @@ MODULE_PARM_DESC(enable_dpcd_backlight,
module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
MODULE_PARM_DESC(enable_gvt,
"Enable support for Intel GVT-g graphics virtualization host
support(default:false)");
-
-module_param_named_unsafe(enable_dbc, i915.enable_dbc, bool, 0600);
-MODULE_PARM_DESC(enable_dbc,
- "Enable support for dynamic backlight control (default:true)");
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 057e203e6bda..0d6cf9138dc4 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -67,8 +67,7 @@
func(bool, verbose_state_checks); \
func(bool, nuclear_pageflip); \
func(bool, enable_dp_mst); \
- func(bool, enable_gvt); \
- func(bool, enable_dbc)
+ func(bool, enable_gvt)
#define MEMBER(T, member) T member
struct i915_params {
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index b25cd88fc1c5..fea161727c6e 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -173,24 +173,6 @@ static bool intel_dp_aux_set_pwm_freq(struct
intel_connector *connector)
return true;
}
-/*
-* Set minimum / maximum dynamic brightness percentage. This value is expressed
-* as the percentage of normal brightness in 5% increments.
-*/
-static bool
-intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
- u32 min, u32 max)
-{
- u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5) };
-
- if (drm_dp_dpcd_write(&intel_dp->aux, DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
- dbc, sizeof(dbc)) < 0) {
- DRM_DEBUG_KMS("Failed to write aux DBC brightness level\n");
- return false;
- }
- return true;
-}
-
static void intel_dp_aux_enable_backlight(const struct intel_crtc_state
*crtc_state,
const struct drm_connector_state
*conn_state)
{
@@ -226,14 +208,6 @@ static void intel_dp_aux_enable_backlight(const struct
intel_crtc_state *crtc_st
if (intel_dp_aux_set_pwm_freq(connector))
new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
- if (i915.enable_dbc &&
- (intel_dp->edp_dpcd[2] & DP_EDP_DYNAMIC_BACKLIGHT_CAP)) {
- if(intel_dp_aux_set_dynamic_backlight_percent(intel_dp, 0,
100)) {
- new_dpcd_buf |= DP_EDP_DYNAMIC_BACKLIGHT_ENABLE;
- DRM_DEBUG_KMS("Enable dynamic brightness.\n");
- }
- }
-
if (new_dpcd_buf != dpcd_buf) {
if (drm_dp_dpcd_writeb(&intel_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf) < 0) {
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix scaler init during CRTC HW state readout
On Thu, Jul 20, 2017 at 11:58:35AM +0300, Jani Nikula wrote:
> On Thu, 20 Jul 2017, Imre Deak wrote:
> > The scaler allocation code depends on a non-zero default value for the
> > crtc scaler_id, so make sure we initialize the scaler state accordingly
> > even if the crtc is off. This fixes at least an initial YUV420 modeset
> > (added in a follow-up patchset by Shashank) when booting with the screen
> > off: after the initial HW readout and modeset which enables the scaler a
> > subsequent modeset will disable the scaler which isn't properly
> > allocated. This results in a funky HW state where the pipe scaler HW
> > registers can't be modified and the normally black screen is grey and
> > shifted to the right or jitters.
> >
> > The problem was revealed by Shashank's YUV420 patchset and first
> > reported by Ville.
> >
> > Cc: Shashank Sharma
> > Cc: Ville Syrjälä
> > Cc: Chandra Konduru
> > Cc: Matt Roper
> > Cc: # 4.11.x
> > Reported-by: Ville Syrjälä
> > Fixes: a1b2278e4dfc ("drm/i915: skylake panel fitting using shared scalers")
> > Signed-off-by: Imre Deak
> >
> > ---
> >
> > [ Older stable versions need backporting, so that's for a follow-up ]
>
> I thought we'd annotate cc: stable with all the kernels that need the
> fix, not according to where the fix applies as-is. In this case, it
> would be v4.2+, right?
Hm, not sure. I know that this won't apply before 4.11 and I will have
to send a backported version anyway. So wanted to save a redundant turn
around after the automatic cherry picking to those stable versions
fail.
Greg, what's the proper tag in this case?
Thanks,
Imre
>
> BR,
> Jani.
>
>
>
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 14 +++---
> > 1 file changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 7774f3465fbc..8a38e64b1931 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -9132,6 +9132,13 @@ static bool haswell_get_pipe_config(struct
> > intel_crtc *crtc,
> > u64 power_domain_mask;
> > bool active;
> >
> > + if (INTEL_GEN(dev_priv) >= 9) {
> > + intel_crtc_init_scalers(crtc, pipe_config);
> > +
> > + pipe_config->scaler_state.scaler_id = -1;
> > + pipe_config->scaler_state.scaler_users &= ~(1 <<
> > SKL_CRTC_INDEX);
> > + }
> > +
> > power_domain = POWER_DOMAIN_PIPE(crtc->pipe);
> > if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
> > return false;
> > @@ -9160,13 +9167,6 @@ static bool haswell_get_pipe_config(struct
> > intel_crtc *crtc,
> > pipe_config->gamma_mode =
> > I915_READ(GAMMA_MODE(crtc->pipe)) & GAMMA_MODE_MODE_MASK;
> >
> > - if (INTEL_GEN(dev_priv) >= 9) {
> > - intel_crtc_init_scalers(crtc, pipe_config);
> > -
> > - pipe_config->scaler_state.scaler_id = -1;
> > - pipe_config->scaler_state.scaler_users &= ~(1 <<
> > SKL_CRTC_INDEX);
> > - }
> > -
> > power_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe);
> > if (intel_display_power_get_if_enabled(dev_priv, power_domain)) {
> > power_domain_mask |= BIT_ULL(power_domain);
>
> --
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use AUX for backlight only if eDP 1.4 or later
On Wed, 19 Jul 2017, "Pandiyan, Dhinakaran"
wrote:
> On Wed, 2017-07-19 at 15:59 +0530, Jenny TC wrote:
>> With older panels, AUX pin for backlight doesn't work.
What evidence do you have to back up that claim?
>> On some panels, this causes backlight issues on S3 resume.
>
> What is it that we are missing in the resume path?
>
>> Enable the
>> feature only for eDP1.4 or later.
>
> I can't find the eDP 1.4 requirement in the spec. Regional brightness
> control was added in eDP 1.4, but we don't enable that. My concern is we
> might be missing a real fix by ignoring < eDP 1.4 panels.
Agreed.
This has been going on too long now, with no real effort to get at the
roots of the problem. The right approach is to revert the regressing
commits now, and start over. Reverts posted [1].
BR,
Jani.
[1] https://patchwork.freedesktop.org/series/27623/
>
>
>>
>> Fix-suggested-by: Puthikorn Voravootivat
>
> 1. Please use the "Fixes" tag to refer to the commit that introduced the
> code you are fixing.
> 2. The "Suggested-by" tag is more common to give credits to the person
> who suggested the fix.
> 3. Please use the "Bugzilla" tag to point to the bug that David
> reported.
>
>
>> Signed-off-by: Jenny TC
>> ---
>> drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 6 +-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
>> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
>> index b25cd88..421f31f 100644
>> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
>> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
>> @@ -292,7 +292,7 @@ static int intel_dp_aux_setup_backlight(struct
>> intel_connector *connector,
>> * via PWM pin or using AUX is better than using PWM pin.
>> *
>> * The heuristic to determine that using AUX pin is better than using PWM
>> pin is
>> - * that the panel support any of the feature list here.
>> + * that the panel is eDP 1.4 or later and support any of the feature list
>> here
>> * - Regional backlight brightness adjustment
>> * - Backlight PWM frequency set
>> * - More than 8 bits resolution of brightness level
>> @@ -310,6 +310,10 @@ static int intel_dp_aux_setup_backlight(struct
>> intel_connector *connector,
>> if (!(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
>> return true;
>>
>> +/* Enable this for eDP 1.4 panel or later. */
>> +if (intel_dp->edp_dpcd[0] < DP_EDP_14)
>> +return false;
>> +
>> /* Panel supports regional backlight brightness adjustment */
>> if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_GENERAL_CAP_3,
>>®_val) != 1) {
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Fix scaler init during CRTC HW state readout
== Series Details == Series: series starting with [1/2] drm/i915: Fix scaler init during CRTC HW state readout URL : https://patchwork.freedesktop.org/series/27607/ State : success == Summary == Series 27607v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/27607/revisions/1/mbox/ Test kms_flip: Subgroup basic-flip-vs-modeset: pass -> SKIP (fi-skl-x1585l) fdo#101781 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-j1900) fdo#101705 fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:455s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:425s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:357s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:539s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:510s fi-byt-j1900 total:279 pass:255 dwarn:0 dfail:0 fail:0 skip:24 time:492s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:492s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:598s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:439s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:417s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:414s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:505s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:476s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:461s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:577s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:585s fi-pnv-d510 total:279 pass:221 dwarn:3 dfail:0 fail:0 skip:55 time:559s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:460s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:586s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:468s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:480s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:434s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:474s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:542s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:406s 0fb3fc159dfcd22ce3b81818c3ffb33bcf737936 drm-tip: 2017y-07m-20d-08h-46m-42s UTC integration manifest 5e28a62 drm/i915: Simplify scaler init during CRTC HW readout dddab95 drm/i915: Fix scaler init during CRTC HW state readout == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5240/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v5 0/7] CRC testing with Chamelium improvements
For future reference, please post new versions of the entire series as new threads. When posting new versions of just some individual patches, in-reply-to each patch being replaced is fine. I think this is more clear, and also gives patchwork a better chance to apply the right patches for testing (not that it does igt CI, but that might change). BR, Jani. On Wed, 19 Jul 2017, Paul Kocialkowski wrote: > Changes since v4: > * Moved igt_get_cairo_surface out of the thread function to properly > handle assert failure > * Rebased on top of current master > > Changes since v3: > * Renamed structure used by async crc calculation for more clarity > * Used const qualifier for untouched buffer when hashing > * Split actual calculation to a dedicated function > * Reworked async functions names for more clarity > * Reworked descriptions for better accuracy > * Exported framebuffer cairo surface and use it directly instead of > (unused) png dumping > * Fix how the framebuffer cairo surface is obtained to avoid destroying > it too early > > * Made CRC checking logic common > * Added a check for the same number of words > * Made frame dumping configuration and helpers common > * Added an extended crc to string helper > * Added a chamelium helper for crc checking and frame dumping > * Split the merging of crc functions to a separate patch > * Added support for frame dump path global variable > * Added listing the dumped images in a file, possibly identified with > an id global variable > > The latter allows having one "dump report" file per run, possibly > identified with the id global variable, that indicates which files > are the output, while keeping the possibility to have the same files > for different runs. This allows saving significant disk space when > the images are identified with e.g. their crc, so that duplicate results > only lead to duplicate dump reports and not duplicate images. > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix scaler init during CRTC HW state readout
On Thu, Jul 20, 2017 at 12:25:30PM +0300, Imre Deak wrote:
> On Thu, Jul 20, 2017 at 11:58:35AM +0300, Jani Nikula wrote:
> > On Thu, 20 Jul 2017, Imre Deak wrote:
> > > The scaler allocation code depends on a non-zero default value for the
> > > crtc scaler_id, so make sure we initialize the scaler state accordingly
> > > even if the crtc is off. This fixes at least an initial YUV420 modeset
> > > (added in a follow-up patchset by Shashank) when booting with the screen
> > > off: after the initial HW readout and modeset which enables the scaler a
> > > subsequent modeset will disable the scaler which isn't properly
> > > allocated. This results in a funky HW state where the pipe scaler HW
> > > registers can't be modified and the normally black screen is grey and
> > > shifted to the right or jitters.
> > >
> > > The problem was revealed by Shashank's YUV420 patchset and first
> > > reported by Ville.
> > >
> > > Cc: Shashank Sharma
> > > Cc: Ville Syrjälä
> > > Cc: Chandra Konduru
> > > Cc: Matt Roper
> > > Cc: # 4.11.x
> > > Reported-by: Ville Syrjälä
> > > Fixes: a1b2278e4dfc ("drm/i915: skylake panel fitting using shared
> > > scalers")
> > > Signed-off-by: Imre Deak
> > >
> > > ---
> > >
> > > [ Older stable versions need backporting, so that's for a follow-up ]
> >
> > I thought we'd annotate cc: stable with all the kernels that need the
> > fix, not according to where the fix applies as-is. In this case, it
> > would be v4.2+, right?
>
> Hm, not sure. I know that this won't apply before 4.11 and I will have
> to send a backported version anyway. So wanted to save a redundant turn
> around after the automatic cherry picking to those stable versions
> fail.
>
> Greg, what's the proper tag in this case?
4.2+ and then when you get the "this didn't apply" email, send the
backported patches. That way the stable maintainers know it "should" be
applied there, but it just doesn't seem to work with the existing patch.
thanks,
greg k-h
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Fix an error handling path in 'mock_gem_device()'
== Series Details == Series: drm/i915/selftests: Fix an error handling path in 'mock_gem_device()' URL : https://patchwork.freedesktop.org/series/27604/ State : success == Summary == Series 27604v1 drm/i915/selftests: Fix an error handling path in 'mock_gem_device()' https://patchwork.freedesktop.org/api/1.0/series/27604/revisions/1/mbox/ Test kms_flip: Subgroup basic-flip-vs-modeset: pass -> SKIP (fi-skl-x1585l) fdo#101781 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-j1900) fdo#101705 fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:444s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:432s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:355s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:530s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:512s fi-byt-j1900 total:279 pass:255 dwarn:0 dfail:0 fail:0 skip:24 time:491s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:490s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:604s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:439s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:416s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:412s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:498s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:474s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:468s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:573s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:584s fi-pnv-d510 total:279 pass:221 dwarn:3 dfail:0 fail:0 skip:55 time:563s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:459s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:586s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:471s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:478s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:438s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:470s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:547s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:413s 0fb3fc159dfcd22ce3b81818c3ffb33bcf737936 drm-tip: 2017y-07m-20d-08h-46m-42s UTC integration manifest 5ea16c7 drm/i915/selftests: Fix an error handling path in 'mock_gem_device()' == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5241/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/8] drm/i915: Add NV12 as supported format for sprite plane
> -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Tuesday, July 11, 2017 9:42 PM > To: Srinivas, Vidya > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 7/8] drm/i915: Add NV12 as supported > format for sprite plane > > On Tue, Jul 11, 2017 at 07:40:55PM +0530, Vidya Srinivas wrote: > > From: Chandra Konduru > > > > This patch adds NV12 to list of supported formats for sprite plane. > > > > v2: Rebased (me) > > > > v3: Review comments by Ville addressed > > - Removed skl_plane_formats_with_nv12 and added > > NV12 case in existing skl_plane_formats > > - Added the 10bpc RGB formats > > > > v4: Addressed review comments from Clinton A Taylor > > "Why are we adding 10 bit RGB formats with the NV12 series > patches? > > Trying to set XR30 or AB30 results in error returned even though > > the modes are advertised for the planes" > > - Removed 10bit RGB formats added previously with NV12 series > > > > v5: Missed the Tested-by/Reviewed-by in the previous series > > Adding the same to commit message in this version. > > Addressed review comments from Clinton A Taylor > > "Why are we adding 10 bit RGB formats with the NV12 series > patches? > > Trying to set XR30 or AB30 results in error returned even though > > the modes are advertised for the planes" > > - Previous version has 10bit RGB format removed from VLV formats > > by mistake. Fixing that in this version. > > Removed 10bit RGB formats added previously with NV12 series > > for SKL. > > > > Tested-by: Clinton Taylor > > Reviewed-by: Clinton Taylor > > Signed-off-by: Chandra Konduru > > Signed-off-by: Nabendu Maiti > > Signed-off-by: Vidya Srinivas > > --- > > drivers/gpu/drm/i915/intel_sprite.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c > > b/drivers/gpu/drm/i915/intel_sprite.c > > index 9a6b011..f1d65d9 100644 > > --- a/drivers/gpu/drm/i915/intel_sprite.c > > +++ b/drivers/gpu/drm/i915/intel_sprite.c > > @@ -1078,6 +1078,7 @@ int intel_sprite_set_colorkey(struct drm_device > *dev, void *data, > > DRM_FORMAT_YVYU, > > DRM_FORMAT_UYVY, > > DRM_FORMAT_VYUY, > > + DRM_FORMAT_NV12, > > }; > > That's not correct for pipe C sprites on SKL/KBL/BXT. > > Also like I mentioned earlier at least SKL shouldn't be advertizing NV12 at > all. IIRC you were going to find out what the situation is with the other > platforms. Apologies for the delay. I shall find this and fix before sending the next series with other review comments addressed. Regards Vidya > > > > > struct intel_plane * > > -- > > 1.9.1 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Ville Syrjälä > Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use AUX for backlight only if eDP 1.4 or later
> >> With older panels, AUX pin for backlight doesn't work.
>
> What evidence do you have to back up that claim?
Debugging further it's found that the panel I am having doesn't support AUX
Backlight.
cat /sys/kernel/debug/dri/0/eDP-1/i915_dpcd
...
0701: bb ff 00 00
With below change its working for my panel. But doesn't address issue reported
in
https://bugs.freedesktop.org/show_bug.cgi?id=101619 which seems to have a wrong
DPCD data.
Since we don't have a proper fix for all panels, I agree for revert.
intel_dp_aux_display_control_heuristic(struct intel_connector *connector)
struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
uint8_t reg_val;
+ /* Panel dosn't support enabling AUX Backlight control */
+ if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP)) {
+ return false;
+ }
/* Panel doesn't support adjusting backlight brightness via PWN pin */
if (!(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
return true;
> >> On some panels, this causes backlight issues on S3 resume.
> >
> > What is it that we are missing in the resume path?
> >
> >> Enable the
> >> feature only for eDP1.4 or later.
> >
> > I can't find the eDP 1.4 requirement in the spec. Regional brightness
> > control was added in eDP 1.4, but we don't enable that. My concern is
> > we might be missing a real fix by ignoring < eDP 1.4 panels.
>
> Agreed.
>
> This has been going on too long now, with no real effort to get at the roots
> of
> the problem. The right approach is to revert the regressing commits now,
> and start over. Reverts posted [1].
>
> BR,
> Jani.
>
> [1] https://patchwork.freedesktop.org/series/27623/
>
> >
> >
> >>
> >> Fix-suggested-by: Puthikorn Voravootivat
> >
> > 1. Please use the "Fixes" tag to refer to the commit that introduced
> > the code you are fixing.
> > 2. The "Suggested-by" tag is more common to give credits to the person
> > who suggested the fix.
> > 3. Please use the "Bugzilla" tag to point to the bug that David
> > reported.
> >
> >
> >> Signed-off-by: Jenny TC
> >> ---
> >> drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 6 +-
> >> 1 file changed, 5 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> >> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> >> index b25cd88..421f31f 100644
> >> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> >> @@ -292,7 +292,7 @@ static int intel_dp_aux_setup_backlight(struct
> intel_connector *connector,
> >> * via PWM pin or using AUX is better than using PWM pin.
> >> *
> >> * The heuristic to determine that using AUX pin is better than
> >> using PWM pin is
> >> - * that the panel support any of the feature list here.
> >> + * that the panel is eDP 1.4 or later and support any of the feature
> >> + list here
> >> * - Regional backlight brightness adjustment
> >> * - Backlight PWM frequency set
> >> * - More than 8 bits resolution of brightness level @@ -310,6
> >> +310,10 @@ static int intel_dp_aux_setup_backlight(struct
> intel_connector *connector,
> >>if (!(intel_dp->edp_dpcd[2] &
> DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
> >>return true;
> >>
> >> + /* Enable this for eDP 1.4 panel or later. */
> >> + if (intel_dp->edp_dpcd[0] < DP_EDP_14)
> >> + return false;
> >> +
> >>/* Panel supports regional backlight brightness adjustment */
> >>if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_GENERAL_CAP_3,
> >> ®_val) != 1) {
>
> --
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq
On 18/07/2017 19:48, Patchwork wrote: == Series Details == Series: drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq URL : https://patchwork.freedesktop.org/series/27510/ State : success == Summary == Series 27510v1 drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq https://patchwork.freedesktop.org/api/1.0/series/27510/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-7560u) k.org#196399 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-b: pass -> DMESG-WARN (fi-pnv-d510) fdo#101597 Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-j1900) fdo#101705 +1 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 k.org#196399 https://bugzilla.kernel.org/show_bug.cgi?id=196399 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:440s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:426s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:354s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:530s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:508s fi-byt-j1900 total:279 pass:255 dwarn:0 dfail:0 fail:0 skip:24 time:499s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:489s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:605s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:436s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:422s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:419s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:498s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:467s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:464s fi-kbl-7560u total:279 pass:268 dwarn:1 dfail:0 fail:0 skip:10 time:574s fi-kbl-r total:279 pass:260 dwarn:1 dfail: 0 fail:0 skip:18 time:579s fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 time:559s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:458s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:585s fi-skl-6700k total:279 pass:257 dwarn:4 dfail:0 fail:0 skip:18 time:469s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:481s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:435s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:471s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:541s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:401s 10de1e17faaab452782e5a1baffd1b30a639a261 drm-tip: 2017y-07m-18d-10h-08m-42s UTC integration manifest 3029bd6 drm/i915: s/INTEL_INFO(dev_priv)->gen/INTEL_GEN(dev_priv) in i915_irq Pushed, thanks for the patch and review. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix an error handling path in 'mock_gem_device()'
On 19/07/2017 23:35, Christophe JAILLET wrote:
Goto the right label in case of error, otherwise there is a leak.
This has been introduced by c5cf9a9147ff. In this patch a goto has not been
updated.
Fixes: c5cf9a9147ff ("drm/i915: Create a kmem_cache to allocate struct i915_priolist
from")
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 627e2aa09766..8cdec455cf7d 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -206,7 +206,7 @@ struct drm_i915_private *mock_gem_device(void)
mkwrite_device_info(i915)->ring_mask = BIT(0);
i915->engine[RCS] = mock_engine(i915, "mock");
if (!i915->engine[RCS])
- goto err_dependencies;
+ goto err_priorities;
i915->kernel_context = mock_context(i915, NULL);
if (!i915->kernel_context)
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Keep a small stash of preallocated WC pages
== Series Details == Series: drm/i915: Keep a small stash of preallocated WC pages URL : https://patchwork.freedesktop.org/series/27622/ State : success == Summary == Series 27622v1 drm/i915: Keep a small stash of preallocated WC pages https://patchwork.freedesktop.org/api/1.0/series/27622/revisions/1/mbox/ Test kms_flip: Subgroup basic-flip-vs-modeset: pass -> SKIP (fi-skl-x1585l) fdo#101781 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-j1900) fdo#101705 fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:444s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:439s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:354s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:511s fi-byt-j1900 total:279 pass:255 dwarn:0 dfail:0 fail:0 skip:24 time:493s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:485s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:601s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:434s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:424s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:420s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:505s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:475s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:473s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:584s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:582s fi-pnv-d510 total:279 pass:221 dwarn:3 dfail:0 fail:0 skip:55 time:561s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:457s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:584s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:482s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:474s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:436s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:471s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:547s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:400s fi-bsw-n3050 failed to collect. IGT log at Patchwork_5242/fi-bsw-n3050/igt.log 0fb3fc159dfcd22ce3b81818c3ffb33bcf737936 drm-tip: 2017y-07m-20d-08h-46m-42s UTC integration manifest 45c2738 drm/i915: Keep a small stash of preallocated WC pages == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5242/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix an error handling path in 'mock_gem_device()'
Quoting Tvrtko Ursulin (2017-07-20 11:09:53)
>
> On 19/07/2017 23:35, Christophe JAILLET wrote:
> > Goto the right label in case of error, otherwise there is a leak.
> > This has been introduced by c5cf9a9147ff. In this patch a goto has not been
> > updated.
> >
> > Fixes: c5cf9a9147ff ("drm/i915: Create a kmem_cache to allocate struct
> > i915_priolist from")
> > Signed-off-by: Christophe JAILLET
> > ---
> > drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> > b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> > index 627e2aa09766..8cdec455cf7d 100644
> > --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> > +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> > @@ -206,7 +206,7 @@ struct drm_i915_private *mock_gem_device(void)
> > mkwrite_device_info(i915)->ring_mask = BIT(0);
> > i915->engine[RCS] = mock_engine(i915, "mock");
> > if (!i915->engine[RCS])
> > - goto err_dependencies;
> > + goto err_priorities;
> >
> > i915->kernel_context = mock_context(i915, NULL);
> > if (!i915->kernel_context)
>
> Reviewed-by: Tvrtko Ursulin
Thanks for the fix and review, pushed.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/selftests: Use mul_u32_u32() for 32b x 32b -> 64b result
As realised by commit 9e3d6223d209 ("math64, timers: Fix 32bit
mul_u64_u32_shr() and friends"), GCC does not always generate ideal code
for performing a 32b x 32b multiply returning a 64b result (i.e. where
we idiomatically use u64 result = (u64)x * (u32)x).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/i915_gem_timeline.c | 2 +-
drivers/gpu/drm/i915/selftests/i915_random.c | 5 -
drivers/gpu/drm/i915/selftests/i915_random.h | 5 +
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
b/drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
index 7a44dab631b8..4795877abe56 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
@@ -121,7 +121,7 @@ static int igt_sync(void *arg)
static unsigned int random_engine(struct rnd_state *rnd)
{
- return ((u64)prandom_u32_state(rnd) * I915_NUM_ENGINES) >> 32;
+ return i915_prandom_u32_max_state(I915_NUM_ENGINES, rnd);
}
static int bench_sync(void *arg)
diff --git a/drivers/gpu/drm/i915/selftests/i915_random.c
b/drivers/gpu/drm/i915/selftests/i915_random.c
index d044bf9a6feb..ea0f5dbc0eb7 100644
--- a/drivers/gpu/drm/i915/selftests/i915_random.c
+++ b/drivers/gpu/drm/i915/selftests/i915_random.c
@@ -41,11 +41,6 @@ u64 i915_prandom_u64_state(struct rnd_state *rnd)
return x;
}
-static inline u32 i915_prandom_u32_max_state(u32 ep_ro, struct rnd_state
*state)
-{
- return upper_32_bits((u64)prandom_u32_state(state) * ep_ro);
-}
-
void i915_random_reorder(unsigned int *order, unsigned int count,
struct rnd_state *state)
{
diff --git a/drivers/gpu/drm/i915/selftests/i915_random.h
b/drivers/gpu/drm/i915/selftests/i915_random.h
index 6c9379871384..7dffedc501ca 100644
--- a/drivers/gpu/drm/i915/selftests/i915_random.h
+++ b/drivers/gpu/drm/i915/selftests/i915_random.h
@@ -43,6 +43,11 @@
u64 i915_prandom_u64_state(struct rnd_state *rnd);
+static inline u32 i915_prandom_u32_max_state(u32 ep_ro, struct rnd_state
*state)
+{
+ return upper_32_bits(mul_u32_u32(prandom_u32_state(state), ep_ro));
+}
+
unsigned int *i915_random_order(unsigned int count,
struct rnd_state *state);
void i915_random_reorder(unsigned int *order,
--
2.13.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v5 0/7] CRC testing with Chamelium improvements
On 20/07/17 12:39, Jani Nikula wrote: For future reference, please post new versions of the entire series as new threads. When posting new versions of just some individual patches, in-reply-to each patch being replaced is fine. I think this is more clear, and also gives patchwork a better chance to apply the right patches for testing (not that it does igt CI, but that might change). Spoiler: we are working on having pre-merge for IGT too ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Use mul_u32_u32() for 32b x 32b -> 64b result
As realised by commit 9e3d6223d209 ("math64, timers: Fix 32bit
mul_u64_u32_shr() and friends"), GCC does not always generate ideal code
for performing a 32b x 32b multiply returning a 64b result (i.e. where
we idiomatically use u64 result = (u64)x * (u32)x). This catches a
couple of instances in the display code using (u64)x * (u32)y.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_tv.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8bd8ed362e1a..c66749e8f75e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10022,7 +10022,7 @@ int intel_dotclock_calculate(int link_freq,
if (!m_n->link_n)
return 0;
- return div_u64((u64)m_n->link_m * link_freq, m_n->link_n);
+ return div_u64(mul_u32_u32(m_n->link_m, link_freq), m_n->link_n);
}
static void ironlake_pch_clock_get(struct intel_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 784df024e230..38087d0a4465 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1385,7 +1385,7 @@ intel_tv_get_modes(struct drm_connector *connector)
mode_ptr->vsync_end = mode_ptr->vsync_start + 1;
mode_ptr->vtotal = vactive_s + 33;
- tmp = (u64) tv_mode->refresh * mode_ptr->vtotal;
+ tmp = mul_u32_u32(tv_mode->refresh, mode_ptr->vtotal);
tmp *= mode_ptr->htotal;
tmp = div_u64(tmp, 100);
mode_ptr->clock = (int) tmp;
--
2.13.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix scaler init during CRTC HW state readout
On Thu, Jul 20, 2017 at 11:41:35AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 20, 2017 at 12:25:30PM +0300, Imre Deak wrote:
> > On Thu, Jul 20, 2017 at 11:58:35AM +0300, Jani Nikula wrote:
> > > On Thu, 20 Jul 2017, Imre Deak wrote:
> > > > The scaler allocation code depends on a non-zero default value for the
> > > > crtc scaler_id, so make sure we initialize the scaler state accordingly
> > > > even if the crtc is off. This fixes at least an initial YUV420 modeset
> > > > (added in a follow-up patchset by Shashank) when booting with the screen
> > > > off: after the initial HW readout and modeset which enables the scaler a
> > > > subsequent modeset will disable the scaler which isn't properly
> > > > allocated. This results in a funky HW state where the pipe scaler HW
> > > > registers can't be modified and the normally black screen is grey and
> > > > shifted to the right or jitters.
> > > >
> > > > The problem was revealed by Shashank's YUV420 patchset and first
> > > > reported by Ville.
> > > >
> > > > Cc: Shashank Sharma
> > > > Cc: Ville Syrjälä
> > > > Cc: Chandra Konduru
> > > > Cc: Matt Roper
> > > > Cc: # 4.11.x
> > > > Reported-by: Ville Syrjälä
> > > > Fixes: a1b2278e4dfc ("drm/i915: skylake panel fitting using shared
> > > > scalers")
> > > > Signed-off-by: Imre Deak
> > > >
> > > > ---
> > > >
> > > > [ Older stable versions need backporting, so that's for a follow-up ]
> > >
> > > I thought we'd annotate cc: stable with all the kernels that need the
> > > fix, not according to where the fix applies as-is. In this case, it
> > > would be v4.2+, right?
> >
> > Hm, not sure. I know that this won't apply before 4.11 and I will have
> > to send a backported version anyway. So wanted to save a redundant turn
> > around after the automatic cherry picking to those stable versions
> > fail.
> >
> > Greg, what's the proper tag in this case?
>
> 4.2+ and then when you get the "this didn't apply" email, send the
> backported patches. That way the stable maintainers know it "should" be
> applied there, but it just doesn't seem to work with the existing patch.
Ok, will resend with that, thanks for catching this and clarifying.
--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v5 0/7] CRC testing with Chamelium improvements
On Thu, 2017-07-20 at 12:39 +0300, Jani Nikula wrote: > For future reference, please post new versions of the entire series as > new threads. When posting new versions of just some individual > patches, > in-reply-to each patch being replaced is fine. I think this is more > clear, and also gives patchwork a better chance to apply the right > patches for testing (not that it does igt CI, but that might change). Quoting Lyude from an earlier exchange: * When you're doing a new revision of a patch series, it's helpful to keep it in the same email thread as the original v1 so it's easier to keep track of in people's mail clients (as well as avoiding accidentally reviewing older patch versions. I actually prefer it your way (posting as new threads), so I suppose I'll do that in the future, if Lyude doesn't have any strong objection about it. Cheers, Paul > On Wed, 19 Jul 2017, Paul Kocialkowski com> wrote: > > Changes since v4: > > * Moved igt_get_cairo_surface out of the thread function to properly > > handle assert failure > > * Rebased on top of current master > > > > Changes since v3: > > * Renamed structure used by async crc calculation for more clarity > > * Used const qualifier for untouched buffer when hashing > > * Split actual calculation to a dedicated function > > * Reworked async functions names for more clarity > > * Reworked descriptions for better accuracy > > * Exported framebuffer cairo surface and use it directly instead of > > (unused) png dumping > > * Fix how the framebuffer cairo surface is obtained to avoid > > destroying > > it too early > > > > * Made CRC checking logic common > > * Added a check for the same number of words > > * Made frame dumping configuration and helpers common > > * Added an extended crc to string helper > > * Added a chamelium helper for crc checking and frame dumping > > * Split the merging of crc functions to a separate patch > > * Added support for frame dump path global variable > > * Added listing the dumped images in a file, possibly identified > > with > > an id global variable > > > > The latter allows having one "dump report" file per run, possibly > > identified with the id global variable, that indicates which files > > are the output, while keeping the possibility to have the same files > > for different runs. This allows saving significant disk space when > > the images are identified with e.g. their crc, so that duplicate > > results > > only lead to duplicate dump reports and not duplicate images. > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- Paul Kocialkowski Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo, Finland ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915: Fix scaler init during CRTC HW state readout
The scaler allocation code depends on a non-zero default value for the
crtc scaler_id, so make sure we initialize the scaler state accordingly
even if the crtc is off. This fixes at least an initial YUV420 modeset
(added in a follow-up patchset by Shashank) when booting with the screen
off: after the initial HW readout and modeset which enables the scaler a
subsequent modeset will disable the scaler which isn't properly
allocated. This results in a funky HW state where the pipe scaler HW
registers can't be modified and the normally black screen is grey and
shifted to the right or jitters.
The problem was revealed by Shashank's YUV420 patchset and first
reported by Ville.
v2:
- In the stable tag also include versions which need backporting (Jani)
Cc: Jani Nikula
Cc: Shashank Sharma
Cc: Ville Syrjälä
Cc: Chandra Konduru
Cc: Matt Roper
Cc: # 4.2.x
Reported-by: Ville Syrjälä
Fixes: a1b2278e4dfc ("drm/i915: skylake panel fitting using shared scalers")
Signed-off-by: Imre Deak
---
[ Stable versions before 4.11 need backporting, so that's for a follow-up ]
---
drivers/gpu/drm/i915/intel_display.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7774f3465fbc..8a38e64b1931 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9132,6 +9132,13 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
u64 power_domain_mask;
bool active;
+ if (INTEL_GEN(dev_priv) >= 9) {
+ intel_crtc_init_scalers(crtc, pipe_config);
+
+ pipe_config->scaler_state.scaler_id = -1;
+ pipe_config->scaler_state.scaler_users &= ~(1 <<
SKL_CRTC_INDEX);
+ }
+
power_domain = POWER_DOMAIN_PIPE(crtc->pipe);
if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
return false;
@@ -9160,13 +9167,6 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
pipe_config->gamma_mode =
I915_READ(GAMMA_MODE(crtc->pipe)) & GAMMA_MODE_MODE_MASK;
- if (INTEL_GEN(dev_priv) >= 9) {
- intel_crtc_init_scalers(crtc, pipe_config);
-
- pipe_config->scaler_state.scaler_id = -1;
- pipe_config->scaler_state.scaler_users &= ~(1 <<
SKL_CRTC_INDEX);
- }
-
power_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe);
if (intel_display_power_get_if_enabled(dev_priv, power_domain)) {
power_domain_mask |= BIT_ULL(power_domain);
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/7] drm/i915: Avoid the gpu reset vs. modeset deadlock
... using the biggest hammer we have. This is essentially a weaponized
version of the timeout-based wedging Chris added in
commit 36703e79a982c8ce5a8e43833291f2719e92d0d1
Author: Chris Wilson
Date: Thu Jun 22 11:56:25 2017 +0100
drm/i915: Break modeset deadlocks on reset
Because defense-in-depth is good it's good to still have both. Also
note that with the locking change we can now restrict this a lot (old
gpus and special testing only), so this doesn't kill the TDR benefits
on at least anything remotely modern.
And futuremore with a few tricks it should be possible to make a much
more educated guess about whether an atomic commit is stuck waiting on
the gpu (atomic_t counting the pending i915_sw_fence used by the
atomic modeset code should do it), so we can improve this.
But for now just start with something that is guaranteed to recover
faster, for much better CI througput.
This defacto reverts TDR on these platforms, but there's not really a
single commit to specify as the sole offender.
v2: Add a debug message to explain what's going on. We can't DRM_ERROR
because that spams CI. And the timeout based fallback still prints a
DRM_ERROR, in case something goes wrong.
Fixes: 4680816be336 ("drm/i915: Wait first for submission, before waiting for
request completion")
Fixes: 221fe7994554 ("drm/i915: Perform a direct reset of the GPU from the
waiter")
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 02b1f4966049..995522e40ec1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3471,6 +3471,12 @@ void intel_prepare_reset(struct drm_i915_private
*dev_priv)
!gpu_reset_clobbers_display(dev_priv))
return;
+ /* We have a modeset vs reset deadlock, defensively unbreak it.
+*
+* FIXME: We can do a _lot_ better, this is just a first iteration.*/
+ i915_gem_set_wedged(dev_priv);
+ DRM_DEBUG_DRIVER("Wedging GPU to avoid deadlocks with pending modeset
updates\n");
+
/*
* Need mode_config.mutex so that we don't
* trample ongoing ->detect() and whatnot.
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/7] drm/i915: More surgically unbreak the modeset vs reset deadlock
There's no reason to entirely wedge the gpu, for the minimal deadlock
bugfix we only need to unbreak/decouple the atomic commit from the gpu
reset. The simplest way to fix that is by replacing the
unconditional fence wait a the top of commit_tail by a wait which
completes either when the fences are done (normal case, or when a
reset doesn't need to touch the display state). Or when the gpu reset
needs to force-unblock all pending modeset states.
The lesser source of deadlocks is when we try to pin a new framebuffer
and run into a stall. There's a bunch of places this can happen, like
eviction, changing the caching mode, acquiring a fence on older
platforms. And we can't just break the depency loop and keep going,
the only way would be to break out and restart. But the problem with
that approach is that we must stall for the reset to complete before
we grab any locks, and with the atomic infrastructure that's a bit
tricky. The only place is the ioctl code, and we don't want to insert
code into e.g. the BUSY ioctl. Hence for that problem just create a
critical section, and if any code is in there, wedge the GPU. For the
steady-state this should never be a problem.
Note that in both cases TDR itself keeps working, so from a userspace
pov this trickery isn't observable. Users themselvs might spot a short
glitch while the rendering is catching up again, but that's still
better than pre-TDR where we've thrown away all the rendering,
including innocent batches. Also, this fixes the regression TDR
introduced of making gpu resets deadlock-prone when we do need to
touch the display.
One thing I noticed is that gpu_error.flags seems to use both our own
wait-queue in gpu_error.wait_queue, and the generic wait_on_bit
facilities. Not entirely sure why this inconsistency exists, I just
picked one style.
A possible future avenue could be to insert the gpu reset in-between
ongoing modeset changes, which would avoid the momentary glitch. But
that's a lot more work to implement in the atomic commit machinery,
and given that we only need this for pre-g4x hw, of questionable
utility just for the sake of polishing gpu reset even more on those
old boxes. It might be useful for other features though.
v2: Rebase onto 4.13 with a s/wait_queue_t/struct wait_queue_entry/.
v3: Really emabarrassing fixup, I checked the wrong bit and broke the
unbreak/wakeup logic.
v4: Also handle deadlocks in pin_to_display.
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/intel_display.c | 45 +++-
2 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 07e98b07c5bc..9b055deca36d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1505,6 +1505,8 @@ struct i915_gpu_error {
/* Protected by the above dev->gpu_error.lock. */
struct i915_gpu_state *first_error;
+ atomic_t pending_fb_pin;
+
unsigned long missed_irq_rings;
/**
@@ -1564,6 +1566,7 @@ struct i915_gpu_error {
unsigned long flags;
#define I915_RESET_BACKOFF 0
#define I915_RESET_HANDOFF 1
+#define I915_RESET_MODESET 2
#define I915_WEDGED(BITS_PER_LONG - 1)
#define I915_RESET_ENGINE (I915_WEDGED - I915_NUM_ENGINES)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f6bd6282d7f7..63ea8d6b2ebd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2162,6 +2162,8 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
unsigned int rotation)
*/
intel_runtime_pm_get(dev_priv);
+ atomic_inc(&dev_priv->gpu_error.pending_fb_pin);
+
vma = i915_gem_object_pin_to_display_plane(obj, alignment, &view);
if (IS_ERR(vma))
goto err;
@@ -2189,6 +2191,8 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
unsigned int rotation)
i915_vma_get(vma);
err:
+ atomic_dec(&dev_priv->gpu_error.pending_fb_pin);
+
intel_runtime_pm_put(dev_priv);
return vma;
}
@@ -3471,11 +3475,14 @@ void intel_prepare_reset(struct drm_i915_private
*dev_priv)
!gpu_reset_clobbers_display(dev_priv))
return;
- /* We have a modeset vs reset deadlock, defensively unbreak it.
-*
-* FIXME: We can do a _lot_ better, this is just a first iteration.*/
- i915_gem_set_wedged(dev_priv);
- DRM_DEBUG_DRIVER("Wedging GPU to avoid deadlocks with pending modeset
updates\n");
+ /* We have a modeset vs reset deadlock, defensively unbreak it. */
+ set_bit(I915_RESET_MODESET, &dev_priv->gpu_error.flags);
+ wake_up_all(&dev_priv->gpu_error.wait_queue);
+
+ if (atomic_read(&dev_priv->gpu_error.pending_fb_pin)) {
+ DRM_DEBUG_KMS("Modeset p
[Intel-gfx] [PATCH 7/7] drm/i915: Drop unpin stall in atomic_prepare_commit
The core already does this in setup_commit(). With this we can also
remove the unpin_work_count since it's the last user, and also remove
the loop since that was only used for stalling against legacy flips.
v2: Amend commit message a bit (Chris).
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 13 +
drivers/gpu/drm/i915/intel_drv.h | 2 --
2 files changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c10966ebf6fc..1009ad9d8221 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11830,18 +11830,7 @@ static int intel_atomic_check(struct drm_device *dev,
static int intel_atomic_prepare_commit(struct drm_device *dev,
struct drm_atomic_state *state)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
- struct drm_crtc_state *crtc_state;
- struct drm_crtc *crtc;
- int i, ret;
-
- for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
- if (state->legacy_cursor_update)
- continue;
-
- if (atomic_read(&to_intel_crtc(crtc)->unpin_work_count) >= 2)
- flush_workqueue(dev_priv->wq);
- }
+ int ret;
ret = mutex_lock_interruptible(&dev->struct_mutex);
if (ret)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9cb7e781e863..96402c06e295 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -798,8 +798,6 @@ struct intel_crtc {
unsigned long long enabled_power_domains;
struct intel_overlay *overlay;
- atomic_t unpin_work_count;
-
/* Display surface base address adjustement for pageflips. Note that on
* gen4+ this only adjusts up to a tile, offsets within a tile are
* handled in the hw itself (with the TILEOFF register). */
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/7] drm/i915: adjust has_pending_fb_unpin to atomic
A bit an oversight - the current code did nothing, since only
legacy flips used the unpin_work_count and assorted logic.
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fcbd4b7fa96c..bd0488a72503 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4149,21 +4149,22 @@ static void ironlake_fdi_disable(struct drm_crtc *crtc)
bool intel_has_pending_fb_unpin(struct drm_i915_private *dev_priv)
{
- struct intel_crtc *crtc;
-
- /* Note that we don't need to be called with mode_config.lock here
-* as our list of CRTC objects is static for the lifetime of the
-* device and so cannot disappear as we iterate. Similarly, we can
-* happily treat the predicates as racy, atomic checks as userspace
-* cannot claim and pin a new fb without at least acquring the
-* struct_mutex and so serialising with us.
-*/
- for_each_intel_crtc(&dev_priv->drm, crtc) {
- if (atomic_read(&crtc->unpin_work_count) == 0)
+ struct drm_crtc *crtc;
+ bool cleanup_done;
+
+ drm_for_each_crtc(crtc, &dev_priv->drm) {
+ struct drm_crtc_commit *commit;
+ spin_lock(&crtc->commit_lock);
+ commit = list_first_entry_or_null(&crtc->commit_list,
+ struct drm_crtc_commit,
commit_entry);
+ cleanup_done = commit ?
+ try_wait_for_completion(&commit->cleanup_done) : true;
+ spin_unlock(&crtc->commit_lock);
+
+ if (cleanup_done)
continue;
- if (crtc->flip_work)
- intel_wait_for_vblank(dev_priv, crtc->pipe);
+ drm_crtc_wait_one_vblank(crtc);
return true;
}
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/7] drm/i915: Rip out legacy page_flip completion/irq handling
All these races and things are now solved through the vblank evasion
trick, plus event handling is done using normal vblank even processing
and drm_crtc_arm_vblank_event. We can get rid of all this complexity.
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 151
drivers/gpu/drm/i915/intel_display.c | 215 ---
drivers/gpu/drm/i915/intel_drv.h | 3 -
3 files changed, 22 insertions(+), 347 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f0cb278cee8b..b64c89e0fbf1 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1708,18 +1708,6 @@ static void gen9_guc_irq_handler(struct drm_i915_private
*dev_priv, u32 gt_iir)
}
}
-static bool intel_pipe_handle_vblank(struct drm_i915_private *dev_priv,
-enum pipe pipe)
-{
- bool ret;
-
- ret = drm_handle_vblank(&dev_priv->drm, pipe);
- if (ret)
- intel_finish_page_flip_mmio(dev_priv, pipe);
-
- return ret;
-}
-
static void valleyview_pipestat_irq_ack(struct drm_i915_private *dev_priv,
u32 iir, u32 pipe_stats[I915_MAX_PIPES])
{
@@ -1784,12 +1772,8 @@ static void valleyview_pipestat_irq_handler(struct
drm_i915_private *dev_priv,
enum pipe pipe;
for_each_pipe(dev_priv, pipe) {
- if (pipe_stats[pipe] & PIPE_START_VBLANK_INTERRUPT_STATUS &&
- intel_pipe_handle_vblank(dev_priv, pipe))
- intel_check_page_flip(dev_priv, pipe);
-
- if (pipe_stats[pipe] & PLANE_FLIP_DONE_INT_STATUS_VLV)
- intel_finish_page_flip_cs(dev_priv, pipe);
+ if (pipe_stats[pipe] & PIPE_START_VBLANK_INTERRUPT_STATUS)
+ drm_handle_vblank(&dev_priv->drm, pipe);
if (pipe_stats[pipe] & PIPE_CRC_DONE_INTERRUPT_STATUS)
i9xx_pipe_crc_irq_handler(dev_priv, pipe);
@@ -2241,19 +2225,14 @@ static void ilk_display_irq_handler(struct
drm_i915_private *dev_priv,
DRM_ERROR("Poison interrupt\n");
for_each_pipe(dev_priv, pipe) {
- if (de_iir & DE_PIPE_VBLANK(pipe) &&
- intel_pipe_handle_vblank(dev_priv, pipe))
- intel_check_page_flip(dev_priv, pipe);
+ if (de_iir & DE_PIPE_VBLANK(pipe))
+ drm_handle_vblank(&dev_priv->drm, pipe);
if (de_iir & DE_PIPE_FIFO_UNDERRUN(pipe))
intel_cpu_fifo_underrun_irq_handler(dev_priv, pipe);
if (de_iir & DE_PIPE_CRC_DONE(pipe))
i9xx_pipe_crc_irq_handler(dev_priv, pipe);
-
- /* plane/pipes map 1:1 on ilk+ */
- if (de_iir & DE_PLANE_FLIP_DONE(pipe))
- intel_finish_page_flip_cs(dev_priv, pipe);
}
/* check event from PCH */
@@ -2315,13 +2294,8 @@ static void ivb_display_irq_handler(struct
drm_i915_private *dev_priv,
intel_opregion_asle_intr(dev_priv);
for_each_pipe(dev_priv, pipe) {
- if (de_iir & (DE_PIPE_VBLANK_IVB(pipe)) &&
- intel_pipe_handle_vblank(dev_priv, pipe))
- intel_check_page_flip(dev_priv, pipe);
-
- /* plane/pipes map 1:1 on ilk+ */
- if (de_iir & DE_PLANE_FLIP_DONE_IVB(pipe))
- intel_finish_page_flip_cs(dev_priv, pipe);
+ if (de_iir & (DE_PIPE_VBLANK_IVB(pipe)))
+ drm_handle_vblank(&dev_priv->drm, pipe);
}
/* check event from PCH */
@@ -2502,7 +2476,7 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
u32 master_ctl)
}
for_each_pipe(dev_priv, pipe) {
- u32 flip_done, fault_errors;
+ u32 fault_errors;
if (!(master_ctl & GEN8_DE_PIPE_IRQ(pipe)))
continue;
@@ -2516,18 +2490,8 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
u32 master_ctl)
ret = IRQ_HANDLED;
I915_WRITE(GEN8_DE_PIPE_IIR(pipe), iir);
- if (iir & GEN8_PIPE_VBLANK &&
- intel_pipe_handle_vblank(dev_priv, pipe))
- intel_check_page_flip(dev_priv, pipe);
-
- flip_done = iir;
- if (INTEL_INFO(dev_priv)->gen >= 9)
- flip_done &= GEN9_PIPE_PLANE1_FLIP_DONE;
- else
- flip_done &= GEN8_PIPE_PRIMARY_FLIP_DONE;
-
- if (flip_done)
- intel_finish_page_flip_cs(dev_priv, pipe);
+ if (iir & GEN8_PIPE_VBLANK)
+ drm_handle_vblank(&dev_priv->drm, pipe);
if (iir & GEN8_PIPE_CDCLK_CRC
[Intel-gfx] [PATCH 2/7] drm/i915: Push i915_sw_fence_wait into the nonblocking atomic commit
Blocking in a worker is ok, that's what the unbound_wq is for. And it
unifies the paths between the blocking and nonblocking commit, giving
me just one path where I have to implement the deadlock avoidance
trickery in the next patch.
I first tried to implement the following patch without this rework, but
force-completing i915_sw_fence creates some serious challenges around
properly cleaning things up. So wasn't a feasible short-term approach.
Another approach would be to simple keep track of all pending atomic
commit work items and manually queue them from the reset code. With the
caveat that double-queue in case we race with the i915_sw_fence must be
avoided. Given all that, taking the cost of a double schedule in atomic
for the short-term fix is the best approach, but can be changed in the
future of course.
v2: Amend commit message (Chris).
Reviewed-by: Maarten Lankhorst
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Joonas Lahtinen
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 995522e40ec1..f6bd6282d7f7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12394,6 +12394,8 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
unsigned crtc_vblank_mask = 0;
int i;
+ i915_sw_fence_wait(&intel_state->commit_ready);
+
drm_atomic_helper_wait_for_dependencies(state);
if (intel_state->modeset)
@@ -12561,10 +12563,7 @@ intel_atomic_commit_ready(struct i915_sw_fence *fence,
switch (notify) {
case FENCE_COMPLETE:
- if (state->base.commit_work.func)
- queue_work(system_unbound_wq, &state->base.commit_work);
break;
-
case FENCE_FREE:
{
struct intel_atomic_helper *helper =
@@ -12668,14 +12667,14 @@ static int intel_atomic_commit(struct drm_device *dev,
}
drm_atomic_state_get(state);
- INIT_WORK(&state->commit_work,
- nonblock ? intel_atomic_commit_work : NULL);
+ INIT_WORK(&state->commit_work, intel_atomic_commit_work);
i915_sw_fence_commit(&intel_state->commit_ready);
- if (!nonblock) {
- i915_sw_fence_wait(&intel_state->commit_ready);
+ if (nonblock)
+ queue_work(system_unbound_wq, &state->commit_work);
+ else
intel_atomic_commit_tail(state);
- }
+
return 0;
}
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/7] drm/i915: Remove intel_flip_work infrastructure
This gets rid of all the interactions between the legacy flip code and
the modeset code. Yay!
This highlights an ommission in the atomic paths, where we fail to
apply a boost to the pending rendering when we miss the target vblank.
But the existing code is still dead and can be removed.
v2: Note that the boosting doesn't work in atomic (Chris).
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 70 -
drivers/gpu/drm/i915/i915_drv.c | 1 -
drivers/gpu/drm/i915/i915_drv.h | 4 --
drivers/gpu/drm/i915/i915_gem.c | 2 -
drivers/gpu/drm/i915/intel_display.c | 117 +--
drivers/gpu/drm/i915/intel_drv.h | 21 +--
drivers/gpu/drm/i915/intel_sprite.c | 8 +--
7 files changed, 3 insertions(+), 220 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2ef75c1a6119..c25f42c60d61 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -543,75 +543,6 @@ static int i915_gem_gtt_info(struct seq_file *m, void
*data)
return 0;
}
-static int i915_gem_pageflip_info(struct seq_file *m, void *data)
-{
- struct drm_i915_private *dev_priv = node_to_i915(m->private);
- struct drm_device *dev = &dev_priv->drm;
- struct intel_crtc *crtc;
- int ret;
-
- ret = mutex_lock_interruptible(&dev->struct_mutex);
- if (ret)
- return ret;
-
- for_each_intel_crtc(dev, crtc) {
- const char pipe = pipe_name(crtc->pipe);
- const char plane = plane_name(crtc->plane);
- struct intel_flip_work *work;
-
- spin_lock_irq(&dev->event_lock);
- work = crtc->flip_work;
- if (work == NULL) {
- seq_printf(m, "No flip due on pipe %c (plane %c)\n",
- pipe, plane);
- } else {
- u32 pending;
- u32 addr;
-
- pending = atomic_read(&work->pending);
- if (pending) {
- seq_printf(m, "Flip ioctl preparing on pipe %c
(plane %c)\n",
- pipe, plane);
- } else {
- seq_printf(m, "Flip pending (waiting for vsync)
on pipe %c (plane %c)\n",
- pipe, plane);
- }
- if (work->flip_queued_req) {
- struct intel_engine_cs *engine =
work->flip_queued_req->engine;
-
- seq_printf(m, "Flip queued on %s at seqno %x,
last submitted seqno %x [current breadcrumb %x], completed? %d\n",
- engine->name,
- work->flip_queued_req->global_seqno,
- intel_engine_last_submit(engine),
- intel_engine_get_seqno(engine),
-
i915_gem_request_completed(work->flip_queued_req));
- } else
- seq_printf(m, "Flip not associated with any
ring\n");
- seq_printf(m, "Flip queued on frame %d, (was ready on
frame %d), now %d\n",
- work->flip_queued_vblank,
- work->flip_ready_vblank,
- intel_crtc_get_vblank_counter(crtc));
- seq_printf(m, "%d prepares\n",
atomic_read(&work->pending));
-
- if (INTEL_GEN(dev_priv) >= 4)
- addr =
I915_HI_DISPBASE(I915_READ(DSPSURF(crtc->plane)));
- else
- addr = I915_READ(DSPADDR(crtc->plane));
- seq_printf(m, "Current scanout address 0x%08x\n", addr);
-
- if (work->pending_flip_obj) {
- seq_printf(m, "New framebuffer address
0x%08lx\n", (long)work->gtt_offset);
- seq_printf(m, "MMIO update completed? %d\n",
addr == work->gtt_offset);
- }
- }
- spin_unlock_irq(&dev->event_lock);
- }
-
- mutex_unlock(&dev->struct_mutex);
-
- return 0;
-}
-
static int i915_gem_batch_pool_info(struct seq_file *m, void *data)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -4854,7 +4785,6 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_gem_gtt", i915_gem_gtt_info, 0},
{"i915_gem_pin_display", i915_gem_gtt_info, 0, (void *)1},
{"i915_gem_stolen", i915_gem_stolen_list_info },
- {"i915_gem_pageflip", i915_gem_pageflip_info, 0
[Intel-gfx] [PATCH] drm/i915: Remove assertion from raw __i915_vma_unpin()
After we detect a i915_vma pin overflow, we call __i915_vma_unpin to
cleanup. However, on an overflow the pin_count bitfield will be zero,
triggering an assertion, even though we the intention is to merely warn
and report the error back to the user (as historically the culprit has
be a leak in the display code).
Fixes: 20dfbde463c8 ("drm/i915: Wrap vma->pin_count accessors with small inline
helpers")
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_vma.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 4a673fc1a432..20cf272c97b1 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -284,12 +284,12 @@ static inline void __i915_vma_pin(struct i915_vma *vma)
static inline void __i915_vma_unpin(struct i915_vma *vma)
{
- GEM_BUG_ON(!i915_vma_is_pinned(vma));
vma->flags--;
}
static inline void i915_vma_unpin(struct i915_vma *vma)
{
+ GEM_BUG_ON(!i915_vma_is_pinned(vma));
GEM_BUG_ON(!drm_mm_node_allocated(&vma->node));
__i915_vma_unpin(vma);
}
--
2.13.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: revert DPCD backlight and DBC enabling by default
== Series Details == Series: drm/i915: revert DPCD backlight and DBC enabling by default URL : https://patchwork.freedesktop.org/series/27623/ State : success == Summary == Series 27623v1 drm/i915: revert DPCD backlight and DBC enabling by default https://patchwork.freedesktop.org/api/1.0/series/27623/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:445s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:431s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:353s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:538s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:514s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:486s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:487s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:602s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:435s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:414s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:412s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:501s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:476s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:475s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:579s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:579s fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 time:560s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:468s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:585s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:469s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:482s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:435s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:497s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:539s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:407s 948c3bddbe7245970c684749ba5d72370cd2 drm-tip: 2017y-07m-20d-10h-52m-43s UTC integration manifest 682e3e2 Revert "drm/i915: Add heuristic to determine better way to adjust brightness" 70cbf1b Revert "drm/i915: Add option to support dynamic backlight via DPCD" == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5244/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Only mark the execobject as pinned on success
If we fail to acquire a fence (for old school fenced GPU access) then we
unwind the vma reservation, including its pin. However, we were making
the execobject as holding the pin before erring out, leading to a double
unpin:
[ 3193.991802] kernel BUG at drivers/gpu/drm/i915/i915_vma.h:287!
[ 3193.998131] invalid opcode: [#1] PREEMPT SMP
[ 3194.002816] Modules linked in: snd_hda_intel i915 vgem snd_hda_codec_analog
snd_hda_codec_generic coretemp snd_hda_codec snd_hwdep snd_hda_core snd_pcm
lpc_ich mei_me e1000e mei prime_numbers ptp pps_core [last unloaded: i915]
[ 3194.022841] CPU: 0 PID: 8123 Comm: kms_flip Tainted: G U
4.13.0-rc1-CI-CI_DRM_471+ #1
[ 3194.031765] Hardware name: Dell Inc. OptiPlex 755 /0PU052,
BIOS A04 11/05/2007
[ 3194.040343] task: 8800785d4c40 task.stack: c90001768000
[ 3194.046339] RIP: 0010:eb_release_vmas.isra.6+0x119/0x180 [i915]
[ 3194.052234] RSP: 0018:c9000176ba80 EFLAGS: 00010246
[ 3194.057439] RAX: 03c0 RBX: 8800710fc2d8 RCX: 8800588e4f48
[ 3194.064546] RDX: 1fff RSI: RDI: 8800588e00d0
[ 3194.071654] RBP: c9000176bab0 R08: R09:
[ 3194.078761] R10: 0040 R11: 0001 R12: 880060822f00
[ 3194.085867] R13: 0310 R14: 03b8 R15: c9000176bbb0
[ 3194.092975] FS: 7fd2b94aba40() GS:88007d20()
knlGS:
[ 3194.101033] CS: 0010 DS: ES: CR0: 80050033
[ 3194.106754] CR2: 7ffbec3ff000 CR3: 74e67000 CR4: 06f0
[ 3194.113861] Call Trace:
[ 3194.116321] eb_relocate_slow+0x67/0x4e0 [i915]
[ 3194.120861] i915_gem_do_execbuffer+0x429/0x1260 [i915]
[ 3194.126070] ? lock_acquire+0xb5/0x210
[ 3194.129803] ? __might_fault+0x39/0x90
[ 3194.133563] i915_gem_execbuffer2+0x9b/0x1b0 [i915]
[ 3194.138447] ? i915_gem_execbuffer+0x2b0/0x2b0 [i915]
[ 3194.143478] drm_ioctl_kernel+0x64/0xb0
[ 3194.147298] drm_ioctl+0x2cd/0x390
[ 3194.150710] ? i915_gem_execbuffer+0x2b0/0x2b0 [i915]
[ 3194.155741] ? finish_task_switch+0xa5/0x210
[ 3194.159993] ? finish_task_switch+0x6a/0x210
[ 3194.164247] do_vfs_ioctl+0x90/0x670
[ 3194.167806] ? entry_SYSCALL_64_fastpath+0x5/0xb1
[ 3194.172492] ? __this_cpu_preempt_check+0x13/0x20
[ 3194.177176] ? trace_hardirqs_on_caller+0xe7/0x1c0
[ 3194.181946] SyS_ioctl+0x3c/0x70
[ 3194.185159] entry_SYSCALL_64_fastpath+0x1c/0xb1
[ 3194.189756] RIP: 0033:0x7fd2b76a8587
[ 3194.193314] RSP: 002b:7fff074845b8 EFLAGS: 0246 ORIG_RAX:
0010
[ 3194.200855] RAX: ffda RBX: 8146da43 RCX: 7fd2b76a8587
[ 3194.207962] RDX: 7fff074846e0 RSI: 40406469 RDI: 0003
[ 3194.215068] RBP: c9000176bf88 R08: R09: 0003
[ 3194.222175] R10: 7fd2b796bb58 R11: 0246 R12: 7fff07484880
[ 3194.229280] R13: 0003 R14: 40406469 R15:
[ 3194.236386] ? __this_cpu_preempt_check+0x13/0x20
[ 3194.241070] Code: 24 b0 00 00 00 48 85 c9 0f 84 6c ff ff ff 8b 41 20 85 c0
7e 73 83 e8 01 89 41 20 41 8b 84 24 e8 00 00 00 a8 0f 0f 85 5f ff ff ff <0f> 0b
48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d f3 c3 49 8b 84
[ 3194.259943] RIP: eb_release_vmas.isra.6+0x119/0x180 [i915] RSP:
c9000176ba80
[ 3194.268047] ---[ end trace 1d7348c6575d8800 ]---
[ 3673.658819] softdog: Initiating panic
[ 3673.662471] Kernel panic - not syncing: Software Watchdog Timer expired
[ 3673.669066] Kernel Offset: disabled
[ 3673.672541] Rebooting in 1 seconds..
Reported-by: Tomi Sarvela
Fixes: 2889caa92321 ("drm/i915: Eliminate lots of iterations over the
execobjects array")
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index fe3e0d40034c..f30675c6bc4a 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -560,9 +560,6 @@ static int eb_reserve_vma(const struct i915_execbuffer *eb,
eb->args->flags |= __EXEC_HAS_RELOC;
}
- entry->flags |= __EXEC_OBJECT_HAS_PIN;
- GEM_BUG_ON(eb_vma_misplaced(entry, vma));
-
if (unlikely(entry->flags & EXEC_OBJECT_NEEDS_FENCE)) {
err = i915_vma_get_fence(vma);
if (unlikely(err)) {
@@ -574,6 +571,9 @@ static int eb_reserve_vma(const struct i915_execbuffer *eb,
entry->flags |= __EXEC_OBJECT_HAS_FENCE;
}
+ entry->flags |= __EXEC_OBJECT_HAS_PIN;
+ GEM_BUG_ON(eb_vma_misplaced(entry, vma));
+
return 0;
}
--
2.13.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Use mul_u32_u32() for 32b x 32b -> 64b result
== Series Details == Series: series starting with [1/2] drm/i915: Use mul_u32_u32() for 32b x 32b -> 64b result URL : https://patchwork.freedesktop.org/series/27629/ State : success == Summary == Series 27629v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/27629/revisions/1/mbox/ Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-j1900) fdo#101705 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:444s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:431s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:360s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:537s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:516s fi-byt-j1900 total:279 pass:255 dwarn:0 dfail:0 fail:0 skip:24 time:489s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:492s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:598s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:437s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:414s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:417s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:512s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:494s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:468s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:573s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:581s fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 time:559s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:469s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:587s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:471s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:473s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:434s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:496s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:550s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:404s 948c3bddbe7245970c684749ba5d72370cd2 drm-tip: 2017y-07m-20d-10h-52m-43s UTC integration manifest 8ac809d drm/i915/selftests: Use mul_u32_u32() for 32b x 32b -> 64b result f61b3c6 drm/i915: Use mul_u32_u32() for 32b x 32b -> 64b result == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5245/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/15] drm/i915: Flush the execlist ports if idle
Chris Wilson writes:
> When doing a GPU reset, the CSB register will be trashed and we will
> lose any context-switch notifications that happened since the tasklet
> was disabled. If we find that all requests on this engine were
> completed, we want to make sure that the ELSP tracker is similarly empty
> so that we do not feed back in the completed requests upon recovering
> from the reset.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 36 ++--
> 1 file changed, 26 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 3c83f2dd6798..ad61d1998fb7 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1327,6 +1327,31 @@ static void reset_common_ring(struct intel_engine_cs
> *engine,
> {
> struct execlist_port *port = engine->execlist_port;
> struct intel_context *ce;
> + unsigned int n;
> +
> + /*
> + * Catch up with any missed context-switch interrupts.
> + *
> + * Ideally we would just read the remaining CSB entries now that we
> + * know the gpu is idle. However, the CSB registers are sometimes^W
> + * often trashed across a GPU reset! Instead we have to rely on
> + * guessing the missed context-switch events by looking at what
> + * requests were completed.
> + */
> + if (!request) {
> + for (n = 0; n < ARRAY_SIZE(engine->execlist_port); n++)
You need to check against null before put in here?
-Mika
> + i915_gem_request_put(port_request(&port[n]));
> + memset(engine->execlist_port, 0, sizeof(engine->execlist_port));
> + return;
> + }
> +
> + if (request->ctx != port_request(port)->ctx) {
> + i915_gem_request_put(port_request(port));
> + port[0] = port[1];
> + memset(&port[1], 0, sizeof(port[1]));
> + }
> +
> + GEM_BUG_ON(request->ctx != port_request(port)->ctx);
>
> /* If the request was innocent, we leave the request in the ELSP
>* and will try to replay it on restarting. The context image may
> @@ -1338,7 +1363,7 @@ static void reset_common_ring(struct intel_engine_cs
> *engine,
>* and have to at least restore the RING register in the context
>* image back to the expected values to skip over the guilty request.
>*/
> - if (!request || request->fence.error != -EIO)
> + if (request->fence.error != -EIO)
> return;
>
> /* We want a simple context + ring to execute the breadcrumb update.
> @@ -1360,15 +1385,6 @@ static void reset_common_ring(struct intel_engine_cs
> *engine,
> request->ring->head = request->postfix;
> intel_ring_update_space(request->ring);
>
> - /* Catch up with any missed context-switch interrupts */
> - if (request->ctx != port_request(port)->ctx) {
> - i915_gem_request_put(port_request(port));
> - port[0] = port[1];
> - memset(&port[1], 0, sizeof(port[1]));
> - }
> -
> - GEM_BUG_ON(request->ctx != port_request(port)->ctx);
> -
> /* Reset WaIdleLiteRestore:bdw,skl as well */
> request->tail =
> intel_ring_wrap(request->ring,
> --
> 2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/15] drm/i915: Check the execlist queue for pending requests before declaring idle
Chris Wilson writes: > Including a check against the execlist queue before calling the engine > idle and passing hangcheck. > > Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/intel_engine_cs.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c > b/drivers/gpu/drm/i915/intel_engine_cs.c > index cba120f3d89d..fbac94557ffa 100644 > --- a/drivers/gpu/drm/i915/intel_engine_cs.c > +++ b/drivers/gpu/drm/i915/intel_engine_cs.c > @@ -1407,6 +1407,10 @@ bool intel_engine_is_idle(struct intel_engine_cs > *engine) > if (port_request(&engine->execlist_port[0])) > return false; > > + /* ELSP is empty, but there are ready requests? */ > + if (READ_ONCE(engine->execlist_first)) > + return false; > + > /* Ring stopped? */ > if (!ring_is_idle(engine)) > return false; > -- > 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/15] drm/i915: Flush the execlist ports if idle
Quoting Mika Kuoppala (2017-07-20 13:18:40)
> > diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> > b/drivers/gpu/drm/i915/intel_lrc.c
> > index 3c83f2dd6798..ad61d1998fb7 100644
> > --- a/drivers/gpu/drm/i915/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/intel_lrc.c
> > @@ -1327,6 +1327,31 @@ static void reset_common_ring(struct intel_engine_cs
> > *engine,
> > {
> > struct execlist_port *port = engine->execlist_port;
> > struct intel_context *ce;
> > + unsigned int n;
> > +
> > + /*
> > + * Catch up with any missed context-switch interrupts.
> > + *
> > + * Ideally we would just read the remaining CSB entries now that we
> > + * know the gpu is idle. However, the CSB registers are sometimes^W
> > + * often trashed across a GPU reset! Instead we have to rely on
> > + * guessing the missed context-switch events by looking at what
> > + * requests were completed.
> > + */
> > + if (!request) {
> > + for (n = 0; n < ARRAY_SIZE(engine->execlist_port); n++)
>
> You need to check against null before put in here?
dma_fence_put and i915_gem_request_put, by extension, are NULL-safe.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915: Fix scaler init during CRTC HW state readout (rev2)
== Series Details == Series: series starting with [v2,1/2] drm/i915: Fix scaler init during CRTC HW state readout (rev2) URL : https://patchwork.freedesktop.org/series/27607/ State : success == Summary == Series 27607v2 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/27607/revisions/2/mbox/ Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 Test kms_flip: Subgroup basic-flip-vs-modeset: pass -> SKIP (fi-skl-x1585l) fdo#101781 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:442s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:427s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:350s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:540s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:513s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:489s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:482s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:598s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:435s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:419s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:415s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:507s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:476s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:466s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:574s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:586s fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 time:567s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:459s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:584s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:466s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:478s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:435s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:480s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:544s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:403s 948c3bddbe7245970c684749ba5d72370cd2 drm-tip: 2017y-07m-20d-10h-52m-43s UTC integration manifest ad6c516 drm/i915: Simplify scaler init during CRTC HW readout 8915378 drm/i915: Fix scaler init during CRTC HW state readout == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5246/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v5 0/7] CRC testing with Chamelium improvements
On Thu, Jul 20, 2017 at 1:27 PM, Paul Kocialkowski wrote: > On Thu, 2017-07-20 at 12:39 +0300, Jani Nikula wrote: >> For future reference, please post new versions of the entire series as >> new threads. When posting new versions of just some individual >> patches, >> in-reply-to each patch being replaced is fine. I think this is more >> clear, and also gives patchwork a better chance to apply the right >> patches for testing (not that it does igt CI, but that might change). > > Quoting Lyude from an earlier exchange: > * When you're doing a new revision of a patch series, it's helpful to >keep it in the same email thread as the original v1 so it's easier >to keep track of in people's mail clients (as well as avoiding >accidentally reviewing older patch versions. > > I actually prefer it your way (posting as new threads), so I suppose > I'll do that in the future, if Lyude doesn't have any strong objection > about it. Yeah, new patch series = new thread, otherwise patchwork doesn't pick it up. I know that some people like to in-reply-to the previous thread to link stuff up, but that doesn't work with patchwork and CI. Another reason why mailing lists aren't awesome, but that's what we're stuck with for 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 https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v5 0/7] CRC testing with Chamelium improvements
On Thu, 2017-07-20 at 14:41 +0200, Daniel Vetter wrote: > On Thu, Jul 20, 2017 at 1:27 PM, Paul Kocialkowski > wrote: > > On Thu, 2017-07-20 at 12:39 +0300, Jani Nikula wrote: > > > For future reference, please post new versions of the entire > > > series as > > > new threads. When posting new versions of just some individual > > > patches, > > > in-reply-to each patch being replaced is fine. I think this is > > > more > > > clear, and also gives patchwork a better chance to apply the right > > > patches for testing (not that it does igt CI, but that might > > > change). > > > > Quoting Lyude from an earlier exchange: > > * When you're doing a new revision of a patch series, it's helpful > > to > >keep it in the same email thread as the original v1 so it's > > easier > >to keep track of in people's mail clients (as well as avoiding > >accidentally reviewing older patch versions. > > > > I actually prefer it your way (posting as new threads), so I suppose > > I'll do that in the future, if Lyude doesn't have any strong > > objection > > about it. > > Yeah, new patch series = new thread, otherwise patchwork doesn't pick > it up. I know that some people like to in-reply-to the previous thread > to link stuff up, but that doesn't work with patchwork and CI. Nice, glad to hear it! > Another reason why mailing lists aren't awesome, but that's what we're > stuck with for now. Frankly, I love mailing lists, in comparison to anything web-based that basically kills my workflow and cannot be used offline. -- Paul Kocialkowski Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo, Finland ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/15] drm/i915: Assert that machine is wedged for nop_submit_request
Quoting Michel Thierry (2017-07-18 01:15:00)
> On 17/07/17 02:11, Chris Wilson wrote:
> > We should only ever do nop_submit_request when the machine is wedged, so
> > assert it is so.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_gem.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index ca7a56ff3904..5517373c1bea 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3089,6 +3089,7 @@ void i915_gem_reset_finish(struct drm_i915_private
> > *dev_priv)
> >
> > static void nop_submit_request(struct drm_i915_gem_request *request)
> > {
> > + GEM_BUG_ON(!i915_terminally_wedged(&request->i915->gpu_error));
> > dma_fence_set_error(&request->fence, -EIO);
> > i915_gem_request_submit(request);
> > intel_engine_init_global_seqno(request->engine,
> > request->global_seqno);
> >
>
> Not sure about this, your patch before this one, ("[PATCH 09/15]
> drm/i915: Wake up waiters after setting the WEDGED bit"), is moving the
> set_bit after engine_set_wedged:
But we are inside a stop_machine()...
> @@ -3157,10 +3157,12 @@ static int __i915_gem_set_wedged_BKL(void *data)
> struct intel_engine_cs *engine;
> enum intel_engine_id id;
>
> - set_bit(I915_WEDGED, &i915->gpu_error.flags);
> for_each_engine(engine, i915, id)
> engine_set_wedged(engine);
>
> + set_bit(I915_WEDGED, &i915->gpu_error.flags);
> + wake_up_all(&i915->gpu_error.reset_queue);
> +
> return 0;
> }
>
> I don't think it won't hit the BUG_ON because i915_gem_set_wedged is
> already protected by stop_machine. Anyway it looks odd.
Ah, I did consider it in passing, then rationalised it away because the
stop_machine() gives us the guarantee that we won't run
nop_submit_request() until after the wedging.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/7] drm/i915: Avoid the gpu reset vs. modeset deadlock
== Series Details == Series: series starting with [1/7] drm/i915: Avoid the gpu reset vs. modeset deadlock URL : https://patchwork.freedesktop.org/series/27631/ State : success == Summary == Series 27631v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/27631/revisions/1/mbox/ Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-j1900) fdo#101705 +1 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:442s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:428s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:354s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:535s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:514s fi-byt-j1900 total:279 pass:255 dwarn:0 dfail:0 fail:0 skip:24 time:494s fi-byt-n2820 total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:487s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:601s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:436s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:418s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:417s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:502s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:476s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:464s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:575s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:585s fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 time:567s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:460s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:587s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:470s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:473s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:447s fi-skl-x1585ltotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:493s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:539s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:416s 948c3bddbe7245970c684749ba5d72370cd2 drm-tip: 2017y-07m-20d-10h-52m-43s UTC integration manifest 67be7e1 drm/i915: More surgically unbreak the modeset vs reset deadlock 03f48e4 drm/i915: Push i915_sw_fence_wait into the nonblocking atomic commit 24b6245 drm/i915: Avoid the gpu reset vs. modeset deadlock == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5247/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] dma-fence: Don't BUG_ON when not absolutely needed
It makes debugging a massive pain.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-fence.c | 4 ++--
include/linux/dma-fence.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 56e0a0e1b600..9a302799040e 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -48,7 +48,7 @@ static atomic64_t dma_fence_context_counter =
ATOMIC64_INIT(0);
*/
u64 dma_fence_context_alloc(unsigned num)
{
- BUG_ON(!num);
+ WARN_ON(!num);
return atomic64_add_return(num, &dma_fence_context_counter) - num;
}
EXPORT_SYMBOL(dma_fence_context_alloc);
@@ -172,7 +172,7 @@ void dma_fence_release(struct kref *kref)
trace_dma_fence_destroy(fence);
- BUG_ON(!list_empty(&fence->cb_list));
+ WARN_ON(!list_empty(&fence->cb_list));
if (fence->ops->release)
fence->ops->release(fence);
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 9342cf0dada4..171895072435 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -431,8 +431,8 @@ int dma_fence_get_status(struct dma_fence *fence);
static inline void dma_fence_set_error(struct dma_fence *fence,
int error)
{
- BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
- BUG_ON(error >= 0 || error < -MAX_ERRNO);
+ WARN_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
+ WARN_ON(error >= 0 || error < -MAX_ERRNO);
fence->error = error;
}
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/15] drm/i915: Emit a user level message when resetting the GPU (or engine)
Quoting Michel Thierry (2017-07-18 01:22:28)
> On 17/07/17 02:11, Chris Wilson wrote:
> > Although a banned context will be told to -EIO off if they try to submit
> > more requests, we have a discrepancy between whole device resets and
> > per-engine resets where we report the GPU reset but not the engine
> > resets. This leaves a bit of mystery as to why the context was banned,
> > and also reduces awareness overall of when a GPU (engine) reset occurs
> > with its possible side-effects.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Michel Thierry
> > Cc: Mika Kuoppala
> > ---
> > drivers/gpu/drm/i915/i915_drv.c | 8 +---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index bc121a46ed9a..4b62fd012877 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1865,9 +1865,10 @@ void i915_reset(struct drm_i915_private *dev_priv)
> > if (!i915_gem_unset_wedged(dev_priv))
> > goto wakeup;
> >
> > + dev_notice(dev_priv->drm.dev,
> > +"Resetting chip after gpu hang\n");
> > error->reset_count++;
> >
> > - pr_notice("drm/i915: Resetting chip after gpu hang\n");
> > disable_irq(dev_priv->drm.irq);
> > ret = i915_gem_reset_prepare(dev_priv);
> > if (ret) {
> > @@ -1945,7 +1946,9 @@ int i915_reset_engine(struct intel_engine_cs *engine)
> >
> > GEM_BUG_ON(!test_bit(I915_RESET_ENGINE + engine->id, &error->flags));
> >
> > - DRM_DEBUG_DRIVER("resetting %s\n", engine->name);
> > + dev_notice(engine->i915->drm.dev,
> > +"Resetting %s after gpu hang\n", engine->name);
> > + error->reset_engine_count[engine->id]++;
> >
>
> This will increment both the engine-reset-count and gpu-reset count in
> the unlikely case that engine-reset gets promoted to full reset.
>
> Not a problem per-se, but I wanted to point it out (plus it makes both
> functions symmetric).
I felt it was justified as then we always increment either counter on
every attempt, not just success, which was the behaviour for the global
counter. I guess should split that out since it is unrelated.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove assertion from raw __i915_vma_unpin()
== Series Details == Series: drm/i915: Remove assertion from raw __i915_vma_unpin() URL : https://patchwork.freedesktop.org/series/27632/ State : success == Summary == Series 27632v1 drm/i915: Remove assertion from raw __i915_vma_unpin() https://patchwork.freedesktop.org/api/1.0/series/27632/revisions/1/mbox/ Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 Test kms_flip: Subgroup basic-flip-vs-modeset: pass -> SKIP (fi-skl-x1585l) fdo#101781 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:445s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:428s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:354s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:547s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:515s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:497s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:485s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:604s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:444s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:418s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:413s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:504s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:489s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:470s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:574s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:587s fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 time:555s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:457s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:585s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:473s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:479s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:467s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:543s fi-snb-2600 total:279 pass:250 dwarn:0 dfail:0 fail:0 skip:29 time:403s 948c3bddbe7245970c684749ba5d72370cd2 drm-tip: 2017y-07m-20d-10h-52m-43s UTC integration manifest 85ab82f55 drm/i915: Remove assertion from raw __i915_vma_unpin() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5248/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [TRYBOT PATCH] drm/i915: Calculate vlv/chv intermediate watermarks correctly, v3.
The watermarks it should calculate against are the old optimal watermarks.
The currently active crtc watermarks are pure fiction, and are invalid in
case of a nonblocking modeset, page flip enabling/disabling planes or any
other reason.
When the crtc is disabled or during a modeset the intermediate watermarks
don't need to be programmed separately, and could be directly assigned
to the optimal watermarks.
CXSR must always be disabled in the intermediate case for modesets, else
we get a WARN for vblank wait timeout.
Also rename crtc_state to new_crtc_state, to distinguish it from the old state.
Changes since v1:
- Use intel_atomic_get_old_crtc_state. (ville)
Changes since v2:
- Always unset cxsr during modeset.
Signed-off-by: Maarten Lankhorst
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101597
---
drivers/gpu/drm/i915/intel_pm.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 48785ef75d33..7b900ad90745 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2004,16 +2004,25 @@ static void vlv_atomic_update_fifo(struct
intel_atomic_state *state,
static int vlv_compute_intermediate_wm(struct drm_device *dev,
struct intel_crtc *crtc,
- struct intel_crtc_state *crtc_state)
+ struct intel_crtc_state *new_crtc_state)
{
- struct vlv_wm_state *intermediate = &crtc_state->wm.vlv.intermediate;
- const struct vlv_wm_state *optimal = &crtc_state->wm.vlv.optimal;
- const struct vlv_wm_state *active = &crtc->wm.active.vlv;
+ struct vlv_wm_state *intermediate =
&new_crtc_state->wm.vlv.intermediate;
+ const struct vlv_wm_state *optimal = &new_crtc_state->wm.vlv.optimal;
+ const struct intel_crtc_state *old_crtc_state =
+ intel_atomic_get_old_crtc_state(new_crtc_state->base.state,
crtc);
+ const struct vlv_wm_state *active = &old_crtc_state->wm.vlv.optimal;
int level;
+ if (!new_crtc_state->base.active ||
drm_atomic_crtc_needs_modeset(&new_crtc_state->base)) {
+ *intermediate = *optimal;
+
+ intermediate->cxsr = false;
+ goto out;
+ }
+
intermediate->num_levels = min(optimal->num_levels, active->num_levels);
intermediate->cxsr = optimal->cxsr && active->cxsr &&
- !crtc_state->disable_cxsr;
+ !new_crtc_state->disable_cxsr;
for (level = 0; level < intermediate->num_levels; level++) {
enum plane_id plane_id;
@@ -2032,12 +2041,13 @@ static int vlv_compute_intermediate_wm(struct
drm_device *dev,
vlv_invalidate_wms(crtc, intermediate, level);
+out:
/*
* If our intermediate WM are identical to the final WM, then we can
* omit the post-vblank programming; only update if it's different.
*/
if (memcmp(intermediate, optimal, sizeof(*intermediate)) != 0)
- crtc_state->wm.need_postvbl_update = true;
+ new_crtc_state->wm.need_postvbl_update = true;
return 0;
}
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 06/18] drm/i915: Check for duplicated power well IDs
On Tue, Jul 11, 2017 at 11:42:33PM +0300, Imre Deak wrote: > Check that all the power well IDs are unique on the given platform. > > v2: > - Fix using BIT_ULL() instead of BIT() for 64 bit mask. > v3: > - Move the check to a separate function. (Ville) > > Signed-off-by: Imre Deak Reviewed-by: Arkadiusz Hiler ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/18] drm/i915/bxt, glk: Give a proper name to the power well struct phy field
On Thu, Jul 06, 2017 at 05:40:29PM +0300, Imre Deak wrote: > Follow-up patches will add new fields to the i915_power_well struct that > are specific to the hsw_power_well_ops helpers. Prepare for this by > changing the generic 'data' field to a union of platform specific > structs. > > Signed-off-by: Imre Deak Reviewed-by: Arkadiusz Hiler ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/15] drm/i915: Flush the execlist ports if idle
Chris Wilson writes:
> When doing a GPU reset, the CSB register will be trashed and we will
> lose any context-switch notifications that happened since the tasklet
> was disabled. If we find that all requests on this engine were
> completed, we want to make sure that the ELSP tracker is similarly empty
> so that we do not feed back in the completed requests upon recovering
> from the reset.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 36 ++--
> 1 file changed, 26 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 3c83f2dd6798..ad61d1998fb7 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -1327,6 +1327,31 @@ static void reset_common_ring(struct intel_engine_cs
> *engine,
> {
> struct execlist_port *port = engine->execlist_port;
> struct intel_context *ce;
> + unsigned int n;
> +
> + /*
> + * Catch up with any missed context-switch interrupts.
> + *
> + * Ideally we would just read the remaining CSB entries now that we
> + * know the gpu is idle. However, the CSB registers are sometimes^W
> + * often trashed across a GPU reset! Instead we have to rely on
> + * guessing the missed context-switch events by looking at what
> + * requests were completed.
> + */
> + if (!request) {
> + for (n = 0; n < ARRAY_SIZE(engine->execlist_port); n++)
> + i915_gem_request_put(port_request(&port[n]));
> + memset(engine->execlist_port, 0, sizeof(engine->execlist_port));
> + return;
> + }
> +
> + if (request->ctx != port_request(port)->ctx) {
> + i915_gem_request_put(port_request(port));
> + port[0] = port[1];
> + memset(&port[1], 0, sizeof(port[1]));
> + }
> +
> + GEM_BUG_ON(request->ctx != port_request(port)->ctx);
>
> /* If the request was innocent, we leave the request in the ELSP
>* and will try to replay it on restarting. The context image may
> @@ -1338,7 +1363,7 @@ static void reset_common_ring(struct intel_engine_cs
> *engine,
>* and have to at least restore the RING register in the context
>* image back to the expected values to skip over the guilty request.
>*/
> - if (!request || request->fence.error != -EIO)
> + if (request->fence.error != -EIO)
> return;
>
> /* We want a simple context + ring to execute the breadcrumb update.
> @@ -1360,15 +1385,6 @@ static void reset_common_ring(struct intel_engine_cs
> *engine,
> request->ring->head = request->postfix;
> intel_ring_update_space(request->ring);
>
> - /* Catch up with any missed context-switch interrupts */
> - if (request->ctx != port_request(port)->ctx) {
> - i915_gem_request_put(port_request(port));
> - port[0] = port[1];
> - memset(&port[1], 0, sizeof(port[1]));
> - }
> -
> - GEM_BUG_ON(request->ctx != port_request(port)->ctx);
> -
> /* Reset WaIdleLiteRestore:bdw,skl as well */
> request->tail =
> intel_ring_wrap(request->ring,
> --
> 2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm/i915: Change use get_new_plane_state instead of existing plane state
The get_existing macros are deprecated and should be replaced by
get_old/new_state for clarity.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c | 4 ++--
drivers/gpu/drm/i915/intel_drv.h| 4 ++--
drivers/gpu/drm/i915/intel_pm.c | 5 ++---
3 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 36d4e635e4ce..5d9a26fa5f6d 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -301,8 +301,8 @@ int intel_atomic_setup_scalers(struct drm_i915_private
*dev_priv,
continue;
}
- plane_state =
intel_atomic_get_existing_plane_state(drm_state,
-
intel_plane);
+ plane_state =
intel_atomic_get_new_plane_state(drm_state,
+
intel_plane);
scaler_id = &plane_state->scaler_id;
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 4f9775a05df7..f59507137347 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1958,12 +1958,12 @@ intel_atomic_get_existing_crtc_state(struct
drm_atomic_state *state,
}
static inline struct intel_plane_state *
-intel_atomic_get_existing_plane_state(struct drm_atomic_state *state,
+intel_atomic_get_new_plane_state(struct drm_atomic_state *state,
struct intel_plane *plane)
{
struct drm_plane_state *plane_state;
- plane_state = drm_atomic_get_existing_plane_state(state, &plane->base);
+ plane_state = drm_atomic_get_new_plane_state(state, &plane->base);
return to_intel_plane_state(plane_state);
}
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 48785ef75d33..0cdb9453e0e2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3028,8 +3028,7 @@ static int ilk_compute_pipe_wm(struct intel_crtc_state
*cstate)
for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
struct intel_plane_state *ps;
- ps = intel_atomic_get_existing_plane_state(state,
- intel_plane);
+ ps = intel_atomic_get_new_plane_state(state, intel_plane);
if (!ps)
continue;
@@ -4766,7 +4765,7 @@ skl_ddb_add_affected_planes(struct intel_crtc_state
*cstate)
struct drm_plane *plane;
enum pipe pipe = intel_crtc->pipe;
- WARN_ON(!drm_atomic_get_existing_crtc_state(state, crtc));
+ WARN_ON(!drm_atomic_get_new_crtc_state(state, crtc));
drm_for_each_plane_mask(plane, dev, cstate->base.plane_mask) {
enum plane_id plane_id = to_intel_plane(plane)->id;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/8] drm/i915: Stop using get_existing_state.
drm_atomic_get_existing_state should be removed, so stop using it in i915. Fortunately all places can be converted to use the new state or old state, even removing some dereferncing of obj->state in the process. i915 no longer depends on plane->fb, so patch 6 removes the assignment. The first 6 patches should definitely be upstreamed, last 2 are RFC, but probably should be upstreamed. I added them because I'm curious if it fixes FD.org #101597. Maarten Lankhorst (8): drm/i915: Change use get_new_plane_state instead of existing plane state drm/i915: Change get_existing_crtc_state to old state drm/i915: Use new atomic helpers in intel_plane_atomic_check drm/i915: Use intel_atomic_get_new_crtc_state in intel_fbc.c drm/i915: Remove last references to drm_atomic_get_existing* macros drm/i915: Do not update legacy state any more drm/i915: Calculate ironlake intermediate watermarks correctly, v2. drm/i915: Calculate vlv/chv intermediate watermarks correctly, v3. drivers/gpu/drm/i915/intel_atomic.c | 4 +- drivers/gpu/drm/i915/intel_atomic_plane.c | 22 + drivers/gpu/drm/i915/intel_display.c | 81 +++ drivers/gpu/drm/i915/intel_drv.h | 24 +++-- drivers/gpu/drm/i915/intel_fbc.c | 5 +- drivers/gpu/drm/i915/intel_pm.c | 34 + 6 files changed, 88 insertions(+), 82 deletions(-) -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 8/8] drm/i915: Calculate vlv/chv intermediate watermarks correctly, v3.
The watermarks it should calculate against are the old optimal watermarks.
The currently active crtc watermarks are pure fiction, and are invalid in
case of a nonblocking modeset, page flip enabling/disabling planes or any
other reason.
When the crtc is disabled or during a modeset the intermediate watermarks
don't need to be programmed separately, and could be directly assigned
to the optimal watermarks.
CXSR must always be disabled in the intermediate case for modesets, else
we get a WARN for vblank wait timeout.
Also rename crtc_state to new_crtc_state, to distinguish it from the old state.
Changes since v1:
- Use intel_atomic_get_old_crtc_state. (ville)
Changes since v2:
- Always unset cxsr during modeset.
Signed-off-by: Maarten Lankhorst
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101597
---
drivers/gpu/drm/i915/intel_pm.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0048bf043337..96de4f8e3b2a 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2004,16 +2004,25 @@ static void vlv_atomic_update_fifo(struct
intel_atomic_state *state,
static int vlv_compute_intermediate_wm(struct drm_device *dev,
struct intel_crtc *crtc,
- struct intel_crtc_state *crtc_state)
+ struct intel_crtc_state *new_crtc_state)
{
- struct vlv_wm_state *intermediate = &crtc_state->wm.vlv.intermediate;
- const struct vlv_wm_state *optimal = &crtc_state->wm.vlv.optimal;
- const struct vlv_wm_state *active = &crtc->wm.active.vlv;
+ struct vlv_wm_state *intermediate =
&new_crtc_state->wm.vlv.intermediate;
+ const struct vlv_wm_state *optimal = &new_crtc_state->wm.vlv.optimal;
+ const struct intel_crtc_state *old_crtc_state =
+ intel_atomic_get_old_crtc_state(new_crtc_state->base.state,
crtc);
+ const struct vlv_wm_state *active = &old_crtc_state->wm.vlv.optimal;
int level;
+ if (!new_crtc_state->base.active ||
drm_atomic_crtc_needs_modeset(&new_crtc_state->base)) {
+ *intermediate = *optimal;
+
+ intermediate->cxsr = false;
+ goto out;
+ }
+
intermediate->num_levels = min(optimal->num_levels, active->num_levels);
intermediate->cxsr = optimal->cxsr && active->cxsr &&
- !crtc_state->disable_cxsr;
+ !new_crtc_state->disable_cxsr;
for (level = 0; level < intermediate->num_levels; level++) {
enum plane_id plane_id;
@@ -2032,12 +2041,13 @@ static int vlv_compute_intermediate_wm(struct
drm_device *dev,
vlv_invalidate_wms(crtc, intermediate, level);
+out:
/*
* If our intermediate WM are identical to the final WM, then we can
* omit the post-vblank programming; only update if it's different.
*/
if (memcmp(intermediate, optimal, sizeof(*intermediate)) != 0)
- crtc_state->wm.need_postvbl_update = true;
+ new_crtc_state->wm.need_postvbl_update = true;
return 0;
}
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 7/8] drm/i915: Calculate ironlake intermediate watermarks correctly, v2.
The watermarks it should calculate against are the old optimal watermarks.
The currently active crtc watermarks are pure fiction, and are invalid in
case of a nonblocking modeset, page flip enabling/disabling planes or any
other reason.
When the crtc is disabled or during a modeset the intermediate watermarks
don't need to be programmed separately, and could be directly assigned
to the optimal watermarks.
Changes since v1:
- Use intel_atomic_get_old_crtc_state. (ville)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_pm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0cdb9453e0e2..0048bf043337 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3105,7 +3105,9 @@ static int ilk_compute_intermediate_wm(struct drm_device
*dev,
struct intel_crtc_state *newstate)
{
struct intel_pipe_wm *a = &newstate->wm.ilk.intermediate;
- struct intel_pipe_wm *b = &intel_crtc->wm.active.ilk;
+ const struct intel_crtc_state *oldstate =
+ intel_atomic_get_old_crtc_state(newstate->base.state,
intel_crtc);
+ const struct intel_pipe_wm *b = &oldstate->wm.ilk.optimal;
int level, max_level = ilk_wm_max_level(to_i915(dev));
/*
@@ -3114,6 +3116,9 @@ static int ilk_compute_intermediate_wm(struct drm_device
*dev,
* and after the vblank.
*/
*a = newstate->wm.ilk.optimal;
+ if (!newstate->base.active ||
drm_atomic_crtc_needs_modeset(&newstate->base))
+ return 0;
+
a->pipe_enabled |= b->pipe_enabled;
a->sprites_enabled |= b->sprites_enabled;
a->sprites_scaled |= b->sprites_scaled;
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/8] drm/i915: Do not update legacy state any more
FBC has been converted to atomic, so updating
some legacy variables is no longer needed.
drm_atomic_helper_update_legacy_modeset_state
does update crtc->x/y anyway, but we shouldn't need it.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 30 --
1 file changed, 4 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d95b3ba1fe47..6e47ee8827ae 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11027,31 +11027,6 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
return ret;
}
-static void
-intel_modeset_update_crtc_state(struct drm_atomic_state *state)
-{
- struct drm_crtc *crtc;
- struct drm_crtc_state *new_crtc_state;
- int i;
-
- /* Double check state. */
- for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
- struct drm_plane_state *plane_state;
- to_intel_crtc(crtc)->config =
to_intel_crtc_state(new_crtc_state);
-
- /*
-* Update legacy state to satisfy fbc code. This can
-* be removed when fbc uses the atomic state.
-*/
- plane_state = drm_atomic_get_new_plane_state(state,
crtc->primary);
- if (plane_state) {
- crtc->primary->fb = plane_state->fb;
- crtc->x = plane_state->src_x >> 16;
- crtc->y = plane_state->src_y >> 16;
- }
- }
-}
-
static bool intel_fuzzy_clock_check(int clock1, int clock2)
{
int diff;
@@ -12438,7 +12413,10 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
/* Only after disabling all output pipelines that will be changed can we
* update the the output configuration. */
- intel_modeset_update_crtc_state(state);
+
+ /* Update legacy crtc->config pointer */
+ for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
+ to_intel_crtc(crtc)->config =
to_intel_crtc_state(new_crtc_state);
if (intel_state->modeset) {
drm_atomic_helper_update_legacy_modeset_state(state->dev,
state);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/8] drm/i915: Remove last references to drm_atomic_get_existing* macros
All the references to get_existing_state can be converted to
get_new_state or get_old_state, which means that i915 is now
get_existing_state free.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 57 +---
1 file changed, 27 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8bd8ed362e1a..d95b3ba1fe47 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4956,27 +4956,25 @@ static void intel_post_plane_update(struct
intel_crtc_state *old_crtc_state)
struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
struct drm_atomic_state *old_state = old_crtc_state->base.state;
struct intel_crtc_state *pipe_config =
- to_intel_crtc_state(crtc->base.state);
+ intel_atomic_get_new_crtc_state(old_state, crtc);
struct drm_plane *primary = crtc->base.primary;
- struct drm_plane_state *old_pri_state =
- drm_atomic_get_existing_plane_state(old_state, primary);
+ struct drm_plane_state *old_primary_state =
+ drm_atomic_get_old_plane_state(old_state, primary);
intel_frontbuffer_flip(to_i915(crtc->base.dev), pipe_config->fb_bits);
if (pipe_config->update_wm_post && pipe_config->base.active)
intel_update_watermarks(crtc);
- if (old_pri_state) {
- struct intel_plane_state *primary_state =
- to_intel_plane_state(primary->state);
- struct intel_plane_state *old_primary_state =
- to_intel_plane_state(old_pri_state);
+ if (old_primary_state) {
+ struct drm_plane_state *new_primary_state =
+ drm_atomic_get_new_plane_state(old_state, primary);
intel_fbc_post_update(crtc);
- if (primary_state->base.visible &&
+ if (new_primary_state->visible &&
(needs_modeset(&pipe_config->base) ||
-!old_primary_state->base.visible))
+!old_primary_state->visible))
intel_post_enable_primary(&crtc->base);
}
}
@@ -4989,22 +4987,21 @@ static void intel_pre_plane_update(struct
intel_crtc_state *old_crtc_state,
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_atomic_state *old_state = old_crtc_state->base.state;
struct drm_plane *primary = crtc->base.primary;
- struct drm_plane_state *old_pri_state =
- drm_atomic_get_existing_plane_state(old_state, primary);
+ struct drm_plane_state *old_primary_state =
+ drm_atomic_get_old_plane_state(old_state, primary);
bool modeset = needs_modeset(&pipe_config->base);
struct intel_atomic_state *old_intel_state =
to_intel_atomic_state(old_state);
- if (old_pri_state) {
- struct intel_plane_state *primary_state =
- to_intel_plane_state(primary->state);
- struct intel_plane_state *old_primary_state =
- to_intel_plane_state(old_pri_state);
+ if (old_primary_state) {
+ struct drm_plane_state *new_primary_state =
+ drm_atomic_get_new_plane_state(old_state, primary);
- intel_fbc_pre_update(crtc, pipe_config, primary_state);
+ intel_fbc_pre_update(crtc, pipe_config,
+to_intel_plane_state(new_primary_state));
- if (old_primary_state->base.visible &&
- (modeset || !primary_state->base.visible))
+ if (old_primary_state->visible &&
+ (modeset || !new_primary_state->visible))
intel_pre_disable_primary(&crtc->base);
}
@@ -10822,7 +10819,7 @@ static bool check_digital_port_conflicts(struct
drm_atomic_state *state)
struct drm_connector_state *connector_state;
struct intel_encoder *encoder;
- connector_state =
drm_atomic_get_existing_connector_state(state, connector);
+ connector_state = drm_atomic_get_new_connector_state(state,
connector);
if (!connector_state)
connector_state = connector->state;
@@ -11039,15 +11036,15 @@ intel_modeset_update_crtc_state(struct
drm_atomic_state *state)
/* Double check state. */
for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
+ struct drm_plane_state *plane_state;
to_intel_crtc(crtc)->config =
to_intel_crtc_state(new_crtc_state);
/*
* Update legacy state to satisfy fbc code. This can
* be removed when fbc uses the atomic state.
*/
- if (drm_atomic_get_existing_plane_state(state, crtc->
[Intel-gfx] [PATCH 2/8] drm/i915: Change get_existing_crtc_state to old state
get_existing_crtc_state is currently unused, but the next commit
needs to access the old intel state. Rename this and use this
as convenience wrapper.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_drv.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index f59507137347..3723ee443faa 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1944,12 +1944,12 @@ intel_atomic_get_crtc_state(struct drm_atomic_state
*state,
}
static inline struct intel_crtc_state *
-intel_atomic_get_existing_crtc_state(struct drm_atomic_state *state,
-struct intel_crtc *crtc)
+intel_atomic_get_old_crtc_state(struct drm_atomic_state *state,
+ struct intel_crtc *crtc)
{
struct drm_crtc_state *crtc_state;
- crtc_state = drm_atomic_get_existing_crtc_state(state, &crtc->base);
+ crtc_state = drm_atomic_get_old_crtc_state(state, &crtc->base);
if (crtc_state)
return to_intel_crtc_state(crtc_state);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/8] drm/i915: Use new atomic helpers in intel_plane_atomic_check
Remove the use of plane->state and drm_atomic_get_existing_state,
instead use the new helpers, and also add
intel_atomic_get_new_crtc_state as it's needed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 22 +-
drivers/gpu/drm/i915/intel_drv.h | 14 ++
2 files changed, 27 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index ee76fab7bb6f..1081d0b63b6e 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -198,12 +198,17 @@ int intel_plane_atomic_check_with_state(struct
intel_crtc_state *crtc_state,
}
static int intel_plane_atomic_check(struct drm_plane *plane,
- struct drm_plane_state *state)
+ struct drm_plane_state *new_plane_state)
{
- struct drm_crtc *crtc = state->crtc;
- struct drm_crtc_state *drm_crtc_state;
+ struct drm_atomic_state *state = new_plane_state->state;
+ struct intel_crtc *crtc;
+ struct intel_crtc_state *new_crtc_state;
+ struct drm_plane_state *old_plane_state;
+ struct intel_plane_state *new_intel_plane_state;
- crtc = crtc ? crtc : plane->state->crtc;
+ old_plane_state = drm_atomic_get_old_plane_state(state, plane);
+
+ crtc = to_intel_crtc(new_plane_state->crtc ?: old_plane_state->crtc);
/*
* Both crtc and plane->crtc could be NULL if we're updating a
@@ -214,12 +219,11 @@ static int intel_plane_atomic_check(struct drm_plane
*plane,
if (!crtc)
return 0;
- drm_crtc_state = drm_atomic_get_existing_crtc_state(state->state, crtc);
- if (WARN_ON(!drm_crtc_state))
- return -EINVAL;
+ new_crtc_state = intel_atomic_get_new_crtc_state(state, crtc);
+ new_intel_plane_state = to_intel_plane_state(new_plane_state);
- return
intel_plane_atomic_check_with_state(to_intel_crtc_state(drm_crtc_state),
- to_intel_plane_state(state));
+ return intel_plane_atomic_check_with_state(new_crtc_state,
+ new_intel_plane_state);
}
static void intel_plane_atomic_update(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3723ee443faa..98851ed5ec2b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1957,6 +1957,20 @@ intel_atomic_get_old_crtc_state(struct drm_atomic_state
*state,
return NULL;
}
+static inline struct intel_crtc_state *
+intel_atomic_get_new_crtc_state(struct drm_atomic_state *state,
+ struct intel_crtc *crtc)
+{
+ struct drm_crtc_state *crtc_state;
+
+ crtc_state = drm_atomic_get_new_crtc_state(state, &crtc->base);
+
+ if (crtc_state)
+ return to_intel_crtc_state(crtc_state);
+ else
+ return NULL;
+}
+
static inline struct intel_plane_state *
intel_atomic_get_new_plane_state(struct drm_atomic_state *state,
struct intel_plane *plane)
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/8] drm/i915: Use intel_atomic_get_new_crtc_state in intel_fbc.c
The previous commit added intel_atomic_get_new_crtc_state, convert intel_fbc.c to the new helper. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_fbc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c index 860b8c26d29b..81d156f04db9 100644 --- a/drivers/gpu/drm/i915/intel_fbc.c +++ b/drivers/gpu/drm/i915/intel_fbc.c @@ -1046,7 +1046,7 @@ void intel_fbc_choose_crtc(struct drm_i915_private *dev_priv, /* Does this atomic commit involve the CRTC currently tied to FBC? */ if (fbc->crtc && - !drm_atomic_get_existing_crtc_state(state, &fbc->crtc->base)) + !intel_atomic_get_new_crtc_state(state, fbc->crtc)) goto out; if (!intel_fbc_can_enable(dev_priv)) @@ -1071,8 +1071,7 @@ void intel_fbc_choose_crtc(struct drm_i915_private *dev_priv, if (fbc_on_plane_a_only(dev_priv) && crtc->plane != PLANE_A) continue; - intel_crtc_state = to_intel_crtc_state( - drm_atomic_get_existing_crtc_state(state, &crtc->base)); + intel_crtc_state = intel_atomic_get_new_crtc_state(state, crtc); intel_crtc_state->enable_fbc = true; crtc_chosen = true; -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/15] drm/i915: Move idle checks before intel_engine_init_global_seqno()
Chris Wilson writes:
> intel_engine_init_globa_seqno() may be called from an uncontrolled
> set-wedged path where we have given up waiting for broken hw and declare
> it defunct. Along that path, any sanity checks that the hw is idle
> before we adjust its state will expectedly fail, so we simply cannot.
> Instead of asserting inside init_global_seqno, we move them to the
> normal caller reset_all_global_seqno() as it handles runtime seqno
> wraparound.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem_request.c | 4
> drivers/gpu/drm/i915/intel_engine_cs.c | 3 ---
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
> b/drivers/gpu/drm/i915/i915_gem_request.c
> index 483af8921060..d93a185c0f0a 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -213,6 +213,10 @@ static int reset_all_global_seqno(struct
> drm_i915_private *i915, u32 seqno)
> cond_resched();
> }
>
> + /* Check we are idle before we fiddle with hw state! */
> + GEM_BUG_ON(!intel_engine_is_idle(engine));
> +
> GEM_BUG_ON(i915_gem_active_isset(&engine->timeline->last_request));
> +
> /* Finally reset hw state */
> intel_engine_init_global_seqno(engine, seqno);
> tl->seqno = seqno;
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index fbac94557ffa..19297e6aab41 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -337,9 +337,6 @@ void intel_engine_init_global_seqno(struct
> intel_engine_cs *engine, u32 seqno)
> {
> struct drm_i915_private *dev_priv = engine->i915;
>
> - GEM_BUG_ON(!intel_engine_is_idle(engine));
> - GEM_BUG_ON(i915_gem_active_isset(&engine->timeline->last_request));
> -
> /* Our semaphore implementation is strictly monotonic (i.e. we proceed
>* so long as the semaphore value in the register/page is greater
>* than the sync value), so whenever we reset the seqno,
> --
> 2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Only mark the execobject as pinned on success
== Series Details == Series: drm/i915: Only mark the execobject as pinned on success URL : https://patchwork.freedesktop.org/series/27634/ State : failure == Summary == Series 27634v1 drm/i915: Only mark the execobject as pinned on success https://patchwork.freedesktop.org/api/1.0/series/27634/revisions/1/mbox/ Test gem_ctx_basic: skip -> FAIL (fi-blb-e6850) Test kms_flip: Subgroup basic-flip-vs-modeset: pass -> SKIP (fi-skl-x1585l) fdo#101781 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> DMESG-WARN (fi-pnv-d510) fdo#101597 fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:447s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:427s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:1 skip:53 time:351s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:530s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:513s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:498s fi-byt-n2820 total:279 pass:250 dwarn:1 dfail:0 fail:0 skip:28 time:488s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:603s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:436s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:414s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:408s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:503s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:475s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:464s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:575s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:581s fi-pnv-d510 total:279 pass:221 dwarn:3 dfail:0 fail:0 skip:55 time:560s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:460s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:588s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:471s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:473s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:477s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:546s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:408s 948c3bddbe7245970c684749ba5d72370cd2 drm-tip: 2017y-07m-20d-10h-52m-43s UTC integration manifest 959ab8f drm/i915: Only mark the execobject as pinned on success == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5249/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Don't touch fence->error when resetting an innocent request
If the request has been completed before the reset took effect, we don't
need to mark it up as being a victim. Touching fence->error after the
fence has been signaled is detected by dma_fence_set_error() and
triggers a BUG:
[ 231.743133] kernel BUG at ./include/linux/dma-fence.h:434!
[ 231.743156] invalid opcode: [#1] SMP KASAN
[ 231.743172] Modules linked in: i915 drm_kms_helper drm iptable_nat
nf_nat_ipv4 nf_nat x86_pkg_temp_thermal iosf_mbi i2c_algo_bit cfbfillrect
syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea fb font
fbdev [last unloaded: drm]
[ 231.743221] CPU: 2 PID: 20 Comm: kworker/2:0 Tainted: G U
4.13.0-rc1+ #52
[ 231.743236] Hardware name: Hewlett-Packard HP EliteBook 8460p/161C, BIOS
68SCF Ver. F.01 03/11/2011
[ 231.743363] Workqueue: events_long i915_hangcheck_elapsed [i915]
[ 231.743382] task: 8801f42e9780 task.stack: 8801f42f8000
[ 231.743489] RIP: 0010:i915_gem_reset_engine+0x45a/0x460 [i915]
[ 231.743505] RSP: 0018:8801f42ff770 EFLAGS: 00010202
[ 231.743521] RAX: 0007 RBX: 8801bf6b1880 RCX: a02881a6
[ 231.743537] RDX: dc00 RSI: dc00 RDI: 8801bf6b18c8
[ 231.743551] RBP: 8801f42ff7c8 R08: 0001 R09:
[ 231.743566] R10: R11: R12: 8801edb02d00
[ 231.743581] R13: 8801e19d4200 R14: 001d R15: 8801ce2a4000
[ 231.743599] FS: () GS:8801f5a8()
knlGS:
[ 231.743614] CS: 0010 DS: ES: CR0: 80050033
[ 231.743629] CR2: 7f0ebd1add10 CR3: 02621000 CR4: 000406e0
[ 231.743643] Call Trace:
[ 231.743752] i915_gem_reset+0x6c/0x150 [i915]
[ 231.743853] i915_reset+0x175/0x210 [i915]
[ 231.743958] i915_reset_device+0x33b/0x350 [i915]
[ 231.744061] ? valleyview_pipestat_irq_handler+0xe0/0xe0 [i915]
[ 231.744081] ? trace_hardirqs_off_caller+0x70/0x110
[ 231.744102] ? _raw_spin_unlock_irqrestore+0x46/0x50
[ 231.744120] ? find_held_lock+0x119/0x150
[ 231.744138] ? mark_lock+0x6d/0x850
[ 231.744241] ? gen8_gt_irq_ack+0x1f0/0x1f0 [i915]
[ 231.744262] ? work_on_cpu_safe+0x60/0x60
[ 231.744284] ? rcu_read_lock_sched_held+0x57/0xa0
[ 231.744400] ? gen6_read32+0x2ba/0x320 [i915]
[ 231.744506] i915_handle_error+0x382/0x5f0 [i915]
[ 231.744611] ? gen6_rps_reset_ei+0x20/0x20 [i915]
[ 231.744630] ? vsnprintf+0x128/0x8e0
[ 231.744649] ? pointer+0x6b0/0x6b0
[ 231.744667] ? debug_check_no_locks_freed+0x1a0/0x1a0
[ 231.744688] ? scnprintf+0x92/0xe0
[ 231.744706] ? snprintf+0xb0/0xb0
[ 231.744820] hangcheck_declare_hang+0x15a/0x1a0 [i915]
[ 231.744932] ? engine_stuck+0x440/0x440 [i915]
[ 231.744951] ? rcu_read_lock_sched_held+0x57/0xa0
[ 231.745062] ? gen6_read32+0x2ba/0x320 [i915]
[ 231.745173] ? gen6_read16+0x320/0x320 [i915]
[ 231.745284] ? intel_engine_get_active_head+0x91/0x170 [i915]
[ 231.745401] i915_hangcheck_elapsed+0x3d8/0x400 [i915]
[ 231.745424] process_one_work+0x3e8/0xac0
[ 231.745444] ? pwq_dec_nr_in_flight+0x110/0x110
[ 231.745464] ? do_raw_spin_lock+0x8e/0x120
[ 231.745484] worker_thread+0x8d/0x720
[ 231.745506] kthread+0x19e/0x1f0
[ 231.745524] ? process_one_work+0xac0/0xac0
[ 231.745541] ? kthread_create_on_node+0xa0/0xa0
[ 231.745560] ret_from_fork+0x27/0x40
[ 231.745581] Code: 8b 7d c8 e8 49 0d 02 e1 49 8b 7f 38 48 8b 75 b8 48 83 c7
10 e8 b8 89 be e1 e9 95 fc ff ff 4c 89 e7 e8 4b b9 ff ff e9 30 ff ff ff <0f> 0b
0f 1f 40 00 55 48 89 e5 41 57 41 56 41 55 41 54 49 89 fe
[ 231.745767] RIP: i915_gem_reset_engine+0x45a/0x460 [i915] RSP:
8801f42ff770
At first glance this looks to be related to commit c64992e035d7
("drm/i915: Look for active requests earlier in the reset path"), but it
could easily happen before as well. On the other hand, we no longer
logged victims due to the active_request being dropped earlier.
Reported-by: Daniel Vetter
Fixes: c64992e035d7 ("drm/i915: Look for active requests earlier in the reset
path")
Signed-off-by: Chris Wilson
Cc: Michel Thierry
Cc: Mika Kuoppala
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 37 +++--
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b1520052a5e4..3ad1352dc871 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2914,11 +2914,9 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs
*engine)
if (engine->irq_seqno_barrier)
engine->irq_seqno_barrier(engine);
- if (engine_stalled(engine)) {
- request = i915_gem_find_active_request(engine);
- if (request && request->fence.error == -EIO)
- request = ERR_PTR(-EIO); /* Previous reset failed! */
- }
+ request = i915_gem_find_active_request(engine);
+ if (request && request->fen
Re: [Intel-gfx] [PATCH 08/15] drm/i915: Clear execlist port[] before updating seqno on wedging
Chris Wilson writes: > When we wedge the device, we clear out the in-flight requests and > advance the breadcrumb to indicate they are complete. However, the > breadcrumb advance includes an assert that the engine is idle, so that > advancement needs to be the last step to ensure we pass our own sanity > checks. I am confused about this one. The previous patch seems to make the concern void. -Mika > > Signed-off-by: Chris Wilson > --- > drivers/gpu/drm/i915/i915_gem.c | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 580b5042f4f7..40e94b4ef532 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -3114,13 +3114,6 @@ static void engine_set_wedged(struct intel_engine_cs > *engine) > dma_fence_set_error(&request->fence, -EIO); > spin_unlock_irqrestore(&engine->timeline->lock, flags); > > - /* Mark all pending requests as complete so that any concurrent > - * (lockless) lookup doesn't try and wait upon the request as we > - * reset it. > - */ > - intel_engine_init_global_seqno(engine, > -intel_engine_last_submit(engine)); > - > /* >* Clear the execlists queue up before freeing the requests, as those >* are the ones that keep the context and ringbuffer backing objects > @@ -3149,6 +3142,13 @@ static void engine_set_wedged(struct intel_engine_cs > *engine) >*/ > clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted); > } > + > + /* Mark all pending requests as complete so that any concurrent > + * (lockless) lookup doesn't try and wait upon the request as we > + * reset it. > + */ > + intel_engine_init_global_seqno(engine, > +intel_engine_last_submit(engine)); > } > > static int __i915_gem_set_wedged_BKL(void *data) > -- > 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Don't touch fence->error when resetting an innocent request
Quoting Chris Wilson (2017-07-20 14:24:29)
> If the request has been completed before the reset took effect, we don't
> need to mark it up as being a victim. Touching fence->error after the
> fence has been signaled is detected by dma_fence_set_error() and
> triggers a BUG:
>
> [ 231.743133] kernel BUG at ./include/linux/dma-fence.h:434!
> [ 231.743156] invalid opcode: [#1] SMP KASAN
> [ 231.743172] Modules linked in: i915 drm_kms_helper drm iptable_nat
> nf_nat_ipv4 nf_nat x86_pkg_temp_thermal iosf_mbi i2c_algo_bit cfbfillrect
> syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea fb font
> fbdev [last unloaded: drm]
> [ 231.743221] CPU: 2 PID: 20 Comm: kworker/2:0 Tainted: G U
> 4.13.0-rc1+ #52
> [ 231.743236] Hardware name: Hewlett-Packard HP EliteBook 8460p/161C, BIOS
> 68SCF Ver. F.01 03/11/2011
> [ 231.743363] Workqueue: events_long i915_hangcheck_elapsed [i915]
> [ 231.743382] task: 8801f42e9780 task.stack: 8801f42f8000
> [ 231.743489] RIP: 0010:i915_gem_reset_engine+0x45a/0x460 [i915]
> [ 231.743505] RSP: 0018:8801f42ff770 EFLAGS: 00010202
> [ 231.743521] RAX: 0007 RBX: 8801bf6b1880 RCX:
> a02881a6
> [ 231.743537] RDX: dc00 RSI: dc00 RDI:
> 8801bf6b18c8
> [ 231.743551] RBP: 8801f42ff7c8 R08: 0001 R09:
>
> [ 231.743566] R10: R11: R12:
> 8801edb02d00
> [ 231.743581] R13: 8801e19d4200 R14: 001d R15:
> 8801ce2a4000
> [ 231.743599] FS: () GS:8801f5a8()
> knlGS:
> [ 231.743614] CS: 0010 DS: ES: CR0: 80050033
> [ 231.743629] CR2: 7f0ebd1add10 CR3: 02621000 CR4:
> 000406e0
> [ 231.743643] Call Trace:
> [ 231.743752] i915_gem_reset+0x6c/0x150 [i915]
> [ 231.743853] i915_reset+0x175/0x210 [i915]
> [ 231.743958] i915_reset_device+0x33b/0x350 [i915]
> [ 231.744061] ? valleyview_pipestat_irq_handler+0xe0/0xe0 [i915]
> [ 231.744081] ? trace_hardirqs_off_caller+0x70/0x110
> [ 231.744102] ? _raw_spin_unlock_irqrestore+0x46/0x50
> [ 231.744120] ? find_held_lock+0x119/0x150
> [ 231.744138] ? mark_lock+0x6d/0x850
> [ 231.744241] ? gen8_gt_irq_ack+0x1f0/0x1f0 [i915]
> [ 231.744262] ? work_on_cpu_safe+0x60/0x60
> [ 231.744284] ? rcu_read_lock_sched_held+0x57/0xa0
> [ 231.744400] ? gen6_read32+0x2ba/0x320 [i915]
> [ 231.744506] i915_handle_error+0x382/0x5f0 [i915]
> [ 231.744611] ? gen6_rps_reset_ei+0x20/0x20 [i915]
> [ 231.744630] ? vsnprintf+0x128/0x8e0
> [ 231.744649] ? pointer+0x6b0/0x6b0
> [ 231.744667] ? debug_check_no_locks_freed+0x1a0/0x1a0
> [ 231.744688] ? scnprintf+0x92/0xe0
> [ 231.744706] ? snprintf+0xb0/0xb0
> [ 231.744820] hangcheck_declare_hang+0x15a/0x1a0 [i915]
> [ 231.744932] ? engine_stuck+0x440/0x440 [i915]
> [ 231.744951] ? rcu_read_lock_sched_held+0x57/0xa0
> [ 231.745062] ? gen6_read32+0x2ba/0x320 [i915]
> [ 231.745173] ? gen6_read16+0x320/0x320 [i915]
> [ 231.745284] ? intel_engine_get_active_head+0x91/0x170 [i915]
> [ 231.745401] i915_hangcheck_elapsed+0x3d8/0x400 [i915]
> [ 231.745424] process_one_work+0x3e8/0xac0
> [ 231.745444] ? pwq_dec_nr_in_flight+0x110/0x110
> [ 231.745464] ? do_raw_spin_lock+0x8e/0x120
> [ 231.745484] worker_thread+0x8d/0x720
> [ 231.745506] kthread+0x19e/0x1f0
> [ 231.745524] ? process_one_work+0xac0/0xac0
> [ 231.745541] ? kthread_create_on_node+0xa0/0xa0
> [ 231.745560] ret_from_fork+0x27/0x40
> [ 231.745581] Code: 8b 7d c8 e8 49 0d 02 e1 49 8b 7f 38 48 8b 75 b8 48 83 c7
> 10 e8 b8 89 be e1 e9 95 fc ff ff 4c 89 e7 e8 4b b9 ff ff e9 30 ff ff ff <0f>
> 0b 0f 1f 40 00 55 48 89 e5 41 57 41 56 41 55 41 54 49 89 fe
> [ 231.745767] RIP: i915_gem_reset_engine+0x45a/0x460 [i915] RSP:
> 8801f42ff770
>
> At first glance this looks to be related to commit c64992e035d7
> ("drm/i915: Look for active requests earlier in the reset path"), but it
> could easily happen before as well. On the other hand, we no longer
> logged victims due to the active_request being dropped earlier.
>
> Reported-by: Daniel Vetter
> Fixes: c64992e035d7 ("drm/i915: Look for active requests earlier in the reset
> path")
> Signed-off-by: Chris Wilson
> Cc: Michel Thierry
> Cc: Mika Kuoppala
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_gem.c | 37 +++--
> 1 file changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index b1520052a5e4..3ad1352dc871 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2914,11 +2914,9 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs
> *engine)
> if (engine->irq_seqno_barrier)
> engine->irq_seqno_barrier(engine);
>
> - if (engine_stalled(engine)) {
> - request = i915_gem_find_active_requ
Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/execlists: Read the context-status HEAD from the HWSP
Chris Wilson writes:
> The engine also provides a mirror of the CSB write pointer in the HWSP,
> but not of our read pointer. To take advantage of this we need to
> remember where we read up to on the last interrupt and continue off from
> there. This poses a problem following a reset, as we don't know where
> the hw will start writing from, and due to the use of power contexts we
> cannot perform that query during the reset itself. So we continue the
> current modus operandi of delaying the first read of the context-status
> read/write pointers until after the first interrupt. With this we should
> now have eliminated all uncached mmio reads in handling the
> context-status interrupt, though we still have the uncached mmio writes
> for submitting new work, and many uncached mmio reads in the global
> interrupt handler itself. Still a step in the right direction towards
> reducing our resubmit latency, although it appears lost in the noise!
>
> v2: Cannonlake moved the CSB write index
> v3: Include the sw/hwsp state in debugfs/i915_engine_info
> v4: Also revert to using CSB mmio for GVT-g
>
> Signed-off-by: Chris Wilson
> Cc: Michel Thierry
> Cc: Tvrtko Ursulin
> Cc: Mika Kuoppala
> Cc: Daniele Ceraolo Spurio
> Cc: Zhenyu Wang
> Cc: Zhi Wang
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 6 --
> drivers/gpu/drm/i915/i915_drv.h | 8
> drivers/gpu/drm/i915/intel_lrc.c| 25 -
> drivers/gpu/drm/i915/intel_ringbuffer.h | 3 +++
> 4 files changed, 35 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 5fd01c14a3ec..552aef61b47b 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3395,8 +3395,10 @@ static int i915_engine_info(struct seq_file *m, void
> *unused)
> ptr = I915_READ(RING_CONTEXT_STATUS_PTR(engine));
> read = GEN8_CSB_READ_PTR(ptr);
> write = GEN8_CSB_WRITE_PTR(ptr);
> - seq_printf(m, "\tExeclist CSB read %d, write %d\n",
> -read, write);
> + seq_printf(m, "\tExeclist CSB read %d [%d cached],
> write %d [%d from hws]\n",
> +read, engine->csb_head,
> +write,
> +intel_read_status_page(engine,
> intel_hws_csb_write_index(engine->i915)));
> if (read >= GEN8_CSB_ENTRIES)
> read = 0;
> if (write >= GEN8_CSB_ENTRIES)
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 81cd21ecfa7d..f62c9db8a9a8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -4228,4 +4228,12 @@ static inline bool i915_gem_object_is_coherent(struct
> drm_i915_gem_object *obj)
> HAS_LLC(to_i915(obj->base.dev)));
> }
>
> +static inline int intel_hws_csb_write_index(struct drm_i915_private *i915)
> +{
> + if (INTEL_GEN(i915) >= 10)
> + return CNL_HWS_CSB_WRITE_INDEX;
> + else
> + return I915_HWS_CSB_WRITE_INDEX;
> +}
> +
> #endif
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 5b721f65d232..7c3dce27e504 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -556,6 +556,7 @@ static void intel_lrc_irq_handler(unsigned long data)
> if (unlikely(intel_vgpu_active(dev_priv))) {
> buf = (u32 * __force)
> (dev_priv->regs +
> i915_mmio_reg_offset(RING_CONTEXT_STATUS_PTR(engine)));
> + engine->csb_head = -1;
> }
>
> /* The write will be ordered by the uncached read (itself
> @@ -569,9 +570,19 @@ static void intel_lrc_irq_handler(unsigned long data)
>* is set and we do a new loop.
>*/
> __clear_bit(ENGINE_IRQ_EXECLIST, &engine->irq_posted);
> - head = readl(csb_mmio);
> - tail = GEN8_CSB_WRITE_PTR(head);
> - head = GEN8_CSB_READ_PTR(head);
> + if (unlikely(engine->csb_head == -1)) { /* following a reset */
> + head = readl(csb_mmio);
> + tail = GEN8_CSB_WRITE_PTR(head);
> + head = GEN8_CSB_READ_PTR(head);
> + engine->csb_head = head;
> + } else {
> + const int write_idx =
> + intel_hws_csb_write_index(dev_priv) -
> + I915_HWS_CSB_BUF0_INDEX;
> +
> + head = engine->csb_head;
> + tail = buf[write_idx];
> + }
I have discussed this with Chris already in irc but I have a kbl
that can't survive the patch. The hwsp tail seems
[Intel-gfx] ✓ Fi.CI.BAT: success for dma-fence: Don't BUG_ON when not absolutely needed
== Series Details == Series: dma-fence: Don't BUG_ON when not absolutely needed URL : https://patchwork.freedesktop.org/series/27636/ State : success == Summary == Series 27636v1 dma-fence: Don't BUG_ON when not absolutely needed https://patchwork.freedesktop.org/api/1.0/series/27636/revisions/1/mbox/ Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-snb-2600) fdo#100215 +1 Test kms_flip: Subgroup basic-flip-vs-modeset: pass -> SKIP (fi-skl-x1585l) fdo#101781 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> DMESG-WARN (fi-pnv-d510) fdo#101597 Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-byt-n2820) fdo#101705 fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215 fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fdo#101705 https://bugs.freedesktop.org/show_bug.cgi?id=101705 fi-bdw-5557u total:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:448s fi-bdw-gvtdvmtotal:279 pass:265 dwarn:0 dfail:0 fail:0 skip:14 time:427s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:356s fi-bsw-n3050 total:279 pass:243 dwarn:0 dfail:0 fail:0 skip:36 time:540s fi-bxt-j4205 total:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:514s fi-byt-j1900 total:279 pass:254 dwarn:1 dfail:0 fail:0 skip:24 time:483s fi-byt-n2820 total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:486s fi-glk-2atotal:279 pass:260 dwarn:0 dfail:0 fail:0 skip:19 time:596s fi-hsw-4770 total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:442s fi-hsw-4770r total:279 pass:263 dwarn:0 dfail:0 fail:0 skip:16 time:417s fi-ilk-650 total:279 pass:229 dwarn:0 dfail:0 fail:0 skip:50 time:411s fi-ivb-3520m total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:504s fi-ivb-3770 total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:481s fi-kbl-7500u total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:467s fi-kbl-7560u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:578s fi-kbl-r total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:586s fi-pnv-d510 total:279 pass:221 dwarn:3 dfail:0 fail:0 skip:55 time:564s fi-skl-6260u total:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:460s fi-skl-6700hqtotal:279 pass:262 dwarn:0 dfail:0 fail:0 skip:17 time:587s fi-skl-6700k total:279 pass:261 dwarn:0 dfail:0 fail:0 skip:18 time:475s fi-skl-6770hqtotal:279 pass:269 dwarn:0 dfail:0 fail:0 skip:10 time:485s fi-skl-x1585ltotal:279 pass:268 dwarn:0 dfail:0 fail:0 skip:11 time:470s fi-snb-2520m total:279 pass:251 dwarn:0 dfail:0 fail:0 skip:28 time:534s fi-snb-2600 total:279 pass:249 dwarn:0 dfail:0 fail:1 skip:29 time:399s 948c3bddbe7245970c684749ba5d72370cd2 drm-tip: 2017y-07m-20d-10h-52m-43s UTC integration manifest 05f99fd dma-fence: Don't BUG_ON when not absolutely needed == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5250/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/15] drm/i915: Wake up waiters after setting the WEDGED bit
Chris Wilson writes: > After setting the WEDGED bit, make sure that we do wake up waiters as > they may not be waiting for a request completion yet, just for its > execution. > > Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/i915_gem.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index 40e94b4ef532..ca7a56ff3904 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -3157,10 +3157,12 @@ static int __i915_gem_set_wedged_BKL(void *data) > struct intel_engine_cs *engine; > enum intel_engine_id id; > > - set_bit(I915_WEDGED, &i915->gpu_error.flags); > for_each_engine(engine, i915, id) > engine_set_wedged(engine); > > + set_bit(I915_WEDGED, &i915->gpu_error.flags); > + wake_up_all(&i915->gpu_error.reset_queue); > + > return 0; > } > > -- > 2.13.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Don't touch fence->error when resetting an innocent request
If the request has been completed before the reset took effect, we don't
need to mark it up as being a victim. Touching fence->error after the
fence has been signaled is detected by dma_fence_set_error() and
triggers a BUG:
[ 231.743133] kernel BUG at ./include/linux/dma-fence.h:434!
[ 231.743156] invalid opcode: [#1] SMP KASAN
[ 231.743172] Modules linked in: i915 drm_kms_helper drm iptable_nat
nf_nat_ipv4 nf_nat x86_pkg_temp_thermal iosf_mbi i2c_algo_bit cfbfillrect
syscopyarea cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea fb font
fbdev [last unloaded: drm]
[ 231.743221] CPU: 2 PID: 20 Comm: kworker/2:0 Tainted: G U
4.13.0-rc1+ #52
[ 231.743236] Hardware name: Hewlett-Packard HP EliteBook 8460p/161C, BIOS
68SCF Ver. F.01 03/11/2011
[ 231.743363] Workqueue: events_long i915_hangcheck_elapsed [i915]
[ 231.743382] task: 8801f42e9780 task.stack: 8801f42f8000
[ 231.743489] RIP: 0010:i915_gem_reset_engine+0x45a/0x460 [i915]
[ 231.743505] RSP: 0018:8801f42ff770 EFLAGS: 00010202
[ 231.743521] RAX: 0007 RBX: 8801bf6b1880 RCX: a02881a6
[ 231.743537] RDX: dc00 RSI: dc00 RDI: 8801bf6b18c8
[ 231.743551] RBP: 8801f42ff7c8 R08: 0001 R09:
[ 231.743566] R10: R11: R12: 8801edb02d00
[ 231.743581] R13: 8801e19d4200 R14: 001d R15: 8801ce2a4000
[ 231.743599] FS: () GS:8801f5a8()
knlGS:
[ 231.743614] CS: 0010 DS: ES: CR0: 80050033
[ 231.743629] CR2: 7f0ebd1add10 CR3: 02621000 CR4: 000406e0
[ 231.743643] Call Trace:
[ 231.743752] i915_gem_reset+0x6c/0x150 [i915]
[ 231.743853] i915_reset+0x175/0x210 [i915]
[ 231.743958] i915_reset_device+0x33b/0x350 [i915]
[ 231.744061] ? valleyview_pipestat_irq_handler+0xe0/0xe0 [i915]
[ 231.744081] ? trace_hardirqs_off_caller+0x70/0x110
[ 231.744102] ? _raw_spin_unlock_irqrestore+0x46/0x50
[ 231.744120] ? find_held_lock+0x119/0x150
[ 231.744138] ? mark_lock+0x6d/0x850
[ 231.744241] ? gen8_gt_irq_ack+0x1f0/0x1f0 [i915]
[ 231.744262] ? work_on_cpu_safe+0x60/0x60
[ 231.744284] ? rcu_read_lock_sched_held+0x57/0xa0
[ 231.744400] ? gen6_read32+0x2ba/0x320 [i915]
[ 231.744506] i915_handle_error+0x382/0x5f0 [i915]
[ 231.744611] ? gen6_rps_reset_ei+0x20/0x20 [i915]
[ 231.744630] ? vsnprintf+0x128/0x8e0
[ 231.744649] ? pointer+0x6b0/0x6b0
[ 231.744667] ? debug_check_no_locks_freed+0x1a0/0x1a0
[ 231.744688] ? scnprintf+0x92/0xe0
[ 231.744706] ? snprintf+0xb0/0xb0
[ 231.744820] hangcheck_declare_hang+0x15a/0x1a0 [i915]
[ 231.744932] ? engine_stuck+0x440/0x440 [i915]
[ 231.744951] ? rcu_read_lock_sched_held+0x57/0xa0
[ 231.745062] ? gen6_read32+0x2ba/0x320 [i915]
[ 231.745173] ? gen6_read16+0x320/0x320 [i915]
[ 231.745284] ? intel_engine_get_active_head+0x91/0x170 [i915]
[ 231.745401] i915_hangcheck_elapsed+0x3d8/0x400 [i915]
[ 231.745424] process_one_work+0x3e8/0xac0
[ 231.745444] ? pwq_dec_nr_in_flight+0x110/0x110
[ 231.745464] ? do_raw_spin_lock+0x8e/0x120
[ 231.745484] worker_thread+0x8d/0x720
[ 231.745506] kthread+0x19e/0x1f0
[ 231.745524] ? process_one_work+0xac0/0xac0
[ 231.745541] ? kthread_create_on_node+0xa0/0xa0
[ 231.745560] ret_from_fork+0x27/0x40
[ 231.745581] Code: 8b 7d c8 e8 49 0d 02 e1 49 8b 7f 38 48 8b 75 b8 48 83 c7
10 e8 b8 89 be e1 e9 95 fc ff ff 4c 89 e7 e8 4b b9 ff ff e9 30 ff ff ff <0f> 0b
0f 1f 40 00 55 48 89 e5 41 57 41 56 41 55 41 54 49 89 fe
[ 231.745767] RIP: i915_gem_reset_engine+0x45a/0x460 [i915] RSP:
8801f42ff770
At first glance this looks to be related to commit c64992e035d7
("drm/i915: Look for active requests earlier in the reset path"), but it
could easily happen before as well. On the other hand, we no longer
logged victims due to the active_request being dropped earlier.
v2: Be trickier to unwind the incomplete request as we cannot rely on
request retirement for the lockless per-engine reset.
Reported-by: Daniel Vetter
Fixes: c64992e035d7 ("drm/i915: Look for active requests earlier in the reset
path")
Signed-off-by: Chris Wilson
Cc: Michel Thierry
Cc: Mika Kuoppala
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 45 -
1 file changed, 27 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b1520052a5e4..607791724fa7 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2914,11 +2914,9 @@ i915_gem_reset_prepare_engine(struct intel_engine_cs
*engine)
if (engine->irq_seqno_barrier)
engine->irq_seqno_barrier(engine);
- if (engine_stalled(engine)) {
- request = i915_gem_find_active_request(engine);
- if (request && request->fence.error == -EIO)
- request = ERR_PTR(-EIO); /
Re: [Intel-gfx] [PATCH 08/15] drm/i915: Clear execlist port[] before updating seqno on wedging
Quoting Mika Kuoppala (2017-07-20 14:31:31) > Chris Wilson writes: > > > When we wedge the device, we clear out the in-flight requests and > > advance the breadcrumb to indicate they are complete. However, the > > breadcrumb advance includes an assert that the engine is idle, so that > > advancement needs to be the last step to ensure we pass our own sanity > > checks. > > I am confused about this one. The previous patch seems to make > the concern void. Yeah, I moved the assert around, but still felt the order imposed by the memory of that assert was better. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Linaro-mm-sig] [PATCH] dma-fence: Don't BUG_ON when not absolutely needed
Am Donnerstag, den 20.07.2017, 14:51 +0200 schrieb Daniel Vetter:
> It makes debugging a massive pain.
It is also considered very bad style to BUG the kernel on anything other
than filesystem eating catastrophic failures.
Reviewed-by: Lucas Stach
> Signed-off-by: Daniel Vetter
> Cc: Sumit Semwal
> Cc: Gustavo Padovan
> Cc: linux-me...@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> ---
> drivers/dma-buf/dma-fence.c | 4 ++--
> include/linux/dma-fence.h | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 56e0a0e1b600..9a302799040e 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -48,7 +48,7 @@ static atomic64_t dma_fence_context_counter =
> ATOMIC64_INIT(0);
> */
> u64 dma_fence_context_alloc(unsigned num)
> {
> - BUG_ON(!num);
> + WARN_ON(!num);
> return atomic64_add_return(num, &dma_fence_context_counter) - num;
> }
> EXPORT_SYMBOL(dma_fence_context_alloc);
> @@ -172,7 +172,7 @@ void dma_fence_release(struct kref *kref)
>
> trace_dma_fence_destroy(fence);
>
> - BUG_ON(!list_empty(&fence->cb_list));
> + WARN_ON(!list_empty(&fence->cb_list));
>
> if (fence->ops->release)
> fence->ops->release(fence);
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> index 9342cf0dada4..171895072435 100644
> --- a/include/linux/dma-fence.h
> +++ b/include/linux/dma-fence.h
> @@ -431,8 +431,8 @@ int dma_fence_get_status(struct dma_fence *fence);
> static inline void dma_fence_set_error(struct dma_fence *fence,
> int error)
> {
> - BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
> - BUG_ON(error >= 0 || error < -MAX_ERRNO);
> + WARN_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
> + WARN_ON(error >= 0 || error < -MAX_ERRNO);
>
> fence->error = error;
> }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] docs: Update documentation generation with missing entries
This adds missing entries for documentation generation, both for tests and the API reference. The list of tests is made complete and ordered alphabetically, with modified descriptions for consistency. More files are added to the API reference, with a minimalistic description block added to them when it was missing. Signed-off-by: Paul Kocialkowski --- docs/reference/intel-gpu-tools/Makefile.am | 24 +++- .../intel-gpu-tools/igt_test_programs.xml | 123 + .../intel-gpu-tools/intel-gpu-tools-docs.xml | 26 +++-- lib/igt_gvt.c | 7 ++ lib/igt_primes.c | 7 ++ lib/igt_rand.c | 7 ++ lib/igt_x86.c | 7 ++ lib/sw_sync.c | 7 ++ 8 files changed, 174 insertions(+), 34 deletions(-) diff --git a/docs/reference/intel-gpu-tools/Makefile.am b/docs/reference/intel-gpu-tools/Makefile.am index 0152a40e..ee1e900f 100644 --- a/docs/reference/intel-gpu-tools/Makefile.am +++ b/docs/reference/intel-gpu-tools/Makefile.am @@ -134,7 +134,11 @@ IGNORE_HFILES=gen6_render.h gen7_media.h gen7_render.h gen8_media.h \ # e.g. HTML_IMAGES=$(top_srcdir)/gtk/stock-icons/stock_about_24.png HTML_IMAGES= -test_program_files = xml/igt_test_programs_core_description.xml \ +test_program_files = xml/igt_test_programs_amdgpu_description.xml \ +xml/igt_test_programs_amdgpu_programs.xml \ +xml/igt_test_programs_chamelium_description.xml \ +xml/igt_test_programs_chamelium_programs.xml \ +xml/igt_test_programs_core_description.xml \ xml/igt_test_programs_core_programs.xml \ xml/igt_test_programs_debugfs_description.xml \ xml/igt_test_programs_debugfs_programs.xml \ @@ -146,14 +150,28 @@ test_program_files = xml/igt_test_programs_core_description.xml \ xml/igt_test_programs_gem_programs.xml \ xml/igt_test_programs_gen3_description.xml \ xml/igt_test_programs_gen3_programs.xml \ +xml/igt_test_programs_gen7_description.xml \ +xml/igt_test_programs_gen7_programs.xml \ +xml/igt_test_programs_gvt_description.xml \ +xml/igt_test_programs_gvt_programs.xml \ xml/igt_test_programs_kms_description.xml \ xml/igt_test_programs_kms_programs.xml \ +xml/igt_test_programs_meta_description.xml \ +xml/igt_test_programs_meta_programs.xml \ +xml/igt_test_programs_perf_description.xml \ +xml/igt_test_programs_perf_programs.xml \ xml/igt_test_programs_pm_description.xml \ xml/igt_test_programs_pm_programs.xml \ xml/igt_test_programs_prime_description.xml \ xml/igt_test_programs_prime_programs.xml \ -xml/igt_test_programs_sysfs_description.xml \ -xml/igt_test_programs_sysfs_programs.xml \ +xml/igt_test_programs_sw_sync_description.xml \ +xml/igt_test_programs_sw_sync_programs.xml \ +xml/igt_test_programs_testdisplay_description.xml \ +xml/igt_test_programs_testdisplay_programs.xml \ +xml/igt_test_programs_tools_description.xml \ +xml/igt_test_programs_tools_programs.xml \ +xml/igt_test_programs_vgem_description.xml \ +xml/igt_test_programs_vgem_programs.xml \ $(NULL) # Extra SGML files that are included by $(DOC_MAIN_SGML_FILE). diff --git a/docs/reference/intel-gpu-tools/igt_test_programs.xml b/docs/reference/intel-gpu-tools/igt_test_programs.xml index 97159df9..ec05d53e 100644 --- a/docs/reference/intel-gpu-tools/igt_test_programs.xml +++ b/docs/reference/intel-gpu-tools/igt_test_programs.xml @@ -100,19 +100,46 @@ + + + AMDGPU Tests + Tests for amdgpu driver behaviour + + + + + + + + Chamelium Tests + Tests using the Chamelium platform + + + + + Core Tests - Tests for core drm ioctls and behaviour. + Tests for core drm ioctls and behaviour + + + Debugfs Tests + Tests for debugfs behaviour + + + + + DRM Tests - Tests for libdrm behaviour. + Tests for libdrm behaviour @@ -121,7 +148,7 @@ DRV Tests - Tests for overall driver behaviour. + Tests for overall driver behaviour @@ -130,21 +157,66 @@ GEM Tests - Tests for core drm ioctls and behaviour. + Tests for the gr
[Intel-gfx] [PATCH i-g-t 2/2] lib/igt_core: Split out env-related handling to common_init_env
This moves the parts of the code doing env-related handling from
common_init to a new dedicated common_init_env function, making
common_init a bit more readable.
Signed-off-by: Paul Kocialkowski
---
lib/igt_core.c | 46 ++
1 file changed, 26 insertions(+), 20 deletions(-)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index e25276fc..c0488e94 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -652,8 +652,6 @@ static void common_init_config(void)
g_clear_error(&error);
- frame_dump_path = getenv("IGT_FRAME_DUMP_PATH");
-
if (!frame_dump_path)
frame_dump_path = g_key_file_get_string(igt_key_file, "Common",
"FrameDumpPath",
@@ -676,6 +674,31 @@ out:
}
#endif
+static void common_init_env(void)
+{
+ const char *env;
+
+ if (!isatty(STDOUT_FILENO) || getenv("IGT_PLAIN_OUTPUT"))
+ __igt_plain_output = true;
+
+ if (!__igt_plain_output)
+ setlocale(LC_ALL, "");
+
+ env = getenv("IGT_LOG_LEVEL");
+ if (env) {
+ if (strcmp(env, "debug") == 0)
+ igt_log_level = IGT_LOG_DEBUG;
+ else if (strcmp(env, "info") == 0)
+ igt_log_level = IGT_LOG_INFO;
+ else if (strcmp(env, "warn") == 0)
+ igt_log_level = IGT_LOG_WARN;
+ else if (strcmp(env, "none") == 0)
+ igt_log_level = IGT_LOG_NONE;
+ }
+
+ frame_dump_path = getenv("IGT_FRAME_DUMP_PATH");
+}
+
static int common_init(int *argc, char **argv,
const char *extra_short_opts,
const struct option *extra_long_opts,
@@ -699,25 +722,8 @@ static int common_init(int *argc, char **argv,
int extra_opt_count;
int all_opt_count;
int ret = 0;
- const char *env;
-
- if (!isatty(STDOUT_FILENO) || getenv("IGT_PLAIN_OUTPUT"))
- __igt_plain_output = true;
-
- if (!__igt_plain_output)
- setlocale(LC_ALL, "");
- env = getenv("IGT_LOG_LEVEL");
- if (env) {
- if (strcmp(env, "debug") == 0)
- igt_log_level = IGT_LOG_DEBUG;
- else if (strcmp(env, "info") == 0)
- igt_log_level = IGT_LOG_INFO;
- else if (strcmp(env, "warn") == 0)
- igt_log_level = IGT_LOG_WARN;
- else if (strcmp(env, "none") == 0)
- igt_log_level = IGT_LOG_NONE;
- }
+ common_init_env();
command_str = argv[0];
if (strrchr(command_str, '/'))
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/2] lib/igt_core: Move all config-related parsing to common_init_config
This moves all the pieces related to config parsing to the dedicated
function for this purpose, renamed common_init_config for consistency.
It allows making the common_init function less big and more readable.
Signed-off-by: Paul Kocialkowski
---
lib/igt_core.c | 77 ++
1 file changed, 35 insertions(+), 42 deletions(-)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 03d9a5bf..e25276fc 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -622,13 +622,35 @@ static void oom_adjust_for_doom(void)
}
#ifdef HAVE_GLIB
-static int config_parse(void)
+static void common_init_config(void)
{
+ char *key_file_env = NULL;
+ char *key_file_loc = NULL;
GError *error = NULL;
- int rc;
+ int ret;
- if (!igt_key_file)
- return 0;
+ /* Determine igt config path */
+ key_file_env = getenv("IGT_CONFIG_PATH");
+ if (key_file_env) {
+ key_file_loc = key_file_env;
+ } else {
+ key_file_loc = malloc(100);
+ snprintf(key_file_loc, 100, "%s/.igtrc", g_get_home_dir());
+ }
+
+ /* Load igt config file */
+ igt_key_file = g_key_file_new();
+ ret = g_key_file_load_from_file(igt_key_file, key_file_loc,
+ G_KEY_FILE_NONE, &error);
+ if (error && error->code == G_KEY_FILE_ERROR) {
+ g_error_free(error);
+ g_key_file_free(igt_key_file);
+ igt_key_file = NULL;
+
+ goto out;
+ }
+
+ g_clear_error(&error);
frame_dump_path = getenv("IGT_FRAME_DUMP_PATH");
@@ -639,19 +661,18 @@ static int config_parse(void)
g_clear_error(&error);
- rc = g_key_file_get_integer(igt_key_file, "DUT", "SuspendResumeDelay",
- &error);
- if (error && error->code == G_KEY_FILE_ERROR_INVALID_VALUE) {
- g_error_free(error);
- return -2;
- }
+ ret = g_key_file_get_integer(igt_key_file, "DUT", "SuspendResumeDelay",
+&error);
+ assert(!error || error->code != G_KEY_FILE_ERROR_INVALID_VALUE);
g_clear_error(&error);
- if (rc != 0)
- igt_set_autoresume_delay(rc);
+ if (ret != 0)
+ igt_set_autoresume_delay(ret);
- return 0;
+out:
+ if (!key_file_env && key_file_loc)
+ free(key_file_loc);
}
#endif
@@ -678,9 +699,6 @@ static int common_init(int *argc, char **argv,
int extra_opt_count;
int all_opt_count;
int ret = 0;
- char *key_file_loc = NULL;
- char *key_file_env = NULL;
- GError *error = NULL;
const char *env;
if (!isatty(STDOUT_FILENO) || getenv("IGT_PLAIN_OUTPUT"))
@@ -802,36 +820,11 @@ static int common_init(int *argc, char **argv,
}
}
- key_file_env = getenv("IGT_CONFIG_PATH");
- if (key_file_env) {
- key_file_loc = key_file_env;
- } else {
- key_file_loc = malloc(100);
- snprintf(key_file_loc, 100, "%s/.igtrc", g_get_home_dir());
- }
-
#ifdef HAVE_GLIB
- igt_key_file = g_key_file_new();
- ret = g_key_file_load_from_file(igt_key_file, key_file_loc,
- G_KEY_FILE_NONE, &error);
- if (error && error->code == G_KEY_FILE_ERROR) {
- g_error_free(error);
- g_key_file_free(igt_key_file);
- igt_key_file = NULL;
- ret = -2;
-
- goto out;
- }
-
- g_clear_error(&error);
-
- ret = config_parse();
+ common_init_config();
#endif
out:
- if (!key_file_env && key_file_loc)
- free(key_file_loc);
-
free(short_opts);
free(combined_opts);
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v5 4/7] Introduce common frame dumping configuration and helpers
On Thu, 2017-07-20 at 09:24 +0200, Daniel Vetter wrote:
> On Wed, Jul 19, 2017 at 04:46:07PM +0300, Paul Kocialkowski wrote:
> > This introduces a common FrameDumpPath configuration field, as well
> > as
> > helper functions in dedicated igt_frame for writing cairo surfaces
> > to png files.
> >
> > Signed-off-by: Paul Kocialkowski
> > ---
> > lib/Makefile.sources | 2 +
> > lib/igt.h| 1 +
> > lib/igt_core.c | 12 +
> > lib/igt_core.h | 2 +-
> > lib/igt_frame.c | 137
> > +++
> > lib/igt_frame.h | 43
>
> Please make sure you pull the new docs into the docs build too. And
> while
> doing that, please review for other stuff added in the past year and
> include that too. And please build the docs and check the result.
I've just sent out a patch for that, thanks for pointing it out!
Cheers,
Paul
> Thanks, Daniel
>
> > 6 files changed, 196 insertions(+), 1 deletion(-)
> > create mode 100644 lib/igt_frame.c
> > create mode 100644 lib/igt_frame.h
> >
> > diff --git a/lib/Makefile.sources b/lib/Makefile.sources
> > index 53fdb54c..c2e58809 100644
> > --- a/lib/Makefile.sources
> > +++ b/lib/Makefile.sources
> > @@ -83,6 +83,8 @@ lib_source_list = \
> > uwildmat/uwildmat.c \
> > igt_kmod.c \
> > igt_kmod.h \
> > + igt_frame.c \
> > + igt_frame.h \
> > $(NULL)
> >
> > .PHONY: version.h.tmp
> > diff --git a/lib/igt.h b/lib/igt.h
> > index a069deb3..d16a4991 100644
> > --- a/lib/igt.h
> > +++ b/lib/igt.h
> > @@ -34,6 +34,7 @@
> > #include "igt_draw.h"
> > #include "igt_dummyload.h"
> > #include "igt_fb.h"
> > +#include "igt_frame.h"
> > #include "igt_gt.h"
> > #include "igt_kms.h"
> > #include "igt_pm.h"
> > diff --git a/lib/igt_core.c b/lib/igt_core.c
> > index 1ba79361..5a3b00e8 100644
> > --- a/lib/igt_core.c
> > +++ b/lib/igt_core.c
> > @@ -235,6 +235,10 @@
> > * An example configuration follows:
> > *
> > * |[
> > + * # The common configuration secton follows.
> > + * [Common]
> > + * FrameDumpPath=/tmp # The path to dump frames that fail
> > comparison checks
> > + *
> > * # The following section is used for configuring the
> > Device Under Test.
> > * # It is not mandatory and allows overriding default
> > values.
> > * [DUT]
> > @@ -290,6 +294,7 @@ static struct {
> > static pthread_mutex_t log_buffer_mutex =
> > PTHREAD_MUTEX_INITIALIZER;
> >
> > GKeyFile *igt_key_file;
> > +char *frame_dump_path;
> >
> > const char *igt_test_name(void)
> > {
> > @@ -621,6 +626,13 @@ static int config_parse(void)
> > if (!igt_key_file)
> > return 0;
> >
> > + frame_dump_path = getenv("IGT_FRAME_DUMP_PATH");
> > +
> > + if (!frame_dump_path)
> > + frame_dump_path =
> > g_key_file_get_string(igt_key_file, "Common",
> > + "FrameDumpP
> > ath",
> > + &error);
> > +
> > rc = g_key_file_get_integer(igt_key_file, "DUT",
> > "SuspendResumeDelay",
> > &error);
> > if (error && error->code == G_KEY_FILE_ERROR_INVALID_VALUE)
> > diff --git a/lib/igt_core.h b/lib/igt_core.h
> > index 0739ca83..1619a9d6 100644
> > --- a/lib/igt_core.h
> > +++ b/lib/igt_core.h
> > @@ -50,7 +50,7 @@
> > extern const char* __igt_test_description __attribute__((weak));
> > extern bool __igt_plain_output;
> > extern GKeyFile *igt_key_file;
> > -
> > +extern char *frame_dump_path;
> >
> > /**
> > * IGT_TEST_DESCRIPTION:
> > diff --git a/lib/igt_frame.c b/lib/igt_frame.c
> > new file mode 100644
> > index ..dfafe53d
> > --- /dev/null
> > +++ b/lib/igt_frame.c
> > @@ -0,0 +1,137 @@
> > +/*
> > + * Copyright © 2017 Intel Corporation
> > + *
> > + * Permission is hereby granted, free of charge, to any person
> > obtaining a
> > + * copy of this software and associated documentation files (the
> > "Software"),
> > + * to deal in the Software without restriction, including without
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute,
> > sublicense,
> > + * and/or sell copies of the Software, and to permit persons to
> > whom the
> > + * Software is furnished to do so, subject to the following
> > conditions:
> > + *
> > + * The above copyright notice and this permission notice (including
> > the next
> > + * paragraph) shall be included in all copies or substantial
> > portions of the
> > + * Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
> > EVENT SHALL
> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> > DAMAGES OR OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>
Re: [Intel-gfx] [PATCH 08/15] drm/i915: Clear execlist port[] before updating seqno on wedging
Chris Wilson writes: > Quoting Mika Kuoppala (2017-07-20 14:31:31) >> Chris Wilson writes: >> >> > When we wedge the device, we clear out the in-flight requests and >> > advance the breadcrumb to indicate they are complete. However, the >> > breadcrumb advance includes an assert that the engine is idle, so that >> > advancement needs to be the last step to ensure we pass our own sanity >> > checks. >> >> I am confused about this one. The previous patch seems to make >> the concern void. > > Yeah, I moved the assert around, but still felt the order imposed by > the memory of that assert was better. Agreet that the ordering is better. If you swap these two patches around, you dont have to change the commit msg. Otherwise change false notion that there is assert in this path. Reviewed-by: Mika Kuoppala ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [maintainer-tools PATCH] Add flowchart to help determine appropriate branch
This patch adds a flowchart to the drm-misc documentation to help committers decide which branch is most appropriate for a given patch. Signed-off-by: Sean Paul --- .gitignore | 1 + Makefile | 2 +- drm-misc-commit-flow.dot | 22 ++ drm-misc.rst | 10 ++ 4 files changed, 34 insertions(+), 1 deletion(-) create mode 100644 drm-misc-commit-flow.dot diff --git a/.gitignore b/.gitignore index e2bd6b6..35ed071 100644 --- a/.gitignore +++ b/.gitignore @@ -1,4 +1,5 @@ drm-intel-flow.svg +drm-misc-commit-flow.svg *.html .* *~ diff --git a/Makefile b/Makefile index e079e35..44fcdc9 100644 --- a/Makefile +++ b/Makefile @@ -18,7 +18,7 @@ drm-intel.html: drm-intel.rst drm-intel-flow.svg drm-intel-timeline.rst drm-inte sed -i 's/ $@ sed -i 's/ next_0[label="no"]; + is_fix -> in_origin[label="yes"]; + + in_origin -> fixes_0[label="yes"] + in_origin -> is_late[label="no"]; + + is_late -> next_1[label="no"] + is_late -> next_fixes_0[label="yes"] +} diff --git a/drm-misc.rst b/drm-misc.rst index c66ac67..05ccefb 100644 --- a/drm-misc.rst +++ b/drm-misc.rst @@ -73,6 +73,16 @@ updated drm-tip gets rebuilt. If there's a conflict see section on `resolving conflicts when rebuilding drm-tip `_. +Where Do I Apply My Patch? +~~ + +Consult this handy flowchart to determine the best branch for your patch. If in +doubt, apply to drm-misc-next or ask your favorite maintainer on IRC. + +.. Note: This requires SVG support in the browser. +.. raw:: html + :file: drm-misc-commit-flow.svg + Merge Timeline ~~ -- 2.14.0.rc0.284.gd933b75aa4-goog ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] igt: Add debugfs_test.read_all_entries to the fast-feedback list
Every time we add something to debugfs, we test on the new platform but forget to test that old platforms still work. The test adds at most 200 ms extra time, which is worth it considering how often we break debugfs. Signed-off-by: Maarten Lankhorst --- tests/intel-ci/fast-feedback.testlist | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/intel-ci/fast-feedback.testlist b/tests/intel-ci/fast-feedback.testlist index abe928d973e9..c1aa373d596d 100644 --- a/tests/intel-ci/fast-feedback.testlist +++ b/tests/intel-ci/fast-feedback.testlist @@ -2,6 +2,7 @@ igt@core_auth@basic-auth igt@core_prop_blob@basic +igt@debugfs_test@read_all_entries igt@drv_getparams_basic@basic-eu-total igt@drv_getparams_basic@basic-subslice-total igt@drv_hangman@error-state-basic -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/2] tests/debugfs_test: Fix testcases to pass
emon_crash should skip if the debugfs file could not be opened the first
time, and debugfs_test.read_all_entries should skip files that could not
be opened, instead of returning an error.
This is because in a typical IGT run there may be more debugfs files
registered than can be opened.
This is an example on f2-pnv-d510:
$ grep -r . /sys/kernel/debug/dri/0 >/dev/null
grep: /sys/kernel/debug/dri/0/i915_sseu_status: No such device
grep: /sys/kernel/debug/dri/0/i915_energy_uJ: No such device
grep: /sys/kernel/debug/dri/0/i915_sink_crc_eDP1: No such device
grep: /sys/kernel/debug/dri/0/i915_emon_status: No such device
grep: /sys/kernel/debug/dri/0/i915_guc_log_control: Invalid argument
grep: /sys/kernel/debug/dri/0/i915_fbc_false_color: No such device
grep: /sys/kernel/debug/dri/0/i915_cur_wm_latency: No such device
grep: /sys/kernel/debug/dri/0/i915_spr_wm_latency: No such device
grep: /sys/kernel/debug/dri/0/i915_pri_wm_latency: No such device
grep: /sys/kernel/debug/dri/0/i915_next_seqno: Permission denied
grep: /sys/kernel/debug/dri/0/i915_cache_sharing: No such device
grep: /sys/kernel/debug/dri/0/i915_min_freq: No such device
grep: /sys/kernel/debug/dri/0/i915_max_freq: No such device
grep: /sys/kernel/debug/dri/0/i915_pipe_C_crc: No such device
grep: /sys/kernel/debug/dri/0/i915_forcewake_user: Invalid argument
grep: /sys/kernel/debug/dri/0/crtc-1/crc/data: Input/output error
Signed-off-by: Maarten Lankhorst
Cc: Abdiel Janulgue
Cc: Arkadiusz Hiler
---
tests/debugfs_test.c | 38 --
1 file changed, 24 insertions(+), 14 deletions(-)
diff --git a/tests/debugfs_test.c b/tests/debugfs_test.c
index 122f7dc8bff6..1663fd41eab8 100644
--- a/tests/debugfs_test.c
+++ b/tests/debugfs_test.c
@@ -29,7 +29,7 @@
#include
#include
-static void read_and_discard_sysfs_entries(int path_fd, bool is_crc)
+static void read_and_discard_sysfs_entries(int path_fd)
{
struct dirent *dirent;
DIR *dir;
@@ -47,24 +47,31 @@ static void read_and_discard_sysfs_entries(int path_fd,
bool is_crc)
igt_assert((sub_fd =
openat(path_fd, dirent->d_name, O_RDONLY |
O_DIRECTORY)) > 0);
- read_and_discard_sysfs_entries(sub_fd,
!strcmp(dirent->d_name, "crc"));
+ read_and_discard_sysfs_entries(sub_fd);
close(sub_fd);
} else {
- char *buf;
+ char buf[512];
+ int sub_fd;
+ ssize_t ret;
igt_set_timeout(5, "reading sysfs entry");
- buf = igt_sysfs_get(path_fd, dirent->d_name);
- igt_reset_timeout();
- /*
-* /crtc-XX/crc/data may fail with -EIO if the CRTC
-* is not active.
-*/
- if (!buf && is_crc && errno == EIO &&
- !strcmp(dirent->d_name, "data"))
+ igt_debug("Reading file \"%s\"\n", dirent->d_name);
+
+ sub_fd = openat(path_fd, dirent->d_name, O_RDONLY);
+ if (sub_fd == -1) {
+ igt_debug("Could not open file \"%s\" with
error: %m\n", dirent->d_name);
continue;
+ }
- igt_assert(buf);
- free(buf);
+ do {
+ ret = read(sub_fd, buf, sizeof(buf));
+ } while (ret == sizeof(buf));
+
+ if (ret == -1)
+ igt_debug("Could not read file \"%s\" with
error: %m\n", dirent->d_name);
+
+ igt_reset_timeout();
+ close(sub_fd);
}
}
closedir(dir);
@@ -82,7 +89,7 @@ igt_main
}
igt_subtest("read_all_entries") {
- read_and_discard_sysfs_entries(debugfs, false);
+ read_and_discard_sysfs_entries(debugfs);
}
igt_subtest("emon_crash") {
@@ -95,6 +102,9 @@ igt_main
for (i = 0; i < 1000; i++) {
char *buf = igt_sysfs_get(debugfs,
"i915_emon_status");
+
+ igt_skip_on_f(!buf && !i, "i915_emon_status could not
be read\n");
+
igt_assert(buf);
free(buf);
}
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Fixes that failed to backport to v4.13-rc1
On Wed, 19 Jul 2017, Maarten Lankhorst
wrote:
> Op 19-07-17 om 15:17 schreef Jani Nikula:
>> Another kernel, another list of failed backports.
>>
>> The following commits have been marked as Cc: stable or fixing something
>> in v4.13-rc1 or earlier, but failed to cherry-pick to
>> drm-intel-fixes. Please see if they are worth backporting, and please do
>> so if they are.
>>
>> BR,
>> Jani.
>>
>> 54d20ed1fff2 ("drm/i915: Fix bad comparison in skl_compute_plane_wm, v2.")
>>
> v1 of this patch will apply. It was the version from before the
> renames that conflict here. :)
Thanks, picked it up to fixes.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Artifacts on virtual console basing on inteldrmfb framebuffer
Moving to intel-gfx list, intel-gfx-bugs is mainly just for the automated emails from bugzilla. And please let's keep the debugging in the bug. BR, Jani. On Thu, 20 Jul 2017, sdrb wrote: > Hello, > > I have got some problems with intel drm frame buffer on Linux virtual > terminals. > > After I switch back from Xorg to VT I receive artifacts on one of the > monitors. > Seems like there is "randr" somehow involved in this issue. > > I described this issue in more details in following bug report: > > https://bugs.freedesktop.org/show_bug.cgi?id=101772 > > Is it known issue and is there any solution for it? > > ___ > intel-gfx-bugs mailing list > intel-gfx-b...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx-bugs -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Synchronize connectors states when switching from poll to irq
On Thu, 2017-07-20 at 01:04 +, Pandiyan, Dhinakaran wrote:
> On Mon, 2017-06-26 at 15:32 +0300, Paul Kocialkowski wrote:
> > After detecting an IRQ storm, hotplug detection will switch from
> > irq-based detection to poll-based detection. After a short delay or
> > when resetting storm detection from debugfs, detection will switch
> > back to being irq-based.
> >
> > However, it may occur that polling does not have enough time to
> > detect
> > the current connector state when that second switch takes place.
>
> Some questions so that I understand this better. How short would this
> have to be for detect to not complete? Is there a way I can easily
> test this scenario?
Well, it doesn't really matter, the point is that it may happen that the
connector's hpd line changes in the time window between the last poll
(that happens every 100ms) and the moment the irq is enabled back. This
time window, however long it may be, always exists and it may happen
that this is exactly when the hpd event occurs.
It's possible to test this by triggering an hpd storm, then triggering a
regular hpd toggle and directly disabling polling mode via debugfs.
I was able to do this with a chamelium and did see the problem take
place.
> > Thus,
> > this sets the appropriate hotplug event bits for the concerned
> > connectors and schedules the hotplug work, that will ensure the
> > connectors states are in sync when switching back to irq.
>
> Not sure I understand this correctly, looks like you are setting the
> event_bits even if there was no irq during the polling interval. Is
> that right?
Yes, you are perfectly right. it is necessary to do this because the
event will not be detected either by polling (happening too late) nor by
the irq (happening too early). So we must trigger the hotplug work to
make it check whether the connectors states changed.
> > Without this, no irq will be triggered and the hpd change will be
> > lost.
> >
> > Signed-off-by: Paul Kocialkowski
> > ---
> > drivers/gpu/drm/i915/intel_hotplug.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> > b/drivers/gpu/drm/i915/intel_hotplug.c
> > index f1200272a699..29f55480b0bb 100644
> > --- a/drivers/gpu/drm/i915/intel_hotplug.c
> > +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> > @@ -218,9 +218,13 @@ static void
> > intel_hpd_irq_storm_reenable_work(struct work_struct *work)
> > struct intel_connector *intel_connector =
> > to_intel_connector(connector);
> >
> > if (intel_connector->encoder->hpd_pin == i)
> > {
> > - if (connector->polled !=
> > intel_connector->polled)
> > + if (connector->polled !=
> > intel_connector->polled) {
> > DRM_DEBUG_DRIVER("Reenablin
> > g HPD on connector %s\n",
> > connector-
> > >name);
> > +
> > + dev_priv-
> > >hotplug.event_bits |= (1 << i);
> > + }
> > +
> > connector->polled =
> > intel_connector->polled;
> > if (!connector->polled)
> > connector->polled =
> > DRM_CONNECTOR_POLL_HPD;
> > @@ -232,6 +236,8 @@ static void
> > intel_hpd_irq_storm_reenable_work(struct work_struct *work)
> > dev_priv->display.hpd_irq_setup(dev_priv);
> > spin_unlock_irq(&dev_priv->irq_lock);
> >
> > + schedule_work(&dev_priv->hotplug.hotplug_work);
>
> How does this work with DP connectors? From what I understand, the
> event_bits are set for DP based on the return value from
> intel_dp_hpd_pulse(). But, doesn't this patch set the bits
> unconditionally?
It works the same as other connectors, nothing specific there. The
hotplug work will read the connector's state and issue a uevent if its
value has changed.
> > +
> > intel_runtime_pm_put(dev_priv);
> > }
> >
--
Paul Kocialkowski
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo, Finland
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Synchronize connectors states when switching from poll to irq
On Wed, 2017-07-19 at 23:11 -0700, Manasi Navare wrote:
> On Tue, Jul 18, 2017 at 03:11:42PM +0300, Paul Kocialkowski wrote:
> > On Mon, 2017-06-26 at 15:32 +0300, Paul Kocialkowski wrote:
> > > After detecting an IRQ storm, hotplug detection will switch from
> > > irq-based detection to poll-based detection. After a short delay
> > > or
> > > when resetting storm detection from debugfs, detection will switch
> > > back to being irq-based.
> > >
> > > However, it may occur that polling does not have enough time to
> > > detect
> > > the current connector state when that second switch takes place.
> > > Thus,
> > > this sets the appropriate hotplug event bits for the concerned
> > > connectors and schedules the hotplug work, that will ensure the
> > > connectors states are in sync when switching back to irq.
> > >
> > > Without this, no irq will be triggered and the hpd change will be
> > > lost.
> >
> > Does anyone have feedback to provide on this?
> > It looks like it should be a no-brainer.
> >
> > Cheers,
> >
> > Paul
> >
> > > Signed-off-by: Paul Kocialkowski > > m>
> > > ---
> > > drivers/gpu/drm/i915/intel_hotplug.c | 8 +++-
> > > 1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c
> > > b/drivers/gpu/drm/i915/intel_hotplug.c
> > > index f1200272a699..29f55480b0bb 100644
> > > --- a/drivers/gpu/drm/i915/intel_hotplug.c
> > > +++ b/drivers/gpu/drm/i915/intel_hotplug.c
> > > @@ -218,9 +218,13 @@ static void
> > > intel_hpd_irq_storm_reenable_work(struct work_struct *work)
> > > struct intel_connector *intel_connector =
> > > to_intel_connector(connector);
> > >
> > > if (intel_connector->encoder->hpd_pin ==
> > > i) {
>
> So if this hpd pin in intel_connector->encoder is set then that
> means it got the hpd but because connector->polled is !=
> intel_connector->polled
> polling didnt detect that connector.
>
> Is that what you are trying to do here?
The first test is simply a way to match the intel_connector to the drm
connector. The second one indicates whether we are using polling or irq
mode. If they don't match (given the test earlier in the code that only
selects hpd pins that use irq mode), it means that we are switching from
polling mode to irq mode.
When that happens, it is necessary to assume that the connector state
may have changed (in the time window between the last poll and enabling
irq), so the hotplug work is scheduled. It will check whether a hpd
state change did happen or not and issue a uevent if that is the case.
> > > - if (connector->polled !=
> > > intel_connector->polled)
> > > + if (connector->polled !=
> > > intel_connector->polled) {
> > > DRM_DEBUG_DRIVER("Reenabl
> > > ing
> > > HPD on connector %s\n",
> > >connecto
> > > r-
> > > > name);
> > >
> > > +
> > > + dev_priv-
> > > >hotplug.event_bits
> > > > = (1 << i);
> > >
> > > + }
> > > +
> > > connector->polled =
> > > intel_connector-
> > > > polled;
> > >
> > > if (!connector->polled)
> > > connector->polled =
> > > DRM_CONNECTOR_POLL_HPD;
> > > @@ -232,6 +236,8 @@ static void
> > > intel_hpd_irq_storm_reenable_work(struct work_struct *work)
> > > dev_priv->display.hpd_irq_setup(dev_priv);
> > > spin_unlock_irq(&dev_priv->irq_lock);
> > >
> > > + schedule_work(&dev_priv->hotplug.hotplug_work);
> > > +
> > > intel_runtime_pm_put(dev_priv);
> > > }
> > >
> >
> > --
> > Paul Kocialkowski
> > Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo,
> > Finland
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Paul Kocialkowski
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo, Finland
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix scaler init during CRTC HW state readout
Acked-by: Shashank Sharma
Regards
Shashank
On 7/20/2017 4:20 AM, Imre Deak wrote:
The scaler allocation code depends on a non-zero default value for the
crtc scaler_id, so make sure we initialize the scaler state accordingly
even if the crtc is off. This fixes at least an initial YUV420 modeset
(added in a follow-up patchset by Shashank) when booting with the screen
off: after the initial HW readout and modeset which enables the scaler a
subsequent modeset will disable the scaler which isn't properly
allocated. This results in a funky HW state where the pipe scaler HW
registers can't be modified and the normally black screen is grey and
shifted to the right or jitters.
The problem was revealed by Shashank's YUV420 patchset and first
reported by Ville.
Cc: Shashank Sharma
Cc: Ville Syrjälä
Cc: Chandra Konduru
Cc: Matt Roper
Cc: # 4.11.x
Reported-by: Ville Syrjälä
Fixes: a1b2278e4dfc ("drm/i915: skylake panel fitting using shared scalers")
Signed-off-by: Imre Deak
---
[ Older stable versions need backporting, so that's for a follow-up ]
---
drivers/gpu/drm/i915/intel_display.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7774f3465fbc..8a38e64b1931 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9132,6 +9132,13 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
u64 power_domain_mask;
bool active;
+ if (INTEL_GEN(dev_priv) >= 9) {
+ intel_crtc_init_scalers(crtc, pipe_config);
+
+ pipe_config->scaler_state.scaler_id = -1;
+ pipe_config->scaler_state.scaler_users &= ~(1 <<
SKL_CRTC_INDEX);
+ }
+
power_domain = POWER_DOMAIN_PIPE(crtc->pipe);
if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
return false;
@@ -9160,13 +9167,6 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
pipe_config->gamma_mode =
I915_READ(GAMMA_MODE(crtc->pipe)) & GAMMA_MODE_MODE_MASK;
- if (INTEL_GEN(dev_priv) >= 9) {
- intel_crtc_init_scalers(crtc, pipe_config);
-
- pipe_config->scaler_state.scaler_id = -1;
- pipe_config->scaler_state.scaler_users &= ~(1 <<
SKL_CRTC_INDEX);
- }
-
power_domain = POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe);
if (intel_display_power_get_if_enabled(dev_priv, power_domain)) {
power_domain_mask |= BIT_ULL(power_domain);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Revert "drm/i915: Add heuristic to determine better way to adjust brightness"
On Tue, Jul 18, 2017 at 11:56:23AM -0700, Puthikorn Voravootivat wrote:
> May be the older panel might not work well with this feature.
> David/Jani, what do you think about adding check that the panel is eDP
> 1.4 or later in the heuristic?
While this patch might seem correct on the surface (with the patch
it now correctly prevents non-eDP 1.4 registers from being read on
sinks that aren't eDP 1.4 compliant), it still isn't correct
as per my understanding of the eDP 1.4 spec.
Chapter 10.1 of the eDP 1.4 spec clearly states that backlight through
AUX is an eDP v1.4 (and higher) feature.
The first conditional in this function will return true
if (!(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
If so, the backlight will attempt to use AUX backlight control
even on eDP sinks with a lower revision than v1.4.
So, per my reading of the eDP v1.4 spec, the conditional should be
the very first thing in this function (my eDP v1.3 device works
fine if the eDP version checks is at the beginning of the function,
but fails if it's after the PWM pin cap check).
Kind regards, David
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index b25cd88fc1c5..e63f2296fd34 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -292,7 +292,7 @@ intel_dp_aux_display_control_capable(struct
> intel_connector *connector)
> * via PWM pin or using AUX is better than using PWM pin.
> *
> * The heuristic to determine that using AUX pin is better than using
> PWM pin is
> - * that the panel support any of the feature list here.
> + * that the panel is eDP 1.4 or later and support any of the feature list
> here.
> * - Regional backlight brightness adjustment
> * - Backlight PWM frequency set
> * - More than 8 bits resolution of brightness level
> @@ -310,6 +310,10 @@ intel_dp_aux_display_control_heuristic(struct
> intel_connector *connector)
> if (!(intel_dp->edp_dpcd[2] &
> DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))
> return true;
>
> + /* Enable this for eDP 1.4 panel or later. */
> + if (intel_dp->edp_dpcd[0] < DP_EDP_14)
> + return false;
> +
> /* Panel supports regional backlight brightness adjustment */
> if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_GENERAL_CAP_3,
> ®_val) != 1) {
>
> On Mon, Jul 10, 2017 at 7:23 AM, David Weinehall
> wrote:
> > This reverts commit 560a758d39c616f83ac25ff6e0816a49ebe6401c.
> >
> > This patch has been identified to introduce a backlight regression
> > on at least two different platforms; either the heuristic is broken
> > (if so the patch needs to be reworked) or the in-kernel DPCD backlight
> > support is broken (if so it's premature to enable DPCD backlight
> > even if the platforms support it).
> >
> > Signed-off-by: David Weinehall
> > ---
> > drivers/gpu/drm/i915/i915_params.c| 7 ++-
> > drivers/gpu/drm/i915/i915_params.h| 1 -
> > drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 61
> > ++-
> > 3 files changed, 6 insertions(+), 63 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_params.c
> > b/drivers/gpu/drm/i915/i915_params.c
> > index 88b9d3e6713a..bec5ade371b0 100644
> > --- a/drivers/gpu/drm/i915/i915_params.c
> > +++ b/drivers/gpu/drm/i915/i915_params.c
> > @@ -63,7 +63,7 @@ struct i915_params i915 __read_mostly = {
> > .huc_firmware_path = NULL,
> > .enable_dp_mst = true,
> > .inject_load_failure = 0,
> > - .enable_dpcd_backlight = -1,
> > + .enable_dpcd_backlight = false,
> > .enable_gvt = false,
> > .enable_dbc = true,
> > };
> > @@ -247,10 +247,9 @@ MODULE_PARM_DESC(enable_dp_mst,
> > module_param_named_unsafe(inject_load_failure, i915.inject_load_failure,
> > uint, 0400);
> > MODULE_PARM_DESC(inject_load_failure,
> > "Force an error after a number of failure check points (0:disabled
> > (default), N:force failure at the Nth failure check point)");
> > -module_param_named_unsafe(enable_dpcd_backlight,
> > i915.enable_dpcd_backlight, int, 0600);
> > +module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight,
> > bool, 0600);
> > MODULE_PARM_DESC(enable_dpcd_backlight,
> > - "Enable support for DPCD backlight control "
> > - "(-1:auto (default), 0:force disable, 1:force enabled if
> > supported");
> > + "Enable support for DPCD backlight control (default:false)");
> >
> > module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
> > MODULE_PARM_DESC(enable_gvt,
> > diff --git a/drivers/gpu/drm/i915/i915_params.h
> > b/drivers/gpu/drm/i915/i915_params.h
> > index 057e203e6bda..6a88c76664db 100644
> > --- a/drivers/gpu/drm/i915/i915_params.h
> > +++ b/drivers/gpu/drm/i915/i915_params.h
> > @@ -53,7 +53,6 @@
> > func(int, edp_vswing); \
> > func(int
[Intel-gfx] [PATCH i-g-t v4 0/2] Analogue/VGA frame comparison support
Changes since v3: * Squashed configure.ac changes in this series Changes since v2: * Changed analogue in favor of analog * Integrated analog frame match fixup in the original commit * Rebased on top of the new revisions of the series this depends on Changes since v1: * Split analogue frame comparison to igt_frame, using cairo surfaces * Added a chamelium helper for analogue frame checking and frame dumping ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v4 2/2] chamelium: Add support for VGA frame comparison testing
This adds support for VGA frame comparison testing with the reference
generated from cairo. The retrieved frame from the chamelium is first
cropped, as it contains the blanking intervals, through a dedicated
helper. Another helper function asserts that the analog frame
matches or dump it to png if not.
Signed-off-by: Paul Kocialkowski
---
configure.ac| 4 ++
lib/igt_chamelium.c | 164 ++--
lib/igt_chamelium.h | 7 ++-
tests/chamelium.c | 57 ++
4 files changed, 226 insertions(+), 6 deletions(-)
diff --git a/configure.ac b/configure.ac
index 7ea768e2..dec3e923 100644
--- a/configure.ac
+++ b/configure.ac
@@ -197,6 +197,10 @@ if test "x$enable_chamelium" = xyes; then
if test x"$glib" != xyes; then
AC_MSG_ERROR([Failed to find glib, required by chamelium. Use
--disable-chamelium to disable chamelium support.])
fi
+ if test x"$gsl" != xyes; then
+ AC_MSG_ERROR([Failed to find gsl, required by chamelium. Use
--disable-chamelium to disable chamelium support.])
+ fi
+
AC_DEFINE(HAVE_CHAMELIUM, 1, [Enable Chamelium support])
fi
diff --git a/lib/igt_chamelium.c b/lib/igt_chamelium.c
index 348d2176..dcd8855f 100644
--- a/lib/igt_chamelium.c
+++ b/lib/igt_chamelium.c
@@ -937,6 +937,8 @@ static cairo_surface_t *convert_frame_dump_argb32(const
struct chamelium_frame_d
int w = dump->width, h = dump->height;
uint32_t *bits_bgr = (uint32_t *) dump->bgr;
unsigned char *bits_argb;
+ unsigned char *bits_target;
+ int size;
image_bgr = pixman_image_create_bits(
PIXMAN_b8g8r8, w, h, bits_bgr,
@@ -946,9 +948,13 @@ static cairo_surface_t *convert_frame_dump_argb32(const
struct chamelium_frame_d
bits_argb = (unsigned char *) pixman_image_get_data(image_argb);
- dump_surface = cairo_image_surface_create_for_data(
- bits_argb, CAIRO_FORMAT_ARGB32, w, h,
- PIXMAN_FORMAT_BPP(PIXMAN_x8r8g8b8) / 8 * w);
+ dump_surface = cairo_image_surface_create(
+ CAIRO_FORMAT_ARGB32, w, h);
+
+ bits_target = cairo_image_surface_get_data(dump_surface);
+ size = cairo_image_surface_get_stride(dump_surface) * h;
+ memcpy(bits_target, bits_argb, size);
+ cairo_surface_mark_dirty(dump_surface);
pixman_image_unref(image_argb);
@@ -1054,6 +1060,154 @@ void chamelium_assert_crc_eq_or_dump(struct chamelium
*chamelium,
}
/**
+ * chamelium_assert_analog_frame_match_or_dump:
+ * @chamelium: The chamelium instance the frame dump belongs to
+ * @frame: The chamelium frame dump to match
+ * @fb: pointer to an #igt_fb structure
+ *
+ * Asserts that the provided captured frame matches the reference frame from
+ * the framebuffer. If they do not, this saves the reference and captured
frames
+ * to a png file.
+ */
+void chamelium_assert_analog_frame_match_or_dump(struct chamelium *chamelium,
+struct chamelium_port *port,
+const struct
chamelium_frame_dump *frame,
+struct igt_fb *fb)
+{
+ cairo_surface_t *reference;
+ cairo_surface_t *capture;
+ igt_crc_t *reference_crc;
+ igt_crc_t *capture_crc;
+ char *reference_suffix;
+ char *capture_suffix;
+ bool match;
+
+ /* Grab the reference frame from framebuffer */
+ reference = igt_get_cairo_surface(chamelium->drm_fd, fb);
+
+ /* Grab the captured frame from chamelium */
+ capture = convert_frame_dump_argb32(frame);
+
+ match = igt_check_analog_frame_match(reference, capture);
+ if (!match && igt_frame_dump_is_enabled()) {
+ reference_crc = chamelium_calculate_fb_crc(chamelium->drm_fd,
+ fb);
+ capture_crc = chamelium_get_crc_for_area(chamelium, port, 0, 0,
+0, 0);
+
+ reference_suffix = igt_crc_to_string_extended(reference_crc,
+ '-', 2);
+ capture_suffix = igt_crc_to_string_extended(capture_crc, '-',
+ 2);
+
+ /* Write reference and capture frames to png */
+ igt_write_compared_frames_to_png(reference, capture,
+reference_suffix,
+capture_suffix);
+
+ free(reference_suffix);
+ free(capture_suffix);
+ }
+
+ cairo_surface_destroy(capture);
+
+ igt_assert(match);
+}
+
+
+/**
+ * chamelium_analog_frame_crop:
+ * @chamelium: The Chamelium instance to use
+ * @dump: The chamelium frame dump to crop
+ * @width: The cropped frame width
+ * @height: The crop
[Intel-gfx] [PATCH i-g-t v4 1/2] lib/igt_frame: Add support for analog frame comparison testing
This adds support for analog frame comparison check, as used in VGA.
Since VGA uses a DAC-ADC chain, its data cannot be expected to be pixel
perfect. Thus, it is impossible to uses a CRC check and full frames have
to be analyzed instead. Such an analysis is implemented, based on both
an absolute error threshold and a correlation with the expected error
trend for a DAC-ADC chain. It was tested with a couple encoders and
provides reliable error detection with few false positives.
Signed-off-by: Paul Kocialkowski
---
configure.ac | 2 +
lib/Makefile.am | 9
lib/Makefile.sources | 2 -
lib/igt_frame.c | 131 +++
lib/igt_frame.h | 2 +
5 files changed, 144 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 7655df1c..7ea768e2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -181,6 +181,8 @@ PKG_CHECK_MODULES(GLIB, [glib-2.0], [glib=yes], [glib=no])
if test x"$glib" = xyes; then
AC_DEFINE(HAVE_GLIB,1,[Enable glib support])
fi
+PKG_CHECK_MODULES(GSL, [gsl], [gsl=yes], [gsl=no])
+AM_CONDITIONAL(HAVE_GSL, [test "x$gsl" = xyes])
# for chamelium
AC_ARG_ENABLE(chamelium, AS_HELP_STRING([--disable-chamelium],
diff --git a/lib/Makefile.am b/lib/Makefile.am
index d4f41128..9c932d6f 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -29,12 +29,20 @@ lib_source_list += \
$(NULL)
endif
+if HAVE_GSL
+lib_source_list += \
+ igt_frame.c \
+ igt_frame.h \
+ $(NULL)
+endif
+
AM_CPPFLAGS = -I$(top_srcdir)
AM_CFLAGS = \
$(CWARNFLAGS) \
$(DRM_CFLAGS) \
$(PCIACCESS_CFLAGS) \
$(LIBUNWIND_CFLAGS) \
+ $(GSL_CFLAGS) \
$(KMOD_CFLAGS) \
$(PROCPS_CFLAGS) \
$(DEBUG_CFLAGS) \
@@ -54,6 +62,7 @@ libintel_tools_la_LIBADD = \
$(DRM_LIBS) \
$(PCIACCESS_LIBS) \
$(PROCPS_LIBS) \
+ $(GSL_LIBS) \
$(KMOD_LIBS) \
$(CAIRO_LIBS) \
$(LIBUDEV_LIBS) \
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index c2e58809..53fdb54c 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -83,8 +83,6 @@ lib_source_list = \
uwildmat/uwildmat.c \
igt_kmod.c \
igt_kmod.h \
- igt_frame.c \
- igt_frame.h \
$(NULL)
.PHONY: version.h.tmp
diff --git a/lib/igt_frame.c b/lib/igt_frame.c
index dfafe53d..222a45f8 100644
--- a/lib/igt_frame.c
+++ b/lib/igt_frame.c
@@ -29,6 +29,8 @@
#include
#include
#include
+#include
+#include
#include "igt.h"
@@ -135,3 +137,132 @@ void igt_write_compared_frames_to_png(cairo_surface_t
*reference,
close(fd);
}
+
+/**
+ * igt_check_analog_frame_match:
+ * @reference: The reference cairo surface
+ * @capture: The captured cairo surface
+ *
+ * Checks that the analog image contained in the chamelium frame dump matches
+ * the given framebuffer.
+ *
+ * In order to determine whether the frame matches the reference, the following
+ * reasoning is implemented:
+ * 1. The absolute error for each color value of the reference is collected.
+ * 2. The average absolute error is calculated for each color value of the
+ *reference and must not go above 60 (23.5 % of the total range).
+ * 3. A linear fit for the average absolute error from the pixel value is
+ *calculated, as a DAC-ADC chain is expected to have a linear error curve.
+ * 4. The linear fit is correlated with the actual average absolute error for
+ *the frame and the correlation coefficient is checked to be > 0.985,
+ *indicating a match with the expected error trend.
+ *
+ * Most errors (e.g. due to scaling, rotation, color space, etc) can be
+ * reliably detected this way, with a minimized number of false-positives.
+ * However, the brightest values (250 and up) are ignored as the error trend
+ * is often not linear there in practice due to clamping.
+ *
+ * Returns: a boolean indicating whether the frames match
+ */
+
+bool igt_check_analog_frame_match(cairo_surface_t *reference,
+ cairo_surface_t *capture)
+{
+ pixman_image_t *reference_src, *capture_src;
+ int w, h;
+ int error_count[3][256][2] = { 0 };
+ double error_average[4][250];
+ double error_trend[250];
+ double c0, c1, cov00, cov01, cov11, sumsq;
+ double correlation;
+ unsigned char *reference_pixels, *capture_pixels;
+ unsigned char *p;
+ unsigned char *q;
+ bool match = true;
+ int diff;
+ int x, y;
+ int i, j;
+
+ w = cairo_image_surface_get_width(reference);
+ h = cairo_image_surface_get_height(reference);
+
+ reference_src = pixman_image_create_bits(
+ PIXMAN_x8r8g8b8, w, h,
+ (void*)cairo_image_surface_get_data(reference),
+ cairo_image_surface_get_str
Re: [Intel-gfx] [PATCH i-g-t v3 0/2] Analogue/VGA frame comparison support
On Wed, 2017-07-19 at 13:50 -0400, Lyude Paul wrote: > For both patches once you squash the configure.ac changes into the > first one: > > Reviewed-by: Lyude > > Once you post the new versions I'll just go ahead and push them I think it makes more sense to split the configure.ac in two parts (as you'll see from v4). Since you may disgree, I haven't added your R-b. > On Wed, 2017-07-19 at 16:48 +0300, Paul Kocialkowski wrote: > > Changes since v2: > > * Changed analogue in favor of analog > > * Integrated analog frame match fixup in the original commit > > * Rebased on top of the new revisions of the series this depends on > > > > Changes since v1: > > * Split analogue frame comparison to igt_frame, using cairo surfaces > > * Added a chamelium helper for analogue frame checking and frame > > dumping > > -- Paul Kocialkowski Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo, Finland ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Calculate vlv/chv intermediate watermarks correctly, v3.
== Series Details == Series: drm/i915: Calculate vlv/chv intermediate watermarks correctly, v3. URL : https://patchwork.freedesktop.org/series/27639/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h CHK include/generated/timeconst.h CHK include/generated/asm-offsets.h CALLscripts/checksyscalls.sh CHK scripts/mod/devicetable-offsets.h CHK include/generated/compile.h CHK kernel/config_data.h CC [M] drivers/gpu/drm/i915/intel_pm.o drivers/gpu/drm/i915/intel_pm.c: In function ‘vlv_compute_intermediate_wm’: drivers/gpu/drm/i915/intel_pm.c:2012:3: error: implicit declaration of function ‘intel_atomic_get_old_crtc_state’ [-Werror=implicit-function-declaration] intel_atomic_get_old_crtc_state(new_crtc_state->base.state, crtc); ^ drivers/gpu/drm/i915/intel_pm.c:2012:3: error: initialization makes pointer from integer without a cast [-Werror=int-conversion] cc1: all warnings being treated as errors scripts/Makefile.build:302: recipe for target 'drivers/gpu/drm/i915/intel_pm.o' failed make[4]: *** [drivers/gpu/drm/i915/intel_pm.o] Error 1 scripts/Makefile.build:561: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:561: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:561: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1019: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
