- 19 Jul, 2023 3 commits
-
-
Tvrtko Ursulin authored
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:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@kernel.org> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230717164013.826614-3-tvrtko.ursulin@linux.intel.com
-
Tvrtko Ursulin authored
Record the default values as preparation for exposing the sysfs controls. Signed-off-by:
-
Tvrtko Ursulin authored
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:
-
- 17 Jul, 2023 1 commit
-
-
Nirmoy Das authored
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:
Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
Oak Zeng <oak.zeng@intel.com> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by:
-
- 12 Jul, 2023 2 commits
-
-
Zhanjun Dong authored
As context structure is shared memory for CPU/GPU, Wa_22016122933 is needed for this memory block as well. Signed-off-by:
Zhanjun Dong <zhanjun.dong@intel.com> CC: Fei Yang <fei.yang@intel.com> Reviewed-by:
Fei Yang <fei.yang@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230706174704.177929-1-zhanjun.dong@intel.com
-
Andrzej Hajda authored
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:
-
- 10 Jul, 2023 2 commits
-
-
Tvrtko Ursulin authored
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:
Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230707125503.3965817-1-tvrtko.ursulin@linux.intel.com
-
Tvrtko Ursulin authored
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:
-
- 07 Jul, 2023 1 commit
-
-
Umesh Nerlige Ramappa authored
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:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by:
-
- 06 Jul, 2023 2 commits
-
-
Vinay Belgaumkar authored
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:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
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:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230705095518.3690951-1-tvrtko.ursulin@linux.intel.com
-
- 03 Jul, 2023 7 commits
-
-
Lucas De Marchi authored
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:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230630203509.1635216-8-lucas.demarchi@intel.com
-
Lucas De Marchi authored
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:
-
Lucas De Marchi authored
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:
-
Lucas De Marchi authored
Now that non-masked registers are already read before programming the context reads, the additional read became redudant, so remove it. Signed-off-by:
-
Lucas De Marchi authored
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:
-
Lucas De Marchi authored
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:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230630203509.1635216-3-lucas.demarchi@intel.com
-
Lucas De Marchi authored
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:
-
- 26 Jun, 2023 1 commit
-
-
Sumitra Sharma authored
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:
Ira Weiny <ira.weiny@intel.com> Signed-off-by:
Sumitra Sharma <sumitraartsy@gmail.com> Reviewed-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
Fabio M. De Francesco <fmdefrancesco@gmail.com> Signed-off-by:
-
- 23 Jun, 2023 1 commit
-
-
Matt Roper authored
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:
Haridhar Kalvala <haridhar.kalvala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230616225041.3922719-1-matthew.d.roper@intel.com
-
- 22 Jun, 2023 1 commit
-
-
Tejas Upadhyay authored
WA 14018778641 needs an update after recent performance data on MTL, aligning driver here with HW WA update. Signed-off-by:
-
- 21 Jun, 2023 1 commit
-
-
Vinay Belgaumkar authored
The scenario being fixed here is depicted in the following sequence- modprobe i915 echo 1 > /sys/class/drm/card0/gt/gt0/slpc_ignore_eff_freq echo 300 > /sys/class/drm/card0/gt_min_freq_mhz (RPn) cat /sys/class/drm/card0/gt_cur_freq_mhz --> cur == RPn as expected echo 1 > /sys/kernel/debug/dri/0/gt0/reset --> reset cat /sys/class/drm/card0/gt_min_freq_mhz --> cached freq is RPn cat /sys/class/drm/card0/gt_cur_freq_mhz --> it's not RPn, but RPe!! When SLPC reinitializes, it sets SLPC min freq to efficient frequency. Even if we disable efficient freq post that, we should restore the cached min freq (via H2G) for it to take effect. v2: Clarify commit message (Ashutosh) Fixes: 95ccf312 ("drm/i915/guc/slpc: Allow SLPC to use efficient frequency") Reviewed-by:
-
- 20 Jun, 2023 1 commit
-
-
Alan Previn authored
intel_gsc_uc_fw_proxy_init_done is used by a few code paths and usages. However, certain paths need a wakeref while others can't take a wakeref such as from the runtime_pm_resume callstack. Add a param into this helper to allow callers to direct whether to take the wakeref or not. This resolves the following bug: INFO: task sh:2607 blocked for more than 61 seconds. Not tainted 6.3.0-pxp-gsc-final-jun14+ #297 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:sh state:D stack:13016 pid:2607 ppid:2602 flags:0x00004000 Call Trace: <TASK> __schedule+0x47b/0xe10 schedule+0x58/0xd0 rpm_resume+0x1cc/0x800 ? __pfx_autoremove_wake_function+0x10/0x10 __pm_runtime_resume+0x42/0x80 __intel_runtime_pm_get+0x19/0x80 [i915] gsc_uc_get_fw_status+0x10/0x50 [i915] intel_gsc_uc_fw_init_done+0x9/0x20 [i915] intel_gsc_uc_load_start+0x5b/0x130 [i915] __uc_resume+0xa5/0x280 [i915] intel_runtime_resume+0xd4/0x250 [i915] ? __pfx_pci_pm_runtime_resume+0x10/0x10 __rpm_callback+0x3c/0x160 Fixes: 8c33c375 ("drm/i915/gsc: take a wakeref for the proxy-init-completion check") Signed-off-by:Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by:
-
- 19 Jun, 2023 2 commits
-
-
Dan Carpenter authored
The mmap_offset_attach() function returns error pointers, it doesn't return NULL. Fixes: eaee1c08 ("drm/i915: Add a function to mmap framebuffer obj") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
-
Arnd Bergmann authored
The function is only defined if CONFIG_PROC_FS is enabled: ld.lld: error: undefined symbol: i915_drm_client_fdinfo >>> referenced by i915_driver.c >>> drivers/gpu/drm/i915/i915_driver.o:(i915_drm_driver) in archive vmlinux.a Use the PTR_IF() helper to make the reference NULL otherwise. Fixes: e894b724 ("drm/i915: Use the fdinfo helper") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Randy Dunlap <rdunlap@infradead.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Signed-off-by:
-
- 15 Jun, 2023 1 commit
-
-
Harshit Mogalapalli authored
Smatch warns: drivers/gpu/drm/i915/gt/uc/intel_huc.c:388 intel_huc_init() warn: missing error code 'err' When the allocation of VMAs fail: The value of err is zero at this point and it is passed to PTR_ERR and also finally returning zero which is success instead of failure. Fix this by adding the missing error code when VMA allocation fails. Fixes: 08872cb1 ("drm/i915/mtl/huc: auth HuC via GSC") Signed-off-by:
Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com> Reviewed-by:
-
- 13 Jun, 2023 4 commits
-
-
Daniele Ceraolo Spurio authored
Add a new debugfs to dump information about the GSC. This includes: - the FW path and SW tracking status; - the release, security and compatibility versions; - the HECI1 status registers. Note that those are the same registers that the mei driver dumps in their own status sysfs on DG2 (where mei owns the GSC). To make it simpler to loop through the status register, the code has been update to use a PICK macro and the existing code using the regs had been adapted to match. v2: fix includes and copyright dates (Alan) v3: actually fix the includes Signed-off-by:
-
Daniele Ceraolo Spurio authored
The compatibility version is queried via an MKHI command. Right now, the only existing interface is 1.0 This is basically the interface version for the GSC FW, so the plan is to use it as the main tracked version, including for the binary naming in the fetch code. v2: use define for the object size (Alan) Signed-off-by:
-
Daniele Ceraolo Spurio authored
The release and security versions of the GSC binary are not used at runtime to decide interface compatibility (there is a separate version for that), but they're still useful for debug, so it is still worth extracting them and printing them out in dmesg. To get to these version, we need to navigate through various headers in the binary. See in-code comment for details. v2: fix and improve size checks when crawling the binary header, add comment about the different version, wrap the partition base/offset pairs in the GSC header in a struct (Alan) Signed-off-by:
-
Daniele Ceraolo Spurio authored
A few fixes/updates are required around the GSC memory allocation and it is easier to do them all at the same time. The changes are as follows: 1 - Switch the memory allocation to stolen memory. We need to avoid accesses from GSC FW to normal memory after the suspend function has completed and to do so we can either switch to using stolen or make sure the GSC is gone to sleep before the end of the suspend function. Given that the GSC waits for a bit before going idle even if there are no pending operations, it is easier and quicker to just use stolen memory. 2 - Reduce the GSC allocation size to 4MBs, which is the POR requirement. The 8MBs were needed only for early FW and I had misunderstood that as being the expected POR size when I sent the original patch. 3 - Perma-map the GSC allocation. This isn't required immediately, but it will be needed later to be able to quickly extract the GSC logs, which are inside the allocation. Since the mapping code needs to be rewritten due to switching to stolen, it makes sense to do the switch immediately to avoid having to change it again later. Note that the explicit setting of CACHE_NONE for Wa_22016122933 has been dropped because that's the default setting for stolen memory on !LLC platforms. v2: only memset the memory we're not overwriting (Alan) Signed-off-by:
-
- 12 Jun, 2023 1 commit
-
-
Alan Previn authored
Ensure intel_gsc_uc_fw_init_done and intel_gsc_uc_fw_proxy_init takes a wakeref before reading GSC Shim registers. NOTE: another patch in review also adds a call from selftest to this same function. (https://patchwork.freedesktop.org/series/117713/) which is why i am adding the wakeref inside the callee, not the caller. v2: - add a helper, 'gsc_uc_get_fw_status' for both callers (Daniele Ceraolo) Fixes: 99afb7cc ("drm/i915/pxp: Add ARB session creation and cleanup") Signed-off-by:
-
- 10 Jun, 2023 1 commit
-
-
Nirmoy Das authored
Ensure correct handling of closed VMAs on multi-gt platforms to prevent Use-After-Free. Currently, when GT0 goes idle, closed VMAs that are exclusively added to GT0's closed_vma link (gt->closed_vma) and subsequently freed by i915_vma_parked(), which assumes the entire GPU is idle. However, on platforms with multiple GTs, such as MTL, GT1 may remain active while GT0 is idle. This causes GT0 to mistakenly consider the closed VMAs in its closed_vma list as unnecessary, potentially leading to Use-After-Free issues if a job for GT1 attempts to access a freed VMA. Although we do take a wakeref for GT0 but it happens later, after evaluating VMAs. To mitigate this, it is necessary to hold a GT0 wakeref early. v2: Use gt id to detect multi-tile(Andi) Fix the incorrect error path. v3: Add more comment(Andi) Use the new gt var when possible(Andrzej) Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Chris Wilson <chris.p.wilson@intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Sushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com> Signed-off-by:Sushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230608110103.777594-1-andi.shyti@linux.intel.com
-
- 08 Jun, 2023 1 commit
-
-
Dan Carpenter authored
This should return negative -EAGAIN instead of positive EAGAIN. Fixes: e5e1e6d2 ("drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC") Signed-off-by:
-
- 07 Jun, 2023 3 commits
-
-
Umesh Nerlige Ramappa authored
ggtt offset for hw_tail is not required for the calculations, so drop it. Signed-off-by:
-
Umesh Nerlige Ramappa authored
On DG2, capturing OA reports while running heavy render workloads sometimes results in invalid OA reports where 64-byte chunks inside reports have stale values. Under memory pressure, high OA sampling rates (13.3 us) and heavy render workload, occasionally, the OA HW TAIL pointer does not progress as fast as the sampling rate. When these glitches occur, the TAIL pointer takes approx. 200us to progress. While this is expected behavior from the HW perspective, invalid reports are not expected. In oa_buffer_check_unlocked(), when we execute the if condition, we are updating the oa_buffer.tail to the aging tail and then setting pollin based on this tail value, however, we do not have a chance to rewind and validate the reports prior to setting pollin. The validation happens in a subsequent call to oa_buffer_check_unlocked(). If a read occurs before this validation, then we end up reading reports up until this oa_buffer.tail value which includes invalid reports. Though found on DG2, this affects all platforms. The aging tail logic is no longer necessary since we are explicitly checking for landed reports. Start by dropping the aging tail logic. v2: - Drop extra blank line - Add reason to drop aging logic (Ashutosh) - Add bug links (Ashutosh) - rename aged_tail to read_tail - Squash patches 3 and 1 v3: (Ashutosh) - Remove extra spaces - Remove gtt_offset from the pollin calculation - s/Bug:/Link/ in commit message (checkpatch) Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7484 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7757Signed-off-by:
-
Fei Yang authored
To comply with the design that buffer objects shall have immutable cache setting through out their life cycle, {set, get}_caching ioctl's are no longer supported from MTL onward. With that change caching policy can only be set at object creation time. The current code applies a default (platform dependent) cache setting for all objects. However this is not optimal for performance tuning. The patch extends the existing gem_create uAPI to let user set PAT index for the object at creation time. The new extension is platform independent, so UMD's can switch to using this extension for older platforms as well, while {set, get}_caching are still supported on these legacy paltforms for compatibility reason. However, since PAT index was not clearly defined for platforms prior to GEN12 (TGL), so we are limiting this externsion to GEN12+ platforms only. See ext_set_pat() in for the implementation details. The documentation related to the PAT/MOCS tables is currently available for Tiger Lake here: https://www.intel.com/content/www/us/en/docs/graphics-for-linux/developer-reference/1-0/tiger-lake.html The documentation for other platforms is currently being updated. BSpec: 45101 Mesa support has been submitted in this merge request: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22878 The media driver supprt has bin submitted in this merge request: https://github.com/intel/media-driver/pull/1680 The IGT test related to this change is igt@gem_create@create-ext-set-pat Signed-off-by:Jordan Justen <jordan.l.justen@intel.com> Tested-by:
Carl Zhang <carl.zhang@intel.com> Tested-by:
Lihao Gu <lihao.gu@intel.com> Signed-off-by:
Slawomir Milczarek <slawomir.milczarek@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230606100042.482345-2-andi.shyti@linux.intel.com
-
- 06 Jun, 2023 4 commits
-
-
John Harrison authored
There were a bunch of defines and structures left over from an API update a very long time ago. Remove them. Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Reviewed-by:
-
Matt Atwood authored
_GTS as an abbreviation here leads to some confusion, match other definitions and drop the s. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ashutosh Dixit <ashutosh.dixit@linux.intel.com> Cc: Andi Shyti <andy.shyti@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com> Reviewed-by:
-
Matt Atwood authored
According to Ashutosh there is no current or planned product in i915 for I915_MAX_GT to be 4 anymore. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ashutosh Dixit <ashutosh.dixit@linux.intel.com> Cc: Andi Shyti <andy.shyti@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by:
-
Tvrtko Ursulin authored
Add some missing error propagation in live_parallel_switch. To avoid needlessly burdening the various backport processes, note I am not marking it as a fix against any patches and not copying stable since it is debug/selftests only code. Signed-off-by:
-
