Re: [Intel-gfx] [PATCH] drm/i915: Remove redundant user_access_end() from __copy_from_user() error path

On Fri, 9 Aug 2019, Sedat Dilek wrote: > On Fri, Aug 9, 2019 at 1:03 AM Nick Desaulniers > wrote: > > > > On Thu, Aug 8, 2019 at 1:22 PM Thomas Gleixner wrote: > > > > tglx just picked up 2 other patches of mine, bumping just in case he's > > > > not picking up patches while on vacation. ;) > >

[Intel-gfx] ✓ Fi.CI.IGT: success for put_user_pages(): miscellaneous call sites

== Series Details == Series: put_user_pages(): miscellaneous call sites URL : https://patchwork.freedesktop.org/series/64950/ State : success == Summary == CI Bug Log - changes from CI_DRM_6667_full -> Patchwork_13939_full Summary ---

[Intel-gfx] ✗ Fi.CI.IGT: failure for dma-buf: make dma_fence structure a bit smaller (rev3)

== Series Details == Series: dma-buf: make dma_fence structure a bit smaller (rev3) URL : https://patchwork.freedesktop.org/series/64953/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6667_full -> Patchwork_13938_full

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Check for a second VCS engine more carefully (rev2)

== Series Details == Series: drm/i915: Check for a second VCS engine more carefully (rev2) URL : https://patchwork.freedesktop.org/series/64938/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6667_full -> Patchwork_13935_full

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Replace global bsd_dispatch_index with random seed (rev2)

== Series Details == Series: drm/i915: Replace global bsd_dispatch_index with random seed (rev2) URL : https://patchwork.freedesktop.org/series/64891/ State : success == Summary == CI Bug Log - changes from CI_DRM_6665_full -> Patchwork_13933_full

[Intel-gfx] ✗ Fi.CI.BAT: failure for Introduce memory region concept (including device local memory) (rev3)

== Series Details == Series: Introduce memory region concept (including device local memory) (rev3) URL : https://patchwork.freedesktop.org/series/56683/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6670 -> Patchwork_13957

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Cancel non-persistent contexts on close

Quoting Chris Wilson (2019-08-06 14:47:25) > Normally, we rely on our hangcheck to prevent persistent batches from > hogging the GPU. However, if the user disables hangcheck, this mechanism > breaks down. Despite our insistence that this is unsafe, the users are > equally insistent that they want

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Introduce memory region concept (including device local memory) (rev3)

== Series Details == Series: Introduce memory region concept (including device local memory) (rev3) URL : https://patchwork.freedesktop.org/series/56683/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: buddy allocator

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Introduce memory region concept (including device local memory) (rev3)

== Series Details == Series: Introduce memory region concept (including device local memory) (rev3) URL : https://patchwork.freedesktop.org/series/56683/ State : warning == Summary == $ dim checkpatch origin/drm-tip 45cebf7cea76 drm/i915: buddy allocator -:29: WARNING:FILE_PATH_CHANGES:

Re: [Intel-gfx] [PATCH v3 24/37] drm/i915: set num_fence_regs to 0 if there is no aperture

On 8/9/19 3:26 PM, Matthew Auld wrote: From: Daniele Ceraolo Spurio We can't fence anything without aperture. When I wrote this patch (before LMEM was in the picture) mappable aperture was supposed to only be missing in headless scenarios so I didn't consider the display case. Do we

[Intel-gfx] [PATCH v3 36/37] drm/i915/query: Expose memory regions through the query uAPI

From: Abdiel Janulgue Returns the available memory region areas supported by the HW. Signed-off-by: Abdiel Janulgue Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_query.c | 57 +++ include/uapi/drm/i915_drm.h | 39 + 2 files changed,

[Intel-gfx] [PATCH v3 26/37] drm/i915: error capture with no ggtt slot

From: Daniele Ceraolo Spurio If the aperture is not available in HW we can't use a ggtt slot and wc copy, so fall back to regular kmap. Signed-off-by: Daniele Ceraolo Spurio Signed-off-by: Abdiel Janulgue --- drivers/gpu/drm/i915/i915_gem_gtt.c | 19

[Intel-gfx] [PATCH v3 33/37] drm/i915: cpu-map based dumb buffers

From: Abdiel Janulgue If there is no aperture we can't use map_gtt to map dumb buffers, so we need a cpu-map based path to do it. We prefer map_gtt on platforms that do have aperture. Signed-off-by: Abdiel Janulgue Cc: Daniele Ceraolo Spurio Cc: Tvrtko Ursulin Cc: Matthew Auld ---

