summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-03-02drm/amd/display: Promote DC to 3.2.372Taimur Hassan
This version brings along the following updates: - Prevent integer overflow when mhz to khz - Remove always-false branches - Remove redundant initializers - Silence unused variable warning - Initialize replay_state to PR_STATE_INVALID - Fallback to boot snapshot for dispclk - Skip cursor cache reset if hubp powergating is disabled Reviewed-by: Leo Li <sunpeng.li@amd.com> Signed-off-by: Taimur Hassan <Syed.Hassan@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-02drm/amdgpu: Fix static assertion failure issueYiPeng Chai
Since the PAGE_SIZE is 8KB on sparc64, the size of structure amdsriov_ras_telemetry will exceed 64KB, so use absolute value to fix the buffer size. Fixes the issue: drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:522:2: error: static assertion failed due to requirement 'sizeof(struct amdsriov_ras_telemetry) <= 64 << 10': amdsriov_ras_telemetry must be 64 KB | sizeof(struct amdsriov_ras_telemetry) <= AMD_SRIOV_MSG_RAS_TELEMETRY_SIZE_KB_V1 << 10, drivers/gpu/drm/amd/amdgpu/amdgv_sriovmsg.h:522:40: note: expression evaluates to '115616 <= 65536' | sizeof(struct amdsriov_ras_telemetry) <= AMD_SRIOV_MSG_RAS_TELEMETRY_SIZE_KB_V1 << 10, Fixes: cb48a6b2b61d ("drm/amd/ras: use dedicated memory as vf ras command buffer") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202602261700.rVOLIw4l-lkp@intel.com/ Signed-off-by: YiPeng Chai <YiPeng.Chai@amd.com> Reviewed-by: Tao Zhou <tao.zhou1@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-02drm/amd/display: Prevent integer overflow when mhz to khzAlex Hung
[WHAT] Cast to long long before multiplication to prevent overflow when converting mhz to khz by multiplying by 1000. This is reported as INTEGER_OVERFLOW errors by Coverity. Reviewed-by: Roman Li <roman.li@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-02drm/amd/display: Remove always-false branchesAlex Hung
[WHAT] program_prealpha_dealpha and hpo_frl_stream_enc_acquired are always false and all branches depending on them will never be taken. This is reported as DEADCODE errors by Coverity. Reviewed-by: Roman Li <roman.li@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-02drm/amd/display: Remove redundant initializersAlex Hung
[WHAT] Remove unnecessary default value assignments for variables that are unconditionally assigned before use. Linux kernel code style prefers no assignments during initialization when variables are assigned unconditionally as they can obscures the actual data flow. In addition, compilers will be able to catch them if variables are used without being updated later in all conditions. This is reported as UNUSED_VALUE errors by Coverity. Reviewed-by: Roman Li <roman.li@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-02drm/amd/display: Silence unused variable warningClay King
[WHY & HOW] Remove unused dpp_pipe_count variable. Reviewed-by: Austin Zheng <austin.zheng@amd.com> Signed-off-by: Clay King <clayking@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-02drm/amd/display: Initialize replay_state to PR_STATE_INVALIDIvan Lipski
[WHY & HOW] Initialize the replay_state variable to PR_STATE_INVALID instead of PR_STATE_0 before retrieving the actual replay state. Reviewed-by: Wenjing Liu <wenjing.liu@amd.com> Signed-off-by: Ivan Lipski <ivan.lipski@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-02drm/amd/display: Fallback to boot snapshot for dispclkDillon Varone
[WHY & HOW] If the dentist is unavailable, fallback to reading CLKIP via the boot snapshot to get the current dispclk. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Dillon Varone <Dillon.Varone@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Tested-by: Dan Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-02drm/amd/pm: fix kernel-doc warning for smu_msg_v1_send_msg()Yujie Liu
Warning: drivers/gpu/drm/amd/amdgpu/../pm/swsmu/smu_cmn.c:415 expecting prototype for smu_msg_proto_v1_send_msg(). Prototype was for smu_msg_v1_send_msg() instead Fixes: 4f379370a49c ("drm/amd/pm: Add smu message control block") Signed-off-by: Yujie Liu <yujie.liu@intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-02drm/amd/ras: fix kernel-doc warning for ras_eeprom_append()Yujie Liu
Warning: drivers/gpu/drm/amd/amdgpu/../ras/rascore/ras_eeprom.c:845 function parameter 'ras_core' not described in 'ras_eeprom_append' Warning: drivers/gpu/drm/amd/amdgpu/../ras/rascore/ras_eeprom.c:845 expecting prototype for ras_core_eeprom_append(). Prototype was for ras_eeprom_append() instead Fixes: 5c3be5defc92 ("drm/amd/ras: Add eeprom ras functions") Signed-off-by: Yujie Liu <yujie.liu@intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-02drm/amdgpu: fix kernel-doc warning for amdgpu_ttm_alloc_mmio_remap_bo()Yujie Liu
Warning: drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:1923 expecting prototype for amdgpu_ttm_mmio_remap_bo_init(). Prototype was for amdgpu_ttm_alloc_mmio_remap_bo() instead Fixes: 96e97a562d06 ("drm/amdgpu: Drop MMIO_REMAP domain bit and keep it Internal") Signed-off-by: Yujie Liu <yujie.liu@intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-02drm/amd/ras: Fix type size of remainder argumentKees Cook
Forcing an int to be dereferenced at uint64_t for div64_u64_rem() runs the risk of endian confusion and stack overflowing writes. Seen while preparing to enable -Warray-bounds globally: In file included from ../arch/x86/include/asm/processor.h:35, from ../include/linux/sched.h:13, from ../include/linux/ratelimit.h:6, from ../include/linux/dev_printk.h:16, from ../drivers/gpu/drm/amd/amdgpu/../ras/ras_mgr/ras_sys.h:29, from ../drivers/gpu/drm/amd/amdgpu/../ras/rascore/ras.h:27, from ../drivers/gpu/drm/amd/amdgpu/../ras/rascore/ras_core.c:24: In function 'div64_u64_rem', inlined from 'ras_core_convert_timestamp_to_time' at ../drivers/gpu/drm/amd/amdgpu/../ras/rascore/ras_core.c:72:9: ../include/linux/math64.h:56:20: error: array subscript 'u64 {aka long long unsigned int}[0]' is partly outside array bounds of 'int[1]' [-Werror=array-bounds=] 56 | *remainder = dividend % divisor; | ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~ ../drivers/gpu/drm/amd/amdgpu/../ras/rascore/ras_core.c: In function 'ras_core_convert_timestamp_to_time': ../drivers/gpu/drm/amd/amdgpu/../ras/rascore/ras_core.c:70:19: note: object 'remaining_seconds' of size 4 70 | int days, remaining_seconds; | ^~~~~~~~~~~~~~~~~ Use a 64-bit type for the remainder calculation, but leave remaining_seconds as 32-bit to avoid 64-bit division later. The value of remainder will always be less than seconds_per_day, so there's no truncation risk. Fixes: ace232eff50e ("drm/amdgpu: Add ras module files into amdgpu") Signed-off-by: Kees Cook <kees@kernel.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-02drm/amdgpu: Move register access functionsLijo Lazar
Move register access methods from amdgpu_device.c to a dedicated file. Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-02drm/amdgpu: Enable DPG support for VCN5sguttula
This will set DPG flags for enabling power gating on GFX11_5_4 Signed-off-by: sguttula <suresh.guttula@amd.com> Reviewed-by: Pratik Vishwakarma <Pratik.Vishwakarma@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-02drm/amd/display: Enable DEGAMMA and reject COLOR_PIPELINE+DEGAMMA_LUTAlex Hung
[WHAT] Create DEGAMMA properties even if color pipeline is enabled, and enforce the mutual exclusion in atomic check by rejecting any commit that attempts to enable both COLOR_PIPELINE on the plane and DEGAMMA_LUT on the CRTC simultaneously. Fixes: 18a4127e9315 ("drm/amd/display: Disable CRTC degamma when color pipeline is enabled") Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4963 Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-02drm/amd/display: Use mpc.preblend flag to indicate 3D LUTAlex Hung
[WHAT] New ASIC's 3D LUT is indicated by mpc.preblend. Fixes: 0de2b1afea8d ("drm/amd/display: add 3D LUT colorop") Reviewed-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-03-02drm/xe/xe2_hpg: Correct implementation of Wa_16025250150Matt Roper
Wa_16025250150 asks us to set five register fields of the register to 0x1 each. However we were just OR'ing this into the existing register value (which has a default of 0x4 for each nibble-sized field) resulting in final field values of 0x5 instead of the desired 0x1. Correct the RTP programming (use FIELD_SET instead of SET) to ensure each field is assigned to exactly the value we want. Cc: Aradhya Bhatia <aradhya.bhatia@intel.com> Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: stable@vger.kernel.org # v6.16+ Fixes: 7654d51f1fd8 ("drm/xe/xe2hpg: Add Wa_16025250150") Reviewed-by: Ngai-Mint Kwan <ngai-mint.kwan@linux.intel.com> Link: https://patch.msgid.link/20260227164341.3600098-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-03-02drm/xe/lrc: Refactor context init into xe_lrc_ctx_init()Raag Jadav
Currently xe_lrc_init() does two things. 1. Allocates LRC bo based on exec queue parameters. 2. Initializes LRC bo with actual context details. Introduce xe_lrc_ctx_init() and split these two implementations for better maintainability. Signed-off-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260302082757.3516577-1-raag.jadav@intel.com
2026-03-02drm/xe/gsc: Fix GSC proxy cleanup on early initialization failureZhanjun Dong
xe_gsc_proxy_remove undoes what is done in both xe_gsc_proxy_init and xe_gsc_proxy_start; however, if we fail between those 2 calls, it is possible that the HW forcewake access hasn't been initialized yet and so we hit errors when the cleanup code tries to write GSC register. To avoid that, split the cleanup in 2 functions so that the HW cleanup is only called if the HW setup was completed successfully. Since the HW cleanup (interrupt disabling) is now removed from xe_gsc_proxy_remove, the cleanup on error paths in xe_gsc_proxy_start must be updated to disable interrupts before returning. Fixes: ff6cd29b690b ("drm/xe: Cleanup unwind of gt initialization") Signed-off-by: Zhanjun Dong <zhanjun.dong@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260220225308.101469-1-zhanjun.dong@intel.com
2026-03-02drm/tyr: Clarify driver/device type namesDeborah Brouwer
Currently the `TyrDriver` struct implements both `platform::Driver` and `drm::Driver`. For clarity, split up these two roles: - Introduce `TyrPlatformDriverData` to implement `platform::Driver`, and - Introduce `TyrDrmDriver` to implement `drm::Driver`. Also rename other variables to reflect their roles in the DRM context: - Rename `TyrDevice` to `TyrDrmDevice` - Rename `TyrData` to `TyrDrmDeviceData` - Rename `File` to `TyrDrmFileData` - Rename `DrmFile` to `TyrDrmFile` No functional changes are intended. Co-developed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Deborah Brouwer <deborah.brouwer@collabora.com> Link: https://patch.msgid.link/20260224002314.344675-1-deborah.brouwer@collabora.com Signed-off-by: Alice Ryhl <aliceryhl@google.com>
2026-03-02drm/xe/queue: Call fini on exec queue creation failTomasz Lis
Every call to queue init should have a corresponding fini call. Skipping this would mean skipping removal of the queue from GuC list (which is part of guc_id allocation). A damaged queue stored in exec_queue_lookup list would lead to invalid memory reference, sooner or later. Call fini to free guc_id. This must be done before any internal LRCs are freed. Since the finalization with this extra call became very similar to __xe_exec_queue_fini(), reuse that. To make this reuse possible, alter xe_lrc_put() so it can survive NULL parameters, like other similar functions. v2: Reuse _xe_exec_queue_fini(). Make xe_lrc_put() aware of NULLs. Fixes: 3c1fa4aa60b1 ("drm/xe: Move queue init before LRC creation") Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> (v1) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260226212701.2937065-2-tomasz.lis@intel.com (cherry picked from commit 393e5fea6f7d7054abc2c3d97a4cfe8306cd6079) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-02drm/xe/configfs: Free ctx_restore_mid_bb in releaseShuicheng Lin
ctx_restore_mid_bb memory is allocated in wa_bb_store(), but xe_config_device_release() only frees ctx_restore_post_bb. Free ctx_restore_mid_bb[0].cs as well to avoid leaking the allocation when the configfs device is removed. Fixes: b30d5de3d40c ("drm/xe/configfs: Add mid context restore bb") Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Nitin Gote <nitin.r.gote@intel.com> Link: https://patch.msgid.link/20260225013448.3547687-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (cherry picked from commit a235e7d0098337c3f2d1e8f3610c719a589e115f) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-02drm/xe: Do not preempt fence signaling CS instructionsMatthew Brost
If a batch buffer is complete, it makes little sense to preempt the fence signaling instructions in the ring, as the largest portion of the work (the batch buffer) is already done and fence signaling consists of only a few instructions. If these instructions are preempted, the GuC would need to perform a context switch just to signal the fence, which is costly and delays fence signaling. Avoid this scenario by disabling preemption immediately after the BB start instruction and re-enabling it after executing the fence signaling instructions. Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Carlos Santa <carlos.santa@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patch.msgid.link/20260115004546.58060-1-matthew.brost@intel.com (cherry picked from commit 2bcbf2dcde0c839a73af664a3c77d4e77d58a3eb) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-03-02drm/syncobj: Fix handle <-> fd ioctls with dirty stackJulian Orth
Consider the following application: #include <fcntl.h> #include <string.h> #include <drm/drm.h> #include <sys/ioctl.h> int main(void) { int fd = open("/dev/dri/renderD128", O_RDWR); struct drm_syncobj_create arg1; ioctl(fd, DRM_IOCTL_SYNCOBJ_CREATE, &arg1); struct drm_syncobj_handle arg2; memset(&arg2, 1, sizeof(arg2)); // simulate dirty stack arg2.handle = arg1.handle; arg2.flags = 0; arg2.fd = 0; arg2.pad = 0; // arg2.point = 0; // userspace is required to set point to 0 ioctl(fd, DRM_IOCTL_SYNCOBJ_HANDLE_TO_FD, &arg2); } The last ioctl returns EINVAL because args->point is not 0. However, userspace developed against older kernel versions is not aware of the new point field and might therefore not initialize it. The correct check would be if (args->flags & DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_TIMELINE) return -EINVAL; However, there might already be userspace that relies on this not returning an error as long as point == 0. Therefore use the more lenient check. Fixes: c2d3a7300695 ("drm/syncobj: Extend EXPORT_SYNC_FILE for timeline syncobjs") Signed-off-by: Julian Orth <ju.orth@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20260301-point-v1-1-21fc5fd98614@gmail.com
2026-03-02drm/panthor: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. The test itself does not change. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Steven Price <steven.price@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20260227133113.235940-8-tzimmermann@suse.de
2026-03-02drm/panfrost: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. The test itself does not change. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Rob Herring <robh@kernel.org> Cc: Steven Price <steven.price@arm.com> Cc: "Adrián Larumbe" <adrian.larumbe@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20260227133113.235940-7-tzimmermann@suse.de
2026-03-02drm: renesas: rz-du: mipi_dsi: Set DSI dividerChris Brandt
Before the MIPI DSI clock source can be configured, the target divide ratio needs to be set. Signed-off-by: Chris Brandt <chris.brandt@renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Tested-by: Biju Das <biju.das.jz@bp.renesas.com> Fixes: 5a4326f2e3b1 ("clk: renesas: rzg2l: Remove DSI clock rate restrictions") Link: https://patch.msgid.link/20260227015216.2721504-1-chris.brandt@renesas.com Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
2026-03-02Merge tag 'drm-misc-next-2026-02-26' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v7.1: UAPI Changes: connector: - Add panel_type property fourcc: - Add ARM interleaved 64k modifier nouveau: - Query Z-Cull info with DRM_IOCTL_NOUVEAU_GET_ZCULL_INFO Cross-subsystem Changes: coreboot: - Clean up coreboot framebuffer support dma-buf: - Provide revoke mechanism for shared buffers - Rename move_notify callback to invalidate_mappings and update users. - Always enable move_notify - Support dma_fence_was_initialized() test - Protect dma_fence_ops by RCU and improve locking - Fix sparse warnings Core Changes: atomic: - Allocate drm_private_state via callback and convert drivers atomic-helper: - Use system_percpu_wq buddy: - Make buddy allocator available to all DRM drivers - Document flags and structures colorop: - Add destroy helper and convert drivers fbdev-emulation: - Clean up gem: - Fix drm_gem_objects_lookup() error cleanup Driver Changes: amdgpu: - Set panel_type to OELD for eDP atmel-hlcdc: - Support sana5d65 LCD controller bridge: - anx7625: Support USB-C plus DT bindings - connector: Fix EDID detection - dw-hdmi-qp: Support Vendor-Specfic and SDP Infoframes; improve others - fsl-ldb: Fix visual artifacts plus related DT property 'enable-termination-resistor' - imx8qxp-pixel-link: Improve bridge reference handling - lt9611: Support Port-B-only input plus DT bindings - tda998x: Support DRM_BRIDGE_ATTACH_NO_CONNECTOR; Clean up - Support TH1520 HDMI plus DT bindings - Clean up imagination: - Clean up komeda: - Fix integer overflow in AFBC checks mcde: - Improve bridge handling nouveau: - Provide Z-cull info to user space - gsp: Support GA100 - Shutdown on PCI device shutdown - Clean up panel: - panel-jdi-lt070me05000: Use mipi-dsi multi functions - panel-edp: Support Add AUO B116XAT04.1 (HW: 1A); Support CMN N116BCL-EAK (C2); Support FriendlyELEC plus DT changes - Fix Kconfig dependencies panthor: - Add tracepoints for power and IRQs rcar-du: - dsi: fix VCLK calculation rockchip: - vop2: Use drm_ logging functions - Support DisplayPort on RK3576 sysfb: - corebootdrm: Support system framebuffer on coreboot firmware; detect orientation - Clean up pixel-format lookup sun4i: - Clean up tilcdc: - Use DT bindings scheme - Use managed DRM interfaces - Support DRM_BRIDGE_ATTACH_NO_CONNECTOR - Clean up a lot of obsolete code v3d: - Clean up vc4: - Use system_percpu_wq - Clean up verisilicon: - Support DC8200 plus DT bindings virtgpu: - Support PRIME imports with enabled 3D Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260226143615.GA47200@linux.fritz.box
2026-03-01gpu: nova-core: Kconfig: Sort select statements alphabeticallyJoel Fernandes
Reorder the select statements in NOVA_CORE Kconfig to be in alphabetical order. Suggested-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Joel Fernandes <joelagnelf@nvidia.com> Link: https://patch.msgid.link/20260224225323.3312204-3-joelagnelf@nvidia.com [acourbot@nvidia.com: fix conflict due to patch reordering.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-02-27drm/xe/vf: Redo LRC creation while in VF fixupsTomasz Lis
If the xe module within a VM was creating a new LRC during save/ restore, this LRC will be invalid. The fixups procedure may not be able to reach it, as there will be a race to add the new LRC reference to an exec queue. Even if the new LRC which was being created during VM migration is added to EQ in time for fixups, said LRC may still remain damaged. In a small percentage of specially crafted test cases, the resulting LRC was still damaged and caused GPU hang. Any LRC which could be created in such a situation, have to be re-created. Due to VM having arbitrarily set amount of CPU cores, it is possible to limit the amount to 1. In such case, there is a possibility that kernel will switch CPU contexts in a way which allows to miss VF migration recovery running in parallel (by simply not switching to the LRC creation thread during recovery). Therefore checking if the migration is in progress just after LRC creation, is not enough to ensure detection. Free the incorrectly created LRC, and trigger a re-run of the creation, but only after waiting for default LRC to get fixups. Use additional atomic value increased after fixups, to ensure any VF migration that avoided detection by just checking for recovery in progress, will be caught. v2: Merge marker and wait for default LRC, reducing amount of calls within xe_init_eq(). Alter the LRC creation loop to remove a race with post-migration fixups worker. v3: Kerneldoc fixes. Rename fixups_complete_count. Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260226212701.2937065-5-tomasz.lis@intel.com
2026-02-27drm/xe/vf: Wait for all fixups before using default LRCsTomasz Lis
When a context is being created during save/restore, the LRC creation needs to wait for GGTT address space to be shifted. But it also needs to have fixed default LRCs. This is mandatory to avoid the situation where LRC will be created based on data from before the fixups, but reference within exec queue will be set too late for fixups. This fixes an issue where contexts created during save/restore have a large chance of having one unfixed LRC, due to the xe_lrc_create() being synced for equal start to race with default LRC fixups. v2: Move the fixups confirmation further, behind all fixups. Revert some renames. Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260226212701.2937065-4-tomasz.lis@intel.com
2026-02-27drm/xe: Wrappers for setting and getting LRC referencesTomasz Lis
There is a small but non-zero chance that VF post migration fixups are running on an exec queue during teardown. The chances are decreased by starting the teardown by releasing guc_id, but remain non-zero. On the other hand the sync between fixups and EQ creation (wait_valid_ggtt) drastically increases the chance for such parallel teardown if queue creation error path is entered (err_lrc label). The exec queue itself is not going to cause an issue, but LRCs have a small chance of getting freed during the fixups. Creating a setter and a getter makes it easier to protect the fixup operations with a lock. For other driver activities, the original access method (without any protection) can still be used. v2: Separate lock, only for LRCs. Kerneldoc fixes. Subject tag fix. Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260226212701.2937065-3-tomasz.lis@intel.com
2026-02-27drm/xe/queue: Call fini on exec queue creation failTomasz Lis
Every call to queue init should have a corresponding fini call. Skipping this would mean skipping removal of the queue from GuC list (which is part of guc_id allocation). A damaged queue stored in exec_queue_lookup list would lead to invalid memory reference, sooner or later. Call fini to free guc_id. This must be done before any internal LRCs are freed. Since the finalization with this extra call became very similar to __xe_exec_queue_fini(), reuse that. To make this reuse possible, alter xe_lrc_put() so it can survive NULL parameters, like other similar functions. v2: Reuse _xe_exec_queue_fini(). Make xe_lrc_put() aware of NULLs. Fixes: 3c1fa4aa60b1 ("drm/xe: Move queue init before LRC creation") Signed-off-by: Tomasz Lis <tomasz.lis@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> (v1) Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260226212701.2937065-2-tomasz.lis@intel.com
2026-02-27drm/xe: restrict multi-lrc to VCS/VECS enginesXin Wang
Tighten uapi validation to restrict multi-lrc support to VIDEO_DECODE and VIDEO_ENHANCE engines only. This check should have been in place from the start, as the driver typically avoids allowing uapi cases that we have no userspace consumer for. Additionally, the GuC firmware on ModSched platforms no longer supports multi-lrc on non-media engines. V4: - use a unified mask for all platforms since engine instance count is an independent runtime check (Matt Roper, Matthew Brost) V3: - store a multi-lrc enable class mask in xe->info and populate from xe_device_desc in xe_pci.c (Matthew Brost) V2: - correct the typo (Shuicheng) - move the check earlier to avoid VM lookup (Shuicheng, Matt Roper) - remove the graphics version check (Matt Roper) - input more details in the commit info (Matt Roper) Cc: Shuicheng Lin <shuicheng.lin@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Xin Wang <x.wang@intel.com> Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260225022014.45394-1-x.wang@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-27drm/xe/tuning: Apply windower hardware filtering setting on Xe3 and Xe3pMatt Roper
A recent bspec tuning guide update asks us to program COMMON_SLICE_CHICKEN4[5] on Xe3 and Xe3p platforms. Add this setting to our LRC tuning RTP table so that the setting will become part of each context's LRC. Bspec: 72161, 55902 Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260224235055.3038710-2-matthew.d.roper@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-27drm/i915: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. The test itself does not change. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tursulin@ursulin.net> Cc: intel-gfx@lists.freedesktop.org Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260227133113.235940-5-tzimmermann@suse.de
2026-02-27drm/ttm: Fix ttm_pool_beneficial_order() return typeTvrtko Ursulin
Fix a nasty copy and paste bug, where the incorrect boolean return type of the ttm_pool_beneficial_order() helper had a consequence of avoiding direct reclaim too eagerly for drivers which use this feature (currently amdgpu). Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: 7e9c548d3709 ("drm/ttm: Allow drivers to specify maximum beneficial TTM pool size") Cc: Christian König <christian.koenig@amd.com> Cc: Thadeu Lima de Souza Cascardo <cascardo@igalia.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.19+ Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20260227124901.3177-1-tvrtko.ursulin@igalia.com
2026-02-27drm/nouveau: Test for imported buffers with drm_gem_is_imported()Thomas Zimmermann
Instead of testing import_attach for imported GEM buffers, invoke drm_gem_is_imported() to do the test. The test itself does not change. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Lyude Paul <lyude@redhat.com> Cc: Danilo Krummrich <dakr@kernel.org> Cc: nouveau@lists.freedesktop.org Link: https://patch.msgid.link/20260227133113.235940-6-tzimmermann@suse.de Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-02-27drm/tests: Mark slow tests as slowMaxime Ripard
Some DRM tests cross the 1s execution time threshold that defines a test as slow. Let's flag them as such. Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260224110310.1854608-1-mripard@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2026-02-27drm/sched: Remove racy hack from drm_sched_fini()Philipp Stanner
drm_sched_fini() contained a hack to work around a race in amdgpu. According to AMD, the hack should not be necessary anymore. In case there should have been undetected users, commit 975ca62a014c ("drm/sched: Add warning for removing hack in drm_sched_fini()") had added a warning one release cycle ago. Thus, it can be derived that the hack can be savely removed by now. Remove the hack. Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Philipp Stanner <phasta@kernel.org> Link: https://patch.msgid.link/20260108083019.63532-2-phasta@kernel.org
2026-02-27drm/i915/overlay: Convert overlay to parent interfaceVille Syrjälä
Convert the direct i915_overlay_*() calls from the display side to go over a new parent interface instead. v2: Correctly handle the ERR_PTR returned by i915_overlay_obj_lookup() (Jani) v3: Rebase due to the NULL check in intel_overlay_cleanup() Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226130150.16816-1-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Move i915 specific code into i915_overlay.cVille Syrjälä
Relocate the i915 driver specific parts of the overlay code into i915_overlay.c. This leaves intel_overlay.c with just the display specific code. The one annoyance here is the DSPCLK_GATE_D register access being done from i830_overlay_clock_gating(). The register definition lives on the display side as we do need to access it on other platforms there. Since it's just one register and bit, I decided to just duplicate that part in i915_reg.h. v2: Use kzalloc_obj() Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226133855.17690-1-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Don't use fetch_and_zero() in display codeVille Syrjälä
We don't generally want fetch_and_zero() on the display side, so stop using it in the display side intel_overlay_cleanup(). Fortunately we don't really have anything to do here apart from freeing the data. And we'll keep on clearing the pointer, just in case something somewhere cares about it. Note that once i915_overlay_cleanup() is converted to the parent interface we can't call it unconditionally (as xe won't have it). So we need to keep the early bailout for overlay==NULL. v2: Adjust the commit message since we do apparently have fetch_and_zero() in display code as well (Jani) v3: Skip i915_overlay_cleanup() if the overlay wasn't initialized Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226130113.16714-1-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Split 'struct intel_overlay'Ville Syrjälä
Split the i915 driver specific bits from 'struct intel_overlay' into a seaarate 'struct i915_overlay'. The latter will move to the i915 side of the parent vs. display driver split. The display side will also need to know the virtual address of the register map. That now gets passed as the return value from i915_overlay_setup(), so that the display side doesn't need to know how the mapping was achieved. v2: Use kzalloc_obj() Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-17-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: s/dev_priv/i915/Ville Syrjälä
Rename the one lingering 'dev_priv' variable to the more modern 'i915' in the overlay code. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-16-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Make i830_overlay_clock_gating() i915 specificVille Syrjälä
i830_overlay_clock_gating() will remain on the i915 side of the parent vs. display driver split. Stop using display specific stuff inside it. The one annoyance here is access to the display engine's DSPCLK_GATE_D register. The proper way to deal with that might be to move it to the display side, but that seems a bit hard right now. So leave it where it is for now. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-15-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Adjust i915 specific interfacesVille Syrjälä
Adjust the names ("i915_overlay_" prefix) and calling convention (pass the driver agnostic 'struct drm_device'() of the functions that will provide the remainder of the parent driver interface to be used by the overlay display code. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-14-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Rename low level i915 specific functionsVille Syrjälä
Some of the lower level functions in the overlay code will move to the i915 side of the upcoming parent vs. display driver split. Move all such functions to the "i915_overlay_" namespace to make it easier to see what belongs where. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-13-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Abstract buffer (un)pinningVille Syrjälä
Make the buffer (un)pinning a bit more abstract so that the display side of the code doesn't need to know about i915 specific things (i915_ggtt_offset() and i915_vma_unpin()). In preparation for the full parent vs. display driver split we'll also pass in the drm_device to these functions, although not strictly needed yet. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-12-ville.syrjala@linux.intel.com
2026-02-27drm/i915/overlay: Extract i915_overlay_cleanup()Ville Syrjälä
Pull the i915 specific bits of the overlay cleanup into a separate function (i915_overlay_cleanup()) to accommodate the upcoming parent vs. display driver split. For now we'll also have to pass in the overlay struct, but that will disappear once the i915 vs. display split is completed. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260226100738.29997-11-ville.syrjala@linux.intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-08 17:46:33 +0000