Re: [Intel-gfx] [PATCH] drm/i915/gvt: Remove one duplicated MMIO

On 2017.08.23 13:23:10 +0800, Jian Jun Chen wrote: > Remove one duplicated MMIO GEN6_PCODE_MAILBOX. Duplicated MMIO will > cause host GVT-g initialization failure. > > Fixes: 9c3a16c887f0 ("drm/i915/hsw+: Add support for multiple power well > regs") > Signed-off-by: Jian Jun Chen > --- oh, as t

[Intel-gfx] [GIT PULL] gvt final fixes for 4.13

Hi, here's one final gvt fix for 4.13. One possible null ptr reference issue fixed by Fred. Thanks -- The following changes since commit d6086598d34e1cf9091c7be201f5b2041dc6203e: drm/i915/gvt: Change the max length of mmio_reg_rw from 4 to 8 (2017-08-07 15:50:39 +0800) are available in the g

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Remove one duplicated MMIO

On Wed, Aug 23, 2017 at 03:12:01PM +0800, Zhenyu Wang wrote: > On 2017.08.23 13:23:10 +0800, Jian Jun Chen wrote: > > Remove one duplicated MMIO GEN6_PCODE_MAILBOX. Duplicated MMIO will > > cause host GVT-g initialization failure. > > > > Fixes: 9c3a16c887f0 ("drm/i915/hsw+: Add support for multip

[Intel-gfx] [RFCv3 0/3] Introduce private PAT management

This patchset introduces private PPAT managment which enables dynamically configuring PPAT at runtime. The previous static PPAT configuration is kept unchanged. More background of this patchset can be found at: https://lists.freedesktop.org/archives/intel-gfx/2017-August/135415.html v3: - Remove

[Intel-gfx] [RFCv3 1/3] drm/i915: Factor out setup_private_pat()

Factor out setup_private_pat() for introducing the following patches. Signed-off-by: Zhi Wang --- drivers/gpu/drm/i915/i915_gem_gtt.c | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt

[Intel-gfx] [RFCv3 3/3] drm/i915: Introduce per-platform PPAT configurations

The previous static PPAT configuration for each platform is kept unchanged. Also the PPAT feature of each platform is described in intel PPAT instance during the initialization and related callbacks which supports the PPAT management framework will be hooked. Signed-off-by: Zhi Wang --- drivers/

[Intel-gfx] [RFCv3 2/3] drm/i915: Introduce private PAT management

The private PAT management is to support PPAT entry manipulation. Two APIs are introduced for dynamically managing PPAT entries: intel_ppat_get and intel_ppat_set. intel_ppat_get will search for an existing PPAT entry which perfectly matches the required PPAT value. If not, it will try to allocate

Re: [Intel-gfx] [maintainer-tools PATCH] dim.rst: Document aliases extension on dimrc.

On Tue, 22 Aug 2017, Rodrigo Vivi wrote: > On my own workflow I was missing a way to download mboxes > directly from patchwork with the patchwork id. So my first > reflex was to modify dim to fulfil my needs. However that > was increasing dim in complexity and dependencies and leaving > that messy

Re: [Intel-gfx] [maintainer-tools PATCH] dim: Properly handle series on apply_branch

On Tue, 22 Aug 2017, Rodrigo Vivi wrote: > So far we could use *dim* to apply a whole series > in a mbox, but only the very last patch was receiving > all the checks and patchwork link. > > So this patch remove this limitation by using git mailsplit > to split the mbox and than use git am and chec

[Intel-gfx] ✓ Fi.CI.BAT: success for Introduce private PAT management (rev2)

== Series Details == Series: Introduce private PAT management (rev2) URL : https://patchwork.freedesktop.org/series/29166/ State : success == Summary == Series 29166v2 Introduce private PAT management https://patchwork.freedesktop.org/api/1.0/series/29166/revisions/2/mbox/ Test kms_flip:

Re: [Intel-gfx] [maintainer-tools PATCH] dim: Properly handle series on apply_branch

On Wed, 23 Aug 2017, Jani Nikula wrote: > I gave you the example how to call apply_patch! ;) Huh, I *thought* I did, maybe I didn't. Sorry. if ! apply_patch $patch "$@"; then rv=1 fi Similar to the checkpatch_commit call in dim_apply_branch. BR Jani. -- Jani

[Intel-gfx] [PATCH 01/20] drm/i915: "Race-to-idle" on switching to the kernel context

During suspend we want to flush out all active contexts and their rendering. To do so we queue a request from the kernel's context, once we know that request is done, we know the GPU is completely idle. To speed up that switch bump the GPU clocks. Switching to the kernel context prior to idling is

[Intel-gfx] [PATCH 02/20] drm/i915: Assert the context is not closed on object-close

