[Intel-gfx] [PATCH 2/2] drm/i915/guc: Remove obsolete comments and remove unused variable

Originally removed in: c1adab970348 ("drm/i915/guc: Remove failed doorbell stat from debugfs") f1448a62a103 ("drm/i915/guc: Remove last submission result from debugfs") Were accidentaly restored in: 925344ccc91d ("BackMerge tag 'v4.12-rc5' into drm-next") We can also remove unused variable and

[Intel-gfx] [PATCH 1/2] drm/i915/tracepoints: Don't compile-out low-level tracepoints

There's no reason to hide those tracepoints. Let's also remove the DRM_I915_LOW_LEVEL_TRACEPOINTS Kconfig option. Cc: Chris Wilson Cc: John Harrison Cc: Tvrtko Ursulin Signed-off-by: Michał Winiarski

Re: [Intel-gfx] [PATCH] drm/i915: Enable scanline read for gen9 dsi

>-Original Message- >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] >Sent: Friday, September 8, 2017 8:18 PM >To: Srinivas, Vidya >Cc: intel-gfx@lists.freedesktop.org; Kahola, Mika ; >Kamath, Sunil ;

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v4,1/2] drm/i915: Introduce INTEL_GEN_MASK

== Series Details == Series: series starting with [v4,1/2] drm/i915: Introduce INTEL_GEN_MASK URL : https://patchwork.freedesktop.org/series/30112/ State : success == Summary == Test kms_flip: Subgroup plain-flip-fb-recreate: pass -> FAIL (shard-hsw)

[Intel-gfx] [PATCH igt] igt/sw_sync: Fix up close(timeline) tests for unsignaled fences

Following kernel commit ea4d5a270b57fa8d4871f372ca9b97b7697fdfda Author: Dominik Behr Date: Thu Sep 7 16:02:46 2017 -0300 dma-buf/sw_sync: force signal all unsignaled fences on dying timeline To avoid hanging userspace components that might have been waiting on

[Intel-gfx] [PATCH v6 1/2] drm/i915: Introduce INTEL_GEN_MASK

Split INTEL_GEN_MASK out of IS_GEN macro, and make it usable within static declarations (unlike combound statements). Signed-off-by: Joonas Lahtinen Cc: Jani Nikula Cc: Chris Wilson Reviewed-by: Jani Nikula

[Intel-gfx] [PATCH v6 2/2] drm/i915: Simplify i915_reg_read_ioctl

Convert to use the freshly available made INTEL_GEN_MASK for easier grepping and improve function readability and clarify the UABI documentation. No functional changes. v2: - Lift GEM_BUG_ONs and use is_power_of_2 (Chris) - Retain -EINVAL on bad flags behavior (Chris) v3: - Extract flags with

[Intel-gfx] [PATCH 0/3] drm/i915: Skylake plane update/disable unifications [v3]

[v3] Took into account fbc adjusted y/x for primary plane (ville syrjälä) [v2] Fixed missed references which were brough on rebase. /Juha-Pekka Juha-Pekka Heikkila (3): drm/i915: dspaddr_offset doesn't need to be more than local variable drm/i915: Unify skylake plane update drm/i915:

[Intel-gfx] [PATCH 3/3] drm/i915: Unify skylake plane disable

Don't handle skylake primary plane separately as it is similar plane as the others. Signed-off-by: Juha-Pekka Heikkila --- drivers/gpu/drm/i915/intel_display.c | 21 ++--- drivers/gpu/drm/i915/intel_drv.h | 1 +

[Intel-gfx] [PATCH 2/3] drm/i915: Unify skylake plane update

Don't handle skylake primary plane separately as it is similar plane as the others. Signed-off-by: Juha-Pekka Heikkila --- drivers/gpu/drm/i915/i915_drv.h | 8 drivers/gpu/drm/i915/intel_display.c | 85 +---

[Intel-gfx] [PATCH 1/3] drm/i915: dspaddr_offset doesn't need to be more than local variable

