- 06 May, 2022 10 commits
-
-
José Roberto de Souza authored
No need to have this parameter in intel_device_info struct as all platforms with display version 9 or newer has this feature. As a side effect of the of removal this flag, it will not be printed in dmesg during driver load anymore and developers will have to rely on to check the macro and compare with platform being used and IP versions of it. Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220505193524.276400-7-jose.souza@intel.com
-
José Roberto de Souza authored
No need to have this parameter in intel_device_info struct as the requirement to support it is the DDI support. As a side effect of the of removal this flag, it will not be printed in dmesg during driver load anymore and developers will have to rely on to check the macro and compare with platform being used and IP versions of it. Reviewed-by:
-
José Roberto de Souza authored
No need to have this parameter in intel_device_info struct as all platforms with display version 9 or newer, haswell or broadwell supports it. As a side effect of the of removal this flag, it will not be printed in dmesg during driver load anymore and developers will have to rely on to check the macro and compare with platform being used and IP versions of it. Reviewed-by:
-
José Roberto de Souza authored
No need to have this parameter in intel_device_info struct as all platforms with graphics version 11 or newer has this feature. As a side effect of the of removal this flag, it will not be printed in dmesg during driver load anymore and developers will have to rely on to check the macro and compare with platform being used and IP versions of it. Reviewed-by:
-
José Roberto de Souza authored
No need to have this parameter in intel_device_info struct as all platforms with graphics version 7 or newer can reset engines. As a side effect of the of removal this flag, it will not be printed in dmesg during driver load anymore and developers will have to rely on to check the macro and compare with platform being used and IP versions of it. Reviewed-by:
-
José Roberto de Souza authored
No need to have this parameter in intel_device_info struct as all platforms with graphics version 6 or newer have software support for this feature. As a side effect of the of removal this flag, it will not be printed in dmesg during driver load anymore and developers will have to rely on to check the macro and compare with platform being used and IP versions of it. Reviewed-by:
-
José Roberto de Souza authored
No need to have this parameter in intel_device_info struct as all platforms with graphics version 9 or newer has graphics microcontroller. As a side effect of the of removal this flag, it will not be printed in dmesg during driver load anymore and developers will have to rely on to check the macro and compare with platform being used and IP versions of it. Reviewed-by:
-
YueHaibing authored
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c: In function ‘act_freq_mhz_show’: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:276:20: error: implicit declaration of function ‘sysfs_gt_attribute_r_max_func’ [-Werror=implicit-function-declaration] 276 | u32 actual_freq = sysfs_gt_attribute_r_max_func(dev, attr, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Move sysfs_gt_attribute_* macros out of #ifdef block to fix this. Fixes: 56a709cf ("drm/i915/gt: Create per-tile RPS sysfs interfaces") Signed-off-by:YueHaibing <yuehaibing@huawei.com> Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220506032652.1856-1-yuehaibing@huawei.com
-
Tvrtko Ursulin authored
DRM_DEBUG_WARN_ON should only be used when we are certain CI is guaranteed to exercise a certain code path, so in case of values coming from MMIO reads we cannot be sure CI will have all the possible SKUs and parts, or that it will catch all possible error conditions. Use drm_warn instead. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220505110007.943449-2-tvrtko.ursulin@linux.intel.com
-
Tvrtko Ursulin authored
DRM_DEBUG_WARN_ON should only be used when we are certain CI is guaranteed to exercise a certain code path, so in case of values coming from MMIO reads we cannot be sure CI will have all the possible SKUs and parts. Use drm_warn instead and move logging to init phase while at it. v2: * GEM_WARN_ON in intel_gt_get_valid_steering. Signed-off-by:
-
- 05 May, 2022 5 commits
-
-
Daniele Ceraolo Spurio authored
The previous patch introduced new failure cases in the HuC init flow that can be hit by simply changing the config, so we want to avoid failing the probe in those scenarios. HuC load failure is already considered a non-fatal error and we have a way to report to userspace if the HuC is not available via a dedicated getparam, so no changes in expectation there. The error message in the HuC init code has also been lowered to info to avoid throwing error message for an expected behavior. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220504204816.2082588-5-daniele.ceraolospurio@intel.com
-
Daniele Ceraolo Spurio authored
HuC loading via GSC is performed via a PXP command sent through the mei modules, so we need both MEI_GSC and MEI_PXP to be available. Given that the GSC will do both the transfer and the authentication, the legacy HuC loading paths can be safely skipped. Also note that the GSC-loaded HuC survives GT reset. v2: move the huc_is_authenticated() function to this patch. Signed-off-by:
Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220504204816.2082588-4-daniele.ceraolospurio@intel.com
-
Daniele Ceraolo Spurio authored
On newer platforms (starting DG2 G10 B-step and G11 A-step), ownership of HuC loading has been moved from the GuC to the GSC. As part of the change, the header format of the HuC binary has been updated and does not match the GuC anymore. The GSC will perform all the required checks on the binary size, so we only need to check that the version matches. Note that since we still haven't added any gsc-loaded FWs, the loaded_via_gsc variable will always be kept to its initialization value of zero. v2: Add a note about loaded_via_gsc being zero (Alan) Signed-off-by:
-
Daniele Ceraolo Spurio authored
The function name is confusing, because it doesn't check the actual auth status in HW but the SW status. Given that there is only one user (the huc_auth function itself), just get rid of it and use the FW status checker directly. Signed-off-by:
-
Matthew Brost authored
In GuC submission mode the EU priority must be updated by the GuC rather than the driver as the GuC owns the programming of the context descriptor. Given that the GuC code uses the GuC priorities, we can't use a generic function using i915 priorities for both execlists and GuC submission. The existing function has therefore been pushed to the execlists back-end while a new one has been added for GuC. v2: correctly use the GuC prio. Cc: John Harrison <john.c.harrison@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Signed-off-by:
Aravind Iddamsetty <aravind.iddamsetty@intel.com> Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220504234636.2119794-1-daniele.ceraolospurio@intel.com
-
- 04 May, 2022 2 commits
-
-
Karol Herbst authored
i915_vma_reopen checked if the vma is closed before without taking the lock. So multiple threads could attempt removing the vma. Instead the lock needs to be taken before actually checking. v2: move struct declaration Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v5.3+ Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5732Signed-off-by:
Karol Herbst <kherbst@redhat.com> Fixes: 155ab883 ("drm/i915: Move object close under its own lock") Reviewed-by:
-
Kefeng Wang authored
Use IOMEM_ERR_PTR() instead of self defined IO_ERR_PTR(). Signed-off-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
- 03 May, 2022 5 commits
-
-
Stuart Summers authored
Additional blitter and media engines will be enabled later. Bspec: 44481, 44482 Signed-off-by:
Stuart Summers <stuart.summers@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220502163417.2635462-2-matthew.d.roper@intel.com
-
Tvrtko Ursulin authored
Use lockdep_assert_not_held to simplify and correct the code. Otherwise false positive are hit if lock state is uknown like after a previous taint. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Remove the duplicate and incorrect (uses "" instead of <>) linux/string_helpers.h include. Fixes: cc1338f2 ("drm/i915/xehp: Update topology dumps for Xe_HP") Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Ramalingam C authored
Capture the eviction details for Flat-CCS capable, lmem objects. v2: Fix the Flat-ccs capbility of lmem obj with smem residency possibility [Thomas] v3: Fixed the suggestions [Matt] Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> cc: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220502142618.2704-4-ramalingam.c@intel.com
-
Ramalingam C authored
Calculate the ccs_sz that needs to be emitted based on the src and dst pages emitted per chunk. And handle the return value of emit_pte for the ccs pages. v2: ccs_sz moved to the reduced scope [Matt] Signed-off-by:
-
- 02 May, 2022 3 commits
-
-
Chris Wilson authored
Userspace may leave predication enabled upon return from the batch buffer, which has the consequent of preventing all operation from the ring from being executed, including all the synchronisation, coherency control, arbitration and user signaling. This is more than just a local gpu hang in one client, as the user has the ability to prevent the kernel from applying critical workarounds and can cause a full GT reset. We could simply execute MI_SET_PREDICATE upon return from the user batch, but this has the repercussion of modifying the user's context state. Instead, we opt to execute a fixup batch which by mixing predicated operations can determine the state of the SET_PREDICATE_RESULT register and restore it prior to the next userspace batch. This allows us to protect the kernel's ring without changing the uABI. Suggested-by:
Zbigniew Kempczynski <zbigniew.kempczynski@intel.com> Signed-off-by:
Chris Wilson <chris.p.wilson@intel.com> Cc: Zbigniew Kempczynski <zbigniew.kempczynski@intel.com> Cc: Thomas Hellstrom <thomas.hellstrom@intel.com> Signed-off-by:
-
Chris Wilson authored
When predication is enabled all commands baring a few (such as MI_BB_END) are nop'ed. If we accidentally enable predication while poisoning the context, not only is the rest of the poisoning skipped (thus disabling the test), but the closing instructions of the poison request are nop'ed. Not only do we then not signal the waiting context, but we even prevent re-enabling arbitration and the GPU will not perform a context switch at the end of the request. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Suggested-by:
CQ Tang <cq.tang@intel.com> Signed-off-by:
-
Akeem G Abodunrin authored
When bit 19 of MI_LOAD_REGISTER_IMM instruction opcode is set on tgl+ devices, HW does not care about certain register address offsets, but instead check the following for valid address ranges on specific engines: RCS && CCS: BITS(0 - 10) BCS: BITS(0 - 11) VECS && VCS: BITS(0 - 13) Also, tgl+ now support relative addressing for BCS engine - So, this patch fixes issue with live_gt_lrc selftest that is failing where there is mismatch between LRC register layout generated during init and HW default register offsets. Signed-off-by:
Akeem G Abodunrin <akeem.g.abodunrin@intel.com> cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Signed-off-by:
-
- 29 Apr, 2022 4 commits
-
-
Daniele Ceraolo Spurio authored
Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Signed-off-by:
Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by:
Jordan Justen <jordan.l.justen@intel.com> Tested-by: Jordan Justen <jordan.l.justen@intel.com> # mesa anvil & iris Link: https://patchwork.freedesktop.org/patch/msgid/20220428041926.1483683-5-matthew.d.roper@intel.com
-
Matt Roper authored
We're now ready to start exposing compute engines to userspace. v2: - Move kerneldoc for other engine classes to a separate patch. (Andi) Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Szymon Morek <szymon.morek@intel.com> UMD (mesa): https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14395Signed-off-by:
-
Matt Roper authored
Compute engines have a separate register that the driver should use to perform MMIO-based TLB invalidation. Note that the term "context" in this register's bspec description is used to refer to the engine instance (in the same way "context" is used on bspec 46167). Bspec: 43930 Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220428041926.1483683-3-matthew.d.roper@intel.com
-
Matt Roper authored
We'll be adding a new type of engine soon. Let's document the existing engine classes first to help make it clear what each type of engine is used for. Cc: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
-
- 28 Apr, 2022 2 commits
-
-
Umesh Nerlige Ramappa authored
Use intel_uncore_read64_2x32 to read upper and lower fields of the GPM timestamp. v2: Fix compile error Signed-off-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by:
-
John Harrison authored
First release of GuC for DG2. Signed-off-by:
-
- 21 Apr, 2022 9 commits
-
-
Tomas Winkler authored
DG2 uses different GSC offsets on memory bar and uses PXP head (HECI1). v2 (Daniele): Rebased to before the ATS patches Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> #v1 Signed-off-by:
-
Alexander Usyskin authored
Add a hook to retrieve the firmware version of the GSC devices to bus-fixup. GSC has a different MKHI clients GUIDs but the same message structure to retrieve the firmware version as MEI so mei_fwver() can be reused. CC: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by:
-
Tomas Winkler authored
Implement runtime handlers for mei-gsc, to track idle state of the device properly. CC: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Alexander Usyskin authored
Setup char device in spite of firmware handshake failure. In order to provide host access to the firmware status registers and other information required for the manufacturing process. Signed-off-by:
-
Tomas Winkler authored
GSC is a graphics system controller, based on CSE, it provides a chassis controller for graphics discrete cards, as well as it supports media protection on selected devices. mei_gsc binds to a auxiliary devices exposed by Intel discrete driver i915. v2: fix error check in mei_gsc_probe v3: update MODULE_LICENSE ("GPL" is preferred over "GPL v2" and they both map to GPL version 2) Signed-off-by: -
Tomas Winkler authored
GSC is a graphics system controller, it provides a chassis controller for graphics discrete cards. There are two MEI interfaces in GSC: HECI1 and HECI2. Both interfaces are on the BAR0 at offsets 0x00258000 and 0x00259000. GSC is a GT Engine (class 4: instance 6). HECI1 interrupt is signaled via bit 15 and HECI2 via bit 14 in the interrupt register. This patch exports GSC as auxiliary device for mei driver to bind to for HECI2 interface and prepares for HECI1 interface as it will follow up soon. CC: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Vitaly Lubart <vitaly.lubart@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
In order to get the GSC Support merged on drm-intel-gt-next in a clean fashion we needed this ATS-M patch to avoid conflict in i915_pci.c: commit 412c942b ("drm/i915/ats-m: add ATS-M platform info") -- Fixing a silent conflict on drivers/gpu/drm/i915/gt/intel_gt_gmch.c: - if (!intel_vtd_active(i915)) + if (!i915_vtd_active(i915)) Signed-off-by:
-
Matthew Auld authored
The compact-pt layout restrictions should only apply to the ppGTT. Also make this play nice on platforms that only have the 64K GTT restriction, and not the compact-pt thing. Signed-off-by:
Nirmoy Das <nirmoy.das@linux.intel.com> Reviewed-by:
-
Matthew Auld authored
Trying to cast the region id into the region type doesn't work too well, since the i915_vm_min_alignment() won't give us the correct value for the stolen-lmem case. Signed-off-by:
-
