[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Try harder to finish the idle-worker (rev2)

== Series Details == Series: drm/i915: Try harder to finish the idle-worker (rev2) URL : https://patchwork.freedesktop.org/series/29690/ State : success == Summary == Series 29690v2 drm/i915: Try harder to finish the idle-worker

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Prove an assert for when we expect forcewake to be held

s/Prove/Provide/ Quoting Chris Wilson (2017-10-06 15:54:59) > Add assert_forcewakes_active() (the complementary function to > assert_forcewakes_inactive) that documents the requirement of a > function for its callers to be holding the forcewake ref (i.e. the > function is part of a sequence over

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use rcu instead of stop_machine in set_wedged

Quoting Daniel Vetter (2017-10-06 15:20:09) > On Fri, Oct 06, 2017 at 12:03:49PM +0100, Chris Wilson wrote: > > Quoting Daniel Vetter (2017-10-06 10:06:37) > > > stop_machine is not really a locking primitive we should use, except > > > when the hw folks tell us the hw is broken and that's the

Re: [Intel-gfx] [PATCH v2] drm/i915: Order two completing nop_submit_request

Quoting Tvrtko Ursulin (2017-10-06 13:23:03) > > On 06/10/2017 12:56, Chris Wilson wrote: > > If two nop's (requests in-flight following a wedged device) complete at > > the same time, the global_seqno value written to the HWSP is undefined > > as the two threads are not serialized. > > > > v2:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Separate RC6, RPS, LLC ring Frequency management

== Series Details == Series: drm/i915: Separate RC6, RPS, LLC ring Frequency management URL : https://patchwork.freedesktop.org/series/31487/ State : success == Summary == Test kms_setmode: Subgroup basic: fail -> PASS (shard-hsw) fdo#99912 fdo#99912

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Cancel the hotplug work when unregistering the connector (rev2)

== Series Details == Series: drm/i915: Cancel the hotplug work when unregistering the connector (rev2) URL : https://patchwork.freedesktop.org/series/31501/ State : success == Summary == Series 31501v2 drm/i915: Cancel the hotplug work when unregistering the connector

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Make i915_engine_info pretty printer to standalone

== Series Details == Series: series starting with [1/2] drm/i915: Make i915_engine_info pretty printer to standalone URL : https://patchwork.freedesktop.org/series/31489/ State : failure == Summary == Test kms_cursor_legacy: Subgroup cursor-vs-flip-atomic-transitions:

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915/selftests: Hold the rpm/forcewake wakeref for the reset tests

== Series Details == Series: series starting with [1/2] drm/i915/selftests: Hold the rpm/forcewake wakeref for the reset tests URL : https://patchwork.freedesktop.org/series/31498/ State : warning == Summary == Series 31498v1 series starting with [1/2] drm/i915/selftests: Hold the

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with drm/i915: Preallocate our mmu notifier workequeu to unbreak cpu hotplug deadlock (rev2)

== Series Details == Series: series starting with drm/i915: Preallocate our mmu notifier workequeu to unbreak cpu hotplug deadlock (rev2) URL : https://patchwork.freedesktop.org/series/31476/ State : success == Summary == Series 31476v2 series starting with drm/i915: Preallocate our mmu

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Cancel the hotplug work when unregistering the connector

== Series Details == Series: drm/i915: Cancel the hotplug work when unregistering the connector URL : https://patchwork.freedesktop.org/series/31501/ State : warning == Summary == Series 31501v1 drm/i915: Cancel the hotplug work when unregistering the connector

[Intel-gfx] [PATCH igt] benchmark/gem_busy: Compare polling with syncobj_wait

v2: Hook the syncobj array to the execbuf! Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- benchmarks/gem_busy.c | 75 ++- 1 file changed, 74 insertions(+), 1 deletion(-) diff --git

Re: [Intel-gfx] [PATCH 01/10] drm/i915/guc: Precompute GuC shared data offset

On 06/10/17 05:35, Michał Winiarski wrote: On Thu, Oct 05, 2017 at 05:02:39PM +, Daniele Ceraolo Spurio wrote: On 05/10/17 02:33, Chris Wilson wrote: Quoting Michał Winiarski (2017-10-05 10:13:40) We're using first page of kernel context state to share data with GuC, let's precompute

[Intel-gfx] ✓ Fi.CI.BAT: success for igt/gem_memfd: Exercise hugepages and memfd

== Series Details == Series: igt/gem_memfd: Exercise hugepages and memfd URL : https://patchwork.freedesktop.org/series/31460/ State : success == Summary == IGT patchset tested on top of latest successful build d8954f05024d73a8b3f26fa0d5892d067a70fdac igt/gem_exec_scheduler: Add small

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Order two completing nop_submit_request (rev2)

== Series Details == Series: drm/i915: Order two completing nop_submit_request (rev2) URL : https://patchwork.freedesktop.org/series/31486/ State : warning == Summary == Test kms_plane: Subgroup plane-panning-bottom-right-suspend-pipe-B-planes: pass -> SKIP

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use rcu instead of stop_machine in set_wedged

Quoting Daniel Vetter (2017-10-06 15:20:09) > On Fri, Oct 06, 2017 at 12:03:49PM +0100, Chris Wilson wrote: > > Quoting Daniel Vetter (2017-10-06 10:06:37) > > > stop_machine is not really a locking primitive we should use, except > > > when the hw folks tell us the hw is broken and that's the

[Intel-gfx] [PATCH v2] drm/i915: Cancel the hotplug work when unregistering the connector

When we unregister the connector, we may have a pending hotplug work. This needs to be cancel early during the teardown so that it does not fire after we have freed the connector. Or else we may see something like: DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock)) [ cut here ]

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Try harder to finish the idle-worker (rev2)