Move u32 dspaddr_offset from struct intel_crtc member into local variable in i9xx_update_primary_plane() Signed-off-by: Juha-Pekka Heikkila --- drivers/gpu/drm/i915/intel_display.c | 11 ++- drivers/gpu/drm/i915/intel_drv.h | 1 - 2 files changed, 6

Re: [Intel-gfx] [PATCH] drm/i915: Enable scanline read for gen9 dsi

On Mon, Sep 11, 2017 at 10:52:27AM +0200, Maarten Lankhorst wrote: > Op 08-09-17 om 21:55 schreef Chris Wilson: > > Quoting Daniel Vetter (2017-09-08 20:45:11) > >> On Fri, Sep 08, 2017 at 05:55:24PM +0300, Ville Syrjälä wrote: > >>> Another thought that just occurred to me: Maybe we could use

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Simplify i915_reg_read_ioctl

On Mon, Sep 11, 2017 at 01:49:18PM +0300, Joonas Lahtinen wrote: > On Fri, 2017-09-08 at 15:24 +0300, Ville Syrjälä wrote: > > On Fri, Sep 08, 2017 at 12:29:35PM +0300, Joonas Lahtinen wrote: > > > @@ -1292,72 +1292,71 @@ void intel_uncore_fini(struct drm_i915_private > > > *dev_priv) > > >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Increase poll time for BDW FCLK_DONE (rev2)

== Series Details == Series: drm/i915: Increase poll time for BDW FCLK_DONE (rev2) URL : https://patchwork.freedesktop.org/series/30006/ State : success == Summary == Series 30006v2 drm/i915: Increase poll time for BDW FCLK_DONE

Re: [Intel-gfx] [PATCH igt 1/5] igt/gem_eio: inflight wedged requires long plugging

Quoting Michał Winiarski (2017-09-11 13:03:28) > On Mon, Sep 11, 2017 at 09:55:58AM +0100, Chris Wilson wrote: > > - igt_post_hang_ring(fd, hang); > > - unplug(); /* only now submit our batches */ > > - igt_assert_eq(__gem_wait(fd, obj[1].handle, -1), 0); > > + fence =

Re: [Intel-gfx] [PATCH] drm/i915: Fix an error handling in 'intel_framebuffer_init()'

On Sun, 10 Sep 2017, Christophe JAILLET wrote: > We should go through the error handling path to decrease the > 'framebuffer_references' as done everywhere else in this function. > > Fixes: 2e2adb05736c ("drm/i915: Add render decompression support") > Signed-off-by:

Re: [Intel-gfx] [PATCH i-g-t 1/3] meson: Simple makefile integration

On Fri, Sep 08, 2017 at 05:14:46PM +0200, Daniel Vetter wrote: > Run ./meson.sh once, then you have > > $ make > > and > > $ make test > > available in the normal src root. > > v2: > > Add > > $ make reconfigure > > which is the meson equivalent to rerunning ./configure. Also takes > some

Re: [Intel-gfx] [PATCH igt 1/5] igt/gem_eio: inflight wedged requires long plugging

On Mon, Sep 11, 2017 at 09:55:58AM +0100, Chris Wilson wrote: > As our hangcheck may exceed 10s to declare the device wedged, we need to > hold the plugging fence indefinitely. This makes using vgem as our input > fence unusable, so resort to using sw_sync. At the same time, we can > then check

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/5] igt/gem_eio: inflight wedged requires long plugging

== Series Details == Series: series starting with [1/5] igt/gem_eio: inflight wedged requires long plugging URL : https://patchwork.freedesktop.org/series/30109/ State : success == Summary == Test perf: Subgroup blocking: pass -> FAIL (shard-hsw)

Re: [Intel-gfx] [PATCH 01/11] drm/i915: Mark the userptr invalidate workqueue as WQ_MEM_RECLAIM

On Mon, Sep 11, 2017 at 09:41:25AM +0100, Chris Wilson wrote: > To silence the critcs: > > [56532.161115] workqueue: PF_MEMALLOC task 36(khugepaged) is flushing > !WQ_MEM_RECLAIM i915-userptr-release: (null) > [56532.161138] [ cut here ] > [56532.161144] WARNING:

Re: [Intel-gfx] [PATCH igt 1/5] igt/gem_eio: inflight wedged requires long plugging

Quoting Martin Peres (2017-09-11 12:06:55) > On 11/09/17 13:57, Petri Latvala wrote: > > gem_eio@in-flight is currently filtered in cibuglog. Martin, are you > > prepared for this subtest rename? > > > > Yes, thanks for the heads up! We wanted to run the others bug not inflight, once the new

Re: [Intel-gfx] [PATCH igt 1/5] igt/gem_eio: inflight wedged requires long plugging

On 11/09/17 13:57, Petri Latvala wrote: gem_eio@in-flight is currently filtered in cibuglog. Martin, are you prepared for this subtest rename? Yes, thanks for the heads up! - Intel Finland Oy Registered Address: PL 281, 00181

[Intel-gfx] [CI 3/3] igt/gem_eio: Install an exithandler to unwedge the device after failure

Under normal conditions, we try to repair the damage we inflict to the GPU, but if we fail we don't. Make sure that if the test does die, we do try to restore normal operation by using an atexit handler. Signed-off-by: Chris Wilson Reviewed-by: Arkadiusz Hiler

[Intel-gfx] [CI 2/3] igt/gem_flink_race: Limit name subtest to 5s

At present, we try to do 1,000,000 cycles, which may be a reasonable estimate for detecting the race, takes 6 minutes in practice on bxt on a good day (as it spends more time doing rpm suspend/resume than actual work, and that accounts for more of the relative difference in performance between bxt

[Intel-gfx] [CI 1/3] igt/tools_test: Remove dmesg subtest

It's a silly test. If fails if there is an *ERROR* in the dmesg ringbuf, so it neither is testing that errors are generated as expected, and as a pre-check it can only see what's at the end of the dmesg and may miss earlier faults. As a test it just randomly fails; worse than useless.

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Increase poll time for BDW FCLK_DONE (rev2)

== Series Details == Series: drm/i915: Increase poll time for BDW FCLK_DONE (rev2) URL : https://patchwork.freedesktop.org/series/30006/ State : failure == Summary == Test kms_setmode: Subgroup basic: pass -> FAIL (shard-hsw) fdo#99912 Test gem_flink_race:

Re: [Intel-gfx] [PATCH igt 1/5] igt/gem_eio: inflight wedged requires long plugging

On Mon, Sep 11, 2017 at 09:55:58AM +0100, Chris Wilson wrote: > As our hangcheck may exceed 10s to declare the device wedged, we need to > hold the plugging fence indefinitely. This makes using vgem as our input > fence unusable, so resort to using sw_sync. At the same time, we can > then check

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Simplify i915_reg_read_ioctl

On Fri, 2017-09-08 at 15:24 +0300, Ville Syrjälä wrote: > On Fri, Sep 08, 2017 at 12:29:35PM +0300, Joonas Lahtinen wrote: > > @@ -1292,72 +1292,71 @@ void intel_uncore_fini(struct drm_i915_private > > *dev_priv) > > intel_uncore_forcewake_reset(dev_priv, false); > > } > > > > -#define

Re: [Intel-gfx] [PATCH v5 2/2] drm/i915: Simplify i915_reg_read_ioctl

Quoting Joonas Lahtinen (2017-09-11 10:59:01) > Convert to use the freshly available made INTEL_GEN_MASK for easier > grepping and improve function readability and clarify the UABI > documentation. > > No functional changes. > > v2: > - Lift GEM_BUG_ONs and use is_power_of_2 (Chris) > - Retain

Re: [Intel-gfx] [PATCH igt 3/5] igt/gem_eio: Install an exithandler to unwedge the device after failure

On Mon, Sep 11, 2017 at 09:56:00AM +0100, Chris Wilson wrote: > Under normal conditions, we try to repair the damage we inflict to the > GPU, but if we fail we don't. Make sure that if the test does die, we do > try to restore normal operation by using an atexit handler. > > Signed-off-by: Chris

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v5,1/2] drm/i915: Introduce INTEL_GEN_MASK

