summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2026-10-07drm/amdgpu: Add SOC_V1_0_DIE_REV_AID() helperMukul Joshi
Add a helper to extract the AID revision from adev->rev_id, matching the existing SOC_V1_0_DIE_REV_XCD(), and use it instead of open-coded rev_id bit checks for AID A1 in gmc_v12_1 and kfd_svm. Signed-off-by: Mukul Joshi <mukul.joshi@amd.com> Reviewed-by: David Yat Sin <david.yatsin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-10-07drm/xe/i2c: cancel the client work on removeFan Wu
xe_i2c_notifier() stores the DesignWare adapter in i2c->adapter and schedules i2c->work when the adapter is registered under the xe I2C platform device, and xe_i2c_client_work() then instantiates the AMC client device on that adapter. xe_i2c_remove() tears down the AMC, unregisters the client devices, the bus notifier and the adapter platform device, but it never drains i2c->work. A work item that is still queued or running when the adapter is unregistered dereferences i2c->adapter in i2c_new_client_device() after platform_device_unregister() has released the adapter. The work item is also embedded in the devm-allocated struct xe_i2c, so a work item still queued after the drm device devm unwind frees that allocation runs its callback on freed memory. The bus notifier is the only thing that schedules this work, and it is unregistered after the client devices. An instance that is still queued when the teardown runs can therefore write i2c->client[XE_I2C_CLIENT_AMC] while the loop is unregistering and clearing the same array, and an AMC client it instantiates late is only cleaned up by the adapter's own child sweep in i2c_del_adapter(). Move bus_unregister_notifier() in front of the client teardown loop and cancel the work right after it, so no new instance can be scheduled and a queued instance is drained before the client array is touched. A running instance still finds a live adapter, since the adapter is unregistered later. Fixes: f0e53aadd702 ("drm/xe: Support for I2C attached MCUs") Link: https://lore.kernel.org/intel-xe/20260912085932.101598-1-fanwu01@zju.edu.cn/ Cc: stable@vger.kernel.org Assisted-by: LLM, in-house static analysis tool Co-developed-by: Song Li <songl@zju.edu.cn> Signed-off-by: Song Li <songl@zju.edu.cn> Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260928013030.612592-1-fanwu01@zju.edu.cn Link: https://patch.msgid.link/20261006000413.318561-2-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit a23f27d5ec11c3f418c5e5531eea34ccda2b5b20) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-10-07drm/panel-edp: Add Sharp LQ138P1JX61 (Surface Laptop 8th Ed.)Gopikrishna Garmidi
The internal eDP panel of the Microsoft Surface Laptop 13.8" 8th Edition is not in edp_panels[], so panel-edp falls back to conservative timings. EDID, read over the panel's DP AUX DDC bus: 00 ff ff ff ff ff ff 00 4d 10 72 15 a1 31 05 54 31 23 01 04 b5 1d 13 78 03 7d 77 ad 50 46 ad 26 0f 50 53 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 60 b6 00 a0 90 00 2b 60 30 20 3a 00 23 c2 10 00 00 18 60 b6 00 a0 90 00 56 66 30 20 3a 00 23 c2 10 00 00 18 00 00 00 fd 00 18 78 be be 2f 01 00 00 00 00 00 00 00 00 00 00 fc 00 4c 51 31 33 38 50 31 4a 58 36 31 0a 20 01 4e 02 03 0f 00 e3 05 80 00 e6 06 05 01 73 6a 0b 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 aa Manufacturer: SHP Model: 0x1572 Made in: week 49 of 2025 Display Product Name: 'LQ138P1JX61' DTD 1: 2304x1536 120.000329 Hz 3:2 (291 mm x 194 mm) DTD 2: 2304x1536 60.000164 Hz 3:2 (291 mm x 194 mm) No datasheet is available, so use delay_200_500_e200: it keeps the 200 ms enable delay of the conservative fallback, but uses the 500 ms unprepare delay of the real panels in the table. This matches the entry for the closely related Sharp LQ120P1JX51 (SHP 0x15a7). Assisted-by: LLM Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patch.msgid.link/20261006-mahua-surface-laptop-v1-4-406fc042162a@oss.qualcomm.com
2026-10-07Merge tag 'drm-misc-fixes-2026-10-01' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes Multiple patches for vc4 that improve memory safety and leaks, one error handling fix and a wrongful cast fix for th1520-dw-hdmi, one input validation fix and the blend mode property addition for vmwgfx, two locking fixes for drm_bridge, an input validation fix for panthor, an error handling fix for drm_dp_helper, EAGAIN handling fix for drm_fb_helper, and a clock reference leakage fix for aspeed. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <self@mripard.dev> Link: https://patch.msgid.link/ar5wE6ElDrxOfNBL@houat
2026-10-07gpu: nova-core: fsp: use KVec::zeroed() in recv_msg()Thorsten Blum
Use KVec::zeroed() to create the message buffer in recv_msg() instead of creating an empty vector and resizing it. Signed-off-by: Thorsten Blum <blum@kernel.org> Link: https://patch.msgid.link/20261006065437.58408-3-blum@kernel.org [ Avoid the unnecessary turbofish syntax. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-10-06gpu: nova-core: gsp: use KVVec::zeroed() for payload buffersThorsten Blum
Use KVVec::zeroed() instead of KVVec::from_elem() to allocate and zero-initialize the command and continuation payload buffers. Also use KVVec::zeroed() in the test helper read_payload(). Signed-off-by: Thorsten Blum <blum@kernel.org> Link: https://patch.msgid.link/20261006115311.92873-3-blum@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-10-06drm/vc4: Set DRM DMA device directly from HVS and V3DDaniel Drake
vc4 uses of_dma_configure() during bind to set the DMA configuration of the drm device by borrowing the configuration of one of its component devices. This violates driver model expectations that IOMMU probing and domain attachment occur before driver binding - see commit bcb81ac6ae3c ("iommu: Get DT/ACPI parsing into the proper probe path"). With the introduction of the bcm2712-iommu driver behind the vc4 hvs device, a warning is triggered: vc4-drm gpu: late IOMMU probe at driver bind, something fishy here! Instead of configuring the virtual aggregate device, adopt the pattern used by sun4i/sun8i/exynos where candidate DMA-capable hardware components register themselves as the device to use for DRM allocations via drm_dev_set_dma_dev(), provided a DMA device has not already been assigned. HVS will typically bind first and claim the DMA device. The gen6 36-bit DMA mask configuration was moved into vc4_hvs_bind() accordingly. For older generations, vc4's v3d component continues to be available as a fallback, and the default platform bus 32-bit DMA mask is retained. Fixes: da8e393e23ef ("drm/vc4: drv: Adopt the dma configuration from the HVS or V3D component") Signed-off-by: Daniel Drake <dan@reactivated.net> Link: https://patch.msgid.link/20261004-drm-dma-device-2-v3-1-45b121ab819f@reactivated.net Reviewed-by: Maíra Canal <mcanal@igalia.com> Signed-off-by: Maíra Canal <mcanal@igalia.com>
2026-10-06drm/xe/sysctrl: Fix mailbox header handlingMallesh Koujalagi
The mailbox header was defined as __le32, which required cpu_to_le32() and le32_to_cpu() conversions whenever it was write or read. These conversions are unnecessary because the header is always handled as a 32-bit value, not as raw bytes. It is written with xe_mmio_write32() and read with xe_mmio_read32(), which already handle any required byte-order conversion through the underlying writel()/readl() accessors. As a result, the header value is already in CPU byte order when used by the driver. Keeping the extra conversions had no effect on little-endian systems and could cause an incorrect on big-endian systems. So use u32 for the mailbox header and remove the unnecessary endianness conversions. Fixes: 1f95f618182b ("drm/xe/xe_sysctrl: Add System Controller mailbox communication support") Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com> Tested-by: Anoop Vijay <anoop.c.vijay@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Link: https://patch.msgid.link/20260924060900.146167-18-mallesh.koujalagi@intel.com (cherry picked from commit 5137b391599579371c32f555958d3cf55e19bd88) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-10-06drm/i915/gt: Unmask interrupts only when ACTIVE is trueKrzysztof Karas
There is a small race window between intel_rps_boost() reading a stale ACTIVE state and queuing rps->work, where ACTIVE may be changed via asynchronous calls triggered by wakeref drop. This means that rps_work() could be triggered after the GT has been parked, so unmasking RPS PM interrupts would happen without holding PM wakelock. This sequence of events may be observed during live_rc6_ctx_wa() selftest: 1) live_rc6_ctx_wa() -> intel_engine_pm_put() -> wakeref_put() ASYNC1) wakeref_put() callback -> __engine_park() -> intel_gt_pm_put_async() -> intel_gt_pm_put_async_untracked() -> intel_wakeref_put_async() ASYNC2) wakeref_put_async() callback -> __gt_park() -> intel_rps_park() -> intel_rps_clear_active() [clear ACTIVE] WITH INTERRUPTS: -> rps_disable_interrupts() -> cancel_work_sync(rps->work) -> rps_reset_interrupts() [rps->pm_iir = 0] WITHOUT INTERRUPTS (TIMER mode): -> rps_stop_timer() -> cancel_work_sync(rps->work) 2) live_rc6_ctx_wa() -> intel_gt_wait_for_idle() -> intel_gt_retire_requests_timeout() -> dma_fence_wait_timeout() -> ops->wait() [i915_fence_wait()] -> i915_request_wait_timeout() -> intel_rps_boost() -> intel_rps_is_active() [check ACTIVE] [OPEN RACE WINDOW] -> queue_work(rps->work) -> retire_requests() -> i915_request_retire() -> intel_rps_dec_waiters() [from 1 to 0] If ASYNC1 and ASYNC2 would execute during [OPEN RACE WINDOW], then: 3) rps_work() executes from the workqueue and may satisfy "(!pm_iir && !client_boost)" test (in TIMER mode rps->pm_iir is zeroed by an earlier rps_work() call or never gets a new value after previous intel_rps_unpark() event), so it jumps to "out" label, bypassing intel_rps_is_active() guard and executes gen6_gt_pm_unmask_irq(); 4) GT is parked and runtime PM wakelock is dropped, so only a raw reference in __gt_park() -> intel_display_power_put_async() remains for 100ms, then the MMIO write in gen6_gt_pm_unmask_irq() detects missing wakelock via assert_rpm_wakelock_held() and emits "RPM wakelock ref not held during HW access" tainting kernel. Commit 3e7abf814193 ("drm/i915: Extract GT render power state management") dropped the "if (rps->interrupts_enabled)" guard that gen6_pm_rps_work() had around this unmask in i915_irq.c. INTEL_RPS_ACTIVE brackets the same window, since it is set in intel_rps_unpark() before rps_enable_interrupts() and rps_start_timer() and cleared in intel_rps_park() before rps_stop_timer() and rps_disable_interrupts(). Skip unmasking when RPS is no longer active (reaching unmask operation is independent of INTERRUPT mode). This does not prevent RPS operation from resuming on the next unpark. In interrupt mode, intel_rps_unpark() calls rps_enable_interrupts(), which enables and unmasks the PM interrupts. In timer mode, it calls rps_start_timer(), restarting periodic engine-busyness evaluation. The timer generates software RPS events and queues rps_work() directly, independently of PM interrupt delivery. Neither mode requires the late worker to unmask interrupts while the GT is parked Fixes: 3e7abf814193 ("drm/i915: Extract GT render power state management") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/16562 Cc: stable@vger.kernel.org # v5.5+ Assisted-by: GitHub-Copilot:claude-opus-5 Assisted-by: GitHub-Copilot:gpt-6-astra Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patch.msgid.link/20260910081329.3300417-1-krzysztof.karas@intel.com (cherry picked from commit ca4a6deadad15b91ee083afe445fa6bdbfb68206) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-10-06drm/i915/gem: Prevent overstepping exec array boundaryKrzysztof Karas
It is possible for eb_relocate_parse_slow() to call kvfree() on entries outside the original exec array during following scenario inside eb_relocate_parse_slow(): 1) eb_copy_relocations() allocates as many as eb->buffer_count copies for exec entries; 2) eb_parse() appends up to two VMAs, right after incrementing eb->buffer_count; 3) cleanup under "out" label uses this incremented buffer_count to release relocation pointers from exec array via kvfree(), not from VMA array. To amend this problem, ensure that relocation cleanup uses the original exec object count, excluding the VMAs appended by the command parser. Fixes: 8e4ba491b0ba ("drm/i915: Parse command buffer earlier in eb_relocate(slow)") Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com> Assisted-by: GitHub-Copilot:gpt-6-astra Cc: stable@vger.kernel.org # 5.10+ Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patch.msgid.link/20260911061145.3535489-1-krzysztof.karas@intel.com (cherry picked from commit 2a0158925fb943c7ba8f3216e2734952128defc9) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2026-10-06drm/gud: don't keep a connector without a CRTC as connector_stateSajal Gupta
If the 'for_each_new_connector_in_state()' loop finishes without hitting the break, connector_state is left pointing at the last connector visited, which has no CRTC, instead of staying NULL. That skips the "if (!connector_state)" fallback below the loop, which looks up the active connector when the state contains none. The function then carries on with a connector that is not driven. Fix by resetting connector_state to NULL for each connector visited that has no CRTC, so that it is NULL when none was found and the fallback runs. Fixes: 40e1a70b4aed ("drm: Add GUD USB Display driver") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://sashiko.dev/#/patchset/20260902123254.36987-1-sajal2005gupta@gmail.com?part=1 Signed-off-by: Sajal Gupta <sajal2005gupta@gmail.com> Acked-by: Ruben Wauters <rubenru09@aol.com> Cc: <stable@vger.kernel.org> Signed-off-by: Ruben Wauters <rubenru09@aol.com> Link: https://patch.msgid.link/20260922084026.15481-1-sajal2005gupta@gmail.com
2026-10-06drm/sched: document the RCU dependencyChristian König
Tvrtko's patches (506aa8b02a8d "dma-fence: Add safe access helpers and document the rules") added RCU protection to the returned strings from get_timeline_name()/get_driver_name() callbacks of the dma_fence backends. This fixed use after free problems for a couple of drivers, but we never documented the consequences for the drm_sched_fence. Add a few words on the function documentation to note that we need an RCU grace period between signaling the last hardware fence and scheduler teardown. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Philipp Stanner <phasta@kernel.org> Link: https://lore.kernel.org/r/20260914182740.1587-2-christian.koenig@amd.com
2026-10-05drm/xe: Fix stale pinned_link entry when fb-pin performs the final unpinThomas Hellström
xe_bo_pin_external() and xe_bo_unpin_external() maintain the bo's pinned_link list membership in xe->pinned.late.external, based on whether the current call is the outermost pin or the final unpin. However, the same external bo's pin_count can also be raised and lowered directly by __xe_pin_fb_vma()/__xe_unpin_fb_vma(), which pin the bo as a display scanout buffer without going through xe_bo_pin_external()/xe_bo_unpin_external() at all, and have no notion of, or ownership over, pinned_link. If a bo is pinned both externally (e.g. dma-buf export) and as an fb, and the external unpin happens first, xe_bo_unpin_external() correctly observes pin_count > 1 and leaves the bo on pinned_link. When the fb unpin later performs the true last unpin (pin_count 1 -> 0), it never touches pinned_link, leaving the bo linked on xe->pinned.late.external indefinitely. Once the bo is subsequently freed, this stale list entry points into freed memory, corrupting the list and risking a use-after-free the next time the list is walked or spliced. The backup object pin/unpin sites in xe_bo_notifier_prepare_pinned()/ xe_bo_notifier_unprepare_pinned() have the same bypass characteristic, though they never add their bo to a pinned list, so are not affected by this particular list-corruption issue. Move the pinned_link removal into xe_bo_account_unpin(), which already runs on every unpin path (kernel, external, framebuffer, backup object) right before the true 1 -> 0 pin_count transition. Since list_del_init() only operates on the node itself, this removal is list-agnostic and safe to perform regardless of which list (external or kernel_bo_present) the bo happens to be linked on, or which code path is performing the final unpin. Drop the now-redundant explicit list_del_init() calls in xe_bo_unpin_external() and xe_bo_unpin(). v2: - New patch v3: - Rebased on changes to previous patch. Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-xe@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.8+ Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Assisted-by: LLM Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20261002100830.12297-3-thomas.hellstrom@linux.intel.com (cherry picked from commit ca58d36a1f93af586ee93b340c9f9fd81312cc01) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-10-05drm/xe: Fix shrinker accounting double-subtraction on nested external pinsThomas Hellström
xe_bo_pin_external() and xe_bo_unpin_external() support nested pins, since the underlying ttm_bo_pin()/ttm_bo_unpin() maintain a pin_count refcount rather than a boolean. However, the shrinker accounting calls xe_ttm_tt_account_subtract() and xe_ttm_tt_account_add() are invoked unconditionally on every pin_external()/unpin_external() call, instead of only on the transition into and out of the pinned state. An external BO (dma-buf) can be pinned more than once while already pinned, for example when it has multiple attachments/importers, each independently calling xe_bo_pin_external(). Each such nested pin subtracts the BO's pages from the shrinker's accounting again, even though the BO's pages were already removed from consideration by the first pin. Symmetrically, each nested unpin adds them back again before the BO is actually unpinned. This desynchronizes the shrinker's page and object counts from reality, and since they are declared as signed long but interpreted as unsigned long in xe_shrinker_count(), the underflow can turn into an enormous shrinkable/purgeable page count, causing the shrinker to be invoked excessively under memory pressure. Guard the accounting calls with the same pin-count transition checks already used to guard the pinned_link list maintenance, so accounting is only updated on the outermost pin and the final unpin. While centralizing this logic into xe_bo_account_pin()/ xe_bo_account_unpin(), also close a second, related accounting gap affecting imported dma-bufs. For an imported bo's ttm_tt, xe's ttm_tt_populate hook (xe_ttm_tt_populate()) early-returns without calling xe_ttm_tt_account_add(), since TTM_TT_FLAG_EXTERNAL is set without TTM_TT_FLAG_EXTERNAL_MAPPABLE. However, TTM core's ttm_tt_populate() wrapper unconditionally marks the tt as populated on driver-hook success, so ttm_tt_is_populated() still reports true for it. xe_bo_account_pin()/xe_bo_account_unpin() trusted ttm_tt_is_populated() as a proxy for "these pages are accounted for by the shrinker", and would subtract/add pages for such a tt that were never added in the first place, again underflowing the shrinker's counts. This is reachable today via xe_bo_pin_external(), and would have become newly reachable via the fb-pin path once this patch routes __xe_pin_fb_vma() through xe_bo_pin_account() below, so fix it here rather than in a later patch, to avoid a commit in this series that introduces the regression before fixing it. Skip the accounting for imported bos, using the same EXTERNAL && !EXTERNAL_MAPPABLE test xe_ttm_tt_populate()/xe_ttm_tt_unpopulate() use to decide whether to act, via a new xe_ttm_bo_is_imported() helper (hoisted up from its only prior use site). v2: - Fix the critical issue caught by Sashiko AI review: the pin-count transition check introduced here was still bypassed by the fb-pin path (__xe_pin_fb_vma()/__xe_unpin_fb_vma()), which could leave a stale pinned_link entry and a permanent shrinker accounting leak when the fb-unpin performed the true last unpin. Addressed in a separate follow-up patch in this series rather than folded in here, since it is a distinct bug with its own Fixes: tag. - Drop the unneeded local "last_unpin" variable in xe_bo_unpin_external(), restoring the original inline bo->ttm.pin_count == 1 check; it was a no-op rename not used by any of the new accounting helpers, and was going to be deleted again by the follow-up patch anyway. v3: - Exclude imported dma-bufs from the pin/unpin shrinker accounting, fixing another underflow caught by Sashiko AI review. - Add a short comment on the backup-object pin site noting it's already populated/accounted at pin time, addressing (as a false-positive clarification, no code fix needed) a separate Medium-severity accounting-leak concern also caught by Sashiko AI review. Fixes: 00c8efc3180f ("drm/xe: Add a shrinker for xe bos") Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: intel-xe@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.15+ Reviewed-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Assisted-by: LLM Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patch.msgid.link/20261002100830.12297-2-thomas.hellstrom@linux.intel.com (cherry picked from commit 6a117a2bb7ca657e3a19f83f4c06265d38dee06c) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-10-05drm/xe: Do not emit Wa_16010904313 twiceTvrtko Ursulin
During development of commit e8372edec948 ("drm/xe/xelp: Implement Wa_16010904313") one of the interim patch versions contained an incorrect rebase on top of some upstream changes, which caused Wa_16010904313 to be emitted both from the indirect context and from the workaround batch buffer. As this workaround needs to be emitted from the indirect context for rcs and ccs, but from the workaround batch buffer for bcs, vcs and vecs, we need to pass the location as an input parameter to setup_timestamp_wa() so it can decide whether to emit itself or not. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: e8372edec948 ("drm/xe/xelp: Implement Wa_16010904313") Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patch.msgid.link/20260925080016.64802-1-tvrtko.ursulin@igalia.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [Rodrigo: small adjustments on commit message for check-patch] (cherry picked from commit 38631a7bce195b88814b93bf2b6d3e48c827fef2) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-10-05drm/xe/mmio: Fix xe_mmio_wait32() to honor delay/sleep maximumsAlan Previn
Check for overflow in udelay use in __xe_mmio_wait32 and avoid growing delays becoming intollerably large by capping the in-loop wait time. v7: - Change assisted-by to "LLM" (Rodrigo). - Move the max-wait macro to outside the function (Rodrigo). v6: - Fix commit message to remove items dropped in v5. Fix the use of MAX_UDELAY_MS for microsecond unit. (Shasiko review). v5: - Simplify: don't introduce additional redesign and use min_t with a backoff to cap wait. (Rodrigo). v4: - Simplify using poll_timeout_us and poll_timeout_us_atomic and update all callers to never use a param for atomic (Jani) v3: - Use div64_s64 kernel API for 32-bit vs 64-bit division. v2: - Fixed checkpatch failure. - Added helper for 64-bit DIV_ROUND_UP on 32-bit CPU (Shasiko review). Fixed bug max range in usleep_range(Shasiko review) Fixes: 5c09bd6ccd41 ("drm/xe/mmio: Move xe_mmio_wait32() to xe_mmio.c") Signed-off-by: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Assisted-by: LLM Link: https://patch.msgid.link/20260929192037.2233429-2-alan.previn.teres.alexis@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 70dab9ee7d620e6018a64798aed065d14e9baed1) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2026-10-05gpu: nova-core: Use bar1_resource_index() in NovaCoreApi::bar1_size()Alistair Popple
bar1_size() reports the length of PCI resource 1 as the size of BAR1. That is only correct when BAR0 is a 32-bit BAR. On Blackwell, and on some Ampere GA100 and Hopper SKUs, BAR0 is 64-bit and takes resource slots 0 and 1, pushing BAR1 to slot 2. Slot 1 is then the upper half of BAR0 rather than a BAR of its own, so NOVA_GETPARAM_VRAM_BAR_SIZE reports the wrong size on those GPUs. Probe handles this with the new bar1_resource_index(), which it uses to map BAR1, so use the same lookup here. Fixes: 7edc491f6fca ("drm: nova: Use nova-core to read VRAM_BAR_SIZE parameter") Signed-off-by: Alistair Popple <apopple@nvidia.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20261001005615.77130-1-apopple@nvidia.com [ Import the driver module. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-10-05drm: nova: Move VRAM BAR size query to GPU infoDanilo Krummrich
Nova exposes static information via its DRM_IOCTL_NOVA_INFO ioctl, thus add vram_bar_size to struct drm_nova_info_gpu and remove DRM_IOCTL_NOVA_GETPARAM and its uAPI definitions. This breaks the uAPI, which is still fine at this point. It requires the corresponding drm-test change in [1]. Link: https://gitlab.freedesktop.org/dakr/drm-test/-/merge_requests/2 [1] Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Eliot Courtney <ecourtney@nvidia.com> Reviewed-by: Alistair Popple <apopple@nvidia.com> Link: https://patch.msgid.link/20260927142258.1260711-1-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-10-05drm/msm/a6xx: check pm_runtime_resume_and_get during resumeRoman Demidov
The return values of pm_runtime_resume_and_get() calls in a6xx_pm_resume() are not checked, which can lead to hardware access on suspended devices and PM reference underflows. Fix this by checking the return value of each pm_runtime_resume_and_get() call and properly unwinding the previously acquired resources on failure. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 5a903a44a984 ("drm/msm/a6xx: Introduce GMU wrapper support") Signed-off-by: Roman Demidov <roman.demidov.nn@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/757106/ Message-ID: <20260929142103.81854-2-roman.demidov.nn@gmail.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-10-05drm/msm/a6xx: fix use-after-free of OPP in a6xx_pm_resumeRoman Demidov
The OPP reference obtained via dev_pm_opp_find_freq_ceil() is dropped with dev_pm_opp_put() before being passed to dev_pm_opp_set_opp(). If the reference count reaches zero, the OPP object may be freed, leading to a use-after-free when dev_pm_opp_set_opp() dereferences it. Fix the order of calls: first use the OPP to set the required performance state, then release the reference. Fixes: 5a903a44a984 ("drm/msm/a6xx: Introduce GMU wrapper support") Signed-off-by: Roman Demidov <roman.demidov.nn@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/757104/ Message-ID: <20260929142103.81854-1-roman.demidov.nn@gmail.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-10-05drm/msm/a5xx: Add hangcheck progress detectionDmitry Baryshkov
A5xx has no progress callback, so any submit still running when the hangcheck timer expires is declared hung, and long compute dispatches such as KHR-GLES31.core.compute_shader.simple-compute-shared_context are reset on A530 while still making progress. Comparing the CP IB1/IB2 state, as a3xx and a6xx do, is not enough: during a long dispatch the CP has fetched the whole IB and waits in one packet. Also count ALU working cycles on SP performance counter 0, which Mesa leaves to the kernel (and the kernel hasn't been using up to now). Assisted-by: LLM Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/757302/ Message-ID: <20260930-adreno-progress-v2-3-3882f0fcd7b4@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-10-05drm/msm/a3xx: Add hangcheck progress detectionDmitry Baryshkov
A3xx has no progress callback, so the hangcheck declares a lockup as soon as a submit is still running when the timer expires, no matter whether the CP is advancing. On A306 a piglit tex-miplevel-selection run is a single submit of about 58k draws that takes 1.2-1.3 s to complete, and it gets reset partway through on every run. With the hangcheck period raised to 10 s the same runs pass without a hang. Compare the CP IB1/IB2 base and remaining size between timer expirations, like a6xx does. On A306 these move on every 20 ms sample while such a submit executes and read zero when idle. The prefetch queues are small (32 and 64 for IB1 and IB2), so buffered data does not hide progress for long. Assisted-by: LLM Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/757301/ Message-ID: <20260930-adreno-progress-v2-2-3882f0fcd7b4@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-10-05drm/msm/a2xx: Add hangcheck progress detectionDmitry Baryshkov
A2xx has no progress callback, so any submit still running when the hangcheck timer expires is declared hung, no matter whether the CP is advancing. A false lockup is particularly expensive here: a2xx recovery is unreliable, and a second reset shortly after the first one leaves a2xx_hw_init() failing for good, so everything submitted afterwards fails as well. Compare the CP IB1/IB2 base and remaining size between timer expirations, like a6xx does. Assisted-by: LLM Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/757299/ Message-ID: <20260930-adreno-progress-v2-1-3882f0fcd7b4@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-10-05drm/msm/gem: Drop use of drm_prime_sg_to_page_array()Rob Clark
Now that we've removed any use of the page array outside of paths that are restricted to native (non-imported) objs, we can remove use of the deprecated function and allow msm_obj->pages to be NULL for imported dma-bufs. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Acked-by: Christian König <christian.koenig@amd.com> Patchwork: https://patchwork.freedesktop.org/patch/757711/ Message-ID: <20261002152948.85308-7-robin.clark@oss.qualcomm.com>
2026-10-05drm/msm/gem: Stop calling get_pages() for imported dma-bufsRob Clark
Use msm_obj->sgt rather than msm_obj->pages to determine that a obj is resident. The sgt is populated up-front for imported dma-bufs, so we will never go down the get_pages() path for imported objects. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Acked-by: Christian König <christian.koenig@amd.com> Patchwork: https://patchwork.freedesktop.org/patch/757710/ Message-ID: <20261002152948.85308-6-robin.clark@oss.qualcomm.com>
2026-10-05drm/msm/gem: Stop exposing a page arrayRob Clark
The remaining callers of msm_gem_pin_pages_locked() and msm_gem_get_pages_locked() don't actually care about pages, other than as a conduit for returning an error. So convert them to just directly return an int instead. And rename _get_pages_locked() to _make_resident_locked() to better reflect it's purpose. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Acked-by: Christian König <christian.koenig@amd.com> Patchwork: https://patchwork.freedesktop.org/patch/757708/ Message-ID: <20261002152948.85308-5-robin.clark@oss.qualcomm.com>
2026-10-05drm/msm/gem: Use get_pages() directly in vmap pathRob Clark
Split out a helper to check madv state, and inline what remains of msm_gem_get_pages_locked() in get_vaddr(). The vmap path is already disallowed on imported dma-bufs. And the rest of the callers of msm_gem_get_pages_locked() don't actually care about the pages, they just want to know that the obj is resident. This gets us one step closer to not actually caring about the page array for imported dma-bufs. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Acked-by: Christian König <christian.koenig@amd.com> Patchwork: https://patchwork.freedesktop.org/patch/757704/ Message-ID: <20261002152948.85308-4-robin.clark@oss.qualcomm.com>
2026-10-05drm/msm/gem: Mmap imported dma-bufs via the exporterRob Clark
This was always the way it was supposed to work, and when we drop the page array for imported dma-bufs our fault handling path will no longer work. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Christian König <christian.koenig@amd.com> Patchwork: https://patchwork.freedesktop.org/patch/757703/ Message-ID: <20261002152948.85308-3-robin.clark@oss.qualcomm.com>
2026-10-05drm/msm/gem: Add helper to check if residentRob Clark
Mostly we don't care about the page array, mapping/etc works in terms of the sgt. Add a helper to prepare for allowing the page array to be NULL for imported dma-bufs. Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Acked-by: Christian König <christian.koenig@amd.com> Patchwork: https://patchwork.freedesktop.org/patch/757702/ Message-ID: <20261002152948.85308-2-robin.clark@oss.qualcomm.com>
2026-10-05drm/msm: Sync registers from mesaRob Clark
Sync changes from mesa commit 81fae85847d2 ("freedreno/registers: Sync xml changes back from kernel"). Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/757953/ Message-ID: <20261003223723.400020-1-robin.clark@oss.qualcomm.com>
2026-10-05drm/msm/a5xx: don't read the GPMU registers on GPUs without a GPMUDmitry Baryshkov
Only a530/a540 have a GPMU. On the other a5xx parts, reading the 0xa800-0xac60 GPMU aperture during a crashdump resets the board -- on sda660 (a512) a GPU hang thus reboots the SoC instead of recovering. Split the GPMU block into its own array and collect it only when a GPMU is present. Fixes: e20c9284c8f2 ("drm/msm/adreno: Add support for Adreno 510 GPU") Assisted-by: LLM Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/754867/ Message-ID: <20260920-a5xx-no-gpmu-v1-1-714200254f76@oss.qualcomm.com> Signed-off-by: Rob Clark <robin.clark@oss.qualcomm.com>
2026-10-05drm/msm/dpu: round up the compressed INTF widthJoonhoe Kim
For DSI with DSC, drm_mode_to_intf_timing_params() scales the INTF active width by bpp / (3 * bits_per_component) and rounds down. The DSI host computes the same width with DIV_ROUND_UP, both for the pixel clock (dsi_adjust_pclk_for_compression()) and for the active width it programs (dsi_timing_setup(), from bytes per line). When the division is not exact the INTF line is one pclk shorter than the DSI line, and the DSI FIFO overflows. Example: a bonded DSI video-mode panel, 952 pixels per link, DSC 8 bpp at 10 bpc: 952 * 8 / 30 = 253.87, so the INTF uses 253 and the DSI 254. Round up, as the DSI host does. Qualcomm's downstream SDE driver also rounds this width up, and Pengyu Luo needed the same rounding on the Legion Y700 gen 4 [1]. Tested on a Lenovo Legion Tab Y700 gen 5 (SM8850) with that panel, with a module parameter selecting the rounding: rounding down, DPMS off/on gives no vblank and 14000-17000 DSI FIFO error interrupts per second (dsi_err_worker: status=4); rounding up, the picture comes back and there are no errors. Only tested on this device. Link: https://lore.kernel.org/all/CAH2e8h6oinKxN1ndcvHCSc+=bFLXVVDZVAVF0cQHoiaMvEwhPQ@mail.gmail.com/ [1] Fixes: f9ce482d7dc0 ("drm/msm/dpu: fix video mode DSC for DSI") Assisted-by: LLM Signed-off-by: Joonhoe Kim <26rote@gmail.com> Reviewed-by: Pengyu Luo <mitltlatltl@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/757958/ Link: https://lore.kernel.org/r/20261004102758.84436-1-26rote@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-10-05drm/ci: Remove sc7180-trogdor-lazor-limozeen jobVignesh Raman
sc7180-trogdor-lazor-limozeen devices in the LAVA lab have been experiencing stability issues, and 4 of the 6 devices have been retired. So remove the corresponding job from CI. Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-10-05gpu: nova-core: fix warning with NOVA_CORE_SELFTESTS disabledAlexandre Courbot
A module-wide new import becomes unused if the `NOVA_CORE_SELFTESTS` config option is disabled: warning: unused import: `Spec` --> ../drivers/gpu/nova-core/driver.rs:29:9 | 29 | Spec, // | ^^^^ | Fix this by fully qualifying the unique use of `Spec` when the tests are enabled. Fixes: 9cb3f5d56e81 ("gpu: nova-core: add an interrupt delivery self-test") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202610031630.JOlyp48X-lkp@intel.com/ Reviewed-by: John Hubbard <jhubbard@nvidia.com> Link: https://patch.msgid.link/20261004-nova-int-fixup-v1-1-9e4bce097f94@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-10-04media: Consolidate AtomISP v2 PCI IDs in the pci_ids.hAndy Shevchenko
We have a few drivers using same pair of the PCI IDs across the kernel and there seems more to go, consolidate AtomISP v2 PCI IDs in pci_ids.h database. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> # pci_ids.h Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-10-03drm/msm/dpu: compute the CRTC bandwidth from the state being checkedJoonhoe Kim
_dpu_core_perf_calc_bw() is called with the new CRTC state but sums plane_fetch_bw over drm_atomic_crtc_for_each_plane(), i.e. the planes of the committed state. When the CRTC is re-enabled (DPMS on, system resume) the committed state has no planes attached, so the check computes bw_ctl = 0 and the display runs without an average bandwidth vote on the MDP path until some later commit changes a plane -- which may not happen for a long time on a static screen such as a lock screen. Seen on a Lenovo TB323FU (SM8850) through the interconnect and DPU tracepoints: after DPMS off/on or s2idle, dpu_perf_crtc_update reported bw_ctl=0 and qnm_mdp was left at avg_bw=0 (peak 800000) instead of the 3728793 kBps voted before, until the next mode change. Iterate the plane states of the CRTC state being checked instead. drm_atomic_crtc_state_for_each_plane_state() falls back to the current plane state for planes that are not part of the commit, so the result is unchanged for commits that do touch the planes. With this, bw_ctl is 3728793600 right after DPMS on and after resume. Only tested on this device. Fixes: c33b7c0389e1 ("drm/msm/dpu: add support for clk and bw scaling for display") Assisted-by: LLM Signed-off-by: Joonhoe Kim <26rote@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/757683/ Link: https://lore.kernel.org/r/20261002130656.50577-1-26rote@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-10-03drm/msm/dpu: disable the slave encoder before the masterJoonhoe Kim
dpu_encoder_virt_atomic_disable() disables the physical encoders in phys_encs[] order, i.e. the master first. With a split display (two interfaces on one CTL, e.g. bonded DSI) the master's dpu_encoder_helper_phys_cleanup() then resets the shared CTL while the slave's timing engine is still running, and the source pipe is left stalled half-way through the slave's next frame. A power collapse of the MDSS core GDSC clears the stall, so it normally goes unnoticed. When MDSS stays powered across the disable (a full modeset, or an active DP controller), the next enable scans out nothing: black screen with the backlight on. Disable the slave before the master, as atomic_enable() enables them in that order. The slave's cleanup still resets the CTL while the master is running, but the last reset, from the master's cleanup, now happens with both timing engines stopped. Tested on a Lenovo Legion Tab Y700 gen 5 (SM8850, bonded DSI video-mode panel) with MDSS kept active: echo on > /sys/bus/platform/devices/9800000.display-subsystem/power/control DPMS off/on: black 10/10 before, picture 10/10 after. Full modesets were not retested with this version. Only tested on this device. Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Fixes: 22cb02bc96ff ("drm/msm/disp/dpu: reset the datapath after timing engine disable") Assisted-by: LLM Signed-off-by: Joonhoe Kim <26rote@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/757684/ Link: https://lore.kernel.org/r/20261002130712.50612-1-26rote@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-10-03drm/msm/dp: don't report link training success after a reinitOleg Keri
When every training attempt fails, the retry loop in msm_dp_ctrl_on_link() ends on a successful msm_dp_ctrl_reinitialize_mainlink(), leaving rc at 0. The caller then enables the stream on an untrained link and the display stays dark. The retry counter only reaches zero in that case, so treat it as a training failure. Fixes: 8ede2ecc3e5e ("drm/msm/dp: Add DP compliance tests on Snapdragon Chipsets") Signed-off-by: Oleg Keri <okerixx@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/756528/ Link: https://lore.kernel.org/r/20260925125314.16563-1-okerixx@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-10-03drm/msm: default separate_gpu_kms to auto selectionMahadevan P
On platforms with multiple display subsystems, such as SA8775P, the GPU binds to the first display subsystem that probes. This implicit binding prevents subsequent display subsystems from probing successfully, breaking multi-display support. Use the tristate separate_gpu_kms module parameter with the default value set to auto (-1). In auto mode, the driver selects the binding behavior based on the number of GPUs and display subsystems. This allows display subsystems to probe independently when required, while preserving the existing single-card behavior on simpler systems. The separate_gpu_kms module parameter has the following semantics: -1 (auto, default): Select the binding mode based on hardware topology. If exactly one GPU and one display subsystem are present, bind them together to form a single DRM device. Otherwise, expose the GPU and display subsystems as separate DRM devices. 0: Always bind the GPU and display together to form a single DRM device. 1: Always expose the GPU and display subsystems as separate DRM devices. Additionally, ensure that display subsystems are always exposed as separate DRM devices when no recognized Adreno GPU is present, regardless of the separate_gpu_kms setting. This ensures correct probing on multi-display platforms without affecting single-display, single-GPU systems. Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com> Patchwork: https://patchwork.freedesktop.org/patch/756649/ Link: https://lore.kernel.org/r/20260928-separate_gpu_kms-v4-1-3f33175de133@oss.qualcomm.com Acked-by: Rob Clark <robin.clark@oss.qualcomm.com> # on IRC Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
2026-10-03Merge tag 'drm-misc-next-2026-10-02' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v7.4: Cross-subsystem Changes: Documentation: - Fix indention in display-related DT bindings Core Changes: - Provide helpers for calculating absolute and relative timeouts clients: - fbdev: Move helpers from drm_kms_helper.ko to drm_client_lib.ko display: - dp/mst: Improve DPCD compliance sched: - fix locking Driver changes: amdxdna: - Support AIE2 rev 9 - Fix UAF access in scheduler fences - Update workqueue interface bridge: - Select DRM_PANEL_BRIDGE for various drivers that require it host1x: - Support partitioning imagination - Clean up firmware interface imx: - Replace simple-display with regular atomic helpers ivpu: - Simplify NULL-pointer handling in cleanup code mxsfb: - Support bus formats plus DT bindings panel: - ebbg-ft8719: Fix MODULE_LICENSE() string; Improve initialization - edp: NV140WU2-M70 - ilitek-ili9882t: Support Ilitek IL79600A plus DT bindings - simple: Support Truly TFT320240-229-E plus DT bindings; Support BOE DV215FHM-R01 plus DT bindings - Refactor struct drm_panel to contain struct drm_bridge plus fallout in various panel drivers panthor: - Validate user-space input against firmware limits renesas: - Support RZ/G3L SoC ssd130x: - ssd132x: Set correct hardware window when clearing screen host1x: - support partitioning panel: - fix fallout from bridge-related changes tegra: - improve syncobj handling on submit Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20261002120720.GA720384@linux.fritz.box
2026-10-03Merge tag 'amd-drm-fixes-7.3-2026-10-01' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/amdgpu/kernel into drm-fixes amd-drm-fixes-7.3-2026-10-01: amdgpu: - dc_state_create_copy() fix - HDMI RGB limited range fix - eDP ASSR fix - DCE 6 fixes - DCE 8.1 fix - SI DPM fixes - Reset fixes - Workaround for multiple SDMA entities with DCC - PWM backlight fix - GPUVM fixes - Switcheroo fix - Error handling leak fixes - GC 6 unload FW leak fix - SDMA 7.1 fix - DML frame size limit fix - RGB vs YCbCr 4:4:4 fix - DP MST fix - DC Power module fixes - MacBookPro14,3 fix amdkfd: - SVM fix radeon: - Sparc64 fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patch.msgid.link/20261001230115.1319089-1-alexander.deucher@amd.com
2026-10-03Merge tag 'mediatek-drm-fixes-20261002' of ↵Dave Airlie
https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-fixes Mediatek DRM Fixes - 20261002 1. Add missing IS_ERR check for ovl_adaptor platform device 2. Fix VID_DOWNSAMPLE_CONFIG register offset 3. Fix pdev reference leak in mtk_drm_bind() 4. Fix runtime PM leak in mtk_hdmi_ddc_v2_probe() 5. Fix ovl adaptor platform device leak Signed-off-by: Dave Airlie <airlied@redhat.com> From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://patch.msgid.link/20261001234906.14940-1-chunkuang.hu@kernel.org
2026-10-02drm/panfrost: add Mali-G68 supportMarkuss Broks
Add the features, issues, and ID for Mali-G68, a first-generation (v9) Valhall GPU. Tested on Exynos8835: the GPU reports GPU_ID 0x9204 (G68 r1p1). Signed-off-by: Markuss Broks <markuss.broks@gmail.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com> Link: https://patch.msgid.link/20260803-staging-mainline-v1-1-5071dc782149@gmail.com Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
2026-10-02Revert "drm/amd/display: Attach blend mode property for alpha planes"Alex Deucher
This reverts commit 44139872f22350b1e6c45da80e414caca81f11f5. This regresses blend mode handling. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-10-02Revert "drm/amd/display: replace STATIC_IFN_KUNIT with VISIBLE_IF_KUNIT"Alex Deucher
This reverts commit 7e9fca772695c65f97493272e2e7cd475f202965. This series breaks the build when CONFIG_KUNIT=y and CONFIG_DRM_AMD_DC_KUNIT_TEST=n. When CONFIG_KUNIT=y, the functions are not static, but when CONFIG_DRM_AMD_DC_KUNIT_TEST=n, they should be. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-10-02Revert "drm/amd/display: replace EXPORT_IF_KUNIT with EXPORT_SYMBOL_IF_KUNIT"Alex Deucher
This reverts commit b6b813e046e475bb3fe209d74f1df70033b5b98e. This series breaks the build when CONFIG_KUNIT=y and CONFIG_DRM_AMD_DC_KUNIT_TEST=n. When CONFIG_KUNIT=y, the functions are not static, but when CONFIG_DRM_AMD_DC_KUNIT_TEST=n, they should be. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-10-02Revert "drm/amd/display: drop INLINE_IFN_KUNIT"Alex Deucher
This reverts commit 5a98f454a61197761c4c5e8eed948dea2b9f5a69. This series breaks the build when CONFIG_KUNIT=y and CONFIG_DRM_AMD_DC_KUNIT_TEST=n. When CONFIG_KUNIT=y, the functions are not static, but when CONFIG_DRM_AMD_DC_KUNIT_TEST=n, they should be. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2026-10-02gpu: nova-core: add KUnit tests for the interrupt treeJohn Hubbard
The vector arithmetic and the leaf and subtree sets touch no hardware, so KUnit can cover them without a GPU. A wrong leaf, bit or subtree for a vector would otherwise show up only as a lost interrupt on hardware. Add the nova_core_gin_tree suite. It checks that a leaf index stops at the widest supported tree, that a leaf count implies the right number of subtrees and vectors, that a leaf count enumerates every leaf in order, that a vector maps to the right leaf, bit and subtree, and that a vector beyond an 8-leaf tree is rejected there and accepted in a 16-leaf tree. It also exercises the subtree set operations and checks that every supported chipset implements the subtree that carries the GSP event. Assisted-by: LLM Signed-off-by: John Hubbard <jhubbard@nvidia.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260930034148.590687-15-jhubbard@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-10-02gpu: nova-core: service GSP events from the SWGEN0 interruptJohn Hubbard
The GSP posts each message for the CPU to the GSP-to-CPU queue and then raises SWGEN0, a software-generated interrupt cause of its falcon. GIN delivers SWGEN0 to the CPU on vector 155. A thread waiting for a command reply was the only reader of the queue, so an event posted between commands stayed unread until the next command was sent. Register a threaded handler on the GSP vector. Draining the queue takes the command-queue mutex, which can sleep, so the top half reads and writes only registers and wakes the IRQ thread to drain the queue. Every existing read of the queue asks for one message type and waits on a deadline, so add a drain that logs and consumes whatever the GSP has already posted and returns at once. When a falcon cause other than SWGEN0 stays set after its latch is cleared, as the Blackwell fault-containment and ECC causes do, disable the GSP vector rather than retrigger the falcon. A retrigger would re-emit the cause at once, and the CPU would take the same interrupt again and again. Assisted-by: LLM Signed-off-by: John Hubbard <jhubbard@nvidia.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260930034148.590687-14-jhubbard@nvidia.com [acourbot: trim comment leaking unneeded implementation details.] [acourbot: make Subtree crate-visible here instead of in earlier patch.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-10-02gpu: nova-core: add the falcon interrupt registers and HAL methodsJohn Hubbard
A falcon latches each interrupt cause that is raised in its IRQSTAT register. On a RISC-V falcon, each cause is routed either to the host, meaning the CPU, or to the falcon's own core, and two routing registers hold that routing. The falcon signals the interrupt tree only when its set of host-routed causes goes from empty to non-empty, so a handler that clears the tree leaf while a cause is still latched has to write INTR_RETRIGGER, which makes the falcon re-emit its causes. Turing falcons have no INTR_RETRIGGER, and the routing registers have different offsets from GA102 on. Add IRQSTAT, INTR_RETRIGGER, and the two routing registers, the last at both sets of offsets, and add two falcon HAL methods: one intersects an IRQSTAT value with the routing registers, and one retriggers the falcon, or does nothing on Turing. GA100 keeps the Turing HAL, as it does for boot, and the retrigger register is a property of that HAL's instance. The two methods have no user yet. Assisted-by: LLM Signed-off-by: John Hubbard <jhubbard@nvidia.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260930034148.590687-13-jhubbard@nvidia.com [acourbot: remove implementation-specific comments on interface doc.] [acourbot: make constructor take boolean instead of having two methods.] [acourbot: add NVIDIA copyright headers to modified files.] Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
generated by cgit v1.2.3 (git 2.0.4) at 2026-10-30 00:52:17 +0000