aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-07-09i915/perf: Remove code to update PWR_CLK_STATE for gen12Umesh Nerlige Ramappa1-33/+0
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: 00a7f0d7155c ("drm/i915/tgl: Add perf support on TGL") Signed-off-by: Umesh Nerlige Ramappa <[email protected]> Reviewed-by: Ashutosh Dixit <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-28drm/i915/gem: Suppress oom warning in favour of ENOMEM to userspaceNirmoy Das1-4/+4
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 <[email protected]> Signed-off-by: Nirmoy Das <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-20drm/i915/gem: Use the correct format specifier for resource_size_tAndi Shyti1-2/+2
Commit 05da7d9f717b ("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 <[email protected]> Cc: Jonathan Cavitt <[email protected]> Reviewed-by: Jonathan Cavitt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-20drm/i915/gem: Return NULL instead of '0'Andi Shyti1-1/+1
Commit 05da7d9f717b ("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: Andi Shyti <[email protected]> Cc: Jonathan Cavitt <[email protected]> Reviewed-by: Jonathan Cavitt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-19drm/i915/gt: Fix potential UAF by revoke of fence registersJanusz Krzysztofik1-0/+1
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 63baf4f3d587 ("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 0d86ee35097a ("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: 0d86ee35097a ("drm/i915/gt: Make fence revocation unequivocal") Closes: https://gitlab.freedesktop.org/drm/intel/issues/10021 Signed-off-by: Janusz Krzysztofik <[email protected]> Cc: [email protected] # v5.8+ Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-15drm/i915/gt/uc: Evaluate GuC priority within locksAndi Shyti1-11/+16
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: Andi Shyti <[email protected]> Cc: Matthew Brost <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-15drm/i915/gt/uc: Fix typo in commentAndi Shyti1-1/+1
Replace "dynmically" with "dynamically". Signed-off-by: Andi Shyti <[email protected]> Cc: John Harrison <[email protected]> Reviewed-by: Jonathan Cavitt <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-12drm/i915/gem: Downgrade stolen lmem setup warningJonathan Cavitt1-2/+6
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/10833 Suggested-by: Chris Wilson <[email protected]> Signed-off-by: Jonathan Cavitt <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915/gt: debugfs: Evaluate forcewake usage within locksAndi Shyti1-0/+4
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: Andi Shyti <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Reviewed-by: Nirmoy Das <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-11drm/i915/mtl: Update workaround 14018575942Angus Chen1-0/+8
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 <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-06drm/i915/guc: Enable w/a 16021333562 for DG2, MTL and ARLJohn Harrison2-12/+21
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: John Harrison <[email protected]> Reviewed-by: Julia Filipchuk <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-06drm/i915/gt: Delete the live_hearbeat_fast selftestNiemiec, Krzysztof1-110/+0
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 <[email protected]> Signed-off-by: Niemiec, Krzysztof <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/fe2vu5h7v7ooxbhwpbfsypxg5mjrnt56gc3cgrqpnhgrgce334@qfrv2skxrp47
2024-06-06drm/i915: Increase FLR timeout from 3s to 9sAndi Shyti1-1/+8
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: Andi Shyti <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Reviewed-by: Nirmoy Das <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-22drm/i915/gt: Fix CCS id's calculation for CCS mode settingAndi Shyti3-1/+15
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: 6db31251bb26 ("drm/i915/gt: Enable only one CCS for compute workload") Signed-off-by: Andi Shyti <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Gnattu OC <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Matt Roper <[email protected]> Tested-by: Jian Ye <[email protected]> Reviewed-by: Umesh Nerlige Ramappa <[email protected]> Tested-by: Gnattu OC <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-16drm/i915/guc: avoid FIELD_PREP warningArnd Bergmann1-3/+3
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: 77b6f79df66e ("drm/i915/guc: Update to GuC version 69.0.3") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Michal Wajdeczko <[email protected]> Signed-off-by: Julia Filipchuk <[email protected]> Signed-off-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-16drm/i915: Support replaying GPU hangs with captured context imageTvrtko Ursulin10-3/+193
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 <[email protected]> Cc: Lionel Landwerlin <[email protected]> Cc: Carlos Santa <[email protected]> Cc: Rodrigo Vivi <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Tested-by: Carlos Santa <[email protected]> Signed-off-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-16drm/i915: Shadow default engine context image in the contextTvrtko Ursulin3-6/+10
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 <[email protected]> Cc: Lionel Landwerlin <[email protected]> Cc: Carlos Santa <[email protected]> Cc: Rodrigo Vivi <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-16Merge drm/drm-next into drm-intel-gt-nextTvrtko Ursulin26466-765336/+1864755
Some display refactoring patches are needed in order to allow conflict- less merging. Signed-off-by: Tvrtko Ursulin <[email protected]>
2024-05-16drm/tests: Add a unit test for range bias allocationArunpravin Paneer Selvam1-1/+35
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 <[email protected]> Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Dave Airlie <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-16drm/buddy: Fix the range bias clear memory allocation issueArunpravin Paneer Selvam1-1/+2
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: Arunpravin Paneer Selvam <[email protected]> Fixes: 96950929eb23 ("drm/buddy: Implement tracking clear page feature") Reviewed-by: Matthew Auld <[email protected]> Signed-off-by: Dave Airlie <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-14drm/i915/gt: Disarm breadcrumbs if engines are already idleChris Wilson1-8/+7
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: 9d5612ca165a ("drm/i915/gt: Defer enabling the breadcrumb interrupt to after submission") Closes: https://gitlab.freedesktop.org/drm/intel/issues/10026 Signed-off-by: Chris Wilson <[email protected]> Cc: Andrzej Hajda <[email protected]> Cc: <[email protected]> # v5.12+ Signed-off-by: Janusz Krzysztofik <[email protected]> Acked-by: Nirmoy Das <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-13drm/i915/gem/i915_gem_ttm_move: Fix typoDeming Wang1-1/+1
The mapings should be replaced by mappings. Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Deming Wang <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-05-10Merge tag 'drm-xe-next-fixes-2024-05-09-1' of ↵Dave Airlie4-2/+9
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 <[email protected]> From: Thomas Hellstrom <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/Zjz7SzCvfA3vQRxu@fedora
2024-05-10Merge tag 'drm-misc-next-fixes-2024-05-08' of ↵Dave Airlie31-160/+172
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: Dave Airlie <[email protected]> From: Maarten Lankhorst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-10Merge tag 'drm-msm-next-2024-05-07' of ↵Dave Airlie138-41421/+25419
https://gitlab.freedesktop.org/drm/msm into drm-next 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: Dave Airlie <[email protected]> From: Rob Clark <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGtpw6dNR9JBikFTQ=TCpt-9FeFW+SGjXWv+Jv3emm0Pbg@mail.gmail.com
2024-05-09drm/xe/ads: Use flexible-arrayLucas De Marchi1-1/+1
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-arrays Reported-by: kernel test robot <[email protected]> Reported-by: Julia Lawall <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Matthew Brost <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]> (cherry picked from commit ee7284230644e21fef0e38fc5bf8f907b6bb7f7c) Signed-off-by: Thomas Hellström <[email protected]>
2024-05-09drm/xe: Use ordered WQ for G2H handlerMatthew Brost3-1/+8
System work queues are shared, use a dedicated work queue for G2H processing to avoid G2H processing getting block behind system tasks. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: <[email protected]> Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Francois Dugast <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 50aec9665e0babd62b9eee4e613d9a1ef8d2b7de) Signed-off-by: Thomas Hellström <[email protected]>
2024-05-08drm/i915: Remove counter productive REGION_* wrappersVille Syrjälä3-9/+4
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ä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi <[email protected]>
2024-05-08drm/i915: Pass the region ID rather than a bitmask to HAS_REGION()Ville Syrjälä3-4/+4
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ä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi <[email protected]>
2024-05-08drm/i915: Fix HAS_REGION() usage in intel_gt_probe_lmem()Ville Syrjälä1-1/+1
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: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi <[email protected]>
2024-05-07Revert "drm/i915: Remove extra multi-gt pm-references"Janusz Krzysztofik1-0/+18
This reverts commit 1f33dc0c1189efb9ae19c6fc22b64dd3e26261fb. There was a patch supposed to fix an issue of illegal attempts to free a still active i915 VMA object when parking a GT believed to be idle, reported by CI on 2-GT Meteor Lake. As a solution, an extra wakeref for a Primary GT was acquired from i915_gem_do_execbuffer() -- see commit f56fe3e91787 ("drm/i915: Fix a VMA UAF for multi-gt platform"). However, that fix occurred insufficient -- the issue was still reported by CI. That wakeref was released on exit from i915_gem_do_execbuffer(), then potentially before completion of the request and deactivation of its associated VMAs. Moreover, CI reports indicated that single-GT platforms also suffered sporadically from the same race. Since that issue was fixed by another commit f3c71b2ded5c ("drm/i915/vma: Fix UAF on destroy against retire race"), the changes introduced by that insufficient fix were dropped as no longer useful. However, that series resulted in another VMA UAF scenario now being triggered in CI. <4> [260.290809] ------------[ cut here ]------------ <4> [260.290988] list_del corruption. prev->next should be ffff888118c5d990, but was ffff888118c5a510. (prev=ffff888118c5a510) <4> [260.291004] WARNING: CPU: 2 PID: 1143 at lib/list_debug.c:62 __list_del_entry_valid_or_report+0xb7/0xe0 .. <4> [260.291055] CPU: 2 PID: 1143 Comm: kms_plane Not tainted 6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1 <4> [260.291058] Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024 <4> [260.291060] RIP: 0010:__list_del_entry_valid_or_report+0xb7/0xe0 ... <4> [260.291087] Call Trace: <4> [260.291089] <TASK> <4> [260.291124] i915_vma_reopen+0x43/0x80 [i915] <4> [260.291298] eb_lookup_vmas+0x9cb/0xcc0 [i915] <4> [260.291579] i915_gem_do_execbuffer+0xc9a/0x26d0 [i915] <4> [260.291883] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915] ... <4> [260.292301] </TASK> ... <4> [260.292506] ---[ end trace 0000000000000000 ]--- <4> [260.292782] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6ca3: 0000 [#1] PREEMPT SMP NOPTI <4> [260.303575] CPU: 2 PID: 1143 Comm: kms_plane Tainted: G W 6.9.0-rc2-CI_DRM_14524-ga25d180c6853+ #1 <4> [260.313851] Hardware name: Intel Corporation Meteor Lake Client Platform/MTL-P LP5x T3 RVP, BIOS MTLPFWI1.R00.3471.D91.2401310918 01/31/2024 <4> [260.326359] RIP: 0010:eb_validate_vmas+0x114/0xd80 [i915] ... <4> [260.428756] Call Trace: <4> [260.431192] <TASK> <4> [639.283393] i915_gem_do_execbuffer+0xd05/0x26d0 [i915] <4> [639.305245] i915_gem_execbuffer2_ioctl+0x123/0x2a0 [i915] ... <4> [639.411134] </TASK> ... <4> [639.449979] ---[ end trace 0000000000000000 ]--- We defer actually closing, unbinding and destroying a VMA until next idle point, or until the object is freed in the meantime. By postponing the unbind, we allow for the VMA to be reopened by the client, avoiding the work required to rebind the VMA. Starting from commit b0647a5e79b1 ("drm/i915: Avoid live-lock with i915_vma_parked()"), we assume that as long as a GT is held idle, no VMA would be reopened while we destroy them. That assumption is no longer true in multi-GT configurations, where a VMA we reopen may be handled by a GT different from the one that we already keep active via its engine while we set up an execbuf request. Restoring the extra GT0 PM wakeref removed from i915_gem_do_execbuffer() processing path seems to fix this issue. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10608 Signed-off-by: Janusz Krzysztofik <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Nirmoy Das <[email protected]> Reviewed-by: Nirmoy Das <[email protected]> Fixes: 1f33dc0c1189 ("drm/i915: Remove extra multi-gt pm-references") Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Rodrigo Vivi <[email protected]>
2024-05-07drm/msm/gen_header: allow skipping the validationDmitry Baryshkov3-4/+27
We don't need to run the validation of the XML files if we are just compiling the kernel. Skip the validation unless the user enables corresponding Kconfig option. This removes a warning from gen_header.py about lxml being not installed. Reported-by: Stephen Rothwell <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/592558/ Signed-off-by: Rob Clark <[email protected]>
2024-05-07drm/msm/a6xx: Cleanup indexed regs const'nessRob Clark2-10/+13
These tables were made non-const in commit 3cba4a2cdff3 ("drm/msm/a6xx: Update ROQ size in coredump") in order to avoid powering up the GPU when reading back a devcoredump. Instead let's just stash the count that is potentially read from hw in struct a6xx_gpu_state_obj, and make the tables const again. Signed-off-by: Rob Clark <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/592699/
2024-05-05drm/msm: Add devcoredump support for a750Connor Abbott1-18/+46
Add an a750 case to the various places where we choose a list of registers. Patchwork: https://patchwork.freedesktop.org/patch/592519/ Signed-off-by: Connor Abbott <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/592519 Signed-off-by: Rob Clark <[email protected]>
2024-05-05drm/msm: Adjust a7xx GBIF debugbus dumpingConnor Abbott2-4/+4
Use the kgsl-style list of indices, because this is about to change for a750 and we want to reuse the downstream header directly. Patchwork: https://patchwork.freedesktop.org/patch/592520/ Signed-off-by: Connor Abbott <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/592520 Signed-off-by: Rob Clark <[email protected]>
2024-05-04drm/msm: Update a6xx registers XMLConnor Abbott1-3/+44
Update to Mesa commit e82d70d472cc ("freedreno/a7xx: Add A7XX_HLSQ_DP_STR location from kgsl"). Signed-off-by: Connor Abbott <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/592518/ Signed-off-by: Rob Clark <[email protected]>
2024-05-04drm/msm: Fix imported a750 snapshot header for upstreamConnor Abbott1-434/+454
Add A7XX prefixes necessary because we use the same code for dumping a6xx and a7xx, fix register name prefixes for upstream, and use the upstream header. Patchwork: https://patchwork.freedesktop.org/patch/592517/ Signed-off-by: Connor Abbott <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/592517 Signed-off-by: Rob Clark <[email protected]>
2024-05-04drm/msm: Import a750 snapshot registers from kgslConnor Abbott1-0/+1426
Import from kgsl commit 809ee24fe560. Signed-off-by: Connor Abbott <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/592516/ Signed-off-by: Rob Clark <[email protected]>
2024-05-04MAINTAINERS: Add Konrad Dybcio as a reviewer for the Adreno driverKonrad Dybcio1-0/+1
Add myself as a reviewer for Adreno driver changes. Signed-off-by: Konrad Dybcio <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/590705/ Signed-off-by: Rob Clark <[email protected]>
2024-05-04MAINTAINERS: Add a separate entry for Qualcomm Adreno GPU driversKonrad Dybcio1-1/+18
The msm driver is.. gigantic and covers display hardware (incl. things concerning (e)DP, DSI, HDMI), as well as the entire lineup of Adreno GPUs (with hw bringup, memory mappings, userspace interaction etc.). Because of that, people listed as M:/R: receive patches concerning drivers for any part of the display block OR the GPU. Separate the latter, as it's both a functionally separate block and is of interest to different folks. Signed-off-by: Konrad Dybcio <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/590704/ Signed-off-by: Rob Clark <[email protected]>
2024-05-04drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting failsKonrad Dybcio1-1/+2
Calling a6xx_destroy() before adreno_gpu_init() leads to a null pointer dereference on: msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); as gpu->pdev is only assigned in: a6xx_gpu_init() |_ adreno_gpu_init |_ msm_gpu_init() Instead of relying on handwavy null checks down the cleanup chain, explicitly de-allocate the LLC data and free a6xx_gpu instead. Fixes: 76efc2453d0e ("drm/msm/gpu: Fix crash during system suspend after unbind") Signed-off-by: Konrad Dybcio <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/588919/ Signed-off-by: Rob Clark <[email protected]>
2024-05-04drm/msm/adreno: fix CP cycles stat retrieval on a7xxZan Dobersek1-2/+2
a7xx_submit() should use the a7xx variant of the RBBM_PERFCTR_CP register for retrieving the CP cycles value before and after the submitted command stream execution. Signed-off-by: Zan Dobersek <[email protected]> Fixes: af66706accdf ("drm/msm/a6xx: Add skeleton A7xx support") Patchwork: https://patchwork.freedesktop.org/patch/588445/ Signed-off-by: Rob Clark <[email protected]>
2024-05-04drm/msm/a7xx: allow writing to CP_BV counter selection registersZan Dobersek1-4/+4
In addition to the CP_PERFCTR_CP_SEL register range, allow writes to the CP_BV_PERFCTR_CP_SEL registers in the 0x8e0-0x8e6 range for profiling purposes of tools like fdperf and perfetto. Signed-off-by: Zan Dobersek <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/580548/ [fixup a730_protect size] Signed-off-by: Rob Clark <[email protected]>
2024-05-03Merge tag 'drm-xe-next-fixes-2024-05-02' of ↵Dave Airlie3-12/+15
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Driver Changes: - Fix for a backmerge going slightly wrong. - An UAF fix - Avoid a WA error on LNL. Signed-off-by: Dave Airlie <[email protected]> From: Thomas Hellstrom <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ZjOijQA43zhu3SZ4@fedora
2024-05-02drm: zynqmp_dpsub: Always register bridgeSean Anderson1-4/+3
We must always register the DRM bridge, since zynqmp_dp_hpd_work_func calls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be initialized. We do this before zynqmp_dpsub_drm_init since that calls drm_bridge_attach. This fixes the following lockdep warning: [ 19.217084] ------------[ cut here ]------------ [ 19.227530] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550 [ 19.241696] Modules linked in: [ 19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96 [ 19.252046] Hardware name: xlnx,zynqmp (DT) [ 19.256421] Workqueue: events zynqmp_dp_hpd_work_func [ 19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 19.269104] pc : __mutex_lock+0x4bc/0x550 [ 19.273364] lr : __mutex_lock+0x4bc/0x550 [ 19.277592] sp : ffffffc085c5bbe0 [ 19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8 [ 19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000 [ 19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000 [ 19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000 [ 19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720 [ 19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001 [ 19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888 [ 19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000 [ 19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000 [ 19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880 [ 19.356581] Call trace: [ 19.359160] __mutex_lock+0x4bc/0x550 [ 19.363032] mutex_lock_nested+0x24/0x30 [ 19.367187] drm_bridge_hpd_notify+0x2c/0x6c [ 19.371698] zynqmp_dp_hpd_work_func+0x44/0x54 [ 19.376364] process_one_work+0x3ac/0x988 [ 19.380660] worker_thread+0x398/0x694 [ 19.384736] kthread+0x1bc/0x1c0 [ 19.388241] ret_from_fork+0x10/0x20 [ 19.392031] irq event stamp: 183 [ 19.395450] hardirqs last enabled at (183): [<ffffffc0800b9278>] finish_task_switch.isra.0+0xa8/0x2d4 [ 19.405140] hardirqs last disabled at (182): [<ffffffc081ad3754>] __schedule+0x714/0xd04 [ 19.413612] softirqs last enabled at (114): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c [ 19.423128] softirqs last disabled at (110): [<ffffffc080133de8>] srcu_invoke_callbacks+0x158/0x23c [ 19.432614] ---[ end trace 0000000000000000 ]--- Fixes: eb2d64bfcc17 ("drm: xlnx: zynqmp_dpsub: Report HPD through the bridge") Signed-off-by: Sean Anderson <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 61ba791c4a7a09a370c45b70a81b8c7d4cf6b2ae) Signed-off-by: Maarten Lankhorst <[email protected]>
2024-05-02Revert "drm/bridge: ti-sn65dsi83: Fix enable error path"Luca Ceresoli1-1/+0
This reverts commit 8a91b29f1f50ce7742cdbe5cf11d17f128511f3f. The regulator_disable() added by the original commit solves one kind of regulator imbalance but adds another one as it allows the regulator to be disabled one more time than it is enabled in the following scenario: 1. Start video pipeline -> sn65dsi83_atomic_pre_enable -> regulator_enable 2. PLL lock fails -> regulator_disable 3. Stop video pipeline -> sn65dsi83_atomic_disable -> regulator_disable The reason is clear from the code flow, which looks like this (after removing unrelated code): static void sn65dsi83_atomic_pre_enable() { regulator_enable(ctx->vcc); if (PLL failed locking) { regulator_disable(ctx->vcc); <---- added by patch being reverted return; } } static void sn65dsi83_atomic_disable() { regulator_disable(ctx->vcc); } The use case for introducing the additional regulator_disable() was removing the module for debugging (see link below for the discussion). If the module is removed after a .atomic_pre_enable, i.e. with an active pipeline from the DRM point of view, .atomic_disable is not called and thus the regulator would not be disabled. According to the discussion however there is no actual use case for removing the module with an active pipeline, except for debugging/development. On the other hand, the occurrence of a PLL lock failure is possible due to any physical reason (e.g. a temporary hardware failure for electrical reasons) so handling it gracefully should be supported. As there is no way for .atomic[_pre]_enable to report an error to the core, the only clean way to support it is calling regulator_disabled() only in .atomic_disable, unconditionally, as it was before. Link: https://lore.kernel.org/all/15244220.uLZWGnKmhe@steina-w/ Fixes: 8a91b29f1f50 ("drm/bridge: ti-sn65dsi83: Fix enable error path") Reviewed-by: Alexander Stein <[email protected]> Signed-off-by: Luca Ceresoli <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 2940ee03b23281071620dda1d790cd644dabd394) Signed-off-by: Maarten Lankhorst <[email protected]>
2024-05-02drm/fb_dma: Add checks in drm_fb_dma_get_scanout_buffer()Jocelyn Falempe1-0/+3
plane->state and plane->state->fb can be NULL, so add a check before dereferencing them. Found by testing with the imx driver. Fixes: 879b3b6511fe ("drm/fb_dma: Add generic get_scanout_buffer() for drm_panic") Signed-off-by: Jocelyn Falempe <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 986c12d8c9a677c094c37bd6aa636b4d4c5ccd46) Signed-off-by: Maarten Lankhorst <[email protected]>
2024-05-02drm/fbdev-generic: Do not set physical framebuffer addressThomas Zimmermann1-1/+0
Framebuffer memory is allocated via vzalloc() from non-contiguous physical pages. The physical framebuffer start address is therefore meaningless. Do not set it. The value is not used within the kernel and only exported to userspace on dedicated ARM configs. No functional change is expected. v2: - refer to vzalloc() in commit message (Javier) Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: a5b44c4adb16 ("drm/fbdev-generic: Always use shadow buffering") Cc: Thomas Zimmermann <[email protected]> Cc: Javier Martinez Canillas <[email protected]> Cc: Zack Rusin <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]> Cc: <[email protected]> # v6.4+ Reviewed-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Zack Rusin <[email protected]> Reviewed-by: Sui Jingfeng <[email protected]> Tested-by: Sui Jingfeng <[email protected]> Acked-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 73ef0aecba78aa9ebd309b10b6cd17d94e632892) Signed-off-by: Maarten Lankhorst <[email protected]>
2024-05-02drm/panthor: Fix the FW reset logicBoris Brezillon1-3/+4
In the post_reset function, if the fast reset didn't succeed, we are not clearing the fast_reset flag, which prevents firmware sections from being reloaded. While at it, use panthor_fw_stop() instead of manually writing DISABLE to the MCU_CONTROL register. Fixes: 2718d91816ee ("drm/panthor: Add the FW logical block") Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Liviu Dudau <[email protected]> Reviewed-by: Steven Price <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-02drm/panthor: Make sure we handle 'unknown group state' case properlyBoris Brezillon1-2/+35
When we check for state values returned by the FW, we only cover part of the 0:7 range. Make sure we catch FW inconsistencies by adding a default to the switch statement, and flagging the group state as unknown in that case. When an unknown state is detected, we trigger a reset, and consider the group as unusable after that point, to prevent the potential corruption from creeping in other places if we continue executing stuff on this context. v2: - Add Steve's R-b - Fix commit message Reported-by: Dan Carpenter <[email protected]> Closes: https://lore.kernel.org/dri-devel/[email protected]/T/#u Suggested-by: Steven Price <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Steven Price <[email protected]> Reviewed-by: Liviu Dudau <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.