aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2023-06-13drm/i915/mtl/gsc: extract release and security versions from the gsc binaryDaniele Ceraolo Spurio7-27/+271
The release and security versions of the GSC binary are not used at runtime to decide interface compatibility (there is a separate version for that), but they're still useful for debug, so it is still worth extracting them and printing them out in dmesg. To get to these version, we need to navigate through various headers in the binary. See in-code comment for details. v2: fix and improve size checks when crawling the binary header, add comment about the different version, wrap the partition base/offset pairs in the GSC header in a struct (Alan) Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Cc: Alan Previn <[email protected]> Reviewed-by: Alan Previn <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13drm/i915/gsc: fixes and updates for GSC memory allocationDaniele Ceraolo Spurio3-32/+75
A few fixes/updates are required around the GSC memory allocation and it is easier to do them all at the same time. The changes are as follows: 1 - Switch the memory allocation to stolen memory. We need to avoid accesses from GSC FW to normal memory after the suspend function has completed and to do so we can either switch to using stolen or make sure the GSC is gone to sleep before the end of the suspend function. Given that the GSC waits for a bit before going idle even if there are no pending operations, it is easier and quicker to just use stolen memory. 2 - Reduce the GSC allocation size to 4MBs, which is the POR requirement. The 8MBs were needed only for early FW and I had misunderstood that as being the expected POR size when I sent the original patch. 3 - Perma-map the GSC allocation. This isn't required immediately, but it will be needed later to be able to quickly extract the GSC logs, which are inside the allocation. Since the mapping code needs to be rewritten due to switching to stolen, it makes sense to do the switch immediately to avoid having to change it again later. Note that the explicit setting of CACHE_NONE for Wa_22016122933 has been dropped because that's the default setting for stolen memory on !LLC platforms. v2: only memset the memory we're not overwriting (Alan) Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Cc: Alan Previn <[email protected]> Cc: John Harrison <[email protected]> Cc: Vinay Belgaumkar <[email protected]> Reviewed-by: Alan Previn <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13drm/amd/display: limit DPIA link rate to HBR3Peichen Huang1-0/+5
[Why] DPIA doesn't support UHBR, driver should not enable UHBR for dp tunneling [How] limit DPIA link rate to HBR3 Cc: Mario Limonciello <[email protected]> Cc: Alex Deucher <[email protected]> Cc: [email protected] Acked-by: Stylon Wang <[email protected]> Signed-off-by: Peichen Huang <[email protected]> Reviewed-by: Mustapha Ghaddar <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-06-13drm/amd/display: fix the system hang while disable PSRTom Chung1-4/+6
[Why] When the PSR enabled. If you try to adjust the timing parameters, it may cause system hang. Because the timing mismatch with the DMCUB settings. [How] Disable the PSR before adjusting timing parameters. Cc: Mario Limonciello <[email protected]> Cc: Alex Deucher <[email protected]> Cc: [email protected] Acked-by: Stylon Wang <[email protected]> Signed-off-by: Tom Chung <[email protected]> Reviewed-by: Wayne Lin <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-06-13drm/amd/display: edp do not add non-edid timingsHersen Wu1-1/+7
[Why] most edp support only timings from edid. applying non-edid timings, especially those timings out of edp bandwidth, may damage edp. [How] do not add non-edid timings for edp. Cc: Mario Limonciello <[email protected]> Cc: Alex Deucher <[email protected]> Cc: [email protected] Acked-by: Stylon Wang <[email protected]> Signed-off-by: Hersen Wu <[email protected]> Reviewed-by: Roman Li <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-06-13Revert "drm/amdgpu: remove TOPDOWN flags when allocating VRAM in large bar ↵Arunpravin Paneer Selvam1-1/+1
system" This reverts commit c105518679b6e87232874ffc989ec403bee59664. This patch disables the TOPDOWN flag for APU and few dGPU cards which has the VRAM size equal to the BAR size. When we enable the TOPDOWN flag, we get the free blocks at the highest available memory region and we don't split the lower order blocks. This change is required to keep off the fragmentation related issues particularly in ASIC which has VRAM space <= 500MiB Hence, we are reverting this patch. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2270 Signed-off-by: Arunpravin Paneer Selvam <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2023-06-13drm/amdgpu: vcn_4_0 set instance 0 init sched score to 1Sonny Jiang1-1/+5
Only vcn0 can process AV1 codecx. In order to use both vcn0 and vcn1 in h264/265 transcode to AV1 cases, set vcn0 sched score to 1 at initialization time. Signed-off-by: Sonny Jiang <[email protected]> Reviewed-by: Leo Liu <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.1.x
2023-06-13drm/radeon: Disable outputs when releasing fbdev clientThomas Zimmermann1-0/+1
Disable the modesetting pipeline before release the radeon's fbdev client. Fixes the following error: [ 17.217408] WARNING: CPU: 5 PID: 1464 at drivers/gpu/drm/ttm/ttm_bo.c:326 ttm_bo_release+0x27e/0x2d0 [ttm] [ 17.217418] Modules linked in: edac_mce_amd radeon(+) drm_ttm_helper ttm video drm_suballoc_helper drm_display_helper kvm irqbypass drm_kms_helper syscopyarea crc32_pclmul sysfillrect sha512_ssse3 sysimgblt sha512_generic cfbfillrect cfbimgblt wmi_bmof aesni_intel cfbcopyarea crypto_simd cryptd k10temp acpi_cpufreq wmi dm_mod [ 17.217432] CPU: 5 PID: 1464 Comm: systemd-udevd Not tainted 6.4.0-rc4+ #1 [ 17.217436] Hardware name: Micro-Star International Co., Ltd. MS-7A38/B450M PRO-VDH MAX (MS-7A38), BIOS B.G0 07/26/2022 [ 17.217438] RIP: 0010:ttm_bo_release+0x27e/0x2d0 [ttm] [ 17.217444] Code: 48 89 43 38 48 89 43 40 48 8b 5c 24 30 48 8b b5 40 08 00 00 48 8b 6c 24 38 48 83 c4 58 e9 7a 49 f7 e0 48 89 ef e9 6c fe ff ff <0f> 0b 48 83 7b 20 00 0f 84 b7 fd ff ff 0f 0b 0f 1f 00 e9 ad fd ff [ 17.217448] RSP: 0018:ffffc9000095fbb0 EFLAGS: 00010202 [ 17.217451] RAX: 0000000000000001 RBX: ffff8881052c8de0 RCX: 0000000000000000 [ 17.217453] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff8881052c8de0 [ 17.217455] RBP: ffff888104a66e00 R08: ffff8881052c8de0 R09: ffff888104a7cf08 [ 17.217457] R10: ffffc9000095fbe0 R11: ffffc9000095fbe8 R12: ffff8881052c8c78 [ 17.217458] R13: ffff8881052c8c78 R14: dead000000000100 R15: ffff88810528b108 [ 17.217460] FS: 00007f319fcbb8c0(0000) GS:ffff88881a540000(0000) knlGS:0000000000000000 [ 17.217463] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 17.217464] CR2: 000055dc8b0224a0 CR3: 000000010373d000 CR4: 0000000000750ee0 [ 17.217466] PKRU: 55555554 [ 17.217468] Call Trace: [ 17.217470] <TASK> [ 17.217472] ? __warn+0x97/0x160 [ 17.217476] ? ttm_bo_release+0x27e/0x2d0 [ttm] [ 17.217481] ? report_bug+0x1ec/0x200 [ 17.217487] ? handle_bug+0x3c/0x70 [ 17.217490] ? exc_invalid_op+0x1f/0x90 [ 17.217493] ? preempt_count_sub+0xb5/0x100 [ 17.217496] ? asm_exc_invalid_op+0x16/0x20 [ 17.217500] ? ttm_bo_release+0x27e/0x2d0 [ttm] [ 17.217505] ? ttm_resource_move_to_lru_tail+0x1ab/0x1d0 [ttm] [ 17.217511] radeon_bo_unref+0x1a/0x30 [radeon] [ 17.217547] radeon_gem_object_free+0x20/0x30 [radeon] [ 17.217579] radeon_fbdev_fb_destroy+0x57/0x90 [radeon] [ 17.217616] unregister_framebuffer+0x72/0x110 [ 17.217620] drm_client_dev_unregister+0x6d/0xe0 [ 17.217623] drm_dev_unregister+0x2e/0x90 [ 17.217626] drm_put_dev+0x26/0x90 [ 17.217628] pci_device_remove+0x44/0xc0 [ 17.217631] really_probe+0x257/0x340 [ 17.217635] __driver_probe_device+0x73/0x120 [ 17.217638] driver_probe_device+0x2c/0xb0 [ 17.217641] __driver_attach+0xa0/0x150 [ 17.217643] ? __pfx___driver_attach+0x10/0x10 [ 17.217646] bus_for_each_dev+0x67/0xa0 [ 17.217649] bus_add_driver+0x10e/0x210 [ 17.217651] driver_register+0x5c/0x120 [ 17.217653] ? __pfx_radeon_module_init+0x10/0x10 [radeon] [ 17.217681] do_one_initcall+0x44/0x220 [ 17.217684] ? kmalloc_trace+0x37/0xc0 [ 17.217688] do_init_module+0x64/0x240 [ 17.217691] __do_sys_finit_module+0xb2/0x100 [ 17.217694] do_syscall_64+0x3b/0x90 [ 17.217697] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 17.217700] RIP: 0033:0x7f319feaa5a9 [ 17.217702] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 27 08 0d 00 f7 d8 64 89 01 48 [ 17.217706] RSP: 002b:00007ffc6bf3e7f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 17.217709] RAX: ffffffffffffffda RBX: 00005607204f3170 RCX: 00007f319feaa5a9 [ 17.217710] RDX: 0000000000000000 RSI: 00007f31a002eefd RDI: 0000000000000018 [ 17.217712] RBP: 00007f31a002eefd R08: 0000000000000000 R09: 00005607204f1860 [ 17.217714] R10: 0000000000000018 R11: 0000000000000246 R12: 0000000000020000 [ 17.217716] R13: 0000000000000000 R14: 0000560720522450 R15: 0000560720255899 [ 17.217718] </TASK> [ 17.217719] ---[ end trace 0000000000000000 ]--- The buffer object backing the fbdev emulation got pinned twice: by the fb_probe helper radeon_fbdev_create_pinned_object() and the modesetting code when the framebuffer got displayed. It only got unpinned once by the fbdev helper radeon_fbdev_destroy_pinned_object(). Hence TTM's BO- release function complains about the pin counter. Forcing the outputs off also undoes the modesettings pin increment. Tested-by: Borislav Petkov (AMD) <[email protected]> Reported-by: Borislav Petkov <[email protected]> Closes: https://lore.kernel.org/dri-devel/20230603174814.GCZHt83pN+wNjf63sC@fat_crate.local/ Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: e317a69fe891 ("drm/radeon: Implement client-based fbdev emulation") Cc: Alex Deucher <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: "Christian König" <[email protected]> Cc: "Pan, Xinhui" <[email protected]> Cc: [email protected] Signed-off-by: Alex Deucher <[email protected]>
2023-06-13drm/amd/pm: workaround for compute workload type on some skusKenneth Feng1-2/+31
On smu 13.0.0, the compute workload type cannot be set on all the skus due to some other problems. This workaround is to make sure compute workload type can also run on some specific skus. v2: keep the variable consistent Signed-off-by: Kenneth Feng <[email protected]> Acked-by: Lijo Lazar <[email protected]> Reviewed-by: Feifei Xu <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.1.x
2023-06-13drm/amd: Tighten permissions on VBIOS flashing attributesMario Limonciello1-2/+2
Non-root users shouldn't be able to try to trigger a VBIOS flash or query the flashing status. This should be reserved for users with the appropriate permissions. Cc: [email protected] Fixes: 8424f2ccb3c0 ("drm/amdgpu/psp: Add vbflash sysfs interface support") Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-06-13drm/amd: Make sure image is written to trigger VBIOS image update flowMario Limonciello1-0/+3
The VBIOS image update flow requires userspace to: 1) Write the image to `psp_vbflash` 2) Read `psp_vbflash` 3) Poll `psp_vbflash_status` to check for completion If userspace reads `psp_vbflash` before writing an image, it's possible that it causes problems that can put the dGPU into an invalid state. Explicitly check that an image has been written before letting a read succeed. Cc: [email protected] Fixes: 8424f2ccb3c0 ("drm/amdgpu/psp: Add vbflash sysfs interface support") Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-06-13drm/amdgpu: add missing radeon secondary PCI IDAlex Deucher1-0/+1
0x5b70 is a missing RV370 secondary id. Add it so we don't try and probe it with amdgpu. Cc: [email protected] Reviewed-by: Michel Dänzer <[email protected]> Tested-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2023-06-13drm/amdgpu: Implement gfx9 patch functions for resubmissionJiadong Zhu1-0/+80
Patch the packages including CONTEXT_CONTROL and WRITE_DATA for gfx9 during the resubmission scenario. Signed-off-by: Jiadong Zhu <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.3.x
2023-06-13drm/amdgpu: Modify indirect buffer packages for resubmissionJiadong Zhu4-0/+102
When the preempted IB frame resubmitted to cp, we need to modify the frame data including: 1. set PRE_RESUME 1 in CONTEXT_CONTROL. 2. use meta data(DE and CE) read from CSA in WRITE_DATA. Add functions to save the location the first time IBs emitted and callback to patch the package when resubmission happens. Signed-off-by: Jiadong Zhu <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.3.x
2023-06-13drm/amdgpu: Program gds backup address as zero if no gds allocatedJiadong Zhu1-5/+8
It is firmware requirement to set gds_backup_addrlo and gds_backup_addrhi of DE meta both zero if no gds partition is allocated for the frame. Signed-off-by: Jiadong Zhu <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.3.x
2023-06-13drm/nouveau: add nv_encoder pointer check for NULLNatalia Petrova1-1/+2
Pointer nv_encoder could be dereferenced at nouveau_connector.c in case it's equal to NULL by jumping to goto label. This patch adds a NULL-check to avoid it. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 3195c5f9784a ("drm/nouveau: set encoder for lvds") Signed-off-by: Natalia Petrova <[email protected]> Reviewed-by: Lyude Paul <[email protected]> [Fixed patch title] Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13drm/amdgpu: Reset CP_VMID_PREEMPT after trailing fence signaledJiadong Zhu1-4/+4
When MEC executes unmap_queue for mid command buffer preemption, it will kick the write pointer of the gfx ring, set CP_VMID_PREEMPT to trigger the preemption and wait for CP_VMID_PREEMPT becomes zero after the preemption done. There is a race condition that PFP may excute the resetting command before MEC set CP_VMID_PREEMPT. As a result, hang happens as CP_VMID_PREEMPT is always 0xffff. To avoid this, we send resetting CP_VMID_PREEMPT command after the trailing fence is siganled and update gfx write pointer explicitly. Signed-off-by: Jiadong Zhu <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected] # 6.3.x Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2535
2023-06-13drm/nouveau/dp: check for NULL nv_connector->native_modeNatalia Petrova1-2/+2
Add checking for NULL before calling nouveau_connector_detect_depth() in nouveau_connector_get_modes() function because nv_connector->native_mode could be dereferenced there since connector pointer passed to nouveau_connector_detect_depth() and the same value of nv_connector->native_mode is used there. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d4c2c99bdc83 ("drm/nouveau/dp: remove broken display depth function, use the improved one") Signed-off-by: Natalia Petrova <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13drm/bridge: ti-sn65dsi86: Avoid possible buffer overflowSu Hui1-0/+4
Smatch error:buffer overflow 'ti_sn_bridge_refclk_lut' 5 <= 5. Fixes: cea86c5bb442 ("drm/bridge: ti-sn65dsi86: Implement the pwm_chip") Signed-off-by: Su Hui <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13drm/i915/dsi: Remove weird has_pch_encoder assertsVille Syrjälä2-4/+0
No idea why the DSI code is feeling the need to assert that has_pch_encoder must not be set. PCH encoders aren't even a thing on any platform that has DSI. Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13drm/i915/dsi: Grab the crtc from the customary placeVille Syrjälä1-2/+2
The encoder hooks already get passed the crtc state so just grab the crtc from there instead of from the connector state. This is generally what everyone else does, so no reason for icl_dsi.c to be different. Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13drm/i915/dsi: Move panel reset+power off to be the last thingVille Syrjälä1-6/+8
Follow what Windows does and do the DSI panel reset+power off after everything else. v2: s/intel_dsi_msleep/msleep/ Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13drm/i915/dsi: Respect power_off_delay on icl+Ville Syrjälä1-0/+2
icl+ DSI isn't respecting the panel power_off_delay. Remedy that. Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13drm/i915/dsi: Do DSC/scaler disable earlier on icl+Ville Syrjälä1-4/+3
Do the scaler disable in the spot where bspec has specfied it for TGL+. And also move the DSC disable to match what intel_ddi.c does. Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13drm/i915/dsi: Move most things from .disable() into .post_disable() on icl+Ville Syrjälä1-9/+10
encoder->disable() is supposed to happen before the pipe/transcoder gets disabled. The icl+ DSI code screwed that up and put most things (including the transcoder disable itself) into encoder->disable(). Follow the common rules and hoist most things into the encoder->post_disable() hook. Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13drm/i915/dsi: Implement encoder->shutdown() for icl+Ville Syrjälä4-7/+9
Plug in the encoder->shutdown() hook for icl+ DSI so that we are guaranteed to respect the power cycle delay during reboots and whatnot. Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13drm/i915/dsi: Respect power cycle delay on icl+Ville Syrjälä4-14/+20
Handle the DSI panel power cycle delay on icl+. Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13drm/i915/dsi: Gate DSI clocks earlierVille Syrjälä1-3/+2
The clock gating step is in the wrong spot compared to the TGL+ bspec sequence. Move it the right place. Windows also seems to use the TGL+ order here always. Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13drm/i915/dsi: Split icl+ D-PHY vs. DSI timing stepsVille Syrjälä1-26/+42
The programming of the DPHY vs. DSI _TIMING registers are two separate steps in the TGL+ bspec sequence, with some other stuff in between. Implement the same split. Windows also seems follow the bspec TGL+ sequence, even on ICL/JSL. Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13drm/i915/dsi: Print the VBT MIPI sequence delay durationVille Syrjälä1-1/+1
Help out debugging things by printing out how long the VBT delay sequence is supposed to wait. Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13drm/i915/dsi: Do display on sequence later on icl+Ville Syrjälä1-1/+2
Doing the init OTP and display on DSI sequences back to back doesn't really make any sense (a single sequence would suffice then). Move the display on sequence to be done just before backlight on, which is also what Windows does. Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13drm/i915/dsi: Do panel power on + reset deassert earlier on icl+Ville Syrjälä1-4/+6
Looks like we're trying to talk to the DSI panel even before turning it on, on icl+. Bspec doesn't actually specify when these should be done, but certainly we need to turn the panel on at least before talking to it. So let's move the power on + reset deassert steps to be the first thing we do. This is also what Windows does. v2: s/intel_dsi_msleep/msleep/ Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13drm/nouveau: don't detect DSM for non-NVIDIA deviceRatchanan Srirattanamet1-0/+3
The call site of nouveau_dsm_pci_probe() uses single set of output variables for all invocations. So, we must not write anything to them unless it's an NVIDIA device. Otherwise, if we are called with another device after the NVIDIA device, we'll clober the result of the NVIDIA device. For example, if the other device doesn't have _PR3 resources, the detection later would miss the presence of power resource support, and the rest of the code will keep using Optimus DSM, breaking power management for that machine. Also, because we're detecting NVIDIA's DSM, it doesn't make sense to run this detection on a non-NVIDIA device anyway. Thus, check at the beginning of the detection code if this is an NVIDIA card, and just return if it isn't. This, together with commit d22915d22ded ("drm/nouveau/devinit/tu102-: wait for GFW_BOOT_PROGRESS == COMPLETED") developed independently and landed earlier, fixes runtime power management of the NVIDIA card in Lenovo Legion 5-15ARH05. Without this patch, the GPU resumption code will "timeout", sometimes hanging userspace. As a bonus, we'll also stop preventing _PR3 usage from the bridge for unrelated devices, which is always nice, I guess. Fixes: ccfc2d5cdb02 ("drm/nouveau: Use generic helper to check _PR3 presence") Signed-off-by: Ratchanan Srirattanamet <[email protected]> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/79 Reviewed-by: Karol Herbst <[email protected]> Signed-off-by: Karol Herbst <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/DM6PR19MB2780805D4BE1E3F9B3AC96D0BC409@DM6PR19MB2780.namprd19.prod.outlook.com
2023-06-13drm/i915/gmch: avoid unused variable warningArnd Bergmann1-3/+1
When CONFIG_PNP is disabled, the mchbar_addr variable is only written but not read: drivers/gpu/drm/i915/soc/intel_gmch.c: In function 'intel_alloc_mchbar_resource': drivers/gpu/drm/i915/soc/intel_gmch.c:41:13: error: variable 'mchbar_addr' set but not used [-Werror=unused-but-set-variable] 41 | u64 mchbar_addr; | ^~~~~~~~~~~ No idea why this showed up now, but it's easy to fix by changing the #ifdef to an IS_ENABLED() check that the compiler can see through. Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-13Merge branch 'drm-next' of git://anongit.freedesktop.org/drm/drm into ↵Dmitry Baryshkov1130-24573/+181073
msm-next-lumag-base Merge the drm-next tree to pick up the DRM DSC helpers (merged via drm-intel-next tree). MSM DSC v1.2 patches depend on these helpers. Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-06-12drm/i915/gsc: take a wakeref for the proxy-init-completion checkAlan Previn1-8/+14
Ensure intel_gsc_uc_fw_init_done and intel_gsc_uc_fw_proxy_init takes a wakeref before reading GSC Shim registers. NOTE: another patch in review also adds a call from selftest to this same function. (https://patchwork.freedesktop.org/series/117713/) which is why i am adding the wakeref inside the callee, not the caller. v2: - add a helper, 'gsc_uc_get_fw_status' for both callers (Daniele Ceraolo) Fixes: 99afb7cc8c44 ("drm/i915/pxp: Add ARB session creation and cleanup") Signed-off-by: Alan Previn <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-10drm/i915: Fix a VMA UAF for multi-gt platformNirmoy Das1-2/+19
Ensure correct handling of closed VMAs on multi-gt platforms to prevent Use-After-Free. Currently, when GT0 goes idle, closed VMAs that are exclusively added to GT0's closed_vma link (gt->closed_vma) and subsequently freed by i915_vma_parked(), which assumes the entire GPU is idle. However, on platforms with multiple GTs, such as MTL, GT1 may remain active while GT0 is idle. This causes GT0 to mistakenly consider the closed VMAs in its closed_vma list as unnecessary, potentially leading to Use-After-Free issues if a job for GT1 attempts to access a freed VMA. Although we do take a wakeref for GT0 but it happens later, after evaluating VMAs. To mitigate this, it is necessary to hold a GT0 wakeref early. v2: Use gt id to detect multi-tile(Andi) Fix the incorrect error path. v3: Add more comment(Andi) Use the new gt var when possible(Andrzej) Cc: Joonas Lahtinen <[email protected]> Cc: Rodrigo Vivi <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Andi Shyti <[email protected]> Cc: Andrzej Hajda <[email protected]> Cc: Sushma Venkatesh Reddy <[email protected]> Signed-off-by: Nirmoy Das <[email protected]> Tested-by: Andi Shyti <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Tested-by: Sushma Venkatesh Reddy <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-10drm/msm/adreno: change adreno_is_* functions to accept const argumentDmitry Baryshkov1-28/+28
All adreno_is_*() functions do not modify their argument in any way, so they can be changed to accept const struct adreno_gpu pointer. Suggested-by: Stephen Boyd <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/531706/ Signed-off-by: Rob Clark <[email protected]>
2023-06-10drm/msm/adreno: warn if chip revn is verified before being setDmitry Baryshkov1-23/+40
The commit 010c8bbad2cb ("drm: msm: adreno: Disable preemption on Adreno 510") tried to check GPU's revn before revn being set. Add WARN_ON_ONCE to prevent such bugs from happening again. A separate helper is necessary so that the warning is displayed really just once instead of being displayed for each of comparisons. Suggested-by: Stephen Boyd <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/531705/ Signed-off-by: Rob Clark <[email protected]>
2023-06-10drm/msm/a5xx: really check for A510 in a5xx_gpu_initDmitry Baryshkov1-1/+2
The commit 010c8bbad2cb ("drm: msm: adreno: Disable preemption on Adreno 510") added special handling for a510 (this SKU doesn't seem to support preemption, so the driver should clamp nr_rings to 1). However the gpu->revn is not yet set (it is set later, in adreno_gpu_init()) and thus the condition is always false. Check config->rev instead. Fixes: 010c8bbad2cb ("drm: msm: adreno: Disable preemption on Adreno 510") Reported-by: Adam Skladowski <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Tested-by: Adam Skladowski <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/531511/ Signed-off-by: Rob Clark <[email protected]>
2023-06-10drm/msm/a6xx: Fix a690 CP_PROTECT settingsRob Clark1-2/+2
Allow access to CP_PERFCTR_CP_SEL[n] and RB_PERFCTR_RB_SEL which are used by fdperf and pps-provider (perfetto). Signed-off-by: Rob Clark <[email protected]>
2023-06-10drm/msm/adreno: Add Adreno A690 supportBjorn Andersson4-5/+166
Introduce support for the Adreno A690, found in Qualcomm SC8280XP. Tested-by: Steev Klimaszewski <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/540335/ Signed-off-by: Rob Clark <[email protected]>
2023-06-10drm/msm: Move cmdstream dumping out of sched kthreadRob Clark3-20/+10
This is something that can block for arbitrary amounts of time as userspace consumes from the FIFO. So we don't really want this to be in the fence signaling path. Signed-off-by: Rob Clark <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/532617/
2023-06-10drm/msm/a6xx: don't set IO_PGTABLE_QUIRK_ARM_OUTER_WBWA with coherent SMMUDmitry Baryshkov1-1/+2
If the Adreno SMMU is dma-coherent, allocation will fail unless we disable IO_PGTABLE_QUIRK_ARM_OUTER_WBWA. Skip setting this quirk for the coherent SMMUs (like we have on sm8350 platform). Fixes: 54af0ceb7595 ("arm64: dts: qcom: sm8350: add GPU, GMU, GPU CC and SMMU nodes") Reported-by: David Heidelberg <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Tested-by: David Heidelberg <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Tested-by: Konrad Dybcio <[email protected]> # SM8450 HDK Patchwork: https://patchwork.freedesktop.org/patch/531562/ Signed-off-by: Rob Clark <[email protected]>
2023-06-10drm/msm: drop unused ring variable in msm_ioctl_gem_submit()Dmitry Baryshkov1-3/+2
The variable ring is not used by msm_parse_deps() and msm_ioctl_gem_submit() and thus can be dropped. Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/529340/ Signed-off-by: Rob Clark <[email protected]>
2023-06-10drm/msm/adreno: fix sparse warnings in a6xx codeDmitry Baryshkov1-2/+2
Sparse reports plenty of warnings against the a6xx code because of a6xx_gmu::mmio and a6xx_gmu::rscc members. For some reason they were defined as __iomem pointers rather than pointers to __iomem memory. Correct the __iomem attribute. Fixes: 02ef80c54e7c ("drm/msm/a6xx: update pdc/rscc GMU registers for A640/A650") Reported-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Reviewed-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/531583/ Signed-off-by: Rob Clark <[email protected]>
2023-06-10Merge drm/drm-next into drm-intel-nextJani Nikula184-1238/+3789
Sync up with changes from drm-intel-gt-next. Signed-off-by: Jani Nikula <[email protected]>
2023-06-10drm/i915/selftests: add local workqueue for SW fence selftestLuca Coelho1-3/+13
Instead of using a global workqueue for the SW fence selftest, allocate a separate one temporarily only while running the test. Cc: Tetsuo Handa <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Ville Syrjälä <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/313f4a713053c2b4896ced5b0e9ff456eb85fe57.1686231190.git.jani.nikula@intel.com
2023-06-10drm/i915: add a dedicated workqueue inside drm_i915_privateLuca Coelho25-54/+110
In order to avoid flush_scheduled_work() usage, add a dedicated workqueue in the drm_i915_private structure. In this way, we don't need to use the system queue anymore. This change is mostly mechanical and based on Tetsuo's original patch[1]. v6 by Jani: - Also create unordered_wq for mock device Link: https://patchwork.freedesktop.org/series/114608/ [1] Cc: Tetsuo Handa <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Ville Syrjälä <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/c816ebe17ef08d363981942a096a586a7658a65e.1686231190.git.jani.nikula@intel.com
2023-06-10drm/i915: use pointer to i915 instead of rpm in wakerefLuca Coelho5-20/+20
Currently a pointer to an intel_runtime_pm structure is stored in the wake reference structures so the runtime data can be accessed. We can save the entire device information (drm_i915_private) instead, since we'll need to reference the new workqueue we'll add in subsequent patches. Reviewed-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Luca Coelho <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ec0eb5149120d04f3d9870d7671ef10103e6fc29.1686231190.git.jani.nikula@intel.com
Powered by cgit, Gruvboxed by Blaster4385.