During the context-close, we should be decoupling all the vma from the object so that upon object-closing we shouldn't see any vma from the already closed contexts. So include a check upon closing the object that the context is still open. v2: Eek, the fpriv check is required for shared objects. D

[Intel-gfx] [PATCH 05/20] drm/i915: Prevent overflow of execbuf.buffer_count and num_cliprects

We check whether the multiplies will overflow prior to calling kmalloc_array so that we can respond with -EINVAL for the invalid user arguments rather than treating it as an -ENOMEM that would otherwise occur. However, as Dan Carpenter pointed out, we did an addition on the unsigned int prior to pa

[Intel-gfx] [PATCH 04/20] drm/i915: Ignore duplicate VMA stored within the per-object handle LUT

By using drm_gem_flink/drm_gem_open on an object using the same fd, it is possible for a client to create multiple handles pointing to the same object (tied to the same contexts and VMA), as exemplified by igt::gem_handle_to_libdrm_bo(). Since this duplication has been possible since forever, we ca

[Intel-gfx] The bunch of mm patches in the queue, mostly for shard testing

Lots of mostly reviewed shrinker patches, one contentious core mm patch, that makes vmpressure behave much better. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 07/20] drm/i915: Rename obj->pin_display to obj->pin_global

In the next patch, we want to extend use of the global pin counter for semi-permanent pinning of context/ring objects. Given that we plan to extend the usage to encompass a disparate set of objects, we want a name that reflects both and should entail less confusion. Signed-off-by: Chris Wilson --

[Intel-gfx] [PATCH 10/20] drm/i915: Move dev_priv->mm.[un]bound_list to its own lock

Remove the struct_mutex requirement around dev_priv->mm.bound_list and dev_priv->mm.unbound_list by giving it its own spinlock. This reduces one more requirement for struct_mutex and in the process gives us slightly more accurate unbound_list tracking, which should improve the shrinker - but the dr

[Intel-gfx] [PATCH 11/20] drm/i915: Set our shrinker->batch to 4096 (~16MiB)

Prefer to defer activating our GEM shrinker until we have a few megabytes to free; or we have accumulated sufficient mempressure by deferring the reclaim to force a shrink. The intent is that because our objects may typically be large, we are too effective at shrinking and are not rewarded for free

[Intel-gfx] [PATCH 14/20] drm/i915: Discard VMA lut handles upon purging the object

If we purge the object from the shrinker, it is no longer accessible and so we can reclaim it from the per-context lookup caches. For example, if the client is leaking objects (but leaving as I915_MADV_DONTNEED) then we still end up with significant mempressure from the unreclaimed radixtrees and s

[Intel-gfx] [PATCH 08/20] drm/i915: Drop debugfs/i915_gem_pin_display

It has now lost its meaning (it shows more than just pin_display), I do not believe that we are using in preference to the complete listing from i915_gem_gtt, or the listing from i915_gem_framebuffer, or the listing of active display objects in i915_display_info. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 12/20] drm/i915: Trim struct_mutex hold duration for i915_gem_free_objects

We free objects in bulk after they wait for their RCU grace period. Currently, we take struct_mutex and unbind all the objects. This can lead to a long lock duration during which time those objects have their pages unfreeable (i.e. the shrinker is prevented from reaping those pages). If we only pro

[Intel-gfx] [PATCH 03/20] drm/i915: Assert that the handle->vma lut is empty on object close

Make sure that we are not leaking an entry in the ctx->handles_lut by asserting that the object was removed prior to being freed. This should be enforced by all such handles being removed by i915_gem_close_object. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 1 + 1 file chan

[Intel-gfx] [PATCH 15/20] drm/i915: Only free the oldest stale object before a fresh allocation

Inspired by Tvrtko's critique of the reaping of the stale contexts before allocating a new one, also limit the freed object reaping to the oldest stale object before allocating a fresh object. Unlike contexts, objects may have radically different sizes of backing storage, but similar to contexts, w

[Intel-gfx] [PATCH 06/20] drm/i915: Refactor testing obj->mm.pages

Since we occasionally stuff an error pointer into obj->mm.pages for a semi-permanent or even permanent failure, we have to be more careful and not just test against NULL when deciding if the object has a complete set of its concurrent pages. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtine

[Intel-gfx] [PATCH 18/20] mm, drm/i915: Mark pinned shmemfs pages as unevictable

Similar in principle to the treatment of get_user_pages, pages that i915.ko acquires from shmemfs are not immediately reclaimable and so should be excluded from the mm accounting and vmscan until they have been returned to the system via shrink_slab/i915_gem_shrink. By moving the unreclaimable page

[Intel-gfx] [PATCH 20/20] drm/i915: Make GPU pages movable

