summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-05-26drm/xe: Assign queue name in time for drm_sched_initTvrtko Ursulin
Currently the queue name is only assigned after the drm scheduler instance has been created. This loses information with all logging or debug workqueue facilities so lets re-order things a bit so the name gets assigned in time. To be able to assign a GuC ID early we split the allocation into reservation and publish phases. First, with the submission state lock held, we reserve the ID in the GuC ID manager, which serves as an authoritative source of truth. Then we can drop the lock and reserve entries in the exec queue lookup XArray. This can be lockless since the NULL entries are invisible both to the kernel and userspace. Only after the queue has been fully created we replace the reserved entries with the queue pointer, which can be done locklessly for single width queues. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patch.msgid.link/20260523103418.61832-1-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-05-26drm/panel: fix kernel-doc warning for devm_drm_panel_add()Dongyang Jin
Use the correct kernel-doc notation for struct members to eliminate kernel-doc warnings: Warning: drivers/gpu/drm/drm_panel.c:119 function parameter 'dev' not described in 'devm_drm_panel_add' Warning: drivers/gpu/drm/drm_panel.c:119 function parameter 'dev' not described in 'devm_drm_panel_add' Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202605210648.RI4ufD66-lkp@intel.com/ Signed-off-by: Dongyang Jin <jindongyang@kylinos.cn> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260521094545.3039207-1-jindongyang@kylinos.cn
2026-05-26drm/panel: simple: add NEC NL6448BC33-70CSteffen Trumtrar
Add NEC NL6448BC33-70C 10.4" 640x480 LCD module support. Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260518-v7-1-topic-panel-simple-nl6448bc33-v3-2-21ea14a6e835@pengutronix.de
2026-05-26drm/panel: simple: Add AM-1280800W8TZQW-T00HDario Binacchi
Add Ampire, AM-1280800W8TZQW-T00H 10.1" TFT LCD panel timings. Co-developed-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260515082232.1766586-2-dario.binacchi@amarulasolutions.com
2026-05-26drm/i915: relocate intel_hpd_cancel_work() callJani Nikula
The i915 and xe calls to display, in particular for probe/cleanup/suspend/resume, need to be unified. It does not help to have the related calls scattered around. As a small step forward, relocate the intel_hpd_cancel_work() call from intel_irq_uninstall() to i915_driver_remove(). Note that the other intel_irq_uninstall() call sites don't need the call, as they're on error paths where hotplug hasn't been enabled yet. Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260516101852.1373108-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-05-26drm/bridge: ite-it66121: Select HDMI or DVI mode based on sink typeJavier Martinez Canillas
The driver unconditionally sets the transmission mode to HDMI, which leads to display output not working with DVI monitors. Check the connector's display information sink type to identify the correct mode to configure the bridge. Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260523-it66121-fix-dvi-mode-v5-v5-3-33b4468162f9@redhat.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2026-05-26drm/bridge: ite-it66121: Move .mode_set logic to .atomic_enableJavier Martinez Canillas
Move the existing .mode_set logic to the .atomic_enable callback. The former is deprecated and drivers are supposed to use the latter instead. Also, drop the struct it66121_ctx.connector field because the connector can be accessed through the atomic state and there is no need to store it anymore. Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260523-it66121-fix-dvi-mode-v5-v5-2-33b4468162f9@redhat.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2026-05-26drm/bridge: ite-it66121: Switch to the HDMI connector helpersJavier Martinez Canillas
Instead of open coding the HDMI AVI Infoframes buffer management, use the helpers provided by the HDMI connector framework. Also, add callbacks to implement HDMI Vendor Specific Infoframe and Audio InfoFrame support. The driver was not sending these before, but they are required when using the HDMI helpers. These were implemented following the IT66121 Programming Guide. Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260523-it66121-fix-dvi-mode-v5-v5-1-33b4468162f9@redhat.com Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
2026-05-26drm/i915/psr: Use DC_OFF wake reference to block DC6 on vblank enableJouni Högander
We are observing following warnings: *ERROR* power well DC_off state mismatch (refcount 0/enabled 1) gen9_dc_off_power_well_enabled is considering target state DC_STATE_DISABLE as DC_OFF power well being enabled. Fix this by using wakeref for the purpose. To achieve this we need to modify notification code as well. Currently it is possible that PSR gets notified vblank enable/disable twice on same status. This is currently not a problem as it is just triggering call to intel_display_power_set_target_dc_state with same target state as a parameter. When using wakeref this becomes a problem due to reference counting. Fix this storing vbank status on last notification and use that to ensure there are no more than one notification with same vblank status. v2: ensure there is no subsequent notifications with same status Fixes: aa451abcffb5 ("drm/i915/display: Prevent DC6 while vblank is enabled for Panel Replay") Cc: <stable@vger.kernel.org> # v6.13+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260520104944.239797-2-jouni.hogander@intel.com (cherry picked from commit 35485ac56d878192a3829a58cb26503125ec7104) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2026-05-26drm/i915/psr: Block DC states on vblank enable when Panel Replay supportedJouni Högander
Currently we are blocking DC states only when Panel Replay is enabled on vblank enable. It may happen that Panel Replay is getting enabled when vblank is already enabled. Fix this by blocking DC states always if Panel Replay is supported. While at it take care of possible dual eDP case by looping all encoders supporting PSR. Fixes: 0c427ac78a1d ("drm/i915/psr: Add interface to notify PSR of vblank enable/disable") Cc: <stable@vger.kernel.org> # v6.16+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260520104944.239797-1-jouni.hogander@intel.com (cherry picked from commit eb5911f990554f7ce947dd53df00c114362e4465) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2026-05-26drm/i915/color: Fix HDR pre-CSC LUT programming loopPranay Samala
The integer lut programming loop never executes completely due to incorrect condition (i++ > 130). Fix to properly program 129th+ entries for values > 1.0. Cc: <stable@vger.kernel.org> #v6.19 Fixes: 82caa1c8813f ("drm/i915/color: Program Pre-CSC registers") Signed-off-by: Pranay Samala <pranay.samala@intel.com> Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patch.msgid.link/20260519075308.383877-1-pranay.samala@intel.com (cherry picked from commit f33862ec3e8849ad7c0a3dd46719083b13ade248) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2026-05-26drm/i915/aux: use polling when irqs are unavailableMichał Grzelak
PTL with physically disconnected display was observed to have 40s longer execution time when testing xe_fault_injection@xe_guc_mmio_send_recv. The issue has not been seen when reverting commit 40a9f77a28fa ("Revert "drm/i915/dp: change aux_ctl reg read to polling read""). Apparently the configuration suffers from not having AUX enabled when using interrupts. One probable cause can be xe enabling interrupts too late: interrupts need memory allocations which currently can't be done before the display FB takeover is done. As for now, use polling for AUX in case interrupts are unavailable. Fixes: 40a9f77a28fa ("Revert "drm/i915/dp: change aux_ctl reg read to polling read"") Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Michał Grzelak <michal.grzelak@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patch.msgid.link/20260416163744.288107-1-michal.grzelak@intel.com (cherry picked from commit 05e0550b65cd1604bd515fbc65f522bce4c10a87) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2026-05-26drm/i915: Fix potential UAF in TTM object purgeJanusz Krzysztofik
TLDR: The bo->ttm object might be changed by calling ttm_bo_validate(), move casting it to an i915_tt object later to actually get the right pointer. A user reported hitting the following bug under heavy use on DG2: [26620.095550] Oops: general protection fault, probably for non-canonical address 0xa56b6b6b6b6b6b8b: 0000 1 SMP NOPTI [26620.095556] CPU: 2 UID: 0 PID: 631 Comm: Xorg Not tainted 6.18.8 #1 PREEMPT(lazy) [26620.095558] Hardware name: ASRock B850M Steel Legend WiFi/B850M Steel Legend WiFi, BIOS 3.50 09/18/2025 [26620.095559] RIP: 0010:i915_ttm_purge+0x84/0x100 [i915] [26620.095604] Code: 00 00 00 48 8d 54 24 10 48 89 e6 48 89 fb e8 83 aa ae ff 85 c0 75 6f 48 83 bb a8 01 00 00 00 74 2c 48 8b 45 78 48 85 c0 74 23 <48> 8b 78 20 48 c7 c2 ff ff ff ff 31 f6 e8 7a 73 e3 e0 48 8b 7d 78 [26620.095605] RSP: 0018:ffffc90005fd7430 EFLAGS: 00010282 [26620.095607] RAX: a56b6b6b6b6b6b6b RBX: ffff8881f46c3dc0 RCX: 0000000000000000 [26620.095608] RDX: 0000000000000000 RSI: 0000000000000246 RDI: 00000000ffffffff [26620.095609] RBP: ffff888289610f00 R08: 0000000000000001 R09: ffff88823b022000 [26620.095609] R10: ffff888103029b28 R11: ffff8881fc7f3800 R12: ffff88810b6150d0 [26620.095609] R13: ffff888289610f00 R14: 0000000000000000 R15: ffff8881f46c3dc0 [26620.095610] FS: 00007f1004d86900(0000) GS:ffff88901c858000(0000) knlGS:0000000000000000 [26620.095611] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [26620.095611] CR2: 00007f0fdf489000 CR3: 000000035b0c1000 CR4: 0000000000750ef0 [26620.095612] PKRU: 55555554 [26620.095612] Call Trace: [26620.095615] <TASK> [26620.095615] i915_ttm_move+0x2b9/0x420 [i915] [26620.095642] ? ttm_tt_init+0x65/0x80 [ttm] [26620.095644] ? i915_ttm_tt_create+0xc6/0x150 [i915] [26620.095667] ttm_bo_handle_move_mem+0xb6/0x160 [ttm] [26620.095669] ttm_bo_evict+0x100/0x150 [ttm] [26620.095671] ? preempt_count_add+0x64/0xa0 [26620.095673] ? _raw_spin_lock+0xe/0x30 [26620.095675] ? _raw_spin_unlock+0xd/0x30 [26620.095675] ? i915_gem_object_evictable+0xb7/0xd0 [i915] [26620.095704] ttm_bo_evict_cb+0x6e/0xd0 [ttm] [26620.095705] ttm_lru_walk_for_evict+0xa6/0x200 [ttm] [26620.095708] ttm_bo_alloc_resource+0x185/0x4f0 [ttm] [26620.095709] ? init_object+0x62/0xd0 [26620.095712] ttm_bo_validate+0x7a/0x180 [ttm] [26620.095713] ? _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095714] __i915_ttm_get_pages+0xb0/0x170 [i915] [26620.095737] i915_ttm_get_pages+0x9f/0x150 [i915] [26620.095759] ? i915_gem_do_execbuffer+0xedc/0x2b40 [i915] [26620.095786] ? alloc_debug_processing+0xd0/0x100 [26620.095787] ? _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095788] ? i915_vma_instance+0xa0/0x4e0 [i915] [26620.095822] __i915_gem_object_get_pages+0x2f/0x40 [i915] [26620.095848] i915_vma_pin_ww+0x706/0x980 [i915] [26620.095875] ? i915_gem_do_execbuffer+0xedc/0x2b40 [i915] [26620.095904] eb_validate_vmas+0x170/0xa00 [i915] [26620.095930] i915_gem_do_execbuffer+0x1201/0x2b40 [i915] [26620.095953] ? alloc_debug_processing+0xd0/0x100 [26620.095954] ? _raw_spin_unlock_irqrestore+0x16/0x30 [26620.095955] ? i915_gem_execbuffer2_ioctl+0xc9/0x240 [i915] [26620.095977] ? __wake_up_sync_key+0x32/0x50 [26620.095979] ? i915_gem_execbuffer2_ioctl+0xc9/0x240 [i915] [26620.096001] ? __slab_alloc.isra.0+0x67/0xc0 [26620.096003] i915_gem_execbuffer2_ioctl+0x11a/0x240 [i915] Results from decode_stacktrace.sh pointed to dereference of a file pointer field of a i915 TTM page vector container associated with an object being purged on eviction. That path is taken when the object is marked as no longer needed. Code analysis revealed a possibility of the i915 TTM page vector container being replaced with a new instance inside a function that purges content of the object, should it be still busy. That function is called, indirectly via a more general function that changes the object's placement and caching policy, before the problematic dereference, but still after a pointer to the container is captured, rendering the pointer no longer valid. Fix the issue by capturing the pointer to the container only after its potential replacement. v2: Move the container_of() inside the if block (Sebastian), - a simplified version of the commit description that explains briefly why the change is necessary (Christian). Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/14882 Fixes: 7ae034590ceae ("drm/i915/ttm: add tt shmem backend") Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: stable@vger.kernel.org # v5.17+ Cc: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Sebastian Brzezinka <sebastian.brzezinka@intel.com> Cc: Christian König <christian.koenig@amd.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://lore.kernel.org/r/20260508122612.469227-2-janusz.krzysztofik@linux.intel.com (cherry picked from commit 4462966a93eb185849b7f174f0d0de53476d00a4) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>
2026-05-26drm: verisilicon: fix build failure of cursor plane codeIcenowy Zheng
The cursor plane patch was stalled for a too long time that the struct drm_atomic_state parameter of atomic modeset hooks has been changed to struct drm_atomic_commit. Fix this by replacing the parameter's type. All helpers that retrieve information from this struct are also changed so simply replacing the type works. Fixes: 8c4ae2189125 ("drm: verisilicon: add support for cursor planes") Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260525153618.1336239-1-zhengxingda@iscas.ac.cn
2026-05-26Merge tag 'exynos-drm-next-for-v7.2' of ↵Dave Airlie
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next New feature and cleanup for Exynos fbdev - Move fbdev emulation to DRM client buffers . Reuses standard ADDFB2/GEM paths and simplifies cleanup. - Use DRM format helpers for geometry and size . Applies 4CC-based format/pitch/size calculation with stronger checks and PAGE_SIZE alignment. . Sets screen_size and fix.smem_len from actual allocated size. Exynos DRM internal cleanup - Adopt DRM core DMA tracking and drop redundant code . Removes private DMA tracking, exynos_drm_gem_prime_import(), and obsolete iommu_dma_init_domain() stub. - Reduce duplication and tighten local scope . Replaces MAX_FB_BUFFER with DRM_FORMAT_MAX_PLANES. . Drops redundant exynos_drm_gem.size and internalizes local-only helpers. Bug fix for Exynos fbdev behavior - Fix screen_buffer offset handling . Keeps screen_buffer at framebuffer base and avoids applying scanout offset. . Includes Fixes and stable Cc for backporting. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Inki Dae <inki.dae@samsung.com> Link: https://patch.msgid.link/20260521143624.56906-1-inki.dae@samsung.com
2026-05-26Merge tag 'mediatek-drm-next-20260521' of ↵Dave Airlie
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next Mediatek DRM Next - 20260521 1. hdmi: Convert DRM_ERROR() to drm_err() 2. Simplify mtk_crtc allocation 3. mtk_dpi: Open-code drm_simple_encoder_init() 4. Convert legacy DRM logging to drm_* helpers in mtk_dsi.c 5. dsi: Add compatible for mt8167-dsi Signed-off-by: Dave Airlie <airlied@redhat.com> From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://patch.msgid.link/20260521140841.5103-1-chunkuang.hu@kernel.org
2026-05-26Merge tag 'drm-xe-next-2026-05-21' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/xe/kernel into drm-next Driver Changes: - drm/xe/oa: Fix exec_queue leak on width check in stream open (Shuicheng Lin) - drm/xe/memirq: Drop cached iosys_map for MEMIRQ status (Michal Wajdeczko) - drm/xe/memirq: Drop cached iosys_map for MEMIRQ mask (Michal Wajdeczko) - drm/xe/memirq: Dump all source pages if MSI-X (Michal Wajdeczko) - drm/xe/memirq: Update diagnostic message (Michal Wajdeczko) - drm/xe/memirq: Reduce buffer size (Michal Wajdeczko) - drm/xe/memirq: Use IRQ page from HW engine definition (Michal Wajdeczko) - drm/xe/memirq: Update GuC initialization and IRQ handler (Michal Wajdeczko) - drm/xe/memirq: Make page layout macros private (Michal Wajdeczko) - drm/xe: Add IRQ page to HW engine definition (Michal Wajdeczko) - drm/xe/guc: Use xe_device_is_l2_flush_optimized() (Gustavo Sousa) - drm/xe/multi_queue: Fix secondary queue error case (Niranjana Vishwanathapura) - drm/xe/reg_sr: Do sanity check for MCR vs non-MCR (Gustavo Sousa) - drm/xe/mcr: Extract reg_in_steering_type_ranges() (Gustavo Sousa) - drm/xe/kunit: Use KUNIT_EXPECT_EQ() in xe_wa_gt() (Gustavo Sousa) - drm/xe: Extract xe_hw_engine_setup_reg_lrc() (Gustavo Sousa) - drm/xe: Define and use MCR version of COMMON_SLICE_CHICKEN4 (Gustavo Sousa) - drm/xe: Define and use MCR version of COMMON_SLICE_CHICKEN1 (Gustavo Sousa) - drm/xe: Define CACHE_MODE_1 as MCR register (Gustavo Sousa) - drm/xe/pf: Fix CFI failure in debugfs access (Mohanram Meenakshisundaram) - drm/xe/vf: Fix signature of print functions (Michal Wajdeczko) - drm/xe: Make drm_driver const (Michal Wajdeczko) - drm/xe/display: Drop xe_display_driver_set_hooks() (Michal Wajdeczko) - drm/xe/display: Add macro with display driver features (Michal Wajdeczko) - drm/xe/display: Add macro with display driver ops (Michal Wajdeczko) - drm/xe/display: Prefer forward declarations (Michal Wajdeczko) - drm/xe/display: Drop xe_display_driver_remove() stub (Michal Wajdeczko) - drm/xe: Drop unused drm/drm_atomic_helper.h include (Michal Wajdeczko) - drm/xe/sriov: Mark NVL as SR-IOV capable (Jakub Kolakowski) - drm/xe/gt_idle: Use NSEC_PER_MSEC instead of float literal (Shuicheng Lin) - drm/xe/gsc: Fix double-free of managed BO in error path (Shuicheng Lin) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/ag9RLujZiYYnSc_F@fedora
2026-05-26Merge tag 'drm-misc-next-2026-05-21' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v7.2-rc1: UAPI Changes: - Add VIRTIO_GPU_F_BLOB_ALIGNMENT flag. Cross-subsystem Changes: - Add common TMDS character rate constants to video/hdmi and use those in bridge drivers. Core Changes: - Fix leak in drm_syncobj_find_fence. - Fix OOB reads related to DP-MST. - Create drm_get_bridge_by_endpoint and convert drivers to use it in preparation of hotplug. Driver Changes: - Assorted bugfixes and cleanups to accel/ethosu, imagination, virtio, rockchip. - Expandable device heap support to amdxdna, bridge/chipone-icn6211. - Add Surface Pro 12 panels. - Convert ite-it6211 to use drm hdmi audio helpers. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/f4034e3c-8290-49e1-9410-dc1f449265f4@linux.intel.com
2026-05-25gpu: nova-core: vbios: remove unused rom_header fieldEliot Courtney
This is only used during construction, so we can remove it. Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-22-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25gpu: nova-core: vbios: move constants and functions to be associatedEliot Courtney
Move constants and functions to be inside the impls of the types they are related to. This makes it more obvious what each type and value is for. Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-21-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25gpu: nova-core: vbios: drop redundant TryFrom importEliot Courtney
This is unused. Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-20-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25gpu: nova-core: vbios: drop unused image wrappersEliot Courtney
These are unused currently, and it is probably sufficient to just check the type of BIOS image in the future. Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-19-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25gpu: nova-core: vbios: remove unnecessary fields in PciRomHeaderEliot Courtney
Remove unnecessary fields in PciRomHeader. This allows a simplification to use `FromBytes` instead of reading fields piecemeal. A lot of these checks were redundant as well since it checks the size of the `data` first in `BiosImage`. Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-18-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25gpu: nova-core: vbios: use let-else in Vbios::newEliot Courtney
Improve readability by moving the success path outside of a nested branch. Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-17-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25gpu: nova-core: vbios: use single logical block for the FWSEC sectionEliot Courtney
Currently, FWSEC takes the first image and the last image. Treat the first FWSEC image and all following image data as one logical block for building the final FWSEC image. This avoids explicitly tracking two FWSEC images. Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-16-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25gpu: nova-core: vbios: use the first PCI-AT imageEliot Courtney
Currently, PCI-AT takes the final image if multiple exist. Use the first one instead, to match nouveau behaviour. Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-15-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25gpu: nova-core: vbios: construct `FwSecBiosImage` directly from BIOS imagesEliot Courtney
`FwSecBiosBuilder` now only contains `falcon_ucode_offset` which just gets passed directly into `FwSecBiosImage`. Remove `FwSecBiosBuilder` and construct `FwSecBiosImage` directly, as a simplification. Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-14-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25gpu: nova-core: vbios: store PMU lookup entries in a KVVecEliot Courtney
The current code copies the data into a KVec and parses it on demand. We can simplify the code by storing the parsed entries. Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-13-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25gpu: nova-core: vbios: read PMU lookup entries using FromBytesEliot Courtney
This simplifies the construction of `PmuLookupTableEntry` and is allowed now that the driver can assume it is little endian. Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-12-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25gpu: nova-core: vbios: simplify setup_falcon_dataEliot Courtney
The code first computes `pmu_in_first_fwsec` or adjusts the offset and then uses it in a branch just once to get the correct source for the PMU table. This can be simplified to a single branch while also avoiding the mutation of `offset`. Also, adjust the code after this to keep the success case non-nested. Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-11-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25gpu: nova-core: vbios: compute FWSEC-relative Falcon data offsetEliot Courtney
Push the computation of the falcon data offset into a helper function. The subtraction to create the offset should be checked, and by doing this the check can be folded into the existing check in `falcon_data_ptr`. Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-10-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25gpu: nova-core: vbios: keep PmuLookupTable local in setup_falcon_dataEliot Courtney
This does not need to be stored in `FwSecBiosBuilder` so we can remove it from there, and just create and use it locally in `setup_falcon_data`. Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-9-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25gpu: nova-core: vbios: drop unused falcon_data_offset from FwSecBiosBuilderEliot Courtney
This is unused, so we can remove it. Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-8-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25gpu: nova-core: vbios: use checked accesses in `setup_falcon_data`Eliot Courtney
Use checked arithmetic for `ucode_offset` in `setup_falcon_data`. This prevents a malformed firmware from causing a panic. Fixes: dc70c6ae2441 ("gpu: nova-core: vbios: Add support to look up PMU table in FWSEC") Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-7-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25gpu: nova-core: vbios: use checked access in `FwSecBiosImage::header`Eliot Courtney
Use checked access in `FwSecBiosImage::header` for getting the header version since the value is firmware derived. Fixes: 47c4846e4319 ("gpu: nova-core: vbios: Add support for FWSEC ucode extraction") Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-6-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25gpu: nova-core: vbios: use checked ops and accesses in `FwSecBiosImage::ucode`Eliot Courtney
Use checked arithmetic and access for extracting the microcode since the offsets are firmware derived. Fixes: 47c4846e4319 ("gpu: nova-core: vbios: Add support for FWSEC ucode extraction") Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-5-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25gpu: nova-core: vbios: read BitToken using FromBytesEliot Courtney
If `header.token_size` is smaller than `BitToken`, then we currently can read past the end of `image.base.data`. Use checked arithmetic for computing offsets and simplify reading it in using `FromBytes`. Fixes: dc70c6ae2441 ("gpu: nova-core: vbios: Add support to look up PMU table in FWSEC") Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-4-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25gpu: nova-core: vbios: avoid reading too far in read_more_at_offsetEliot Courtney
Fix bug where `read_more_at_offset` would unnecessarily read more data. This happens when the window to read has some part cached and some part not. It would read `len` bytes instead of just the uncached portion, which could read past `BIOS_MAX_SCAN_LEN`. Fixes: 6fda04e7f0cd ("gpu: nova-core: vbios: Add base support for VBIOS construction and iteration") Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-3-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25gpu: nova-core: vbios: use checked arithmetic for bios image range endEliot Courtney
`read_bios_image_at_offset` is called with a length from the VBIOS header, so we should be more defensive here and use checked arithmetic. Fixes: 6fda04e7f0cd ("gpu: nova-core: vbios: Add base support for VBIOS construction and iteration") Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-2-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25gpu: nova-core: vbios: stop scanning at BIOS_MAX_SCAN_LENEliot Courtney
Current code lets `current_offset` go to `BIOS_MAX_SCAN_LEN` which is one byte too far. Fixes: 6fda04e7f0cd ("gpu: nova-core: vbios: Add base support for VBIOS construction and iteration") Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com> Reviewed-by: John Hubbard <jhubbard@nvidia.com> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260525-fix-vbios-v5-1-e5e455251537@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-05-25drm/i915/dp: Detect changes in common link parametersImre Deak
Detect DPRX capability changes without a long HPD or RX_CAP_CHANGED signal and queue a corresponding link params reset. Besides detecting the above unexpected capability changes, this also avoids races between queuing and handling a deferred link params reset. v2: (Ville) - Query/set intel_dp::reset_link_params instead of using helpers for these. - Assert matching types for old/new common rate elements as well. - Add TODO: for adding a struct tracking both rates and number of rates. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260522160514.2628249-5-imre.deak@intel.com
2026-05-25drm/i915/dp: Cache max common lane countImre Deak
Cache the maximum common lane count together with the common link rates. This is safe because the cached value is updated: - during driver probe, before the connector is registered and can be used for mode validation or modesetting - during resume, before output HW state readout can query it - during connector detection, right after updating the sink/link capabilities Caching the value allows detecting max common lane count changes in a follow-up change and keeps the tracking of max common lane count aligned with that of common rates. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260522160514.2628249-4-imre.deak@intel.com
2026-05-25drm/i915/dp: Add helper to set common link paramsImre Deak
Add intel_dp_set_common_link_params() to prepare for updating the maximum common lane count together with the common rates. Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260522160514.2628249-3-imre.deak@intel.com
2026-05-25drm/i915/dp: Reset link params after a DPRX capability changeImre Deak
There is no reason to distinguish between DPRX capability changes signaled via a long HPD and via an RX_CAP_CHANGED HPD IRQ. Both cases result in reading out the DPRX capabilities and updating the corresponding sink and common capabilities cached in intel_dp, however only the long HPD resets the link training/recovery state and MST link probe parameters correspondingly. The link training/recovery state may contain reduced maximum link rate/lane count values left over from a previous link training failure. Based on the above after an RX_CAP_CHANGED increased the link rate, lane count parameters the maximum link rate/lane count in the link training/recovery state may remain below these, leaving the newly added valid configurations unavailable for subsequent modesets in an inconsistent way. Handle RX_CAP_CHANGED IRQs the same way as long HPDs and reset the link recovery state and MST link probe parameters in that case as well. v2: Set intel_dp::reset_link_params instead of using a helper for this. (Ville). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patch.msgid.link/20260522160514.2628249-2-imre.deak@intel.com
2026-05-25drm/hyperv: validate VMBus packet size in receive callbackBerkant Koc
hyperv_receive_sub() reads msg->vid_hdr.type and dispatches into one of four message-type branches without knowing how many bytes the host wrote into hv->recv_buf. The completion path then runs memcpy(hv->init_buf, msg, VMBUS_MAX_PACKET_SIZE), so the consumer that wakes on wait_for_completion_timeout() can read up to 16 KiB of residue from a prior message as if it were the response payload. Pass bytes_recvd into hyperv_receive_sub() and reject any packet that does not cover the pipe + synthvid header. A single switch on msg->vid_hdr.type then computes the type-specific payload size: the three completion-driving types (SYNTHVID_VERSION_RESPONSE, SYNTHVID_RESOLUTION_RESPONSE, SYNTHVID_VRAM_LOCATION_ACK) fall through to a shared exit that requires that size before memcpy/complete, while SYNTHVID_FEATURE_CHANGE validates its own payload and returns before reading is_dirt_needed. Unknown types are dropped. SYNTHVID_RESOLUTION_RESPONSE is variable length: the host fills resolution_count entries, not the full SYNTHVID_MAX_RESOLUTION_COUNT array. Validate the fixed prefix first so resolution_count can be read, bound it against the array, then require only the count-sized array, so the shorter responses the host actually sends are accepted. Only run the sub-handler when vmbus_recvpacket() returned success. The memcpy length is bytes_recvd, which is bounded by VMBUS_MAX_PACKET_SIZE only on a successful receive; on -ENOBUFS vmbus_recvpacket() instead reports the required length, which can exceed hv->recv_buf, so copying bytes_recvd would read and write past the 16 KiB buffers. Gating on the success return keeps the copy bounded. The nonzero-return path is itself a malformed-message case and is now logged rather than silently skipped; channel recovery is not attempted. Rejected packets are reported via drm_err_ratelimited() rather than silently dropped, matching the CoCo-hardened pattern in hv_kvp_onchannelcallback(). Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video device") Cc: stable@vger.kernel.org # 5.14+ Signed-off-by: Berkant Koc <me@berkoc.com> Assisted-by: Claude:claude-opus-4-7 berkoc-pipeline Reviewed-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Link: https://patch.msgid.link/8200dbc199c7a9b75ac7e8af6c748d2189b5ebd5.1779542874.git.me@berkoc.com
2026-05-25drm/hyperv: validate resolution_count and fix WIN8 fallbackBerkant Koc
A SYNTHVID_RESOLUTION_RESPONSE with resolution_count > 64 walks past the supported_resolution[SYNTHVID_MAX_RESOLUTION_COUNT] array in the parse loop. Bound resolution_count against the array size, folded into the existing zero-check. When the WIN10 resolution probe fails, the caller in hyperv_connect_vsp() left hv->screen_*_max / preferred_* unpopulated, which sets mode_config.max_width / max_height to 0 and makes drm_internal_framebuffer_create() reject every userspace framebuffer with -EINVAL. The pre-WIN10 branch had the same gap for preferred_width / preferred_height. Use a single post-probe fallback guarded by screen_width_max == 0 so both paths converge on the WIN8 defaults. Signed-off-by: Berkant Koc <me@berkoc.com> Assisted-by: Claude:claude-opus-4-7 berkoc-pipeline Fixes: 76c56a5affeb ("drm/hyperv: Add DRM driver for hyperv synthetic video device") Cc: stable@vger.kernel.org # 5.14+ Reviewed-by: Michael Kelley <mhklinux@outlook.com> Tested-by: Michael Kelley <mhklinux@outlook.com> Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Link: https://patch.msgid.link/6945b22419c7d404b4954a113de2ac9c900dba93.1779542874.git.me@berkoc.com
2026-05-25drm/i915/psr: Allow SCL=0 on platforms with always-on VRR TGAnkit Nautiyal
For Legacy timing generator, if there are no panel replay/sel_update or other SRD constraints, the Set context latency (SCL) window should be at least 1. However, for VRR timing generator the SCL window can be 0. It has other guardband constraints, but that are checked during guardband computation. Allow SCL to be 0 for platforms that have VRR TG always on. Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20260517142753.2813959-3-ankit.k.nautiyal@intel.com
2026-05-25drm/i915/psr: Simplify the conditions for SCL computationAnkit Nautiyal
'needs_sel_update' is common for both display version branches, so check it once and keep the version specific checks as separate early returns. v2: Split into separate early returns. (Jani) Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patch.msgid.link/20260517142753.2813959-2-ankit.k.nautiyal@intel.com
2026-05-25drm/i915/display: Handle odd position for planar formats in selective fetchJouni Högander
Since Lunarlake there is no restriction planar planes has to be even positions. Due to this we may end up having odd offset for UV-plane in selective fetch configuration. Add handling for this case into selective fetch configuration. Bspec: 68927 Suggested-by: Vidya Srinivas <vidya.srinivas@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Vidya Srinivas <vidya.srinivas@intel.com> Link: https://patch.msgid.link/20260512080022.2527094-1-jouni.hogander@intel.com
2026-05-25drm/i915/psr: Use DC_OFF wake reference to block DC6 on vblank enableJouni Högander
We are observing following warnings: *ERROR* power well DC_off state mismatch (refcount 0/enabled 1) gen9_dc_off_power_well_enabled is considering target state DC_STATE_DISABLE as DC_OFF power well being enabled. Fix this by using wakeref for the purpose. To achieve this we need to modify notification code as well. Currently it is possible that PSR gets notified vblank enable/disable twice on same status. This is currently not a problem as it is just triggering call to intel_display_power_set_target_dc_state with same target state as a parameter. When using wakeref this becomes a problem due to reference counting. Fix this storing vbank status on last notification and use that to ensure there are no more than one notification with same vblank status. v2: ensure there is no subsequent notifications with same status Fixes: aa451abcffb5 ("drm/i915/display: Prevent DC6 while vblank is enabled for Panel Replay") Cc: <stable@vger.kernel.org> # v6.13+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Michał Grzelak <michal.grzelak@intel.com> Link: https://patch.msgid.link/20260520104944.239797-2-jouni.hogander@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2026-08-10 15:45:52 +0000