- 17 May, 2022 2 commits
-
-
Nirmoy Das authored
Determine lmem_size using ADDR_RANGE register so that lmem_setup() works on platform with small-bar as well. Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
Nirmoy Das authored
Caller of setup_lmem() ignores -ENODEV but failing to setup lmem on dGPU isn't ignorable error. Signed-off-by:
-
- 13 May, 2022 2 commits
-
-
Vinay Belgaumkar authored
To avoid false positives in error injection cases. Signed-off-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by:
Alan Previn <alan.previn.teres.alexis@intel.com> Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220506054142.5025-1-vinay.belgaumkar@intel.com
-
Nathan Chancellor authored
When an attribute group is created with sysfs_create_group(), the ->sysfs_ops() callback is set to kobj_sysfs_ops, which sets the ->show() callback to kobj_attr_show(). kobj_attr_show() uses container_of() to get the ->show() callback from the attribute it was passed, meaning the ->show() callback needs to be the same type as the ->show() callback in 'struct kobj_attribute'. However, show_dynamic_id() has the type of the ->show() callback in 'struct device_attribute', which causes a CFI violation when opening the 'id' sysfs node under drm/card0/metrics. This happens to work because the layout of 'struct kobj_attribute' and 'struct device_attribute' are the same, so the container_of() cast happens to allow the ->show() callback to still work. Change the type of show_dynamic_id() to match the ->show() callback in 'struct kobj_attributes' and update the type of sysfs_metric_id to match, which resolves the CFI violation. Fixes: f89823c2 ("drm/i915/perf: Implement I915_PERF_ADD/REMOVE_CONFIG interface") Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Sami Tolvanen <samitolvanen@google.com> Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220513075136.1027007-1-tvrtko.ursulin@linux.intel.com
-
- 12 May, 2022 1 commit
-
-
Umesh Nerlige Ramappa authored
There are 2 ways an engine can get reset in i915 and the method of reset affects how KMD labels a context as guilty/innocent. (1) GuC initiated engine-reset: GuC resets a hung engine and notifies KMD. The context that hung on the engine is marked guilty and all other contexts are innocent. The innocent contexts are resubmitted. (2) GT based reset: When an engine heartbeat fails to tick, KMD initiates a gt/chip reset. All active contexts are marked as guilty and discarded. In order to correctly mark the contexts as guilty/innocent, pass a mask of engines that were reset to __guc_reset_context. Fixes: eb5e7da7 ("drm/i915/guc: Reset implementation for new GuC interface") Signed-off-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by:
-
- 10 May, 2022 10 commits
-
-
Lucas De Marchi authored
The new Link Copy engines in PVC may be fused off according to the mslice_mask. Each bit of the MEML3_EN_MASK we read from the GEN10_MIRROR_FUSE3 register disables a pair of link copy engines. v2 (Tvrtko): - Minor cosmetic changes: s/u8/unsigned long/, use instance local variable. (Tvrtko) Bspec: 44483 Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220505213812.3979301-13-matthew.d.roper@intel.com
-
Lucas De Marchi authored
As we have more copy engines now, mask all of them from aux table invalidate. v2 (MattR): - Use I915_MAX_BCS to determine mask rather than hardcoding BCS8. (Prathap) Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Signed-off-by:
Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220505213812.3979301-12-matthew.d.roper@intel.com
-
Matt Roper authored
Add the reset support for new copy engines in PVC. Bspec: 52549 Original-author: CQ Tang Signed-off-by:
Stuart Summers <stuart.summers@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220505213812.3979301-11-matthew.d.roper@intel.com
-
Matt Roper authored
Add the interrupt handler support for new copy engines. Bspec: 54030 Original-author: CQ Tang Signed-off-by:
-
Matt Roper authored
This patch adds the basic definitions needed to support new copy engines. Also updating the cmd_info to accommodate new engines, as the engine id's of legacy engines have been changed. v2: - Add _BCS(n) definition, similar to other engines. (Tvrtko) - Add I915_MAX_BCS definition, similar to other engnes. (Prathap) - Move GVT change to avoid u16 overflow to its own patch. (Tvrtko) Original-author: CQ Tang Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Signed-off-by:
-
Matt Roper authored
When i915 adds additional PVC blitter instances (in an upcoming patch), the definition of VECS0 will change from bit(10) to bit(18), causing GVT's R_ALL mask to overflow the u16 storage that's currently used. Let's replace the u16 with an intel_engine_mask_t to ensure we avoid this. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Signed-off-by:
-
John Harrison authored
PVC adds extra blitter engines (in the following patch). The reset selftest has a local array on the stack which is sized by the number of engines. The increase pushes the size of this array to the point where it trips the 'stack too large' compile warning. This patch takes the allocation of the stack and makes it dynamic instead. v2 (MattR): - Minor cosmetic changes: re-sort definition and allocate using kmalloc_array(). (Tvrtko) Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by:
-
Matt Roper authored
The SoC registers, including RP_STATE_CAP, have moved to a new location in GTTMMADR on Ponte Vecchio. We need to update the register offset accordingly. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220505213812.3979301-5-matthew.d.roper@intel.com
-
Ayaz A Siddiqui authored
v2 (MattR): - Clarify comment above RING_CMD_CCTL programming. - Remove bspec reference from field definition. (Lucas) - Add WARN if we try to use a (presumably uninitialized) wb_index of 0. On most platforms 0 is an invalid MOCS entry and even on the ones where it isn't, it isn't the right setting for wb_index. (Lucas) Bspec: 45101, 72161 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Ayaz A Siddiqui <ayaz.siddiqui@intel.com> Signed-off-by:
Fei Yang <fei.yang@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Commit e4e80625 ("drm/i915: Change shrink ordering to use locking around unbinding.") changed the return type to int without changing the return values or their meaning to "0 is success". Move it back to boolean. Signed-off-by:
-
- 09 May, 2022 2 commits
-
-
Tvrtko Ursulin authored
If i915 does not want to use huge pages there is a) no point in setting up the private mount and b) should former fail, it is misleading to log THP support is disabled in the caller, which does not even know if callee tried to enable it. Fix both by restructuring the flow in i915_gemfs_init and at the same time note the failure to set it up in all cases. Signed-off-by:
-
Tvrtko Ursulin authored
We have a statement from HW designers that the GPU read regression when using 2M pages was fixed from Icelake onwards, which was also confirmed by bencharking Eero did last year: """ When IOMMU is disabled, enabling THP causes following perf changes on TGL-H (GT1): 10-15% SynMark Batch[0-3] 5-10% MemBW GPU texture, SynMark ShMapVsm 3-5% SynMark TerrainFly* + Geom* + Fill* + CSCloth + Batch4 1-3% GpuTest Triangle, SynMark TexMem* + DeferredAA + Batch[5-7] + few others -7% MemBW GPU blend In the above 3D benchmark names, * means all the variants of tests with the same prefix. For example "SynMark TexMem*", means both TexMem128 & TexMem512 tests in the synthetic (Intel internal) SynMark test suite. In the (public, but proprietary) GfxBench & GLB(enchmark) test suites, there are both onscreen and offscreen variants of each test. Unless explicitly stated otherwise, numbers are for both variants. All tests are run with FullHD monitor. All tests are fullscreen except for GLB and GpuTest ones, which are run in 1/2 screen window (GpuTest triangle is run both in fullscreen and 1/2 screen window). """ Since the only regression is MemBW GPU blend, against many more gains, it sounds it is time to enable THP on Gen11+. Signed-off-by:
-
- 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:
-
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 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:
-
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:
-
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:
-
- 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:
-
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:
-
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 1 commit
-
-
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:
-
