- 17 Mar, 2023 3 commits
-
-
Fei Yang authored
On MTL, objects allocated through i915_gem_object_create_internal() are mapped as uncached in GPU by default because HAS_LLC is false. However in the live_hwsp_read selftest these watcher objects are mapped as WB on CPU side. The conseqence is that the updates done by the GPU are not immediately visible to CPU, thus the selftest is randomly failing due to the stale data in CPU cache. Solution can be either setting WC for CPU + UC for GPU, or WB for CPU + 1-way coherent WB for GPU. To keep the consistency, let's simply inherit the same cache settings from the timeline, which is WB for CPU + 1-way coherent WB for GPU, because this test is supposed to emulate the behavior of the timeline anyway. Signed-off-by:
Fei Yang <fei.yang@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Andrzej Hajda authored
Probe pseudo errors should be injected only in places where real errors can be encountered, otherwise unwinding code can be broken. Placing intel_uc_init_late before i915_inject_probe_error violated this rule, resulting in following bug: __intel_gt_disable:655 GEM_BUG_ON(intel_gt_pm_is_awake(gt)) Fixes: 481d458c ("drm/i915/guc: Add golden context to GuC ADS") Acked-by:
Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230314151920.1065847-1-andrzej.hajda@intel.com
-
Tvrtko Ursulin authored
No need to look at the mask of present engines when we already have a count stored ever since e2d0ff35 ("drm/i915: Count engine instances per uabi class"). Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by:
-
- 16 Mar, 2023 4 commits
-
-
Andrzej Hajda authored
Write-combining memory allows speculative reads by CPU. ggtt->error_capture is WC mapped to CPU, so CPU/MMU can try to prefetch memory beyond the error_capture, ie it tries to read memory pointed by next PTE in GGTT. If this PTE points to invalid address DMAR errors will occur. This behaviour was observed on ADL and RPL platforms. To avoid it, guard scratch page should be added after error_capture. The patch fixes the most annoying issue with error capture but since WC reads are used also in other places there is a risk similar problem can affect them as well. v2: - modified commit message (I hope the diagnosis is correct), - added bug checks to ensure scratch is initialized on gen3 platforms. CI produces strange stacktrace for it suggesting scratch[0] is NULL, to be removed after resolving the issue with gen3 platforms. v3: - removed bug checks, replaced with gen check. v4: - change code for scratch page insertion to support all platforms, - add info in commit message there could be more similar issues v5: - check for nop_clear_range instead of gen8 (Tvrtko), - re-insert scratch pages on resume (Tvrtko) v6: - use scratch_range callback to set scratch pages (Chris) Reviewed-by: -
Andrzej Hajda authored
The callback will be responsible for setting scratch page PTEs for specified range. In contrast to clear_range it cannot be optimized to nop. It will be used by code adding guard pages. Reviewed-by:
-
Andrzej Hajda authored
Tests on DG2 machines show that releasing forcewakes during BAR resize results later in forcewake ack timeouts. Since forcewakes can be realeased asynchronously the simplest way to prevent it is to get all forcewakes for duration of BAR resizing. v2: hold rpm as well during resizing (Rodrigo) Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6530 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7853Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by:
-
Nirmoy Das authored
Change the function doc to reflect updated name. v2: un-kerneldoc the comment(Matt). :s/engines_init_common/engine_init_common(Andi) Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
- 15 Mar, 2023 1 commit
-
-
Jani Nikula authored
There's no need for any of these to be mutable, constify: drivers/gpu/drm/i915/gt/sysfs_engines.o: .data 0000000000000020 files.0 drivers/gpu/drm/i915/gt/sysfs_engines.o: .data 0000000000000050 files.1 drivers/gpu/drm/i915/gt/sysfs_engines.o: .data 0000000000000038 preempt_timeout_attr drivers/gpu/drm/i915/gt/sysfs_engines.o: .data 0000000000000038 timeslice_duration_attr drivers/gpu/drm/i915/gt/sysfs_engines.o: .data 0000000000000038 timeslice_duration_def drivers/gpu/drm/i915/gt/sysfs_engines.o: .data 0000000000000038 preempt_timeout_def drivers/gpu/drm/i915/gt/sysfs_engines.o: .data 0000000000000038 max_spin_def drivers/gpu/drm/i915/gt/sysfs_engines.o: .data 0000000000000038 stop_timeout_def drivers/gpu/drm/i915/gt/sysfs_engines.o: .data 0000000000000038 heartbeat_interval_def drivers/gpu/drm/i915/gt/sysfs_engines.o: .data 0000000000000038 name_attr drivers/gpu/drm/i915/gt/sysfs_engines.o: .data 0000000000000038 class_attr drivers/gpu/drm/i915/gt/sysfs_engines.o: .data 0000000000000038 inst_attr drivers/gpu/drm/i915/gt/sysfs_engines.o: .data 0000000000000038 mmio_attr drivers/gpu/drm/i915/gt/sysfs_engines.o: .data 0000000000000038 caps_attr drivers/gpu/drm/i915/gt/sysfs_engines.o: .data 0000000000000038 all_caps_attr drivers/gpu/drm/i915/gt/sysfs_engines.o: .data 0000000000000038 max_spin_attr drivers/gpu/drm/i915/gt/sysfs_engines.o: .data 0000000000000038 stop_timeout_attr drivers/gpu/drm/i915/gt/sysfs_engines.o: .data 0000000000000038 heartbeat_interval_attr Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
- 14 Mar, 2023 4 commits
-
-
Nirmoy Das authored
debug_active_activate() expected ref->count to be zero which is not true anymore as __i915_active_activate() calls debug_active_activate() after incrementing the count. v2: No need to check for "ref->count == 1" as __i915_active_activate() already make sure of that(Janusz). References: https://gitlab.freedesktop.org/drm/intel/-/issues/6733 Fixes: 04240e30 ("drm/i915: Skip taking acquire mutex for no ref->active callback") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Thomas Hellström <thomas.hellstrom@intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.10+ Signed-off-by:
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Reviewed-by:
-
John Harrison authored
The seqno value actually written out to memory is no longer in the regular HWSP. Instead, it is now in its own private timeline buffer. Thus, it is no longer visible in an error capture. So, explicitly read the value and include that in the capture. v2: %d -> %u (Alan) Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Reviewed-by:
Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230311063714.570389-4-John.C.Harrison@Intel.com
-
John Harrison authored
The comparison in the search for a matching register capture node was not the most readable. It was also assuming that a zero GuC id means invalid, which it does not. So remove one invalid term, one redundant term and re-format to keep each term on a single line, and only one term per line. Signed-off-by:
-
John Harrison authored
Error captures are tagged with an 'ecode'. This is a pseduo-unique magic number that is meant to distinguish similar seeming bugs with different underlying signatures. It is a combination of two ring state registers. Unfortunately, the register state being used is only valid in execlist mode. In GuC mode, the register state exists in a separate list of arbitrary register address/value pairs rather than the named entry structure. So, search through that list to find the two exciting registers and copy them over to the structure's named members. v2: if else if instead of if if (Alan) Signed-off-by:
-
- 13 Mar, 2023 1 commit
-
-
Badal Nilawar authored
The Wa_14017073508 require to send Media Busy/Idle mailbox while accessing Media tile. As of now it is getting handled while __gt_unpark, __gt_park. But there are various corner cases where forcewakes are taken without __gt_unpark i.e. without sending Busy Mailbox especially during register reads. Forcewakes are taken without busy mailbox leads to GPU HANG. So bringing mailbox calls under forcewake calls are no feasible option as forcewake calls are atomic and mailbox calls are blocking. The issue already fixed in B step so disabling MC6 on A step and reverting previous commit which handles Wa_14017073508 Fixes: 8f70f1ec ("drm/i915/mtl: Add Wa_14017073508 for SAMedia") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Badal Nilawar <badal.nilawar@intel.com> Reviewed-by:
Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230310061339.2495416-2-badal.nilawar@intel.com
-
- 11 Mar, 2023 4 commits
-
-
Lucas De Marchi authored
Use gt_tuning_settings() for the recommended tunings rather than the one for workarounds. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Lucas De Marchi authored
dg1_gt_workarounds_init() is only ever called for DG1, so there is no point checking it again. Signed-off-by:
-
John Harrison authored
The CI results for the 'fast request' patch set (enables error return codes for fire-and-forget H2G messages) hit an issue with the KMD sending context submission requests on an invalid context. That was caused by a fault injection probe failing the context creation of a kernel context. However, there was no return code checking on any of the kernel context registration paths. So the driver kept going and tried to use the kernel context for the record defaults process. This would not cause any actual problems. The invalid requests would be rejected by GuC and ultimately the start up sequence would correctly wedge due to the context creation failure. But fixing the issue correctly rather ignoring it means we won't get CI complaining when the fast request patch lands and enables the extra error checking. So fix it by checking for errors and aborting as appropriate when creating kernel contexts. While at it, clean up some other submission init related failure cleanup paths. Also, rename guc_init_lrc_mapping to guc_init_submission as the former name hasn't been valid in a long time. v2: Add another wrapper to keep the flow balanced (Daniele) Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230217223308.3449737-3-John.C.Harrison@Intel.com
-
John Harrison authored
The stats worker thread management was mis-matched between enable/disable call sites. Fix those up. Also, abstract the cancel/enable code into a helper function rather than replicating in multiple places. v2: Rename the helpers and wrap the enable as well as the cancel (review feedback from Daniele). Signed-off-by:
-
- 09 Mar, 2023 2 commits
-
-
Daniele Ceraolo Spurio authored
The GSC FW load is a slow process (up to 250 ms), so we defer it to a dedicated worker to avoid stalling the init flow for that long. However, we currently start this worker before the HW init is complete, so there is a chance that the GSC loading code submits to the HW before the engine initialization has completed. We can easily fix this by starting the thread later in the gt_resume flow. From this later spot, the GSC code can still race with the default submission code; we functionally don't care who wins the race (the GSC load doesn't need any state), but since the whole point of the separate worker is to make the main thread faster, we prefer the default submission code to run first. Therefore, make an exception for driver probe and only and start the gsc load from uc_init_late. Signed-off-by:
-
Daniele Ceraolo Spurio authored
If we unload the driver and wedge before the GSC worker is complete, the worker will hit an error on its submission to the GSC engine and then exit. This is hard to hit for a user, but it is reproducible with skipping selftests. The error is handled gracefully by the worker, so there are no functional issues, but we still end up with an error message in dmesg, which is something we want to avoid as this is a supported scenario. We could modify the worker to better handle a wedging occurring during its execution, but that gets complicated for a couple of reasons: - We do want the error on runtime wedging, because there are implications for subsystems outside of GT (i.e., PXP, HDCP), it's only the error on driver unload that we want to silence. - The worker is responsible for multiple submissions (GSC FW load, HuC auth, SW proxy), so all of those will have to be adapted to handle the wedged_on_fini scenario. Therefore, it's much simpler to just wait for the worker to be done before wedging on driver removal, also considering that the worker will likely already be idle in the great majority of non-selftest scenarios. Signed-off-by:
-
- 07 Mar, 2023 2 commits
-
-
Gustavo Sousa authored
Wa_1606376872 applies to all Xe_LP IPs except DG1. Signed-off-by:
Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
-
Tejas Upadhyay authored
We can skip the assignment and i915 variable altogether and use refernce directly. Also used at single place only. Signed-off-by:
Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by:
-
- 03 Mar, 2023 4 commits
-
-
Anshuman Gupta authored
Use ktime_get() after accessing the mmio or any driver resource, while using wall time for various calculation that depends on the inserted delay in order to account any mmio and resource access latency. Cc: Chris Wilson <chris.p.wilson@intel.com> Signed-off-by:
-
Anshuman Gupta authored
While reading the engine timestamps there can be uncontrollable concurrent mmio access via other i915 child drivers and by GuC, which is not truly atomic context as expected by this selftest, which may cause mmio latency to read the engine timestamps, Account such latency to calculate time to read engine timestamp such that selftest can validate the timestamp and ktime pair. Cc: Chris Wilson <chris.p.wilson@intel.com> Signed-off-by:
-
Janusz Krzysztofik authored
Users reported oopses on list corruptions when using i915 perf with a number of concurrently running graphics applications. Root cause analysis pointed at an issue in barrier processing code -- a race among perf open / close replacing active barriers with perf requests on kernel context and concurrent barrier preallocate / acquire operations performed during user context first pin / last unpin. When adding a request to a composite tracker, we try to reuse an existing fence tracker, already allocated and registered with that composite. The tracker we obtain may already track another fence, may be an idle barrier, or an active barrier. If the tracker we get occurs a non-idle barrier then we try to delete that barrier from a list of barrier tasks it belongs to. However, while doing that we don't respect return value from a function that performs the barrier deletion. Should the deletion ever fail, we would end up reusing the tracker still registered as a barrier task. Since the same structure field is reused with both fence callback lists and barrier tasks list, list corruptions would likely occur. Barriers are now deleted from a barrier tasks list by temporarily removing the list content, traversing that content with skip over the node to be deleted, then populating the list back with the modified content. Should that intentionally racy concurrent deletion attempts be not serialized, one or more of those may fail because of the list being temporary empty. Related code that ignores the results of barrier deletion was initially introduced in v5.4 by commit d8af05ff ("drm/i915: Allow sharing the idle-barrier from other kernel requests"). However, all users of the barrier deletion routine were apparently serialized at that time, then the issue didn't exhibit itself. Results of git bisect with help of a newly developed igt@gem_barrier_race@remote-request IGT test indicate that list corruptions might start to appear after commit 31177017 ("drm/i915/gt: Schedule request retirement when timeline idles"), introduced in v5.5. Respect results of barrier deletion attempts -- mark the barrier as idle only if successfully deleted from the list. Then, before proceeding with setting our fence as the one currently tracked, make sure that the tracker we've got is not a non-idle barrier. If that check fails then don't use that tracker but go back and try to acquire a new, usable one. v3: use unlikely() to document what outcome we expect (Andi), - fix bad grammar in commit description. v2: no code changes, - blame commit 31177017 ("drm/i915/gt: Schedule request retirement when timeline idles"), v5.5, not commit d8af05ff ("drm/i915: Allow sharing the idle-barrier from other kernel requests"), v5.4, - reword commit description. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6333 Fixes: 31177017 ("drm/i915/gt: Schedule request retirement when timeline idles") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org # v5.5 Cc: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
-
Alan Previn authored
The Driver-FLR flow may inadvertently exit early before the full completion of the re-init of the internal HW state if we only poll GU_DEBUG Bit31 (polling for it to toggle from 0 -> 1). Instead we need a two-step completion wait-for-completion flow that also involves GU_CNTL. See the patch and new code comments for detail. This is new direction from HW architecture folks. v2: - Add error message for the teardown timeout (Anshuman) - Don't duplicate code in comments (Jani) v3: - Add get/put runtime-pm for this function. Though not functionally required during unload, its so the uncore doesn't complain. v4: - Remove the get/put runtime-pm - that was for a prior version of this patch (not needed for drm-managed callback). - Remove the fixes tag since this is only for MTL and MTL still needs force probe (Daniele). - Bit 31 of GU_CNTL should be DRIVERFLR instead of DRIVERFLR_STATUS (Daniele). Signed-off-by:Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by:
-
- 01 Mar, 2023 2 commits
-
-
Andrea Righi authored
It seems that commit bc3c5e08 ("drm/i915/sseu: Don't try to store EU mask internally in UAPI format") exposed a potential out-of-bounds access, reported by UBSAN as following on a laptop with a gen 11 i915 card: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/i915/gt/intel_sseu.c:65:27 index 6 is out of range for type 'u16 [6]' CPU: 2 PID: 165 Comm: systemd-udevd Not tainted 6.2.0-9-generic #9-Ubuntu Hardware name: Dell Inc. XPS 13 9300/077Y9N, BIOS 1.11.0 03/22/2022 Call Trace: <TASK> show_stack+0x4e/0x61 dump_stack_lvl+0x4a/0x6f dump_stack+0x10/0x18 ubsan_epilogue+0x9/0x3a __ubsan_handle_out_of_bounds.cold+0x42/0x47 gen11_compute_sseu_info+0x121/0x130 [i915] intel_sseu_info_init+0x15d/0x2b0 [i915] intel_gt_init_mmio+0x23/0x40 [i915] i915_driver_mmio_probe+0x129/0x400 [i915] ? intel_gt_probe_all+0x91/0x2e0 [i915] i915_driver_probe+0xe1/0x3f0 [i915] ? drm_privacy_screen_get+0x16d/0x190 [drm] ? acpi_dev_found+0x64/0x80 i915_pci_probe+0xac/0x1b0 [i915] ... According to the definition of sseu_dev_info, eu_mask->hsw is limited to a maximum of GEN_MAX_SS_PER_HSW_SLICE (6) sub-slices, but gen11_sseu_info_init() can potentially set 8 sub-slices, in the !IS_JSL_EHL(gt->i915) case. Fix this by reserving up to 8 slots for max_subslices in the eu_mask struct. Reported-by:
Emil Renner Berthing <emil.renner.berthing@canonical.com> Signed-off-by:
Andrea Righi <andrea.righi@canonical.com> Fixes: bc3c5e08 ("drm/i915/sseu: Don't try to store EU mask internally in UAPI format") Reviewed-by:
-
Tvrtko Ursulin authored
After the abandonment of i915->kernel_context and since we have started to create per-gt engine->kernel_context, these tests need to be updated to instantiate the batch buffer VMA in the correct PPGTT for the context used to execute each spinner. v2(Tejas): - Clean commit message - Matt - Add BUG_ON to match vm v3(Tejas): - Fix dim checkpatch warnings Signed-off-by:
-
- 28 Feb, 2023 2 commits
-
-
Matt Roper authored
Xe_HP architecture already makes the CS_CTX_TIMESTAMP readable by userspace on all engines; there's no longer a need to add it to the software-managed whitelist for the non-RCS engines. Bspec: 45545 Signed-off-by:
-
Matt Roper authored
A recommended tuning setting for both gen12 and Xe_HP platforms requires that we grant userspace r/w access to the COMMON_SLICE_CHICKEN3 register. Bspec: 73993, 73994, 31870, 68331 Cc: Dongwon Kim <dongwon.kim@intel.com> Signed-off-by:
-
- 27 Feb, 2023 1 commit
-
-
Andi Shyti authored
It has become common practice to refer to the drm_i915_private structures as "i915". However, there are still instances where they are referred to as "dev_priv". This inconsistency can make grepping for information more difficult and does not maintain a cohesive style throughout the code. Rename all the "dev_priv" structures in the gt/* directory to "i915". Signed-off-by:
-
- 24 Feb, 2023 4 commits
-
-
Matt Roper authored
MTL's primary GT can continue to use the same engine TLB invalidation programming as past Xe_HP-based platforms. However the media GT needs some special handling: * Invalidation registers on the media GT are singleton registers (unlike the primary GT where they are still MCR). * Since the GSC is now exposed as an engine, there's a new register to use for TLB invalidation. The offset is identical to the compute engine offset, but this is expected --- compute engines only exist on the primary GT while the GSC only exists on the media GT. * Although there's only a single GSC engine instance, it inexplicably uses bit 1 to request invalidations rather than bit 0. v2: - Add a 'regs == xelpmp_regs' condition to the GSC instance handling. If the registers change on a future platform, the GSC-specific handling is likely to change as well. (Andrzej) Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by:
-
Jonathan Cavitt authored
Refactor the supports_x_tiling and fast_blit_ok helper functions in the live client selftest to better reflect when XY_FAST_COPY_BLT supports X-tile and can be used. Bspec: 47982 Signed-off-by:
Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
Matthew Auld authored
This was mostly needed to differentiate between mappable and non-mappable lmem, such that ttm would understand non-mappable -> mappable moves (or vice versa), and not just turn them into noops. We have since gained proper .intersects() and .compatible() hooks for the resource manager, which takes care of this for us. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by:
-
Matthew Auld authored
At the very least, we have some tests that force the BAR size for testing purposes, which would result in different BAR size with stolen-lmem vs normal lmem, since the BAR is only resized as part of the normal lmem probing. Signed-off-by:
-
- 17 Feb, 2023 4 commits
-
-
John Harrison authored
Direction from hardware is that ring buffers should never be mapped via the BAR on systems with LLC. There are too many caching pitfalls due to the way BAR accesses are routed. So it is safest to just not use it. Signed-off-by:
Jouni Högander <jouni.hogander@intel.com> Reviewed-by:
-
John Harrison authored
Direction from hardware is that stolen memory should never be used for ring buffer allocations on platforms with LLC. There are too many caching pitfalls due to the way stolen memory accesses are routed. So it is safest to just not use it. Signed-off-by:
-
Tvrtko Ursulin authored
As the logic for selecting the register and corresponsing values grew, the code become a bit unsightly. Consolidate by storing the required values at engine init time in the engine itself, and by doing so minimise the amount of invariant platform and engine checks during each and every TLB invalidation. v2: * Fail engine probe if TLB invlidations registers are unknown. v3: * Rebase. v4: * Fix handling of GEN8_M2TCR. (Andrzej) v5: * Tidy checkpatch warnings. Signed-off-by:
-
Thomas Weißschuh authored
Since commit ee6d3dd4 ("driver core: make kobj_type constant.") the driver core allows the usage of const struct kobj_type. Take advantage of this to constify the structure definitions to prevent modification at runtime. Signed-off-by:
Thomas Weißschuh <linux@weissschuh.net> Reviewed-by:
-
- 15 Feb, 2023 1 commit
-
-
Matt Roper authored
MCR range tables use the final MMIO offset of a register (including the 0x380000 GSI offset when applicable). Since the i915_mcr_reg_t passed as a parameter during steering lookup does not include the GSI offset, we need to add it back in for GSI registers before searching the tables. Fixes: a7ec65fc ("drm/i915/xelpmp: Add multicast steering for media GT") Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230214001906.1477370-1-matthew.d.roper@intel.com
-
- 10 Feb, 2023 1 commit
-
-
Matt Roper authored
Although registers in the L3 bank/node configuration ranges are marked as having "DEV" reset characteristics in the bspec, this appears to be a hold-over from pre-Xe_HP platforms. In reality, these registers maintain their values across engine resets, meaning that workarounds and tuning settings targeting them should be placed on the GT workaround list rather than an engine workaround list. Note that an extra clue here is that these registers moved from the RENDER forcewake domain to the GT forcewake domain in Xe_HP; generally RCS/CCS engine resets should not lead to the reset of a register that lives outside the RENDER domain. Re-applying these registers on engine resets wouldn't actually hurt anything, but is unnecessary and just makes it more confusing to anyone trying to decipher how these registers really work. v2: - Also move DG2's Wa_14010648519 to the GT list. (Gustavo) Cc: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by:
-