[Intel-gfx] [PATCH v3 37/37] HAX drm/i915: add the fake lmem region

Intended for upstream testing so that we can still exercise the LMEM plumbing and !HAS_MAPPABLE_APERTURE paths. Smoke tested on Skull Canyon device. This works by allocating an intel_memory_region for a reserved portion of system memory, which we treat like LMEM. For the LMEMBAR we steal the

[Intel-gfx] [PATCH v3 34/37] drm/i915: support basic object migration

We are going want to able to move objects between different regions like system memory and local memory. In the future everything should be just another region. Signed-off-by: Matthew Auld Signed-off-by: Abdiel Janulgue Signed-off-by: CQ Tang Cc: Joonas Lahtinen Cc: Abdiel Janulgue ---

[Intel-gfx] [PATCH v3 28/37] drm/i915: check for missing aperture in insert_mappable_node

From: CQ Tang Signed-off-by: CQ Tang Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 2aa4fbe7edc0..af63d1a0af14 100644 ---

[Intel-gfx] [PATCH v3 35/37] drm/i915: Introduce GEM_OBJECT_SETPARAM with I915_PARAM_MEMORY_REGION

From: Abdiel Janulgue This call will specify which memory region an object should be placed. Note that changing the object's backing storage should be immediately done after an object is created or if it's not yet in use, otherwise this will fail on a busy object. Signed-off-by: Abdiel

[Intel-gfx] [PATCH v3 27/37] drm/i915: Don't try to place HWS in non-existing mappable region

From: Michal Wajdeczko HWS placement restrictions can't just rely on HAS_LLC flag. Signed-off-by: Michal Wajdeczko Cc: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[Intel-gfx] [PATCH v3 29/37] drm/i915: Allow i915 to manage the vma offset nodes instead of drm core

From: Abdiel Janulgue This enables us to store extra data within vma->vm_private_data and assign the pagefault ops for each mmap instance. We replace the core drm_gem_mmap implementation to overcome the limitation in having only a single offset node per gem object, allowing us to have multiple

[Intel-gfx] [PATCH v3 31/37] drm/i915/lmem: add helper to get CPU accessible offset

From: Abdiel Janulgue LMEM can be accessed by the CPU through a BAR. The mapping itself should be 1:1. Signed-off-by: Abdiel Janulgue Signed-off-by: Matthew Auld Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 16 drivers/gpu/drm/i915/gem/i915_gem_lmem.h

[Intel-gfx] [PATCH v3 24/37] drm/i915: set num_fence_regs to 0 if there is no aperture

From: Daniele Ceraolo Spurio We can't fence anything without aperture. Signed-off-by: Daniele Ceraolo Spurio Signed-off-by: Stuart Summers Cc: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_fence_reg.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

[Intel-gfx] [PATCH v3 32/37] drm/i915: Add cpu and lmem fault handlers

From: Abdiel Janulgue Fault handler to handle missing pages to be filled depending on an object's backing storage. Handle also changes needed to refault pages depending on fault handler usage. Signed-off-by: Abdiel Janulgue Signed-off-by: Matthew Auld Cc: Joonas Lahtinen ---

[Intel-gfx] [PATCH v3 30/37] drm/i915: Introduce DRM_I915_GEM_MMAP_OFFSET

From: Abdiel Janulgue Add a new CPU mmap implementation that allows multiple fault handlers that depends on the object's backing pages. Note that we multiplex mmap_gtt and mmap_offset through the same ioctl, and use the zero extending behaviour of drm to differentiate between them, when we

[Intel-gfx] [PATCH v3 13/37] drm/i915/selftests: move gpu-write-dw into utils

Using the gpu to write to some dword over a number of pages is rather useful, and we already have two copies of such a thing, and we don't want a third so move it to utils. There is probably some other stuff also... Signed-off-by: Matthew Auld --- .../gpu/drm/i915/gem/selftests/huge_pages.c |

[Intel-gfx] [PATCH v3 15/37] drm/i915/selftest: extend coverage to include LMEM huge-pages

Signed-off-by: Matthew Auld --- .../gpu/drm/i915/gem/selftests/huge_pages.c | 121 +- 1 file changed, 120 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c index

