#
2955ae81 |
| 02-Aug-2024 |
John Harrison <John.C.Harrison@Intel.com> |
drm/i915: ARL requires a newer GSC firmware
ARL and MTL share a single GSC firmware blob. However, ARL requires a newer version of it.
So add differentiate of the PCI ids for ARL from MTL and creat
drm/i915: ARL requires a newer GSC firmware
ARL and MTL share a single GSC firmware blob. However, ARL requires a newer version of it.
So add differentiate of the PCI ids for ARL from MTL and create ARL as a sub-platform of MTL. That way, all the existing workarounds and such still treat ARL as MTL exactly as before. However, now the GSC code can check for ARL and do an extra version check on the firmware before committing to it.
Also, the version extraction code has various ways of failing but the return code was being ignore and so the firmware load would attempt to continue anyway. Fix that by propagating the return code to the next level out.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Fixes: 213c43676beb ("drm/i915/mtl: Remove the 'force_probe' requirement for Meteor Lake") Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240802031051.3816392-1-John.C.Harrison@Intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 67733d7a71503fd3e32eeada371f8aa2516c5c95) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
show more ...
|
#
3f2f20da |
| 29-Dec-2023 |
Andi Shyti <andi.shyti@linux.intel.com> |
drm/i915/guc: Use the new gt_to_guc() wrapper
Get the guc reference from the gt using the gt_to_guc() helper.
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Nirmoy Das <nirmoy.
drm/i915/guc: Use the new gt_to_guc() wrapper
Get the guc reference from the gt using the gt_to_guc() helper.
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231229102734.674362-3-andi.shyti@linux.intel.com
show more ...
|
#
f1530f91 |
| 07-Aug-2023 |
Jonathan Cavitt <jonathan.cavitt@intel.com> |
drm/i915/gt: Apply workaround 22016122933 correctly
WA_22016122933 was recently applied to all MeteorLake engines, which is simultaneously too broad (should only apply to Media engines) and too spec
drm/i915/gt: Apply workaround 22016122933 correctly
WA_22016122933 was recently applied to all MeteorLake engines, which is simultaneously too broad (should only apply to Media engines) and too specific (should apply to all platforms that use the same media engine as MeteorLake). Correct this in cases where coherency settings are modified.
There were also two additional places where the workaround was applied unconditionally. The change was confirmed as necessary for all platforms, so the workaround label was removed.
Suggested-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Acked-by: Fei Yang <fei.yang@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230801153242.2445478-4-jonathan.cavitt@intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20230807121957.598420-4-andi.shyti@linux.intel.com
show more ...
|
#
115cdcca |
| 07-Aug-2023 |
Jonathan Cavitt <jonathan.cavitt@intel.com> |
drm/i915: Make i915_coherent_map_type GT-centric
Refactor i915_coherent_map_type to be GT-centric rather than device-centric. Each GT may require different coherency handling due to hardware workar
drm/i915: Make i915_coherent_map_type GT-centric
Refactor i915_coherent_map_type to be GT-centric rather than device-centric. Each GT may require different coherency handling due to hardware workarounds.
Since the function now takes a GT instead of the i915, the function is renamed and moved to the gt folder.
Suggested-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Acked-by: Fei Yang <fei.yang@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230801153242.2445478-3-jonathan.cavitt@intel.com Link: https://patchwork.freedesktop.org/patch/msgid/20230807121957.598420-3-andi.shyti@linux.intel.com
show more ...
|
#
b1cef13e |
| 20-Jul-2023 |
Alan Previn <alan.previn.teres.alexis@intel.com> |
drm/i915/selftest/gsc: Ensure GSC Proxy init completes before selftests
On MTL, if the GSC Proxy init flows haven't completed, submissions to the GSC engine will fail. Those init flows are dependent
drm/i915/selftest/gsc: Ensure GSC Proxy init completes before selftests
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: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230720230126.375566-1-alan.previn.teres.alexis@intel.com
show more ...
|
#
aee90e92 |
| 15-Jun-2023 |
Alan Previn <alan.previn.teres.alexis@intel.com> |
drm/i915/gsc: Fix intel_gsc_uc_fw_proxy_init_done with directed wakerefs
intel_gsc_uc_fw_proxy_init_done is used by a few code paths and usages. However, certain paths need a wakeref while others ca
drm/i915/gsc: Fix intel_gsc_uc_fw_proxy_init_done with directed wakerefs
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: 8c33c3755b75 ("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: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230615211940.4061378-1-alan.previn.teres.alexis@intel.com
show more ...
|
#
561055b8 |
| 12-Jun-2023 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/mtl/gsc: Add a gsc_info debugfs
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
drm/i915/mtl/gsc: Add a gsc_info debugfs
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 <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230612181529.2222451-5-daniele.ceraolospurio@intel.com
show more ...
|
#
a6c13a23 |
| 12-Jun-2023 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/mtl/gsc: query the GSC FW for its compatibility version
The compatibility version is queried via an MKHI command. Right now, the only existing interface is 1.0 This is basically the interfa
drm/i915/mtl/gsc: query the GSC FW for its compatibility version
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 <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230612181529.2222451-4-daniele.ceraolospurio@intel.com
show more ...
|
#
56fafa56 |
| 12-Jun-2023 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/mtl/gsc: extract release and security versions from the gsc binary
The release and security versions of the GSC binary are not used at runtime to decide interface compatibility (there is a
drm/i915/mtl/gsc: extract release and security versions from the gsc binary
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 <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230612181529.2222451-3-daniele.ceraolospurio@intel.com
show more ...
|
#
b267a670 |
| 12-Jun-2023 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/gsc: fixes and updates for GSC memory allocation
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 follo
drm/i915/gsc: fixes and updates for GSC memory allocation
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: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230612181529.2222451-2-daniele.ceraolospurio@intel.com
show more ...
|
#
8c33c375 |
| 08-Jun-2023 |
Alan Previn <alan.previn.teres.alexis@intel.com> |
drm/i915/gsc: take a wakeref for the proxy-init-completion check
Ensure intel_gsc_uc_fw_init_done and intel_gsc_uc_fw_proxy_init takes a wakeref before reading GSC Shim registers.
NOTE: another pat
drm/i915/gsc: take a wakeref for the proxy-init-completion check
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: 99afb7cc8c44 ("drm/i915/pxp: Add ARB session creation and cleanup") Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230608230716.3079594-1-alan.previn.teres.alexis@intel.com
show more ...
|
#
8a9bf295 |
| 02-May-2023 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/gsc: add initial support for GSC proxy
The GSC uC needs to communicate with the CSME to perform certain operations. Since the GSC can't perform this communication directly on platforms wher
drm/i915/gsc: add initial support for GSC proxy
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, i915 needs to transfer the messages from GSC to CSME and back. The proxy flow is as follow: 1 - i915 submits a request to GSC asking for the message to CSME 2 - GSC replies with the proxy header + payload for CSME 3 - i915 sends the reply from GSC as-is to CSME via the mei proxy component 4 - CSME replies with the proxy header + payload for GSC 5 - i915 submits a request to GSC with the reply from CSME 6 - GSC replies either with a new header + payload (same as step 2, so we restart from there) or with an end message.
After GSC load, i915 is expected to start the first proxy message chain, while all subsequent ones will be triggered by the GSC via interrupt.
To communicate with the CSME, we use a dedicated mei component, which means that we need to wait for it to bind before we can initialize the proxies. This usually happens quite fast, but given that there is a chance that we'll have to wait a few seconds the GSC work has been moved to a dedicated WQ to not stall other processes.
v2: fix code style, includes and variable naming (Alan) v3: add extra check for proxy status, fix includes and comments
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230502163854.317653-4-daniele.ceraolospurio@intel.com
show more ...
|
#
a161b6db |
| 24-Apr-2023 |
Fei Yang <fei.yang@intel.com> |
drm/i915/mtl: workaround coherency issue for Media
This patch implements Wa_22016122933.
In MTL, memory writes initiated by the Media tile update the whole cache line, even for partial writes. This
drm/i915/mtl: workaround coherency issue for Media
This patch implements Wa_22016122933.
In MTL, memory writes initiated by the Media tile update the whole cache line, even for partial writes. This creates a coherency problem for cacheable memory if both CPU and GPU are writing data to different locations within a single cache line. This patch circumvents the issue by making CPU/GPU shared memory uncacheable (WC on CPU side, and PAT index 2 for GPU). Additionally, it ensures that CPU writes are visible to the GPU with an intel_guc_write_barrier().
While fixing the CTB issue, we noticed some random GSC firmware loading failure because the share buffers are cacheable (WB) on CPU side but uncached on GPU side. To fix these issues we need to map such shared buffers as WC on CPU side. Since such allocations are not all done through GuC allocator, to avoid too many code changes, the i915_coherent_map_type() is now hard coded to return WC for MTL.
v2: Simplify the commit message(Matt).
BSpec: 45101
Signed-off-by: Fei Yang <fei.yang@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230424182902.3663500-3-fei.yang@intel.com
show more ...
|
#
58041996 |
| 07-Feb-2023 |
John Harrison <John.C.Harrison@Intel.com> |
drm/i915/guc: More debug print updates - GSC firmware
Update a bunch more debug prints to use the new GT based scheme.
v2: Also change prints to use %pe for error values (MichalW).
Signed-off-by:
drm/i915/guc: More debug print updates - GSC firmware
Update a bunch more debug prints to use the new GT based scheme.
v2: Also change prints to use %pe for error values (MichalW).
Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230207050717.1833718-3-John.C.Harrison@Intel.com
show more ...
|
#
5a44fcd7 |
| 08-Dec-2022 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded
If the GSC was loaded, the only way to stop it during the driver unload flow is to do a driver-FLR. The driver-initiated FLR is not the same
drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded
If the GSC was loaded, the only way to stop it during the driver unload flow is to do a driver-FLR. The driver-initiated FLR is not the same as PCI config space FLR in that it doesn't reset the SGUnit and doesn't modify the PCI config space. Thus, it doesn't require a re-enumeration of the PCI BARs. However, the driver-FLR does cause a memory wipe of graphics memory on all discrete GPU platforms or a wipe limited to stolen memory on the integrated GPU platforms.
We perform the FLR as the last action before releasing the MMIO bar, so that we don't have to care about the consequences of the reset on the unload flow.
v2: rename FLR function, add comment to explain FLR impact (Rodrigo), better explain why GSC needs FLR (Alan)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221208200521.2928378-5-daniele.ceraolospurio@intel.com
show more ...
|
#
15bd4a67 |
| 08-Dec-2022 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/gsc: GSC firmware loading
GSC FW is loaded by submitting a dedicated command via the GSC engine. The memory area used for loading the FW is then re-purposed as local memory for the GSC itse
drm/i915/gsc: GSC firmware loading
GSC FW is loaded by submitting a dedicated command via the GSC engine. The memory area used for loading the FW is then re-purposed as local memory for the GSC itself, so we use a separate allocation instead of using the one where we keep the firmware stored for reload.
The GSC is not reset as part of GT reset, so we only need to load it on first boot and S3/S4 exit.
v2: use REG_* for register fields definitions (Rodrigo), move to WQ immediately
v3: mark worker function as static
Bspec: 63347, 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> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221208200521.2928378-4-daniele.ceraolospurio@intel.com
show more ...
|