== Series Details == Series: drm/i915: Try harder to finish the idle-worker (rev2) URL : https://patchwork.freedesktop.org/series/29690/ State : warning == Summary == Test kms_plane_multiple: Subgroup legacy-pipe-C-tiling-none: pass -> SKIP (shard-hsw)

Re: [Intel-gfx] [PATCH] drm/i915: Silence compiler warning for hsw_power_well_enable()

Quoting Imre Deak (2017-10-02 12:42:24) > On Mon, Oct 02, 2017 at 11:04:16AM +0100, Chris Wilson wrote: > > Not all compilers are able to determine that pg is guarded by wait_fuses > > and so may think that pg is used uninitialized. > > > > Reported-by: Geert Uytterhoeven >

[Intel-gfx] ✗ Fi.CI.BAT: warning for igt/gem_exec_capture: Exercise readback of userptr

== Series Details == Series: igt/gem_exec_capture: Exercise readback of userptr URL : https://patchwork.freedesktop.org/series/31480/ State : warning == Summary == IGT patchset tested on top of latest successful build d8954f05024d73a8b3f26fa0d5892d067a70fdac igt/gem_exec_scheduler: Add small

[Intel-gfx] ✓ Fi.CI.BAT: success for igt/gem_eio: Check hang/eio recovery during suspend

== Series Details == Series: igt/gem_eio: Check hang/eio recovery during suspend URL : https://patchwork.freedesktop.org/series/31485/ State : success == Summary == IGT patchset tested on top of latest successful build d8954f05024d73a8b3f26fa0d5892d067a70fdac igt/gem_exec_scheduler: Add small

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/cnl: WaDisableGatherAtSetShaderCommonSlice (rev2)

HI, > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Rodrigo Vivi > Sent: perjantai 6. lokakuuta 2017 16.10 > To: intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/cnl: >

[Intel-gfx] [PATCH 1/2] drm/i915/selftests: Hold the rpm/forcewake wakeref for the reset tests

Resetting the engine requires us to hold the forcewake wakeref to prevent RC6 trying to happen in the middle of the reset sequence. Normally, this is taken by i915_handle_error(), but as we are calling the lowlevel functions ourselves, we need to hold it. Wrap the entire live_hangcheck set of

Re: [Intel-gfx] [PATCH] drm/i915/huc: Fix includes in intel_huc.c

Quoting Michal Wajdeczko (2017-10-06 10:02:09) > Fix includes order and make sure we only include required headers. > While here, make intel_huc.h header self-contained. > > Signed-off-by: Michal Wajdeczko > Cc: Joonas Lahtinen > Cc:

[Intel-gfx] ✓ Fi.CI.BAT: success for huge gtt pages (rev13)