== Series Details == Series: series starting with [v5,1/2] drm/i915: Introduce INTEL_GEN_MASK URL : https://patchwork.freedesktop.org/series/30113/ State : success == Summary == Series 30113v1 series starting with [v5,1/2] drm/i915: Introduce INTEL_GEN_MASK

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v14,1/5] drm/i915: Factor out setup_private_pat()

== Series Details == Series: series starting with [v14,1/5] drm/i915: Factor out setup_private_pat() URL : https://patchwork.freedesktop.org/series/30107/ State : failure == Summary == Test kms_fbc_crc: Subgroup page_flip_and_mmap_gtt: pass -> SKIP

Re: [Intel-gfx] [PATCH igt 5/5] igt/gem_flink_race: Limit name subtest to 5s

On Mon, 2017-09-11 at 09:56 +0100, Chris Wilson wrote: > At present, we try to do 1,000,000 cycles, which may be a reasonable > estimate for detecting the race, takes 6 minutes in practice on bxt on a > good day (as it spends more time doing rpm suspend/resume than actual work, > and that accounts

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/2] drm/i915: Introduce INTEL_GEN_MASK

== Series Details == Series: series starting with [v4,1/2] drm/i915: Introduce INTEL_GEN_MASK URL : https://patchwork.freedesktop.org/series/30112/ State : success == Summary == Series 30112v1 series starting with [v4,1/2] drm/i915: Introduce INTEL_GEN_MASK

Re: [Intel-gfx] [PATCH i-g-t] tests/tools_test: Make sure l3_parity is supported

On Thu, Sep 07, 2017 at 09:49:42AM +0300, Abdiel Janulgue wrote: > Check support before executing test. > v2: Skip test only if intel_l3_parity tool tells us to skip. (Petri) > > bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101650 > Cc: Petri Latvala >

Re: [Intel-gfx] [PATCH igt 5/5] igt/gem_flink_race: Limit name subtest to 5s

On Mon, Sep 11, 2017 at 09:56:02AM +0100, Chris Wilson wrote: > At present, we try to do 1,000,000 cycles, which may be a reasonable > estimate for detecting the race, takes 6 minutes in practice on bxt on a > good day (as it spends more time doing rpm suspend/resume than actual work, > and that

[Intel-gfx] [PATCH v5 2/2] drm/i915: Simplify i915_reg_read_ioctl

Convert to use the freshly available made INTEL_GEN_MASK for easier grepping and improve function readability and clarify the UABI documentation. No functional changes. v2: - Lift GEM_BUG_ONs and use is_power_of_2 (Chris) - Retain -EINVAL on bad flags behavior (Chris) v3: - Extract flags with

[Intel-gfx] [PATCH v5 1/2] drm/i915: Introduce INTEL_GEN_MASK

Split INTEL_GEN_MASK out of IS_GEN macro, and make it usable within static declarations (unlike combound statements). Signed-off-by: Joonas Lahtinen Cc: Jani Nikula Cc: Chris Wilson Reviewed-by: Jani Nikula

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] igt/gem_eio: inflight wedged requires long plugging

== Series Details == Series: series starting with [1/5] igt/gem_eio: inflight wedged requires long plugging URL : https://patchwork.freedesktop.org/series/30109/ State : success == Summary == IGT patchset tested on top of latest successful build 866970a57a9def534f4b4671b59670fb70f54141

[Intel-gfx] [PATCH v4 1/2] drm/i915: Introduce INTEL_GEN_MASK

Split INTEL_GEN_MASK out of IS_GEN macro, and make it usable within static declarations (unlike combound statements). Signed-off-by: Joonas Lahtinen Cc: Jani Nikula Cc: Chris Wilson Reviewed-by: Jani Nikula

[Intel-gfx] [PATCH v4 2/2] drm/i915: Simplify i915_reg_read_ioctl