[Intel-gfx] [PATCH v3 20/37] drm/i915: treat shmem as a region

Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Abdiel Janulgue --- drivers/gpu/drm/i915/gem/i915_gem_phys.c | 6 +- drivers/gpu/drm/i915/gem/i915_gem_region.c| 14 +++- drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 68 ++- drivers/gpu/drm/i915/i915_drv.c

[Intel-gfx] [PATCH v3 25/37] drm/i915/selftests: check for missing aperture

We may be missing support for the mappable aperture on some platforms. Signed-off-by: Matthew Auld Cc: Daniele Ceraolo Spurio --- .../drm/i915/gem/selftests/i915_gem_coherency.c| 5 - drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 3 +++

[Intel-gfx] [PATCH v3 11/37] drm/i915/blt: bump size restriction

Reported-by: Chris Wilson Signed-off-by: Matthew Auld --- .../gpu/drm/i915/gem/i915_gem_client_blt.c| 31 +++- .../gpu/drm/i915/gem/i915_gem_object_blt.c| 139 ++ .../gpu/drm/i915/gem/i915_gem_object_blt.h| 9 +- .../i915/gem/selftests/i915_gem_client_blt.c | 16

[Intel-gfx] [PATCH v3 12/37] drm/i915/blt: support copying objects

We can already clear an object with the blt, so try to do the same to support copying from one object backing store to another. Really this is just object -> object, which is not that useful yet, what we really want is two backing stores, but that will require some vma rework first, otherwise we

[Intel-gfx] [PATCH v3 14/37] drm/i915/selftests: add write-dword test for LMEM

Simple test writing to dwords across an object, using various engines in a randomized order, checking that our writes land from the cpu. Signed-off-by: Matthew Auld --- .../drm/i915/selftests/intel_memory_region.c | 179 ++ 1 file changed, 179 insertions(+) diff --git

[Intel-gfx] [PATCH v3 17/37] drm/i915/lmem: support pread

We need to add support for pread'ing an LMEM object. Signed-off-by: Matthew Auld Signed-off-by: Steve Hampson Cc: Joonas Lahtinen Cc: Abdiel Janulgue --- drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 88 +++ .../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +

[Intel-gfx] [PATCH v3 22/37] drm/i915: define HAS_MAPPABLE_APERTURE

From: Daniele Ceraolo Spurio The following patches in the series will use it to avoid certain operations when aperture is not available in HW. Signed-off-by: Daniele Ceraolo Spurio Cc: Matthew Auld --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ 1 file changed, 2 insertions(+) diff --git

[Intel-gfx] [PATCH v3 23/37] drm/i915: do not map aperture if it is not available.

From: Daniele Ceraolo Spurio Skip both setup and cleanup of the aperture mapping if the HW doesn't have an aperture bar. Signed-off-by: Daniele Ceraolo Spurio Cc: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 36 ++--- 1 file changed, 22 insertions(+), 14

[Intel-gfx] [PATCH v3 19/37] drm/i915: enumerate and init each supported region

From: Abdiel Janulgue Nothing to enumerate yet... Signed-off-by: Abdiel Janulgue Signed-off-by: Matthew Auld Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_gem_gtt.c | 70 +--

[Intel-gfx] [PATCH v3 21/37] drm/i915: treat stolen as a region

Convert stolen memory over to a region object. Still leaves open the question with what to do with pre-allocated objects... Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Abdiel Janulgue --- drivers/gpu/drm/i915/gem/i915_gem_region.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_stolen.c |

[Intel-gfx] [PATCH v3 18/37] drm/i915/lmem: support pwrite

We need to add support for pwrite'ing an LMEM object. Signed-off-by: Matthew Auld Signed-off-by: Steve Hampson Cc: Joonas Lahtinen Cc: Abdiel Janulgue --- drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 87 1 file changed, 87 insertions(+) diff --git

[Intel-gfx] [PATCH v3 16/37] drm/i915/lmem: support CPU relocations

Add LMEM support for the CPU reloc path. When doing relocations we have both a GPU and CPU reloc path, as well as some debugging options to force a particular path. The GPU reloc path is preferred when the object is not currently idle, otherwise we use the CPU reloc path. Since we can't kmap the

[Intel-gfx] [PATCH v3 09/37] drm/i915/lmem: support kernel mapping

From: Abdiel Janulgue We can create LMEM objects, but we also need to support mapping them into kernel space for internal use. Signed-off-by: Abdiel Janulgue Signed-off-by: Matthew Auld Signed-off-by: Steve Hampson Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/gem/i915_gem_internal.c | 4