== Series Details == Series: huge gtt pages (rev13) URL : https://patchwork.freedesktop.org/series/25118/ State : success == Summary == Series 25118v13 huge gtt pages https://patchwork.freedesktop.org/api/1.0/series/25118/revisions/13/mbox/ Test gem_exec_suspend: Subgroup basic-s3:

[Intel-gfx] [PATCH] drm/i915: Cancel the hotplug work when unregistering the connector

When we unregister the connector, we may have a pending hotplug work. This needs to be cancel early during the teardown so that it does not fire after we have freed the connector. Or else we may see something like: DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock)) [ cut here ]

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use rcu instead of stop_machine in set_wedged

On Fri, Oct 06, 2017 at 12:12:41PM +0200, Thomas Gleixner wrote: > On Fri, 6 Oct 2017, Chris Wilson wrote: > > Quoting Daniel Vetter (2017-10-06 10:06:37) > > > stop_machine is not really a locking primitive we should use, except > > > when the hw folks tell us the hw is broken and that's the only

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/huc: Fix includes in intel_huc.c

== Series Details == Series: drm/i915/huc: Fix includes in intel_huc.c URL : https://patchwork.freedesktop.org/series/31475/ State : success == Summary == Test kms_cursor_legacy: Subgroup cursorA-vs-flipA-atomic-transitions: fail -> PASS (shard-hsw)

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix pointer-to-int conversion

Quoting Michal Wajdeczko (2017-10-06 14:08:44) > Commit faf654864b25 ("drm/i915: Unify uC variable types to avoid > flooding checkpatch.pl") breaks 32-bit kernel builds. Lets use > cast helper to make compiler happy. > > v2: introduce ptr_to_u64 (Chris) > > Signed-off-by: Michal Wajdeczko

[Intel-gfx] [PATCH 19/21] drm/i915: disable platform support for vGPU huge gtt pages

Currently gvt gtt handling doesn't support huge page entries, so disable for now. v2: remove useless 48b PPGTT check Suggested-by: Zhenyu Wang Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson

[Intel-gfx] [PATCH 20/21] drm/i915: enable platform support for 64K pages

For gen9+ enable platform level support for 64K pages. Also enable for mock testing. Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson Reviewed-by: Chris Wilson ---

[Intel-gfx] [PATCH 18/21] drm/i915/selftests: mix huge pages

Try to mix sg page sizes for 4K, 64K and 2M pages. v2: s/BIT(x) >> 12/BIT(x) >> PAGE_SHIFT/ Suggested-by: Chris Wilson Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson

[Intel-gfx] [ANNOUNCE] dim-tools mailing list for drm maintainer tools

The drm maintainer tools and documentation [1][2], the dim script in particular, have expanded in use and features and especially user base beyond at least my imagination. It's time to move the maintainer tools patches and discussion away from the intel-gfx mailing list, but it seems best to not

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/cnl: WaDisableGatherAtSetShaderCommonSlice (rev2)

Quoting Rodrigo Vivi (2017-10-06 14:10:06) > On Fri, Oct 06, 2017 at 11:06:34AM +, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915/cnl: WaDisableGatherAtSetShaderCommonSlice (rev2) > > URL : https://patchwork.freedesktop.org/series/31457/ > > State : warning > > > > ==

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Preallocate our mmu notifier workequeu to unbreak cpu hotplug deadlock

On 06/10/2017 15:23, Daniel Vetter wrote: On Fri, Oct 06, 2017 at 12:34:02PM +0100, Tvrtko Ursulin wrote: On 06/10/2017 10:06, Daniel Vetter wrote: 4.14-rc1 gained the fancy new cross-release support in lockdep, which seems to have uncovered a few more rules about what is allowed and isn't.

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Separate RC6, RPS, LLC ring Frequency management

== Series Details == Series: drm/i915: Separate RC6, RPS, LLC ring Frequency management URL : https://patchwork.freedesktop.org/series/31487/ State : success == Summary == Series 31487v1 drm/i915: Separate RC6, RPS, LLC ring Frequency management

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Make i915_engine_info pretty printer to standalone

== Series Details == Series: series starting with [1/2] drm/i915: Make i915_engine_info pretty printer to standalone URL : https://patchwork.freedesktop.org/series/31489/ State : success == Summary == Series 31489v1 series starting with [1/2] drm/i915: Make i915_engine_info pretty printer

[Intel-gfx] ✗ Fi.CI.BAT: failure for ] lib: Ask the kernel to quiesce the GPU