Convert to use the freshly available made INTEL_GEN_MASK for easier grepping and improve function readability and clarify the UABI documentation. No functional changes. v2: - Lift GEM_BUG_ONs and use is_power_of_2 (Chris) - Retain -EINVAL on bad flags behavior (Chris) v3: - Extract flags with

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Increase poll time for BDW FCLK_DONE (rev2)

== Series Details == Series: drm/i915: Increase poll time for BDW FCLK_DONE (rev2) URL : https://patchwork.freedesktop.org/series/30006/ State : success == Summary == Series 30006v2 drm/i915: Increase poll time for BDW FCLK_DONE

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915: Simplify i915_reg_read_ioctl

Quoting Chris Wilson (2017-09-11 10:18:51) > Quoting Joonas Lahtinen (2017-09-11 08:57:19) > > + entry = reg_read_whitelist; > > + remain = ARRAY_SIZE(reg_read_whitelist); > > + while (remain) { > > + GEM_BUG_ON(!is_power_of_2(entry->size)); > > +

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v3,1/2] drm/i915: Introduce INTEL_GEN_MASK

== Series Details == Series: series starting with [v3,1/2] drm/i915: Introduce INTEL_GEN_MASK URL : https://patchwork.freedesktop.org/series/30103/ State : success == Summary == Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 Test

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915: Simplify i915_reg_read_ioctl

Quoting Joonas Lahtinen (2017-09-11 08:57:19) > Convert to use the freshly available made INTEL_GEN_MASK for easier > grepping and improve function readability and clarify the UABI > documentation. > > No functional changes. > > v2: > - Lift GEM_BUG_ONs and use is_power_of_2 (Chris) > - Retain

Re: [Intel-gfx] [PATCH v13 4/5] drm/i915: Do not allocate unused PPAT entries

On Mon, 2017-09-11 at 12:26 +0800, Zhi Wang wrote: > Only PPAT entries 0/2/3/4 are using. Remove extra PPAT entry allocation > during initialization. > > v8: > > - Move ppat_index() into i915_gem_gtt.c. (Chris) > - Change the name of ppat_bits_to_index to ppat_index. > > Cc: Ben Widawsky

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [01/11] drm/i915: Mark the userptr invalidate workqueue as WQ_MEM_RECLAIM

== Series Details == Series: series starting with [01/11] drm/i915: Mark the userptr invalidate workqueue as WQ_MEM_RECLAIM URL : https://patchwork.freedesktop.org/series/30108/ State : warning == Summary == Series 30108v1 series starting with [01/11] drm/i915: Mark the userptr invalidate

Re: [Intel-gfx] [PATCH v13 2/5] drm/i915: Introduce private PAT management

On Mon, 2017-09-11 at 12:26 +0800, Zhi Wang wrote: > 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_put. > > intel_ppat_get will search for an existing PPAT entry which perfectly >

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v14,1/5] drm/i915: Factor out setup_private_pat()

== Series Details == Series: series starting with [v14,1/5] drm/i915: Factor out setup_private_pat() URL : https://patchwork.freedesktop.org/series/30107/ State : success == Summary == Series 30107v1 series starting with [v14,1/5] drm/i915: Factor out setup_private_pat()

[Intel-gfx] [PATCH igt 2/5] igt/gem_eio: Exercise wedged with native in-flight requests

If we wedged one engine with unready requests to a second engine (blocked by waiting on requests from the first, using a dma-fence), check that we propagate the -EIO to those in-flight requests. Signed-off-by: Chris Wilson --- tests/gem_eio.c | 89

[Intel-gfx] [PATCH igt 1/5] igt/gem_eio: inflight wedged requires long plugging

As our hangcheck may exceed 10s to declare the device wedged, we need to hold the plugging fence indefinitely. This makes using vgem as our input fence unusable, so resort to using sw_sync. At the same time, we can then check that the async result is also -EIO. Bugzilla:

[Intel-gfx] [PATCH igt 4/5] 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

[Intel-gfx] CI urgent

Just a few fixes for unhappy tests being run by CI. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt 5/5] igt/gem_flink_race: Limit name subtest to 5s

