- 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:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-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:
Matt Roper <matthew.d.roper@intel.com> Reviewed-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:
Matthew Brost <matthew.brost@intel.com> Reviewed-by:
John Harrison <John.C.Harrison@Intel.com> 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:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210819210349.95103-1-lucas.demarchi@intel.com
-
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:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210813113600.GC30697@kili
-
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:
Daniel Vetter <daniel.vetter@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210810130523.1972031-1-daniel.vetter@ffwll.ch
-
- 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 6 commits
-
-
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:
-
Matt Roper authored
The bspec lists many shadowed registers (i.e., registers for which we don't need to grab forcewake when writing) that we weren't tracking in the driver. Although we may not actually use all of these registers right now, it's best to just match the bspec list exactly. Note that the bspec also lists registers that are shadowed for various HW-internal accesses; we can ignore those and just list the ones that are shadowed for accesses from the IA/CPU. Bspec: 52077 Signed-off-by:
-
Matt Roper authored
The bspec lists many shadowed registers (i.e., registers for which we don't need to grab forcewake when writing) that we weren't tracking in the driver. Although we may not actually use all of these registers right now, it's best to just match the bspec list exactly. Note that the bspec also lists registers that are shadowed for various HW-internal accesses; we can ignore those and just list the ones that are shadowed for accesses from the IA/CPU. Bspec: 18333 Signed-off-by:
-
Matt Roper authored
Rather than defining our shadow tables as a list of individual registers, provide them as a list of register ranges; we'll have some ranges of multiple registers being added soon (and we already have a couple adjacent registers that we can squash into a single range now). This change also defines the table with hex literal values rather than symbolic register names; since that's how the tables are defined in the bspec, this change will make it easier to review the tables overall. v2: - Force signed comparison on range overlap sanity check Signed-off-by:
-
Matt Roper authored
The forcewake read logic is identical between gen11 and gen12, only the forcewake table data (which is tracked separately) differs; there's no need to generate a separate set of gen12 read functions when the gen11 functions will work just as well. We'll keep the separate write functions for now since the generated code directly references different shadow tables between the two platforms. Signed-off-by:
-
Matt Roper authored
For historical reasons, the GT forcewake domain used to be referred to as the "blitter" domain; that name is no longer accurate since the GT domain contains a lot of additional registers and functionality besides just the blitter. Although we renamed the domain in the driver in commit 55e3c170 ("drm/i915: Rename FORCEWAKE_BLITTER to FORCEWAKE_GT"), we neglected to update the string that gets printed in driver error messages; let's do that now to avoid confusion. Signed-off-by:
-
- 07 Aug, 2021 1 commit
-
-
Matthew Brost authored
Disable bonding on gen12+ platforms aside from ones already supported by the i915 - TGL, RKL, and ADL-S. Signed-off-by:
-
- 05 Aug, 2021 5 commits
-
-
Matt Roper authored
Although DG2_G10 platforms will always have all SQIDI's present and don't need steering for registers in a SQIDI MMIO range, this isn't true for DG2_G11 platforms; only SQIDI's 2 and 3 can be used on those. We handle SQIDI ranges a bit differently from other types of explicit steering. The SQIDI ranges belong to either the MCFG unit or the SF unit, both of which have their own dedicated steering registers and do not use the typical 0xFDC steering control that all other types of ranges use. Thus we only need to worry about picking a valid initial value for the MCFG and SF steering registers (0xFD0 and 0xFD8 respectively) at driver init; they won't change after we set them up so we don't need to worry about re-steering them explicitly at runtime. Given that any SQIDI value should work fine for DG2-G10 and XeHP SDV, while only values of 2 and 3 are valid for DG2-G11, we'll just initialize the MCFG and SF steering registers to a constant value of "2" for all XeHP-based platforms for simplicity --- that will work in all cases. Bspec: 66534 Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
-
Matt Roper authored
DG2's replicated register ranges are almost the same at XeHP SDV with the exception of one LNCF sub-range that switches to gslice steering. We can re-use the XeHP SDV mslice steering table and just provide a DG2-specific LNCF steering table. Bspec: 66534 Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Matt Roper authored
Define and initialize the MMIO ranges for which XeHP SDV requires MSLICE and LNCF steering. Bspec: 66534 Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
Xe_HP is more modular than its predecessors and as a consequence it has more types of replicated registers. As with l3bank regions on previous platforms, we may need to explicitly re-steer accesses to these new types of ranges at runtime if we can't find a single default steering value that satisfies the fusing of all types. v2: - Add a local 'i915' variable to reduce gt->i915 usage. (Caz) - Drop unused 'intel_gt_read_register' prototype. (Caz) v3: - Drop unnecessary comment text. (Lucas) - Drop unused register bit definition. (Lucas) Bspec: 66534 Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Caz Yokoyama <caz.yokoyama@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Chris Wilson authored
Jason Ekstrand requested a more efficient method than userptr+set-domain to determine if the userptr object was backed by a complete set of pages upon creation. To be more efficient than simply populating the userptr using get_user_pages() (as done by the call to set-domain or execbuf), we can walk the tree of vm_area_struct and check for gaps or vma not backed by struct page (VM_PFNMAP). The question is how to handle VM_MIXEDMAP which may be either struct page or pfn backed... With discrete we are going to drop support for set_domain(), so offering a way to probe the pages, without having to resort to dummy batches has been requested. v2: - add new query param for the PROBE flag, so userspace can easily check if the kernel supports it(Jason). - use mmap_read_{lock, unlock}. - add some kernel-doc. v3: - In the docs also mention that PROBE doesn't guarantee that the pages will remain valid by the time they are actually used(Tvrtko). - Add a small comment for the hole finding logic(Jason). - Move the param next to all the other params which just return true. Testcase: igt/gem_userptr_blits/probe Signed-off-by:Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by:
-
- 04 Aug, 2021 6 commits
-
-
Daniel Vetter authored
It's already removed, this just garbage collects it all. v2: Rebase over s/GEN/GRAPHICS_VER/ v3: Also ditch eb.reloc_pool and eb.reloc_context (Maarten) Reviewed-by:
-
Daniel Vetter authored
Media userspace was the last userspace to still use them, and they converted now too: https://github.com/intel/media-driver/commit/144020c37770083974bedf59902b70b8f444c799 This means no reason anymore to make relocations faster than they've been for the first 9 years of gem. This code was added in commit 7dd4f672 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Jun 16 15:05:24 2017 +0100 drm/i915: Async GPU relocation processing Furthermore there's pretty strong indications it's buggy, since the code to use it by default as the only option had to be reverted: commit ad5d95e4 Author: Dave Airlie <airlied@redhat.com> Date: Tue Sep 8 15:41:17 2020 +1000 Revert "drm/i915/gem: Async GPU relocations only" This code just disables gpu relocations, leaving the garbage collection for later patches and more importantly, much less confusing diff. Also given how much headaches this code has caused in the past, letting this soak for a bit seems justified. Acked-by:
Dave Airlie <airlied@redhat.com> Reviewed-by:
-
Matt Roper authored
DG2 supports compute DSS and has the same maximum number of DSS and EU as XeHP SDV. Signed-off-by:
-
Matt Roper authored
Due to the removal of legacy slices and the transition to a gslice/cslice/mslice/etc. design, we'll internally store all DSS under "slice0." Signed-off-by:
-
Matthew Auld authored
Xe_HP no longer has "slices" in the same way that old platforms did. There are new concepts (gslices, cslices, mslices) that apply in various contexts, but for the purposes of fusing slices no longer exist and we just have one large pool of dual-subslices (DSS) to work with. Furthermore, the meaning of the DSS fuse is inverted compared to past platforms --- it now specifies which DSS are enabled rather than which ones are disabled. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
Prasad Nallani <prasad.nallani@intel.com> Reviewed-by:
-
Matt Roper authored
The DG2 forcewake table is very similar to the one used by XeHP SDV (and both platforms are even presented as a single table in the bspec). For the most part DG2 starts using a few additional ranges that were 'reserved' on XeHP SDV and stops using some others. However there is a single range (0xd800-0xd87f) that needs to be handled differently between the two platforms (it needs GT wake on XeHP SDV, but render wake on DG2) so unless we want to wake both domains (which could waste power) or define new types of forcewake domains for this special case we need to have separate tables for the two platforms. Let's define the ranges for both platforms with a parameterized macro so that we don't actually need to duplicate everything in the code. It should be fine for DG2 to re-use the Xe_HP shadow register list so we can continue to use the 'xehpsdv' MMIO write functions and don't need to spin up a separate DG2 instance. Bspec: 66534 Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