[Intel-gfx] [PATCH v3 10/37] drm/i915/blt: don't assume pinned intel_context

Currently we just pass in bcs0->engine_context so it matters not, but in the future we may want to pass in something that is not a kernel_context, so try to be a bit more generic. Suggested-by: Chris Wilson Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/gem/i915_gem_client_blt.c | 3 ++-

[Intel-gfx] [PATCH v3 08/37] drm/i915: setup io-mapping for LMEM

From: Abdiel Janulgue Signed-off-by: Abdiel Janulgue Cc: Matthew Auld --- drivers/gpu/drm/i915/intel_region_lmem.c | 28 ++-- 1 file changed, 26 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_region_lmem.c b/drivers/gpu/drm/i915/intel_region_lmem.c

[Intel-gfx] [PATCH v3 04/37] drm/i915/region: support continuous allocations

Some objects may need to be allocated as a continuous block, thinking ahead the various kernel io_mapping interfaces seem to expect it. Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Abdiel Janulgue --- .../gpu/drm/i915/gem/i915_gem_object_types.h | 4 +

[Intel-gfx] [PATCH v3 06/37] drm/i915: Add memory region information to device_info

From: Abdiel Janulgue Exposes available regions for the platform. Shared memory will always be available. Signed-off-by: Abdiel Janulgue Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/intel_device_info.h | 2 ++ 2 files changed, 4

[Intel-gfx] [PATCH v3 07/37] drm/i915: support creating LMEM objects

We currently define LMEM, or local memory, as just another memory region, like system memory or stolen, which we can expose to userspace and can be mapped to the CPU via some BAR. Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Abdiel Janulgue --- drivers/gpu/drm/i915/Makefile

[Intel-gfx] [PATCH v3 03/37] drm/i915/region: support basic eviction

Support basic eviction for regions. Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Abdiel Janulgue --- .../gpu/drm/i915/gem/i915_gem_object_types.h | 7 ++ drivers/gpu/drm/i915/gem/i915_gem_region.c| 11 +++ drivers/gpu/drm/i915/gem/i915_gem_region.h| 1 +

[Intel-gfx] [PATCH v3 02/37] drm/i915: introduce intel_memory_region

Support memory regions, as defined by a given (start, end), and allow creating GEM objects which are backed by said region. The immediate goal here is to have something to represent our device memory, but later on we also want to represent every memory domain with a region, so stolen, shmem, and

[Intel-gfx] [PATCH v3 01/37] drm/i915: buddy allocator

Simple buddy allocator. We want to allocate properly aligned power-of-two blocks to promote usage of huge-pages for the GTT, so 64K, 2M and possibly even 1G. While we do support allocating stuff at a specific offset, it is more intended for preallocating portions of the address space, say for an

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Push the wakeref->count deferral to the backend

== Series Details == Series: series starting with [1/2] drm/i915: Push the wakeref->count deferral to the backend URL : https://patchwork.freedesktop.org/series/64995/ State : success == Summary == CI Bug Log - changes from CI_DRM_6670 -> Patchwork_13956

[Intel-gfx] [PATCH v3 05/37] drm/i915/region: support volatile objects

Volatile objects are marked as DONTNEED while pinned, therefore once unpinned the backing store can be discarded. Signed-off-by: Matthew Auld Signed-off-by: CQ Tang Cc: Joonas Lahtinen Cc: Abdiel Janulgue --- drivers/gpu/drm/i915/gem/i915_gem_internal.c | 17 +++---

[Intel-gfx] [PATCH v3 00/37] Introduce memory region concept (including device local memory)

In preparation for upcoming devices with device local memory, introduce the concept of different memory regions, and a simple buddy allocator to manage them in i915. One of the concerns raised from v1 was around not using enough of TTM, which is a fair criticism, so trying to get better alignment

Re: [Intel-gfx] [PATCH 3/3] drm/i915/blt: bump the size restriction

> -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Tang, CQ > Sent: Friday, August 9, 2019 3:21 PM > To: Chris Wilson ; Auld, Matthew > ; intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 3/3] drm/i915/blt: bump the size

Re: [Intel-gfx] [PATCH 3/3] drm/i915/blt: bump the size restriction

> -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Chris Wilson > Sent: Friday, August 9, 2019 2:18 PM > To: Auld, Matthew ; intel- > g...@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 3/3] drm/i915/blt: bump the size

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/execlists: Backtrack along timeline