At present, we try to do 1,000,000 cycles, which may be a reasonable estimate for detecting the race, takes 6 minutes in practice on bxt on a good day (as it spends more time doing rpm suspend/resume than actual work, and that accounts for more of the relative difference in performance between bxt

[Intel-gfx] [PATCH igt 3/5] igt/gem_eio: Install an exithandler to unwedge the device after failure

Under normal conditions, we try to repair the damage we inflict to the GPU, but if we fail we don't. Make sure that if the test does die, we do try to restore normal operation by using an atexit handler. Signed-off-by: Chris Wilson --- tests/gem_eio.c | 18

Re: [Intel-gfx] [PATCH] drm/i915: Enable scanline read for gen9 dsi

Op 08-09-17 om 21:55 schreef Chris Wilson: > Quoting Daniel Vetter (2017-09-08 20:45:11) >> On Fri, Sep 08, 2017 at 05:55:24PM +0300, Ville Syrjälä wrote: >>> Another thought that just occurred to me: Maybe we could use these >>> timestamps as a workaround for the DDI "scanline reads as 0 at the

Re: [Intel-gfx] [maintainer-tools PATCH 3/5] dim: remove defaults from pull mail hello/signature

On Sat, 09 Sep 2017, "Vivi, Rodrigo" wrote: > On Fri, 2017-09-08 at 16:29 +0300, Jani Nikula wrote: >> Historical baggage from the times this was just Daniel's maintainer >> script. >> >> Cc: Daniel Vetter >> Signed-off-by: Jani Nikula

Re: [Intel-gfx] [maintainer-tools PATCH 5/5] dim: update pull and test request recipients

On Fri, 08 Sep 2017, Sean Paul wrote: > On Fri, Sep 8, 2017 at 9:30 AM, Jani Nikula wrote: >> Make it easier to add/remove people as needed. Add Joonas, Rodrigo and >> Sean as new recipients for pull requests. Replace Daniel with Joonas and >>

[Intel-gfx] [PATCH 06/11] drm/i915: Pin fence for iomap

Acquire the fence register for the iomap in i915_vma_pin_iomap() on behalf of the caller. We probably want for the caller to specify whether the fence should be pinned for their usage, but at the moment all callers do want the associated fence, or none, so take it on their behalf. Signed-off-by:

[Intel-gfx] [PATCH 07/11] drm/i915: Consolidate get_fence with pin_fence

Following the pattern now used for obj->mm.pages, use just pin_fence and unpin_fence to control access to the fence registers. I.e. instead of calling get_fence(); pin_fence(), we now just need to call pin_fence(). This will make it easier to reduce the locking requirements around fence registers.

[Intel-gfx] [PATCH 08/11] drm/i915: Emit pipelined fence changes

Many years ago, long before requests, we tried doing this. We never quite got it right, but now with requests we have the tracking to do the job properly! One of the stall points for gen2/gen3 is the use of fence registers for GPU operations. There are only a few available, and currently if we

[Intel-gfx] [PATCH 10/11] drm/i915: Check PIN_NONFAULT overlaps in evict_for_node

If the caller says that he doesn't want to evict any other faulting vma, honour that flag. The logic was used in evict_something, but not the more specific evict_for_node, now being used as a preliminary probe since commit 606fec956c0e ("drm/i915: Prefer random replacement before eviction

[Intel-gfx] [PATCH 04/11] drm/i915: Try harder to finish the idle-worker

If a worker requeues itself, it may switch to a different kworker pool, which flush_work() considers as complete. To be strict, we then need to keep flushing the work until it is no longer pending. References: https://bugs.freedesktop.org/show_bug.cgi?id=102456 Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 11/11] drm/i915: Try a minimal attempt to insert the whole object for relocations

As we have a lightweight fallback to insert a single page into the aperture, try to avoid any heavier evictions when attempting to insert the entire object. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +++- 1 file changed, 3

[Intel-gfx] [PATCH 05/11] drm/i915: Keep the device awake whilst in the GTT domain

Since runtime suspend is very harsh on GTT mmappings (they all get zapped on suspend) keep the device awake while the buffer remains in the GTT domain. However, userspace can control the domain and although there is a soft contract that writes must be flushed (for e.g. flushing scanouts and fbc),

[Intel-gfx] [PATCH 09/11] drm/i915: Track user GTT faulting per-vma

We don't wish to refault the entire object (other vma) when unbinding one partial vma. To do this track which vma have been faulted into the user's address space. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 2 +-

[Intel-gfx] [PATCH 02/11] drm/i915/fence: Avoid del_timer_sync() from inside a timer

A fence may be signaled from any context, including from inside a timer. One example is timer_i915_sw_fence_wake() which is used to provide a safety-net when waiting on an external fence. If the external fence is not signaled within a timely fashion, we signal our fence on its behalf, and so we

[Intel-gfx] [PATCH 01/11] drm/i915: Mark the userptr invalidate workqueue as WQ_MEM_RECLAIM

To silence the critcs: [56532.161115] workqueue: PF_MEMALLOC task 36(khugepaged) is flushing !WQ_MEM_RECLAIM i915-userptr-release: (null) [56532.161138] [ cut here ] [56532.161144] WARNING: CPU: 1 PID: 36 at kernel/workqueue.c:2418

[Intel-gfx] [PATCH 03/11] drm/i915: Include fence-hint for timeout warning

If an asynchronous wait on a foriegn fence, we print a warning indicating which fence was not signaled. As i915_sw_fences become more common, include the debug hint (the symbol-name of the target) to help identify the waiter. E.g. [ 31.968144] Asynchronous wait on fence sw_sync:gem_eio:1 timed

[Intel-gfx] Fixes for CI/bxt

A collection of fixes targetting the timeouts (INCOMPLETES) and failures on CI/bxt. You've seen most of these patches before... -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v14 5/5] drm/i915/selftests: Introduce live tests of private PAT management

Introduce two live tests of private PAT management: igt_ppat_init - This test is to check if all the PPAT configurations are written into HW. igt_ppat_get - This test performs several sub-tests on intel_ppat_get() and intel_ppat_put(). The "perfect match" test case will try to get a PPAT entry

[Intel-gfx] [PATCH v14 4/5] drm/i915: Do not allocate unused PPAT entries

Only PPAT entries 0/2/3/4 are using. Remove extra PPAT entry allocation during initialization. v8: - Move ppat_index() into i915_gem_gtt.c. (Chris) - Change the name of ppat_bits_to_index to ppat_index. Suggested-by: Joonas Lahtinen Signed-off-by: Zhi Wang

[Intel-gfx] [PATCH v14 1/5] drm/i915: Factor out setup_private_pat()

Factor out setup_private_pat() for introducing the following patches. Signed-off-by: Zhi Wang Cc: Ben Widawsky Cc: Rodrigo Vivi Cc: Chris Wilson Cc: Joonas Lahtinen

[Intel-gfx] [PATCH v14 2/5] 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_put. intel_ppat_get will search for an existing PPAT entry which perfectly matches the required PPAT value. If not, it will try to

[Intel-gfx] [PATCH v14 3/5] drm/i915: Remove the "INDEX" suffix from PPAT marcos

Remove the "INDEX" suffix from PPAT marcos as they are bits actually, not indexes. Suggested-by: Chris Wilson Signed-off-by: Zhi Wang Cc: Ben Widawsky Cc: Rodrigo Vivi Cc: Joonas Lahtinen

Re: [Intel-gfx] [PATCH v10 1/5] drm/i915: Factor out setup_private_pat()

Thanks! :) I'm going to refresh them again. -Original Message- From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] Sent: Monday, September 11, 2017 11:28 AM To: Wang, Zhi A ; intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org Cc:

Re: [Intel-gfx] [PATCH v10 1/5] drm/i915: Factor out setup_private_pat()

On Sat, 2017-09-09 at 16:53 +0800, Zhi Wang wrote: > Factor out setup_private_pat() for introducing the following patches. > > Reviewed-by: Ben Widawsky > Reviewed-by: Chris Wilson > Cc: Ben Widawsky > Cc:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/2] drm/i915: Introduce INTEL_GEN_MASK

== Series Details == Series: series starting with [v3,1/2] drm/i915: Introduce INTEL_GEN_MASK URL : https://patchwork.freedesktop.org/series/30103/ State : success == Summary == Series 30103v1 series starting with [v3,1/2] drm/i915: Introduce INTEL_GEN_MASK

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/doc: Update todo.rst

== Series Details == Series: drm/doc: Update todo.rst URL : https://patchwork.freedesktop.org/series/30098/ State : success == Summary == Test perf: Subgroup polling: pass -> FAIL (shard-hsw) fdo#102252 fdo#102252

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Simplify i915_reg_read_ioctl

On Fri, 2017-09-08 at 15:16 +0100, Chris Wilson wrote: > Quoting Joonas Lahtinen (2017-09-08 12:49:06) > > Convert to use the freshly available made INTEL_GEN_MASK for easier > > grepping and improve function readability and clarify the UABI > > documentation. > > > > No functional changes. > >

