summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/xe/xe_uc.c
AgeCommit message (Collapse)Author
2024-07-18drm/xe: Wedge the entire deviceMatthew Brost
Wedge the entire device, not just GT which may have triggered the wedge. To implement this, cleanup the layering so xe_device_declare_wedged() calls into the lower layers (GT) to ensure entire device is wedged. While we are here, also signal any pending GT TLB invalidations upon wedging device. Lastly, short circuit reset wait if device is wedged. v2: - Short circuit reset wait if device is wedged (Local testing) Fixes: 8ed9aaae39f3 ("drm/xe: Force wedged state and block GT reset upon any GPU hang") Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240716063902.1390130-1-matthew.brost@intel.com (cherry picked from commit 7dbe8af13c189f5937e87e9fb924d5bbc49e6f71) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-06-06drm/xe/vf: Custom uC initializationMichal Wajdeczko
VF drivers can't modify WOPCM registers nor upload firmwares to GuC, HuC or GSC. Modify xe_uc initialization functions to skip those steps if running in the VF mode, or defer to a new custom helper function that would not include those steps. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240604212231.1416-3-michal.wajdeczko@intel.com
2024-05-22drm/xe/uc: Don't emit false error if running in execlist modeMichal Wajdeczko
When running in execlist mode (using force_execlist=1 modparam) we incorrectly select the error path in xe_uc_init(), leading to an unwanted error message like this: [ ] xe 0000:00:00.0: [drm] *ERROR* GT0: Failed to initialize uC (0000000000000000) Fix that by doing early return like we do in other similar cases. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240521114857.712-1-michal.wajdeczko@intel.com
2024-05-14drm/xe/uc: Move GuC submission init to post hwconfig stepMichal Wajdeczko
We shouldn't need anything from the GuC submission code until we finish GuC initialization in post hwconfig step. While around add diagnostic message if we fail uC init. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240510203810.1952-3-michal.wajdeczko@intel.com
2024-05-07drm/xe: Don't rely on xe_assert.h to be included elsewhereMichal Wajdeczko
While xe_assert.h is now included and used by the xe_force_wake.h, we want to stop include xe_force_wake.h from xe_device.h as it's not needed there. Explicitly include xe_assert.h where needed. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240507110959.2747-2-michal.wajdeczko@intel.com
2024-04-25drm/xe: Change xe_guc_submit_stop return to voidHimal Prasad Ghimiray
The function xe_guc_submit_stop consistently returns 0 without an error state, prompting the caller to verify it, which is redundant. Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240424041911.2184868-1-himal.prasad.ghimiray@intel.com
2024-04-18drm/xe: Remove useless mem_access during probeRodrigo Vivi
xe_pm_init is the very last thing during the xe_pci_probe(), hence these protections are useless from the point of view of ensuring that the device is awake. Let's remove it so we continue towards the goal of killing xe_device_mem_access. v2: Adding more cases v3: Provide a separate fix for xe_tile_init_noalloc return (Matt) Adding a new case where display HDCP init calls which are also called at display probe time. Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240417203952.25503-5-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-02-20drm/xe: Initialize GuC earlier during probeMichał Winiarski
SR-IOV VF has limited access to MMIO registers. Fortunately, it is able to access a curated subset that is needed to initialize the driver by communicating with SR-IOV PF using GuC CT. Initialize GuC earlier in order to keep the unified probe ordering between VF and PF modes. Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240219130530.1406044-4-michal.winiarski@intel.com
2024-02-20drm/xe/huc: Realloc HuC FW in vram for post-hwconfigMichał Winiarski
Similar to GuC, we're using system memory for the initial stage, and move the image to vram when it's available for subsequent loads (e.g. after reset). Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240219130530.1406044-2-michal.winiarski@intel.com
2024-01-18drm/xe/gsc: Initialize GSC proxyDaniele Ceraolo Spurio
The GSC uC needs to communicate with the CSME to perform certain operations. Since the GSC can't perform this communication directly on platforms where it is integrated in GT, the graphics driver needs to transfer the messages from GSC to CSME and back. The proxy flow must be manually started after the GSC is loaded to signal to GSC that we're ready to handle its messages and allow it to query its init data from CSME. Note that the component must be removed before the pci_remove call completes, so we can't use a drmm helper for it and we need to instead perform the cleanup as part of the removal flow. v2: add function documentation, more targeted memory clear, clearer logs and variable names (Alan) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240117182621.2653049-2-daniele.ceraolospurio@intel.com
2023-12-21drm/xe: Introduce GuC Doorbells ManagerMichal Wajdeczko
The GFX doorbell solution provides a mechanism for submission of workload to the graphics hardware by a ring3 application without the penalty of ring transition for each workload submission. This feature is not currently used by the Linux drivers, but in SR-IOV mode the doorbells are treated as shared resource and the PF driver must be able to provision exclusive range of doorbells IDs across all enabled VFs. Introduce simple GuC doorbell ID manager that will be used by the PF driver for VFs provisioning and can later be used by submission code once we are ready to switch from H2G based notifications to doorbells mechanism. Cc: Matthew Brost <matthew.brost@intel.com> Cc: Piotr Piórkowski <piotr.piorkowski@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://lore.kernel.org/r/20231218190629.502-4-michal.wajdeczko@intel.com Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
2023-12-21drm/xe/huc: Prepare for 2-step HuC authenticationDaniele Ceraolo Spurio
Starting on MTL, the HuC is authenticated twice, once via GuC (same as with older integrated platforms) and once via GSC; the first authentication allows the HuC to be used for clear-media workloads, while the second one unlocks support for protected content. Ahead of adding the authentication flow via GSC, this patch adds support for differentiating the 2 auth steps and checking if they're complete. Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Vivaik Balasubrawmanian <vivaik.balasubrawmanian@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/uc: Extract xe_uc_sanitize_resetMichał Winiarski
Earlier GuC load will require more fine-grained control over reset. Extract it outside of xe_uc_init_hw. Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/gsc: GSC FW loadDaniele Ceraolo Spurio
The GSC FW must be copied in a 4MB stolen memory allocation, whose GGTT address is then passed as a parameter to a dedicated load instruction submitted via the GSC engine. Since the GSC load is relatively slow (up to 250ms), we perform it asynchronously via a worker. This requires us to make sure that the worker has stopped before suspending/unloading. Note that we can't yet use xe_migrate_copy for the copy because it doesn't work with stolen memory right now, so we do a memcpy from the CPU side instead. v2: add comment about timeout value, fix GSC status checking before load (John) Bspec: 65306, 65346 Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/gsc: Introduce GSC FWDaniele Ceraolo Spurio
Add the basic definitions and init function. Same as HuC, GSC is only supported on the media GT on MTL and newer platforms. Note that the GSC requires submission resources which can't be allocated during init (because we don't have the hwconfig yet), so it can't be marked as loadable at the end of the init function. The allocation of those resources will come in the patch that makes use of them to load the FW. v2: better comment, move num FWs define inside the enum (John) Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/uc: Fix uC status trackingDaniele Ceraolo Spurio
The current uC status tracking has a few issues: 1) the HuC is moved to "disabled" instead of "not supported" 2) the status is left uninitialized instead of "disabled" when the modparam is used to disable support 3) due to #1, a number of checks are done against "disabled" instead of the appropriate status. Address all of those by making sure to follow the appropriate state transition and checking against the required state. v2: rebase on s/guc_submission_enabled/uc_enabled/ Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe/uc: Rename guc_submission_enabled() to uc_enabled()Daniele Ceraolo Spurio
The guc_submission_enabled() function is being used as a boolean toggle for all firmwares and all related features, not just GuC submission. We could add additional flags/functions to distinguish and allow different use-cases (e.g. loading HuC but not using GuC submission), but given that not using GuC is a debug-only scenario having a global switch for all FWs is enough. However, we want to make it clear that this switch turns off everything, so rename it to uc_enabled(). v2: rebase on s/XE_WARN_ON/xe_assert Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Use Xe assert macros instead of XE_WARN_ON macroFrancois Dugast
The XE_WARN_ON macro maps to WARN_ON which is not justified in many cases where only a simple debug check is needed. Replace the use of the XE_WARN_ON macro with the new xe_assert macros which relies on drm_*. This takes a struct drm_device argument, which is one of the main changes in this commit. The other main change is that the condition is reversed, as with XE_WARN_ON a message is displayed if the condition is true, whereas with xe_assert it is if the condition is false. v2: - Rebase - Keep WARN splats in xe_wopcm.c (Matt Roper) v3: - Rebase Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: nuke GuC on unloadMatthew Auld
On PVC unloading followed by reloading the module often results in a completely dead machine (seems to be plaguing CI). Resetting the GuC like we do at load seems to cure it at least when locally testing this. v2: - Move pc_fini into guc_fini. We want to do the GuC reset just after calling pc_fini, otherwise we encounter communication failures. It also seems like a good idea to do the reset before we start releasing the various other GuC resources. In the case of pc_fini there is an explicit stop, but for other stuff like logs, ads, ctb there is not. References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/542 References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/597 Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: remove gucrc disable from suspend pathRiana Tauro
Currently GuCRC is disabled in suspend path for xe. Rc6 is a prerequiste to enable s0ix and should not be disabled for s2idle. There is no requirement to disable GuCRC for S3+. Remove it from xe_guc_pc_stop, thus removing from suspend path. Retain the call in other places where xe_guc_pc_stop is called. v2: add description and return statement to kernel-doc (Rodrigo) v3: update commit message (Rodrigo) v4: add mem_access_get to the gucrc disable function Signed-off-by: Riana Tauro <riana.tauro@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-21drm/xe: Cleanup CODE_INDENT style issuesFrancois Dugast
Remove all existing style issues of type CODE_INDENT reported by checkpatch. Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: don't auto fall back to execlist mode if guc failed to initChang, Bruce
In general, this is due to FW load failure, should just report error and fail the probe so that user can easily retry again. Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Bruce Chang <yu.bruce.chang@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Sort includesLucas De Marchi
Sort includes and split them in blocks: 1) .h corresponding to the .c. Example: xe_bb.c should have a "#include "xe_bb.h" first. 2) #include <linux/...> 3) #include <drm/...> 4) local includes 5) i915 includes This is accomplished by running `clang-format --style=file -i --sort-includes drivers/gpu/drm/xe/*.[ch]` and ignoring all the changes after the includes. There are also some manual tweaks to split the blocks. v2: Also sort includes in headers Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2023-12-19drm/xe: Use GuC to do GGTT invalidations for the GuC firmwareMatthew Brost
Only the GuC should be issuing TLB invalidations if it is enabled. Part of this patch is sanitize the device on driver unload to ensure we do not send GuC based TLB invalidations during driver unload. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com>
2023-12-12drm/xe: Introduce a new DRM driver for Intel GPUsMatthew Brost
Xe, is a new driver for Intel GPUs that supports both integrated and discrete platforms starting with Tiger Lake (first Intel Xe Architecture). The code is at a stage where it is already functional and has experimental support for multiple platforms starting from Tiger Lake, with initial support implemented in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as well as in NEO (for OpenCL and Level0). The new Xe driver leverages a lot from i915. As for display, the intent is to share the display code with the i915 driver so that there is maximum reuse there. But it is not added in this patch. This initial work is a collaboration of many people and unfortunately the big squashed patch won't fully honor the proper credits. But let's get some git quick stats so we can at least try to preserve some of the credits: Co-developed-by: Matthew Brost <matthew.brost@intel.com> Co-developed-by: Matthew Auld <matthew.auld@intel.com> Co-developed-by: Matt Roper <matthew.d.roper@intel.com> Co-developed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Co-developed-by: Francois Dugast <francois.dugast@intel.com> Co-developed-by: Lucas De Marchi <lucas.demarchi@intel.com> Co-developed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Co-developed-by: Philippe Lecluse <philippe.lecluse@intel.com> Co-developed-by: Nirmoy Das <nirmoy.das@intel.com> Co-developed-by: Jani Nikula <jani.nikula@intel.com> Co-developed-by: José Roberto de Souza <jose.souza@intel.com> Co-developed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Co-developed-by: Dave Airlie <airlied@redhat.com> Co-developed-by: Faith Ekstrand <faith.ekstrand@collabora.com> Co-developed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Co-developed-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com>