== Series Details == Series: drm/i915/execlists: Backtrack along timeline URL : https://patchwork.freedesktop.org/series/64942/ State : success == Summary == CI Bug Log - changes from CI_DRM_6663_full -> Patchwork_13932_full Summary

[Intel-gfx] ✓ Fi.CI.BAT: success for Some bits from the LMEM series

== Series Details == Series: Some bits from the LMEM series URL : https://patchwork.freedesktop.org/series/64994/ State : success == Summary == CI Bug Log - changes from CI_DRM_6670 -> Patchwork_13955 Summary --- **SUCCESS** No

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Keep the engine awake until the tasklet is idle

== Series Details == Series: drm/i915/guc: Keep the engine awake until the tasklet is idle URL : https://patchwork.freedesktop.org/series/64992/ State : success == Summary == CI Bug Log - changes from CI_DRM_6670 -> Patchwork_13954 Summary

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Some bits from the LMEM series

== Series Details == Series: Some bits from the LMEM series URL : https://patchwork.freedesktop.org/series/64994/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: buddy allocator +drivers/gpu/drm/i915/selftests/i915_buddy.c:292:13: warning:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/gtt: enable GTT cache by default

== Series Details == Series: series starting with [1/2] drm/i915/gtt: enable GTT cache by default URL : https://patchwork.freedesktop.org/series/64988/ State : success == Summary == CI Bug Log - changes from CI_DRM_6670 -> Patchwork_13953

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Some bits from the LMEM series

== Series Details == Series: Some bits from the LMEM series URL : https://patchwork.freedesktop.org/series/64994/ State : warning == Summary == $ dim checkpatch origin/drm-tip 94ffded7068a drm/i915: buddy allocator -:30: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does

Re: [Intel-gfx] [PATCH 1/3] drm/i915: buddy allocator

Quoting Matthew Auld (2019-08-09 21:29:24) > +int i915_buddy_alloc_range(struct i915_buddy_mm *mm, > + struct list_head *blocks, > + u64 start, u64 size) > +{ > + struct i915_buddy_block *block; > + struct i915_buddy_block *buddy; > +

Re: [Intel-gfx] [PATCH 3/3] drm/i915/blt: bump the size restriction

Quoting Matthew Auld (2019-08-09 21:29:26) > As pointed out by Chris, with our current approach we are actually > limited to S16_MAX * PAGE_SIZE for our size when using the blt to clear > pages. Keeping things simple try to fix this by reducing the copy to a > sequence of S16_MAX * PAGE_SIZE

Re: [Intel-gfx] [PATCH 2/3] drm/i915/blt: don't assume pinned intel_context

Quoting Matthew Auld (2019-08-09 21:29:25) > Currently we just pass in bcs0->engine_context so it matters not, but in > the future we may want to pass in something that is not a > kernel_context, so try to be a bit more generic. > > Suggested-by: Chris Wilson > Signed-off-by: Matthew Auld > Cc:

[Intel-gfx] [PATCH 2/2] drm/i915/guc: Keep the engine awake until the tasklet is idle

For the guc, we need to keep the engine awake (and not parked) and not just the gt. If we let the engine park, we disable the irq and stop processing the tasklet, leaving state outstanding inside the tasklet. Reported-by: Daniele Ceraolo Spurio Signed-off-by: Chris Wilson Cc: Daniele Ceraolo

[Intel-gfx] [PATCH 1/2] drm/i915: Push the wakeref->count deferral to the backend

If the backend wishes to defer the wakeref parking, make it responsible for unlocking the wakeref (i.e. bumping the counter). This allows it to time the unlock much more carefully in case it happens to needs the wakeref to be active during its deferral. For instance, during engine parking we may

[Intel-gfx] Plan B

A bit fragile, perhaps? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/3] drm/i915/blt: don't assume pinned intel_context

Currently we just pass in bcs0->engine_context so it matters not, but in the future we may want to pass in something that is not a kernel_context, so try to be a bit more generic. Suggested-by: Chris Wilson Signed-off-by: Matthew Auld Cc: Chris Wilson ---

[Intel-gfx] [PATCH 0/3] Some bits from the LMEM series

We are going to want the blt improvements and they can go in without everything else. Also the buddy allocator is fairly standalone at this point, and includes a set of selftests(some donated by Chris) and is unlikely to change much. Matthew Auld (3): drm/i915: buddy allocator drm/i915/blt:

[Intel-gfx] [PATCH 1/3] drm/i915: buddy allocator

Simple buddy allocator. We want to allocate properly aligned power-of-two blocks to promote usage of huge-pages for the GTT, so 64K, 2M and possibly even 1G. While we do support allocating stuff at a specific offset, it is more intended for preallocating portions of the address space, say for an

[Intel-gfx] [PATCH 3/3] drm/i915/blt: bump the size restriction

As pointed out by Chris, with our current approach we are actually limited to S16_MAX * PAGE_SIZE for our size when using the blt to clear pages. Keeping things simple try to fix this by reducing the copy to a sequence of S16_MAX * PAGE_SIZE blocks. Reported-by: Chris Wilson Signed-off-by:

Re: [Intel-gfx] [PATCH] drm/i915: Remove redundant user_access_end() from __copy_from_user() error path

On Fri, Aug 9, 2019 at 1:03 AM Nick Desaulniers wrote: > > On Thu, Aug 8, 2019 at 1:22 PM Thomas Gleixner wrote: > > > tglx just picked up 2 other patches of mine, bumping just in case he's > > > not picking up patches while on vacation. ;) > > > > I'm only half on vacation :) > > > > So I can

Re: [Intel-gfx] [PATCH] drm/i915: Stop reconfiguring our shmemfs mountpoint

On Fri, Aug 9, 2019 at 8:52 PM Chris Wilson wrote: > > Quoting Matthew Auld (2019-08-09 19:47:02) > > On Thu, 8 Aug 2019 at 18:23, Chris Wilson wrote: > > > > > > The filesystem reconfigure API is undergoing a transition, breaking our > > > current code. As we only set the default options, we

[Intel-gfx] [PATCH] drm/i915/guc: Keep the engine awake until the tasklet is idle

For the guc, we need to keep the engine awake (and not parked) and not just the gt. If we let the engine park, we disable the irq and stop processing the tasklet, leaving state outstanding inside the tasklet. Reported-by: Daniele Ceraolo Spurio Signed-off-by: Chris Wilson Cc: Daniele Ceraolo

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gtt: disable 2M pages for pre-gen11

Quoting Matthew Auld (2019-08-09 20:34:56) > We currently disable THP(Transparent-Huge-Pages) for our shmem objects > due to a performance regression with read BW in some internal > benchmarks. Given that this is our main source of 2M pages, there really > isn't much point in enabling 2M GTT

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gtt: enable GTT cache by default

Quoting Matthew Auld (2019-08-09 20:34:55) > For some platforms the GTT cache is by default not enabled, and > currently where we explicitly enable it, we make it conditional on 2M GTT > page support, since the BSpec states that we must disable it if we > enable 2M/1G pages. To make this more

[Intel-gfx] [PATCH 2/2] drm/i915/gtt: disable 2M pages for pre-gen11

We currently disable THP(Transparent-Huge-Pages) for our shmem objects due to a performance regression with read BW in some internal benchmarks. Given that this is our main source of 2M pages, there really isn't much point in enabling 2M GTT pages, especially this that comes at the cost of

[Intel-gfx] [PATCH 1/2] drm/i915/gtt: enable GTT cache by default

For some platforms the GTT cache is by default not enabled, and currently where we explicitly enable it, we make it conditional on 2M GTT page support, since the BSpec states that we must disable it if we enable 2M/1G pages. To make this more consistent opt for blanket enabling the GTT cache for

[Intel-gfx] ✓ Fi.CI.BAT: success for DC3CO Support for TGL (rev2)

== Series Details == Series: DC3CO Support for TGL (rev2) URL : https://patchwork.freedesktop.org/series/64923/ State : success == Summary == CI Bug Log - changes from CI_DRM_6668 -> Patchwork_13952 Summary --- **SUCCESS** No

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: split out uncore_mmio_debug

== Series Details == Series: drm/i915: split out uncore_mmio_debug URL : https://patchwork.freedesktop.org/series/64941/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6661_full -> Patchwork_13931_full Summary ---

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for DC3CO Support for TGL (rev2)

== Series Details == Series: DC3CO Support for TGL (rev2) URL : https://patchwork.freedesktop.org/series/64923/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/tgl: Add DC3CO required register and bits Okay! Commit: drm/i915/tgl: Add DC3CO

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for DC3CO Support for TGL (rev2)

