- 06 Sep, 2021 7 commits
-
-
Daniel Vetter authored
And use it anywhere we have open-coded checks for ctx->vm that really only check for full ppgtt. Plus for paranoia add a GEM_BUG_ON that checks it's really only set when we have full ppgtt, just in case. gem_context->vm is different since it's NULL in ggtt mode, unlike intel_context->vm or gt->vm, which is always set. v2: 0day found a testcase that I missed. v3: Repaint shed (Jon, Tvrtko) Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Jason Ekstrand <jason@jlekstrand.net> Link: https://patchwork.freedesktop.org/patch/msgid/20210902142057.929669-7-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Consolidates the "which is the vm my execbuf runs in" code a bit. We do some get/put which isn't really required, but all the other users want the refcounting, and I figured doing a function just for this getparam to avoid 2 atomis is a bit much. Reviewed-by:
-
Daniel Vetter authored
The important part isn't so much that this does an rcu lookup - that's more an implementation detail, which will also be removed. The thing that makes this different from other functions is that it's gettting you the vm that batchbuffers will run in for that gem context, which is either a full ppgtt stored in gem->ctx, or the ggtt. We'll make more use of this function later on. Reviewed-by:
-
Daniel Vetter authored
Changing the vm from a finalized gem ctx is no longer possible, which means we don't have to check for that anymore. I was pondering whether to keep the check as a WARN_ON, but things go boom real bad real fast if the vm of a vma is wrong. Plus we'd need to also get the ggtt vm for !full-ppgtt platforms. Ditching it all seemed like a better idea. Reviewed-by:
-
Daniel Vetter authored
The comment added in commit b81dde71 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue May 21 22:11:29 2019 +0100 drm/i915: Allow userspace to clone contexts on creation and moved in commit 27dbae8f Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Nov 6 09:13:12 2019 +0000 drm/i915/gem: Safely acquire the ctx->vm when copying suggested that i915_address_space were at least intended to be managed through SLAB_TYPESAFE_BY_RCU: * This ppgtt may have be reallocated between * the read and the kref, and reassigned to a third * context. In order to avoid inadvertent sharing * of this ppgtt with that third context (and not * src), we have to confirm that we have the same * ppgtt after passing through the strong memory * barrier implied by a successful * kref_get_unless_zero(). But extensive git history search has not brough any such reuse to light. What has come to light though is that ever since commit 2850748e Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Oct 4 14:39:58 2019 +0100 drm/i915: Pull i915_vma_pin under the vm->mutex (yes this commit is earlier) the final i915_vma_put call has been moved from i915_gem_context_free (now called _release) to context_close, which means it's not actually safe anymore to access the ctx->vm pointer without lock helds, because it might disappear at any moment. Note that superficially things all still work, because the i915_address_space is RCU protected since commit b32fa811 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Jun 20 19:37:05 2019 +0100 drm/i915/gtt: Defer address space cleanup to an RCU worker except the very clever macro above (which is designed to protected against object reuse due to SLAB_TYPESAFE_BY_RCU or similar tricks) results in an endless loop if the refcount of the ctx->vm ever permanently drops to 0. Which it totally now can. Fix that by moving the final i915_vm_put to where it should be. Note that i915_gem_context is rcu protected, but _only_ the final kfree. This means anyone who chases a pointer to a gem ctx solely under the protection can pretty only call kref_get_unless_zero(). This seems to be pretty much the case, aside from a bunch of cases that consult the scheduling information without any further protection. Reviewed-by: -
Daniel Vetter authored
gem context refcounting is another exercise in least locking design it seems, where most things get destroyed upon context closure (which can race with anything really). Only the actual memory allocation and the locks survive while holding a reference. This tripped up Jason when reimplementing the single timeline feature in commit 00dae4d3 Author: Jason Ekstrand <jason@jlekstrand.net> Date: Thu Jul 8 10:48:12 2021 -0500 drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4) We could fix the bug by holding ctx->mutex in execbuf and clear the pointer (again while holding the mutex) context_close, but it's cleaner to just make the context object actually invariant over its _entire_ lifetime. This way any other ioctl that's potentially racing, but holding a full reference, can still rely on ctx->syncobj being an immutable pointer. Which without this change, is not the case. Reviewed-by:
-
Daniel Vetter authored
The only reason for this really is the i915_gem_engines->fence callback engines_notify(), which exists purely as a fairly funky reference counting scheme for that. Otherwise all other callers are from process context, and generally fairly benign locking context. Unfortunately untangling that requires some major surgery, and we have a few i915_gem_context reference counting bugs that need fixing, and they blow in the current hardirq calling context, so we need a stop-gap measure. Put a FIXME comment in when this should be removable again. v2: Fix mock_context(), noticed by intel-gfx-ci. Acked-by:
-
- 03 Sep, 2021 5 commits
-
-
Sreedhar Telukuntla authored
Initialize the L3CC table as part of mocs initialization to program LNCFCMOCSx registers so that the mocs settings are available for selection for subsequent memory transactions in the driver load path. We need to keep L3CC initialization in intel_mocs_init_engine() also so that in execlists submission, these registers can be rewritten during engine reset. Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Sreedhar Telukuntla <sreedhar.telukuntla@intel.com> Signed-off-by:
Ayaz A Siddiqui <ayaz.siddiqui@intel.com> Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210903092153.535736-6-ayaz.siddiqui@intel.com
-
Ayaz A Siddiqui authored
Historically we've initialized all undefined/reserved entries in a platform's MOCS table to the contents of table entry #1 (i.e., I915_MOCS_PTE). Going forward, we can't assume that table entry #1 will always contain suitable values to use for undefined/reserved table indices. We'll allow a platform-specific table index to be selected at table initialization time in these cases. This new mechanism to select L3 WB entry will be applicable for all the Gen12+ platforms except TGL and RKL. Since TGL and RLK are already in production so their mocs settings are intact to avoid ABI break. Reviewed-by:
-
Ayaz A Siddiqui authored
Blitter commands which do not have MOCS fields rely on cacheability of BlitterCacheControlRegister which was mapped to index 0 by default.Once we changed the MOCS value of index 0 to L3 WB, tests like gem_linear_blits started failing due to a change in cacheability from UC to WB. Program and place the BlitterCacheControlRegister in build_aux_regs(). Reviewed-by:
-
Ayaz A Siddiqui authored
Cache-control registers for Command Stream(CMD_CCTL) are used to set catchability for memory writes and reads outputted by Command Streamers on Gen12 onward platforms. These registers need to point un-cached(UC) MOCS index. Reviewed-by:
-
Ayaz A Siddiqui authored
Now there are lots of Command and registers that require mocs index programming. So propagating mocs_index from mocs to gt so that it can be used directly without having platform-specific checks. V2: Changed 'i915_mocs_index_gt' to anonymous structure. Cc: CQ Tang<cq.tang@intel.com> Reviewed-by:
-
- 02 Sep, 2021 1 commit
-
-
Thomas Hellström authored
Using the I915_MMAP_TYPE_FIXED mmap type requires the TTM backend, so for that mmap type, use __i915_gem_object_create_user() instead of i915_gem_object_create_internal(), as we really want to tests objects mmap-able by user-space. This also means that the out-of-space error happens at object creation and returns -ENXIO rather than -ENOSPC, so fix the code up to expect that on out-of-offset-space errors. Finally only use I915_MMAP_TYPE_FIXED for LMEM and SMEM for now if testing on LMEM-capable devices. For stolen LMEM, we still take the same path as for integrated, as that haven't been moved over to TTM yet, and user-space should not be able to create out of stolen LMEM anyway. v2: - Check the presence of the obj->ops->mmap_offset callback rather than hardcoding the supported mmap regions in can_mmap() (Maarten Lankhorst) Fixes: 7961c5b6 ("drm/i915: Add TTM offset argument to mmap.") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
-
- 31 Aug, 2021 1 commit
-
-
Daniele Ceraolo Spurio authored
The function is only used from within GEM_BUG_ON(), which is causing warnings with Wunneeded-internal-declaration in some builds. Since the function is a simple wrapper around a CT function, we can just call the CT function directly instead. Fixes: 1fb12c58 ("drm/i915/guc: skip disabling CTBs before sanitizing the GuC") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210823163137.19770-1-daniele.ceraolospurio@intel.com
-
- 27 Aug, 2021 2 commits
-
-
Daniel Vetter authored
In commit 8e02cceb ("drm/i915: delete gpu reloc code") I deleted the gpu relocation code and the selftest include and enabling, but accidentally forgot about the selftest source code. Fix this oversight. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Matt Roper authored
A recent restructuring of our context workaround list initialization added an early return for non-render engines; this caused us to potentially miss the wa_init_finish() call at the end of the function. The mistake is pretty harmless --- the only impact is that non-render engines on graphics version 12.50+ platforms we don't trim down the workaround list to reclaim some memory, and we don't print the usual "Initialized 1 context workaround" message in dmesg. Let's change the early return to a jump down to the wa_init_finish() call at the bottom of the function. Reported-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Fixes: 9e9dfd08 ("drm/i915/dg2: Maintain backward-compatible nested batch behavior") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210826033559.1209020-1-matthew.d.roper@intel.com
-
- 26 Aug, 2021 1 commit
-
-
Jani Nikula authored
Follow the usual naming conventions. While at it, fix i915_pci.h SPDX license comment format and add header include guards. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210825150623.28980-1-jani.nikula@intel.com
-
- 25 Aug, 2021 4 commits
-
-
Thomas Hellström authored
The buffer object argument to ttm_move_memcpy was only used to determine whether the destination memory should be cleared only or whether we should copy data. Replace it with a "clear" bool, and update the callers. The intention here is to be able to use ttm_move_memcpy() async under a dma-fence as a fallback if an accelerated blit fails in a security- critical path where data might leak if the blit is not properly performed. For that purpose the bo is an unsuitable argument since its relevant members might already have changed at call time. Finally, update the ttm_move_memcpy kerneldoc that seems to have ended up with a stale version. Cc: Christian König <christian.koenig@amd.com> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20210813144331.372957-3-thomas.hellstrom@linux.intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20210813144331.372957-3-thomas.hellstrom@linux.intel.com
-
Thomas Hellström authored
In order to make the code a bit more readable and to facilitate async memcpy moves, reorganize the move code a little. Determine at an early stage whether to copy or to clear. v2: - Don't set up the memcpy iterators unless we are actually going to memcpy. Signed-off-by:
-
Akeem G Abodunrin authored
New LRI register offsets were introduced for DG2, this patch adds those extra registers, and create new register table for setting offsets to compare with HW generated context image - especially for gt_lrc test. Also updates general purpose register with scratch offset for DG2, in order to use it for live_lrc_fixed selftest. Cc: Chris P Wilson <chris.p.wilson@intel.com> Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Signed-off-by:
Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Signed-off-by:
Caz Yokoyama <caz.yokoyama@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210805163647.801064-8-matthew.d.roper@intel.com
-
Matthew Brost authored
Like in the case of several other selftests, generating lots of requests in a loop takes a bit longer with GuC submission. Increase a timeout in i915_gem_contexts selftest to take this into account. Signed-off-by:
-
- 24 Aug, 2021 2 commits
-
-
Ville Syrjälä authored
Use NULL where appropriate. drivers/gpu/drm/i915/gt/intel_ring_submission.c:1210:24: warning: Using plain integer as NULL pointer Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210712161815.24776-2-ville.syrjala@linux.intel.comReviewed-by:
-
Nathan Chancellor authored
Clang warns: In file included from drivers/gpu/drm/i915/gt/intel_reset.c:1514: drivers/gpu/drm/i915/gt/selftest_hangcheck.c:465:62: warning: variable 'err' is uninitialized when used here [-Wuninitialized] pr_err("[%s] Create context failed: %d!\n", engine->name, err); ^~~ ... drivers/gpu/drm/i915/gt/selftest_hangcheck.c:580:62: warning: variable 'err' is uninitialized when used here [-Wuninitialized] pr_err("[%s] Create context failed: %d!\n", engine->name, err); ^~~ ... 2 warnings generated. This appears to be a copy and paste issue. Use ce directly using the %pe specifier to pretty print the error code so that err is not used uninitialized in these functions. Fixes: 3a7b7266 ("drm/i915/selftest: Bump selftest timeouts for hangcheck") Reported-by:Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
- 20 Aug, 2021 5 commits
-
-
Lucas De Marchi authored
This was added in commit 05e26584 ("drm/i915/dg1: add initial DG-1 definitions") so we could continue to add support for DG1 without risk to expose a broken UAPI. Now that we added DG1 to the PCI ID list i915 may bind to, remove the leftover. Fixes: d5ef86b3 ("drm/i915: Add pci ids and uapi for DG1") Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Dan Carpenter authored
If the intel_engine_create_pinned_context() function returns an error pointer, then dereferencing "ce" will Oops. Use "vm" instead of "ce->vm". Fixes: cf586021 ("drm/i915/gt: Pipelined page migration") Signed-off-by:
-
Matthew Auld authored
This should give a more complete view of the various bits of internal resource manager state, for device local-memory. v2(Thomas): - Move the region printing into a nice helper Signed-off-by:
-
Matthew Auld authored
Implement the debug hook for the buddy resource manager. For this we want to print out the status of the memory manager, including how much memory is still allocatable, what page sizes we have etc. This will be triggered when TTM is unable to fulfil an allocation request for device local-memory. v2(Thomas): - s/MB/MiB - s/KB/KiB Signed-off-by: -
Thomas Hellström authored
It's only used by the for_i915_gem_ww() macro and we can use the (typically) on-stack _err variable in its place. v2: - Don't clear the _err variable when entering the loop (Matthew Auld, Maarten Lankhorst). - Use parentheses around the _err macro argument. - Fix up comment. Cc: Matthew Auld <matthew.william.auld@gmail.com> Suggested-by:
-
- 19 Aug, 2021 1 commit
-
-
Matthew Brost authored
A small race exists between intel_gt_retire_requests_timeout and intel_timeline_exit which could result in the syncmap not getting free'd. Rather than work to hard to seal this race, simply cleanup the syncmap on fini. unreferenced object 0xffff88813bc53b18 (size 96): comm "gem_close_race", pid 5410, jiffies 4294917818 (age 1105.600s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 0a 00 00 00 ................ 00 00 00 00 00 00 00 00 6b 6b 6b 6b 06 00 00 00 ........kkkk.... backtrace: [<00000000120b863a>] __sync_alloc_leaf+0x1e/0x40 [i915] [<00000000042f6959>] __sync_set+0x1bb/0x240 [i915] [<0000000090f0e90f>] i915_request_await_dma_fence+0x1c7/0x400 [i915] [<0000000056a48219>] i915_request_await_object+0x222/0x360 [i915] [<00000000aaac4ee3>] i915_gem_do_execbuffer+0x1bd0/0x2250 [i915] [<000000003c9d830f>] i915_gem_execbuffer2_ioctl+0x405/0xce0 [i915] [<00000000fd7a8e68>] drm_ioctl_kernel+0xb0/0xf0 [drm] [<00000000e721ee87>] drm_ioctl+0x305/0x3c0 [drm] [<000000008b0d8986>] __x64_sys_ioctl+0x71/0xb0 [<0000000076c362a4>] do_syscall_64+0x33/0x80 [<00000000eb7a4831>] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by:
-
- 18 Aug, 2021 2 commits
-
-
Matt Roper authored
For tgl+, the per-context setting of MI_MODE[12] determines whether the bits of a nested MI_BATCH_BUFFER_START instruction should be interpreted in the traditional manner or whether they should instead use a new tgl+ meaning that breaks backward compatibility, but allows nesting into 3rd-level batchbuffers. For previous platforms, the hardware default for this register bit is to maintain backward-compatible behavior unless a context intentionally opts into the new behavior; however Xe_HPG flips the hardware default behavior. From a SW perspective, we want to maintain the backward-compatible behavior for userspace, so we'll apply a fake workaround to set it back to the legacy behavior on platforms where the hardware default is to break compatibility. At the moment there is no Linux userspace that utilizes third-level batchbuffers, so this will avoid userspace from needing to make any changes. using the legacy meaning is the correct thing to do. If/when we have userspace consumers that want to utilize third-level batch nesting, we can provide a context parameter to allow them to opt-in. Bspec: 45974, 45718 Cc: John Harrison <John.C.Harrison@Intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com>
-
Kees Cook authored
The kernel builds with -Werror=designated-init, and __designated_init is used by CONFIG_GCC_PLUGIN_RANDSTRUCT for automatically selected (all function pointer) structures. Include the field names in the init/exit table. Avoids warnings like: drivers/gpu/drm/i915/i915_module.c:59:4: error: positional initialization of field in 'struct' declared with 'designated_init' attribute [-Werror=designated-init] Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: David Airlie <airlied@linux.ie> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Fixes: a04ea6ae ("drm/i915: Use a table for i915_init/exit (v2)") Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210817233357.2379455-1-keescook@chromium.org
-
- 13 Aug, 2021 1 commit
-
-
Maarten Lankhorst authored
DG1 has support for local memory, which requires the usage of the lmem placement extension for creating bo's, and memregion queries to obtain the size. Because of this, those parts of the uapi are no longer guarded behind FAKE_LMEM. According to the pull request referenced below, mesa should be mostly ready for DG1. VK_EXT_memory_budget is not hooked up yet, but we should definitely just enable the uapi parts by default. Signed-off-by:
Jason Ekstrand <jason@jlekstrand.net>
-
- 12 Aug, 2021 3 commits
-
-
Matt Roper authored
The RP_STATE_CAP register is no longer part of the MCHBAR on XEHPSDV; this register is now a per-tile register at GTTMMADDR offset 0x250014. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Instead of maintaining the same if ladder in 3 different places, add a function to read RP_STATE_CAP. Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210805163647.801064-6-matthew.d.roper@intel.com
-
Daniel Vetter authored
This essentially reverts commit 89ff76bf Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Apr 2 13:42:18 2020 +0100 drm/i915/gem: Utilize rcu iteration of context engines Note that the other use of __context_engines_await have disappeard in the following commits: ccbc1b97 ("drm/i915/gem: Don't allow changing the VM on running contexts (v4)") c7a71fc8 ("drm/i915: Drop getparam support for I915_CONTEXT_PARAM_ENGINES") 4a766ae4 ("drm/i915: Drop the CONTEXT_CLONE API (v2)") None of these have any business to optimize their engine lookup with rcu, unless extremely convincing benchmark data and a solid analysis why we can't make that workload (whatever it is that does) faster with a proper design fix. Also since there's only one caller of context_apply_all left and it's really just a loop, inline it and then inline the lopp body too. This is how all other callers that take the engine lock loop over engines, it's much simpler. Reviewed-by:
-
- 11 Aug, 2021 4 commits
-
-
Stuart Summers authored
Starting in XeHP, the concept of slice has been removed in favor of DSS (Dual-Subslice) masks for various workload types. These workloads have been divided into those enabled for geometry and those enabled for compute. i915 currently maintains a single set of S/SS/EU masks for the device. The goal of this patch set is to minimize the amount of impact to prior generations while still giving the user maximum flexibility. v2: - Generalize a comment about uapi access to geometry/compute masks; the proposed uapi has changed since the comment was first written, and will show up in a future series once the userspace code is published. (Lucas) v3: - Eliminate unnecessary has_compute_dss flag. (Lucas) - Drop unwanted comment change in uapi header. (Lucas) Bspec: 33117, 33118, 20376 Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Stuart Summers <stuart.summers@intel.com> Signed-off-by:
Steve Hampson <steven.t.hampson@intel.com> Signed-off-by:
-
Matt Roper authored
Xe_HPG adds some additional INSTDONE_GEOM debug registers; the Mesa team has indicated that having these reported in the error state would be useful for debugging GPU hangs. These registers are replicated per-DSS with gslice steering. Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
Matt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210805163647.801064-4-matthew.d.roper@intel.com
-
Matt Roper authored
We no longer have traditional slices on Xe_HP platforms, but the INSTDONE registers are replicated according to gslice representation which is similar. We can mostly re-use the existing instdone code with just a few modifications: * Create an alternate instdone loop macro that will iterate over the flat DSS space, but still provide the gslice/dss steering values for compatibility with the legacy code. * We should allocate INSTDONE storage space according to the maximum number of gslices rather than the maximum number of legacy slices to ensure we have enough storage space to hold all of the values. XeHP design has 8 gslices, whereas older platforms never had more than 3 slices. Signed-off-by:
-
Daniel Vetter authored
We still have quite a bit more work to do with overall reworking of the ttm-based dg1 code, but the uapi stuff is now finalized with the latest pull. So remove that. This also fixes kerneldoc build warnings because we've included the same headers in two places, resulting in sphinx complaining about duplicated symbols. This regression has been created when we moved the uapi definitions to the real include/uapi/ folder in 727ecd99 ("drm/doc/rfc: drop the i915_gem_lmem.h header") v2: Fix a few references that I missed, the htmldocs build took forever. Acked-by:
Stephen Rothwell <sfr@canb.auug.org.au> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Fixes: 727ecd99 ("drm/doc/rfc: drop the i915_gem_lmem.h header") Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
- 10 Aug, 2021 1 commit
-
-
Matt Roper authored
The list of shadowed registers on XeHP is identical to the set for earlier gen12 platforms, with additional ranges added for the new VCS and VECS engines. Since those register ranges were reserved on earlier gen12 platforms, it's safe to consolidate to a single gen12 table rather than tracking Xe_HP separately. Bspec: 52077 Signed-off-by:
-