On a long run of more than 2-3 days, physical memory tends to get fragmented severely, which considerably slows down the system. In such a scenario, the shrinker is also unable to help as lack of memory is not the actual problem, since it has been observed that there are enough free pages of 0 orde

[Intel-gfx] [PATCH 13/20] drm/i915: Start writeback from the shrinker

When we are called to relieve mempressue via the shrinker, the only way we can make progress is either by discarding unwanted pages (those objects that userspace has marked MADV_DONTNEED) or by reclaiming the dirty objects via swap. As we know that is the only way to make further progress, we can i

[Intel-gfx] [PATCH 16/20] mm: Track actual nr_scanned during shrink_slab()

Some shrinkers may only be able to free a bunch of objects at a time, and so free more than the requested nr_to_scan in one pass. Whilst other shrinkers may find themselves even unable to scan as many objects as they counted, and so underreport. Account for the extra freed/scanned objects against t

[Intel-gfx] [PATCH 17/20] drm/i915: Wire up shrinkctl->nr_scanned

shrink_slab() allows us to report back the number of objects we successfully scanned (out of the target shrinkctl->nr_to_scan). As report the number of pages owned by each GEM object as a separate item to the shrinker, we cannot precisely control the number of shrinker objects we scan on each pass;

[Intel-gfx] [PATCH 09/20] drm/i915: Remove walk over obj->vma_list for the shrinker

In the next patch, we want to reduce the lock coverage within the shrinker, and one of the dangerous walks we have is over obj->vma_list. We are only walking the obj->vma_list in order to check whether it has been permanently pinned by HW access, typically via use on the scanout. But we have a coup

[Intel-gfx] [PATCH 19/20] shmem: Support for registration of driver/file owner specific ops

From: Akash Goel This provides support for the drivers or shmem file owners to register a set of callbacks, which can be invoked from the address space operations methods implemented by shmem. This allow the file owners to hook into the shmem address space operations to do some extra/custom oper

Re: [Intel-gfx] [GIT PULL] gvt final fixes for 4.13

On Wed, 23 Aug 2017, Zhenyu Wang wrote: > Hi, here's one final gvt fix for 4.13. One possible null ptr > reference issue fixed by Fred. Pulled to drm-intel-fixes, thanks. BR, Jani. > > Thanks > -- > The following changes since commit d6086598d34e1cf9091c7be201f5b2041dc6203e: > > drm/i915/gvt:

Re: [Intel-gfx] [PATCH i-g-t 05/11] tests/perf: rework oa-exponent test

On 22/08/17 17:13, Matthew Auld wrote: On 22 August 2017 at 15:56, Lionel Landwerlin wrote: On 10/08/17 14:15, Matthew Auld wrote: On 4 August 2017 at 12:20, Lionel Landwerlin wrote: New issues that were discovered while making the tests work on Gen8+ : - we need to measure timings betwee

Re: [Intel-gfx] [PATCH 01/23] mm/shmem: introduce shmem_file_setup_with_mnt

Hi Andrew, This patch has been floating around for a while now Acked and without further comments. It is blocking us from merging huge page support to drm/i915. Would you mind merging it, or prodding the right people to get it in? Regards, Joonas On Mon, 2017-08-21 at 19:34 +0100, Matthew Auld

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/20] drm/i915: "Race-to-idle" on switching to the kernel context

== Series Details == Series: series starting with [01/20] drm/i915: "Race-to-idle" on switching to the kernel context URL : https://patchwork.freedesktop.org/series/29201/ State : failure == Summary == Series 29201v1 series starting with [01/20] drm/i915: "Race-to-idle" on switching to the k

[Intel-gfx] [PATCH v2 01/10] tests/perf: make stream_fd a global variable

When debugging unstable tests on new platforms we currently we don't cleanup everything well in between different tests. Since only a single OA stream fd can be opened at a time, having the stream_fd as a global variable helps us cleanup the state between tests. Signed-off-by: Lionel Landwerlin -

[Intel-gfx] [PATCH v2 02/10] tests/perf: add per context filtering test for gen8+

From: Robert Bragg v2: Remove the changes touching oa-exponent test (Matthew) Cleanup some comments bits (Matthew) Signed-off-by: Robert Bragg Signed-off-by: Lionel Landwerlin --- tests/perf.c | 777 --- 1 file changed, 745 insertion

[Intel-gfx] [PATCH v2 00/10] Improve robustness of the i915 perf tests

Hi all, Here is an updated patch series containing mostly cleanups. Cheers, Lionel Landwerlin (9): tests/perf: make stream_fd a global variable tests/perf: update max buffer size for reading reports tests/perf: rc6: try to guess when rc6 is disabled tests/perf: remove frequency related c

[Intel-gfx] [PATCH v2 05/10] tests/perf: remove frequency related changes