[Intel-gfx] [PATCH 2/3] drm/i915: Introduce INTEL_GEN_MASK

Split INTEL_GEN_MASK out of IS_GEN macro, and make it usable within static declarations (unlike combound statements). Cc: Jani Nikula Cc: Chris Wilson Signed-off-by: Joonas Lahtinen Reviewed-by: Jani Nikula

[Intel-gfx] [PATCH v3 2/2] drm/i915: Simplify i915_reg_read_ioctl

Convert to use the freshly available made INTEL_GEN_MASK for easier grepping and improve function readability and clarify the UABI documentation. No functional changes. v2: - Lift GEM_BUG_ONs and use is_power_of_2 (Chris) - Retain -EINVAL on bad flags behavior (Chris) Cc: Tvrtko Ursulin

[Intel-gfx] [PATCH v3 1/2] drm/i915: Introduce INTEL_GEN_MASK

Split INTEL_GEN_MASK out of IS_GEN macro, and make it usable within static declarations (unlike combound statements). Cc: Jani Nikula Cc: Chris Wilson Signed-off-by: Joonas Lahtinen Reviewed-by: Jani Nikula

[Intel-gfx] [PATCH 1/3] drm-tip: 2017y-09m-07d-21h-01m-55s UTC integration manifest

From: Chris Wilson --- integration-manifest | 22 ++ 1 file changed, 22 insertions(+) create mode 100644 integration-manifest diff --git a/integration-manifest b/integration-manifest new file mode 100644 index ..1f3c6bf6d582 ---

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/6] drm/i915: Separate GuC/HuC specific functionality from intel_uc

== Series Details == Series: series starting with [1/6] drm/i915: Separate GuC/HuC specific functionality from intel_uc URL : https://patchwork.freedesktop.org/series/30097/ State : failure == Summary == Test kms_sysfs_edid_timing: pass -> WARN (shard-hsw)

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/doc: Update todo.rst

== Series Details == Series: drm/doc: Update todo.rst URL : https://patchwork.freedesktop.org/series/30098/ State : success == Summary == Series 30098v1 drm/doc: Update todo.rst https://patchwork.freedesktop.org/api/1.0/series/30098/revisions/1/mbox/ Test kms_cursor_legacy: Subgroup

[Intel-gfx] [PATCH] drm/doc: Update todo.rst

We're using this for outreachy, unfortunately someone already tried to look at a task that was done already :-( Update them all. Cc: Sean Paul Signed-off-by: Daniel Vetter --- Documentation/gpu/todo.rst | 15 --- 1 file changed, 4

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915: Separate GuC/HuC specific functionality from intel_uc

== Series Details == Series: series starting with [1/6] drm/i915: Separate GuC/HuC specific functionality from intel_uc URL : https://patchwork.freedesktop.org/series/30097/ State : success == Summary == Series 30097v1 series starting with [1/6] drm/i915: Separate GuC/HuC specific

<    1   2