== Series Details == Series: ] lib: Ask the kernel to quiesce the GPU URL : https://patchwork.freedesktop.org/series/31448/ State : failure == Summary == IGT patchset tested on top of latest successful build d8954f05024d73a8b3f26fa0d5892d067a70fdac igt/gem_exec_scheduler: Add small priority

Re: [Intel-gfx] [PATCH i-g-t 1/7] intel-gpu-overlay: Move local perf implementation to a library

On 29/09/2017 14:43, Petri Latvala wrote: On Fri, Sep 29, 2017 at 01:39:33PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Idea is to avoid duplication across multiple users in upcoming patches. v2: Commit message and use a separate library instead of piggy-

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix pointer-to-int conversion

Quoting Chris Wilson (2017-10-06 14:16:55) > Quoting Michal Wajdeczko (2017-10-06 14:08:44) > > Commit faf654864b25 ("drm/i915: Unify uC variable types to avoid > > flooding checkpatch.pl") breaks 32-bit kernel builds. Lets use > > cast helper to make compiler happy. > > > > v2: introduce

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Don't use BIT() in UAPI section

== Series Details == Series: drm/i915: Don't use BIT() in UAPI section URL : https://patchwork.freedesktop.org/series/31482/ State : failure == Summary == Series 31482 revision 1 was fully merged or fully failed: no git log ___ Intel-gfx mailing

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/guc: Move firmware size check out of generic code

== Series Details == Series: drm/i915/guc: Move firmware size check out of generic code URL : https://patchwork.freedesktop.org/series/31474/ State : warning == Summary == Test kms_cursor_legacy: Subgroup cursorA-vs-flipA-atomic-transitions: fail -> PASS

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use rcu instead of stop_machine in set_wedged

On Fri, Oct 06, 2017 at 12:03:49PM +0100, Chris Wilson wrote: > Quoting Daniel Vetter (2017-10-06 10:06:37) > > stop_machine is not really a locking primitive we should use, except > > when the hw folks tell us the hw is broken and that's the only way to > > work around it. > > > > This patch

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix pointer-to-int conversion (rev2)

== Series Details == Series: drm/i915: Fix pointer-to-int conversion (rev2) URL : https://patchwork.freedesktop.org/series/31488/ State : success == Summary == Series 31488v2 drm/i915: Fix pointer-to-int conversion https://patchwork.freedesktop.org/api/1.0/series/31488/revisions/2/mbox/

Re: [Intel-gfx] [PATCH v2 06/11] drm/i915: Name i915_runtime_pm structure in dev_priv as "rpm"

On 10/6/2017 6:10 PM, Chris Wilson wrote: Quoting Sagar Arun Kamble (2017-10-06 13:13:35) We were using dev_priv->pm for runtime power management related state. This patch renames it to "rpm" which looks more apt. Will be using pm for state containing RPS/RC6 state in the next patch.

Re: [Intel-gfx] [PATCH v2 10/11] drm/i915: Create generic functions to control RC6, RPS

On 10/6/2017 6:16 PM, Chris Wilson wrote: Quoting Sagar Arun Kamble (2017-10-06 13:13:39) Prepared generic functions intel_enable_rc6, intel_disable_rc6, intel_enable_rps and intel_disable_rps functions to setup RC6/RPS based on platforms. v2: Make intel_enable/disable_rc6/rps static.

Re: [Intel-gfx] [PATCH v2 11/11] drm/i915: Introduce separate status variable for RC6 and LLC ring frequency setup

On 10/6/2017 6:25 PM, Chris Wilson wrote: Quoting Sagar Arun Kamble (2017-10-06 13:13:40) Defined new struct intel_rc6 to hold RC6 specific state and intel_ring_pstate to hold ring specific state. v2: s/intel_ring_pstate/intel_llc_pstate and rebase. (Chris) Signed-off-by: Sagar Arun Kamble

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Order two completing nop_submit_request (rev2)

== Series Details == Series: drm/i915: Order two completing nop_submit_request (rev2) URL : https://patchwork.freedesktop.org/series/31486/ State : success == Summary == Series 31486v2 drm/i915: Order two completing nop_submit_request

[Intel-gfx] [PATCH 02/21] drm/i915: introduce simple gemfs

