- 06 Aug, 2024 4 commits
-
-
David Gow authored
In commit a78a8da5 ("drm/ttm: replace busy placement with flags v6"), __i915_ttm_get_pages was updated to use flags instead of the separate 'busy' placement list. However, the behaviour was subtly changed. Originally, the function would attempt to use the preferred placement without eviction, and give an opportunity to restart the operation before falling back to allowing eviction. This was unintentionally changed, as the preferred placement was not given the TTM_PL_FLAG_DESIRED flag, and so eviction could be triggered in that first pass. This caused thrashing, and a significant performance regression on DG2 systems with small BAR. For example, Minecraft and Team Fortress 2 would drop to single-digit framerates. Restore the original behaviour by marking the initial placement as desired on that first attempt. Also, rework this to use a separate struct ttm_palcement, as the individual placements are marked 'const', so hot-patching the flags is even more dodgy than before. Thanks to Justin Brewer for bisecting this. Fixes: a78a8da5 ("drm/ttm: replace busy placement with flags v6") Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11255Signed-off-by:
David Gow <david@davidgow.net> Reviewed-by:
Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
-
David Gow authored
In commit a78a8da5 ("drm/ttm: replace busy placement with flags v6"), the old system of having a separate placement list (for placements which should be used without eviction) and a 'busy' placement list (for placements which should be attempted if eviction is required) was replaced with a new one where placements could be marked 'FALLBACK' (to be attempted if eviction is required) or 'DESIRED' (to be attempted first, but not if eviction is required). i915 had always included the requested placement in the list of 'busy' placements: i.e., the placement could be used either if eviction is required or not. But when the new system was put in place, the requested (first) placement was marked 'DESIRED', so would never be used if eviction became necessary. While a bug in the original commit prevented this flag from working, when this was fixed in 4a0e7b3c ("drm/i915: fix applying placement flag"), it caused long hangs on DG2 systems with small BAR. Don't mark the requested placement DESIRED (or FALLBACK), allowing it to be used in both situations. This matches the old behaviour, and resolves the hangs. Thanks to Justin Brewer for bisecting the issue. Fixes: a78a8da5 ("drm/ttm: replace busy placement with flags v6") Fixes: 4a0e7b3c ("drm/i915: fix applying placement flag") Link: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11255Signed-off-by:
-
Andi Shyti authored
Calculating the size of the mapped area as the lesser value between the requested size and the actual size does not consider the partial mapping offset. This can cause page fault access. Fix the calculation of the starting and ending addresses, the total size is now deduced from the difference between the end and start addresses. Additionally, the calculations have been rewritten in a clearer and more understandable form. Fixes: c58305af ("drm/i915: Use remap_io_mapping() to prefault all PTE in a single pass") Reported-by:
Jann Horn <jannh@google.com> Co-developed-by:
Chris Wilson <chris.p.wilson@linux.intel.com> Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240802083850.103694-3-andi.shyti@linux.intel.com
-
Andi Shyti authored
When mapping a framebuffer object, the virtual memory area (VMA) offset ('vm_pgoff') should be adjusted by the start of the 'vma_node' associated with the object. This ensures that the VMA offset is correctly aligned with the corresponding offset within the GGTT aperture. Increment vm_pgoff by the start of the vma_node with the offset= provided by the user. Suggested-by:Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: <stable@vger.kernel.org> # v4.9+ [Joonas: Add Cc: stable] Signed-off-by:
-
- 05 Aug, 2024 2 commits
-
-
Krzysztof Niemiec authored
While the uabi_engines_llist is populated in intel_engines_init() during driver load, the corresponding function intel_engines_release() does not correctly get rid of it. This can lead to a UAF if, after failed initialization (for example when gt is set wedged on init), we try to access the engines. Suggested-by:
Krzysztof Niemiec <krzysztof.niemiec@intel.com> Reviewed-by:
-
Nitin Gote authored
Wa_14019789679 implementation for MTL, ARL and DG2. v2: Corrected condition v3: - Fix indentation (Jani Nikula) - dword size should be 0x1 and initialize dword to 0 instead of MI_NOOP (Tejas) - Use IS_GFX_GT_IP_RANGE() (Tejas) v4: - 3DSTATE_MESH_CONTROL instruction is 3 dwords long Align with dword size. (Roper, Matthew D) - Add RCS engine check. (Tejas) Bspec: 47083 Signed-off-by:Nitin Gote <nitin.r.gote@intel.com> Reviewed-by:
Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
- 18 Jul, 2024 3 commits
-
-
John Harrison authored
There is a new part to an existing workaround, so enable that piece as well. v2: Extend even further. v3: Drop DG2 as there are CI failures still to resolve. Also re-order the parameters to a function to reduce excessive line wrapping. Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Reviewed-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240622004636.662081-3-John.C.Harrison@Intel.com
-
John Harrison authored
The context switch out workaround also applies to ARL. Signed-off-by:
-
Jonathan Cavitt authored
Prevent a NULL pointer access in intel_memory_regions_hw_probe. Fixes: 05da7d9f ("drm/i915/gem: Downgrade stolen lmem setup warning") Reported-by:
Dan Carpenter <dan.carpenter@linaro.org> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11704Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
-
- 15 Jul, 2024 1 commit
-
-
Nitin Gote authored
We're seeing a GPU hang issue on a CHV platform, which was caused by commit bac24f59 ("drm/i915/execlists: Enable coarse preemption boundaries for Gen8"). The Gen8 platform only supports timeslicing and doesn't have a preemption mechanism, as its engines do not have a preemption timer. Commit 751f82b3 ("drm/i915/gt: Only disable preemption on Gen8 render engines") addressed this issue only for render engines. This patch extends that fix by ensuring that preemption is not considered for all engines on Gen8 platforms. v4: - Use the correct Fixes tag (Rodrigo Vivi) - Reworded commit log (Andi Shyti) v3: - Inside need_preempt(), condition of can_preempt() is not required as simplified can_preempt() is enough. (Chris Wilson) v2: Simplify can_preempt() function (Tvrtko Ursulin) Fixes: 751f82b3 ("drm/i915/gt: Only disable preemption on gen8 render engines") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11396Suggested-by:
Andi Shyti <andi.shyti@intel.com> Signed-off-by:
-
- 09 Jul, 2024 1 commit
-
-
Umesh Nerlige Ramappa authored
PWR_CLK_STATE only needs to be modified up until gen11. For gen12 this code is not applicable. Remove code to update context image with PWR_CLK_STATE for gen12. Fixes: 00a7f0d7 ("drm/i915/tgl: Add perf support on TGL") Signed-off-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240629005643.3050678-1-umesh.nerlige.ramappa@intel.com
-
- 27 Jun, 2024 1 commit
-
-
Nirmoy Das authored
We report object allocation failures to userspace with ENOMEM so add __GFP_NOWARN to remove superfluous oom warnings. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/4936 Cc: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
-
- 20 Jun, 2024 2 commits
-
-
Andi Shyti authored
Commit 05da7d9f ("drm/i915/gem: Downgrade stolen lmem setup warning") adds a debug message where the "lmem_size" and "dsm_base" variables are printed using the %lli identifier. However, these variables are defined as resource_size_t, which are unsigned long for 32-bit machines and unsigned long long for 64-bit machines. The documentation (core-api/printk-formats.rst) recommends using the %pa specifier for printing addresses and sizes of resources. Replace %lli with %pa. This patch also mutes the following sparse warning when compiling with: make W=1 ARCH=i386 drivers/gpu/drm/i915 >> drivers/gpu/drm/i915/gem/i915_gem_stolen.c:941:5: error: format '%lli' expects argument of type 'long long int', but argument 5 has type 'resource_size_t' {aka 'unsigned int'} [-Werror=format=] Signed-off-by:
-
Andi Shyti authored
Commit 05da7d9f ("drm/i915/gem: Downgrade stolen lmem setup warning") returns '0' from i915_gem_stolen_lmem_setup(), but it's supposed to return a pointer to the intel_memory_region structure. Sparse complains with the following message: >> drivers/gpu/drm/i915/gem/i915_gem_stolen.c:943:32: sparse: sparse: Using plain integer as NULL pointer Return NULL. Signed-off-by:
-
- 19 Jun, 2024 1 commit
-
-
Janusz Krzysztofik authored
CI has been sporadically reporting the following issue triggered by igt@i915_selftest@live@hangcheck on ADL-P and similar machines: <6> [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence ... <6> [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled <6> [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled <3> [414.070354] Unable to pin Y-tiled fence; err:-4 <3> [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&fence->active)) ... <4>[ 609.603992] ------------[ cut here ]------------ <2>[ 609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301! <4>[ 609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <4>[ 609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G U W 6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1 <4>[ 609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023 <4>[ 609.604010] Workqueue: i915 __i915_gem_free_work [i915] <4>[ 609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915] ... <4>[ 609.604271] Call Trace: <4>[ 609.604273] <TASK> ... <4>[ 609.604716] __i915_vma_evict+0x2e9/0x550 [i915] <4>[ 609.604852] __i915_vma_unbind+0x7c/0x160 [i915] <4>[ 609.604977] force_unbind+0x24/0xa0 [i915] <4>[ 609.605098] i915_vma_destroy+0x2f/0xa0 [i915] <4>[ 609.605210] __i915_gem_object_pages_fini+0x51/0x2f0 [i915] <4>[ 609.605330] __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915] <4>[ 609.605440] process_scheduled_works+0x351/0x690 ... In the past, there were similar failures reported by CI from other IGT tests, observed on other platforms. Before commit 63baf4f3 ("drm/i915/gt: Only wait for GPU activity before unbinding a GGTT fence"), i915_vma_revoke_fence() was waiting for idleness of vma->active via fence_update(). That commit introduced vma->fence->active in order for the fence_update() to be able to wait selectively on that one instead of vma->active since only idleness of fence registers was needed. But then, another commit 0d86ee35 ("drm/i915/gt: Make fence revocation unequivocal") replaced the call to fence_update() in i915_vma_revoke_fence() with only fence_write(), and also added that GEM_BUG_ON(!i915_active_is_idle(&fence->active)) in front. No justification was provided on why we might then expect idleness of vma->fence->active without first waiting on it. The issue can be potentially caused by a race among revocation of fence registers on one side and sequential execution of signal callbacks invoked on completion of a request that was using them on the other, still processed in parallel to revocation of those fence registers. Fix it by waiting for idleness of vma->fence->active in i915_vma_revoke_fence(). Fixes: 0d86ee35 ("drm/i915/gt: Make fence revocation unequivocal") Closes: https://gitlab.freedesktop.org/drm/intel/issues/10021Signed-off-by:
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: stable@vger.kernel.org # v5.8+ Reviewed-by:
-
- 15 Jun, 2024 2 commits
-
-
Andi Shyti authored
The ce->guc_state.lock was made to protect guc_prio, which indicates the GuC priority level. But at the begnning of the function we perform some sanity check of guc_prio outside its protected section. Move them within the locked region. Use this occasion to expand the if statement to make it clearer. Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240613222402.551625-2-andi.shyti@linux.intel.com
-
Andi Shyti authored
Replace "dynmically" with "dynamically". Signed-off-by:
-
- 12 Jun, 2024 1 commit
-
-
Jonathan Cavitt authored
In the case where lmem_size < dsm_base, hardware is reporting that stolen lmem is unusable. In this case, instead of throwing a warning, we can continue execution as normal by disabling stolen LMEM support. For example, this change will allow the following error report from ATS-M to no longer apply: <6> [144.859887] pcieport 0000:4b:00.0: bridge window [mem 0xb1000000-0xb11fffff] <6> [144.859900] pcieport 0000:4b:00.0: bridge window [mem 0x3bbc00000000-0x3bbc17ffffff 64bit pref] <6> [144.859917] pcieport 0000:4c:01.0: PCI bridge to [bus 4d-4e] <6> [144.859932] pcieport 0000:4c:01.0: bridge window [mem 0xb1000000-0xb11fffff] <6> [144.859945] pcieport 0000:4c:01.0: bridge window [mem 0x3bbc00000000-0x3bbc17ffffff 64bit pref] <6> [144.859984] i915 0000:4d:00.0: [drm] BAR2 resized to 256M <6> [144.860640] i915 0000:4d:00.0: [drm] Using a reduced BAR size of 256MiB. Consider enabling 'Resizable BAR' or similar, if available in the BIOS. <4> [144.860719] -----------[ cut here ]----------- <4> [144.860727] WARNING: CPU: 17 PID: 1815 at drivers/gpu/drm/i915/gem/i915_gem_stolen.c:939 i915_gem_stolen_lmem_setup+0x38c/0x430 [i915] <4> [144.861430] Modules linked in: i915 snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core snd_pcm vgem drm_shmem_helper prime_numbers i2c_algo_bit ttm video drm_display_helper drm_buddy fuse x86_pkg_temp_thermal coretemp kvm_intel kvm ixgbe mdio irqbypass ptp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pps_core i2c_i801 mei_me i2c_smbus mei wmi acpi_power_meter [last unloaded: i915] <4> [144.861611] CPU: 17 PID: 1815 Comm: i915_module_loa Tainted: G U 6.8.0-rc5-drmtip_1515-g78f49af27723+ #1 <4> [144.861624] Hardware name: Intel Corporation WHITLEY/WHITLEY, BIOS SE5C6200.86B.0020.P41.2109300305 09/30/2021 <4> [144.861632] RIP: 0010:i915_gem_stolen_lmem_setup+0x38c/0x430 [i915] <4> [144.862287] Code: ff 41 c1 e4 05 e9 ac fe ff ff 4d 63 e4 48 89 ef 48 85 ed 74 04 48 8b 7d 08 48 c7 c6 10 a3 7b a0 e8 e9 90 43 e1 e9 ee fd ff ff <0f> 0b 49 c7 c4 ed ff ff ff e9 e0 fd ff ff 0f b7 d2 48 c7 c6 00 d9 <4> [144.862299] RSP: 0018:ffffc90005607980 EFLAGS: 00010207 <4> [144.862315] RAX: fffffffffff00000 RBX: 0000000000000003 RCX: 0000000000000000 Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10833Suggested-by:
-
- 11 Jun, 2024 2 commits
-
-
Andi Shyti authored
The forcewake count and domains listing is multi process critical and the uncore provides a spinlock for such cases. Lock the forcewake evaluation section in the fw_domains_show() debugfs interface. Signed-off-by:
-
Angus Chen authored
The WA should be extended to cover VDBOX engine. We found that 28-channels 1080p VP9 encoding may hit this issue. v3: update the WA number and explain the reason why this workaround is needed v2: add WA number v1: initial version Signed-off-by:Angus Chen <angus.chen@intel.com> Reviewed-by:
-
- 07 Jun, 2024 1 commit
-
-
John Harrison authored
Enable another workaround that is implemented inside the GuC. v2: Use the correct Gen12 w/a id rather than the Xe version (review feedback from Matthew R) also extend to include ARL. Signed-off-by:
Julia Filipchuk <julia.filipchuk@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240528230515.479395-1-John.C.Harrison@Intel.com
-
- 06 Jun, 2024 2 commits
-
-
Niemiec, Krzysztof authored
The test is trying to push the heartbeat frequency to the limit, which might sometimes fail. Such a failure does not provide valuable information, because it does not indicate that there is something necessarily wrong with either the driver or the hardware. Remove the test to prevent random, unnecessary failures from appearing in CI. Suggested-by:
Chris Wilson <chris.p.wilson@intel.com> Signed-off-by:
-
Andi Shyti authored
Following the guidelines it takes 3 seconds to perform an FLR reset. Let's give it a bit more slack because this time can change depending on the platform and on the firmware Signed-off-by:
-
- 22 May, 2024 1 commit
-
-
Andi Shyti authored
The whole point of the previous fixes has been to change the CCS hardware configuration to generate only one stream available to the compute users. We did this by changing the info.engine_mask that is set during device probe, reset during the detection of the fused engines, and finally reset again when choosing the CCS mode. We can't use the engine_mask variable anymore, as with the current configuration, it imposes only one CCS no matter what the hardware configuration is. Before changing the engine_mask for the third time, save it and use it for calculating the CCS mode. After the previous changes, the user reported a performance drop to around 1/4. We have tested that the compute operations, with the current patch, have improved by the same factor. Fixes: 6db31251 ("drm/i915/gt: Enable only one CCS for compute workload") Signed-off-by:
Jian Ye <jian.ye@intel.com> Reviewed-by:
Gnattu OC <gnattuoc@me.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240517090616.242529-1-andi.shyti@linux.intel.com
-
- 16 May, 2024 6 commits
-
-
Arnd Bergmann authored
With gcc-7 and earlier, there are lots of warnings like In file included from <command-line>:0:0: In function '__guc_context_policy_add_priority.isra.66', inlined from '__guc_context_set_prio.isra.67' at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3292:3, inlined from 'guc_context_set_prio' at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3320:2: include/linux/compiler_types.h:399:38: error: call to '__compiletime_assert_631' declared with attribute error: FIELD_PREP: mask is not constant _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ ... drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2422:3: note: in expansion of macro 'FIELD_PREP' FIELD_PREP(GUC_KLV_0_KEY, GUC_CONTEXT_POLICIES_KLV_ID_##id) | \ ^~~~~~~~~~ Make sure that GUC_KLV_0_KEY is an unsigned value to avoid the warning. Fixes: 77b6f79d ("drm/i915/guc: Update to GuC version 69.0.3") Signed-off-by:Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
-
Tvrtko Ursulin authored
When debugging GPU hangs Mesa developers are finding it useful to replay the captured error state against the simulator. But due various simulator limitations which prevent replicating all hangs, one step further is being able to replay against a real GPU. This is almost doable today with the missing part being able to upload the captured context image into the driver state prior to executing the uploaded hanging batch and all the buffers. To enable this last part we add a new context parameter called I915_CONTEXT_PARAM_CONTEXT_IMAGE. It follows the existing SSEU configuration pattern of being able to select which context to apply against, paired with the actual image and its size. Since this is adding a new concept of debug only uapi, we hide it behind a new kconfig option and also require activation with a module parameter. Together with a warning banner printed at driver load, all those combined should be sufficient to guard against inadvertently enabling the feature. In terms of implementation we allow the legacy context set param to be used since that removes the need to record the per context data in the proto context, while still allowing flexibility of specifying context images for any context. Mesa MR using the uapi can be seen at: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27594 v2: * Fix whitespace alignment as per checkpatch. * Added warning on userspace misuse. * Rebase for extracting ce->default_state shadowing. v3: * Rebase for I915_CONTEXT_PARAM_LOW_LATENCY. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Carlos Santa <carlos.santa@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Carlos Santa <carlos.santa@intel.com> Signed-off-by:
Tvrtko Ursulin <tursulin@igalia.com> Signed-off-by:
Tvrtko Ursulin <tursulin@ursulin.net> Link: https://patchwork.freedesktop.org/patch/msgid/20240514145939.87427-2-tursulin@igalia.com
-
Tvrtko Ursulin authored
To enable adding override of the default engine context image let us start shadowing the per engine state in the context. Signed-off-by:
-
Tvrtko Ursulin authored
Some display refactoring patches are needed in order to allow conflict- less merging. Signed-off-by: -
Arunpravin Paneer Selvam authored
Allocate cleared blocks in the bias range when the DRM buddy's clear avail is zero. This will validate the bias range allocation in scenarios like system boot when no cleared blocks are available and exercise the fallback path too. The resulting blocks should always be dirty. v1:(Matthew) - move the size to the variable declaration section. - move the mm.clear_avail init to allocator init. Signed-off-by:
Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240514145636.16253-2-Arunpravin.PaneerSelvam@amd.com
-
Arunpravin Paneer Selvam authored
Problem statement: During the system boot time, an application request for the bulk volume of cleared range bias memory when the clear_avail is zero, we dont fallback into normal allocation method as we had an unnecessary clear_avail check which prevents the fallback method leads to fb allocation failure following system goes into unresponsive state. Solution: Remove the unnecessary clear_avail check in the range bias allocation function. v2: add a kunit for this corner case (Daniel Vetter) Signed-off-by:
-
- 14 May, 2024 1 commit
-
-
Chris Wilson authored
The breadcrumbs use a GT wakeref for guarding the interrupt, but are disarmed during release of the engine wakeref. This leaves a hole where we may attach a breadcrumb just as the engine is parking (after it has parked its breadcrumbs), execute the irq worker with some signalers still attached, but never be woken again. That issue manifests itself in CI with IGT runner timeouts while tests are waiting indefinitely for release of all GT wakerefs. <6> [209.151778] i915: Running live_engine_pm_selftests/live_engine_busy_stats <7> [209.231628] i915 0000:00:02.0: [drm:intel_power_well_disable [i915]] disabling PW_5 <7> [209.231816] i915 0000:00:02.0: [drm:intel_power_well_disable [i915]] disabling PW_4 <7> [209.231944] i915 0000:00:02.0: [drm:intel_power_well_disable [i915]] disabling PW_3 <7> [209.232056] i915 0000:00:02.0: [drm:intel_power_well_disable [i915]] disabling PW_2 <7> [209.232166] i915 0000:00:02.0: [drm:intel_power_well_disable [i915]] disabling DC_off <7> [209.232270] i915 0000:00:02.0: [drm:skl_enable_dc6 [i915]] Enabling DC6 <7> [209.232368] i915 0000:00:02.0: [drm:gen9_set_dc_state.part.0 [i915]] Setting DC state from 00 to 02 <4> [299.356116] [IGT] Inactivity timeout exceeded. Killing the current test with SIGQUIT. ... <6> [299.356526] sysrq: Show State ... <6> [299.373964] task:i915_selftest state:D stack:11784 pid:5578 tgid:5578 ppid:873 flags:0x00004002 <6> [299.373967] Call Trace: <6> [299.373968] <TASK> <6> [299.373970] __schedule+0x3bb/0xda0 <6> [299.373974] schedule+0x41/0x110 <6> [299.373976] intel_wakeref_wait_for_idle+0x82/0x100 [i915] <6> [299.374083] ? __pfx_var_wake_function+0x10/0x10 <6> [299.374087] live_engine_busy_stats+0x9b/0x500 [i915] <6> [299.374173] __i915_subtests+0xbe/0x240 [i915] <6> [299.374277] ? __pfx___intel_gt_live_setup+0x10/0x10 [i915] <6> [299.374369] ? __pfx___intel_gt_live_teardown+0x10/0x10 [i915] <6> [299.374456] intel_engine_live_selftests+0x1c/0x30 [i915] <6> [299.374547] __run_selftests+0xbb/0x190 [i915] <6> [299.374635] i915_live_selftests+0x4b/0x90 [i915] <6> [299.374717] i915_pci_probe+0x10d/0x210 [i915] At the end of the interrupt worker, if there are no more engines awake, disarm the breadcrumb and go to sleep. Fixes: 9d5612ca ("drm/i915/gt: Defer enabling the breadcrumb interrupt to after submission") Closes: https://gitlab.freedesktop.org/drm/intel/issues/10026Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: <stable@vger.kernel.org> # v5.12+ Signed-off-by:
Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by:
-
- 13 May, 2024 1 commit
-
-
Deming Wang authored
The mapings should be replaced by mappings. Reviewed-by:
Deming Wang <wangdeming@inspur.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240513061451.1627-1-wangdeming@inspur.comSigned-off-by:
-
- 10 May, 2024 3 commits
-
-
Dave Airlie authored
Merge tag 'drm-xe-next-fixes-2024-05-09-1' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Driver Changes: - Use ordered WQ for G2H handler. (Matthew Brost) - Use flexible-array rather than zero-sized (Lucas De Marchi) Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2024-05-08' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next-fixes for v6.10-rc1: - panthor fixes. - Reverting Kconfig changes, and moving drm options to submenu. - Hide physical fb address in fb helper. - zynqmp bridge fix. - Revert broken ti-sn65dsi83 fix. Signed-off-by:
-
https://gitlab.freedesktop.org/drm/msmDave Airlie authored
Updates for v6.10 Core: - Switched to generating register header files during build process instead of shipping pre-generated headers - Merged DPU and MDP4 format databases. DP: - Stop using compat string to distinguish DP and eDP cases - Added support for X Elite platform (X1E80100) - Reworked DP aux/audio support - Added SM6350 DP to the bindings (no driver changes, using SM8350 as a fallback compat) GPU: - a7xx perfcntr reg fixes - MAINTAINERS updates - a750 devcoredump support Signed-off-by:
-
- 09 May, 2024 2 commits
-
-
Lucas De Marchi authored
Zero-length arrays are deprecated and flexible arrays should be used instead: https://www.kernel.org/doc/html/v6.9-rc7/process/deprecated.html#zero-length-and-one-element-arraysReported-by:
kernel test robot <lkp@intel.com> Reported-by:
Julia Lawall <julia.lawall@inria.fr> Closes: https://lore.kernel.org/r/202405051824.AmjAI5Pg-lkp@intel.com/ Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit ee728423) Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com>
-
Matthew Brost authored
System work queues are shared, use a dedicated work queue for G2H processing to avoid G2H processing getting block behind system tasks. Fixes: dd08ebf6 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: <stable@vger.kernel.org> Signed-off-by:
Francois Dugast <francois.dugast@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240506034758.3697397-1-matthew.brost@intel.com (cherry picked from commit 50aec966) Signed-off-by:
-
- 08 May, 2024 3 commits
-
-
Ville Syrjälä authored
This extra macro level between the region IDs and their bitmasks just makes it harder to see what is used where. Get rid of the wrappers. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240502121423.1002-3-ville.syrjala@linux.intel.comReviewed-by:
-
Ville Syrjälä authored
The name 'HAS_REGION()' suggests we are checking for a single region, so seem more sensible to pass in the region ID rather than a bitmask. Signed-off-by:
-
Ville Syrjälä authored
HAS_REGION() takes a bitmask, not the region ID. This causes the GEM_BUG_ON() to assert that the SMEM region is available rather than the intended LMEM region. No real harm since SMEM is always available, but also not checking what was intended. Signed-off-by:
-
