aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2024-03-01Merge tag 'drm-misc-fixes-2024-02-29' of ↵Dave Airlie7-27/+326
https://anongit.freedesktop.org/git/drm/drm-misc into drm-fixes A reset fix for host1x, a resource leak fix and a probe fix for aux-hpd, a use-after-free fix and a boot fix for a pmic_glink qcom driver in drivers/soc, a fix for the simpledrm/tegra transition, a kunit fix for the TTM tests, a font handling fix for fbcon, two allocation fixes and a kunit test to cover them for drm/buddy Signed-off-by: Dave Airlie <[email protected]> From: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240229-angelic-adorable-teal-fbfabb@houat
2024-02-29drm/amdgpu: remove misleading amdgpu_pmops_runtime_idle() commentBjorn Helgaas1-2/+1
After 4020c2280233 ("drm/amdgpu: don't runtime suspend if there are displays attached (v3)"), "ret" is unconditionally set later before being used, so there's point in initializing it and the associated comment is no longer meaningful. Remove the comment and the unnecessary initialization. Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-02-29Reapply "Revert drm/amd/display: Enable Freesync Video Mode by default"Alex Deucher1-5/+7
This reverts commit 11b92df8a2f7f4605ccc764ce6ae4a72760674df. This conflicts with how compositors want to handle VRR. Now that compositors actually handle VRR, we probably don't need freesync video. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2985 Acked-by: Hamza Mahfooz <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-02-29Revert "drm/amd: Remove freesync video mode amdgpu parameter"Alex Deucher2-0/+28
This reverts commit e94e787e37b99645e7c02d20d0a1ba0f8a18a82a. This conflicts with how compositors want to handle VRR. Now that compositors actually handle VRR, we probably don't need freesync video. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2985 Acked-by: Hamza Mahfooz <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-02-29drm/amd/display: check dc_link before dereferencingMelissa Wen1-1/+1
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:6683 amdgpu_dm_connector_funcs_force() warn: variable dereferenced before check 'dc_link' (see line 6663) Fixes: 967176179215 ("drm/amd/display: fix null-pointer dereference on edid reading") Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Melissa Wen <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-02-29drm/amdgpu: add deferred error check for UMC v12 address queryTao Zhou1-1/+2
Both RAS UE and deferred errors need page retirement. Signed-off-by: Tao Zhou <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-02-29drm/amd/swsmu: modify the gfx activity scalingLi Ma2-3/+4
Add an if condition for gfx activity because the scaling has been changed after smu fw version 5d4600. And remove a warning log. Signed-off-by: Li Ma <[email protected]> Reviewed-by: Yifan Zhang <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-03-01Merge tag 'drm-intel-gt-next-2024-02-28' of ↵Dave Airlie1-0/+3
git://anongit.freedesktop.org/drm/drm-intel into drm-next Driver Changes: Fixes: - Add some boring kerneldoc (Tvrtko Ursulin) - Check before removing mm notifier (Nirmoy Signed-off-by: Dave Airlie <[email protected]> From: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/Zd889Wvu/ZKZSK4/@tursulin-desk
2024-02-29drm/xe: Add LRC parsing for more GPU instructionsMatt Roper4-0/+53
The LRCs on some of our newer platforms appear to contain a few GPU instructions that weren't handled in our LRC parser. Add the relevant instruction names and opcodes so that our debugfs LRC dumps will properly indicate what these are. Bspec: 55866, 64848, 46931 Signed-off-by: Matt Roper <[email protected]> Reviewed-by: Ravi Kumar Vodapalli <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-29drm/i915: Simplify aux_ch_to_digital_port()Ville Syrjälä1-10/+5
Just return the correct thing from within the loop to make the code more readable. We have no ref counts/etc. to deal with here so no point in breaking from the loop just to return something. Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]>
2024-02-29drm/i915: Don't explode when the dig port we don't have an AUX CHVille Syrjälä1-3/+14
The icl+ power well code currently assumes that every AUX power well maps to an encoder which is using said power well. That is by no menas guaranteed as we: - only register encoders for ports declared in the VBT - combo PHY HDMI-only encoder no longer get an AUX CH since commit 9856308c94ca ("drm/i915: Only populate aux_ch if really needed") However we have places such as intel_power_domains_sanitize_state() that blindly traverse all the possible power wells. So these bits of code may very well encounbter an aux power well with no associated encoder. In this particular case the BIOS seems to have left one AUX power well enabled even though we're dealing with a HDMI only encoder on a combo PHY. We then proceed to turn off said power well and explode when we can't find a matching encoder. As a short term fix we should be able to just skip the PHY related parts of the power well programming since we know this situation can only happen with combo PHYs. Another option might be to go back to always picking an AUX CH for all encoders. However I'm a bit wary about that since we might in theory end up conflicting with the VBT AUX CH assignment. Also that wouldn't help with encoders not declared in the VBT, should we ever need to poke the corresponding power wells. Longer term we need to figure out what the actual relationship is between the PHY vs. AUX CH vs. AUX power well. Currently this is entirely unclear. Cc: [email protected] Fixes: 9856308c94ca ("drm/i915: Only populate aux_ch if really needed") Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10184 Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Imre Deak <[email protected]>
2024-02-29drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flipHsin-Yi Wang1-5/+7
It's possible that mtk_crtc->event is NULL in mtk_drm_crtc_finish_page_flip(). pending_needs_vblank value is set by mtk_crtc->event, but in mtk_drm_crtc_atomic_flush(), it's is not guarded by the same lock in mtk_drm_finish_page_flip(), thus a race condition happens. Consider the following case: CPU1 CPU2 step 1: mtk_drm_crtc_atomic_begin() mtk_crtc->event is not null, step 1: mtk_drm_crtc_atomic_flush: mtk_drm_crtc_update_config( !!mtk_crtc->event) step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip: lock mtk_crtc->event set to null, pending_needs_vblank set to false unlock pending_needs_vblank set to true, step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip called again, pending_needs_vblank is still true //null pointer Instead of guarding the entire mtk_drm_crtc_atomic_flush(), it's more efficient to just check if mtk_crtc->event is null before use. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Hsin-Yi Wang <[email protected]> Reviewed-by: CK Hu <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/ Signed-off-by: Chun-Kuang Hu <[email protected]>
2024-02-29drm/xe: Remove obsolete async_ops from struct xe_vmMika Kuoppala1-24/+0
When sync binds were reworked and worker removed, async_ops became obsolete. Remove it. Fixes: f3e9b1f43458 ("drm/xe: Remove async worker and rework sync binds") Signed-off-by: Mika Kuoppala <[email protected]> Reviewed-by: Francois Dugast <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-29drm/i915/display: Save a few bytes of memory in ↵Christophe JAILLET1-3/+3
intel_backlight_device_register() 'name' may still be "intel_backlight" when backlight_device_register() is called. In such a case, using kstrdup_const() saves a memory duplication when dev_set_name() is called in backlight_device_register(). Use kfree_const() accordingly. Signed-off-by: Christophe JAILLET <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ecfdb3af5005e05131e2fb93fd870830f39a8c29.1708708142.git.christophe.jaillet@wanadoo.fr Signed-off-by: Jani Nikula <[email protected]>
2024-02-29drm/i915/bios: abstract child device expected sizeJani Nikula1-16/+24
Add a function to return the expected child device size. Flip the if ladder around and use the same versions as in documentation to make it easier to verify. Return an error for unknown versions. No functional changes. v2: Move BUILD_BUG_ON() next to the expected sizes Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2024-02-29drm/i915/bios: abstract child device size checkJani Nikula1-35/+44
Separate the child device size check to a separate function for clarity. No functional changes. Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2024-02-29drm/i915/bios: bump expected child device sizeJani Nikula2-2/+5
VBT versions since 256 have an extra byte for EFP index. v2: Update BUILD_BUG_ON() (Matt) Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2024-02-29drm/i915: Check before removing mm notifierNirmoy Das1-0/+3
Error in mmu_interval_notifier_insert() can leave a NULL notifier.mm pointer. Catch that and return early. Fixes: ed29c2691188 ("drm/i915: Fix userptr so we do not have to worry about obj->mm.lock, v7.") Cc: <[email protected]> # v5.13+ [tursulin: Added Fixes and cc stable.] Cc: Andi Shyti <[email protected]> Cc: Shawn Lee <[email protected]> Signed-off-by: Nirmoy Das <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Tvrtko Ursulin <[email protected]> (cherry picked from commit db7bbd13f08774cde0332c705f042e327fe21e73) Signed-off-by: Joonas Lahtinen <[email protected]>
2024-02-29drm/xe/xe_trace: Add move_lacks_source detail to xe_bo_move tracePriyanka Dandamudi2-5/+9
Add move_lacks_source detail to xe_bo_move trace to make it readable that is to check if it is migrate clear or migrate copy. Cc: Thomas Hellström <[email protected]> Signed-off-by: Priyanka Dandamudi <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Fixes: a09946a9a903 ("drm/xe/xe_bo_move: Enhance xe_bo_move trace") Signed-off-by: Thomas Hellström <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 8034f6b070cc3716e81b1846f8a4ca5339c3f29b) Signed-off-by: Thomas Hellström <[email protected]>
2024-02-29drm/xe/xe_trace: Add move_lacks_source detail to xe_bo_move tracePriyanka Dandamudi2-5/+9
Add move_lacks_source detail to xe_bo_move trace to make it readable that is to check if it is migrate clear or migrate copy. Cc: Thomas Hellström <[email protected]> Signed-off-by: Priyanka Dandamudi <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Fixes: a0df2cc858c3 ("drm/xe/xe_bo_move: Enhance xe_bo_move trace") Signed-off-by: Thomas Hellström <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-29Merge drm/drm-next into drm-intel-nextJani Nikula910-8520/+45722
Sync to get the drm_printer changes to drm-intel-next. Signed-off-by: Jani Nikula <[email protected]>
2024-02-29drm: xlnx: dp: Reset DisplayPort IPRohit Visavalia1-0/+4
Assert DisplayPort reset signal before deasserting, it is to clear out any registers programmed before booting kernel. Signed-off-by: Rohit Visavalia <[email protected]> Reviewed-by: Vishal Sagar <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-29drm/xe: Deny unbinds if uapi ufence pendingMika Kuoppala2-0/+44
If user fence was provided for MAP in vm_bind_ioctl and it has still not been signalled, deny UNMAP of said vma with EBUSY as long as unsignalled fence exists. This guarantees that MAP vs UNMAP sequences won't escape under the radar if we ever want to track the client's state wrt to completed and accessible MAPs. By means of intercepting the ufence release signalling. v2: find ufence with num_fences > 1 (Matt) v3: careful on clearing vma ufence (Matt) Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/1159 Cc: Thomas Hellström <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Joonas Lahtinen <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Thomas Hellström <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 158900ade92cce5ab85a06d618eb51e6c7ffb28a) Signed-off-by: Thomas Hellström <[email protected]>
2024-02-29drm/xe: Expose user fence from xe_sync_entryMika Kuoppala3-11/+53
By allowing getting reference to user fence, we can control the lifetime outside of sync entries. This is needed to allow vma to track the associated user fence that was provided with bind ioctl. v2: xe_user_fence can be kept opaque (Jani, Matt) v3: indent fix (Matt) Cc: Thomas Hellström <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Jani Nikula <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Thomas Hellström <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 977e5b82e0901480bc201342d39f855fc0a2ef47) Signed-off-by: Thomas Hellström <[email protected]>
2024-02-29drm/xe: Use pointers in trace eventsLucas De Marchi1-15/+15
Commit a0df2cc858c3 ("drm/xe/xe_bo_move: Enhance xe_bo_move trace") inadvertently reverted commit 8d038f49c1f3 ("drm/xe: Fix cast on trace variable"), breaking the build on 32bits. As noted by Ville, there's no point in converting the pointers to u64 and add casts everywhere. In fact, it's better to just use %p and let the address be hashed. Convert all the cases in xe_trace.h to use pointers. Cc: Ville Syrjälä <[email protected]> Cc: Matt Roper <[email protected]> Cc: Priyanka Dandamudi <[email protected]> Cc: Oak Zeng <[email protected]> Cc: Thomas Hellström <[email protected]> Signed-off-by: Lucas De Marchi <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 7a975748d4dc0a524c99a390c6f74b7097ef8cf7) Signed-off-by: Thomas Hellström <[email protected]>
2024-02-29drm/xe/xe_bo_move: Enhance xe_bo_move tracePriyanka Dandamudi4-15/+34
Enhanced xe_bo_move trace to be more readable. It will help to show the migration details. Src and dst details. v2: Modify trace_xe_bo_move(), it takes the integer mem_type rather than a string. Make mem_type_to_name() extern, it will be used by trace.(Thomas) v3: Move mem_type_to_name() to xe_bo.[ch] (Thomas, Matt) v4: Add device details to reduce ambiquity related to vram0/vram1. (Oak) v5: Rename mem_type_to_name to xe_mem_type_to_name. (Thomas) v6: Optimised code to use xe_bo_device(__entry->bo). (Thomas) Cc: Thomas Hellström <[email protected]> Cc: Oak Zeng <[email protected]> Cc: Kempczynski Zbigniew <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Brian Welty <[email protected]> Signed-off-by: Priyanka Dandamudi <[email protected]> Reviewed-by: Oak Zeng <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Signed-off-by: Thomas Hellström <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit a0df2cc858c309a8bc2e87b4274772587aa25e05) Signed-off-by: Thomas Hellström <[email protected]>
2024-02-29drm/xe/mmio: fix build warning for BAR resize on 32-bitArnd Bergmann1-1/+1
clang complains about a nonsensical test on builds with a 32-bit phys_addr_t, which means resizing will always fail: drivers/gpu/drm/xe/xe_mmio.c:109:23: error: result of comparison of constant 4294967296 with expression of type 'resource_size_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] 109 | root_res->start > 0x100000000ull) | ~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~ Previously, BAR resize was always disallowed on 32-bit kernels, but this apparently changed recently. Since 32-bit machines can in theory support PAE/LPAE for large address spaces, this may end up useful, so change the driver to shut up the warning but still work when phys_addr_t/resource_size_t is 64 bit wide. Fixes: 9a6e6c14bfde ("drm/xe/mmio: Use non-atomic writeq/readq variant for 32b") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]> (cherry picked from commit f5d3983366c0b88ec388b3407b29c1c0862ee2b8) Signed-off-by: Thomas Hellström <[email protected]>
2024-02-29drm/xe: get rid of MAX_BINDSPaulo Zanoni1-4/+1
Mesa has been issuing a single bind operation per ioctl since xe.ko changed to GPUVA due xe.ko bug #746. If I change Mesa to try again to issue every single bind operation it can in the same ioctl, it hits the MAX_BINDS assertion when running Vulkan conformance tests. Test dEQP-VK.sparse_resources.transfer_queue.3d.rgba32i.1024_128_8 issues 960 bind operations in a single ioctl, it's the most I could find in the conformance suite. I don't see a reason to keep the MAX_BINDS restriction: it doesn't seem to be preventing any specific issue. If the number is too big for the memory allocations, then those will fail. Nothing related to num_binds seems to be using the stack. Let's just get rid of it. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Testcase: dEQP-VK.sparse_resources.transfer_queue.3d.rgba32i.1024_128_8 References: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/746 Cc: Matthew Brost <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Matthew Brost <[email protected]> Signed-off-by: Matthew Brost <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit ba6bbdc6eaef92998ec7f323c9e1211d344d2556) Signed-off-by: Thomas Hellström <[email protected]>
2024-02-29drm/xe: Use vmalloc for array of bind allocation in bind IOCTLMatthew Brost1-11/+14
Use vmalloc in effort to allow a user pass in a large number of binds in an IOCTL (mesa use case). Also use array allocations rather open coding the size calculation. v2: Use __GFP_ACCOUNT for allocations (Thomas) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Thomas Hellström <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 35ed1d2bfff7b1969e7f99f3641a83ea54f037e2) Signed-off-by: Thomas Hellström <[email protected]>
2024-02-29drm/xe: Don't support execlists in xe_gt_tlb_invalidation layerMatthew Brost1-0/+12
The xe_gt_tlb_invalidation layer implements TLB invalidations for a GuC backend. Simply return if in execlists mode. A follow up may properly implement the xe_gt_tlb_invalidation layer for both GuC and execlists. Fixes: a9351846d945 ("drm/xe: Break of TLB invalidation into its own file") Cc: Rodrigo Vivi <[email protected]> Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit a9e483dda3efa5b9aae5d9eef94d2c3a878d9bea) Signed-off-by: Thomas Hellström <[email protected]>
2024-02-29drm/xe: Fix execlist splatMatthew Brost1-1/+1
Although execlist submission is not supported it should be kept in a basic working state as it can be used for very early hardware bring up. Fix the below splat. WARNING: CPU: 3 PID: 11 at drivers/gpu/drm/xe/xe_execlist.c:217 execlist_run_job+0x1c2/0x220 [xe] Modules linked in: xe drm_kunit_helpers drm_gpuvm drm_ttm_helper ttm drm_exec drm_suballoc_helper drm_buddy gpu_sched mei_pxp mei_hdcp wmi_bmof x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul snd_hda_intel ghash_clmulni_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core video snd_pcm mei_me mei wmi fuse e1000e i2c_i801 ptp i2c_smbus pps_core intel_lpss_pci CPU: 3 PID: 11 Comm: kworker/u16:0 Tainted: G U 6.8.0-rc3-guc+ #1046 Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP, BIOS TGLSFWI1.R00.3243.A01.2006102133 06/10/2020 Workqueue: rcs0 drm_sched_run_job_work [gpu_sched] RIP: 0010:execlist_run_job+0x1c2/0x220 [xe] Code: 8b f8 03 00 00 4c 89 39 e9 e2 fe ff ff 49 8d 7d 20 be ff ff ff ff e8 ed fd a6 e1 85 c0 0f 85 e1 fe ff ff 0f 0b e9 da fe ff ff <0f> 0b 0f 0b 41 83 fc 03 0f 86 8a fe ff ff 0f 0b e9 83 fe ff ff be RSP: 0018:ffffc9000013bdb8 EFLAGS: 00010246 RAX: ffff888105021a00 RBX: ffff888105078400 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffc9000013bd14 RDI: ffffc90001609090 RBP: ffff88811e3f0040 R08: 0000000000000088 R09: 00000000ffffff81 R10: 0000000000000001 R11: ffff88810c10c000 R12: 00000000fffffffe R13: ffff888109b72c28 R14: ffff8881050784a0 R15: ffff888105078408 FS: 0000000000000000(0000) GS:ffff88849f980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000563459d130f8 CR3: 000000000563a001 CR4: 0000000000f70ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __warn+0x7f/0x170 ? execlist_run_job+0x1c2/0x220 [xe] ? report_bug+0x1c7/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? execlist_run_job+0x1c2/0x220 [xe] ? execlist_run_job+0x2c/0x220 [xe] drm_sched_run_job_work+0x246/0x3f0 [gpu_sched] ? process_one_work+0x18d/0x4e0 process_one_work+0x1f7/0x4e0 worker_thread+0x1da/0x3e0 ? __pfx_worker_thread+0x10/0x10 kthread+0xfe/0x130 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> Fixes: 9b9529ce379a ("drm/xe: Rename engine to exec_queue") Signed-off-by: Matthew Brost <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit ddadc7120d4be7a40a9745924339c472c5850d14) Signed-off-by: Thomas Hellström <[email protected]>
2024-02-29drm/xe/uapi: Remove unused flagsFrancois Dugast5-118/+6
Those cases missed in previous uAPI cleanups were mostly accidentally brought in from i915 or created to exercise the possibilities of gpuvm but they are not used by userspace yet, so let's remove them. They can still be brought back later if needed. v2: - Fix XE_VM_FLAG_FAULT_MODE support in xe_lrc.c (Brian Welty) - Leave DRM_XE_VM_BIND_OP_UNMAP_ALL (José Roberto de Souza) - Ensure invalid flag values are rejected (Rodrigo Vivi) v3: Rebase after removal of persistent exec_queues (Francois Dugast) v4: Rodrigo: Rebase after the new dumpable flag. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Thomas Hellström <[email protected]> Cc: Rodrigo Vivi <[email protected]> Signed-off-by: Francois Dugast <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 84a1ed5e67565b09b8fd22a26754d2897de55ce0) Signed-off-by: Thomas Hellström <[email protected]>
2024-02-29drm/panel: add samsung s6e3fa7 panel driverRichard Acayan3-0/+295
The S6E3FA7 display controller is enabled in every Pixel 3a (non-XL) variant. Add the driver for it, generated by linux-mdss-dsi-panel-driver-generator. There are other panels connected to the same S6E3FA7 display controller, such as the AMS604NL01 panel, which are incompatible with this driver. Name the device tree compatible after the panel model according to iFixit. Link: https://github.com/msm8916-mainline/linux-mdss-dsi-panel-driver-generator Link: https://android.googlesource.com/kernel/msm/+/7fda1cd7b64710dafac5f34899611c6d35eb4cd2/arch/arm64/boot/dts/google/dsi-panel-s6e3fa7-1080p-cmd.dtsi Link: https://github.com/msm8953-mainline/linux/blob/v6.6.12-r0/drivers/gpu/drm/panel/panel-samsung-s6e3fa7.c Link: https://www.ifixit.com/Guide/Image/meta/muyjtLQTHu6MDkhK Signed-off-by: Richard Acayan <[email protected]> Reviewed-by: Jessica Zhang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]>
2024-02-29drm/xe: Add uapi for dumpable bosMaarten Lankhorst1-1/+2
Add the flag XE_VM_BIND_FLAG_DUMPABLE to notify devcoredump that this mapping should be dumped. This is not hooked up, but the uapi should be ready before merging. It's likely easier to dump the contents of the bo's at devcoredump readout time, so it's better if the bos will stay unmodified after a hang. The NEEDS_CPU_MAPPING flag is removed as requirement. Signed-off-by: Maarten Lankhorst <[email protected]> Reviewed-by: José Roberto de Souza <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 76a86b58d2b3de31e88acb487ebfa0c3cc7c41d2) Signed-off-by: Thomas Hellström <[email protected]>
2024-02-28drm/xe/guc: Fix missing topology initZhanjun Dong1-2/+1
init_steering_dss need topology dss mask to be init ahead. Fixed by moving xe_gt_topology_init ahead of xe_gt_mcr_init Fixes: bf8ec3c3e82c ("drm/xe: Initialize GuC earlier during probe") Cc: Michał Winiarski <[email protected]> Signed-off-by: Zhanjun Dong <[email protected]> Reviewed-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-02-28drm/amd/display: Add monitor patch for specific eDPRyan Lin1-2/+4
[WHY] Some eDP panels' ext caps don't write initial values. The value of dpcd_addr (0x317) can be random and the backlight control interface will be incorrect. [HOW] Add new panel patches to remove sink ext caps. Cc: Mario Limonciello <[email protected]> Cc: Alex Deucher <[email protected]> Cc: [email protected] # 6.5.x Cc: Tsung-hua Lin <[email protected]> Cc: Chris Chi <[email protected]> Reviewed-by: Wayne Lin <[email protected]> Acked-by: Alex Hung <[email protected]> Signed-off-by: Ryan Lin <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-02-28amd/amdkfd: remove unused parameterEric Huang3-4/+3
The adev can be found from bo by amdgpu_ttm_adev(bo->tbo.bdev), and adev is also not used in the function amdgpu_amdkfd_map_gtt_bo_to_gart(). Signed-off-by: Eric Huang <[email protected]> Reviewed-by: Harish Kasiviswanathan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-02-28drm/amd/pm: Fix esm reg mask use to get pcie speedAsad Kamal3-6/+6
Fix mask used for esm ctrl register to get pcie link speed on smu_v11_0_3, smu_v13_0_2 & smu_v13_0_6 Fixes: 511a95552ec8 ("drm/amd/pm: Add SMU 13.0.6 support") Fixes: c05d1c401572 ("drm/amd/swsmu: add aldebaran smu13 ip support (v3)") Fixes: f1c378593153 ("drm/amd/powerplay: add Arcturus support for gpu metrics export") Signed-off-by: Asad Kamal <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Reviewed-by: Le Ma <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-02-28drm/amd/pm: Skip reporting pcie width/speed on vfsAsad Kamal2-12/+16
Skip reporting pcie link width/speed on vfs for smu_v13_0_6 & smu_v13_0_2 Signed-off-by: Asad Kamal <[email protected]> Reviewed-by: Yang Wang <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-02-28drm/amdgpu: enable pp_od_clk_voltage for gfx 9.4.3 SRIOVYang Wang1-5/+27
v1: enabel pp_od_clk_voltage node for gfx 9.4.3 SRIOV and BM. v2: add onevf check for gfx 9.4.3 v3: refine code check order to make function clearly. Signed-off-by: Yang Wang <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2024-02-28drm/dp: Don't attempt AUX transfers when eDP panels are not poweredDouglas Anderson3-0/+40
If an eDP panel is not powered on then any attempts to talk to it over the DP AUX channel will timeout. Unfortunately these attempts may be quite slow. Userspace can initiate these attempts either via a /dev/drm_dp_auxN device or via the created i2c device. Making the DP AUX drivers timeout faster is a difficult proposition. In theory we could just poll the panel's HPD line in the AUX transfer function and immediately return an error there. However, this is easier said than done. For one thing, there's no hard requirement to hook the HPD line up for eDP panels and it's OK to just delay a fixed amount. For another thing, the HPD line may not be fast to probe. On parade-ps8640 we need to wait for the bridge chip's firmware to boot before we can get the HPD line and this is a slow process. The fact that the transfers are taking so long to timeout is causing real problems. The open source fwupd daemon sometimes scans DP busses looking for devices whose firmware need updating. If it happens to scan while a panel is turned off this scan can take a long time. The fwupd daemon could try to be smarter and only scan when eDP panels are turned on, but we can also improve the behavior in the kernel. Let's let eDP panels drivers specify that a panel is turned off and then modify the common AUX transfer code not to attempt a transfer in this case. Tested-by: Steev Klimaszewski <[email protected]> Reviewed-by: Hsin-Yi Wang <[email protected]> Tested-by: Eizan Miyamoto <[email protected]> Acked-by: Neil Armstrong <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240202141109.1.I24277520ac754ea538c9b14578edc94e1df11b48@changeid
2024-02-28drm: tests: Fix invalid printf format specifiers in KUnit testsDavid Gow2-10/+10
The drm_buddy_test's alloc_contiguous test used a u64 for the page size, which was then updated to be an 'unsigned long' to avoid 64-bit multiplication division helpers. However, the variable is logged by some KUNIT_ASSERT_EQ_MSG() using the '%d' or '%llu' format specifiers, the former of which is always wrong, and the latter is no longer correct now that ps is no longer a u64. Fix these to all use '%lu'. Also, drm_mm_test calls KUNIT_FAIL() with an empty string as the message. gcc and clang warns if a printf format string is empty, so give these some more detailed error messages, which should be more useful anyway. Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous test") Fixes: fca7526b7d89 ("drm/tests/drm_buddy: fix build failure on 32-bit targets") Fixes: fc8d29e298cf ("drm: selftest: convert drm_mm selftest to KUnit") Reviewed-by: Matthew Auld <[email protected]> Acked-by: Christian König <[email protected]> Tested-by: Guenter Roeck <[email protected]> Reviewed-by: Justin Stitt <[email protected]> Signed-off-by: David Gow <[email protected]> Signed-off-by: Shuah Khan <[email protected]>
2024-02-28drm/i915/cdclk: Document CDCLK componentsGustavo Sousa1-0/+26
Improve documentation by giving an overview of the components involved in the generation of the CDCLK. v2: Fix htmldoc error because of missing blank line at the start of bulleted list. Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Gustavo Sousa <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-28drm/i915/cdclk: Rename intel_cdclk_needs_modeset to intel_cdclk_clock_changedGustavo Sousa3-9/+8
Looks like the name and description of intel_cdclk_needs_modeset() became inaccurate as of commit 59f9e9cab3a1 ("drm/i915: Skip modeset for cdclk changes if possible"), when it became possible to update the cdclk without requiring disabling the pipes when only changing the cd2x divider was enough. Later on we also added the same type of support with squash and crawling with commit 25e0e5ae5610 ("drm/i915/display: Do both crawl and squash when changing cdclk"), commit d4a23930490d ("drm/i915: Allow cdclk squasher to be reconfigured live") and commit d62686ba3b54 ("drm/i915/adl_p: CDCLK crawl support for ADL"). As such, update that function's name and documentation to something more appropriate, since the real checks for requiring modeset are done elsewhere. v2: - Rename to intel_cdclk_clock_changed instead of intel_cdclk_params_changed. (Ville) Cc: Ville Syrjälä <[email protected]> Signed-off-by: Gustavo Sousa <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-28drm/xe/xe2: fix 64-bit division in pte_update_sizeArnd Bergmann1-1/+1
This function does not build on 32-bit targets when the compiler fails to reduce DIV_ROUND_UP() into a shift: ld.lld: error: undefined symbol: __aeabi_uldivmod >>> referenced by xe_migrate.c >>> drivers/gpu/drm/xe/xe_migrate.o:(pte_update_size) in archive vmlinux.a There are two instances in this function. Change the first to use an open-coded shift with the same behavior, and the second one to a 32-bit calculation, which is sufficient here as the size is never more than 2^32 pages (16TB). Fixes: 237412e45390 ("drm/xe: Enable 32bits build") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-02-28drm/xe/mmio: fix build warning for BAR resize on 32-bitArnd Bergmann1-1/+1
clang complains about a nonsensical test on builds with a 32-bit phys_addr_t, which means resizing will always fail: drivers/gpu/drm/xe/xe_mmio.c:109:23: error: result of comparison of constant 4294967296 with expression of type 'resource_size_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] 109 | root_res->start > 0x100000000ull) | ~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~ Previously, BAR resize was always disallowed on 32-bit kernels, but this apparently changed recently. Since 32-bit machines can in theory support PAE/LPAE for large address spaces, this may end up useful, so change the driver to shut up the warning but still work when phys_addr_t/resource_size_t is 64 bit wide. Fixes: 9a6e6c14bfde ("drm/xe/mmio: Use non-atomic writeq/readq variant for 32b") Fixes: 237412e45390 ("drm/xe: Enable 32bits build") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-02-28drm/xe/kunit: fix link failure with built-in xeArnd Bergmann3-3/+5
When the driver is built-in but the tests are in loadable modules, the helpers don't actually get put into the driver: ERROR: modpost: "xe_kunit_helper_alloc_xe_device" [drivers/gpu/drm/xe/tests/xe_test.ko] undefined! Change the Makefile to ensure they are always part of the driver even when the rest of the kunit tests are in loadable modules. Fixes: 5095d13d758b ("drm/xe/kunit: Define helper functions to allocate fake xe device") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Lucas De Marchi <[email protected]>
2024-02-28drm/tests: connector: Add tests for drmm_connector_initMaxime Ripard1-1/+169
drmm_connector_init is the preferred function to initialize a drm_connector structure. Let's add a bunch of unit tests for it. Reviewed-by: Maíra Canal <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-28drm/tests: Add helper to create mock crtcMaxime Ripard1-0/+62
We're going to need a full-blown, functional, KMS device to test more components of the atomic modesetting infrastructure. Let's add a new helper to create a dumb, mocked, CRTC. By default it will create a CRTC relying only on the default helpers, but drivers are free to deviate from that. Reviewed-by: Maíra Canal <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-02-28drm/tests: Add helper to create mock planeMaxime Ripard1-0/+85
We're going to need a full-blown, functional, KMS device to test more components of the atomic modesetting infrastructure. Let's add a new helper to create a dumb, mocked, primary plane. By default, it will create a linear XRGB8888 plane, using the default helpers. Reviewed-by: Maíra Canal <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.