Not a fully blown gemfs, just our very own tmpfs kernel mount. Doing so moves us away from the shmemfs shm_mnt, and gives us the much needed flexibility to do things like set our own mount options, namely huge= which should allow us to enable the use of transparent-huge-pages for our shmem backed

[Intel-gfx] [PATCH 2/2] drm/i915: Prove an assert for when we expect forcewake to be held

Add assert_forcewakes_active() (the complementary function to assert_forcewakes_inactive) that documents the requirement of a function for its callers to be holding the forcewake ref (i.e. the function is part of a sequence over which RC6 must be prevented). One such example is during ringbuffer

[Intel-gfx] [PATCH] drm/i915: Preallocate our mmu notifier workequeu to unbreak cpu hotplug deadlock

4.14-rc1 gained the fancy new cross-release support in lockdep, which seems to have uncovered a few more rules about what is allowed and isn't. This one here seems to indicate that allocating a work-queue while holding mmap_sem is a no-go, so let's try to preallocate it. Of course another way to

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Preallocate our mmu notifier workequeu to unbreak cpu hotplug deadlock

On Fri, Oct 06, 2017 at 12:34:02PM +0100, Tvrtko Ursulin wrote: > > On 06/10/2017 10:06, Daniel Vetter wrote: > > 4.14-rc1 gained the fancy new cross-release support in lockdep, which > > seems to have uncovered a few more rules about what is allowed and > > isn't. > > > > This one here seems to

[Intel-gfx] [PATCH 15/21] drm/i915: accurate page size tracking for the ppgtt

Now that we support multiple page sizes for the ppgtt, it would be useful to track the real usage for debugging purposes. Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson Reviewed-by: Chris

[Intel-gfx] [PATCH 16/21] drm/i915/debugfs: include some gtt page size metrics

Good to know, mostly for debugging purposes. v2: some improvements from Chris Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson Reviewed-by: Chris Wilson ---

[Intel-gfx] [PATCH 21/21] drm/i915: enable platform support for 2M pages

For gen8+ platforms which support the 48b PPGTT, enable platform level support for 2M pages. Also enable for mock testing. Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson Reviewed-by: Chris

[Intel-gfx] [PATCH 11/21] drm/i915: disable GTT cache for 2M pages

When SW enables the use of 2M/1G pages, it must disable the GTT cache. v2: don't disable for Cherryview which doesn't even support 48b PPGTT! v3: explicitly check that the system does support 2M/1G pages v4: split WA and decision logic Signed-off-by: Matthew Auld Cc:

[Intel-gfx] [PATCH 17/21] drm/i915/selftests: huge page tests

v2: mock test page support configurations and add MI_STORE_DWORD test v3: run all mockable huge page tests on all platforms via the mock_device v4: add pin_update regression test various improvements suggested by Chris v5: fix issues reported by kbuild test single sg spanning multiple

[Intel-gfx] [PATCH 08/21] drm/i915: align the vma start to the largest gtt page size

For the 48b PPGTT try to align the vma start address to the required page size boundary to guarantee we use said page size in the gtt. If we are dealing with multiple page sizes, we can't guarantee anything and just align to the largest. For soft pinning and objects which need to be tightly packed

[Intel-gfx] [PATCH 05/21] drm/i915: push set_pages down to the callers

Each backend is now responsible for calling __i915_gem_object_set_pages upon successfully gathering its backing storage. This eliminates the inconsistency between the async and sync paths, which stands out even more when we start throwing around an sg_mask in a later patch. Suggested-by: Chris

[Intel-gfx] [PATCH 06/21] drm/i915: introduce page_size members

In preparation for supporting huge gtt pages for the ppgtt, we introduce page size members for gem objects. We fill in the page sizes by scanning the sg table. v2: pass the sg_mask to set_pages v3: calculate the sg_mask inline with populating the sg_table where possible, and pass to set_pages

[Intel-gfx] [PATCH 14/21] drm/i915: support 64K pages for the 48b PPGTT

Support inserting 64K pages into the 48b PPGTT. v2: check for 64K scratch v3: we should only have to re-adjust maybe_64K at every sg interval Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson

[Intel-gfx] [PATCH 12/21] drm/i915: support 2M pages for the 48b PPGTT

Support inserting 2M gtt pages into the 48b PPGTT. v2: sanity check sg->length against page_size v3: don't recalculate rem on each loop whitespace breakup Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson

