== Series Details ==
Series: series starting with [CI,01/21] mm/shmem: introduce
shmem_file_setup_with_mnt
URL : https://patchwork.freedesktop.org/series/31525/
State : failure
== Summary ==
Test kms_properties:
Subgroup crtc-properties-legacy:
pass -> DMESG-WARN
== Series Details ==
Series: benchmark/gem_busy: Compare polling with syncobj_wait
URL : https://patchwork.freedesktop.org/series/31507/
State : warning
== Summary ==
Test kms_setmode:
Subgroup basic:
pass -> FAIL (shard-hsw) fdo#99912
Test gem_eio:
== Series Details ==
Series: igt/gem_eio: Check hang/eio recovery during suspend
URL : https://patchwork.freedesktop.org/series/31485/
State : success
== Summary ==
Test gem_eio:
Subgroup in-flight-contexts:
dmesg-warn -> PASS (shard-hsw) fdo#102886 +1
Test kms_cu
== Series Details ==
Series: drm/i915: Cancel the hotplug work when unregistering the connector
(rev2)
URL : https://patchwork.freedesktop.org/series/31501/
State : success
== Summary ==
Test kms_cursor_legacy:
Subgroup cursorA-vs-flipA-atomic-transitions:
fail -
== Series Details ==
Series: igt/gem_memfd: Exercise hugepages and memfd
URL : https://patchwork.freedesktop.org/series/31460/
State : success
== Summary ==
Test gem_eio:
Subgroup in-flight:
dmesg-warn -> PASS (shard-hsw) fdo#102886 +2
Test kms_setmode:
Su
== Series Details ==
Series: drm/i915: Cancel the hotplug work when unregistering the connector
URL : https://patchwork.freedesktop.org/series/31501/
State : warning
== Summary ==
Test drv_module_reload:
Subgroup basic-reload-inject:
pass -> DMESG-WARN (shard-hsw)
== Series Details ==
Series: series starting with [CI,01/21] mm/shmem: introduce
shmem_file_setup_with_mnt
URL : https://patchwork.freedesktop.org/series/31525/
State : success
== Summary ==
Series 31525v1 series starting with [CI,01/21] mm/shmem: introduce
shmem_file_setup_with_mnt
https://
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 wor
== 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:
dmes
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 sg_mask in a later patch.
Su
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 PPGTT.
v2: don't separate l
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
Reviewed-by: Chris Wilson
Link:
https://patchwork.freedesktop.org/patch/msgid/2017100
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
Reviewed-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Link:
https://patchwork.freedesktop.or
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 kbuild
test single sg
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 preferred if we could
ju
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
Cc: Chris Wilson
Cc: Zhenyu Wang
Reviewed-by: Zhenyu Wang
Reviewed-by: Chris Wi
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
Reviewed-by: Chris Wilson
Link:
https://patchwork.freedesktop.org/patch/msgid/201710
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
Cc: Chris Wilson
Reviewed-by: Chris Wilson
Link:
https://patchwork.freedesktop.org/patch/msgid/20171006
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 transparent-huge-pages f
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
Cc: Chris Wilson
Reviewed-by: Chris Wilson
Link:
https://patchw
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.
v2: remove redundant vma->p
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: Chris Wilson
Link:
https://patchwork.freedesktop.org/patch/msgid/20171006145041.21673-21-matthew.a...@intel.c
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 Wilson
Link:
https://patchwork.freedesktop.org/patch/msgid/20171006145041.21673-17-matthew.a...@intel.com
Sig
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: Matthew Auld
Cc: Joonas Laht
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 which completely fill the
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 sg_table where
possible, and
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
Cc: Chris Wilson
Reviewed-by: Chris Wilson
Link:
https://patchwork.freedesktop.o
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
Signed-off-by: Matthew Auld
Cc: Joona
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 pinning and objects which need
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
Cc: Joonas Lahtinen
Cc: Chris W
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 initialization of GuC objects
v2
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 p
Quoting Patchwork (2017-10-06 22:29:20)
> == 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) f
== 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 https://bugs.freedesktop.org/show_bug.cgi?
On Fri, Oct 06, 2017 at 06:19:12PM -0300, Paulo Zanoni wrote:
> 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/ser
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 series
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 force
== 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:
https://
== 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 smal
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 a/benchmarks/gem_busy.c b/benchmarks/gem_busy.c
index f050454
== 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:
== 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
== 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
== 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 https:
== 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
https://patchwork.freed
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 only
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: U
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 only
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 ]
== 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
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
> > Fixes: b2891eb2531e
== 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
priorit
== 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
https://patchwork.freedesktop.o
== 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 notif
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 t
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 w
== 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)
shar
== 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
rpm/forcew
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
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 ]
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
== 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:
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 ptr_to_u
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-
backing to libintel_tool
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
== 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 s
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. (Chris)
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: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_huc.c | 6 ++
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.
Signed-o
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 r
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 subte
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
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 Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c| 11 +++
drivers/gpu/drm/i91
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
---
drivers/gpu/drm/i915/i915_debugfs.c | 61 ++---
1 file changed, 57 insertions(+), 4 del
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 Wilson
---
drivers/gpu/drm/i915/i915_pci.c | 6 --
drivers/gpu/dr
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: Joonas Lahtinen
Cc: Chris
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 pa
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 ther
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
Cc: Zhenyu Wang
Reviewed-by: Zhenyu Wang
Reviewed-by: Chris Wilson
---
drivers/gp
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
---
drivers/gpu/drm/i915/i915_pci.c | 3 ++-
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 3 ++
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
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/scatterlist.c | 15 +++
1 file cha
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 op
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
Cc: Chris Wilson
Cc: Mika Kuopp
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
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 31 +
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
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c |
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: GEM_B
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
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gemfs.c | 22
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
d
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 mnt
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 Lahtinen
Cc: Mika Kuoppa
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
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 Wil
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 al
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 o
== 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/
fi-bd
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:
> WaDisableGatherAtSetS
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.
== 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) fdo#1027
== 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 to
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
1 - 100 of 204 matches
Mail list logo