- 02 8月, 2023 4 次提交
-
-
由 Andi Shyti 提交于
The inclusion of intel_gt_defines.h was initially added to i915_drv.h to provide the definition of I915_MAX_GT, where it was originally defined. However, since I915_MAX_GT is now included in i915_gem_object_types.h, it sis no longer required in i915_drv.h. Signed-off-by: NAndi Shyti <andi.shyti@linux.intel.com> Cc: Chris Wilson <chris.p.wilson@linux.intel.com> Reviewed-by: NMauro Carvalho Chehab <mchehab@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230801141955.383305-5-andi.shyti@linux.intel.com
-
由 Chris Wilson 提交于
With multi-GT devices, the object may have been bound on each GT. Invalidate the TLBs across all GT before releasing the pages back to the system. Signed-off-by: NChris Wilson <chris.p.wilson@linux.intel.com> Cc: Fei Yang <fei.yang@intel.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org> Reviewed-by: NAndi Shyti <andi.shyti@linux.intel.com> Signed-off-by: NAndi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230801141955.383305-4-andi.shyti@linux.intel.com
-
由 Andi Shyti 提交于
Create a new intel_gt_defines.h inside the gt/ directory as a placeholder for all the generic GT based defines. As of now place only I915_MAX_GT. Co-developed-by: NChris Wilson <chris.p.wilson@linux.intel.com> Signed-off-by: NChris Wilson <chris.p.wilson@linux.intel.com> Signed-off-by: NAndi Shyti <andi.shyti@linux.intel.com> Reviewed-by: NMauro Carvalho Chehab <mchehab@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230801141955.383305-3-andi.shyti@linux.intel.com
-
由 Chris Wilson 提交于
Prepare for supporting more TLB invalidation scenarios by moving the current MMIO invalidation to its own file. Signed-off-by: NChris Wilson <chris.p.wilson@linux.intel.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@kernel.org> Reviewed-by: NAndi Shyti <andi.shyti@linux.intel.com> Signed-off-by: NAndi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230801141955.383305-2-andi.shyti@linux.intel.com
-
- 01 8月, 2023 1 次提交
-
-
由 David Reaver 提交于
Fix the following make htmldocs errors/warnings: ./drivers/gpu/drm/i915/gt/uc/intel_huc.c:29: ERROR: Unexpected indentation. ./drivers/gpu/drm/i915/gt/uc/intel_huc.c:30: WARNING: Block quote ends without a blank line; unexpected unindent. ./drivers/gpu/drm/i915/gt/uc/intel_huc.c:35: WARNING: Bullet list ends without a blank line; unexpected unindent. This output is a bit misleading. The real issue here is we need a blank line before and after the bulleted list. Link: https://www.kernel.org/doc/html/latest/gpu/i915.html#huc Link: https://lore.kernel.org/dri-devel/20230530152958.1384061-1-daniele.ceraolospurio@intel.com/Signed-off-by: NDavid Reaver <me@davidreaver.com> Reviewed-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230727025400.372965-1-me@davidreaver.com
-
- 31 7月, 2023 1 次提交
-
-
由 Janusz Krzysztofik 提交于
Infinite waits for completion of GPU activity have been observed in CI, mostly inside __i915_active_wait(), triggered by igt@gem_barrier_race or igt@perf@stress-open-close. Root cause analysis, based of ftrace dumps generated with a lot of extra trace_printk() calls added to the code, revealed loops of request dependencies being accidentally built, preventing the requests from being processed, each waiting for completion of another one's activity. After we substitute a new request for a last active one tracked on a timeline, we set up a dependency of our new request to wait on completion of current activity of that previous one. While doing that, we must take care of keeping the old request still in memory until we use its attributes for setting up that await dependency, or we can happen to set up the await dependency on an unrelated request that already reuses the memory previously allocated to the old one, already released. Combined with perf adding consecutive kernel context remote requests to different user context timelines, unresolvable loops of await dependencies can be built, leading do infinite waits. We obtain a pointer to the previous request to wait upon when we substitute it with a pointer to our new request in an active tracker, e.g. in intel_timeline.last_request. In some processing paths we protect that old request from being freed before we use it by getting a reference to it under RCU protection, but in others, e.g. __i915_request_commit() -> __i915_request_add_to_timeline() -> __i915_request_ensure_ordering(), we don't. But anyway, since the requests' memory is SLAB_FAILSAFE_BY_RCU, that RCU protection is not sufficient against reuse of memory. We could protect i915_request's memory from being prematurely reused by calling its release function via call_rcu() and using rcu_read_lock() consequently, as proposed in v1. However, that approach leads to significant (up to 10 times) increase of SLAB utilization by i915_request SLAB cache. Another potential approach is to take a reference to the previous active fence. When updating an active fence tracker, we first lock the new fence, substitute a pointer of the current active fence with the new one, then we lock the substituted fence. With this approach, there is a time window after the substitution and before the lock when the request can be concurrently released by an interrupt handler and its memory reused, then we may happen to lock and return a new, unrelated request. Always get a reference to the current active fence first, before replacing it with a new one. Having it protected from premature release and reuse, lock it and then replace with the new one but only if not yet signalled via a potential concurrent interrupt nor replaced with another one by a potential concurrent thread, otherwise retry, starting from getting a reference to the new current one. Adjust users to not get a reference to the previous active fence themselves and always put the reference got by __i915_active_fence_set() when no longer needed. v3: Fix lockdep splat reports and other issues caused by incorrect use of try_cmpxchg() (use (cmpxchg() != prev) instead) v2: Protect request's memory by getting a reference to it in favor of delegating its release to call_rcu() (Chris) Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8211 Fixes: df9f85d8 ("drm/i915: Serialise i915_active_fence_set() with itself") Suggested-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NJanusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.6+ Reviewed-by: NAndi Shyti <andi.shyti@linux.intel.com> Signed-off-by: NAndi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230720093543.832147-2-janusz.krzysztofik@linux.intel.com
-
- 28 7月, 2023 1 次提交
-
-
由 Alan Previn 提交于
On MTL, if the GSC Proxy init flows haven't completed, submissions to the GSC engine will fail. Those init flows are dependent on the mei's gsc_proxy component that is loaded in parallel with i915 and a worker that could potentially start after i915 driver init is done. That said, all subsytems that access the GSC engine today does check for such init flow completion before using the GSC engine. However, selftests currently don't wait on anything before starting. To fix this, add a waiter function at the start of __run_selftests that waits for gsc-proxy init flows to complete. Selftests shouldn't care if the proxy-init failed as that should be flagged elsewhere. Difference from prior versions: v7: - Change the fw status to INTEL_UC_FIRMWARE_LOAD_FAIL if the proxy-init fails so that intel_gsc_uc_fw_proxy_get_status catches it. (Daniele) v6: - Add a helper that returns something more than a boolean so we selftest can stop waiting if proxy-init hadn't completed but failed (Daniele). v5: - Move the call to __wait_gsc_proxy_completed from common __run_selftests dispatcher to the group-level selftest function (Trvtko). - change the pr_info to pr_warn if we hit the timeout. v4: - Remove generalized waiters function table framework (Tvrtko). - Remove mention of CI-framework-timeout from comments (Tvrtko). v3: - Rebase to latest drm-tip. v2: - Based on internal testing, increase the timeout for gsc-proxy specific case to 8 seconds. Signed-off-by: NAlan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230720230126.375566-1-alan.previn.teres.alexis@intel.com
-
- 26 7月, 2023 9 次提交
-
-
由 Andi Shyti 提交于
Perform some refactoring with the purpose of keeping in one single place all the operations around the aux table invalidation. With this refactoring add more engines where the invalidation should be performed. Fixes: 972282c4 ("drm/i915/gen12: Add aux table invalidate for all engines") Signed-off-by: NAndi Shyti <andi.shyti@linux.intel.com> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: <stable@vger.kernel.org> # v5.8+ Reviewed-by: NAndrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230725001950.1014671-8-andi.shyti@linux.intel.com
-
由 Jonathan Cavitt 提交于
For platforms that use Aux CCS, wait for aux invalidation to complete by checking the aux invalidation register bit is cleared. Fixes: 972282c4 ("drm/i915/gen12: Add aux table invalidate for all engines") Signed-off-by: NJonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by: NAndi Shyti <andi.shyti@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.8+ Reviewed-by: NNirmoy Das <nirmoy.das@intel.com> Reviewed-by: NAndrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230725001950.1014671-7-andi.shyti@linux.intel.com
-
由 Andi Shyti 提交于
Enable the CCS_FLUSH bit 13 in the control pipe for render and compute engines in platforms starting from Meteor Lake (BSPEC 43904 and 47112). For the copy engine add MI_FLUSH_DW_CCS (bit 16) in the command streamer. Fixes: 972282c4 ("drm/i915/gen12: Add aux table invalidate for all engines") Requires: 8da173db894a ("drm/i915/gt: Rename flags with bit_group_X according to the datasheet") Signed-off-by: NAndi Shyti <andi.shyti@linux.intel.com> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Cc: <stable@vger.kernel.org> # v5.8+ Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NAndrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: NNirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230725001950.1014671-6-andi.shyti@linux.intel.com
-
由 Andi Shyti 提交于
In preparation of the next patch align with the datasheet (BSPEC 47112) with the naming of the pipe control set of flag values. The variable "flags" in gen12_emit_flush_rcs() is applied as a set of flags called Bit Group 1. Define also the Bit Group 0 as bit_group_0 where currently only PIPE_CONTROL0_HDC_PIPELINE_FLUSH bit is set. Signed-off-by: NAndi Shyti <andi.shyti@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.8+ Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NAndrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: NNirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230725001950.1014671-5-andi.shyti@linux.intel.com
-
由 Jonathan Cavitt 提交于
All memory traffic must be quiesced before requesting an aux invalidation on platforms that use Aux CCS. Fixes: 972282c4 ("drm/i915/gen12: Add aux table invalidate for all engines") Requires: a2a4aa0eef3b ("drm/i915: Add the gen12_needs_ccs_aux_inv helper") Signed-off-by: NJonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by: NAndi Shyti <andi.shyti@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.8+ Reviewed-by: NNirmoy Das <nirmoy.das@intel.com> Reviewed-by: NAndrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230725001950.1014671-4-andi.shyti@linux.intel.com
-
由 Andi Shyti 提交于
We always assumed that a device might either have AUX or FLAT CCS, but this is an approximation that is not always true, e.g. PVC represents an exception. Set the basis for future finer selection by implementing a boolean gen12_needs_ccs_aux_inv() function that tells whether aux invalidation is needed or not. Currently PVC is the only exception to the above mentioned rule. Requires: 059ae7ae2a1c ("drm/i915/gt: Cleanup aux invalidation registers") Signed-off-by: NAndi Shyti <andi.shyti@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com> Cc: <stable@vger.kernel.org> # v5.8+ Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NAndrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: NNirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230725001950.1014671-3-andi.shyti@linux.intel.com
-
由 Andi Shyti 提交于
Fix the 'NV' definition postfix that is supposed to be INV. Take the chance to also order properly the registers based on their address and call the GEN12_GFX_CCS_AUX_INV address as GEN12_CCS_AUX_INV like all the other similar registers. Remove also VD1, VD3 and VE1 registers that don't exist and add BCS0 and CCS0. Signed-off-by: NAndi Shyti <andi.shyti@linux.intel.com> Cc: <stable@vger.kernel.org> # v5.8+ Reviewed-by: NNirmoy Das <nirmoy.das@intel.com> Reviewed-by: NAndrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230725001950.1014671-2-andi.shyti@linux.intel.com
-
由 Tvrtko Ursulin 提交于
We can use the existing helper in flush_write_domain() and save some lines of code. Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NAndi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230721130741.1306563-1-tvrtko.ursulin@linux.intel.com
-
由 Andi Shyti 提交于
Quite surprised to see that around i915 there are still i915->gt0 references. Replace them with the to_gt() helper. Signed-off-by: NAndi Shyti <andi.shyti@linux.intel.com> Reviewed-by: NAndrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230725103330.1041394-1-andi.shyti@linux.intel.com
-
- 25 7月, 2023 1 次提交
-
-
由 Christophe JAILLET 提交于
All error handling paths go to 'out', except this one. Be consistent and also branch to 'out' here. Fixes: c10a652e ("drm/i915/selftests: Rework context handling in hugepages selftests") Signed-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: NAndrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: NAndi Shyti <andi.shyti@linux.intel.com> Signed-off-by: NAndi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/7a036b88671312ee9adc01c74ef5b3376f690b76.1689619758.git.christophe.jaillet@wanadoo.fr
-
- 24 7月, 2023 1 次提交
-
-
由 Andrzej Hajda 提交于
i915_request contains direct alias to i915, there is no point to go via rq->engine->i915. v2: added missing rq.i915 initialization in measure_breadcrumb_dw. Signed-off-by: NAndrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by: NNirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230720113002.1541572-1-andrzej.hajda@intel.com
-
- 21 7月, 2023 1 次提交
-
-
由 Daniele Ceraolo Spurio 提交于
Due to a change in the auth flow on MTL, GuC 70.7.0 and newer will only be able to authenticate HuC 8.5.1 and newer. The plan is to update the 2 binaries synchronously in linux-firmware so that the fw repo always has a matching pair that works; still, it's better to check in the kernel so we can print an error message and abort HuC loading if the binaries are out of sync instead of failing the authentication. v2: Add clarification comment, fix typo in commit msg, clean up variable declaration (John) Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> #v1 Reviewed-by: NJohn Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230717234905.117114-1-daniele.ceraolospurio@intel.com
-
- 19 7月, 2023 4 次提交
-
-
由 Tvrtko Ursulin 提交于
User feedback indicates significant performance gains are possible in specific games with non default RPS up/down thresholds. Expose these tunables via sysfs which will allow users to achieve best performance when running games and best power efficiency elsewhere. Note this patch supports non GuC based platforms only. v2: * Make checkpatch happy. Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> References: https://gitlab.freedesktop.org/drm/intel/-/issues/8389 Cc: Rodrigo Vivi <rodrigo.vivi@kernel.org> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NAndi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230717164013.826614-4-tvrtko.ursulin@linux.intel.com
-
由 Tvrtko Ursulin 提交于
In preparation for exposing via sysfs add helpers for managing rps thresholds. v2: * Force sw and hw re-programming on threshold change. Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@kernel.org> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NAndi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230717164013.826614-3-tvrtko.ursulin@linux.intel.com
-
由 Tvrtko Ursulin 提交于
Record the default values as preparation for exposing the sysfs controls. Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@kernel.org> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NAndi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230717164013.826614-2-tvrtko.ursulin@linux.intel.com
-
由 Tvrtko Ursulin 提交于
Since 36d516be ("drm/i915/gt: Switch to manual evaluation of RPS") thresholds are invariant so lets move their setting to init time. Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@kernel.org> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NAndi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230717164013.826614-1-tvrtko.ursulin@linux.intel.com
-
- 17 7月, 2023 1 次提交
-
-
由 Nirmoy Das 提交于
Use smem on MTL due to a HW bug in MTL that prevents reading from stolen memory using LMEM BAR. Cc: Oak Zeng <oak.zeng@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: NNirmoy Das <nirmoy.das@intel.com> Reviewed-by: NOak Zeng <oak.zeng@intel.com> Reviewed-by: NAndrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: NAndi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230713150142.12700-1-nirmoy.das@intel.com
-
- 13 7月, 2023 1 次提交
-
-
由 Zhanjun Dong 提交于
As context structure is shared memory for CPU/GPU, Wa_22016122933 is needed for this memory block as well. Signed-off-by: NZhanjun Dong <zhanjun.dong@intel.com> CC: Fei Yang <fei.yang@intel.com> Reviewed-by: NFei Yang <fei.yang@intel.com> Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230706174704.177929-1-zhanjun.dong@intel.com
-
- 12 7月, 2023 1 次提交
-
-
由 Andrzej Hajda 提交于
Arrays passed to reg_in_range_table should end with empty record. The patch solves KASAN detected bug with signature: BUG: KASAN: global-out-of-bounds in xehp_is_valid_b_counter_addr+0x2c7/0x350 [i915] Read of size 4 at addr ffffffffa1555d90 by task perf/1518 CPU: 4 PID: 1518 Comm: perf Tainted: G U 6.4.0-kasan_438-g3303d06107f3+ #1 Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P DDR5 SODIMM SBS RVP, BIOS MTLPFWI1.R00.3223.D80.2305311348 05/31/2023 Call Trace: <TASK> ... xehp_is_valid_b_counter_addr+0x2c7/0x350 [i915] Fixes: 0fa9349d ("drm/i915/perf: complete programming whitelisting for XEHPSDV") Signed-off-by: NAndrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: NAndi Shyti <andi.shyti@linux.intel.com> Reviewed-by: NNirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230711153410.1224997-1-andrzej.hajda@intel.com
-
- 10 7月, 2023 2 次提交
-
-
由 Tvrtko Ursulin 提交于
Commit a4d86249 ("drm/i915/gt: Provide a utility to create a scratch buffer") mistakenly passed in uapi I915_CACHING_CACHED as argument to i915_gem_object_set_cache_coherency(), which actually takes internal enum i915_cache_level. No functional issue since the value matches I915_CACHE_LLC (1 == 1), which is the intended caching mode, but lets clean it up nevertheless. Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: a4d86249 ("drm/i915/gt: Provide a utility to create a scratch buffer") Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: NTejas Upadhyay <tejas.upadhyay@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230707125503.3965817-1-tvrtko.ursulin@linux.intel.com
-
由 Tvrtko Ursulin 提交于
Commit 9275277d ("drm/i915: use pat_index instead of cache_level") added a dedicated gen12_pte_encode but forgot to remove the Gen12 specific bit from gen8_pte_encode. Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: 9275277d ("drm/i915: use pat_index instead of cache_level") Cc: Fei Yang <fei.yang@intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: NFei Yang <fei.yang@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230707124644.3965281-1-tvrtko.ursulin@linux.intel.com
-
- 08 7月, 2023 1 次提交
-
-
由 Umesh Nerlige Ramappa 提交于
For reports that are not powers of 2, reports at the end of the OA buffer may get split across the buffer boundary. When zeroing out such reports, take the split into consideration. v2: Use OA_BUFFER_SIZE (Ashutosh) Fixes: 09a36015 ("drm/i915/perf: Clear out entire reports after reading if not power of 2 size") Signed-off-by: NUmesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: NAshutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: NAshutosh Dixit <ashutosh.dixit@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230616173402.699776-1-umesh.nerlige.ramappa@intel.com
-
- 07 7月, 2023 1 次提交
-
-
由 Vinay Belgaumkar 提交于
GuC load takes longer sometimes due to GT frequency not ramping up. Add perf_limit_reasons to the existing warn print to see if frequency is being throttled. v2: Review comments (Ashutosh) Signed-off-by: NVinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: NAshutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230627191336.319381-1-vinay.belgaumkar@intel.com
-
- 06 7月, 2023 1 次提交
-
-
由 Tvrtko Ursulin 提交于
Commit 2caffbf1 ("drm/i915: Revoke mmaps and prevent access to fence registers across reset") removed the temporary implementation of a reset under stop machine but forgot to remove this one commented out define. Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230705095518.3690951-1-tvrtko.ursulin@linux.intel.com
-
- 04 7月, 2023 7 次提交
-
-
由 Lucas De Marchi 提交于
When checking if the workarounds were applied successfully, the read-back mask should also contain the bits being set: it's possible that in a call to wa_write_clr_set(), the cleared bits are not a superset of the set bits. Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: NKenneth Graunke <kenneth@whitecape.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230630203509.1635216-8-lucas.demarchi@intel.com
-
由 Lucas De Marchi 提交于
The comment on the parameter being 0 to avoid the read back doesn't apply as this is not a call to wa_add(), but rather to wa_write_clr_set(). So, this register is actually checked and it's according to the Bspec that the register is RW, not RO. Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: NKenneth Graunke <kenneth@whitecape.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230630203509.1635216-7-lucas.demarchi@intel.com
-
由 Lucas De Marchi 提交于
Contrary to GEN12_FF_MODE2, platforms using XEHP_FF_MODE2 are not affected by Wa_1608008084, hence read back can be enabled. Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: NKenneth Graunke <kenneth@whitecape.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230630203509.1635216-6-lucas.demarchi@intel.com
-
由 Lucas De Marchi 提交于
Now that non-masked registers are already read before programming the context reads, the additional read became redudant, so remove it. Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: NKenneth Graunke <kenneth@whitecape.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230630203509.1635216-5-lucas.demarchi@intel.com
-
由 Lucas De Marchi 提交于
Most of the context workarounds tweak masked registers, but not all. For masked registers, when writing the value it's sufficient to just write the wa->set_bits since that will take care of both the clr and set bits as well as not overwriting other bits. However there are some workarounds, the registers are non-masked. Up until now the driver was simply emitting a MI_LOAD_REGISTER_IMM with the set_bits to program the register via the GPU in the WA bb. This has the side effect of overwriting the content of the register outside of bits that should be set and also doesn't handle the bits that should be cleared. Kenneth reported that on DG2, mesa was seeing a weird behavior due to the kernel programming of L3SQCREG5 in dg2_ctx_gt_tuning_init(). With the GPU idle, that register could be read via intel_reg as 0x00e001ff, but during a 3D workload it would change to 0x0000007f. So the programming of that tuning was affecting more than the bits in L3_PWM_TIMER_INIT_VAL_MASK. Matt Roper noticed the lack of rmw for the context workarounds due to the use of MI_LOAD_REGISTER_IMM. So, for registers that are not masked, read its value via mmio, modify and then set it in the buffer to be written by the GPU. This should take care in a simple way of programming just the bits required by the tuning/workaround. If in future there are registers that involved that can't be read by the CPU, a more complex approach may be required like a) issuing additional instructions to read and modify; or b) scan the golden context and patch it in place before saving it; or something else. But for now this should suffice. Scanning the context workarounds for all platforms, these are the impacted ones with the respective registers mtl: DRAW_WATERMARK mtl/dg2: XEHP_L3SQCREG5, XEHP_FF_MODE2 ICL has some non-masked registers in the context workarounds: GEN8_L3CNTLREG, IVB_FBC_RT_BASE and VB_FBC_RT_BASE_UPPER, but there shouldn't be an impact. The first is already being manually read and the other 2 are intentionally overwriting the entire register. Same reasoning applies to GEN12_FF_MODE2: the WA is intentionally overwriting all the bits to avoid a read-modify-write. v2: Reword commit message wrt GEN12_FF_MODE2 and the changed behavior on preparatory patches. v3: Also skip reading if clear|set bits covers everything Cc: Kenneth Graunke <kenneth@whitecape.org> Cc: Matt Roper <matthew.d.roper@intel.com> Link: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23783#note_1968971Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: NKenneth Graunke <kenneth@whitecape.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230630203509.1635216-4-lucas.demarchi@intel.com
-
由 Lucas De Marchi 提交于
Right now context workarounds don't do a rmw and instead only write to the register. Since 2 separate programmings to the same register are coalesced into a single write, this is not problematic for GEN12_FF_MODE2 since both TDS and GS timer are going to be written together and the other remaining bits be zeroed. However in order to fix other workarounds that may want to preserve the unrelated bits in the same register, context workarounds need to be changed to a rmw. To prepare for that, move the programming of GEN12_FF_MODE2 to a single place so the value passed for "clear" can be all the bits. Otherwise the second workaround would be dropped as it'd be detected as overwriting a previously programmed workaround. Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230630203509.1635216-3-lucas.demarchi@intel.com
-
由 Lucas De Marchi 提交于
Move helper function to get all the forcewakes required by the wa list to the top, so it can be re-used by other functions. Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: NKenneth Graunke <kenneth@whitecape.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230630203509.1635216-2-lucas.demarchi@intel.com
-
- 26 6月, 2023 1 次提交
-
-
由 Sumitra Sharma 提交于
kmap() has been deprecated in favor of the kmap_local_page() due to high cost, restricted mapping space, the overhead of a global lock for synchronization, and making the process sleep in the absence of free slots. kmap_local_page() is faster than kmap() and offers thread-local and CPU-local mappings, can take pagefaults in a local kmap region and preserves preemption by saving the mappings of outgoing tasks and restoring those of the incoming one during a context switch. The mapping is kept thread local in the function “i915_vma_coredump_create” in i915_gpu_error.c Therefore, replace kmap() with kmap_local_page(). Suggested-by: NIra Weiny <ira.weiny@intel.com> Signed-off-by: NSumitra Sharma <sumitraartsy@gmail.com> Reviewed-by: NThomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: NFabio M. De Francesco <fmdefrancesco@gmail.com> Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230617180420.GA410966@sumitra.com [tursulin: Removed blank line within tags. Fixup commit text.]
-
- 24 6月, 2023 1 次提交
-
-
由 Matt Roper 提交于
This workaround was already implemented for DG2, PVC, and some steppings of MTL, but the workaround database has now been updated to extend this workaround to TGL, RKL, DG1, and ADL. v2: - Skip readback verification for these extra gen12lp platforms. On some of the platforms, the firmware locks this register, preventing the driver from making any modifications. We should still try to apply the workaround, but if the register is locked and the value doesn't stick, that's semi-expected and not something we want to flag as a driver error on debug builds. Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NHaridhar Kalvala <haridhar.kalvala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230616225041.3922719-1-matthew.d.roper@intel.com
-