Experience shows that most of the issues we face with periodicity of the reports produced by the OA unit are related to power management, not frequency. Signed-off-by: Lionel Landwerlin --- tests/perf.c | 143 +-- 1 file changed, 10 inserti

[Intel-gfx] [PATCH v2 07/10] tests/perf: make enable-disable more reliable

Estimation of the amount of reports can only refer to periodic ones, as context switch reports completely depend on what happens on the system. Also generate some load to prevent clock frequency changes to impact our measurement. Signed-off-by: Lionel Landwerlin --- tests/perf.c | 96 +++

[Intel-gfx] [PATCH v2 04/10] tests/perf: rc6: try to guess when rc6 is disabled

Signed-off-by: Lionel Landwerlin --- tests/perf.c | 13 + 1 file changed, 13 insertions(+) diff --git a/tests/perf.c b/tests/perf.c index bc5ea133..1b441601 100644 --- a/tests/perf.c +++ b/tests/perf.c @@ -3445,6 +3445,17 @@ gen8_test_single_ctx_render_target_writes_a_counter(void)

[Intel-gfx] [PATCH v2 10/10] tests/perf: add Geminilake support

Signed-off-by: Lionel Landwerlin Reviewed-by: Matthew Auld --- tests/perf.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tests/perf.c b/tests/perf.c index 2f492679..1462a3fd 100644 --- a/tests/perf.c +++ b/tests/perf.c @@ -1124,6 +1124,9 @@ init_sys_info(void)

[Intel-gfx] [PATCH v2 09/10] tests/perf: add Kabylake support

Signed-off-by: Lionel Landwerlin Reviewed-by: Matthew Auld --- tests/perf.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/tests/perf.c b/tests/perf.c index 4a2cc38d..2f492679 100644 --- a/tests/perf.c +++ b/tests/perf.c @@ -,8 +,23 @@ init_sys_info

[Intel-gfx] [PATCH v2 08/10] tests/perf: make buffer-fill more reliable

Filling rate of the buffer must discard context switch reports as they do not depend upon the periodicity, instead they're a factor on the amount of different applications concurrently running on the system. Signed-off-by: Lionel Landwerlin Tested-by: Matthew Auld Reviewed-by: Matthew Auld ---

[Intel-gfx] [PATCH v2 03/10] tests/perf: update max buffer size for reading reports