== Series Details == Series: DC3CO Support for TGL (rev2) URL : https://patchwork.freedesktop.org/series/64923/ State : warning == Summary == $ dim checkpatch origin/drm-tip 15a54f3bbd2d drm/i915/tgl: Add DC3CO required register and bits fdc2aa531791 drm/i915/tgl: Add DC3CO mask to

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/4] drm/i915: Remove i915_gem_context_create_gvt()

== Series Details == Series: series starting with [CI,1/4] drm/i915: Remove i915_gem_context_create_gvt() URL : https://patchwork.freedesktop.org/series/64985/ State : success == Summary == CI Bug Log - changes from CI_DRM_6668 -> Patchwork_13951

Re: [Intel-gfx] [PATCH] drm/i915: Stop reconfiguring our shmemfs mountpoint

Quoting Matthew Auld (2019-08-09 19:47:02) > On Thu, 8 Aug 2019 at 18:23, Chris Wilson wrote: > > > > The filesystem reconfigure API is undergoing a transition, breaking our > > current code. As we only set the default options, we can simply remove > > the call to s_op->remount_fs(). In the

Re: [Intel-gfx] [PATCH] drm/i915: Stop reconfiguring our shmemfs mountpoint

On Thu, 8 Aug 2019 at 18:23, Chris Wilson wrote: > > The filesystem reconfigure API is undergoing a transition, breaking our > current code. As we only set the default options, we can simply remove > the call to s_op->remount_fs(). In the future, when HW permits, we can > try re-enabling huge

[Intel-gfx] [PATCH v5 9/9] drm/i915/tgl: Add DC3CO counter in i915_dmc_info

Adding DC3CO counter in i915_dmc_info debugfs will be useful for DC3CO validation. DMC firmware uses DMC_DEBUG3 register as DC3CO counter register on TGL, as per B.Specs DMC_DEBUG3 is general purpose register. Cc: Jani Nikula Cc: Imre Deak Cc: Animesh Manna Signed-off-by: Anshuman Gupta ---

[Intel-gfx] [PATCH v5 0/9] DC3CO Support for TGL

This revision is rebased on latest drm-tip as earlier v4 series had CI failures due to merge conflicts, there are no functional changes with this v5 series. one patch of this series "tgl-DC3CO-PSR2-helper" will require rebase after https://patchwork.freedesktop.org/series/62416/ series will

[Intel-gfx] [PATCH v5 2/9] drm/i915/tgl: Add DC3CO mask to allowed_dc_mask and gen9_dc_mask

Enable dc3co state in enable_dc module param and add dc3co enable mask to allowed_dc_mask and gen9_dc_mask. v1: Adding enable_dc=3,4 options to enable DC3CO with DC5 and DC6 independently. Cc: Jani Nikula Cc: Imre Deak Cc: Animesh Manna Signed-off-by: Anshuman Gupta ---

[Intel-gfx] [PATCH v5 8/9] drm/i915/tgl: switch between dc3co and dc5 based on display idleness

DC3CO is useful power state, when DMC detects PSR2 idle frame while an active video playback, playing 30fps video on 60hz panel is the classic example of this use case. DC5 and DC6 saves more power, but can't be entered during video playback because there are not enough idle frames in a row to

[Intel-gfx] [PATCH v5 7/9] drm/i915/tgl: DC3CO PSR2 helper

Add dc3co helper functions to enable/disable psr2 deep sleep. Disallow DC3CO state before PSR2 exit, it essentially does that by putting a reference to POWER_DOMAIN_VIDEO before PSR2 exit. Cc: Jani Nikula Cc: Imre Deak Cc: Animesh Manna Cc: José Roberto de Souza Signed-off-by: Anshuman Gupta

[Intel-gfx] [PATCH v5 3/9] drm/i915/tgl: Add power well to enable DC3CO state

"DC3CO Off" power well inherits its power domains from "DC Off" power well, these power domains will disallow DC3CO when any external displays are connected and at time of modeset and aux programming. Renaming "DC Off" power well to "DC5 Off" power well. v2: commit log improvement. v3: Used

[Intel-gfx] [PATCH v5 5/9] drm/i915/tgl: Add helper function to prefer dc3co over dc5

We need to have a S/W flag based upon which driver can switch to DC3CO. If it is only edp display connected and it has psr2 capability, then set a prefer_dc3co flag to true, which will be used to switch to dc3co as well as to program DC3CO PSR2 transcoder early exitline event. Cc: Jani Nikula