[Intel-gfx] [PATCH 09/21] drm/i915: align 64K objects to 2M

We can't mix 64K and 4K pte's in the same page-table, so for now we align 64K objects to 2M to avoid any potential mixing. This is potentially wasteful but in reality shouldn't be too bad since this only applies to the virtual address space of a 48b PPGTT. v2: don't separate logically connected

[Intel-gfx] [PATCH 10/21] drm/i915: enable IPS bit for 64K pages

Before we can enable 64K pages through the IPS bit, we must first enable it through MMIO, otherwise the page-walker will simply ignore it. v2: add comment mentioning that 64K is BDW+ v3: move to more suitable home Signed-off-by: Matthew Auld Cc: Joonas Lahtinen

[Intel-gfx] [PATCH 07/21] drm/i915: introduce vm set_pages/clear_pages

Move the setting/clearing of the vma->pages to a vm operation. Doing so neatens things up a little, but more importantly gives us a sane place to also set/clear the vma->pages_sizes, which we introduce later in preparation for supporting huge-pages. v2: remove redundant vma->pages check v3:

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

We are planning to use our own tmpfs mnt in i915 in place of the shm_mnt, such that we can control the mount options, in particular huge=, which we require to support huge-gtt-pages. So rather than roll our own version of __shmem_file_setup, it would be preferred if we could just give shmem our

[Intel-gfx] [PATCH 04/21] drm/i915: introduce page_sizes field to dev_info

In preparation for huge gtt pages expose page_sizes as part of the device info, to indicate the page sizes supported by the HW. Currently only 4K is supported. v2: s/page_size_mask/page_sizes/ v3: introduce I915_GTT_MAX_PAGE_SIZE Signed-off-by: Matthew Auld Cc: Joonas

[Intel-gfx] [PATCH 00/21] huge gtt pages

Some more bits of polish. Matthew Auld (21): mm/shmem: introduce shmem_file_setup_with_mnt drm/i915: introduce simple gemfs drm/i915/gemfs: enable THP drm/i915: introduce page_sizes field to dev_info drm/i915: push set_pages down to the callers drm/i915: introduce page_size members

[Intel-gfx] [PATCH 03/21] drm/i915/gemfs: enable THP

Enable transparent-huge-pages through gemfs by mounting with huge=within_size. v2: sprinkle within_size comment Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson Reviewed-by: Chris Wilson

[Intel-gfx] [PATCH 13/21] drm/i915: add support for 64K scratch page

Before we can fully enable 64K pages, we need to first support a 64K scratch page if we intend to support the case where we have object sizes < 2M, since any scratch PTE must also point to a 64K region. Without this our 64K usage is limited to objects which completely fill the page-table, and

Re: [Intel-gfx] [PATCH] drm/i915: Preallocate our mmu notifier workequeu to unbreak cpu hotplug deadlock

On 06/10/2017 16:52, Daniel Vetter wrote: 4.14-rc1 gained the fancy new cross-release support in lockdep, which seems to have uncovered a few more rules about what is allowed and isn't. This one here seems to indicate that allocating a work-queue while holding mmap_sem is a no-go, so let's try

[Intel-gfx] ✓ Fi.CI.BAT: success for benchmark/gem_busy: Compare polling with syncobj_wait

== Series Details == Series: benchmark/gem_busy: Compare polling with syncobj_wait URL : https://patchwork.freedesktop.org/series/31507/ State : success == Summary == IGT patchset tested on top of latest successful build d8954f05024d73a8b3f26fa0d5892d067a70fdac igt/gem_exec_scheduler: Add

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix pointer-to-int conversion (rev2)

== Series Details == Series: drm/i915: Fix pointer-to-int conversion (rev2) URL : https://patchwork.freedesktop.org/series/31488/ State : success == Summary == shard-hswtotal:2446 pass:1328 dwarn:6 dfail:0 fail:9 skip:1103 time:10066s == Logs == For more details see:

[Intel-gfx] [CI 09/21] drm/i915: align 64K objects to 2M

From: Matthew Auld We can't mix 64K and 4K pte's in the same page-table, so for now we align 64K objects to 2M to avoid any potential mixing. This is potentially wasteful but in reality shouldn't be too bad since this only applies to the virtual address space of a 48b

