Select Git revision
Search by author
- Any Author
- authors
-
Aaron Watry awatry
-
Adam Jackson ajax
-
Adela Rybak adelaryb
-
Aditya Swarup aswarup
-
Alan Previn Teres Alexi alan_previn_intel
-
Alejandro Piñeiro
apinheiro
-
Alexander Usyskin
ausyskin
-
Alexander von Gluck kallisti5
-
Alex Deucher agd5f
-
Alex Smith aejsmith
-
Alok Hota
ahota
-
Alyssa Rosenzweig
alyssa
-
Andreas Baierl rellla
-
Andreas Boll ab
-
Andres Gomez tanty
-
Andres Rodriguez lostgoat
-
Andrey Grodzovsky
agrodzov
-
Andrzej Hajda andrzej.hajda
-
AnkithaRathod AnkithaRathod
-
Anshuman Gupta anshuma1
- Mar 28, 2025
-
-
John Harrison authoredThe error capture list in the ADS is initially allocated using a placeholder size. When the actual size is determinied later on, there is a debug print about the new size. However, the wording is such that some people see it as an unexpected thing and therefore a potential problem. So re-word it to be a little less concerning. Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250325203211.3907890-1-John.C.Harrison@Intel.com
-
Arnd Bergmann authored
Building the xe driver for i386 results in a link time warning: x86_64-linux-ld: drivers/gpu/drm/xe/xe_migrate.o: in function `xe_migrate_vram': xe_migrate.c:(.text+0x1e15): undefined reference to `__udivdi3' Avoid this by using DIV_U64_ROUND_UP() instead of DIV_ROUND_UP(). The driver is unlikely to be used on 32=bit hardware, so the extra cost here is not too important. Fixes: 9c44fd5f ("drm/xe: Add migrate layer functions for SVM support") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20250324210612.2927194-1-arnd@kernel.org Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
John Harrison authored
The dump on a dead CT tries to emulate the devcoredump formatting (it would use devcoredump code directly but that requires more re-work to happen - work in progress). So update the print of the dead CT reason code to match the format of the 'reason' string that was added to the actual devcoredump a little while ago. Signed-off-by:
-
bnilawar authored
According to pci core guidelines, pci_save_config is recommended when the driver explicitly needs to set the pci power state. As of now xe kmd is only doing pci_save_config while entering to s2idle/s3 state, which makes pci core think that device driver has already applied required pci power state. This leads to GPU remain in D0 state. To fix the issue setting the pci power state to D3Cold. Fixes:dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Badal Nilawar <badal.nilawar@intel.com> Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by:
-
Tejas Upadhyay authored
Sysfs_ops needs to be defined on all directories which can have attr files with set/get method. Add sysfs_ops to even those directories which is currently empty but would have attr files with set/get method in future. Leave .default with default sysfs_ops as it will never have setter method. V2(Himal/Rodrigo): - use single sysfs_ops for all dir and attr with set/get - add default ops as ./default does not need runtime pm at all Fixes: 3f0e1465 ("drm/xe: Runtime PM wake on every sysfs call") Reviewed-by:
Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250327122647.886637-1-tejas.upadhyay@intel.com Signed-off-by:
Tejas Upadhyay <tejas.upadhyay@intel.com>
-
- Mar 27, 2025
-
-
Extend Wa_14022293748, Wa_22019794406 to Xe3_LPG Signed-off-by:
Julia Filipchuk <julia.filipchuk@intel.com> Reviewed-by:
-
Matthew Brost authoredThe intent of the error path in xe_migrate_clear is to wait on locally generated fence and then return. The code is waiting on m->fence which could be the local fence but this is only stable under the job mutex leading to a possible UAF. Fix code to wait on local fence. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable@vger.kernel.org Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20250311182915.3606291-1-matthew.brost@intel.com
-
The RCU_MODE_FIXED_SLICE_CCS_MODE setting is not getting invoked in the gt reset path after the ccs_mode setting by the user. Add it to engine register update list (in hw_engine_setup_default_state()) which ensures it gets set in the gt reset and engine reset paths. v2: Add register update to engine list to ensure it gets updated after engine reset also. Fixes: 0d97ecce ("drm/xe: Enable Fixed CCS mode setting") Cc: stable@vger.kernel.org Signed-off-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Thomas Hellström authored
When the size of the range invalidated is larger than rounddown_pow_of_two(ULONG_MAX), The function macro roundup_pow_of_two(length) will hit an out-of-bounds shift [1]. Use a full TLB invalidation for such cases. v2: - Use a define for the range size limit over which we use a full TLB invalidation. (Lucas) - Use a better calculation of the limit. [1]: [ 39.202421] ------------[ cut here ]------------ [ 39.202657] UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 [ 39.202673] shift exponent 64 is too large for 64-bit type 'long unsigned int' [ 39.202688] CPU: 8 UID: 0 PID: 3129 Comm: xe_exec_system_ Tainted: G U 6.14.0+ #10 [ 39.202690] Tainted: [U]=USER [ 39.202690] Hardware name: ASUS System Product Name/PRIME B560M-A AC, BIOS 2001 02/01/2023 [ 39.202691] Call Trace: [ 39.202692] <TASK> [ 39.202695] dump_stack_lvl+0x6e/0xa0 [ 39.202699] ubsan_epilogue+0x5/0x30 [ 39.202701] __ubsan_handle_shift_out_of_bounds.cold+0x61/0xe6 [ 39.202705] xe_gt_tlb_invalidation_range.cold+0x1d/0x3a [xe] [ 39.202800] ? find_held_lock+0x2b/0x80 [ 39.202803] ? mark_held_locks+0x40/0x70 [ 39.202806] xe_svm_invalidate+0x459/0x700 [xe] [ 39.202897] drm_gpusvm_notifier_invalidate+0x4d/0x70 [drm_gpusvm] [ 39.202900] __mmu_notifier_release+0x1f5/0x270 [ 39.202905] exit_mmap+0x40e/0x450 [ 39.202912] __mmput+0x45/0x110 [ 39.202914] exit_mm+0xc5/0x130 [ 39.202916] do_exit+0x21c/0x500 [ 39.202918] ? lockdep_hardirqs_on_prepare+0xdb/0x190 [ 39.202920] do_group_exit+0x36/0xa0 [ 39.202922] get_signal+0x8f8/0x900 [ 39.202926] arch_do_signal_or_restart+0x35/0x100 [ 39.202930] syscall_exit_to_user_mode+0x1fc/0x290 [ 39.202932] do_syscall_64+0xa1/0x180 [ 39.202934] ? do_user_addr_fault+0x59f/0x8a0 [ 39.202937] ? lock_release+0xd2/0x2a0 [ 39.202939] ? do_user_addr_fault+0x5a9/0x8a0 [ 39.202942] ? trace_hardirqs_off+0x4b/0xc0 [ 39.202944] ? clear_bhb_loop+0x25/0x80 [ 39.202946] ? clear_bhb_loop+0x25/0x80 [ 39.202947] ? clear_bhb_loop+0x25/0x80 [ 39.202950] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 39.202952] RIP: 0033:0x7fa945e543e1 [ 39.202961] Code: Unable to access opcode bytes at 0x7fa945e543b7. [ 39.202962] RSP: 002b:00007ffca8fb4170 EFLAGS: 00000293 [ 39.202963] RAX: 000000000000003d RBX: 0000000000000000 RCX: 00007fa945e543e3 [ 39.202964] RDX: 0000000000000000 RSI: 00007ffca8fb41ac RDI: 00000000ffffffff [ 39.202964] RBP: 00007ffca8fb4190 R08: 0000000000000000 R09: 00007fa945f600a0 [ 39.202965] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 [ 39.202966] R13: 00007fa9460dd310 R14: 00007ffca8fb41ac R15: 0000000000000000 [ 39.202970] </TASK> [ 39.202970] ---[ end trace ]--- Fixes: 332dd011 ("drm/xe: Add range based TLB invalidations") Cc: Matthew Brost <matthew.brost@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: <stable@vger.kernel.org> # v6.8+ Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> #v1 Link: https://lore.kernel.org/r/20250326151634.36916-1-thomas.hellstrom@linux.intel.com
-
Change the scope of the migrate subsystem to be dev managed instead of drm managed. The parent pci struct &device, that the xe struct &drm_device is a part of, gets removed when a hot unplug is triggered, which causes the underlying iommu group to get destroyed as well. The migrate subsystem, which handles the lifetime of the page-table tree (pt) BO, doesn't get a chance to keep the BO back during the hot unplug, as all the references to DRM haven't been put back. When all the references to DRM are indeed put back later, the migrate subsystem tries to put back the pt BO. Since the underlying iommu group has been already destroyed, a kernel NULL ptr dereference takes place while attempting to keep back the pt BO. Closes: #3914 Suggested-by:
Thomas Hellstrom <thomas.hellstrom@intel.com> Reviewed-by:
Aradhya Bhatia <aradhya.bhatia@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250326151929.1495972-1-aradhya.bhatia@intel.com Signed-off-by:
-
Thomas Hellström authored
With SVM, ranges forwarded to the PT code for binding can, mostly due to races when migrating, point to both VRAM and system / foreign device memory. Make the PT code able to handle that by checking, for each PTE set up, whether it points to local VRAM or to system memory. v2: - Fix system memory GPU atomic access. v3: - Avoid the UAPI change. It needs more thought. Signed-off-by:
-
Thomas Hellström authored
The drm_pagemap functionality does not depend on the device having recoverable pagefaults available. So allow xe_migrate_vram() also for such devices. Even if this will have little use in practice, it's beneficial for testin multi-device SVM, since a memory provider could be a non-pagefault capable gpu. Signed-off-by:
-
Thomas Hellström authored
On device unbind, migrate exported bos, including pagemap bos to system. This allows importers to take proper action without disruption. In particular, SVM clients on remote devices may continue as if nothing happened, and can chose a different placement. The evict_flags() placement is chosen in such a way that bos that aren't exported are purged. For pinned bos, we unmap DMA, but their pages are not freed yet since we can't be 100% sure they are not accessed. All pinned external bos (not just the VRAM ones) are put on the pinned.external list with this patch. But this only affects the xe_bo_pci_dev_remove_pinned() function since !VRAM bos are ignored by the suspend / resume functionality. As a follow-up we could look at removing the suspend / resume iteration over pinned external bos since we currently don't allow pinning external bos in VRAM, and other external bos don't need any special treatment at suspend / resume. v2: - Address review comments. (Matthew Auld). v3: - Don't introduce an external_evicted list (Matthew Auld) - Add a discussion around suspend / resume behaviour to the commit message. - Formatting fixes. v4: - Move dma-unmaps of pinned kernel bos to a dev managed callback to give subsystems using these bos a chance to clean them up. (Matthew Auld) Signed-off-by:
-
Thomas Hellström authored
If drm_gpusvm_migrate_to_devmem() succeeds, if a cpu access happens to the range the bo may be freed before xe_bo_unlock(), causing a UAF. Since the reference is transferred, use xe_svm_devmem_release() to release the reference on drm_gpusvm_migrate_to_devmem() failure, and hold a local reference to protect the UAF. Fixes: 2f118c94 ("drm/xe: Add SVM VRAM migration") Signed-off-by:
-
Thomas Hellström authored
Don't rely on CONFIG_DRM_GPUSVM because other drivers may enable it causing us to compile in SVM support unintentionally. Also take the opportunity to leave more code out of compilation if !CONFIG_DRM_XE_GPUSVM and !CONFIG_DRM_XE_DEVMEM_MIRROR v3: - Fixes for compilation errors on 32-bit. This changes the Kconfig logic a bit. Signed-off-by:
-
- Mar 26, 2025
-
-
Matt Roper authored
One additional BMG PCI ID has been added to the spec; make sure our driver recognizes devices with this ID properly. Bspec: 68090 Cc: stable@vger.kernel.org # v6.12+ Reviewed-by:
Clint Taylor <Clinton.A.Taylor@intel.com> Reviewed-by:
-
Add fault injection for xe_oa_alloc_regs to allow it to fail while executing xe_oa_add_config_ioctl(). This need to be added as it cannot be reached by injecting error through IOCTL arguments. Signed-off-by:
Nakshtra Goyal <nakshtra.goyal@intel.com> Reviewed-by:
Francois Dugast <francois.dugast@intel.com> Reviewed-by:
-
- Mar 25, 2025
-
-
Enable per-function engine activity stats when VF's are enabled and disable when VF's are disabled v2: fix commit message remove reset stats from pf config (Michal) Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:Riana Tauro <riana.tauro@intel.com> Reviewed-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250311071759.2117211-4-riana.tauro@intel.com Signed-off-by:
-
Add PMU support for per-function engine activity stats. per-function engine activity is enabled when VF's are enabled. If 2 VF's are enabled, then the applicable function values are 0 - PF engine activity 1 - VF1 engine activity 2 - VF2 engine activity This can be read from perf tool as shown below ./perf stat -e xe_<bdf>/engine-active-ticks,gt=0,engine_class=0, engine_instance=0,function=1/ -I 1000 v2: fix documentation (Umesh) remove global for functions (Lucas, Michal) v3: fix commit message move function_id checks to same place (Michal) v4: fix comment (Umesh) Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: -
Add support for function level engine activity stats. Engine activity stats are enabled when VF's are enabled v2: remove unnecessary initialization move offset to improve code readability (Umesh) remove global for function engine activity (Lucas) v3: fix commit message (Michal) v4: remove enable function parameter fix kernel-doc (Umesh) Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: -
Maarten Lankhorst authored
There are extra spaces in xe_vm_bind_ioctl_validate_bo(), remove those. Reviewed-by:
Maarten Lankhorst <dev@lankhorst.se>
-
- Mar 24, 2025
-
-
Francois Dugast authored
Allow fault injection in a function used during initialization by xe_hw_engine_class_sysfs_init() so that its error handling can be tested. Signed-off-by:
-
WARNING: unmet direct dependencies detected for FB_IOMEM_HELPERS Depends on [n]: HAS_IOMEM [=y] && FB_CORE [=n] Selected by [m]: - DRM_XE_DISPLAY [=y] && HAS_IOMEM [=y] && DRM [=m] && DRM_XE [=m] && DRM_XE [=m]=m [=m] && HAS_IOPORT [=y] DRM_XE_DISPLAY requires FB_IOMEM_HELPERS, but the dependency FB_CORE is missing, selecting FB_IOMEM_HELPERS if DRM_FBDEV_EMULATION is set as other drm drivers. Fixes: 44e69495 ("drm/xe/display: Implement display support") Signed-off-by:
Yue Haibing <yuehaibing@huawei.com> Reviewed-by:
-
- Mar 21, 2025
-
-
Lucas De Marchi authored
Allow to test if driver behaves correctly when xe_pcode_probe_early() fails. Note that this is not sufficient for testing survivability mode as it's still required to read the hw to check for errors, which doesn't happen on an injected failure. To complete the early probe coverage, allow injection in the other functions as well: xe_mmio_probe_early() and xe_device_probe_early(). Reviewed-by:
-
Lucas De Marchi authored
Commit d40f275d ("drm/xe: Move survivability entirely to xe_pci") tried to follow the logic: initialize everything needed and if everything succeeds, set the flag that it's enabled. While it fixed some corner cases of those calls failing, it was wrong for setting the flag after the call to xe_heci_gsc_init(): that function does a different initialization for survivability mode. Fix that and add comments about this being done on purpose. Suggested-by:
-
Lucas De Marchi authored
Commit d40f275d ("drm/xe: Move survivability entirely to xe_pci") moved the survivability handling to be done entirely in the xe_pci layer. However there are some issues with that approach: 1) Survivability mode needs at least the mmio initialized, otherwise it can't really read a register to decide if it should enter that state 2) SR-IOV mode should be initialized, otherwise it's not possible to check if it's VF Besides, as pointed by Riana the check for xe_survivability_mode_enable() was wrong in xe_pci_probe() since it's not a bool return. Fix that by moving the initialization to be entirely in the xe_device layer, with the correct dependencies handled: only after mmio and sriov initialization, and not triggering it on error from wait_for_lmem_ready(). This restores the trigger behavior before that commit. The xe_pci layer now only checks for "is it enabled?", like it's doing in xe_pci_suspend()/xe_pci_remove(), etc. Cc: Riana Tauro <riana.tauro@intel.com> Fixes: d40f275d ("drm/xe: Move survivability entirely to xe_pci") Reviewed-by:
-
Lucas De Marchi authored
The different GTs on a device can be very different. Right now for all platforms the same firmware is loaded in each GT, however future platforms may benefit from loading a different file depending on the GT type. Based on previous patch by John Harrison <John.C.Harrison@Intel.com>. Reviewed-by:
-
Lucas De Marchi authored
The `entries` variable is used to loop through the array - it's supposed to be const, but not static. Reviewed-by:
-
Thomas Hellström authored
Introduce and use a helper to iterate over the various pinned bo lists. There are a couple of slight functional changes: 1) GGTT maps are now performed with the bo locked. 2) If the per-bo callback fails, keep the bo on the original list. v2: - Skip unrelated change in xe_bo.c Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
- Mar 20, 2025
-
-
The WA requires KMD to disable DOP clock gating during a semaphore wait and also ensure that idle delay for every CS is lower than the idle wait time in the PWRCTX_MAXCNT register. Default values for these registers already comply with this restriction. v2: Store timestamp_base in gt info and other comments (Daniele) v3: Skip WA check for VF v4: Review comments (Matt Roper) v5: Cleanup the clock functions and use reg_field_get (Matt Roper) v6: Fix checkpatch issue v7: Fix CI issue Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Signed-off-by:
-
- Mar 19, 2025
-
-
The `struct ttm_resource->placement` contains TTM_PL_FLAG_* flags, but it was incorrectly tested for XE_PL_* flags. This caused xe_dma_buf_pin() to always fail when invoked for the second time. Fix this by checking the `mem_type` field instead. Fixes: 7764222d ("drm/xe: Disallow pinning dma-bufs in VRAM") Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: intel-xe@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.8+ Signed-off-by:
Tomasz Rusinowicz <tomasz.rusinowicz@intel.com> Signed-off-by:
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Reviewed-by:
-
Thomas Hellström authored
Backmerging to bring in the xe shrinker from drm-next. Signed-off-by:
-
- Mar 14, 2025
-
-
Raag Jadav authored
Add hwmon support for fan1_input, fan2_input and fan3_input attributes, which will expose fan speed of respective channels in RPM when supported by hardware. With this in place we can monitor fan speed using lm-sensors tool. v2: Rely on platform checks instead of mailbox error (Aravind, Rodrigo) v3: Introduce has_fan_control flag (Rodrigo) Signed-off-by:
Raag Jadav <raag.jadav@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250312085909.755073-1-raag.jadav@intel.com Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-xe-next-fixes-2025-03-12' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Core Changes: - Fix kernel-doc for gpusvm (Lucas) Driver Changes: - Drop duplicated pc_start call (Rodrigo) - Drop sentinels from rtp (Lucas) - Fix MOCS debugfs missing forcewake (Tvrtko) - Ring flush invalitation (Tvrtko) - Fix type for width alignement (Tvrtko) Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/fsztfqcddrarwjlxjwm2k4wvc6u5vntceh6b7nsnxjmwzgtunj@sbkshjow65rf
-
Dave Airlie authored
Merge tag 'mediatek-drm-next-6.15-v2' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next Mediatek DRM Next for Linux 6.15 1. HDMI fixup and refinement 2. Move to devm_platform_ioremap_resource() usage 3. Add MT8188 dsc compatible 4. Fix config_updating flag never false when no mbox channel 5. dp: drm_err => dev_err in HPD path to avoid NULL ptr 6. Add dpi power-domains example 7. Add MT8365 SoC support 8. Fix error codes in mtk_dsi_host_transfer() Signed-off-by:
-
- Mar 13, 2025
-
-
If devm_add_action_or_reset() isn't successful, xe_eu_stall_fini() is invoked. So, unsuccessful return from devm_add_action_or_reset() shouldn't dereference gt->eu_stall as xe_eu_stall_fini() already frees it. Fix this issue. Fixes: 9a0b11d4 ("drm/xe/eustall: Add support to init, enable and disable EU stall sampling") Signed-off-by:
Harish Chegondi <harish.chegondi@intel.com> Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by:
-
Francois Dugast authored
Add a new entry in stats to for svm page faults. If CONFIG_DEBUG_FS is enabled, the count can be viewed with per GT stat debugfs file. This is similar to what is already in place for vma page faults. Example output: cat /sys/kernel/debug/dri/0/gt0/stats svm_pagefault_count: 6 tlb_inval_count: 78 vma_pagefault_count: 0 vma_pagefault_kb: 0 v2: Fix build with CONFIG_DRM_GPUSVM disabled v3: Update argument in kernel doc Reviewed-by: -
Plane->min_alignment returns an unsigned int so lets use that in the whole relevant call chain. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by:
-
This is more readable than the nameless booleans and will also come handy later. Signed-off-by:
-
Emit_flush_invalidate() is incorrectly marking the write to LRC_PPHWSP as a GGTT write and also writing an atypical ~0 dword as the payload. Fix it. While at it drop the unused flags argument. Signed-off-by:
-