[Intel-gfx] [PATCH v5 6/9] drm/i915/tgl: Add VIDEO power domain

The Power domain name VIDEO is inspired from the fact that DC3CO should be enabled only during VIDEO playback. POWER_DOMAIN_VIDEO is a hook to "DC5 Off" power well, which can disallow DC5/6 and allow DC3CO. Cc: Jani Nikula Cc: Imre Deak Cc: Animesh Manna Signed-off-by: Anshuman Gupta ---

[Intel-gfx] [PATCH v5 1/9] drm/i915/tgl: Add DC3CO required register and bits

Adding following definition to i915_reg.h 1. DC_STATE_EN register DC3CO bit fields and masks. 2. Transcoder EXITLINE register and its bit fields and mask. Cc: Jani Nikula Cc: Imre Deak Cc: Animesh Manna Signed-off-by: Anshuman Gupta --- drivers/gpu/drm/i915/i915_reg.h | 8 1 file

[Intel-gfx] [PATCH v5 4/9] drm/i915/tgl: mutual exclusive handling for DC3CO and DC5/6

As per B.Specs DC5 and DC6 not allowed when DC3CO is enabled and DC3CO should be enabled only during VIDEO playback. Which essentially means both can DC5 and DC3CO can not be enabled at same time, it makes DC3CO and DC5 mutual exclusive. Cc: Jani Nikula Cc: Imre Deak Cc: Animesh Manna Cc:

[Intel-gfx] [CI 4/4] drm/i915: Lift timeline into intel_context

Move the timeline from being inside the intel_ring to intel_context itself. This saves much pointer dancing and makes the relations of the context to its timeline much clearer. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 35

[Intel-gfx] [CI 1/4] drm/i915: Remove i915_gem_context_create_gvt()

As we are phasing out using the GEM context for internal clients that need to manipulate logical context state directly, remove the constructor for the GVT context. We are not using it for anything other than default setup and allocation of an i915_ppgtt. Signed-off-by: Chris Wilson ---

[Intel-gfx] [CI 2/4] drm/i915/gt: Make deferred context allocation explicit

Refactor the backends to handle the deferred context allocation in a consistent manner, and allow calling it as an explicit first step in pinning a context for the first time. This should make it easier for backends to keep track of partially constructed contexts from initialisation.

[Intel-gfx] [CI 3/4] drm/i915: Push the ring creation flags to the backend

Push the ring creation flags from the outer GEM context to the inner intel_context to avoid an unsightly back-reference from inside the backend. Signed-off-by: Chris Wilson Reviewed-by: Andi Shyti --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 38 ---

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Remove i915_gem_context_create_gvt() (rev2)

== Series Details == Series: series starting with [1/4] drm/i915: Remove i915_gem_context_create_gvt() (rev2) URL : https://patchwork.freedesktop.org/series/64979/ State : success == Summary == CI Bug Log - changes from CI_DRM_6668 -> Patchwork_13950

Re: [Intel-gfx] [PATCH 00/34] put_user_pages(): miscellaneous call sites

> > On Wed 07-08-19 19:36:37, Ira Weiny wrote: > > On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote: > > > > So I think your debug option and my suggested renaming serve a bit > > > > different purposes (and thus both make sense). If you do the > > > > renaming, you can just grep to

Re: [Intel-gfx] screen freeze with 5.2-rc6 Dell XPS-13 skylake i915

Fix released on Linux 5.2.8 On Wed, 2019-07-24 at 22:39 +0200, Paul Bolle wrote: > Hi Jose, > > Souza, Jose schreef op wo 24-07-2019 om 20:27 [+]: > > We fixed the patch instead of revert it, it is merged on drm-tip > > and on > > his way to linux-stable. > > That should be (drm-tip) commit

[Intel-gfx] [PATCH] drm/i915/gt: Make deferred context allocation explicit

Refactor the backends to handle the deferred context allocation in a consistent manner, and allow calling it as an explicit first step in pinning a context for the first time. This should make it easier for backends to keep track of partially constructed contexts from initialisation.

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Check for a second VCS engine more carefully

== Series Details == Series: drm/i915: Check for a second VCS engine more carefully URL : https://patchwork.freedesktop.org/series/64938/ State : success == Summary == CI Bug Log - changes from CI_DRM_6660_full -> Patchwork_13930_full

  1   2   3   4   >