[Intel-gfx] [CI 15/21] drm/i915: accurate page size tracking for the ppgtt

From: Matthew Auld Now that we support multiple page sizes for the ppgtt, it would be useful to track the real usage for debugging purposes. Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson

[Intel-gfx] [CI 03/21] drm/i915/gemfs: enable THP

From: Matthew Auld Enable transparent-huge-pages through gemfs by mounting with huge=within_size. v2: sprinkle within_size comment Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson

[Intel-gfx] [CI 17/21] drm/i915/selftests: huge page tests

From: Matthew Auld v2: mock test page support configurations and add MI_STORE_DWORD test v3: run all mockable huge page tests on all platforms via the mock_device v4: add pin_update regression test various improvements suggested by Chris v5: fix issues reported by

[Intel-gfx] [CI 01/21] mm/shmem: introduce shmem_file_setup_with_mnt

From: Matthew Auld We are planning to use our own tmpfs mnt in i915 in place of the shm_mnt, such that we can control the mount options, in particular huge=, which we require to support huge-gtt-pages. So rather than roll our own version of __shmem_file_setup, it would be

[Intel-gfx] [CI 19/21] drm/i915: disable platform support for vGPU huge gtt pages

From: Matthew Auld Currently gvt gtt handling doesn't support huge page entries, so disable for now. v2: remove useless 48b PPGTT check Suggested-by: Zhenyu Wang Signed-off-by: Matthew Auld Cc: Joonas Lahtinen

[Intel-gfx] [CI 21/21] drm/i915: enable platform support for 2M pages

From: Matthew Auld For gen8+ platforms which support the 48b PPGTT, enable platform level support for 2M pages. Also enable for mock testing. Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson

[Intel-gfx] [CI 18/21] drm/i915/selftests: mix huge pages

From: Matthew Auld Try to mix sg page sizes for 4K, 64K and 2M pages. v2: s/BIT(x) >> 12/BIT(x) >> PAGE_SHIFT/ Suggested-by: Chris Wilson Signed-off-by: Matthew Auld Cc: Joonas Lahtinen

[Intel-gfx] [CI 02/21] drm/i915: introduce simple gemfs

From: Matthew Auld Not a fully blown gemfs, just our very own tmpfs kernel mount. Doing so moves us away from the shmemfs shm_mnt, and gives us the much needed flexibility to do things like set our own mount options, namely huge= which should allow us to enable the use of

[Intel-gfx] [CI 05/21] drm/i915: push set_pages down to the callers

From: Matthew Auld Each backend is now responsible for calling __i915_gem_object_set_pages upon successfully gathering its backing storage. This eliminates the inconsistency between the async and sync paths, which stands out even more when we start throwing around an

[Intel-gfx] [CI 12/21] drm/i915: support 2M pages for the 48b PPGTT

From: Matthew Auld Support inserting 2M gtt pages into the 48b PPGTT. v2: sanity check sg->length against page_size v3: don't recalculate rem on each loop whitespace breakup Signed-off-by: Matthew Auld Cc: Joonas Lahtinen

[Intel-gfx] [CI 04/21] drm/i915: introduce page_sizes field to dev_info

From: Matthew Auld In preparation for huge gtt pages expose page_sizes as part of the device info, to indicate the page sizes supported by the HW. Currently only 4K is supported. v2: s/page_size_mask/page_sizes/ v3: introduce I915_GTT_MAX_PAGE_SIZE Signed-off-by:

[Intel-gfx] [CI 13/21] drm/i915: add support for 64K scratch page

From: Matthew Auld Before we can fully enable 64K pages, we need to first support a 64K scratch page if we intend to support the case where we have object sizes < 2M, since any scratch PTE must also point to a 64K region. Without this our 64K usage is limited to objects

[Intel-gfx] [CI 06/21] drm/i915: introduce page_size members

From: Matthew Auld In preparation for supporting huge gtt pages for the ppgtt, we introduce page size members for gem objects. We fill in the page sizes by scanning the sg table. v2: pass the sg_mask to set_pages v3: calculate the sg_mask inline with populating the

[Intel-gfx] [CI 07/21] drm/i915: introduce vm set_pages/clear_pages

From: Matthew Auld Move the setting/clearing of the vma->pages to a vm operation. Doing so neatens things up a little, but more importantly gives us a sane place to also set/clear the vma->pages_sizes, which we introduce later in preparation for supporting huge-pages.