Signed-off-by: Lionel Landwerlin --- tests/perf.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tests/perf.c b/tests/perf.c index 5058315c..bc5ea133 100644 --- a/tests/perf.c +++ b/tests/perf.c @@ -1280,9 +1280,7 @@ read_2_oa_reports(int format_id, /* Note: w

[Intel-gfx] [PATCH v2 06/10] tests/perf: rework oa-exponent test

New issues that were discovered while making the tests work on Gen8+ : - we need to measure timings between periodic reports and discard all other kind of reports - it seems periodicity of the reports can be affected outside of RC6 (frequency change), we can detect this by looking at the

Re: [Intel-gfx] [PATCH v14 1/7] drm/i915/gvt: Add framebuffer decoder support

On 2017.08.18 18:21:30 +0800, Tina Zhang wrote: > This patch is to introduce the framebuffer decoder which can decode guest > OS's framebuffer information, including primary, cursor and sprite plane. > > v14: > - refine pixel format table. (Zhenyu) > > v9: > - move drm format change to a separate

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Ignore duplicate VMA stored within the per-object handle LUT

On Tue, 2017-08-22 at 12:05 +0100, Chris Wilson wrote: > By using drm_gem_flink/drm_gem_open on an object using the same fd, it > is possible for a client to create multiple handles pointing to the same > object (tied to the same contexts and VMA), as exemplified by > igt::gem_handle_to_libdrm_bo()

[Intel-gfx] Merging iosf_mbi patches via the drm-tip tree

Hi Thomas et al, would it be ok to merge patch [1] - which contains changes in the iosf_mbi code - via the drm-tip tree? It's part of patchset [2] from Hans. Thanks, Imre [1] https://lists.freedesktop.org/archives/intel-gfx/2017-August/135991.html [2] https://lists.freedesktop.org/archives/intel

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Ignore duplicate VMA stored within the per-object handle LUT

Quoting Joonas Lahtinen (2017-08-23 11:05:18) > On Tue, 2017-08-22 at 12:05 +0100, Chris Wilson wrote: > > By using drm_gem_flink/drm_gem_open on an object using the same fd, it > > is possible for a client to create multiple handles pointing to the same > > object (tied to the same contexts and VM

Re: [Intel-gfx] [PATCH 1/2] drm: Add retries for dp dual mode read

On Tue, 22 Aug 2017, Shashank Sharma wrote: > From the CI builds, its been observed that during a driver > reload/insert, dp dual mode read function sometimes fails to > read from dual mode devices (like LSPCON) over i2c-over-aux > channel. > > This patch: > - adds some delay and few retries, allo

[Intel-gfx] [PATCH] drm/i915: Expose a wakeref debugfs to disable (i915) runtime pm

Some igt do nothing more active than peek at buffers through a gtt mmap. The pagefault into the GTT wakes the device up, but it will promptly autosuspend and zap the GTT mmap, forcing the cycle to repeat continuously. This makes those tests much, much slower than expected as every GTT access become

[Intel-gfx] [PATCH v2 1/2] drm: Add retries for dp dual mode read

From the CI builds, its been observed that during a driver reload/insert, dp dual mode read function sometimes fails to read from dual mode devices (like LSPCON) over i2c-over-aux channel. This patch: - adds some delay and few retries, allowing a scope for these devices to settle down and respon

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Expose a wakeref debugfs to disable (i915) runtime pm

== Series Details == Series: drm/i915: Expose a wakeref debugfs to disable (i915) runtime pm URL : https://patchwork.freedesktop.org/series/29207/ State : success == Summary == Series 29207v1 drm/i915: Expose a wakeref debugfs to disable (i915) runtime pm https://patchwork.freedesktop.org/api/

[Intel-gfx] [PATCH igt] igt/gem_fence_thresh: Use streaming reads for verify

At the moment, the verify tests use an extremely brutal write-read of every dword, degrading performance to UC. If we break those up into cachelines, we can do a wcb write/read at a time instead, roughly 8x faster. We lose the accuracy of the forced wcb flushes around every dword, but we are retain

[Intel-gfx] ✓ Fi.CI.BAT: success for Add retries for dp dual mode reads (rev2)

== Series Details == Series: Add retries for dp dual mode reads (rev2) URL : https://patchwork.freedesktop.org/series/29155/ State : success == Summary == Series 29155v2 Add retries for dp dual mode reads https://patchwork.freedesktop.org/api/1.0/series/29155/revisions/2/mbox/ Test kms_cursor

Re: [Intel-gfx] [PATCH] drm/doc: Document ioctl errno value patterns

On Fri, Aug 18, 2017 at 07:43:28PM +0200, Daniel Vetter wrote: > We're not super-consistent about these, but I think it's worth to > document at least the commmon patterns. > > v2: > - Add a not about ENOTTY (it's just a confusing name, but used > exactly what it's meant for in DRM) (Chris). > - U

[Intel-gfx] ✗ Fi.CI.BAT: failure for igt/gem_fence_thresh: Use streaming reads for verify

== Series Details == Series: igt/gem_fence_thresh: Use streaming reads for verify URL : https://patchwork.freedesktop.org/series/29208/ State : failure == Summary == IGT patchset tested on top of latest successful build 42b42c99cd9d1b890807ae97cbd1c593396ae051 tests/Makefile.am: Wrap audio tes

[Intel-gfx] [PATCH i-g-t] lib/core: Use igt_info instead of printf

igt_info doesn't add anything when printing to stdout, but so looks the same. But it has the upside of appending the lines also to the igt crashdump log, where I especially want the backtraces. Atm they're the only thing that doesn't end up in there, which is a bit confusing. While at it also conv

[Intel-gfx] ✓ Fi.CI.BAT: success for lib/core: Use igt_info instead of printf

== Series Details == Series: lib/core: Use igt_info instead of printf URL : https://patchwork.freedesktop.org/series/29210/ State : success == Summary == IGT patchset tested on top of latest successful build 42b42c99cd9d1b890807ae97cbd1c593396ae051 tests/Makefile.am: Wrap audio test with dedi

[Intel-gfx] [PATCH igt] igt/gem_fence_thrash, gem_mmap_gtt: Don't let the device sleep

These tests are not intended to exercise runtime pm, but the device going to sleep in the middle of these tests can significantly slow them down as the GTT mmapping is torn down and must be rebuilt. This can be a major nuisance if the device autosuspends many times a second. These tests differ fro

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Wire up shrinkctl->nr_scanned

Quoting Andrew Morton (2017-08-22 23:45:50) > On Tue, 22 Aug 2017 14:53:25 +0100 Chris Wilson > wrote: > > > shrink_slab() allows us to report back the number of objects we > > successfully scanned (out of the target shrinkctl->nr_to_scan). As > > report the number of pages owned by each GEM obj

Re: [Intel-gfx] [PATCH] drm/i915: "Race-to-idle" on switching to the kernel context

On Mon, Aug 21, 2017 at 12:48:03PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > Quoting Chris Wilson (2017-08-21 10:28:16) > >> Quoting Mika Kuoppala (2017-08-21 10:17:52) > >> > Chris Wilson writes: > >> > > >> > > During suspend we want to flush out all active contexts and their >

[Intel-gfx] ✓ Fi.CI.BAT: success for igt/gem_fence_thrash, gem_mmap_gtt: Don't let the device sleep

== Series Details == Series: igt/gem_fence_thrash, gem_mmap_gtt: Don't let the device sleep URL : https://patchwork.freedesktop.org/series/29215/ State : success == Summary == IGT patchset tested on top of latest successful build 42b42c99cd9d1b890807ae97cbd1c593396ae051 tests/Makefile.am: Wrap

[Intel-gfx] [PATCH igt] igt/kms_hdmi_inject: Require /proc/asound before asserting

The subtest "inject-audio" tries to load an EDID and confirm that it is being passed through to the audio driver (as an ELD). This cannot work if the audio driver is not present, so skip instead. References: https://bugs.freedesktop.org/show_bug.cgi?id=102370 Signed-off-by: Chris Wilson --- test

Re: [Intel-gfx] [PATCH] drm/i915: "Race-to-idle" on switching to the kernel context

On Fri, Aug 18, 2017 at 03:08:15PM +0100, Chris Wilson wrote: > During suspend we want to flush out all active contexts and their > rendering. To do so we queue a request from the kernel's context, once > we know that request is done, we know the GPU is completely idle. To > speed up that switch bu

Re: [Intel-gfx] [PATCH] drm/i915: "Race-to-idle" on switching to the kernel context

Quoting David Weinehall (2017-08-23 15:54:13) > On Fri, Aug 18, 2017 at 03:08:15PM +0100, Chris Wilson wrote: > > During suspend we want to flush out all active contexts and their > > rendering. To do so we queue a request from the kernel's context, once > > we know that request is done, we know th

Re: [Intel-gfx] [PATCH i-g-t] pm_rps: Extended testcases with checking PMINTRMSK register value

On Tue, Aug 22, 2017 at 01:14:19PM +, Szwichtenberg, Radoslaw wrote: > On Tue, 2017-08-22 at 13:33 +0100, Chris Wilson wrote: > > Quoting Szwichtenberg, Radoslaw (2017-08-22 12:56:00) > > > On Tue, 2017-08-22 at 01:31 +0300, Arkadiusz Hiler wrote: > > > > On Mon, Aug 21, 2017 at 09:39:24PM +020

[Intel-gfx] ✗ Fi.CI.BAT: failure for igt/kms_hdmi_inject: Require /proc/asound before asserting

== Series Details == Series: igt/kms_hdmi_inject: Require /proc/asound before asserting URL : https://patchwork.freedesktop.org/series/29217/ State : failure == Summary == IGT patchset tested on top of latest successful build 42b42c99cd9d1b890807ae97cbd1c593396ae051 tests/Makefile.am: Wrap aud

Re: [Intel-gfx] [PATCH igt] igt/gem_fence_thrash, gem_mmap_gtt: Don't let the device sleep

On Wed, Aug 23, 2017 at 03:13:55PM +0100, Chris Wilson wrote: > These tests are not intended to exercise runtime pm, but the device > going to sleep in the middle of these tests can significantly slow them > down as the GTT mmapping is torn down and must be rebuilt. This can be a > major nuisance i

Re: [Intel-gfx] [maintainer-tools PATCH 30/30] qf: Use .dimrc to config and extend qf.

On Tue, Aug 22, 2017 at 11:16:35AM -0700, Rodrigo Vivi wrote: > On Tue, Aug 22, 2017 at 12:33 AM, Jani Nikula wrote: > > On Mon, 21 Aug 2017, Rodrigo Vivi wrote: > >> Soon we will need to extend qf for very specific > >> usages of our internal maintenance and rebase bot. > >> > >> So instead of c

Re: [Intel-gfx] [PATCH igt] igt/gem_fence_thrash, gem_mmap_gtt: Don't let the device sleep

Quoting Daniel Vetter (2017-08-23 16:09:50) > On Wed, Aug 23, 2017 at 03:13:55PM +0100, Chris Wilson wrote: > > These tests are not intended to exercise runtime pm, but the device > > going to sleep in the middle of these tests can significantly slow them > > down as the GTT mmapping is torn down a

[Intel-gfx] [PATCH i-g-t 1/3] tests/chamelium: Introduce fast basic hpd tests, with limited toggles

This introduces a fast fashion of testing basic hotplug detect, with only 3 toggles. It drastically reduces the run time of the test, which is necessary for the fast-feedback test list. Signed-off-by: Paul Kocialkowski --- tests/chamelium.c | 12 1 file changed, 12 insertions(+) di

[Intel-gfx] [PATCH i-g-t 3/3] intel-ci: Add fast chamelium tests to the fast-feedback list

This adds the fastest chamelium tests to the Intel CI fast-feedback list, with the objective of running in under a minute. Signed-off-by: Paul Kocialkowski --- tests/intel-ci/fast-feedback.testlist | 9 + 1 file changed, 9 insertions(+) diff --git a/tests/intel-ci/fast-feedback.testlist

[Intel-gfx] [PATCH i-g-t 2/3] tests/chamelium: Introduce fast CRC tests, with a single mode

This introduces a fast fashion of testing display CRC, that only tests a single mode (the highest resolution). It drastically reduces the run time of the test, which is necessary for the fast-feedback test list. Signed-off-by: Paul Kocialkowski --- tests/chamelium.c | 22 --

[Intel-gfx] [PATCH 3/7] drm/i915: Eliminate obj->state usage in g4x/vlv/chv wm computation

From: Ville Syrjälä Use explicit old/new states instead of relying on obj->state. Reviewed-by: Maarten Lankhorst Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.h | 9 + drivers/gpu/drm/i915/intel_drv.h | 8 drivers/gpu/drm/i915/intel_pm.c | 30

[Intel-gfx] [PATCH 1/7] drm/i915: Pass the new crtc state to color management code

From: Ville Syrjälä In an effort to eliminate the obj->state usage let's pass on the new crtc state pointer (which we already have!) to the color management code. Reviewed-by: Maarten Lankhorst Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 4 ++-- 1 file changed, 2 i

[Intel-gfx] [PATCH 2/7] drm/i915: Pass the crtc state explicitly to intel_pipe_update_start/end()

From: Ville Syrjälä Pass the appropriate new crtc state explicitly to intel_pipe_update_start/end() instead of of mucking around with crtc->state. v2: The mmio flip stuff is gone Reviewed-by: Maarten Lankhorst #v1 Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 14 +++

[Intel-gfx] [PATCH 4/7] drm/i915: Pass proper old/new states to intel_plane_atomic_check_with_state()

From: Ville Syrjälä Eliminate plane->state and crtc->state usage from intel_plane_atomic_check_with_state() and its callers. Instead pass the proper states in or dig them up from the top level atomic state. Note that intel_plane_atomic_check_with_state() itself isn't allowed to use the top level

[Intel-gfx] [PATCH 6/7] drm/i915: Eliminate crtc->state usage from intel_update_pipe_config()

From: Ville Syrjälä Pass the correct new crtc state to intel_update_pipe_config() instead of using crtc->state. Reviewed-by: Maarten Lankhorst Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 19 +-- 1 file changed, 9 insertions(+), 10 deletions(-) diff

[Intel-gfx] [PATCH 7/7] drm/i915: Eliminate crtc->state usage from intel_atomic_commit_tail and .crtc_update()

From: Ville Syrjälä We already have the correct new crtc state so just use that instead of crtc->state. Reviewed-by: Maarten Lankhorst Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/dr

[Intel-gfx] [PATCH 5/7] drm/i915: Eliminate obj->state usage from pre/post plane update

From: Ville Syrjälä Dig up the appropriate new crtc and plane states from the top level atomic state in intel_pre_plane_update() and intel_post_plane_update(). Reviewed-by: Maarten Lankhorst Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 9 ++--- 1 file changed, 6

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] tests/chamelium: Introduce fast basic hpd tests, with limited toggles

== Series Details == Series: series starting with [1/3] tests/chamelium: Introduce fast basic hpd tests, with limited toggles URL : https://patchwork.freedesktop.org/series/29218/ State : success == Summary == IGT patchset tested on top of latest successful build 42b42c99cd9d1b890807ae97cbd1c

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/7] drm/i915: Pass the new crtc state to color management code

== Series Details == Series: series starting with [1/7] drm/i915: Pass the new crtc state to color management code URL : https://patchwork.freedesktop.org/series/29219/ State : success == Summary == Series 29219v1 series starting with [1/7] drm/i915: Pass the new crtc state to color manageme

[Intel-gfx] [PATCH v3 00/12] Improve robustness of the i915 perf tests

Hi all, Finally figured the final issue with the flakyness of the tests on Broadwell (patch 12). Some fallout of that generated patch 11. Cheers, Lionel Landwerlin (11): tests/perf: make stream_fd a global variable tests/perf: update max buffer size for reading reports tests/perf: rc6: try

[Intel-gfx] [PATCH v3 03/12] tests/perf: update max buffer size for reading reports

Signed-off-by: Lionel Landwerlin --- tests/perf.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tests/perf.c b/tests/perf.c index 5058315c..bc5ea133 100644 --- a/tests/perf.c +++ b/tests/perf.c @@ -1280,9 +1280,7 @@ read_2_oa_reports(int format_id, /* Note: w

[Intel-gfx] [PATCH v3 04/12] tests/perf: rc6: try to guess when rc6 is disabled

Signed-off-by: Lionel Landwerlin --- tests/perf.c | 13 + 1 file changed, 13 insertions(+) diff --git a/tests/perf.c b/tests/perf.c index bc5ea133..1b441601 100644 --- a/tests/perf.c +++ b/tests/perf.c @@ -3445,6 +3445,17 @@ gen8_test_single_ctx_render_target_writes_a_counter(void)

[Intel-gfx] [PATCH v3 01/12] tests/perf: make stream_fd a global variable

When debugging unstable tests on new platforms we currently we don't cleanup everything well in between different tests. Since only a single OA stream fd can be opened at a time, having the stream_fd as a global variable helps us cleanup the state between tests. Signed-off-by: Lionel Landwerlin -

[Intel-gfx] [PATCH v3 02/12] tests/perf: add per context filtering test for gen8+

From: Robert Bragg Signed-off-by: Robert Bragg Signed-off-by: Lionel Landwerlin --- tests/perf.c | 777 --- 1 file changed, 745 insertions(+), 32 deletions(-) diff --git a/tests/perf.c b/tests/perf.c index ca5bfdc5..5058315c 100644 --- a

[Intel-gfx] [PATCH v3 07/12] tests/perf: make enable-disable more reliable

Estimation of the amount of reports can only refer to periodic ones, as context switch reports completely depend on what happens on the system. Also generate some load to prevent clock frequency changes to impact our measurement. Signed-off-by: Lionel Landwerlin --- tests/perf.c | 96 +++

[Intel-gfx] [PATCH v3 05/12] tests/perf: remove frequency related changes

Experience shows that most of the issues we face with periodicity of the reports produced by the OA unit are related to power management, not frequency. Signed-off-by: Lionel Landwerlin --- tests/perf.c | 141 --- 1 file changed, 9 insertio

[Intel-gfx] [PATCH v3 10/12] tests/perf: add Geminilake support

Signed-off-by: Lionel Landwerlin Reviewed-by: Matthew Auld --- tests/perf.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tests/perf.c b/tests/perf.c index b7d9f96d..9f12da40 100644 --- a/tests/perf.c +++ b/tests/perf.c @@ -1124,6 +1124,9 @@ init_sys_info(void)

[Intel-gfx] [PATCH v3 08/12] tests/perf: make buffer-fill more reliable

Filling rate of the buffer must discard context switch reports as they do not depend upon the periodicity, instead they're a factor on the amount of different applications concurrently running on the system. Signed-off-by: Lionel Landwerlin Tested-by: Matthew Auld Reviewed-by: Matthew Auld ---

[Intel-gfx] [PATCH v3 11/12] tests/perf: estimate number of blocking/polling based on time spent

Blocking & polling tests define an amount of time to spend in the test and then estimate the number of syscalls that should successfully return. The problem is that while running the test we might spend slightly more time than initiallly planned. This change estimates the number of syscalls based o

[Intel-gfx] [PATCH v3 09/12] tests/perf: add Kabylake support

Signed-off-by: Lionel Landwerlin Reviewed-by: Matthew Auld --- tests/perf.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/tests/perf.c b/tests/perf.c index 59cd50aa..b7d9f96d 100644 --- a/tests/perf.c +++ b/tests/perf.c @@ -,8 +,23 @@ init_sys_info

[Intel-gfx] [PATCH v3 06/12] tests/perf: rework oa-exponent test

New issues that were discovered while making the tests work on Gen8+ : - we need to measure timings between periodic reports and discard all other kind of reports - it seems periodicity of the reports can be affected outside of RC6 (frequency change), we can detect this by looking at the

[Intel-gfx] [PATCH v3 12/12] tests/perf: prevent power management to kick in when necessary

Some of our tests measure that the OA unit produces reports at expected time intervals (as configured through the PERF_OPEN ioctl). It turns out the power management plays a role in the decision of the OA unit to write reports to memory. Under normal circumstances we don't really mind if the unit m

[Intel-gfx] [PATCH igt v2] igt/pm_rpm: Use libc 'ftw' rather than opencoding our own filetree walk

By using ftw, we avoid the issue of having to handle directory recursion ourselves and can focus on the test of checking the reading a sysfs/debugfs does not break runtime suspend. In the process, disregard errors when opening the individual files as they may fail for other reasons. v2: Bracket th

[Intel-gfx] ✓ Fi.CI.BAT: success for igt/pm_rpm: Use libc 'ftw' rather than opencoding our own filetree walk (rev2)

== Series Details == Series: igt/pm_rpm: Use libc 'ftw' rather than opencoding our own filetree walk (rev2) URL : https://patchwork.freedesktop.org/series/29141/ State : success == Summary == IGT patchset tested on top of latest successful build 42b42c99cd9d1b890807ae97cbd1c593396ae051 tests/

  1   2   >