summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-02-02drm/xe/pf: Simplify IS_SRIOV_PF macroMichal Wajdeczko
Instead of two having variants of the IS_SRIOV_PF macro, move the CONFIG_PCI_IOV check to the xe_device_is_sriov_pf() function and let the compiler optimize that. This will help us drop poor man's type check of the macro parameter that fails on const xe pointer. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20260128222714.3056-1-michal.wajdeczko@intel.com
2026-02-02drm/xe: Fix kerneldoc for xe_tlb_inval_job_alloc_depShuicheng Lin
Correct the function name in the kerneldoc. It is for below warning: "Warning: drivers/gpu/drm/xe/xe_tlb_inval_job.c:210 expecting prototype for xe_tlb_inval_alloc_dep(). Prototype was for xe_tlb_inval_job_alloc_dep() instead" Fixes: 15366239e2130 ("drm/xe: Decouple TLB invalidations from GT") Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260129233834.419977-8-shuicheng.lin@intel.com
2026-02-02drm/xe: Fix kerneldoc for xe_gt_tlb_inval_init_earlyShuicheng Lin
Correct the function name in the kerneldoc. It is for below warning: "Warning: drivers/gpu/drm/xe/xe_tlb_inval.c:136 expecting prototype for xe_gt_tlb_inval_init(). Prototype was for xe_gt_tlb_inval_init_early() instead" v2: add () for the function. (Michal) Fixes: db16f9d90c1d9 ("drm/xe: Split TLB invalidation code in frontend and backend") Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260129233834.419977-7-shuicheng.lin@intel.com
2026-02-02drm/xe: Fix kerneldoc for xe_migrate_exec_queueShuicheng Lin
Correct the function name in the kerneldoc. It is for below warning: "Warning: drivers/gpu/drm/xe/xe_migrate.c:1262 expecting prototype for xe_get_migrate_exec_queue(). Prototype was for xe_migrate_exec_queue() instead" Fixes: 916ee4704a865 ("drm/xe/vf: Register CCS read/write contexts with Guc") Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260129233834.419977-6-shuicheng.lin@intel.com
2026-02-02drm/xe/query: Fix topology query pointer advanceShuicheng Lin
The topology query helper advanced the user pointer by the size of the pointer, not the size of the structure. This can misalign the output blob and corrupt the following mask. Fix the increment to use sizeof(*topo). There is no issue currently, as sizeof(*topo) happens to be equal to sizeof(topo) on 64-bit systems (both evaluate to 8 bytes). Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260130043907.465128-2-shuicheng.lin@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-02drm/xe: use entry_dump callbacks for xe2+ PAT dumpsXin Wang
Move xe2+ PAT entry printing into the entry_dump op so platform specific logic stays localized, simplifying future maintenance. v2: - Do not null xe->pat.ops for VFs. - Skip PAT init and dump on VFs (-EOPNOTSUPP), avoiding NULL ops use. v3: - fixed typo v4: (Matt) - Switch xe2_dump() to use the new ops->entry_dump() vfunc. - Remove xe3p_xpc_dump() and reuse the common xe2_dump() for Xe3p XPC. - This also fixes Xe3p_HPM media PAT dumping by using the proper non-MCR access for the PAT register range (bspec 76445). Cc: Matt Roper <matthew.d.roper@intel.com> Suggested-by: Brian Nguyen <brian3.nguyen@intel.com> Signed-off-by: Xin Wang <x.wang@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260130175349.2249033-1-x.wang@intel.com Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
2026-02-02drm/xe/guc: Fix kernel-doc warning in GuC scheduler ABI headerChaitanya Kumar Borah
The GuC scheduler ABI header contains a file-level comment that is not intended to document a kernel-doc symbol. Using kernel-doc comment syntax (/** */) triggers kernel-doc warnings. With "-Werror", this causes the build to fail. Convert the comment to a regular block comment. HDRTEST drivers/gpu/drm/xe/abi/guc_scheduler_abi.h Warning: drivers/gpu/drm/xe/abi/guc_scheduler_abi.h:11 This comment starts with '/**', but isn't a kernel-doc comment. Refer to Documentation/doc-guide/kernel-doc.rst * Generic defines required for registration with and submissions to the GuC 1 warnings as errors make[6]: *** [drivers/gpu/drm/xe/Makefile:377: drivers/gpu/drm/xe/abi/guc_scheduler_abi.hdrtest] Error 3 make[5]: *** [scripts/Makefile.build:544: drivers/gpu/drm/xe] Error 2 make[4]: *** [scripts/Makefile.build:544: drivers/gpu/drm] Error 2 make[3]: *** [scripts/Makefile.build:544: drivers/gpu] Error 2 make[2]: *** [scripts/Makefile.build:544: drivers] Error 2 make[1]: *** [/home/kbuild2/kernel/Makefile:2088: .] Error 2 make: *** [Makefile:248: __sub-make] Error 2 v2: - Add Fixes tag (Daniele) Fixes: b0c5cf4f5917 ("drm/gt/guc: extract scheduler-related defines from guc_fwif.h") Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Shuicheng Lin <shuicheng.lin@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/20260130135210.2659200-1-chaitanya.kumar.borah@intel.com
2026-02-02drm/xe/guc: Fix CFI violation in debugfs access.Daniele Ceraolo Spurio
xe_guc_print_info is void-returning, but the function pointer it is assigned to expects an int-returning function, leading to the following CFI error: [ 206.873690] CFI failure at guc_debugfs_show+0xa1/0xf0 [xe] (target: xe_guc_print_info+0x0/0x370 [xe]; expected type: 0xbe3bc66a) Fix this by updating xe_guc_print_info to return an integer. Fixes: e15826bb3c2c ("drm/xe/guc: Refactor GuC debugfs initialization") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: George D Sworo <george.d.sworo@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patch.msgid.link/20260129182547.32899-2-daniele.ceraolospurio@intel.com
2026-02-02drm/panel-edp: Move FriendlyELEC HD702ERobin Murphy
FriendlyELEC's HD702E module is an eDP panel (in as much as it's some LVDS LCD behind a Chrontel CH7511B eDP bridge), so move its data over to the eDP driver, also resolving the warning about the missing bpc value in the process. The unfortunate combination of HPD not being wired up and the RK3399 eDP controller's behaviour seems to result in the EDID not being readable over DP-AUX without probing the panel first, thus the hard-coded mode is still needed to get things going. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/a00a59dcef3693efb02a8ee942848fbeaeaf05ba.1769191673.git.robin.murphy@arm.com
2026-02-02drm/panel: boe-th101mb31ig002: Remove use of deprecated mipi_dsi_dcs_nop()Caio Ishikawa
Replace calls to deprecated mipi_dsi_dcs_nop() with mipi_dsi_dcs_nop_multi(). No intended functional changes. Signed-off-by: Caio Ishikawa <caio.ishikawa@proton.me> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260124124959.196051-3-caio.ishikawa@proton.me
2026-02-02drm/i915/display: fix the pixel normalization handling for xe3p_lpdVinod Govindapillai
Pixel normalizer is enabled with normalization factor as 1.0 for FP16 formats in order to support FBC for those formats in xe3p_lpd. Previously pixel normalizer gets disabled during the plane disable routine. But there could be plane format settings without explicitly calling the plane disable in-between and we could endup keeping the pixel normalizer enabled for formats which we don't require that. This is causing crc mismatches in yuv formats and FIFO underruns in planar formats like NV12. Fix this by updating the pixel normalizer configuration based on the pixel formats explicitly during the plane settings arm calls itself - enable it for FP16 and disable it for other formats in HDR capable planes. v2: avoid redundant pixel normalization setting updates v3: moved the normalization factor definition to intel_fbc.c and some updates to comments v4: simplified the pixel normalizer setting handling Fixes: 5298eea7ed20 ("drm/i915/xe3p_lpd: use pixel normalizer for fp16 formats for FBC") Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260130095919.107805-1-vinod.govindapillai@intel.com (cherry picked from commit c0dc68f4e2aa7eddb9ec6d95931f9576d8fe7334) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-02-02drm/vc4: Replace IDR with XArray for perfmon trackingMaíra Canal
The IDR interface is deprecated and the XArray API is the recommended replacement. Replace the per-file IDR used to track perfmons with an XArray. This allows us to remove the external mutex that protects the IDR. While at it, introduce the vc4_perfmon_delete() helper to consolidate the perfmon cleanup logic used by both vc4_perfmon_close_file() and vc4_perfmon_destroy_ioctl(). Also, remove the redundant assignment of vc4file->dev to itself in vc4_perfmon_open_file(). Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://patch.msgid.link/20260127115822.64401-2-mcanal@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-02-02drm/v3d: Replace IDR with XArray for perfmon trackingMaíra Canal
The IDR interface is deprecated and the XArray API is the recommended replacement. Replace the per-file IDR used to track perfmons with an XArray. This allows us to remove the external mutex that protects the IDR. While here, introduce the v3d_perfmon_delete() helper to consolidate the perfmon cleanup logic used by both v3d_perfmon_close_file() and v3d_perfmon_destroy_ioctl(). Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Link: https://patch.msgid.link/20260127115822.64401-1-mcanal@igalia.com Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-02-02drm/xe: Apply WA_16028005424 to MediaBalasubramani Vivekanandan
Apply WA_16028005424 to following IPs: Xe2_LPM, Xe2_HPM, Xe3_LPM, Xe3p_LPM While doing this move the same WA defined for Xe3_LPG under the comment for Xe3_LPG. It was wrongly placed under Xe3_LPM. Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260128062911.1456539-2-balasubramani.vivekanandan@intel.com
2026-02-02drm/i915/display: fix the pixel normalization handling for xe3p_lpdVinod Govindapillai
Pixel normalizer is enabled with normalization factor as 1.0 for FP16 formats in order to support FBC for those formats in xe3p_lpd. Previously pixel normalizer gets disabled during the plane disable routine. But there could be plane format settings without explicitly calling the plane disable in-between and we could endup keeping the pixel normalizer enabled for formats which we don't require that. This is causing crc mismatches in yuv formats and FIFO underruns in planar formats like NV12. Fix this by updating the pixel normalizer configuration based on the pixel formats explicitly during the plane settings arm calls itself - enable it for FP16 and disable it for other formats in HDR capable planes. v2: avoid redundant pixel normalization setting updates v3: moved the normalization factor definition to intel_fbc.c and some updates to comments v4: simplified the pixel normalizer setting handling Fixes: 5298eea7ed20 ("drm/i915/xe3p_lpd: use pixel normalizer for fp16 formats for FBC") Signed-off-by: Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Link: https://patch.msgid.link/20260130095919.107805-1-vinod.govindapillai@intel.com
2026-02-02Revert "drm/gma500: use drm_crtc_vblank_crtc()"Jani Nikula
This reverts commit d930ffa5d6e8867a290db9c6aad1c62731aeb2c3. According to Thomas, commit d930ffa5d6e8 ("drm/gma500: use drm_crtc_vblank_crtc()") breaks the driver with a NULL-ptr oops on startup. This is because the IRQ initialization in gma_irq_install() now uses CRTCs that are only allocated later in psb_modeset_init(). Stack trace is below. Revert. Go back to the drawing board. [ 65.831766] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000021: 0000 [#1] SMP KASAN NOPTI [ 65.832114] KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] [ 65.832232] CPU: 1 UID: 0 PID: 296 Comm: (udev-worker) Tainted: G E 6.19.0-rc6-1-default+ #4622 PREEMPT(voluntary) [ 65.832376] Tainted: [E]=UNSIGNED_MODULE [ 65.832448] Hardware name: /DN2800MT, BIOS MTCDT10N.86A.0164.2012.1213.1024 12/13/2012 [ 65.832543] RIP: 0010:drm_crtc_vblank_crtc+0x24/0xd0 [ 65.832652] Code: 90 90 90 90 90 90 0f 1f 44 00 00 48 89 f8 48 81 c7 18 01 00 00 48 83 ec 10 48 ba 00 00 00 00 00 fc ff df 48 89 f9 48 c1 e9 03 <0f> b6 14 11 84 d2 74 05 80 fa 03 7e 58 48 89 c6 8b 90 18 01 00 00 [ 65.832820] RSP: 0018:ffff88800c8f7688 EFLAGS: 00010006 [ 65.832919] RAX: fffffffffffffff0 RBX: ffff88800fff4928 RCX: 0000000000000021 [ 65.833011] RDX: dffffc0000000000 RSI: ffffc90000978130 RDI: 0000000000000108 [ 65.833107] RBP: ffffed1001ffea03 R08: 0000000000000000 R09: ffffed100191eec7 [ 65.833199] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8880014480c8 [ 65.833289] R13: dffffc0000000000 R14: fffffffffffffff0 R15: ffff88800fff4000 [ 65.833380] FS: 00007fe53d4d5d80(0000) GS:ffff888148dd8000(0000) knlGS:0000000000000000 [ 65.833488] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 65.833575] CR2: 00007fac707420b8 CR3: 000000000ebd1000 CR4: 00000000000006f0 [ 65.833668] Call Trace: [ 65.833735] <TASK> [ 65.833808] gma_irq_preinstall+0x190/0x3e0 [gma500_gfx] [ 65.834054] gma_irq_install+0xb2/0x240 [gma500_gfx] [ 65.834282] psb_driver_load+0x7b2/0x1090 [gma500_gfx] [ 65.834516] ? __pfx_psb_driver_load+0x10/0x10 [gma500_gfx] [ 65.834726] ? ksize+0x1d/0x40 [ 65.834817] ? drmm_add_final_kfree+0x3b/0xb0 [ 65.834935] ? __pfx_psb_pci_probe+0x10/0x10 [gma500_gfx] [ 65.835164] psb_pci_probe+0xc8/0x150 [gma500_gfx] [ 65.835384] local_pci_probe+0xd5/0x190 [ 65.835492] pci_call_probe+0x167/0x4b0 [ 65.835594] ? __pfx_pci_call_probe+0x10/0x10 [ 65.835693] ? local_clock+0x11/0x30 [ 65.835808] ? __pfx___driver_attach+0x10/0x10 [ 65.835915] ? do_raw_spin_unlock+0x55/0x230 [ 65.836014] ? pci_match_device+0x303/0x790 [ 65.836124] ? pci_match_device+0x386/0x790 [ 65.836226] ? __pfx_pci_assign_irq+0x10/0x10 [ 65.836320] ? kernfs_create_link+0x16a/0x230 [ 65.836418] ? do_raw_spin_unlock+0x55/0x230 [ 65.836526] ? __pfx___driver_attach+0x10/0x10 [ 65.836626] pci_device_probe+0x175/0x2c0 [ 65.836735] call_driver_probe+0x64/0x1e0 [ 65.836842] really_probe+0x194/0x740 [ 65.836951] ? __pfx___driver_attach+0x10/0x10 [ 65.837053] __driver_probe_device+0x18c/0x3a0 [ 65.837163] ? __pfx___driver_attach+0x10/0x10 [ 65.837262] driver_probe_device+0x4a/0x120 [ 65.837369] __driver_attach+0x19c/0x550 [ 65.837474] ? __pfx___driver_attach+0x10/0x10 [ 65.837575] bus_for_each_dev+0xe6/0x150 [ 65.837669] ? local_clock+0x11/0x30 [ 65.837770] ? __pfx_bus_for_each_dev+0x10/0x10 [ 65.837891] bus_add_driver+0x2af/0x4f0 [ 65.838000] ? __pfx_psb_init+0x10/0x10 [gma500_gfx] [ 65.838236] driver_register+0x19f/0x3a0 [ 65.838342] ? rcu_is_watching+0x11/0xb0 [ 65.838446] do_one_initcall+0xb5/0x3a0 [ 65.838546] ? __pfx_do_one_initcall+0x10/0x10 [ 65.838644] ? __kasan_slab_alloc+0x2c/0x70 [ 65.838741] ? rcu_is_watching+0x11/0xb0 [ 65.838837] ? __kmalloc_cache_noprof+0x3e8/0x6e0 [ 65.838937] ? klp_module_coming+0x1a0/0x2e0 [ 65.839033] ? do_init_module+0x85/0x7f0 [ 65.839126] ? kasan_unpoison+0x40/0x70 [ 65.839230] do_init_module+0x26e/0x7f0 [ 65.839341] ? __pfx_do_init_module+0x10/0x10 [ 65.839450] init_module_from_file+0x13f/0x160 [ 65.839549] ? __pfx_init_module_from_file+0x10/0x10 [ 65.839651] ? __lock_acquire+0x578/0xae0 [ 65.839791] ? do_raw_spin_unlock+0x55/0x230 [ 65.839886] ? idempotent_init_module+0x585/0x720 [ 65.839993] idempotent_init_module+0x1ff/0x720 [ 65.840097] ? __pfx_cred_has_capability.isra.0+0x10/0x10 [ 65.840211] ? __pfx_idempotent_init_module+0x10/0x10 Reported-by: Thomas Zimmermann <tzimmermann@suse.de> Closes: https://lore.kernel.org/r/5aec1964-072c-4335-8f37-35e6efb4910e@suse.de Fixes: d930ffa5d6e8 ("drm/gma500: use drm_crtc_vblank_crtc()") Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patch.msgid.link/20260130151319.31264-1-jani.nikula@intel.com
2026-02-02drm/i915/psr: Use TRANS_PUSH to trigger frame change eventJouni Högander
Now we have everything in place for triggering PSR "frame change" event using TRANS_PUSH: use TRANS_PUSH for LunarLake and onwards. v4: - Added call to intel_vrr_psr_frame_change_enable call - added setting LNL_TRANS_PUSH_PSR_PR_EN into intel_vrr_send_push v3: use HAS_PSR_FRAME_CHANGE macro v2: use AND instead of OR in intel_psr_use_trans_push Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260127124120.1069026-12-jouni.hogander@intel.com
2026-02-02drm/i915/display: Add HAS_PSR_TRANS_PUSH_FRAME_CHANGE macroJouni Högander
Add a macro indicating that the platform supports triggering a Frame Change event for the PSR HW using the TRANS PUSH mechanism. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260127124120.1069026-11-jouni.hogander@intel.com
2026-02-02drm/i915/psr: Do PSR exit on frontbuffer flush on LunarLake and onwardsJouni Högander
We need to use intel_psr_exit in frontbuffer flush on LunarLake and onwards if we want to move using trans push mechanism to trigger Frame Change event. Keep PSR1 and PSR2 HW tracking as it is for older platforms as this was seen causing problems there. v2: typo fixed Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260127124120.1069026-10-jouni.hogander@intel.com
2026-02-02drm/i915/psr: Wait for idle only after possible send pushJouni Högander
We are planning to move using trans push mechanism to trigger the Frame Change event. In that case we can't wait PSR to idle before send push happens. Due to this move wait for idle to be done after possible send push is done. This should be ok for Frame Change event triggered by register write as well. Wait for idle is needed only for corner case where PSR is transitioning into DEEP_SLEEP when Frame Change event is triggered. It just has to be before wait for vblank. Otherwise we may have vblank before PSR enters DEEP_SLEEP and still using old frame buffers for first frame after wake up. v2: some typos fixed Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260127124120.1069026-9-jouni.hogander@intel.com
2026-02-02drm/i915/display: Wait for vblank in case of PSR is using trans pushJouni Högander
In case PSR uses trans push as a "frame change" event and we need to wait vblank after triggering PSR "frame change" event. Otherwise we may miss selective updates. DSB skips all waits while PSR is active. Check push send is skipped as well because trans push send bit is not reset by the HW if VRR is not enabled -> we may start configuring new selective update while previous is not complete. Avoid this by waiting for vblank after sending trans push. v2: some typos fixed Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260127124120.1069026-8-jouni.hogander@intel.com
2026-02-02drm/i915/dsb: Set DSB_SKIP_WAITS_EN chicken bit for LunarLake and onwardsJouni Högander
On LunarLake we are using TRANS_PUSH mechanism to trigger "Frame Change" event. This way we have more control on when PSR HW is woken up. I.e. not every display register write is triggering sending update. This allows us setting DSB_SKIP_WAITS_EN chicken bit as well. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260127124120.1069026-7-jouni.hogander@intel.com
2026-02-02drm/i915/vrr: Prepare to Use TRANS_PUSH mechanism for PSR frame changeJouni Högander
On Lunarlake and onward it is possible to generate PSR Frame Change event using TRANS_PUSH mechanism: Ensure push is performed on flip if needed by PSR. Don't use intel_psr_trigger_frame_change_event if PSR uses trans push as Frame Change event: When not using trans push to generate Frame Change event plane/pipe register writes are triggering the event. This is causing problems when transiting to PSR active/idle and the event is coming in. To tackle this we are waiting PSR to idle and using intel_psr_trigger_frame_change_event to ensure PSR exit. If the Frame change event is triggered after everything is configured (on trans push) we don't need to worry about all this. Ensure possible intel_vrr_tg_disable call is not overwriting LNL_TRANS_PUSH_PSR_PR_EN. v8: - split adding intel_vrr_psr_frame_change_enable as a separate change - update commit message v7: - HAS_PSR_FRAME_CHANGE macro moved to separate patch and renamed as HAS_PSR_TRANS_PUSH_FRAME_CHANGE - use intel_psr_use_trans_push instead of HAS_PSR_FRAME_CHANGE in intel_psr_trigger_frame_change - moved calling intel_vrr_psr_frame_change_enable away from this patch v6: - add HAS_PSR_FRAME_CHANGE macro - use TRANS_PUSH in instead of TRAN_VRR_CTL v5: use intel_psr_use_trans_push for intel_vrr_psr_frame_change_enable v4: - use rmw when enabling/disabling transcoder - set TRANS_PUSH_EN conditionally in intel_vrr_send_push - do not call intel_vrr_send_push from intel_psr_trigger_frame_change - do not enable using TRANS_PUSH mechanism for PSR "Frame Change" v3: - use rmw when enabling/disabling - keep LNL_TRANS_PUSH_PSR_PR_EN set always on LunarLake and onwards v2: use intel_vrr_trans_push_enabled_set_clear instead of rmw Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260127124120.1069026-6-jouni.hogander@intel.com
2026-02-02drm/i915/vrr: Add helper for PSR to enable Frame Change event on trans pushJouni Högander
Add new helper to enable PSR Frame Change event generation using trans push mechanism. This helper is to be used by PSR code on PSR enable. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260127124120.1069026-5-jouni.hogander@intel.com
2026-02-02drm/i915/vrr: Add helper for parsing value to be written into TRANS_PUSHJouni Högander
On Lunarlake and onwards it is possible to generate PSR "frame change" event using TRANS_PUSH mechanism. As a preparation add new helper to parse value to be written into TRANS_PUSH register. Setting LNL_TRANS_PUSH_PSR_PR_EN is done in upcoming change. Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260127124120.1069026-4-jouni.hogander@intel.com
2026-02-02drm/i915/psr: Add intel_psr_use_trans_push to query if TRANS_PUSH is usedJouni Högander
This is a preparation to start using trans push as a PSR "Frame Change" event. It adds intel_psr_use_trans_push placeholder which return false for now until we have everything in place. v2: - modify commit message - add TODO Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260127124120.1069026-3-jouni.hogander@intel.com
2026-02-02drm/i915/psr: Add TRANS_PUSH register bit definition for PSRJouni Högander
Add TRANS_PUSH register bit LNL_TRANS_PUSH_PSR_PR_EN definition for PSR usage. v2: add bspec reference Bspec: 69984 Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260127124120.1069026-2-jouni.hogander@intel.com
2026-02-02Merge tag 'exynos-drm-next-for-v6.20' of ↵Dave Airlie
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next Fix three regressions . Fix a regression where vidi_connection_ioctl() used the wrong device to look up the vidi context. It stores the vidi device in exynos_drm_private and uses it in ioctl(), preventing invalid pointer access and related bugs. . Fix a security regression where vidi_connection_ioctl() directly dereferenced a user pointer for EDID data. It copies EDID from user space with copy_from_user() into kernel memory before use, preventing arbitrary kernel memory access. . Fix a concurrency regression where vidi_context members related to EDID memory were accessed without locking. It protects alloc/free and state updates with ctx->lock, preventing race conditions and use-after-free bugs. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Inki Dae <inki.dae@samsung.com> Link: https://patch.msgid.link/20260201143939.27074-1-inki.dae@samsung.com
2026-02-01Revert "drm/nouveau/disp: Set drm_mode_config_funcs.atomic_(check|commit)"John Ogness
This reverts commit 604826acb3f53c6648a7ee99a3914ead680ab7fb. Apparently there is more to supporting atomic modesetting than providing atomic_(check|commit) callbacks. Before this revert: WARNING: [] drivers/gpu/drm/drm_plane.c:389 at .__drm_universal_plane_init+0x13c/0x794 [drm], CPU#1: modprobe/1790 BUG: Kernel NULL pointer dereference on read at 0x00000000 .drm_atomic_get_plane_state+0xd4/0x210 [drm] (unreliable) .drm_client_modeset_commit_atomic+0xf8/0x338 [drm] .drm_client_modeset_commit_locked+0x80/0x260 [drm] .drm_client_modeset_commit+0x40/0x7c [drm] .__drm_fb_helper_restore_fbdev_mode_unlocked.part.0+0xfc/0x108 [drm_kms_helper] .drm_fb_helper_set_par+0x8c/0xb8 [drm_kms_helper] .fbcon_init+0x31c/0x618 [...] .__drm_fb_helper_initial_config_and_unlock+0x474/0x7f4 [drm_kms_helper] .drm_fbdev_client_hotplug+0xb0/0x120 [drm_client_lib] .drm_client_register+0x88/0xe4 [drm] .drm_fbdev_client_setup+0x12c/0x19b4 [drm_client_lib] .drm_client_setup+0x15c/0x18c [drm_client_lib] .nouveau_drm_probe+0x19c/0x268 [nouveau] Fixes: 604826acb3f5 ("drm/nouveau/disp: Set drm_mode_config_funcs.atomic_(check|commit)") Reported-by: John Ogness <john.ogness@linutronix.de> Closes: https://lore.kernel.org/lkml/87ldhf1prw.fsf@jogness.linutronix.de Signed-off-by: John Ogness <john.ogness@linutronix.de> Tested-by: Daniel Palmer <daniel@thingy.jp> Link: https://patch.msgid.link/20260130113230.2311221-1-john.ogness@linutronix.de Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-02-02Merge tag 'amd-drm-next-6.20-2026-01-30' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.20-2026-01-30: amdgpu: - Misc cleanups - SMU 13 fixes - SMU 14 fixes - GPUVM fault filter fix - USB4 fixes - DC FP guard fixes - Powergating fix - JPEG ring reset fix - RAS fixes - Xclk fix for soc21 APUs - Fix COND_EXEC handling for GC 11 - UserQ fixes - MQD size alignment fixes - SMU feature interface cleanup - GC 10-12 KGQ init fixes - GC 11-12 KGQ reset fixes amdkfd: - Fix device snapshot reporting - GC 12.1 trap handler fixes - MQD size alignment fixes Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20260130183257.28879-1-alexander.deucher@amd.com
2026-02-01drm/exynos: vidi: use ctx->lock to protect struct vidi_context member ↵Jeongjun Park
variables related to memory alloc/free Exynos Virtual Display driver performs memory alloc/free operations without lock protection, which easily causes concurrency problem. For example, use-after-free can occur in race scenario like this: ``` CPU0 CPU1 CPU2 ---- ---- ---- vidi_connection_ioctl() if (vidi->connection) // true drm_edid = drm_edid_alloc(); // alloc drm_edid ... ctx->raw_edid = drm_edid; ... drm_mode_getconnector() drm_helper_probe_single_connector_modes() vidi_get_modes() if (ctx->raw_edid) // true drm_edid_dup(ctx->raw_edid); if (!drm_edid) // false ... vidi_connection_ioctl() if (vidi->connection) // false drm_edid_free(ctx->raw_edid); // free drm_edid ... drm_edid_alloc(drm_edid->edid) kmemdup(edid); // UAF!! ... ``` To prevent these vulns, at least in vidi_context, member variables related to memory alloc/free should be protected with ctx->lock. Cc: <stable@vger.kernel.org> Signed-off-by: Jeongjun Park <aha310510@gmail.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2026-02-01drm/exynos: vidi: fix to avoid directly dereferencing user pointerJeongjun Park
In vidi_connection_ioctl(), vidi->edid(user pointer) is directly dereferenced in the kernel. This allows arbitrary kernel memory access from the user space, so instead of directly accessing the user pointer in the kernel, we should modify it to copy edid to kernel memory using copy_from_user() and use it. Cc: <stable@vger.kernel.org> Signed-off-by: Jeongjun Park <aha310510@gmail.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2026-02-01drm/exynos: vidi: use priv->vidi_dev for ctx lookup in vidi_connection_ioctl()Jeongjun Park
vidi_connection_ioctl() retrieves the driver_data from drm_dev->dev to obtain a struct vidi_context pointer. However, drm_dev->dev is the exynos-drm master device, and the driver_data contained therein is not the vidi component device, but a completely different device. This can lead to various bugs, ranging from null pointer dereferences and garbage value accesses to, in unlucky cases, out-of-bounds errors, use-after-free errors, and more. To resolve this issue, we need to store/delete the vidi device pointer in exynos_drm_private->vidi_dev during bind/unbind, and then read this exynos_drm_private->vidi_dev within ioctl() to obtain the correct struct vidi_context pointer. Cc: <stable@vger.kernel.org> Signed-off-by: Jeongjun Park <aha310510@gmail.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2026-01-31kernel.h: drop STACK_MAGIC macroYury Norov
Patch series "Unload linux/kernel.h", v5. kernel.h hosts declarations that can be placed better. This series decouples kernel.h with some explicit and implicit dependencies; also, moves tracing functionality to a new independent header. This patch (of 6): The macro was introduced in 1994, v1.0.4, for stacks protection. Since that, people found better ways to protect stacks, and now the macro is only used by i915 selftests. Move it to a local header and drop from the kernel.h. Link: https://lkml.kernel.org/r/20260116042510.241009-1-ynorov@nvidia.com Link: https://lkml.kernel.org/r/20260116042510.241009-2-ynorov@nvidia.com Signed-off-by: Yury Norov <ynorov@nvidia.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org> Reviewed-by: Aaron Tomlin <atomlin@atomlin.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Petr Pavlu <petr.pavlu@suse.com> Cc: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2026-01-31Merge branch 'mm-hotfixes-stable' into mm-nonmm-stable to pick up changesAndrew Morton
required to merge "kho: use unsigned long for nr_pages".
2026-01-30Merge tag 'rust-fixes-6.19' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux Pull Rust fixes from Miguel Ojeda: "Toolchain and infrastructure: - Trigger rebuilds of the newly added 'proc-macro2' crate (and its dependencies) when the Rust compiler version changes - Fix error in '.rsi' targets (macro expanding single targets) under 'O=' pointing to an external (not subdir) folder - Fix off-by-one line number in 'rustdoc' KUnit tests - Add '-fdiagnostics-show-context' to GCC flags skipped by 'bindgen' - Clean objtool warning by adding one more 'noreturn' function - Clean 'libpin_init_internal.{so,dylib}' in 'mrproper' 'kernel' crate: - Fix build error when using expressions in formatting arguments - Mark 'num::Bounded::__new()' as unsafe and clean documentation accordingly - Always inline functions using 'build_assert' with arguments - Fix 'rusttest' build error providing the right 'isize_atomic_repr' type for the host 'macros' crate: - Fix 'rusttest' build error by ignoring example rust-analyzer: - Remove assertion that was not true for distributions like NixOS - Add missing dependency edges and fix editions for 'quote' and sysroot crates to provide correct IDE support DRM Tyr: - Fix build error by adding missing dependency on 'CONFIG_COMMON_CLK' Plus clean a few typos in docs and comments" * tag 'rust-fixes-6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: (28 commits) rust: num: bounded: clean __new documentation and comments scripts: generate_rust_analyzer: fix resolution of #[pin_data] macros drm/tyr: depend on `COMMON_CLK` to fix build error rust: sync: atomic: Provide stub for `rusttest` 32-bit hosts kbuild: rust: clean libpin_init_internal in mrproper rust: proc-macro2: rebuild if the version text changes rust: num: bounded: add missing comment for always inlined function rust: sync: refcount: always inline functions using build_assert with arguments rust: bits: always inline functions using build_assert with arguments scripts: generate_rust_analyzer: compile sysroot with correct edition scripts: generate_rust_analyzer: compile quote with correct edition scripts: generate_rust_analyzer: quote: treat `core` and `std` as dependencies scripts: generate_rust_analyzer: syn: treat `std` as a dependency scripts: generate_rust_analyzer: remove sysroot assertion rust: kbuild: give `--config-path` to `rustfmt` in `.rsi` target scripts: generate_rust_analyzer: Add pin_init_internal deps scripts: generate_rust_analyzer: Add pin_init -> compiler_builtins dep scripts: generate_rust_analyzer: Add compiler_builtins -> core dep rust: macros: ignore example with module parameters rust: num: bounded: mark __new as unsafe ...
2026-01-31drm/radeon: Make MSI address limit based on the device DMA limitVivian Wang
The radeon driver restricts the MSI message address for devices older than the BONAIR generation to 32-bit MSI addresses due to the former restrictions of the PCI/MSI code which only allowed either 32-bit or full 64-bit address range. This does not work on platforms which have a MSI doorbell address above the 32-bit boundary but do not support the full 64 bit address range. The PCI/MSI core converted this binary decision to a DMA_BIT_MASK() based decision, which allows to describe the device limitations precisely. Convert the driver to provide the exact DMA address limitations to the PCI/MSI core. That allows devices which do not support the full 64-bit address space to work on platforms which have a MSI doorbell address above the 32-bit limit as long as it is within the hardware's addressable range. [ tglx: Massage changelog ] Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patch.msgid.link/20260129-pci-msi-addr-mask-v4-3-70da998f2750@iscas.ac.cn
2026-01-31PCI/MSI: Convert the boolean no_64bit_msi flag to a DMA address maskVivian Wang
Some PCI devices have PCI_MSI_FLAGS_64BIT in the MSI capability, but implement less than 64 address bits. This breaks on platforms where such a device is assigned an MSI address higher than what's supported. Currently, no_64bit_msi bit is set for these devices, meaning that only 32-bit MSI addresses are allowed for them. However, on some platforms the MSI doorbell address is above the 32-bit limit but within the addressable range of the device. As a first step to enable MSI on those combinations of devices and platforms, convert the boolean no_64bit_msi flag to a DMA mask and fixup the affected usage sites: - no_64bit_msi = 1 -> msi_addr_mask = DMA_BIT_MASK(32) - no_64bit_msi = 0 -> msi_addr_mask = DMA_BIT_MASK(64) - if (no_64bit_msi) -> if (msi_addr_mask < DMA_BIT_MASK(64)) Since no values other than DMA_BIT_MASK(32) and DMA_BIT_MASK(64) are used, this is functionally equivalent. This prepares for changing the binary decision between 32 and 64 bit to a DMA mask based decision which allows to support systems which have a DMA address space less than 64bit but a MSI doorbell address above the 32-bit limit. [ tglx: Massaged changelog ] Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Brett Creeley <brett.creeley@amd.com> # ionic Reviewed-by: Thomas Gleixner <tglx@kernel.org> Acked-by: Takashi Iwai <tiwai@suse.de> # sound Link: https://patch.msgid.link/20260129-pci-msi-addr-mask-v4-1-70da998f2750@iscas.ac.cn
2026-01-30drm/xe/pf: Fix typo in function kernel-docMichal Wajdeczko
The function name is missing an underscore, which results in: Warning: ../drivers/gpu/drm/xe/xe_gt_sriov_pf_control.c:1261 This comment starts with '/**', but isn't a kernel-doc comment. Refer to Documentation/doc-guide/kernel-doc.rst * xe_gt_sriov_pf_control_trigger restore_vf() - Start ... Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Shuicheng Lin <shuicheng.lin@intel.com> Link: https://patch.msgid.link/20251217150702.2669-1-michal.wajdeczko@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-01-30drm/panel-edp: Add CMN N116BCL-EAK (C2)Cong Yang
Add support for the CMN N116BCL-EAK (C2) panel, pleace the EDID here for subsequent reference. edid-decode (hex): 00 ff ff ff ff ff ff 00 0d ae 7a 11 00 00 00 00 08 22 01 04 95 1a 0e 78 03 46 a5 9c 5b 53 8b 24 1d 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 e6 1e 56 e2 50 00 3c 30 30 20 a6 00 00 90 10 00 00 1a 00 00 00 fd 00 28 3c 32 32 08 01 0a 20 20 20 20 20 20 00 00 00 fe 00 43 4d 4e 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe 00 4e 31 31 36 42 43 4c 2d 45 41 4b 0a 20 01 80 70 20 79 02 00 25 01 09 fc 34 01 fc 34 01 28 3c 80 81 00 10 72 1a 00 00 03 01 28 3c 00 00 00 00 00 00 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2f 90 Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20260130030456.2080748-1-yangcong5@huaqin.corp-partner.google.com
2026-01-30drm/bridge: dw-hdmi-qp: Rework Audio InfoFrame handlerCristian Ciocaltea
Make use of the recently introduced dw_hdmi_qp_write_infoframe() helper to simplify the writing of the Audio InfoFrame packet header and body registers. Additionally, discard the redundant static values identifying the frame version and length. Moreover, since now having dedicated callbacks per InfoFrame type, move the implementation to dw_hdmi_qp_bridge_write_audio_infoframe() and drop dw_hdmi_qp_config_audio_infoframe(). Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Daniel Stone <daniels@collabora.com> Link: https://patch.msgid.link/20260129-dw-hdmi-qp-iframe-v2-5-0157ad05232c@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2026-01-30drm/bridge: dw-hdmi-qp: Rework DRM InfoFrame handlerCristian Ciocaltea
Make use of the recently introduced dw_hdmi_qp_write_infoframe() helper to simplify the writing of the Dynamic Range and Mastering (DRM) InfoFrame packet header and body registers. Moreover, since now having dedicated callbacks per InfoFrame type, move the implementation to dw_hdmi_qp_bridge_write_hdr_drm_infoframe() and drop dw_hdmi_qp_config_drm_infoframe(). While at it, also discard the unnecessary infoframe size verification, as well as the redundant disabling of the packet transmission (already done by the explicit call to the clear callback). Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Daniel Stone <daniels@collabora.com> Link: https://patch.msgid.link/20260129-dw-hdmi-qp-iframe-v2-4-0157ad05232c@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2026-01-30drm/bridge: dw-hdmi-qp: Rework AVI InfoFrame handlerCristian Ciocaltea
Make use of the recently introduced dw_hdmi_qp_write_infoframe() helper to simplify the writing of the Auxiliary Video InfoFrame (AVI) packet header and body registers. Moreover, since now having dedicated callbacks per InfoFrame type, move the implementation to dw_hdmi_qp_bridge_write_avi_infoframe() and drop dw_hdmi_qp_config_avi_infoframe(). While at it, also discard the superfluous infoframe size verification. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Daniel Stone <daniels@collabora.com> Link: https://patch.msgid.link/20260129-dw-hdmi-qp-iframe-v2-3-0157ad05232c@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2026-01-30drm/bridge: dw-hdmi-qp: Provide SPD InfoFrameCristian Ciocaltea
The hardware is capable of sending Source Product Description (SPD) InfoFrames, hence enable the missing support. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Daniel Stone <daniels@collabora.com> Link: https://patch.msgid.link/20260129-dw-hdmi-qp-iframe-v2-2-0157ad05232c@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2026-01-30drm/bridge: dw-hdmi-qp: Provide HDMI Vendor Specific InfoFrameCristian Ciocaltea
Since commit b626b1a1c9cc ("drm/bridge: refactor HDMI InfoFrame callbacks"), the following warning is generated: [ 13.654149] rockchip-drm display-subsystem: [drm] HDMI VSI not supported Add the missing support for sending HDMI Vendor-Specific Infoframes. Additionally, introduce dw_hdmi_qp_write_{pkt|infoframe}() helpers, as a prerequisite to rework all dw_hdmi_qp_bridge_write_*_infoframe() callbacks and get rid of some boilerplate code. Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Daniel Stone <daniels@collabora.com> Link: https://patch.msgid.link/20260129-dw-hdmi-qp-iframe-v2-1-0157ad05232c@collabora.com Signed-off-by: Daniel Stone <daniels@collabora.com>
2026-01-30drm/i915: move intel_gvt_init() level higherMichał Grzelak
Both initialisation and removal of GVT happen at different abstraction levels. Hence caller of i915_driver_hw_probe() has no way of knowing status of intel_gvt_init(). This can lead to an unbalanced number of calls of intel_gvt_init() and intel_gvt_driver_remove() since GVT error path is currently handled in i915_driver_probe(). One such scenario has been seen with i915_driver_hw_probe() fault injection, which caused double entry deletion and list corruption. Move intel_gvt_init() up to i915_driver_probe(). Add out_cleanup_gvt error path for removing gvt. Trigger it only after intel_gvt_init() succeeded. In case intel_gvt_init() failed, theoretically we should follow err_msi error path. That is actually impossible since call to intel_gvt_init() unconditionally returns 0, although it claims to return negative error code on failure. Thus follow standard out_cleanup_hw error path on a hypothetical future intel_gvt_init() failure. Remove err_msi label from i915_driver_hw_probe() since intel_gvt_init() was the only user of it. Changelog: v1->v2 - don't move err_msi error path from i915_driver_hw_probe (Jani) - rewrite commit message Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15481 Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patch.msgid.link/20260129090129.2601661-2-michal.grzelak@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-01-29Merge tag 'drm-fixes-2026-01-30' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds
Pull drm fixes from Dave Airlie: "Seems to be a bit quieter this week, mostly xe and amdgpu, with msm and imx fixes and one WARN_ON from user blocked. Nothing of note outstanding either. uapi: - Fix a WARN_ON() when passing an invalid handle to drm_gem_change_handle_ioctl() msm: - GPU: - Fix bogus hwcg register update for a690 xe: - Skip address copy for sync-only execs - Fix a WA - Derive mem_copy cap from graphics version - Fix is_bound() pci_dev lifetime - xe nvm cleanup fixes amdgpu: - SMU 13 fixes - SMU 14 fixes - GPUVM fault filter fix - Powergating fix - HDMI debounce fix - Xclk fix for soc21 APUs - Fix COND_EXEC handling for GC 11 - GC 10-12 KGQ init fixes - GC 11-12 KGQ reset fixes imx/tve: - drop ddc device reference when unloading" * tag 'drm-fixes-2026-01-30' of https://gitlab.freedesktop.org/drm/kernel: (21 commits) drm/xe/nvm: Fix double-free on aux add failure drm/xe/nvm: Manage nvm aux cleanup with devres drm/amdgpu/gfx12: adjust KGQ reset sequence drm/amdgpu/gfx11: adjust KGQ reset sequence drm/amdgpu/gfx12: fix wptr reset in KGQ init drm/amdgpu/gfx11: fix wptr reset in KGQ init drm/amdgpu/gfx10: fix wptr reset in KGQ init drm/xe/configfs: Fix is_bound() pci_dev lifetime drm/amdgpu: Fix cond_exec handling in amdgpu_ib_schedule() drm/amdgpu/soc21: fix xclk for APUs drm/amd/display: Clear HDMI HPD pending work only if it is enabled drm/imx/tve: fix probe device leak drm/amd/pm: fix race in power state check before mutex lock drm/amdgpu: fix NULL pointer dereference in amdgpu_gmc_filter_faults_remove drm/amd/pm: fix smu v14 soft clock frequency setting issue drm/amd/pm: fix smu v13 soft clock frequency setting issue drm/xe: derive mem copy capability from graphics version drm/xe/xelp: Fix Wa_18022495364 drm/xe: Skip address copy for sync-only execs drm: Do not allow userspace to trigger kernel warnings in drm_gem_change_handle_ioctl() ...
2026-01-30Merge tag 'drm-xe-next-fixes-2026-01-29' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next - Reduce LRC timestamp stuck message on VFs to notice (Brost) - Disable GuC Power DCC strategy on PTL (Vinay) - Unregister drm device on probe error (Lin) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/aXuyrtsnlAOmj_OB@intel.com
2026-01-30Merge tag 'drm-misc-next-fixes-2026-01-29' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next Two fixes for NULL pointer dereference in imx8 following the bridge refcounting conversions, and one for the bridge connector following the HDMI audio reworks. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <mripard@redhat.com> Link: https://patch.msgid.link/20260129-efficient-jerboa-of-ecstasy-822832@houat
2026-01-30Merge tag 'drm-intel-next-fixes-2026-01-29' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/i915/kernel into drm-next - Prevent u64 underflow in intel_fbc_stolen_end Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patch.msgid.link/aXsWGWjacEJ03rTs@jlahtine-mobl
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-13 21:59:28 +0000