[Intel-gfx] [CI 20/21] drm/i915: enable platform support for 64K pages

From: Matthew Auld For gen9+ enable platform level support for 64K pages. Also enable for mock testing. Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson Reviewed-by:

[Intel-gfx] [CI 16/21] drm/i915/debugfs: include some gtt page size metrics

From: Matthew Auld Good to know, mostly for debugging purposes. v2: some improvements from Chris Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson Reviewed-by: Chris

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

Quoting Chris Wilson (2017-08-23 13:55:55) > 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

Re: [Intel-gfx] [PATCH 08/21] drm/i915: align the vma start to the largest gtt page size

Quoting Matthew Auld (2017-10-06 15:50:28) > For the 48b PPGTT try to align the vma start address to the required > page size boundary to guarantee we use said page size in the gtt. If we > are dealing with multiple page sizes, we can't guarantee anything and > just align to the largest. For soft

Re: [Intel-gfx] [PATCH] drm/i915/execlists: Add a comment for the extra MI_ARB_ENABLE

Quoting Michel Thierry (2017-10-05 20:41:40) > On 10/5/2017 12:10 PM, Chris Wilson wrote: > > Michel Thierry noticed that we were applying WaDisableCtxRestoreArbitration > > even to gen9, which does not require the w/a. The rationale is that we > > need to enable MI arbitration for execlists to

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with drm/i915: Preallocate our mmu notifier workequeu to unbreak cpu hotplug deadlock (rev2)

== Series Details == Series: series starting with drm/i915: Preallocate our mmu notifier workequeu to unbreak cpu hotplug deadlock (rev2) URL : https://patchwork.freedesktop.org/series/31476/ State : warning == Summary == Test gem_eio: Subgroup in-flight-contexts:

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: avoid unnecessary call to intel_hpd_pin_to_port

Em Sex, 2017-10-06 às 10:45 +, Patchwork escreveu: > == Series Details == > > Series: series starting with [1/2] drm/i915: avoid unnecessary call > to intel_hpd_pin_to_port > URL   : https://patchwork.freedesktop.org/series/31459/ > State : warning > > == Summary == > > Series 31459v1

Re: [Intel-gfx] [PATCH 4/5] drm/i915/guc: group initialization of GuC objects

On 10/04/2017 06:58 AM, Michal Wajdeczko wrote: On Wed, 04 Oct 2017 00:57:00 +0200, Sujaritha Sundaresan wrote: The previous patch has split up the initialization of some of the GuC objects in 2 different functions, let's pull them back together. v3: Group

[Intel-gfx] ✓ Fi.CI.IGT: success for huge gtt pages (rev13)

== Series Details == Series: huge gtt pages (rev13) URL : https://patchwork.freedesktop.org/series/25118/ State : success == Summary == Test kms_setmode: Subgroup basic: fail -> PASS (shard-hsw) fdo#99912 fdo#99912

[Intel-gfx] [CI 08/21] drm/i915: align the vma start to the largest gtt page size

From: Matthew Auld For the 48b PPGTT try to align the vma start address to the required page size boundary to guarantee we use said page size in the gtt. If we are dealing with multiple page sizes, we can't guarantee anything and just align to the largest. For soft

[Intel-gfx] [CI 10/21] drm/i915: enable IPS bit for 64K pages

From: Matthew Auld Before we can enable 64K pages through the IPS bit, we must first enable it through MMIO, otherwise the page-walker will simply ignore it. v2: add comment mentioning that 64K is BDW+ v3: move to more suitable home Signed-off-by: Matthew Auld

[Intel-gfx] [CI 14/21] drm/i915: support 64K pages for the 48b PPGTT

From: Matthew Auld Support inserting 64K pages into the 48b PPGTT. v2: check for 64K scratch v3: we should only have to re-adjust maybe_64K at every sg interval Signed-off-by: Matthew Auld Cc: Joonas Lahtinen

[Intel-gfx] [CI 11/21] drm/i915: disable GTT cache for 2M pages

From: Matthew Auld When SW enables the use of 2M/1G pages, it must disable the GTT cache. v2: don't disable for Cherryview which doesn't even support 48b PPGTT! v3: explicitly check that the system does support 2M/1G pages v4: split WA and decision logic

  1   2   3   >